JP3699900B2 - 複数のプラットフォーム間を渡る統合移動通信システムおよび方法 - Google Patents
複数のプラットフォーム間を渡る統合移動通信システムおよび方法 Download PDFInfo
- Publication number
- JP3699900B2 JP3699900B2 JP2001037564A JP2001037564A JP3699900B2 JP 3699900 B2 JP3699900 B2 JP 3699900B2 JP 2001037564 A JP2001037564 A JP 2001037564A JP 2001037564 A JP2001037564 A JP 2001037564A JP 3699900 B2 JP3699900 B2 JP 3699900B2
- Authority
- JP
- Japan
- Prior art keywords
- terminal
- mobile terminal
- platform
- mobile
- communication
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W60/00—Affiliation to network, e.g. registration; Terminating affiliation with the network, e.g. de-registration
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W76/00—Connection management
- H04W76/20—Manipulation of established connections
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W8/00—Network data management
- H04W8/02—Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W8/00—Network data management
- H04W8/02—Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
- H04W8/04—Registration at HLR or HSS [Home Subscriber Server]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W8/00—Network data management
- H04W8/18—Processing of user or subscriber data, e.g. subscribed services, user preferences or user profiles; Transfer of user or subscriber data
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
- H04W80/04—Network layer protocols, e.g. mobile IP [Internet Protocol]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
- H04W88/16—Gateway arrangements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
- H04W88/18—Service support devices; Network management devices
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W92/00—Interfaces specially adapted for wireless communication networks
- H04W92/02—Inter-networking arrangements
Description
【０００１】
【発明の属する技術分野】
本発明は移動通信に関し、特に、種々の移動通信プロトコルを統合管理すべく、プラットフォームを渡る移動通信を実現し、モニタリングする方法および装置に関する。
【０００２】
【従来の技術】
移動通信に対する要望は年々高まる一方である。このような要望に応じるため、移動通信産業は、シグナリングの手法に応じて多種多様なプロトコルを取り入れてきた。これらの多種の通信を統合すべく、現在使用されている多数のプロトコルを相互に織り込んだシステムが必要とされている。
【０００３】
移動通信プロトコルには、たとえばセルラープロトコル、モバイルＩＰ、ＤＨＣＰ／ＤＮＳ (dynamic host configuration protocol/domain name system)、ＳＩＰ（session initiation protocol）などがある。通信機能に応じて各プロトコルも異なり、各プロトコルの実行ごとに、位置登録、位置確認、認証、許可、課金などの標準機能をサポートしなければならない。位置登録は、モバイル端末からその位置を通知し、確認を受け取ることによって、ネットワークあるいはプラットフォーム内での端末の位置を登録するものである。位置確認は、モバイル端末がネットワーク内のどの場所に位置するかを確認するものである。認証は、モバイルのユーザーがネットワークで認められた正当なユーザであるかどうかを決定する機能であり、少なくともひとつのデータベースをインタラクティブに使用することによって行う。許可は、モバイル端末のユーザがそのネットワークの特定のサービスを受けられるか否かを決定する機能であり、同じくひとつ以上のデータベースをインタラクティブに使用して許可の可否を決定する。課金は、ネットワークがモバイル端末をモニタリングして料金を課す機能である。認証（Authentication）、許可（Authorization）、課金（Accounting）は一般にトリプルＡ（“ＡＡＡ”）機能と呼ばれている。
【０００４】
通常は、端末の電源をＯＮにした時点と、端末がネットワークのサイトから別のサイトへハンドオフ（通信チャネル切替）した時点で位置登録が行なわれ、同時に、認証も行なわれる。位置確認は、一般に、第１の端末が第２の端末との通信チャネルを設定しようとするときに行なわれ、同時に、第１および第２の端末に対する認証も行なわれる。また、モバイル端末が他の端末と通信している期間に課金される。以後、通信を開始する側の端末を「発呼側（端末）」と、通信される側の端末を「着呼側（端末）」と称することとする。
【０００５】
本明細書において、プラットフォームはネットワークの一部として定義付けられ、プラットフォーム内では、同一のシグナリングプロトコルを用いて、接続セットアップ、接続解除、ハンドオフ、位置登録、位置確認、課金が行なわれる。プラットフォームはまた、単一の提供元によって提供されるネットワークの一部である。たとえ、Ａ社が提供するネットワークのシグナリングプロトコルと、Ｂ社のネットワークのシグナリングプロトコルが同一であっても、あくまでも単一の提供元のネットワークに含まれるものだけをプラットフォームとする。単一の提供者（たとえばベル・アトランティック・モバイル）が、そのネットワーク内に複数のプラットフォームを有することもできる。この場合、たとえば、第１のプラットフォームはＣＤＭＡ（符号分割マルチプルアクセス）方式を用い、第２のプラットフォームはアナログのＡＭＰＳを用い、第３のプラットフォームはモバイルＩＰを用いるなど、それぞれ異なるプロトコルを使用することができる。
【０００６】
異なる提供元によって管理されるが同一のプロトコルを使用する複数のプラットフォーム間の境界は、モビリティ・データベースによって管理され、各ネットワークの提供元は、それぞれ独自のモビリティ・データベースを有する。
【０００７】
上述した多様な機能は、端末にサービスを提供するネットワークに接続されたデータベースによって実行される。図１６は、データベースを含む従来のモバイル通信ネットワーク配置を示す。データベースは、モバイル端末の端末ＩＤ（ＴＩＤ）、ロケーションＩＤ（ＬＩＤ）、パスワード、パーミッション・リスト、課金情報など、多様な情報を格納する。プラットフォームによっては、モビリティ・データベースおよび共通ＬＩＤの概念をサポートしないものもある。
【０００８】
図１６に示すように、各ネットワークは、モビリティ・データベースを有する。モビリティ・データベースは、端末ＩＤ、ロケーションＩＤ、その他の端末情報を格納する。たとえば、携帯ネットワーク１０１（１Ｇ／２Ｇ携帯ネットワーク）は、ＨＬＲ（Home Location Register：ホーム位置レジスタ）と呼ばれるモビリティ・データベース１０５を有し、端末ＩＤとしてのＥ．１６４番号、ロケーションＩＤとしてのプラットフォーム固有情報、パスワードとしてプラットフォーム情報の集合、パーミッション・リスト、課金リストを格納する。周知の携帯ネットワークの中には、位置登録と課金に関してトラヒックを低減するために、ＨＬＲに格納された情報のコピーを記録するＶＬＲ（Visitor Location Register：ビジタ位置レジスタ）を用いることもある。
【０００９】
モバイルＩＰネットワーク１０２は、ＨＡ（home agent：ホームエージェント）と呼ばれるデータベース１０６を有する。データベース１０６は、端末ＩＤおよびロケーションＩＤとしてのＩＰアドレス、パスワードとしてのプラットフォーム固有情報の集合、パーミッション・リスト、および課金リストを格納する。モバイルＩＰ（ＲＦＣ２００２）の最新スタンダードでは、ＦＡ（foreign agent：フォーリンエージェント）と呼ばれる特別機能を備える。ＦＡは、モバイルＩＰ固有の相関性を扱うものであるが、このような機能は周知であり、本発明の範囲外であるので詳述は避ける。
【００１０】
ＤＨＣＰ／ＤＮＳネットワーク１０３は、ドメインネームシステムと呼ばれるモビリティ・データベース１０７を有する。モビリティ・データベース１０７は、端末ＩＤとしてのホストネームおよびドメインネーム、ロケーションＩＤとしてのＩＰアドレス、パスワードとしてのプラットフォーム固有情報の集合、パーミッション・リスト、および課金リストを格納する。ＤＨＣＰ（Dynamic Host Configuration Protocol）を用いて、モバイル端末が現在アクセスできるアクセスポイントのＩＰアドレスを割り当ててもよい。さらに、現在ＩＥＴＦで論じられているダイナミックＤＮＳを用いて、割り当てられたＩＰアドレスをネットワーク全体に広告することもできる。
【００１１】
ＳＩＰネットワーク１０４は、ＳＩＰプロキシ（proxy）と呼ばれるモビリティ・データベース１０８を有する。モビリティ・データベース１０８は、端末ＩＤおよびロケーションＩＤとしてのＳＩＰ ＵＲＬ、パスワードとしてプラットフォーム固有情報の集合、パーミッション・リスト、および課金リストを格納する。
【００１２】
エンドユーザは、通話相手（着呼者）が現在どのネットワークにいるかにかかわりなく、任意の相手と通信する機能を要望するが、個々のネットワークは異なるプロトコルを有するので、直接の接続は無理である。また、モビリティ・データベース１０５〜１０８間での情報交換が存在しないので、別のネットワークの端末に、より高度な機能（認証、許可、課金など）を期待するのは不可能である。
【００１３】
このような問題に鑑みて、ＩＰ（インターネットプロトコル）通信と、非ＩＰ通信とを整合させるシステムが提案されている。たとえば、シスコ・システムズ（Cisco Systems）社のホワイトペーパーには、インターネット上で音声、映像、データを統合するアーキテクチャが開示されている（http://www.cisco.com/warp/public/cc/cisco/mkt/iptel/prodlit/avvid_wp.htm）。
【００１４】
この文献は、ＩＰベースのプラットフォームを含む複数のモバイルプラットフォーム間で相互通信を行なう方法を提案しており、特に、図１７に示すように、クライアントレベル１１２、インフラレベル１１１、呼処理レベル１１０、およびアプリケーションレベル１０９の４層構造のアーキテクチャを開示する。
【００１５】
アプリケーションレベル１０９は自由な開発のために他者へ開放され、統一メッセージング（Unified Messaging）のような高度なサービスを実現する。呼処置レベル１１０は、コールマネージャとして機能し、インターネット上での音声による呼を制御する。コールマネージャは、ＩＰベースのボイス・アプリケーションに、通常の電話で通話するような見栄えと感覚を与える。
【００１６】
コールマネージャはまた、要求に応じて、図１８に示すようにＩＰ通信とＰＳＴＮ通信との間の相互通信を制御する。図１８では、ＩＰベースのネットワーク１１４（ルータ等を含む）と、ＰＳＴＮネットワーク１１５との間での通話例を示す。ＩＰベース端末１１９が、まずコールマネージャ１１６に発呼の要求をする。コールマネージャ１１６は、ＰＳＴＮネットワーク１１５の呼設定部１１７と通信制御情報の交換を行う。すべての情報交換が完了したら、物理的リンクとしてのゲートウェイ１１３を介して、ＩＰベース端末１１９とＰＳＴＮ端末１１８との間に呼が設定される。コールマネージャ１１６は、物理リンクゲートウェイ１３を制御して、所望の呼を設定する。
【００１７】
【発明が解決しようとする課題】
しかし、図１８に示すシステムは、ＩＰ通信とＰＳＴＮとの間の相互通信方法を開示しながらも、移動通信関連の機能については、なんら開示していない。
【００１８】
さらに別の方法として、ＴＩＡ（電気通信産業協会）が提案する方法がある（http://www.tiaonline.org）。ＴＩＡは、ＩＰサービスを実行するＴＲ４５．６アーキテクチャを提供しており、このアーキテクチャは、図１９に示すように、アクセスネットワークと、コアネットワークとの２つの階層を有する。（この構成は、http://search.ietf.org/internet-drafts/draft-hiller-3gwireless-00.txtにも掲載されている。） 図１９では、コアネットワークは、モバイルＩＰ対応のＩＰネットワーク１２０であり、アクセスネットワークは、携帯ネットワーク１２３および１２４である。ＩＰネットワーク１２０は、フォーリンエージェント（ＦＡ）１２１と、ネットワークのモビリティ・データベースとして位置登録および位置確認に関与するホームエージェント（ＨＡ）とを有する。各アクセスネットワーク１２３、１２４は、ＶＬＲ（ビジター位置レジスタ）１２６、１２９と、ＨＬＲ（ホーム位置レジスタ）１２７、１３０をそれぞれ有する。ホーム位置レジスタ（ＨＬＲ）とビジター位置レジスタ（ＶＬＲ）との組み合わせにより、これらのアクセスネットワークのモビリティ・データベースとして機能する。ＩＰネットワーク１２０は、必ずしもインターネットとは同義ではないことに留意する必要がある。インターネットはすべてのトラヒックに対して開放されているが、ＩＰネットワーク１２０は、インターネットの一部、あるいはインターネットとは別個のネットワークであり、ＩＰ（インターネットプロトコル）通信に限られている。
【００１９】
図１９のシステムでは、あるモバイル端末から、別のネットワークをホームネットワークとするモバイル端末に通信するために、ＩＰネットワーク１２０を経由して呼を転送しなければならない。すなわち、別のプラットフォームにある端末に通信するためには、モバイル端末はＩＰコンパチブルな機能を備えていなければならない。ＩＰネットワーク１２０を介した通信に関与するすべての端末がＩＰコンパチブルでなければ、図１９のシステムは機能しないという問題点があり、ＩＰコンパチブルでない端末の使用が大きく制限されることになる。
【００２０】
そこで、本発明は、複数のモバイルプラットフォーム間で相互通信を可能とするシステムおよび方法を提供することを第１の目的とする。
【００２１】
本発明の第２の目的は、ＩＰベースのプラットフォームをも含めた複数のモバイルプラットフォーム間で相互通信を可能とするシステムおよび方法を提供することにある。
【００２２】
本発明の第３の目的は、異なるプラットフォームにあるモバイル端末間での通信を実現するシステムおよび方法を提供することにある。
【００２３】
本発明の第４の目的は、ＩＰ対応機能を有さないモバイル端末と、ＩＰ対応仕様のモバイル端末との間の通信を実現するシステムおよび方法を提供することにある。
【００２４】
また、異なる複数のプラットフォーム間を渡る移動通信を行なう場合の、モバイル端末の位置確認方法および位置登録方法を提供することをも目的とする。
【００２５】
その他の目的および効果については、以下で図面を参照して述べる詳細な説明により、明らかになるものである。なお、米国の移動通信市場の状況については、http://www.fcc.gov/wth/reports/fc99136.pdfを参照されたい。
【００２６】
【課題を解決するための手段】
上記の目的を達成するために、本発明は、既存のプラットフォームと、プラットフォームごとに設けられている現存の移動通信データベースをほとんどそのまま利用し、かつ、統一された通信操作で異なるプラットフォーム間の通信を可能にする統一的な移動通信管理システムと方法を実現する。
【００２７】
具体的には、本発明の複数プラットフォーム間を渡る統一移動通信システムは、第１のプロトコルを用いて第１のモバイル端末にサービスを提供する第１の通信プラットフォームと、第２のプロトコルを用いて第２のモバイル端末にサービスを提供する第２の通信プラットフォームと、これら第１および第２の通信プラットフォームの間に接続される移動通信管理部（UMM：unified mobility manager）とを含む。第１の通信プラットフォームは、第１のモバイル端末の端末ＩＤとロケーションＩＤとを関連付けて格納する第１の移動通信データベースを有し、第２の通信プラットフォームは、第２のモバイル端末の端末ＩＤとロケーションＩＤとを関連付けて格納する第２の移動通信データベースを有する。
【００２８】
本発明のシステムの特徴として、システムは第２モバイル端末の端末ＩＤのエイリアス（別名）を、第１プラットフォームの第１プロトコルと互換性のある形式で、第２モバイル端末本来の端末ＩＤと関連付けて格納する第１プラットフォーム用のエイリアス・データベース（第１のエイリアス・データベース）を含み、移動通信管理部は、このエイリアス・データベースにアクセスする。システムはさらに、第１モバイル端末の端末ＩＤのエイリアスを、第２プラットフォームの第２プロトコルと互換性のある形式で、第１モバイル端末本来の端末ＩＤと関連付けて格納する第２のエイリアス・データベースを含み、移動通信管理部は、このエイリアス・データベースにアクセスする。
【００２９】
たとえば、第１のプラットフォームがＩＰ（インターネットプロトコル）対応のネットワークに含まれ、第２のプラットフォームが公衆電話網とすると、第１プラットフォームにおけるモバイル端末の端末ＩＤは、たとえばドメインネームであり、第２プラットフォームにおけるモバイル端末の端末ＩＤは、１０桁の数字から成る電話番号である。本発明のシステムにおいては、第１プラットフォーム用のエイリアス・データベースに、第２プラットフォーム端末用のドメインネームを、この端末本来のＩＤ（すなわち電話番号）のエイリアスとして格納する。また、第２プラットフォーム用のエイリアス・データベースに、第１プラットフォームのモバイル端末用の電話番号を、このモバイル端末本来のＩＤ（すなわちドメインネーム）のエイリアスとして格納する。
【００３０】
このように端末ＩＤを別のプラットフォームと互換性のある形式に変換したエイリアスを有することによって、異なるプラットフォーム間の移動通信を円滑に行うことができる。たとえば、ＩＰネットワーク上にある第１モバイル端末のユーザは、公衆電話網にある第２端末（たとえば携帯電話）のエイリアスであるドメイン名を入力すれば、移動通信管理部がエイリアスデータベースにアクセスし、検索したドメイン名を第２端末本来の電話番号に変換して、相手先に接続する（通話を可能にする）。
【００３１】
移動通信管理部は、第１のモバイル端末から第２モバイル端末に宛てられたメッセージを捕獲受信する受信部を有する。このメッセージ中には、第２モバイル端末のエイリアスが含まれる。移動通信管理部は判定部を有し、判定部は、メッセージから抽出されたエイリアスに基づいて第１のエイリアス・データベースを調べ、第２モバイル端末が第２プラットフォームに属するのか、あるいは第１プラットフォームに属するのかを判断する。第２モバイル端末のエイリアスが第１のエイリアス・データベースにあれば、この第２モバイル端末が第２プラットフォームに属すると判断する。移動通信管理部の出力部は、この判断に基づいて、第２プラットフォームの移動通信データべースを検索して第２端末の位置を取得するように求める要求を出力する。これにより、第２端末の位置確認が行なわれる。
【００３２】
移動通信管理部はまた、任意のプラットフォームにある第２端末からのメッセージを受信して、第２端末の位置登録を行わせる。この場合、エイリアスデータベースを検索することによって、判定部が第２端末の本来の端末ＩＤを求め、第２端末が本来属する第２プラットフォームの移動通信データベースに第２端末の位置登録を行うように求めるメッセージを出力する。
【００３３】
このように、既存の異なるプラットフォーム間に統一的な移動通信管理部（ＵＭＭ：unified mobility manager）を介在させ、エイリアスデータベースを参照することによって、異なるプラットフォーム間でモバイル端末のアドレス変換を行ない、任意のモバイル端末の位置を確認することが可能になる。また、移動通信管理部が任意のプラットフォーム上にある端末から発せられた位置登録用のメッセージを捕獲受信し、エイリアスデータベースに基づいてアドレス変換し、変換されたアドレスに基づいて他プラットフォームの移動通信データベースにアクセスすることにより、任意のモバイル端末の現在位置を、別のプロトコルで管理されている他プラットフォームの移動通信データベースに登録することが可能になる。
【００３４】
各プラットフォームの移動通信データベースは、課金情報、認証情報の少なくとも一方を格納し、移動通信管理部による各プラットフォームの移動通信データベースとのインタラクションを介して、任意の（他プラットフォームの端末をも含む）モバイル端末の位置を検索し、域外にあるモバイル端末の認証、許可、課金を可能にする。
【００３５】
このように、移動通信管理部は、複数のプラットフォーム間に渡って、ひとつのプロトコルから別のプロトコルへとアドレス変換することにより、異なるプラットフォーム間での移動通信を実現するものである。
【００３６】
本発明のその他の特徴、効果は、以下で図面を参照して述べる詳細な記載により、いっそう明確になる。
【００３７】
【発明の実施の形態】
＜第１実施形態＞
図１に、本発明の第１実施形態に係る統一された移動通信ネットワークの構成図を示す。それぞれ異なるプロトコルを有する複数のネットワーク（またはそれに含まれるプラットフォーム）１〜４と、各ネットワークに対応する移動通信データベース５〜９との間に移動通信管理部（あるいはUMM：unified mobility manager）１０が介在する。ネットワーク１はたとえば携帯電話用の通信規約であるセルラープロトコルで管理される携帯電話ネットワークであり、ネットワーク２は、モバイル用のインターネットプロトコルで管理されるモバイルＩＰネットワークである。同様に、ネットワーク３はＤＨＣＰ／ＤＮＳプロトコルを採用する通信ネットワークであり、プラットフォーム４はＳＩＰ（session initiation protocol）を採用する通信ネットワークである。
【００３８】
上述したように、本発明において、ネットワークに単一のプラットフォームが対応してもよいし、複数のプラットフォームが含まれていてもよいが、説明の便宜上、良好な実施形態においてはネットワークとプラットフォームは対応するものとし、ネットワーク１〜４はそれぞれプラットフォーム１〜４と読み替えてもよいこととする。
【００３９】
移動通信管理部（UMM）１０は、この統一移動通信ネットワーク内の任意のプラットフォームで生成され送信される、あるいは受信されるメッセージを、途中で捕獲受信し、後述する方法により、途中受信したメッセージを、それが処理されるべき適切なデータベースへ転送する。
【００４０】
図２は、図１に示す移動通信管理部１０のネットワーク構成を示す図である。図２において、移動通信管理部１０は、MMGWネットワークとして示され、各プラットフォーム１〜４に対応する移動通信管理ゲートウェイ（ＭＭＧＷ）１１〜１４を備える。各移動通信管理ゲートウェイは、プラットフォーム１〜４と、それぞれ対応する移動通信データベース５〜９の間で送受信されるメッセージをモニタリング、すなわち捕獲受信する。各ゲートウェイで受信されたメッセージが、他のプラットフォームの移動通信データベースに宛てられたものであれば、そのメッセージはクロスプラットフォームパス１５を介して、意図された移動通信データベースへ転送される。
【００４１】
クロスプラットフォームパス１５は、現実の伝送媒体としてたとえばインターネットを用いる伝送通路である。この場合、当業界で周知のように、インターネット上を送受信されるメッセージは、通信パケット内にヘッダと情報本体とを有する。クロスプラットフォームパスとしてインターネットを用いることの利点は、トラヒック増大などにより通信に失敗した場合に、中間ノードで通信情報を送受信できる点にある。あるいは、クロスプラットフォームパス１５は、移動通信データベース５〜８と相互接続される物理的な専用ネットワークであってもよい。物理的な専用ネットワークを用いることの利点は、移動通信データベース間のトランザクション（データ送受信）とは無関係な外部トラヒックに影響を受けずに済む点にある。クロスプラットフォームパスは、オペレータ相互の間で機能する構成としてもよいし、各オペレータとの間で個別に機能する構成としてもよい。換言すれば、単一の相互クロスプラットフォームパスとしてもよいし、ネットワークに接続された複数のクロスプラットフォームパスとしてもよい。
【００４２】
図１および２に示すシステムの特徴として、各プラットフォームに対応するエイリアスデータベース２１〜２４を備える。図２の例では、エイリアスデータベース２１〜２４はそれぞれ対応するゲートウェイ（ＭＭＧＷ）１１〜１４に接続されている。エイリアスデータベースは、他のプラットフォーム上のモバイル端末に関する識別情報を格納するデータベースである。既存の技術においては、一般にモバイル端末は、その端末が属するプラットフォームのネイティブプロトコルに基づいて別の端末の存在を確認する。たとえば、携帯端末であればＥ．１６４を用いて他のプラットフォームの端末を呼び出す。この場合、相手先の端末がたとえば他プラットフォームであるＤＨＣＰ／ＤＮＳプラットフォームにあるとすると、対手先の端末のホストネームあるいはドメインネームを、自己が属するセルラーネットワークに与えることはしないという問題を含む。さらに、従来の技術においては、端末は、基本的にその端末の識別子だけを取り扱える設計になっており、携帯端末であれば、ＳＩＰネットワークから送られてきたＳＩＰ ＵＲＬの端末ＩＤに応答できるようには設計されていない。
【００４３】
本発明の移動通信管理部１０におけるエイリアスデータベース２１〜２４は、既存の技術におけるこのような問題点を解決するために設けられている。すなわち、エイリアスデータベース２１〜２４は、他のプラットフォームにあるモバイル端末の識別情報を、自己のホームプラットフォームで使用できるフォーマットで格納する。具体的には、エイリアスデータベースは、他プラットフォームにあるモバイル端末の端末ＩＤを自己のプラットフォーム用のフォーマットに変換した識別名であるエイリアス（別名）と、他のプラットフォームにあるモバイル端末の本来の端末ＩＤと、他のプラットフォームを示す識別子とを互いに関連付けて格納する。プラットフォーム識別子については、端末ＩＤの中に組み込まれてもよい。エイリアスデータベース２１〜２４はさらに、移動通信データベース５〜８の中のどのデータベースが、この遠隔（他プラットフォーム）のモバイル端末に関する情報を格納しているかを特定するルーティング情報を格納してもよい。
【００４４】
セルラープラットフォーム１用のエイリアスデータベース２１に格納されるエントリの例を挙げると、ＤＨＣＰ／ＤＮＳネットワーク３にある端末ＩＤ゛doug.domainname.com”のエイリアスとして、電話番号の形態で（212）556-1234を格納し、モバイルＩＰネットワーク２上で”123.456.78.9”で定義されている端末ＩＤのエイリアスとして、フリーダイヤル番号(800)345-6789を格納する。このように、Ｅ．１６４ネットワーク１にあるモバイル端末は、自己のプラットフォームで使用されている形式（すなわち電話番号の形態）のまま、他プラットフォームにあるモバイル端末に発呼することができる。
【００４５】
エイリアスデータベース２１〜２４のエントリは一般的に、
１）エイリアス（自己プラットフォームの形式での識別子）
２）実アドレス（遠隔(他の)プラットフォームの実際の端末ＩＤ）
３）この遠隔端末をサポートするプラットフォーム（ルーティング情報）
これらのエントリは、たとえば構成の簡単なテーブルとして格納されてもよい。３番目のルーティング情報に関しては、遠隔にある端末ＩＤをサポートするのが単一のネットワークのみである場合には、オプションとして省略してもよい。複数のネットワークがこの端末ＩＤに関する単一のプロトコルを支援しているが、各プラットフォームは個別に経営され操作されている場合は、正しい移動通信データベース５〜８にメッセージを配信するために個別にプラットフォームの識別を行なうのが好ましい。
【００４６】
図２において、移動通信管理ゲートウェイ（ＭＭＧＷ）１１は、セルラープラットフォーム１の移動通信データベース５へ送信、あるいはこのデータベースから供給されるメッセージをモニタリングする。このセルラーネットワーク１上で生成されたメッセージは、まずすべて、このネットワークを介して移動通信データベース５に向けられる。移動通信管理ゲートウェイ１１は、このルートの途中でメッセージを捕獲受信し、このメッセージがセルラーネットワーク１用の移動通信データベース５を指定するものであるかどうかを判断する。メッセージが移動通信データベース５に向けられたものであれば、ゲートウェイ１１はメッセージをデータベース５に配信する。そうでない場合は、ゲートウェイ１１は、メッセージが意図する適切なデータベース６〜８にメッセージを転送する。あるいは、同じセルラーネットワーク１内であっても、別会社によって経営され、あるいは異なる地域で運営されている別バージョンのデータベース５に転送することもありえる。別のデータベースへメッセージを転送する過程において、移動通信管理ゲートウェイは、メッセージが宛てられたデータベースのプロトコルと互換性のある形式にフォーマットし直すこともできる。
【００４７】
図３は、クロスプラットフォーム発呼処理の例を示す。図３の例では、プラットフォームＢの発呼側端末４１は、プラットフォームＡの着呼側端末３１を呼び出そうとしている。発呼側端末４１も着呼側端末３１も、それぞれが本来属するプラットフォームＢおよびＡに位置登録している。この例では、端末４１の（本来の）ネイティブプラットフォームはプラットフォームＢであり、端末３１のネイティブプラットフォームはプラットフォームＡである。したがって、端末４１および３１の位置は、対応する移動通信データベース４２、３２にそれぞれ登録されている。図３のような呼の設定を実現するには、プラットフォームを渡る位置確認が必要となる。呼び出し先の端末の位置確認のために着呼側のデータベースにアクセスする必要を回避するために、すべての端末に関するすべての位置を格納できる中間データベースを設けてもよい。
【００４８】
図３に示すように、プラットフォームBにある発呼側端末４１からプラットフォームAの着呼側端末３１を呼び出す場合、発呼側端末４１は、プラットフォームＢで使われているプロトコルによって着呼側端末３１を識別する。たとえば、プラットフォームＢはＥ．１６４セルラープロトコルを使用するとする。この場合、発呼側端末４１は、電話番号(XXX)YYY-ZZZZをダイヤルすることによって、相手先（着呼側端末）３１を呼び出す。統合移動通信管理部５０のゲートウェイ５２は、発呼側端末４１がダイヤルした電話番号（すなわち位置分析要求）を捕獲受信し、エイリアスデータベース２６を参照する。エイリアスデータベース２６を検索することによって、着呼側端末３１がプラットフォームBの端末であるか否かを判断する。図３に示す例では、着呼側端末３１はプラットフォームBの端末ではないので、エイリアスデータベース２６はゲートウェイ５２に着呼側端末３１に関するエイリアス情報を提示する。ゲートウェイ５２は、エイリアスデータベース２６から与えられた情報に基づき、プラットフォームＢのプロトコルからプラットフォームＡのプロトコルへ変換する。変換後、ゲートウェイ５２は、プラットフォームＡ用のゲートウェイ５１を介して移動通信データベース３２にアクセスすることによって、プラットフォームＡ上の着呼側端末３１の現在位置を確認する（位置確認）。
【００４９】
なお、エイリアスデータベースは、遠隔端末のエイリアスと実アドレス、および必要ならばルーティング情報をたとえばテーブル形式で格納しており、構成が非常に簡単である。このため、良好な実施形態では、ゲートウェイ５２は、まずエイリアスデータベースを参照して、発呼側端末が呼び出そうとしている端末が、他プラットフォームの端末であるか否かを調べることとしている。しかし、まず自己の移動通信データベース４２を検索して呼び出し先の端末が自己のプラットフォームにあるか否かを判断する構成としてもよい。
【００５０】
上述したように、異なるプラットフォームを渡って相手先（着呼側）のネイティブプラットフォームの移動通信データベースにアクセスすることにより、次のような効果が達成される。
【００５１】
（１）着呼側プラットフォームの移動通信データベースに格納されている許可リストを参照することによって、発呼側からの呼（より一般的にはプラットフォームＢからの呼）が許可されたものであるか否かを確認することができる。
【００５２】
（２）複数のルート（配信パス）が存在する場合に、着呼側プラットフォームＡの移動通信データベース３２を用いて着呼側端末３１の位置を確認することによって、ゲートウェイ５２は適切なパスを決定することができる。
【００５３】
（３）課金技術によっては、プラットフォームＡの移動通信データベース３２を用いて着呼側端末に向けられた呼をモニタリングし、課金処理を行なうことができる。また、その呼に関して、移動通信で用いられている公知の方法により、発呼者側に課金することもできる。
【００５４】
図４に示すように、移動通信管理部（UMM）５０により実現されるプラットフォーム間を渡る（クロスプラットフォーム）通信は、プラットフォーム間に位置するプラットフォームゲートウェイ５５によって設定される。プラットフォームゲートウェイ５５は、シグナリングプロトコルを終端させる。「終端」させるというのは、当業界で周知のように、プロトコル処理の機能的な側面をも含むものである。シグナリングの終端例は、たとえば「非同期転送モード通信システム用のマルチメディアネットワークインターフェイス（“Multimedia Network Interface for Asynchronous Transfer Mode Communication System”）」と題された米国特許第5,717,691号に開示されている。シグナリングプロトコル、すなわち回線接続を確立するための信号交換を終端させるとは、たとえば、メッセージのコンテンツを読んで、そのコンテンツにより指定されたことを行なうことを意味する。例として、通信チャネルの設定および切断、ハンドオフ、課金、位置確認および位置登録などがある。シグナリングの終端に関するその他の例は、上記の米国特許を参照されたい。
【００５５】
プラットフォームゲートウェイ５５は、エイリアスデータベース２６および２５からのエイリアス情報を使用して、発呼側端末４１と着呼側端末３１との間にチャネルを設定する。各エイリアスデータベース２６、２５から得たエイリアス情報に基づいて、プラットフォームゲートウェイ５５は、プラットフォームゲートウェイ５５の両側のエンドポイント（終点）を確立する。すなわち、プラットフォームB用のエイリアスデータベース２６を用いて、発呼側端末４１から着呼側端末３１に向けての通信パスが生成され、プラットフォームＡ用のエイリアスデータベース２５を用いて、着呼側端末３１から発呼側端末４１への逆方向の通信パスが生成される。
【００５６】
図４の例では、説明の便宜上、２つのプラットフォームしか描かれていないが、３以上のプラットフォームがある場合でも同様である。この場合、各エイリアス・データベースは、ネイティブプラットフォーム以外のプラットフォームにある端末に関するエイリアス情報を格納し、プラットフォームゲートウェイ５５は、これらのエイリアス・データベースからの情報をもとに、適切なチャネルを設定することができる。
【００５７】
図５は、発呼側端末４１と着呼側端末３１の間の通信例を示す。図５の例では、プラットフォームＢはセルラープロトコル（Ｅ．１６４等）に基づく携帯電話網であり、プラットフォームＢの発呼側端末４１の端末ＩＤは、たとえば(AAA)BBB-CCCCである。一方、ＤＨＣＰ／ＤＮＳプロトコルに基づくプラットフォームＡにある着呼側端末３１の端末ＩＤは、”doug.domainname.com”である。プラットフォームゲートウェイ５５は、プラットフォームＢ用のエイリアス・データベース２６（図４）を調べ、着呼側端末３１のエイリアスが格納されているかどうかを検索する。エイリアス・データベース２６に着呼側端末３１のエイリアスが格納されているということは、着呼側端末３１は、プラットフォームＢ以外の他プラットフォームにあることを意味する。プラットフォームゲートウェイ５５は、エイリアス・データベース２６に格納されている着呼側端末３１のエイリアスである電話番号（XXX）YYY-ZZZZに基づき、発呼側から着呼側に向ける通信パスを生成する。同様に、エイリアス・データベース２５から得られたプラットフォームＡにおける発呼側端末４１のエイリアス”bob.domainname.com”に基づき、着呼側から発呼側への逆チャネルを設定する。
【００５８】
発呼側端末４１からのメッセージ（あるいはメッセージパケット）は、そのヘッダ情報に着呼側端末３１を識別するための情報、すなわち着呼側端末３１の端末ＩＤをプラットフォームＢにおける電話番号としての形態（エイリアス）にした識別情報を含んだ状態で、プラットフォームＢに発信される。このヘッダ情報を含むメッセージは、プラットフォームゲートウェイ５５によってプラットフォームＡへと転送される。この転送プロセスにおいて、ヘッダに含まれるエイリアスである電話番号（XXX）YYY-ZZZZは、着呼側端末３１の本来の端末ＩＤ（実アドレス）”doug.domainname.com”に置き換えられる。変換後の実アドレス、すなわち着呼側端末３１の本来の端末ＩＤに基づいて、メッセージは着呼側端末３１に配信される。
【００５９】
リターンパス（復路）も同様にして設定される。すなわち、エイリアスデータベース２５からのエイリアス情報はプラットフォームゲートウェイ５５に送られる。着呼側端末３１は、ヘッダ情報を有するメッセージ（またはメッセージパケット）を出力する。このヘッダ情報の中には、発呼側端末４１のエイリアスとして、プラットフォームAでの識別名”bob.domainname.com”が含まれている。プラットフォームゲートウェイ５５は、このメッセージパケットを受け取り、ヘッダ情報を発呼側端末４１の実際の端末ＩＤである(AAA)BBB-CCCCに変換し、メッセージを発呼側端末に送信する。
【００６０】
図６は、本発明の良好な実施形態に基づく統合移動通信管理システムを用いたハンドオフの例を示す。着呼側端末３１が移動中である場合、ゾーン間、セクタ間で、ハンドオフと呼ばれる通信中のチャネル切替を行なう必要がある。図６の例で、着呼側端末３１は、プラットフォームA内のひとつのサイトから同じプラットフォーム内の別のサイトへと移動している。着呼側端末３１の移動につれて、その位置をプラットフォームAの移動通信データベース３２に再登録する必要がある（図６において破線の矢印で示す）。着呼側端末３１に宛てられたメッセージはプラットフォームＡの移動通信管理ゲートウェイ５１を通過する。移動通信管理ゲートウェイ５１は、発呼側端末４１からのメッセージ（又はメッセージパケット）をモニタリングして、そのメッセージに移動先を示す適切なロケーションＩＤ（ＬＩＤ）を与える。この着呼側端末３１のロケーションＩＤの変更プロセスは、発呼側端末４１に通知される。
【００６１】
なお、図６では、各プラットフォームのための移動通信管理ゲートウェイ５１および５２と、プラットフォームゲートウェイ５５との間のデータパスを省略してあるが、図４と同様に、他プラットフォームにある着呼側端末３１との間で通信を行なうためのエイリアスデータのやり取りが行なわれていることは言うまでもない。
【００６２】
図７は、本発明の良好な実施形態に基づく統合移動通信管理システムを用いた呼の終端処理の例を示す。通信チャネルが終端されると、プラットフォームゲートウェイ６０は、発呼側端末４１と着呼側端末３１との間の信号パスを終端する制御を行なう。通信チャネルは、プラットフォームＡおよびＢのそれぞれの側で、そのプラットフォーム本来のネイティブプロトコルで切断される。
【００６３】
＜第2実施形態＞
図８は、本発明の第2実施形態に係る統合移動通信管理システムを用いたハンドオフの別の例を示す。図６に示す第1実施形態でのハンドオフの例では、着呼側端末３１が同一プラットフォームＡ内の別のサイトへ移動する際のハンドオフを示していたが、図８では、異なるプラットフォーム間でのハンドオフ、すなわちプラットフォームを渡るローミングを示す。状況によっては、発呼側端末と着呼側端末の間の直接接続ができない場合もあり得る。このような場合、図８に示すように、プラットフォームＢにあるモバイル端末Ａと、プラットフォームＣにあるモバイル端末Ｂは、プラットフォームＡ（たとえばインターネット）を介して通信を行なう。ここでは、通信パスは、２つのプラットフォームゲートウェイ６１および６２を用いて設定される。プラットフォームゲートウェイ６１は、プラットフォームＡとＢとの間のメッセージ（またはメッセージパケット）の交換を行なうために、プラットフォームゲートウェイ６２は、プラットフォームＡとＣとの間のメッセージ交換のために用いられる。
【００６４】
モバイル端末Ｂは、プラットフォームＣからプラットフォームＤへと移動し、今度はプラットフォームゲートウェイ６３がその通信ライン上に必要になってくる。一方、プラットフォームＡとＣをつなぐプラットフォームゲートウェイ６２は、通信チャネルからはずれる。この場合、ひとつの方法として、端末Ａと端末Ｂとの間のプラットフォームゲートウェイ６２を介したそれまでの通信パスを完全に終端させるという方法がある。別の方法は、それまでの通信パスも、通信パスの一部としてそのまま残し、端末ＡとＢのいずれか一方のロケーションＩＤの変化に応じた変更要求にしたがい、通信パスの一部分を変更するものである。後者の場合、端末ＡとＢのいずれか一方のロケーションＩＤの変化に応じてセグメントを変更し、変調を行なう。
【００６５】
なお、発呼時の発呼側端末ＡからＢへの通信チャネルの形成は、まず、プラットフォームＢ上にチャネルを形成し、次にプラットフォームＡ上に、最後に着呼側端末Ｂが位置するプラットフォームＣ上に形成する。
【００６６】
図９は、図８に示したネットワークプラットフォーム間でのハンドオフがどのように実行されるかを示す構成図である。統合移動通信システム（あるいはネットワーク）７０は、各プラットフォームＡ〜Ｄのための移動通信管理ゲートウェイ７２〜７５とを含む移動通信管理部と、エイリアスデータベース７６〜７９と、クロスプラットフォームパス８０を有する。各プラットフォームＡ〜Ｄは、それぞれ対応する移動通信データベース８１〜８４を有する。各プラットフォームの移動通信データベースは、既存の移動通信データベースでよい。
【００６７】
発呼側端末Ａが位置するプラットフォームＢと、着呼側端末Ｂが位置するプラットフォームＣの間には直接のプラットフォームゲートウェイが存在せず、かわらにプラットフォームＡを間に介して、通信チャネルの設定を行なう。着呼側端末ＢのプラットフォームＤへの移動につれて、同じくプラットフォームＡを介し、別のプラットフォームゲートウェイを用いて、新たな通信チャネルを設定する。
【００６８】
ハンドオフを効率的に行なうために、各プラットフォーム間に位置するプラットフォームゲートウェイ６１、６２、６３は、発呼側端末Ａと着呼側端末Ｂの端末ＩＤ、およびこれら端末の各プラットフォームにおけるエイリアスを備えることが望ましい。あるいは、ハンドオフの際に、必要とされるプラットフォームゲートウェイが対応するプラットフォームの移動通信ゲートウェイを介して、エイリアスデータベースを参照することによって、移動先プラットフォームでの着呼側端末Ｂの実アドレスを読み出してもよい。
【００６９】
図８および９に示す例では、発呼側端末Ａと着呼側端末Ｂは、１以上のネイティブプロトコルに基づき、１以上のホームネットワーク（あるいはホームプラットフォーム）に属するものとする。たとえば、発呼側端末Ａは、モバイルＩＰ環境とセルラー（１Ｇ／２Ｇ）環境の双方で機能するデュアルモード／マルチバンド電話機であってもよい。
【００７０】
図１０および１１は、図８および９に示すプラットフォームを渡るハンドオフを実際の端末ＩＤとエイリアスとを用いてどのように行なうかを示す図である。図１０および１１に示す例では、プラットフォームＡは、モバイルＩＰネットワークであり、プラットフォームＢ、Ｃ、Ｄは、たとえばＥ．１６４をサポートするセルラープラットフォームである。発呼側のモバイル端末Ａは、ホームネットワークとしてプラットフォームＢを利用する。着呼側のモバイル端末Ｂは、ホームネットワークとしてプラットフォームＡを利用する。モバイル端末ＡおよびＢの本来の端末ＩＤは、それぞれのホームプラットフォームのプロトコルに基づいて記述されている。
【００７１】
図１０の例では、発呼側のモバイル端末ＡのホームプラットフォームＢにおける端末ＩＤは、(aaa)bbb-ccccである。このモバイル端末Aの他プラットフォームＡにおけるエイリアスは、www.xxx.yyy.zzzであり、プラットフォームCおよびDにおけるエイリアスは、(aaa)bbb-ccccである。プラットフォームが異なってもそこで用いるプロトコルが同一の場合は、ひとつの端末Ａに対して共通のエイリアスが与えられる場合もあり得る。これは、Ｅ．１６４アドレスを指定する複数のデータベース間で単一のエイリアスで通信できるからである。もっとも、必要ならば異なるプラットフォームごとに異なるエイリアスを与えてもよい。
【００７２】
一方、着呼側のモバイル端末ＢのホームプラットフォームＡにおける本来の端末ＩＤはsss.ttt.uuu.vvvである。セルラープラットフォームである他プラットフォームＢ，Ｃ，Ｄでの着呼側端末Ｂのエイリアスは、(ddd)eee-ffffである。上述したように、他プラットフォームにあるモバイル端末のＩＤは、自己のプラットフォームのプロトコル形式に応じたエイリアスに変換され、エイリアスは本来の端末ＩＤとを対応付けて格納される。このようにエイリアスを用いることにより、モバイル端末Ａとモバイル端末Ｂの間に、異なるプラットフォームをわたる通信が可能になる。
【００７３】
図１１に示す例では、異なるプラットフォーム間でハンドオフする場合、発呼側端末Ａが位置するプラットフォームＢと、着呼側端末Ｂが位置するプラットフォームＣの間に直接介在するプラットフォームゲートウェイがない。そこで、破線で示すように、プラットフォームＡを間に介してまず、プラットフォームＢからプラットフォームＣへのチャネルを形成する。着呼側のモバイル端末Ｂが、プラットフォームＣからＤに移動した場合、公知の方法で、移動先における着呼側端末Ｂの位置を確認し、新しいロケーションをプラットフォームＣの移動通信データベースに格納する。ここでのハンドオフ方式はバックワードハンドオフであってよい。発呼側端末Ａと新たなロケーション（プラットフォームＤ）における着呼側端末Ｂとの間に新たに通信パスが形成される前に、プラットフォームＣとの通信路を使って新しいロケーション情報を渡す方式をバックワードハンドオフと呼ぶ。しかし、着呼側端末Ｂの本来の移動通信データベース８２はあくまでもプラットフォームＡにある(図９参照)。
【００７４】
図９に示す、着呼側端末Ｂがそれまで位置していたプラットフォームＣの移動通信ゲートウェイ７４は、着呼側端末ＢからプラットフォームＣ上に発せられたロケーション更新メッセージを途中で捕獲する。このメッセージを調べて、着呼側端末Ｂの本来の移動通信データベースはプラットフォームＡのものであると判断したならば、ゲートウェイ７４は、更新されたロケーションメッセージをプラットフォームＡの移動通信データベース８２に転送する。このやり取りに基づいて、プラットフォームＡ、Ｃ、Ｄのハンドオフプロトコルは、着呼側端末Ｂの移動（位置変更）に適応すべく変更される。
【００７５】
ハンドオフプロトコルの変更は、たとえば、移動通信管理ゲートウェイ７３、７４、７５がメッセージ（又はメッセージパケット）を取り扱う際に、このメッセージのヘッダ情報を変更することによって行なう。この過程で、プラットフォームＢ（セルラーネットワーク）で用いられていたメッセージの送信先アドレス（すなわち着呼側端末Ｂのエイリアス）は、モバイルＩＰネットワークであるプラットフォームＡのＩＰアドレスに書き換えられ、プラットフォームゲートウェイ６１と移動先のロケーションとの間に新たな通信パスが形成される。プラットフォームＡ用のエイリアスデータベース７７は、特定のロケーションへのクロスプラットフォーム通信チャネルを設定するのに、どのプラットフォームゲートウェイが望ましいかを示すルーティング情報を含んでもよい。
【００７６】
＜第３実施形態＞
図１２は、本発明の第３実施形態に係る統合移動通信管理部９１の構成図である。統合移動通信管理部９１に、ネットワーク（あるいはプラットフォーム）９０と、このネットワークの移動通信データベース９８が接続されている。統合移動通信管理部９１は、移動通信ゲートウェイ９２を有する。移動通信ゲートウェイ９２は、受信部９３と、判定部９４と、出力部９５とを備える。判定部９４にはエイリアス・データベース９７が接続されている。
【００７７】
受信部９３は、ネットワーク９０およびこのネットワーク上にあるモバイル端末からメッセージを受信する。受信部９３は、移動通信データベース９８へ送られるメッセージを途中で捕獲して、判定部９４へ送る。判定部９４はメッセージを調べ、エイリアス・データベース９７に格納された情報に基づき、このメッセージがクロスプラットフォームパス９６を介して他プラットフォームの移動通信データベースに送られるべきか否かを判断する。エイリアス・データベース９７は、上述したように、他プラットフォームにある端末の本来の端末ＩＤと、この端末ＩＤをネットワーク９０のプロトコル形式に変換したエイリアスとを、たとえばテーブルの形式で格納する。このエイリアス・データベース９７に相手側端末のエイリアスが格納されている場合は、この相手側端末は他プラットフォームの端末であり、メッセージの転送が必要であることを意味する。エイリアス・データベースにエイリアスがない場合は、端末は自己のプラットフォームの端末であることを意味する。
【００７８】
判定部９４は、エイリアスデータベース９７の参照の結果、メッセージが他プラットフォームへの転送を必要とすると判断した場合に、このメッセージに適切なエイリアス情報を添付して出力部９５に供給する。出力部９５は、クロスプラットフォームパス９６を介して他プラットフォームの移動通信データベースにメッセージを転送する。一方、エイリアスデータベース９７の参照の結果、メッセージの転送が必要ない、すなわち、端末が自己のホームプラットフォームにあると判断された場合は、出力部９５に対して、自己のプラットフォームの移動通信データベース９８にメッセージを送るよう要求する。
【００７９】
図１３は、第１実施形態〜第３実施形態に共通する統合移動通信管理部のエイリアス処理フローを示す図である。まずステップＳ１３０１で、第１プラットフォームに位置するモバイル端末Ａの端末ＩＤとロケーションＩＤとを、第１プラットフォームの移動通信データベースに格納する。次に、ステップＳ１３０３で、この端末ＩＤのエイリアスを、他のプラットフォーム（１以上）のエイリアスデータベースに、他プラットフォームのプロトコルと互換性のある形式で格納する。一方で、他プラットフォームの端末ＩＤのエイリアスを、第１プラットフォームのエイリアスデータベースに、第１プラットフォームのプロトコルと互換性のある形式で格納する。
【００８０】
次に、ステップＳ１３０５で、移動通信管理部が第２プラットフォームのモバイル端末Ｂに宛てられたメッセージを、端末Ｂのエイリアスの下に受信する。ステップＳ１３０７で、移動通信管理部は、エイリアスに基づいて対応するエイリアスデータベースを検索し、モバイル端末Ｂの本来の端末ＩＤを検索する。最後にステップＳ１３０９で、検索した端末ＩＤとメッセージとを関連付けて、第２プラットフォームへ転送する。
【００８１】
図１４は、移動通信管理部の位置確認処理を示すフローチャートである。モバイル端末Ａからモバイル端末Ｂへとメッセージが送られることとする。モバイル端末Ａのホームプラットフォームは第１プラットフォームであるが、モバイル端末Ｂのプラットフォームはまだわかっていないものとする。
【００８２】
まず、ステップＳ１４０１で、移動通信管理ゲートウェイが、モバイル端末Ａからモバイル端末Ｂへのメッセージを途中で捕獲受信する。ステップＳ１４０３で、移動通信ゲートウェイはメッセージをチェックし、メッセージ中に含まれる相手先識別子が、モバイル端末Ａのプラットフォーム用のエイリアスデータベースに登録されているか否かを判断する。相手先識別子がエイリアスデータベースにあれば（ステップＳ１４０３でＹＥＳ）、ステップＳ１４０７に進み、移動通信管理ゲートウェイは、モバイル端末Ｂのロケーションを、第２プラットフォーム（エイリアスデータベースでモバイル端末Ｂの端末ＩＤとともに、ホームプラットフォームとして検索されている）の移動通信データベースで検索する。相手先識別子がエイリアスデータベースにない場合は（ステップＳ１４０３でＮＯ）、モバイル端末Ｂはモバイル端末Ａと同じ第１プラットフォームにあることを意味し、ステップＳ１４０５で、移動通信管理ゲートウェイはモバイル端末Ｂの現在位置を第１プラットフォームの移動通信データベースで検索する。
【００８３】
図１５は、移動通信管理部の位置登録の処理フローである。まず、ステップＳ１５０１で、移動通信管理ゲートウェイは、第１プラットフォームにあるモバイル端末Ｂからのメッセージを、この第１プラットフォームの移動通信データベースへのメッセージとして捕獲受信する。ステップＳ１５０３で、移動通信管理ゲートウェイは、メッセージ中に含まれる相手先識別子（すなわちエイリアス）が第１プラットフォーム用のエイリアスデータベースにあるかどうかを判断する。エイリアスが第１プラットフォーム用のエイリアスデータベースにある場合は（ステップＳ１５０３でＹＥＳ）、ステップＳ１５０７へ進み、メッセージを第２プラットフォームの移動通信データベースに転送する。相手先エイリアスが第１プラットフォーム用のエイリアスデータベース中にない場合は（ステップＳ１５０３でＮＯ）、ステップＳ１５０５で、メッセージを第１プラットフォームの移動通信データベースに供給する。
【００８４】
以上、良好な実施形態に基づいて本発明を述べてきたが、本発明はこれらの実施形態に限定されず、請求項に特定される本発明の範囲内で多様な変形が可能である。たとえば、実施形態においては、移動通信管理ゲートウェイはまず、エイリアスデータベースを参照して、メッセージを他プラットフォームの移動通信データベースへ転送すべきか否かを判断しているが、これは、エイリアスデータベースの構造自体が非常に簡単であり、検索時間も短いからである。しかし、本発明はこの構成例には限定されず、たとえば、先に自己のプラットフォームの移動通信データベースを参照し、そこにデータがない場合に、エイリアスデータベースを参照する手順としてもよい。
【００８５】
【発明の効果】
本発明によれば、それぞれ異なる通信プロトコルを有する複数のプラットフォーム間で統合された移動通信が可能になる。
【００８６】
また、各プラットフォームで用いられている既存の移動通信データベースをほとんどそのまま利用し、簡単な構成のエイリアスデータベースを設けることにより、プラットフォーム間を渡る移動通信が容易に実現される。
【図面の簡単な説明】
【図１】本発明の一実施形態による複数プラットフォーム間を渡る移動通信システムの概略構成図である。
【図２】図１のシステムにおける統一的な移動通信管理（ＵＭＭ）ネットワークの構成を示す図である。
【図３】本発明の統合移動通信管理システムを介して行われる異なるプラットフォーム間での通信操作の流れを示す図である。
【図４】本発明の統合移動通信管理システムによる呼の設定（通信チャネルの設定）の一例を示す図である。
【図５】本発明の統合移動通信管理システムにおける、各端末の端末ＩＤとエイリアスを用いた通信動作の一例を示す図である。
【図６】本発明の統合移動通信管理システムにおける、ハンドオフの一例を示す図である。
【図７】本発明の統合移動通信管理システムにおける呼の終了の一例を示す図である。
【図８】本発明の統合移動通信管理システムにおける複数プラットフォーム間でのハンドオフの別の例を示す図である。
【図９】図８に示す複数のプラットフォーム間におけるハンドオフを実行する機能構成図である。
【図１０】本発明の統合移動通信管理システムにおけるクロスプラットフォーム・ハンドオフにおいて、各プラットフォームでの端末ＩDとエイリアスの一例を示す図である。
【図１１】本発明の統合移動通信管理システムにおけるクロスプラットフォーム・ハンドオフ動作の一例を示す図である。
【図１２】本発明の統合移動通信管理システムにおける通信管理ゲートウエイの内部構成図である。
【図１３】本発明の端末ＩＤとエイリアスを用いた統合移動通信管理方法のプロセスフローを示す図である。
【図１４】本発明の統合移動通信管理システムにおいて、エイリアスデータベースに基づくモバイル端末の位置登録処理のフローチャートである。
【図１５】本発明の統合移動通信管理システムにおいて、エイリアスデータベースに基づく位置確認処理のフローチャートである。
【図１６】従来のそれぞれ独立したプラットフォームと、各プラットフォームごとに用いられる移動通信データベースを示す図である。
【図１７】従来の移動通信ネットワークにおける４層アーキテクチャを示す図である。
【図１８】従来の異なるプラットフォーム間における固定通信ネットワークを示す図である。
【図１９】従来のＩＰ対応機能を有するモバイル端末専用の移動通信ネットワークを示す図である。
【符号の説明】
１、２，３，４，９０ 通信プラットフォーム
５，６，７，８、３２、４２，８１〜８４、９８ 移動通信データベース
１０、５０ 統合移動通信管理部
１１〜１４，５１，５２、７２〜７５、９２ 移動通信管理ゲートウェイ
１５、８０、９６ クロスプラットフォームパス
２１〜２４、２５，２６、７６〜７９、９７ エイリアス・データベース
３１，４１ モバイル端末
５５、５６、６１〜６３ プラットフォーム・ゲートウェイ
７０、９１ ＭＭＧＷネットワーク
９３ 受信部
９４ 判定部
９５ 出力部
【発明の属する技術分野】
本発明は移動通信に関し、特に、種々の移動通信プロトコルを統合管理すべく、プラットフォームを渡る移動通信を実現し、モニタリングする方法および装置に関する。
【０００２】
【従来の技術】
移動通信に対する要望は年々高まる一方である。このような要望に応じるため、移動通信産業は、シグナリングの手法に応じて多種多様なプロトコルを取り入れてきた。これらの多種の通信を統合すべく、現在使用されている多数のプロトコルを相互に織り込んだシステムが必要とされている。
【０００３】
移動通信プロトコルには、たとえばセルラープロトコル、モバイルＩＰ、ＤＨＣＰ／ＤＮＳ (dynamic host configuration protocol/domain name system)、ＳＩＰ（session initiation protocol）などがある。通信機能に応じて各プロトコルも異なり、各プロトコルの実行ごとに、位置登録、位置確認、認証、許可、課金などの標準機能をサポートしなければならない。位置登録は、モバイル端末からその位置を通知し、確認を受け取ることによって、ネットワークあるいはプラットフォーム内での端末の位置を登録するものである。位置確認は、モバイル端末がネットワーク内のどの場所に位置するかを確認するものである。認証は、モバイルのユーザーがネットワークで認められた正当なユーザであるかどうかを決定する機能であり、少なくともひとつのデータベースをインタラクティブに使用することによって行う。許可は、モバイル端末のユーザがそのネットワークの特定のサービスを受けられるか否かを決定する機能であり、同じくひとつ以上のデータベースをインタラクティブに使用して許可の可否を決定する。課金は、ネットワークがモバイル端末をモニタリングして料金を課す機能である。認証（Authentication）、許可（Authorization）、課金（Accounting）は一般にトリプルＡ（“ＡＡＡ”）機能と呼ばれている。
【０００４】
通常は、端末の電源をＯＮにした時点と、端末がネットワークのサイトから別のサイトへハンドオフ（通信チャネル切替）した時点で位置登録が行なわれ、同時に、認証も行なわれる。位置確認は、一般に、第１の端末が第２の端末との通信チャネルを設定しようとするときに行なわれ、同時に、第１および第２の端末に対する認証も行なわれる。また、モバイル端末が他の端末と通信している期間に課金される。以後、通信を開始する側の端末を「発呼側（端末）」と、通信される側の端末を「着呼側（端末）」と称することとする。
【０００５】
本明細書において、プラットフォームはネットワークの一部として定義付けられ、プラットフォーム内では、同一のシグナリングプロトコルを用いて、接続セットアップ、接続解除、ハンドオフ、位置登録、位置確認、課金が行なわれる。プラットフォームはまた、単一の提供元によって提供されるネットワークの一部である。たとえ、Ａ社が提供するネットワークのシグナリングプロトコルと、Ｂ社のネットワークのシグナリングプロトコルが同一であっても、あくまでも単一の提供元のネットワークに含まれるものだけをプラットフォームとする。単一の提供者（たとえばベル・アトランティック・モバイル）が、そのネットワーク内に複数のプラットフォームを有することもできる。この場合、たとえば、第１のプラットフォームはＣＤＭＡ（符号分割マルチプルアクセス）方式を用い、第２のプラットフォームはアナログのＡＭＰＳを用い、第３のプラットフォームはモバイルＩＰを用いるなど、それぞれ異なるプロトコルを使用することができる。
【０００６】
異なる提供元によって管理されるが同一のプロトコルを使用する複数のプラットフォーム間の境界は、モビリティ・データベースによって管理され、各ネットワークの提供元は、それぞれ独自のモビリティ・データベースを有する。
【０００７】
上述した多様な機能は、端末にサービスを提供するネットワークに接続されたデータベースによって実行される。図１６は、データベースを含む従来のモバイル通信ネットワーク配置を示す。データベースは、モバイル端末の端末ＩＤ（ＴＩＤ）、ロケーションＩＤ（ＬＩＤ）、パスワード、パーミッション・リスト、課金情報など、多様な情報を格納する。プラットフォームによっては、モビリティ・データベースおよび共通ＬＩＤの概念をサポートしないものもある。
【０００８】
図１６に示すように、各ネットワークは、モビリティ・データベースを有する。モビリティ・データベースは、端末ＩＤ、ロケーションＩＤ、その他の端末情報を格納する。たとえば、携帯ネットワーク１０１（１Ｇ／２Ｇ携帯ネットワーク）は、ＨＬＲ（Home Location Register：ホーム位置レジスタ）と呼ばれるモビリティ・データベース１０５を有し、端末ＩＤとしてのＥ．１６４番号、ロケーションＩＤとしてのプラットフォーム固有情報、パスワードとしてプラットフォーム情報の集合、パーミッション・リスト、課金リストを格納する。周知の携帯ネットワークの中には、位置登録と課金に関してトラヒックを低減するために、ＨＬＲに格納された情報のコピーを記録するＶＬＲ（Visitor Location Register：ビジタ位置レジスタ）を用いることもある。
【０００９】
モバイルＩＰネットワーク１０２は、ＨＡ（home agent：ホームエージェント）と呼ばれるデータベース１０６を有する。データベース１０６は、端末ＩＤおよびロケーションＩＤとしてのＩＰアドレス、パスワードとしてのプラットフォーム固有情報の集合、パーミッション・リスト、および課金リストを格納する。モバイルＩＰ（ＲＦＣ２００２）の最新スタンダードでは、ＦＡ（foreign agent：フォーリンエージェント）と呼ばれる特別機能を備える。ＦＡは、モバイルＩＰ固有の相関性を扱うものであるが、このような機能は周知であり、本発明の範囲外であるので詳述は避ける。
【００１０】
ＤＨＣＰ／ＤＮＳネットワーク１０３は、ドメインネームシステムと呼ばれるモビリティ・データベース１０７を有する。モビリティ・データベース１０７は、端末ＩＤとしてのホストネームおよびドメインネーム、ロケーションＩＤとしてのＩＰアドレス、パスワードとしてのプラットフォーム固有情報の集合、パーミッション・リスト、および課金リストを格納する。ＤＨＣＰ（Dynamic Host Configuration Protocol）を用いて、モバイル端末が現在アクセスできるアクセスポイントのＩＰアドレスを割り当ててもよい。さらに、現在ＩＥＴＦで論じられているダイナミックＤＮＳを用いて、割り当てられたＩＰアドレスをネットワーク全体に広告することもできる。
【００１１】
ＳＩＰネットワーク１０４は、ＳＩＰプロキシ（proxy）と呼ばれるモビリティ・データベース１０８を有する。モビリティ・データベース１０８は、端末ＩＤおよびロケーションＩＤとしてのＳＩＰ ＵＲＬ、パスワードとしてプラットフォーム固有情報の集合、パーミッション・リスト、および課金リストを格納する。
【００１２】
エンドユーザは、通話相手（着呼者）が現在どのネットワークにいるかにかかわりなく、任意の相手と通信する機能を要望するが、個々のネットワークは異なるプロトコルを有するので、直接の接続は無理である。また、モビリティ・データベース１０５〜１０８間での情報交換が存在しないので、別のネットワークの端末に、より高度な機能（認証、許可、課金など）を期待するのは不可能である。
【００１３】
このような問題に鑑みて、ＩＰ（インターネットプロトコル）通信と、非ＩＰ通信とを整合させるシステムが提案されている。たとえば、シスコ・システムズ（Cisco Systems）社のホワイトペーパーには、インターネット上で音声、映像、データを統合するアーキテクチャが開示されている（http://www.cisco.com/warp/public/cc/cisco/mkt/iptel/prodlit/avvid_wp.htm）。
【００１４】
この文献は、ＩＰベースのプラットフォームを含む複数のモバイルプラットフォーム間で相互通信を行なう方法を提案しており、特に、図１７に示すように、クライアントレベル１１２、インフラレベル１１１、呼処理レベル１１０、およびアプリケーションレベル１０９の４層構造のアーキテクチャを開示する。
【００１５】
アプリケーションレベル１０９は自由な開発のために他者へ開放され、統一メッセージング（Unified Messaging）のような高度なサービスを実現する。呼処置レベル１１０は、コールマネージャとして機能し、インターネット上での音声による呼を制御する。コールマネージャは、ＩＰベースのボイス・アプリケーションに、通常の電話で通話するような見栄えと感覚を与える。
【００１６】
コールマネージャはまた、要求に応じて、図１８に示すようにＩＰ通信とＰＳＴＮ通信との間の相互通信を制御する。図１８では、ＩＰベースのネットワーク１１４（ルータ等を含む）と、ＰＳＴＮネットワーク１１５との間での通話例を示す。ＩＰベース端末１１９が、まずコールマネージャ１１６に発呼の要求をする。コールマネージャ１１６は、ＰＳＴＮネットワーク１１５の呼設定部１１７と通信制御情報の交換を行う。すべての情報交換が完了したら、物理的リンクとしてのゲートウェイ１１３を介して、ＩＰベース端末１１９とＰＳＴＮ端末１１８との間に呼が設定される。コールマネージャ１１６は、物理リンクゲートウェイ１３を制御して、所望の呼を設定する。
【００１７】
【発明が解決しようとする課題】
しかし、図１８に示すシステムは、ＩＰ通信とＰＳＴＮとの間の相互通信方法を開示しながらも、移動通信関連の機能については、なんら開示していない。
【００１８】
さらに別の方法として、ＴＩＡ（電気通信産業協会）が提案する方法がある（http://www.tiaonline.org）。ＴＩＡは、ＩＰサービスを実行するＴＲ４５．６アーキテクチャを提供しており、このアーキテクチャは、図１９に示すように、アクセスネットワークと、コアネットワークとの２つの階層を有する。（この構成は、http://search.ietf.org/internet-drafts/draft-hiller-3gwireless-00.txtにも掲載されている。） 図１９では、コアネットワークは、モバイルＩＰ対応のＩＰネットワーク１２０であり、アクセスネットワークは、携帯ネットワーク１２３および１２４である。ＩＰネットワーク１２０は、フォーリンエージェント（ＦＡ）１２１と、ネットワークのモビリティ・データベースとして位置登録および位置確認に関与するホームエージェント（ＨＡ）とを有する。各アクセスネットワーク１２３、１２４は、ＶＬＲ（ビジター位置レジスタ）１２６、１２９と、ＨＬＲ（ホーム位置レジスタ）１２７、１３０をそれぞれ有する。ホーム位置レジスタ（ＨＬＲ）とビジター位置レジスタ（ＶＬＲ）との組み合わせにより、これらのアクセスネットワークのモビリティ・データベースとして機能する。ＩＰネットワーク１２０は、必ずしもインターネットとは同義ではないことに留意する必要がある。インターネットはすべてのトラヒックに対して開放されているが、ＩＰネットワーク１２０は、インターネットの一部、あるいはインターネットとは別個のネットワークであり、ＩＰ（インターネットプロトコル）通信に限られている。
【００１９】
図１９のシステムでは、あるモバイル端末から、別のネットワークをホームネットワークとするモバイル端末に通信するために、ＩＰネットワーク１２０を経由して呼を転送しなければならない。すなわち、別のプラットフォームにある端末に通信するためには、モバイル端末はＩＰコンパチブルな機能を備えていなければならない。ＩＰネットワーク１２０を介した通信に関与するすべての端末がＩＰコンパチブルでなければ、図１９のシステムは機能しないという問題点があり、ＩＰコンパチブルでない端末の使用が大きく制限されることになる。
【００２０】
そこで、本発明は、複数のモバイルプラットフォーム間で相互通信を可能とするシステムおよび方法を提供することを第１の目的とする。
【００２１】
本発明の第２の目的は、ＩＰベースのプラットフォームをも含めた複数のモバイルプラットフォーム間で相互通信を可能とするシステムおよび方法を提供することにある。
【００２２】
本発明の第３の目的は、異なるプラットフォームにあるモバイル端末間での通信を実現するシステムおよび方法を提供することにある。
【００２３】
本発明の第４の目的は、ＩＰ対応機能を有さないモバイル端末と、ＩＰ対応仕様のモバイル端末との間の通信を実現するシステムおよび方法を提供することにある。
【００２４】
また、異なる複数のプラットフォーム間を渡る移動通信を行なう場合の、モバイル端末の位置確認方法および位置登録方法を提供することをも目的とする。
【００２５】
その他の目的および効果については、以下で図面を参照して述べる詳細な説明により、明らかになるものである。なお、米国の移動通信市場の状況については、http://www.fcc.gov/wth/reports/fc99136.pdfを参照されたい。
【００２６】
【課題を解決するための手段】
上記の目的を達成するために、本発明は、既存のプラットフォームと、プラットフォームごとに設けられている現存の移動通信データベースをほとんどそのまま利用し、かつ、統一された通信操作で異なるプラットフォーム間の通信を可能にする統一的な移動通信管理システムと方法を実現する。
【００２７】
具体的には、本発明の複数プラットフォーム間を渡る統一移動通信システムは、第１のプロトコルを用いて第１のモバイル端末にサービスを提供する第１の通信プラットフォームと、第２のプロトコルを用いて第２のモバイル端末にサービスを提供する第２の通信プラットフォームと、これら第１および第２の通信プラットフォームの間に接続される移動通信管理部（UMM：unified mobility manager）とを含む。第１の通信プラットフォームは、第１のモバイル端末の端末ＩＤとロケーションＩＤとを関連付けて格納する第１の移動通信データベースを有し、第２の通信プラットフォームは、第２のモバイル端末の端末ＩＤとロケーションＩＤとを関連付けて格納する第２の移動通信データベースを有する。
【００２８】
本発明のシステムの特徴として、システムは第２モバイル端末の端末ＩＤのエイリアス（別名）を、第１プラットフォームの第１プロトコルと互換性のある形式で、第２モバイル端末本来の端末ＩＤと関連付けて格納する第１プラットフォーム用のエイリアス・データベース（第１のエイリアス・データベース）を含み、移動通信管理部は、このエイリアス・データベースにアクセスする。システムはさらに、第１モバイル端末の端末ＩＤのエイリアスを、第２プラットフォームの第２プロトコルと互換性のある形式で、第１モバイル端末本来の端末ＩＤと関連付けて格納する第２のエイリアス・データベースを含み、移動通信管理部は、このエイリアス・データベースにアクセスする。
【００２９】
たとえば、第１のプラットフォームがＩＰ（インターネットプロトコル）対応のネットワークに含まれ、第２のプラットフォームが公衆電話網とすると、第１プラットフォームにおけるモバイル端末の端末ＩＤは、たとえばドメインネームであり、第２プラットフォームにおけるモバイル端末の端末ＩＤは、１０桁の数字から成る電話番号である。本発明のシステムにおいては、第１プラットフォーム用のエイリアス・データベースに、第２プラットフォーム端末用のドメインネームを、この端末本来のＩＤ（すなわち電話番号）のエイリアスとして格納する。また、第２プラットフォーム用のエイリアス・データベースに、第１プラットフォームのモバイル端末用の電話番号を、このモバイル端末本来のＩＤ（すなわちドメインネーム）のエイリアスとして格納する。
【００３０】
このように端末ＩＤを別のプラットフォームと互換性のある形式に変換したエイリアスを有することによって、異なるプラットフォーム間の移動通信を円滑に行うことができる。たとえば、ＩＰネットワーク上にある第１モバイル端末のユーザは、公衆電話網にある第２端末（たとえば携帯電話）のエイリアスであるドメイン名を入力すれば、移動通信管理部がエイリアスデータベースにアクセスし、検索したドメイン名を第２端末本来の電話番号に変換して、相手先に接続する（通話を可能にする）。
【００３１】
移動通信管理部は、第１のモバイル端末から第２モバイル端末に宛てられたメッセージを捕獲受信する受信部を有する。このメッセージ中には、第２モバイル端末のエイリアスが含まれる。移動通信管理部は判定部を有し、判定部は、メッセージから抽出されたエイリアスに基づいて第１のエイリアス・データベースを調べ、第２モバイル端末が第２プラットフォームに属するのか、あるいは第１プラットフォームに属するのかを判断する。第２モバイル端末のエイリアスが第１のエイリアス・データベースにあれば、この第２モバイル端末が第２プラットフォームに属すると判断する。移動通信管理部の出力部は、この判断に基づいて、第２プラットフォームの移動通信データべースを検索して第２端末の位置を取得するように求める要求を出力する。これにより、第２端末の位置確認が行なわれる。
【００３２】
移動通信管理部はまた、任意のプラットフォームにある第２端末からのメッセージを受信して、第２端末の位置登録を行わせる。この場合、エイリアスデータベースを検索することによって、判定部が第２端末の本来の端末ＩＤを求め、第２端末が本来属する第２プラットフォームの移動通信データベースに第２端末の位置登録を行うように求めるメッセージを出力する。
【００３３】
このように、既存の異なるプラットフォーム間に統一的な移動通信管理部（ＵＭＭ：unified mobility manager）を介在させ、エイリアスデータベースを参照することによって、異なるプラットフォーム間でモバイル端末のアドレス変換を行ない、任意のモバイル端末の位置を確認することが可能になる。また、移動通信管理部が任意のプラットフォーム上にある端末から発せられた位置登録用のメッセージを捕獲受信し、エイリアスデータベースに基づいてアドレス変換し、変換されたアドレスに基づいて他プラットフォームの移動通信データベースにアクセスすることにより、任意のモバイル端末の現在位置を、別のプロトコルで管理されている他プラットフォームの移動通信データベースに登録することが可能になる。
【００３４】
各プラットフォームの移動通信データベースは、課金情報、認証情報の少なくとも一方を格納し、移動通信管理部による各プラットフォームの移動通信データベースとのインタラクションを介して、任意の（他プラットフォームの端末をも含む）モバイル端末の位置を検索し、域外にあるモバイル端末の認証、許可、課金を可能にする。
【００３５】
このように、移動通信管理部は、複数のプラットフォーム間に渡って、ひとつのプロトコルから別のプロトコルへとアドレス変換することにより、異なるプラットフォーム間での移動通信を実現するものである。
【００３６】
本発明のその他の特徴、効果は、以下で図面を参照して述べる詳細な記載により、いっそう明確になる。
【００３７】
【発明の実施の形態】
＜第１実施形態＞
図１に、本発明の第１実施形態に係る統一された移動通信ネットワークの構成図を示す。それぞれ異なるプロトコルを有する複数のネットワーク（またはそれに含まれるプラットフォーム）１〜４と、各ネットワークに対応する移動通信データベース５〜９との間に移動通信管理部（あるいはUMM：unified mobility manager）１０が介在する。ネットワーク１はたとえば携帯電話用の通信規約であるセルラープロトコルで管理される携帯電話ネットワークであり、ネットワーク２は、モバイル用のインターネットプロトコルで管理されるモバイルＩＰネットワークである。同様に、ネットワーク３はＤＨＣＰ／ＤＮＳプロトコルを採用する通信ネットワークであり、プラットフォーム４はＳＩＰ（session initiation protocol）を採用する通信ネットワークである。
【００３８】
上述したように、本発明において、ネットワークに単一のプラットフォームが対応してもよいし、複数のプラットフォームが含まれていてもよいが、説明の便宜上、良好な実施形態においてはネットワークとプラットフォームは対応するものとし、ネットワーク１〜４はそれぞれプラットフォーム１〜４と読み替えてもよいこととする。
【００３９】
移動通信管理部（UMM）１０は、この統一移動通信ネットワーク内の任意のプラットフォームで生成され送信される、あるいは受信されるメッセージを、途中で捕獲受信し、後述する方法により、途中受信したメッセージを、それが処理されるべき適切なデータベースへ転送する。
【００４０】
図２は、図１に示す移動通信管理部１０のネットワーク構成を示す図である。図２において、移動通信管理部１０は、MMGWネットワークとして示され、各プラットフォーム１〜４に対応する移動通信管理ゲートウェイ（ＭＭＧＷ）１１〜１４を備える。各移動通信管理ゲートウェイは、プラットフォーム１〜４と、それぞれ対応する移動通信データベース５〜９の間で送受信されるメッセージをモニタリング、すなわち捕獲受信する。各ゲートウェイで受信されたメッセージが、他のプラットフォームの移動通信データベースに宛てられたものであれば、そのメッセージはクロスプラットフォームパス１５を介して、意図された移動通信データベースへ転送される。
【００４１】
クロスプラットフォームパス１５は、現実の伝送媒体としてたとえばインターネットを用いる伝送通路である。この場合、当業界で周知のように、インターネット上を送受信されるメッセージは、通信パケット内にヘッダと情報本体とを有する。クロスプラットフォームパスとしてインターネットを用いることの利点は、トラヒック増大などにより通信に失敗した場合に、中間ノードで通信情報を送受信できる点にある。あるいは、クロスプラットフォームパス１５は、移動通信データベース５〜８と相互接続される物理的な専用ネットワークであってもよい。物理的な専用ネットワークを用いることの利点は、移動通信データベース間のトランザクション（データ送受信）とは無関係な外部トラヒックに影響を受けずに済む点にある。クロスプラットフォームパスは、オペレータ相互の間で機能する構成としてもよいし、各オペレータとの間で個別に機能する構成としてもよい。換言すれば、単一の相互クロスプラットフォームパスとしてもよいし、ネットワークに接続された複数のクロスプラットフォームパスとしてもよい。
【００４２】
図１および２に示すシステムの特徴として、各プラットフォームに対応するエイリアスデータベース２１〜２４を備える。図２の例では、エイリアスデータベース２１〜２４はそれぞれ対応するゲートウェイ（ＭＭＧＷ）１１〜１４に接続されている。エイリアスデータベースは、他のプラットフォーム上のモバイル端末に関する識別情報を格納するデータベースである。既存の技術においては、一般にモバイル端末は、その端末が属するプラットフォームのネイティブプロトコルに基づいて別の端末の存在を確認する。たとえば、携帯端末であればＥ．１６４を用いて他のプラットフォームの端末を呼び出す。この場合、相手先の端末がたとえば他プラットフォームであるＤＨＣＰ／ＤＮＳプラットフォームにあるとすると、対手先の端末のホストネームあるいはドメインネームを、自己が属するセルラーネットワークに与えることはしないという問題を含む。さらに、従来の技術においては、端末は、基本的にその端末の識別子だけを取り扱える設計になっており、携帯端末であれば、ＳＩＰネットワークから送られてきたＳＩＰ ＵＲＬの端末ＩＤに応答できるようには設計されていない。
【００４３】
本発明の移動通信管理部１０におけるエイリアスデータベース２１〜２４は、既存の技術におけるこのような問題点を解決するために設けられている。すなわち、エイリアスデータベース２１〜２４は、他のプラットフォームにあるモバイル端末の識別情報を、自己のホームプラットフォームで使用できるフォーマットで格納する。具体的には、エイリアスデータベースは、他プラットフォームにあるモバイル端末の端末ＩＤを自己のプラットフォーム用のフォーマットに変換した識別名であるエイリアス（別名）と、他のプラットフォームにあるモバイル端末の本来の端末ＩＤと、他のプラットフォームを示す識別子とを互いに関連付けて格納する。プラットフォーム識別子については、端末ＩＤの中に組み込まれてもよい。エイリアスデータベース２１〜２４はさらに、移動通信データベース５〜８の中のどのデータベースが、この遠隔（他プラットフォーム）のモバイル端末に関する情報を格納しているかを特定するルーティング情報を格納してもよい。
【００４４】
セルラープラットフォーム１用のエイリアスデータベース２１に格納されるエントリの例を挙げると、ＤＨＣＰ／ＤＮＳネットワーク３にある端末ＩＤ゛doug.domainname.com”のエイリアスとして、電話番号の形態で（212）556-1234を格納し、モバイルＩＰネットワーク２上で”123.456.78.9”で定義されている端末ＩＤのエイリアスとして、フリーダイヤル番号(800)345-6789を格納する。このように、Ｅ．１６４ネットワーク１にあるモバイル端末は、自己のプラットフォームで使用されている形式（すなわち電話番号の形態）のまま、他プラットフォームにあるモバイル端末に発呼することができる。
【００４５】
エイリアスデータベース２１〜２４のエントリは一般的に、
１）エイリアス（自己プラットフォームの形式での識別子）
２）実アドレス（遠隔(他の)プラットフォームの実際の端末ＩＤ）
３）この遠隔端末をサポートするプラットフォーム（ルーティング情報）
これらのエントリは、たとえば構成の簡単なテーブルとして格納されてもよい。３番目のルーティング情報に関しては、遠隔にある端末ＩＤをサポートするのが単一のネットワークのみである場合には、オプションとして省略してもよい。複数のネットワークがこの端末ＩＤに関する単一のプロトコルを支援しているが、各プラットフォームは個別に経営され操作されている場合は、正しい移動通信データベース５〜８にメッセージを配信するために個別にプラットフォームの識別を行なうのが好ましい。
【００４６】
図２において、移動通信管理ゲートウェイ（ＭＭＧＷ）１１は、セルラープラットフォーム１の移動通信データベース５へ送信、あるいはこのデータベースから供給されるメッセージをモニタリングする。このセルラーネットワーク１上で生成されたメッセージは、まずすべて、このネットワークを介して移動通信データベース５に向けられる。移動通信管理ゲートウェイ１１は、このルートの途中でメッセージを捕獲受信し、このメッセージがセルラーネットワーク１用の移動通信データベース５を指定するものであるかどうかを判断する。メッセージが移動通信データベース５に向けられたものであれば、ゲートウェイ１１はメッセージをデータベース５に配信する。そうでない場合は、ゲートウェイ１１は、メッセージが意図する適切なデータベース６〜８にメッセージを転送する。あるいは、同じセルラーネットワーク１内であっても、別会社によって経営され、あるいは異なる地域で運営されている別バージョンのデータベース５に転送することもありえる。別のデータベースへメッセージを転送する過程において、移動通信管理ゲートウェイは、メッセージが宛てられたデータベースのプロトコルと互換性のある形式にフォーマットし直すこともできる。
【００４７】
図３は、クロスプラットフォーム発呼処理の例を示す。図３の例では、プラットフォームＢの発呼側端末４１は、プラットフォームＡの着呼側端末３１を呼び出そうとしている。発呼側端末４１も着呼側端末３１も、それぞれが本来属するプラットフォームＢおよびＡに位置登録している。この例では、端末４１の（本来の）ネイティブプラットフォームはプラットフォームＢであり、端末３１のネイティブプラットフォームはプラットフォームＡである。したがって、端末４１および３１の位置は、対応する移動通信データベース４２、３２にそれぞれ登録されている。図３のような呼の設定を実現するには、プラットフォームを渡る位置確認が必要となる。呼び出し先の端末の位置確認のために着呼側のデータベースにアクセスする必要を回避するために、すべての端末に関するすべての位置を格納できる中間データベースを設けてもよい。
【００４８】
図３に示すように、プラットフォームBにある発呼側端末４１からプラットフォームAの着呼側端末３１を呼び出す場合、発呼側端末４１は、プラットフォームＢで使われているプロトコルによって着呼側端末３１を識別する。たとえば、プラットフォームＢはＥ．１６４セルラープロトコルを使用するとする。この場合、発呼側端末４１は、電話番号(XXX)YYY-ZZZZをダイヤルすることによって、相手先（着呼側端末）３１を呼び出す。統合移動通信管理部５０のゲートウェイ５２は、発呼側端末４１がダイヤルした電話番号（すなわち位置分析要求）を捕獲受信し、エイリアスデータベース２６を参照する。エイリアスデータベース２６を検索することによって、着呼側端末３１がプラットフォームBの端末であるか否かを判断する。図３に示す例では、着呼側端末３１はプラットフォームBの端末ではないので、エイリアスデータベース２６はゲートウェイ５２に着呼側端末３１に関するエイリアス情報を提示する。ゲートウェイ５２は、エイリアスデータベース２６から与えられた情報に基づき、プラットフォームＢのプロトコルからプラットフォームＡのプロトコルへ変換する。変換後、ゲートウェイ５２は、プラットフォームＡ用のゲートウェイ５１を介して移動通信データベース３２にアクセスすることによって、プラットフォームＡ上の着呼側端末３１の現在位置を確認する（位置確認）。
【００４９】
なお、エイリアスデータベースは、遠隔端末のエイリアスと実アドレス、および必要ならばルーティング情報をたとえばテーブル形式で格納しており、構成が非常に簡単である。このため、良好な実施形態では、ゲートウェイ５２は、まずエイリアスデータベースを参照して、発呼側端末が呼び出そうとしている端末が、他プラットフォームの端末であるか否かを調べることとしている。しかし、まず自己の移動通信データベース４２を検索して呼び出し先の端末が自己のプラットフォームにあるか否かを判断する構成としてもよい。
【００５０】
上述したように、異なるプラットフォームを渡って相手先（着呼側）のネイティブプラットフォームの移動通信データベースにアクセスすることにより、次のような効果が達成される。
【００５１】
（１）着呼側プラットフォームの移動通信データベースに格納されている許可リストを参照することによって、発呼側からの呼（より一般的にはプラットフォームＢからの呼）が許可されたものであるか否かを確認することができる。
【００５２】
（２）複数のルート（配信パス）が存在する場合に、着呼側プラットフォームＡの移動通信データベース３２を用いて着呼側端末３１の位置を確認することによって、ゲートウェイ５２は適切なパスを決定することができる。
【００５３】
（３）課金技術によっては、プラットフォームＡの移動通信データベース３２を用いて着呼側端末に向けられた呼をモニタリングし、課金処理を行なうことができる。また、その呼に関して、移動通信で用いられている公知の方法により、発呼者側に課金することもできる。
【００５４】
図４に示すように、移動通信管理部（UMM）５０により実現されるプラットフォーム間を渡る（クロスプラットフォーム）通信は、プラットフォーム間に位置するプラットフォームゲートウェイ５５によって設定される。プラットフォームゲートウェイ５５は、シグナリングプロトコルを終端させる。「終端」させるというのは、当業界で周知のように、プロトコル処理の機能的な側面をも含むものである。シグナリングの終端例は、たとえば「非同期転送モード通信システム用のマルチメディアネットワークインターフェイス（“Multimedia Network Interface for Asynchronous Transfer Mode Communication System”）」と題された米国特許第5,717,691号に開示されている。シグナリングプロトコル、すなわち回線接続を確立するための信号交換を終端させるとは、たとえば、メッセージのコンテンツを読んで、そのコンテンツにより指定されたことを行なうことを意味する。例として、通信チャネルの設定および切断、ハンドオフ、課金、位置確認および位置登録などがある。シグナリングの終端に関するその他の例は、上記の米国特許を参照されたい。
【００５５】
プラットフォームゲートウェイ５５は、エイリアスデータベース２６および２５からのエイリアス情報を使用して、発呼側端末４１と着呼側端末３１との間にチャネルを設定する。各エイリアスデータベース２６、２５から得たエイリアス情報に基づいて、プラットフォームゲートウェイ５５は、プラットフォームゲートウェイ５５の両側のエンドポイント（終点）を確立する。すなわち、プラットフォームB用のエイリアスデータベース２６を用いて、発呼側端末４１から着呼側端末３１に向けての通信パスが生成され、プラットフォームＡ用のエイリアスデータベース２５を用いて、着呼側端末３１から発呼側端末４１への逆方向の通信パスが生成される。
【００５６】
図４の例では、説明の便宜上、２つのプラットフォームしか描かれていないが、３以上のプラットフォームがある場合でも同様である。この場合、各エイリアス・データベースは、ネイティブプラットフォーム以外のプラットフォームにある端末に関するエイリアス情報を格納し、プラットフォームゲートウェイ５５は、これらのエイリアス・データベースからの情報をもとに、適切なチャネルを設定することができる。
【００５７】
図５は、発呼側端末４１と着呼側端末３１の間の通信例を示す。図５の例では、プラットフォームＢはセルラープロトコル（Ｅ．１６４等）に基づく携帯電話網であり、プラットフォームＢの発呼側端末４１の端末ＩＤは、たとえば(AAA)BBB-CCCCである。一方、ＤＨＣＰ／ＤＮＳプロトコルに基づくプラットフォームＡにある着呼側端末３１の端末ＩＤは、”doug.domainname.com”である。プラットフォームゲートウェイ５５は、プラットフォームＢ用のエイリアス・データベース２６（図４）を調べ、着呼側端末３１のエイリアスが格納されているかどうかを検索する。エイリアス・データベース２６に着呼側端末３１のエイリアスが格納されているということは、着呼側端末３１は、プラットフォームＢ以外の他プラットフォームにあることを意味する。プラットフォームゲートウェイ５５は、エイリアス・データベース２６に格納されている着呼側端末３１のエイリアスである電話番号（XXX）YYY-ZZZZに基づき、発呼側から着呼側に向ける通信パスを生成する。同様に、エイリアス・データベース２５から得られたプラットフォームＡにおける発呼側端末４１のエイリアス”bob.domainname.com”に基づき、着呼側から発呼側への逆チャネルを設定する。
【００５８】
発呼側端末４１からのメッセージ（あるいはメッセージパケット）は、そのヘッダ情報に着呼側端末３１を識別するための情報、すなわち着呼側端末３１の端末ＩＤをプラットフォームＢにおける電話番号としての形態（エイリアス）にした識別情報を含んだ状態で、プラットフォームＢに発信される。このヘッダ情報を含むメッセージは、プラットフォームゲートウェイ５５によってプラットフォームＡへと転送される。この転送プロセスにおいて、ヘッダに含まれるエイリアスである電話番号（XXX）YYY-ZZZZは、着呼側端末３１の本来の端末ＩＤ（実アドレス）”doug.domainname.com”に置き換えられる。変換後の実アドレス、すなわち着呼側端末３１の本来の端末ＩＤに基づいて、メッセージは着呼側端末３１に配信される。
【００５９】
リターンパス（復路）も同様にして設定される。すなわち、エイリアスデータベース２５からのエイリアス情報はプラットフォームゲートウェイ５５に送られる。着呼側端末３１は、ヘッダ情報を有するメッセージ（またはメッセージパケット）を出力する。このヘッダ情報の中には、発呼側端末４１のエイリアスとして、プラットフォームAでの識別名”bob.domainname.com”が含まれている。プラットフォームゲートウェイ５５は、このメッセージパケットを受け取り、ヘッダ情報を発呼側端末４１の実際の端末ＩＤである(AAA)BBB-CCCCに変換し、メッセージを発呼側端末に送信する。
【００６０】
図６は、本発明の良好な実施形態に基づく統合移動通信管理システムを用いたハンドオフの例を示す。着呼側端末３１が移動中である場合、ゾーン間、セクタ間で、ハンドオフと呼ばれる通信中のチャネル切替を行なう必要がある。図６の例で、着呼側端末３１は、プラットフォームA内のひとつのサイトから同じプラットフォーム内の別のサイトへと移動している。着呼側端末３１の移動につれて、その位置をプラットフォームAの移動通信データベース３２に再登録する必要がある（図６において破線の矢印で示す）。着呼側端末３１に宛てられたメッセージはプラットフォームＡの移動通信管理ゲートウェイ５１を通過する。移動通信管理ゲートウェイ５１は、発呼側端末４１からのメッセージ（又はメッセージパケット）をモニタリングして、そのメッセージに移動先を示す適切なロケーションＩＤ（ＬＩＤ）を与える。この着呼側端末３１のロケーションＩＤの変更プロセスは、発呼側端末４１に通知される。
【００６１】
なお、図６では、各プラットフォームのための移動通信管理ゲートウェイ５１および５２と、プラットフォームゲートウェイ５５との間のデータパスを省略してあるが、図４と同様に、他プラットフォームにある着呼側端末３１との間で通信を行なうためのエイリアスデータのやり取りが行なわれていることは言うまでもない。
【００６２】
図７は、本発明の良好な実施形態に基づく統合移動通信管理システムを用いた呼の終端処理の例を示す。通信チャネルが終端されると、プラットフォームゲートウェイ６０は、発呼側端末４１と着呼側端末３１との間の信号パスを終端する制御を行なう。通信チャネルは、プラットフォームＡおよびＢのそれぞれの側で、そのプラットフォーム本来のネイティブプロトコルで切断される。
【００６３】
＜第2実施形態＞
図８は、本発明の第2実施形態に係る統合移動通信管理システムを用いたハンドオフの別の例を示す。図６に示す第1実施形態でのハンドオフの例では、着呼側端末３１が同一プラットフォームＡ内の別のサイトへ移動する際のハンドオフを示していたが、図８では、異なるプラットフォーム間でのハンドオフ、すなわちプラットフォームを渡るローミングを示す。状況によっては、発呼側端末と着呼側端末の間の直接接続ができない場合もあり得る。このような場合、図８に示すように、プラットフォームＢにあるモバイル端末Ａと、プラットフォームＣにあるモバイル端末Ｂは、プラットフォームＡ（たとえばインターネット）を介して通信を行なう。ここでは、通信パスは、２つのプラットフォームゲートウェイ６１および６２を用いて設定される。プラットフォームゲートウェイ６１は、プラットフォームＡとＢとの間のメッセージ（またはメッセージパケット）の交換を行なうために、プラットフォームゲートウェイ６２は、プラットフォームＡとＣとの間のメッセージ交換のために用いられる。
【００６４】
モバイル端末Ｂは、プラットフォームＣからプラットフォームＤへと移動し、今度はプラットフォームゲートウェイ６３がその通信ライン上に必要になってくる。一方、プラットフォームＡとＣをつなぐプラットフォームゲートウェイ６２は、通信チャネルからはずれる。この場合、ひとつの方法として、端末Ａと端末Ｂとの間のプラットフォームゲートウェイ６２を介したそれまでの通信パスを完全に終端させるという方法がある。別の方法は、それまでの通信パスも、通信パスの一部としてそのまま残し、端末ＡとＢのいずれか一方のロケーションＩＤの変化に応じた変更要求にしたがい、通信パスの一部分を変更するものである。後者の場合、端末ＡとＢのいずれか一方のロケーションＩＤの変化に応じてセグメントを変更し、変調を行なう。
【００６５】
なお、発呼時の発呼側端末ＡからＢへの通信チャネルの形成は、まず、プラットフォームＢ上にチャネルを形成し、次にプラットフォームＡ上に、最後に着呼側端末Ｂが位置するプラットフォームＣ上に形成する。
【００６６】
図９は、図８に示したネットワークプラットフォーム間でのハンドオフがどのように実行されるかを示す構成図である。統合移動通信システム（あるいはネットワーク）７０は、各プラットフォームＡ〜Ｄのための移動通信管理ゲートウェイ７２〜７５とを含む移動通信管理部と、エイリアスデータベース７６〜７９と、クロスプラットフォームパス８０を有する。各プラットフォームＡ〜Ｄは、それぞれ対応する移動通信データベース８１〜８４を有する。各プラットフォームの移動通信データベースは、既存の移動通信データベースでよい。
【００６７】
発呼側端末Ａが位置するプラットフォームＢと、着呼側端末Ｂが位置するプラットフォームＣの間には直接のプラットフォームゲートウェイが存在せず、かわらにプラットフォームＡを間に介して、通信チャネルの設定を行なう。着呼側端末ＢのプラットフォームＤへの移動につれて、同じくプラットフォームＡを介し、別のプラットフォームゲートウェイを用いて、新たな通信チャネルを設定する。
【００６８】
ハンドオフを効率的に行なうために、各プラットフォーム間に位置するプラットフォームゲートウェイ６１、６２、６３は、発呼側端末Ａと着呼側端末Ｂの端末ＩＤ、およびこれら端末の各プラットフォームにおけるエイリアスを備えることが望ましい。あるいは、ハンドオフの際に、必要とされるプラットフォームゲートウェイが対応するプラットフォームの移動通信ゲートウェイを介して、エイリアスデータベースを参照することによって、移動先プラットフォームでの着呼側端末Ｂの実アドレスを読み出してもよい。
【００６９】
図８および９に示す例では、発呼側端末Ａと着呼側端末Ｂは、１以上のネイティブプロトコルに基づき、１以上のホームネットワーク（あるいはホームプラットフォーム）に属するものとする。たとえば、発呼側端末Ａは、モバイルＩＰ環境とセルラー（１Ｇ／２Ｇ）環境の双方で機能するデュアルモード／マルチバンド電話機であってもよい。
【００７０】
図１０および１１は、図８および９に示すプラットフォームを渡るハンドオフを実際の端末ＩＤとエイリアスとを用いてどのように行なうかを示す図である。図１０および１１に示す例では、プラットフォームＡは、モバイルＩＰネットワークであり、プラットフォームＢ、Ｃ、Ｄは、たとえばＥ．１６４をサポートするセルラープラットフォームである。発呼側のモバイル端末Ａは、ホームネットワークとしてプラットフォームＢを利用する。着呼側のモバイル端末Ｂは、ホームネットワークとしてプラットフォームＡを利用する。モバイル端末ＡおよびＢの本来の端末ＩＤは、それぞれのホームプラットフォームのプロトコルに基づいて記述されている。
【００７１】
図１０の例では、発呼側のモバイル端末ＡのホームプラットフォームＢにおける端末ＩＤは、(aaa)bbb-ccccである。このモバイル端末Aの他プラットフォームＡにおけるエイリアスは、www.xxx.yyy.zzzであり、プラットフォームCおよびDにおけるエイリアスは、(aaa)bbb-ccccである。プラットフォームが異なってもそこで用いるプロトコルが同一の場合は、ひとつの端末Ａに対して共通のエイリアスが与えられる場合もあり得る。これは、Ｅ．１６４アドレスを指定する複数のデータベース間で単一のエイリアスで通信できるからである。もっとも、必要ならば異なるプラットフォームごとに異なるエイリアスを与えてもよい。
【００７２】
一方、着呼側のモバイル端末ＢのホームプラットフォームＡにおける本来の端末ＩＤはsss.ttt.uuu.vvvである。セルラープラットフォームである他プラットフォームＢ，Ｃ，Ｄでの着呼側端末Ｂのエイリアスは、(ddd)eee-ffffである。上述したように、他プラットフォームにあるモバイル端末のＩＤは、自己のプラットフォームのプロトコル形式に応じたエイリアスに変換され、エイリアスは本来の端末ＩＤとを対応付けて格納される。このようにエイリアスを用いることにより、モバイル端末Ａとモバイル端末Ｂの間に、異なるプラットフォームをわたる通信が可能になる。
【００７３】
図１１に示す例では、異なるプラットフォーム間でハンドオフする場合、発呼側端末Ａが位置するプラットフォームＢと、着呼側端末Ｂが位置するプラットフォームＣの間に直接介在するプラットフォームゲートウェイがない。そこで、破線で示すように、プラットフォームＡを間に介してまず、プラットフォームＢからプラットフォームＣへのチャネルを形成する。着呼側のモバイル端末Ｂが、プラットフォームＣからＤに移動した場合、公知の方法で、移動先における着呼側端末Ｂの位置を確認し、新しいロケーションをプラットフォームＣの移動通信データベースに格納する。ここでのハンドオフ方式はバックワードハンドオフであってよい。発呼側端末Ａと新たなロケーション（プラットフォームＤ）における着呼側端末Ｂとの間に新たに通信パスが形成される前に、プラットフォームＣとの通信路を使って新しいロケーション情報を渡す方式をバックワードハンドオフと呼ぶ。しかし、着呼側端末Ｂの本来の移動通信データベース８２はあくまでもプラットフォームＡにある(図９参照)。
【００７４】
図９に示す、着呼側端末Ｂがそれまで位置していたプラットフォームＣの移動通信ゲートウェイ７４は、着呼側端末ＢからプラットフォームＣ上に発せられたロケーション更新メッセージを途中で捕獲する。このメッセージを調べて、着呼側端末Ｂの本来の移動通信データベースはプラットフォームＡのものであると判断したならば、ゲートウェイ７４は、更新されたロケーションメッセージをプラットフォームＡの移動通信データベース８２に転送する。このやり取りに基づいて、プラットフォームＡ、Ｃ、Ｄのハンドオフプロトコルは、着呼側端末Ｂの移動（位置変更）に適応すべく変更される。
【００７５】
ハンドオフプロトコルの変更は、たとえば、移動通信管理ゲートウェイ７３、７４、７５がメッセージ（又はメッセージパケット）を取り扱う際に、このメッセージのヘッダ情報を変更することによって行なう。この過程で、プラットフォームＢ（セルラーネットワーク）で用いられていたメッセージの送信先アドレス（すなわち着呼側端末Ｂのエイリアス）は、モバイルＩＰネットワークであるプラットフォームＡのＩＰアドレスに書き換えられ、プラットフォームゲートウェイ６１と移動先のロケーションとの間に新たな通信パスが形成される。プラットフォームＡ用のエイリアスデータベース７７は、特定のロケーションへのクロスプラットフォーム通信チャネルを設定するのに、どのプラットフォームゲートウェイが望ましいかを示すルーティング情報を含んでもよい。
【００７６】
＜第３実施形態＞
図１２は、本発明の第３実施形態に係る統合移動通信管理部９１の構成図である。統合移動通信管理部９１に、ネットワーク（あるいはプラットフォーム）９０と、このネットワークの移動通信データベース９８が接続されている。統合移動通信管理部９１は、移動通信ゲートウェイ９２を有する。移動通信ゲートウェイ９２は、受信部９３と、判定部９４と、出力部９５とを備える。判定部９４にはエイリアス・データベース９７が接続されている。
【００７７】
受信部９３は、ネットワーク９０およびこのネットワーク上にあるモバイル端末からメッセージを受信する。受信部９３は、移動通信データベース９８へ送られるメッセージを途中で捕獲して、判定部９４へ送る。判定部９４はメッセージを調べ、エイリアス・データベース９７に格納された情報に基づき、このメッセージがクロスプラットフォームパス９６を介して他プラットフォームの移動通信データベースに送られるべきか否かを判断する。エイリアス・データベース９７は、上述したように、他プラットフォームにある端末の本来の端末ＩＤと、この端末ＩＤをネットワーク９０のプロトコル形式に変換したエイリアスとを、たとえばテーブルの形式で格納する。このエイリアス・データベース９７に相手側端末のエイリアスが格納されている場合は、この相手側端末は他プラットフォームの端末であり、メッセージの転送が必要であることを意味する。エイリアス・データベースにエイリアスがない場合は、端末は自己のプラットフォームの端末であることを意味する。
【００７８】
判定部９４は、エイリアスデータベース９７の参照の結果、メッセージが他プラットフォームへの転送を必要とすると判断した場合に、このメッセージに適切なエイリアス情報を添付して出力部９５に供給する。出力部９５は、クロスプラットフォームパス９６を介して他プラットフォームの移動通信データベースにメッセージを転送する。一方、エイリアスデータベース９７の参照の結果、メッセージの転送が必要ない、すなわち、端末が自己のホームプラットフォームにあると判断された場合は、出力部９５に対して、自己のプラットフォームの移動通信データベース９８にメッセージを送るよう要求する。
【００７９】
図１３は、第１実施形態〜第３実施形態に共通する統合移動通信管理部のエイリアス処理フローを示す図である。まずステップＳ１３０１で、第１プラットフォームに位置するモバイル端末Ａの端末ＩＤとロケーションＩＤとを、第１プラットフォームの移動通信データベースに格納する。次に、ステップＳ１３０３で、この端末ＩＤのエイリアスを、他のプラットフォーム（１以上）のエイリアスデータベースに、他プラットフォームのプロトコルと互換性のある形式で格納する。一方で、他プラットフォームの端末ＩＤのエイリアスを、第１プラットフォームのエイリアスデータベースに、第１プラットフォームのプロトコルと互換性のある形式で格納する。
【００８０】
次に、ステップＳ１３０５で、移動通信管理部が第２プラットフォームのモバイル端末Ｂに宛てられたメッセージを、端末Ｂのエイリアスの下に受信する。ステップＳ１３０７で、移動通信管理部は、エイリアスに基づいて対応するエイリアスデータベースを検索し、モバイル端末Ｂの本来の端末ＩＤを検索する。最後にステップＳ１３０９で、検索した端末ＩＤとメッセージとを関連付けて、第２プラットフォームへ転送する。
【００８１】
図１４は、移動通信管理部の位置確認処理を示すフローチャートである。モバイル端末Ａからモバイル端末Ｂへとメッセージが送られることとする。モバイル端末Ａのホームプラットフォームは第１プラットフォームであるが、モバイル端末Ｂのプラットフォームはまだわかっていないものとする。
【００８２】
まず、ステップＳ１４０１で、移動通信管理ゲートウェイが、モバイル端末Ａからモバイル端末Ｂへのメッセージを途中で捕獲受信する。ステップＳ１４０３で、移動通信ゲートウェイはメッセージをチェックし、メッセージ中に含まれる相手先識別子が、モバイル端末Ａのプラットフォーム用のエイリアスデータベースに登録されているか否かを判断する。相手先識別子がエイリアスデータベースにあれば（ステップＳ１４０３でＹＥＳ）、ステップＳ１４０７に進み、移動通信管理ゲートウェイは、モバイル端末Ｂのロケーションを、第２プラットフォーム（エイリアスデータベースでモバイル端末Ｂの端末ＩＤとともに、ホームプラットフォームとして検索されている）の移動通信データベースで検索する。相手先識別子がエイリアスデータベースにない場合は（ステップＳ１４０３でＮＯ）、モバイル端末Ｂはモバイル端末Ａと同じ第１プラットフォームにあることを意味し、ステップＳ１４０５で、移動通信管理ゲートウェイはモバイル端末Ｂの現在位置を第１プラットフォームの移動通信データベースで検索する。
【００８３】
図１５は、移動通信管理部の位置登録の処理フローである。まず、ステップＳ１５０１で、移動通信管理ゲートウェイは、第１プラットフォームにあるモバイル端末Ｂからのメッセージを、この第１プラットフォームの移動通信データベースへのメッセージとして捕獲受信する。ステップＳ１５０３で、移動通信管理ゲートウェイは、メッセージ中に含まれる相手先識別子（すなわちエイリアス）が第１プラットフォーム用のエイリアスデータベースにあるかどうかを判断する。エイリアスが第１プラットフォーム用のエイリアスデータベースにある場合は（ステップＳ１５０３でＹＥＳ）、ステップＳ１５０７へ進み、メッセージを第２プラットフォームの移動通信データベースに転送する。相手先エイリアスが第１プラットフォーム用のエイリアスデータベース中にない場合は（ステップＳ１５０３でＮＯ）、ステップＳ１５０５で、メッセージを第１プラットフォームの移動通信データベースに供給する。
【００８４】
以上、良好な実施形態に基づいて本発明を述べてきたが、本発明はこれらの実施形態に限定されず、請求項に特定される本発明の範囲内で多様な変形が可能である。たとえば、実施形態においては、移動通信管理ゲートウェイはまず、エイリアスデータベースを参照して、メッセージを他プラットフォームの移動通信データベースへ転送すべきか否かを判断しているが、これは、エイリアスデータベースの構造自体が非常に簡単であり、検索時間も短いからである。しかし、本発明はこの構成例には限定されず、たとえば、先に自己のプラットフォームの移動通信データベースを参照し、そこにデータがない場合に、エイリアスデータベースを参照する手順としてもよい。
【００８５】
【発明の効果】
本発明によれば、それぞれ異なる通信プロトコルを有する複数のプラットフォーム間で統合された移動通信が可能になる。
【００８６】
また、各プラットフォームで用いられている既存の移動通信データベースをほとんどそのまま利用し、簡単な構成のエイリアスデータベースを設けることにより、プラットフォーム間を渡る移動通信が容易に実現される。
【図面の簡単な説明】
【図１】本発明の一実施形態による複数プラットフォーム間を渡る移動通信システムの概略構成図である。
【図２】図１のシステムにおける統一的な移動通信管理（ＵＭＭ）ネットワークの構成を示す図である。
【図３】本発明の統合移動通信管理システムを介して行われる異なるプラットフォーム間での通信操作の流れを示す図である。
【図４】本発明の統合移動通信管理システムによる呼の設定（通信チャネルの設定）の一例を示す図である。
【図５】本発明の統合移動通信管理システムにおける、各端末の端末ＩＤとエイリアスを用いた通信動作の一例を示す図である。
【図６】本発明の統合移動通信管理システムにおける、ハンドオフの一例を示す図である。
【図７】本発明の統合移動通信管理システムにおける呼の終了の一例を示す図である。
【図８】本発明の統合移動通信管理システムにおける複数プラットフォーム間でのハンドオフの別の例を示す図である。
【図９】図８に示す複数のプラットフォーム間におけるハンドオフを実行する機能構成図である。
【図１０】本発明の統合移動通信管理システムにおけるクロスプラットフォーム・ハンドオフにおいて、各プラットフォームでの端末ＩDとエイリアスの一例を示す図である。
【図１１】本発明の統合移動通信管理システムにおけるクロスプラットフォーム・ハンドオフ動作の一例を示す図である。
【図１２】本発明の統合移動通信管理システムにおける通信管理ゲートウエイの内部構成図である。
【図１３】本発明の端末ＩＤとエイリアスを用いた統合移動通信管理方法のプロセスフローを示す図である。
【図１４】本発明の統合移動通信管理システムにおいて、エイリアスデータベースに基づくモバイル端末の位置登録処理のフローチャートである。
【図１５】本発明の統合移動通信管理システムにおいて、エイリアスデータベースに基づく位置確認処理のフローチャートである。
【図１６】従来のそれぞれ独立したプラットフォームと、各プラットフォームごとに用いられる移動通信データベースを示す図である。
【図１７】従来の移動通信ネットワークにおける４層アーキテクチャを示す図である。
【図１８】従来の異なるプラットフォーム間における固定通信ネットワークを示す図である。
【図１９】従来のＩＰ対応機能を有するモバイル端末専用の移動通信ネットワークを示す図である。
【符号の説明】
１、２，３，４，９０ 通信プラットフォーム
５，６，７，８、３２、４２，８１〜８４、９８ 移動通信データベース
１０、５０ 統合移動通信管理部
１１〜１４，５１，５２、７２〜７５、９２ 移動通信管理ゲートウェイ
１５、８０、９６ クロスプラットフォームパス
２１〜２４、２５，２６、７６〜７９、９７ エイリアス・データベース
３１，４１ モバイル端末
５５、５６、６１〜６３ プラットフォーム・ゲートウェイ
７０、９１ ＭＭＧＷネットワーク
９３ 受信部
９４ 判定部
９５ 出力部
Claims (19)
- 複数のプラットフォーム間を渡る統一的なネットワーク通信路を確立するシステムであって、
第１プロトコルを用いて第１モバイル端末にサービスを提供し、前記第１モバイル端末の端末ＩＤとロケーションＩＤとを関連付けて格納する第１の移動通信データベースを有する第１の通信プラットフォームと、
第２プロトコルを用いて第２モバイル端末にサービスを提供し、前記第２モバイル端末の端末ＩＤとロケーションＩＤとを関連付けて格納する第２の移動通信データベースを有する第２の通信プラットフォームと、
前記第２モバイル端末の端末ＩＤを、前記第１プロトコルと互換性のある形式のエイリアスとして、前記第２モバイル端末の端末ＩＤと関連付けて格納する第１のエイリアス・データベースと、
前記第１モバイル端末の端末ＩＤを、前記第２プロトコルと互換性のある形式のエイリアスとして、前記第１モバイル端末の端末ＩＤと関連付けて格納する第２のエイリアス・データベースと、
前記第１および第２の通信プラットフォームとの間に接続され、第１のメッセージの送信先が前記第１のエイリアス・データベースに登録されているか否か判断して、前記第１のメッセージの送信先が前記第１のエイリアス・データベースに登録されている場合に前記第１の通信プラットフォームから前記第２の通信プラットフォームへ前記第１のメッセージを転送し、第２のメッセージの送信先が前記第２のエイリアス・データベースに登録されているか否か判断して、前記第２のメッセージの送信先が前記第２のエイリアス・データベースに登録されている場合に前記第２の通信プラットフォームから前記第１の通信プラットフォームへ前記第２のメッセージを転送する移動通信管理部と、
を備えることを特徴とするプラットフォーム間ネットワーク通信システム。 - 第３のプロトコルを用いて第３モバイル端末にサービスを提供し、前記第３モバイル端末の端末ＩＤを格納する第３の移動通信データベースを有する第３の通信プラットフォームをさらに含み、
前記第３モバイル端末の端末ＩＤは、前記第１プロトコルと互換性のある形式のエイリアスとして、当該端末ＩＤと関連付けて前記第１のエイリアス・データベースに格納され、かつ、前記第２プロトコルと互換性のある形式のエイリアスとして、前記端末ＩＤと関連付けて前記第２のエイリアス・データベースに格納されることを特徴とする請求項１に記載のプラットフォーム間ネットワーク通信システム。 - 前記移動通信管理部は、前記第１モバイル端末から、前記第２モバイル端末の位置情報を含むメッセージを受信し、前記第１のエイリアス・データベースを検索した検索結果に基づいて、前記第２の移動通信データベースを参照して前記第２モバイル端末の現在位置を確認することを特徴とする請求項１に記載のプラットフォーム間ネットワーク通信システム。
- 前記移動通信管理部は、前記第１のモバイル端末から、前記第２モバイル端末のエイリアスが含まれるメッセージを受信し、前記第１のエイリアス・データベースを検索して前記第２のモバイル端末の端末ＩＤを獲得し、獲得した端末ＩＤを用いて前記第２の移動通信データベースから前記第２モバイル端末の現在位置を検索することを特徴とする請求項１に記載のプラットフォーム間ネットワーク通信システム。
- 前記移動通信管理部は、前記第１のエイリアス・データベースを検索して、前記第１のモバイル端末から第２のモバイル端末への通信路を設定するゲートウェイをさらに含むことを特徴とする請求項４に記載のプラットフォーム間ネットワーク通信システム。
- 前記移動通信管理部のゲートウェイは、前記第２のエイリアス・データベースを参照して、前記第２モバイル端末から第１モバイル端末への反対方向の通信路を設定することを特徴とする請求項５に記載のプラットフォーム間ネットワーク通信システム。
- 前記移動通信管理部は、前記第１の通信プラットフォームに位置する第２のモバイル端末から、前記第２モバイル端末のエイリアスを含むメッセージを受信し、前記第１のエイリアス・データベースを検索して前記第２モバイル端末の端末ＩＤを取得し、取得した端末ＩＤに基づき、前記第２モバイル端末の現在位置を前記第２プラットフォームの移動通信データベースに登録することを特徴とする請求項１に記載のプラットフォーム間ネットワーク通信システム。
- 前記第２プラットフォームの第２の移動通信データベースは、課金情報と認証情報のうちの少なくとも一方をさらに格納することを特徴とする請求項１に記載のプラットフォーム間ネットワーク通信システム。
- 第１モバイル端末にサービスを提供する第１の通信プラットフォームと、第２モバイル端末にサービスを提供する第２の通信プラットフォームの間に位置するコンピュータに用いられ、
前記第１および第２モバイル端末の端末ＩＤを格納する第１データ部と、
前記第２モバイル端末の端末ＩＤを、前記第１の通信プラットフォームで用いられる端末ＩＤと互換性のある形式のエイリアスとして、前記第１データ部と関連付けて格納し、前記第１モバイル端末の端末ＩＤを、前記第２の通信プラットフォームで用いられる端末ＩＤと互換性のある形式のエイリアスとして、前記第１データ部と関連付けて格納する第２データ部と、
を含むデータ構造を有し、
前記第１データ部は、前記第１の通信プラットフォームから送信される第１のメッセージに含まれる前記第２モバイル端末のエイリアスを検索して、検索結果に基づいて前記第１の通信プラットフォームから前記第２の通信プラットフォームへ前記第１のメッセージを転送し、前記第２の通信プラットフォームから送信される第２のメッセージに含まれる前記第１モバイル端末のエイリアスを検索して、検索結果に基づいて前記第２の通信プラットフォームから前記第１の通信プラットフォームへ前記第２のメッセージを転送するために使用されることを特徴とするコンピュータ読み取り可能の記録媒体。 - 前記端末ＩＤに関するメッセージを配信するルート情報を格納する第３データ部をさらに含むことを特徴とする請求項９に記載の記録媒体。
- 第１プラットフォームから送られてきた第１モバイル端末の端末ＩＤとロケーションＩＤとを、第１の移動通信データベースに格納するステップと、
第２プラットフォームに位置する第２モバイル端末の端末ＩＤとロケーションＩＤとを第２の移動通信データベースに格納するステップと、
前記第２モバイル端末の端末ＩＤのエイリアスを、前記第１プラットフォームのプロトコルと互換性のある形式で第１のエイリアス・データベースに格納するステップと、
前記第１モバイル端末の端末ＩＤのエイリアスを、前記第２プラットフォームのプロトコルと互換性のある形式で第２エイリアス・データベースに格納するステップと、
前記第１モバイル端末から、前記第２モバイル端末のエイリアスに宛てられた第１のメッセージを受信し、前記第２モバイル端末から、前記第１モバイル端末のエイリアスに宛てられた第２のメッセージを受信するステップと、
前記第２モバイル端末のエイリアスと端末ＩＤとを前記第１エイリアス・データベースで検索し、前記第１モバイル端末のエイリアスと端末ＩＤとを前記第２エイリアス・データベースで検索するステップと、
前記第２モバイル端末の端末ＩＤと前記第１のメッセージとを関連付けて、前記第１のメッセージを前記第２プラットフォームに転送し、前記第１モバイル端末の端末ＩＤと前記第２のメッセージとを関連付けて、前記第２のメッセージを前記第１のプラットフォームに転送するステップとを含むプラットフォーム間の通信方法。 - 第１の移動通信データベース及び第１のエイリアス・データベースを有する第１の通信プラットフォームと第２の移動通信データベース及び第２のエイリアス・データベースを有する第２の通信プラットフォームとの間に位置する移動通信管理装置であって、
前記第１の通信プラットフォームに位置する第１モバイル端末から送信され、前記第１のモバイル端末と任意の第２モバイル端末との間の通信に用いられるメッセージを受信する受信部と、
前記受信部で受信されたメッセージを調べて、前記第２モバイル端末が前記第１の通信プラットフォームからサービスの提供を受けているのか、前記第２の通信プラットフォームからサービスの提供を受けているのかを判断する判断部と、
前記第２モバイル端末が前記第２の通信プラットフォームからサービスの提供を受けていると判断された場合に、前記第２の通信プラットフォームに対応する移動通信データベースを検索して前記第２モバイル端末のロケーションを獲得するように求めるメッセージを出力する出力部とを備え、
前記判断部は、前記メッセージに含まれる前記第２モバイル端末の端末ＩＤが、前記第１の通信プラットフォームに関連する第１のエイリアス・データベースに登録されている場合に、前記第２モバイル端末が第２の通信プラットフォームからサービスの提供を受けていると判断し、前記第１のエイリアス・データベースは、前記第２モバイル端末の端末ＩＤと、この端末ＩＤのエイリアスとを関連付けて格納し、
前記出力部は、前記第１のエイリアス・データベースから得られた前記第２モバイル端末の端末ＩＤを用いて、前記メッセージを出力することを特徴とする移動通信管理装置。 - 第１の移動通信データベースを有し、第１モバイル端末にサービスを提供する第１の通信プラットフォームと第２の移動通信データベースを有し、第２モバイル端末にサービスを提供する第２の通信プラットフォームとの間に位置する移動通信管理装置であって、
前記第１モバイル端末から前記第２モバイル端末へ宛てられたメッセージを受信する受信部と、
前記受信部で受信されたメッセージを調べて、前記第１の通信プラットフォームの第１のエイリアス・データベースを検索し、前記モバイル端末が前記第１の通信プラットフォームからサービスの提供を受けているのか、前記第２の通信プラットフォームからサービスの提供を受けているのかを判断する判断部と、
前記第２モバイル端末が前記第２の通信プラットフォームからサービスの提供を受けていると判断された場合に、前記第２の移動通信データベースに、前記第２モバイル端末の位置登録を行なうことを要求するメッセージを出力する出力部とを備える移動通信管理装置。 - 第１の通信プラットフォームと第２の通信プラットフォームとを渡ってモバイル端末の位置を確認する方法であって、
前記第１の通信プラットフォームに位置する第１モバイル端末から、任意の第２モバイル端末へ宛てられたメッセージを捕獲受信するステップと、
複数のモバイル端末の端末ＩＤと、これら端末ＩＤに対応するエイリアスとを関連付けて格納するエイリアス・データベースを参照して、前記受信されたメッセージに含まれる前記第２モバイル端末の端末ＩＤが、前記第２モバイル端末のエイリアスとして登録されているかを検索し、前記第２モバイル端末のエイリアスとして登録されている場合に、前記第２モバイル端末は前記第２の通信プラットフォームからサービスの提供を受けていると判断するステップと、
前記エイリアス・データベースで検索された前記第２モバイル端末の端末ＩＤに基づき、前記第２の通信プラットフォームの移動通信データベースを検索して前記第２モバイル端末のロケーションを獲得するステップとを含むモバイル端末の位置確認方法。 - 受信されたメッセージに含まれる前記第２モバイル端末の識別子が前記エイリアス・データベースに登録されていない場合に、前記第２モバイル端末は前記第１の通信プラットフォームからサービスの提供を受けていると判断するステップと、
前記第１の通信プラットフォームの移動通信データベースを検索して、前記第２モバイル端末のロケーションを獲得するステップとをさらに含むことを特徴とする請求項１４に記載のモバイル端末の位置確認方法。 - 第１の通信プラットフォームと第２の通信プラットフォームとを渡るモバイル端末の位置を登録する方法であって、
前記第１の通信プラットフォームに位置するモバイル端末から発せられ、このモバイル端末の位置登録のために用いられるメッセージを捕獲受信するステップと、
複数のモバイル端末の端末ＩＤと、これらの端末ＩＤに対応するエイリアスとを関連付けて格納するエイリアス・データベースを参照して、前記受信されたメッセージに含まれる前記モバイル端末の端末ＩＤがエイリアスとして登録されているかどうかを検索し、エイリアスとして登録されている場合に、前記モバイル端末は前記第２の通信プラットフォームからサービスの提供を受けているものと判断するステップと、
前記エイリアス・データベースで検索された前記モバイル端末の端末ＩＤに基づいて、前記第２の通信プラットフォームの移動通信データベースに前記メッセージを転送するステップとを含むモバイル端末の位置登録方法。 - 受信されたメッセージに含まれる前記モバイル端末の端末ＩＤが前記エイリアス・データベースに登録されていない場合に、前記モバイル端末は前記第１の通信プラットフォームからサービスの提供を受けていると判断するステップと、
前記モバイル端末の端末ＩＤに基づいて、前記第１の通信プラットフォームの移動通信データベースに前記メッセージを転送するステップ
とをさらに含むことを特徴とする請求項１６に記載のモバイル端末の位置登録方法。 - 第１モバイル端末にサービスを提供する第１の通信プラットフォームと、第２モバイル端末にサービスを提供する第２の通信プラットフォームの間に位置するコンピュータに用いられ、
前記第１および第２モバイル端末の端末ＩＤを格納する第１データ部と、
前記第２モバイル端の端末ＩＤを、前記第１の通信プラットフォームで用いられる端末ＩＤと互換性のある形式のエイリアスとして、前記第１データ部と関連付けて格納し、前記第１モバイル端の端末ＩＤを、前記第２の通信プラットフォームで用いられる端末ＩＤと互換性のある形式のエイリアスとして、前記第１データ部と関連付けて格納する第２データ部と、
を含むデータ構造を有し、
前記第１データ部は、前記第１の通信プラットフォームから送信される第１のメッセージに含まれる前記第２モバイル端末のエイリアスを検索して、検索結果に基づいて前記第１の通信プラットフォームから前記第２の通信プラットフォームへ前記第１のメッセージを転送し、前記第２の通信プラットフォームから送信される第２のメッセージに含まれる前記第１モバイル端末のエイリアスを検索して、検索結果に基づいて前記第２の通信プラットフォームから前記第１の通信プラットフォームへ前記第２のメッセージを転送するために使用されることを特徴とするプログラム。 - 複数のプラットフォーム間を渡る統一的なネットワーク通信路を確立するシステムであって、
第１プロトコルを用いて第１モバイル端末にサービスを提供し、前記第１モバイル端末の端末ＩＤとロケーションＩＤとを関連付けて格納する第１の移動通信データベースを有する第１の通信プラットフォームと、
第２プロトコルを用いて第２モバイル端末にサービスを提供し、前記第２モバイル端末の端末ＩＤとロケーションＩＤとを関連付けて格納する第２の移動通信データベースを有する第２の通信プラットフォームと、
前記第１モバイル端末の端末ＩＤを、前記第２プロトコルと互換性のある形式のエイリアスとして格納するエイリアス・データベースと、
メッセージの送信先が前記エイリアス・データベースに登録されているか否か判断して、前記メッセージの送信先が前記エイリアス・データベースに登録されている場合に前記第２モバイル端末から第１モバイル端末へ前記メッセージを転送する移動通信管理部と、
を備えることを特徴とするプラットフォーム間ネットワーク通信システム。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US09/504106 | 2000-02-14 | ||
| US09/504,106 US6654607B1 (en) | 2000-02-14 | 2000-02-14 | Method and apparatus for enabling and monitoring mobile communication across platforms |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2001285372A JP2001285372A (ja) | 2001-10-12 |
| JP3699900B2 true JP3699900B2 (ja) | 2005-09-28 |
Family
ID=24004866
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001037564A Expired - Fee Related JP3699900B2 (ja) | 2000-02-14 | 2001-02-14 | 複数のプラットフォーム間を渡る統合移動通信システムおよび方法 |
Country Status (4)
| Country | Link |
|---|---|
| US (1) | US6654607B1 (ja) |
| EP (1) | EP1126738B1 (ja) |
| JP (1) | JP3699900B2 (ja) |
| DE (1) | DE60129365T2 (ja) |
Families Citing this family (60)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| AU6915400A (en) * | 1999-08-16 | 2001-03-19 | Z-Force Corporation | System of reusable software parts and methods of use |
| US7346022B1 (en) * | 1999-09-28 | 2008-03-18 | At&T Corporation | H.323 user, service and service provider mobility framework for the multimedia intelligent networking |
| US6775267B1 (en) | 1999-12-30 | 2004-08-10 | At&T Corp | Method for billing IP broadband subscribers |
| US6826173B1 (en) | 1999-12-30 | 2004-11-30 | At&T Corp. | Enhanced subscriber IP alerting |
| US6937713B1 (en) | 1999-12-30 | 2005-08-30 | At&T Corp. | IP call forward profile |
| US7180889B1 (en) | 1999-12-30 | 2007-02-20 | At&T Corp. | Personal control of address assignment and greeting options for multiple BRG ports |
| JP3688547B2 (ja) * | 2000-02-15 | 2005-08-31 | 株式会社東芝 | 位置識別子管理装置及び移動計算機並びに位置識別子管理方法及び位置識別子処理方法 |
| US7554967B1 (en) * | 2000-03-30 | 2009-06-30 | Alcatel-Lucent Usa Inc. | Transient tunneling for dynamic home addressing on mobile hosts |
| US7240100B1 (en) * | 2000-04-14 | 2007-07-03 | Akamai Technologies, Inc. | Content delivery network (CDN) content server request handling mechanism with metadata framework support |
| US7130612B1 (en) | 2000-05-30 | 2006-10-31 | At&T Corp. | System and method for providing wireless services within a wireless local area network |
| AU2001266295A1 (en) * | 2000-06-19 | 2002-01-02 | Mobilespear Ltd. | System and method for object access through an access device |
| US8041817B2 (en) | 2000-06-30 | 2011-10-18 | At&T Intellectual Property I, Lp | Anonymous location service for wireless networks |
| JP2002064851A (ja) * | 2000-08-18 | 2002-02-28 | Nec Corp | 移動通信システム及び移動通信端末の在圏位置情報整合方法 |
| FI20001877A (fi) * | 2000-08-25 | 2002-02-26 | Nokia Networks Oy | Yhteisvastuun vaihtaminen langattomassa tietoliikennejärjestelmässä |
| US6804196B1 (en) * | 2000-11-20 | 2004-10-12 | Nortel Networks Limited | Determining traffic information in a communications network |
| US7085555B2 (en) | 2000-12-19 | 2006-08-01 | Bellsouth Intellectual Property Corporation | Location blocking service from a web advertiser |
| US7224978B2 (en) | 2000-12-19 | 2007-05-29 | Bellsouth Intellectual Property Corporation | Location blocking service from a wireless service provider |
| US7245925B2 (en) | 2000-12-19 | 2007-07-17 | At&T Intellectual Property, Inc. | System and method for using location information to execute an action |
| US7181225B1 (en) | 2000-12-19 | 2007-02-20 | Bellsouth Intellectual Property Corporation | System and method for surveying wireless device users by location |
| US7110749B2 (en) | 2000-12-19 | 2006-09-19 | Bellsouth Intellectual Property Corporation | Identity blocking service from a wireless service provider |
| US7428411B2 (en) | 2000-12-19 | 2008-09-23 | At&T Delaware Intellectual Property, Inc. | Location-based security rules |
| US7116977B1 (en) | 2000-12-19 | 2006-10-03 | Bellsouth Intellectual Property Corporation | System and method for using location information to execute an action |
| US7130630B1 (en) | 2000-12-19 | 2006-10-31 | Bellsouth Intellectual Property Corporation | Location query service for wireless networks |
| US6940835B2 (en) * | 2000-12-28 | 2005-09-06 | Nortel Networks Limited | Application-level mobility support in communications network |
| US7085808B2 (en) * | 2001-06-07 | 2006-08-01 | Nokia Corporation | Method for distinguishing clients in a communication system, a communication system; and a communication device |
| US20030028599A1 (en) * | 2001-06-19 | 2003-02-06 | Kolsky Amir D. | Method and system for a communication scheme over heterogeneous networks |
| US20030003894A1 (en) * | 2001-06-27 | 2003-01-02 | Kumar Anil K. | Developing mobile unit based estimates of metered packet charges |
| ES2183728B1 (es) * | 2001-07-16 | 2004-06-16 | Airtel Movil, S.A. | Sistema de nombramientos de dominios (dns) para acceso a bases de datos. |
| US7173925B1 (en) * | 2001-07-18 | 2007-02-06 | Cisco Technology, Inc. | Method and system of control signaling for a wireless access network |
| TW535066B (en) * | 2001-09-14 | 2003-06-01 | Inventec Tomorrow Studio Corp | Method for sharing data between cable platform and wireless platform and system thereof |
| US7003293B2 (en) * | 2001-10-23 | 2006-02-21 | The Boeing Company | Network system having multiple subnets for a mobile platform |
| KR100878077B1 (ko) * | 2001-12-24 | 2009-01-13 | 에스케이 텔레콤주식회사 | 고정포트 할당을 통한 포트별 무선 애플리케이션 서비스가능한 무선 데이터 서비스 시스템 및 방법 |
| KR100466928B1 (ko) * | 2001-12-29 | 2005-01-24 | 에스케이 텔레콤주식회사 | 듀얼 스텍 이동 통신 시스템 |
| EP1469694A4 (en) | 2002-01-17 | 2006-12-13 | Fujitsu Ltd | MOBILE NETWORK SYSTEM |
| US6970703B2 (en) * | 2002-01-23 | 2005-11-29 | Motorola, Inc. | Integrated personal communications system and method |
| US8432893B2 (en) | 2002-03-26 | 2013-04-30 | Interdigital Technology Corporation | RLAN wireless telecommunication system with RAN IP gateway and methods |
| US7505431B2 (en) | 2002-03-26 | 2009-03-17 | Interdigital Technology Corporation | RLAN wireless telecommunication system with RAN IP gateway and methods |
| US7406068B2 (en) | 2002-03-26 | 2008-07-29 | Interdigital Technology Corporation | TDD-RLAN wireless telecommunication system with RAN IP gateway and methods |
| US7489672B2 (en) | 2002-03-26 | 2009-02-10 | Interdigital Technology Corp. | RLAN wireless telecommunication system with RAN IP gateway and methods |
| US7394795B2 (en) | 2002-03-26 | 2008-07-01 | Interdigital Technology Corporation | RLAN wireless telecommunication system with RAN IP gateway and methods |
| KR20030089364A (ko) * | 2002-05-17 | 2003-11-21 | 주식회사 로커스 | 이동통신망에서의 무선 인터넷 서비스 통합 방법 및액세스 게이트웨이 시스템 |
| US7305429B2 (en) * | 2002-06-10 | 2007-12-04 | Utstarcom, Inc. | Method and apparatus for global server load balancing |
| US20040122976A1 (en) * | 2002-10-24 | 2004-06-24 | Ashutosh Dutta | Integrated mobility management |
| FR2846841B1 (fr) * | 2002-10-31 | 2005-02-18 | Orange France Sa | Systeme et procede de gestion d'acces d'un reseau de communication a un terminal mobile |
| KR100513863B1 (ko) * | 2003-04-29 | 2005-09-09 | 삼성전자주식회사 | 호스트의 이동성을 지원할 수 있는 무선 근거리 네트워크시스템 및 그의 동작방법 |
| JP4616622B2 (ja) * | 2003-12-16 | 2011-01-19 | 株式会社リコー | 通信装置、通信制御方法、通信制御プログラム及び記録媒体 |
| US7493124B2 (en) * | 2004-03-15 | 2009-02-17 | Motorola, Inc. | Method and apparatus for updating information within a communication system |
| CA2563294A1 (en) * | 2004-04-09 | 2005-10-27 | Siemens Medical Solutions Health Services Corporation | A system for managing operating sessions of an executable application |
| US7937084B2 (en) | 2005-03-14 | 2011-05-03 | Mitsubishi Electric Corporation | Communication network system and mobile terminal |
| KR100641198B1 (ko) | 2005-04-14 | 2006-11-06 | 엘지전자 주식회사 | 듀얼 ｅｆｓ를 구비한 이동 통신 단말기 및 이를 이용한플랫폼 제공 방법 |
| US20060274743A1 (en) | 2005-06-06 | 2006-12-07 | Alper Yegin | System and method for a mobile device to learn information about the access networks within its neighborhood |
| JP4840799B2 (ja) * | 2005-10-20 | 2011-12-21 | 義隆 中山 | 異社間の携帯電話通信システム |
| DE102005050937A1 (de) * | 2005-10-21 | 2007-05-03 | Vodafone Holding Gmbh | Austausch von Informationen in einem Kommunikationssystem |
| US7587197B2 (en) * | 2006-03-21 | 2009-09-08 | Sony Ericsson Mobile Communications Ab | Method and system for maintaining anonymity of a mobile radio terminal |
| US20070258436A1 (en) * | 2006-05-05 | 2007-11-08 | Kulkarni Narayan A | Measurement data record method for detecting hybrid mobile tune away |
| US7707313B2 (en) * | 2006-08-14 | 2010-04-27 | Motorola, Inc. | System and method for routing and domain name system support of a mobile node |
| CN101170572A (zh) * | 2006-10-23 | 2008-04-30 | 日电（中国）有限公司 | 基于p2p sip技术实现的多媒体网络通信系统 |
| US20090202062A1 (en) * | 2008-02-12 | 2009-08-13 | Chazon Stein | System and Method for Communication |
| US20090202048A1 (en) * | 2008-02-12 | 2009-08-13 | Chazon Stein | System and Method for Communication |
| US8107956B2 (en) | 2008-12-30 | 2012-01-31 | Motorola Mobility, Inc. | Providing over-the-top services on femto cells of an IP edge convergence server system |
Family Cites Families (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| SE9401879L (sv) * | 1994-05-31 | 1995-12-01 | Ericsson Telefon Ab L M | Anordning vid telekommunikationssystem |
| CA2224604A1 (en) * | 1995-06-28 | 1997-01-16 | John Gallant | Method and apparatus for improved call connectivity in an intelligent wireless network |
| US5933784A (en) * | 1996-06-28 | 1999-08-03 | Synacom Technology, Inc. | Signaling gateway system and method |
| EP0909523A4 (en) | 1996-07-10 | 2001-01-17 | American Pcs Communications Ll | NETWORK TRANSFER DEVICE |
| US6125122A (en) * | 1997-01-21 | 2000-09-26 | At&T Wireless Svcs. Inc. | Dynamic protocol negotiation system |
| US5901352A (en) * | 1997-02-20 | 1999-05-04 | St-Pierre; Sylvain | System for controlling multiple networks and associated services |
-
2000
- 2000-02-14 US US09/504,106 patent/US6654607B1/en not_active Expired - Lifetime
-
2001
- 2001-02-14 DE DE60129365T patent/DE60129365T2/de not_active Expired - Lifetime
- 2001-02-14 JP JP2001037564A patent/JP3699900B2/ja not_active Expired - Fee Related
- 2001-02-14 EP EP01301249A patent/EP1126738B1/en not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| JP2001285372A (ja) | 2001-10-12 |
| US6654607B1 (en) | 2003-11-25 |
| DE60129365D1 (de) | 2007-08-30 |
| EP1126738B1 (en) | 2007-07-18 |
| EP1126738A3 (en) | 2002-08-28 |
| EP1126738A2 (en) | 2001-08-22 |
| DE60129365T2 (de) | 2007-11-29 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3699900B2 (ja) | 複数のプラットフォーム間を渡る統合移動通信システムおよび方法 | |
| CA2283886C (en) | Communicating packet data with a mobile station roaming within an incompatible mobile network | |
| US6614774B1 (en) | Method and system for providing wireless mobile server and peer-to-peer services with dynamic DNS update | |
| EP1334639B1 (en) | Optimal gateway discovery while roaming | |
| US7664495B1 (en) | Voice call redirection for enterprise hosted dual mode service | |
| EP1301056B1 (en) | A system for providing subscriber features within a telecommunications network | |
| EP1605662A2 (en) | Mobile terminal, server, and method of controlling routing path for voice-over-IP service | |
| KR101015642B1 (ko) | 헤테로지니어스 네트워크를 통한 데이터 푸쉬 서비스시스템 및 방법 | |
| RU2526718C2 (ru) | Способ и система для предоставления услуги межсетевого роуминга | |
| KR20070050256A (ko) | 차세대 무선 패킷 서비스 망에서 유동 아이피를 이용한패킷 착신 호 처리 장치 및 방법 | |
| US9667798B2 (en) | Enabling a communication server to use MSC-S related functions | |
| JP3559433B2 (ja) | 通信システム | |
| JP2002543677A (ja) | 異種ネットワーク間の相互動作用仮想番号計画 | |
| EP2653004B1 (en) | Enabling a communication server to use msc-s related functions | |
| JP2007221481A (ja) | 電話システム | |
| KR20010030085A (ko) | 무선 원격 통신 시스템에서 무선 호출에 대한 서비스특성을 지원하는 구조 | |
| CA2391517C (en) | Method and device for carrying out security procedures involving mobile stations in hybrid cellular telecommunication systems | |
| EP1279269B1 (en) | Method and system for establishing a communication between a first and a second communication entity | |
| KR100501839B1 (ko) | 올 아이피 이동 통신망의 호 제어 장치 및 호 제어 방법 | |
| Pang et al. | GSM‐IP: A VoIP service for mobile networks |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20040927 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20050329 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050530 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20050621 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20050711 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090715 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090715 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100715 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110715 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120715 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130715 Year of fee payment: 8 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| LAPS | Cancellation because of no payment of annual fees |