ゲートウェイセッション確立のための方法及び装置
３ＧＰＰコアネットワークから非３ＧＰＰアクセスネットワークへポリシーを配備する方法が開示される。ポリシーは、非３ＧＰＰアクセスネットワークを介して、移動端末から３ＧＰＰコアネットワークへ確立される接続に関連する。ローカルＩＰアドレスが３ＧＰＰコアネットワークにおいて受信され（Ｓ１）、このローカルＩＰアドレスは、接続の確立中に移動端末によって取得される。３ＧＰＰコアネットワークにおいて、ポリシー制御セッションの確立は、３ＧＰＰコアネットワークから非３ＧＰＰアクセスネットワークへと開始される（Ｓ３）。受信されるローカルＩＰアドレスは、共有ＩＰアドレス割当情報を参照して接続のために使用される非３ＧＰＰアクセスネットワークを判定する（Ｓ２ａ）、あるいはその判定を可能にする（Ｓ２ｂ）ために使用される。共有ＩＰアドレス割当情報は、複数の非３ＧＰＰアクセスネットワークに割り当てられている、それぞれが異なるローカルＩＰアドレスの範囲を設定する。３ＧＰＰコアネットワークにおいて、ポリシー制御セッションを開始するステップの結果として確立するポリシー制御セッションを使用して、非３ＧＰＰアクセスネットワークへ提供される（Ｓ４）。このポリシーは、確立される接続に関連する非３ＧＰＰアクセスネットワークに配備するためのものである。この方法は、非３ＧＰＰアクセスネットワークにおいて使用するためにも提供される。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、非３ＧＰＰアクセスネットワークを介して、３ＧＰＰコアネットワークへ移動端末を接続するためのスキームにおけるゲートウェイセッション確立のための方法及び装置に関するものである。この方法は、固定網と移動網のコンバージェンス（収束）における特定用途を見い出せる。
【背景技術】
【０００２】
電気通信における現在の傾向は、固定ネットワークと移動ネットワークのコンバージェンス（収束）であり、これは、固定網と移動網のコンバージェンス（ＦＭＣ（Fixed Mobile Convergence））として知られる。ＩＰベースの技術を使用して進化中のネットワークの動向は、固定ネットワークと移動ネットワークとで共通していて、これは、収束をより容易にすることである。ＦＭＣによって、移動ネットワークオペレータと固定ネットワークオペレータは、より効率的に自身のネットワークリソースを利用することが可能となり、これは、資本支出と事業費（ＣＡＰＥＸとＯＰＥＸ）の削減をもたらすことになる。例えば、ユーザが自宅でマルチメディアテレフォニー（ＭＭＴｅｌ）のようなＩＰベースのアプリケーションを実行している場合には、無線アクセスネットワークではなくむしろ固定アクセスネットワークのブロードバンド接続性を利用することがより効率的である。
【０００３】
宅内ネットワークはＦＭＣの成功の鍵となる。なぜなら、それらは、通常のユーザによってほぼ共通に使用される固定ネットワークアクセスであるからである。それゆえ、宅内ネットワークを通じて移動電話を改良型パケットコア（ＥＰＣ：「非３ＧＰＰアクセス用アーキテクチャの拡張」、３ＧＰＰ ＴＳ ２３．４０２、Ｖ８．２．０、２００８年６月参照）へ移動電話を接続することができることが重要である。以下では、用語、ユーザ機器（ＵＥ）は、用語、移動端末あるいは移動電話の代わりに使用することにする。用語ＵＥは、第３世代パートナシッププロジェクト（３ＧＰＰ）の文献でも知られている。
【０００４】
３ＧＰＰは、移動体２Ｇ／３Ｇ／ＬＴＥアクセス及び「非３ＧＰＰアクセス」（ＴＳ２３．４０２）を定義する。後者は、固定ネットワークであり得る。多くのＵＥは、複数の無線インタフェースを提供することによってＦＭＣの動向を取り扱っている。この無線インタフェースには２Ｇ／３Ｇ／ＬＴＥアクセスへ接続するためのインタフェースや、固定ネットワークに接続するためのＷｉＦｉインタフェースがある。
【０００５】
ＴＳ２３．４０２は、ＵＥを、非３ＧＰＰアクセスネットワークを介して３ＧＰＰコアネットワーク（ＥＰＣ）へ接続するための様々な方法を定義している。これらのインタフェースは、プロキシモバイルＩＰ（ＰＭＩＰ）プロトコルあるいはクライアントモバイルＩＰ（ＣＭＩＰ）プロトコルのどちらかを使用する。本明細書では、通常、ＣＭＩＰの使用が想定される。即ち、Ｓ２ｃとして知られるインタフェースである。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
本出願人は、上述の状況で以下の技術的課題を認識している。
【０００７】
高度な使用の場合に対しては、例えば、ＩＭＳボイスコールを行うことに対しては、ＱｏＳセットアップは、ＥＰＣと非３ＧＰＰアクセスの両方で要求される。Ｓ２ｃに対してこれをどのようにして行うかについては、ＴＳ２３．４０２で定義される。以下のこれらの定義は、非３ＧＰＰアクセスドメイン内の境界ゲートウェイ（ＢＧＷ）が、ＥＰＣ（ポリシー及び課金ルール機能あるいはＰＣＲＦ）内のポリシーサーバ向けのゲートウェイ制御セッションをセットアップするために要求される。そして、このゲートウェイセッションは、ＱｏＳルールをダウンロードするために使用される。このルールのダウンロードは接続時に実行されるが、その後の段階、例えば、ユーザがアプリケーション向けの新規のセッションを開始する場合に実行される可能性もある。ゲートウェイ制御セッションはユーザ単位で確立される定義によるので、ＢＧＷはＵＥの識別情報を有することが要求される。この識別情報を安全に取得するための唯一の方法は、認証を介在させることである。それゆえ、仕様書では、３ＧＰＰアクセス認証を定義している（即ち、アクセス時のユーザ認証）。
【０００８】
３ＧＰＰアクセス認証は、上位レベルでのみ定義される。特殊な事例での３ＧＰＰアクセス認証を適用する場合、例えば、非３ＧＰＰアクセスネットワークがＢＢＦネットワーク（ＢＢＦはブロードバンドフォーラムを表していて、固定アクセス用の標準化機構：http://www.broadband-forum.org/参照）である場合、仕様書は、特定の認証プロトコルを推進しない。いくつかの候補が検証されているが、これらの候補の有用性は、特定のネットワークトポロジーにかなり依存している。例としては、ユーザが自身の所有するＷｉＦｉＡＰ（アクセスポイント）を構成設定しているか？、あるいは、これがオペレータによってリモートで管理されているか？、宅内ゲートウェイ（ＲＧＷ）でブリッジされているかあるいはルーティングされているか？ＲＧＷにネットワークアドレス変換（ＮＡＴ）が存在するか等である。
【０００９】
出願人によって認識される上述の課題を取り組むことが要望されている。
【課題を解決するための手段】
【００１０】
ＢＢＦネットワークのような非３ＧＰＰアクセスネットワークを介して、移動端末あるいはＵＥから、進化型パケットコアのような３ＧＰＰコアネットワークへの接続を含む方法が提案される。この方法は、固定移動集約スキームでの使用を見い出し、ここでは、移動端末あるいはＵＥは、例えば、ＷｉＦｉを使用して、固定宅内ネットワークを介して、３ＧＰＰコアネットワークへ接続する。
【００１１】
本明細書では、非３ＧＰＰアクセスネットワークにおけるＢＧＷ（あるいはその等価物）と、３ＧＰＰコアネットワークにおけるＰＣＲＦ（あるいはその等価物）との間のゲートウェイ制御セッション（あるいはゲートウェイセッション）を確立するための方法が特に提案される。ゲートウェイ制御セッションは、３ＧＰＰコアネットワークから非３ＧＰＰアクセスネットワークへ、非３ＧＰＰアクセスネットワークを介して移動端末から３ＧＰＰコアネットワークへ確立される接続に関連するポリシーを提供するために確立される。それゆえ、ゲートウェイ制御セッション（あるいはゲートウェイセッション）は、ポリシー制御セッションと見なすことができ、また、ゲートウェイ制御セッション（あるいはゲートウェイセッション）の代わりになるようなものとして参照することができる。
【００１２】
ＢＢＦネットワークが非３ＧＰＰアクセスネットワークである場合、ＢＧＷはＢＮＧとなり得る。この方法は、３ＧＰＰアクセス認証を行うことなく、ゲートウェイセッションの確立を達成する。この方法では、ＰＣＲＦが、ＢＧＷに代わって、ゲートウェイセッションの確立を開始する。そのような方法で、ＰＣＲＦが正規のＢＧＷをアドレス指定することができるようにするために、アドレス割当情報がオペレータ間で共有される。
【００１３】
ゲートウェイセッションの確立のためのスキームは、以下のステップを有するように提案される。（０）アドレス割当情報の共有、（１）ＵＥが取得するローカルＩＰアドレスを用いる、ＵＥのローカル認証、（２）３ＧＰＰコアネットワーク内のＰＤＮゲートウェイへのローカルＩＰアドレスの転送、（３）ＰＣＲＦへのローカルＩＰアドレスの転送、（４）ステップ（３）で受信されるローカルＩＰアドレスとステップ０からのＩＰアドレス割当情報とを使用して、ＰＣＲＦがＢＧＷに向けてのゲートウェイセッションを開始する、（５）ゲートウェイセッションが確立される。
【００１４】
上述のステップ（２）では、ユーザ認証を含む、トンネル（セキュリティゲートウェイ）が、ＵＥと３ＧＰＰコアネットワークにおけるＰＤＮゲートウェイとの間で確立される。ステップ（２）は、以下の段階を備えるように見なすことができる。：Ａ）セキュリティアソシエーションが確立される、次に、Ｂ）移動ＩＰセッションが確立される、そして、最後に、Ｃ）トンネルが確立される。この状況における段階Ｂは重要である。それは、ローカルＩＰアドレスをＰＤＮ ＧＷへ搬送するからである。上述のステップ（３）では、ＩＰセッションが、ステップ（２）で受信されるＵＥ情報を使用して、ＰＤＮゲートウェイとＰＣＲＦとの間で確立される（これは、後の段階で、ＰＣＲＦからＰＤＮへのパケットフィルタのダウンロードを可能にする）。上述のステップ（４）では、ＰＣＲＦは、ステップ（３）で受信されるＵＥ情報とステップ（０）からのアドレス割当情報を使用して、ＰＣＲＦがＢＧＷに向けてのゲートウェイセッションを開始する（このセッションの目的は、後の段階で、ＰＣＲＦからＰＤＮへのパケットフィルタのダウンロードを可能にすることである）。ＰＣＲＦは、一般的には、特定のＢＧＷをアドレス指定しないが、Ｄｉａｍｔｅｒアドレス体系とＤＲＡとをアドレス指定することになる。ＰＣＲＦは、ポリシー制御機能（ＰＣＦ）、あるいは、それと等価の、ＢＢＦネットワークにおけるブロードバンドポリシー制御機能（ＢＰＣＦ）を使用して、ＢＧＷへのゲートウェイセッションを開始することができる。
【００１５】
上述のステップ（０）に関し、この提案は、各非３ＧＰＰアクセスネットワークが、ＩＰアドレスのどのブロックがあるいは範囲がＵＥ／ＮＡＴに割り当てられることができるかを知っていることである。この情報をＰＣＲＦへ配信する、あるいはこの情報をＰＣＲＦ（上述のステップ（４）で使用するため）と共有する、いくつかの方法が可能である。ここでは、このような方法として、ＩＰアドレス範囲を共有する方法が提案される：（ａ）ＤＮＳを使用すること、（ｂ）ＤＲＡルーティングコンフィグレーションを使用すること、及び（ｃ）分散マッピングデータベースを使用することである。ＩＰアドレス割当情報が共有される厳格な方法は重要ではなく、もちろん、本発明は、これらの３つの方法に限定されるものではない。他の共有する方法を使用することができ、これらの方法の２つ以上を組み合わせることも可能であることが理解されるべきである。
【００１６】
上述の方法（群）を用いることで、ＩＰアドレス範囲はネットワークＩＤにマッピングされ、そして、ＤＮＳサーバへ追加される。非３ＧＰＰアクセスネットワークにおけるＤＲＡは、所与のＵＥ／ＮＡＴ ＩＰアドレスを提供するＰＣＦを検出することを可能にするために、自身のルーティングテーブルを更新する。ゲートウェイセッションを開始するために、ＰＣＲＦは、ＵＥ／ＮＡＴアドレスに基づくリバースＤＮＳルックアップを実行する。ＤＮＳはネットワークＩＤでリプライし、そして、これは、非３ＧＰＰアクセスネットワークにおけるＤＲＡをアドレス指定するために使用される（例えば、宛先−アドレス体系 ＡＶＰ）。ＰＣＦは、所与のＵＥ／ＮＡＴ ＩＰアドレスを提供するＢＧＷを検出することを可能にするように構成されている。これは、後述する第１の実施形態で扱われる方法である。
【００１７】
上述の方法（ｂ）を用いると、セッションを開始するために、ＰＣＲＦによってＰＣＦへ送信されるメッセージは、特別なフォーマットの宛先−アドレス体系ＡＶＰを含んでいる。宛先アドレス体系は、対象のＵＥ／ＮＡＴのＩＰアドレスから構築される。これは、どのようにしてＤＮＳ名がリバースＤＮＳルックアップに対するＩＰアドレスから構築されるかに類似している。このことを動作させるために、３ＧＰＰドメインにおけるＤＲＡが適切に構成設定される必要がある。これは、非３ＧＰＰドメインからのコンフィグレーションメッセージから受信されるルーティング情報に基づいている。非３ＧＰＰ側のＤＲＡは、所与のＵＥ／ＮＡＴ ＩＰアドレスを提供するＢＧＷを検出することを可能にするために、自身のルーティングテーブルを更新する。これは、後述する第２の実施形態で扱われる方法である。
【００１８】
上述の方法（ｃ）を用いると、既存のデータベース構造を再使用することに代えて、別のデータベースが導入される。非３ＧＰＰドメイン内では、どのＩＰアドレス範囲がどのＢＧＷによって提供され、また、どのＢＧＷがどのＰＣＦによって提供されるかをリストにしているローカルマッピングデータベースが存在する。このローカルマッピングデータベースを使用することで、ＤＲＡは、所与のＵＥ／ＮＡＴアドレスをアドレス指定するためのＰＣＦを検出することができる。同様に、ＰＣＦは、アドレス指定するためのＢＧＷを検出することができる。各非３ＧＰＰオペレータは、すべてのネットワークに、アドレスブロックについてのローミング協定があり、そして、それをＵＥ／ＮＡＴへアドレスを割り当てるために使用することを通知する。これらのブロックは、３ＧＰＰドメイン内のＰＣＲＦに記憶される、即ち、ＰＣＲＦは、非３ＧＰＰネットワークＩＤにマッピングされる範囲のリストを維持する。ＵＥ／ＮＡＴアドレスを使用することで、ＰＣＲＦは、このリストを問い合わせ、ネットワークＩＤを検出する。ネットワークＩＤを使用することで、正規の非３ＧＰＰネットワークをアドレス指定することができる。これは、後述する第３の実施形態で扱われる方法である。
【００１９】
提案されるスキームでは、少なくともＰＣＲＦ、ＢＰＣＦ及びＢＧＷは、既存のスキームで開示されない新規のステップを実行するように構成されているので、本出願人が所有する権利において新規性がある。以下に記載される他のノードは、新規のステップを実行するものであるので、本出願人が所有する権利において新規性がある。
【００２０】
本明細書で提案される方法を実行する装置を制御するためのプログラムも提案され、これは、装置にロードされる場合、その装置に本明細書で提案される装置となるように動作させる。このプログラムは、搬送媒体で搬送されても良い。この搬送媒体は、記憶媒体であっても良い。この搬送媒体は、送信媒体であっても良い。このようなプログラムによってプログラムされる装置も予想され、それは、そのようなプログラムを含む記憶媒体となるからである。
【００２１】
本明細書で言及されるように、ネットワークコンフィグレーションに依存する、３ＧＰＰアクセス認証を実行するいくつかの方法が存在する。これは、ＵＥあるいは、ＷｉＦｉ ＡＰあるいはＲＧＷ、それらの組み合わせを意味する。その影響は、新規のプロトコルのコンフィグレーションあるいは導入となって現れる。本発明の実施形態は、ＰＣＲＦが開始するゲートウェイセッション確立を提案する。これは、３ＧＰＰアクセス認証に対する必要性を解消するという効果を有する。その結果、ＱｏＳセットアップは、ＵＥ、ＷｉＦｉ ＡＰ及びＲＧＷの少なくとも１つに影響を与えることなく、非３ＧＰＰアクセスにおいて達成される。
【００２２】
本明細書では、３ＧＰＰコアネットワークから非３ＧＰＰアクセスネットワークへポリシーを配備する方法が開示される。ポリシーは、非３ＧＰＰアクセスネットワークを介して、移動端末から３ＧＰＰコアネットワークへ確立される接続に関連する。ローカルＩＰアドレスが３ＧＰＰコアネットワークにおいて受信され、このローカルＩＰアドレスは、接続の確立中に移動端末によって取得される。３ＧＰＰコアネットワークにおいて、ポリシー制御セッションの確立は、３ＧＰＰコアネットワークから非３ＧＰＰアクセスネットワークへと開始される。受信されるローカルＩＰアドレスは、共有ＩＰアドレス割当情報を参照して接続のために使用される非３ＧＰＰアクセスネットワークを判定する、あるいはその判定を可能にするために使用される。共有ＩＰアドレス割当情報は、複数の非３ＧＰＰアクセスネットワークに割り当てられている、それぞれが異なるローカルＩＰアドレスの範囲を設定する。３ＧＰＰコアネットワークにおいて、ポリシー制御セッションを開始するステップの結果として確立されるポリシー制御セッションを使用して、非３ＧＰＰアクセスネットワークへ提供される。このポリシーは、確立される接続に関連する非３ＧＰＰアクセスネットワークに配備するためのものである。
【００２３】
これらのステップは、ポリシー及び課金ルール機能のような、３ＧＰＰコアネットワークにおけるポリシーサーバによって実行されても良い。
【００２４】
共有ＩＰアドレス割当情報は、３ＧＰＰコアネットワークで保持されるＤＮＳデータベースあるいは別のデータベースに記憶されても良い。接続のために使用される非３ＧＰＰアクセスネットワークの判定は、ローカルＩＰアドレスに基づいてデータベースにおけるルックアップ動作を実行することを含んでいても良い。あるいは、そのような判定は、ローカルＩＰアドレスに基づくルックアップ動作を実行することを別のノードに可能にするために、その別のノードへローカルＩＰアドレスを提供することによって実現されても良い。
【００２５】
別のデータベースは、ＤＲＡであっても良い。この方法は、接続のために使用される非３ＧＰＰアクセスネットワークを判定することをＤＲＡへ可能にするために、該ＤＲＡへローカルＩＰアドレスを提供することを含んでいても良い。
【００２６】
別のデータベースは、ポリシーサーバで保持されても良い。
【００２７】
本明細書では、３ＧＰＰコアネットワークから非３ＧＰＰアクセスネットワークにポリシーを配備する方法が開示される。このポリシーは、非３ＧＰＰアクセスネットワークを介して移動端末から３ＧＰＰコアネットワークへ確立される接続に関連する。この方法は、非３ＧＰＰアクセスネットワークにおいて、３ＧＰＰコアネットワークから非３ＧＰＰアクセスネットワークへのポリシー制御セッションの確立を支援することを含み、ポリシー制御セッションの確立は、接続の確立中に移動端末によって取得されるローカルＩＰアドレスを使用して３ＧＰＰコアネットワークによって開始されていて、ローカルＩＰアドレスは、複数の非３ＧＰＰアクセスネットワークに割り当てられている、それぞれが異なるローカルＩＰアドレスの範囲を設定する共有ＩＰアドレス割当情報を参照して接続のために使用される非３ＧＰＰアクセスネットワークを判定する、あるいはその判定を可能にするものである。ポリシーは、非３ＧＰＰアクセスネットワークにおいて、支援するステップの結果として確立されるポリシー制御セッションを使用して受信される。確立される接続に関連して、受信されるポリシーが非３ＧＰＰアクセスネットワークにおいて配備される、あるいはその受信されるポリシーは、そのような配備を行うために非３ＧＰＰアクセスネットワークにおいて準備される。
【００２８】
これらのステップは、非３ＧＰＰアクセスネットワークにおける境界ゲートウェイノードであるゲートウェイノードによって、あるいは、非３ＧＰＰアクセスネットワークにおけるポリシー制御機能であるポリシーサーバによって、あるいは、ゲートウェイノードとポリシーサーバとが協働することによって、実行されても良い。
【００２９】
ポリシーは、ＱｏＳポリシーであっても、あるいはＱｏＳポリシーを有していても良い。
【００３０】
移動端末は、ＵＥを含んでいても良い。
【００３１】
３ＧＰＰコアネットワークは、進化型パケットコアネットワークを含んでいても良い。
【００３２】
非３ＧＰＰアクセスネットワークは、ＢＢＦネットワークを含んでいても良い。
【００３３】
本明細書では、３ＧＰＰコアネットワークで使用するための装置が開示される。この装置は、３ＧＰＰコアネットワークから非３ＧＰＰアクセスネットワークへポリシーを配備するためのものである。このポリシーは、非３ＧＰＰアクセスネットワークを介して移動端末から３ＧＰＰコアネットワークへ確立される接続に関連する。受信機あるいは受信ユニットあるいはそのような手段が、接続の確立中に、移動端末によって取得されているローカルＩＰアドレスを受信するために提供される。プロセッサあるいはプロセッサユニットあるいはそのような手段が、受信されるローカルＩＰアドレスを使用して、３ＧＰＰコアネットワークから非３ＧＰＰアクセスネットワークへのポリシー制御セッションの確立を開始するために提供されることで、共有ＩＰアドレス割当情報を参照して接続のために使用される非３ＧＰＰアクセスネットワークを判定する、あるいはその判定を可能にする。この共有ＩＰアドレス割当情報は、複数の非３ＧＰＰアクセスネットワークに割り当てられている、それぞれが異なるローカルＩＰアドレスの範囲を設定する。プロセッサあるいはプロセッサユニットあるいはそのような手段が、確立されるポリシー制御セッションを使用して非３ＧＰＰアクセスネットワークへポリシーを提供するために提供される。このポリシーは、確立される接続に関連する非３ＧＰＰアクセスネットワークに配備するためのものである。
【００３４】
本明細書では、非３ＧＰＰアクセスネットワークで使用するための装置が開示される。この装置は、３ＧＰＰコアネットワークから非３ＧＰＰアクセスネットワークへポリシーを配備するためのものである。このポリシーは、非３ＧＰＰアクセスネットワークを介して移動端末から３ＧＰＰコアネットワークへ確立される接続に関連する。プロセッサあるいはプロセッサユニットあるいはそのような手段が、３ＧＰＰコアネットワークから非３ＧＰＰアクセスネットワークへのポリシー制御セッションの確立を支援するために提供され、ポリシー制御セッションの確立は、接続の確立中に移動端末によって取得されるローカルＩＰアドレスを使用して３ＧＰＰコアネットワークによって開始されていて、ローカルＩＰアドレスは、複数の非３ＧＰＰアクセスネットワークに割り当てられている、それぞれが異なるローカルＩＰアドレスの範囲を設定する共有ＩＰアドレス割当情報を参照して接続のために使用される非３ＧＰＰアクセスネットワークを判定する、あるいはその判定を可能にするものである。受信機あるいは受信ユニットあるいはそのような手段が、確立されるポリシー制御セッションを使用してポリシーを受信するために提供される。プロセッサあるいはプロセッサユニットあるいはそのような手段が、確立される接続に関連して、受信されるポリシーを配備する、あるいは配備のための準備をするために提供される。
【図面の簡単な説明】
【００３５】
【図１】アーキテクチャの概要を提供するブロック図である。
【図２】３ＧＰＰアクセス認証が使用されない場合のアクセスに接続するための周知の手順に伴う課題を示すステップ群を有するブロック図である。
【図３】アクセスに接続するための３ＧＰＰアクセス認証の使用を示すステップ群を有するブロック図である。
【図４Ａ】３ＧＰＰアクセス認証を含む非３ＧＰＰ（ＢＢＦ）アクセスネットワークに接続するためのシグナリング図である（図４Ａは全体シグナリング図を示し、その詳細が判読しにくいことは問題ではない、それは、図４Ａは図４Ｂから図４Ｅの複製であり、図４Ａは、文字ではなく図式で示したものと見なすことができるからである）。
【図４Ｂ】明確のために、図４Ａのシグナリング図を４つに分図したものの１つを示す図である。
【図４Ｃ】明確のために、図４Ａのシグナリング図を４つに分図したものの１つを示す図である。
【図４Ｄ】明確のために、図４Ａのシグナリング図を４つに分図したものの１つを示す図である。
【図４Ｅ】明確のために、図４Ａのシグナリング図を４つに分図したものの１つを示す図である。
【図５】ＰＣＲＦが開始するゲートウェイセッション確立を示すステップ群を有するブロック図である。
【図６Ａ】ＤＮＳに基づくＩＰアドレス範囲を共有するためのシグナリング図である（図６Ａは全体シグナリング図を示し、その詳細が判読しにくいことは問題ではない、それは、図６Ａは図６Ｂから図６Ｅの複製であり、図６Ａは、文字ではなく図式で示したものと見なすことができるからである）。
【図６Ｂ】明確のために、図６Ａのシグナリング図を４つに分図したものの１つを示す図である。
【図６Ｃ】明確のために、図６Ａのシグナリング図を４つに分図したものの１つを示す図である。
【図６Ｄ】明確のために、図６Ａのシグナリング図を４つに分図したものの１つを示す図である。
【図６Ｅ】明確のために、図６Ａのシグナリング図を４つに分図したものの１つを示す図である。
【図７Ａ】ＤＲＡルーティングコンフィグレーションに基づくＩＰアドレス範囲を共有するためのシグナリング図である（図７Ａは全体シグナリング図を示し、その詳細が判読しにくいことは問題ではない、それは、図７Ａは図７Ｂから図７Ｅの複製であり、図７Ａは、文字ではなく図式で示したものと見なすことができるからである）。
【図７Ｂ】明確のために、図７Ａのシグナリング図を４つに分図したものの１つを示す図である。
【図７Ｃ】明確のために、図７Ａのシグナリング図を４つに分図したものの１つを示す図である。
【図７Ｄ】明確のために、図７Ａのシグナリング図を４つに分図したものの１つを示す図である。
【図７Ｅ】明確のために、図７Ａのシグナリング図を４つに分図したものの１つを示す図である。
【図８Ａ】分散マッピングデータベースに基づくＩＰアドレス範囲を共有するためのシグナリング図である（図８Ａは全体シグナリング図を示し、その詳細が判読しにくいことは問題ではない、それは、図８Ａは図８Ｂから図８Ｅの複製であり、図８Ａは、文字ではなく図式で示したものと見なすことができるからである）。
【図８Ｂ】明確のために、図８Ａのシグナリング図を４つに分図したものの１つを示す図である。
【図８Ｃ】明確のために、図８Ａのシグナリング図を４つに分図したものの１つを示す図である。
【図８Ｄ】明確のために、図８Ａのシグナリング図を４つに分図したものの１つを示す図である。
【図８Ｅ】明確のために、図８Ａのシグナリング図を４つに分図したものの１つを示す図である。
【図９】本発明を実施する方法が実現される場合のノードの構成を示す図である。
【図１０】本発明の実施形態に従う３ＧＰＰコアネットワークにおけるポリシーサーバノードの構成を示す図である。
【図１１】本発明の実施形態に従う非３ＧＰＰアクセスネットワークにおけるポリシーサーバノードの構成を示す図である。
【図１２】本発明の実施形態に従う非３ＧＰＰアクセスネットワークにおけるゲートウェイノードの構成を示す図である。
【図１３】本発明の実施形態に従って実行されるステップ群を示すフローチャートである。
【発明を実施するための形態】
【００３６】
従来技術に関連する上述の技術的な課題を考慮して、本発明の実施形態は、３ＧＰＰアクセス認証を使用することなく、ゲートウェイセッションをセットアップする方法を提案する。ゲートウェイセッションを確立するための構想はＢＧＷ（Ｓ２ｃに対して現在規定される）によるものではなく、ＰＣＲＦによるものである。しかしながら、このようなＰＣＲＦから開始されるゲートウェイセッション確立の実装は付随的な課題をもたらす。これには、どのようにして、ＰＣＲＦが正規のＢＧＷを取り扱うことができるか？である。本発明の実施形態は、オペレータ間でアドレス割当情報を共有することによってこの課題を解決することを提案する。
【００３７】
本発明の実施形態の詳細説明の前に、技術的な課題のより詳細な説明を説明する。
【００３８】
ＴＳ２３．４０２は、どのようにしてＵＥをＳ２ｃを使用して非３ＧＰＰアクセスに接続するかを定義する。ここでは、非３ＧＰＰアクセスがＢＢＦネットワークである状況を想定する。図１は、そのような構成を示している。図では、ＲＧは宅内ゲートウェイを表し、それゆえ、これは、本明細書で言及するＲＧＷと等価である。
【００３９】
まず、３ＧＰＰアクセス認証を伴わない状況を検討する。これについては、図２で示される。このような状況では、ＢＧＷ（本明細書では、ＢＮＧと呼ばれる）はＰＣＲＦに向けてのゲートウェイセッションを確立することができない。図２では、以下のステップが示される。
【００４０】
・ステップ１：ローカル認証である。ＵＥは、ローカルＩＰアドレスを取得する。これには、３ＧＰＰ ＵＥ信用証明書が含まれない。例えば、商用ＯＳを備えるラップトップと同一の手順である。
【００４１】
・ステップ２：ＤＳＭＩＰｖ６（デュアルスタックＭＩＰｖ６）トンネルのセットアップである。これには、３ＧＰＰユーザ認証が含まれる。ステップ２の後、ユーザは、ベストエフォート型のトラフィックを実行することができる。多くのステップで、ＱｏＳをセットアップすることが要求される。
【００４２】
・ステップ３：インターネットプロトコル接続アクセスネットワーク（ＩＰ−ＣＡＮ）セッションのセットアップである。これは、ステップ２で受信される３ＧＰＰ ＵＥ信用証明書に基づいている。このセッションの目的は、後の段階で、ＰＣＲＦからパケットデータネットワークゲートウェイ（ＰＤＮ−ＧＷ）へパケットフィルタをダウンロードすることを可能にするためである。
【００４３】
・ステップ４：ＢＮＧは、ゲートウェイセッションを開始することを必要とする。これは、３ＧＰＰ ＵＥ信用証明書に基づいている。このセッションの目的は、後の段階で、ＰＣＲＦからＢＮＧへパケットフィルタをダウンロードすることを可能にするためである。
【００４４】
しかしながら、ＢＮＧは、ゲートウェイセッションをセットアップするために要求される３ＧＰＰ ＵＥ信用証明書を有していない。結果として、そのＵＥに対するＢＢＦにおけるＱｏＳはセットアップされない。
【００４５】
ここで、３ＧＰＰアクセス認証を伴う状況を検討する。これについては、図３で示される。３ＧＰＰアクセス認証を使用することによって、ＢＮＧはＵＥ信用証明書を取得することができる。これを使用することで、ゲートウェイセッションをセットアップすることができる。図３では、以下のステップが示される。
【００４６】
・ステップ１：ＵＥは、３ＧＰＰアクセス認証を実行する。これには、３ＧＰＰ ＵＥ信用証明書が含まれる。このセットアップは、非３ＧＰＰアクセスの方法とに沿うものであり、３ＧＰＰアクセス認証は、ＴＳ２３．４０２のＳ２Ｃに対してのオプションである。
【００４７】
・ステップ２、３：図２で参照したものである。
【００４８】
・ステップ４：ＢＮＧは、ゲートウェイセッションを開始する。これは、ステップＳ１で受信される３ＧＰＰ ＵＥ信用証明書に基づいている。このセッションの目的は、後の段階で、ＰＣＲＦからＢＮＧへパケットフィルタをダウンロードすることを可能にするためである。
【００４９】
図４のシグナリング図は、どのようにしてＵＥが３ＧＰＰアクセス認証を使用してネットワークへ接続することになるかの詳細を説明するものである（図４Ａは全体シグナリング図を示し、一方、図４Ｂから図４Ｅは、明確にするために、同一のシグナリング図を４つに分図したものである）。ここで、ＲＧＷとＷｉＦｉ ＡＰは、図４に組み込まれていることに注意されたい。また、ＮＡＴを想定している。
【００５０】
図４のシグナリング図では、ＢＮＧはＤｉａｍｅｔｅｒリレーとして動作する。こうすることで、Ｄａｉｍｅｔｅｒシグナリングをスプーフ（spoof）することができる。代替のソリューションは、ＲＧＷから直接ＡＡＡサーバへＤｉａｍｅｔｅｒシグナリングを送信することである。ＡＡＡサーバは、ゲートウェイセッションを開始するために、ＢＮＧへシグナリングすることができる。
【００５１】
図４のシグナリング図は、８０２．１Ｘが認証プロトコルとして使用される。これは、とりわけ、ＷｉＦｉ ＡＰ（即ち、８０２．１Ｘ認証器）が適切に構成設定されることを必要とする。つまり、ＡＡＡサーバのＩＰアドレスを把握することを必要とし、また、そのＡＡＡサーバを用いてＲａｄｉｕｓ／Ｄｉａｍｅｔｅｒ共有シークレットを有することを必要とする。これは、おそらく、ＷｉＦｉ ＡＰがオペレータによって所有され、そして、管理される場合に実現される。しかしながら、ほとんどの場合、ＷｉＦｉ ＡＰはユーザによって所有され、そして、管理される。そのため、このソリューションは、配備の課題を生じる。
【００５２】
別の認証プロトコルの候補には、ダイナミックホストコンフィグレーションプロトコル（ＤＨＣＰ）認証がある。しかしながら、このプロトコルは、主に、固定アクセス向けのＲＧＷの認証に対して記述されている。プロトコルの更新は、より汎用的なものにすることが要求され、そうすることで、ユーザが一様にＤＨＣＰ認証を使用することができる。ＩＰｖ６の状況では、ＤＨＣＰはＩＰアドレスを取得するために要求されない。その結果、ＩＰｖ６においてＤＨＣＰ認証を使用することは不利益である。
【００５３】
更にまた別の候補には、ネットワークアクセス用認証搬送プロトコル（ＰＡＮＡ）がある。上述の状況で適切に動作するためにこのプロトコルに対しては、ＲＧＷは、ブリッジされていることを必要とする。今日、ほとんどの場合、ＲＧＷはＮＡＴ化されている。これは、本発明の実施形態に関連する状況におけるＰＡＮＡの有用性を制限する。
【００５４】
本発明の実施形態に関連する状況において、上述のプロトコルの任意のものを実装することは、自明なことではない。プロトコル及びコンフィグレーションの少なくとも一方に関して、ＵＥ、ＷｉＦｉ ＡＰ及びＲＧＷの少なくともいずれかについて必要な条件が課されることになる。それゆえ、本発明の実施形態は、３ＧＰＰアクセス認証を伴わないゲートウェイセッション確立を開始する方法を提案する。
【００５５】
上述の課題により関係する状況を用いて、本発明の実施形態をより詳細に説明する。
【００５６】
図５に示される概要図は、どのようにしてＰＣＲＦが、本発明の実施形態のゲートウェイセッション確立を開始することができるかを定義している。
【００５７】
・ステップ０：後述する。
【００５８】
・ステップ１：ローカル認証である。ＵＥはローカルＩＰアドレスを取得する。これには、３ＧＰＰ ＵＥ信用証明書が含まれない。例えば、商用ＯＳを備えるラップトップと同一の手順である（これは、図２のステップ１となる）。
【００５９】
・ステップ２：ＤＳＭＩＰｖ６（デュアルスタックＭＩＰｖ６）トンネルのセットアップである。これには、３ＧＰＰユーザ認証が含まれる。ステップ２の後、ユーザは、ベストエフォート型のトラフィックを実行することができる。多くのステップで、ＱｏＳをセットアップすることが要求される（これは、図２のステップ２となる）。
【００６０】
・ステップ３：インターネットプロトコル接続アクセスネットワーク（ＩＰ−ＣＡＮ）セッションのセットアップである。これは、ステップ２で受信される３ＧＰＰ ＵＥ信用証明書に基づいている。このセッションの目的は、後の段階で、ＰＣＲＦからパケットデータネットワークゲートウェイ（ＰＤＮ−ＧＷ）へパケットフィルタをダウンロードすることを可能にするためである（これは、図２のステップ３となる）。
【００６１】
・ステップ４：ＰＣＲＦは、ＢＮＧに向けてのゲートウェイセッションを開始する（これは、実質的には、図２のステップ４の逆のステップである）。このセッションの目的は、後の段階で、ＰＣＲＦからＢＮＧへパケットフィルタをダウンロードすることを可能にするためである。
【００６２】
ここで、ＰＣＲＦとＢＰＣＦ（ブロードバンドポリシー制御機能）との間のＳ９インタフェースは、ローミングインタフェースであることに注意されたい。ＢＢＦドメインとＥＰＣドメインは、２つの異なるオペレータである可能性がある。ＵＥは移動体であるので、自身のホームオペレータとのローミング協定を有している任意のネットワークに接続することができる。（３ＧＰＰドメインとＢＢＦドメインとの間のインタフェースはＳ９と呼ばれ、これは、ＰＣＲＦとＢＰＣＦとの間で定義される。ＰＣＲＦとＢＧＷとの間でセッションを直接確立することができるが、そのインタフェースはＧｘｘと呼ばれ、Ｇｘｘの上位のセットがＳ９である）。
【００６３】
ＢＮＧがＰＣＲＦ向けのゲートウェイセッションを確立する場合、ＢＮＧはこれをＵＥ信用証明書に基づいて実行する。これはＩＭＳＩであり、ホームネットワークのコード（即ち、ＭＮＣとＭＣＣ）を含んでいる。それゆえ、ＢＮＧは常に正規のＰＣＲＦをアドレス指定することができるようになる。
【００６４】
このことは、ＰＣＲＦがセッションを確立する場合にはあてはまらない。ＵＥ／ＮＡＴの位置についての唯一の手掛かりは、自身のローカルＩＰアドレスである。ＰＧＷはそのアドレスをステップ２で受信し、それをステップ３でＰＣＲＦへ転送する。また、追加の情報を得ないことには、ＰＣＲＦはどのネットワークに向けてアドレスするかを知ることができない。
【００６５】
この問題をどのようにして解決するかについての提案は、共有ＩＰアドレス範囲に基づくことである。この基本的な概念は、各ＢＢＦオペレータが、ＩＰアドレスのどのブロックがＵＥ／ＮＡＴに割り当てられるかを知ることである。
【００６６】
以下の説明では、どのようにしてこの情報をＰＣＲＦへ配信するかについての代替構成を伴う、本発明の様々な異なる実施形態が説明される。ＰＣＲＦへのこの情報の配信は、図５のステップ０で示される。
【００６７】
ここで、図５のステップ４では、ＰＣＲＦは、特定のＢＮＧあるいはＢＰＣＦをアドレス（address）しないことに注意されたい。これは、Ｄｉａｍｅｔｅｒアドレス体系（realm）とＤＲＡ（不図示）を取り扱う。これは、ＥＰＣ（ＴＳ２９．２１３）内のアドレス割当手順に類似している。唯一残っている問題は、どのようしにてＰＣＲＦがＢＰＣＦをアドレスすることであり、これについては、以下で様々なソリューションを提示する。これらのソリューションは包括的なものではないことを明らかであり、当業者であれは、同一の原理に基づいて他のソリューションを容易に考え出すことができるであろう。
【００６８】
第１の実施形態は、ＩＰアドレス範囲の共有がＤＮＳに基づいているソリューションを提示する。図６のシグナリング図は、第１の実施形態に従うスキームを実現する方法の１つの詳細を示している（図６Ａは全体シグナリング図を示し、一方、図６Ｂから図６Ｅは、明確にするために、同一のシグナリング図を４つに分図したものである）。
【００６９】
ＢＢＦドメインでは、ネットワークＩＤにマッピングされているＩＰアドレス範囲が、ＤＮＳサーバに追加される。ネットワークＩＤは、「ims.mnc＜MNC＞.mcc＜MCC＞.3gppnetwork.org（３ＧＰＰ仕様書で定義される）」の形式のドメイン名である。
【００７０】
ＢＢＦ側のＤＲＡは、自身のルーティングテーブルを更新して、ＵＥ／ＮＡＴ ＩＰアドレスを提供するＢＰＣＦを検出することができる。ＢＰＣＦは、ＵＥ／ＮＡＴ ＩＰアドレスを提供するＢＮＧを検出できるように構成されている。
【００７１】
ここで、ＥＰＣドメインは、複数のＰＣＲＦを含むことができることに注意されたい。その場合、Ｄｉａｍｅｔｅｒルーティングエージェント（ＤＲＡ）は、ＴＳ２９．２１３で定義されるように使用される。これは、図６では示されていない。図６は、ＢＢＦ側のＤＲＡだけを示している。
【００７２】
ゲートウェイセッションを開始するために、ＰＣＲＦは、ＵＥ／ＮＡＴアドレスに基づくリバースＤＮＳルックアップを用いて開始する。ＤＮＳは、ネットワークＩＤをリプライすることになる。これは、ＢＢＦドメイン内のＤＲＡをアドレス指定するための宛先アドレス体系ＡＶＰ（デスティネーションレルムＡＶＰ（Destination-Realm AVP））で使用される。
【００７３】
「所有ＩＰアドレス範囲のコンフィグレーション」と呼ばれるブロックは、図示のような機能を果たしている。ここでは、どのようにしてこのブロックが実装されるべきかについては詳細に説明しない。これは、マニュアルでセットアップすることもできるし、一部を自動とすることもできる。
【００７４】
第２の実施形態は、ＩＰアドレス範囲の共有がＤＲＡルーティングコンフィグレーションに基づいているソリューションを提示する。図７のシグナリング図は、第２の実施形態に従うスキームを実現する方法の１つの詳細を示している（図７Ａは全体シグナリング図を示し、一方、図７Ｂから図７Ｅは、明確にするために、同一のシグナリング図を４つに分図したものである）。
【００７５】
図７に示される第２の実施形態では、セッションを開始するためにＢＰＣＦへＰＣＲＦによって送信されるメッセージは、特別なフォーマットの宛先アドレス体系ＡＶＰを含んでいる。宛先アドレス体系は、対象のＵＥ／ＮＡＴのＩＰＤアドレスから構築され、これは、どのようにしてＤＮＳ名がリバースＤＮＳルックアップに対するＩＰアドレスから構築されるかの形態に類似している（ＲＦＣ３５９６あるいはＲＦＣ２３１７におけるセクション２．５参照）。
【００７６】
これを動作させるために、３ＧＰＰドメインのＤＲＡは、適切に構成設定される必要がある。これは、ＢＢＦドメインからのコンフィグレーションメッセージから受信されるルーティング情報に基づいて実行される（図７の信号４）。ＢＢＦ側のＤＲＡは、自身のルーティングテーブルを更新して、ＵＥ／ＮＡＴ ＩＰアドレスを提供するＢＰＣＦを検出することができる。ＢＰＣＦは、ＵＥ／ＮＡＴ ＩＰアドレスを提供するＢＮＧを検出することができるように構成される。
【００７７】
「所有ＩＰアドレス範囲のコンフィグレーション」と呼ばれるブロックは、図示のような機能を果たしている。ここでは、どのようにしてこのブロックが実装されるべきかについては詳細に説明しない。これは、マニュアルでセットアップすることもできるし、一部を自動とすることもできる。
【００７８】
第３の実施形態は、ＩＰアドレス範囲の共有が分散マッピングデータベースに基づいているソリューションを提示する。上述の第１の実施形態と第２の実施形態は、既存のデータベース構造を再使用することを試行する。これがいくつかの理由で望ましくない場合、第３の実施形態のように新規のデータベースを導入することができる。
【００７９】
図８のシグナリング図は、第３の実施形態に従うスキームを実現する方法の１つの詳細を示している（図８Ａは全体シグナリング図を示し、一方、図８Ｂから図８Ｅは、明確にするために、同一のシグナリング図を４つに分図したものである）。
【００８０】
ＢＢＦドメイン内では、どのＩＰアドレス範囲がどのＢＮＧによって提供され、また、どのＢＮＧがどのＢＰＣＦによって提供されるかをリストにしているローカルマッピングデータベースが存在する。このデータベースは、ここでは更には詳細には説明しない。なぜなら、ほとんどの場合、今日では、このようなデータベースは、既に、ＢＢＦドメイン内（Ａ−ＲＡＣＦの一部として）に存在しているからである。このローカルマッピングデータベースを使用することで、ＤＲＡは、ＵＥ／ＮＡＴアドレスをアドレス指定するためのＢＰＣＦを検出することができる。同様に、ＢＰＣＦは、アドレス指定するためのＢＮＧを検出することができる。
【００８１】
各ＢＢＦオペレータは、すべてのネットワークに、それらのネットワークがアドレスブロックについてのローミング協定を有し、そして、それらのネットワークがＵＥ／ＮＡＴへアドレスを割り当てるために使用することを通知する。これらのブロックは、ＥＰＣドメインのＰＣＲＦに記憶される。即ち、ＰＣＲＦは、（ＢＢＦ）ネットワークＩＤにマッピングされる範囲のリストを維持している。ＵＥ／ＮＡＴアドレスを使用して、ＰＣＲＦはこのリストを照会し、ネットワークＩＤを検出する。ネットワークＩＤを使用することで、正規のＢＢＦネットワークをアドレス指定することができる。
【００８２】
ここで、ＥＰＣドメインは複数のＰＣＲＦを含んでいる場合があることに注意されたい。この場合、Ｄｉａｍｅｔｅｒルーティングエージェント（ＤＲＡ）は、ＴＳ２９．２１３で定義されるように使用される。これについては、シグナリング図には示されていない。
【００８３】
「所有ＩＰアドレス範囲のコンフィグレーション」と呼ばれるブロックは、図示のような機能を果たしている。ここでは、どのようにしてこのブロックが実装されるべきかについては詳細に説明しない。これは、マニュアルでセットアップすることもできるし、一部を自動とすることもできる。
【００８４】
上述のステップ群の１つ以上の動作が、デバイスあるいはノード上の、あるいは装置上で動作するプログラムによって制御することができることは明らかであろう。このような動作プログラムは、コンピュータ可読媒体に記憶することができる。あるいは、例えば、インターネットウェブサイトから提供されるダウンロード可能なデータ信号のような信号で実施し得る。装置の請求項は、それ自身による動作プログラムを包含するように解釈されるべきであり、あるいはキャリヤ（搬送波）上のレコードとして、あるは、信号として、あるいはその他の形態として解釈されるべきである。
【００８５】
図９は、本発明を実行する方法が実現されるノード１の図である。本発明を実現する方法を実行するための、ノード１を制御するためのコンピュータプログラムは、プログラム記憶装置３０に記憶される。本発明を実現する方法の実行中に使用されるデータは、データ記憶装置２０に記憶される。本発明を実現する方法の実行中には、プログラムステップがプログラム記憶装置３０からフェッチされ、中央処理ユニット（ＣＰＵ）１０によって実行され、これは、データ記憶装置２０から要求に応じてデータを取得する。
【００８６】
本発明の実施形態の応答からの結果となる出力情報は、データ記憶装置２０に記憶戻すことができる、あるいは、入力／出力（Ｉ／Ｏ）インタフェース４０へ送信することができる。これは、必要に応じて、他のノードへデータを送信するための送信機を備えることができる。同様に、入力／出力（Ｉ／Ｏ）インタフェース４０は、例えば、ＣＰＵ１０によって使用するために、他のノードからデータを受信するための受信機を備えることができる。
【００８７】
添付のシグナリング図のそれぞれは、様々なノードによって交換される一連のメッセージと、その様々なノードによって実行される方法のステップを示しているだけでなく、これらのメッセージを交換するための、あるいはこれらの方法のステップを実行するための、装置を示しているものと見なすことができる。例えば、図６のＰＣＲＦは、ステップ３９のリバースＤＮＳルックアップを実行するための装置を備えるものと見なすことができる（但し、これは、図９に示されるようなＣＰＵによって実行されるプログラムを使用して、一実施形態で実現することができる）。
【００８８】
図５から図８のＰＣＲＦ、ＰＣＦ及びＢＮＧとして使用するために適している装置は、それぞれ図１０から図１２で示される。上述の具体的なネットワークとプロトコル以外のネットワークとプロトコルへの本発明の適用性のために、ＰＣＲＦはポリシーサーバ（あるいは、ポリシー及び課金ルール機能）として参照することができ、ＰＣＦはポリシーサーバ（あるいはポリシー制御機能）として参照することができ、そして、ＢＮＧはゲートウェイノード（あるいは境界ゲートウェイノード）として参照することができる。
【００８９】
３ＧＰＰコアネットワークから非３ＧＰＰアクセスネットワークへポリシーを配備する本発明の実施形態に従う方法が図１３に示される。ポリシーは、非３ＧＰＰアクセスネットワークを介して、移動端末（例えば、ＵＥ）から３ＧＰＰコアネットワークへ確立される接続に関連する。図１３のステップ群と図５から図８のステップ群との対応は以下で説明する。
【００９０】
図１０のポリシーサーバ（ＰＣＲＦ）は、図１３のステップＳ１、Ｓ２ａ、Ｓ３及びＳ４をそれぞれ実行するように構成されている、部分Ｐ１、Ｐ２ａ、Ｐ３、及びＰ４を備える。図１１のポリシーサーバ（ＰＣＦ）は、図１３のステップＳ５ａ、Ｓ６ａ及びＳ７ａをそれぞれ実行するように構成されている、部分Ｐ５ａ、Ｐ６ａ、及びＰ７ａを備える。図１２のゲートウェイノード（ＢＮＧ）は、図１３のステップＳ５ｂ、Ｓ６ｂ及びＳ７ｂをそれぞれ実行するように構成されている、部分Ｐ５ｂ、Ｐ６ｂ、及びＰ７ｂを備える。部分Ｐ１はローカルＩＰアドレス受信ユニットである。部分Ｐ２ａはアクセスネットワーク判定ユニットである。部分Ｐ３はポリシー制御セッション開始及び確立ユニットである。部分Ｐ４はポリシー提供ユニットである。部分Ｐ５ａはポリシー制御セッション確立ユニットである。部分Ｐ６ａはポリシー受信ユニットである。部分Ｐ７ａはポリシー送信ユニット（あるいはポリシー配備準備ユニット）である。部分Ｐ５ｂはポリシー制御セッション確立ユニットである。部分Ｐ６ｂはポリシー受信ユニットである。部分Ｐ７ｂはポリシー配備ユニットである。これらのユニットは、ハードウェアで構成されていても良いし、上述のプログラムによって実現されても良いし、これらの組み合わせによって実現されても良い。例えば、図９を参照すると、これらのユニットの１つ以上のそれぞれは、プログラム記憶装置３０からフェッチされ、ＣＰＵ１０によって実行される適切なプログラムステップによって効果的に提供され、ＣＰＵ１０は、データ記憶装置２０から要求に応じてデータを取得する。１つ以上のユニットは、組み合わされていても良い。
【００９１】
図１３のステップＳ１では、ローカルＩＰアドレスが、部分１による３ＧＰＰコアネットワーク内のポリシーサーバ（ＰＣＲＦ）で受信される。ローカルＩＰアドレスは、接続の確立中に移動端末によって取得されたものである。先の要約の項目を参照すると、これは、一般的にはステップ（３）に対応し、また、ステップ（４）の一部に対応し、これは、ローカルＩＰアドレスの受信を示している。また、これは、一般的には、図６のステップ３２、図７のステップ３４、図８のステップ２９に対応する。
【００９２】
図１３のステップＳ３では、３ＧＰＰコアネットワークから非３ＧＰＰアクセスネットワークへの、ポリシー制御セッションの確立がポリシーサーバ（ＰＣＲＦ）の部分Ｐ３によって開始される。このポリシー制御セッションは、他の部分では、ゲートウェイ制御セッションあるいはゲートウェイセッションとして参照される。ステップＳ３に密接に関連して、ステップＳ１で受信されるローカルＩＰアドレスは、共有ＩＰアドレス割当情報を参照して接続のために使用される非３ＧＰＰアクセスネットワークを判定するために（ステップＳ２ａ）あるいはその非３ＧＰＰアクセスネットワークの判定を可能にするために（ステップＳ２ｂ）、ポリシーサーバ（ＰＣＲＦ）によって使用される。共有ＩＰアドレス割当情報は、複数のそのような非３ＧＰＰアクセスネットワークに割り当てられる、それぞれが異なる範囲のローカルＩＰアドレスを設定する。ステップＳ２ａは、ポリシーサーバ（ＰＣＲＦ）の部分Ｐ２ａによって実行される。ステップＳ２ａの代替としてのステップＳ２ｂは、３ＧＰＰコアネットワーク（３ＧＰＰ ＤＲＡのような）の別のノードによって実行されることになる。先の要約の項目を参照すれば、ステップＳ２ａ／ｂとＳ３は、一般的には、ステップ（４）に対応する。ステップＳ３は、また、一般的には、図６のステップ３８、図７のステップ４０、図８のステップ３５に対応する。ステップＳ２ａは、また、一般的には、図６のステップ３９、図８のステップ３６に対応する。ステップＳ２ｂは、また、一般的には、図７のステップ４３に対応する。
【００９３】
これに関して、共有ＩＰアドレス割当情報は、３ＧＰＰコアネットワークで保持されるＤＮＳデータベースあるいは別のデータベースに記憶されていても良く、そうすることで、ステップＳ２ａ／ｂは、接続のために使用される非３ＧＰＰアクセスネットワークを判定するためにローカルＩＰアドレスに基づいてデータベースにおけるルックアップ動作を実行すること、あるいは、ローカルＩＰアドレスに基づいてそのようなルックアップ動作を実行することを別のノードに実現可能にするために、その別のノードへローカルＩＰアドレスを提供することに関与する。ＤＮＳのオプションは、ステップ３９のリバースＤＮＳルックアップであるステップＳ２ａとともに、図６を参照して第１の実施形態で記載される。ＤＮＳデータベース以外のデータベースを使用するオプションは、図７及び図８をそれぞれ参照する第２の実施形態及び第３の実施形態で記載される。
【００９４】
第２の実施形態（図７）では、他のデータベースは３ＧＰＰ ＤＲＡであり、これは、図７のステップ４３の接続のために使用される非３ＧＰＰアクセスネットワークを判定することを３ＧＰＰ ＤＲＡに可能にするために、図７のステップ４２の３ＧＰＰ ＤＲＡへローカルＩＰＤアドレスを提供するポリシーサーバ（ＰＣＲＦ）を備える。第３の実施形態（図８）では、他のデータベースはポリシーサーバ（ＰＣＲＦ）によって保持され、これは、図８のステップ３６の接続のために使用される非３ＧＰＰ アクセスネットワークを判定するポリシーサーバ（ＰＣＲＦ）を備える。
【００９５】
ステップＳ３の一方として、ポリシーサーバ（ＰＣＦ）と非３ＧＰＰアクセスネットワークのゲートウェイノード（ＢＮＧ）とは協働して、それぞれ部分Ｐ５ａと部分Ｐ５ｂを使用するステップＳ５ａ及びステップＳ５ｂにおいて、ポリシー制御セッションの確立（上述のステップＳ３を参照して説明される３ＧＰＰコアネットワークによって開始されているポリシー制御セッションの確立）を支援する。先の要約の項目を参照すれば、ステップＳ５ａ／ｂはステップ（５）のいくつかの点に対応する。ステップＳ５ａは、また、一般的には、図６のステップ３８及び４３、図７のステップ４０及び４８、図８のステップ３５及び４６に対応し、あるいは、ポリシーサーバ（ＰＣＦ）に関連するこれらのステップの少なくとも一部に対応する。ステップＳ５ｂは、また、図６のステップ３８及び４３、図７のステップ４０及び４８、図８のステップ３５及び４６に対応し、あるいは、ゲートウェイノード（ＢＮＧ）に関連するこれらのステップの少なくとも一部に対応する。
【００９６】
ステップＳ４において、ポリシーサーバ（ＰＣＲＦ）の部分Ｐ４は、ステップＳ３、Ｓ５ａ及びＳ５ｂの結果として確立されるポリシー制御セッションを使用して非３ＧＰＰアクセスネットワークへポリシーを提供する。このポリシーは、確立された接続に関連する非３ＧＰＰアクセスネットワークにおける配備のためであり、そして、それについての使用は、一般的には、要約の項目と、要約の前の項目で、上述したものとなる。ステップＳ４は、図６のステップ４７、図７のステップ５２、図８のステップ５０に対応する（それぞれ、ＱｏＳルールの提供に関連する）。
【００９７】
ステップＳ６ａとＳ６ｂにおいて、ポリシーは、ステップＰ６ａとＰ６ｂを使用して、それぞれポリシーサーバ（ＰＣＦ）とゲートウェイノード（ＢＮＧ）によってポリシー制御セッションを介して受信される。ステップＳ６ａは、一般的には、図６のステップ４８、図７のステップ５３、図８のステップ５１に対応する。ステップＳ６ｂは、一般的には、図６のステップ５１／５２、図７のステップ５６／５７、図８のステップ５４／５５に対応する。
【００９８】
ステップＳ７ａにおいて、ポリシーサーバ（ＰＣＦ）の部分Ｐ７ａは、ゲートウェイノード（ＢＮＧ）へポリシーを送信することによって、確立される接続に関連してポリシーの配備を準備して、そうすることで、ステップＳ７ａはステップＳ６ｂに先行する。ステップＳ７ａは、一般的には、図６のステップ５１、図７のステップ５６、図８のステップ５４に対応する。
【００９９】
ステップＳ７ｂにおいて、ゲートウェイノード（ＢＮＧ）の部分Ｐ７ｂは、確立された接続に関連してポリシーを配備する。ステップＳ７ｂは、一般的には、図６のステップ５２、図７のステップ５７、図８のステップ５５に対応する。
【０１００】
上述のように、これは、Ｇｘｘインタフェースを使用してＰＣＲＦとＢＮＧとの間で直接確立されるポリシー制御セッションに対して可能である。
【０１０１】
上述のポリシーはＱｏＳポリシーであっても良いし、あるいはＱｏＳポリシーを備えても良く、本発明の実施形態は、３ＧＰＰコアネットワークを非３ＧＰＰアクセスネットワークへの他のタイプのポリシーを配備のために有用である。３ＧＰＰコアネットワークは、進化型パケットコアネットワークを備えても良い。非３ＧＰＰアクセスネットワークは、ＢＢＦネットワークを備えても良い。
【０１０２】
３ＧＰＰ ＴＲ２３．８３９ Ｖ０．３．０は、Ｓ２ｃ及びＳ２ｂを対象とする、ＢＢＦアクセス相互作用の研究あるいはサポートを立案している。Ｓ２ａ（上述のように）は、３ＧＰＰ ＴＲ２３．８３９ Ｖ０．３．０では対象とされていないが、本発明の実施形態に従うＰＣＲＦで開始されるゲートウェイ制御セッション確立をＳ２ａ、Ｓ２ｂ及びＳ２ｃに対して使用することができることが当業者によって明らかであろう。
【０１０３】
本発明の範囲から逸脱することなく上述の実施形態を様々に変形することができることが当業者には理解されるであろう。例えば、上述の実施形態は３ＧＰＰネットワークの一部を参照して説明されているが、本発明の実施形態は、同様の機能コンポーネントを有する３ＧＰＰネットワークの後継となる同様のネットワークにも適用可能となることが容易に理解されるであろう。本願の請求項における用語「３ＧＰＰ」と「非３ＧＰＰ」は、それに従って解釈されるべきである。同様に、本発明の実施形態は、ＢＢＦのような非３ＧＰＰアクセスネットワークに制限されるものではなく、任意の非３ＧＰＰアクセスネットワークに適用可能である。
【０１０４】
付録
図４、６、７及び８のシグナリング図は、https://sourceforge.net/projects/msc-generator/から利用可能な「msc-generator」ツールを使用して生成したものである。このツールは、テキスト記述から通信アプリケーション用のシグナリング図（メッセージシーケンスチャート）を描画するためのツールである。完全性のために、図４、６、７及び８それぞれを生成するために使用される完全なテキスト記述を以下に含める。以下のテキスト記述は、添付のシグナリング図からは明らかでない更なる情報を伝えるために、いくつかの色付け及び陰影付け効果を含んでいる。
【０１０５】
【数１】
【０１０６】
【数２】
【０１０７】
【数３】
【０１０８】
【数４】
【０１０９】
【数５】
【０１１０】
【数６】
【０１１１】
【数７】
【０１１２】
【数８】
【０１１３】
【数９】
【０１１４】
【数１０】
【０１１５】
【数１１】
【０１１６】
【数１２】
【０１１７】
【数１３】
【０１１８】
【数１４】
【０１１９】
【数１５】
【０１２０】
【数１６】
【技術分野】
【０００１】
本発明は、非３ＧＰＰアクセスネットワークを介して、３ＧＰＰコアネットワークへ移動端末を接続するためのスキームにおけるゲートウェイセッション確立のための方法及び装置に関するものである。この方法は、固定網と移動網のコンバージェンス（収束）における特定用途を見い出せる。
【背景技術】
【０００２】
電気通信における現在の傾向は、固定ネットワークと移動ネットワークのコンバージェンス（収束）であり、これは、固定網と移動網のコンバージェンス（ＦＭＣ（Fixed Mobile Convergence））として知られる。ＩＰベースの技術を使用して進化中のネットワークの動向は、固定ネットワークと移動ネットワークとで共通していて、これは、収束をより容易にすることである。ＦＭＣによって、移動ネットワークオペレータと固定ネットワークオペレータは、より効率的に自身のネットワークリソースを利用することが可能となり、これは、資本支出と事業費（ＣＡＰＥＸとＯＰＥＸ）の削減をもたらすことになる。例えば、ユーザが自宅でマルチメディアテレフォニー（ＭＭＴｅｌ）のようなＩＰベースのアプリケーションを実行している場合には、無線アクセスネットワークではなくむしろ固定アクセスネットワークのブロードバンド接続性を利用することがより効率的である。
【０００３】
宅内ネットワークはＦＭＣの成功の鍵となる。なぜなら、それらは、通常のユーザによってほぼ共通に使用される固定ネットワークアクセスであるからである。それゆえ、宅内ネットワークを通じて移動電話を改良型パケットコア（ＥＰＣ：「非３ＧＰＰアクセス用アーキテクチャの拡張」、３ＧＰＰ ＴＳ ２３．４０２、Ｖ８．２．０、２００８年６月参照）へ移動電話を接続することができることが重要である。以下では、用語、ユーザ機器（ＵＥ）は、用語、移動端末あるいは移動電話の代わりに使用することにする。用語ＵＥは、第３世代パートナシッププロジェクト（３ＧＰＰ）の文献でも知られている。
【０００４】
３ＧＰＰは、移動体２Ｇ／３Ｇ／ＬＴＥアクセス及び「非３ＧＰＰアクセス」（ＴＳ２３．４０２）を定義する。後者は、固定ネットワークであり得る。多くのＵＥは、複数の無線インタフェースを提供することによってＦＭＣの動向を取り扱っている。この無線インタフェースには２Ｇ／３Ｇ／ＬＴＥアクセスへ接続するためのインタフェースや、固定ネットワークに接続するためのＷｉＦｉインタフェースがある。
【０００５】
ＴＳ２３．４０２は、ＵＥを、非３ＧＰＰアクセスネットワークを介して３ＧＰＰコアネットワーク（ＥＰＣ）へ接続するための様々な方法を定義している。これらのインタフェースは、プロキシモバイルＩＰ（ＰＭＩＰ）プロトコルあるいはクライアントモバイルＩＰ（ＣＭＩＰ）プロトコルのどちらかを使用する。本明細書では、通常、ＣＭＩＰの使用が想定される。即ち、Ｓ２ｃとして知られるインタフェースである。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
本出願人は、上述の状況で以下の技術的課題を認識している。
【０００７】
高度な使用の場合に対しては、例えば、ＩＭＳボイスコールを行うことに対しては、ＱｏＳセットアップは、ＥＰＣと非３ＧＰＰアクセスの両方で要求される。Ｓ２ｃに対してこれをどのようにして行うかについては、ＴＳ２３．４０２で定義される。以下のこれらの定義は、非３ＧＰＰアクセスドメイン内の境界ゲートウェイ（ＢＧＷ）が、ＥＰＣ（ポリシー及び課金ルール機能あるいはＰＣＲＦ）内のポリシーサーバ向けのゲートウェイ制御セッションをセットアップするために要求される。そして、このゲートウェイセッションは、ＱｏＳルールをダウンロードするために使用される。このルールのダウンロードは接続時に実行されるが、その後の段階、例えば、ユーザがアプリケーション向けの新規のセッションを開始する場合に実行される可能性もある。ゲートウェイ制御セッションはユーザ単位で確立される定義によるので、ＢＧＷはＵＥの識別情報を有することが要求される。この識別情報を安全に取得するための唯一の方法は、認証を介在させることである。それゆえ、仕様書では、３ＧＰＰアクセス認証を定義している（即ち、アクセス時のユーザ認証）。
【０００８】
３ＧＰＰアクセス認証は、上位レベルでのみ定義される。特殊な事例での３ＧＰＰアクセス認証を適用する場合、例えば、非３ＧＰＰアクセスネットワークがＢＢＦネットワーク（ＢＢＦはブロードバンドフォーラムを表していて、固定アクセス用の標準化機構：http://www.broadband-forum.org/参照）である場合、仕様書は、特定の認証プロトコルを推進しない。いくつかの候補が検証されているが、これらの候補の有用性は、特定のネットワークトポロジーにかなり依存している。例としては、ユーザが自身の所有するＷｉＦｉＡＰ（アクセスポイント）を構成設定しているか？、あるいは、これがオペレータによってリモートで管理されているか？、宅内ゲートウェイ（ＲＧＷ）でブリッジされているかあるいはルーティングされているか？ＲＧＷにネットワークアドレス変換（ＮＡＴ）が存在するか等である。
【０００９】
出願人によって認識される上述の課題を取り組むことが要望されている。
【課題を解決するための手段】
【００１０】
ＢＢＦネットワークのような非３ＧＰＰアクセスネットワークを介して、移動端末あるいはＵＥから、進化型パケットコアのような３ＧＰＰコアネットワークへの接続を含む方法が提案される。この方法は、固定移動集約スキームでの使用を見い出し、ここでは、移動端末あるいはＵＥは、例えば、ＷｉＦｉを使用して、固定宅内ネットワークを介して、３ＧＰＰコアネットワークへ接続する。
【００１１】
本明細書では、非３ＧＰＰアクセスネットワークにおけるＢＧＷ（あるいはその等価物）と、３ＧＰＰコアネットワークにおけるＰＣＲＦ（あるいはその等価物）との間のゲートウェイ制御セッション（あるいはゲートウェイセッション）を確立するための方法が特に提案される。ゲートウェイ制御セッションは、３ＧＰＰコアネットワークから非３ＧＰＰアクセスネットワークへ、非３ＧＰＰアクセスネットワークを介して移動端末から３ＧＰＰコアネットワークへ確立される接続に関連するポリシーを提供するために確立される。それゆえ、ゲートウェイ制御セッション（あるいはゲートウェイセッション）は、ポリシー制御セッションと見なすことができ、また、ゲートウェイ制御セッション（あるいはゲートウェイセッション）の代わりになるようなものとして参照することができる。
【００１２】
ＢＢＦネットワークが非３ＧＰＰアクセスネットワークである場合、ＢＧＷはＢＮＧとなり得る。この方法は、３ＧＰＰアクセス認証を行うことなく、ゲートウェイセッションの確立を達成する。この方法では、ＰＣＲＦが、ＢＧＷに代わって、ゲートウェイセッションの確立を開始する。そのような方法で、ＰＣＲＦが正規のＢＧＷをアドレス指定することができるようにするために、アドレス割当情報がオペレータ間で共有される。
【００１３】
ゲートウェイセッションの確立のためのスキームは、以下のステップを有するように提案される。（０）アドレス割当情報の共有、（１）ＵＥが取得するローカルＩＰアドレスを用いる、ＵＥのローカル認証、（２）３ＧＰＰコアネットワーク内のＰＤＮゲートウェイへのローカルＩＰアドレスの転送、（３）ＰＣＲＦへのローカルＩＰアドレスの転送、（４）ステップ（３）で受信されるローカルＩＰアドレスとステップ０からのＩＰアドレス割当情報とを使用して、ＰＣＲＦがＢＧＷに向けてのゲートウェイセッションを開始する、（５）ゲートウェイセッションが確立される。
【００１４】
上述のステップ（２）では、ユーザ認証を含む、トンネル（セキュリティゲートウェイ）が、ＵＥと３ＧＰＰコアネットワークにおけるＰＤＮゲートウェイとの間で確立される。ステップ（２）は、以下の段階を備えるように見なすことができる。：Ａ）セキュリティアソシエーションが確立される、次に、Ｂ）移動ＩＰセッションが確立される、そして、最後に、Ｃ）トンネルが確立される。この状況における段階Ｂは重要である。それは、ローカルＩＰアドレスをＰＤＮ ＧＷへ搬送するからである。上述のステップ（３）では、ＩＰセッションが、ステップ（２）で受信されるＵＥ情報を使用して、ＰＤＮゲートウェイとＰＣＲＦとの間で確立される（これは、後の段階で、ＰＣＲＦからＰＤＮへのパケットフィルタのダウンロードを可能にする）。上述のステップ（４）では、ＰＣＲＦは、ステップ（３）で受信されるＵＥ情報とステップ（０）からのアドレス割当情報を使用して、ＰＣＲＦがＢＧＷに向けてのゲートウェイセッションを開始する（このセッションの目的は、後の段階で、ＰＣＲＦからＰＤＮへのパケットフィルタのダウンロードを可能にすることである）。ＰＣＲＦは、一般的には、特定のＢＧＷをアドレス指定しないが、Ｄｉａｍｔｅｒアドレス体系とＤＲＡとをアドレス指定することになる。ＰＣＲＦは、ポリシー制御機能（ＰＣＦ）、あるいは、それと等価の、ＢＢＦネットワークにおけるブロードバンドポリシー制御機能（ＢＰＣＦ）を使用して、ＢＧＷへのゲートウェイセッションを開始することができる。
【００１５】
上述のステップ（０）に関し、この提案は、各非３ＧＰＰアクセスネットワークが、ＩＰアドレスのどのブロックがあるいは範囲がＵＥ／ＮＡＴに割り当てられることができるかを知っていることである。この情報をＰＣＲＦへ配信する、あるいはこの情報をＰＣＲＦ（上述のステップ（４）で使用するため）と共有する、いくつかの方法が可能である。ここでは、このような方法として、ＩＰアドレス範囲を共有する方法が提案される：（ａ）ＤＮＳを使用すること、（ｂ）ＤＲＡルーティングコンフィグレーションを使用すること、及び（ｃ）分散マッピングデータベースを使用することである。ＩＰアドレス割当情報が共有される厳格な方法は重要ではなく、もちろん、本発明は、これらの３つの方法に限定されるものではない。他の共有する方法を使用することができ、これらの方法の２つ以上を組み合わせることも可能であることが理解されるべきである。
【００１６】
上述の方法（群）を用いることで、ＩＰアドレス範囲はネットワークＩＤにマッピングされ、そして、ＤＮＳサーバへ追加される。非３ＧＰＰアクセスネットワークにおけるＤＲＡは、所与のＵＥ／ＮＡＴ ＩＰアドレスを提供するＰＣＦを検出することを可能にするために、自身のルーティングテーブルを更新する。ゲートウェイセッションを開始するために、ＰＣＲＦは、ＵＥ／ＮＡＴアドレスに基づくリバースＤＮＳルックアップを実行する。ＤＮＳはネットワークＩＤでリプライし、そして、これは、非３ＧＰＰアクセスネットワークにおけるＤＲＡをアドレス指定するために使用される（例えば、宛先−アドレス体系 ＡＶＰ）。ＰＣＦは、所与のＵＥ／ＮＡＴ ＩＰアドレスを提供するＢＧＷを検出することを可能にするように構成されている。これは、後述する第１の実施形態で扱われる方法である。
【００１７】
上述の方法（ｂ）を用いると、セッションを開始するために、ＰＣＲＦによってＰＣＦへ送信されるメッセージは、特別なフォーマットの宛先−アドレス体系ＡＶＰを含んでいる。宛先アドレス体系は、対象のＵＥ／ＮＡＴのＩＰアドレスから構築される。これは、どのようにしてＤＮＳ名がリバースＤＮＳルックアップに対するＩＰアドレスから構築されるかに類似している。このことを動作させるために、３ＧＰＰドメインにおけるＤＲＡが適切に構成設定される必要がある。これは、非３ＧＰＰドメインからのコンフィグレーションメッセージから受信されるルーティング情報に基づいている。非３ＧＰＰ側のＤＲＡは、所与のＵＥ／ＮＡＴ ＩＰアドレスを提供するＢＧＷを検出することを可能にするために、自身のルーティングテーブルを更新する。これは、後述する第２の実施形態で扱われる方法である。
【００１８】
上述の方法（ｃ）を用いると、既存のデータベース構造を再使用することに代えて、別のデータベースが導入される。非３ＧＰＰドメイン内では、どのＩＰアドレス範囲がどのＢＧＷによって提供され、また、どのＢＧＷがどのＰＣＦによって提供されるかをリストにしているローカルマッピングデータベースが存在する。このローカルマッピングデータベースを使用することで、ＤＲＡは、所与のＵＥ／ＮＡＴアドレスをアドレス指定するためのＰＣＦを検出することができる。同様に、ＰＣＦは、アドレス指定するためのＢＧＷを検出することができる。各非３ＧＰＰオペレータは、すべてのネットワークに、アドレスブロックについてのローミング協定があり、そして、それをＵＥ／ＮＡＴへアドレスを割り当てるために使用することを通知する。これらのブロックは、３ＧＰＰドメイン内のＰＣＲＦに記憶される、即ち、ＰＣＲＦは、非３ＧＰＰネットワークＩＤにマッピングされる範囲のリストを維持する。ＵＥ／ＮＡＴアドレスを使用することで、ＰＣＲＦは、このリストを問い合わせ、ネットワークＩＤを検出する。ネットワークＩＤを使用することで、正規の非３ＧＰＰネットワークをアドレス指定することができる。これは、後述する第３の実施形態で扱われる方法である。
【００１９】
提案されるスキームでは、少なくともＰＣＲＦ、ＢＰＣＦ及びＢＧＷは、既存のスキームで開示されない新規のステップを実行するように構成されているので、本出願人が所有する権利において新規性がある。以下に記載される他のノードは、新規のステップを実行するものであるので、本出願人が所有する権利において新規性がある。
【００２０】
本明細書で提案される方法を実行する装置を制御するためのプログラムも提案され、これは、装置にロードされる場合、その装置に本明細書で提案される装置となるように動作させる。このプログラムは、搬送媒体で搬送されても良い。この搬送媒体は、記憶媒体であっても良い。この搬送媒体は、送信媒体であっても良い。このようなプログラムによってプログラムされる装置も予想され、それは、そのようなプログラムを含む記憶媒体となるからである。
【００２１】
本明細書で言及されるように、ネットワークコンフィグレーションに依存する、３ＧＰＰアクセス認証を実行するいくつかの方法が存在する。これは、ＵＥあるいは、ＷｉＦｉ ＡＰあるいはＲＧＷ、それらの組み合わせを意味する。その影響は、新規のプロトコルのコンフィグレーションあるいは導入となって現れる。本発明の実施形態は、ＰＣＲＦが開始するゲートウェイセッション確立を提案する。これは、３ＧＰＰアクセス認証に対する必要性を解消するという効果を有する。その結果、ＱｏＳセットアップは、ＵＥ、ＷｉＦｉ ＡＰ及びＲＧＷの少なくとも１つに影響を与えることなく、非３ＧＰＰアクセスにおいて達成される。
【００２２】
本明細書では、３ＧＰＰコアネットワークから非３ＧＰＰアクセスネットワークへポリシーを配備する方法が開示される。ポリシーは、非３ＧＰＰアクセスネットワークを介して、移動端末から３ＧＰＰコアネットワークへ確立される接続に関連する。ローカルＩＰアドレスが３ＧＰＰコアネットワークにおいて受信され、このローカルＩＰアドレスは、接続の確立中に移動端末によって取得される。３ＧＰＰコアネットワークにおいて、ポリシー制御セッションの確立は、３ＧＰＰコアネットワークから非３ＧＰＰアクセスネットワークへと開始される。受信されるローカルＩＰアドレスは、共有ＩＰアドレス割当情報を参照して接続のために使用される非３ＧＰＰアクセスネットワークを判定する、あるいはその判定を可能にするために使用される。共有ＩＰアドレス割当情報は、複数の非３ＧＰＰアクセスネットワークに割り当てられている、それぞれが異なるローカルＩＰアドレスの範囲を設定する。３ＧＰＰコアネットワークにおいて、ポリシー制御セッションを開始するステップの結果として確立されるポリシー制御セッションを使用して、非３ＧＰＰアクセスネットワークへ提供される。このポリシーは、確立される接続に関連する非３ＧＰＰアクセスネットワークに配備するためのものである。
【００２３】
これらのステップは、ポリシー及び課金ルール機能のような、３ＧＰＰコアネットワークにおけるポリシーサーバによって実行されても良い。
【００２４】
共有ＩＰアドレス割当情報は、３ＧＰＰコアネットワークで保持されるＤＮＳデータベースあるいは別のデータベースに記憶されても良い。接続のために使用される非３ＧＰＰアクセスネットワークの判定は、ローカルＩＰアドレスに基づいてデータベースにおけるルックアップ動作を実行することを含んでいても良い。あるいは、そのような判定は、ローカルＩＰアドレスに基づくルックアップ動作を実行することを別のノードに可能にするために、その別のノードへローカルＩＰアドレスを提供することによって実現されても良い。
【００２５】
別のデータベースは、ＤＲＡであっても良い。この方法は、接続のために使用される非３ＧＰＰアクセスネットワークを判定することをＤＲＡへ可能にするために、該ＤＲＡへローカルＩＰアドレスを提供することを含んでいても良い。
【００２６】
別のデータベースは、ポリシーサーバで保持されても良い。
【００２７】
本明細書では、３ＧＰＰコアネットワークから非３ＧＰＰアクセスネットワークにポリシーを配備する方法が開示される。このポリシーは、非３ＧＰＰアクセスネットワークを介して移動端末から３ＧＰＰコアネットワークへ確立される接続に関連する。この方法は、非３ＧＰＰアクセスネットワークにおいて、３ＧＰＰコアネットワークから非３ＧＰＰアクセスネットワークへのポリシー制御セッションの確立を支援することを含み、ポリシー制御セッションの確立は、接続の確立中に移動端末によって取得されるローカルＩＰアドレスを使用して３ＧＰＰコアネットワークによって開始されていて、ローカルＩＰアドレスは、複数の非３ＧＰＰアクセスネットワークに割り当てられている、それぞれが異なるローカルＩＰアドレスの範囲を設定する共有ＩＰアドレス割当情報を参照して接続のために使用される非３ＧＰＰアクセスネットワークを判定する、あるいはその判定を可能にするものである。ポリシーは、非３ＧＰＰアクセスネットワークにおいて、支援するステップの結果として確立されるポリシー制御セッションを使用して受信される。確立される接続に関連して、受信されるポリシーが非３ＧＰＰアクセスネットワークにおいて配備される、あるいはその受信されるポリシーは、そのような配備を行うために非３ＧＰＰアクセスネットワークにおいて準備される。
【００２８】
これらのステップは、非３ＧＰＰアクセスネットワークにおける境界ゲートウェイノードであるゲートウェイノードによって、あるいは、非３ＧＰＰアクセスネットワークにおけるポリシー制御機能であるポリシーサーバによって、あるいは、ゲートウェイノードとポリシーサーバとが協働することによって、実行されても良い。
【００２９】
ポリシーは、ＱｏＳポリシーであっても、あるいはＱｏＳポリシーを有していても良い。
【００３０】
移動端末は、ＵＥを含んでいても良い。
【００３１】
３ＧＰＰコアネットワークは、進化型パケットコアネットワークを含んでいても良い。
【００３２】
非３ＧＰＰアクセスネットワークは、ＢＢＦネットワークを含んでいても良い。
【００３３】
本明細書では、３ＧＰＰコアネットワークで使用するための装置が開示される。この装置は、３ＧＰＰコアネットワークから非３ＧＰＰアクセスネットワークへポリシーを配備するためのものである。このポリシーは、非３ＧＰＰアクセスネットワークを介して移動端末から３ＧＰＰコアネットワークへ確立される接続に関連する。受信機あるいは受信ユニットあるいはそのような手段が、接続の確立中に、移動端末によって取得されているローカルＩＰアドレスを受信するために提供される。プロセッサあるいはプロセッサユニットあるいはそのような手段が、受信されるローカルＩＰアドレスを使用して、３ＧＰＰコアネットワークから非３ＧＰＰアクセスネットワークへのポリシー制御セッションの確立を開始するために提供されることで、共有ＩＰアドレス割当情報を参照して接続のために使用される非３ＧＰＰアクセスネットワークを判定する、あるいはその判定を可能にする。この共有ＩＰアドレス割当情報は、複数の非３ＧＰＰアクセスネットワークに割り当てられている、それぞれが異なるローカルＩＰアドレスの範囲を設定する。プロセッサあるいはプロセッサユニットあるいはそのような手段が、確立されるポリシー制御セッションを使用して非３ＧＰＰアクセスネットワークへポリシーを提供するために提供される。このポリシーは、確立される接続に関連する非３ＧＰＰアクセスネットワークに配備するためのものである。
【００３４】
本明細書では、非３ＧＰＰアクセスネットワークで使用するための装置が開示される。この装置は、３ＧＰＰコアネットワークから非３ＧＰＰアクセスネットワークへポリシーを配備するためのものである。このポリシーは、非３ＧＰＰアクセスネットワークを介して移動端末から３ＧＰＰコアネットワークへ確立される接続に関連する。プロセッサあるいはプロセッサユニットあるいはそのような手段が、３ＧＰＰコアネットワークから非３ＧＰＰアクセスネットワークへのポリシー制御セッションの確立を支援するために提供され、ポリシー制御セッションの確立は、接続の確立中に移動端末によって取得されるローカルＩＰアドレスを使用して３ＧＰＰコアネットワークによって開始されていて、ローカルＩＰアドレスは、複数の非３ＧＰＰアクセスネットワークに割り当てられている、それぞれが異なるローカルＩＰアドレスの範囲を設定する共有ＩＰアドレス割当情報を参照して接続のために使用される非３ＧＰＰアクセスネットワークを判定する、あるいはその判定を可能にするものである。受信機あるいは受信ユニットあるいはそのような手段が、確立されるポリシー制御セッションを使用してポリシーを受信するために提供される。プロセッサあるいはプロセッサユニットあるいはそのような手段が、確立される接続に関連して、受信されるポリシーを配備する、あるいは配備のための準備をするために提供される。
【図面の簡単な説明】
【００３５】
【図１】アーキテクチャの概要を提供するブロック図である。
【図２】３ＧＰＰアクセス認証が使用されない場合のアクセスに接続するための周知の手順に伴う課題を示すステップ群を有するブロック図である。
【図３】アクセスに接続するための３ＧＰＰアクセス認証の使用を示すステップ群を有するブロック図である。
【図４Ａ】３ＧＰＰアクセス認証を含む非３ＧＰＰ（ＢＢＦ）アクセスネットワークに接続するためのシグナリング図である（図４Ａは全体シグナリング図を示し、その詳細が判読しにくいことは問題ではない、それは、図４Ａは図４Ｂから図４Ｅの複製であり、図４Ａは、文字ではなく図式で示したものと見なすことができるからである）。
【図４Ｂ】明確のために、図４Ａのシグナリング図を４つに分図したものの１つを示す図である。
【図４Ｃ】明確のために、図４Ａのシグナリング図を４つに分図したものの１つを示す図である。
【図４Ｄ】明確のために、図４Ａのシグナリング図を４つに分図したものの１つを示す図である。
【図４Ｅ】明確のために、図４Ａのシグナリング図を４つに分図したものの１つを示す図である。
【図５】ＰＣＲＦが開始するゲートウェイセッション確立を示すステップ群を有するブロック図である。
【図６Ａ】ＤＮＳに基づくＩＰアドレス範囲を共有するためのシグナリング図である（図６Ａは全体シグナリング図を示し、その詳細が判読しにくいことは問題ではない、それは、図６Ａは図６Ｂから図６Ｅの複製であり、図６Ａは、文字ではなく図式で示したものと見なすことができるからである）。
【図６Ｂ】明確のために、図６Ａのシグナリング図を４つに分図したものの１つを示す図である。
【図６Ｃ】明確のために、図６Ａのシグナリング図を４つに分図したものの１つを示す図である。
【図６Ｄ】明確のために、図６Ａのシグナリング図を４つに分図したものの１つを示す図である。
【図６Ｅ】明確のために、図６Ａのシグナリング図を４つに分図したものの１つを示す図である。
【図７Ａ】ＤＲＡルーティングコンフィグレーションに基づくＩＰアドレス範囲を共有するためのシグナリング図である（図７Ａは全体シグナリング図を示し、その詳細が判読しにくいことは問題ではない、それは、図７Ａは図７Ｂから図７Ｅの複製であり、図７Ａは、文字ではなく図式で示したものと見なすことができるからである）。
【図７Ｂ】明確のために、図７Ａのシグナリング図を４つに分図したものの１つを示す図である。
【図７Ｃ】明確のために、図７Ａのシグナリング図を４つに分図したものの１つを示す図である。
【図７Ｄ】明確のために、図７Ａのシグナリング図を４つに分図したものの１つを示す図である。
【図７Ｅ】明確のために、図７Ａのシグナリング図を４つに分図したものの１つを示す図である。
【図８Ａ】分散マッピングデータベースに基づくＩＰアドレス範囲を共有するためのシグナリング図である（図８Ａは全体シグナリング図を示し、その詳細が判読しにくいことは問題ではない、それは、図８Ａは図８Ｂから図８Ｅの複製であり、図８Ａは、文字ではなく図式で示したものと見なすことができるからである）。
【図８Ｂ】明確のために、図８Ａのシグナリング図を４つに分図したものの１つを示す図である。
【図８Ｃ】明確のために、図８Ａのシグナリング図を４つに分図したものの１つを示す図である。
【図８Ｄ】明確のために、図８Ａのシグナリング図を４つに分図したものの１つを示す図である。
【図８Ｅ】明確のために、図８Ａのシグナリング図を４つに分図したものの１つを示す図である。
【図９】本発明を実施する方法が実現される場合のノードの構成を示す図である。
【図１０】本発明の実施形態に従う３ＧＰＰコアネットワークにおけるポリシーサーバノードの構成を示す図である。
【図１１】本発明の実施形態に従う非３ＧＰＰアクセスネットワークにおけるポリシーサーバノードの構成を示す図である。
【図１２】本発明の実施形態に従う非３ＧＰＰアクセスネットワークにおけるゲートウェイノードの構成を示す図である。
【図１３】本発明の実施形態に従って実行されるステップ群を示すフローチャートである。
【発明を実施するための形態】
【００３６】
従来技術に関連する上述の技術的な課題を考慮して、本発明の実施形態は、３ＧＰＰアクセス認証を使用することなく、ゲートウェイセッションをセットアップする方法を提案する。ゲートウェイセッションを確立するための構想はＢＧＷ（Ｓ２ｃに対して現在規定される）によるものではなく、ＰＣＲＦによるものである。しかしながら、このようなＰＣＲＦから開始されるゲートウェイセッション確立の実装は付随的な課題をもたらす。これには、どのようにして、ＰＣＲＦが正規のＢＧＷを取り扱うことができるか？である。本発明の実施形態は、オペレータ間でアドレス割当情報を共有することによってこの課題を解決することを提案する。
【００３７】
本発明の実施形態の詳細説明の前に、技術的な課題のより詳細な説明を説明する。
【００３８】
ＴＳ２３．４０２は、どのようにしてＵＥをＳ２ｃを使用して非３ＧＰＰアクセスに接続するかを定義する。ここでは、非３ＧＰＰアクセスがＢＢＦネットワークである状況を想定する。図１は、そのような構成を示している。図では、ＲＧは宅内ゲートウェイを表し、それゆえ、これは、本明細書で言及するＲＧＷと等価である。
【００３９】
まず、３ＧＰＰアクセス認証を伴わない状況を検討する。これについては、図２で示される。このような状況では、ＢＧＷ（本明細書では、ＢＮＧと呼ばれる）はＰＣＲＦに向けてのゲートウェイセッションを確立することができない。図２では、以下のステップが示される。
【００４０】
・ステップ１：ローカル認証である。ＵＥは、ローカルＩＰアドレスを取得する。これには、３ＧＰＰ ＵＥ信用証明書が含まれない。例えば、商用ＯＳを備えるラップトップと同一の手順である。
【００４１】
・ステップ２：ＤＳＭＩＰｖ６（デュアルスタックＭＩＰｖ６）トンネルのセットアップである。これには、３ＧＰＰユーザ認証が含まれる。ステップ２の後、ユーザは、ベストエフォート型のトラフィックを実行することができる。多くのステップで、ＱｏＳをセットアップすることが要求される。
【００４２】
・ステップ３：インターネットプロトコル接続アクセスネットワーク（ＩＰ−ＣＡＮ）セッションのセットアップである。これは、ステップ２で受信される３ＧＰＰ ＵＥ信用証明書に基づいている。このセッションの目的は、後の段階で、ＰＣＲＦからパケットデータネットワークゲートウェイ（ＰＤＮ−ＧＷ）へパケットフィルタをダウンロードすることを可能にするためである。
【００４３】
・ステップ４：ＢＮＧは、ゲートウェイセッションを開始することを必要とする。これは、３ＧＰＰ ＵＥ信用証明書に基づいている。このセッションの目的は、後の段階で、ＰＣＲＦからＢＮＧへパケットフィルタをダウンロードすることを可能にするためである。
【００４４】
しかしながら、ＢＮＧは、ゲートウェイセッションをセットアップするために要求される３ＧＰＰ ＵＥ信用証明書を有していない。結果として、そのＵＥに対するＢＢＦにおけるＱｏＳはセットアップされない。
【００４５】
ここで、３ＧＰＰアクセス認証を伴う状況を検討する。これについては、図３で示される。３ＧＰＰアクセス認証を使用することによって、ＢＮＧはＵＥ信用証明書を取得することができる。これを使用することで、ゲートウェイセッションをセットアップすることができる。図３では、以下のステップが示される。
【００４６】
・ステップ１：ＵＥは、３ＧＰＰアクセス認証を実行する。これには、３ＧＰＰ ＵＥ信用証明書が含まれる。このセットアップは、非３ＧＰＰアクセスの方法とに沿うものであり、３ＧＰＰアクセス認証は、ＴＳ２３．４０２のＳ２Ｃに対してのオプションである。
【００４７】
・ステップ２、３：図２で参照したものである。
【００４８】
・ステップ４：ＢＮＧは、ゲートウェイセッションを開始する。これは、ステップＳ１で受信される３ＧＰＰ ＵＥ信用証明書に基づいている。このセッションの目的は、後の段階で、ＰＣＲＦからＢＮＧへパケットフィルタをダウンロードすることを可能にするためである。
【００４９】
図４のシグナリング図は、どのようにしてＵＥが３ＧＰＰアクセス認証を使用してネットワークへ接続することになるかの詳細を説明するものである（図４Ａは全体シグナリング図を示し、一方、図４Ｂから図４Ｅは、明確にするために、同一のシグナリング図を４つに分図したものである）。ここで、ＲＧＷとＷｉＦｉ ＡＰは、図４に組み込まれていることに注意されたい。また、ＮＡＴを想定している。
【００５０】
図４のシグナリング図では、ＢＮＧはＤｉａｍｅｔｅｒリレーとして動作する。こうすることで、Ｄａｉｍｅｔｅｒシグナリングをスプーフ（spoof）することができる。代替のソリューションは、ＲＧＷから直接ＡＡＡサーバへＤｉａｍｅｔｅｒシグナリングを送信することである。ＡＡＡサーバは、ゲートウェイセッションを開始するために、ＢＮＧへシグナリングすることができる。
【００５１】
図４のシグナリング図は、８０２．１Ｘが認証プロトコルとして使用される。これは、とりわけ、ＷｉＦｉ ＡＰ（即ち、８０２．１Ｘ認証器）が適切に構成設定されることを必要とする。つまり、ＡＡＡサーバのＩＰアドレスを把握することを必要とし、また、そのＡＡＡサーバを用いてＲａｄｉｕｓ／Ｄｉａｍｅｔｅｒ共有シークレットを有することを必要とする。これは、おそらく、ＷｉＦｉ ＡＰがオペレータによって所有され、そして、管理される場合に実現される。しかしながら、ほとんどの場合、ＷｉＦｉ ＡＰはユーザによって所有され、そして、管理される。そのため、このソリューションは、配備の課題を生じる。
【００５２】
別の認証プロトコルの候補には、ダイナミックホストコンフィグレーションプロトコル（ＤＨＣＰ）認証がある。しかしながら、このプロトコルは、主に、固定アクセス向けのＲＧＷの認証に対して記述されている。プロトコルの更新は、より汎用的なものにすることが要求され、そうすることで、ユーザが一様にＤＨＣＰ認証を使用することができる。ＩＰｖ６の状況では、ＤＨＣＰはＩＰアドレスを取得するために要求されない。その結果、ＩＰｖ６においてＤＨＣＰ認証を使用することは不利益である。
【００５３】
更にまた別の候補には、ネットワークアクセス用認証搬送プロトコル（ＰＡＮＡ）がある。上述の状況で適切に動作するためにこのプロトコルに対しては、ＲＧＷは、ブリッジされていることを必要とする。今日、ほとんどの場合、ＲＧＷはＮＡＴ化されている。これは、本発明の実施形態に関連する状況におけるＰＡＮＡの有用性を制限する。
【００５４】
本発明の実施形態に関連する状況において、上述のプロトコルの任意のものを実装することは、自明なことではない。プロトコル及びコンフィグレーションの少なくとも一方に関して、ＵＥ、ＷｉＦｉ ＡＰ及びＲＧＷの少なくともいずれかについて必要な条件が課されることになる。それゆえ、本発明の実施形態は、３ＧＰＰアクセス認証を伴わないゲートウェイセッション確立を開始する方法を提案する。
【００５５】
上述の課題により関係する状況を用いて、本発明の実施形態をより詳細に説明する。
【００５６】
図５に示される概要図は、どのようにしてＰＣＲＦが、本発明の実施形態のゲートウェイセッション確立を開始することができるかを定義している。
【００５７】
・ステップ０：後述する。
【００５８】
・ステップ１：ローカル認証である。ＵＥはローカルＩＰアドレスを取得する。これには、３ＧＰＰ ＵＥ信用証明書が含まれない。例えば、商用ＯＳを備えるラップトップと同一の手順である（これは、図２のステップ１となる）。
【００５９】
・ステップ２：ＤＳＭＩＰｖ６（デュアルスタックＭＩＰｖ６）トンネルのセットアップである。これには、３ＧＰＰユーザ認証が含まれる。ステップ２の後、ユーザは、ベストエフォート型のトラフィックを実行することができる。多くのステップで、ＱｏＳをセットアップすることが要求される（これは、図２のステップ２となる）。
【００６０】
・ステップ３：インターネットプロトコル接続アクセスネットワーク（ＩＰ−ＣＡＮ）セッションのセットアップである。これは、ステップ２で受信される３ＧＰＰ ＵＥ信用証明書に基づいている。このセッションの目的は、後の段階で、ＰＣＲＦからパケットデータネットワークゲートウェイ（ＰＤＮ−ＧＷ）へパケットフィルタをダウンロードすることを可能にするためである（これは、図２のステップ３となる）。
【００６１】
・ステップ４：ＰＣＲＦは、ＢＮＧに向けてのゲートウェイセッションを開始する（これは、実質的には、図２のステップ４の逆のステップである）。このセッションの目的は、後の段階で、ＰＣＲＦからＢＮＧへパケットフィルタをダウンロードすることを可能にするためである。
【００６２】
ここで、ＰＣＲＦとＢＰＣＦ（ブロードバンドポリシー制御機能）との間のＳ９インタフェースは、ローミングインタフェースであることに注意されたい。ＢＢＦドメインとＥＰＣドメインは、２つの異なるオペレータである可能性がある。ＵＥは移動体であるので、自身のホームオペレータとのローミング協定を有している任意のネットワークに接続することができる。（３ＧＰＰドメインとＢＢＦドメインとの間のインタフェースはＳ９と呼ばれ、これは、ＰＣＲＦとＢＰＣＦとの間で定義される。ＰＣＲＦとＢＧＷとの間でセッションを直接確立することができるが、そのインタフェースはＧｘｘと呼ばれ、Ｇｘｘの上位のセットがＳ９である）。
【００６３】
ＢＮＧがＰＣＲＦ向けのゲートウェイセッションを確立する場合、ＢＮＧはこれをＵＥ信用証明書に基づいて実行する。これはＩＭＳＩであり、ホームネットワークのコード（即ち、ＭＮＣとＭＣＣ）を含んでいる。それゆえ、ＢＮＧは常に正規のＰＣＲＦをアドレス指定することができるようになる。
【００６４】
このことは、ＰＣＲＦがセッションを確立する場合にはあてはまらない。ＵＥ／ＮＡＴの位置についての唯一の手掛かりは、自身のローカルＩＰアドレスである。ＰＧＷはそのアドレスをステップ２で受信し、それをステップ３でＰＣＲＦへ転送する。また、追加の情報を得ないことには、ＰＣＲＦはどのネットワークに向けてアドレスするかを知ることができない。
【００６５】
この問題をどのようにして解決するかについての提案は、共有ＩＰアドレス範囲に基づくことである。この基本的な概念は、各ＢＢＦオペレータが、ＩＰアドレスのどのブロックがＵＥ／ＮＡＴに割り当てられるかを知ることである。
【００６６】
以下の説明では、どのようにしてこの情報をＰＣＲＦへ配信するかについての代替構成を伴う、本発明の様々な異なる実施形態が説明される。ＰＣＲＦへのこの情報の配信は、図５のステップ０で示される。
【００６７】
ここで、図５のステップ４では、ＰＣＲＦは、特定のＢＮＧあるいはＢＰＣＦをアドレス（address）しないことに注意されたい。これは、Ｄｉａｍｅｔｅｒアドレス体系（realm）とＤＲＡ（不図示）を取り扱う。これは、ＥＰＣ（ＴＳ２９．２１３）内のアドレス割当手順に類似している。唯一残っている問題は、どのようしにてＰＣＲＦがＢＰＣＦをアドレスすることであり、これについては、以下で様々なソリューションを提示する。これらのソリューションは包括的なものではないことを明らかであり、当業者であれは、同一の原理に基づいて他のソリューションを容易に考え出すことができるであろう。
【００６８】
第１の実施形態は、ＩＰアドレス範囲の共有がＤＮＳに基づいているソリューションを提示する。図６のシグナリング図は、第１の実施形態に従うスキームを実現する方法の１つの詳細を示している（図６Ａは全体シグナリング図を示し、一方、図６Ｂから図６Ｅは、明確にするために、同一のシグナリング図を４つに分図したものである）。
【００６９】
ＢＢＦドメインでは、ネットワークＩＤにマッピングされているＩＰアドレス範囲が、ＤＮＳサーバに追加される。ネットワークＩＤは、「ims.mnc＜MNC＞.mcc＜MCC＞.3gppnetwork.org（３ＧＰＰ仕様書で定義される）」の形式のドメイン名である。
【００７０】
ＢＢＦ側のＤＲＡは、自身のルーティングテーブルを更新して、ＵＥ／ＮＡＴ ＩＰアドレスを提供するＢＰＣＦを検出することができる。ＢＰＣＦは、ＵＥ／ＮＡＴ ＩＰアドレスを提供するＢＮＧを検出できるように構成されている。
【００７１】
ここで、ＥＰＣドメインは、複数のＰＣＲＦを含むことができることに注意されたい。その場合、Ｄｉａｍｅｔｅｒルーティングエージェント（ＤＲＡ）は、ＴＳ２９．２１３で定義されるように使用される。これは、図６では示されていない。図６は、ＢＢＦ側のＤＲＡだけを示している。
【００７２】
ゲートウェイセッションを開始するために、ＰＣＲＦは、ＵＥ／ＮＡＴアドレスに基づくリバースＤＮＳルックアップを用いて開始する。ＤＮＳは、ネットワークＩＤをリプライすることになる。これは、ＢＢＦドメイン内のＤＲＡをアドレス指定するための宛先アドレス体系ＡＶＰ（デスティネーションレルムＡＶＰ（Destination-Realm AVP））で使用される。
【００７３】
「所有ＩＰアドレス範囲のコンフィグレーション」と呼ばれるブロックは、図示のような機能を果たしている。ここでは、どのようにしてこのブロックが実装されるべきかについては詳細に説明しない。これは、マニュアルでセットアップすることもできるし、一部を自動とすることもできる。
【００７４】
第２の実施形態は、ＩＰアドレス範囲の共有がＤＲＡルーティングコンフィグレーションに基づいているソリューションを提示する。図７のシグナリング図は、第２の実施形態に従うスキームを実現する方法の１つの詳細を示している（図７Ａは全体シグナリング図を示し、一方、図７Ｂから図７Ｅは、明確にするために、同一のシグナリング図を４つに分図したものである）。
【００７５】
図７に示される第２の実施形態では、セッションを開始するためにＢＰＣＦへＰＣＲＦによって送信されるメッセージは、特別なフォーマットの宛先アドレス体系ＡＶＰを含んでいる。宛先アドレス体系は、対象のＵＥ／ＮＡＴのＩＰＤアドレスから構築され、これは、どのようにしてＤＮＳ名がリバースＤＮＳルックアップに対するＩＰアドレスから構築されるかの形態に類似している（ＲＦＣ３５９６あるいはＲＦＣ２３１７におけるセクション２．５参照）。
【００７６】
これを動作させるために、３ＧＰＰドメインのＤＲＡは、適切に構成設定される必要がある。これは、ＢＢＦドメインからのコンフィグレーションメッセージから受信されるルーティング情報に基づいて実行される（図７の信号４）。ＢＢＦ側のＤＲＡは、自身のルーティングテーブルを更新して、ＵＥ／ＮＡＴ ＩＰアドレスを提供するＢＰＣＦを検出することができる。ＢＰＣＦは、ＵＥ／ＮＡＴ ＩＰアドレスを提供するＢＮＧを検出することができるように構成される。
【００７７】
「所有ＩＰアドレス範囲のコンフィグレーション」と呼ばれるブロックは、図示のような機能を果たしている。ここでは、どのようにしてこのブロックが実装されるべきかについては詳細に説明しない。これは、マニュアルでセットアップすることもできるし、一部を自動とすることもできる。
【００７８】
第３の実施形態は、ＩＰアドレス範囲の共有が分散マッピングデータベースに基づいているソリューションを提示する。上述の第１の実施形態と第２の実施形態は、既存のデータベース構造を再使用することを試行する。これがいくつかの理由で望ましくない場合、第３の実施形態のように新規のデータベースを導入することができる。
【００７９】
図８のシグナリング図は、第３の実施形態に従うスキームを実現する方法の１つの詳細を示している（図８Ａは全体シグナリング図を示し、一方、図８Ｂから図８Ｅは、明確にするために、同一のシグナリング図を４つに分図したものである）。
【００８０】
ＢＢＦドメイン内では、どのＩＰアドレス範囲がどのＢＮＧによって提供され、また、どのＢＮＧがどのＢＰＣＦによって提供されるかをリストにしているローカルマッピングデータベースが存在する。このデータベースは、ここでは更には詳細には説明しない。なぜなら、ほとんどの場合、今日では、このようなデータベースは、既に、ＢＢＦドメイン内（Ａ−ＲＡＣＦの一部として）に存在しているからである。このローカルマッピングデータベースを使用することで、ＤＲＡは、ＵＥ／ＮＡＴアドレスをアドレス指定するためのＢＰＣＦを検出することができる。同様に、ＢＰＣＦは、アドレス指定するためのＢＮＧを検出することができる。
【００８１】
各ＢＢＦオペレータは、すべてのネットワークに、それらのネットワークがアドレスブロックについてのローミング協定を有し、そして、それらのネットワークがＵＥ／ＮＡＴへアドレスを割り当てるために使用することを通知する。これらのブロックは、ＥＰＣドメインのＰＣＲＦに記憶される。即ち、ＰＣＲＦは、（ＢＢＦ）ネットワークＩＤにマッピングされる範囲のリストを維持している。ＵＥ／ＮＡＴアドレスを使用して、ＰＣＲＦはこのリストを照会し、ネットワークＩＤを検出する。ネットワークＩＤを使用することで、正規のＢＢＦネットワークをアドレス指定することができる。
【００８２】
ここで、ＥＰＣドメインは複数のＰＣＲＦを含んでいる場合があることに注意されたい。この場合、Ｄｉａｍｅｔｅｒルーティングエージェント（ＤＲＡ）は、ＴＳ２９．２１３で定義されるように使用される。これについては、シグナリング図には示されていない。
【００８３】
「所有ＩＰアドレス範囲のコンフィグレーション」と呼ばれるブロックは、図示のような機能を果たしている。ここでは、どのようにしてこのブロックが実装されるべきかについては詳細に説明しない。これは、マニュアルでセットアップすることもできるし、一部を自動とすることもできる。
【００８４】
上述のステップ群の１つ以上の動作が、デバイスあるいはノード上の、あるいは装置上で動作するプログラムによって制御することができることは明らかであろう。このような動作プログラムは、コンピュータ可読媒体に記憶することができる。あるいは、例えば、インターネットウェブサイトから提供されるダウンロード可能なデータ信号のような信号で実施し得る。装置の請求項は、それ自身による動作プログラムを包含するように解釈されるべきであり、あるいはキャリヤ（搬送波）上のレコードとして、あるは、信号として、あるいはその他の形態として解釈されるべきである。
【００８５】
図９は、本発明を実行する方法が実現されるノード１の図である。本発明を実現する方法を実行するための、ノード１を制御するためのコンピュータプログラムは、プログラム記憶装置３０に記憶される。本発明を実現する方法の実行中に使用されるデータは、データ記憶装置２０に記憶される。本発明を実現する方法の実行中には、プログラムステップがプログラム記憶装置３０からフェッチされ、中央処理ユニット（ＣＰＵ）１０によって実行され、これは、データ記憶装置２０から要求に応じてデータを取得する。
【００８６】
本発明の実施形態の応答からの結果となる出力情報は、データ記憶装置２０に記憶戻すことができる、あるいは、入力／出力（Ｉ／Ｏ）インタフェース４０へ送信することができる。これは、必要に応じて、他のノードへデータを送信するための送信機を備えることができる。同様に、入力／出力（Ｉ／Ｏ）インタフェース４０は、例えば、ＣＰＵ１０によって使用するために、他のノードからデータを受信するための受信機を備えることができる。
【００８７】
添付のシグナリング図のそれぞれは、様々なノードによって交換される一連のメッセージと、その様々なノードによって実行される方法のステップを示しているだけでなく、これらのメッセージを交換するための、あるいはこれらの方法のステップを実行するための、装置を示しているものと見なすことができる。例えば、図６のＰＣＲＦは、ステップ３９のリバースＤＮＳルックアップを実行するための装置を備えるものと見なすことができる（但し、これは、図９に示されるようなＣＰＵによって実行されるプログラムを使用して、一実施形態で実現することができる）。
【００８８】
図５から図８のＰＣＲＦ、ＰＣＦ及びＢＮＧとして使用するために適している装置は、それぞれ図１０から図１２で示される。上述の具体的なネットワークとプロトコル以外のネットワークとプロトコルへの本発明の適用性のために、ＰＣＲＦはポリシーサーバ（あるいは、ポリシー及び課金ルール機能）として参照することができ、ＰＣＦはポリシーサーバ（あるいはポリシー制御機能）として参照することができ、そして、ＢＮＧはゲートウェイノード（あるいは境界ゲートウェイノード）として参照することができる。
【００８９】
３ＧＰＰコアネットワークから非３ＧＰＰアクセスネットワークへポリシーを配備する本発明の実施形態に従う方法が図１３に示される。ポリシーは、非３ＧＰＰアクセスネットワークを介して、移動端末（例えば、ＵＥ）から３ＧＰＰコアネットワークへ確立される接続に関連する。図１３のステップ群と図５から図８のステップ群との対応は以下で説明する。
【００９０】
図１０のポリシーサーバ（ＰＣＲＦ）は、図１３のステップＳ１、Ｓ２ａ、Ｓ３及びＳ４をそれぞれ実行するように構成されている、部分Ｐ１、Ｐ２ａ、Ｐ３、及びＰ４を備える。図１１のポリシーサーバ（ＰＣＦ）は、図１３のステップＳ５ａ、Ｓ６ａ及びＳ７ａをそれぞれ実行するように構成されている、部分Ｐ５ａ、Ｐ６ａ、及びＰ７ａを備える。図１２のゲートウェイノード（ＢＮＧ）は、図１３のステップＳ５ｂ、Ｓ６ｂ及びＳ７ｂをそれぞれ実行するように構成されている、部分Ｐ５ｂ、Ｐ６ｂ、及びＰ７ｂを備える。部分Ｐ１はローカルＩＰアドレス受信ユニットである。部分Ｐ２ａはアクセスネットワーク判定ユニットである。部分Ｐ３はポリシー制御セッション開始及び確立ユニットである。部分Ｐ４はポリシー提供ユニットである。部分Ｐ５ａはポリシー制御セッション確立ユニットである。部分Ｐ６ａはポリシー受信ユニットである。部分Ｐ７ａはポリシー送信ユニット（あるいはポリシー配備準備ユニット）である。部分Ｐ５ｂはポリシー制御セッション確立ユニットである。部分Ｐ６ｂはポリシー受信ユニットである。部分Ｐ７ｂはポリシー配備ユニットである。これらのユニットは、ハードウェアで構成されていても良いし、上述のプログラムによって実現されても良いし、これらの組み合わせによって実現されても良い。例えば、図９を参照すると、これらのユニットの１つ以上のそれぞれは、プログラム記憶装置３０からフェッチされ、ＣＰＵ１０によって実行される適切なプログラムステップによって効果的に提供され、ＣＰＵ１０は、データ記憶装置２０から要求に応じてデータを取得する。１つ以上のユニットは、組み合わされていても良い。
【００９１】
図１３のステップＳ１では、ローカルＩＰアドレスが、部分１による３ＧＰＰコアネットワーク内のポリシーサーバ（ＰＣＲＦ）で受信される。ローカルＩＰアドレスは、接続の確立中に移動端末によって取得されたものである。先の要約の項目を参照すると、これは、一般的にはステップ（３）に対応し、また、ステップ（４）の一部に対応し、これは、ローカルＩＰアドレスの受信を示している。また、これは、一般的には、図６のステップ３２、図７のステップ３４、図８のステップ２９に対応する。
【００９２】
図１３のステップＳ３では、３ＧＰＰコアネットワークから非３ＧＰＰアクセスネットワークへの、ポリシー制御セッションの確立がポリシーサーバ（ＰＣＲＦ）の部分Ｐ３によって開始される。このポリシー制御セッションは、他の部分では、ゲートウェイ制御セッションあるいはゲートウェイセッションとして参照される。ステップＳ３に密接に関連して、ステップＳ１で受信されるローカルＩＰアドレスは、共有ＩＰアドレス割当情報を参照して接続のために使用される非３ＧＰＰアクセスネットワークを判定するために（ステップＳ２ａ）あるいはその非３ＧＰＰアクセスネットワークの判定を可能にするために（ステップＳ２ｂ）、ポリシーサーバ（ＰＣＲＦ）によって使用される。共有ＩＰアドレス割当情報は、複数のそのような非３ＧＰＰアクセスネットワークに割り当てられる、それぞれが異なる範囲のローカルＩＰアドレスを設定する。ステップＳ２ａは、ポリシーサーバ（ＰＣＲＦ）の部分Ｐ２ａによって実行される。ステップＳ２ａの代替としてのステップＳ２ｂは、３ＧＰＰコアネットワーク（３ＧＰＰ ＤＲＡのような）の別のノードによって実行されることになる。先の要約の項目を参照すれば、ステップＳ２ａ／ｂとＳ３は、一般的には、ステップ（４）に対応する。ステップＳ３は、また、一般的には、図６のステップ３８、図７のステップ４０、図８のステップ３５に対応する。ステップＳ２ａは、また、一般的には、図６のステップ３９、図８のステップ３６に対応する。ステップＳ２ｂは、また、一般的には、図７のステップ４３に対応する。
【００９３】
これに関して、共有ＩＰアドレス割当情報は、３ＧＰＰコアネットワークで保持されるＤＮＳデータベースあるいは別のデータベースに記憶されていても良く、そうすることで、ステップＳ２ａ／ｂは、接続のために使用される非３ＧＰＰアクセスネットワークを判定するためにローカルＩＰアドレスに基づいてデータベースにおけるルックアップ動作を実行すること、あるいは、ローカルＩＰアドレスに基づいてそのようなルックアップ動作を実行することを別のノードに実現可能にするために、その別のノードへローカルＩＰアドレスを提供することに関与する。ＤＮＳのオプションは、ステップ３９のリバースＤＮＳルックアップであるステップＳ２ａとともに、図６を参照して第１の実施形態で記載される。ＤＮＳデータベース以外のデータベースを使用するオプションは、図７及び図８をそれぞれ参照する第２の実施形態及び第３の実施形態で記載される。
【００９４】
第２の実施形態（図７）では、他のデータベースは３ＧＰＰ ＤＲＡであり、これは、図７のステップ４３の接続のために使用される非３ＧＰＰアクセスネットワークを判定することを３ＧＰＰ ＤＲＡに可能にするために、図７のステップ４２の３ＧＰＰ ＤＲＡへローカルＩＰＤアドレスを提供するポリシーサーバ（ＰＣＲＦ）を備える。第３の実施形態（図８）では、他のデータベースはポリシーサーバ（ＰＣＲＦ）によって保持され、これは、図８のステップ３６の接続のために使用される非３ＧＰＰ アクセスネットワークを判定するポリシーサーバ（ＰＣＲＦ）を備える。
【００９５】
ステップＳ３の一方として、ポリシーサーバ（ＰＣＦ）と非３ＧＰＰアクセスネットワークのゲートウェイノード（ＢＮＧ）とは協働して、それぞれ部分Ｐ５ａと部分Ｐ５ｂを使用するステップＳ５ａ及びステップＳ５ｂにおいて、ポリシー制御セッションの確立（上述のステップＳ３を参照して説明される３ＧＰＰコアネットワークによって開始されているポリシー制御セッションの確立）を支援する。先の要約の項目を参照すれば、ステップＳ５ａ／ｂはステップ（５）のいくつかの点に対応する。ステップＳ５ａは、また、一般的には、図６のステップ３８及び４３、図７のステップ４０及び４８、図８のステップ３５及び４６に対応し、あるいは、ポリシーサーバ（ＰＣＦ）に関連するこれらのステップの少なくとも一部に対応する。ステップＳ５ｂは、また、図６のステップ３８及び４３、図７のステップ４０及び４８、図８のステップ３５及び４６に対応し、あるいは、ゲートウェイノード（ＢＮＧ）に関連するこれらのステップの少なくとも一部に対応する。
【００９６】
ステップＳ４において、ポリシーサーバ（ＰＣＲＦ）の部分Ｐ４は、ステップＳ３、Ｓ５ａ及びＳ５ｂの結果として確立されるポリシー制御セッションを使用して非３ＧＰＰアクセスネットワークへポリシーを提供する。このポリシーは、確立された接続に関連する非３ＧＰＰアクセスネットワークにおける配備のためであり、そして、それについての使用は、一般的には、要約の項目と、要約の前の項目で、上述したものとなる。ステップＳ４は、図６のステップ４７、図７のステップ５２、図８のステップ５０に対応する（それぞれ、ＱｏＳルールの提供に関連する）。
【００９７】
ステップＳ６ａとＳ６ｂにおいて、ポリシーは、ステップＰ６ａとＰ６ｂを使用して、それぞれポリシーサーバ（ＰＣＦ）とゲートウェイノード（ＢＮＧ）によってポリシー制御セッションを介して受信される。ステップＳ６ａは、一般的には、図６のステップ４８、図７のステップ５３、図８のステップ５１に対応する。ステップＳ６ｂは、一般的には、図６のステップ５１／５２、図７のステップ５６／５７、図８のステップ５４／５５に対応する。
【００９８】
ステップＳ７ａにおいて、ポリシーサーバ（ＰＣＦ）の部分Ｐ７ａは、ゲートウェイノード（ＢＮＧ）へポリシーを送信することによって、確立される接続に関連してポリシーの配備を準備して、そうすることで、ステップＳ７ａはステップＳ６ｂに先行する。ステップＳ７ａは、一般的には、図６のステップ５１、図７のステップ５６、図８のステップ５４に対応する。
【００９９】
ステップＳ７ｂにおいて、ゲートウェイノード（ＢＮＧ）の部分Ｐ７ｂは、確立された接続に関連してポリシーを配備する。ステップＳ７ｂは、一般的には、図６のステップ５２、図７のステップ５７、図８のステップ５５に対応する。
【０１００】
上述のように、これは、Ｇｘｘインタフェースを使用してＰＣＲＦとＢＮＧとの間で直接確立されるポリシー制御セッションに対して可能である。
【０１０１】
上述のポリシーはＱｏＳポリシーであっても良いし、あるいはＱｏＳポリシーを備えても良く、本発明の実施形態は、３ＧＰＰコアネットワークを非３ＧＰＰアクセスネットワークへの他のタイプのポリシーを配備のために有用である。３ＧＰＰコアネットワークは、進化型パケットコアネットワークを備えても良い。非３ＧＰＰアクセスネットワークは、ＢＢＦネットワークを備えても良い。
【０１０２】
３ＧＰＰ ＴＲ２３．８３９ Ｖ０．３．０は、Ｓ２ｃ及びＳ２ｂを対象とする、ＢＢＦアクセス相互作用の研究あるいはサポートを立案している。Ｓ２ａ（上述のように）は、３ＧＰＰ ＴＲ２３．８３９ Ｖ０．３．０では対象とされていないが、本発明の実施形態に従うＰＣＲＦで開始されるゲートウェイ制御セッション確立をＳ２ａ、Ｓ２ｂ及びＳ２ｃに対して使用することができることが当業者によって明らかであろう。
【０１０３】
本発明の範囲から逸脱することなく上述の実施形態を様々に変形することができることが当業者には理解されるであろう。例えば、上述の実施形態は３ＧＰＰネットワークの一部を参照して説明されているが、本発明の実施形態は、同様の機能コンポーネントを有する３ＧＰＰネットワークの後継となる同様のネットワークにも適用可能となることが容易に理解されるであろう。本願の請求項における用語「３ＧＰＰ」と「非３ＧＰＰ」は、それに従って解釈されるべきである。同様に、本発明の実施形態は、ＢＢＦのような非３ＧＰＰアクセスネットワークに制限されるものではなく、任意の非３ＧＰＰアクセスネットワークに適用可能である。
【０１０４】
付録
図４、６、７及び８のシグナリング図は、https://sourceforge.net/projects/msc-generator/から利用可能な「msc-generator」ツールを使用して生成したものである。このツールは、テキスト記述から通信アプリケーション用のシグナリング図（メッセージシーケンスチャート）を描画するためのツールである。完全性のために、図４、６、７及び８それぞれを生成するために使用される完全なテキスト記述を以下に含める。以下のテキスト記述は、添付のシグナリング図からは明らかでない更なる情報を伝えるために、いくつかの色付け及び陰影付け効果を含んでいる。
【０１０５】
【数１】
【０１０６】
【数２】
【０１０７】
【数３】
【０１０８】
【数４】
【０１０９】
【数５】
【０１１０】
【数６】
【０１１１】
【数７】
【０１１２】
【数８】
【０１１３】
【数９】
【０１１４】
【数１０】
【０１１５】
【数１１】
【０１１６】
【数１２】
【０１１７】
【数１３】
【０１１８】
【数１４】
【０１１９】
【数１５】
【０１２０】
【数１６】
【特許請求の範囲】
【請求項１】
非３ＧＰＰアクセスネットワークを介して移動端末から３ＧＰＰコアネットワークへ確立される接続に関連するポリシーを、前記３ＧＰＰコアネットワークから前記非３ＧＰＰアクセスネットワークへ配備する方法であって、
前記３ＧＰＰコアネットワークにおいて、
（ａ）前記接続の確立中に、前記移動端末によって取得されているローカルＩＰアドレスを受信するステップと、
（ｂ）前記（ａ）ステップで受信される前記ローカルＩＰアドレスを使用して、前記３ＧＰＰコアネットワークから前記非３ＧＰＰアクセスネットワークへのポリシー制御セッションの確立を開始して、複数の前記非３ＧＰＰアクセスネットワークに割り当てられている、それぞれが異なるローカルＩＰアドレスの範囲を設定する共有ＩＰアドレス割当情報を参照して前記接続のために使用される前記非３ＧＰＰアクセスネットワークを判定する、あるいはその判定を可能にするステップと、
（ｃ）前記（ｂ）ステップの結果として確立される前記ポリシー制御セッションを使用して前記非３ＧＰＰアクセスネットワークへ前記ポリシーとして、前記確立される接続に関連する前記非３ＧＰＰアクセスネットワークに配備するためのポリシーを提供するステップと
を有することを特徴とする方法。
【請求項２】
前記（ａ）、（ｂ）及び（ｃ）ステップは、ポリシー及び課金ルール機能である、前記３ＧＰＰコアネットワークにおけるポリシーサーバによって実行される
ことを特徴とする請求項１に記載の方法。
【請求項３】
前記共有ＩＰアドレス情報は、前記３ＧＰＰコアネットワークで保持されるＤＮＳデータベースあるいは別のデータベースに記憶され、
前記（ｂ）ステップは、前記接続のために使用される前記非３ＧＰＰアクセスネットワークを判定するために、前記ローカルＩＰアドレスに基づいて前記データベースにおけるルックアップ動作を実行する、あるいは、前記ローカルＩＰアドレスに基づくルックアップ動作を実行することを別のノードに実行することを可能にするために、前記別のノードへ前記ローカルＩＰアドレスを提供するステップを備える
ことを特徴とする請求項１または２に記載の方法。
【請求項４】
前記別のデータベースは、ＤＲＡであり、前記接続のために使用される前記非３ＧＰＰアクセスネットワークを判定することを前記ＤＲＡへ可能にするために、該ＤＲＡへ前記ローカルＩＰアドレスを提供する
ことを特徴とする請求項３に記載の方法。
【請求項５】
請求項２に従属する場合において、前記別のデータベースは、前記ポリシーサーバで保持される
ことを特徴とする請求項３に記載の方法。
【請求項６】
非３ＧＰＰアクセスネットワークを介して移動端末から３ＧＰＰコアネットワークへ確立される接続に関連するポリシーを、前記３ＧＰＰコアネットワークから前記非３ＧＰＰアクセスネットワークへ配備する方法であって、
前記非３ＧＰＰアクセスネットワークにおいて、
（ａ）前記３ＧＰＰコアネットワークから前記非３ＧＰＰアクセスネットワークへのポリシー制御セッションの確立を支援するステップであって、前記ポリシー制御セッションの確立は、前記接続の確立中に前記移動端末によって取得されるローカルＩＰアドレスを使用して前記３ＧＰＰコアネットワークによって開始されていて、前記ローカルＩＰアドレスは、複数の前記非３ＧＰＰアクセスネットワークに割り当てられている、それぞれが異なるローカルＩＰアドレスの範囲を設定する共有ＩＰアドレス割当情報を参照して前記接続のために使用される前記非３ＧＰＰアクセスネットワークを判定する、あるいはその判定を可能にするものである、支援するステップと、
（ｂ）前記（ａ）ステップの結果として確立される前記ポリシー制御セッションを使用して前記ポリシーを受信するステップと、
（ｃ）前記確立される接続に関連して、前記（ｂ）ステップで受信される前記ポリシーを配備する、あるいは配備のための準備をするステップと
を有することを特徴とする方法。
【請求項７】
前記（ａ）、（ｂ）及び（ｃ）ステップは、前記非３ＧＰＰアクセスネットワークにおける境界ゲートウェイノードであるゲートウェイノードによって、あるいは、前記非３ＧＰＰアクセスネットワークにおけるポリシー制御機能であるポリシーサーバによって、あるいは、前記ゲートウェイノードと前記ポリシーサーバとが協働することによって、実行される
ことを特徴とする請求項６に記載の方法。
【請求項８】
前記ポリシーは、ＱｏＳポリシーである、あるいはＱｏＳポリシーを有する
ことを特徴とする請求項１乃至７のいずれか１項に記載の方法。
【請求項９】
前記移動端末は、ＵＥを含んでいる
ことを特徴とする請求項１乃至８のいずれか１項に記載の方法。
【請求項１０】
前記３ＧＰＰコアネットワークは、進化型パケットコアネットワークを含んでいる
ことを特徴とする請求項１乃至９のいずれか１項に記載の方法。
【請求項１１】
前記非３ＧＰＰアクセスネットワークは、ＢＢＦネットワークを含んでいる
ことを特徴とする請求項１乃至１０のいずれか１項に記載の方法。
【請求項１２】
非３ＧＰＰアクセスネットワークを介して移動端末から３ＧＰＰコアネットワークへ確立される接続に関連するポリシーを、前記３ＧＰＰコアネットワークから前記非３ＧＰＰアクセスネットワークへ配備するための該３ＧＰＰコアネットワークにおいて使用するための装置であって、
前記３ＧＰＰコアネットワークにおいて、
（ａ）前記接続の確立中に、前記移動端末によって取得されているローカルＩＰアドレスを受信するための手段と、
（ｂ）前記受信される前記ローカルＩＰアドレスを使用して、前記３ＧＰＰコアネットワークから前記非３ＧＰＰアクセスネットワークへのポリシー制御セッションの確立を開始して、複数の前記非３ＧＰＰアクセスネットワークに割り当てられている、それぞれが異なるローカルＩＰアドレスの範囲を設定する共有ＩＰアドレス割当情報を参照して前記接続のために使用される前記非３ＧＰＰアクセスネットワークを判定する、あるいはその判定を可能にするための手段と、
（ｃ）前記確立される前記ポリシー制御セッションを使用して前記非３ＧＰＰアクセスネットワークへ前記ポリシーとして、前記確立される接続に関連する前記非３ＧＰＰアクセスネットワークに配備するためのポリシーを提供するための手段と
を有することを特徴とする装置。
【請求項１３】
非３ＧＰＰアクセスネットワークを介して移動端末から３ＧＰＰコアネットワークへ確立される接続に関連するポリシーを、前記３ＧＰＰコアネットワークから前記非３ＧＰＰアクセスネットワークへ配備するための該３ＧＰＰコアネットワークにおいて使用するための装置であって、
（ａ）前記３ＧＰＰコアネットワークから前記非３ＧＰＰアクセスネットワークへのポリシー制御セッションの確立を支援するための手段であって、前記ポリシー制御セッションの確立は、前記接続の確立中に前記移動端末によって取得されるローカルＩＰアドレスを使用して前記３ＧＰＰコアネットワークによって開始されていて、前記ローカルＩＰアドレスは、複数の前記非３ＧＰＰアクセスネットワークに割り当てられている、それぞれが異なるローカルＩＰアドレスの範囲を設定する共有ＩＰアドレス割当情報を参照して前記接続のために使用される前記非３ＧＰＰアクセスネットワークを判定する、あるいはその判定を可能にするものである、支援するための手段と、
（ｂ）前記確立される前記ポリシー制御セッションを使用して前記ポリシーを受信するための手段と、
（ｃ）前記確立される接続に関連して、前記受信される前記ポリシーを配備する、あるいは配備のための準備をするための手段と
を有することを特徴とする装置。
【請求項１４】
請求項１乃至１１のいずれか１項に記載の方法を実行するための装置を制御するためのプログラム。
【請求項１５】
請求項１４に記載のプログラムを含む記憶媒体。
【請求項１】
非３ＧＰＰアクセスネットワークを介して移動端末から３ＧＰＰコアネットワークへ確立される接続に関連するポリシーを、前記３ＧＰＰコアネットワークから前記非３ＧＰＰアクセスネットワークへ配備する方法であって、
前記３ＧＰＰコアネットワークにおいて、
（ａ）前記接続の確立中に、前記移動端末によって取得されているローカルＩＰアドレスを受信するステップと、
（ｂ）前記（ａ）ステップで受信される前記ローカルＩＰアドレスを使用して、前記３ＧＰＰコアネットワークから前記非３ＧＰＰアクセスネットワークへのポリシー制御セッションの確立を開始して、複数の前記非３ＧＰＰアクセスネットワークに割り当てられている、それぞれが異なるローカルＩＰアドレスの範囲を設定する共有ＩＰアドレス割当情報を参照して前記接続のために使用される前記非３ＧＰＰアクセスネットワークを判定する、あるいはその判定を可能にするステップと、
（ｃ）前記（ｂ）ステップの結果として確立される前記ポリシー制御セッションを使用して前記非３ＧＰＰアクセスネットワークへ前記ポリシーとして、前記確立される接続に関連する前記非３ＧＰＰアクセスネットワークに配備するためのポリシーを提供するステップと
を有することを特徴とする方法。
【請求項２】
前記（ａ）、（ｂ）及び（ｃ）ステップは、ポリシー及び課金ルール機能である、前記３ＧＰＰコアネットワークにおけるポリシーサーバによって実行される
ことを特徴とする請求項１に記載の方法。
【請求項３】
前記共有ＩＰアドレス情報は、前記３ＧＰＰコアネットワークで保持されるＤＮＳデータベースあるいは別のデータベースに記憶され、
前記（ｂ）ステップは、前記接続のために使用される前記非３ＧＰＰアクセスネットワークを判定するために、前記ローカルＩＰアドレスに基づいて前記データベースにおけるルックアップ動作を実行する、あるいは、前記ローカルＩＰアドレスに基づくルックアップ動作を実行することを別のノードに実行することを可能にするために、前記別のノードへ前記ローカルＩＰアドレスを提供するステップを備える
ことを特徴とする請求項１または２に記載の方法。
【請求項４】
前記別のデータベースは、ＤＲＡであり、前記接続のために使用される前記非３ＧＰＰアクセスネットワークを判定することを前記ＤＲＡへ可能にするために、該ＤＲＡへ前記ローカルＩＰアドレスを提供する
ことを特徴とする請求項３に記載の方法。
【請求項５】
請求項２に従属する場合において、前記別のデータベースは、前記ポリシーサーバで保持される
ことを特徴とする請求項３に記載の方法。
【請求項６】
非３ＧＰＰアクセスネットワークを介して移動端末から３ＧＰＰコアネットワークへ確立される接続に関連するポリシーを、前記３ＧＰＰコアネットワークから前記非３ＧＰＰアクセスネットワークへ配備する方法であって、
前記非３ＧＰＰアクセスネットワークにおいて、
（ａ）前記３ＧＰＰコアネットワークから前記非３ＧＰＰアクセスネットワークへのポリシー制御セッションの確立を支援するステップであって、前記ポリシー制御セッションの確立は、前記接続の確立中に前記移動端末によって取得されるローカルＩＰアドレスを使用して前記３ＧＰＰコアネットワークによって開始されていて、前記ローカルＩＰアドレスは、複数の前記非３ＧＰＰアクセスネットワークに割り当てられている、それぞれが異なるローカルＩＰアドレスの範囲を設定する共有ＩＰアドレス割当情報を参照して前記接続のために使用される前記非３ＧＰＰアクセスネットワークを判定する、あるいはその判定を可能にするものである、支援するステップと、
（ｂ）前記（ａ）ステップの結果として確立される前記ポリシー制御セッションを使用して前記ポリシーを受信するステップと、
（ｃ）前記確立される接続に関連して、前記（ｂ）ステップで受信される前記ポリシーを配備する、あるいは配備のための準備をするステップと
を有することを特徴とする方法。
【請求項７】
前記（ａ）、（ｂ）及び（ｃ）ステップは、前記非３ＧＰＰアクセスネットワークにおける境界ゲートウェイノードであるゲートウェイノードによって、あるいは、前記非３ＧＰＰアクセスネットワークにおけるポリシー制御機能であるポリシーサーバによって、あるいは、前記ゲートウェイノードと前記ポリシーサーバとが協働することによって、実行される
ことを特徴とする請求項６に記載の方法。
【請求項８】
前記ポリシーは、ＱｏＳポリシーである、あるいはＱｏＳポリシーを有する
ことを特徴とする請求項１乃至７のいずれか１項に記載の方法。
【請求項９】
前記移動端末は、ＵＥを含んでいる
ことを特徴とする請求項１乃至８のいずれか１項に記載の方法。
【請求項１０】
前記３ＧＰＰコアネットワークは、進化型パケットコアネットワークを含んでいる
ことを特徴とする請求項１乃至９のいずれか１項に記載の方法。
【請求項１１】
前記非３ＧＰＰアクセスネットワークは、ＢＢＦネットワークを含んでいる
ことを特徴とする請求項１乃至１０のいずれか１項に記載の方法。
【請求項１２】
非３ＧＰＰアクセスネットワークを介して移動端末から３ＧＰＰコアネットワークへ確立される接続に関連するポリシーを、前記３ＧＰＰコアネットワークから前記非３ＧＰＰアクセスネットワークへ配備するための該３ＧＰＰコアネットワークにおいて使用するための装置であって、
前記３ＧＰＰコアネットワークにおいて、
（ａ）前記接続の確立中に、前記移動端末によって取得されているローカルＩＰアドレスを受信するための手段と、
（ｂ）前記受信される前記ローカルＩＰアドレスを使用して、前記３ＧＰＰコアネットワークから前記非３ＧＰＰアクセスネットワークへのポリシー制御セッションの確立を開始して、複数の前記非３ＧＰＰアクセスネットワークに割り当てられている、それぞれが異なるローカルＩＰアドレスの範囲を設定する共有ＩＰアドレス割当情報を参照して前記接続のために使用される前記非３ＧＰＰアクセスネットワークを判定する、あるいはその判定を可能にするための手段と、
（ｃ）前記確立される前記ポリシー制御セッションを使用して前記非３ＧＰＰアクセスネットワークへ前記ポリシーとして、前記確立される接続に関連する前記非３ＧＰＰアクセスネットワークに配備するためのポリシーを提供するための手段と
を有することを特徴とする装置。
【請求項１３】
非３ＧＰＰアクセスネットワークを介して移動端末から３ＧＰＰコアネットワークへ確立される接続に関連するポリシーを、前記３ＧＰＰコアネットワークから前記非３ＧＰＰアクセスネットワークへ配備するための該３ＧＰＰコアネットワークにおいて使用するための装置であって、
（ａ）前記３ＧＰＰコアネットワークから前記非３ＧＰＰアクセスネットワークへのポリシー制御セッションの確立を支援するための手段であって、前記ポリシー制御セッションの確立は、前記接続の確立中に前記移動端末によって取得されるローカルＩＰアドレスを使用して前記３ＧＰＰコアネットワークによって開始されていて、前記ローカルＩＰアドレスは、複数の前記非３ＧＰＰアクセスネットワークに割り当てられている、それぞれが異なるローカルＩＰアドレスの範囲を設定する共有ＩＰアドレス割当情報を参照して前記接続のために使用される前記非３ＧＰＰアクセスネットワークを判定する、あるいはその判定を可能にするものである、支援するための手段と、
（ｂ）前記確立される前記ポリシー制御セッションを使用して前記ポリシーを受信するための手段と、
（ｃ）前記確立される接続に関連して、前記受信される前記ポリシーを配備する、あるいは配備のための準備をするための手段と
を有することを特徴とする装置。
【請求項１４】
請求項１乃至１１のいずれか１項に記載の方法を実行するための装置を制御するためのプログラム。
【請求項１５】
請求項１４に記載のプログラムを含む記憶媒体。
【図１】
【図２】
【図３】
【図４Ｂ】
【図４Ｃ】
【図４Ｄ】
【図４Ｅ】
【図５】
【図６Ｂ】
【図６Ｃ】
【図６Ｄ】
【図６Ｅ】
【図７Ｂ】
【図７Ｃ】
【図７Ｄ】
【図７Ｅ】
【図８Ｂ】
【図８Ｃ】
【図８Ｄ】
【図８Ｅ】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図４Ａ】
【図６Ａ】
【図７Ａ】
【図８Ａ】
【図２】
【図３】
【図４Ｂ】
【図４Ｃ】
【図４Ｄ】
【図４Ｅ】
【図５】
【図６Ｂ】
【図６Ｃ】
【図６Ｄ】
【図６Ｅ】
【図７Ｂ】
【図７Ｃ】
【図７Ｄ】
【図７Ｅ】
【図８Ｂ】
【図８Ｃ】
【図８Ｄ】
【図８Ｅ】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図４Ａ】
【図６Ａ】
【図７Ａ】
【図８Ａ】
【公表番号】特表２０１３−５１６８２１（Ｐ２０１３−５１６８２１Ａ）
【公表日】平成２５年５月１３日（２０１３．５．１３）
【国際特許分類】
【出願番号】特願２０１２−５４６４０５（Ｐ２０１２−５４６４０５）
【出願日】平成２２年１１月３０日（２０１０．１１．３０）
【国際出願番号】ＰＣＴ／ＥＰ２０１０／０６８４９０
【国際公開番号】ＷＯ２０１１／０８２８９５
【国際公開日】平成２３年７月１４日（２０１１．７．１４）
【出願人】（５９８０３６３００）テレフオンアクチーボラゲット エル エム エリクソン（パブル） (2,266)
【Ｆターム（参考）】
【公表日】平成２５年５月１３日（２０１３．５．１３）
【国際特許分類】
【出願日】平成２２年１１月３０日（２０１０．１１．３０）
【国際出願番号】ＰＣＴ／ＥＰ２０１０／０６８４９０
【国際公開番号】ＷＯ２０１１／０８２８９５
【国際公開日】平成２３年７月１４日（２０１１．７．１４）
【出願人】（５９８０３６３００）テレフオンアクチーボラゲット エル エム エリクソン（パブル） (2,266)
【Ｆターム（参考）】
[ Back to top ]