JP5576946B2 - ゲートウェイセッション確立のための方法及び装置 - Google Patents

Description

本発明は、非３ＧＰＰアクセスネットワークを介して、３ＧＰＰコアネットワークへ移動端末を接続するためのスキームにおけるゲートウェイセッション確立のための方法及び装置に関するものである。この方法は、固定網と移動網のコンバージェンス（収束）における特定用途を見い出せる。

電気通信における現在の傾向は、固定ネットワークと移動ネットワークのコンバージェンス（収束）であり、これは、固定網と移動網のコンバージェンス（ＦＭＣ（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」ツールを使用して生成したものである。このツールは、テキスト記述から通信アプリケーション用のシグナリング図（メッセージシーケンスチャート）を描画するためのツールである。完全性のために、図４、６、７及び８それぞれを生成するために使用される完全なテキスト記述を以下に含める。以下のテキスト記述は、添付のシグナリング図からは明らかでない更なる情報を伝えるために、いくつかの色付け及び陰影付け効果を含んでいる。

Claims (12)

1. 非３ＧＰＰアクセスネットワークを介して移動端末から３ＧＰＰコアネットワークへ確立される接続に関連するポリシーを、前記３ＧＰＰコアネットワークから前記非３ＧＰＰアクセスネットワークへ配備する方法であって、
   前記３ＧＰＰコアネットワークにおいて、
   （ａ）前記接続の確立中に、前記移動端末によって取得されているローカルＩＰアドレスを受信するステップ（Ｓ１）と、
   （ｂ）前記（ａ）ステップで受信される前記ローカルＩＰアドレスを使用して、前記３ＧＰＰコアネットワークから前記非３ＧＰＰアクセスネットワークへのポリシー制御セッションの確立を開始して、複数の前記非３ＧＰＰアクセスネットワークに割り当てられている、それぞれが異なるローカルＩＰアドレスの範囲を設定する共有ＩＰアドレス割当情報を参照して前記接続のために使用される前記非３ＧＰＰアクセスネットワークを判定する、あるいはその判定を可能にするステップ（Ｓ３）と、
   （ｃ）前記（ｂ）ステップの結果として確立される前記ポリシー制御セッションを使用して前記非３ＧＰＰアクセスネットワークへ前記ポリシーとして、前記確立される接続に関連する前記非３ＧＰＰアクセスネットワークに配備するためのポリシーを提供するステップ（Ｓ４）と
   を有することを特徴とする方法。
2. 前記（ａ）、（ｂ）及び（ｃ）ステップは、ポリシー及び課金ルール機能である、前記３ＧＰＰコアネットワークにおけるポリシーサーバによって実行される
   ことを特徴とする請求項１に記載の方法。
3. 前記共有ＩＰアドレス情報は、前記３ＧＰＰコアネットワークで保持されるドメインネームシステムであるＤＮＳのＤＮＳデータベースあるいは別のデータベースに記憶され、
   前記（ｂ）ステップは、前記接続のために使用される前記非３ＧＰＰアクセスネットワークを判定するために、前記ローカルＩＰアドレスに基づいて前記データベースにおけるルックアップ動作を実行する、あるいは、前記ローカルＩＰアドレスに基づくルックアップ動作を実行することを別のノードに実行することを可能にするために、前記別のノードへ前記ローカルＩＰアドレスを提供するステップを備える
   ことを特徴とする請求項１または２に記載の方法。
4. 前記別のデータベースは、ＤｉａｍｅｔｅｒルーティングエージェントであるＤＲＡであり、前記接続のために使用される前記非３ＧＰＰアクセスネットワークを判定することを前記ＤＲＡへ可能にするために、該ＤＲＡへ前記ローカルＩＰアドレスを提供する
   ことを特徴とする請求項３に記載の方法。
5. 請求項２に従属する場合において、前記別のデータベースは、前記ポリシーサーバで保持される
   ことを特徴とする請求項３に記載の方法。
6. 前記ポリシーは、ＱｏＳポリシーである、あるいはＱｏＳポリシーを有する
   ことを特徴とする請求項１乃至５のいずれか１項に記載の方法。
7. 前記移動端末は、ＵＥを含んでいる
   ことを特徴とする請求項１乃至６のいずれか１項に記載の方法。
8. 前記３ＧＰＰコアネットワークは、進化型パケットコアネットワークを含んでいる
   ことを特徴とする請求項１乃至７のいずれか１項に記載の方法。
9. 前記非３ＧＰＰアクセスネットワークは、ブロードバンドフォーラムであるＢＢＦのＢＢＦネットワークを含んでいる
   ことを特徴とする請求項１乃至８のいずれか１項に記載の方法。
10. 非３ＧＰＰアクセスネットワークを介して移動端末から３ＧＰＰコアネットワークへ確立される接続に関連するポリシーを、前記３ＧＰＰコアネットワークから前記非３ＧＰＰアクセスネットワークへ配備するための該３ＧＰＰコアネットワークにおいて使用するための装置であって、
    前記３ＧＰＰコアネットワークにおいて、
    （ａ）前記接続の確立中に、前記移動端末によって取得されているローカルＩＰアドレスを受信するための手段（Ｐ１）と、
    （ｂ）前記受信される前記ローカルＩＰアドレスを使用して、前記３ＧＰＰコアネットワークから前記非３ＧＰＰアクセスネットワークへのポリシー制御セッションの確立を開始して、複数の前記非３ＧＰＰアクセスネットワークに割り当てられている、それぞれが異なるローカルＩＰアドレスの範囲を設定する共有ＩＰアドレス割当情報を参照して前記接続のために使用される前記非３ＧＰＰアクセスネットワークを判定する、あるいはその判定を可能にするための手段（Ｐ３）と、
    （ｃ）前記確立される前記ポリシー制御セッションを使用して前記非３ＧＰＰアクセスネットワークへ前記ポリシーとして、前記確立される接続に関連する前記非３ＧＰＰアクセスネットワークに配備するためのポリシーを提供するための手段（Ｐ４）と
    を有することを特徴とする装置。
11. コンピュータによって実行される場合に、前記コンピュータに、請求項１乃至９のいずれか１項に記載の方法を実行するための装置を制御するための、コンピュータ実行可能命令を有するプログラム。
12. 請求項１１に記載のプログラムを含む記憶媒体。