JP2018509090A - サービスｃプレーン手法のためにネットワークトークンを使用する効率的なポリシー実施 - Google Patents

Abstract

デバイスは、制御プレーンシグナリングを使用して、1つまたは複数のアプリケーションに関連付けられるフローを確立する。ゲートウェイデバイスは、制御プレーンシグナリング中にネットワークトークンを求める要求を取得する。ゲートウェイデバイスは、制御プレーンシグナリング中にネットワークトークンを導出し、それをデバイスおよび/またはアクセスノードに送る。デバイスおよび/またはアクセスノードは、ネットワークトークンを取得し、ネットワークトークンは、1つまたは複数のフローのうちの第1のフロー、1つまたは複数のアプリケーションのうちの第1のアプリケーションに関連付けられ、制御プレーンシグナリングを介してデバイスまたはアクセスノード提供される。ネットワークトークンは、デバイスからユーザプレーンにおいて送られるパケットに含まれ得る。ネットワークトークンは、アクセスノードおよび/またはゲートウェイデバイスにおいて暗号関数を使用して確認され、確認の結果に基づいてその宛先に送られ得る。

Description

本出願は、内容が参照により本明細書に組み込まれる、Efficient Policy Enforcement Using Network Access Tokens For Services C-Plane Approachと題する2015年2月24日に出願された米国仮出願第62/120,135号、および2015年8月21日に出願された米国非仮出願第14/832,965号の優先権を主張する。

一態様は、一般にネットワークトークンに関し、より詳細には、パケットステアリングおよび/またはデバイスが許可されたアプリケーションサービスのみにアクセスしていることの確認を容易にするための、データフローに関連付けられるネットワークトークンの導出、提供、および使用に関する。

クライアントデバイスによっては、ネットワークアクセスを有することがあるが、それらのネットワークアクセスは、アプリケーションサービスのセットに限定され得る。一例では、クライアントデバイスのネットワークアクセスは、特定のアプリケーションサービスプロバイダによって提供され得る。クライアントデバイスは、アプリケーションサービスプロバイダによってそのサーバ上で実行されるアプリケーションサービスに限定され得る。別の例では、ネットワークアクセスを有するクライアントデバイスは、所与のアプリケーションサービスに関連付けられるデータの特別の課金または処理(たとえば、サービス品質のビットレート)を可能にする契約の一部であり得る。たとえば、クライアントデバイスは、セルラープロバイダを通じたセルラーサブスクリプションを有することがあり、そのセルラープロバイダは、クライアントデバイスに1つまたは複数の制限を課すことを希望することがある。一例では、今日において、セルラープロバイダとして知られているのではなく、ソーシャルメディアのプロバイダとして知られている会社が、セルラープロバイダとしての役割を果たすことがある。この例では、クライアントデバイスは、会社とのサブスクリプションを有することがある。そのサブスクリプション契約の一部として、クライアントデバイスは、インターネットへのアクセスを得ることがあるが、他のソーシャルメディアサイトを除外して会社のソーシャルメディアサイトを使用することに制限され得る。別の例として、クライアントデバイスは、ストリーミングメディアサービスのプロバイダとのサブスクリプションを有することがある。この例では、契約の一部として、クライアントデバイスは、様々なセルラープロバイダを通じてインターネットへのアクセスを得ることがあるが、(ストリーミングメディアサービスのプロバイダと様々なセルラープロバイダおよび/またはクライアントデバイスのユーザとの間の)契約によって、すべてのストリーミングメディアサービスのためにメディアサービスのプロバイダのサイトを使用することに制限され得る。さらに別の例として、アクセスポイント名(APN)によっては、あるトラフィックのみが、ポリシーまたはサブスクリプションの制限に基づいてクライアントデバイスから送られることを許され得る。

クライアントデバイスがいかなる契約にも違反せず、所与のアプリケーションサービスへのアクセスを提供され、かつ/または合意されたレベルのサービスを提供されるようにするために、アプリケーションサービスに関連してポリシーが定められ得る。そのようなポリシーは、クライアントデバイスから、たとえば、パケットデータネットワーク(たとえば、インターネット)上のサーバの方に送られたアップリンク(UL)パケットに対して実施され得る。

今日では、アプリケーションサービスに関するポリシー実施が、ネットワークへのゲートウェイにおいて発生する。そのようなゲートウェイの一例は、ネットワークコア(たとえば、発展型パケットコア(EPC))とインターネットなどのパケットデータネットワークとの間のゲートウェイとしての働きをするパケットデータネットワークゲートウェイ(P-GW)である。サービスアクセスポリシーの実施では、クライアントデバイスから送られたすべてのULパケットをP-GWが検証する必要があり得るという1つの問題がある。その上、各ULパケットは、特定のベアラを介してその宛先アドレスにステアリングされる必要があり得る。

P-GWにおけるULパケットの検証は、クライアントデバイスが許可されたアプリケーションサービスにのみパケットを送るようにするために必要とされ得る。検証は、P-GWを通過するパケットの宛先アドレスおよびポート番号を確認することを含み得る。さらに、各パケットのソースアドレスを確認することは、(たとえば、許可されていないクライアントデバイスからのパケットが、許可されたクライアントデバイスから来たように見えることによってシステムをだますのを防ぐことによって)スプーフィング防止に有用であり得る。パケットステアリングは、合意されたサービス品質(QoS)が達成されるようにするために必要とされ得る。

現在の手法により、かなりのオーバーヘッドが生じ、処理遅延に起因する転送レイテンシが増大している。現在の手法は、一般に、パケット検査(たとえば、ディープパケット検査、浅いパケット検査)とトラフィックフローテンプレート(TFT)およびサービスデータフロー(SDF)テンプレートとを使用して実現される。P-GWは、ULパケットがサービスに関して定められたTFT/SDFテンプレートに適合することを、各パケットのヘッダを検査することによって確認する。

TFT/SDFテンプレートによって実現された追加のフィルタ処理ルールに対してパケットがテストされる必要があるので、追加のポリシー制御が追加のオーバーヘッドおよび処理遅延を招くことになるため、(たとえば、アプリケーションごとの)きめの細かいポリシー制御は困難である。さらに、TFT/SDFテンプレートの使用は、スポンサー提供の接続に対してスケーラブルではない。様々なサービス(おそらく数年後は数千のサービス)のスポンサーの数が増加すれば、対応する増加した数のTFT/SDFテンプレートを通じてパケットをフィルタ処理するために必要とされる時間が増加することになる。これもやはり、追加のオーバーヘッドおよび処理遅延を招くことになる。

必要とされるのは、パケット検査を補完および/または改善するための選択肢である。

一態様によれば、方法はデバイスにおいて実行可能であり得る。本方法は、制御プレーンシグナリングを使用して、1つまたは複数のアプリケーションに関連付けられる1つまたは複数のフローのセットを確立するステップと、制御プレーンシグナリング中にデバイスにおいて、第1のネットワークトークンを取得するステップとを含み得る。第1のネットワークトークンは、1つまたは複数のフローのセットのうちの第1のフローに関連付けられ、1つまたは複数のアプリケーションのうちの第1のアプリケーションに関連付けられ、制御プレーンシグナリングを介してデバイスに提供され得る。本方法はまた、第1のフローに関連付けられるパケットとともにデバイスから第1のネットワークトークンを送ることを含み得る。いくつかの態様によれば、本方法はまた、第1のフローに関連付けられるデバイスから送られるあらゆるパケットとともに、デバイスから第1のネットワークトークンを送ることを含み得る。第1のネットワークトークンは、ネットワークアクセスポリシーに従って導出され得る。それは、第1のフローにおけるパケットを第1のアプリケーションにステアリングするために使用され得る。

第1のネットワークトークンは、第1のネットワークトークンを求める明示的または暗黙的要求に応答して提供され得る。暗黙的要求は、パケットデータネットワーク(PDN)接続要求メッセージ、専用ベアラアクティブ化要求メッセージ、またはベアラ変更要求メッセージのうちの1つを含み得る。

いくつかの態様によれば、第1のネットワークトークンは、デバイスからゲートウェイデバイスに、インターネットプロトコル(IP)レイヤと媒体アクセス制御(MAC)レイヤとの間のシムレイヤにおけるシムヘッダ、パケットデータコンバージェンスプロトコル(PDCP)ヘッダ、および/またはIPバージョン6(IPv6)において定義されているIP拡張ヘッダにおいて移送され得る。シムヘッダにおいて移送されたとき、第1のネットワークトークンはアクセスノードには透過的であり得る。いくつかの態様によれば、第1のネットワークトークンは、デバイスからアクセスノードに、インターネットプロトコル(IP)レイヤと媒体アクセス制御(MAC)レイヤとの間のシムレイヤにおけるシムヘッダ、および/またはパケットデータコンバージェンスプロトコル(PDCP)ヘッダにおいて移送され得る。

いくつかの態様によれば、制御プレーンシグナリング中にデバイスにおいて、第2のネットワークアクセストークンが取得され得る。第2のネットワークトークンは、第1のトークンを導出した第1のデバイスとは異なる第2のデバイスによって導出され得る。第2のネットワークトークンは、1つまたは複数のフローのセットのうちの第1のフローに関連付けられ、1つまたは複数のアプリケーションのうちの第1のアプリケーションに関連付けられ、制御プレーンシグナリングを介してデバイスに提供され得る。

デバイスは、ネットワークインターフェースと、ネットワークインターフェースに結合された処理回路とを含み得る。処理回路は、制御プレーンシグナリングを使用して、1つまたは複数のアプリケーションに関連付けられる1つまたは複数のフローのセットを確立することと、制御プレーンシグナリング中にデバイスにおいて、ネットワークトークンを取得することとを行うように構成され得、ネットワークトークンは、1つまたは複数のフローのセットのうちの第1のフローに関連付けられ、1つまたは複数のアプリケーションのうちの第1のアプリケーションに関連付けられ、制御プレーンシグナリングを介してデバイスに提供される。

一態様によれば、ゲートウェイデバイスにおいて実行可能な方法は、ゲートウェイデバイスにおいて、クライアントデバイスに関連付けられるデータ接続セットアップ、アクティブ化、または変更に関連付けられる制御プレーンシグナリング中にネットワークトークンを求める要求を取得するステップを含み得る。本方法は、ゲートウェイデバイスにおいて、ネットワークトークンを導出するステップであって、ネットワークトークンが、アクセスポリシーに従ってフローおよびアプリケーションサービスに関連付けられる、ステップと、制御プレーンシグナリングを介して、ネットワークトークンをクライアントデバイスに、またはクライアントデバイスに関連付けられるアクセスノードに制御プレーンシグナリング中に送るステップとをさらに含み得る。ネットワークトークンは、ゲートウェイデバイスを通じてネットワークを介して送信する間にクライアントデバイスとアプリケーションサービスとの間で移行するパケットをステアリングするために使用され得る。ネットワークトークンを求める要求は、明示的であり得る。ネットワークトークンを求める要求は、暗黙的であり得る。要求は、ゲートウェイデバイスにおいてパケットデータネットワーク(PDN)接続要求、専用ベアラアクティブ化要求、またはベアラ変更要求を取得すると、暗黙的に認識され得る。

一態様によれば、ネットワークトークンの導出は、クライアントデバイスが接続されるアクセスノードに固有の秘密鍵に基づき得る。そのような態様による方法は、アクセスノードに秘密鍵を送るステップを含み得る。

一態様によれば、ネットワークトークンは、アップリンクネットワークトークンおよびアップリンクネットワークトークンとは異なるダウンリンクネットワークトークンとして導出され得る。アップリンクネットワークトークンの導出は、ゲートウェイデバイスに知られている鍵に、かつクライアントデバイスに関連付けられるパラメータに基づき得る。ダウンリンクネットワークトークンの導出は、ゲートウェイデバイスに知られている鍵に、かつアプリケーションサーバに関連付けられるパラメータに基づき得る。そのような態様によれば、本方法は、クライアントデバイスにアップリンクネットワークトークンおよびダウンリンクネットワークトークンを送るステップを含み得る。

一態様によれば、ゲートウェイデバイスは、ネットワークトークンを含む第1のパケットを取得し得る。ゲートウェイデバイスは、パケット検査を使用せずに、第1のパケットとともに含まれるネットワークトークンに関連付けられるデータを使用して、クライアントデバイスとアプリケーションサービスとの間で第1のパケットをステアリングすることができる。ゲートウェイデバイスは、ゲートウェイデバイスに知られている鍵を使用して、ネットワークトークンを確認し得る。ゲートウェイデバイスは、確認が成功しなかった場合に、ネットワークトークンを含む第1のパケットを処分することによって、機能し得る。ゲートウェイデバイスは、確認が成功した場合に、パケット検査を使用せずに、第1のパケットとともに含まれるネットワークトークンを使用して、クライアントデバイスとアプリケーションサービスとの間で第1のパケットをステアリングすることによって、機能し得る。ネットワークトークンを確認することは、ゲートウェイデバイスに知られている鍵と、ネットワークトークンパラメータインデックス、ソースインターネットプロトコル(IP)アドレス、ソースポート番号、宛先IPアドレス、宛先ポート番号、プロトコル識別子(ID)、アプリケーションID、優先度、および/またはサービス品質クラス識別子(QCI)とを含む入力パラメータのセットを有する関数から確認ネットワークトークンを導出することを含み得る。確認は、次いで、ネットワークトークンを確認ネットワークトークンと比較することをさらに含み得る。いくつかの態様では、ネットワークトークンパラメータインデックス、ソースインターネットプロトコル(IP)アドレス、ソースポート番号、宛先IPアドレス、宛先ポート番号、プロトコル識別子(ID)、アプリケーションID、優先度、および/またはサービス品質クラス識別子(QCI)は、パケットから取得される。

いくつかの態様によれば、方法は、ネットワークトークンを確認する前に、ネットワークトークンパラメータインデックスを識別するステップを含み得、ネットワークトークンパラメータインデックスが入力パラメータのリストを定義する。そのような方法はまた、入力として、ゲートウェイデバイスに知られている鍵および入力パラメータのリストを有する関数から確認ネットワークトークンを導出することを含み得る。ネットワークトークンパラメータインデックスは、アプリケーション識別子(ID)を定義し得る。入力パラメータのリストは、ゲートウェイデバイスにおいてテーブルに記憶され得る。ネットワークトークンは、IPヘッダとは別個のシムヘッダにおいて搬送され得る。ネットワークトークンは、汎用パケット無線サービス(GPRS)トンネリングプロトコル(GTP)ヘッダにおいて搬送され得る。ネットワークトークンは、インターネットプロトコル(IP)バージョン6(IPv6)において定義されたIP拡張ヘッダにおいて搬送され得る。

1つの態様によれば、ゲートウェイデバイスは、ネットワークインターフェースと、ネットワークインターフェースに結合された処理回路とを含み得る。処理回路は、クライアントデバイスに関連するデータ接続セットアップ、アクティブ化、または変更に関連付けられる制御プレーンシグナリング中にネットワークトークンを求める要求を取得することと、ネットワークトークンを取得することと、ネットワークトークンが、アクセスポリシーに従ってフローおよびアプリケーションサービスに関連付けられる、取得することと、制御プレーンシグナリングを介して、ネットワークトークンをクライアントデバイスに、またはクライアントデバイスに関連付けられるアクセスノードに制御プレーンシグナリング中に送ることとを行うように構成され得る。

いくつかの態様によれば、アクセスノードにおいて実行可能な方法は、制御プレーンシグナリング中にアクセスノードにおいて、ネットワークトークンを取得するステップを含み得る。ネットワークトークンは、1つまたは複数のフローのセットのうちの第1のフローに関連付けられ、1つまたは複数のアプリケーションのうちの第1のアプリケーションに関連付けられ、制御プレーンシグナリングを介してアクセスノードに提供され得る。本方法はさらに、アクセスノードから、第1のフローに関連付けられるパケットとともにネットワークトークンを送るステップを含み得る。本方法はさらに、アクセスノードから、第1のフローに関連付けられるあらゆるパケットとともにネットワークトークンを送ることを含み得る。ネットワークトークンは、1つまたは複数のアプリケーションに関連付けられる1つまたは複数のフローのセットに関連付けられ得る。

別の態様によれば、アクセスノードにおいて実行可能な方法は、制御プレーンシグナリングにおいて、アクセスノードに固有の秘密鍵をゲートウェイデバイスから取得するステップを含み得る。本方法は、ユーザプレーンシグナリングにおいて、クライアントデバイスからアクセスノードにおいてパケットを取得するステップをさらに含み得、パケットがネットワークトークンを含む。アクセスノードは、ゲートウェイデバイスから取得されたアクセスノードに固有の秘密鍵を使用して、ネットワークトークンを確認し、ネットワークトークンが確認された場合に、ゲートウェイデバイスにパケットおよびネットワークトークンを送るか、またはネットワークトークンが確認されなかった場合に、パケットおよびネットワークトークンを処分することによって、機能し得る。ネットワークトークンは、汎用パケット無線サービス(GPRS)トンネリングプロトコル(GTP)ヘッダにおいてゲートウェイデバイスに搬送され得る。ネットワークトークンは、パケットデータコンバージェンスプロトコル(PDCP)ヘッダから汎用パケット無線サービストンネリングプロトコルヘッダ(GTPヘッダ)にコピーされ、GTPヘッダにおいてゲートウェイデバイスに搬送され得る。いくつかの態様によれば、ネットワークトークンは、アプリケーションサービスに関連付けられるアクセスポリシーを実施するためのものであり、アクセスノードに固有の秘密鍵は、許可されていないパケットがゲートウェイデバイスに到着するのを防ぐために、アクセスノードにおいて受信されたパケットに含まれるネットワークトークンを、ゲートウェイデバイスにパケットを送る前に検証するためのものである。

1つの態様によれば、アクセスノードは、ネットワークインターフェースと、ネットワークインターフェースに結合された処理回路とを含み得る。処理回路は、制御プレーンシグナリングにおいて、アクセスノードに固有の秘密鍵をゲートウェイデバイスから取得するように構成され得る。処理回路は、ユーザプレーンシグナリングにおいて、クライアントデバイスからアクセスノードにおいてパケットを取得するようにさらに構成され得、パケットがネットワークトークンを含む。処理回路は、またさらに、ゲートウェイデバイスから取得されたアクセスノードに固有の秘密鍵を使用して、ネットワークトークンを確認し、ネットワークトークンが確認された場合に、ゲートウェイデバイスにパケットおよびネットワークトークンを送るか、または、ネットワークトークンが確認されなかった場合に、パケットおよびネットワークトークンを処分するように構成され得る。

いくつかの態様によれば、ゲートウェイデバイスにおいて実行可能な方法は、ゲートウェイデバイスにおいて、アプリケーションサーバからパケットを取得するステップを含み得る。パケットは、ダウンリンクネットワークトークンを含み得る。本方法は、ゲートウェイデバイスに知られている鍵を使用して、ダウンリンクネットワークトークンを確認するステップと、確認が成功しなかった場合にパケットを処分するステップと、確認が成功した場合に、ダウンリンクネットワークトークンを処分し、ダウンリンクネットワークトークンによって表されるパラメータに基づいて、クライアントデバイスにパケットを送るステップとを含み得る。パケットは、インターネットプロトコル(IP)データパケットであり得る。

例示的な動作環境を示す図である。 例示的なアップリンク動作を示す図である。 P-GWによってクライアントデバイスにネットワークトークンが発行され得る例示的な呼フローを示す図である。 P-GWによってアクセスノード(たとえば、eNodeB)にネットワークトークンが発行され得る例示的な呼フローを示す図である。 P-GWがクライアントデバイスにネットワークトークンを発行することができ、また、アクセスノードに固有の秘密鍵をアクセスノードに発行することができる例示的な呼フローを示す図である。 P-GWによってクライアントデバイスに第1のネットワークトークン(たとえば、ネットワークトークン1)が発行され得、クライアントデバイスに関連付けられるアクセスノードによってクライアントデバイスに第1のものとは異なる第2のネットワークトークン(たとえば、ネットワークトークン2)が発行され得る例示的な呼フローを示す図である。 P-GWによってクライアントデバイスに2つのネットワークトークン(たとえば、アップリンクネットワークトークンおよびダウンリンクネットワークトークン)が発行され得る例示的な呼フローを示す図である。 本明細書で説明する一態様によるシステムのユーザプレーンプロトコルスタックの例示的な図である。 本明細書で説明する別の態様によるシステムのユーザプレーンプロトコルスタックの例示的な図である。 本明細書で説明するさらに別の態様によるシステムのユーザプレーンプロトコルスタックの例示的な図である。 本明細書で説明するさらに別の態様によるシステムのユーザプレーンプロトコルスタックの例示的な図である。 本明細書で説明するさらに別の態様によるシステムのユーザプレーンプロトコルスタックの例示的な図である。 本明細書で説明するさらに別の態様によるシステムのユーザプレーンプロトコルスタックの例示的な図である。 ネットワークトークンベースのアプリケーションアクセスをサポートするように適応された例示的なデバイスを示すブロック図である。 デバイスがネットワークトークンを取得し得る例示的な方法である。 デバイスがゲートウェイデバイスからネットワークトークンを取得し、アクセスノードから別個のネットワークトークンを取得し得る例示的な方法である。 トークンベースのアプリケーションアクセスをサポートするように適応された例示的なアクセスノードを示すブロック図である。 アクセスノード(たとえば、eNodeB)においてネットワークトークンをセットアップする(たとえば、ネットワークトークンを導出し、クライアントデバイスにネットワークトークンを提供する)例示的な方法を示す図である。 アクセスノードにおいて実行可能な例示的な方法の流れ図である。 アクセスノードにおいて実行可能な別の例示的な方法の流れ図である。 アクセスノードにおいて実行可能なまた別の例示的な方法の流れ図である。 トークンベースのアプリケーションアクセスをサポートするように適応された例示的なゲートウェイを示すブロック図である。 ゲートウェイ(たとえば、P-GW)においてネットワークトークンをセットアップする(たとえば、ネットワークトークンを導出し、クライアントデバイスにネットワークトークンを提供する)例示的な方法を示す図である。 ゲートウェイ(たとえば、P-GW)においてアップリンクおよびダウンリンクネットワークトークンをセットアップする例示的な方法を示す図である。 ゲートウェイにおいて実行可能な例示的な方法の流れ図である。

以下の説明では、例として、本開示が実施され得る具体的な実施形態が示されている添付の図面を参照する。実施形態は、本発明を当業者が実施できるようにするために、本開示の態様を十分に詳細に説明することを意図するものである。本開示の範囲から逸脱することなしに、他の実施形態が利用されてよく、また開示された実施形態に変更が行われてよい。以下の詳細な説明は限定的な意味に解釈されるべきではなく、本発明の範囲は添付の特許請求の範囲によってのみ定義される。

「デバイス」という用語は、チップ構成要素および/またはクライアントデバイス、とりわけ、「モバイルデバイス」、「携帯電話」、「モバイル通信デバイス」、「モバイルコンピューティングデバイス」、「デジタルタブレット」、「スマートフォン」、「ユーザ機器」、「ユーザデバイス」、「端末」などを指すために本明細書において使用され得る。

動作環境
図1は、例示的な動作環境100を示す。そのような例示的な動作環境100では、1つまたは複数のクライアントデバイス102、104(たとえば、クライアントデバイスA、クライアントデバイスB)がアクセスノード106(たとえば、Node B、eNodeB、アクセスポイント(AP))とワイヤレスに通信することができる。アクセスノード106は、無線アクセスネットワーク(RAN)108(たとえば、発展型ユニバーサル地上波無線アクセスネットワーク(E-UTRAN))内に含まれ得る。当業者に知られているように、RAN108は通常、2つ以上のアクセスノード106を含む。図面の散乱を減らすために、たった1つのアクセスノード106が示されている。セルラー通信システム(たとえば、4G、LTE、LTE-A)の非限定的な例では、RAN108は、制御信号およびデータトラフィックをコアネットワーク(CN)110(たとえば、発展型パケットコア(EPC))に通信することができる。図1の図では、破線は制御信号経路を表し、実線はデータトラフィック経路を表す。制御信号は、制御プレーンを介して伝達されると考えられている。ユーザデータは、ユーザプレーンを介して伝達されると考えられている。

CN110は、モビリティ管理エンティティ(MME)112、サービングゲートウェイ(S-GW)116、ホーム加入者サーバ(HSS)118、およびパケットデータネットワークゲートウェイ(P-GW)120を含み得る。P-GW120は、パケットデータネットワーク(PDN)122(たとえば、インターネット)と通信し得る。より詳細には、P-GW120は、PDN122におけるサーバ124、126、128、130(たとえば、アプリケーションサーバ)と通信し得る。サーバ124、126、128、130は、たとえば、販売サービス、情報サービス、ストリーミングビデオサービス、およびソーシャルメディアサービスを提供するサービスプロバイダなどの、サービスプロバイダに関連付けられ得る。

図2は、例示的なアップリンク動作200を示す。例示的なアップリンク動作200は、便宜のためにロングタームエボリューション(LTE)システムのコンテキストにおいて提示されている。例は、本明細書で説明する任意の態様の範囲に何らかの制限を課すものではない。

図2には、クライアントデバイス202(たとえば、ユーザ機器、ユーザデバイス、端末、モバイルデバイス)、アクセスノード204(たとえば、eNodeB)、サービングゲートウェイ(S-GW)206、パケットゲートウェイ(P-GW)208、およびパケットデータネットワーク(PDN)210(たとえば、インターネット)が表されている。

図2の例示的なアップリンク動作200について、ここで説明する。(たとえば、クライアントデバイス202のアプリケーション/アプリケーションサービス212からの)IPフロー214が、トラフィックフローテンプレート(TFT)216とともに含まれるパケットフィルタ(図示せず)に適用される。図示されるIPフロー214の数は、例示的なものであり、限定するものではない。

TFT216のパケットフィルタは、ベアラ218(たとえば、発展型パケットシステム(EPS)ベアラ)へのIPフローをフィルタ処理する。3つのベアラ218(たとえば、ベアラ1、ベアラN-1、およびベアラN)は、例示のために示されている。一態様では、ベアラは、複数のアプリケーション/アプリケーションサービスによって共有され得る。各ベアラは、パラメータの一意のセットに関連付けられ得る。

IPフロー214は、たとえば、デフォルトベアラに、または1つもしくは複数の専用ベアラにマッピングされ得る。デフォルトベアラは通常、保証されていないビットレートを有し得る一方、専用ベアラは通常、保証されたビットレートまたは保証されていないビットレートのいずれかを有し得る。ベアラは、アクセスノード204およびS-GW206を通過し得る。アクセスノード204およびS-GW206の態様は、本明細書で説明されないが、当業者には知られている。

一態様では、ベアラ218からのIPフロー214は、決定および処理回路/機能/モジュール220に渡され得る。決定および処理回路/機能/モジュール220により、ベアラ218から受信されたULパケットは暗号-検証およびトラフィックステアリング回路/機能/モジュール222に、またはサービスデータフロー(SDF)テンプレート224およびその中に含まれるパケットフィルタ(図示せず)に渡され得る。

ネットワークトークンを伴うULパケットが、暗号-検証およびトラフィックステアリング回路/機能/モジュール222に渡され得る。ネットワークトークンに関連付けられる1つまたは複数のポリシーの実施が、ネットワークトークンの検証が成功すると実行され得る。

ネットワークトークンを伴わないULパケットが、決定および処理回路/機能/モジュール220によってSDFテンプレート224に渡され得る。SDFテンプレート224のパケットフィルタの使用は、暗号-検証およびトラフィックステアリング回路/機能/モジュール222の使用が必要とするよりも多くの処理およびメモリリソースを必要とし得る。SDFテンプレート224のパケットフィルタを使用してフィルタ処理を実行するために、たとえば、P-GW208は、SDFごとに別個のテーブルエントリを維持しなければならない。

したがって、ネットワークトークンの使用(および、結果として生じる、暗号-検証およびトラフィックステアリング回路/機能/モジュール222の使用)により、リソースを節約し、レイテンシを低減する。一態様では、暗号ネットワークトークン(たとえば、ソフトウェアトークン)が、パケット検査を補完/改善するために使用され得る。この態様の1つの利点は、スケーラビリティを含む。すなわち、テーブルエントリまたは状態が高速経路(fast-path)(高速パス(fast-pass)とも呼ばれる)上で維持される必要はない。この態様の別の利点は、低レイテンシを含む。すなわち、単一の暗号化演算(たとえば、ハッシュまたは高度暗号化規格(AES:advanced encryption standard)のうち、より速く実行されるか、または適切と判断される方)が、アクセス制御に十分であり得る。

さらに別の利点は、柔軟性を含み得る。すなわち、暗号ネットワークトークンは、様々なメタデータに基づいて導出され得る。そのようなメタデータは、TFT/SDFテンプレートにおいてフィルタ処理されているパラメータに限定されない。さらに、様々なポリシー(たとえば、真正性ポリシー、および/またはパケットポリシーの許可)がネットワークトークンに適用され得る。さらにまた別の利点は、分散型サービス妨害(DDoS)攻撃に対する耐性を含み得る。すなわち、誤った/不適当な/真正ではない暗号ネットワークトークンを含むいかなるパケットも、サーバ(たとえば、図1のサーバ124、126、128、130)に送られる前にドロップされ、それによって、サーバがパケットでいっぱいになるのを防ぐことができる。さらにまた別の利点は、再配置可能性の特徴にあり得る。この利点の実現は、第1のゲートウェイにおいて対応する秘密鍵へのフィルタ処理ルール(またはルールのセット)を定義/マッピングし、次いで第2のゲートウェイと秘密鍵を共有することによって理解され得る。したがって、第1のゲートウェイと第2のゲートウェイとの間のハンドオーバ中、態様は、秘密鍵の転送/共有を介したSDFフィルタの再配置を可能にする。これにより、所与のSDFフィルタに関連付けられるフィルタ処理ルール(またはルールのセット)に関するデータのすべてを転送する必要がなくなる。したがって、再配置可能性の利点は、他の目的のためにデータのすべてを転送するために使用されていたかもしれない処理リソースを解放する。

概要
1つの特徴は、一般に、ゲートウェイデバイスなどのデバイスによるネットワークトークンの導出に関する。ネットワークトークンは、本明細書ではトークン、ネットワークトークン、または暗号ネットワークトークンと呼ばれ得る。ネットワークトークンは、アプリケーションおよびクライアントデバイスに関連付けられるネットワークポリシーを反映するサブスクリプションプロファイルに基づき得る。いくつかの態様では、ネットワークトークンは、ゲートウェイデバイスによって導出され得、ゲートウェイデバイスによってのみ確認され得る。ネットワークトークンは、アプリケーションサービスとクライアントデバイス(たとえば、モバイルデバイス、ユーザ機器、ユーザデバイス)との間のデータフローに関連付けられ得る。ゲートウェイデバイスは、クライアントデバイスにネットワークトークンを提供し得る。クライアントデバイスは、ゲートウェイデバイスを介してアプリケーションサービスに送られる1つまたは複数のデータパケットにネットワークトークンを含めることができる。ゲートウェイデバイスは、1つまたは複数のパケットの各々に関連付けられるネットワークトークンを確認することができ、ネットワークトークンに関連付けられる情報を使用して、アプリケーションサービスにパケットをステアリングすることができる。ここで、ネットワークトークンに関する例示的な態様に関連して、2つの広範なプロセスを例示する。

第1のプロセスは、ネットワークトークンの「セットアップ」に関する。セットアップは、制御プレーン(Cプレーン)におけるシグナリング/メッセージングのいずれかを介したネットワークトークンの導出および提供を伴い得る。以下では、Cプレーンにおけるシグナリングまたはメッセージングを介したネットワークトークンの確立の非限定的な例を提供する。

第2のプロセスは、ネットワークトークンの使用、およびネットワークトークンを使用するポリシーの実施に関する。使用および/または実施は、1つまたは複数のULパケットにネットワークトークンを含めることを伴ってよく、パケットにネットワークトークンを含めることは、たとえば、クライアントデバイス(たとえば、クライアントデバイス202、図2)および/またはアクセスノード(たとえば、アクセスノード204、図2)において発生し得る。トークンは、パケットに追加されること、またはさもなければそれに関連付けられることがある。使用および/または実施はさらに、ネットワークトークンの検証のネットワーク機能を伴い得る。ネットワークトークンの検証は、たとえば、P-GW(たとえば、P-GW208、図2)において起こり得る。いくつかの態様では、クライアントデバイスに送られたネットワークトークンを導出したP-GWは、クライアントデバイスから受信されたネットワークトークンを検証するP-GWとなる。言い換えれば、いくつかの態様では、トークンを導出するノード(たとえば、P-GW)は、トークンを検証することもできる唯一のノードである。検証は必ずしもフィルタ処理の必要性を伴うとは限らない。単一の暗号化演算(たとえば、ハッシュ、AES)が実施され得る。TFT/SDFテンプレートとともにパケット検査を使用するときに必要とされるメモリルックアップは、必要ではないことがある。

本明細書では、通信システムにおけるアクセス/承認制御の既知の方法を補完するために、またはそのような方法の代替として暗号ネットワークトークンを利用する方法およびデバイスの例を提示する。ゲートウェイ(たとえば、P-GW)は、暗号ネットワークトークンを使用して、フロー状態を維持することなく、許可されていないトラフィックをフィルタ処理すること(すなわち、ステートレスフィルタ)ができる。さらに、クライアントデバイスは、暗号ネットワークトークンを使用して、1つまたは複数のULパケットを合意されたデータフロー(たとえば、ベアラ)に関連付け、許可された宛先にパケットをステアリングすることができる。他のアクセス制御ルールがネットワークトークンに含まれること、またはネットワークトークンに関連付けられることもある。

本明細書では、パケットデータネットワーク(PDN)におけるパケットのアクセス/承認およびトラフィックフローのためのトークンをセットアップする例示的な方法について説明する。トークンのセットアップに続いて、ネットワークトークンの確認によるアクセス/承認ポリシーの実施の例示的な方法について、本明細書で説明する。基本暗号アルゴリズム(たとえば、ハッシュ、AES)が使用され得る。今日の方法とは対照的に、アクセス/承認ポリシーを実施するためにメモリルックアップが必要とされることはない。

データフロー
本明細書で説明する態様では、IPフロー、データフロー、またはフローは、図2の例示的な図に提示されたようなベアラに限定される必要はない。クライアントデバイスは、1つまたは複数のアプリケーションを動作させること、または実行することができる。各クライアントアプリケーションは、アプリケーションサーバ上で動作するか、または実行されるアプリケーションサービスにマッピングされ得る。したがって、フローは、デバイスにおいて動作しているアプリケーションに、かつアプリケーションサーバに基づいて定義され得る。フローは、クライアントデバイスにおいて実行されているアプリケーションとアプリケーションサーバにおいて実行されているアプリケーションサービスとの間でパケットがたどる経路と定義され得る。フローは、クライアントデバイス上で動作しているアプリケーションに関連付けられ得るが、フローは、必ずしもクライアントデバイスを識別するとは限らない。ネットワークトークンは、1つまたは複数のフローを識別するために使用され得る。したがって、ネットワークトークンは複数のフローに関連付けられ得る。

1つのフローは、ネットワークにおいて同じサーバ上で実行されている複数のサービスにマッピングされ得る。たとえば、クライアントデバイスは、サーバ上の1つのプロバイダによって提供された1つのサービスを使用することができる。サーバは通常、1つのIPアドレスを有する。ただし、サービスは、サーバ上の複数のアプリケーションをホストし得る。複数のアプリケーションは、たとえば、マッピングアプリケーション、情報探索アプリケーション、およびソーシャルネットワーキングアプリケーションを含み得る。したがって、複数のアプリケーションは、同じ宛先IPアドレスを有するので、コアネットワークのゲートウェイ(たとえば、P-GW)の観点からは、複数のアプリケーションは、複数のフローの代わりに単一のフローと見なされ得る。したがって、単一のフローは複数のサービスにマッピングされ得る。

フローは複数のサービスに関連付けられ得る。また、ネットワークトークンも複数のサービスに関連付けられ得、サービスが、複数のアプリケーションサービスプロバイダによって実行され得る。たとえば、クライアントデバイスは、複数のスポンサー(たとえば、複数のサービスプロバイダ)を有し得る。本明細書で説明する態様では、ゲートウェイは、複数のアプリケーションサービスプロバイダに関連付けられるネットワークトークンを導出し得る。結果として、単一のトークンが1つまたは複数のアプリケーションサービスにマッピングされ得、そして1つまたは複数のアプリケーションサービスは1つまたは複数のフローに関連付けられる。

本明細書で提供するいくつかの例では、アプリケーション識別子(App ID)に基づいてネットワークトークンが導出され得る。ただし、ネットワークトークンの導出は、そのような例に限定されない。他のパラメータ、およびパラメータの組合せも、ネットワークトークンを導出するために使用され得る。App IDは、1つまたは複数のサーバに関連付けられ得る。たとえば、所与のサービスプロバイダは、異なる地理的領域に異なるデータセンター(各々がそれ自体のサーバを有する)を有し得る。そのような場合、App IDは2つ以上のサーバに関連付けられる。トークンは、サーバIPアドレスの代わりにApp IDを有利に使用し得る。ネットワークトークンが宛先サーバのIPアドレスを指定しなくても、ネットワークトークンに関連付けられるパケットが所与のサービスプロバイダのサーバに向かって進んでいることを、ゲートウェイは確認することができる。

トークンセットアップ-例示的なシステムレベル呼フロー
本明細書に記載する例は、(デフォルトベアラがセットアップされ得る)初期PDN接続要求手順に、また(1つまたは複数の専用ベアラがセットアップされ得る)専用ベアラセットアップ手順に当てはまり得る。

図3は、P-GW310によってクライアントデバイス302にネットワークトークンが発行され得る例示的な呼フロー300を示す図である。呼フローは、Cプレーンにおいて実施され得る。アクセスノード304(たとえば、eNodeB)はアグノスティックであり得る。すなわち、アクセスノード304は、クライアントデバイス302がP-GW310にネットワークトークンを求める要求を送ったことを知らなくてよい。ネットワークトークンの要求および交換は、アグノスティックなアクセスノード304には透過的であり得る。図3は、クライアントデバイス302、アクセスノード304、MME306、S-GW308、P-GW310、ポリシーおよび課金ルール機能(PCRF:policy and charging rules function)312サーバ、ならびにホーム加入者サーバ(HSS)314の図を含む。

図3の例示的な呼フロー300では、クライアントデバイス302が、全般的に接続を確立するための、またはサービスとの接続を確立するためのステップを行うことができる。一態様では、クライアントデバイス302は、MME306にPDN接続要求を送る316ことができる。接続を確立するためにクライアントデバイス302によって行われるステップに関連して、ネットワークトークンを求める要求が暗黙的に認識され得る。たとえば、クライアントデバイス302のPDN接続要求に関連して、ネットワークトークンを求める要求が暗黙的に認識され得る。代替的に、クライアントデバイスから送られる接続要求に、ネットワークトークンを求める要求が明示的に含まれ得る。たとえば、PDN接続要求とともに、ネットワークトークンを求める要求が明示的に含まれ得る。ネットワークトークンを求める要求は、アプリケーション識別子(App ID)を含み得る。また別の選択肢として、クライアントデバイス302はネットワークトークンを要求しなくてよいが、ネットワークトークンはCプレーンにおいて割り当てられ得る。たとえば、別のノード、または何らかのポリシーが、ネットワークトークンの使用を必要とすることがある。そのような代替態様では、クライアントデバイス302がネットワークトークンを要求しなくても、ネットワークトークンが制御プレーンにおいてクライアントデバイスに提供され得る。

PDN接続要求の受信に応答して、MMEは、S-GW308にセッション生成要求を送る318ことができる。ネットワークトークンを求める要求は、セッション生成要求にコピーされること、またはさもなければセッション生成要求とともに含まれることがある。ネットワークトークンを求める要求はまた、アプリケーション識別子(App ID)を含み得る。

セッション生成要求の受信に応答して、S-GW308は、P-GW310にセッション生成要求を送る320ことができる。ネットワークトークンを求める要求は、セッション生成要求にコピーされること、またはさもなければセッション生成要求とともに含まれることがある。ネットワークトークンを求める要求はまた、アプリケーション識別子(App ID)を含み得る。

セッション生成要求の受信に応答して、P-GW310は、IP接続性アクセスネットワーク(IP-CAN)の確立/変更のためのステップを実行する324ことができる。当業者に知られているように、IP-CANは、インターネットプロトコル(IP)接続をもたらすアクセスネットワークである。この用語は、セルラーネットワーク(たとえば、3GPPネットワーク)ならびにワイヤレスローカルエリアネットワーク(WLAN)(たとえば、WiFi、HotSpotなど)に当てはまり得る。

また、ネットワークトークンを求める要求の受信に応答して、P-GW310は、ネットワークトークンを取得または導出する326ことができる。本明細書で使用する「導出する」という用語は、ローカルに導出することまたは別のデバイスから取得することを意味し得る。ネットワークトークンは、パケットに関連付けられる入力パラメータのハッシュであり得る。一態様では、パケットの入力パラメータを使用してトークンを再作成し、次いで再作成されたトークンを、パケットとともに含まれているトークンと比較することによって、P-GW310においてネットワークトークンが検証され得る。P-GW310に知られている秘密鍵が、ネットワークトークンを導出するために暗号関数において使用され得る。一例では、P-GW310は、アプリケーション機能(AF)から取り出されたアプリケーションアクセスポリシーに鑑みてネットワークトークンを導出し得る。一態様では、アクセスポリシーは、アプリケーションにフローを結び付けることができる。ネットワークトークンはさらに、たとえば、ネットワークトークンを求める要求とともにApp IDが含まれている場合に、App IDに鑑みて導出され得る。いくつかの態様では、ネットワークトークンは、暗号化された情報を含み得る。解読は、入力として一例ではP-GW310に知られている秘密鍵を有する暗号関数を使用して達成され得る。例として、ネットワークトークンの解読の成功により、ネットワークトークンを含んでいたULパケットに関連して、サーバおよび/もしくはアプリケーションサービスの宛先アドレスならびに/またはULパケットの発生源であったクライアントデバイスおよび/もしくはアクセスノードのソースアドレスを示し得る値が生じ得る。一態様では、たとえば、ネットワークトークンからサーバおよび/またはアプリケーションサービスの宛先アドレスを取得する能力は、トークンに関連するパケットがその宛先に送られることが許可されることを意味し得、SDFテンプレート224(およびそれらの関連付けられるパケットフィルタ)が必要とされないことをさらに意味し得る。したがって、パケット検査は回避され得る。P-GW310は、次のようにクライアントデバイス302にネットワークトークンを発行することができる。

P-GW310は、S-GW308にセッション生成応答を送る328ことができる。P-GW310は、S-GW308に送られるセッション生成応答にネットワークトークンを含めることができる。セッション生成応答に応答して、S-GW308は、MME306にセッション生成応答を送る330ことができる。S-GW308は、MME306に送られるセッション生成応答にネットワークトークンを含めることができる。セッション生成応答に応答して、MME306は、アクセスノード304にベアラセットアップ要求/PDN接続受け入れを送る332ことができる。MME306は、アクセスノード304に送られるベアラセットアップ要求/PDN接続受け入れにネットワークトークンを含めることができる。ベアラセットアップ要求/PDN接続受け入れに応答して、アクセスノード304はクライアントデバイスにRRC接続再構成を送る334ことができる。アクセスノード304は、クライアントデバイスに送られるRRC接続再構成にネットワークトークンを含めることができる。クライアントデバイス302は、アクセスノード304から受信されたRRC接続再構成とともに含まれていたネットワークトークンを受信することができる。

クライアントデバイス302がネットワークトークンを有すると、クライアントデバイス302は、アプリケーションサービスへのデータ送信のために構成された1つまたは複数のULパケットとともにネットワークトークンを含めることができる。

図4は、P-GW410によってアクセスノード(たとえば、eNodeB)404にネットワークトークンが発行され得、クライアントデバイス402がネットワークトークンを受信しないことがある例示的な呼フロー400を示す図である。ここでは、クライアントデバイス402はアグノスティックと見なされ得る。すなわち、この例によれば、クライアントデバイス402は、アプリケーションサービスを対象にした1つまたは複数のULパケットにネットワークトークンを含めるエンティティではないことがある。呼フローは、Cプレーンにおいて実施され得る。図4は、クライアントデバイス402、アクセスノード404、MME406、S-GW408、P-GW410、PCRF412、およびHSS414の図を含む。

図4の例示的な呼フローでは、クライアントデバイス402が、全般的に接続を確立するための、またはサービスとの接続を確立するためのステップを行うことができる。一態様では、クライアントデバイス402は、MME406にPDN接続要求を送る416ことができる。接続を確立するためにクライアントデバイス402によって行われるステップに関連して、ネットワークトークンを求める要求が暗黙的に認識され得る。たとえば、クライアントデバイス402のPDN接続要求に関連して、ネットワークトークンを求める要求が暗黙的に認識され得る。代替的に、クライアントデバイス402の接続要求に、ネットワークトークンを求める要求が明示的に含まれ得る。たとえば、PDN接続要求とともに、ネットワークトークンを求める要求が明示的に含まれ得る。ネットワークトークンを求める要求は、アプリケーション識別子(App ID)を含み得る。また別の選択肢として、クライアントデバイス402はネットワークトークンを要求しなくてよいが、ネットワークトークンはCプレーンにおいて割り当てられ得る。

PDN接続要求の受信に応答して、MME406は、S-GW408にセッション生成要求を送る418ことができる。ネットワークトークンを求める要求は、セッション生成要求にコピーされること、またはさもなければセッション生成要求とともに含まれることがある。ネットワークトークンを求める要求は、アプリケーション識別子(App ID)を含み得る。

セッション生成要求の受信に応答して、S-GW408は、P-GW410にセッション生成要求を送る420ことができる。ネットワークトークンを求める要求は、セッション生成要求にコピーされること、またはさもなければセッション生成要求とともに含まれることがある。ネットワークトークンを求める要求は、アプリケーション識別子(App ID)を含み得る。

セッション生成要求の受信に応答して、P-GW410は、IP-CANセッションの確立/変更のためのステップを実行する424ことができる。また、ネットワークトークンを求める要求の受信に応答して、P-GW410は、ネットワークトークンを導出する426ことができる。P-GW410に知られている秘密鍵が、ネットワークトークンを導出するために暗号関数において使用され得る。一例では、P-GW410は、アプリケーション機能(AF)から取り出されたアプリケーションアクセスポリシーに鑑みてネットワークトークンを導出し得る。一態様では、アクセスポリシーは、アプリケーションにフローを結び付けることができる。ネットワークトークンはさらに、たとえば、ネットワークトークンを求める要求とともにApp IDが含まれている場合に、App IDに鑑みて導出され得る。P-GW410は、次のようにアクセスノード404にネットワークトークンを発行することができる。

P-GW410は、S-GW408にセッション生成応答を送る428ことができる。P-GW410は、S-GW408に送られるセッション生成応答にネットワークトークンを含めることができる。セッション生成応答に応答して、S-GW408は、MME406にセッション生成応答を送る430ことができる。S-GW408は、MME406に送られるセッション生成応答にネットワークトークンを含めることができる。セッション生成応答に応答して、MME406は、アクセスノード404にベアラセットアップ要求/PDN接続受け入れを送る432ことができる。MME406は、アクセスノード404に送られるベアラセットアップ要求/PDN接続受け入れにネットワークトークンを含めることができる。この例示的な方法では、アクセスノード404は、P-GW410からネットワークトークンを取得することができる。

呼フローは続くことができる。たとえば、ベアラセットアップ要求/PDN接続受け入れに応答して、アクセスノード404はクライアントデバイス402にRRC接続再構成を送る434ことができる。この第2の例では、アクセスノード404は、クライアントデバイス402へのRRC接続再構成にネットワークトークンを含めなくてよい。

アクセスノード404がネットワークトークンを有すると、アクセスノード404は、アプリケーションサービスへのデータ送信のために構成された各ULパケットとともにネットワークトークンを含めることができる。

図5は、P-GW510がクライアントデバイス502にネットワークトークンを発行することができ、また、アクセスノード504に固有の秘密鍵をアクセスノード504に発行することができる例示的な呼フロー500を示す図である。アクセスノード504に固有の秘密鍵は、P-GW510によって保持される秘密鍵、および、たとえば、アクセスノード504の識別子の関数であり得る。この第3の例示的な呼フロー500の実施により、アクセスノード504が、クライアントデバイス502から受信された1つまたは複数のULパケットとともに含まれるネットワークトークンを、コアネットワークにULパケットを(それらの含まれているネットワークトークンとともに)転送する前に確認することが可能になり得る。これは、「ファーストマイルフィルタ処理(first-mile filtering)」動作を容易にすることができ、この動作では、使用/実施プロセス(本明細書で後述する)中、アクセスノード504は、受信されたネットワークトークンに関する暗号関数およびアクセスノード504に固有の秘密鍵に基づいてULパケットを確認する権限を与えられ得る。これにより、「信頼できる」アクセスノード504は、クライアントデバイス502から受信された許可されていないULパケットを、パケットがコアネットワークに送られる前に処分することが可能になり得る。呼フローは、Cプレーンにおいて実施され得る。図5は、クライアントデバイス502、アクセスノード504、MME506、S-GW508、P-GW510、PCRF512、およびHSS514の図を含む。

図5の例示的な呼フロー500では、クライアントデバイス502が、全般的に接続を確立するための、またはサービスとの接続を確立するためのステップを行うことができる。一態様では、クライアントデバイス502は、MME506にPDN接続要求を送る516ことができる。接続を確立するためにクライアントデバイス502によって行われるステップに関連して、ネットワークトークンを求める要求が暗黙的に認識され得る。たとえば、クライアントデバイス502のPDN接続要求に関連して、ネットワークトークンを求める要求が暗黙的に認識され得る。代替的に、クライアントデバイス502から送られる接続要求に、ネットワークトークンを求める要求が明示的に含まれ得る。たとえば、PDN接続要求とともに、ネットワークトークンを求める要求が明示的に含まれ得る。ネットワークトークンを求める要求は、アプリケーション識別子(App ID)を含み得る。また別の選択肢として、クライアントデバイス502はネットワークトークンを要求しなくてよいが、ネットワークトークンはCプレーンにおいて割り当てられ得る。

PDN接続要求の受信に応答して、MME506は、S-GW508にセッション生成要求を送る518ことができる。ネットワークトークンを求める要求は、セッション生成要求にコピーされること、またはさもなければセッション生成要求とともに含まれることがある。ネットワークトークンを求める要求はまた、アプリケーション識別子(App ID)を含み得る。

セッション生成要求の受信に応答して、S-GW508は、P-GW510にセッション生成要求を送る520ことができる。ネットワークトークンを求める要求は、セッション生成要求にコピーされること、またはさもなければセッション生成要求とともに含まれることがある。ネットワークトークンを求める要求はまた、アプリケーション識別子(App ID)を含み得る。

セッション生成要求の受信に応答して、P-GW510は、IP-CANセッション(項目4)の確立/変更のためのステップを実行する524ことができる。また、ネットワークトークンを求める要求の受信に応答して、P-GW510は、ネットワークトークンを導出する526ことができる。P-GW510によって導出されたアクセスノード504に固有の秘密鍵が、ネットワークトークンを導出するために暗号関数において使用され得る。P-GW510は、アクセスノード504ごとにアクセスノード504に固有の秘密鍵を、P-GW510に知られている秘密鍵(K_NT)からその秘密鍵(K_{NT, eNB})を導出することによって、導出することができる。たとえば、アクセスノード504に固有の秘密鍵は、たとえば、K_NTおよびアクセスノード識別子(たとえば、「eNB ID」)の関数であり得る鍵導出関数(KDF)を使用して導出され得る(すなわち、K_NT,eNB=KDF(K_NT,eNB ID))。このようにして、導出された各ネットワークトークンは、特定のアクセスノード504に関連付けられる(たとえば、結び付けられる)ことがある。一例では、P-GW510は、アプリケーション機能(AF)から取り出されたアプリケーションアクセスポリシーに鑑みてネットワークトークンを導出し得る。一態様では、アクセスポリシーは、アプリケーションにフローを結び付けることができる。ネットワークトークンはさらに、ネットワークトークンを求める要求とともにApp IDが含まれている場合に、App IDに鑑みて導出され得る。P-GW510は、クライアントデバイス502にネットワークトークンを発行することができ、次のようにアクセスノードに固有の秘密鍵(K_NT,eNB)をアクセスノード504に発行することができる。

P-GW510は、S-GW508にセッション生成応答を送る528ことができる。P-GW510は、S-GW508に送られるセッション生成応答にネットワークトークンおよび秘密鍵K_NT,eNBを含めることができる。セッション生成応答に応答して、S-GW508は、MME506にセッション生成応答を送る530ことができる。S-GW508は、MME506に送られるセッション生成応答にネットワークトークンおよび秘密鍵K_NT,eNBを含めることができる。セッション生成応答に応答して、MME506は、アクセスノード504にベアラセットアップ要求/PDN接続受け入れを送る532ことができる。MME506は、アクセスノード504に送られるベアラセットアップ要求/PDN接続受け入れにネットワークトークンおよび秘密鍵K_NT,eNBを含めることができる。したがって、アクセスノード504は、今では秘密鍵K_NT,eNBを取得している。ベアラセットアップ要求/PDN接続受け入れに応答して、アクセスノード504はクライアントデバイス502にRRC接続再構成を送る534ことができる。アクセスノード504は、クライアントデバイス502へのRRC接続再構成にネットワークトークンを含めることができる。クライアントデバイス502は、アクセスノード504から受信されたRRC接続再構成とともに含まれていたネットワークトークンを受信することができる。したがって、クライアントデバイス502は、今ではネットワークトークンを取得している。

クライアントデバイス502がネットワークトークンを有すると、クライアントデバイス502は、アプリケーションサービスへのデータ送信のために構成された1つまたは複数のULパケットとともにネットワークトークンを含めることができる。

図6は、P-GW610によってクライアントデバイス602に第1のネットワークトークン(たとえば、ネットワークトークン1)が発行され得、クライアントデバイス602に関連付けられるアクセスノード604によってクライアントデバイス602に第1のものとは異なる第2のネットワークトークン(たとえば、ネットワークトークン2)が発行され得る例示的な呼フロー600を示す図である。この例は、秘密鍵の共有を伴わないことがある。すなわち、第1のネットワークトークンは、P-GW610にのみ知られている第1の秘密鍵により導出され得、第2のネットワークトークンは、アクセスノード604に知られている第2の秘密鍵により導出され得、第1の秘密鍵と第2の秘密鍵とは異なる。この例は、たとえば、アクセスノード604とP-GW610との間の信頼仮定(trust assumption)が望ましいものとは言えないか、または存在しない状況において、有用であり得る。例示的な呼フロー600は、Cプレーンにおいて実施され得る。図6は、クライアントデバイス602、アクセスノード604、MME606、S-GW608、P-GW610、PCRF612、およびHSS614の図を含む。

図6の例示的な呼フロー600では、クライアントデバイス602が、全般的に接続を確立するための、またはサービスとの接続を確立するためのステップを行うことができる。一態様では、クライアントデバイス602は、MME606にPDN接続要求を送る616ことができる。接続を確立するためにクライアントデバイス602によって行われるステップに関連して、ネットワークトークンを求める要求が暗黙的に認識され得る。たとえば、クライアントデバイス602のPDN接続要求に関連して、ネットワークトークンを求める要求が暗黙的に認識され得る。代替的に、クライアントデバイス602の接続要求に、ネットワークトークンを求める要求が明示的に含まれ得る。たとえば、PDN接続要求とともに、ネットワークトークンを求める要求が明示的に含まれ得る。ネットワークトークンを求める要求は、アプリケーション識別子(App ID)を含み得る。また別の選択肢として、クライアントデバイス602はネットワークトークンを要求しなくてよいが、ネットワークトークンはCプレーンにおいて割り当てられ得る。

PDN接続要求の受信に応答して、MME606は、S-GW608にセッション生成要求を送る618ことができる。ネットワークトークンを求める要求は、セッション生成要求にコピーされること、またはさもなければセッション生成要求とともに含まれることがある。ネットワークトークンを求める要求はまた、アプリケーション識別子(App ID)を含み得る。

セッション生成要求の受信に応答して、S-GW608は、P-GW610にセッション生成要求を送る620ことができる。ネットワークトークンを求める要求は、セッション生成要求にコピーされること、またはさもなければセッション生成要求とともに含まれることがある。ネットワークトークンを求める要求はまた、アプリケーション識別子(App ID)を含み得る。

セッション生成要求の受信に応答して、P-GW610は、IP-CANセッションの確立/変更のためのステップを実行する624ことができる。また、ネットワークトークンを求める要求の受信に応答して、P-GW610は、第1のネットワークトークン(たとえば、ネットワークトークン1)を導出する626ことができる。P-GW610に知られている秘密鍵が、ネットワークトークンを導出するために暗号関数において使用され得る。一例では、P-GW610は、アプリケーション機能(AF)から取り出されたアプリケーションアクセスポリシーに鑑みてネットワークトークンを導出し得る。一態様では、アクセスポリシーは、アプリケーションにフローを結び付けることができる。ネットワークトークンはさらに、ネットワークトークンを求める要求とともにApp IDが含まれている場合に、App IDに鑑みて導出され得る。P-GW610は、次のようにクライアントデバイス602にネットワークトークンを発行することができる。

P-GW610は、S-GW608にセッション生成応答を送る628ことができる。P-GW610は、S-GW608に送られるセッション生成応答にネットワークトークンを含めることができる。セッション生成応答に応答して、S-GW608は、MME606にセッション生成応答を送る630ことができる。S-GW608は、MME606に送られるセッション生成応答にネットワークトークンを含めることができる。セッション生成応答に応答して、MME606は、アクセスノード604にベアラセットアップ要求/PDN接続受け入れを送る632ことができる。MME606は、アクセスノード604に送られるベアラセットアップ要求/PDN接続受け入れにネットワークトークンを含めることができる。

ベアラセットアップ要求/PDN接続受け入れに応答して、アクセスノード604は、第2のネットワークトークン(たとえば、ネットワークトークン2)を導出する633ことができる。アクセスノード604に知られている秘密鍵が、第2のネットワークトークンを導出するために暗号関数において使用され得る。一例では、アクセスノード604は、アプリケーション機能(AF)から取り出されたアプリケーションアクセスポリシーに鑑みて第2のネットワークトークンを導出し得る。一態様では、アクセスポリシーは、アプリケーションにフローを結び付けることができる。第2のネットワークトークンはさらに、ネットワークトークンを求める要求とともにApp IDが含まれている場合に、App IDに鑑みて導出され得る。

また、ベアラセットアップ要求/PDN接続受け入れに応答して、アクセスノード604はクライアントデバイス602にRRC接続再構成を送る634ことができる。アクセスノード604は、クライアントデバイス602に送られるRRC接続再構成に、P-GW610において導出された第1のネットワークトークンを含めることができ、さらに、アクセスノード604において導出された第2のネットワークトークンを含めることができる。したがって、クライアントデバイス602は、アクセスノード604から受信されたRRC接続再構成において、P-GW610において導出された第1のネットワークトークンとアクセスノード604において導出された第2のネットワークトークンの両方を受信することができる。

クライアントデバイス602が、P-GW610において導出された第1のネットワークトークンとアクセスノード604において導出された第2のネットワークトークンの両方を有すると、クライアントデバイス602は、アプリケーションサービスへのデータ送信のために構成されたULパケットとともに、P-GW610において導出された第1のネットワークトークンとアクセスノード604において導出された第2のネットワークトークンの両方を含めることができる。

図7は、P-GW710によってクライアントデバイス702に2つのネットワークトークン(たとえば、ULネットワークトークンおよびダウンリンク(DL)ネットワークトークン)が発行され得る例示的な呼フロー700を示す図である。この例示的な呼フローは、優先度付けおよびフィルタ処理のためのダウンリンク(DL)トークンの使用に関連して有用であり得る。

一態様では、クライアントデバイス702は、PDNにおける所与のアプリケーション/アプリケーションサービス/アプリケーションサーバ宛のパケットとともにULネットワークトークンを含めることができる。一態様では、クライアントデバイス702は、PDNにおける所与のアプリケーション/アプリケーションサービス/アプリケーションサーバから受信されるパケットにおいてDLネットワークトークンを受信することを予想し得る。クライアントデバイス702は、PDNにおけるアプリケーション(APP)715にDLネットワークトークンを送る736ことができ、その点において、PDNにおけるAPP715は、クライアントデバイス702に送る1つまたは複数のパケットにDLネットワークトークンのコピーを含めることが予想され得る。

例示的な呼フロー700は、Cプレーンにおいて実施され得る。図7は、クライアントデバイス702、アクセスノード704、MME706、S-GW708、P-GW710、PCRF712、HSS714、およびPDNにおけるアプリケーション/アプリケーションサービス/アプリケーションサーバ(APP)715の図を含む。

図7の例示的な呼フロー700では、クライアントデバイス702が、全般的に接続を確立するための、またはサービスとの接続を確立するためのステップを行うことができる。一態様では、クライアントデバイス702は、MME706にPDN接続要求を送る716ことができる。接続を確立するためにクライアントデバイス702によって行われるステップに関連して、ネットワークトークンを求める要求が暗黙的に認識され得る。たとえば、クライアントデバイス702のPDN接続要求に関連して、ネットワークトークンを求める要求が暗黙的に認識され得る。代替的に、クライアントデバイス702の接続要求に、ネットワークトークンを求める要求が明示的に含まれ得る。たとえば、PDN接続要求とともに、ネットワークトークンを求める要求が明示的に含まれ得る。ネットワークトークンを求める要求は、アプリケーション識別子(App ID)を含み得る。また別の選択肢として、クライアントデバイス702はネットワークトークンを要求しなくてよいが、ネットワークトークンはCプレーンにおいて割り当てられ得る。

PDN接続要求の受信に応答して、MME706は、S-GW708にセッション生成要求を送る718ことができる。ネットワークトークンを求める要求は、セッション生成要求にコピーされること、またはさもなければセッション生成要求とともに含まれることがある。ネットワークトークンを求める要求はまた、アプリケーション識別子(App ID)を含み得る。

セッション生成要求の受信に応答して、S-GW708は、P-GW710にセッション生成要求を送る720ことができる。ネットワークトークンを求める要求は、セッション生成要求にコピーされること、またはさもなければセッション生成要求とともに含まれることがある。ネットワークトークンを求める要求はまた、アプリケーション識別子(App ID)を含み得る。

セッション生成要求の受信に応答して、P-GW710は、IP-CANセッションの確立/変更のためのステップを実行する724ことができる。また、ネットワークトークンを求める要求の受信に応答して、P-GW710は、ULネットワークトークンを導出する726ことができ、いくつかの態様では、ダウンリンク(DL)ネットワークトークンを導出することができる。P-GW710に知られている秘密鍵が、ULネットワークトークンを導出するために暗号関数において使用され得る。一例では、P-GW710は、アプリケーション機能(AF)から取り出されたアプリケーションアクセスポリシーに鑑みてULネットワークトークンを導出し得る。一態様では、アクセスポリシーは、アプリケーションにフローを結び付けることができる。ULネットワークトークンはさらに、ULネットワークトークンを求める要求とともにApp IDが含まれている場合に、App IDに鑑みて導出され得る。DLネットワークトークンの導出は、P-GW710に知られている鍵に、かつアプリケーションサーバに関連付けられるパラメータに基づき得る。P-GW710は、次のようにクライアントデバイス702にULネットワークトークン、およびいくつかの態様ではDLネットワークトークンを発行することができる。

P-GW710は、S-GW708にセッション生成応答を送る728ことができる。P-GW710は、S-GW708に送られるセッション生成応答にULネットワークトークンを含めることができる。P-GW710はまた、S-GW708に送られるセッション生成応答にDLネットワークトークンを含めることができる。セッション生成応答に応答して、S-GW708は、MME706にセッション生成応答を送る730ことができる。S-GW708は、MME706に送られるセッション生成応答にULネットワークトークンおよびDLネットワークトークンを含めることができる。セッション生成応答に応答して、MME706は、アクセスノード704にベアラセットアップ要求/PDN接続受け入れを送る732ことができる。MME706は、アクセスノード704に送られるベアラセットアップ要求/PDN接続受け入れにULネットワークトークンおよびDLネットワークトークンを含めることができる。

ベアラセットアップ要求/PDN接続受け入れに応答して、アクセスノード704はクライアントデバイス702にRRC接続再構成を送ることができる。アクセスノード704は、クライアントデバイス702へのRRC接続再構成とともにULネットワークトークンおよびDLネットワークトークンを含めることができる。したがって、クライアントデバイス702は、ULネットワークトークンとDLネットワークトークンの両方を受信することができ、両方は、P-GW710において導出されていて、アクセスノード704から受信されたRRC接続再構成においてクライアントデバイス702に配信されていることがある。

いくつかの態様では、クライアントデバイス702は、PDN上のAPP715にDLネットワークトークンを送る736ことができる。次いでAPP715は、ダウンリンクにおいてAPP715からP-GW710に送られる1つまたは複数のダウンリンクパケットとともにDLネットワークトークンを含めることができる。この態様では、P-GW710は、ダウンリンク方向ならびにアップリンク方向でIPフローをより効率的に方向付けることが可能であり得る。元のDLネットワークトークンがP-GW710によって導出されたので、P-GW710は、APP715からパケットとともに受信されたDLネットワークトークンを検証することが可能であり得る。これは、TFT/SDFを使用するダウンリンクパケット検査に代わる有用なものであり得る。

トークン使用/実施-例示的なシステムレベルプロトコルスタック
ここで、上記で説明したネットワークトークンに関連する使用および実施の態様を提示する。

ネットワークトークンの使用について、クライアントデバイス、アクセスノード、ゲートウェイ、およびアプリケーションサーバのユーザプレーンプロトコルスタックの間のネットワークトークンの移動に関して説明することがある。本明細書では、ユーザプレーンプロトコルスタックの例示的なセットを示す6つの図を示す。各図は、プロトコルスタックの間のネットワークトークンの移動の記述が、次の図とは異なる。プロトコルスタックに表されているレイヤの多く、およびレイヤの間の相互接続は、よく知られている。これらのレイヤについて、図8の図に関して簡単に説明する。それらの説明は、繰り返しを回避して本明細書を簡潔にするために、例示的な図ごとには繰り返さない。図のうちの4つは、シムレイヤを含み、シムレイヤは、4つの図によって示されるそれぞれの態様に関連するネットワークトークンの移動に利用されるレイヤと見なされ得る。

図8は、本明細書で説明する一態様によるシステムのユーザプレーンプロトコルスタック800の例示的な図である。図8は、クライアントデバイス802、アクセスノード804、ゲートウェイ806、およびアプリケーションサーバ808を示す。例示的な図である図8では、クライアントデバイス802のプロトコルスタックは、最下位レイヤから上へ、物理(PHY)レイヤ810、媒体アクセス制御(MAC)レイヤ812、無線リンク制御(RLC)レイヤ814、パケットデータコンバージェンスプロトコル(PDCP)レイヤ816、およびインターネットプロトコル(IP)レイヤ818を含み得る。一態様では、ネットワークトークンは、インターネットプロトコル(IP)バージョン6(IPv6)において定義されたIP拡張ヘッダにおいて搬送され得る。

一態様では、シムレイヤ820がクライアントデバイス802のユーザプレーンプロトコルスタックに追加され得、対応するシムレイヤ822がゲートウェイ806のプロトコルスタックに追加され得る。シムレイヤ820および対応するシムレイヤ822は、本明細書で説明する態様による、クライアントデバイス802からゲートウェイ806へのネットワークトークンの移動を容易にする。一態様では、シムレイヤ820は、クライアントデバイス802のIPレイヤ818の下、かつMACレイヤ812の上にある。この態様では、対応するシムレイヤ822は、ゲートウェイ806のIPレイヤ824の下、かつGTP-Uレイヤ826の上にある。

図8によって示される態様は、アクセスノード804によるいかなる処理も必要とすることなく、クライアントデバイス802からゲートウェイ806へのネットワークトークン860の移動に有用であり得る。代替方法も許容できる。例として、クライアントデバイス802は、(図8に示されていない)上記で説明した制御プレーンシグナリング/メッセージセットアップ方法により、ゲートウェイ806からネットワークトークンを受信することがある。ネットワークトークンの使用の一態様によれば、クライアントデバイス802は、アプリケーションサーバ808宛のパケットにネットワークトークンを含めることができる。ネットワークトークン860は、図8に示すようにシムレイヤ820のシムヘッダにおいてゲートウェイ806に搬送され得る。ネットワークトークン860は、IPヘッダとは別個のシムヘッダにおいて搬送され得る。

ゲートウェイ806における(以下で説明する)ネットワークトークンの確認が成功した場合、ゲートウェイ806はネットワークトークンを処分した後、アプリケーションサーバ808にパケットを転送することができる。ゲートウェイ806におけるネットワークトークン860の確認が成功しなかった場合、ゲートウェイ806はパケットおよびネットワークトークンを処分することができる。図示の態様によれば、ネットワークトークンベースのアプリケーションアクセスをサポートするために、アプリケーションサーバ808においていかなる変更も必要とされない。

説明を完全にするために、アクセスノード804、ゲートウェイ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、およびGTP-Uレイヤ848をさらに含み得る。これらのそれぞれのレイヤは、ゲートウェイ806の同様の名称のレイヤ(850、852、854、856、および826)と結び付いている。図8の例示的な図では、クライアントデバイスIPレイヤ818は、ゲートウェイ806のIPレイヤ824と結び付き、ゲートウェイ806のIPレイヤ824は、アプリケーションサーバ808のIPレイヤ858と結び付く。

図9は、本明細書で説明する別の態様によるシステムのユーザプレーンプロトコルスタックの例示的な図である。図9は、クライアントデバイス902、アクセスノード904、ゲートウェイ906、およびアプリケーションサーバ908を示す。

図9によって示される態様は、アクセスノード904を介したクライアントデバイス902からゲートウェイ906へのネットワークトークン960の移動に有用であり得る。この態様では、シムレイヤは必要とされない。例として、クライアントデバイス902は、(図9に示されていない)上記で説明した制御プレーンシグナリング/メッセージセットアップ方法により、ゲートウェイ906からネットワークトークン960を受信することがある。ネットワークトークンの使用の一態様によれば、クライアントデバイス902は、アプリケーションサーバ908宛のパケットにネットワークトークン960を含めることができる。ネットワークトークン960を含むパケットは、PDCPレイヤ916ヘッダにおいてクライアントデバイス902からアクセスノード904のPDCPレイヤ936に搬送され得る。アクセスノード904は、PDCPヘッダにおいて発見されたネットワークトークンを、GTP-Uヘッダにコピーし得る。次いで、ネットワークトークン960を含むパケットは、GTP-Uレイヤ948ヘッダにおいてアクセスノード904からゲートウェイ906のGTP-Uレイヤ926に搬送され得る。すなわち、一態様では、ネットワークトークンは、汎用パケット無線サービス(GPRS)トンネリングプロトコル(GTP)ヘッダにおいて搬送され得る。例示的な一態様では、ゲートウェイ906からクライアントデバイス902に当初送られたネットワークトークンは、ゲートウェイに知られている秘密鍵を使用して作成されていることがある。そのような態様では、アクセスノード904は、(確認に必要な秘密鍵を保有しないので)ネットワークトークンを確認するのが不可能となる。したがって、図9の図におけるアクセスノード904の例示的な目的は、あるヘッダから別のヘッダにネットワークトークンをコピーし、それによって、すでに存在するPDCPレイヤ936ヘッダおよびGTP-Uレイヤ948ヘッダを介してクライアントデバイス902からゲートウェイ906にネットワークトークンを転送することである。ネットワークトークンがゲートウェイに到着すると、ゲートウェイ906における(以下で説明する)ネットワークトークンの確認が成功した場合、ゲートウェイ906はネットワークトークンを処分した後、アプリケーションサーバ908にパケットを転送することができる。ゲートウェイ906におけるネットワークトークン960の確認が成功しなかった場合、ゲートウェイ906はパケットおよびネットワークトークンを処分することができる。図示の態様によれば、トークンベースのアプリケーションアクセスをサポートするために、アプリケーションサーバ908においていかなる変更も必要とされない。

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

図10は、本明細書で説明するさらに別の態様によるシステムのユーザプレーンプロトコルスタックの例示的な図である。図10は、クライアントデバイス1002、アクセスノード1004、ゲートウェイ1006、およびアプリケーションサーバ1008を示す。

図10によって示される態様は、アクセスノード1004からゲートウェイ1006へのネットワークトークン1060の移動に有用であり得る。この態様は、クライアントデバイス1002がアプリケーションサーバ1008上の特定のサービスへのアクセスを制限され、クライアントデバイス1002からゲートウェイ1006にトラフィックを搬送するために確立されたベアラがそのようなもの(たとえば、スポンサー提供の接続)としてセットアップされる場合に、有用であり得る。この態様はまた、クライアントデバイス1002とアクセスノード1004との間、またはクライアントデバイス1002とゲートウェイ1006との間に信頼関係が存在しない場合に有用であり得る。例として、図10によって示される態様では、クライアントデバイス1002は、ゲートウェイ1006からネットワークトークンを受信しない。図10によって示される態様では、アクセスノード1004は、(図10に示されていない)上記で説明した制御プレーンシグナリング/メッセージセットアップ方法により、ゲートウェイ1006からネットワークトークン1060を受信することがある。ネットワークトークンの使用の一態様によれば、アクセスノード1004は、アプリケーションサーバ1008宛のクライアントデバイス1002パケットにネットワークトークン1060を含めることができる。クライアントデバイス1002パケットは、ネットワークトークン1060を含め、GTP-Uレイヤ1048ヘッダにおいてアクセスノード1004からゲートウェイ1006のGTP-Uレイヤ1026に搬送され得る。ネットワークトークンがゲートウェイに到着すると、ゲートウェイ1006における(以下で説明する)ネットワークトークンの確認が成功した場合、ゲートウェイ1006はネットワークトークンを処分した後、アプリケーションサーバ1008にパケットを転送することができる。ゲートウェイ1006におけるネットワークトークン1060の確認が成功しなかった場合、ゲートウェイ1006はパケットおよびネットワークトークンを処分することができる。図示の態様によれば、トークンベースのアプリケーションアクセスをサポートするために、アプリケーションサーバ1008においていかなる変更も必要とされない。

図10に関連して説明していないクライアントデバイス1002、アクセスノード1004、ゲートウェイ1006、およびアプリケーションサーバ1008のユーザプレーンプロトコルスタックのレイヤは、それらの説明が図8における同様の名称のレイヤの説明と同じまたは同様であるので、説明しない。

図11は、本明細書で説明するさらに別の態様によるシステムのユーザプレーンプロトコルスタックの例示的な図である。図11は、クライアントデバイス1102、アクセスノード1104、ゲートウェイ1106、およびアプリケーションサーバ1108を示す。

一態様では、シムレイヤ1162がクライアントデバイス1102のユーザプレーンプロトコルスタックに追加され得、対応するシムレイヤ1164がアクセスノード1104のプロトコルスタックに追加され得、さらに対応するシムレイヤ1166がゲートウェイ1106のプロトコルスタックに追加され得る。シムレイヤ1162、1164、および1166は、本明細書で説明する態様による、クライアントデバイス1102からアクセスノード1104への、かつアクセスノード1104からゲートウェイ1106へのネットワークトークンの移動を容易にする。一態様では、シムレイヤ1162は、クライアントデバイス1102のIPレイヤ1118の下、かつMACレイヤ1112の上にある。この態様では、対応するシムレイヤ1164は、アクセスノード1104のPDCPレイヤ1136の上にある。この態様では、追加の対応するシムレイヤ1166は、ゲートウェイ1106のIPレイヤ1124の下、かつGTP-Uレイヤ1126の上にある。

図11によって示される態様は、アクセスノード1104を介したクライアントデバイス1102からゲートウェイ1106へのネットワークトークン1160の移動に有用であり得、アクセスノード1104が、ネットワークトークンを検証するために使用され得るアクセスノードに固有の秘密鍵(K_NT,eNB)の受信者である。例として、クライアントデバイス1102は、(図11に示されていない)上記で説明した制御プレーンシグナリング/メッセージセットアップ方法により、ゲートウェイ1106からネットワークトークンを受信することがある。さらに、アクセスノード1104は、ゲートウェイ1106によって導出され、(図11に示されていない)上記で説明した制御プレーンシグナリング/メッセージセットアップ方法によりクライアントデバイス1102に送られるネットワークトークンを導出するためにゲートウェイ1106によって使用される、アクセスノードに固有の秘密鍵(K_NT,eNB)を受信することができる。ネットワークトークンの使用の一態様によれば、クライアントデバイス1102は、アプリケーションサーバ1108宛のパケットにネットワークトークンを含めることができる。シムレイヤ1162のシムヘッダは、図11に示すようにアクセスノード1104の対応するシムレイヤ1164にネットワークトークン1160を搬送することができる。アクセスノード1104は、クライアントデバイスパケットとともに含まれるネットワークトークンを確認するために、ゲートウェイ1106によって提供されたアクセスノードに固有の秘密鍵を使用することができる。アクセスノード1104における(以下で説明する)ネットワークトークンの確認が成功した場合、アクセスノード1104は、ゲートウェイ1106にクライアントデバイスパケットおよびネットワークトークンを転送することができる。アクセスノード1104におけるネットワークトークン1160の確認が成功しなかった場合、アクセスノード1104はパケットおよびネットワークトークンを処分することができる。アクセスノード1104における(以下で説明する)ネットワークトークンの確認が成功し、クライアントデバイスパケットおよびネットワークトークンがゲートウェイ1106に転送された場合、第2の確認プロセスがゲートウェイ1106において行われ得る。ゲートウェイ1106における(以下で説明する)ネットワークトークンの確認が成功した場合、ゲートウェイ1106はネットワークトークンを処分した後、アプリケーションサーバ1108にパケットを転送することができる。ゲートウェイ1106におけるネットワークトークン1160の確認が(アクセスノード1104における成功にもかかわらず)成功しなかった場合、ゲートウェイ1106はパケットおよびネットワークトークンを処分することができる。図示の態様によれば、トークンベースのアプリケーションアクセスをサポートするために、アプリケーションサーバ1108においていかなる変更も必要とされない。

図11に示される態様によれば、アクセスノード1104は、ゲートウェイ1106によってクライアントデバイス1102に送られるトークンを確認することができる。アクセスノード1104における確認は、ゲートウェイ1106がアクセスノードに固有の秘密鍵を導出すること(トークンセットアップに関連して上記で説明した導出)ができるので、可能である。これによりアクセスノード1104は、アプリケーションサーバ宛の許可されていないクライアントデバイストラフィックを、そのトラフィックがネットワークに深く入り込む前にフィルタ処理することが可能になり、それによって、許可されていないトラフィックを配信するためにネットワークリソースが使用されるのを防ぐことができる。

図11に関連して説明していないクライアントデバイス1102、アクセスノード1104、ゲートウェイ1106、およびアプリケーションサーバ1108のプロトコルスタックのレイヤは、それらの説明が図8における同様の名称のレイヤの説明と同じまたは同様であるので、説明しない。

図12は、本明細書で説明するさらに別の態様によるシステムのユーザプレーンプロトコルスタックの例示的な図である。図12は、クライアントデバイス1202、アクセスノード1204、ゲートウェイ1206、およびアプリケーションサーバ1208を示す。

一態様では、シムレイヤ1272がクライアントデバイス1202のプロトコルスタックに追加され得、対応するシムレイヤ1274がアクセスノード1204のプロトコルスタックに追加され得、さらに対応するシムレイヤ1276がゲートウェイ1206のプロトコルスタックに追加され得る。シムレイヤ1272、1274、および1276は、本明細書で説明する態様による、クライアントデバイス1202からアクセスノード1204への、かつアクセスノード1204からゲートウェイ1206へのネットワークトークンの移動を容易にする。一態様では、シムレイヤ1272は、クライアントデバイス1202のIPレイヤ1218の下、かつMACレイヤ1212の上にある。この態様では、対応するシムレイヤ1274は、アクセスノード1204のPDCPレイヤ1236の上にある。この態様では、追加の対応するシムレイヤ1276は、ゲートウェイ1206のIPレイヤ1224の下、かつGTP-Uレイヤ1226の上にある。

図12によって示される態様は、アクセスノード1204を介したクライアントデバイス1202からゲートウェイ1206へのネットワークトークン1260の移動に有用であり得、アクセスノード1204とゲートウェイ1206の両方が、クライアントデバイス1202のためにネットワークトークンを発行することができる。例として、クライアントデバイス1202は、(図12に示されていない)上記で説明した制御プレーンシグナリング/メッセージセットアップ方法により、アクセスノード1204からネットワークトークンNT2を受信し、ゲートウェイ1206から別個のネットワークトークンNT1を受信することがある。それぞれゲートウェイ1206およびアクセスノード1204から受信されるネットワークトークン、NT1、NT2の使用の一態様によれば、クライアントデバイス1202は、アプリケーションサーバ1208宛のパケットにネットワークトークン、NT1、NT2を含めることができる。シムレイヤ1272のシムヘッダは、図12に示すようにアクセスノード1204の対応するシムレイヤ1274にネットワークトークンNT1、NT2を搬送することができる。アクセスノード1204は、クライアントデバイスパケットとともに含まれるネットワークトークンNT2を確認するために、アクセスノード1204に知られている秘密鍵を使用することができる。アクセスノード1204におけるネットワークトークンNT2の確認が成功した場合、アクセスノード1204は、ネットワークトークンNT2を処分し、ゲートウェイ1206にパケットおよびネットワークトークンNT1を転送することができる。アクセスノード1204におけるネットワークトークンNT2の確認が成功しなかった場合、アクセスノード1204はパケットおよびネットワークトークンを処分することができる。

アクセスノード1204におけるネットワークトークンNT2の確認が成功し、パケットおよびネットワークトークンNT1がゲートウェイ1206に転送された場合、第2の確認プロセスがゲートウェイ1206において行われ得る。ゲートウェイ1206におけるネットワークトークンNT1の確認が成功した場合、ゲートウェイ1206はネットワークトークンNT1を処分した後、アプリケーションサーバ1208にパケットを転送することができる。ゲートウェイ1206におけるネットワークトークンNT1の確認が(アクセスノード1204における成功にもかかわらず)成功しなかった場合、ゲートウェイ1206はパケットおよびネットワークトークンNT1を処分することができる。図示の態様によれば、トークンベースのアプリケーションアクセスをサポートするために、アプリケーションサーバ1208においていかなる変更も必要とされない。

図12に示される態様によれば、アクセスノード1204は、クライアントデバイス1202に送られるトークンを確認することができ、このネットワークトークンは、アクセスノード1204自体によって導出されている。これによりアクセスノード1204は、アプリケーションサーバ宛の許可されていないクライアントデバイストラフィックを、そのトラフィックがネットワークに深く入り込む前にフィルタ処理することが可能になり、それによって、許可されていないトラフィックを配信するためにネットワークリソースが使用されるのを防ぐことができる。この態様は、アクセスノード1204とゲートウェイ1206との間で仮定される信頼関係がないときに有用であり得る。したがって、このオプションは、アクセスノード1204およびゲートウェイ1206が異なる事業者によって所有/実行されている場合に最も有用であり得る。

図12に関連して説明していないクライアントデバイス1202、アクセスノード1204、ゲートウェイ1206、およびアプリケーションサーバ1208のプロトコルスタックのレイヤは、それらの説明が図8における同様の名称のレイヤの説明と同じまたは同様であるので、説明しない。

図13は、本明細書で説明するさらに別の態様によるシステムのユーザプレーンプロトコルスタックの例示的な図である。図13は、クライアントデバイス1302、アクセスノード1304、ゲートウェイ1306、およびアプリケーションサーバ1308を示す。

一態様では、シムレイヤ1320がクライアントデバイス1302のプロトコルスタックに追加され得、対応するシムレイヤ1322がゲートウェイ1306のプロトコルスタックに追加され得る。シムレイヤ1320および対応するシムレイヤ1322は、本明細書で説明する態様による、クライアントデバイス1302からゲートウェイ1306へのネットワークトークンの移動を容易にする。一態様では、シムレイヤ1320は、クライアントデバイス1302のIPレイヤ1318の下、かつMACレイヤ1312の上にある。この態様では、対応するシムレイヤ1322は、ゲートウェイ1306のIPレイヤ1324の下、かつGTP-Uレイヤ1326の上にある。

さらに、図13は、ダウンリンクネットワークトークンNT_Dを示す。ダウンリンクトークンは、優先度付けおよびフィルタ処理に使用され得る。ダウンリンクトークンについては、(上記の)トークンセットアップに関して説明した。例として、クライアントデバイス1302は、(図13に示されていない)上記で説明した制御プレーンシグナリング/メッセージセットアップ方法により、ゲートウェイ1306からネットワークトークンNTを受信することがある。クライアントデバイス1302はまた、(図13に示されていない)上記で説明した制御プレーンシグナリング/メッセージセットアップ方法により、ゲートウェイ1306から第2のネットワークトークンNT_Dを受信することがある。ネットワークトークンの使用の一態様によれば、ダウンリンクネットワークトークンNT_Dは、(図13に示されていない)上記で説明した制御プレーンシグナリング/メッセージセットアップ方法により、クライアントデバイス1302からアプリケーションサーバ1308に配信され得る。その後、使用中に、アプリケーションサーバ1308は、ゲートウェイ1306に送られるクライアントデバイス1302宛のダウンリンクパケットにダウンリンクネットワークトークンNT_Dを含めることができる。ゲートウェイ1306は、優先度付けおよびフィルタ処理にダウンリンクネットワークトークンNT_Dを使用し得る。

図13に関連して説明していないクライアントデバイス1302、アクセスノード1304、ゲートウェイ1306、およびアプリケーションサーバ1308のプロトコルスタックのレイヤは、それらの説明が図8における同様の名称のレイヤの説明と同じまたは同様であるので、説明しない。

例示的なデバイス
図14は、ネットワークトークンベースのアプリケーションアクセスをサポートするように適応された例示的なデバイス1400を示すブロック図である。本明細書で使用する「デバイス」という用語は、チップ構成要素および/またはクライアントデバイスなどのエンドユーザデバイス(たとえば、モバイルデバイス、ユーザ機器、ユーザデバイス)を表し得る。一例では、例示的なデバイス1400は、通信インターフェース回路1402と、通信インターフェース回路1402に結合された処理回路1404と、処理回路1404に結合されたメモリデバイス1406(たとえば、データを記憶するための磁気および/または光デバイス)とを含み得る。この列挙は非限定的なものである。

通信インターフェース回路1402は、ユーザとの入力/出力動作のための第1の入力/出力回路/機能/モジュール1408を含み得る。通信インターフェース回路1402は、アクセスノードとのワイヤレス通信のための受信機/送信機回路/機能/モジュール1410を含み得る。この列挙は非限定的なものである。

処理回路1404は、トークンベースのアプリケーションアクセスをサポートするように適応された、1つまたは複数のプロセッサ、特定用途向けプロセッサ、ハードウェアおよび/またはソフトウェアモジュールなどを含むこと、または実装することがある。たとえば、ネットワークトークン埋込みモジュール/回路/機能1412は、アクセスノードおよび/またはゲートウェイに転送されるパケットにネットワークトークンを埋め込む(含める)ように適応され得る。この例は非限定的なものである。

メモリデバイス1406は、ネットワークトークン埋込み命令1422と、暗号検証/確認命令1424と、秘密鍵記憶および命令とを含むように適応され得る。この列挙は非限定的なものである。

図15は、デバイスがネットワークトークンを取得し得る例示的な方法1500である。例示的な方法1500は、デバイスにおいて実行可能であり得る。一態様では、デバイスは、cプレーンシグナリングを使用してアクセスノードとの接続を確立し得る。たとえば、そのような態様では、アクセスノードにおいてベアラが確立され得る。一態様では、デバイスは、制御プレーンシグナリングを使用して、1つまたは複数のアプリケーションに関連付けられる1つまたは複数のフローのセットを確立する1504ことができる。1つまたは複数のフローは、ポリシーに基づいて定義され得る。ポリシーは、ネットワークアクセスポリシーなどのネットワークポリシーであり得る。デバイスは、制御プレーンシグナリング中にネットワークトークンを取得する1506ことができ、ネットワークトークンは、ネットワークアクセスポリシーに従って導出され、1つまたは複数のフローのセットのうちの第1のフローに関連付けられ、1つまたは複数のアプリケーションのうちの第1のアプリケーションに関連付けられ、制御プレーンシグナリングを介してデバイスに提供され得る。

一態様では、制御プレーンシグナリングを使用して、1つまたは複数のアプリケーションに関連付けられる1つまたは複数のフローのセットを確立する前に、デバイスは随意に、アプリケーションサービスがネットワークトークンを必要とするかどうかを判断する1502ことができる。

一態様では、例示的な方法1500はさらに、デバイスから、第1のフローに関連付けられるパケットとともにネットワークトークンを送る1508ことを含み得る。本方法は、1つのパケットとともに1つのネットワークトークンのみを送ることに限定されない。本方法は、第1のフローに関連付けられる1つもしくは複数のパケットとともにネットワークトークンを送ることを含むことができ、または第1のフローに関連付けられるあらゆるパケットとともにネットワークトークンを送ることを含むことができる。

一態様では、アプリケーションサービスは、ベアラまたはアクセスポイント名(APN)に関連付けられ得る。モビリティ管理エンティティ(MME)またはパケットデータネットワークゲートウェイ(P-GW)によって、ネットワークにおいてベアラの確立が開始され得る。本明細書で使用する、ベアラの確立は、デフォルトベアラのアクティブ化、専用ベアラのアクティブ化、またはすでに確立されたベアラの変更を含み得る。ベアラを確立し、ネットワークトークンを取得するステップは、制御メッセージにおいて実施され得る。ネットワークトークンは、デバイスおよびアプリケーションサービスに関連付けられる(たとえば、結び付けられる)ことがある。ネットワークトークンは、1つまたは複数のフローおよび1つまたは複数のアプリケーションに関連付けられ得る。

一態様では、ベアラの確立がデバイスによって開始され得る。ベアラまたはAPNを確立するように実施され得るステップは、デバイスからパケットデータネットワーク(PDN)接続要求を送ること、デバイスから専用ベアラアクティブ化要求を送ること、またはデバイスからベアラ変更要求を送ることを含み得る。

一態様では、ベアラを確立することは、ネットワークトークンを要求することを含むことができ、要求は暗黙的または明示的であり得る。要求は、制御メッセージにおけるアプリケーション識別子(App ID)またはサービスデータフロー(SDF)によるアプリケーションサービスの識別を含み得る。

上記のように、デバイスは、ネットワークトークンを要求する前に、アプリケーションサービスがネットワークトークンを必要とするかどうかを判断し得る。そのような事例では、判断は、ネットワークから受信される指示、アプリケーションサービスから受信される指示、アプリケーションサービスの構成、および/またはクエリへの応答に基づき得る。

例として、ネットワークから受信される指示は、添付プロセスの一部として、シグナリングトランスポートレイヤ(S1B)メッセージまたは非アクセス層(NAS)メッセージに含まれ得る。ネットワークから受信される指示は、アプリケーションサービスの構成に関連して記憶され得る。ネットワークから受信される指示は、アプリケーションサービスへのサブスクリプションの生成中に受信されること、またはアプリケーションサービスへのソフトウェアアップグレードとしてダウンロードされることがある。ネットワークから受信される指示は、ポリシーの一部として受信され得る。

例として、アプリケーションサービスの構成は、アプリケーションサービスのポリシーに、またはアプリケーションサービスへの移送もしくは接続サービスをホストする接続プロバイダのポリシーに基づき得る。

図16は、デバイスがゲートウェイデバイスからネットワークトークンを取得し、アクセスノードから別個のネットワークトークンを取得し得る例示的な方法1600である。例示的な方法1600は、デバイスにおいて実行可能であり得る。一態様では、デバイスは、cプレーンシグナリングを使用してアクセスノードとの接続を確立し得る。たとえば、そのような態様では、アクセスノードにおいてベアラが確立され得る。一態様では、デバイスは、制御プレーンシグナリングを使用して、1つまたは複数のアプリケーションに関連付けられる1つまたは複数のフローのセットを確立する1602ことができる。1つまたは複数のフローは、ポリシーに基づいて定義され得る。ポリシーは、ネットワークアクセスポリシーなどのネットワークポリシーであり得る。デバイスは、制御プレーンシグナリング中に、第1のネットワークトークンを取得する1604ことができ、第1のネットワークトークンが、ネットワークアクセスポリシーに従って第1のデバイス(たとえば、P-GW、ゲートウェイデバイス)によって導出され得る。第1のネットワークトークンは、1つまたは複数のフローのセットのうちの第1のフロー、1つまたは複数のアプリケーションのうちの第1のアプリケーションに関連付けられ得、さらに、制御プレーンシグナリングを介してデバイスに提供され得る。

ネットワークアクセスポリシーは、デバイスからのフローをアプリケーションサービスに結び付けることができる。本方法は、次いで、デバイスにおいて、ネットワークアクセスポリシーに従ってフローにパケットを関連付けるために、第1のネットワークトークンを取得する1604ステップを含み得る。本方法はさらに、アプリケーションサービス宛であるフローに関連付けられるパケットに第1のネットワークトークンを含めるステップによって続くことができる。一態様では、デバイスは、アプリケーション宛の1つまたは複数のパケットに第1のネットワークトークンを含める1608ことができる。本方法はさらに、デバイスにおいて、アクセスポリシーに従ってフローにパケットを関連付けるために、第2のネットワークトークンを取得する1606随意のステップを含み得る。随意のステップに続いて、本方法はさらに、アプリケーション宛の1つまたは複数のパケットに第2のネットワークトークンを含める1608随意のステップを含むことができる。

第1および第2のネットワークトークンは、デバイスによって、制御メッセージにおいて取得され得る。

例示的なアクセスノード
図17は、トークンベースのアプリケーションアクセスをサポートするように適応された例示的なアクセスノード1700(たとえば、eNodeB)を示すブロック図である。一例では、例示的なアクセスノード1700は、ネットワーク通信インターフェース回路1702と、ネットワーク通信インターフェース回路1702に結合された処理回路1704と、処理回路1704に結合されたメモリデバイス1706(たとえば、データを記憶するための磁気および/または光デバイス)とを含み得る。この列挙は非限定的なものである。

ネットワーク通信インターフェース回路1702は、S-GWを介したP-GWとの通信のための第1の入力/出力回路/機能/モジュール1708を含み得る。ネットワーク通信インターフェース回路1702は、クライアントデバイスとのワイヤレス通信のための受信機/送信機回路/機能/モジュール1710を含み得る。この列挙は非限定的なものである。

処理回路1704は、トークンベースのアプリケーションアクセスをサポートするように適応された、1つまたは複数のプロセッサ、特定用途向けプロセッサ、ハードウェアおよび/またはソフトウェアモジュールなどを含むこと、または実装することがある。たとえば、ネットワークトークン導出回路/機能/モジュール1712が、ゲートウェイにのみ知られている秘密鍵、またはメモリデバイス1706に記憶され得るアクセスノードに固有の秘密鍵などのゲートウェイおよび/もしくは別のエンティティに知られている秘密鍵に基づいてトークンを導出するように適応され得る。別の例として、ネットワークトークン抽出/埋込みモジュール/回路/機能1714が、クライアントデバイスからのアップリンクパケットからネットワークトークンを抽出し、かつ/またはゲートウェイに転送されるパケットにネットワークトークンを埋め込む(含める)ように適応され得る。さらに別の例として、暗号検証/確認モジュール/回路/機能1716が、たとえば、クライアントデバイスから受信されたネットワークトークンを検証/確認するように適応され得る。この列挙は非限定的なものである。

メモリデバイス1706は、ネットワークトークン導出命令1720と、ネットワークトークン抽出/埋込み命令1722と、暗号検証/確認命令1724と、秘密鍵記憶および命令とを含むように適応され得る。この列挙は非限定的なものである。

図18は、アクセスノード(たとえば、eNodeB)においてネットワークトークンをセットアップする(たとえば、ネットワークトークンを導出し、クライアントデバイスにネットワークトークンを提供する)例示的な方法1800を示す。

例として、アクセスノードは、クライアントデバイスとの接続を確立する1802ことができる。アクセスノードは、アクセスノードに知られている鍵からネットワークトークンを導出する1804ことができる。アクセスノードは、アクセスノードにおいて導出されたネットワークトークンをクライアントデバイスに送る1806ことができる。アクセスノードにおいて導出されたネットワークトークンは、制御プレーンシグナリングを介してクライアントデバイスに送られ得る。一態様では、クライアントデバイスは、制御プレーンシグナリングを介して、P-GWにおいて導出されたネットワークトークンおよびアクセスノードにおいて導出されたネットワークトークンを受信し得る。ネットワークトークンは互いに異なり得る。P-GWにおいて導出されるネットワークトークンは、P-GWに知られている秘密鍵から導出され得、アクセスノードにおいて導出されるネットワークトークンは、アクセスノードに知られている秘密鍵から導出され得る。P-GWに知られている秘密鍵は、P-GWにのみ知られていることがある。アクセスノードに知られている秘密鍵は、アクセスノードにのみ知られていることがある。P-GWに知られている秘密鍵およびアクセスノードに知られている秘密鍵は、互いに異なり得る。クライアントデバイスから送られるULパケットとともに、アクセスノードにおいて導出されたネットワークトークン、ならびにP-GWにおいて導出されたネットワークトークンを含めることにより、アクセスノードはULパケットを、ネットワークの深くに送る前に確認することが可能になり得る。

上記で説明した例では、クライアントデバイスとの連絡の確立およびアクセスノードからクライアントデバイスへのネットワークトークンの送信は、制御メッセージにおいて実施され得る。アクセスノードにおいて導出されたネットワークトークンは、クライアントデバイス、アクセスノード、およびアプリケーションサービスに関連付けられる(たとえば、結び付けられる)ことがある。

図19は、アクセスノードにおいて実行可能な例示的な方法1900の流れ図である。本方法は、クライアントデバイスとの接続を確立する1902ステップを含み得る。本方法は、接続を確立することの一部として、クライアントデバイスのためのコンテキストを確立する1904ステップを含み得る。本方法は、クライアントデバイスおよびアプリケーションサービスに関連付けられるパケットにネットワークトークンを含める1906ことによって、続くことができる。コンテキストは、ネットワークトークンを含むことができ、ネットワークトークンがクライアントデバイスおよびアプリケーションサービスに関連付けられる(たとえば、結び付けられる)。本方法はさらに、ネットワークトークンを含むクライアントデバイスからのパケットを受信または取得する1908ステップを含むことができる。ネットワークトークンの有効性の判断が行われ得る1910。ネットワークトークンが、クライアントデバイスおよびアプリケーションサービスに関連付けられるネットワークトークンのコピーである場合、ネットワークトークンは有効であると判断され得る1912。本方法は、ネットワークトークンが有効である場合に、ネットワークトークンのコピーを含むパケットをゲートウェイに送る1914ステップをさらに含むことができる。ネットワークトークンが無効であると判断された場合、アクセスノードはパケットおよびネットワークトークンを処分する1916ことができる。

図20は、アクセスノードにおいて実行可能な別の例示的な方法2000の流れ図である。本方法は、クライアントデバイスとの接続を確立する2002ステップを含み得る。本方法は、クライアントデバイスからパケットを受信または取得する2004ステップを含むことができる。本方法は、ネットワークトークンのコピーを含むパケットをゲートウェイに送るステップをさらに含むことができ、ネットワークトークンが、アクセスノードによって、制御メッセージにおいて取得されている2006。

図21は、アクセスノードにおいて実行可能なまた別の例示的な方法2100の流れ図である。本方法は、クライアントデバイスとの接続を確立する2102ステップを含み得る。本方法は、第1のネットワークトークンおよび第2のネットワークトークンを含むクライアントデバイスからのパケットを取得するステップを含むことができ、第1のネットワークトークンがゲートウェイに関連付けられ(たとえば、結び付けられ)、第2のネットワークトークンがアクセスノードに関連付けられる(たとえば、結び付けられる)2104。本方法は、引き続き、アクセスノードにおいて第2のネットワークトークンを検証/確認する2106ことができる。検証/確認が成功した場合、アクセスノードは、第2のネットワークトークンを処分する2108ことができる。次いでアクセスノードは、第1のネットワークトークンを含むパケットをゲートウェイに送る2110ことができる。検証/確認が成功しなかった場合、アクセスノードは、パケットと第1および第2のネットワークトークンとを処分する2112ことができる。

例示的なゲートウェイ
図22は、トークンベースのアプリケーションアクセスをサポートするように適応された例示的なゲートウェイ2200を示すブロック図である。一例では、例示的なゲートウェイ2200は、ネットワーク通信インターフェース回路2202と、ネットワーク通信インターフェース回路2202に結合された処理回路2204と、処理回路2204に結合されたメモリデバイス2206(たとえば、データを記憶するための磁気および/または光デバイス)とを含み得る。この列挙は非限定的なものである。

ネットワーク通信インターフェース回路2202は、サービングゲートウェイとの通信のための第1の入力/出力回路/機能/モジュール2208、およびパケットデータネットワークとの通信のための第2の入力/出力回路/機能/モジュール2210を含み得る。第1の入力/出力回路/機能/モジュール2208は、複数のベアラ上に確立された複数のIPフローを処理し得る。第2の入力/出力回路/機能/モジュール2210は、パケットデータネットワーク上の複数のサーバとの複数のIPフローを処理し得る。この列挙は非限定的なものである。

処理回路2204は、トークンベースのアプリケーションアクセスをサポートするように適応された、1つまたは複数のプロセッサ、特定用途向けプロセッサ、ハードウェアおよび/またはソフトウェアモジュールなどを含むこと、または実装することがある。たとえば、ネットワークトークン導出回路/機能/モジュール2212は、メモリデバイス2206に記憶され得る秘密鍵に基づいてトークンを導出するように適応され得る。秘密鍵は、ゲートウェイにのみ知られていることがある。別の例として、鍵導出回路/機能/モジュール2214は、アクセスノードに固有の秘密鍵を、たとえば、メモリデバイス2206に記憶され得る秘密鍵および所与のアクセスノードの識別子に基づいて導出するように適応され得る。また別の例として、決定および処理回路/機能/モジュール2216は、EPSベアラから受信されたアップリンクパケット、またはアプリケーションサーバから受信されたダウンリンクパケットが、ネットワークトークンを含むかどうかを決定するように適応され得、含む場合には、受信されたパケットを暗号-検証およびトラフィック-ステアリング回路/機能/モジュール2218に渡すようにさらに適応され得る。決定および処理回路/機能/モジュール2216は、ネットワークトークンを含まない受信されたパケットをサービスデータフローフィルタバンク(図示せず)に渡すようにさらに適応され得る。この列挙は非限定的なものである。

メモリデバイス2206は、ネットワークトークン導出命令2220と、鍵導出命令2222と、決定および処理命令2224と、暗号-検証およびトラフィック-ステアリング命令2226と、秘密鍵記憶および命令とを含むように適応され得る。この列挙は非限定的なものである。

図23は、ゲートウェイ(たとえば、P-GW)においてネットワークトークンをセットアップする(たとえば、ネットワークトークンを導出し、クライアントデバイスにネットワークトークンを提供する)例示的な方法2300を示す。

例として、ゲートウェイは、クライアントデバイスに関連付けられるベアラセットアップ、アクティブ化、または変更中に、ネットワークトークンを求める要求を受信する2302ことができる。随意のステップとして、ネットワークトークンの導出のためにアクセスノード(たとえば、eNodeB)に固有の秘密鍵を導出するかどうかの判断が行われ得る2304。随意のステップ2304が使用されない場合、またはアクセスノードに固有の秘密鍵を導出するかどうかの判断が、アクセスノードに固有の秘密鍵を導出しないとの決定をもたらした場合、本方法は、ゲートウェイにおいて、ゲートウェイにのみ知られている秘密鍵からネットワークトークンを導出する2306ことに進むことができる。ゲートウェイは次に、ベアラセットアップ、アクティブ化、または変更中に、クライアントデバイスに、またはクライアントデバイスに関連付けられるアクセスノードに、ネットワークトークンを送る2308ことができる。随意のステップ2304が使用される場合、またはアクセスノードに固有の秘密鍵を導出するかどうかの判断が、アクセスノードに固有の秘密鍵を導出するとの決定をもたらした場合、本方法は、アクセスノードに固有の秘密鍵を導出する2310ステップに進むことができる。アクセスノード(たとえば、eNB)に固有の秘密鍵は、たとえば、ゲートウェイ(たとえば、K_NT)にのみ知られている秘密鍵、および、たとえば、アクセスノードの識別子(たとえば、eNB識別子)を含む入力を有する鍵導出関数(KDF)を使用して導出され得る。したがって、例示的な一態様では、K_NT,eNB=KDF(K_{NT,eNB ID})である。この例示的な態様は、限定的であることを意図していない。

一態様によれば、ネットワークトークンは、クライアントデバイスが接続されるアクセスノードに固有の秘密鍵から導出され得る2312。本方法は、クライアントデバイスにネットワークトークンを送り、アクセスノードに固有の秘密鍵をアクセスノードに送る2314ことを含み得る。

一態様によれば、クライアントデバイスのためのアプリケーションサービスが識別され得、クライアントデバイスにまたはアクセスノードに送られるネットワークトークンが、アプリケーションサービスに関連付けられ得る。

一態様によれば、ネットワークトークンを求める要求を受信または取得し、ネットワークトークン(およびいくつかの例では、アクセスノードに固有の導出された秘密鍵)を送ることは、制御メッセージにおいて実施され得る。

一態様によれば、ネットワークトークンの導出は、アクセスポリシーに基づき得る。また別の態様によれば、クライアントデバイスにネットワークトークンを送ることは、モビリティ管理エンティティ(MME)にネットワークトークンを送ること、およびMMEからクライアントデバイスにネットワークトークンを送ることをさらに含み得る。

例示的な図23に示されているように、ネットワークトークンは、ゲートウェイにのみ知られている秘密鍵から直接導出される(ステップ2306参照)こと、またはアクセスノードに固有の秘密鍵を導出するために使用され得る、ゲートウェイにのみ知られている同じ秘密鍵から間接的に導出される(ステップ2310、2312参照)ことがある。

いくつかの態様では、ベアラは、アプリケーション識別子(ID)および/またはクライアントデバイスIDに関連付けられ得る。いくつかの態様では、アプリケーションサービスは、ベアラまたはアクセスポイント名(APN)に関連付けられ得る。いくつかの態様では、ネットワークトークンは、クライアントデバイスおよびアプリケーションサービスに関連付けられる(たとえば、結び付けられる)ことがある。

いくつかの態様では、ベアラは、複数のトラフィックフローテンプレート(TFT)を含み得る。複数のTFTは、複数のアプリケーションサービスに対応し得る。

また別の態様によれば、クライアントデバイスにネットワークトークンを送ること、およびアクセスノードに固有の秘密鍵をアクセスノードに送ることは、ネットワークトークンおよびアクセスノードに固有の秘密鍵をモビリティ管理エンティティ(MME)に送ること、MMEからクライアントデバイスにネットワークトークンを送ること、およびアクセスノードに固有の秘密鍵をMMEからアクセスノードに送ることをさらに含み得る。

別の態様では、ネットワークトークンは、アプリケーションサービスに関連付けられるアクセスポリシーを実施するために使用され得、アクセスノードに固有の秘密鍵は、許可されていないパケットがゲートウェイに到着するのを防ぐために、アクセスノードにおいて受信されたパケットに含まれるネットワークトークンを、ゲートウェイにパケットを送る前に検証するために使用され得る。

図24は、ゲートウェイ(たとえば、P-GW)においてアップリンクおよびダウンリンクネットワークトークンをセットアップする例示的な方法2400を示す。一態様では、ゲートウェイにおいて、クライアントデバイスに関連付けられるベアラセットアップ、アクティブ化、または変更中に、ネットワークトークンを求める要求が受信され得る2402。クライアントデバイスのためのアプリケーションサービスが識別され得る2404。ゲートウェイにおいてULネットワークトークンが導出され得る2406。ゲートウェイにおいて、ULネットワークトークンとは異なるDLネットワークトークンも導出され得る2408。一態様では、ゲートウェイは、クライアントデバイスにULネットワークトークンおよびDLネットワークトークンを送る2410ことができる。随意に、クライアントデバイスは、PDN上のAPPにダウンリンクネットワークトークンを送る2412ことができる。

一態様では、ネットワークトークンを求める要求を受信または取得することと、ULネットワークトークンおよびDLネットワークトークンの提供とは、制御メッセージにおいて実施され得る。

一態様では、アップリンクネットワークトークンを導出することは、ゲートウェイに知られている鍵に、かつクライアントデバイスに関連付けられるパラメータに基づき、ダウンリンクネットワークトークンを導出することは、ゲートウェイに知られている鍵に、かつアプリケーションサーバに関連付けられるパラメータに基づく。

一態様では、アップリンクネットワークトークンおよびダウンリンクネットワークトークンをクライアントデバイスに送ることは、ULネットワークトークンおよびDLネットワークトークンをモビリティ管理エンティティ(MME)に送ることと、アップリンクネットワークトークンおよびダウンリンクネットワークトークンをMMEからクライアントデバイスに送ることとをさらに含む。

図25は、ゲートウェイにおいて実行可能な例示的な方法2500の流れ図である。本方法は、ゲートウェイにおいて、ネットワークトークンを含むパケットを受信または取得する2502ステップを含むことができる。本方法は、引き続き、ゲートウェイに知られている鍵を使用して、ネットワークトークンを検証/確認する2504ことができる。ネットワークトークンが有効である場合2506、本方法は、ネットワークトークンを処分し、アプリケーションサーバにパケットを送る2508ことによって続くことができる。ネットワークトークンが有効ではない場合2506、本方法は、パケットおよびネットワークトークンを処分する2510ことによって続くことができる。

一態様では、ネットワークトークンを確認することは、ゲートウェイに知られている鍵と、ネットワークトークンパラメータインデックス、ソースインターネットプロトコル(IP)アドレス、ソースポート番号、宛先IPアドレス、宛先ポート番号、プロトコル識別子(ID)、アプリケーションID、優先度、および/またはサービス品質クラス識別子(QCI)とを含む入力パラメータのセットを有する関数から確認ネットワークトークンを導出することと、ネットワークトークンを確認ネットワークトークンと比較することとを含み得る。

一態様では、ゲートウェイデバイスにおいて実行可能な、例示的な方法は、ゲートウェイにおいて、アプリケーションサーバからパケットを受信または取得するステップであって、パケットがダウンリンクネットワークトークンを含む、ステップと、ゲートウェイに知られている鍵を使用して、ダウンリンクネットワークトークンを確認するステップと、確認が成功しなかった場合に、パケットおよびダウンリンクネットワークトークンを処分するステップと、確認が成功した場合に、ダウンリンクネットワークトークンを処分し、ダウンリンクネットワークトークンによって表されるパラメータに基づいて、クライアントデバイスにパケットを送るステップとを含み得る。

図示および説明された特定の実装形態は例にすぎず、本明細書で別段に規定されていない限り、本開示を実装するための唯一の方法として解釈されるべきではない。本開示における様々な例は他の多くの分割ソリューションによって実施され得ることが、当業者には容易に明らかである。

本明細書で説明し、図面に示した、構成要素、動作、特徴、および/または機能のうちの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、または当技術分野において既知の任意の他の形態の記憶媒体に存在し得る。プロセッサが記憶媒体から情報を読み取り、記憶媒体に情報を書き込むことができるように、記憶媒体がプロセッサに結合され得る。代替的に、記憶媒体は、プロセッサと一体であり得る。

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

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

100 動作環境
102 クライアントデバイス
104 クライアントデバイス
106 アクセスノード
108 無線アクセスネットワーク(RAN)
110 コアネットワーク(CN)
112 モビリティ管理エンティティ(MME)
116 サービングゲートウェイ(S-GW)
118 ホーム加入者サーバ(HSS)
120 パケットデータネットワークゲートウェイ(P-GW)
122 パケットデータネットワーク(PDN)
124 サーバ
126 サーバ
128 サーバ
130 サーバ
200 アップリンク動作
202 クライアントデバイス
204 アクセスノード
206 サービングゲートウェイ(S-GW)
208 パケットゲートウェイ(P-GW)
210 パケットデータネットワーク(PDN)
212 アプリケーション/アプリケーションサービス
214 IPフロー
216 トラフィックフローテンプレート(TFT)
218 ベアラ
220 決定および処理回路/機能/モジュール
222 暗号-検証およびトラフィックステアリング回路/機能/モジュール
224 サービスデータフロー(SDF)テンプレート
300 呼フロー
302 クライアントデバイス
304 アクセスノード
306 MME
308 S-GW
310 P-GW
312 ポリシーおよび課金ルール機能(PCRF)
314 ホーム加入者サーバ(HSS)
400 呼フロー
402 クライアントデバイス
404 アクセスノード
406 MME
408 S-GW
410 P-GW
412 PCRF
414 HSS
500 呼フロー
502 クライアントデバイス
504 アクセスノード
506 MME
508 S-GW
510 P-GW
512 PCRF
514 HSS
600 呼フロー
602 クライアントデバイス
604 アクセスノード
606 MME
608 S-GW
610 P-GW
612 PCRF
614 HSS
700 呼フロー
702 クライアントデバイス
704 アクセスノード
706 MME
708 S-GW
710 P-GW
712 PCRF
714 HSS
715 アプリケーション(APP)、アプリケーション/アプリケーションサービス/アプリケーションサーバ(APP)
800 ユーザプレーンプロトコルスタック
802 クライアントデバイス
804 アクセスノード
806 ゲートウェイ
808 アプリケーションサーバ
810 物理(PHY)レイヤ
812 媒体アクセス制御(MAC)レイヤ
814 無線リンク制御(RLC)レイヤ
816 パケットデータコンバージェンスプロトコル(PDCP)レイヤ
818 インターネットプロトコル(IP)レイヤ
820 シムレイヤ
822 対応するシムレイヤ
824 IPレイヤ
826 GTP-Uレイヤ
830 物理(PHY)レイヤ
832 媒体アクセス制御(MAC)レイヤ
834 無線リンク制御(RLC)レイヤ
836 パケットデータコンバージェンスプロトコル(PDCP)レイヤ
840 イーサネット（登録商標）レイヤ
842 MACレイヤ
844 IPレイヤ
846 ユーザデータグラムプロトコル(UDP)レイヤ
848 GTP-Uレイヤ
858 IPレイヤ
860 ネットワークトークン
902 クライアントデバイス
904 アクセスノード
906 ゲートウェイ
908 アプリケーションサーバ
916 PDCPレイヤ
926 GTP-Uレイヤ
936 PDCPレイヤ
948 GTP-Uレイヤ
960 ネットワークトークン
1002 クライアントデバイス
1004 アクセスノード
1006 ゲートウェイ
1008 アプリケーションサーバ
1026 GTP-Uレイヤ
1048 GTP-Uレイヤ
1060 ネットワークトークン
1102 クライアントデバイス
1104 アクセスノード
1106 ゲートウェイ
1108 アプリケーションサーバ
1112 MACレイヤ
1118 IPレイヤ
1124 IPレイヤ
1126 GTP-Uレイヤ
1136 PDCPレイヤ
1160 ネットワークトークン
1162 シムレイヤ
1164 対応するシムレイヤ、シムレイヤ
1166 対応するシムレイヤ、シムレイヤ
1202 クライアントデバイス
1204 アクセスノード
1206 ゲートウェイ
1208 アプリケーションサーバ
1212 MACレイヤ
1218 IPレイヤ
1224 IPレイヤ
1226 GTP-Uレイヤ
1236 PDCPレイヤ
1260 ネットワークトークン
1272 シムレイヤ
1274 対応するシムレイヤ、シムレイヤ
1276 対応するシムレイヤ、シムレイヤ
1302 クライアントデバイス
1304 アクセスノード
1306 ゲートウェイ
1308 アプリケーションサーバ
1312 MACレイヤ
1318 IPレイヤ
1320 シムレイヤ
1322 対応するシムレイヤ
1324 IPレイヤ
1326 GTP-Uレイヤ
1400 デバイス
1402 通信インターフェース回路
1404 処理回路
1406 メモリデバイス
1408 第1の入力/出力回路/機能/モジュール
1410 受信機/送信機回路/機能/モジュール
1412 ネットワークトークン埋込みモジュール/回路/機能
1422 ネットワークトークン埋込み命令
1424 暗号検証/確認命令
1500 方法
1600 方法
1700 アクセスノード
1702 ネットワーク通信インターフェース回路
1704 処理回路
1706 メモリデバイス
1708 第1の入力/出力回路/機能/モジュール
1710 受信機/送信機回路/機能/モジュール
1712 ネットワークトークン導出回路/機能/モジュール
1714 ネットワークトークン抽出/埋込みモジュール/回路/機能
1716 暗号検証/確認モジュール/回路/機能
1720 ネットワークトークン導出命令
1722 ネットワークトークン抽出/埋込み命令
1724 暗号検証/確認命令
1800 方法
1900 方法
2000 方法
2100 方法
2200 ゲートウェイ
2202 ネットワーク通信インターフェース回路
2204 処理回路
2206 メモリデバイス
2208 第1の入力/出力回路/機能/モジュール
2210 第2の入力/出力回路/機能/モジュール
2212 ネットワークトークン導出回路/機能/モジュール
2214 鍵導出回路/機能/モジュール
2216 決定および処理回路/機能/モジュール
2218 暗号-検証およびトラフィック-ステアリング回路/機能/モジュール
2220 ネットワークトークン導出命令
2222 鍵導出命令
2224 決定および処理命令
2226 暗号-検証およびトラフィック-ステアリング命令
2300 方法
2400 方法
2500 方法

Claims (46)

1. デバイスにおいて実行可能な方法であって、
   制御プレーンシグナリングを使用して、1つまたは複数のアプリケーションに関連付けられる1つまたは複数のフローのセットを確立するステップと、
   前記制御プレーンシグナリング中に前記デバイスにおいて、第1のネットワークトークンを取得するステップとを含み、前記第1のネットワークトークンは、
   1つまたは複数のフローの前記セットのうちの第1のフローに関連付けられ、
   前記1つまたは複数のアプリケーションのうちの第1のアプリケーションに関連付けられ、
   前記制御プレーンシグナリングを介して前記デバイスに提供される、方法。
2. 前記デバイスから、前記第1のフローに関連付けられるパケットとともに前記第1のネットワークトークンを送るステップ
   をさらに含む、請求項1に記載の方法。
3. 前記デバイスから、前記第1のフローに関連付けられる前記デバイスから送られるあらゆるパケットとともに前記第1のネットワークトークンを送るステップ
   をさらに含む、請求項1に記載の方法。
4. 前記第1のネットワークトークンは、ネットワークアクセスポリシーに従って導出される、請求項1に記載の方法。
5. 前記第1のネットワークトークンは、前記第1のフローにおけるパケットを前記第1のアプリケーションにステアリングするために使用される、請求項1に記載の方法。
6. 前記第1のネットワークトークンは、前記第1のネットワークトークンを求める暗黙的要求に応答して提供され、
   前記暗黙的要求は、
   パケットデータネットワーク(PDN)接続要求メッセージ、
   専用ベアラアクティブ化要求メッセージ、または
   ベアラ変更要求メッセージ
   のうちのいずれか1つを含む、請求項1に記載の方法。
7. 前記第1のネットワークトークンを前記デバイスからゲートウェイデバイスに、
   インターネットプロトコル(IP)レイヤと媒体アクセス制御(MAC)レイヤとの間のシムレイヤにおけるシムヘッダ、
   パケットデータコンバージェンスプロトコル(PDCP)ヘッダ、および/または
   IPバージョン6(IPv6)において定義されるIP拡張ヘッダ
   において移送するステップをさらに含む、請求項1に記載の方法。
8. 前記第1のネットワークトークンが前記シムヘッダにおいて移送されたとき、前記第1のネットワークトークンはアクセスノードには透過的である、請求項7に記載の方法。
9. 前記第1のネットワークトークンを前記デバイスからアクセスノードに、
   インターネットプロトコル(IP)レイヤと媒体アクセス制御(MAC)レイヤとの間のシムレイヤにおけるシムヘッダ、および/または
   パケットデータコンバージェンスプロトコル(PDCP)ヘッダ
   において移送するステップをさらに含む、請求項1に記載の方法。
10. 前記制御プレーンシグナリング中に前記デバイスにおいて、第2のネットワークトークンを取得するステップをさらに含み、前記第2のネットワークトークンは、
    前記第1のトークンを導出した第1のデバイスとは異なる第2のデバイスによって導出され、
    1つまたは複数のフローの前記セットのうちの前記第1のフローに関連付けられ、
    前記1つまたは複数のアプリケーションのうちの前記第1のアプリケーションに関連付けられ、
    前記制御プレーンシグナリングを介して前記デバイスに提供される、請求項1に記載の方法。
11. ネットワークインターフェースと、
    前記ネットワークインターフェースに結合された処理回路とを備えるデバイスであって、前記処理回路は、
    制御プレーンシグナリングを使用して、1つまたは複数のアプリケーションに関連付けられる1つまたは複数のフローのセットを確立することと、
    前記制御プレーンシグナリング中に前記デバイスにおいて、ネットワークトークンを取得することとを行うように構成され、前記ネットワークトークンは、
    1つまたは複数のフローの前記セットのうちの第1のフローに関連付けられ、
    前記1つまたは複数のアプリケーションのうちの第1のアプリケーションに関連付けられ、
    前記制御プレーンシグナリングを介して前記デバイスに提供される、デバイス。
12. 前記処理回路は、前記第1のフローに関連付けられるパケットとともに前記ネットワークトークンを送るようにさらに構成される、請求項11に記載のデバイス。
13. 前記処理回路は、前記第1のフローに関連付けられるあらゆるパケットとともに前記ネットワークトークンを送るようにさらに構成される、請求項11に記載のデバイス。
14. 前記処理回路は、前記第1のフローにおけるパケットを前記第1のアプリケーションにステアリングするために、前記ネットワークトークンに関連付けられるデータを使用するようにさらに構成される、請求項11に記載のデバイス。
15. ゲートウェイデバイスにおいて実行可能な方法であって、
    前記ゲートウェイデバイスにおいて、クライアントデバイスに関連付けられるデータ接続セットアップ、アクティブ化、または変更に関連付けられる制御プレーンシグナリング中にネットワークトークンを求める要求を取得するステップと、
    前記ゲートウェイデバイスにおいて、前記ネットワークトークンを導出するステップであって、前記ネットワークトークンが、アクセスポリシーに従ってフローおよびアプリケーションサービスに関連付けられる、ステップと、
    制御プレーンシグナリングを介して、前記ネットワークトークンを前記クライアントデバイスに、または前記クライアントデバイスに関連付けられるアクセスノードに前記制御プレーンシグナリング中に送るステップと
    を含む方法。
16. 前記ネットワークトークンは、前記ゲートウェイデバイスを通じてネットワークを介して送信する間に前記クライアントデバイスと前記アプリケーションサービスとの間で移行するパケットをステアリングするために使用される、請求項15に記載の方法。
17. 前記ネットワークトークンを求める前記要求は明示的である、請求項15に記載の方法。
18. 前記ネットワークトークンを求める前記要求は、前記ゲートウェイデバイスにおいて、
    パケットデータネットワーク(PDN)接続要求、
    専用ベアラアクティブ化要求、または
    ベアラ変更要求
    を取得すると暗黙的に認識される、請求項15に記載の方法。
19. 前記ネットワークトークンの導出は、前記クライアントデバイスが接続されるアクセスノードに固有の秘密鍵に基づき、前記方法は、
    前記アクセスノードに前記秘密鍵を送るステップ
    をさらに含む、請求項15に記載の方法。
20. 前記ネットワークトークンは、アップリンクネットワークトークンおよび前記アップリンクネットワークトークンとは異なるダウンリンクネットワークトークンとして導出され、
    前記アップリンクネットワークトークンの導出は、前記ゲートウェイデバイスに知られている鍵に、かつ前記クライアントデバイスに関連付けられるパラメータに基づき、
    前記ダウンリンクネットワークトークンの導出は、前記ゲートウェイデバイスに知られている前記鍵に、かつアプリケーションサーバに関連付けられるパラメータに基づき、前記方法は、
    前記アップリンクネットワークトークンおよび前記ダウンリンクネットワークトークンを前記クライアントデバイスに送るステップ
    をさらに含む、請求項15に記載の方法。
21. 前記ゲートウェイデバイスにおいて、前記ネットワークトークンを含む第1のパケットを取得するステップと、
    パケット検査を使用せずに、前記第1のパケットとともに含まれる前記ネットワークトークンに関連付けられるデータを使用して、前記クライアントデバイスと前記アプリケーションサービスとの間で第1のパケットをステアリングするステップと
    をさらに含む、請求項15に記載の方法。
22. 前記ゲートウェイデバイスにおいて、前記ネットワークトークンを含む第1のパケットを取得するステップと、
    前記ゲートウェイデバイスに知られている鍵を使用して、前記ネットワークトークンを確認するステップと、
    前記確認が成功しなかった場合に、前記ネットワークトークンを含む前記第1のパケットを処分するステップと、
    前記確認が成功した場合に、パケット検査を使用せずに、前記第1のパケットとともに含まれる前記ネットワークトークンを使用して、前記クライアントデバイスと前記アプリケーションサービスとの間で第1のパケットをステアリングするステップと
    をさらに含む、請求項15に記載の方法。
23. 前記ネットワークトークンを確認するステップは、
    前記ゲートウェイデバイスに知られている前記鍵と、
    ネットワークトークンパラメータインデックス、ソースインターネットプロトコル(IP)アドレス、ソースポート番号、宛先IPアドレス、宛先ポート番号、プロトコル識別子(ID)、アプリケーションID、優先度、および/またはサービス品質クラス識別子(QCI)と
    を含む入力パラメータのセットを有する関数から確認ネットワークトークンを導出するステップと、
    前記ネットワークトークンを前記確認ネットワークトークンと比較するステップと
    を含む、請求項22に記載の方法。
24. 前記ネットワークトークンパラメータインデックス、ソースインターネットプロトコル(IP)アドレス、ソースポート番号、宛先IPアドレス、宛先ポート番号、プロトコル識別子(ID)、アプリケーションID、優先度、および/またはサービス品質クラス識別子(QCI)は、前記パケットから取得される、請求項23に記載の方法。
25. 前記ネットワークトークンを確認する前に、ネットワークトークンパラメータインデックスを識別するステップであって、前記ネットワークトークンパラメータインデックスが入力パラメータのリストを定義する、ステップと、
    入力として、前記ゲートウェイデバイスに知られている前記鍵および入力パラメータの前記リストを有する関数から確認ネットワークトークンを導出するステップと
    をさらに含む、請求項23に記載の方法。
26. 前記ネットワークトークンパラメータインデックスは、アプリケーション識別子(ID)をさらに定義する、請求項25に記載の方法。
27. 入力パラメータの前記リストは、前記ゲートウェイデバイスにおいてテーブルに記憶される、請求項25に記載の方法。
28. 前記ネットワークトークンは、IPヘッダとは別個のシムヘッダにおいて搬送される、請求項25に記載の方法。
29. 前記ネットワークトークンは、汎用パケット無線サービス(GPRS)トンネリングプロトコル(GTP)ヘッダにおいて搬送される、請求項25に記載の方法。
30. 前記ネットワークトークンは、インターネットプロトコル(IP)バージョン6(IPv6)において定義されたIP拡張ヘッダにおいて搬送される、請求項25に記載の方法。
31. ネットワークインターフェースと、
    前記ネットワークインターフェースに結合された処理回路とを備えるゲートウェイデバイスであって、前記処理回路は、
    クライアントデバイスに関連付けられるデータ接続セットアップ、アクティブ化、または変更に関連付けられる制御プレーンシグナリング中にネットワークトークンを求める要求を取得することと、
    前記ネットワークトークンを取得することであって、前記ネットワークトークンが、アクセスポリシーに従ってフローおよびアプリケーションサービスに関連付けられる、取得することと、
    制御プレーンシグナリングを介して、前記ネットワークトークンを前記クライアントデバイスに、または前記クライアントデバイスに関連付けられるアクセスノードに前記制御プレーンシグナリング中に送ることと
    を行うように構成される、ゲートウェイデバイス。
32. 前記処理回路は、前記ゲートウェイデバイスを通じてネットワークを介して送信する間に前記クライアントデバイスと前記アプリケーションサービスとの間でパケットをステアリングするために前記ネットワークトークンを使用するようにさらに構成される、請求項31に記載のゲートウェイデバイス。
33. 前記処理回路は、
    パケット検査を使用せずに、前記第1のパケットとともに含まれる前記ネットワークトークンを使用して、前記クライアントデバイスと前記アプリケーションサービスとの間で第1のパケットをステアリングするようにさらに構成される、請求項31に記載のゲートウェイデバイス。
34. 前記処理回路は、前記ネットワークトークンを導出することによって前記ネットワークトークンを取得し、
    前記クライアントデバイスが接続されるアクセスノードに固有の秘密鍵に基づいて前記ネットワークトークンを導出することと、
    前記アクセスノードに前記秘密鍵を送ることと
    を行うようにさらに構成される、請求項31に記載のゲートウェイデバイス。
35. 前記処理回路は、前記ネットワークトークンを導出することによって前記ネットワークトークンを取得し、
    前記ネットワークトークンを、アップリンクネットワークトークンおよび前記アップリンクネットワークトークンとは異なるダウンリンクネットワークトークンとして導出することであって、
    前記アップリンクネットワークトークンは、前記ゲートウェイデバイスに知られている鍵に、かつ前記クライアントデバイスに関連付けられるパラメータに基づき、
    前記ダウンリンクネットワークトークンは、前記ゲートウェイデバイスに知られている前記鍵に、かつアプリケーションサーバに関連付けられるパラメータに基づく、導出することと、
    前記アップリンクネットワークトークンおよび前記ダウンリンクネットワークトークンを前記クライアントデバイスに送ることと
    を行うようにさらに構成される、請求項31に記載のゲートウェイデバイス。
36. アクセスノードにおいて実行可能な方法であって、
    制御プレーンシグナリング中に前記アクセスノードにおいて、ネットワークトークンを取得するステップを含み、前記ネットワークトークンは、
    1つまたは複数のフローのセットのうちの第1のフローに関連付けられ、
    1つまたは複数のアプリケーションのうちの第1のアプリケーションに関連付けられ、
    前記制御プレーンシグナリングを介して前記アクセスノードに提供される、方法。
37. 前記アクセスノードから、前記第1のフローに関連付けられるパケットとともに前記ネットワークトークンを送るステップ
    をさらに含む、請求項36に記載の方法。
38. 前記アクセスノードから、前記第1のフローに関連付けられるあらゆるパケットとともに前記ネットワークトークンを送るステップ
    をさらに含む、請求項36に記載の方法。
39. 前記ネットワークトークンは、前記1つまたは複数のアプリケーションに関連付けられる1つまたは複数のフローの前記セットに関連付けられる、請求項36に記載の方法。
40. アクセスノードにおいて実行可能な方法であって、
    制御プレーンシグナリングにおいて、前記アクセスノードに固有の秘密鍵をゲートウェイデバイスから取得するステップと、
    ユーザプレーンシグナリングにおいて、クライアントデバイスから前記アクセスノードにおいてパケットを取得するステップであって、前記パケットがネットワークトークンを含む、ステップと、
    前記ゲートウェイデバイスから取得された前記アクセスノードに固有の秘密鍵を使用して、前記ネットワークトークンを確認するステップと、
    前記ネットワークトークンが確認された場合に、前記パケットおよびネットワークトークンを前記ゲートウェイデバイスに送るステップ、または
    前記ネットワークトークンが確認されなかった場合に、前記パケットおよびネットワークトークンを処分するステップと
    を含む方法。
41. 前記ネットワークトークンは、汎用パケット無線サービス(GPRS)トンネリングプロトコル(GTP)ヘッダにおいて前記ゲートウェイデバイスに搬送される、請求項40に記載の方法。
42. 前記ネットワークトークンは、パケットデータコンバージェンスプロトコル(PDCP)ヘッダから汎用パケット無線サービストンネリングプロトコルヘッダ(GTPヘッダ)にコピーされ、前記GTPヘッダにおいて前記ゲートウェイデバイスに搬送される、請求項40に記載の方法。
43. 前記ネットワークトークンは、アプリケーションサービスに関連付けられるアクセスポリシーを実施するためのものであり、前記アクセスノードに固有の前記秘密鍵は、許可されていないパケットが前記ゲートウェイデバイスに到着するのを防ぐために、前記アクセスノードにおいて受信されたパケットに含まれる前記ネットワークトークンを、前記ゲートウェイデバイスに前記パケットを送る前に検証するためのものである、請求項40に記載の方法。
44. ネットワークインターフェースと、
    前記ネットワークインターフェースに結合された処理回路とを備えるアクセスノードであって、前記処理回路は、
    制御プレーンシグナリングにおいて、前記アクセスノードに固有の秘密鍵をゲートウェイデバイスから取得することと、
    ユーザプレーンシグナリングにおいて、クライアントデバイスから前記アクセスノードにおいてパケットを取得することであって、前記パケットがネットワークトークンを含む、取得することと、
    ゲートウェイデバイスから取得された前記アクセスノードに固有の秘密鍵を使用して、前記ネットワークトークンを確認することと、
    前記ネットワークトークンが確認された場合に、前記パケットおよびネットワークトークンをゲートウェイデバイスに送ること、または
    前記ネットワークトークンが確認されなかった場合に、前記パケットおよびネットワークトークンを処分することと
    を行うように構成される、アクセスノード。
45. ゲートウェイデバイスにおいて実行可能な方法であって、
    前記ゲートウェイデバイスにおいて、アプリケーションサーバからパケットを取得するステップであって、前記パケットがダウンリンクネットワークトークンを含む、ステップと、
    前記ゲートウェイデバイスに知られている鍵を使用して、前記ダウンリンクネットワークトークンを確認するステップと、
    前記確認が成功しなかった場合に、前記パケットを処分するステップと、
    前記確認が成功した場合に、前記ダウンリンクネットワークトークンを処分し、前記ダウンリンクネットワークトークンによって表されるパラメータに基づいてクライアントデバイスに前記パケットを送るステップと
    を含む方法。
46. 前記パケットは、インターネットプロトコル(IP)データパケットである、請求項45に記載の方法。

Images