(57)【要約】【課題】可変長のギャップに対応することにより、通信効率の低下を防ぐことが可能な通信装置、光ネットワークシステムおよび通信方法を提供する。【解決手段】通信装置１０２において、制御部２３は、送信すべき組のデータ長の総和を他の装置に通知するためのレポートを生成すること、およびデータ長の総和が他の装置から通知された最大送信許可量以下になるように、組を送信すべきデータとして選択すること、の少なくとも一方を行なう。そして、制御部２３は、他の装置へ送信すべき複数のパケットのうち、先頭のパケットに対応するギャップのデータ長が決定されたときに用いられた差と、最後尾のパケットに対応するギャップのデータ長が決定されたときに用いられた差とに基づいて、他の装置に通知するデータ長の総和の補正、および最大送信許可量との比較に用いる組のデータ長の総和の補正の少なくとも一方を行なう。【選択図】図３
2010088103.tif 000002
【特許請求の範囲】
【請求項１】
複数のパケットを他の装置へ送信する通信装置であって、
受信または生成したパケット間に挿入されるデータであるギャップの数および所定データ長の積と、前記ギャップの累積長との差を算出し、前記算出した差に基づいて、新たに挿入すべきギャップのデータ長を決定する制御部と、
前記パケットおよび対応の前記ギャップの組のデータ長を示す情報と、前記組のギャップのデータ長が決定されたときに用いられた前記差とを含むコードベクタテーブルを生成するテーブル生成部とを備え、
前記制御部は、前記コードベクタテーブルに基づいて、送信すべき１または複数の前記組のデータ長の総和を前記他の装置に通知するためのレポートを生成すること、およびデータ長の総和が前記他の装置から通知された最大送信許可量以下になるように、１または複数の前記組を送信すべきデータとして選択すること、の少なくとも一方を行ない、
前記制御部は、前記他の装置へ送信すべき複数のパケットのうち、先頭のパケットに対応する前記ギャップのデータ長が決定されたときに用いられた前記差と、最後尾のパケットに対応する前記ギャップのデータ長が決定されたときに用いられた前記差とに基づいて、前記他の装置に通知するデータ長の総和の補正、および前記最大送信許可量との比較に用いる前記組のデータ長の総和の補正の少なくとも一方を行なう通信装置。
【請求項２】
前記制御部は、前記他の装置へ送信すべき複数のパケットのうち、先頭のパケットに対応する前記ギャップのデータ長が決定されたときに用いられた前記差が最後尾のパケットに対応する前記ギャップのデータ長が決定されたときに用いられた前記差より大きい場合には、前記他の装置に通知するデータ長の総和の補正、および前記最大送信許可量との比較に用いる前記組のデータ長の総和の補正の少なくとも一方を行なう請求項１に記載の通信装置。
【請求項３】
前記制御部は、さらに、前記パケットおよび対応の前記ギャップの組のデータ長が所定値単位となるように前記ギャップの長さを決定し、
前記制御部は、前記他の装置へ送信すべき複数のパケットのうち、先頭のパケットに対応する前記ギャップのデータ長が決定されたときに用いられた前記差と、最後尾のパケットに対応する前記ギャップのデータ長が決定されたときに用いられた前記差と、前記所定値とに基づいて、前記他の装置に通知するデータ長の総和の補正、および前記最大送信許可量との比較に用いる前記組のデータ長の総和の補正の少なくとも一方を行なう請求項１または２に記載の通信装置。
【請求項４】
前記制御部は、１または複数の前記パケットをそれぞれ有する複数のキューに跨って前記レポートの生成および前記送信すべきデータの選択を行なう場合には、前記他の装置へ送信すべき複数の前記パケットを有する前記複数のキューのうち、最後尾のパケットに対応するキュー以外のキューにおいて、先頭のパケットに対応する前記ギャップのデータ長が決定されたときに用いられた前記差と、最後尾のパケットに対応する前記ギャップのデータ長が決定されたときに用いられた前記差とに基づいて、前記他の装置に通知するデータ長の総和の補正、および前記最大送信許可量との比較に用いる前記組のデータ長の総和の補正を行なう請求項１から３のいずれかに記載の通信装置。
【請求項５】
前記制御部は、前記他の装置が前記通信装置から受信した１または複数の前記組の誤り訂正処理を行なうために前記１または複数の組に付加して送信すべき誤り訂正用データのデータ長に基づいて前記最大送信許可量を補正し、
前記制御部は、前記コードベクタテーブルに基づいて、１または複数の前記組のデータ長の総和が、補正された前記最大送信許可量以下になるように、１または複数の前記組を送信すべきデータとして選択する請求項１から４のいずれかに記載の通信装置。
【請求項６】
前記通信装置は、前記他の装置へ送信すべき複数のパケットの先頭に前記所定データ長を含む所定範囲の可変データ長を有するヘッダを付加して前記他の装置へ送信し、
前記制御部は、前記ヘッダおよび前記ギャップの総数と前記所定データ長との積と、前記所定データ長および前記ギャップの累積長の和との差を算出し、前記算出した差に基づいて、新たに挿入すべきギャップのデータ長を決定し、
前記制御部は、前記コードベクタテーブルに基づいて、前記他の装置に通知すべき１または複数の前記組のデータ長の総和が所定の最大レポート量以下になるように、１または複数の前記組を選択し、選択した１または複数の前記組のデータ長の総和を前記他の装置に通知するためのレポートを生成すること、およびデータ長の総和が前記他の装置から通知された最大送信許可量以下になるように、１または複数の前記組を送信すべきデータとして選択すること、の少なくとも一方を行ない、
前記制御部は、付加すべき前記ヘッダのデータ長と前記所定データ長との差に基づいて前記最大レポート量および前記最大送信許可量の少なくとも一方を補正し、
前記制御部は、補正された前記最大レポート量または補正された前記最大送信許可量を用いて前記レポートの生成および前記送信すべきデータの選択の少なくとも一方を行なう請求項１から５のいずれかに記載の通信装置。
【請求項７】
前記制御部は、前記コードベクタテーブルに基づいて、前記他の装置に通知すべき１または複数の前記組のデータ長の総和が所定の最大レポート量以下になるように、１または複数の前記組を選択し、選択した１または複数の前記組のデータ長の総和を前記他の装置に通知するためのレポートを生成すること、およびデータ長の総和が前記他の装置から通知された最大送信許可量以下になるように、１または複数の前記組を送信すべきデータとして選択すること、の少なくとも一方を行ない、
前記制御部は、前記他の装置が前記通信装置から受信した前記複数のパケットの最後尾を検出するために前記最後尾に付加して送信すべき終了コードのデータ長に基づいて前記最大レポート量および前記最大送信許可量の少なくとも一方を補正し、
前記制御部は、補正された前記最大レポート量または補正された前記最大送信許可量を用いて前記レポートの生成および前記送信すべきデータの選択の少なくとも一方を行なう請求項１から６のいずれかに記載の通信装置。
【請求項８】
第１の通信装置と、
光ファイバ経由で複数のパケットを前記第１の通信装置へ送信する第２の通信装置とを備え、
前記第２の通信装置は、
受信または生成したパケット間に挿入されるデータであるギャップの数および所定データ長の積と、前記ギャップの累積長との差を算出し、前記算出した差に基づいて、新たに挿入すべきギャップのデータ長を決定する制御部と、
前記パケットおよび対応の前記ギャップの組のデータ長を示す情報と、前記組のギャップのデータ長が決定されたときに用いられた前記差とを含むコードベクタテーブルを生成するテーブル生成部とを含み、
前記制御部は、前記コードベクタテーブルに基づいて、送信すべき１または複数の前記組のデータ長の総和を前記第１の通信装置に通知するためのレポートを生成すること、およびデータ長の総和が前記第１の通信装置から通知された最大送信許可量以下になるように、１または複数の前記組を送信すべきデータとして選択すること、の少なくとも一方を行ない、
前記制御部は、前記第１の通信装置へ送信すべき複数のパケットのうち、先頭のパケットに対応する前記ギャップのデータ長が決定されたときに用いられた前記差と、最後尾のパケットに対応する前記ギャップのデータ長が決定されたときに用いられた前記差とに基づいて、前記第１の通信装置に通知するデータ長の総和の補正、および前記最大送信許可量との比較に用いる前記組のデータ長の総和の補正の少なくとも一方を行なう光ネットワークシステム。
【請求項９】
複数のパケットを他の装置へ送信する通信方法であって、
受信または生成したパケット間に挿入されるデータであるギャップの数および所定データ長の積と、前記ギャップの累積長との差を算出するステップと、
前記算出した差に基づいて、新たに挿入すべきギャップのデータ長を決定するステップと、
前記パケットおよび対応の前記ギャップの組のデータ長を示す情報と、前記組のギャップのデータ長が決定されたときに用いられた前記差とを含むコードベクタテーブルを生成するステップと、
前記コードベクタテーブルに基づいて、送信すべき１または複数の前記組のデータ長の総和を前記他の装置に通知するためのレポートを生成すること、およびデータ長の総和が前記他の装置から通知された最大送信許可量以下になるように、１または複数の前記組を送信すべきデータとして選択すること、の少なくとも一方を行なうステップとを含み、
前記データ長の通知および前記組の選択の少なくとも一方を行なうステップにおいては、前記他の装置へ送信すべき複数のパケットのうち、先頭のパケットに対応する前記ギャップのデータ長が決定されたときに用いられた前記差と、最後尾のパケットに対応する前記ギャップのデータ長が決定されたときに用いられた前記差とに基づいて、前記他の装置に通知するデータ長の総和の補正、および前記最大送信許可量との比較に用いる前記組のデータ長の総和の補正の少なくとも一方を行なう通信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数の宅側装置が媒体を共有してデータの伝送を行なう媒体共有型通信であるＰＯＮ（Passive Optical Network）のうち、パケット間に挿入されるギャップの長さ
が可変であるＰＯＮにおける通信装置、光ネットワークシステムおよび通信方法に関する。
【背景技術】
【０００２】
光ファイバを用いた公衆回線網において１ギガビット／秒の通信速度を実現し、かつデータをイーサネット（登録商標）フレームのままで伝送するＧＥ−ＰＯＮ（Giga Bit Ethernet(登録商標) Passive Optical Network）が開発されている。
【０００３】
たとえば、特許文献１には、以下のような光加入者線終端装置が開示されている。すなわち、光加入者線端局装置からのグラントに応じてレポートを送信する光加入者線終端装置であって、光加入者線端局装置からのデータおよびグラントを受信するための第１の受信手段と、第１の受信手段によって受信されたデータを下位ネットワークに送信するための第１の送信手段と、第１の受信手段によって受信されたグラントに含まれる最大送信許可量以下で、かつ最大となる送信要求量を決定するための決定手段と、決定手段によって決定された送信要求量を含んだレポートを生成するための生成手段と、下位ネットワークからデータを受信するための第２の受信手段と、第２の受信手段によって受信されたデータおよび生成手段によって生成されたレポートを記憶するための記憶手段と、記憶手段によって記憶されたデータおよびレポートを光加入者線端局装置に送信するための第２の送信手段とを含む。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００４−１９４２６３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
ところで、現在、ＧＥ−ＰＯＮに対して、さらに高速な１０ギガビット／秒の通信速度を実現する１０ギガビットイーサネット（登録商標）ＰＯＮ規格の制定が進められている。この規格では、フレーム間に挿入されるギャップが２０バイトの固定長に設定されるＧＥ−ＰＯＮとは異なり、フレーム間に挿入されるギャップが１７バイト〜２３バイトの可変長に設定される。なお、１０ギガビットイーサネット（登録商標）ＰＯＮ規格では、運用開始から現在までに生成されたギャップの長さの平均が２０バイトを超えないように、新たなギャップの長さが決定される。
【０００６】
しかしながら、特許文献１記載の構成では、ギャップが可変長であることが考慮されていないため、ＯＮＵ（光加入者線終端装置：Optical Network Unit）からＯＬＴ（Optical Line Terminal）へのレポートに含まれる送信要求量を正確に算出することが困難である。ここで、１０ギガビットイーサネット（登録商標）ＰＯＮ規格では、ＯＬＴへのレポートに含まれる送信要求量の単位は、２バイトであるＧＥ−ＰＯＮとは異なり、２０バイトである。このため、送信要求量が誤って算出されると、ＯＮＵからＯＬＴへデータを送信するための帯域がＰＯＮシステムにおいて大幅に浪費されてしまう。
【０００７】
それゆえに、本発明の目的は、可変長のギャップに対応することにより、通信効率の低下を防ぐことが可能な通信装置、光ネットワークシステムおよび通信方法を提供することである。
【課題を解決するための手段】
【０００８】
上記課題を解決するために、この発明のある局面に係わる通信装置は、複数のパケットを他の装置へ送信する通信装置であって、受信または生成したパケット間に挿入されるデータであるギャップの数および所定データ長の積と、上記ギャップの累積長との差を算出し、上記算出した差に基づいて、新たに挿入すべきギャップのデータ長を決定する制御部と、上記パケットおよび対応の上記ギャップの組のデータ長を示す情報と、上記組のギャップのデータ長が決定されたときに用いられた上記差とを含むコードベクタテーブルを生成するテーブル生成部とを備え、上記制御部は、上記コードベクタテーブルに基づいて、送信すべき１または複数の上記組のデータ長の総和を上記他の装置に通知するためのレポートを生成すること、およびデータ長の総和が上記他の装置から通知された最大送信許可量以下になるように、１または複数の上記組を送信すべきデータとして選択すること、の少なくとも一方を行ない、上記制御部は、上記他の装置へ送信すべき複数のパケットのうち、先頭のパケットに対応する上記ギャップのデータ長が決定されたときに用いられた上記差と、最後尾のパケットに対応する上記ギャップのデータ長が決定されたときに用いられた上記差とに基づいて、上記他の装置に通知するデータ長の総和の補正、および上記最大送信許可量との比較に用いる上記組のデータ長の総和の補正の少なくとも一方を行なう。
【０００９】
好ましくは、上記制御部は、上記他の装置へ送信すべき複数のパケットのうち、先頭のパケットに対応する上記ギャップのデータ長が決定されたときに用いられた上記差が最後尾のパケットに対応する上記ギャップのデータ長が決定されたときに用いられた上記差より大きい場合には、上記他の装置に通知するデータ長の総和の補正、および上記最大送信許可量との比較に用いる上記組のデータ長の総和の補正の少なくとも一方を行なう。
【００１０】
好ましくは、上記制御部は、さらに、上記パケットおよび対応の上記ギャップの組のデータ長が所定値単位となるように上記ギャップの長さを決定し、上記制御部は、上記他の装置へ送信すべき複数のパケットのうち、先頭のパケットに対応する上記ギャップのデータ長が決定されたときに用いられた上記差と、最後尾のパケットに対応する上記ギャップのデータ長が決定されたときに用いられた上記差と、上記所定値とに基づいて、上記他の装置に通知するデータ長の総和の補正、および上記最大送信許可量との比較に用いる上記組のデータ長の総和の補正の少なくとも一方を行なう。
【００１１】
好ましくは、上記制御部は、１または複数の上記パケットをそれぞれ有する複数のキューに跨って上記レポートの生成および上記送信すべきデータの選択を行なう場合には、上記他の装置へ送信すべき複数の上記パケットを有する上記複数のキューのうち、最後尾のパケットに対応するキュー以外のキューにおいて、先頭のパケットに対応する上記ギャップのデータ長が決定されたときに用いられた上記差と、最後尾のパケットに対応する上記ギャップのデータ長が決定されたときに用いられた上記差とに基づいて、上記他の装置に通知するデータ長の総和の補正、および上記最大送信許可量との比較に用いる上記組のデータ長の総和の補正を行なう。
【００１２】
好ましくは、上記制御部は、上記他の装置が上記通信装置から受信した１または複数の上記組の誤り訂正処理を行なうために上記１または複数の組に付加して送信すべき誤り訂正用データのデータ長に基づいて上記最大送信許可量を補正し、上記制御部は、上記コードベクタテーブルに基づいて、１または複数の上記組のデータ長の総和が、補正された上記最大送信許可量以下になるように、１または複数の上記組を送信すべきデータとして選択する。
【００１３】
好ましくは、上記通信装置は、上記他の装置へ送信すべき複数のパケットの先頭に上記所定データ長を含む所定範囲の可変データ長を有するヘッダを付加して上記他の装置へ送信し、上記制御部は、上記ヘッダおよび上記ギャップの総数と上記所定データ長との積と、上記所定データ長および上記ギャップの累積長の和との差を算出し、上記算出した差に基づいて、新たに挿入すべきギャップのデータ長を決定し、上記制御部は、上記コードベクタテーブルに基づいて、上記他の装置に通知すべき１または複数の上記組のデータ長の総和が所定の最大レポート量以下になるように、１または複数の上記組を選択し、選択した１または複数の上記組のデータ長の総和を上記他の装置に通知するためのレポートを生成すること、およびデータ長の総和が上記他の装置から通知された最大送信許可量以下になるように、１または複数の上記組を送信すべきデータとして選択すること、の少なくとも一方を行ない、上記制御部は、付加すべき上記ヘッダのデータ長と上記所定データ長との差に基づいて上記最大レポート量および上記最大送信許可量の少なくとも一方を補正し、上記制御部は、補正された上記最大レポート量または補正された上記最大送信許可量を用いて上記レポートの生成および上記送信すべきデータの選択の少なくとも一方を行なう。
【００１４】
好ましくは、上記制御部は、上記コードベクタテーブルに基づいて、上記他の装置に通知すべき１または複数の上記組のデータ長の総和が所定の最大レポート量以下になるように、１または複数の上記組を選択し、選択した１または複数の上記組のデータ長の総和を上記他の装置に通知するためのレポートを生成すること、およびデータ長の総和が上記他の装置から通知された最大送信許可量以下になるように、１または複数の上記組を送信すべきデータとして選択すること、の少なくとも一方を行ない、上記制御部は、上記他の装置が上記通信装置から受信した上記複数のパケットの最後尾を検出するために上記最後尾に付加して送信すべき終了コードのデータ長に基づいて上記最大レポート量および上記最大送信許可量の少なくとも一方を補正し、上記制御部は、補正された上記最大レポート量または補正された上記最大送信許可量を用いて上記レポートの生成および上記送信すべきデータの選択の少なくとも一方を行なう。
【００１５】
上記課題を解決するために、この発明のある局面に係わる光ネットワークシステムは、第１の通信装置と、光ファイバ経由で複数のパケットを上記第１の通信装置へ送信する第２の通信装置とを備え、上記第２の通信装置は、受信または生成したパケット間に挿入されるデータであるギャップの数および所定データ長の積と、上記ギャップの累積長との差を算出し、上記算出した差に基づいて、新たに挿入すべきギャップのデータ長を決定する制御部と、上記パケットおよび対応の上記ギャップの組のデータ長を示す情報と、上記組のギャップのデータ長が決定されたときに用いられた上記差とを含むコードベクタテーブルを生成するテーブル生成部とを含み、上記制御部は、上記コードベクタテーブルに基づいて、送信すべき１または複数の上記組のデータ長の総和を上記第１の通信装置に通知するためのレポートを生成すること、およびデータ長の総和が上記第１の通信装置から通知された最大送信許可量以下になるように、１または複数の上記組を送信すべきデータとして選択すること、の少なくとも一方を行ない、上記制御部は、上記第１の通信装置へ送信すべき複数のパケットのうち、先頭のパケットに対応する上記ギャップのデータ長が決定されたときに用いられた上記差と、最後尾のパケットに対応する上記ギャップのデータ長が決定されたときに用いられた上記差とに基づいて、上記第１の通信装置に通知するデータ長の総和の補正、および上記最大送信許可量との比較に用いる上記組のデータ長の総和の補正の少なくとも一方を行なう。
【００１６】
上記課題を解決するために、この発明のある局面に係わる通信方法は、複数のパケットを他の装置へ送信する通信方法であって、受信または生成したパケット間に挿入されるデータであるギャップの数および所定データ長の積と、上記ギャップの累積長との差を算出するステップと、上記算出した差に基づいて、新たに挿入すべきギャップのデータ長を決定するステップと、上記パケットおよび対応の上記ギャップの組のデータ長を示す情報と、上記組のギャップのデータ長が決定されたときに用いられた上記差とを含むコードベクタテーブルを生成するステップと、上記コードベクタテーブルに基づいて、送信すべき１または複数の上記組のデータ長の総和を上記他の装置に通知するためのレポートを生成すること、およびデータ長の総和が上記他の装置から通知された最大送信許可量以下になるように、１または複数の上記組を送信すべきデータとして選択すること、の少なくとも一方を行なうステップとを含み、上記データ長の通知および上記組の選択の少なくとも一方を行なうステップにおいては、上記他の装置へ送信すべき複数のパケットのうち、先頭のパケットに対応する上記ギャップのデータ長が決定されたときに用いられた上記差と、最後尾のパケットに対応する上記ギャップのデータ長が決定されたときに用いられた上記差とに基づいて、上記他の装置に通知するデータ長の総和の補正、および上記最大送信許可量との比較に用いる上記組のデータ長の総和の補正の少なくとも一方を行なう。
【発明の効果】
【００１７】
本発明によれば、可変長のギャップに対応することにより、通信効率の低下を防ぐことができる。
【図面の簡単な説明】
【００１８】
【図１】本発明の第１の実施の形態に係るＰＯＮシステムの概略構成を示すブロック図である。
【図２】本発明の第１の実施の形態に係るＰＯＮシステムの動作手順を説明するためのシーケンス図である。
【図３】本発明の第１の実施の形態に係るＯＮＵの概略構成を示すブロック図である。
【図４】ＯＮＵがＯＬＴからのグラントフレームに基づいてデータフレームおよびＩＦＧをＯＬＴへ送信する際の動作手順を定めたフローチャートである。
【図５】（ａ）は、１ギガビットイーサネット（登録商標）ＰＯＮ規格に従うフレームの構成を示す図である。（ｂ）は、１０ギガビットイーサネット（登録商標）ＰＯＮ規格に従うフレームの構成を示す図である。
【図６】ＯＮＵがコードベクタテーブルを更新する際の動作手順を定めたフローチャートである。
【図７】制御フレーム処理部２３によるＩＦＧ長の算出方法を示す図である。
【図８】本発明の第１の実施の形態に係るＯＮＵにおけるＩＦＧ長およびＩＦＧクレジットの算出方法を示す図である。
【図９】本発明の第１の実施の形態に係るＯＮＵにおけるＩＦＧ長およびＩＦＧクレジットの算出の具体例を示す図である。
【図１０】ＩＦＧ長が固定であると仮定した場合のコードベクタの一例を示す図である。
【図１１】図１０に示す例においてＯＬＴに報告される送信要求量を示す図である。
【図１２】本発明の第１の実施の形態に係るコードベクタの一例を示す図である。
【図１３】図１２に示す例においてＯＬＴに報告される送信要求量を示す図である。
【図１４】ＯＮＵがパケット３を最初に受信してパケット３からパケット７をＯＬＴへ送信したと仮定した場合における、制御フレーム処理部２３によるＩＦＧクレジットおよびＩＦＧ長の算出の具体例を示す図である。
【図１５】制御フレーム処理部２３がＩＦＧクレジットを用いて送信要求量の補正を行なう際の動作手順を定めたフローチャートである。
【図１６】図４に示すフローチャートにおけるステップＳ２２の詳細な動作手順を定めたフローチャートである。
【図１７】図４に示すフローチャートにおけるステップＳ２４の詳細な動作手順を定めたフローチャートである。
【図１８】複数のキューを扱う場合における図４に示すフローチャートのステップＳ２２の詳細な動作手順を定めたフローチャートである。
【図１９】複数のキューを扱う場合における図４に示すフローチャートのステップＳ２４の詳細な動作手順を定めたフローチャートである。
【図２０】図４に示すフローチャートにおけるステップＳ２２の詳細な動作手順を定めたフローチャートである。
【図２１】本発明の第２の実施の形態に係るＰＯＮシステムにおけるＯＮＵからＯＬＴへのフレームおよびＩＦＧの送信動作を示す図である。
【図２２】ＯＮＵのレポートおよびＯＬＴのグラントの具体例を示す図である。
【図２３】ヘッダが２０バイトの固定長である場合および可変長である場合のＯＮＵのレポート内容の一例を示す図である。
【図２４】図４に示すフローチャートにおけるステップＳ２４の詳細な動作手順を定めたフローチャートである。
【図２５】図４に示すフローチャートにおけるステップＳ２２の詳細な動作手順を定めたフローチャートである。
【図２６】ＩＦＧ、フレームおよび終了コードの構成の一例を示す図である。
【図２７】図４に示すフローチャートにおけるステップＳ２４の詳細な動作手順を定めたフローチャートである。
【図２８】図４に示すフローチャートにおけるステップＳ２２の詳細な動作手順を定めたフローチャートである。
【図２９】ＯＮＵがＯＬＴからのグラントフレームに基づいてデータフレームおよびＩＦＧをＯＬＴへ送信する際の動作手順を定めたフローチャートである。
【発明を実施するための形態】
【００１９】
以下、本発明の実施の形態について図面を用いて説明する。なお、図中同一または相当部分には同一符号を付してその説明は繰り返さない。
【００２０】
＜第１の実施の形態＞
図１は、本発明の第１の実施の形態に係るＰＯＮシステムの概略構成を示すブロック図である。
【００２１】
図１を参照して、ＰＯＮシステム３０１は、主に電話局などに設置されるＯＬＴ１０１と、主に各宅内に設置される複数のＯＮＵ１０２−１〜１０２−ｎと、ＯＬＴ１０１から送信される光信号を分岐してＯＮＵ１０２−１〜１０２−ｎに送信し、ＯＮＵ１０２−１〜１０２−ｎから送信される光信号を集束してＯＬＴ１０１に送信するスプリッタ１０５と、ＯＮＵ１０２−１〜１０２−ｎのそれぞれに接続されるユーザ端末１１１とを備える。なお、第１のＯＮＵ１０２−１〜第ｎのＯＮＵ１０２−ｎは、それぞれ同じ構成を有している。
【００２２】
ＯＬＴ１０１は、上位ネットワーク１０９を介して受信したデータを、光伝送路１０４およびスプリッタ１０５を介してＯＮＵ１０２−１〜１０２−ｎに送信する。また、ＯＬＴ１０１は、ＯＮＵ１０２−１〜１０２−ｎから送信されたレポート１０７に基づいて、ＯＮＵ１０２−１〜１０２−ｎ内のバッファ１０３−１〜１０３−ｎに蓄積されているデータの送信開始時刻および送信許可量を演算し、指示信号を挿入したグラント１０６を光伝送路１０４およびスプリッタ１０５を介してＯＮＵ１０２−１〜１０２−ｎに送信する。
【００２３】
たとえば、ＯＮＵ１０２−１が下位ネットワーク１１０を介してユーザ端末１１１から上り情報フレーム１０８を受信すると、この上り情報フレーム１０８を一旦バッファ１０３−１に蓄積する。ＯＮＵ１０２−１は、ＯＬＴ１０１からグラント１０６を受信すると、そのグラント１０６によって指定された時刻にバッファ１０３−１内のデータの長さを
レポート１０７でＯＬＴ１０１に通知する。なお、上り情報フレーム１０８は、可変長のパケットである。
【００２４】
ＯＮＵ１０２−１は、指示信号が挿入されたグラント１０６をＯＬＴ１０１から受信すると、その指示信号に基づいてバッファ１０３−１内のデータをレポート１０７とともにＯＬＴ１０１に送信する。
【００２５】
図２は、本発明の第１の実施の形態に係るＰＯＮシステムの動作手順を説明するためのシーケンス図である。なお、このシーケンス図は、ＯＬＴ１０１と、ＯＮＵ１０２−１と、ユーザ端末１１１との動作について代表的に示しているが、他のＯＮＵ１０２−２〜１０２−ｎの動作についても同様である。
【００２６】
図２を参照して、運用時間開始時刻Ｔ０において、ＯＬＴ１０１は、ＯＮＵ１０２−１〜１０２−ｎに関するＲＴＴ（Round Trip Time）を既に計算している。
【００２７】
時刻Ｔｂ０において、ＯＮＵ１０２−１は、ユーザ端末１１１から上り情報フレーム１０８を受信すると、この上り情報フレーム１０８を一旦バッファ１０３−１に蓄積する。また、ＯＮＵ１０２−１は、後述するコードベクタテーブルを作成する。
【００２８】
時刻Ｔａ１において、ＯＬＴ１０１は、送信要求量を通知させるために、ＯＮＵ１０２−１に対してレポート送信開始時刻Ｔｂ２を含んだグラント１２１を送信する。このレポート送信開始時刻Ｔｂ２は、他のＯＮＵから送信されるレポートと衝突しないように計算される。
【００２９】
ＯＮＵ１０２−１は、自身に対するグラント１２１を受信すると、コードベクタテーブルを参照することによりバッファ１０３−１に蓄積されたデータの長さを得て送信要求量を算出し、グラント１２１に含まれるレポート送信開始時刻Ｔｂ２に、ＯＬＴ１０１に対して送信要求量を含んだレポート１２２を送信する。
【００３０】
ＯＬＴ１０１は、レポート１２２を受信すると、固定または可変の最大送信許可量以下となり、かつレポート１２２に含まれる送信要求量になるべく近い値を送信許可量としてグラント１２３に挿入する。レポート１２２に含まれる送信要求量がゼロの場合には、ＯＬＴ１０１による演算結果がゼロとなるため帯域が割り当てられない。しかしながら、ＯＮＵ１０２−１にレポートを送信させる必要があるので、ＯＬＴ１０１はＯＮＵ１０２−１に対して必ずグラント１２３を送信する。
【００３１】
グラント１２３に含まれる送信開始時刻Ｔｂ４は、演算済みである前回のＯＮＵデータの受信予定時刻、前回のＯＮＵの送信許可量、現在のＯＮＵに対応するＲＴＴおよび固定時間であるガードタイムを用い、データおよびレポートが他のＯＮＵからのデータまたはレポートと衝突しないように計算される。なお、ＯＬＴ１０１は、送信許可量および送信開始時刻Ｔｂ４を含むグラント１２３を送信する時刻Ｔａ３を、グラント１２３が送信開始時刻Ｔｂ４までにＯＮＵ１０２−１に到着するように計算する。
【００３２】
ＯＮＵ１０２−１は、自身に対するグラント１２３を受信すると、グラント１２３に含まれる送信開始時刻Ｔｂ４に、送信許可量分のデータ１２４を、次回の送信要求量を含んだレポート１２４とともにＯＬＴ１０１に送信する。このレポートはデータの直前または直後に送信されるが、データの直前に送信される場合には、送信要求量としてＯＬＴ１０１に報告する値は、バッファ１０３−１に蓄積されているデータの長さとデータ１２４のデータ長との差分である。
【００３３】
ここで、ＯＮＵ１０２−１は、データ１２４に対応する情報をコードベクタテーブルから消去する。
【００３４】
ＯＬＴ１０１はデータおよびレポート１２４を受信すると、データを上位ネットワーク１０９に送信し、レポートについてはレポート１２２に対する処理と同様の処理を行なう。以上説明した処理は、すべてのＯＮＵ１０２−１〜１０２−ｎに対して独立に行なわれ、運用時間が終了するまで時刻Ｔａ３〜時刻Ｔａ４の処理が繰り返される。
【００３５】
図３は、本発明の第１の実施の形態に係るＯＮＵの概略構成を示すブロック図である。
図３を参照して、ＯＮＵ１０２は、受信部２１と、送信部２２と、制御フレーム処理部（制御部およびテーブル生成部）２３と、受信部２４と、バッファメモリ２５と、送信部２６と、カウンタ２７と、バッファメモリ２８とを含む。
【００３６】
受信部２１は、ＯＬＴからの光信号を受信してデータフレームおよびグラントフレームを出力する。バッファメモリ２８は、受信部２１から受けたデータフレームを蓄積する。送信部２２は、バッファメモリ２８に蓄積されたデータフレームをユーザ側の端末に送信する。制御フレーム処理部２３は、受信部２１から受けたグラントフレームに基づいてレポートフレームを生成し、また、ユーザ側の端末から受信したデータフレームの送信制御を行なう。
【００３７】
受信部２４は、ユーザ側の端末からの上り情報フレームを受信する。バッファメモリ２５は、受信部２４によって受信された上り情報フレームすなわちデータフレームと、制御フレーム処理部２３によって生成された制御フレームとを蓄積する。送信部２６は、制御フレーム処理部２３の制御に基づいて、バッファメモリ２５に蓄積されたフレームをＯＬＴに送信する。カウンタ２７は、受信部２４によって受信された各データフレームの長さをカウントする。
【００３８】
受信部２１は、ＯＬＴからの光信号を受信し、フレームのヘッダ部分を読み取ることによって当該フレームが自身宛てであるか否かを判定する。受信部２１は、受信したフレームが自身宛てであれば当該フレームを取り込み、他のＯＮＵ宛てまたは他のＯＮＵに接続される装置宛てであれば当該フレームを廃棄する。また、受信部２１は、取込んだフレームのヘッダ部分によってデータフレームであるか、グラントフレームなどの制御フレームであるかを判定する。受信したフレームがデータフレームであれば、受信部２１は当該データフレームをバッファメモリ２８経由で送信部２２に転送する。また、受信したフレームが制御フレームであれば、受信部２１はこの制御フレームを制御フレーム処理部２３に転送する。
【００３９】
送信部２２は、受信部２１からデータフレームを受けると、このデータフレームをユーザ側の端末等が接続されるリンクへ送信する。
【００４０】
制御フレーム処理部２３は、カウンタ２７から転送されるデータフレームの長さ等を記憶するコードベクタテーブル２９を作成し、送信要求量の演算および上り制御フレームの作成を行なう。制御フレーム処理部２３は、受信部２１からグラントフレームを受けると、後述する処理によってレポートフレームを作成してバッファメモリ２５に転送する。また、制御フレーム処理部２３は、バッファメモリ２５に蓄積されているレポートフレームの送信制御も行なう。また、制御フレーム処理部２３は、ＯＬＴからのグラントフレーム以外の制御フレームの処理も実行してバッファメモリ２５に蓄積し、この制御フレームの送信制御も行なう。
【００４１】
受信部２４は、ユーザ側の端末（リンク）からのフレームを受信し、バッファメモリ２５に転送する。バッファメモリ２５は、制御フレーム処理部２３および受信部２４からそれぞれ転送された制御フレームおよびデータフレームをフレーム種類毎に一旦キューに蓄積する。
【００４２】
カウンタ２７は、受信部２４によって受信されたデータフレームの長さをカウントし、各データフレームの長さを制御フレーム処理部２３に通知する。
【００４３】
制御フレーム処理部２３は、カウンタ２７から通知されたデータフレームの長さに基づいて、受信部２４によって受信された各データフレーム間に挿入すべきギャップ（以下、ＩＦＧとも称する）の長さを決定する。また、制御フレーム処理部２３は、カウンタ２７から通知されたデータフレームの長さと、ＩＦＧ長とに基づいて、コードベクタテーブル２９を作成する。
【００４４】
また、制御フレーム処理部２３は、生成した制御フレームの長さに基づいて、各制御フレーム間に挿入すべきＩＦＧの長さを決定する。また、制御フレーム処理部２３は、制御フレームの長さと、ＩＦＧ長とに基づいて、コードベクタテーブル２９を作成する。
【００４５】
ここで、ＩＦＧは、ＯＬＴが各フレームを受信するために必要なフレーム間隔を得るための空白データであるが、この空白データの他にたとえばイーサネット（登録商標）規格に従うパケットの識別子が含まれている。また、ＩＦＧには、さらに、他の制御情報が含まれる場合がある。なお、レベル情報等、ＯＮＵおよびＯＬＴが直接使用する制御情報は、フレームに含まれている。
【００４６】
制御フレーム処理部２３は、バッファメモリ２５におけるキューに蓄積されたフレームを送信部２６に転送する。送信部２６は、制御フレーム処理部２３から通知されたＩＦＧ長に基づいてＩＦＧを生成し、バッファメモリ２５から転送されたフレームの間にＩＦＧを挿入してＯＬＴへ送信する。
【００４７】
以下では、データフレーム間に挿入されるＩＦＧについて代表的に説明を行なう。なお、制御フレーム間に挿入されるＩＦＧについても、本発明を適用することが可能である。
【００４８】
図４は、ＯＮＵがＯＬＴからのグラントフレームに基づいてデータフレームおよびＩＦＧをＯＬＴへ送信する際の動作手順を定めたフローチャートである。
【００４９】
図４を参照して、まず、制御フレーム処理部２３は、受信部２１によって受信されたＯＬＴからのグラントフレームを受ける（Ｓ２１）。
【００５０】
次に、制御フレーム処理部２３は、コードベクタテーブルを参照し、グラントフレームに含まれる送信許可量以下で送信可能なデータフレームおよび対応のＩＦＧを検索し、ＯＬＴへ送信すべきデータとして選択する（Ｓ２２）。
【００５１】
次に、制御フレーム処理部２３は、選択したデータフレームおよび対応のＩＦＧに基づいてコードベクタテーブルの内容を更新する。より詳細には、制御フレーム処理部２３は、未選択のデータフレームおよび対応のＩＦＧを示すポインタを更新する（Ｓ２３）。
【００５２】
次に、制御フレーム処理部２３は、コードベクタテーブルを参照し、データ長が予めＯＮＵに設定されているクレジット（以下、最大レポート量とも称する）以下となるように、送信すべきデータフレームおよび対応のＩＦＧを検索し、検索したデータフレームおよび対応のＩＦＧのデータ長の総和を送信要求量とする（Ｓ２４）。
【００５３】
次に、制御フレーム処理部２３は、検索結果に基づいてコードベクタテーブルの内容を更新する。より詳細には、制御フレーム処理部２３は、ＯＬＴへ送信要求していないデータフレームおよび対応のＩＦＧを示すポインタを更新する（Ｓ２８）。
【００５４】
次に、制御フレーム処理部２３は、送信元アドレス（当該ＯＮＵのアドレス）、送信先アドレス（ＯＬＴのアドレス）および送信要求量によって構成されるレポートフレームを作成し、バッファメモリ２５に転送する（Ｓ２５）。
【００５５】
次に、制御フレーム処理部２３は、グラントフレームに含まれる送信開始時刻に、レポートフレームならびに選択したデータフレームおよびＩＦＧの送信をバッファメモリ２５および送信部２６に指示する（Ｓ２６）。
【００５６】
送信部２６は、制御フレーム処理部２３からの指示に基づいてＩＦＧを生成し、バッファメモリ２５から転送されたデータフレームの間に挿入してＯＬＴへ送信する。ここで、送信部２６は、後述する図８に示すＩＦＧ長およびＩＦＧクレジットの算出方法に従い、ＩＦＧ長の決定およびＩＦＧの生成を行なう（Ｓ２７）。
【００５７】
図５（ａ）は、１ギガビットイーサネット（登録商標）ＰＯＮ規格に従うフレームの構成を示す図である。図５（ｂ）は、１０ギガビットイーサネット（登録商標）ＰＯＮ規格に従うフレームの構成を示す図である。
【００５８】
図５（ａ）を参照して、１ギガビットイーサネット（登録商標）ＰＯＮ規格では、ＩＦＧは２０バイトの固定長に設定される。
【００５９】
図５（ｂ）を参照して、１０ギガビットイーサネット（登録商標）ＰＯＮ規格では、ＩＦＧは１７バイト〜２３バイトの可変長である。なお、ＯＮＵが送信するデータの先頭フレームの前に挿入されるＩＦＧは２０バイトの固定長である。
【００６０】
また、１０ギガビットイーサネット（登録商標）ＰＯＮ規格では、ＯＮＵ−ＯＬＴ間の伝送において、誤り訂正方式としてＦＥＣ（Forward Error Correction）が行なわれる。すなわち、ＩＦＧおよびパケットの区切りに関わらず、ＩＦＧおよびパケットの２１６バイトごとに３２バイトのＦＥＣパリティが挿入される。図５（ｂ）に示す例では、パケット１および２の途中にＦＥＣパリティがそれぞれ挿入されている。
【００６１】
また、１ギガビットイーサネット（登録商標）ＰＯＮ規格では、ＯＬＴへのレポートに含まれる送信要求量の単位は２バイトである。
【００６２】
一方、１０ギガビットイーサネット（登録商標）ＰＯＮ規格では、ＯＬＴへのレポートに含まれる送信要求量の単位は２０バイトである。
【００６３】
たとえば、パケット長が６４バイトであり、このパケットに対応するＩＦＧの長さが２０バイトの場合、１ギガビットイーサネット（登録商標）ＰＯＮ規格ではＯＬＴへの報告数が４２となり、１０ギガビットイーサネット（登録商標）ＰＯＮ規格ではＯＬＴへの報告数が５となる。
【００６４】
このため、たとえばＯＮＵが送信するデータの長さが１０１バイトの場合には、１９バイト分の帯域がＰＯＮシステム３０１において無駄に消費されてしまう。
【００６５】
さらに、１０ギガビットイーサネット（登録商標）ＰＯＮ規格では、上記のようにＦＥＣを採用しているため、ＯＮＵからはＦＥＣフレーム単位でデータを送信する必要がある。このため、たとえばＩＦＧおよびパケットのデータ長が２１７バイトの場合には、２１５バイト＋３２バイト＝２４７バイト分の帯域がＰＯＮシステム３０１において無駄に消費されてしまう。
【００６６】
図６は、ＯＮＵがコードベクタテーブルを更新する際の動作手順を定めたフローチャートである。
【００６７】
図６を参照して、受信部２４は、ユーザ端末１１１からデータフレームを受信する（Ｓ１）。
【００６８】
次に、制御フレーム処理部２３は、カウンタ２７から通知されたデータフレームの長さおよび現在のＩＦＧクレジットに基づいて、新たに挿入すべきＩＦＧの長さおよび新たなＩＦＧクレジットを決定する（Ｓ２）。なお、ＩＦＧクレジットについては後述する。
【００６９】
図７は、制御フレーム処理部２３によるＩＦＧ長の算出方法を示す図である。
制御フレーム処理部２３は、運用開始時刻Ｔ０から現在までに生成したＩＦＧの長さの平均（以下、ＩＦＧ平均長とも称する。）が２０バイトを超えないように、新たなＩＦＧの長さを決定する。これにより、ＯＬＴが行なうデータ受信処理においてオーバーフローが起こることを防ぐ。
【００７０】
１０ギガビットイーサネット（登録商標）ＰＯＮ規格におけるＯＬＴでは、ＯＮＵから受信した光信号を電気信号に変換した後、この電気信号を低速な周波数で扱うためにパラレル処理する。このため、ＯＮＵでは、パケットおよびＩＦＧの組のデータ長がたとえば１ワード＝４バイト単位になるように、ＩＦＧを生成する。すなわち、ＯＮＵは、たとえば１ワード＝４バイト単位のデータをＯＬＴへ送信する。この場合、ＩＦＧは１７〜２３バイトの可変長となる。
【００７１】
図７を参照して、四角で囲まれたＤおよびＩがそれぞれ１バイトのパケットおよび１バイトのＩＦＧを示している。また、”０”〜”３”は、データの順番を示している。パケットは、必ず”０”に対応する位置から始まる、すなわち”０”に対応する行にパケットの先頭が置かれる。○で囲まれたＤが、パケットの先頭である。
【００７２】
図７に示す例では、ユーザ端末１１１から受信したパケットは１９バイトである。制御フレーム処理部２３は、ＩＦＧ平均長が２０バイトである場合には、このパケットに付加するＩＦＧの長さを１７バイトに設定する。一方、ＩＦＧ平均長が２０バイト未満である場合には、ＩＦＧの長さを２１バイトに設定する。
【００７３】
上記のような処理を行なうために、制御フレーム処理部２３は、ＩＦＧクレジットという変数を用いる。ＩＦＧクレジットは、以下の式で表わされる。
【００７４】
ＩＦＧクレジット＝運用開始時刻Ｔ０から現在までに受信されたパケット間に挿入されるＩＦＧの数×２０バイト−運用開始時刻Ｔ０から現在までに受信されたパケット間に挿入されるＩＦＧの累積長
ＯＮＵ１０２では、ＩＦＧ平均長が２０バイトを超えないように、新たなＩＦＧの長さが決定され、かつ１ワード＝４バイト単位のデータをＯＮＵ１０２が送信することから、ＩＦＧクレジットの範囲は−３〜０となる。
【００７５】
ＩＦＧクレジットが０のときは、ＩＦＧ平均長が２０バイトである。また、たとえばＩＦＧクレジットが−１のときは、ＩＦＧの累積長が、ＩＦＧ平均長＝２０バイトのときよりも１バイト少ない。
【００７６】
図８は、本発明の第１の実施の形態に係るＯＮＵにおけるＩＦＧ長およびＩＦＧクレジットの算出方法を示す図である。
【００７７】
図８を参照して、制御フレーム処理部２３は、受信されたパケットのデータ長の４の剰余と、現在のＩＦＧクレジットとに基づいて、ＩＦＧ長および新たなＩＦＧクレジットを決定する。
【００７８】
図９は、本発明の第１の実施の形態に係るＯＮＵにおけるＩＦＧ長およびＩＦＧクレジットの算出の具体例を示す図である。
【００７９】
図９を参照して、運用開始時刻Ｔ０において、ＩＦＧクレジットは初期値である０に設定されている。最初にＯＮＵが受信したパケット１のデータ長は６６バイトである。パケット１の前に挿入されるＩＦＧの長さは２０バイトの固定長に設定される。このとき、パケット１の後ろに挿入されるＩＦＧの長さは１８バイトに設定され、ＩＦＧクレジットは−２に更新される。次にＯＮＵが受信したパケット２のデータ長は６５バイトである。このとき、パケット２の後ろに挿入されるＩＦＧの長さは１９バイトに設定され、ＩＦＧクレジットは−３に更新される。次にＯＮＵが受信したパケット３のデータ長は６５バイトである。このとき、パケット３の後ろに挿入されるＩＦＧの長さは２３バイトに設定され、ＩＦＧクレジットは０に更新される。次にＯＮＵが受信したパケット４のデータ長は６５バイトである。このとき、パケット４の後ろに挿入されるＩＦＧの長さは１９バイトに設定され、ＩＦＧクレジットは−１に更新される。次にＯＮＵが受信したパケット５のデータ長は６６バイトである。このとき、パケット５の後ろに挿入されるＩＦＧの長さは１８バイトに設定され、ＩＦＧクレジットは−３に更新される。次にＯＮＵが受信したパケット６のデータ長は６７バイトである。このとき、パケット６の後ろに挿入されるＩＦＧの長さは２１バイトに設定され、ＩＦＧクレジットは−２に更新される。
【００８０】
再び図６を参照して、制御フレーム処理部２３は、算出したＩＦＧ長と、受信されたパケットのデータ長とに基づいて、コードベクタのエンドフラグ位置およびエンドポイントを算出する（Ｓ３）。
【００８１】
次に、制御フレーム処理部２３は、エンドフラグ、エンドポイントおよびＩＦＧクレジットをコードベクタテーブル２９に書き込み、コードベクタテーブル２９を更新する（Ｓ４）。
【００８２】
図１０は、ＩＦＧ長が固定であると仮定した場合のコードベクタの一例を示す図である。図１１は、図１０に示す例においてＯＬＴに報告される送信要求量を示す図である。図１０において、コードベクタにおける１つのアドレスは６４バイトに対応している。また、エンドフラグが設定されたアドレスに書き込まれたエンドポイントの値がパケットの終点を示す。たとえば、アドレス０にはエンドフラグが設定されていないのでアドレス０にパケットの終点は存在しない。一方、アドレス１にエンドフラグが設定されており、エンドポイントとして３９が書き込まれているので、アドレス１の６４×１＋３９＝１０３バイト目に、パケットの終点がある。
【００８３】
図１０を参照して、運用開始時刻Ｔ０から、８３バイト、１５０バイトおよび１４０バイトの３つのパケットＡ，Ｂ，Ｃをこの順番にＯＮＵがユーザ端末１１１から受信した場合を考える。
【００８４】
パケットＡについては、ＯＬＴへの８３バイトのパケットの送信前に２０バイトのＩＦＧが送信されることから、アドレス１番地にエンドフラグが書き込まれ、エンドポイントは３９が書き込まれる。
【００８５】
パケットＡの次の領域すなわちアドレス１番地の４０バイト目から２０バイトのＩＦＧが保存され、その次にパケットＢが保存される。すなわち、２０バイトのＩＦＧおよび１５０バイトのパケットが保存されることから、アドレス４番地にエンドフラグが書き込まれ、エンドポイントは１７が書き込まれる。
【００８６】
パケットＢの次の領域すなわちアドレス４番地の１８バイト目から２０バイトのＩＦＧが保存され、その次にパケットＣが保存される。すなわち、２０バイトのＩＦＧおよび１４０バイトのパケットが保存されることから、アドレス６番地にエンドフラグが書き込まれ、エンドポイントは４９が書き込まれる。
【００８７】
図１１を参照して、パケットＡ，Ｂ，ＣをＯＮＵからＯＬＴへ送信する場合、ＩＦＧを含めたデータ長は４３３バイトになる。４３３バイト＝（２１６×２＋１）バイトであることから、ＦＥＣフレーム３つ分をＯＬＴへ送信する必要が生じる。すなわち、（２１６＋３２）×３＝７４４バイトのデータを送信するための帯域（グラント）がＰＯＮシステムにおいて必要になってしまう。
【００８８】
図１２は、本発明の第１の実施の形態に係るコードベクタの一例を示す図である。図１３は、図１２に示す例においてＯＬＴに報告される送信要求量を示す図である。図１２において、コードベクタにおける１つのアドレスは６４バイトに対応している。
【００８９】
図１２を参照して、図１０と同様に、運用開始時刻Ｔ０から、８３バイト、１５０バイトおよび１４０バイトの３つのパケットＡ，Ｂ，Ｃをこの順番にＯＮＵが受信した場合を考える。
【００９０】
まず、ＯＮＵが送信するデータの先頭のＩＦＧは２０バイト固定長に設定されることから、パケットＡの送信前に２０バイト固定長のＩＦＧが送信される。また、ＩＦＧクレジットの初期値は０に設定される。
【００９１】
パケットＡについては、８３バイトのパケットの送信前に２０バイトのＩＦＧが送信されることから、アドレス１番地にエンドフラグが書き込まれ、エンドポイントは３９が書き込まれる。また、ＩＦＧクレジットとして初期値の０が書き込まれる。
【００９２】
そして、ＩＦＧクレジットが０のときに８３バイトのパケットを送信することから、図８に従い、新たなＩＦＧクレジットが−３に設定され、パケットＡの後に付加すべきＩＦＧの長さは１７バイトに設定される。パケットＡの次の領域すなわちアドレス１番地の４０バイト目から１７バイトのＩＦＧが保存され、その次にパケットＢが保存される。すなわち、１７バイトのＩＦＧおよび１５０バイトのパケットが保存されることから、アドレス４番地にエンドフラグが書き込まれ、エンドポイントは１４が書き込まれる。また、ＩＦＧクレジットとして−３が書き込まれる。
【００９３】
そして、ＩＦＧクレジットが−３のときに１５０バイトのパケットを送信することから、新たなＩＦＧクレジットが−１に設定され、パケットＢの後に付加すべきＩＦＧの長さは２２バイトに設定される。パケットＢの次の領域すなわちアドレス４番地の１５バイト目から２２バイトのＩＦＧが保存され、その次にパケットＣが保存される。すなわち、２２バイトのＩＦＧおよび１４０バイトのパケットが保存されることから、アドレス６番地にエンドフラグが書き込まれ、エンドポイントは４８が書き込まれる。また、ＩＦＧクレジットとして−１が書き込まれる。
【００９４】
そして、ＩＦＧクレジットが−１のときに１４０バイトのパケットを送信することから、新たなＩＦＧクレジットが−１に設定され、パケットＣの後に付加すべきＩＦＧの長さは２０バイトに設定される。
【００９５】
図１３を参照して、パケットＡ，Ｂ，ＣをＯＮＵからＯＬＴへ送信する場合、２０バイト、１７バイト、２２バイトの３つのＩＦＧを含めたデータ長は４３２バイトになる。４３２バイト＝（２１６×２）バイトであることから、ＦＥＣフレーム２つ分をＯＬＴへ送信すればよい。すなわち、（２１６＋３２）×２＝４９６バイトのデータを送信するための帯域（グラント）がＰＯＮシステムにおいて必要になる。このように、本発明の第１の実施の形態に係るＰＯＮシステムでは、ＰＯＮシステムにおいて必要となる帯域を、図１０および図１１に示す場合と比べて大幅に減らすことができる。
【００９６】
上記では、最初にＯＮＵが受信したパケット１を先頭パケットとしてＯＬＴへ送信する場合について説明した。しかしながら、このようなケースは運用開始時のみであり、その後は、ＯＮＵが最初に受信したパケット１ではなくパケット１より後に受信されたパケットが先頭パケットとなる。この場合、上記説明した方法では、以下のような問題点がある。
【００９７】
ここでは、図９に示す例において、ＯＮＵがパケット３を先頭パケットとし、パケット７を最後尾のパケットとしてＯＬＴへ送信する場合について説明する。
【００９８】
この場合、パケット３の前に挿入されるＩＦＧの長さは固定長の２０バイトであり、これに対応するＩＦＧクレジットは−３である。また、パケット７の前に挿入されるＩＦＧの長さは２１バイトであり、これに対応するＩＦＧクレジットは−２である。
【００９９】
図１４は、ＯＮＵがパケット３を最初に受信してパケット３からパケット７をＯＬＴへ送信したと仮定した場合における、制御フレーム処理部２３によるＩＦＧクレジットおよびＩＦＧ長の算出の具体例を示す図である。
【０１００】
図１４を参照して、ＩＦＧクレジットの初期値は０に設定される。そして、パケット７の前に挿入される１７バイトのＩＦＧに対応するＩＦＧクレジットすなわちパケット６のデータ長から算出されるＩＦＧクレジットは−３である。
【０１０１】
図１４に示すように、パケット３からパケット７をＯＬＴへ送信する場合、実際にはＩＦＧクレジットは０から−３になって３減るべきであるところ、図９に示すように、ＩＦＧクレジットは−３から−２に変化しており、１増えていることが分かる。すなわち、ＩＦＧ平均長が２０を超えてしまっており、誤った送信要求量が算出されてしまう。
【０１０２】
すなわち、制御フレーム処理部２３は、図９に示す表に基づくコードベクタテーブルから送信要求量を算出することから、パケット３からパケット７を送信する場合、送信要求量として（８４＋８８＋８５＋８５＋８６）＝４２８バイトを算出する。
【０１０３】
その一方で、送信部２６は、図８に示すＩＦＧ長およびＩＦＧクレジットの算出方法に従い、図１４で示すようにＩＦＧ長の決定およびＩＦＧの生成を行なうことから、（８５＋８４＋８５＋８９＋８２）＝４２５バイトのデータをＯＬＴへ送信する。
【０１０４】
したがって、ＯＬＴへの送信要求量と実際に送信されるデータの長さとが不一致になってしまう。
【０１０５】
このような問題点を解決するために、制御フレーム処理部２３がコードベクタテーブルにおけるＩＦＧクレジットを書き換える構成が考えられる。しかしながら、このような構成では、コードベクタテーブルを書き換えるために処理時間が増大してしまう。
【０１０６】
そこで、本発明の第１の実施の形態に係るＰＯＮシステムでは、図１２に示すように、コードベクタテーブルにＩＦＧクレジットの項目を設け、パケットごとのＩＦＧクレジットを書き込む。
【０１０７】
図１５は、制御フレーム処理部２３がＩＦＧクレジットを用いて送信要求量の補正を行なう際の動作手順を定めたフローチャートである。
【０１０８】
図１５を参照して、制御フレーム処理部２３は、送信すべき複数のパケットのうち、先頭のパケットがキューの先頭パケットである場合には（Ｓ１１でＹＥＳ）、補正変数Ａ１＝０とする（Ｓ１２）。
【０１０９】
一方、制御フレーム処理部２３は、送信すべき複数のパケットのうち、先頭のパケットがキューの先頭パケットでない場合には（Ｓ１１でＮＯ）、補正変数Ａ１＝２０−（送信すべき先頭パケットのキューにおけるＩＦＧ長）とする（Ｓ１３）。
【０１１０】
前述のように、ＯＮＵが送信するデータの先頭フレームの前に挿入されるＩＦＧは２０バイトの固定長である。このため、送信すべき先頭パケットがキューの先頭パケットではなく、かつ対応のＩＦＧ長が２０バイトではない場合には、実際に送信されるＩＦＧ長と送信要求量の算出で用いられるＩＦＧ長とが一致しなくなる。しかしながら、本発明の第１の実施の形態に係るＯＮＵでは、補正変数Ａ１により、この不一致を防ぐことができる。
【０１１１】
次に、制御フレーム処理部２３は、送信すべき複数のパケットのうち、先頭のパケットに対応するＩＦＧクレジットと最後尾のパケットに対応するＩＦＧクレジットとの差を算出する。すなわち、（送信すべき最後尾のパケットに対応するＩＦＧクレジット−送信すべき先頭のパケットに対応するＩＦＧクレジット）を算出する（Ｓ１４）。
【０１１２】
次に、制御フレーム処理部２３は、算出したＩＦＧクレジットの差が０より大きい場合には（Ｓ１５でＹＥＳ）、補正変数Ａ２＝Ａ１−ＩＦＧクレジットの範囲長とする（Ｓ１６）。
【０１１３】
一方、制御フレーム処理部２３は、算出したＩＦＧクレジットの差が０以下である場合には（Ｓ１５でＮＯ）、補正変数Ａ２＝Ａ１とする（Ｓ１７）。
【０１１４】
そして、制御フレーム処理部２３は、図９に示す表に基づくコードベクタテーブルから算出した送信要求量に補正変数Ａ２を加算することで送信要求量を補正する（Ｓ１８）。
【０１１５】
図９および図１４に示した例では、パケット３はキューの先頭パケットではなく（Ｓ１１でＮＯ）、パケット３に対応するＩＦＧ長は１９バイトであることから、制御フレーム処理部２３は、補正変数Ａ１＝２０−１９＝１とする（Ｓ１３）。
【０１１６】
次に、制御フレーム処理部２３は、ＯＬＴへ送信すべきパケット３〜７のうち、最後尾のパケット７の前に挿入されるＩＦＧのデータ長が決定されたときに用いられたＩＦＧクレジットである−２から、先頭のパケット３の前に挿入されるＩＦＧのデータ長が決定されたときに用いられたＩＦＧクレジットである−３を減算し、＋１を減算結果として得る（Ｓ１４）。
【０１１７】
そして、制御フレーム処理部２３は、減算結果が正であるため（Ｓ１５でＹＥＳ）、補正変数Ａ１からＩＦＧクレジットの範囲長である４を減算し、−３を補正変数Ａ２として得る（Ｓ１６）。
【０１１８】
そして、制御フレーム処理部２３は、送信要求量である４２８バイトに−３である補正変数Ａ２を加算することで送信要求量を４２５バイトに補正する（Ｓ１８）。
【０１１９】
このような構成により、ＯＮＵが受信した複数のパケットのうち、どのパケットから送信するかに関わらず、実際に送信されるデータの長さと、ＯＬＴへ通知する送信要求量とを一致させることができるため、ＯＮＵ−ＯＬＴ間の通信を正しく行ない、通信効率の低下を防ぐことができる。
【０１２０】
なお、制御フレーム処理部２３は、図４を用いて説明したように、グラントフレームに含まれる送信許可量以下で送信可能なデータフレームおよび対応のＩＦＧを検索する。このとき、制御フレーム処理部２３は、データフレームおよび対応のＩＦＧのデータ長の総和を算出し、この総和と送信許可量とを比較する。ここで、制御フレーム処理部２３は、図１５に示す動作手順により、この総和を必要に応じて補正し、補正後の総和と送信許可量とを比較することにより、送信許可量以下で送信可能なデータフレームおよび対応のＩＦＧを検索する。
【０１２１】
このような構成により、ＯＮＵが受信した複数のパケットのうち、どのパケットから送信するかに関わらず、実際に送信されるデータの長さを、ＯＬＴから通知された送信許可量以下とすることができるため、ＯＮＵ−ＯＬＴ間の通信を正しく行ない、通信効率の低下を防ぐことができる。
【０１２２】
図１６は、図４に示すフローチャートにおけるステップＳ２２の詳細な動作手順を定めたフローチャートである。
【０１２３】
キューの先頭パケット以外のパケットを最初に送信する場合において、送信要求量と実際に送信されるデータの長さとが不一致になる問題は、送信許可量以下で送信可能なデータフレームおよび対応のＩＦＧをコードベクタテーブルから検索するときにも考慮する必要がある。
【０１２４】
図９および図１４に示した例では、ＩＦＧ長は１７から２３まで変動し、かつＩＦＧクレジットの差が負の場合にはＩＦＧクレジットの範囲長である４を減算する補正を行なう必要があることから、−７から＋３までの変動範囲に基づいて送信許可量を補正する必要がある。
【０１２５】
すなわち、制御フレーム処理部２３は、送信要求量を４２８バイトから４２５バイトに補正してＯＬＴへ通知し、ＯＬＴからは送信許可量として４２５バイトが通知される。しかしながら、コードベクタテーブルにおいてこの４２５バイトをそのまま使用して検索を行なうと、パケット７すなわち送信すべき最後尾のパケットが検索されなくなってしまう。
【０１２６】
そこで、制御フレーム処理部２３は、以下のように送信許可量を補正する。すなわち、図１６を参照して、制御フレーム処理部２３は、グラントフレームに含まれる送信許可量Ｇを取得する（Ｓ３１）。
【０１２７】
次に、制御フレーム処理部２３は、取得した送信許可量Ｇに７を加える補正を行なう（Ｓ３２）。
【０１２８】
そして、制御フレーム処理部２３は、補正した送信許可量Ｇ以下で送信可能なデータフレームおよび対応のＩＦＧを検索し、ＯＬＴへ送信すべきデータとして選択する（Ｓ３３）。
【０１２９】
このような構成により、ＯＬＴから通知された送信許可量以下で送信可能なデータフレームおよび対応のＩＦＧを正しく検索することができる。
【０１３０】
図１７は、図４に示すフローチャートにおけるステップＳ２４の詳細な動作手順を定めたフローチャートである。
【０１３１】
キューの先頭パケット以外のパケットを最初に送信する場合において、送信要求量と実際に送信されるデータの長さとが不一致になる問題は、データ長が最大レポート量以下となるようにデータフレームおよび対応のＩＦＧを検索するときにも考慮する必要がある。
【０１３２】
図９および図１４に示した例では、ＩＦＧ長は１７から２３まで変動し、かつＩＦＧクレジットの差が負の場合にはＩＦＧクレジットの範囲長である４を減算する補正を行なう必要があることから、−７から＋３までの変動範囲に基づいて最大レポート量を補正する必要がある。
【０１３３】
すなわち、制御フレーム処理部２３は、データ長が最大レポート量以下となるように、送信すべきデータフレームおよび対応のＩＦＧを検索し、検索したデータフレームおよび対応のＩＦＧのデータ長の総和を送信要求量とする。しかしながら、コードベクタテーブルにおいて最大レポート量をそのまま使用して検索を行なうと、レポートすべき最後尾のパケットが検索されなくなってしまう。
【０１３４】
そこで、制御フレーム処理部２３は、以下のように最大レポート量を補正する。すなわち、図１７を参照して、制御フレーム処理部２３は、コードベクタテーブルを参照して、ＯＬＴへレポートしていない、すなわち送信要求していないデータの長さＲを算出する。ここで、制御フレーム処理部２３は、たとえばＯＬＴへレポートした最後のデータの位置を示すリードポインタおよびキューに蓄積された最後のデータの位置を示すライトポインタを用いる等により、データ長Ｒを算出する（Ｓ４１）。
【０１３５】
そして、制御フレーム処理部２３は、データ長Ｒの方が最大レポート量ＲＭより小さい場合には（Ｓ４２でＹＥＳ）、データ長Ｒを送信要求量とする（Ｓ４３）。
【０１３６】
一方、制御フレーム処理部２３は、データ長Ｒの方が最大レポート量ＲＭより大きい場合には（Ｓ４２でＮＯ）、最大レポート量ＲＭに７を加える補正を行なう（Ｓ４４）。
【０１３７】
そして、制御フレーム処理部２３は、データ長が最大レポート量ＲＭ以下となるように、送信すべきデータフレームおよび対応のＩＦＧを検索し、検索したデータフレームおよび対応のＩＦＧのデータ長の総和を送信要求量とする（Ｓ４５）。
【０１３８】
次に、制御フレーム処理部２３は、図１５に示した送信要求量の補正を行なう（Ｓ４６）。
【０１３９】
このような構成により、データ長が最大レポート量以下となるようにデータフレームおよび対応のＩＦＧを正しく検索することができる。
【０１４０】
次に、本発明の第１の実施の形態に係るＯＮＵが複数のキューを跨いで各種演算およびデータ送信を行なう際の動作について図面を用いて説明する。
【０１４１】
図１８は、複数のキューを扱う場合における図４に示すフローチャートのステップＳ２２の詳細な動作手順を定めたフローチャートである。
【０１４２】
図１８を参照して、制御フレーム処理部２３は、優先度の一番高いキューを最初に選択する（Ｓ５２）。
【０１４３】
次に、制御フレーム処理部２３は、コードベクタテーブルを参照して、選択キューにおけるデータの長さＱＬＥＮを算出する（Ｓ５３）。
【０１４４】
そして、制御フレーム処理部２３は、データ長ＱＬＥＮの方が送信許可量Ｇより大きい場合には（Ｓ５４でＹＥＳ）、送信許可量Ｇに７を加える補正を行なう（Ｓ５５）。
【０１４５】
そして、制御フレーム処理部２３は、補正した送信許可量Ｇ以下で送信可能なデータフレームおよび対応のＩＦＧを検索し、ＯＬＴへ送信すべきデータとして選択する（Ｓ５６）。
【０１４６】
一方、制御フレーム処理部２３は、データ長ＱＬＥＮの方が送信許可量Ｇより小さい場合には（Ｓ５４でＮＯ）、図１５に示した送信要求量の補正と同様の補正をデータ長ＱＬＥＮに対して行なう（Ｓ５７）。
【０１４７】
そして、制御フレーム処理部２３は、送信許可量Ｇから補正後のデータ長ＱＬＥＮを減じた値を新たに送信許可量Ｇとする（Ｓ５８）。
【０１４８】
次に、制御フレーム処理部２３は、今回の送信許可量に対する検索において未選択のキューが存在する場合には（Ｓ５１でＹＥＳ）、未選択のキューの中で優先度の一番高いキューを選択し、ステップＳ５２以降の処理を繰り返す。
【０１４９】
そして、制御フレーム処理部２３は、今回の送信許可量に対する検索において未選択のキューが存在しなくなると（Ｓ５１でＮＯ）、選択したデータフレームおよび対応のＩＦＧに基づいてコードベクタテーブルの内容を更新する（Ｓ２３）。
【０１５０】
ここで、具体例として、優先度の高い順にキュー１、キュー２、キュー３が少なくとも存在する場合について説明する。キュー１〜３の各々のデータ長すなわち図１５に示す補正処理前のデータ長は２００バイトである。そして、キュー１〜３の実際に送信する際のデータ長すなわち図１５に示す補正処理後のデータ長はそれぞれ１９７バイト、２０２バイト、１９５バイトである。また、ＯＬＴから送信許可量として５９０バイトが通知されたと仮定する。
【０１５１】
まず、制御フレーム処理部２３は、優先度の一番高いキュー１を最初に選択する（Ｓ５２）。
【０１５２】
次に、制御フレーム処理部２３は、コードベクタテーブルを参照して、選択したキュー１において、ＯＬＴへレポートしていない、すなわち送信要求していないデータの長さＱＬＥＮ＝２００バイトを算出する（Ｓ５３）。
【０１５３】
次に、制御フレーム処理部２３は、データ長ＱＬＥＮ＝２００バイトの方が送信許可量Ｇ＝５９０バイトより小さいことから（Ｓ５４でＮＯ）、図１５に示した送信要求量の補正と同様の補正をデータ長ＱＬＥＮに対して行ない、データ長ＱＬＥＮを１９７バイトに補正する（Ｓ５７）。
【０１５４】
そして、制御フレーム処理部２３は、送信許可量Ｇ＝５９０バイトから補正後のデータ長ＱＬＥＮ＝１９７バイトを減じた３９３バイトを新たに送信許可量Ｇとする（Ｓ５８）。
【０１５５】
次に、制御フレーム処理部２３は、未選択のキューの中で優先度の一番高いキュー２を選択する（Ｓ５２）。
【０１５６】
次に、制御フレーム処理部２３は、コードベクタテーブルを参照して、選択したキュー２において、ＯＬＴへレポートしていない、すなわち送信要求していないデータの長さＱＬＥＮ＝２００バイトを算出する（Ｓ５３）。
【０１５７】
次に、制御フレーム処理部２３は、データ長ＱＬＥＮ＝２００バイトの方が送信許可量Ｇ＝３９３バイトより小さいことから（Ｓ５４でＮＯ）、図１５に示した送信要求量の補正と同様の補正をデータ長ＱＬＥＮに対して行ない、データ長ＱＬＥＮを２０２バイトに補正する（Ｓ５７）。
【０１５８】
そして、制御フレーム処理部２３は、送信許可量Ｇ＝３９３バイトから補正後のデータ長ＱＬＥＮ＝２０２バイトを減じた１９１バイトを新たに送信許可量Ｇとする（Ｓ５８）。
【０１５９】
次に、制御フレーム処理部２３は、未選択のキューの中で優先度の一番高いキュー３を選択する。
【０１６０】
次に、制御フレーム処理部２３は、コードベクタテーブルを参照して、選択したキュー２において、ＯＬＴへレポートしていない、すなわち送信要求していないデータの長さＱＬＥＮ＝２００バイトを算出する（Ｓ５３）。
【０１６１】
そして、制御フレーム処理部２３は、データ長ＱＬＥＮ＝２００バイトの方が送信許可量Ｇ＝１９１バイトより大きいことから（Ｓ５４でＹＥＳ）、送信許可量Ｇに７を加えて１９８バイトとする補正を行なう（Ｓ５５）。
【０１６２】
そして、制御フレーム処理部２３は、補正した送信許可量Ｇ＝１９８バイト以下で送信可能なデータフレームおよび対応のＩＦＧを検索し、ＯＬＴへ送信すべきデータとして選択する（Ｓ５６）。
【０１６３】
図１９は、複数のキューを扱う場合における図４に示すフローチャートのステップＳ２４の詳細な動作手順を定めたフローチャートである。
【０１６４】
図１９を参照して、制御フレーム処理部２３は、優先度の一番高いキューを最初に選択する（Ｓ６２）。
【０１６５】
次に、制御フレーム処理部２３は、コードベクタテーブルを参照して、選択キューにおいて、ＯＬＴへレポートしていない、すなわち送信要求していないデータの長さＱＬＥＮを算出する（Ｓ６３）。
【０１６６】
そして、制御フレーム処理部２３は、データ長ＱＬＥＮの方が最大レポート量ＲＭより大きい場合には（Ｓ６４でＹＥＳ）、最大レポート量ＲＭに７を加える補正を行なう（Ｓ６５）。
【０１６７】
そして、制御フレーム処理部２３は、補正した最大レポート量ＲＭ以下となるように、送信すべきデータフレームおよび対応のＩＦＧを検索し、検索したデータフレームおよび対応のＩＦＧのデータ長の総和を送信要求量とする（Ｓ６６）。
【０１６８】
そして、制御フレーム処理部２３は、図１５に示した送信要求量の補正を行なう（Ｓ６９）。
【０１６９】
一方、制御フレーム処理部２３は、データ長ＱＬＥＮの方が最大レポート量ＲＭより小さい場合には（Ｓ６４でＮＯ）、図１５に示した送信要求量の補正と同様の補正をデータ長ＱＬＥＮに対して行なう（Ｓ６７）。
【０１７０】
そして、制御フレーム処理部２３は、最大レポート量ＲＭから補正後のデータ長ＱＬＥＮを減じた値を新たに最大レポート量ＲＭとする（Ｓ６８）。
【０１７１】
次に、制御フレーム処理部２３は、今回のレポート生成において未選択のキューが存在する場合には（Ｓ６１でＹＥＳ）、未選択のキューの中で優先度の一番高いキューを選択し、ステップＳ６２以降の処理を繰り返す。
【０１７２】
そして、制御フレーム処理部２３は、今回のレポート生成において未選択のキューが存在しなくなると（Ｓ６１でＮＯ）、検索結果に基づいてコードベクタテーブルの内容を更新する（Ｓ２８）。
【０１７３】
次に、本発明の他の実施の形態について図面を用いて説明する。なお、図中同一または相当部分には同一符号を付してその説明は繰り返さない。
【０１７４】
＜第２の実施の形態＞
本実施の形態は、第１の実施の形態に係るＰＯＮシステムと比べて誤り訂正用データの送信を考慮したＰＯＮシステムに関する。以下で説明する内容以外は第１の実施の形態に係るＰＯＮシステムと同様である。
【０１７５】
図５（ｂ）を参照して説明したように、ＯＮＵは、フレームおよびＩＦＧの２１６バイトごとに３２バイトのＦＥＣパリティを付加したＦＥＣフレーム単位でＯＬＴへのデータ送信を行なう場合がある。この場合、ＯＮＵは、ＯＬＴから与えられる送信許可量をすべてフレームおよびＩＦＧの送信に割り当てることはできず、送信許可量からＦＥＣパリティ分を除いたデータ長をフレームおよびＩＦＧの送信に割り当てることができる。
【０１７６】
一方、ＯＮＵのコードベクタテーブルは、フレームおよびＩＦＧのデータ長とＩＦＧクレジットとを含む一方で、ＦＥＣパリティのデータ長を含んでいない。このため、ＦＥＣフレームの構成を考慮したコードベクタテーブルを作成する必要が生じるが、処理量およびコードベクタテーブルのデータサイズが増大してしまう。
【０１７７】
そこで、本発明の第２の実施の形態に係るＯＮＵでは、以下のようにＦＥＣフレーム構成を考慮したデータ送信を行なう。
【０１７８】
図２０は、図４に示すフローチャートにおけるステップＳ２２の詳細な動作手順を定めたフローチャートである。図２０に示すフローチャートのステップＳ７１〜Ｓ７３の動作は、図１６に示すフローチャートのステップＳ３１〜Ｓ３３の動作と同様である。
【０１７９】
図２０を参照して、まず、制御フレーム処理部２３は、グラントフレームに含まれる送信許可量Ｇを取得する（Ｓ７１）。
【０１８０】
次に、制御フレーム処理部２３は、ＦＥＣフレームの構成に基づいて送信許可量Ｇを補正する（Ｓ７４）。具体的には、制御フレーム処理部２３は、以下の式に従って送信許可量Ｇを補正する。
【０１８１】
Ｇ＝ｆｌｏｏｒ（Ｇ／２４８）×２１６
ここで、ｆｌｏｏｒ（）は、引数の小数点以下を切り捨てる関数、すなわち引数の値を超えない最大の整数を出力する関数である。
【０１８２】
次に、制御フレーム処理部２３は、補正した送信許可量Ｇに７を加える補正を行なう（Ｓ７２）。
【０１８３】
そして、制御フレーム処理部２３は、補正した送信許可量Ｇ以下で送信可能なデータフレームおよび対応のＩＦＧを検索し、ＯＬＴへ送信すべきデータとして選択する（Ｓ７３）。
【０１８４】
図２１は、本発明の第２の実施の形態に係るＰＯＮシステムにおけるＯＮＵからＯＬＴへのフレームおよびＩＦＧの送信動作を示す図である。図２２は、ＯＮＵのレポートおよびＯＬＴのグラントの具体例を示す図である。
【０１８５】
図２１および図２２を参照して、ここでは、ＯＮＵにおいて送信すべきフレームおよび対応のＩＦＧの組が２５存在する場合を考える。また、フレームおよび対応のＩＦＧの各組は８４バイトのデータ長を有するものとする。
【０１８６】
この場合、ＯＮＵは、２５×８４バイト＝２１００バイトの送信要求量を算出し（Ｓ８１）、この送信要求量を含んだレポートをＯＬＴへ送信する（Ｓ８２）。
【０１８７】
ＯＬＴは、ＯＮＵからのレポートを受信すると、このレポートに含まれる送信要求量に対応する送信許可量を算出する。具体的には、ＯＬＴは、ＦＥＣパリティが付加されるデータ長の単位が２１６ビットであることから、２１００バイトの送信要求量に対して２１６０バイトの送信許可量を算出する。そして、ＯＬＴは、ＦＥＣパリティを送信するための帯域を考慮して、算出した送信許可量を補正する。具体的には、ＯＬＴは、送信許可量を２１６０バイト／２１６×２４８＝２４８０バイトに補正する（Ｓ８３）。
【０１８８】
そして、ＯＬＴは、補正した送信許可量をグラントに挿入し、ＯＮＵへ送信する（Ｓ８４）。
【０１８９】
ＯＮＵでは、２１００バイトの送信要求量に対し、２４８０バイトの送信許可量がＯＬＴから与えられる。ここで、ＯＮＵがＦＥＣパリティを考慮しない構成である場合には、ＯＮＵは、最大２４８０バイトのフレームおよび対応のＩＦＧを送信してしまう。しかしながら、本発明の第２の実施の形態に係るＯＮＵは、ＦＥＣパリティを考慮して、グラントフレームに含まれる送信許可量を補正する。具体的には、送信許可量＝２４８０バイト／２４８×２１６＝２１６０バイトに補正する（Ｓ８５）。
【０１９０】
そして、ＯＮＵは、補正した送信許可量に基づいて、２１００バイトのフレームおよび対応のＩＦＧを送信する（Ｓ８６）。
【０１９１】
このように、本発明の第２の実施の形態に係るＯＮＵでは、制御フレーム処理部２３は、ＯＬＴがＯＮＵから受信したフレームおよび対応のＩＦＧの誤り訂正処理を行なうためにフレームおよび対応のＩＦＧに付加して送信すべき誤り訂正用データのデータ長に基づいて送信許可量Ｇを補正する。そして、制御フレーム処理部２３は、コードベクタテーブルに基づいて、補正した送信許可量Ｇ以下で送信可能なフレームおよび対応のＩＦＧを検索し、ＯＬＴへ送信すべきデータとして選択する。
【０１９２】
このような構成により、フレームおよび対応のＩＦＧに誤り訂正用データを付加してＯＬＴへ送信する場合でも、誤り訂正用データを考慮したコードベクタテーブルを作成することなく、ＯＬＴから与えられる送信許可量に応じて正しくデータ送信を行なうことができる。
【０１９３】
その他の構成および動作は第１の実施の形態に係るＰＯＮシステムと同様であるため、ここでは詳細な説明を繰り返さない。
【０１９４】
次に、本発明の他の実施の形態について図面を用いて説明する。なお、図中同一または相当部分には同一符号を付してその説明は繰り返さない。
【０１９５】
＜第３の実施の形態＞
本実施の形態は、第１の実施の形態に係るＰＯＮシステムと比べてバーストの先頭におけるＩＦＧのデータ長を可変にしたＰＯＮシステムに関する。以下で説明する内容以外は第１の実施の形態に係るＰＯＮシステムと同様である。
【０１９６】
本発明の第１の実施の形態に係るＯＮＵでは、バーストの先頭におけるＩＦＧすなわちＯＮＵが１度に送信するフレームの先頭フレームの前に付加されるＩＦＧ（以下、ヘッダとも称する。）は２０バイトの固定長であった。しかしながら、ＰＯＮシステムにおいてアナログ信号の送受信に用いるシリアライザおよびデシリアライザ等の仕様を満足するために、バーストの先頭におけるＩＦＧを２０バイト以外のデータ長にする場合がある。
【０１９７】
本発明の第３の実施の形態に係るＰＯＮシステムでは、たとえば２０バイトを中心とした−８バイトから８バイトの範囲すなわち１２バイトから２８バイトの範囲でヘッダのデータ長を変更可能である。
【０１９８】
図２３は、ヘッダが２０バイトの固定長である場合および可変長である場合のＯＮＵのレポート内容の一例を示す図である。
【０１９９】
図２３を参照して、ＯＮＵにおいて送信すべきフレームおよび対応のＩＦＧの組が４つ存在している。また、フレームおよび対応のＩＦＧの各組は８４バイトのデータ長を有している。
【０２００】
ヘッダが２０バイトの固定長である場合には、ＯＮＵは、４×８４バイト＝３３６バイトをそのまま送信要求量としてレポートに含めてＯＬＴへ送信する。一方、ヘッダが可変長であり、ｎバイトである場合には、ＯＮＵは、３３６＋（ｎ−２０）バイトを送信要求量とする必要がある。
【０２０１】
図２４は、図４に示すフローチャートにおけるステップＳ２４の詳細な動作手順を定めたフローチャートである。図２４に示すフローチャートのステップＳ１０１〜Ｓ１０６の動作は、図１７に示すフローチャートのステップＳ４１〜Ｓ４６の動作と同様である。
【０２０２】
図２４を参照して、制御フレーム処理部２３は、ヘッダのデータ長に基づいて、最大レポート量ＲＭを補正する（Ｓ１０７）。具体的には、ヘッダのデータ長をｎバイトとすると、制御フレーム処理部２３は、以下の式に従って最大レポート量ＲＭを補正する。
【０２０３】
ＲＭ＝ＲＭ−（ｎ−２０）
そして、制御フレーム処理部２３は、コードベクタテーブルを参照し、データ長が補正した最大レポート量ＲＭ以下となるように、送信すべきデータフレームおよび対応のＩＦＧを検索し、検索したデータフレームおよび対応のＩＦＧのデータ長の総和を送信要求量とする（Ｓ１０２〜Ｓ１０６）。
【０２０４】
そして、制御フレーム処理部２３は、ステップＳ１０６において算出した送信要求量を、ヘッダのデータ長に基づいて補正する（Ｓ１０８）。具体的には、制御フレーム処理部２３は、ステップＳ１０６において算出した送信要求量を以下の式に従って補正する。
【０２０５】
送信要求量＝送信要求量＋（ｎ−２０）
図２５は、図４に示すフローチャートにおけるステップＳ２２の詳細な動作手順を定めたフローチャートである。図２５に示すフローチャートのステップＳ９１〜Ｓ９３の動作は、図１６に示すフローチャートのステップＳ３１〜Ｓ３３の動作と同様である。
【０２０６】
図２５を参照して、まず、制御フレーム処理部２３は、グラントフレームに含まれる送信許可量Ｇを取得する（Ｓ９１）。
【０２０７】
次に、制御フレーム処理部２３は、ヘッダのデータ長に基づいて送信許可量Ｇを補正する（Ｓ９４）。具体的には、ヘッダのデータ長をｎバイトとすると、制御フレーム処理部２３は、以下の式に従って送信許可量Ｇを補正する。
【０２０８】
Ｇ＝Ｇ−（ｎ−２０）
次に、制御フレーム処理部２３は、補正した送信許可量Ｇに７を加える補正を行なう（Ｓ９２）。
【０２０９】
そして、制御フレーム処理部２３は、補正した送信許可量Ｇ以下で送信可能なデータフレームおよび対応のＩＦＧを検索し、ＯＬＴへ送信すべきデータとして選択する（Ｓ９３）。
【０２１０】
ここで、ヘッダのデータ長を２４バイトに設定した場合の動作について説明する。
レポート生成においては、制御フレーム処理部２３は、最大レポート量ＲＭを４バイト小さく補正して送信すべきデータフレームおよび対応のＩＦＧを検索する（Ｓ１０１〜Ｓ１０５，Ｓ１０７）。そして、制御フレーム処理部２３は、ステップＳ１０６において算出した送信要求量を４バイト大きく補正することにより、ヘッダのデータ長を考慮した送信要求量を算出する（Ｓ１０８）。
【０２１１】
データ送信においては、制御フレーム処理部２３は、グラントフレームに含まれる送信許可量Ｇを４バイト小さく補正したデータ長以下で送信可能なデータフレームおよび対応のＩＦＧを検索する（Ｓ９１〜Ｓ９４）。そして、送信部２６は、先頭フレームの前に付加すべきＩＦＧのデータ長を２４バイトにしてＯＬＴへ送信する（Ｓ２７）。
【０２１２】
このように、本発明の第３の実施の形態に係るＯＮＵでは、制御フレーム処理部２３は、ヘッダのデータ長と所定データ長との差およびコードベクタテーブルに基づいて、送信すべきヘッダならびにフレームおよび対応のＩＦＧのデータ長の総和をＯＬＴに通知するためのレポートを生成する。
【０２１３】
また、制御フレーム処理部２３は、ヘッダのデータ長と所定データ長との差およびコードベクタテーブルに基づいて、データ長の総和がＯＬＴから通知された送信許可量以下になるように、ヘッダならびにフレームおよび対応のＩＦＧを送信すべきデータとして選択する。
【０２１４】
このような構成により、バーストの先頭におけるＩＦＧのデータ長を可変にした場合でも、予めＯＮＵに設定されている最大レポート量に応じて正しくＯＬＴに対する送信要求を行なうことができ、また、ＯＬＴから与えられる送信許可量に応じて正しくデータ送信を行なうことができる。
【０２１５】
また、本発明の第３の実施の形態に係るＯＮＵでは、本発明の第１の実施の形態に係るＯＮＵにおけるコードベクタテーブルの内容を変更することなく、バーストの先頭におけるＩＦＧのデータ長を可変にすることができる。そして、バーストの先頭におけるＩＦＧのデータ長をたとえば２０バイトよりも長く設定することにより、ＰＯＮシステムにおいて用いられるＩＣ（Integrated Circuit）等の仕様に柔軟に対応することができる。また、バーストの先頭におけるＩＦＧをたとえば２０バイトよりも短く設定することにより、通信時間を短縮し、ＰＯＮシステムにおける帯域を効率的に使用することができる。
【０２１６】
その他の構成および動作は第１の実施の形態に係るＰＯＮシステムと同様であるため、ここでは詳細な説明を繰り返さない。
【０２１７】
次に、本発明の他の実施の形態について図面を用いて説明する。なお、図中同一または相当部分には同一符号を付してその説明は繰り返さない。
【０２１８】
＜第４の実施の形態＞
本実施の形態は、第１の実施の形態に係るＰＯＮシステムと比べてパケットの最後尾を示す終了コードを送信するＰＯＮシステムに関する。以下で説明する内容以外は第１の実施の形態に係るＰＯＮシステムと同様である。
【０２１９】
図２６は、ＩＦＧ、フレームおよび終了コードの構成の一例を示す図である。
図２６を参照して、ＩＦＧは、１２バイトのアイドルデータと、５バイトのプリアンブルと、２バイトのＬＬＩＤと、１バイトのＣＲＣ（Cyclic Redundancy Check）データとを含む。フレームのデータ長はたとえば６４バイトであり、このフレームは、データと、イーサネット（登録商標）用のパリティであるＦＣＳ（Frame Check Sequence）とを含む。
【０２２０】
１０ギガビットイーサネット（登録商標）ＰＯＮでは、バーストの最後すなわち最後尾のパケットのＦＣＳの後に、ＥＯＰ（End Of Packet）を示す終了コード（0xfd）を付加して送信する。
【０２２１】
一方、ＯＮＵのコードベクタテーブルは、フレームおよび対応のＩＦＧのデータ長とＩＦＧクレジットを含む一方で、終了コードのデータ長を含んでいない。このため、終了コードを考慮したコードベクタテーブルを作成する必要が生じるが、処理量およびコードベクタテーブルのデータサイズが増大してしまう。
【０２２２】
そこで、本発明の第４の実施の形態に係るＯＮＵでは、以下のように終了コードを考慮したデータ送信を行なう。
【０２２３】
図２７は、図４に示すフローチャートにおけるステップＳ２４の詳細な動作手順を定めたフローチャートである。図２７に示すフローチャートのステップＳ１１１〜Ｓ１１６の動作は、図１７に示すフローチャートのステップＳ４１〜Ｓ４６の動作と同様である。
【０２２４】
図２７を参照して、制御フレーム処理部２３は、終了コードのデータ長に基づいて、最大レポート量ＲＭを補正する（Ｓ１１７）。具体的には、終了コードのデータ長をｋバイトとすると、制御フレーム処理部２３は、以下の式に従って最大レポート量ＲＭを補正する。
【０２２５】
ＲＭ＝ＲＭ−ｋ
そして、制御フレーム処理部２３は、コードベクタテーブルを参照し、データ長が補正した最大レポート量ＲＭ以下となるように、送信すべきデータフレームおよび対応のＩＦＧを検索し、検索したデータフレームおよび対応のＩＦＧのデータ長の総和を送信要求量とする（Ｓ１１２〜Ｓ１１６）。
【０２２６】
そして、制御フレーム処理部２３は、ステップＳ１１６において算出した送信要求量を、終了コードのデータ長に基づいて補正する（Ｓ１１８）。具体的には、制御フレーム処理部２３は、ステップＳ１１６において算出した送信要求量を以下の式に従って補正する。
【０２２７】
送信要求量＝送信要求量＋ｋ
図２８は、図４に示すフローチャートにおけるステップＳ２２の詳細な動作手順を定めたフローチャートである。図２８に示すフローチャートのステップＳ１２１〜Ｓ１２３の動作は、図１６に示すフローチャートのステップＳ３１〜Ｓ３３の動作と同様である。
【０２２８】
図２８を参照して、まず、制御フレーム処理部２３は、グラントフレームに含まれる送信許可量Ｇを取得する（Ｓ１２１）。
【０２２９】
次に、制御フレーム処理部２３は、終了コードのデータ長に基づいて送信許可量Ｇを補正する（Ｓ１２４）。具体的には、終了コードのデータ長をｋバイトとすると、制御フレーム処理部２３は、以下の式に従って送信許可量Ｇを補正する。
【０２３０】
Ｇ＝Ｇ−ｋ
次に、制御フレーム処理部２３は、補正した送信許可量Ｇに７を加える補正を行なう（Ｓ１２２）。
【０２３１】
そして、制御フレーム処理部２３は、補正した送信許可量Ｇ以下で送信可能なデータフレームおよび対応のＩＦＧを検索し、ＯＬＴへ送信すべきデータとして選択する（Ｓ１２３）。
【０２３２】
図２９は、ＯＮＵがＯＬＴからのグラントフレームに基づいてデータフレームおよびＩＦＧをＯＬＴへ送信する際の動作手順を定めたフローチャートである。図２９に示すフローチャートのステップＳ１３１〜Ｓ１３６およびＳ１３８の動作は、図４に示すフローチャートのステップＳ２１〜Ｓ２６およびＳ２８の動作と同様である。
【０２３３】
図２９を参照して、送信部２６は、制御フレーム処理部２３からの指示に基づいてＩＦＧを生成し、バッファメモリ２５から転送されたデータフレームの間にＩＦＧを挿入し、また、最後尾のデータフレームの後に終了コードを付加してＯＬＴへ送信する（Ｓ１３７）。
【０２３４】
たとえば、ＯＮＵがＦＥＣフレーム単位でＯＬＴへのデータ送信を行なう場合であって２１６０バイトのフレームおよび対応のＩＦＧをＯＬＴに対して送信要求するときには、ＯＮＵがこのまま２１６０バイトを送信要求量とすると、ＦＥＣパリティを含めて２４８０バイトの送信許可量しかＯＬＴから与えられなくなる。
【０２３５】
すなわち、２１６０バイトのフレームおよび対応のＩＦＧに加えて終了コードも送信する必要があることから、実際には２７２８バイトの送信許可量が必要になる。終了コードを送信しないのであれば２１６０／２１６＝１０個のＦＥＣフレームを送信すればよいが、終了コードを送信するためには１１個のＦＥＣフレームを送信する必要がある。
【０２３６】
そこで、本発明の第４の実施の形態に係るＯＮＵでは、制御フレーム処理部２３は、終了コードのデータ長およびコードベクタテーブルに基づいて、送信すべき終了コードならびにフレームおよび対応のＩＦＧのデータ長の総和をＯＬＴに通知するためのレポートを生成する。
【０２３７】
また、制御フレーム処理部２３は、終了コードのデータ長およびコードベクタテーブルに基づいて、データ長の総和がＯＬＴから通知された送信許可量Ｇ以下になるように、終了コードならびにフレームおよび対応のＩＦＧを送信すべきデータとして選択する。
【０２３８】
このような構成により、終了コードを送信する場合でも、予めＯＮＵに設定されている最大レポート量に応じて正しくＯＬＴに対する送信要求を行なうことができ、また、ＯＬＴから与えられる送信許可量に応じて正しくデータ送信を行なうことができる。すなわち、終了コードを付加するためにＦＥＣフレームを１つ多く送信する必要がある場合でも、終了コードを考慮したコードベクタテーブルを作成することなく終了コードを正しく送信することができる。
【０２３９】
その他の構成および動作は第１の実施の形態に係るＰＯＮシステムと同様であるため、ここでは詳細な説明を繰り返さない。
【０２４０】
今回開示された実施の形態はすべての点で例示であって制限的なものではないと考えられるべきである。本発明の範囲は上記した説明ではなくて特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。
【符号の説明】
【０２４１】
２１  受信部、２２  送信部、２３  制御フレーム処理部（制御部）、２４  受信部、２５  バッファメモリ、２６  送信部、２７  カウンタ、２８  バッファメモリ、１０１  ＯＬＴ、１０２，１０２−１〜１０２−ｎ  ＯＮＵ、１０５  スプリッタ、１１１  ユーザ端末、３０１  ＰＯＮシステム。
【図１】
2010088103.tif 000003
【図２】
2010088103.tif 000004
【図３】
2010088103.tif 000005
【図４】
2010088103.tif 000006
【図５】
2010088103.tif 000007
【図６】
2010088103.tif 000008
【図７】
2010088103.tif 000009
【図８】
2010088103.tif 000010
【図９】
2010088103.tif 000011
【図１０】
2010088103.tif 000012
【図１１】
2010088103.tif 000013
【図１２】
2010088103.tif 000014
【図１３】
2010088103.tif 000015
【図１４】
2010088103.tif 000016
【図１５】
2010088103.tif 000017
【図１６】
2010088103.tif 000018
【図１７】
2010088103.tif 000019
【図１８】
2010088103.tif 000020
【図１９】
2010088103.tif 000021
【図２０】
2010088103.tif 000022
【図２１】
2010088103.tif 000023
【図２２】
2010088103.tif 000024
【図２３】
2010088103.tif 000025
【図２４】
2010088103.tif 000026
【図２５】
2010088103.tif 000027
【図２６】
2010088103.tif 000028
【図２７】
2010088103.tif 000029
【図２８】
2010088103.tif 000030
【図２９】
2010088103.tif 000031