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

ההטמעה של שירות ההתאמה המהירה של Google (GFPS) למכשירי BLE תואמת למפרט הליבה של Bluetooth בגרסה 4.2 ואילך.

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

רמות תאימות

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

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

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

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

בבקשה הגולמית type 0x00 של מאפיין ההתאמה מבוססת-המפתח, ביט 4 משמש לציון אם המכשיר המחפש תומך במפרט המכשיר של Bluetooth LE, וביט 5 משמש לציון אם המכשיר המחפש תומך בLE Audio.

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

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

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

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

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

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

מאפיין של PSM (Protocol Service Multiplexor) של Message Stream

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

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

מאפיין שירות ההתאמה המהירה מוצפנת הרשאות מזהה ייחודי אוניברסלי (UUID)
Message Stream PSM כן קריאה FE2C1239-8366-4814-8EB0-01DE32100BEA
Octet סוג הנתונים תיאור ערך
0 uint8 מדינה
  • 0x00 = לא ידוע. הכלי לחיפוש שגיאות ניסיון ינסה שוב כמה פעמים
  • 0x01 = אפשר להתחבר
  • 0x02 = לא זמין. שירות FP לחיפוש לא ישתמש ברכיב הזה כדי להתחבר הפעם
 משתנה
2-1 uint16 הערך של PSM צריך להיות בטווח שבין 0x80 ל-0xFF משתנה

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

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

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

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

הגנה מפני התקפת MITM על ידי חברים מזויפים ב-CSIS

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

הגדרת מאפיין

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

הודעות

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

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

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

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) משתנה

הרכיב הראשי (הרכיב המקושר הראשון) הוא הגשר בין ה-Fast Pair Seeker לבין רכיבי הקישור הנוספים. המאפיין צריך לעמוד בהנחיות:

  • כשמקבלים בקשת כתיבה מ'מחפש התאמה מהירה', הספק צריך
    • הגדרת הכתובת של הרכיב שמחובר
    • שליחת מפתח הגישה לרכיב שקשור לקישור
    • מגדירים את קוד הסטטוס כ-Pending‏, 0x01
  • כשמקבלים בקשת קריאה לפני שמקבלים מפתח גישה מהרכיב שמחובר, הספק צריך להחזיר הודעה עם
    • מפתח גישה, כל ערך
    • הכתובת של הרכיב שמחובר
    • קוד סטטוס בהמתנה, 0x01
  • לפני שהספק שולח התראה ל-Fast Pair Checkker, הוא מגדיר את התוצאה של בקשת הקריאה באמצעות
    • מפתח הגישה מהרכיב שמחובר
    • הכתובת של הרכיב שמחובר
    • קוד סטטוס הצלחה, 0x00
  • אם יש שגיאה שאי אפשר לשחזר בצד הספק, מגדירים את התוצאה
    • מפתח גישה, כל ערך
    • הכתובת של הרכיב שמחובר
    • קוד סטטוס כשל, 0x02

פרטים נוספים זמינים בתרשים MITM מס' 1 ובתרשים MITM מס' 2.

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

LE Advertising

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

יכולת קישור

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

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

LEA Advertising

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

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

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

יכולת קישור LEA

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

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

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

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

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

זמן לשינוי יכולת הקלט/פלט

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

הסתרת ההודעה בממשק המשתמש

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

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

דרישות Bluetooth

המלצות לאודיו LE באוזניות ל-Android

תמיכה ב-CTKD

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

הודעה על Target

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

תמיכה בשרת GATT EATT

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

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

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

LE Advertising

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

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

מסד הנתונים של GATT יהיה זהה לכל החיבורים של GATT להעברת LE. שירות LE Audio (0x184E) ייכלל במסד הנתונים של GATT בחיבור מהיר.

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

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

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

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

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

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

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

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

תרשים רצף של התקפת MITM

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

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

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

בעיה ידועה

התכונה FP ל-LEA אופטימיזציה לעבודה עם Android V‏(Android 15).

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

לכן, מומלץ מאוד לשותפים להטמיע את המפרט של Fast Pair-LEA גם במכשירים חדשים וגם במכשירים קיימים בשדה (באמצעות עדכונים אוויריים) שתומכים בשני מצבים.