LE 오디오 프로파일: PACS·ASCS·BAP·CAP
Core가 주는 것은 CIS·BIS라는 등시성 통로(14장)까지다. 그 위에서 “이어폰이 어떤 코덱을 할 수 있는지 묻고, 설정을 합의하고, 소리를 흘리기 시작하고, 멈추는” 약속은 GATT 기반의 프로파일·서비스 사양들이 정한다. 이 장은 Core 밖이다. 근거는 Bluetooth SIG가 공개한 PACS 1.0.1, ASCS 1.0, BAP 1.0.1 원문이고, 각 사양의 표 번호를 달았다.
- PACS·ASCS·BAP·CAP·BASS가 각각 무엇을 맡는지 구별할 수 있다.
- ASE 상태 기계의 일곱 상태와 여덟 동작, 누가 어떤 전이를 시작할 수 있는지 따라갈 수 있다.
- BAP의 코덱·QoS 설정 이름(예: 16_2_1, 48_4_2)을 읽고 비트레이트와 지연을 해석할 수 있다.
- 링크가 끊겼을 때 ASE가 어디로 돌아가는지 안다.
누가 무엇을: 사양 지도
| 사양 | 종류 | 맡는 일 |
|---|---|---|
| PACS | 서비스 | “나는 이런 코덱·샘플링 주파수·프레임 길이를 받고 보낼 수 있다”(PAC 레코드), 오디오 위치(왼쪽·오른쪽), 지금 쓸 수 있는 오디오 맥락(미디어, 대화 등) |
| ASCS | 서비스 | 서버의 오디오 스트림 끝점(ASE)과 그 상태 기계, 클라이언트가 조작하는 ASE Control Point |
| BAP | 프로파일 | 유니캐스트(ASCS로 CIS 설정)와 방송(BIG·BASE) 절차, 필수 코덱·QoS 설정 표 |
| CAP | 프로파일 | 좌우 이어폰처럼 여러 기기를 한 세트로 묶어(CSIP) 함께 시작·멈춤 |
| BASS | 서비스 | 방송 도우미(휴대폰)가 수신기(보청기)에게 “이 방송을 들어라”, 방송 코드(9장)를 대신 넣어 줌. PAST(5장)로 동기 정보도 건넴 |
PACS는 연주자의 이력서(“이 악기, 이 음역을 할 수 있다”)다. ASCS는 무대 하나하나(ASE)의 준비 상태판이다. 비어 있음 → 악보 정함(코덱) → 자리 배치 정함(QoS) → 막 올리는 중 → 연주 중. BAP는 감독이 그 상태판을 어떤 순서로 넘겨야 하는지 정한 진행표이고, CAP는 오케스트라 여러 무대를 한꺼번에 움직이는 총감독이다.
PACS v1.0.1, ASCS v1.0, BAP v1.0.1(Bluetooth SIG, 공개 HTML 판) · CAP·CSIP·BASS는 같은 SIG 사양 목록 · 코덱 LC3과 LTV 형식의 값은 Assigned Numbers 문서
ASE 상태 기계
서버(이어폰)는 방향마다 ASE를 가진다. 소리를 받는 Sink ASE, 마이크 소리를 내보내는 Source ASE. 각 ASE는 일곱 상태 중 하나다. Idle(0x00), Codec Configured(0x01), QoS Configured(0x02), Enabling(0x03), Streaming(0x04), Disabling(0x05, Source ASE만), Releasing(0x06). 클라이언트(휴대폰)는 ASE Control Point에 동작을 써서 상태를 옮긴다.
| opcode | 동작 | 할 수 있는 상태 |
|---|---|---|
| 0x01 | Config Codec | Idle, Codec Configured, QoS Configured |
| 0x02 | Config QoS | Codec Configured, QoS Configured |
| 0x03 | Enable | QoS Configured |
| 0x04 | Receiver Start Ready | Enabling. 오디오를 받는 쪽(Audio Sink)만: Sink ASE는 서버가 스스로, Source ASE는 클라이언트가 |
| 0x05 | Disable | Enabling, Streaming |
| 0x06 | Receiver Stop Ready | Disabling (Source ASE만) |
| 0x07 | Update Metadata | Enabling, Streaming |
| 0x08 | Release | Codec Configured ~ Disabling |
Config QoS, Enable, Receiver Stop Ready는 클라이언트만 시작할 수 있고, Released(Releasing → Idle 또는 코덱 설정을 남겨 두는 Codec Configured)는 서버만 한다. 끊김 규칙이 중요하다. CIS가 끊기면 Streaming·Disabling의 ASE는 곧바로 QoS Configured로 돌아가고(다시 Enable만 하면 된다), LE-ACL이 끊기면 어느 상태든 Releasing으로 간다.
ASE 하나 조작해 보기 (ASCS Table 3.2)
ASE 상태(Table 3.1)·전이(Table 3.2)·끊김 규칙: ASCS v1.0 §3.1·§3.2 · ASE Control Point 동작(Table 4.6): §4.2 · 동작별 절차: §5.1~§5.9 · BAP의 같은 규칙: BAP §5.6.3.2
BAP 설정 이름 읽기
BAP는 서로 다른 회사 기기가 반드시 맞출 수 있도록 코덱·QoS 설정에 이름을 붙였다. 16_2_1은 “16 kHz, 설정 2(10 ms 프레임, 40옥텟), QoS 1(낮은 지연)”이다. 마지막 숫자 1은 낮은 지연(재전송 2~5, 최대 전송 지연 8~31 ms), 2는 높은 신뢰도(재전송 13, 75~100 ms)다. 16_2_1은 유니캐스트 클라이언트·서버 모두 필수다. 비트레이트는 SDU 크기 × 8 ÷ SDU 간격이다.
BAP QoS 설정 (BAP v1.0.1 Table 5.2)
이어폰과 휴대폰이 둘 다 BAP를 지원한다. 회사가 달라도 반드시 함께 쓸 수 있는 설정은?
Table 5.2에서 클라이언트·서버 둘 다 M인 줄은?
QoS 설정 표와 요구(M/C): BAP v1.0.1 Table 5.2 · 코덱 설정 표: BAP Table 3.5·3.11 · 유니캐스트 절차: BAP §5
묶어서 다루기: CAP와 방송 도우미
좌우 이어폰은 서로 다른 두 기기이고 각자 ASE를 가진다. CAP는 두 기기가 같은 조정 세트(CSIP로 서로를 알아봄)라는 것을 알고, 두 기기의 ASE를 같은 CIG 안의 두 CIS로 묶어 함께 Enable하게 한다. 그래야 왼쪽만 먼저 나오거나 한쪽만 멈추지 않는다. 등시성 그룹의 공통 동기점(CIG_Sync_Delay, 14장)이 두 귀의 소리를 같은 순간에 내게 한다.
방송(Auracast)에서는 휴대폰이 방송 도우미가 된다. 보청기 대신 스캔해서 방송을 찾고, BASS로 보청기에 “이 방송 묶음(SID)을 들어라”를 쓰고, 필요하면 방송 코드를 넣어 주고, PAST로 주기적 광고 동기 정보를 넘긴다(5장). 보청기는 스캔 없이 BIG에 동기화해 BIS를 받는다(9장).
CAP·CSIP·BASS(Bluetooth SIG 사양) · BIG 동기와 PAST: [Vol 6] Part B §4.4.6, §5.1.13 · 방송 코드: [Vol 3] Part C §3.2.6
핵심 정리
- Core 밖: PACS(능력), ASCS(ASE 상태 기계), BAP(절차와 설정 표), CAP(세트 묶기), BASS(방송 도우미).
- ASE 상태: Idle → Codec Configured → QoS Configured → Enabling → Streaming, Source ASE는 Disabling, 끝은 Releasing.
- Config QoS·Enable·Receiver Stop Ready는 클라이언트만, Released는 서버만. Receiver Start Ready는 오디오를 받는 쪽(Sink ASE면 이어폰, Source ASE면 휴대폰)만 한다.
- CIS가 끊기면 QoS Configured로, LE-ACL이 끊기면 Releasing으로.
- BAP 이름 = 주파수_설정_QoS. 16_2_1(16 kHz, 10 ms, 40옥텟, 32 kbps)만 양쪽 필수. 44.1 kHz는 프레임 있는 PDU.
확인 퀴즈
Enable 동작을 쓸 수 있는 ASE 상태는?
Streaming 중 CIS가 끊기면 ASE는?
48_4_2의 SDU 간격과 크기는?
Disabling 상태가 있는 ASE는?