JP2794740B2

JP2794740B2 - 網内リソース管理方法

Info

Publication number: JP2794740B2
Application number: JP562189A
Authority: JP
Inventors: 清広野口; 廣一大西; 忠信岡田
Original assignee: Nippon Telegraph and Telephone Corp
Current assignee: Nippon Telegraph and Telephone Corp
Priority date: 1989-01-12
Filing date: 1989-01-12
Publication date: 1998-09-10
Anticipated expiration: 2013-09-10
Also published as: JPH02185134A

Description

【発明の詳細な説明】〔産業上の利用分野〕本発明は、低速から高速までの種々の通信速度で、時
間的変動を伴うバーストトラヒックに対して、ユーザか
らの実時間通信や高信頼度通信等の種々の通信品質を同
時に満足させることが可能で、かつ網内リソースを効率
よく運用させることが可能な網内リソース管理方法に関
する。

〔従来の技術〕

従来より、固定ルート上でパケット形式により通信を
行う方式としては、例えば、『スタティスティカル、ス
イッチング、アーキテクチャーズ、フォー、フューチャ
ー、サービセス』（Kultzor,Montgomery:Statistical I
SS′84,May1984）に記載された高速パケット交換方式が
ある。上記高速パケット交換方式においては、呼設定の
流量制御論理として、呼設定時に発加入者にその呼の最
大スループットを宣言させ、ルーチングはこの宣言値に
より行っている。なお、ここで、スループットとは、単
位時間当りのパケット転送箇所を言い、スロット型の場
合には、スロットの箇数を言う。

パケット通信網においては、交換機や多重化装置、お
よびクロスコネクト等のノードと、これらのノードおよ
びユーザ端末を接続する伝送路等のリンクにより構成さ
れ、該リンクおよびバッファ等の網内リソースを共用す
る。また、パケット通信網では、これらの網内リソース
を共用して、トラヒック間の統計的多重を行い、さらに
は、エンドツーエンド遅延品質、廃棄品質等の通信品質
を確率的に保証する。通常、トラヒック属性パラメータ
および通信品質を表わすサービスクラスの値が規定され
ており、ユーザは、通信要求を行う呼、または回線のト
ラヒック属性、および通信品質に応じて、そのトラヒッ
ク属性パラメータ値、およびサービスクラス値を決定し
て、呼または回線の設定要求時にそれらの値を網に対し
て申告する。

〔発明が解決しようとする課題〕

第５図（ａ）（ｂ）は、それぞれ従来の網内リソース
管理方法の処理フローチャートであって、第５図（ａ）
は、高信頼度通信のために開発され、データ通信を対象
とするパケット交換方式（X.25）における網内リソース
管理方法、第５図（ｂ）は、64Kb/sを基本とする一定速
度通信を前提にした回線交換方式における網内リソース
管理方法である。

第５図（ａ）においては、ユーザから呼接続要求があ
ると（ステップ１）、呼設定フェーズ（２）で呼設定処
理（ステップ21）を行って後、次の情報転送フェーズ
（３）に移り、ウィンドウフロー制御（ステップ31）を
行う。ウィンドウフロー制御は、受信側のバッファの大
きさに応じて連続して受信できるパケット数（ウィンド
ウサイズ）により、送受信を制御する方法である。

数百ミリ秒程度の遅延時間を許容するパケット交換方
式では、情報転送フェーズにおいて、トラヒック負荷が
増大した場合には、遅延させることにより網内リソース
の有効利用を行っていた。すなわち、具体的には、ウィ
ンドウフロー制御によりトラヒック負荷の時間的な均衡
化を図り、その結果、網内リソースの有効利用を図るこ
とができた。このパケット交換方式では、呼設定フェー
ズにおける呼レベルでのトラヒック管理、例えばトラヒ
ック状況の管理による呼接続の受付判断等の機能の導入
は行っていなかった。

次に、第５図（ｂ）において、呼接続要求があると
（ステップ１）、呼設定フェーズ（２）で同時接続数等
の管理（ステップ24）を行うことにより、呼の受付け判
断を行い（ステップ23）、管理されたものについて呼接
続処理（ステップ21）を行い、拒否されたものについて
は呼損（22）となっていた。呼接続処理（ステップ21）
が行われたものについて、情報転送フェーズ（３）では
フロー制御を行わず、ノーアクションであった。

このように、呼設定フェーズ（２）においては、同時
接続呼数の管理を行っており、特に過負荷における網内
リソース管理を実現してきた。このようなパケット交換
方式では、情報転送フェーズでのトラヒック管理機能は
不要であった。

低速から高速までの時間的な変動を伴うトラヒックを
同時に収容し、さらには、実時間通信要求、高信頼度通
信要求等の種々の通信品質を同時に満足させることを前
提とする通信網が提案されているが、未だに具体的な網
内リソース管理方法については考えられていない。CCIT
T SGXVIII 1.121において、網における網内リソース
管理方法の大枠の規定があるだけである。具体的には、
ユーザがバーストトラヒック属性および要求品質クラス
を申告することにより、網はその値を基にして網内リソ
ース管理を実現する必要があることが規定されているの
みである。その他の具体的な規定、さらに具体的な網内
リソースの管理方法については未だ規定されていない。

本発明の目的は、このような従来の課題を解決し、マ
ルチメディア統合網、例えばATM交換機において、低速
から高速までの種々の通信速度を持ち、時間的な変動を
伴うバーストトラヒックに対して、ユーザからの実時間
通信、高信頼度通信等の種々の通信品質の要求を同時に
満足させることが可能であり、かつ網内リソースを効率
的に運用することが可能な網内リソース管理方法を提供
することにある。

〔課題を解決するための手段〕

上記目的を達成するため、本発明の網内リソース管理
方法は、交換機、多重化装置およびクロスコネクトを含
むノードと、該ノードおよびユーザ端末を結合する伝送
路を含むリンクにより構成され、該リンクおよびバッフ
ァ等の網内リソースを共用し、呼接続ないし回線設定要
求時に、ユーザが申告するトラヒック属性値および通信
品質を表わすサービスクラス、ならびに網内リソース使
用状況に基づいて、各ノードが必要となるリソース量を
導出するパケット通信網において、該呼ないし回線をユ
ーザが申告したトラヒック属性値とリンク容量から導か
れる値で決まるクラス１およびクラス２に分離し、各ノ
ードは、呼接続ないし回線設定要求時にユーザが申告す
るトラヒック属性値、サービスクラス、および上記呼な
いし回線の接続要求時点での網内使用リソース量をリン
ク容量より減算して得られる空きリソース量を基に、上
記呼ないし回線の要求トラヒック属性と要求品質を満足
させるために必要なリソース量を導入し、該必要リソー
ス量が空きリソース量よりも大きい場合には上記呼を呼
損とし、該必要リソース量が空きリソース量より小さい
場合には、先ず上記接続要求呼ないし回線がクラス１か
クラス２のどちらに属するかを、伝送路容量とユーザが
申告したトラヒック属性値により決定し、上記呼ないし
回線がクラス１の場合には呼接続処理ないし回線設定処
理に移行し、上記呼ないし回線がクラス２の場合には、
リンク容量に対して該呼ないし回線の要求品質が満足さ
せるために必要なリソース量を導入し、該リソース量を
割り当てリソース量として、ノードが上記割り当てリソ
ース量を上記呼ないし回線用のリソースとして割り当
て、呼接続処理ないし回線設定処理に移行し、上記呼か
呼切断要求を行うか、上記回線が回線切断処理を行うま
で、上記割り当てリソース量を該呼ないし回線用として
割り当てておくことに特徴がある。

〔作用〕

本発明においては、種々の通信品質や通信速度を要求
する通信メディアを効率的に収容できるマルチメディア
統合網、例えばATM交換網において、通信中の全呼の各
々の通信品質を良好に保持し、かつ交換機リソースを有
効に運用することができるようにする。すなわち、本発
明の網内リソース管理方法では、ユーザが申告するトラ
ヒック属性を基にして網内リソース管理クラスに分離
し、クラス１呼のトラヒック量を観測するとともに、ク
ラス２呼の要求通信品質を満足できるだけの割り当て容
量を管理し、また要求呼に対して品質が満足できるだけ
の容量が確保できるか否かを判断し、呼接続を受け付け
るか否かを判定する。呼接続を受理できる場合のクラス
２呼の必要帯域の確定的な割り当て機能を持つ。

請求項１は本発明の第１の実施例に、請求項２は第２
の実施例に、請求項３は第３の実施例に、請求項４は第
４の実施例に、また請求項５は第５の実施例に、それぞ
れ対応している。

本発明を要約すると、（ｉ）制御クラスとして、統計
的な多重化効果が大きく期待できるクラス１と、多重化
効果が余り期待できないクラス２とを導入し、これらの
クラス対応のリソース管理を行う。（ii）クラス１に属
する呼のリソース管理は、観測値を基に行う。（iii）
クラス２に属する呼のリソース管理、その呼が要求する
通信品質を満足できるだけのリソース量を導入し、その
量を基に行う。（iv）ユーザが要求する通信品質を満足
させることができ、かつリソースの使用効率の向上を図
ることが可能な呼受付判定機能を設ける。

これにより、（イ）伝送路容量、バッファ容量等の網
内リソースを有効に利用することができる。（ロ）網
は、ユーザが要求する種々の通信品質を同時に保証する
ことができる。（ハ）本発明者が提案したが、本発明と
は別出願である『網内リソース制御パラメータ』、『網
内リソース割り当て方法』、および『モニタリング方
式』を本発明と組み合わせることにより、この効果をさ
らに向上させることが可能である。

〔実施例〕

以下、本発明の実施例を、図面により詳細に説明す
る。

第１図（ａ）は、本発明の第１の実施例を示す網内リ
ソース管理方法の処理フローチャートである。

本発明の網内リソース管理方法では、呼または回線を
ユーザが申告したトラヒック属性値とリンク容量とから
導かれる値で決まるクラス１とクラス２に分離する。そ
して、呼接続ないし回線設定要求時点でのクラス１呼の
使用リソース量を、上記時点で同時接続されているクラ
ス１の呼および回線のトラヒック量と定義し、呼接続な
いし回線設定要求点でのクラス２呼の使用リソース量
を、上記時点で同時接続されているクラス２の呼および
回線に対して、それぞれの設定時に決定された割り当て
リソース量の合計量と定義し、呼接続ないし回線設定時
点での上記クラス１呼の使用リソース量とクラス２呼の
使用リソース量の加算値を、上記時点での網内使用リソ
ース量と定義する。

また、本実施例のリソース管理プログラムは、次のサ
ブルーチンプログラムから構成される。すなわち、ユー
ザの申告値を呼接続要求時点での空きリソース量より、
呼受付判定基準値を導出するサブルーチン25、上記基準
値と網内リソース使用状況により、呼接続要求に対する
受理判断を行うサブルーチン23、クラス１または２領域
を判定するサブルーチン26、割り当てるべき網内リソー
ス量を伝送路容量を基準として決定するサブルーチン2
7、割り当てるべき網内リソース量を、呼接続時点での
空きリソース量を基準として決定するサブルーチン29、
および割り当てられた網内リソース量を管理するサブル
ーチン28である。

第１図（ａ）において、交換機は呼接続要求を受ける
と（ステップ１）、呼設定フェーズ（２）で、先ずユー
ザ申告パラメータ値を基に、ステップ23で行う接続要求
の受付可否判断を行うために必要となる基準値を導出す
る（ステップ25）。なお、基準値の導出方法について
は、前述の『網内リソース管理パラメータ』（別途出願
中）を参照されたい）。具体的には、呼接続要求受信時
における空きリソース量に対して、要求呼を含む同時接
続呼の要求品質を同時に満足させるために必要となる要
求呼に対する必要リソース量を導出する。なお、必要リ
ソース量の導出方法については、前述の『網内リソース
割り当て方法』（本願と同日に出願）を参照されたい。
この必要リソース量が、呼接続時点での空きリソース量
より大きい場合には、呼損とする（ステップ22）。一
方、必要リソース量が空きリソース量より小さい場合に
は、呼接続要求を受理して、以下の処理手順に従って実
行する（ステップ23）。

すなわち、呼接続要求呼が上記ユーザ申告値を基に統
計的な多重化効果が十分に期待できるクラス１領域呼
か、あるいは統計的な多重化効果が期待できないクラス
２領域呼であるかを判断する（ステップ26）。判断の結
果、接続要求呼がクラス１領域呼である場合、呼設定処
理を実行し（ステップ21）、情報転送フェーズ（３）に
移行する。一方、呼がクラス２領域呼である場合には、
伝送路容量に対して、接続要求呼の品質を満足できるだ
けの網内リソース量を導出し、その量をその接続要求呼
の網内リソースとして割り当てる（ステップ27）。各ノ
ードは、呼が呼切断要求を行うまで、または回線が回線
切断処理を行うまで、割り当てリソース量を呼または回
線用として割り当てておく。なお、品質を満足できるだ
けの網内リソース量を導出する方法は、別途出願中の前
記『網内リソース割り当て方法』を参照されたい。ま
た、割り当て状況およびクラス１呼のトラヒック観測値
は、網内リソース管理サブルーチン（28）により管理さ
れている。このリソース管理サブルーチン28では、情報
転送フェーズ（３）のクラス１領域呼に対する網内リソ
ース使用状況の観測プログラム32におけるトラヒック観
測値を常時管理している。本実施例では、以上の動作を
各交換機毎に独立して行う。

第１図（ｂ）は、本発明の第２の実施例を示す網内リ
ソース管理方法の処理フローチャートである。

第１図（ｂ）では、（ａ）の網内リソース割り当て処
理ステップ27について、各交換が管理するクラス２呼に
対する割り当てリソース量を、伝送路容量に対してでは
なく、呼接続要求時点での空きリソース量に対して、接
続要求呼の要求品質を保証できるだけの容量としている
（ステップ29）。すなわち、各ノードは、クラス２に属
する呼または回線に対する割り当てリソース量を、呼受
付判定基準値つまり必要リソース量と同じ値にしてい
る。これ以外の処理は、全て第１の実施例と同じであ
る。

第１図（ｃ）は、本発明の第３および第４の実施例を
示す網内リソース管理方法の処理フローチャートであ
る。また、第２図（ａ）は、第３の実施例における割り
当てリソース量の更新アルゴリズムを示す図である。

第３の実施例では、網内リソース管理プログラム28に
関して、各交換機が管理するクラス２呼に対する割り当
てリソース量を呼接続要求時点毎に、または一定周期毎
のいずれかの時点系列における各々の時点での同時接続
呼に対して、使用可能リソース量Ｖという概念を導入す
る。先ず、第２図（ａ）に示すように、この使用可能リ
ソース量Ｖ値を伝送路容量V₀と定義し（ステップ10
1）、ユーザが申告したトラヒック属性値の最も大きな
呼、例えば申告ピークスループット値の最も大きな呼に
注目して（ｉ＝1,i≦Ｎ）（ステップ102）、このＶ値に
対して呼の要求品質を満足させるために必要な割り当て
リソース量R_iを決定する（ステップ103）。次に、その
リソース量R_iをＶ値より減算した値を新たなＶ値とし
（ステップ104）、次にユーザが申告したトラヒック属
性値の２番目に大きな呼に注目して（ステップ105,10
2）、このＶ値に対して呼の要求品質を満足させるため
に必要な割り当てリソース量を決定する（ステップ10
3）。再び、そのリソース量R_iをＶ値より減算した値を
新たなＶ値とし、以下、割り当てリソース量更新周期時
点での同時接続呼の全てに対して、同じ処理を返す。交
換機は、各呼に対して決定した割り当てリソース量を新
たな割り当てリソース量として更新・管理する。

このように、更新時点毎に、その時点での要求スルー
プット値の大きな呼、例えば要求ピークスループット値
の大きな呼から順番に、割り当てリソース量を決定し直
して行く。この処理を、簡単な例で説明する。いま、更
新時点での同時接続呼数が５であった場合、この中で要
求スループット値の最も大きな呼、例えば要求ピークス
ループット値が最も大きな呼C₁に注目する。そして、先
ず使用可能リソース量Ｖ（＝V₀）に対して、その呼C₁の
品質を満足させるために必要な割り当てリソース量R₁を
決定し、Ｖ＝Ｖ−R₁とする。次に、２番目に大きな要求
スループット値を有する呼C₂に注目して、このＶ値に対
して呼C₂の品質を満足させるために必要な割り当てリソ
ース量R₂を決定し、Ｖ＝Ｖ−R₂とする。次に、３番目に
大きな要求スループット値を有する呼C₃に注目して、そ
のＶ値に対してその呼C₃の品質を満足させるために必要
な割り当てリソース量R₃を決定し、Ｖ＝Ｖ−R₃とする。
残りの２呼に対しても、同じような処理を実行して、そ
れらの処理で決定された値R₁〜R₅値を各々の呼に対する
割り当てリソース量として、交換機が管理するのであ
る。

第１図（ｃ）および第２図（ｂ）は、本発明の第４の
実施例を示す網内リソース管理方法の処理フローチャー
トである。

第４の実施例では、第３の実施例のように、使用可能
リソース量Ｖの更新を各呼毎に行うのではなく、同一ス
ループット特性を有するスループットクラス毎に更新を
行う。この更新アルゴリズムを、第２図（ｂ）に示す。
すなわち、割り当てリソース量R_iを決定した後（ステッ
プ203）、R_j＝R_j＋R_iとし（ステップ204）、次のスルー
プットクラスでなければ、Ｖは前の値のままでｉのみを
１だけインクリメントして再び必要なリソース量R_iを決
定する（ステップ203）。なお、次のスループットクラ
スであれば、Ｖ＝Ｖ−R_jとし、ｊを１だけインクリメン
トし、R_i＝０とする（ステップ206）。

第１図（ｃ）および第２図（ａ）（ｂ）は、本発明の
第５の実施例を示す網内リソース管理方法の処理フロー
チャートでもある。

第５の実施例では、第３または第４の実施例におい
て、呼受付け判断を以下に示す手順により実行する。

接続要求呼または回線がクラス１の場合には、その呼
または回線の接続要求時点での『呼受付判定基準量』が
『空きリソース量』より小さいとき呼接続要求を受理し
（ステップ26,21）、またそうでない場合には呼損とす
る（ステップ22）。

一方、接続要求呼または回線がクラス２の場合には、
その接続要求呼または回線を含むクラス２の呼または回
線に対して、『割当リソース量』を更新し、そのリソー
ス量の同時接続クラス２呼または回線の加算値である
『クラス２呼の使用リソース量』と『クラス１呼の使用
リソース量』の加算値が網内リソース量より小さいとき
には、呼接続要求を受理し（ステップ21）、そうでない
場合には呼損とする（ステップ22）。

第３図（ａ）は、本発明の第６の実施例を示す網内リ
ソース管理方法の処理フローチャートである。

第６の実施例では、第１図（ａ）に示す第１の実施例
において、全呼を、統計的な多重化効果が十分に期待で
きないクラス２として扱った場合である。第３図（ａ）
に示すように、先ずユーザの申告値を基に呼接続要求時
点での空きリソース量より、呼受付判定基準値を導出す
る（ステップ25）。次に、要求リソース量が呼接続時点
での空きリソース量により大きい場合には呼損とする
（ステップ23,22）。一方、要求リソース量が空きリソ
ース量より小さい場合には、呼接続要求を受け付けて、
全ての呼が多重化効果が期待できないクラス２であるた
め、網内リソースの割り当て処理を行い（ステップ2
7）、呼接続処理を行う（ステップ21）。そして、情報
転送フェーズ（３）で各種情報転送処理を行う（ステッ
プ33）。

すなわち、この実施例では、交換処理能力および伝送
路容量が、端末が要求するスループット値に対して十分
に大きくできない場合や、専用網的な使用を行う場合等
において適用すれば、特に効果が大である。

第３図（ｂ）は、本発明の第７の実施例を示す網内リ
ソース管理方法の処理フローチャートである。

第３図（ｂ）の実施例で、第３図（ａ）と異なる点
は、各ノードが、クラス１に属する呼または回線に対す
る割り当てリソース量を、呼受付判定基準値と同じ値に
している点である。それ以外は、全く同じ処理となる。

先ず、呼対応の割り当て量を導入し（ステップ25）、
次に、要求リソース量が呼接続時点での空きリソース量
より大きい場合には呼損とする（ステップ23,22）。一
方、要求リソース量が空きリソース量より場合には、呼
接続要求を受け付けて、全ての呼が多重化効果が期待で
きないクラス２であるため、網内リソースの割り当て処
理を行い（ステップ27）、呼接続処理を行う（ステップ
21）。そして、情報転送フェーズ（３）で各種情報処理
を行う（ステップ33）。網内リソース管理の処理（ステ
ップ28）も、第３図（ａ）と同じである。

第３図（ｃ）は、本発明の第８の実施例を示す網内リ
ソース管理方法の処理フローチャートである。

この実施例においては、網内リソース管理プログラム
28に関して、各交換機が管理するクラス２呼に対する割
り当てリソース量を呼接続要求時点毎に、また一定周期
毎のいずれかの時点系列における各々の時点での同時接
続呼に対して、使用可能リソース量Ｖという概念を導入
する。例えば、更新時点毎に、その時点での要求スルー
プット値の大きな呼、例えば要求ピークスループット値
の大きな呼から順番に、割り当てリソース量を決定し直
して行く。

次に、本発明の第９の実施例を説明する。この実施例
は、第１図（ｃ）および第２図（ａ）（ｂ）を基した第
５の実施例の応用となる網内リソース管理方法である。

第９の実施例では、第３または第４の実施例におい
て、呼受付け判断を以下に示す手順により実行する。

接続要求呼または回線の全呼を、クラス２として扱っ
た場合である。その接続要求呼または回線を含むクラス
２の呼または回線に対して、『割当リソース量』を更新
し、そのリソース量の同時接続クラス２呼または回線の
加算値である『クラス２呼の使用リソース量』が網内リ
ソース量より小さいときには、呼接続要求を受理し、そ
うでない場合には呼損とする。

第４図は、本発明の第10の実施例を示す網内リソース
管理方法である。

第10実施例は、第１の実施例において、全呼を統計的
な多重効果が十分に期待できるクラス１として扱った場
合の実施例である。

第４図において、交換機は呼接続要求を受けると（ス
テップ１）、呼設定フェーズ（２）で、先ずユーザ申告
パラメータ値を基に、ステップ23で行う接続要求の受付
可否判断を行うために必要となる基準値を導出する（ス
テップ25）。具体的には、呼接続要求受信時における空
きリソース量に対して、要求呼を含む同時接続呼の要求
品質を同時に満足させるために必要となる要求呼に対す
る必要リソース量を導出する。この必要リソース量が、
呼接続時点での空きリソース量より大きい場合には、呼
損とする（ステップ22）。一方、必要リソース量が空き
リソース量より小さい場合には、呼接続要求を受理する
（ステップ23）。

次に、呼接続要求呼は全て上記ユーザ申告値を基に統
計的な多重化効果が十分に期待できるクラス１領域呼で
あるため、受理された呼接続要求は、呼設定処理を実行
し（ステップ21）、情報転送フェーズ（３）に移行す
る。また、割り当て状況およびクラス１呼のトラヒック
観測値は、網内リソース管理サブルーチン（28）により
管理されている。このリソース管理サブルーチン28で
は、情報転送フェーズ（３）のクラス１領域呼に対する
網内リソース使用状況の観測プログラム32におけるトラ
ヒック観測値を常時管理している。

この実施例では、交換機処理能力および伝送路容量
が、端末が要求するスループットに対して十分に大きな
場合、あるいは入力トラヒッ特に規制を加える場合、例
えば、端末が要求するピークスループット値を伝送路容
量の数％程度に規制する場合、公衆網的な運用を行う場
合等に適用すれば、特にその効果が大である。また、本
実施例の場合には、複雑な制御を行う必要がなく、簡単
な方法で実現可能である。

〔発明の効果〕

以上説明したように、本発明によれば、種々の属性を
持つバーストトラヒックに対して、伝送路容量やバッフ
ァ容量等の網内リソースを有効に利用することができ、
かつ網は、ユーザからの種々の要求品質を同時に保証す
ることが可能である。

【図面の簡単な説明】

第１図は本発明の第１〜第４の実施例を示す網内リソー
ス管理方法の処理フローチャート、第２図は第３および
第４の実施例における割り当てリソース量の更新アルゴ
リズムを示すフローチャート、第３図は本発明の第６〜
第８の実施例を示す網内リソース管理方法の処理フロー
チャート、第４図は本発明の第10の実施例を示す網内リ
ソース管理方法の処理フローチャート、第５図は従来の
パケット交換方式および回線交換方式の網内リソース管
理方法の処理フローチャートである。 1:呼接続要求ブロック、2:呼設定フロー制御ブロック、
3:情報転送フェーズブロック、21:呼設定処理、22:呼損
処理、23:呼受付判断処理、24:同時接続呼数の管理、2
5:呼受付判定基準値の導出処理、26:クラス1/2領域識別
処理、27:要求品質を保証できるだけの網内リソース割
り当て量を伝送路容量を基準値として導出する処理、2
8:網内リソース管理、29:リソース割り当て比率より導
出する処理、31:ウインドウフロー制御処理、32:クラス
１領域呼に対する網内リソース使用状況の観測処理、3
3:各種情報転送フェーズ。

───────────────────────────────────────────────────── フロントページの続き (56)参考文献特開昭63−38345（ＪＰ，Ａ) 特開平２−171061（ＪＰ，Ａ) 特開平２−222339（ＪＰ，Ａ) 特開平２−250451（ＪＰ，Ａ) 電子情報通信学会技術研究報告，ＩＮ 86−65（1986−８−25），Ｐ67−72 電子情報通信学会技術研究報告，ＳＥ 87−74（1987−８−21），Ｐ１−６電子情報通信学会技術研究報告，ＳＳＥ89−69（1989−９−20），Ｐ７−12 (58)調査した分野(Int.Cl.⁶，ＤＢ名) H04L 12/28 H04L 12/56

Claims

(57)【特許請求の範囲】

【請求項１】交換機、多重化装置およびクロスコネクト
を含むノードと、該ノードおよびユーザ端末を結合する
伝送路を含むリンクにより構成され、該リンクおよびバ
ッファを含む網内リソースを共用し、呼接続ないし回線
設定要求時に、ユーザが申告するトラヒック属性値およ
び通信品質を表わすサービスクラス、ならびに網内リソ
ース使用状況に基づいて、各ノードが必要となるリソー
ス量を導出するパケット通信網において、該呼ないし回
線をユーザが申告したトラヒック属性値とリンク容量か
ら導かれる値で決まるクラス１およびクラス２に分離
し、各ノードは、呼接続ないし回線設定要求時にユーザ
が申告するクラヒック属性値、サービスクラス、および
上記呼ないし回線の接続要求時点での網内使用リソース
量をリンク容量より減算して得られる空きリソース量を
基に、上記呼ないし回線の要求トラック属性と要求品質
を満足させるために必要なリソース量を導出し、該必要
リソース量が空きリソース量よりも大きい場合には上記
呼を呼損とし、該必要リソース量が空きリソース量より
小さい場合には、先ず上記接続要求呼ないし回線がクラ
ス１かクラス２のどちらかに属するかを、伝送路容量と
ユーザが申告したトラヒック属性値により決定し、上記
呼ないし回線がクラス１の場合には呼接続処理ないし回
線設定処理に移行し、上記呼ないし回線がクラス２の場
合には、リンク容量に対して該呼ないし回線の要求品質
を満足させるために必要なリソース量を導出し、該リソ
ース量を割り当てリソース量として、ノードが上記割り
当てリソース量を上記呼ないし回線用のリソースとして
割り当て、呼接続処理ないし回線設定処理に移行し、上
記呼が呼切断要求を行うか、上記回線が回線切断処理を
行うまで、上記割り当てリソース量を該呼ないし回線用
として割り当てておくことを特徴とする網内リソース管
理方法。
【請求項２】請求項１記載の網内リソース管理方法にお
いて、各ノードは、クラス２に属する呼ないし回線に対
する割り当てリソース量を、前記必要リソース量と同じ
値にすることを特徴とする網内リソース管理方法。
【請求項３】請求項１または２記載の網内リソース管理
方法において、各ノードは、クラス２に属する呼ないし
回線の割り当てリソース量を、呼ないし回線設定時に決
定した後、該リソース量の割り当てを呼切断時まで継続
させず、使用可能リソース量Ｖを導入して、該Ｖの初期
値をリンク容量V₀とし、呼ないし回線接続要求時点ごと
か、予め定めた周期ごとに、該時点ごとの同時接続呼な
いし同時接続回線に対して、ユーザが申告したトラヒッ
ク属性値の最も大きな呼ないし回線に注目して、上記V₀
値に対して該呼ないし回線の要求品質を満足させるため
に必要な割り当てリソース量を決定し、該値を該呼ない
し回線の割り当てリソース量の更新値とし、さらに該値
をＶ値より減算した値を新たなＶ値とし、次にユーザが
申告したトラヒック属性値の２番目に大きな呼ないし回
線に注目して、該Ｖ値に対して該呼ないし回線の要求品
質を満足させるために必要な割り当てリソース量を決定
して、該値を該呼ないし回線の割り当てリソース量の更
新値とし、さらに該値をＶ値より減算した値を新たなＶ
値とし、以下、該時点までのクラス２の同時接続呼ない
し同時接続回線の全てに対して同じ処理を繰り返すこと
により、全ての割り当てリソース量を更新し、各ノード
は更新されたクラス２の呼ないし回線の割り当てリソー
ス量を用いて制御することを特徴とする網内リソース管
理方法。
【請求項４】請求項３記載の網内リソース管理方法にお
いて、ユーザが申告するトラヒック属性に複数のクラス
に分離されたスループットクラスの概念を導入し、クラ
ス２の呼ないし回線ごとに前記使用可能リソース量Ｖを
更新することなく、上記スループットクラスごとに該使
用可能リソース量Ｖを更新することを特徴とする網内リ
ソース管理方法。
【請求項５】請求項３または４記載の網内リソース管理
方法において、接続要求呼ないし回線がクラス１の場合
には、該呼ないし回線の接続要求時点での必要リソース
量が空きリソース量より小さいとき、呼接続要求を受理
し、必要リソース量が空きリソース量より大きいとき呼
損とし、接続要求呼ないし回線がクラス２の場合には、
該接続要求呼ないし回線を含むクラス２の呼ないし回線
に対して、割り当てリソース量を更新し、該割り当てリ
ソース量の同時接続クラス２呼ないし回線の加算値であ
るクラス２呼の使用リソース量とクラス１呼の使用リソ
ース量の加算値が網内リソース量より小さい場合には、
呼接続要求を受理し、網内リソース量より大きい場合に
は呼損とすることを特徴とする網内リソース管理方法。