נקודה חשובה: האפשרות להתאמה מהירה של אודיו עם צריכת אנרגיה נמוכה (LEA) זמינה באופן בלעדי נגישים בגרסת Android V. מומלץ מאוד ליישם התאמת מפרט של מכשירי BLE למכשירים שתואמים ל-LEA. ההמלצה הזו שנובעות מהניסיון שלנו שבו נתקלנו בבעיות רבות עם אוזניות יש תמיכה ב-LEA אבל אין התאמה מהירה בין התאמה מהירה לבין הטמעת LEA. לקבלת מידע נוסף כדאי לעיין בקטע בעיה ידועה. ה-FP LEA האישור זמין רק אחרי ההשקה של Android V.

מכשיר Bluetooth עם צריכת אנרגיה נמוכה (BLE)

הטמעת שירות ההתאמה המהירה (GFPS) של Google למכשירי BLE היא תואם ל-Bluetooth Core Specification גרסה 4.2 ואילך.

הנספח הבא למפרט ההתאמה המהירה יאפשר תמיכה למכשירים עם צריכת אנרגיה נמוכה (LE) בלבד ולמכשירים עם צריכת אנרגיה נמוכה (LEA) ב-GFP.

רמות תאימות

מילות המפתח 'יהיה', 'חובה', 'יהיה', 'יכול', 'יכול' ו'יכול' שמצוינות במפרט כמפורט למטה:

מונח	תיאור
חייבת	נדרש כדי – משמש להגדרת דרישות.
חייב	משמש לביטוי: תוצאה טבעית של דרישת חובה שצוינה קודם לכן או הצהרת עובדות שלא ניתן לערער עליה (כזו שתמיד נכונה, ללא קשר לנסיבות).
רצון	זה נכון - משמש רק לצורך הצהרת עובדות.
צריך	מומלץ – מציינים שיש כמה אפשרויות שמומלץ להשתמש בהן כמתאימים במיוחד, אבל לא חובה.
מאי	מותר – משמש להצגת אפשרויות.
יכולה	הוא יכול – משמש לקשר הצהרה באופן סיבתי.

מאפיין התאמה מבוססת-מפתחות

הודעה מהמחפש לספק

הבקשה הגולמית type 0x00 של מאפיין התאמה מבוססת-מפתחות משתמשת ב-Bit 4 כדי לציין אם ה-seeker תומך ב-BLE Device Specification, ומשתמש ב ביט 5 כדי לציין אם ה-Finder תומך ב-LE Audio.

אוקטט	סוג הנתונים	תיאור	ערך	חובה?
0	uint8	סוג הודעה	0x00 = בקשת התאמה מבוססת-מפתח	חובה
1	uint8	דגלים Bit 0 (MSB): הוצאה משימוש ו-Seeker התעלמו. ביט 1: 1 אם המחפש מבקש שהספק יתחיל את החיבור, והבקשה הזו מכילה את כתובת BR/EDR של המחפש. 0 אם לא. ביט 2: 1 אם המחפש מבקש שהספק יודיע לשם הקיים. 0 אם לא. ביט 3: 1 אם מדובר בכתיבה רטרואקטיבית של מפתח חשבון. 0 אם לא. ביט 4: 1 אם המחפש תומך ב-BLE Device Specification. 0 אם לא. Bit 5: 1 אם ה-Finder תומך ב-LE Audio. 0 אם לא. סיביות 6-7 שמורות לשימוש עתידי. יש להתעלם מהן.	משתנה	חובה
2 - 7	uint48	אחת משתי האפשרויות: כתובת BLE הנוכחית של הספק כתובת הזהות של הספק	משתנה	חובה
8 - 13	uint48	כתובת BR/EDR של המבקש	משתנה	הצגה רק אם הוגדר ביט 1 או 3 דגלים
n - 15		ערך אקראי (מלח)	משתנה	חובה

הודעה מהספק למחפש

כשמוגדר ביט 4 של הבקשה, הודעת התשובה החדשה type 0x02 עבור אפשר להשתמש במאפיין הצמדה מבוסס-מפתחות כדי ליצור קשר נוסף למחפש.

אוקטט	סוג הנתונים	תיאור	ערך
0	uint8	סוג הודעה	0x02 = תגובה מורחבת של התאמה מבוססת-מפתחות
1	uint8	דגלים Bit 0 (MSB): 1 אם הספק הוא מכשיר LE בלבד, 0 אחרת. אם הביט 0 מוגדר ל-1, המגיש יניח שביט 1 מוגדר ל-1. ביט 1: 1 אם הספק מעדיף קישור LE, אחרת 0. ביט 2: 1 אם סוג הכתובת של הכתובת השנייה הוא 'אקראי', 0 אם סוג הכתובת ציבורית הוא 'אקראי'. סיביות 3-7 שמורות לשימוש עתידי. יש להתעלם מהן.	משתנה
2	uint8	מספר כתובות הספק (בגרסה הנוכחית, המספר הוא 1 או 2, כי עלינו לשנות את מצב הצפנה של בלוקים ל-AES-CTR אם המספר הוא >= 3)	משתנה
3 - 8 או 3 - 14		הכתובת הראשונה תהיה כתובת הזהות של הכתובת הראשית, שאפשר לקשר אם עדיף לקשר בין BR/EDR הכתובת השנייה תהיה כתובת שאפשר לקשר אליה אם הכתובת המשנית זמינה	משתנה
9 - 15 או 15		ערך אקראי (מלח)	משתנה

ספק שתומך במפרט מכשיר BLE יקרא Bit 4 ו-Bit 5 להבין את היכולות של המחפש

• כאשר Bit 4 הוא 0, הספק יתעלם מ-Bit 5 ויגיב עם הפורמט type 0x01
• כש-Bit 4 הוא 1,
  • לספק LE בלבד, התשובה שלו צריכה להיות type 0x02 כדי לציין LE העדפה ליצירת קשרים.
  • לספק של מצב כפול, הוא יכול לתת תשובה עם type 0x02 כדי לציין העדפה לחיבור בין BR/EDR או LE.
• לטיפול במקרים של ספק מצב כפול של LE Audio (LEA): דוגמה: התאמה עם ספק מצב כפול של LEA לצורך השוואה

מאפיין PSM של שידור הודעות (Protocol Service Multiplexor)

כדי לתמוך בשידור הודעות במכשירי BLE, התכונה 'התאמה מהירה' תיצור לתחזק ערוץ BLE L2CAP לשליחה ולקבלה של הודעות. התאמה מהירה שרת L2CAP ישתמש בבקרת זרימה מבוססת-אשראי מסוג LE.

מאפיין זה מאפשר למחפש לקרוא את ערך ה-PSM ולאחר מכן ליצור חיבור L2CAP מאובטח באמצעות ערך ה-PSM.

מאפיין שירות ההתאמה המהירה	מוצפנת	הרשאות	מזהה ייחודי אוניברסלי (UUID)
PSM של שידור הודעות	כן	קריאה	FE2C1239-8366-4814-8EB0-01DE32100BEA

אוקטט	סוג הנתונים	תיאור	ערך
0	uint8	מדינה 0x00 = לא ידוע. המערכת של חיפוש FP תנסה שוב מספר פעמים 0x01 = מוכן לחיבור 0x02 = לא זמין. רכיב FP לחיפוש לא ישתמש ברכיב הזה כדי להתחבר הפעם	משתנה
2-1	uint16	ערך PSM יהיה בטווח שבין 0x80 ל-0xFF	משתנה

הערה: ב-TWS, יש מהרכיבים הבאים: ראשי ומשני. התפקיד של הרכיבים האלה שניתנים להחלפה בתנאים מסוימים. בהנחה ש-A הוא רכיב ראשי ו-B הוא רכיב משני, עקב התרוקנות הסוללה של רכיב A , יש צורך ברכיב B יכול לקחת את תפקיד הרכיב הראשי, והתרחיש הזה נקרא role switch.

אחרי role switch, אם הספק לא ניתן לטפל בשידור ההודעות בהתאמה המהירה, היא תנתק באופן יזום את חיבור L2CAP קיים. מי שרוצה את ההתאמה המהירה יכול ליצור מחדש את L2CAP חיבור לשידור הודעות עם הרכיב הראשי החדש.

מאפיין נוסף של מפתח גישה

מאפיין זה נועד לספק הגנה מפני MITM רכיבים.

הגנת CSIS Fake Member MITM

כדי להשתמש בהתאמה מהירה נדרשת הגנת MITM במסגרת תהליך ההתאמה. כ-CSIS לא מספק הגנת MITM, התכנון הנוכחי של FP למספר צריך להרחיב את הרכיבים כדי לספק הגנה מפני MITM רכיבים.

הגדרת מאפיין

מאפיין השירות להתאמה מהירה	מוצפנת	הרשאה	מזהה ייחודי אוניברסלי (UUID)
מפתח גישה נוסף	כן	קריאה,כתיבה,עדכון	FE2C123A-8366-4814-8EB0-01DE32100BEA

הודעות

פורמט ההודעה חל על פעולות קריאה, כתיבה ושליחת הודעות.

פורמט נתונים מוצפן

הנתונים המוצפנים נשלחים באמצעות חיבור GATT בהתאמה מהירה.

אוקטט	סוג הנתונים	תיאור	ערך
0-15	uint128	חסימה של מפתח גישה נוסף מוצפן	משתנה

פורמט של נתונים גולמיים

לאחר פענוח הנתונים המוצפנים באמצעות סוד משותף, הפורמט הוא כך:

אוקטט	סוג הנתונים	תיאור	ערך
0	uint8	סוג הודעה	אחד מ- 0x00 = מפתח הגישה של המחפש 0x01 = מפתח הגישה של הספק
1-3	uint24	מפתח גישה בן 6 ספרות	משתנה
4-9	uint48	הכתובת של רכיב הקישור ליעד	משתנה
10	uint8	קוד סטטוס, משמש רק בפעולת קריאה	אחד מ- 0x00 = הצלחה 0x01 = בהמתנה. ניסיון חוזר של מחפש FP עד זמן קצוב לתפוגה 0x02 = כישלון. ניסיון חוזר להפסקת ההצגה של FP
11-15		ערך אקראי (מלח)	משתנה

הרכיב העיקרי (הרכיב הראשון הקשור) הוא הגשר בין ההתאמה המהירה המחפש ורכיבי החיבור הנוספים. המאפיין יש לפעול בהתאם להנחיות:

• כשמקבלים בקשת כתיבה מ'המחפש התאמה מהירה', הספק
  • צריך להגדיר את הכתובת של הרכיב שאליו רוצים לקשר
  • שליחת מפתח הגישה לרכיב שקשור לקישור
  • יש להגדיר את קוד הסטטוס למצב 'בהמתנה', 0x01
• כשמקבלים בקשת קריאה לפני שמקבלים מפתח גישה מהרכיב את הקשר, הספק יחזיר הודעה עם
  • מפתח גישה, כל ערך
  • הכתובת של הרכיב שאליו רוצים לקשר
  • קוד סטטוס בהמתנה, 0x01
• לפני שהספק שולח התראה למחפש ההתאמה המהירה, מגדיר את התוצאה. לבקשת הקריאה עם
  • מפתח הגישה מהרכיב שרוצים לקשר
  • הכתובת של הרכיב שאליו רוצים לקשר
  • קוד סטטוס הצלחה, 0x00
• אם קיימת שגיאה שלא ניתן לשחזר בצד הספק, מגדירים את התוצאה
  • מפתח גישה, כל ערך
  • הכתובת של הרכיב שאליו רוצים לקשר
  • קוד סטטוס של כישלון, 0x02

ראו תרשים MITM ו תרשים MITM 2 לפרטים נוספים.

דרישות של מכשיר LE

פרסום LE

עבור מצב ניתן לגילוי או מצב בלתי ניתן לגילוי, הספק ישתמש ב-RPA כדי לפרסם נתוני התאמה מהירה.

יכולת חיבור

במכשירים שתומכים ב-LE, המחפש צריך ליצור קשר עם חיבור LE. אחרי שעוברים את האימות שמבוסס על מפתחות להתאמה מהירה, הספק יאפשר התקשרות עם RPA ויגדיר את יכולת הקלט (IO) כ-DisplayYesNo לצורך אימות מפתח גישה להתאמה מהירה.

דרישות למכשיר LEA

פרסום LEA

במכשירים עם שני פיצ'רים: במצב גלוי, הספק יפרסם נתוני התאמה מהירה עם Identity address. במקרה שלא ניתן לגלות את המצב, הספק יפרסם את נתוני ההתאמה המהירה באמצעות RPA. מומלץ מאוד להשתמש במודעות מדור קודם (BT 4.2) כדי לתמוך בתוכניות ישנות יותר לצורך תאימות לאחור. חובה לשנות את ה-IRK בכל פעם שהמכשיר מתאפס להגדרות המקוריות.

במכשירים ללא מצב כפול: עבור מצב גלוי או מצב שלא ניתן לגילוי, הספק ישתמש במצב מורחב פרסום (BT 5.0) עם RPA כדי לפרסם נתונים של התאמה מהירה.

המודעה המחוברת ל-LE שמכילה נתונים של שירות FP תכלול CAS UUID בהתאם Bluetooth Adapter Profile (BAP 1.0.1) פרופיל אודיו נפוץ לדרישה. לפרסומת שאינה ניתנת לגילוי אם אין מספיק מקום פנוי בפרסומת מדור קודם בגלל ההכללה של נתוני סוללה ו-SASS, במקרה כזה, חובה לכלול CAS UUID בתגובה לסריקה.

יכולת קישור LEA

המחפש צריך ליצור קשר עם חיבור ה-LE הקיים. אחרי המעבר אימות התאמה מהירה באמצעות מפתחות, ספק המצב הכפול יאפשר יצירת קשר עם כתובת זהות ו-RPA חיבור ל-RPA, והגדרת יכולת ה-IO, DisplayYesNo להתאמה מהירה אימות מפתח הגישה.

ערוץ תקשורת פנימי בין רכיבים

חיבור ה-GATT הקיים נשמר כדי לבצע הגנת MITM רכיבים נוספים. הרכיב הראשי המקושר יטפל בהודעה בין Fast Pairseeker לבין שאר הרכיבים שלו.

התקשורת הפנימית משמשת עבור Initial Pair ו-Subsequent Pair

• כשתהליך התאמה מבוססת-מפתחות עובר אל הרכיב הראשי, הרכיב ישלח הודעה כדי לשנות את יכולת ה-IO של שנותר רכיבים
• לאחר השלמת ההתאמה המהירה, הרכיב הראשי ישלח הודעה לאיפוס יכולת IO של שאר הרכיבים שלו
• כשמפעילים תהליך של מפתח גישה נוסף, הרכיב הראשי צריך לטפל מסירת מפתחות גישה בין התכונה 'חיפוש באמצעות התאמה מהירה' לבין שאר הרכיבים שלה

הגיע הזמן לשנות את יכולת הקלט (IO)

• שינוי היכולת של הקלט/פלט (IO) ל-DisplayYesNo לאחר השלמת תהליך ההתאמה מבוססת-המפתח
  • אם המכשיר כולל מספר רכיבים, יש להגדיר את כל הרכיבים DisplayYesNo
  • חריג אחד שלפיו הספק צריך אין לשנות את יכולת ה-IO ל-DisplayYesNo היא Retroactive Pair, ש-Bit 3 שלו של 'בקשת התאמה מבוססת-מפתחות' מוגדרת ל-1. ראו הודעה מהמחפש לספק
• שינוי יכולת הקלט/פלט (IO) להגדרת ברירת המחדל
  • התאמה ראשונית
    • אם חיבור ה-LE מנותק, צריך לסיים את ההתאמה המהירה
    • אם לא נדרשת כתיבה נוספת של מפתח גישה, אחרי החיבור של המפתח הראשי בקשה בעוד 15 שניות, סיום הסשן של ההתאמה המהירה
    • אחרי שמתקבלת בקשת כתיבה נוספת של מפתח גישה, אם הרכיב לא נוצר קשר בתוך 15 שניות. כלומר, מסיים את סשן ההתאמה המהירה
    • לאחר קישור כל הרכיבים, אם לא נדרשת כתיבה של מפתח לחשבון בקשה תוך 15 שניות, סיום סשן ההתאמה המהירה
    • לאחר שהתקבלה בקשה לכתיבה של מפתח חשבון, מגדירים זמן קצוב לתפוגה של 15 שניות לערך סיום ההתאמה המהירה
  • ההתאמה הבאה
    • אם חיבור ה-LE מנותק, צריך לסיים את ההתאמה המהירה
    • אם לא נדרשת כתיבה נוספת של מפתח גישה, אחרי החיבור של המפתח הראשי בקשה תוך 15 שניות, סיום סשן ההתאמה המהירה
    • אחרי שמתקבלת בקשת כתיבה נוספת של מפתח גישה, אם הרכיב לא נוצר קשר בתוך 15 שניות. כלומר, מסיים את סשן ההתאמה המהירה
    • לאחר קישור כל הרכיבים, סיום ההתאמה המהירה

הסתרת אינדיקציה לממשק המשתמש

כשהאוזניות לא מוכנות להתאמה, הספק ישתמש ב-type 0b0010 כדי להגדיר אינדיקטור של הסתרה של ממשק המשתמש לנתונים של מפתח החשבון, כדי להנחות את המחפש לא להציג ממשק משתמש של התאמה מאוחרת יותר (למידע נוסף, ניתן לעיין בקטע מטען ייעודי (payload) של פרסום: נתוני חשבון בהתאמה מהירה).

דרישות למכשיר LE Audio

דרישות Bluetooth

כדאי לעיין במאמר המלצות ל-Android, לאוזניות LE Audio.

תמיכה ב-CTKD

במכשירים עם מצב כפול, חובה להשתמש ב-CTKD מ-LE ל-BR/EDR, או בתאימות ל דרישות של BAP.

הכרזה על היעד

ציוד היקפי ישתמש בהודעה ממוקדת כדי לבקש חיבור ממכשיר מרכזי מותאם. הודעות מטורגטות מוגדרות ב-BAP וב-CAP לניהול החיבורים בהתאם ל-CAP 1.0 בטבלה 8.4 (p48/58).

תמיכה בשרת GATT EATT

פרוטוקול EATT מאפשר למכשיר המרכזי לשלוח עסקאות GATT מרובות במקביל כשהמכשיר מחובר. במכשיר שתומך ב-CSIP, העלייה תגדל את הביצועים של חיבור הפרופיל, ובקרוב מתחילים ליצור קשר עם CSIP עבור האוזניות האחרות.

שמירה במטמון חזק של GATT (מומלץ מאוד)

אם הספק הוא לא מכשיר יחיד אלא הגדרה מתואמת עם הטמעת CSIP, כדי לצמצם את מספר לגילוי השירות והאצת החיבור, הספק צריך להטמיע שמירה במטמון GATT שהוגדר ב-Bluetooth 5.1.

הדרישות להתאמה מהירה

פרסום LE

עבור מצב גלוי או מצב בלתי גלוי, אם למכשיר יש מספר רכיבים, נתוני התאמה מהירה יפורסמו על ידי הרכיב הראשי. אם המכשיר לא מוכן להתאמה הבאה, הרכיב המשני לפרסם נתונים של התאמה מהירה בשביל תכונות מורחבות. לראות הסתרת האינדיקציה לממשק המשתמש.

הרשאות הגישה לשירות GATT

מסד הנתונים של GATT צריך להיות זהה לכל חיבורי ה-GATT מסוג LE Transport. LE Audio (0x184E) ייכללו במסד הנתונים של GATT של חיבור בהתאמה מהירה.

דוגמה: התאמה לספק במצב LEA כפול

תרחיש 1 – כאשר המחפש לא תומך ב-LEA

לספק תהיה תאימות לאחור למחפש שלא תמיכה ב-LEA.

רכיבים

• ספק: A2DP/HFP/LEA
• מחפש: A2DP/HFP

ההתנהגות הצפויה של זוג ראשוני / הזוג העוקב

• הספק מפרסם את שירות ההתאמה המהירה נתונים (0xFE2C) עם כתובת זהות (ראשית) או RPA (בהמשך).
  • שימוש בפרסום מדור קודם
• המחפש מקבל פרסומת עם כתובת זהות שתשמש כראשי או כמודעה RPA להתאמה לאחר מכן
• המחפש שולח בקשה להתאמה מבוססת-מפתח
  • ביט-5 הדגל של בקשת התאמה מבוססת-מפתחות מוגדר ל-0
• הספק שולח תגובת התאמה מבוססת-מפתח עם כתובת ציבורית באחת הבאים:
  • אם נעשה שימוש בסוג הודעה 0x01, הכתובת תהיה כתובת ציבורית.
  • אם סוג ההודעה הוא 0x02
    • Bit-0 יהיה 0
    • Bit-1 יהיה 0
    • הכתובת תהיה כתובת ציבורית
• מי שרוצה יוצר קשר עם תדרי BR/EDR
  • היכולת IO מוגדרת כ-DisplayYesNo ל-BR/EDR
• תהליך האימות של מפתח גישה להתאמה מהירה בין המחפש והספק

תרחיש 2 – כאשר המחפש תומך ב-LEA

רכיבים

• ספק
  • תמיכה ב-A2DP/HFP/LEA
  • רכיב יחיד
• מחפש
  • SupportA2DP/HFP/LEA

ההתנהגות הצפויה של זוג ראשוני / הזוג העוקב

• הספק מפרסם את שירות ההתאמה המהירה נתונים (0xFE2C) עם כתובת זהות (ראשית) או RPA (בהמשך).
  • שימוש בפרסום מדור קודם
• המחפש שולח בקשה להתאמה מבוססת-מפתח
  • ביט-5 הדגל של בקשת התאמה מבוססת-מפתחות מוגדר ל-1
• הספק שולח תגובת התאמה מבוססת-מפתחות עם סוג ההודעה 0x02
  • Bit-0 יהיה 0
  • Bit-1 יהיה 1
  • הכתובת היא כתובת זהות
• המחפש יוצר קשר עם חיבור LE בתעבורה LE
  • הכיוון של CTKD הוא מ-LE ל-BR/EDR
  • יכולת ה-IO מוגדרת כ-DisplayYesNo for LE
• תהליך האימות של מפתח גישה להתאמה מהירה בין המחפש והספק

תרחיש 3 – כאשר המחפש תומך ב-LEA וב-CSIP מעורבים

רכיבים

• ספק
  • תמיכה ב-A2DP/HFP/LEA
  • רכיבים מרובים
    • הרכיב הראשי הוא BR/EDR/LE
    • הרכיב המשני הוא LE בלבד
• מחפש
  • תמיכה ב-A2DP/HFP/LEA

ההתנהגות הצפויה של זוג ראשוני / הזוג העוקב

• הרכיב הראשי מפרסם את ההתאמה המהירה נתוני שירות (0xFE2C) עם כתובת זהות (ראשית) או RPA (המשך).
  • שימוש בפרסום מדור קודם
• המחפש שולח בקשת התאמה מבוססת-מפתחות לרכיב הראשי
  • ביט-5 הדגל של בקשת התאמה מבוססת-מפתחות מוגדר ל-1
• הרכיב הראשי שולח תגובת התאמה מבוססת-מפתחות עם סוג ההודעה 0x02
  • Bit-0 יהיה 0
  • Bit-1 יהיה 1
  • הכתובות הן :
    • הכתובת הראשונה היא כתובת הזהות של הרכיב הראשי
    • הכתובת השנייה היא הכתובת שאפשר לקשר לרכיב המשני, הרכיב השני משתמש גם בכתובת הזאת כדי לבצע פרסום של CSIP
• המחפש יוצר קשר עם רכיב בחיבור ה-LE הקיים
  • הכיוון של CTKD הוא מ-LE ל-BR/EDR
  • יכולת ה-IO מוגדרת כ-DisplayYesNo עבור LE
• המחפש יוצר קשר עם רכיב שהכתובת שלו היא מהתאמה מורחבת של מפתחות
  • היכולת IO תהיה מסוג DisplayYesNo. אחרת, יש לדחות את בקשת ההתאמה
• המחפש והספק מבצעים תהליך הגנת MITM לצורך התאמה של הרכיב המשני, הספק יטמיע את שני התרחישים
  • הגנת MITM – התראה
  • הגנת MITM – קריאה
• המחפש ימתין עד להתחברות לרכיב המשני

תרשים רציף ל-MITM

הסשן הזה מתאר את הרצף של התהליך להגנה מפני MITM.

קבלת מפתח גישה מהרכיב שמקושר בהתראה

קבלת מפתח גישה מהרכיב שמקושר באמצעות קריאה

בעיה ידועה

שיטת FP for LEA עברה אופטימיזציה לעבודה עם Android V.

לעומת זאת, נתקלנו במספר בעיות באוזניות שתומכות ב-LEA אבל אין התאמה מהירה עם הטמעת LEA בצורה נכונה (כלומר, רק התאמה מהירה מעל קלאסי). באופן ספציפי, ולדוגמה, במקרים שבהם לא נוצרת RPA של הספק באמצעות המפתח הנכון לפתרון זהויות (IRK), ולא ניתן לפענח את הכתובת. לא הצלחנו לבדוק רשימה מקיפה של אוזניות האישיות שלנו, הבדיקות המוגבלות שלנו חשפו בעיות שונות, כולל כשלים כדי להציג התראות על הסוללה של אוזניית הכפתור, היעדר מעבר לאודיו (SASS) פונקציונליות, כשלים ראשוניים רחבים בהתאמה הראשונית ועוד.

לכן, אנחנו ממליצים בחום לשותפים להטמיע את האפשרות 'התאמה מהירה' מפרט למכשירים חדשים ולמכשירים קיימים בשדה (באמצעות עדכונים אלחוטיים) שתומכים בשני מצבים.