JP5487776B2 - 通信制御装置及びそれに用いる呼処理輻輳制御方法 - Google Patents

Description

本発明は通信制御装置及びそれに用いる呼処理輻輳制御方法に関し、特に複数の機能処理部にまたがって処理される呼処理におけるパケット処理に関する。

本発明に関連する呼処理におけるパケット処理は、装置内で複数の機能処理部にまたがって処理されている。機能処理部間にはキューが設けられ、このキューによって輻輳及びパケット廃棄を吸収しているが、呼種別や呼処理量等の負荷環境によってキュー長の最適値が異なる。

尚、ネットワークにおけるパケット処理については、高速、高効率のパケット輻輳制御を行う技術（例えば、特許文献１参照）、外部バッファ装置を設けることで輻輳によるパケット廃棄を確実に回避する技術（例えば、特許文献２参照）が知られている。

特開２００５−０９４３９２号公報 特開２００７−３２５１７８号公報

しかしながら、本発明に関連するパケット処理では、機能処理部間にキューを設け、このキューによって輻輳及びパケット廃棄を吸収しているが、呼種別や呼処理量等の負荷環境によってキュー長の最適値が異なるため、運用での環境によってキュー長の設定値が必ずしも最適値にならないという課題がある。

また、本発明に関連するパケット処理では、実環境での各機能処理部の処理時間測定が困難であり、どこがボトルネックとなっているかがわからないという課題もある。

本発明に関連するパケット処理では、該当装置が処理する呼種別及び呼トラフィック状況が、顧客のネットワーク使用状況によって異なる。このような状況で発生した装置内輻輳は、どのようになっているのかを把握するすべがなく、最適な輻輳対処ができない。

尚、上記の特許文献１，２に記載の技術では、輻輳によるパケット廃棄に関する技術であり、上述したような課題を解決することができない。

そこで、本発明の目的は上記の問題点を解消し、輻輳時のボトルネック箇所を判別することができ、各運用環境にあったキュー長の最適なチューニングを行うことができる通信制御装置及びそれに用いる呼処理輻輳制御方法を提供することにある。

本発明による通信制御装置は、呼処理パケットを複数の機能処理手段にまたがって処理し、前記複数の機能処理手段各々の間に処理キューを配置した通信制御装置であって、
次段の機能処理手段との間の処理キューへ前記呼処理パケットを蓄積する前及び前段の機能処理手段との間の処理キューから前記呼処理パケットを取出す場合に前記複数の機能処理手段各々から通知されるタイムスタンプ情報を基に前記複数の機能処理手段各々での呼処理パケット処理時間を算出する処理時間測定手段と、前記処理時間測定手段の算出結果を基に各機能処理手段の輻輳状態を判別する輻輳制御手段とを備え、
前記輻輳制御手段は、前記輻輳状態と判断された前記機能処理手段の前段の処理キューのキュー長を調整する。

本発明による呼処理輻輳制御方法は、呼処理パケットを複数の機能処理手段にまたがって処理し、前記複数の機能処理手段各々の間に処理キューを配置した通信制御装置に用いる呼処理輻輳制御方法であって、
次段の機能処理手段との間の処理キューへ前記呼処理パケットを蓄積する前及び前段の機能処理手段との間の処理キューから前記呼処理パケットを取出す場合に前記複数の機能処理手段各々から通知されるタイムスタンプ情報を基に前記複数の機能処理手段各々での呼処理パケット処理時間を算出する処理時間測定処理と、前記処理時間測定処理の算出結果を基に各機能処理手段の輻輳状態を判別する輻輳制御処理とを備え、
前記輻輳制御処理は、前記輻輳状態と判断された前記機能処理手段の前段の処理キューのキュー長を調整する。

本発明は、上記のような構成及び動作とすることで、輻輳時のボトルネック箇所を判別することができ、各運用環境にあったキュー長の最適なチューニングを行うことができるという効果が得られる。

本発明の実施の形態による通信制御装置内の呼処理パケットの呼処理部の構成例を示すブロック図である。 本発明の実施の形態で用いるタイムスタンプ情報の一例を示す図である。 図１の処理時間測定部内のタイムスタンプデータの構成例を示す図である。 本発明の実施の形態による通信制御装置内の呼処理パケットの呼処理部の動作例を示す図である。

次に、本発明の実施の形態について図面を参照して説明する。まず、本発明による通信制御装置の概要について説明する。本発明による通信制御装置内においては、呼処理パケットを複数の機能処理部にまたがって処理している場合、呼処理能力を最大限に行えるよう各機能処理部のキュー長をチューニングする必要がある。しかしながら、この通信制御装置の運用では、呼種別や呼処理量、パケットトラフィック量等の環境の違いにより、ボトルネックが異なってくる場合がある。

本発明による通信制御装置では、運用中の各機能処理部の処理時間を測定することにより輻輳状態を確認し、それぞれの環境にあった最適なチューニングを可能とすることを特徴としている。

より具体的に説明すると、本発明による通信制御装置では、呼処理パケットの処理を複数の機能処理部にて、処理キューを介して行っていく。処理時間測定部はタイムスタンプデータを有し、タイムスタンプデータはパケットを識別するためのシーケンス番号とタイムスタンプと機能処理部を識別するための処理部識別子とからなるタイムスタンプ情報を保有する。このタイムスタンプデータは、処理時間測定部内のデータエリアに、登録毎に書込みを行い、データの蓄積を行っている。

各機能処理部では、呼処理パケットを処理キューに積む前（呼処理パケットの処理キューへの蓄積前）と、処理キューから呼処理パケットを刈り取った時点（処理キューからの呼処理パケットの出力時点）で、タイムスタンプ情報を処理時間測定部へ通知し、タイムスタンプデータに登録する。

この動作によって、処理時間測定部内のデータエリアには、タイムスタンプデータが作成され、処理時間測定部では、このデータから各機能処理部での呼処理パケット処理時間を算出する。

輻輳制御部は、処理時間測定部からの算出データを定期的に監視することで、処理時間がある一定以上の値となった時点で輻輳状態と判断する。これによって、輻輳制御部では、自動的に輻輳状態を検出することが可能となる。

また、本発明による通信制御装置では、処理時間測定部からの算出データにより各処理キューの輻輳状態が判別可能となるため、ボトルネック箇所が判別可能となる。本発明による通信制御装置では、この結果を輻輳制御部から呼処理部にフィードバックすることにより、装置ポリシーに沿った各処理キューのキュー長のチューニングをすることが可能となる。

さらに、本発明による通信制御装置では、タイムスタンプ情報処理を呼処理部と分けたことにより、呼処理に影響を与えることなく、処理時間の算出が可能となる。

図１は本発明の実施の形態による通信制御装置内の呼処理パケットの呼処理部の構成例を示すブロック図であり、図２は本発明の実施の形態で用いるタイムスタンプ情報の一例を示す図であり、図３は図１の処理時間測定部内のタイムスタンプデータの構成例を示す図である。

図１において、本発明の実施の形態による通信制御装置は、呼処理部１と、輻輳制御部２と、処理時間測定部３とを備えている。呼処理部１は複数の機能処理部１１−１〜１１−ｎ＋１と、処理キュー１２−１〜１２−ｎとを備え、呼処理パケットの処理を複数の機能処理部１１−１〜１１−ｎ＋１にて、処理キュー１２−１〜１２−ｎを介して行っている。

処理時間測定部３は、タイムスタンプデータ３１を有する。タイムスタンプデータ３１は、図２に示すように、パケットを識別するためのシーケンス番号４１とタイムスタンプ４２と機能処理部１１−１〜１１−ｎ＋１を識別するための処理部識別子４３とからなるタイムスタンプ情報４０を保有する。処理時間測定部３内のデータエリアには、このタイムスタンプ情報４０が、図３に示すように、登録毎に書込みを行って蓄積される。

各機能処理部１１−１〜１１−ｎ＋１では、処理キュー１２−１〜１２−ｎに積む前（呼処理パケットの処理キュー１２−１〜１２−ｎへの蓄積前）と、処理キュー１２−１〜１２−ｎから呼処理パケットを刈り取った時点（処理キュー１２−１〜１２−ｎからの呼処理パケットの出力時点）で、タイムスタンプ情報４０を処理時間測定部３へ通知する。処理時間測定部３は、通知されてきたタイムスタンプ情報４０をタイムスタンプデータ３１に登録する。

処理時間測定部３では、この動作によって、図３に示すようなタイムスタンプデータ３１が作成され、このタイムスタンプデータ３１から各機能処理部１１−１〜１１−ｎ＋１での呼処理パケット処理時間が算出可能となる。

輻輳制御部２は、処理時間測定部３からの算出データを定期的に監視することで、処理時間がある一定以上の値となった時点で輻輳状態と判断する。これによって、輻輳制御部２では、自動的に輻輳状態を検出することが可能となる。また、輻輳制御部２では、算出データより各処理キュー１２−１〜１２−ｎの輻輳状態が判別可能となるため、ボトルネック箇所を判別することが可能となる。

本実施の形態では、この結果を輻輳制御部２から呼処理部１にフィードバックすることにより、装置ポリシーに沿った各処理キュー１２−１〜１２−ｎのキュー長のチューニングをすることが可能となる。

また、本実施の形態では、タイムスタンプ情報の処理（輻輳制御部２及び処理時間測定部３の処理）を呼処理部１と分けたことにより、呼処理に影響を与えることなく、各機能処理部１１−１〜１１−ｎ＋１での処理時間を算出することが可能となる。

図４は本発明の実施の形態による通信制御装置内の呼処理パケットの呼処理部の動作例を示す図である。図４においては、通信制御装置内の呼処理能力の低下が見られ、通信制御装置内で輻輳状態になった場合のボトルネック箇所の確認及びキュー長のチューニングについて示す。

図４では、図１と同様の呼処理部１が通信制御装置内の呼処理パケットを処理する様子を示している。呼処理パケットの処理は、複数の機能処理部１１−１〜１１−ｎ＋１にて、処理キュー１２−１〜１２−ｎを介して処理されていく。

図４において、呼処理パケットを受信した機能処理部１１−１にて処理を行った後、次の機能処理部１１−２へ処理を引き渡すため、呼処理パケットを処理キュー１２−１へ積む。その際、機能処理部１１−１は、処理時間測定部３へタイムスタンプ情報４０の登録を行う（図４の２０２参照）。

処理キュー１２−１に積まれた呼処理パケットは、機能処理部１１−２にて刈り取られる。その際、上記と同様に、機能処理部１１−２は、処理時間測定部３へタイムスタンプ情報４０の登録を行う（図４の２０２参照）。この処理は、全ての機能処理部１１−１〜１１−ｎ＋１にて行われる。

処理時間測定部３では、各機能処理部１１−１〜１１−ｎ＋１から登録されたタイムスタンプ情報４０を、データエリアに有するタイムスタンプデータ３１に順に書込んでいく（図３参照）。

タイムスタンプデータ３１は、図２に示すように、パケットを識別するためのシーケンス番号４１とタイムスタンプ４２と機能処理部１１−１〜１１−ｎ＋１を識別するための処理部識別子４３とからなるタイムスタンプ情報４０を保有する。本実施の形態では、この情報により、該当パケットの各機能処理部１１−１〜１１−ｎ＋１における処理時間の算出が可能となる。

例えば、図３に示すように、タイムスタンプ情報４０が書込まれていた場合、データ３１２からデータ３１３において、処理識別子“２”を持つ機能処理部のシーケンス番号“１００”のパケット処理に５ｍｓかかったことがわかる。この値が、ある一定以上であれば輻輳と判断することが可能となる。また、輻輳が発生し、途中の処理キューにて廃棄が起きた場合には、ある一定時間内に次処理タイムスタンプ情報がないことから、その廃棄を判別することが可能となる。

図４において、処理時間測定部３は、呼処理パケットを処理キュー１２−１〜１２−ｎに積む前と、処理キュー１２−１〜１２−ｎから呼処理パケットを刈り取った時点で、タイムスタンプ情報を処理時間測定部３へ通知し（図４の２０２参照）、処理時間測定部３のタイムスタンプデータ３１に登録する。

輻輳処理部２では、定期的に処理時間測定部３へ、タイムスタンプデータ３１の解析指示（図４の２０５参照）を行っている。処理時間測定部３では、収集していたタイムスタンプデータ３１より、各機能処理部１１−１〜１１−ｎ＋１での処理時間及びパケット廃棄を算出する。

本実施の形態では、処理時間測定部３の算出結果から、機能処理部１１−２にて輻輳（図４の２０１参照）及び処理キュー１２−１にて廃棄（図４の２００参照）が起きていることが分かり、機能処理部１１−２がボトルネックであることが判別可能となる。

処理時間測定部３の算出結果は、輻輳制御部２に通知（図４の２０３参照）することにより、例えば装置ポリシーとして、廃棄パケットを少なくしたい場合、ボトルネックとなっている機能処理部１１−２の前段の処理キュー１２−１のキュー長を深くするチューニング（図４２０４参照）を行うことで、その運用環境に合わせた輻輳制御を行うことが可能となる。

また、この装置内輻輳は、輻輳制御部２と処理時間測定部３との連携を常時行うことにより、事前に検出することが可能となっており、ネットワーク上への影響を最小限に抑えている。

このように、本実施の形態では、呼処理部１内の各機能処理部１１−１〜１１−ｎ＋１にて、タイムスタンプ情報を収集することにより、各機能処理部１１−１〜１１−ｎ＋１でのパケット処理時間の算出が可能となり、輻輳時のボトルネック箇所の判別が可能となる。

また、本実施の形態では、実運用での輻輳時のボトルネック箇所の判別が可能になることにより、各運用環境にあったキュー長の最適なチューニングが可能となる。

さらに、本実施の形態では、常時、輻輳状態の監視を行うことにより、ネットワーク上で検出される呼処理遅延やパケット廃棄の抑止が可能となる。

さらにまた、本実施の形態では、タイムスタンプ情報処理（輻輳制御部２及び処理時間測定部３との処理）を呼処理部１と分けたことにより、呼処理に影響を与えることなく、処理時間の算出が可能となる。

尚、本発明は、呼処理部１のソフトウェア変更や機能追加があった場合に、システム試験において上記のタイムスタンプ情報処理を行うことで、各機能処理部１１−１〜１１−ｎ＋１の処理時間測定やボトルネック再調査により、開発へのフィーバッグ及び輻輳制御対処を行うことが可能となる。

本発明は、呼処理の輻輳が考えられるネットワーク上の各装置に適用することが可能である。

１ 呼処理部
２ 輻輳制御部
３ 処理時間測定部
１１−１〜１１−ｎ＋１ 機能処理部
１２−１〜１２−ｎ 処理キュー
３１ タイムスタンプデータ

Claims (6)

1. 呼処理パケットを複数の機能処理手段にまたがって処理し、前記複数の機能処理手段各々の間に処理キューを配置した通信制御装置であって、
   次段の機能処理手段との間の処理キューへ前記呼処理パケットを蓄積する前及び前段の機能処理手段との間の処理キューから前記呼処理パケットを取出す場合に前記複数の機能処理手段各々から通知されるタイムスタンプ情報を基に前記複数の機能処理手段各々での呼処理パケット処理時間を算出する処理時間測定手段と、前記処理時間測定手段の算出結果を基に各機能処理手段の輻輳状態を判別する輻輳制御手段とを有し、
   前記輻輳制御手段は、前記輻輳状態と判断された前記機能処理手段の前段の処理キューのキュー長を調整することを特徴とする通信制御装置。
2. 前記輻輳制御手段は、前記呼処理パケット処理時間が予め設定された一定以上の値となった場合に前記輻輳状態と判断することを特徴とする請求項１記載の通信制御装置。
3. 前記タイムスタンプ情報は、前記呼処理パケットを識別するためのシーケンス番号とタイムスタンプと前記機能処理手段を識別するための処理部識別子とからなることを特徴とする請求項１または請求項２記載の通信制御装置。
4. 呼処理パケットを複数の機能処理手段にまたがって処理し、前記複数の機能処理手段各々の間に処理キューを配置した通信制御装置に用いる呼処理輻輳制御方法であって、
   次段の機能処理手段との間の処理キューへ前記呼処理パケットを蓄積する前及び前段の機能処理手段との間の処理キューから前記呼処理パケットを取出す場合に前記複数の機能処理手段各々から通知されるタイムスタンプ情報を基に前記複数の機能処理手段各々での呼処理パケット処理時間を算出する処理時間測定処理と、前記処理時間測定処理の算出結果を基に各機能処理手段の輻輳状態を判別する輻輳制御処理とを有し、
   前記輻輳制御処理は、前記輻輳状態と判断された前記機能処理手段の前段の処理キューのキュー長を調整することを特徴とする呼処理輻輳制御方法。
5. 前記輻輳制御処理において、前記呼処理パケット処理時間が予め設定された一定以上の値となった場合に前記輻輳状態と判断することを特徴とする請求項４記載の呼処理輻輳制御方法。
6. 前記タイムスタンプ情報は、前記呼処理パケットを識別するためのシーケンス番号とタイムスタンプと前記機能処理手段を識別するための処理部識別子とからなることを特徴とする請求項４または請求項５記載の呼処理輻輳制御方法。

Images