חלוקת רשתות 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 ובמודול Tethering, כדי לשלב ממשקי API קיימים של קישוריות שנדרשים לפריסת רשת.

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

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

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

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

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

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

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

• הוספה של רוב המחלקות של android.net.* public או system API למודול Tethering

• הרחבת הגבולות של מודול ה-Tethering כך שיכלול:

  • 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, הקוד עם היכולות הבאות מועבר למודול של שיתוף האינטרנט:

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

הטמעה

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

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

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

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

קטגוריית הפלח	OSAppId	תיאור
ארגונים	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

דוגמאות לכללי 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 לתנועה עם זמן אחזור נמוך (LOW_LATENCY):

כלל 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 slicing' זמינה מ-Android 14-QPR1, ומאפשרת לספקי סלולר להציע למשתמשים שלהם יכולות רשת משופרות (זמן אחזור ורוחב פס) באמצעות 5G network slicing.

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

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

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

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

איור 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 של הטלפוניה משתמש בשילוב של סטטוס ההרשאה וסטטוס ההקצאה כדי לקבוע את סטטוס הרכישה הנוכחי של הפרוסה. התוצאה יכולה להיות אחת מהאפשרויות הבאות:

• PURCHASE_PREMIUM_CAPABILITY_RESULT_ALREADY_PURCHASED
• PURCHASE_PREMIUM_CAPABILITY_RESULT_ALREADY_IN_PROGRESS
• PURCHASE_PREMIUM_CAPABILITY_RESULT_ENTITLEMENT_CHECK_FAILED
• PURCHASE_PREMIUM_CAPABILITY_RESULT_CARRIER_ERROR

אם סטטוס ההרשאה הוא 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

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

ממשק JavaScript

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

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

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

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

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

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

• FAILURE_CODE_UNKNOWN
• FAILURE_CODE_CARRIER_URL_UNAVAILABLE
• FAILURE_CODE_AUTHENTICATION_FAILED
• FAILURE_CODE_PAYMENT_FAILED
• FAILURE_CODE_NO_USER_DATA

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