JP2004531134A - 移動通信ネットワーク内にｇｇｓｎ選択するシステム及び方法 - Google Patents

Abstract

移動通信ネットワーク内のデータ呼を提供するためのＧＧＳＮを判定するための方法及びシステムを提供した。メッセージはＳＧＳＮから受信され（３１０）、分析されることによりメッセージがＧＧＳＮの識別を要求するか否か判定される（３１５）。受信したメッセージは、ＧＧＳＮの識別が要求される場合（３１５）、ＧＧＳＮ選択アルゴリズムが実行されることにより、特定のＭＳからのデータ呼を提供するＧＧＳＮを識別する（３２５）。次に応答が構成され、選択したＧＧＳＮを識別するＳＧＳＮに送信する（３３０）。

Description

【技術分野】
【０００１】
本発明は、移動通信ネットワークに関し、より詳細には、移動通信ネットワーク内の総合データ呼に対するＧＧＳＮの選択に関する。
【背景技術】
【０００２】
現行のデジタル無線又は移動通信ネットワークの大部分は第二世代（「２Ｇ」）ネットワークである。主要なプロトコルはＴＤＭＡ，ＧＳＭ、及びＣＤＭＡである。これらのネットワークは（音声とは反対に）データ提供の能力が制約されてきた。典型的なバンド幅は約９．６Ｋビット／秒である。
【０００３】
第三世代（「３Ｇ」）ネットワークが提案されている。ＣＤＭＡ２０００及びＵＭＴＳは、計画された最も普及している２つの第三世代ネットワークである。これらの計画は、規定のネットワークでより多くの音声ユーザにサービスを提供し、「携帯電話」等の、移動局に（１４４Ｋビット／秒以上の）高いデータレートを維持する。
【０００４】
図１は、ＵＭＴＳネットワーク１００の例示的な構成を示す。地域的な「カバー範囲」は、「セル」（図示せず）と呼ばれる複数の小さな地域的な範囲に分割される。カバー範囲内の電源を入れた基地局（ＭＳｓ）１０１は、無線チャネルを経由して対応するノード１０２と通信する。複数のノード１０２ａ−ｎは、リンク１０３ａ−ｎを経由して、対応する無線ネットワークコントローラ（ＲＮＣ）１０４と通信する。ＲＮＣ１０４は、ノードからの通信トラフィックを統合し、ＭＳ１０１により活性化された提供オプションを検出する等の、機能を提供する。ノード１０２及びＲＮＣ１０４の組合せは、ユニバーサル地上無線接続網（ＵＴＲＡＮ）１０５と呼ばれる。潜在的には、ネットワーク内において多くのＵＴＲＡＮがある。
【０００５】
各ＵＴＲＡＮ１０５は、信号リンク１０６及びベアラトランク１０７を経由して、コールサーバ１０８（ＭＳＣサーバ又はセッション制御マネージャとも呼ばれる）と通信し、ＩＰリンク１１０を経由して、ＳＧＳＮ１１１と通信する。ＵＴＲＡＮ及び、音声呼等の、コールサーバ間のトラフィックは、ＡＴＭベースであり得、インターフェースは、Ｉｕ−ｃｓインターフェースにより定義される。コールサーバは音声呼を管理するための制御ロジック、及び着信音声のトラフィックをスイッチングするためのベアラプレーンを有する。
【０００６】
ＵＴＲＡＮとＳＧＳＮとの間のトラフィックは、パケットベースである。ＳＧＳＮへの進入はＧＴＰ（ＧＰＲＳトンネリングプロトコル）チャネルによる。ＳＧＳＮはこれらのチャネルを、コールサーバの制御ロジックからの命令に基づいて切り替える。これらの命令はＩＰパケット内に含まれ、ＳＧＳＮから、コールサーバが命令を受信するリンク１２０及びＩＰネットワーク１１８を経由して、コールサーバに対して送信される。同じように、ＵＴＲＡＮは、ＩＰトラフィックを、ＳＧＳＮ及びＩＰネットワーク１１８，１２０を経由して、コールサーバと通信する。ＧＴＰチャネル内のトラフィックは、ウェブサイトへのトラフィック等のデータトラフィック、又は、パケット化した音声であってもよい。この場合、制御ロジックが、ＱｏＳを考慮する等、このトラフィックに特定の管理を行うことが必要とされる。（ＳＧＳＮは「パケットアクセス制御ノード（Ｓｅｒｖｉｎｇ ＧＰＲＳ Ｓｕｐｐｏｒｔ Ｎｏｄｅ）」の業界頭文語。）コールサーバ１０８及びＳＧＳＮ１１１は複数の（潜在的には異なる）ＵＴＲＡＮ１０５ａ−ｎをそれぞれ処理できる。
【０００７】
Ｉｕ−ＣＳインターフェースが実施された場合、コールサーバ１０８は音声呼に基づく回路の制御を担う。ＵＴＲＡＮ１０５は、このような活性化した呼を検出し、活性化に応答して、コールサーバ１０８に対する必要な信号リンク１０６及びベアラ回線１０７を確立すべく、コールサーバ１０８と協働する。ＵＴＲＡＮとの協働に加えて、コールサーバは、音声ネットワークに対する、対応する信号リンク１１２及びベアラ回線１１４を確立する。より詳細には、コールサーバは、ＳＳ７信号ネットワーク１１３と信号リンクを、ＰＳＴＮベアラ回線ネットワーク１１５とベアラ回線を確立する。したがって、音声呼は、従来の信号及びスイッチングを使用し、回線に基づく技術を使用し、被呼者に送信される。
【０００８】
ＳＧＳＮ１１１は、インターネットリクエスト等の従来のデータ呼及びデータネットワークを通じた音声呼の双方の、データ呼の制御を担う。ＵＴＲＡＮ１０５は、活性化したこのようなコールの検出を担い、活性化に応答して、ＩＰリンク１０９を経由して、ＳＧＳＮ１１１に対する必要なデータパスを確立すべく、ＳＧＳＮ１１１と協働する。ＳＧＳＮは、次にＵＴＲＡＮから開始し、バーチャルプライベートネットワーク又は「ＶＰＮ」を設定するためにＧＧＳＮに対して延伸するＧＴＰチャネルの確立を助ける。スイッチングの機能のための制御ロジックはコールサーバ上にある。（ＧＧＳＮは「パケットゲートウェイノード（Ｇａｔｅｗａｙ ＧＰＲＳ Ｓｕｐｐｏｒｔ Ｎｏｄｅ）」の業界頭文語。）次にＳＧＳＮは受信情報を処理し、プライベートＩＰネットワーク１１８内のチャネル上で搬送され得るＩＰパケットの形式にする。ＧＧＳＮは、潜在的に複数のＳＧＳＮ１１１ｊ−ｌからＩＰパケットを受信し、セキュリティー等、他のサービスの提供に加えて、このようなトラフィックを統合する。次に、統合ＩＰトラフィックは、インターネット１２１等の公共ＩＰネットワーク上に接続され得る。
【０００９】
移動性管理は音声及びデータ呼に対して実行することが必要である。コールサーバ１０８は、回線−切替した音声呼に対して移動端末の管理を担う。コールサーバ内の制御ロジックは、この機能を実行するために、コールサーバと同一場所に配置した在圏ロケーションレジスタ（ＶＬＲ）１１６と接続する。ＶＬＲは、典型的にホームロケーションレジスタ（ＨＬＲ）１１７に格納した情報の部分集合である加入者情報を保持する。ＨＬＲは、音声及びデータ呼の移動性管理を制御するため更新される。回線−切替した音声呼を生成している間に、加入者が移動（ローミング）する際、コールサーバからの適切なＵＴＲＡＮに対する回線接続は、維持されなければならない。コールサーバは、更に、データ呼（パケット化したボイスコールを含む）に対して移動性管理を担う。この場合、適切なＳＧＳＮからの適切なＵＴＲＡＮに対するＧＴＰトンネルは、ネットワーク内において加入者が移動するため、維持される必要がある。データ呼の場合の移動性管理は、このようなトンネルの選択や維持に関連する。この機能を実行するためのロジックは、コールサーバ上にあり、この機能を実行するためにＨＬＲ及びＶＬＲに接続する。
【００１０】
ＭＳ１０１がデータ呼を生成した場合（パケットセッションを開始した場合等）、ＵＴＲＡＮ１０５は信号情報を受信し、データ呼の接近を検出し、ＭＳ１０１からのパケットの受信を開始する。データ呼の接近を検出中に、コールサーバ移動性管理モジュール内で実行されるエージェントソフトウェアは、加入者に対する「ホーム」ＧＧＳＮを含む特定の加入者プロフィール取得するための鍵として、ＭＳの加入者ＩＤ、ＭＳ番号（ＭＳＮ）、端末識別コード等を使用してＨＬＲ１１７に接続する。データ呼が続行すると、ＵＴＲＡＮからデータパケットを受信するＳＳＧＮは、データパケットを、次に公共ＩＰネットワーク１２１，１２２に送信するために、ＩＰネットワーク１１８を通じて、パケットを統合するホームＧＧＳＮに対して送信する。
【発明の開示】
【発明が解決しようとする課題】
【００１１】
発明者は、ＧＧＳＮの静的な割当ては、特定の非効率性と不利益が生じると考える。例えば、ユーザがローミングした場合、トンネル端のＧＧＳＮはユーザからかなり離れてしまう。ネットワークの非効率的な使用（ＩＰパケットがネット−ワーク内で多くのホップに遭遇する必要が生じ得る）となるだけではなく、性能も悪影響を受ける。この性能の不利益は、この手法を、ボイスオーバＩＰコール及び特定のマルチメディアトラフィックのためにネットワークのデータ側を使用するためには、適切ではなくすることがある。
【課題を解決するための手段】
【００１２】
本発明によると、移動通信ネットワーク内のデータ呼を提供するＧＧＳＮを判定する方法及びシステムが提供された。メッセージは、コールサーバ内の制御ロジックから受信され、メッセージがＧＧＳＮの識別を要求するか否か判定するために分析される。受信したメッセージがＧＧＳＮの識別を要求する場合、ＧＧＳＮ選択アルゴリズムは、特定のＭＳからのデータ呼を提供するＧＧＳＮを識別するため実行される。次に、応答が構成され、選択したＧＧＳＮを識別するＳＧＳＮに送信する。
【００１３】
本発明の一形態によると、ＳＧＳＮに最も近いＧＧＳＮが選択される。本発明の別形態によると、特定のＭＳからデータ呼を提供する能力を有するＧＧＳＮが選択される。本発明の別形態によると、ＧＧＳＮは、ネットワークに対してＧＧＳＮを接続するネットワークセグメントの作動状況を考慮して選択される。
【００１４】
本発明の別形態によると、ＩＰパケット受信ロジックは、コールサーバの制御ロジックからメッセージを受信し、ＩＰパケット分析ロジックは、受信したメッセージがＧＧＳＮの識別を要求するか否かを判定する。ＧＧＳＮ選択ロジックは、ＩＰパケット分析ロジックに応答して、特定のＭＳからのデータ呼を提供するＧＧＳＮを識別し、ＩＰパケット応答ロジックは選択したＧＧＳＮを識別するＳＧＳＮに対して応答パケットを構成し、送信する。
【００１５】
本発明の別形態によると、ロジックは、ＨＬＲとの通信内のスイッチプラットフォーム上で実行するソフトウェアロジックである。本発明の別形態によると、ロジックは、ＨＬＲ上でソフトウェアロジックを実行する。本発明の別形態によると、ロジックは、ＨＬＲと協働する付属物上でソフトウェアロジックを実行する。
【００１６】
本発明の別の実施形態では、ＧＧＳＮ選択ロジックは、バッチなどである。ＧＧＳＮ選択アルゴリズムが、実行されることにより、ＳＧＳＮからのデータ呼を提供するＧＧＳＮを識別する。識別したＧＧＳＮがＨＬＲに対して提供されることにより、識別したＧＧＳＮとＳＧＳＮが関連する。
【発明を実施するための最良の形態】
【００１７】
本発明の好適な実施形態は、移動通信ネットワーク内のデータ呼を提供するＧＧＳＮを判定し、及び識別するための新規なシステム及び方法を提供する。より詳細には、本発明の好適な実施形態は、単に全ての場合にホームＧＧＳＮに使用するのではなく、多様な基準に基づいて提供するＧＧＳＮを選択する。選択は、（他のものの中の）ＧＧＳＮの地域的な近さ、ＧＧＳＮの利用可能な能力、ＧＧＳＮと接続するネットワークセグメントの能力、ＧＧＳＮの作動的な状態、ＧＧＳＮのリンクに基づき得る。更に、サービスプロバイダは、同様に、ＧＧＳＮ選択ロジックに含まれ得るＧＧＳＮを選択する方針（ポリシー）を確立し得る。したがって、複数の実施形態は、動的にＧＧＳＮを選択し（ほぼリアルタイムにより）、さらに特定の実施形態は、ネットワーク管理の一部として、バッチタイプの選択をする。
【００１８】
図２は、本発明の好適な実施形態による、無線ネットワーク２００を例示的に示す。同じ番号は、図１と同じ若しくは同様の要素を説明するために使用され、記載は簡潔にするために繰り返さない。システム２００は、プライベートＩＰネットワーク１１８及びＨＬＲ１１７の間に位置し、通信するＨＬＲプロキシスイッチ２０５を有する点が、図１と異なる（当業者は、ＨＬＲ１１７は論理的には単一のデータベースであるが、物理的構成は、複数のインスタンスを有する分散型のデータベースであると理解する）。
【００１９】
好適な実施形態の下において、ＨＬＲプロキシ２０５は、２０００年１１月２２日に受理された、同時継続米国特許第０９／７２１３２９号（本発明の譲渡人に譲渡された）に記載されたプロキシスイッチを使用して実施され、これは参照として完全に組入れられている。より詳細には、同時継続出願により記載されたプロキシスイッチは改良されることにより、ＩＰプロトコルに基づいてＩＰリンクと通信し、本発明で記載したＧＧＳＮ選択ロジックを有する。
【００２０】
同時継続出願に記載したように、プロキシスイッチは、全ての信号メッセージを対応し、さらに設定されることにより、受信した信号メッセージ並びに、セッション及びシステムの状態により一つ以上の幾つかの特定の動作をし得る。この働きは、信号情報が、ＳＳ７信号などの代わりにＩＰパケットに変換されることを除いては、本発明の特定の実施形態により使用される。
【００２１】
特定の実施形態の下、ＨＬＲプロキシスイッチ２０５は、プライベートＩＰネットワーク１１８から受信したＩＰパケットに応答し、以下のことを一つ以上実行する。
１．ＨＬＲプロキシ２０５は、メッセージを変更せずに、ＨＬＲ又はＳＧＳＮに転送する。
【００２２】
２．ＨＬＲプロキシ２０５は、メッセージを遮断して転送せず、代わりに、そのメッセージに対する応答を生成する等、メッセージを制御する。
トリガーイベントに従って実行される動作の種類は、以下に記載される。下記のように、ＨＬＲプロキシ２０５は、他の全てのメッセージを変更せずに転送するが、規定（プレ特定）のメッセージをインターセプトすることが可能なプロキシスイッチを使用して実施され得る。プロキシスイッチは、改良されることにより、３Ｇ又は使用した信号プロトコルを制御し、下記のようにインターセプトしたメッセージに対する応答を生成する。
【００２３】
図３は好適な実施形態のＧＧＳＮ選択ロジックを示すフローチャートである。ロジックは工程３００から開始し、コールサーバ１０８から等、ネットワークから、及びＨＬＲ１１７に向けられた、ＩＰパケットを受信する工程３１０に進む。各パケットは観測される工程３１５により、パケットが既知のユーザのためのＧＧＳＮに対応する情報要素（ＩＥ）を要求するコマンドであるか否か確認する。（上記のように、このような要求は、コールサーバ１０８により開始され、ＨＬＲ１１７に送信することにより、どのＧＧＳＮが、既知のユーザに対するＩＰトラフィックを統合すべきか判定する。上記のように、通常の要求は、次に、ユーザのホームＧＧＳＮに応答するＨＬＲ１１７により受信される。）使用した特定のＩＥは、特定のサービスプロバイダにより供給されるように、ネットワークの標準に基づいて判定される。
【００２４】
パケットがこのようなコマンドを含まない場合、ロジックはパケットを変更せずにＨＬＲ１１７等に転送する工程３２０に進む。従って、ＨＬＲはそれに応じてパケットを制御する。ＨＬＲ１１７が、制御するパケットの一部として応答パケットを送信する場合、ＨＬＲプロキシ２０５は上記のように処理する。特に、ＨＬＲプロキシ２０５は、応答パケットを変更せずに受信し３１０、観測し３１５、及び転送３２０し得る（定義によりＨＬＲからの応答は、ＧＧＳＮを有するＩＥを要求するコマンドを有しない）。この形態により、応答はＳＳＧＮ１１１等、要求元に送信される。
【００２５】
パケットがＧＧＳＮを有するＩＥを要求するコマンドを含む場合、ロジックは、規定のアルゴリズムに基づいてＧＧＳＮを選択する３２５（詳細は下記）。次に、選択したＧＧＳＮは、応答パケットにカプセル化され、ＳＳＧＮ等１１１、要求元に送信される３３０。最初のＩＰパケットはＨＬＲに送信されない。
【００２６】
ＳＳＧＮ１１１が、ＧＧＳＮの識別を要求するパケットを受信することにより使用すると、ＳＳＧＮは、このインスタンス内で、ＧＧＳＮは「ホーム」ＧＧＳＮではなく、代わりに動的に選択したＧＧＳＮである場合を除いて、上記のように選択したＧＧＳＮとＧＴＰトンネルを確立する。次に、選択したＧＧＳＮは、ＧＧＳＮを経由した、ユーザ由来の、又はユーザ向けのＩＰパケットを統合し得る。
【００２７】
上記の条件により、ＧＧＳＮを選択する規定のアルゴリズムは、多くの形態があり得る。ある実施形態は、ＭＳ及びＳＳＧＮに地域的に最も近いＧＧＳＮを選択する。この場合、ＧＧＳＮを判定する３２５の一部として、ＨＬＲプロキシ２０５は、ネットワークトポロジーデータベース（図示せず）を参考にし、データベースを照会することにより、要求を生じたＧＧＳＮに最も近いＧＧＳＮを検索する。例えば、最も近いとは、ＳＳＧＮ及びＧＧＳＮ間のネットワークホップが最小数であると推論され得る。
【００２８】
他方法のアルゴリズムの下では、性能の基準、及び／又は条件が分析されることによりＧＧＳＮを選択する。例えば、ＧＧＳＮ選択ロジックは、管理データベース、又は搭載量以下のＩＰネットワークセグメントを識別するユーティリティを照会し、次に、そのようなセグメントからＧＧＳＮを選択し得る。この手法は、上記の手法と連合し、又は代替として使用され得る。
【００２９】
他の方法では、大量の障害状態を経験したＧＧＳＮを避け、代わりに「バック−アップ」ＧＧＳＮを選択する等、信頼性情報により、ＧＧＳＮを選択し得る。
実際のアルゴリズムは、管理者によりこのようなアルゴリズムの集合から選択され得る。この例では、ＨＬＲプロキシ２０５は、ユーザによりアルゴリズムの選択を可能にし、ユーザが非常に要求される時間のアルゴリズムを選択し、別の時間には別のアルゴリズムを選択する等、選択ルールを特定することを可能にする管理者インターフェース（図示せず）を含み得る。
【００３０】
上記の説明はＨＬＲプロキシ２０５に関連していたが、本発明の別の実施形態はネットワークの他の場所にＧＧＳＮ選択ロジックを設け得る。例えば、図４は、（本開示で記載された等の）ＧＧＳＮ選択ロジック４０５がＨＬＲ１１７内に含まれる実施形態を示す。図５は、ＨＬＲ１１７と協働する付属物５１０上に実行される実施形態を示す。図６は、ＧＧＳＮ選択ロジック６０５が、ネットワーク管理ユーティリティの一部としてバッチジョブ等のように周期的に実行される他の実施形態を示す。ＧＧＳＮは、ネットワークの性能及び信頼情報に基づいて、ＭＳとの関連において選択される。次に、ロジック６０５は、データインターフェース６１０経由でＨＬＲに接続し、それに従ってＧＧＳＮを特定する。この接続及び更新は、同じように、ＨＬＲ内のホームＧＧＳＮをプログラムするよう作動し得、しかしこのインスタンス内では、ＧＧＳＮは他の基準に基づき得る。
【００３１】
別例
現在、ＨＳＳ−ホーム加入者サーバを提供するための幾つかの提案がある。ＨＳＳは、ＰＳＴＮ及びＩＰエンティティのどちらにも、加入者プロファイル及び必要なデータを提供する。ＨＳＳは、支払いがＨＳＳに連動し得る場合に、加入者が商品を購入できる移動取引サーバ（ｍｏｂｉｌｅ ｔｒａｎｓａｃｔｉｏｎ ｓｅｒｖｅｒ）として使用され得る。
【００３２】
この場合、ＧＧＳＮの選択は、加入者が商品を購買する場合に、ネットワークが別のＧＧＳＮによるより安全なＩＰセッションに加入者を切り替える等、移動商取引に関連させ得る。
【００３３】
例示的な実施形態を記載してきた、当業者は、本発明の精神と範囲から離れることなく記載した実施形態を変更し得ることが理解される。
【図面の簡単な説明】
【００３４】
【図１】３Ｇ移動ネットワークを例示するシステムダイアグラム。
【図２】本発明の一実施形態による、３Ｇ移動ネットワークを例示するシステムダイアグラム。
【図３】本発明の一実施形態によるＧＧＳＮ選択ロジックを示すフロー図。
【図４】本発明の別実施形態を示すアーキテクチャダイアグラム。
【図５】本発明の別実施形態を示すアーキテクチャダイアグラム。
【図６】本発明の別実施形態を示すアーキテクチャダイアグラム。

Claims (9)

1. 少なくとも２つのＧＧＳＮネットワークとＳＧＳＮネットワークとを有する移動通信網内において、データ呼を提供するＧＧＳＮを判定する方法であって、
   ＳＧＳＮよりメッセージを受信する工程と、
   受信したメッセージを分析することによって、メッセージがＧＧＳＮの識別を要求するか否かを判定する工程と、
   受信メッセージがＧＧＳＮの識別を要求する場合に、ＧＧＳＮを識別するＧＧＳＮ選択アルゴリズムを実行することにより、特定のＭＳによるデータ呼を提供する工程と、
   選択ＧＧＳＮを識別するＳＧＳＮへの応答を構成し、及び送信する工程とを備える方法。
2. 前記ＧＧＳＮ選択アルゴリズムを実行する工程は、ＳＧＳＮに最も近いＧＧＳＮを判定する工程を備える請求項１に記載の方法。
3. 前記ＧＧＳＮ選択アルゴリズムを実行する工程は、特定のＭＳからのデータ呼を提供する能力を有するＧＧＳＮを判定する工程を備える請求項１に記載の方法。
4. 前記ＧＧＳＮ選択アルゴリズムを実行する工程は、ＧＧＳＮをネットワークに接続するネットワークセグメントの作動状況を考慮する工程を備える請求項１に記載の方法。
5. 少なくとも２つのＧＧＳＮネットワークとＳＧＳＮネットワークとを有する移動通信網内において、データ呼を提供するＧＧＳＮを判定するシステムであって、
   ＳＧＳＮよりメッセージを受信するＩＰパケット受信ロジックと、
   受信メッセージがＧＧＳＮの識別を要求するか否かを判定するＩＰパケット分析ロジックと、
   ＩＰパケット分析ロジックに応答し、特定ＭＳからのデータ呼を提供するＧＧＳＮを識別するＧＧＳＮ選択ロジックと、
   選択ＧＧＳＮを識別するＳＧＳＮへの応答パケットを構成し、及び送信するＩＰパケット応答ロジックとを備えるシステム。
6. 前記ネットワークがＨＲＬを備え、及び前記ＩＰパケット受信ロジック、前記ＩＰパケット分析ロジック、前記ＧＧＳＮ選択ロジック、及び前記ＩＰパケット応答ロジックは、前記ＨＬＲ及びＩＰネットワーク通信のスイッチプラットフォーム上で実行するソフトウェアロジックである請求項５に記載のシステム。
7. 前記ネットワークがＨＲＬを備え、及び前記ＩＰパケット受信ロジック、前記ＩＰパケット分析ロジック、前記ＧＧＳＮ選択ロジック、及び前記ＩＰパケット応答ロジックは、前記ＨＬＲで実行するソフトウェアロジックである請求項５に記載のシステム。
8. 前記ネットワークがＨＲＬを備え、及び前記ＩＰパケット受信ロジック、前記ＩＰパケット分析ロジック、前記ＧＧＳＮ選択ロジック、及び前記ＩＰパケット応答ロジックは、前記ＨＬＲと協働する付属品で実行するソフトウェアロジックである請求項５に記載のシステム。
9. 少なくとも２つのＧＧＳＮネットワークとＳＧＳＮネットワークとを有する移動通信網内において、データ呼を提供するＧＧＳＮを判定する方法であって、
   ＧＧＳＮ選択アルゴリズムを実行することにより、ＳＧＳＮからのデータ呼を提供するＧＧＳＮを識別する工程と、
   ＨＬＲに対して識別したＧＧＳＮを提供することにより、識別したＧＧＳＮとＳＧＳＮを関連させる工程とを備える方法。

Images