(57)【要約】      （修正有）【課題】複数の国において加入者にセルラ通信サービスを提供するようモバイルネットワークを管理する方法を提供する。【解決手段】方法は、複数の国の全てをカバーする中央ノードからセルラ通信サービスの第１セットを提供するステップと、複数の地域ノードからセルラ通信サービスの第２セットを提供するステップであって、各地域ノードは複数の国のサブセットにセルラ通信サービスの第２セットを提供する、提供するステップとを有する。【選択図】なし【特許請求の範囲】
【請求項１】
複数の国において加入者にセルラ通信サービスを提供するようモバイルネットワークを管理する方法であって、
前記複数の国の全てをカバーする中央ノードから前記セルラ通信サービスの第１セットを提供するステップと、
複数の地域ノードから前記セルラ通信サービスの第２セットを提供するステップであって、各地域ノードは前記複数の国のサブセットに前記セルラ通信サービスの第２セットを提供する、提供するステップと、
を有する方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信に関し、具体的には携帯電話ネットワークアーキテクチャ並びに関連するネットワーク要素及びサービスの提供に関する。
【背景技術】
【０００２】
従来の携帯電話ネットワークは国毎に構築されてきた。従って、各国は、当該国内に配置された全てのサービスのためのフルセットの設備を有する。従って、サービス国に配置された−サービス提供される物理的エリアに配置される必要がある要素−無線タワー及びマイクロ波バックホールだけでなく、全てのシグナリング及び付随するカスタマケア及び課金設備もまた各国に配置されている。このアプローチは、グローバルネットワークにおける効率性を欠き、オペレータ及び消費者に不利益となりうる。いくつかの利益が、複数の国内ネットワークへの消費者の優先的なアクセスを可能にするアプローチにより提供できる。このようなシステムは、出願人の先願ＷＯ２０１１／０３６４８４において開示されている。これは、中央サービス−“ＩＭＳＩブローカ”−が、必要に応じて新たな識別情報を有するモバイルハンドセットのＳＩＭを提供するよう構成されるシステムを開示する。
【０００３】
この種類の地理的制約に更に対処することによって、コストを更に低減することが望ましい。これは、従来の携帯電話ネットワークがこのように構築されているため、チャレンジングである。他のビジネスモデルを実行するネットワークは、このような地理的制約を有さない。例えば、ＡｍａｚｏｎやＧｏｏｇｌｅなどのインターネット企業は、少数の大きなデータセンタにおいて世界にサービスを提供するインフラストラクチャを配置することができる。このようなインフラストラクチャの中央化は、携帯電話ネットワークにとって実践的でない。例えば、オーストラリアの顧客からオーストラリアの顧客への呼が全く異なる地域の主要なデータセンタを介し通過することは望ましくない。これは、呼の遅延を許容できないレベルに増加させる。
【発明の概要】
【０００４】
本発明者は、個々の地域における許容できない遅延を生じさせることなく、ネットワークのコスト及び品質を最適化するため、ローカル、地域及び中央データセンタの間の分割においてリソースを配分することが可能であると理解した。
【０００５】
本発明の課題は、ローカル、地域及び中央データセンタ間にネットワーク要素、オペレーショナル・サポート・システム（ＯＳＳ）及びビジネス・サポート・システム（ＢＳＳ）を分割する新たな形態のモバイルアーキテクチャを提供することである。１つの広い大洋では、このようなシステムは、ネットワーク要素がローカル又は地域データセンタを有する一方、地域又は中央データ選択に少なくとも部分的に含まれるビジネス・サポート・システム及びオペレーショナル・サポート・システムを有する。ローカルデータセンタは単一の国をサポートし、地域データセンタは複数の国をサポートする一方、中央データセンタはワールドワイドネットワークをサポートする。更なる態様では、ワールドワイドモバイルサービスを提供するシステムは、ＯＳＳ及びＢＳＳ機能を実行するよう構成される中央サーバと、オーディオ及びデータサービスを提供するよう構成される１以上の地域サーバ及び／又は１以上のローカル（国内）サーバとを有してもよい。
【０００６】
第１の態様では、本発明は、複数の国において加入者にセルラ通信サービスを提供するようモバイルネットワークを管理する方法であって、前記複数の国の全てをカバーする中央ノードから前記セルラ通信サービスの第１セットを提供するステップと、複数の地域ノードから前記セルラ通信サービスの第２セットを提供するステップであって、各地域ノードは前記複数の国のサブセットに前記セルラ通信サービスの第２セットを提供する、提供するステップとを有する方法を提供する。
【０００７】
このアプローチは、ネットワークのコスト及び品質を最適化することを可能にする。このアーキテクチャを利用することは、全体的なネットワークを提供するためより少数のコンポーネントしか利用しないことを可能にする。さらに、より少数のコンポーネントしか必要でないため、それぞれはより大きくすることができ、より良い品質及び冗長性の増加を可能にする。コンポーネントは単一の国でなく世界又は国のグループにサービス提供可能であるため、ネットワークのロードバランシングが追跡可能である。例えば、シグナリングサーバは、東京の顧客がリソースを広範に利用しているとき、ロンドンの顧客により未使用であるかもしれない。
【０００８】
遅延問題は、２つのパーティ間の実際の通信をサポートする、特に、２つのパーティ間の音声呼をサポートするのに必要なネットワークアクションが、双方のパーティをサポートするローカルデータセンタによって、又は各パーティの関連するローカルデータセンタによって実行されてもよい。遅延に影響を与えない呼に関連するアクション（ＯＳＳ又はＢＳＳにより処理される他のオペレーショナル又はビジネスサポート機能など）は、地域データセンタ又は中央データセンタにより処理されてもよい。
【０００９】
更なる広範な態様では、ネットワークは、１つの地域に関連するデータセンタが故障の場合に他の地域をサポートしてもよいように、冗長性のため構成されてもよい。いくつかの構成では、ネットワークは、データセンタにおいて提供されるＢＳＳ及びＯＳＳ機能とローカルネットワークとのインタラクションによって、ローカルオペレータにより提供される。データセンタは、専用の通信バックボーンにより接続されてもよい。
【図面の簡単な説明】
【００１０】
本発明の特定の実施例が、添付した図面を参照して具体例により後述される。
【図１】図１は、複数の国にわたる携帯電話ネットワークの一例となる構成を示す。
【図２】図２は、本発明の実施例によるワールドワイドモバイルネットワークをサポートするよう構成されるネットワークアセットの論理分布を示す。
【図３】図３は、本発明の実施例による地域データセンタにおいて提供される機能の具体例を示す。
【図４】図４は、本発明の実施例によるネットワーク要素の間の接続を示す。
【図５】図５は、物理的接続を示す本発明の実施例を示す。
【図６】図６は、ＳＳ７アーキテクチャを示す本発明の実施例を示す。
【図７】図７は、ＩＳＵＰシグナリングのためのシグナリングアプローチを示す本発明の実施例を示す。
【図８】図８はＳＣＣＰシグナリングのためのシグナリングアプローチを示す本発明の実施例を示す。
【図９】図９は、ＩＰピアリング及びデータトラフィックを示す本発明の実施例を示す。
【図１０】図１０は、地域データセンタの実施例を示す。
【図１１】図１１は、ＭＮＯとの直接的な相互接続のための構成を示す。
【図１２】図１２は、複数のＧＲＸの提供によるアーキテクチャを示す。
【図１３】図１３は、サービス相互接続のための構成を示す。
【図１４】図１４は、リファレンスコールフローを示す。
【図１５】図１５は、リファレンスコールフローを示す。
【図１６】図１６は、リファレンスコールフローを示す。
【図１７】図１７は、シグナリング設計の更なる態様を示す。
【図１８】図１８は、ＳＩＰ接続のための構成を示す。
【図１９】図１９は、モバイルナンバーポータビリティのための一般化されたフローを示す。
【図２０】図２０は、モバイルナンバーポータビリティのためのメッセージモデルを示す。
【図２１】図２１は、モバイルナンバーポータビリティのための一般化された処理フローを示す。
【図２２】図２２は、モバイルナンバーポータビリティのための再利用テンプレートを示す。
【図２３】図２３は、ナンバー分類テーブルを示す。
【図２４】図２４は、ナンバー分類のための方式を示す。
【図２５】図２５は、ナンバー分類のための方式の修正を示す。
【図２６】図２６は、ＡＰのためのＧＧＳＮを定義するための異なるモデルを示す。
【図２７】図２７は、ＡＰのためのＧＧＳＮを定義するための異なるモデルを示す。
【図２８】図２８は、ＡＰのためのＧＧＳＮを定義するための異なるモデルを示す。
【発明を実施するための形態】
【００１１】
図１は、ネットワークに関連するデータセンタと共に、複数の国にわたる携帯電話ネットワークの一例となる構成を示す。データセンタは、ロンドン、アムステルダム、香港、シドニー、ニューヨーク及びロサンジェルスに存在し、説明される実施例におけるこれらのデータセンタは地域及び／又はグローバル機能（純粋な国内データセンタは図示しない）を有する。これらは、典型的には、当該国におけるローカルオペレータとのインタラクションによって、複数の国における国内ネットワークをサポートする。後述されるように、いくつかのデータセンタは１つのみの国内ネットワーク（又はおそらく１つの国のための複数の国内ネットワーク）をサポートするローカルデータセンタとして機能し、いくつかのデータセンタは複数の国における国内ネットワークをサポートするローカルデータセンタとして機能し、少なくとも１つのデータセンタは少なくともいくつかのサービスのための全てのネットワークをサポートするためのグローバルデータセンタとして機能することによって、異なるデータセンタは異なる機能を提供してもよい。単一のデータセンタが複数の役割を有してもよく、例えば、いくつかの目的のためにはローカルデータセンタとして、他の目的のためには地域データセンタとして、他の目的のためにはグローバルデータセンタクトとして機能してもよい。
【００１２】
図２において、当該タスクの分割がより詳細に示され、ワールドワイドモバイルネットワークをサポートするためのネットワークアセットの論理分布を示す。図２から理解できるように、本実施例では、ロンドン及びアムステルダムのデータセンタは、個々の通信の遅延に影響を与えないＯＳＳ及びＢＳＳ機能をサポートするグローバルデータセンタとして機能する。これらの機能は、中央化された課金、顧客管理、故障管理及びパフォーマンス管理を含むものであってもよい。６つ全てのデータセンタは、グローバルに非中央化され、グローバルにレジリエントなネットワークのための基礎を提供する地域データセンタとして機能する。これは、適切である場合、機能を地域にローカライズすることを可能にし、また需要が十分高くなるとき、新たなデータセンタを地域レベルで加えることによって、また、これが需要を最も効果的にサポートするとき、ある地域データセンタと他の地域データセンタとの間でサポートがスイッチされることを可能にすることによって、ネットワークに対するスケーラビリティ及びフレキシビリティを可能にする。
【００１３】
図２に示されるように、これらの地域データセンタは異なる地理的地域におけるローミングをサポートするのに利用されてもよい。この場合、ロサンジェルス及びニューヨークのデータセンタは米国におけるローミングをサポートし、ロンドン及びアムステルダムのデータセンタはＥＭＥＡ（Ｅｕｒｏｐｅ，Ｍｉｄｄｌｅ  Ｅａｓｔ  ａｎｄ  Ａｆｒｉｃａ）におけるローミングをサポートし、香港及びシドニーのデータセンタはアジアパシフィックにおけるローミングをサポートする。これらのデータセンタは国内オペレータとやりとりし、これらは各地域において異なる国内オペレータであってもよく、単一の地域に複数のオペレータを含むものであってもよい。グローバル及び地域データセンタ（及び好ましくは、それらの間の専用のバックボーン）は、典型的には通常の制御下にあるが、国内オペレータのネットワークは、典型的にはそうでない。加入者ＳＩＭ（好ましくは、出願人の先願ＷＯ２０１１／０３６４８４に説明されるアプローチに従って提供される）には、これら複数の国内ネットワークにアクセスするためのＩＭＳＩが備えられてもよく、これら全てのＩＭＳＩは、グローバル及び地域データセンタを有するグローバルネットワークに関連するユーザアカウントに関連付けされる。
【００１４】
図３は、グローバル及び地域データセンタにより提供される機能の表示を提供する。ホーム・ロケーション・レジスタ（ＨＬＲ）の提供などのネットワーク機能を含むフル範囲のＯＳＳ及びＢＳＳ機能が、ロンドン及びアムステルダムの２つのグローバルデータセンタにおいて提供される。各グローバルデータセンタにおけるこれらの機能の提供は、故障の際の冗長性を提供する。本実施例における地域データセンタには、地域通信トラフィックをサポートするためのより限定的な機能群しか備えられず、これらは、異なるネットワークタイプの間でデジタルメディアストリームを変換するため、インターネット及びＭＧＷ（Ｍｅｄｉａ  Ｇａｔｅｗａｙ）などのパケット交換ネットワークとＧＰＲＳネットワークとの間のスイッチングを可能にするためのＧＧＳＮ（Ｇａｔｅｗａｙ  ＧＰＲＳ  Ｓｕｐｐｏｒｔ  Ｎｏｄｅ）である。これらの機能のグローバルでなく地域的な提供は、これらの機能がグローバルに提供される場合に生じる遅延問題を回避する。主要なシグナリング制御ノードは、グローバルデータセンタに配置されるが、メディア処理ノードは、国内ネットワークの近くに配置され、インターネットとのローカルイグジットである。
【００１５】
図示される特定の構成では、ポリシー及び課金制御ノード（ＰＣＲＦ及びＯＣＳ）は、グローバルデータセンタに配置される。これらとＢＳＳ及びＣＲＭ（Ｃｕｓｔｏｍｅｒ  Ｒｅｌａｔｉｏｎｓｈｉｐ  Ｍａｎａｇｅｍｅｎｔ）システムと一緒にすることは、これらがディープ接続されるとき、論理的である。他のバックエンドインタフェースは、グローバルデータセンタに最も便利には提供されてもよい。メディア処理ノードに加えて、地理的位置に関連する他の特定の制御ノードは、地域データセンタに配置されてもよい。
【００１６】
グローバルデータセンタと地域データセンタ（例えば、Ｇｘ及びＧｙインタフェース）との間で交換される制御及びシグナリングトラフィックは、共通のバックボーンによりトランスポートされる。データセンタをリンクさせる一例となるバックボーン構成が図４に示される。図４はまた、ネットワークのための冗長性及びスケーリングサービスを提供するネットワーク要素の間の接続を示す。ＯＡＭ（Ｏｐｅｒａｔｉｏｎｓ，Ａｄｍｉｎｉｓｔｒａｔｉｏｎ  ａｎｄ  Ｍａｎａｇｅｍｅｎｔ）トラフィックは、ＯＡＭプラットフォームが配置されるグローバルデータセンタに送信される。必要とされる全てのトラフィック接続は、共通のバックボーンを介し実現される。これは、ＶＰＬＳなどのバーチャルプライベートネットワークとして提供されてもよい。図示される構成では、２つの主要なキャリアは、冗長性のための各データセンタにおいて実際の物理的接続を提供する。データセンタ間の交差を必要とする全てのタイプのトラフィックは、専用の接続が提供される、キーデータベース同期（ＨＬＲ、オンライン課金システム）を除きリンクされる。外部の相互接続は、各データセンタにおけるスポークモデル及びハブに備えられる。トラフィックは、異なるＶＲＦ（バーチャルルーティング及びフォワーディング）を利用してバックボーン内で分離されてもよい。
【００１７】
図１０は、リモートモバイル・パケット・コアとしてもみなすことが可能な地域データセンタのための典型的な構成を示す。ポリシー及び課金などの中央に提供されるサービスは、中央（又はおそらく他の地域）データセンタからバックボーンを介し提供される。データセンタ自体は、中央的でなく地方の地域に提供するのに適したＧＧＳＮ及び他のネットワーク要素を有する。このとき、地域データセンタは、ローカルなインターネット、グローバルローミングを介したローミング（ＧＲＸ）及び直接的なオペレータ接続（ＭＮＯ  Ｄｉｒｅｃｔ）を提供する。
【００１８】
図５は、音声のための１つの接続構成を示す。これは、地域データセンタとＭＮＯ（Ｍｏｂｉｌｅ  Ｎｅｔｗｏｒｋ  Ｏｐｅｒａｔｏｒ）との間の直接的な接続である。理解できるように、異なる地域データセンタは、適切な交換及び伝送ネットワークを介しＭＮＯに接続可能であり、これにより、ＭＮＯは必要に応じて複数の地域データセンタによりサポート可能である。図６〜８は、他の音声のための相互接続構成を示す。図６は、グローバルデータセンタと個々のＳＳ７  ＳＴＰ（Ｓｉｇｎａｌ  Ｔｒａｎｓｆｅｒ  Ｐｏｉｎｔ）との間の接続を示すＳＳ７リンクアーキテクチャを示す。関連するＩＳＵＰ（ＩＳＤＮ  Ｕｓｅｒ  Ｐａｒｔ）シグナリングが図７に示され、ＳＣＣＰ（Ｓｉｇｎａｌｉｎｇ  Ｃｏｎｎｅｃｔｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐａｒｔ）シグナリングが図８に示される。図９は、データのための接続構成を示す。
【００１９】
一例となるネットワーク構成及び一例となるシグナリング構成の態様がより詳細に説明される。
【００２０】
複数の異なるアクセス相互接続が提供されてもよい。好適なアプローチは、図１１に示されるように、ＭＮＯとの直接的な相互接続に対するものである。図示された構成では、ＣＮＯ（グローバル及び地域データセンタについて担当するコア・ネットワーク・オペレータ）とＭＮＯとの間で交換される全てのデータは、制御プレーン又はユーザプレーンに関するものである場合、直接的な相互接続リンクを介し移動する。冗長性のため、リンクは異なるサードパーティプロバイダからのものであってもよく、オペレータ間のＢＧＰ／ＩＰピアリングを実現してもよい。好ましくは、各ＭＮＯは、上述されるように、冗長性のための２つの異なるＣＮＯデータセンタに接続される。
【００２１】
利用可能な他の構成は、スポンサーローミング（それ自体のナンバリング範囲はないが、スポンサーにより提供されたＩＭＳＩサブ範囲を利用して、ＭＶＮＯ（Ｍｏｂｉｌｅ  Ｖｉｒｔｕａｌ  Ｎｅｔｗｏｒｋ  Ｏｐｅｒａｔｏｒ）により運営されうる）又はＧＲＸハブプロバイダを利用したローミングを含むものであってもよい。ＧＲＸは、標準的な国際ローミングのためのＧＳＭ（登録商標）オペレータを相互接続する正規の方法としてＧＳＭＡにより指定されている。オペレータは、ＩＲ２１と呼ばれるドキュメントを介し他のオペレータに自らの識別子及びナンバリングプランを通知する。この“多対多”相互接続のための実際のインフラストラクチャは、ハブとして機能するキャリアにより提供される。図１２は、マルチＧＲＸ提供によるハイレベルアーキテクチャを示す。
【００２２】
サービス相互接続は、相互接続の接続性に関連し、またＢｌａｃｋＢｅｒｒｙネットワークなどのプライベートデータネットワークに関連する。相互接続の接続性はモバイル・パケット・コアにより提供され、それは、ＧＧＳＮによってモバイルユーザに利用可能とされるが、コアバックボーンにより実現される。
【００２３】
このための構成が、図１３に示される。各データセンタは、通常は２つのローカルＩＳＰ（冗長性のため）により提供されるインターネットとの自らの接続を有する。これは、データセンタサイト間のバックボーンを介したＧｉインタフェーストランスポートが必要でないことを意味する。これは、アクセス遅延及びバックボーン帯域幅要求を低減し、トポロジーを簡単化する。
【００２４】
ローカルＩＳＰとの接続は、コアバックボーンにより実現される直接的な相互接続を介し実現される。ＣＮＯパブリックＩＰアドレススペースは、これらの接続において利用される。トラフィックがインターネットにイグジットする前に、コアバックボーンにより必要とされる場合、モバイルユーザアクセスのためのＮＡＴ／ＰＡＴがまた実行される。インターネットＤＮＳサービスはローカルＩＳＰにより実行され、これにより、ＣＮＯはインターネットアドレス決定のための内部的なＤＮＳを必要としない。
【００２５】
このトポロジーによって、ＣＮＯは、ＧＧＳＮが存在するローカルインターネットアクセスを提供する。ローカルインターネットアクセス予想をサポートするため、ロカリティの通知に基づきサービスを提供するための手段がとられる必要がある。例えば、Ｐｏｌｉｓｈユーザは、インターネットにアクセスするとき、Ｐｏｌｉｓｈ言語へのそれのアクセスを自動的にリダイレクトするため、Ｇｏｏｇｌｅ（又は他のウェブサイトプロバイダ）を有することを期待するかもしれない。これは、典型的には、ユーザのＩＰアドレスに基づき実行される。
【００２６】
ＢｌａｃｋＢｅｒｒｙ接続について、ＢｌａｃｋＢｅｒｒｙ  ＰＯＩとのピアリングを達成することが必要である。これは、直接的な相互接続、ＩＰＸ相互接続又はＧＲＥトンネリングなどによって、複数の方法により実行されてもよい。
【００２７】
個々のネットワーク要素がここで説明される。ＧＧＳＮは、３ＧＰＰ  ＴＳ  ２３．２０３及び２９．２１２によるビルトインＰｏｌｉｃｙ  ａｎｄ  Ｃｈａｒｇｉｎｇ  Ｅｎｆｏｒｃｅｍｅｎｔ  Ｆｕｎｃｔｉｏｎ（ＰＣＥＦ）を有してもよく、このため、主要な機能はイベントトリガ、レポートトラフィック統計（例えば、ボリューム、時間）をサポートし、ポリシー制御サーバ（Ｐｏｌｉｃｙ  ａｎｄ  Ｃｈａｒｇｉｎｇ  Ｒｕｌｅｓ  Ｆｕｎｃｔｉｏｎ，ＰＣＲＦ）により指示されるようにＱｏＳを適用することである。ローカルルールがまた設定され、何れのサービスが利用中であるか検出するため、サービスアウェアネス機能が利用され、これにより、ポリシー及び課金がデータフローレベルにおいて適用可能である。Ｌ３及びＨＴＴＰレベルの双方においてダイナミックベアラＱｏＳマネージメント、サービス及びデータフローグレーティング及びトラフィックリダイレクションなどのポリシー実施が提供されてもよい。完全に内部的なハードウェア冗長性は、例えば、アクティブ／スタンバイ冗長性モデルを利用して、複数のサービスブレードの間のスイッチオーバにより復元力をサポートするのに利用されてもよい。これは、アクティブ／スタンバイリカバリユニットペアを含むリカバリグループに基づくものであってもよい。リカバリグループは、リカバリグループにリンク付け可能なリソース（例えば、ディスクファイルシステム又はＩＰアドレス）を制御するのに利用される。例えば、ＩＰアドレスがリカバリグループにリンク付けされるとき、それは、高可用性サービス（ＨＡＳ）機能がリカバリユニットに対して制御及び配分する移動可能なリソースになる。リカバリグループ内の現在アクティブなリカバリユニットは、移動可能なリソースを所持し、アクティブなリカバリユニットが失敗した場合、移動可能なリソースの機能はスタンバイ中のリカバリユニットにスイッチされる。冗長性及びトラフィック継続性を確保するため、各タイプのトラフィックは、別のポート上に構成される２つのＶＬＡＮに配置される。
【００２８】
ＡＰＮ解決及びＡＡＡサービスなどの他のネットワーク機能は、地域データセンタに配置されたサーバにより提供されてもよい。冗長性は、ハードウェアによって又はサービスレベルにおいてサポートされてもよい。
【００２９】
ポリシー制御及び課金は、中央データセンタに備えられ、好ましくはまた、フォールハードウェア冗長性を利用する（ＯＣＳはより複雑であり、複数の戦略を利用可能な相互接続されたシステムのネットワークを伴う）。ネットワークバックアップなどの他のサービスが中央的に提供されてもよい。
【００３０】
サービス冗長性はまた重要であり、ネットワーク要素の故障、内部接続リンクの故障及びサイトの故障を含むフェイルオーバシナリオを計画することによって実現される。典型的には、サービスフェイルオーバは、サービスの提供においてデータセンタの変更を伴う。これは、モバイル・パケット・データ・サービスが実現されるとき、各ＧＧＳＮ位置においてセッション／ベアラ確立のため独立して当該アーキテクチャにより実現可能である。
【００３１】
Ｇｐインタフェースにおける冗長性がまた望ましく、これは２つの異なるオペレータのコアネットワーク（ＰＳドメイン）の間の相互接続インタフェースである。それは、Ｖｉｓｉｔｅｄネットワーク（ＳＧＳＮ）及びＨｏｍｅネットワーク（説明されたＣＮＯのためのＧＧＳＮ）を相互接続する。それは、ＡＰＮの解決（基本的には、サービスを提供するＧＧＳＮの選択）のためホームＤＮＳをクエリするため、Ｖｉｓｉｔｅｄ  ＳＧＳＮ及び／又はＤＮＳにより利用されるＤＮＳインタフェースを伴う。このクエリは、ＧＲＸを介し又はＭＮＯとの直接的な相互接続リンクを介しルーティングされ、ＡＰＮ解決は双方のシナリオにおいて異なる。このため、各データセンタにおける２つのＤＮＳサーバのそれぞれは異なるＤＮＳクラスタに属する。ＡＰＮ解決の後、ＧＧＳＮが特定のＰＤＰを処理するのに選択される。ＧＧＳＮの選択は、問い合わされたＤＮＳと、当該呼シナリオとに依存する。冗長性は、ユーザＩＭＳＩ、アクセスタイプ及びＤＮＳコンフィギュレーションに基づくコンフィギュレーションを介し実現される。
【００３２】
Ｇｉインタフェース上の冗長性は、データサービスのため実現される。内部的な冗長性は、冗長な地理的エンドポイント及び異なるリンクプロバイダを利用して接続レベルにおいてコアバックボーンにより保証されるローカルＩＳＰとの接続によって、ＧＧＳＮレベルにおいて提供される。インターネットＤＮＳサービスについて、ＩＳＰのＤＮＳサーバが再利用され、サービスＡＰＮに設定される。各ＩＳＰプロバイダは、冗長性のため２つのＤＮＳサーバを提供する。インターネットアクセスは、好ましくは、フェイルオーバシナリオにおいてさえサービングＧＧＳＮと併存して常に提供され、これは、バックボーンを介しデータセンタ間で転送されるインターネットトラフィックが必要でないことを意味する。
【００３３】
冗長性が、２つのグローバルデータセンタにおいてアクティブ／アクティブ又はアクティブ／スタンバイ設定を利用して、Ｇｙインタフェース（モバイル・パケット・データサービスのオンライン課金のため）及びＧｘインタフェース（モバイル・パケット・データサービスのポリシー制御のため）において提供される。
【００３４】
ネットワークサービスの提供がここで説明される。モバイル・データ・サービスがサービスアクションポイント（ＡＰ）上で実現される。これらは、それの名前、従って、アクセスポイント名（又はＡＰＮ）により識別される。ＡＰＮは、提供されるサービス特性と共に、サービスを処理するＧＧＳＮを定義する。これらの特性は、ルーティングインスタンス選択、ユーザ装置へのＩＰアドレス配分（ＩＰプール）、認証、会計及び課金、ポリシー実施、帯域幅及びＱｏＳ制御及びアクセス制御を含む。
【００３５】
ＡＰＮは、ＨＬＲにおける加入者プロファイルに設定され、ＰＳ  Ａｔｔａｃｈに成功すると、ＳＧＳＮに提供される。その後、それは、ユーザ装置によってデータセッション（ＰＤＰコンテクスト）をリクエストするのに利用され、ＨＬＲから受信したプロファイルに従ってＳＧＳＮにより検証され、Ｇｎ／Ｇｐ  ＤＮＳを介し解決され、ｔｈｒｕ  ＧＴＰシグナリングがＧＧＳＮにわたされ、その後、ＯＣＳ及びＰＣＲＦと同様に他のコアネットワーク要素と共にリクエストを処理する。
【００３６】
図２６〜２８は、ＡＰＮのＧＧＳＮを決定するための異なるモデルを示す。
【００３７】
図２６の構成では、移動局（ＭＳ）がＳＧＳＮに登録すると、ＨＬＲはそれについて許可されたＡＰＮをそれに提供する。移動局のＴＥ（信頼された要素）は、ＰＤＰ（Ｐａｃｋｅｔ  Ｄａｔａ  Ｐｒｏｔｏｃｏｌ）をリクエストするため、ＭＳのＡＰＮを選択する。ＳＧＳＮは、ＰＤＰセッションが何れのＧＧＳＮに対して確立されるべきか知るため、ＨＰＬＭＮ  ＤＮＳ（３として示される）からＡＰＮを解決する。ここで、これはＧＧＳＮ１に対して自動的に解決され、ＧＧＳＮはＰＤＰを受け入れ、インターネットへのアクセスが確立される。当該アプローチは、ＧＧＳＮのインテリジェントな選択を可能にしない（例えば、ＭＳの位置に基づく）。
【００３８】
図２７の構成では、移動局（ＭＳ）がＳＧＳＮに登録すると、ＨＬＲは再びそれについて許可されたＡＰＮをそれに提供する。移動局のＴＥ（信頼された要素）は、ＰＤＰ（Ｐａｃｋｅｔ  Ｄａｔａ  Ｐｒｏｔｏｃｏｌ）をリクエストするため、ＭＳのＡＰＮを選択する。ＳＧＳＮは、ＰＤＰセッションが何れのＧＧＳＮに対して確立されるべきか知るため、ＨＰＬＭＮ  ＤＮＳ（３として示される）からＡＰＮを解決する。これは、ＧＧＳＮ１に対して自動的には解決されず、それはＤＮＳ  Ｖｉｅｗ及びゾーンを利用して、リクエストの発信元のＳＧＳＮに従ってＧＧＳＮを選択する。選択されたＧＧＳＮはＰＤＰを受け入れ、インターネットへのアクセスが確立される。当該アプローチは、要求元のＳＧＳＮに基づきＧＧＳＮのより適切な選択とより大きなフレキシビリティを可能にする。
【００３９】
図２８の構成では、移動局（ＭＳ）がＳＧＳＮに登録すると、ＨＬＲは、ここでは信頼された要素ＡＰＮに関連するＡＰＮ１〜ＡＰＮｘとして示される許可されたＡＰＮのグループをそれに提供する。ＴＥは、元のＡＰＮとのデータセッションが確立可能である場合、ＳＩＭにより報告及びチェックし、ＳＩＭは、ＭＳが登録されるネットワークなど、コンフィギュレーション基準に依存して元のＡＰＮをＡＰＮ１〜ＡＰＮｘの何れかにマッピングするようプログラムされる。その後、ＭＳは変換されたＡＰＮによりＰＤＰリクエストを送信し、ＳＧＳＮは正しいＧＧＳＮを特定するため、ＨＰＬＭＮ  ＤＮＳから正しいＡＰＮを解決し、インターネットへのアクセスが以前のように確立される。このモデルは、ＳＩＭから又は移動機において導出可能な何れか適切なパラメータからのＧＧＳＮの選択を可能にするため、好ましい。それはまた、処理における特定のローミング嗜好又は合意があるとき、ＨＰＬＭＮにより大きな制御を提供し、これは、例えば、北米地域における全てのデータトラフィックについてＵＳ  ＧＧＳＮを利用することによって、データトラフィックの地域化を可能にできる。
【００４０】
ＡＰＮ名が、ユーザが加入している特定のサービスを示すのに選択され、認証、許可、会計及び課金並びにセッション制御に伴う異なるプラットフォームにより知られる必要がある。
【００４１】
ＧＧＳＮは、ＰＣＣルール下で適用可能となるように、ＳＰＩ（Ｓｈａｌｌｏｗ  Ｐａｃｋｅｔ  Ｉｎｓｐｅｃｔｉｏｎ）及びＤＰＩ（Ｄｅｅｐ  Ｐａｃｋｅｔ  Ｉｎｓｐｅｃｔｉｏｎ）の双方を可能にするサービスアウェアネス機能をサポートしてもよい。モバイル・パケット・データサービスは、ＭＭＳのためのベアラを提供してもよい。合法的な傍受が、必要とされる場合、ＧＧＳＮにおいてデータサービスのために提供されてもよい。ポリシー制御及び課金はそれぞれ、Ｇｘ及びＧｙインタフェースを利用して外部サーバによりＧＧＳＮにおいて処理される。
【００４２】
上述したアーキテクチャは、ＬＴＥを利用したネットワークについて容易に修正可能である。ＬＴＥは、ＨＬＲの代わりにホーム・サブスクライバ・サーバを利用し、ＨＬＲはＨＳＳにより置換可能であるか、又は、これら２つがパラレルに実現されてもよい。アーキテクチャはまた、ホームルーティング及びローカルブレイクアウトのＬＴＥデータローミングパラダイムをサポートするよう容易に更新されてもよい。同様に、このアーキテクチャは、ＩＰｖ６をサポートするよう容易に適応化されてもよい。
【００４３】
図１４〜１６において、リファレンスコールフローが示される。
【００４４】
シグナリング設計の更なる態様が以下において更に説明される。２つのタイプのネットワークノード、すなわち、ＭＳＳ（ＭＳＣ  Ｓｅｒｖｅｒ  Ｓｙｓｔｅｍ）及びＳＴＰ（Ｓｉｇｎａｌ  Ｔｒａｎｓｆｅｒ  Ｐｏｉｎｔ）がシグナリングのためのレスポンスであり、これらが図１７に示される。これらは、Ｖｏｉｃｅ  ＩＳＵＰ及びモビリティシグナリング（ＳＣＣＰ）を担当する。ＳＣＣＰルーティングは、ＣＮＯ加入者がロケーションアップデートを実行する相互接続パートナのネットワークのＭＳＳに対するＣＮＯのＨＬＲからのロケーションアップデートレスポンスに必要とされる。ＭＳＳとＭＧＷとの間の制御プレーンは、Ｈ．２４８／ＭＥＧＡＣＯ及びＭ３ＵＡ／ＳＩＧＴＲＡＮから構成される。Ｈ．２４８インタフェースは、ＭＳＳがＭＧＷ制御機能を有するＭＧＷとＭＳＳとの間のリソース制御及び他のマネージメント機能のために利用される。ＳＩＧＴＲＡＮインタフェースは、ＭＳＳとＭＧＷとの間のシグナリングメッセージをルーティングするのに利用され、ＭＧＷはＭＳＳと何れかの外部のネットワーク要素との間のシグナリング
ゲートウェイとして機能する。
【００４５】
ＩＳＵＰプロトコルは、異なるネットワークとの接続のため利用される。国内及び国際相互接続とのシグナリングルーティングは、ＳＣＣＰトラフィックについてはグローバル・タイル上で、ＩＳＵＰトラフィックについてはＳＰＣ上となる。
【００４６】
Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ（ＳＩＰ）は、２以上の参加者の間のマルチメディアセッションを生成及び管理するのに利用されてもよい。ＳＩＰの一般的な目的は、Ｖｏｉｃｅ  ｏｖｅｒ  ＩＰ（ＶｏＩＰ）をサポートし、将来的なＶｏＩＰサービスがフルインターネットベースになることを保証することである。これは、他のＭＳＣサーバ（ＭＳＳ）機能により動作してもよく、ＭＳＳにおけるＭｅｄｉａ  Ｇａｔｅｗａｙ  Ｃｏｎｔｒｏｌ  Ｆｕｎｃｔｉｏｎ（ＭＧＣＦ）を実現する。
【００４７】
ＳＣＴＰ（Ｓｔｒｅａｍ  Ｃｏｎｔｒｏｌ  Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｐｒｏｔｏｃｏｌ）は、Ｍ３ＵＡとＨ．２４８トラフィックとの双方を搬送する物理ＩＰレイヤの上位のレイヤである。ＭＳＳ及びＳＴＰは、モビリティ関連イベントの大部分においてＳＣＣＰゲートウェイとして機能する。ＭＮＯから発信されたＳＣＣＰトラフィックは、Ｄｅｓｔｉｎａｔｉｏｎ  Ｐｏｉｎｔ  Ｃｏｄｅ（ＤＰＣ）及びＳｕｂ−Ｓｙｓｔｅｍ  Ｎｕｍｂｅｒ（ＳＳＮ）に変換されたＧｌｏｂａｌ  Ｔｉｔｌｅ（ＧＴ）に基づき内部サービスプラットフォーム要素に転送される。
【００４８】
従って、２つの主要なタスクが、ＭＳＳとＭＧＷとの間の適切なＳＣＴＰレイヤを生成するのに実行される必要がある。これらは、ＭＳＳ及びＭＧＷにおける同様のパラメータ値によるＨ．２４８及びＭ３ＵＡのＳＣＴＰパラメータセットの生成と、ＭＳＳ及びＭＧＷにおけるシグナリングユニットのＳＣＴＰマルチホーミングの生成とである。マルチホーミングは、全てのＳＣＴＰ関連付けに利用される。ホストは、複数のＩＰアドレスによってアドレス指定可能であるときマルチホーミングされる。ＳＣＴＰは、一方がプライマリとして機能し、他方がセカンダリパスとして機能するように双方のインタフェースを利用できる。通常、シグナリングトラフィックはプライマリパスを介し移動し、故障が発生した場合、ＳＣＴＰは、セカンダリパスを介し送達確認されていないメッセージの再送を開始する。これは、パスの１つが故障した場合、メッセージが消失しないことを保証する。
【００４９】
以下のための相互接続戦略は以下の通りである。
【００５０】
ＩＰ相互接続を介し接続されるＭＮＯについて、ＩＰ相互接続は、ＣＮＯとパートナのネットワークとの間のＩＰ“ＳＩＧＴＲＡＮ”リンクを介しＳＳ７に生成されるモビリティＳＣＣＰルーティングトラフィックによって、ＳＩＰにより制御プレーンのためにＭＳＳに接続され、ＲＴＰによりユーザプレーンのためＭＧＷに接続される。
【００５１】
ＴＤＭ相互接続を介し接続されるＭＮＯについて、ＴＤＭ相互接続はＩＳＵＰシグナリングを利用してＭＳＳ制御プレーンに接続される。ＳＴＭ−１を介したＥ１接続は、ユーザプレーン機能のためＭＧＷに確立される。ＴＤＭ相互接続は、シグナリングゲートウェイとして機能するＭＧＷを介したＭＳＳとのシグナリング接続を有する。Ｇｌｏｂａｌ  Ｔｉｔｌｅに基づくモビリティＳＣＣＰルーティングが、相互接続パートナのネットワークに対して生成される。ＳＣＣＰルーティングは、ＣＮＯ加入者がロケーションアップデートを実行する相互接続パートナのネットワークのＭＳＳに対するＣＮＯ  ＨＬＲからのロケーションアップデートレスポンスについて必要とされる。ＭＧＷにおけるシグナリングは、ＳＩＧＴＲＡＮを介しＭＳＳにより制御される。それは、ＭＧＷにおいて設定されるインタフェース・シグナリング・ユニット（ＩＳＵ）を介し提供される。ＴＤＭ相互接続は、シグナリングゲートウェイとしてＭＧＷを利用するＭＳＳとのシグナリング接続を有する。
【００５２】
ＭＳＳとＭＧＷとの間のシグナリングインタフェースはＭｃインタフェースである。それは、Ｈ．２４８及びＳＩＧＴＲＡＮなどの２つの主要なシグナリング機能を有する。Ｔｒｕｐｈｏｎｅでは、Ｍｃインタフェースは、双方のＭＳＳがコアバックボーンを介し接続される６つ全てのＭＧＷとのＨ．２４８及びＳＩＧＴＲＡＮインタフェースを有するように設計される。Ｈ．２４８は、ＭＳＳとＭＧＷとの間の“マルチホーミング”接続を提供するＳｔｒｅａｍ  Ｃｏｎｔｒｏｌ  Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｐｒｏｔｏｃｏｌ（ＳＣＴＰ）を介し搬送される。この“マルチホーミング”は、接続の各エンドの２つのＩＰサブネットにおける２つのＩＰアドレスの利用を介し２つの離散的なパスを提供する。ＳＩＧＴＲＡＮ関連付けは、ＴＤＭ相互接続のためにＮＡ０、ＮＡ１及びＩＮ０についてＭＳＳとＭＧＷとの間で生成される。ＭＳＳがサーバとして機能し、ＭＧＷがクライアントとして機能することによって、全てのＩＰシグナリングリンクセットについて２つのＳＣＴＰ関連付けがある。
【００５３】
Ｎｃインタフェースは、ＭＳＳ要素の間のインタフェースである。それは、ＳＩＰ−Ｉ及びＢＩＣＣ上で動作し、制御部分に基づく。このインタフェースにはユーザプレーンは関与しない。ネットワーク・ツー・ネットワークベースの呼制御シグナリングが、ＭＳＳの間のＮｃインタフェースを介し実行される。ＮＳＮ  ＭＳＳにおいて利用可能なＩＰベースネットワークにおける他の呼制御プロトコルは、カプセル化されたＩＳＵＰ（ＳＩＰ−Ｉ）によるＳｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌである。それは、ＢＩＣＣに提供されるものと同様のトランク状のシグナリング能力を提供する。ＭＳＳにおいて、ＳＩＰ−Ｉは、ＩＳＵＰメッセージのためのトンネリング方法として利用される。
【００５４】
ＭＧＷの間のユーザプレーンインタフェースは、Ｎｂインタフェースである。地域データセンタにおける全てのＭＧＷは、ユーザプレーンデータ転送用に利用されるＲＴＰによりコアバックボーンを介しＩＰインタフェース上で接続される。Ｎｂインタフェースは、ＭＧＷの間のユーザプレーン情報のみに関連し、それに付属された制御部分を有さない。
【００５５】
ＳＳ７ネットワークには、完全なＭＴＰ２及びＭＴＰ３シグナリング手段を与えるため、シグナリングゲートウェイ機能及び階層的で中央化されたルーティングの実現を担当するノードであるＩＰ転送ポイントが備えられる。ＳＴＰは、フェイルオーバを保証するため、ネットワーク要素までデュアルサイトフルメッシュコンフィギュレーションによる完全に冗長な手段を有する。ＳＩＧＴＲＡＮのために利用されるネットワークプレーンは、各ＭＳＳとＮＡ０における全てのＳＴＰとの間をリンクさせる。
【００５６】
ＭＳＳとＳＴＰペアの間のＳＩＧＴＲＡＮリンクは、ＳＴＰエンドにおけるシグナリングユニットとＭＳＳにおけるシグナリングユニットとの間のＳＣＴＰ関連付けに基づく。ＳＴＰペア内のＳＴＰと各ＭＳＳとの間には２つのＳＣＴＰ関連付けがある。ＭＳＳのＭ３ＵＡの役割はクライアントであり、ＳＴＰの役割はサーバである。
【００５７】
ＭＳＳは、グローバルデータセンタに配置されたＳＴＰペアに接続される。ＭＳＳとＳＴＰとの間のシグナリングは、ＣＮＯ  ＩＰネットワークを利用するＳＩＧＴＲＡＮに基づく。ＭＳＳは、サービスプラットフォーム要素との直接的な物理的シグナリングを有さない。ＭＳＳからＳＴＰペアへのＳＩＧＴＲＡＮインタフェースは、ＭＳＳノードがサービスプラットフォーム要素と通信するために主として利用される。ＭＳＳとＳＴＰとの間のシグナリングルートは、それらの間のシグナリングインタフェースのレイヤ３機能である。ＭＳＳとＳＴＰとの間のシグナリングルートは、ＭＳＳとサービスプラットフォーム要素との間のシグナリングルートのためのベースラインを維持してもよい。ＭＳＳとＳＴＰとの間のシグナリングルートのコンフィギュレーションは、何れかの内部ネットワーク要素のシグナリングルートコンフィギュレーションと同様のものであってもよい。
【００５８】
課金センチネルはＳＣＰ機能を実現するためのプラットフォームであり、本実施例では、それはＯｐｅｎｃｌｏｕｄ  Ｒｈｉｎｏ  Ｔｅｌｅｃｏｍ  Ａｐｐｌｉｃａｔｉｏｎ  Ｓｅｒｖｅｒ（ＴＡＳ）に基づき、ＩＮ−ＳＣＰ機能を実現するのに利用される。ＣＳは、インテリジェント呼ルーティング機能と共に、Ｓｍａｒｔ  Ｄｉａｌｌｉｎｇ  ａｎｄ  Ｓｍａｒｔ  ＣＬＩサービスなどのＣＮＯサービスを実現するのに利用される。コアネットワークとのインタフェースは３ＧＰＰ  ＣＡＰであり、ＯＣＳは直径及びＨＴＴＰを利用する。加入者プロファイルは、ＯＣＳデータベースに格納され、呼設定中に必要に応じて抽出される。
【００５９】
Ｒｈｉｎｏ  ＴＡＳは、ＵＳＳＤコールバック機能をサポートするのに利用されるコアネットワークとのＳＩＰ／ＩＣＳインタフェースを有する。ＣＮＯにより配備されるフェイルオーバ戦略は、単一の故障ポイントのないフルメッシュサイト間コンフィギュレーションによりＭＳＳのための用いられるものと同様である。一例となる構成では、ＣＮＯは、ターミネーション及びＴＳＡＮｎｅｄ音声呼のためのｔａ  ＣＡＰ２プロトコルと、ＵＳＳＤコールバックサービス呼設定のためＳＩＰ／ＩＳＣとを利用している。
【００６０】
外部パートナのＩＶＲは、ＳＩＰを用いてＭＳＳに直接接続され、同時にＲＴＰを用いてＭＧＷに直接接続される。
【００６１】
ＭＳＳは、ＳＴＰを介しグローバルデータセンタにおいてＨＬＲに接続される。各ノードは、ネットワークＳＴＰのペアに対するＳＩＧＴＲＡＮ関連付けを有する。各ＨＬＲは、正しいルーティングを保証するため、シグナリングポイントコード及びグローバルタイトルを有する。ＨＬＲはＳＩＧＴＲＡＮシグナリングスタックを有し、各ＨＬＲはネットワークにおいてＳＴＰペアに物理的に接続される。ＣＮＯ  ＭＳＳは、ＳＴＰを介しＨＬＲに対してシグナリングをルーティングする。フルメッシュ接続を保証するため、ＳＴＰは、ＨＬＲに送信されるメッセージのロードシェアとして機能する。サイト間メッシュリンクは、特定のサイトにおいて停止状態が発生したか確認し、第２のものに対してシグナリングをリルートし、サービスの生存を維持することができる。
【００６２】
ＳＭＳＣ（ＳＭＳセンタ）は、ＳＴＰペアを介しＭＳＳに接続される。ＭＳＳとＳＭＳＣとの間で利用されるシグナリングルーティングは、ポイントコードとサブシステムナンバーとに基づくＳＣＣＰルーティングである。フルメッシュ接続がフェイルオーバのため再び提供されてもよい。
【００６３】
ＭＳＳからＭＦＳへのシグナリングは、ＩＴＰを介して提供される。マルチファンクションサービス（ＭＦＳ）は、ＭＡＰ  ＳＲＩ  Ｇａｔｅｗａｙ、ＭＡＰ  ＰＲＮ  Ｆｉｘ及びＭＮＰ（Ｍｏｂｉｌｅ  Ｎｕｍｂｅｒ  Ｐｏｒｔａｂｉｌｉｔｙ）ＤＩＰＳの３つのサービスを担当するネットワーク要素である。ＣＮＯモバイルナンバーポータビリティは、各グローバルデータセンタにおいて提供されてもよい。
【００６４】
異なるデフォルトシグナリングキャリアが異なる地理的エリアにおいて提供されてもよい。ＳＩＧＴＲＡＮは、相互接続のためのシグナリングプロトコルとして利用されてもよい。復元力を増加させるため、ＣＮＯは、プライベートＩＰピアリングに対するフルメッシュＳＳ７リンクを有してもよい。これらのリンクは、ＳＣＴＰを介しＭ２ＰＡにより生成されてもよく、ルーティング方法は、発信側及び着信側の双方においてＧＴとなる。シグナリングキャリアは、ＣＮＯ  ＩＴＰへの／からの関連するＡＮＳＩからＩＴＵ及びＩＴＵからＡＮＳＩへの変換を担当可能である。
【００６５】
このようなアーキテクチャにわたって提供されるサービスの具体例は、モバイルナンバーポータビリティ（ＭＮＰ）である。ネットワークオペレータの間のモバイルナンバーポータビリティが知られているが、異なる国は異なる規制アプローチと異なる処理フローとを有する。本アーキテクチャは、共通のコアプロセス及び地域適応化による構造化されたレイヤアプローチに適している。これは、高いフレキシビリティと効果的なコード再利用とを可能にする。後述されるように、この基本モデルは、国に特有の特定の要素を除く、全ての地域に共通するコア要素を有する他のサービスに適用可能である。
【００６６】
図１９は、可能である場合、共通の処理を適用しながら、ＭＮＰ処理を隔離することを可能にするマルチレイヤサービスアーキテクチャを示す。ローカルな地域に固有の複雑な統合問題は、これらの地域に隔離できる（及び、例えば、中央ノードでなく関連する地域又はローカルノードにおいて実行される）。
【００６７】
第１レイヤ（ファサードレイヤ）は、ＭＮＰ機能を他のシステム及びプロセスに明示するサービス板又はＡＰＩである。当該レイヤは、“ＭＮＰシステム”内においてＭＮＰ機能及び複雑さを隔離する。さらに、これは、他のシステムがＭＮＰをシンプルかつ一貫して扱うことを可能にすることを保証し、所与の国について何れのアプローチが必要とされうるかにかかわらず、全てのＭＮＰ処理を処理するシステムが存在することを理解することしか必要としない。ＭＮＰシステムは、何れの外部システム又はプロセスがそれのサービスを利用可能であるかの知識を有する必要はなく、リクエストが許可されて明確に構成される限り、ＭＮＰシステムはそれの処理を試みる。ＭＮＰシステムの隔離を実現することによって、システムがＭＮＰサービス及び機能を利用する何れかのシステム群にわたって再利用可能であることが保証される。
【００６８】
第２レイヤ（一般化レイヤ）は、共通の又は一般化された機能、すなわち、全てのＭＮＰアプローチに共通する機能を含む。複雑さ及びメンテナンスオーバヘッドを低減するため、この共通の機能は１回のみ実現されるべきである。この実現は“中央的”とみなされるべきである。このレイヤは、ファサードレイヤ（実際、それは当該レイヤを実現してもよい）及び後述される実現化レイヤとやりとりする。一般化レイヤは、単一の統合構成を介し実現化レイヤと統合する。一般化レイヤはある意味において全ての機能を処理し、ここで、特定のエリアの機能はアプローチに固有又は国に固有の処理により変化する一方、本レイヤにおいて提示される機能は、以降のレイヤにおいて実現される機能のための単なるラッパであり、標準的な情報セットが当該機能を表すのに利用されるが、それは処理のため他のレイヤにわたされる。例えば、全体的な状態管理（例えば、ポートを実行する処理において、特定のリクエストなど）は、ＭＮＰに対する全てのアプローチに共通する（状態値自体は異なりうるが）。従って、それは一般化レイヤにおいて処理される。
【００６９】
第３レイヤ（実現化レイヤ）は、ＭＮＰに対する少数の一般化されたアプローチに固有の機能を含む。各一般化されたアプローチは、当該アプローチに固有の機能を実現する自らの“コンポーネント”を有する。実現化レイヤは、単一のインタフェース構造を介し一般化レイヤと統合する。実現化レイヤにおける各アプローチに固有のコンポーネントは、当該コンポーネントに固有のインタフェース構造によりコネクションレイヤ（後述される）に統合される。実現化レイヤ内のコンポーネントは、コンポーネントに関連する汎用的アプローチを利用する何れか所与の国がどのように当該アプローチを実現するかの詳細を理解していない。いくつかのアプローチについて、一般化及びコネクションレイヤにおけるものに加えて、何れかの固有の処理又は機能も実現される必要がないことが可能である。例えば、英国は、承認コードがネットワークオペレータ間でわたされる“オーソリティ・コード・アプローチ”を利用してＭＮＰを実現する。この“コードアプローチ”はまた、少数の世界中の他の国において利用されている。ＭＮＰ処理に“オーソリティ・コード・アプローチ”を実現するのに必要とされる機能及び処理を提供するコンポーネントが実現化レイヤに存在する。当該コンポーネントは、国が“コードアプローチ”スタイルＭＮＰを実現する何れの場合においても利用される。
【００７０】
第４レイヤ（コネクションレイヤ）は、ＭＮＰ処理が実行される必要がある国に固有の機能を含む。これは、当該国について必要とされるデータ形式において当該国において必要とされる何れの外部サービス及び／又はプロセスに対する統合を含む。コネクションレイヤは、当該国が実現するＭＮＰアプローチに固有のインタフェースを介し一般化レイヤに統合される。コネクションレイヤ内のコンポーネントは、サービスが提供される国に完全に固有のものである。例えば、英国に固有のインタフェース処理及び情報コンテンツは、ＵＫサービスコールアウトにより管理される。このＵＫサービスコールアウトは、“オーソリティ・コード・アプローチ”コンポーネントにおり利用され（ＵＫは“オーソリティ・コード・アプローチ”スタイルＭＮＰを実現しているため）、クリアリングハウス（ＵＫ  ＭＮＰ処理のための中央通信ポイント）との統合を実現する。
【００７１】
このアプローチが、特定のメッセージモデル及び処理フローを参照してより詳細に説明される。
【００７２】
図２０において、階層的メッセージモデルが示される。このメッセージモデル（ＭＮＰフレームワーク）は、カノニカルメッセージモデルの階層ツリーを定義する。これは、国に固有のサービスプロバイダにメッセージを動的に発送する多形的アプローチを以下のように提供する。
【００７３】
ベースタイプ（１０１）がファサードレイヤにおいて定義される。これは、ファサードレイヤをサポートするためのタイプの抽象及びクリーンレイヤを定義する。コアメッセージモデル（１０２）はベースタイプから遺伝する。一般化レイヤにおいて定義されるインタフェースは、このタイプを利用する。コアメッセージモデルは、一般化レイヤにおいて利用されるドメインモデルの知識（１０３）を提供する。
【００７４】
実現化レイヤにおける各固有のビジネスドメインの知識（１０４）は、一般化において定義される知識を継承する。当該継承は知識転送パス（１０５）を提供し、これにより、ドメイン知識の懸念の分離をサポートすると共に、共通の懸念の重複を回避する。実現化レイヤにおける固有のビジネスドメインは知識領域の多形化にあり、実現化レイヤにおけるこれらのビジネスドメインは、互いに緩やかに結合し、独立して処理されてもよいが（ポートオーソリティコードドメイン−ＰＡＣドメイン−が１つの具体例として示される）、それらは全て一般化レイヤからの知識を継承する。実現化レイヤには複数レベルの継承があってもよい。
【００７５】
国に固有のドメイン（１１０）はコネクションレイヤにあり、実現化レイヤからのビジネスドメインからの知識を継承する。国に固有のドメインにおける知識は、適切なカノニカル形式による。実際のカントリＭＮＯデータ形式とカノニカルカントリ形式との間の変換を提供する本コネクションレイヤにおけるインタフェース設定がある。従って、専用の知識は外部の世界から遮断及び切断されてもよい。
【００７６】
図２１において、一般化されたＭＮＰ処理フローが示される。ファサードインタフェースは、マルチチャネルクライアントからのＭＮＰリクエストをサポートするためのクリーン及び統一インタフェース（２０１）を提供する。インターネットアクセスは、ウェブブラウザ（２０２）を介してもよく、リッチクライアントはデスクトップアプリケーション（２０３）を利用し、モバイルアクセスはモバイル装置（２０４）又はチャネルパートナ（２０５）を介してもよい。ファサードレイヤは、一般化レイヤにおけるジェネラル・ゲートウェイについて定義される対応するインタフェースにリクエストメッセージを配信（２０６）する。ジェネラル・ゲートウェイは、異なるフォーマットによるメッセージペイロードの階層ツリーを受け付けるための汎用インタフェースを定義する。ファサードレイヤにおけるジェネラル・ゲートウェイインタフェースの利用は、ファサードクライアントに対する内部変更の影響を最小限にする。これは、以下の２つの具体例、すなわち、１）既存のカントリＭＮＯのインタフェース又は処理フローの変更がファサードレイヤのクライアントの起動に影響を与えず、２）新たなカントリＭＮＯの追加が既存のクライアントコードに影響を与えず、追加的なリクエストを送信するための新たな能力をクライアントに与える、において示すことができる。
【００７７】
ＭＮＰ一般化サービス（２０９）は、実現化知識［２１０］を利用してジェネラル・ゲートウェイ［２０８］を介し送信されるリクエストを処理する。実現化知識は、ビジネスドメインの次のレイヤを知っており（しかしながら、実現詳細でない）、従って、次の実現化ドメインにリクエストを動的に送る。実現化レイヤは、実現化ドメインの間の実現化フローの１〜ｎのステップを含む。各実現化レイヤは、特定のビジネスドメインを有し、それらのそれぞれはドメインモデルを有し、ドメインロジックを実行するため対応するビジネスプロセスを提供する自らのドメイン知識を有する。上述されたように、ドメインの具体例はＰＡＣ（Ｐｏｒｔ  Ａｕｔｈｏｒｉｔｙ  Ｃｏｄｅ）ドメインである。実現化レイヤにおける各ドメインは、それの実現化知識を有し、それを利用してフローを次のステップに動的に送ることができ、コネクションレイヤにおけるコネクタ又は他のレベルの特定のドメインの何れかである。
【００７８】
コネクションレイヤは、複数のコネクタを有し、それらのそれぞれは特定のカントリＭＮＯに接続するための実現詳細を提供する。当該コネクションは双方向であってもよい。特定のドメインからコネクタへのフローもまた、ドメイン固有の処理フローに応じて双方向とすることができる。各コネクタは、実際のカントリＭＮＯデータモデルに／から専用のカントリカノニカルデータモデルを変換する変換を含む。従って、内部の専用の知識は外部の世界から遮断及び切断される。各コネクタは、コネクション実現詳細を処理するためのアダプタを有する。水平方向において継承／拡張関係があり、従って、水平方向は共通からより具体的なものまでの機能を提供する。水平方向は、カントリ固有ＭＮＰ機能を端から端まで実現するため、機能フロー全体を提供する。実現化ドメインは互いに垂直方向に切断され、フレームワーク全体への影響を最小限にすることによってプラグ着脱可能である。ドメインは、垂直方向に多形性を有する。カントリコネクタは、上位のレイヤに対して最小限の影響によりフレキシブルにプラグ着脱可能である。カントリＭＮＯへのコネクションレイヤにおけるコネクタと実現化レイヤにおけるドメイン間の接続は双方向とすることができる。
【００７９】
図２２は、当該アプローチが継承及び再利用をどのように実現するかを示す。４レイヤに基づくフレームワークは、ほとんど知識依存性なく大きな再利用性を提供し、これにより、何れかのカントリ固有のＭＮＯナンバーポータビリティの実現又は修正は、当該フレームワークの消費者への最小限の影響により最もフレキシブルな方法によりプラグ又は非プラグ可能である。
【００８０】
当該フレームワークの水平方向は、サービス継承及び拡張を提供する。水平方向のサービス契約のためのカノニカルメッセージモデルの階層ツリーが定義できる。クリーンでシンプルな汎用インタフェースが、メッセージデータフローが動的に送られ、水平方向に拡充されることを可能にするファサードレイヤについて定義された。サービスビジネスロジカルは、メッセージフローを処理するため継続されて水平方向に拡張される。典型的な具体例は、ＵＫ  ＭＮＯについてオーソリティ・コード・アプローチを実現するための水平方向サービスフローである。ＭＮＰリクエストが動的に送られ、オーソリティ・コード・アプローチロジックを実現するＭＮＰ  ＰＡＣ（Ｐｏｒｔ  Ａｕｔｈｏｒｉｔｙ  Ｃｏｄｅ）ドメインにおいて流れ、その後、カノニカルモデルをＵＫ  ＭＮＯデータモデルに変換し、ＵＫ  ＭＮＯにＨＴＴＰポストアウトを実行するために低レベルトランスポート詳細を処理するＵＫサービスコネクタにわたされる。その後、インドなどの他のオーソリティ・コード・アプローチベースのカントリＭＮＯを実現するため、変換及びトランスポートの詳細を処理するためにカントリ固有コネクタにプラグインすることしか必要でない。ＵＫコネクタの更新及び修正は、インドのＭＮＯコネクタに対する影響を有さず、またその反対の影響もない。これは水平方向の多形性を提供する。
【００８１】
垂直方向では、フレームワークは共通のクラスコンポーネントの最大限の再利用をサポートする。実現化ドメイン間又はカントリサービスコネクタ間の共通の機能は、テンプレートとして抽象化できる。オブジェクト指向テンプレート設計アプローチが利用されてもよい。垂直的に利用されるテンプレートは、共通の機能のためのＣａｐａｂｉｌｉｔｙ  ｏｆ  Ｇｅｎｅｒａｌ  Ｒｅｓｐｏｎｓｉｂｉｌｉｔｙ  Ａｓｓｉｇｎｍｅｎｔを提供するものであってもよい。典型例は、ＵＫコネクタのために実現されたセッション・マネージメントである。各接続におけるオープン／クローズの代わりに、ＨＴＴＰセキュリティセッションが、専用システムと外部システムとの間のシステム統合パフォーマンスを向上させるため、複数のＨＴＴＰ  Ｐｏｓｔについてキャッシュ及び維持される。セッションマネージメントのテンプレート設計は、例えば、ＳＯＡＰ／ＨＴＴＰ、ｐｌａｉｎ  ＨＴＴＰ又はＲＳＴなどの下位のＨＴＴＰプロトコルを利用する全てのカントリＭＮＯコネクタに対する垂直的な透過性を提供する。
【００８２】
同じ汎用アプローチを利用する他のサービスモデルは、ディレクトリ及びナンバーサービスに対するものである。リクエストされたナンバー（ＭＳＩＳＤＮ）はディレクトリ及びナンバーサービスに対する異なるアプローチを有する複数の国からのものであるアドレスに対する同様のチャレンジがある。これは、要求元のエンティティがディレクトリ及びナンバーサービスに対する各国の規制アプローチの詳細を意識しないことを可能にする。上述されたアプローチは、要求元のエンティティがディレクトリ及びナンバーサービスに対する各国の規制アプローチの詳細を意識しないことを可能にする。
【００８３】
各国は、ＭＳＩＳＤＮがどのようにサーチされるべきかについて当該国におけるルールと、ディレクトリサービスにそれらのナンバーを提示又は非提示する、又は請求及び他の出力にそれらのナンバーを完全又は部分的に隠す個人の管理に関するローカルな法律とを有するディレクトリ及びナンバーサービスのための自らの規制アプローチを有する。ＭＮＰに関して、各国わたるディレクトリ及びナンバーサービスの一般化された範囲は多くは共通する一方、具体的な実現は各国について変わる。
【００８４】
例えば、
・オランダでは、消費者は、他の消費者の請求又は他の記録に表れる自分のＭＳＩＳＤＮを隠すことを要求してもよい。このマスキングは、このような出力にＭＳＩＳＤＮの最後の３桁をハッシュアウトする形態をとる。
・ドイツでは、特定のＭＳＩＳＤＮは、請求又は他の出力に表示されることが禁止されている。
・オーストラリアでは、消費者は、自らのナンバーがディレクトリサービス組織に利用可能になることを（デフォルトで）選択又は非選択してもよい。
・ポーランドでは、規制当局は、アクティブ化されるとすぐに販売されたＭＳＩＳＤＮが通知されなければならない。
【００８５】
このようなバリエーションは、ＭＮＰについて上述されたような同一のアーキテクチャアプローチを利用することによって、複雑な中央処理なく処理可能である。サービスロジックは明らかに異なるが、同じ原理を実現する。規制当局及び／又はディレクトリサービスオペレータとの物理的なやりとりは、各国によりそれが変わることを可能にするため、論理処理から離れて抽象化される。共通の機能は、各具体的な実現のニーズに従ってそれの実現形態において可変であるドメインにグループ化され、これらの実現化は、実現化の具体的な複雑さに依存したｎディープ構造を有することが可能である。例えば、
・規制当局に対する実際の統合が国に固有であったとしても、ディレクトリサービスの選択／非選択ロジックは多くは共通してもよく、
・ナンバー遮断アプローチは、各国にわたって大きく変わるが、３又は４つの一般化されたアプローチに属する（例えば、特別なナンバーの遮断、他人の出力への自分のナンバーの遮断、消費者自体の出力へのナンバーの遮断など）
このアーキテクチャモデルによりスケーラブルに管理可能な他の問題は、ナンバーの分類である。ナンバーは関連するデータ及びメタデータを有する。データは、具体的なナンバーに関する情報を我々に言う。メタデータは、データ自体に関する情報を我々に与え、我々が多くのことを実行することを可能にし、例えば、セールが行われるとき、我々はメタデータを利用して、購入希望のナンバーの種類に関する関連する質問を尋ねるため、ＵＩを動的に構築することが可能である。ナンバーのクラスに関する階層的メタデータを定義するためのシステムが以下で説明される。
【００８６】
グローバルモバイルネットワークのオペレータのためのナンバーマネージメントを構築するためのチャレンジは、ナンバーに関する必ずしも全てのデータアイテムが全てのケースにおいて関連しているとは限らず、関連性は経時的に変化する可能性があり、新たなアイテムが新たな国への拡張によって必要とされうる。図２３において、メタデータによるナンバーの従来のタビュラー分類が示される。これは、新たなフィールドが必要とされる場合、困難を生じさせる。
【００８７】
図２４において、テーブルよりスキーマを利用したより良いモデルが示される。ここで、スキーマを変更することなく新たなデータアイテムを追加することが可能である。新たなアイテムを追加するため、
・“国”などの新たな行をカテゴリテーブルに追加し、
・“アフガニスタン”、“アルバニア”、“アルジェリア”などのそれの全ての可能性のある値をカテゴリ値テーブルに追加し、
・“国＝アルジェリア”及び“利用＝プライマリ”などの具体的なナンバーと１以上のカテゴリ値とを関連付けるためのリンクエントリをナンバーカテゴリテーブルに追加する。
【００８８】
このモデルにない更なるルールはメタデータとして表現されてもよい。具体例は以下である。
・ナンバーがＵＳナンバーである場合、州がまた供給される必要がある。
・ナンバーがＵＳである場合、利用カテゴリが定義される必要がある。
・ナンバーがアルジェリアのナンバーである場合、特別なカテゴリが供給される必要がある。
・将来的に、“アルバニア”及び“バージニア”ナンバーのみに適用するように、利用カテゴリを変更してもよい。
【００８９】
これは、依存性テーブルを追加することによって処理されてもよい。これは、これらのルールを保持するため、相互依存するカテゴリ値レコードの階層を定義する。一例となる構成は以下である。
【００９０】
【表１】
2019216447.tif 000002
３つのシナリオにおいて依存性テーブルを解釈する必要があり得る。
・新たなナンバーをシステムにロードするとき、各ナンバーはこれに従って分類される必要がある。
・ナンバーを購入するとき、興味のあるナンバーの種類に関する質問が尋ねられる必要がある（これは動的な販売ＵＩ）。
・分類ルールが変更される場合、何れについて更なる情報を提供する必要があるか確認するため、全てのナンバーを再分析する必要がある。
【００９１】
ナンバー又はナンバーの範囲がカテゴリ化されるとき、依存性テーブルが解釈される。当該テーブルにおける第１行のみが“依存”値を含まない。これは、第１行が全てのナンバーに適用可能であることを意味する。このレコードはまた、全てのナンバーがそれらが属する国を定義する必要があることを意味する国カテゴリを参照する。購入するナンバーのタイプを選択するためＵＩを動的に構築する場合、これは、関連する全てのカテゴリ値を表示する単一のリストボックスを生成する（すなわち、世界の全ての国）。１つが選択される必要がある。選択がなされると、依存性テーブルは、なされた判定に基づき再び分析される。ＵＳがリストボックスから選択される場合、依存性テーブルからの行１及び４が、カテゴリ値２５０に“依存”するため（国＝“ＵＳ”）、成立する。行１は、５２個のＵＳ州カテゴリのリストボックスが表示される必要があることを示す。行４は、同様に、“プライマリ”又は“セカンダリ”の利用を選択可能なリストボックスが表示される。州について“カリフォルニア”を選択した場合、特別なカテゴリの金、銀又は標準の追加的な分類が必要とされる。特別なカテゴリはまた“アルジェリア”のナンバーに適用されることが観察できる（依存性テーブル行２）。これは図２５に示される。
【００９２】
このシステムは、極めてフレキシブルである。例えば、全てのＵＳの州でなく一部のＵＳの州に利用カテゴリを適用するため、依存性テーブル行を置換することは些細であることが理解できる。示されるロジックは、典型的には、再利用可能なソフトウェアコンポーネントにカプセル化され、様々な利用ケースについて埋め込まれる。また、例えば、ニューヨークのナンバーが利用可能でないとき、“ニューヨーク”カテゴリ値の参照を削除するなどによって、ナンバープールにおける変更に応答して、依存性テーブルを動的に更新できる。
【００９３】
上述されるように、このアーキテクチャアプローチ及びサービスを提供するためのアプローチは極めて強力である。それは、時間及びボリュームにクリティカルな要素を地域ノードに分散しながら、１以上の中央ノードにおける共通の要素を実現することによって、マルチカントリネットワークオペレータのモバイルネットワークの構成を可能にする。これは、汎用要素を機能の中央コアに抽象化し、地域のバリエーションを処理するためフレームワークアダプタを実現することによって、複数の地域の顧客にモバイルサービスを提供するための通信スタックを設定することをサポートする。地域バリエーションが地域ノードにおいて実現される必要がある場合、必要な機能は当該ノードに分散させることができる。一部の地域ノードはまた、中央ノードのコピーを提供し、冗長性を提供するため参加することができる。
【００９４】
このアプローチは、加入者のローカル化を維持しながら、従来の地理的制約を回避するのに利用されてもよい。例えば、元のＩＰパケット変換が提供され、パケットトラフィックがアムステルダムからルーティングされているとき、顧客はある地域、すなわち、ドイツにローカルであるようである。ＡＰＮ操作は、ＳＧＳＮにより提供されるＭＮＣ／ＭＣＣの組み合わせ及び加入者のＩＭＳＩの比較に基づきまず行われる。
【００９５】
マッピングは、“国内”ＩＰアドレスに対してＩＰバックボーンにより行われてもよい。加入者が自らの好適なカントリ経験を維持するため、顧客の嗜好が位置情報を無効にするのに利用可能である。
【００９６】
上述されるように、ローカライズされたＡＰＮが、パケットトラフィックが最も近いＧＧＳＮ又はパケットゲートウェイに最も効率的にルーティングするため提供されてもよい。これは、ルーティングの最適化をサポートする。例えば、ネットワーク及びユーザ装置は、音声又はデータサービスのより良いルーティングを実行し、ユーザ装置が高速なアタッチメントを可能にするよう接続嗜好を設定するよう動的に設定されてもよい。同様に、シグナリングが課金及び呼制御を可能にするよう中央でマッチングされるように、所与の顧客の音声及びデータのルーティングは、取引のデスティネーションのソースデスティネーション位置及び部分的に分散化されたモバイル通信ネットワークにおける利用可能なルーティングリソースに基づく。好適な送信パスへの通信のルーティング動作の修正は、元のデスティネーションベアラ及び位置における技術（Ｗｉ−Ｆｉ／ＧＳＮ／ＬＴＥ）に基づくものであってもよい。効率的なルーティングはまた、サードパーティネットワークを介したメディア及びＳＭＳのトロンボーンを必要とすることなく、分散ネットワークにおけるＳＭＳ及び音声呼の転送を可能にするよう選択されてもよい。
【００９７】
全てのサービスがソース位置及びデスティネーションナンバー及び／又は位置により変更された全てのナンバーについて利用可能になるように、サービスにインテリジェントにマッピングされる複数の国又は１つの国からの複数のモバイルナンバーが提供されてもよい。
【００９８】
共通のサービスは、異なる国際的な識別子にわたって提供されてもよい。例えば、単一の請求、顧客サービス及び音声メールは、加入者が複数の国際識別子を有するにもかかわらず、加入者に提供されてもよい。同様に、合法的な傍受及びエマージェンシサービスが、複数の国際識別子にわたって提供されてもよい。ＷＯ２０１１／０３６４８４と同様に複数の識別子を加入者に提供するシステムによる当該アプローチを利用する特定の効果は、共通のサービスの提供のためこれらの加入者識別子を調整ことはより容易であるということである。ローミング時でさえ国内フォーマットによるホームカントリデスティネーションに顧客がダイアルすることを可能にするようユーザ体感が選択可能であり、例えば、発信元の回線識別情報及び制限が、法律により許可されている程度まで複数の地域にわたって加入者に一貫して提供されてもよい。
【００９９】
このモデルは、ネットワークマネージメントのための更なる意義を有する。例えば、アクティブなネットワークプローブが、１つの論理ノードとして動作するため、ネットワーク全体に分散化されてもよく、プローブシステムが全体として品質保証されることを可能にする。各ネットワークプローブは自らの識別子を有し、それに従って通信してもよいが、ハイレベルでは、単一の論理ノードとして他の要素及びサービスとやりとりする。
【０１００】
上述されたように、中央的に実現される汎用モデル及び地域的に実現される地域バリエーションによる階層的サービスの記述を用いたサービスモデルが利用されてもよい。モバイルナンバーポータビリティについて、これは、これらの国の異なるポーティングナンバーの存在にもかかわらず、複数の国においてポーティングナンバーを同時に伴うものであってもよい。これは、最小数の要素しかプロトコルの各レイヤにおいて適応化される必要がないように、標準化されたフレームワークを用いてＭＮＰの複数の国際モデルの統合を可能にする。ディレクトリ及びナンバーサービスについて、これは、ディレクトリサービス（ＵＫ１１８，ＵＳ５５５など）及び有料サービスなどの通常知られるナンバーが、自宅、位置及び以前の履歴に基づくルールに従って各国のローカルなナンバリング方式又はホームナンバーシステムに解決されるように、マルチカントリナンバー及びショートコードマッピングサービスを提供することに関するものであってもよい。ナンバリング法則は、ナンバーがローカルな実務に従って各ローカル管轄において正しく示されるように、多国的にマッピングされてもよい。
【０１０１】
このアプローチはまた、複数の地域にわたって好適なナンバーを確保することによってナンバーマネージメントをサポートする。これは、例えば、顧客が１つの国であるナンバーを購入すると、複数の国において同様のナンバーを確保することに関するものであってもよい。
【０１０２】
他の国から独立したサービスのパッケージングが、このモデルを利用して可能である。例えば、任意的に異なる通過により法的に契約及び課金されながら、個人グループが地理的境界にわたって時間の共通のプールを共有することを可能にすることができる。
【図１】
2019216447.tif 000003
【図２】
2019216447.tif 000004
【図３】
2019216447.tif 000005
【図４】
2019216447.tif 000006
【図５】
2019216447.tif 000007
【図６】
2019216447.tif 000008
【図７】
2019216447.tif 000009
【図８】
2019216447.tif 000010
【図９】
2019216447.tif 000011
【図１０】
2019216447.tif 000012
【図１１】
2019216447.tif 000013
【図１２】
2019216447.tif 000014
【図１３】
2019216447.tif 000015
【図１４】
2019216447.tif 000016
【図１５】
2019216447.tif 000017
【図１６】
2019216447.tif 000018
【図１７】
2019216447.tif 000019
【図１８】
2019216447.tif 000020
【図１９】
2019216447.tif 000021
【図２０】
2019216447.tif 000022
【図２１】
2019216447.tif 000023
【図２２】
2019216447.tif 000024
【図２３】
2019216447.tif 000025
【図２４】
2019216447.tif 000026
【図２５】
2019216447.tif 000027
【図２６】
2019216447.tif 000028
【図２７】
2019216447.tif 000029
【図２８】
2019216447.tif 000030
【手続補正書】
【提出日】令和1年10月18日(2019.10.18)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
複数の地域における加入者にＭＮＰ（Ｍｏｂｉｌｅ  Ｎｕｍｂｅｒ  Ｐｏｒｔａｂｉｌｉｔｙ）を提供する方法であって、
前記複数の地域の全てをカバーする中央ノードからＭＮＰの共通するコアプロセスを提供するステップと、
ＭＮＰの複数の地域適応化プロセスを提供するステップであって、各地域適応化プロセスは複数の地域ノードのそれぞれから提供され、各地域ノードは異なる各自の地域をカバーする、提供するステップと、
前記共通するコアプロセス及び前記複数の地域適応化プロセスのそれぞれを実現することによって、加入者にＭＮＰを提供するステップと、
を有する方法。
【請求項２】
当該方法は、前記地域ノードのそれぞれと少なくとも１つのモバイルネットワークオペレータとの間の各自のコネクタを提供するステップを含む、請求項１記載の方法。
【請求項３】
前記コネクタは、ＨＴＴＰ（Ｈｙｐｅｒ  Ｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）、ＳＭＴＲ（Ｓｉｍｐｌｅ  Ｍａｉｌ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）、ＳＯＡＰ（Ｓｉｍｐｌｅ  Ｏｂｊｅｃｔ  Ａｃｃｅｓｓ  Ｐｒｏｔｏｃｏｌ）及びＲＳＴ（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎａｌ  Ｓｔａｔｅ  Ｔｒａｎｓｆｅｒ）から選ばれる複数の異なるプロトコルの少なくとも１つを含む、請求項２記載の方法。
【請求項４】
前記地域ノードの少なくとも１つは、複数の国のＭＮＰの地域適応化プロセスを提供する、請求項１乃至３何れか一項記載の方法。
【請求項５】
前記地域ノードの少なくとも１つは、１つの国のＭＮＰの地域適応化プロセスを提供する、請求項１乃至４何れか一項記載の方法。
【請求項６】
前記中央ノードは、モバイルネットワークにおいてクライアントアプリケーションからＭＮＰリクエストを受信する中央インタフェースを有する、請求項１乃至５何れか一項記載の方法。
【請求項７】
当該方法は、ＭＮＰの少なくとも１つの中間プロセスを提供するステップを含み、前記ＭＮＰの少なくとも１つの中間プロセスは、前記複数の地域の一部に共通する機能を実行する、請求項１乃至６何れか一項記載の方法。
【請求項８】
前記少なくとも１つの中間プロセスは、ＭＮＰを提供するため、複数の地域適応化プロセスとやりとりする、請求項７記載の方法。
【外国語明細書】
2019216447000001.pdf