(57)【要約】      （修正有）【課題】インターネットと比較してより一定の品質を保証し、より高い情報セキュリティを担保し、従来の電機通信網回線レベルに近い高信頼性のＩＰ回線を提供するためには、ＳＩＰ信号の通信路とリソース管理部を実現する。【解決手段】呼処理サーバは、呼処理を行う呼処理部と、自網のネットワークを仮想パスとしてリソース管理し、そのリソース量に対してＳＩＰネゴシエーションの結果得られる要求帯域を、メディアセッション毎に仮想パスから加減算してリソース管理するリソース管理部と備え、リソース管理部は、自網と他網の網間における所定の帯域上限値と、ネットワークリソース情報およびデータフロー情報に基づく帯域管理によって経路帯域を判定して経路選択を行い、１以上の転送処理部の中から自網に張られたストリーム数が少ない転送処理部を選択し、ストリーム数が同じ場合は、上り方向と下り方向の使用率の合計が少ない転送処理部を選択する。【選択図】図１
2010103968.tif 000002
【特許請求の範囲】
【請求項１】
呼処理サーバと１以上の転送処理部を含む自網と、少なくとも１つの呼処理部を含む他網が接続される網構成のリソース管理システムにおいて、
前記呼処理サーバは、
ユーザ端末間のＳＩＰネゴシエーションを管理し、セッション状態情報に基づいて呼処理を行う呼処理部と、
前記自網のネットワークを仮想パスとしてリソース管理し、そのリソース量に対してＳＩＰネゴシエーションの結果得られる要求帯域を、ＳＩＰネゴシエーション毎に確立したメディアセッション毎に仮想パスから加減算してリソース管理するリソース管理部と備え、
前記リソース管理部は、
前記自網と前記他網の網間における所定の帯域上限値と、ネットワークリソース情報およびデータフロー情報に基づく帯域管理によって前記転送処理部を含む経路帯域を判定して経路選択を行う手段と、
前記１以上の転送処理部から前記他網と接続するための転送処理部を選択する際に、前記自網に張られたストリーム数が少ない転送処理部を選択し、前記ストリーム数が同じ場合は、上り方向と下り方向の使用率の合計が少ない転送処理部を選択する手段と
を備えたことを特徴とするリソース管理システム。
【請求項２】
請求項１に記載のリソース管理システムにおいて、
前記ネットワークリソース情報は、転送処理部区間仮想パス構成情報と、網間仮想パス構成情報と、ＲＡＣＳ受付優先度情報と、ＱｏＳクラス設定情報とを含むことを特徴とするリソース管理システム。
【請求項３】
請求項１に記載のリソース管理システムにおいて、
前記データフロー情報は、ピークレート情報と、ＱｏＳクラス識別情報と、受付優先度と、受付優先クラス識別情報とを含むことを特徴とするリソース管理システム。
【請求項４】
請求項１に記載のリソース管理システムにおいて、
前記セッション状態情報は、ユーザ情報、要求品質情報、経路情報、要求呼処理制御情報、処理状態情報を含むことを特徴とするリソース管理システム。
【請求項５】
請求項１に記載のリソース管理システムにおいて、
前記呼処理サーバは、ユーザが通信時に送受信するメディアトラヒックの帯域確保要求時に転送処理部に対して自網側のポリシング設定を識別する識別子と他網側のポリシング設定を識別する識別子を転送処理部内で一意に識別可能な識別子の払い出しを要求するメッセージを送信し、同時に自網側の識別子と他網側の識別子のペアを識別管理するための転送処理部でユニークな識別子も転送処理部に払い出しを要求し、自網側の識別子と他網側の識別子とこのペアを識別する識別子を転送処理部ごとに記憶する手段を備えた
ことを特徴とするリソース管理システム。
【請求項６】
呼処理サーバと１以上の転送処理部を含む自網と、少なくとも１つの呼処理部を含む他網が接続される網構成のリソース管理方法において、
前記呼処理サーバの呼処理部は、ユーザ端末間のＳＩＰネゴシエーションを管理し、セッション状態情報に基づいて呼処理を行い、前記呼処理サーバのリソース管理部は、前記自網のネットワークを仮想パスとしてリソース管理し、そのリソース量に対してＳＩＰネゴシエーションの結果得られる要求帯域を、ＳＩＰネゴシエーション毎に確立したメディアセッション毎に仮想パスから加減算してリソース管理し、
さらに、前記リソース管理部は、
前記自網と前記他網の網間における所定の帯域上限値と、ネットワークリソース情報およびデータフロー情報に基づく帯域管理によって前記転送処理部を含む経路帯域を判定して経路選択を行い、
前記１以上の転送処理部から前記他網と接続するための転送処理部を選択する際に、前記自網に張られたストリーム数が少ない転送処理部を選択し、前記ストリーム数が同じ場合は、上り方向と下り方向の使用率の合計が少ない転送処理部を選択する
ことを特徴とするリソース管理方法。
【請求項７】
請求項６に記載のリソース管理方法において、
前記リソース管理部が加入端末からの呼（ＳＩＰ）に対応したサービスセッション制御信号を受信する第１のステップと、
前記呼に対応した前記セッション状態情報を読み出す第２のステップと、
前記呼に対応した使用可能な候補経路について前記ネットワークリソース情報を読み出す第３のステップと、
前記ストリーム数および帯域使用率による前記転送処理部の選択が可能か否かを判定する第４のステップと、
前記第４のステップで前記転送処理部の選択が可能なときに、前記呼に対応した前記データフロー情報を読み出し、メディアの追加または削除の条件判定を行う第５のステップと、
前記第５のステップの条件を満たさないときに、「ストリーム数が少ない＞帯域使用率が低い」の優先順位に基づいて次優先の転送処理部を選択して前記第４のステップに戻る第６のステップと、
前記第５のステップの条件を満たすときに、候補経路につき前記呼に対応したセッション状態情報から仮想パス選択論理を適用した転送処理部を決定する第７のステップと、
前記第７のステップで決定した転送処理部の経路で対応したＳＩＰセッション制御処理を行う第８のステップと、
前記第４のステップまたは前記第６のステップで前記転送処理部の選択が不可のときに、前記呼の帯域確保要求に対してエラー返却を行う第９のステップと
を有することを特徴とするリソース管理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信ネットワークを構成するルータとは独立したリソース管理部（リソース管理サーバ）を用いて、ルータやパケット転送装置間のリンクの利用可能な帯域（リソース）を管理するリソース管理システムおよびリソース管理方法に関する。
【背景技術】
【０００２】
従来、リソース管理部（リソース管理サーバ）を用いて、ルータやパケット転送装置間のリンクの利用可能な帯域をリソース量として、その利用状況を管理するとともに、ユーザ端末等からのリソース確保要求に対して適切な容量のリソースを払い出す方式が採用されている。また、ユーザ端末間で必要なトラヒックに対するリソース量はＳＩＰ（Session Initiation Protocol)を用いてネゴシエーションして決定され、ユーザ端末間やユーザ端末とサーバ間でＳＩＰを用いてネゴシエーションが行われる際に、リソース管理部に対して帯域の予約と確保要求、通信ネットワークへのポリシング設定が行われる。ここで、ポリシング設定とは、ＩＰアドレス、ポート番号を対象としたクラシファイ、カラーリング、マーキング、シェイピング、ドロッピング、ディスカードなどである。すなわち、通信ネットワークへのポリシング設定により、トラヒックが制御されて適切なＱｏＳがリソース管理部により提供される。
【０００３】
ところで、従来のリソース管理部はアクセス系のネットワークに限られ、アクセス系のネットワークのＳＩＰ信号はユーザ端末の発呼ごとになり、アクセス区間のリソースを使用するメディア通信のトラヒックに比べて少ないので特段の考慮がなされていない。
【０００４】
また、中継網、特に他網との接続に対してその境界ゲートウェイに対して、同じようなリソース管理と転送網へのポリシング設定を行う場合、ＳＩＰ信号は同じ束として扱うことが可能となる。このため、無視できない値であるが、従来技術では考慮されていなかった。
【先行技術文献】
【非特許文献】
【０００５】
【非特許文献１】ＮＴＴ技術ジャーナル2007年４月、「ＮＧＮが提供する新しいコミュニケーションとそれを支える技術」
【発明の概要】
【発明が解決しようとする課題】
【０００６】
呼処理サーバのリソース管理部（ＲＡＣＳ：Resource and Admission Control Subsystem）と複数の転送処理部（Ｉ−ＢＧＦ：Interconnection Border Gateway Function ）を含む次世代の通信ネットワーク（ＮＧＮ：Next Generation Network ）では、インターネットと比較してより一定の品質を保証し、より高い情報セキュリティを担保し、従来の電機通信網回線レベルに近い高信頼性のＩＰ回線を提供するためには、ＳＩＰ信号の通信路（ＳＩＰ信号路）とリソース管理部を実現することが課題となる。
【０００７】
ところで、バックボーンネットワークや中継網において、物理リンクの冗長構成は一般的である。物理的なネットワークでは、その方路への経路中のいずれかの物理リンクの上限がボトルネックになり、最後に加わったユーザのトラヒックにより上限に達する場合、このユーザの影響が他のユーザの通信にも影響を及ぼすことがある。１ホップ程度の物理リンクの冗長であれば、装置からのロードバランスというアプローチ手段も考えられている。
【０００８】
また、アクセスラインでは、ユーザ毎の契約帯域とその上限帯域以内でのサービス利用を許可するために、ユーザがサービスを利用する毎に使用帯域を申告させ、ユーザの申告帯域の積み上げが、ユーザの契約帯域の上限に収まるかどうかを判定している。そして、契約帯域の上限に収まる場合には、通信を許可する受付制御と、受付許可した利用種別毎に実際のトラヒックの通過を許可するピンホール制御を行うことが研究されてきた。ユーザの契約帯域を仮想的なリソースとして仮想パスとして管理するリソース管理サーバによるリソース管理方式がこれにあたる。
【０００９】
しかし、バックボーンや中継網では十分なリソースが用意され、ユーザの契約帯域毎にリソースの受付を判断する必要はない。ただし、中継網では、接続事業者毎に接続を許可する帯域が守られているかどうかを、ユーザ毎に判断する必要がある。仮に自網では、アクセスライン毎およびユーザの契約帯域毎に受付を許可していたとしても、図１２に示すように他網１向けのユーザに偏っていた場合に、接続事業者毎の帯域を超えている場合が考えられる。この場合に、自網のユーザや、他網１と共用している区間でトラヒックが重なって信号遅延やパケットロスなど通信障害が発生する可能性がある。
【００１０】
さらに、他網１への中継網がＩ−ＢＧＦ１とＩ−ＢＧＦ２で冗長構成をとっている場合に、それぞれの性能緒元や接続可能な物理リンクのボトルネックを加味して振り分けをしないと、やはりトラヒックが偏ってしまう可能性がある。
【００１１】
特に、図１３に示すように、複数の接続事業者でＩ−ＢＧＦ２をとりあいになっている場合には、前者と後者のバランスを考えないと、ある接続事業者へのトラヒックが他の接続事業者へのトラヒックに影響を与えてしまう可能性がある。
【００１２】
本発明は、呼処理サーバと転送処理部（Ｉ−ＢＧＦ）を含む自網と、呼処理部を含む他網が接続される網構成において、呼処理サーバのリソース管理部（ＲＡＣＳ）がユーザとの契約に基づくサービス品質を満足させるためのトラヒックの規定と受付制御を実施することができるリソース管理システムおよびリソース管理方法を提供することを目的とする。
【課題を解決するための手段】
【００１３】
第１の発明は、呼処理サーバと１以上の転送処理部を含む自網と、少なくとも１つの呼処理部を含む他網が接続される網構成のリソース管理システムにおいて、呼処理サーバは、ユーザ端末間のＳＩＰネゴシエーションを管理し、セッション状態情報に基づいて呼処理を行う呼処理部と、自網のネットワークを仮想パスとしてリソース管理し、そのリソース量に対してＳＩＰネゴシエーションの結果得られる要求帯域を、ＳＩＰネゴシエーション毎に確立したメディアセッション毎に仮想パスから加減算してリソース管理するリソース管理部と備え、リソース管理部は、自網と他網の網間における所定の帯域上限値と、ネットワークリソース情報およびデータフロー情報に基づく帯域管理によって転送処理部を含む経路帯域を判定して経路選択を行う手段と、１以上の転送処理部から他網と接続するための転送処理部を選択する際に、自網に張られたストリーム数が少ない転送処理部を選択し、ストリーム数が同じ場合は、上り方向と下り方向の使用率の合計が少ない転送処理部を選択する手段とを備える。
【００１４】
ここで、ネットワークリソース情報は、転送処理部区間仮想パス構成情報と、網間仮想パス構成情報と、ＲＡＣＳ受付優先度情報と、ＱｏＳクラス設定情報とを含む。データフロー情報は、ピークレート情報と、ＱｏＳクラス識別情報と、受付優先度と、受付優先クラス識別情報とを含む。セッション状態情報は、ユーザ情報、要求品質情報、経路情報、要求呼処理制御情報、処理状態情報を含む。
【００１５】
また、第１の発明のリソース管理システムにおいて、呼処理サーバは、ユーザが通信時に送受信するメディアトラヒックの帯域確保要求時に転送処理部に対して自網側のポリシング設定を識別する識別子と他網側のポリシング設定を識別する識別子を転送処理部内で一意に識別可能な識別子の払い出しを要求するメッセージを送信し、同時に自網側の識別子と他網側の識別子のペアを識別管理するための転送処理部でユニークな識別子も転送処理部に払い出しを要求し、自網側の識別子と他網側の識別子とこのペアを識別する識別子を転送処理部ごとに記憶する手段を備える。
【００１６】
第２の発明は、呼処理サーバと１以上の転送処理部を含む自網と、少なくとも１つの呼処理部を含む他網が接続される網構成のリソース管理方法において、呼処理サーバの呼処理部は、ユーザ端末間のＳＩＰネゴシエーションを管理し、セッション状態情報に基づいて呼処理を行い、呼処理サーバのリソース管理部は、自網のネットワークを仮想パスとしてリソース管理し、そのリソース量に対してＳＩＰネゴシエーションの結果得られる要求帯域を、ＳＩＰネゴシエーション毎に確立したメディアセッション毎に仮想パスから加減算してリソース管理し、さらに、リソース管理部は、自網と他網の網間における所定の帯域上限値と、ネットワークリソース情報およびデータフロー情報に基づく帯域管理によって転送処理部を含む経路帯域を判定して経路選択を行い、１以上の転送処理部から他網と接続するための転送処理部を選択する際に、自網に張られたストリーム数が少ない転送処理部を選択し、ストリーム数が同じ場合は、上り方向と下り方向の使用率の合計が少ない転送処理部を選択する。
【００１７】
第２の発明のリソース管理方法において、リソース管理部が加入端末からの呼（ＳＩＰ）に対応したサービスセッション制御信号を受信する第１のステップと、呼に対応したセッション状態情報を読み出す第２のステップと、呼に対応した使用可能な候補経路についてネットワークリソース情報を読み出す第３のステップと、ストリーム数および帯域使用率による転送処理部の選択が可能か否かを判定する第４のステップと、第４のステップで転送処理部の選択が可能なときに、呼に対応したデータフロー情報を読み出し、メディアの追加または削除の条件判定を行う第５のステップと、第５のステップの条件を満たさないときに、「ストリーム数が少ない＞帯域使用率が低い」の優先順位に基づいて次優先の転送処理部を選択して第４のステップに戻る第６のステップと、第５のステップの条件を満たすときに、候補経路につき呼に対応したセッション状態情報から仮想パス選択論理を適用した転送処理部を決定する第７のステップと、第７のステップで決定した転送処理部の経路で対応したＳＩＰセッション制御処理を行う第８のステップと、第４のステップまたは第６のステップで転送処理部の選択が不可のときに、呼の帯域確保要求に対してエラー返却を行う第９のステップとを有する。
【発明の効果】
【００１８】
本発明は、ＲＡＣＳがユーザとの契約に基づくサービス品質を満足させるためのトラヒックの規定と受付制御を実施することにより、広く普及しているインターネットと比較して一定の品質を保証するとともに、高い情報セキュリティを提供し、従来の電気通信網回線レベルに近い信頼性のＩＰ回線を確保することができる。
【図面の簡単な説明】
【００１９】
【図１】本発明のリソース管理システムの構成例を示す図である。
【図２】ＳＩＰ信号通信パターンを示す図である。
【図３】ＲＡＣＳが対応するメディア通信路の経路パターンを示す図である。
【図４】帯域管理範囲を説明する図である。
【図５】データフロー情報を示す図である。
【図６】ネットワークリソース情報を示す図である。
【図７】ＱｏＳクラス規定を示す図である。
【図８】メディアの追加削除時の実施条件を示す図である。
【図９】ＲＡＣＳの基本機能フローを示すフローチャートである。
【図１０】自網発メディア通信シーケンスを示す図である。
【図１１】他網発メディア通信シーケンスを示す図である。
【図１２】従来のリソース管理システムの問題点を説明する図である。
【図１３】従来のリソース管理システムの問題点を説明する図である。
【発明を実施するための形態】
【００２０】
図１は、本発明のリソース管理システムの構成例を示す。
図において、通信ネットワーク（ＮＧＮ）１は、リソース管理部（ＲＡＣＳ）１２１と呼処理制御部（ＣＳＣＦ：Call State Control Function ）１２２を含む中継呼処理サーバ１２と、対向呼処理サーバ１３と、転送網１１の転送処理部（Ｉ−ＢＧＦ）１１１，１１２を含む。ＮＧＮ１はＩ−ＢＧＦ１１１経由で他網２と接続し、Ｉ−ＢＧＦ１１１およびＩ−ＢＧＦ１１２経由で他網３と接続している。物理的な接続は、一般的に専有、非専有の中継装置１４を介して接続する。
【００２１】
ＣＳＣＦ１２２から呼の要求を受信したＲＡＣＳ１２１は、ネットワークリソース情報とデータフロー情報に基づく帯域管理により、リソースとＩ−ＢＧＦを含む経路帯域が十分か否かを判定して経路選択を行い、中継呼処理サーバ１２はＳＩＰ信号のセッション状態情報、すなわちユーザ情報、要求品質情報、経路情報、要求呼処理制御情報、処理状態情報の管理により呼処理の決定と実施を行う。ＲＡＣＳ１２１が対象とする転送網１１は、コアルータ（ＣＲ）およびＩ−ＢＧＦを含み他網までの網によって構成される。ＲＡＣＳ１２１のＱｏＳ提供区間は、転送網の帯域をリソースとして論理仮想化したものであり、Ｉ−ＢＧＦごとのＩ−ＢＧＦ区間、Ｉ−ＢＧＦと他網との網間に大別できる。呼処理サーバ間の呼制御信号はＳＩＰ信号を用いて行われる。
【００２２】
図２は、ＳＩＰ信号の通信パターンを示す。
図において、ＳＩＰ信号（invite,update 等) は、物理的にはユーザ通信のメディアトラヒックが流れるルートとは別のルートを通る。ＲＡＣＳ１２１が対応するＳＩＰ信号は、ＣＳＣＦ１２２がＲＡＣＳ１２１と連携し、図中両端のＣＳＣＦ（またはＳＩＰサーバまたはパケット転送装置）１６，１７を経由して加入者網から他網へ、他網から加入者網へ転送する。このＳＩＰ信号によるユーザ端末間のネゴシエーション結果に伴いユーザ端末間のエンドツーエンドでメディアセッションが確立されメディア通信が開始される。このメディア通信は、Ｉ−ＢＧＦ１１１またはＩ−ＢＧＦ１１２を経由して転送網１１で行われる。
【００２３】
図３は、ＲＡＣＳが対応するメディア通信路の経路パターンを示す。
図において、ネットワークリファレンスモデルにおいて、ＲＡＣＳ１２１が対象とする経路は、Ｉ−ＢＧＦ１１１と他網２との間の網間、Ｉ−ＢＧＦ１１２と他網３との間の網間、Ｉ−ＢＧＦ１１３と他網４との間の網間である。
【００２４】
ＲＡＣＳ１２１では、帯域管理を行うにあたってネットワークの論理抽象化を行う。すなわち、物理ネットワーク構成および物理帯域を他網ごとの仮想パス（網間仮想パス）、およびＩ−ＢＧＦごとにＩ−ＢＧＦの転送能力を論理抽象化した仮想パス（Ｉ−ＢＧＦ区間仮想パス）から構成される仮想パスネットワークとして論理抽象化することにより管理する。これにより、他網までの物理リンク速度や経路の考え方を集約して単純化でき、かつ各ネットワーク上のＩ−ＢＧＦを直接制御することなく入り口での集中制御が可能になる。また、Ｉ−ＢＧＦのボトルネックを加味した管理や経路の故障管理が可能となり、他網ごとの仮想パスと合せて網間での共用部分を管理することができる。
【００２５】
また、ＲＡＣＳ１２１は、Ｉ−ＢＧＦごとのセッション数上限値および抽象化した論理帯域の上限値を記憶し、メモリなど一時領域にて使用中セッション数と論理帯域の積み上げ、積み下げの管理を行う。また、ＲＡＣＳ１２１は、使用中セッション（Ｉ−ＢＧＦを使用するメディアストリーム数）の少ないＩ−ＢＧＦを選択し、同じ場合は帯域使用率すなわち使用帯域の少ないＩ−ＢＧＦを選択する。
【００２６】
ＲＡＣＳの帯域管理範囲と帯域管理区分については次の通りである。
ＲＡＣＳの帯域管理範囲は、図４に示すように、Ｉ−ＢＧＦ区間仮想パスと網間仮想パスの２つに分けて帯域を管理する。網間仮想パスは、１または複数の物理インタフェースで構成される帯域上限を仮想パス上限帯域として管理する。Ｉ−ＢＧＦ区間仮想パスは、Ｉ−ＢＧＦ単位で帯域の積み上げ、積み下げを管理する。
【００２７】
帯域管理区分は、上限帯域をＱｏＳクラスの粒度に分けて帯域を管理する。ＱｏＳクラスとは、図７に示すように、ＩＴＵ−Ｔ  Ｙ.1540 のクラス０からクラス５をＮＧＮのＱｏＳクラスとして４つ（ａからｄ）に分類しなおしたものである。パケットの転送は、ＩＥＴＦのdiffservの規定クラス（ＥＦからＢＥ）とマッピングして転送処理装置を制御する。パケットは、転送網ではdiffservクラスの振る舞いをする。網間仮想パスおよびＩ−ＢＧＦ区間仮想パスそれぞれにおいて、ＱｏＳクラス粒度でそれぞれ帯域を管理する。同一の帯域確保要求中に複数の優先度のメディアフロー用の帯域を確保する要求が含まれていた場合に、優先度の高いＱｏＳを指定したメディアフローを優先的に仮想パスに割り付けて記憶する。
【００２８】
ＲＡＣＳが行う帯域管理の方法では、データフロー情報やネットワークリソース情報が使われる。データフロー情報には、図５に示すように、発ＩＰ／着ＩＰ／プロトコル／着ポート／発ポートを含むデータフロー識別情報と、ピークレートの値と、ＱｏＳクラス識別情報と、ＲＡＣＳの受付優先度情報と、受付優先クラス識別情報とがある。ここで、データフロー情報の中のＴＧＮ番号は方路を表す通番であり、０や１などである。ＳＩＰルートは、ＳＩＰ信号を通す経路を表す番号であり、０や１などである。
【００２９】
ネットワークリソース情報には、図６に示すように、Ｉ−ＢＧＦ区間仮想パス構成情報としてＩ−ＢＧＦ区間仮想パス上限帯域およびＱｏＳクラス上限帯域（Ｉ−ＢＧＦ区間仮想パス上限帯域に対する割合）と、網間仮想パス構成情報として網間仮想パス構成情報として網間仮想パス上限帯域およびＱｏＳクラス上限帯域（網間仮想パス上限帯域に対する割合）と、ＲＡＣＳ受付優先度情報（上限帯域に対する割合）と、ＱｏＳクラス設定情報としてバッファ時間／バースト比例情報／遅延ゆらぎ係数／帯域補正係数とがある。バッファ時間は、ＲＡＣＳが制御するパケット転送処理装置が吸収できるパケット転送のゆらぎ、遅延時間の合計である。時間が大きいほど、多くのパケットを受信して蓄積することができ、パケット転送のゆらぎや遅延時間を吸収することができる。制御補正係数は、ＲＡＣＳがパケット転送処理装置を制御するときの補正係数であり、制御時に設定した値でパケット転送処理装置が振る舞うことができないときに補正するための値である。例えば、パケット転送処理装置の能力を考慮して帯域補正係数を所望の値の 1.2倍に設定することにより、パケット転送処理装置が所望の値に対応する振る舞いが可能となる。帯域補正係数は、パケット転送処理装置が設定値に対して、レイヤ２の設定値として扱うか、レイヤ３の設定値として扱うかを補正する係数となっている。
【００３０】
ＲＡＣＳの帯域制御論理に関して、以下の考慮に基づいた処理を行う。まず、最低限１パケット分が通過できるように、バースト許容値の最低値を規定する。次に、トラヒックの擾乱を考慮した係数（帯域補正係数）ｂk はトークンレート、バースト許容値ともにそれぞれ乗算する。転送処理装置への設定値と実際の転送網でのパケットの振る舞いとの差分を補完するための係数（制御補正係数）gnはトークンレート、バースト許容値ともにそれぞれ乗算する。
【００３１】
(1) 確保帯域（積み上げ帯域）として、ｒi'=max[(ａk＋ｄk)/Ｄk＊ｒi , ｒi] とする。ＣＳＣＦは、ＲＴＣＰ分を含まない帯域をMax requested bandwidth として帯域確保要求メッセージで指定する。ＣＳＣＦはＲＴＣＰの有無を指定し、ＲＴＣＰ分帯域はＲＡＣＳで計算をする。すなわち、ＲＡＣＳでメディアが存在する方向のトラヒックは指定帯域の1.05倍、メディアが存在しない方向についてもＣＳＣＦはＲＴＣＰの有無を指定し、ＲＴＣＰ有の場合はメディアが存在する方向の0.05倍をメディアが存在しない方向の帯域量として帯域制御を行う。特定音声コーデックの場合は、ＲＡＣＳで1.05となることを考慮した値をＲＡＣＳに通知する。
【００３２】
(2) トークンレートとして sdr＝max[gn*ｂk*ｒi/8,rmin]とする。
(3) バースト許容値として mbs＝min｛smax,max[gn*ｂk*ｒi*(ａk＋ｄk)/8/1000,smin]｝とする。ここで、rminは最少トークンレート、sminは最小バースト許容値、smaxは最大バースト許容値である。
【００３３】
また、ＣＳＣＦからＲＡＣＳに対して片方向通信として指定された場合で、RTP/AVP の場合は、反対方向のトラヒックも考慮する。ＲＴＳＰの双方向分はＣＳＣＦが独立したメディアとしてＲＡＣＳに要求する。rmin、smin、smaxはクラス毎に設定可能とする。保守者が投入するrminの値は、当初は０を推奨する。各設定値が「０」時は、計算を行わないこととする。
【００３４】
すなわち、転送処理装置のバッファ可能時間と流入トラヒックのクラス毎の遅延ゆらぎ量の他に、最小トークンレートと最小バースト許容サイズと最大許容バーストサイズを記憶する。転送処理装置に流入を許可するトラヒックのトークンレートとバースト許容値とを設定する際に、ユーザ間のＳＩＰネゴシエーションで決定した要求帯域から、それぞれトラヒックの擾乱を考慮した係数と転送処理装置への設定粒度を考慮した係数を乗算して一次的なトークンレートと一次的なバースト許容値を算出した後、それぞれ記憶している最少値と比較して大きい方の値、記憶している最大値と比較して小さい方の値を算出結果として転送処理装置に設定し、トラヒックの流入制限を行う。
【００３５】
図８は、メディアの追加削除時の実施条件を示す。
ここで、Ａは既存メディアの合計であり、Ｍは上限帯域であり、Ｘは追加メディア分合計であり、Ｙは削除メディアであるとき、メディアの追加削除時の実施条件として
Ａ＋Ｘ−Ｙ≦Ｍ
を満たす場合に一時的に許容する。すなわち、ＳＩＰ信号上は複数のメディアフローが要求されている場合に、ＣＳＣＦからＲＡＣＳへの帯域確保要求の予約時、確保時に、その帯域確保要求中にはメディアの削除と追加の要求が含まれている場合がある。もちろん変更なしのメディアが含まれている場合もある。これらは帯域確保要求ごとに、過不足を計算した上でリソースから積み上げ、積み下げを実施する。例えば、一回の帯域確保要求の中に、追加メディアと削除メディアが含まれる場合に、追加メディアの帯域に対して削除しようとするメディアの帯域の方が大きい場合には、必ず帯域の確保が可能となる。
【００３６】
ＲＡＣＳがＩ−ＢＧＦを選択する際の論理と方法について説明する。
まず、ＲＡＣＳは、各Ｉ−ＢＧＦを使用するメディアフロー数により選択を行い、次に帯域による選択を行う。メディアフロー数による選択は、メディアフロー数が少ないＩ−ＢＧＦを選択する。音声呼のみの場合には、メディアフロー数による選択により複数のＩ−ＢＧＦを順番に使用することになる。ＮＧＮでは、音声のみの呼だけでなく、ビデオ呼も使用される。この場合、メディアフロー数以外に使用帯域を考慮しなければ、帯域を使い切る前にメディアフロー数による頭打ちとなる場合もある。使用帯域によるＩ−ＢＧＦ選択は、Ｉ−ＢＧＦ区間仮想パスの帯域使用率を参照し、その中で最も帯域使用率の低いＩ−ＢＧＦを選択する。帯域の使用率は上り方向／下り方向で異なるため、帯域使用率の最も低いＩ−ＢＧＦを選択する際には、上り方向／下り方向の使用率の加算結果を元に比較する。その理由は、上り方向／下り方向の使用率をそれぞれ判別することにすると、ユーザからの要求が同一メディアに対して異なるＩ−ＢＧＦを設定する危険性があるためである。帯域使用率が同値のＩ−ＢＧＦ区間仮想パスが複数存在していた場合、どのＩ−ＢＧＦを選択するかについては規定しない。サービス提供状況により、音声呼が支配呼となるか、ビデオ呼が支配呼になるかによって、フロー数による選択と帯域使用率による選択の優先順位を入れ替える機能を提供する。例えば、テレビ電話などの動画通信が増えると、コーデック種別などにより必要帯域が偏るため、帯域による振り分けを優先するようにしてもよい。
【００３７】
ＳＩＰ信号の通信路を確立するまでのＩ−ＢＧＦ選択は、まず保守者が特定のＩ−ＢＧＦに対して、あらかじめ確立可否を設定する。２つのＩ−ＢＧＦに対して、それぞれ事業者ごとに冗長用経路の０または１の確立可否を設定する。ＲＡＣＳは、ＣＳＣＦからＳＩＰ信号の通信路確立の契機を与えられて、指定された０または１のＳＩＰ信号の通信路を設定許可されたＩ−ＢＧＦのストリーム数の上限チェックを実施し、当該Ｉ−ＢＧＦに対してＳＩＰ信号の通信路の設定とＩ−ＢＧＦへの制御を行う。
【００３８】
メディアフローのＩ−ＢＧＦ選択論理について説明する。
ＲＡＣＳは、各Ｉ−ＢＧＦの基本情報を記憶する。制御用のＩＰアドレス、最大ストリーム数、Ｉ−ＢＧＦのパケット転送処理性能をリンクの物理帯域量を表すbps に見立ててＩ−ＢＧＦ仮想パス最大帯域として記憶する。なお、bps への換算計算は、パケット転送処理能力であるpps をパケットサイズを元にbps に換算する。上り下りの帯域計算として1/2 する。
【００３９】
Ｉ−ＢＧＦを通過する物理リンクにボトルネックがある場合を想定して、以下のように算出する。「ＲＡＣＳとＩ−ＢＧＦ間のリンク帯域（転送処理装置内のボトルネックとなりうるリンクを含む）」と、「pps をbps に換算した帯域／２」の小さい方の値を取得する。ＲＡＣＳとＩ−ＢＧＦ間にリンクがない場合、Ｉ−ＢＧＦの処理能力以外にボトルネックがないため、上り下りを区別せず、上り下り合計帯域とする。
【００４０】
また、ＲＡＣＳに登録したＩ−ＢＧＦごと、対向する他網ごとにユーザ通信用に使用するＩ−ＢＧＦを設定する。例えば、他網１向けにはＩ−ＢＧＦ＃１とＩ−ＢＧＦ＃２、他網２向けにはＩ−ＢＧＦ＃２とＩ−ＢＧＦ＃３を通過することを設定する。これらをメディアルートと呼ぶ。
【００４１】
Ｉ−ＢＧＦ選択は、Ｉ−ＢＧＦ数≠メディアルート数の場合、その他網向けに使用できるメディアルートが設定されたＩ−ＢＧＦの選択となる。
【００４２】
当該他網向けに使用可能な複数のＩ−ＢＧＦに対してストリーム数による選択方法について説明する。ストリーム数上限やＩ−ＢＧＦ故障によってＩ−ＢＧＦが選択できなかった場合は、帯域確保要求に対してエラーを返却する。ストリーム数による選択の結果、Ｉ−ＢＧＦが複数選択された場合は、帯域による選択を行う。帯域による選択の結果、Ｉ−ＢＧＦが複数選択された場合は、選択されたＩ−ＢＧＦの中から任意のＩ−ＢＧＦを選択する。選択されたＩ−ＢＧＦに対して溢れ判定を行い、溢れ判定がＯＫである場合にそのＩ−ＢＧＦを選択する。溢れ判定がＮＧの場合は、「ストリーム数が少ない＞帯域使用率が低い」の優先順位に基づき、次優先のＩ−ＢＧＦの選択を行い、溢れ判定を繰り返す。ここで、「＞」は優先順位の高低を表す。最終的に溢れ判定がＯＫとなるＩ−ＢＧＦが選択できなかった場合は、帯域確保要求に対してエラーを返却する。
【００４３】
図９は、ＲＡＣＳ１２１の基本機能フローを示す。
ステップＳ１では、ＲＡＣＳ１２１は加入端末からＳＩＰ呼に対応したサービスセッション制御信号を受信し、ステップＳ２へ進む。
ステップＳ２では、このＳＩＰ呼に対応したセッション状態情報を読み出し、ステップＳ３へ進む。
【００４４】
ステップＳ３では、このＳＩＰ呼に対応した使用可能な候補経路についてネットワークリソース情報を読み出し、ステップＳ４へ進む。
ステップＳ４では、ストリーム数／帯域使用率によるＩ−ＢＧＦの選択ができたか否かを判定し、Ｉ−ＢＧＦの選択ができた場合にステップＳ５へ進み、Ｉ−ＢＧＦの選択ができない場合にステップＳ９へ進む。
ステップＳ９では、このＳＩＰ呼の帯域確保要求に対してエラーを返却する。
【００４５】
ステップＳ５では、溢れ判定を行う。すなわち、このＳＩＰ呼に対応したデータフロー情報を読み出し、メディア追加・削除の実施条件（上記のＡ＋Ｘ−Ｙ≦Ｍ）を満たすか否かを判定し、実施条件を満たす場合に一時的に許容してステップＳ７へ進み、実施条件を満たさない場合にステップＳ６へ進む。
【００４６】
ステップＳ６では、「ストリーム数が少ない＞帯域使用率が低い」の優先順位に基づいて次優先のＩ−ＢＧＦの選択ができたか否かを判定し、Ｉ−ＢＧＦの選択ができた場合にステップＳ５へ戻り、Ｉ−ＢＧＦの選択ができない場合にステップＳ９のエラー返却へ進む。
ステップＳ７では、候補経路について、このＳＩＰ呼に対応したセッション状態情報から仮想パス選択論理を適用したＩ−ＢＧＦを決定し、ステップＳ８に進む。
【００４７】
ステップＳ８では、このＳＩＰ呼にＩ−ＢＧＦ経由で対応したＳＩＰセッション制御処理を行う。このＳＩＰセッション制御処理は、以下に示すように、選択したＩ−ＢＧＦのＩ−ＢＧＦ区間仮想パスでのリソース確保と、選択したＩ−ＢＧＦに対するポリシー制御などである。
【００４８】
メディアフロー通信を開始する際には、呼処理制御部（ＣＳＣＦ）において、ＳＩＰ−ＩＮＶＩＴＥメッセージのＳＤＰから必要パラメータを取り出し、呼処理サーバのＲＡＣＳに対して制御要求情報を送信する。ＲＡＣＳは、制御要求パラメータの事業者ＩＤより、Ｉ−ＢＧＦおよび収容物理ポートを抽出し、さらに物理リンクまたはＶＬＡＮ−ＩＤが抽出できる場合は抽出し、事業者毎のＳＩＰ信号路に結びついたメディアルートに沿った仮想パス毎に帯域判定を行う。ただし、ＩＮＶＩＴＥ受信時の制御では、着側のＩＰアドレスおよびポート番号は特定できないことから、Ｉ−ＢＧＦでのポリシー制御の有効化は行われない。ＳＩＰメッセージの応答である１８３Ｗ／ＳＤＰまたは２００Ｗ／ＳＤＰメッセージから、ＣＳＣＦが着側のＩＰアドレスおよびポート番号を抽出し、ＲＡＣＳが２回目の制御要求パラメータを受信し、その情報に従ってＩ−ＢＧＦを制御した際にポリシーが有効化される。すなわち、Ｉ−ＢＧＦでは、発着ＩＰアドレス、発着ポート番号などの全ての制御のための情報が揃ったときにポリシーを有効化する。
【００４９】
ＲＡＣＳがＩ−ＢＧＦをポリシー制御する際には、発ＩＰアドレス、発ポート番号、着ＩＰアドレス、着ポート番号、プロトコル種別（ＩＰ／ＴＣＰ／ＵＤＰ）、ピークレート、ピークパケットサイズ、ＤＳＣＰ値などのパラメータが使われる。ＲＡＣＳでは、発ＩＰアドレス、発ポート番号、着ＩＰアドレス、着ポート番号、プロトコル種別までのパラメータをクラシファイ・パラメータとして、Ｉ−ＢＧＦに対してポリシー制御を行う。また、ＳＩＰシグナリングポート開通時、およびＭＥＧＡＣＯによるメディアフロー制御時それぞれにおいて、ピークレートとピークパケットサイズを制御パラメータとして用いる。ピークレートとピークパケットサイズの制御パラメータは、他網側のターミネーション（Termination ）に対して設定され、これらのパラメータを元にＩ−ＢＧＦでの流入制御を行う。ＤＳＣＰ値を用いたパケットの優先制御は、他網側および自網側のターミネーションに対して設定され、本パラメータを元にＩ−ＢＧＦでの優先制御を行う。
【００５０】
ＲＡＣＳは、ＭＥＧＡＣＯプロトコルを用いてＩ−ＢＧＦの自網側ターミネーションと他網側ターミネーションに、ＮＡＰＴ制御が動作するようにそれぞれのローカルアドレスとグローバルアドレス、ポート番号、ＤＳＣＰ値を設定することでポリシー制御を行う。
【００５１】
図１０は、本発明における自網発メディア通信シーケンスを示す。
図において、中継呼処理サーバ１２は、呼処理制御部（ＣＳＣＦ）１２２とリソース管理部（ＲＡＣＳ）１２１からなる。中継呼処理サーバ１２は、対向呼処理サーバ１３Ａまたはパケット転送処理装置から送信元情報(8) を格納したSIPinvite 信号を受信し、送信元装置に対して100trying 信号を返却し、受信したSIPinvite 信号を記憶する。
【００５２】
ＣＳＣＦ１２２は、ＲＡＣＳ１２１に対して帯域確保要求メッセージにより送信元情報(8) を通知し、帯域確保要求を行う。この帯域確保要求には、複数のメディアフローごとにそれぞれ必要な上り下りの要求帯域が含まれる。また、メディアフローごとにパケットの振る舞いであるＤＳＣＰに相当するクラスが指定される。また、対向サーバを特定する方路情報が含まれる。この方路情報には、対向者識別子と対向者識別子内のコントロール信号路の通番が含まれる。
【００５３】
ＲＡＣＳ１２１は、Ｉ−ＢＧＦごとに仮想化した上り下りそれぞれのクラスごとの上限帯域から要求されたメディアフローごとの帯域を取得可能か否か残帯域と比較する。帯域取得が不可能な場合は、即座に帯域確保要求にＮＧ応答する。全てのメディアフローに対して帯域取得可能な場合は、ＲＡＣＳ１２１はＩ−ＢＧＦに対して、送信元情報(8) を指定したターミネーションの作成指示を行う。ターミネーションのステータスは、ＯＵＳで作成する。
【００５４】
ＲＡＣＳ１２１は、Ｉ−ＢＧＦに対してコントロール信号路を特定する情報と信号の方向性まで設定する。Ｉ−ＢＧＦは、その中でターミネーションをユニークに決定する識別子の付与を行ってＲＡＣＳ１２１に返信し、ＲＡＣＳ１２１はこれをＩ−ＢＧＦごとに記憶する。すなわち、ＲＡＣＳ１２１は、Ｉ−ＢＧＦに対してポリシング設定する際、同時に自網側と他網側のターミネーション作成を同一メッセージ上で試みる。この際、リソース管理サーバは、ターミネーションの組み合わせをcontext として識別し保存する。ただし、contecxtの識別子も、一回目の設定時はワイルドカードで指定したメッセージをＩ−ＢＧＦに送信して、Ｉ−ＢＧＦで払いだす。一方、Ｉ−ＢＧＦでターミネーションIDはユニークであり、識別子、IP/group/interface/id の/id 以下は、自網側と他網側で異なった識別子が払いだされるため、ターミネーションのセットを決定できる概念がcontext となる。メディアのターミネーションが格納されたcontext の中にはメディアのターミネーションの自網、他網のペアが格納される。他のペアは格納しない。モニタ設定をして、トラヒックのコピーをＩ−ＢＧＦから外部へ転送する場合にのみ、もうひとつのターミネーションが格納される。
【００５５】
これにより、ターミネーション情報をＩ−ＢＧＦごとにユニークに保持する。以後、ターミネーション識別子として、ＲＡＣＳ１２１とＩ−ＢＧＦとのユニークな識別子として制御に用いる。
【００５６】
Ｉ−ＢＧＦは、ＲＡＣＳ１２１に対してＳＩＰ信号の送信元情報(8) に対応するＳＩＰ信号の送信先に通知するべき送信元情報(3) を応答する。ＲＡＣＳ１２１は、帯域確保要求メッセージの応答にＳＩＰ信号の送信先に通知するべき送信元情報(3) を応答する。
【００５７】
ＣＳＣＦ１２２は、保存していたSIPinvite 信号について送信元情報(8) を送信元情報(3) として、対向呼処理サーバ１３Ｃまたはパケット転送処理装置に送信する。また、ＣＳＣＦ１２２は、対向呼処理サーバ１３Ｃからの180ringing信号を対向呼処理サーバ１３Ａに転送し、対向呼処理サーバ１３ＡからＰＲＡＣＫ信号があった場合は対向呼処理サーバ１３Ｃに転送する。さらに、ＣＳＣＦ１２２は、対向呼処理サーバ１３Ｃから送信元情報(6) を格納した 200ＯＫ信号を受信して記憶する。
【００５８】
ＣＳＣＦ１２２は、ＲＡＣＳ１２１に対して帯域確保要求メッセージにより送信元情報(6) を通知し、帯域確保要求を行う。この帯域確保要求には、複数メディアフロー分それぞれに必要な上り下りの要求帯域が含まれる。また、対向サーバを特定する方路情報が含まれる。この方路情報には、対向者識別子と対向者識別子内のコントロール信号路の通番が含まれる。
【００５９】
ＲＡＣＳ１２１は、Ｉ−ＢＧＦに対してメディアフローごとにユニークなターミネーション識別子を用いて送信元情報(6) を指定したターミネーションの変更指示を行う。ステータスをＩＮＳにする。同時に、メディアフローごとに要求帯域にパケット転送処理装置ごとに記憶するパケット転送処理装置で所望の要求帯域を得られるようにするための制御補正係数を乗じた帯域量と、各クラスごとに到着パケットのバースト性を考慮したパケットが遅延してまとまった時間分のバースト比例係数を乗じたバースト量を設定する。
【００６０】
Ｉ−ＢＧＦは、ＲＡＣＳ１２１に対してＳＩＰ信号の送信元情報(6) に対応するＳＩＰ信号の送信先に通知するべき送信元情報(4) を応答する。ＲＡＣＳ１２１は、帯域確保要求メッセージの応答にＳＩＰ信号の送信先に通知するべき送信元情報(4) を応答する。ＣＳＣＦ１２２は、保存していたSIPinvite 信号について送信元情報(6) を送信元情報(4) として、対向呼処理サーバ１３Ａまたはパケット転送処理装置に送信する。
【００６１】
図１１は、他網発メディア通信シーケンスを示す。
図において、他網発の要求呼の処理については、Ｉ−ＢＧＦを経由して中継呼処理サーバ１２がSIPinvite 信号を受信して始まる。中継呼処理サーバ１２は、対向呼処理サーバ１３Ｄまたはパケット転送処理装置から送信元情報(6) を格納したSIPinvite 信号を受信し、送信元装置に対して100trying 信号を返却し、受信したSIPinvite 信号を記憶する。
【００６２】
ＣＳＣＦ１２２は、ＲＡＣＳ１２１に対して帯域確保要求メッセージにより送信元情報(6) を通知し、帯域確保要求を行う。この帯域確保要求には、複数のメディアフローごとにそれぞれ必要な上り下りの要求帯域が含まれる。
【００６３】
ＲＡＣＳ１２１は、Ｉ−ＢＧＦごとに仮想化した上り下りそれぞれのクラスごとの上限帯域から要求されたメディアフローごとの帯域を取得可能か否か残帯域と比較する。帯域取得が不可能な場合は、即座に帯域確保要求にＮＧ応答する。全てのメディアフローに対して帯域取得可能な場合は、ＲＡＣＳ１２１はＩ−ＢＧＦに対して、送信元情報(6) を指定したターミネーションの作成指示を行う。ＲＡＣＳ１２１は、Ｉ−ＢＧＦに対してコントロール信号路を特定する情報と信号の方向性まで設定する。
【００６４】
Ｉ−ＢＧＦは、その中でターミネーションをユニークに決定する識別子の付与を行ってＲＡＣＳ１２１に返信し、ＲＡＣＳ１２１はこれをＩ−ＢＧＦごとに記憶する。これにより、ターミネーション情報をＩ−ＢＧＦごとにユニークに保持する。以後、ターミネーション識別子として、ＲＡＣＳ１２１とＩ−ＢＧＦとのユニークな識別子として制御に用いる。
【００６５】
Ｉ−ＢＧＦは、ＲＡＣＳ１２１に対してＳＩＰ信号の送信元情報(6) に対応するＳＩＰ信号の送信先に通知するべき送信元情報(4) を応答する。ＲＡＣＳ１２１は、帯域確保要求メッセージの応答にＳＩＰ信号の送信先に通知するべき送信元情報(4) を応答する。
【００６６】
ＣＳＣＦ１２２は、保存していたSIPinvite 信号について送信元情報(6) を送信元情報(4) として、対向呼処理サーバ１３Ｅまたはパケット転送処理装置に送信する。また、ＣＳＣＦ１２２は、対向呼処理サーバ１３Ｅからの180ringing信号を対向呼処理サーバ１３Ｄに転送し、対向呼処理サーバ１３ＤからＰＲＡＣＫ信号があった場合は対向呼処理サーバ１３Ｅに転送する。さらに、ＣＳＣＦ１２２は、対向呼処理サーバ１３Ｅから送信元情報(8) を格納した 200ＯＫ信号を受信して記憶する。
【００６７】
ＣＳＣＦ１２２は、ＲＡＣＳ１２１に対して帯域確保要求メッセージにより送信元情報(8) を通知し、帯域確保要求を行う。ＲＡＣＳ１２１は、Ｉ−ＢＧＦに対してメディアフローごとにユニークなターミネーション識別子を用いて送信元情報(8) を指定したターミネーションの変更指示を行う。
【００６８】
Ｉ−ＢＧＦは、ＲＡＣＳ１２１に対してＳＩＰ信号の送信元情報(8) に対応するＳＩＰ信号の送信先に通知するべき送信元情報(3) を応答する。ＲＡＣＳ１２１は、帯域確保要求メッセージの応答にＳＩＰ信号の送信先に通知するべき送信元情報(3) を応答する。ＣＳＣＦ１２２は、保存していたSIPinvite 信号について送信元情報(8) を送信元情報(3) として、対向呼処理サーバ１３Ｄまたはパケット転送処理装置に送信する。
【００６９】
また、Ｕプレーンのセッションのリフレッシュタイミングについて、ＲＡＣＳは次のように動作する。ＲＡＣＳを含めて中継呼処理サーバでは固定的なタイミングをもたず、Re-INVITE/UPDATE受信時にセッションのリフレッシュを行う。ＲＡＣＳにおけるリフレッシュ受信の監視は、ＳＩＰセッションのExpire値/2＋30秒となる。リフレッシュのタイマが満了した場合にＲＡＣＳからＣＳＣＦに通知を行う。さらに、ＳＩＰセッションのExpire値/2秒間リフレッシュを受けなかった場合、ＲＡＣＳはセッションを開放し、ＣＳＣＦにセッションの開放通知を行う。
【符号の説明】
【００７０】
１  通信ネットワーク（ＮＧＮ）
２，３  他網
１１  転送網
１２  中継呼処理サーバ
１３  対向呼処理サーバ
１４  中継装置
１１１〜１１３  転送処理部（Ｉ−ＢＧＦ）
１２１  リソース管理部（ＲＡＣＳ）
１２２  呼処理制御部（ＣＳＣＦ）
【図１】
2010103968.tif 000003
【図２】
2010103968.tif 000004
【図３】
2010103968.tif 000005
【図４】
2010103968.tif 000006
【図５】
2010103968.tif 000007
【図６】
2010103968.tif 000008
【図７】
2010103968.tif 000009
【図８】
2010103968.tif 000010
【図９】
2010103968.tif 000011
【図１０】
2010103968.tif 000012
【図１１】
2010103968.tif 000013
【図１２】
2010103968.tif 000014
【図１３】
2010103968.tif 000015