אפשר לשפר את הנגישות של מכשירי שמיעה (HA) במכשירים ניידים עם Android באמצעות ערוצי L2CAP (CoC) מבוססי-חיבור דרך Bluetooth עם צריכת אנרגיה נמוכה (BLE). ב-CoC נעשה שימוש במאגר נתונים זמני גמיש של כמה חבילות אודיו כדי לשמור על זרימה קבועה של אודיו, גם אם יש אובדן חבילות. המאגר הזה מספק איכות אודיו למכשירי שמיעה, אבל על חשבון זמן האחזור.
העיצוב של CoC מתבסס על Bluetooth (BT) Core Specification Version 6.0. כדי לשמור על התאמה למפרטים הבסיסיים, כל הערכים הרב-בייטיים בדף הזה צריכים להיקרא כ-little-endian.
טרמינולוגיה
- מרכזי
- מכשיר Android שסורק פרסומים באמצעות Bluetooth.
- ציוד היקפי
- מכשיר השמיעה ששולח מנות פרסום באמצעות Bluetooth.
טופולוגיה של רשת וארכיטקטורת מערכת
כשמשתמשים ב-CoC למכשירי שמיעה, טופולוגיית הרשת מניחה שיש רכזת מרכזית אחת ושני מכשירים היקפיים, אחד בצד שמאל ואחד בצד ימין, כמו שרואים באיור 1. מערכת האודיו ב-Bluetooth רואה את הציוד ההיקפי השמאלי והימני כמקור אודיו יחיד. אם ציוד היקפי חסר, בגלל התאמה מונופונית או אובדן חיבור, המרכז מערבב את ערוץ האודיו השמאלי והימני ומשדר את האודיו לציוד ההיקפי שנותר. אם הרכזת מאבדת את החיבור לשני המכשירים ההיקפיים, היא מחשיבה את הקישור ליעד האודיו כאבוד. במקרים כאלה, האודיו מנותב ליציאה אחרת.
איור 1. טופולוגיה להתאמת מכשירי שמיעה למכשירים ניידים עם Android באמצעות CoC דרך BLE.
אם הרכזת לא מעבירה נתוני אודיו לציוד ההיקפי ויכולה לשמור על חיבור BLE, היא לא אמורה להתנתק מהציוד ההיקפי. השמירה על החיבור מאפשרת תקשורת נתונים עם שרת GATT שנמצא בציוד ההיקפי.
כשמבצעים התאמה וחיבור של מכשירי שמיעה, המרכזייה צריכה:
- כדאי לעקוב אחרי הציוד ההיקפי השמאלי והימני ששויך לאחרונה.
- אם יש התאמה תקפה, מניחים שהציוד ההיקפי נמצא בשימוש. המרכזייה צריכה לנסות להתחבר או להתחבר מחדש למכשיר המותאם כשהחיבור מתנתק.
- אם מוחקים התאמה, מניחים שהציוד ההיקפי לא נמצא יותר בשימוש.
בדוגמאות שלמעלה, התאמה מתייחסת לפעולה של רישום מכשירי שמיעה עם UUID נתון וסימון של צד ימין או צד שמאל במערכת ההפעלה, ולא לתהליך ההתאמה של Bluetooth.
דרישות מערכת
כדי להטמיע את CoC בצורה נכונה ולספק חוויית משתמש טובה, מערכות ה-Bluetooth במכשירים המרכזיים ובמכשירים ההיקפיים צריכות לבצע את הפעולות הבאות:
- מטמיעים בקר תואם BT 4.2 ומעלה. מומלץ מאוד להשתמש ב-LE Secure Connections.
- תמיכה בלפחות שני קישורי LE בו-זמנית במרכז עם פרמטרים כפי שמתואר בפורמט של מנות אודיו ותזמון.
- תמיכה בקישור LE אחד לפחות בציוד ההיקפי עם הפרמטרים שמתוארים במאמר פורמט ותזמון של מנות אודיו.
- תמיכה בבקרת זרימה מבוססת קרדיט LE [BT Vol 3, Part A, Sec 10.1]. המכשירים צריכים לתמוך בגודל MTU ו-MPS של 167 בייטים לפחות ב-CoC, ולהיות מסוגלים לשמור בזיכרון עד שמונה מנות.
- תמיכה בהרחבת אורך הנתונים של LE [BT Vol 6, Part B, Sec 5.1.9] עם מטען ייעודי (payload) של 167 בייט לפחות.
-
מוודאים שהמכשיר המרכזי תומך בפקודה HCI LE Connection Update Command (0x0A)
ושפרמטרים
maximum_CE_Lengthו-minimum_CE_Lengthשונים מאפס. - לשמור על קצב העברת הנתונים במרכז לשני חיבורי LE CoC לשני ציוד היקפי שונים עם מרווחי החיבורים וגדלי המטען הייעודי (payload) בפורמט ותזמון של מנות אודיו.
-
מגדירים את הפרמטרים
MaxRxOctetsו-MaxRxTimeבפרייםLL_LENGTH_REQאוLL_LENGTH_RSPבציוד ההיקפי לערכים המינימליים הנדרשים שדרושים למפרטים האלה. כך המערכת המרכזית יכולה לבצע אופטימיזציה של מתזמן הזמן שלה כשהיא מחשבת את משך הזמן שנדרש לקבלת פריים.
מומלץ מאוד שהרכיב המרכזי והרכיב ההיקפי יתמכו ב-2M 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.
|
Volume |
כתיבה ללא תגובה | בייט בין -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]. |
בטבלאות הבאות מתוארים מזהי ה-UUID שהוקצו לשירות והמאפיינים שלהם.
מזהה ייחודי של שירות: {0xFDF0}
| מאפיין | מזהה ייחודי אוניברס |
|---|---|
ReadOnlyProperties |
{6333651e-c481-4a3e-9169-7c902aad37bb} |
AudioControlPoint |
{f0d4de7e-4a88-476c-9d9f-1937b0996cc0} |
AudioStatus |
{38663f1a-e711-4cac-b641-326b56404837} |
Volume |
{00e4ca9e-ab14-41e4-8823-f9e70c7e91df} |
LE_PSM_OUT |
{2d410339-82b6-42aa-b34e-e2e01df8cc1a} |
בנוסף לשירות ASHA GATT, הציוד ההיקפי צריך גם להטמיע את שירות מידע המכשיר כדי לאפשר למרכז לזהות את שמות היצרנים ואת שמות המכשירים של הציוד ההיקפי.
ReadOnlyProperties
ReadOnlyProperties יכול לקבל את הערכים הבאים:
| בייט | תיאור |
|---|---|
| 0 | גרסה – הערך חייב להיות 0x01 |
| 1 | מידע נוסף מפורט בDeviceCapabilities. |
| 2-9 | מידע נוסף מפורט בHiSyncId. |
| 10 | מידע נוסף מפורט בFeatureMap. |
| 11-12 |
RenderDelay. זהו הזמן, באלפיות השנייה, מרגע שהציוד ההיקפי מקבל פריים אודיו ועד שהציוד ההיקפי מעבד את הפלט. אפשר להשתמש בבייטים האלה כדי להשהות סרטון ולסנכרן אותו עם האודיו.
|
| 13-14 | שמור לשימוש בעתיד. מאותחלים לאפסים. |
| 15-16 | מזהי קודק נתמכים. זוהי מסיכת ביטים של מזהי קודקים נתמכים. הערך 1 במיקום ביט מסוים מציין רכיב קודק נתמך. לדוגמה, הערך 0x0002 מציין שרכיב הקודק G.722 בתדר 16 kHz נתמך. כל הביטים האחרים צריכים להיות מוגדרים כ-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 שמורים. | ||||
AudioControlPoint
אי אפשר להשתמש בנקודת הבקרה הזו כשה-LE CoC סגור. הוראות מפורטות מופיעות במאמר בנושא איך מתחילים ומפסיקים שידור אודיו.
| קוד פעולה | ארגומנטים | GATT sub-procedure | תיאור |
|---|---|---|---|
1 «Start» |
|
לכתוב עם תגובה, ולצפות להודעת סטטוס נוספת באמצעות המאפיין
AudioStatusPoint.
|
הפקודה הזו מורה לציוד ההיקפי לאפס את רכיב ה-codec ולהתחיל את ההפעלה של פריים 0. השדה codec מציין את מזהה ה-codec שבו יש להשתמש להפעלה הזו.
לדוגמה, הערך של השדה codec הוא `1` עבור G.722 ב-16 kHz.שדה הביטים של סוג האודיו מציין את סוגי האודיו שקיימים בזרם:
otherstate מצוין אם הצד השני של מכשירי השמיעה הבינאורליים מחובר.
הערך בשדה הוא 1 כשהמכשיר ההיקפי האחר מחובר, אחרת הערך הוא 0.
הציוד ההיקפי לא יכול לבקש עדכוני חיבור לפני שמתקבל אופקוד «Stop».
|
2 «Stop» |
ללא |
לכתוב עם תגובה, ולצפות להודעת סטטוס נוספת באמצעות המאפיין
AudioStatusPoint.
|
הפקודה הזו גורמת לציוד ההיקפי להפסיק את עיבוד האודיו. כדי להפעיל שוב את האודיו, צריך להתחיל רצף חדש של הגדרת אודיו אחרי ההפסקה הזו. |
3 «Status» |
|
כתיבה ללא תגובה |
ההתראה מודיעה לציוד ההיקפי המחובר שיש עדכון סטטוס בציוד ההיקפי השני. השדה connected מציין את סוג העדכון:
|
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נשלחת לצד השני של המכשירים הבינאורליים.
פורמט ותזמון של מנות אודיו
אריזת מסגרות אודיו (בלוקים של דגימות) בחבילות מאפשרת למכשיר השמיעה להפיק תזמון מעוגני התזמון של שכבת הקישור. כדי לפשט את ההטמעה:
- מסגרת אודיו צריכה תמיד להתאים למרווח החיבור בזמן. לדוגמה, אם מרווח החיבור הוא 20 ms וקצב הדגימה הוא 16 kHz, אז פריים האודיו חייב להכיל 320 דגימות.
- שיעורי הדגימה במערכת מוגבלים למכפלות של 8 kHz כדי שתמיד יהיה מספר שלם של דגימות בפריים, בלי קשר לזמן הפריים או למרווח החיבור.
- בייט רצף צריך להופיע לפני פריימים של אודיו. בייט הרצף חייב לספור עם גלישה, ולאפשר לציוד ההיקפי לזהות חוסר התאמה או הצפה של המאגר.
-
פריים אודיו תמיד צריך להתאים לחבילת LE אחת. מסגרת האודיו
צריכה להישלח כמנה נפרדת של L2CAP. הגודל של LE
LL PDU חייב להיות:
גודל מטען הייעודי (payload) של האודיו + 1 (מונה רצף) + 6 (4 בשביל כותרת L2CAP, 2 בשביל SDU) - אירוע חיבור צריך להיות תמיד גדול מספיק כדי להכיל שני מנות נתונים של אודיו ושני מנות נתונים ריקות לאישור (ACK) כדי לשריין רוחב פס לשידור חוזר. הערה: יכול להיות שבקר ה-Bluetooth של המרכזייה יפצל את חבילת האודיו. הציוד ההיקפי צריך להיות מסוגל לקבל יותר משני חבילות אודיו מפוצלות לכל אירוע חיבור.
כדי לאפשר גמישות מסוימת במרכזייה, לא מצוין אורך המנות של 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 נפתח – המכשיר ההיקפי חייב להעניק שמונה קרדיטים בהתחלה.
- מתבצע עדכון של החיבור כדי לשנות את הקישור לפרמטרים שנדרשים עבור הקודק שנבחר. יכול להיות שהעדכון הזה יתבצע לפני החיבור של CoC בשלב הקודם.
- המארח המרכזי והמארח ההיקפי ממתינים לאירוע השלמת העדכון.
-
מפעילים מחדש את מקודד האודיו ומאפסים את ספירת רצף המנות ל-0.
פקודה
«Start»עם הפרמטרים הרלוונטיים מופעלת ב-AudioControlPoint. המרכז ממתין להודעת סטטוס מוצלחת של הפקודה הקודמת«Start»מהציוד ההיקפי לפני שהוא מתחיל להזרים. ההמתנה הזו מאפשרת לציוד ההיקפי להכין את צינור ההפעלה של האודיו. במהלך סטרימינג של אודיו, העותק צריך להיות זמין בכל אירוע חיבור, גם אם זמן האחזור של העותק הנוכחי הוא לא אפס. - הציוד ההיקפי לוקח את מנת האודיו הראשונה מהתור הפנימי שלו (מספר רצף 0) ומפעיל אותה.
הבעיות המרכזיות הן שפקודת «Stop» לא סוגרת את זרם האודיו. אחרי הפקודה הזו, המכשיר ההיקפי לא צריך להיות זמין בכל אירוע חיבור. כדי להפעיל מחדש את הזרמת האודיו, צריך לבצע את השלבים שלמעלה, החל משלב 5. גם כשהרכזת לא משדרת אודיו, היא צריכה לשמור על חיבור LE לשירותי GATT.
הציוד ההיקפי לא יכול לשלוח עדכון חיבור למרכז. כדי לחסוך בחשמל, המכשיר המרכזי עשוי לשלוח עדכון חיבור למכשיר ההיקפי כשהוא לא מזרים אודיו.