JP2007329617A - 通信制御処理実行方法およびシステム、ならびにそのプログラム - Google Patents
通信制御処理実行方法およびシステム、ならびにそのプログラム Download PDFInfo
- Publication number
- JP2007329617A JP2007329617A JP2006158067A JP2006158067A JP2007329617A JP 2007329617 A JP2007329617 A JP 2007329617A JP 2006158067 A JP2006158067 A JP 2006158067A JP 2006158067 A JP2006158067 A JP 2006158067A JP 2007329617 A JP2007329617 A JP 2007329617A
- Authority
- JP
- Japan
- Prior art keywords
- request
- call
- processing
- control server
- server
- 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.)
- Pending
Links
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
- Telephonic Communication Services (AREA)
Abstract
【課題】高負荷時においても接続要求処理を迅速に応答し、また、負荷に対するサーバの耐性を向上することが可能な通信制御処理実行方法およびシステムを実現する。
【解決手段】IPネットワークでの呼処理サーバに関し、呼処理バッファに優先度の異なる2種類以上のキュー60,70を用意することにより、接続要求処理の実行を切断要求処理の実行よりも優先して行う。呼処理タスクが次の処理を行うために、キュー60,70からイベントを取り出す際に、キュー60,70の間で取り出し順の優先制御を行う。ルータなどのパケット転送処理と同様に、PQ、あるいは、WRRなどのスケジューリングアルゴリズムを適用し、応答時間条件の厳しい処理要求呼を優先して処理する。Tpは各要求呼に対する処理の所要時間であリ、Tqはキューにおける平均待ち時間であり、sはサーバが同時に処理を並行実行できる数である。
【選択図】図4
【解決手段】IPネットワークでの呼処理サーバに関し、呼処理バッファに優先度の異なる2種類以上のキュー60,70を用意することにより、接続要求処理の実行を切断要求処理の実行よりも優先して行う。呼処理タスクが次の処理を行うために、キュー60,70からイベントを取り出す際に、キュー60,70の間で取り出し順の優先制御を行う。ルータなどのパケット転送処理と同様に、PQ、あるいは、WRRなどのスケジューリングアルゴリズムを適用し、応答時間条件の厳しい処理要求呼を優先して処理する。Tpは各要求呼に対する処理の所要時間であリ、Tqはキューにおける平均待ち時間であり、sはサーバが同時に処理を並行実行できる数である。
【選択図】図4
Description
本発明は、IPネットワークなどの通信網において、通信サービスの開始・終了時の呼設定・切断処理や通話中のセッション状態管理を行う通信制御サーバのソフトウェアにおける通信制御処理実行方法およびシステム、ならびにそのプログラムに関する。
IPネットワークなどのパケット通信では、複数の利用者が共通のネットワークを用いてそれぞれパケットの送受信を行っている。ネットワークは有限の通信リソース(回線の帯域幅、ノードのバッファ量など)を持っているため、利用者数が大きくなってネットワークの転送能力を超える量のパケットが流入すると、パケットの到着の遅延が大きくなったり、廃棄(パケットのロス)が発生したりして、通信サービスの品質が劣化してしまう。
これに対して、ノードでのパケット転送時に優先制御を行う方法が普及している。例えば、IPネットワークにおけるDiffservという方式は、パケットのヘッダに優先度を付けておき、ルータで転送能力を超えるパケットが流入した際には、優先度の低いパケットを廃棄したり、後回しにして、優先度の高いパケットを優先的に転送するものであって、これにより、パケットの遅延や廃棄確率などの品質条件を相対的に高く保つことが可能になる(S.Blake,D.Black,M.Carlson,E.Davies,Z.Wang,and W.Weiss:An architecture for differentiated services,RFC2475,DECEMBER 1998.を参照(非特許文献4))。
近年、市販されているルータにも、上記の機能が実装されているものが多い。
パケット通信においては、利用者が転送したい情報を1つまたは複数のパケットを使用して送信する。一般的に、あるネットワークの利用(あるデータの転送開始から終了まで、ある電話の通話開始から終了まで、など)をセッションと呼び、そのセッションのために連続的に転送されるパケットの集合のことをフローと呼ぶ。
優先制御の主な利用方法としては、パケットごとに転送優先度を決定するのではなく、フロー単位で優先度を付ける。
パケット通信においては、利用者が転送したい情報を1つまたは複数のパケットを使用して送信する。一般的に、あるネットワークの利用(あるデータの転送開始から終了まで、ある電話の通話開始から終了まで、など)をセッションと呼び、そのセッションのために連続的に転送されるパケットの集合のことをフローと呼ぶ。
優先制御の主な利用方法としては、パケットごとに転送優先度を決定するのではなく、フロー単位で優先度を付ける。
ところで、前記の優先制御について、この方法では転送優先度の高いフローと低いフローが混在している場合には、高優先フローの転送品質の確保に効果があるが、高優先度フロー数が増加し、それだけでネットワークリソースを使い切ってしまうような場合には、高優先フローであっても転送品質の劣化は免れない。高優先フローをネットワークのリソース容量以上に収容することは可能であるが、サービス品質の劣化が全利用者に及んでしまう、という問題があった。
(受付制御)
前記の問題を解決し、転送品質を維持するために、ネットワークのリソース容量以上の利用要求を拒絶するという制御を行う方法が有効であり、これを受付制御(Admission Control)と呼ぶ(前記の非特許文献2および非特許文献3参照)。
前記非特許文献2,3では、IPネットワークにおいて、ネットワーク中の全てのリンクのリソース容量と利用されているリソース量を把握しておくことで、新たなセッションの発生による利用要求を受信した際に受付判定を行う方法、およびシステムが記述されている。
前記の問題を解決し、転送品質を維持するために、ネットワークのリソース容量以上の利用要求を拒絶するという制御を行う方法が有効であり、これを受付制御(Admission Control)と呼ぶ(前記の非特許文献2および非特許文献3参照)。
前記非特許文献2,3では、IPネットワークにおいて、ネットワーク中の全てのリンクのリソース容量と利用されているリソース量を把握しておくことで、新たなセッションの発生による利用要求を受信した際に受付判定を行う方法、およびシステムが記述されている。
リソース管理サーバでは、管理対象のネットワーク中の全てのリンクについて、高優先フローが使用しているリソース量をリアルタイムに管理している。これは、高優先フローの利用開始時に利用要求を受信し、それを記録することにより行われる。また、リソース管理サーバは、ネットワークからの情報収集によって経路情報と各リンクのリソース容量を把握している。利用要求の受信時には、そのフローが通過する全てのリンクを経路情報から検索し、各リンクの使用リソース量を加算して記録する。このとき、使用量がリソース容量を超えてしまう場合には、この利用要求に対して利用すること自体を、または優先フローとして扱うことを拒絶する。後者の場合、該当する要求の通信は非優先フローとして許可される。
このようなリソース管理・受付制御方法により、高優先フローはネットワークのリソース容量が許す限り収容され、容量を超えることは防止されるので、利用を許容されたフローはその品質が確保される。
このようなリソース管理・受付制御方法により、高優先フローはネットワークのリソース容量が許す限り収容され、容量を超えることは防止されるので、利用を許容されたフローはその品質が確保される。
(受付制御の適用例)
前記機能を持つリソース管理・受付制御サーバは、通信キャリアがIP技術で様々な通信サービスを統合して大規模に展開する次世代ネットワーク(「NGN」)の国際標準化の中でもその必要性を認識されており、ITU−TやETSI TISPANにおいてRACS(Resource and Admission Control Subsystem)としてネットワークアーキテクチャ内に定義されている。
前記機能を持つリソース管理・受付制御サーバは、通信キャリアがIP技術で様々な通信サービスを統合して大規模に展開する次世代ネットワーク(「NGN」)の国際標準化の中でもその必要性を認識されており、ITU−TやETSI TISPANにおいてRACS(Resource and Admission Control Subsystem)としてネットワークアーキテクチャ内に定義されている。
このような適用例の中で、リソース管理・受付制御サーバは、IP電話,TV電話,VoDなどの様々なセッションベースの通信サービスの発信時にアプリケーションサーバやセッション制御サーバから受付制御機能として呼び出され、応答を行うことが期待される。
具体的には、呼の生起(利用者がサービス利用開始の意思を通知する)時に利用者からの接続要求がアプリケーションサーバやセッション制御サーバに通知され、各サーバが接続処理を行う中で、求められる品質で接続することが可能か否かを受付制御サーバに問い合わせる。
具体的には、呼の生起(利用者がサービス利用開始の意思を通知する)時に利用者からの接続要求がアプリケーションサーバやセッション制御サーバに通知され、各サーバが接続処理を行う中で、求められる品質で接続することが可能か否かを受付制御サーバに問い合わせる。
受付制御サーバは、前記問い合わせに対してリソースの空き状況を確認し、空きがあると判断されれば受付許可を、空きがないと判断されれば受付拒否を、それぞれ通知する。
また、受付が許可されるた接続が確立された後、その呼が終了する際には、呼の切断処理が行われる。この中で、切断要求を認識したアプリケーションサーバやセッション制御サーバは受付制御サーバに対して該当呼の終了を通知する。ここで、受付制御サーバは、該当呼のために確保していたリソースを解放する処理を行い、切断処理の完了通知を応答する。
また、受付が許可されるた接続が確立された後、その呼が終了する際には、呼の切断処理が行われる。この中で、切断要求を認識したアプリケーションサーバやセッション制御サーバは受付制御サーバに対して該当呼の終了を通知する。ここで、受付制御サーバは、該当呼のために確保していたリソースを解放する処理を行い、切断処理の完了通知を応答する。
(受付制御サーバの呼処理容量の要求条件)
前記受付制御サーバを始め、既存電話網における電話交換機やIPネットワークにおけるWebサーバ、セッション制御サーバ、認証サーバなど、通信サーバにおいて接続を制御するサーバでは、性能に関係する様々な要求条件があるが、その中でも特に「応答時間」,「処理容量」が重要である。応答時間は要求受信から応答するまでの時間であり、これが長くなると利用者の要求通知からサービス使用開始までの待ち時間が長くなり、体感する利用品質に影響するなどの問題が生じる。その一例として、既存電話網の品質基準としては、接続遅延時間は3秒以上となる確率が0.01以下となること、と規定されている(事業用電気通信設備規則第35条)。この場合、サービスが開始されるまでにセッション制御サーバ、受付制御サーバなどを何段も介することを考慮すると、1サーバ当りの応答時間は数100ミリ秒以内である必要がある。
前記受付制御サーバを始め、既存電話網における電話交換機やIPネットワークにおけるWebサーバ、セッション制御サーバ、認証サーバなど、通信サーバにおいて接続を制御するサーバでは、性能に関係する様々な要求条件があるが、その中でも特に「応答時間」,「処理容量」が重要である。応答時間は要求受信から応答するまでの時間であり、これが長くなると利用者の要求通知からサービス使用開始までの待ち時間が長くなり、体感する利用品質に影響するなどの問題が生じる。その一例として、既存電話網の品質基準としては、接続遅延時間は3秒以上となる確率が0.01以下となること、と規定されている(事業用電気通信設備規則第35条)。この場合、サービスが開始されるまでにセッション制御サーバ、受付制御サーバなどを何段も介することを考慮すると、1サーバ当りの応答時間は数100ミリ秒以内である必要がある。
ここで言う応答時間とは接続要求処理に対する応答時間のことであるが、切断要求に対する応答時間にも要求条件がある。通信サービスが通信時間に対する従量課金である場合には、切断時刻を正確に記録する必要がある。呼処理サーバのうち、切断時刻を記録するサーバにおいては、切断要求処理の実行が遅延してしまうと利用者へ過大に課金してしまうことになるので、接続要求処理と同様に、切断要求処理においても大きな処理遅延がないように、サーバの処理容量を確保しておく必要がある。
処理容量とは、単位時間当りに処理できる要求数であり、1秒当りの呼数、1時間当りの呼数などが論じられる。スループットと表されることも多い。処理容量が小さいと、利用者一人当りの発呼頻度が一定であると仮定した場合、そのシステムが収容できる利用者数が少なくなり、システムを多数導入することによりサービス提供のためのコストが上昇し、提供料金に反映されてサービスの利用価値が下がったり、競爭力が低下することにつながる。また、機能の特性上、システムを多数導入することでは収容利用者数を増加できないこともあり、サービス全体のスケール性に影響することもある。
(スループットと応答時間の関係)
前述のようなサーバでは、一般的に要求の到着順に処理を行うが、ある要求に対する処理を実行中に別の要求が到着した場合には、これをバッファに蓄積して待ち合わせることが多い。
このようなシステム内の動作は、待ち行列理論において、これまでに多くの議論がなされている。サーバのスループットより高い頻度で要求が到着する場合、待ち行列(キュー)に追加されて待ち合わせる要求数が多くなり、各要求呼に対する応答時間が長くなっていく。ここで、要求呼の到着間隔が指数分布(平均λ)、各要求呼に対する処理の所要時間がTpで一定と仮定し、サーバが同時に処理を並列実行できる数をsとすると、このシステムはケンドールの記号におけるM/D/S型の待ち行列モデルと考えることができ、キューにおける平均待ち時間Tqはクロメリン−ポラチェックの公式から下記のように表される。
前述のようなサーバでは、一般的に要求の到着順に処理を行うが、ある要求に対する処理を実行中に別の要求が到着した場合には、これをバッファに蓄積して待ち合わせることが多い。
このようなシステム内の動作は、待ち行列理論において、これまでに多くの議論がなされている。サーバのスループットより高い頻度で要求が到着する場合、待ち行列(キュー)に追加されて待ち合わせる要求数が多くなり、各要求呼に対する応答時間が長くなっていく。ここで、要求呼の到着間隔が指数分布(平均λ)、各要求呼に対する処理の所要時間がTpで一定と仮定し、サーバが同時に処理を並列実行できる数をsとすると、このシステムはケンドールの記号におけるM/D/S型の待ち行列モデルと考えることができ、キューにおける平均待ち時間Tqはクロメリン−ポラチェックの公式から下記のように表される。
図3は、Tp=8〔msec〕としたときの発呼頻度に対するキュー滞在時間の推移を表す図である。
ここで、発呼頻度はスループットSに対して正規化しており、S=s/Tpと表せる。このように、サーバに対する負荷が低く、スループットに対する発呼頻度の大きさが9割程度までは数ミリ秒で応答できていたものが、発呼頻度がスループットと同等程度になると100ミリ秒前後となり、スループットを超えると急激に上昇してしまうことがわかる。
つまり、スループットと応答時間には深い関係があり、スループットが高いということは、要求条件として定められた時間内に応答できる発呼頻度の限界を高めることができることになる。
ここで、発呼頻度はスループットSに対して正規化しており、S=s/Tpと表せる。このように、サーバに対する負荷が低く、スループットに対する発呼頻度の大きさが9割程度までは数ミリ秒で応答できていたものが、発呼頻度がスループットと同等程度になると100ミリ秒前後となり、スループットを超えると急激に上昇してしまうことがわかる。
つまり、スループットと応答時間には深い関係があり、スループットが高いということは、要求条件として定められた時間内に応答できる発呼頻度の限界を高めることができることになる。
なお、前述の非特許文献4の他にも、B.Teitelbaum,et al,“QBone Bandwidth Broker Architecture,”http://qbone.internet2.edu/bb/bboutline2.html(非特許文献1)、(笠原,増田,吉田,“パーフローQoSを実現するエージェント型リソース制御システム,”情報処理学会論文誌,Vol.46 No.2,pp.5 17−524,Feb.2005.(非特許文献2)、および、増田.佐藤,笠原,“受付制御のためのNWリソース管理方法の提案,”信学技報,NS2003−170,pp.5−8,Nov.2003.(非特許文献3)がある。
B.Teitelbaum,et al,"QBone Bandwidth Broker Architecture," http://qbone.internet2.edu/bb/bboutline2.html
笠原,増田,吉田,"パーフローQoSを実現するエージェント型リソース制御システム,"情報処理学会論文誌,Vol.46 No.2,pp.5 17−524,Feb.2005.
増田.佐藤,笠原,"受付制御のためのNWリソース管理方法の提案,"信学技報,NS2003−170,pp.5−8,Nov.2003.
S.Blake,D.Black,M.Carlson,E.Davies,Z.Wang,and W.Weiss:An architecture for differentiated services,RFC2475,DECEMBER 1998.
受付制御サーバが行う主な処理は、前述したように接続要求に対する処理と切断要求に対する処理である。他にも、サーバ間での接続を継続するために行う処理や、システムが正常に稼動を続けるための処理などが実行されているが、受付制御サーバの本来の使用目的は接続・切断要求に対する処理であり、特に高負荷状態は利用者の接続・切断要求の頻度が高まることによって発生するため、高負荷状態において受付制御サーバが行っている処理の殆んどは接続・切断要求処理となる。
受付制御サーバの処理能力を決定する要因のうち、最も重要なものにプロセッサの処理能力がある。前述のように、高負荷状態においてはプロセッサの能力の殆んどは接続要求,切断要求に対する処理に使われる。ここで、ある接続要求に対する受付が成功した場合は、その通信の終了時に切断要求が発生する。従って、接続要求に対する受付制御結果の殆んどが成功であると仮定すると、受付制御サーバに到着する接続要求と切断要求の数はほぼ同じ(切断要求の方がわずかに少ない)となる。
一般的にセッション制御サーバでは、接続要求、切断要求などの処理要求を呼処理バッファ(イベントキュー)に登録し、呼処理を行うプログラムが登録されたイベントを受け取って処理していく。ここで、一般的には接続要求と切断要求処理は、処理の順番という意味では同等に扱われ、発生した順(呼処理バッファに登録された順)に処理されていく。このため、高負荷時においては、受付制御サーバのプロセッサは接続要求の処理と切断要求の処理がほぼ半分ずつ分け合っていることになる。
前述のように、セッション制御サーバでは、利用品質の確保のために接続要求を、課金のための切断時刻記録のために切断要求を、それぞれ迅速に実行する必要がある。しかし、同様にセッション確立時の接続要求と、セッション終了時の切断要求に対する処理を行う呼処理サーバの中には、切断時間の正確な記録が要求されないものがある。この場合、切断要求に対する処理の応答時間の要求条件は、接続条件のそれより厳しくはない。このようなサーバで、前述のように接続要求処理と切断要求処理を同等の優先度で発生順に処理している場合、プロセッサのリソースを効率的に利用しているとは言えない。
(目的)
本発明の目的は、前記課題を解決するため、接続要求処理に対する応答時間の要求条件が厳しく、切断要求処理に対するそれが厳しくない呼処理サーバにおいて、呼処理プログラムで接続要求処理の実行を切断要求処理の実行より優先して行うことで、高負荷時においても接続要求処理を迅速に応答し、また、負荷に対するサーバの耐性を向上することが可能な通信制御処理実行方法およびシステムを提供することにある。
本発明の目的は、前記課題を解決するため、接続要求処理に対する応答時間の要求条件が厳しく、切断要求処理に対するそれが厳しくない呼処理サーバにおいて、呼処理プログラムで接続要求処理の実行を切断要求処理の実行より優先して行うことで、高負荷時においても接続要求処理を迅速に応答し、また、負荷に対するサーバの耐性を向上することが可能な通信制御処理実行方法およびシステムを提供することにある。
本発明の通信制御処理実行方法およびシステムは、通信サービスの利用開始時に接続要求を受信し、それに対する呼設定処理を、また、利用終了時に終了通知を受信し、それに対する終了処理を行うサーバにおいて、両要求呼に対して異なるキューを持ち、呼処理時のキュー取り出しにおいては接続要求呼を優先することで、高負荷時にもサーバ内の処理待ち時間を短かく抑えることを特徴とする。
本発明によれば、高負荷時の接続処理応答時間を短縮することができるとともに、プロセッサ使用率100%未満での輻輳制御発動を行う必要がないため、輻輳に対する耐性を向上させることができる。
以下、本発明の原理と実施例を説明する。
(原理)
図4は、本発明の呼処理実行制御方法の原理を示す説明図である。
前述のように、呼処理プログラムでは、到着した処理要求呼を呼処理バッファに蓄積する。呼処理バッファはキュー(待ち行列)となっており、従来の呼処理サーバでは、これを到着順に処理していた。
本発明では、呼処理バッファにおいて優先度の高い(応答時間の厳しい、例えば、接続要求)要求と優先度の低い(応答時間条件が厳しくない、例えば、切断要求)要求に対しては、異なるキューを用意する。一般的に、呼処理サーバに処理要求が到着すると、その要求呼は要求種別に応じて該当するキューに追加される。呼処理プログラム中の呼処理を実行する部分は、キューから要求呼(イベント)を取り出し、これを実行し、終了した後、キューを確認し、イベントがあればこれを取り出し、実行する、ということを繰り返す。なお、キューにイベントがない場合には待ち状態となり、イベントの発生時に再度起動される。
(原理)
図4は、本発明の呼処理実行制御方法の原理を示す説明図である。
前述のように、呼処理プログラムでは、到着した処理要求呼を呼処理バッファに蓄積する。呼処理バッファはキュー(待ち行列)となっており、従来の呼処理サーバでは、これを到着順に処理していた。
本発明では、呼処理バッファにおいて優先度の高い(応答時間の厳しい、例えば、接続要求)要求と優先度の低い(応答時間条件が厳しくない、例えば、切断要求)要求に対しては、異なるキューを用意する。一般的に、呼処理サーバに処理要求が到着すると、その要求呼は要求種別に応じて該当するキューに追加される。呼処理プログラム中の呼処理を実行する部分は、キューから要求呼(イベント)を取り出し、これを実行し、終了した後、キューを確認し、イベントがあればこれを取り出し、実行する、ということを繰り返す。なお、キューにイベントがない場合には待ち状態となり、イベントの発生時に再度起動される。
この『呼処理の実行部分』は、呼処理シナリオなどと呼ばれ、1つまたは複数のタスク、プロセス、スレッドなどのコンピュータの実行単位として動作する。実行単位は呼処理サーバの環境(オペレーティングシステムの対応、最適性)によって異なる。以後、本文では、『呼処理タスク』と呼ぶ。
本発明では、呼処理タスクが次の処理を行うために、キューからイベントを取り出す際に、キュー間で取り出し順の優先制御を行う。ルータなどのパケット転送処理と同様に、PQ(プライオリティ・キューイング)、WRR(ウェイテッド・ラウンドロビン)などのスケジューリングアルゴリズムを適用し、応答時間条件の厳しい処理要求呼を優先して処理する。
本発明では、呼処理タスクが次の処理を行うために、キューからイベントを取り出す際に、キュー間で取り出し順の優先制御を行う。ルータなどのパケット転送処理と同様に、PQ(プライオリティ・キューイング)、WRR(ウェイテッド・ラウンドロビン)などのスケジューリングアルゴリズムを適用し、応答時間条件の厳しい処理要求呼を優先して処理する。
PQの場合を例にとると、呼処理タスクはある呼処理が終了した後、まず高優先キューを確認し、イベントがあればそれを取り出して実行する。なければ、次に優先度の高いキュー(キューが高/低の2種類しかなければ、低優先度キュー)を確認し、イベントがあればこれを処理する。全てのキューにイベントがなければ、待ち状態に入り、後にイベントが発生して、呼び出されるまで待機する。
図4は、キューが高/低の2種類しか設けられていない場合の構成を示しており、高優先度として接続要求キュー60、低優先度として切断要求キュー70がそれぞれ設けられる。Tpは各要求呼に対する処理の所要時間であって、一定と仮定される。また、Tqはキューにおける平均待ち時間であって、前式〔数1〕で表わされる。また、sは、サーバが同時に処理を並行実行できる数である。
まず、キューに対して優先度を付ける。接続要求キュー60を高優先、切断要求キュー70を低優先とする。呼処理タスクはある呼処理が終了した後、まず高優先の接続要求キュー60を確認し、イベントがあればそれを取り出して実行する。なければ、低優先の切断要求キュー70を確認し、イベントがあれば処理する。全てのキュー60,70にイベントがなければ、待ち状態に入り、後にイベントが発生し呼び出されるまで待機する。
このようなスケジューリングでプロセッサに渡されたイベントは、sだけ同時に並列処理され、所要時間Tpで処理が完了する。
まず、キューに対して優先度を付ける。接続要求キュー60を高優先、切断要求キュー70を低優先とする。呼処理タスクはある呼処理が終了した後、まず高優先の接続要求キュー60を確認し、イベントがあればそれを取り出して実行する。なければ、低優先の切断要求キュー70を確認し、イベントがあれば処理する。全てのキュー60,70にイベントがなければ、待ち状態に入り、後にイベントが発生し呼び出されるまで待機する。
このようなスケジューリングでプロセッサに渡されたイベントは、sだけ同時に並列処理され、所要時間Tpで処理が完了する。
図1は、本発明の一実施例に係る接続要求、切断要求の処理手順を示す図である。
利用者端末1からセッション制御サーバ30に対して、利用開始(接続)要求を行うと、セッション制御サーバ30は呼設定処理を行って、受付制御サーバ20に対してリソース確保(接続)要求を行う。受付制御サーバ20はリソース確保処理を行い、セッション制御サーバ30に対して、リソース確保応答を行う。セッション制御サーバ30は呼設定処理を行って、要求のあった利用者端末1に対して、利用開始応答を行う。
利用者端末1が相手方と接続された後、通信を行い、用件が終了したときには、利用者端末1からセッション制御サーバ30に対して、利用終了(切断)通知を行う。セッション制御サーバ30は、終了処理を行って、受付制御サーバ20に対してリソース解放(切断)要求を行う。受付制御サーバ20は、リソース解放処理を行い、セッション制御サーバ30に対してリソース解放応答を行う。これにより、セッション制御サーバ30は、切断時刻記録を行う。
利用者端末1からセッション制御サーバ30に対して、利用開始(接続)要求を行うと、セッション制御サーバ30は呼設定処理を行って、受付制御サーバ20に対してリソース確保(接続)要求を行う。受付制御サーバ20はリソース確保処理を行い、セッション制御サーバ30に対して、リソース確保応答を行う。セッション制御サーバ30は呼設定処理を行って、要求のあった利用者端末1に対して、利用開始応答を行う。
利用者端末1が相手方と接続された後、通信を行い、用件が終了したときには、利用者端末1からセッション制御サーバ30に対して、利用終了(切断)通知を行う。セッション制御サーバ30は、終了処理を行って、受付制御サーバ20に対してリソース解放(切断)要求を行う。受付制御サーバ20は、リソース解放処理を行い、セッション制御サーバ30に対してリソース解放応答を行う。これにより、セッション制御サーバ30は、切断時刻記録を行う。
図2は、本発明における利用開始時の通信制御サーバの連携の例を示す図である。
利用者端末を収容するセッション制御サーバと、ネットワークで使用するリソースを管理する受付制御サーバとは、図2に示すような連携を行っている。
丸内の数字の順序で処理が進行される。
(1)利用者1(発信者)の端末からのこの端末を収容しているセッショ制御サーバ31に対して利用開始要求が送信されると、(2)セッション制御サーバ31は、利用開始要求の着信先の利用者2が収容されているセッション制御サーバ32に対して利用開始要求を転送する。(3)セッション制御サーバは、利用者2(着信)の端末に着信の通知を行う。また、(4)セッション制御サーバ32は、受付制御サーバ22に対してリソース確保要求を送信する。(5)受付制御サーバ22が管理するリソースを確保すると、セッション制御サーバ32は、セッション制御サーバ31に対して利用開始要求応答を返送する。(6)セッション制御サーバ31は、受付制御サーバ21に対してリソース確保要求を送信する。(7)受付制御サーバ21が管理するリソースを確保すると、セッション制御サーバ31は、利用者1(発信)の端末に対して利用開始要求応答(通話開始)を返送する。このような連携により、利用者1はネットワーク11を経由して利用者2と通話することができる。
利用者端末を収容するセッション制御サーバと、ネットワークで使用するリソースを管理する受付制御サーバとは、図2に示すような連携を行っている。
丸内の数字の順序で処理が進行される。
(1)利用者1(発信者)の端末からのこの端末を収容しているセッショ制御サーバ31に対して利用開始要求が送信されると、(2)セッション制御サーバ31は、利用開始要求の着信先の利用者2が収容されているセッション制御サーバ32に対して利用開始要求を転送する。(3)セッション制御サーバは、利用者2(着信)の端末に着信の通知を行う。また、(4)セッション制御サーバ32は、受付制御サーバ22に対してリソース確保要求を送信する。(5)受付制御サーバ22が管理するリソースを確保すると、セッション制御サーバ32は、セッション制御サーバ31に対して利用開始要求応答を返送する。(6)セッション制御サーバ31は、受付制御サーバ21に対してリソース確保要求を送信する。(7)受付制御サーバ21が管理するリソースを確保すると、セッション制御サーバ31は、利用者1(発信)の端末に対して利用開始要求応答(通話開始)を返送する。このような連携により、利用者1はネットワーク11を経由して利用者2と通話することができる。
(実施例)
以下、図2により説明する。
I)セッション制御サーバと受付制御サーバの連携
受付制御サーバを例にとり説明する。ある利用者がIP電話のサービスにおいて発信したと仮定する。まず、利用者1の端末から通話開始の意思を表す呼設定開始(セットアップ)通知が発信される。呼設定開始の通知は、SIP(Session Initiation Protocol)などを使用して、セッション制御サーバ31に達する。セッション制御サーバ31では、利用者の認証や電話番号から着信者の位置の特定などの処理を行う。ネットワーク規模などにもよるが、呼設定は複数台のセッション制御サーバを経由して行われることもある。着信者側までの通話開始条件が解決されると、着信者2の端末への呼び出し信号の送出、発信者1への通話開始通知などが順次行われる。
以下、図2により説明する。
I)セッション制御サーバと受付制御サーバの連携
受付制御サーバを例にとり説明する。ある利用者がIP電話のサービスにおいて発信したと仮定する。まず、利用者1の端末から通話開始の意思を表す呼設定開始(セットアップ)通知が発信される。呼設定開始の通知は、SIP(Session Initiation Protocol)などを使用して、セッション制御サーバ31に達する。セッション制御サーバ31では、利用者の認証や電話番号から着信者の位置の特定などの処理を行う。ネットワーク規模などにもよるが、呼設定は複数台のセッション制御サーバを経由して行われることもある。着信者側までの通話開始条件が解決されると、着信者2の端末への呼び出し信号の送出、発信者1への通話開始通知などが順次行われる。
ここで、サービス品質の確保のため、帯域管理・受付制御を適用している場合には、これらの呼設定処理の途中で、受付制御サーバ21,22に対して該当通信が使用するネットワークリソースが利用可能か否かの問い合わせ、および、そのリソース確保が要求される。これが、リソース確保処理であり、受付制御サーバ21,22にとっての接続要求に該当する。
また、通信が終了したときには、セッション制御サーバ31,32に通話切断が通知される。ここで、セッション制御サーバ31,32では、課金のための切断時刻の記録が行われる。また、切断処理の中で、接続処理のときと同様に受付制御サーバ21,22にも切断通知が行われる。これは、受付制御サーバ21,22において、該当呼に対して確保しておいたネットワークリソースを解放するためであり、受付制御サーバ21,22にとっての切断要求である。
セッション制御サーバ31,32と受付制御サーバ21,22間には、この他にもサービス運用を継続するためのメッセージのやり取りが多く必要であるが、本発明は呼設定処理に関連するものであり、特に呼設定処理中の接続要求処理・切断要求処理がサーバ処理容量の大部分を占める状況での処理方式に関するものであるため、ここでは説明を省略する。
また、通信が終了したときには、セッション制御サーバ31,32に通話切断が通知される。ここで、セッション制御サーバ31,32では、課金のための切断時刻の記録が行われる。また、切断処理の中で、接続処理のときと同様に受付制御サーバ21,22にも切断通知が行われる。これは、受付制御サーバ21,22において、該当呼に対して確保しておいたネットワークリソースを解放するためであり、受付制御サーバ21,22にとっての切断要求である。
セッション制御サーバ31,32と受付制御サーバ21,22間には、この他にもサービス運用を継続するためのメッセージのやり取りが多く必要であるが、本発明は呼設定処理に関連するものであり、特に呼設定処理中の接続要求処理・切断要求処理がサーバ処理容量の大部分を占める状況での処理方式に関するものであるため、ここでは説明を省略する。
II)受付制御サーバ内の呼処理
受付制御サーバが行うべき処理は様々であるが、本発明の適用において主に論じられる高負荷状況では、その処理の殆んどが接続(リソース確保)要求処理と切断(リソース解放)要求処理に占められるため、ここではこの2つの処理について説明する。
前述のように、受付制御サーバにはセッション制御サーバから接続要求・切断要求呼が頻繁に到着する。受付制御サーバは、接続要求と切断要求に対しては異なるキューを持ち、要求呼の到着時に各キューに振り分ける。
受付制御サーバが行うべき処理は様々であるが、本発明の適用において主に論じられる高負荷状況では、その処理の殆んどが接続(リソース確保)要求処理と切断(リソース解放)要求処理に占められるため、ここではこの2つの処理について説明する。
前述のように、受付制御サーバにはセッション制御サーバから接続要求・切断要求呼が頻繁に到着する。受付制御サーバは、接続要求と切断要求に対しては異なるキューを持ち、要求呼の到着時に各キューに振り分ける。
III)スケジューリングにPQを適用する場合
PQ(プライオリティ・キューイング)は、呼処理タスクがキューからイベントを取り出す際に、キュー間で取り出し順序の優先制御を行うスケジューリングアルゴリズムである。
キューに対して優先度を付ける。接続要求キューを高優先、切断要求キューを低優先とする。呼処理タスクはある呼処理が終了した後、まず高優先の接続要求キューを確認し、イベントがあればそれを取り出して実行する。なければ、低優先の切断要求キューを確認し、イベントがあれば処理する。全てのキューにイベントがなければ、待ち状態に入り、後にイベントが発生し呼び出されるまで待機する。
PQ(プライオリティ・キューイング)は、呼処理タスクがキューからイベントを取り出す際に、キュー間で取り出し順序の優先制御を行うスケジューリングアルゴリズムである。
キューに対して優先度を付ける。接続要求キューを高優先、切断要求キューを低優先とする。呼処理タスクはある呼処理が終了した後、まず高優先の接続要求キューを確認し、イベントがあればそれを取り出して実行する。なければ、低優先の切断要求キューを確認し、イベントがあれば処理する。全てのキューにイベントがなければ、待ち状態に入り、後にイベントが発生し呼び出されるまで待機する。
IV)スケジューリングにWRRを適用する場合
WRR(ウェイテッド・ラウンドロビン)は、呼処理タスクがキューからイベントを取り出す際に、キュー間で取り出し順序の優先制御を行うスケジューリングアルゴリズムである。
キューに対して優先度を付ける。接続要求キューを高優先、切断要求キューを低優先とする。呼処理タスクは、ある呼処理が終了した後のキューの取り出しにおいて、接続要求キューと切断要求キューの取り出し頻度を差別化する。例えば、接続要求を4度取り出す(または、接続要求キューに待ちイベントがなくなる)までは切断要求キューからの取り出しを行わわず、切断要求キューからは1度の取り出しを行ったならば、接続要求キューからの取り出しに戻る、と言うような制御を行うと、接続要求処理が80%、切断要求処理が20%の割合で処理実行を差別化することができる。
WRR(ウェイテッド・ラウンドロビン)は、呼処理タスクがキューからイベントを取り出す際に、キュー間で取り出し順序の優先制御を行うスケジューリングアルゴリズムである。
キューに対して優先度を付ける。接続要求キューを高優先、切断要求キューを低優先とする。呼処理タスクは、ある呼処理が終了した後のキューの取り出しにおいて、接続要求キューと切断要求キューの取り出し頻度を差別化する。例えば、接続要求を4度取り出す(または、接続要求キューに待ちイベントがなくなる)までは切断要求キューからの取り出しを行わわず、切断要求キューからは1度の取り出しを行ったならば、接続要求キューからの取り出しに戻る、と言うような制御を行うと、接続要求処理が80%、切断要求処理が20%の割合で処理実行を差別化することができる。
V)高負荷時の接続処理応答時間の短縮(効果1)
スケジューリングにPQを適用した場合を例に説明する。
待ち行列型のシステムでは、要求呼の到着頻度がシステムの処理容量(単位時間当りの処理量)に近くなり、また、これを超えると、待ち行列中の待ちイベント数が多くなっていく。待ち行列が長いと、各イベントが処理実行開始まで待たされる時間が長くなる。
受付制御サーバに到着する接続要求呼の頻度をgとし、簡単のために接続要求呼数と切断要求呼数が等しく(すなわち、全ての接続要求に対する呼設定が成功し、接続要求と対になる切断要求が必ず存在する)、受付制御サーバ内の接続要求処理と切断要求処理の処理負荷(処理ステップ数、実行に要する時間)が等しいと仮定する。
スケジューリングにPQを適用した場合を例に説明する。
待ち行列型のシステムでは、要求呼の到着頻度がシステムの処理容量(単位時間当りの処理量)に近くなり、また、これを超えると、待ち行列中の待ちイベント数が多くなっていく。待ち行列が長いと、各イベントが処理実行開始まで待たされる時間が長くなる。
受付制御サーバに到着する接続要求呼の頻度をgとし、簡単のために接続要求呼数と切断要求呼数が等しく(すなわち、全ての接続要求に対する呼設定が成功し、接続要求と対になる切断要求が必ず存在する)、受付制御サーバ内の接続要求処理と切断要求処理の処理負荷(処理ステップ数、実行に要する時間)が等しいと仮定する。
このとき、受付制御サーバは、接続・切断を合わせてλ=2gの頻度で処理要求が到着しており、これが受付制御サーバのスループットSに達すると、システムの処理容量が飽和し、キューにおける処理待ちの発生が多くなる。受付制御サーバのプロセッサの実行制御が効率的に行われる場合、プロセッサ使用率は100%近くに達する。
ここで、本発明のように、接続・切断要求処理の実行の優先制御が行われていない場合には、呼処理タスクは両方のキューから平等にイベントを取り出すため、両方のキューにおいて同じように待ち行列が長くなり、待ち時間が延びていく。
これに対して、本発明の優先制御が適用されると、接続要求呼は優先的に実行されるため、プロセッサのリソースは接続要求呼に対して優先的に使用され、残りが切断要求呼に使用される。S<λ=2g、つまりg>S/2の場合には、接続・切断要求呼の総数に対してプロセッサの容量が不足するため、非優先の切断要求呼がリソースを使用できず、待ち行列が伸びていくことになる。
接続要求呼の頻度がさらに高まり、g>Sとなった場合には、プロセッサのリソースの全てを接続要求処理に使用しても不足が生じる。この時、初めて接続要求呼においても、待ち行列の取り出しより到着頻度が高くなり、待ち行列の伸長が発生する。
ここで、本発明のように、接続・切断要求処理の実行の優先制御が行われていない場合には、呼処理タスクは両方のキューから平等にイベントを取り出すため、両方のキューにおいて同じように待ち行列が長くなり、待ち時間が延びていく。
これに対して、本発明の優先制御が適用されると、接続要求呼は優先的に実行されるため、プロセッサのリソースは接続要求呼に対して優先的に使用され、残りが切断要求呼に使用される。S<λ=2g、つまりg>S/2の場合には、接続・切断要求呼の総数に対してプロセッサの容量が不足するため、非優先の切断要求呼がリソースを使用できず、待ち行列が伸びていくことになる。
接続要求呼の頻度がさらに高まり、g>Sとなった場合には、プロセッサのリソースの全てを接続要求処理に使用しても不足が生じる。この時、初めて接続要求呼においても、待ち行列の取り出しより到着頻度が高くなり、待ち行列の伸長が発生する。
本発明を適用しなかった場合には、前記の図3に示すように、λがSに近づくと、つまり接続要求呼の到着頻度gがS/2に近づくと接続・切断処理ともに処理待ち時間が急激に増加し、利用者に対するサービス品質が保てなくなるが、本発明を適用した場合にはgがSに達するまでは数ミリ秒の待ち時間を保ち、処理実行に要する数ミリ秒と合わせても要求条件を満たした範囲内での応答が可能となる。
図5は、本発明を適用した場合の図であって、イベントの取り出しにPQ,WRRのスケジューリングアルゴリズムを適用して、優先制御を行った場合の、計算機シミュレーションによるキュー滞在時間の評価結果のグラフである。
図5は、本発明を適用した場合の図であって、イベントの取り出しにPQ,WRRのスケジューリングアルゴリズムを適用して、優先制御を行った場合の、計算機シミュレーションによるキュー滞在時間の評価結果のグラフである。
VI)輻輳耐性の向上(効果2)
一般的には、このような要求呼の到着頻度が高まった場合の応答時間の伸長への対策として、キュー長(待ち呼数)の伸長の発生原因であるプロセッサ使用率の上昇を監視し、設定したしきい値を超えた場合に新規呼の到着を規制する輻輳制御機能を実装する。
本発明を適用しなかった場合には、プロセッサ使用率が100%に達すると応答時間が要求条件を満たせなくなるため、100%の手前にしきい値を設け、しきい値を超えたならば規制を発動する必要がある。
これに対して、本発明を適用した場合には、プロセッサ使用率が100%を超えても接続要求の応答時間は要求条件を満たすことが可能であるため、プロセッサ使用率100%以下での輻輳制御発動を行う必要はなく、輻輳に対する耐性が向上する。
一般的には、このような要求呼の到着頻度が高まった場合の応答時間の伸長への対策として、キュー長(待ち呼数)の伸長の発生原因であるプロセッサ使用率の上昇を監視し、設定したしきい値を超えた場合に新規呼の到着を規制する輻輳制御機能を実装する。
本発明を適用しなかった場合には、プロセッサ使用率が100%に達すると応答時間が要求条件を満たせなくなるため、100%の手前にしきい値を設け、しきい値を超えたならば規制を発動する必要がある。
これに対して、本発明を適用した場合には、プロセッサ使用率が100%を超えても接続要求の応答時間は要求条件を満たすことが可能であるため、プロセッサ使用率100%以下での輻輳制御発動を行う必要はなく、輻輳に対する耐性が向上する。
ただし、要求呼の到着頻度がサーバのスループットを超え、プロセッサ使用率が100%以上に達した状態が継続すると、非優先の切断要求呼のキューが伸長し、キュー長オーバー(バッファ溢れ)や未解放呼の滞留によるリソース効率の低下が発生するため、プロセッサ使用率が100%以上の状態に耐用できる継続時間には限度があり、継続時間を考慮した別の輻輳制御を導入する必要がある。
図1および図2に示す手順では、セッション制御サーバと受付制御サーバが接続され、両サーバが連携して処理を行う手順の例が示されているが、本発明では、セッション制御サーバと連携するサーバとして、受付制御サーバ以外の呼処理サーバでも適用できる。すなわち、受付制御サーバ以外にも、切断要求処理に対する対応時間が厳しくない呼処理サーバが存在する場合には、受付制御サーバに置換えてその呼処理サーバを連携サーバとしてもよい。
図2のシーケンスチャートを示す手順をプログラムに変換し、そのプログラムをCD−ROMなどの記録媒体に格納しておけば、記録媒体をセッション制御サーバや受付制御サーバのプロセッサに装着し、記録媒体からプログラムをインストールしてこれを実行させることで、本発明を容易に実現することができる。また、インターネットを介して他のプロセッサにダウンロードすることにより、このプログラムを汎用化することも可能である。
1 利用者(発信)端末
2 利用者(着信)端末
11 ネットワーク
30,31,32 セッション制御サーバ
20,21,22 受付制御サーバ
60 接続要求キュー
70 切断要求キュー
2 利用者(着信)端末
11 ネットワーク
30,31,32 セッション制御サーバ
20,21,22 受付制御サーバ
60 接続要求キュー
70 切断要求キュー
Claims (5)
- 通信サービスの利用開始時に接続要求を受信し、それに対する呼設定処理を、および、利用終了時に終了通知を受信し、それに対する終了処理を、それぞれ行うサーバの通信制御処理実行方法において、
前記サーバは、前記両処理の要求呼に対して、優先度の異なる2種類以上のキューを持ち、呼処理時のキュー取り出しにおいては接続要求処理の実行を切断要求処理の実行よりも優先して行うことを特徴とする通信制御処理実行方法。 - 請求項1に記載の通信制御処理実行方法において、
前記サーバは、キューからイベントを取り出す際に、キュー間で取り出し順の優先制御を行う場合に、PQ(プライオリティ・キューイング)、WRR(ウェイテッド・ラウンドロビン)などのスケジューリングアルゴリズムを適用し、応答時間条件の厳しい処理要求呼を優先して処理する特徴とする通信制御処理実行方法。 - 通信サービスの利用開始時に接続要求を受信し、それに対する呼設定処理を、および、利用終了時に終了通知を受信し、それに対する終了処理を、それぞれ行うシステムにおいて、
利用端末から利用開始要求を受信した際には呼設定処理、および受付制御サーバにリソース確保要求を行い、終了通知を受信した際には呼切断処理、および受付制御サーバにリソース解放要求を行うセッション制御サーバと、
ネットワークで使用するリソースを管理し、前記セッション制御サーバからリソース確保要求を受けた際にリソース確保を行い、リソース解放要求を受けた際にリソースの解放を行う受付制御サーバであって、
優先度の高い要求と優先度の低い要求に対して、呼処理バッファ内の異なる複数のキューに登録し、該キューから要求呼を取り出して、実行する際には、優先度の高い要求を優先度の低い要求より優先して取り出し、実行する受付制御サーバと、
前記セッション制御サーバに利用開始要求を行い、かつ該セッション制御サーバから着信の通知を受け取る利用者端末と
を有することを特徴とする通信制御処理システム。 - 請求項3に記載の通信制御処理システムにおいて、
前記受付制御サーバを、該受付制御サーバおよびセッション制御サーバ以外の通信制御サーバに置き換えて、同様のキュー登録処理、および優先実行処理を行わせることを特徴とした通信制御処理システム。 - 受付制御サーバの通信制御処理プログラムであって、
該受付制御サーバのプロセッサに、セッション制御サーバからリソース確保要求を受け取る手順、該リソース確保要求呼を呼処理バッファ内の優先度の高い要求呼を蓄積するキューに登録する手順、優先度の高いキューから該リソース確保要求呼を取り出し、優先的に処理する手順、該リソース確保要求呼が使用するネットワークリソースの使用状況を確認し、該リソース確保要求呼の受付可否を判定する手順、該リソース確保要求呼の受付が可能であった場合にネットワークリソースを確保する手順、受付判定結果を前記セッション制御サーバに通知する手順、前記セッション制御サーバから前記リソース確保要求呼に対応するリソース解放要求を受け取る手順、該リソース解放要求を呼処理バッファ内の優先度の低い要求呼を蓄積するキューに登録する手順、優先度の低いキューから該リソース確保要求呼を取り出し、処理する手順、該リソース確保解放呼に対応するリソース確保が求呼が使用していたネットワークリソースを解放する手順を、それぞれ実行させるための通信制御処理プログラム。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2006158067A JP2007329617A (ja) | 2006-06-07 | 2006-06-07 | 通信制御処理実行方法およびシステム、ならびにそのプログラム |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2006158067A JP2007329617A (ja) | 2006-06-07 | 2006-06-07 | 通信制御処理実行方法およびシステム、ならびにそのプログラム |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2007329617A true JP2007329617A (ja) | 2007-12-20 |
Family
ID=38929807
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2006158067A Pending JP2007329617A (ja) | 2006-06-07 | 2006-06-07 | 通信制御処理実行方法およびシステム、ならびにそのプログラム |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2007329617A (ja) |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2011191901A (ja) * | 2010-03-12 | 2011-09-29 | Oki Networks Co Ltd | 信号処理装置及びプログラム |
JP2016511904A (ja) * | 2013-02-28 | 2016-04-21 | オラクル・インターナショナル・コーポレイション | ミドルウェアマシン環境において協働的同時並行性をサポートするためのシステムおよび方法 |
CN109241066A (zh) * | 2017-07-04 | 2019-01-18 | 北京国双科技有限公司 | 请求处理方法及装置 |
WO2023238368A1 (ja) * | 2022-06-10 | 2023-12-14 | 楽天モバイル株式会社 | ネットワークリソースに対するタスクの優先度制御 |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2002158700A (ja) * | 2000-11-20 | 2002-05-31 | Nec Corp | QoSサーバ及びリソース割当て制御方法 |
JP2003283556A (ja) * | 2002-03-26 | 2003-10-03 | Hitachi Ltd | データ通信中継装置及びシステム |
-
2006
- 2006-06-07 JP JP2006158067A patent/JP2007329617A/ja active Pending
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2002158700A (ja) * | 2000-11-20 | 2002-05-31 | Nec Corp | QoSサーバ及びリソース割当て制御方法 |
JP2003283556A (ja) * | 2002-03-26 | 2003-10-03 | Hitachi Ltd | データ通信中継装置及びシステム |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2011191901A (ja) * | 2010-03-12 | 2011-09-29 | Oki Networks Co Ltd | 信号処理装置及びプログラム |
JP2016511904A (ja) * | 2013-02-28 | 2016-04-21 | オラクル・インターナショナル・コーポレイション | ミドルウェアマシン環境において協働的同時並行性をサポートするためのシステムおよび方法 |
CN109241066A (zh) * | 2017-07-04 | 2019-01-18 | 北京国双科技有限公司 | 请求处理方法及装置 |
WO2023238368A1 (ja) * | 2022-06-10 | 2023-12-14 | 楽天モバイル株式会社 | ネットワークリソースに対するタスクの優先度制御 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7706385B2 (en) | Bandwidth management system and method for guaranteeing quality of service in voice over internet protocol network | |
US7420962B2 (en) | Method for management of voice-over IP communications of various relative priority levels | |
KR100881925B1 (ko) | 이동통신 기지국 시스템에서 하향 음성 패킷망 패킷스케줄링 장치 및 방법 | |
EP1989843B1 (en) | System and method for prioritizing session initiation protocol messages | |
CA2302218C (en) | Packet network | |
US7701854B2 (en) | Differentiated handling of SIP messages for VoIP call control | |
JP4881887B2 (ja) | トラフィックシェーピング機能および装置 | |
US8144588B1 (en) | Scalable resource management in distributed environment | |
US20130016611A1 (en) | Method and apparatus for prioritizing voice over internet protocol signaling messages | |
WO2009124991A1 (en) | Calculating packet delay in a multihop ethernet network | |
JP6982250B2 (ja) | パケット転送装置、方法、及びプログラム | |
CN1643858B (zh) | 服务质量请求关联 | |
JP2007329617A (ja) | 通信制御処理実行方法およびシステム、ならびにそのプログラム | |
WO2000056023A1 (en) | Methods and arrangements for policing and forwarding data in a data communications system | |
CN101471869B (zh) | 会话处理方法、系统和装置 | |
Islam et al. | A comparative analysis of different real time applications over various queuing techniques | |
CN111638986A (zh) | 一种QoS队列调度方法、装置、系统及可读存储介质 | |
Domżał | Intelligent routing in congested approximate flow-aware networks | |
Domżał et al. | Efficient congestion control mechanism for flow‐aware networks | |
US20070280685A1 (en) | Method of Optimising Connection Set-Up Times Between Nodes in a Centrally Controlled Network | |
JP2005333417A (ja) | Ip電話端末装置、ip電話用仲介サーバ、ip電話システム、制御方法及びプログラム | |
Domżał et al. | Click-based tests of QoS mechanisms for flow-based router | |
Zhang | On overload control of parlay application server in next generation network | |
WO2024187376A1 (en) | Network device for packet switching in accordance with a bounded end-to-end delay, and method of operating the same | |
JP5587249B2 (ja) | 情報管理方法、輻輳制御方法および輻輳制御装置 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20080725 |
|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20100604 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20100615 |
|
A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20101015 |