(57)【特許請求の範囲】
【請求項１】
インターネット・プロトコル網（以下「ＩＰ網」という。）に接続されており、該ＩＰ網に接続された複数の端末を管理するサーバ装置であって、
それぞれ、電話網内の複数のサービス制御装置対応に設けられたサービス制御ゲートウェイ装置に接続される複数のサーバ装置と、
上記複数の端末の一の端末から受信したアドレス問い合わせ要求に、特定の番号列を含む着端末番号が含まれる場合、上記複数のサーバに、問い合わせ信号をマルチキャストする手段とを有することを特徴とするサーバ装置。
【請求項２】
ＩＰ網に接続され、電話網と上記ＩＰ網とを接続するゲートウェイ装置を制御するサーバ装置であって、
サービス制御ゲートウェイ装置に接続され、上記サービス制御ゲートウェイ装置を介して上記電話網内のサービス制御装置にアクセスする手段と、
上記ＩＰ網に接続された他のサーバ装置からマルチキャストされたアドレス情報を問い合わせるための問い合わせ信号を受信すると、上記問い合わせ信号に含まれる情報から処理可能な呼であるか否かを判断し、可能と判断した場合に、呼処理を行う情報を含む応答信号を上記他のサーバに送信する手段を有することを特徴とするサーバ装置。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、インテリジェントネットワークにおけるサービス制御装置とインターネット・プロトコル（ＩＰ）網と電話網とを接続するゲートウェイ装置と前記ゲートウェイ装置あるいはＩＰ網に接続される端末を制御するサーバが接続される通信システムにおけるサービスの提供に関する。
【０００２】
【従来の技術】
公衆電話網では、サービスのカスタマイズ化やサービスの早期提供を可能にするインテリジェント・ネットワーク（ＩＮ）の技術を用いて、様々なサービスがユーザに提供されている。ＩＮは、電気通信標準化部門（ＩＴＵ−Ｔ）で標準化が行われており、１９９７年には、ＩＮ能力セット２が標準化された（ＩＴＵ−Ｔ勧告：Ｑ．１２２０−Ｑ．１２２８）。ＩＮは基本呼処理を行う伝達網の上位に信号網を介して高機能網を配する２階層構成をとる。
【０００３】
一方、安価な中継電話サービスとして、ＩＰ網を中継網に利用する動きが盛んである。伝達網とＩＰ網との間に音声とＩＰパケットを変換する機能を有するゲートウェイ装置を接続し、電話番号とＩＰアドレスを相互変換する機能を持たせることにより、ＩＰ網で音声サービスを提供することを可能にする。該アドレス変換機能は、ゲートウェイ上にある場合もあれば、ＩＰ網内の独立したサーバ上にある場合もある。アドレス変換機能をＩＰ網内の独立したサーバに持たせる方式としては、ＩＴＵ−Ｔで標準化が進められている、“Ｈ．３２３ゲートキーパ方式”や、インターネット技術の標準化組織であるＩＥＴＦ（Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ）で標準化が進められている“ＭＧＣＰ（Ｍｅｄｉａ  Ｇａｔｅｗａｙ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）方式”などがある。さらに、電話網そのものをＩＰ網に置き換える構想も発表されている。
【０００４】
しかし、現在のＩＰ網による中継電話サービスでは、アドレス変換機能が特定の機器に集中するため、該機能の大規模化が困難である。また、アドレス変換機能が複数存在する場合、その間の連携を取る仕組みが存在しないため、電話網のＩＮで実現されているように、サービスを集中的に制御し、ネットワークワイドなサービスを提供することはできない。従って、ＩＰ網による中継電話サービスを利用する加入者やＩＰ網に接続される端末からの発信サービスに、ＩＮで実現されているサービスを提供することはできない。即ち、ＩＰ網―公衆網連携電話サービスを利用するユーザに、ＩＮで実現されるサービスを提供することはできない。
【０００５】
現在、ＩＥＴＦにおいて、複数のアドレス変換サーバ間の連携を行うための方式として“Ｇａｔｅｗａｙ  Ｌｏｃａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ（ＧＬＰ）”の検討が開始されている。ＧＬＰは、サーバ装置への負荷軽減を目的とするもので、複数のサーバで同じ情報を保持するためにアドレス情報を交換するプロトコルである。
【０００６】
また、ＩＮのサービス制御機能とＩＰ網とが連携して通信サービスを提供する方法に関して、ＩＴＵ−Ｔにおいて、検討が開始されている。ＩＰ網と公衆網のサービス制御機能との間に、“サービス制御ゲートウェイ機能”を、ＩＰ網と公衆網の交換機との間に、“コール・ベアラゲートウェイ機能”を、ＩＰ網に“Ｈ３２３ゲートキーパ機能”を、それぞれ設ける案が出ている。
【０００７】
しかし、これらの機能を用いたサービスの提供方法は、今後の検討課題である。
【０００８】
【発明が解決しようとする課題】
近年、通信サービスの多様化に伴い、ＩＮのサービス制御機能とＩＰ網の連携による新たなＩＰ網―公衆網連携電話サービスの提供が望まれている。例えば、ＩＮのサービス制御機能を利用することによって、ＩＰ網―公衆網連携電話サービスを利用する端末から、フリーフォン等のサービスにアクセスすることが望まれる。これには、電話番号―ＩＰアドレス間の変換の際にＩＮ機能へのアクセスが必要になり、ＩＰ網上の装置からＩＮのサービス制御機能にサービス要求を行い、呼の継続処理方法（着信先）を含むサービス要求応答を受信する必要がある。
【０００９】
しかし、上述の通り、従来の技術では、ＩＰ網―公衆網連携電話サービスでは、ネットワークワイドなサービスを提供することはできない。従って、ＩＰ網―公衆網連携電話サービスを利用するユーザに、従来の電話網と同等の電話サービスを提供するためには、ＩＮのサービス制御機能にアクセスすることが必要となる。
【００１０】
ＩＮのサービス制御機能に必要となる情報や機能を、アドレス変換機能を有するＩＰ網内の独立した特定のサーバ上に持たせることが考えられる。しかし、ＩＰ網内の全てのサーバに前記特定のサーバの情報を持たせると、ＩＰ網の構成が変更するたびに各サーバの情報を変更する必要となるという課題が生じる。また、ＩＮのサービス制御機能を有する装置のＩＰアドレス情報と電話番号の対応情報の配備方法も課題となる。特定の装置（データベース）に該機能を配備すると、該特定の装置への負荷が集中するため、ＩＰ網内の装置に対して情報を分散配置することが必要となる。その分散配置された情報に対して、アクセスする方式の提案が第一の課題である。
【００１１】
また、現在ＩＥＴＦで検討が行われているＧＬＰでは、基本呼に関して、すべてのサーバ装置が電話番号とＩＰアドレスの対応情報を持つことになっている。実際には、管理ドメイン外の電話番号とＩＰアドレスの対応情報は集約するなどして対応情報が大きくなりすぎないようするための工夫は検討されているが、それでも管理ドメインが増えてくると対応情報を扱いきれないサーバが出てくる可能性は考えられる。その際に、対応情報の扱いきれない部分を、他のより高性能なサーバが持っているより完全に近い対応情報で補うことにより接続性を確保することが可能になる。このような対応情報補完のための方式の構築が第二の課題である。
【００１２】
【課題を解決するための手段】
本発明では、複数の交換機によって構成される伝達網と、ＩＰ網とを接続するゲートウェイ装置に、音声をＩＰ上で転送することを可能にする機能を持たせ、少なくても１つ以上の前記ゲートウェイ装置を管理するサーバを設ける。また、上記ＩＰ網には、ゲートウェイ装置を介して他のＩＰ網が接続されており、上記他のＩＰ網に接続される装置を管理するサーバを設ける。
【００１３】
上記第一の課題を解決するため上記音声をＩＰ化する機能を有するゲートウェイ装置とサーバとを備えるＩＰ網と、少なくても１つの交換機と、ユーザ毎のサービス用制御情報を記憶するための記憶装置を備える上記交換機に接続されたサービス制御装置とからなる通信網において、上記サーバと上記サービス制御装置とをサービス制御ゲートウェイ装置を介して接続する。上記第二の課題の解決のためにはサービス制御ゲートウェイ装置による接続は必ずしも必要ではない。
【００１４】
上記音声をＩＰ化する機能を有するゲートウェイ装置を管理するサーバは、電話番号とゲートウェイ装置のＩＰアドレスとの対応情報と認証情報と利用帯域情報とを記憶する。さらに、付加サービスを起動するための情報と機能も持つ上記他のＩＰ網に接続されるサーバは、管理する端末の識別子（Ｅ１６４アドレス等の電話番号情報）とＩＰアドレスの対応情報と認証情報と利用帯域情報とを記憶する。また、サーバ間で仮想的なＩＰ制御網を構築しそれぞれが所有する番号情報を周期的に交換を行う。該管理する端末の識別子とＩＰアドレスの対応情報において、識別子に対応する装置のアドレス情報が一意に決定できるクラスと、一意に決定することができないクラスに分類されている。対応する装置のアドレス情報を決定することができないクラスの場合、問い合せ信号を複数のサーバに送信するが、マルチキャストを行う範囲をＩＰアドレスに対応付ける。
【００１５】
上記他のＩＰ網に接続される端末から上記サーバが発呼信号に先立つアドレス要求信号を受信した時、上記サーバは、着番号のクラスを判別する。具体的には、番号情報に特定の番号列（例：０ＡＢ０、０Ａ０Ｃ、０ＡＢＣ）を含むか否かを判断する。着番号に特定の番号列が含まれない場合は対応する装置のアドレス情報が一意に決定できるクラスの場合であり、上記番号情報を用いて、着端末が接続されているゲートウェイ装置を管理するサーバのＩＰアドレス情報、又は、ゲートウェイ装置のＩＰアドレス情報を導き出し、本情報を含む応答信号を発信端末に送信する。着端末番号に特定の番号列が含まれる場合は、対応する装置のアドレス情報が決定できないクラスの場合であり、上記サーバが、複数のサーバに対して、問い合せ信号をマルチキャストし、応答があったサーバのＩＰアドレス情報を、上記サーバから上記発信端末に通知することを第１の特徴とする。上記アドレス情報を通知する応答信号に含まれるＩＰアドレスの情報は、後続する呼設定要求信号の送信先を特定するために利用する。
【００１６】
また、上記サーバは、マルチキャストした問い合せ信号に対する応答信号を受信した時、該信号に含まれるアドレス情報を一定期間上記サーバのメモリ内に蓄積する。一定期間内に上記サーバが管理している端末から同様のサービス要求を受信した場合には、該蓄積した情報を用いて、後続の処理を行うことを第２の特徴とする。
【００１７】
また、呼設定要求信号の送信先の情報を含む応答信号を受信した端末は、受信情報に基づき呼設定要求をサーバ、あるいは、ゲートウェイ装置に送信する。先にマルチキャストされた問い合せ信号に応答したサーバが、該呼設定要求を受信し、本信号がＩＮ機能の起動を要求するものであると判別した場合には、サーバ内に蓄積してある情報から、サービス制御ゲートウェイ装置のＩＰアドレス情報を取得し、該サービス制御ゲートウェイ装置に対してサービス要求を送信する。該サービス制御ゲートウェイ装置は、予め蓄積されているサービス制御装置に関する情報を用いて、サービス制御装置にサービス要求を送信し、該要求を受信したサービス制御装置は、受信情報に対応するサービス情報を該サービス制御ゲートウェイ装置経由で該サーバに通知する。該サーバは該サービス制御ゲートウェイ装置から受信した情報に基づき、電話網とＩＰ網との間に存在する適切なゲートウェイ装置を選択し、呼設定要求を送信することを第３の特徴とする。
【００１８】
ＩＰ―公衆網連携電話サービスを利用する端末から、サーバに蓄積してある情報を用いて、該サーバから直接、或いは、他のサーバを介して、サービス制御ゲートウェイ装置経由で、サービス制御装置にアクセスすることを可能にすることにより、ＩＰ網を利用するユーザに対しても、公衆電話網で提供されている様々なサービス（例えば、フリーフォン）を提供することが可能となる。また、サービス制御ゲートウェイ装置へのアクセス機能をもつサーバの情報を固定情報として持たず、マルチキャストによって判別することにより、特定のサーバへの負荷集中を回避すること、及び、網構成の変更に柔軟に対応することが可能となる。また、サーバ内のＩＰアドレス−電話番号対応情報で変換できない情報を他のより高性能なサーバへのマルチキャスト問い合わせにより得る方式の採用により、低性能なサーバでも接続性の高いＩＰ電話を実現することが可能となる。
【００１９】
【発明の実施の形態】
本発明の実施の形態を図面を用いて説明する。
【００２０】
まず、ＩＰ網からサービス制御ゲートウェイ装置を介してサービス制御装置にアクセスする方式について説明する。
【００２１】
図１は、本発明を適用する既存電話網１３（１３ａ、１３ｂ）とＩＰ網１４を接続した場合の網の構成例を示す。
【００２２】
インテリジェントネットワークは、サービス制御ポイント（ＳＣＰ）４と、複数の交換機８（８ａ、８ｂ、８ｃ）がＮｏ．７共通線信号方式（ＳＳ７）１８を介して接続される構成となっている。各交換機４には、加入者線を介して加入者端末９（９ａ、９ｂ）が収容されている。
【００２３】
インターネット網等に代表されるＩＰ網１４と、複数の交換機８によって構成される伝達網は、ゲートウェイ装置２（２ａ、２ｂ、２ｃ、２ｄ）を介して接続される。また、複数台のゲートウェイ装置２には、ゲートウェイ装置の帯域やアドレス情報を管理するサーバ３ｂ、３ｃがそれぞれ接続されている。ＩＰ網１４に接続されるサービス制御ゲートウェイ装置１ａは、ＳＣＰ４に接続されている。  ＩＰ網１４に接続される他のサービス制御ゲートウェイ装置１ｂは、他網の高機能網に存在する他のＳＣＰに接続されている。ＳＳ７網１８はゲートウェイ装置２によって終端される。ＳＳ７網１８はサーバ３ｂにより終端することも可能である。
【００２４】
ＩＰ網１４には、複数の中継ルータ７（７ａ、７ｂ、７ｃ）と関門ルータ６がＩＰプロトコルを用いて接続され、ＩＰコア網１６を形成している。ＩＰ網１４は、関門ルータ６を介して、他のＩＰ網と接続されている。中継ルータ７には、ゲートウェイ装置５を介して、ＩＰ網１７が接続されており、複数台の端末１１、１２とゲートウェイ装置５の利用帯域やアドレスの管理を行うサーバが３ａが接続されている。サーバ３（３ａ、３ｂ、３ｃ）は、仮想ＩＰ制御網１５を構築している。
【００２５】
サービス制御ゲートウェイ装置１は、サーバ３とＳＣＰ４との間で交換されるサービスに関する信号を送受信し、ＩＰプロトコルと既存電話網で利用されるプロトコルとの変換を実行するためのものである。また、サーバ３から受信した情報に基づき、アクセスするべきＳＣＰを決定するための情報やユーザ認証に用いる情報を蓄積する。
【００２６】
この図ではサービスゲートウェイ装置１は、ＩＰ網とＳＳ７網の間に置かれ、ＩＰプロトコルとＳＳ７プロトコルの変換を行っているが、ＩＰ網と高機能網の間にサービスゲートウェイ装置１を置き、ＩＰプロトコルと高機能網の内部プロトコルとの変換を行うような構成も可能である。
【００２７】
また、サービスゲートウェイ装置１とＳＣＰ４を統合し、ＳＣＰ４で直接サーバ３からの情報を受信するような構成も可能である。
【００２８】
ＳＣＰ４は、フリーダイヤルに代表される番号変換サービスのように、ネットワークワイドなサービスや、ユーザ毎に登録してある情報に基づいて提供するカスタマサービスを実行するためものである。
【００２９】
ゲートウェイ装置２は、音声サービスをＩＰ網の上でも提供するため、音声をＩＰパケット化する機能と、電話網内の交換機とゲートウェイ装置との間で、共通線信号網で利用される信号情報をやり取りするための手段と、ＩＰ網内の装置とインターネットプロトコルによって通信する手段を提供する。ゲートウェイ装置２として、具体的にはインターネット電話サービスを提供する通信事業者によって運営・管理されるＶｏＩＰ（Ｖｏｉｃｅ  ｏｖｅｒ  ＩＰ）ゲートウェイ等がある。
【００３０】
図２は、サービス制御ゲートウェイ装置１の構成を示す。
【００３１】
サービス制御ゲートウェイ装置１は、ＳＣＰやゲートウェイ装置との間の信号を制御するＣＰＵ２１と、メモリ２２と、ＩＰ網との間の信号線２４を終端するＩＰ網インタフェース部２３と、ＳＣＰとの間の信号線２６を終端する高機能網インタフェース部２５とをバス２７で接続する構成となっている。
【００３２】
メモリ２２は、サーバやＳＣＰからの信号を送受信するためのプログラムや、ＳＣＰで実現されているサービスにアクセスするために必要となる情報やＳＣＰにアクセスするために利用する認証情報が格納されている。
【００３３】
ＣＰＵ２１とＳＣＰの間の通信は、例えば新たなＩＮのメッセージを用いて行われる。ＣＰＵ２１とサーバとの間の通信は、例えば、インターネット・プロトコルを用いて行われる。
【００３４】
図３は、ゲートウェイ装置２の構成を示す。
【００３５】
ゲートウェイ装置２は、ＩＰ網に接続される装置や、伝達網に接続される装置との間の信号を制御するＣＰＵ３１と、メモリ３２と、ＩＰ網との間の信号線３４を終端するＩＰ網インタフェース部３３と、伝達網との間の信号線３６を終端する伝達網インタフェース部３５と、音声情報をパケット化する音声パケット化部３８をバス３７で接続する構成となっている。
【００３６】
メモリ３２は、ＩＰ網上のサーバやルータ、或いは、電話網の交換機からの信号を送受信するためのプログラムが格納されている。
【００３７】
ＣＰＵ３１とＩＰ網上の装置との間の通信は、例えば、インターネット・プロトコルを用いて行われる。ＣＰＵ３１と伝達網との間の通信は、例えば、Ｎ−ＩＳＤＮのＩＳＤＮユーザパートプロトコル（ＩＳＵＰ）を用いて行われる。
【００３８】
図４は、サーバ３の構成を示す。
【００３９】
サーバ３は、ＩＰ網に接続される他の装置との間の信号を制御するＣＰＵ４１と、メモリ４２と、ＩＰ網との間の信号線４４を終端するＩＰ網インタフェース部４３とをバス４５で接続する構成となっている。
【００４０】
メモリ４２は、サーバが管理する端末やゲートウェイ装置の電話番号とＩＰアドレスの対応情報や、ユーザ認証情報や認証を行うためのプログラムや、帯域を管理するための情報やプログラムや、ＩＰ網上のサーバやルータからの信号を送受信するために必要な情報やプログラムが格納されている。
【００４１】
ＣＰＵ４１とＩＰ網上の装置との間の通信は、例えば、インターネット・プロトコルを用いて行われる。
【００４２】
サーバ３がＳＳ７網１８を終端する場合には、サーバ３にＳＳ７網インタフェース部を追加する。
【００４３】
図５は、サーバ３ａのＣＰＵ４１が実行する処理フローを示す。
【００４４】
本処理フローは、ＩＰ網に接続される加入者端末１１から電話網の端末９ａに発信する場合、サーバ３ａにアドレス問い合せを開始する場合に実行される。
【００４５】
サーバ３ａは端末１１からアドレス要求信号を受信する（５１）。端末１１からの信号を検出すると、ＩＰ網インタフェース部４５を介してメモリ４２に信号が転送され、メモリに蓄積されているプログラムを用いて、信号受信処理を開始する。受信信号に含まれる情報要素を解析し、ユーザからの発信を受け付けることができるかを判別する（５２）。発信を受け付ける場合には、発信端末と着信端末の識別子から端末の存在するエリアを比較する（５３）。存在するエリアが同一である場合には、サーバのメモリに蓄積されている情報を利用して、着端末のＩＰアドレスと呼処理を行うチャネルの情報を検索する（６４）。必要な情報を検出したサーバは、発信端末の状態を“空き”から“塞がり”に更新し（６１）、該呼に割り当てる帯域を決定し（６２）、アドレス確認信号を発信端末に送信し、本ルーチンを終了する（６３）。ステップ６２で、割り当てる帯域がなかった場合には、エラー信号を発信端末に送信する（６５）。
【００４６】
発着端末の存在するエリアが異なる場合には、着端末の番号とメモリに蓄積してある情報と比較し、着端末番号のクラスを決定する（５４）。
【００４７】
着端末番号が、サーバ内メモリに蓄積された情報からアドレス解決可能なクラスであれば（５５）、着端末番号から対応するゲートウェイ装置、もしくは該ゲートウェイ装置を管理するサーバのＩＰアドレスと呼処理を行うチャネルの情報を検索する（６４）。以下、発着端末が同一エリア内の場合と同じように呼設定処理を行う。
【００４８】
ＩＮへの問い合わせが必要など、サーバ内メモリ内に蓄積された情報からアドレス解決不可能なクラスであれば、まずメモリ内に蓄積されたキャッシュを調べ、過去の一定期間内に該クラスの番号解決のために他サーバに問い合わせを行っていないかを確認する（５６）。もし過去の一定期間内にサーバに問い合わせを行っていれば、その時に応答したサーバのＩＰアドレスと呼処理を行うチャネルの情報を検索する（６４）。過去の一定期間内に問い合わせを行っていなく、適切なサーバのＩＰアドレスの解決が不可能な場合、予めメモリに蓄積してある情報を用いて、他のサーバにアドレス情報を問い合わせるための信号をマルチキャストする（５８）。本信号には、例えば、着信端末を識別するための番号（Ｅ１６４アドレス等）が含まれる。ここで、電話番号とＩＰアドレスとを対応付ける情報は、サーバ間で情報を定期的に交換することにより蓄積する方法、或いは、サービス開始時に網オペレータによって入力する方法のいずれかによって、各サーバに提供されているものとする。また、通信できるサーバの情報は、網オペレータによって各サーバ内のメモリに予め設定されているか、ＩＰマルチキャストアドレスに各サーバが登録されているものとする。
【００４９】
図９に情報テーブルの例を示す。着番号３０１は着番号のパターンを示す。これと端末から受信した番号を比較し、クラス３０２を決定する。ＩＰアドレス３０３はクラス３０２が内部解決可能であれば対応するサーバもしくはゲートウェイ２のＩＰアドレスが書かれる。内部解決不能であればそのクラスに対応したマルチキャストアドレスが書かれる。キャッシュ３０４はクラス３０２が内部解決不能で、過去にマルチキャストアドレスを用いて問い合わせが成功した場合に、利用したサーバ３のアドレスが書かれる。有効期限３０５はキャッシュの有効期限が書かれる。システムの時計がこの有効期限を過ぎていた場合はキャッシュの内容は使われない。３０１１〜３０１３は具体的なパターンの例を示す。「？」は０から９までの任意の数字を、［１−８］は１から８までの任意の数字を示す。３０１１は内部解決可能なパターンの例である。この場合はクラス３０２１は「内部解決可能」となり、ＩＰアドレス３０３１にはサーバ３もしくはゲートウェイ２のアドレスが書かれている。キャッシュと有効期限は必要ないので、そこは空欄となる。３０１２と３０１３は内部解決不能なパターンの例である。内部解決不能な場合は３０２２と３０２３のように複数の場合が考えられうるので、クラスも考えられるパターンをすべて網羅する必要がある。ＩＰアドレス３０３２と３０３３にはクラスに対応したマルチキャストアドレスが書かれている。キャッシュ３０４２と３０４３には過去に対応したサービスゲートウェイ１へのアクセス能力をもつサーバ３のアドレスが書かれている。有効期限３０５２と３０５３にはキャッシュの有効期限が書かれている。
【００５０】
上記信号を受信したサーバは、問い合せ信号に含まれる情報から、サーバで処理が可能な呼であると判別した場合に、該サーバ上で呼処理を行うチャネルの情報を含む応答信号を送信する（５９）。上記応答信号には、前記問い合せ信号に対する応答であることを示す情報（相関ｉｄ）を含む。上記応答信号を受信したサーバは、サーバ問い合わせキャッシュを更新し（６０）、発信端末の状態を空きから塞がりに更新し（６１）、該呼に割り当てる帯域を決定し（６２）、アドレス確認信号を発信端末に送信し、本ルーチンを終了する（６３）。ステップ６２で、割り当てる帯域がなかった場合には、エラー信号を発信端末に送信する（６５）。
【００５１】
図６は、サーバ３ｂのＣＰＵ４１が実行する処理フローを示す。
【００５２】
サーバ３ａの管理下にある端末から、アドレス情報をマルチキャストする必要がある番号への発信が行われた場合、サーバ３ｂが問い合せ信号を受信する（７１）。サーバ３ｂのメモリ４２に蓄積されているアクセス可能な問い合せ要求送信もとのサーバの情報、および、一定期間内に問い合わせてきたサーバ数を読み出し、問い合せ信号を処理することが可能か否かを判別する（７２）。次に、問い合せ信号に対応するサービス制御ゲートウェイ装置へのアクセスが可能か否かを判別し、アクセスが可能である場合には、前記問い合せ信号に対する応答信号をサーバ３ａに対して送信する（７４）。上記応答信号には、前記問い合せ信号に対する応答であることを示す情報（相関ｉｄ）を含む。サーバ３ｂはタイマを開始して、サーバ３ａが管理する端末、或いは、サーバ３ａからの呼設定要求信号の受信を待つ（７５）。一定期間内に、サーバ３ａもしくは、サーバ３ａが管理する端末から、先に受信した着番号の情報と相関ｉｄを含む呼設定要求信号を受信し（７６）、呼設定受付信号をサーバ３ａに送信する（７７）。次に、着番号情報から、サービス制御ゲートウェイ装置１ａへのアクセスが必要であることを判別し、アドレス情報を検索し（７８）、該サービス制御ゲートウェイ装置に対して、サービス要求信号を送信する（７９）。
【００５３】
サービス制御ゲートウェイ装置１ａは、受信信号を適切なＳＣＰに送信し、ＳＣＰからサービス要求信号に対する応答信号を受信すると、前記サーバ３ｂに対して、サービス要求応答信号を送信する（８０）。該応答信号には、着端末へのルーチング情報を含む番号情報が含まれる。このルーチング情報をキーにして、サーバ３ｂは、電話網とのインタワークを行うゲートウェイ装置のアドレス情報を検索する（８１）。サーバ３ｂは、該当ゲートウェイ装置に対して、呼設定要求を送信する（８２）。該サーバ３ｂが、前記呼設定要求を受信したゲートウェイ装置から、前記呼設定要求と関連付ける情報（相関ｉｄ）を含むアドレス要求信号を受信すると、予めメモリ内に蓄積してある情報を用いてユーザの認証処理を行い（８４）、認証結果がＯＫである場合には、該当端末の状態を空きから塞がりに更新し（８５）、該呼に対して帯域を割り当てる（８６）。正常に帯域が割り当てられた場合には、該当ゲートウェイ装置に対して相関ｉｄを含むアドレス確認信号を送信し（８７）、ゲートウェイ装置からの呼設定受付信号の受信を待つ。
【００５４】
ステップ７２において、問い合せ信号の処理をすることができない場合や、ステップ７３において、サービス制御ゲートウェイ装置１ａへのアクセスが拒否された場合には、受信信号を廃棄し（８８）、空き状態に戻る（８９）。
【００５５】
ステップ７５において、一定期間内にサーバ３ａまたはサーバ３ａが管理する端末から適切な相関ｉｄを含む呼設定要求信号を受信しなかった場合には、空き状態に戻る（８９）。
【００５６】
ステップ８４においてユーザ認証処理に失敗した場合、ステップ８６において、帯域割り当てを行うことができなかった場合には、エラー信号をゲートウェイ装置に送信を送信し、本ルーチンを終了する（９０）。
【００５７】
次に、図７〜図８に示す信号シーケンスに従って、ＩＰ網上の端末にＩＮサービスを提供するためのサービス制御方法について説明する。
【００５８】
図７は、ＩＰ網に接続されている電話機能を有す端末１１から、公衆電話網に接続された端末９ｂに発信する場合の信号シーケンス図である。ＩＰ網に存在するサーバと端末間、サーバとゲートウェイ間、端末とゲートウェイ間の通信には、例えば、ＩＴＵ−Ｔ  Ｈ３２３で規定されているプロトコルを利用するものとする。
【００５９】
端末１１は、予め、端末１１が属するＩＰ網１７を管理するサーバ３ａに対して該端末の登録を行い、サーバ３ａとアドレス問い合せ情報等を交換するために利用するチャネル情報（例えば、ＴＣＰ又はＵＤＰのポート番号）を取得しているものとする。端末１１から発信を行う場合、まず、上記チャネルを利用して、アドレス問い合せ信号（ＡＲＱ）をサーバ３ａに送信する（２０１）。アドレス問い合せ信号を受信したサーバ３ａは、図５に示す処理フローをメモリから読み出し実行する。まず、受信信号に含まれる発信端末の識別子を用いて認証処理を行う。次に、受信信号に含まれる発信端末の識別子と着番号情報と比較し、同一エリア内の呼か否かを識別する。同一エリア内の呼でない場合、予めメモリ内に蓄積されている情報を利用して、着番号のクラスを判別する。着番号に対して、着端末を収容するゲートウェイ装置を管理するサーバ３ｂのＩＰアドレスが一意に決まるクラスの場合、該当サーバ３ｂのＩＰアドレスと呼処理信号情報の送受信に利用する情報（ＴＣＰのポート番号等）を検索する（２０２）。
【００６０】
サーバ３ａは、発端末の状態を更新した後、呼に割り当てる帯域を決定し、サーバ３ｂのアドレス情報や利用可能な帯域情報を含むアドレス確認信号（ＡＣＦ）を端末１１に送信する（２０３）。
【００６１】
端末１１は、受信情報に基づき、サーバ３ｂとの間で呼処理信号を交換するために例えばＴＣＰ等の信頼性のあるコネクションを確立した後、サーバ３ｂに対して、呼設定要求信号（Ｓｅｔｕｐ）を送信する（２０４）。本信号を受信したサーバ３ｂは、呼を受け付けられる場合、呼受付信号（Ｃａｌｌ  Ｐｒｏｃ）を端末１１に送信する（２０５）。
【００６２】
サーバ３ｂは、受信した呼設定要求信号内に含まれる着番号情報から、メモリ内の情報を用いて、着端末に最寄りのゲートウェイ装置２ａのＩＰアドレスと呼処理信号情報の送受信に利用する情報（ＴＣＰのポート番号等）を決定する（２０６）。サーバ３ｂとゲートウェイ２ａの間で、呼処理信号情報を交換するため、例えばＴＣＰ等の信頼性のあるコネクションを設定し、呼設定要求信号（Ｓｅｔｕｐ）を送信する（２０７）。
【００６３】
呼設定要求信号を受信したゲートウェイ装置２ａは、サーバ３ｂに対して、認証処理や帯域割り当てを要求するためアドレス要求信号（ＡＲＱ）を送信する（２０８）。サーバ３ｂでは、着ユーザの認証処理を行い、着端末の状態を空きから塞がりに更新した後、呼に対して帯域を割り当て、利用帯域情報を含むアドレス確認信号（ＡＣＦ）をゲートウェイ装置２ａに送信する（２０９）。
【００６４】
ゲートウェイ装置２ａは、サーバ３ｂに対して、呼設定受付信号（Ｃａｌｌ  Ｐｒｏｃ）を送信するとともに（２１０）、共通線信号網を利用して着端末を収容する交換機８ｂに対し、アドレス信号（ＩＡＭ）を送信する（２１１）。
【００６５】
本信号を受信した交換機８ｂは、呼設定要求信号（Ｓｅｔｕｐ）を端末９ｂに対して送信する（２１２）。端末は呼を受け付けられる場合には、呼受付信号（Ｃａｌｌ  Ｐｒｏｃ）を交換機８ｂに送信する（２１３）。交換機８ｂは着端末に呼を設定するのに必要な情報が受信されたことを示すため、アドレス完了信号（ＡＣＭ）をゲートウェイ装置２ａに対して送信する（２１４）。
【００６６】
着端末がオフフックした時（２１５）、端末９ｂから交換機８ｂに対して応答信号（Ｃｏｎｎｅｃｔ）を送信し（２１６）、交換機８ｂはゲートウェイ装置２ａに着ユーザが該呼に応答したことを通知するため、応答信号（ＡＮＭ）を送信する（２１７）。ゲートウェイ装置２ａは、サーバ３ｂに対して、音声情報を転送するために利用するトランスポートアドレス情報（ＵＤＰのポート番号等）を含む応答信号（Ｃｏｎｎｅｃｔ）を送信する（２１８）。サーバ３ｂは上記応答信号で受信したトランスポートアドレス情報を含む応答信号（Ｃｏｎｎｅｃｔ）を端末１１に送信する（２１９）。このアドレス情報を用いて、ゲートウェイ装置２ａと端末１１の間で、例えば、ＲＴＰ（Ｒｅａｌ―Ｔｉｍｅ  Ｐｒｏｔｏｃｏｌ）を用いて音声をＩＰ網上で転送することが可能になる。
【００６７】
以上の処理フローを実行することにより、例えば、インターネット電話に加入するＩＰ網上の端末から電話網の端末に対して発信をすることが可能となる。
【００６８】
なお、本シーケンスでは、サーバ３ｂが呼処理信号を送受信する例を示したが、ステップ２０２においてゲートウェイ装置２ａのアドレス情報と呼処理情報を送受信するための情報を検出すれば、サーバ３ｂを介さず、呼処理を行うことも可能である。
【００６９】
次に、図８に示す信号シーケンスに従って、インターネット電話に加入するＩＰ網上の端末からフリーフォンサービス等を利用する場合の処理フローを説明する。ＩＰ網に存在するサーバと端末間、サーバとゲートウェイ間、端末とゲートウェイ間の通信には、例えば、ＩＴＵ−Ｔ  Ｈ３２３で規定されているプロトコルを利用するものとする。
【００７０】
端末１１は、予め、端末１１が属するＩＰ網１７を管理するサーバ３ａに対して該端末の登録を行い、サーバ３ａとアドレス問い合せ情報等を交換するために利用するチャネル情報（例えば、ＴＣＰ又はＵＤＰのポート番号）を取得しているものとする。端末１１から発信を行う場合、まず、上記チャネルを利用して、アドレス問い合せ信号（ＡＲＱ）をサーバ３ａに送信する（２５１）。アドレス問い合せ信号を受信したサーバ３ａは、図５に示す処理フローをメモリから読み出し実行する。まず、受信信号に含まれる発信端末の識別子を用いて認証処理を行う。次に、受信信号に含まれる発信端末の識別子と着番号情報と比較し、同一エリア内の呼か否かを識別する。同一エリア内の呼でない場合、予めメモリ内に蓄積されている情報を利用して、着番号のクラスを判別する。着番号に対して、着端末を収容するゲートウェイ装置を管理するサーバのＩＰアドレスが一意に決まらないクラスの場合、サーバ３ａのメモリ内キャッシュの情報を検索する。キャッシュに着番号に関連する情報が含まれない場合には、サービス制御ゲートウェイ装置１（１ａ、１ｂ）にアクセスする機能をもつ複数のサーバに対して、問い合せ信号をマルチキャストする（２５２、２５３）。
【００７１】
本問い合せ信号を受信したサーバ３ｂは、図６に示す処理フローをメモリから読み出し実行する。まず問い合せ信号を送信したサーバの認証処理を行い、次にサービス制御ゲートウェイ装置１ａへのアクセスが可能であると判断した後、サーバ３ｂの呼処理信号を送受信するためのアドレス情報（ＴＣＰのポート番号等）を含む応答信号をサーバ３ａに対して送信し（２５４）、端末１１あるいはサーバ３ａからの呼設定要求信号（Ｓｅｔｕｐ）の受信をまつ。サーバ３ａは、端末１１の状態を空きから塞がりに更新し、呼に割り当てる帯域を決定し、受信したサーバ３ｂの呼処理信号を送受信するためのアドレス情報を含むアドレス確認信号（ＡＣＦ）を端末１１に送信する（２５５）。
【００７２】
端末１１は、受信情報に基づき、サーバ３ｂとの間で呼処理信号を交換するために例えばＴＣＰ等の信頼性のあるコネクションを確立した後、サーバ３ｂに対して、呼設定要求信号（Ｓｅｔｕｐ）を送信する（２５６）。本信号を受信したサーバ３ｂは、呼を受け付けられる場合、呼受付信号（Ｃａｌｌ  Ｐｒｏｃ）を端末１１に送信する（２５７）。
【００７３】
サーバ３ｂは、受信した呼設定要求信号内に含まれる着番号情報から、メモリ内の情報を用いて、ＳＣＰへのアクセスが必要な呼であることを判別し（２５８）、着番号からサービス制御ゲートウェイ装置１ａのＩＰアドレス情報を決定し、該サービス制御ゲートウェイ装置１ａにサービス要求信号を送信する（２５９）。サービス制御ゲートウェイ装置１ａでは、サーバの認証処理を行った後、ＳＣＰ４へのアクセスが可能である場合には、受信信号を共通線信号網で転送できるように下位プロトコルの変換を行い（２６０）、サービス要求信号をＳＣＰ４に対して送信する（２６１）。
【００７４】
サービス要求を受信したＳＣＰ４は、ＩＮサービス処理プログラムを起動し、例えば０１２０で始まる論理番号から端末の位置へのルーチングを可能にするための物理番号に変換を行い、変換した番号を含む応答信号をサービス制御ゲートウェイ装置１ａ経由でサーバ３ｂに対して送信する（２６３、２６４）。
【００７５】
サーバ３ｂは、応答信号２６４に含まれる電話網でのルーチングに利用する番号に最寄りのゲートウェイ装置２ａのＩＰアドレスと呼処理信号情報の送受信に利用する情報（ＴＣＰのポート番号等）を決定する（２６５）。この後の処理は、図７のステップ２０７以降の処理と同様である。サーバ３ｂとゲートウェイ２ａの間で、呼処理信号情報を交換するため、例えばＴＣＰ等の信頼性のあるコネクションを設定し、呼設定要求信号（Ｓｅｔｕｐ）を送信する（２６６）。
【００７６】
呼設定要求信号を受信したゲートウェイ装置２ａは、サーバ３ｂに対して、認証処理や帯域割り当てを要求するためアドレス要求信号（ＡＲＱ）を送信する（２６７）。サーバ３ｂでは、ルーチング番号が示す端末の認証処理を行い、着端末の状態を空きから塞がりに更新した後、呼に対して帯域を割り当て、利用帯域情報を含むアドレス確認信号（ＡＣＦ）をゲートウェイ装置２ａに送信する（２６８）。
【００７７】
ゲートウェイ装置２ａは、サーバ３ｂに対して、呼設定受付信号（Ｃａｌｌ  Ｐｒｏｃ）を送信するとともに（２６９）、共通線信号網を利用して着端末を収容する交換機８ｂに対し、アドレス信号（ＩＡＭ）を送信する（２７０）。
【００７８】
本信号を受信した交換機８ｂは、呼設定要求信号（Ｓｅｔｕｐ）を端末９ｂに対して送信する（２７１）。端末は呼を受け付けられる場合には、呼受付信号（Ｃａｌｌ  Ｐｒｏｃ）を交換機８ｂに送信する（２７２）。交換機８ｂは着端末に呼を設定するのに必要な情報が受信されたことを示すため、アドレス完了信号（ＡＣＭ）をゲートウェイ装置２ａに対して送信する（２７３）。
【００７９】
着端末がオフフックした時（２７４）、端末９ｂから交換機８ｂに対して応答信号（Ｃｏｎｎｅｃｔ）を送信し（２７５）、交換機８ｂはゲートウェイ装置２ａに着ユーザが該呼に応答したことを通知するため、応答信号（ＡＮＭ）を送信する（２７６）。ゲートウェイ装置２ａは、サーバ３ｂに対して、音声情報を転送するために利用するトランスポートアドレス情報（ＵＤＰのポート番号等）を含む応答信号（Ｃｏｎｎｅｃｔ）を送信する（２７７）。サーバ３ｂは上記応答信号で受信したトランスポートアドレス情報を含む応答信号（Ｃｏｎｎｅｃｔ）を端末１１に送信する（２７８）。このアドレス情報を用いて、ゲートウェイ装置２ａと端末１１の間で、例えば、ＲＴＰ（Ｒｅａｌ―Ｔｉｍｅ  Ｐｒｏｔｏｃｏｌ）を用いて音声をＩＰ網上で転送することが可能になる。
【００８０】
以上の処理フローを実行することにより、例えば、インターネット電話に加入するＩＰ網上の端末からＩＮを用いて提供できるサービスを利用することが可能となる。
【００８１】
次に、サーバ内のＩＰアドレス−電話番号対応情報で変換できない情報を他のより高性能なサーバへのマルチキャスト問い合わせにより得る方式について説明する。
【００８２】
図１０は、本発明を適用する既存電話網１３（１３ａ、１３ｂ）とＩＰ網１４を接続した場合の網の構成例を示す。図１との違いは、高機能網およびサービス制御ゲートウェイ装置が省かれていることである。これは該方式の説明には必要ないためであり、高機能網は実際には存在していてもかまわない。
【００８３】
図１１は、サーバ３ｂのＣＰＵ４１が実行する処理フローを示す。図６との違いは、サービス制御ゲートウェイ装置を通じたサービス制御装置との通信が存在しないことである。サーバ３ａのＣＰＵ４１が実行する処理フローは基本的に変わらない。
【００８４】
図１２は、  ＩＰ網に接続されている電話機能を有す端末１１から、公衆電話網に接続された端末９ｂに発信する場合の信号シーケンス図である。図７との違いは、着番号からサーバ３ｂのＩＰアドレスに変換（２０２）が不能なため、解決可能サーバに問い合わせをマルチキャストし（３０１、３０２）、該問い合わせの応答３０３を待って、その結果に基づきＡＣＦ２０３をサーバ３ａから端末に送信するところである。
【００８５】
以上の処理フローを実行することにより、端末１１から、サーバ３ａ内のＩＰアドレス−電話番号対応情報に無い電話番号へも通話を行うことが可能となる。
【００８６】
【発明の効果】
本発明によれば、インターネットをはじめとするＩＰ網と公衆網の連携による電話サービスを利用する場合、インテリジェントネットワークのサービス制御局によって提供されるサービスを効率的に利用することが可能になり、ＩＰ網と公衆電話網の連携による電話サービスの種類を増やすことが可能になる。また、サービス制御局を有する通信事業者はサービスの利用範囲を拡大することが可能になる。
【００８７】
また、すべてのサーバに完全なＩＰアドレス−電話番号変換情報を持たせる必要が無くなるため、サーバの性能に関わらずＩＰ電話の接続性を確保することが可能となる。
【図面の簡単な説明】
【図１】既存電話網とＩＰ網を接続した網構成の一例を示す図。
【図２】サービス制御ゲートウェイ装置の構成を示す図。
【図３】ゲートウェイ装置の構成を示す図。
【図４】ＩＰ網上のサーバの構成を示す図。
【図５】サーバで行われる処理内容を示すフローチャート。
【図６】サーバで行われる処理内容を示すフローチャート。
【図７】公衆電話網とＩＰ網を接続した網構成におけるインターネット電話の処理フローを示す信号シーケンス図。
【図８】インテリジェントネットワークとＩＰ網を接続した網構成におけるサービス提供方法の詳細を示す信号シーケンス図。
【図９】サーバの記憶装置内に蓄積される情報テーブルの１例。
【図１０】既存電話網とＩＰ網を接続した網構成の一例を示す図。
【図１１】サーバで行われる処理内容を示すフローチャート。
【図１２】公衆電話網とＩＰ網を接続した網構成におけるインターネット電話の処理フローを示す信号シーケンス図。
【符号の説明】
１…サービス制御ゲートウェイ装置、２、５・・・ゲートウェイ装置、３・・・サーバ、４・・・ＳＣＰ、７・・・中継ルータ、８…交換機、９、１１、１２・・・加入者端末、１８・・・共通線信号網。
【図１】
0003633356.tif 000002
【図２】
0003633356.tif 000003
【図３】
0003633356.tif 000004
【図４】
0003633356.tif 000005
【図５】
0003633356.tif 000006
【図６】
0003633356.tif 000007
【図７】
0003633356.tif 000008
【図８】
0003633356.tif 000009
【図９】
0003633356.tif 000010
【図１０】
0003633356.tif 000011
【図１１】
0003633356.tif 000012
【図１２】
0003633356.tif 000013