呼制御方法、システム、及びサーバー、並びにセッション・ボーダー・コントローラー
【課題】本発明の目的は、帯域情報だけでなくパケット処理性能を考慮した呼の受付制御を行う方法、システム、及び装置を提供することである。
【解決手段】複数の端末、前記複数の端末からのパケットを滞留させる入力バッファを有するセッション・ボーダー・コントローラー(SBC)、前記SBCを制御する呼制御サーバーを有するネットワークにおける呼制御方法が提供される。当該方法は、(a)前記SBCは前記入力バッファを監視し、所定の輻輳閾値を超えてパケットが滞留しているか否かを決定する段階、(b)前記所定の輻輳閾値を超えてパケットが滞留していると決定された場合、前記SBCは前記呼制御サーバーへ輻輳を通知する段階、(c)前記呼制御サーバーは前記SBCに対し、新たな呼を受け付けないよう指示する段階、を有する。
【解決手段】複数の端末、前記複数の端末からのパケットを滞留させる入力バッファを有するセッション・ボーダー・コントローラー(SBC)、前記SBCを制御する呼制御サーバーを有するネットワークにおける呼制御方法が提供される。当該方法は、(a)前記SBCは前記入力バッファを監視し、所定の輻輳閾値を超えてパケットが滞留しているか否かを決定する段階、(b)前記所定の輻輳閾値を超えてパケットが滞留していると決定された場合、前記SBCは前記呼制御サーバーへ輻輳を通知する段階、(c)前記呼制御サーバーは前記SBCに対し、新たな呼を受け付けないよう指示する段階、を有する。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、呼制御方法、システム、及びサーバー、並びにセッション・ボーダー・コントローラーに関し、より詳細には、複数の端末、前記複数の端末からのパケットを滞留させる入力バッファを有するセッション・ボーダー・コントローラー(SBC)、前記SBCを制御する呼制御サーバーを有するシステムにおける呼制御に関する。
【背景技術】
【0002】
インターネットの急速な普及に伴い、近年ではより高速な双方向広帯域サービスが望まれるようになった。更に固定通信と移動体通信の連携、電話網と放送網とインターネットの融合、コストの削減、サービス品質の向上、等が望まれている。これらを実現するために国際電気通信連合(International Telecommunication Union:ITU−T)、欧州電気通信標準化協会(European Telecommunications Standards Institute:ETSI)、IETF(Internet Engineering Task Force)等の標準化団体は次世代ネットワーク(Next Generation Network:NGN)技術の規格を制定し、世界各国でNGNが構築され始めている。
【0003】
NGNはインターネット・プロトコル(IP)や非同期転送モード(ATM)などに基づくパケット転送ノードにより接続された呼制御サーバーとルータとセッション・ボーダー・コントローラー(SBC)により端末間及び事業者間を接続し、電話やビデオ配信などをサービスとして提供するネットワークであり、(1)セッションの確立・切断のために、IP電話でも用いられる制御用通信プロトコルであるSIP(Session Initiation Protocol)が用いられる、(2)帯域確保のようなQoS(サービス品質)制御やNAT/ファイアウォールのようなセキュリティに関する処理を行う制御装置が設けられる、等を特徴とする。
【0004】
図1はNGN100における従来の呼制御サーバーとSBCの動作を説明するシステム構成図である。このような構成は非特許文献1に記載されている。図1の上半分に示されるNGN100は、端末110a、110b、当該端末からのパケットを滞留させる入力バッファを有し当該端末間のセッションを制御するSBC120、SBC120を制御する呼制御サーバー130、それらを接続する事業者Aのネットワーク140a及び事業者Bのネットワーク140bを有する。呼制御サーバー130は、自身に設定されているSBC120の性能限界に応じて呼の受付制御を行い、SBC120を通るトラヒックの品質を確保する。呼の受付制御を行う際に、呼制御サーバー130はセッション記述プロトコル(Session Description Protocol:SDP)で定められたセッション記述を参照するが、一般に当該セッション記述が有する性能限界に関する情報は帯域情報のみである。
【0005】
図2は従来の呼制御サーバーが帯域を管理する場合の発呼受付シーケンスである。段階202で、端末110aは発呼する。段階204で、呼制御サーバー130はセッション記述に記載された帯域情報を加算し、端末110aを含む接続事業者から要求されているトラヒックの帯域の合計x1+x2+x3+x4を計算する。ここで当該帯域の合計がSBC120の性能限界であるXMbit/sより少なかった場合、つまりX>x1+x2+x3+x4となった場合に、段階206で、呼制御サーバー130はSBC120へ呼設定情報を送信する。呼設定情報は、例えば端末110aのアドレス、端末110aがSBCへ送るための宛先アドレス、端末110bのアドレス、端末110bがSBCへ送るための宛先アドレス、トラヒック疎通帯域、当該トラヒックが通る物理インターフェースである。段階208で、SBC120は当該呼設定情報に従い呼を設定すると、呼制御サーバー130へ設定完了メッセージを送信する。段階210で、呼制御サーバー130は段階202で受けた呼を端末110bへ転送する。段階212で、端末110bは端末110aへ呼を受け付けたことを通知する。段階214で、端末110aと端末110bとの間で通話が実現する。
【0006】
図3は、従来のSBCが帯域を管理する場合の発呼受付シーケンスである。段階302で、端末110aは発呼する。段階304で、呼制御サーバー130はSBC120へ図2の段階206と同様の呼設定情報を送信する。段階306で、SBC120は図2の段階204と同様の方法でトラヒックの帯域の合計を計算し、SBC120の性能限界と比較する。当該帯域の合計がSBC120の性能限界であるXMbit/sより少なかった場合、段階308で、SBC120は呼制御サーバー130へ設定完了メッセージを送信する。段階310〜段階314は図2の段階210〜段階214と同様である。
【0007】
図4は従来の呼制御サーバーが帯域を管理する場合の発呼受付拒否シーケンスである。段階402で、端末110aは発呼する。段階404で、呼制御サーバー130は図2の段階204と同様の方法でトラヒックの帯域の合計を計算し、SBC120の性能限界と比較する。当該帯域の合計がSBC120の性能限界であるXMbit/sより多かった場合、段階406で、呼制御サーバー130は端末110aへ発呼受付拒否メッセージを送信し、段階402の発呼を拒否する。
【0008】
図5は従来のSBCが帯域を管理する場合の発呼受付拒否シーケンスである。段階502〜段階504は図3の段階302〜段階304と同様である。段階506で、呼制御サーバー130は図4の段階404と同様の計算及び比較を行う。帯域の合計がSBC120の性能限界であるXMbit/sより多かった場合、段階508で、SBC120は呼制御サーバー130へ帯域不足による設定受付拒否メッセージを送信する。段階510は段階406と同様である。
【0009】
上述の図4、5を参照し説明した発呼受付拒否の様子は図1の下半分に示される。図1では一番下に示されたトラヒックの受付が拒否される。しかしながら、呼制御サーバー130はSBC120の帯域以外の性能限界である秒間パケット処理性能を認識できないので、上述のような帯域の合計に基づき呼の受付を制御しても、秒間パケット処理性能がSBC120の性能限界を超えてしまう場合がある。従って帯域以外の性能限界である秒間パケット処理性能が限界に達していても、呼の受付を制限することができず、疎通するトラヒックに対してパケット廃棄やパケット遅延などを生じてしまう。
【非特許文献1】井上友二、そこが知りたい最新技術NGN入門、(日本)、インプレスR&D、2007年1月30日、p.156−172
【発明の開示】
【発明が解決しようとする課題】
【0010】
本発明の目的は、帯域情報だけでなくパケット処理性能を考慮した呼の受付制御を行う方法、システム、及び装置を提供することである。
【課題を解決するための手段】
【0011】
本発明の第1の態様によると、複数の端末、前記複数の端末からのパケットを滞留させる入力バッファを有するセッション・ボーダー・コントローラー(SBC)、前記SBCを制御する呼制御サーバーを有するシステムの呼制御方法が提供される。当該方法は、(a)前記SBCは前記入力バッファを監視し、所定の輻輳閾値を超えてパケットが滞留しているか否かを決定する段階、(b)前記所定の輻輳閾値を超えてパケットが滞留していると決定された場合、前記SBCは前記呼制御サーバーへ輻輳を通知する段階、(c)前記呼制御サーバーは前記SBCに対し、新たな呼を受け付けないよう指示する段階、を有する。
【0012】
本発明の第2の態様によると、呼制御を行うシステムが提供される。当該システムは、複数の端末、前記複数の端末からのパケットを滞留させる入力バッファを有するセッション・ボーダー・コントローラー(SBC)、前記SBCを制御する呼制御サーバー、を有し、前記SBCは、前記入力バッファを監視し、所定の輻輳閾値を超えてパケットが滞留しているか否かを決定する輻輳監視部、前記所定の輻輳閾値を超えてパケットが滞留していると決定された場合、前記呼制御サーバーへ輻輳を通知する制御信号処理部、を有し、前記呼制御サーバーは、前記SBCから輻輳を通知された場合に、前記SBCに新たな呼を受け付けないよう指示する。
【0013】
本発明の第3の態様によると、複数の端末、前記複数の端末からのパケットを滞留させる入力バッファを有するセッション・ボーダー・コントローラー(SBC)を有するシステムで用いられる、前記SBCを制御する呼制御サーバーが提供される。当該呼制御サーバーは、前記SBCから輻輳を通知されると、前記SBCに対し新たな呼を受け付けないよう指示するか、又は前記SBCが接続している呼のうち、より多くの帯域を使用するコーデックを使用している呼及び処理負荷のより大きいコーデックを使用している呼のうち、1又は複数の呼を切断するよう更に指示する。
【0014】
本発明の第4の態様によると、複数の端末及び呼制御サーバーを有するシステムで用いられ、前記複数の端末からのパケットを滞留させる入力バッファを有するセッション・ボーダー・コントローラー(SBC)が提供される。当該SBCは、前記入力バッファを監視し、所定の輻輳閾値を超えてパケットが滞留しているか否かを決定する輻輳監視部、及び前記呼制御サーバーへ輻輳を通知する制御信号処理部、を有し、前記所定の輻輳閾値を超えてパケットが滞留していると決定された場合、前記SBCが接続している呼のうち、より多くの帯域を使用するコーデックを使用している呼及び処理負荷のより大きいコーデックを使用している1又は複数の呼に対応する1又は複数のインターフェース若しくはVPN(仮想プライベート・ネットワーク)の設定を削除する。
【発明の効果】
【0015】
本発明により、帯域情報に基づく既存の呼制御方法を使用しながら、SBCの秒間パケット処理性能に基づく更なる呼制御を行うことができ、トラヒックの劣化を防ぐことができる。
【発明を実施するための最良の形態】
【0016】
[概要]
図6は、NGN200における本発明の呼制御サーバーとSBCの動作を説明するシステム構成図である。図6の上半分に示されるNGN200は、端末210a、210b、SBC220、SBC220を制御する呼制御サーバー230、それらを接続する事業者Aのネットワーク240a及び事業者Bのネットワーク240bを有する。
【0017】
図7は、SBC220の構成を詳細に示す図である。SBC220は、事業者ネットワーク240a又は240bから受信したパケットを滞留させる入力バッファ221、入力バッファ221に滞留されたパケットを処理し事業者ネットワーク240a又は240bへ送信するパケット処理機能部222、入力バッファ221に滞留するパケットが輻輳閾値を超えているか否かを監視し及び輻輳通知を生成する輻輳監視部223、事業者ネットワーク240a又は240bを介し呼制御サーバー230からの呼設定情報を受信し及び呼制御サーバー230へ輻輳通知を送信する制御信号処理部224、当該呼設定情報に基づきセッションを制御するセッション制御部225、を有する。
【0018】
図6の下半分に示されるように、本発明では上述した従来の帯域情報に基づく呼制御に加え、呼制御サーバー230がSBC220から輻輳通知を受信すると、呼制御サーバー230は当該輻輳通知に基づき呼制御を行う。SBC220は複数のアドレスを持っており、端末210a、210bは当該複数のアドレスのうちの何れかのアドレスを宛先として事業者ネットワーク240a、240bを介しトラヒックを送信する。呼制御サーバー230は当該複数のアドレスのうちどのアドレスを使用しているかを把握しており、適切なアドレスを選んで呼の設定を行う。
【0019】
[実施例1]
図8乃至図9を参照して本発明の実施例1を説明する。
【0020】
図8は、本発明の第1の実施例を説明するシステム構成図である。図8の上半分は上述の図6の上半分の構成と同様である。
【0021】
図9は、本発明の第1の実施例を説明するシーケンス図である。図9の(A)は新たな呼の受付により輻輳閾値を超える場合の受付拒否シーケンスを示す。図9の段階902〜段階904は、図3の段階302〜段階304と同様である。段階906で、SBC220は図2乃至図5を参照して説明された従来のシーケンスと同様に呼制御サーバー230又はSBC220がセッション記述に含まれる帯域情報を合計しSBC220の性能限界と比較する。当該合計が当該性能限界を超えていた場合は従来のシーケンスと同様の処理が行われる。その他の場合、段階906で、SBC220の輻輳監視部223は、入力バッファ221を監視し、パケットが輻輳閾値を超えて滞留していることを検出する。パケットが輻輳閾値を超えて滞留していることは、SBCの秒間パケット処理性能を超えるパケットが流入する可能性があることを意味する。つまり図8の下半分に示されるように、SBCを通過するトラヒックの秒間パケット数の合計であるy1+y2+y3+y4がSBCの秒間パケット処理性能Yppsを超えることが予想される。段階908で、SBC220の制御信号処理部224は、SBC220に流入するパケットがパケット処理機能部222の性能を超える可能性があると判断し、呼制御サーバー230へ設定受付拒否メッセージを送信する。段階910で、呼制御サーバー230は、端末110aへ段階902の発呼を拒否する発呼拒否メッセージを送信する。
【0022】
図9の(B)は新たな呼の受付前に輻輳閾値を超えた場合の発呼受付拒否シーケンスである。段階912で、SBC220は段階906と同様にパケットが輻輳閾値を超えて滞留していることを検出する。段階914で、SBC220は呼制御サーバー230へ自身のパケット処理性能を上回ってパケットが流入する可能性がることを示すパケット処理性能不足アラームを送信する。段階916で、端末110aが発呼する。これに対し段階918で、呼制御サーバー230は端末110aへ発呼受付拒否メッセージを送信する。
【0023】
上述の本発明の第1の実施例によると、呼制御サーバー230がSBC220に流入するパケットがSBC220のパケット処理性能の限界を超える可能性があることを認識できるので、図8の下半分に示されるように、セッション記述に含まれる帯域情報の合計がSBC220の性能限界を下回っていたとしても、つまりSBC220の帯域が余っていたとしても、SBC220のパケット処理性能の限界を超える可能性がある新規の呼を受け付けない。従って、SBC220が秒間パケット処理性能の性能限界に達する前に呼の受付制御が適切に行われ、トラヒックの劣化を回避できる。
【0024】
[実施例2]
図10乃至図11を参照して本発明の実施例2を説明する。
【0025】
図10は、本発明の第2の実施例を説明するシステム構成図である。
【0026】
図11は、本発明の第2の実施例を説明する、輻輳の検出により既存の呼を切断する場合の呼切断シーケンスを示す。図11の段階1102〜段階1114は従来の発呼受付シーケンスと同様であり、図2の段階202〜段階214と同様である。或いは図11の段階1102〜段階1114は図3の段階302〜段階314で置き換えられて良い。段階1116で、図9の段階906と同様にパケットが輻輳閾値を超えて滞留していることを検出する。段階1118で、図9の段階914と同様にパケット処理性能不足アラームを送信する。段階1120で、呼制御サーバー230は例えばSIPパケットに含まれるコーデック、SDPパケットに含まれるパケット内のメディアのミリ秒単位の時間長を与えるptimeパラメータを調べ、SBC220のパケット処理機能部222により大きな負荷をかけている又はより多くの帯域を使用している1又は複数の既存の呼を選択する。段階1122で、呼制御サーバー230は段階1120で選択された1又は複数の既存の呼既存の呼を切断する。ここでは例として端末110aの呼が切断されている。段階1124で、呼制御サーバー230はSBC220へ段階1120で切断された呼の呼設定情報を削除するよう指示する。段階1126で、SBC220は呼設定情報の削除が完了したことを呼制御サーバー230へ通知する。段階1118〜段階1126は、SBC220の処理性能の不足が解消されるまで、つまり輻輳が検出されなくなるまで繰り返される。段階1128で、輻輳が検出されなくなるとSBC220は呼制御サーバー230へパケット処理性能が不足していないことを示すパケット処理性能不足アラームクリアメッセージを送信する。
【0027】
上述の本発明の第2の実施例によると、呼制御サーバー230がSBC220に流入するパケットがSBC220のパケット処理性能の限界を超えていることを認識できるので、図10の下半分に示されるように、セッション記述に含まれる帯域情報の合計がSBC220の性能限界を下回っていたために受け付けられた呼でも、SBC220の秒間パケット処理性能が限界に達する可能性がある場合には切断される。従って、SBC220が秒間パケット処理性能の性能限界に達する前に呼の受付制御が適切に行われ、トラヒックの劣化を回避できる。
【0028】
[実施例3]
図12乃至図13を参照して本発明の実施例3を説明する。
【0029】
図12は、本発明の第3の実施例を説明するシステム構成図である。図12は2つのSBC220a、220b、及びSBC220a、220bと事業者ネットワークBとを接続するルータ又はスイッチ250が設けられ、その他は上述の図6の上半分の構成と同様である。
【0030】
図13は、本発明の第3の実施例を説明する、輻輳によりSBCが自律的にリンクダウンする場合のシーケンス図である。図13の段階1302〜段階1318は図11の段階1102〜段階1118と同様である。但しSBC220はSBC220aに置き換えられる。段階1320で、SBC220aのセッション制御部225は自律的にルータ又はスイッチ250とのインターフェースをリンクダウンすることにより、ルータ又はスイッチ250にルータ又はスイッチ250の経路選択テーブルに保持されている経路情報を削除させる。段階1322で、SBC220aは、削除完了メッセージを呼制御サーバー230へ送信し、リンクダウンによりSBC220a宛の経路が削除されたことを通知する。段階1324で、呼制御サーバー230はSBC220bへ呼設定情報を送信する。段階1326で、SBC220bは呼制御サーバー230へ呼の設定が完了したことを示す設定完了メッセージを送信する。段階1328〜段階1330は、図11の段階1124〜段階1126と同様である。
【0031】
上述の本発明の第3の実施例によると、セッション記述に含まれる帯域情報の合計がSBC220aの性能限界を下回っていたために受け付けられた呼は、SBC220aの秒間パケット処理性能が限界に達する可能性のある場合には、SBC220aに代わって処理性能に余裕のあるSBC220bにより処理される。従って、SBC220aが秒間パケット処理性能の性能限界に達する前に当該呼を処理するSBCが適切に切り替えられ、トラヒックは適切に迂回され、トラヒックの劣化を回避できる。
【0032】
[実施例4]
図12及び図14を参照して本発明の実施例4を説明する。第4の実施例の構成は実施例3と同様である。
【0033】
図14は、本発明の第4の実施例を説明する、輻輳により呼制御サーバー230がインターフェース又はVPN(仮想プライベート・ネットワーク)設定の削除を指示する場合のシーケンス図である。図14の段階1402〜段階1418は図13の段階1302〜段階1318と同様である。段階1420で、図11の段階1120と同様に、SBC220aのパケット処理機能部222により大きな負荷をかけている又はより多くの帯域を使用している1又は複数の既存の呼を選択する。段階1422で、呼制御サーバー230はSBC220aに、段階1420で選択された1又は複数の既存の呼が割り当てられている1又は複数のインターフェース又は1又は複数のVPN設定を削除するよう指示する。段階1424〜段階1432は図13の段階1322〜段階1330と同様である。
【0034】
上述の本発明の第4の実施例によると、セッション記述に含まれる帯域情報の合計がSBC220aの性能限界を下回っていたために受け付けられた呼は、SBC220aの秒間パケット処理性能が限界に達する可能性がある場合には、SBC220aに代わって処理性能に余裕のあるSBC220bにより処理される。従って、SBC220aが秒間パケット処理性能の性能限界に達する前に当該呼を処理するSBCが適切に切り替えられ、トラヒックは適切に迂回され、トラヒックの劣化を回避できる。
【0035】
[実施例5]
図15乃至図16を参照して本発明の実施例5を説明する。
【0036】
図15は本発明の第5の実施例を説明するシステム構成図であり、図12の構成と同様である。
【0037】
図16は、本発明の第5の実施例を説明する、輻輳により自律的にVPN設定を削除する場合のシーケンス図である。図16の段階1602〜段階1618は図13の段階1302〜段階1318と同様である。段階1620で、SBC220aのセッション制御部225は輻輳が検出されている入力バッファ221に対応するVPNの設定を自律的に削除することにより、ルータ又はスイッチ250にルータ又はスイッチ250が保持しているVPNの設定を削除させる。段階1622〜段階1630は図13の段階1322〜段階1330と同様である。
【0038】
上述の本発明の第5の実施例によると、セッション記述に含まれる帯域情報の合計がSBC220aの性能限界を下回っていたために受け付けられた呼は、SBC220aの秒間パケット処理性能が限界に達する可能性が場合には、SBC220aに代わって処理性能に余裕のあるSBC220bにより処理される。従って、SBC220aが秒間パケット処理性能の性能限界に達する前に当該呼を処理するSBCが適切に切り替えられ、トラヒックは適切に迂回され、トラヒックの劣化を回避できる。
【図面の簡単な説明】
【0039】
【図1】従来の呼制御サーバーとSBCの動作を説明するシステム構成図である。
【図2】従来の呼制御サーバーが帯域を管理する場合の発呼受付シーケンスである。
【図3】従来のSBCが帯域を管理する場合の発呼受付シーケンスである。
【図4】従来の呼制御サーバーが帯域を管理する場合の発呼受付拒否シーケンスである。
【図5】従来のSBCが帯域を管理する場合の発呼受付拒否シーケンスである。
【図6】本発明の呼制御サーバーとSBCの動作を説明するシステム構成図である。
【図7】本発明のSBCの構成を詳細に示す図である。
【図8】本発明の第1の実施例を説明するシステム構成図である。
【図9】本発明の第1の実施例を説明するシーケンス図である。
【図10】本発明の第2の実施例を説明するシステム構成図である。
【図11】本発明の第2の実施例を説明するシーケンス図である。
【図12】本発明の第3の実施例を説明するシステム構成図である。
【図13】本発明の第3の実施例を説明するシーケンス図である。
【図14】本発明の第4の実施例を説明するシーケンス図である。
【図15】本発明の第5の実施例を説明するシステム構成図である。
【図16】本発明の第5の実施例を説明するシーケンス図である。
【符号の説明】
【0040】
110a、110b、220a、220b 端末
120、220、220a、220b セッション・ボーダー・コントローラー(SBC)
130、230 呼制御サーバー
140a、140b、240a、240b 事業者ネットワーク
221 入力バッファ
222 パケット処理機能部
224 制御信号処理部
225 セッション制御部
250 ルータ又はスイッチ
【技術分野】
【0001】
本発明は、呼制御方法、システム、及びサーバー、並びにセッション・ボーダー・コントローラーに関し、より詳細には、複数の端末、前記複数の端末からのパケットを滞留させる入力バッファを有するセッション・ボーダー・コントローラー(SBC)、前記SBCを制御する呼制御サーバーを有するシステムにおける呼制御に関する。
【背景技術】
【0002】
インターネットの急速な普及に伴い、近年ではより高速な双方向広帯域サービスが望まれるようになった。更に固定通信と移動体通信の連携、電話網と放送網とインターネットの融合、コストの削減、サービス品質の向上、等が望まれている。これらを実現するために国際電気通信連合(International Telecommunication Union:ITU−T)、欧州電気通信標準化協会(European Telecommunications Standards Institute:ETSI)、IETF(Internet Engineering Task Force)等の標準化団体は次世代ネットワーク(Next Generation Network:NGN)技術の規格を制定し、世界各国でNGNが構築され始めている。
【0003】
NGNはインターネット・プロトコル(IP)や非同期転送モード(ATM)などに基づくパケット転送ノードにより接続された呼制御サーバーとルータとセッション・ボーダー・コントローラー(SBC)により端末間及び事業者間を接続し、電話やビデオ配信などをサービスとして提供するネットワークであり、(1)セッションの確立・切断のために、IP電話でも用いられる制御用通信プロトコルであるSIP(Session Initiation Protocol)が用いられる、(2)帯域確保のようなQoS(サービス品質)制御やNAT/ファイアウォールのようなセキュリティに関する処理を行う制御装置が設けられる、等を特徴とする。
【0004】
図1はNGN100における従来の呼制御サーバーとSBCの動作を説明するシステム構成図である。このような構成は非特許文献1に記載されている。図1の上半分に示されるNGN100は、端末110a、110b、当該端末からのパケットを滞留させる入力バッファを有し当該端末間のセッションを制御するSBC120、SBC120を制御する呼制御サーバー130、それらを接続する事業者Aのネットワーク140a及び事業者Bのネットワーク140bを有する。呼制御サーバー130は、自身に設定されているSBC120の性能限界に応じて呼の受付制御を行い、SBC120を通るトラヒックの品質を確保する。呼の受付制御を行う際に、呼制御サーバー130はセッション記述プロトコル(Session Description Protocol:SDP)で定められたセッション記述を参照するが、一般に当該セッション記述が有する性能限界に関する情報は帯域情報のみである。
【0005】
図2は従来の呼制御サーバーが帯域を管理する場合の発呼受付シーケンスである。段階202で、端末110aは発呼する。段階204で、呼制御サーバー130はセッション記述に記載された帯域情報を加算し、端末110aを含む接続事業者から要求されているトラヒックの帯域の合計x1+x2+x3+x4を計算する。ここで当該帯域の合計がSBC120の性能限界であるXMbit/sより少なかった場合、つまりX>x1+x2+x3+x4となった場合に、段階206で、呼制御サーバー130はSBC120へ呼設定情報を送信する。呼設定情報は、例えば端末110aのアドレス、端末110aがSBCへ送るための宛先アドレス、端末110bのアドレス、端末110bがSBCへ送るための宛先アドレス、トラヒック疎通帯域、当該トラヒックが通る物理インターフェースである。段階208で、SBC120は当該呼設定情報に従い呼を設定すると、呼制御サーバー130へ設定完了メッセージを送信する。段階210で、呼制御サーバー130は段階202で受けた呼を端末110bへ転送する。段階212で、端末110bは端末110aへ呼を受け付けたことを通知する。段階214で、端末110aと端末110bとの間で通話が実現する。
【0006】
図3は、従来のSBCが帯域を管理する場合の発呼受付シーケンスである。段階302で、端末110aは発呼する。段階304で、呼制御サーバー130はSBC120へ図2の段階206と同様の呼設定情報を送信する。段階306で、SBC120は図2の段階204と同様の方法でトラヒックの帯域の合計を計算し、SBC120の性能限界と比較する。当該帯域の合計がSBC120の性能限界であるXMbit/sより少なかった場合、段階308で、SBC120は呼制御サーバー130へ設定完了メッセージを送信する。段階310〜段階314は図2の段階210〜段階214と同様である。
【0007】
図4は従来の呼制御サーバーが帯域を管理する場合の発呼受付拒否シーケンスである。段階402で、端末110aは発呼する。段階404で、呼制御サーバー130は図2の段階204と同様の方法でトラヒックの帯域の合計を計算し、SBC120の性能限界と比較する。当該帯域の合計がSBC120の性能限界であるXMbit/sより多かった場合、段階406で、呼制御サーバー130は端末110aへ発呼受付拒否メッセージを送信し、段階402の発呼を拒否する。
【0008】
図5は従来のSBCが帯域を管理する場合の発呼受付拒否シーケンスである。段階502〜段階504は図3の段階302〜段階304と同様である。段階506で、呼制御サーバー130は図4の段階404と同様の計算及び比較を行う。帯域の合計がSBC120の性能限界であるXMbit/sより多かった場合、段階508で、SBC120は呼制御サーバー130へ帯域不足による設定受付拒否メッセージを送信する。段階510は段階406と同様である。
【0009】
上述の図4、5を参照し説明した発呼受付拒否の様子は図1の下半分に示される。図1では一番下に示されたトラヒックの受付が拒否される。しかしながら、呼制御サーバー130はSBC120の帯域以外の性能限界である秒間パケット処理性能を認識できないので、上述のような帯域の合計に基づき呼の受付を制御しても、秒間パケット処理性能がSBC120の性能限界を超えてしまう場合がある。従って帯域以外の性能限界である秒間パケット処理性能が限界に達していても、呼の受付を制限することができず、疎通するトラヒックに対してパケット廃棄やパケット遅延などを生じてしまう。
【非特許文献1】井上友二、そこが知りたい最新技術NGN入門、(日本)、インプレスR&D、2007年1月30日、p.156−172
【発明の開示】
【発明が解決しようとする課題】
【0010】
本発明の目的は、帯域情報だけでなくパケット処理性能を考慮した呼の受付制御を行う方法、システム、及び装置を提供することである。
【課題を解決するための手段】
【0011】
本発明の第1の態様によると、複数の端末、前記複数の端末からのパケットを滞留させる入力バッファを有するセッション・ボーダー・コントローラー(SBC)、前記SBCを制御する呼制御サーバーを有するシステムの呼制御方法が提供される。当該方法は、(a)前記SBCは前記入力バッファを監視し、所定の輻輳閾値を超えてパケットが滞留しているか否かを決定する段階、(b)前記所定の輻輳閾値を超えてパケットが滞留していると決定された場合、前記SBCは前記呼制御サーバーへ輻輳を通知する段階、(c)前記呼制御サーバーは前記SBCに対し、新たな呼を受け付けないよう指示する段階、を有する。
【0012】
本発明の第2の態様によると、呼制御を行うシステムが提供される。当該システムは、複数の端末、前記複数の端末からのパケットを滞留させる入力バッファを有するセッション・ボーダー・コントローラー(SBC)、前記SBCを制御する呼制御サーバー、を有し、前記SBCは、前記入力バッファを監視し、所定の輻輳閾値を超えてパケットが滞留しているか否かを決定する輻輳監視部、前記所定の輻輳閾値を超えてパケットが滞留していると決定された場合、前記呼制御サーバーへ輻輳を通知する制御信号処理部、を有し、前記呼制御サーバーは、前記SBCから輻輳を通知された場合に、前記SBCに新たな呼を受け付けないよう指示する。
【0013】
本発明の第3の態様によると、複数の端末、前記複数の端末からのパケットを滞留させる入力バッファを有するセッション・ボーダー・コントローラー(SBC)を有するシステムで用いられる、前記SBCを制御する呼制御サーバーが提供される。当該呼制御サーバーは、前記SBCから輻輳を通知されると、前記SBCに対し新たな呼を受け付けないよう指示するか、又は前記SBCが接続している呼のうち、より多くの帯域を使用するコーデックを使用している呼及び処理負荷のより大きいコーデックを使用している呼のうち、1又は複数の呼を切断するよう更に指示する。
【0014】
本発明の第4の態様によると、複数の端末及び呼制御サーバーを有するシステムで用いられ、前記複数の端末からのパケットを滞留させる入力バッファを有するセッション・ボーダー・コントローラー(SBC)が提供される。当該SBCは、前記入力バッファを監視し、所定の輻輳閾値を超えてパケットが滞留しているか否かを決定する輻輳監視部、及び前記呼制御サーバーへ輻輳を通知する制御信号処理部、を有し、前記所定の輻輳閾値を超えてパケットが滞留していると決定された場合、前記SBCが接続している呼のうち、より多くの帯域を使用するコーデックを使用している呼及び処理負荷のより大きいコーデックを使用している1又は複数の呼に対応する1又は複数のインターフェース若しくはVPN(仮想プライベート・ネットワーク)の設定を削除する。
【発明の効果】
【0015】
本発明により、帯域情報に基づく既存の呼制御方法を使用しながら、SBCの秒間パケット処理性能に基づく更なる呼制御を行うことができ、トラヒックの劣化を防ぐことができる。
【発明を実施するための最良の形態】
【0016】
[概要]
図6は、NGN200における本発明の呼制御サーバーとSBCの動作を説明するシステム構成図である。図6の上半分に示されるNGN200は、端末210a、210b、SBC220、SBC220を制御する呼制御サーバー230、それらを接続する事業者Aのネットワーク240a及び事業者Bのネットワーク240bを有する。
【0017】
図7は、SBC220の構成を詳細に示す図である。SBC220は、事業者ネットワーク240a又は240bから受信したパケットを滞留させる入力バッファ221、入力バッファ221に滞留されたパケットを処理し事業者ネットワーク240a又は240bへ送信するパケット処理機能部222、入力バッファ221に滞留するパケットが輻輳閾値を超えているか否かを監視し及び輻輳通知を生成する輻輳監視部223、事業者ネットワーク240a又は240bを介し呼制御サーバー230からの呼設定情報を受信し及び呼制御サーバー230へ輻輳通知を送信する制御信号処理部224、当該呼設定情報に基づきセッションを制御するセッション制御部225、を有する。
【0018】
図6の下半分に示されるように、本発明では上述した従来の帯域情報に基づく呼制御に加え、呼制御サーバー230がSBC220から輻輳通知を受信すると、呼制御サーバー230は当該輻輳通知に基づき呼制御を行う。SBC220は複数のアドレスを持っており、端末210a、210bは当該複数のアドレスのうちの何れかのアドレスを宛先として事業者ネットワーク240a、240bを介しトラヒックを送信する。呼制御サーバー230は当該複数のアドレスのうちどのアドレスを使用しているかを把握しており、適切なアドレスを選んで呼の設定を行う。
【0019】
[実施例1]
図8乃至図9を参照して本発明の実施例1を説明する。
【0020】
図8は、本発明の第1の実施例を説明するシステム構成図である。図8の上半分は上述の図6の上半分の構成と同様である。
【0021】
図9は、本発明の第1の実施例を説明するシーケンス図である。図9の(A)は新たな呼の受付により輻輳閾値を超える場合の受付拒否シーケンスを示す。図9の段階902〜段階904は、図3の段階302〜段階304と同様である。段階906で、SBC220は図2乃至図5を参照して説明された従来のシーケンスと同様に呼制御サーバー230又はSBC220がセッション記述に含まれる帯域情報を合計しSBC220の性能限界と比較する。当該合計が当該性能限界を超えていた場合は従来のシーケンスと同様の処理が行われる。その他の場合、段階906で、SBC220の輻輳監視部223は、入力バッファ221を監視し、パケットが輻輳閾値を超えて滞留していることを検出する。パケットが輻輳閾値を超えて滞留していることは、SBCの秒間パケット処理性能を超えるパケットが流入する可能性があることを意味する。つまり図8の下半分に示されるように、SBCを通過するトラヒックの秒間パケット数の合計であるy1+y2+y3+y4がSBCの秒間パケット処理性能Yppsを超えることが予想される。段階908で、SBC220の制御信号処理部224は、SBC220に流入するパケットがパケット処理機能部222の性能を超える可能性があると判断し、呼制御サーバー230へ設定受付拒否メッセージを送信する。段階910で、呼制御サーバー230は、端末110aへ段階902の発呼を拒否する発呼拒否メッセージを送信する。
【0022】
図9の(B)は新たな呼の受付前に輻輳閾値を超えた場合の発呼受付拒否シーケンスである。段階912で、SBC220は段階906と同様にパケットが輻輳閾値を超えて滞留していることを検出する。段階914で、SBC220は呼制御サーバー230へ自身のパケット処理性能を上回ってパケットが流入する可能性がることを示すパケット処理性能不足アラームを送信する。段階916で、端末110aが発呼する。これに対し段階918で、呼制御サーバー230は端末110aへ発呼受付拒否メッセージを送信する。
【0023】
上述の本発明の第1の実施例によると、呼制御サーバー230がSBC220に流入するパケットがSBC220のパケット処理性能の限界を超える可能性があることを認識できるので、図8の下半分に示されるように、セッション記述に含まれる帯域情報の合計がSBC220の性能限界を下回っていたとしても、つまりSBC220の帯域が余っていたとしても、SBC220のパケット処理性能の限界を超える可能性がある新規の呼を受け付けない。従って、SBC220が秒間パケット処理性能の性能限界に達する前に呼の受付制御が適切に行われ、トラヒックの劣化を回避できる。
【0024】
[実施例2]
図10乃至図11を参照して本発明の実施例2を説明する。
【0025】
図10は、本発明の第2の実施例を説明するシステム構成図である。
【0026】
図11は、本発明の第2の実施例を説明する、輻輳の検出により既存の呼を切断する場合の呼切断シーケンスを示す。図11の段階1102〜段階1114は従来の発呼受付シーケンスと同様であり、図2の段階202〜段階214と同様である。或いは図11の段階1102〜段階1114は図3の段階302〜段階314で置き換えられて良い。段階1116で、図9の段階906と同様にパケットが輻輳閾値を超えて滞留していることを検出する。段階1118で、図9の段階914と同様にパケット処理性能不足アラームを送信する。段階1120で、呼制御サーバー230は例えばSIPパケットに含まれるコーデック、SDPパケットに含まれるパケット内のメディアのミリ秒単位の時間長を与えるptimeパラメータを調べ、SBC220のパケット処理機能部222により大きな負荷をかけている又はより多くの帯域を使用している1又は複数の既存の呼を選択する。段階1122で、呼制御サーバー230は段階1120で選択された1又は複数の既存の呼既存の呼を切断する。ここでは例として端末110aの呼が切断されている。段階1124で、呼制御サーバー230はSBC220へ段階1120で切断された呼の呼設定情報を削除するよう指示する。段階1126で、SBC220は呼設定情報の削除が完了したことを呼制御サーバー230へ通知する。段階1118〜段階1126は、SBC220の処理性能の不足が解消されるまで、つまり輻輳が検出されなくなるまで繰り返される。段階1128で、輻輳が検出されなくなるとSBC220は呼制御サーバー230へパケット処理性能が不足していないことを示すパケット処理性能不足アラームクリアメッセージを送信する。
【0027】
上述の本発明の第2の実施例によると、呼制御サーバー230がSBC220に流入するパケットがSBC220のパケット処理性能の限界を超えていることを認識できるので、図10の下半分に示されるように、セッション記述に含まれる帯域情報の合計がSBC220の性能限界を下回っていたために受け付けられた呼でも、SBC220の秒間パケット処理性能が限界に達する可能性がある場合には切断される。従って、SBC220が秒間パケット処理性能の性能限界に達する前に呼の受付制御が適切に行われ、トラヒックの劣化を回避できる。
【0028】
[実施例3]
図12乃至図13を参照して本発明の実施例3を説明する。
【0029】
図12は、本発明の第3の実施例を説明するシステム構成図である。図12は2つのSBC220a、220b、及びSBC220a、220bと事業者ネットワークBとを接続するルータ又はスイッチ250が設けられ、その他は上述の図6の上半分の構成と同様である。
【0030】
図13は、本発明の第3の実施例を説明する、輻輳によりSBCが自律的にリンクダウンする場合のシーケンス図である。図13の段階1302〜段階1318は図11の段階1102〜段階1118と同様である。但しSBC220はSBC220aに置き換えられる。段階1320で、SBC220aのセッション制御部225は自律的にルータ又はスイッチ250とのインターフェースをリンクダウンすることにより、ルータ又はスイッチ250にルータ又はスイッチ250の経路選択テーブルに保持されている経路情報を削除させる。段階1322で、SBC220aは、削除完了メッセージを呼制御サーバー230へ送信し、リンクダウンによりSBC220a宛の経路が削除されたことを通知する。段階1324で、呼制御サーバー230はSBC220bへ呼設定情報を送信する。段階1326で、SBC220bは呼制御サーバー230へ呼の設定が完了したことを示す設定完了メッセージを送信する。段階1328〜段階1330は、図11の段階1124〜段階1126と同様である。
【0031】
上述の本発明の第3の実施例によると、セッション記述に含まれる帯域情報の合計がSBC220aの性能限界を下回っていたために受け付けられた呼は、SBC220aの秒間パケット処理性能が限界に達する可能性のある場合には、SBC220aに代わって処理性能に余裕のあるSBC220bにより処理される。従って、SBC220aが秒間パケット処理性能の性能限界に達する前に当該呼を処理するSBCが適切に切り替えられ、トラヒックは適切に迂回され、トラヒックの劣化を回避できる。
【0032】
[実施例4]
図12及び図14を参照して本発明の実施例4を説明する。第4の実施例の構成は実施例3と同様である。
【0033】
図14は、本発明の第4の実施例を説明する、輻輳により呼制御サーバー230がインターフェース又はVPN(仮想プライベート・ネットワーク)設定の削除を指示する場合のシーケンス図である。図14の段階1402〜段階1418は図13の段階1302〜段階1318と同様である。段階1420で、図11の段階1120と同様に、SBC220aのパケット処理機能部222により大きな負荷をかけている又はより多くの帯域を使用している1又は複数の既存の呼を選択する。段階1422で、呼制御サーバー230はSBC220aに、段階1420で選択された1又は複数の既存の呼が割り当てられている1又は複数のインターフェース又は1又は複数のVPN設定を削除するよう指示する。段階1424〜段階1432は図13の段階1322〜段階1330と同様である。
【0034】
上述の本発明の第4の実施例によると、セッション記述に含まれる帯域情報の合計がSBC220aの性能限界を下回っていたために受け付けられた呼は、SBC220aの秒間パケット処理性能が限界に達する可能性がある場合には、SBC220aに代わって処理性能に余裕のあるSBC220bにより処理される。従って、SBC220aが秒間パケット処理性能の性能限界に達する前に当該呼を処理するSBCが適切に切り替えられ、トラヒックは適切に迂回され、トラヒックの劣化を回避できる。
【0035】
[実施例5]
図15乃至図16を参照して本発明の実施例5を説明する。
【0036】
図15は本発明の第5の実施例を説明するシステム構成図であり、図12の構成と同様である。
【0037】
図16は、本発明の第5の実施例を説明する、輻輳により自律的にVPN設定を削除する場合のシーケンス図である。図16の段階1602〜段階1618は図13の段階1302〜段階1318と同様である。段階1620で、SBC220aのセッション制御部225は輻輳が検出されている入力バッファ221に対応するVPNの設定を自律的に削除することにより、ルータ又はスイッチ250にルータ又はスイッチ250が保持しているVPNの設定を削除させる。段階1622〜段階1630は図13の段階1322〜段階1330と同様である。
【0038】
上述の本発明の第5の実施例によると、セッション記述に含まれる帯域情報の合計がSBC220aの性能限界を下回っていたために受け付けられた呼は、SBC220aの秒間パケット処理性能が限界に達する可能性が場合には、SBC220aに代わって処理性能に余裕のあるSBC220bにより処理される。従って、SBC220aが秒間パケット処理性能の性能限界に達する前に当該呼を処理するSBCが適切に切り替えられ、トラヒックは適切に迂回され、トラヒックの劣化を回避できる。
【図面の簡単な説明】
【0039】
【図1】従来の呼制御サーバーとSBCの動作を説明するシステム構成図である。
【図2】従来の呼制御サーバーが帯域を管理する場合の発呼受付シーケンスである。
【図3】従来のSBCが帯域を管理する場合の発呼受付シーケンスである。
【図4】従来の呼制御サーバーが帯域を管理する場合の発呼受付拒否シーケンスである。
【図5】従来のSBCが帯域を管理する場合の発呼受付拒否シーケンスである。
【図6】本発明の呼制御サーバーとSBCの動作を説明するシステム構成図である。
【図7】本発明のSBCの構成を詳細に示す図である。
【図8】本発明の第1の実施例を説明するシステム構成図である。
【図9】本発明の第1の実施例を説明するシーケンス図である。
【図10】本発明の第2の実施例を説明するシステム構成図である。
【図11】本発明の第2の実施例を説明するシーケンス図である。
【図12】本発明の第3の実施例を説明するシステム構成図である。
【図13】本発明の第3の実施例を説明するシーケンス図である。
【図14】本発明の第4の実施例を説明するシーケンス図である。
【図15】本発明の第5の実施例を説明するシステム構成図である。
【図16】本発明の第5の実施例を説明するシーケンス図である。
【符号の説明】
【0040】
110a、110b、220a、220b 端末
120、220、220a、220b セッション・ボーダー・コントローラー(SBC)
130、230 呼制御サーバー
140a、140b、240a、240b 事業者ネットワーク
221 入力バッファ
222 パケット処理機能部
224 制御信号処理部
225 セッション制御部
250 ルータ又はスイッチ
【特許請求の範囲】
【請求項1】
複数の端末、前記複数の端末からのパケットを滞留させる入力バッファを有するセッション・ボーダー・コントローラー(SBC)、前記SBCを制御する呼制御サーバーを有するシステムの呼制御方法であって、
(a)前記SBCは前記入力バッファを監視し、所定の輻輳閾値を超えてパケットが滞留しているか否かを決定する段階、
(b)前記所定の輻輳閾値を超えてパケットが滞留していると決定された場合、前記SBCは前記呼制御サーバーへ輻輳を通知する段階、
(c)前記呼制御サーバーは前記SBCに対し、新たな呼を受け付けないよう指示する段階、を有する呼制御方法。
【請求項2】
(d)前記呼制御サーバーは前記SBCに対し、前記SBCが接続している呼のうち、より多くの帯域を使用するコーデックを使用している呼及び処理負荷のより大きいコーデックを使用している呼のうち、1又は複数の呼を切断するよう指示する段階、を更に有する請求項1記載の呼制御方法。
【請求項3】
前記システムは前記複数の端末、1又は複数の前記SBC、前記呼制御サーバーを接続する1又は複数のパケット転送ノードを更に有し、
(e)前記呼制御サーバーは前記システムへ流入するパケットを受信する前記パケット転送ノードに対し、前記パケット転送ノードが有する経路選択テーブルから輻輳を通知したSBCのアドレスを含む経路を削除するよう又は前記経路をリンクダウンするよう指示する段階、
(f)前記呼制御サーバーは、輻輳を通知していない1つのSBCへ呼の設定に必要な設定情報を送信する段階、及び
(g)前記輻輳を通知していないSBCは、前記設定情報に基づき、前記輻輳を通知したSBCのアドレス宛の全ての呼を、前記輻輳を通知していないSBCのアドレス宛の呼として確立しなおす段階、を有する請求項2記載の呼制御方法。
【請求項4】
前記システムは前記複数の端末、1又は複数の前記SBC、前記呼制御サーバーを接続する1又は複数のパケット転送ノードを更に有し、
(h)前記呼制御サーバーは前記システムへ流入するパケットを受信する前記パケット転送ノードに対し、前記パケット転送ノードが有するVPN(仮想プライベート・ネットワーク)経路から輻輳を通知したSBCのアドレスを含むVPN経路を削除するよう指示する段階、
(f)前記呼制御サーバーは、輻輳を通知していない1つのSBCへ呼の設定に必要な設定情報を送信する段階、及び
(g)前記輻輳を通知していないSBCは、前記設定情報に基づき、前記輻輳を通知したSBCのアドレス宛の全ての呼を、前記輻輳を通知していないSBCのアドレス宛の呼として確立しなおす段階、を有する請求項2記載の呼制御方法。
【請求項5】
呼制御を行うシステムであって、
複数の端末、
前記複数の端末からのパケットを滞留させる入力バッファを有するセッション・ボーダー・コントローラー(SBC)、
前記SBCを制御する呼制御サーバー、を有し、
前記SBCは、
前記入力バッファを監視し、所定の輻輳閾値を超えてパケットが滞留しているか否かを決定する輻輳監視部、
前記所定の輻輳閾値を超えてパケットが滞留していると決定された場合、前記呼制御サーバーへ輻輳を通知する制御信号処理部、を有し、
前記呼制御サーバーは、前記SBCから輻輳を通知された場合に、前記SBCに新たな呼を受け付けないよう指示する、呼制御システム。
【請求項6】
前記呼制御サーバーは前記SBCに対し、前記SBCが接続している呼のうち、より多くの帯域を使用するコーデックを使用している呼及び処理負荷のより大きいコーデックを使用している呼のうち、1又は複数の呼を切断するよう更に指示する、請求項5記載の呼制御システム。
【請求項7】
前記システムは前記複数の端末、1又は複数の前記SBC、前記呼制御サーバーを接続する1又は複数のパケット転送ノードを更に有し、
前記呼制御サーバーは前記システムへ流入するパケットを受信する前記パケット転送ノードに対し、前記パケット転送ノードが有する経路選択テーブルから輻輳を通知したSBCのアドレスを含む経路を削除するよう又は前記経路をリンクダウンするよう指示し、
前記呼制御サーバーは、輻輳を通知していない1つのSBCへ呼の設定に必要な設定情報を送信し、及び
前記輻輳を通知していないSBCは、前記設定情報に基づき、前記輻輳を通知したSBCのアドレス宛の全ての呼を、前記輻輳を通知していないSBCのアドレス宛の呼として確立しなおす、請求項6記載の呼制御システム。
【請求項8】
前記システムは前記複数の端末、1又は複数の前記SBC、前記呼制御サーバーを接続する1又は複数のパケット転送ノードを更に有し、
前記呼制御サーバーは前記システムへ流入するパケットを受信する前記パケット転送ノードに対し、前記パケット転送ノードが有するVPN経路から輻輳を通知したSBCのアドレスを含むVPN経路を削除するよう指示し、
前記呼制御サーバーは、輻輳を通知していない1つのSBCへ呼の設定に必要な設定情報を送信し、及び
前記輻輳を通知していないSBCは、前記設定情報に基づき、前記輻輳を通知したSBCのアドレス宛の全ての呼を、前記輻輳を通知していないSBCのアドレス宛の呼として確立しなおす、請求項6記載の呼制御システム。
【請求項9】
複数の端末、前記複数の端末からのパケットを滞留させる入力バッファを有するセッション・ボーダー・コントローラー(SBC)を有するシステムで用いられる、前記SBCを制御する呼制御サーバーであって、
前記SBCから輻輳を通知されると、
前記SBCに対し新たな呼を受け付けないよう指示するか、又は
前記SBCが接続している呼のうち、より多くの帯域を使用するコーデックを使用している呼及び処理負荷のより大きいコーデックを使用している呼のうち、1又は複数の呼を切断するよう更に指示する、呼制御サーバー。
【請求項10】
複数の端末及び呼制御サーバーを有するシステムで用いられ、前記複数の端末からのパケットを滞留させる入力バッファを有するセッション・ボーダー・コントローラー(SBC)であって、
前記入力バッファを監視し、所定の輻輳閾値を超えてパケットが滞留しているか否かを決定する輻輳監視部、及び
前記呼制御サーバーへ輻輳を通知する制御信号処理部、を有し、
前記所定の輻輳閾値を超えてパケットが滞留していると決定された場合、前記SBCが接続している呼のうち、より多くの帯域を使用するコーデックを使用している呼及び処理負荷のより大きいコーデックを使用している1又は複数の呼に対応する1又は複数のインターフェース若しくはVPN(仮想プライベート・ネットワーク)設定を削除する、呼制御サーバー。
【請求項1】
複数の端末、前記複数の端末からのパケットを滞留させる入力バッファを有するセッション・ボーダー・コントローラー(SBC)、前記SBCを制御する呼制御サーバーを有するシステムの呼制御方法であって、
(a)前記SBCは前記入力バッファを監視し、所定の輻輳閾値を超えてパケットが滞留しているか否かを決定する段階、
(b)前記所定の輻輳閾値を超えてパケットが滞留していると決定された場合、前記SBCは前記呼制御サーバーへ輻輳を通知する段階、
(c)前記呼制御サーバーは前記SBCに対し、新たな呼を受け付けないよう指示する段階、を有する呼制御方法。
【請求項2】
(d)前記呼制御サーバーは前記SBCに対し、前記SBCが接続している呼のうち、より多くの帯域を使用するコーデックを使用している呼及び処理負荷のより大きいコーデックを使用している呼のうち、1又は複数の呼を切断するよう指示する段階、を更に有する請求項1記載の呼制御方法。
【請求項3】
前記システムは前記複数の端末、1又は複数の前記SBC、前記呼制御サーバーを接続する1又は複数のパケット転送ノードを更に有し、
(e)前記呼制御サーバーは前記システムへ流入するパケットを受信する前記パケット転送ノードに対し、前記パケット転送ノードが有する経路選択テーブルから輻輳を通知したSBCのアドレスを含む経路を削除するよう又は前記経路をリンクダウンするよう指示する段階、
(f)前記呼制御サーバーは、輻輳を通知していない1つのSBCへ呼の設定に必要な設定情報を送信する段階、及び
(g)前記輻輳を通知していないSBCは、前記設定情報に基づき、前記輻輳を通知したSBCのアドレス宛の全ての呼を、前記輻輳を通知していないSBCのアドレス宛の呼として確立しなおす段階、を有する請求項2記載の呼制御方法。
【請求項4】
前記システムは前記複数の端末、1又は複数の前記SBC、前記呼制御サーバーを接続する1又は複数のパケット転送ノードを更に有し、
(h)前記呼制御サーバーは前記システムへ流入するパケットを受信する前記パケット転送ノードに対し、前記パケット転送ノードが有するVPN(仮想プライベート・ネットワーク)経路から輻輳を通知したSBCのアドレスを含むVPN経路を削除するよう指示する段階、
(f)前記呼制御サーバーは、輻輳を通知していない1つのSBCへ呼の設定に必要な設定情報を送信する段階、及び
(g)前記輻輳を通知していないSBCは、前記設定情報に基づき、前記輻輳を通知したSBCのアドレス宛の全ての呼を、前記輻輳を通知していないSBCのアドレス宛の呼として確立しなおす段階、を有する請求項2記載の呼制御方法。
【請求項5】
呼制御を行うシステムであって、
複数の端末、
前記複数の端末からのパケットを滞留させる入力バッファを有するセッション・ボーダー・コントローラー(SBC)、
前記SBCを制御する呼制御サーバー、を有し、
前記SBCは、
前記入力バッファを監視し、所定の輻輳閾値を超えてパケットが滞留しているか否かを決定する輻輳監視部、
前記所定の輻輳閾値を超えてパケットが滞留していると決定された場合、前記呼制御サーバーへ輻輳を通知する制御信号処理部、を有し、
前記呼制御サーバーは、前記SBCから輻輳を通知された場合に、前記SBCに新たな呼を受け付けないよう指示する、呼制御システム。
【請求項6】
前記呼制御サーバーは前記SBCに対し、前記SBCが接続している呼のうち、より多くの帯域を使用するコーデックを使用している呼及び処理負荷のより大きいコーデックを使用している呼のうち、1又は複数の呼を切断するよう更に指示する、請求項5記載の呼制御システム。
【請求項7】
前記システムは前記複数の端末、1又は複数の前記SBC、前記呼制御サーバーを接続する1又は複数のパケット転送ノードを更に有し、
前記呼制御サーバーは前記システムへ流入するパケットを受信する前記パケット転送ノードに対し、前記パケット転送ノードが有する経路選択テーブルから輻輳を通知したSBCのアドレスを含む経路を削除するよう又は前記経路をリンクダウンするよう指示し、
前記呼制御サーバーは、輻輳を通知していない1つのSBCへ呼の設定に必要な設定情報を送信し、及び
前記輻輳を通知していないSBCは、前記設定情報に基づき、前記輻輳を通知したSBCのアドレス宛の全ての呼を、前記輻輳を通知していないSBCのアドレス宛の呼として確立しなおす、請求項6記載の呼制御システム。
【請求項8】
前記システムは前記複数の端末、1又は複数の前記SBC、前記呼制御サーバーを接続する1又は複数のパケット転送ノードを更に有し、
前記呼制御サーバーは前記システムへ流入するパケットを受信する前記パケット転送ノードに対し、前記パケット転送ノードが有するVPN経路から輻輳を通知したSBCのアドレスを含むVPN経路を削除するよう指示し、
前記呼制御サーバーは、輻輳を通知していない1つのSBCへ呼の設定に必要な設定情報を送信し、及び
前記輻輳を通知していないSBCは、前記設定情報に基づき、前記輻輳を通知したSBCのアドレス宛の全ての呼を、前記輻輳を通知していないSBCのアドレス宛の呼として確立しなおす、請求項6記載の呼制御システム。
【請求項9】
複数の端末、前記複数の端末からのパケットを滞留させる入力バッファを有するセッション・ボーダー・コントローラー(SBC)を有するシステムで用いられる、前記SBCを制御する呼制御サーバーであって、
前記SBCから輻輳を通知されると、
前記SBCに対し新たな呼を受け付けないよう指示するか、又は
前記SBCが接続している呼のうち、より多くの帯域を使用するコーデックを使用している呼及び処理負荷のより大きいコーデックを使用している呼のうち、1又は複数の呼を切断するよう更に指示する、呼制御サーバー。
【請求項10】
複数の端末及び呼制御サーバーを有するシステムで用いられ、前記複数の端末からのパケットを滞留させる入力バッファを有するセッション・ボーダー・コントローラー(SBC)であって、
前記入力バッファを監視し、所定の輻輳閾値を超えてパケットが滞留しているか否かを決定する輻輳監視部、及び
前記呼制御サーバーへ輻輳を通知する制御信号処理部、を有し、
前記所定の輻輳閾値を超えてパケットが滞留していると決定された場合、前記SBCが接続している呼のうち、より多くの帯域を使用するコーデックを使用している呼及び処理負荷のより大きいコーデックを使用している1又は複数の呼に対応する1又は複数のインターフェース若しくはVPN(仮想プライベート・ネットワーク)設定を削除する、呼制御サーバー。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【公開番号】特開2010−4495(P2010−4495A)
【公開日】平成22年1月7日(2010.1.7)
【国際特許分類】
【出願番号】特願2008−163766(P2008−163766)
【出願日】平成20年6月23日(2008.6.23)
【出願人】(000004226)日本電信電話株式会社 (13,992)
【Fターム(参考)】
【公開日】平成22年1月7日(2010.1.7)
【国際特許分類】
【出願日】平成20年6月23日(2008.6.23)
【出願人】(000004226)日本電信電話株式会社 (13,992)
【Fターム(参考)】
[ Back to top ]