JP2005269624A - パケット通信装置およびパケット通信方法 - Google Patents

Abstract

【課題】 ネットワークリソースの予約が必要な通信の通信品質を、ネットワークリソースの予約が完了するまでの間も、保証する。
【解決手段】 パケット受信部３は、他の通信機器からのパケットを受信し、リソース予約管理テーブル２は、ネットワークリソースの予約を必要とするパケットの情報を記録する。リソース割当要求部４は、リソース予約管理テーブル２に記録されたパケットの情報と一致するパケットを検知して、ネットワークに対して、リソース割当要求を行う。通信期間選択部５は、ネットワークに対するリソース割当要求の進捗状況に応じて、該当するパケットを送信する通信区間を選択し、パケット送信部６は、選択された通信期間により、パケットを送信する。
【選択図】 図１

Description

本発明は、ネットワークリソースの予約をサポートするネットワークにおけるパケット通信装置に関するものである。

インターネットに代表されるネットワーク環境では、情報の内容は、複数のパケットに分割され、これらのパケットが伝送されることにより、通信が行われる。一般に、パケットの伝送は、ベストエフォートによって処理される。これは、リアルタイム性が要求される音声や映像などのマルチメディア通信も、リアルタイム性を必要としないｆｔｐなどの非マルチメディア通信も同一に扱われることを意味する。結果として、ｆｔｐなどの非マルチメディア通信により、ネットワークが混雑すると、音声や映像のマルチメディア通信に遅延やデータの欠落などが発生し、音声が途切れたり映像の品質が劣化してしまう。

映像や音声などのマルチメディア通信を、品質劣化なく提供するためには、ネットワークの経路上のネットワークリソースを予約により確保し、通信品質を保証する必要がある。

ＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）は、インターネット標準のネットワークリソースを予約法として、ＲＳＶＰ（Ｒｅｓｏｕｒｃｅ Ｒｅｓｅｒｖａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）などのリソース管理プロトコルを規定する。

ＲＳＶＰによると、マルチメディア通信の開始前に、マルチメディア通信に必要なネットワークリソースが、通信相手との経路を構成する中継機器上にあらかじめ確保される。ＲＳＶＰを使用すると、通信を開始する前に、マルチメディア通信ごとに必要なネットワークリソースを確保できるため、通信品質が保証される。

中継機器における優先制御や無線ネットワークでの優先的な帯域割当により、ネットワークリソースを確保できる。このような帯域割当は、電力線通信や無線ＬＡＮにおいて実施されており、例えば無線ＬＡＮに適用できるＩＥＥＥ８０２．１１ｅでは、分散制御型による、優先度に基づいて送信権の獲得が可能な競合アクセス通信期間と、中央制御型による、独占的に送信権の獲得が可能な非競合アクセス通信期間とを提供する。

マルチメディア通信の場合、無線ネットワークに対して、事前にネットワークリソースの割当要求を行い、非競合アクセス通信期間を一定時間確保すれば、通信品質を保証できる。

一方、リソース予約を必要とするマルチメディア通信を行う端末の全てが、このようなネットワークリソース予約に対応しているとは限らない。このような場合、マルチメディア通信の開始前に、端末が事前にネットワークリソースの予約を行うかわりに、ネットワークの経路上の通信装置が、マルチメディア通信に必要なネットワークリソースの割当要求を発行すれば、通信品質を保証できる。

ネットワークリソースの予約に対応しない端末が、ネットワークリソースの予約を必要とする通信を開始すると、経路上の通信装置がこの通信を検知し、その通信に必要なネットワークリソースを割り当てるよう制御する。この方法によれば、端末が事前にネットワークリソースを予約しなくても、パケットの重要度などに応じて帯域割当を行うことができ、通信品質を保証できる。

ＲＳＶＰによるリソース予約では、端末がマルチメディア通信の開始前に、マルチメディア通信を品質劣化無く行うために必要なネットワークリソースを、通信経路上のネットワークにある中継機器で予約しておく必要がある。したがって、マルチメディア通信を行うためには、経路上のネットワークリソース予約の完了を待ってから、開始する必要があり、マルチメディア通信の開始までにタイムラグが生じる場合がある。

このようなタイムラグは、ホームネットワークにおけるマルチメディア通信、例えば、ＴＶやＶＴＲなどのＡＶ機器をネットワーク経由で利用するような映像視聴において、問題となる。つまり、ホームネットワークにおけるこれらの機器は、常時、すぐに使用できるべきであるという社会的通念があり、ユーザはこのようなタイムラグを許容しない。このようなタイムラグを解消するため、ネットワークリソースの予約完了前に、端末がマルチメディア通信を開始することも可能である。しかしながら、ネットワークリソースの予約が完了していないため、本来、通信品質を保証されて転送されるべきマルチメディア通信は、他のベストエフォートの通信と同様に扱われてしまい、結局、通信品質が保証されない。

ネットワークの経路上の通信機器が、マルチメディア通信を検出して、ネットワークリソースの予約を代行して行う場合、ネットワークリソースの予約を開始した時点において、すでにマルチメディア通信は開始されてしまっている。したがって、マルチメディア通信開始後ネットワークリソースの予約が完了するまでの間、マルチメディア通信は、ベストエフォートの通信として扱われてしまい、通信品質が劣化してしまう。

このような通信品質の劣化は、映像品質の劣化或いは音声品質の劣化として現れてしまうため、ユーザにとって許容しがたいものである。

以上述べたように、マルチメディア通信を、通信品質を保ったままタイムラグ無く即座に提供する技術が必要とされている。

また、ネットワークリソースの予約は、一般のユーザに理解しにくい問題であるから、ユーザ自身が設定を行わなくても、必要な通信制御が実施されることが望ましい。
特開２００１−３２０４１０号公報 ＲＦＣ２２０５ "Ｒｅｓｏｕｒｃｅ Ｒｅｓｅｒｖａｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＲＳＶＰ） ―― Ｖｅｒｓｉｏｎ １ Ｆｕｎｃｔｉｏｎａｌ Ｓｐｅｃｉｆｉｃａｔｉｏｎ"，URL http://www.ietf.org/rfc/rfc2205.txt "Ａ Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ Ｍｅｔｈｏｄ ｆｏｒ Ｈｉｇｈ−Ｓｐｅｅｄ Ｐｏｗｅｒ Ｌｉｎｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｓｙｓｔｅｍ Ｍｏｄｅｍｓ"，２００４ １ｓｔ ＩＥＥＥ Ｃｏｎｓｕｍｅｒ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ ａｎｄ Ｎｅｔｗｏｒｋｉｎｇ Ｃｏｎｆｅｒｅｎｃｅ Ｐｒｏｃｅｅｄｉｎｇｓ 映像情報メディア学会誌Ｖｏｌ５７、Ｎｏ１１（１４５９〜１４６４頁）

そこで本発明は、ネットワークの予約をサポートするネットワークにおいて、ネットワークリソースの予約が必要な通信の通信品質を、ネットワークリソースの予約が完了するまでの間も、保証できるパケット通信装置を提供することを目的とする。

第１の発明に係るパケット通信装置は、少なくともパケットの優先度による制御を行うと共にネットワークリソースの予約なしに通信できる第１通信期間と、ネットワークリソースの予約なしには通信できない第２通信期間とを、実質的にサポートするネットワークを構成するパケット通信装置であって、パケットを受信するパケット受信部と、ネットワークリソースの予約に関する情報を保持するリソース予約情報保持部と、リソース予約情報保持部が保持する情報を参照し、パケット受信部により受信されたパケットが、ネットワークリソースの予約が必要なとき、パケットを第２通信期間を利用して送信するためネットワークにリソース割当要求を発行するリソース割当要求部と、パケットを第１通信期間と第２通信期間とのいずれの通信期間を利用して通信するかを選択する通信期間選択部と、通信期間選択部により選択された通信期間を利用してパケットを送信するパケット送信部とを備え、通信期間選択部は、リソース割当要求部が発行するリソース割当要求による予約が完了するまで、第１通信期間を選択し、通信期間選択部は、リソース割当要求部が発行するリソース割当要求による予約が完了した後、第２通信期間を選択する。

この構成により、ネットワークリソースの予約が必要なパケットに対して、ネットワークリソース予約中は、優先度に基づいて、第１通信期間で送信し、予約完了後は第２通信期間で通信するため、リソース予約が必要なパケットの通信品質を保証できる。

第２の発明に係るパケット通信装置では、パケット受信部は、複数のパケット受信器のセットにより構成され、ネットワークリソースの予約が必要なパケットの優先度は、複数のパケット受信器のうちいずれのパケット受信器がネットワークリソースの予約が必要なパケットを受信したかによって決定される。

この構成により、第１通信期間に必要となるパケットの優先度は、パケット通信装置の受信ポートごとに設定ができるため、ユーザが特別な設定を行わなくても、簡単に設定できる。

第３の発明に係るパケット通信装置では、リソース予約情報保持部に保持された情報によりネットワークリソースの予約が必要とされるパケットについて、現時点で必要な予約パラメータを測定するリソース測定部をさらに備える。

この構成により、ユーザは予約に必要な予約パラメータを設定する必要が無くなり、設定が簡便化できる。

第４の発明に係るパケット通信装置では、リソース予約情報保持部に保持された情報によりネットワークリソースの予約が必要とされるパケットについて、リソース割当要求部が発行したリソース割当要求に関する予約パラメータと、リソース測定部により測定された現時点で必要な予約パラメータとを比較し、ネットワークリソースの再予約が必要か否かを判定するリソース監視部をさらに備え、リソース監視部がネットワークリソースの再予約が必要と判定するとき、リソース割当要求部は、現時点で必要な予約パラメータに基づくリソース割当要求を発行する。

この構成により、予約パラメータ（トラフィック特性）が変動する通信にも対応でき、リソース予約が必要なパケットの通信品質を保証できる。

第５の発明に係るパケット通信装置では、リソース割当要求部が現時点で必要な予約パラメータに基づくリソース割当要求を発行した後、予約が完了するまでの間、ネットワークリソースの予約が必要とされるパケットを、第２通信期間だけで送信できない場合、第２の通信期間と第１通信期間との両方を利用して送信する。

この構成により、予約した以上のトラフィックが発生しても、予約パラメータ以上のパケットを第１通信期間で優先的に送信でき、該当パケットの通信品質を保証できる。

第６の発明に係るパケット通信装置は、少なくともパケットの優先度による制御を行うと共にネットワークリソースの予約なしに通信できる第１通信期間と、ネットワークリソースの予約なしには通信できない第２通信期間とを、実質的にサポートするネットワークを構成するパケット通信装置であって、パケットを受信するパケット受信部と、パケット受信部により受信されたパケットを、パケットの種類に応じて第１通信期間または第２通信期間を利用して送信するパケット送信部と、ネットワークリソースの予約が必要なパケットを第２通信期間を利用して通信するため、ネットワークに対してリソース割当要求を行うリソース割当要求部とを備え、パケット送信部は、リソース割当要求の進捗状況に応じて、ネットワークリソースの予約が必要なパケットの通信期間を変更する。

この構成により、ネットワークリソースの予約が必要なパケットに対して、ネットワークリソースの予約状況に応じて、最適な通信期間を選択でき、パケットの通信品質を保証できる。

本発明のパケット通信装置によれば、ネットワークリソースの予約が必要な通信の通信品質を、ネットワークリソースの予約が完了するまでの間も、保証できるため、ユーザは、利用したいマルチメディア通信を、通信品質を保ったまま、タイムラグ無く即座に利用できる。

以下図面を参照しながら、本発明の実施の形態を説明する。

（実施の形態１）
図１は、本発明の実施の形態１におけるパケット通信装置のブロック図である。

本形態のパケット通信装置１０は、リソース予約管理テーブル２と、パケット受信部３と、リソース割当要求部４と、通信期間選択部５と、パケット送信部６と、予約制御部９とを備える。

リソース予約管理テーブル２は、リソース予約情報保持部に相当し、パケットのリソース予約情報を保持する。本形態では、リソース予約管理テーブル２は、リソース予約情報を、図９に示される予約ルールのセットとして管理する。それぞれの予約ルールは、リソース予約管理テーブル２の１つの予約ルールエントリにより表現され、各予約ルールエントリは、次の複数のフィールドを有する。勿論、リソース予約情報保持部は、テーブルに限られず、リスト、配列等、周知の記憶構造により構成できる。

「定義情報」フィールドの値は、パケットを分類するためのものであり、送信元のＭＡＣアドレスの値と送信元のＴＣＰポートの値を含む。パケットを分類するためのルールを記述する。「定義情報」フィールドの値は、ＭＡＣヘッダ、ＩＰｖ４ヘッダ、ＩＰｖ６ヘッダ、ＴＣＰヘッダ、ＵＤＰヘッダなど、インターネットで用いられる各パケットヘッダに含まれる値であれば任意である。

「優先度」フィールドの値は、優先度の高低を示す。本形態では、優先度として、ＩＥＥＥ８０２．１ｐで示される８段階の優先度が用いられる。値「７」が最高の優先度であり、値「０」の優先度を持つパケットは、「ベストエフォート」の取り扱いを受ける。なお、予約ルールエントリが存在しないパケットの優先度は、値「０」として扱われ、通信期間として第１通信期間１６が用いられるものとする。

「予約済フラグ」フィールドの値（「ＯＮ」又は「ＯＦＦ」）は、予約済か否かを示す。「予約済フラグ」フィールドの値が「ＯＦＦ」の場合、該当する予約ルールに関するネットワークリソースの予約が完了していないことが示され、この値が「ＯＮ」の場合、その予約が完了していることが示される。

「予約中フラグ」フィールドの値（「ＯＮ」又は「ＯＦＦ」）は、予約中か否かを示す。「予約パラメータ」フィールドの値は、ネットワークリソースの予約時に指定される値であり、本形態では、予約される平均ビットレートの値である。

「通信期間」フィールドの値は、この予約ルールエントリが、第１通信期間（予約なしでも通信できる期間、例えばＣＳＭＡ期間）と第２通信期間（予約なしでは通信できない期間、例えばＴＤＭＡ期間）のいずれに該当するかを示す。

なお、フィールド「定義情報」、「優先度」、「予約パラメータ」の値は、パケット通信装置に予め設定されてもよいし、ＧＵＩ等を介しユーザにより指定されてもよいし、ネットワーク経由で設定されてもよい。

パケット受信部３は、他の通信機器から送信されたパケットを受信する。

リソース割当要求部４は、リソース予約管理テーブル２が保持する予約ルールに該当するパケットを検知し、ネットワークに対してリソース割当要求を行う。

通信期間選択部５は、ネットワークに対するリソース割当要求の進捗状況、例えば、リソース割当要求が完了したか否かによって、該当するパケットを送信する通信区間を、第１通信期間あるいは第２通信期間のいずれかから選択する。

パケット送信部６は、通信期間選択部５により選択された通信期間で、パケットを送信する。

予約制御部９は、リソース予約管理テーブル２、リソース割当要求部４及び通信期間選択部５の処理を仲介すると共に、これらの要素を制御する。特に、予約制御部９は、状況に応じて、リソース予約管理テーブル２の予約ルールエントリを操作する。

図２は、本発明の実施の形態１におけるネットワークを示す。

このネットワーク１は、パケットを送信する通信期間として、第２通信期間１５と第１通信期間１６の２つの通信期間をサポートする。本形態では、これらの通信期間は、次のようになっている。第１通信期間１６では、パケットの優先度に応じた送信権が割り当てられる。つまり、第１通信期間１６では、予約なしでも通信を行える。第２通信期間１５では、ネットワークリソースの予約に基づき帯域保証された通信が提供される。つまり、第２通信期間１５では、予約なしでは通信できない。

端末２０、２１、２２、２３は、それぞれパケットを送受信する。パケット２０１は、端末２０から端末２２に送信され、パケット２１１は、端末２１から端末２３に送信される。

端末２０はパケット通信装置１０に接続され、端末２１はパケット通信装置１１に接続され、端末２２はパケット通信装置１２に接続され、端末２３はパケット通信装置１３に接続される。パケット通信装置１０、１１、１２、１３は、ネットワーク１を介して、それぞれ接続されている。パケット通信装置１０、１１、１２、１３は、端末２０、２１、２２、２３が送信したパケットを、ネットワーク１を介して、パケットを受信する端末宛に転送する。

なお、パケット通信装置１１〜１３は、パケット通信装置１０と同様に構成されるため、パケット通信装置１１〜１３に関する説明は省略する。

図３は、本発明の実施の形態１におけるパケット通信装置１０〜１３のハードウェアブロック図である。図５〜図８、図１２〜１６に示されるフローチャートに沿ったシステムプログラムは、図３のＲＯＭ３２に格納されており、バス３３を介してＣＰＵ３０にロードされる。ＣＰＵ３０は、このシステムプログラムを実行し、図１の各要素の動作を制御する。

ＲＡＭ３１には、ＣＰＵ３０がその処理上必要な記憶領域と、リソース予約管理テーブル２のための領域とが、確保される。また、ネットワークインターフェイス３４、３５が、ＣＰＵ３０の制御下において、ネットワーク１と入出力することにより、パケット受信部３及びパケット送信部７とが、実現される。

本形態では、端末２０は、予約を必要とするパケットを送信する送信端末であり、端末２２は、端末２０からのパケットを受信する受信端末である。端末２１は、予約を必要としないパケットを送信する送信端末であり、端末２３は、端末２１からのパケットを受信する端末である。

（１）端末２１から端末２３へ送信されるパケットの送信手順
まず、図２、図５、図７、図８を用いて、パケット通信装置１１が、端末２２から端末２３へのパケット２１１を処理する手順、すなわち、該当する予約ルールエントリがないパケット２１１の送信手順について、説明する。なお、本形態では、パケット通信装置１１のリソース管理テーブル２は、予約ルールエントリを全く保持していないものとする。

まず、端末２１、２３がソケット通信を開設し、端末２１がパケット２１１の送信を開始する。

パケット通信装置１１のパケット受信部２は、端末２１からパケット２１１を受信し、パケット２１１はリソース割当要求部４に出力される。リソース割当要求部４は、予約制御部９を介してリソース管理テーブル２をアクセスする。図５において、パケット通信装置１１のリソース管理テーブル２には、予約ルールエントリが存在しないため、リソース割当要求部４は、何も処理せず終了する（ステップ２１）。

続いて、図７において、パケット通信装置１１の通信期間選択部５は、予約制御部９を介してリソース管理テーブル２をアクセスする。リソース管理テーブル２に端末２１から端末２３へのパケットに関する予約ルールエントリが無いため、通信期間選択部５は、何も処理せず終了する（ステップ４１）。

さらに、図８において、パケット通信装置１１のパケット送信部６は、予約制御部９を介してリソース管理テーブル２をアクセスする。リソース管理テーブル２に端末２１から端末２３へのパケットに関するルールが無いため（ステップ５１）、パケット送信部６は、送信すべきパケット２１１の優先度の値を「０」に設定し（ステップ５６）、第１通信期間１６で送信する（ステップ５５）。

以上の処理により、端末２１から端末２３へのパケット２１１は、ネットワーク１において、優先度「０」が付与され、第１通信期間１６で送信されるようになる。

図４（ａ）は、この時のネットワーク１の通信状態を示したものであり、パケット２１１は、第１通信期間１６で送信される。

（２）端末２０から端末２２へ送信されるパケットの送信手順（予約完了前）
次に、図２および図９を用いて、端末２０から端末２２へのパケット２０１、すなわち、予約ルールエントリが存在するがネットワークリソースの予約完了前であるパケット２０１の送信手順について説明する。

パケット通信装置１０には、図９（ａ）に示される予約ルールエントリが記載されているものとする。

まず、端末２０、２２がソケット通信を開設する。この場合、送信元である端末２０は、送信元ＭＡＣアドレスが「００：０１：０２：０３：０４：０５」であり、送信元ＴＣＰポート番号が「８０」であるパケット２０１を送信するものとする。

パケット通信装置１０のパケット受信部３は、端末２０からパケット２０１を受信し、そのパケット２０１は、リソース割当要求部４へ出力される。

次に、図５および図９を用いて、リソース割当要求部４の動作を説明する。

図５において、リソース割当要求部４は、予約制御部９を介してリソース管理テーブル２をアクセスし、このパケット２０１が、リソース予約管理テーブル２の予約ルールエントリに該当するかを確認する（ステップ２１）。本形態では、パケット通信装置１０のリソース予約管理テーブル２は、図９（ａ）に示される予約ルールエントリを保持している。端末２０のＭＡＣアドレス「００：０１：０２：０３：０４：０５」と送信元ＴＣＰポート番号８０とは、フィールド「定義情報」の値により定義された予約ルールに該当する。

したがって、図５において、リソース割当要求部４は、予約制御部９を介してリソース管理テーブル２をアクセスし、該当する予約ルールエントリの「予約済フラグ」フィールドの値が「ＯＮ」であるかを確認する（ステップ２２）。図９（ａ）において、「予約フラグ」フィールドは「ＯＦＦ」である。

したがって、リソース割当要求部４は、リソース管理テーブル２の「予約パラメータ」フィールドから、値「平均ビットレート６Ｍｂｐｓ」を、ネットワークリソースとして取得する（ステップ２３）。

さらに、リソース割当要求部４は、ネットワーク１に対し、取得したネットワークリソースによりリソース予約を実行する（ステップ２４）。リソース予約実行後、予約制御部９は、リソース予約管理テーブル２の「予約中フラグ」フィールドの値を「ＯＦＦ」から「ＯＮ」に更新する（ステップ２５）。これにより、リソース予約管理テーブルは、図９（ｂ）の状態になる。しかしながら、予約が完了するまでは、「予約済フラグ」フィールドの値は、依然として「ＯＦＦ」のままである。

次に、図７および図９を用いて、通信期間選択部５の動作を説明する。

図７において、通信期間選択部５は、予約制御部９を介してリソース管理テーブル２をアクセスし、このパケットが、リソース予約管理テーブル２に保持された予約ルールエントリに該当するかを確認する（ステップ４１）。

保持されているパケットの場合、通信期間選択部５は、予約制御部９を介してリソース管理テーブル２をアクセスし、リソース予約管理テーブル２の「予約済フラグ」フィールドが「ＯＮ」かどうかを確認する（ステップ４２）。現在のリソース予約管理テーブル２では、図９（ｂ）に示されるとおり、「予約済フラグ」フィールドの値は「ＯＦＦ」であるので、通信期間選択部５は、予約制御部９を介してリソース管理テーブル２をアクセスし、リソース予約管理テーブル２の「通信期間」フィールドの値を「第１通信期間」とする（ステップ４４）。

以上により、リソース予約管理テーブルは、図９（ｃ）の状態になる。

つぎに、図８および図９を用いて、パケット送信部６の動作を説明する。

まず、図８において、パケット送信部６は、予約制御部９を介してリソース管理テーブル２をアクセスし、送信すべきパケット２０１が、リソース予約管理テーブル２に保持された予約ルールエントリに該当するかを確認する（ステップ５１）。

図９（ｃ）に示されるとおり、このパケット２０１は、予約ルールエントリに保持されているパケットであるので、パケット送信部６は、予約制御部９を介してリソース管理テーブル２をアクセスし、リソース予約管理テーブル２の「送信期間」フィールドから、パケット送信部６は、そのパケット２０１を送信する送信期間を取得する（ステップ５２）。さらに、パケット送信部６は、「優先度」フィールドから優先度を取得し（ステップ５３）、取得された送信期間が「第１通信期間」かを確認する（ステップ５４）。

図９（ｃ）に示されるとおり、端末２０から端末２２への通信に用いられるパケット２０１の送信期間は「第１通信期間」であり、優先度は「７」である。

したがって、端末２０から端末２２への通信に用いられるパケットは、パケット通信装置１０において、優先度は「７」で、第１通信期間１６を用いて送信される（ステップ５５）。

以上により、図４（ｂ）に示されるように、ネットワークリソースの予約が完了するまでの間、ネットワーク１において、端末２０から端末２２へのパケット２０１が、端末２１から端末２３へのパケット２１１よりも、高い優先度で送信される。

したがって、パケット２０１は、未だ予約が確立していない期間においても、高い優先度で保護され、廃棄を免れやすくなる。その結果、パケット２０１が関係する通信品質を向上できる。

（３）端末２０から端末２２へ送信されるパケットの送信手順（予約完了後）
パケット通信装置１０が、端末２０から端末２２への通信に関するネットワークリソースの予約を完了した後の、端末２０から端末２２へのパケットの送信手順について説明する。

パケット受信部３の動作は、上述と同様であるから省略する。

図６は、リソース割当要求部４が、ステップ２４で行ったリソース予約結果を受け取った場合の動作を示すフローチャートである。

リソース割当要求部４は、ネットワーク１から、リソース割当要求の結果を取得する（ステップ３１）。ここでは、リソースの予約が成功し、完了したという結果を受け取ったものとする。このとき、リソース割当要求部４は、リソース予約が完了したと判断し（ステップ３２）、予約制御部９を介して、リソース予約管理テーブル２の予約ルールエントリの「予約済フラグ」フィールドが「ＯＮ」であるかを確認する（ステップ３３）。

図９（ｃ）に示されるとおり、「予約済フラグ」フィールドは「ＯＦＦ」であるので、リソース割当要求部４は、予約制御部９を介して、リソース予約管理テーブルの「予約済フラグ」フィールドを「ＯＮ」に更新し（ステップ３４）、「予約中フラグ」フィールドを「ＯＦＦ」に更新する（ステップ３５）。これにより、リソース予約管理テーブルは、図９（ｄ）の状態になる。

次に、ネットワークリソース予約完了後の、通信期間選択部５の動作について、図７を用いて説明する。

通信期間選択部５は、予約制御部９を介してリソース管理テーブル２をアクセスし、送信すべきパケットが、リソース予約管理テーブル２に保持された予約ルールエントリに該当するかを確認する（ステップ４１）。

保持されているパケットの場合、通信期間選択部５は、リソース予約管理テーブル２の「予約済フラグ」フィールドが「ＯＮ」かどうかを確認する（ステップ４２）。現在のリソース予約管理テーブル２では、図９（ｄ）に示されるとおり、「予約済フラグ」フィールドが「ＯＮ」であるので、リソース予約管理テーブル２の「通信期間」フィールドは「第２通信期間」にセットされる（ステップ４４）。

以上により、リソース予約管理テーブル２は、図９（ｅ）の状態になる。

続いて、ネットワークリソース予約完了後の、パケット送信部６の動作について、図８を用いて説明する。

まず、パケット送信部６は、予約制御部９を介してリソース管理テーブル２をアクセスし、送信すべきパケットが、リソース予約管理テーブル２に保持された予約ルールエントリに該当するかを確認する（ステップ５１）。

保持されたパケットの場合、パケット送信部６は、予約制御部９を介してリソース管理テーブル２をアクセスし、リソース予約管理テーブル２の「送信期間」フィールドから、そのパケットを送信する送信期間を取得し（ステップ５２）、さらに「優先度」フィールドから優先度を取得し（ステップ５３）、取得した送信期間が「第１通信期間」かを確認する（ステップ５４）。

端末２０から端末２２への通信に用いられるパケットの通信期間は、図９（ｅ）に示されるとおり、「第２通信期間」であるので、第２通信期間１５で送信される（ステップ５７）。

したがって、端末２０から端末２２への通信に用いられるパケットは、パケット通信装置１０において、そのパケット用にネットワークリソースが予約済の、第２通信期間１５を用いて送信される。

図４（ｃ）は、この時のネットワーク１の状態を示したものであり、パケット２０１が第２通信期間１５で、パケット２１１は第１通信期間１６で送信される。

以上の処理により、ネットワークリソースの予約が必要なパケットがネットワークリソースの予約完了前に送信される場合、ネットワークリソースの予約完了前までの間、他のパケットよりも高い優先度により第１通信期間１６において送信され、ネットワークリソースの予約完了後、そのパケット用に割り当てられた予約を利用する第２通信期間１５において送信されることにより、通信品質の劣化を抑制できる。

なお、本形態において、端末とパケット通信装置は別体として図示したが、パケット通信装置と端末とを一体的に構成しても差し支えないことは、言うまでもない。

また、本形態では、選択できる通信期間を２つとしているが、３つ以上の通信期間があっても、同様の効果が期待できる。その場合、本形態においては、通信期間の選択を、ネットワークリソースの予約が完了したか、していないかの２つの状態で切り替えているが、状態の個数（例えば、「ネットワークリソースの予約中」、「帯域不足のため、予約を保留中」、「予約完了」など）に応じて通信期間の個数を増やし、これらの通信期間の一つを選択できるようにすればよい。

また、第１通信期間１６において、「優先度」フィールドの初期値は、「０」である必要は無く、他の値でもよい。また、この初期値は、常に一定である必要は無い。例えば、この初期値を、リソースの予約を行って１秒間は、最高優先度とし、それ以降１０秒までは中優先度とし、１０秒以上経過したら低優先度とするなど、状況に応じて初期値は更新されてもよい。

あるいは、優先度は、予約ルールエントリに記載されたパケットを受信したパケット受信部３に応じて、設定されてもよい。例えば、図１０に示されるように、パケット通信装置１０のパケット受信部を、複数のパケット受信器３０１、３０２、３０３により構成する。この場合、予約ルールエントリに記述があるパケットをパケット受信器３０１で受信した場合は優先度を「７」にし、パケット受信器３０２で受信した場合は優先度を「５」にし、パケット受信器３０３で受信した場合は優先度を「４」にする等が考えられる。

なお、本形態では、独占的に送信権を獲得できる第２通信期間１５と、優先度に基づいて、送信権を獲得できる第１通信期間１６を用いて送信する例を述べたが、このような通信期間を提供できる無線ＬＡＮや電灯線通信などに適用可能であることは、自明である。

さらに、ネットワーク自身（例：Ｅｔｈｅｒｎｅｔ（登録商標））が第１通信期間１６と第２通信期間１５をサポートしなくても、パケット通信装置が、リソース予約に基づいた帯域保証制御と、パケットの優先度に基づいた優先制御によるパケットの転送制御を実施し、予約が完了するまでは優先制御で、予約が完了した後は帯域保証制御でパケットを転送すれば十分である。このとき、本発明の関係において、ネットワークが第１通信期間と第２通信期間とを実質的にサポートしていることになり、この場合も本発明の範囲に包含され、また同様の効果が得られる。

さらに、本形態では、優先度に基づいて、送信権を獲得できる第１通信期間１６を用いて送信する例を述べたが、第１通信期間１６の代わりとして、非特許文献２に示されるＩｎｔｅｌｌｉｇｅｎｔ ＴＤＭＡによって、仮の予約帯域（例えば、１Ｍｂｐｓ程度）をあらかじめ確保した期間を第２通信期間（仮予約期間とする）に設定しておき、リソース予約が完了するまでは、この仮予約期間で送信して、リソース予約完了後は、第２通信期間で通信するように構成してもよい。

これによれば、予約を必要とするパケットの帯域が仮の予約帯域以下であれば帯域は保証され、また仮の予約帯域以上であっても、Ｉｎｔｅｌｌｉｇｅｎｔ ＴＤＭＡによって、可能な限りの帯域が割当てられるため、リソース予約完了するまでの間も、同様の効果が得られる。

（実施の形態２）
実施の形態２では、実施の形態１の構成に加え、リソース測定部７およびリソース監視部８をさらに備える。

図１１は、本発明の実施の形態２におけるパケット通信装置のブロック図であり、図１と同じ構成要素については同じ符号を用い、説明を省略する。

図１７に示されるように、実施の形態２のリソース予約管理テーブル２の予約ルールエントリは、図９のフィールドに加え、「再予約フラグ」フィールドと、「仮予約パラメータ」フィールドとをさらに備える。

本形態では、リソース予約を必要とするパケットに関する予約ルールエントリが作成された状態、つまり定義情報と優先度が指定された状態において、「仮予約パラメータ」フィールドの値が「０」にセットされ、「再予約フラグ」フィールドの値が「ＯＦＦ」にセットされる。なお、「再予約フラグ」フィールドの値「ＯＦＦ」は、ネットワークリソースの予約を再度行う必要が無いことを示し、「再予約フラグ」フィールドの値「ＯＮ」は、ネットワークリソースの再予約が必要なことを示す。

リソース測定部７は、リソース予約管理テーブル２に保持された予約ルールエントリに該当するパケットについて、現時点で必要な予約パラメータを測定する。そして、リソース測定部７は、測定結果を、予約制御部９を介し、この予約ルールエントリの「予約パラメータ」フィールドまたは「仮予約パラメータ」フィールドに記録する。

リソース監視部８は、リソース予約管理テーブル２に保持された予約ルールエントリの「予約パラメータ」フィールドの値と、「仮予約パラメータ」フィールドの値とを比較し、比較結果が規定値（本形態では、変化量１０％）以上になった場合、再予約が必要であることを、予約ルールエントリに記録する。より具体的には、この記録は、「再予約フラグ」フィールドの値を、値「ＯＦＦ」から値「ＯＮ」にすることにより実施される。

本形態では、実施の形態１の処理（１）、（２）、（３）が完了した状態からの動作を説明する。このとき、図２において、端末２０は、ネットワークの予約を完了し、端末２０は、第２通信期間１５を利用して端末２２と通信する。端末２１は、図４（ｃ）に示されるように、第１通信期間１６を利用して端末２３と通信する。

この時、リソース予約テーブル２は、図１７（ａ）の状態にあり、フィールド「定義情報」、「優先度」、「予約済フラグ」、「予約中フラグ」、「予約パラメータ」及び「通信期間」の各値は、図９（ｅ）と同じである。

また「再予約フラグ」フィールドの値は「ＯＦＦ」であり、「仮予約パラメータ」フィールドの値は「０」である。

以下、実施の形態１との相違点を中心に、説明する。

（４）端末２０から端末２２へ送信されるパケットの送信手順（再予約完了前）
まず、端末２０から端末２２への通信に関し、パケット通信装置１０が新しい予約パラメータで再予約要求を発行し、再予約が完了する前までの、端末２０から端末２２へのパケットの送信手順について説明する。

パケット受信部３は、パケットを受信し、リソース測定部７へ受信されたパケットを出力する。

次に、図１２を参照しながら、リソース測定部７の動作を説明する。リソース測定部７は、予約制御部９を介し、そのパケットに該当する予約ルールエントリが、リソース予約管理テーブル２に保持されているかを確認する(ステップ６１)。図１７（ａ）に示されるとおり、この予約ルールエントリは保持されているので、リソース測定部７は、ネットワークリソースの測定を行う(ステップ６２)。本形態では、ネットワークリソースの測定は、平均ビットレートによるものとし、測定結果「平均ビットレート８Ｍｂｐｓ」が得られたものとする。

測定後、リソース測定部７は、予約制御部９を介し、この予約ルールエントリの「予約済フラグ」フィールドの値が「ＯＮ」であるかを確認する（ステップ６３）。この値が「ＯＦＦ」である場合（予約なし）、リソース測定部７は、予約制御部９を介し、「予約パラメータ」フィールドに、測定結果を記録する（ステップ６４）。

一方、「予約済フラグ」フィールドの値が「ＯＮ」である場合（予約済）、リソース測定部７は、予約制御部９を介し、「仮予約パラメータ」フィールドに、測定結果を記録する(ステップ６５)と共に、「再予約フラグ」フィールドの値を「ＯＮ」にセットする(ステップ６６)。

本形態では、図１７（ａ）に示されるとおり、「予約済フラグ」フィールドの値が「ＯＮ」であるので、リソース測定部７は、予約制御部９を介し、「仮予約パラメータ」フィールドに測定結果「平均ビットレート８Ｍｂｐｓ」を記録する。その結果、リソース予約管理テーブル２は、図１７（ｂ）に示される状態になる。

次に、図１３を参照しながら、リソース監視部８の動作を説明する。

まず、リソース監視部８は、予約制御部９を介し、そのパケットに該当する予約ルールエントリが、リソース予約管理テーブル２に保持されているかを確認し(ステップ７１)、保持されていなければ、処理を終了する。

ここでは、図１７（ｂ）に示されるとおり、パケットに該当する予約ルールエントリが存在するので、リソース監視部８は、予約制御部９を介し、リソース予約管理テーブル２の該当する予約ルールエントリから、「予約パラメータ」フィールドの値と「仮予約パラメータ」フィールドの値を取得する（ステップ７２）。

リソース監視部８は、「予約パラメータ」の値と「仮予約パラメータ」の値の変動が規定値以上（例えば、平均ビットレートが１０％増加、など）であるかを判断し（ステップ７３）、規定値以上であるならば、リソース監視部８は、予約制御部９を介し、「再予約フラグ」フィールドの値を「ＯＮ」にセットする（ステップ７４）。

本形態では、「予約パラメータ」の値と「仮予約パラメータ」の値が、「６Ｍｂｐｓ」から「８Ｍｂｐｓ」へ規定値の１０％以上変動しているため、リソース監視部８は、予約制御部９を介し、「再予約フラグ」フィールドの値を「ＯＮ」にセットするものとする。その結果、リソース予約管理テーブルは、図１７（ｃ）に示される状態になる。

さらに、図１４を参照しながら、リソース割当要求部４の動作について説明する。なお、ステップ２１からステップ２５までは、実施の形態１と同様であるので、詳しい説明は省略する。

まず、リソース割当要求部４は、予約制御部９を介し、リソース予約管理テーブル２に、パケットに関する予約ルールエントリが保持されているかを確認し（ステップ２１）、もし保持されていれば、その「予約済フラグ」フィールドの値が「ＯＮ」であるかを確認する（ステップ２２）。

本形態では、図１７（ｃ）にあるように、「予約済フラグ」フィールドの値は「ＯＮ」にセットされているので、次に、リソース割当要求部４は、予約制御部９を介し、「再予約フラグ」フィールドの値が「ＯＮ」であるかを確認する（ステップ２６）。ここでは、「再予約フラグ」フィールドの値は「ＯＮ」であるから、リソース割当要求部４は、予約制御部９を介し、ネットワークリソースとして、「仮予約パラメータ」フィールドの値を取得する（ステップ２７）。そして、その値を用いて、リソース割当要求部４は、ネットワークに予約要求を発行し（ステップ２４）、予約制御部９を介し、「予約中フラグ」フィールドに値「ＯＮ」にセットする（ステップ２５）。その結果、リソース予約管理テーブル２は、図１７（ｄ）のようになる。

通信期間選択部５の動作は、実施の形態１と同様であるので、説明を省略する。

続いて、図１６を用いて、パケット送信部６の動作を説明する。なお、ステップ５１からステップ５７までは、実施の形態１と同様であるので、詳しい説明は省略する。

まず、パケット送信部６は、予約制御部９を介し、パケットに関する予約ルールエントリがリソース管理テーブル２に保持されているかを確認する（ステップ５１）。ここでは、保持されているので、パケット送信部６は、予約制御部９を介し、予約ルールエントリの「通信期間」フィールドの値と「優先度」フィールドの値を取得する（ステップ５２、５３）。

次に、パケット送信部６は、予約制御部９を介し、予約ルールエントリの「通信期間」フィールドの値が「第１通信期間」であるかを確認する（ステップ５４）。図１７（ｄ）に示されるように、「通信期間」フィールドの値は「第２通信期間」であるので、パケット送信部６は、そのパケットを第２通信期間１５で送信する（ステップ５７）。

さらに、パケット送信部６は、予約制御部９を介し、「再予約フラグ」フィールドの値が「ＯＮ」であるかを確認する（ステップ５８）。その値が「ＯＮ」であれば、予約ルールエントリに保持済のパケットを第２通信期間１５で送信できていないことを意味する。この場合、パケット送信部６は、予約ルールエントリに設定されている優先度に基づいて、第１通信期間１６においてこのパケットを送信する（ステップ５９）。

これにより、リソース割当要求部４がネットワークに対して行った予約パラメータ（本形態では、平均ビットレート６Ｍｂｐｓ）の値を超えたトラフィック（本形態では、平均ビットレート８Ｍｂｐｓ）が流れている場合、第２通信期間１５だけでは、送信できなかったパケット（本形態では、８Ｍｂｐｓと６Ｍｂｐｓの差分である、２Ｍｂｐｓ）を、第１通信期間１６を使用して送信できる。図４（ｄ）は、この時のネットワーク１の状態を示したものであり、パケット２０１は、第２通信期間１５と第１通信期間１６との両方を利用して送信されている。

（５）端末２０から端末２２へ送信されるパケットの送信手順（再予約完了後）
次に、新しい予約パラメータでのリソース再予約が完了した後において、パケット通信装置１０が、端末２０から端末２２へパケットを送信する手順について説明する。

まず、図１５を参照しながら、リソース要求割当部４の動作を説明する。なお、ステップ３１からステップ３５までは、実施の形態１と同一であるので、詳しい説明は省略する。

リソース割当要求部４は、ネットワークからリソース割当要求の結果を取得し（ステップ３１）、予約が完了したものとする（ステップ３２）。図１７（ｄ）に示されるように、該当する予約ルールエントリの「予約済フラグ」フィールドの値は「ＯＮ」であるので（ステップ３３）、リソース割当要求部４は、予約制御部９を介し、該当する予約ルールエントリの「仮予約パラメータ」フィールドの値を「予約パラメータ」フィールドの値に上書きする。これにより、「予約パラメータ」フィールドの値は、予約済の最新パラメータに更新される（ステップ３６）。そして、リソース割当要求部４は、予約制御部９を介し、「再予約フラグ」フィールドの値を「ＯＦＦ」にセットし（ステップ３７）、「予約中フラグ」フィールドの値を「ＯＦＦ」にセットする（ステップ３５）。

以上により、リソース予約管理テーブル２は、図１７（ｅ）の状態に更新される。

新しい予約パラメータでの予約が完了すると、パケット送信部６は、予約済の最新パラメータによって予約されたリソースを使用して通信できるだけでなく、第１通信期間１６を利用せず第２通信期間１５だけを利用して、通信できる。

図４（ｅ）は、この時のネットワーク１の状態を示したものであり、予約完了後、パケット２０１は、再予約された第２通信期間１５を利用して送信され、パケット２１１は、第１通信期間１６を利用して送信される。

以上の処理において、ネットワークリソースの予約が必要なパケットの予約パラメータを、計測によって取得することにより、ユーザの設定なしに、通信品質を確保できる。

また、パケットの予約に必要なパラメータが、リソース予約後に変動するような通信の場合でも、変動後のパラメータでリソースの再予約を行うことで、通信品質を保証できる。

さらに、リソースの再予約を行っている間は、第２通信期間に加えて、優先度に基づいて、第１通信期間でも送信することにより、通信品質の劣化を抑制できる。

なお、本形態では、予約パラメータとして平均ビットレートを用いているが、このほか、最大ビットレート、平均フレームサイズ、最大フレームサイズ、ジッタ、遅延などを用いてもよい。また、リソース測定部７が測定できるパラメータも、それに準じて、様々なパラメータに変更して良い。

また、本形態では、ネットワークリソースの測定を行うリソース測定部７を設けている。このリソース測定部７は、実施の形態１に追加することもできる。

以上の説明から明らかなように、実施の形態２では、予約済のトラフィック（パケットの集合から構成される）が存在し、そのトラフィックが必要とするネットワークリソースが何らかの理由で増加するとき、リソース測定部７がこの必要とするネットワークリソースを測定しているから、必要となるネットワークリソースの変化に対して適応的に、ネットワークリソースを再予約できる。

さらに、この再予約が完了するまでの時間では、事実上、このトラフィックに予約されたネットワークリソースは、現在必要なネットワークリソースを下回っていることになる。そのような場合、第２通信期間だけでなく第１通信期間をも利用して、通信品質を保持できる。

また、再予約が完了した後は、第２通信期間だけを利用して、予約により保証された通信品質を確保できる。

本発明にかかるパケット通信装置は、例えばネットワークの予約をサポートする通信分野等において好適に利用できる。

本発明の実施の形態１におけるパケット通信装置のブロック図 本発明の実施の形態１におけるネットワークのブロック図 明の実施の形態１におけるパケット通信装置のハードウェアブロック図 本発明の実施の形態１におけるネットワーク１の状態図 本発明の実施の形態１におけるリソース割当要求部のフローチャート 本発明の実施の形態１におけるリソース割当要求部のフローチャート 本発明の実施の形態１における通信期間選択部のフローチャート 本発明の実施の形態１におけるパケット送信部のフローチャート 本発明の実施の形態１におけるリソース予約管理テーブルの状態図 本発明の実施の形態１における複数のパケット受信部を備えるパケット通信装置のブロック図 本発明の実施の形態２におけるパケット通信装置のブロック図 本発明の実施の形態２におけるリソース測定部のフローチャート 本発明の実施の形態２におけるリソース監視部のフローチャート 本発明の実施の形態２におけるリソース割当要求部のフローチャート 本発明の実施の形態２におけるリソース割当要求部のフローチャート 本発明の実施の形態２におけるパケット通信部のフローチャート 本発明の実施の形態２におけるリソース予約管理テーブルの状態図

符号の説明

１ ネットワーク
２ リソース予約管理テーブル
３ パケット受信部
４ リソース割当要求部
５ 通信期間選択部
６ パケット受信部
７ リソース測定部
８ リソース監視部
１０、１１、１２、１３ パケット通信装置
１５ 第２通信期間
１６ 第１通信期間
２０、２１、２２、２３ 端末
２０１、２１１ パケット

Claims (8)

1. 少なくともパケットの優先度による制御を行うと共にネットワークリソースの予約なしに通信できる第１通信期間と、ネットワークリソースの予約なしには通信できない第２通信期間とを、実質的にサポートするネットワークを構成するパケット通信装置であって、
   パケットを受信するパケット受信部と、
   前記ネットワークリソースの予約に関する情報を保持するリソース予約情報保持部と、
   前記リソース予約情報保持部が保持する前記情報を参照し、前記パケット受信部により受信された前記パケットが、前記ネットワークリソースの予約が必要なとき、前記パケットを前記第２通信期間を利用して送信するため前記ネットワークにリソース割当要求を発行するリソース割当要求部と、
   前記パケットを前記第１通信期間と前記第２通信期間とのいずれの通信期間を利用して通信するかを選択する通信期間選択部と、
   前記通信期間選択部により選択された通信期間を利用して前記パケットを送信するパケット送信部とを備え、
   前記通信期間選択部は、前記リソース割当要求部が発行する前記リソース割当要求による予約が完了するまで、前記第１通信期間を選択し、
   前記通信期間選択部は、前記リソース割当要求部が発行する前記リソース割当要求による予約が完了した後、前記第２通信期間を選択する、パケット通信装置。
2. 前記パケット受信部は、複数のパケット受信器のセットにより構成され、前記ネットワークリソースの予約が必要なパケットの優先度は、前記複数のパケット受信器のうちいずれのパケット受信器が前記ネットワークリソースの予約が必要なパケットを受信したかによって決定される、請求項１記載のパケット通信装置。
3. 前記リソース予約情報保持部に保持された前記情報により前記ネットワークリソースの予約が必要とされるパケットについて、現時点で必要な予約パラメータを測定するリソース測定部をさらに備える、請求項１または２記載のパケット通信装置。
4. 前記リソース予約情報保持部に保持された前記情報により前記ネットワークリソースの予約が必要とされるパケットについて、前記リソース割当要求部が発行したリソース割当要求に関する予約パラメータと、前記リソース測定部により測定された前記現時点で必要な予約パラメータとを比較し、ネットワークリソースの再予約が必要か否かを判定するリソース監視部をさらに備え、
   前記リソース監視部が前記ネットワークリソースの再予約が必要と判定したとき、前記リソース割当要求部は、前記現時点で必要な予約パラメータに基づくリソース割当要求を発行する、請求項３記載のパケット通信装置。
5. 前記リソース割当要求部が前記現時点で必要な予約パラメータに基づく前記リソース割当要求を発行した後、予約が完了するまでの間、前記ネットワークリソースの予約が必要とされるパケットを、前記第２通信期間だけで送信できない場合、前記第２の通信期間と前記第１通信期間との両方を利用して送信する、請求項４記載のパケット通信装置。
6. 少なくともパケットの優先度による制御を行うと共にネットワークリソースの予約なしに通信できる第１通信期間と、ネットワークリソースの予約なしには通信できない第２通信期間とを、実質的にサポートするネットワークを構成するパケット通信装置であって、
   パケットを受信するパケット受信部と、
   前記パケット受信部により受信されたパケットを、パケットの種類に応じて前記第１通信期間または前記第２通信期間を利用して送信するパケット送信部と、
   前記ネットワークリソースの予約が必要なパケットを前記第２通信期間を利用して通信するため、前記ネットワークに対してリソース割当要求を行うリソース割当要求部とを備え、
   前記パケット送信部は、前記リソース割当要求の進捗状況に応じて、前記前記ネットワークリソースの予約が必要なパケットの通信期間を変更する、パケット通信装置。
7. 前記パケット送信部は、前記リソース割当要求の進捗状況に応じて、前記前記ネットワークリソースの予約が必要なパケットの通信期間を、前記第１通信期間から前記第２通信期間へ変更する、請求項６記載のパケット通信装置。
8. 少なくともパケットの優先度による制御を行うと共にネットワークリソースの予約なしに通信できる第１通信期間と、ネットワークリソースの予約なしには通信できない第２通信期間とを、実質的にサポートするネットワークを利用するパケット通信方法であって、
   パケットを受信するステップと、
   前記ネットワークリソースの予約に関する情報を保持するステップと、
   前記保持された情報を参照し、前記受信された前記パケットが、前記ネットワークリソースの予約が必要なとき、前記パケットを前記第２通信期間を利用して送信するため前記ネットワークにリソース割当要求を発行するステップと、
   前記パケットを前記第１通信期間と前記第２通信期間とのいずれの通信期間を利用して通信するかを選択するステップと、
   前記選択された通信期間を利用して前記パケットを送信するステップとを備え、
   前記選択するステップでは、前記リソース割当要求による予約が完了するまで、前記第１通信期間を選択し、前記リソース割当要求による予約が完了した後、前記第２通信期間を選択する、パケット通信方法。

Images