パケット送信制御プログラム、パケット送信制御装置、及びパケット送信制御方法
【課題】 ネットワーク全体で、パケットのデッドラインを保証した通信を行うことができる技術を提供する。
【解決手段】 情報処理装置には周期的な通信タスクの送信順序を制御するパケットスケジューラが設けられる。また情報処理装置には利用可能通信帯域が与えられている。パケットスケジューラは、利用帯域が利用可能通信帯域を超えず、かつ、デッドラインモノトニック法によってデッドラインが保証できると判定された場合に、要求された通信タスクを実行する通信タスクとして登録する。
【解決手段】 情報処理装置には周期的な通信タスクの送信順序を制御するパケットスケジューラが設けられる。また情報処理装置には利用可能通信帯域が与えられている。パケットスケジューラは、利用帯域が利用可能通信帯域を超えず、かつ、デッドラインモノトニック法によってデッドラインが保証できると判定された場合に、要求された通信タスクを実行する通信タスクとして登録する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、パケット送信制御プログラム、パケット送信制御装置、及びパケット送信制御方法に関する。
【背景技術】
【０００２】
従来、リアルタイムパケット通信においてデッドラインを考慮して、ＥＤＦ（Earliest
Deadline First）アルゴリズムに基づいてパケット通信を行う技術が知られている（特許文献１，２）。
【０００３】
ＥＤＦアルゴリズムとは、デッドラインが最も近い処理を優先して実行するアルゴリズムである。
【特許文献１】特表２００２−５４３５２０号公報
【特許文献２】特表２００３−５０５９３１号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかしながら、デッドラインが最も近い処理を優先的に実行するＥＤＦ法では、パケットの送信要求の発生タイミングによっては、デッドラインが短く設定されたパケットが頻繁に送信されてしまい、他のパケット送信のデッドラインが保証できなくなるおそれがある。
【０００５】
本発明は上記実情に鑑みてなされたものであって、その目的とするところは、ネットワークに接続されている情報処理装置におけるパケット送信のデッドラインを保証する技術を提供することにある。
【課題を解決するための手段】
【０００６】
上記目的を達成するために本発明では、以下の手段または処理によってデッドラインを保証したパケット通信を行う。
【０００７】
本発明に係るパケット送信制御プログラムは、ネットワークに接続された情報処理装置における、パケットの送信を制御するパケット送信制御プログラムである。本発明に係るパケット送信制御プログラムは、情報処理装置を、送信要求受付手段と、スケジュール可能性判定手段と、パケット制御手段として機能させる。
【０００８】
送信要求受付手段は、各周期においてデッドラインが定められた周期的なパケット送信の実行要求を受け付ける。
【０００９】
スケジュール可能性判定手段は、要求されたパケット送信のデッドライン保証が可能か否か判定し、デッドライン保証可能であれば、要求されたパケット送信を、実行する通信タスクとして登録する。
【００１０】
パケット制御手段は、登録された通信タスクのパケットを、通信タスクのデッドラインに応じた優先度で送信する。
【００１１】
スケジュール可能性判定手段は、すでに登録されている通信タスク及び要求されたパケット通信の全てについてデッドラインを保証でき、かつ、全てのデッドラインを保証する
ようにパケットを送信したときの単位時間あたりのパケットの転送量（データ転送量）が情報処理装置に与えられた所定の最大転送量以内となる場合に、要求されたパケット送信を、実行する通信タスクとして登録する。
【００１２】
このように、本発明に係るパケット送信制御プログラムは、各情報処理装置内でパケット送信のデッドラインを保証できるか否か判定し、さらに、各情報処理装置のパケット転送量が割り当てられた最大転送量以内であるか判定した上で、パケット送信要求を登録するか否か決定するので、ネットワーク内の全ての情報処理装置についてパケット送信のデッドラインを保証することが可能となる。
【００１３】
本発明におけるスケジュール可能性判定手段は、デッドラインモノトニック（Deadline
Monotonic）法によって、すでに登録された通信タスク及び要求されたパケット送信の全てについてデッドライン保証が可能であるか判定することが好適である。
【００１４】
より具体的には、送信要求受付手段が受け付けるパケット送信要求には、情報として、パケット送信の送信周期、１周期あたりの送信データ量及び各周期におけるデッドラインが含まれることが好ましい。ここで、各周期におけるデッドラインは送信周期と同じか送信周期よりも短い時間である。
【００１５】
まず、スケジュール可能性判定手段は、１周期あたりの送信データ量及びネットワークの実効通信速度から、要求されたパケット送信に要する送信所要時間を算出する。次に、スケジュール可能性判定手段は、送信周期、算出した送信所要時間、及びデッドラインを用いてデッドラインモノトニック法によって、スケジュール可能性を判定する。
【００１６】
なお、スケジュール可能性判定手段は、送信周期、送信所要時間、及びデッドラインが、デッドライン保証可能な必要十分条件を満たすか否かを判定する必要はなく、デッドライン保証可能なための十分条件を満たすか否かのみを判定するようにしても良い。デッドラインモノトニック法では、必要十分条件の判定は複雑であり処理に時間を要するため、処理の軽い十分条件での判定を用いることも好ましい。
【００１７】
本発明に係るパケット送信制御プログラムが設けられている情報処理装置に割り当てられる所定の最大転送量は、設定情報として情報処理装置にあらかじめ与えられたり、各情報処理装置の全体送信量管理サーバから与えられたりすることが好ましい。
【００１８】
また、最大転送量は常に同じ値である必要はなく、パケット送信制御プログラムは、すでに登録された通信タスク及び要求されたパケット送信の全てについてデッドラインを保証するようにパケットを送信したときの単位時間あたりの転送量が最大転送量を超える場合には、全体送信量管理サーバに対して最大転送量の増加を求めることが好ましい。
【００１９】
なお、本発明は、上記処理の少なくとも一部を有するパケット送信制御プログラムとして捉えることができる。また、本発明は、上記手段の少なくとも一部を含むパケット送信制御装置、または、上記処理の少なくとも一部を含むパケット送信制御方法として捉えることができる。上記手段及び処理の各々は可能な限り互いに組み合わせて本発明を構成することができる。
【００２０】
たとえば、本発明の一態様としてのパケット送信制御装置は、ネットワークに接続された情報処理装置における、パケットの送信を制御するパケット送信制御装置であって、各周期においてデッドラインが定められた周期的なパケット送信の実行要求を受け付ける送信要求受付手段と、前記要求されたパケット送信のデッドライン保証が可能か否か判定し、デッドライン保証可能であれば、該要求されたパケット送信を、実行する通信タスクと
して登録するスケジュール可能性判定手段と、前記登録された通信タスクのパケットを、該通信タスクのデッドラインに応じた優先度で送信するパケット制御手段と、を有し、前記スケジュール可能性判定手段は、すでに登録された通信タスク及び前記要求されたパケット送信の全てについてデッドラインを保証でき、かつ、全てのデッドラインを保証するようにパケットを送信したときの単位時間あたりの転送量が所定の最大転送量以内となる場合に、前記要求されたパケット送信を、実行する通信タスクとして登録することを特徴とする。
【００２１】
また、本発明の一態様としてのパケット送信制御方法は、ネットワークに接続された情報処理装置における、パケットの送信を制御するパケット送信制御方法であって、前記情報処理装置が、各周期においてデッドラインが定められた周期的なパケット送信の実行要求を受け付け、すでに登録された通信タスク及び前記要求されたパケット送信の全てについてデッドラインを保証でき、かつ、全てのデッドラインを保証するようにパケットを送信したときの単位時間あたりの転送量が所定の最大転送量以内となる場合に、前記要求されたパケット送信を、実行する通信タスクとして登録し、前記登録された通信タスクのパケットを、該通信タスクのデッドラインに応じた優先度で送信することを特徴とする。
【発明の効果】
【００２２】
本発明によれば、ネットワークに接続されている情報処理装置におけるパケット送信のデッドラインを保証することが可能となる。
【発明を実施するための最良の形態】
【００２３】
以下に図面を参照して、この発明の好適な実施の形態を例示的に詳しく説明する。
【００２４】
［第１の実施形態］
＜システム概要＞
図１は、本実施形態に係るパケットスケジューラ（パケット送信制御プログラム）を実行する情報処理装置のネットワークシステムを示す図である。複数の情報処理装置１ａ、１ｂ、１ｃがネットワーク３を介して接続されており、各情報処理装置は互いにパケット通信を行う。ここで、情報処理装置１ｃは、各情報処理装置１ａ，１ｂ，１ｃのそれぞれが単位時間あたりに送信できるパケットの最大転送量を管理する全体送信量管理サーバとしての機能も兼ねる。
【００２５】
図２は、パケットスケジューラを実行する情報処理装置１の構成を示す図である。情報処理装置１は、ＣＰＵ１１，タイマ１２，ハードディスク装置などの補助記憶装置１３、読み書き可能メモリ（ＲＡＭ）などのメモリ１４、及びネットワーク制御部１５を有する。これらの各要素は、バスを介して互いに接続されている。
【００２６】
タイマ１２は、情報処理装置１における現在時刻（システム時刻）を刻むものである。パケットスケジューラは、このタイマ１２のシステム時刻に基づいてパケット送信の制御を行う。
【００２７】
補助記憶装置１３には、パケットスケジューラやその他アプリケーションのプログラムが格納されている。これらのソフトウェアは、補助記憶装置１３からメモリ１４に、必要に応じて適宜読み出され、ＣＰＵ１１によって実行される。なお、メモリ１４には、パケットスケジューラが管理する通信タスクについての情報（周期、データ転送量、デッドライン、優先度など）や、情報処理装置１が単位時間あたりに送信（送出）できる最大転送量などが記憶される。
【００２８】
情報処理装置１は、ネットワーク制御部１５を介してネットワーク３と接続されている
。
【００２９】
上述したように図１の情報処理装置１ｃは全体送信量管理サーバとしての機能も兼ねる。全体送信量管理サーバは、ネットワーク３に接続された各情報処理装置が単位時間あたりに送信できる最大転送量を決定する機能を有する。このように、全体送信量管理サーバは、各情報処理装置の最大転送量を決定することで、ネットワーク全体で、過剰な通信が発生することを防止する。
【００３０】
＜機能構成＞
図３は、パケットスケジューラを実行する情報処理装置１の機能ブロック図である。パケットスケジューラの機能は、送信要求受付部２１，最大転送量取得部２２，通信速度取得部２６，スケジュール可能性判定部２３，及びパケット制御部２５から構成される。なお、これらの各部は、パケット送信制御プログラムがＣＰＵ１１によって実行されることによって、その機能が実現される。
【００３１】
送信要求受付部２１は、アプリケーションプログラム４からパケット送信の要求を受け付ける。パケットスケジューラは、ＩＰ（Internet Protocol）層上で機能するプログラムであるので、アプリケーションプログラム４と送信要求受付部２１の間には、ＴＣＰ（Transmission Control Protocol）やＵＤＰ（User Datagram Protocol）などのトランスポート層および、さらにその上位のアプリケーション層が存在し、これらのプロトコル層を実装するプログラムが仲介するが、図３では省略している。
【００３２】
送信要求受付部２１が受け付けるパケット送信の要求は、一定周期ごとに所定のデータ量を送信する必要があり、送信開始から所定の時間（デッドライン）以内にパケットの送信を完了する必要がある。
【００３３】
図４は、周期的なパケット送信の通信タスクを説明する図である。図４（ａ）に示すように、一定周期Ｔごとに所定量のパケットを送信する必要がある。また、この送信を完了する制限時間であるデッドラインＤが定められている。なお、パケットの送信はデッドライン以内に完了すれば、正しく処理されたものとみなされる。したがって、図４（ｂ）に示すように、複数の通信タスクが存在する状況では、それぞれの通信タスクは１周期内で連続して全てのデータを送信する必要はなく、分割して送信することになってもかまわない。
【００３４】
最大転送量取得部２２は、情報処理装置１が単位時間あたりに送信することを許可された最大量である最大転送量を、全体送信量管理サーバから取得する。上述したように、全体送信量管理サーバは、各情報処理装置の最大転送量を決定する。本実施形態では、最大転送量は全体送信量管理サーバから情報処理装置１に対して通信によって通知される。
【００３５】
通信速度取得部２６は、ネットワーク３の実効通信速度を取得する。実効通信速度は、実測によって取得してもよく、あらかじめ定められた設定値を使用することもできる。
【００３６】
スケジュール可能性判定部２３は、送信要求受付部２１が受け付けたパケット送信の要求が、デッドラインを守って送信することができるか否か判定する。デッドライン保証が可能であれば、通信タスク管理テーブル２４に、実行すべき通信タスクとして登録する。スケジュール可能性判定部２３の機能の詳細については後述する。
【００３７】
パケット制御部２５は、通信タスク管理テーブル２４に格納されている情報に基づいて、パケット送信を行う。パケット送信の通信タスクは、デッドラインが短いものほど優先度が高く設定され、パケット制御部２５はこの優先度に基づいて送信するパケットを選択
する。
【００３８】
＜処理フロー＞
（スケジュール可能性判定処理）
次に図５を用いて、スケジュール可能性判定部２３が行う、スケジュール可能性判定処理について説明する。
【００３９】
スケジュール可能性判定部２３は、まずステップＳ１０１で、送信要求受付部２１が受け付けたパケット送信と、すでに実行する通信タスクとして通信タスク管理テーブル２４に格納されているタスクとを合計した場合の、単位時間あたりのデータ転送量を算出する。これは、Σ（各送信の送信データ量／周期）によって求めることができる。なお、（送信データ量）／（周期）は、ＭＴＵ（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）単位に切り上げる。
【００４０】
次に、ステップＳ１０２で、算出した単位時間あたりのデータ転送量が、最大転送量取得部２２が取得した最大転送量以内であるか判定する。ここで、算出したデータ転送量が、最大転送量を超える転送量となる場合には、ステップＳ１０６に進み、受け付けたパケット送信を登録しないで、その実行を拒否する。算出したデータ転送量が、最大転送量以内である場合は、ステップＳ１０３に進む。
【００４１】
ステップＳ１０３では、要求されたパケット送信の１周期の送信に要する送信所要時間を計算する。送信所要時間は、１周期あたりのデータ転送量を、通信速度取得部２６が取得したネットワーク３の通信速度で割ることによって求めることができる。（送信所要時間）＝（１周期あたりのデータ転送量）／（ネットワークの通信速度）。なお、１周期あたりのデータ転送量は、ＭＴＵ単位で切り上げて使用する。
【００４２】
スケジュール可能性判定部２３は、ステップＳ１０４で、デッドラインモノトニック法を利用して、すでに登録された通信タスク及び要求されたパケット送信についてデッドラインを保証できるか判定を行う。
【００４３】
デッドラインモノトニック法では、各パケット送信の周期、１周期あたりの送信所要時間、及びデッドラインを用いる。これらの情報に基づいてスケジュール可能性を判定する判断方法については、既知の如何なる方法を用いてもかまわない。例えば、スケジュール可能性の必要十分条件となる判定式を用いても良いし、十分条件を用いても良い。
【００４４】
スケジュール可能性の十分条件を表す判定式としては、例えば、以下の判定式を用いることができる。
【数１】
なお、Ｔｉ，Ｃｉ，Ｄｉは、それぞれ通信タスクｉの周期、送信所要時間、デッドラインである。また、通信タスクｉは、ｉ＝１の通信タスクが最も優先度が高く、ｉが大きくなるにしたがって優先度が小さくなる。
また、
【数２】
は、ｘ以上の最小整数を表す。
【００４５】
この他の判定式については、例えば、以下の文献などに記載されている。
【００４６】
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 ]