(57)【特許請求の範囲】
【請求項１】
固定サイズのデータブロックのｎ（ｎは整数）倍でデータを送信するための帯域を割り当てる局側通信装置とともに光通信システムを構成し、当該局側通信装置に対して前記データブロックに含めて可変サイズの上りユーザデータを送信する加入者側の通信装置であって、
複数のキューにより構成され、上りユーザデータを格納するための上りデータ保持手段と、
前記複数のキューに蓄積された各上りユーザデータを１つまたは複数のグループにグループ化し、同一グループの上りユーザデータの合計蓄積量に基づいて、前記局側通信装置が帯域割り当てを行うための前記データブロックのｍ（ｍは整数）倍のデータ蓄積量をグループ毎に算出する演算手段と、
前記演算手段により算出されたデータ蓄積量を、自身が備える特定のキューのデータ蓄積量として前記局側通信装置へ通知する通知手段と、
を備え、
前記演算手段によって算出されたデータ蓄積量を前記局側通信装置へ通知した後、その通知に対して前記局側通信装置から帯域割り当てられたときに、通知した上りユーザデータを優先的に出力するかどうかを、グループ毎に任意に設定可能とすることを特徴とする通信装置。
【請求項２】
前記演算手段は、前記各キューに予め割り当てられていた優先度および複数の上りユーザデータをグループ化して送信する場合の最大データ量を示すしきい値に基づいて、上りユーザデータをグループ化することを特徴とする請求項１に記載の通信装置。
【請求項３】
前記演算手段は、上りユーザデータをグループ化する場合、最も優先度が高いキューに格納された上りユーザデータから順番に上りユーザデータを選択し、選択した上りユーザデータの合計蓄積量が前記しきい値を超えない範囲で最大となるようにグループ化を行うことを特徴とする請求項２に記載の通信装置。
【請求項４】
前記複数の上りユーザデータをまとめて送信する場合の最大データ量を示すしきい値を複数準備しておき、
前記演算手段は、各上りユーザデータを複数のグループにグループ化する場合、グループ化処理毎にそれぞれ異なるしきい値を使用することを特徴とする請求項３に記載の通信装置。
【請求項５】
前記演算手段は、前記算出した合計蓄積量に加え、前記通知手段が前記局側通信装置へデータ蓄積量を通知する際に使用するフレームのデータ量に基づいて、前記局側通信装置へ通知するデータ蓄積量を算出することを特徴とする請求項１〜４のいずれか一つに記載の通信装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、光通信システムを構成する通信装置に関し、特に、ＧＥ−ＰＯＮ（Gigabit  Ethernet（登録商標）-Passive  Optical  Network）システムにおける加入者終端装置（ＯＮＵ：Optical  Network  Unit）に関する。
【背景技術】
【０００２】
従来のＧＥ−ＰＯＮシステムでは、必要に応じてＦＥＣ（Forward  Error  Correction）を行う。ここで、下記非特許文献１では、フレーム単位でＦＥＣを行うことにより必要に応じたＦＥＣを実現する方式が提案されている。この方式では、フレーム単位で誤り訂正符号（パリティビット）が付与されるため、加入者終端装置（ＯＮＵ）は、フレームに対して付与するパリティ分を考慮して送信バッファへの蓄積量を算出し、算出結果を回線終端装置（ＯＬＴ：Optical  Line  Terminal）へ通知する。そして、ＯＬＴは、通知内容に基づいて、ＯＮＵに割り当てる上り帯域（上り信号の送信を許可する期間）を決定する。
【０００３】
これに対して、ＧＥ−ＰＯＮをベースに高速化を図った１０ＧＥ−ＰＯＮシステムでは６４Ｂ／６６Ｂ符号化を採用しているため、ＦＥＣによるビット誤り訂正を、フレームごとに実施するよりも、符号化処理を実行して得られる６６ビットのブロックに対してビット誤り訂正を実施するほうが効率よい。そこで、下記非特許文献２では、１０ＧＥ−ＰＯＮシステムにおいて、Ethernet（登録商標）のフレーム単位ではなく、６４Ｂ／６６Ｂ符号化を実行して得られる６６ビットのブロック毎にＦＥＣによるビット誤り訂正を行う方法が提案されている。
【０００４】
【非特許文献１】“IEEE  802.3ah”，Clause65，2005年
【非特許文献２】Jeff  Mandin，“Framing  for  Forward  Error  Correction  in  10G  EPON”，IEEE802.3  10Gb/s  PHY  for  EPON  Study  Group，2006年7月
【発明の開示】
【発明が解決しようとする課題】
【０００５】
上記非特許文献２に記載の方法を適用した１０ＧＥ−ＰＯＮシステムでは、従来のＧＥ−ＰＯＮシステムにおけるＦＥＣのフレーミング方法とは異なり、ブロック単位でパリティを付与する。そのため、ＯＮＵは、バッファの蓄積量を通知する際、フレームとパリティ以外の、余剰分の帯域も付与して通知しなければならない。ここで、ＯＮＵがバッファを構成するキューごとに蓄積量を通知するシステムにおいては、ＯＮＵから二つ以上のキューについての蓄積量をキューごとに通知された場合、その蓄積量がデータブロック単位の場合はＯＮＵに必要以上に多くの帯域を割り当てる場合があるため、伝送効率が低下する。また、蓄積量がデータブロック単位でない場合は、ＯＬＴでデータブロックの数を計算しなければならず、ＯＬＴの帯域割り当て演算の負荷が大きくなる、という問題があった。
【０００６】
たとえば、第１のキューと第２のキューについての蓄積量が通知され、かつ各蓄積量に含まれる余剰帯域の合計が「１ブロック（上記ブロック単位に相当）＋パリティ」相当分（ここでは便宜上「帯域割り当て基本単位」と呼ぶ）以上となる場合、ＯＬＴは、「帯域割り当て基本単位」を余分に与えることとなり、伝送効率が低下する。すなわち、同じキューに蓄積された場合には１つの帯域割り当て基本単位で送信可能な情報量の複数のユーザデータが異なるキューに蓄積された場合、ＯＬＴは、これら複数のユーザデータに対して帯域割り当て基本単位を個別に割り当ててしまい、伝送効率が低下する。
【０００７】
本発明は、上記に鑑みてなされたものであって、１０ＧＥ−ＰＯＮシステムに代表される、送信データの固定サイズのブロックに対してＦＥＣのパリティを付与してフレーミングを行うシステムにおいて、伝送効率の向上を実現する通信装置（加入者終端装置）を得ることを目的とする。
【課題を解決するための手段】
【０００８】
上述した課題を解決し、目的を達成するために、本発明は、固定サイズのデータブロックのｎ（ｎは整数）倍のデータを送信するための帯域を割り当てる局側通信装置とともに光通信システムを構成し、当該局側通信装置に対して前記データブロックのｎ倍の上りユーザデータを送信する加入者側の通信装置であって、複数のキューにより構成され、上りユーザデータを格納するための上りデータ保持手段と、前記複数のキューに蓄積された上りユーザデータの合計蓄積量に基づいて、前記局側通信装置が帯域割り当てを行うための前記データブロックのｍ（ｍは「ｎ≦ｍ」を満たす整数）倍のデータ蓄積量を算出する演算手段と、前記演算手段により算出されたデータ蓄積量を、自身が備える特定の単一キューのデータ蓄積量として前記局側通信装置へ通知する通知手段と、を備えることを特徴とする。
【発明の効果】
【０００９】
この発明によれば、上りユーザデータの合計蓄積量に基づいてＯＬＴへ通知するデータ蓄積量を算出することとしたので、ＯＬＴにより余分な帯域を割り当てられることがなくなり、上り方向の伝送効率向上を実現できる、という効果を奏する。
【発明を実施するための最良の形態】
【００１０】
以下に、本発明にかかる通信装置の実施の形態を図面に基づいて詳細に説明する。なお、この実施の形態によりこの発明が限定されるものではない。
【００１１】
実施の形態１．
図１は、本発明にかかる通信装置を含んだ光通信システムの実施の形態１の構成例を示す図である。この図１では、本発明にかかる通信装置であるＯＮＵ（加入者終端装置）の構成例を併せて示している。
【００１２】
図１に示したように、本実施の形態の光通信システムは、複数のＯＮＵ１と、これらを収容しているＯＬＴ（回線終端装置）２と、光カプラなどで構成される光分岐部３と、を含み、各ＯＮＵ１は、光ファイバおよび光分岐部３を介してＯＬＴ２に接続されている。またＯＬＴ２はネットワークに接続されている。
【００１３】
なお、以下の説明では、図１に示した光通信システムが１０ＧＥ−ＰＯＮシステムであり、ＯＮＵ１およびＯＬＴ２は、送信するデータを固定サイズのブロックに分割し、各ブロックにＦＥＣのパリティを付与して生成した信号を送信するシステムであるものとする。また、ＯＬＴ２は、各ＯＮＵ１から通知された、各ＯＮＵ１が保持している送信データの容量（蓄積量）に基づいて、各ＯＮＵ１に割り当てる上り方向のリソース（帯域）を決定する。また、割り当てる帯域は、上記固定サイズのブロック１つとそれに付与されるパリティからなるコードワードを送信するために必要な帯域（以下、これを「帯域割り当て基本単位」とよぶ）の整数倍であるものとする。各ＯＮＵ１は、ＯＬＴ１から割り当てられた帯域（ＧＥ−ＰＯＮシステムではこれをグラント（Grant）とよび、送信を許可する期間を示す）においてデータをバースト送信する。
【００１４】
また、上記複数のＯＮＵ１は、すべて同じ構成をとり、Ｏ／Ｅ変換部１１、ＦＥＣ処理部１２、データ変換部１３、フレーム識別部１４、下りデータバッファ１５、上りデータバッファ１６、蓄積状態管理部１７、演算部１８、出力順序制御部１９、制御フレーム生成部２０および出力制御部２１を含む。
【００１５】
Ｏ／Ｅ変換部１１は、ＯＬＴ２から光信号として受信した下り信号を電気信号へ変換し、また、ＦＥＣ処理部１２から電気信号として受け取った上り信号を光信号へ変換する。
【００１６】
ＦＥＣ処理部１２は、Ｏ／Ｅ変換部１１から受け取ったデータに対してＦＥＣ復号化を行い、ビット誤りを訂正する。また、データ変換部１３から受け取ったデータに対してＦＥＣ符号化を行う。
【００１７】
データ変換部１３は、ＦＥＣ処理部１２から受け取った６６ビットのデータを６４ビットに変換する。また、出力制御部２１から受け取った６４ビットのデータを６６ビットに変換する。
【００１８】
フレーム識別部１４は、ＯＬＴ２から受信した下り方向のフレームについて、それがデータフレーム（下りユーザデータを含んだフレーム）か制御フレームかを識別し、識別結果に応じてフレームを振り分ける。
【００１９】
下りデータバッファ１５は、フレーム認識部１４から受け取ったデータフレームに含まれる下りユーザデータを蓄積する。
【００２０】
上りデータ保持手段に相当する上りデータバッファ１６は、複数のキューを備え、ＯＬＴ２に向けて送信する上りユーザデータをその優先度に対応したキューに蓄積する。すなわち、各キューは上りユーザデータが取りうる優先度のいずれか一つと対応付けされており、同じ優先度の上りユーザデータは同じキューに蓄積される。
【００２１】
蓄積状態管理部１７は、上りデータバッファ１６の各キューの上りユーザデータの蓄積状態を管理する。
【００２２】
演算部１８は、ＯＬＴ２から送信を許可された期間において出力（送信）する上りデータを決定する。また、蓄積状態管理部１７から取得した上りデータバッファ１６の各キューに蓄積された上りデータ量に基づいて、ＯＬＴ２へ通知するデータ蓄積量を算出する。
【００２３】
出力順序制御部１９は、演算部１８での決定結果に従い、上りデータバッファ１６に格納された上りユーザデータの中からＯＬＴ２へ向けて送信するものを選択し、出力制御部２１に対して出力する。
【００２４】
通知手段としての機能を有する制御フレーム生成部２０は、演算部１８により算出されたデータ蓄積量の情報を含んだ制御フレームを生成する。ここで、図２は、演算部１８により算出されたデータ蓄積量の情報を含んだ制御フレームの構成例を示す図であり、具体的には、ＩＥＥＥ８０２．３ａｈにおいて規定されているＲｅｐｏｒｔフレームの構成を示す図である。図２に示したＲｅｐｏｒｔフレームは、キュー（Queue）ごとのデータ蓄積量を個別に通知可能な構成となっている。ただし、本実施の形態の通信装置では、伝送効率の向上を目的として、後述するように、キューごとの個別のデータ蓄積量を通知するのではなく、各キューに蓄積されたデータの合計値に基づいて算出された値を通知することとしている。
【００２５】
出力制御部２１は、制御フレーム生成部２０により生成された制御フレームおよび出力順序制御部１９から受け取ったデータフレームの双方または一方をデータ変換部１３へ出力する。
【００２６】
つづいて、図１に示した構成の光通信システムにおいてＯＮＵ１に接続された端末からネットワークに向けて上りユーザデータを送信する場合のＯＮＵ１の動作について、図面を参照しながら説明する。
【００２７】
配下の端末において上りユーザデータが発生した場合、ＯＮＵ１では、当該上りユーザデータを上りデータバッファ１６が受け取り、その優先度に対応するキューに蓄積する。各上りユーザデータの優先度の詳細については特に規定しないが、たとえば、音声情報などのリアルタイム性（低遅延）が要求されるユーザデータは、優先度の高いデータとして扱う。すなわちユーザデータの種類に応じて、蓄積先のキューを決定する。
【００２８】
蓄積状態管理部１７は、上りデータバッファ１６の各キューの上りユーザデータの蓄積量（SQｎとする。ただし‘ｎ’はキューの識別番号）を監視している。そして、たとえば、いずれかのキューに新たな上りユーザデータが蓄積され、上りデータバッファ１６のデータ蓄積状態が変化した場合など、所定の条件を満足した場合に各キューの上りユーザデータ蓄積状態（データ蓄積量）を演算部１８に通知する。通知を受けた演算部１８は、ＯＬＴ２へ通知するデータ蓄積量（通知量）を算出する。なお、蓄積状態管理部１７が各キューの上りユーザデータ蓄積状態を能動的に通知するのではなく、演算部１８が必要に応じて上りユーザデータ蓄積状態を蓄積状態管理部１７へ問い合わせるようにしてもよい。また、算出する通知量は、ＦＥＣ処理部１２がＦＥＣ符号化処理を実施して得られるデータのデータ量である。
【００２９】
ここで、演算部１８における通知量（データ蓄積量）算出動作について図３を参照しながら説明する。通知量を算出する場合、演算部１８は、まず、キュー毎に、各上りユーザデータをフレーム化する際に必要なＩＦＧ（Inter  Frame  Gap）やプリアンブルなどを含んだフレームオーバヘッド、を含めたデータ蓄積量（SQLnとする）を算出する。そして、算出したSQLnを加算することにより、合計蓄積量であるTSQLmを算出する（ステップＳ１）。
【００３０】
なお、ＯＬＴ２へ通知可能な最大蓄積量には上限が存在する。すなわち、１回の処理にてＯＬＴ２が割り当て可能な帯域（送信許可期間）には上限が存在する。そのため、演算部１８は、上記ステップＳ１で算出した合計蓄積量（TSQLm）のデータを送信するために必要な帯域（要求帯域）が上限を超えていないかどうかを確認する。具体的には、ＯＬＴ２へ通知可能な蓄積量の上限（最大値）をRP＿MAXとすると、まず、RP＿MAXからその中に含まれるパリティ相当分の値を取り除いたもの（R＿MAX）を算出し、このR＿MAXと上記TSQLmを比較する（ステップＳ２）。そして、TSQLmがR＿MAX以下の場合（ステップＳ２，Ｙｅｓ）、ステップＳ３を実行する。一方、TSQLmがR＿MAXを超えている場合（ステップＳ２，Ｎｏ）、ステップＳ５を実行する。
【００３１】
ステップＳ３では、TSQLmを、パリティを除いたコードワードの長さ（CW＿SIZE=224バイト）で割ったときの数であるTSQLmBLKを算出する（ステップＳ３）。ただし、割り切れない（計算結果が整数とならない）場合、端数を繰り上げた値を最終的なTSQLmBLKとする。これにより、上りデータバッファ１６に格納された全データを送信するために必要なコードワードの数（NCWとする）が得られる（すなわち、NCW＝TSQLmBLK）。
【００３２】
そして、上記NCWに基づいて、ＯＬＴ２へ通知する通知量RLmを算出する（ステップＳ４）。RLmの算出動作を具体的に示すと、ＯＮＵ１からＯＬＴ２に向けて最終的に出力されるデータには、NCWと同じ数のパリティ（１６バイト）が付与され、また、パリティを含めたコードワードの長さ（CWP＿SIZEとする）は２４０バイトのため、RLmは、次式で表される。
【００３３】
（ＲＬｍ）＝（ＮＣＷ）×（ＣＷＰ＿ＳＩＺＥ）
ここで、ＦＥＣ処理でリードソロモンＲＳ（２５５，２３９）を利用している場合、CWP＿SIZEは２２４バイトである。これは、同期ビットはＯＬＴ２が算出するグラント（ＯＮＵ１に対して送信を許可する期間）に含まれないためであり、具体的には、「CWP＿SIZE＝（６６−２）ビット×２８＝２２４バイト」となる。
【００３４】
一方、TSQLmがR＿MAXを超えている場合（ステップＳ２，Ｎｏ）に実行するステップＳ５では、ＯＬＴ２へ通知可能な最大蓄積量に対応する最大コードワード数をNCW＿MAXとすると、次式よりＯＬＴ２へ通知する通知量RLmを算出する。
（ＲＬｍ）＝（ＮＣＷ＿ＭＡＸ）×（ＣＷＰ＿ＳＩＺＥ）
すなわち、このステップＳ５では通知可能な最大蓄積量を通知量RLmとする。
【００３５】
上記ステップＳ４またはＳ５で算出された通知量RLmは、後述するＲｅｐｏｒｔフレーム送信処理によりＯＬＴ２へ通知される（ステップＳ６）。
【００３６】
なお、演算部１８が、通知量をフレーム単位で求める機能を有する場合、R＿MAX以下かつフレーム単位で最大となる蓄積量TSQLm＿FMAXを求め、この値からコードワード数NCWを計算し、さらに、このNCWを用いて通知量（RLm）を算出するようにしてもよい。フレーム単位で蓄積量を求めて通知量を算出することにより、グラントの利用効率を上げることができる。
【００３７】
演算部１８による上記データ蓄積量（通知量）算出処理が実行されると、次に、制御フレーム生成部２０は、この算出された通知量の情報を受け取り、当該通知量情報を含んだＲｅｐｏｒｔフレーム（図２参照）を生成する。具体的には、演算部１８から受け取った通知量情報をキュー＃０の蓄積量（Queue  #0  Report）として設定したＲｅｐｏｒｔフレームを生成する。
【００３８】
そして、制御フレーム生成部２０により生成されたＲｅｐｏｒｔフレームは出力制御部２１に渡される。出力制御部２１は、ＯＬＴ２から予め通知されていた送信許可期間において、当該Ｒｅｐｏｒｔフレームをデータ変換部１３へ出力し、その後、Ｒｅｐｏｒｔフレームは、データ変換部１３、ＦＥＣ処理部１２およびＯ／Ｅ変換部１１を介して、ＯＬＴ２へ送信される。
【００３９】
以上の処理を実行して生成されたＲｅｐｏｒｔフレームをＯＮＵ１から受信したＯＬＴ２は、従来の１０ＧＥ−ＰＯＮシステムのＯＬＴと同様の処理を実行してＯＮＵ１へ割り当てるグラント（上り帯域）を決定する。そして、決定結果（グラント）は、制御フレームであるＧａｔｅフレームを利用してＯＮＵ１へ通知される。
【００４０】
上述したように、本実施の形態では、ＯＮＵ１は、複数のキューをまとめて蓄積量を算出し、その算出結果を報告しているため、ＯＬＴ２が一度のグラントで帯域を割り当てたときの余剰帯域を少なくすることができる。また、パリティを含めたコードワード単位で蓄積量をＯＬＴ２へ報告するようにしたため、ＯＬＴ２での演算量を減らすことが出来る。
【００４１】
また、Ｒｅｐｏｒｔフレームを送信したＯＮＵ１は、送信したＲｅｐｏｒｔフレームに対応するＧａｔｅフレームを受信した場合、以下の処理を実行して上りデータバッファ１６に蓄積された上りユーザデータを送信する。ただし、Ｏ／Ｅ変換部１１、ＦＥＣ処理部１２およびデータ変換部１３における処理は一般的な処理であるため説明を省略する。
【００４２】
受信信号に対して所定の処理が実行されデータ変換部１３から出力されたデータ（フレーム）を受信し、それが制御フレームであるＧａｔｅフレームであると判断した場合、フレーム識別部１４は、このＧａｔｅフレームを演算部１８へ渡す。
【００４３】
Ｇａｔｅフレームを受け取った演算部１８は、Ｇａｔｅフレームに含まれるグラント情報を確認し、上りデータバッファ１６の各キューに含まれる上りユーザデータの中から、当該Ｇａｔｅフレームで指定されたグラント（送信許可期間）において送信する上りユーザデータを選択する。上りユーザデータの選択処理においては、上述した通知量の算出動作での処理と同様の処理を実行する。このとき、ＯＬＴ２からのＧａｔｅフレームに含まれるグラント情報がパリティ分を含む場合は、パリティ分を除いて処理を行う。また、上りバースト送信制御に必要なフレームオーバヘッド分も除いて処理を行う。
【００４４】
なお、演算部１８は、送信する上りユーザデータを選択するにあたって、優先度が高いキューに蓄積されている上りユーザデータを優先的に選択する。この場合の動作を示したものが図４である。図４に示した例の場合、まず、ＯＮＵ１が、キューを区別することなく各キューに蓄積されているすべての上りユーザデータの合計データ量を算出し、算出結果をキュー＃０の蓄積量（図示した「Queue#0  Report」に相当）に設定したＲｅｐｏｒｔフレームを生成・送信する。その後Ｇａｔｅフレームを受信し、その結果指定されたグラントにメッセージを割り当てる場合、優先度の高いキューに蓄積された上りユーザデータから順番に選択する。これにより、優先度の高い上りユーザデータの遅延量が増大するのを抑えられる。
【００４５】
また、上りユーザデータを選択するにあたって、演算部１８は、前回のＲｅｐｏｒｔフレームに設定したデータ蓄積量（キュー＃０の蓄積量として設定した蓄積量）を算出する際、既に上りデータバッファ１６に蓄積されていた上りユーザデータを優先的に選択する。そのために、演算部１８は、Ｒｅｐｏｒｔフレームに設定する通知量を算出する際には、その時点で上りデータバッファ１６に蓄積されている上りユーザデータの位置情報として、各上りユーザデータの開始位置から通知量の最後の位置を記憶しておく。
【００４６】
なお、上記説明では、演算部１８は、Ｒｅｐｏｒｔフレームを送信するための帯域（Ｒｅｐｏｒｔフレームのデータ量）を考慮せずに通知量（RLm）を算出するようにしていたが、任意のグラントでＲｅｐｏｒｔフレームも送信する場合に、Ｒｅｐｏｒｔフレームのデータ量を考慮して通知量を算出するようにしてもよい。図５は、ＯＮＵがＲｅｐｏｒｔフレームのデータ量を考慮して通知量を算出する場合の動作の一例を示す図であり、この例では、ＯＮＵが、１回目のＲｅｐｏｒｔフレームに対して、２回目のＲｅｐｏｒｔフレームを送信するために必要な帯域を考慮して算出したＲＬ＃１を設定している。
【００４７】
このように、本実施の形態のＯＮＵは、Ｒｅｐｏｒｔフレームを生成する場合、その時点で保持している上りユーザデータの合計蓄積量に基づいてＲｅｐｏｒｔフレームへ設定する蓄積量（ＯＬＴへ通知するデータ蓄積量）を決定することとした。また、決定した蓄積量をある特定の単一キューのデータ蓄積量として設定したＲｅｐｏｒｔフレームをＯＬＴへ通知することとした。これにより、ＯＬＴにより余分な帯域を割り当てられることがなくなり、上り方向の伝送効率向上を実現できる。
【００４８】
実施の形態２．
つづいて、実施の形態２について説明する。なお、本実施の形態の光通信システムおよびＯＮＵの構成は、上述した実施の形態１と同様である（図１参照）。
【００４９】
実施の形態１では、ＯＮＵ１からの１回のＲｅｐｏｒｔフレーム送信に対してＯＬＴ２が１つのグラントを割り当てる場合について説明したが、１回のＲｅｐｏｒｔフレーム送信に対して複数のグラントを割り当てるような構成とすることも可能である。
【００５０】
たとえば、ＯＮＵ１の上りデータバッファ１６を構成する各キューを予めグループ分けしておき、グループ毎に、上りユーザデータの合計蓄積量（実施の形態１で示したTSQLmに相当）を算出し、これらの算出結果を用いて、ＯＬＴ２へ通知する通知量（実施の形態１で示したRLmに相当）を算出する。そして、算出した各通知量を、Ｒｅｐｏｒｔフレームのキュー＃０の蓄積量（Queue  #0  Report）から順番に設定してＯＬＴ２へ送信する。グループ毎の合計蓄積量を算出する処理および算出した各合計蓄積量に基づいて通知量を算出する処理については、実施の形態１で示した処理と同様であるため、その説明は省略する。
【００５１】
ここで、それぞれのグループに対応したグラントの長さを想定し、閾値G＿LIMIT#mをＯＮＵ１に設定しておく。そしてＲｅｐｏｒｔフレームを作成する際に、G＿LIMIT#m以下で蓄積量を通知する。すなわち、演算部１８は、G＿LIMIT#mを考慮してグループ毎の通知量を算出する。G＿LIMIT#mは、ＦＥＣのパリティを含まないコードワード長であっても含んだコードワード長であってもよいが、計算量を考慮した場合、パリティを含まないコードワード長が望ましい（パリティを含まないコードワード長の場合には、計算量が抑えられる）。
【００５２】
各キューをグループ分けするにあたっては、各キューが複数のグループに属するようにしてグループ分けを行ってもよい。そして、各キューが複数のグループに属するようなグループ構成とした場合、グループ毎の上りユーザデータの合計蓄積量算出処理では、グラントに割り当てたデータの合計データ量が対応するしきい値（当該グラントにて送信可能な最大データ量）を超えないように、グラントに対してデータを割り当てる。このとき、グラントに対応するグループ内の優先度の高いデータ（優先度の高いキューに格納されたデータ）から順番に割り当てる。そして、グループ内のすべてのデータを割り当てることができた場合、すべてのデータの合計データ量をそのグループの合計蓄積量とする。一方、合計データ量がしきい値を超えてしまう場合（同一グループ内の全データを対応するグラントに割り当てることができない場合）、割り当て可能なデータの合計データ量を合計蓄積量とする。またこのとき、割り当てることができなかったデータを格納しているキューが他のグループにも属していれば、当該割り当てることができなかったデータを当該他のグループに対応するグラントに割り当てる。以上の処理をすべてのグループに対して実行することにより、各グループの上りユーザデータの合計蓄積量を算出する。
【００５３】
グループ毎の上りユーザデータの合計蓄積量算出処理の具体例を以下に示す。ここでは、図６に示した場合の例について説明する。図６は、キュー（Queue）＃０〜＃３が上りデータバッファ１６を構成し、また、キュー＃０と＃１がグループＡに属し、キュー＃０〜＃２がグループＢに属し、キュー＃１〜＃３がグループＣに属する場合の例を示している。また、キュー＃０にデータＤ０が格納され、キュー＃１にデータＤ１およびＤ２が格納され、キュー＃２にデータＤ３が格納され、キュー＃３にはデータＤ４が格納されている。なお、グループＸ、グラントＸおよびしきい値Ｘ（Ｘ＝Ａ，Ｂ，Ｃ）が対応関係にあるものとし、各キューに対応する優先度の関係は、キュー＃０の優先度が最も高く、以下、キュー＃１、キュー＃２、キュー＃３の順に低くなっていくものとする。
【００５４】
合計蓄積量算出処理では、演算部１８は、まず、グループＡに属するデータをその優先度順に、合計データ量が対応するしきい値Ａを超えない範囲でグラントＡに割り当てる。そして、割り当て処理が終了した場合、グラントＡに割り当てたデータの合計データ量をグループＡの合計蓄積量とする。次に、グループＢに属するデータをその優先度順に、合計データ量が対応するしきい値Ｂを超えない範囲でグラントＢに割り当て、割り当てたデータの合計データ量をグループＢの合計蓄積量とする。最後に、グループＣに属するデータをその優先度順に、合計データ量が対応するしきい値Ｃを超えない範囲でグラントＣに割り当て、割り当てたデータの合計データ量をグループＣの合計蓄積量とする。
【００５５】
図６に示した例では、グループＡにデータＤ０〜Ｄ２が属し、また、データＤ０の優先度が最も高いため、まず、データＤ０をグラントＡに割り当てる。そして、データＤ１の優先度が次に高いため、データＤ１をグラントＡに割り当てることが可能かどうか（（Ｄ０のデータ量）＋（Ｄ１のデータ量）≦（しきい値Ａ）が成立するかどうか）を確認する。この例では、データＤ１をグラントＡに割り当てることが不可能であるため、グラントＡに対するデータの割り当てを終了し、グラントＡに割り当てたデータ（この例ではデータＤ０のみ）の合計データ量（＝データＤ０のデータ量）をグループＡの合計蓄積量とする。
【００５６】
次に、グループＢにデータＤ１〜Ｄ３が属し、また、データＤ１とＤ２の優先度は同じ（共にキュー＃１に格納されている）かつＤ３の優先度よりも高いため、キュー＃１内の並び順に従い、まず、データＤ１をグラントＢに割り当てる。そして、残った中で優先度が最も高いデータＤ２をグラントＢに割り当てることが可能かどうか（（Ｄ１のデータ量）＋（Ｄ２のデータ量）≦（しきい値Ｂ）が成立するかどうか）を確認する。この例ではデータＤ２をグラントＢに割り当てることが可能であるため、データＤ２をグラントＢに割り当てる。さらに、データＤ３をグラントＢに割り当てることが可能かどうかを確認する。この例では、データＤ３をグラントＢに割り当てることが可能であるため、データＤ３をグラントＢへ割り当てる。そして、グループＢに属する他のデータが存在しないため、グラントＢへのデータ割り当てを終了し、グラントＢに割り当てたデータ（データＤ１〜Ｄ３）の合計データ量をグループＢの合計蓄積量とする。
【００５７】
そして、グループＣにはデータＤ３およびＤ４が属し、また、データＤ３の優先度がデータＤ４の優先度よりも高い。しかし、データＤ３はグループＢにも属しており、グループＢのデータを割り当てる処理にてグラントＢに割り当て済みである。そのため、ここでは、未だどのグラントにも割り当てられていないデータ（データＤ４）を対象としてグラントへＣへの割り当て処理を行う。具体的には、まず、データＤ４をグラントＣに割り当てる。そして、未だどのグラントにも割り当てられていないデータはグループＣ内に存在しないため、グラントＣへのデータ割り当てを終了し、グラントＣに割り当てたデータ（データＤ４）の合計データ量（＝データＤ４のデータ量）をグループＣの合計蓄積量とする。
【００５８】
このようにグラント毎に閾値を用いることで、ＯＬＴ２がＯＮＵ１から通知された通知量でグラントを割り当てる場合は、複数のグラントがあっても、それぞれのグラントに含まれる余剰な帯域を極力減らすことができ、上りの帯域利用効率を向上させることができる。
【００５９】
また、それぞれのグラントで閾値を複数もち、輻輳時の最低割当量を確保できるような閾値も設定した場合、輻輳時には通常よりも低い閾値を使用して最低割当量を確保するなど、状況に応じて閾値を使い分けることが可能となる。すなわち、上りの帯域利用効率において柔軟な設計が可能となり、また帯域利用効率も向上させることができる。
【００６０】
また、上記説明では、ＯＬＴ２が、従来の１０ＧＥ−ＰＯＮシステムのＯＬＴと同様の処理を実行してＯＮＵ１へ割り当てるグラント（上り帯域）を決定する場合を想定していた。しかしながら、ＯＮＵ１からグループ毎の上りユーザデータの合計蓄積量を通知された場合、ＯＬＴ２が、通知された上りユーザデータの合計蓄積量の中から選択した合計蓄積量に基づいて帯域を割り当てるようにした場合、トラヒックの状態（輻輳状態かどうかなど）に応じた効率のよい帯域割り当てが可能となる。なお、ＯＮＵ１によるグループ毎の合計蓄積量算出方法は、上記図６に基づいて説明したとおりである。
【００６１】
図７は、ＯＬＴ２が、通知された上りユーザデータの合計蓄積量の中から選択した合計蓄積量に基づいて帯域を割り当てる動作の一例を示した図である。図７に示した例では、キュー＃０と＃１が属するグループＡとキュー＃０〜＃３が属するグループＢが存在する。そのため、まず、ＯＮＵ１からＯＬＴ２に対してグループＡとグループＢ（すなわちグラントＡとグラントＢ）についての上りユーザデータの合計蓄積量がＯＬＴ２へ通知される。そして、ＯＬＴ２は、通知された複数の合計蓄積量の中から１つの合計蓄積量をトラヒックの状態に応じて選択し、選択した合計蓄積量に基づいて帯域を割り当てる。たとえば、輻輳状態にあると判断した場合、ＯＬＴ２は、グループＡの合計蓄積量（値が小さい方の合計蓄積量）を選択する。
【００６２】
なお、各キューのグループ分けは、たとえば、対応付けられた優先度を利用し、優先度の高いグループと低いグループに分ける。
【００６３】
また、予めグループ分けしておくのではなく、必要に応じてグループ分けするようにしてもよい。
【００６４】
たとえば、演算部１８が、上りデータバッファ１６に蓄積されているすべての上りユーザデータを１つのグラントに納めることが可能かどうかを判断し、１つに収めることができない場合にはグループ分けを行うようにする。この場合、優先度の高いキューから順番に選択していき、１つのグラント（１番目のグラント）に収めることができなくなった時点で、別グループ（２番目のグラント）に割り当てるキューの選択を開始する。なお、この場合においても、上記G＿LIMIT#m（しきい値）を利用することが可能である。すなわち、G＿LIMIT#mに対応する長さ以下にグラント長を収めることができなくなった時点で、別グループに割り当てるキューの選択を開始する。これにより、それぞれのグラントに含まれる余剰な帯域を極力減らすことができる。
【００６５】
また、別のグループ化方法として、たとえば、優先度が最も高いキューから順番に３つのキューを選択した場合には選択したキューに蓄積されているすべての上りユーザデータを１つのグラントに収めることができないが、優先度が最も高いキューと２番目に高いキューに加えて４番目に高いキューを選択した場合には、選択したキューに蓄積されているすべての上りユーザデータを１つのグラントに収めることが可能であれば、優先度が３番目に高いキューに代えて４番目に高いキューを選択する。なお、このようなグループ化を行う場合であっても、上記G＿LIMIT#m（しきい値）を利用することが可能である。このようにすることで、キューのグループ化を柔軟に行うことができ、それぞれのグラントに含まれる余剰な帯域を極力減らすことができる。
【００６６】
また、優先度を考慮せずに、蓄積量の多いバッファから順番に選択することによりグループ化を行う方法も考えられる。
【００６７】
このように、本実施の形態では、上りデータバッファを構成する各キューを複数のグループに分け、Ｒｅｐｏｒｔフレームに設定する通知量（Queue  #n  Report）をグループ毎に算出することとした。これにより、上りデータバッファに蓄積された各データを、ＯＬＴから余剰な帯域を割り当てられるのを防止しつつ複数のグラントに効率的に割り当てることができる。
【産業上の利用可能性】
【００６８】
以上のように、本発明にかかる通信装置は、光通信システムに有用であり、特に、送信データの固定サイズのブロックに対してＦＥＣのパリティを付与してフレーミングを行う方式を採用した光通信システムにおいて効率的なデータ伝送を実現する加入者側の通信装置（加入者終端装置）に適している。
【図面の簡単な説明】
【００６９】
【図１】本発明にかかる通信装置を含んだ光通信システムの実施の形態１の構成例を示す図である。
【図２】バッファを構成する各キューのデータ蓄積量の情報を含んだ制御フレームの構成例を示す図である。
【図３】演算部における通知量（データ蓄積量）算出動作の一例を示すフローチャートである。
【図４】実施の形態１の通信システムにおける帯域制御の一例を示す図である。
【図５】本発明にかかる通信装置がＲｅｐｏｒｔフレームのデータ量を考慮して通知量を算出する場合の動作の一例を示す図である。
【図６】実施の形態２のＯＬＴにおける上りユーザデータの合計蓄積量算出処理の一例を示す図である。
【図７】実施の形態２のＯＬＴにおける上りユーザデータの合計蓄積量算出処理の一例を示す図である。
【符号の説明】
【００７０】
１  ＯＮＵ（加入者終端装置）
２  ＯＬＴ（回線終端装置）
３  光分岐部
１１  Ｏ／Ｅ変換部
１２  ＦＥＣ処理部
１３  データ変換部
１４  フレーム識別部
１５  下りデータバッファ
１６  上りデータバッファ
１７  蓄積状態管理部
１８  演算部
１９  出力順序制御部
２０  制御フレーム生成部
２１  出力制御部
【図１】
0005058005.tif 000002
【図２】
0005058005.tif 000003
【図３】
0005058005.tif 000004
【図４】
0005058005.tif 000005
【図５】
0005058005.tif 000006
【図６】
0005058005.tif 000007
【図７】
0005058005.tif 000008