במכשירים עם Android מגרסה 12 ואילך, מערכת Android תומכת בפילוח רשת 5G. פילוח רשת הוא שימוש בווירטואליזציה של רשת כדי לחלק חיבורים יחידים לרשת למספר חיבורים וירטואליים נפרדים, שמספקים כמויות שונות של משאבים לסוגים שונים של תעבורת נתונים. טכנולוגיית פריסת רשתות 5G מאפשרת למפעילי רשת להקצות חלק מהרשת כדי לספק תכונות ספציפיות לפלח מסוים של לקוחות. ב-Android 12 נוספו היכולות הבאות של חלוקת רשתות 5G לארגונים, שמפעילי רשתות יכולים לספק ללקוחות הארגוניים שלהם:
חלוקת מכשירים מנוהלים לארגונים
בארגונים שמספקים לעובדים מכשירים ארגוניים בניהול מלא, ספקי רשת יכולים לספק לארגונים האלה פרוסות רשת ארגוניות פעילות אחת או יותר, שהתנועה במכשירים הארגוניים מנותבת אליהן. מגרסה Android 12 ואילך, מערכת Android מאפשרת לספקי סלולר לספק פרוסות ארגוניות באמצעות כללי URSP, במקום להגדיר פרוסות באמצעות APN.
חלוקת אפליקציות עסקיות בארגונים למכשירים עם פרופילים לשימוש בעבודה
ב-Android 12, חברות שמשתמשות בפתרון של פרופיל עבודה יכולות להגדיר ניתוב של תעבורת הנתונים מכל האפליקציות בפרופיל עבודה לפלח רשת ארגוני. ארגונים יכולים להפעיל את היכולת הזו באמצעות בקר מדיניות מכשיר (DPC).
הפתרון של פרופיל העבודה מספק רמה אוטומטית של אימות ובקרת גישה, שנדרשות לארגונים כדי להבטיח שרק תנועה מאפליקציות ארגוניות בפרופיל העבודה תנותב לפלח הרשת הארגוני. אין צורך לשנות את האפליקציות בפרופיל העבודה כדי לבקש במפורש את פרוסת הרשת הארגונית.
איך פועל פיצול של רשת 5G ב-AOSP
ב-Android 12 נוספה תמיכה בפריסת רשת 5G באמצעות תוספות לבסיס הקוד של הטלפוניה ב-AOSP ובמודול הקשירה, כדי לשלב ממשקי 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.javaf/b/services/core/java/com/android/server/TestNetworkService.java
העברת קוד ה-VPN מחוץ למודול Tethering
ב-Android 12, הקוד עם היכולות הבאות מועבר למודול Tethering:
- קבלת בקשות מאפליקציות לחיבורים לרשת
- קבלת בקשות מהמערכת (לדוגמה, "הצבת האפליקציות האלה בפרופיל ארגוני"; נוסף ב-Android 12)
- שליחת בקשות מהמערכת לקוד הטלפוניה שמנסה להגדיר רשתות או פרוסות על ידי מעבר דרך ה-API של HAL והמודם
- הודעה ל-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, ספקי הסלולר יכולים להשתמש בתיאורי טראפיק על סמך הגורמים הבאים:
- מזהה מערכת ההפעלה וסוג מזהה האפליקציה של מערכת ההפעלה, סוג הרכיב
0x08, נתמכים ב-Android 12 ומעלה - סוג יכולות החיבור, סוג הרכיב
0x90, נתמך ב-Android 17 ואילך
מזהה מערכת ההפעלה ומזהה האפליקציה במערכת ההפעלה
כשמגדירים כללי URSP באמצעות הרכיב של מתאר התנועה מסוג OS Id ו-OS App Id, ספקי סלולר יכולים להשתמש בערכים הבאים של OS Id ו-OS App Id שספציפיים ל-Android.
| מזהה | ערך | תיאור |
|---|---|---|
| מזהה מערכת ההפעלה | 97a498e3-fc92-5c94-8986-0333d06e4e47 |
מזהה מערכת ההפעלה ב-Android הוא UUID מגרסה 5 שנוצר באמצעות מרחב השמות ISO OID והשם Android. |
ספקי סלולר שמגדירים כללי URSP באמצעות סוגי OS Id ו-OS App Id צריכים להגדיר כל תנועה של פרוסת רשת עם רכיב תיאור התנועה כשרשור של OS Id, אורך OS App Id (0x0A) ו-OS App Id. לדוגמה, פרוסת העלות ENTERPRISE חייבת להיות 0x97A498E3FC925C9489860333D06E4E470A454E5445525052495345.
מידע נוסף על סוג הרכיב של מתאר התנועה מופיע בטבלה 5.2.1 ב-3GPP TS 24.526.
בטבלה הבאה מתוארים הערכים של 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 |
אין לנו תוכניות להוסיף ערכים חדשים של OSAppId. נשפר את תיאור התנועה של יכולות החיבור לפי הצורך.
יכולות החיבור
החל מ-Android 17 ואילך (Radio HAL AIDL 2.5 ואילך), Android תומך ברכיב של מתאר התנועה של יכולות החיבור (סוג 0x90), שמוגדר בטבלה 5.2.1 של 3GPP TS 24.526.
כששירות מערכת או אפליקציה מבקשים רשת עם יכולת ספציפית, מחסנית הנתונים של הטלפוניה ב-Android ממפה את NetworkCapabilities המבוקש לערך יכולת חיבור רגיל שמאוכלס ב-TrafficDescriptor שנשלח למודם במהלך הגדרת שיחת הנתונים (setupDataCall). בעוד שמפרט 3GPP מאפשר כמה יכולות חיבור בתיאור יחיד, מסגרת הטלפוניה של Android 17 ממפה את יכולות החיבור המרובות המבוקשות ליכולת חיבור יחידה.
בטבלה הבאה מפורט מיפוי ברירת המחדל של יכולות הרשת ב-Android ליכולות החיבור של 3GPP:
| יכולת רשת | יכולת החיבור | ערך (הקסדצימלי או עשרוני) | תיאור |
|---|---|---|---|
NET_CAPABILITY_IMS |
CONNECTION_CAPABILITY_IMS |
0x01 (1) |
תקשורת קולית ווידאו ב-IMS |
NET_CAPABILITY_MMS |
CONNECTION_CAPABILITY_MMS |
0x02 (2) |
תנועת MMS |
NET_CAPABILITY_SUPL |
CONNECTION_CAPABILITY_SUPL |
0x04 (4) |
מיקום מאובטח של מישור המשתמש (SUPL) |
NET_CAPABILITY_INTERNET |
CONNECTION_CAPABILITY_INTERNET |
0x08 (8) |
תנועת נתונים באינטרנט שמוגדרת כברירת מחדל |
NET_CAPABILITY_PRIORITIZE_LATENCY |
CONNECTION_CAPABILITY_REAL_TIME_INTERACTIVE |
0xA6 (166) |
תנועה אינטראקטיבית בזמן אמת (לדוגמה, משחקים, AR/VR) |
NET_CAPABILITY_PRIORITIZE_BANDWIDTH |
CONNECTION_CAPABILITY_DOWNLINK_STREAMING |
0xA3 (163) |
תנועת סטרימינג ברוחב פס גבוה בקישור Downlink |
NET_CAPABILITY_PRIORITIZE_UNIFIED_COMMUNICATIONS |
CONNECTION_CAPABILITY_UNIFIED_COMMUNICATIONS |
0xA7 (167) |
תקשורת מאוחדת (לדוגמה, שיחות קוליות או שיחות וידאו ב-OTT) |
הגדרת URSP של ספק ותאימות לדורות קודמים
כדי להבטיח פעולה חלקה במכשירים עם גרסאות שונות של HAL ו-OS, מומלץ לספקי סלולר לשקול את ההתנהגות הבאה כשמקצים כללי URSP:
- מכשירים עם Android 16 ומטה (Radio HAL AIDL 2.4 ומטה): המודם מקבל לפחות את
OSAppIdבתיאור התנועה. - מכשירים עם Android 17 ואילך (AIDL 2.5 ואילך): כדי להשתמש ביכולות פרימיום של פרוסות (כמו השהיה נמוכה, רוחב פס גבוה ותקשורת מאוחדת), הפלטפורמה מאכלסת את
OSAppId,ConnectionCapabilityאו את שניהם בתיאור התנועה.
מפעילים יכולים להגדיר כללי URSP באחת מהדרכים הבאות:
- כללים שמבוססים על עדיפות (מומלץ):
- כלל א' (עדיפות גבוהה יותר, מספר עדיפות נמוך יותר, לדוגמה, 10): התאמה לפי יכולות החיבור (לדוגמה,
0xA6לזמן אחזור נמוך,0xA3לרוחב פס גבוה או0xA7לתקשורת מאוחדת). מכשירים עם Android מגרסה 17 ואילך תואמים קודם לכלל הזה. - כלל ב' (עדיפות נמוכה יותר, מספר עדיפות גבוה יותר, לדוגמה,
20): התאמה לפי מזהה מערכת ההפעלה וסוג מזהה האפליקציה של מערכת ההפעלה (לדוגמה,
PRIORITIZE_LATENCY). מכשירים ישנים שלא תומכים ביכולת החיבור ב-HAL תואמים לכלל הזה של חזרה למצב קודם.
- כלל א' (עדיפות גבוהה יותר, מספר עדיפות נמוך יותר, לדוגמה, 10): התאמה לפי יכולות החיבור (לדוגמה,
- כלל שמתייחס רק למזהה אפליקציה במערכת ההפעלה (גרסה קודמת):
- מפעילים יכולים להמשיך להשתמש בכללי URSP קיימים שמבוססים על מזהה מערכת ההפעלה ועל סוג מזהה האפליקציה של מערכת ההפעלה. מכיוון שמכשירים עם Android מגרסה 17 ואילך ממשיכים לעבור את
OSAppId, גם מכשירים חדשים וגם מכשירים ישנים תואמים לכללים האלה.
- מפעילים יכולים להמשיך להשתמש בכללי URSP קיימים שמבוססים על מזהה מערכת ההפעלה ועל סוג מזהה האפליקציה של מערכת ההפעלה. מכיוון שמכשירים עם Android מגרסה 17 ואילך ממשיכים לעבור את
- כלל משולב (תנאי AND):
- מפעילים סלולריים יכולים לציין גם את מזהה מערכת ההפעלה וגם את מזהה האפליקציה של מערכת ההפעלה, וגם את יכולות החיבור בתוך מתאר תנועה יחיד. הכלל הזה תואם רק למכשירים עם Android מגרסה 17 ואילך עם AIDL מגרסה 2.5 ומעלה.
דוגמאות לכללי 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:
| כלל 3 של URSP (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:
| כלל 5 במדיניות URSP (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 |
זמן אחזור קצר עם יכולת חיבור
תמיכה ביכולות חיבור בכללי URSP זמינה ב-Android מגרסה 17 ואילך. זו דוגמה לכלל URSP לתנועת נתונים עם זמן אחזור נמוך באמצעות מתאר יכולות החיבור:
| כלל URSP מספר 7 (זמן אחזור נמוך עם יכולת חיבור) | |
|---|---|
| קדימות | 7 (0x07) |
| מאפיין תעבורת נתונים מס' 1 | |
| סוג יכולות החיבור | 0xA6 (166: אינטראקטיבי בזמן אמת) |
| תיאור בחירת המסלול #1 | |
| קדימות | 1 (0x01) |
| רכיב מספר 1: S-NSSAI | SST:XX SD:YYYYYY |
| רכיב מספר 2: DNN | זמן אחזור |
| מאפיין בחירת מסלול מספר 2 | |
| קדימות | 2 (0x02) |
| רכיב מספר 1: DNN | זמן אחזור |
זמן אחזור קצר עם OSAppId
תמיכה בזמן אחזור קצר זמינה ב-Android מגרסה 13 ואילך.
הדוגמה הבאה היא של כלל URSP לתנועה LOW_LATENCY באמצעות OSAppId:
| כלל URSP מספר 8 (זמן אחזור נמוך עם חזרה ל-OSAppId) | |
|---|---|
| קדימות | 8 (0x08) |
| מאפיין תעבורת נתונים מס' 1 | |
| מזהה מערכת ההפעלה + סוג מזהה האפליקציה של מערכת ההפעלה | 0x97A498E3FC925C9489860333D06E4E47125052494f524954495a455f4c4154454e4359 |
| תיאור בחירת המסלול #1 | |
| קדימות | 1 (0x01) |
| רכיב מספר 1: S-NSSAI | SST:XX SD:YYYYYY |
| רכיב מספר 2: DNN | זמן אחזור |
| מאפיין בחירת מסלול מספר 2 | |
| קדימות | 2 (0x02) |
| רכיב מספר 1: DNN | זמן אחזור |
רוחב פס גבוה עם יכולת חיבור
תמיכה ביכולות חיבור בכללי URSP זמינה ב-Android מגרסה 17 ואילך. הדוגמה הבאה היא כלל URSP לטראפיק עם רוחב פס גבוה, שמשתמש בתיאור של יכולות החיבור:
| כלל URSP 9 (רוחב פס גבוה עם יכולת חיבור) | |
|---|---|
| קדימות | 9 (0x09) |
| מאפיין תעבורת נתונים מס' 1 | |
| סוג יכולות החיבור | 0xA3 (163: סטרימינג של קישור Downlink) |
| תיאור בחירת המסלול #1 | |
| קדימות | 1 (0x01) |
| רכיב מספר 1: S-NSSAI | SST:XX SD:YYYYYY |
| רכיב מספר 2: DNN | רוחב פס |
| מאפיין בחירת מסלול מספר 2 | |
| קדימות | 2 (0x02) |
| רכיב מספר 1: DNN | רוחב פס |
רוחב פס גבוה עם OSAppId
תמיכה ברוחב פס גבוה זמינה ב-Android מגרסה 13 ואילך.
הדוגמה הבאה היא של כלל URSP לתנועה HIGH_BANDWIDTH באמצעות OSAppId:
| כלל URSP 10 (רוחב פס גבוה עם חזרה ל-OSAppId) | |
|---|---|
| קדימות | 10 (0x0A) |
| מאפיין תעבורת נתונים מס' 1 | |
| מזהה מערכת ההפעלה + סוג מזהה האפליקציה של מערכת ההפעלה | 0x97A498E3FC925C9489860333D06E4E47145052494f524954495a455f42414e445749445448 |
| תיאור בחירת המסלול #1 | |
| קדימות | 1 (0x01) |
| רכיב מספר 1: S-NSSAI | SST:XX SD:YYYYYY |
| רכיב מספר 2: DNN | רוחב פס |
| מאפיין בחירת מסלול מספר 2 | |
| קדימות | 2 (0x02) |
| רכיב מספר 1: DNN | רוחב פס |
תקשורת אחידה עם יכולת חיבור
תמיכה בתקשורת מאוחדת זמינה ב-Android מגרסה 17 ואילך. הדוגמה הבאה היא של כלל URSP לתנועת נתונים UNIFIED_COMMUNICATIONS באמצעות יכולת חיבור.
תעבורת נתונים של תקשורת מאוחדת מנותבת דרך חיבור ברירת המחדל לאינטרנט, ולכן לא נדרש APN ייעודי (DNN) בתיאור של בחירת הנתיב:
| כלל URSP מספר 11 (תקשורת מאוחדת עם יכולת חיבור) | |
|---|---|
| קדימות | 11 (0x0B) |
| מאפיין תעבורת נתונים מס' 1 | |
| סוג יכולות החיבור | 0xA7 (167: תקשורת אחידה) |
| תיאור בחירת המסלול #1 | |
| קדימות | 1 (0x01) |
| רכיב מספר 1: S-NSSAI | SST:XX SD:YYYYYY |
תקשורת אחידה עם OSAppId
תמיכה בתקשורת מאוחדת זמינה ב-Android מגרסה 17 ואילך. הדוגמה הבאה היא של כלל URSP לטראפיק של UNIFIED_COMMUNICATIONS באמצעות OSAppId:
| כלל URSP מספר 12 (תקשורת מאוחדת עם חזרה ל-OSAppId) | |
|---|---|
| קדימות | 12 (0x0C) |
| מאפיין תעבורת נתונים מס' 1 | |
| מזהה מערכת ההפעלה + סוג מזהה האפליקציה של מערכת ההפעלה | 0x97A498E3FC925C9489860333D06E4E47215052494F524954495A455F554E49464945445F434F4D4D554E49434154494F4N53 |
| תיאור בחירת המסלול #1 | |
| קדימות | 1 (0x01) |
| רכיב מספר 1: S-NSSAI | SST:XX SD:YYYYYY |
ברירת מחדל
| כלל URSP 13 (ברירת מחדל) | |
|---|---|
| קדימות | 13 (0x0D) |
| מאפיין תעבורת נתונים מס' 1 | |
| התאמה להכול | לא רלוונטי |
| תיאור בחירת המסלול #1 | |
| קדימות | 1 (0x01) |
| רכיב מספר 1: S-NSSAI | SST:XX SD:YYYYYY |
בדיקה
כדי לבדוק את חלוקת רשת 5G לפלחים, משתמשים בבדיקה הידנית הבאה.
כדי להגדיר מכשיר לבדיקה:
מוודאים שמדיניות URSP מוגדרת עם כלל לא ברירת מחדל שתואם לקטגוריה של הארגון, ושמתאר בחירת המסלול התואם ממפה את הקטגוריה של הארגון לפלח של הארגון. בנוסף, צריך לוודא שיש כלל ברירת מחדל שמפנה את התעבורה לפלח האינטרנט שמוגדר כברירת מחדל.
מוודאים שמוגדר במכשיר פרופיל עבודה.
הצטרפות לשימוש בפילוח רשת דרך ה-DPC
כדי לבדוק את אופן הפעולה של פילוח רשת 5G:
- מוודאים שסשן PDU נוצר עם פרוסת הרשת הארגונית (לדוגמה, באמצעות כתובת IP ספציפית) ושכל האפליקציות בפרופיל העבודה משתמשות בסשן ה-PDU הזה.
- מוודאים שסשן PDU נפרד נוצר עם פרופיל האינטרנט שמוגדר כברירת מחדל, ושהאפליקציות בפרופיל האישי משתמשות בסשן ה-PDU.
שדרוג ל-5G slicing
התכונה 'מכירת שדרוג של פיצול של רשת 5G' זמינה מ-Android 14 QPR1, ומאפשרת לספקי סלולר להציע למשתמשים שלהם יכולות רשת משופרות (זמן אחזור ורוחב פס) באמצעות פיצול של רשת 5G.
התכונה 'מכירת שדרוג של פיצול של רשת 5G' משתמשת בתגובה TS.43 משרת ההרשאות של הספק כדי להניע את תהליך הרכישה. חברות סלולר יכולות להשתמש בתגובה כדי לציין את כתובת ה-URL של תצוגת ה-webview של חברת הסלולר לרכישה, לשלוח נתונים נוספים לתצוגת ה-webview ולציין אם הפלח הוקצה וזמין ברשת של חברת הסלולר.
ספקי סלולר יכולים להתאים אישית את ההתנהגות של תכונת השדרוג של פיצול של רשת 5G באמצעות הגדרות של ספקי סלולר. ההגדרות האלה קובעות אם אפשר לשלוח בקשות רכישה, מתי אפליקציות יכולות לבקש יכולות פרימיום וכמה זמן מסגרת הטלפוניה מחכה לתשובות מהמשתמש או מהרשת.
תכונת השדרוג של פריסת 5G מספקת ממשק שנקרא DataBoostWebServiceFlow, שמאפשר תקשורת בין Android לבין תצוגת האינטרנט של הספק.
איור 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(בתהליך)
ה-framework של הטלפוניה משתמש בשילוב של סטטוס ההרשאה וסטטוס ההקצאה כדי לקבוע את מצב הרכישה הנוכחי של הפרופיל. התוצאה יכולה להיות אחת מהאפשרויות הבאות:
PURCHASE_PREMIUM_CAPABILITY_RESULT_ALREADY_PURCHASEDPURCHASE_PREMIUM_CAPABILITY_RESULT_ALREADY_IN_PROGRESSPURCHASE_PREMIUM_CAPABILITY_RESULT_ENTITLEMENT_CHECK_FAILEDPURCHASE_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 הוא פרמטר אופציונלי שמציין את משך הזמן המיועד של החבילה.
אם הרכישה לא מצליחה, אתר הספק צריך לשלוח הודעה לאפליקציה לרכישת פרוסות באמצעות method notifyPurchaseFailed(code, reason), כאשר code הוא קוד השגיאה שמציין את הסיבה לכשל ו-reason הוא הסיבה לכשל שניתנת לקריאה על ידי בני אדם אם קוד השגיאה לא ידוע.
אם לא מתבצעת קריאה לאף אחת משיטות התגובה האלה, הרכישה לא תיחשב כמושלמת ובסופו של דבר יחול פסק זמן על בקשת הרכישה.
אלה קודי הכשל התקינים שאפשר לקבל מאתר חברת התובלה במקרה של כשל ברכישה:
FAILURE_CODE_UNKNOWNFAILURE_CODE_CARRIER_URL_UNAVAILABLEFAILURE_CODE_AUTHENTICATION_FAILEDFAILURE_CODE_PAYMENT_FAILEDFAILURE_CODE_NO_USER_DATA
בסיום הרכישה, הספק צריך לעדכן את כללי ה-URSP עם פרופיל הרשת PRIORITIZE_LATENCY במכשיר של המשתמש.
ניתוב אוטומטי של פיצול רשת 5G לשיחות קוליות ושיחות וידאו ב-OTT
Android 17 מספק תמיכה בהעברה אוטומטית של שיחות קוליות ושיחות וידאו דרך האינטרנט (OTT) לחיבורי רשת פרימיום. התכונה הזו מאפשרת למערכת להפנות באופן אוטומטי תנועה משיחות קוליות ומשיחות וידאו לממשק רשת ייעודי (כמו פרוסת 5G פרימיום או חיבור PDN 4G פרימיום) בלי שיהיה צורך לבצע שינויים במערך הרשת של האפליקציה.
הפתרון הזה ברמת הפלטפורמה מייתר את הצורך של מפתחי אפליקציות לבקש במפורש יכולות רשת, ומספק חוויה חלקה למפתחים ולמשתמשי קצה.
איך זה עובד
מערכת Android כוללת תמיכה בניתוב אוטומטי באמצעות תוספות למסגרות של קישוריות וטלקום. התכונה 'ניתוב אוטומטי' פועלת באופן הבא:
- זיהוי שיחות: המערכת ממנפת ממשקי API קיימים של Telecom Jetpack שמשמשים אפליקציות OTT כדי לזהות את ההתחלה והסיום של שיחות קוליות או שיחות וידאו.
- ניהול חיבורים: כשמזוהה שיחה, מערכת Android מציגה ממשק רשת פרימיום ייעודי, כמו פרוסת תקשורת מאוחדת.
- ניתוב תעבורה: במהלך השיחה, הפלטפורמה מזהה את האפליקציה לפי ה-UID שלה ומנתבת את התעבורה שלה באופן אוטומטי לחיבור הרשת הפרימיום.
- פתרון חלופי אחרי השיחה: כשהשיחה מסתיימת, הפלטפורמה מסירה את כלל הניתוב, והתנועה של האפליקציה חוזרת לרשת ברירת המחדל של המערכת לתנועה שאינה שיחות (כמו הודעות).
דרישות
כדי לתמוך בהעברה אוטומטית של שיחות ב-OTT, צריך לעמוד בדרישות הבאות:
- ספקי סלולר: צריכים להציע פרוסת רשת מאוחדת לתקשורת על ידי הגדרת כללי URSP מתאימים (באמצעות יכולת חיבור או OSAppId לתנועת נתונים של תקשורת מאוחדת).
- אפליקציות: חובה להשתמש בממשקי Android Telecom Jetpack API כדי לאפשר למערכת לזהות מצבי שיחה.
- יצרני מכשירים: נדרשת גרסת Android 17 ואילך.