JP5031224B2 - 無線ネットワーク中において管理されたローミング・サービスを提供するための方法および装置 - Google Patents

Description

本発明は、無線ネットワーク中において管理されたローミング・サービスを提供するための方法および装置に関する。より詳細には、本発明は、無線ネットワーク内で実装して、ローミング登録要求またはロケーション・アップデート（位置更新、location update）要求を阻止することができる管理されたローミング・アプリケーションに関する。次いでこの管理されたローミング・アプリケーションは、これらの要求について様々なコール・ロジック（ｃａｌｌ ｌｏｇｉｃ）・ルーチンのうちの少なくとも１つを実施する。コール・ロジック・ルーチンの実装形態は、このサービス・プロバイダにとってのローミング・サービスの改善された管理を実行する。

本発明は、詳細には管理されたローミング・サービスの技術を対象としており、したがって特にこの技術に関して説明することになるが、本発明は、他の分野およびアプリケーションにおいても有用性を有することが理解されよう。

背景として、マーケット分析によれば、国際的ローミング・マーケットが将来数年にわたってその全世界収入を増大させるものと期待されることが示されている。西ヨーロッパのみにおける高マージンの国際的ローミング・サービスは、総計無線サービス収入の７％であると推定されるが、これは、その全体的なネットワーク・トラフィックの見積もりの１．５％を占めるにすぎない。これにより、国際的ローミング・サービスはすべてのオペレータにとって非常に魅力的な収入源になっている。

ビジネスのグローバル化が進むにつれて、増大するモバイル・エンド・ユーザ社会は、そのすべての無線通信ニーズについてのユビキタス・アクセスを要求している。実際に、カーナーズ・インスタット（Cahners In-Stat）社が行った調査では、国際旅行が１５年より短い間にほぼ倍増していることが示されている。アメリカ合衆国だけで、大体６億６千４百万人の到着があり、ヨーロッパにおいては、ほぼ４億人の国際的な到着があった。アジア太平洋地域は、１億１千５百万人を超える国際的な到着を経験しており、アジアは、最高の成長率を有している。この同じ調査により、５０年前には５カ国だけで全到着数の７１％を占めていたが、西暦２０００年には、２０カ国が全到着数の７０％を占め、国際旅行における多様性が増大している（より多くの人々がより多くの国々へ旅行している）ことを示していることも見出されている。この傾向は続き、次の２０年の間に国際旅行は、ほぼ３倍に増大することが予想される。カーナーズ・インスタット社はまた、４人の旅行者のうちの大体１人は、彼らの旅行の主目的としてビジネスのために旅行していることも予測している。

この調査によれば、推定９千１百万人の加入者が２００５年までにローミング収入のうちのほぼ２９０億ドルを生み出すことになる。一部の地域では２００６年までに無線浸透率が大体８８％に達し、オペレータは成長のための新しい収入源を探しており、ローミングは非常に魅力的な収入源である。

国際的ローミングのマーケットの可能性にもかかわらず、世界中のサービス・プロバイダは、非管理ローミングのために収入を失ってきていることが見出されている。非管理ローミングは、なかでもとりわけ、好ましくないネットワーク中におけるローミング、および他のネットワークに比べて加入者サービス機能が少ないネットワーク中におけるローミングしか可能にできないことを含んでいる。これは、加入者が入ってローミングする多数の国に運用会社を有するグローバル・サービス・プロバイダにとってはより大きな問題にさえなる。エンド・ユーザのための管理されたローミング・サービスの導入は、かなりの競争上の優位性、ならびにグローバル無線オペレータにとっての収益の高いビジネスとなる可能性がある。

今日では、どのサービス・プロバイダの無線ネットワークにおいても、管理されたローミングをサポートする解決方法は展開されていない。現在では、無線ネットワークにおける管理されたローミング・サービスをサポートするために使用可能な規格は存在していない。

ここで図１を参照すると、現行の技術を示す実施例の無線ネットワークが示されている。ネットワーク１０は、ホーム・ネットワークまたは親ネットワーク１２や、ローミング・ネットワークまたは外国ネットワーク１４など複数の他のネットワークを含んでいる。ネットワーク１２は、モバイル・ステーション（移動局）またはモバイル・デバイス３０のホーム・ネットワークと考えられるネットワークであり、ネットワーク１４は、ホーム・ネットワーク１２に対して別の国または地理的地域に配置されたネットワークとすることができる。ネットワーク１０内に他のネットワーク、サブネットワーク、およびネットワーク・エレメントを組み込むことができることが理解されよう。

しかし、図に示すようにネットワーク１２は、信号ゲートウェイ１６およびＨＬＲ（home location registerホーム・ロケーション・レジスタ）１１８を含んでいる。他のネットワーク・エレメントをネットワーク１２内に含めることもできるが、説明を簡単にするために図に示されたエレメントしか含めていない。ネットワーク１４には、ネットワークＡ、ネットワークＢ、ネットワークＣ、およびネットワークＤを含めていくつかのネットワークが含まれている。図に示すように、（そのホーム・ネットワークがネットワーク１２である）モバイル・デバイス３０は、ネットワーク１４のネットワークＡ内をローミングしている。この場合、モバイル・ステーション３０は、ネットワークＡ上で登録しようと試み、したがって信号ゲートウェイ１６に対して登録要求またはロケーション・アップデート（位置更新）要求を送信する。信号ゲートウェイ１６は、ホーム・ロケーション・レジスタ（ＨＬＲ）１１８へとこの要求を渡す。このシナリオにおいては、信号ゲートウェイ１６およびホーム・ロケーション・レジスタ（ＨＬＲ）１１８により、モバイル・ステーション３０は、インテリジェントな判断をどのコンポーネントによって行うこともなしに、ネットワークＡ上に登録することができるようになるはずである。したがって、たとえ不可能ではないとしても、サービス・プロバイダが、彼らの加入者のためのローミングを効率よく管理することは難しい。

本発明は、以上で言及した困難および他の困難を解決する新しい改善されたシステムを企図している。
無線ネットワークにおける管理されたローミング・サービスを提供するための方法および装置が提供される。もちろん、この技法は、加入者が、ホーム・ネットワークを有しているが、第２のネットワーク中をローミングしている状況において特に有用である。

本発明の一態様においては、本方法は、この加入者のホーム・ネットワークの信号ゲートウェイにおいて第２のネットワークからのメッセージを受信する工程と、管理されたローミング・アプリケーションに対してこのメッセージを送信する工程と、このメッセージがロケーション・アップデート（位置更新）要求であるかどうかを判定する工程と、ロケーション・アップデート要求ではないメッセージの処理についてこのメッセージをホーム・ロケーション・レジスタに送信する工程と、この要求がロケーション・アップデート要求である場合にこの管理されたローミング・アプリケーションにより、このメッセージ上のコール・ロジック（ｃａｌｌ ｌｏｇｉｃ）・ルーチンを実施する工程を含んでいる。

本発明の他の態様において、このコール・ロジック・ルーチンは、この第２のネットワークについての所定のしきい値パーセンテージに基づいて、このロケーション・アップデート要求を許可すべきかどうかを判定する工程を含んでいる。

本発明の他の態様において、このコール・ロジック・ルーチンは、この第２のネットワークが好ましいネットワークであるかどうかに基づいて、このロケーション・アップデート要求を許可すべきかどうかを判定する工程を含んでいる。

本発明の他の態様において、このコール・ロジック・ルーチンは、このロケーション・アップデート要求がＧＰＲＳ加入者を起源としているかどうかを判定する工程を含んでいる。

本発明の他の態様において、このコール・ロジック・ルーチンは、このホーム・ネットワークおよびこの第２のネットワークが共通のサービス・プロバイダに属するかどうかに基づいて、このロケーション・アップデート要求を許可すべきかどうかを判定する工程を含んでいる。

本発明の他の態様においては、本発明による方法を達成するための手段が提供される。
本発明の他の態様においては、本システムは、その中に加入者データおよびネットワーク・プロファイル・データを記憶しているデータベースと、メッセージを受信し、このメッセージがロケーション・アップデート要求であるかどうかを判定し、このメッセージがロケーション・アップデート要求ではない場合、処理するためにホーム・ロケーション・レジスタにこのメッセージを送信し、この要求がロケーション・アップデート要求である場合には、このメッセージについてコール・ロジック・ルーチンを実施するように動作する少なくとも１つのフロント・エンド・エレメントを備えている。

本発明の他の態様において、この少なくとも１つのフロント・エンド・エレメントは、信号ゲートウェイからこのメッセージを受信するように動作する。
本発明の他の態様において、このコール・ロジック・ルーチンは、第２のネットワークについての所定のしきい値パーセンテージに基づいて、このロケーション・アップデート要求を許可すべきかどうかを判定する工程を含んでいる。

本発明の他の態様において、このコール・ロジック・ルーチンは、第２のネットワークが好ましいネットワークであるかどうかに基づいて、このロケーション・アップデート要求を許可すべきかどうかを判定する工程を含んでいる。

本発明の他の態様において、このコール・ロジック・ルーチンは、このロケーション・アップデート要求がＧＰＲＳ加入者を起源としているかどうかを判定する工程を含んでいる。

本発明の他の態様において、このコール・ロジック・ルーチンは、ホーム・ネットワークおよび第２のネットワークが共通のサービス・プロバイダに属するかどうかに基づいて、このロケーション・アップデート要求を許可すべきかどうかを判定する工程を含んでいる。

本発明の他の態様において、このコール・ロジック・ルーチンは、このデータベースに記憶されるこの加入者データおよびネットワーク・プロファイル・データに基づいて実施される。
本発明の他の態様において、このデータベースは、中央集中化されたデータベースである。

本発明の他の態様において、この少なくとも１つのフロント・エンド・エレメントは、この無線ネットワーク全体を通して分散された複数のフロント・エンド・エレメントである。
本発明の他の態様において、このコール・ロジック・ルーチンは、加入者のＰＬＭＮ（public land mobile network公衆地上モバイル・ネットワーク）リストをアップデートする工程を含んでいる。

本発明のさらなる適用範囲については、以下で行う詳細な説明から明らかになろう。しかし、本発明の趣旨および範囲内における様々な変更および修正が当業者には明らかなはずであるので、本発明の好ましい実施形態を示しながら、詳細な説明および特定の実施例を例証としてしか示していないことを理解されたい。

本発明は、このデバイスの様々な部分の構造、構成、および組合せ中、ならびにこの方法の工程中に存在し、それによってこれらの企図された目的は、以下でより十分に記述し、特許請求の範囲中に詳細に指摘し、添付図面に示すように達成される。

展開された無線ネットワークの数の増加と共に、サービス・プロバイダには、かかる方法で無線加入者のローミング要求を管理して、その生産性およびそのリソースの効率的な利用を増大させる誘因が存在する。エンド・ユーザにローミング・サービスをスムーズに導入するには、このネットワークからの準備する際における顧客セルフケア・サポートおよび最大の支援が必要になる。初期インストレーションの後に、ローミング・サービスは、連続的自動終了適応（continuous automatic termination adaptation）を必要とする。

この現在説明している実施形態では、ローミング・データの準備およびこのモバイル端末の動的設定が実証される。少なくとも１つの形態においては、現在説明している実施形態は、設定やネットワーク選択などの手動タスクについての必要性をなくすることにより、（ＧＳＭ、ＧＰＲＳ、またはＵＭＴＳなど）異なるオペレータ・ネットワークにまたがるシームレスなローミングを実行する。現在説明している実施形態の追加の利点は、ビジネス・ユーザおよび消費者が、どこでも、いつでも、任意のデバイスを介して、ネットワーク技術に関係なく、所与のオペレータのサービスに対してアクセスすることができることである。制御の量はカスタマイズすることができ、一般的にオペレータ要件に基づいている。管理されたローミング・サービス（Managed Roaming Service）の発展経路は、このＷｉＦｉサービスを伴う３Ｇ相互作用の包含をもたらすことができ、ここでこのＶＰＮ接続セットアップおよびＷｉＦｉネットワーク認証パラメータは、この準備データからモバイル端末によってセキュリティ上安全に検索する必要がある。

このサービス・プロバイダは、プレミアム加入者を他のカテゴリの加入者から区別し、異なるタイプのネットワーク使用可能性に基づいて異なるタイプの加入者に課金することによって追加の収入を生み出すことができる。この管理されたローミング・アプリケーションは、彼らのローミング提携先のネットワークに対してではなく、彼らのネットワークに対して彼らの面白いモバイル・トラフィック上での制御をこのサービス・プロバイダに提供するので、このサービス・プロバイダは、彼らのネットワークの効率的な利用による、より大きな収入を得る。さらに、この現在説明している実施形態のサービスなど、管理されたローミング・サービスは、サービス・プロバイダがこのローミング提携先とより良好な取引を交渉する助けになり、それによってこれらの加入者のローミング・コストを低下させる。

次に図面を参照しているが、これらの図面は、本発明の好ましい実施形態を例証する目的にすぎず、本発明を限定する目的はない。図２は、本発明による全体的に好ましいシステムの図を示している。この図に示すように、この現在説明している実施形態を実装することができるネットワーク１００がブロック形式で示されている。このネットワーク１００は、信号ゲートウェイ１１４、ＯＴＡＦ（over the-air function空中ファンクション）モジュール１１６、およびホーム・ロケーション・レジスタ（ＨＬＲ）１１８を有するホーム・ネットワーク、または親ネットワーク１１２を含んでいる。またネットワーク１００内には、（１２２における）ネットワークＡ、（１２４における）ネットワークＢ、（１２６における）ネットワークＣ、（１２８における）ネットワークＤなど、他のネットワークまたはサブネットワークをその中に含む別のネットワーク１２０も示されている。特に、ネットワーク１００は、管理されたローミング・アプリケーション・モジュール１３０も含んでいる。

ネットワーク１００は、説明を簡単にするために図に示されていない様々な他のネットワーク、サブネットワーク、およびネットワーク・エレメントを含むこともできることを理解されたい。ネットワーク１００およびそのエレメントは、実装される無線技術の世代に応じて変化することができる。示された、知られているネットワークおよびネットワーク・エレメントはまた、当業者なら理解するように様々な形態を取ることもできる。

注目すべきことに、管理されたローミング・アプリケーション・モジュール１３０も、同様に様々な形態を取ることができる。例えば、管理されたローミング・アプリケーション・モジュール１３０は、信号ゲートウェイ１１４と同じネットワーク・エレメント上に存在する１つ（または複数）のソフトウェア・ルーチンの形態を取ることもでき、あるいは管理されたローミング・アプリケーション・モジュール１３０は、このネットワーク１１２内の様々な適切なロケーションに分散することもできる。例えば、このネットワーク全体を通して分散される（以下で説明する）この管理されたローミング・アプリケーションの複数のフロント・エンド・エレメントが存在することができるが、一方で（以下で説明する）中央データベースを１つの便利なロケーションに配置することもできる。どの構成においても、もちろんＭＲＡ（managed roaming application管理されたローミング・アプリケーション）モジュール１３０（例えば、このフロント・エンド・エレメント）は、メッセージまたは信号ゲートウェイからの信号がホーム・ロケーション・レジスタなどに転送される以前に、これらのメッセージおよび信号を阻止するように動作することが好ましい。管理されたローミング・アプリケーション・モジュール１３０の実装形態は、様々なソフトウェア技法およびハードウェア構成の実装形態を含むことができることについても理解されたい。これらの技法および構成は、現在説明している実施形態を理解すれば明らかなはずである。

図２を再び参照すると、訪問ネットワーク（または外国ネットワーク）１２０中をローミングしている、モバイル・ステーション３０をもつ加入者が登録しようと試みるときに、モバイル・ステーション３０は、訪問ネットワーク１２０からそれ自体のホーム・ロケーション・レジスタ（ＨＬＲ）１１８へとＬＵ（location updateロケーション・アップデート）オペレーションを送信しようと試みる。しかし、１つ（または複数）の管理されたローミング・アプリケーション（ＭＲＡ）モジュール１３０は、ＧＳＭケース、ＧＰＲＳケース、およびＵＭＴＳケースについてのロケーション・アップデート（ＬＵ）オペレーション要求を阻止し、この加入者がこの外国ネットワーク１２０に登録する許可が得られることになるかどうかを制御する。図に示すように、モバイル・デバイス３０は、（破線１によって示されるように）信号ゲートウェイ１１４に対してメッセージを信号で伝え、または送信する。このメッセージは、（破線２によって示されるように）管理されたローミング・アプリケーション（ＭＲＡ）モジュール１３０へと送信される。次いで、アプリケーション１３０は、（以下に示す）いくつかのコール・ロジック・ルーチンのうちのどれかを適用して、メッセージまたは要求のタイプ、ネットワーク・タイプ、この加入者についての試みの回数、または他のサービス・ロジックなどに応じて、この登録する試みを受け入れ、または拒否することになる。一部のケースでは、管理されたローミング・アプリケーション（ＭＲＡ）モジュール１３０は、（破線３および４によって示されるように）適用されるそのコール・ロジック応じて空中ファンクション（ＯＴＡＦ）モジュール１１６および／またはホーム・ロケーション・レジスタ（ＨＬＲ）１１８と情報をやりとりすることになる。もちろん、図に示していないが、信号またはメッセージは、外国ネットワーク１２０に返されて、このコール・ロジックを実行することもできる。

これに関して、次に図３を参照すると、方法２００が示されている。この方法は、一般的に（以下で説明するように、管理されたローミング・フロント・エンド（ＭＲＦＥ）１３２中の）管理されたローミング・アプリケーション（ＭＲＡ）モジュール１３０によって適用されて、このコール・ロジック・ルーチンを実装すべきかどうかが判定される。図に示すように、方法２００は、（２０２における）外国ネットワーク１２０など外側のネットワークからの信号ゲートウェイ１１４によるメッセージの初期受信を含んでいる。このメッセージは、（２０４において）管理されたローミング・アプリケーション（ＭＲＡ）モジュール１３０へと送信され、（２０６において）管理されたローミング・アプリケーション（ＭＲＡ）モジュール１３０は、受信されるこのメッセージが、登録要求またはロケーション・アップデート要求であるかどうかを判定する。そうでない場合には、（２０８において）通常の処理が行われる。これに関しては、このメッセージは、一般的にホーム・ロケーション・レジスタ（ＨＬＲ）１１８へと転送される。

しかし、２０６において、受信されるこのメッセージが登録要求、またはロケーション・アップデート要求であることが判定される場合には、次いで（２１０において）この管理されたローミング・アプリケーション・モジュールは、以下で説明している、いくつかのコール・ロジック・ルーチンのうちのどれかを実施する。管理されたローミング・アプリケーション・モジュール１３０の実装形態は、ネットワーク・サービス・プロバイダにとっての改善されたローミング・サービスの管理を可能にする。

次に図４を参照すると、一形態において、管理されたローミング・アプリケーション（ＭＲＡ）モジュール１３０は、管理されたローミング・フロント・エンド（ＭＲＦＥ）１３２と管理されたローミング・データベース（ＭＲＤＢ）１３４とから構成される。管理されたローミング・フロント・エンド（ＭＲＦＥ）１３２は、この着信ロケーション・アップデート要求に対して以上で指摘したこの管理されたローミング・コール・ロジックまたはコール・ロジック・ルーチンを実施する。このエレメントは、他のネットワークから到来するすべての関連するモバイル・アクセス・プラットフォーム（ＭＡＰ）メッセージを阻止する。管理されたローミング・フロント・エンド（ＭＲＦＥ）モジュール１３２は、（ＳＳ＃７／Ｓｉｇｔｒａｎ信号メッセージなど）任意の信号メッセージを符号化し復号化し、（ＧＳＭ、ＧＰＲＳ、またはＵＭＴＳを使用したこれらのネットワークなど）適切なネットワークとこのサービス・ロジックをインターフェースする責任を有する。管理されたローミング・フロント・エンド・エレメント１３２は、この信号ゲートウェイによって通常達成されることになるように、この非ロケーション・アップデート・メッセージを適切なホーム・ロケーション・レジスタ（ＨＬＲ）１１８へと中継する。しかし、この管理されたローミング・フロント・エンド・エレメントは、管理されたローミング・データベース（ＭＲＤＢ）１３４から適切なデータを抽出して、着信ロケーション・アップデート（ＬＵ）を処理する。一部のケースでは、以下で明らかになるように、空中ファンクション（ＯＴＡＦ）モジュール１１６、無線ネットワーク、およびモバイル・ステーション３０もまた、このコール・ロジックを適用するプロセス中に含めることができる。管理されたローミング・データベース（ＭＲＤＢ）１３４は、ネットワーク情報、加入者情報、およびサービス・ロジック情報に関連したすべての情報についてのリポジトリである。

一般的に、管理されたローミング・データベース（ＭＲＤＢ）１３４は、１３６に示されたようなモジュールを介してアップストリーム・システムによって入力され、準備される。これに関しては、管理されたローミング・アプリケーション（ＭＲＡ）モジュール１３０中の管理されたローミング・データベース（ＭＲＤＢ）１３４により、オペレータは、管理されたローミング・アプリケーション（ＭＲＡ）モジュール１３０についての１つのエントリ・ポイントに準備、運営および管理を提供する標準的な準備メカニズムを介して、設定データと、加入者／訪問ロケーション・レジスタ（ＶＬＲ）ネットワークデータを準備することができるようになる。

この設定データは、管理されたローミング・データベース（ＭＲＤＢ）１３４から管理されたローミング・フロント・エンド（ＭＲＦＥ）１３２へと配信される。以上で指摘したように、この管理されたローミング・フロント・エンド・モジュールは、実際に同じまたは異なる地理的地域に配置された複数のモジュールとして実装することができる。対をなす１対の、管理されたローミング・データベース（ＭＲＤＢ）１３４のノードは、この標準プラットフォーム上でサポートされるデータベース複製機能を使用して同期して保持される。したがって、この対をなす１対のいずれかのノードを使用してデータの共通のビューを取得することができる。

管理されたローミング・データベース（ＭＲＤＢ）１３４は、管理されたローミング・フロント・エンド（ＭＲＦＥ）１３２の設定データおよび規則を複数の管理されたローミング・フロント・エンド（ＭＲＦＥ）１３２に配信する責任を仮定することにより、データについてのインターフェースを集中させるので、このオペレータには、この分散された展開においてノードごとにこれらの設定データおよび規則を別々に準備する必要はない。

管理されたローミング・データベース（ＭＲＤＢ）１３４が保持する一部のテーブルについての例証を以下に示す。管理されたローミング・データベース（ＭＲＤＢ）１３４の構成は、そのアプリケーションに応じて変化し得ることを理解されたい。他のテーブルも含めることができるが、これらの説明は除外することもある。さらに、各テーブルの内容は、そのアプリケーションに応じて変化することもある。例えば、これらのテーブルの内容は、１つ（または複数）のどのコール・ロジック・ルーチンが、特定のアプリケーションに実装されるかに応じて変化することもある。少なくとも１つの形態において、このデータベースは、データの一貫性などの利点を得るために集中される。

ＩＭＳＩ２ＨＬＲ＿Ａｄｄｒｅｓｓテーブルは一般的に、このＩＭＳＩ（international mobile subscriber identity国際的モバイル加入者識別情報）からホーム・ロケーション・レジスタ（ＨＬＲ）１１８への静的変換を実施することにより、ホーム・ロケーション・レジスタ（ＨＬＲ）１１８に向かう経路情報を抽出するために使用される。

Ｔｒａｎｓｌａｔｉｏｎ Ｔｙｐｅ Ａｄｄｒｅｓｓテーブルは、変換タイプ（Translation Type）を使用して経路指定する代替方法を提供することについて使用される。この変換タイプは、このＳＴＰに向けられたメッセージ中で変更することができる。

ＨＬＲ＿Ｌｏｃａｔｉｏｎテーブルは、ホーム・ロケーション・レジスタ（ＨＬＲ）の所在を見出すために使用される。
ＩＭＳＩ＿ｌｉｓｔテーブルは、加入者のローミング・プロファイルについての情報を有する加入者ごとのテーブルである。

ＶＬＲ（訪問ロケーション・レジスタ）／ＳＧＳＮ＿ｌｉｓｔテーブルは、この加入者プロファイルに基づいて異なるネットワーク分類を提供する。例えば、以下で説明するサービス・ルーチンのうちの１つでは、このローミング加入者には、ネットワーク％プロファイルのサービス・ロジックに基づいて異なる処理が提供される。

Ｎｅｔｗｏｒｋ＿テーブルを使用して、ネットワーク中における顧客の登録の試行回数を記憶して、パーセンテージを算出する。
Ｃｏｕｎｔｒｙ＿テーブルを使用して、ある国における顧客の登録の試行回数を記憶して、パーセンテージを算出する。

ＩＭＳＩ＿Ｃａｃｈｅ＿テーブルを使用して、この加入者のロケーション・アップデートの試みを追跡する。これは、アプリケーションが、試みを拒否すべき、または受け入れるべきときを決定する助けになる。

以上で指摘したように、この全体的な管理システムは、様々な異なるタイプのコール・ロジックをロケーション・アップデート（ＬＵ）要求に対して適用することができる。このシステムは、これらのコール・ロジック・ルーチンのうちのすべてまたは複数を実施するように構成することができ、これらのコール・ロジック・ルーチンでは、特定の状況に合うようにするために単にオペレータまたは設計者による選択を必要とするだけとなる。代わりに、所与のネットワークの管理されたローミング・アプリケーション（ＭＲＡ）モジュール１３０は、１つのコール・ロジック・ルーチンしか実施しないように設計することもできる。もちろんこれらの決定は、設計者の自由裁量のうちにあり、本明細書中の本発明の範囲内のいくつかの異なる方法で解決することができる。

ロケーション・アップデート（ＬＵ）要求としてのメッセージを認識するとすぐに、管理されたローミング・アプリケーション（ＭＲＡ）モジュール１３０は、少なくとも４つの異なるタイプのコール・ロジック・ルーチンを実施することができる。第１のコール・ロジック・ルーチンは、ネットワーク上で許可された登録の所定のしきい値パーセンテージに基づいている。この許可された登録のパーセンテージは、ある加入者についてのあるネットワーク上で許可された登録の、他のネットワークに対するパーセンテージに関連づけることができる。第２のコール・ロジック・ルーチンは、この訪問ネットワークが好ましいネットワークであるかどうかに基づいて、このロケーション・アップデート（ＬＵ）要求を許可すべきかどうかを判定する。第３のコール・ロジック・ルーチンは、ロケーション・アップデート（ＬＵ）要求がＧＰＲＳ加入者を起源としているかどうかを判定し、第４のコール・ロジック・ルーチンは、そのホーム・ネットワーク、およびその訪問ネットワークすなわちローミング・ネットワークが、共通のサービス・プロバイダに属するかどうかに基づいて、このロケーション・アップデート（ＬＵ）要求を許可すべきかどうかを判定する。これらの４つの実施例のシナリオについては以下で説明することにする。

次に図５を参照すると、異なるレベルの許可されたローミング・パーセンテージ（例えば、１００％、３０％、６０％、１０％）を有するネットワーク１２２、１２４、１２６、および１２８をその中に含んでいる外国ネットワーク１２０が、所与の加入者のプロファイルについて示されている。この実施例においては、加入者が、ネットワークＡ（１２２）をローミングしているときに、このネットワークＡが１００％の許容しきい値を有する好ましいネットワークであるので、この着信登録は、受け入れられ、加入者のホーム・ロケーション・レジスタ（ＨＬＲ）１１８へと送信される。しかし、この加入者がネットワークＢへとローミングするときには、管理されたローミング・アプリケーション（ＭＲＡ）モジュール１３０は、この管理されたサービスまたはコール・ロジック・ルーチンを適用し、追加された登録がこのプロファイル・パーセンテージ（例えば、３０％）を超過するかどうかを判定する。これは、好ましくないネットワークからの加入者についての最初の着信登録について判定される。以下で明らかになるように、これが最初の試みか否かにより、このアクション・コースが決定されることもある。したがって、管理されたローミング・アプリケーション（ＭＲＡ）モジュール１３０は、この着信登録を妨げ、この加入者の空中ファンクション（ＯＴＡＦ）モジュールに対して空中（ＯＴＡ）メッセージを送信して、この加入者のＳＩＭ（subscriber identity module加入者識別情報モジュール）カードをアップデートすることができる。（本明細書中において、いくつかのコンテキストで説明されているように）モバイル・デバイス３０内のこの加入者識別情報モジュール（ＳＩＭ）カード中の公衆地上モバイル・ネットワーク（ＰＬＭＮ）リストをアップデートすることにより、一般にパフォーマンスが改善され、ローミング・サービスのより効率的な管理が行われることになる。そのようにすることにより、デバイス３０へのデータの配信が可能になり、これにより、このデバイスは将来において好ましいネットワーク上でより簡単に登録することができるようになる。送信される空中（ＯＴＡ）メッセージはまた、それによってモバイル・デバイス３０を登録することができるようにするための、ネットワークの優先順位リストを提供することもできる。より詳細な１組のシナリオが、図６〜１０のコール・フロー図に示されている。

オペレーション中に、管理されたローミング・フロント・エンド（ＭＲＦＥ）１３２は、信号ゲートウェイ１１４からホーム・ロケーション・レジスタ（ＨＬＲ）１１８ベースのメッセージを受信する。管理されたローミング・フロント・エンド（ＭＲＦＥ）１３２は、これらの非ロケーション・アップデート（ＬＵ）メッセージをこの顧客の公衆地上モバイル・ネットワーク（ＰＬＭＮ）リスト中の適切なホーム・ロケーション・レジスタ（ＨＬＲ）１１８に対して中継する。これらのロケーション・アップデート（ＬＵ）メッセージについては、管理されたローミング・フロント・エンド（ＭＲＦＥ）１３２は、管理されたローミング・データベース（ＭＲＤＢ）１３４からこのサービス／加入者に関連したデータを抽出した後にこの基本的なコール・ロジックを評価する。管理されたローミング・フロント・エンド（ＭＲＦＥ）１３２は、以下の主要なファンクションを実施する。

ロケーション・アップデート（ＬＵ）が、（ネットワークＡ（１２２）など）好ましいネットワークから、あるいは例えば「国内ローミング（National Roaming）」として分類されるネットワークから受信される場合、管理されたローミング・アプリケーション（ＭＲＡ）モジュール１３０は、登録を受け入れ、このメッセージを正しいホーム・ロケーション・レジスタ（ＨＬＲ）１１８に中継する。この国際的モバイル加入者識別情報（ＩＭＳＩ）が、Ｃａｃｈｅテーブル中に存在する場合（これは、この加入者についての以前の登録の試みが特定の存続期間中に拒否されたことを意味する）には、次いで空中（ＯＴＡ）メッセージがこの加入者の加入者識別情報モジュール（ＳＩＭ）カードに送信されて、この公衆地上モバイル・ネットワーク（ＰＬＭＮ）リストがアップデートされる。このタイマ値、例えばＥｘｔｅｎｄＥｘｐｉｒａｔｉｏｎＴｉｍｅは、必要に応じてこのエントリのための有効期間が延長されることになるか否かを示している。

このロケーション・アップデート（ＬＵ）が好ましくないネットワークから受信され、このロケーション・アップデートが登録する最初の試みであり、しきい値パーセンテージが、登録する試みによって超過される場合、管理されたローミング・アプリケーション（ＭＲＡ）モジュール１３０は、この登録を妨げ、構成可能な拒否原因（例えば、非応答シナリオなど）と共に拒否メッセージをこの訪問ＭＳＣへと送信する。この時に、キャッシュが、タイマ、例えばＥｘｐｉｒａｔｉｏｎＴｉｍｅＦｉｒｓｔＥｎｔｒｙタイマと共に作成される。

しかし、このロケーション・アップデートが、最初の試みであり、許可されるパーセンテージしきい値がこのネットワーク・プロファイルを超過しない場合には、管理されたローミング・アプリケーション（ＭＲＡ）モジュール１３０は、この登録を受け入れる（このメッセージを正しいホーム・ロケーション・レジスタ（ＨＬＲ）１１８に中継する）。

このロケーション・アップデートが、２番目の試みである場合には、このアプリケーションは、登録を受け入れる（正しいホーム・ロケーション・レジスタ（ＨＬＲ）１１８へと中継する）はずであり、この空中（ＯＴＡ）メッセージを送信する。この空中（ＯＴＡ）メッセージは、この加入者の加入者識別情報モジュール（ＳＩＭ）カードに送信されて、この公衆地上モバイル・ネットワーク（ＰＬＭＮ）リストをアップデートする。このＥｘｔｅｎｄＥｘｐｉｒａｔｉｏｎＴｉｍｅタイマの値は、必要に応じて延長される。

この主要アルゴリズムに基づいて、この妨害プロシージャ（ｂａｒｒｉｎｇ ｐｒｏｃｅｄｕｒｅ）は、この加入者識別情報モジュール（ＳＩＭ）が、この国際的モバイル加入者識別情報（ＩＭＳＩ）リスト中で「適用すべき制限なし」として分類されない場合で、またこの訪問ロケーション・レジスタ（ＶＬＲ）が、「好ましくない」と分類される場合だけに呼び出される。アップデート・プロシージャ、例えばアップデートＧＰＲＳロケーション・プロシージャは、このＧＳＭロケーション・アップデート（ＬＵ）受入／除外プロシージャと同様に実施される。

管理されたローミング・アプリケーション（ＭＲＡ）１３０が、その訪問公衆地上モバイル・ネットワーク（ＶＰＬＭＮ）からこのロケーション・アップデート（ＬＵ）を受信するときに、この管理されたローミング・アプリケーション（ＭＲＡ）は、その訪問ロケーション・レジスタ（ＶＬＲ）アドレス、国際的モバイル加入者識別情報（ＩＭＳＩ）を抽出し、タイムスタンプを算出する。管理されたローミング・アプリケーション（ＭＲＡ）モジュール１３０は、ＩＭＳＩ＿Ｌｉｓｔテーブルを少し読み取って、加入者について適用すべき振舞いを探す。この国際的モバイル加入者識別情報（ＩＭＳＩ）がこのＩＭＳＩ＿Ｌｉｓｔテーブル中に存在しない場合、このアプリケーションは、デフォルトＩＭＳＩサービスの振舞いなどの構成されたオペレーションを適用する（例えば、この国際的モバイル加入者識別情報（ＩＭＳＩ）が、この国際的モバイル加入者識別情報（ＩＭＳＩ）リスト・テーブル中で見出されない場合には、警告イベントおよびログ・イベントが生成される必要がある）。この国際的モバイル加入者識別情報（ＩＭＳＩ）が存在する場合には、国際的モバイル加入者識別情報（ＩＭＳＩ）特性に応じて、訪問ロケーション・レジスタ（ＶＬＲ）アドレス・チェックが存在しても存在しなくてもよい。「チェックなし」の場合には、このアプリケーションは、この国際的モバイル加入者識別情報（ＩＭＳＩ）に向けて算出されたホーム・ロケーション・レジスタ（ＨＬＲ）１１８の経路指定情報を使用して、このロケーション・アップデート（ＬＵ）メッセージを正しいホーム・ロケーション・レジスタ（ＨＬＲ）１１８へと中継する。「チェック適用」の場合には、このアプリケーションは、このＶＬＲ（訪問ロケーション・レジスタ）／ＳＧＳＮ＿ｌｉｓｔテーブル中でこの訪問ロケーション・レジスタ（ＶＬＲ）アドレスを探し、その結果、適用すべき振舞いを決定する。

この訪問ロケーション・レジスタ（ＶＬＲ）アドレスがこのＶＬＲ（訪問ロケーション・レジスタ）／ＳＧＳＮ＿ｌｉｓｔテーブル中に存在しない場合には、このアプリケーションは、デフォルトＶＬＲの振舞いなど構成されたオペレーションを適用し（例えば、この訪問ロケーション・レジスタ（ＶＬＲ）が、このＶＬＲ（訪問ロケーション・レジスタ）／ＳＧＳＮ＿ｌｉｓｔテーブル中で見出されない場合には、警告イベントおよびログ・イベントが生成される必要がある）、あるいはこのアプリケーションは、この訪問ロケーション・レジスタ（ＶＬＲ）アドレス（「好ましい」／「無関係（don't care）」／「好ましくない」）に関連する振舞いを適用する。このパーセンテージ分布ケースについての詳細な好ましい／無関係／好ましくない場合の解決方法については、以下のコール・ロウ（call-low）セクションの下で説明している。

管理されたローミング・フロント・エンド（ＭＲＦＥ）１３２は、許可されたネットワーク・パーセンテージを算出する。それを行うために、管理されたローミング・フロント・エンド（ＭＲＦＥ）１３２は、このロケーション・アップデートが起源としているネットワークを識別する。管理されたローミング・フロント・エンド（ＭＲＦＥ）１３２は、このＮｅｔｗｏｒｋテーブルからこのネットワーク中のローミング・サービス利用者（roamer）数を算出する。管理されたローミング・フロント・エンド（ＭＲＦＥ）１３２は、このＣｏｕｎｔｒｙテーブルからその国にいるローミング・サービス利用者数を算出する。

次いで管理されたローミング・フロント・エンド（ＭＲＦＥ）１３２は、この選択されたネットワーク中のローミング・サービス利用者のパーセンテージを算出する。このパーセンテージがこのネットワーク・プロファイルに関連する値よりも少ない場合には、この登録は受け入れられることになる。そうでない場合には、この登録は拒否される。

Ｐａｒａｍｅｔｅｒテーブル中のＰｅｒｃｅｎｔＬｏｃａｔｉｏｎＡｌｌｏｗｅｄパラメータなどのパラメータは、訪問公衆地上モバイル・ネットワーク（ＶＰＬＭＮ）からのロケーション・アップデート（ＬＵ）受入れのパーセンテージを指定する。このＰｅｒｃｅｎｔＬｏｃａｔｉｏｎＡｌｌｏｗｅｄ＝０の場合、「好ましくない公衆地上モバイル・ネットワーク（ＰＬＭＮ）リスト」から受信されるすべての最初のロケーション・アップデートは、拒否されることになる。このＰｅｒｃｅｎｔＬｏｃａｔｉｏｎＡｌｌｏｗｅｄ＝１００の場合には、「好ましくない公衆地上モバイル・ネットワーク（ＰＬＭＮ）リスト」から受信されるすべての最初のロケーション・アップデートは、許可されることになる。

アプリケーション・タイマが較正される。加入者のロケーション・アップデート（ＬＵ）が拒否される場合、次いでその国際的モバイル加入者識別情報（ＩＭＳＩ）は、このキャッシュに記憶される。この基礎となるロジックは、常に２番目のロケーション・アップデート（ＬＵ）を許可することになる。このＥｘｔｅｎｄＥｘｐｉｒａｔｉｏｎＴｉｍｅフラグが真に設定される場合、これは、キャッシュ中にすでに存在しているこのエントリの有効期間を修正する（延長または短縮する）ことができることを意味する。このＥｘｔｅｎｄＥｘｐｉｒａｔｉｏｎＴｉｍｅが延長される場合、次いでこのロケーション・アップデート（ＬＵ）の拒否率は低下させられ、この好ましいローミングはあまり有効ではなくなる。このＥｘｔｅｎｄＥｘｐｉｒａｔｉｏｎＴｉｍｅが短縮される場合には、次いでこのロケーション・アップデート（ＬＵ）の拒否率は増大させられ、この好ましいローミングは、より有効になる。

この有効期間を修正することができる場合には、このアプリケーションは、このタイマを現在の時刻＋ＥｘｐｉｒａｔｉｏｎＴｉｍｅＥｎｔｒｙＦｏｕｎｄに設定するはずである（通常、このタイマは、ＥｘｐｉｒａｔｉｎＴｉｍｅＦｉｒｓｔＥｎｔｒｙよりも小さくなる）。このＥｘｐｉｒａｔｉｏｎＴｉｍｅＥｎｔｒｙＦｏｕｎｄの目的は、このエントリの除去を延期して、このアプリケーション・バージョン・フォールバック・プロシージャの処理を可能にすることである。

図６を参照すると、コール・フロー６００は、ロケーション・アップデート（ＬＵ）要求以外のすべてのホーム・ロケーション・レジスタ（ＨＬＲ）／認証センタ（ＡＵＣ）に関連したＧＳＭ／ＧＰＲＳ／ＵＭＴＳメッセージが、管理されたローミング・アプリケーション（ＭＲＡ）モジュール１３０によって阻止され、他のどのようなコール・ロジックも適用せずにホーム・ロケーション・レジスタ（ＨＬＲ）１１８に直接に中継されることになることを示している。図に示すように、（６０２において）信号ゲートウェイ１１４は、受信し、次いで（６０４において）外国ネットワークから到来するこれらのホーム・ロケーション・レジスタＨＬＲ／ＡＵＣメッセージを管理されたローミング・アプリケーション（ＭＲＡ）モジュール１３０へと転送する。次に（６０６において）管理されたローミング・アプリケーション（ＭＲＡ）モジュール１３０は、ホーム・ロケーション・レジスタ（ＨＬＲ）１１８のロケーション・テーブル、ＴＴ Ａｄｄｒｅｓｓテーブルなどから経路指定情報を抽出した後に、ホーム・ロケーション・レジスタ（ＨＬＲ）１１８へとそれを中継する。次いで（６０８、６１０において）肯定応答（Acknowledgement）が、信号ゲートウェイ１１４を介してこの外国ネットワークに戻される。

図７を参照すると、コール・フロー７００は、（７０２、７０４において）加入者が好ましい外国ネットワーク中で登録し、ロケーション・アップデート（ＬＵ）要求が行われる場合に、またこのＣａｃｈｅテーブル中に国際的モバイル加入者識別情報（ＩＭＳＩ）エントリが見出されない（すなわち、この登録があらかじめ設定された存続期間内で以前に拒否されなかった）場合には、次いでこのロケーション・アップデート（ＬＵ）要求は、管理されたローミング・アプリケーション（ＭＲＡ）モジュール１３０によって受け入れられることを示している。次いで（７０６において）このロケーション・アップデート（ＬＵ）要求は、適切なホーム・ロケーション・レジスタ（ＨＬＲ）１１８へと転送される。次いで（７０８において）ホーム・ロケーション・レジスタ（ＨＬＲ）１１８は、このＬＵ＿Ａｃｋをこの信号ゲートウェイへと直接に送信し、（７１０において）この信号ゲートウェイは、この肯定応答をこの外国ネットワークへと送信する。

図８を参照すると、コール・フロー８００において、加入者は、「好ましい」ネットワーク中（または「好ましくない」ネットワーク中）で登録しようと試み、またこの加入者は、拒否されており、この国際的モバイル加入者識別情報（ＩＭＳＩ）テーブル中に存在している。このシナリオにおいては、この加入者の登録が以前に拒否された場合、（８０２、８０４において）この加入者の２番目の好ましくない登録は受け入れられ、（８０６において）このロケーション・アップデート（ＬＵ）は、ホーム・ロケーション・レジスタ（ＨＬＲ）１１８へと転送される。この加入者がこの「好ましい」ネットワーク中で登録される場合には、（８０２，８０４において）この加入者の登録は受け入れられ、（８０６において）ホーム・ロケーション・レジスタ（ＨＬＲ）１１８へと転送される。また空中（ＯＴＡ）メッセージが、（８１２において）空中（ＯＴＡ）サーバへと送信されて、この「好ましい」公衆地上モバイル・ネットワーク（ＰＬＭＮ）リストをこの加入者のＳＩＭカードへとダウンロードして、（８１４、８１６において）この「好ましい」ネットワーク中への加入者の登録が制御される。

図９を参照すると、コール・フロー９００は、（９０２、９０４において）加入者が好ましくないネットワークへの登録を試み、このＣａｃｈｅテーブル中へのこの加入者についての国際的モバイル加入者識別情報（ＩＭＳＩ）エントリが存在しない（すなわち、この好ましくない登録は、あらかじめ設定された存続期間内における最初の登録である）場合のシナリオを実例によって示している。管理されたローミング・アプリケーション（ＭＲＡ）モジュール１３０は、この「ネットワーク・テーブル」および「国テーブル」からのデータを抽出し、この選択されたネットワーク中へのローミング・サービス利用者のパーセンテージを算出する。この算出されたパーセンテージが「ネットワーク・プロファイル・パーセンテージ」よりも小さい場合には、（９０６において）このロケーション・アップデート（ＬＵ）は、この準備されたしきい値内にあると考えられ、受け入れられ、適切なホーム・ロケーション・レジスタ（ＨＬＲ）１１８へと転送される。次いで（９０８、９１０において）肯定応答が、この外国ネットワークへと逆に転送される。

図１０を参照すると、コール・フロー１０００は、この選択されたネットワークにおけるローミング・サービス利用者の算出されたパーセンテージが、この「ネットワーク・プロファイル・パーセンテージ」を超過するときに、最初の好ましくない登録がどのようにして拒否されるかを示している。（１００２、１００４において）このキャッシュ・テーブル中への国際的モバイル加入者識別情報（ＩＭＳＩ）エントリを有さない好ましくないネットワークからのロケーション・アップデートを入手した後に、管理されたローミング・アプリケーション（ＭＲＡ）モジュール１３０は、この選択されたネットワーク中のローミング・サービス利用者のパーセンテージが、この準備されたしきい値を超過していると判定する。したがって、管理されたローミング・アプリケーション（ＭＲＡ）モジュール１３０は、このロケーション・アップデート（ＬＵ）メッセージを妨げ、このキャッシュ・テーブルにこの情報を記憶し、有効期間＝ＥｘｐｉｒａｔｉｏｎＴｉｍｅＦｉｒｓｔＥｎｔｒｙを設定する。（１００６において）エラー・メッセージが、このゲートウェイに返信される。

第２のタイプのコール・ロジックは、標準的振舞いと呼ぶことにする。図５〜１０に関連して説明しているこれらの実施形態とは異なり、このコール・ロジックは、パーセンテージしきい値に基づいてはいない。登録に際しての判定は、加入者が好ましいネットワーク中にいるか否かに基づいている。

図１１を参照すると、「標準的振舞い」ロジックにおいて、管理されたローミング・アプリケーション（ＭＲＡ）モジュール１３０の機能は、好ましくないネットワークから到来する最初のロケーション・アップデートを妨げ、このすべての後続のロケーション・アップデート（ＬＵ）をどのような例外もなしに許可する。この「標準的振舞い」は、加入者が、国際的モバイル加入者識別情報（ＩＭＳＩ）テーブル中でその振舞いについてアクティブ化されるときに起動される。第１のケースでは、（１１０２、１１０４において）加入者は、好ましくないネットワークから要求を送信し、（１１０６において）この最初のロケーション・アップデート（ＬＵ）が妨げられる。このケースでは、図１１に示すように、この管理されたローミング・アプリケーション・コール・ロジックは、この国際的モバイル加入者識別情報（ＩＭＳＩ）テーブル中の「標準的振舞い」フラグが「真」とマーク付けされることを決定する。この加入者は、初めてこの好ましくないネットワーク中で登録しようと試み、登録することが妨げられる。

第２のケースでは、（１２０２、１２０４において）加入者は、好ましくないネットワークからロケーション・アップデート（ＬＵ）要求を送信し、（１２０６において）２番目のロケーション・アップデート（ＬＵ）が許可される。このケースでは、図１２のコール・フロー１２００に示すように、管理されたローミング・アプリケーション（ＭＲＡ）１３０のコール・ロジックが、この国際的モバイル加入者識別情報（ＩＭＳＩ）テーブル中の「標準的振舞い」フラグが「真」とマーク付けされることを決定する。管理されたローミング・アプリケーション（ＭＲＡ）モジュール１３０のコール・ロジックは、この加入者の以前の登録を追跡し、この加入者が、第２回目としてこの好ましくないネットワーク中で登録しようと試みており、登録することが許可されることを決定する。（１２０８，１２１０において）肯定応答が送信される。

第３のケースでは、加入者は、この好ましいネットワーク中におり、このロケーション・アップデート（ＬＵ）は、受け入れられる。このケースでは、図１３のコール・フロー１３００に示すように、管理されたローミング・アプリケーション（ＭＲＡ）１３０は、この国際的モバイル加入者識別情報（ＩＭＳＩ）テーブル中の「標準的振舞い」フラグが、「真」とマーク付けされることを決定する。管理されたローミング・アプリケーション（ＭＲＡ）モジュール１３０は、さらに（１３０２、１３０４において）この加入者が、この好ましいネットワーク中で登録しようと試み、（１３０６において）このネットワーク中において登録することが許可されることを決定する。（１３０８、１３１０において）肯定応答が送信される。管理されたローミング・アプリケーション（ＭＲＡ）モジュール１３０は、この加入者の以前の登録を追跡し、その登録が以前に拒否された登録である場合、次いで（１３１２、１３１４、および１３１６において）この管理されたローミング・アプリケーション（ＭＲＡ）モジュールはまた、空中（ＯＴＡ）メッセージを送信して、この加入者のＳＩＭカード中の公衆地上モバイル・ネットワーク（ＰＬＭＮ）リストをクリアする。しかし、この加入者が、この最後の構成可能な期間内にその登録を拒否されていない場合には、この空中（ＯＴＡ）メッセージは、送信されない。

第３のタイプのコール・ロジックを使用して、ユーザが、ＧＰＲＳ（General Packet Radio Services汎用パケット無線システム）ユーザであるかどうかを判定する。それを行うために、管理されたローミング・アプリケーション（ＭＲＡ）モジュール１３０は、以下の２つの異なるアプローチのうちの一方を使用して、この着信ロケーション・アップデート（ＬＵ）が、ＧＳＭ（Global System for Mobile Communication欧州移動電話システム）／ＧＰＲＳ加入者からのものか、あるいは「ＧＰＲＳだけの」加入者からのものかを判定することができる。

一方のアプローチでは、このＧＰＲＳロケーション・アップデートのために、管理されたローミング・アプリケーション（ＭＲＡ）モジュール１３０は、国際的モバイル加入者識別情報（ＩＭＳＩ）リスト・テーブル中に準備して、加入者を「ＧＰＲＳだけの加入者」として識別するために必要な加入者ごとのフラグを使用する。ＧＰＲＳロケーション・アップデートが管理されたローミング・アプリケーション（ＭＲＡ）モジュール１３０によって受信されるときに、この基礎になっている管理されたローミング・アプリケーション（ＭＲＡ）モジュール１３０のロジックは、以下の２つの可能性のある処理のために、この起呼側加入者が「ＧＰＲＳだけの加入者」であるかどうかをチェックすることになる。

１）この「ＧＰＲＳだけの加入者」フィールドがチェックの結果、「ｙ（イエス）」である場合には、これは、この加入者の装置が、このＧＰＲＳ用だけのロケーション・アップデート（ＬＵ）を実施することを意味する。この場合には、任意のＧＳＭ加入者に対する処理と同じ完全なＭＲＳ処理が適用される。
２）この「ＧＰＲＳだけの加入者」フィールドがチェックの結果、「ｎ（ノー）」である場合には、これは、ＧＳＭ用のロケーション・アップデート（ＬＵ）が以前に実施されたときだけに、この加入者用の装置がＧＰＲＳ用のロケーション・アップデート（ＬＵ）を実施することを意味する。この場合には、チェックは実施されず、このＧＰＲＳロケーション・アップデート（ＬＵ）は、対応するホーム・ロケーション・レジスタ（ＨＬＲ）１１８へと転送される。

他方のアプローチでは、管理されたローミング・アプリケーション（ＭＲＡ）モジュール１３０は、この加入者のＧＳＭ登録を追跡する。このスキームにおいては、この管理されたローミング・アプリケーション（ＭＲＡ）モジュールは、各加入者からのＧＳＭ登録にマーク付けし、構成可能な期間にわたってこのレコードをログする。このＧＰＲＳロケーション・アップデート（ＬＵ）が、この構成された期間内にこの加入者について管理されたローミング・アプリケーション（ＭＲＡ）モジュール１３０によって受信される場合には、管理されたローミング・アプリケーション（ＭＲＡ）モジュール１３０が、このＧＳＭロケーション・アップデート（ＬＵ）について以前に実施されているので、管理されたローミング・アプリケーション（ＭＲＡ）モジュール１３０のチェックは実施されない。次いで、このＧＰＲＳロケーション・アップデート（ＬＵ）は、対応するホーム・ロケーション・レジスタ（ＨＬＲ）１１８へと転送される。

管理されたローミング・アプリケーション（ＭＲＡ）モジュール１３０が、ある加入者についてのＧＰＲＳロケーション・アップデート（ＬＵ）を受信し、このＧＳＭ−ＧＰＲＳテーブル中のＧＳＭロケーション・アップデート（ＬＵ）についてのエントリを見出さない場合には、管理されたローミング・アプリケーション（ＭＲＡ）モジュール１３０は、以前にこのＧＳＭ加入者について実施されたモジュールと同じ管理されたローミング・アプリケーション（ＭＲＡ）モジュール１３０をこのＧＰＲＳ加入者について実施する。

どちらのアプローチにおいても、これらのコール・フローは、以下のようになる。第１のケースにおいては、このＧＳＭ登録が実施された後に、加入者についてのＧＰＲＳ登録が試みられる。このケースでは、図１４におけるコール・フロー１４００は、（１４０２、１４０４において）管理されたローミング・アプリケーション（ＭＲＡ）モジュール１３０が、このＩＭＳＩ＿ｌｉｓｔテーブル中で「ＧＰＲＳだけの加入者」フィールドをチェックした結果「ｎ」である加入者からＧＰＲＳロケーション・アップデートを受信しており、またはこのＧＳＭロケーション・アップデート（ＬＵ）が構成可能な期間内で以前に受信されたことを示している。これらのシナリオのどちらも、この加入者用の装置が、ＧＳＭについてのロケーション・アップデート（ＬＵ）が以前に実施された後に、ＧＰＲＳについてのロケーション・アップデート（ＬＵ）を実施していることを意味している。このケースにおいては、管理されたローミング・アプリケーション（ＭＲＡ）モジュール１３０のチェックが、このＧＳＭロケーション・アップデート（ＬＵ）について以前に行われているので、管理されたローミング・アプリケーション（ＭＲＡ）モジュール１３０のチェックは、このＧＰＲＳロケーション・アップデート（ＬＵ）については実施されない。したがって、（１４０６において）このＧＰＲＳロケーション・アップデート（ＬＵ）は、対応するホーム・ロケーション・レジスタ（ＨＬＲ）１１８へと転送され、（１４０８、１４１０において）肯定応答が送信される。

第２のケースにおいては、ＧＰＲＳだけの加入者について最初の好ましくないＧＰＲＳ登録が試みられ、このＧＰＲＳ加入者は、この国際的モバイル加入者識別情報（ＩＭＳＩ）ロスト・テーブル（lost table）への配信を制御するように登録される。このケースでは、図１５のコール・フロー１５００は、（１５０２、１５０４において）管理されたローミング・アプリケーション（ＭＲＡ）モジュール１３０が、このＩＭＳＩ＿ｌｉｓｔテーブル中で「ＧＰＲＳだけの加入者」フィールドをチェックした結果「ｙ」である加入者からＧＰＲＳロケーション・アップデートを受信しており、またはこのＧＳＭロケーション・アップデート（ＬＵ）が構成可能な期間内で以前に受信されていないことを示している。どちらのシナリオも、この加入者用の装置が、ＧＰＲＳだけについてのロケーション・アップデート（ＬＵ）を送信すること、またＧＳＭロケーション・アップデート（ＬＵ）が以前に送信されなかったことを意味している。（１５０６において）エラー・メッセージが返される。

このコール・フローは、この選択されたネットワーク中のローミング・サービス利用者の算出されたパーセンテージが「ネットワーク・プロファイル・パーセンテージ」を超過するときに、どのようにして最初の好ましくないＧＰＲＳ登録が拒否されるかを示している。このキャッシュ・テーブル中への国際的モバイル加入者識別情報（ＩＭＳＩ）エントリを有さない好ましくないネットワークからＧＰＲＳロケーション・アップデートを入手した後に、管理されたローミング・アプリケーション（ＭＲＡ）モジュール１３０は、この選択されたネットワーク中のローミング・サービス利用者のパーセンテージが、この準備されたしきい値を超過していることを決定する。したがって、管理されたローミング・アプリケーション（ＭＲＡ）モジュール１３０は、このＧＰＲＳロケーション・アップデート（ＬＵ）メッセージを妨げ、このキャッシュ・テーブル中にこの情報を記憶し、有効期間＝ＥｘｐｉｒａｔｉｏｎＴｉｍｅＦｉｒｓｔＥｎｔｒｙを設定する。しかし、これは１つの実施例にすぎないことを理解されたい。本明細書中で説明している他のコール・ロジック・ルーチンも実装することができる。

第３のケースでは、キャッシュ・テーブル中の国際的モバイル加入者識別情報（ＩＭＳＩ）を有するＧＰＲＳだけの加入者についての好ましい／２番目の好ましくないＧＰＲＳロケーション・アップデート（ＬＵ）が試みられる。このケースでは、図１６のコール・フロー１６００は、（１６０２、１６０４において）管理されたローミング・アプリケーション（ＭＲＡ）モジュール１３０が、この国際的モバイル加入者識別情報（ＩＭＳＩ）リスト・テーブル中で「ＧＰＲＳだけの加入者」フィールドをチェックした結果「ｙ」である加入者からＧＰＲＳロケーション・アップデートを受信しており、またはこのＧＳＭロケーション・アップデート（ＬＵ）が構成可能な期間内で以前に受信されていないことを示している。どちらのシナリオも、この加入者用の装置が、ＧＰＲＳだけについてのロケーション・アップデート（ＬＵ）を送信すること、またＧＳＭロケーション・アップデート（ＬＵ）が以前に送信されなかったことを意味している。

このコール・フローは、ＧＰＲＳ加入者が、「好ましい」ネットワークからのＧＰＲＳロケーション・アップデート（ＬＵ）を、または「好ましくない」ネットワークからの２番目のＧＰＲＳロケーション・アップデート（ＬＵ）を送信し、この加入者が、この国際的モバイル加入者識別情報（ＩＭＳＩ）テーブル中にエントリを有する（すなわち、この加入者についての以前の登録が前に拒否された）ことを示している。この加入者の登録が以前に拒否されているので、（１６０６において）この加入者の２番目の好ましくない登録は受け入れられ、このロケーション・アップデート（ＬＵ）は、ホーム・ロケーション・レジスタ（ＨＬＲ）１１８へと転送される。このシナリオにおいては、（１６１２、１６１４、１６１６において）空中（ＯＴＡ）メッセージもこの空中（ＯＴＡ）サーバへと送信されて、加入者のＳＩＭカード中にこの「好ましい」公衆地上モバイル・ネットワーク（ＰＬＭＮ）リストがダウンロードされて、この「好ましい」ネットワークへの加入者の登録が制御される。この加入者がこの「好ましい」ネットワーク中に登録される場合には、この加入者の登録は受け入れられ、ホーム・ロケーション・レジスタ（ＨＬＲ）１１８へと転送される。さらに、構成可能な期間内で以前に登録が妨げられなかった加入者についての好ましいＧＰＲＳ登録のケースでは、このコール・フローは、この空中（ＯＴＡ）メッセージがこの加入者に対して送信されない点を除いて、図１６に示すコール・フローと同様なものになる。

ローミングがこのサービス・プロバイダのネットワーク外で許可されないときには、第４のタイプのコール・ロジックを適用することができる。この機能は、プロバイダの中心施設に管理されたローミング・アプリケーション（ＭＲＡ）モジュール１３０を展開しているサービス・プロバイダのネットワーク中のみでロケーション・アップデート（ＬＵ）を許可する機能を提供する。このロケーション・アップデート（ＬＵ）が、好ましいネットワーク、または無関係のネットワーク（例えば、好ましいネットワークが存在しない国におけるネットワーク）を起源としている場合、これらすべてのロケーション・アップデート（ＬＵ）が受け入れられ、正しいホーム・ロケーション・レジスタ（ＨＬＲ）１１８に向けて中継されることになる。そうでない場合には、これらのロケーション・アップデートは、構成可能な原因と共に拒否されることになる。このネットワーク分類に基づいて、管理されたローミング・アプリケーション（ＭＲＡ）モジュール１３０のサービス・ロジックは、管理されたローミング・アプリケーション（ＭＲＡ）モジュール１３０のサービス・プロバイダのネットワークが存在する国においてしか適用されないことになる。サービス・プロバイダ（管理されたローミング・アプリケーション（ＭＲＡ）モジュール１３０をその中心施設に展開してきているサービス・プロバイダ）のネットワークが存在しない国においては、これらすべてのネットワークが無関係であるので、この管理されたローミング・サービス・ロジックは適用されない。しかし、もし無関係なネットワークを有する地域の場合、ある区域が好ましいものに引き上げられる場合には、この選択されたＭＳＣ／ＶＬＲ／ＳＧＳＮから到来するすべてのロケーション・アップデート（ＬＵ）は、まるでこれらが好ましいネットワークから到来したかのように処理されるはずである。

この機能は、この加入者プロファイルに基づいてアクティブ化されることになる。この国際的モバイル加入者識別情報（ＩＭＳＩ）に関連したテーブル中の、加入者ごとのフィールド、例えば「この管理されたローミング・アプリケーション・サービス・プロバイダのネットワークに属するロケーション・アップデート（ＬＵ）だけを許可すること」は、ネットワーク・レベルごとのフラグ、例えば「この管理されたローミング・アプリケーションを実施する」と一緒に使用されることになる。

第１のケースでは、加入者はこの無関係なネットワーク中におり、このロケーション・アップデート（ＬＵ）は、受け入れられる。このケースでは、図１７のコール・フロー１７００に示すように、（１７０２、１７０４において）管理されたローミング・アプリケーション（ＭＲＡ）１３０は、要求を受信した後に、このネットワーク・レベル・テーブル中の「この管理されたローミング・アプリケーションを実施する」フラグが、「真」としてマーク付けされているか、「偽」としてマーク付けされているかをチェックすることになる。このフラグが偽に設定されている場合には、このネットワークは「無関係なネットワーク」であると考えられ、それによって（１７０６において）管理されたローミング・アプリケーション（ＭＲＡ）モジュール１３０のロジックが実施されることになり、このロケーション・アップデート（ＬＵ）は、ホーム・ロケーション・レジスタ（ＨＬＲ）１１８へと中継されることになり、（１７０８、１７１０において）肯定応答が送信されることになる。このシナリオにおいては、このサービス・プロバイダのネットワークは、この加入者がローミングしている地域には存在しないので、好ましいネットワークおよび好ましくないネットワークは、存在しない。それ故、これらすべての登録（最初の登録および最後の登録）が許可される。

第２のケースでは、加入者は、管理されたローミング・アプリケーション（ＭＲＡ）モジュール１３０のサービス・プロバイダ・ネットワーク中におり、これらすべての好ましくないＬＵは妨げられる。図１８のコール・フロー１８００に示すように、「この管理されたローミング・アプリケーションを実施する」フラグが真に設定され、このＩＭＳＩ＿Ｌｉｓｔ＿テーブル中のその加入者ごとのフィールド「この管理されたローミング・アプリケーション・サービス・プロバイダのネットワークに属するロケーション・アップデート（ＬＵ）だけを許可すること」が、加入者、および管理されていないローミング・アプリケーション（ＭＲＡ）モジュール１３０のネットワークを起源とする（１８０２、１８０４における）この着信ロケーション・アップデート（ＬＵ）について真とマーク付けされている場合には、（１８０６において）このロケーション・アップデート（ＬＵ）は、妨げられることになる（最初のロケーション・アップデートおよび次のロケーション・アップデート）。このシナリオにおいては、このサービス・プロバイダのネットワークは、この加入者がローミングしているその全地域に存在している。

第３のケースでは、加入者は、この管理されたローミング・アプリケーション・サービス・プロバイダのネットワーク中におり、これらすべての好ましいロケーション・アップデート（ＬＵ）は受け入れられる。以下の図１９のコール・フロー１９００に示すように、「この管理されたローミング・アプリケーションを実施する」フラグが真に設定され、このＩＭＳＩ＿Ｌｉｓｔ＿テーブル中のその加入者ごとのフィールド「この管理されたローミング・アプリケーション・サービス・プロバイダのネットワークに属するロケーション・アップデート（ＬＵ）だけを許可すること」が、加入者、および管理されたローミング・アプリケーション（ＭＲＡ）モジュール１３０のＳＰのネットワークを起源とする（１９０２、１９０４における）この着信ロケーション・アップデート（ＬＵ）について真とマーク付けされている場合には、（１９０６、１９０８、１９１０において）このロケーション・アップデート（ＬＵ）は、受け入れられることになる。このシナリオにおいては、このサービス・プロバイダのネットワークは、この加入者がローミングしているその全地域に存在している。

以上の説明は、単に本発明の特定の実施形態の開示を示しているにすぎず、これらの実施形態に本発明を限定することは意図していない。したがって、本発明は、以上で説明した実施形態だけに限定されるものではない。そうではなくて、当業者なら、本発明の範囲に含まれる代替実施形態を考えつくことができることを理解されたい。

従来のネットワークのブロック図である。 本発明を実装することができるネットワークのブロック図である。 本発明による方法を示すフロー・チャートである。 本発明による管理されたローミング・サービス・モジュールのブロック図である。 本発明の一実施形態が実装されるネットワークのブロック図である。 本発明の一実施形態によるコール・フロー図である。 本発明の一実施形態によるコール・フロー図である。 本発明の一実施形態によるコール・フロー図である。 本発明の一実施形態によるコール・フロー図である。 本発明の一実施形態によるコール・フロー図である。 本発明の一実施形態によるコール・フロー図である。 本発明の一実施形態によるコール・フロー図である。 本発明の一実施形態によるコール・フロー図である。 本発明の一実施形態によるコール・フロー図である。 本発明の一実施形態によるコール・フロー図である。 本発明の一実施形態によるコール・フロー図である。 本発明の一実施形態によるコール・フロー図である。 本発明の一実施形態によるコール・フロー図である。 本発明の一実施形態によるコール・フロー図である。

Claims (2)

1. ホーム・ネットワークを有し、第２のネットワーク中をローミングする無線加入者に提供されるローミング・サービスを管理するための方法であって、
   前記加入者の前記ホーム・ネットワークの信号ゲートウェイにおいて前記第２のネットワークからのメッセージを受信する工程と、
   管理されたローミング・アプリケーションに前記メッセージを送信する工程と、
   前記メッセージが、ロケーション・アップデート要求であるかどうかを判定する工程と、
   前記メッセージがロケーション・アップデート要求ではない場合における処理のためのホーム・ロケーション・レジスタに前記メッセージを送信する工程と、
   前記メッセージが、ロケーション・アップデート要求である場合には、前記管理されたローミング・アプリケーションにより、前記メッセージについてコール・ロジック・ルーチンを実施する工程とを含み、
   前記コール・ロジック・ルーチンが少なくとも、
   前記第２のネットワーク上で許可された登録の所定のしきい値パーセンテージに基づいて前記ロケーション・アップデート要求を許可すべきかどうかを判定する工程と、
   前記第２のネットワークが好ましいネットワークであるかどうかに基づいて前記ロケーション・アップデート要求を許可すべきかどうかを判定する工程と、
   前記ロケーション・アップデート要求がＧＰＲＳ加入者を起源としているかどうかを判定し、この場合には完全なローミング・サービスを提供する工程と、
   前記ホーム・ネットワークおよび前記第２のネットワークが共通のサーバ・プロバイダに属するかどうかに基づいて前記ロケーション・アップデート要求を許可すべきかどうかを判定する工程とを含む方法。
2. 無線ネットワーク中で管理されたローミング・サービスを提供するためのシステムであって、
   その中に加入者データおよびネットワーク・プロファイル・データを記憶しているデータベースと、
   メッセージを受信し、前記メッセージがロケーション・アップデート要求であるかどうかを判定し、前記メッセージがロケーション・アップデート要求でない場合における処理するために前記メッセージをホーム・ロケーション・レジスタに送信し、前記要求がロケーション・アップデート要求である場合には、前記メッセージについてコール・ロジック・ルーチンを実施するように動作するとともに、前記データベースと協働した少なくとも１つのフロント・エンド・エレメントとを含み、
   前記コール・ロジック・ルーチンにおいて、前記フロント・エンド・エレメントが少なくとも、
   前記第２のネットワーク上で許可された登録の所定のしきい値パーセンテージに基づいて前記ロケーション・アップデート要求を許可すべきかどうかを判定し、
   前記第２のネットワークが好ましいネットワークであるかどうかに基づいて前記ロケーション・アップデート要求を許可すべきかどうかを判定し、
   前記ロケーション・アップデート要求がＧＰＲＳ加入者を起源としているかどうかを判定し、この場合には完全なローミング・サービスを提供し、
   前記ホーム・ネットワークおよび前記第２のネットワークが共通のサーバ・プロバイダに属するかどうかに基づいて前記ロケーション・アップデート要求を許可すべきかどうかを判定するシステム。

Images