JP6737812B2 - ネットワークアクセストークンを使用したダウンリンクトラフィックのための効率的なポリシー実施−制御プレーン手法 - Google Patents

Description

関連出願の相互参照
本出願は、2015年5月21日に米国特許商標庁に出願された仮出願第62/165,056号、および2016年1月28日に米国特許商標庁に出願された非仮出願第15/009,188号の優先権および利益を主張し、それらの内容全体が参照により本明細書に組み込まれる。

本明細書で説明する態様は、一般に、パケット検証および/またはマッピングのためのトークンの使用に関し、より詳細には、ネットワークアクセストークンをゲートウェイデバイスにおいて導出することに関し、ネットワークアクセストークンは、アプリケーションサーバに関連するアプリケーション機能へ制御プレーン(Cプレーン)シグナリングの中で送られ、アプリケーションサーバからゲートウェイデバイスへユーザプレーン(Uプレーン)トラフィックの中で送られるダウンリンクデータパケットの中に含められ、ダウンリンクポリシー実施のためにゲートウェイデバイスによって使用される。

セルラー通信ネットワークなどのデジタル通信ネットワークでは、デバイス(たとえば、チップコンポーネント、クライアントデバイス、モバイルデバイス、ユーザ機器、端末)、無線アクセスネットワーク(RAN:radio access network)、コアネットワーク、およびアプリケーションサーバの間で、パケットが交換され得る。アプリケーションサーバは、たとえば、パケットデータネットワーク(PDN:packet data network)(たとえば、インターネット)および/またはインターネットプロトコル(IP)マルチメディアサービス(IMS)ネットワークの一部であってよい。

RANは、セルラー通信ネットワーク(たとえば、4G、ロングタームエボリューション(LTE)、LTE-アドバンスト(LTE-A)、および5Gなどの将来のネットワーク)の一部であってよい。セルラー通信ネットワーク(本明細書では通信ネットワークとも呼ぶ)は、RANおよびコアネットワーク(CN:core network)(たとえば、発展型パケットコア(EPC:evolved packet core))を含み得る。デバイス、RAN、およびコアネットワークの間で交換されるパケットは、制御プレーン上およびユーザプレーン上で交換され得る。パケットは、制御プレーンメッセージおよびユーザプレーンメッセージの中で交換され得る。制御プレーンメッセージは、制御信号(たとえば、制御シグナリング、制御プレーンシグナリング)を含み得る。ユーザプレーンメッセージは、ユーザデータ(たとえば、ユーザデータトラフィック、データトラフィック)を含み得る。

アップリンク方向およびダウンリンク方向で進行するパケットは、ベアラ(たとえば、IP接続性アクセスネットワーク(IP-CAN:IP Connectivity Access Network)ベアラ)を通じて転送されてよく、またはより一般的には(たとえば、ベアラが規定されないことがあるかまたは使用されないことがあるセルラー通信ネットワークでは)、データフローの中で転送されてよい。当業者に知られているように、デバイスに向かって流れるデータの方向は、ダウンリンク方向と呼ばれることがあり、デバイスから流れるデータの方向は、アップリンク方向と呼ばれることがある。

例示のためにダウンリンク方向を使用すると、ダウンリンクインターネットプロトコル(IP)パケット(以下で、「ダウンリンクデータパケット」)は、たとえば、PDN(たとえば、インターネット)からコアネットワークの中へ流れる。ダウンリンクデータパケットは、パケットデータネットワークゲートウェイデバイス(P-GW)を経由してコアネットワークに入り得る。P-GWは、ネットワークポリシー(たとえば、コアネットワークポリシー)のための実施ポイントであってよい。P-GWは、ダウンリンクデータパケット上でネットワークポリシー(たとえば、ダウンリンクポリシー)を実施し得る。

P-GWにおけるダウンリンクデータパケットの処理は、様々なダウンリンクデータパケットがセルラー通信ネットワークにおける様々なベアラまたはデータフローにマッピングされるのを必要とすることがある。様々なベアラまたはデータフローは、たとえば、様々な異なる最大ビットレート(MBR:maximum bit rate)、および/またはQoSに影響を及ぼし得る他のパラメータをサポートし得る。

マッピングするための現在の解決策は、パケット検査(たとえば、深いパケット検査および/または浅いパケット検査)、トラフィックフローテンプレート(TFT:traffic flow template)、およびサービスデータフロー(SDF:service data flow)テンプレートを使用して実現される。現在の解決策は、本明細書ではTFT/SDF手法と呼ぶ。TFT/SDF手法では、P-GWは、ダウンリンクデータパケットがアプリケーションサービスに対して規定されたTFT/SDFテンプレートに準拠することを、各ダウンリンクデータパケットのヘッダを検査することによって確かめる。

TFT/SDF手法は、たとえば、各ダウンリンクデータパケットをベアラにマッピングするために、SDFテンプレートにおけるパケットフィルタのセットをダウンリンクデータパケットが通過することを伴う。

図1は、従来技術による、(たとえば、ダウンリンクデータパケット106のストリームからの)サービスデータフロー(a〜f)104のダウンリンク部を検出し、そのダウンリンク部を図示のIP-CANベアラ108などのデータフローまたはベアラにマッピングする際の、サービスデータフロー(SDF)テンプレート102の役割を示す。SDFテンプレート102に対応しないいかなるパケットも、廃棄110ロケーションに配信され得る。図1は、第3世代パートナーシッププロジェクト(3GPP)技術仕様(TS)23.203、図6.4に基づく。

SDFテンプレート102は、ダウンリンクデータパケット106のストリームの中の各ダウンリンクデータパケットを検証およびマッピングするためのプロシージャにおいて使用される。SDFテンプレート102は、フィルタ処理のために使用される。マッピングは、対応するSDFフィルタにデータパケットを適用するいくつかの機能によって行われてよい。次いで、SDFフィルタがポリシーを実施する。しかしながら、SDFテンプレート102におけるパケットフィルタのセットの使用は、テーブルおよびテーブルルックアッププロシージャの使用を伴う。そのようなテーブルおよびプロシージャの使用は、テーブルがメモリ/記憶空間を占有しプロシージャの実行がプロセッサリソースを消費するという点で、効率に影響を及ぼす。追加として、ダウンリンクデータパケット106のストリームの中の任意の所与のパケットが、その中の1つまたは複数のフィルタの要件のすべてを満たすSDFテンプレート102に適用される前に、ダウンリンクデータパケット106のストリームの中の各パケットが各SDFテンプレート102内の1つまたは複数のフィルタを通じてフィルタ処理されなければならないという点で、時間リソースが浪費される。

たとえば、ダウンリンクトラフィックのアクセスおよびポリシー実施のためにP-GWにおいてパケット検査(たとえば、深いパケット検査および/または浅いパケット検査)およびTFT/SDFテンプレートを使用することは、オーバーヘッド(たとえば、メモリルックアップおよびパターン照合のための処理およびメモリリソース)を招くことがあり、処理遅延に起因する転送レイテンシを付加する。追加として、追加のポリシー制御は追加のオーバーヘッドおよび処理遅延を招くことになるので、(たとえば、アプリケーションサービスごとの)きめ細かいポリシー制御は困難である。さらに、TFT/SDFテンプレートの使用は、スポンサー付きの接続性にとってスケーラブルでない。たとえば、異なるアプリケーションサービス(おそらくは、来たるべき数年における数千の新たなアプリケーションサービス)のスポンサーの数の増加は、増加した数のテンプレートを通じてパケットをフィルタ処理するのに必要な時間の増大を意味することになる。このことは、やはり追加のオーバーヘッドおよび処理遅延を招くことになる。

第3世代パートナーシッププロジェクト(3GPP)技術仕様(TS)23.203、図6.4

望まれることは、ダウンリンクトラフィックに対してアクセスおよびポリシー実施の効率を改善するための方法である。

一態様によれば、ゲートウェイデバイスにおいて動作可能であり得る方法が本明細書で開示される。方法は、デバイスに関連するトリガをゲートウェイデバイスにおいて検出するステップを含み得る。トリガの検出に応答して、方法は、引き続き、デバイスに関連するアプリケーションサービスを識別し得、アプリケーションサービスに関連するトラフィックネットワークポリシーを取得し得、トラフィックネットワークポリシーに基づくネットワークアクセストークンを取得し得、制御プレーンシグナリングの中でネットワークアクセストークンをエンティティへ送り得る。ネットワークアクセストークンは、デバイスに向けられているユーザプレーントラフィックの中でゲートウェイデバイスにおいて取得されたダウンリンクデータパケットの検証および/またはマッピングを容易にし得る。一例によれば、ゲートウェイデバイスはパケットデータネットワークゲートウェイデバイス(P-GW)である。

一態様によれば、トリガは、アプリケーションサービスに関連するトラフィックネットワークポリシーを取得すること、トラフィックネットワークポリシーに基づくネットワークアクセストークンを取得すること、および/または制御プレーンシグナリングの中でネットワークアクセストークンをエンティティへ送ることのうちの、1つまたは複数をゲートウェイデバイスに実行させるための制御プレーンメッセージを、ゲートウェイデバイスにおいて取得することを含む。一例では、制御プレーンメッセージは、アプリケーションサービスに関連するトラフィックネットワークポリシーを取得すること、トラフィックネットワークポリシーに基づくネットワークアクセストークンを取得すること、および/または制御プレーンシグナリングの中でネットワークアクセストークンをエンティティへ送ることのうちの、1つまたは複数を実行するための明示的コマンドを含む。一例では、制御プレーンメッセージは、アプリケーションサービスに関連するトラフィックネットワークポリシーを取得すること、トラフィックネットワークポリシーに基づくネットワークアクセストークンを取得すること、および/または制御プレーンシグナリングの中でネットワークアクセストークンをエンティティへ送ることのうちの、1つまたは複数を実行するための暗黙的コマンドを含む。一例では、制御プレーンメッセージは、ベアラセットアップメッセージ、ベアラ活動化メッセージ、および/またはベアラ変更メッセージのうちの1つまたは複数に関連付けられる。一例では、制御プレーンメッセージは、セッション作成要求である。一態様によれば、トリガは、アプリケーションサービスに向けられている、デバイスから送られた第1のデータパケットをゲートウェイデバイスにおいて取得することを含む。

一例では、アプリケーションサービスに関連するトラフィックネットワークポリシーは、ポリシーおよび課金ルール機能(PCRF:policy and charging rules function)から取得される。トラフィックネットワークポリシーは、モバイルネットワークオペレータとアプリケーションサービスプロバイダとの間のサービスレベル合意、および/またはデバイスの加入プロファイルに基づいて規定されてよい。一例では、エンティティはポリシーおよび課金ルール機能(PCRF)であり、ネットワークアクセストークンは、制御プレーンシグナリングの中でPCRFへ送られる。一例では、エンティティはアプリケーション機能であり、ネットワークアクセストークンは、制御プレーンシグナリングの中でアプリケーション機能へ送られる。一例では、エンティティはアプリケーション機能であり、ネットワークアクセストークンは、ポリシーおよび課金ルール機能(PCRF)を経由して制御プレーンシグナリングの中でアプリケーション機能へ送られる。

一態様によれば、方法は、制御プレーンシグナリングの中でアプリケーション識別子(App ID)をエンティティへ送るステップをさらに含み得る。一例では、App IDは、アプリケーションサーバ、アプリケーションサービス、ならびに/またはアプリケーションサーバおよび/もしくはアプリケーションサービスに関連するアプリケーション機能のうちの1つまたは複数を識別する。一態様では、ゲートウェイデバイスにおいてユーザプレーントラフィックの中でダウンリンクデータパケットを取得する前に、ネットワークアクセストークンは、ゲートウェイデバイスにおいて取得されてよく、制御プレーンシグナリングの中でエンティティへ送られてよい。一実装形態では、方法は、ネットワークアクセストークンを含むダウンリンクデータパケットを、ゲートウェイデバイスにおいてユーザプレーントラフィックの中で取得するステップと、1つまたは複数のプロセスを実行するステップとをさらに含み得る。1つまたは複数のプロセスは、ネットワークアクセストークンを確認しネットワークアクセストークンから取得されたデータを使用してダウンリンクデータパケットをデバイスにマッピングすること、またはネットワークアクセストークンから取得されたデータを使用してダウンリンクデータパケットをデバイスにマッピングすることを含み得る。方法は、ネットワークアクセストークンをダウンリンクデータパケットから除去するステップと、マッピングに従ってダウンリンクデータパケットをデバイスへ送るステップとをさらに含み得る。一例によれば、ネットワークアクセストークンを確認することは、ダウンリンクデータパケットから取得されたデータに基づいて第2のネットワークアクセストークンを取得することと、ネットワークアクセストークンを第2のネットワークアクセストークンと比較することとを含む。一例では、ネットワークアクセストークンおよび第2のネットワークアクセストークンが等しい場合、ネットワークアクセストークンの確認が成功する。一態様によれば、第2のネットワークアクセストークンは、ダウンリンクデータパケットから取得されたデータ、およびトラフィックネットワークポリシーに基づいてよい。

アプリケーションサーバおよび通信ネットワークと通信するように適合された通信回路と、通信回路に結合された処理回路とを含む、ゲートウェイデバイスが本明細書で説明される。一態様によれば、処理回路は、上記で例示した方法を実行するように構成され得る。上記で例示した方法を実行するように構成されたゲートウェイデバイスが、本明細書で説明される。追加として、少なくとも1つのプロセッサによって実行されたとき、少なくとも1つのプロセッサに、上記で例示した方法を実行させる1つまたは複数の命令が記憶された非一時的機械可読記憶媒体も、本明細書で説明される。

別の態様によれば、アプリケーションサーバにおいて動作可能な方法が本明細書で説明される。方法は、デバイスにリンクされるとともにアプリケーションサービスにリンクされたネットワークアクセストークンを、アプリケーションサーバにおいて取得するステップを含み得る。方法は、デバイスに向けたダウンリンクデータパケットを作成するステップと、ダウンリンクデータパケットをネットワークアクセストークンにマッピングするステップと、ダウンリンクデータパケットの中にネットワークアクセストークンを含めるステップと、ネットワークアクセストークンを含むダウンリンクデータパケットを、ゲートウェイデバイスを経由してユーザプレーントラフィックの中でデバイスへ送るステップとをさらに含み得る。一態様によれば、ネットワークアクセストークンは、制御プレーンシグナリングの中でゲートウェイデバイスから取得されている。一例では、ネットワークアクセストークンは、アプリケーションサーバに関連するアプリケーション機能において、制御プレーンシグナリングの中でゲートウェイデバイスから取得されている。一態様によれば、ネットワークアクセストークンは、ゲートウェイデバイスに関連するポリシーおよび課金ルール機能(PCRF)とのインターフェースを介してアプリケーション機能において取得されている。一例では、ネットワークアクセストークンは、アプリケーションサーバにさらにリンクされる。一態様では、アプリケーションサービスは、アプリケーションサーバ上でホスティングされる。一例では、ネットワークアクセストークンは、インターネットプロトコル(IP)ヘッダであってIPv4用のIPオプションフィールドであるIPヘッダ、インターネットプロトコル(IP)ヘッダであってIPv6用のIP拡張ヘッダであるIPヘッダ、伝送制御プロトコル(TCP)ヘッダ、セキュアソケットレイヤ(SSL)ヘッダ、トランスポートレイヤセキュリティ(TLS)レコードヘッダ、インターネットプロトコル(IP)ヘッダと伝送制御プロトコル/ユーザデータグラムプロトコル(TCP/UDP)ヘッダとの間のシムヘッダ(shim header)、および/またはハイパーテキスト転送プロトコル(HTTP)ヘッダのうちの1つまたは複数の中に含まれる。

通信ネットワークと通信するように適合された通信回路と、通信回路に結合された処理回路とを含む、アプリケーションサーバが本明細書で説明される。一態様によれば、処理回路は、上記で例示した方法を実行するように構成され得る。追加として、上記で例示した方法を実行するように構成されたアプリケーションサーバが本明細書で説明される。追加として、少なくとも1つのプロセッサによって実行されたとき、少なくとも1つのプロセッサに、上記で例示した方法を実行させる1つまたは複数の命令が記憶された非一時的機械可読記憶媒体も、本明細書で説明される。

従来技術による、サービスデータフローのダウンリンク部を検出し、そのダウンリンク部をデータフローまたはベアラにマッピングする際の、サービスデータフロー(SDF)テンプレートの役割を示す図である。 現在のサービスデータフロー/トラフィックフローテンプレート(SDF/TFT)手法を、本明細書で説明する態様による例示的な実装形態と比較する図である。 本明細書で説明する態様による例示的な動作環境を示す図である。 本明細書で説明する態様によるダウンリンク動作の一例を示す図である。 制御プレーン(Cプレーン)を使用する、ゲートウェイデバイス(たとえば、P-GW)におけるネットワークアクセストークンのセットアップ(たとえば、サービス識別、ネットワークアクセストークン導出、ネットワークアクセストークン送信)、およびユーザプレーン(Uプレーン)におけるネットワークアクセストークンの使用を示す、例示的なフローチャートである。 本明細書で説明する態様による、制御プレーンにおけるネットワークアクセストークン(代替として、本明細書および図6では「DLトークン」と呼ぶ)のセットアップ(たとえば、サービス識別、ネットワークアクセストークン導出、ネットワークアクセストークン送信)の一例を示す例示的な制御プレーンコールフロー図である。 本明細書で説明する態様による、ユーザプレーンにおけるネットワークアクセストークン(代替として、本明細書および図7では「DLトークン」と呼ぶ)の使用の一例を示す例示的なユーザプレーンコールフロー図である。 本明細書で説明する態様による第1のユーザプレーンプロトコルスタックの例示的な図である。 本明細書で説明する態様による第2のユーザプレーンプロトコルスタックの例示的な図である。 本明細書で説明する態様による、ネットワークアクセストークンを含むダウンリンクデータパケットの検証および/またはマッピングをサポートするように適合された例示的なゲートウェイデバイスを示すブロック図である。 本明細書で説明する態様に従って制御プレーンにおいて実施される、ネットワークアクセストークンセットアップの例示的な方法のフローチャートである。 本明細書で説明する態様に従ってユーザプレーンにおいて実施される、ネットワークアクセストークンを使用するポリシー実施の例示的な方法のフローチャートである。 本明細書で説明する態様に従ってユーザプレーンにおいて実施される、ネットワークアクセストークンを使用するポリシー実施の別の例示的な方法のフローチャートである。 本明細書で説明する態様による、ダウンリンクデータパケットの検証および/またはマッピングをサポートするように適合された例示的なアプリケーションサーバを示すブロック図である。 本明細書で説明する態様による、アプリケーションサーバが、ネットワークアクセストークンを取得し、ダウンリンクデータパケットの中にネットワークアクセストークンを含め(たとえば、埋め込み、関連付け)、ゲートウェイデバイスを経由してデータ送信の中でダウンリンクデータパケットをデバイスへ送る、例示的な方法のフローチャートである。 本明細書で説明する態様による、ダウンリンクデータパケットの検証および/またはマッピングをサポートするように適合された例示的なデバイスを示すブロック図である。

以下の説明では、添付の図面に対する参照が行われ、添付の図面には、例として、本開示で説明する特定の態様および特徴が示される。本開示で説明する態様および特徴は、当業者が本発明を実践することを可能にするだけ十分詳しく提供されることが意図される。本開示の範囲から逸脱することなく、他の態様および特徴が利用されてよく、また開示されたものに対して変更が行われてよい。以下の詳細な説明は限定的な意味で解釈されるべきではなく、本明細書で説明および図示する態様、特徴、および実装形態の範囲は、添付の特許請求の範囲によってのみ定義される。

「例示的」という用語は、「例、事例、または例示の働きをすること」を意味するために本明細書で使用される。「例示的」として本明細書で説明するいかなる態様、特徴、または実装形態も、他の態様、特徴、もしくは実装形態よりも好ましいか、または有利であると必ずしも解釈されるべきでない。「態様」という用語は、すべての態様が、説明する態様または任意の説明する特徴、利点、および/もしくは動作モードを含むことを必要としない。「取得する」という用語は、導出する、生成する、計算する、要求する、受信する、取得する、受諾する、調達する、取る、収集する、得る、配信または受信を行う、与えられる、アクセスできるようになる、入手するなどを意味するために本明細書で使用される。本明細書で使用する「取得する」という用語は、局所的に取得すること、ならびに/または非局所的もしくはリモートエンティティ(たとえば、デバイス、サーバ、ポリシーおよび課金ルール機能(PCRF)、アプリケーション機能(AF)、ノード)から取得することを包含する。本明細書で使用する「取得する」という用語は、部分的に取得すること、および/または完全に取得することを包含する。「デバイス」という用語は、デバイスの中でも、チップコンポーネント、クライアントデバイス、ワイヤレスデバイス、モバイルデバイス、モバイルフォン、モバイル通信デバイス、モバイルコンピューティングデバイス、デジタルタブレット、スマートフォン、ユーザ機器、ユーザデバイス、ユーザ端末、アクセス端末、および/または端末を指すために本明細書で使用される。「送る」という用語は、宛先まで運搬させるためにプロビジョニングする、送信する、転送する、提供する、供給するを意味するために本明細書で使用される。

本明細書で使用する「ネットワークアクセストークン」は、暗号トークンなどのトークンであってよい。本明細書で使用する「ネットワークアクセストークン」は、「ネットワークアクセストークン」、「ダウンリンク(DL)トークン」、または「DLトークン」と呼ばれることがある。

本明細書で使用する「アプリケーション機能」は、制御プレーンエンティティ(たとえば、制御プレーンにおいて機能性を有するエンティティ)であってよい。アプリケーション機能は、アプリケーションサーバの一部(たとえば、それに含まれる、それに関連付けられる、それに結合される)であってよい。

本明細書で使用する「アプリケーションサーバ」は、ユーザプレーンエンティティ(たとえば、ユーザプレーンにおいて機能性を有するエンティティ)であってよい。たとえば、アプリケーションサーバは、パケットを作成(たとえば、構築、コンパイル、形成、アセンブル)するとともにダウンリンクユーザプレーントラフィックの中でパケットをデバイスへ送る、ユーザプレーンエンティティであってよい。アプリケーションサーバは、1つまたは複数のアプリケーションおよび/またはアプリケーションサービス(個別に、かつ総称して、本明細書では「アプリケーションサービス」と呼ぶ)をホスティングし得る。例示的なアプリケーションサービスは、1つまたは複数のタイプのトラフィック、たとえば、ストリーミングビデオ、音声、およびデータサービスを含む。デバイスは、アプリケーションサービスに加入し得る。本明細書で使用する「アプリケーションサービス」は、アプリケーションサービスプロバイダによって提供される任意のサービス(たとえば、IPアプリケーション)であってよい。

パケットデータネットワーク(PDN)(たとえば、インターネット)およびIPマルチメディアサービス(IMS)ネットワークなどの、セルラー通信ネットワークのコアネットワークの外部のネットワークは、PDNへの参照によって本明細書で例示されることがあるが、コアネットワークの外部のネットワークをPDNまたはIMSネットワークに限定することは何ら意図されない。さらに、本明細書で提示する態様および特徴は例示的である。本明細書で提示する任意の態様または特徴を、セルラー通信ネットワークのみにおいて使用するように限定することは何ら意図されない。

概要
本明細書で説明する態様は、ネットワークアクセストークンを取得するとともに、制御プレーンシグナリングの中でネットワークアクセストークンをアプリケーション機能へ送るように、ゲートウェイデバイス(たとえば、パケットデータネットワーク(PDN)ゲートウェイデバイス(P-GW))がトリガされることをもたらし得る。P-GWは、暗号機能などの機能を使用してネットワークアクセストークンを取得する(たとえば、導出する、生成する、計算する、要求する、受信する、取得する、受諾する、調達する、取る、収集する、得る、配信または受信を行う、与えられる、アクセスできるようになる、入手する)ことがある。ネットワークアクセストークンは、デバイスおよび/またはアプリケーションサービスにリンクされ得る。ネットワークアクセストークンは、コアネットワークの制御プレーンエンティティ(たとえば、PCRF)を経由して制御プレーンインターフェースを介して(すなわち、制御プレーンメッセージを使用して)アプリケーション機能へ送られ得る。

アプリケーションサーバは、アプリケーションサーバに関連するアプリケーション機能からネットワークアクセストークンを取得し得る。アプリケーションサーバは、デバイスに向けたダウンリンクデータパケットを作成(たとえば、構築、コンパイル、形成、アセンブル)し得る。アプリケーションサーバは、ネットワークアクセストークンをダウンリンクデータパケットに含めてよく(たとえば、埋め込んでよく、関連付けてよく)、ネットワークアクセストークンを含むダウンリンクデータパケットを、P-GWを経由してユーザプレーンにおいてデバイスへ送ってよい。

P-GWは、ダウンリンクデータパケットを(たとえば、ダウンリンクデータパケットに含まれるネットワークアクセストークンを確認することによって)検証することができ、かつ/またはネットワークアクセストークンから取得されたデータを使用して、ダウンリンクデータパケットをデバイスまたはデバイスのために確立されたベアラ/サービスフローにマッピングすることができる。P-GWは、ネットワークアクセストークンから取得されたマッピングデータを使用して、ダウンリンクデータパケットをデバイスへ送ることができる。

概して、アプリケーションサーバからのネットワークアクセストークンを含むダウンリンクデータパケットを、P-GWがユーザプレーンにおいて転送/処理するために、ネットワークアクセストークンは、P-GWによって最初に導出されてよく、制御プレーンにおいてアプリケーション機能へ送られてよく、アプリケーション機能からアプリケーションサーバによって取得されてよい。ネットワークアクセストークンは複製されてよく、複製はアプリケーションサーバからデバイスへ送られる各ダウンリンクデータパケットの中に含められてよい。

本明細書で説明する例示的な態様とのSDF/TFT手法の比較
図2は、現在のサービスデータフロー/トラフィックフローテンプレート(SDF/TFT)手法200を、本明細書で説明する態様による例示的な実装形態202と比較する図を提供する。例示的な図において、サービスA〜N204(ただし、Nは正の整数)は、第1のIPパケットフロー206および第2のIPパケットフロー208を、それぞれ、第1のP-GW210および第2のP-GW212に提供する。第1のIPパケットフロー206は、各IPパケットに含まれる(たとえば、埋め込まれる、関連付けられる)ネットワークアクセストークンを有しない。第2のIPパケットフロー208は、各IPパケットに含まれる(たとえば、埋め込まれる、関連付けられる)ネットワークアクセストークン(DLトークン)(たとえば、DLトークン1、DLトークン2、DLトークン3、...、DLトークンN)を有する。

第1のP-GW210は、ダウンリンクIPパケットを検証し、ベアラ218およびベアラ219などの、最終的にデバイス220へのデータフローまたはベアラにマッピングするために、トラフィックフローテンプレートフィルタ処理ルール216とともにSDF/TFTテンプレート214を利用する。第2のP-GW212は、第2のIPパケットフロー208(たとえば、ネットワークアクセストークンを含むダウンリンクIPパケット)を検証し、かつ/またはベアラ224およびベアラ225などの、最終的にデバイス226へのデータフローまたはベアラにマッピングするために、暗号モジュール/回路/機能222を利用する。

SDF/TFTテンプレート214(およびトラフィックフローテンプレートフィルタ処理ルール216を含む関連するテーブル)およびテーブルルックアッププロシージャの使用を、本明細書で提示する例示的な態様で説明するようなネットワークアクセストークンの使用と、P-GWにおいて置換または拡張することによって、検証および/またはマッピングするプロセスにおいてより大きい効率が取得され得る。

ネットワークアクセストークンを使用して検証および/またはマッピングすることは、暗号モジュール/回路/機能222を使用して実施され得る。ネットワークアクセストークンは、特に、ダウンリンクデータパケットのソースを確認し、かつ/あるいはダウンリンクデータパケットをベアラ224またはベアラ225(たとえば、IP-CANベアラ)などのデータフローまたはベアラにマッピングするために使用され得る。ネットワークアクセストークンは、トラフィックネットワークポリシーに基づいてよい。トラフィックネットワークポリシーは、デバイス226に関連するアプリケーションサービスに基づいてよい。ダウンリンクデータパケットフィルタ処理を増補/拡張するための暗号モジュール/回路/機能222の使用は、ダウンリンクポリシー実施の現在のSDF/TFT方法にまさる少なくとも以下の利点をもたらし得る。

スケーラビリティ:テーブルエントリまたはテーブル状態が処理回路の高速経路(または、高速パス)上で維持される必要がない。

低レイテンシ:単一の暗号演算(たとえば、ハッシュまたは高度暗号化標準(AES:Advanced Encryption Standard)のうち、より高速に実行され適切である方)がアクセス制御にとって十分である。

フレキシビリティ:様々なメタデータに基づいてネットワークアクセストークンが構築され得る。様々なポリシー(たとえば、パケットの真正性/認可)がネットワークアクセストークンの中で適用および/または反映され得る。

分散型サービス拒否(DDoS:Distributed Denial of Service)耐性:たとえば、確認に失敗したダウンリンクトラフィックを廃棄すること(たとえば、それの含められているネットワークアクセストークンが確認に失敗したダウンリンクデータパケットを廃棄すること)による、(たとえば、ダウンリンクトラフィックがコアネットワークの中に入る前の)ネットワークの境界におけるゲートウェイデバイス(たとえば、P-GW)による無認可ダウンリンクトラフィックの効率的なフィルタ処理。

再配置可能性:鍵伝達を介して(たとえば、ネットワーク機能仮想化(NFV:Network Functions Virtualization)を使用して)SDFフィルタの再配置が行われ得る。注:フィルタ処理ルール(または、ルールのセット)は、対応する鍵へのマッピングによって定義され得る。

例示的な動作環境
図3は、本明細書で説明する態様による例示的な動作環境300を示す。そのような例示的な動作環境300では、1つまたは複数のデバイス302、304(たとえば、クライアントデバイスA、クライアントデバイスB)が、アクセスノード306(たとえば、ノードB、eノードB(eNB)、アクセスポイント(AP))とワイヤレスに通信し得る。アクセスノード306は、無線アクセスネットワーク(RAN)308(たとえば、拡張ユニバーサル地上波無線アクセスネットワーク(E-UTRAN:enhanced universal terrestrial radio access network))内に含まれてよい。当業者に知られているように、RAN308は2つ以上のアクセスノード306を含んでよい。図3は、乱雑さを低減するために1つのアクセスノード306だけを示す。

セルラー通信ネットワーク(たとえば、4G、LTE、LTE-A)の非限定的な例では、制御信号およびデータトラフィックが、RAN308とコアネットワーク(CN)310(たとえば、発展型パケットコア(EPC))との間で通信され得る。制御信号は、S1-MMEインターフェースを介して通信され得る。データトラフィックは、S1-Uインターフェースを介して通信され得る。

図3の例では、破線は制御シグナリング経路を表し、実線はデータトラフィック経路を表す。制御プレーンは、制御信号(たとえば、制御プレーンシグナリング)を運搬する。ユーザプレーンは、ユーザデータ(たとえば、ユーザプレーンメッセージ)を運搬する。

CN310は、モビリティ管理エンティティ(MME:mobility management entity)312、サービングゲートウェイデバイス(S-GW)316、ホーム加入者サーバ(HSS:home subscriber server)318、パケットデータネットワークゲートウェイデバイス(P-GW)320、ならびにポリシーおよび課金ルール機能(PCRF)332を含み得る。PCRF332は、加入プロファイルリポジトリ(SPR:subscription profile repository)334に結合され得る。PCRF332はまた、AF325、AF327、AF329、AF331などの1つまたは複数のアプリケーション機能に結合され得る。AF325、AF327、AF329、AF331などのアプリケーション機能は、1つまたは複数のアプリケーションサーバ上でホスティングされる対応するアプリケーションおよび/またはアプリケーションサービスに関連し得るかまたは含まれ得る。

P-GW320は、ユーザプレーンにおいてパケットデータネットワーク(PDN)322(たとえば、インターネット)と通信し得る。より詳細には、P-GW320は、ユーザプレーンにおいてアプリケーションサーバ324、326、328、330などのサーバと通信し得る。P-GW320とアプリケーションサーバ324、326、328、330などのアプリケーションサーバとの間の通信は、ユーザプレーンにおいてSGiインターフェースを介して導かれてよい。PCRF332は、制御プレーンにおいてAF325、AF327、AF329、AF331などのアプリケーション機能と通信し得る。PCRF332とAF325、AF327、AF329、AF331などのアプリケーション機能との間の通信は、Rxインターフェースを介して導かれてよい。アプリケーションサーバ324、326、328、330は、たとえば、販売サービス、情報サービス、ストリーミングビデオサービス、およびソーシャルメディアサービスを提供するサービスプロバイダなどの、サービスプロバイダに関連付けられてよい。アプリケーションサーバ324、326、328、330は、アプリケーションおよび/またはアプリケーションサービスをホスティングし得る。アプリケーションサーバ324、326、328、330は、AF325、AF327、AF329、AF331などの1つもしくは複数のアプリケーション機能を含んでよく、またはそれらに関連付けられてよい。

アプリケーションサーバ324、326、328、330の各々はユーザプレーン(または、データプレーン)エンティティと見なされてよく、AF325、AF327、AF329、AF331などのアプリケーション機能の各々は制御プレーン(または、シグナリングプレーン)エンティティと見なされてよい。

図4は、本明細書で説明する態様によるダウンリンク動作の一例である。例は、便宜上、ロングタームエボリューション(LTE)セルラー通信ネットワークのコンテキストで提示される。例は、本明細書で説明する任意の態様の範囲に何らかの限定を課すものではない。

デバイス402(たとえば、チップコンポーネント、クライアントデバイス、ユーザ機器、ユーザデバイス、端末、モバイルデバイス)、アクセスノード404(たとえば、eノードB)、サービングゲートウェイデバイス(S-GW)406、ゲートウェイデバイス(たとえば、P-GW)408、およびPDN410(たとえば、インターネット)が図4に表される。

図4における例示的なダウンリンク動作が次に説明される。ダウンリンクIPフロー414(たとえば、PDN410の中のアプリケーションサーバ(図示せず)からのユーザプレーンにおけるIPパケットのフロー)が、P-GW408の決定および処理モジュール/回路/機能420に適用され得る。示されるダウンリンクIPフロー414の数は例示的であり、限定的であることを意図しない。決定および処理モジュール/回路/機能420は、ダウンリンクIPフロー414から受信されたパケット(本明細書ではダウンリンクデータパケットと呼ぶ)を、暗号検証および/またはマッピングモジュール/回路/機能422に、あるいはサービスデータフロー(SDF)テンプレート424およびその中のパケットフィルタ426に通過/転送/送信/伝達/適用させ得る。

ダウンリンクデータパケットに含まれる(たとえば、埋め込まれる、関連付けられる)ネットワークアクセストークンを有するダウンリンクデータパケットは、暗号検証および/またはマッピングモジュール/回路/機能422に通過させられ得る。

一実装形態では、アプリケーション識別子(App ID)を含むネットワークアクセストークンが、ダウンリンクデータパケットに含まれてよい(たとえば、埋め込まれてよく、関連付けられてよい)。App IDは、トラフィックネットワークポリシーを決定するために使用され得る。トラフィックネットワークポリシーは、アプリケーションサーバから取り出されてよい。いくつかの態様では、アプリケーションサーバは、デバイスと通信するための要求を開始する第1のアプリケーションサーバであってよく、または通信を開始するためにデバイスがシークするのに用いる第2のアプリケーションサーバであってもよいが、第3のアプリケーションサーバも許容できる。いくつかの態様では、トラフィックネットワークポリシーは、アプリケーションサーバに関連するアプリケーション機能(AF)から取り出されてよい。他の態様では、トラフィックネットワークポリシーは、加入プロファイルリポジトリ(SPR)から取り出されてよい。

トラフィックネットワークポリシーは、たとえば、サービス品質(QoS)プロファイルまたはアクセス制御リスト(ACL:access control list)に基づいてよい。ポリシーは、たとえば、デバイスがいかなる合意にも違反しておらず、加入されたアプリケーションサービスへのアクセスが提供されており、かつ/または合意されたレベルのサービス(たとえば、QoS)が提供されていることを確実にするように、アプリケーションサービスに関して設定されてよい。そのようなポリシーは、アプリケーションサーバからデバイスに向かって送られるダウンリンクデータパケットに対してP-GWによって実施され得る。追加の例として、そのようなポリシーは、デバイスがアプリケーションサービスの事前定義されたセットからダウンリンクデータパケットを受信することを許可するルールを実施するために使用され得る。別の例として、ポリシーは、いくつかのアプリケーションサービスおよび/またはデバイスに関連するパケットに、異なる課金または処理を適用するために使用され得る。

いくつかの実装形態では、トラフィックネットワークポリシーは、たとえば、サービス優先度、最大帯域幅、保証帯域幅、および/または最大遅延を含むサービス品質(QoS)パラメータを含み得る。この情報は、ネットワークアクセストークンに関連する各ダウンリンクデータパケットを、複数のデータフローまたはベアラ418(たとえば、発展型パケットシステム(EPS)またはIP-CANベアラ)の中からの特定のデータフローまたはベアラに(たとえば、ネットワークアクセストークンを解読すること、および解読されたネットワークアクセストークンの中に含まれるデータを使用することによって)マッピングするために、暗号検証および/またはマッピングモジュール/回路/機能422によって使用され得る。

それに含まれる(たとえば、埋め込まれる、関連付けられる)ネットワークアクセストークンを有しないダウンリンクIPフロー414の中のダウンリンクデータパケットは、決定および処理モジュール/回路/機能420によってSDFテンプレート424へ送られてよい。パケットフィルタ426は、SDFテンプレート424に含まれてよい。SDFテンプレート424のパケットフィルタ426の使用は、暗号検証および/またはマッピングモジュール/回路/機能422の使用が必要とするよりも、多くの処理リソースおよびメモリリソースを必要とすることがある。SDFテンプレート424のパケットフィルタ426を使用してフィルタ処理を実行するために、P-GW408は、SDFごとに別個のテーブルエントリを有するテーブル428を維持する必要があり得る。各テーブルエントリは、限定はしないが、App ID、最大ビットレート(MBR)、およびアクセスポイント名総計最大ビットレート(APN-AMBR:access point name-aggregate maximum bit rate)などの、複数のパラメータの識別を必要とし得る。SDFテンプレート424のパケットフィルタ426は、ネットワークアクセストークンを含まない各ダウンリンクデータパケットを、複数のデータフローまたはベアラ418の中からの特定のデータフローまたはベアラに(たとえば、フィルタ処理プロセスによって)マッピングし得る。

例示のために3つのデータフローまたはベアラ418が図示される。一態様では、データフローまたはベアラは、複数のアプリケーション/アプリケーションサービスによって共有されてよい。データフローまたはベアラ418の各々は、パラメータのユニークなセットに関連付けられてよい。

ダウンリンクIPフロー414は、たとえば、デフォルトのデータフローまたはベアラに、あるいは1つもしくは複数の専用のデータフローおよび/または1つもしくは複数のベアラにマッピングされ得る。デフォルトのデータフローまたはデフォルトのベアラは、非保証型ビットレートを有してよく、専用のデータフローまたは専用のベアラは、保証型ビットレートまたは非保証型ビットレートのいずれかを有してよい。データフローまたはベアラ418は、S-GW406およびアクセスノード404(たとえば、eノードB)を通過し得る。アクセスノード404(たとえば、eノードB)およびS-GW406の態様は、本明細書で説明されないが当業者に知られている。

デバイス402に到達すると、様々なデータフローまたはベアラ418の中のダウンリンクIPフロー414は、トラフィックフローテンプレート(TFT)416に含まれるパケットフィルタ430に適用され得る。TFT416のパケットフィルタ430は、複数のデータフローまたはベアラ418からデバイス402におけるそれらのそれぞれのアプリケーション/アプリケーションサービス412へ、ダウンリンクIPフロー414をフィルタ処理するかまたは別の方法で導く。一態様では、データフローまたはベアラ418のうちの少なくとも1つが、複数のアプリケーション/アプリケーションサービス412によって共有されてよい。本明細書で示されるダウンリンクIPフロー414およびデータフローまたはベアラ418の数は例示的であり、限定的であることを意図しない。

導出される場合、接続ID(図6に関して説明する)が、P-GW408内の接続IDストレージ432(たとえば、キャッシュまたはメモリ回路)エリアの中に記憶されてよい。

ネットワークアクセストークンセットアップおよび使用、一般に-制御プレーン手法
図5は、制御プレーン(Cプレーン)を使用する、ゲートウェイデバイス(たとえば、P-GW)におけるネットワークアクセストークンのセットアップ(たとえば、サービス識別、ネットワークアクセストークン導出、ネットワークアクセストークン送信)、およびユーザプレーン(Uプレーン)におけるネットワークアクセストークンの使用を示す、例示的なフローチャート500である。ゲートウェイデバイスによって実行される動作の順序は例示的であり、限定的でない。本明細書で説明するように、すべて本明細書で説明する態様に従って、ネットワークアクセストークンは、ネットワークアクセストークンを含む(たとえば、その中に/それとともに埋め込んでいる、それに関連付けられている、その中に組み込まれている、それに追加されている)ダウンリンクデータパケットを検証および/またはマッピングするために使用されてよく、ここで、ダウンリンクデータパケットは、ゲートウェイデバイスにおいてユーザプレーントラフィックの中で受信される。

ゲートウェイデバイス(たとえば、パケットデータネットワーク(PDN)ゲートウェイデバイス(P-GW))は、デバイスに関連するトリガを検出し得る(502)。トリガは、たとえば、トリガを表すデータおよび/またはシグナリングの中にデバイス識別子またはデバイスアドレスを含めることによって、デバイスに関連付けられ得る。例示的な一実装形態では、トリガを表すデータおよび/またはシグナリングは、デバイス(たとえば、チップコンポーネント、クライアントデバイス、ユーザ機器)に関連付けられてよく、デバイスは、中間ノードを経由してゲートウェイデバイスにおいてデータおよび/またはシグナリングを受信させてよい。データおよび/またはシグナリングは、ゲートウェイデバイスにトリガを表し得る。概して、デバイスに関連するトリガを検出することによって、ゲートウェイデバイスは、ネットワークアクセストークンを取得(たとえば、導出、生成、計算、部分的に計算など)し、そのネットワークアクセストークンをPCRFへ送り得るようになる。

1つまたは複数のアプリケーションサービスは、デバイスに関連付けられてよく、またはリンクされてよい。たとえば、1つまたは複数のアプリケーションサービスがデバイスによって使用されてよく、あるいは1つまたは複数のアプリケーションサービスは、1つまたは複数のアプリケーションサービスをホスティングするアプリケーションサーバへデバイスから送られるパケットの宛先であってよい。一実装形態では、ゲートウェイデバイスは、デバイスに関連するアプリケーションサービスをトリガの検出に応答して識別し得る(504)。ゲートウェイデバイスは、アプリケーションサービスに関連するトラフィックネットワークポリシーをトリガの検出に応答して取得し得る(506)。トラフィックネットワークポリシーが1つまたは複数のアプリケーションサービスに関連付けられてよいことに留意されたい。

一実装形態では、ゲートウェイデバイスは、アプリケーションサービスに関連するトラフィックネットワークポリシーをPCRFから取得し得る。一実装形態では、ゲートウェイデバイスは、アプリケーションサービスに関連するトラフィックネットワークポリシーを加入プロファイルリポジトリ(SPR)から取得し得る。一実装形態では、たとえば、ゲートウェイデバイス(たとえば、P-GW320、図3)は、SPR(たとえば、334、図3)とのインターフェースを有するPCRF(たとえば、332、図3)からトラフィックネットワークポリシーを取得し得る。

ゲートウェイデバイスは、ネットワークアクセストークンをトリガの検出に応答して取得し得る(508)。ネットワークアクセストークンは、トラフィックネットワークポリシーに基づいてよい(たとえば、それにリンクされてよく、それの機能であってよく、それを含んでよく、またはそれから導出されてよい)。トラフィックネットワークポリシーは、たとえば、(1)モバイルネットワークオペレータ(MNO:mobile network operator)とアプリケーションサービスプロバイダ(ASP:application service provider)との間のサービスレベル合意に基づいて、または(2)デバイスの加入プロファイルに基づいてのいずれかで、あるいはそれらの任意の組合せで規定されてよい。

いくつかの例示的な実装形態では、トラフィックネットワークポリシーに基づくネットワークアクセストークンを取得することは、そのトラフィックにとってデバイス固有でないネットワークのポリシーの実施を容易にし得る。たとえば、モバイルネットワークオペレータ(MNO)は、加入が必要でなくてよいすべてのデバイス(たとえば、UE)に1つまたは複数のサービスを提供するための、アプリケーションサービスプロバイダ(ASP)との合意を有することがある。

いくつかの実装形態では、デバイスの加入プロファイルは、ネットワークアクセストークンがデバイスに関して取得されることを許可されるかどうかを示すフィールドを含み得る。したがって、オプションとして、ゲートウェイデバイスは、本明細書で説明する態様に従って、デバイスの加入プロファイルを取得してよく(503)、加入プロファイルは、デバイスに向けられたダウンリンクデータパケットの検証および/またはマッピングに関してネットワークアクセストークンの使用が許可されているかどうかを識別する。

ネットワークアクセストークンは、デバイスに向けられているユーザプレーントラフィック(たとえば、ユーザプレーンデータトラフィック)の中でゲートウェイデバイスにおいて取得されたダウンリンクデータパケットの検証および/またはマッピングを容易にし得る。いくつかの実装形態では、ネットワークアクセストークンを取得することは、ゲートウェイデバイスにおいてユーザプレーントラフィックの中で受信されるべきダウンリンクデータパケットを検証および/またはマッピングするプロセスの一部であってよい。ネットワークアクセストークンは、デバイスおよび/または1つもしくは複数のアプリケーションサービス(たとえば、デバイスに関連するアプリケーションサービス、デバイスが相互作用するアプリケーションサービス、デバイスに関連するものとしてゲートウェイデバイスによって識別されるアプリケーションサービス)にリンクされてよい。

ゲートウェイデバイスは、制御プレーンシグナリングの中でネットワークアクセストークンをエンティティ(たとえば、デバイス、サーバ、ポリシーおよび課金ルール機能(PCRF)、アプリケーション機能(AF)、ノード)へ送り得る(510)。いくつかの実装形態では、エンティティはポリシーおよび課金ルール機能(PCRF)であってよい。一態様によれば、ゲートウェイデバイスは、Gx参照点などのインターフェースを介して制御プレーンシグナリングの中でネットワークアクセストークンをPCRFへ送り得る。いくつかの実装形態では、ゲートウェイデバイスにおいてユーザプレーントラフィックの中でダウンリンクデータパケット(ネットワークアクセストークンを含む)を取得する前に、ネットワークアクセストークンは、ゲートウェイデバイスにおいて制御プレーンシグナリングの中で取得されるとともにエンティティへ送られてよい。

エンティティ(たとえば、PCRF)は、制御プレーンシグナリングの中でネットワークアクセストークンをアプリケーション機能(AF)へ送り得る(512)。一態様によれば、PCRFは、Rx参照点などのインターフェースを介してAFへネットワークアクセストークンを送り得る。

PCRFからRx参照点を介してアプリケーション機能においてネットワークアクセストークンを取得することは、既存のインターフェースを有益に再使用し得る。言い換えれば、本明細書で説明するいくつかの態様によれば、本明細書で説明する方法を実施するために新たな参照点が必要とされない。ただし、本明細書では、アプリケーション機能を、Rxインターフェースを介してのみネットワークアクセストークンを取得することに何ら限定しない。アプリケーション機能は、任意のインターフェースを通じてネットワークアクセストークンを取得してよい。

アプリケーション機能(AF)は、アプリケーションサーバ上の制御プレーンエンティティであってよく、またはアプリケーションサーバに関連付けられてよい。AFは、デバイスへ送られるダウンリンクデータパケットにネットワークアクセストークンを含める(たとえば、埋め込む、関連付ける、組み込む、追加する)ようにアプリケーションサーバを構成し得る。

アプリケーションサーバは、ダウンリンクデータパケットを作成することを担当するユーザプレーンエンティティであってよい。一実装形態では、アプリケーションサーバは、アプリケーション機能からネットワークアクセストークンを取得し得る(514)。アプリケーションサーバは、デバイスに向けた(たとえば、デバイスに導かれる、デバイスに向かう、デバイスへ行く、デバイスに配信されることが意図される、ダウンリンクデータパケットの宛先アドレスがデバイスのアドレスに相当する)ダウンリンクデータパケットを作成(たとえば、構築、コンパイル、形成、アセンブル)し得る(516)。アプリケーションサーバは、(デバイスにリンクされている)ネットワークアクセストークンをダウンリンクデータパケットに含め得る(518)。アプリケーションサーバは、ネットワークアクセストークンを含むダウンリンクデータパケットを、ゲートウェイデバイス(たとえば、P-GW)を経由してユーザプレーントラフィックの中でデバイスへ送り得る(520)。

ダウンリンクデータパケットは、アプリケーションサーバからコアネットワークのゲートウェイデバイス(たとえば、P-GW)を経由してユーザプレーンデータ送信の中でデバイスへ送られてよい。ユーザプレーンデータ送信は、ネットワークアクセストークンを含む1つまたは複数のダウンリンクデータパケットを備え得る。

ゲートウェイデバイス(たとえば、P-GW)は、ネットワークアクセストークンを含むダウンリンクデータパケットを取得し得る。ゲートウェイデバイスは、(たとえば、ネットワークアクセストークンを含んでいたダウンリンクデータパケットを検証するために)ネットワークアクセストークンを確認すること、および/またはネットワークアクセストークンから取得されたデータを使用してダウンリンクデータパケットをデバイスにマッピングすることを含む、1つまたは複数のプロセスを実行し得る(522)。ゲートウェイデバイスは、ネットワークアクセストークンをダウンリンクデータパケットから除去(たとえば、抽出)し得る(524)。ネットワークアクセストークンを除去することは、ネットワークアクセストークンを確認する前または確認した後に行われてよい。後に行われる場合、かつ確認が失敗した場合、さらなる処理(たとえば、ネットワークアクセストークン除去)は必要でない。ゲートウェイデバイスは、マッピングに従って(たとえば、ネットワークアクセストークンなしの)ダウンリンクデータパケットをデバイスへ送り得る(526)。

図6は、本明細書で説明する態様による、制御プレーンにおけるネットワークアクセストークン(代替として、本明細書および図6では「DLトークン」と呼ぶ)のセットアップ(たとえば、サービス識別、ネットワークアクセストークン導出、ネットワークアクセストークン送信)の一例を示す例示的な制御プレーンコールフロー図600である。図示した例示的なネットワークアクセストークンセットアップは、デバイス/アクセスノードアグノスティックである。言い換えれば、ゲートウェイデバイス610(たとえば、パケットデータネットワークゲートウェイデバイス(P-GW))の観点から、制御プレーントラフィックの中でのネットワークアクセストークンのセットアップ(たとえば、サービス識別、トークン導出、トークン送信)は、ゲートウェイデバイス610においてユーザプレーントラフィックの中で受信されるべきダウンリンクデータパケットを検証および/またはマッピングするプロセスにおいてネットワークアクセストークンが使用されるべきである場合、セットアップがデバイスのアクション(たとえば、初期接続プロシージャアクション)に起因するのか、それともアクセスノードのアクション(たとえば、ハンドオーバアクション)に起因するのかに依存しない。本明細書で説明する態様によれば、ネットワークアクセストークンセットアップは、初期PDN接続性要求プロシージャに、ならびに後続することがある任意の専用のデータフローまたはベアラセットアップ/活動化/変更プロシージャに、等しく良好に適用され得る。

図6は、デバイス602(たとえば、チップコンポーネント、クライアントデバイス、ユーザ機器)、アクセスノード604(たとえば、eノードB)、モビリティ管理エンティティ(MME)606、サービングゲートウェイデバイス(S-GW)608、ゲートウェイデバイス610(たとえば、パケットデータネットワークゲートウェイデバイス(P-GW))、ポリシーおよび課金ルール機能(PCRF)612、ならびにアプリケーション機能(AF)614の表示を含む。AF614は、制御プレーン上のエンティティであってよく、PCRF612へのインターフェースに関連する制御を働かせ得る。

概して、図6の実装形態では、トリガ(たとえば、反応または一連の反応を開始または促進する行為または事象、所定の行為、所定の事象などの任意のもの)を検出することによって、アプリケーションサービスに関連するトラフィックネットワークポリシーを取得すること、トラフィックネットワークポリシーに基づくネットワークアクセストークンを取得すること、および/または制御プレーンシグナリングの中でネットワークアクセストークンをエンティティへ送ることのうちの1つまたは複数を、ゲートウェイデバイス610(たとえば、P-GW)が実行し得るようになる。言い換えれば、アプリケーションサービスに関連するトラフィックネットワークポリシーを取得すること、トラフィックネットワークポリシーに基づくネットワークアクセストークンを取得すること、および/または制御プレーンシグナリングの中でネットワークアクセストークンをエンティティへ送ることのうちの任意の1つまたは複数は、トリガの検出に応答してよい。

図6の実装形態では、たとえば、ゲートウェイデバイス610(たとえば、P-GW)において「セッション作成要求」(ここで、「セッション作成要求」は制御プレーンメッセージである)を取得すること(624)(たとえば、受信すること)は、ゲートウェイデバイス610へのトリガとして働き得る。他のトリガが許容でき、考えられる。

図6は、トリガを実施する制御プレーンコールフローを示し、ここで、トリガは、ベアラを確立することに関係する(たとえば、図6のトリガは、ゲートウェイデバイス610においてセッション作成要求を取得することを含んでよい)。例示的な制御プレーンコールフロー図600は、たとえば、4G、LTE、LTE-Aセルラー通信ネットワークにおいて使用されるようなベアラに関して説明されるが、本明細書では、本明細書で説明する態様を、ベアラを使用するセルラー通信ネットワークに何ら限定しない。本明細書で説明するすべての態様は、たとえば、4G、LTE、LTE-Aセルラー通信ネットワークにおいて使用されるようなベアラと比較して、より一般的に説明される「データフロー」を実施する通信ネットワークにも適用されることが、当業者によって理解されよう。

次に図6の例示的な制御プレーンコールフロー図600を参照すると、デバイス(たとえば、チップコンポーネント、クライアントデバイス、ユーザ機器)は、PDN接続性要求をMME606へ送り得る(620)。MME606は、PDN接続性要求に応答して(in response to)(たとえば、応答して(responsive to))、セッション作成要求をS-GW608へ送り得る(622)。S-GW608は、セッション作成要求をゲートウェイデバイス610へ送り得る(ここで、ゲートウェイデバイス610は、今度はセッション作成要求を取得している(624)(たとえば、受信しているなど))。これらおよび/または他の制御プレーンメッセージは、トリガと見なされてよい。ゲートウェイデバイス610は、トリガを検出し得る(625)。トリガの検出(たとえば、ゲートウェイデバイスにおいてセッション作成要求を取得すること(624))は、アプリケーションサービスに関連するトラフィックネットワークポリシーを取得すること(626)、トラフィックネットワークポリシーに基づくネットワークアクセストークンを取得すること(628)、および/または制御プレーンシグナリングの中でネットワークアクセストークンをエンティティへ送ること(636)のうちの1つまたは複数を、ゲートウェイデバイス610に実行させ得る。

例として、ゲートウェイデバイス610(たとえば、P-GW)は、アプリケーションサービス用のトラフィックネットワークポリシーをPCRF612から取得し得る(626)。トラフィックネットワークポリシーは、デバイス固有またはアプリケーション固有であってよい。前者の場合、トラフィックネットワークポリシーは、(PCRFが加入プロファイルリポジトリ(SPR)から取得し得る)加入プロファイルに基づいて決定され得る。後者の場合、アプリケーションサービスプロバイダ(ASP)が、すべてのデバイスに適用され得るアプリケーショントラフィック上のトラフィックネットワークポリシーを、モバイルネットワークオペレータ(MNO)に提供/交渉し得、そうしたトラフィックネットワークポリシーは、PCRFにおいて記憶され得る。

例として、ゲートウェイデバイス610は、トラフィックネットワークポリシーに基づくネットワークアクセストークン(DLトークン)を取得し得る(628)。たとえば、トラフィックネットワークポリシーは、特に、DLトークン導出のために使用されるフィールドを規定し得るかまたはDLトークンを導出するために使用される入力パラメータのリストを規定し得る、鍵パラメータインデックス(KPI)を含み得る。トラフィックネットワークポリシーは、特に、フロー処理ポリシー(たとえば、当業者によって理解されるような、データフローまたはベアラ、およびフロー処理ポリシーの他の側面に、フローをマッピングするQoSポリシー)を規定し得るポリシー識別子(ポリシーID)を含み得る。

限定ではなく例として、ネットワークアクセストークン(DLトークン)は、以下のように与えられてよい。
DLトークン=KeyID|KPI|ポリシーID|H(K_P-GW,ポリシーID|IP_S|IP_C|P_S|P_C|Proto|App ID|...)
ただし、KeyIDは、DLトークンを取得(たとえば、導出、生成、計算など)するために使用される鍵(たとえば、K_P-GW)の識別子であり、KPIは、DLトークン導出のために使用されるフィールドを規定し得るかまたはDLトークンを導出するために使用される入力パラメータのリストを規定する、鍵パラメータインデックスであり、ポリシーIDは、フロー処理ポリシー(たとえば、当業者によって理解されるような、データフローまたはベアラ、およびフロー処理ポリシーの他の側面に、フローをマッピングするQoSポリシー)を規定し得るポリシー識別子であり、Hはセキュアハッシュ関数であり(代替として、たとえば、ハッシュメッセージ認証コード(HMAC:hash message authentication code)が使用され得る)、K_P-GWはゲートウェイデバイス610(たとえば、P-GW)の秘密鍵であり、IP_Sはサーバ(たとえば、アプリケーションサーバ)IPアドレスであり、IP_Cはクライアント(たとえば、チップコンポーネント、クライアントデバイス、ユーザ機器)IPアドレスであり、P_Sはサーバポート番号であり、P_Cはクライアントポート番号であり、Protoはプロトコル番号またはプロトコル識別子であり、App IDはアプリケーション識別子である。

KeyIDは、ゲートウェイデバイス610(たとえば、P-GW)によって割り当てられ得る。DLトークンが、ゲートウェイデバイス610だけに知られている秘密鍵(たとえば、KP-GW)に基づいて、ゲートウェイデバイス610によって生成されることに留意されたい。したがって、KeyIDはまた、DLトークンの一部として、ゲートウェイデバイス610によって割り当てられる。秘密鍵(たとえば、KP-GW)は、ゲートウェイデバイス610(たとえば、P-GW)において記憶される。

サーバおよびクライアントデバイスのIPアドレスおよびポート番号、プロトコル番号またはプロトコル識別子、ならびにApp IDは、ゲートウェイデバイス610において検出されるべきターゲットを備えるパケットの中に含まれ得る。

ネットワークアクセストークン(DLトークン)の中に含まれ得るポリシーIDは、(DLトークンを含む)ダウンリンクデータパケットを所与のデータフローまたはベアラにマッピングするために使用され得る。代替として、ポリシーIDに代わってKeyIDを使用することが可能であり得、その場合、DLトークンの導出(たとえば、計算)においてポリシーID値は使用してはならない。追加または代替のパラメータは、優先度および/またはサービス品質クラス識別子(QCI)を含み得る。DLトークンの導出のための他の式が許容できる場合がある。当業者に知られているように、上記で説明した例示的なパラメータの間の縦線は、連結関数を示す。

随意に、ゲートウェイデバイス610(たとえば、P-GW)は、接続識別子(接続ID)を取得し得る(630)。接続IDは、デバイス開始型接続(たとえば、チップコンポーネント/クライアントデバイス/UE開始型接続)を識別するために使用され得る。一態様では、限定ではなく例として、接続IDは、以下のように与えられてよい。
接続ID=KeyID|KPI|HMAC(K'_P-GW,IP_S|IP_C|P_S|P_C|Proto)
ただし、K'_P-GWは、DLトークンを導出するために使用される秘密鍵K_P-GWとは異なる、P-GWに知られている秘密鍵であってよい。

随意に、導出される場合、接続IDは、ゲートウェイデバイス610のキャッシュまたはメモリ/記憶デバイスにおける接続ID記憶ロケーションの中に記憶され得る(632)。

ゲートウェイデバイス610(たとえば、P-GW)はまた、IP-CANセッション確立/変更を実行し得る(634)。

ゲートウェイデバイス610は、ネットワークアクセストークン(DLトークン)をPCRF612へ送り得る(636)。ゲートウェイデバイス610は、制御プレーンシグナリングの中でネットワークアクセストークンをPCRF612へ送り得る(636)。

いくつかの実装形態では、ゲートウェイデバイス610(たとえば、P-GW)は、メッセージの中でPCRF612へネットワークアクセストークンを送り得る(636)。いくつかの実装形態では、メッセージは、ネットワークアクセストークンプロビジョニングメッセージと呼ばれることがある(また、図6ではDLトークンプロビジョニングメッセージと呼ばれることもある)。アクセス許可メッセージは、ネットワークアクセストークンプロビジョニングメッセージの一例であってよい。図6はアクセス許可メッセージへの参照を含むが、参照は例示的であり、限定的でない。

ネットワークアクセストークンプロビジョニングメッセージは、アプリケーションサービス/アプリケーションサーバがアクセス(たとえば、アプリケーションサーバの観点からのセルラーネットワークへの進入点がゲートウェイデバイス610(たとえば、P-GW)である、データをデバイスへ送るためのセルラーネットワークアクセス)を要求しないときに適切であり得るが、代わりに、アクセスは、たとえば、セルラーネットワークのポリシーに基づく。随意に、ゲートウェイデバイス610は、DLトークンとともにアプリケーション識別子(App ID)を送ってよい(636)。たとえば、ダウンリンクトークンプロビジョニングメッセージは、アプリケーション識別子(App ID)を随意に含んでよい。App IDは、アプリケーションサーバ(または、その上でホスティングされるアプリケーションサービス)を識別するために使用され得る。App IDはまた、トラフィックネットワークポリシーを識別するために使用され得る。

PCRF612は、ネットワークアクセストークン(DLトークン)をアプリケーション機能(AF)614へ送り得る(638)。PCRF612は、制御プレーンシグナリングの中でDLトークンをAF614へ送り得る(638)。PCRF612は、DLトークンプロビジョニングメッセージ(たとえば、制御プレーンにおけるアクセス許可メッセージ)の中でAF614へDLトークンを送り得る(638)。

追加として、ゲートウェイデバイス610(たとえば、P-GW)は、セッション作成応答をS-GW608へ送り得る(640)。S-GW608は、セッション作成応答をMME606へ送り得る(642)。セッション作成応答に応答して、MME606は、ベアラセットアップ要求/PDN接続性受付(または、データフローセットアップ要求/PDN接続性受付)をアクセスノード604(たとえば、eノードB)へ送り得る(644)。アクセスノード604は、次いで、無線リソース制御(RRC)接続再構成メッセージをデバイス602へ送り得る(646)。図6の例示的な制御プレーンコールフロー図600におけるデバイス602、アクセスノード604、MME606、S-GW608、ゲートウェイデバイス610(たとえば、P-GW)、PCRF612、およびAF614の間の通信は、制御プレーン(Cプレーン)の中で行われてよい。

図7は、本明細書で説明する態様による、ユーザプレーンにおけるネットワークアクセストークン(代替として、本明細書および図7では「DLトークン」と呼ぶ)の使用の一例を示す例示的なユーザプレーンコールフロー図700である。図7に示すコールフローは、図6に示すコールフローによって先行されてよい。言い換えれば、図6のコールフローでは、ネットワークアクセストークン(DLトークン)は、制御プレーンにおいてアプリケーション機能(たとえば、AF614、図6)へ送られてよく、アプリケーションサーバ(たとえば、714、図7)は、アプリケーション機能(たとえば、AF614、図6)に関連してよく、アプリケーション機能(たとえば、AF614、図6)からネットワークアクセストークン(DLトークン)を取得し得るが、図7のコールフローでは、アプリケーションサーバ714は、ダウンリンクデータパケットを作成し、ダウンリンクデータパケットにDLトークンを含め、DLトークンを含むダウンリンクデータパケットを、ユーザプレーントラフィックの中でゲートウェイデバイス710へ送る。

図7は、デバイス702(たとえば、チップコンポーネント、クライアントデバイス、ユーザ機器)、アクセスノード704(たとえば、eノードB)、サービングゲートウェイデバイス(S-GW)708、ゲートウェイデバイス710(たとえば、パケットデータネットワークゲートウェイデバイス(P-GW))、およびアプリケーションサーバ714の表示を含む。

アプリケーションサーバ714は、ユーザプレーン上のエンティティであってよい。アプリケーションサーバ714は、たとえば、ダウンリンクデータパケットの作成およびユーザプレーンを介したダウンリンクデータパケット送信を含む機能を実施し得る。デバイス702へのダウンリンクデータパケット送信は、ゲートウェイデバイス710(たとえば、P-GW)を経由してよい。

アプリケーションサーバ714は、アプリケーション機能(たとえば、AF614、図6)からネットワークアクセストークンを取得し得る。ネットワークアクセストークンは、所与のデバイスおよび/またはアプリケーションサービスにリンクされてよい。アプリケーションサーバ714は、(たとえば、所与のデバイス702に配信されるように向けられた)所与のデバイス702のためのダウンリンクデータパケットを作成(たとえば、構築、コンパイル、形成、アセンブル)し得、追加として、アプリケーションサーバ714は、ダウンリンクデータパケットにDLトークンを含めてよい(たとえば、埋め込んでよく、関連付けてよく、組み込んでよく、追加してよい)(716)。DLトークンを含むダウンリンクデータパケットは、ゲートウェイデバイス710(たとえば、P-GW)を経由してユーザプレーントラフィックの中でデバイス702へ送られ得る(718)。

ゲートウェイデバイス710(たとえば、P-GW)は、たとえば、ポリシーおよび課金実施機能(PCEF:policy and charging enforcement function)を介して、または決定および処理モジュール/回路/機能(420、図4)を介して、ユーザプレーントラフィックの中で受信されたダウンリンクデータパケットを評価し得る。評価は、ネットワークアクセストークンを含むダウンリンクデータパケットを識別するために行われてよい。

ネットワークアクセストークンを含むダウンリンクデータパケットは、ネットワークアクセストークンに基づいて検証および/またはマッピングされ得る(720)。ゲートウェイデバイス710は、ネットワークアクセストークン(DLトークン)をダウンリンクデータパケットから随意に除去してよい(722)。ネットワークアクセストークンを除去することは、ダウンリンクデータパケットの検証の前または後に実行されてよい。

一態様では、ダウンリンクデータパケットは、ダウンリンクデータパケットに含まれるネットワークアクセストークン(DLトークン)を確認することによって検証され得る。検証が肯定的である場合、ダウンリンクデータパケットは、DLトークンから取得されたデータを使用してデバイスにマッピングされてよい。検証を伴うかまたは伴わずに、ダウンリンクデータパケットは、ネットワークアクセストークンから取得されたデータを使用してデバイス702にマッピングされてよい。ゲートウェイデバイス710は、次いで、マッピングに適切な(たとえば、ネットワークアクセストークンから取得されたデータの中で識別される要件に適切な)データフローまたはベアラを介してデバイス702へダウンリンクデータパケットを送り得る(724)。図7の実装形態に示すように、ゲートウェイデバイス710は、ネットワークアクセストークンなしでダウンリンクデータパケットをデバイス702へ送り得る(724)。

図7の例示的なユーザプレーンコールフロー図700におけるアプリケーションサーバ714、ゲートウェイデバイス710、S-GW708、アクセスノード704、およびデバイス702の間の通信は、ユーザプレーン(Uプレーン)の中で行われてよい。

本明細書で説明する態様は、現在の3GPP規格において規定されるような「ベアラ」の使用に限定されない。(たとえば、ゲートウェイデバイス710(たとえば、P-GW)およびS-GW708を含む)コアネットワークならびに/またはコアネットワークおよびRAN(たとえば、アクセスノード704)を通じた、ベアラまたはデータフローが、ネットワークによってデバイスのために確立され得る。したがって、RRC接続が確立されるとデータフローが確立されること、およびアイドルモード中、ゲートウェイデバイス710とS-GW708との間のデータフローが維持されることが可能であり得る。RRC接続が確立されていなくても、アプリケーションサーバ714が、所与のデバイス702に向けられたダウンリンクデータパケットの中のネットワークアクセストークンのコピーを送ってよいことにも留意されたい。

例示的なプロトコルスタック
ネットワークアクセストークンの使用が、デバイス、アクセスノード、ゲートウェイデバイス、およびアプリケーションサーバのプロトコルスタックの間でのネットワークアクセストークンの移動に関して説明され得る。ユーザプレーンプロトコルスタックの2つの例示的なセットが本明細書で説明される。プロトコルスタックにおいて表されるレイヤのうちのいくつか、およびレイヤ間の相互接続部が、図8の例に関して手短に説明される。繰り返しを避け適用例の簡潔性を改善するために、それらの説明は図8の説明に関して繰り返されない。図8は、ネットワークアクセストークンの移動のために利用されるレイヤと見なされてよいシムレイヤ(shim layer)822を含む。図8は、ネットワークアクセストークンの移動のためにIPレイヤを利用する。

図8は、本明細書で説明する態様による第1のユーザプレーンプロトコルスタック800の例示的な図である。図8のユーザプレーンプロトコルスタックでは、トークン埋込みのためにシムレイヤ822が実装される。図8は、デバイス802(たとえば、チップコンポーネント、クライアントデバイス、ユーザ機器)、アクセスノード804(たとえば、eノードB)、ゲートウェイデバイス806(たとえば、P-GW)、およびアプリケーションサーバ808を示す。図8の例示的な図において、デバイス802のプロトコルスタックは、最も低いレイヤから上に向かって、物理(PHY)レイヤ810、媒体アクセス制御(MAC)レイヤ812、無線リンク制御(RLC)レイヤ814、パケットデータコンバージェンスプロトコル(PDCP)レイヤ816、およびIPレイヤ818を含み得る。

一態様では、シムレイヤ822は、ゲートウェイデバイス806およびアプリケーションサーバ808のプロトコルスタックの中に実装され得る。シムレイヤ822は、本明細書で説明する態様に従って、ゲートウェイデバイス806とアプリケーションサーバ808との間でのネットワークアクセストークンの移動を容易にし得る。一態様では、ゲートウェイデバイス806のシムレイヤ822は、ゲートウェイデバイス806のIPレイヤ824の上にあり、アプリケーションサーバ808のシムレイヤ823は、アプリケーションサーバ808のIPレイヤ858の上にある。図8に示すように、ネットワークアクセストークン860は、アクセスノード804および/もしくはデバイス802へまたはそれらを通じてネットワークアクセストークンをトランスポートする必要なしに、アプリケーションサーバ808とゲートウェイデバイス806との間でトランスポートされ得る。

図8によって示される態様は、アプリケーションサーバ808からゲートウェイデバイス806へのネットワークアクセストークン860の移動にとって有用であり得る。例として、実施動作中(トークンセットアップおよび送信動作とは対照的に)、ゲートウェイデバイス806は、アプリケーションサーバ808からシムレイヤ822を経由してユーザプレーントラフィックの中でネットワークアクセストークン860を受信し得る。ネットワークアクセストークン860の使用の一態様によれば、アプリケーションサーバ808は、デバイス802に向けられたパケットの中の所与のネットワークアクセストークンのコピーを含み得る。シムレイヤ822のシムヘッダは、図8に示すように、ネットワークアクセストークン860をゲートウェイデバイス806まで運び得る。

一実装形態では、ゲートウェイデバイス806におけるネットワークアクセストークン860の確認が成功した場合、ゲートウェイデバイス806は、ネットワークアクセストークンから取得されたデータを使用してダウンリンクデータパケットをデバイス802にマッピングしてよく送ってよい。ゲートウェイデバイス806におけるネットワークアクセストークン860の確認が成功しなかった場合、ゲートウェイデバイス806は、ダウンリンクデータパケットおよびネットワークアクセストークン860を廃棄してよい。ゲートウェイデバイス806は、ネットワークアクセストークン860を含んでいたダウンリンクデータパケットをデバイス802へ送る前に、ネットワークアクセストークン860を廃棄してよくまたは廃棄しなくてもよい。いくつかの態様によれば、ダウンリンクデータパケットをデバイスへ送る前にネットワークアクセストークンを廃棄することは、ダウンリンクデータパケットパスが通過するデバイスもアクセスノード(たとえば、eノードB)もネットワークアクセストークンを採用しないという点で、送信帯域幅および送信時間を節約する。

デバイス802、ゲートウェイデバイス806、およびアプリケーションサーバ808のプロトコルスタックのレイヤが、次に手短に説明される。図8の例示的な図において、アクセスノード804のプロトコルスタックは、最も低いレイヤから上に向かって、物理(PHY)レイヤ830、媒体アクセス制御(MAC)レイヤ832、無線リンク制御(RLC)レイヤ834、およびパケットデータコンバージェンスプロトコル(PDCP)レイヤ836を含み得、それらは、それぞれ、デバイス802の同様に称されるレイヤ(810、812、814、および816)と一緒に加わっている。図8の例示的な図において、アクセスノード804のプロトコルスタックは、追加として、最も低いレイヤから上に向かって、イーサネット（登録商標）レイヤ840、MACレイヤ842、IPレイヤ844、ユーザデータグラムプロトコル(UDP)レイヤ846、および汎用パケット無線サービス(GPRS:general packet radio service)トンネリングプロトコル(GTP)-ユーザデータ(GTP-U)レイヤ848を含み得る(ここで、GTP-Uは、GPRSコアネットワーク内および無線アクセスネットワーク(たとえば、RANのアクセスノード804)とコアネットワーク(たとえば、図8の例では、コアネットワークのゲートウェイデバイス806)との間でユーザデータを運ぶために使用される)。イーサネット（登録商標）レイヤ840、MACレイヤ842、IPレイヤ844、UDPレイヤ846、およびGTP-Uレイヤ848は、それぞれ、ゲートウェイデバイス806の同様に称されるレイヤ(750、852、854、856、および826)と一緒に加わっている。図8の例示的な図において、デバイス802のIPレイヤ818は、ゲートウェイデバイス806のIPレイヤ824に結合し、ゲートウェイデバイス806のIPレイヤ824は、アプリケーションサーバ808のIPレイヤ858に結合する。

図9は、本明細書で説明する態様による第2のユーザプレーンプロトコルスタック900の例示的な図である。図9のユーザプレーンプロトコルスタックは、ネットワークアクセストークン埋込みのためにIPヘッダを利用する。図9は、デバイス902(たとえば、チップコンポーネント、クライアントデバイス)、アクセスノード904(たとえば、eノードB)、ゲートウェイデバイス906(たとえば、P-GW)、およびアプリケーションサーバ908を示す。図9の例示的な図において、デバイス902のプロトコルスタックは、最も低いレイヤから上に向かって、物理(PHY)レイヤ910、媒体アクセス制御(MAC)レイヤ912、無線リンク制御(RLC)レイヤ914、パケットデータコンバージェンスプロトコル(PDCP)レイヤ916、およびインターネットプロトコル(IP)レイヤ918を含み得る。

一態様では、IPレイヤ918のヘッダは、本明細書で説明する態様に従って、ゲートウェイデバイス906とアプリケーションサーバ908との間でのネットワークアクセストークン(本明細書および図9ではDLトークンと呼ぶ)960の移動を容易にし得る。インターネットプロトコル(IP)バージョン4(IPv4)およびインターネットプロトコル(IP)バージョン(IPv6)は、両方とも本明細書で説明する態様を採用し得る。

図9によって示される態様は、アプリケーションサーバ908からゲートウェイデバイス906へのDLトークン960の移動にとって有用であり得る。例として、実施動作中、ゲートウェイデバイス906は、ユーザプレーントラフィックの中でアプリケーションサーバ908からDLトークン960を受信し得る。DLトークンの使用の一態様によれば、アプリケーションサーバ908は、デバイス902に向けられたダウンリンクデータパケットの中の所与のDLトークンのコピーを含み得る。IPレイヤ923の中のIPヘッダは、図9に示すように、(ダウンリンクデータパケットの中に埋め込まれている)DLトークン960をゲートウェイデバイス906まで運び得る。

一実装形態では、ゲートウェイデバイス906におけるDLトークン960の確認が成功した場合、ゲートウェイデバイス906は、DLトークンから取得されたデータを使用してダウンリンクデータパケットをデバイス902にマッピングしてよく送ってよい。ゲートウェイデバイス906におけるDLトークン960の確認が成功しなかった場合、ゲートウェイデバイス906は、ダウンリンクデータパケットおよびDLトークン960を廃棄してよい。ゲートウェイデバイス906は、DLトークン960を含んでいたダウンリンクデータパケットをデバイス902へ送る前に、DLトークン960を廃棄してよくまたは廃棄しなくてもよい。

図9に関して説明されたデバイス902、アクセスノード904、ゲートウェイデバイス906、およびアプリケーションサーバ908のプロトコルスタックのレイヤは、それらの説明が図7において同様に称されるレイヤの説明と同じまたは類似であるので説明されない。

DLトークンを含むダウンリンクデータパケットの配信に関して、一態様では、DLトークンは、IPバージョン4(IPv4)ヘッダまたはIPバージョン6(IPv6)ヘッダなどのIPヘッダの中に埋め込まれてよい。IPv4におけるIPヘッダは、IPv4オプションフィールドであってよい。IPオプションフィールドに関して、例示的なIPv4オプションフィールドの使用のために、インターネットエンジニアリングタスクフォース(IETF)において新たなオプション番号が規定されてよい。IPv6におけるIPヘッダは、IP拡張ヘッダであってよい。IP拡張ヘッダに関して、例示的なIPv6拡張ヘッダの使用のために、インターネットエンジニアリングタスクフォース(IETF)においてネクストヘッダコードなどのコードが規定されてよい。一態様では、DLトークン960は、伝送制御プロトコル(TCP)ヘッダの中に埋め込まれてよい。DLトークン960は、TCPヘッダのオプションフィールドの中に埋め込まれてよい。一態様では、DLトークン960は、セキュアソケットレイヤ(SSL)ヘッダの中に埋め込まれてよい。一態様では、DLトークン960は、トランスポートレイヤセキュリティ(TLS)レコードヘッダの中に埋め込まれてよい。TLSレコードに関して、例示的なTLSレコードプロトコルのために、インターネットエンジニアリングタスクフォース(IETF)において新たなレコード型が規定されてよい。一態様では、DLトークン960は、IPヘッダと伝送制御プロトコル/ユーザデータグラムプロトコル(TCP/UDP)ヘッダとの間のシムヘッダの中に埋め込まれてよい(図示せず)。また別の態様では、DLトークン960は、ハイパーテキスト転送プロトコル(HTTP)ヘッダの中に埋め込まれてよい(図示せず)。HTTPヘッダは、HTTP実験(eXperimental)または拡張(eXtension)ヘッダであってよい。HTTP実験または拡張ヘッダは、非セキュアHTTP接続に対してXタグ(X-tag)を利用し得る。

例示的なゲートウェイデバイス
図10は、本明細書で説明する態様による、ネットワークアクセストークンを含むダウンリンクデータパケットの検証および/またはマッピングをサポートするように適合された例示的なゲートウェイデバイス1000を示すブロック図である。一例では、例示的なゲートウェイデバイス1000は、ネットワーク通信回路1002、ネットワーク通信回路1002に結合された処理回路1004、および処理回路1004に結合されたメモリ/記憶デバイス1006を含み得る。この列挙は非限定的である。これらの回路および/もしくはデバイスまたはそれらの任意の組合せは、検出する、識別する、送る、作成する、かつ/またはマッピングするアクションを実行し得る。したがって、これらの回路および/もしくはデバイスまたはそれらの任意の組合せは、検出するための手段、識別するための手段、送るための手段、作成するための手段、および/またはマッピングするための手段の非限定的な例と見なされてよい。

ネットワーク通信回路1002は、たとえば、アプリケーションサーバおよび通信ネットワークと通信するように適合され得る。ネットワーク通信回路1002は、サービングゲートウェイデバイスとの通信用の第1の入力/出力モジュール/回路/機能1008、およびパケットデータネットワークとの通信用の第2の入力/出力モジュール/回路/機能1010を含み得る。いくつかの実装形態では、第1の入力/出力モジュール/回路/機能1008および第2の入力/出力モジュール/回路/機能1010は、同じ入力/出力モジュール/回路/機能であってよい。第1の入力/出力モジュール/回路/機能1008は、複数のベアラまたはデータフロー上に確立された複数のIPフローを処理し得る。第2の入力/出力モジュール/回路/機能1010は、パケットデータネットワーク上で複数のサーバとともに複数のIPフローを処理し得る。この列挙は非限定的である。同じまたは他の入力/出力モジュール/回路/機能が、当業者に知られているような1つまたは複数のPCRFなどの、コアネットワークの他の態様とインターフェースし得る。ネットワーク通信回路(通信回路)は、アプリケーションサーバおよび通信ネットワークと通信するように適合され得る。処理回路1004は、通信回路に結合され得る。

処理回路1004は、ネットワークアクセストークンを含むダウンリンクデータパケットの検証および/またはマッピングをサポートするように適合されている、1つまたは複数のプロセッサ、アプリケーション固有のプロセッサ、ハードウェアおよび/またはソフトウェアモジュールなどを含み得るかまたは実装し得る。たとえば、処理回路1004は、デバイスに関連するトリガを検出するように構成され得る。処理回路1004は、アプリケーションサービスに関連するトラフィックネットワークポリシーをトリガの検出に応答して取得することと、トラフィックネットワークポリシーに基づくネットワークアクセストークンを取得することであって、ネットワークアクセストークンが、デバイスに向けられているユーザプレーントラフィックの中でゲートウェイデバイスにおいて取得されたダウンリンクデータパケットの検証および/またはマッピングを容易にする、取得することと、制御プレーンシグナリングの中でネットワークアクセストークンをエンティティへ送ることとを行うように構成され得る。さらなる例として、ネットワークアクセストークン(本明細書では「DLトークン」とも呼ぶ)取得モジュール/回路/機能1012は、メモリ/記憶デバイス1006の中に記憶され得る非共有秘密鍵に基づいてネットワークアクセストークンを導出することを含む、本明細書で説明する態様によるネットワークアクセストークンを取得(たとえば、導出、生成、計算など)するように適合され得る。別の例として、接続識別(接続ID)取得モジュール/回路/機能1014は、秘密鍵に基づいて接続識別子を取得(たとえば、導出、生成、計算など)するように適合され得る。接続IDは、デバイス開始型接続を識別するために使用され得る。また別の例として、決定および処理モジュール/回路/機能1016は、アプリケーションサーバから受信されたダウンリンクデータパケットがネットワークアクセストークンを含むかどうかを判断/決定するように適合され得、そうである場合、受信パケットを暗号検証および/またはマッピングモジュール/回路/機能1018へ通過させるようにさらに適合され得る。決定および処理モジュール/回路/機能1016は、ネットワークアクセストークンを含まない受信パケットを、(たとえば、処理回路1004の外部の)サービスデータフローフィルタバンクへ通過させるようにさらに適合され得る。また別の例として、暗号検証/確認モジュール/回路/機能1030は、たとえば、アプリケーションサーバから受信されたネットワークアクセストークンを検証/確認するように適合され得る。この列挙は非限定的である。

メモリ/記憶デバイス1006は、ネットワークアクセストークン取得命令1020、接続ID取得命令1022、決定および処理命令1024、暗号検証および/またはマッピング命令1026、暗号検証/確認命令1028、鍵(たとえば、共有秘密鍵および/または非共有秘密鍵)ストレージおよび命令1032、ならびに接続IDストレージ1034を含むように適合され得る。この列挙は非限定的である。

ネットワーク通信回路1002、処理回路1004、メモリ/記憶デバイス1006、および例示的なゲートウェイデバイス1000の他の構成要素の間の通信は、通信バス1036を通じてよい。

ゲートウェイデバイスにおいて動作可能な例示的な方法-ネットワークアクセストークンセットアップ
図11は、本明細書で説明する態様に従って制御プレーンにおいて実施される、ネットワークアクセストークンセットアップの例示的な方法1100のフローチャートである。例示的な方法1100によれば、ゲートウェイデバイス(たとえば、パケットデータネットワークゲートウェイデバイス、P-GW)は、ネットワークアクセストークンを取得(たとえば、導出、生成、計算、部分的に計算など)することができ、そのネットワークアクセストークンをPCRFなどの第1の制御プレーンエンティティへ送ることができる。アプリケーション機能などの第2の制御プレーンエンティティは、第1の制御プレーンエンティティからネットワークアクセストークンを取得し得る。第1および第2の制御プレーンエンティティは、本明細書で説明する態様に従って、制御プレーンシグナリングを介して制御プレーンにおいてネットワークアクセストークンを取得し得る。パケットデータネットワークゲートウェイデバイス(P-GW)は、本明細書では例示のために参照される。

一態様では、ゲートウェイデバイスにおいて動作可能な例示的な方法1100は、デバイスに関連するトリガをゲートウェイデバイスにおいて検出するステップを含み得る(1102)。いくつかの態様では、ゲートウェイデバイスは、パケットデータネットワークゲートウェイデバイス(P-GW)であってよい。トリガは、制御プレーンシグナリングの中に存在し得る。

例として、トリガは、アプリケーションサービスに関連するトラフィックネットワークポリシーを取得すること、トラフィックネットワークポリシーに基づくネットワークアクセストークンを取得すること、および/または制御プレーンシグナリングの中でネットワークアクセストークンをエンティティ(たとえば、PCRF、AF)へ送ることのうちの、1つまたは複数をゲートウェイデバイスに実行させるための制御プレーンメッセージを取得することを含み得る。一実装形態では、制御プレーンメッセージは、アプリケーションサービスに関連するトラフィックネットワークポリシーを取得すること、ネットワークアクセストークンを取得すること、および/または制御プレーンシグナリングの中でネットワークアクセストークンをエンティティへ送ることのうちの、1つまたは複数を実行するための明示的コマンド(または、要求もしくは命令)を含んでよい。一実装形態では、制御プレーンメッセージは、アプリケーションサービスに関連するトラフィックネットワークポリシーを取得すること、トラフィックネットワークポリシーに基づくネットワークアクセストークンを取得すること、および/または制御プレーンシグナリングの中でネットワークアクセストークンをエンティティへ送ることのうちの、1つまたは複数を実行するための暗黙的コマンド(たとえば、個別にまたは組み合わせて、暗黙的コマンド、暗黙的要求、または暗黙的命令を表す1つまたは複数のメッセージまたはデータ)を含んでよい。一実装形態では、制御プレーンメッセージは、ベアラセットアップメッセージ、ベアラ活動化メッセージ、および/またはベアラ変更メッセージのうちの1つまたは複数に関連付けられてよい。一実装形態では、制御プレーンメッセージは、セッション作成要求であってよい。

例として、トリガは、アプリケーションサービスに向けられている、デバイスから送られた第1のデータパケットをゲートウェイデバイスにおいて取得することを含み得る。いくつかの実装形態では、トリガは、未知のアプリケーションサービスに関連する、デバイスからのデータパケット(たとえば、アップリンクデータパケット、アップリンクデータトラフィック)をゲートウェイデバイスにおいて取得することを含み得る。いくつかの実装形態では、トリガは、デバイスに関連付けられているかまたは前に関連付けられていたアプリケーションサービスと整合しない、デバイスからのデータパケットをゲートウェイデバイスにおいて取得することを含み得る。言い換えれば、トリガは、デバイスに前に関連付けられていたアプリケーションサービスに関連付けられていない、デバイスからのデータパケットをゲートウェイデバイスにおいて取得することを含んでよい。

さらなる例として、トリガは、デバイスからPDN接続性要求を受信することを含み得る。PDN接続性要求は、たとえば、ベアラセットアップ中、ベアラセット活動化中、および/もしくはベアラセット変更中に、または本質的に「ベアラ」が規定または使用されないネットワークの中ではデータフローセットアップ中、データフロー活動化中、および/もしくはデータフロー変更中に行われてよい。他の態様では、明示的コマンド、明示的要求、または明示的命令が、P-GWによって受信される既存の制御プレーンシグナリングメッセージの中に埋め込まれてよい。たとえば、明示的コマンド、明示的要求、または明示的命令が、セッション作成要求メッセージに含まれてよい。

一態様では、暗黙的コマンド、暗黙的要求、または暗黙的命令は、たとえば、P-GWにおける事前定義されたメッセージの受信から認識され得る。たとえば、P-GWの処理回路は、トリガを検出するように構成/プログラムされてよく、ここで、トリガは事前定義されたメッセージの受信である。そのような事前定義されたメッセージの一例は、セッション作成要求メッセージであってよい。同じ目的のために他のメッセージが事前定義されてよい。そのような事前定義されたメッセージの受信は、したがって、ネットワークアクセストークンを取得(たとえば、導出、生成、計算、部分的に計算など)するとともに制御プレーンシグナリングの中で送るための、コマンド、要求、または命令を暗黙のうちに表すトリガであり得る。次いで、ゲートウェイデバイス(たとえば、P-GW)を経由してアプリケーションサーバからデバイスへ送られたデータ送信の中のダウンリンクデータパケットを検証および/またはマッピングするために、ネットワークアクセストークンが使用され得る。

別の態様では、暗黙的コマンド、暗黙的要求、または暗黙的命令は、たとえば、所与のデバイスからの第1の制御プレーンシグナリングメッセージの受信から認識され得る。また別の態様では、たとえば、App IDによって識別されるノードがネットワークアクセストークンを採用する場合、暗黙的コマンド、暗黙的要求、または暗黙的命令は、特定のApp IDに関連付けられた制御プレーンシグナリングが取得されるときに認識され得る。

図11に戻ると、ゲートウェイデバイスがデバイスに関連するトリガを検出した後(1102)、ゲートウェイデバイスは、デバイスに関連するアプリケーションサービスを識別し得る(1104)。デバイスに関連するアプリケーションサービスを識別することは、トリガの検出に応答して行われてよい。ゲートウェイデバイスは、アプリケーションサービスに関連するトラフィックネットワークポリシーを取得し得る(1106)。アプリケーションサービスに関連するトラフィックネットワークポリシーを取得することは、トリガの検出に応答して行われてよい。いくつかの態様では、アプリケーションサービスに関連するトラフィックネットワークポリシーは、PCRF(332、図3)から取得されてよい。いくつかの態様では、アプリケーションサービスに関連するトラフィックネットワークポリシーは、PCRF(332、図3)のSPR(334、図3)から取得されてよい(または、それに由来するデータを含めることによって導出されてよい)。

P-GWは、次いで、トラフィックネットワークポリシーに基づくネットワークアクセストークン(本明細書では「DLトークン」とも呼ぶ)を取得(たとえば、導出、生成、計算、部分的に計算など)し得る(1108)。トラフィックネットワークポリシーに基づくネットワークアクセストークンを取得することは、トリガの検出に応答して行われてよい。ネットワークアクセストークンは、ゲートウェイデバイスにおいてユーザプレーントラフィックの中で受信されるべきダウンリンクデータパケットを検証および/またはマッピングするプロセスにおいて使用され得る。

P-GWは、たとえば、トラフィックネットワークポリシーから取得されたデータを使用して、ネットワークアクセストークンを取得し得る。ただし、ネットワークアクセストークンを取得するために使用されるデータが、トラフィックネットワークポリシーから取得されたデータに限定されることを意図しないことを理解されたい。たとえば、本明細書で説明する態様で例示されるように、ネットワークアクセストークンを取得するために使用されるデータは、トリガを備えるパケットから取得されるデータ(たとえば、セッション作成要求)、およびP-GW上で記憶/導出されるデータ(たとえば、K_P-GW、KeyID)を含んでよい。

上記で説明したように、ネットワークアクセストークンは、たとえば、ゲートウェイデバイスによって取得される秘密鍵を含む、入力データのセットを伴う機能(たとえば、暗号機能)を使用して導出され得る。いくつかの態様では、ゲートウェイデバイス(たとえば、秘密鍵を導出したP-GW)だけが、秘密鍵(たとえば、K_P-GW、図6)を知っている場合がある。入力データのセットは、ポリシー識別子、サーバ(たとえば、アプリケーションサーバ)インターネットプロトコル(IP)アドレス、サーバポート番号、宛先IPアドレス、宛先ポート番号、プロトコル識別子(Proto)、および/またはアプリケーション識別子(App ID)をさらに含み得る。追加または代替の入力データが許容され、限定はしないが、優先度および/またはサービス品質クラス識別子(QCI)、ネットワークアクセストークンを取得するために使用される秘密鍵を識別する鍵識別子(KeyID)、ならびにネットワークアクセストークン導出のために使用されるフィールドを規定するかまたはネットワークアクセストークンを導出するために使用される入力パラメータのリストを規定する、鍵パラメータインデックス(KPI)を含み得る。

一態様では、鍵識別子(KeyID)は、ネットワークアクセストークン導出のために使用される秘密鍵(たとえば、K_P-GW)を規定し得る。鍵識別子は、周期的にまたはP-GWからの命令に従って変更されてよい。いくつかの態様では、P-GWは、ネットワークアクセストークンを取得すること(たとえば、導出すること、生成すること、計算すること、要求すること、受信すること、取得すること、受諾すること、調達すること、取ること、収集すること、得ること、配信または受信を行うこと、与えられること、アクセスできるようになること、入手すること)のための複数の鍵を有してよい。P-GWがネットワークアクセストークン鍵を変更する場合、2つの鍵は、同じ時間において有効であり得る。したがって、鍵識別子は、そのようなシナリオにおける即時のネットワークアクセストークン無効化を回避するために使用され得る。

一態様では、ネットワークアクセストークンは、鍵識別子(KeyID)、鍵パラメータインデックス(KPI)、ポリシー識別子、およびネットワークアクセストークンの導出に関して使用される関数の出力の連結であってよい。いくつかの態様では、関数は、セキュアハッシュアルゴリズム(SHA:secure hash algorithm)-1、SHA-2、またはSHA-3などのセキュアハッシュ関数であってよい。他の態様では、関数は、ハッシュメッセージ認証コード(HMAC)関数であってよい。また他の態様では、関数は、メッセージ認証コード(MAC)導出関数であってよい。MAC導出関数は、暗号ブロック連鎖メッセージ認証コード(CBC-MAC:cipher block chaining message authentication code)関数、暗号ベースMAC(CMAC:cypher-based MAC)関数、またはガロアメッセージ認証コード(GMAC:Galois message authentication code)関数を含み得る。

ネットワークアクセストークンの1つの特徴は、それが特定のデバイスおよび/またはアプリケーションサービスに固有であってよいということであり得る。言い換えれば、ネットワークアクセストークンは、1つの(たとえば、特定の、所与の)デバイスおよび/または1つのアプリケーションサービスにリンク(たとえば、それにバインド)されてよい。したがって、ネットワークアクセストークンは、1つのデバイスを識別し得、かつ/または1つのアプリケーションサービスを識別し得る。したがって、ネットワークアクセストークンは、1つのアプリケーションサービスにリンクされた「デバイスごとのネットワークアクセストークン」と見なされてよい。別の態様では、ネットワークアクセストークンは、アプリケーションサーバ、アプリケーションサービス、およびデバイスにリンク/バインドされてよい。例示的な一態様によれば、P-GWは、所与のデバイスに対して識別される1つまたは複数のアプリケーションサービスの各々に対して1つのネットワークアクセストークンを取得し得る。P-GWは、SFT/TFTテンプレートを使用することを必要とせずに、ネットワークアクセストークンを含むダウンリンクデータパケットを、ネットワークアクセストークンにリンクされたデバイスおよび/またはアプリケーションサービスにマッピングすることができる。

一態様では、ネットワークアクセストークンおよびアプリケーション識別子(App ID)は、アプリケーション機能へ送られてよい。一実装形態では、ネットワークアクセストークンおよびApp IDは、ネットワークアクセストークンプロビジョニングメッセージ(たとえば、アクセス許可メッセージ)の中でアプリケーション機能へ送られてよい。App IDは、アプリケーションサーバ、アプリケーションサービス、またはネットワークアクセストークンの宛先であるアプリケーション機能を識別し得る。そのような態様では、または任意の他の態様では、ネットワークアクセストークンは、アプリケーションサーバ、アプリケーションサービス、App ID、および/またはデバイスなどの何かにリンク(たとえば、バインド)されてよい。本明細書で使用する「リンクされる」および/または「バインドされる」という用語は、ネットワークアクセストークン(本明細書では「DLトークン」とも呼ぶ)が、限定はしないが、名前付きの何か(すなわち、何かのいくつかの識別子)を含む機能を使用して取得(たとえば、導出、生成、計算など)され得ることを示す。例として、ネットワークアクセストークンは、アプリケーションサービスおよびデバイスにリンクまたはバインドされてよい(すなわち、ネットワークアクセストークンは、識別されたアプリケーションサービスおよび識別されたデバイスに固有である)。ネットワークアクセストークンを取得(たとえば、導出、生成、計算など)するために使用される式は、アプリケーションサービスおよび/またはデバイスを特に識別するものに加えて、パラメータを含んでよい。本明細書で列挙するパラメータ(たとえば、KeyID、KPI、ポリシーID、K_P-GW、IP_S、IP_C、P_S、P_C、Proto、App ID、優先度、サービス品質クラス識別子(QCI))が、ネットワークアクセストークンを取得(たとえば、導出、生成、計算など)するために使用される式の例に関して、網羅的または限定的であることを意図しないことが理解されよう。追加として、本明細書で列挙するパラメータは、ネットワークアクセストークンを取得するために使用される式の例に関して、パラメータの最小数を識別することを意図しない。

トラフィックネットワークポリシーに基づくネットワークアクセストークンを取得した後(1108)、ゲートウェイデバイスは、制御プレーンシグナリングの中でネットワークアクセストークンをエンティティへ送り得る(1110)。一実装形態では、エンティティはポリシーおよび課金ルール機能(PCRF)であってよく、ネットワークアクセストークンは、制御プレーンシグナリングの中でPCRFへ送られてよい。一実装形態では、エンティティはアプリケーション機能であってよく、ネットワークアクセストークンは、制御プレーンシグナリングの中でアプリケーション機能へ送られる。一実装形態では、エンティティはアプリケーション機能であってよく、ネットワークアクセストークンは、ポリシーおよび課金ルール機能(PCRF)を経由して制御プレーンシグナリングの中でアプリケーション機能へ送られる。

一態様では、ネットワークアクセストークンは、1つのパケットにおける制御プレーンシグナリングの中でエンティティへ送られてよい。一態様では、ネットワークアクセストークンは、複数のパケットにおける制御プレーンシグナリングの中でエンティティへ送られてよい(たとえば、ネットワークアクセストークンは、複数のパケットの間で分散されてよい)。

随意に、ゲートウェイデバイスは、上記で説明したようなアプリケーション識別子を取得してよく、制御プレーンシグナリングの中でアプリケーション識別子(App ID)をエンティティへ送ってよい(1112)。

ゲートウェイデバイスにおいて動作可能な例示的な方法-ネットワークアクセストークンを用いて実装される実施
図12は、本明細書で説明する態様に従ってユーザプレーンにおいて実施される、ネットワークアクセストークンを使用するポリシー実施の例示的な方法1200のフローチャートである。例示的な方法1200は、独立した方法であってよく、または図11の方法に追加されてもよい。言い換えれば、図12の例示的な方法1200は、図11の例示的な方法によって先行されてよい。さらに言い換えれば、図12による方法を実行する前に、ゲートウェイデバイスは、制御プレーンシグナリングの中でネットワークアクセストークンを第1の制御プレーンエンティティ(たとえば、PCRF)へ送っていてよく、第2の制御プレーンエンティティ(たとえば、アプリケーション機能)は、制御プレーンシグナリングの中で第1の制御プレーンエンティティからネットワークアクセストークンを取得していてよく、アプリケーションサーバは、第2の制御プレーンエンティティからネットワークアクセストークンを取得していてよい。アプリケーションサーバは、ネットワークアクセストークンを含むダウンリンクデータパケットを作成(たとえば、構築、コンパイル、形成、アセンブル)していてよく、ネットワークアクセストークンを含むダウンリンクデータパケットを、ゲートウェイデバイスを経由してデバイスへ送っていてよい。図12による例示的な方法が実施され得るのは、この時点であってよい。

例示的な方法1200は、ネットワークアクセストークンがゲートウェイデバイスによって制御プレーンシグナリングの中でアプリケーション機能へ送られた場合、たとえば、ゲートウェイデバイスにおいてユーザプレーンシグナリングの中で受信されたネットワークアクセストークンを使用することによって、ダウンリンクポリシーを効率的に実施するために使用され得る。

例示的な方法1200は、ゲートウェイデバイス(たとえば、P-GW)において動作可能であり得る。一態様では、方法は、ネットワークアクセストークンを含むダウンリンクデータパケットを、ゲートウェイデバイスにおいてユーザプレーントラフィックの中で取得するステップを含み得る(1202)。いくつかの実装形態では、方法は、ダウンリンクデータパケットを(たとえば、ネットワークアクセストークンを確認することによって)検証すること、および/またはネットワークアクセストークンから取得されたデータを使用してダウンリンクデータパケットをデバイスにマッピングすることを含む、1つまたは複数のプロセスを実行するステップをさらに含み得る。ゲートウェイデバイスは、検証および/またはマッピングするプロセスを実行すべきかどうかを決定し得る(1204)。

ゲートウェイデバイスが、検証およびマッピングするプロセスを実行すべきと決定した場合、ゲートウェイデバイスは、ネットワークアクセストークンを確認し得る(1206)。ゲートウェイデバイスは、ネットワークアクセストークンの確認が成功したかどうかを決定し得る(1208)。ネットワークアクセストークンの確認が成功しなかった場合、ゲートウェイデバイスは、ダウンリンクデータパケットを廃棄してよい(1210)。ネットワークアクセストークンの確認が成功した場合、ゲートウェイデバイスは、ネットワークアクセストークンから取得されたデータを使用して、デバイスへのダウンリンクデータパケットのマッピングを実行してよい(1212)。ゲートウェイデバイスは、ネットワークアクセストークンをダウンリンクデータパケットから除去してよい(1214)。ゲートウェイデバイスは、次いで、マッピングに従ってデータパケットをデバイスへ送り得る(1216)。ダウンリンクデータパケットからのネットワークアクセストークンの除去は、ネットワークアクセストークンの確認の前または後に実行されてよい。いくつかの実装形態では、ネットワークアクセストークンの除去は随意であってよい。

同様に、ゲートウェイデバイスが、検証およびマッピングするプロセスを実行すべきでないと決定した場合(1204)、ゲートウェイデバイスは、マッピングするプロセスを実行すべきかどうかを決定し得る(1218)。ゲートウェイデバイスが、マッピングするプロセスを(たとえば、ネットワークアクセストークンを確認することなく)実行すべきと決定した場合、ゲートウェイデバイスは、ネットワークアクセストークンから取得されたデータを使用して、デバイスへのダウンリンクデータパケットのマッピングを実行してよい(1212)。ゲートウェイデバイスは、ネットワークアクセストークンをダウンリンクデータパケットから除去してよい(1214)。ダウンリンクデータパケットからのネットワークアクセストークンの除去は、マッピングの前または後に実行されてよい。いくつかの実装形態では、ネットワークアクセストークンの除去は随意である。ゲートウェイデバイスは、次いで、マッピングに従ってデータパケットをデバイスへ送り得る(1216)。

第1のネットワークアクセストークンの確認は、たとえば、第1のネットワークアクセストークンを含んでいたダウンリンクデータパケットから取得されたデータを使用して行われてよい。ゲートウェイデバイスは、ダウンリンクデータパケットから取得されたデータに基づいて第2のネットワークアクセストークンを取得(たとえば、導出、生成、計算など)し得る。ゲートウェイデバイスは、ダウンリンクデータパケットに含まれる第1のネットワークアクセストークンを、第2のネットワークアクセストークンと比較することによって確認し得る。ゲートウェイデバイスが、ダウンリンクデータパケットから取得されたデータに基づいて第2のネットワークアクセストークンを取得したので(また、たとえば、ダウンリンクデータパケットが本物である場合、取得されたデータが第1のネットワークアクセストークンを作成するために使用されるデータと同じであるはずなので)、第2のネットワークアクセストークンは、おそらく第1のネットワークアクセストークンに等しいはずである。ゲートウェイデバイスは、第1のネットワークアクセストークンを第2のネットワークアクセストークンと比較してよく、第1のネットワークアクセストークンおよび第2のネットワークアクセストークンが等しい場合、ネットワークアクセストークンの確認は成功する。すなわち、第2のネットワークアクセストークンの値が第1のネットワークアクセストークンの値に整合する(たとえば、それに等しい、それと等価である)場合、第1のネットワークアクセストークンの確認は成功する。その上、第2のネットワークアクセストークンの値が第1のネットワークアクセストークンの値に整合する(たとえば、それに等しい、それと等価である)場合、(第1のネットワークアクセストークンを含んでいた)ダウンリンクデータパケットの検証が成功したという結論が下されてよい。

ゲートウェイデバイスにおけるダウンリンクデータパケットの検証は、たとえば、デバイスが、認可されたアプリケーションサービスからのパケットしか受信しないことを確実にするために、かつ/あるいは検証されているダウンリンクデータパケットにトラフィックネットワークポリシーおよび/または特定のパケット処理ポリシー(たとえば、QoSポリシー)を適用するために望ましいことがある。検証は、各パケットの宛先アドレス、宛先アドレスおよびポート番号、または宛先アドレスプレフィックスを確認することを含んでよい。検証は、追加または代替として、各パケットのソースアドレス、ソースアドレスおよびポート番号、またはソースアドレスプレフィックスを確認することを含んでよい。当業者に知られているように、宛先アドレスおよびソースアドレスは各々、2つの部分、すなわち、プレフィックス部およびサフィックス部が備えられ得る。各パケットのソースアドレスプレフィックスを確認することは、ポリシーが特定のサーバの代わりにソース領域に適用される場合に有用であり得る(すなわち、アプリケーションサービスは、特定のサーバ(たとえば、マシン)にひも付けられなくてよい)。各パケットのソースアドレスを確認することは、(たとえば、無認可アプリケーションサービスからのパケットが、認可されたアプリケーションサービスから来るように見えることによってセルラー通信ネットワークをだますことを防止することによる)アンチスプーフィング(anti-spoofing)にとって有用であり得る。追加として、ダウンリンクデータパケットの検証は、各パケットのプロトコル番号を確認すること、ならびに各ダウンリンクデータパケットにアクセス制御およびレート制御を適用する(たとえば、QoSポリシーが、ある種のアクセス制御およびレート制御を規定し得る)ことを必要としてよい。

さらに、P-GWは、ダウンリンクデータパケットに含まれるネットワークアクセストークンを使用して、ネットワークアクセストークンに関連する(たとえば、リンクされる、バインドされる)デバイスにダウンリンクデータパケットをマッピングし得る。マッピングは、ネットワークアクセストークンから取得されたデータを使用して(たとえば、データをマッピングして)達成され得る。データは、たとえば、ネットワークアクセストークンを解読することによって、ネットワークアクセストークンから取得され得る。ネットワークアクセストークンの中に含まれるデータ(たとえば、ネットワークアクセストークンを導出、生成、計算するために使用されるデータ)は、たとえば、ネットワークアクセストークンを取得(たとえば、導出、生成、計算など)するために使用される鍵(たとえば、K_P-GW)の識別子(たとえば、KeyID)、ネットワークアクセストークン導出のために使用されるフィールドを規定し得るかまたはネットワークアクセストークンを導出するために使用される入力パラメータのリストを規定し得る、鍵パラメータインデックス(たとえば、KPI)、トラフィックネットワークポリシー、特定のパケット処理ポリシー、および/またはフロー処理ポリシー(たとえば、当業者によって理解されるような、データフローまたはベアラ、およびフロー処理ポリシーの他の側面に、フローをマッピングするQoSポリシー)を規定し得るポリシー識別子(たとえば、ポリシーID)、サーバ(たとえば、アプリケーションサーバ)IPアドレス(たとえば、IP_S)、クライアント(たとえば、チップコンポーネント、クライアントデバイス、ユーザ機器)IPアドレス(たとえば、IP_C)、サーバポート番号(たとえば、P_S)、クライアントポート番号(たとえば、P_C)、プロトコル番号またはプロトコル識別子(たとえば、Proto)、ならびにアプリケーション識別子(たとえば、App ID)を含み得る。ネットワークアクセストークンから取得されたデータを使用して、ゲートウェイデバイスは、アプリケーションサービスに関連するトラフィックネットワークポリシーの中に記載された要件に適合するデータフローまたはベアラ(たとえば、IP-CANベアラ)を介して、ネットワークアクセストークンを含んでいたダウンリンクデータパケットをデバイスにマッピングすることができる。マッピングは、たとえば、ネットワークアクセストークンにおけるポリシーIDフィールドの中のデータフローまたはベアラの識別によって容易にされ得る。

図13は、本明細書で説明する態様に従ってユーザプレーンにおいて実施される、ネットワークアクセストークンを使用するポリシー実施の別の例示的な方法1300のフローチャートである。例示的な方法1300は、ネットワークアクセストークンがゲートウェイデバイスによって制御プレーンシグナリングの中でアプリケーション機能へ送られた場合、たとえば、ゲートウェイデバイスにおいてユーザプレーンシグナリングの中で受信されたネットワークアクセストークンを使用することによって、ダウンリンクポリシーを効率的に実施するために使用され得る。

例示的な方法1300は、ゲートウェイデバイス(たとえば、P-GW)において動作可能であり得る。一態様では、ネットワークアクセストークンを含むダウンリンクデータパケットは、ゲートウェイデバイスにおいてユーザプレーントラフィックの中で取得され得る(1302)。ゲートウェイデバイスにおけるモジュール/回路/機能は、ネットワークアクセストークンを確認し得る(1304)。確認は、上記で説明したように行われてよい。ネットワークアクセストークンの確認は、成功しているかまたは成功していないものとして決定され得る(1306)。ネットワークアクセストークンの確認が成功しなかった場合、ダウンリンクデータパケットは廃棄されてよい(1308)。ネットワークアクセストークンの確認が成功した場合、新規ネットワークアクセストークンが必要とされるかどうかの決定が行われてよい(1310)。

たとえば、ネットワークアクセストークンがいくつかの条件下でしか有効でない場合があるので、新規ネットワークアクセストークンが必要とされることがある。たとえば、いくつかの態様では、ネットワークアクセストークンは周期的に変更されることがある。別の態様では、ネットワークアクセストークンは、ネットワークアクセストークンの導出からの所定の時間に基づく満了を条件とすることがある。ネットワークアクセストークンは、所定の時間が満了すると有効であることをやめる場合がある。いくつかの態様では、ネットワークアクセストークンは、ネットワークアクセストークンを導出するために使用される鍵(たとえば、K_P-GW)に課された制限に基づく満了を条件とすることがある。たとえば、ネットワークアクセストークンを導出するために使用される鍵は、新たな鍵(たとえば、K''_P-GW)によって取り換えられてよい。既存の鍵(たとえば、K'_P-GW)と新たな異なる鍵(たとえば、K''_P-GW)との取換えは、たとえば、既存の鍵、鍵識別子、またはいくつかの他のイベントの、所定の時限の満了に起因してよい。ネットワークアクセストークンがネットワークアクセストークンとしての使用にとってもはや有効でないか、またはいくつかの他の方法でもはや望まれないと決定されると、ゲートウェイデバイスは、現在のネットワークアクセストークンを取り換えるための新規ネットワークアクセストークンを取得してよい(1316)。

ゲートウェイデバイスは、新規ネットワークアクセストークンを取得(たとえば、導出など)するための決定を行ってよい。新規ネットワークアクセストークンセットアップが、上記で説明したように先行してよい。新規ネットワークアクセストークンが現在使用中のネットワークアクセストークンと同じにならないように、(現在使用中のネットワークアクセストークンを導出するために使用された複数のパラメータの中の)少なくとも1つのパラメータが変更されるのを必要とされ得ることを、当業者は理解されよう。パラメータの変更は、限定はしないが、複数のパラメータの連結の中でのパラメータのロケーションを変更すること、パラメータの値を変更すること(たとえば、パラメータの値は時間の関数であってよい)、および/または第2のパラメータの代わりに第1のパラメータを代用することを含んでよく、ここで、第2のパラメータは第1のパラメータと異なる。

新規ネットワークアクセストークンが必要とされない場合、第1の代替形態によれば、ネットワークアクセストークンを含むダウンリンクデータパケットが、その宛先へ送られてよい(1312)。第2の代替形態によれば、ネットワークアクセストークンを有しないダウンリンクデータパケットが、その宛先へ送られてよい(1313)。両方の代替形態によれば、ダウンリンクデータパケットの宛先はデバイスである。

新規ネットワークアクセストークンが必要とされる場合、ゲートウェイデバイスは、たとえば、前に説明した方法に従って、新規ネットワークアクセストークンを取得してよい(1316)。新規ネットワークアクセストークンは、ゲートウェイデバイスに関連するPCRFへ送られてよい(1318)。追加のダウンリンクデータパケットをゲートウェイデバイスへ送るアプリケーションサーバは、新規ネットワークアクセストークンを、たとえば、PCRFからアプリケーション機能を経由して取得し得る。

追加として、第1の代替形態によれば、新規ネットワークアクセストークンを含むダウンリンクデータパケットが、その宛先へ送られてよい(1314)。第2の代替形態によれば、新規ネットワークアクセストークンを有しないダウンリンクデータパケットが、その宛先へ送られてよい(1315)。両方の代替形態によれば、ダウンリンクデータパケットの宛先はデバイスである。

いくつかの態様では、別のエンティティ(たとえば、デバイスまたはアプリケーションサーバ)が、ダウンリンクトークンを取得(たとえば、導出など)するための決定を行ってよい。たとえば、一態様では、デバイスは、ダウンリンクトークンを必要とすることを決定し得る。別の態様では、アプリケーションサーバは、ダウンリンクトークンを必要とすることを決定し得る。別のエンティティ(たとえば、デバイス)がダウンリンクトークンを必要とする場合、そのダウンリンクトークンは、ゲートウェイデバイスのネットワークアクセストークンとは無関係となるべきである。他のエンティティによって必要とされることが決定されたダウンリンクトークンは、他のエンティティ(たとえば、デバイス)によって導出されるとともにアプリケーションサーバへ送られてよい。鍵K_P-GWを使用してP-GWによって取得(導出など)されたネットワークアクセストークンを変更するように、デバイスがゲートウェイデバイス(たとえば、P-GW)に強制または要求できず、これは、そうすることが他のデバイスおよびサービスフローに関連するすべてのネットワークアクセストークンを無効にすることになるからであることに留意されたい。

例示的なアプリケーションサーバ
図14は、本明細書で説明する態様による、ダウンリンクデータパケットの検証および/またはマッピングをサポートするように適合された例示的なアプリケーションサーバ1400を示すブロック図である。一例では、例示的なアプリケーションサーバ1400は、ネットワーク通信回路1402、ネットワーク通信回路1402に結合された処理回路1404、および処理回路1404に結合されたメモリ/記憶デバイス1406を含み得る。この列挙は非限定的である。これらの回路および/もしくはデバイスまたはそれらの任意の組合せは、検出する、識別する、送る、作成する、かつ/またはマッピングするアクションを実行し得る。したがって、これらの回路および/もしくはデバイスまたはそれらの任意の組合せは、検出するための手段、識別するための手段、送るための手段、作成するための手段、および/またはマッピングするための手段の非限定的な例と見なされてよい。

ネットワーク通信回路1402は、たとえば、通信ネットワークと通信するように適合され得る。ネットワーク通信回路1402は、ゲートウェイデバイス(たとえば、P-GW)との通信用の第1の入力/出力モジュール/回路/機能1408を含み得る。ネットワーク通信回路1402は、追加のエンティティとの通信用の受信機/送信機モジュール/回路/機能1410含み得る。この列挙は非限定的である。

処理回路1404は、ネットワークアクセストークン(本明細書では「DLトークン」とも呼ぶ)関連のアクションおよび/または動作をサポートするように適合されている、1つまたは複数のプロセッサ、アプリケーション固有のプロセッサ、ハードウェアおよび/またはソフトウェアモジュールなどを含み得るかまたは実装し得る。たとえば、処理回路1404は、デバイスにリンクされるとともにアプリケーションサーバおよび/またはアプリケーションサービスにリンクされたネットワークアクセストークンを取得するように構成され得る。処理回路1404は、デバイスに向けたダウンリンクデータパケットを作成し、ダウンリンクデータパケットをネットワークアクセストークンにマッピングし、ダウンリンクデータパケットの中にネットワークアクセストークンを含め、ネットワークアクセストークンを含むダウンリンクデータパケットを、ゲートウェイデバイスを経由してユーザプレーントラフィックの中でデバイスへ送るように構成され得る。これらのアクションおよび/または動作の各々は、ゲートウェイデバイスが最初に制御プレーンシグナリングの中で直接または間接的にネットワークアクセストークンをアプリケーションサーバへ送った場合、ゲートウェイデバイスにおいてユーザプレーントラフィックの中で受信されるべきダウンリンクデータパケットを検証および/またはマッピングするプロセスの一部であってよい。さらなる例として、ネットワークアクセストークン取得モジュール/回路/機能1412は、メモリ/記憶デバイス1406の中に記憶され得るネットワークアクセストークンを取得する(たとえば、導出する、生成する、計算する、要求する、受信する、取得する、受諾する、調達する、取る、収集する、得る、配信または受信を行う、与えられる、アクセスできるようになる、入手するなど)ように適合され得るか、または例示的なアプリケーションサーバ1400に関連するアプリケーション機能からネットワークアクセストークンを取得するように適合され得る。別の例として、ネットワークアクセストークン包含モジュール/回路/機能1414は、ゲートウェイデバイスに転送されるダウンリンクデータパケットの中にネットワークアクセストークンを含める(たとえば、埋め込む、関連付ける、組み込む、追加する)ように適合され得る。また別の例として、暗号検証/確認モジュール/回路/機能1416は、たとえば、デバイスから受信されたトークンを検証/確認するように適合され得る。この列挙は非限定的である。

メモリ/記憶デバイス1406は、ネットワークアクセストークン処理命令1420、ネットワークアクセストークン包含(たとえば、埋込み、関連付け)命令1422、暗号検証/確認命令1424、ならびに鍵(たとえば、共有秘密鍵および/または非共有秘密鍵)ストレージならびにトークン(たとえば、ネットワークアクセストークン)ストレージおよび命令1426を含むように適合され得る。この列挙は非限定的である。

ネットワーク通信回路1402、処理回路1404、メモリ/記憶デバイス1406、および例示的なアプリケーションサーバ1400の他の構成要素(図示せず)の間の通信は、通信バス1434を通じてよい。

アプリケーションサーバにおいて動作可能な例示的な方法
図15は、本明細書で説明する態様による、アプリケーションサーバが、ネットワークアクセストークンを取得し、ダウンリンクデータパケットの中にネットワークアクセストークンを含め(たとえば、組み込み、関連付け)、ゲートウェイデバイスを経由してデータ送信の中でダウンリンクデータパケットをデバイスへ送る、例示的な方法1500のフローチャートである。例示的な方法1500は、アプリケーションサーバにおいて動作可能であり得る。

例示的な方法1500は、デバイスにリンクされるとともにアプリケーションサーバおよび/またはアプリケーションサービスにリンクされたネットワークアクセストークンを、アプリケーションサーバにおいて取得するステップを含み得る(1502)。例示的な方法1500はまた、デバイスに向けたダウンリンクデータパケットを作成するステップを含み得る(1504)。このことは、ダウンリンクデータパケットをネットワークアクセストークンにマッピングすることによって後続され得る(1506)。ただし、例示的な方法1500で説明されるアクションが任意の順序で実行されてよいことに留意されたい。例示的な方法1500は、アプリケーションサーバに、ダウンリンクデータパケットの中にネットワークアクセストークンを含めさせる(埋め込ませる、関連付けさせる)ステップをさらに含み得る(1508)。例示的な方法1500は、次いで、ネットワークアクセストークンを含むダウンリンクデータパケットを、ゲートウェイデバイスを経由してユーザプレーントラフィックの中でデバイスへ送るステップを伴い得る(1510)。

いくつかの態様によれば、ネットワークアクセストークンは、制御プレーンシグナリングの中でゲートウェイデバイスから取得され得る。ネットワークアクセストークンは、制御プレーンシグナリングの中でゲートウェイデバイスから直接または間接的のいずれかで取得され得る。たとえば、ネットワークアクセストークンは、アプリケーションサーバに関連するアプリケーション機能において、制御プレーンシグナリングの中でゲートウェイデバイスから取得され得る。さらに、アプリケーション機能において取得されたネットワークアクセストークンは、ゲートウェイデバイスに関連するポリシーおよび課金ルール機能(PCRF)とのインターフェース(たとえば、Rxインターフェース)を介して取得されていてよい。しかしながら、概して、いくつかの態様によれば、ネットワークアクセストークンは、制御プレーンシグナリングの中でゲートウェイデバイスから取得され得る。アプリケーションサービスは、アプリケーションサーバ上でホスティングされ得る。いくつかの実装形態では、ネットワークアクセストークンは、インターネットプロトコル(IP)ヘッダであってIPv4用のIPオプションフィールドであるIPヘッダ、インターネットプロトコル(IP)ヘッダであってIPv6用のIP拡張ヘッダであるIPヘッダ、伝送制御プロトコル(TCP)ヘッダ、セキュアソケットレイヤ(SSL)ヘッダ、トランスポートレイヤセキュリティ(TLS)レコードヘッダ、インターネットプロトコル(IP)ヘッダと伝送制御プロトコル/ユーザデータグラムプロトコル(TCP/UDP)ヘッダとの間のシムヘッダ、および/またはハイパーテキスト転送プロトコル(HTTP)ヘッダのうちの1つまたは複数の中に含まれ得る。

例示的なデバイス
図16は、本明細書で説明する態様による、ダウンリンクデータパケットの検証および/またはマッピングをサポートするように適合された例示的なデバイス1600を示すブロック図である。一例では、例示的なデバイス1600は、ネットワーク通信回路1602、ネットワーク通信回路1602に結合された処理回路1604、および処理回路1604に結合されたメモリ/記憶デバイス1606を含み得る。この列挙は非限定的である。これらの回路および/もしくはデバイスまたはそれらの任意の組合せは、検出する、識別する、送る、作成する、かつ/またはマッピングするアクションを実行し得る。したがって、これらの回路および/もしくはデバイスまたはそれらの任意の組合せは、検出するための手段、識別するための手段、送るための手段、作成するための手段、および/またはマッピングするための手段の非限定的な例と見なされてよい。

ネットワーク通信回路1602は、ユーザとの入力/出力動作用の第1の入力/出力モジュール/回路/機能1608を含み得る。ネットワーク通信回路1602は、アクセスノード(たとえば、eノードB)とのワイヤレス通信用の受信機/送信機モジュール/回路/機能1610を含み得る。この列挙は非限定的である。

処理回路1604は、制御プレーンシグナリングの中でアプリケーション機能へ送られたネットワークアクセストークンを使用してダウンリンクデータトラフィックの効率的なポリシー実施をサポートするように適合されている、1つまたは複数のプロセッサ、アプリケーション固有のプロセッサ、ハードウェアおよび/またはソフトウェアモジュールなどを含み得るかまたは実装し得る。処理回路1604は、したがって、例示的なデバイス1600は、本明細書で説明する態様による、ネットワークアクセストークンを含むダウンリンクデータパケットの検証および/またはマッピングを含む効率的なポリシー実施のプロセスをサポートし得る。たとえば、ネットワークアクセストークントリガモジュール/回路/機能1612は、またはより一般的には処理回路1604は、またはさらにより一般的には例示的なデバイス1600は、トリガがゲートウェイデバイスにおいて受信されるようにする制御プレーンメッセージを作成(たとえば、構築、コンパイル、形成、アセンブル)するように適合され得る。ネットワークアクセストークントリガモジュール/回路/機能1612は、またはより一般的には処理回路1604は、またはさらにより一般的には例示的なデバイス1600は、制御プレーンシグナリングの中で制御プレーンメッセージを送るようにさらに適合されてよく、ここで、トリガを検出することによって、アプリケーションサービスに関連するトラフィックネットワークポリシーを取得すること、トラフィックネットワークポリシーに基づくネットワークアクセストークンを取得すること、および/または制御プレーンシグナリングの中でネットワークアクセストークンをエンティティ(たとえば、AF、PCRF)へ送ることのうちの1つまたは複数をゲートウェイデバイスが実行し得るようになる。

メモリ/記憶デバイス1606は、ネットワークアクセストークン要求命令1620を含むように適合され得る。この列挙は非限定的である。

ネットワーク通信回路1602、処理回路1604、メモリ/記憶デバイス1606、および例示的なデバイス1600の他の構成要素(図示せず)の間の通信は、通信バス1634を通じて行われてよい。

図示および説明した特定の実装形態は例にすぎず、本明細書で別段に規定されない限り、本開示を実装するための唯一の方法として解釈されるべきでない。

本明細書で説明し、図面に示した、構成要素、動作、特徴、および/または機能のうちの1つまたは複数は、単一の構成要素、動作、特徴、または機能に再構成および/または結合されてよく、いくつかの構成要素、動作、特徴、または機能に具現化されてもよい。本発明から逸脱することなく、さらなる要素、構成要素、動作、および/または機能も追加されてよい。本明細書で説明したアルゴリズムはまた、ソフトウェアに効率的に実装され得る。本明細書で説明したアルゴリズムはまた、ハードウェアに効率的に実装されてよく、含まれてよく、および/または組み込まれてよい。

説明では、不要な詳細で本開示を不明瞭にしないように、要素、モジュール、回路、および/または機能がブロック図の形態で示されることがある。反対に、図示および説明した特定の実装形態は例にすぎず、本明細書で別段に規定されない限り、本開示を実装するための唯一の方法として解釈されるべきでない。追加として、ブロック定義、および様々なブロック間の論理の区分は、特定の実装形態の例である。ほとんどの部分について、タイミング問題などに関する詳細は、そのような詳細が本開示の完全な理解を得るために必要ではなく、関連分野における当業者の能力の範囲内である場合、省略されている。

また、態様がフローチャート、フロー図、構造図、またはブロック図として示されるプロセスとして説明され得ることに留意されたい。フローチャートは動作を逐次プロセスとして説明することがあるが、動作の多くは並列にまたは同時に実行され得る。追加として、動作の順序は並べ替えられてよい。プロセスは、その動作が完了したときに終了する。プロセスは、メソッド、関数、プロシージャ、サブルーチン、サブプログラムなどに対応し得る。プロセスが関数に対応するとき、その終了は呼出し関数またはメイン関数への関数のリターンに対応する。

情報および信号が、様々な異なる技術および技法のいずれかを使用して表され得ることを、当業者は理解するであろう。たとえば、この説明全体にわたって言及され得るデータ、命令、コマンド、情報、信号、ビット、シンボル、およびチップは、電圧、電流、電磁波、磁場もしくは磁性粒子、光場もしくは光学粒子、またはそれらの任意の組合せによって表され得る。いくつかの図面は、提示および説明を明快にするために、信号を単一の信号として示すことがある。信号が信号のバスを表してよく、バスが様々なビット幅を有してよく、本開示が、単一のデータ信号を含む任意の数のデータ信号上に実装されてよいことが当業者によって理解されよう。

本明細書で「第1の」、「第2の」などの呼称を使用した要素へのいかなる言及も、そのような限定が明示的に述べられていない限り、それらの要素の数量または順序を限定しないことを理解されたい。むしろ、これらの呼称は、2つ以上の要素の間、または要素の事例の間を区別する都合のよい方法として本明細書で使用され得る。したがって、第1の要素および第2の要素への言及は、2つの要素だけがそこで採用され得ること、または何らかの形で第1の要素が第2の要素に先行しなければならないことを意味しない。追加として、別段に述べられていない限り、要素のセットは1つまたは複数の要素を備え得る。

その上、記憶媒体は、読取り専用メモリ(ROM)、ランダムアクセスメモリ(RAM)、磁気ディスク記憶媒体、光学記憶媒体、フラッシュメモリデバイス、ならびに/あるいは情報を記憶するための他の機械可読媒体、プロセッサ可読媒体、および/またはコンピュータ可読媒体を含む、データを記憶するための1つまたは複数のデバイスを表してよい。「機械可読媒体」、「コンピュータ可読媒体」、および/または「プロセッサ可読媒体」という用語は、限定はしないが、ポータブル記憶デバイスもしくは固定記憶デバイス、光記憶デバイス、ならびに命令および/またはデータを記憶、包含、または搬送することが可能な様々な他の媒体などの非一時的媒体を含んでよい。したがって、本明細書で説明した様々な方法は、「機械可読媒体」、「コンピュータ可読媒体」、および/または「プロセッサ可読媒体」に記憶され得るとともに1つまたは複数のプロセッサ、機械、および/またはデバイスによって実行され得る命令および/またはデータによって、完全にまたは部分的に実装されてよい。

さらに、態様は、ハードウェア、ソフトウェア、ファームウェア、ミドルウェア、マイクロコード、またはそれらの任意の組合せによって実装されてよい。ソフトウェア、ファームウェア、ミドルウェア、またはマイクロコードで実装されるとき、必要なタスクを実行するためのプログラムコードまたはコードセグメントは、記憶媒体または他のストレージなどの機械可読媒体の中に記憶され得る。プロセッサは、必要なタスクを実行し得る。コードセグメントは、プロシージャ、関数、サブプログラム、プログラム、ルーチン、サブルーチン、モジュール、ソフトウェアパッケージ、クラス、または命令、データ構造、もしくはプログラムステートメントの任意の組合せを表してよい。コードセグメントは、情報、データ、引数、パラメータ、もしくはメモリ内容を渡すことおよび/または受け取ることによって、別のコードセグメントまたはハードウェア回路に結合されてよい。情報、引数、パラメータ、データなどは、メモリ共有、メッセージパッシング、トークンパッシング、ネットワーク送信などを含む任意の好適な手段を介して渡され、転送され、または送信されてよい。

本明細書で開示する例に関して説明した様々な例示的な論理ブロック、要素、モジュール、回路、機能、および/または構成要素は、汎用プロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)もしくは他のプログラマブル論理構成要素、個別ゲートもしくはトランジスタ論理、個別ハードウェア構成要素、または本明細書で説明した機能を実行するように設計されたそれらの任意の組合せを用いて実装または実行されてよい。汎用プロセッサはマイクロプロセッサであってよいが、代替として、プロセッサは、任意の従来のプロセッサ、コントローラ、マイクロコントローラ、またはステートマシンであってもよい。プロセッサはまた、コンピューティング構成要素の組合せ、たとえば、DSPとマイクロプロセッサとの組合せ、いくつかのマイクロプロセッサ、DSPコアと連係した1つもしくは複数のマイクロプロセッサ、および/または他の任意のそのような構成として実装されてよい。本明細書で説明した態様を実行するために構成された汎用プロセッサは、そのような態様を実行するための専用プロセッサと見なされる。同様に、汎用コンピュータは、本明細書で説明した態様を実行するために構成されるとき、専用コンピュータと見なされる。

本明細書で開示する例に関して説明した方法またはアルゴリズムは、処理ユニット、プログラミング命令、または他の指示の形態で、直接ハードウェアで、プロセッサによって実行可能なソフトウェアモジュールで、または両方の組合せで具現化されてよく、単一のデバイスに含まれるかまたは複数のデバイスにわたって分散されることがある。ソフトウェアモジュールは、RAMメモリ、フラッシュメモリ、ROMメモリ、EPROMメモリ、EEPROMメモリ、レジスタ、ハードディスク、リムーバブルディスク、CD-ROM、または当技術分野で既知の任意の他の形態の記憶媒体に存在してよい。記憶媒体は、プロセッサが記憶媒体から情報を読み取ることができ、記憶媒体に情報を書き込むことができるように、プロセッサに結合されてよい。代替として、記憶媒体はプロセッサと一体であってもよい。

本明細書で開示する態様に関して説明した様々な例示的な論理ブロック、要素、モジュール、回路、機能、および/またはアルゴリズムステップが、電子ハードウェア、コンピュータソフトウェア、または両方の組合せとして実装され得ることを、当業者はさらに諒解するであろう。ハードウェアとソフトウェアとのこの互換性を明確に示すために、様々な例示的な構成要素、ブロック、要素、モジュール、回路、機能、および/またはステップが、それらの機能に関して上記で概して説明された。そのような機能がハードウェアとして実装されるのか、ソフトウェアとして実装されるか、それともそれらの組合せとして実装されるのかは、特定の適用例およびシステムまたはネットワーク全体に課された設計選択に依存する。

本明細書で説明した本発明の様々な特徴は、本発明から逸脱することなく、異なるシステムまたはネットワークで実施され得る。上記の態様は例にすぎず、本発明を限定するものとして解釈されるべきではないことに留意されたい。態様の説明は例示的であることが意図され、特許請求の範囲を限定することは意図されない。したがって、本教示は、他のタイプの装置に容易に適用されてよく、多くの代替形態、変更形態、および変形形態が当業者には明らかであろう。

204 サービス
206 第1のIPパケットフロー
208 第2のIPパケットフロー
210 第1のゲートウェイデバイス
212 第2のゲートウェイデバイス
214 SDF/TFTテンプレート
216 トラフィックフローテンプレートフィルタ処理ルール
218〜219 ベアラ
220 デバイス
222 暗号モジュール/回路/機能
224〜225 ベアラ
226 デバイス
302〜304 デバイス
306 アクセスノード
308 無線アクセスネットワーク
310 コアネットワーク
312 モビリティ管理エンティティ
316 サービングゲートウェイデバイス
318 ホーム加入者サーバ
320 パケットデータネットワークゲートウェイデバイス
322 パケットデータネットワーク
324 アプリケーションサーバ
325 アプリケーション機能
332 ポリシーおよび課金ルール機能
334 加入プロファイルリポジトリ
402 デバイス
404 アクセスノード
406 サービングゲートウェイデバイス
408 ゲートウェイデバイス
410 パケットデータネットワーク
412 アプリケーション/アプリケーションサービス
414 ダウンリンクIPフロー
416 トラフィックフローテンプレート
418 データフローまたはベアラ
420 決定および処理モジュール/回路/機能
422 暗号検証および/またはマッピングモジュール/回路/機能
424 サービスデータフローテンプレート
426 パケットフィルタ
428 テーブル
430 パケットフィルタ
432 接続IDストレージ
800 ユーザプレーンプロトコルスタック
802 デバイス
804 アクセスノード
806 ゲートウェイデバイス
808 アプリケーションサーバ
810 物理レイヤ
812 媒体アクセス制御レイヤ
814 無線リンク制御レイヤ
816 パケットデータコンバージェンスプロトコルレイヤ
818 IPレイヤ
822 シムレイヤ
823 シムレイヤ
824 IPレイヤ
826 汎用パケット無線サービストンネリングプロトコルユーザデータレイヤ
830 物理レイヤ
832 媒体アクセス制御レイヤ
834 無線リンク制御レイヤ
836 パケットデータコンバージェンスプロトコルレイヤ
840 イーサネット（登録商標）レイヤ
842 媒体アクセス制御レイヤ
844 IPレイヤ
846 ユーザデータグラムプロトコルレイヤ
848 汎用パケット無線サービストンネリングプロトコルユーザデータレイヤ
850 イーサネット（登録商標）レイヤ
852 媒体アクセス制御レイヤ
854 IPレイヤ
856 ユーザデータグラムプロトコルレイヤ
858 IPレイヤ
860 ネットワークアクセストークン
1000 ゲートウェイデバイス
1002 ネットワーク通信回路
1004 処理回路
1006 メモリ/記憶デバイス
1008 第1の入力/出力モジュール/回路/機能
1010 第2の入力/出力モジュール/回路/機能
1012 ネットワークアクセストークン取得モジュール/回路/機能
1014 接続ID取得モジュール/回路/機能
1016 決定および処理モジュール/回路/機能
1018 暗号検証および/またはマッピングモジュール/回路/機能
1020 ネットワークアクセストークン取得命令
1022 接続ID取得命令
1024 決定および処理命令
1026 暗号検証および/またはマッピング命令
1028 暗号検証/確認命令
1030 暗号検証/確認モジュール/回路/機能
1032 鍵ストレージおよび命令
1034 接続IDストレージ
1400 アプリケーションサーバ
1402 ネットワーク通信回路
1404 処理回路
1406 メモリ/記憶デバイス
1408 第1の入力/出力モジュール/回路/機能
1410 受信機/送信機モジュール/回路/機能
1412 ネットワークアクセストークン取得モジュール/回路/機能
1414 ネットワークアクセストークン包含モジュール/回路/機能
1416 暗号検証/確認モジュール/回路/機能
1420 ネットワークアクセストークン処理命令
1422 ネットワークアクセストークン包含命令
1424 暗号検証/確認命令
1426 鍵ストレージならびにトークンストレージおよび命令
1434 通信バス
1600 デバイス
1602 ネットワーク通信回路
1604 処理回路
1606 メモリ/記憶デバイス
1608 第1の入力/出力モジュール/回路/機能
1610 受信機/送信機モジュール/回路/機能
1612 ネットワークアクセストークントリガモジュール/回路/機能
1620 ネットワークアクセストークン要求命令
1634 通信バス

Claims (15)

1. ゲートウェイデバイスにおいて動作可能な方法であって、
   デバイスに関連するトリガを前記ゲートウェイデバイスにおいて検出するステップと、
   前記デバイスに関連するアプリケーションサービスを前記トリガの検出に応答して識別するステップと、
   前記アプリケーションサービスに関連するトラフィックネットワークポリシーを取得するステップと、
   前記トラフィックネットワークポリシーに基づくネットワークアクセストークンを取得するステップであって、前記ネットワークアクセストークンが、前記デバイスに向けられているユーザプレーントラフィックの中で前記ゲートウェイデバイスにおいて取得されたダウンリンクデータパケットの検証および/またはマッピングを容易にする、ステップと、
   制御プレーンシグナリングの中で前記ネットワークアクセストークンをエンティティへ送るステップと
   を含む方法。
2. 前記ゲートウェイデバイスがパケットデータネットワークゲートウェイデバイス(P-GW)である、請求項1に記載の方法。
3. 前記トリガが、アプリケーションサービスに関連する前記トラフィックネットワークポリシーを取得すること、前記トラフィックネットワークポリシーに基づく前記ネットワークアクセストークンを取得すること、および/または制御プレーンシグナリングの中で前記ネットワークアクセストークンを前記エンティティへ送ることのうちの、1つまたは複数を前記ゲートウェイデバイスに実行させるための制御プレーンメッセージを、前記ゲートウェイデバイスにおいて取得するステップを含む、請求項1に記載の方法。
4. 前記制御プレーンメッセージが、
   アプリケーションサービスに関連する前記トラフィックネットワークポリシーを取得すること、前記トラフィックネットワークポリシーに基づく前記ネットワークアクセストークンを取得すること、および/または制御プレーンシグナリングの中で前記ネットワークアクセストークンを前記エンティティへ送ることのうちの、1つまたは複数を実行するための明示的コマンドを含み、または、
   アプリケーションサービスに関連する前記トラフィックネットワークポリシーを取得すること、前記トラフィックネットワークポリシーに基づく前記ネットワークアクセストークンを取得すること、および/または制御プレーンシグナリングの中で前記ネットワークアクセストークンを前記エンティティへ送ることのうちの、1つまたは複数を実行するための暗黙的コマンドを含み、または、
   ベアラセットアップメッセージ、ベアラ活動化メッセージ、および/またはベアラ変更メッセージのうちの1つまたは複数に関連し、または、
   セッション作成要求である、
   請求項3に記載の方法。
5. 前記トリガが、
   前記アプリケーションサービスに向けられている、前記デバイスから送られた第1のデータパケットを、前記ゲートウェイデバイスにおいて取得するステップを含む、
   請求項1に記載の方法。
6. アプリケーションサービスに関連する前記トラフィックネットワークポリシーがポリシーおよび課金ルール機能(PCRF)から取得される、請求項1に記載の方法。
7. 前記トラフィックネットワークポリシーが、
   モバイルネットワークオペレータとアプリケーションサービスプロバイダとの間のサービスレベル合意、および/または
   前記デバイスの加入プロファイルに基づいて規定される、
   請求項1に記載の方法。
8. 前記エンティティがポリシーおよび課金ルール機能(PCRF)であり、前記ネットワークアクセストークンが前記制御プレーンシグナリングの中で前記PCRFへ送られる、請求項1に記載の方法。
9. 前記エンティティがアプリケーション機能であり、前記ネットワークアクセストークンが前記制御プレーンシグナリングの中で、またはポリシーおよび課金ルール機能(PCRF)を経由して前記制御プレーンシグナリングの中で前記アプリケーション機能へ送られる、請求項1に記載の方法。
10. 前記制御プレーンシグナリングの中でアプリケーション識別子(App ID)を前記エンティティへ送るステップをさらに含み、
    前記App IDが、アプリケーションサーバ、前記アプリケーションサービス、ならびに/または前記アプリケーションサーバおよび/もしくは前記アプリケーションサービスに関連するアプリケーション機能のうちの1つまたは複数を識別する、
    請求項1に記載の方法。
11. 前記ネットワークアクセストークンを含む前記ダウンリンクデータパケットを、前記ゲートウェイデバイスにおいてユーザプレーントラフィックの中で取得するステップと、
    1つまたは複数のプロセスを実行するステップであって、
    前記ネットワークアクセストークンを確認し、前記ネットワークアクセストークンから取得されたデータを使用して前記ダウンリンクデータパケットを前記デバイスにマッピングすることであって、前記ネットワークアクセストークンを確認することは、前記ダウンリンクデータパケットから取得されたデータに基づいて第2のネットワークアクセストークンを取得することと、前記ネットワークアクセストークンを前記第2のネットワークアクセストークンと比較することとを含み、前記ネットワークアクセストークンおよび前記第2のネットワークアクセストークンが等しい場合、前記ネットワークアクセストークンの前記確認が成功し、前記第2のネットワークアクセストークンが、前記ダウンリンクデータパケットから取得されたデータ、および前記トラフィックネットワークポリシーに基づくこと、または
    前記ネットワークアクセストークンから取得されたデータを使用して前記ダウンリンクデータパケットを前記デバイスにマッピングすること
    を含む、ステップと、
    前記ネットワークアクセストークンを前記ダウンリンクデータパケットから除去するステップと、
    前記マッピングに従って前記デバイスへ前記ダウンリンクデータパケットを送るステップと
    をさらに含む請求項1に記載の方法。
12. ゲートウェイデバイスであって、
    デバイスに関連するトリガを前記ゲートウェイデバイスにおいて検出するための手段と、
    前記デバイスに関連するアプリケーションサービスを前記トリガの検出に応答して識別するための手段と、
    前記アプリケーションサービスに関連するトラフィックネットワークポリシーを取得するための手段と、
    前記トラフィックネットワークポリシーに基づくネットワークアクセストークンを取得するための手段であって、前記ネットワークアクセストークンが、前記デバイスに向けられているユーザプレーントラフィックの中で前記ゲートウェイデバイスにおいて取得されたダウンリンクデータパケットの検証および/またはマッピングを容易にする、手段と、
    制御プレーンシグナリングの中で前記ネットワークアクセストークンをエンティティへ送るための手段と
    を備えるゲートウェイデバイス。
13. アプリケーションサーバにおいて動作可能な方法であって、
    デバイスにリンクされるとともにアプリケーションサービスにリンクされたネットワークアクセストークンを、ゲートウェイデバイスからの制御シグナリングを介して、前記アプリケーションサーバにおいて取得するステップと、
    前記デバイスに向けたダウンリンクデータパケットを作成するステップと、
    前記ダウンリンクデータパケットを前記ネットワークアクセストークンにマッピングするステップと、
    前記ネットワークアクセストークンを前記ダウンリンクデータパケットの中に含めるステップと、
    前記ネットワークアクセストークンを含む前記ダウンリンクデータパケットを、前記ゲートウェイデバイスを経由してユーザプレーントラフィックの中で前記デバイスへ送るステップと
    を含む方法。
14. アプリケーションサーバであって、
    デバイスにリンクされるとともにアプリケーションサービスにリンクされたネットワークアクセストークンを、ゲートウェイデバイスからの制御シグナリングを介して、前記アプリケーションサーバにおいて取得するための手段と、
    前記デバイスに向けたダウンリンクデータパケットを作成するための手段と、
    前記ダウンリンクデータパケットを前記ネットワークアクセストークンにマッピングするための手段と、
    前記ネットワークアクセストークンを前記ダウンリンクデータパケットの中に含めるための手段と、
    前記ネットワークアクセストークンを含む前記ダウンリンクデータパケットを、前記ゲートウェイデバイスを経由してユーザプレーントラフィックの中で前記デバイスへ送るための手段と
    を備えるアプリケーションサーバ。
15. 1つまたは複数の命令が記憶された非一時的機械可読記憶媒体であって、前記1つまたは複数の命令が、少なくとも1つのプロセッサによって実行されたとき、前記少なくとも1つのプロセッサに、請求項１から１１または１３のうちいずれか一項に記載の前記方法の前記ステップを実行させる、
    非一時的機械可読記憶媒体。