חלוקת רשתות 5G

במכשירים עם Android מגרסה 12 ואילך, מערכת Android תומכת בפילוח רשת 5G. זהו שימוש בווירטואליזציה של רשת כדי לחלק חיבורים יחידים לרשת למספר חיבורים וירטואליים נפרדים, שמספקים כמויות שונות של משאבים לסוגים שונים של תעבורה. ‫5G network slicing מאפשר למפעילי רשת להקדיש חלק מהרשת כדי לספק תכונות ספציפיות לפלח מסוים של לקוחות. ב-Android 12 נוספו היכולות הבאות של פילוח רשתות 5G ארגוניות, שמפעילי רשתות יכולים לספק ללקוחות הארגוניים שלהם:

חלוקת מכשירים מנוהלים לארגונים

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

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

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

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

איך פועל פיצול של רשת 5G ב-AOSP

ב-Android 12 נוספה תמיכה בפריסת רשת 5G באמצעות תוספות לבסיס הקוד של הטלפוניה ב-AOSP ובמודול הקשירה, כדי לשלב ממשקי API קיימים של קישוריות שנדרשים לפריסת רשת.

פלטפורמת הטלפוניה של Android מספקת ממשקי HAL ו-API לטלפוניה כדי לתמוך בפילוח על סמך בקשות רשת שהוגשו על ידי קוד הרשת המרכזי, וביכולות פילוח של רשת 5G במודם. באיור 1 מתואר הרכיבים של התכונה 'פילוח רשת' ב-5G.

רכיבים של פיצול רשת 5G

איור 1. ארכיטקטורת פיצול של רשת 5G ב-AOSP.

פלטפורמת הטלפוניה והקישוריות תומכת ב:

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

  • תמיכה בפילוח של ארגונים

    • זיהוי הנוכחות של פרופיל עבודה במכשיר
    • בודקים הרשאות או הוראות ניתוב שסופקו מ-DPC שבו משתמש האדמין של ה-IT בארגון

שירות הרשתות הראשי כולל את השינויים הבאים במודול Tethering ב-Android 12:

  • המודול Tethering מוסיף את רוב המחלקות של android.net.* ממשקי API ציבוריים או מערכתיים

  • הרחבת הגבולות של מודול השיתוף באינטרנט כך שיכלול:

    • f/b/core/java/android/net/…
    • f/b/services/net/…
    • f/b/services/core/java/com/android/server/connectivity/…
    • f/b/services/core/java/com/android/server/ConnectivityService.java
    • f/b/services/core/java/com/android/server/TestNetworkService.java

  • העברת קוד ה-VPN מחוץ למודול Tethering

ב-Android 12, הקוד עם היכולות הבאות מועבר למודול Tethering:

  • קבלת בקשות מאפליקציות לחיבורים לרשת
  • קבלת בקשות מהמערכת (לדוגמה, 'העברת האפליקציות האלה למחיצה של הארגון'; נוסף ב-Android 12)
  • שליחת בקשות מהמערכת לקוד הטלפוניה שמנסה להגדיר רשתות או פרוסות באמצעות HAL API והמודם
  • הודעה ל-netd איך לנתב תעבורה על בסיס כל אפליקציה (הוצג ב-Android 12)
  • הודעה לאפליקציות על מה שקורה לתעבורת הרשת שלהן באמצעות ממשקי API של ConnectivityManager כמו NetworkCallback, getActiveNetwork, getNetworkCapabilities.

הטמעה

כדי לתמוך בפיצול של רשת 5G במכשיר, המכשיר צריך לכלול מודם שתומך ב-IRadio 1.6 HAL, שכולל את setupDataCall_1_6 API. ממשק ה-API הזה מגדיר חיבור נתונים וכולל את הפרמטרים הבאים לתמיכה בפילוח של רשת 5G:

  • ‫trafficDescriptor: מציין את תיאור התנועה שנשלח למודם
  • ‫sliceInfo: מציין מידע על פרוסת הרשת שתשמש במקרה של העברה מ-EPDG ל-5G
  • ‫matchAllRuleAllowed: מציין אם מותר להשתמש בכלל URSP שמוגדר כברירת מחדל. בטלפוניה, ההגדרה הזו היא true ברשתות ברירת מחדל, אבל לא בפרוסות. הכלל 'התאמה לכל הרשתות' חל על רשתות ברירת מחדל. אם אפליקציה מבקשת פרוסה ספציפית שלא זמינה, הפרוסה הספציפית מדווחת כלא זמינה. באפליקציות ארגוניות, אם הרשת הארגונית לא זמינה, אפשר להשתמש ב-Telephony framework כדי לחזור לרשת שמוגדרת כברירת מחדל.

מודמים חייבים להטמיע גם את ה-API‏ getSlicingConfig, אלא אם ה-API‏ getHalDeviceCapabilities מדווח שהוא לא נתמך.

דרישות ל-Enterprise

בהמשך מפורטות הדרישות לשימוש בפריסת רשת 5G במכשירים בפריסת Android Enterprise.

  • חשוב לוודא שבמכשירים מנוהלים או במכשירים של עובדים שהוגדר בהם פרופיל עבודה יש תמיכה ב-5G SA עם מודמים שתומכים ב-API‏ setupDataCall_1_6.
  • עבודה עם שותף חברת תובלה על הגדרת פלח וביצועים או מאפיינים של הסכם רמת שירות (SLA).

הפעלת פיצול של רשת 5G במכשירים שהוגדר בהם פרופיל עבודה

במכשירים שהוגדרו בהם פרופילים של עבודה, חלוקת רשת 5G לפלחים מושבתת כברירת מחדל ב-AOSP. כדי להפעיל את חלוקת הרשת, אדמינים ב-IT בארגון יכולים להפעיל או להשבית את ניתוב התנועה של אפליקציות בפרופיל העבודה לחלק ברשת הארגונית, על בסיס כל עובד, באמצעות אפליקציית DPC של EMM. האפליקציה משתמשת בשיטה setPreferentialNetworkServiceEnabled ב-API של DevicePolicyManager (DPM) (שהושק ב-Android 12).

ספקי EMM עם DPC מותאם אישית צריכים לשלב את DevicePolicyManager API כדי לתמוך בלקוחות ארגוניים.

כללי URSP

בקטע הזה יש מידע למפעילים על הגדרת כללי URSP עבור קטגוריות שונות של פרוסות, כולל תנועה של עסקים, CBS, השהיה נמוכה ורוחב פס גבוה. כשמגדירים כללי URSP לקטגוריות שונות של פלחים, ספקי הסלולר צריכים להשתמש בערכים הספציפיים ל-Android שמופיעים בהמשך.

מזהה ערך תיאור
OSId 97a498e3-fc92-5c94-8986-0333d06e4e47 מזהה מערכת ההפעלה (OSId) של Android הוא UUID בגרסה 5 שנוצר באמצעות מרחב השמות ISO OID והשם Android.

מפעילים סלולריים צריכים להגדיר כללי URSP לכל פרוסת תנועה עם רכיב תיאור התנועה בתור 'מזהה מערכת הפעלה + סוג מזהה אפליקציה במערכת ההפעלה'. לדוגמה, הערך של הפלח 'ENTERPRISE' צריך להיות 0x97A498E3FC925C9489860333D06E4E470A454E5445525052495345. הערך הזה הוא שרשור של OSId, האורך של OSAppId ‏ (0x0A) ו-OSAppId. מידע נוסף על סוג הרכיב של מתאר התנועה זמין במאמר 3GPP TS 24.526 Table 5.2.1.

בטבלה הבאה מתוארים הערכים של OSAppId לקטגוריות שונות של פלחים.

קטגוריית הפלח OSAppId תיאור
ENTERPRISE 0x454E5445525052495345 ‫OSAppId הוא ייצוג של מערך בייטים של המחרוזת ENTERPRISE
ENTERPRISE2 0x454E544552505249534532 ‫OSAppId הוא ייצוג של מערך בייטים של המחרוזת ENTERPRISE2
ENTERPRISE3 0x454E544552505249534533 ‫OSAppId הוא ייצוג של מערך בייטים של המחרוזת ENTERPRISE3
ENTERPRISE4 0x454E544552505249534534 ‫OSAppId הוא ייצוג של מערך בייטים של המחרוזת ENTERPRISE4
ENTERPRISE5 0x454E544552505249534535 ‫OSAppId הוא ייצוג של מערך בייטים של המחרוזת ENTERPRISE5
CBS 0x434253 ‫OSAppId הוא ייצוג של מערך בייטים של המחרוזת CBS
PRIORITIZE_LATENCY 0x5052494f524954495a455f4c4154454e4359 ‫OSAppId הוא ייצוג של מערך בייטים של המחרוזת PRIORITIZE_LATENCY
PRIORITIZE_BANDWIDTH 0x5052494f524954495a455f42414e445749445448 ‫OSAppId הוא ייצוג של מערך בייטים של המחרוזת PRIORITIZE_BANDWIDTH
PRIORITIZE_UNIFIED_COMMUNICATIONS 0x5052494f524954495a455f554e49464945445f434f4d4d554e49434154494f4e53 ‫OSAppId הוא ייצוג של מערך בייטים של המחרוזת PRIORITIZE_UNIFIED_COMMUNICATIONS

דוגמאות לכללי URSP

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

Enterprise 1

תמיכה ב-Enterprise 1 זמינה ב-Android מגרסה 12 ואילך. זו דוגמה לכלל URSP לתנועה של ENTERPRISE1:

כלל URSP מס' 1 (enterprise1)
קדימות ‫1 (0x01)
תיאור תעבורת נתונים מס' 1
מזהה מערכת ההפעלה + סוג מזהה האפליקציה של מערכת ההפעלה 0x97A498E3FC925C9489860333D06E4E470A454E5445525052495345
תיאור בחירת המסלול #1
קדימות ‫1 (0x01)
רכיב מספר 1: S-NSSAI SST:XX SD:YYYYYY
רכיב מספר 2: DNN ארגון
תיאור בחירת מסלול מספר 2
קדימות ‫2 (0x02)
רכיב מספר 1: DNN ארגון

‫Enterprise 2

תמיכה ב-Enterprise 2 זמינה ב-Android מגרסה 13 ואילך. זו דוגמה לכלל URSP לתנועה של ENTERPRISE2:

כלל URSP מס' 2 (enterprise2)
קדימות ‫2 (0x02)
תיאור תעבורת נתונים מס' 1
מזהה מערכת ההפעלה + סוג מזהה האפליקציה של מערכת ההפעלה 0x97A498E3FC925C9489860333D06E4E470B454E544552505249534532
תיאור בחירת המסלול #1
קדימות ‫1 (0x01)
רכיב מספר 1: S-NSSAI SST:XX SD:YYYYYY
רכיב מספר 2: DNN enterprise2
תיאור בחירת המסלול מספר 2
קדימות ‫2 (0x02)
רכיב מספר 1: DNN enterprise2

Enterprise 3

תמיכה ב-Enterprise 3 זמינה ב-Android מגרסה 13 ואילך. זו דוגמה לכלל URSP לתנועה של ENTERPRISE3:

כלל URSP מספר 3 (enterprise3)
קדימות ‫3 (0x03)
תיאור תעבורת נתונים מס' 1
מזהה מערכת ההפעלה + סוג מזהה האפליקציה של מערכת ההפעלה 0x97A498E3FC925C9489860333D06E4E470B454E544552505249534533
תיאור בחירת המסלול #1
קדימות ‫1 (0x01)
רכיב מספר 1: S-NSSAI SST:XX SD:YYYYYY
רכיב מספר 2: DNN enterprise3
תיאור בחירת המסלול מספר 2
קדימות ‫2 (0x02)
רכיב מספר 1: DNN enterprise3

‫Enterprise 4

תמיכה ב-Enterprise 4 זמינה ב-Android מגרסה 13 ואילך. דוגמה לכלל URSP לתנועה של ENTERPRISE4:

כלל URSP מס' 4 (enterprise4)
קדימות ‫4 (0x04)
תיאור תעבורת נתונים מס' 1
מזהה מערכת ההפעלה + סוג מזהה האפליקציה של מערכת ההפעלה 0x97A498E3FC925C9489860333D06E4E470B454E544552505249534534
תיאור בחירת המסלול #1
קדימות ‫1 (0x01)
רכיב מספר 1: S-NSSAI SST:XX SD:YYYYYY
רכיב מספר 2: DNN enterprise4
תיאור בחירת המסלול מספר 2
קדימות ‫2 (0x02)
רכיב מספר 1: DNN enterprise4

Enterprise 5

תמיכה ב-Enterprise 5 זמינה ב-Android מגרסה 13 ואילך. זו דוגמה לכלל URSP לתנועה של ENTERPRISE5:

כלל URSP מספר 5 (enterprise5)
קדימות ‫5 (0x05)
תיאור תעבורת נתונים מס' 1
מזהה מערכת ההפעלה + סוג מזהה האפליקציה של מערכת ההפעלה 0x97A498E3FC925C9489860333D06E4E470B454E544552505249534535
תיאור בחירת המסלול #1
קדימות ‫1 (0x01)
רכיב מספר 1: S-NSSAI SST:XX SD:YYYYYY
רכיב מספר 2: DNN enterprise5
תיאור בחירת המסלול מספר 2
קדימות ‫2 (0x02)
רכיב מספר 1: DNN enterprise5

CBS

תמיכה ב-CBS זמינה ב-Android מגרסה 13 ואילך. דוגמה לכלל URSP לתנועה של CBS:

כלל URSP מס' 6 (CBS)
קדימות ‫6 (0x06)
תיאור תעבורת נתונים מס' 1
מזהה מערכת ההפעלה + סוג מזהה האפליקציה של מערכת ההפעלה 0x97A498E3FC925C9489860333D06E4E4703434253
תיאור בחירת המסלול #1
קדימות ‫1 (0x01)
רכיב מספר 1: S-NSSAI SST:XX SD:YYYYYY
רכיב מספר 2: DNN cbs
תיאור בחירת המסלול מספר 2
קדימות ‫2 (0x02)
רכיב מספר 1: DNN cbs

זמן אחזור נמוך

התמיכה בזמן אחזור קצר זמינה ב-Android מגרסה 13 ואילך. דוגמה לכלל URSP לתנועה עם זמן אחזור נמוך:

כלל URSP מספר 7 (זמן אחזור נמוך)
קדימות ‫7 (0x07)
תיאור תעבורת נתונים מס' 1
מזהה מערכת ההפעלה + סוג מזהה האפליקציה של מערכת ההפעלה 0x97A498E3FC925C9489860333D06E4E47125052494f524954495a455f4c4154454e4359
תיאור בחירת המסלול #1
קדימות ‫1 (0x01)
רכיב מספר 1: S-NSSAI SST:XX SD:YYYYYY
רכיב מספר 2: DNN זמן אחזור
תיאור בחירת המסלול מספר 2
קדימות ‫2 (0x02)
רכיב מספר 1: DNN זמן אחזור

רוחב פס גבוה

התמיכה ברוחב פס גבוה זמינה ב-Android מגרסה 13 ואילך. דוגמה לכלל URSP לתנועה עם רוחב פס גבוה:

כלל URSP מספר 8 (רוחב פס גבוה)
קדימות ‫8 (0x08)
תיאור תעבורת נתונים מס' 1
מזהה מערכת ההפעלה + סוג מזהה האפליקציה של מערכת ההפעלה 97A498E3FC925C9489860333D06E4E47145052494f524954495a455f42414e445749445448
תיאור בחירת המסלול #1
קדימות ‫1 (0x01)
רכיב מספר 1: S-NSSAI SST:XX SD:YYYYYY
רכיב מספר 2: DNN רוחב פס
תיאור בחירת המסלול מספר 2
קדימות ‫2 (0x02)
רכיב מספר 1: DNN רוחב פס

ברירת מחדל

כלל URSP מספר 9 (ברירת מחדל)
קדימות ‫9 (0x09)
תיאור תעבורת נתונים מס' 1
התאמה להכול לא רלוונטי
תיאור בחירת המסלול #1
קדימות ‫1 (0x01)
רכיב מספר 1: S-NSSAI SST:XX SD:YYYYYY

בדיקה

כדי לבדוק את חלוקת רשת 5G לפלחים, משתמשים בבדיקה הידנית הבאה.

כדי להגדיר מכשיר לבדיקה:

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

  2. מוודאים שמוגדר במכשיר פרופיל עבודה.

  3. הצטרפות לשימוש בפילוח רשת דרך ה-DPC

כדי לבדוק את אופן הפעולה של פילוח רשת 5G:

  1. מוודאים שסשן PDU נוצר עם פרוסת הרשת הארגונית (לדוגמה, באמצעות כתובת IP ספציפית) ושכל האפליקציות בפרופיל העבודה משתמשות בסשן ה-PDU הזה.
  2. מוודאים שסשן PDU נפרד נוצר עם פרופיל האינטרנט שמוגדר כברירת מחדל, ושהאפליקציות בפרופיל האישי משתמשות בסשן ה-PDU.

שדרוג למכירת פיצול של רשת 5G

התכונה 'מכירת שדרוג של פיצול של רשת 5G' זמינה מ-Android 14 QPR1, ומאפשרת לספקי סלולר להציע למשתמשים שלהם יכולות רשת משופרות (זמן אחזור ורוחב פס) באמצעות פיצול של רשת 5G.

התכונה 'מכירת שדרוג של פיצול של רשת 5G' משתמשת בתגובה TS.43 משרת ההרשאות של הספק כדי להניע את תהליך הרכישה. חברות סלולר יכולות להשתמש בתגובה כדי לציין את כתובת ה-URL של תצוגת האינטרנט של הרכישה של חברת הסלולר, לשלוח נתונים נוספים לתצוגת האינטרנט ולציין אם החבילה הוקצתה וזמינה ברשת של חברת הסלולר.

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

התכונה 'מכירת שדרוג של פיצול של רשת 5G' מספקת ממשק שנקרא DataBoostWebServiceFlow, שמאפשר תקשורת בין Android לבין WebView של הספק.

איור 2 מציג את תהליך הרכישה של שדרוג לפיצול של רשת 5G:

תהליך רכישה להגדלת המכירה של פיצול רשת 5G

איור 2. תהליך רכישה של שדרוג ל-5G slicing.

TS.43 entitlement process

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

שדות של רכישת פלח

הגדרת ההרשאות TS.43 כוללת את השדות הבאים של רכישת פרוסות:

סטטוס הזכאות

מקש: EntitlementStatus

סוג: int

ערכים נתמכים: 0 (מושבת), 1 (מופעל), 2 (לא תואם), 3 (הקצאת הרשאות), 4 (כלול)

סטטוס של ניהול תצורה

מקש: ProvStatus

סוג: int

ערכים נתמכים: 0 (לא הוקצה), 1 (הוקצה), 2 (לא זמין), 3 (בתהליך)

ה-framework של הטלפוניה משתמש בשילוב של סטטוס ההרשאה וסטטוס ההקצאה כדי לקבוע את מצב הרכישה הנוכחי של הפרופיל. התוצאה יכולה להיות אחת מהאפשרויות הבאות:

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

סטטוס הקצאת ההרשאות
לא הוקצה (0) הוקצה (1) לא זמין (2) בתהליך (3)
סטטוס ההרשאה מושבת (0) נכשל נכשל נכשל נכשל
מופעל (1) הצגת WebView המוצר כבר נרכש המוצר כבר נרכש בתהליך
לא תואם (2) נכשל נכשל נכשל נכשל
הקצאת הרשאות (3) שגיאה של חברת התובלה שגיאה של חברת התובלה בתהליך בתהליך
כלול (4) שגיאה של חברת התובלה המוצר כבר נרכש המוצר כבר נרכש שגיאה של חברת התובלה

שדות של זרימת שירות

בתגובה TS.43 מצוינים כתובת ה-URL, נתוני המשתמשים וסוג התוכן כדי להתאים אישית את ההתנהגות של תצוגת האינטרנט של הרכישה אצל הספק. אם לא מציינים את סוג התוכן, כתובת ה-URL נטענת כבקשת GET. אם נתוני המשתמש קיימים, הם מצורפים לכתובת ה-URL כפרמטר של שאילתה (לדוגמה, https://www.android.com?encodedValue=Base64EncodedUserData). אם הם לא קיימים, כתובת ה-URL משמשת כמו שהיא (לדוגמה, https://www.android.com).
אם סוג התוכן מצוין בפורמט JSON או XML, כתובת ה-URL נטענת כבקשת POST, ונתוני המשתמש (מפוענחים אם הם מקודדים ב-Base 64) נשלחים כנתונים של בקשת ה-POST.

כתובת URL

מקש: ServiceFlow_URL

סוג: String

דוגמה: "https://www.android.com"

נתוני המשתמש

מקש: ServiceFlow_UserData

סוג: String

דוגמה: "encodedValue=Base64EncodedUserData"

סוג התוכן

מקש: ServiceFlow_ContentsType

סוג: String

ערכים נתמכים: 0 (לא צוין), 1 (JSON), ‏ 2 (XML)

הגדרות של חברות תובלה

אלה הגדרות הספק שזמינות להתאמה אישית של ההתנהגות של תכונת השדרוג של פיצול של רשת 5G.

KEY_SUPPORTED_PREMIUM_CAPABILITIES_INT_ARRAY

רשימה של יכולות פרימיום נתמכות. זו מערך int של TelephonyManager.PremiumCapability. היכולות המתקדמות האלה חולקות את אותו ערך כמו המחלקה התואמת NetworkCapabilities.NetCapability. אם נשלחת בקשה ליכולת פרימיום שלא נכללת בהגדרה הזו, בקשת הרכישה תיכשל ותחזיר את התוצאה CARRIER_DISABLED.

ב-Android 14, יש תמיכה רק ב-PREMIUM_CAPABILITY_PRIORITIZE_LATENCY.

KEY_PREMIUM_CAPABILITY_MAXIMUM_DAILY_NOTIFICATION_COUNT_INT

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

KEY_PREMIUM_CAPABILITY_MAXIMUM_MONTHLY_NOTIFICATION_COUNT_INT

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

KEY_PREMIUM_CAPABILITY_PURCHASE_URL_STRING

כתובת ה-URL של הרכישה של הספק החלופי שתוצג למשתמש כשהוא ילחץ על הודעת השדרוג. אם כתובת האתר של הרכישה לא נמצאת בתגובה TS.43 משרת ההרשאות, המערכת משתמשת בערך הזה במקום זאת. אם אף אחד מה-URL מהתגובה TS.43 או מהגדרות הספק לא תקף, בקשת הרכישה תיכשל עם התוצאה PURCHASE_PREMIUM_CAPABILITY_RESULT_CARRIER_DISABLED.

KEY_PREMIUM_CAPABILITY_SUPPORTED_ON_LTE_BOOL

האם לאפשר רכישה של יכולות פרימיום כשהמכשיר מחובר ל-Long-Term Evolution ‏ (LTE). אם true, אפשר לשלוח בקשות לרכישה גם ב-LTE וגם ב-New Radio (NR). אם false, אפשר לשלוח בקשות רכישה רק ב-NR, ובקשות שנשלחות ב-LTE נכשלות עם התוצאה PURCHASE_PREMIUM_CAPABILITY_RESULT_NETWORK_NOT_AVAILABLE.

KEY_PREMIUM_CAPABILITY_NOTIFICATION_DISPLAY_TIMEOUT_MILLIS_LONG

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

KEY_PREMIUM_CAPABILITY_NOTIFICATION_BACKOFF_HYSTERESIS_TIME_MILLIS_LONG

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

KEY_PREMIUM_CAPABILITY_PURCHASE_CONDITION_BACKOFF_HYSTERESIS_TIME_MILLIS_LONG

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

KEY_PREMIUM_CAPABILITY_NETWORK_SETUP_TIME_MILLIS_LONG

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

ממשק JavaScript

כשמשתמש לוחץ על ההתראה על שיפור הביצועים ברשת, מוצג לו אובייקט WebView עם כתובת ה-URL לרכישה מהספק. ספקי סלולר יכולים להשתמש בממשקי ה-API שמופיעים בממשק JavaScript‏ DataBoostWebServiceFlow באתר הרכישה שלהם כדי לתקשר עם אפליקציית הרכישה של הפרופיל.

אתר הספק יכול לקבל את היכולת המבוקשת בתשלום באמצעות השיטה getRequestedCapability().

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

אם הרכישה לא מצליחה, אתר הספק צריך להודיע לאפליקציה לרכישת חבילות באמצעות השיטה notifyPurchaseFailed(code, reason), כאשר code הוא קוד הכשל שמציין את הסיבה לכשל ו-reason היא הסיבה לכשל שניתנת לקריאה על ידי בני אדם אם קוד הכשל לא ידוע.

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

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

בסיום הרכישה, הספק צריך לעדכן את כללי ה-URSP עם פרופיל הרשת PRIORITIZE_LATENCY במכשיר של המשתמש.

ניתוב אוטומטי של פיצול רשת 5G לשיחות קוליות ולווידאו ב-OTT

‫Android 17 מספק תמיכה בניתוב אוטומטי של שיחות קוליות ושיחות וידאו ב-OTT (מעל גבי האינטרנט) לחיבורי רשת פרימיום. התכונה הזו מאפשרת למערכת להפנות באופן אוטומטי תנועה משיחות קוליות ומשיחות וידאו לממשק רשת ייעודי (כמו פרוסת 5G פרימיום או חיבור PDN 4G פרימיום) בלי שיהיה צורך לבצע שינויים במערך הרשת של האפליקציה.

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

איך זה עובד

מערכת Android כוללת תמיכה בניתוב אוטומטי באמצעות תוספות למסגרות של קישוריות וטלקום. התכונה 'ניתוב אוטומטי' פועלת באופן הבא:

  • זיהוי שיחות: המערכת ממנפת ממשקי API קיימים של Telecom Jetpack שמשמשים אפליקציות OTT כדי לזהות את ההתחלה והסיום של שיחות קוליות או שיחות וידאו.
  • ניהול חיבורים: כשמזוהה שיחה, מערכת Android מציגה ממשק רשת פרימיום ייעודי, כמו פרוסת תקשורת מאוחדת.
  • ניתוב תעבורה: במהלך השיחה, הפלטפורמה מזהה את האפליקציה לפי ה-UID שלה ומנתבת את התעבורה שלה באופן אוטומטי לחיבור הרשת הפרימיום.
  • מעבר חזרה אחרי השיחה: כשהשיחה מסתיימת, הפלטפורמה מסירה את כלל הניתוב, והתנועה של האפליקציה חוזרת לרשת ברירת המחדל של המערכת לתנועה שאינה שיחות (כמו הודעות).

דרישות

כדי לתמוך בהעברה אוטומטית של שיחות ב-OTT, צריך לעמוד בדרישות הבאות:

  • ספקים סלולריים: צריכים להציע פרוסת רשת מאוחדת לתקשורת על ידי הגדרת כללי URSP מתאימים. ספקי הסלולר צריכים לאכלס את ה-URSP בOSAppID ספציפי לתנועת נתונים של תקשורת מאוחדת.
  • אפליקציות: צריך להשתמש בממשקי Android Telecom Jetpack API כדי לאפשר למערכת לזהות את מצבי השיחה.
  • יצרני מכשירים: נדרשת מערכת Android מגרסה 17 ואילך.