パケット送信制御プログラム、パケット送信制御装置、及びパケット送信制御方法
【課題】ネットワーク全体で、パケットのデッドラインを保証した通信を行うことができる技術を提供する。
【解決手段】情報処理装置には周期的な通信タスクの送信順序を制御するパケットスケジューラが設けられる。また情報処理装置には利用可能通信帯域が与えられている。パケットスケジューラは、利用帯域が利用可能通信帯域を超えず、かつ、デッドラインモノトニック法によってデッドラインが保証できると判定された場合に、要求された通信タスクを実行する通信タスクとして登録する。この際、複数の通信タスクに係るパケットをＭＴＵの範囲内で連結して送信する。
【解決手段】情報処理装置には周期的な通信タスクの送信順序を制御するパケットスケジューラが設けられる。また情報処理装置には利用可能通信帯域が与えられている。パケットスケジューラは、利用帯域が利用可能通信帯域を超えず、かつ、デッドラインモノトニック法によってデッドラインが保証できると判定された場合に、要求された通信タスクを実行する通信タスクとして登録する。この際、複数の通信タスクに係るパケットをＭＴＵの範囲内で連結して送信する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、パケット送信制御プログラム、パケット送信制御装置、及びパケット送信制御方法に関する。
【背景技術】
【０００２】
従来、リアルタイムパケット通信においてデッドラインを考慮して、ＥＤＦ（Earliest
Deadline First）アルゴリズムに基づいてパケット通信を行う技術が知られている（特
許文献１，２）。ＥＤＦアルゴリズムとは、デッドラインが最も近い処理を優先して実行するアルゴリズムである。
【０００３】
また、ギガビットイーサのような高速ＬＡＮでは、パケット数が増大すると端末でのパケット処理能力不足により高速通信の利点を享受できない。そこで、より大きいサイズのパケット、いわゆるジャンボフレームが導入されている（特許文献３，４）。
【特許文献１】特表２００２−５４３５２０号公報
【特許文献２】特表２００３−５０５９３１号公報
【特許文献３】特開２００３−２２９９０５号公報
【特許文献４】特開２００５−５７３７３号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかしながら、デッドラインが最も近い処理を優先的に実行するＥＤＦ法では、パケットの送信要求の発生タイミングによっては、デッドラインが短く設定されたパケットが頻繁に送信されてしまい、他のパケット送信のデッドラインが保証できなくなるおそれがある。
【０００５】
また、ジャンボフレームを導入した場合であっても、送信する個々のデータサイズが小さい場合には、パケット数が増大してしまい効率的な通信が実現できない。
【０００６】
本発明は上記実情に鑑みてなされたものであって、その目的とするところは、効率的なパケット通信を実現し、かつ、ネットワークに接続されている情報処理装置におけるパケット送信のデッドラインを保証する技術を提供することにある。
【課題を解決するための手段】
【０００７】
上記目的を達成するために本発明では、以下の手段または処理によってデッドラインを保証した効率的なパケット通信を行う。
【０００８】
本発明に係るパケット送信制御プログラムは、ネットワークに接続された情報処理装置における、パケットの送信を制御するパケット送信制御プログラムである。本発明に係るパケット送信制御プログラムは、情報処理装置を、送信要求受付手段と、スケジュール可能性判定手段と、パケット制御手段として機能させる。
【０００９】
送信要求受付手段は、各周期においてデッドラインが定められた周期的なパケット送信の実行要求を受け付ける。
【００１０】
スケジュール可能性判定手段は、要求されたパケット送信のデッドラインを保証が可能か否か判定し、デッドライン保証可能であれば、要求されたパケット送信を、実行する通
信タスクとして登録する。
【００１１】
パケット制御手段は、登録された通信タスクのパケットを、通信タスクのデッドラインに応じた優先度で送信する。
【００１２】
スケジュール可能性判定手段は、すでに登録されている通信タスク及び要求されたパケット通信の全てについてデッドラインを保証でき、かつ、全てのデッドラインを保証するようにパケットを送信したときの単位時間あたりのパケットの転送量（データ転送量）が情報処理装置に与えられた所定の最大転送量以内となる場合に、要求されたパケット送信を、実行する通信タスクとして登録する。
【００１３】
このように、本発明に係るパケット送信制御プログラムは、各情報処理装置内でパケット送信のデッドラインを保証できるか否か判定し、さらに、各情報処理装置のパケット転送量が割り当てられた最大転送量以内であるか判定した上で、パケット送信要求を登録するか否か決定するので、ネットワーク内の全ての情報処理装置についてパケット送信のデッドラインを保証することが可能となる。
【００１４】
本発明におけるパケット制御手段は、さらに、パケット送信の際に複数の通信タスクに係るパケットを連結して送信する。すなわち、１つの通信タスクに係るパケットのみでは、１回に送信できるデータの最大値に満たない場合には、他の通信タスクに係るパケットを連結して送信する。
【００１５】
このように、複数の通信タスクに係るパケットを連結して送信することにより、パケットヘッダの処理に係るオーバヘッドの割合を少なくでき、したがって、効率的な通信を実現することが可能となる。
【００１６】
本発明におけるパケット制御手段は、さらに、複数の通信タスクに係るパケットを固定長に分割して、各通信タスクのデッドラインに応じた優先度に応じて連結して送信することが好適である。
【００１７】
このように、固定長に分割することで、１回に送信できるデータの最大値いっぱいまで、パケットを連結して送信することが可能となる。また、優先度の高い通信タスクが後から登録された場合に、この通信タスクに係るパケットを優先的に送信することもできる。
【００１８】
本発明におけるスケジュール可能性判定手段は、デッドラインモノトニック（Deadline
Monotonic）法によって、すでに登録された通信タスク及び要求されたパケット送信の全てについてデッドライン保証が可能であるか判定することが好適である。
【００１９】
より具体的には、送信要求受付手段が受け付けるパケット送信要求には、情報として、パケット送信の送信周期、１周期あたりの送信データ量及び各周期におけるデッドラインが含まれることが好ましい。ここで、各周期におけるデッドラインは送信周期と同じか送信周期よりも短い時間である。
【００２０】
まず、スケジュール可能性判定手段は、１周期あたりの送信データ量及びネットワークの実効通信速度から、要求されたパケット送信に要する送信所要時間を算出する。次に、スケジュール可能性判定手段は、送信周期、算出した送信所要時間、及びデッドラインを用いてデッドラインモノトニック法によって、スケジュール可能性を判定する。
【００２１】
なお、スケジュール可能性判定手段は、送信周期、送信所要時間、及びデッドラインが、デッドライン保証可能な必要十分条件を満たすか否かを判定する必要はなく、デッドラ
イン保証可能なための十分条件を満たすか否かのみを判定するようにしても良い。デッドラインモノトニック法では、必要十分条件の判定は複雑であり処理に時間を要するため、処理の軽い十分条件での判定を用いることも好ましい。
【００２２】
本発明に係るパケット送信制御プログラムが設けられている情報処理装置に割り当てられる所定の最大転送量は、設定情報として情報処理装置にあらかじめ与えられたり、各情報処理装置の全体送信量管理サーバから与えられたりすることが好ましい。
【００２３】
また、最大転送量は常に同じ値である必要はなく、パケット送信制御プログラムは、すでに登録された通信タスク及び要求されたパケット送信の全てについてデッドラインを保証するようにパケットを送信したときの単位時間あたりの転送量が最大転送量を超える場合には、全体送信量管理サーバに対して最大転送量の増加を求めることが好ましい。
【００２４】
なお、本発明は、上記処理の少なくとも一部を有するパケット送信制御プログラムとして捉えることができる。また、本発明は、上記手段の少なくとも一部を含むパケット送信制御装置、または、上記処理の少なくとも一部を含むパケット送信制御方法として捉えることができる。上記手段及び処理の各々は可能な限り互いに組み合わせて本発明を構成することができる。
【００２５】
たとえば、本発明の一態様としてのパケット送信制御装置は、ネットワークに接続された情報処理装置における、パケットの送信を制御するパケット送信制御装置であって、各周期においてデッドラインが定められた周期的なパケット送信の実行要求を受け付ける送信要求受付手段と、前記要求されたパケット送信のデッドライン保証が可能か否か判定し、デッドライン保証可能であれば、該要求されたパケット送信を、実行する通信タスクとして登録するスケジュール可能性判定手段と、前記登録された通信タスクのパケットを、該通信タスクのデッドラインに応じた優先度で送信するパケット制御手段と、を有し、前記スケジュール可能性判定手段は、すでに登録された通信タスク及び前記要求されたパケット送信の全てについてデッドラインを保証でき、かつ、全てのデッドラインを保証するようにパケットを送信したときの単位時間あたりの転送量が所定の最大転送量以内となる場合に、前記要求されたパケット送信を、実行する通信タスクとして登録し、前記パケット制御手段は、複数の通信タスクに係るパケットを連結して送信することを特徴とする。
【００２６】
また、本発明の一態様としてのパケット送信制御方法は、ネットワークに接続された情報処理装置における、パケットの送信を制御するパケット送信制御方法であって、前記情報処理装置が、各周期においてデッドラインが定められた周期的なパケット送信の実行要求を受け付け、すでに登録された通信タスク及び前記要求されたパケット送信の全てについてデッドラインを保証でき、かつ、全てのデッドラインを保証するようにパケットを送信したときの単位時間あたりの転送量が所定の最大転送量以内となる場合に、前記要求されたパケット送信を、実行する通信タスクとして登録し、前記登録された複数の通信タスクに係るパケットを、該通信タスクのデッドラインに応じた優先度で連結して送信することを特徴とする。
【発明の効果】
【００２７】
本発明によれば、効率的な通信が可能になるとともに、ネットワークに接続されている情報処理装置におけるパケット送信のデッドラインを保証することが可能となる。
【発明を実施するための最良の形態】
【００２８】
以下に図面を参照して、この発明の好適な実施の形態を例示的に詳しく説明する。
【００２９】
［第１の実施形態］
＜システム概要＞
図１は、本実施形態に係るパケットスケジューラ（パケット送信制御プログラム）を実行する情報処理装置のネットワークシステムを示す図である。複数の情報処理装置１ａ、１ｂ、１ｃがネットワーク３を介して接続されており、各情報処理装置は互いにパケット通信を行う。ここで、情報処理装置１ｃは、各情報処理装置１ａ，１ｂ，１ｃのそれぞれが単位時間あたりに送信できるパケットの最大転送量を管理する全体送信量管理サーバとしての機能も兼ねる。
【００３０】
図２は、パケットスケジューラを実行する情報処理装置１の構成を示す図である。情報処理装置１は、ＣＰＵ１１，タイマ１２，ハードディスク装置などの補助記憶装置１３、読み書き可能メモリ（ＲＡＭ）などのメモリ１４、及びネットワーク制御部１５を有する。これらの各要素は、バスを介して互いに接続されている。
【００３１】
タイマ１２は、情報処理装置１における現在時刻（システム時刻）を刻むものである。パケットスケジューラは、このタイマ１２のシステム時刻に基づいてパケット送信の制御を行う。
【００３２】
補助記憶装置１３には、パケットスケジューラやその他アプリケーションのプログラムが格納されている。これらのソフトウェアは、補助記憶装置１３からメモリ１４に、必要に応じて適宜読み出され、ＣＰＵ１１によって実行される。なお、メモリ１４には、パケットスケジューラが管理する通信タスクについての情報（周期、データ転送量、デッドライン、優先度など）や、情報処理装置１が単位時間あたりに送信（送出）できる最大転送量などが記憶される。
【００３３】
情報処理装置１は、ネットワーク制御部１５を介してネットワーク３と接続されている。
【００３４】
上述したように図１の情報処理装置１ｃは全体送信量管理サーバとしての機能も兼ねる。全体送信量管理サーバは、ネットワーク３に接続された各情報処理装置が単位時間あたりに送信できる最大転送量を決定する機能を有する。このように、全体送信量管理サーバは、各情報処理装置の最大転送量を決定することで、ネットワーク全体で、過剰な通信が発生することを防止する。
【００３５】
＜機能構成＞
図３は、パケットスケジューラを実行する情報処理装置１の機能ブロック図である。パケットスケジューラの機能は、送信要求受付部２１，最大転送量取得部２２，通信速度取得部２６，スケジュール可能性判定部２３，及びパケット制御部２５から構成される。なお、これらの各部は、パケット送信制御プログラムがＣＰＵ１１によって実行されることによって、その機能が実現される。
【００３６】
送信要求受付部２１は、アプリケーションプログラム４からパケット送信の実行要求を受け付ける。パケットスケジューラは、ＩＰ（Internet Protocol）層上で機能するプロ
グラムであるので、アプリケーションプログラム４と送信要求受付部２１の間には、ＴＣＰ（Transmission Control Protocol）やＵＤＰ（User Datagram Protocol）などのトラ
ンスポート層および、さらにその上位のアプリケーション層が存在し、これらのプロトコル層を実装するプログラムが仲介するが、図３では省略している。
【００３７】
送信要求受付部２１が受け付けるパケット送信の要求は、各周期ごとに所定のデータ量を送信する必要があり、送信開始から所定の時間（デッドライン）以内にパケットの送信を完了する必要がある。
【００３８】
図４は、周期的なパケット送信の通信タスクを説明する図である。図４（ａ）に示すように、一定周期Ｔごとに所定量のパケットを送信する必要がある。また、この送信を完了する制限時間であるデッドラインＤが定められている。なお、パケットの送信はデッドライン以内に完了すれば、正しく処理されたものとみなされる。したがって、図４（ｂ）に示すように、複数の通信タスクが存在する状況では、それぞれの通信タスクは１周期内で連続して全てのデータを送信する必要はなく、分割して送信することになってもかまわない。
【００３９】
最大転送量取得部２２は、情報処理装置１が単位時間あたりに送信することを許可された最大量である最大転送量を、全体送信量管理サーバから取得する。上述したように、全体送信量管理サーバは、各情報処理装置の最大転送量を決定する。本実施形態では、最大転送量は全体送信量管理サーバから情報処理装置１に対して通信によって通知される。
【００４０】
通信速度取得部２６は、ネットワーク３の実効通信速度を取得する。実効通信速度は、実測によって取得してもよく、あらかじめ定められた設定値を使用することもできる。
【００４１】
スケジュール可能性判定部２３は、送信要求受付部２１が受け付けたパケット送信の要求が、デッドラインを守って送信することができるか否か判定する。デッドライン保証可能であれば、通信タスク管理テーブル２４に、実行すべき通信タスクとして登録する。スケジュール可能性判定部２３の機能の詳細については後述する。
【００４２】
パケット制御部２５は、通信タスク管理テーブル２４に格納されている情報に基づいて、パケット送信を行う。パケット送信の通信タスクは、デッドラインが短いものほど優先度が高く設定され、パケット制御部２５はこの優先度に基づいて送信するパケットを選択する。
【００４３】
なお、パケット制御部２５は、１回に送信できるデータの最大値が定められている。この最大値は、ＭＴＵ（Maximum Transfer Unit）と呼ばれる。本実施形態においては、Ｍ
ＴＵの値として、イーサネット（登録商標）の標準規格である１５１８バイト（オクテット）よりも大きい１６０００バイトを使用する。なお、本発明において具体的なＭＴＵのサイズは、これに限定されるものではない。
【００４４】
パケット制御部２５は、送信するパケットがＭＴＵよりも大きい場合には、ＭＴＵサイズに分割した上で送信する。逆に、パケット制御部２５は、送信するパケットがＭＴＵサイズに満たない場合には、ＭＴＵサイズ内で連結して送信できる他のパケットがあればパケットを連結して送信する。
【００４５】
＜処理フロー＞
（スケジュール可能性判定処理）
次に図５を用いて、スケジュール可能性判定部２３が行う、スケジュール可能性判定処理について説明する。
【００４６】
スケジュール可能性判定部２３は、まずステップＳ１０１で、送信要求受付部２１が受け付けたパケット送信と、すでに実行する通信タスクとして通信タスク管理テーブル２４に格納されているタスクとを合計した場合の、単位時間あたりのデータ転送量を算出する。これは、Σ（各送信の送信データ量／周期）によって求めることができる。なお、（送信データ量）／（周期）は、ＭＴＵ（Maximum Transfer Unit）単位に切り上げる。
【００４７】
次に、ステップＳ１０２で、算出した単位時間あたりのデータ転送量が、最大転送量取
得部２２が取得した最大転送量以内であるか判定する。ここで、算出したデータ転送量が、最大転送量を超える転送量となる場合には、ステップＳ１０６に進み、受け付けたパケット送信を登録しないで、その実行を拒否する。算出したデータ転送量が、最大転送量以内である場合は、ステップＳ１０３に進む。
【００４８】
ステップＳ１０３では、要求されたパケット送信の１周期の送信に要する送信所要時間を計算する。送信所要時間は、１周期あたりのデータ転送量を、通信速度取得部２６が取得したネットワーク３の通信速度で割ることによって求めることができる。（送信所要時間）＝（１周期あたりのデータ転送量）／（ネットワークの通信速度）。なお、１周期あたりのデータ転送量は、ＭＴＵ単位で切り上げて使用する。
【００４９】
スケジュール可能性判定部２３は、ステップＳ１０４で、デッドラインモノトニック法を利用して、すでに登録された通信タスク及び要求されたパケット送信についてデッドラインを保証できるか判定を行う。
【００５０】
デッドラインモノトニック法では、各パケット送信の周期、１周期あたりの送信所要時間、及びデッドラインを用いる。これらの情報に基づいてスケジュール可能性を判定する判断方法については、既知の如何なる方法を用いてもかまわない。例えば、スケジュール可能性の必要十分条件となる判定式を用いても良いし、十分条件を用いても良い。
【００５１】
スケジュール可能性の十分条件を表す判定式としては、例えば、以下の判定式を用いることができる。
【００５２】
【数１】
【００５３】
なお、Ｔｉ，Ｃｉ，Ｄｉは、それぞれ通信タスクｉの送信周期、送信所要時間、デッドラインである。また、通信タスクｉは、ｉ＝１の通信タスクが最も優先度が高く、ｉが大きくなるにしたがって優先度が小さくなる。
【００５４】
また、
【数２】
は、ｘ以上の最小整数を表す。
【００５５】
この他の判定式については、例えば、以下の文献などに記載されている。
【００５６】
Audsley, Burns, Richardson, Wellings, "Hard Real-Time Scheduling: The Deadline-Monotonic Approach", Proceedings of the 8th IEEE Workshop on Real-Time Operating Systems and Software, 1991
【００５７】
このような判定式にしたがってスケジュール可能性の判定を行い、すでに登録された通
信タスクと要求された通信タスクの全てについてデッドラインを守ることができる場合には、ステップＳ１０５に進んで、要求されたパケット送信を、実行する通信タスクとして、通信タスク管理テーブル２４に格納する。デッドラインを保証できない場合には、ステップＳ１０６に進み、受け付けたパケット送信を登録せず、その実行を拒否する。
【００５８】
（パケット送信処理）
次に、図６を用いて、パケット制御部２５が行うパケット送信処理について説明する。パケット制御部２５は、通信タスク管理テーブル２４に格納されている周期やデッドラインなどの情報に基づいてパケットの送信順序を制御する。また、パケット送信を効率的に行えるように、１つの通信タスクに係るパケットだけではＭＴＵサイズに満たない場合には、他の通信タスクに係るパケットを連結して送信する。
【００５９】
パケット制御部２５は、ステップＳ２０１で、通信タスク管理テーブル２４を参照して、最も優先度が高く、かつ、パケット送信が完了していない通信タスクを選択する。なお、上述したように、通信タスクの優先度は、デッドラインが短いものほど優先度が高く設定されている。
【００６０】
ここで、パケット制御部２５は選択したパケットのサイズを計測する。なお、送信するパケットがＭＴＵサイズよりも大きい場合には、ＭＴＵサイズに分割して送信する。一方、送信するパケットがＭＴＵサイズよりも小さい場合には、他のデータを連結して１つのパケットとして送信する余地がある。
【００６１】
そこで、パケット制御部２５は、ステップＳ２０２で、送信するパケットに空きがあるか判定する。すなわち、計測したパケットサイズがＭＴＵサイズよりも小さいか判定する。ここで、ある閾値を設けて、次送信パケットにこの閾値以上の空きがあるか判定することが好ましい。
【００６２】
次送信パケットに空きがある場合（Ｓ２０２−ＹＥＳ）には、ステップＳ２０３へ進み、空き部分に入るデータが存在するか判定する。具体的には、パケット制御部２５は、通信タスク管理テーブル２４を参照して、優先度の高い通信タスクから順番に、送信データのサイズが空きサイズよりも小さい通信タスクが存在するか検査する。なお、パケット制御部２５は、通信タスク管理テーブル２４に登録されている全ての通信タスクを対象に検査を行っても良いが、優先度の高いものから所定の数の通信タスクについてのみ検査を行っても良い。連結するパケットの対象を絞ることで、優先度の逆転防止と通信の効率化のバランスを図ることができる。
【００６３】
空き部分に入るデータが存在する場合（Ｓ２０４−ＹＥＳ）は、ステップＳ２０５へ進み、次送信の空き部分に該当データを追加する。その後、ステップＳ２０２に戻り、再び次に送信するパケットに空きがあるかチェックする。一方、空き部分に入るデータが存在しない場合（Ｓ２０４−ＮＯ）は、ステップＳ２０６へ進み、パケットを送信する。
【００６４】
また、ステップＳ２０２において、次送信パケットに空きがないと判定された場合（Ｓ２０２−ＮＯ）は、ステップＳ２０６へ進み、その状態でパケットを送信する。
【００６５】
図７（ａ）に示すように４つの通信タスクに係るデータが送信待ちの場合を例にして、より具体的な説明を行う。通信タスクＡ〜Ｄは、通信タスクＡが最も優先度が高く、通信タスクＤが最も優先度が低いものとする。ここでは、まず通信タスクＡが送信されるデータとして選択されるが、送信パケットには空きがある。そこで、空き部分に入るデータが存在するか優先度が高いものから順に調べると、通信タスクＢが連結できることが分かる。通信タスクＢを連結してもまだ空きがあるので、さらに追加できるデータがあるか調べ
ると、通信タスクＣを連結するとＭＴＵサイズを超えるので連結できないが、通信タスクＤは連結できることが分かる。通信タスクＡ，Ｂ，Ｄを連結した後はこれ以上空きがないので、この状態でパケットが送信されることになる。
【００６６】
（実施形態の効果）
本実施形態では、各情報処理装置が送信するデータ量は、全体送信量管理サーバによって管理される。さらに、各情報処理装置は、利用可能な転送量の範囲内で、デッドラインモノトニック法によってデッドライン以内に通信を完了することが保証された通信タスクのみを受け入れる。したがって、ネットワークシステム全体で、デッドラインを守ってパケット送信することができる。
【００６７】
また、通信タスクに係るデータのサイズがＭＴＵサイズに比して小さい場合に、複数の通信タスクに係るデータを連結して送信するため、効率的な通信が実現できる。
【００６８】
［第２の実施形態］
第２の実施形態は、パケット制御部２５の送信処理が異なるだけであり、その他については第１の実施形態と同様であるので、同様の部分については説明を省略する。
【００６９】
本実施形態では、パケット制御部２５は、送信予定のデータを、ＭＴＵよりも小さい固定長のサイズに分割した上で（以下、分割されたデータをセルという）、優先度にしたがってセルを連結してＭＴＵサイズ分のパケットを生成して送信する。なお、本実施形態においてはセル長として５３バイトを採用するが、その他どのようなセル長を採用しても良い。
【００７０】
図８（ａ）に示すように、４つの通信タスクに係るデータが送信待ちの場合を例にして具体的に説明を行う。通信タスクＡ〜Ｄは、通信タスクＡが最も優先度が高く、通信タスクＤが最も優先度が低いものとする。まず、各通信タスクに係るデータは、セルに分割される。たとえば、通信タスクＡに係るデータは、Ａ１〜Ａ４の４つのセルに分割される。
【００７１】
次に、パケット制御部２５は、優先度の高い通信タスクに係るセルから順番に、次に送信するパケットに連結していく。このような方法によって生成される送信パケットは、図８（ｂ）に示すように、セルＡ１〜Ａ４，Ｂ１，Ｃ１〜Ｃ４から構成される。この図は、生成されるパケットの一例であるが、以下の２つの利点がある。まず、第一に固定長のセルに分割しているので、優先度の逆転が発生しない。第二に、セルサイズを小さくすることで、送信パケットをＭＴＵいっぱいまで有効に利用することができる。
【００７２】
また、パケット制御部２５がパケット生成処理を行っている間に、優先度の高い新しい通信タスクが登録された場合に、その通信タスクに係るデータを優先して送信することができる。
【００７３】
このように、本実施形態によれば、優先度の逆転が極力起こらず、より効率的な通信が可能となる。
【００７４】
［第３の実施形態］
第３の実施形態は、スケジュール可能性判定部２３が行う処理（図５参照）が異なるだけであり、その他については第１または第２の実施形態と同様であるので、同様の部分については説明を省略する。
【００７５】
図９は、第３の実施形態におけるスケジュール可能性判定部２３のスケジュール可能性判定処理を示すフローチャートである。図９の処理のうち、第１の実施形態と異なる部分
について詳しく説明する。
【００７６】
第１の実施形態と同様に、ステップＳ３０２で、要求されたパケット送信とすでに登録された通信タスクを合計した場合に必要となる単位時間あたりのデータ転送量が、情報処理装置１に割り当てられた最大転送量以内であるか判断する。必要となる単位時間あたりのデータ転送量が最大転送量を超える場合には、ステップＳ３０３に進む。
【００７７】
ステップＳ３０３では、最大転送量取得部２２が、最大転送量の増加を全体送信量管理サーバに対して要求する。ここで、新たに要求する最大転送量は、ステップＳ３０２で求めた必要となる単位時間あたりのデータ転送量以上である。ステップＳ３０４で、全体送信量管理サーバへの要求が認められたか否か判定する。要求が認められた場合には、ステップＳ３０５に進んで、デッドラインモノトニック法によるスケジュール可能性判定を行う。要求が認められなかった場合には、ステップＳ３０８に進んで、要求されたパケット送信を拒否する。
【００７８】
全体送信量管理サーバは、ネットワーク全体での単位時間あたりに送信可能なデータ量（利用可能帯域）および、各情報処理装置が単位時間あたりに送信する最大送信データ量を管理しているため、帯域に余裕がある場合には、情報処理装置１からの最大転送量を増加する要求を受け入れることができる。
【００７９】
このように、第３の実施形態では、各情報処理装置が単位時間あたりに送信することのできる、データ量を必要に応じて増やすことができるので、より柔軟なスケジューリングが可能となる。
【００８０】
なお、このように最大転送量の増加を認める場合には、情報処理装置１が必要とする転送量が最大転送量よりも低くなった場合に、最大転送量を低下させる要求を全体送信量管理サーバに対して通知することが、ネットワーク資源の有効活用の観点から有効であることは言うまでもない。
【００８１】
［第４の実施形態］
第４の実施形態は、情報処理装置が、複数のネットワークに接続されている実施形態である。図１０に示すように、情報処理装置６は、複数のネットワーク制御部１５ａ，１５ｂ，１５ｃを介して複数のネットワークに接続されている。この場合、情報処理装置６を含むネットワークシステムの全体は図１１のようになる。図１１において、情報処理装置６は、ネットワーク７ａ，７ｂ，７ｃに接続されている。これら複数のネットワークとしては、例えば、イーサネット（登録商標）、携帯電話、光通信、無線通信などが挙げられる。
【００８２】
この場合、情報処理装置６は、ネットワークごとに通信タスク管理テーブルを有する。スケジュール可能性判定部２３は、送信相手先のネットワークに応じた通信タスク管理テーブルを用いて、上記実施形態と同様のスケジュール可能性判定処理を行うことで、それぞれのネットワークでデッドラインを保証した通信を行うことが可能となる。
【００８３】
なお、図１１では複数のネットワークに接続された情報処理装置は１台だけであるが、複数あってもかまわないことは明らかである。
【００８４】
［変形例］
上記実施例においては、情報処理装置が単位時間あたりに送信できるデータ量の最大値は、全体送信量管理サーバから取得していた。しかし、必ずしもそのように構成する必要はなく、最大転送量は設定ファイルなどによる設定情報として、情報処理装置にあらかじ
め与えられていても良い。
【図面の簡単な説明】
【００８５】
【図１】第１の実施形態におけるパケットスケジューラが利用されるネットワークシステムの概要図である。
【図２】第１の実施形態におけるパケットスケジューラを実行する情報処理装置の構成を示す図である。
【図３】第１の実施形態におけるパケットスケジューラの機能ブロック図である。
【図４】周期タスクを説明する模式図である。
【図５】第１の実施形態におけるスケジュール可能性判定処理を示すフローチャートである。
【図６】第１の実施形態におけるパケット送信制御を処理を示すフローチャートである。
【図７】第１の実施形態におけるパケットの連結処理を説明する図である。
【図８】第２の実施形態におけるパケットの連結処理を説明する図である。
【図９】第３の実施形態におけるスケジュール可能性判定処理を示すフローチャートである。
【図１０】第４の実施形態におけるパケットスケジューラを実行する情報処理装置の構成を示す図である。
【図１１】第４の実施形態におけるパケットスケジューラが利用されるネットワークシステムの概要図である。
【符号の説明】
【００８６】
１ 情報処理装置
２ パケットスケジューラ
３ ネットワーク
４ アプリケーションプログラム
６ 情報処理装置
７ ネットワーク
１１ ＣＰＵ
１２ タイマ
１３ 補助記憶装置
１４ メモリ
１５ ネットワーク制御部
２１ 送信要求受付部
２２ 最大転送量取得部
２３ スケジュール可能性判定部
２４ 通信タスク管理テーブル
２５ パケット制御部
２６ 通信速度取得部
【技術分野】
【０００１】
本発明は、パケット送信制御プログラム、パケット送信制御装置、及びパケット送信制御方法に関する。
【背景技術】
【０００２】
従来、リアルタイムパケット通信においてデッドラインを考慮して、ＥＤＦ（Earliest
Deadline First）アルゴリズムに基づいてパケット通信を行う技術が知られている（特
許文献１，２）。ＥＤＦアルゴリズムとは、デッドラインが最も近い処理を優先して実行するアルゴリズムである。
【０００３】
また、ギガビットイーサのような高速ＬＡＮでは、パケット数が増大すると端末でのパケット処理能力不足により高速通信の利点を享受できない。そこで、より大きいサイズのパケット、いわゆるジャンボフレームが導入されている（特許文献３，４）。
【特許文献１】特表２００２−５４３５２０号公報
【特許文献２】特表２００３−５０５９３１号公報
【特許文献３】特開２００３−２２９９０５号公報
【特許文献４】特開２００５−５７３７３号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかしながら、デッドラインが最も近い処理を優先的に実行するＥＤＦ法では、パケットの送信要求の発生タイミングによっては、デッドラインが短く設定されたパケットが頻繁に送信されてしまい、他のパケット送信のデッドラインが保証できなくなるおそれがある。
【０００５】
また、ジャンボフレームを導入した場合であっても、送信する個々のデータサイズが小さい場合には、パケット数が増大してしまい効率的な通信が実現できない。
【０００６】
本発明は上記実情に鑑みてなされたものであって、その目的とするところは、効率的なパケット通信を実現し、かつ、ネットワークに接続されている情報処理装置におけるパケット送信のデッドラインを保証する技術を提供することにある。
【課題を解決するための手段】
【０００７】
上記目的を達成するために本発明では、以下の手段または処理によってデッドラインを保証した効率的なパケット通信を行う。
【０００８】
本発明に係るパケット送信制御プログラムは、ネットワークに接続された情報処理装置における、パケットの送信を制御するパケット送信制御プログラムである。本発明に係るパケット送信制御プログラムは、情報処理装置を、送信要求受付手段と、スケジュール可能性判定手段と、パケット制御手段として機能させる。
【０００９】
送信要求受付手段は、各周期においてデッドラインが定められた周期的なパケット送信の実行要求を受け付ける。
【００１０】
スケジュール可能性判定手段は、要求されたパケット送信のデッドラインを保証が可能か否か判定し、デッドライン保証可能であれば、要求されたパケット送信を、実行する通
信タスクとして登録する。
【００１１】
パケット制御手段は、登録された通信タスクのパケットを、通信タスクのデッドラインに応じた優先度で送信する。
【００１２】
スケジュール可能性判定手段は、すでに登録されている通信タスク及び要求されたパケット通信の全てについてデッドラインを保証でき、かつ、全てのデッドラインを保証するようにパケットを送信したときの単位時間あたりのパケットの転送量（データ転送量）が情報処理装置に与えられた所定の最大転送量以内となる場合に、要求されたパケット送信を、実行する通信タスクとして登録する。
【００１３】
このように、本発明に係るパケット送信制御プログラムは、各情報処理装置内でパケット送信のデッドラインを保証できるか否か判定し、さらに、各情報処理装置のパケット転送量が割り当てられた最大転送量以内であるか判定した上で、パケット送信要求を登録するか否か決定するので、ネットワーク内の全ての情報処理装置についてパケット送信のデッドラインを保証することが可能となる。
【００１４】
本発明におけるパケット制御手段は、さらに、パケット送信の際に複数の通信タスクに係るパケットを連結して送信する。すなわち、１つの通信タスクに係るパケットのみでは、１回に送信できるデータの最大値に満たない場合には、他の通信タスクに係るパケットを連結して送信する。
【００１５】
このように、複数の通信タスクに係るパケットを連結して送信することにより、パケットヘッダの処理に係るオーバヘッドの割合を少なくでき、したがって、効率的な通信を実現することが可能となる。
【００１６】
本発明におけるパケット制御手段は、さらに、複数の通信タスクに係るパケットを固定長に分割して、各通信タスクのデッドラインに応じた優先度に応じて連結して送信することが好適である。
【００１７】
このように、固定長に分割することで、１回に送信できるデータの最大値いっぱいまで、パケットを連結して送信することが可能となる。また、優先度の高い通信タスクが後から登録された場合に、この通信タスクに係るパケットを優先的に送信することもできる。
【００１８】
本発明におけるスケジュール可能性判定手段は、デッドラインモノトニック（Deadline
Monotonic）法によって、すでに登録された通信タスク及び要求されたパケット送信の全てについてデッドライン保証が可能であるか判定することが好適である。
【００１９】
より具体的には、送信要求受付手段が受け付けるパケット送信要求には、情報として、パケット送信の送信周期、１周期あたりの送信データ量及び各周期におけるデッドラインが含まれることが好ましい。ここで、各周期におけるデッドラインは送信周期と同じか送信周期よりも短い時間である。
【００２０】
まず、スケジュール可能性判定手段は、１周期あたりの送信データ量及びネットワークの実効通信速度から、要求されたパケット送信に要する送信所要時間を算出する。次に、スケジュール可能性判定手段は、送信周期、算出した送信所要時間、及びデッドラインを用いてデッドラインモノトニック法によって、スケジュール可能性を判定する。
【００２１】
なお、スケジュール可能性判定手段は、送信周期、送信所要時間、及びデッドラインが、デッドライン保証可能な必要十分条件を満たすか否かを判定する必要はなく、デッドラ
イン保証可能なための十分条件を満たすか否かのみを判定するようにしても良い。デッドラインモノトニック法では、必要十分条件の判定は複雑であり処理に時間を要するため、処理の軽い十分条件での判定を用いることも好ましい。
【００２２】
本発明に係るパケット送信制御プログラムが設けられている情報処理装置に割り当てられる所定の最大転送量は、設定情報として情報処理装置にあらかじめ与えられたり、各情報処理装置の全体送信量管理サーバから与えられたりすることが好ましい。
【００２３】
また、最大転送量は常に同じ値である必要はなく、パケット送信制御プログラムは、すでに登録された通信タスク及び要求されたパケット送信の全てについてデッドラインを保証するようにパケットを送信したときの単位時間あたりの転送量が最大転送量を超える場合には、全体送信量管理サーバに対して最大転送量の増加を求めることが好ましい。
【００２４】
なお、本発明は、上記処理の少なくとも一部を有するパケット送信制御プログラムとして捉えることができる。また、本発明は、上記手段の少なくとも一部を含むパケット送信制御装置、または、上記処理の少なくとも一部を含むパケット送信制御方法として捉えることができる。上記手段及び処理の各々は可能な限り互いに組み合わせて本発明を構成することができる。
【００２５】
たとえば、本発明の一態様としてのパケット送信制御装置は、ネットワークに接続された情報処理装置における、パケットの送信を制御するパケット送信制御装置であって、各周期においてデッドラインが定められた周期的なパケット送信の実行要求を受け付ける送信要求受付手段と、前記要求されたパケット送信のデッドライン保証が可能か否か判定し、デッドライン保証可能であれば、該要求されたパケット送信を、実行する通信タスクとして登録するスケジュール可能性判定手段と、前記登録された通信タスクのパケットを、該通信タスクのデッドラインに応じた優先度で送信するパケット制御手段と、を有し、前記スケジュール可能性判定手段は、すでに登録された通信タスク及び前記要求されたパケット送信の全てについてデッドラインを保証でき、かつ、全てのデッドラインを保証するようにパケットを送信したときの単位時間あたりの転送量が所定の最大転送量以内となる場合に、前記要求されたパケット送信を、実行する通信タスクとして登録し、前記パケット制御手段は、複数の通信タスクに係るパケットを連結して送信することを特徴とする。
【００２６】
また、本発明の一態様としてのパケット送信制御方法は、ネットワークに接続された情報処理装置における、パケットの送信を制御するパケット送信制御方法であって、前記情報処理装置が、各周期においてデッドラインが定められた周期的なパケット送信の実行要求を受け付け、すでに登録された通信タスク及び前記要求されたパケット送信の全てについてデッドラインを保証でき、かつ、全てのデッドラインを保証するようにパケットを送信したときの単位時間あたりの転送量が所定の最大転送量以内となる場合に、前記要求されたパケット送信を、実行する通信タスクとして登録し、前記登録された複数の通信タスクに係るパケットを、該通信タスクのデッドラインに応じた優先度で連結して送信することを特徴とする。
【発明の効果】
【００２７】
本発明によれば、効率的な通信が可能になるとともに、ネットワークに接続されている情報処理装置におけるパケット送信のデッドラインを保証することが可能となる。
【発明を実施するための最良の形態】
【００２８】
以下に図面を参照して、この発明の好適な実施の形態を例示的に詳しく説明する。
【００２９】
［第１の実施形態］
＜システム概要＞
図１は、本実施形態に係るパケットスケジューラ（パケット送信制御プログラム）を実行する情報処理装置のネットワークシステムを示す図である。複数の情報処理装置１ａ、１ｂ、１ｃがネットワーク３を介して接続されており、各情報処理装置は互いにパケット通信を行う。ここで、情報処理装置１ｃは、各情報処理装置１ａ，１ｂ，１ｃのそれぞれが単位時間あたりに送信できるパケットの最大転送量を管理する全体送信量管理サーバとしての機能も兼ねる。
【００３０】
図２は、パケットスケジューラを実行する情報処理装置１の構成を示す図である。情報処理装置１は、ＣＰＵ１１，タイマ１２，ハードディスク装置などの補助記憶装置１３、読み書き可能メモリ（ＲＡＭ）などのメモリ１４、及びネットワーク制御部１５を有する。これらの各要素は、バスを介して互いに接続されている。
【００３１】
タイマ１２は、情報処理装置１における現在時刻（システム時刻）を刻むものである。パケットスケジューラは、このタイマ１２のシステム時刻に基づいてパケット送信の制御を行う。
【００３２】
補助記憶装置１３には、パケットスケジューラやその他アプリケーションのプログラムが格納されている。これらのソフトウェアは、補助記憶装置１３からメモリ１４に、必要に応じて適宜読み出され、ＣＰＵ１１によって実行される。なお、メモリ１４には、パケットスケジューラが管理する通信タスクについての情報（周期、データ転送量、デッドライン、優先度など）や、情報処理装置１が単位時間あたりに送信（送出）できる最大転送量などが記憶される。
【００３３】
情報処理装置１は、ネットワーク制御部１５を介してネットワーク３と接続されている。
【００３４】
上述したように図１の情報処理装置１ｃは全体送信量管理サーバとしての機能も兼ねる。全体送信量管理サーバは、ネットワーク３に接続された各情報処理装置が単位時間あたりに送信できる最大転送量を決定する機能を有する。このように、全体送信量管理サーバは、各情報処理装置の最大転送量を決定することで、ネットワーク全体で、過剰な通信が発生することを防止する。
【００３５】
＜機能構成＞
図３は、パケットスケジューラを実行する情報処理装置１の機能ブロック図である。パケットスケジューラの機能は、送信要求受付部２１，最大転送量取得部２２，通信速度取得部２６，スケジュール可能性判定部２３，及びパケット制御部２５から構成される。なお、これらの各部は、パケット送信制御プログラムがＣＰＵ１１によって実行されることによって、その機能が実現される。
【００３６】
送信要求受付部２１は、アプリケーションプログラム４からパケット送信の実行要求を受け付ける。パケットスケジューラは、ＩＰ（Internet Protocol）層上で機能するプロ
グラムであるので、アプリケーションプログラム４と送信要求受付部２１の間には、ＴＣＰ（Transmission Control Protocol）やＵＤＰ（User Datagram Protocol）などのトラ
ンスポート層および、さらにその上位のアプリケーション層が存在し、これらのプロトコル層を実装するプログラムが仲介するが、図３では省略している。
【００３７】
送信要求受付部２１が受け付けるパケット送信の要求は、各周期ごとに所定のデータ量を送信する必要があり、送信開始から所定の時間（デッドライン）以内にパケットの送信を完了する必要がある。
【００３８】
図４は、周期的なパケット送信の通信タスクを説明する図である。図４（ａ）に示すように、一定周期Ｔごとに所定量のパケットを送信する必要がある。また、この送信を完了する制限時間であるデッドラインＤが定められている。なお、パケットの送信はデッドライン以内に完了すれば、正しく処理されたものとみなされる。したがって、図４（ｂ）に示すように、複数の通信タスクが存在する状況では、それぞれの通信タスクは１周期内で連続して全てのデータを送信する必要はなく、分割して送信することになってもかまわない。
【００３９】
最大転送量取得部２２は、情報処理装置１が単位時間あたりに送信することを許可された最大量である最大転送量を、全体送信量管理サーバから取得する。上述したように、全体送信量管理サーバは、各情報処理装置の最大転送量を決定する。本実施形態では、最大転送量は全体送信量管理サーバから情報処理装置１に対して通信によって通知される。
【００４０】
通信速度取得部２６は、ネットワーク３の実効通信速度を取得する。実効通信速度は、実測によって取得してもよく、あらかじめ定められた設定値を使用することもできる。
【００４１】
スケジュール可能性判定部２３は、送信要求受付部２１が受け付けたパケット送信の要求が、デッドラインを守って送信することができるか否か判定する。デッドライン保証可能であれば、通信タスク管理テーブル２４に、実行すべき通信タスクとして登録する。スケジュール可能性判定部２３の機能の詳細については後述する。
【００４２】
パケット制御部２５は、通信タスク管理テーブル２４に格納されている情報に基づいて、パケット送信を行う。パケット送信の通信タスクは、デッドラインが短いものほど優先度が高く設定され、パケット制御部２５はこの優先度に基づいて送信するパケットを選択する。
【００４３】
なお、パケット制御部２５は、１回に送信できるデータの最大値が定められている。この最大値は、ＭＴＵ（Maximum Transfer Unit）と呼ばれる。本実施形態においては、Ｍ
ＴＵの値として、イーサネット（登録商標）の標準規格である１５１８バイト（オクテット）よりも大きい１６０００バイトを使用する。なお、本発明において具体的なＭＴＵのサイズは、これに限定されるものではない。
【００４４】
パケット制御部２５は、送信するパケットがＭＴＵよりも大きい場合には、ＭＴＵサイズに分割した上で送信する。逆に、パケット制御部２５は、送信するパケットがＭＴＵサイズに満たない場合には、ＭＴＵサイズ内で連結して送信できる他のパケットがあればパケットを連結して送信する。
【００４５】
＜処理フロー＞
（スケジュール可能性判定処理）
次に図５を用いて、スケジュール可能性判定部２３が行う、スケジュール可能性判定処理について説明する。
【００４６】
スケジュール可能性判定部２３は、まずステップＳ１０１で、送信要求受付部２１が受け付けたパケット送信と、すでに実行する通信タスクとして通信タスク管理テーブル２４に格納されているタスクとを合計した場合の、単位時間あたりのデータ転送量を算出する。これは、Σ（各送信の送信データ量／周期）によって求めることができる。なお、（送信データ量）／（周期）は、ＭＴＵ（Maximum Transfer Unit）単位に切り上げる。
【００４７】
次に、ステップＳ１０２で、算出した単位時間あたりのデータ転送量が、最大転送量取
得部２２が取得した最大転送量以内であるか判定する。ここで、算出したデータ転送量が、最大転送量を超える転送量となる場合には、ステップＳ１０６に進み、受け付けたパケット送信を登録しないで、その実行を拒否する。算出したデータ転送量が、最大転送量以内である場合は、ステップＳ１０３に進む。
【００４８】
ステップＳ１０３では、要求されたパケット送信の１周期の送信に要する送信所要時間を計算する。送信所要時間は、１周期あたりのデータ転送量を、通信速度取得部２６が取得したネットワーク３の通信速度で割ることによって求めることができる。（送信所要時間）＝（１周期あたりのデータ転送量）／（ネットワークの通信速度）。なお、１周期あたりのデータ転送量は、ＭＴＵ単位で切り上げて使用する。
【００４９】
スケジュール可能性判定部２３は、ステップＳ１０４で、デッドラインモノトニック法を利用して、すでに登録された通信タスク及び要求されたパケット送信についてデッドラインを保証できるか判定を行う。
【００５０】
デッドラインモノトニック法では、各パケット送信の周期、１周期あたりの送信所要時間、及びデッドラインを用いる。これらの情報に基づいてスケジュール可能性を判定する判断方法については、既知の如何なる方法を用いてもかまわない。例えば、スケジュール可能性の必要十分条件となる判定式を用いても良いし、十分条件を用いても良い。
【００５１】
スケジュール可能性の十分条件を表す判定式としては、例えば、以下の判定式を用いることができる。
【００５２】
【数１】
【００５３】
なお、Ｔｉ，Ｃｉ，Ｄｉは、それぞれ通信タスクｉの送信周期、送信所要時間、デッドラインである。また、通信タスクｉは、ｉ＝１の通信タスクが最も優先度が高く、ｉが大きくなるにしたがって優先度が小さくなる。
【００５４】
また、
【数２】
は、ｘ以上の最小整数を表す。
【００５５】
この他の判定式については、例えば、以下の文献などに記載されている。
【００５６】
Audsley, Burns, Richardson, Wellings, "Hard Real-Time Scheduling: The Deadline-Monotonic Approach", Proceedings of the 8th IEEE Workshop on Real-Time Operating Systems and Software, 1991
【００５７】
このような判定式にしたがってスケジュール可能性の判定を行い、すでに登録された通
信タスクと要求された通信タスクの全てについてデッドラインを守ることができる場合には、ステップＳ１０５に進んで、要求されたパケット送信を、実行する通信タスクとして、通信タスク管理テーブル２４に格納する。デッドラインを保証できない場合には、ステップＳ１０６に進み、受け付けたパケット送信を登録せず、その実行を拒否する。
【００５８】
（パケット送信処理）
次に、図６を用いて、パケット制御部２５が行うパケット送信処理について説明する。パケット制御部２５は、通信タスク管理テーブル２４に格納されている周期やデッドラインなどの情報に基づいてパケットの送信順序を制御する。また、パケット送信を効率的に行えるように、１つの通信タスクに係るパケットだけではＭＴＵサイズに満たない場合には、他の通信タスクに係るパケットを連結して送信する。
【００５９】
パケット制御部２５は、ステップＳ２０１で、通信タスク管理テーブル２４を参照して、最も優先度が高く、かつ、パケット送信が完了していない通信タスクを選択する。なお、上述したように、通信タスクの優先度は、デッドラインが短いものほど優先度が高く設定されている。
【００６０】
ここで、パケット制御部２５は選択したパケットのサイズを計測する。なお、送信するパケットがＭＴＵサイズよりも大きい場合には、ＭＴＵサイズに分割して送信する。一方、送信するパケットがＭＴＵサイズよりも小さい場合には、他のデータを連結して１つのパケットとして送信する余地がある。
【００６１】
そこで、パケット制御部２５は、ステップＳ２０２で、送信するパケットに空きがあるか判定する。すなわち、計測したパケットサイズがＭＴＵサイズよりも小さいか判定する。ここで、ある閾値を設けて、次送信パケットにこの閾値以上の空きがあるか判定することが好ましい。
【００６２】
次送信パケットに空きがある場合（Ｓ２０２−ＹＥＳ）には、ステップＳ２０３へ進み、空き部分に入るデータが存在するか判定する。具体的には、パケット制御部２５は、通信タスク管理テーブル２４を参照して、優先度の高い通信タスクから順番に、送信データのサイズが空きサイズよりも小さい通信タスクが存在するか検査する。なお、パケット制御部２５は、通信タスク管理テーブル２４に登録されている全ての通信タスクを対象に検査を行っても良いが、優先度の高いものから所定の数の通信タスクについてのみ検査を行っても良い。連結するパケットの対象を絞ることで、優先度の逆転防止と通信の効率化のバランスを図ることができる。
【００６３】
空き部分に入るデータが存在する場合（Ｓ２０４−ＹＥＳ）は、ステップＳ２０５へ進み、次送信の空き部分に該当データを追加する。その後、ステップＳ２０２に戻り、再び次に送信するパケットに空きがあるかチェックする。一方、空き部分に入るデータが存在しない場合（Ｓ２０４−ＮＯ）は、ステップＳ２０６へ進み、パケットを送信する。
【００６４】
また、ステップＳ２０２において、次送信パケットに空きがないと判定された場合（Ｓ２０２−ＮＯ）は、ステップＳ２０６へ進み、その状態でパケットを送信する。
【００６５】
図７（ａ）に示すように４つの通信タスクに係るデータが送信待ちの場合を例にして、より具体的な説明を行う。通信タスクＡ〜Ｄは、通信タスクＡが最も優先度が高く、通信タスクＤが最も優先度が低いものとする。ここでは、まず通信タスクＡが送信されるデータとして選択されるが、送信パケットには空きがある。そこで、空き部分に入るデータが存在するか優先度が高いものから順に調べると、通信タスクＢが連結できることが分かる。通信タスクＢを連結してもまだ空きがあるので、さらに追加できるデータがあるか調べ
ると、通信タスクＣを連結するとＭＴＵサイズを超えるので連結できないが、通信タスクＤは連結できることが分かる。通信タスクＡ，Ｂ，Ｄを連結した後はこれ以上空きがないので、この状態でパケットが送信されることになる。
【００６６】
（実施形態の効果）
本実施形態では、各情報処理装置が送信するデータ量は、全体送信量管理サーバによって管理される。さらに、各情報処理装置は、利用可能な転送量の範囲内で、デッドラインモノトニック法によってデッドライン以内に通信を完了することが保証された通信タスクのみを受け入れる。したがって、ネットワークシステム全体で、デッドラインを守ってパケット送信することができる。
【００６７】
また、通信タスクに係るデータのサイズがＭＴＵサイズに比して小さい場合に、複数の通信タスクに係るデータを連結して送信するため、効率的な通信が実現できる。
【００６８】
［第２の実施形態］
第２の実施形態は、パケット制御部２５の送信処理が異なるだけであり、その他については第１の実施形態と同様であるので、同様の部分については説明を省略する。
【００６９】
本実施形態では、パケット制御部２５は、送信予定のデータを、ＭＴＵよりも小さい固定長のサイズに分割した上で（以下、分割されたデータをセルという）、優先度にしたがってセルを連結してＭＴＵサイズ分のパケットを生成して送信する。なお、本実施形態においてはセル長として５３バイトを採用するが、その他どのようなセル長を採用しても良い。
【００７０】
図８（ａ）に示すように、４つの通信タスクに係るデータが送信待ちの場合を例にして具体的に説明を行う。通信タスクＡ〜Ｄは、通信タスクＡが最も優先度が高く、通信タスクＤが最も優先度が低いものとする。まず、各通信タスクに係るデータは、セルに分割される。たとえば、通信タスクＡに係るデータは、Ａ１〜Ａ４の４つのセルに分割される。
【００７１】
次に、パケット制御部２５は、優先度の高い通信タスクに係るセルから順番に、次に送信するパケットに連結していく。このような方法によって生成される送信パケットは、図８（ｂ）に示すように、セルＡ１〜Ａ４，Ｂ１，Ｃ１〜Ｃ４から構成される。この図は、生成されるパケットの一例であるが、以下の２つの利点がある。まず、第一に固定長のセルに分割しているので、優先度の逆転が発生しない。第二に、セルサイズを小さくすることで、送信パケットをＭＴＵいっぱいまで有効に利用することができる。
【００７２】
また、パケット制御部２５がパケット生成処理を行っている間に、優先度の高い新しい通信タスクが登録された場合に、その通信タスクに係るデータを優先して送信することができる。
【００７３】
このように、本実施形態によれば、優先度の逆転が極力起こらず、より効率的な通信が可能となる。
【００７４】
［第３の実施形態］
第３の実施形態は、スケジュール可能性判定部２３が行う処理（図５参照）が異なるだけであり、その他については第１または第２の実施形態と同様であるので、同様の部分については説明を省略する。
【００７５】
図９は、第３の実施形態におけるスケジュール可能性判定部２３のスケジュール可能性判定処理を示すフローチャートである。図９の処理のうち、第１の実施形態と異なる部分
について詳しく説明する。
【００７６】
第１の実施形態と同様に、ステップＳ３０２で、要求されたパケット送信とすでに登録された通信タスクを合計した場合に必要となる単位時間あたりのデータ転送量が、情報処理装置１に割り当てられた最大転送量以内であるか判断する。必要となる単位時間あたりのデータ転送量が最大転送量を超える場合には、ステップＳ３０３に進む。
【００７７】
ステップＳ３０３では、最大転送量取得部２２が、最大転送量の増加を全体送信量管理サーバに対して要求する。ここで、新たに要求する最大転送量は、ステップＳ３０２で求めた必要となる単位時間あたりのデータ転送量以上である。ステップＳ３０４で、全体送信量管理サーバへの要求が認められたか否か判定する。要求が認められた場合には、ステップＳ３０５に進んで、デッドラインモノトニック法によるスケジュール可能性判定を行う。要求が認められなかった場合には、ステップＳ３０８に進んで、要求されたパケット送信を拒否する。
【００７８】
全体送信量管理サーバは、ネットワーク全体での単位時間あたりに送信可能なデータ量（利用可能帯域）および、各情報処理装置が単位時間あたりに送信する最大送信データ量を管理しているため、帯域に余裕がある場合には、情報処理装置１からの最大転送量を増加する要求を受け入れることができる。
【００７９】
このように、第３の実施形態では、各情報処理装置が単位時間あたりに送信することのできる、データ量を必要に応じて増やすことができるので、より柔軟なスケジューリングが可能となる。
【００８０】
なお、このように最大転送量の増加を認める場合には、情報処理装置１が必要とする転送量が最大転送量よりも低くなった場合に、最大転送量を低下させる要求を全体送信量管理サーバに対して通知することが、ネットワーク資源の有効活用の観点から有効であることは言うまでもない。
【００８１】
［第４の実施形態］
第４の実施形態は、情報処理装置が、複数のネットワークに接続されている実施形態である。図１０に示すように、情報処理装置６は、複数のネットワーク制御部１５ａ，１５ｂ，１５ｃを介して複数のネットワークに接続されている。この場合、情報処理装置６を含むネットワークシステムの全体は図１１のようになる。図１１において、情報処理装置６は、ネットワーク７ａ，７ｂ，７ｃに接続されている。これら複数のネットワークとしては、例えば、イーサネット（登録商標）、携帯電話、光通信、無線通信などが挙げられる。
【００８２】
この場合、情報処理装置６は、ネットワークごとに通信タスク管理テーブルを有する。スケジュール可能性判定部２３は、送信相手先のネットワークに応じた通信タスク管理テーブルを用いて、上記実施形態と同様のスケジュール可能性判定処理を行うことで、それぞれのネットワークでデッドラインを保証した通信を行うことが可能となる。
【００８３】
なお、図１１では複数のネットワークに接続された情報処理装置は１台だけであるが、複数あってもかまわないことは明らかである。
【００８４】
［変形例］
上記実施例においては、情報処理装置が単位時間あたりに送信できるデータ量の最大値は、全体送信量管理サーバから取得していた。しかし、必ずしもそのように構成する必要はなく、最大転送量は設定ファイルなどによる設定情報として、情報処理装置にあらかじ
め与えられていても良い。
【図面の簡単な説明】
【００８５】
【図１】第１の実施形態におけるパケットスケジューラが利用されるネットワークシステムの概要図である。
【図２】第１の実施形態におけるパケットスケジューラを実行する情報処理装置の構成を示す図である。
【図３】第１の実施形態におけるパケットスケジューラの機能ブロック図である。
【図４】周期タスクを説明する模式図である。
【図５】第１の実施形態におけるスケジュール可能性判定処理を示すフローチャートである。
【図６】第１の実施形態におけるパケット送信制御を処理を示すフローチャートである。
【図７】第１の実施形態におけるパケットの連結処理を説明する図である。
【図８】第２の実施形態におけるパケットの連結処理を説明する図である。
【図９】第３の実施形態におけるスケジュール可能性判定処理を示すフローチャートである。
【図１０】第４の実施形態におけるパケットスケジューラを実行する情報処理装置の構成を示す図である。
【図１１】第４の実施形態におけるパケットスケジューラが利用されるネットワークシステムの概要図である。
【符号の説明】
【００８６】
１ 情報処理装置
２ パケットスケジューラ
３ ネットワーク
４ アプリケーションプログラム
６ 情報処理装置
７ ネットワーク
１１ ＣＰＵ
１２ タイマ
１３ 補助記憶装置
１４ メモリ
１５ ネットワーク制御部
２１ 送信要求受付部
２２ 最大転送量取得部
２３ スケジュール可能性判定部
２４ 通信タスク管理テーブル
２５ パケット制御部
２６ 通信速度取得部
【特許請求の範囲】
【請求項１】
ネットワークに接続された情報処理装置における、パケットの送信を制御するパケット送信制御プログラムであって、
前記情報処理装置を、
各周期においてデッドラインが定められた周期的なパケット送信の実行要求を受け付ける送信要求受付手段と、
前記要求されたパケット送信のデッドライン保証が可能か否か判定し、デッドライン保証可能であれば、該要求されたパケット送信を、実行する通信タスクとして登録するスケジュール可能性判定手段と、
前記登録された通信タスクのパケットを、該通信タスクのデッドラインに応じた優先度で送信するパケット制御手段
として機能させ、
前記スケジュール可能性判定手段は、すでに登録された通信タスク及び前記要求されたパケット送信の全てについてデッドラインを保証でき、かつ、全てのデッドラインを保証するようにパケットを送信したときの単位時間あたりの転送量が所定の最大転送量以内となる場合に、前記要求されたパケット送信を、実行する通信タスクとして登録し、
前記パケット制御手段は、複数の通信タスクに係るパケットを連結して送信する
ことを特徴とするパケット送信制御プログラム。
【請求項２】
前記パケット制御手段は、複数の通信タスクに係るパケットを固定長に分割して、前記優先度に応じて連結して送信する
ことを特徴とする請求項１に記載のパケット送信制御プログラム。
【請求項３】
前記パケット送信の実行要求には、送信周期、１周期あたりの送信データ量、及び各周期におけるデッドラインが含まれ、
前記スケジュール可能性判定手段は、１周期あたりの送信データ量及び前記ネットワークにおける実効通信速度から、要求されたパケット送信に要する送信所要時間を算出し、前記送信周期、前記送信所要時間、及び前記デッドラインを用いて、デッドラインモノトニック法によって、前記すでに登録された通信タスク及び前記要求されたパケット送信の全てについて前記デッドライン保証が可能か否かを判定する
ことを特徴とする請求項１または２に記載のパケット送信制御プログラム。
【請求項４】
ネットワークに接続された情報処理装置における、パケットの送信を制御するパケット送信制御装置であって、
各周期においてデッドラインが定められた周期的なパケット送信の実行要求を受け付ける送信要求受付手段と、
前記要求されたパケット送信のデッドライン保証が可能か否か判定し、デッドライン保証可能であれば、該要求されたパケット送信を、実行する通信タスクとして登録するスケジュール可能性判定手段と、
前記登録された通信タスクのパケットを、該通信タスクのデッドラインに応じた優先度で送信するパケット制御手段と、
を有し、
前記スケジュール可能性判定手段は、すでに登録された通信タスク及び前記要求されたパケット送信の全てについてデッドラインを保証でき、かつ、全てのデッドラインを保証するようにパケットを送信したときの単位時間あたりの転送量が所定の最大転送量以内となる場合に、前記要求されたパケット送信を、実行する通信タスクとして登録し、
前記パケット制御手段は、複数の通信タスクに係るパケットを連結して送信する
ことを特徴とするパケット送信制御装置。
【請求項５】
ネットワークに接続された情報処理装置における、パケットの送信を制御するパケット送信制御方法であって、
前記情報処理装置が、
各周期においてデッドラインが定められた周期的なパケット送信の実行要求を受け付け、
すでに登録された通信タスク及び前記要求されたパケット送信の全てについてデッドラインを保証でき、かつ、全てのデッドラインを保証するようにパケットを送信したときの単位時間あたりの転送量が所定の最大転送量以内となる場合に、前記要求されたパケット送信を、実行する通信タスクとして登録し、
前記登録された複数の通信タスクに係るパケットを、該通信タスクのデッドラインに応じた優先度で連結して送信する
ことを特徴とするパケット送信制御方法。
【請求項１】
ネットワークに接続された情報処理装置における、パケットの送信を制御するパケット送信制御プログラムであって、
前記情報処理装置を、
各周期においてデッドラインが定められた周期的なパケット送信の実行要求を受け付ける送信要求受付手段と、
前記要求されたパケット送信のデッドライン保証が可能か否か判定し、デッドライン保証可能であれば、該要求されたパケット送信を、実行する通信タスクとして登録するスケジュール可能性判定手段と、
前記登録された通信タスクのパケットを、該通信タスクのデッドラインに応じた優先度で送信するパケット制御手段
として機能させ、
前記スケジュール可能性判定手段は、すでに登録された通信タスク及び前記要求されたパケット送信の全てについてデッドラインを保証でき、かつ、全てのデッドラインを保証するようにパケットを送信したときの単位時間あたりの転送量が所定の最大転送量以内となる場合に、前記要求されたパケット送信を、実行する通信タスクとして登録し、
前記パケット制御手段は、複数の通信タスクに係るパケットを連結して送信する
ことを特徴とするパケット送信制御プログラム。
【請求項２】
前記パケット制御手段は、複数の通信タスクに係るパケットを固定長に分割して、前記優先度に応じて連結して送信する
ことを特徴とする請求項１に記載のパケット送信制御プログラム。
【請求項３】
前記パケット送信の実行要求には、送信周期、１周期あたりの送信データ量、及び各周期におけるデッドラインが含まれ、
前記スケジュール可能性判定手段は、１周期あたりの送信データ量及び前記ネットワークにおける実効通信速度から、要求されたパケット送信に要する送信所要時間を算出し、前記送信周期、前記送信所要時間、及び前記デッドラインを用いて、デッドラインモノトニック法によって、前記すでに登録された通信タスク及び前記要求されたパケット送信の全てについて前記デッドライン保証が可能か否かを判定する
ことを特徴とする請求項１または２に記載のパケット送信制御プログラム。
【請求項４】
ネットワークに接続された情報処理装置における、パケットの送信を制御するパケット送信制御装置であって、
各周期においてデッドラインが定められた周期的なパケット送信の実行要求を受け付ける送信要求受付手段と、
前記要求されたパケット送信のデッドライン保証が可能か否か判定し、デッドライン保証可能であれば、該要求されたパケット送信を、実行する通信タスクとして登録するスケジュール可能性判定手段と、
前記登録された通信タスクのパケットを、該通信タスクのデッドラインに応じた優先度で送信するパケット制御手段と、
を有し、
前記スケジュール可能性判定手段は、すでに登録された通信タスク及び前記要求されたパケット送信の全てについてデッドラインを保証でき、かつ、全てのデッドラインを保証するようにパケットを送信したときの単位時間あたりの転送量が所定の最大転送量以内となる場合に、前記要求されたパケット送信を、実行する通信タスクとして登録し、
前記パケット制御手段は、複数の通信タスクに係るパケットを連結して送信する
ことを特徴とするパケット送信制御装置。
【請求項５】
ネットワークに接続された情報処理装置における、パケットの送信を制御するパケット送信制御方法であって、
前記情報処理装置が、
各周期においてデッドラインが定められた周期的なパケット送信の実行要求を受け付け、
すでに登録された通信タスク及び前記要求されたパケット送信の全てについてデッドラインを保証でき、かつ、全てのデッドラインを保証するようにパケットを送信したときの単位時間あたりの転送量が所定の最大転送量以内となる場合に、前記要求されたパケット送信を、実行する通信タスクとして登録し、
前記登録された複数の通信タスクに係るパケットを、該通信タスクのデッドラインに応じた優先度で連結して送信する
ことを特徴とするパケット送信制御方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【公開番号】特開２００８−２３６６２５（Ｐ２００８−２３６６２５Ａ）
【公開日】平成２０年１０月２日（２００８．１０．２）
【国際特許分類】
【出願番号】特願２００７−７６６０２（Ｐ２００７−７６６０２）
【出願日】平成１９年３月２３日（２００７．３．２３）
【出願人】（５０２０８７４６０）株式会社トヨタＩＴ開発センター (232)
【出願人】（０００００３２０７）トヨタ自動車株式会社 (59,920)
【Ｆターム（参考）】
【公開日】平成２０年１０月２日（２００８．１０．２）
【国際特許分類】
【出願日】平成１９年３月２３日（２００７．３．２３）
【出願人】（５０２０８７４６０）株式会社トヨタＩＴ開発センター (232)
【出願人】（０００００３２０７）トヨタ自動車株式会社 (59,920)
【Ｆターム（参考）】
[ Back to top ]