Bluetooth® 저에너지 프라이머
4.1 Bluetooth 핵심 specification
6.6.2 Bluetooth Channel Sounding
7.8.1 LE ACL - LE 비동기 연결 지향 논리 전송
7.8.3 PADVB - LE 정기 광고 방송주기적 광고 브로드캐스트
7.8.5 LE BIS 및 LE CIS - 등시적 통신
8. Bluetooth® Channel Sounding
8.1 Bluetooth Channel Sounding 소개
8.3 데이터 전송 아키텍처에서의 Bluetooth Channel Sounding
8.4 Bluetooth Channel Sounding 방식 두가지
8.5 Bluetooth Channel Sounding 링크 레이어 제어 절차
8.13.3 Bluetooth Channel Sounding 보안 기능
13.4.1 Bluetooth SIG 정의된 속성에 한함
1. 개정 내역
| 버전 | 날짜 | 작성자 | 변경 사항 |
|---|---|---|---|
| 1.0.0 | 2022년 4월 22일 | 마틴 울리, Bluetooth SIG | 초기 버전. |
| 1.0.4 | 2022년 6월 6일 | 마틴 울리, Bluetooth SIG | 링크 Layer 섹션 개선: 여러 개의 링크 Layer 상태 머신 인스턴스가 허용된다는 정보 추가, 채널 분류가 선택적 구현 기능 명확히 하기 위해 언어 개선 기능 채널 상태 보고서와 채널 맵 업데이트를 구분, AFH가 규제 맥락에서 다른 의미를 가질 수 있음을 표시했습니다. |
| 1.1.0 | 2023년 1월 17일 | 마틴 울리, Bluetooth SIG | 블루투스® 핵심 사양 5.4를 반영하도록 업데이트되어 응답을 통한 주기적 광고 대한 정보가 추가되었습니다. |
| 1.2.0 | 2024년 3월 15일 | 이프티 아네즈, Bluetooth SIG | 관찰자 역할과 관련된 형식 업데이트 및 14.2 오타가 수정되었습니다. |
| 1.3.0 | 2024년 10월 15일 | 마틴 울리, Bluetooth SIG | Bluetooth® Channel Sounding, 결정 기반 광고 필터링 및 광고 송신기 모니터링 기능에 대한 정보와 프레임 간 공간 타이밍 변수의 수정된 허용 값을 포함하도록 업데이트되었습니다. |
2. 이 백서 정보
Bluetooth® 저에너지 입문서는 제품 설계자 및 개발자와 같은 기술 전문가가 공식 기술 사양을 참조하고 이 주제를 더 깊이 파고들기 전에 Bluetooth 저에너지(LE)에 대해 빠르게 배울 수 있도록 돕기 위해 만들어졌습니다.
Bluetooth SIG 제공하는 Bluetooth LE 대한 사양, 논문 및 기타 교육 자료는 상당수 존재합니다. 이 백서의 또 다른 목표는 이러한 자료의 존재와 목적에 대한 인식을 높이고 독자가 주제와 지원 자료에 대한 방향을 잡는 데 도움을 주는 것입니다.
대부분의 Bluetooth LE 제품은 무연결 통신(광고)과 지점 간 연결을 조합하여 데이터를 교환하거나 광고 패킷을 브로드캐스팅하는 방식으로만 통신합니다. 이 리소스에서는 이러한 범주에 속하는 제품에 사용되는 Bluetooth LE 스택을 다룹니다. 이와 대조적으로 여기서는 Bluetooth 메시를 다루지 않습니다. 블루투스 메시는 다른 정보 리소스를 참조해야 하는 Bluetooth LE 특수한 용도입니다.
이 백서의 목적은 공식 사양과 정확히 동일한 내용을 재현하거나 동일한 깊이로 다루는 것이 아닙니다. 때때로 적절하다고 판단되는 경우 사양에서 간략하게 발췌한 내용이 포함될 수 있습니다. 이 백서는 중요한 Bluetooth LE 개념을 소개하고 설명하여 방향을 제시하고 다른 리소스 및 사양으로 가는 길을 안내하며 학습 곡선을 조금 덜 가파르게 만드는 역할을 한다고 생각해야 합니다.
3. 소개
블루투스 기술은 2000년부터 사용되어 왔습니다. 처음에는 다른 중간 네트워킹 장비 없이 두 장치가 무선으로 데이터를 교환할 수 있도록 하기 위해 만들어졌지만, 무선 마우스와 차량용 핸즈프리 키트와 같은 제품에서 빠르게 그 역할을 찾았습니다. 후자는 오디오 제품 오디오는 이 오리지널 버전의 블루투스 기술의 킬러 앱으로 입증되었습니다. 그리고 수년 동안 계속 그렇게 되었습니다.
최초의 Bluetooth 제품에 사용된 Bluetooth 기술의 첫 번째 버전은 Bluetooth BR(기본 속도)로 더 공식적으로 알려져 있습니다. 이 기술은 물리적 Layer에서 초당 1백만 비트(1mb/s)의 원시 데이터 속도를 제공했습니다.
나중에 Bluetooth BR/EDR (향상된 데이터 전송률)로 알려진 더 빠른 버전의 Bluetooth 기술이 정의되었습니다. 이 기술은 2mb/s의 원시 데이터 속도를 제공했지만 여전히 두 디바이스 간에 직접 데이터를 교환하는 사용 사례를 위해 설계되었습니다.
Bluetooth 저에너지(LE)는 블루투스 코어 사양[1] 버전 4.0에서 처음 구체화되었습니다. 이는 이전 버전인 Bluetooth Bluetooth BR/EDR 대체하기보다는 새로운 세대의 제품에 적합하고 새롭고 까다로운 기술 및 기능 요구 사항을 충족할 수 있는 성능과 품질을 갖춘 대안으로서 함께 자리 잡은 새로운 버전의 Bluetooth 기술입니다.
Bluetooth LE 두 디바이스 간의 지점 간 통신 이외의 토폴로지를 지원하며, 하나의 디바이스가 동시에 무제한의 수신기로 데이터를 전송할 수 있는 다양한 브로드캐스트 기반 모드를 지원합니다. 또한 수만 개의 디바이스로 구성된 네트워크를 생성하고 각 디바이스가 네트워크의 다른 디바이스와 통신할 수 있는 Bluetooth 메시 네트워킹의 기반이 됩니다.
두 디바이스 간의 일대일 통신은 연결 지향 통신과 연결 없는 통신 모두에서 지원됩니다. 일대다 통신은 무연결 브로드캐스팅에서 지원됩니다.
애플리케이션 데이터가 통신할 수 있는 방향은 Bluetooth LE 사용하는 방식에 따라 다릅니다. 여기서 모드라는 용어는 이를 줄여서 사용할 수 있습니다. 일부 모드는 연결 지향 통신을 포함하며 일부 모드는 연결 없는 통신을 포함합니다. 일부 모드는 애플리케이션 데이터의 양방향 교환을 지원하지만 경우에 따라 애플리케이션 데이터는 한 방향으로만 이동할 수 있습니다.
일반적으로 애플리케이션 데이터는 시간과 중요한 관계가 없지만 시간과 중요한 관계가 있는 경우가 있으며, 디바이스는 수신된 데이터를 처리할 때 이러한 관계를 유지해야 합니다. Bluetooth LE 연결 지향 모드와 연결 없는 모드 모두에서 등시성 통신을 지원합니다. 비동기 통신은 데이터에 시간 제한이 있는 경우를 위해 설계되었습니다. 오디오가 이에 해당하는 좋은 예입니다.
Bluetooth LE 위치 관련 애플리케이션에서 사용하도록 설계된 여러 가지 디바이스 위치 추적 기능이 있습니다.
- 방향 탐지 은 수신기 전송된 신호의 방향을 계산할 수 있는 두 가지 방법을 정의합니다 수신기 이 두 가지 방법을도착각(Angle of Arrival)과출발각(Angle of Departure) 각도)이라고 합니다.
- Bluetooth® Channel Sounding 사용하면 두 장치가 협력하여 한 장치가 다른 장치와의 거리를 안전하게 계산할 수 있습니다.
이 새로운 Bluetooth 기술 변형의 원래 design 목표 중 하나는 에너지 사용 효율을 높이는 것이었습니다. 동전 크기의 작은 배터리로 며칠 또는 몇 주 이상 작동하는 디바이스를 구상했으며, 이러한 에너지 효율성 추구는 Bluetooth LE 많은 특징을 설명합니다. 특히, 이 design 장치에 비대칭적인 기능과 책임을 할당하여 대형 스마트폰 배터리와 같이 상대적으로 전원이 풍부한 장치가 동전형 배터리로 작동하는 피어 장치보다 더 많은 작업을 수행할 수 있도록 했습니다. 이러한 design 결정과 그 밖의 다른 design 결정 덕분에 Bluetooth LE 현재의 저전력 무선 통신 기술이 되었고, 이후 수년 동안 다양한 유형의 제품에 널리 채택될 수 있는 입지를 다지게 되었습니다.
4. Bluetooth LE 사양
Bluetooth LE 깊이 있고 철저하게 이해하려면 해당 사양에 대해 잘 알고 있어야 합니다. Bluetooth LE 아키텍처, 절차 및 프로토콜은 블루투스 코어 사양 하나의 핵심 사양에 의해 전체적으로 정의됩니다 블루투스 코어 사양 제품들이 상호 운용이 가능하도록 블루투스를 사용하는 방법은 프로파일과 서비스라고 하는 두 가지 특수 유형의 사양 모음에서 다룹니다. 그림 1은 Bluetooth LE 사양 유형과 그 관계를 보여줍니다.
그림 1 - Bluetooth LE 사양
4.1 Bluetooth 핵심 specification
블루투스 코어 사양 Bluetooth LE 블루투스 클래식 모두의 기본 사양입니다. 이 사양:
- 은 Bluetooth 기술의 아키텍처와 다양한 스택 구성의 Layer을 정의합니다.
- 주요 기능을 설명하고 정의합니다.
- 는 지원되는 작업을 뒷받침하는 공식 절차를 정의합니다.
- 는 디바이스가 스택의 관련 Layer 간에 통신하는 프로토콜을 정의합니다.
Bluetooth 핵심 specification은 필연적으로 큰 specification입니다.
요약하면 Bluetooth 핵심 specification은 Bluetooth 기술의 작동 방식과 Bluetooth 스택 또는 그 기능 중 하나 이상을 구현할 때 개발자에게 필요한 요구 사항을 정의합니다.
4.2 프로필 specification
두 개의 Bluetooth LE 장치가 연결을 통해 통신하는 경우 일반적으로 클라이언트 관계가 형성된 경우입니다. 서버는 상태 데이터를 포함하고 클라이언트는 어떤 방식으로든 해당 데이터를 사용합니다.
키를 어딘가에 내려놓았다가 일시적으로 분실했을 때 키를 찾는 데 도움이 되는 블루투스 리모트키를 생각해 보세요. 스마트워치는 클라이언트 디바이스 역할을 하고 블루투스 리모트키가 서버 역할을 할 수 있습니다. 스마트워치 디스플레이의 버튼을 누르면 리모트키의 상태 변경되고 이 변경에 따라 큰 소리가 나도록 하여 키를 다시 찾을 수 있도록 할 수 있습니다.
프로필 specification은 관련 장치(예: 스마트워치 및 리모트키)가 맡는 역할을 정의하며, 특히 클라이언트 장치의 동작과 연결된 서버의 데이터에 대해 정의합니다.
키 찾기 예제에서 스마트워치 또는 동일한 역할을 맡는 다른 디바이스의 동작은 찾기 프로필 사양에 정의되어 있습니다.
4.3 서비스 specification
서버의 상태 데이터는 특성 및 설명자[2]로 알려진 공식적으로 정의된 데이터 항목에 존재합니다. 특성과 설명자는 서비스라는 구조 안에 그룹화됩니다. 서비스는 그 안에 포함된 특성과 설명자에 의미와 동작을 할당할 수 있는 컨텍스트를 제공합니다.
서비스 명세는 하나의 서비스와 그 서비스에 포함된 특성 및 설명자를 정의합니다. 다양한 조건과 상태 데이터 값에 따라 서비스를 호스팅하는 디바이스가 보여줄 동작은 서비스 specification에 정의되어 있습니다.
서비스 specification은 서버 디바이스 동작의 한 측면을 정의하는 것으로 생각할 수 있습니다.
스마트워치와 리모트키 예시에서는 리모트키가 서버 역할을 하며 즉시 알림 서비스를 구현합니다.
4.4 프로토콜 specification
일부 표준화된 Bluetooth 애플리케이션에는 자체 프로토콜이 필요하며, 이러한 프로토콜에는 자체 specification이 있습니다. 기본 Bluetooth Mesh specification은 프로토콜 specification입니다.
4.5 할당 번호
Bluetooth LE 다양한 측면에서는 고유 식별자를 사용합니다. 예를 들어, 모든 서비스, 특성 및 설명자에는 특정 장치의 특정 인스턴스가 아닌 해당 서비스, 특성 또는 설명자와 관련된 유형의 유형을 식별하는 UUID(범용 고유 식별자)가 있습니다. 회사는 특정 프로필에 필요한 고유한 회사 식별자로 식별될 수 있습니다.
Bluetooth SIG 할당하는 식별자는 다음과 같습니다. 할당 번호 라고 하며, 이러한 식별자의 전체 목록은 Bluetooth SIG 웹사이트의 할당 번호 페이지에서 확인할 수 있습니다.
5. Bluetooth LE 스택
5.1 상위 Layer 아키텍처
Bluetooth LE 스택은 여러 계층과 기능 모듈로 구성되며, 그 중 일부는 필수이고 일부는 선택 사항입니다. 스택의 이러한 부분은 다음과 같은 두 가지 주요 아키텍처 블록에 분산되어 있습니다. host컨트롤러와 표준 논리 인터페이스는 이 두 구성 요소가 통신할 수 있는 방법을 정의합니다.
host 운영 체제와 같은 역할을 하는 경우가 많습니다. 컨트롤러는 종종 칩에 내장된 시스템입니다. 그러나 반드시 그런 것은 아니며 Bluetooth 사양에서는 이러한 구현 세부 사항을 의무화하지 않습니다. 중요한 것은 host 컨트롤러가 아키텍처에서 별도의 논리적 컨테이너 역할을 하며, 어떤 방식으로든 물리적으로 분리된 구성 요소로 구현될 수 있고, 이들 간의 통신을 위해 정의된 표준 인터페이스가 있다는 것입니다. 따라서 Bluetooth 시스템은 서로 다른 제조업체의 host 및 컨트롤러 구성 요소로 구성될 수 있습니다.
그림 2는 Bluetooth LE 스택과 그 계층, host 및 컨트롤러 구성 요소에 대한 분포를 보여줍니다.
Host Controller 인터페이스(HCI)는 이들 간의 논리적 인터페이스를 나타내지만 물리적 구성 요소는 아닙니다. HCI는 기본 물리적 전송 측면에서 여러 가지 방식으로 구현될 수 있지만 논리적 또는 기능적 인터페이스는 항상 동일합니다.
LC3는 Bluetooth LE 오디오에 사용되는 기본 오디오 코덱인 저복잡도 통신 코덱입니다. 표준 Bluetooth LE 스택에는 포함되지 않지만, 그림과 같이 host 또는 controller에 구현된 LC3 구성 요소와 함께 항상 LE 오디오 제품에서 찾을 수 있습니다.
그림 3은 통신 시스템을 위한 표준 OSI 참조 모델을 보여줍니다. 물리 및 데이터 링크 레이어와 같은 OSI 레이어의 서브셋 포함하는 다른 많은 무선 시스템과 달리, Bluetooth LE 스택은 OSI 참조 모델의 모든 레이어에 걸쳐 있다는 점에 유의해야 합니다. 풀 스택 통신 시스템인 Bluetooth 기술의 한 가지 장점은 다른 표준 단체에 대한 외부 의존성이 없다는 것입니다. 이러한 종속성은 기술의 진화를 제한할 수 있습니다.
그림 2 - Bluetooth LE 스택
그림 3 - OSI 참조 모델
블루투스 메시 프로토콜은 Bluetooth LE 핵심 기능을 사용하며 블루투스 메시 프로토콜 및 절차를 구현하는 특수 레이어 모음을 코어 Host 추가합니다. host 연결 형성 기능과 같은 기타 제품 요구 사항을 지원하는 데 필요한 그림 2의 host 부분에 표시된 모든 계층이 포함될 수 있습니다.
이 리소스에서는 블루투스 메시를 더 이상 다루지 않으므로 이 주제에 대한 교육 리소스를 찾고 계신다면 섹션 18을 참조하세요. 아래의 추가 리소스를 참조하세요.
그림 4 - Bluetooth Mesh 스택
5.2 레이어 한눈에 보기
그림 2에 표시된 대로 Bluetooth LE 스택의 각 계층의 주요 책임과 특징을 요약하면 다음과 같습니다:
| 레이어 | 주요 책임 |
|---|---|
| 물리적 계층 | 변조 방식, 주파수 대역, 채널 사용, 송신기 및 수신기 특성 등 무선(RF) 사용과 관련된 Bluetooth 기술의 모든 측면을 정의하며, 지원되는 여러 가지 물리 계층 파라미터의 조합이 정의되어 있으며 이를 PHY라고 합니다. |
| 링크 Layer | 무선 인터페이스 패킷 형식, 오류 확인과 같은 비트 스트림 처리 절차, 무선 통신 및 링크 제어를 위한 상태 머신 및 프로토콜을 정의합니다. 논리적 전송으로 알려진 무접속, 연결 지향 및 등시성 통신을 위해 기본 라디오를 사용하는 몇 가지 고유한 방법을 정의합니다. |
| Channel Sounding | 애플리케이션 계층에서 다른 디바이스와의 거리를 계산하는 데 사용할 수 있는 측정을 수행할 수 있는 기능을 디바이스에 제공합니다. 위상 기반 거리 측정 위상 기반 거리 측정(PBR)))과왕복 시간(RTT) 타이밍왕복 시간(RTT)))이라는 두 가지 방법이 통합되어 있습니다. 이러한 메토는 함께 또는 개별적으로 사용할 수 있습니다. |
| 비동기 적응 계층(ISOAL) | 등시성 통신을 사용하는 장치에서 서로 다른 프레임 지속 시간을 사용할 수 있으며, 프레임된 PDU의 분할 및 재조립 또는 프레임되지 않은 PDU의 분할 및 재조합을 수행합니다. |
| Host 컨트롤러 인터페이스(HCI) | host 구성 요소와 컨트롤러 간의 명령 및 데이터 양방향 통신을 위한 잘 정의된 기능 인터페이스를 제공하며, 여러 물리적 전송 구현 중 하나에서 지원됩니다. |
| 논리적 링크 제어 및 적응 프로토콜(L2CAP) | host 내에서 프로토콜 멀티플렉서 역할을 수행하여 적절한 host 구성 요소에서 프로토콜이 서비스되도록 하며, 아래 계층과 L2CAP 위 계층 간에 PDU/SDU의 세분화 및 재조립을 수행합니다. |
| 보안 관리자 프로토콜(SMP) | 페어링과 같은 보안 절차를 실행하는 동안 사용되는 프로토콜입니다. |
| 속성 프로토콜(ATT) | 서버의 속성 테이블에서 데이터를 검색하고 사용할 수 있도록 하는 ATT 클라이언트 ATT 서버에서 사용하는 프로토콜입니다. |
| 일반 속성 프로필(GATT) | 속성 테이블의 기본 속성과 관련하여 서비스, 특성 및 설명자로 알려진 상위 수준의 데이터 유형을 정의하고, ATT를 사용하여 속성 테이블과 함께 작업하기 위한 상위 수준의 절차를 정의합니다. |
| 일반 액세스 프로필(GAP) | 비연결 상태 때 사용할 수 있는 운영 모드 및 절차(예: 연결되지 않은 통신을 위한 광고 사용 방법 및 디바이스 검색 수행 방법)를 정의합니다.보안 수준 및 모드를 정의합니다.일부 사용자 인터페이스 표준을 정의합니다. |
6. 물리 Layer
Bluetooth LE 물리적 계층은 무선 수신기 송수신을 위해 디지털 데이터를 인코딩 및 디코딩하는 데 사용되는 방법과 적용되는 기타 무선 관련 파라미터 및 속성을 정의합니다.
6.1 주파수 대역
Bluetooth LE 2400MHz ~ 2483.5MHz 범위의 2.4GHz 비면허 대역에서 작동하며 각 폭이 2MHz인 40개의 채널로 나뉩니다. 채널 사용 방식은 링크 Layer 데이터 전송 아키텍처에 의해 정의됩니다.
그림 5 - Bluetooth LE 채널
6.2 변조 방식
6.2.1 가우시안 주파수 편이 변조
전송 전에 스택의 상위 계층에서 디지털 데이터를 인코딩하고 수신된 무선 신호를 디코딩하기 위해 Bluetooth LE 가우스 주파수 시프트 키잉(GFSK)이라는 변조 방식을 사용합니다. GFSK는 선택한 채널( 반송파)의 중심 주파수를 가진 신호를 지정된 양만큼 위로 이동하여 디지털 값 1을 나타내거나 같은 양만큼 아래로 이동하여 이진 값 0을 나타내는 방식으로 작동합니다. 가우스 필터링이 신호에 적용되어 급격한 주파수 변경에 수반되는 노이즈를 줄입니다.
그림 6은 기본 주파수 시프트 키잉 프로세스를 보여줍니다. 주파수가 시프트되는 양을 주파수 편차라고 하며, 사용 중인 PHY 변형에 따라 최소 +/-185kHz 또는 최소 370kHz입니다(PHY는 6.3 PHY 변형 섹션에서 설명함).
그림 6 - Bluetooth LE 주파수 시프트 키잉
6.2.2 진폭 편이 변조(ASK)
Channel Sounding (섹션 8.Bluetooth® 채널 사운딩 참조)은 일부 전송에 ASK(진폭 시프트 키잉)라는 변조 방식을 사용합니다. ASK는 두 가지 심볼 상태가 있는 이진 변조 방식입니다. 첫 번째는 특정 기간 동안 선택한 주파수에서 고정 진폭 반송파를 전송하는 것으로 표현됩니다. 두 번째는 선택한 주파수에서 해당 기간 동안 전송이 없는 상태로 표시됩니다.
6.3 PHY 변형
여러 변조 방식 변형이 정의되어 있습니다. 각 변조 방식을 PHY라고 하며 이름이 있습니다. 물리 계층은 디지털 개념이 아닌 아날로그 무선 아티팩트만 다루기 때문에 물리 계층의 전송 속도는 초당 비트가 아닌 초당 심볼로 측정됩니다.
Bluetooth LE 이진 변조 방식을 사용하므로 단일 아날로그 심볼이 스택에서 단일 디지털 비트를 더 높게 나타냅니다.
각 PHY에는 대역폭-비트 주기 제품 (BT)이라는 속성 포함되어 있습니다. BT는 신호의 대역폭과 심볼의 지속 시간 간의 관계를 결정합니다.
BT 값은 기호를 구성하는 무선 펄스의 모양과 스팬에 영향을 줍니다. BT 값이 높을수록 펄스의 폭이 좁고 사각형이 되며, 값이 낮을수록 펄스의 모양이 넓고 둥글어집니다.
Bluetooth Core specification에 정의된 PHY 유형은 다음과 같이 요약되어 있습니다:
- LE 1M PHY는 최소 185kHz의 필수 주파수 편차에서 1Msym/s의 심볼 속도를 사용하며 특별한 코딩을 사용하지 않습니다. 모든 디바이스는 LE 1M PHY를 지원해야 합니다. 이 PHY의 BT=0.5.
- The LE 2M PHY는 LE 1M과 유사하지만 2Msym/s의 심볼 속도를 사용하며 필요한 주파수 편차가 최소 370kHz입니다. LE 2M PHY에 대한 지원은 선택 사항입니다. 이 PHY의 BT=0.5.
- LE 2M 2BT PHY의 심볼 레이트는 2Msym/s이지만 최소 420kHz의 주파수 편차가 필요합니다. 이 PHY에서는 BT=2입니다.
- The LE 코디드 PHY는 1 Msym/s의 심볼 속도를 사용하지만 패킷은 링크 Layer 정의된 순방향 오류 수정(FEC)이라는 코딩의 적용을 받습니다. FEC는 전송의 유효 범위를 증가시키지만 애플리케이션 데이터 속도를 감소시킵니다. LE 코디드 PHY에 대한 지원은 선택 사항입니다. 이 PHY를 사용하면 BT=0.5.
PHY의 비교는 다음과 같습니다:
| LE 1M | LE 코디드 S=2 | LE 코디드 S=8 | LE 2M | LE 2M 2BT | |
|---|---|---|---|---|---|
| 심볼 비율 | 1 Ms/s | 1 Ms/s | 1 Ms/s | 2 Ms/s | 2 Ms/s |
| 프로토콜 데이터 속도 | 1 Mbit/s | 500 Kbit/s | 125 Kbit/s | 2 Mbit/s | 2 Mbit/s |
| 대략적인 최대. 애플리케이션 데이터 속도 | 800kbps | 400kbps | 100 kbps | 1400 kbps | 해당 없음[3] |
| BT | 0.5 | 0.5 | 0.5 | 0.5 | 2.0 |
| 오류 감지 | CRC | CRC | CRC | CRC | 해당 없음[4] |
| 오류 수정 | 없음 | FEC | FEC | 없음 | 없음 |
| 범위 배율(대략) | 1 | 2 | 4 | 0.8 | 0.8 |
| 요구 사항 | 필수 | 선택 사항 | 선택 사항 | 선택 사항 | 선택 사항 |
정의
| 기간 | 정의 |
|---|---|
| 심볼 비율 | 물리 계층에서 아날로그 심볼이 전송되는 속도입니다. |
| 프로토콜 데이터 속도 | 애플리케이션 데이터 페이로드를 포함하지만 LE 코디드 PHY가 사용 중일 때 패킷에 포함된 FEC 데이터를 제외한 Bluetooth 프로토콜 데이터 유닛(PDU)과 관련된 비트의 전송 속도입니다. |
| 대략적인 최대. 애플리케이션 데이터 속도 | 통신 장치의 애플리케이션 간에 애플리케이션 데이터를 전송할 수 있는 대략적인 최대 속도입니다. 애플리케이션 데이터는 다양한 PDU의 페이로드 부분에서 전송되며 나머지 프로토콜 데이터 속도는 Bluetooth 프로토콜 데이터에 의해 소비됩니다. |
| CRC | 주기적 중복 검사. 전송 오류를 감지하는 데 사용되는 필드입니다. 이 필드와 그 사용법은 링크 Layer 정의되어 있습니다. |
6.4 시간 분할
Bluetooth LE 라디오는 반이중 장치로, 송신 및/또는 수신이 가능하지만 동시에 두 가지를 모두 수행할 수는 없습니다. 그러나 모든 PHY는 전이중 무전기처럼 보이도록 시분할 이중(TDD) 방식에 사용됩니다.
6.5 송신 전력 및 수신 감도
물리적 Layer은 출력 전력 요구 사항을 포함한 송신기 특성을 정의하며, specification에 따르면 최대 전력 설정 시 출력 전력 레벨은 0.01mW(-20dBm)에서 100mW(+20dBm) 사이여야 한다고 명시되어 있습니다.
세계 각지의 규제 기관[5] 은 이러한 요구 사항을 무시할 수 있으며, 구현자는 디바이스가 해당 지역 규정을 준수하는지 확인해야 합니다.
수신기 감도는 특정 비트 오류율(BER)이 발생하는 수신기 입력 레벨로 정의됩니다. 링크 Layer이 각 패킷에 단일 CRC(순환 중복 검사) 필드를 추가하고 이를 디코딩된 패킷에서 하나 이상의 오류 비트를 감지하는 메커니즘으로 사용하기 때문에 지정된 BER은 수신된 패킷의 길이에 따라 달라집니다. 패킷의 길이가 다양하고 패킷당 하나의 CRC가 있기 때문에 패킷의 길이가 계산된 BER에 영향을 미칩니다.
일반적으로 Bluetooth LE 수신기 감도에 대한 논의에서 0.1%의 BER이 인용됩니다. 이는 최대 37옥텟 길이의 패킷에 허용되는 최대 오류율입니다.
물리적 Layer에서 정의한 기타 수신기 특성에는 간섭 성능, 대역 외 차단, 상호 변조 특성, 사용 가능한 최대 입력 레벨 및 수신 신호 강도 표시(RSSI)의 필수 정확도 등이 있습니다.
6.6 안테나 전환
6.6.1 방향 탐지
Bluetooth LE 는 수신 신호가 전송된 방향을 계산하는 두 가지 방법을 지원합니다. 첫 번째는 도래각(Angle of Arrival)입니다. 도착각(Angle of Arrival) ) 그리고 두 번째, 출발 각도( 출발각(Angle of Departure) ). 두 방법 모두 안테나 배열을 갖춘 하나의 장치와 방향 탐색 신호 전송 중에 한 안테나에서 다른 안테나로 전환하는 프로세스를 포함합니다. 출발각(Angle of Departure) 방법) 또는 신호를 수신할 때( 도착각(Angle of Arrival) 방법). 방향 탐지 신호는 CTE(Constant Tone Extension) 필드를 포함하는 표준 Bluetooth 패킷입니다.
안테나 어레이는 다양한 디자인으로 제공되며 한 안테나에서 다음 안테나로 전환할 때 다양한 스위칭 패턴을 따를 수 있습니다. 이는 host 의해 제어되지만 물리 Layer은 안테나 스위칭 프로세스, 관련 수신기 요구 사항 및 몇 가지 유용한 정의에 대해 일반적으로 적용되는 몇 가지 규칙도 정의합니다.
블루투스 코어 사양 이 주제에 대한 자세한 내용을 6권, 파트 A, 섹션 5에서 다룹니다. 도착각(Angle of Arrival) 및 출발각(Angle of Departure) 방향 탐지 기능 대한 자세한 내용은 블루투스 코어 사양 버전 5.1 기능 개요 문서에서 확인할 수 있습니다.
6.6.2 Bluetooth Channel Sounding
Bluetooth Channel Sounding 두 장치 중 하나 또는 둘 모두에서 둘 이상의 안테나를 사용할 수 있으며 안테나 선택 및 사용에 관한 규칙이 있습니다. 섹션 8.Bluetooth® 채널 사운드를 참조하세요.
7. 링크 레이어
7.1 링크 레이어 개요
링크 레이어 사양은 Bluetooth 핵심 사양의 Bluetooth LE 섹션 중 Host controller 인터페이스 기능 사양 섹션 다음으로 가장 큰 섹션입니다. 하지만 가장 복잡하다는 것은 틀림없습니다.
링크 Layer에는 많은 책임이 있습니다. 무선으로 전송되는 여러 유형의 패킷과 관련 무선 인터페이스 프로토콜을 정의합니다. 링크 Layer의 작동은 잘 정의된 상태 머신의 영향을 받습니다. 상태에 따라 링크 Layer은 여러 유형의 이벤트에 의해 매우 다양한 방식으로 작동할 수 있습니다. 링크의 상태 또는 링크 사용 매개변수에 영향을 미치는 수많은 제어 절차가 정의되어 있습니다. 무선 채널 선택 및 분류는 링크 Layer specification에 정의되어 있습니다.
링크 Layer은 연결 및 비연결 통신과 결정론적 및 (약간) 무작위 이벤트 타이밍을 모두 지원합니다. 두 디바이스 간의 지점 간 통신과 한 디바이스에서 무제한의 수신 디바이스로 동시에 전송하는 일대다 통신을 모두 지원합니다. 사용되는 링크 Layer에 따라 애플리케이션 데이터의 전송은 양방향으로 이루어지거나 한 방향으로만 진행될 수 있습니다.
Bluetooth LE 다재다능함의 대부분은 링크 Layer 정교함에 뿌리를 두고 있습니다.
7.2 패킷
링크 Layer 두 가지 패킷 유형을 정의합니다. 첫 번째는 코딩되지 않은 PHY(그림 7 참조), LE 1M 및 LE 2M 사용되며 두 번째는 LE 코디드 PHY에서 사용됩니다(그림 8 참조). 다른 패킷 유형은 Channel Sounding 함께 사용하도록 정의되어 있습니다.
그림 7 - LE 비코딩 PHY용 링크 Layer 패킷 형식
그림 8 - LE 코디드 PHY용 링크 Layer 패킷
두 패킷 유형 모두 프리앰블, 액세스 주소, CRC 필드를 포함합니다. 표 1은 이러한 각 공통 필드에 대해 설명합니다.
| 링크 Layer 패킷 필드 이름 | 묘사 |
|---|---|
| 서문 | 프리앰블을 통해 수신기 신호의 주파수를 정확하게 동기화하고 자동 이득 제어를 수행하며 심볼 타이밍을 예측할 수 있습니다. |
| 액세스 주소 | 액세스 주소 수신기에서 신호를 배경 잡음과 구별하고 패킷과 수신 디바이스의 관련성 여부를 판단하는 데 사용됩니다. 예를 들어, 연결된 한 쌍의 디바이스는 무작위로 할당된 동일한 액세스 주소 패킷을 교환합니다. 연결에 참여하지 않는 디바이스는 해당 액세스 주소 자신과 관련이 없는 주소이므로 해당 패킷을 무시합니다. 마찬가지로 모든 레거시 광고 패킷은 모든 디바이스에서 수신할 수 있음을 나타내는 0x8E89BED6 값의 동일한 액세스 주소 사용합니다. |
| CRC | 순환 중복 검사는 오류 감지에 사용됩니다. 이 값은 송신기 패킷의 다른 비트 값을 사용하여 계산합니다. 패킷을 수신하면 수신 장치도 수신된 패킷의 비트 값 중 CRC 필드를 구성하는 비트를 제외한 나머지 비트의 값으로 CRC 값을 계산합니다. 그런 다음 수신기계산된 CRC를 패킷의 CRC 필드 값과 비교합니다. 두 CRC 값이 일치하면 패킷이 올바르게 수신된 것입니다. 그렇지 않으면 하나 이상의 비트에 오류가 있는 것으로 간주합니다. |
표 1 - 공통 링크 Layer 패킷 필드
링크 Layer 패킷의 PDU 필드에는 Bluetooth LE 사용 방식에 따라 다양한 프로토콜 데이터 단위(PDU)가 포함될 수 있습니다. CTE(일정한 톤 확장)는 두 가지 방향 탐지 방법(도착 각도 또는 출발 각도) 중 하나가 사용 중인 경우에만 존재합니다.
패킷이 전송되기 전에 PDU 및 CRC 필드는 화이트닝이라는 프로세스를 거칩니다. 화이트닝의 목적은 패킷에 긴 0 또는 1 시퀀스가 포함되면 수신기주파수 잠금이 드리프트될 수 있으므로 이를 방지하는 것입니다. 화이트닝 프로세스는 수신기 원래의 비트 스트림을 복원하기 위해 CRC를 확인하기 전에 역으로 진행됩니다.
PDU 필드는 암호화될 수 있으며, 이 경우 PDU가 변조되지 않도록 보호하는 메시지 무결성 검사 필드가 포함됩니다[6].
LE 코디드 PHY가 사용 중일 때 비트 스트림은 전송 전에 추가 처리를 거치게 됩니다. 순방향 오류 수정(FEC) 인코더와 패턴 매퍼를 애플리케이션 수신기 이러한 프로세스를 역으로 적용하고 가능한 경우 잘못된 값을 가진 비트의 값을 수정할 때 사용하는 추가 데이터가 생성됩니다.
7.3 상태 머신
링크 Layer 그림 9에 표시된 상태 머신에 의해 관리됩니다.
그림 9 - 링크 Layer 상태 머신
각 상태 대한 자세한 내용은 링크 Layer 사양을 참조하세요. 표 2에 요약이 나와 있습니다. 일부 용어는 이 섹션의 뒷부분에서 설명합니다.
| 상태 | 묘사 |
|---|---|
| 대기 | 장치가 패킷을 전송하거나 수신하지 않습니다. |
| 시작 | 특정 디바이스의 광고 패킷에 응답하여 연결을 요청합니다. |
| 광고 | 광고 패킷을 전송하고 다른 디바이스에서 광고 패킷에 대한 응답으로 전송된 패킷을 처리할 수 있습니다. |
| 연결 | 다른 디바이스와의 연결에서. |
| 스캔 | 다른 디바이스의 광고 패킷을 수신 대기 중입니다. |
| 비동기식 생방송 | 등시성 데이터 패킷을 브로드캐스트합니다. |
| 동기화 | 특정 디바이스에서 전송되는 특정 광고 트레인에 속한 주기적 광고 수신합니다. |
표 2 - 링크 Layer 상태
연결 상태 두 가지 중요한 장치 역할이 정의됩니다. 중앙 역할과 주변 장치 역할이 그것입니다. 연결을 시작하고 시작 상태 연결 상태 전환하는 장치는 중앙 역할을 맡습니다. 연결 요청을 수락하여 광고 상태 연결 상태 전환하는 장치는 주변 장치 역할을 맡습니다.
예를 들어 애플리케이션 사용할 수 있도록 측정값을 스마트폰으로 전송하는 심박수 모니터를 생각해 보세요. 일반적으로 스마트폰은 중앙 역할을 맡고 심박수 모니터는 주변 역할을 맡습니다. 스마트폰은 광고 패킷을 스캔하여 모니터를 검색한 다음 일반적으로 사용자의 참여로 모니터에 대한 연결을 시작합니다. 연결되면 심박수 프로필 사양에 정의된 추가 절차에 따라 스마트폰 애플리케이션 모니터에 연결을 통해 측정값 전송을 시작하도록 지시합니다.
스테이트 머신의 인스턴스는 한 번에 하나의 상태만 존재할 수 있습니다. 링크 Layer 구현은 둘 이상의 상태 머신 인스턴스를 동시에 지원할 수 있습니다.
모든 역할 및 상태 조합이 허용되는 것은 아닙니다. 이에 대한 자세한 내용은 Bluetooth 핵심 specification을 참조하세요.
7.4 채널 선택
6.1 주파수 대역 섹션에서 설명한 대로 Bluetooth LE 2.4GHz 주파수 대역을 40개의 채널로 나눕니다. 링크 Layer 이러한 채널이 사용되는 방식을 제어하며, 이는 다시 Bluetooth LE 통신에 사용되는 전반적인 방식(보다 공식적으로는 현재 물리적 채널 - 이에 대해서는 7.7 데이터 전송 아키텍처 섹션에서 다룸)에 따라 달라집니다.
Bluetooth LE 다양한 방식으로 확산 스펙트럼 기술을 사용하여 시간이 지남에 따라 여러 채널을 통해 데이터를 통신합니다. 이렇게 하면 충돌 가능성이 줄어들어 통신이 더욱 안정적으로 이루어집니다.
Bluetooth LE 사용되는 확산 스펙트럼 기술의 잘 알려진 예로는 적응형 주파수 호핑이 있습니다. 여기에는 패킷 통신에 사용되는 무선 채널이 일정한 간격으로 변경되는 것이 포함됩니다. 채널은 채널 선택 알고리즘과 각 채널을 사용 또는 미사용으로 분류하는 채널 맵이라는 데이터 테이블을 사용하여 선택됩니다. 구현은 각 채널의 통신 품질을 모니터링할 수 있으며, 다른 소스의 간섭으로 인해 채널의 성능이 좋지 않은 것으로 확인되면 채널 맵을 업데이트하여 해당 채널의 분류를 미사용으로 설정하고 더 이상 알고리즘에서 이 채널을 선택하지 않도록 할 수 있습니다. 이러한 방식으로 채널 선택 알고리즘은 현재 상황에 맞게 조정되고 가장 안정적인 성능을 위해 최적화됩니다.
무선 채널이 사용되는 방법은 아래에서 Bluetooth LE 논리적 전송 및 관련 물리적 채널에 대해 설명할 때 자세히 설명합니다.
7.5 필터 정책
링크 Layer 은 다양한 기준을 사용하여 수신된 패킷을 필터링하는 기능이 있어 LE 스택의 상위 계층이 처리할 관련 없는 PDU로 인해 방해를 받지 않도록 합니다. 패킷을 필터링하여 폐기할지 또는 추가 처리를 위해 패킷을 선택할지 결정할 때 적용할 기준은 여러 링크 Layer 필터 정책에 의해 정의되고 구현됩니다. 링크 Layer 광고, 스캔, 시작 및 주기적 동기화 설정 상태 각각에 대해 별도의 필터 정책이 있습니다.
필터 정책은 다양한 링크 Layer 상태에 대해 숫자가 정의된 모드에서 작동합니다. 모든 경우의 기본 모드는 패킷 필터링이 수행되지 않습니다. 다른 모드에서는 필터 허용 목록이라는 디바이스 주소 목록을 사용하는 경우가 많습니다. 이러한 경우, 다양한 모드에 적용되는 조건에 다른 세부 사항이 있으며 자세한 내용은 Bluetooth 핵심 specification을 참조해야 하지만 필터 허용 목록의 회원, 회원사 주소인 장치의 패킷은 필터링되지 않을 수 있습니다. 그러나 이것은 대부분의 경우에 적용되는 기본 원칙입니다.
애플리케이션은 필터 허용 목록을 채우고 HCI 명령을 사용하여 다양한 링크 Layer 상태에 대한 필터 정책 모드를 구성할 수 있습니다.
결정 스캐닝 필터 정책 모드 라고 하는 특수 필터 정책 모드 세트가 정의되어 있으며, 이를 결정 기반 광고 필터링 (DBAF) 이라고 합니다. DBAF는 단순히 다음을 확인하는 것보다 더 정교한 필터링 조건을 허용합니다. 멤버십 필터 수락 목록을 공식화해야 합니다.
DBAF 모드는 스캐닝 필터 정책에만 적용되며 기본 채널에서 수신되는 특정 유형의 광고 PDU에만 적용됩니다. 결정 검색 필터 모드로 인해 발생할 수 있는 필터링은 확장 광고 패킷에만 적용되며, 이에 대한 자세한 내용은 7.7.2.3.7 결정 기반 광고 필터링 섹션에서 확인할 수 있습니다.
7.6 광고 송출 장치 모니터링
7.6.1 필터링 및 장치 감지
광고는 연결되지 않은 통신 수단으로 사용될 수 있지만, 가장 일반적인 용도는 디바이스 검색을 활성화하는 것입니다.
디바이스 검색에는 광고 패킷 검색이 포함됩니다. 광고 패킷을 수신하면 광고 디바이스가 존재한다는 표시로 사용되며, 광고 PDU의 유형에 따라 디바이스에 연결할 수 있음을 나타낼 수도 있습니다.
광고 패킷은 LE controller 처리하며, 자세한 내용은 링크 Layer specification에 정의되어 있습니다. 스택의 Host Layer은 Host Controller 인터페이스를 통해 전송된 이벤트를 사용하여 광고 패킷의 도착과 그 콘텐츠를 알 수 있습니다.
디바이스는 20밀리초에 한 번에서 10.24초에 한 번까지 광고할 수 있으며, 수신된 모든 패킷이 HCI 이벤트를 생성하고 모든 이벤트가 애플리케이션 함수에 대한 호출로 이어질 수 있기 때문에 광고는 물리적 HCI 전송, Bluetooth LE Host 및 애플리케이션 많은 부하를 줄 수 있습니다. 다행히도 이를 방지할 수 있는 방법이 있습니다.
디바이스 검색만을 목적으로 광고가 수행되는 경우 일반적으로 패킷의 내용은 변경되지 않습니다. 수신 중인 광고 패킷과 관련된 호출을 수신하려는 애플리케이션 여러 HCI 명령 중 하나를 사용하여 컨트롤러에 적절히 지시합니다. 이러한 HCI 명령을 통해 애플리케이션 적절한 이름의 HCI 명령 매개변수 Filter_Duplicates를 설정하여 중복 수신을 원하는지 여부를 표시할 수 있습니다. 중복 필터링을 지정하면 광고 디바이스당 한 번만 HCI 이벤트 및 애플리케이션 대한 관련 호출이 발생합니다.
하지만 중복 필터링에는 잠재적인 단점이 있습니다. 중복을 필터링하지 않으면 일반적으로 애플리케이션 관심 디바이스가 여전히 범위 내에 있는지 여부를 알 수 있습니다. 애플리케이션 해당 디바이스에 대한 광고 데이터 수신을 중단하면 해당 디바이스가 더 이상 범위 내에 있지 않다고 간주할 수 있습니다. 하지만 중복 필터링이 활성화되면 HCI 광고 이벤트가 없다고 해서 더 이상 디바이스가 범위를 벗어났다고 판단할 수 없습니다. 중복 패킷을 브로드캐스팅하고 있으며 이러한 패킷이 필터링되고 있을 가능성이 높기 때문입니다.
디바이스의 존재를 인식하지 못하는 문제는 연결을 설정할 때 특히 문제가 됩니다. 범위 내의 디바이스를 검색하여 사용자에게 선택할 수 있는 목록을 GUI에 표시하는 애플리케이션 상상해 보세요. 사용자가 선택하면 애플리케이션 선택한 디바이스와의 연결을 요청합니다. 연결이 필요한 경우 LE 컨트롤러는 먼저 높은 듀티 사이클 스캔을 수행해야 합니다. 이는 동일한 채널에서 연결 요청으로 응답하기 전에 대상 디바이스로부터 광고 패킷을 수신할 수 있도록 하기 위함입니다. 높은 듀티 사이클은 공격적인 형태의 스캔으로 광고 패킷을 빠르게 수신할 수 있지만 사용되는 에너지 측면에서 비용이 많이 듭니다. 연결할 디바이스가 아직 범위 내에 있는 경우에는 괜찮지만, 사용자가 선택하는 데 걸린 시간 동안 디바이스가 범위를 벗어났다면 상대적으로 비용이 많이 드는 이 스캔 작업은 에너지 낭비입니다.
예를 들어, 신호 강도가 낮으면 디바이스가 애플리케이션사용 사례에 적합할 만큼 충분히 가까이 있지 않다는 표시일 수 있으므로 디바이스에 애플리케이션 연결 중 가치가 없는 경우가 있습니다. 따라서 기술적으로는 디바이스가 여전히 존재할 수 있지만 신호 강도가 낮으면 디바이스에 연결하기 위해 스캔하는 것은 실제로 범위를 벗어난 것과 마찬가지로 에너지 낭비일 수 있습니다.
광고 송신기 모니터링 기능 사용하면 중복 광고 패킷을 필터링할 수 있지만, 디바이스가 여전히 존재하는지 여부와 디바이스에 연결 중 수 있을 만큼 신호 강도가 충분한지 여부를 추적하는 기능은 잃지 않습니다.
7.6.2 광고 모니터링 사용
LE 컨트롤러는 모니터링되는 광고주 목록이라는 목록을 유지 관리합니다. 애플리케이션은 HCI 명령을 사용하여 낮은 RSSI(신호 강도) 임계값, 높은 RSSI 임계값 및 시간 초과 값과 함께 관심 디바이스를 목록에 추가할 수 있습니다. 애플리케이션 다른 명령을 사용하여 광고주 모니터링을 활성화 또는 비활성화할 수도 있습니다.
표 3은 지정된 디바이스에 대해 광고주 모니터링이 작동하는 방식을 결정하는 매개변수에 대해 설명합니다.
| 매개변수 | 묘사 |
|---|---|
| 주소 및 주소 유형 | 모니터링할 디바이스의 주소 및 주소 유형입니다. 이 두 매개 변수를 통해 controller는 장치를 식별하고 모니터링할 수 있습니다. |
| RSSI 임계값 낮음 | 모니터링되는 디바이스의 모든 광고 패킷의 RSSI가 Time Out 매개변수 지정된 기간 동안 이 값 이하로 유지되면 신호 손실이 발생한 것으로 간주합니다. 이런 일이 발생하면 컨트롤러는 HCI LE 모니터 광고주 보고서 이벤트를 사용하여 host 알립니다. 이 장치의 상태 Awaiting RSSI High로 설정됩니다. |
| RSSI 임계값 높음 | 이 모니터링되는 디바이스에서 수신한 광고 패킷의 RSSI가 이 값보다 크거나 같고 디바이스 상태 RSSI 높음 대기 중이면 컨트롤러는 host HCI LE 모니터 광고주 보고서 이벤트를 전송하여 디바이스가 범위 내에 있음을 알립니다. 이 디바이스의 상태 지워지거나 더 이상 높은 임계값 이상의 RSSI를 기다리고 있지 않음을 나타내도록 설정되며 신호 손실을 모니터링하는 데 사용되는 타이머가 재설정됩니다. |
| 시간 초과 | 신호 손실을 모니터링하는 데 사용되는 시간(초)입니다. 이 기간 동안 RSSI 측정값이 RSSI 임계값 낮음 매개변수 초과하지 않으면 신호 손실이 발생한 것으로 간주합니다. |
표 3 - 모니터링되는 광고주 매개변수
광고 송신기 모니터링 기능 컨트롤러의 중복 광고 필터링 지시 여부와 관계없이 사용할 수 있지만, 중복 필터링을 활성화한 상태에서 사용할 때 가장 큰 이점이 있습니다.
그림 10은 광고 송신기 모니터링 기능 관련된 시나리오의 예시를 보여줍니다. 그림의 왼쪽은 광고 패킷 수신, 광고 모니터링을 구성하는 데 사용되는 HCI 명령, 구성된 RSSI 임계값에 따라 광고 디바이스가 범위 안팎으로 이동하는 데 사용되는 HCI 이벤트를 보여주는 시퀀스 다이어그램입니다. 오른쪽에는 디바이스 신호 강도의 변화와 그에 따른 상태 변화 및 HCI 이벤트가 표시됩니다.
그림 10 - 광고 송신기 모니터링 예시
표 4는 그림 10에서 레이블이 지정된 관심 지점을 설명합니다.
| 포인트 | 설명 |
|---|---|
| A | 스캐너의 host 컨트롤러에 모니터링할 수 있는 광고 디바이스 수를 묻는 것으로 시작합니다. 그런 다음 host RSSI 낮음, RSSI 높음 및 타임아웃 값(표시되지 않음)과 함께 디바이스를 목록에 추가합니다. 마지막으로 host 컨트롤러에 광고주 모니터링을 활성화하도록 지시합니다. |
| B | 이 시점에서 그림은 첫 번째 디바이스에서 전송한 광고 패킷을 표시하기 시작합니다. 이 시점 이전에도 디바이스가 광고 중이었을 수 있지만 패킷은 이 시점부터만 표시된다는 점에 유의하세요. 수신된 패킷의 RSSI가 구성된 낮은 임계값보다 크므로 각 패킷이 수신될 때마다 모니터링되는 디바이스의 타이머가 재설정됩니다. |
| C | C 지점 이후에 수신되는 다음 몇 개의 패킷은 RSSI가 낮은 RSSI 임계값보다 낮으므로 타이머가 마지막으로 리셋되는 지점이 C 지점이며, 이 지점부터 타이머가 실행됩니다. |
| D | 이제 일련의 낮은 RSSI 패킷이 수신되고 D 지점에서 타임아웃이 발생합니다. 컨트롤러는 조건 == 0x00으로 LE 모니터 광고주 보고서 이벤트를 전송하여 host 신호 손실 상태를 알립니다. 이제 디바이스는 광고 송신기 모니터링 목록에서 높은 RSSI 대기 중 상태 됩니다. |
| E | 지점 E에서 RSSI가 낮은 임계값을 초과하는 일련의 패킷 중 첫 번째 패킷이 수신됩니다. 이러한 패킷이 수신될 때마다 타이머가 재설정됩니다. |
| F | 지점 F에서 RSSI 값이 RSSI 높음 임계값을 초과합니다. host 컨트롤러가 전송한 조건 == 0x01의 LE 모니터 광고주 보고서 이벤트를 통해 모니터링되는 디바이스가 충분히 강한 신호로 범위 내에 돌아왔다는 알림을 받습니다. 디바이스는 더 이상 높은 RSSI 대기 중 상태 아닙니다. |
표 4 - 광고 송신기 모니터링 사례의 관심 포인트
7.7 데이터 전송 아키텍쳐
블루투스 코어 사양 아키텍처 섹션에는 블루투스 데이터 전송 아키텍처를 총체적으로 구성하는 여러 개념이 정의되어 있습니다. 이러한 개념 중 핵심은 물리적 채널, 물리적 링크, 논리적 링크 및 논리적 전송입니다. 특정 조합은 토폴로지, 타이밍, 신뢰성 및 채널 사용과 같은 문제와 관련된 특정 요구 사항이 있는 다양한 애플리케이션 유형을 지원하기 위해 정의됩니다.
물리적 채널은 블루투스를 사용하여 통신하는 여러 가지 방법 중 하나를 정의합니다. 예를 들어, 37개 채널에 걸쳐 적응형 주파수 호핑을 사용하는 LE Piconet 물리적 채널을 사용하여 연결된 두 장치 간에 통신이 이루어질 수 있습니다. 또는 LE 광고 물리적 채널을 사용하여 한 장치에서 무제한의 다른 장치로 연결되지 않은 브로드캐스트 통신을 할 수 있습니다. LE 주기적 물리 채널도 데이터를 브로드캐스트하는 데 사용할 수 있지만, 정해진 시간 스케줄에 따라 정기적으로 사용할 수 있습니다. 옵저버수신기) 장치는 해당 시간 일정을 결정하고 이를 사용하여 스캔 일정을 동기화할 수 있습니다.
물리적 링크는 단일 물리적 채널을 기반으로 하며 전원 제어의 사용 여부 등 해당 링크의 특정 특성을 지정합니다.
논리적 링크 및 전송에는 특정 물리적 채널 유형을 사용하여 물리적 링크를 통해 특정 데이터 통신 요구 사항 집합을 지원하는 데 적합한 수단을 제공하도록 설계된 다양한 매개변수가 있습니다.
예를 들어, Bluetooth LE 안정적인 양방향 지점 간 통신은 제어 데이터용 LE-C 링크 또는 사용자 데이터용 LE-U 링크가 포함된 LE 비동기 연결 지향 논리(ACL) 전송을 LE Piconet 물리 채널을 기반으로 하는 물리적 링크를 통해 사용합니다.
반면, Bluetooth LE 신뢰할 수 없는 단방향 브로드캐스트 통신은 LE 광고 물리 채널 기반의 물리적 링크를 통해 제어 데이터용 ADVB-C 링크 또는 사용자 데이터용 ADVB-U 링크가 포함된 LE 광고 브로드캐스트(ADVB) 논리적 전송을 사용합니다.
7.8 논리 전송
7.8.1 LE ACL - LE 비동기 연결 지향 논리 전송
두 개의 Bluetooth LE 장치가 연결되면 비동기 연결 지향 논리 전송(LE-ACL 또는 간단히 ACL)을 사용하게 됩니다. LE-ACL은 가장 일반적으로 사용되는 Bluetooth LE 논리 전송 유형 중 하나로, 연결 지향적 데이터 통신을 제공합니다. 실제로 ACL 연결은 일반적으로 간단히 연결이라고 합니다.
디바이스는 연결을 요청하는 PDU로 수신된 광고 패킷에 응답하여 광고 디바이스와의 연결을 설정할 수 있습니다. 요청에는 여러 매개변수가 지정됩니다. 이러한 매개 변수에는 액세스 주소 연결 간격, 주변 대기 시간, 감독 시간 초과 및 채널 맵이 포함됩니다.
연결을 요청하는 장치는 대기 상태 시작 상태 전환된 후 연결 상태 들어가 중앙 역할을 맡습니다. 다른 장치는 광고에서 연결로 전환되고 주변 장치 역할을 맡습니다.
연결 간격 매개변수 이 연결을 서비스하기 위해 무전기를 사용할 수 있는 주기를 밀리초 단위로 정의합니다. 연결 간격이 만료될 때마다 연결 이벤트가 시작되며 이 시점에서 연결에 있는 중앙 장치가 패킷을 전송할 수 있습니다. 특정 연결에 대한 연결 이벤트에는 각각 카운터 값인 16비트 식별자가 있으며, 각 이벤트마다 증가합니다. 각 연결 이벤트가 시작될 때 사용할 무선 채널은 해당 채널 선택 알고리즘을 사용하여 선택됩니다.
감시 시간 초과 매개변수는 링크가 끊긴 것으로 간주되기 전에 두 개의 링크 Layer 데이터 패킷이 수신될 때까지 경과할 수 있는 최대 시간을 지정합니다.
중앙 장치와 동일한 합의된 연결 매개변수를 보유한 주변 장치는 중앙 장치에서 패킷을 전송할 시기와 채널을 알고 있으므로 정확히 같은 시간에 해당 채널에서 수신하도록 선택하여 중앙 장치로부터 패킷을 수신할 수 있습니다. 중앙 장치의 패킷 마지막 비트를 수신한 후 주변 장치는 짧은 시간(기본값 150마이크로초) 동안 대기한 다음 중앙 장치에 응답할 수 있습니다. 패킷 전송 사이의 시간을 프레임 간 공간 시간(IFS)이라고 합니다.
그런 다음 중앙과 주변 장치가 번갈아 가며 패킷을 전송하고 수신하며 연결 이벤트 중에 구현에서 정의한 수의 패킷을 교환할 수 있습니다. 주변장치의 동작은 0이 아닌 주변장치 지연 시간 매개변수 값에 의해 수정될 수 있습니다.
그림 11은 중앙 장치의 패킷 전송을 나타내는 C>P와 주변 장치의 패킷 전송을 나타내는 P>C로 두 개의 연결 이벤트 동안 패킷이 교환되는 기본적인 모습을 보여줍니다.
그림 11 - LE-ACL 연결을 통한 기본 패킷 교환
LE ACL 연결을 통해 교환되는 패킷에는 링크 Layer 제어 절차와 관련된 LL 데이터 PDU 또는 LL 제어 PDU가 포함되어 있습니다.
LE-ACL은 데이터가 올바른 순서로 처리되고 패킷의 수신을 확인할 수 있으며, 이를 통해 다음 패킷으로 넘어갈지 아니면 이전 패킷을 재전송할지 결정할 수 있도록 하는 시스템을 통합합니다.
데이터 패킷에는 통신의 안정성에 기여하는 세 가지 중요한 필드가 포함되어 있습니다. 이러한 필드를 SN( 순차 번호 ), NESN(다음 예상 순차 번호 ), 추가 데이터 필드라고 합니다. 이 세 가지 필드는 모두 단일 비트 필드이며, 이를 사용하여 수신된 패킷의 올바른 순서를 확인하는 승인 시스템과 방법을 제공합니다.
통신은 중앙 장치(장치 A)가 SN과 NESN을 모두 0으로 설정한 링크 Layer 데이터 패킷을 전송하는 것으로 시작됩니다. 이 시점부터 패킷이 교환될 때마다 모든 것이 정상이라면 장치 A가 설정한 SN 필드의 값은 0과 1 사이를 번갈아 가며 나타납니다. 따라서 주변 장치(장치 B)는 항상 다음에 수신할 패킷의 SN 값이 무엇인지 알고 이를 확인합니다.
장치 B가 장치 A로부터 예상 SN 값이 포함된 패킷을 수신하면, NESN이 논리 값 NOT(SN)으로 설정된 링크 Layer 데이터 패킷으로 응답합니다. 예를 들어 수신된 SN 값이 1이면 응답의 NESN은 0이 됩니다.
장치 A가 다음 패킷에서 SN에 사용하려는 값으로 설정된 NESN이 포함된 응답을 장치 B로부터 수신하면 장치 A는 이를 장치 B의 승인으로 간주하여 마지막으로 전송된 패킷을 올바르게 수신했음을 확인합니다. 그림 12는 이를 보여줍니다.
그림 12 - 링크 Layer에서 패킷을 성공적으로 교환한 모습
장치 B는 잘못된 SN 값을 가진 패킷을 수신하면 이전에 수신한 패킷의 재전송으로 간주하고 이를 승인하지만 추가 처리를 위해 스택 위로 전달하지 않습니다.
장치 A가 장치 B로부터 예상치 못한 NESN 값을 응답으로 받거나 응답을 전혀 받지 못한 경우, 장치 A는 원래 사용한 것과 동일한 SN 값으로 패킷을 재전송합니다. 통신이 실패한 것으로 결론 내리기 전에 재전송할 횟수와 관련하여 컨트롤러 구현마다 다양한 알고리즘을 자유롭게 구현할 수 있습니다. 그림 13을 참조하세요.
그림 13 - 링크 Layer 재전송
각 패킷에는 CRC 필드가 포함되며, 암호화된 패킷에는 MIC 필드도 포함됩니다. 패킷을 수신하면 링크 Layer CRC를 확인하고, 존재하는 경우 MIC를 확인합니다. 두 검사 중 하나라도 실패하면 패킷은 승인되지 않으며, 일반적으로 패킷의 발신자가 패킷을 다시 전송합니다. 그림 14를 참조하세요.
그림 14 - CRC 장애를 처리하는 링크 Layer
주변장치는 모든 연결 이벤트 동안 중앙 장치의 패킷을 수신 대기할 필요가 없습니다. 주변 장치 대기 시간 매개변수 주변 장치가 수신 대기할 필요가 없는 연속 연결 이벤트의 수를 정의합니다. 이를 통해 주변 장치의 전력을 절약할 수 있습니다.
그림 15는 주변장치 지연 시간이 1이고, 따라서 대체 연결 이벤트 중에만 수신하는 주변장치의 동작을 보여줍니다. 주변 장치가 수신 대기 중이 아닌 이벤트 중에 Central이 전송할 수 있지만 이러한 패킷은 수신되지 않으므로 승인되지 않고 연결 이벤트가 종료됩니다.
그림 15 - 주변 장치 지연 시간이 1인 ACL 연결
LE-ACL은 적응형 주파수 호핑이라는 방식을 사용합니다. 각 연결 이벤트가 시작될 때 채널 선택 알고리즘을 사용하여 사용 가능한 채널 세트에서 무선 채널이 결정적으로 선택되는 주파수 호핑이 발생합니다. 그런 다음 연결에 포함된 각 디바이스는 선택한 채널로 전환되며, 시간이 지나고 일련의 연결 이벤트가 발생하면 2.4GHz 대역에 분산되어 자주 변경되는 일련의 다른 채널을 사용하여 통신이 이루어지므로 충돌이 발생할 확률이 크게 줄어듭니다.
Bluetooth LE 사용하도록 정의된 40개 채널 중 37개 채널( 범용 채널이라고 함)은 LE-ACL 연결에서 사용할 수 있습니다.
특정 환경에서 일부 Bluetooth 무선 채널은 간섭의 영향으로 인해 제대로 작동하지 않을 수 있지만 다른 채널은 안정적으로 작동할 수 있습니다. 시간이 지남에 따라 환경의 다른 무선 통신 장치가 왔다 갔다 하기 때문에 신뢰할 수 있는 채널과 신뢰할 수 없는 채널 목록이 변경될 수 있습니다.
연결의 중앙 장치는 범용 채널을 사용 중 또는 미사용으로 분류하는 채널 맵을 유지 관리합니다. 이 채널 맵은 링크 Layer 절차를 사용하여 주변 장치와 공유되므로 주변 장치는 각각 사용할 채널과 사용하지 않을 채널에 대한 동일한 정보를 갖게 됩니다. 채널 선택 알고리즘을 통해 미사용으로 지정된 채널은 피할 수 있습니다.
기본적으로 모든 범용 채널은 사용 중으로 지정되어 있지만, Central 장치는 구현별 기술을 사용하여 각 채널이 얼마나 잘 작동하는지 모니터링할 수 있습니다. Central 디바이스는 하나 이상의 채널이 제대로 작동하지 않는다고 판단되면 채널 맵에서 해당 채널의 분류를 미사용으로 업데이트할 수 있습니다. 반대로, 이전에 잘 작동하지 않던 채널이 지금은 잘 작동하는 것으로 확인되면 채널 맵에서 해당 채널의 분류를 사용 중으로 업데이트할 수 있습니다. 그러면 채널 맵 업데이트가 주변 장치와 공유될 수 있습니다.
또한 주변장치는 자체 채널 모니터링을 수행하고 간격을 두고 채널 상태 보고서를 중앙 장치로 전송할 수 있으며, 각 채널의 상태는 양호, 불량 또는 알 수 없음으로 분류됩니다. 그러면 Central은 자체 무선 상태와 원격 주변 장치에서 경험하는 상태를 모두 고려하여 채널 맵에서 채널 분류에 대한 결정을 내릴 수 있습니다.
이러한 방식으로 Bluetooth LE 장치는 사용 가능한 채널의 최적 서브셋 사용할 수 있으므로 예를 들어 정적으로 할당된 채널을 사용하는 다른 무선 기술과 효과적으로 공존할 수 있습니다. 이것이 바로 Bluetooth 적응형 주파수 호핑 시스템의 적응형 측면입니다.
| 참고: 규제 기관은 적응형 주파수 호핑 및 관련 용어를 블루투스 코어 사양 다르게 정의할 수 있습니다. 목표 시장의 스펙트럼 사용에 관한 규정은 특정 구현 결정에 영향을 미칠 수 있으므로 제품 개발 수명 주기 초기에 검토하는 것이 좋습니다. 섹션 18을 참조하세요 . 추가 리소스에서 규제 문제에 대한 지침을 제공하는 Bluetooth SIG규제 측면 문서에 대한 링크를 참조하세요. |
그림 16은 테스트 중 연결된 두 디바이스에서 채널을 사용한 방식을 보여주며, ISM 2.4GHz 스펙트럼에서 무선 사용이 분산되는 방식을 보여줍니다. 차트 하단에서 채널 인덱스와 주파수를 MHz 단위로 확인할 수 있습니다. 채널 인덱스는 무선 채널을 간접적으로 참조하는 방법입니다.
그림 16 - 적응형 주파수 호핑을 통한 채널 간 통신 분산
링크 Layer 사양에는 여러 제어 절차가 명시되어 있습니다. 표 5에 몇 가지 예가 나와 있습니다.
| 제어 절차 | 묘사 |
|---|---|
| 연결 업데이트 | 중앙 또는 주변 장치에서 연결 매개변수 연결 간격, 주변 장치 대기 시간 및 감독 시간 초과에 대한 변경을 요청할 수 있습니다. |
| 채널 맵 업데이트 | 중앙 장치가 연결된 주변 장치로 최신 채널 맵 데이터를 전송할 수 있습니다. |
| 암호화 | 중앙 또는 주변 장치에서 패킷 암호화를 활성화할 수 있습니다. |
| 기능 교환 | 중앙 또는 주변 장치가 비트맵 필드로 인코딩된 각 장치가 지원하는 링크 Layer 기능의 교환을 시작할 수 있습니다. |
| 주기적 광고 동기화 전송 | 중앙 또는 주변 장치에서 발견된 주기적 광고 주기적 광고 트레인과 관련된 주기적 광고 주기적 광고[7] 동기화 정보를 LE ACL 연결을 통해 다른 장치로 전송할 수 있습니다. |
| CIS 생성 절차 | 중앙 장치가 주변 장치와 연결된 비동기 스트림(CIS)[8] 을 생성할 수 있도록 허용합니다. |
| 전원 제어 요청 | 한 피어가 다른 피어에게 송신 전력 레벨을 조정하도록 요청할 수 있습니다. |
| 채널 분류 보고 | 주변 장치가 연결된 Central에 채널 분류 데이터를 보고할 수 있습니다. |
표 5 - 링크 Layer 제어 절차 예시
하위 등급 연결은 추가 속성이 할당되어 있고 몇 가지 방식으로 다르게 동작하는 LE ACL 연결입니다. 추가 속성을 서브레이트 계수, 서브레이트 기본 이벤트 및 연속 번호라고 합니다.
하위 등급 연결 속성은 연결된 디바이스에서 특정 연결 이벤트의 서브셋 활발하게 사용하고 다른 연결 이벤트에서는 무전기를 사용하지 않도록 하는 메커니즘을 제공합니다. 따라서 하위 등급 연결은 ACL 연결 간격이 짧지만 여전히 낮은 듀티 사이클을 나타낼 수 있습니다.
그림 17은 하위 등급 연결과 관련된 기본 개념을 보여줍니다.
그림 17 - 서브레이트 계수=5의 기본 서브레이트 연결
여기서 5개의 연결 이벤트 중 하나만 사용되는 것을 볼 수 있습니다. 나머지 4개는 건너뛰기 때문에 해당 연결 이벤트 동안에는 무선 활동이 없습니다. 이 사용된 연결 이벤트와 건너뛴 연결 이벤트의 비율은 하위율 매개변수 의해 결정되며 이 예에서는 5로 설정되어 있습니다.
라디오가 링크 Layer 패킷을 송수신하는 데 사용되는 연결 이벤트를 하위 연결 이벤트라고 합니다.
기본 ACL 연결 매개 변수와 연결 하위 등급을 관리하는 매개 변수 간의 관계를 고려할 때, 하위 등급 연결은 ACL 연결 이벤트가 발생하는 빈도를 제어하는 연결 간격과 하위 등급 매개 변수가 적용된 후 해당 ACL 연결 이벤트가 실제로 사용되는 빈도를 결정하는 유효 연결 간격을 모두 갖는 것으로 생각할 수 있습니다.
하위 등급 연결은 다른 링크 Layer 제어 절차를 사용하며, 특히 하위 등급 연결 매개변수를 업데이트하는 절차는 일반적인 제어 업데이트 절차와 다르게 작동합니다. 중요한 점은 일반적인 매개변수 변경이 적용되는 데 상당한 시간이 걸리는 반면, 하위 등급 연결 매개변수 변경은 거의 즉각적으로 적용될 수 있다는 점입니다. 따라서 낮은 듀티 사이클을 나타내며 전력을 거의 소비하지 않는 영구 연결을 설정할 수 있고 사용자가 알아차릴 수 있는 지연 없이 높은 듀티 사이클, 높은 대역폭 연결로 전환할 수 있다는 장점이 있습니다. 이 기능은 보청기 및 스마트폰과 관련된 일부 LE 오디오 시나리오에서 특히 유용합니다.
블루투스 코어 사양 버전 5.3 기능 향상 백서에는 하위 등급 연결에 관한 상당한 양의 장이 있으며, 자세한 정보를 얻을 수 있는 자료로 추천합니다.
7.8.2 ADVB - LE 광고 브로드캐스트
LE 광고 브로드캐스트(또는 간단히 광고)는 연결되지 않은 통신 모드를 제공합니다. 데이터를 전송하거나 연결할 주변 장치의 가용성을 표시하는 데 사용할 수 있습니다.
일반적으로 광고 패킷은 범위 내의 모든 스캔 디바이스가 수신하도록 되어 있으므로 일대다 토폴로지에서 광고를 사용하여 여러 스캔 디바이스로 동시에 데이터를 전송할 수 있습니다. 그러나 다이렉트 광고로 알려진 특수한 형태의 광고가 정의되어 있으며, 이를 통해 한 광고 디바이스에서 특정 스캔 디바이스로 데이터를 연결 없이 통신할 수 있으며, 이는 해당 블루투스 디바이스 주소 식별됩니다 주소
ADVB 논리적 전송에 적용되는 광고는 광고 장치에서 스캔 장치로 한 방향으로만 애플리케이션 데이터의 통신을 지원하지만 이러한 장치는 추가 정보를 요청하거나 연결이 형성되도록 PDU를 통해 광고 패킷에 응답할 수 있습니다. 스캐닝 디바이스가 추가 정보를 얻기 위해 응답하면 활성 스캐닝을 수행 중이라고 합니다. 그렇지 않은 경우 수동 스캔을 수행 중이라고 합니다.
광고는 일반적으로 수신자가 수신 확인을 보내지 않기 때문에 신뢰할 수 없는 전송이라고 합니다.
두 가지 범주의 광고 절차가 정의되어 있으며 블루투스 코어 사양 다음과 같이 언급되어 있습니다. 레거시 광고 과 확장 광고.
7.8.2.2.1 채널 사용 및 패킷 크기
ADV_IND PDU 유형(7.8.2.2.3 레거시 광고 및 관련 PDU 유형 참조)을 사용하는 레거시 광고 레거시 광고 패킷은 6옥텟 헤더와 최대 31옥텟의 페이로드가 포함된 37옥텟 길이입니다. 광고 패킷의 동일한 사본은 기본 광고 채널로 알려진 37, 38, 39번의 최대 3개 전용 채널에서 한 번에 한 채널씩 일정한 순서로 전송됩니다.
그림 18 - 레거시 광고 및 채널 사용량
7.8.2.2.2 스케줄링
광고 패킷의 전송은 광고 이벤트가 발생할 때마다 이루어집니다. 광고 이벤트의 스케줄링은 타이밍 매개변수에 의해 제어되며, 기본적으로는 다른 광고 디바이스와의 지속적인 충돌을 피하기 위해 의도적으로 약간 불규칙하게 설정됩니다. 각 광고 이벤트마다 0~10ms 범위의 의사 난수 값( advDelay )이 할당되고, 이 값이 정규 광고 간격(advInterval)에 더해져 광고 이벤트가 제때에 교란되도록 합니다. 그림 19는 블루투스 코어 사양 6권 파트 B의 그림 4.5를 재현한 것으로, advDelay 매개변수 효과를 보여줍니다.
그림 19 - advDelay를 사용하여 시간에 따라 교란된 광고 이벤트
이러한 방식으로 광고 이벤트를 예약하면 충돌을 피하는 데 도움이 되지만 수신자가 광고 패킷을 효율적으로 수신하기 어렵고, 예측할 수 없는 광고 이벤트의 타이밍을 수용하기 위해 더 높은 RX 듀티 사이클이 필요합니다.
7.8.2.2.3 레거시 광고 및 관련 PDU 유형
레거시 광고 사용하기 위해 여러 가지 PDU 유형이 정의되어 있습니다. 패킷이 모든 스캔 디바이스를 대상으로 하는 비지시 광고와 패킷이 하나의 특정 디바이스를 대상으로 하는 지시형 광고에는 서로 다른 유형의 PDU가 사용됩니다. PDU 유형은 또한 수신자가 추가 데이터 요청과 광고 디바이스에 연결할 수 있는지 여부로 응답하는 활성 스캔이 허용되는지 여부를 나타냅니다. 모든 레거시 광고 37, 38, 39번의 기본 채널 중 하나 이상에서 이루어지며 LE 1M PHY만 사용할 수 있습니다.
표 6에는 레거시 광고 PDU가 나열되어 있습니다.
| PDU 이름 | 묘사 | 채널 | PHY(들) | 전송자 | 스캔 가능 | 연결 가능 |
|---|---|---|---|---|---|---|
| ADV_IND | 언디렉티드 광고 | 기본 | LE 1M | 주변장치 | Y | Y |
| ADV_DIRECT_IND | 직접 광고 | 기본 | LE 1M | 주변장치 | N | Y |
| ADV_NON_CONN_IND | 비방향성, 비연결성, 비스캔성 광고 | 기본 | LE 1M | 주변장치 | N | N |
| ADV_SCAN_IND | 비디렉션, 스캔 가능한 광고 | 기본 | LE 1M | 주변장치 | Y | N |
| SCAN_REQ | 스캔 요청 | 기본 | LE 1M | 중앙 | N/A | N/A |
| SCAN_RSP | 스캔 응답 | 기본 | LE 1M | 주변장치 | N/A | N/A |
| CONNECT_IND | 연결 요청 | 기본 | LE 1M | 중앙 | N/A | N/A |
표 6 - 레거시 광고 PDU
Bluetooth Core specification의 링크 Layer specification 장 4.4절에서는 모든 광고 PDU 유형에 대해 자세히 설명합니다.
블루투스 코어 사양 버전 5는 광고 수행 방식에 몇 가지 주요 변경 사항을 도입했습니다. 광고, 스캔 및 연결 중 관련된 8개의 새로운 PDU가 추가되고 새로운 절차가 정의되었습니다. 이러한 새로운 광고 기능을 총칭하여 다음과 같이 부릅니다. 확장 광고.
확장 광고 사용하면 훨씬 더 많은 양의 데이터를 방송하고, 결정적인 일정에 따라 광고를 실행하며, 서로 다른 구성에 따라 관리되는 여러 개의 개별 광고 데이터 세트를 전송할 수 있습니다. 또한 경합 및 듀티 사이클과 관련하여 상당한 개선을 제공합니다.
확장 광고 ADVB와 PADVB 논리적 전송 모두에서 사용됩니다.
7.8.2.3.1 채널 사용 및 패킷 크기
라디오 채널은 레거시 광고 수행할 때 사용하는 방식과 다르게 사용되며, 주요 광고 채널 37, 38, 39는 데이터가 적고 범용 채널 0~36은 대부분의 데이터를 전달합니다.
7.8.2.2 레거시 광고 설명된 대로 레거시 광고 3개의 서로 다른 기본 광고 채널에서 동일한 페이로드를 최대 3회까지 전송합니다. 확장 광고 페이로드 데이터를 기본 채널에서 참조하는 작은 헤더를 사용하여 한 번만 전송합니다. 따라서 전송되는 총 데이터 양이 레거시 광고 사용하는 경우보다 적으므로 유효 듀티 사이클이 줄어듭니다.
그림 20 - 경합 및 듀티 사이클 감소
확장 광고 사용하면 패킷 길이를 최대 255옥텟까지 늘릴 수 있습니다. 이는 부분적으로 페이로드를 0-36 채널 번호 범위의 범용 채널 중 하나로 오프로딩하여 이루어집니다.
그림 21 - 확장 광고 더 큰 광고 패킷과 채널 오프로드를 지원합니다.
확장 광고 수행할 때는 37, 38, 39번의 기본 채널에서 헤더 데이터만 전송됩니다. 여기에는 AuxPtr이라는 필드가 포함됩니다.
AuxPtr 필드는 0~36번 채널 집합에서 범용 채널로 전송될 페이로드가 포함된 관련 보조 패킷을 참조합니다. 보조 패킷이 전송될 채널을 나타내는 범용 채널 인덱스는 수신자가 보조 패킷을 찾을 수 있는 위치를 알 수 있도록 합니다. 범용 채널에서 전송되고 기본 채널의 패킷에서 AuxPtr 필드에 의해 참조되는 패킷을 하위 패킷이라고 하고 참조 패킷을 상위 패킷이라고 합니다.
AuxPtr의 채널 인덱스 값 선택은 구현에 따라 다르며, Bluetooth 핵심 specification에서는 "충돌을 피하기 위해 충분한 채널 다양성을 사용할 것"만 권장하고 있습니다.
7.8.2.3.2 패킷 체이닝
애플리케이션 더 많은 데이터(최대 1,650바이트)를 브로드캐스트해야 하는 사용 사례의 경우, 컨트롤러가 데이터를 조각화하고 해당 데이터의 서브셋 포함하는 각 패킷과 함께 패킷을 체인화할 수 있습니다. 체인화된 각 패킷은 서로 다른 채널로 전송될 수 있으며, AuxPtr 헤더 필드는 체인에서 다음 패킷을 참조합니다. 그림 22가 이를 보여줍니다.
그림 22 - 패킷 체인을 사용한 확장 광고
7.8.2.3.3 광고 세트
레거시 광고 광고 페이로드와 매개변수를 변경할 수 있는 공식적인 규정을 두고 있지 않습니다. 확장 광고 여러 개의 개별적인 광고 데이터 세트를 보유할 수 있는 표준 메커니즘이 포함되어 있습니다.
광고 세트에는 주어진 패킷이 속한 세트를 나타내는 데 사용되는 ID가 있으며, 각 세트에는 광고 간격 및 사용할 PDU 유형과 같은 자체 광고 매개변수가 있습니다.
다양한 광고 세트를 예약하고 전송하는 작업은 Host 직접 수행하지 않고 컨트롤러의 링크 Layer 맡기면 전력 효율이 훨씬 떨어집니다. Host 처음에 광고 세트와 각 파라미터를 컨트롤러에 알리기만 하면 되고, 그 이후에는 링크 Layer 이를 이어받습니다.
7.8.2.3.4 주기적 광고
확장 광고 결정론적 스케줄링을 사용하는 광고 방법이 포함되며, 세부 사항은 스캔 디바이스에서 검색 및 동기화될 수 있습니다. 이를 주기적 광고. 주기적 광고 별개의 논리적 전송으로 정의되며 7.8.3 PADVB - LE 주기적 광고 브로드캐스트 섹션에 설명되어 있습니다.
7.8.2.3.5 확장 광고 및 관련 PDU 유형
확장 광고 사용할 수 있도록 여러 가지 PDU 유형이 정의되어 있습니다. 표 7에는 확장 광고 PDU가 나열되어 있습니다.
| PDU 이름 | 묘사 | 채널 | PHY(들) | 전송자 |
|---|---|---|---|---|
| ADV_EXT_IND | 확장 광고 | 기본 | 르 1m, LE 코디드 | 주변장치 |
| ADV_DECISION_IND | 의사 결정 PDU | 기본 | 르 1m, LE 코디드 | 주변장치 |
| AUX_ADV_IND | 하위 확장 광고 | 범용 | 르 1m, LE 2M, LE 코디드 | 주변장치 |
| AUX_CHAIN_IND | 추가 광고 데이터 | 범용 | 르 1m, LE 2M, LE 코디드 | 주변장치 |
| AUX_SYNC_IND | 주기적 광고 동기화 | 주기적 | 르 1m, LE 2M, LE 코디드 | 주변장치 |
| AUX_SCAN_REQ | 보조 스캔 요청 | 범용 | 르 1m, LE 2M, LE 코디드 | 중앙 |
| AUX_SCAN_RSP | 보조 스캔 응답 | 범용 | 르 1m, LE 2M, LE 코디드 | 주변장치 |
| AUX_CONNECT_REQ | 보조 연결 요청 | 범용 | 르 1m, LE 2M, LE 코디드 | 중앙 |
| AUX_CONNECT_RSP | 보조 연결 응답 | 범용 | 르 1m, LE 2M, LE 코디드 | 주변장치 |
표 7 - 확장 광고 PDU
ADV_EXT_IND, AUX_ADV_IND, AUX_SCAN_RSP, AUX_SYNC_IND, AUX_CHAIN_IND 및 AUX_CONNECT_RSP 유형의 PDU 페이로드는 공통 확장 광고 페이로드 형식으로 알려진 동일한 포맷으로 정의됩니다. 여기에는 AuxPtr 필드 및 AdvMode와 같은 필드가 포함됩니다. AdvMode는 2비트를 사용하여 광고 모드의 연결 가능 및 스캔 가능 속성을 나타내는데, 이는 별도의 PDU 유형이 아닌 광고 모드의 속성을 나타냅니다.
Bluetooth Core specification의 링크 Layer specification 장 4.4절에서는 모든 광고 PDU 유형에 대해 자세히 설명합니다.
7.8.2.3.6 예약하기
확장 광고 확장 광고 이벤트에서 발생합니다. 확장 광고 이벤트는 광고 이벤트와 동시에 시작되며 AuxPtr 필드가 있는 상위 패킷과 이와 관련된 하위 패킷을 포함합니다.
7.8.2.3.7 결정 기반 광고 필터링
방해 요소
ADV_EXT_IND PDU가 수신되면 스캐너는 항상 AuxPtr 필드를 따라가서 연결된 하위 PDU(예: AUX_ADV_IND PDU)를 스캔합니다. 일부 애플리케이션의 경우 이는 기본 채널의 수신기 성능에 부정적인 영향을 미치는 비효율적인 동작일 수 있습니다.
다음 시나리오를 생각해 보세요:
- 스캐너가 ADV_EXT_PDU를 수신합니다.
- 스캐너는 보조 채널 필드에 있는 정보를 사용하여 지정된 보조 채널에서 스캔하도록 전환합니다.
- 스캐너가 예상대로 AUX_ADV_IND PDU를 수신합니다.
- 애플리케이션 Layer은 확장된 광고 PDU를 수신하지만, 현재 애플리케이션 데이터와 관련성이 없거나 관심이 없다는 것을 확인하기 위해 AdvData 페이로드 필드만 확인합니다.
여기서 일어난 일을 방해 요소라고 합니다. 확장 광고 PDU의 페이로드가 애플리케이션 유용할지 여부를 미리 알 수 있는 방법이 없었기 때문에 이를 스캔한 다음 애플리케이션 전달하여 평가하지 않고는 알 수 없었습니다. 그리고 AuxPtr이 지정한 보조 채널에서 스캔이 진행되는 동안 기본 채널은 스캔되지 않았기 때문에 다른 ADV_EXT_IND PDU를 놓쳤을 가능성이 있습니다. 보시다시피, 이러한 상황과 일부 애플리케이션에서는 방해 요소가 문제가 될 수 있습니다.
DBAF는 산만함의 문제를 해결합니다.
DBAF와 광고 디바이스
DBAF가 사용 중일 때 광고 디바이스는 기본 채널에서 ADV_EXT_IND PDU 대신 ADV_DECISION_IND PDU를 전송합니다.
그림 23 - ADV_DECISION_IND
그림 24에서 의사 결정 데이터 필드가 확장되어 있습니다.
그림 24 - ADV_DECISION_IND 의사 결정 데이터 필드
확인 가능한 태그 필드에는 해당 애플리케이션 속한 PDU의 레이블로 사용되는 애플리케이션 할당 해시 값이 포함되어 있습니다 애플리케이션 이를 통해 스캐너가 AuxPtr을 따르고 관련 보조 PDU를 스캔해야 하는 경우를 간단하게 식별할 수 있습니다. 향후 프로파일에서는 확인 가능한 태그 해시 값을 생성하는 데 사용되는 키 값을 디바이스 간에 공유할 수 있는 방법을 정의할 예정입니다.
의사 결정을 내리는 데 필요한 기타 데이터는 임의 데이터 필드에 포함할 수 있습니다.
DBAF 및 스캔 장치
스캐닝 장치의 애플리케이션 컨트롤러가 관련 보조 PDU에 대한 보조 채널에서 스캔할지 여부를 결정하기 위해 ADV_DECISION_PDU에 대해 평가해야 하는 논리적 테스트를 공식화할 수 있습니다. 테스트는 ADV_DECISION_IND PDU의 결정 데이터 필드 또는 광고 모드 필드인 AdvMode와 같은 다른 필드에 적용될 수 있습니다. 또한 수신 신호 강도 표시기(RSSI)도 의사 결정 테스트에 포함될 수 있습니다.
테스트 요구 사항은 애플리케이션 호출하는 HCI 명령을 통해 컨트롤러에 전달됩니다. 테스트를 그룹화할 수 있으며, 그룹은 논리 AND 또는 논리 OR 연산을 포함하는 비교적 복잡한 복합 조건의 요소를 구성할 수 있습니다. 예를 들어
- (그룹 1 테스트 1) 및 (그룹 1 테스트 2) 및 (그룹 1 테스트 3)
- (그룹 1) 또는 (그룹 2) 또는 (그룹 3) 또는 (그룹 4)
애플리케이션 컨트롤러가 사용해야 하는 결정 검색 필터 정책 모드를 알려줍니다. 옵션은 다음과 같습니다:
- 의사 결정 없음 모드. 이 모드에서는 결정 PDU가 무시됩니다.
- 모든 PDU 모드. 모든 유형의 광고 PDU가 선택됩니다. 결정 PDU는 host 지정한 검사의 적용을 받습니다. 기타 광고 PDU는 기본 필터 정책의 적용을 받습니다.
- 의사 결정 전용 모드. 의사 결정 PDU만 선택됩니다. host 지정한 검사의 대상이 됩니다. 통과한 것은 HCI 광고 보고서에서 host 보고됩니다. 실패한 것은 폐기됩니다.
표 8은 레거시 광고 확장 광고 요약하여 비교한 것입니다.
| 레거시 광고 | 확장 광고 | ||
|---|---|---|---|
| 최대 host 광고 데이터 크기 | 31 바이트 | 1,650바이트 | 확장 광고 최대 50배 더 큰 host 광고 데이터 크기를 지원할 수 있는 조각화를 지원합니다. |
| 패킷당 최대 host 광고 데이터 | 31 바이트 | 254바이트 | 확장 광고 PDU는 8배 더 큰 광고 데이터 필드를 지원하는 공통 확장 광고 페이로드 형식을 사용합니다. |
| TX 채널 | 37,38,39 | 0-39 | 확장 광고 37개의 범용 채널을 보조 광고 채널로 사용합니다. 그러나 ADV_EXT_IND PDU 유형은 기본 광고 채널(37, 38, 39)에서만 전송할 수 있습니다. |
| PHY 지원 | LE 1M | LE 1MLE 2M(ADV_EXT_IND PDU 제외LE 코디드 | ADV_EXT_IND를 제외한 모든 확장 광고 PDU는 LE 1M 또는 LE 코디드 PHY를 사용하여 전송할 수 있는 ADV_EXT_IND PDU를 제외한 세 가지 LE PHY 중 하나를 사용하여 전송할 수 있습니다. |
| 최대 활성 광고 구성 | 1 | 16 | 확장 광고 광고 디바이스가 한 번에 최대 16개의 서로 다른 광고 구성을 지원하고 세트에 정의된 시간 간격에 따라 각 광고 세트에 대한 광고를 인터리빙할 수 있는 광고 세트가 포함되어 있습니다. |
| 커뮤니케이션 유형 | 비동기식 | 비동기 동기 | 확장 광고 다음이 포함됩니다. 주기적 광고를 통해 송신자와 수신자 간에 광고 데이터를 시간 동기화하여 통신할 수 있습니다. |
표 8 - 레거시 확장 광고 비교
7.8.3 PADVB - LE 정기 광고 방송주기적 광고 브로드캐스트
ADVB 논리적 전송(7.8.2 ADVB - LE 광고 브로드캐스트 참조)에 의해 수행되는 광고에는 광고 패킷 전송 타이밍에 어느 정도의 무작위성이 포함됩니다. 지속적인 패킷 충돌을 방지하기 위해 광고 이벤트 스케줄링에 0~10ms의 무작위 지연이 의도적으로 삽입됩니다. 레거시 광고 실행할 때 광고가 작동할 수 있는 유일한 방법입니다.
주기적 광고 결정적 일정에 따라 패킷을 전송하고 다른 디바이스가 광고 디바이스의 일정에 따라 패킷 스캔을 동기화할 수 있는 메커니즘을 제공합니다. 주기적 광고 항상 스캔할 수 없고 연결할 수 없습니다.
주기적 광고 보다 에너지 효율적인 스캔 방법을 제공하여 옵저버 디바이스에 이점을 제공할 수 있으며, LE 오디오 방송 솔루션의 핵심 구성 요소입니다.
광고는 주기적 광고 간격이라고 하는 고정된 간격으로 이루어지며 광고 데이터 페이로드는 변경될 수 있습니다. 일련의 AUX_SYNC_IND 및 관련 AUX_CHAIN_IND PDU가 주기적 광고 트레인을 형성한다고 합니다.
각 주기적 광고 이벤트에서 host 페이로드에 조각화가 필요한지 여부에 따라 하나의 AUX_SYNC_IND PDU가 전송된 후 0개 이상의 AUX_CHAIN_IND PDU가 전송됩니다.
AUX_ADV_IND PDU에는 공통 확장 광고 페이로드 형식의 일부이며 채널 및 타이밍 오프셋 정보를 포함하는 SyncInfo라는 필드가 포함되어 있습니다.
주기적 광고 37개의 범용 광고 채널을 사용합니다. 채널 선택 알고리즘 2번을 사용하여 각 주기적 광고 이벤트가 시작될 때 채널이 선택되고 paEventCounter라는 이벤트 카운터 필드가 입력으로 사용됩니다. 이 카운터는 각 주기적 광고 이벤트에서 증가합니다. AUX_SYNC_IND PDU와 관련된 모든 보조 AUX_CHAIN_IND PDU는 구현별 알고리즘을 사용하여 채널이 선택되고 AuxPtr 필드에 지정됩니다. 그림 25를 참조하십시오.
주기적 광고 간격은 특정 광고 세트에 대한 주기적 광고 발생할 수 있는 빈도를 결정합니다. 그림 25에 표시된 것처럼 AUX_SYNC_IND PDU의 전송으로 시작하여 0개 이상의 AUX_CHAIN_IND PDU로 계속 이어집니다.
그림 25 - 주기적 광고 이벤트
그림 25는 단일 상자로 표시된 여러 기본 광고 채널에 잠재적으로 여러 개의 ADV_EXT_IND PDU가 있는 것으로 단순화했습니다.
스캐닝 장치는 두 가지 방법 중 하나로 주기적 광고 트레인과 동기화할 수 있습니다. AUX_ADV_IND PDU를 스캔하고 SyncInfo 필드의 내용을 사용하여 사용할 주기적 광고 간격, 타이밍 오프셋 및 채널 정보를 설정하거나, AUX_ADV_IND PDU에서 이 정보를 자체적으로 결정한 다른 장치에서 LE-ACL 연결을 통해 이 정보를 수신할 수 있습니다. 이 방법을 주기적 광고 동기화 전송 절차라고 합니다.
7.8.4 PAwR - 응답이 있는 LE 주기적 광고
응답 포함 주기적 광고(PAwR) 는 여러 가지 면에서 주기적 광고 (PADVB)와 유사합니다:
- PADVB를 사용하면 하나의 디바이스(브로드캐스터)가 하나 이상의 수신 디바이스( 옵저버)로 애플리케이션 데이터를 전송하여 일대다 통신 토폴로지를 형성할 수 있습니다. 응답 포함 주기적 광고(PAwR)도 마찬가지입니다.
- 응답 포함 주기적 광고(PAwR) 와 PADVB는 모두 무연결 통신 방식을 사용합니다.
- 광고 패킷의 전송은 고정된 간격으로 주기적으로 이루어지며 두 경우 모두 일정이 무작위로 변동되지 않습니다.
- 옵저버는 방송사가 사용하는 주기적 광고 동기화 전송(PAST) 절차를 사용하거나 AUX_ADV_IND PDU에서 주기적 광고 동기화 전송 일정을 설정할 수 있습니다.
응답 포함 주기적 광고(PAwR) 는 다음과 같이 PADVB와 다릅니다:
- PADVB는 생방송 자키에서 옵저버로의 단방향 데이터 통신만 지원합니다. 응답 포함 주기적 광고(PAwR) 옵저버는 응답 패킷을 생방송 자키에게 다시 전송할 수 있습니다. 응답 포함 주기적 광고(PAwR) 양방향, 무연결 통신 메커니즘을 제공합니다.
- 응답이없는 주기적 광고 (PADVB)에 대한 동기화 정보는 AUX_ADV_IND PDU의 SyncInfo 필드에 포함되어 있습니다. 응답이있는 주기적 광고 응답 포함 주기적 광고(PAwR)))에 대한 동기화 정보는 SyncInfo 필드와 AUX_ADV_IND PDU의 ACAD 필드에 포함되어 있습니다.
- PADVB 생방송 자키는 광고 이벤트 내에서 전송을 예약합니다. 응답 포함 주기적 광고(PAwR) 브로드캐스터는 일련의 이벤트 및 하위 이벤트에서 전송을 예약하고 옵저버는 특정 하위 이벤트 또는 하위 이벤트 중에만 청취하는 방식으로 동기화해야 합니다.
- 응답 포함 주기적 광고(PAwR) 생방송 자키가 전송 시간 슬롯을 사용하여 특정 디바이스에 연결 요청(AUX_CONNECT_REQ PDU)을 전송하고 해당 디바이스와 LE-ACL 연결을 설정할 수 있습니다. PADVB에는 이 기능이 없습니다.
- 응답 없는 주기적 광고 (PADVB)의 경우, 애플리케이션 데이터는 수시로만 변경되는 경향이 있습니다. 응답 포함 주기적 광고(PAwR) 는 애플리케이션 데이터가 자주 변경될 것으로 예상하여 설계되었습니다.
- PADVB를 사용하면 동일한 광고 세트에 동기화된 모든 옵저버 디바이스에 동일한 애플리케이션 데이터가 전달됩니다. 응답 포함 주기적 광고(PAwR)를 사용하면 각 옵저버 디바이스 또는 옵저버 디바이스 세트에 서로 다른 데이터를 전달할 수 있습니다.
주기적 광고 동기화 전송(PAST) 절차에 대한 지원은 PADVB에서는 선택 사항이지만 응답 포함 주기적 광고(PAwR)에서는 필수입니다.
채널 선택은 채널 선택 알고리즘 #2를 사용하여 이루어지며, 주기적 광고 서브이벤트마다 이루어집니다(7.8.4.3 스케줄링 참조). 서브이벤트에서 전송된 PDU에 대한 응답은 동일한 채널을 사용합니다. 여기에는 AUX_SYNC_SUBEVENT_IND PDU에 대한 응답으로 전송되는 AUX_SYNC_SUBEVENT_RSP PDU와 AUX_CONNECT_REQ PDU에 대한 응답으로 전송되는 AUX_CONNECT_RSP PDU가 포함됩니다.
다른 광고 모드와 마찬가지로 응답 포함 주기적 광고(PAwR) 의 경우응답 포함 주기적 광고(PAwR) 주기적 광고 이벤트응답 포함 주기적 광고(PAwR) 이벤트)로 알려진 이벤트에서 활동이 이루어집니다. 이러한 이벤트는 일정 간격으로 발생하며 스케줄링에 무작위적인 변동이 없습니다. 이벤트는 주기적 광고 간격마다 ms마다 시작됩니다.
각 응답 포함 주기적 광고(PAwR) 이벤트는 여러 개의 하위 이벤트로 구성되며, 광고 패킷이 전송되는 것은 하위 이벤트 중입니다. Host 이벤트당 서브이벤트 수를 최대 128개까지 구성할 수 있습니다. 서브 이벤트는 주기적 광고 서브 이벤트 간격마다 시작됩니다. Host 이벤트당 서브이벤트 수와 주기적 광고 서브이벤트 간격을 HCI( Host 컨트롤러 인터페이스) 명령인 HCI_LE_Set_Periodic_Advertising_Parameters V2(또는 그 이상)를 사용하여 구성합니다.
그림 26 - 응답 포함 주기적 광고(PAwR) ) 이벤트 및 하위 이벤트를 참조하세요.
그림 26 - 응답 포함 주기적 광고(PAwR) ) 이벤트 및 하위 이벤트[9]
각 서브이벤트에서 생방송 자키는 하나의 패킷을 전송하는데, 이 패킷에는 보통 AUX_SYNC_SUBEVENT_IND PDU가 포함되지만, 대신 AUX_CONNECT_REQ PDU가 포함될 수도 있습니다. 주기적 광고 응답 슬롯 지연으로 알려진 지연 후, 동일한 서브이벤트 내에서 옵저버 디바이스로부터 응답을 받기 위해 일련의 시간 슬롯이 예약됩니다. AUX_SYNC_SUBEVENT_IND PDU에 대한 응답은 AUX_SYNC_SUBEVENT_RSP PDU로 전송됩니다. Host HCI 명령 HCI_LE_Set_Periodic_Advertising_Parameters에 필요한 응답 슬롯 수를 구성합니다. 그림 27은 응답 포함 주기적 광고(PAwR) 서브 이벤트의 구조를 보여줍니다.
그림 27 - 응답 슬롯이 있는 응답 포함 주기적 광고(PAwR) ) 하위 이벤트
7.8.4.4.1 일반 사항
동기화 프로세스는 옵저버 디바이스에 광고 디바이스가 전송한 관련 패킷을 효율적으로 검색하고 수신하는 데 필요한 정보를 제공합니다. 응답 포함 주기적 광고(PAwR)의 경우, 여기에는 세 가지 측면이 있습니다:
- 옵저버는 응답 이벤트가 포함된주기적 광고 얼마나 자주 발생하는지, 그리고 다음 이벤트가 언제 발생하는지 알아야 합니다. 이 정보는 주기적 광고 간격이라는 매개변수 동기화 패킷 윈도우 오프셋이라는 계산된 값으로 제공됩니다.
- 옵저버는 서브이벤트 발생 빈도, 응답 이벤트가 있는주기적 광고 서브 이벤트 수 등 서브이벤트에 대한 정보가 필요합니다. 또한 응답 전송을 위해 예약된 각 서브이벤트 내의 시간 슬롯과 관련된 특정 세부 정보도 알아야 합니다. 이 정보는 서브이벤트_간격, 서브이벤트 개수, 응답 슬롯 지연, 응답 슬롯 간격 및 응답 슬롯 개수라는 파라미터에 포함되어 있습니다.
- 마지막으로 옵저버는 스캔해야 할 하위 이벤트 번호, 특정 응답 슬롯, 전송된 응답 패킷에 사용할 액세스 주소 알아야 합니다.
(1)에서 설명한 이벤트 타이밍 정보와 (2)의 하위 이벤트 정보를 획득한 옵저버는 응답 포함 주기적 광고(PAwR) 광고 트레인의 이벤트 및 하위 이벤트의 타이밍 파라미터와 구조에 대한 완전한 설명을 갖게 됩니다. 그러나 (3)의 정보가 있어야만 관련성 있는 데이터를 포함할 것으로 예상되는 패킷만 수신하고 응답 패킷의 전송을 예약할 수 있도록 스캔을 예약할 수 있습니다.
(1) 및 (2)는 블루투스 코어 사양 정의된 대로 응답 포함 주기적 광고(PAwR) 논리적 전송으로 처리됩니다. 이 수준의 동기화 정보를 얻는 데 사용할 수 있는 두 가지 절차가 있습니다. 이 문서에서는 7.8.4.4.2 주기적 광고 동기화 정보 검색 및 7.8.4.4.3 주기적 광고 동기화 전송(PAST) 섹션에서 두 가지 절차를 다룹니다.
(3)은 애플리케이션 Layer에서 해결해야 하며 전자 선반 라벨ESL 프로파일과 같은 해당 Bluetooth 프로파일 specification에 정의될 수 있습니다.
7.8.4.4.2 주기적 광고 동기화 정보 검색하기
응답 포함 주기적 광고(PAwR) 와 PADVB는 각각 스캔을 통해 주기적 광고 동기화 정보를 획득하는 데 유사한 절차를 사용합니다.
옵저버는 응답 포함 주기적 광고(PAwR) 와 PADVB를 모두 사용하면 보조 광고 채널에서 전송된 AUX_ADV_IND 패킷을 검색합니다. AUX_ADV_IND에는 주기적 광고 간격 값과 syncPacketWindowOffset이라는 변수를 계산하기 위한 일부 데이터 항목이 포함된 SyncInfo 필드가 포함되어 있습니다. 이 두 값을 획득한 옵저버는 7.8.4.4.1 일반의 (1)에 따라 응답 이벤트가 있는주기적 광고 언제 발생할지 계산할 수 있습니다.
응답 포함 주기적 광고(PAwR) 동기화 절차를 완료하기 전에 7.8.4.4.1 일반의 (2)에 따라 하위 이벤트 및 응답 슬롯에 대한 정보도 필요합니다. 이 정보는 주기적 광고 간격을 가져온 동일한 AUX_ADV_IND PDU에서 주기적 광고 응답 타이밍 정보라는 광고 데이터 유형(AD 유형)에서 찾을 수 있으며, 이 정보 자체는 PDU의 추가 컨트롤러 광고 정보(ACAD) 필드에서 찾을 수 있습니다.
7.8.4.4.3 주기적 광고 동기화 전송(PAST)
PAST 절차를 사용할 때 연결을 통해 동기화 파라미터를 전달하는 디바이스가 다른 디바이스를 대신하여 먼저 스캔하여 동기화 파라미터를 획득하는 경우가 있습니다. 그러나 응답 포함 주기적 광고(PAwR)의 경우 PAST 지원이 필수이므로 응답 포함 주기적 광고(PAwR) 생방송 자키가 LE ACL 연결을 통해 필요한 동기화 데이터를 옵저버에게 전달할 수 있습니다. 이 방법을 사용하면 두 디바이스 모두 AUX_ADV_IND PDU를 스캔할 필요가 없습니다.
7.8.4.4.4 서브이벤트 동기화 및 응답 슬롯 할당
서브이벤트 동기화는 옵저버 디바이스에 스캔을 수행해야 하는 서브이벤트를 지정하는 것과 관련이 있습니다. 하나 이상의 옵저버 디바이스가 동일한 서브이벤트에 동기화될 수 있습니다. 개별 옵저버는 하나 이상의 하위 이벤트 동안 수신하도록 동기화될 수 있습니다.
또한 옵저버가 응답 PDU를 보내려면 어떤 서브이벤트 응답 슬롯을 사용할지 결정할 수 있는 근거가 있어야 합니다.
이 두 가지 문제는 모두 애플리케이션 Layer의 책임입니다.
7.8.5 LE BIS 및 LE CIS - 등시적 통신
비동기 통신은 Bluetooth LE 사용하여 장치 간에 시간 제한 데이터를 전송하는 방법을 제공합니다. 이는 동일한 소스에서 서로 다른 시간에 데이터를 수신하는 여러 싱크 장치가 해당 데이터의 처리를 동기화할 수 있는 메커니즘을 제공합니다. LE 오디오 등시성 통신을 사용합니다.
등시성 통신을 사용할 때 데이터에는 시간 제한이 있는 유효 기간이 있으며, 이 기간이 지나면 데이터가 만료된다고 합니다. 아직 전송되지 않은 만료된 데이터는 폐기됩니다. 즉, 기기는 프로필에 명시된 유효 기간 및 허용 가능한 대기 시간에 관한 규칙에 따라 유효한 데이터만 수신합니다.
데이터는 등시적 스트림으로 전송되며 스트림은 등시적 그룹에 속합니다. 장치는 수신된 패킷을 동시에 처리하기 전에 같은 그룹의 구성원인 모든 스트림이 관련 패킷을 전달할 기회를 가질 수 있도록 일정 시간 동안 기다립니다. 예를 들어, 스테레오 음악은 왼쪽 스테레오 채널과 오른쪽 스테레오 채널의 두 스트림을 사용하여 전송될 수 있습니다. 두 스트림은 동일한 그룹의 구성원이므로 두 스트림에서 수신된 패킷의 렌더링이 동시에 이루어지므로 사용자는 의도한 대로 스테레오 음악을 들을 수 있습니다.
LE 비동기 물리적 채널을 사용하는 두 가지 논리적 전송이 정의되어 있습니다. 커넥티드 비동기 스트림 (LE CIS 또는 간단히 CIS)은 연결 지향 통신을 사용하며 데이터의 양방향 전송을 지원합니다. 브로드캐스트 비동기 스트림 (LE BIS 또는 간단히 BIS)은 연결 없는 브로드캐스트 통신을 사용하며 데이터의 단방향 통신을 제공합니다.
7.8.5.2.1 CIS 개요
단일 CIS 스트림은 연결된 두 장치 간에 점대점 등시성 통신을 제공하고 CIS PDU로 알려진 링크 Layer PDU에서 데이터를 전송합니다. 그림 28의 전체 데이터 전송 아키텍처에는 LE-CIS(CIS) 논리적 전송이 표시되어 있습니다(그림 28).
그림 28 - Bluetooth 데이터 전송 아키텍처의 LE-CIS
두 개의 논리적 링크인 LE-S와 LE-F가 정의되어 있으며 프레임되지 않은 데이터(LE-S)와 프레임된 데이터(LE-F)를 모두 지원합니다. LE-S와 LE-F의 사용은 비동기 적응 계층의 관심사입니다.
CIS 스트림은 LE 비동기 물리적 채널을 사용하며 모든 Bluetooth LE PHY를 사용할 수 있습니다.
양방향 통신은 CIS에서 지원되며 승인 프로토콜이 사용됩니다.
CIS 스트림은 연결된 비동기 그룹(CIG)이라는 그룹의 구성원이며, 각 그룹은 1개 이상의 CIS를 포함할 수 있습니다. 그림 29를 참조하십시오.
CIG당 최대 31개의 CIS가 있을 수 있습니다. 중앙 디바이스에서 여러 개의 CIG를 생성할 수 있습니다. 그러나 사용 가능한 방송 시간 및 기타 구현 세부 정보에 따라 이러한 제한 더 낮은 값으로 줄어드는 경우가 많습니다.
그림 29 - 두 개의 CIS를 포함하는 CIG
7.8.5.2.2 채널 사용
연결된 비동기 스트림은 채널 선택 알고리즘 2번과 함께 적응형 주파수 호핑을 사용합니다.
7.8.5.2.3 예약하기
CIG와 그 회원, 회원사 CIS의 일정은 CIG 이벤트, CIS 이벤트 및 하위 이벤트의 시스템에 의해 관리됩니다.
CIG 이벤트는 CIG에 속한 CIS 전반에 걸쳐 활동 스케줄링의 시작을 알리는 신호이며, 이는 그룹 내 첫 번째 CIS의 앵커 지점에서 발생합니다. CIG 이벤트는 ISO_Interval이라는 매개변수 지정된 간격으로 발생합니다.
각 CIS 이벤트는 하나 이상의 하위 이벤트로 나뉩니다. 사용 중인 하위 이벤트의 수는 NSE라는 스트림 매개변수 표시됩니다. 연결된 등시 스트림에서 하위 이벤트가 발생하는 동안 그림 30과 같이 중앙에서 한 번 전송(T)하고 주변 장치에서 응답(R)합니다. 하위 이벤트는 Sub_Interval이라는 CIS 매개변수 지정된 기간만큼 간격을 두고 간격을 둡니다. CIS 이벤트당 하위 이벤트가 하나만 있는 경우 Sub_Interval은 항상 0으로 설정되며, 그렇지 않은 경우 400마이크로초 이상이지만 ISO 간격보다 작습니다.
채널은 각 하위 이벤트마다 변경된다는 점에 유의하세요.
각 CIS는 CIG 이벤트 중에 순차적으로 서비스되거나 서로 다른 CIS의 하위 이벤트가 인터리빙될 수 있습니다. 그림 30에는 각각 순차적으로 서비스되는 세 개의 CIS를 포함하는 CIG의 예가 나와 있습니다.
그림 30 - CIS 이벤트 및 하위 이벤트
각 CIS에는 플러시 타임아웃(FT) 및 버스트 수(BN) 등 NSE(서브 이벤트 수) 외에 여러 가지 중요한 매개변수가 있습니다.
각 페이로드(예: LC3[10]와 같은 오디오 코덱에서 출력되는 오디오 데이터 청크)에는 성공적으로 전송될 수 있는 최대 CIS 이벤트 수(승인으로 표시)가 주어지며, 이는 FT 매개변수 지정됩니다. 이러한 각 CIS 이벤트의 각 하위 이벤트에서 시도를 할 수 있으며 FT 이벤트 내에서 성공하지 못하면 패킷은 플러시 (삭제)됩니다. 때때로 서로 다른 데이터(즉, 페이로드)를 포함하는 여러 개의 PDU를 동시에 사용할 수 있는 경우가 있으며, CIS는 동일한 CIS 이벤트 중에 여러 개의 서로 다른 PDU를 전송할 수 있도록 허용합니다. 각 CIS 이벤트에서 서비스될 수 있는 서로 다른 PDU의 수는 버스트 번호(BN) 매개변수 지정됩니다.
7.8.5.2.4 처리 동기화
CIG에는 CIG_Sync_Delay라는 관련 타이밍 매개변수 있습니다. 동일한 CIG의 CIS에는 각각 CIS_Sync_Delay라는 타이밍 매개변수 있으며, 이는 그룹 내 모든 스트림에서 리시버의 등시 데이터 처리(일반적으로 오디오 렌더링)를 동기화할 때 사용됩니다. 수신기는 수신 데이터를 렌더링하기 전에 이 매개변수 지정된 시간 동안 대기합니다.
그림 31 - CIG에서 CIS 데이터의 동기화된 렌더링
그림 31에 표시된 것처럼 각 스트림에는 서로 다른 CIS_Sync_Delay 값이 있습니다. CIG의 첫 번째 CIS 스트림의 경우 그룹 수준 매개변수 CIG_Sync_Delay로 설정됩니다. 그룹 내 다른 각 스트림에 대해 CIS_Sync_Delay는 점진적으로 낮은 값으로 설정됩니다. 즉, 그룹에서 이전에 서비스된 스트림에서 수신하는 장치는 그룹의 CIS 이벤트 처리에서 나중에 전송된 패킷을 수신하는 장치보다 수신된 패킷의 콘텐츠를 렌더링하기까지 더 오래 기다려야 합니다. 프로파일과 같은 상위 계층 사양에서는 로컬 처리 지연을 고려할 수 있도록 데이터를 렌더링해야 하는 시간을 계산할 때 추가 프레젠테이션 지연을 사용하도록 규정할 수 있습니다. 이 계층형 지연 시스템의 장점은 각 싱크 디바이스가 수신된 데이터를 동시에 처리한다는 것입니다.
7.8.5.2.5 CIS 스트림 생성
연결된 아이소크로닉스 스트림을 설정하려면 먼저 ACL 연결을 만들어야 합니다. 이 연결은 두 가지 용도로 사용됩니다. 먼저 링크 Layer 제어 PDU를 교환할 수 있습니다. 둘째, 스트림이 설정된 후 CIS 이벤트를 예약할 수 있는 타이밍 기준점을 제공합니다.
중앙 장치는 항상 CIS를 생성하는 절차를 시작합니다. 이는 LL_CIS_REQ PDU라는 링크 Layer 제어 PDU를 전송하는 방식으로 이루어집니다. 모든 것이 잘되면 주변 장치가 LL_CIS_RSP PDU로 응답하고 중앙 장치가 LL_CIS_IND PDU를 보내면 스트림이 설정된 것으로 간주합니다. 이 PDU에는 렌더링 전에 적용할 CIS 이벤트의 타이밍과 지연을 결정하는 중요한 파라미터가 포함되어 있습니다. 특히 CIS_Offset은 ACL 앵커 포인트(연결 이벤트에서 첫 번째 패킷이 전송되는 시간)와 스트림의 첫 번째 CIS 이벤트 사이의 오프셋을 마이크로초 단위로 제공합니다. CIG_Sync_Delay에는 전체 CIG 동기화 지연 값(마이크로초)이, CIS_Sync_Delay에는 이 스트림에서 사용할 동기화 지연 값(마이크로초)이 포함됩니다.
스트림이 생성된 후에는 스트림을 생성하는 데 사용된 ACL 연결과 독립적으로 또는 함께 실행됩니다. 그러나 ACL 연결이 종료되면 연결된 CIS도 종료되어야 합니다.
7.8.5.2.6 CIS 암호화
두 개의 피어 디바이스가 페어링된 경우 CIS에서 사용하는 링크가 암호화될 수 있습니다.
7.8.5.3.1 BIS 개요
BIS 스트림은 하나의 송신기 다수의 수신기 장치 간에 방송 등시성 통신을 제공합니다. 데이터는 BIS 데이터 PDU로 알려진 링크 Layer PDU에서 전송됩니다. 제어 정보는 BIS 제어 PDU에서 전송됩니다.
그림 32의 전체 데이터 전송 아키텍처에는 LE-BIS(BIS) 논리적 전송이 설명되어 있습니다.
그림 32 - Bluetooth 데이터 전송 아키텍처의 LE-BIS
BIS를 통해 브로드캐스트되는 데이터는 그에 따라 정의된 논리 링크 유형인 LE-S 및 LE-F로 프레임 또는 언프레임될 수 있습니다. LEB-C 논리적 링크는 제어 정보를 전달합니다.
BIS 스트림은 LE 비동기 물리적 채널을 사용하며 모든 Bluetooth LE PHY를 사용할 수 있습니다.
BIS 스트림은 브로드캐스트 비동기 그룹(BIG)이라는 그룹의 구성원이며, 각 그룹은 1개 이상의 BIS를 포함할 수 있습니다. 그림 33을 참조하십시오.
그림 33 - 두 개의 BIS를 포함하는 BIG
BIG당 최대 31개의 BIS가 있을 수 있습니다. 중앙 디바이스에서 여러 개의 BIG을 생성할 수 있습니다. 그러나 사용 가능한 방송 시간 및 기타 구현 세부 정보에 따라 이러한 제한 더 낮은 값으로 줄어드는 경우가 많습니다.
단방향 통신은 BIS에서만 지원됩니다.
CIS와 달리 BIS는 승인 프로토콜을 통합하지 않습니다. 따라서 BIS 전송은 본질적으로 신뢰할 수 없습니다. 하지만 이를 극복하기 위해 무조건 패킷 재전송 시스템이 사용됩니다. BIS는 통신이 단방향으로 이루어지기 때문에 주변 장치 응답을 위한 슬롯을 예약할 필요가 없습니다(CIS의 경우처럼). 따라서 주어진 방송 시간 동안 두 배의 서브 이벤트가 전송되도록 예약할 수 있으므로 안정성을 향상시키는 재전송을 할 수 있는 기회가 더 많습니다. 또한 재전송은 별개의 하위 이벤트에서 전송되므로 서로 다른 채널에서 전송됩니다. 선택한 채널은 마지막 전송에서 최소 6MHz 이상 떨어져 있어야 하며, 이는 특정 채널의 간섭으로 인한 패킷 손실 가능성을 완화하는 데 도움이 됩니다.
7.8.5.3.2 채널 사용
방송 비동기 스트림은 채널 선택 알고리즘 2번과 함께 적응형 주파수 호핑을 사용합니다.
7.8.5.3.3 예약하기
BIG 및 그 구성원 BIS의 스케줄링은 BIG 이벤트, BIS 이벤트 및 하위 이벤트의 시스템에 의해 관리됩니다. 또한 전체 BIG와 관련된 제어 PDU의 전송을 위해 특수 제어 하위 이벤트가 정의되어 있습니다.
BIG 이벤트는 BIG에 속한 BIS 전반에 걸쳐 활동 스케줄링의 시작을 알립니다. BIS 이벤트는 BIG의 시작 지점( BIG 앵커 포인트라고 함)으로부터 BIS_Spacing이라는 매개변수 지정된 값의 배수인 간격으로 시작됩니다.
각 BIS 이벤트는 하나 이상의 하위 이벤트로 나뉩니다. 사용 중인 하위 이벤트의 수는 NSE라는 스트림 매개변수 표시됩니다. 하위 이벤트가 진행되는 동안 생방송 자키는 하나의 패킷을 전송합니다. 통신은 단방향이며 패킷을 수신할 필요는 없습니다. 서브 이벤트는 Sub_Interval이라는 BIG 매개변수 지정된 기간만큼 간격을 두고 배치됩니다.
연결된 등시성 그룹에 따라 BIG 내에서 BIS 이벤트의 스케줄링은 순차적이거나 인터리빙될 수 있습니다.
BIG 이벤트에는 항상 BIG의 마지막 하위 이벤트로 예약되는 컨트롤 하위 이벤트가 포함될 수 있습니다.
채널은 각 하위 이벤트마다 변경된다는 점에 유의하세요.
그림 28은 순차적 배열로 예약된 BIG 및 BIS 이벤트와 하위 이벤트의 예를 보여줍니다. BIG 제어 하위 이벤트(지정된 Tc)는 BIG 이벤트 #1의 마지막에 전송된다는 점에 유의하세요.
그림 34 - BIG/BIS 이벤트 스케줄링
7.8.5.3.4 처리 동기화
BIG에서 브로드캐스트 등시 스트림 간 데이터의 동기화된 처리는 연결된 등시 통신에서 사용되는 접근 방식과 유사한 방식으로 이루어집니다. 수신자는 BIG 및 전체 파라미터에 대한 정보를 보유하고 있으며 어떤 스트림을 수신하도록 선택했는지 알 수 있습니다. BIG의 타이밍 파라미터는 모든 스트림에 균일하게 적용됩니다. 수신기는 전체 BIG_Sync_Delay 값과 BIS_Spacing 매개변수 사용하여 수신된 데이터를 다른 스트림과 동기화되도록 처리하기 전에 대기할 시간을 계산할 수 있습니다.
7.8.5.3.5 BIS 스트림 생성
디바이스가 BIS 내에서 방송되는 패킷을 수신하고 동일한 BIG의 구성원인 다른 스트림을 수신하는 다른 디바이스와 동시에 해당 패킷의 콘텐츠를 렌더링하거나 처리하려면 먼저 디바이스가 BIG와 이를 정의하는 파라미터(예: 포함된 스트림 수, 각 스트림과 관련된 이벤트와 하위 이벤트 사이의 간격, 타이밍 앵커 포인트 계산을 위한 타이밍 오프셋 정보 등)를 검색해야 합니다. 이를 지원하기 위해 방송사는 주기적 광고 통해 필요한 파라미터를 전달합니다. BIGInfo로 알려진 복합 필드는 ACAD(추가 컨트롤러 광고 데이터) 필드 내의 AUX_SYNC_IND PDU에서 방송되며 필요한 데이터를 포함합니다.
BIGInfo를 수신하는 방법에는 두 가지가 있습니다. 첫 번째 경우, 수신기 정의된 절차를 사용하여 주기적 광고 트레인(7.8.3.1 기본 사항 참조)과 직접 동기화하여 AUX_SYNC_IND PDU를 수신하고 ACAD 내에서 BIGInfo를 추출해야 합니다. 그러나 주기적 광고 트레인을 스캔하고 동기화하는 것은 전력 소비 측면에서 비용이 많이 드는 절차가 될 수 있습니다. 따라서 두 번째 경우에는 주기적 광고 트레인을 검색하고 동기화하는 작업을 다른 디바이스(일반적으로 더 큰 전력 자원을 보유한 디바이스)에 위임할 수 있습니다. 스캔이 위임된 디바이스는 BIGInfo를 획득한 후, 이 정보를 보다 효율적인 ACL 연결을 통해 방송 등시 스트림을 수신하고자 하는 디바이스에 전달합니다. 이는 주기적 광고 동기화 전송(PAST)이라는 절차를 사용하여 수행됩니다.
7.8.5.3.6 BIG 암호화
BIG는 암호화될 수 있습니다. 이 경우 BIS를 수신하는 디바이스가 브로드캐스트 디바이스와 페어링되어 있지 않아도 됩니다. 대신 암호화 키를 도출하는 데 사용되는 브로드캐스트 코드 매개변수 배포해야 합니다. 이 작업은 대역 외에서 수행하거나 상위 수준 프로필에 설명된 절차에 따라 수행할 수 있습니다.
7.8.5.4 재전송 및 안정성
BIS 또는 CIS 스트림의 하위 이벤트 연속 내에서 동일한 패킷의 재전송을 사용하여 안정성을 향상시킬 수 있습니다. BIS의 경우 재전송은 무조건적으로 이루어지지만, CIS의 경우 주변 장치가 전송을 확인하지 않은 경우에 발생합니다.
BIS의 경우 주변 장치 응답을 위한 슬롯을 예약할 필요가 없기 때문에(CIS의 경우처럼) 주어진 방송 시간 동안 두 배의 하위 이벤트가 전송되도록 예약할 수 있으므로 안정성을 높이는 재전송의 기회가 더 많아집니다.
재전송은 별개의 하위 이벤트를 차지하기 때문에 서로 다른 채널에서 전송되며, 선택한 채널은 마지막 전송과 최소 6MHz 이상 떨어져 있어야 합니다. 이렇게 하면 특정 채널의 간섭으로 인한 패킷 손실 가능성을 완화할 수 있습니다.
8. 블루투스® Channel Sounding
8.1 Bluetooth Channel Sounding 소개
블루투스 Channel Sounding Bluetooth LE 컨트롤러의 옵션 기능 . 이 기능을 사용하면 애플리케이션 원격 장치와의 현재 거리를 계산할 수 있는 데이터를 생성합니다. 원격 장치도 channel sounding 사용하며 첫 번째 장치와 일련의 무선 신호 교환에 참여합니다.
Bluetooth Channel Sounding 신호 강도(수신 신호 강도 표시기 또는 RSSI)를 거리의 대용물로 사용하는 방법보다 더 정확하고 안정적이며 훨씬 더 안전합니다. Bluetooth Channel Sounding 초기 구현은 최대 100미터 거리에서 +/- 20cm의 정확도를 달성하는 것으로 입증되었습니다. RSSI 기반 거리 추정은 특히 몇 미터 이상의 거리에서는 정확도가 떨어지고 신뢰할 수 없습니다. 또한 내재된 보안이 없으므로 사용 방법에 세심한 주의를 기울여야 합니다.
블루투스 코어 사양 블루투스 Channel Sounding 생성된 데이터를 사용하여 거리를 계산하는 알고리즘을 제공하지 않는다는 점에 유의해야 합니다. 이는 애플리케이션 계층의 책임입니다(섹션 8.14 거리 측정 애플리케이션 참조).
Bluetooth Channel Sounding 자동차와 같이 귀중한 물건을 보호하기 위해 강력한 보안이 필요한 키리스 엔트리 및 시동 시스템과 같은 애플리케이션에서 안전하게 거리를 계산할 수 있도록 설계되었습니다.
8.2 디바이스 역할
블루투스 Channel Sounding 두 가지 장치 역할을 정의합니다. 하나는 이니시에이터 는 channel sounding 절차를 시작하고 궁극적으로 생성된 데이터를 거리 값을 계산할 수 있는 애플리케이션 계층으로 전달하는 장치입니다. 다른 장치는 리플렉터. 모든 경우에 channel sounding 이니시에이터 신호를 전송하고 리플렉터 자체 전송으로 이에 응답하는 방식으로 이루어집니다.
그림 35 - CS 중 이니시에이터 리플렉터 간의 신호 교환
사실, 앞으로 살펴보겠지만, 전체 Channel Sounding 절차에는 다양한 유형과 다양한 시퀀스의 일련의 전송이 포함됩니다.
8.3 데이터 전송 아키텍처에서의 Bluetooth Channel Sounding
Bluetooth LE 데이터 전송 아키텍처는 7.7 데이터 전송 아키텍처 섹션에서 소개했습니다. 블루투스 Channel Sounding 다른 전송의 예와 함께 그림 36에 표시된 것처럼 물리적 채널과 물리적 링크로 구성됩니다.
그림 36 - 데이터 전송 아키텍처의 Bluetooth Channel Sounding
8.4 Bluetooth Channel Sounding 방식 두가지
블루투스 Channel Sounding 여러 가지 이유로 흥미롭습니다. 하지만 한 가지 특징적인 기능 블루투스 코어 사양 두 가지 서로 다른 거리 측정 방법이 정의되어 있으며, 애플리케이션 두 가지 방법 중 하나를 사용하거나 최상의 보안을 위해 두 가지 방법을 함께 사용할 수 있다는 점입니다. 이 두 가지 방법을 위상 기반 거리 측정 위상 기반 거리 측정(PBR)))과왕복 시간(RTT))이라고 하며 각 방법에 대한 기본 이론은 다음에서 설명합니다. 보안에 대한 자세한 내용은 8.13 보안 섹션에서 설명합니다.
8.4.1 위상 기반 거리 측정
위상 기반 거리 측정(PBR) 무선 전송이 일련의 파동으로 구성되며 파동 주기로 알려진 각 완전한 파동은 전송 주파수가 변하지 않는 한 상수인 물리적 길이를 갖는다는 사실을 이용합니다.
그림 37 - 각각 표시된 파장을 가진 두 개의 파동 주기
파장의 일부분은 위상이라는 양으로 표현됩니다. 위상은 각도 또는 라디안 단위로 표시됩니다. 신호의 파장과 위상 기반 거리 측정(PBR) 이 작동하는 방식의 핵심입니다.
그림 38은 파동 주기 내의 여러 지점을 표시하고 해당 위치에 해당하는 위상 값을 라디안 단위로 표시합니다.
그림 38 - 위상 값 예시
이니시에이터 디바이스의 수신기 측정한 신호의 파장과 위상 값만으로는 두 디바이스 간의 거리를 계산할 수 없습니다. 따라서 위상 기반 거리 측정(PBR) 은 각각 다른 주파수(f1 및 f2)를 가진 두 개의 서로 다른 신호를 교환하여 작동하므로 파장이 각각 다릅니다.
이니시에이터 주파수 F1으로 전송합니다. 리플렉터 장치는 이 전송을 수신하여 동일한 주파수로 이니시에이터 다시 전송합니다. 이니시에이터 응답 전송의 위상(p1)을 측정하고 이를 기록합니다. 그런 다음 이니시에이터 주파수 f2에서 다른 channel sounding 신호를 전송합니다. 다시 한 번 리플렉터 동일한 주파수 f2에서 유사한 전송으로 응답하고 이니시에이터 응답이 수신된 지점에서 위상(p2)을 측정합니다.
그림 39 - 주파수 F1에서 첫 번째 위상 기반 거리 측정(PBR) ) 신호 교환
그림 40 - 주파수 f2에서 초 위상 기반 거리 측정(PBR) ) 신호 교환
두 Channel Sounding 신호에 대해 측정된 위상 값의 차이(p2 - p1)를 통해 간단한 수학을 사용하여 두 장치 사이의 거리를 계산할 수 있습니다.
실제로 Bluetooth가 위상 기반 거리 측정(PBR) 사용하는 방식은 여기에 제공된 설명보다 조금 더 복잡하지만 그 핵심은 이 기본 방법론입니다.
하지만 위상 값을 사용하여 거리를 계산하는 데는 복잡한 문제가 있습니다. 위상 값은 신호의 여러 파동 주기를 따라 측정할 때 주기적입니다. 한 파동 주기에 대해 측정하면 0 라디안에서 2π 라디안(0 - 360도)의 모든 값을 통과합니다. 그러나 신호의 다음 파동 주기에서 위상은 다시 0 라디안에서 시작하여 모든 값을 거쳐 2π 라디안까지 한 번 더 통과합니다. 이는 각 웨이브 사이클마다 반복됩니다. 그림 41은 이 주기적 패턴을 보여줍니다.
그림 41 - 위상 값의 주기적 특성
위상 기반 거리 측정(PBR)의 맥락에서 이는 중요한 의미를 갖습니다. 위상 값은 디바이스 간의 거리에 따라 달라집니다. 그러나 특정 물리적 거리에서는 위상 값이 반복되기 시작합니다. 따라서 동일한 위상차 값으로 두 개 이상의 거리가 암시될 수 있습니다. 이를 거리 모호성이라고 합니다. 다행히도 8.10 채널 및 채널 선택에 설명된 대로 Bluetooth Channel Sounding design 실제로는 이러한 문제가 발생하지 않도록 보장합니다.
8.4.2 왕복 타이밍
무선 신호는 빛의 속도로 이동합니다. 왕복 시간(RTT) ) 방법은 리플렉터 수신 신호를 처리하고 응답을 공식화하여 전송하는 데 필요한 시간을 고려하여 신호가 이니시에이터 리플렉터 이동한 후 다시 돌아오는 데 걸리는 시간을 측정하는 방식입니다. 그런 다음 장치 간 왕복 측정된 시간에 광속을 곱한 다음 결과를 2로 나누어 거리를 계산할 수 있습니다.
그림 42 - 왕복 시간(RTT) ) 전송 및 타이밍 포인트
그림 42는 왕복 시간(RTT) 패킷의 교환을 보여줍니다. 녹색 점선( ---- )은 두 신호 중 어느 쪽도 공중에 있지 않은 경과 시간을 나타냅니다. 타임라인에는 네 개의 지점이 표시되어 있으며 표 9에 설명되어 있습니다.
| 시간 내 즉시 | 설명 |
|---|---|
| ToDA | 장치 A에서 출발 시간: 장치 A에서 무선으로 신호를 전송하는 시간입니다. |
| ToAB | 장치 B에 도착한 시간: 신호가 장치 B의 안테나에 도착한 시간입니다. |
| ToDB | 장치 B에서 출발 시간: 장치 B에서 무선으로 전송하는 시간입니다. |
| ToAA | 장치 A에 도착한 시간: 장치 B의 신호가 장치 A의 안테나에 수신된 시간입니다. |
표 9 - 왕복 시간(RTT) ) 타이밍 인스턴스
왕복 시간 왕복 시간(RTT) 은 그림 42에 표시된 타이밍 인스턴스로 다음과 같이 표현할 수 있습니다:
왕복 시간(RTT) ) = 2 * ToF = (ToAA - ToDA) - (ToDB - ToAB)
이 용어는 리플렉터 처리 시간입니다. 이니시에이터 이 값을 전송한 후 리플렉터 응답을 받기까지 경과한 시간에서 이 값을 뺍니다 리플렉터 그렇다면 이니시에이터 리플렉터 이니시에이터 신호를 처리하고 응답을 회신하는 데 걸린 시간을 어떻게 알 수 있을까요?
답은 간단합니다. 리플렉터 소요되는 시간은 Channel Sounding 시작되기 전에 두 장치 간에 합의된 고정된 기간입니다.
실제로 Channel Sounding 시작하려면 일련의 절차를 실행해야 합니다. 링크 Layer 사양은 제어 절차 모음을 정의하며, 그 중 다수는 Channel Sounding 구성하고 시작하는 것과 관련이 있습니다.
8.5 Bluetooth Channel Sounding 링크 레이어 제어 절차
channel sounding 시작하려면 먼저 두 장치가 LE-ACL 연결을 설정해야 합니다(7.8.1 LE ACL - LE 비동기 연결 지향 논리적 전송 참조). channel sounding 제어 절차에서 연결을 사용하기 전에 링크에서 암호화를 활성화해야 하므로 두 channel sounding 디바이스가 페어링되어 있어야 합니다.
두 장치 간에 암호화된 연결이 설정되면 다음과 같은 링크 Layer 제어 절차가 실행됩니다:
- Channel Sounding 보안 시작
- Channel Sounding 기능 교환
- Channel Sounding 구성
- 모드-0 FAE 테이블 요청
- Channel Sounding 시작
8.5.1 Channel Sounding 보안 시작
블루투스 Channel Sounding Bluetooth LE 다른 측면에서는 찾아볼 수 없는 여러 가지 고유한 보안 기능이 있습니다. 그중 일부는 초기화 벡터(CS_IV), 인스턴스화 논스 (CS_IN) 및 개인화 벡터(CS_PV)라는 세 가지 숫자 파라미터에 따라 달라집니다.
Channel Sounding 보안 시작 절차 중에 두 장치는 각각 세 가지 보안 매개변수 유형에 대한 값을 생성하여 암호화된 LE-ACL 연결을 통해 다른 장치에 전달합니다. 그런 다음 각 장치에서 세 가지 유형의 각 값 쌍을 연결하여 프로세스가 끝날 때 각 장치가 동일한 128비트 CS_IV, 64비트 CS_IN 및 128비트 CS_PV 값을 보유하도록 합니다.
8.5.2 Channel Sounding 기능 교환
모든 channel sounding 장치에 동일한 기능이 있는 것은 아닙니다. 예를 들어, 지원되는 channel sounding 방법(8.4 두 가지 Bluetooth Channel Sounding 방법 참조)이 다를 수 있습니다. 총 22개의 channel sounding 기능 파라미터가 정의되어 있습니다.
두 장치가 모두 지원할 수 있는 Channel Sounding 구성에 도달하기 위해서는 먼저 두 장치의 기능에 대한 정보를 교환해야 합니다. 링크 Layer은 이를 위해 LL_CS_CAPABILITIES_REQ 및 LL_CS_CAPABILITIES_RSP PDU를 정의합니다.
8.5.3 Channel Sounding 구성
각 장치의 channel sounding 기능에 대한 정보를 기반으로 링크 Layer LL_CS_CONFIG_REQ 및 LL_CS_CONFIG_RSP PDU를 사용하여 두 장치가 모두 지원할 수 있는 선택된 구성을 교환합니다.
이니시에이터 또는 리플렉터 channel sounding 역할은 이 절차 중에 프로세스를 구동하는 애플리케이션 다른 장치가 응답하는 LL_CS_CONFIG_REQ PDU에 선택 사항을 전송하여 결정됩니다.
8.5.4 모드 0 FAE 테이블 요청
모든 디바이스는 전송 주파수를 설정할 때 어느 정도의 부정확성을 나타내며, 이는 필요한 주파수가 속해 있는 RF 채널에 따라 달라질 수 있습니다.
분수 주파수 오프셋 작동 오류(FAE)는 디바이스가 전송 주파수를 설정할 수 있는 부정확성을 측정하는 척도입니다. 이는 의도한 주파수와 실제로 생성되는 주파수 간의 차이(ppm)로 표시됩니다.
channel sounding 이니시에이터 리플렉터 FAE를 고려한 캘리브레이션을 수행해야 하며, 이를 위해서는 리플렉터 FAE 데이터 테이블이 필요합니다. 이니시에이터는 링크 Layer 모드 0 FAE 테이블 요청 제어 절차를 통해 이 데이터를 획득합니다. 여기에는 이니시에이터 LL_CS_FAE_REQ PDU를 전송하면 리플렉터 FAE 테이블이 포함된 LL_CS_FAE_RSP PDU로 응답하는 방식이 포함됩니다. 디바이스의 FAE 테이블은 제조 과정에서 설정된다는 점에 유의하세요.
모드 0은 8.8 단계 및 모드 섹션에서 설명합니다.
8.5.5 Channel Sounding 시작
보안 자료를 교환하고, 구성에 동의하고, 가능한 경우 FAE 데이터를 공유한 이니시에이터 이제 LE 컨트롤러에 channel sounding 시작하도록 지시할 수 있습니다. 여기에는 링크 Layer 제어 PDU인 LL_CS_REQ, LL_CS_RSP 및 LL_CS_IND의 교환이 포함됩니다.
Channel sounding 딩은 CS 단계라고 하는 일련의 다른 작업으로 진행되며 여러 타이밍 매개변수의 영향을 받습니다. 이러한 매개변수는 Channel Sounding 시작 중에 교환됩니다.
8.6 시간 분할
7.8 논리적 전송에서 설명한 논리적 전송은 모두 이벤트 및 때로는 하위 이벤트 측면에서 활동이 발생하는 타임라인을 구성합니다. channel sounding 활동의 순서와 스케줄링은 보다 정교하고 가변적이며, 이를 수용하기 위해 4단계의 시간 분할이 정의되어 있습니다.
channel sounding 실행될 때는 일련의 하나 이상의 CS 프로시저를 통해 실행됩니다. CS 프로시저는 CS 이벤트로 나뉘며, 각 CS 이벤트는 다시 CS 하위 이벤트로 나뉩니다. 각 CS 하위 이벤트 내에서 일련의 두 개 이상의 CS 단계가 예약되며, CS 단계 내에서 RF 송신 및 수신 활동이 이루어집니다. 그림 43은 이러한 개념을 예시 구성과 함께 사용할 때 나타날 수 있는 모습을 보여줍니다.
그림 43 - CS 시간 분할 개념
8.7 패킷 및 톤
CS 단계 내에서 이루어지는 RF 활동은 두 가지 형태 중 하나를 취합니다:
- 패킷 - 무선 전송을 위해 가우스 주파수 시프트 키잉(GFSK)을 사용하여 변조된 이진 데이터가 포함된 패킷입니다.
- 톤 - 데이터가 포함되지 않은 무선 전송입니다. 무선 신호 자체의 속성은 디지털 도메인의 데이터가 필요 없는 위상 기반 거리 측정(PBR) ) 방식에 사용됩니다.
Channel sounding 패킷을 CS_Sync 패킷이라고 하며 여러 가지 변형이 정의되어 있습니다. CS_Sync 패킷은 캘리브레이션 단계와 왕복 시간(RTT) ) 방식이 사용 중일 때 전송됩니다. channel sounding 사용되는 톤을 CS 톤이라고 하며, 위상 기반 거리 측정(PBR) ) 방식이 사용 중일 때 사용됩니다.
8.8 단계 및 모드
CS 단계는 Bluetooth Channel Sounding 사용하는 시간 분할 및 스케줄링 체계의 가장 낮은 수준입니다. 단계에는 연결된 모드가 있으며 이 중 네 가지 모드가 정의되어 있습니다.
| 모드 | 묘사 |
|---|---|
| 0 | 모드 0은 보정 목적으로 사용됩니다. |
| 1 | 모드-1은 왕복 시간(RTT) ) 방식과 관련이 있습니다. |
| 2 | 모드-2는 위상 기반 거리 측정(PBR) ) 방식과 관련이 있습니다. |
| 3 | 모드-3은 단일 듀얼 방식 단계에서 왕복 시간(RTT) 과 위상 기반 거리 측정(PBR) 을 모두 지원합니다. |
8.8.1 모드-0
스텝 모드 0의 목적은 이니시에이터 분수 주파수 오프셋(FFO)이라는 값을 계산할 수 있도록 하는 것입니다.
Channel Sounding 장치에서 생성되는 신호의 주파수는 주파수, 파장 및 위상 간의 관계를 고려할 때 Bluetooth Channel Sounding 작동 방식에서 중요한 구성 요소입니다. 그러나 생성된 신호의 주파수가 의도한 주파수와 얼마나 가깝게 일치하는지는 다양하며 어느 정도의 부정확성은 항상 예상할 수 있습니다.
FFO는 리플렉터 주어진 목표 주파수를 생성할 때 이니시에이터 얼마나 다른지를 측정한 값입니다. FFO 계산에는 리플렉터 수신한 CS 톤의 주파수와 이니시에이터 8.5.4 모드-0 FAE 테이블 요청 제어 절차 중에 획득한 리플렉터모드-0 FAE 테이블이 포함됩니다.
FFO는 이니시에이터 리플렉터 간의 차이를 보정하고 궁극적으로 결과의 정확성을 향상시키기 위해 계산에 사용됩니다.
그림 44는 모드 0 단계에서 이니시에이터 리플렉터 전송하는 패킷과 톤을 보여줍니다.
그림 44 - 모드 0에서의 패킷 및 톤 전송
블루투스 코어 사양 다이어그램에 표시되고 레이블이 지정된 시간 슬롯을 정의합니다. 레이블과 그 의미는 표 10에 나와 있습니다.
| T_SY | 동기화 시퀀스 시간입니다. |
| T_RD | 전송 감속 시간. 이 시간은 5μs이며 송신기 RF 채널에서 에너지를 제거하는 데 사용됩니다. |
| T_IP1 | 이니시에이터전송 종료와 리플렉터 전송 시작 사이의 막간 시간입니다 리플렉터 기간은 10μs에서 145μs 사이이며 기능 교환 절차에서 결정됩니다. |
| T_GD | 보호 시간. 항상 10μs입니다. |
| T_FM | 주파수 측정 시간. 모드-0 단계의 경우 항상 80μs입니다. |
표 10 - CS 단계 시간 슬롯
모든 CS 하위 이벤트는 하나 이상의 모드 0 단계로 시작됩니다.
8.8.2 모드-1
모드 1 단계에서는 왕복 시간 측정하기 위해 CS_Sync 패킷을 교환합니다. 그림 45는 이 단계 모드에 대해 정의된 패킷 교환 및 시간 슬롯을 보여줍니다.
그림 45 - 모드-1에서의 패킷 교환왕복 시간(RTT)))
왕복 시간 계산을 위해 이니시에이터는 CS_Sync 패킷을 전송할 때 타임스탬프를 캡처하고 리플렉터로부터 CS_Sync 패킷을 수신할 때 또 다른 타임스탬프를 캡처합니다. Bluetooth 핵심 specification은 각각 다른 정확도를 제공하는 여러 타임스탬프 방법을 정의합니다.
8.8.3 모드-2
모드 2 단계는 위상 기반 거리 측정(PBR) ) 거리 측정 방법의 사용과 관련이 있습니다. 이니시에이터 리플렉터 각 장치가 동일한 주파수로 전송하는 CS 톤을 교환합니다. 위상 기반 거리 측정(PBR) ) 방법을 사용하는 경우 여러 개의 안테나가 관련될 수 있으며, 이는 그림 46에 표시된 시간 슬롯의 의미에 반영되어 있습니다.
그림 46 - 모드-2의 CS 톤 교환위상 기반 거리 측정(PBR)))
그림 46에 표시된 몇 가지 추가 시간 슬롯 레이블이 있으며 표 11에 설명되어 있습니다.
| T_SW | 안테나 전환을 위해 예약된 시간 구간 |
| T_PM | 위상 측정 톤을 전송하는 시간입니다. |
| T_IP2 | CS 톤 사이의 인터루드 기간입니다. |
| N_AP | 안테나 경로 수입니다. |
표 11 - 추가 위상 기반 거리 측정(PBR) ) 시간 슬롯 레이블
8.8.4 모드-3
모드 3 단계는 이니시에이터 왕복 시간(RTT) ) 계산과 위상 기반 거리 측정(PBR) ) 계산을 모두 한 번에 수행할 수 있는 기반을 제공합니다. 그림 47은 이 단계 모드에서 발생하는 CS_Sync 패킷과 CS 톤의 교환을 보여줍니다.
그림 47 - 모드 3 단계에서 교환되는 패킷 및 톤
8.9 모드 시퀀싱
CS 절차는 항상 두세 가지 모드가 혼합된 여러 CS 단계로 구성됩니다. 일반적으로 실행되는 단계가 많을수록 거리 계산을 위해 더 많은 데이터를 수집하고 더 나은 결과를 얻을 수 있습니다. 실행되는 CS 절차, CS 이벤트, CS 하위 이벤트 및 CS 단계의 수와 사용되는 단계 모드의 조합은 애플리케이션에 의해 구성됩니다. 이를 모드 시퀀싱이라고 합니다.
모드 0은 항상 포함되며 모든 CS 하위 이벤트는 하나, 둘 또는 세 개의 연속된 모드 0 단계로 시작해야 합니다. 한 단계 시퀀스에는 최소 하나, 최대 두 개의 다른 모드가 있어야 합니다. 그러나 모든 조합이 허용되는 것은 아니며 블루투스 코어 사양 허용되는 조합을 정의합니다. 주어진 구성에서 선택한 모드 0이 아닌 모드 중 하나는 메인 모드로, 다른 하나는 서브 모드로 지정됩니다(있는 경우). 이러한 용어의 의미와 모드 순서에 미치는 영향에 대한 자세한 내용은 블루투스 코어 사양 확인할 수 있습니다.
표 12에는 허용되는 모드 0이 아닌 조합이 나와 있습니다.
| 메인_모드 | Sub_Mode |
|---|---|
| 모드-1 | 없음 |
| 모드-2 | 없음 |
| 모드-3 | 없음 |
| 모드-2 | 모드-1 |
| 모드-2 | 모드-3 |
| 모드-3 | 모드-2 |
표 12 - 허용되는 모드 0이 아닌 모드 조합.
일반적으로 단계 모드 시퀀싱은 이 패턴을 따릅니다:
- 하나 이상의 모드 0 단계가 하위 이벤트를 시작합니다.
- 그런 다음 Channel Sounding 구성 절차 중에 지정된 범위에 속하는 n개의 메인 모드 단계가 무작위로 선택되는 일련의 메인 모드 단계가 이어집니다.
- 하나의 서브모드 단계는 n개의 메인 모드 단계의 순서를 따릅니다.
그림 48은 그 예를 보여줍니다.
그림 48 - 구성 매개변수가 있는 스텝 모드 시퀀스 예시
8.10 채널 및 채널 선택
6.1 주파수 대역 섹션에서는 Bluetooth LE 2.4GHz 주파수 대역을 각각 2MHz 폭의 40개 채널로 나누는 방법에 대해 설명합니다. 섹션 7.8 논리적 전송에서는 링크 Layer 사양에 정의된 다양한 논리적 전송이 채널을 선택하는 방법에 대해 설명합니다. 블루투스 Channel Sounding 두 가지 측면에서 다른 접근 방식을 취합니다.
8.10.1 RF 채널
Bluetooth Channel Sounding 링크 Layer 논리 전송이 사용 중인 경우와 마찬가지로 2.4GHz 비면허 대역에서 작동합니다. 그러나 이 대역은 1MHz 폭의 79개 채널로 나뉘며, 이 중 72개 채널을 Channel Sounding 사용할 수 있습니다. 이러한 채널의 배열은 LE 기본 광고 채널을 피할 수 있도록 합니다.
표 13에는 채널 channel sounding 채널, 채널 인덱스 값 및 channel sounding 중에 각 채널을 사용할 수 있는지 여부가 나와 있습니다.
| CS 채널 색인 | RF 중심 주파수 | 허용됨 |
|---|---|---|
| 0 | 2402MHz | 아니 |
| 1 | 2403 MHz | 아니 |
| 2 | 2404MHz | 예 |
| ... | ... | ... |
| 22 | 2424MHz | 예 |
| 23 | 2425MHz | 아니 |
| 24 | 2426MHz | 아니 |
| 25 | 2427 MHz | 아니 |
| 26 | 2428MHz | 예 |
| ... | ... | ... |
| 76 | 2478 MHz | 예 |
| 77 | 2479 MHz | 아니 |
| 78 | 2480MHz | 아니 |
표 13 - CS 채널 인덱스 및 RF 물리적 채널
일반적인 2MHz가 아닌 1MHz의 채널 폭을 사용하면 약 150미터까지는 거리 모호성 (8.4.1 위상 기반 거리 측정 설명된 대로)이 발생하지 않습니다. 이는 Bluetooth Channel Sounding 설계된 애플리케이션 유형에 충분합니다.
8.10.2 채널 필터링
적응형 주파수 호핑(AFH)은 7.4 채널 선택 섹션에서 설명했습니다. AFH의 적응적 측면에는 디바이스가 각 RF 채널의 성능을 측정하고 특정 채널의 사용 여부에 관한 정보를 통신 디바이스 간에 공유하는 것이 포함됩니다. 이를 통해 디바이스는 자신이 작동하는 RF 환경에 적응하고 과도한 수준의 간섭이 발생하는 채널을 피할 수 있습니다.
블루투스 Channel Sounding 같은 이유로 채널 인덱스 필터 비트 맵을 유지합니다. 맵의 각 채널은 포함 또는 제외로 표시됩니다. 채널 선택 프로세스는 제외로 표시된 채널이 선택되지 않도록 합니다. 이니시에이터 리플렉터 링크 Layer Channel Sounding 채널 맵 업데이트 절차를 사용하여 RF 채널 성능 정보를 서로 공유합니다.
8.10.3 채널 선택 및 주파수 호핑
그림 49에 표시된 것처럼 각 CS 단계가 실행되기 직전에 채널이 선택됩니다.
그림 49 - 단계 실행 전 주파수 호핑
Bluetooth 핵심 specification에는 Bluetooth Channel Sounding 사용할 수 있는 세 가지 채널 선택 알고리즘이 정의되어 있습니다. 이를 CSA #3a, CSA #3b 및 CSA #3c라고 합니다.
CSA #3a는 모드-0 단계에서 사용할 채널을 선택하는 용도로만 사용됩니다.
CSA #3b와 CSA #3c는 모두 모드 0이 아닌 단계와 함께 사용하도록 설계되었지만 CS 절차 중에는 둘 중 하나만 사용할 수 있습니다.
CSA #3a와 CSA #3b는 매우 유사한 방식으로 작동합니다. 각각은 채널 맵에 포함된 것으로 표시된 모든 채널의 인덱스가 포함된 채널 목록을 사용합니다. 채널 목록은 channel sounding 시작될 때 셔플되며, 채널 선택은 셔플된 목록에서 각 채널을 한 번에 하나씩 사용하며 각 채널은 한 번만 사용됩니다. CSA #3a의 규칙은 셔플 목록의 모든 채널 인덱스가 사용되면 관련 채널 목록이 다시 생성되고 재편성되어 다시 사용이 시작된다는 것입니다. CSA #3b는 셔플된 목록이 다시 생성되기 전에 여러 번 반복될 수 있도록 허용합니다.
CSA #3c는 CSA #3b와 상당히 다르며 더 복잡하지만 일부 상황에서는 반사된 신호 경로를 감지하는 데 몇 가지 이점을 제공할 수 있습니다. 자세한 내용은 Bluetooth 핵심 specification을 참조하세요. CSA #3c에 대한 지원은 선택 사항입니다.
8.11 안테나 전환 및 안테나 경로
디바이스에는 위상 기반 거리 측정 중에 사용하기 위해 최대 4개의 안테나 배열이 있을 수 있습니다. 장치 중 하나의 안테나에서 다른 장치의 안테나 중 하나로 전송하는 것이 안테나 경로를 구성합니다. 최대 4개의 안테나 경로가 허용되며, 이로 인해 표 14와 같이 각 이니시에이터 및 리플렉터 안테나 어레이 크기 순열이 8개 목록으로 제한됩니다.
| 안테나 구성 인덱스(ACI) | 디바이스 A의 안테나 수 | 디바이스 B의 안테나 수 | 안테나 경로 수(N_AP) |
|---|---|---|---|
| 0 | 1 | 1 | 1 |
| 1 | 2 | 1 | 2 |
| 2 | 3 | 1 | 3 |
| 3 | 4 | 1 | 4 |
| 4 | 1 | 2 | 2 |
| 5 | 1 | 3 | 3 |
| 6 | 1 | 4 | 4 |
| 7 | 2 | 2 | 4 |
표 14 - 안테나 어레이 크기 순열 및 안테나 경로
다음 그림은 서로 다른 두 가지 안테나 구성과 관련 안테나 경로의 예를 보여줍니다.
안테나 스위칭은 모드-2 및 모드-3 단계에서 CS 톤을 전송하는 동안 이루어집니다. 이는 그림 46과 그림 47에 표시된 시간 슬롯 지속 시간에 대한 공식에서 N_AP(안테나 경로 수)라는 용어에 반영되어 있습니다.
8.12 RTT와 정확도
진공 상태에서의 빛의 속도는 초당 299,792,458미터입니다. 즉, 빛은 마이크로초라는 짧은 시간 동안 거의 300미터를 이동합니다. 물론 전파도 빛의 속도로 이동합니다.
따라서 왕복 시간(RTT) ) 방식을 사용할 때 이니시에이터ToD 및 ToA 타임스탬프가 캡처되는 정확도는 매우 중요합니다. 캡처된 타임스탬프의 아주 작은 오차는 결과 거리 계산에서 상당한 오차로 이어질 수 있습니다.
거리 추정을 위해 충분한 정확도로 타임스탬프를 획득하는 것은 엔지니어에게 상당한 도전 과제입니다. Bluetooth 핵심 specification에는 몇 가지 접근 방식이 설명되어 있습니다.
- 액세스 주소 액세스 주소 CS_Sync 패킷의 첫 번째 필드이며 길이는 32비트입니다. 타임스탬프 방법 중 하나는 액세스 주소 수신된 시간을 캡처하는 것이지만, 정확히 어떻게 해야 하는지에 대한 세부 사항은 구현에 맡겨져 있습니다.
- 정밀 시간 추정: 부분적인 타이밍 추정치에 도달하는 방법에는 두 가지가 있는데, 어느 것이 액세스 주소 도착을 사용하는 것보다 더 정확할 가능성이 높습니다 주소 일반적으로 분수 방법은 매우 작은 타이밍 오류를 확인하기 위해 CS_Sync 패킷의 끝에 배치할 수 있는 필드를 분석하는 것입니다. 이를 위해 두 개의 필드 중 하나를 CS_Sync 패킷에 추가할 수 있습니다.
- 무작위 시퀀스: 수신 신호의 샘플링은 수신 신호의 위상과 동기화되지 않을 가능성이 높으며, 이는 작은 타이밍 오류의 원인이 될 수 있습니다. 무작위 시퀀스 필드를 분석하면 실제 샘플링 포인트와 최적의 샘플링 포인트 간의 차이를 파악할 수 있습니다. 이를 통해 타임스탬프 값의 정확도를 개선할 수 있습니다.
- 사운드 시퀀스: 1과 0이 번갈아 가며 나오는 시퀀스입니다. GFSK로 변조되어 전송될 때 1과 0을 나타내는 심볼은 서로 다른 주파수를 가지며 두 개의 다른 톤을 구성하는 것으로 생각할 수 있습니다. 두 톤 사이의 위상차를 분석하면 타이밍 오류를 측정할 수 있으며, 이를 통해 타임스탬프를 개선할 수 있습니다.
일반적으로 일련의 단계를 거쳐 측정한 값은 값의 분포를 분석하여 타임스탬프의 정확도를 높이는 데 도움이 될 수 있습니다.
8.13 보안
거리 측정 시스템의 보안에는 몇 가지 새로운 과제가 있습니다. 일반적으로 보호해야 할 위협은 악성 디바이스가 신뢰할 수 있는 두 디바이스 중 하나(특히 블루투스 Channel Sounding 경우 이니시에이터 )를 속여 다른 신뢰할 수 있는 디바이스가 실제보다 더 가까이 있다고 속이는 것으로, 자동차 도난과 같은 명백한 잠재적 결과를 초래할 수 있습니다.
다음 두 섹션에서는 두 가지 유형의 공격에 대해 간략하게 설명합니다. 8.13.3 Bluetooth Channel Sounding 보안 기능 섹션에서는 이러한 유형의 공격(및 기타 공격)으로부터 보호하는 Bluetooth Channel Sounding 기능을 요약하여 설명합니다.
8.13.1 신호위조(Spoofing)
한 종류의 공격은 신뢰할 수 있는 디바이스 중 하나를 공격 디바이스가 모방하는 것입니다. 리플레이 공격은 이러한 공격의 한 예로, 악성 디바이스가 정상적이고 성공적인 대화 중에 신뢰할 수 있는 디바이스 간에 교환되는 패킷을 기록하는 것을 포함합니다. 그런 다음 나중에 기록된 패킷 중 일부를 사용하여 신뢰할 수 있는 디바이스가 마치 정상적인 디바이스와 대화 중인 것처럼 동작하게 하는 응답을 보냅니다.
그림 52에서 앨리스와 밥은 보안이 취약한 전용 무선 거리 측정 시스템에서 신뢰할 수 있는 두 개의 디바이스를 나타냅니다. 공격자는 악성 디바이스로, 이 첫 번째 공격 단계에서는 단순히 앨리스와 밥 사이의 교환을 수신하고 패킷을 기록합니다.
그림 53에서 공격의 2단계는 1단계에서 기록된 패킷을 사용하여 앨리스가 신뢰할 수 있는 디바이스인 밥과 교환한다고 생각하도록 속이는 것입니다.
그림 52 - 리플레이 공격 파트 1
그림 53 - 리플레이 공격 파트 2
Bluetooth Channel Sounding 이러한 종류의 공격에 대한 여러 가지 보호 기능을 갖추고 있습니다.
8.13.2 릴레이 공격
또 다른 유형의 잠재적 공격은 릴레이 공격이라고 합니다. 이는 물리적 계층에서 작동하는 중간자(MITM) 공격 , 신뢰할 수 있는 장치에서 다른 장치로 신호를 중계하지만 실시간으로 어떤 방식으로든 신호를 조작하여 장치가 실제보다 가까운 것처럼 보이게 합니다.
그림 54 - 릴레이 공격
Bluetooth Channel Sounding 이러한 종류의 공격에 대한 여러 가지 보호 기능을 갖추고 있습니다.
8.13.3 Bluetooth Channel Sounding 보안 기능
Bluetooth Channel Sounding 광범위한 보안 기능이 포함되어 있으며, 일반 액세스 프로필은 Channel Sounding 적용되는 4가지 보안 수준을 정의합니다.
Bluetooth Channel Sounding 정의된 보안 기능의 전체 목록은 네 가지 범주로 그룹화할 수 있습니다.
8.13.3.1 PBR 및 RTT 방식을 결합하여 사용하기
블루투스 Channel Sounding 위상 기반 거리 측정 방법과 왕복 타이밍 방법을 모두 지원합니다. 스텝 모드 시퀀싱의 유연성 덕분에 애플리케이션에서 두 가지 방법을 동시에 사용할 수 있습니다. 이를 통해 서로 다른 두 가지 방법으로 생성된 데이터를 교차 검사할 수 있습니다.
두 가지 방법을 동시에 공격하여 channel sounding 신호의 위상과 계산된 왕복 시간을 모두 조작하여 오해의 소지가 있고 일관된 결과를 제공하는 공격의 복잡성은 보안 전문가들에 의해 매우 높은 것으로 간주됩니다. 이것만으로도 공격을 탐지할 수 있는 강력한 메커니즘입니다.
Bluetooth Channel Sounding 보안에는 결정론적 랜덤 비트 생성기(DRBG)라는 함수의 specification이 포함되어 있습니다. 이 함수를 반복적으로 호출하면 일반 관찰자가 보기에는 무작위적이고 예측할 수 없는 값의 시퀀스가 생성됩니다.
그러나 DRBG는 Channel Sounding 보안 시작 절차 중에 두 장치에서 설정한 초기화 벡터(CS_IV), 인스턴스화 논스 (CS_IN) 및 개인화 벡터(CS_PV) 값을 사용하며 이러한 DRBG 매개 변수에 대해 동일한 값을 사용하는 두 장치는 함수에 대한 일련의 호출에서 정확히 동일한 출력 시퀀스를 생성합니다. 따라서 이 시퀀스는 세 가지 DRBG 파라미터를 보유한 디바이스에서는 결정적이지만 그렇지 않은 디바이스(공격자 등)에서는 예측할 수 없습니다. CS_IV, CS_IN 및 CS_PV는 channel sounding 수행될 때마다 다른 값을 가지며, 암호화된 LE-ACL 연결을 통해 부분 값을 교환하여 생성되므로 공격자는 사용 중인 DRBG 매개변수 값을 알지 못한다고 안전하게 가정할 수 있습니다.
DRBG는 비트 스트림의 콘텐츠와 전체 전송 패턴을 모두 무작위화하는 데 사용됩니다. 블루투스 코어 사양 channel sounding 비트 스트림의 영역을 무작위로 선택한 다음 무작위로 생성된 비트 패턴으로 설정하도록 지정하고 있으며, 두 경우 모두 DRBG를 사용합니다. 또한 톤 확장 슬롯이라고 하는 모드 2 및 모드 3 단계에 대해 정의된 시간 슬롯이 있으며 이 슬롯 동안 전송이 이루어지는지 여부는 DRBG 호출에 따라 달라집니다.
이 두 가지 방식으로 DRBG를 사용한다는 것은 이니시에이터 리플렉터 모두 전송 내용과 톤 확장 슬롯에 전송된 톤의 유무를 무작위로 지정할 수 있다는 것을 의미합니다. DRBG는 정의상 결정론적이기 때문에 이니시에이터 리플렉터 (각각 CS_IV, CS_IN 및 CS_PV를 소유한)는 모두 무엇을 예상할 수 있는지 알 수 있지만 공격자는 알 수 없습니다. channel sounding 장치 중 하나에서 예상치 못한 비트 값이나 예상치 못한 전송(또는 예상치 못한 전송 부재)을 발견하면 이는 잠재적 공격으로 간주됩니다.
리플레이 공격은 두 장치가 Channel Sounding 수행할 때마다 전송되는 패킷과 톤의 순서가 달라지고, 단순히 녹음된 이전 일련의 교환을 재생하는 것만으로도 쉽게 탐지될 수 있기 때문에 성공할 수 없습니다.
합법적인 송신 장치로부터 부분적으로 수신된 무선 심볼의 값을 예측하고 해당 심볼의 전체 버전을 조기에 중계하여 합법적인 수신자가 왕복 시간과 거리를 잘못 계산하도록 타이밍을 조작하는 MITM(man-in-the-middle)을 이용한 물리적 Layer 공격은 여러 가지 알려진 공격이 존재합니다. 공격자의 신호는 일반적으로 증폭되어 대상 디바이스가 다중 경로 전파로 인한 반사로 간주될 수 있는 약한 원본 신호 대신 조작된 신호를 기본 신호로 간주하고 무시하도록 합니다. 이 공격은 심볼의 일반적인 전체 지속 시간을 이용해 타이밍을 앞당기며, 지속 시간이 긴 심볼은 짧은 심볼보다 이 유형의 공격에 더 취약합니다.
대역폭 비트 주기 제품 값이 2.0인 LE 2M 2BT PHY는 다른 PHY와 관련된 펄스보다 짧은 지속 시간을 갖는 심볼 펄스를 생성하므로 이러한 유형의 공격 위험이 줄어듭니다.
릴레이 공격에 대한 보호 수단으로 사용할 수 있는 또 다른 기능 SNR 제어입니다.
SNR 제어를 사용하면 수신기 미리 합의한 양의 임의의 이니시에이터 일부 신호에 혼합할 수 있습니다. 심볼 조작 릴레이 공격은 공격자가 심볼의 전체 지속 시간보다 훨씬 짧은 시간 내에 정상적인 신호를 매우 빠르게 분리하여 조작할 수 있어야 합니다. 신호에 노이즈를 주입하면 공격자가 분석을 완료하기가 더 어려워지고 느려지므로 공격 성공 가능성이 줄어듭니다. 반면, 이니시에이터 리플렉터 장치는 사전에 SNR이 합의되어 있어 인위적으로 추가된 노이즈를 쉽게 필터링할 수 있습니다.
Bluetooth Channel Sounding 사양에는 공격 탐지 시스템에 대한 설명과 공격이 진행 중일 확률을 보고하기 위한 표준화된 메트릭인 NADM(정규화된 공격 탐지 메트릭)이 포함되어 있습니다. NADM은 표 15에 표시된 것처럼 관련 형용사 용어와 함께 슬라이딩 스케일을 사용합니다.
| NADM 값 | 묘사 |
|---|---|
| 0x00 | 공격 가능성은 극히 낮음 |
| 0x01 | 공격 가능성은 매우 낮음 |
| 0x02 | 공격 가능성 낮음 |
| 0x03 | 공격 가능 |
| 0x04 | 공격 가능성 높음 |
| 0x05 | 공격 가능성 매우 높음 |
| 0x06 | 공격 가능성 매우 높음 |
| 0xFF | 랜덤 시퀀스 또는 사운드 시퀀스가 없는 왕복 시간(RTT) ) 유형의 기본값을 알 수 없습니다. |
표 15 - NADM 값
예상치 못한 비트 값이나 위상 조정, 비교가 가능한 기준 신호의 특성 등이 공격 가능성을 나타내는 지표는 Bluetooth 핵심 specification에 나와 있습니다.
8.14 거리 측정 애플리케이션
Bluetooth Channel Sounding 자체는 거리 값을 계산하지 않습니다. 대신 독점적인 거리 계산 알고리즘에 사용할 수 있는 타이밍 정보, 진폭 및 위상 값(IQ 샘플)을 포함한 원시 자료를 애플리케이션에 제공합니다. 표준 알고리즘은 상호 운용성과 관련이 없기 때문에 정의되어 있지 않으며, 제조업체는 알고리즘이 달성할 수 있는 결과의 품질을 통해 자유롭게 차별화할 수 있습니다.
Bluetooth Channel Sounding 사용하는 애플리케이션에는 다음을 포함하되 이에 국한되지 않는 여러 가지 책임이 있습니다:
- Bluetooth Channel Sounding 제공하는 데이터를 사용하여 거리 측정을 계산하는 알고리즘을 구현합니다.
- 사용할 스텝 모드와 해당 시퀀싱 및 타이밍 매개변수 등 애플리케이션의 요구와 우선순위에 적합한 구성을 선택합니다. 여기에는 생성할 Channel Sounding 측정 데이터의 양과 지연 시간 등의 문제를 균형 있게 조정하는 것이 포함됩니다.
- Host 컨트롤러 인터페이스(HCI) 명령을 사용하여 섹션 5 Bluetooth Channel Sounding 링크 Layer 제어 절차에 설명된 제어 절차를 시작하고 진행합니다.
- GAP에 정의된 Channel Sounding 보안 수준 중 하나를 선택하고 보안 요구 사항을 염두에 두고 Channel Sounding 구성합니다.
- NADM 값으로 표현되는 공격 탐지 정보를 애플리케이션 적합한 방식으로 처리합니다.
Bluetooth Channel Sounding specification은 정확하고 안전한 거리 측정 애플리케이션을 위한 엄격하고 표준적이며 상호 운용 가능한 프레임워크 역할을 하는 동시에 개발자가 특정 우선순위에 따라 애플리케이션을 최적화할 수 있는 유연성을 제공합니다.
9. 등시 적응 레이어
9.1 기본 사항
ISOAL(동시 적응 Layer)의 목적은 주로 오디오 장치와 관련된 연결 및 방송 등시성 통신에 영향을 미칠 수 있는 잠재적인 문제를 해결하기 위한 것입니다. 다른 등시성 통신 용도에도 적용될 수 있습니다.
9.1.1 오디오 샘플링 101
디지털 오디오는 아날로그 오디오 신호를 샘플링하고 샘플링된 오디오에 코덱을 적용하여 디지털 샘플 데이터를 압축 및 기타 처리한 후 저장하거나 Bluetooth LE 오디오의 경우 전송하는 방식으로 작동합니다. 인코딩된 디지털 오디오 데이터를 읽거나 수신하면 데이터를 디코딩하는 데 사용되는 코덱으로 프로세스가 역전되어 일련의 디지털 샘플을 생성한 다음 원래 아날로그 오디오를 (대략) 재현하는 데 사용됩니다. 그림 55는 오디오 신호의 샘플링, 인코딩 및 전송에 관련된 단계와 인코딩된 오디오 데이터를 수신하고 디코딩한 후 최종적으로 렌더링하는 역단계에 관련된 단계를 보여줍니다.
그림 55 - 오디오 처리 단계
오디오 코덱의 주요 목표 중 하나는 오디오 데이터의 크기를 줄여 제한된(그리고 귀중한!) 대역폭을 가진 링크를 통해 효율적으로 전송할 수 있도록 하는 것입니다. 샘플링에는 일정한 간격으로 신호의 진폭을 측정하고 기록하는 작업이 포함됩니다. 샘플이 기록되는 빈도를 샘플 레이트라고 합니다. 그림 56의 수직선은 곡선으로 표시된 연속적으로 가변적인 오디오 신호의 샘플을 나타냅니다. 이러한 일련의 샘플은 원본 아날로그 신호의 대략적인 표현을 만들어냅니다. 샘플을 더 자주 수집할수록(즉, 샘플 레이트가 높을수록) 근사치가 원본에 가까워지고 원본 오디오를 재현하는 과정을 역으로 수행할수록 결과와 체감 품질이 향상됩니다.
샘플링의 또 다른 차원은 비트 심도입니다. 샘플링할 때 신호의 진폭은 정수 값으로 표현해야 합니다. 한 가지 접근 방식은 가능한 진폭 값의 범위를 256개의 개별 진폭 대역으로 나누고 각각을 0에서 255 사이의 숫자로 표현하는 것입니다. 이 방식에서는 샘플링된 진폭 값이 속하는 대역을 기록하는 데 단일 샘플에 1바이트(8비트)만 필요하므로 비트 심도를 8비트라고 합니다. 가능한 진폭 범위를 더 세밀한 대역으로 나누면 샘플 값을 더 세밀하게 표현할 수 있으므로 잠재적으로 더 나은 품질의 결과를 얻을 수 있습니다. 예를 들어 비트 심도가 24비트이면 가능한 진폭 값의 범위를 0에서 16,777,215 범위의 정수로 표현할 수 있습니다. 그러나 각 샘플에는 3바이트가 필요하므로 비트 심도가 증가된 샘플링을 통해 생성되는 데이터의 양은 3배가 됩니다.
디지털 샘플링은 대용량의 데이터를 생성할 수 있습니다. 44.1kHz(CD 품질), 비트 심도 24의 속도로 샘플링된 3분짜리 노래를 예로 들어 보겠습니다. 계산을 해보면 전체 노래를 디지털 형식으로 표현하는 데 필요한 원시 샘플링 데이터의 양이 거의 24메가바이트에 달한다는 것을 알 수 있습니다. 컴퓨터의 4테라바이트 하드 드라이브에 데이터를 저장하는 것이 목적이라면 걱정할 필요가 없지만, 대역폭이 제한된 통신 링크를 통해 데이터를 전송할 때는 문제가 됩니다. 바로 이때 코덱이 등장합니다.
그림 56 - 연속 아날로그 신호를 나타내는 개별 샘플
9.1.2 코덱 및 프레임
Bluetooth LE 오디오에 사용되는 LC3와 같은 코덱은 원시 디지털 샘플 데이터를 원본 크기의 25% 미만으로 압축할 수 있습니다(단, 실제 결과는 원본 오디오 콘텐츠에 따라 크게 달라집니다). 이는 상당한 용량 절약입니다.
코덱은 일반적으로 일련의 연속된 샘플에서 발견되는 패턴을 인식하고 활용하는 방식으로 작동합니다. 이 원리를 설명하기 위해 아주 간단한 예를 들자면, 데이터 세트에 모두 동일한 값인 50으로 구성된 연속된 100개의 샘플 값이 포함되어 있는 경우 비트 심도가 8비트라고 가정하면 코덱은 이를 개별 샘플 목록[50,50,50...,50]이 포함된 원래 100바이트 시리즈가 아닌 [100,50]이 포함된 두 바이트로 표현할 수 있습니다. 분명히 코덱이 작동하려면 한 번에 하나의 샘플로 작업하는 것이 아니라 전체 샘플을 분석하고 인코딩해야 합니다(단일 샘플에서 발견할 수 있는 패턴이 많지 않습니다!).
코덱이 한 번에 분석하는 샘플의 모음을 프레임이라고 합니다. 프레임은 일반적으로 밀리초 단위로 측정되는 고정된 지속 시간을 가지며, 샘플 레이트에 따라 결정되는 수의 샘플을 포함합니다. 예를 들어, 샘플 레이트가 44.1KHz인 경우 10ms 프레임에는 4410개의 샘플이 포함됩니다.
오디오 제품마다 다른 프레임 길이를 사용할 수 있습니다. 10ms와 7.5ms가 일반적입니다. 한 장치에서 하나의 프레임 지속 시간으로 오디오( 소스)를 생성하고 다른 장치에서 오디오( 싱크)를 소비하지만 다른 프레임 지속 시간을 사용하는 경우 해결해야 할 문제가 있습니다. 바로 이때 ISOAL이 등장합니다.
9.2 프레임 형식 vs 비프레임 형식
디바이스가 등시성 통신을 사용하는 경우, 송신 디바이스와 수신 디바이스가 사용하는 프레임 지속 시간이 동일할 필요는 없습니다. 이로 인해 두 가지 상황이 발생할 수 있습니다:
- 첫 번째 디바이스에서 사용하는 프레임 지속 시간은 다른 디바이스에서 사용하는 프레임 지속 시간의 정확한 배수입니다.
- 첫 번째 디바이스에서 사용하는 프레임 지속 시간은 다른 디바이스에서 사용하는 프레임 지속 시간의 정확한 배수가 아닙니다.
첫 번째 상황에서는 더 큰 프레임 길이와 더 작은 프레임 길이 사이의 관계가 간단하며 둘 사이의 데이터 변환은 간단한 작업입니다. 하나 이상의 필수 링크 Layer PDU의 페이로드에 전송되는 데이터는 프레임이 해제 된 것으로 두 요구 사항 간의 프레임 길이 조정을 지원하기 위한 추가 데이터가 포함되지 않습니다.
두 번째로, 링크 Layer PDU는 더 큰 페이로드의 일부와 함께 해당 부분이 프레임의 시작인지, 프레임의 연속인지 또는 프레임의 끝인지를 나타내는 짧은 헤더 필드를 포함할 수 있습니다. 이와 같이 포맷된 데이터를 프레임이라고 합니다.
연결된 비동기 PDU와 브로드캐스트 비동기 PDU( 링크 Layer 의해 정의됨)에는 모두 LLID라는 필드가 포함되어 있습니다. LLID는 링크 Layer PDU의 페이로드에 프레임된 데이터가 포함되어 있는지 또는 프레임되지 않은 데이터가 포함되어 있는지를 나타냅니다. ISOAL은 데이터의 프레임 여부에 따라 링크 Layer 수신하는 데이터에 다른 프로세스를 적용합니다. 마찬가지로 프레임이 필요한지 여부는 상위 계층 SDU에서 수신하여 링크 Layer 링크 Layer 으로 전달하여 링크 Layer ISO PDU로 전송하는 데이터의 ISOAL 처리에 영향을 미칩니다.
9.3 단편화 및 재결합
데이터가 프레임되지 않은 경우 재조합은 하나 이상의 링크 Layer PDU의 페이로드에 포함된 일련의 하나 이상의 조각에서 단일 서비스 데이터 단위(SDU)를 생성합니다. 그런 다음 ISOAL은 SDU를 상위 계층으로 전달합니다. 이는 그림 57에 나와 있습니다.
그림 57 - 프레임되지 않은 ISO PDU의 재결합
상위 계층 SDU를 링크 Layer PDU에서 전송하기 위해 더 작은 페이로드로 분할해야 하고 프레이밍이 필요하지 않은 경우, 이 프로세스를 조각화라고 합니다. 이는 그림 58에 나와 있습니다.
그림 58 - 프레임되지 않은 ISO PDU를 생성하는 조각화
프레임되지 않은 PDU에는 헤더가 있으며, 이 헤더에는 그 뒤에 오는 데이터가 SDU의 시작, 이전 SDU의 연속 또는 이 SDU의 끝임을 나타내는 필드가 포함되어 있습니다. PDU에는 프레임되지 않은 SDU의 단일 조각만 포함됩니다.
9.4 세그먼트화 및 재조합
데이터가 프레임된 경우 재조립은 하나 이상의 링크 Layer PDU의 페이로드에 포함된 일련의 하나 이상의 세그먼트에서 단일 서비스 데이터 단위(SDU)를 생성합니다. 그런 다음 ISOAL은 SDU를 상위 계층으로 전달합니다. 이는 그림 59에 나와 있습니다.
그림 59 - 프레임형 ISO PDU의 재조립
상위 계층 SDU를 링크 Layer PDU에서 전송하기 위해 더 작은 페이로드로 분할해야 하고 프레이밍이 필요한 경우 이 프로세스를 세그먼테이션이라고 합니다. 이는 그림 60에 나와 있습니다.
그림 60 - 프레임 ISO PDU를 생성하는 세그멘테이션
프레임된 PDU 내의 세그먼트에는 헤더가 있으며, 이 헤더에는 그 뒤에 오는 데이터가 SDU의 시작, 이전 SDU의 연속 또는 이 SDU의 끝임을 나타내는 필드와 타이밍 오프셋 정보가 포함됩니다. PDU에는 프레임된 SDU의 여러 조각이 포함될 수 있습니다.
10. host 컨트롤러 인터페이스(HCI)
10.1 기본 사항
Host Controller 인터페이스(HCI)는 host controller 명령을 내리고 controller host 통신할 수 있는 표준화된 인터페이스를 정의합니다. specification은 여러 부분으로 나뉘는데, 첫 번째 부분은 특정 구현 메커니즘에 대한 고려 없이 기능적인 측면에서만 인터페이스를 정의하고, 다른 부분은 네 가지 가능한 물리적 전송 중 하나를 사용할 때 HCI를 구현할 수 있는 방법을 정의합니다.
HCI는 Bluetooth LE Bluetooth BR/EDR 모두에서 사용됩니다.
10.2 HCI 기능 specification
기능 인터페이스는 명령과 이벤트로 정의됩니다. 이는 본질적으로 host 컨트롤러 간에 교환할 수 있는 메시지입니다. 명령은 host 컨트롤러로, 이벤트는 컨트롤러에서 host 전송됩니다. 이벤트는 명령에 대한 응답일 수도 있고 원치 않는 메시지로 전송될 수도 있습니다. 그림 61을 참조하세요.
그림 61 - HCI 명령 및 이벤트
10.3 HCI 전송
네 가지 HCI 전송 유형은 다음과 같습니다:
- UART
- USB
- 보안 디지털(SD)
- 3선식 UART
10.3.1 UART 전송
host controller 모두 동일한 인쇄 회로 기판에서 UART를 사용하여 연결된 경우 UART를 사용하여 HCI 통신을 구현하는 데 HCI UART 전송을 사용할 수 있습니다. 5가지 패킷 유형에 기반한 프로토콜이 정의되어 있습니다. HCI 명령 패킷, HCI ACL 데이터 패킷, HCI 동기 데이터 패킷, HCI 이벤트 패킷 및 HCI ISO 데이터 패킷이 그것입니다.
RS232 구성 요구 사항이 지정되어 있습니다. 요약하면, UART 전송은 8개의 데이터 비트, 패리티 없음, 1개의 스톱 비트 및 RTS/CTS 흐름 제어를 사용합니다.
10.3.2 USB 전송
USB는 두 가지 방식으로 HCI 전송 수단으로 사용할 수 있습니다. 블루투스 컨트롤러는 USB 동글 내에 구현할 수 있습니다. 또는 제품 내부에서 USB를 사용하여 host 컨트롤러 구현을 연결할 수 있습니다.
USB 표준은 엔드포인트라고 하는 데이터를 보내거나 받을 수 있는 버퍼를 정의합니다. HCI USB 전송 사양은 존재할 것으로 예상되는 엔드포인트와 필수 또는 권장 속성을 나타냅니다.
10.3.3 Secure Digital(SD)
HCI SD 전송과 함께 사용하기 위한 프로토콜은 보안 디지털 협회(SDA)에서 정의하고 소유하고 있습니다. HCI SD 전송에 대한 Bluetooth 핵심 specification의 섹션은 주로 통신 아키텍처에 대한 개요와 함께 SDA가 소유한 외부 specification에 대한 참조로 구성되어 있습니다.
10.3.4 3선식 UART
3선식 UART HCI 전송 specification은 3선식으로 연결된 두 개의 UART 간에 HCI 명령 및 이벤트를 통신하기 위한 아키텍처와 프로토콜을 설명합니다. 안정성, 데이터 무결성, 링크 설정, 전원 관리 및 하드웨어 구성을 다룹니다.
10.4 HCI 예시
HCI 기능 인터페이스가 실제로 작동하는 모습을 보여주는 여러 가지 예는 다음과 같습니다.
10.4.1 비접촉식 AoA/AoD
그림 62는 컨트롤러 구성 중 HCI 명령 및 이벤트 교환을 보여줍니다. host 지원하는 패킷 전송을 준비하려면 방향 탐지 도착 각도를 사용하여 ( 도착각(Angle of Arrival) ) 또는 출발 각도( 출발각(Angle of Departure) ) 기술.
그림 62 - 무연결 도착각(Angle of Arrival)/출발각출발각(Angle of Departure) 컨트롤러 구성
10.4.2 LE 경로 손실 모니터링
LE 경로 손실 모니터링은 LE 전력 제어 기능 일부입니다. 연결된 피어 디바이스가 사용하는 전송 전력을 관리하여 수신기 대한 최적의 전력 범위 내에서 유지하려는 디바이스는 이 기능 사용할 수 있습니다.
그림 63은 host LE 경로 손실 모니터링을 구성하고 활성화하는 데 필요한 HCI 명령을 전송하는 모습을 보여줍니다. 모니터링이 활성화된 후 컨트롤러는 경로 손실 데이터가 포함된 LE 경로 손실 임계값 이벤트를 host 전송합니다.
그림 63 - LE 경로 손실 모니터링
10.4.3 액티브 스캐닝
액티브 스캔은 레거시 광고 활용하고 단일 광고 패킷에 포함될 수 있는 것보다 더 많은 데이터를 통신해야 하는 주변기기에서 지원됩니다. 이 주제에 대한 자세한 내용은 14.3 검색 섹션을 참조하세요.
그림 64는 장치(디바이스 A)의 host 구성 요소가 활성 스캔을 수행하도록 컨트롤러를 구성한 다음 별도의 명령으로 이를 활성화하여 스캔을 시작하는 것을 보여줍니다. 액티브 스캔을 수행하도록 구성된 디바이스 A의 링크 Layer 다른 디바이스로부터 ADV_IND와 같은 스캔 가능한 광고 패킷을 수신하면, 이 디바이스는 SCAN_REQ PDU를 전송하고 다른 디바이스로부터 SCAN_RSP PDU를 다시 수신하는 방식으로 응답합니다. 그런 다음 원본 광고 패킷의 콘텐츠와 스캔 응답이 일련의 HCI LE 광고 보고서 이벤트를 통해 디바이스 A의 Host 전달됩니다.
그림 64 - 활성 스캔
11. 논리적 링크 제어 및 적응 프로토콜
11.1 기본 사항
L2CAP(논리적 링크 제어 및 적응 프로토콜)는 프로토콜 멀티플렉싱, 흐름 제어, 서비스 데이터 단위(SDU)의 분할 및 재조립을 담당합니다.
L2CAP은 채널이라는 개념을 사용해 스택의 계층 사이를 통과하는 패킷 시퀀스를 구분합니다. 고정 채널은 설정이 필요 없고 즉시 사용 가능하며 특정 상위 계층 프로토콜과 연결됩니다. 채널은 지정된 프로토콜 서비스 멀티플렉서(PSM) 값을 통해 동적으로 생성되어 프로토콜과 연결될 수도 있습니다.
그림 65는 L2CAP의 주요 기능을 보여줍니다.
그림 65 - L2CAP 주요 기능
11.2 L2CAP 및 프로토콜 멀티플렉싱
스택의 L2CAP 위에는 ATT(속성 프로토콜) 및 SMP(보안 관리자 프로토콜)와 같은 고유한 프로토콜을 사용하는 Layer이 있습니다. L2CAP 프로토콜 멀티플렉싱은 SDU가 스택을 통해 적절한 Layer으로 전달되어 처리되도록 합니다.
L2CAP 채널이 속성 프로토콜을 처리할 때는 ATT용으로 예약된 고정 채널을 사용하며, 이 경우 강화되지 않은 ATT 베어러로 작동하거나 하나 이상의 동적 채널을 사용하여 각각 강화된 ATT 베어러로 작동한다고 할 수 있습니다. 강화되지 않은 ATT 베어러는 한 번에 하나씩 순차적으로 실행되는 ATT 트랜잭션을 지원합니다. 향상된 ATT 베어러는 병렬 L2CAP 채널 내에서 순차적으로 실행되는 병렬 ATT 트랜잭션을 지원합니다. 12. 속성 프로토콜을 참조하세요.
11.3 L2CAP 및 흐름 제어
흐름 제어는 스택의 한 Layer에서 패킷을 생성하는 속도가 같은 스택 또는 원격 장치의 Layer에서 패킷을 처리하는 속도를 초과하지 않도록 하는 것과 관련이 있습니다. 흐름 제어가 없으면 버퍼 오버플로와 같은 문제가 발생할 위험이 있습니다.
신용 기반 흐름 제어는 흐름 제어를 위한 여러 가지 접근 방식 중 하나입니다. 간단히 설명하면 다음과 같이 작동합니다:
- 송신 장치는 데이터 손실 없이(예: 버퍼 오버플로우) 처리할 수 있는 PDU 수를 통해 수신 장치의 용량을 알고 있습니다. 이 용량 정보는 구성을 통해 또는 두 장치 간에 이루어진 교환을 통해 수집됩니다. 데이터 전송 시작합니다.
- 송신기 수신기 용량 제한에 카운터를 설정합니다. 송신기 PDU를 전송할 때마다 카운터가 감소합니다. 카운터 값이 0에 도달하면 송신기 수신기 최대 용량에 도달했음을 인식하고 수신기 백로그를 처리하는 동안 일시적으로 추가 PDU 전송을 중지합니다.
- 수신기 버퍼에서 하나 이상의 PDU를 읽고 처리한 후, 해당 크레딧을 송신기 다시 보내면 송신기 이를 사용하여 카운터를 증가시킵니다. 카운터가 0이 아닌 값이면 송신기 계속해서 추가 PDU를 전송할 수 있습니다.
L2CAP은 주로 흐름 제어와 관련된 몇 가지 작동 모드를 정의합니다.
예를 들어, L2CAP 미보강 ATT 베어러를 통한 ATT는 흐름 제어를 제공하지 않는 기본 L2CAP 모드를 사용합니다. 따라서 ATT를 신뢰할 수 없으며, 애플리케이션은 전송된 ATT PDU가 수신 장치에 의해 손실될 수 있는 가능성을 수용해야 합니다. 알림과 같이 승인되지 않은 PDU의 경우, 송신 디바이스는 링크 Layer 승인 덕분에 원격 디바이스의 스택에서 PDU를 수신했는지 여부를 알 수 있지만 스택 상단에 있는 수신 애플리케이션에 성공적으로 전달되었는지 여부를 알 수 없습니다.
L2CAP 강화 ATT 무기명을 통한 ATT는 흐름 제어 기능을 제공하는 향상된 신용 기반 흐름 제어 모드를 사용합니다. 따라서 EATT는 신뢰할 수 있는 것으로 간주될 수 있습니다.
11.4 L2CAP 세그먼트화 및 재조합
L2CAP 위와 아래의 레이어에는 해당 레이어에서 생성된 유형의 PDU가 허용되는 최대 크기를 지정하는 최대 전송 단위(MTU) 크기가 적용됩니다. 예를 들어, ATT_MTU 파라미터는 ATT PDU가 될 수 있는 최대 크기를 정의합니다.
L2CAP 자체와 스택의 위 또는 아래 레이어는 서로 다른 MTU 크기를 가질 수 있으며, 따라서 인접한 레이어가 처리할 수 있는 일련의 작은 부품으로 일부 PDU/SDU를 분할하거나 반대로 일련의 관련 작은 부품을 전체 PDU/SDU로 재조립해야 할 수 있습니다. 이러한 프로세스를 상위 레이어와 관련하여 L2CAP가 적용하는 것을 분할 및 재조립이라고 하며, L2CAP와 하위 레이어와의 관계에서 이와 동일한 프로세스를 조각화 및 재결합이라고 합니다.
12. 속성 프로토콜
12.1 기본 사항
속성 프로토콜(ATT)은 두 개의 장치에서 사용되며, 하나는 다음 역할을 수행합니다. 클라이언트 역할을 하는 장치와 서버 역할을 하는 장치입니다. 서버는 속성이라고 하는 일련의 복합 데이터 항목을 노출합니다. 속성은 서버에 의해 속성 테이블이라는 색인 목록으로 구성됩니다.
각 속성에는 핸들, UUID(범용 고유 식별자), 값 및 권한 집합이 포함되어 있습니다.
- 핸들은 ATT 클라이언트 속성 테이블의 특정 항목을 참조할 수 있는 고유 인덱스 값입니다.
- UUID는 속성의 유형을 식별합니다.
- 권한 필드는 읽기, 쓰기 또는 두 가지 형태의 액세스가 모두 허용되는지 여부와 액세스가 허용되기 위해 충족되어야 하는 기타 보안 조건을 나타내는 플래그 집합입니다.
- Bluetooth SIG 학습 가이드 Bluetooth LE 보안 이해 에서 속성 권한에 대한 자세한 정보를 확인할 수 있습니다.
- 속성 값 필드는 속성 값을 포함하는 바이트 배열입니다. 데이터 유형과 의미 측면에서 바이트 배열을 해석하는 것은 스택의 상위 Layer에서 다뤄야 할 문제입니다.
일반 속성 프로파일(GATT)은 속성이 서비스, 특성 및 설명자로 알려진 상위 수준의 구성을 어떻게 나타낼 수 있는지를 정의합니다. 일반적으로 이와 같은 더 복잡한 유형을 표현하려면 인접한 핸들 값 범위의 속성 그룹이 필요하며, 이러한 이유로 속성 프로토콜은 핸들 값 범위로 식별되는 속성 그룹으로 작업하는 것을 지원합니다. 섹션 13을 참조하세요. 일반 어트리뷰트 프로파일에서 자세한 내용을 확인하세요.
ATT 클라이언트 ATT 서버에서 속성 또는 관심 있는 속성 유형의 핸들 값을 포함하여 속성 테이블의 세부 정보를 검색하는 데 ATT를 사용합니다. 핸들 값을 알면 일부 PDU 유형과 함께 사용하여 테이블의 특정 속성을 식별하고 그에 따라 작동할 수 있습니다. 예를 들어, 기본 서비스 정의의 일부인 모든 속성의 핸들 및 UUID를 찾는 데 ATT_READ_BY_GROUP_TYPE_REQ PDU를 사용할 수 있습니다. 이를 더 짧게 표현하면, 예를 들어 속성 테이블에 정의된 모든 GATT 기본 서비스를 찾는 데 ATT_READ_BY_GROUP_TYPE_REQ PDU를 사용할 수 있다는 것입니다.
검색 작업을 지원하는 ATT_READ_BY_GROUP_TYPE_REQ와 같은 PDU를 사용하는 경우, 핸들 범위가 지정되며 검색할 속성 테이블의 항목 서브셋 (전체 테이블일 수도 있음)과 검색할 속성 유형을 나타냅니다. 그림 66은 검색되는 모든 기본 서비스와 검색된 기본 서비스와 관련된 속성을 포함하는 핸들 값의 범위를 나타내는 응답을 통해 이 프로세스를 보여줍니다.
그림 66 - 그룹별 읽기 유형 요청 및 응답
ATT는 연결된 Bluetooth LE 장치의 애플리케이션이 프로토콜이 정의하는 PDU와 GATT(일반 속성 프로필)와 같은 상위 수준 사양에 정의된 절차를 사용하여 서로 상호 작용하는 주요 메커니즘 중 하나입니다.
ATT의 두 가지 변형, 즉 기본 ATT와 새로운 EATT(향상된 속성 프로토콜)가 정의되어 있습니다.
ATT는 Bluetooth LE Bluetooth BR/EDR 모두에서 사용할 수 있습니다. 이 문서에서는 Bluetooth LE 함께 사용되는 ATT만 고려합니다.
12.2 ATT PDUs
속성 프로토콜은 6가지 방법 중 하나를 기반으로 하는 31개의 서로 다른 PDU를 정의합니다.
12.2.1 명령
클라이언트 호출한 서버로부터 응답이 없을 때 클라이언트 서버로 ATT 명령 PDU를 전송합니다. 명령의 예는 그림 67에 표시된 ATT_WRITE_CMD입니다.
그림 67 - ATT_WRITE_CMD
12.2.2 요청 및 응답
클라이언트 서버로 ATT 요청 PDU를 전송합니다. 서버는 30초 이내에 해당 유형의 응답 PDU 또는 오류 응답 PDU(ATT_ERROR_RSP)로 응답해야 합니다. 30초 이내에 응답하지 않으면 시간 초과로 간주됩니다.
요청/응답 PDU 페어링의 예는 그림 68에 표시된 ATT_WRITE_REQ 및 ATT_WRITE_RSP PDU입니다.
그림 68 - ATT_WRITE_REQ
12.2.3 통지
알림은 서버에서 클라이언트 전송하는 ATT_HANDLE_VALUE_NTF 유형의 요청하지 않은 PDU입니다. 응답 PDU는 정의되어 있지 않습니다. 그림 69를 참조하세요.
그림 69 - ATT_HANDLE_VALUE_NTF
12.2.4 알림 및 확인
서버에서 클라이언트 ATT 표시 PDU를 전송합니다. 클라이언트 30초 이내에 해당 유형의 확인 PDU 또는 오류 응답 PDU(ATT_ERROR_RSP)로 응답해야 합니다. 30초 이내에 응답하지 않으면 시간 초과로 간주됩니다.
표시/확인 PDU 페어링의 예로는 그림 70 - 표시 및 확인에 표시된 ATT_HANDLE_VALUE_IND 및 ATT_HANDLE_VALUE_CFM PDU를 들 수 있습니다.
그림 70 - 표시 및 확인
12.2.5 PDU 형식
모든 ATT PDU의 구조는 동일하며, PDU 유형을 식별하는 옵코드, 파라미터 세트, 인증 서명(선택 사항)으로 구성됩니다. 서명 필드는 거의 사용되지 않으며 링크 Layer의 모든 암호화된 패킷에 인증 데이터가 포함되어 있으므로 속성 프로토콜이 암호화된 링크를 통해 실행될 때 중복됩니다.
12.2.6 최대 전송 단위
ATT PDU의 최대 길이는 설정된 최대 전송 단위(MTU) 값에 따라 달라집니다. ATT에 사용되는 베어러[11] 에 따라 두 가지 메커니즘 중 하나를 사용하여 MTU를 설정할 수 있습니다.
12.3 데이터 교환
ATT는 트랜잭션의 개념을 정의합니다. 클라이언트 요청 PDU는 서버가 30초 이내에 응답 PDU를 반환할 것으로 기대합니다. 서버가 전송한 표시를 클라이언트 30초 이내에 확인 PDU로 회신할 것으로 예상합니다. 각 요청/응답 쌍 또는 표시/확인 쌍은 하나의 트랜잭션을 형성합니다. 트랜잭션이 시간 초과되면 트랜잭션이 실패한 것으로 간주되며 현재 무기명을 사용하여 어떤 유형의 PDU도 더 이상 전송할 수 없습니다.
ATT는 순차적 트랜잭션 모델을 사용합니다. 즉, ATT 트랜잭션이 시작된 경우 현재 트랜잭션이 완료될 때까지 동일한 무기명 인스턴스에서 더 이상의 ATT PDU를 처리할 수 없습니다. 원격 장치에서 예상 응답 또는 확인 PDU를 수신했거나 30초 동안 기다린 후 트랜잭션이 시간 초과되면 트랜잭션이 완료된 것으로 간주됩니다.
12.4 베어러(Barers)
ATT는 아래의 L2CAP 계층에서 두 가지 방식 중 하나로 처리되며, 각각 무기명이라고 합니다. 두 가지 ATT 베어러는 강화되지 않은 ATT 베어 러와 강화된 ATT 베어러입니다. 어떤 베어러를 사용하느냐에 따라 ATT가 사용되는 방식과 경우에 따라 프로토콜의 신뢰성에 영향을 미칩니다. 일반 속성 프로필은 ATT가 사용되는 방식을 다루며 예를 들어 다음과 같이 명시합니다:
강화되지 않은 ATT 무기명
- 고정 L2CAP 채널을 사용하므로 이 무기명의 인스턴스는 하나만 있을 수 있습니다.
- 트랜잭션은 애플리케이션 Layer의 클라이언트 수에 관계없이 엄격하게 순차적으로 진행됩니다. 즉, 한 애플리케이션에서 시작된 트랜잭션이 다른 애플리케이션에서 시작하려는 트랜잭션을 지연시킬 수 있습니다.
- 강화되지 않은 ATT 베어러를 통해 사용할 ATT MTU 선택에 영향을 미치기 위해 ATT_EXCHANGE_MTU_REQ 및 ATT_EXCHANGE_MTU_RSP PDU를 교환할 수 있습니다.
- 버퍼 오버플로 등의 문제로 인해 처리할 수 없는 클라이언트 수신한 알림은 모두 삭제됩니다. 따라서 강화되지 않은 ATT 베어러를 통해 사용하는 경우 ATT_HANDLE_VALUE_NTF PDU는 신뢰할 수 없는 것으로 간주됩니다.
- 강화되지 않은 ATT 베어러를 사용하는 경우 ATT_MULTIPLE_HANDLE_VALUE_NTF, ATT_READ_MULTIPLE_VARIABLE_REQ 및 ATT_READ_MULTIPLE_VARIABLE_RSP와 같은 일부 PDU 유형에 대한 지원은 선택 사항입니다.
- 강화되지 않은 ATT 베어러를 지원하는 L2CAP 채널은 암호화되지 않거나 암호화되어 있을 수 있습니다.
향상된 ATT 무기명
- 동적 L2CAP 채널과 여러 채널을 사용하므로 여러 베어러 인스턴스가 허용됩니다.
- 트랜잭션은 순차적으로 처리되지만 무기명 단위로 처리됩니다. 따라서 스택 내에서 각각 별도의 향상된 ATT 무기명 인스턴스가 처리하는 병렬 트랜잭션이 가능합니다. 이는 한 애플리케이션ATT 사용이 다른 애플리케이션의해 차단될 가능성을 피할 수 있다는 분명한 이점이 있습니다.
- ATT MTU는 L2CAP 계층에서 자동으로 사용되는 MTU 값으로 설정되며, ATT_EXCHANGE_MTU_REQ 및 ATT_EXCHANGE_MTU_RSP PDU는 Enhanced ATT 베어러를 통해 허용되지 않습니다.
- 향상된 신용 기반 흐름 제어 모드라고 하는 L2CAP 흐름 제어 방식은 향상된 ATT 무기명과 함께 사용됩니다. 이는 강화되지 않은 ATT 베어러를 사용할 때는 신뢰할 수 없는 PDU를 강화된 ATT 베어러를 사용할 때는 신뢰할 수 있는 것으로 간주하는 효과가 있습니다.
- 향상된 ATT 베어러를 사용할 때는 ATT_MULTIPLE_HANDLE_VALUE_NTF, ATT_READ_MULTIPLE_VARIABLE_REQ 및 ATT_READ_MULTIPLE_VARIABLE_RSP와 같은 일부 PDU를 반드시 지원해야 합니다.
- 강화된 ATT 베어러를 지원하는 L2CAP 채널은 암호화된 채널이어야 합니다.
12.5 EATT에 대한 지원 찾기
정의된 일반 속성 프로필 서비스를 통해 클라이언트 연결된 서버가 EATT를 지원하는지 여부를 확인할 수 있고, 반대로 클라이언트 서버에 EATT를 지원한다고 알릴 수 있습니다.
서버에서 EATT를 지원하는 경우 서버 지원 기능이라는 특성 일반 속성 프로필 서비스에 포함되어야 합니다. 이 특성 값의 첫 번째 옥텟의 비트 0이 1로 설정되어 있으면 EATT가 지원됨을 의미합니다. GATT/ATT 클라이언트 이 특성 읽어서 서버가 EATT를 지원하는지 여부를 확인할 수 있습니다.
클라이언트 지원 기능 특성 값은 특정 기능에 대한 지원 여부를 나타내는 비트로 구성됩니다. 비트 1은 클라이언트 향상된 ATT 베어러가 지원되는지 여부를 나타냅니다. 비트 2는 ATT_MULTIPLE_HANDLE_VALUE_NTF PDU가 지원되는지 여부를 나타냅니다. 클라이언트 이 특성 적절한 값을 기록하여 서버에 지원되는 기능을 알려야 합니다.
그림 71 - EATT 기능 지원 검색
13. 일반 속성 프로필
13.1 기본 사항
일반 속성 프로필(GATT)은 속성 테이블에 있는 속성을 기반으로 상위 수준의 데이터 유형을 정의합니다(12. 속성 프로토콜 참조). 이러한 데이터 유형을 서비스, 특성 및 설명자라고 합니다. 또한 속성 프로토콜(ATT)을 통해 이러한 데이터 유형을 사용하는 데 관련된 일련의 절차를 정의합니다. 애플리케이션은 일반적으로 이러한 절차에 매핑된 플랫폼 API를 사용합니다.
서비스는 포함된 특성을 사용할 수 있는 컨텍스트를 제공하고 정의된 유형을 갖는 그룹화 메커니즘입니다. 서비스는 종종 디바이스의 주요 기능 능력에 해당합니다.
특성은 상태 데이터의 개별 항목이며 유형, 관련 값 및 관련 GATT 절차 집합의 관점에서 데이터가 어떻게 사용될 수 있는지를 나타내는 속성 집합이 있습니다. 예를 들어, 연결된 피어 디바이스가 특정 특성 값을 읽을 수는 있지만 쓸 수는 없도록 정의할 수 있습니다.
특성은 서비스에 속합니다. 동일한 특성 유형이 두 개 이상의 서비스의 회원, 회원사 될 수 있으며 이러한 서비스가 제공하는 다양한 상황에 따라 특성 사용 규칙이 달라질 수 있습니다. 이러한 세부 사항은 서비스 specification에서 확인할 수 있습니다.
설명자는 일부 특성에 속하며 특성 대한 텍스트 설명과 같은 메타데이터를 포함하거나 특성 동작을 제어할 수 있는 수단을 제공할 수 있습니다. 특성에는 0개 이상의 설명자가 첨부될 수 있습니다. 예를 들어, GATT는 특성 값 알림이라는 작업을 정의하는데, 이는 디바이스가 특성 값이 포함된 ATT PDU를 연결된 피어에게 비동기적으로 다른 디바이스의 응답 없이 전송하는 것을 포함합니다. 특성 알림을 지원하는 경우 일반적으로 특성 값이 변경될 때 또는 타이머에 의해 제어되는 주기적으로 알림이 전송됩니다. 그러나 알림은 피어 디바이스가 요청한 경우에만 전송되며, 이는 클라이언트 특성 구성 설명 자라는 특정 유형의 설명자에서 특성이 알림을 지원하는 경우 해당 특성 있어야 하는 플래그를 설정하여 수행됩니다.
서비스, 특성 및 설명자의 계층 구조는 그림 72에 나와 있습니다.
그림 72 - 서비스, 특성 및 설명자
GATT는 두 가지 역할을 정의합니다. GATT 클라이언트 ATT 명령 및 요청을 GATT 서버로 보냅니다. GATT 서버는 GATT 클라이언트 받은 명령 및 요청을 수락하고 처리한 후 GATT 클라이언트 ATT 알림, 표시 및 응답을 보냅니다.
모든 GATT 서버에는 두 가지 특수 서비스가 필수입니다. 일반 액세스 서비스와 일반 속성 서비스입니다.
13.2 Bluetooth SIG와 사용자 지정
일부 서비스, 특성 및 설명자는 Bluetooth SIG 의해 정의되며 해당 유형을 식별하는 16비트 UUID 값을 갖습니다. 정의된 각 유형의 Bluetooth SIG 목록은 사양/할당 번호에서 확인할 수 있습니다. 구현자는 https://support.bluetooth.com/hc/en-us/articles/360062030092-Requesting-Assigned-Numbers 에서 설명된 대로 16비트 UUID 및 기타 유형의 할당 번호를 구매할 수 있습니다.
구현자는 사용자 지정 서비스, 특성 및 설명자를 정의할 수 있습니다. 사용자 지정 서비스, 특성 및 설명자는 구현자가 할당된 128비트 UUID 값으로 식별하거나 구현자가 Bluetooth SIG 16비트 UUID 값을 구매할 수 있습니다. 16비트 UUID에는 0000XXXX-0000-1000-8000-00805F9B34FB 형식의 동등한 128비트 값도 있으며 여기서 XXXX는 16비트 UUID 값입니다. 구현자는 Bluetooth SIG UUID를 구매한 경우 외에는 이 범위의 UUID를 사용할 수 없습니다.
GATT 서버에는 Bluetooth SIG 정의 서비스, 특성 및 설명자(속성)만 포함하거나 Bluetooth SIG 정의 속성과 사용자 지정 속성을 혼합하여 포함할 수 있습니다.
13.3 절차
서비스 검색, 특성 검색, 설명자 검색, 특성 값 읽기 및 쓰기, 특성 값 통지 및 표시 등을 다루는 GATT 절차가 정의되어 있습니다. GATT specification은 해당 절차와 이러한 절차가 사용해야 하는 기본 ATT 프로토콜 간의 명확한 매핑을 제공합니다.
13.4 예시
13.4.1 Bluetooth SIG 정의된 속성에 한함
그림 73은 특성이 있는 서비스 집합의 예를 보여줍니다. 하나의 특성 연관된 설명자가 있습니다. 이 예의 각 특성은 Bluetooth SIG 의해 정의됩니다.
그림 73 - 서비스, 특성 및 설명자 예시 세트
표시된 서비스는 표준 근접성 프로필을 구현하는 디바이스에 있을 수 있는 서비스입니다( 즉각적인 알림 및 TX 전원 서비스는 필수가 아님). 알림 수준 특성 링크 손실 서비스 내에서 한 번, 즉시 알림 서비스에서 한 번 두 번 표시되는 것을 확인할 수 있습니다. 두 경우 모두 UUID는 동일합니다. 이것이 바로 해당 특성 알림 수준 특성 식별한 것입니다 특성 그러나 특성 그룹화되는 서비스는 서로 다른 컨텍스트를 제공하며, 두 서비스 간에 알림 수준 특성 관련된 규칙 및 동작이 다릅니다.
서비스 변경된 특성 관련 클라이언트 특성 구성 설명자가 있는데, 이는 해당 특성 알림을 지원하기 때문입니다. 알림 또는 표시를 지원하는 모든 특성 클라이언트 특성 구성 설명자가 있어야 하는데, 그 값(클라이언트가 쓸 수 있는)에 따라 알림 또는 표시가 현재 활성화되어 있는지 여부가 제어되기 때문입니다.
13.4.2 Bluetooth SIG 및 사용자 정의 속성 혼합
그림 74는 단일 사용자 지정 특성 포함하는 단일 사용자 지정 서비스와 Bluetooth SIG 정의된 GATT 속성이 혼합된 GATT 서버를 보여줍니다. 이 사용자 지정 서비스를 근접 모니터링 서비스라고 하며 UUID 유형 식별자 값은 0x 3E099910-293F-11E4-93BD-AFD0FE6D1DFD입니다. 이 특성 클라이언트 특성 하며, UUID 값은 0x 3E099911-293F-11E4-93BD-AFD0FE6D1DFD입니다. 이 서비스 및 특성 교육용 개발자 리소스인 블루투스 저에너지 개발 소개에서 프로젝트 작업에 사용됩니다. 18페이지를 참조하세요. 추가 리소스에서 자세한 내용을 확인하세요.
그림 74 - Bluetooth SIG 정의 및 사용자 지정 속성 혼합
14. 일반 액세스 프로필
14.1 기본 사항
블루투스 코어 사양 일반 액세스 프로파일(GAP) 섹션에서는 장치 검색 및 두 장치 간의 연결 설정과 관련된 절차를 정의합니다. 일반적으로 데이터의 무연결 통신을 수행하는 방법, 주기적 광고 사용 방법(7.8.3 PADVB - LE 주기적 광고 브로드캐스트 참조) 및 등시성 통신 설정 방법(7.8.5 LE BIS 및 LE CIS - 비동기 통신 참조)도 GAP에서 다루는 주제입니다.
또한 일부 주요 사용자 인터페이스 표준과 Bluetooth LE 보안의 특정 측면도 핵심 사양의 이 섹션에서 다룹니다.
광고 패킷(광고)의 전송과 스캔을 통한 수신은 GAP가 작동하는 방식의 핵심입니다. 다양한 광고 및 스캐닝 패킷 유형이 있으며, 이는 링크 Layer 의해 정의됩니다. 페이로드 필드를 AdvData라고 하며 이 필드가 모든 PDU 유형에 존재하는 것은 아닙니다. 이 필드가 있는 경우, 이 필드에 포함된 데이터는 AD 유형으로 알려진 일련의 하나 이상의 길이/태그/값 구조로 인코딩됩니다. AD 유형은 bluetooth.com의 사양 페이지에서 제공되는 핵심 사양 보충(CSS) 문서에 정의되어 있습니다.
GAP는 Bluetooth LE 및 Bluetooth BR/EDR 모두와 관련이 있습니다. 이 섹션의 나머지 부분에서는 Bluetooth LE 적용되는 GAP만 다룹니다. 또한 광고 및 스캔과 같은 활동은 GAP와 핵심적인 관련이 있지만, 이러한 절차는 실제로는 관련된 PDU 유형과 마찬가지로 링크 Layer 수행된다는 점에 유의해야 합니다.
14.2 역할
GAP는 네 가지 장치 역할을 정의합니다. 표 16에 이러한 역할이 나열되어 있고 설명되어 있습니다.
| 역할 | 묘사 |
|---|---|
| 방송사 | 어떤 형태의 광고를 사용하여 연결되지 않은 방식으로 데이터를 전송하는 장치입니다. 여기에는 레거시 광고 확장 광고 및 주기적 광고 포함됩니다 주기적 광고 방송사는 방송 등시 스트림을 전송할 수도 있습니다. 방송사는 송신기 보유하지만 수신기 보유는 선택 사항입니다. 생방송 자키는 주변 장치 역할도 수행하지 않는 한 중앙 장치로부터의 연결을 허용하지 않습니다. |
| 옵저버 | 옵저버는 광고 패킷 또는 방송 등시 스트림 데이터 패킷을 수신합니다. 다른 디바이스에 연결되지 않으며, 송신기 포함하거나 포함하지 않을 수 있습니다. 옵저버는 연결되지 않은 방식으로 생방송 데이터를 수신할 수 있습니다. |
| 주변장치 | 주변장치는 중앙 장치에 연결할 수 있습니다. 여기에는 송신기 수신기 포함됩니다. |
| 중앙 | 센트럴은 주변 장치와의 연결 설정을 시작할 수 있습니다. 여기에는 송신기 수신기 모두 포함됩니다 수신기 |
표 16 - GAP 역할
중앙 및 주변이라는 역할 이름은 링크 Layer 사용된다는 점에 유의하세요. 이 두 가지 다른 맥락에서의 용어는 같은 의미는 아닙니다.
14.3 발견
생방송 자키 또는 주변 디바이스가 검색 불가능 모드에 있거나 GAP가 정의하는 두 가지 검색 가능 모드 중 하나에 있습니다. 검색 불가 모드에서 광고하는 경우 전송된 패킷은 무선으로 표시되지만(보안 기능 아님) 일반 검색 가능 절차 또는 제한적 검색 가능 절차를 수행하는 스캔 디바이스는 이러한 패킷을 무시합니다.
검색 가능한 디바이스는 일반 검색 가능 모드 또는 제한적 검색 가능 모드 중 하나에 속할 수 있습니다. 일반 검색 가능 모드에서는 디바이스를 무기한으로 검색할 수 있는 반면, 제한 검색 가능 모드에서는 최대 3분 동안만 검색할 수 있습니다.
디바이스 검색은 광고 디바이스가 어떤 검색 가능한 모드에 있는지 플래그라는 광고 데이터 필드에서 광고 유형을 검사하여 인식할 수 있습니다. 제한된 검색 가능 모드는 사용자가 버튼을 누르거나 디바이스를 집어 이동하는 등 최근에 상호 작용한 디바이스에 우선순위를 부여하는 데 자주 사용됩니다.
중앙 또는 관찰자 장치가 다른 장치를 검색하려고 시도할 때 수동 검색 또는 능동 검색을 사용할 수 있습니다. 두 가지 중 허용되는 방식은 장치가 일반 검색 가능 모드에서 장치를 검색하려고 하는지 또는 제한된 검색 가능 모드에서 장치를 검색하려고 하는지에 따라 달라집니다.
패시브 스캐닝은 스캐닝 PDU를 전송하지 않고 광고 PDU를 수신하는 것을 포함합니다. 능동적 스캐닝은 광고 PDU를 수신하고 이에 대한 응답으로 스캐닝 PDU를 전송하여 추가 정보를 요청하는 것을 포함합니다. 다양한 PDU 유형은 링크 Layer 의해 정의되며 7.8.2 ADVB - LE 광고 브로드캐스트에 요약되어 있습니다.
Bluetooth 핵심 specification에 따르면 일부 장치는 레거시 광고만 사용하는 반면, 다른 장치는 확장 광고를 사용하거나 두 가지 형태의 광고를 모두 인터리빙할 수 있습니다. 검색 절차 중 하나를 수행하는 디바이스는 두 가지 유형의 광고에 대한 스캔을 인터리빙하는 것이 좋습니다. 또한 디바이스가 지원하는 모든 PHY에서 스캔하는 것이 좋습니다.
그림 75는 다른 관련 변수와 함께 GAP 검색 모드를 보여줍니다.
14.4 연결 모드
광고 디바이스는 사용된 PDU레거시 광고 또는 AdvMode 필드 값확장 광고으로 연결할 수 있는지 여부를 나타낼 수 있습니다.
그림 75는 다른 관련 변수와 함께 GAP 연결 모드를 보여줍니다.
장치는 GAP에 정의된 연결 관련 절차 중 하나를 수행하여 다른 장치와의 연결을 요청할 수 있습니다. 여기에는 일반적으로 이를 허용하는 여러 유형 중 하나의 수신된 PDU에 대한 응답으로 CONNECT_IND PDU레거시 광고 또는 AUX_CONNEXT_REQ PDU확장 광고를 전송하는 것이 포함됩니다. 링크 Layer 광고 및 연결 요청 PDU 유형과 연결 요청에 대한 응답으로 전송할 수 있는 PDU 유형에 관한 규칙을 정의합니다. 7.8.2.2.3 레거시 광고 및 관련 PDU 유형 및 7.8.2.3.5 확장 광고 및 관련 PDU 유형을 참조하세요.
14.5 디렉티드와 언디렉티드
GAP에서 사용하는 광고는 PDU를 수신하는 모든 옵저버 또는 중앙 디바이스에 적용될 수 있는 비지시형 광고이거나 특정 디바이스만 해당 PDU를 처리해야 한다는 의미의 지시형 광고일 수 있습니다. 다이렉트 광고에 관련된 PDU에는 수신 대상 디바이스의 블루투스 주소 포함된 TargetA 필드가 포함됩니다. 비지시형 광고에서는 TargetA 필드가 없습니다.
그림 75는 GAP 검색 및 연결 모드의 맥락에서 다이렉트 광고와 비다이렉트 광고를 보여줍니다.
그림 75 - GAP 검색 및 연결 모드
광고 유형 플래그는 기본 광고 채널에서 수신된 레거시 광고 패킷에 표시됩니다. 그러나 확장 광고 사용 중일 때는 기본 채널에서 수신되는 ADV_EXT_IND PDU에 AdvData 필드가 표시되지 않습니다. 확장 광고 함께 플래그가 사용 중인 경우 범용 채널의 보조 AUX_EXT_IND PDU에 표시됩니다.
14.6 스캔 가능과 스캔 불가능
특정 광고 PDU 유형은 스캔이 가능하다고 합니다. 즉, 이러한 PDU를 수신하는 디바이스는 더 많은 광고 데이터를 요청하기 위해 적절한 유형의 스캔 요청 PDU로 응답할 수 있습니다. 광고 PDU는 링크 Layer 의해 정의됩니다. 자세한 내용은 7.8.2.2.3 레거시 광고 및 관련 PDU 유형 및 7.8.2.3.5 확장 광고 및 관련 PDU 유형을 참조하세요.
14.7 GAP 및 LE 보안
GAP specification은 여러 보안 용어, 모드 및 절차를 정의합니다. 일반적으로 GAP 보안 절차에는 SMP(보안 관리자 프로토콜) 및 링크 Layer과 같은 스택의 다른 Layer이 포함되지만 이러한 Layer을 사용하여 특정 결과를 달성하기 위한 상위 수준의 절차는 Bluetooth 핵심 specification의 볼륨 3 파트 C(일반 액세스 프로필)에 정의되어 있으며, 자세한 내용은 이를 참조해야 합니다.
14.8 주기적 광고
주기적 광고 (응답이 있는 경우와 응답이 없는 경우 모두)는 링크 Layer 수행하지만(7.8.3 PADVB - LE 주기적 광고 브로드캐스트 참조), GAP는 브로드캐스터가 주기적 광고 모드로 진입하고 옵저버가 주기적 광고 트레인과 동기화하기 위한 절차를 지정합니다. 또한 옵저버가 생방송 자키로부터 주기적 광고 동기화 파라미터를 획득하여 ACL 연결을 통해 다른 디바이스로 전달할 수 있는 주기적 광고 동기화 전송(PAST) 절차도 GAP에 정의되어 있습니다.
14.9 비동기식 방송
생방송 등시 스트림과 연결된 등시 스트림을 사용하는 비동시 통신은 링크 Layer 수행하지만(7.8.5 LE BIS 및 LE CIS - 비동시 통신 참조) GAP는 이러한 형태의 통신을 위해 생방송 자키와 옵저버가 따라야 하는 절차를 명시하고 있습니다.
15. 보안 관리자 프로토콜
15.1 기본 사항
보안 관리자 프로토콜(SMP)은 스택의 보안 관리자 구성 요소의 일부입니다. 페어링, 본딩 및 키 배포와 같은 보안 관련 절차의 실행을 지원합니다.
보안 관리자 구성 요소는 다른 Layer에서 사용할 수 있는 보안 기능을 위한 암호화 도구 상자를 제공하고 페어링 알고리즘을 정의합니다.
섹션 16. Bluetooth LE 보안은 보안 전반에 대해 자세히 설명합니다.
15.2 예제
그림 76은 두 장치를 페어링하는 동안 사용되는 SMP를 보여줍니다. SMP 페어링 기능 교환 중에 입력/출력 기능 및 기타 플래그가 교환되는 것을 주목하세요. 이 단계는 어떤 페어링 알고리즘이 선택되고 인증 같은 단계가 절차에 어떻게 포함되는지를 결정하는 중요한 단계입니다.
그림 76 - 페어링 중 사용 중인 SMP
16. Bluetooth LE 보안
보안은 매우 중요한 주제이며 신중하게 고려하고 이해해야 할 사항입니다.
Bluetooth LE 보안 기능 및 기능 모음을 제공하며, 대부분은 선택 사항입니다. 특정 보안 문제를 주소 특정 보안 요구 사항을 충족하기 위한 보안 도구가 들어 있는 도구 상자로 생각해야 합니다. 제품 대한 보안 요구 사항을 확인한 후 해당 요구 사항을 충족하는 것은 제품 팀의 책임입니다. 적절한 경우, 이는 선택된 Bluetooth LE 보안 기능을 사용하여 달성해야 합니다.
이 주제의 중요성을 감안하여 Bluetooth SIG 이 주제에 대한 교육 리소스를 만들었으며 그 내용은 여기서 반복하지 않습니다. 섹션 18을 참조하세요 . 추가 리소스에서 자세한 내용을 확인하세요.
17. 애플리케이션
다른 섹션에서 설명한 Bluetooth LE 기능이 궁극적으로 활용되는 것은 애플리케이션을 통해서입니다. 그러나 최신 블루투스 코어 사양 모든 기능을 애플리케이션에서 반드시 사용할 수 있는 것은 아닙니다. 그 주된 이유는 다음과 같습니다:
- Bluetooth 핵심 specification의 새로운 기능이 구성 요소에 구현되어 컴퓨터, 스마트폰 등 일반적으로 사용 가능한 제품에 나타나려면 시간이 걸립니다.
- 많은 Bluetooth LE 기능은 선택 사항이며 어떤 기능을 포함하고 어떤 기능을 생략할지는 구현자가 결정합니다. 예를 들어 구현자는 controller 칩 제조업체일 수도 있고, Bluetooth Host 구성 요소를 포함하는 운영 체제 개발자일 수도 있습니다. 따라서 애플리케이션을 개발하려는 디바이스가 특정 버전의 Bluetooth 핵심 사양을 지원한다고 해서 반드시 해당 버전의 모든 기능을 지원하는 것은 아닙니다.
- 디바이스의 Bluetooth 스택이 특정 기능 지원한다고 해서 애플리케이션 개발자가 이를 사용할 수 있다는 의미는 아닙니다. 애플리케이션 개발자는 스택을 직접 사용하지 않고 API를 사용하여 작업합니다. 블루투스 기능 대한 API가 없는 경우 블루투스 컨트롤러가 해당 기능 지원하더라도 애플리케이션 해당 기능을 사용할 수 없습니다.
여기서 얻을 수 있는 교훈은 애플리케이션 개발에 착수하기 전에 몇 가지 조사를 해야 한다는 것입니다. 특히 API 설명서를 확인하여 필요한 기능의 지원 여부를 확인하고 애플리케이션이 실행될 하드웨어 및 운영 체제의 Bluetooth 스택 구성 요소 specification을 확인해야 합니다.
18. 추가 리소스
이 섹션에는 다양한 관점에서 Bluetooth LE 대한 학습을 지원하는 기타 리소스가 나열되어 있습니다.
| 리소스 | 묘사 | 위치 |
|---|---|---|
| Bluetooth 핵심 specification | 핵심 기술 사양입니다. Bluetooth 스택의 모든 계층과 관련 프로토콜 및 절차를 정의합니다. Bluetooth LE Bluetooth BR/EDR 모두 다룹니다. | 사양 |
| 프로필 및 서비스 specification | 서비스 사양은 단일 GATT 서비스와 그 서비스에 포함된 특성 및 설명자를 정의합니다. 다양한 조건과 상태 데이터 값에 대응하여 서비스를 호스팅하는 GATT 서버 디바이스가 보여줄 동작은 서비스 사양에 정의되어 있으며, 프로파일 사양은 관련 디바이스가 맡는 역할을 정의하고 특히 클라이언트 디바이스의 동작과 연결된 서버의 데이터를 정의합니다. | 사양 |
| LC3 | LE 오디오 사용하는 저복잡도 통신 코덱을 정의합니다. | 사양 |
| 학습 가이드 - Bluetooth 저에너지 개발 소개 | 스마트폰 및 주변 장치와 관련된 연결 지향 시나리오를 위한 소프트웨어 개발에 대해 배우고자 하는 개발자를 위한 교육 리소스입니다. 솔루션이 포함된 일련의 실습 프로젝트가 포함되어 있습니다. | 블루투스 리소스/블루투스-le-개발자-스타터-키트/ |
| 학습 가이드 - Bluetooth Mesh 소프트웨어 개발 소개 | Bluetooth mesh 마이크로 컨트롤러에서 mesh 모델 구현에 대해 배우고자 하는 개발자를 위한 교육 리소스입니다. 솔루션이 포함된 일련의 실습 프로젝트가 포함되어 있습니다. | 블루투스 리소스/블루투스-메시-개발자-학습 가이드/ |
| 학습 가이드 - Bluetooth Mesh 프록시 기능 소개 | Bluetooth mesh 네트워크의 노드와 상호 작용할 수 있는 스마트폰과 같은 디바이스용 GUI 애플리케이션을 만드는 방법을 배우고자 하는 개발자를 위한 교육 리소스입니다. 솔루션이 포함된 일련의 실습 프로젝트가 포함되어 있습니다. | 블루투스-자원/블루투스-메시-프록시-키트/ |
| 논문 - Bluetooth Mesh 네트워킹 - 개발자를 위한 소개 | Bluetooth Mesh 의 주요 개념과 기능에 대해 배우고 싶은 사람을 위한 교육 리소스입니다. | 개발자를 위한 블루투스 리소스/블루투스 메시 네트워킹 소개/ |
| 논문 - Bluetooth Mesh 모델 - 기술 개요 | Bluetooth mesh 제품에 사용할 수 있는 표준 모델을 더 잘 이해하고자 하는 모든 사람을 위한 교육 리소스입니다. | 블루투스-리소스/블루투스-메시-모델/ |
| 학습 가이드 - Bluetooth LE 보안 이해 | Bluetooth LE (Bluetooth 메시 제외)에서 보안의 모든 측면을 설명하고 예시를 보여주는 교육 자료입니다. 보안을 처음 접하는 초보자부터 이전 경험이 있는 사용자 모두에게 적합합니다. 솔루션이 포함된 일련의 실습 프로젝트가 포함되어 있습니다. | 블루투스 리소스/레-보안-스터디 가이드/ |
| 문서 - 블루투스 보안 및 개인정보 보호 모범 사례 가이드 | 구현자가 특정 애플리케이션에 대해 사용 가능한 특정 보안 및 개인정보 보호 옵션이 다른 옵션보다 나은지 또는 나쁜지, specification에 어떤 위험과 함정이 남아 있는지 더 잘 이해할 수 있도록 돕기 위한 가이드입니다. | 블루투스 리소스/블루투스 보안 및 개인정보 보호 모범 사례 가이드/ |
| 학습 가이드 - Linux 개발자를 위한 Bluetooth 기술 | Linux Bluetooth 스택인 BlueZ를 사용하는 소프트웨어 개발에 대해 배우고자 하는 Linux 개발자를 위한 교육 리소스입니다. 솔루션이 포함된 일련의 실습 프로젝트가 포함되어 있습니다. | 블루투스-리소스/블루투스-포-리눅스/ |
| 학습 가이드 - Bluetooth 인터넷 게이트웨이 설계 및 개발 | 인터넷에서 Bluetooth LE 및 블루투스 메시 장치에 대한 액세스를 제공하는 데 사용되는 블루투스 인터넷 게이트웨이에 대해 설명하는 교육 자료입니다. 가능한 아키텍처와 구현 접근 방식을 설명합니다. 솔루션이 포함된 일련의 실습 프로젝트가 포함되어 있습니다. | 블루투스-리소스/블루투스-인터넷-게이트웨이/ |
| 학습 가이드 - 웹 Bluetooth 소개 | 자바스크립트 웹 Bluetooth API를 사용하는 웹 애플리케이션 개발에 대해 배우고자 하는 개발자를 위한 교육 리소스입니다. 솔루션이 포함된 일련의 실습 프로젝트가 포함되어 있습니다. | 블루투스-리소스/웹-블루투스-튜토리얼/ |
| 학습 가이드 - Bluetooth 비콘 소개 | Bluetooth 비콘에 대해 배우고자 하는 개발자를 위한 교육 자료입니다. 솔루션이 포함된 일련의 실습 프로젝트가 포함되어 있습니다. | 블루투스-리소스/비콘-스마트-스타터-키트/ |
| 논문 - Bluetooth 핵심 specification 버전 5.0 기능 향상 | Bluetooth 핵심 specification 버전 5.0에서 발표된 새로운 기능 및 기타 변경 사항에 대해 설명합니다. LE 2M PHY, LE 코딩된 PHY 및 확장 광고를 포함합니다. | 블루투스 리소스/블루투스-5-go-faster-go-further/ |
| 논문 - Bluetooth 핵심 specification 버전 5.1 기능 개요 | Bluetooth 핵심 specification 5.1 버전에 새로 추가된 기능 및 기타 변경 사항에 대해 설명합니다. AoA 및 AoD 방향 찾기를 포함합니다. | 기능 |
| 논문 - Bluetooth 핵심 specification 버전 5.2 기능 개요 | Bluetooth 핵심 specification 버전 5.2에서 발표된 새로운 기능 및 기타 변경 사항에 대해 설명합니다. 향상된 속성 프로토콜, LE 전력 제어 및 LE 비동기 채널이 포함됩니다. | 블루투스 리소스/블루투스 코어 사양 버전 기능 개요/ |
| 논문 - Bluetooth 핵심 specification 버전 5.3 기능 개요 | Bluetooth 핵심 specification 버전 5.3에서 발표된 새로운 기능 및 기타 변경 사항에 대해 설명합니다. 서브레이팅 및 LE 채널 분류를 사용한 LE 향상된 연결 업데이트가 포함되어 있습니다. | 기능 |
| Bluetooth® 핵심 사양 버전 5.4 - 기술 개요 | Bluetooth 핵심 specification 버전 5.4에서 발표된 새로운 기능 및 기타 변경 사항에 대해 설명합니다. 응답이 포함된 주기적 광고 및 암호화된 광고 데이터가 포함됩니다. | 블루투스 리소스/블루투스 코어 사양 버전 5-4 기술 개요/ |
| Bluetooth® 핵심 사양 v6.0 기능 개요 | Bluetooth 핵심 specification 버전 6.0에 추가된 새로운 기능 및 기타 변경 사항에 대해 설명합니다. Bluetooth Channel Sounding, 의사 결정 기반 광고 필터링 및 광고주 모니터링이 포함됩니다. | 기능 |
| Bluetooth Channel Sounding 기술 개요 | Bluetooth Channel Sounding 대한 자세한 기술 개요를 제공합니다. | 블루투스 리소스/블루투스-채널-사운드-기술-개요/ |
| 전자책 - Bluetooth LE 오디오 소개 | Bluetooth LE 오디오의 기능과 기술에 대한 명확한 소개를 제공하는 Nick Hunn이 쓴 책입니다. | 블루투스-리소스/레-오디오-북/ |
| 규제 측면 문서 | Bluetooth LE 기술 및 다양한 지역에 적용되는 RF 규정에 대한 Bluetooth SIG이해와 관련된 지침 및 지원 정보를 제공합니다. | 블루투스 리소스/블루투스-저에너지-규제-측면-문서-rad/ |
[1] 블루투스 사양은 섹션 4에 소개되어 있습니다.
[2] 서비스, 특성 및 설명자는 일반 속성 프로필 섹션에 설명되어 있습니다.
[3] LE 2M 2BT는 블루투스 Channel Sounding 사용되며 일반 데이터 통신에는 사용되지 않습니다.
[4] 블루투스 Channel Sounding 특별한 경우이며 8.Bluetooth® Channel Sounding 다룹니다.
[5] Bluetooth LE 및 RF 규정에 대한 자세한 내용은 18을 참조하세요. 규제 측면 문서에 대한 추가 리소스
[6] 섹션 15에서는 Bluetooth LE 보안에 대해 자세히 설명합니다.
[7] [8] 주기적 광고 비동기 스트림은 7.8 논리적 전송에 설명되어 있습니다.
[9] #nse - 1은 하위 이벤트 수에서 1을 뺀 값입니다.
[10] LE 오디오 사용하는 저복잡성 통신 코덱
[11] 12.4 무기명 참조
