(57)【要約】【課題】本発明は、子ノード毎かつサービスクラス毎のバッファ蓄積量を計算可能であって、親ノード搭載の演算用メモリを削減することが可能な簡易な計算方法を提供することにある。【解決手段】本発明に係る通信システムは、ＯＬＴ２０と複数のＯＮＵ１０が接続された通信システムであって、ＯＬＴ２０は、受信したデータに付与された宛先のＯＮＵ１０毎かつデータに付与されたサービスクラス毎に用意したバッファに蓄積しているデータ量を表す変数に対して、データのデータ量を加算するエンキュー処理手段と、前記変数から、予め定めた減算量を減算するデキュー処理手段と、を備える。【選択図】図１
2014045349.tif 000002
【特許請求の範囲】
【請求項１】
親ノードと複数の子ノードが接続された通信システムであって、
前記親ノードは、
受信したデータに付与された宛先の子ノード毎かつ前記データに付与されたサービスクラス毎に用意したデータ量を表す変数に対して、前記データのデータ量を加算するエンキュー処理手段と、
前記変数から、予め定めた減算量を減算するデキュー処理手段と、
を備える通信システム。
【請求項２】
前記デキュー処理手段は、前記減算量を優先度の高いサービスクラスを優先的に、予め定めた減算量を減算することを特徴とする請求項１に記載の通信システム。
【請求項３】
前記デキュー処理手段は、前記減算量を各サービスクラスについて予め定められた重みづけにて分割し、分割した減算量を前記変数から減算することを特徴とする請求項１に記載の通信システム。
【請求項４】
前記エンキュー処理手段は、
前記データのデータ量を加算後の前記変数が、受信したデータに付与された宛先の子ノード毎かつ前記データに付与されたサービスクラス毎に用意したデータを蓄積するバッファの最大容量を超えるか否かを判定し、
超える場合は、前記データのデータ量を加算後の前記変数から、前記最大容量の超過量を減算することを特徴とする請求項１から３のいずれかに記載の通信システム。
【請求項５】
親ノードと複数の子ノードが接続された通信システムに用いられる前記親ノードであって、
受信したデータに付与された宛先の子ノード毎かつ前記データに付与されたサービスクラス毎に用意したデータ量を表す変数に対して、前記データのデータ量を加算するエンキュー処理手段と、
前記変数から、予め定めた減算量を減算するデキュー処理手段と、
を備える親ノード。
【請求項６】
親ノードと複数の子ノードが接続された通信システムに用いられる前記親ノードにおける通信処理方法であって、
受信したデータに付与された宛先の子ノード毎かつ前記データに付与されたサービスクラス毎に用意したデータ量を表す変数に対して、前記データのデータ量を加算するエンキュー処理手順と、
前記変数から、予め定めた減算量を減算するデキュー処理手順と、
を有する通信処理方法。
【請求項７】
前記エンキュー処理手順は、データの到着の都度、前記エンキュー処理を実行し、
前記デキュー処理手順は、所定の時間経過を契機に、前記デキュー処理を実行する
ことを特徴とする請求項６に記載の通信処理方法。
【請求項８】
親ノードと複数の子ノードが接続された通信システムに用いられる前記親ノードにおける通信処理プログラムであって、
エンキュー処理手段が、受信したデータに付与された宛先の子ノード毎かつ前記データに付与されたサービスクラス毎に用意したデータ量を表す変数に対して、前記データのデータ量を加算するエンキュー処理手順と、
デキュー処理手段が、前記変数から、予め定めた減算量を減算するデキュー処理手順と、
をコンピュータに実行させる通信処理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データをその優先度に従って転送する通信システムに関し、特に、（データの転送先となる通信装置の）データを一時的に格納するバッファメモリのデータ蓄積量を計算することが可能な通信システムに関する。
【背景技術】
【０００２】
近年、通信装置において子ノードのバッファメモリに蓄積されたデータ量（以降バッファ蓄積量とする）を親ノード側で計算する方法が必要となっている。親ノードと子ノードから構成される通信装置の一例として、図１に示されるアクセスネットワークにおける、パッシブ光ネットワーク（Ｐａｓｓｉｖｅ  Ｏｐｔｉｃａｌ  Ｎｅｔｗｏｒｋ：ＰＯＮ）システムにおける通信事業者局内装置（Ｏｐｔｉｃａｌ  Ｌｉｎｅ  Ｔｅｒｍｉｎａｌ：ＯＬＴ）と加入者宅内装置（Ｏｐｔｉｃａｌ  Ｎｅｔｗｏｒｋ  Ｕｎｉｔ：ＯＮＵ）が挙げられる。
【０００３】
ＰＯＮシステムではＯＬＴ−ＯＮＵ間の通信速度とＵＮＩ（Ｕｓｅｒ−ｎｅｔｗｏｒｋ  ｉｎｔｅｒｆａｃｅ）の速度は、一般的にＯＬＴ−ＯＮＵ間の方が高速であることから、速度差を吸収し、データの損失を防ぐためにＯＮＵはバッファメモリを有する。
【０００４】
現在、１つのアクセス回線にて電話、テレビ、インターネットを実現するトリプルプレイサービスが提供されている。それらのサービスはそれぞれ必要とされる通信品質（データ損失率、遅延、遅延ゆらぎ等）が異なる。そのため、通信ネットワークでは様々なサービスを複数のサービスクラスに分類し、サービスクラス毎に満たすべき通信品質（ＱｏＳ：Ｑｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅ）が定められる。
【０００５】
サービスクラス毎に通信品質を担保する方法として、通信ネットワークではトラヒック規定と転送制御を行うことが一般的である。トラヒック規定とは、各サービスクラスに分類されたサービス毎について通信ネットワークに入力可能な平均レートと、バースト量と呼ばれるデータの塊の最大値を規定することである。転送制御とは、サービスクラスに対応した優先度識別子をデータに付加し、通信ネットワークを構成する通信装置に対して優先度毎にバッファ（キューとも呼ばれる）を設定した上、優先度識別子に基づいてデータを格納・出力することでデータの転送順序を制御することである。
【０００６】
さて、ＰＯＮシステムではＯＬＴでＯＮＵの下り（上位ネットワークからＵＮＩ方向の通信）バッファ蓄積量を計算する方法の具体例として、非特許文献１に代表されるＯＬＴによるフレームの優先度書換技術や、特許文献１および非特許文献２に代表されるＰＯＮシステムの省電力化技術等がある。
【０００７】
通信装置の優先度毎の出力バッファメモリに設定すべきバッファ量（以下バッファ設定量とする）は、トラヒック規定と転送制御方法及びユーザの通信品質保証型サービスの加入状況をもとにして、サービスクラス毎の通信品質を満たすように決定される。
【０００８】
ユーザが利用したい通信品質保証型サービスを提供するためには、通信事業者がＯＮＵバッファメモリ等の通信装置のリソースの設定をユーザの加入状況に応じて設定する必要がある。アクセスネットワークの通信装置は数量が膨大であるため、バッファ設定量をユーザ毎に設定・管理することは困難である。従って、アクセスネットワークの通信装置のバッファメモリの設定を簡易化することが望ましい。
【０００９】
この課題に対する一つの解決手段が従来技術１である。従来技術１であるＯＬＴによるフレームの優先度書換技術は、サービスクラス毎に設定されたバッファ設定量を変更することなく、ユーザのサービス使用状況により変動するバッファ蓄積量に応じてデータに付与されたサービスクラスを書換えることで、有限のバッファメモリを有効活用可能とし装置のバッファメモリの設定を簡易化することができる。
【００１０】
従来技術１では、ＯＬＴにて、ＯＮＵ毎かつサービスクラス毎に計算したバッファ蓄積量と予め指定した閾値と比較し、閾値よりバッファ蓄積量が大きい場合、データに付与されたサービスクラスを書換える。従って、ＯＬＴがＯＮＵのバッファ蓄積量を計算する機能が必須である。
【００１１】
次に従来技術２について説明する。昨今の消費電力削減の要請からＰＯＮシステムの省電力化が求められており、ＰＯＮシステムの省電力化のためにスリープ制御が提案されている。その一つのアプローチが特許文献１および非特許文献２に示される従来技術２である。
【００１２】
従来技術２はＯＮＵのスリープ効率向上のため、ＯＮＵに内部に記憶領域は少ないが低消費電力のバッファメモリと、記憶領域が大きいが消費電力も大きいバッファメモリの二つを用意し、ＯＮＵに流れるデータレートが低いときは消費電力の少ないバッファメモリを起動し、消費電力の大きいバッファメモリをスリープすることでＯＮＵの消費電力を削減する技術である。
【００１３】
従来技術２では、ＯＮＵ内蔵の二つのバッファメモリを切り替える際のデータの損失を防ぐためにＯＬＴがＯＮＵのバッファ蓄積量を計算し、予め与えたバッファ切替時間の間、当該ＯＮＵ宛に流れるデータに対してシェーピングを実施する。従ってＯＬＴがＯＮＵのバッファ蓄積量を計算する機能が必須である。
【００１４】
バッファ蓄積量を計算するためには、データがＯＮＵのバッファメモリに書き込まれる動作（以下、エンキュー動作とする）およびＯＮＵバッファメモリから読み出される動作（以下、デキュー動作とする）をＯＬＴが模擬する必要がある。ＯＮＵバッファのエンキュー動作はフレームの到着の都度、フレーム長をバッファ蓄積量を表す変数に足し合せることなどにより容易に実現できる。
【００１５】
また、デキュー動作を正確に計算するためには、ＯＮＵが受信するフレームのデータ量を図２のようにＯＮＵ毎かつサービスクラス毎に記憶し、所定のタイミングで前記バッファ蓄積量を表す変数から前記記憶したフレーム長を減算するなどの方法で実現できる。
【００１６】
一般にＯＮＵやＯＬＴといったアクセスネットワークの通信装置は、装置コストの削減や、消費電力削減の要請から非特許文献３に示されるように、メモリの搭載量を出来うる限り削減することが望まれている。こういった背景からアクセスネットワークの通信装置は、必要最小限しか演算用途のメモリを搭載することができない。そのため演算用のメモリ使用量が少ないバッファ蓄積量の計算方法が求められている。
【先行技術文献】
【特許文献】
【００１７】
【特許文献１】特開２０１２−４９７０７号公報
【非特許文献】
【００１８】
【非特許文献１】“ＯＮＵバッファを柔軟に使用可能なＯＬＴによる優先度書換の提案”、２０１２年電子情報通信学会総合大会  Ｂ−７−２９
【非特許文献２】“ＯＮＵのバッファ省電力化手法の検討”、２０１０年電子情報通信学会ソサエティ大会  Ｂ−８−１９
【非特許文献３】“１０Ｇ−ＥＰＯＮ  ＯＬＴおよびＯＮＵ用チップセットの開発（１）”、２０１２年電子情報通信学会総合大会  Ｃ−１２−２０
【発明の概要】
【発明が解決しようとする課題】
【００１９】
しかしながら、従来技術では、親ノードが子ノード毎かつ、サービスクラス毎のバッファ蓄積量を正確に計算するために、親ノードが受信したフレームのフレーム長を当該フレームが子ノードからデキューされるまで記憶し続ける必要があった。
【００２０】
従って、バッファ蓄積量計算機能を親ノードに追加すると、バッファ蓄積量計算機能を追加しない場合と比較して前記フレーム長を記憶するための演算用メモリが更に必要となり、親ノードに搭載すべき演算用メモリが増加してしまうという問題があった。
【００２１】
本発明は、上記課題を解消するためになされたものであり、その目的は、子ノード毎かつサービスクラス毎のバッファ蓄積量を計算可能であって、親ノード搭載の演算用メモリを削減することが可能な簡易な計算方法を提供することにある。
【課題を解決するための手段】
【００２２】
前記目標を達成するため、本発明は、親ノードが行う子ノードのデキュー動作の模擬について、受信したフレーム長を使用することなくバッファ蓄積量を計算することとした。
【００２３】
具体的には、本発明に係る通信システムは、親ノードと複数の子ノードが接続された通信システムであって、前記親ノードは、受信したデータに付与された宛先の子ノード毎かつ前記データに付与されたサービスクラス毎に用意したデータ量を表す変数に対して、前記データのデータ量を加算するエンキュー処理手段と、前記変数から、予め定めた減算量を減算するデキュー処理手段と、を備える。
【００２４】
従来技術ではデキュー処理の計算に親ノードが受信したデータ量を図２のように記憶する必要があった。本発明では、デキュー動作の計算において、予め定めた減算量を利用するため、前記受信データ量を必要としない。従って、データ量を記憶するために必要な演算用メモリを削減することができる。
【００２５】
本発明に係る通信システムでは、前記デキュー処理手段は、前記減算量を優先度の高いサービスクラスを優先的に、予め定めた減算量を減算してもよい。
本通信システムは、優先度の高いクラスのバッファから出力データの減算を行うことで優先度の高いサービスクラスからデータを読み出す完全優先制御を模擬したバッファ蓄積量計算を行うことができる。
【００２６】
本発明に係る通信システムでは、前記デキュー処理手段は、前記減算量を各サービスクラスについて予め定められた重みづけにて分割し、分割した減算量を前記変数から減算してもよい。
本通信システムは、一度の計算に係る減算量を重みづけに従ってクラス毎の減算量に分割した上で減算を行うことで各サービスクラスについて予め定められた重みづけにてデータを読み出す重みづけラウンドロビンを模擬したバッファ蓄積量計算を行うことができる。
【００２７】
本発明に係る通信システムでは、前記エンキュー処理手段は、前記データのデータ量を加算後の前記変数が、受信したデータに付与された宛先の子ノード毎かつ前記データに付与されたサービスクラス毎に用意したデータを蓄積するバッファの最大容量を超えるか否かを判定し、超える場合は、前記データのデータ量を加算後の前記変数から、前記最大容量の超過量を減算してもよい。
【００２８】
本発明に係る親ノードは、親ノードと複数の子ノードが接続された通信システムに用いられる前記親ノードであって、受信したデータに付与された宛先の子ノード毎かつ前記データに付与されたサービスクラス毎に用意したデータ量を表す変数に対して、前記データのデータ量を加算するエンキュー処理手段と、前記変数から、予め定めた減算量を減算するデキュー処理手段と、を備える。
【００２９】
本発明に係る通信処理方法は、親ノードと複数の子ノードが接続された通信システムに用いられる前記親ノードにおける通信処理方法であって、受信したデータに付与された宛先の子ノード毎かつ前記データに付与されたサービスクラス毎に用意したデータ量を表す変数に対して、前記データのデータ量を加算するエンキュー処理手順と、前記変数から、予め定めた減算量を減算するデキュー処理手順と、を有する。
【００３０】
本発明に係る通信処理方法では、前記エンキュー処理手順は、データの到着の都度、前記エンキュー処理を実行し、前記デキュー処理手順は、所定の時間経過を契機に、前記デキュー処理を実行してもよい。
本通信処理方法は、エンキュー処理をデータの到着毎に行い、デキュー処理を所定の時間経過を契機に計算する。従って本発明はバッファに対するデータの蓄積量計算をハードウェアおよびソフトウェアに実装する際の設計自由度を高めることができる。
【００３１】
本発明に係る通信処理プログラムは、親ノードと複数の子ノードが接続された通信システムに用いられる前記親ノードにおける通信処理プログラムであって、エンキュー処理手段が、受信したデータに付与された宛先の子ノード毎かつ前記データに付与されたサービスクラス毎に用意したデータ量を表す変数に対して、前記データのデータ量を加算するエンキュー処理手順と、デキュー処理手段が、前記変数から、予め定めた減算量を減算するデキュー処理手順と、
をコンピュータに実行させる。
【発明の効果】
【００３２】
本発明は、親ノードが受信したデータのデータ量を利用することなくバッファ蓄積量を計算することが可能であり、バッファ蓄積量計算に必要な親ノードの演算用メモリを削減することができる。
【図面の簡単な説明】
【００３３】
【図１】アクセスネットワークの一例を示す。
【図２】ＯＬＴが受信したデータ量を記憶するテーブルの一例を示す。
【図３】実施形態１の通信システムを説明する図である。
【図４】エンキュー動作の計算方法の一例を示すフロー図である。
【図５】デキュー動作の計算方法の一例を示すフロー図である。
【図６】実施形態２に係るデキュー動作の計算方法の一例を示すフロー図である。
【発明を実施するための形態】
【００３４】
以下に、本発明の実施の形態について図面を参照して詳細に記述する。以下に説明する実施形態では通信で用いられるデータを単にデータと表記するが、それは例えばＯＳＩ参照モデルにて示されるＬ３のパケットやＬ２のフレームである。また、ＰＯＮシステムを通信システムの例として説明を行うが、本発明の要旨を逸脱しない範囲において適宜変更可能である。
【００３５】
（実施形態１）
図３は、実施形態１の通信システムを説明する図である。本実施形態に係る通信システムは、親ノードであるＯＬＴ２０と、子ノードであるＯＮＵ１０を備える。ＯＬＴ２０は、メモリ２１と、演算部２２と、データ情報測定部２３とを備える。本実施形態では、演算部２２及びデータ情報測定部２３が、エンキュー処理手段として機能するとともにデキュー処理手段として機能する。データ情報測定部２３は、ＯＬＴ２０に入力されたデータから、データ量と、ＯＮＵ１０と、データに付与されたサービスクラスと、を測定する。メモリ２１は、ＯＮＵ１０毎かつサービスクラス毎に用意したバッファ蓄積量を表す変数を保存する。演算部２２は、メモリ２１に格納されたデータ量を表す変数Ｂｉ，ｊを参照し、データ情報測定部２３の測定したデータ量を用いて演算する。
【００３６】
本発明に係る通信処理方法は、エンキュー処理手順及びデキュー処理手順を有する。これらの手順は演算部２２及びデータ情報測定部２３が実行する。以下に演算部２２の計算手順を示す。計算はエンキュー動作とデキュー動作により成り立つ。本例ではそれぞれの動作を並列に計算することを想定して説明するが、それぞれの動作をシリアルに処理してもよい。すなわち、エンキュー処理手順及びデキュー処理手順は、どちらを先に行ってもよいし、同時に行ってもよい。
【００３７】
まず、エンキュー動作を図３及び図４を用いて説明する。
エンキュー動作はＯＬＴ２０のデータ情報測定部２３がデータを受信したことを契機に計算を開始する。データ情報測定部２３は、データに付与されたデータ量、宛先ＯＮＵ、サービスクラス識別情報などの制御信号を演算部２２に対して送信する。ここでは、データ単位にエンキュー動作を実行する説明をするが、エンキュー動作はバースト単位に計算を行ってもよい。ここでいうバーストとは同一のＯＮＵ１０に転送される同じ優先度のサービスクラスのバッファに収容されるデータの塊のことを指す。
【００３８】
ステップＳ４００では、エンキュー動作対象となるＯＮＵ１０およびサービスクラスを特定する。具体的にはデータ情報測定部２３が測定した宛先ＯＮＵならびにサービスクラスから、ＯＮＵ１０毎かつサービスクラス毎に用意したバッファ蓄積量を示す変数Ｂｉｊ（ｉ：ＯＮＵの識別変数、ｊ：サービスクラス識別変数）を決定する。
【００３９】
ステップＳ４０１では、ＯＮＵ１０毎かつサービスクラス毎に用意したバッファ蓄積量を示す変数Ｂｉｊに、データ情報測定部２３の測定したデータ量を加算する。具体的にはステップＳ４００にて決定されたＢｉｊに対して受信したデータのデータ量Ｆを加算し、新たなＢｉｊとしてメモリ２１に保存する。
【００４０】
ステップＳ４０２ではＯＮＵ１０におけるバッファにあふれがないかチェックする。具体的には、新たなＢｉｊとしてメモリ２１に保存したＢｉｊと当該ＯＮＵの当該サービスクラスにおけるバッファの最大量Ｂｍａｘ  ｉ，ｊと比較し、Ｂｍａｘ  ｉ，ｊよりＢｉｊが小さいもしくは同じであれば計算を終了する。もし、Ｂｍａｘ  ｉ，ｊよりＢｉｊの方が大きい場合はステップＳ４０３に進む。Ｂｍａｘ  ｉ，ｊはあらかじめＯＬＴ２０に与えておいてもよいし、ＯＬＴ２０がＯＮＵ１０などと通信することによって取得してもよい。
【００４１】
ステップＳ４０３では、ＯＮＵ１０におけるバッファからあふれる分のデータ量を減算する。具体的にはステップＳ４０１にて加算したデータ量Ｆを減算し、新たなＢｉｊとして保存し計算を終了する。
【００４２】
以上のステップによりエンキュー動作の模擬は完了となる。この計算方法によれば、データ到着を契機とし、データ単位に計算を開始することで、ＯＮＵ１０のバッファ蓄積量を正確に計算できる。
【００４３】
次にデキュー動作を図５を用いて説明する。
本例ではＯＮＵ１０のバッファのスケジューリング方式が優先度の高いサービスクラスのデータからＵＮＩに出力される完全優先制御であるとして計算を行う。さらにＯＮＵ１０は２つのバッファを持つものとして説明を行うが、１つもしくは２つより多くのバッファを持っていてもよい。本例では、デキュー動作の計算を予め設定された一定の時間間隔かつ、ＯＮＵ１０毎に独立して行うこととする。
【００４４】
ステップＳ５００では計算を行うサービスクラスを設定する。具体的には、最も優先度の高いサービスクラスの値にｊを初期化する（本例では０が最も優先度が高いサービスクラスとした）。
【００４５】
ステップＳ５０１では最優先のサービスクラスにデータが蓄積しているかを判定する。具体的には、当該サービスクラスの変数Ｂｉｊの値を参照し、変数Ｂｉｊが０であればステップＳ５０７に移動する。もし、Ｂｉｊが０でなければ、ステップＳ５０２に進む。
【００４６】
ステップＳ５０２では最優先のサービスクラスから減算量を引く、減算量がバッファ蓄積量に対して過剰だった場合、過剰分を一時変数ｆｔとしてメモリ２１に保存し、２番目に高い優先度バッファのＢｉｊ計算に用いる。具体的にはＢｉｊから減算量ｆを減算し、新たなＢｉｊとする。もし減算によりＢｉｊが０よりも小さくなった場合、その時点の値を計算用の一次変数ｆｔに保存し（本例ではｆｔは負の値）、Ｂｉｊの値を０とする。減算量ｆは、例えばデキュー動作の計算周期と当該ＯＮＵ１０のＵＮＩ速度の積によって計算される。
【００４７】
ステップＳ５０３では２番目に優先度の高いバッファのデキュー動作を計算するか判定する。具体的には、一時変数ｆｔの値が０であれば計算を終了する。もしｆｔが０でなければステップＳ５０４に進む。
【００４８】
ステップＳ５０４では２番目に優先度の高いバッファを指定する。本例ではｊ＝１である。
【００４９】
ステップＳ５０５では、２番目に優先度の高いバッファにデータが蓄積されているか確認する。具体的には、ｊ＝１のサービスクラスのＢｉｊの値を参照し、Ｂｉｊが０であれば計算を終了する。もし、Ｂｉｊが０でなければ、ステップＳ５０６に進む。
【００５０】
ステップＳ５０６では、変数Ｂｉｊに一時変数ｆｔを加算し、新たなＢｉｊとする。もし加算によりＢｉｊが０よりも小さくなった場合、Ｂｉｊの値を０とし計算を終了する。
【００５１】
ステップＳ５０７では２番目に優先度の高いバッファを指定する。本例ではｊ＝１である。
【００５２】
ステップＳ５０８では２番目に優先度の高いバッファにデータが蓄積されているか確認する。具体的には、ｊ＝１のサービスクラスのＢｉｊの値を参照し、Ｂｉｊが０であれば計算を終了する。もし、Ｂｉｊが０でなければ、ステップＳ５０９に進む。
【００５３】
ステップＳ５０９では２番目に優先度の高いサービスクラスから減算量ｆをひく。具体的には、ｊ＝１のＢｉｊから減算量ｆを減算し、新たなＢｉｊとする。もし減算によりＢｉｊが０よりも小さくなった場合、Ｂｉｊの値を０とし計算を終了する。
【００５４】
以上で、デキュー処理の計算は終了である。従来技術ではデキューデータの計算にＯＬＴ２０が受信したデータ量を図２のように記憶する必要があった。本例では、デキュー動作の計算において、減算量ｆを所定の値とすることで、ＯＬＴ２０が受信したデータ量の情報を必要としない。従って、データ量を記憶するために必要なメモリを削減することができる。さらに、上述のように、優先度の高いサービスクラスのバッファから減算を行うことで完全優先制御を模擬することができる。
【００５５】
（実施形態２）
本実施形態では、ＯＮＵ１０が各サービスクラスについて予め定められた重みづけにてデータを読み出す重みづけラウンドロビンスケジューリングであることを想定して説明する。また、本例ではＯＮＵ１０は２つのバッファを持つものとして説明を行うが、１つもしくは２つより多くのバッファを持っていてもよい。
【００５６】
実施形態２が実施形態１と異なる点はデキュー動作の計算方法にある。図６を用いて本実施形態の動作を示す。計算は一定の時間間隔かつＯＮＵ１０毎に独立して行うこととする。
【００５７】
ステップＳ６００では各サービスクラスにおける減算量ｆｊを決定する。具体的には、例えばデキュー動作の計算周期と当該ＯＮＵのＵＮＩ速度の積によって計算される減算量ｆを、各サービスクラスによって異なる重み付けに従って分割する。
【００５８】
ステップＳ６０１では計算を行うサービスクラスを設定する。具体的には、最も優先度の高いサービスクラスの値にｊを初期化する。本例では０が最も優先度が高いサービスクラスとした。
【００５９】
ステップＳ６０２では該当サービスクラスにデータが蓄積しているかを判定する。具体的には、当該サービスクラスのＢｉｊの値を参照し、Ｂｉｊが０であればステップＳ６０４に移動する。もし、Ｂｉｊが０でなければ、ステップＳ６０３に進む
【００６０】
ステップＳ６０３ではＢｉｊから減算量ｆｊを減算する。具体的にはＢｉｊからサービスクラス別の減算量ｆｊを減算し、新たなＢｉｊとする。もし減算によりＢｉｊが０よりも小さくなった場合、Ｂｉｊの値を０とし計算を終了する。
【００６１】
ステップＳ６０４では計算を行うサービスクラスを設定する。具体的には、２番目に優先度の高いサービスクラスの値にｊを初期化する。本例では１が２番目に優先度が高いサービスクラスとした。
【００６２】
ステップＳ６０５では該当サービスクラスにデータが蓄積しているかを判定する。具体的には、当該サービスクラスのＢｉｊの値を参照し、Ｂｉｊが０であれば計算を終了する。もし、Ｂｉｊが０でなければ、ステップＳ６０６に進む
【００６３】
ステップＳ６０６ではＢｉｊから減算量ｆｊを減算する。具体的にはＢｉｊからサービスクラス別の減算量ｆｊを減算し、新たなＢｉｊとする。もし減算によりＢｉｊが０よりも小さくなった場合、Ｂｉｊの値を０とし計算を終了する。
【００６４】
以上で本例におけるデキュー処理の計算は終了である。従来技術ではデキューデータの計算にＯＬＴ２０が受信したデータ量を図２のように記憶する必要があった。本例では、デキュー動作の計算において、減算量ｆを所定の値とすることで、ＯＬＴ２０が受信したデータ量の情報を必要としない。従って、データ量を記憶するために必要なメモリを削減することができる。さらに、上述のように、減算量ｆを重みづけに従ってサービスクラス毎の減算量ｆｊに分割した上でＢｉｊから減算を行うことで重みづけラウンドロビンを模擬することができる。
【００６５】
なお、以上の実施形態において説明した装置は、プログラムをコンピュータに実行させることによって実現してもよい。
【産業上の利用可能性】
【００６６】
本発明は情報通信産業に適用することができる。
【符号の説明】
【００６７】
１０：ＯＮＵ
２０：ＯＬＴ
２１：メモリ
２２：演算部
２３：データ情報測定部
【図１】
2014045349.tif 000003
【図２】
2014045349.tif 000004
【図３】
2014045349.tif 000005
【図４】
2014045349.tif 000006
【図５】
2014045349.tif 000007
【図６】
2014045349.tif 000008