תמיכה באודיו למכשירי שמיעה באמצעות Bluetooth LE

אפשר לשפר את הנגישות של מכשירי שמיעה (HA) במכשירים ניידים עם Android באמצעות שימוש בערוצי L2CAP (CoC) שמתמקדים בחיבור דרך Bluetooth עם צריכת אנרגיה נמוכה (BLE). ב-CoC נעשה שימוש במאגר גמיש של כמה חבילות אודיו כדי לשמור על זרימת אודיו יציבה, גם אם יש אובדן חבילות. המאגר הזה מספק איכות אודיו למכשירי שמיעה, על חשבון זמן האחזור.

העיצוב של CoC מבוסס על Bluetooth Core Specification Version 5 (BT). כדי לשמור על תאימות למפרט הליבה, כל הערכים שמכילים כמה בייטים בדף הזה יקראו בתור 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, ולהיות מסוגלים לאחסן ב-buffer עד 8 חבילות.
• יש להן תוספת של אורך הנתונים ב-LE‏ [BT Vol 6, Part B, Sec 5.1.9] עם עומס שימושי של לפחות 167 בייטים.
• המכשיר המרכזי צריך לתמוך בפקודה HCI LE Connection Update ולעמוד בפרמטרים maximum_CE_Length ו-minimum_CE_Length שאינם אפס.
• לאפשר למכשיר המרכזי לשמור על קצב העברת הנתונים בשני חיבורי LE CoC לשני ציוד היקפי שונה, עם מרווחי ההתחברות וגדלי המטען השימושי בפורמט וזמן של חבילות אודיו.
• מגדירים את הפרמטרים MaxRxOctets ו-MaxRxTime בפריימים LL_LENGTH_REQ או LL_LENGTH_RSP של הציוד ההיקפי לערכי המינימום הנדרשים, הנחוצים למפרטים האלה. כך המערכת המרכזית יכולה לבצע אופטימיזציה של מתזמן הזמן שלה כשהיא מחשבת את משך הזמן הנדרש לקבלת פריים.

מומלץ מאוד שהרכיב המרכזי והרכיב ההיקפי יתמכו ב-PHY בנפח 2MB, כפי שמפורט במפרט BT 5.0. המכשיר המרכזי צריך לתמוך בקישורי אודיו של לפחות 64kbit/s גם ב-PHY של 1M וגם ב-PHY של 2M. אסור להשתמש ב-PHY לטווח ארוך של BLE.

ב-CoC נעשה שימוש במנגנוני Bluetooth הרגילים להצפנה בשכבת הקישור ולקפיצת תדרים.

שירותי ASHA GATT

ציוד היקפי צריך ליישם את שירות השרת של GATT ל-Audio Streaming for Hearing Aid‏ (ASHA) שמתואר בהמשך. ההתקן ההיקפי צריך לפרסם את השירות הזה כשהוא במצב גלוי לכולם, כדי לאפשר להתקן המרכזי לזהות מקור אודיו. כל פעולות הסטרימינג של אודיו LE ידרשו הצפנה. סטרימינג של אודיו ב-BLE כולל את המאפיינים הבאים:

מאפיין	מאפיינים	תיאור
ReadOnlyProperties	קריאה	ראו ReadOnlyProperties.
AudioControlPoint	'כתיבה' ו'כתיבה ללא מענה'	נקודת בקרה לשידור אודיו. AudioControlPoint
AudioStatusPoint	קריאה/עדכון	שדה דוח הסטטוס של נקודת הבקרה של האודיו. ראו AudioStatusPoint.
עוצמת הקול	כתיבת הודעה ללא תגובה	בייט בין -128 ל-0 שמציין את מידת ההפחתה שתחול על אות האודיו בסטרימינג, בטווח של -48 dB עד 0 dB. ההגדרה ‎-128 תובן כהשתקה מלאה, כלומר רמת עוצמת הקול הנמוכה ביותר שלא הושתקה היא ‎-127, ששווה ל-47.625 dB‏ attenuation. בהגדרה 0, שידור של צליל סינוס מקצה לקצה מייצג ערך קלט שווה ערך של 100 dBSPL במכשיר השמיעה. הזרמה במרכז תתבצע בקנה מידה מלא ותשתמש במשתנה הזה כדי להגדיר את רמת הצגה הרצויה בציוד ההיקפי.
LE_PSM_OUT	קריאה	PSM לשימוש בחיבור של ערוץ האודיו. לבחירה מתוך הטווח הדינמי [BT Vol 3, Part A, Sec 4.22]

מזהי ה-UUID שהוקצו לשירות ולמאפיינים:

Service UUID: ‏ {0xFDF0}

מאפיין	UUID
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	DeviceCapabilities
2-9	HiSyncId
10	מידע נוסף זמין במאמר FeatureMap.
11-12	RenderDelay. זהו הזמן, באלפיות השנייה, מרגע שהציוד ההיקפי מקבל פריים אודיו ועד שהציוד ההיקפי מעבד את הפלט. אפשר להשתמש ביחידות הבאיט האלה כדי לעכב את הסרטון כדי שהוא יסתנכרן עם האודיו.
13-14	שמור לשימוש בעתיד. מפעילים את האפסים.
15-16	מזהי הקודקים הנתמכים. זוהי מסיכת ביט של מזהי הקודקים הנתמכים. 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‏ @ 16kHz	64 kbit/s	משתנה	C ו-P
השמות 2 עד 15 שמורים. 0 הוא גם שמור.

AudioControlPoint

לא ניתן להשתמש בנקודת הבקרה הזו כשהקודקס של LE סגור. תיאור התהליך מופיע במאמר התחלה והפסקה של שידור אודיו.

קוד פעולה	ארגומנטים	תהליך משנה של GATT	תיאור
1 «Start»	uint8_t codec uint8_t audiotype int8_t volume int8_t otherstate	כותבים עם תגובה, ומצפים לקבלת התראה נוספת על הסטטוס באמצעות המאפיין AudioStatusPoint.	הפקודה מורה להתקן ההיקפי לאפס את הקודק ולהתחיל את ההפעלה של הפריים 0. בשדה ה-codec מצוין מזהה ה-codec שישמש להפעלה הזו. לדוגמה, שדה ה-codec הוא '1' עבור G.722 ב-16k Hz. שדה הביטים של סוג האודיו מציין את סוגי האודיו שנמצאים בסטרימינג: 0 – לא ידוע 1 – רינגטון 2 – שיחת טלפון 3 – מדיה המשמעות של השדה otherstate היא אם הצד השני של המכשירים הדו-אוזניים מחובר. הערך בשדה הוא 1 כשמכשיר ההיקפי השני מחובר, אחרת הערך הוא 0. ציוד ההיקפי לא יבקש עדכוני חיבור לפני קבלת קוד הפקודה «Stop».
2 «Stop»	ללא	כותבים עם תגובה, ומצפים לקבלת התראה נוספת על הסטטוס באמצעות המאפיין AudioStatusPoint.	הפקודה מורה לציוד ההיקפי להפסיק את העיבוד של האודיו. אחרי העצירה הזו, צריך להתחיל רצף הגדרה חדש של אודיו כדי להפעיל שוב את העיבוד של האודיו.
3 «Status»	uint8_t connected	כתיבת הודעה ללא תגובה	מודיע לציוד ההיקפי המחובר שיש עדכון סטטוס בציוד ההיקפי השני. השדה המחובר מציין את סוג העדכון: 0 – ציוד היקפי מסוג אחר מנותק 1 – ציוד היקפי מסוג אחר מחובר 2 – עדכון של פרמטר החיבור ל-LE התרחש באחד מהחיבורים

AudioStatusPoint

שדה דוח הסטטוס של נקודת הבקרה של האודיו

קוד פעולה	תיאור
0	סטטוס תקין
-1	פקודה לא ידועה
-2	פרמטרים לא חוקיים

מודעות לשירות ASHA GATT

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

היסט בייטים	שם	תיאור
0	אורך המודעה	>= 0x09
1	סוג המודעה	0x16 (Service Data – UUID של 16 ביט)
2-3	מזהה UUID של השירות	0xFDF0 (little-endian) הערה: זהו מזהה זמני.
4	גרסת הפרוטוקול	0x01
5	יכולת	0 – צד שמאל (0) או צד ימין (1) 1 – מכשיר יחיד (0) או שני מכשירים (1). 2 – המכשיר תומך ב-CSIS (פחות מ-0: לא נתמך, 1: נתמך) 3-7 – שמורות. הביטים האלה חייבים להיות אפס.
6-9	HiSyncID קטועה	ארבעת הבייטים המשמעותיים ביותר של HiSyncId. הבייטים האלה צריכים להיות החלק הכי אקראי במזהה.

לציוד ההיקפי צריך להיות סוג נתונים של Complete Local Name שמציין את שם מכשיר השמיעה. השם הזה ישמש בממשק המשתמש של המכשיר הנייד כדי שהמשתמש יוכל לבחור את המכשיר הנכון. השם לא יכול לציין את הערוץ הימני או הימני, כי המידע הזה מופיע ב-DeviceCapabilities.

אם הפריטים ההיקפיים מציבים את השם ואת סוגי הנתונים של שירות ASHA באותו סוג מסגרת (ADV או SCAN RESP), שני סוגי הנתונים ('Complete Local Name' ו-'Service Data for ASHA service') יופיעו באותה מסגרת. כך הסורק של המכשיר הנייד יכול לקבל את שני סוגי הנתונים באותה תוצאת סריקה.

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

סנכרון של ציוד היקפי שמאלי וימני

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

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

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

• כחלק מהפקודה «Start» של AudioControlPoint, מוצג סטטוס החיבור הנוכחי של הצד השני של המכשירים הדו-אוזניים.
• בכל פעם שמתבצעת פעולה של חיבור, ניתוק או עדכון של פרמטר החיבור באחד מהציוד ההיקפי, הפקודה «Status» של AudioControlPoint נשלחת לצד השני של המכשירים הדו-אוזניים.

הפורמט והתזמון של מנות האודיו

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

• פריים אודיו צריך תמיד להתאים לפרק הזמן של מרווח ההתחברות. לדוגמה, אם פרק הזמן בין החיבורים הוא 20ms ותדירות הדגימה היא 16kHz, מסגרת האודיו תכיל 320 דגימות.
• שיעורי הדגימה במערכת מוגבלים למכפילים של 8kHz כדי שתמיד יהיה מספר שלם של דגימות בפריים, ללא קשר לזמן הפריים או למרווח הזמן בין החיבורים.
• צריך להוסיף בייט של רצף לתחילת הפריימים של האודיו. הבאיט של הרצף צריך להכיל ספירה עם חזרה לתחילת הרצף, ולאפשר להתקן ההיקפי לזהות אי-התאמה של מאגר או מצב של מחסור בנתונים.
• תמיד צריך להכניס פריים אודיו לחבילת LE אחת. הפריימים של האודיו צריכים להישלח כחבילת L2CAP נפרדת. הגודל של ה-PDU של LL ב-LE הוא:
  גודל המטען השימושי של האודיו + 1 (מספר רצף) + 6 (4 לכותרת L2CAP, 2 ל-SDU)
• אירוע חיבור צריך תמיד להיות גדול מספיק כדי להכיל 2 חבילות אודיו ו-2 חבילות ריקות ל-ACK, כדי שאפשר יהיה להקצות רוחב פס להעברות חוזרות. הערה: ייתכן שמנהל ה-Bluetooth של המרכז יפצל את חבילת האודיו. ההתקן ההיקפי צריך להיות מסוגל לקבל יותר מ-2 חבילות אודיו מקוטעות לכל אירוע חיבור.

כדי לתת למרכזית גמישות מסוימת, אורך החבילה של G.722 לא מצוין. אורך החבילה של G.722 יכול להשתנות בהתאם למרווח הזמן של החיבור שהמרכז מגדיר.

פורמט האוקטט של הפלט של G.722 מפנה אל Rec. ITU-T G.722 (09/2012) הקטע 1.4.4 'Multiplexer'

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

קודק	קצב העברת נתונים	מרווח הזמן בין חיבורים	אורך CE (PHY של 1M/2M)	גודל המטען הייעודי של האודיו
G.722‏ @ 16kHz	64 kbit/s	20 אלפיות השנייה	5,000/3,750 us	160 בייטים

התחלה ועצירה של שידור אודיו

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

1. מתבצעת קריאה של PSM, ואם רוצים גם של RenderDelay. הערכים האלה יכולים להישמר במטמון על ידי היחידה המרכזית.
2. ערוץ CoC L2CAP נפתח – הציוד ההיקפי צריך להקצות 8 קרדיטים בהתחלה.
3. מתבצע עדכון חיבור כדי להעביר את הקישור לפרמטרים שנדרשים לקודק שנבחר. העדכון הזה יכול להתבצע במרכז לפני החיבור ל-CoC בשלב הקודם.
4. גם המארח המרכזי וגם המארח ההיקפי ממתינים לאירוע של השלמת העדכון.
5. מפעילים מחדש את מקודד האודיו ומאפסים את ספירת רצף החבילות ל-0. נשלחת הפקודה «Start» עם הפרמטרים הרלוונטיים ב-AudioControlPoint. לפני שמתחילים את הסטרימינג, היחידה המרכזית ממתינה לקבלת התראה על סטטוס מוצלח של הפקודה הקודמת «Start» מהיחידה ההיקפית. ההמתנה הזו נותנת לציוד ההיקפי זמן להכין את צינור עיבוד הנתונים להפעלת האודיו. במהלך סטרימינג של אודיו, העותק צריך להיות זמין בכל אירוע חיבור, גם אם זמן האחזור הנוכחי של העותק שונה מאפס.
6. ההתקן ההיקפי מקבל את חבילת האודיו הראשונה מהתור הפנימי שלו (מספר רצף 0) ומפעיל אותה.

המכשיר המרכזי שולח את הפקודה «Stop» כדי לסגור את שידור האודיו. אחרי הפקודה הזו, ההתקן ההיקפי לא צריך להיות זמין בכל אירוע חיבור. כדי להפעיל מחדש את סטרימינג האודיו, צריך לבצע את הפעולות שמפורטות למעלה, החל משלב 5. כשהמכשיר המרכזי לא משדר אודיו בסטרימינג, הוא עדיין אמור לשמור על חיבור LE לשירותי GATT.

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