5G ネットワーク スライス

Android 12 以降を搭載したデバイスでは、Android は 5G ネットワーク スライシングに対応しています。これは、ネットワーク仮想化で 1 つのネットワーク接続を複数の仮想接続に分割し、仮想接続ごとに異なる種類のトラフィックに対する異なる量のリソースを提供するという機能です。5G ネットワーク スライシングにより、ネットワーク事業者は、ネットワークの一部を特定の顧客セグメント専用にして、特定の機能を提供できます。Android 12 では、以下の 5G エンタープライズ ネットワーク スライシング機能が導入されています。ネットワーク オペレーターはこれらの機能を企業クライアントに提供できます。

完全管理対象デバイス向けエンタープライズ デバイス スライシング

完全管理対象の社有デバイスを従業員に提供している企業の場合、ネットワーク プロバイダが 1 つ以上のアクティブなエンタープライズ ネットワーク スライスを提供して、社有デバイスのトラフィックをそこにルーティングするようにできます。Android 12 以降では、携帯通信会社は APN を通じてスライスを設定する代わりに、URSP ルールを通じてエンタープライズ スライスを提供できるようになっています。

仕事用プロファイルが設定されたデバイス向けのエンタープライズ ビジネスアプリ スライス

仕事用プロファイル ソリューションを使用している企業の場合、Android 12 では、仕事用プロファイルのすべてのアプリが送信元であるトラフィックをエンタープライズ ネットワーク スライスにルーティングできます。この機能は、企業が Device Policy Controller（DPC）から有効にできます。

仕事用プロファイル ソリューションは、仕事用プロファイルのエンタープライズ アプリからのトラフィックのみをエンタープライズ ネットワーク スライスにルーティングするために必要となる、認証レベルの自動化とアクセス制御を提供します。仕事用プロファイルのアプリを修正して、エンタープライズ ネットワーク スライスを明示的にリクエストする必要はありません。

AOSP での 5G ネットワーク スライシングの動作

Android 12 では、AOSP のテレフォニー コードベースと Tethering モジュールへの追加によって、ネットワーク モジュール スライシングに必要な既存の接続 API を組み込むことで、5G ネットワーク スライシングのサポートが導入されています。

Android のテレフォニー プラットフォームは、コア ネットワーク コードとモデムの 5G スライシング機能から申請されたネットワーク リクエストに基づくスライシングをサポートする HAL とテレフォニー API を提供しています。図 1 は、5G ネットワーク スライシング機能のコンポーネントを示しています。

5G ネットワーク スライシングのコンポーネント

図 1. AOSP の 5G ネットワーク スライシングのアーキテクチャ

テレフォニーと接続のプラットフォームは、以下をサポートしています。

  • スライス カテゴリのネットワーク リクエストをトラフィック記述子に変換してから、URSP トラフィック マッチングとルート選択のためにモデムに渡す
  • エンタープライズ ネットワーク スライスが使用できない場合にデフォルト ネットワークにフォールバックする
  • 仕事用プロファイルのすべてのアプリが送信元であるトラフィックを、対応する接続にルーティングする

  • エンタープライズ スライシングのサポート

    • デバイス上の仕事用プロファイルの存在を検出する
    • 企業の IT 管理者が使用している DPC から提供される権限またはルーティング指示を確認する

Android 12 では、コア ネットワーク サービスの Tethering モジュールに以下の変更があります。

  • android.net.* の公開 API またはシステム 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.java
    • f/b/services/core/java/com/android/server/TestNetworkService.java

  • VPN コードを Tethering モジュールの外へ移動

Android 12 では、以下の機能を備えたコードを Tethering モジュールに移動します。

  • アプリからのネットワーク接続のリクエストを受信する
  • システムからのリクエストを受信する（Android 12 で導入された「このアプリをエンタープライズ スライスに配置する」など）
  • システムからテレフォニーのコードにリクエストを送信する（テレフォニーのコードでは HAL API とモデムを通じてネットワークまたはスライスをセットアップする）
  • アプリごとにトラフィックのルーティング方法を netd に通知する（Android 12 で導入）
  • NetworkCallback、getActiveNetwork、getNetworkCapabilities などの ConnectivityManager API を通じて、ネットワーク トラフィックで何が発生しているかをアプリに通知する

実装

デバイスで 5G スライスをサポートするには、setupDataCall_1_6 API を備えた IRadio 1.6 HAL をサポートするモデムが必要になります。この API はデータ接続をセットアップし、5G スライスをサポートするための以下のパラメータを含んでいます。

  • trafficDescriptor: モデムに送信されるトラフィック記述子を指定します。
  • sliceInfo: EPDG から 5G にハンドオーバーする場合に使用されるネットワーク スライスの情報を指定します。
  • matchAllRuleAllowed: デフォルトのマッチオール URSP ルールの使用を許可するかどうかを指定します。テレフォニーは、デフォルト ネットワークではこれを true に設定しますが、スライスでは true に設定しません。マッチオール ルールはデフォルト ネットワークに適用されます。利用できない特定のスライスをアプリがリクエストした場合、そのスライスは利用不可と報告されます。エンタープライズ アプリでは、エンタープライズ ネットワークが利用できない場合、テレフォニー フレームワークがデフォルト ネットワークにフォールバックできます。

また、モデムでは、getHalDeviceCapabilities API でサポートされていないと報告されない限り、getSlicingConfig API を実装する必要があります。

企業の要件

Android Enterprise デプロイメントのデバイスで 5G ネットワーク スライスを使用する際の企業の要件は以下のとおりです。

  • 仕事用プロファイルが設定された完全管理対象デバイスまたは従業員のデバイスが、setupDataCall_1_6 API をサポートするモデムを備えた 5G SA 対応であること。
  • スライスの設定、パフォーマンス、SLA 特性に関して、携帯通信会社のパートナーと協力すること。

仕事用プロファイルが設定されたデバイスで 5G スライシングを有効にする

仕事用プロファイルが設定されているデバイスの場合、AOSP では 5G ネットワーク スライシングはデフォルトでオフになっています。ネットワーク スライシングを有効にするために、企業の IT 管理者は EMM DPC を通じて従業員ごとにエンタープライズ ネットワーク スライスに対する仕事用プロファイル アプリのトラフィックのルーティングをオンまたはオフにできます。EMM DPC は、DevicePolicyManager（DPM）API（Android 12 で導入）の setPreferentialNetworkServiceEnabled メソッドを使用します。

カスタム DPC を使用する EMM ベンダーがエンタープライズ クライアントをサポートするには、DevicePolicyManager API を統合する必要があります。

URSP ルール

このセクションでは、エンタープライズ、CBS、低遅延、高帯域幅のトラフィックを含んでいるさまざまなスライス カテゴリの URSP ルールを設定する際の携帯通信会社向けの情報について説明します。さまざまなスライス カテゴリの URSP ルールを設定する場合、携帯通信会社は次の Android 固有の値を使用する必要があります。

ID 値 説明
OSId 97a498e3-fc92-5c94-8986-0333d06e4e47 Android の OSId は、名前空間「ISO OID」と名前「Android」を使って生成された、バージョン 5 の UUID です。

携帯通信会社は、トラフィック記述子コンポーネントを「OS Id + OS App Id type」とする URSP ルールを各スライス トラフィックに設定する必要があります。たとえば、「ENTERPRISE」スライスの値は 0x97A498E3FC925C9489860333D06E4E470A454E5445525052495345 とします。この値は、OSId、OSAppId の長さ（0x0A）、OSAppId を連結したものです。トラフィック記述子のコンポーネント タイプについて詳しくは、3GPP TS 24.526 の表 5.2.1 をご覧ください。

次の表に、スライス カテゴリごとの 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」のバイト配列表現です

URSP ルールの例

次の表は、エンタープライズ、CBS、低遅延、高帯域幅、デフォルトのトラフィックの URSP ルールの例を示しています。

エンタープライズ 1

エンタープライズ 1 のサポートは Android 12 以降で利用できます。以下に、ENTERPRISE1 トラフィックの URSP ルールの例を示します。

URSP ルール #1（enterprise1）
優先度 1（0x01）
トラフィック記述子 #1
OS Id + OS App Id type 0x97A498E3FC925C9489860333D06E4E470A454E5445525052495345
ルート選択記述子 #1
優先度 1（0x01）
コンポーネント #1: S-NSSAI SST:XX SD:YYYYYY
コンポーネント #2: DNN enterprise
ルート選択記述子 #2
優先度 2（0x02）
コンポーネント #1: DNN enterprise

エンタープライズ 2

エンタープライズ 2 のサポートは Android 13 以降で利用できます。以下に、ENTERPRISE2 トラフィックの URSP ルールの例を示します。

URSP ルール #2（enterprise2）
優先度 2（0x02）
トラフィック記述子 #1
OS Id + OS App Id type 0x97A498E3FC925C9489860333D06E4E470B454E544552505249534532
ルート選択記述子 #1
優先度 1（0x01）
コンポーネント #1: S-NSSAI SST:XX SD:YYYYYY
コンポーネント #2: DNN enterprise2
ルート選択記述子 #2
優先度 2（0x02）
コンポーネント #1: DNN enterprise2

エンタープライズ 3

エンタープライズ 3 のサポートは Android 13 以降で利用できます。以下に、ENTERPRISE3 トラフィックの URSP ルールの例を示します。

URSP ルール #3（enterprise3）
優先度 3（0x03）
トラフィック記述子 #1
OS Id + OS App Id type 0x97A498E3FC925C9489860333D06E4E470B454E544552505249534533
ルート選択記述子 #1
優先度 1（0x01）
コンポーネント #1: S-NSSAI SST:XX SD:YYYYYY
コンポーネント #2: DNN enterprise3
ルート選択記述子 #2
優先度 2（0x02）
コンポーネント #1: DNN enterprise3

エンタープライズ 4

エンタープライズ 4 のサポートは Android 13 以降で利用できます。以下に、ENTERPRISE4 トラフィックの URSP ルールの例を示します。

URSP ルール #4（enterprise4）
優先度 4（0x04）
トラフィック記述子 #1
OS Id + OS App Id type 0x97A498E3FC925C9489860333D06E4E470B454E544552505249534534
ルート選択記述子 #1
優先度 1（0x01）
コンポーネント #1: S-NSSAI SST:XX SD:YYYYYY
コンポーネント #2: DNN enterprise4
ルート選択記述子 #2
優先度 2（0x02）
コンポーネント #1: DNN enterprise4

エンタープライズ 5

エンタープライズ 5 のサポートは Android 13 以降で利用できます。以下に、ENTERPRISE5 トラフィックの URSP ルールの例を示します。

URSP ルール #5（enterprise5）
優先度 5（0x05）
トラフィック記述子 #1
OS Id + OS App Id type 0x97A498E3FC925C9489860333D06E4E470B454E544552505249534535
ルート選択記述子 #1
優先度 1（0x01）
コンポーネント #1: S-NSSAI SST:XX SD:YYYYYY
コンポーネント #2: DNN enterprise5
ルート選択記述子 #2
優先度 2（0x02）
コンポーネント #1: DNN enterprise5

CBS

CBS のサポートは Android 13 以降で利用できます。以下に、CBS トラフィックの URSP ルールの例を示します。

URSP ルール #6（CBS）
優先度 6（0x06）
トラフィック記述子 #1
OS Id + OS App Id type 0x97A498E3FC925C9489860333D06E4E4703434253
ルート選択記述子 #1
優先度 1（0x01）
コンポーネント #1: S-NSSAI SST:XX SD:YYYYYY
コンポーネント #2: DNN cbs
ルート選択記述子 #2
優先度 2（0x02）
コンポーネント #1: DNN cbs

低遅延

低遅延のサポートは Android 13 以降で利用できます。以下に、LOW_LATENCY トラフィックの URSP ルールの例を示します。

URSP ルール #7（低遅延）
優先度 7（0x07）
トラフィック記述子 #1
OS Id + OS App Id type 0x97A498E3FC925C9489860333D06E4E47125052494f524954495a455f4c4154454e4359
ルート選択記述子 #1
優先度 1（0x01）
コンポーネント #1: S-NSSAI SST:XX SD:YYYYYY
コンポーネント #2: DNN 遅延
ルート選択記述子 #2
優先度 2（0x02）
コンポーネント #1: DNN 遅延

高帯域幅

高帯域幅のサポートは Android 13 以降で利用できます。以下に、HIGH_BANDWIDTH トラフィックの URSP ルールの例を示します。

URSP ルール #8（高帯域幅）
優先度 8（0x08）
トラフィック記述子 #1
OS Id + OS App Id type 97A498E3FC925C9489860333D06E4E47145052494f524954495a455f42414e445749445448
ルート選択記述子 #1
優先度 1（0x01）
コンポーネント #1: S-NSSAI SST:XX SD:YYYYYY
コンポーネント #2: DNN bandwidth
ルート選択記述子 #2
優先度 2（0x02）
コンポーネント #1: DNN bandwidth

デフォルト

URSP ルール #9（デフォルト）
優先度 9（0x09）
トラフィック記述子 #1
match-all なし
ルート選択記述子 #1
優先度 1（0x01）
コンポーネント #1: S-NSSAI SST:XX SD:YYYYYY

テスト

5G ネットワーク スライシングのテストには、次の手動テストを使用します。

テスト用のデバイスをセットアップする手順は次のとおりです。

  1. URSP ポリシーに、エンタープライズ カテゴリに一致し、かつ対応するルート選択記述子がエンタープライズ カテゴリをエンタープライズ スライスにマッピングするデフォルトでないルールと、トラフィックをデフォルトのインターネットにルーティングするデフォルトのルールを設定します。

  2. デバイスに仕事用プロファイルを設定します。

  3. DPC を通じてネットワーク スライシングの使用を許可します。

5G ネットワーク スライシングの動作をテストするには、次の手順を実行します。

  1. PDU セッションがエンタープライズ スライスで確立されていることを（特定の IP アドレスを使用するなどして）確認し、仕事用プロファイルのアプリでその PDU セッションを使用していることを確認します。
  2. デフォルトのインターネット スライスで別の PDU セッションが確立され、個人用プロファイルのアプリでその PDU セッションが使用されていることを確認します。

5G スライシング アップセル

Android 14-QPR1 から利用できるようになった 5G スライシング アップセル機能により、携帯通信会社は 5G ネットワーク スライシングを通じてユーザーに拡張ネットワーク機能（遅延および帯域幅）を提供できるようになっています。

5G スライシング アップセル機能では、携帯通信会社の利用資格サーバーからの TS.43 レスポンスを使用して購入フローを進めます。携帯通信会社は、このレスポンスを使用して携帯通信会社の購入ウェブビューの URL を指定したり、ウェブビューに追加データを送信したりできます。また、スライスがプロビジョニングされ携帯通信会社のネットワークで利用可能であるかどうかを示することもできます。

携帯通信会社は、携帯通信会社設定を使用して 5G スライシング アップセルの動作をカスタマイズできます。この設定では、購入リクエストを行うことができるかどうか、アプリにいつ有料機能のリクエストを許可するか、テレフォニー フレームワークがユーザーやネットワークからのレスポンスをどの程度待機するかを制御できます。

5G スライシング アップセル機能では、Android と携帯通信会社のウェブビュー間の通信を可能にする DataBoostWebServiceFlow と呼ばれるインターフェースを提供しています。

5G スライシング アップセルの購入フローを図 2 に示します。

5G スライシング アップセルの購入フロー

図 2. 5G スライシング アップセルの購入フロー。

TS.43 利用資格のプロセス

ユーザーが拡張ネットワーク機能をリクエストすると、テレフォニー フレームワークは、リクエストされた有料機能のサービス利用資格設定をリクエストします。TS.43 レスポンスが有効な場合、テレフォニー フレームワークは HTTP レスポンスのフィールドを使用して購入リクエストを進めます。

スライス購入フィールド

TS.43 利用資格設定には次のスライス購入フィールドが含まれます。

利用資格ステータス

キー: EntitlementStatus

タイプ: int

サポートされている値: 0（無効）、1（有効）、2（非対応）、3（プロビジョニング）、4（付属）

プロビジョニング ステータス

キー: ProvStatus

タイプ: int

サポートされている値: 0（未プロビジョニング）、1（プロビジョニング済み）、2（利用不可）、3（処理中）

テレフォニー フレームワークは、利用資格ステータスとプロビジョニング ステータスを組み合わせて使用し、現在のスライス購入の状態を決定します。結果は次のいずれかになります。

利用資格ステータスが 1（有効）で、プロビジョニング ステータスが 0（未プロビジョニング）である場合、テレフォニー フレームワークは携帯通信会社のウェブビューを通じてブーストを購入するようユーザーにアップセル通知を表示します。次の表に、プロビジョニング ステータスの値と利用資格ステータスの値の各組み合わせに対するテレフォニー フレームワークの動作を示します。

プロビジョニング ステータス
未プロビジョニング（0） プロビジョニング済み（1)） 利用不可（2） 処理中（3）
利用資格ステータス 無効（0） 失敗 失敗 失敗 失敗
有効（1） ウェブビューを表示 すでに購入済み すでに購入済み 処理中
非対応（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

サポートされている有料機能のリスト。これは TelephonyManager.PremiumCapability の int 配列です。 これらの有料機能は、対応する NetworkCapabilities.NetCapability クラスと同じ値を共有します。リクエストされた有料機能がこの設定に含まれていない場合、購入リクエストは CARRIER_DISABLED という結果で失敗します。

Android 14 では、PREMIUM_CAPABILITY_PRIORITIZE_LATENCY のみがサポートされています。

KEY_PREMIUM_CAPABILITY_MAXIMUM_DAILY_NOTIFICATION_COUNT_INT

ユーザーに表示される購入アップセル通知の 1 日の最大数。1 日の最大数に達するとアップセル通知は表示されなくなり、購入リクエスト（利用資格サーバーのリクエストを含む）は翌日の午前 0 時までスロットリングされます。1 日の最大数に達した後に行われた購入リクエストは、PURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLED という結果で失敗します。

KEY_PREMIUM_CAPABILITY_MAXIMUM_MONTHLY_NOTIFICATION_COUNT_INT

ユーザーに表示される購入アップセル通知の 1 か月の最大数。1 か月の最大数に達するとアップセル通知は表示されなくなり、購入リクエスト（利用資格サーバーのリクエストを含む）は翌月の初日までスロットリングされます。1 か月の最大数に達した後に行われた購入リクエストは、PURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLED という結果で失敗します。

KEY_PREMIUM_CAPABILITY_PURCHASE_URL_STRING

アップセル通知をクリックした場合にユーザーに表示されるバックアップの携帯通信会社の購入 URL。利用資格サーバーからの TS.43 レスポンスに購入 URL が見つからない場合、代わりにこの値が使用されます。TS.43 レスポンスからの URL や携帯通信会社の設定のいずれも有効でない場合、購入リクエストは 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 インターフェース

ユーザーがネットワーク ブースト通知をクリックすると、携帯通信会社の購入 URL を含む WebView オブジェクトがユーザーに表示されます。携帯通信会社は、購入ウェブサイトの DataBoostWebServiceFlow JavaScript インターフェースで指定された API を使用して、スライス購入アプリと通信できます。

携帯通信会社のウェブサイトはメソッド getRequestedCapability() を通じて有料機能のリクエストを受けられます。

購入が正常に完了した場合、携帯通信会社のウェブサイトは notifyPurchaseSuccessful() または notifyPurchaseSuccessful(duration) を通じてスライス購入アプリに通知する必要があります。duration はスライスの想定時間を示すオプション パラメータです。

購入が正常に完了しなかった場合、携帯通信会社のウェブサイトは、メソッド notifyPurchaseFailed(code, reason) を通じてスライス購入アプリに通知する必要があります。code は失敗の理由を示す失敗コードで、reason は、失敗コードが不明な場合に人が読める形式で示された失敗の理由です。

これらのレスポンス メソッドのいずれかが呼び出されなかった場合、購入は完了したとは見なされず、購入リクエストはタイムアウトになります。

携帯通信会社のウェブサイトが購入失敗に対して返せる有効な失敗コードを以下に示します。

購入が完了したら、携帯通信会社はユーザーのデバイスに対し、PRIORITIZE_LATENCY スライスで URSP ルールを更新する必要があります。