(57)【特許請求の範囲】
【請求項１】
プラットフォーム管理・運営機能を果たす手段を備えたオペレーション・メンテナンスプロセッサと、
信号トラフィックを取り扱う手段を備えたネットワークアクセスプロセッサと、
データベースサーバと
を相互接続するネットワークを有するワイヤレスモビリティサービスプラットフォームであって、
前記データベースサーバが、耐故障性の冗長スキームに従って複数のハードウェアプラットフォームに分散されたメモリサブスクライバデータベースを有し、かつ、ルーティングパッケージ、アプリケーションパッケージ、及びトリガパッケージを有するパッケージベースのデータベース構造を維持するための手段を有し、
前記プラットフォームが、前記オペレーション・メンテナンスプロセッサ、前記ネットワークアクセスプロセッサ、及び前記データベースサーバでホストされる、共通通信・データベースアクセス機能を有するプラットフォームソフトウェア層を有し、
前記プラットフォームが、複数のアプリケーションをホストするための手段を有し、
前記プラットフォームが、前記ネットワークアクセスプロセッサでホストされる信号中継層を有し、前記信号中継層が、フィルタリング基準に従って信号トラフィックを監視するため、及び前記監視に基いてアプリケーションをトリガリングするための手段を有し、更に、入ってくる信号におけるオペレーションを検査し、かつ前記検査に応じて、元の宛先に信号を中継するか、別の宛先に信号を中継するか、または前記プラットフォーム上に存在するアプリケーションのためのプロクシとして機能して、前記アプリケーションをシミュレーションすることにより応答を生成するための手段を有することを特徴とするワイヤレスモビリティサービスプラットフォーム。
【請求項２】
前記データベースサーバが、全てのサブスクライバデータについて２つのリアルタイム位置を有する２Ｎ冗長構成に構成されることを特徴とする請求項１に記載のワイヤレスモビリティサービスプラットフォーム。
【請求項３】
前記データベースサーバが、内部の活動中及び待機中のサブスクライバデータベースに加えて、前記オペレーション・メンテナンスプロセッサ上にディスクサブスクライバデータベースを維持するための手段を含むことを特徴とする請求項２に記載のワイヤレスモビリティサービスプラットフォーム。
【請求項４】
前記オペレーション・メンテナンスプロセッサが、前記データベース上のサブスクライバデータを使用者が更新することを可能にする手段を含むことを特徴とする請求項３に記載のワイヤレスモビリティサービスプラットフォーム。
【請求項５】
前記オペレーション・メンテナンスプロセッサが、イベントが前記プラットフォーム内から受け取られかつデータベースに記録されるイベントハンドリングを実行するための手段を含むことを特徴とする請求項１乃至４の何れかに記載のワイヤレスモビリティサービスプラットフォーム。
【請求項６】
前記オペレーション・メンテナンスプロセッサが、前記プラットフォームの全てのプロセッサに対してタイミングを同期させるための手段を含むことを特徴とする請求項１乃至５の何れかに記載のワイヤレスモビリティサービスプラットフォーム。
【請求項７】
前記データベース構造が、ＨＬＲパッケージを含むことを特徴とする請求項１乃至６の何れかに記載のワイヤレスモビリティサービスプラットフォーム。
【発明の詳細な説明】
【０００１】
（序論）
【技術分野】
本発明は、GSM、ANSI41、またはPDC等の様々なネットワークプロトコルのいずれかにおいて配置するためのワイヤレスモビリティサービスプラットフォームに関するものである。
【０００２】
【背景技術】
本発明の目的は、下記の項目の幾つかまたは全部を提供することである。即ち、
（ａ）ネットワークの障害許容力、
（ｂ）高い設備能力、
（ｃ）オンラインでアップグレードする能力、
（ｄ）ネットワークデータの柔軟なアロケーションとプロビジョニングの能力、
（ｅ）高い処理能力、
（ｆ）新たなアプリケーションを速やかかつ簡単に装備できる能力。
【０００３】
【発明の開示】
従って、本発明によれば、ネットワークを有するワイヤレスモビリティサービスプラットフォームであって、
前記ネットワークが、
プラットフォーム管理・運営機能を果たす手段を備えたオペレーション・メンテナンスプロセッサと、
信号トラフィックを取り扱う手段を備えたネットワークアクセスプロセッサと、
耐故障性の冗長スキームに従って複数のハードウェアプラットフォームに分散されたメモリサブスクライバデータベースを含むデータベースサーバと、
前記オペレーション・メンテナンスプロセッサ、前記ネットワークアクセスプロセッサ、及び前記データベースサーバでホストされる、共通通信・データベースアクセス機能を有するプラットフォームソフトウェア層と、
ネットワークアクセスプロセッサでホストされる信号中継層との間を相互接続することを特徴とするワイヤレスモビリティサービスプラットフォームが提供される。
【０００４】
或る実施態様では、前記信号中継層が、フィルタリング基準に従って信号トラフィックを監視するための手段を含む。
【０００５】
或る実施態様では、前記信号中継層が、前記監視に基いてアプリケーションをトリガリングするための手段を含む。
【０００６】
或る実施態様では、前記信号中継層が、入ってくる信号におけるオペレーションの検査に従って、元の宛先に信号をフォワーディングするか、別の宛先に信号を中継するための手段を含む。
【０００７】
或る実施態様では、前記信号中継層が、前記プラットフォーム上に存在するアプリケーションをシミュレートすることによって応答を生成するための手段を含む。
【０００８】
別の実施態様では、前記データベースサーバが、パッケージをベースにしているデータベース構造を維持するための手段を含む。
【０００９】
或る実施態様では、前記データベース構造が、コアパッケージ、HLRパッケージ、ルーティングパッケージ、及びトリガパッケージを含む。
【００１０】
或る実施態様では、前記データベースサーバが、全てのサブスクライバデータについて２つのリアルタイム位置を有する２Ｎ冗長構成に構成される。
【００１１】
或る実施態様では、前記データベースサーバが、内部の活動中及び待機中のサブスクライバデータベースに加えて、前記オペレーション・メンテナンスプロセッサ上にディスクサブスクライバデータベースを維持するための手段を含む。
【００１２】
或る実施態様では、前記オペレーション・メンテナンスプロセッサが、前記データベース上のサブスクライバデータを使用者が更新することを可能にする手段を含む。
【００１３】
或る実施態様では、前記オペレーション・メンテナンスプロセッサが、イベントが前記プラットフォーム内から受け取られかつデータベースに記録されるイベントハンドリングを実行するための手段を含む。
【００１４】
或る実施態様では、前記オペレーション・メンテナンスプロセッサが、前記プラットフォームの全てのプロセッサに対してタイミングを同期させるための手段を含む。
【００１５】
【発明を実施するための最良の形態】
本発明は、添付の図面とともに、単なる例示として提示された以下のいくつかの実施例についての説明を参照することで、より明確に理解されよう。
【００１６】
図１には、ワイヤレスモビリティサービスプラットフォーム１の全体のアーキテクチャが示されている。そのプラットフォームは、分散された３つの層即ちコンポーネントアーキテクチャを有し、これによりそのシステムの様々な機能性コンポーネントが、同じ位置に配置することも幾何学的に分散配置することもできる複数のハードウェアプラットフォームの上に配備されることになる。その層とは、以下に列記するものである。即ち、
・OMP：オペレーション・メンテナンスプロセッサ２
このOMPは、そのプラットフォームの全ての部分の完全集中管理運営を提供し、オペレータのサブスクライバ管理及びネットワーク運営システムとの媒介をサポートする。
・NAP：ネットワークアクセスプロセッサ３
このNAPは、全てのSS7及びX.25信号トラフィックの取扱いと、任意のMAPプロトコルの実行とを担う信号エンドポイントである。NAP群は、サポートされているアプリケーションの必要に応じて、２Ｎ冗長構成またはN+1負荷分割構成のいずれかの形で配備され得る。
・DBS：データベースサーバ４
このDBSは、プラットフォーム１のための完全に集中化された冗長性を有するメモリ内（RAM）サブスクライバデータベースを提供する。DBSは、常に２Ｎ冗長構成の形で配備され、これによって全てのサブスクライバデータが少なくとも２つのリアルタイム位置に維持されて、DBSシステムの１個に障害が生じた場合でもサービスが停止しないことが確実となる。データの更新は、DBSインスタンス群とOMPとで同期して行われる。
【００１７】
この構成の利点としては、以下のものが挙げられる。
・集中化された管理及びプロビジョニングインタフェース。
OMPコンポーネントが独立していることによって、複数のプラットフォームが1個の論理システムとして管理・プロビジョニングされ得ることになる。このOMPは、オペレータのネットワーク運営及びサブスクライバ管理システムに対してインタフェースする必要がある唯一のプラットフォームである。
・障害許容力
NAP及びDBSコンポーネントは共に、1個のシステムの障害に対する完全な障害許容力を確保するべく2N冗長構成の形に配置することができる。ほぼ100%のアベイラビリティを得ることができる。障害の検出は、そのプラットフォームの基本的機能であり、例えばHP ServiceGuardTM等の第三者の製品には依存していない。
・処理能力
ネットワークアクセス層（NAP）とデータベースサーバ（DBS）とが、別々のプラットフォームに配置できる論理的に別のシステムであることから、実際に実現される用途が必要とする厳密な処理能力や容量の要求を満たすような、あらゆる配置にすることが可能である。ネットワーク層においてデータベースサーバにおけるものより非常に高い処理能力を必要とする用途は、NAPシステムのための処理能力をDBSシステムよりその分だけ高めることで実現することができ、その逆もまた可能である。
・利用しやすさ及び機能のアップグレード
この分散型アーキテクチャによって、追加の能力を提供するべく別のシステムを付加するときにサービスが停止しないことが確実となる。同様に、2N冗長構成によって、待機中のシステムを、提供中のサービスに影響を及ぼすことなく新たなアプリケーションまたはOSソフトウェアのバージョンにアプグレードすることが可能となる。
【００１８】
ここで、図２を参照すると、プラットフォーム１のソフトウェアアーキテクチャが表示されている。各層は、以下説明するように図１に示すアーキテクチャのコンポーネントの1個または複数個に存在する。
【００１９】
HP-UXTM (Unix（登録商標）)１１。これはオペレーティングシステムであり、OA及びM 2、NAP 3、及びDBS 4に存在する。
【００２０】
HP Open CalITM１１。これは第三者であるHewlett PackardTMのスタックであり、NAP3上に存在する。
【００２１】
プラットフォーム層１２。これは通信機能やデータベースアクセス機能のような共通ソフトウェア機能を有する。全てのコンポーネント２、３、及び４に存在する。
【００２２】
信号中継層（SRL）１３。これは、入ってくる信号を監視し、設定可能な基準に従ってフィルタリング及び中継オペレーションを実行する。NAP３上に存在する。
【００２３】
主要アプリケーション１４。RIG、HLR、またはAuC等の大規模なアプリケーションが存在する。それらは、全てのアーキテクチャコンポーネント２、３、及び４上に少なくとも部分的に存在する。
【００２４】
小型のアプリケーション１５。モジュラー式にプラットフォーム１に付加され得る小規模アプリケーションが存在する。それらは、全てのアーキテクチャコンポーネント上に少なくとも部分的に存在する。
【００２５】
図１のアーキテクチャ及び図２のソフトウェア構造により、新しいカスタム品のアプリケーションを、費用対効果の高い形で速やかに開発・配備することが可能となる。複数のアプリケーションはコホスト（co-host）即ち共同ホストすることができる。アプリケーション専用ロジックがNAPコンポーネントに存在し、そこで実現されるサービスの特定の要求に基いてネットワークトラフィックが処理され得る。
【００２６】
サブスクライバデータは、DBSのRAMデータベース及びOMP上のセキュリティ保護されたストレージに記憶される。使用されるパッケージ指向データベース設計により、新たなデータの型及び構造を、複雑で時間のかかる固定的データベーススキーマの変更を行う必要なしに容易に実現できる。全てのエントリは、MSISDNまたはIMSI（ANSI 41におけるMDN及びMIN）またはそれと同等のものにより複式キー入力され得る。データベースパッケージ構造は図３に図示されている。その構造は、コアパッケージ、HLRパッケージ、ルーティングパッケージ、アプリケーションケーションパッケージ、及びトリガパッケージを備える。プラットフォームがモジュラー式に構成されていることにより、共通のコンポーネントを頻繁に再使用することも可能である。
【００２７】
以下、アーキテクチャのコンポーネントにについてより詳細に説明する。NAP３は、全てのSS7及びX. 25ネットワークトラフィックの処理を担う、アベイラビリティが高く高性能のネットワークサーバである。各NAPは、最大32個のSS7リンクをサポート可能である。様々な製品のアプリケーションロジックはNAPに存在する。NAPは、MAP、TCAP及びSCCPプリミティブが管理され得る場所だからである。NAPスタックは図４に示されている。
【００２８】
SS7スタックオプション
以下のスタック変数がサポートされる。
・GSM ITU SS7
−MAP Phase 2+, 2 and 1
−TCAP (White Book)
−SCCP (Blue Book)
−MTP (Blue Book)
・ANSI-41/ANSI SS7
−MAP ANSI Revs A, B, C, D
−TCAP ANSI T1. 114
−SCCP ANSI T1. 112
−MTP ANSIT1. 111
・ハイブリッドスタック
−GSM/ITU MAP over ANSI TCAP以下
・リバースハイブリッドスタック
−ANSI MAP over GSM/ITU TCAP 以下
MAP over X. 25またはTCP/IPを用いるANSI変数も可能である。
【００２９】
構成
NAPの構成として、（2N冗長としても知られる）アクティブ／スタンバイ（Active/Standby）と、N+1冗長により高いアベイラビリティが得られる負荷分割構成との2種がある。
・2N冗長構成
この構成はＮ個のアクティブNAPノードからなり、各ノードにはホットスタンバイ（待機中）のパートナーノード（hot standby partner node）が存在し、これは活動中のシステムにおいて何らかの障害が生じた場合に即座に機能を引き継がせるために利用できる。回復時間は６秒以下に保証されている。全てのSS7リンクは、回復時にアクティブ状態のままであり、サブシステムが動作を続ける。各NAPペアに対して、１つのプロトコルスタックが１つのポイントコードを有する。新たなペアを追加するには、追加のポイントコードを割り当てる必要がある。
・N+1冗長構成
この構成では、N個のアクティブプラットフォームが、ネットワークを共有する。プラットフォームの１つに障害が生じた場合、負荷は残りのシステムのなかで再度分散される。この構成は、SCCPグローバルタイトルルーティング（SCCP Global Title Routing）をサポートし、第1のNAPが利用不可能になった場合にGT変換を異なるNAPに切り換えることが可能なホームSS7ネットワークの残りの部分に依存している。ポイントコードエイリアシングも、サポートされている場合には使用することができる。
【００３０】
データベースサーバ（DBS）
このDBSは、プラットフォーム１上で動作するアプリケーションのための、完全に集中化された冗長性を有するメモリ内（RAM）サブスクライバデータベースを提供する。DBSは、常に2N冗長構成の形で配備され、これによって全てのサブスクライバデータが少なくとも2つの同時進行位置に維持されて、DBSインスタンスの1個が障害が生じた場合でもサービスが停止しないことが確実となる。
【００３１】
各DBSメモリデータベースは、OMPに格納されたディスクのデータベース及び（2N冗長ペアにおける）その相手のDBSと完全に同期をとってデータ更新される。各ペアについて、一方のDBSはアクティブ状態となるように構成され、一方のDBSが影データとなる。DBSシステムのアクティブDBS／影DBSの組み合わせは、障害が生じた場合に最大の冗長性を維持できるように構成される。
【００３２】
或るアプリケーションがアクティブなDBSに更新要求を送信するとき、そのアクティブDBSは、そのサービス及びネットワークオペレータの要求に応じて、以下の３種の方法のうちの１つに構成され得る。即ち、
１．影DBSがデータを複製した後に初めて、アクティブDBS上でのデータベースの更新とクライアントアプリケーションへの応答が行われる。
２．アクティブDBSは、影DBSの確認応答を待たずにそのデータベースの更新を行う。しかし、クライアントアプリケーションへの応答は、影DBSの確認応答を受け取った後に行う。
３．アクティブDBSは、影DBSの確認応答を待たずにそのデータベースの更新とクライアントアプリケーションへの応答を行う。これは最速動作モードであり、高速の応答時間を要求するアプリケーションのために設計されたものである。
【００３３】
オペレーション・メンテナンスプロセッサ（OMP）
オペレーション・メンテナンスプロセッサは、オペレータのサブスクライバ管理及びネットワーク運営システムとの媒介機能を含む、プラットフォーム１全体の管理運営機能を提供する。
【００３４】
このOMPはまたディスクデータベースを備えており、データベースの同期を取ることについて重要な役割を果たしている。
【００３５】
OMPは以下の役目を担っている。即ち、
・DBS及びNAP装置の始動と停止、
・サブスクライバディスクデータベースの変更、
・イベント情報の維持と報告。
【００３６】
OMPは、以下の論理エンティティからなる。
・OMPマネージャ
OMP UNIX（登録商標）プロセスを生成し、DBS群及びNAP群の始動／停止を連携させる。
・RDBMS
障害発生時の回復のためにMSDP情報をディスクに格納するために用いられる第三者のデータベース（OpenIngresTM）。
・システム管理者端末
MSDP及び関連アプリケーションのためのグラフィカルユーザインタフェース（DUI）。複数のインスタンスを、ローカルで、或いはTCP/IPを介してリモートで動作させることができる。
・プロビジョニングインタフェース
サブスクライバの生成／読み出し／更新／削除のために用いられる。外部システムが全てのサブスクライバデータをリモートで管理できるようにするために、全機能のMMLが用いられる。
・イベントハンドラ
システム内のエンティティからイベント／アラームを受け取る。選択に応じて、それらをイベントモニタ及び（特殊なファイル例えばRS-232、TCP/IP等であり得る）UNIX（登録商標）ファイルに記録する。
・プラットフォームモニタ
プラットフォームのノード（DBS、NAP）の状態を監視し表示する。複数のインスタンスを、ローカルで、或いはTCP/IPを介してリモートで動作させることができる。
・DBSインタフェース
システムを始動させたとき、またはプロビジョニングインタフェースからサブスクライバを追加／変更／削除したとき、DBSのサブスクライバ情報を更新するために用いられる。NAPからディスクデータベースに更新を保護しておくためにDBSも使用する。
・タイミングインタフェース
あらゆる装置上でのシステム時間を同期させるために用いられる（ネットワークタイムプロトコル（Network Time Protocol）を用いる）。
【００３７】
前記プラットフォーム１の有利な特徴は、ネットワークでのSS7トラフィックを監視し、かつSCCP、TCAPまたはMAPレベルでのオペレーションの検査に基いてアプリケーションをトリガする能力を提供する信号中継層１３である。検査されたオペレーションは、
・元の宛先へフォワーディングされるか、
・別の宛先に中継されるか、
・そのプラットフォームアプリケーションが、そのオペレーションの元の宛先のシステムであるかのごとくシミュレーション処理を行ってMAPレベルで応答されるか、のいずれかであり得る。
【００３８】
この能力により、プラットフォームが、番号ポータビリティのようなアプリケーションをサポートしたり、或いは複数のHLRを含むネットワークにおいてアドレスレジスタとして機能することが可能となる。
【００３９】
フォワーディング、中継、または応答のいずれを行うかの決定は、そのプラットフォームに含められたデータを用いることで、或いはMAP、INAP、TCP/IPまたは他のプロトコルを用いて外部システムに照会することによりなされ得る。図５にはトリガリングの一例が示されており、ここではプラットフォームが「Ulysses」と称される。この例では、プラットフォームがINAP信号２を生成し、次に宛先ネットワーク要素のためのMAPオペレーション３ｂを生成する。その後、MAP応答が宛先ネットワーク要素から発信元ネットワーク要素に供給される。
【００４０】
図６及び図７は、特定のアプリケーションやオペレータの個々の要求を満たすように改変できるその能力とアーキテクチャの柔軟性が実証されている2つの典型的な構成を示す。図６は、冗長性を有する小規模乃至中規模の配置を示す。この構成は、冗長性を必要とするが、設備能力や処理能力についての要求はあそれほど高くない用途、例えば小規模GSMネットワークにおける番号ポータビリティアプリケーションに適したものである。
【００４１】
以下の3つのプラットフォームが配備されている。
・システム全体管理用の管理者用端末を備えたHP D2xxシリーズスタンドアロンOMPが1台。
・アクティブ／スタンバイ構成（2N冗長構成）に配置されたHP K4xxシリーズが2台。NAPとDBSソフトウェアの両方がそれぞれの装置上で動作する。
【００４２】
図１０は、完全冗長の大規模マルチノード構成を示す。この特定の構成は、ANSI-41とGSMとの間を接続する大規模なローミング網間接続ゲートウェイ（RIG）を表す。ここには以下のように、全部で11のシステムが存在する。
・HP D2xxシリーズスタンドアロンOMPが1台。
・HP K3xx シリーズDBSプラットフォームが4台。
・HP K4xx NAPプラットフォームが2台。
・HP D2xxシリーズANSI-41認証局が2つ。
・HP D2xxシリーズGSM認証局が2つ。
【００４３】
プラットフォーム１のトランザクション速度については、このプラットフォームは、混雑している時間において１秒間持続するトラフィック当たり数十〜数千個のトランザクションを処理する構成に配置することが可能である。応答時間については、このプラットフォーム１は、処理されることが必要なプロトコル及びデータベースの要求に応じて、約200〜700ミリ秒でメッセージを返す。最終的には応答時間はその適用対象によって決まる。妥当な仮定としては、混雑時におけるサービスインスタンスの95%について、プラットフォームは500ミリ秒以下で応答することができる。
【００４４】
混雑時での95%の場合、その用途についての目標応答時間は、概ね以下のとおりである。
・単純なSCCP中継のための応答時間150ミリ秒、
・トリガロジックが実行され（即ちMAPが解析され）、かつサービスデータベースがアクセスされないときの応答時間200ミリ秒、
・DBSのアクセスのそれぞれについて追加の100ミリ秒、
・サービスロジックの呼び出し及びMAP応答の送信のために追加の100ミリ秒、
・１回の外部SCF/SDFトランザクションの呼び出しのために追加の300ミリ秒。但し、これには外部SCF/SDFにおいて費やされる時間は含まれない。
【００４５】
データベースのサイジングについては、プラットフォーム１は、約600万のHLR型のデータレコードをサポートできる。例えば番号ポータビリティのような必要となるデータがより少ない用途もあり、また、取り扱える最大のレコード数は1000万程度である。
【００４６】
本発明は、ここに説明した実施態様に限定されず、その構造及び細部を様々に変更することができる。
【図面の簡単な説明】
【図１】  本発明のプラットフォームの概略図。
【図２】  ソフトウェアアーキテクチャを示す図。
【図３】  パッケージ指向データベース構造を示す図。
【図４】  サポートされている変数を示す図。
【図５】  サービスのトリガリングを示す図。
【図６】  ２種のハードウェアプラットフォームの構成のうち小規模の構成のハードウェアアーキテクチャを示す図。
【図７】  ２種のハードウェアプラットフォームの構成のうち大規模の構成のハードウェアアーキテクチャを示す図。
【図１】
0004830081.tif 000002
【図２】
0004830081.tif 000003
【図３】
0004830081.tif 000004
【図４】
0004830081.tif 000005
【図５】
0004830081.tif 000006
【図６】
0004830081.tif 000007
【図７】
0004830081.tif 000008