For devices running Android 12 or higher, Android provides support for 5G network slicing, the use of network virtualization to divide single network connections into multiple distinct virtual connections that provide different amounts of resources to different types of traffic. 5G network slicing allows network operators to dedicate a portion of the network to providing specific features for a particular segment of customers. Android 12 introduces the following 5G enterprise network slicing capabilities, which network operators can provide to their enterprise clients:
Enterprise device slicing for fully managed devices
For enterprises who provide fully managed company devices to their employees, network providers can provide them with one or more active enterprise network slices where traffic on the company devices are routed to. From Android 12, Android allows carriers to provide enterprise slices through URSP rules, instead of setting up slices through APNs.
Enterprise business app slicing for devices with work profiles
For enterprises using the work profile solution, Android 12 allows devices to route the traffic from all apps in the work profile to an enterprise network slice. Enterprises can enable this capability through a Device Policy Controller (DPC).
The work profile solution provides an automatic level of authentication and access control that enterprises require to ensure that only traffic from enterprise apps in the work profile are routed to the enterprise network slice. Apps in the work profile don't need to be modified to explicitly request the enterprise network slice.
How 5G network slicing works in AOSP
Android 12 introduces support for 5G network slicing through additions to the telephony codebase in AOSP and the Tethering module to incorporate existing connectivity APIs that are required for network slicing.
The Android telephony platform provides HAL and telephony APIs to support slicing based on network requests filed by the core networking code and 5G slicing capabilities in the modem. Figure 1 describes the components of the 5G network slicing feature.
Figure 1. 5G network slicing architecture in AOSP.
The telephony and connectivity platform supports:
- Converting network requests for slice categories into traffic descriptors which are then passed to the modem for URSP traffic matching and route selection
- Falling back to the default network if the enterprise network slice isn't available
- Routing traffic from all apps under the work profile to the corresponding connection
Supporting enterprise slicing
- Detecting the presence of a work profile on the device
- Checking for permissions or routing directions provided from the DPC used by the enterprise's IT admin
The core networking service includes the following changes to the Tethering module in Android 12:
- Adds most of
android.net.*public or system API classes to the Tethering module Expands the Tethering module boundaries to include:
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
Moves VPN code out of the Tethering module
Android 12 moves code with the following capabilities to the Tethering module:
- Receiving requests from apps for network connections
- Receiving requests from the system (for example, "place these apps on an enterprise slice"; introduced in Android 12)
- Sending requests from the system to the telephony code which attempts to set up networks or slices by going through the HAL API and the modem
- Informing netd how to route traffic on a per-app basis (introduced in Android 12)
- Informing apps what is happening to their network traffic through
ConnectivityManagerAPIs such asNetworkCallback,getActiveNetwork,getNetworkCapabilities.
Implementation
To support 5G slicing on a device, the device must have a modem that supports
the IRadio 1.6 HAL which has the
setupDataCall_1_6
API. This API sets up a data connection and includes the following parameters
for supporting 5G slicing:
trafficDescriptor: Specifies traffic descriptor sent to the modemsliceInfo: Specifies information for the network slice to be used in case of EPDG to 5G handovermatchAllRuleAllowed: Specifies whether using a default match-all URSP rule is allowed. Telephony sets this to true for default networks but not for slices. The match all rule is applied to default networks. When an app requests a specific slice that is not available, the specific slice is reported as not available. For enterprise apps, the Telephony framework can fall back to the default network if the enterprise network isn't available.
Modems must also implement the
getSlicingConfig
API unless it's reported as unsupported by the
getHalDeviceCapabilities
API.
Enterprise requirements
The following describes requirements for enterprises to use 5G network slicing on devices in an Android enterprise deployment.
- Ensure that fully managed or employee devices set up with a work profile
are 5G SA-capable with modems that support the
setupDataCall_1_6API. - Work with carrier partner on slice setup and performance or SLA characteristics.
Enable 5G slicing on devices set up with a work profile
For devices that are set up with work profiles, 5G network slicing is off by
default in AOSP. To enable network slicing, enterprise IT admins can turn on or
off work profile app traffic routing to the enterprise network slice on a
per-employee basis through the EMM DPC, which uses the
setPreferentialNetworkServiceEnabled
method in the
DevicePolicyManager (DPM)
API (introduced in Android 12).
EMM vendors with custom DPCs must integrate the DevicePolicyManager API to
support enterprise clients.
URSP rules
This section includes information for carriers on configuring URSP rules for different slice categories including enterprise, CBS, low latency, and high bandwidth traffic. When configuring URSP rules for different slice categories, carriers must use the following Android-specific values.
| ID | Value | Description |
|---|---|---|
| OSId | 97a498e3-fc92-5c94-8986-0333d06e4e47 |
The OSId for Android is a version 5 UUID generated with the namespace ISO OID and the name "Android". |
Carriers must configure URSP rules for each slice traffic with the traffic
descriptor component as "OS Id + OS App Id type". For example, the "ENTERPRISE"
slice must have a value of
0x97A498E3FC925C9489860333D06E4E470A454E5445525052495345.
This value is a concatenation of the OSId, the length of the OSAppId (0x0A),
and the OSAppId.
For more information about the traffic descriptor component type, see
3GPP TS 24.526 Table 5.2.1.
The following table describes the OSAppId values for different slice categories.
| Slice category | OSAppId | Description |
|---|---|---|
| ENTERPRISE | 0x454E5445525052495345 |
The OSAppId is a byte array representation of the string "ENTERPRISE" |
| ENTERPRISE2 | 0x454E544552505249534532 |
The OSAppId is a byte array representation of the string "ENTERPRISE2" |
| ENTERPRISE3 | 0x454E544552505249534533 |
The OSAppId is a byte array representation of the string "ENTERPRISE3" |
| ENTERPRISE4 | 0x454E544552505249534534 |
The OSAppId is a byte array representation of the string "ENTERPRISE4" |
| ENTERPRISE5 | 0x454E544552505249534535 |
The OSAppId is a byte array representation of the string "ENTERPRISE5" |
| CBS | 0x434253 |
The OSAppId is a byte array representation of the string "CBS" |
| PRIORITIZE_LATENCY | 0x5052494f524954495a455f4c4154454e4359 |
The OSAppId is a byte array representation of the string "PRIORITIZE_LATENCY" |
| PRIORITIZE_BANDWIDTH | 0x5052494f524954495a455f42414e445749445448 |
The OSAppId is a byte array representation of the string "PRIORITIZE_BANDWIDTH" |
Example URSP rules
The following tables show example URSP rules for enterprise, CBS, low latency, high bandwidth, and default traffic.
Enterprise 1
Support for Enterprise 1 is available in Android 12 and higher. The following is an example URSP rule for ENTERPRISE1 traffic:
| URSP rule #1 (enterprise1) | |
|---|---|
| Precedence | 1 (0x01) |
| Traffic descriptor #1 | |
| OS Id + OS App Id type | 0x97A498E3FC925C9489860333D06E4E470A454E5445525052495345 |
| Route selection descriptor #1 | |
| Precedence | 1 (0x01) |
| Component #1: S-NSSAI | SST:XX SD:YYYYYY |
| Component #2: DNN | enterprise |
| Route selection descriptor #2 | |
| Precedence | 2 (0x02) |
| Component #1: DNN | enterprise |
Enterprise 2
Support for Enterprise 2 is available in Android 13 and higher. The following is an example URSP rule for ENTERPRISE2 traffic:
| URSP rule #2 (enterprise2) | |
|---|---|
| Precedence | 2 (0x02) |
| Traffic descriptor #1 | |
| OS Id + OS App Id type | 0x97A498E3FC925C9489860333D06E4E470B454E544552505249534532 |
| Route selection descriptor #1 | |
| Precedence | 1 (0x01) |
| Component #1: S-NSSAI | SST:XX SD:YYYYYY |
| Component #2: DNN | enterprise2 |
| Route selection descriptor #2 | |
| Precedence | 2 (0x02) |
| Component #1: DNN | enterprise2 |
Enterprise 3
Support for Enterprise 3 is available in Android 13 and higher. The following is an example URSP rule for ENTERPRISE3 traffic:
| URSP rule #3 (enterprise3) | |
|---|---|
| Precedence | 3 (0x03) |
| Traffic descriptor #1 | |
| OS Id + OS App Id type | 0x97A498E3FC925C9489860333D06E4E470B454E544552505249534533 |
| Route selection descriptor #1 | |
| Precedence | 1 (0x01) |
| Component #1: S-NSSAI | SST:XX SD:YYYYYY |
| Component #2: DNN | enterprise3 |
| Route selection descriptor #2 | |
| Precedence | 2 (0x02) |
| Component #1: DNN | enterprise3 |
Enterprise 4
Support for Enterprise 4 is available in Android 13 and higher. The following is an example URSP rule for ENTERPRISE4 traffic:
| URSP rule #4 (enterprise4) | |
|---|---|
| Precedence | 4 (0x04) |
| Traffic descriptor #1 | |
| OS Id + OS App Id type | 0x97A498E3FC925C9489860333D06E4E470B454E544552505249534534 |
| Route selection descriptor #1 | |
| Precedence | 1 (0x01) |
| Component #1: S-NSSAI | SST:XX SD:YYYYYY |
| Component #2: DNN | enterprise4 |
| Route selection descriptor #2 | |
| Precedence | 2 (0x02) |
| Component #1: DNN | enterprise4 |
Enterprise 5
Support for Enterprise 5 is available in Android 13 and higher. The following is an example URSP rule for ENTERPRISE5 traffic:
| URSP rule #5 (enterprise5) | |
|---|---|
| Precedence | 5 (0x05) |
| Traffic descriptor #1 | |
| OS Id + OS App Id type | 0x97A498E3FC925C9489860333D06E4E470B454E544552505249534535 |
| Route selection descriptor #1 | |
| Precedence | 1 (0x01) |
| Component #1: S-NSSAI | SST:XX SD:YYYYYY |
| Component #2: DNN | enterprise5 |
| Route selection descriptor #2 | |
| Precedence | 2 (0x02) |
| Component #1: DNN | enterprise5 |
CBS
Support for CBS is available in Android 13 and higher. The following is an example URSP rule for CBS traffic:
| URSP rule #6 (CBS) | |
|---|---|
| Precedence | 6 (0x06) |
| Traffic descriptor #1 | |
| OS Id + OS App Id type | 0x97A498E3FC925C9489860333D06E4E4703434253 |
| Route selection descriptor #1 | |
| Precedence | 1 (0x01) |
| Component #1: S-NSSAI | SST:XX SD:YYYYYY |
| Component #2: DNN | cbs |
| Route selection descriptor #2 | |
| Precedence | 2 (0x02) |
| Component #1: DNN | cbs |
Low latency
Support for Low Latency is available in Android 13 and higher. The following is an example URSP rule for LOW_LATENCY traffic:
| URSP rule #7 (low latency) | |
|---|---|
| Precedence | 7 (0x07) |
| Traffic descriptor #1 | |
| OS Id + OS App Id type | 0x97A498E3FC925C9489860333D06E4E47125052494f524954495a455f4c4154454e4359 |
| Route selection descriptor #1 | |
| Precedence | 1 (0x01) |
| Component #1: S-NSSAI | SST:XX SD:YYYYYY |
| Component #2: DNN | latency |
| Route selection descriptor #2 | |
| Precedence | 2 (0x02) |
| Component #1: DNN | latency |
High bandwidth
Support for High Bandwidth is available in Android 13 and higher. The following is an example URSP rule for HIGH_BANDWIDTH traffic:
| URSP rule #8 (high bandwidth) | |
|---|---|
| Precedence | 8 (0x08) |
| Traffic descriptor #1 | |
| OS Id + OS App Id type | 97A498E3FC925C9489860333D06E4E47145052494f524954495a455f42414e445749445448 |
| Route selection descriptor #1 | |
| Precedence | 1 (0x01) |
| Component #1: S-NSSAI | SST:XX SD:YYYYYY |
| Component #2: DNN | bandwidth |
| Route selection descriptor #2 | |
| Precedence | 2 (0x02) |
| Component #1: DNN | bandwidth |
Default
| URSP rule #9 (default) | |
|---|---|
| Precedence | 9 (0x09) |
| Traffic descriptor #1 | |
| match-all | N/A |
| Route selection descriptor #1 | |
| Precedence | 1 (0x01) |
| Component #1: S-NSSAI | SST:XX SD:YYYYYY |
Testing
To test 5G network slicing, use the following manual test.
To setup a device for testing, do the following:
Ensure that the URSP policy is configured with a non-default rule that matches the enterprise category and that the corresponding route-selection descriptor maps the enterprise category to the enterprise slice; and a default rule directing traffic to the default internet slice.
Ensure that a work profile is configured on the device.
Opt in to using network slicing through the DPC
To test 5G network slicing behavior, do the following:
- Verify that a PDU session is established with the enterprise slice (for example, by using a specific IP address) and that apps in work profile use that PDU session.
- Verify that a separate PDU session is established with the default internet slice and that apps in the personal profile use the PDU session.
5G slicing upsell
The 5G slicing upsell feature, available from Android 14-QPR1, lets carriers offer enhanced network capabilities (latency and bandwidth) to their users through 5G network slicing.
The 5G slicing upsell feature uses the TS.43 response from the carrier entitlement server to drive the purchase flow. Carriers can use the response to specify the URL for the carrier's purchase webview, send additional data to the webview, and indicate whether the slice is provisioned and available on the carrier network.
Carriers can customize the behavior of the 5G slicing upsell feature using carrier configurations, which control whether purchase requests can be made, when apps are allowed to request premium capabilities, and how long the Telephony framework waits for responses from the user or the network.
The 5G slicing upsell feature provides an interface, called
DataBoostWebServiceFlow,
to allow communication between Android and the carrier webview.
Figure 2 shows the 5G slicing upsell purchase flow:
Figure 2. 5G slicing upsell purchase flow.
TS.43 entitlement process
When a user makes a request for enhanced network capabilities, the Telephony framework requests the service entitlement configuration for the requested premium capability. If the TS.43 response is valid, the Telephony framework uses the fields from the HTTP response to drive the purchase request.
Slice purchase fields
The TS.43 entitlement configuration includes the following slice purchase fields:
- Entitlement status
Key:
EntitlementStatusType:
intSupported values:
0(disabled),1(enabled),2(incompatible),3(provisioning),4(included)- Provisioning status
Key:
ProvStatusType:
intSupported values:
0(not provisioned),1(provisioned),2(not available),3(in progress)
The Telephony framework uses the combination of the entitlement status and provisioning status to determine the current slice purchase state. The result can be one of the following:
PURCHASE_PREMIUM_CAPABILITY_RESULT_ALREADY_PURCHASEDPURCHASE_PREMIUM_CAPABILITY_RESULT_ALREADY_IN_PROGRESSPURCHASE_PREMIUM_CAPABILITY_RESULT_ENTITLEMENT_CHECK_FAILEDPURCHASE_PREMIUM_CAPABILITY_RESULT_CARRIER_ERROR
If the entitlement status is 1 (enabled) and the provisioning status is 0
(not provisioned), the Telephony framework displays an upsell notification to
the user to purchase the boost through the carrier webview. The following table
describes the behavior of the Telephony framework for different combinations of
provisioning and entitlement status values.
| Provisioning status | |||||
|---|---|---|---|---|---|
Not provisioned (0) |
Provisioned (1 |
Not available (2) |
In progress (3) |
||
| Entitlement status | Disabled (0) |
Failed | Failed | Failed | Failed |
Enabled (1) |
Show webview | Already purchased | Already purchased | In progress | |
Incompatible (2) |
Failed | Failed | Failed | Failed | |
Provisioning (3) |
Carrier error | Carrier error | In progress | In progress | |
Included (4) |
Carrier error | Already purchased | Already purchased | Carrier error | |
Service flow fields
The TS.43 response specifies the URL, user data, and contents type to customize
the carrier purchase webview behavior. If the contents type is unspecified, the
URL is loaded as a GET request. If the user data exists, it's appended to the
URL as a query parameter (for example,
https://www.android.com?encodedValue=Base64EncodedUserData); and if it doesn't
exist, the URL is used as is (for example, https://www.android.com).
If the contents type is specified in JSON or XML format, the URL is loaded as a
POST request, and the user data (decoded if it is encoded in Base 64) is sent as
the data for the POST request.
- URL
Key:
ServiceFlow_URLType:
StringExample:
"https://www.android.com"- User data
Key:
ServiceFlow_UserDataType:
StringExample:
"encodedValue=Base64EncodedUserData"- Contents type
Key:
ServiceFlow_ContentsTypeType:
StringSupported values:
0(unspecified),1(JSON),2(XML)
Carrier configurations
The following are the carrier configurations available to customize the behavior of the 5G slicing upsell feature.
KEY_SUPPORTED_PREMIUM_CAPABILITIES_INT_ARRAYA list of premium capabilities that are supported. This is an int array of
TelephonyManager.PremiumCapability. These premium capabilities share the same value as the correspondingNetworkCapabilities.NetCapabilityclass. If a premium capability is requested and it isn't included in this configuration, the purchase request fails with theCARRIER_DISABLEDresult.In Android 14, only
PREMIUM_CAPABILITY_PRIORITIZE_LATENCYis supported.KEY_PREMIUM_CAPABILITY_MAXIMUM_DAILY_NOTIFICATION_COUNT_INTThe daily maximum number of times the purchase upsell notification is shown to the user. If the daily maximum is met, the upsell notification isn't shown and purchase requests (including entitlement server requests) are throttled until midnight of the next day. Purchase requests made after the daily maximum is reached fail with the
PURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLEDresult.KEY_PREMIUM_CAPABILITY_MAXIMUM_MONTHLY_NOTIFICATION_COUNT_INTThe monthly maximum number of times the purchase upsell notification is shown to the user. If the monthly maximum is met, the upsell notification isn't shown and purchase requests (including entitlement server requests) are throttled until the first day of the subsequent month. Purchase requests made after the monthly maximum is reached fail with the
PURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLEDresult.KEY_PREMIUM_CAPABILITY_PURCHASE_URL_STRINGThe backup carrier purchase URL to display to the user when they click the upsell notification. If the purchase URL isn't found in the TS.43 response from the entitlement server, this value is used instead. If neither the URL from the TS.43 response or the carrier configuration is valid, the purchase request fails with the
PURCHASE_PREMIUM_CAPABILITY_RESULT_CARRIER_DISABLEDresult.KEY_PREMIUM_CAPABILITY_SUPPORTED_ON_LTE_BOOLWhether to allow premium capabilities to be purchased when the device is connected to Long-Term Evolution (LTE). If
true, purchase requests can be made on both LTE and New Radio (NR). Iffalse, purchase requests can only be made on NR and requests made on LTE fail with thePURCHASE_PREMIUM_CAPABILITY_RESULT_NETWORK_NOT_AVAILABLEresult.KEY_PREMIUM_CAPABILITY_NOTIFICATION_DISPLAY_TIMEOUT_MILLIS_LONGThe amount of time to show the purchase upsell notification to the user before it's automatically canceled. When the notification is canceled, subsequent requests are throttled and fail with the
PURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLEDresult.KEY_PREMIUM_CAPABILITY_NOTIFICATION_BACKOFF_HYSTERESIS_TIME_MILLIS_LONGThe amount of time that subsequent purchase requests should be throttled after a failure due to timeout or user cancelation. If the user doesn't click the purchase upsell notification within the timeout specified by
KEY_PREMIUM_CAPABILITY_NOTIFICATION_DISPLAY_TIMEOUT_MILLIS_LONGor if they cancel or dismiss the notification, this backoff timer starts. While this timer is active, purchase requests fail with thePURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLEDresult.KEY_PREMIUM_CAPABILITY_PURCHASE_CONDITION_BACKOFF_HYSTERESIS_TIME_MILLIS_LONGThe amount of time that subsequent purchase requests should be throttled after a failure due to the carrier or network. If the entitlement check fails, the URL is unavailable, or the carrier purchase URL indicates a failure, this backoff timer starts. While this timer is active, purchase requests fail with the
PURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLEDresult.KEY_PREMIUM_CAPABILITY_NETWORK_SETUP_TIME_MILLIS_LONGThe amount of time within which the network must set up a slicing configuration for the purchase premium capability. During this period, subsequent purchase requests are blocked and return the
PURCHASE_PREMIUM_CAPABILITY_RESULT_PENDING_NETWORK_SETUPresult. If the network fails to set up a slicing configuration in time, apps can request to purchase premium capabilities again. Telephony doesn't consider a purchase complete until the corresponding slicing configuration is sent, regardless of whether the user paid the carrier or not.
Javascript interface
When the user clicks the network boost notification, a WebView object with
the carrier purchase URL is shown to the user. Carriers can use the APIs
provided in the
DataBoostWebServiceFlow
Javascript interface in their purchase website to communicate with the slice
purchase app.
The carrier website can get the requested premium capability through the method
getRequestedCapability().
If the purchase is successful, the carrier website must notify the slice
purchase app through notifyPurchaseSuccessful() or
notifyPurchaseSuccessful(duration) where duration is an optional parameter
indicating the intended duration of the slice.
If the purchase isn't successful, the carrier website must notify the slice
purchase app through the method notifyPurchaseFailed(code, reason), where code
is the failure code indicating the reason for failure and reason is the
human-readable reason for failure if the failure code is unknown.
If either of these response methods aren't called, the purchase won't be considered completed and the purchase request eventually times out.
The following are the valid failure codes that the carrier website can return for purchase failure:
FAILURE_CODE_UNKNOWNFAILURE_CODE_CARRIER_URL_UNAVAILABLEFAILURE_CODE_AUTHENTICATION_FAILEDFAILURE_CODE_PAYMENT_FAILEDFAILURE_CODE_NO_USER_DATA
When the purchase is completed the carrier must update the
URSP rules
with the PRIORITIZE_LATENCY slice to the user's device.