Pour les appareils équipés d'Android 12 ou version ultérieure, Android est compatible avec le découpage du réseau 5G, qui utilise la virtualisation du réseau pour diviser les connexions réseau uniques en plusieurs connexions virtuelles distinctes qui fournissent différentes quantités de ressources à différents types de trafic. Le découpage du réseau 5G permet aux opérateurs réseau de dédier une partie du réseau à la fourniture de fonctionnalités spécifiques pour un segment particulier de clients. Android 12 introduit les fonctionnalités de segmentation du réseau 5G pour les entreprises suivantes, que les opérateurs réseau peuvent proposer à leurs clients professionnels :
Partitionnement des appareils pour les entreprises (appareils entièrement gérés)
Pour les entreprises qui fournissent des appareils entièrement gérés à leurs employés, les fournisseurs de réseau peuvent leur fournir une ou plusieurs tranches de réseau d'entreprise actives vers lesquelles le trafic sur les appareils de l'entreprise est acheminé. Depuis Android 12, Android permet aux opérateurs de fournir des tranches d'entreprise via des règles URSP, au lieu de configurer des tranches via des APN.
Découpage des applications d'entreprise pour les appareils dotés de profils professionnels
Pour les entreprises qui utilisent la solution de profil professionnel, Android 12 permet aux appareils de router le trafic de toutes les applications du profil professionnel vers une tranche de réseau d'entreprise. Les entreprises peuvent activer cette fonctionnalité à l'aide d'un contrôleur de règles relatives aux appareils (DPC).
La solution de profil professionnel fournit un niveau d'authentification et de contrôle des accès automatique dont les entreprises ont besoin pour s'assurer que seul le trafic des applications professionnelles du profil professionnel est acheminé vers la tranche de réseau de l'entreprise. Il n'est pas nécessaire de modifier les applications du profil professionnel pour qu'elles demandent explicitement la tranche de réseau de l'entreprise.
Fonctionnement de la segmentation du réseau 5G dans AOSP
Android 12 est compatible avec le découpage du réseau 5G grâce à des ajouts au code de téléphonie dans AOSP et au module Tethering pour intégrer les API de connectivité existantes requises pour le découpage du réseau.
La plate-forme de téléphonie Android fournit des API HAL et de téléphonie pour prendre en charge le slicing basé sur les requêtes réseau déposées par le code réseau principal et les capacités de slicing 5G dans le modem. La figure 1 décrit les composants de la fonctionnalité de découpage du réseau 5G.
Figure 1. Architecture de segmentation du réseau 5G dans AOSP.
La plate-forme de téléphonie et de connectivité est compatible avec les éléments suivants :
- Conversion des requêtes réseau pour les catégories de tranches en descripteurs de trafic, qui sont ensuite transmis au modem pour la mise en correspondance du trafic URSP et la sélection de l'itinéraire
- Revenir au réseau par défaut si la tranche de réseau d'entreprise n'est pas disponible
- Acheminement du trafic de toutes les applications du profil professionnel vers la connexion correspondante
Prise en charge du slicing Enterprise
- Détecter la présence d'un profil professionnel sur l'appareil
- Vérification des autorisations ou des itinéraires fournis par le DPC utilisé par l'administrateur informatique de l'entreprise
Le service réseau principal inclut les modifications suivantes apportées au module Tethering dans Android 12 :
- Ajout de la plupart des classes d'API publiques ou système
android.net.*au module Tethering Les limites du module de partage de connexion sont étendues pour inclure :
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
Déplace le code VPN hors du module Tethering
Android 12 déplace le code avec les fonctionnalités suivantes vers le module Tethering :
- Recevoir des requêtes d'applications pour des connexions réseau
- Recevoir des requêtes du système (par exemple, "placer ces applications sur une tranche d'entreprise", introduit dans Android 12)
- Envoi de requêtes du système au code de téléphonie qui tente de configurer des réseaux ou des tranches en passant par l'API HAL et le modem
- Informer netd sur la manière d'acheminer le trafic par application (introduit dans Android 12)
- Informer les applications de ce qui se passe avec leur trafic réseau via les API
ConnectivityManagertelles queNetworkCallback,getActiveNetworketgetNetworkCapabilities.
Implémentation
Pour qu'un appareil soit compatible avec le découpage 5G, il doit disposer d'un modem compatible avec l'IRadio 1.6 HAL, qui possède l'API setupDataCall_1_6. Cette API configure une connexion de données et inclut les paramètres suivants pour la prise en charge du découpage 5G :
trafficDescriptor: spécifie le descripteur de trafic envoyé au modem.sliceInfo: spécifie les informations du découpage du réseau à utiliser en cas de transfert d'EPDG vers la 5G.matchAllRuleAllowed: indique si l'utilisation d'une règle URSP par défaut correspondant à tous les éléments est autorisée. La téléphonie définit cette valeur sur "true" pour les réseaux par défaut, mais pas pour les tranches. La règle "Tout correspond" est appliquée aux réseaux par défaut. Lorsqu'une application demande un segment spécifique qui n'est pas disponible, ce segment est signalé comme indisponible. Pour les applications d'entreprise, le framework Telephony peut revenir au réseau par défaut si le réseau d'entreprise n'est pas disponible.
Les modems doivent également implémenter l'API getSlicingConfig, sauf si elle est signalée comme non compatible par l'API getHalDeviceCapabilities.
Exigences pour les entreprises
Les exigences suivantes s'appliquent aux entreprises qui souhaitent utiliser le découpage du réseau 5G sur des appareils déployés dans une entreprise Android.
- Assurez-vous que les appareils entièrement gérés ou les appareils des employés configurés avec un profil professionnel sont compatibles avec la 5G SA et disposent de modems compatibles avec l'API
setupDataCall_1_6. - Collaborez avec un opérateur partenaire pour configurer et évaluer les performances des tranches ou les caractéristiques du SLA.
Activer le slicing 5G sur les appareils configurés avec un profil professionnel
Pour les appareils configurés avec des profils professionnels, le slicing de réseau 5G est désactivé par défaut dans AOSP. Pour activer le découpage du réseau, les administrateurs informatiques d'entreprise peuvent activer ou désactiver l'acheminement du trafic des applications du profil professionnel vers le segment de réseau de l'entreprise pour chaque employé via l'outil de contrôle des règles relatives aux appareils EMM, qui utilise la méthode setPreferentialNetworkServiceEnabled dans l'API DevicePolicyManager (DPM) (introduite dans Android 12).
Les fournisseurs EMM avec des DPC personnalisés doivent intégrer l'API DevicePolicyManager pour prendre en charge les clients professionnels.
Règles URSP
Cette section fournit aux opérateurs des informations sur la configuration des règles URSP pour différentes catégories de tranches, y compris le trafic d'entreprise, CBS, à faible latence et à bande passante élevée. Lors de la configuration des règles URSP pour différentes catégories de tranches, les opérateurs doivent utiliser les valeurs spécifiques à Android suivantes.
| ID | Valeur | Description |
|---|---|---|
| OSId | 97a498e3-fc92-5c94-8986-0333d06e4e47 |
L'OSId pour Android est un UUID de version 5 généré avec l'espace de noms ISO OID et le nom "Android". |
Les opérateurs doivent configurer des règles URSP pour chaque tranche de trafic avec le composant du descripteur de trafic "ID d'OS + type d'ID d'application d'OS". Par exemple, la tranche "ENTERPRISE" doit avoir une valeur de 0x97A498E3FC925C9489860333D06E4E470A454E5445525052495345.
Cette valeur est une concaténation de l'OSId, de la longueur de l'OSAppId (0x0A) et de l'OSAppId.
Pour en savoir plus sur le type de composant du descripteur de trafic, consultez le tableau 5.2.1 de la spécification technique 3GPP TS 24.526.
Le tableau suivant décrit les valeurs OSAppId pour différentes catégories de tranches.
| Catégorie de tranche | OSAppId | Description |
|---|---|---|
ENTERPRISE |
0x454E5445525052495345 |
OSAppId est une représentation sous forme de tableau d'octets de la chaîne ENTERPRISE. |
ENTERPRISE2 |
0x454E544552505249534532 |
OSAppId est une représentation sous forme de tableau d'octets de la chaîne ENTERPRISE2. |
ENTERPRISE3 |
0x454E544552505249534533 |
OSAppId est une représentation sous forme de tableau d'octets de la chaîne ENTERPRISE3. |
ENTERPRISE4 |
0x454E544552505249534534 |
OSAppId est une représentation sous forme de tableau d'octets de la chaîne ENTERPRISE4. |
ENTERPRISE5 |
0x454E544552505249534535 |
OSAppId est une représentation sous forme de tableau d'octets de la chaîne ENTERPRISE5. |
CBS |
0x434253 |
OSAppId est une représentation sous forme de tableau d'octets de la chaîne CBS. |
PRIORITIZE_LATENCY |
0x5052494f524954495a455f4c4154454e4359 |
OSAppId est une représentation sous forme de tableau d'octets de la chaîne PRIORITIZE_LATENCY. |
PRIORITIZE_BANDWIDTH |
0x5052494f524954495a455f42414e445749445448 |
OSAppId est une représentation sous forme de tableau d'octets de la chaîne PRIORITIZE_BANDWIDTH. |
PRIORITIZE_UNIFIED_COMMUNICATIONS |
0x5052494f524954495a455f554e49464945445f434f4d4d554e49434154494f4e53 |
OSAppId est une représentation sous forme de tableau d'octets de la chaîne PRIORITIZE_UNIFIED_COMMUNICATIONS. |
Exemples de règles URSP
Les tableaux suivants présentent des exemples de règles URSP pour le trafic Enterprise, CBS, à faible latence, à bande passante élevée et par défaut.
Enterprise 1
La prise en charge d'Enterprise 1 est disponible dans Android 12 et versions ultérieures. Voici un exemple de règle URSP pour le trafic ENTERPRISE1 :
| Règle URSP n° 1 (enterprise1) | |
|---|---|
| Priorité | 1 (0x01) |
| Descripteur de trafic n° 1 | |
| ID de l'OS + type d'ID de l'application de l'OS | 0x97A498E3FC925C9489860333D06E4E470A454E5445525052495345 |
| Descripteur de sélection d'itinéraire 1 | |
| Priorité | 1 (0x01) |
| Composant 1 : S-NSSAI | SST:XX SD:YYYYYY |
| Composant 2 : DNN | enterprise |
| Descripteur de sélection de route n° 2 | |
| Priorité | 2 (0x02) |
| Composant 1 : DNN | enterprise |
Enterprise 2
La prise en charge d'Enterprise 2 est disponible dans Android 13 et versions ultérieures. Voici un exemple de règle URSP pour le trafic ENTERPRISE2 :
| Règle URSP n° 2 (enterprise2) | |
|---|---|
| Priorité | 2 (0x02) |
| Descripteur de trafic n° 1 | |
| ID de l'OS + type d'ID de l'application de l'OS | 0x97A498E3FC925C9489860333D06E4E470B454E544552505249534532 |
| Descripteur de sélection d'itinéraire 1 | |
| Priorité | 1 (0x01) |
| Composant 1 : S-NSSAI | SST:XX SD:YYYYYY |
| Composant 2 : DNN | enterprise2 |
| Descripteur de sélection de route n° 2 | |
| Priorité | 2 (0x02) |
| Composant 1 : DNN | enterprise2 |
Enterprise 3
La prise en charge d'Enterprise 3 est disponible dans Android 13 et versions ultérieures. Voici un exemple de règle URSP pour le trafic ENTERPRISE3 :
| Règle URSP n° 3 (enterprise3) | |
|---|---|
| Priorité | 3 (0x03) |
| Descripteur de trafic n° 1 | |
| ID de l'OS + type d'ID de l'application de l'OS | 0x97A498E3FC925C9489860333D06E4E470B454E544552505249534533 |
| Descripteur de sélection d'itinéraire 1 | |
| Priorité | 1 (0x01) |
| Composant 1 : S-NSSAI | SST:XX SD:YYYYYY |
| Composant 2 : DNN | enterprise3 |
| Descripteur de sélection de route n° 2 | |
| Priorité | 2 (0x02) |
| Composant 1 : DNN | enterprise3 |
Enterprise 4
La prise en charge d'Enterprise 4 est disponible dans Android 13 et les versions ultérieures. Voici un exemple de règle URSP pour le trafic ENTERPRISE4 :
| Règle URSP n°4 (enterprise4) | |
|---|---|
| Priorité | 4 (0x04) |
| Descripteur de trafic n° 1 | |
| ID de l'OS + type d'ID de l'application de l'OS | 0x97A498E3FC925C9489860333D06E4E470B454E544552505249534534 |
| Descripteur de sélection d'itinéraire 1 | |
| Priorité | 1 (0x01) |
| Composant 1 : S-NSSAI | SST:XX SD:YYYYYY |
| Composant 2 : DNN | enterprise4 |
| Descripteur de sélection de route n° 2 | |
| Priorité | 2 (0x02) |
| Composant 1 : DNN | enterprise4 |
Enterprise 5
La prise en charge d'Enterprise 5 est disponible dans Android 13 et versions ultérieures. Voici un exemple de règle URSP pour le trafic ENTERPRISE5 :
| Règle 5 de l'URSP (enterprise5) | |
|---|---|
| Priorité | 5 (0x05) |
| Descripteur de trafic n° 1 | |
| ID de l'OS + type d'ID de l'application de l'OS | 0x97A498E3FC925C9489860333D06E4E470B454E544552505249534535 |
| Descripteur de sélection d'itinéraire 1 | |
| Priorité | 1 (0x01) |
| Composant 1 : S-NSSAI | SST:XX SD:YYYYYY |
| Composant 2 : DNN | enterprise5 |
| Descripteur de sélection de route n° 2 | |
| Priorité | 2 (0x02) |
| Composant 1 : DNN | enterprise5 |
CBS
La prise en charge de CBS est disponible dans Android 13 et versions ultérieures. Voici un exemple de règle URSP pour le trafic CBS :
| Règle 6 de l'URSP (CBS) | |
|---|---|
| Priorité | 6 (0x06) |
| Descripteur de trafic n° 1 | |
| ID de l'OS + type d'ID de l'application de l'OS | 0x97A498E3FC925C9489860333D06E4E4703434253 |
| Descripteur de sélection d'itinéraire 1 | |
| Priorité | 1 (0x01) |
| Composant 1 : S-NSSAI | SST:XX SD:YYYYYY |
| Composant 2 : DNN | cbs |
| Descripteur de sélection de route n° 2 | |
| Priorité | 2 (0x02) |
| Composant 1 : DNN | cbs |
Latence faible
La faible latence est disponible dans Android 13 et versions ultérieures. Voici un exemple de règle URSP pour le trafic LOW_LATENCY :
| Règle 7 de l'URSP (faible latence) | |
|---|---|
| Priorité | 7 (0x07) |
| Descripteur de trafic n° 1 | |
| ID de l'OS + type d'ID de l'application de l'OS | 0x97A498E3FC925C9489860333D06E4E47125052494f524954495a455f4c4154454e4359 |
| Descripteur de sélection d'itinéraire 1 | |
| Priorité | 1 (0x01) |
| Composant 1 : S-NSSAI | SST:XX SD:YYYYYY |
| Composant 2 : DNN | latence |
| Descripteur de sélection de route n° 2 | |
| Priorité | 2 (0x02) |
| Composant 1 : DNN | latence |
Bande passante élevée
La prise en charge de la bande passante élevée est disponible dans Android 13 et versions ultérieures. Voici un exemple de règle URSP pour le trafic HIGH_BANDWIDTH :
| Règle URSP 8 (bande passante élevée) | |
|---|---|
| Priorité | 8 (0x08) |
| Descripteur de trafic n° 1 | |
| ID de l'OS + type d'ID de l'application de l'OS | 97A498E3FC925C9489860333D06E4E47145052494f524954495a455f42414e445749445448 |
| Descripteur de sélection d'itinéraire 1 | |
| Priorité | 1 (0x01) |
| Composant 1 : S-NSSAI | SST:XX SD:YYYYYY |
| Composant 2 : DNN | bande passante |
| Descripteur de sélection de route n° 2 | |
| Priorité | 2 (0x02) |
| Composant 1 : DNN | bande passante |
Par défaut
| Règle URSP n° 9 (par défaut) | |
|---|---|
| Priorité | 9 (0x09) |
| Descripteur de trafic n° 1 | |
| match-all | N/A |
| Descripteur de sélection d'itinéraire 1 | |
| Priorité | 1 (0x01) |
| Composant 1 : S-NSSAI | SST:XX SD:YYYYYY |
Tests
Pour tester le découpage du réseau 5G, utilisez le test manuel suivant.
Pour configurer un appareil à des fins de test :
Assurez-vous que la stratégie URSP est configurée avec une règle non définie par défaut qui correspond à la catégorie d'entreprise, et que le descripteur de sélection de route correspondant mappe la catégorie d'entreprise à la tranche d'entreprise. Assurez-vous également qu'une règle par défaut dirige le trafic vers la tranche Internet par défaut.
Assurez-vous qu'un profil professionnel est configuré sur l'appareil.
Activer l'utilisation du découpage du réseau via le DPC
Pour tester le comportement du découpage du réseau 5G :
- Vérifiez qu'une session PDU est établie avec la tranche d'entreprise (par exemple, en utilisant une adresse IP spécifique) et que les applications du profil professionnel utilisent cette session PDU.
- Vérifiez qu'une session PDU distincte est établie avec la tranche Internet par défaut et que les applications du profil personnel utilisent la session PDU.
Vente incitative du découpage 5G
La fonctionnalité de vente incitative de découpage 5G, disponible à partir d'Android 14 QPR1, permet aux opérateurs de proposer à leurs utilisateurs des capacités réseau améliorées (latence et bande passante) grâce au découpage du réseau 5G.
La fonctionnalité de vente incitative du découpage 5G utilise la réponse TS.43 du serveur d'autorisation de l'opérateur pour déclencher le parcours d'achat. Les opérateurs peuvent utiliser la réponse pour spécifier l'URL de la vue Web d'achat de l'opérateur, envoyer des données supplémentaires à la vue Web et indiquer si la tranche est provisionnée et disponible sur le réseau de l'opérateur.
Les opérateurs peuvent personnaliser le comportement de la fonctionnalité de vente incitative du découpage 5G à l'aide de configurations d'opérateur. Celles-ci contrôlent si des demandes d'achat peuvent être effectuées, quand les applications sont autorisées à demander des fonctionnalités Premium et combien de temps le framework Telephony attend les réponses de l'utilisateur ou du réseau.
La fonctionnalité de vente incitative de la segmentation 5G fournit une interface, appelée DataBoostWebServiceFlow, pour permettre la communication entre Android et la WebView de l'opérateur.
La figure 2 illustre le parcours d'achat de l'option de découpage 5G :
Figure 2. Parcours d'achat pour la vente incitative du découpage 5G.
Processus d'attribution TS.43
Lorsqu'un utilisateur demande des fonctionnalités réseau améliorées, le framework Telephony demande la configuration des droits d'accès au service pour la fonctionnalité premium demandée. Si la réponse TS.43 est valide, le framework Telephony utilise les champs de la réponse HTTP pour générer la demande d'achat.
Segmenter les champs d'achat
La configuration des droits d'accès TS.43 inclut les champs d'achat de tranche suivants :
- État du droit d'accès
Clé :
EntitlementStatusType :
intValeurs acceptées :
0(désactivé),1(activé),2(incompatible),3(provisionnement),4(inclus)- État du provisionnement
Clé :
ProvStatusType :
intValeurs acceptées :
0(non provisionné),1(provisionné),2(non disponible),3(en cours)
Le framework de téléphonie combine l'état des droits d'accès et l'état du provisionnement pour déterminer l'état actuel de l'achat de la tranche. Le résultat peut être l'un des suivants :
PURCHASE_PREMIUM_CAPABILITY_RESULT_ALREADY_PURCHASEDPURCHASE_PREMIUM_CAPABILITY_RESULT_ALREADY_IN_PROGRESSPURCHASE_PREMIUM_CAPABILITY_RESULT_ENTITLEMENT_CHECK_FAILEDPURCHASE_PREMIUM_CAPABILITY_RESULT_CARRIER_ERROR
Si l'état du droit d'accès est 1 (activé) et que l'état du provisionnement est 0 (non provisionné), le framework de téléphonie affiche une notification de vente incitative à l'utilisateur pour qu'il achète le forfait via la WebView de l'opérateur. Le tableau suivant décrit le comportement du framework Telephony pour différentes combinaisons de valeurs d'état de provisionnement et d'autorisation.
| État du provisionnement | |||||
|---|---|---|---|---|---|
Non provisionné (0) |
Provisionné (1) |
Non disponible (2) |
En cours (3) |
||
| État du droit d'accès | Désactivé (0) |
Échec | Échec | Échec | Échec |
Activé (1) |
Afficher WebView | Déjà acheté | Déjà acheté | En cours | |
Incompatible (2) |
Échec | Échec | Échec | Échec | |
Provisionnement (3) |
Erreur de l'opérateur | Erreur de l'opérateur | En cours | En cours | |
Inclus (4) |
Erreur de l'opérateur | Déjà acheté | Déjà acheté | Erreur de l'opérateur | |
Champs du flux de service
La réponse TS.43 spécifie l'URL, les données utilisateur et le type de contenu pour personnaliser le comportement de la vue Web d'achat de l'opérateur. Si le type de contenu n'est pas spécifié, l'URL est chargée en tant que requête GET. Si les données utilisateur existent, elles sont ajoutées à l'URL en tant que paramètre de requête (par exemple, https://www.android.com?encodedValue=Base64EncodedUserData). Si elles n'existent pas, l'URL est utilisée telle quelle (par exemple, https://www.android.com).
Si le type de contenu est spécifié au format JSON ou XML, l'URL est chargée en tant que requête POST, et les données utilisateur (décodées si elles sont encodées en Base64) sont envoyées en tant que données pour la requête POST.
- URL
Clé :
ServiceFlow_URLType :
StringExemple :
"https://www.android.com"- Données utilisateur
Clé :
ServiceFlow_UserDataType :
StringExemple :
"encodedValue=Base64EncodedUserData"- Type de contenu
Clé :
ServiceFlow_ContentsTypeType :
StringValeurs acceptées :
0(non spécifié),1(JSON),2(XML)
Configurations de l'opérateur
Vous trouverez ci-dessous les configurations d'opérateur disponibles pour personnaliser le comportement de la fonctionnalité de vente incitative pour le découpage 5G.
KEY_SUPPORTED_PREMIUM_CAPABILITIES_INT_ARRAYListe des fonctionnalités premium compatibles. Il s'agit d'un tableau d'entiers de
TelephonyManager.PremiumCapability. Ces fonctionnalités premium partagent la même valeur que la classeNetworkCapabilities.NetCapabilitycorrespondante. Si une fonctionnalité premium est demandée et qu'elle n'est pas incluse dans cette configuration, la demande d'achat échoue et le résultatCARRIER_DISABLEDest renvoyé.Dans Android 14, seul
PREMIUM_CAPABILITY_PRIORITIZE_LATENCYest pris en charge.KEY_PREMIUM_CAPABILITY_MAXIMUM_DAILY_NOTIFICATION_COUNT_INTNombre maximal de fois par jour où la notification d'upsell d'achat est présentée à l'utilisateur. Si le nombre maximal quotidien est atteint, la notification de vente incitative ne s'affiche pas et les demandes d'achat (y compris les demandes au serveur d'autorisation) sont limitées jusqu'à minuit le jour suivant. Les demandes d'achat effectuées après avoir atteint le nombre maximal quotidien échouent et renvoient le résultat
PURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLED.KEY_PREMIUM_CAPABILITY_MAXIMUM_MONTHLY_NOTIFICATION_COUNT_INTNombre maximal de fois par mois où la notification d'incitation à l'achat est présentée à l'utilisateur. Si le maximum mensuel est atteint, la notification de vente incitative ne s'affiche pas et les demandes d'achat (y compris les demandes au serveur d'autorisation) sont limitées jusqu'au premier jour du mois suivant. Les demandes d'achat effectuées après avoir atteint le maximum mensuel échouent et renvoient le résultat
PURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLED.KEY_PREMIUM_CAPABILITY_PURCHASE_URL_STRINGURL d'achat de l'opérateur de secours à afficher à l'utilisateur lorsqu'il clique sur la notification de vente incitative. Si l'URL d'achat n'est pas trouvée dans la réponse TS.43 du serveur d'habilitation, cette valeur est utilisée à la place. Si l'URL de la réponse TS.43 ou la configuration de l'opérateur ne sont pas valides, la demande d'achat échoue et le résultat
PURCHASE_PREMIUM_CAPABILITY_RESULT_CARRIER_DISABLEDest renvoyé.KEY_PREMIUM_CAPABILITY_SUPPORTED_ON_LTE_BOOLIndique si les fonctionnalités premium peuvent être achetées lorsque l'appareil est connecté à la technologie Long-Term Evolution (LTE). Si la valeur est
true, les demandes d'achat peuvent être effectuées à la fois sur LTE et New Radio (NR). Si la valeur estfalse, les demandes d'achat ne peuvent être effectuées que sur NR. Les demandes effectuées sur LTE échouent avec le résultatPURCHASE_PREMIUM_CAPABILITY_RESULT_NETWORK_NOT_AVAILABLE.KEY_PREMIUM_CAPABILITY_NOTIFICATION_DISPLAY_TIMEOUT_MILLIS_LONGDurée pendant laquelle la notification de vente incitative d'achat s'affiche pour l'utilisateur avant d'être automatiquement annulée. Lorsque la notification est annulée, les requêtes suivantes sont limitées et échouent avec le résultat
PURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLED.KEY_PREMIUM_CAPABILITY_NOTIFICATION_BACKOFF_HYSTERESIS_TIME_MILLIS_LONGDélai pendant lequel les demandes d'achat ultérieures doivent être limitées après un échec dû à un délai d'attente ou à une annulation par l'utilisateur. Si l'utilisateur ne clique pas sur la notification d'upselling d'achat dans le délai spécifié par
KEY_PREMIUM_CAPABILITY_NOTIFICATION_DISPLAY_TIMEOUT_MILLIS_LONG, ou s'il annule ou ferme la notification, ce minuteur de désactivation démarre. Lorsque ce minuteur est actif, les demandes d'achat échouent et renvoient le résultatPURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLED.KEY_PREMIUM_CAPABILITY_PURCHASE_CONDITION_BACKOFF_HYSTERESIS_TIME_MILLIS_LONGDélai pendant lequel les demandes d'achat ultérieures doivent être limitées après un échec dû à l'opérateur ou au réseau. Si la vérification des droits d'accès échoue, si l'URL n'est pas disponible ou si l'URL d'achat auprès de l'opérateur indique un échec, ce minuteur de délai avant nouvelle tentative démarre. Tant que ce minuteur est actif, les demandes d'achat échouent et renvoient le résultat
PURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLED.KEY_PREMIUM_CAPABILITY_NETWORK_SETUP_TIME_MILLIS_LONGDélai dans lequel le réseau doit configurer le slicing pour la fonctionnalité premium d'achat. Pendant cette période, les demandes d'achat ultérieures sont bloquées et renvoient le résultat
PURCHASE_PREMIUM_CAPABILITY_RESULT_PENDING_NETWORK_SETUP. Si le réseau ne parvient pas à configurer une configuration de découpage à temps, les applications peuvent demander à acheter à nouveau des fonctionnalités premium. La téléphonie ne considère pas un achat comme terminé tant que la configuration de segmentation correspondante n'est pas envoyée, que l'utilisateur ait payé ou non l'opérateur.
Interface JavaScript
Lorsque l'utilisateur clique sur la notification d'augmentation du réseau, un objet WebView avec l'URL d'achat de l'opérateur s'affiche. Les opérateurs peuvent utiliser les API fournies dans l'interface JavaScript DataBoostWebServiceFlow sur leur site Web d'achat pour communiquer avec l'application d'achat de tranches.
Le site Web du transporteur peut obtenir la fonctionnalité premium demandée via la méthode getRequestedCapability().
Si l'achat est effectué, le site Web de l'opérateur doit notifier l'application d'achat de tranche via notifyPurchaseSuccessful() ou notifyPurchaseSuccessful(duration), où duration est un paramètre facultatif indiquant la durée prévue de la tranche.
Si l'achat n'aboutit pas, le site Web de l'opérateur doit en informer l'application d'achat de tranches via la méthode notifyPurchaseFailed(code, reason), où code est le code d'échec indiquant la raison de l'échec et reason est la raison de l'échec lisible par l'utilisateur si le code d'échec est inconnu.
Si l'une de ces méthodes de réponse n'est pas appelée, l'achat ne sera pas considéré comme terminé et la demande d'achat finira par expirer.
Voici les codes d'échec valides que le site Web du transporteur peut renvoyer en cas d'échec de l'achat :
FAILURE_CODE_UNKNOWNFAILURE_CODE_CARRIER_URL_UNAVAILABLEFAILURE_CODE_AUTHENTICATION_FAILEDFAILURE_CODE_PAYMENT_FAILEDFAILURE_CODE_NO_USER_DATA
Une fois l'achat effectué, l'opérateur doit mettre à jour les règles URSP avec la tranche PRIORITIZE_LATENCY sur l'appareil de l'utilisateur.
Routage automatique du découpage 5G pour les services OTT de voix et de vidéo
Android 17 permet le routage automatique des appels vocaux et vidéo over-the-top (OTT) vers des connexions réseau premium. Cette fonctionnalité permet au système de rediriger automatiquement le trafic des appels vocaux et vidéo vers une interface réseau premium dédiée (telle qu'une tranche 5G premium ou une connexion PDN 4G premium) sans nécessiter de modifications de la pile réseau de l'application.
Cette solution au niveau de la plate-forme élimine la nécessité pour les développeurs d'applications de demander explicitement des fonctionnalités réseau, offrant ainsi une expérience fluide aux développeurs et aux utilisateurs finaux.
Fonctionnement
Android intègre la prise en charge du routage automatique grâce à des ajouts aux frameworks de connectivité et de télécommunications. La fonctionnalité de routage automatique fonctionne comme suit :
- Détection des appels : le système utilise les API Telecom Jetpack existantes utilisées par les applications OTT pour détecter le début et la fin des appels vocaux ou vidéo.
- Gestion de la connexion : lorsqu'un appel est détecté, Android affiche une interface réseau premium dédiée, telle qu'une tranche de communication unifiée.
- Orientation du trafic : pendant l'appel, la plate-forme identifie l'application par son UID et achemine automatiquement son trafic vers la connexion réseau premium.
- Rétablissement après l'appel : une fois l'appel terminé, la plate-forme supprime la règle de routage et le trafic de l'application revient au réseau système par défaut pour le trafic non lié aux appels (comme la messagerie).
Conditions requises
Pour que le routage automatique des appels OTT soit possible, les exigences suivantes doivent être remplies :
- Opérateurs : ils doivent proposer une tranche de communication unifiée en configurant les règles URSP appropriées. Les opérateurs doivent renseigner l'URSP avec un
OSAppIDspécifique pour le trafic de communications unifiées. - Applications : elles doivent utiliser les API Android Telecom Jetpack pour permettre au système de détecter les états des appels.
- Fabricants d'appareils : Android 17 ou version ultérieure est requis.