JP3720345B2 - 伝送装置 - Google Patents

Description

本発明は、ＱｏＳ（Quality of Service）を保証してデータをネットワーク上に伝送する技術に関し、特に、ＱｏＳを保証するネットワークの伝送路上を流れるパケットを監視し、帯域を確保して伝送すべきフローを見出して帯域制御装置に帯域要求を行なう伝送装置に関する。

近年、無線ＬＡＮ（Local Area Network）等のネットワークにおいて、リアルタイム性が要求されるストリーミングデータを他のデータと同時に伝送しようという試みがなされ、実現されるようになってきている。

データはさまざまな性質を持っているため、それらが伝送される際に満たさなければならない伝送条件はデータによって異なる。例えば、ＷＷＷ（World Wide Web）やファイル転送などでは多少の伝送遅延があってもかまわないが、絶対に誤りのないことが必要とされる。

一方、映像や音声などのストリーミングデータは、制限された遅延時間の範囲内において、一定量のデータを伝送し続けなければならないというリアルタイム性が要求される。データの再生（受取り）までの遅延ができるだけ少ない方がよい。また、伝送エラーは少ないことが望ましいが、完全にエラーフリーであることが要求されるわけではない。

このように伝送特性が異なるデータを統合してＬＡＮ上に伝送させる場合には、適切なＱｏＳ制御がなされていることが必要である。すなわち、リアルタイム性が要求されるストリーミングデータについては、専用の帯域を確保して通信品質が確保された通信路（ＱｏＳ通信路）で伝送する。これをイソクロナス伝送という。それ以外のＷＷＷやファイル転送などのデータは、残りの帯域を使って送信すればよい。これをアシンクロナス伝送という。

このようなＱｏＳ制御を、データリンク層、媒体アクセスコントローラまたはＭＡＣ（Media Access Control）層においてサポートするネットワークが出てきている。たとえば、ＩＥＥＥ（the Institute of Electrical and Electronics Engineers, Inc.）８０２．１１ｅは、無線ＬＡＮ８０２．１１のＭＡＣ層を拡張したものであり、従来のＭＡＣ制御に加えてＱｏＳ制御をサポートしたものである。このＩＥＥＥ８０２．１１ｅは、ＰＣ（Personal Computer）とＡＶ（Audio Visual）機器間で共通に利用できるよう標準化が進められている。

ところで、一般にＱｏＳといっても、優先度ベースのＱｏＳ（Prioritized ＱｏＳ）とパラメータベースのＱｏＳ（Parameterized ＱｏＳ）とがある。優先度ベースのＱｏＳは、送信するフレームを４〜８段階の優先度のカテゴリーに分け、カテゴリーごとに提供するサービスの品質に差をつけることによって、優先制御を提供するものである。ＩＰ上の多くのアプリケーションは、優先度ベースのＱｏＳである。

一方、パラメータベースのＱｏＳは、指定された帯域幅や遅延時間などのパラメータを保証して伝送するＱｏＳである。ＡＶのデータやＩＥＥＥ１３９４のデータなどは、パラメータベースのＱｏＳである。

優先度ベースのＱｏＳとパラメータベースのＱｏＳとは、どちらも同時にサポートすることが可能である。時間によって、自立分散制御（衝突を前提にしたアクセス制御方式）と集中制御（衝突を発生させないアクセス制御方式）とを切り替えることによって実現可能である。

非特許文献１に記載されているように、ＱｏＳ制御をサポートするネットワークにおいては、以下に説明するような構成が一般的である。

まず、ネットワーク上に１台の帯域制御装置が存在する。帯域制御装置とは、ネットワーク上の各端末から帯域予約要求を受取り、各端末に帯域を割当てて送信機会を与える局のことである。無線ＬＡＮでは、この帯域制御装置を基地局（アクセスポイント）が担当することが多い。また、帯域制御装置のことをコーディネータとも呼ぶ。

帯域制御装置は、一定間隔で正確にビーコンを出し続け、ビーコン間隔時間を、非競合アクセス期間ＣＦＰ（Contention Free Period）と、競合アクセス期間ＣＰ（Contention Period）とに分ける。

非競合アクセス期間においては、各端末が帯域制御装置から与えられた送信機会のときにのみデータを送信するため、パケットの衝突は発生しない。帯域制御装置は、各端末に対し送信機会を与える情報を通知しなければならない。送信機会を与える方法は、基地局が端末に対し順にポーリングを発信して送信機会を通知する方法と、ビーコンにスケジューリング情報を持たせてネットワーク上の全端末にブロードキャストする方法とがある。パラメータベースのＱｏＳデータは、帯域の使用権が確定されている非競合アクセス期間で伝送されなければならない。

一方、競合アクセス期間においては、送信したい端末が媒体の空き状況を見て（キャリアセンス）、一定時間空いていれば、そこからさらにランダムバックオフと呼ばれる時間だけ待って送信を行なう。２以上の端末が同じランダムバックオフを引いた場合、パケットの衝突が生じる可能性がある。パケットが衝突したと判断されれば、パケットを再送する。競合アクセス期間では、基地局や端末がそれぞれ自立分散的にパケットを送信する。このアクセス制御方式は、ＣＳＭＡ／ＣＡ（Carrier Sense Multiple Access with Collision Avoidance）と呼ばれる。優先度ベースのＱｏＳデータは、競合アクセス期間で伝送することができる。優先度の高いデータほど、キャリアセンス後の待ち時間（フレーム送信間隔）を短くするなどの方法で、優先制御を実現している。

一般に、競合アクセス期間よりも非競合アクセス期間の方が媒体の使用効率はよい。上述したアクセス方法の違いによるものである。以下、パラメータベースのＱｏＳを中心に説明する。

ネットワーク上の各端末は、帯域制御装置に対して帯域予約要求を出すが、その際ＱｏＳパラメータを設定することができる。ＱｏＳパラメータとは、端末が送信したいデータごとに要求される伝送条件に関する情報のことであり、たとえばデータレートの平均値、データレートの最大値／最小値、許容される最大遅延時間、許容される遅延時間のジッタ（ゆらぎ）、フレームサイズの平均値などがある。

たとえば、ＩＥＥＥ８０２．１１ｅにおいては、ＱｏＳパラメータがＴＳＰＥＣ（Traffic SPECification）というパラメータ群で定量的に表されている。ＱｏＳパラメータは、端末から設定することになっているが、誰がどのようにＱｏＳパラメータを決定するかについては、ＩＥＥＥ８０２．１１ｅの仕様書には記載されていない。基本的には、それぞれのアプリケーションが必要とする伝送条件を指定することになる。ＭＡＣマネジメント・エンティティは、アプリケーションからの伝送条件の指定を受取り、それを自ネットワークに適用できるＱｏＳパラメータに変換してＱｏＳを確保する。

アプリケーションから伝送条件の指定がないと、すべてのデータは競合アクセス期間で送信されることになる。ＩＰ上のアプリケーションにおいては、映像や音声などのデータを扱うアプリケーションであっても、そのセッション開始時に伝送条件を指定せずに伝送を始めてしまうものが少なくない。現在の多くのＩＰ上のアプリケーションは、パラメータベースのＱｏＳを前提としないためである。その場合、ＱｏＳを確保しないで送信するため、映像や音声などのデータが、望ましい伝送品質を満たさずに送信されることになる。すなわち、ＱｏＳをサポートしたネットワークであっても、その機能が生かされないことになる。

また、上述したように、競合アクセス期間よりも非競合アクセス期間の方が媒体の使用効率が良いので、可能ならば非競合アクセス期間を使って送信することが望ましい。非競合アクセス期間を積極的に使うことで、ネットワーク全体のスループットの向上につながるからである。

そこで、アプリケーションから伝送条件の指定がない場合でも、何らかの機構、たとえばＭＡＣマネジメント・エンティティなどにおいて、自動的に最適なＱｏＳパラメータを生成して、ＱｏＳを確保することができないかが検討されている。これに関連する技術として、特許文献１および２に開示された発明がある。

特許文献１に開示された帯域制御装置は、ＲＴＰ（Realtime Transport Protocol）の開始フレームを検出し、ＲＴＰのセッションが開始されたことを認識し、ＲＴＰヘッダの情報から必要なＱｏＳパラメータを抽出して、帯域要求を行なうものである。

また、特許文献１は、トランスポート層プロトコル及びトランスポート層ポート番号毎のトラフィック量を測定し、その統計情報をメモリに記憶し、トラフィック量に比例した帯域を各プロトコルに割り当てるように要求する方法も開示している。

特許文献２に開示されたデータ伝送方法は、ストリームデータであるかどうかを検査し、ストリームデータと判断されればチャンネルを割り当ててデータを伝送し、ストリームデータではないと判断されれば、チャンネルを割り当てずに非同期伝送方式で伝送するというものである。
特開２００２−２４７０６７号公報 特開２０００−１３４２７８号公報 ８０２．１１高速無線ＬＡＮ教科書（ＩＤＧジャパン出版、２００３年、３月２９日、ｐｐ．６６−１２２）

しかし、データリンク層においてパラメータベースのＱｏＳ制御をサポートするネットワークがあっても、ＩＰ上のアプリケーションが、伝送条件の指定をせずに伝送を始めてしまうものが少なくないため、映像や音声などのデータを扱うアプリケーションにおいて、本来望ましい伝送品質を満たさないで伝送してしまうという問題点があった。また、伝送条件の指定をせずに伝送を始めてしまうので、すべてのデータは競合アクセス期間で送信されることになり、媒体の使用効率の低下につながるという問題点があった。

また、特許文献１に記載されている方法は、ＲＴＰにしか適用できないという問題点がある。確かに、ＲＴＰは、リアルタイム性を持つアプリケーションに標準的に使用されるプロトコルであるが、ＩＰ上のアプリケーションの中にはＲＴＰを使わないものもある。たとえば、Microsoft(R)社のWindows（Ｒ） Media Player(R)が使用するプロトコルはＴＣＰである。また、媒体の使用効率を向上させることを主眼におけば、リアルタイム性を持つアプリケーションだけでなく、ほぼ固定の帯域を持つ一般的なアプリケーションに対しても、帯域を予約してデータを伝送することが望ましい。また、一般的なアプリケーションに対応できる汎用的な構成であることも求められる。

特許文献１には、さらにトランスポート層プロトコルおよびトランスポート層ポート番号毎のトラフィック量を測定するという技術も開示されている。しかし、ストリーミングデータであることを判断する具体的な手法がないため、これだけでは有用といえない。

また、特許文献２に開示されているデータ伝送方法においては、ストリーミングデータであることを判断する手法が開示されているが、可変ビットレートのアプリケーションにうまく対応できないという問題点がある。映像や音声を固定ビットレートで圧縮する方式であるＣＢＲ（Constant Bit Rate）においては、帯域幅が長時間にわたって一定であるので、必要とされるデータレートを計算しやすい。トラフィック量を測定し、それに比例するデータレートを要求することは容易である。しかし、映像を可変ビットレートで圧縮する方式であるＶＢＲ（Variable Bit Rate）もあり、そのようなアプリケーションではデータレートが時間的に変動するので、ストリーミングデータであることを認識できない、または、データレートの平均を要求しても帯域制御装置はうまく対応できないという問題点がある。

本発明は、上記問題点を解決するためになされたものであり、第１の目的は、アプリケーションから伝送条件の指定がない場合でも、自動的に帯域を予約してデータを伝送することが可能な伝送装置を提供することである。

第２の目的は、なるべく非競合アクセス期間で送信して、媒体の使用効率を向上させることが可能な伝送装置を提供することである。

本発明のある局面に従えば、所定の品質を確保して通信を行なう伝送装置であって、伝送するデータのパケットをパケットヘッダごとに分類するための分類手段と、分類手段による分類結果に応じて、同じパケットヘッダを有するパケットの集合をパケット群として管理し、パケット群の所定の単位時間あたりのビットレートを測定するための測定手段と、パケット群のビットレートの履歴に応じて、帯域を確保して伝送すべきか否かを判断するための判断手段と、判断手段によって帯域を確保して伝送すべきであると判断されたパケット群の帯域予約を帯域制御装置に要求するための要求手段とを含む。

好ましくは、判断手段は、測定手段による測定結果から直前の所定のデータ数を対象としてビットレートのばらつきを表すパラメータを計算するための計算手段と、計算手段によって計算されたパラメータが予め設定された値以下ならば、当該パケット群を帯域を確保して伝送すべきパケット群であると判断するためのパケット判断手段とを含む。

さらに好ましくは、計算手段は、計算したパラメータが予め設定された値より大きい場合、計算の対象とするデータ数を増やして、当該パラメータを再計算し、パケット判断手段は、再計算されたパラメータの値が予め設定された値以下ならば、当該パケット群を帯域を確保して伝送すべきパケット群であると判断する。

さらに好ましくは、計算手段は、対象とするデータ数を順次増やしながら、当該パラメータが予め設定された値以下になるか、対象とするデータ数が予め決められた最大となるまで、当該パラメータの計算を繰返す。

好ましくは、判断手段は、測定手段による測定結果から、特定の帯域でパケット群を送信したときに必要となるバッファ容量を計算し、計算を帯域を変えて行ない、必要とする帯域と必要となるバッファ容量との関係を導出し、この関係から当該パケット群を帯域を確保して伝送すべきパケット群であると判断する。

好ましくは、判断手段は、要求する帯域ごとに必要となるバッファ容量の最大値を抽出し、要求する帯域と必要となるバッファ容量の最大値との関係を表わすグラフが所定領域内にあるか否かによって帯域を確保して伝送すべきパケット群であるか否かを判定する。

さらに好ましくは、判断手段は、所定領域内にある帯域を要求手段に要求させ、所定領域内にあるバッファ容量の最大値を確保するようバッファ手段に要求する。

さらに好ましくは、判断手段は、帯域を確保するために必要なコストとバッファ容量のコストとに基づいて、トータルのコストが最小となるように要求すべき帯域と確保すべきバッファ容量とを決定する。

好ましくは、判断手段が、一度帯域を確保して伝送すべきと判断したパケット群が所定の時間観測されず、もはや帯域を確保する必要がないと判断した場合、要求手段は、当該パケット群のために確保している帯域を解放することを帯域制御装置に要求する。

好ましくは、判断手段が、一度帯域を確保して伝送すべきと判断したパケット群のビットレートの特性に所定の基準以上の変化があった場合、要求手段は、当該パケット群のために確保している帯域のビットレートを最新の値に変更することを帯域制御装置に要求する。

好ましくは、判断手段が、一度帯域を確保して伝送すべきと判断したパケット群のビットレートの特性に所定の基準以上の変化があった場合、要求手段は、当該パケット群のために確保している帯域を解放することを帯域制御装置に要求する。

本発明のある局面によれば、判断手段が、分類手段による分類結果に応じて、同じパケットヘッダを有するパケットの集合をパケット群として管理し、パケット群のビットレートに応じて、帯域を確保して伝送すべきか否かを判断するので、アプリケーションから伝送条件の指定がない場合でも、自動的に帯域を予約してデータを伝送することが可能となった。

また、パケット判断手段は、計算手段によって計算されたパラメータが予め設定された値以下ならば、当該パケット群を帯域を確保して伝送すべきパケット群であると判断するので、帯域を確保して伝送すべきか否かを容易に判定することが可能となった。

また、計算手段は、計算したパラメータが予め設定された値より大きい場合、計算の対象とするデータ数を増やして、当該パラメータを再計算するので、帯域を確保して伝送すべきか否かの判定をより厳密に行なうことが可能となった。

また、計算手段は、対象とするデータ数を順次増やしながら、当該パラメータが予め設定された値以下になるか、対象とするデータ数が予め決められた最大となるまで、当該パラメータの計算を繰返すので、帯域を確保して伝送すべきか否かの判定をより厳密に行なうことが可能となった。

本発明の別の局面によれば、判断手段が、異なる帯域要求を要求手段に行なわせながら、そのときに必要となるバッファ容量を測定し、要求する帯域と必要となるバッファ容量との関係から帯域を確保して伝送すべきパケット群であるか否かを判定するので、アプリケーションから伝送条件の指定がない場合でも、自動的に帯域を予約してデータを伝送することが可能となった。

また、判断手段は、要求する帯域ごとに必要となるバッファ容量の最大値を抽出し、要求する帯域と必要となるバッファ容量の最大値との関係を表わすグラフが所定領域内にあるか否かによって帯域を確保して伝送すべきパケット群であるか否かを判定するので、帯域を確保して伝送すべきか否かを容易に判定することが可能となった。

また、判断手段は、所定領域内にある帯域を要求手段に要求させ、所定領域内にあるバッファ容量の最大値を確保するようバッファ手段に要求するので、媒体の特性やシステムの実装に応じて帯域要求およびバッファ容量の確保を行なうことが可能となった。

また、判断手段は、帯域を確保するために必要なコストとバッファ容量のコストとに基いて、トータルのコストが最小となるように要求すべき帯域と確保すべきバッファ容量とを決定するので、媒体の特性やシステムの実装に応じて最適な帯域要求およびバッファ容量の確保を行なうことが可能となった。

（第１の実施の形態）
図１は、本発明の第１の実施の形態における伝送装置の概略構成を示すブロック図である。この伝送装置１は、アプリケーションからのパケットまたは異なるネットワークからのパケットを受け、伝送装置１全体の制御を行なうサブレイヤ１０１と、無線などの媒体を介してデータの送受信を行なう媒体アクセスコントローラ１２１と、ＭＡＣマネジメント・エンティティ１３１とを含む。

媒体アクセスコントローラ１２１は、ビーコンの送受信、媒体の空き状況を見ながらのデータの送受信、ポーリング応答、ＡＣＫの生成、再送制御など、データ処理に関する制御を行なう。

ＭＡＣマネジメント・エンティティ１３１は、帯域制御装置に対する帯域要求コマンドの発行、帯域制御装置からの応答処理、媒体固有ＩＤの管理など、ＭＡＣマネジメントに関する制御を行なう。

媒体アクセスコントローラ１２１とＭＡＣマネジメント・エンティティ１３１とを合わせて、ＭＡＣ層の機能を実現している。これらによって、ＳＡＰ（Service Access Point）と呼ばれるインタフェースが上位層に提供される。

媒体アクセスコントローラ１２１は、同期データ伝送用のＭＤ＿ＩＳＯ（MAC Data Isochronous）と非同期データ伝送用のＭＤ＿ＡＳＹＮＣ（MAC Data Asynchronous）を提供する。ＭＡＣマネジメント・エンティティ１３１は、ＭＡＣ層管理用のＭＭ（MAC Management）を提供する。媒体アクセスコントローラ１２１やＭＡＣマネジメント・エンティティ１３１は、ＩＥＥＥ８０２．１１ｅなどの規格に基づくものとする。

サブレイヤ１０１は、媒体アクセスコントローラ１２１およびＭＡＣマネジメント・エンティティ１３１の上位に設けられ、フロー番号計算部１０２と、フロー番号別パケット情報記憶部１０３と、パケット情報記憶部の履歴１０４と、タイマー１０５と、ストリームデータ判断部１０６と、帯域要求コマンド生成部１０７と、パケット分類器ルール記憶部１０８と、パケット分類器１０９と、ＶＢＲ用バッファ１１０とを含む。なお、ＶＢＲ用バッファ１１０は、本実施の形態においては使用されない。

フロー番号計算部１０２は、アプリケーションからのパケットまたは異なるネットワークからのパケットを受け、パケットヘッダを抽出する。

図２は、パケットヘッダの一例であるＩＰパケットのヘッダを示す図である。ＩＰパケットのヘッダは、宛先ＭＡＣアドレスと、送信元ＭＡＣアドレスと、Ｔｙｐｅフィールドと、Ｖｅｒｓｉｏｎフィールドと、ＴＯＳ（ＩＰレベルの優先情報）フィールドと、Ｐｒｏｔｏｃｏｌフィールドと、送信元ＩＰアドレスと、宛先ＩＰアドレスと、送信元ポート番号と、宛先ポート番号とを含む。

本実施の形態においては、ＩＰパケット以外のパケットは無視するものとする。また、プロトコルはＵＤＰまたはＴＣＰを対象とするので、それ以外のパケットも無視する。アプリケーションごとのフローを監視したいので、ＵＤＰ／ＴＣＰのポート番号も含めるものとする。

パケットヘッダは、アプリケーションを特定できるまでのフィールドを含めることが望ましいが、必ずしも図２の通りでなくてもよい。簡易的にＥｔｈｅｒｎｅｔ（Ｒ）のアドレスのみを対象としてもよいし、パケットをさらに分析して、たとえばＩＥＥＥ８０２．１Ｄで規定されているプライオリティ値、ＩＥＥＥ８０２．１Ｑで規定されているＶＬＡＮ（Virtual LAN）フィールドなどを含めてもよい。アプリケーションからのパケットまたは異なるネットワークからのパケットの種類に応じて、対象とするパケットヘッダを適切に設定する。

フロー番号計算部１０２は、パケットヘッダをバイト列としてハッシュコードを計算する。ハッシュコードとは、データから一意に計算される固定長の値である。ハッシュコードを比較することによって、パケットの識別を高速化できる。

図３は、ハッシュコードの計算方法の一例を示す図である。図３（ａ）は、ヘッダの各バイトを順次加算してハッシュコードを算出する処理を示している。また、図３（ｂ）は、図３（ａ）に示す処理によって計算されたハッシュコードの下位８ビットを抽出してフロー番号を算出する処理を示している。

図３（ａ）に示す処理によって得られたハッシュコードは３２ビットであるので、その下位８ビットを取り出し、それをフロー識別番号とする。パケットは、フロー識別番号別に０〜２５５に分類される。このフロー識別番号はパケットヘッダの縮約形と考えてよい。フロー識別番号が異なるパケットは異なるパケットヘッダを持つと言えるが、その逆は正しくない。すなわち、パケットヘッダが異なるパケットでも同一のフロー識別番号を持つことがある。

図４は、フロー番号別のポインタ配列を示す図である。フロー番号計算部１０２は、フロー識別番号別に２５６個のポインタを有している。ポインタの初期値はすべてｎｕｌｌである。ポインタの参照先がｎｕｌｌであれば、そのフロー識別番号に対応するパケットが到着していないことを示す。ポインタの参照先がｎｕｌｌでなければ、そのフロー識別番号に対応するパケットが到着していることを示す。

ポインタの参照先には、後述するようにパケットヘッダなどの情報が記録される。これらの情報は、セルの単位で管理される。たとえば、図４においてはフロー識別番号０に対応するパケットは到着していない。また、フロー識別番号１に対応するパケットは１種類だけ到着しており、その情報がセル（Ａ）に記録されている。また、フロー識別番号１９６に対応するパケットは２種類到着しており、それぞれの情報がセル（Ｃ）およびセル（Ｄ）に記録されている。

図５は、ポインタの参照先に情報が記録されるセル構造の一例を示す図である。このセル構造は、パケットヘッダと、先頭パケット到着時刻と、最終パケット到着時刻と、合計パケット長と、パケット数と、次ポインタとを含む。次ポインタを含めるのは、異なるパケットヘッダを有するパケットが、同一のフロー識別番号を有する場合でも、次ポインタをたどっていくことで、異なるパケットヘッダのパケットを区別して処理できるようにするためである。次ポインタの初期値は、ｎｕｌｌである。次ポインタがｎｕｌｌであれば、同じフロー識別番号で異なるパケットヘッダを持つパケットが存在しないことを示す。次ポインタがｎｕｌｌでなければ、同じフロー識別番号で異なるパケットヘッダを持つパケットが他にも存在することを示す。なお、合計パケット長、パケット数の初期値は０である。

図６は、フロー番号計算部１０２の処理手順を説明するためのフローチャートである。パケットが到着すると、フロー番号計算部１０２は、まず図３に示す処理を用いて、パケットヘッダからフロー識別番号を計算する（Ｓ１０１）。そして、ｐにフロー識別番号別のポインタを代入する（Ｓ１０２）。

次に、フロー番号計算部１０２は、ｐがｎｕｌｌであるか否か判断する（Ｓ１０３）。ｐがｎｕｌｌであれば（Ｓ１０３，Ｙｅｓ）、新しいセルを１つ用意して、フロー識別番号別のポインタまたはセルの次ポインタ（Ｓ１０９から来た処理の場合）にそのセルのアドレスを記録する（Ｓ１０４）。そして、セルに、到着したパケットのパケットヘッダ、先頭パケット到着時刻、合計パケット長を記録し、パケット数に１を代入して（Ｓ１０５）、処理を終了する。

また、フロー番号計算部１０２は、ｐがｎｕｌｌでなければ（Ｓ１０３，Ｎｏ）、ｐが参照しているセルの情報を取得し（Ｓ１０６）、到着したパケットのパケットヘッダと、セルのパケットヘッダとが一致するか否か判断する（Ｓ１０７）。パケットヘッダが一致していれば（Ｓ１０７，Ｙｅｓ）、そのセルに最終パケット到着時刻および合計パケット長を記録し、パケット数をインクリメントして（Ｓ１０８）、処理を終了する。

また、パケットヘッダが一致していなければ（Ｓ１０７，Ｎｏ）、ｐにセルの次ポインタを代入し（Ｓ１０９）、ステップＳ１０３に戻る。

図７は、パケット情報記憶部１０３に記憶されるセルの情報を、一定周期でパケット情報記憶部の履歴１０４にコピーする処理の手順を説明するためのフローチャートである。この処理は、タイマー１０５が所定時間を計時する毎にパケット情報記憶部１０３によって実行されるものとする。

まず、パケット情報記憶部１０３は、変数ｉに０を代入し（Ｓ２０１）、ｐにフロー番号ｉのポインタを代入する（Ｓ２０２）。そして、ｐがｎｕｌｌであるか否かを判断する（Ｓ２０３）。

ｐがｎｕｌｌであれば（Ｓ２０３，Ｙｅｓ）、変数ｉをインクリメントし、インクリメントした値が２５６未満ならば（Ｓ２０４，Ｙｅｓ）、ステップＳ２０２へ戻って以降の処理を繰返す。また、インクリメントした値が２５６以上であれば（Ｓ２０４，Ｎｏ）、処理を終了する。

ｐがｎｕｌｌでなければ（Ｓ２０３，Ｎｏ）、ｐが参照しているセルの情報を抽出し（Ｓ２０５）、参照しているセルのパケットが一定時間来ていないか否かを判断する（Ｓ２０６）。パケットが一定時間来ていないか否かは、最終パケット到着時刻と現在時刻から判断する。パケットが一定時間来ていなければ（Ｓ２０６，Ｙｅｓ）、当該セルを削除する（Ｓ２０７）。

図８は、セルの削除を説明するための図である。フロー番号４１に対応するセルはセル（Ｂ）のみであるので、セル（Ｂ）を削除する場合はフロー番号４１のポインタをｎｕｌｌとする。また、フロー番号１９６に対応するセルはセル（Ｃ）およびセル（Ｄ）であるので、セル（Ｃ）を削除する場合はフロー番号１９６のポインタ参照先をセル（Ｄ）に設定する。このように、削除されたセルを参照している（フロー番号別のポインタなど）ポインタ参照先を削除されたセルの次ポインタに設定する。最終パケット到着時刻が一定時間以上更新されていなければ、該当するフローはなくなったものとして、そのセルを削除する。削除されたセルは、後に再利用される。

パケットが一定時間以内に来ていれば（Ｓ２０６，Ｎｏ）、参照しているセルの内容をパケット情報記憶部の履歴１０４へコピーする（Ｓ２０８）。パケット情報記憶部の履歴１０４にはすべてのフローについて、ビットレートを長く保存するのに十分な量のメモリがあるものとする。

次に、パケット情報記憶部１０３は、セル内の合計パケット長とパケット数をクリアし（Ｓ２０９）、ｐにセルの次ポインタを代入し（Ｓ２１０）、Ｓ２０３に戻って以降の処理を繰返す。

図９は、パケット情報記憶部の履歴１０４の内容の一例を示す図である。本実施の形態においては、直前のデータ４０００ｍｓ分を計算の対象とする。図９に記載されているのはその一部である。Ｆ３，Ｆ４は、パケットヘッダ別に分類されたフローを示しており、単位時間（２０ｍｓ）当りの合計パケット長（バイト数）が順次記憶される。なお、タイマー１０５で起動される間隔は、ＭＡＣのビーコン周期に合わせている。

ストリームデータ判断部１０６は、パケット情報記憶部の履歴１０４から直近の所定のデータ数（単位時間当りの合計パケット長）を読み出し、統計量を計算する。統計量には、式（１）〜（３）に示すように平均値ｍ（ｘ）、標準偏差σ（ｘ）、標準偏差を平均で割った変動係数ｖが含まれる。変動係数ｖは、母集団の平均値の大小にかかわらず、相対的な標準偏差になることが知られている。流量のばらつきを見るには、流量の大小に依存しない変動係数を用いるのがよい。変動係数ｖが小さいほどばらつきは少なく、変動係数ｖが大きいほどばらつきが大きいことを示している。

ストリームデータ判断部１０６は、変動係数が設定された値以下ならば、そのフローがストリームデータであると判断する。たとえば、変動係数が０．３以下ならばストリームデータであると判断する。変動係数と比較するしきい値は、パラメータとして設定できるようにしておく。

また、変動係数が予め設定された値より大きい場合、ストリームデータ判断部１０６は、パケット情報記憶部の履歴１０４から取り出すデータ数（単位時間当りの合計パケット長）を増やして、変動係数を再計算するようにしてもよい。

また、変動係数が予め設定された値より大きい場合、ストリームデータ判断部１０６は、パケット情報記憶部の履歴１０４から取り出すデータ数（単位時間当りの合計パケット長）を順次増やしながら、変動係数の計算を繰返してもよい。この場合、取り出すデータ数が予め定められた最大となるまで計算を繰返し、変動係数が予め設定された値以下とならなければ、そのフローがストリームデータではないと判断する。

図１０は、フロー別の統計量の計算結果の一例を示す図である。Ｆ３のフローは変動係数が１を超えておりばらつきが大きい。したがって、Ｆ３はストリームデータではないと判断される。また、Ｆ４のフローは変動係数が約０．２であり、ばらつきが少ないことがわかる。したがって、Ｆ４はストリームデータであると判断される。

ストリームデータ判断部１０６は、最大値／平均値も計算するようにしてもよい。この値は、ピークレートが平均値からどれだけ乖離しているかを示す。ピークレートが一時的に非常に大きくなると、帯域を確保してもうまく伝送できない。そのため、最大値／平均値を計算して、その値があまり大きくないことを確認する。

ストリームデータ判断部１０６は、フローがストリームデータであると判断すれば、ＱｏＳパラメータを決定して、帯域要求コマンド生成部１０７にそれを通知する。

帯域要求コマンド生成部１０７は、ＭＡＣマネジメント・エンティティ１３１を介して、帯域制御装置に帯域要求コマンドを発行する。その際、要求するＱｏＳパラメータを指定することができる。ＱｏＳパラメータには、要求する帯域の最小値／平均値／最大値、フレームサイズの平均値、最大遅延時間、ジッタなどを指定する。ここでは、以下のように指定する。

要求する帯域の最小値は、測定したビットレートの平均値とするか、よりロバストな代表値である中央値（メディアン）や最頻値（モード）とする。また、要求する帯域の平均値は、測定したビットレートの平均値をベースに、標準偏差σに比例した分を加える。すなわち、（ａｖｅｒａｇｅ＋ｋ１＊σ）とする。

また、要求する帯域の最大値は、測定したビットレートの最大値とするか、測定したビットレートの平均値をベースに、標準偏差σに比例した分を加える。すなわち、（ａｖｅｒａｇｅ＋ｋ２＊σ）とする。なお、ｋ１＜ｋ２とする。要求する帯域の計算方法は一例であって、他の統計量を組み合わせて計算してもよい。フレームサイズの平均値は、測定したパケット合計長をパケット数で割ることにより計算する。

許容される最大遅延時間および許容される遅延時間のジッタ（ゆらぎ）については、パケットの種類が特定できない限り設定することはできない。本実施の形態においては、オプションで以下のような処理を行なう。

パケットの種類がＡＶストリームならば最大遅延時間３００ｍｓ、ＶｏＩＰならば最大遅延時間１０ｍｓ、オーディオストリームならば最大遅延時間１００ｍｓといったように予め最大遅延時間を決めておく。もし、ＲＴＰパケットであることがわかれば、ＲＴＰのペイロードタイプを見てパケットの種類を知ることができる。

ＲＴＰパケットであるかどうかは、ＲＴＰのヘッダの規則性を見て判定することができる。ＲＴＰのペイロードタイプとアプリケーションのマッピングはＲＦＣ１８９０で規定されている。たとえば、ペイロードタイプ＝０ならば、タイプの定義はＩＴＵ−Ｔ Ｇ．７１１であり、パケットの種類はＶｏＩＰであることがわかる。パケットの種類がわかれば、決めうちの最大遅延時間を設定することは可能である。

また、ＲＴＰパケットでなくても、パケットの到着間隔やパケット長などからパケットの種類を推定することもできる。たとえば、パケットの到着間隔が２０ｍｓ、パケット長が２００バイト程度で固定されているときは、ＶｏＩＰであると推定できる。このように、パケットのプロトコルが識別できる場合や、パケットの到着間隔からパケットの種類を推定して、決めうちの最大遅延時間を設定することができる。しかし、常にパケットの種類を特定できるわけではなく、パケットの種類が特定できなければ、最大遅延時間やジッタのパラメータは設定しない。

図１１は、端末１と帯域制御装置２との間で、帯域要求コマンドの発行と受付が行われる様子を示す図である。帯域要求コマンド生成部１０７は、ＱｏＳパラメータを指定し、ＭＡＣマネジメント・エンティティ１３１を介して、帯域制御装置２に帯域要求コマンドを発行する。

帯域制御装置２は、ＭＡＣマネジメント・エンティティ２０１を介して帯域要求コマンドを受けると、現在の帯域の割当状態を見て、新しい帯域要求コマンドが受け入れ可能であるか否かを判断する。受け入れ可能か否かは、ＭＡＣマネジメント・エンティティ１３１へ通知される。この時、帯域制御装置２からストリームＩＤが通知される。受け入れ可能であれば、ＭＡＣマネジメント・エンティティ１３１は、帯域要求コマンド生成部１０７へその旨通知する。

帯域要求コマンド生成部１０７は、ＭＡＣマネジメント・エンティティ１３１から受入可能である旨、およびストリームＩＤを受けると、パケット分類器ルール記憶部１０８に、パケットヘッダとストリームＩＤとの組を保存する。

図１２は、パケット分類器ルール記憶部１０８に保存されるルールの一例を示す図である。パケットヘッダとストリームＩＤとの組は、パケット分類器記憶部１０８に最低限保存される。より汎用的に、優先度やバッファ容量を保存するようにしてもよい。これらはオプションである。優先度は、ルールが適用される順番に影響を与える。また、バッファ容量は、そのフローが必要としているＶＢＲ用バッファ１１０の容量を示す。

パケット分類器ルール記憶部１０８に保存されるルールは、帯域要求コマンド生成部１０７が保存するもの以外に、サブレイヤ１０１の中で暗黙的に作成されるようにしてもよいし、より上位の層から明示的に指定できるようにしてもよい。

パケット分類器１０９は、パケット分類器ルール記憶部１０８に保存されているルールに基づきパケットを分類する。パケット分類器１０９は、パケットが到着するごとに、パケット分類器ルール記憶部１０８に保存されているルールを順に適用して、パケットヘッダがルールの条件に合致すれば、そのパケットがストリームデータであると判断する。

パケットがストリームデータであれば、パケット分類器１０９は、ＭＤ＿ＩＳＯを介してデータを伝送する（イソクロナス伝送）。また、ストリームデータでなければ、パケット分類器１０９は、ＭＤ＿ＡＳＹＮＣを介してデータを伝送する（アシンクロナス伝送）。

また、パケット分類器１０９は、パケット分類器ルール記憶部１０８にストリームＩＤが格納されているので、パケットヘッダの先頭などにストリームＩＤを追加する処理を行なうようにしてもよい。パケットヘッダにストリームＩＤが追加されれば、媒体アクセスコントローラ１２１は、そのストリームＩＤを見ることにより簡単にパケットを分類することができるため、媒体アクセスコントローラ１２１の回路構成を簡単にすることができる。さもなければ、媒体アクセスコントローラ１２１は、再度パケットヘッダを見てパケットの分類を行なわなければならない。

ストリームデータ判断部１０６は、フローがなくなったことを検出すると、帯域要求コマンド生成部１０７に帯域解放要求コマンドを発行するように通知する。フローがなくなったか否かは、フロー番号別パケット情報記憶部１０３から情報が来なくなったことで判断する。

帯域要求コマンド生成部１０７は、ＭＡＣマネジメント・エンティティ１３１を介して帯域制御装置２に帯域解放要求コマンドを発行する。帯域制御装置２は帯域解放要求コマンドを受け付け、解放された帯域のストリームＩＤをＭＡＣマネジメント・エンティティ１３１へ通知する。帯域要求コマンド生成部１０７は解放された帯域のストリームＩＤを受けると、パケット分類器ルール記憶部１０８に保存されているパケットヘッダとストリームＩＤとの組を削除する。

図１３は、本発明の第１の実施の形態における伝送装置を含んだネットワークシステムの構成例を示す図である。図１３（ａ）は、無線ＬＡＮのインフラストラクチャモードで一般的な構成である。本実施の形態における伝送装置は端末Ａ〜Ｃに含まれ、ＬＡＮ３に接続される、無線ＬＡＮのアクセスポイントが帯域制御装置２を担当することが多い。

また、図１３（ｂ）は、本実施の形態における伝送装置が、無線ＬＡＮのアドホックモードまたは他のネットワーク４および５のブリッジとして使われるような構成である。ネットワーク６に接続された端末Ａおよび端末Ｂのいずれか１台が帯域制御装置２になる。ネットワーク上に帯域制御装置２は１台だけ存在する。帯域制御装置２は、予め決まっていることもあるし、動的に決まることもある。

本実施の形態においては、ＱｏＳをサポートしたネットワークを対象としており、ネットワークの媒体が無線であれば、ＩＥＥＥ８０２．１１ｅ、ＵＷＢ（Ultra Wide Band）、Ｈｉ−ＳＷＡＮ、ワイヤレス１３９４などである。また、有線であれば、ツイストペアケーブル、電力線、同軸、光ファイバーなどの媒体で、かつＱｏＳをサポートしたネットワークである。

図１４は、一般的な帯域制御装置２の帯域割当方法を示す図である。帯域制御装置２は、ビーコンを一定間隔で正確に発信する。ビーコン間隔時間は、媒体や実装によって異なるが、一般的に５ｍｓから１００ｍｓ程度である。帯域制御装置２は、ビーコン間隔を非競合アクセス期間と競合アクセス期間とに分ける。帯域を確保して伝送するデータは、非競合アクセス期間で伝送される。

図１４においては、非競合アクセス期間でフローＡ、フローＢおよびフローＣが伝送される。非競合アクセス期間では、各端末が送信するタイミングが決められており、衝突は発生しない。競合アクセス期間では、上述したように送信したい端末がキャリアセンスをしてランダムバックオフの時間だけ待って送信する方式であるため、２以上の端末でランダムバックオフの時間が一致すれば衝突が発生する可能性がある。

以上説明したように、本実施の形態における伝送装置によれば、ストリームデータ判断部１０６が、フローがストリームデータであると判断した場合、実測したビットレートなどからＱｏＳパラメータを生成し、帯域要求コマンド生成部１０７に帯域要求コマンドを発行させるようにしたので、アプリケーションから伝送条件の指定がない場合でも、自動的に最適なＱｏＳパラメータを生成して帯域を予約することが可能となった。

また、ストリームデータ判断部１０６によってフローがストリームデータであると判断された場合、非競合アクセス期間にデータが伝送されるようになり、媒体の使用効率を向上させることが可能となった。

また、ストリームデータのようなリアルタイム性が要求されるアプリケーションだけでなく、固定の帯域を持つ一般的なアプリケーションに対しても、帯域を予約して伝送できるようになり、さらに媒体の使用効率を向上させることが可能となった。

（第２の実施の形態）
本発明の第１の実施の形態において説明した伝送装置は、固定ビットレートのアプリケーションに対して有効であるが、可変ビットレートのアプリケーションに対して有効でない場合もある。本発明の第２の実施の形態における伝送装置は、可変ビットレートのアプリケーションに対して適用できるようにしたものである。

本発明の第２の実施の形態における伝送装置は、第１の実施の形態における伝送装置と比較して、ＶＢＲ用バッファ１１０を追加した点およびストリームデータ判断部１０６の機能が異なる点のみが異なる。したがって、重複する構成および機能の詳細な説明は繰返さない。なお、本実施の形態におけるストリームデータ判断部の参照符号を１０６’として説明する。

図１５は、ビットレートの変動をＶＢＲ用バッファ１１０で吸収する場合の概念を説明するための図である。図１５に示すように、サブレイヤ１０１に入力されるアプリケーションからのパケットまたは伝送路上のパケットのビットレートが時間的に変動しても、パケット分類器１１０が伝送路に流れるビットレートに適当な上限を指定してパケットの伝送を制御することにより、ＶＢＲ用バッファ１１０でビットレートの変動を吸収する。ビットレートが一時的に上昇しても、伝送しきれないパケットがＶＢＲ用バッファ１１０に蓄積されるので、伝送路に流れるビットレートを調整することができる。

図１６は、ビットレートが変動する場合のフローの一例を示す図である。第１の実施の形態において説明した方法で変動係数を計算すると、変動係数が１を超えてしまい、ストリームデータと判断されない。

ストリームデータ判断部１０６’は、第１の実施の形態で説明したようなばらつき具合を計算するのではなく、ＶＢＲ用バッファ１１０でビットレートの変動を吸収することを前提に、要求する帯域と必要なバッファ容量との関係を求める。すなわち、要求する帯域をいくらにすれば、必要なバッファ容量がいくらになるかをシミュレートする。

まず、ストリームデータ判断部１０６’は、直近の指定された時間分（たとえば、１０００ｍｓ間）のパケット合計長の平均（ａｖｅｒａｇｅ）を求める。次に、単位時間あたりに出て行くバイト数（ｃｏｕｔ）を仮決定して、必要なバッファ容量がいくらになるかを計算する。単位時間あたりに出て行くバイト数は、パケット合計長の平均より少し大きな値とする（ｃｏｕｔ＝ａｖｅｒａｇｅ×α、α＞１．０）。

図１７は、単位時間あたりに出て行くデータのバイト数を指定して、バッファにどれだけのデータ（バイト数）が残るかを計算する方法を説明するための図である。図１７に記載されているのは一部である。図１７において、ｔｉｍｅは、ある時点からの経過時間を示し、２０ｍｓ間隔となっている。ｉｎは、単位時間あたりにバッファに入るデータのバイト数（Ａ_ｎ）を示す。ｏｕｔは、単位時間あたりにバッファから出て行くデータのバイト数（Ｂ_ｎ）を示す。ｂｕｆｆｅｒは、バッファに残るデータのバイト数（Ｃ_ｎ）を示す。

単位時間あたりに入力されるデータのバイト数（実際の測定結果）をＡ_ｎ、単位時間あたりに出て行くデータのバイト数をＢ_ｎ、バッファに残るデータのバイト数をＣ_ｎとすると、Ｂ_ｎおよびＣ_ｎは次式によって求められる。なお、添え字ｎは、単位時間の経過カウントを示す。

Ｂ_ｎ＝ＭＩＮ（Ｃ_ｎ−１＋Ａ_ｎ，ｃｏｕｔ） …（４）
Ｃ_ｎ＝Ｃ_ｎ−１＋Ａ_ｎ−Ｂ_ｎ（Ｃ_０＝０） …（５）
ａｖｅｒａｇｅはＡ_ｎの平均である。ｃｏｕｔをａｖｅｒａｇｅより少し大きな値に仮決定してＢ_ｎ，Ｃ_ｎを計算する。

図１８は、バッファに残るデータのバイト数（Ｃ_ｎ）の変化を示す図である。図１８を見ると、バッファに残るデータのバイト数は、ある範囲内に収まっていることがわかる。必要なバッファ容量は、バッファに残るデータのバイト数の最大値（ｍａｘ＿ｂｕｆｆｅｒ）で判断する。

図１７においては、ａｖｅｒａｇｅ＝２５８８である。ｃｏｕｔ＝２６３０と仮決定して計算すると、ｃｏｕｔ／ａｖｅｒａｇｅ＝１．０１６２５８、ｍａｘ＿ｂｕｆｆｅｒ＝１５２１５、ｍａｘ＿ｂｕｆｆｅｒ／ａｖｅｒａｇｅ＝５．８７９２２８となる。

ストリームデータ判断部１０６’は、単位時間あたりに出て行くバイト数（ｃｏｕｔ）を変化させて、上述した計算を繰返す。すなわち、単位時間あたりに出て行くバイト数（帯域制御装置に要求する帯域）を順次変化させることにより、バッファに残るデータのバイト数の最大値（必要なバッファの容量）がどのように変化するかを調べる。

図１９は、要求する帯域と必要なバッファの容量との関係を示す図である。図１９から、要求する帯域と必要なバッファの容量とが、トレードオフの関係にあることがわかる。図１９は、α（＝ｃｏｕｔ／ａｖｅｒａｇｅ）を１．０１から１．４０まで０．０１刻みで変化させたときのβ（ｍａｘ＿ｂｕｆｆｅｒ／ａｖｅｒａｇｅ）の値を示している。ｃｏｕｔ／ａｖｅｒａｇｅとｍａｘ＿ｂｕｆｆｅｒ／ａｖｅｒａｇｅとの関係は、ほぼ反比例の関係にあることがわかる。シミュレーションの結果、このようなトレードオフの関係はさまざまなフローについて成り立つことがわかった。

ｃｏｕｔ／ａｖｅｒａｇｅとｍａｘ＿ｂｕｆｆｅｒ／ａｖｅｒａｇｅとは、ほぼ反比例の関係にあるので、上述した計算を何度も行なう必要はない。たとえば、αのある２点だけを計算して、その他は補間するという方法をとってもよい。たとえば、α＝１．１とα＝１．３の時だけ上述した計算を行なう。そして、ｃｏｕｔ／ａｖｅｒａｇｅとｍａｘ＿ｂｕｆｆｅｒ／ａｖｅｒａｇｅとの積を計算し、その平均値を算出する。αを変化させた時の、ｍａｘ＿ｂｕｆｆｅｒ／ａｖｅｒａｇｅの値は、積の平均値／αで推定する。実際に計算すると、上述した計算を何度も行なうことになり時間がかかるので、この補間の方法は有益である。

図１９に示すトレードオフ曲線から、帯域を確保して伝送すべきデータかどうかを判断する。判断する基準として２つの要素を考慮しなければならない。

１つ目は、要求する帯域の上限である。帯域を確保して伝送することで、媒体の使用効率を高めることを考えると、ビットレートの平均値と比べてあまりに過剰な帯域を要求することに意味はない。帯域を確保して伝送することで、媒体の使用効率がかえって悪くなってはいけない。したがって、ｃｏｕｔ／ａｖｅｒａｇｅの上限は自然と決まることになる。これは、媒体の伝送方式や媒体アクセスコントローラの実装に依存すると考えられる。本実施の形態においては、ｃｏｕｔ／ａｖｅｒａｇｅの上限を１．２とする（図１９の１点鎖線）。

２つ目は、バッファの容量と遅延との問題である。バッファにデータを蓄積して伝送するということは、その分だけ遅延が発生する。ｍａｘ＿ｂｕｆｆｅｒ／ａｖｅｒａｇｅ×単位時間は、バッファで待たされる最大遅延時間を表している。したがって、最大遅延時間は妥当なものでなければならない。本実施の形態においては、最大遅延時間を１００ｍｓとする。単位時間を２０ｍｓとしているので、ｍａｘ＿ｂｕｆｆｅｒ／ａｖｅｒａｇｅの上限を５．０と設定する（図１９の点線）。また、実際にバッファの容量が確保できるかどうか確認することも必要である。バッファの容量は、ｍａｘ＿ｂｕｆｆｅｒで与えられる。

これらの２つの上限をトレードオフ曲線に重ねる。図１９においては、ｃｏｕｔ／ａｖｅｒａｇｅの上限を１点鎖線で、ｍａｘ＿ｂｕｆｆｅｒ／ａｖｅｒａｇｅの上限を点線で示す。トレードオフ曲線が１点鎖線と点線とで囲まれた領域内に存在すれば、すなわち、２つの上限の制約条件を同時に満足する点があれば、帯域を確保して伝送すべきデータであると判断する。実際には、まずｃｏｕｔを上限にまで設定して、ｍａｘ＿ｂｕｆｆｅｒを計算する。ｍａｘ＿ｂｕｆｆｅｒが上限を超えていれば、ストリームデータではないと判断する。ｍａｘ＿ｂｕｆｆｅｒが上限におさまっていれば、ストリームデータであると判断し、最適な点を調べるためトレードオフ曲線を計算する。

一般的なストリームデータであれば、図１９に示すトレードオフ曲線のように、縦軸、横軸とも妥当な範囲に収まる。逆に、バースト性を持つトラフィックについてのトレードオフ曲線を描くと、縦軸または横軸が妥当な範囲に収まらない（たとえば、ｍａｘ＿ｂｕｆｆｅｒ／ａｖｅｒａｇｅが１００を超える等）。以上の事実は、シミュレーションすると明らかであるが、机上の推論でも容易に理解できる。

帯域を確保して伝送すべきデータであると判断されれば、２つの上限の制約条件を同時に満足するいずれか１点を取り出し、必要なバッファ容量を計算する。必要なバッファ容量は、ｍａｘ＿ｂｕｆｆｅｒに比例定数ｋ（ｋ＞１）を乗じたものとする。

ストリームデータ判断部１０６’は、パケット分類器１０９に必要なバッファ容量を確保するように要求する。パケット分類器１０９が必要なバッファ容量の確保に成功すれば、ストリームデータ判断部１０６’は、帯域を要求するよう帯域要求コマンド生成部１０７に通知する。

帯域要求コマンド生成部１０７は、帯域制御装置２に対して帯域要求コマンドを発行する。帯域要求コマンド生成部１０７は、帯域制御装置２から受け入れ可能のメッセージを受けると、パケット分類器ルール記憶部１０８に、パケットヘッダとストリームＩＤとを通知し、合わせてフローが必要なバッファ容量も通知する。バッファ容量は、ＶＢＲ用バッファ１１０のためのものである。

パケット分類器１０９は、パケットが到着するごとに、パケット分類器ルール記憶部１０８に保存されているルールを順に適用する。パケットヘッダが条件に一致していれば、ストリームデータであると判断してＭＤ＿ＩＳＯを介してデータ伝送するが（イソクロナス伝送）、バッファ容量が指定されていれば、ＶＢＲ用バッファ１１０を介して伝送路に流れるデータのビットレートを調整する。

次に、トレードオフ曲線上で、２つの上限の制約条件を同時に満足する点のうち、どの点を選ぶべきかについて説明する。

図２０は、トレードオフ曲線上の最適な点の抽出方法の一例を示す図である。抽出方法として３つ考えられる。できるだけ要求する帯域を少なくさせることを重要視すると、図２０のＡが最適な点となる。

また、できるだけバッファ容量を少なく（遅延を少なく）させることを重要視すると、図２０のＢが最適な点となる。

また、トータルのコストを最小とする考え方もある。伝送路の帯域のコストをＣ_α、バッファ容量（遅延）のコストをＣ_βとする。Ｃ_α・α＋Ｃ_β・βが最小となる点を選ぶ。伝送路の帯域のコストがバッファ容量（遅延）のコストと比べて非常に高い場合（Ｃ_α＞＞Ｃ_βのとき）、図２０のＡが最適な点となる。

バッファ容量（遅延）のコストが伝送路の帯域のコストと比べて非常に高い場合（Ｃ_β＞＞Ｃ_αのとき）、図２０のＢが最適な点となる。それ以外の時、図２０のＣが最適な点となる。傾き−Ｃ_α／Ｃ_βの直線がトレードオフ曲線と接する点を求めることにより、最適な点を求めることができる。

どちらを優先するかは、媒体の特性やシステムの実装によって異なるので、最適な点を調整できるようにしておくとよい。２つの上限、すなわち要求する帯域の上限と、バッファの容量（遅延の上限）とをパラメータとして与えられるようにする。また、コスト係数もパラメータとして与えられるようにする。

ここでいうコストとは概念的なものとして導入されたもので、一般的に使われるコストの意味に限定されるものではない。要求する帯域とバッファの容量（遅延）とのトレードオフの関係において、最適な点を選ぶために利用されるべきものである。

以上説明したように、本実施の形態における伝送装置によれば、ＶＢＲ用バッファ１１０によってデータのビットレートの変動を吸収し、ストリームデータ判断部１０６’が、要求する帯域と必要なバッファの容量との関係から帯域を確保して伝送すべきデータであるか否かを判断するようにしたので、アプリケーションから伝送条件の指定がない場合でも、必要に応じて帯域を予約することが可能となった。

また、伝送路の帯域のコストとバッファ容量のコストとから、要求する帯域と必要なバッファの容量とを決定するようにしたので、トータルのコストが最小となるように帯域要求および必要なバッファ容量の確保を行なうことが可能となった。

以上が本発明における実施の形態の説明であるが、帯域を確保して伝送を始めた後も当該パケット群のビットレートの測定を続け、第１の実施の形態のストリームデータ判断部１０６および第２の実施の形態のストリームデータ判断部１０６’でストリームデータの判断に必要な計算を続けるものとする。当該パケット群のビットレートの特性が変化していないか否かを確認して、変化していればそれに応じた処理を行なう。以下の３つの場合が考えられる。

１つ目は、当該パケット群が所定の時間観測されなくなった場合である。ストリームデータ判断部１０６（１０６’）は、帯域要求コマンド生成部１０７に、当該パケット群のために確保している帯域を解放するよう通知する。帯域要求コマンド生成部１０７は、帯域解放の通知を受けると、まずパケット分類器ルール記憶部１０８に対して、当該パケット群のパケットヘッダとストリームＩＤとの組を削除する。次に、ＭＡＣマネジメント・エンティティ１３１を介して、帯域制御装置に帯域解放コマンドを発行して、その返答を受信する。帯域解放コマンドの返答は常に成功であると期待できる。

２つ目は、当該パケット群のビットレートの特性が変動し、ストリームデータ判断部１０６（１０６’）が当該パケット群を依然としてストリームデータであると判断した場合である。ストリームデータ判断部１０６（１０６’）は、帯域変更が必要かどうかを判断し、帯域変更が必要と判断されればＱｏＳパラメータを生成し、帯域要求コマンド生成部１０７に、当該パケット群のために確保している帯域を最新の値に変更するよう通知する。帯域変更が必要の場合とは、例えば直近のビットレート測定単位時間で測定したビットレートの平均値が、現在使用している帯域のビットレートと比べて１０％以上大きい場合などとする。帯域要求コマンド生成部１０７は、帯域変更の通知を受けると、ＭＡＣマネジメント・エンティティ１３１を介して、帯域制御装置に帯域変更コマンドを発行して、その返答を受信する。帯域変更コマンドの返答が成功ならば、イソクロナス伝送を継続する。帯域変更コマンドの返答が失敗ならば、ストリームデータ判断部１０６（１０６’）は、イソクロナス伝送を継続するのは不可であると判断し、帯域要求コマンド生成部１０７に、当該パケット群のために確保している帯域を解放するよう通知する。以降の処理は先に記載した通りである。ストリームデータ判断部１０６（１０６’）は、帯域変更が必要ないと判断されれば、イソクロナス伝送を継続する。

３つ目は、当該パケット群のビットレートの特性が変動し、ストリームデータ判断部１０６（１０６’）が当該パケット群をもはやストリームデータではないと判断した場合である。ストリームデータではないという判断は、第１の実施の形態及び第２の実施の形態に記載の方法でもよいし、また、一度帯域を確保して伝送し始めたパケット群について、それ以降のストリームデータの判断方法を調整してもよい。例えば、第１の実施の形態において、変動係数のしきい値を調整してもよい。ストリームデータ判断部１０６（１０６’）は、当該パケット群がもはやストリームデータではないと判断した場合、帯域要求コマンド生成部１０７に、当該パケット群のために確保している帯域を解放するよう通知する。以降の処理は先に記載した通りである。

今回開示された実施の形態は、すべての点で例示であって制限的なものではないと考えられるべきである。本発明の範囲は上記した説明ではなくて特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。

本発明の第１の実施の形態における伝送装置の概略構成を示すブロック図である。 パケットヘッダの一例であるＩＰパケットのヘッダを示す図である。 ハッシュコードの計算方法の一例を示す図である。 フロー番号別のポインタ配列を示す図である。 ポインタの参照先に情報が記録されるセル構造の一例を示す図である。 フロー番号計算部１０２の処理手順を説明するためのフローチャートである。 パケット情報記憶部１０３に記憶されるセルの情報を、一定周期でパケット情報記憶部の履歴１０４にコピーする処理の手順を説明するためのフローチャートである。 セルの削除を説明するための図である。 パケット情報記憶部の履歴１０４の内容の一例を示す図である。 フロー別の統計量の計算結果の一例を示す図である。 端末１と帯域制御装置２との間で、帯域要求コマンドの発行と受付が行われる様子を示す図である。 パケット分類器ルール記憶部１０８に保存されるルールの一例を示す図である。 本発明の第１の実施の形態における伝送装置を含んだネットワークシステムの構成例を示す図である。 一般的な帯域制御装置２の帯域割当方法を示す図である。 ビットレートの変動をＶＢＲ用バッファ１１０で吸収する場合の概念を説明するための図である。 ビットレートが変動する場合のフローの一例を示す図である。 単位時間あたりに出て行くデータのバイト数を指定して、バッファにどれだけのデータが残るかを計算する方法を説明するための図である。 バッファに残るデータのバイト数の変化を示す図である。 要求する帯域と必要なバッファの容量との関係を示す図である。 トレードオフ曲線上の最適な点の抽出方法の一例を示す図である。

符号の説明

１ 伝送装置、２ 帯域制御装置、３ ＬＡＮ、４，５ 他のネットワーク、６ ネットワーク、１０１ サブレイヤ、１０２ フロー番号計算部、１０３ フロー番号別パケット情報記憶部、１０４ パケット情報記憶部、１０５ タイマー、１０６ ストリームデータ判断部、１０７ 帯域要求コマンド生成部、１０８ パケット分類器ルール記憶部、１０９ パケット分類器、１１０ ＶＢＲ用バッファ、１２１ 媒体アクセスコントローラ、１３１，２０１ ＭＡＣマネジメント・エンティティ。

Claims (11)

1. 所定の品質を確保して通信を行なう伝送装置であって、
   伝送するデータのパケットをパケットヘッダごとに分類するための分類手段と、
   前記分類手段による分類結果に応じて、同じパケットヘッダを有するパケットの集合をパケット群として管理し、前記パケット群の所定の単位時間あたりのビットレートを測定するための測定手段と、
   前記パケット群のビットレートの履歴に応じて、帯域を確保して伝送すべきか否かを判断するための判断手段と、
   前記判断手段によって帯域を確保して伝送すべきであると判断されたパケット群の帯域予約を帯域制御装置に要求するための要求手段とを含む、伝送装置。
2. 前記判断手段は、前記測定手段による測定結果から直前の所定のデータ数を対象としてビットレートのばらつきを表すパラメータを計算するための計算手段と、
   前記計算手段によって計算されたパラメータが予め設定された値以下ならば、当該パケット群を帯域を確保して伝送すべきパケット群であると判断するためのパケット判断手段とを含む、請求項１記載の伝送装置。
3. 前記計算手段は、計算したパラメータが予め設定された値より大きい場合、計算の対象とするデータ数を増やして、当該パラメータを再計算し、
   前記パケット判断手段は、前記再計算されたパラメータの値が予め設定された値以下ならば、当該パケット群を帯域を確保して伝送すべきパケット群であると判断する、請求項２記載の伝送装置。
4. 前記計算手段は、対象とするデータ数を順次増やしながら、当該パラメータが予め設定された値以下になるか、前記対象とするデータ数が予め決められた最大となるまで、当該パラメータの計算を繰返す、請求項２記載の伝送装置。
5. 前記判断手段は、前記測定手段による測定結果から、特定の帯域でパケット群を送信したときに必要となるバッファ容量を計算し、該計算を帯域を変えて行ない、必要とする帯域と必要となるバッファ容量との関係を導出し、該関係から当該パケット群を帯域を確保して伝送すべきパケット群であると判断する、請求項１記載の伝送装置。
6. 前記判断手段は、要求する帯域ごとに必要となるバッファ容量の最大値を抽出し、要求する帯域と必要となるバッファ容量の最大値との関係を表わすグラフが所定領域内にあるか否かによって帯域を確保して伝送すべきパケット群であるか否かを判定する、請求項５記載の伝送装置。
7. 前記判断手段は、前記所定領域内にある帯域を前記要求手段に要求させ、前記所定領域内にあるバッファ容量の最大値を確保するよう前記バッファ手段に要求する、請求項６記載の伝送装置。
8. 前記判断手段は、帯域を確保するために必要なコストとバッファ容量のコストとに基づいて、トータルのコストが最小となるように要求すべき帯域と確保すべきバッファ容量とを決定する、請求項７記載の伝送装置。
9. 前記判断手段が、一度帯域を確保して伝送すべきと判断したパケット群が所定の時間観測されず、もはや帯域を確保する必要がないと判断した場合、前記要求手段は、当該パケット群のために確保している帯域を解放することを前記帯域制御装置に要求する、請求項１〜８のいずれかに記載の伝送装置。
10. 前記判断手段が、一度帯域を確保して伝送すべきと判断したパケット群のビットレートの特性に所定の基準以上の変化があった場合、前記要求手段は、当該パケット群のために確保している帯域のビットレートを最新の値に変更することを前記帯域制御装置に要求する、請求項１〜８のいずれかに記載の伝送装置。
11. 前記判断手段が、一度帯域を確保して伝送すべきと判断したパケット群のビットレートの特性に所定の基準以上の変化があった場合、前記要求手段は、当該パケット群のために確保している帯域を解放することを前記帯域制御装置に要求する、請求項１〜８のいずれかに記載の伝送装置。

Images