JP2004241835A

JP2004241835A - 品質保証型データストリームを転送するための受付判定方法、閉域ｉｐ網、そのプログラム

Info

Publication number: JP2004241835A
Application number: JP2003026276A
Authority: JP
Inventors: Masaji Takano; 正次高野
Original assignee: Nippon Telegraph and Telephone Corp
Current assignee: Nippon Telegraph and Telephone Corp
Priority date: 2003-02-03
Filing date: 2003-02-03
Publication date: 2004-08-26

Abstract

【課題】リーキーバケットモデルにより表現できるデータストリームのパケット損失をゼロとする簡易な受付判定を実現する。
【解決手段】受付判定サーバ１００１はサービス要求リクエストが受信すると、サービスに対応するサービス別サーバに問い合わせて、サービス内容情報を取得する。ストリーム特性ＤＢ３００１に問い合わせて、トラヒック特性情報を取得する。網構成ＤＢ２００１に問い合わせて、転送ルート情報を取得する。トラヒックＤＢ２００２に問い合わせて、提供中サービス情報を取得する。バースト継続時間と基準バースト継続限界時間にもとづき転送ルート上の各リンクについて、そのリンク速度をもとに品質保証型サービス向けに割り当てる速度の最大値を計算し、要求されているサービスの受付判定を行なう。
【選択図】図２

Description

【０００１】
【発明の属する技術分野】
本発明は、ＩＰ網上での周期的なバースト性を有するデータストリームの転送において、サービス品質を保証するための受付判定の技術に関する。
【０００２】
【従来の技術】
近年、インターネットの利用が普及し、さまざまな通信サービスが大規模で公衆的なＩＰ網において提供されることが期待されている。一般に、これらの通信サービスの多くはデータストリームの転送に帰着されるが、現在特に期待されている通信サービスは、高品質の映像によるＶＯＤ（ＶｉｄｅｏＯｎＤｅｍａｎｄ）サービスなどに代表されるように、そのトラヒックが転送されるデータ量のボリュームが単に大きいだけでなく、データストリームがバースト性などの多様で複雑なトラヒック特性を有する。しかも、そのサービスに要求される品質（サービス品質）は非常に厳しいものである。具体的には、サービス品質はそのサービス毎に、パケット損失率、遅延時間の最大値、遅延時間分布のゆらぎなどの多様な通信品質のパラメータによって表現され、それぞれの目標値が規定される。サービスに対する課金を行うためには、そのサービス品質の達成が厳しく求められる。特に、確認応答（ＡＣＫ：Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）を行わないＵＤＰ（ＵｓｅｒＤａｔａｇｒａｍＰｒｏｔｏｃｏｌ）プロトコルによる転送の場合には、転送中に損失となったパケットの再転送を行うことができない。そこで、ユーザのサービス要求メッセージが到着したときに、網の帯域などのリソースと既に受付済みで提供中のサービスを総合的に判断して、いま到着したユーザ要求に対する適切な受付可否判定と、受付けたユーザ要求へのサービス品質を満足したデータストリーム転送を確実に行うための仕組みが要求される。
【０００３】
通信サービスにおけるサービス品質を保証あるいは達成させるための技術の現状は、以下のようなものである。
【０００４】
（ＡＴＭの場合）
ＡＴＭ（ＡｓｙｎｃｈｒｏｎｏｕｓＴｒａｎｓｆｅｒＭｏｄｅ：非同期転送モード）が、複雑なトラヒック特性を有する通信に対してサービス品質を保証するために標準化された技術であることは広く知られている。ＡＴＭ網では、セルと呼ばれる一定の大きさのデータサイズを転送単位として通信を行う。セルには着信先のアドレス情報がそのヘッダ内に格納されているので、ＡＴＭ交換機はセルの着信先に向かう適切なインタフェースに送出することができる。通信サービスの種類にかかわらず同一のセルの形式で転送することにより、さまざまなデータ速度の情報を同一の経路を使って転送することが可能となり、経済性が向上した。コネクション毎に通信サービスの品質を保証するために、発信元から着信先までの経路上の帯域リソースを確保する仕組みが用意されている。転送するデータの量、すなわち、一定時間当たりに転送する必要のあるセルの数が一定の場合には、ＣＢＲ（ＣｏｎｓｔａｎｔＢｉｔＲａｔｅ：固定ビットレート）というサービスカテゴリによって、転送経路上の帯域リソースの確保を行うことができる。ＣＢＲコネクションのそれぞれの帯域はＰＣＲ（ＰｅａｋＣｅｌｌＲａｔｅ：ピークセルレート）でＡＴＭ網側に申告される。また、転送するデータの量が変動する場合には、ＶＢＲ（ＶａｒｉａｂｌｅＢｉｔＲａｔｅ）というサービスカテゴリで帯域リソースを確保する。ＶＢＲコネクションは、ＰＣＲ，ＳＣＲ（平均セルレート）、ＭＢＳ（最大バーストサイズ）の３つのパラメータの申告値によってリソースをＡＴＭ網側で確保される。ＶＢＲコネクションは、さらに、そのサービスに要求されるリアルタイム性の有無から、ｒｔ−ＶＢＲ（ｒｅａｌ−ｔｉｍｅ−ＶＢＲ：実時間可変ビットレート）とｎｒｔ−ＶＢＲ（ｎｏｎ−ｒｅａｌ−ｔｉｍｅＶＢＲ）の２つに分かれている。ＡＴＭのサービスカテゴリは、この他に、ＵＢＲ（ＵｎｓｐｅｃｉｆｉｅｄＢｉｔＲａｔｅ：無規定ビットレート）とＡＢＲ（ＡｖａｉｌａｂｌｅＢｉｔＲａｔｅ：アベイラブルビット）があるが、これらは厳しいサービス品質を保証する必要があるサービス向けに使うことは想定されていない。
【０００５】
ＡＴＭでは網内の通信品質を確保するために帯域などのリソース全てを管理し、コネクション毎に要求してくるサービスカテゴリやそのＰＣＲ，ＳＣＲ，ＭＢＳパラメータに応じてそのリソースを割り当てることが可能かどうかを判定し、コネクションをＶＣ（仮想チャネル）に割り当てて制御している。さらに、コネクションが自ら申告したパラメータの値に違反した場合に、同一のＶＰ（ＶｉｒｔｕａｌＰａｔｈ：仮想パス）を共有する全てのコネクションの通信品質の劣化を引き起こすことを避けるために、ＵＰＣ（ＵｓａｇｅＰａｒａｍｅｔｅｒＣｏｎｔｒｏｌｌｅｒ）によるトラヒックの加工や制限などを行う必要がある。
【０００６】
（ＡＴＭにおける課題）
このようにＡＴＭ網では、サービス品質の保証を行うためのメカニズムが検討され標準化が進んでいるが、▲１▼網側でＵＰＣの実装が必須であること、▲２▼端末がＶＢＲコネクション毎にトラヒック特性パラメータＰＣＲ，ＳＣＲ，ＭＢＳのそれぞれの値を正確に申告する必要があること、▲３▼網側がそれに基づいて受付判定を行う機能が必要だが、コネクション数が増大すると、コネクションの確立要求の度に、経路計算や受付判定の計算時間が急激に増加するといった課題が存在している（非特許文献１、非特許文献２、特許文献１）。
【０００７】
（ＩＰ網の場合ＲＳＶＰ）
ＩＰ網でのサービス品質保証を行うためのプロトコルは、ＲＳＶＰ（ＲｅｓｏｕｒｃｅＲｅＳｅｒＶａｔｉｏｎＰｒｏｔｏｃｏｌ）が最もよく知られている。ＲＳＶＰは、アプリケーションがエンドエンドでのネットワーク資源をダイナミックに確保するメカニズムである。データの受信側となるアプリケーションは、必要とするサービス品質に応じて網のリソースの確保を要求するリクエストをデータの発信元に向けて送信する。このリクエストを最初に受信したＲＳＶＰ対応ルータは、リクエストしたアプリケーションに対して、要求されたサービス品質の提供が可能かどうかを判定する。次に、このリクエストはさらに上流のルータに転送されて、同様の判定が行われて、最終的には、データの発信元まで到達する。この間の全ての経路上でリソースの確保が可能な場合、要求されたサービス品質を保証するエンドエンドのコネクションを確立させることができる。ＲＳＶＰは、最近注目されているＭＰＬＳ（ＭｕｌｔｉＰｒｏｔｏｃｏｌＬａｂｅｌＳｗｉｔｃｈｉｎｇ）技術と結びつくための拡張が提案されている。ＭＰＬＳが注目される理由は、ＩＰ網において仮想的なプライベートネットワークやトラヒック・エンジニアリングを実現するための基盤技術として認識されたためであるが、ＭＰＬＳについてはさらに後述する。
【０００８】
（ＩＰ網ＲＳＶＰにおける課題）
しかしながら、ＲＳＶＰを機能させるためには、データの送信端末と受信端末の間の全てのルータがＲＳＶＰに対応しているだけでなく、端末上のアプリケーションもＲＳＶＰに対応している必要がある。これは、ＲＳＶＰがサービス品質を保証するために、データの転送にかかわる端末やルータが制御情報を交換するためのプロトコルにすぎず、実際にサービス品質を保証するためのメカニズムはそれぞれのルータの実装に任されている。また、ユーザ毎にさまざまな端末装置やＯＳ（ＯｐｅｒａｔｉｏｎＳｙｓｔｅｍ）やアプリケーションを自由に選択しているようなインターネット環境においては、このようなユーザ端末側におけるＲＳＶＰ対応を前提にすることは必ずしも容易な条件ではない。さらに、現状では、確保されるリソースは帯域速度だけであるので、トラヒック特性がバースト性を有する場合には最大バースト時の帯域を確保しなければサービス品質が保証できないことになるが、それではＩＰ網の帯域リソースを有効に利用できないという課題がある（非特許文献３、非特許文献４）。
【０００９】
（ＩＰ網の場合ＭＰＬＳとＤｉｆｆＳｅｒｖ）
ＭＰＬＳとはラベル（Ｌａｂｅｌ）と呼ばれるパケットに付けられた情報を基に、ルータがバケットを転送するインタフェースあるいはネクスト・ホップ・ルータを決定する方式である。他方、従来のルータの転送動作は、パケットの着信先のＩＰアドレスを見て、ネクスト・ホップ・ルータを決定する方式である。このとき、ＲＩＰ（ＲｏｕｔｉｎｇＩｎｆｏｒｍａｔｉｏｎＰｒｏｔｏｃｏｌ），ＯＳＰＦ（ＯｐｅｎＳｈｏｒｔｅｓｔＰａｔｈＦｉｒｓｔ）と同じように、ＩＰルーチングの最短経路にあるルータにパケットは転送される。最近、指摘されている欠点は、転送される経路が特定のリンクに片寄ってしまい、その結果、そのリンクにおいて輻輳が発生し、また、ネットワーク全体で見たときの転送効率やスループットの低下が起こっているという問題である。この片寄りを回避させる目的で、最短経路以外の明示的な経路を指定して迂回させる機能が求められた。ＭＰＬＳは、そのラベルの仕組みによって、明示的に最短経路以外の経路を指定できる点で注目されたといえる。
【００１０】
ＭＰＬＳと組合せて、大規模インターネットにおいて、エンドエンドでのサービス品質を実現させるために期待されている技術が、ＤｉｆｆＳｅｒｖ（ＤｉｆｆｅｒｅｎｔｉａｔｅｄＳｅｒｖｉｃｅｓ）である。ＤｉｆｆＳｅｒｖは、エッジのルータにおいて、入ってくるパケットの品質クラス分けを行い、そのクラスを識別する情報をＩＰヘッダに書き込む。コア・ルータでは、そのバケットの品質クラス単位でのホップ毎の扱いを規定して、エンドエンドのサービス品質を実現することができる。例えば、品質クラスには、ＥＦ（ＥｘｐｅｄｉｔｅｄＦｏｒｗａｒｄｉｎｇ）サービスとＡＦ´（ＡｓｓｕｒｅｄＦｏｒｗａｒｄｉｎｇ）サービスとＢＥ（ＢｅｓｔＥｆｆｏｒｔ）の３つのサービスクラスが標準化されている。一般に、ＥＦパケットは優先キューを用いて他のサービスクラスよりも先に転送される。ＡＦパケットはＥＦパケットがルータ内になくなったときに転送される。ＡＦサービスクラスには、さらに複数のサブクラスに分かれる場合があるが、このときはＷＦＱ（ＷｅｉｇｈｔｅｄＦａｉｒＱｕｅｕｅｉｎｇ）によって、サブクラスそれぞれにあらかじめ決められた重みにしたがった転送レートで送出される。ＢＥサービスクラスのパケットは最後に転送される。なお、サービス品質を保証されることを期待するユーザと、そのサービスを提供するサービスプロバイダの間では、そのサービス品質レベルに関する取り決めであるＳＬＡ（ＳｅｒｖｉｃｅＬｅｖｅｌＡｇｒｅｅｍｅｎｔ）をあらかじめ結んでおく必要がある。このＳＬＡの中に、遅延時間や遅延時間のゆらぎやパケット損失率に関する目標値が含まれることになる。
【００１１】
（ＩＰ網の場合ＭＰＬＳとＤｉｆｆＳｅｒｖにおける課題）
しかしながら、ＭＰＬＳとＤｉｆｆＳｅｒｖの組合せによって可能になることは、サービス品質のクラスに応じた目印を付けて、パケットそれぞれについてできるだけ適切な経路に割り振ることやホップでのＱｕｅｕｅｉｎｇの優先的な扱いといった転送の制御メカニズムが動作することにすぎない。動作した結果として、パケット損失率やエンドエンド遅延時間や遅延時間のゆらぎの実現値がそれぞれ目標値を達成することを保証するものではない。決められた目標値を達成するために、これらのメカニズムを運用させる具体的な方法については課題として残っている（非特許文献５、非特許文献６）。
【００１２】
（リーキーバケットによるモデル化の場合）
理論的な検討として、あるセッションによるデータストリームのトラヒック特性をリーキーバケットモデルによって表現し、それを基にしてサービスの品質保証を行うための受付制御が提案されている。リーキーバケットは、図８のようにバーストとしてパケットを連続して送出するバーストＯＮ期間とパケットを送出しないバーストＯＦＦ期間を一定時間間隔で繰り返すモデルである。本明細書では、バーストＯＮ期間をバースト時と呼ぶ。一般的に、リーキーバケットモデルは、ピークレートと平均レートとトークンパケットサイズの３つのパラメータによって表現すると定義されている。しかし、以降の説明を簡単にするために、トークンバケットサイズの代わりにバーストサイズを導入する。ただし、バーストサイズとは、リーキーバケットモデルのトラヒック特性の単一周期の間に転送されるパケットのデータサイズの合計と定義する。このとき、
バーストサイズ＝（トークンバケットサイズ）＊（ピークレート）／
（（ピークレート）―（平均レート））
という関係が成り立つ。
【００１３】
図９は、リーキーバケットモデルで表現することが可能なデータストリームがルータで転送されるときの、出側の通信リンクのバッファ内に滞留するデータ量の様子を典型的にモデル化して示している。ただし、入側リンクの方が出側リンクよりもリンク速度が速いことを仮定している。
【００１４】
入側リンクでは、バースト時にそのリンク速度で連続的にパケットを送出している（図９（１））。ただし、同図はパケット毎に示さず、バーストを構成するパケットのデータサイズ全体を流体的に示したものである。ルータでは、パケット毎のヘッダ情報を見て、適切なネクスト・ホップ・ルータへの通信リンクに向けてそのパケットを転送するが、この転送の速度は出側リンクのリンク速度である（図９（２））。このとき、出側リンクのバッファに滞留するデータ量が図９（３）に示されている。
【００１５】
図１０は図９（３）の１周期分を拡大して示した図である。同図を用いて、バッファに滞留するデータ量とパケット損失の関係について説明する。このルータのバッファ内に滞留するデータ量は、バースト時に入側リンクから入ってくるデータのレートと出側リンクから出ていくデータのレートの差の傾きで増加している。その後、バーストが終了して入側リンクからデータが入ってこなくなると、出側リンクのリンク速度で減少する。リーキーバケットモデルで表現することができるデータストリームが転送されているときに、あるルータでパケット損失が起こらないことを判定する条件は、図１０のバッファに滞留するデータ量の最大値がそのルータでのバッファ容量を超えないことである。ＡｎｗａｒＥｌｗａｌｉｄ等の文献（非特許文献７）では、この条件を満たすようにデータストリームのリーキーバケットモデル表現に基づいた受付判定を行うことが提案されている。具体的には、データストリームのリーキーバケット表現と、各ルータそれぞれの入側リンク速度と出側リンク速度と帯域とバッファ容量から、そのセッションを確立した場合、そのルータのバッファにおいてオーバーフロー、すなわち、パケット損失が起こるかどうかを判定することができる。送信側から受信側までの経路上の全てのルータでパケット損失が発生しないときに限り、そのセッションの確立を許可することに決めると、これはパケット損失ゼロを達成することができるセッションの受付判定方法となる。ただし、ここではパケット損失の原因がルータでのバッファオーバーフローだけに限定される場合を考えており、電気信号としてのビット誤りによるパケット廃棄は想定していない。あるいは、バッファオーバーフローによって損失となるパケット数よりもビット誤りにより廃棄されるパケットの数が相対的に十分に小さいことを想定しているが、これは現実的な仮定である。
【００１６】
これまでは、単一のデータストリームの受付判定を考えたが、転送される複数のデータストリームが多重化されても同様に考えることが可能である。このことを図１１によって説明する。図１１は、通信リンクで観察される複数のデータストリームそれぞれのバーストの様子を示している。データストリーム毎にバースト時には、入側リンクのリンク速度でルータのバッファにパケットが到着して、出側リンクのリンク速度で送出されている。入側リンクのリンク速度の方が出側リンクのリンク速度よりも高速であるために、ルータ内のバッファでパケットが滞留する。バーストの隙間では、入側リンクからのパケットの到着はないが、バッファに滞留しているパケットが残っている間は出側リンクからのパケットの送出が続く。つまり、入側がバーストしているときは、バッファ内に滞留するデータ量が増大して、入側のバーストがないときは、バッファ内に滞留するデータ量が減少する。このとき、リンクの使用率が一定であるいう条件の下では、バッファ内に滞留するデータ量が最大になるのは、ストリーム毎のバーストがつながってひとかたまりになってしまうときである。したがって、ひとかたまりになったバーストを、単一のデータストリームとみなしてリーキーバケットモデルとして表現すると、前述の単一のデータストリームの受付判定と同一の方法で、バッファでのオーバーフローによるパケット損失の発生の有無を判定することができる。ＡｎｗａｒＥｌｗａｌｉｄ等の文献（非特許文献７）で実際に提案されているのは、この受付判定方法である。
【００１７】
（リーキーバケットモデルにおける課題）
ＡｎｗａｒＥｌｗａｌｉｄ等のリーキーバケットモデルによる受付判定においては、ユーザセッションの確立要求時に、そのセッションに流れるデータストリームをリーキーバケットモデルの３つのパラメータの数値を決定して申告する必要があることと、発信側から着信側への経路上の全てのルータでバッファオーバーフローが起こらないことを評価する必要があることが課題である（非特許文献７）。
【００１８】
【特許文献１】
特許第２８８３３３７号
【非特許文献１】
齋藤洋、“ＡＴＭフォーラムシリーズトラヒックマネージメント仕様４
．０”、（社）電信電話技術員会
【非特許文献２】
富永英義、石川宏、“ポイント図解式標準ＡＴＭ教科書”、アスキー出
版局
【非特許文献３】
ＲＦＣ：２２０５
ＲｅｓｏｕｒｃｅＲｅＳｅｒＶａｔｉｏｎＰｒｏｔｏｃｏｌ（ＲＳＶＰ）−Ｖｅｒｓｉｏｎ１Ｆｕｎｃｔｉｏｎａｌ
Ｓｐｅｃｉｆｉｃａｔｉｏｎ
【非特許文献４】
ＲＦＣ：３２０９
ＲＳＶＰ−ＴＥ：ＥｘｔｅｎｓｉｏｎｓｔｏＲＳＶＰｆｏｒＬＳＰＴｕｎｎｅｌｓ
【非特許文献５】
ＲＦＣ：３０３１
ＭｕｌｔｉｐｒｏｔｏｃｏｌＬａｂｅｌＳｗｉｔｃｈｉｎｇＡｒｃｈｉｔｅｃｔｕｒｅ
【非特許文献６】
ＲＦＣ：３０３２
ＭＰＬＳＬａｂｅｌＳｔａｃｋＥｎｃｏｄｉｎｇ
【非特許文献７】
ＡｎｗａｒＥｌｗａｌｉｄ，ＤｅｂａｓｉｓＭｉｔｒａ，ａｎｄＲｏｂｅｒｔＨ．Ｗｅｎｔｗｏｒｔｈ， ”ＡＮｅｗＡｐｐｒｏａｃｈｆｏｒＡｌｌｏｃａｔｉｎｇＢｕｆｆｅｒｓａｎｄＢａｎｄｗｉｄｔｈｔｏＨｅｔｅｒｏｇｅｎｅｏｕｓ，ＲｅｇｕｌａｔｅｄＴｒａｆｆｉｃｉｎａｎＡＴＭＮｏｄｅ”，ＩＥＥＥＪｏｕｒｎａｌｏｎＳｅｌｅｃｔｅｄＡｒｅａｓｉｎＣｏｍｍｕｎｉｃａｔｉｏｎｓ，Ｖｏｌ．１３，Ｎｏ．６，Ａｕｇｕｓｕｔ１９９５．
【非特許文献８】
ＩＴＵ−Ｔ勧告Ｙ．１５４１
【非特許文献９】
ＲＦＣ：３２６１
ＳＩＰ：ＳｅｓｓｉｏｎＩｎｉｔｉａｔｉｏｎＰｒｏｔｏｃｏｌ
【非特許文献１０】
ＫａｔｓｕｙｏｓｈｉＩｉｄａ，ＫｅｎｎｊｉＫａｗａｈａｒａ，ＴｅｔｓｕｙａＴａｋｉｎｅ，ａｎｄＹｕｊｉＯｉｅ， ”ＰｅｒｆｏｒｍａｎｃｅＥｖａｌｕａｔｉｏｎｏｆｔｈｅＡｒｃｈｉｔｅｃｔｕｒｅｆｏｒＥｎｄ−ｔｏ−ＥｎｄＱｕａｌｉｔｙｏｆ−ＳｅｒｖｉｃｅＰｒｏｖｉｓｉｏｎｉｎｇ”，ＩＥＥＥＣｏｍｍｕｎｉｃａｔｉｏｎｓＭａｇａｚｉｎｅ，Ａｐｒｉｌ２０００．
【非特許文献１１】
ＫａｔｓｕｙｏｓｈｉＩｉｄａ，ＴｅｔｓｕｙａＴａｋｉｎｅ，ＨｉｄｅｋｉＳｕｎａｈａｒａ，ａｎｄＹｕｊｉＯｉｅ， ”ＤｅｌａｙＡｎａｌｙｓｉｓｆｏｒＣＢＲＴｒａｆｆｉｃＵｎｄｅｒＳｔａｔｉ−ＰｒｉｏｒｉｔｙＳｃｈｅｄｕｌｉｎｇ”，ＩＥＥＥ／ＡＣＭＴｒａｎｓａｃｔｉｏｎｓｏｎＮｅｔｗｏｒｋｉｎｇＶｏｌ．９，Ｎｏ．２，Ａｐｒｉｌ２００１．
【非特許文献１２】
藤木正也、雁部頴一“通信トラヒック理論”、丸善株式会社、１９８０
【００１９】
【発明が解決しようとする課題】
本発明は、大規模公衆向けの閉域ＩＰ網において、リーキーバケットモデルによって表現できるデータストリームを品質保証型サービスとして転送する方法において、以下の課題を解決することである。
【００２０】
第１の課題は、受付けた品質保証型サービスに対しては、そのサービス品質としてパケット損失率がゼロとなることを実現できること、また遅延時間とそのゆらぎについても、品質目標値を達成できることである。特に、ここでは、ルータなどの装置の制御メカニズムが動作するための仕組みではなく、その結果としてのサービス品質を確実に達成できるようにすることである。
【００２１】
第２の課題は、要求されるデータストリームのトラヒック特性の申告に基づく網リソースの確保を簡素化し、その受付判定をリアルタイムに処理でき、かつ、ＵＰＣの実装が必須ではなく、しかも、効率の高い網の運用ができるようにすることである。
【００２２】
【課題を解決するための手段】
本発明を説明しやすくするために、以下の用語を定義する。
【００２３】
（データストリームのバースト継続時間と周期の定義）
まず、リーキーバケットモデル表現のパラメータとして、バースト継続時間を導入する。バースト継続時間とは、バーストＯＮ期間の時間の長さであり、以下のように定義する。
【００２４】
バースト継続時間＝バーストサイズ／リンク速度
このとき、リンクのリンク速度毎にバースト継続時間が変化してしまうため、データストリーム固有のトラヒック特性を表現するためには適当ではない。そこで、リーキーバケットモデルによる表現のパラメータとして、周期を以下のように定義する。
【００２５】
周期＝バーストサイズ／平均レート
ここで、品質保証型サービスを提供する場合には、そのサービスの平均レートが少なくともリンク速度以下であることが必要であるので、この条件の下では、
周期＞＝バースト継続時間
の不等式が成り立つ。周期は、リンクのリンク速度によって変化しないという性質がある。これらの関係を説明しているのが、図５である。
【００２６】
このとき、任意のリーキーバケットモデルは、平均レートとピークレートの２つのパラメータと、トークンパケットサイズかバーストサイズか周期のどれか１つのパラメータの、合計３つのパラメータを使って一意に表現することができることになる。
【００２７】
本明細書では、これ以降、リーキーバケットモデルは、平均レートとピークレートと周期の３つのパラメータによって表現する。
【００２８】
（ノードのバースト吸収時間の定義）
次に、ノードのバッファに対して、バッファ容量の尺度に相当するバースト吸収時間を導入する。図６はバースト吸収時間を説明するための図である。入側リンクにおける受信パケット用のバッファのバースト吸収時間は、以下のように定義する。
【００２９】
バースト吸収時間＝バッファ容量／入側リンク速度
同様に、出側リンクでの送信待ちパケット用のバッファのバースト吸収時間も定義する。
【００３０】
バースト吸収時間＝バッファ容量／出側リンク速度
バースト吸収時間は、ノードの入側リンク速度とバッファ容量の組から決まるので、網を構築した時点でバースト吸収時間の値をデータベースに蓄積することができる。また、逆に、網全体のバッファである一定のバースト吸収時間を有するように各バッファのバッファ容量や各リンクのリンク速度を設計することもできることに注意する。
【００３１】
（パケット損失ゼロを達成する受付判定の方法）
このとき、要求されているデータストリームのトラヒック特性によって定義することができるバースト継続時間と、バッファに対して定義することができるバースト吸収時間によって、あるルータでのパケット損失ゼロを達成できるセッションの受付判定の方法を図７によって説明する。この受付判定方法は、ノードのバースト吸収時間が、要求されているデータストリームの最大のバースト継続時間であるバースト継続時間よりも長いならば、そのデータストリームの全てのパケットは、そのノードのバッファに収容できるのでパケット損失が起こらないとして、そのサービス要求の受付を可と判定する方法である。
【００３２】
しかし、この判定方法は、リンクのリンク速度毎にバースト継続時間が変化してしまうため個別に計算する必要があり、煩雑である。そこで、上記のようにバースト継続時間は周期よりも必ず短いという性質があり、周期は平均レート以上のリンク速度を確保しているという条件の下に、網内に転送される過程において変化しないので、バースト継続時間の代わりに周期を用いるようにする。つまり、バースト吸収時間が周期よりも大きいときに、そのサービス要求の受付を可と判定する方法である。
【００３３】
しかしながら、通常の実装においては、データストリームの周期とノードでのバースト吸収時間を比較すると、データストリームの周期の方が長く、ノードのバースト吸収時間の方が短いので、この受付判定方法が有効になることは現実的にはあまりない。
【００３４】
そこで、本発明のリンクのパケット損失ゼロを達成する受付判定方法は、リンクが品質保証型サービス向けに割り当てる速度の最大値を以下のように制限する。
【００３５】
品質保証型サービス向けに割り当てる速度の最大値＝ＭＩＮ｛（リンク速度）＊（バースト吸収時間）／（周期）、（リンク速度）｝
ただし、ＭＩＮ｛ｘ，ｙ｝は引数集合の最小値を返す関数
（具体例）
ここで具体例を使って説明する。例えば、リンク速度が１００Ｍｂｐｓ、データストリームの周期が１００ミリ秒、ノードのバースト吸収時間が５０ミリ秒であるときは、そのリンクでの割り当てる速度の最大値は、１００Ｍｂｐｓ＊５０ミリ秒／１００ミリ秒＝５０Ｍｂｐｓとなる。入側リンク速度１００Ｍｂｐｓのノードのバースト吸収時間が５０ミリ秒であれば、そのバッファ容量は、１００Ｍｂｐｓ＊５０ミリ秒＝５Ｍｂｉｔｓとなる。他方、データストリームの周期が１００ミリ秒なので、このデータストリームを５０Ｍｂｐｓ分のバーストサイズは、１００Ｍｂｐｓ＊５０ミリ秒＝５Ｍｂｉｔｓとなる。バッファ容量とバーストサイズが等しいので、出側リンクのリンク速度などを考慮するとバッファオーバーフローは起こらないので、パケット損失はゼロとなりサービス品質を達成することができる。
【００３６】
この具体例では、リンク速度が１００Ｍｂｐｓに対して、品質保証型サービス向けに割り当てるリンク速度の最大値が５０Ｍｂｐｓに制限されるため、網リソースの利用効率が悪いようだが、実際のところ必ずしもそうではない。これは品質を保証するサービスのトラヒックは５０Ｍｂｐｓまでに制限されるが、品質を保証しない通信サービスに残りの速度である５０Ｍｂｐｓを使うことが可能であるためである。しかも、品質を保証するサービスを品質保証しないサービスに対して優先制御を行うことにより、品質保証するサービスのトラヒックは品質保証しないサービスのトラヒックの影響をほとんど受けないようにする制御を行うことが必要である。
【００３７】
本発明の考え方は以下である。
【００３８】
▲１▼サービス品質を保証するデータストリームに対して、それぞれのトラヒック特性をリーキーバケットモデルで表現したときに定まる周期の集合に対して、ある一定値を網全体の閾値として設定する。この一定値を基準バースト継続時間と呼ぶことにする。
【００３９】
▲２▼網の全てのノードのバッファ容量を、バースト吸収時間の尺度で一定値以上にあらかじめ設計する。この一定値を、基準バースト吸収時間と呼ぶことにする。
【００４０】
▲３▼パケット損失ゼロをサービス品質とする品質保証型サービスのサービス要求リクエストに対して受付判定を行う。具体的には、各リンクに対して、品質保証型サービス向けに割り当てる速度の最大値を管理して、その最大値と、既にサービス提供中のセッション毎の平均レートを積み上げた値といま受付判定をしているサービス要求の平均レートの和を比較して、前者の方が大きいときに限り、そのサービス要求リクエストを受け付ける。ただし、この品質保証型サービス向けに割り当てる速度の最大値は、
品質保証型サービス向けに割り当てる速度の最大値＝ＭＩＮ｛（リンク速度）＊（基準バースト吸収時間）／（基準バースト継続時間）、（リンク速度）｝
ただし、ＭＩＮ｛ｘ，ｙ｝は引数集合の最小値を返す関数
によって定める。
リーキーバケットモデルで表現が不可能なデータストリームや、可能であっても基準バースト継続時間より大きなバースト継続時間を持つデータストリームに対してサービス品質を保証する必要がある場合には、データストリームのトラヒック特性を矯正して基準バースト継続時間未満に収めることによって、パケット損失ゼロを保証することが可能である。ここで、基準バースト吸収時間と基準バースト継続時間は、その網の設計時に網全体で一定値が達成できるように決める設計値であることに注意する。
【００４１】
▲４▼品質保証型サービスのサービス別に遅延時間とそのゆらぎをサービス品質目標値未満に抑えるためには、遅延時間とそのゆらぎの品質指標それぞれに、別の方法で、割り当てる速度の最大値を求めておく。そのとき、上記のパケット損失ゼロを達成するための割り当てる速度の最大値とあわせて３つの中で最小のものをその品質保証型サービス向けに割り当てる速度の最大値として運用する。さらに、品質保証型サービスを複数のサービスクラスで構成させるときには、各サービスクラス別に割り当てる速度の最大値を求めて、品質保証型サービスの全てのサービスクラスそれぞれで割り当てる速度の最大値を合計しても、元のリンク速度を超えないように調整する。
【００４２】
▲５▼品質保証型サービス向けに割り当てることができないリンク速度に相当する網リソースは、サービス品質を要求しないサービスクラスのトラヒックであるベストエフォートが使用するので、全体としての網の効率は悪くならない。
【００４３】
上記の考え方を実現させるための手段を以下に説明する。
【００４４】
本発明は前記の課題を解決するために、品質保証型サービスを提供するＩＰ網に以下の手段を具備する。
【００４５】
第１に、転送するデータストリーム毎のトラヒック特性を測定し、リーキーバケットモデルの表現を行うために、ピークレート、平均レート、バースト継続時間の各パラメータ値を決定するトラヒック特性測定装置を有する。
【００４６】
第２に、該トラヒック特性測定装置によって測定されたデータストリームのトラヒック特性情報を蓄積し、後述する受付判定サーバからの問い合せに応じて、データストリームのトラヒック特性情報をストリーム特性情報として回答するストリーム特性ＤＢを有する。
【００４７】
第３に、品質保証型サービスを提供する該ＩＰ網に関する情報が蓄積されている網構成ＤＢを有する。蓄積される情報には、ユーザ端末やルータなど、該ＩＰ網を構成する全てのノードの網内識別子、その位置情報、通信リンクの帯域、通信リンクとノードの接続関係などの情報を含む。ここで、網内識別子とは、該ＩＰ網に収容されている全てのネットワークノードにユニークに付けられ、ネットワークノードの各々がこれにより識別でき、その収容位置をこの識別子を検索キーにして該網構成ＤＢで調べることができる。具体的には、ＩＰアドレスを考えてもよいが、ユーザ端末のＩＰアドレスは該ＩＰ網に接続するたびに動的に割り当てることも可能である。また、ＩＰアドレスの割り当て方法もさまざまに考えることができる。しかし、網内識別子の割り当て方法などは、本発明の有効性とかかわらないので、通信サービスを始める前には網内識別子が決まっているものとする。
【００４８】
第４に、該ＩＰ網で提供する品質保証型サービスに関する情報が蓄積されているトラヒックＤＢを有する。蓄積される情報には、提供した品質保証型サービスを特定するサービス識別子、サービスを要求したユーザ端末の網内識別子、サービスを提供したサーバの網内識別子、サービス要求リクエストが到着した時間、サービスの受付可否判定結果、サービスの提供が開始された時刻、サービスの提供が終了した時刻あるいはサービスの提供が終了する見込みの時などの情報を含む。
【００４９】
第５に、該ＩＰ網において、品質保証型サービスのサービス要求リクエストに対して受付判定処理を行う受付判定サーバを有する。受付判定サーバはサービス要求リクエストが受信すると、まず、該サービス要求リクエストに要求されているサービスに対応するサービス別サーバに問い合わせて、そのサービス識別子やそのサービスを提供することによって発生するデータストリームの送信ノードと着信ノードの網内識別子などサービス内容を確定させる情報などを含むサービス内容情報を取得する。次に、該ストリーム特性ＤＢに問い合わせて、該サービス要求リクエストに格納されている情報と該サービス内容情報から、ユーザに要求されているサービスを提供することによって発生するデータストリームの平均レートなどのトラヒック特性情報を取得する。さらに、該網構成ＤＢに問い合わせて、発生する該データストリームの送受信ユーザ端末の網内識別子から、そのデータストリームの転送ルートと、その転送ルート上の各リンクのリンク速度を含む転送ルート情報を取得する。最後に、該トラヒックＤＢに問い合わせて、該転送ルート上で品質保証型サービスとして現在サービス提供中の全てのサービスに関する情報である提供中サービス情報を取得する。該受付判定サーバは、基準バースト接続時間と基準バースト吸収時間に基づき転送ルート上の各リンクについて、そのリンク速度を基に品質保証型サービス向けに割り当てる速度の最大値を計算する。該受付判定サーバは、これらの情報を総合して該サービス要求リクエストに要求されているサービスの受付判定を行う。具体的には、転送ルート上の各リンクにおいて、既にサービス提供中のセッション毎の平均レートを積み上げた値といま受付判定の対象であるサービス要求の平均レートの和が、そのリンクの品質保証型サービス向けに割り当てる速度の最大値を超えないときに限り、該サービス要求を受けつける。受付が可と判定されると、そのサービス要求されているサービスに対応したサービス別サーバに、該サービス要求リクエストのフォワーディングを行う。これ以降は、該サービス別サーバと該ユーザ端末の間でやりとりが始まる。受付が否と判定されると、該サービス要求リクエストを送信したユーザ端末に対して、サービス提供拒否のレスポンスを送信する。
【００５０】
第６に、該ＩＰ網を構成するネットワークノードである、ルータ、ＧＷ、ネットワーク終端装置には、全て優先Ｑｕｅｕｅｉｎｇ制御機能と前記の基準バースト吸収時間以上のバッファ容量を持つバッファを有する。優先Ｑｕｅｕｅｉｎｇ制御が動作するためには、全てのパケットにはそのパケットの優先サービスクラスに対応した目印が必要であるが、その目印を付ける方法は本発明の有効性とは無関係である。また、本発明で想定する優先Ｑｕｅｕｅｉｎｇ制御は、バッファに滞留しているパケットの中で、最も高い優先サービスクラスに属するパケットを到着順に選択する制御である。このように動作する優先Ｑｕｅｕｅｉｎｇ制御の実装方式には、さまざまな方式があるが、その詳細は本発明の有効性とは無関係である。
【００５１】
第７に、該トラヒック特性測定装置によって特定されたトラヒック特性が、該ＩＰ網で提供する全てのサービスのサービス品質全体に対して不適切なトラヒック特性を有すると判定されたデータストリームに対して、そのデータストリームのシェーピングを行い、適切なトラヒック特性に変換するストリームシェーピング装置を有することもできる。
【００５２】
本発明の上記の手段によって、ＩＰ網において、品質保証型サービスとしてデータストリームを転送する方法は、以下の利点が生じる。
【００５３】
第１に、受付けた品質保証型サービスに対しては、そのサービス品質としてパケット損失率がゼロとなることを実現できる。また、遅延時間とそのゆらぎについても、品質目標値を達成できる。
【００５４】
第２に、要求されるデータストリームのトラヒック特性の申告に基づく網リソースの確保を簡素化し、その受付判定をリアルタイムに処理でき、かつ、ＵＰＣの実装が必須ではなく、しかも、効率の高い網の運用ができる。具体的には、トラヒック特性の申告は、ユーザ端末に代わってトラヒックＤＢが行うので、網リソースの確保が簡単で確実である。受付判定は、要求されたサービスの平均レートが、転送ルート上の各リンクでそのサービス向けに割り当てられる速度として残っているかを調べるだけであり、従来技術のようにバースト性を評価することがないため高速に判定処理ができる。さらに、基準バースト継続時間と基準バースト吸収時間の尺度で、網リソースが網全体で一定となるように設計されているため、ボトルネックが発生しにくく、網全体の平均的な利用効率が高くなっている。
【００５５】
【発明の実施の形態】
次に、本発明の実施形態について図面を用いて詳細に説明する。
【００５６】
（本実施形態でサービス品質を保証するサービスの種類）
本実施形態である大規模公衆向け閉域ＩＰ網がユーザに対して提供しようとする通信サービスは、ＩＰ電話サービス、映像ストリーム配信サービス、インターネットアクセスを含む広いＩＰサービス向けのベストエフォートサービスの３つである。本実施形態は、これら３つのサービスに対して、それぞれ適切なサービス品質を保証できる必要があるが、品質保証型に分類されるサービスは、ＩＰ電話サービスと映像ストリーム配信サービスである。これらのサービスそれぞれに要求されるサービス品質は、ＩＴＵ−Ｔなどにおいて議論されており、具体的なサービス品質のパラメータとその数値はＩＴＵ−Ｔ勧告Ｙ．１５４１などの中に見ることができる（非特許文献８）。
【００５７】
（ＩＰ電話サービスの概要）
ＩＰ電話サービスは、本実施形態の閉域ＩＰ網内のユーザ端末同士、あるいは、閉域ＩＰ網内のユーザ端末と他のＩＰ網のユーザ端末、あるいは、閉域ＩＰ網のユーザ端末とＰＳＴＮ網の固定電話端末を結んだ相互の音声通信を適切なサービス品質で提供するものである。ここで、閉域ＩＰ網内のユーザ端末とインターネットを経由したユーザ端末間の音声通信についてはベストエフォートとする。
【００５８】
一般に、ＩＰ電話サービスを行うには、音声そのものの転送に先立って、相互のユーザ端末間のセッションを確立する必要がある。セッションを確立するために必要な情報は、音声の符号化方式、ＩＰアドレスとポート番号、必要な通信速度などであり、これらの情報をユーザ端末とやりとりするためのシグナリング方式として、ＳＩＰ（ＳｅｓｓｉｏｎＩｎｉｔｉａｔｉｏｎＰｒｏｔｏｃｏｌ）方式などが標準化されている。具体的には、ＳＩＰサーバにサービス要求メッセージを送って、電話番号からＩＰアドレス変換などを行っている。また、ＩＰ網内のユーザ端末が固定電話網（ＰＳＴＮ網）側の電話端末と通話を行うためには、ＭＧＷ（ＭｅｄｉａＧａｔｅＷａｙ）を経由してそこでメディア変換を行う必要がある。
【００５９】
ＩＰ網においてＩＰ電話サービスを実現する技術は、ＳＩＰ以外に、Ｈ．３２３、Ｈ．２４８（Ｍｅｇａｃｏ）などが検討されているが、これらの標準化内容と本発明の有効性は無関係である。
【００６０】
本実施形態のＩＰ電話サービスに要求されるサービス品質としては、ＩＴＵ−Ｔ勧告Ｙ．１５４１にあるように、エンドエンド遅延時間の目標値が１００ミリ秒未満、パケット損失率が０．０１未満、呼損率が０．１５未満を規定する。ただし、これは固定電話と同等であるようなサービス品質の高いＩＰ電話サービスのものである。
【００６１】
次に、本実施形態におけるＩＰ電話サービスのトラヒック特性を説明する。まず、そのトラヒックのボリュームであるが、一般的には、音声符号化方式やパケットフォーマットに依存するが、例えば、最も広く使われている音声符号化方式であるＧ．７１１が音声そのものを６４ｋｂｐｓのビットレートで符号化するので、これを２０ミリ秒毎にパケットにして送出するパケットフォーマットの場合には、ＲＴＰとＩＰヘッダを加えてＩＰパケットレベルで平均８０ｋｂｐｓとなる。本実施形態では、サービス品質保証を行うＩＰ電話サービスは、この音声符号化方式をＧ．７１１として２０ミリ秒毎にパケットにして送出する場合に限定するものとする。その結果、ＩＰ電話サービスのセッション当たり平均８０ｋｂｐｓと一律に換算することができる。したがって、ＩＰ電話サービスの１セッション当たりに必要な網のリソースは、リンクの帯域リソースとしては平均８０ｋｂｐｓとなる。ただし、ＩＰ電話サービスのトラヒック特性としての最大の特徴は、特定のセッションのＩＰ電話ストリームに着目すると、それぞれのセッション毎に、一定の長さのパケットを１パケットずつ一定時間間隔で送信していることである。したがって、本発明の適用条件であるリーキーバケットモデルによって表現されるようなトラヒック特性を有しない。しかしながら、パケット損失が発生しないようにすることは以下のようにすれば可能である。本実施形態の場合、セッション毎に２０ミリ秒間隔に１パケットが到着するので、１セッション当たりのリンクのバッファ容量は８０ｋｂｐｓの２０ミリ秒分、つまり、少なくとも１６００ｂｉｔ確保されていればパケット損失は発生しないようにすることができる（非特許文献９）。
【００６２】
（映像ストリーム配信サービスの概要）
映像ストリーム配信サービスは、ユーザ端末が要求する映像のデータストリームを映像配信サーバが送信する、クライアント・サーバ型のサービスのひとつである。コンテンツプロバイダはこれを課金サービスとして提供することを期待しているが、同時に、利用するユーザの方もその映像に対して非常に高いサービス品質を要求している。
【００６３】
映像ストリーム配信サービスに要求される最も厳しいサービス品質の指標は、パケット損失率である。その目標値は、Ｙ．１５４１において１０のマイナス５乗未満と規定されている。この厳しい規定では、パケット損失が起こらないように網設計することが実質的に必要になるので、本実施形態では、詳しくは後述するがパケット損失ゼロとなるように受付判定を行っている。他方で、これ以外のサービス品質である遅延時間や遅延時間のゆらぎは厳しいとはいえない。映像を再生するアプリケーション側がバッファを有しており、数秒程度の遅延時間やそのゆらぎを吸収することができるからであり、現実的にはユーザが遅延時間やそのゆらぎのサービス品質劣化を体感することはほとんどない。そこで、本実施形態では、遅延時間とそのゆらぎについての目標値の規定はしないものとする。
【００６４】
測定された映像ストリームのトラヒック特性の特徴として、特定のセッションの映像ストリームに着目すると、それぞれリーキーバケットモデルとして表現できることが知られている。つまり、リーキーバケットモデルの特徴である、▲１▼バーストが一定周期で発生すること、▲２▼１回のバースト時のデータ量であるバーストサイズが一定であること、▲３▼バースト時のピークレートが出側のリンク帯域速度に一致することの３つの特徴を有することが、映像データストリームのトラヒック測定結果からわかっている。これらの特徴が映像ストリームのトラヒック特性として、結果的に現れる理由として以下を擧げることができる。
【００６５】
▲１▼パーストが一定周期で発生すること
映像サーバは、ユーザ端末に対して映像ストリームを送出するが、これは映像の視聴時間の間、継続する映像サーバの動作である。映像サーバがストリームを配信するユーザ端末は１台ではなく、複数のユーザに対する処理を同時並行的に行う。したがって、映像サーバの通信インタフェースは論理的に時分割して共有されて、それぞれのユーザ端末向けの映像ストリームを順番に配信するように実装されることが普通である。このとき、特定のユーザ向けの映像ストリームだけに着目すると、映像ストリームが周期的なバースト性を持って測定される。したがって、このバースト性の周期は、映像ストリーム毎に決まっているというよりも、むしろ映像サーバ毎に決まっているという性質がある。さらに、映像サーバでは配信する映像ストリームの品質を安定化させるために、このバースト性の周期をできるだけ小さくなるように、映像配信アプリケーションが実装されている。その結果、大規模かつ高機能映像サーバでは、その映像ストリームのバースト性の周期がＯＳのタイムスロット程度まで小さく実装されている。ただし、映像サーバのＯＳとしては、ＷｉｎｄｏｗｓやＭａｃＯＳやＬｉｎｕｘを含むＵＮＩＸ系などであるが、これらはどれも１０ミリ秒をタイムスロットにしているので、映像サーバアプリケーションレベルでの実装を考えるとき、バースト性の周期の限界（下界）は現実的に１０ミリ秒であろう。いずれにせよ、実際に測定される映像サーバから送出される映像ストリームのバースト性の周期は、２０ミリ秒から５００ミリ秒程度である。
【００６６】
▲２▼１回のバースト時のデータ量が一定であること
映像ストリームは、それぞれ平均ビットレートがあらかじめ決まっている。これは、通常の場合、映画フィルムなどの映像ソースをＭＰＥＧなどの動画像符号化方式でコーディングする前にあらかじめコーディングレートとして平均ビットレートを指定することが必須だからである。平均ビットレートが決まっていて、かつ、上記のようにバーストの周期が一定であるため、１回のバースト時のデータ量が一定になることは当然である。
【００６７】
▲３▼バースト時のピークレートが出側のリンク帯域速度に一致すること
パケットの送出時に、出側のリンク帯域速度に一致することは当然である。さらに、リーキーバケットモデルで表現されるトラヒック特性が、ルータのホップによっても壊れないで残るということが以下のように説明される。映像サーバは、大規模公衆の閉域ＩＰ網の場合、その階層構造の最上層のＬＡＮに配置されるのが通常の場合である。この理由は、映像サーバから閉域ＩＰ網内の全てのユーザ端末への配信経路が最上層から最下層へのシンプルな経路になり、マルチキャストやミラーリングといった機能を導入しやすくなるためである。したがって、映像データストリームの発信元である映像配信サーバから、着信先であるユーザ端末へ至る転送ルートのリンク速度は、次第に低速になっていくのが普通である。そのため、映像データストリームのバースト性のピークレートはルータでホップされる度にそれぞれのリンク速度に減少するものの、パケットの集団的な到着としてのバースト性はそのまま残るので、リーキーバケットモデルのバースト周期とバースト時のデータ量の値がほぼ保存されると考えられる。
【００６８】
以上の理由から、映像サーバが大規模公衆網の閉域ＩＰ網においては、映像ストリームのトラヒック特性がリーキーバケットモデルにより表現できること、さらに、そのトラヒック特性がユーザ端末に向かって転送されるルータでのホップでは壊れないことは、たまたま測定された現象ではなく、かなり普遍的な現象であると考えることができる。したがって、映像ストリームが、本発明の適用可能なトラヒック特性としての前提条件を満たしていると考える。
【００６９】
（ベストエフォートサービスの概要）
ベストエフォートサービスとは、ネットワークが混雑したときにユーザが利用できる通信速度を保証しないサービスの総称であるが、インターネットへのアクセスであるＷＷＷ、メール、ファイル転送など、ほとんどのサービスが現状ではベストエフォートサービスとして提供されている。
【００７０】
ベストエフォートサービスのトラヒック特性は、現時点で、これを陽にモデル化したり表現したりするようなことはできない。ベストエフォートサービスクラスは、さまざまなプロトコルによるセッションやそれぞれのトラヒック特性が全て統合されてしまうからである。この中の大多数のセッションやトラヒックボリュームはＴＣＰプロトコルによって占められていることが、インターネット上のリンクで測定されているが、ＴＣＰプロトコルはそのウインドウサイズ制御のアルゴリズムが複雑であるために、その制御アルゴリズムからでは特定のセッションに対するパケットレベルのサービス品質の推定を行うことは現状では全く困難である。
【００７１】
ベストエフォートサービスのサービス品質として要求されることは、比較的ゆるいサービス品質を相対的に長い時間で見たときに、サービスクラス全体の平均値として達成できていることで現状としては十分であり、ユーザが要求する特定のセッションに対してサービス品質を要求されることはない。
【００７２】
とはいえ、ベストエフォートサービスクラスは、ＩＰ網に接続中には、全てのユーザがさまざまなアプリケーションによって利用状態にある。したがって、ベストエフォートのトラヒックのスルートップが極端に小さくなると、その悪い影響が全てのユーザに及ぶことが想定されるので、ベストエフォートのスルートップは常に一定以上確保することが必要である。
【００７３】
（優先Ｑｕｅｕｅｉｎｇ制御の設定）
本実施形態では、上記の各サービスクラスの概要と、それぞれに要求されるサービス品質を総合して、優先Ｑｕｅｕｅｉｎｇ制御を次のように設定する。つまり、その優先サービスクラスは、高い順番に、ＩＰ電話サービス、映像ストリーム配信サービス、最後に、ベストエフォートサービスと決める。これは、遅延時間とゆらぎに対するサービス品質の要求条件が厳しい順番で定めることにする。また、優先Ｑｕｅｕｅｉｎｇ制御のサービスクラス別にバッファが存在するものとする。
【００７４】
次に、優先Ｑｕｅｕｅｉｎｇ制御の優先順位にしたがって、それぞれのサービスクラスを提供するために必要な網リソースの設備量を設計する。まず、ＩＰ電話サービスの需要を予測し、その需要に応えるために必要なリンクのリンク速度やバッファ容量、ＭＧＷでのポート数などＩＰ電話サービスのサービス品質を保証するために必要な網のリソースを設計する。この詳しい内容は後述する。
【００７５】
（基準バースト継続時間と基準バースト吸収時間の決定）
ここで、本発明の適用先のサービスクラスである映像ストリーム配信サービスに対して、基準バースト継続時間を１００ミリ秒と規定する。これは、前述のように、映像配信サーバのバースト性の周期が２０ミリ秒から５００ミリ秒であることを考慮して定めた。また、各バッファの基準バースト吸収時間は４０ミリ秒と規定する。すなわち、各ノードのバッファ容量はリンク速度に対して少なくとも４０ミリ秒分のバーストによるデータ量以上のサイズを有することを要求条件とする。ただし、本実施形態で説明しているバッファ容量とは、優先Ｑｕｅｕｅｉｎｇ制御のサービスクラス別に存在するバッファのバッファ容量である。しかしながら、優先サービスクラス別のＱｕｅｕｅが存在せず、共有型のバッファである場合も本発明は実施することが可能である。その場合には、優先サービスクラス別に必要なバッファ容量を計算して、その合計以上のバッファ容量を有するバッファを持つことによって、各サービスクラス別に受付判定制御を行うことによってそれぞれの優先サービスクラスに必要なサービス品質を満足することができる。
【００７６】
図１は本発明の一実施形態である大規模公衆向けの閉域ＩＰ網の構成図である。
【００７７】
大規模公衆向け閉域ＩＰ網１０はルータ１０１Ａ、１０１Ｂ、１０１Ｃ、１０１Ｄ、１０１Ｅ、１０１Ｆ、１０１Ｇとネットワーク終端装置３０Ａ、３０Ｂ、３０Ｃ、・・・、３０ＪとＧＷ（ゲートウェイ）装置４０、５０を含んでいる。ネットワーク終端装置３０Ａ、３０Ｂ、３０Ｃ、・・・、３０Ｊにはそれぞれ通信リンクＬ２Ａ、Ｌ２Ｂ、Ｌ２Ｃ、・・・、Ｌ２Ｊを介してユーザ端末２０Ａ、２０Ｂ、２０Ｃ、・・・、２０Ｊが接続されている。ここで、ユーザ端末２０Ａ〜２０Ｊはコンピュータや家電製品を含むＩＰ端末であってもよい。また、ネットワーク終端装置３０Ａ、３０Ｂ、３０Ｃ、・・・、３０ＪはＡＤＳＬモデムやＯＮＵ（ＯｐｉｔｉｃａｌＮｅｔｗｏｒｋＵｎｉｔ）などであってもよい。ルータ１０１Ａ〜１０１Ｇは閉域ＩＰ網１０を構成するノードであり、優先Ｑｕｅｕｅｉｎｇ機能と基準バースト吸収時間以上の基準バースト吸収時間以上のバッファを有している。ルータ１０１Ａから１０１Ｇ間は通信リンクＬ１０２ＡＢ、Ｌ１０２ＡＥ、・・・、Ｌ１０２ＥＧによって互いに接続されている。また、ルータ１０１Ｃとネットワーク終端装置３０Ａ、３０Ｂ、３０Ｃ間はそれぞれ通信リンクＬ２Ａ、Ｌ２Ｂ、Ｌ２Ｃによって接続され、ルータ１０１Ｄとネットワーク終端装置３０Ｄ、３０Ｅ間はそれぞれ通信リンクＬ３Ｄ、Ｌ３Ｅによって接続され、ルータ１０１Ｆとネットワーク終端装置３０Ｆ、３０Ｇ間は通信リンクＬ３Ｆ、Ｌ３Ｇによって接続され、ルータ１０１Ｇとネットワーク終端装置３０Ｈ、３０Ｉ、３０Ｊ間は通信リンクＬ３Ｈ、Ｌ３Ｉ、Ｌ３Ｊによって接続されている。ルータ１０１Ａは、優先Ｑｕｅｕｅｉｎｇ制御装置と基準バースト吸収時間以上のバッファを有するＧＷ装置４０と５０に通信リンクＬ１０２Ａ４とＬ１０２Ａ５によりそれぞれ接続している。ＧＷ４０とＧＷ５０は、それぞれインターネットと品質保証型サービス用ＬＡＮ（ＬｏｃａｌＡｒｅａＮｅｔｗｏｒｋ）６０と接続されている。その通信リンクが、それぞれＬ１０２ＯＵＴとＬ２０２ＡＧである。したがって、閉域ＩＰ網１０は、インターネットを経由してその他の網と通信を行うことが可能である。また、品質保証型サービス用ＬＡＮ６０は、詳しくは後述するが、閉域ＩＰ網１０がさまざまなＩＰサービスをユーザに提供するためのＬＡＮである。品質保証型サービス用ＬＡＮ６０の実施形態の構成図については、引き続く図２に示す。ただし、図１は本発明の実施形態である大規模公衆向けの閉域ＩＰ網１０の一部を説明のために抜き出して図示したものである。
【００７８】
図２は、図１の実施形態の品質保証型サービス用ＬＡＮ６０の構成図である。同図における４０００および５０００は、提供するサービス種別毎に構築されるサービス別ＬＡＮであり、それぞれのサービスを提供するために必要となる各種サーバやＤＢ（ＤａｔａＢａｓｅ）などから構成される。サービス別ＬＡＮ４０００、５０００の構成については、図３を用いて詳しく後述する。
【００７９】
品質保証型サービス用ＬＡＮ６０はルータ２０１Ａ、２０１Ｂ、２０１ＣとＧＷ（ゲートウェイ）装置５０受付判定サーバ１００１と網構成ＤＢ２００１とトラヒックＤＢ２００２とストリーム特性ＤＢ３００１とストリーム特性測定装置３００２とストリームシェーピング装置３００３を含んでいる。ルータ２０１Ａ、２０１Ｂ、２０１Ｃは品質保証型サービス用ＬＡＮ６０を構成するノードとなるルータで、優先Ｑｕｅｕｅｉｎｇ制御機能とバッファを有している。Ｌ２０２ＡＢ、Ｌ２０２ＡＣはルータ２０１Ａ、２０１Ｂ、２０１Ｃ間を接続している通信リンクである。また、これらのルータ２０１Ａ、２０１Ｂ、２０１Ｃは通信リンクＬ２０２ＡＧおよびＬ１０２Ａ５によって、図１の大規模公衆向け閉域ＩＰ網１０に接続されている。受付判定サーバ１００１は、ユーザからのサービス要求それぞれに対して、受付が可能か否かの判定を行う。網構成ＤＢ２００１は、網内のルータやネットワーク終端装置、ユーザ端末を含むノードに関する必要な情報を蓄積している。トラヒックＤＢ２００２は、各種サービス要求によって確立したセッションやそれによって発生したトラヒックに関して必要な情報を蓄積する。さらに、ストリーム特性ＤＢ３００１は、サービスの種別毎に各ユーザセッションに流れるデータストリームのトラヒック特性に関する必要な情報を蓄積する。ストリーム特性測定装置３００２は、ストリーム特性ＤＢ３００１に蓄積するデータストリームのトラヒック特性を測定する。ストリームシェーピング装置３００３は、データストリームのトラヒック特性が閉域ＩＰ網６０においてサービス品質を保証した通信サービスを提供する目的において、不適切なトラヒック特性を持つデータストリームを送出するサーバに対して、そのデータストリームが適切なトラヒック特性となるようにシェーピングを行う。ここで、適切か不適切かの判断方法についての詳細は図３で後述するが、図２のサービス別ＬＡＮ４０００は適切なトラヒック特性を有するデータストリームを送出するサービス別ＬＡＮであり、サービス別ＬＡＮ５０００は不適切なトラヒック特性を有するデータストリームを送出するサービス別ＬＡＮである。ただし、図２は、品質保証型サービス用ＬＡＮの一部を説明のために抜き出して図示したものである。
【００８０】
図３は図２のサービス別ＬＡＮ４０００および５０００を、それぞれＩＰ電話サービスと映像ストリーム配信サービスを提供する本実施形態にあわせて具体化したものである。両方ともセッションの確立・変更・終了を行うためのアプリケーション層シグナリングプロトコルとして、ＳＩＰ（ＳｅｓｓｉｏｎＩｎｉｔｉａｔｉｏｎＰｒｏｔｏｃｏｌ）を使用する。
【００８１】
品質保証型サービス用ＬＡＮ６０はＧＷ装置５０とルータ２０１Ａ〜２０１Ｃと受付判定サーバ１００１と網構成ＤＢ２００１とトラヒックＤＢ２００２とストリーム特性ＤＢ３００１とストリーム特性測定装置３００２とストリームシェーピング装置３００３とＩＰ電話用ＳＩＰサーバ４００１とＭＧＷ（メディアゲートウェイ）４００２と映像配信サーバ５００２Ａ、５００２Ｂを含んでいる。
【００８２】
ＩＰ｀電話サービスにかかわるものは以下である。ＩＰ電話用ＳＩＰサーバ４００１は、電話番号とＩＰアドレスへの相互変換を行い、発着のユーザ端末間でのＩＰ電話サービスのセッションの確立のための処理などを行う。ＭＧＷ（ＭｅｄｉａＧａｔｅＷａｙ）４００２は、発着のユーザ端末のどちらかがＰＳＴＮ網のユーザ端末であるとき、ＩＰ網でのＩＰ電話端末とのセッションとＰＳＴＮ網での固定電話端末とのセッションをそれぞれ終端して、転送するデータを相互のセッションで転送可能なメディア形式に変換を行い、ユーザ端末間のＩＰ電話サービスを可能とする。
【００８３】
映像ストリーム配信サービスにかかわるものは以下である。映像配信用ＳＩＰサーバ５００１は、サービス要求を出したユーザ端末と映像配信サーバの間で、映像のデータストリームを転送するためのセッションを確立・変更・終了を行う。映像配信サーバ５００２Ａは、そのデータストリームのトラヒック特性が基準バースト継続時間未満であり、映像配信サーバ５００２Ｂは基準バースト継続時間を超える場合である。基準バースト継続時間を超えるバースト継続時間を有する映像配信サーバ５００２Ｂは、ストリームシェーピング装置３００３によって、バースト継続時間が基準バースト継続時間未満となるトラヒック特性を有するように矯正される。そうでなければ、サービス品質を保証せず、ベストエフォートのサービスクラスとする。
【００８４】
本発明の実施形態である図１から図３の閉域ＩＰ網において、ユーザ端末２０Ａからの要求された品質保証型サービスに対する受付判定について図４を用いて詳しく説明する。ユーザ端末２０Ａからのサービス要求リクエストのうち、ＧＷ４０を経由して、さらにインターネットを経由して、そのサービスを提供するサーバへ向けて直接転送するサービス要求メッセージはベストエフォートサービスクラスに属する。品質保証型サービスに属するＩＰ電話サービスと映像ストリーム配信サービスのサービス要求リクエストは、受付判定サーバ１００１へ向けて転送される（ステップ７００１）。
【００８５】
ところで、ユーザ端末あるいはユーザに、サービス要求のメッセージの送出先が受付判定サーバ１００１となるように誘導する方法について、簡単に言及しておく。現在、一般にインターネットの利用は、ＷＷＷ（ＷｏｒｌｄＷｉｄｅＷｅｂ）あるいはＷｅｂと呼ばれるインタフェースで行われている。Ｗｅｂの技術によって、インターネットにつながっているコンピュータ上のさまざまな情報がＷｅｂサーバに蓄積され、それをＷｅｂクライアントがリクエストしてダウンロードすることによって自由に閲覧し利用できるようになっている。このとき、ドキュメントを転送するのに利用されるプロトコルがＨＴＴＰ（ＨｙｐｅｒＴｅｘｔＴｒａｎｓｆｅｒＰｒｏｔｏｃｏｌ）であり、ドキュメントを記述する言語としてＨＴＭＬ（ＨｙｐｅｒＴｅｘｔＭａｒｋｕｐＬａｎｇｕａｇｅ）が使用されている。Ｗｅｂプロシキは、当初セキュリティ目的でのファイアウォールとして導入されたが、キャッシュなどの機能とともに、ＨＴＴＰ以外のシステムへのゲートウェイとしての役割を果たすことができる。具体的には、ＦＴＰ（ＦｉｌｅＴｒａｎｓｆｅｒＰｒｏｔｏｃｏｌ）サーバとＷｅｂクライアントとを仲介して、ＷｅｂクライアントからのＨＴＴＰリクエストをＦＴＰリクエストに変換しＦＴＰサーバに転送することができるし、ＦＴＰサーバからのレスポンスをＨＴＴＰレスポンスへフォーマット変換をしてＷｅｂクライアントに返すことができる。つまり、ユーザからのサービス要求メッセージを受付判定サーバ１００１に向けて送信させる方法のひとつは、ＷｅｂインタフェースとＷｅｂプロキシを利用することで可能である。しかしながら、この具体的な方法がいかようであるかは本発明の有効性には関係がないので、説明を先に進める。
【００８６】
（まず、サービス内容情報を取得する）
受付判定サーバ１００１はユーザ端末２０Ａからサービス要求リクエストが受信すると、まず、サービス要求リクエストに要求されているサービスがＩＰ電話サービスであるのか、映像ストリーム配信サービスであるのかを調べて、ＩＰ電話サービスのときにはＩＰ電話ＳＩＰサーバ４００１に、映像ストリーム配信サービスのときには映像配信ＳＩＰサーバ５００１に対してサービス内容問い合せのメッセージを送信する（ステップ７００２）。サービス内容問い合せを受信したＳＩＰサーバ５００１は、要求されているサービスのサービス識別子やそのサービスを提供することによって発生するデータストリームの送信ノードと着信ノードの網内識別子などサービス内容を確定させる情報などを含むサービス内容情報を回答として受付判定サーバ１００１に返す。
【００８７】
（次に、ストリーム特性情報を取得する）
次に、受付判定サーバ１００１は、サービス要求リクエストに要求されているサービスのサービス識別子に対応するデータストリームのストリーム特性情報をストリーム特性ＤＢ３００１に問い合わせる（ステップ７００３）。ストリーム特性ＤＢ３００１は、あらかじめ測定した各サービスのデータストリームのトラヒック特性情報をストリーム特性情報として蓄積しており、問い合わせられたサービス識別子に対応するデータストリームのトラヒック特性情報を受付判定サーバ１００１に回答することができる。ここで、データストリームのトラヒック特性を測定し、そのリーキーバケットモデルによる表現を行うために、ピークレート、平均レート、バースト継続時間のパラメータ値の決定するための手段がトラヒック特性測定装置３００２である。
【００８８】
本実施形態では、さらに、トラヒック特性測定装置３００２によって特定されたトラヒック特性について、基準バースト継続時間を超えるバースト継続時間を有するデータストリームに対して、そのデータストリームのシェーピングを行い、バースト継続時間を基準バースト継続時間未満に矯正を行う。ただし、ストリームシェーピング装置３００３は、本発明に必須の要件ではない。データストリームのストリーム特性が不適切な場合は、サービス品質を保証せず、ベストエフォートのサービスクラスとしてサービスを提供することもできるからである。
【００８９】
（さらに、転送ルート情報を取得する）
次に、受付判定サーバ１００１は、受信したサービス要求リクエストによって要求されているサービスを提供することによって発生するデータストリームの転送ルートとその転送ルートを構成する各リンクのリンク速度に関する情報を、網構成ＤＢ２００１に問い合わせる（ステップ７００４）。これが転送ルート問い合せである。網構成ＤＢ２００１には、閉域ＩＰ網１０に関する情報が蓄積されている。蓄積される情報には、ユーザ端末やルータなど閉域ＩＰ網１０を構成する全てのノードの網内識別子、その位置情報、通信リンクの帯域、通信リンクとノードの接続関係などの情報を含む。
【００９０】
（補足）
ただし、一般的なＩＰ網では、ある発着信端末の組み合わせに対して、パケットの転送ルートは厳密には一意に決めることができない。この特性がＩＰ網のコネクションレス性と呼ばれる。しかしながら、大規模公衆向けの閉域ＩＰ網の場合、通常はユーザ端末を含むノードは単純なツリー構造で構成されるため、転送ルートのバラエティが存在しないかあまり多くないことが通常である。これは、このような目的の網は、非常に大多数のユーザのトラヒックを集めて、１箇所かわずか数箇所のインターネットへの接続ポイントへ向けて接続する網構成とならざるを得ないからである。本実施形態の閉域ＩＰ網１０も、図１のように単純なツリー構造であるため、転送ルートは一意に定めることができる。ただし、本発明は信頼性を高めるためにリンクの二重化を行うことは排除しない。リンクの二重化をしていても論理的には１つのリンクと見なせる場合には、転送ルートや網リソースを決定することができるからである。
【００９１】
（最後に提供中サービス情報を取得する）
最後に、受付判定サーバ１００１は、現在サービス提供中の品質保証型サービスのサービスセッションに関する情報をトラヒックＤＢ２００２に問い合わせる（ステップ７００５）。これが提供中サービス問い合せである。トラヒックＤＢ２００２は、受付判定を行ったサービス要求リクエストの全てに関する情報を蓄積しているので、それらの情報を提供中サービス回答として、受付判定サーバ１００１に返すことができる。トラヒックＤＢ２００２に蓄積される情報には、提供した品質保証型サービスを特定するサービス識別子、サービスを要求したユーザ端末の網内識別子、サービスを提供したサーバの網内識別子、サービス要求リクエストが到着した時間、サービスの受付可否判定結果、サービスの提供が開始された時刻、サービスの提供が終了した時刻あるいはサービスの提供が終了する見込みの時刻などの情報を含む。ただし、提供中サービス回答の情報量を減らすために、該サービス要求メッセージに要求されたサービスの転送ルート上のリンクを共有する提供中のサービスだけを回答する方法、現時点と直近で送った情報との差分情報だけを回答する方法などが考えられるが、本発明の有効性には関係がない。
【００９２】
（受付判定における割り当て可能なリンク速度の上限の計算）
本実施形態での映像ストリーム配信サービス向けに割り当て可能なリンク速度の上限の計算方法を説明する。ただし、ＩＰ電話サービス向けのそれは、そのトラヒック特性が本発明の対象とするリーキーバケットモデルで表現できるという条件に合わないので後述の別の方法で定めるものとする。
【００９３】
受付判定サーバ１００１は、基準バースト継続時間と閉域ＩＰ網１０の基準バースト吸収時間に基づき転送ルート上の各リンクについて、そのリンク速度を基に品質保証型サービスに対して割り当て可能なリンク速度の上限を計算することができる。つまり、映像ストリーム配信サービスの基準バースト継続時間は１００ミリ秒であるが、これは閉域ＩＰ網１０の基準バースト吸収時間の４０ミリ秒よりも大きい。
【００９４】
割り当て可能なリンク速度の上限＝ＭＩＮ｛（リンク速度）＊（基準バースト吸収時間）／（基準バースト継続時間）、（リンク速度）｝
ただし、ＭＩＮ｛ｘ，ｙ｝は引数集合の最小値を返す関数
上の式に代入すると、映像ストリーム配信サービスに割り当て可能なリンク速度の上限はリンク速度の５分の２となり、これに対するリンク速度までは品質保証型サービスを提供してもパケット損失がゼロになる。
【００９５】
したがって、受付判定サーバ１００１は、上記のサービス内容情報、ストリーム特性情報、転送ルート情報、提供中サービス情報と、この割り当て可能なリンク速度の上限を総合して該サービス要求リクエストに要求されているサービスの受付判定を行うことができることを示す。サービス要求リクエストを発信したユーザ端末２０Ａは、映像ストリームの着信端末になるが、映像ストリームの発信元が映像配信サーバ５００２Ａになる場合、そのデータストリームの転送ルートが以下となることが網構成ＤＢ２００１からの次の転送ルート問い合せによってわかっている。
【００９６】
映像配信サーバ５００２Ａ―リンクＬ２０２ＢＳＡ―ルータ２０１Ｂ―リンクＬ２０２ＡＢ―ルータ２０１Ａ―リンクＬ２０２ＡＧ―ＧＷ５０―リンクＬ１０２Ａ５―ルータ１０１Ａ―リンクＬ１０２ＡＢ―ルータ１０１Ｂ―リンクＬ１０２ＢＣ―ルータ１０１Ｃ―リンクＬ３Ａ―ネットワーク終端装置３０Ａ―リンクＬ２Ａ―ユーザ端末２０Ａ。
【００９７】
また、受付判定サーバ１００１は、取得した転送ルート情報の中で転送ルート上の各リンクのリンク速度の情報も取得していて、例えば、Ｌ１０２ＢＣはリンク速度１００Ｍｂｐｓとわかっている。
【００９８】
上記のように、パケット損失率をゼロにするためには、基準バースト吸収時間と基準バースト継続時間による割り当て可能なリンク速度の上限はリンク速度の５分の２となるので、映像ストリーム配信サービス向けのリンク速度は、Ｌ１０２ＢＣでは４０Ｍｂｐｓである。
【００９９】
提供中サービス情報の取得によって受付判定サーバ１００１は、転送ルート上の各リンクで現在提供中の映像ストリーム配信サービスの情報が既にわかっている。例えば、Ｌ１０２ＢＣの下りには、現在提供中の映像ストリーム配信サービスとして、平均レート６Ｍｂｐｓのセッションが３本、平均レート４Ｍｂｐｓのセッションが３本、平均レートで合計３０Ｍｂｐｓが転送されている情報を取得している。
【０１００】
したがって、Ｌ１０２ＢＣでの映像ストリーム配信サービス向けの残余のリンク速度は、４０Ｍｂｐｓ―３０Ｍｂｐｓ＝１０Ｍｂｐｓとなっている。だから、現在受付判定をしているサービス要求メッセージが要求している映像ストリーム配信サービスの平均レートが１０Ｍｂｐｓ未満ならば受付判定はＬ１０２ＢＣの下りリンクでは可となり、そうでなければ、受付判定は否となる。
【０１０１】
Ｌ１０２ＢＣの上りについても本実施形態では下りと同一の方法とする。ただし、映像ストリーム配信サービスでは、下りのトラヒックデータのボリュームが大きいのに対して、上りのトラヒックデータのボリュームは非常に小さいことが特徴である。本実施形態では、映像ストリーム配信サービス１セッション当たり１００ｋｂｐｓの場合である。ただし、実施形態によって、上り方向のリンク速度が不足することによってサービス品質が劣化することはないと判明する場合には、上り方向の受付判定はしなくてもよい。
【０１０２】
表１は上記の情報をまとめたものであり、受付判定サーバ１００はこのような表を管理して受付判定を行なう。
【０１０３】
【表１】

Ｌ１０２ＢＣの下りと上り両方向について受付判定が可となった場合に、Ｌ１０２ＢＣのリンクでの受付判定を可とする。そうでないときには、Ｌ１０２ＢＣのリンクでの受付判定を否とする。
【０１０４】
要求された映像ストリーム配信サービスの転送ルート上の全てのリンクに対して同様の判定を行い、全てのリンクで残余のリンク速度が、要求された映像ストリーム配信サービスの平均レートよりも大きくて、そのリンクでの受付判定が可となった場合に限り、該サービス要求メッセージで要求された映像ストリーム配信サービスの受付判定を可とする。
【０１０５】
（受付判定後の処理）
受付が可と判定されると、受付判定サーバ１００１はそのサービス要求されているサービスに対応したサービス別ＳＩＰサーバ６００１に、該サービス要求リクエストのフォワーディングを行う（ステップ７００６）。ここで、該サービス別ＳＩＰサーバに向けて、あらためてサービス要求メッセージをフォワーディングする方法は、例えば、前述のようにＷｅｂインタフェースとＷｅｂプロキシを利用する場合には、ＨＴＴＰのリダイレクション機能で簡単に実現できる。これ以降は、サービス別ＳＩＰサーバとユーザ端末２０Ａの間でセッション確立のやりとりが始まる。このセッションの確立に引き続く、データの転送、セッションの終了については、本発明の有効性と無関係であるのでこれ以上説明しない。受付判定の結果、サービスの提供が不能であると判定されたときには、受付判定サーバ１００１はサービスを要求したユーザの端末２０Ａに向けて、サービス提供拒否のレスポンスを返すことができる（ステップ７００７）。例えば、Ｗｅｂインタフェースのときには、ＨＴＴＰのサーバエラークラスのレスポンスのレスポンスコード５０３ＳｅｒｖｉｃｅＵｎａｖａｉｌａｂｌｅを返すことができるが、実際の方法は本発明の有効性とは無関係である。
【０１０６】
最後に、受付判定サーバ１００１は、受付判定の結果をトラヒックＤＢ２００２に登録するために、受付判定登録リクエストを送信する（ステップ７００８）。受付判定登録リクエストには該サービス要求リクエストの全てあるいは一部の情報と受付判定の可否を格納する。トラヒックＤＢ２００２は、受付判定登録リクエストを受信すると、それに格納された、該サービス要求リクエストの全てに関する情報を蓄積する。また、サービス別サーバはサービス提供が終了すると、トラヒックＤＢ２００２にサービス終了登録リクエストを送信する。トラヒックＤＢ２００２は、該サービス終了登録リクエストを受信すると、その受信時刻をトラヒックＤＢ２００２の蓄積データ中の該当サービスの提供が終了した時刻として記録し、該サービス別サーバに対して、サービス終了登録レスポンスを送信する。
【０１０７】
（ＩＰ電話サービスのサービス品質の達成について）
ＩＰ電話サービスに対して、サービス品質を保証するための方法を説明しておく。本発明は、リーキーバケットモデルによってトラヒック特性が表現されるデータストリームに対して適用可能であるので、前述のように、このトラヒック特性を有しないＩＰ電話サービスに対しては適用できない。したがって、これから説明するＩＰ電話サービスのサービス品質を保証するための方法は本発明とは無関係であるが、先の実施形態の中でＩＰ電話サービスを対象としており、これが本発明の実施対象である映像ストリーム配信サービスに対するパケット損失ゼロの達成に支障がないことを明確にする必要があるため、別途説明するものである。その内容は、固定電話網において確立された設計方法とＫａｔｓｕｙｏｓｈｉＩｉｄａ等の文献（非特許文献１０、非特許文献１１、非特許文献１２）の中で提案されているものである。ただし、本実施形態では、ＩＰ電話サービスのサービス要求に対して受付制御を行うと同時に、ＩＰ電話サービスを優先Ｑｕｅｕｅｉｎｇ制御の最優先サービスクラスとして設定する。したがって、ＩＰ電話サービスのセッション同士の干渉によるサービス品質の劣化もないし、他のサービスクラスである映像ストリーム配信サービスやベストエフォートサービスの影響もほとんど受けないことに注意する。
【０１０８】
ユーザにとっては、回線交換技術によってサービスが提供される固定電話の電話サービスと、ＩＰ網におけるパケットの転送技術によってサービスが提供されるＩＰ電話の電話サービスは本質的に同一のサービスであり、固定電話網で確立された設計方法の多くがＩＰ電話サービスにもそのまま適用可能である。特に、呼損率を満足するための設備量設計は、固定電話の場合と全く同じ考え方でよい。固定電話では回線数や各リンクのリンク速度を、それぞれの最繁時呼量と、固定電話網全体で一定の呼損率目標値から、設備量として準備すべきセッションの数、つまり、最大同時接続数を決めている。このときに用いる計算式が、有名なアーラン損失式である。この手順は、そのままＩＰ電話で適用することができる。違うのは、固定電話の１セッションは６４ｋｂｐｓで一律に換算することができるが、ＩＰ電話の１セッションは音声符号化方式やパケットフォーマットの組み合わせによってさまざまな通信速度になる点だけである。ただし、本実施形態では、１セッション８０ｋｂｐｓと決めているので、簡単に各ノード間で必要なリンク速度に換算することができる。ＭＧＷで必要なポートの数もそのＭＧＷでの最大同時接続分を準備する。このようにして、呼損率について目標値を満たす設計を行うことができる。また、本実施形態では、各リンクに対して求めた最大同時接続数を用いてサービス要求のセッションに対して受付判定を行うので、サービス品質が設計値より悪くなることは起こらない。
【０１０９】
次に、ＩＰ電話サービスの残りのサービス品質はエンドエンドでの遅延時間とそのゆらぎについて説明する。この評価方法はいろいろ考えられるが、本実施形態では以下とする。上でアーラン損失式を用いて計算した各リンクで必要なリンク速度は、呼損率を満たしたＩＰ電話サービスだけを提供するために最低限必要なリンク速度であるので、その１０倍のリンク速度をもつリンクを各ノード間で設計する。このときのエンドエンドの遅延時間とゆらぎをシミュレーションや測定値やＫａｔｓｕｙｏｓｉＩｉｄａ等の論文の理論評価式などを組み合わせて用いることにより評価することができる。
【０１１０】
このとき、評価結果の遅延時間とゆらぎの数値が、サービス品質目標値をどちらか一方でも満足しない場合は、全てのリンクのリンク速度を２倍にする。両方の目標値を満足した場合は、そのリンクのリンク速度で確定させる。この手順により、呼損率と遅延時間とそのゆらぎのサービス品質目標値を満足するＩＰ電話サービスを提供することができる。
【０１１１】
また、上のＫａｔｓｕｙｏｓｈｉＩｉｄａ等の論文の中で論じられているように、ある同時接続数のＩＰ電話サービスのセッションに対してサービス品質を保証するために、各ノードに必要なバッファ容量も同じ評価式を使って評価することができる。
【０１１２】
したがって、呼損率と遅延時間とそのゆらぎの各サービス品質の目標値を満足するようなＩＰ電話サービスを提供するために必要な各リンクのリンク速度や各ノードのバッファ容量を評価することができる。
【０１１３】
（補足）
前述のように、本実施形態では、ＩＰ電話サービスを優先Ｑｕｅｕｅｉｎｇ制御の最優先サービスクラスとして設定するために、他のサービスクラスである映像ストリーム配信サービスやベストエフォートサービスの影響をほとんど受けないが、全く影響がないわけではない。例えば、ベストエフォートサービスのパケットがルータにおいて転送処理中であるときに、ＩＰ電話サービスのパケットが到着した場合には、最優先のサービスクラスであるＩＰ電話サービスのパケットであっても、そのベストエフォートサービスのパケットの転送が終わるまでの待ち時間が発生してしまう。これをブロッキングと呼ぶが、ブロッキングの待ち時間を考慮して評価する方法が、ＫａｔｓｕｙｏｓｈｉＩｉｄａ等の論文に記載されている。さらにＩＰ電話サービスを提供するユーザ端末の一方がＰＳＴＮ網内にある場合には、ＭＧＷでの遅延ゆらぎ吸収バッファで設定する遅延時間を評価する必要があるが、上のシミュレーションやＫａｔｓｕｙｏｓｈｉＩｉｄａ等の評価式から決めることができる。
【０１１４】
なお、本発明は専用のハードウェアにより実現されるもの以外に、その機能を実現するためのプログラムを、コンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行するものであってもよい。コンピュータ読み取り可能な記録媒体とは、フロッピーディスク、光磁気ディスク、ＣＤ−ＲＯＭ等の記録媒体、コンピュータシステムに内蔵されるハードディスク装置等の記憶装置を指す。さらに、コンピュータ読み取り可能な記録媒体は、インターネットを介してプログラムを送信する場合のように、短時間の間、動的にプログラムを保持するもの（伝送媒体もしくは伝送波）、その場合のサーバとなるコンピュータシステム内部の揮発性メモリのように、一定時間プログラムを保持しているものも含む。
【０１１５】
【発明の効果】
以上説明したように本発明によると、大規模公衆向けの閉域ＩＰ網において、品質保証型サービスとしてデータストリームを転送する方法において、以下の効果が生じる。
【０１１６】
１）受付けた品質保証型サービスに対しては、そのサービス品質としてパケット損失率がゼロになることを実現できる。また、遅延時間とそのゆらぎについても、品質目標値を達成できる。特に、ここでは、ルータなどの装置の制御メカニズムが動作するための仕組み動作ではなく、その結果としてのサービス品質を確実に達成できる。
【０１１７】
２）要求されるデータストリームのトラヒック特性の申告に基づく網リソースの確保を簡素化し、その受付判定をリアルタイムに処理でき、かつ、ＵＰＣの実装が必須ではなく、しかも、効率の高い網の運用ができる。具体的には、トラヒック特性の申告は、ユーザ端末に代わってトラヒックＤＢが行うので、網リソースの確保が簡単で確実である。受付判定は、要求されたサービスの平均レートがそのサービス向けに割り当てられる速度として残っているかを調べるだけであり、従来技術のようにバースト性を評価することがないため高速に判定処理ができる。さらに基準バースト継続時間と基準バースト吸収時間の尺度で、網リソースが網全体で一定となるように設計されているため、ボトルネックが発生しにくく、網全体の平均的な利用効率が高くなっている。
【図面の簡単な説明】
【図１】本発明の一実施形態の大規模公衆向け閉域ＩＰ網の構成図である。
【図２】図１の実施形態中の品質保証型サービス用ＬＡＮ６０の構成図である。
【図３】図２のサービス別ＬＡＮ４０００および５０００を、それぞれＩＰ電話サービスと映像ストリーム配信サービスを提供する本実施形態にあわせて具体化した図である。
【図４】本実施形態の品質保証型サービスに対する受付判定を説明する図である。
【図５】バースト継続時間と周期の関係を説明するための図である。
【図６】バースト吸収時間を説明するための図である。
【図７】パケット損失ゼロの条件を説明するため図である。
【図８】リーキーバケットモデルで表現できるデータストリームを説明するための図である。
【図９】データストリームのバーストとバッファに滞留するデータ量の関係を説明するための図である。
【図１０】パケット損失ゼロの条件を説明するための図である。
【図１１】ストリーム多重によりパケット損失の発生する最悪の場合を説明するための図である。
【符号の説明】
１０大規模公衆向け閉域ＩＰ網
２０Ａ〜２０Ｊユーザ端末
３０Ａ〜３０Ｊネットワーク終端装置
４０、５０ＧＷ装置
１０１Ａ〜１０１Ｇ、２０１Ａ〜２０１Ｃルータ
１００１受付判定サーバ
２００１網構成ＤＢ
２００２トラヒックＤＢ
３００１ストリーム特性ＤＢ
３００２ストリーム特性測定装置
３００３ストリームシェーピング装置
４００１ＩＰ電話用ＳＩＰサーバ
４００２ＭＧＷ
５００１映像配信用ＳＩＰサーバ
５００２Ａ、５００２Ｂ映像配信サーバ
Ｌ２Ａ〜Ｌ２Ｊ、Ｌ３Ａ〜Ｌ３Ｊ接続リンク
Ｌ１０２ＡＢ、Ｌ１０２ＢＣ、Ｌ１０２ＢＤ、Ｌ１０２Ａ、Ｌ１０２ＥＦ、Ｌ１０２ＥＧ、Ｌ１０２ＡＣ、Ｌ１０２ＡＧ、Ｌ１０２Ａ４、Ｌ１０２Ａ５接続リンク
Ｌ２０２ＣＥ、Ｌ２０２ＣＭ、Ｌ２０２ＭＰ接続リンク

Claims

一定のバッファを有するノードとノード間のリンク速度を管理して、トラヒック特性をリーキーバケットモデルにより表現されたデータストリームの転送要求に対してパケット損失をゼロとするために、要求ごとに受付判定を行なうことを特徴とするサービス要求の受付判定方法。
要求されたデータストリームの転送の送信元と着信先が確定すると、その転送ルートが特定できる閉域網において、受付判定を行う、請求項１記載のサービス要求の受付判定方法。
トラヒック特性がリーキーバケットモデルにより表現されたデータストリームの転送サービスが映像ストリーム配信サービスである、請求項１記載のサービス要求の受付判定方法。
サービス品質を保証するデータストリームに対して、それぞれのトラヒック特性をリーキーバケットモデルで表現したときに定まる周期の集合に対して、基準バースト継続時間と呼ぶある一定値を網全体の闘値として設定し、
網のすべてのノードのバッファ容量をバースト吸収時間の尺度で基準バースト吸収時間と呼ぶ一定値以上にあらかじめ設計し、
各リンクに対して、品質保証型サービス向けに割り当てる速度の最大値を
速度の最大値＝ＭＩＮ［（リンク速度）＊（基準バースト吸収時間）／（基準バースト継続時間），（リンク速度）］
ただし、ＭＩＮ［ｘ，ｙ］は引数集合の最小値を返す関数
で管理して、そのリンクにおいて割り当てる速度の最大値と、既にサービス提供中のセッション毎の平均レートを積み上げた値と比較して、前者の方が大きいときに限り、そのサービス要求リクエストを受け付ける、請求項１から３のいずれか１項に記載のサービス要求の受付判定方法。
遅延時間とそのゆらぎの品質指標それぞれに割り当てる速度の最大値を求めておき、前記パケット損失ゼロを達成するための割り当てる速度の最大値とあわせて３つの中で、最小のものをその品質保証型サービス向けに割り当てる速度の最大値として運用し、さらに、品質保証型サービスを複数のサービスクラスで構成させるときには、各サービスクラス別に割り当てる速度の最大値を求めて、品質保証型サービスのすべてのサービスクラスそれぞれで割り当てる速度の最大値を合計しても、元のリンク速度を超えないように調整する、請求項４に記載のサービス要求の受付判定方法。
大規模公衆向けの閉域ＩＰ網において、
転送するデータストリーム毎のトラヒック特性を測定し、リーキーバケットモデルの表現を行なうために、ピークレート、平均レート、バースト継続時間の各パラメータ値を決定するトラヒック特性測定装置と、
該トラヒック特性測定装置によって測定されたデータストリームのトラヒック特性情報を蓄積し、問い合わせに応じて、データストリームのトラヒック特性情報をストリーム特性情報として回答するストリーム特性ＤＢと、
該ＩＰ網を構成するすべてのノードの網内識別子、その位置情報、通信リンクの帯域、通信リンクとノードの接続関係の情報を含む、品質保証型サービスを提供する該ＩＰ網に関する情報が蓄積されている網構成ＤＢと、
提供した品質保証型サービスを特定するサービス識別子、サービスを要求したユーザ端末の網内識別子、サービスを提供したサーバの網内識別子、サービス要求リクエストが到着した時間、サービスの受付可否判定結果、サービスの提供が開始された時刻、サービスの提供が終了した時刻あるいはサービスの提供が終了する見込みのある時刻の情報を含む、該ＩＰ網で提供する品質保証型サービスに関する情報が蓄積されているトラヒックＤＢと、
品質保証型サービスのサービス要求リクエストに対して、受付判定処理を行なう受付判定サーバであって、サービス要求リクエストが受信すると、まず、該サービス要求リクエストに要求されているサービスに対応するサービス別サーバに問い合せて、サービス内容情報を取得し、次に、前記ストリーム特性ＤＢに問い合わせて、該サービス要求リクエストに格納されている情報とトラヒック特性情報を取得し、さらに、前記網構成ＤＢに問い合わせて、発生する該データストリームの送受信ユーザ端末の網内識別子から、そのデータストリームの転送ルートと、その転送ルート上の各リンクのリンク速度を含む転送ルート情報を取得し、最後に、前記トラヒックＤＢに問い合わせて、該転送ルート上で品質保証型サービスとして現在サービス提供中のすべてのサービスに関する情報である提供中サービス情報を取得し、基準バースト継続時間と基準バースト吸収時間にもとづき転送ルート上の各リンクについて、そのリンク速度をもとに品質保証型サービス向けに割り当てる速度の最大値を計算し、これらの情報を総合して該サービス要求リクエストに要求されているサービスの受付判定を行なう受付判定サーバを有し、
該ＩＰ網を構成するネットワークノードである、ルータ、ＧＷ、ネットワーク終端装置はすべて優先Ｑｕｅｕｅｉｎｇ制御機能と前記基準バースト吸収時間以上のバッファ容量をもつバッファを有することを特徴とする閉域ＩＰ網。
前記トラヒック特性測定装置によって特定されたトラヒック特性が、該ＩＰ網で提供するすべてのサービスのサービス品質全体に対して不適切なトラヒック特性を有すると判定されたデータストリームに対して、そのデータストリームのシェーピングを行い、適切なトラヒック特性に変換するストリームシェーピング装置をさらに有する、請求項６に記載の閉域ＩＰ網。
品質保証型サービスのサービス要求リクエストに対して、受付判定処理を行なう受付判定サーバであって、
サービス要求リクエストが受信すると、まず、該サービス要求リクエストに要求されているサービスに対応するサービス別サーバに問い合わせて、サービス内容情報を取得し、データストリームのトラヒック特性情報を蓄積したストリーム特性ＤＢに問い合わせて、該サービス要求リクエストに格納されている情報とトラヒック特性情報を取得し、該ＩＰに関する情報が蓄積されている網構成ＤＢに問い合わせて、発生する該データストリームの送受信ユーザ端末の網内識別子から、そのデータストリームの転送ルートと、その転送ルート上の各リンクのリンク速度を含む転送ルート情報を取得し、最後に、該ＩＰ網で提供する品質保証型サービスに関する情報が蓄積されているトラヒックＤＢに問い合わせて、該転送ルート上で品質保証型サービスとして現在サービス提供中のすべてのサービスに関する情報である提供中サービス情報を取得する手段と、
基準バースト継続時間と基準バースト吸収時間にもとづき転送ルート上の各リンクについて、そのリンク速度をもとに品質保証型サービス向けに割り当てる速度の最大値を計算する手段と、
これらの情報を総合して該サービス要求リクエストに要求されているサービスの受付判定を行なう手段を有する受付判定サーバ。
請求項１から５記載のサービス要求の受付判定方法をコンピュータに実行させるためのプログラム。