אפשר לשפר את הנגישות של מכשירי שמיעה (HA) במכשירים ניידים עם Android באמצעות ערוצי L2CAP (CoC) מבוססי-חיבור דרך Bluetooth עם צריכת אנרגיה נמוכה (BLE). ב-CoC נעשה שימוש במאגר נתונים זמני גמיש של כמה חבילות אודיו כדי לשמור על זרימה קבועה של אודיו, גם אם יש אובדן חבילות. המאגר הזה מספק איכות אודיו למכשירי שמיעה, אבל על חשבון זמן האחזור.
העיצוב של CoC מתייחס לגרסה 5 של מפרט הליבה של Bluetooth (BT). כדי לשמור על התאמה למפרטים הבסיסיים, כל הערכים הרב-בייטיים בדף הזה צריכים להיקרא כ-little-endian.
טרמינולוגיה
- מרכזי
- מכשיר Android שסורק פרסומים באמצעות Bluetooth.
- ציוד היקפי
- מכשיר השמיעה ששולח מנות פרסום באמצעות Bluetooth.
טופולוגיה של רשת וארכיטקטורת מערכת
כשמשתמשים ב-CoC למכשירי שמיעה, טופולוגיית הרשת מניחה שיש מרכז אחד ושני מכשירים היקפיים, אחד בצד שמאל ואחד בצד ימין, כמו שרואים באיור 1. מערכת האודיו ב-Bluetooth רואה את הציוד ההיקפי השמאלי והימני כמקור אודיו יחיד. אם ציוד היקפי חסר, בגלל התאמה מונופונית או אובדן חיבור, המרכז מערבב את ערוץ האודיו השמאלי והימני ומשדר את האודיו לציוד ההיקפי שנותר. אם הרכזת מאבדת את החיבור לשני המכשירים ההיקפיים, היא מחשיבה את הקישור ליעד האודיו כאבוד. במקרים כאלה, האודיו מנותב ליציאה אחרת.
איור 1. טופולוגיה להתאמת מכשירי שמיעה למכשירים ניידים עם Android באמצעות CoC דרך BLE.
אם הרכזת לא מעבירה בסטרימינג נתוני אודיו לציוד ההיקפי ויכולה לשמור על חיבור BLE, הרכזת לא צריכה להתנתק מהציוד ההיקפי. השמירה על החיבור מאפשרת את תקשורת הנתונים עם שרת GATT שנמצא בציוד ההיקפי.
כשמבצעים התאמה וחיבור של מכשירי שמיעה, המרכזייה צריכה:
- כדאי לעקוב אחרי הציוד ההיקפי השמאלי והימני ששויך לאחרונה.
- אם יש התאמה תקפה, מניחים שהציוד ההיקפי נמצא בשימוש. המרכזייה צריכה לנסות להתחבר או להתחבר מחדש למכשיר המותאם כשהחיבור מתנתק.
- אם מוחקים התאמה, מניחים שהציוד ההיקפי לא נמצא יותר בשימוש.
בדוגמאות שלמעלה, התאמה מתייחסת לפעולה של רישום מכשירי שמיעה עם UUID נתון וסימון של צד ימין או צד שמאל במערכת ההפעלה, ולא לתהליך ההתאמה של Bluetooth.
דרישות מערכת
כדי להטמיע את CoC בצורה נכונה ולספק חוויית משתמש טובה, מערכות ה-Bluetooth במכשירים המרכזיים וההיקפיים צריכות:
- להטמיע בקר תואם BT 4.2 ומעלה. מומלץ מאוד להשתמש בחיבורים מאובטחים של LE.
- לתמוך לפחות ב-2 קישורי LE בו-זמנית עם פרמטרים כפי שמתואר בפורמט ותזמון של מנות אודיו.
- התמיכה בציוד ההיקפי צריכה לכלול לפחות קישור LE אחד עם הפרמטרים שמתוארים במאמר פורמט ותזמון של מנות אודיו.
- יש להם בקרת זרימה מבוססת-קרדיט LE [BT Vol 3, Part A, Sec 10.1]. המכשירים צריכים לתמוך בגודל MTU ו-MPS של 167 בייט לפחות ב-CoC, ולשמור במאגר עד 8 חבילות.
- להיות בעלי תוסף של אורך נתונים מסוג LE [BT Vol 6, Part B, Sec 5.1.9] עם מטען ייעודי (payload) של לפחות 167 בייטים.
-
המכשיר המרכזי תומך בפקודה HCI LE Connection Update Command
ועומד בדרישות של הפרמטרים
maximum_CE_Lengthו-minimum_CE_Lengthשאינם אפס. - המרכז צריך לשמור על קצב העברת הנתונים עבור שני חיבורים של LE CoC לשני מכשירים היקפיים שונים עם מרווחי החיבור וגדלי המטען הייעודי (payload) שמופיעים בפורמט ותזמון של מנות אודיו.
-
הגדרת הפרמטרים
MaxRxOctetsו-MaxRxTimeבפרייםLL_LENGTH_REQאוLL_LENGTH_RSPלערכים המינימליים הנדרשים בהתאם למפרטים האלה. כך המערכת המרכזית יכולה לבצע אופטימיזציה של מתזמן הזמן שלה כשהיא מחשבת את משך הזמן שנדרש לקבלת פריים.
מומלץ מאוד שהרכיב המרכזי והרכיב ההיקפי יתמכו ב-2MB PHY כפי שמצוין במפרט BT 5.0. המרכזייה צריכה לתמוך בקישורי אודיו של לפחות 64 kbit/s ב-PHYs של 1M ו-2M. אסור להשתמש ב-PHY לטווח ארוך של BLE.
ב-CoC נעשה שימוש במנגנוני Bluetooth סטנדרטיים להצפנה של שכבת הקישור ולדילוג תדרים.
שירותי ASHA GATT
ציוד היקפי צריך להטמיע את שירות שרת ה-GATT של Audio Streaming for Hearing Aid (ASHA) שמתואר בהמשך. הציוד ההיקפי צריך לפרסם את השירות הזה כשהוא במצב גילוי כללי, כדי שהרכזת תוכל לזהות את יעד האודיו. כל פעולות הסטרימינג של LE Audio חייבות לדרוש הצפנה. הזרמת אודיו ב-BLE כוללת את המאפיינים הבאים:
| מאפיין | מאפיינים | תיאור |
|---|---|---|
| ReadOnlyProperties | קריאה | ראו ReadOnlyProperties. |
| AudioControlPoint | כתיבה וכתיבה ללא תגובה | נקודת בקרה לשידור אודיו. מידע על AudioControlPoint |
| AudioStatusPoint | קריאה/שליחת עדכון | שדה דוח הסטטוס של נקודת הבקרה של האודיו. מידע נוסף זמין במאמר בנושא AudioStatusPoint. |
| עוצמת הקול | כתיבה ללא תגובה | בייט בין -128 ל-0 שמציין את מידת ההנחתה שצריך להחיל על אות האודיו בסטרימינג, בטווח של -48 dB עד 0 dB. הגדרה של -128 צריכה להתפרש כהשתקה מלאה, כלומר, עוצמת הקול הכי נמוכה שלא מושתקת היא -127, ששווה להנחתה של -47.625 dB. בהגדרה 0, צריך להזרים צליל סינוס ממינימום למקסימום שייצג שווה ערך של קלט של 100 dBSPL במכשיר השמיעה. היחידה המרכזית צריכה להזרים בקנה מידה מלא נומינלי ולהשתמש במשתנה הזה כדי להגדיר את רמת ההצגה הרצויה ביחידה ההיקפית. |
| LE_PSM_OUT | קריאה | ה-PSM שבו יש להשתמש לחיבור ערוץ האודיו. כדי לבחור מתוך הטווח הדינמי [BT Vol 3, Part A, Sec 4.22] |
המזהים הייחודיים האוניברסליים (UUIDs) שהוקצו לשירות ולמאפיינים:
Service UUID: {0xFDF0}
| מאפיין | מזהה ייחודי אוניברס |
|---|---|
| ReadOnlyProperties | {6333651e-c481-4a3e-9169-7c902aad37bb} |
| AudioControlPoint | {f0d4de7e-4a88-476c-9d9f-1937b0996cc0} |
| AudioStatus | {38663f1a-e711-4cac-b641-326b56404837} |
| עוצמת הקול | {00e4ca9e-ab14-41e4-8823-f9e70c7e91df} |
| LE_PSM_OUT | {2d410339-82b6-42aa-b34e-e2e01df8cc1a} |
בנוסף לשירות ASHA GATT, הציוד ההיקפי צריך גם להטמיע את שירות מידע המכשיר כדי לאפשר למרכז לזהות את שמות היצרנים ואת שמות המכשירים של הציוד ההיקפי.
ReadOnlyProperties
הערכים של ReadOnlyProperties הם:
| בייט | תיאור |
|---|---|
| 0 | גרסה – הערך חייב להיות 0x01 |
| 1 | כאן אפשר לראות את המאפיינים של המכשיר. |
| 2-9 | ראו HiSyncId. |
| 10 | כאן אפשר לראות את מפת התכונות. |
| 11-12 | RenderDelay. זהו הזמן, באלפיות השנייה, מרגע שהציוד ההיקפי מקבל פריים אודיו ועד שהציוד ההיקפי מעבד את הפלט. אפשר להשתמש בבייטים האלה כדי להשהות סרטון ולסנכרן אותו עם האודיו. |
| 13-14 | שמור לשימוש בעתיד. מאותחלים לאפסים. |
| 15-16 | מזהי Codec נתמכים. זוהי מסיכת ביטים של מזהי קודקים נתמכים. הערך 1 במיקום של ביט מתאים לרכיב קודק נתמך. לדוגמה, הערך 0x0002 מציין שרכיב הקודק G.722 בתדר 16kHz נתמך. כל הביטים האחרים צריכים להיות מוגדרים כ-0. |
DeviceCapabilities
| ביט | תיאור |
|---|---|
| 0 | צד המכשיר (0: שמאל, 1: ימין) |
| 1 | מציין אם המכשיר הוא עצמאי ומקבל נתונים מונופוניים, או אם המכשיר הוא חלק ממערכת (0: מונופוני, 1: בינאורלי) |
| 2 | המכשיר תומך ב-CSIS (0: לא נתמך, 1: נתמך) |
| 3-7 | שמור (מוגדר ל-0) |
HiSyncID
השדה הזה חייב להיות ייחודי לכל המכשירים הבינאורליים, אבל הוא חייב להיות זהה עבור האוזנייה השמאלית והימנית.
| בייט | תיאור |
|---|---|
| 0-1 | מזהה היצרן. זהו מזהה החברה שהוקצה על ידי BTSIG. |
| 2-7 | מזהה ייחודי שמזהה את סט מכשירי השמיעה. המזהה הזה צריך להיות זהה בשני המכשירים ההיקפיים, גם בצד שמאל וגם בצד ימין. |
FeatureMap
| ביט | תיאור |
|---|---|
| 0 | האם נתמכת הזרמת פלט אודיו של LE CoC (כן/לא). |
| 1-7 | שמור (מוגדר ל-0). |
מזהי קודקים
אם הביט מוגדר, הקודק הספציפי הזה נתמך.
| מזהה / מספר הביט | קודק ותדירות דגימה | קצב העברת הנתונים הנדרש | זמן רינדור פריים | חובה במרכזי (C) או בהיקפי (P) |
|---|---|---|---|---|
| 0 | שמורה | שמורה | שמורה | שמורה |
| 1 | G.722 @ 16 kHz | 64 kbit/s | משתנה | C ו-P |
|
המספרים 2 עד 15 שמורים. גם המספר 0 שמור. |
||||
AudioControlPoint
אי אפשר להשתמש בנקודת הבקרה הזו כשה-LE CoC סגור. הוראות מפורטות מופיעות במאמר בנושא הפעלה והפסקה של שידור אודיו.
| קוד פעולה | ארגומנטים | GATT sub-procedure | תיאור |
|---|---|---|---|
1 «Start» |
|
לכתוב עם תגובה, ולצפות להודעת סטטוס נוספת באמצעות מאפיין AudioStatusPoint. |
הפקודה הזו מורה לציוד ההיקפי לאפס את רכיב ה-codec ולהתחיל את ההפעלה של פריים 0. בשדה codec מציינים את מזהה ה-codec שבו יש להשתמש בהפעלה הזו.
לדוגמה, שדה ה-codec הוא '1' עבור G.722 ב-16k Hz. שדה הסיביות של סוג האודיו מציין את סוגי האודיו שקיימים בזרם:
הציוד ההיקפי לא יכול לבקש עדכוני חיבור לפני שמתקבל אופקוד «Stop».
|
2 «Stop» |
ללא | לכתוב עם תגובה, ולצפות להודעת סטטוס נוספת באמצעות מאפיין AudioStatusPoint. | הפקודה הזו גורמת לציוד ההיקפי להפסיק את עיבוד האודיו. כדי להפעיל שוב את האודיו, צריך להתחיל רצף חדש של הגדרת אודיו אחרי ההפסקה הזו. |
3 «Status» |
|
כתיבה ללא תגובה |
ההתראה מודיעה לציוד ההיקפי המחובר שיש עדכון סטטוס בציוד ההיקפי השני. השדה המקושר מציין את סוג העדכון:
|
AudioStatusPoint
שדה דוח הסטטוס של נקודת הבקרה של האודיו
| קודים של פעולות | תיאור |
|---|---|
| 0 | הסטטוס תקין |
| -1 | פקודה לא ידועה |
| -2 | פרמטרים לא חוקיים |
מודעות לקידום שירות ASHA GATT
המזהה הייחודי האוניברסלי של השירות צריך להיות בחבילת המודעות. בפרסומת או במסגרת התגובה של הסריקה, לציוד ההיקפי צריך להיות נתונים של שירות:
| היסט בבייטים | שם | תיאור |
|---|---|---|
| 0 | אורך המודעה | >= 0x09 |
| 1 | סוג המודעה | 0x16 (נתוני שירות – מזהה ייחודי אוניברסלי (UUID) של 16 ביט) |
| 2-3 | מזהה ייחודי אוניברסלי (UUID) של השירות |
0xFDF0 (little-endian) הערה: זהו מזהה זמני. |
| 4 | גרסת הפרוטוקול | 0x01 |
| 5 | יכולת |
|
| 6-9 | HiSyncID קוצר | ארבעת הבייטים המשמעותיים ביותר של HiSyncId. הבייטים האלה צריכים להיות החלק האקראי ביותר במזהה. |
לציוד ההיקפי צריך להיות סוג נתונים של שם מקומי מלא שמציין את השם של מכשיר השמיעה. השם הזה ישמש בממשק המשתמש של המכשיר הנייד כדי שהמשתמש יוכל לבחור את המכשיר הנכון. השם לא יכול לציין את הערוץ השמאלי או הימני, כי המידע הזה מופיע ב-DeviceCapabilities.
אם הציוד ההיקפי מכניס את השם ואת סוגי הנתונים של שירות ASHA לאותו סוג פריים (ADV או SCAN RESP), שני סוגי הנתונים (Complete Local Name ו-Service Data for ASHA service) צריכים להופיע באותו פריים. כך הסורק במכשיר הנייד יכול לקבל את שני סוגי הנתונים באותה תוצאת סריקה.
במהלך ההתאמה הראשונית, חשוב שהציוד ההיקפי ישדר בקצב מהיר מספיק כדי שהמכשיר הנייד יוכל לגלות את הציוד ההיקפי ולהתחבר אליו במהירות.
סנכרון של ציוד היקפי שמאלי וימני
כדי לעבוד עם Bluetooth במכשירי Android ניידים, מכשירים היקפיים אחראים לוודא שהם מסונכרנים. ההפעלה במכשירי הקצה השמאליים והימניים צריכה להיות מסונכרנת בזמן. שני המכשירים ההיקפיים צריכים להשמיע דגימות אודיו מהמקור בו-זמנית.
מכשירים היקפיים יכולים לסנכרן את השעה שלהם באמצעות מספר סידורי שמופיע לפני כל מנה של מטען אודיו. המרכזית מבטיחה שלמנות אודיו שמיועדות להפעלה בו-זמנית בכל הציוד ההיקפי יהיה אותו מספר סידורי. המספר הסידורי גדל באחד אחרי כל מנת אודיו. כל מספר רצף הוא באורך 8 ביט, ולכן מספרי הרצף יחזרו על עצמם אחרי 256 מנות אודיו. מכיוון שגודל כל מנת אודיו וקצב הדגימה קבועים לכל חיבור, שני הציוד ההיקפי יכולים להסיק את זמן ההפעלה היחסי. מידע נוסף על מנות אודיו זמין במאמר בנושא פורמט ותזמון של מנות אודיו.
היחידה המרכזית מספקת טריגרים למכשירים הבינאורליים כשהסנכרון צריך להתבצע. הטריגרים האלה מעדכנים כל ציוד היקפי לגבי הסטטוס של מכשיר הציוד ההיקפי המותאם שלו, בכל פעם שיש פעולה שעשויה להשפיע על הסנכרון. הטריגרים הם:
-
כחלק מהפקודה
«Start»של AudioControlPoint, מוצג מצב החיבור הנוכחי של הצד השני של המכשירים הבינאורליים. -
בכל פעם שיש פעולת חיבור, ניתוק או עדכון של פרמטר חיבור בציוד היקפי אחד, הפקודה
«Status»של AudioControlPoint נשלחת לצד השני של המכשירים הבינאורליים.
פורמט ותזמון של מנות אודיו
אריזת מסגרות אודיו (בלוקים של דגימות) בחבילות מאפשרת למכשיר השמיעה להפיק תזמון מעוגני התזמון של שכבת הקישור. כדי לפשט את ההטמעה:
- מסגרת אודיו צריכה תמיד להתאים למרווח החיבור בזמן. לדוגמה, אם מרווח החיבור הוא 20ms וקצב הדגימה הוא 16 kHz, אז פריים האודיו חייב להכיל 320 דגימות.
- שיעורי הדגימה במערכת מוגבלים למכפלות של 8kHz כדי שתמיד יהיה מספר שלם של דגימות בפריים, בלי קשר לזמן הפריים או למרווח החיבור.
- בייט רצף צריך להופיע לפני פריימים של אודיו. בייט הרצף חייב לספור עם גלישה, ולאפשר לציוד ההיקפי לזהות חוסר התאמה או הצפה של המאגר.
-
פריים אודיו תמיד צריך להתאים לחבילת LE אחת. מסגרת האודיו
צריכה להישלח כמנה נפרדת של L2CAP. הגודל של LE
LL PDU חייב להיות:
גודל מטען הייעודי (payload) של האודיו + 1 (מונה רצף) + 6 (4 בשביל כותרת L2CAP, 2 בשביל SDU) - אירוע חיבור צריך להיות תמיד גדול מספיק כדי להכיל 2 מנות אודיו ו-2 מנות ריקות לאישור (ACK) כדי לשריין רוחב פס לשידור חוזר. הערה: יכול להיות שבקר ה-Bluetooth של המרכזייה יפצל את חבילת האודיו. הציוד ההיקפי צריך להיות מסוגל לקבל יותר מ-2 מנות אודיו מפוצלות לכל אירוע חיבור.
כדי לאפשר גמישות מסוימת במרכז, לא מצוין אורך המנה (packet) של G.722. אורך המנות של G.722 יכול להשתנות בהתאם למרווח החיבור שהוגדר במרכז.
פורמט האוקטט של הפלט G.722 מתייחס אל Rec. ITU-T G.722 (09/2012) section 1.4.4 "Multiplexer"
לכל רכיב codec שציוד היקפי תומך בו, הציוד ההיקפי צריך לתמוך בפרמטרים של החיבור שמופיעים בהמשך. זו רשימה חלקית של הגדרות שהרכזת יכולה להטמיע.
| קודק | קצב העברת נתונים | מרווח בין חיבורים | אורך CE (1M/2M PHY) | גודל המטען הייעודי (payload) של האודיו |
|---|---|---|---|---|
| G.722 @ 16 kHz | 64 kbit/s | 20 אלפיות השנייה | 5,000/3,750 דולר ארה"ב | 160 בייטים |
איך מתחילים ומפסיקים שידור אודיו
לפני שמתחילים שידור אודיו, הרכזת שולחת שאילתות לציוד ההיקפי ומגדירה קודק משותף. לאחר מכן, הגדרת השידור מתבצעת לפי הרצף הבא:
- המערכת קוראת את הערכים של PSM, ואם יש, גם של RenderDelay. יכול להיות שהערכים האלה יישמרו במטמון של המרכזייה.
- ערוץ CoC L2CAP נפתח – המכשיר ההיקפי חייב להעניק 8 נקודות קרדיט בהתחלה.
- מתבצע עדכון של החיבור כדי לשנות את הקישור לפרמטרים שנדרשים עבור הקודק שנבחר. יכול להיות שהעדכון הזה יתבצע לפני החיבור של CoC בשלב הקודם.
- המארח המרכזי והמארח ההיקפי ממתינים לאירוע השלמת העדכון.
-
מפעילים מחדש את מקודד האודיו ומאפסים את ספירת רצף המנות ל-0.
פקודת
«Start»עם הפרמטרים הרלוונטיים מונפקת ב-AudioControlPoint. היחידה המרכזית ממתינה להודעת סטטוס מוצלחת של הפקודה הקודמת«Start»מהיחידה ההיקפית לפני שהיא מתחילה להזרים. ההמתנה הזו מאפשרת לציוד ההיקפי להכין את צינור ההפעלה של האודיו. במהלך סטרימינג של אודיו, העותק צריך להיות זמין בכל אירוע חיבור, גם אם זמן האחזור של העותק הנוכחי הוא לא אפס. - הציוד ההיקפי לוקח את מנת האודיו הראשונה מהתור הפנימי שלו (מספר רצף 0) ומפעיל אותה.
הבעיות המרכזיות הן שפקודת «Stop» לא סוגרת את זרם האודיו. אחרי הפקודה הזו, המכשיר ההיקפי לא צריך להיות זמין בכל אירוע חיבור. כדי להפעיל מחדש את הזרמת האודיו, צריך לבצע את השלבים שלמעלה, החל משלב 5. גם אם המרכז לא משדר אודיו, הוא צריך לשמור על חיבור LE לשירותי GATT.
הציוד ההיקפי לא יכול לשלוח עדכון חיבור למרכז. כדי לחסוך בחשמל, המרכז עשוי להנפיק עדכון חיבור לפריפריה כשהיא לא משדרת אודיו.