פילוח רשת 5G

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

חלוקה של מכשירים ארגוניים למחיצות (slicing) במכשירים מנוהלים

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

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

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

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

איך פועל חלוקת הרשתות ב-5G ב-AOSP

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

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

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

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

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

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

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

שירות הרשתות הליבה כולל את השינויים הבאים במודול הקישור (tethering) ב-Android 12:

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

• הרחבת הגבולות של מודול הקישור (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 מהמודול של הקישור

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

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

הטמעה

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

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

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

דרישות ל-Enterprise

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

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

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

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

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

כללי URSP

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

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

ספקי הסלולר צריכים להגדיר כללי URSP לכל תנועה של פרוסת נתונים, עם רכיב מתאר התנועה כ'OS Id + OS App Id type'. לדוגמה, הערך של הפלחים 'ENTERPRISE' צריך להיות 0x97A498E3FC925C9489860333D06E4E470A454E5445525052495345. הערך הזה הוא שרשור של OSId, האורך של OSAppId‏ (0x0A) ו-OSAppId. למידע נוסף על סוג הרכיב של מתאר התנועה, ראו 3GPP TS 24.526 טבלה 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
OS Id + OS App Id type	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
OS Id + OS App Id type	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
OS Id + OS App Id type	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
OS Id + OS App Id type	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
OS Id + OS App Id type	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
OS Id + OS App Id type	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
OS Id + OS App Id type	0x97A498E3FC925C9489860333D06E4E47125052494f524954495a455f4c4154454e4359
תיאור בחירת המסלול מס' 1
קדימות	1 (0x01)
רכיב מס' 1: S-NSSAI	SST:XX SD:YYYYYY
רכיב מס' 2: DNN	זמן אחזור
תיאור בחירת המסלול מס' 2
קדימות	2 (0x02)
רכיב מס' 1: DNN	זמן אחזור

רוחב פס גבוה

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

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

ברירת מחדל

כלל URSP מס' 9 (ברירת המחדל)
קדימות	9 (0x09)
תיאור התנועה מס' 1
match-all	לא רלוונטי
תיאור בחירת המסלול מס' 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 slicing

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

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

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

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

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

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

תהליך ההרשאה של TS.43

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

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

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

סטטוס הזכאות

מקש: EntitlementStatus

סוג: int

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

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

מקש: ProvStatus

סוג: int

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

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

• 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 (לא הוקצה), במסגרת הטלפוניה תוצג למשתמש התראה על שדרוג למינויים מתקדמים, כדי לעודד אותו לרכוש את חבילת ה-Boost דרך תצוגת האינטרנט של הספק. בטבלה הבאה מתוארת ההתנהגות של מסגרת הטלפוניה בשילובים שונים של ערכי הקצאה וסטטוס הרשאה.

		סטטוס הקצאת הרשאות
		לא הוקצה (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 slicing.

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 החלופית לרכישת ספק שתוצג למשתמש כשילחץ על ההתראה על שדרוג. אם כתובת ה-URL של הרכישה לא נמצאת בתשובה של TS.43 מהשרת של הרשאות הגישה, המערכת תשתמש בערך הזה במקום זאת. אם כתובת ה-URL בתגובה של TS.43 או הגדרת הספק לא תקינות, בקשת הרכישה תיכשל עם התוצאה PURCHASE_PREMIUM_CAPABILITY_RESULT_CARRIER_DISABLED.

KEY_PREMIUM_CAPABILITY_SUPPORTED_ON_LTE_BOOL

האם לאפשר רכישה של יכולות פרימיום כשהמכשיר מחובר לרשת Long-Term Evolution‏ (LTE). אם הערך של true הוא 1, אפשר לשלוח בקשות רכישה גם ב-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.