פילוח רשת 5G

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

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

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

פילוח הדוחות שמתייחסים לאפליקציות עסקיות ב-Enterprise

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

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

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

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

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

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

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

הטמעה

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

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

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

דרישות לארגונים

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

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

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

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

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

כללי URSP

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

מזהה ערך תיאור
מזהה OS 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 לקטגוריות השונות של הפלחים.

קטגוריית הפלח מזהה OSApp תיאור
ארגון 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 + סוג מזהה אפליקציה של מערכת ההפעלה 0x97A498E3FC925C9489860333D06E4E470A454E5445525052495345
מתאר בחירת מסלול מס' 1
קדימות 1 (0x01)
רכיב מס' 1: S-NSSAI SST:XX SD:YYYYYY
רכיב מס' 2: DNN Enterprise
מתאר בחירת מסלול מס' 2
קדימות 2 (0x02)
רכיב מס' 1: DNN Enterprise

ארגון 2

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

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

ארגון 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

ארגון 4

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

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

ארגון 5

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

כלל URSP מס' 5 (enterprise5)
קדימות 5 (0x05)
מתאר תנועה מס' 1
מזהה OS + סוג מזהה אפליקציה של מערכת ההפעלה 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 + סוג מזהה אפליקציה של מערכת ההפעלה 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 + סוג מזהה אפליקציה של מערכת ההפעלה 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 מוגדרת עם כלל שאינו ברירת מחדל תואם לקטגוריית הארגון ושבחירת הנתיב המתאימה רכיב descriptor ממפה את קטגוריית הארגון לפלח הארגוני. וגם כלל ברירת מחדל שמפנה את התנועה לפלח האינטרנט שמוגדר כברירת מחדל.

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

  3. הבעת הסכמה לשימוש בחיתוך רשת דרך בקר ה-DPC

כדי לבדוק את ההתנהגות של חיתוך ברשת 5G, מבצעים את הפעולות הבאות:

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

מכירת מוצר או שירות נוסף (upsell) ברשת 5G

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

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

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

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

איור 2 מציג את תהליך הרכישה של חלוקת הנתונים למכירת מוצר או שירות נוסף (upsell) באמצעות 5G:

תהליך הרכישה של מכירת מוצר או שירות נוסף (upsell) באמצעות 5G

איור 2. תהליך הרכישה של מכירת מוצר או שירות נוסף (upsell) באמצעות 5G.

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

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

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

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

סטטוס הזכאות

מקש: EntitlementStatus

סוג: int

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

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

מקש: ProvStatus

סוג: int

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

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

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

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

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

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

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

האם לאפשר רכישה של יכולות פרימיום כשהמכשיר שמקושרת לאבולוציה לטווח ארוך (LTE). אם הערך שלו הוא true, בקשות רכישה יכולות להיות שנוצר גם ב-LTE וגם ברדיו חדש (NR). אם המיקום false, בקשות רכישה אפשר לשלוח רק ב-NR ובקשות שנשלחות ב-LTE נכשלות עם PURCHASE_PREMIUM_CAPABILITY_RESULT_NETWORK_NOT_AVAILABLE תוצאה אחת.

KEY_PREMIUM_CAPABILITY_NOTIFICATION_DISPLAY_TIMEOUT_MILLIS_LONG

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

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

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

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

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

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

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