פילוח רשת 5G

במכשירים עם Android מגרסה 12 ואילך, מערכת Android מספקת תמיכה בפילוח של רשת 5G, באמצעות שימוש בווירטואליזציה של רשת כדי לחלק חיבורים וירטואליים נפרדים לכמה חיבורים וירטואליים שמספקים כמויות שונות של משאבים לסוגים שונים של תעבורת נתונים. חלוקת הרשת לפלחים ב-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 בארגון

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

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

• הרחבת הגבולות של המודול של שיתוף אינטרנט בין מכשירים (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 והמודם
• מידע נטו לנתב תנועה לפי אפליקציה (הושקה ב-Android 12)
• עדכון האפליקציות לגבי מה שקורה לתעבורת הנתונים שלהן ברשת באמצעות ConnectivityManager ממשקי API כמו NetworkCallback,‏ getActiveNetwork ו-getNetworkCapabilities.

הטמעה

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

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

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

דרישות ל-Enterprise

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

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

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

במכשירים שהוגדרו בהם פרופילים של עבודה, חלוקת הרשתות ל-5G מושבתת כברירת מחדל ב-AOSP. כדי להפעיל חלוקה של הרשת, אדמינים ב-IT בארגון יכולים להפעיל או להשבית את ניתוב התנועה של אפליקציות בפרופיל העבודה לחלק של הרשת של הארגון, לכל עובד בנפרד, באמצעות ה-DPC של EMM, שמשתמש בשיטה 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 לכל תנועה של פרוסת נתונים, כאשר רכיב מתאר התנועה מוגדר כ'סוג מזהה מערכת הפעלה + מזהה אפליקציה של מערכת הפעלה'. לדוגמה, הערך של הפלחים '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, לזמן אחזור קצר, לרוחב פס גבוה ולתעבורת נתונים שמוגדרת כברירת מחדל.

ארגון 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 + סוג מזהה אפליקציה של מערכת ההפעלה	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	ארגון4
תיאור בחירת המסלול מס' 2
קדימות	2 (0x02)
רכיב מס' 1: DNN	ארגון4

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 + סוג מזהה אפליקציה של מערכת ההפעלה	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 מציג את תהליך הרכישה של חלוקת הנתונים למכירת מוצר או שירות נוסף (upsell) באמצעות 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, אפשר לשלוח בקשות רכישה גם ב-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

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

אתר הספק יכול לקבל את יכולת הפרימיום המבוקשת באמצעות method 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.