ประเด็นหลัก: ความสามารถของ FastPair Low Energy Audio (LEA) สามารถเข้าถึงได้เป็นพิเศษในรุ่น Android V(Android 15) เราขอแนะนำอย่างยิ่งให้ใช้ข้อกำหนดเฉพาะของอุปกรณ์ BLE สำหรับการจับคู่ด่วนสำหรับอุปกรณ์ที่เข้ากันได้กับ LEA คําแนะนํานี้มาจากประสบการณ์ที่เราพบปัญหามากมายเกี่ยวกับหูฟังที่รองรับ LEA แต่ไม่มีการใช้งานการจับคู่ด่วนผ่าน LEA อย่างเหมาะสม ดูข้อมูลเพิ่มเติมได้ในส่วนปัญหาที่ทราบแล้ว การรับรอง FP LEA จะพร้อมใช้งานหลังจากการเผยแพร่ Android V(Android 15) เท่านั้น

อุปกรณ์บลูทูธพลังงานต่ำ (BLE)

การใช้งานบริการจับคู่ด่วนของ Google (GFPS) สำหรับอุปกรณ์ BLE เข้ากันได้กับข้อกำหนดหลักของบลูทูธ v4.2 ขึ้นไป

เอกสารแนบท้ายต่อไปนี้ของข้อกำหนดการจับคู่ด่วนจะอนุญาตให้รองรับอุปกรณ์พลังงานต่ำ (LE) เท่านั้นและอุปกรณ์เสียงพลังงานต่ำ (LEA) ใน GFPS

ระดับการปฏิบัติตามข้อกำหนด

คีย์เวิร์ด "ต้อง" "ควร" "จะ" "อาจ" และ "สามารถ" ที่กล่าวถึงในข้อกําหนดมีคำอธิบายดังนี้

คำศัพท์	คำอธิบาย
shall	is required to - ใช้เพื่อกำหนดข้อกำหนด
must	ใช้เพื่อแสดงถึง ผลที่ตามมาตามปกติของข้อกำหนดที่จำเป็นที่ระบุไว้ก่อนหน้านี้ หรือ ข้อความที่เป็นข้อเท็จจริงที่ไม่อาจโต้แย้งได้ (ข้อความที่เป็นความจริงเสมอไม่ว่าจะอยู่ในสถานการณ์ใดก็ตาม)
จะ	it is true that - ใช้เฉพาะในข้อความที่เป็นข้อเท็จจริง
should	แนะนำให้ - ใช้เพื่อระบุว่าในหลายๆ ทางเลือก เราขอแนะนำให้ใช้ทางเลือกหนึ่งโดยเฉพาะ แต่ไม่ได้บังคับ
อาจ	ได้รับอนุญาตให้ - ใช้เพื่ออนุญาตตัวเลือก
ทำได้	สามารถ - ใช้เพื่อเชื่อมโยงข้อความในลักษณะที่เป็นเหตุเป็นผล

ลักษณะการจับคู่ตามคีย์

ข้อความจาก Seeker ถึงผู้ให้บริการ

คำขอแบบไฟล์ดิบ type 0x00 ของลักษณะการจับคู่ตามคีย์ใช้บิต 4 เพื่อระบุว่าอุปกรณ์ค้นหารองรับข้อกำหนดของอุปกรณ์ BLE หรือไม่ และใช้บิต 5 เพื่อระบุว่าอุปกรณ์ค้นหารองรับ LE Audio หรือไม่

อ็อกเท็ต	ประเภทข้อมูล	คำอธิบาย	ค่า	จำเป็นไหม
0	uint8	ประเภทข้อความ	0x00 = คำขอจับคู่ตามคีย์	บังคับ
1	uint8	ธง บิต 0 (MSB): เลิกใช้งานแล้วและ Seeker จะไม่สนใจ บิตที่ 1: 1 หากผู้ค้นหาขอให้ผู้ให้บริการเริ่มการจับคู่ และคำขอนี้มีที่อยู่ BR/EDR ของผู้ค้นหา 0 ไม่เช่นนั้น บิต 2: 1 หากผู้ค้นหาขอให้ผู้ให้บริการแจ้งชื่อที่มีอยู่ 0 ไม่เช่นนั้น บิต 3: 1 หากเป็นกรณีนี้สำหรับการเขียนคีย์บัญชีย้อนหลัง 0 ไม่เช่นนั้น บิตที่ 4: 1 หากอุปกรณ์ค้นหารองรับข้อกำหนดของอุปกรณ์ BLE 0 ไม่เช่นนั้น บิต 5: 1 หาก Seeker รองรับ LE Audio 0 ไม่เช่นนั้น บิต 6-7 สงวนไว้สำหรับการใช้งานในอนาคตและระบบจะไม่สนใจ	แตกต่างกัน	บังคับ
2-7 คน	uint48	โดยทำอย่างใดอย่างหนึ่งต่อไปนี้ ที่อยู่ BLE ปัจจุบันของผู้ให้บริการ ที่อยู่ประจำตัวของผู้ให้บริการ	แตกต่างกัน	บังคับ
8 - 13	uint48	ที่อยู่ BR/EDR ของผู้ค้นหา	แตกต่างกัน	แสดงเฉพาะในกรณีที่ตั้งค่า Flags Bit 1 หรือ 3
n - 15		ค่าแบบสุ่ม (Salt)	แตกต่างกัน	บังคับ

ข้อความจากผู้ให้บริการถึงผู้ค้นหา

เมื่อตั้งค่าบิต 4 ของคำขอแล้ว ระบบจะใช้ข้อความตอบกลับใหม่ type 0x02 สำหรับลักษณะการจับคู่ตามคีย์เพื่อแสดงตัวเลือกการจับคู่เพิ่มเติมแก่ผู้ค้นหาได้

อ็อกเท็ต	ประเภทข้อมูล	คำอธิบาย	ค่า
0	uint8	ประเภทข้อความ	0x02 = คำตอบเพิ่มเติมเกี่ยวกับการจับคู่ตามคีย์
1	uint8	ธง บิต 0 (MSB): 1 หากผู้ให้บริการเป็นอุปกรณ์ LE เท่านั้น มิฉะนั้นจะเป็น 0 หากตั้งค่าบิต 0 เป็น 1 ผู้ค้นหาจะถือว่าบิต 1 มีการตั้งค่าเป็น 1 บิตที่ 1: 1 หากผู้ให้บริการต้องการการเชื่อมโยง LE ไม่เช่นนั้นจะเป็น 0 บิตที่ 2: 1 หากประเภทที่อยู่ของที่อยู่ลำดับที่ 2 เป็นแบบสุ่ม 0 หากเป็นแบบสาธารณะ บิตที่ 3-7 สงวนไว้สำหรับการใช้งานในอนาคตและระบบจะไม่สนใจ	แตกต่างกัน
2	uint8	จำนวนที่อยู่ของผู้ให้บริการ (ในเวอร์ชันปัจจุบัน จำนวนคือ 1 หรือ 2 เนื่องจากเราต้องแก้ไขโหมดการเข้ารหัสแบบบล็อกเป็น AES-CTR หากตัวเลข >= 3)	แตกต่างกัน
3 - 8 หรือ 3 - 14		ที่อยู่แรกต้องเป็นที่อยู่ของข้อมูลประจำตัวของอุปกรณ์หลัก และสามารถจับคู่ได้หากต้องการใช้การจับคู่ BR/EDR ที่อยู่ที่สองต้องเป็นที่อยู่ของอุปกรณ์รองที่สามารถใช้การเชื่อมโยงได้ หากมีอุปกรณ์รอง	แตกต่างกัน
9 - 15 หรือ 15		ค่าแบบสุ่ม (Salt)	แตกต่างกัน

ผู้ให้บริการที่รองรับข้อกำหนดของอุปกรณ์ BLE จะอ่านบิต 4 และบิต 5 เพื่อทําความเข้าใจความสามารถของผู้ค้นหา

• เมื่อบิต 4 เป็น 0 ผู้ให้บริการจะละเว้นบิต 5 และตอบกลับด้วยรูปแบบ type 0x01
• เมื่อบิต 4 เป็น 1
  • สำหรับผู้ให้บริการ LE เท่านั้น ระบบจะตอบกลับด้วย type 0x02 เพื่อระบุค่ากำหนดการเชื่อมโยง LE
  • สำหรับผู้ให้บริการแบบ 2 โหมด ผู้ให้บริการจะตอบกลับด้วย type 0x02 เพื่อระบุค่ากำหนดการเชื่อมโยง BR/EDR หรือ LE
• สําหรับเคสผู้ให้บริการ LE Audio (LEA) แบบคู่ โปรดดูตัวอย่าง: การจับคู่กับผู้ให้บริการ LEA แบบคู่สําหรับข้อมูลอ้างอิง

ลักษณะ PSM (ตัวรวมบริการโปรโตคอล) ของสตรีมข้อความ

การจับคู่ด่วนจะสร้างและดูแลรักษาแชแนล BLE L2CAP เพื่อส่งและรับข้อความเพื่อรองรับสตรีมข้อความสำหรับอุปกรณ์ BLE การจับคู่ด่วน เซิร์ฟเวอร์ L2CAP จะใช้การควบคุมโฟลว์ตามเครดิต LE

ลักษณะนี้ช่วยให้ผู้ค้นหาอ่านค่า PSM ได้ จากนั้นจึงสร้างการเชื่อมต่อ L2CAP ที่ปลอดภัยตามค่า PSM

ลักษณะบริการการจับคู่ด่วน	มีการเข้ารหัส	สิทธิ์	UUID
PSM ของสตรีมข้อความ	ใช่	อ่าน	FE2C1239-8366-4814-8EB0-01DE32100BEA

อ็อกเท็ต	ประเภทข้อมูล	คำอธิบาย	ค่า
0	uint8	รัฐ 0x00 = ไม่รู้จัก FP Seeker จะลองอีกครั้งหลายครั้ง 0x01 = พร้อมเชื่อมต่อ 0x02 = ไม่พร้อมใช้งาน FP Seeker จะไม่ใช้คอมโพเนนต์นี้เพื่อเชื่อมต่อในครั้งนี้	แตกต่างกัน
1 - 2	uint16	ค่า PSM จะอยู่ในช่วง 0x80 ถึง 0xFF	แตกต่างกัน

หมายเหตุ: TWS ประกอบด้วยคอมโพเนนต์ 2 รายการ ได้แก่ หลักและรอง บทบาทของคอมโพเนนต์เหล่านี้ใช้แทนกันได้ในบางเงื่อนไข สมมติว่า A เป็นคอมโพเนนต์หลักและ B เป็นคอมโพเนนต์รอง เนื่องจากแบตเตอรี่ของคอมโพเนนต์ A หมด คอมโพเนนต์ B จึงต้องทำหน้าที่เป็นคอมโพเนนต์หลัก และสถานการณ์นี้เรียกว่า role switch

หลังจาก role switch หากผู้ให้บริการไม่สามารถจัดการสตรีมข้อความการจับคู่ด่วนได้ ผู้ให้บริการจะต้องยกเลิกการเชื่อมต่อ L2CAP ที่มีอยู่ จากนั้นผู้มองหาการจับคู่ด่วนสามารถสร้างการเชื่อมต่อสตรีมข้อความ L2CAP อีกครั้งด้วยคอมโพเนนต์หลักใหม่

ลักษณะพาสคีย์เพิ่มเติม

ลักษณะนี้มีไว้เพื่อมอบการป้องกัน MITM ในคอมโพเนนต์เพิ่มเติม

CSIS Fake Member MITM Protection

การจับคู่ด่วนต้องใช้การป้องกัน MITM ในขั้นตอนการจับคู่ เนื่องจาก CSIS ไม่ได้ให้การป้องกัน MITM การออกแบบ FP ในปัจจุบันสำหรับคอมโพเนนต์หลายรายการจึงต้องขยายการให้บริการเพื่อมอบการป้องกัน MITM ในคอมโพเนนต์เพิ่มเติม

คําจํากัดความของลักษณะ

ลักษณะบริการจับคู่ด่วน	มีการเข้ารหัส	สิทธิ์	UUID
พาสคีย์เพิ่มเติม	ใช่	อ่าน เขียน แจ้งเตือน	FE2C123A-8366-4814-8EB0-01DE32100BEA

ข้อความ

ระบบจะใช้รูปแบบข้อความกับการดำเนินการอ่าน เขียน และแจ้งเตือน

รูปแบบข้อมูลที่เข้ารหัส

ระบบจะส่งข้อมูลที่เข้ารหัสโดยใช้การเชื่อมต่อ GATT ของการจับคู่ด่วน

Octet	ประเภทข้อมูล	คำอธิบาย	ค่า
0-15	uint128	บล็อกพาสคีย์เพิ่มเติมที่เข้ารหัส	แปรเปลี่ยน

รูปแบบข้อมูลดิบ

หลังจากถอดรหัสข้อมูลที่เข้ารหัสโดยใช้ข้อมูลลับที่ใช้ร่วมกันแล้วจะมีรูปแบบดังนี้

อ็อกเท็ต	ประเภทข้อมูล	คำอธิบาย	ค่า
0	uint8	ประเภทข้อความ	หนึ่งใน 0x00 = พาสคีย์ของผู้ค้นหา 0x01 = พาสคีย์ของผู้ให้บริการ
1-3	uint24	พาสคีย์ 6 หลัก	แปรเปลี่ยน
4-9	uint48	ที่อยู่ของคอมโพเนนต์การเชื่อมโยงเป้าหมาย	แปรเปลี่ยน
10	uint8	รหัสสถานะ ซึ่งใช้โดยการดำเนินการแบบอ่านเท่านั้น	ข้อใดข้อหนึ่ง 0x00 = สำเร็จ 0x01 = รอดำเนินการ FP Seeker จะลองใหม่จนกว่าจะหมดเวลา 0x02 = ไม่สําเร็จ FP Seeker stop retry
11-15		ค่าแบบสุ่ม (Salt)	แปรเปลี่ยน

อุปกรณ์หลัก (คอมโพเนนต์ที่จับคู่ครั้งแรก) เป็นบริดจ์ระหว่างอุปกรณ์ค้นหาการจับคู่ด่วนกับคอมโพเนนต์การจับคู่เพิ่มเติม โดยลักษณะต้องเป็นไปตามหลักเกณฑ์ต่อไปนี้

• เมื่อได้รับคำขอเขียนจากผู้ค้นหาการจับคู่ด่วน ผู้ให้บริการต้องดำเนินการดังนี้
  • ตั้งค่าที่อยู่ของคอมโพเนนต์ที่จะเชื่อมโยง
  • ส่งพาสคีย์ไปยังคอมโพเนนต์ที่กำลังเชื่อมโยง
  • ตั้งรหัสสถานะเป็น "รอดำเนินการ", 0x01
• เมื่อได้รับคำขออ่านก่อนที่จะได้รับพาสคีย์จากคอมโพเนนต์ที่ผูกมัด ผู้ให้บริการจะต้องแสดงข้อความที่มี
  • พาสคีย์ ค่าใดก็ได้
  • ที่อยู่ของคอมโพเนนต์ที่ผูกมัด
  • รหัสสถานะรอดำเนินการ 0x01
• ก่อนที่ผู้ให้บริการจะส่งการแจ้งเตือนไปยังตัวค้นหาการจับคู่ด่วน ให้ตั้งค่าผลลัพธ์สำหรับคำขออ่านด้วย
  • พาสคีย์จากคอมโพเนนต์ที่เชื่อมโยง
  • ที่อยู่ของคอมโพเนนต์ที่ยึด
  • รหัสสถานะ "สำเร็จ" 0x00
• หากเกิดข้อผิดพลาดที่กู้คืนไม่ได้ในฝั่งผู้ให้บริการ ให้ตั้งค่าผลลัพธ์เป็น
  • พาสคีย์ ค่าใดก็ได้
  • ที่อยู่ของคอมโพเนนต์ที่ยึด
  • รหัสสถานะ "การดำเนินการไม่สำเร็จ" 0x02

ดูรายละเอียดเพิ่มเติมได้ที่แผนภาพ MITM 1 และแผนภาพ MITM 2

ข้อกำหนดของอุปกรณ์ LE

LE Advertising

สําหรับโหมดที่ค้นพบได้หรือโหมดที่ค้นพบไม่ได้ ผู้ให้บริการจะใช้ RPA เพื่อโฆษณาข้อมูล FastPair

ความสามารถในการประสาน

สําหรับอุปกรณ์ที่รองรับ LE ผู้ค้นหาต้องสร้างการเชื่อมโยงกับการเชื่อมต่อ LE ที่มีอยู่ หลังจากผ่านการยืนยันการจับคู่ตามคีย์การจับคู่ด่วนแล้ว ผู้ให้บริการควรอนุญาตให้จับคู่กับ RPA และตั้งค่าความสามารถของ IO เป็น DisplayYesNo สำหรับการยืนยันพาสคีย์การจับคู่ด่วน

ข้อกำหนดของอุปกรณ์ LEA

LEA Advertising

สำหรับอุปกรณ์แบบ 2 โหมด สำหรับโหมดที่ค้นพบได้ ผู้ให้บริการต้องโฆษณาข้อมูลการจับคู่ด่วนด้วยที่อยู่ข้อมูลประจำตัว สำหรับโหมดที่ค้นหาไม่ได้ ผู้ให้บริการต้องโฆษณาข้อมูลการจับคู่ด่วนด้วย RPA ขอแนะนําอย่างยิ่งให้ใช้โฆษณาเดิม (BT 4.2) เพื่อรองรับอุปกรณ์รุ่นเก่าเพื่อความเข้ากันได้แบบย้อนหลัง คุณต้องเปลี่ยน IRK ทุกครั้งที่รีเซ็ตอุปกรณ์เป็นค่าเริ่มต้น

สำหรับอุปกรณ์ที่ไม่ใช่โหมดคู่: สำหรับโหมดที่ค้นพบได้หรือโหมดที่ค้นพบไม่ได้ ผู้ให้บริการจะใช้การโฆษณาแบบขยาย (BT 5.0) ที่มี RPA เพื่อโฆษณาข้อมูล FastPair

โฆษณาที่เชื่อมต่อได้แบบ LE ซึ่งมีข้อมูลบริการ FP จะต้องมี CAS UUID ตามข้อกําหนดของโปรไฟล์อะแดปเตอร์บลูทูธ (BAP 1.0.1) และโปรไฟล์เสียงทั่วไป สำหรับโฆษณาที่ค้นพบไม่ได้ หากไม่มีพื้นที่เพียงพอในโฆษณาเดิมเนื่องจากมีการรวมแบตเตอรี่และข้อมูล SASS ก็จำเป็นต้องมี CAS UUID ในการตอบสนองการสแกนในกรณีดังกล่าว

ความสามารถในการเชื่อมโยง LEA

ผู้ค้นหาต้องสร้างการเชื่อมโยงกับการเชื่อมต่อ LE ที่มีอยู่ หลังจากผ่านการยืนยันการจับคู่ตามคีย์การจับคู่ด่วนแล้ว ผู้ให้บริการแบบ 2 โหมดจะอนุญาตให้จับคู่กับที่อยู่ข้อมูลประจำตัวและ RPA ส่วนผู้ให้บริการแบบไม่ใช้ 2 โหมดจะอนุญาตให้จับคู่กับ RPA และตั้งค่าความสามารถของ IO เป็น DisplayYesNo สำหรับการยืนยันพาสคีย์การจับคู่ด่วน

ช่องทางการสื่อสารภายในระหว่างคอมโพเนนต์

ระบบจะเก็บการเชื่อมต่อ GATT ที่มีอยู่ไว้เพื่อดำเนินการป้องกัน MITM ในส่วนประกอบเพิ่มเติม คอมโพเนนต์ที่เชื่อมโยงหลักจะจัดการการรับส่งข้อความระหว่างผู้ค้นหาการจับคู่ด่วนกับคอมโพเนนต์ที่เหลือ

การสื่อสารภายในใช้สำหรับ Initial Pair และ Subsequent Pair

• เมื่อกระบวนการจับคู่คีย์ผ่านไปยังคอมโพเนนต์หลัก คอมโพเนนต์หลักจะต้องส่งข้อความเพื่อเปลี่ยนความสามารถ IO ขององค์ประกอบที่เหลือ
• เมื่อจับคู่ด่วนเสร็จแล้ว คอมโพเนนต์หลักจะส่งข้อความเพื่อรีเซ็ตความสามารถของ IO ของคอมโพเนนต์ที่เหลือ
• เมื่อเรียกใช้กระบวนการพาสคีย์เพิ่มเติม คอมโพเนนต์หลักจะจัดการการส่งพาสคีย์ระหว่างเครื่องมือค้นหาการจับคู่ด่วนกับคอมโพเนนต์ที่เหลือ

เวลาที่ใช้ในการเปลี่ยนความสามารถของ IO

• เปลี่ยนความสามารถของ IO เป็น DisplayYesNo เมื่อผ่านขั้นตอนการจับคู่คีย์
  • หากอุปกรณ์มีคอมโพเนนต์หลายรายการ ให้ตั้งค่าคอมโพเนนต์ทั้งหมดเป็น DisplayYesNo
  • ข้อยกเว้นข้อหนึ่งที่ผู้ให้บริการต้องไม่เปลี่ยนแปลงความสามารถของ IO เป็น DisplayYesNo คือ Retroactive Pair ซึ่งบิต 3 ของคำขอการจับคู่ตามคีย์ได้รับการตั้งค่าเป็น 1 โปรดดูข้อความจากผู้ค้นหาถึงผู้ให้บริการ
• เปลี่ยนความสามารถของ IO เป็นการตั้งค่าเริ่มต้น
  • การจับคู่ครั้งแรก
    • หากการเชื่อมต่อ LE ตัดการเชื่อมต่อ ให้สิ้นสุดเซสชันการจับคู่ด่วน
    • หลังจากจับคู่อุปกรณ์หลักแล้ว หากไม่มีคำขอเขียนพาสคีย์เพิ่มเติมใน 15 วินาที ให้สิ้นสุดเซสชันการจับคู่ด่วน
    • หลังจากได้รับคำขอเขียนพาสคีย์เพิ่มเติม หากคอมโพเนนต์ที่กำลังจะจับคู่ไม่จับคู่ภายใน 15 วินาที ให้สิ้นสุดเซสชันการจับคู่ด่วน
    • หลังจากเชื่อมโยงคอมโพเนนต์ทั้งหมดแล้ว หากไม่มีคำขอเขียนคีย์บัญชีภายใน 15 วินาที ให้สิ้นสุดเซสชันการจับคู่ด่วน
    • หลังจากได้รับคำขอเขียนคีย์บัญชีแล้ว ให้ตั้งค่าระยะหมดเวลาเป็น 15 วินาทีเพื่อสิ้นสุดเซสชันการจับคู่ด่วน
  • การจับคู่ครั้งต่อๆ ไป
    • หากการเชื่อมต่อ LE ตัดการเชื่อมต่อ ให้สิ้นสุดเซสชันการจับคู่ด่วน
    • หลังจากจับคู่อุปกรณ์หลักแล้ว หากไม่มีคำขอเขียนพาสคีย์เพิ่มเติมภายใน 15 วินาที ให้สิ้นสุดเซสชันการจับคู่ด่วน
    • หลังจากได้รับคำขอการเขียนพาสคีย์เพิ่มเติม หากคอมโพเนนต์ที่ผูกมัดไม่ผูกมัดภายใน 15 วินาที ให้สิ้นสุดเซสชันการจับคู่ด่วน
    • เมื่อจับคู่คอมโพเนนต์ทั้งหมดแล้ว ให้สิ้นสุดเซสชันการจับคู่ด่วน

ซ่อนตัวบ่งชี้ UI

เมื่อหูฟังยังไม่พร้อมสำหรับการจับคู่ ผู้ให้บริการจะใช้ type 0b0010 เพื่อตั้งค่าการซ่อนตัวบ่งชี้ UI สำหรับข้อมูลคีย์บัญชีเพื่อบอกให้ผู้ค้นหาไม่แสดง UI การจับคู่ในภายหลัง (ดูเพย์โหลดการโฆษณา: ข้อมูลบัญชีการจับคู่ด่วน)

ข้อกำหนดของอุปกรณ์เสียง LE

ข้อกำหนดเกี่ยวกับบลูทูธ

ดูคําแนะนําเกี่ยวกับหูฟัง LE Audio ของ Android

การรองรับ CTKD

สำหรับอุปกรณ์แบบ 2 โหมด จำเป็นต้องมี CTKD จาก LE ไปยัง BR/EDR และสอดคล้องกับข้อกำหนดของ BAP

ประกาศเป้าหมาย

อุปกรณ์ต่อพ่วงจะใช้การประกาศที่กำหนดเป้าหมายเพื่อขอการเชื่อมต่อจากอุปกรณ์กลางที่จับคู่ไว้ การประกาศที่กำหนดเป้าหมายมีคำจำกัดความอยู่ใน BAP และ CAP สำหรับการจัดการการเชื่อมต่อตามตาราง 8.4 ของ CAP 1.0 (หน้า 48/58)

การรองรับเซิร์ฟเวอร์ GATT EATT

EATT ช่วยให้อุปกรณ์กลางส่งธุรกรรม GATT หลายรายการพร้อมกันได้เมื่ออุปกรณ์มีการจับคู่ สำหรับอุปกรณ์ที่รองรับ CSIP จะช่วยเพิ่มประสิทธิภาพในการเชื่อมต่อโปรไฟล์ จากนั้นจะเริ่มขั้นตอนการผูก CSIP สำหรับหูฟังเอียร์บัดเครื่องอื่นในอีกไม่ช้า

การแคชที่เชื่อถือได้ของ GATT (แนะนำอย่างยิ่ง)

หากผู้ให้บริการไม่ใช่อุปกรณ์เดียว แต่เป็นชุดที่มีการประสานงานกับการใช้งาน CSIP หากต้องการลดจำนวนครั้งในการค้นหาบริการและทำให้การเชื่อมต่อเร็วขึ้น ผู้ให้บริการควรใช้การแคช GATT ที่กำหนดไว้ในบลูทูธ 5.1

ข้อกำหนดสำหรับการจับคู่ด่วน

LE Advertising

สำหรับโหมดที่ค้นพบได้หรือโหมดที่ค้นพบไม่ได้ หากอุปกรณ์มีส่วนประกอบหลายอย่าง ข้อมูลการจับคู่ด่วนจะแสดงโดยคอมโพเนนต์หลัก หากอุปกรณ์ยังไม่พร้อมสำหรับการจับคู่ครั้งถัดไป คอมโพเนนต์รองจะโฆษณาข้อมูลการจับคู่ด่วนสำหรับฟีเจอร์เพิ่มเติมได้ ดูซ่อนการบ่งชี้ UI

ระดับการเข้าถึงบริการ GATT

ฐานข้อมูล GATT จะต้องเหมือนกันสำหรับการเชื่อมต่อ GATT ขนส่ง LE ทั้งหมด บริการ LE Audio (0x184E) จะรวมอยู่ในฐานข้อมูล GATT ของการเชื่อมต่อการจับคู่ด่วน

ตัวอย่าง: การจับคู่กับผู้ให้บริการแบบ 2 โหมดของ LEA

สถานการณ์ที่ 1 - เมื่อ Seeker ไม่รองรับ LEA

ผู้ให้บริการต้องมีความเข้ากันได้แบบย้อนหลังกับ Seeker ที่ไม่รองรับ LEA

คอมโพเนนต์

• ผู้ให้บริการ: A2DP/HFP/LEA
• ผู้ค้นหา: A2DP/HFP

ลักษณะการทำงานที่ควรจะเป็นสำหรับการจับคู่ครั้งแรก / การจับคู่ครั้งต่อๆ ไป

• ผู้ให้บริการโฆษณาข้อมูลบริการจับคู่ด่วน (0xFE2C) พร้อมที่อยู่ (เริ่มต้น) หรือ RPA (ภายหลัง)
  • ใช้การโฆษณาเดิม
• ผู้ค้นหาจะได้รับโฆษณาของผู้ให้บริการที่มีที่อยู่ข้อมูลประจำตัวสำหรับการจับคู่ครั้งแรกหรือ RPA สำหรับการจับคู่ครั้งต่อๆ ไป
• ผู้ค้นหาส่งคำขอการจับคู่ตามคีย์
  • ตั้งค่าบิตแฟล็ก 5 ของคำขอการจับคู่คีย์เป็น 0
• ผู้ให้บริการส่งการตอบกลับการจับคู่ตามคีย์พร้อมที่อยู่สาธารณะในรูปแบบใดรูปแบบหนึ่งต่อไปนี้
  • หากใช้ข้อความประเภท 0x01 ที่อยู่ต้องเป็นที่อยู่สาธารณะ
  • หากใช้ข้อความประเภท 0x02
    • บิตที่ 0 ต้องเป็น 0
    • บิตที่ 1 ต้องเป็น 0
    • ที่อยู่นั้นต้องเป็นที่อยู่สาธารณะ
• ผู้ค้นหาสร้างการเชื่อมโยงกับผู้ให้บริการขนส่ง BR/EDR
  • ตั้งค่าความสามารถของ IO เป็น DisplayYesNo สำหรับ BR/EDR
• ผู้ค้นหาและผู้ให้บริการทำตามขั้นตอนการยืนยันพาสคีย์การจับคู่ด่วน

สถานการณ์ที่ 2 - เมื่อ Seeker สนับสนุน LEA

คอมโพเนนต์

• ผู้ให้บริการ
  • รองรับ A2DP/HFP/LEA
  • คอมโพเนนต์เดียว
• ผู้ค้นหา
  • การสนับสนุนA2DP/HFP/LEA

ลักษณะการทำงานที่ควรจะเป็นสำหรับการจับคู่ครั้งแรก / การจับคู่ครั้งต่อๆ ไป

• ผู้ให้บริการโฆษณาข้อมูลบริการจับคู่ด่วน (0xFE2C) พร้อมที่อยู่ (เริ่มต้น) หรือ RPA (ภายหลัง)
  • ใช้การโฆษณาเดิม
• Seeker ส่งคำขอการจับคู่คีย์
  • ตั้งค่า Flag บิต 5 ของคำขอการจับคู่ตามคีย์เป็น 1
• ผู้ให้บริการส่งการตอบกลับการจับคู่ตามคีย์ที่มีประเภทข้อความ 0x02
  • บิต-0 จะเป็น 0
  • Bit-1 ต้องเป็น 1
  • ที่อยู่คือที่อยู่ประจำตัว
• ผู้ค้นหาจะสร้างการเชื่อมโยงกับการเชื่อมต่อ LE ที่มีอยู่ในการขนส่ง LE
  • ทิศทาง CTKD คือจาก LE ไปยัง BR/EDR
  • ตั้งค่าความสามารถ IO เป็น DisplayYesNo สำหรับ LE
• ผู้ค้นหาและผู้ให้บริการทำตามขั้นตอนการยืนยันพาสคีย์การจับคู่ด่วน

สถานการณ์ที่ 3 - เมื่อ Seeker สนับสนุน LEA และ CSIP ที่เกี่ยวข้อง

คอมโพเนนต์

• ผู้ให้บริการ
  • รองรับ A2DP/HFP/LEA
  • คอมโพเนนต์หลายรายการ
    • คอมโพเนนต์หลักคือ BR/EDR/LE
    • คอมโพเนนต์รองเป็นแบบ LE เท่านั้น
• Seeker
  • รองรับ A2DP/HFP/LEA

ลักษณะการทำงานที่ควรจะเป็นสำหรับการจับคู่ครั้งแรก / การจับคู่ครั้งต่อๆ ไป

• คอมโพเนนต์หลักจะโฆษณาข้อมูลบริการการจับคู่ด่วน (0xFE2C) ด้วยที่อยู่ข้อมูลประจำตัว (เริ่มต้น) หรือ RPA (ต่อจากนี้)
  • ใช้การโฆษณาเดิม
• ผู้ค้นหาส่งคําขอการจับคู่ตามคีย์ไปยังคอมโพเนนต์หลัก
  • ตั้งค่า Flag บิต 5 ของคำขอการจับคู่ตามคีย์เป็น 1
• คอมโพเนนต์หลักจะส่งการตอบกลับการจับคู่ตามคีย์ที่มีประเภทข้อความ 0x02
  • บิตที่ 0 ต้องเป็น 0
  • บิตที่ 1 ต้องเป็น 1
  • ที่อยู่มีดังนี้
    • ที่อยู่แรกคือที่อยู่ข้อมูลประจำตัวของคอมโพเนนต์หลัก
    • ที่อยู่ที่สองคือที่อยู่ที่จะจับคู่ได้สําหรับคอมโพเนนต์รอง ซึ่งคอมโพเนนต์ที่ 2 จะใช้ที่อยู่นี้เพื่อโฆษณา CSIP ด้วย
• ผู้ค้นหาจะสร้างการเชื่อมโยงกับคอมโพเนนต์หลักในการเชื่อมต่อ LE ที่มีอยู่
  • ทิศทาง CTKD คือจาก LE ไปยัง BR/EDR
  • ตั้งค่าความสามารถ IO เป็น DisplayYesNo สำหรับ LE
• ผู้ค้นหาสร้างการเชื่อมโยงกับคอมโพเนนต์รองซึ่งมีที่อยู่มาจากคำตอบแบบขยายของการจับคู่ตามคีย์
  • ความสามารถของ IO ต้องเป็น DisplayYesNo ไม่เช่นนั้นให้ปฏิเสธคําขอจับคู่
• ผู้ค้นหาและผู้ให้บริการทำตามกระบวนการป้องกัน MITM สำหรับการจับคู่คอมโพเนนต์รอง โดยผู้ให้บริการจะต้องติดตั้งใช้งานทั้ง 2 สถานการณ์
  • การป้องกัน MITM - การแจ้งเตือน
  • การป้องกัน MITM - อ่าน
• ตัวค้นหาจะรอจนกว่าจะจับคู่กับคอมโพเนนต์รอง

แผนภาพตามลำดับสำหรับ MITM

เซสชันนี้จะอธิบายลำดับของกระบวนการป้องกันของ MITM

รับพาสคีย์จากคอมโพเนนต์ที่เชื่อมโยงอยู่ผ่านการแจ้งเตือน

รับพาสคีย์จากคอมโพเนนต์ที่จับคู่อยู่ด้วยการอ่าน

ปัญหาที่เป็นที่ทราบแล้ว

FP สำหรับ LEA ได้รับการเพิ่มประสิทธิภาพให้ทำงานร่วมกับ Android V(Android 15) ได้

ในทางกลับกัน เราพบปัญหามากมายเกี่ยวกับชุดหูฟังที่รองรับ LEA แต่ไม่มีการใช้งานฟีเจอร์จับคู่ด่วนผ่าน LEA ที่ถูกต้อง (เช่น ฟีเจอร์จับคู่ด่วนผ่าน Classic เท่านั้น) ตัวอย่างเช่น เมื่อ RPA ของผู้ให้บริการไม่ได้สร้างขึ้นจากคีย์การแก้ไขข้อมูลประจำตัว (IRK) ที่ถูกต้อง และไม่สามารถแก้ไขที่อยู่ได้ แม้ว่าเราจะไม่สามารถทดสอบการกำหนดค่าชุดหูฟังอย่างครอบคลุมได้ แต่การทดสอบแบบจำกัดของเราก็พบปัญหาต่างๆ เช่น ไม่สามารถแสดงการแจ้งเตือนแบตเตอรี่ของหูฟังเอียร์บัด ไม่มีฟังก์ชันการสลับเสียง (SASS) การจับคู่ครั้งแรกและครั้งต่อๆ ไปไม่สำเร็จในวงกว้าง และอื่นๆ

ดังนั้น เราขอแนะนำอย่างยิ่งให้พาร์ทเนอร์ใช้ข้อกำหนดการจับคู่ด่วน-LEA ทั้งสำหรับอุปกรณ์ใหม่และอุปกรณ์ที่มีอยู่ในพื้นที่ (ผ่านการอัปเดตแบบ OTA) ที่รองรับโหมดคู่