(57)【要約】光ネットワーク用プロトコルは、トランシーバノードへのデータ送信を光ネットワークの加入者光インタフェースに許可する時間を制御できる。このプロトコルは、特定加入者グループの加入者光インタフェース間における上り送信の衝突を防止できる。このプロトコルにより、加入者に近接したトランシーバノードは、１人以上の加入者の要求に基づき、上り帯域幅を追加または減少して割り当てできる。すなわち加入者に近接したトランシーバノードは、加入ベースでまたは必要に応じて、加入者の上り帯域幅を管理（監視）および調整できる。このプロトコルは、個別パケットではなく、パケットの集合を考慮できる。アルゴリズムは、パケットの集合に対して計算を実行することにより、実行頻度を少なくし、低性能・低価格装置での実現を可能にする。例えば汎用マイクロプロセッサで実行するソフトウエアで実現できる。
2004535717.tif 000002
【特許請求の範囲】
【請求項１】
光ネットワークにおける加入者光インタフェースのグループに関して、
前記加入者光インタフェースから状態メッセージを受け取り、
前記状態メッセージから上り送信の予約情報を計算し、
各加入者光インタフェースの上り送信タイムスロットの期間を計算し、
前記計算した上り送信タイムスロット期間を各加入者光インタフェースへ送信し、
前記計算した上り送信タイムスロットの各期間中に各加入者光インタフェースから上り送信を受け取る各段階を備えた、光ネットワークの上りパケットを処理する方法。
【請求項２】
各状態メッセージは、各加入者光インタフェースが送ろうとするデータ量を示す、請求項１の方法。
【請求項３】
上り送信タイムスロットの期間を計算する前記段階は、
加入者光インタフェースが活性であるか否かを決定し、
加入者光インタフェースの待ち行列サイズを評価する各段階をさらに備える、請求項１の方法。
【請求項４】
上り送信タイムスロットの期間を計算する前記段階は、時間領域において加入者光インタフェースの提供負荷をフィルタする段階をさらに備える、請求項１の方法。
【請求項５】
上り送信タイムスロットの期間を計算する前記段階は、トークンバケットに加入者光インタフェースの持続速度にほぼ等しい数のトークンを加える段階をさらに備える、請求項１記載の方法。
【請求項６】
上り送信タイムスロットが上りパケットを収容するほど十分に大きくない場合、当該上りパケットを送信前に加入者光インタフェースに保持するか否かを決定する段階をさらに備える、請求項１記載の方法。
【請求項７】
特定の加入者光インタフェースから上りパケットを受け取るか否かを、同一加入者グループにおける他の加入者光インタフェースがどれくらいの量のデータを送ろうとしているかに基づき決定する段階をさらに備える、請求項１記載の方法。
【請求項８】
特定の加入者光インタフェースから上りパケットを受け取るか否かを、加入者光インタフェースに付与したサービス品質に基づき決定する段階をさらに備える、請求項１記載の方法。
【請求項９】
請求項１記載の各段階を実行するためのコンピュータ実行可能命令を有するコンピュータ読み取り可能媒体。
【請求項１０】
複数の加入者光インタフェースと、
前記複数の加入者光インタフェースに接続した光タップルーティング装置とを備え、前記光タップルーティング装置は、記憶装置と当該記憶装置に接続した中央処理装置とを備え、当該中央処理装置は、
加入者の上り送信期間長をトークンバケットアルゴリズムによって計算し、
前記期間中に、複数の異なる加入者からのパケット衝突を実質的に低減するようにして、複数の加入者光インタフェースから少なくとも１つのパケットを入手する各段階を実行すべくプログラムされている、光ネットワークシステム。
【請求項１１】
前記中央処理装置は、
第１加入者光インタフェースの帯域幅を監視し、
前記第１加入者光インタフェースが使用しない帯域幅の一部を、１つ以上の他の第２加入者光インタフェースに提供する各段階をさらに実行すべくプログラムされている、請求項１０の光ネットワークシステム。
【請求項１２】
前記中央処理装置は、特定の加入者光インタフェースから上りパケットを受け取るか否かを、加入者光インタフェースに付与したサービス品質に基づき決定する段階をさらに実行すべくプログラムされている、請求項１０の光ネットワークシステム。
【請求項１３】
光ネットワークにおける加入者のグループに関して、
加入者から１つ以上の上りパケットを送信する要求を受け取り、
前記１つ以上の上りパケットを処理できるか否かを決定し、
前記加入者に、前記１つ以上の上りパケットを処理できるか否かを示すメッセージを送り、
前記１つ以上の上りパケットを処理できると決定した場合、前記上りパケットを受け取る各段階を備えた、光ネットワークの上りパケットを処理する方法。
【請求項１４】
上りパケットを処理できるか否かを決定する前記段階は、利用可能上り帯域幅をトークンバケットアルゴリズムによって計算する段階をさらに備える、請求項１３の方法。
【請求項１５】
上りパケットを処理できるか否かを決定する前記段階は、利用可能上り帯域幅を、他の加入者が送信しようとしている他の上りパケットに基づき計算する段階をさらに備える、請求項１３の方法。
【請求項１６】
上りパケットを処理できるか否かを決定する前記段階は、加入者の上り帯域幅加入サービス品質を決定する段階をさらに備える、請求項１３の方法。
【請求項１７】
上りパケットを処理できるか否かを決定する前記段階は、利用可能上り帯域幅を、データサービスハブを宛先とする合計上りデータトラフィック負荷に基づき計算する段階をさらに備える、請求項１３の方法。
【請求項１８】
メッセージを送る前記段階は、加入者の送信可能上りパケット量を示すメッセージを送る段階をさらに備える、請求項１３の方法。
【請求項１９】
１つ以上の上りパケットを処理できないと決定した場合、加入者が保持している上りパケットを破棄する段階をさらに備える、請求項１３の方法。
【請求項２０】
重み付け最大最小・数学アルゴリズムに基づき、各加入者光インタフェースに帯域幅を割り当てる段階をさらに備える、請求項１３の方法。
【請求項２１】
請求項１３記載の各段階を実行するためのコンピュータ実行可能命令を有するコンピュータ読み取り可能媒体。
【請求項２２】
上り送信タイムスロットの期間を計算する前記段階は、トークンバケットエミュレーションアルゴリズムによって前記期間を計算することをさらに備える、請求項１の方法。
【発明の詳細な説明】
【０００１】
関連出願
本出願は、２００１年７月５日に出願し米国出願第０９／８９９，４１０号を付与された非仮特許出願「データサービスプロバイダと加入者との間で光信号を通信するシステムおよび方法」の一部継続出願である。また本出願は、２００１年１０月４日に出願し米国出願第０９／９７１，３６３号を付与された非仮特許出願「データサービスプロバイダと加入者との間で光信号を上りおよび下り方向に通信するシステムおよび方法」に関連する。本出願は、２０００年１０月２６日に出願し米国出願第６０／２４４，０５２号を付与された仮特許出願「光ファイバケーブルを介して映像、音声、およびデータサービスを提供するシステム、その２」と、２０００年１２月２８日に出願し米国出願第６０／２５８，８３７号を付与された仮特許出願「光ファイバケーブルを介して映像、音声、およびデータサービスを提供するシステム、その３」と、２０００年１０月２７日に出願し米国出願第６０／２４３，９７８号を付与された仮特許出願「光ファイバケーブルを介して音声およびデータサービスを提供するプロトコル」と、２００１年５月８日に出願し米国出願第６０／２８９，１１２号を付与された仮特許出願「光ファイバケーブルを介して音声およびデータサービスを提供するプロトコル、その２」とに関して優先権を主張すると共に、それらの全内容を参照により組み込む。
【０００２】
技術分野
本発明は、映像、音声、およびデータ通信に関する。さらに詳しくは、加入者からデータサービスプロバイダへ上り光信号を通信するシステムおよび方法に関する。
【０００３】
背景技術
音声や映像トラフィック等、より複雑なデータを送信する通信ネットワークへの依存が高まっており、帯域幅に対する要求が極めて高くなっている。この帯域幅に対する要求に応えるため、通信ネットワークは、かかる複雑なデータを送信するにあたり、光ファイバへの依存を高めている。同軸ケーブルを使用した従来の通信構成は、光ファイバケーブルだけからなる通信ネットワークに徐々に置き換えられている。光ファイバケーブルが同軸ケーブルより優れている点の１つは、より多量の情報を搬送できることである。
【０００４】
家庭向け光ファイバ（ＦＴＴＨ）光ネットワーク構成は、多くのデータサービスプロバイダの夢であった。なぜなら光ファイバは、どのような組み合せの高速サービスでも、高信頼ネットワークを介して企業および消費者へ配信できるからである。ＦＴＴＨに関連し、事業向け光ファイバ（ＦＴＴＢ）がある。ＦＴＴＨおよびＦＴＴＢ構成が好ましい理由は、信号品質が向上し、保守が低減し、関連ハードウエアの寿命が延びるからである。しかしながらＦＴＴＨおよびＦＴＴＢ構成は、コストが極めて高いと考えられてきた。しかしながら、ＦＴＴＨおよびＦＴＴＢは、現在、帯域幅に対する要求の高さおよび改良型光ネットワークの研究開発により、現実的となっている。
【０００５】
当業界は、従来型の混成家庭向け光ファイバ（ＦＴＴＨ）および混成同軸光ファイバ（ＨＦＣ）構成を提案した。ＨＦＣは、現在多くのケーブルテレビシステムが採用している構成である。このＦＴＴＨ／ＨＦＣ構成は、能動信号源をデータサービスハブと加入者との間に配置する。この構成において、代表的な能動信号源は、ルータからなる。この従来型ルータは、複数のデータポートを有し、それらが各加入者を支援する設計となっている。すなわち従来型ルータは、各加入者について１つのポートを使用する。このルータの各データポートは光ファイバに接続し、その光ファイバは加入者に接続する。この従来型ＦＴＴＨ／ＨＦＣ構成におけるデータポートと光ファイバとの間の接続は、ラストマイルにファイバが集中する。「ラストマイル」および「ファーストマイル」とは、いずれも加入者に接続する光ネットワークの最後の部分を示す用語である。従って、距離としてのマイルを文字通りに解釈すべきではない。
【０００６】
ＦＴＴＨ／ＨＦＣ構成は、ルータからの光ケーブル数が多いことに加え、従来の同軸ケーブルによって無線周波信号を伝送しなければならない。同軸ケーブルを使用するため、加入者とデータサービスハブとの間に多くの無線周波（ＲＦ）増幅器を必要とする。例えば同軸型システムの１〜３キロメートル毎に無線周波増幅器を必要とする。
【０００７】
ＦＴＴＨ／ＨＦＣ構成において同軸ケーブルを使用することは、システムの総コストを押し上げる。なぜなら、この構成には２つの独立したネットワークが存在するからである。すなわちＦＴＴＨ／ＨＦＣ構成は、完全に異なる導波路（同軸ケーブルと光ファイバの組合せ）と、かかる２つの独立したシステムを支援するために必要な光機器とにより、高い保守コストを必要とする。簡単に言えばＦＴＴＨ／ＨＦＣ構成は、光ネットワークと電気ネットワークとを単に接続するだけであり、両ネットワークは互いに別々に動作する。
【０００８】
ＦＴＴＨ／ＨＦＣ構成における電気ネットワークの１つの問題は、データサービスプロバイダと加入者との間のデータ通信を支援するため、ケーブルモデム技術を含むことである。一般にデータサービスプロバイダは、ケーブルモデム終端システム（ＣＭＴＳ）を使用し、加入者宛に下りデータ通信を発信する。加入者は、かかる下りデータ通信を受信するため、一般にケーブルモデムを使用する。このケーブルモデムは、当業界においてデータオーバケーブルサービスインタフェース規格（ＤＯＣＳＩＳ）として知られる特定プロトコルに基づき動作する。ＤＯＣＳＩＳプロトコルは、サービスフローを定義する。サービスフローとは、下り方向の流れについて、ＣＭＴＳが各パケット内の多数のパラメータを検査し、それに基づいてパケットグループに割り当てる識別データである。
【０００９】
すなわちサービスフローは、メディアアクセス制御（ＭＡＣ）層伝送サービスであり、ケーブルモデムが伝送した上りパケット、あるいはＣＭＴＳが伝送した下りパケットに対し、一意の方向性パケット伝送を提供する。ＤＯＣＳＩＳプロトコルにおいてパケットグループに割り当てた識別データは、入りパケット内にＴＣＰ、ＵＴＰ、ＩＰ、ＬＬＣ、および８０２．１Ｐ／Ｑ識別子等のパラメータを含むことができる。
【００１０】
ＣＭＴＳは、これら識別データに基づき、特定のデータストリームにサービスフローＩＤ（ＳＦＩＤ）を割り当てる。一般にサービスフローは、ＣＭＴＳが前記ＳＦＩＤをデータストリームに割り当てた時に発生する。ＳＦＩＤは、ＣＭＴＳにおいてサービスフローの基本識別子として働く。サービスフローは、少なくともＳＦＩＤと方向とによって特徴付けられる。
【００１１】
一般にＳＦＩＤは、ユーザが通信を希望する時に割り当てる。ユーザが通信チャネルを解放すると、ＳＦＩＤは消滅する。全セッションが閉じると、当該モデムとの全通信は終了する。モデムは、再び通信を必要とする場合、タイムスロットを獲得し、帯域幅を要求しなければならない。このため通信を再開するまでに幾分かの遅延がある。この遅延は、システム負荷やアプリケーションの性質により、ユーザが気付くこともあれば気付かないこともある。
【００１２】
ケーブルモデムを経由する通信は、非対称である。すなわち下り方向のデータ速度は、上り方向よりも大きい。これは例えばウエブサーフィン等、ある種の通信にはふさわしい。しかしながら、ピアツーピアファイル転送（例えばナップスタータイプのサービス等のデジタル音声ファイル転送）や大きなＥメール添付ファイルなど、別のタイプのサービスにとっては効率的でない。この非対称通信は、同軸ケーブルを使用する結果、戻り信号を低周波数に制限しなければならないことに起因する。
【００１３】
従って本分野においては、データサービスプロバイダと加入者との間で光信号を通信するにあたり、同軸ケーブルを必要とせず、同軸ケーブルでのデータ信号伝送を支援する関連ハードウエアやソフトウエアも必要としないシステムおよび方法が求められている。また本分野においては、データサービスプロバイダと加入者との間で光信号を通信するにあたり、多数の加入者にサービスを提供でき、データサービスハブにおける接続数を削減できるシステムおよび方法が求められている。
【００１４】
さらに本分野においては、光ネットワークの一部である各加入者に対して帯域幅を保証できる、上り光通信処理方法およびシステムが求められている。さらに本分野においては、帯域幅を保証できると共に、保証した帯域幅の残余部分をプールして各加入者がアクセスできるようにできるシステムおよび方法が求められている。すなわち本分野においては、複数の加入者から保証帯域幅を回収しそれをプールできるシステムおよび方法が求められている。さらに本分野においては、トークンバケットエミュレーションによってパケットのグループまたはパケットの集合を処理できるシステムおよび方法が求められている。さらに本分野においては、異なる加入者に帯域幅を公平に割り当てることができるシステムおよび方法が求められている。「公平」とは、正確に数学的定義である。さらに本分野においては、上りデータパスの通信トラフィック負荷を軽減できるシステムおよび方法が求められている。
【００１５】
発明の開示
本発明は、広く光ファイバネットワークを介してデータおよび放送信号を効率的に伝送するシステムおよび方法に関する。さらに詳しくは、光ネットワークの加入者から当該光ネットワークのデータサービスハブへ伝送する上り光通信を扱う方法およびシステムに関する。「上り」とは、加入者が発信するデータ信号を光ネットワークのデータサービスハブへ向けて送る通信方向を定義する用語である。逆に「下り」とは、データサービスハブが発信するデータ信号を光ネットワークの加入者へ向けて送る通信方向を定義する用語である。
【００１６】
本発明の方法およびシステムは、所定加入者グループの一部である複数の加入者光インタフェースの動作を連係させられる。本方法およびシステムは、各光インタフェースからトランシーバノードへのデータ送信を許可する時間を制御するプロトコルを備えることができる。このように所定グループの光インタフェースの送信許可時間を制御することは、時分割マルチアクセス（ＴＤＭＡ）の一形式と言える。プロトコルは、ＴＤＭＡによって特定加入者グループの加入者光インタフェース間における上り送信の衝突を避けることができる。
【００１７】
本発明の前記プロトコルおよび加入者光インタフェースは、キャリア検出または衝突検出を有する従来のプロトコルおよび送信器とは異なり、同一トランシーバノードを共有する加入者グループの他の光インタフェースの送信を検出または感知するような設計ではない。すなわち本発明のプロトコルを実行するトランシーバノードは、加入者グループの加入者光インタフェースにネットワークへの情報送信を許可する期間を制御または計画する。
【００１８】
トランシーバノードは、本発明のプロトコルにより、１人以上の加入者の要求に基づき、上り帯域幅の割り当てを追加または低減できる。すなわちトランシーバノードは、加入ベースであるいは必要に応じて、加入者の上り帯域幅を監視（または管理）および調整できる。トランシーバノードは、所定増分において、加入者に上りデータ帯域幅を提供できる。例えばトランシーバノードは、特定加入者または加入者グループに１，２，５，１０，２０，５０，１００，２００，４５０メガビット／秒（Ｍｂ／ｓ）の単位で上り帯域幅を提供できる。
【００１９】
本発明のプロトコルを実行または遂行するトランシーバノードは、構成要素の１つとして光タップルーティング装置を有する。この光タップルーティング装置は、どの光タップマルチプレクサが下り電気信号を受信するのかを判断でき、複数の光タップのどれが上り光信号を発信したかを特定できる。光タップルーティング装置は、データをフォーマットし、各光タップに接続した各加入者に対してデータを送受するためのプロトコルを実行できる（後述する）。光タップルーティング装置は、加入者グループの中央制御形式を提供できる。光タップルーティング装置は、コンピュータまたはハードワイヤード装置で構成でき、それによって本発明のプロトコルを定義するプログラムを実行できる。
【００２０】
本発明のアルゴリズムは、個別のパケットではなくパケットの集合を対象にできる。本アルゴリズムは、パケットの集合に対して計算を行うことにより、実行頻度を少なくし、低性能、低価格装置での実行を可能にする。この本発明方法は、専用高速ハードウエアではなく汎用マイクロプロセッサで実行するソフトウエアで実現可能である。
【００２１】
本発明のコンピュータ実行プロトコルは、各データパケットを単一で扱う従来のトークンバケットエミュレーションとは異なり、パケットのグループまたは集合をトークンバケットエミュレーションで処理できる。トークンバケットエミュレーションは、本発明のプロトコルが帯域幅を極めて効率的に扱うことを可能にする。トークンバケットエミュレーションは、加入者グループの各加入者に帯域幅を保証できる。しかしながら特定の加入者が使用しない保証帯域幅の一部は、プロトコルが回収し、特定時点において帯域幅を必要とする他のユーザに提供できる。回収した帯域幅は、加入者グループ用に形成する帯域幅プールを介して提供できる。
【００２２】
帯域幅回収、帯域幅保証、およびトークンバケットエミュレーションは、本発明プロトコルが追跡するいくつかのパラメータの機能で構成できる。これらパラメータは、ピーク速度、持続速度、バーストサイズ、優先重み付け、および保証指示（保証指示は、加入者が常に持続速度を保証されているか否かを追跡する）である。最初の３つのパラメータ、すなわちピーク速度、持続速度、およびバーストサイズをハードウエアで追跡する従来例とは異なり、本発明はこれらパラメータを、ソフトウエアで実行可能な本発明プロトコルで監視できる。これらパラメータの全ては、ネットワークプロバイダが調整可能であり、それによって光ネットワークを様々な加入者環境に適応できる。
【００２３】
最初にパケットを受け取り、次にトークンバケットアルゴリズムを使用して前記受け取ったパケットの処理方法を決定する従来のルータとは異なり、本発明は、加入者光インタフェースからパケットグループ送出要求通知を受け取る。そして光タップルーティング装置は、トークンバケットアルゴリズムを使用し、光タップルーティング装置が受け取り可能なバイト数を加入者光インタフェースに通知する。すなわち光タップルーティング装置は、トークンバケットアルゴリズムを使用し、加入者光インタフェースが（ａ）送ろうとするパケットの全てを送れるか、または（ｂ）送ろうとするパケットの一部を送れるか、または（ｃ）送ろうとするパケットのいずれも送れないか、を決定できる。加入者光インタフェースは、送ろうとするパケットの全てを送れない場合、それらパケットを破棄するか、またはそれらを保持して再送を試みるかの決定をできる。
【００２４】
このように上りデータトラフィックは、より効率的に管理できる。上り情報は、入りデータ経路から取り出すことができる。光タップルーティング装置がパケットを受け入れないであろう時、加入者光インタフェースは、それを送らない。別の言い方をすれば、加入者光インタフェースにおけるパケットは、次の送信ウインドウ（以下ではスーパーフレームと呼ぶ）において送信するため、保持できる。パケットを保持するメモリが満杯であれば、トランシーバノードは、ユーザ装置からのパケットを受け入れない。
【００２５】
さらに光タップルーティング装置は、加入者光インタフェースがパケットを送れるか否かを決定するにあたり、送信する加入者光インタフェースからのパケットのタイプとデータ負荷とを参照するだけでなく、同一加入者グループの他の加入者光インタフェースが送ろうとしているデータ量と、各加入者光インタフェースに提供するサービスレベル（加入者がサービスに支払っている金額、あるいは管理者が定める他の基準）とを参照できる。
【００２６】
また、受け入れるパケット量の決定は、加入者光インタフェースのグループ（光タップルーティング装置へ入る共通経路を共有する）がもたらす総負荷だけでなく、光タップルーティング装置からデータサービスハブへ向かう総負荷に基づくことができる。
【００２７】
一実施例において、６つの加入者論理グループが存在でき、各グループは光タップルーティング装置へデータを送ることができる。一般に１から４のデータ経路を光タップルーティング装置からデータサービスハブへ配置できる。光タップルーティング装置は、６つの論理グループからの総負荷を予測し、全パケットを受け入れてそれらをデータサービスハブへ転送できるか否か、あるいはそれらパケットのサブセットだけを受け入れるかを決定できる。光タップルーティング装置は、全パケットを受け入れてしまうと、それら全てをデータサービスハブへ転送できない可能性がある。
【００２８】
本発明プロトコルは、加入者光インタフェースからのパケットを受け入れるか否かを決定することで、帯域幅を効率的に割り当ることができる。本発明は、ソフトウエアによって、上りトラフィックの中央制御を提供でき、加入者グループ間に帯域幅を公平に割り当てることができる。「公平」とは、数学的定義である。「公平」の数学的定義は、重み付け最大最小アルゴリズムからなることができる。このアルゴリズムは、重み係数を、準備した重みと、加入者光インタフェースグループの各加入者光インタフェースに関するバッファ占有率をローパスフィルタを通して測定したものとの積から形成できる。各加入者光インタフェース用の最大最小パラメータは、そのインタフェースの最大割り当てから形成できる。
【００２９】
最大最小による公平は、各加入者が受け入れねばならない最小値を最大にする。すなわち最大最小割り当ての結果、最小割り当てを受け取る加入者は、他の加入者がそれよりも少ない割り当てを受け取らない限り、より大きな割り当てを決して受け取れない。重み付け最大最小割り当ては、各者に相対重み付け係数を割り当てる。これは、その重み付け係数の最小値に割り当てを乗算したものを最大にし、より高い優先度を有する者が有利になるよう、最大最小割り当てを偏らせる厳密な方法を提供する。
【００３０】
発明を実施するための最良の形態
本発明は、光ネットワークに配置したハードウエア、ソフトウエア、またはそれらの組合せによって実現する。本発明は、トランシーバノードを備えることができる。このトランシーバノードは、光タップルーティング装置と、１つ以上の加入者光インタフェースから上りパケットを受信する複数の光タップマルチプレクサとを備える。本発明のプロトコルは、データパケットを１つの方法で処理する従来のトークンバケットエミュレーションとは異なり、トークンバケットエミュレーションによってデータパケットの集合を処理できる。本発明のプロトコルにより、トランシーバノードは、１つ以上の加入者の要求に基づき、上り帯域幅の割り当てを追加または低減できる。本発明は、加入ベースであるいは必要に応じて、加入者の上り帯域幅を監視および調整できる。本発明は、加入者グループの各加入者が保証帯域幅を持つことを可能にする。しかしながら本発明プロトコルは、特定加入者が使用しない保証帯域幅の大部分を回収し、特定時点において帯域幅を必要とする他の加入者に提供できる。
【００３１】
図を参照しながら本発明の態様と動作環境例とを説明する。図において同一番号は同一要素を示す。
【００３２】
図１は、本発明に基づく光ネットワーク構成例１００を示す機能ブロック図である。光ネットワーク構成例１００はデータサービスハブ１１０を備え、このデータサービスハブは１つ以上の屋外トランシーバノード１２０に接続する。トランシーバノード１２０は、光タップ１３０に接続する。「トランシーバノード」の用語は、２００１年７月５日に出願した米国同時係属出願第０９／８９９，４１０号「データサービスプロバイダと加入者との間で光信号を通信するシステムおよび方法」、および２００１年１０月４日に出願した米国同時係属出願第０９／９７１，３６３号「データサービスプロバイダと加入者との間で光信号を上りおよび下り方向に通信するシステムおよび方法」が説明するノードを参照できる。これら２出願の内容は、参照によりここに組み込む。
【００３３】
光タップ１３０は、複数の加入者光インタフェース１４０に接続できる。光ネットワーク構成例１００の各構成要素間には、光導波路１５０，１６０，１７０，１８０等がある。光導波路１５０〜１８０は矢印で示し、それら矢印の頭は光ネットワーク構成例１００の構成要素間におけるデータの流れ方向例を示す。図１は１つのトランシーバノード１２０と、１つの光タップ１３０と、１つの加入者光インタフェース１４０とのみを示すが、図２とその説明から明らかな通り、それぞれ複数のトランシーバノード１２０と光タップ１３０と加入者光インタフェース１４０とを使用しても、本発明の範囲および精神を逸脱しない。本発明の実施例の多くにおいて、一般に複数の加入者光インタフェース１４０を１つ以上の光タップ１３０に接続する。
【００３４】
トランシーバノード１２０は、加入者光インタフェース１４０を使用する１人以上の加入者からの要求に基づき、帯域幅を追加あるいは削減できる。トランシーバノード１２０は、屋外環境条件に耐えるように設計でき、撚り線に吊り下げるか、台座や穴に取り付けるように設計できる。トランシーバノードは、摂氏マイナス４０度から摂氏プラス６０度の温度範囲で動作できる。トランシーバノード１２０は、電力を消費しない受動冷却装置を用いることにより、前記温度範囲で動作できる。
【００３５】
加入者光インタフェース１４０とデータサービスハブ１１０との間に配置する従来のルータとは異なり、トランシーバノード１２０は、トランシーバノード１２０の周囲温度を制御するための能動冷却加熱装置を必要としない。本発明は、より多くの判断用電子機器を、加入者光インタフェース１４０にではなくトランシーバノード１２０に配置する。一般にこれら判断用電子機器は、本発明の加入者光インタフェース１４０に配置する電子機器に比べ、サイズが大きく、より高価である。
【００３６】
トランシーバノード１２０は、能動温度制御装置を必要としないため、小型の電子機器であり、従来ルータの環境容器よりも一般に小型である。
【００３７】
本発明の一実施例において、３本の基幹光導波路１６０，１７０，および１８０（光ファイバで構成できる）は、データサービスハブ１１０からトランシーバノード１２０まで光信号を伝送できる。なお「光導波路」の用語は、本発明において、光ファイバ、平面光案内回路、光ファイバピグテール、およびその他光導波路に適用する。
【００３８】
第１光導波路１６０は、放送映像およびその他信号を伝送できる。信号は従来のケーブルテレビフォーマットで伝送できる。このフォーマットは、放送信号を搬送波に変調し、それによってデータサービスハブ１１０内の光送信器（図示せず）を変調する。第２光導波路１７０は、目的サービスを下り方向に伝送できる。目的サービスとは、１つ以上の加入者光インタフェース１４０へ配信するデータおよび電話サービス等である。第２光導波路１７０は、加入者へ光信号を伝送することに加え、インターネットプロトコル放送パケットを伝送できる。これは当業者に明らかな通りである。
【００３９】
一実施例において、第３光導波路１８０は、トランシーバノード１２０からデータサービスハブ１１０への上りデータ信号を伝送できる。第３光導波路１８０が伝送する光信号は、１人以上の加入者から受け取るデータおよび電話サービスを含むこともできる。第２光導波路１７０と同様、第３光導波路１８０は、ＩＰ放送パケットも伝送できる。これは当業者に明らかな通りである。
【００４０】
上り第３光導波路１８０は、点線で示す。これは、それが本発明の一実施例のオプションまたは一部に過ぎないからである。すなわち第３光導波路１８０は、省略しても構わない。他の実施例において、第２光導波路１７０は、光信号を上り方向および下り方向の両方向に伝送する。これは第２光導波路１７０を示す二重矢印で表現した通りである。かかる実施例において、第２光導波路１７０は双方向に光信号を伝送するため、２本の光導波路１６０，１７０があれば、データサービスハブ１１０とトランシーバノード１２０との間で光信号を伝送できる。別の実施例（図示せず）において、単一の光導波路だけで、データサービスハブ１１０とトランシーバノード１２０との間をリンクしても良い。この単一光導波路実施例は、３つの異なる波長を上り信号および下り信号に用いることができる。あるいは１つの波長で双方向データを変調しても良い。
【００４１】
一実施例において、光タップ１３０は、８方向光スプリッタで構成できる。８方向光スプリッタからなる光タップ１３０は、下り光信号を８方向に分割し、８つの異なる加入者光インタフェース１４０にサービスを提供する。上り方向において、光タップ１３０は、８つの加入者光インタフェース１４０から受信する光信号を結合できる。
【００４２】
他の実施例において、光タップ１３０は、４方向スプリッタで構成でき、４つの加入者光インタフェース１４０にサービスを提供できる。さらに他の実施例において、光タップ１３０は、４方向スプリッタをさらに備えることができる。このスプリッタは、通過タップであり、光タップ１３０で受信する光信号の一部を抽出して内蔵の４方向スプリッタに提供すると共に、残りの光エネルギをさらに下り方向に伝送し、他の光タップまたは他の加入者光インタフェース１４０に提供する。本発明は、４方向および８方向光スプリッタに限定するものではない。４方向あるいは８方向スプリッタよりも少ないあるいは多い数の方向スプリッタも本発明範囲である。
【００４３】
図２は、光ネットワーク構成例１００を示す機能ブロック図である。この構成例は、加入者グループ２００をさらに含む。各グループは、各トランシーバノード１２０に対応する。図２は、光ネットワーク構成例１００の多様性を示す。トランシーバノード１２０と光タップ１３０との間に接続した光導波路１５０は、最小数である。図２は、加入者グループ２００の多様性も示す。これは、光タップ１３０により実現する。
【００４４】
各光タップ１３０は、光スプリッタを備えることができる。光タップ１３０は、複数の加入者光インタフェース１４０を単一の光導波路１５０に接続する。この光導波路は、トランシーバノード１２０に接続する。一実施例において、６本の光ファイバ１５０をトランシーバノード１２０に接続するように設計する。光タップ１３０を使用することにより、１６の加入者を６本の光ファイバ１５０の各々に割り当てられる。これら光ファイバは、トランシーバノード１２０に接続する。
【００４５】
他の実施例において、１２本の光ファイバ１５０をトランシーバノード１２０に接続し、８個の加入者光インタフェース１４０を１２本の光ファイバ１５０の各々に割り当てる。当業者には明らかな通り、トランシーバノード１２０と１つの加入者光インタフェース１４０との間に（光タップ１３０を介して）接続した特定の導波路１５０に割り当てる加入者光インタフェース１４０の数は、本発明の範囲および精神を逸脱することなく、変更可能である。さらに当業者には明らかな通り、特定の光ファイバケーブルに割り当てる加入者光インタフェース１４０の実際の数は、特定の光ファイバ１５０の能力に依存する。
【００４６】
加入者グループ２００に示す通り、加入者に通信サービスを提供する場合、多くの構成が可能である。例えば、光タップ１３０Ａは、加入者光インタフェース１４０Ａ１から加入者光インタフェース１４０ＡＮまでをトランシーバノード１２０に接続できる。さらに光タップ１３０Ａは、光タップ１３０ＡＮ等の他の光タップ１３０をトランシーバノード１２０に接続できる。光タップ１３０と他の光タップ１３０との組合せは、光タップ１３０と加入者光インタフェース１４０との組合せ同様、無限である。光タップ１３０により、トランシーバノード１２０における配信用光導波路１５０の接続を削減できる。さらに、加入者グループ２００にサービスを提供するファイバの総数も削減できる。
【００４７】
本発明の能動トランシーバノード１２０により、トランシーバノード１２０とデータサービスハブ１１０との間の距離は、０〜８０キロメートルの範囲にできる。しかしながら本発明は、この範囲に限定されない。当業者には明らかな通り、この範囲は、本発明の装置のいくつかを構成する各種既製構成要素の選択次第で拡大できる。
【００４８】
当業者には明らかな通り、データサービスハブ１１０とトランシーバノード１２０との間に配置する光導波路は、本発明範囲を逸脱することなく、他の構成も可能である。光導波路は双方向能力を有するため、データサービスハブ１１０とトランシーバノード１２０との間に配置する光導波路は、本発明の範囲および精神を逸脱することなく、その数および伝送方向を変更できる。
【００４９】
当業者には明らかな通り、各回線に関して光導波トランシーバ４３０とデータサービスハブ１１０とを構成する光送信器の選択は、データサービスハブ１１０とトランシーバノード１２０との間に必要な光パスの長さに関して最適化する。さらに当業者には明らかな通り、ここに記載の波長は実際的であるものの、一例に過ぎない。場合によっては、通信ウインドウを１３１０および１５５０ｎｍにおいて異なる方法で使用しても、本発明の範囲および精神を逸脱しない。さらに本発明は、１３１０および１５５０ｎｍの波長領域に限定されない。当業者には明らかな通り、光信号用のさらに短いあるいは長い波長も本発明の範囲および精神を逸脱しない。
【００５０】
図３は、本発明のトランシーバノード１２０の一例を示す機能ブロック図である。この実施例において、トランシーバノード１２０は、単方向光信号入力ポート４０５を備えることができる。このポートは、データサービスハブ１１０からの光信号を受信できる。これら信号は、第１光導波路１６０を経由したものである。単方向光信号入力ポート４０５で受信した光信号は、放送映像データからなることができる。入力ポート４０５で受信した光信号は、増幅器４１０へ伝送する。この増幅器は、例えばエルビウムドープファイバー増幅器（ＥＤＦＡ）であり、前記光信号を増幅する。増幅した光信号は、スプリッタ４１５へ送る。このスプリッタは、前記放送映像光信号をダイプレクサ４２０に分配する。これらダイプレクサは、光信号を所定加入者グループ２００へ送る設計である。
【００５１】
トランシーバノード１２０は、双方向光信号入出力ポート４２５をさらに備えることができる。このポートは、トランシーバノード１２０を第２光導波路１７０に接続する。この導波路は、データサービスハブ１１０とトランシーバノード１２０との間において双方向データフローを支援する。下り光信号は、双方向光信号入力ポート４２５を経由し、光導波トランシーバ４３０へ流れる。このトランシーバは、下り光信号を電気信号に変換する。また光導波トランシーバは、上り電気信号を光信号に変換する。光導波トランシーバ４３０は、光／電気変換器および電気／光変換器を備えることができる。別のシステム例において、光ファイバ１７０は信号を下り方向へ伝送し、光ファイバ１８０は信号を上り方向へ伝送する。
【００５２】
下りおよび上り電気信号は、光導波トランシーバ４３０と光タップルーティング装置４３５との間で送受される。光タップルーティング装置４３５は、データサービスハブ光信号とのインタフェースを管理し、各タップマルチプレクサ４４０に対しデータサービスハブ信号を転送、分割、または割り当てできる。マルチプレクサ４４０は、光信号を１つ以上の光タップ１３０と送受し、結果として１つ以上の加入者光インタフェース１４０と光信号を送受する。タップマルチプレクサ４４０は、電気領域で動作し、レーザ送信器を変調し、光信号を発生する。これら光信号は、１つ以上の光タップに結合した加入者グループに割り当てる。
【００５３】
光タップルーティング装置４３５は、利用可能な上りデータパケットが到着すると、各タップマルチプレクサ４４０から通知を受ける。光タップルーティング装置は、各タップマルチプレクサ４４０に接続し、前記上りデータパケットを受け取る。光タップルーティング装置４３５は、そのパケットを光導波トランシーバ４３０を経由してデータサービスハブ１１０へ中継する。光タップルーティング装置４３５は、全タップマルチプレクサ４４０（またはポート）からやって来る上りデータパケットの各々からソースＩＰアドレスを読み、それを対応するタップマルチプレクサ４４０に関連付けることにより、参照テーブルを構築できる。この参照テーブルは、下り経路にパケットを転送する際、利用できる。各パケットが光導波トランシーバ４３０から来ると、光タップルーティング装置４３５は、宛先ＩＰアドレス（上りパケット用ソースＩＰアドレスと同じである）を見る。光タップルーティング装置４３５は、前記参照テーブルから、どのポートが当該ＩＰアドレスに接続しているかを決定し、そのポートへ当該パケットを送る。これは、当業者には明らかな通り、標準レイヤ３ルータ機能である。
【００５４】
光タップルーティング装置４３５は、複数の加入者を１つのポートに割り当てることができる。すなわち光タップルーティング装置４３５は、１つのポートでそのポートに対応する加入者グループにサービスを提供できる。光タップ１３０は各タップマルチプレクサ４４０に結合し、割り当てられた加入者グループに下り光信号を供給できる。その加入者グループは、加入者光インタフェース１４０によって前記下り光信号を受信する。
【００５５】
すなわち光タップルーティング装置４３５は、どのタップマルチプレクサ４４０が下り電気信号を受信するかを決定できる、あるいは複数の光タップ１３０のうちどれが上り光信号（電気信号に変換される）を伝送したかを決定できる。光タップルーティング装置４３５は、データをフォーマットし、各光タップ１３０に接続した各加入者からのデータの送受信に必要なプロトコルを実行できる。光タップルーティング装置４３５は、コンピュータまたはハードワイヤード装置で構成でき、各ポートに割り当てた加入者グループとの通信用プロトコルを定義する。
【００５６】
光タップルーティング装置の各ポートは、各タップマルチプレクサ４４０に接続する。光タップルーティング装置４３５により、トランシーバノード１２０は、加入ベースで、あるいは必要に応じて、あるいは要求に基づき、加入者の帯域幅を調整できる。トランシーバノード１２０は、光タップルーティング装置４３５を介し、予め指定した増分においてデータ帯域幅を加入者に提供できる。例えばトランシーバノード１２０は、光タップルーティング装置４３５を介し、特定の加入者または加入者グループに対し、１，２，５，１０，２０，５０，１００，２００，および４５０メガビット／秒（Ｍｂ／ｓ）の単位で上りおよび下り帯域幅を提供できる。当業者には明らかな通り、他の加入者帯域幅単位を適用することも本発明の範囲を逸脱しない。
【００５７】
電気信号は、光タップルーティング装置４３５と各タップマルチプレクサ４４０との間で通信する。タップマルチプレクサ４４０は、光信号を様々な加入者グループに対して送受する。各タップマルチプレクサ４４０は、各光送信器３２５に接続する。各光送信器３２５は、ファブリペロー（Ｆ−Ｐ）レーザ、分散フィードバックレーザ（ＤＦＢ）、または面発光型レーザ（ＶＣＳＥＬ）の１つから構成できる。しかしながら他のタイプの光送信器も、本発明の範囲を逸脱することなく可能である。光送信器は、下り光信号を発生する。その信号は、加入者光インタフェース１４０へ伝送する。
【００５８】
各タップマルチプレクサ４４０は、光受信器３７０にも接続する。各光受信器３７０は、双方向スプリッタ３６０からの上り光信号を電気信号に変換できる。各光受信器３７０は、１つ以上のフォトレセプタまたはフォトダイオードから構成し、光信号を電気信号に変換できる。光送信器３２５と光受信器３７０とは、既製ハードウエアで構成して光信号を発生し受信できるため、トランシーバノード１２０は、アップグレードおよび保守を効率的に行え、極めて高いデータ速度を提供する。
【００５９】
各光送信器３２５と各光受信器３７０とは、双方向スプリッタ３６０に接続する。各双方向スプリッタ３６０は、ダイプレクサ４２０に接続する。このダイプレクサは、スプリッタ４１５から受信する単方向光信号を各光受信器３７０から受信する下り光信号に結合する。このように、放送映像サービスおよびデータサービスは、図２に示すような配信光導波路１５０等の単一光導波路によって供給できる。すなわち光信号は、各ダイプレクサ４２０から結合信号入出力ポート４４５へ結合できる。このポートは、各配信光導波路１５０に接続する。
【００６０】
従来技術とは異なり、トランシーバノード１２０は、従来のルータを使用しない。トランシーバノード１２０の構成要素は、小型電子筐体内に配置できる。例えばトランシーバノード１２０は、撚り線に吊り下げたり、台座に取り付けることができる。これは、従来のケーブルテレビ装置を「ラストマイル」内に配置したり、ネットワークの加入者近接地点に配置したりするのと同じである。なお「ラストマイル」とは、光ネットワークの加入者に接続する最後の部分を示す用語である。
【００６１】
光タップルーティング装置４３５も、従来のルータではないため、特定の温度に動作環境を維持する能動温度制御装置を必要としない。すなわちトランシーバノード１２０は、一実施例において摂氏マイナス４０度から摂氏プラス６０度の温度範囲で動作できる。
【００６２】
トランシーバノード１２０は、能動温度制御装置を備えない。このような温度装置は、トランシーバノード１２０を一定温度に保つために電力を消費する。トランシーバノード１２０は、１つ以上の受動温度制御装置４５０を備えることができる。この装置は、電力を消費しない。受動温度制御装置４５０は、１つ以上のヒートシンクまたはヒートパイプを備え、トランシーバノード１２０から熱を除去する。当業者には明らかな通り、本発明は、これら例示した受動温度制御装置に限定されない。当業者には明らかな通り、本発明は、例示した動作温度範囲に限定されない。適切な受動温度制御装置４５０により、トランシーバノード１２０の動作温度範囲は、縮小または拡大できる。
【００６３】
トランシーバノード１２０は、過酷な屋外環境条件に耐えうると共に、高速対称データ伝送を提供できる。すなわちトランシーバノード１２０は、ネットワーク加入者に対し、上りおよび下りとも同一ビットレートでの伝送を行える。これは従来ネットワークに比較すると、優れた点である。一般に従来ネットワークは、前記した通り、対称データ伝送を支援できない。さらにトランシーバノード１２０は、多数の加入者にサービスを提供できると共に、データサービスハブ１１０およびトランシーバノード１２０の両方において接続数を削減できる。
【００６４】
またトランシーバノード１２０は、効率的なアップグレードをネットワーク側からまたはデータサービスハブ１１０側から全て行うことができる。すなわち、トランシーバノード１２０を構成するハードウエアのアップグレードは、データサービスハブ１１０とトランシーバノード１２０との間の位置でおよびそれら内の位置で実施できる。すなわちトランシーバノード１２０またはデータサービスハブ１１０または両方のアップグレード中、ネットワークの加入者側（配信光導波路１５０から加入者光インタフェース１４０まで）には全く手を触れる必要がない。
【００６５】
図４は、本発明の一実施例に基づく、１本の光導波路１５０によって加入者光インタフェース１４０に接続した光タップ１３０を示す機能ブロック図である。光タップ１３０は、結合信号入出力ポート５０５から構成できる。このポートは、他の配信光導波路に接続し、この導波路はトランシーバノード１２０に接続する。前記した通り、光タップ１３０は、光スプリッタ５１０で構成できる。この光スプリッタは、４方向または８方向光スプリッタで良い。４方向または８方向分岐よりも少ないまたは多い光タップを使用しても、本発明の範囲を逸脱しない。前記光タップは、下り光信号を分岐し、各加入者光インタフェース１４０にサービスを提供できる。一実施例において、光タップ１３０は４方向光タップであり、通過タイプでも良い。この場合、下り光信号の一部を抽出あるいは分岐し、内蔵する４方向スプリッタに信号を提供し、残りの光エネルギをさらに下流の配信光導波路１５０へ転送する。
【００６６】
光タップ１３０は、効率的カプラであり、トランシーバノード１２０と各加入者光インタフェース１４０との間で光信号を通信できる。光タップ１３０は、縦列接続できる。あるいはトランシーバノード１２０から星形接続しても良い。前記した通り、光タップ１３０は、各光タップ１３０よりも下流側の他の光タップに信号を転送することもできる。
【００６７】
光タップ１３０を限定数あるいは少数の光導波路に接続することにより、どのトランシーバノード１２０においても光導波路が高密度で存在しないようにできる。すなわち一実施例において、光タップは、トランシーバノード１２０から離れた地点において、限定数の光導波路１５０に接続し、トランシーバノードにおける光導波路１５０の高密度化を避けることができる。当業者には明らかな通り、光タップ１３０はトランシーバノード１２０に内蔵しても良い。これに関する詳細は、別の実施例に基づく図１１のトランシーバノード１２０に関連して後述する。
【００６８】
加入者光インタフェース１４０は、光タップ１３０からの下り光信号を電気信号に変換する。この電気信号は、適切な通信装置によって処理可能である。加入者光インタフェース１４０は、上り電気信号を上り光信号に変換することもできる。この光信号は、配信光導波路１５０を経由し、光タップ１３０へ伝送できる。加入者光インタフェース１４０は、光ダイプレクサ５１５を備えることができる。この光ダイプレクサは、配信光導波路１５０からの下り光信号を、双方向光信号スプリッタ５２０とアナログ光受信器５２５とに分配する。光ダイプレクサ５１５は、デジタル光送信器５３０が発生する上り光信号を受信できる。デジタル光送信器５３０は、電気２値／デジタル信号を光形式に変換する。これら光信号は、データサービスハブ１１０へ伝送できる。逆にデジタル光受信器５４０は、光信号を電気２値／デジタル信号に変換する。この電気信号は、処理装置５５０によって扱える。
【００６９】
本発明は、光信号を様々な波長で伝送できる。ただしここに記載の波長領域は、実際的なものであり、実施例に過ぎない。当業者には明らかな通り、１３１０〜１５５０ｎｍ波長領域内、それ以上、あるいはそれ以下の波長も本発明の範囲を逸脱しない。
【００７０】
アナログ光受信器５２５は、下り放送光映像信号を変調無線周波テレビ信号に変換することができる。変換された信号は、変調無線周波単方向信号出力５３５から出力する。変調無線周波単方向信号出力５３５は、テレビセット（図示せず）やラジオ（図示せず）等の無線周波受信器へ供給することもできる。アナログ光受信器５２５は、アナログ変調無線周波送信およびデジタルテレビ用のデジタル変調無線周波送信も処理できる。
【００７１】
双方向光信号スプリッタ５２０は、結合光信号をそれぞれの方向へ伝送できる。すなわち光ダイプレクサ５１５から双方向光スプリッタ５２０へ入る下り光信号は、デジタル光受信器５４０へ伝送する。デジタル光送信器５３０から双方向光スプリッタへ入る上り光信号は、光ダイプレクサ５１５へ送り、そこから光タップ１３０へ送る。双方向光信号スプリッタ５２０は、デジタル光受信器５４０へ接続する。この受信器は、下りデータ光信号を電気信号に変換する。また双方向光信号スプリッタ５２０は、デジタル光送信器５３０にも接続する。この送信器は、上り電気信号を光信号に変換する。
【００７２】
デジタル光受信器５４０は、１つ以上のフォトレセプタまたはフォトダイオードで構成でき、光信号を電気信号に変換する。デジタル光送信器は、１つ以上のレーザで構成できる。このレーザは、例えばファブリペロー（Ｆ−Ｐ）レーザ、分散フィードバックレーザ、または面発光型レーザ（ＶＣＳＥＬ）である。
【００７３】
デジタル光受信器５４０とデジタル光送信器５３０とは、処理装置５５０に接続する。この処理装置は、埋め込んだアドレスに基づき当該加入者光インタフェース１４０向けのデータを選択する。処理装置５５０が扱うデータは、１つ以上の電話サービスおよびインターネットサービス等のデータサービスからなることができる。処理装置５５０は、電話入出力５５５に接続する。この入出力は、アナログインタフェースでよい。処理装置５５０は、データインタフェース５６０にも接続する。このデータインタフェースは、コンピュータ装置、セットトップボックス、ＩＳＤＮ電話、その他同様の装置へのリンクを提供できる。さらにデータインタフェース５６０は、ボイスオーバインターネットプロトコル（ＶｏＩＰ）電話やイーサネット電話へのリンクも提供できる。データインタフェース５６０は、イーサネット（１０ＢａｓｅＴ、１００ＢａｓｅＴ、ギガビット）インタフェース、ＨＰＮＡインタフェース、ユニバーサルシリアルバス（ＵＳＢ）およびＩＥＥＥ１３９４インタフェース、ＡＤＳＬインタフェース、その他同様のインタフェースでも良い。
【００７４】
図５は、本発明の一実施例に基づく、単一のスーパーフレーム５６２内における保証上り帯域幅とプールした上り帯域幅とを示すブロック図である。一般にスーパーフレーム５６２は、１期間であってその期間中に連続するイベントの全体が繰り返される。一実施例において、１スーパーフレームは、８ミリ秒の期間である。すなわち８ミリ秒毎に、トランシーバノード１２０は、所定タップマルチプレクサ４４０の全加入者１４０を巡回し、データパケットを送信する順番または機会を各加入者１４０に与える。一実施例において、１つの上りチャネルは１６の加入者１４０にサービスを提供できる。しかしながら当業者には明らかな通り、これよりも少ないまたは多い数の加入者１４０をチャネルに与えても、本発明の範囲および精神を逸脱しない。
【００７５】
フレーム５００に沿った横軸５７６は、時間を表す。図５において、各タイムスロットは、加入者光インタフェース（ＳＯＩ）が上り方向にデータパケットを送信できる期間を表す。タイムスロット５６４，５６６，５６８，５７０，５７２は、スーパーフレーム５６２の保証帯域幅５７４を形成する。図５に示す通り、帯域幅は単位時間に送信可能なデータビット数からなる。代表的にこれはデータ速度の関数であり、許容時間でもある。帯域幅は、１秒あたりのメガビット数（百万ビット／秒、ＭＢｐｓ）で表すことも多い。
【００７６】
図５に示す通り、各加入者光インタフェース１４０は、割り当てタイムスロット５６４，５６６，５６８，５７０，５７２を有し、そのタイムスロットにおいて上り方向に光ネットワーク１００を介して情報を送信する。例えば第１タイムスロット５６４に割り当てた第１加入者光インタフェースは最初に送信でき、第２加入者光インタフェースは、タイムスロット５６４の期間終了後に、第２タイムスロット５６６において送信できる。各加入者光インタフェースは、割り当てタイムスロットに送信を終えると、プール帯域幅５７８においてさらに送信できる。一般に各加入者光インタフェース１４０は、プール帯域幅５７８の帯域幅を要求し、本発明のプロトコルに許可を求めねばならない。このプロトコルは、基本的にトランシーバノード１２０において実行する。
【００７７】
いずれかの加入者光インタフェース１４０がプール帯域幅５７８を使っていなければ、いずれの加入者光インタフェースでもそれを使って良い。例えば加入者光インタフェース１４０は、まず保証帯域幅を使い、そして保証帯域幅以上にデータを追加して送信したい場合、プール帯域幅５７８から割り当てられるであろう追加時間を要求できる。
【００７８】
図６は、第２実施例を示し、１つのスーパーフレーム内においてどのように上り帯域幅を各帯域幅に分割するかを示す。一般にスーパーフレーム６００は、連続するイベントの全体を繰り返す期間からなる。一実施例において、スーパーフレームは、８ミリ秒の期間からなる。すなわちトランシーバノードは、８ミリ秒毎に所定チャネル上の全加入者を巡回し、各加入者にデータパケット送信の順番または機会を与えることができる。一実施例において、各上りチャネルは１６加入者にサービスを提供できる。しかしながら当業者には明らかな通り、これよりも少ないまたは多い数の加入者をチャネルに加えても、本発明の範囲および精神を逸脱しない。
【００７９】
図６は、左から右に時間が経過する。各タイムスロットは、特定の加入者光インタフェース１４０（ＳＯＩ）が上り方向にデータパケットを送信できる期間を表す。例えばタイムスロット０を割り当てた第１加入者光インタフェースは、そのタイムスロット内に送信できる。第２加入者光インタフェースは、第１タイムスロットの後の第２タイムスロット内で送信できる。
【００８０】
各タイムスロットの期間は、トランシーバノード１２０が制御する。トランシーバノードは、各加入者に保証帯域幅を提供するすると共に、現スーパーフレーム期間中にその加入者がプール帯域幅を利用できるように各タイムスロットを制御する。通常、全タイムスロットの合計は、スーパーフレーム期間より少ないか等しくなければならない。準備されたデータを送信するためにスーパーフレームの一部しか使用しない場合、スーパーフレームの開始側にタイムスロットを集める。するとスーパーフレームの末尾近くに何も送信しない時間ができる。
【００８１】
図６の最終タイムスロットは、特別のタイムスロットであり、送信しようとする未知の加入者光インタフェース用に確保してあり、トランシーバノードがその加入者光インタフェースを発見できるようにしてある。トランシーバノードおよび未知の加入者光インタフェースは、これら２つのシステムの相対的タイミングに関する範囲情報等のパラメータを待たないため、前記特別の発見用タイムスロットは、広範囲の相対的タイミングオフセットをカバーするよう、十分な期間を持たねばならない。本発明の一実施例において、最低発見スロットタイムは、１８０マイクロ秒である。
【００８２】
前記発見用タイムスロットは、全てのスーパーフレームが必要とするわけではない。本発明の一実施例において、トランシーバノードは、約１秒毎または１２５スーパーフレーム毎に１つの発見用タイムスロットを配置する。
【００８３】
図６は、隣接タイムスロット間に設けたガード帯域または時間をさらに示す。ガード帯域は、第１加入者光インタフェース１４０のレーザがその出力をゼロに低減するための十分な時間と、第２加入者光インタフェース１４０のレーザが第１のものと干渉せずに最大動作出力に到達する時間とを提供する。さらにガード帯域は、タップマルチプレクサ４４０が最初の加入者光インタフェース１４０のクロックをロック（同期）するための時間を含む。図示のガード時間２μｓは一例である。ガード帯域の正確な時間は、デジタル光送信器５３０の遷移時間とタップマルチプレクサ４４０のクロック獲得時間とに依存する。
【００８４】
ガード時間の存在は一般的だが、トランシーバノードにおいて２つのレーザ光受信器を共有する場合、ガード時間は短くて良い。この場合、タイムスロットを終了しようとする加入者光インタフェース１４０とタイムスロットを開始しようとする加入者光インタフェース１４０とが異なる光受信器に信号を送るなら（すなわちスイッチを切り換えて開始加入者光インタフェース１４０からの信号を受信するなら）、開始加入者光インタフェースの光送信器は、終了加入者光インタフェースの送信器をオフする前に、オンしても構わない。そして終了加入者光インタフェースの送信器は、前記スイッチを切り換えてからオフしても構わない。このような動作は、ガード時間を幾分か節約できる。しかしながらいくらかのガード時間を残し、その間に開始加入者光インタフェース１４０は、「ならしシーケンス」を送信し、タップマルチプレクサのクロックを送信器のクロックにロック（同期）する。これは当業者に明らかな通り、共通の要件である。
【００８５】
図７は、各加入者光インタフェース１４０による割り当てタイムスロットの利用方法を示す。図において、加入者光インタフェース１４０は、まず加入者光インタフェース状態メッセージを送信し、それに続けてゼロ以上のデータメッセージを送信する。データメッセージの数は、割り当てタイムスロットの期間によってのみ制限を受ける。すなわち全データメッセージの送信は、タイムスロットが終了するまでに完了しなければならない。各メッセージ（状態およびデータのいずれも）は、標準イーサネットフレーム（図８に示す）としてフォーマットし、各フレームは標準イーサネットフレーム間ギャップ（例えば１Ｇｂｉｔ／ｓにおいて９６ナノ秒）によって分離する。このフレーム間ギャップは、当業者に明らかな通り、受信器がイーサネットメッセージの開始を識別する役に立つ。
【００８６】
【表１】
2004535717.tif 000003
加入者光インタフェース状態メッセージは、標準イーサネットフレームとしてもフォーマットする。そのペイロードは、タイムスロットの開始における加入者光インタフェースの上り送信待ち行列に格納したバイト数の計数からなることができる。この情報は、以下に示すように、当該加入者光インタフェースが後のスーパーフレームにおいて送信のために取得する時間を計算するために使用する。表１は、加入者光インタフェース状態メッセージの一例を示す。
【００８７】
１加入者光インタフェース（ＳＯＩ）１４０からの１タイムスロットは、スーパーフレームの大部分を占めても良いし、その小さな部分を占めても良い。１つの加入者光インタフェース１４０だけが意味のある送信データを有する時、スーパーフレームのほぼ全てをそれに割り当てる。好適実施例において、各加入者光インタフェースは、その加入者光インタフェース状態メッセージ７１０を送信するための最小時間を有する。この最小時間は、例えば２５６ｋｂのデータを送信する場合、２５６μｓである。例外はタイムスロット１６，６５０であり、これはより短い。その理由は、小さなメッセージだけを送る必要があるからである。これらは例に過ぎず、本発明は、より長いまたはより短い最小タイムスロットを用いることができる。
【００８８】
図８は、タイムスロット例８００の内容を示す。当業者には明らかな通り、これは標準イーサネットパケットであるが、本発明はイーサネットパケットに限定されない。タイムスロット例８００は、プリアンブル８１０を有し、そのサイズは例えば８バイトである。タイムスロット８００は、宛先媒体アクセス制御メッセージ８１５をさらに備えても良い。これは例えば６バイト長である。タイムスロット８００は、発信元媒体アクセス制御メッセージ８２０をさらに備えても良い。これは例えば６バイトのサイズである。発信元媒体アクセス制御メッセージ８２０に隣接するのは、タイプ／長さ識別子Ｔ８２５である。これは当業者に明らかな通りである。
【００８９】
Ｔ８２５に隣接するのは、メッセージデータ８３０である。これは例えば４６〜１５００バイトの長さを持つ。メッセージデータ８３０に隣接するのは、ＦＣＳ８３５である。このＦＣＳは、フレームチェックシーケンスであり、イーサネットの標準機能であり、パケット内のデータの完全性を検査する。これは当業者に明らかな通りである。ＦＣＳメッセージ８４０は、例えば４バイト長である。当業者には明らかな通り、本発明はこれら一例としての長さに制限されない。すなわち、より短いまたは長いデータメッセージも本発明の範囲を逸脱しない。
【００９０】
図９は、本発明に基づくトランシーバノード１２０が処理可能な複数のスーパーフレーム例９１０，９１５，９２０を示す。図９は、加入者光インタフェース１４０が帯域幅の必要をトランシーバノード１２０に通知する方法、およびトランシーバノード１２０が加入者光インタフェース１４０にデータ送信を許可する方法を示す。トランシーバノード１２０内において、光タップルーティング装置４３５は、複数のタップマルチプレクサ４４０と共働し、トラフィック管理に必要なインテリジェント動作を行う。スーパーフレームｊ−２９１０において、加入者光インタフェースは、資源予約要求を行える。
【００９１】
スーパーフレームｊ−２９１０および予約収集遅延（ＲＣＤ）９２５の完了後、予約要求の完全セットが光タップルーティング装置４３５に対して利用可能となる。ＲＣＤ９２５は、トランシーバノード１２０における単方向伝送遅延およびその他遅延を含む。一般に光タップルーティング装置４３５は、スーパーフレームｊ９２０用タイムスロット割り当ての計算を当該スーパーフレームの開始前に完了しなければならない。その時、全加入者光インタフェース１４０に割り当てを通信するための十分な時間を残さねばならない。
【００９２】
一般に予約送信遅延（ＲＴＤ）９３５は、全加入者光インタフェース１４０に割り当てを通信するために必要な残り時間からなる。それは、光タップルーティング装置４３５内のセットアップ時間と、現下りメッセージ（セットアップデータを送信できるまでに完成しなければならない）の最悪送信遅延と、単方向伝送遅延と、加入者光インタフェース１４０における受信および解釈遅延とを含むことができる。
【００９３】
ＲＣＤ９２５とＲＴＤ９３５との間には、スーパーフレームｊ９２０のスロット割り当てを計算するための実際処理時間９３０がある。この時間中に、光タップルーティング装置４３５は、スーパーフレームｊ９２０のデータ送信配分に必要な全ての計算を行わねばならない。一般にＲＣＤ９２５と計算時間９３０とＲＴＤ９３５とは、スーパーフレームｊ−１９１５中に実行する。スーパーフレームｊ９２０中に、データを上り方向に送信する。この送信は、スーパーフレームｊ−２９１０に先行するスーパーフレームでなされた要求に基づく。そのスーパーフレームを図示したとすれば、図９のスーパーフレームｊ−２９１０の左側に来る。
【００９４】
図９に示す処理は、連続処理またはスライド処理と見なせる。すなわち各フレームにおいてデータを送信し、送信スロットの要求を行い、要求したスロットは将来のスーパーフレームで与えられる（あるいは、時間の利用可能性によっては、与えられない）。要求発生時間（スーパーフレーム９１０中）と付与時間（スーパーフレーム９２０中に起動）との間には、一般に少なくとも１つのスーパーフレーム９１５を介在させる必要がある。この間に、光タップルーティング装置４３５は、全要求を集め、どのように配分するかを決め、各加入者光インタフェース１４０に適切な命令を送る。しかしながら介在させるスーパーフレーム９１５中には、以前の要求、決定、付与サイクルに基づき、上りデータを送信する。
【００９５】
図１０は、複数のスーパーフレーム１０１０，１０１５，１０２０，１０２５を示す。これらは、一例として長さτ（タウ）を有する。本図は、パケット送信における最大遅延を示すためにある。この遅延は、どのようなメッセージを送ることができるかを決定するための方法に起因する。この図は、最大遅延の一例として、パケットが加入者光インタフェース１４０に入る時間から光タップルーティング装置４３５に到着する時間までに遭遇する最大遅延を示す。このパケットは、本システム例において、光タップルーティング装置４３５から８０２．３ｚ規格に基づく標準ギガビットイーサネットプロトコルにより処理する。しかしながら本発明は、光タップルーティング装置４３５から上り方向に標準ルータに向かってイーサネットプロトコルを用いてパケットを処理することに限定されない。ＳＯＮＥＴ等、他の既知プロトコルをこの処理段階に用いても良い。
【００９６】
図９に関連して説明した手順の結果、加入者光インタフェース１４０が資源の必要性を認識した時からそれら資源が利用可能になる時間までの遅延は、一般に最小になる。図１０が示す通り、この遅延の最悪値は、スーパーフレーム長の約４倍であり、スーパーフレーム長は例えば本例において８ｍｓである。従って本システム例において、パケットの遅延は約３２ｍｓである。この最悪遅延は、図１０の状況が発生する場合に発生する。
【００９７】
本例において、トラフィック１０３５が加入者光インタフェース１４０に到着するのは、加入者光インタフェース１４０がそのデータをスーパーフレームｊ−３１０１０へ送信した直後である。加入者光インタフェース１４０は、スーパーフレームｊ−２１０１５内のタイムスロット１０４０まで、送信しようとするトラフィック１０３５のタイムスロットを要求できない。
【００９８】
図９に示す通り、パケットはスーパーフレームｊ１０２５まで遅れ、そこで送信される。一般にトラフィック１０３５を有する加入者光インタフェース１４０は、各スーパーフレーム中の同様時点において送信を行う。しかしながら他の加入者光インタフェース１４０が要求を行い、スーパーフレームｊ１０２５中の早い時点で非常に長いタイムスロットを与えられる可能性がある。この場合、トラフィック１０３５は、スーパーフレームｊ１０２５の終了間近まで送信されない。図１０に明らかな通り、トラフィック１０３５の総遅延は、待ち行列遅延１０５５に示すように、４つのスーパーフレームよりわずかに短い。総遅延は、トラフィック１０３５が加入者光インタフェースに到着してから、それがトランシーバノード１２０に完全に送信されるまでであり、一般に総加入者光インタフェース遅延１０６５である。
【００９９】
図９で説明した通り、図９に示す処理は、「スライド」処理であり、同一イベントが各スーパーフレームで発生する。このため、前記トラフィック１０３５はスーパーフレーム１０１５および１０２０中において送信されないが、他のデータはこれらの時間において処理される。当業者には明らかな通り、図１０の例は最悪遅延であり、平均遅延はもっと小さい。
【０１００】
図１１は、光ネットワークの加入者を発信元とする上り通信を処理する方法の一例を示す。この上り通信は、当該光ネットワークのデータサービスハブ１１０への送信である。基本的に図１１は、トランシーバノード１２０特に光タップルーティング装置４３５が行う処理の全体を示す。
【０１０１】
以下のフローチャート説明は、おおむね従来のコンピュータ要素による処理および動作の記号表現で行う。コンピュータ要素とは、処理装置（プロセッサ）、記憶装置、接続した表示装置、および入力装置等である。これら処理および動作は、混成分散コンピューティング環境における従来のコンピュータ要素を使用しても良い。例えば遠隔ファイルサーバ、コンピュータサーバ、記憶装置等を使用できる。これら従来の分散コンピューティング要素の各々は、処理装置から通信ネットワークを介してアクセス可能である。
【０１０２】
以下の処理および動作は、処理装置による信号処理と、１つ以上の記憶装置に格納したデータ構造内での信号維持とを含む。本説明において、処理とは、一般に所望結果に導くための一連のコンピュータ実行ステップである。一般にこれらステップは、物理量の物理的処理を必要とする。通常、これら量は、電気信号、磁気信号、または光信号の形態を取るが、必ずしもそうとは限らない。これら信号は、記憶、転送、結合、比較、処理等が可能である。当業者には明らかな通り、これら信号の表現として、ビット、バイト、ワード、情報、要素、記号、文字、数字、点、データ、入力、オブジェクト、画像、ファイル等の用語を用いる。これらおよび同様の用語は、コンピュータ動作に関する適切な物理量に関連付けられる。またこれら用語は、コンピュータ動作内および動作中において存在する物理量に従来から適用している単なるラベルに過ぎない。
【０１０３】
コンピュータ内での処理は、生成、追加、計算、比較、移動、受け取り、決定、識別、格納、ロード、実行等の用語を用いて参照することが多い。これら処理は、人間のオペレータが手動で行う動作に関連することが多い。本明細書に記載の動作は、コンピュータと対話する人間のオペレータまたはユーザが与える様々な入力に関連した機械動作であっても良い。
【０１０４】
ここに記載のプログラム、処理、方法等は、特定のコンピュータまたは装置に関係あるいは限定するものではない。本開示に基づくことにより、様々な汎用機械を以下に説明する処理に使用できる。
【０１０５】
図１１〜１６に示す論理流れ図は、中核論理または最高位処理であり、繰り返し実行できる。図１１〜１６に示す論理流れ図は、図１〜５に示したソフトウエア要素またはハードウエア要素または両方の初期化の後、開始する。
【０１０６】
例えばオブジェクト指向プログラミング環境において、図１１〜１６に示す各ステップの実行に使用可能なソフトウエア要素、ソフトウエアオブジェクト、またはハードウエアは、初期化または作成する。従って当業者には明らかな通り、図１〜５で説明したソフトウエアオブジェクトまたはハードウエアの初期化に関するいくつかのステップは、示さない。
【０１０７】
本発明は、コンピュータプログラム、またはハードウエア、または両者の組合せで構成し、以下に説明し添付フローチャートに示す各機能を実施する。しかしながら本発明をコンピュータプログラミングまたはハードウエア設計において実施する場合、多くの様々な方法が可能である。従って本発明は、特定セットのコンピュータプログラム命令に限定されない。熟練したプログラマであれば、例えば本明細書のフローチャートおよび関連説明に基づき、コンピュータプログラムを書き、あるいは適切なハードウエア回路を見つけ、開示した本発明を容易に実施できるであろう。従って特定セットのプログラムコード命令や詳細ハードウエア装置の開示は、本発明の作成方法や使用方法を適切に理解するために、必要ではなかろう。処理の流れを示す図面を参照しながら、請求の範囲に記載したコンピュータ実行処理による本発明機能を詳細に説明する。
【０１０８】
以下に説明する処理および処理の流れにおいて、記述通りに本発明を機能させるには、あるステップを他のステップに先行させねばならない。しかしながら本発明は、本発明機能に変更を生じない限り、記述のステップ順序に限定されない。すなわちあるステップを他のステップの前あるいは後に実行しても、本発明の範囲および精神を逸脱しない。
【０１０９】
再び図２を簡単に参照すると、１つのトランシーバノード１２０は、光タップ１３０を介して複数の加入者光インタフェース１４０にサービスを提供できる。図３は、トランシーバノード１２０の詳細を示す。１つの光タップルーティング装置４３５は、複数のタップマルチプレクサ４４０と共働する。各タップマルチプレクサ４４０は、複数の加入者光インタフェース１４０に接続する。各タップマルチプレクサ４４０は、図１１の処理を実行できる。図１１は２つの似た処理を示すが、６つあるいはそれ以上の処理を平行同時実行しても良い。以下においては、複数処理の１つだけを図１１を参照して詳細に説明する。
【０１１０】
図１１のステップ１２０５は、上りデータパケットを処理する方法の第１ステップである。ステップ１２０５において、各スーパーフレーム内では、各加入者光インタフェース１４０が、状態メッセージを送る。このメッセージは、当該加入者光インタフェース１４０がそのバッファに持っている送信すべきデータ量を示す。このデータ量は、瞬時待ち行列サイズと呼ぶ。加入者光インタフェースは、状態メッセージを送信した後、そのスーパーフレーム内で許可された量のデータを送る（本フローチャートには図示せず）。一実施例において、各加入者光インタフェースは、１スーパーフレームにおいて例えば１度だけ送信を行う。加入者光インタフェースは、その送信時間中、まず状態メッセージを送信し、次にＴｍｉｎ（例えば通話またはＤＳＩチャネル）用のトラフィックを送信し、次に他の許可された全パケットを送信する。
【０１１１】
ステップ１２０５において、第１加入者光インタフェース１４０は、状態メッセージを送り、次にデータを送る。ステップ１２１０において、タップマルチプレクサ４４０は、状態メッセージをまだ送っていない別の加入者光インタフェース１４０があるか否かを決定する。現在のスーパーフレームの間に全メッセージを受信できなければ、処理はステップ１２０５へ戻り、別の加入者光インタフェース１４０からの状態メッセージを待つ。すなわちタップマルチプレクサ４４０は、一般に次の加入者光インタフェースがその状態メッセージを送信するまでそれを受信できないため、それを待つ。この処理は、図９のスーパーフレームｊ−２９１０中に発生する。
【０１１２】
全メッセージを受信すると、処理はステップ１２１５へ進み、トランシーバノードは、全加入者光インタフェースが状態メッセージにおいて報告した瞬時待ち行列サイズ等の予約情報を処理する。予約情報は、タップマルチプレクサ４４０に特定の加入者光インタフェースがその待ち行列内に送信すべく持っているデータ量を知らせる。この情報は、スーパーフレーム内において当該加入者光インタフェースに割り当てる時間を決めるために使用する。これは図９のＲＣＤ時間９２５中に発生する。
【０１１３】
ルーチン１２２０は、必要なデータが全て集まると、上りデータ管理の多くを実行できる。ルーチン１２２０は、エミュレートしたトークンバケットアルゴリズムからなることができる。このアルゴリズムは、複数の加入者光インタフェース１４０の上りデータ送信を制御できる。このルーティン１２２０は、トークンバケットアルゴリズムではあるが、従来のトークンバケットとは少し異なった動作を行う。これの詳細は後述する。トークンバケットアルゴリズムは、当業者に良く知られている。かかるバケットアルゴリズムを説明した資料の１つは、シスコシステムズ社が発行した「監視および整形の概要」ＱＣ８７〜ＱＣ９８ページである。バケットアルゴリズムを説明した他の刊行物は、次の白書である。「サービスソリューションのシスコＩＯＳ（登録商標）ソフトウエア品質」、シスコシステムズ社発行、著作権１９９８年。これら両資料の全内容は、参照によりここに組み込む。
【０１１４】
ルーチン１２２０が終了すると、次のスーパーフレームにおいて各加入者光インタフェース１４０がいつおよびどれくらい長く送信するかが決定されている。ステップ１２２５は、この情報を下り方向に加入者光インタフェース１４０へ送信する。これは図９のＲＴＤ時間９３５に発生する。
【０１１５】
ステップ１２３０は、図９のスーパーフレームｊ９２０中に、ルーチン１２２０がタイムスロットを割り当てたデータを上り方向へ送信する。各タップマルチプレクサ４４０が実行するステップ１２０５〜１２３０の連鎖またはグループの並行処理によりデータが準備され、このデータはステップ１２３５において上り方向にデータサービスハブ１１０へ送る。
【０１１６】
図１２は、ルーチン１２２０の詳細を示す。ルーチン１２２０の処理は、ステップ１３０５で始まる。それに続くステップは、各タップマルチプレクサ４４０に接続した各加入者光インタフェース１４０についてそれぞれ実行する。ステップ１３１０は、待ち行列サイズすなわち各加入者光インタフェース１４０ｎが送信すべきデータ量を評価する。（加入者光インタフェース１４０の添字ｎは、複数の加入者光インタフェース１４０のいずれか１つを指示するために使用する。
）
決定ステップ１３１０は、その時点において加入者光インタフェース１４０ｎが活性であるか否かを決定する。決定ステップ１３１０が肯定であれば、その加入者光インタフェースに、データ上り送信時間を割り当てる。しかしながらステップ１３１０が否定であれば、当該加入者光インタフェース１４０は、いくつかの連続するスーパーフレームについて非活性にとどまる。そしてこの加入者光インタフェース１４０の帯域幅を取り上げ、その帯域幅を活性加入者光インタフェース１４０に与えることができる。本発明において、各加入者光インタフェース１４０に最低帯域幅を確保し、いくらかのハウスキーピング機能を実行できるようにする。これらハウスキーピング機能は、加入者光インタフェース１４０の内部動作を監視すること、および加入者光インタフェース１４０が送信すべきデータを持ったら即座にそれを知ることを含む。現在の加入者光インタフェース１４０ｎが活性か否かの決定は、次のいくつかのステップで行う。
【０１１７】
一般に各加入者光インタフェース１４０には活性カウンタを設ける。最初このカウンタは、ある最大値に設定する。この最大値は、ネットワークサービスプロバイダまたは加入者光インタフェース１４０の製造者が決定する。最大値を例えば５に設定した場合、加入者光インタフェース１４０が送信すべきトラフィックを５連続スーパーフレームについて有さなければ、その加入者光インタフェースは非活性と見なす。
【０１１８】
またステップ１３１０は、現在の加入者光インタフェース１４０ｎの待ち行列サイズが最低閾値を超えているか否かを決定する。この最低閾値は、ハウスキーピングトラフィックに対応する。決定ステップ１３１０が否定であれば、Ｎｏをたどってステップ１３２０へ進み、活性カウントを減分する。活性カウンタがゼロになれば、評価対象の当該加入者光インタフェースから帯域幅を取り上げ、他の加入者光インタフェース１４０にそれを割り当てられる。決定ステップ１３１０が肯定であれば、最低待ち行列サイズＱｍｉｎを超えるデータが存在し、Ｙｅｓをたどってステップ１３１５へ進み、活性カウンタを最大値にリセットする。
【０１１９】
ルーチン１３２５は、提供負荷（一般に現在のスーパーフレームｊ−１で送信するより少ない待ち行列サイズに等しい）を時間領域にフィルタする。ルーチン１３２５におけるこのフィルタ機能の目的は、システムが負荷サイズの瞬時的な増加または減少に対し、過剰に反応することを避けることである。この過剰反応に関連する問題点は、当業者に明らかな通りである。ルーチン１３２５の詳細は、図１３を参照して後述する。
【０１２０】
次にルーチン１３３０は、加入者光インタフェース１４０ｎ用のエミュレートしたトークンバケットアルゴリズムにおけるトークン数を更新する。ルーチン１３３０の詳細は、図１４を参照して後述する。更新したトークン数は、ルーチン１３３５で使用し、タイムスロットの最大長Ｔｍａｘｎを決定する。この最大長は、加入者光インタフェース１４０ｎに許可するデータ送信量である。ルーチン１３３５の詳細は、図１５を参照して後述する。
【０１２１】
最小タイムスロットＴｍｉｎｎは、加入者光インタフェース１４０ｎが送信できる最小時間であり、決定ステップ１３４０において決定する。決定ステップ１３４０が否定であれば、前記活性カウンタはゼロになっており、Ｎｏをたどってステップ１３５０へ進み、加入者光インタフェース１４０ｎは非活性であると見なす。次に加入者光インタフェース１４０ｎに最小タイムスロットを割り当てる。この最小タイムスロットは、ハウスキーピング機能を収容するためにちょうどの大きさである。
【０１２２】
加入者光インタフェース１４０の活性カウンタがゼロより大きければ、あるいは使用するかしないかに関わらず（ＤＳ１回路が提供されているかいないかに関わらず）常に利用可能な持続速度が加入者光インタフェース１４０ｎに与えられていれば、Ｙｅｓをたどってステップ１３４５へ進む。当業者には明らかな通り、ＤＳ１回路は、ＰＢＸ（局内電話交換）等のデータを搬送する業務で使うことが多い。すなわちそのユーザはデータを散発的にしか発生しないが、そのデータは最小の遅延で送信処理せねばならない。この範疇に入るのは、例えば通話である。
【０１２３】
前記した通り、これら２つの条件のいずれかが存在する時、Ｙｅｓをたどってステップ１３４５へ進み、当該加入者光インタフェース１４０のＴｍｉｎｎに適切な値を割り当てる。この適切な値は、例えば加入条件に基づきまたは加入者が要求したサービスレベルに基づき、サービスを確立または変更した時に決定する。
【０１２４】
決定ステップ１３５５は、現在のスーパーフレームにおいて全加入者光インタフェース１４０を考慮あるいは処理したか否かを決定する。決定ステップ１３３５が否定であれば、Ｎｏをたどってステップ１３１０へ戻り、次の加入者光インタフェース１４０のデータを処理する。全加入者光インタフェース１４０を処理していれば、Ｙｅｓをたどってステップ１３６０へ進み、Ｔｍａｘの昇順に基づき加入者光インタフェース１４０を並べる、あるいは分類する。この分類は、次の計算処理における加入者光インタフェースの処理順序を決定するが、送信順序には影響を与えない。
【０１２５】
ステップ１３６０が加入者光インタフェース１４０を整列すると、ルーチン１３６５は、実際の送信時間を計算する。これの詳細は、図１６を参照して後述する。ルーチン１３６５が送信時間を計算すると、トークンバケットエミュレーションは終了し、処理はステップ１２２５へ戻る。
【０１２６】
図１３は、提供負荷を更新するルーチン１３２５を示す。図１３は、フィルタ機能を示しており、この機能は提供負荷または待ち行列サイズの変動を低減する。このフィルタリングは、当業者に明らかな通り、通信システムがトラフィックの急激な増加または減少に過剰反応することを防止し、それによって通信システムの能力を向上させる。このフィルタは、以前の負荷（それ自体、本ルーチンの出力である）の大部分と、現在評価中のスーパーフレーム用に存在する負荷の一部とを使用し、平均負荷を決定する。
【０１２７】
ステップ１４１０は、平均負荷の直前値に分数ｆを乗算する。分数ｆには多くの値を使用でき、それら全てが本発明の範囲内である。特に効果的な値の例は、１６分の１５（１５／１６）である。次にステップ１４１５は、加入者光インタフェース１４０ｎの瞬時負荷を計算する。この負荷は、加入者光インタフェース１４０ｎが最後の報告時間（スーパーフレームｊ−２９１０内）で報告した現在の瞬時待ち行列サイズから、現在のスーパーフレームｊ−１９１５中に送信する実際のデータ量を減じたものである。この値を計算できる理由は、送信時間割り当て（現在のスーパーフレームｊ−１９１５で使用する）をすでに加入者光インタフェース１４０ｎへ送っているからである。
【０１２８】
ステップ１４２０は、この最新の計算結果に分数（１−ｆ）を乗算する。ステップ１４２５は、ステップ１４１０と１４２０の計算結果を加算する。このステップ１４２５の値は、新しい提供負荷Ｌとなり、将来の計算に使用する。ステップ１４３０は、この値Ｌを格納する。この値は、加入者光インタフェース１４０ｎが次回このサブルーチンに入った時、ステップ１４１０で使用する。当該サブルーチンはステップ１４３５で終了し、処理は図１２のルーチン１３３０へ戻る。
【０１２９】
図１４は、トークンバケット更新ルーチン１３３０の詳細を示す。この更新機能は、第１ステップ１５０５で始まる。ステップ１５１０は、加入者光インタフェース１４０ｎのトークンバケットにトークンを追加する。この追加するトークンは、現在の加入者光インタフェース１４０ｎの持続速度にスーパーフレームの期間を乗算したものに等しい。例えば、許可持続速度が１０Ｍｂ／ｓでありスーパーフレームの期間が８ｍｓであれば、追加するトークンの数は、１０Ｍｂ／ｓに８ｍｓを掛け８０，０００ビットとなる。これは、１スーパーフレームにおいて通常送信できるビット数を表す。ただし、加入者光インタフェースがそれらデータを送信すべく持っており、送信許可量を変更する要素が何もないことが前提である。
【０１３０】
ステップ１５１５は、前のスーパーフレームで送信したデータ量に対応するビット数を減算し、その時点で送信した量を考慮する。決定ステップ１５２０は、トークンバケットのトークンが現在の加入者光インタフェース１４０のバースト限度より多いか否かを決定する。決定ステップ１５２０は、前のスーパーフレームにおける送信が少なければ、肯定である。バケット内に余剰トークンを残すことが許可されていれば、加入者光インタフェース１４０は、支払ったサービスレベルで許可された以上のデータを送信できる。
【０１３１】
トークンの量がバースト限度よりも多ければ、決定ステップ１５２０は肯定となり、Ｙｅｓをたどってステップ１５２５へ進み、余剰トークンを取り去り、バケット内のトークン量をバースト限度まで低減する。決定ステップ１５２０が否定であれば、Ｎｏをたどってステップ１５３０へ進み、サブルーチンは終了する。
【０１３２】
ルーチン１３３５は別のサブ処理であり、処理するデータ量を左右する。図１５は、このルーチン１３３５を詳細に示す。ルーチン１３３５は、加入者光インタフェース１４０が送信しようとしている速度が許可されたピーク速度を超えているか否かを決定する。ステップ１６１０は、加入者光インタフェース１４０ｎに付与される最大タイムスロットＴｍａｘｎを、加入者光インタフェース１４０ｎの持続速度にスーパーフレーム期間を乗算し（許可された持続速度において加入者光インタフェース１４０が送信できるビット数を計算するため）、それに現在のバケット割り当てを加えたものにまず設定する。
【０１３３】
決定ステップ１６１５は、その値が許可されたピーク速度にスーパーフレーム期間を乗算したものを超えるか否かを決定する。決定ステップ１６１５が肯定であれば、Ｙｅｓをたどってステップ１６２０へ進み、Ｔｍａｘｎの値を変更し、許可されたピーク速度（これにスーパーフレーム期間を乗算したもの）に等しくする。ステップ１６２０の後、アルゴリズムはステップ１６２５で終了し、処理は元へ戻る。決定ステップ１６１５が否定であれば、ステップ１６１０で計算したＴｍａｘｎの値はピーク速度にスーパーフレーム期間を乗算したものより低く、Ｎｏをたどってステップ１６２５へ進み、アルゴリズムは終了する。そして処理は図１２の決定ステップ１３４０へ戻る。
【０１３４】
図１６は、ルーチン１３６５を説明する。このルーチンにおいて、最大最小アルゴリズムは、各加入者光インタフェース１４０が次のフレームで送信許可される時間量を最終的に計算する。ステップ１７０５は、ルーチン１３６５の第１ステップである。ステップ１７１０は、全加入者光インタフェース１４０のＴｍａｘｎを加算して合計Ｔｍａｘを計算する。これは、全加入者光インタフェース１４０が要求し権利を有する送信時間量を表す。加入者光インタフェース１４０は、この送信時間が利用可能送信時間を超えていなければそれを受け取る。
【０１３５】
どれくらいの送信時間が利用可能であるかを決定するため、ステップ１７１５は、ステップ１３４５またはステップ１３５０からの全加入者光インタフェース１４０の合計最小送信時間Ｔｍｉｎをスーパーフレーム長から減算する。得られる差は、全加入者光インタフェース１４０に必須データの送信を許可した後に残る時間である。（これら計算を使用して新しい加入者光インタフェース１４０を次のスーパーフレームにおいて見つける場合、かかる発見用タイムスロットの時間もステップ１７１５において減算する必要がある。）
次に続く各ステップは、各加入者光インタフェース１４０に最小送信時間Ｔｍｉｎを割り当て必要に応じて発見時間を割り当てた後、スーパーフレーム内で利用可能な送信時間を配分する。ステップ１７２０は、ステップ１３６０で計算した最大送信時間Ｔｍａｘに基づく加入者光インタフェース１４０の順位を使用する。ステップ１７２０は、帯域幅を最も必要としていない加入者光インタフェース１４０を最初に考慮する。決定ステップ１７２５は、ステップ１７２０で考慮した送信時間を各加入者光インタフェース１４０に与えるだけの十分な時間がスーパーフレーム内にあるか否かを決定する。決定ステップ１７２５が肯定であれば（本ループの第１回目は肯定であろう）十分な時間があるため、Ｙｅｓをたどってステップ１７３０へ進み、最も帯域幅を必要としない加入者光インタフェース１４０が受け取る送信時間を各加入者光インタフェース１４０に付与する。
【０１３６】
ステップ１７３０は、最小必要加入者光インタフェース１４０を満足させるので、ステップ１７３５はそれを考慮から除外する。ステップ１７４０は、直前に付与した合計時間を減算することにより、スーパーフレーム内の利用可能時間量を更新する。決定ステップ１７４５は、追加時間を必要とする加入者光インタフェース１４０がさらにあるか否かを決定する。繰り返しの最初は、決定ステップ１７４５は大方においてＹｅｓであるため、ステップ１７２０へ戻る。
【０１３７】
繰り返しを数回行うと、検討する加入者光インタフェース１４０の数は、満足した加入者光インタフェース１４０の数だけ減少する。再びステップ１７２０は、次に帯域幅を必要としない加入者光インタフェース１４０を検討する。一実施例において、現在の加入者光インタフェース１４０は最小帯域幅を必要とする加入者光インタフェース１４０の送信時間を既に付与されたが、さらに送信時間を必要とする加入者光インタフェース１４０が存在する可能性がある。
【０１３８】
決定ステップ１７２５は、加入者光インタフェース１４０が必要とする残り送信時間を全ての残存加入者光インタフェース１４０に与えられるか否かを調べる。ステップ１７２５が肯定であれば、Ｙｅｓをたどってステップ１７３０へ進み、全ての残存加入者光インタフェース１４０に追加の送信時間または帯域幅を付与する。ステップ１７３５は、今しがた満足させた加入者光インタフェース１４０をさらなる考慮から除外する。ステップ１７４０は、今しがた割り当てた時間を利用可能時間から除外する。
【０１３９】
ステップ１７２０からステップ１７４５までのループは、以下の２イベントの１つが発生するまで繰り返す。１つは、最終的に全加入者光インタフェース１４０に対し、それらが当該サブルーチンを開始した時に必要としていた合計時間を付与した時である。この場合、決定ステップ１７４５は、Ｎｏとなりサブルーチンは終了する。あるいは、ある時点において、残っている加入者光インタフェース１４０のうち最も少ない時間を必要とする加入者光インタフェース１４０が必要とする時間を、残っている全加入者光インタフェース１４０に対し割り当てる十分な時間がない時である。この場合、決定ステップ１７２５は否定となり、Ｎｏをたどってステップ１７５０へ進む。
【０１４０】
決定ステップ１７２５が否定であれば、要求した帯域幅を受け取るのは、加入者光インタフェース１４０の全てではない。これはネットワークサービス運営者が、１人以上のユーザに残り帯域幅を不公平に分配することを意図することになる。これは、各加入者光インタフェース１４０に重み付け係数を割り当てることにより行う。この重み付け係数は、特定の加入者光インタフェース１４０へのサービスを確立する時に割り当てるが、前記事態が処理中に発生するまで使用しない。処理中に前記事態に至った場合、ステップ１７５０は、あらかじめ割り当てた重み付け係数をＴｍａｘに乗算する。この結果の積は、Ｔｍａｘｗｎである。ここで添字ｎは、関連する各加入者光インタフェース１４０にそれを適用することを意味する（すなわち割り当てられた送信時間では満足できない加入者光インタフェース１４０）。
【０１４１】
ステップ１７５５は、各加入者光インタフェース１４０への割り当てを計算する。まず各加入者光インタフェース１４０のＴｍａｘｗｎを関与する全Ｔｍａｘｗの合計で除算する。これは、各加入者光インタフェースが利用可能な時間部分を与える。その時間部分に利用可能時間を乗算し、各加入者光インタフェースが持てる時間を計算する。これをステップ１７５５は、関与する全加入者光インタフェース１４０について行う。従ってステップ１７５５が終了すると、各加入者光インタフェースは、その相対的必要量およびその割り当てられた重み付けに基づいて重み付けした送信時間を持つことになる。このサブルーチンはステップ１７６０で終了する。そして処理は図１２のステップ１３７０へ戻り、次に図１１のステップ１２２５へ戻り、トランシーバノード１２０は計算した送信時間を各加入者光インタフェース１４０へ通信する。
【０１４２】
図１６には示していない変更実施例において、ステップ１７１５とステップ１７２０との間にいくつかのステップを追加する。これら追加のステップは、全タップマルチプレクサ４４０を対象とし、各タップマルチプレクサ４４０は、受け入れようとしているデータをヘッドエンドまで送信する十分な帯域幅を持っているか否かを決定する。これを行うため、ステップ１７１５において、全タップマルチプレクサ４４０の利用可能時間を加算し、光導波トランシーバ４３０を介してヘッドエンドへ戻る送信路で利用可能な時間と比較する。それが全タップマルチプレクサ４４０が必要とするものより低ければ、ステップ１７５５と同様のステップをステップ１７１５と１７２０の間に追加できる。
【０１４３】
上り送信計画
トランシーバノード１２０は、データサービスハブ１１０までの上りリンクまたはデータ経路を、各加入者光インタフェース１４０に帯域幅を割り当てることによって管理する。ここでは、その割り当て処理を説明すると共に、いくつかの構成例を示す。下りトラフィックと同様、各チャネルは、所定数の加入者の上りデータ経路からなり、独立して動作する。
【０１４４】
トランシーバノード１２０は、トークンバケットアルゴリズムをエミュレートすることにより、上り送信を管理する。トランシーバノード１２０内において、各加入者光インタフェース１４０を次のパラメータによって定義する。
【０１４５】
・ピーク速度。ピーク速度は、加入者に許可された上りパケット送信最大速度である。
【０１４６】
・持続速度。持続速度は、加入者のプロフィール速度である。通常、この速度は、加入者が確実に受け取れる最小帯域幅であり、加入者が長期間にわたって使用できる最大帯域幅を表す。
【０１４７】
・バーストサイズ。加入者がバースト中にピーク速度において送信できるデータ量である。
【０１４８】
・優先度重み付け。当該加入者のデータに関し、他の加入者と比較しての相対的重要度である。トランシーバノード１２０は、複数の加入者光インタフェース１４０がトラフィックバーストを送信しようとしており、そのトラフィックバーストの合計がリンク容量または上りデータ経路容量を超えるであろう場合、優先度重み付けを使用して上り送信の仲裁を行う。
【０１４９】
・保証指標。加入者が常にその持続速度を保証されねばならないか否かの指標。この指標が真の場合、トランシーバノード１２０は、通常、指示された帯域幅を、たとえその加入者が現在非活性であっても、その加入者に割り当てねばならない。この設定により加入者は、活性になるとすぐにその持続速度で送信を開始できる。この指標が偽であれば、その加入者が非活性の時、トランシーバノード１２０は、その帯域幅を借り受け、それを他の加入者光インタフェース１４０に割り当てられる。
【０１５０】
図１１〜１７の方法は、いくつかの特性を持つことができる。
【０１５１】
・一実施例において、各加入者光インタフェース１４０への最小割り当ては、その持続速度か、あるいはその加入者の帯域幅が保証されていない場合、２５６Ｋｂｉｔ／ｓであることができる。
【０１５２】
・一実施例において、各加入者光インタフェース１４０への最大割り当ては、そのピーク速度か、あるいはその現在のトークンバケットのバーストに対応する量のいずれか小さい方とできる。
【０１５３】
・一実施例において、全加入者光インタフェース１４０にその最大量を付与できなければ、重み付け最大最小アルゴリズムを用い、最小値を超える帯域幅を割り当てる。重み係数は、規定重みと、各加入者光インタフェース１４０のバッファ占有のローパスフィルタ測定との積である。各加入者光インタフェース１４０に対する最大最小制限は、最大割り当てとなり得る。
【０１５４】
図１１〜１７に示した方法の一例として、表２は３加入者からなる簡易例を示す。第１列は、各加入者の計算限度を示し、第２列は平均提供負荷を示し、第３列は各加入者の優先度重みを示す。
【０１５５】
【表２】
2004535717.tif 000004
これらパラメータにより、トランシーバノード１２０は、表の最終列に基づき帯域幅を割り当てられる。表２の第３加入者光インタフェース１４０は、最小限度を有するため、１０Ｍｂｉｔ／ｓの全てを受け取る（他の２つの加入者光インタフェース１４０も、１０Ｍｂｉｔ／ｓを受け取る）。第３加入者光インタフェース１４０は、本実施例において、限度までの割り当てを受ける唯一の加入者である。そして残りの帯域幅（４７０Ｍｂｉｔ／ｓ）は、残りの２加入者に分配する。各加入者が受け取る量は、その負荷と重みとの積に比例できる。従って第２加入者光インタフェース１４０は、１０Ｍｂｉｔ／ｓに加え、４７０Ｍｂｉｔ／ｓの７５％を受け取る。第１加入者光インタフェース１４０は、４７０Ｍｂｉｔ／ｓの２５％と１０Ｍｂｉｔ／ｓとを受け取る。
【０１５６】
加入者光インタフェース１４０パケット処理
加入者光インタフェース１４０は、２優先度待ち行列機構により、上りトラフィックのサービス品質管理を支援する。加入者光インタフェース１４０は、標準レイヤ２イーサネットスイッチからなることができ、ラストマイルリンクまたは上りデータ経路は、そのスイッチ用の別のイーサネットポートとして簡単に扱うことができる。加入者光インタフェース１４０スイッチは、ボイスオーバＩＰおよびＴＤＭオーバＩＰトラフィックに優先権を与えるため、内部アプリケーションが発生したパケットに優先権を与えるように構成する。上りパケットは、優先権を設定した後、トランシーバノード１２０へ送信できるようになるまで、出力バッファで待ち行列を作る。この出力バッファは、先入れ先出しサービスを提供する。このバッファのサイズは、各加入者光インタフェース１４０に個別に設定する。
【０１５７】
バックボーンネットワーク統合
サービス品質（ＱｏＳ）は、全ネットワークに渡り包括的に管理する時、最も強力である。本発明は、全バックボーンネットワークに渡り、並ぶもののない包括的ＱｏＳ管理の機会を提供する。このような統合の基本は、ＩＰの優先制御サービス（ディフサーブ）構成である。
【０１５８】
サービス品質保証の作成
トランシーバノード（ＴＮ）１２０は、加入者とのサービス品質保証（ＳＬＡ）を広く支援する。トランシーバノード１２０は、保証全体において１構成要素に過ぎないが、アクセスネットワークとして重要である。以下においては、ラストマイルリンクまたは上りデータ経路がサービス品質保証にどのように貢献するかと、ＱｏＳ管理機能がどのようにサービス品質保証を支援できるかについて検討する。
【０１５９】
サービス品質保証の要素
一般にサービス品質保証は、ＡＴＭやフレームリレー等の専用ネットワーク技術に関連して知られている。しかしながらトランシーバノード１２０のＱｏＳ管理の威力と柔軟性とは、同じ概念をＩＰアクセスネットワークに拡大することを可能にする。従来のＡＴＭまたはフレームリレーサービス品質保証の一部である要素は、データ経路サービス品質保証の一部たりえる。
【０１６０】
・ピーク速度。ネットワークがユーザからのトラフィックバーストを受け入れる最大速度であり、ビット／秒で表現する。ネットワークは、ピーク速度を超えるトラフィックを破棄する。
【０１６１】
・持続速度。ネットワークがユーザに提供する最小スループットであり、ビット／秒で表現する。
【０１６２】
・バーストサイズ。ネットワークがユーザのピーク速度において中断無しに受け入れるトラフィック量であり、ビットで表現する。
【０１６３】
・最大待ち時間。ユーザのトラフィックがネットワークを横断する際に経験する最悪遅延である。
【０１６４】
・損失率。ネットワークが破棄するであろうピーク速度、持続速度、およびバーストサイズに適合するトラフィックのパーセントである。
【０１６５】
当然ながらサービスプロバイダは、他の要素をサービス品質保証に含めることもできる。トランシーバノード１２０は、サービスプロバイダが付加価値サービスとすることができる多くの特徴を提供する。トランシーバノード１２０は、例えば次のようなサービスを支援する。
【０１６６】
・アプリケーション優先化。基幹ネットワークアプリケーション（例えば仮想専用ネットワークトラフィック）に優先権を与える。
【０１６７】
・統計の強化。詳細なトラフィックプロフィールと統計を提供し、ユーザのネットワーク発展計画を支援する。
【０１６８】
・能動監視。ユーザトラフィックを連続的に監視し、ネットワークアプリケーション障害（例えばウエブサーバ障害）を早期検出する。
【０１６９】
・ネットワークセキュリティ。トラフィックの暗号化を加入者に提供する。
【０１７０】
以下においては、従来のサービス品質保証動作パラメータに焦点を当てる。トランシーバノード１２０がいかにネットワーク性能に貢献するかを検証し、サービス品質保証要件を満たすためにどのように下りＱｏＳ管理を行うかを検証する。表３は、以下において式で使用する主要パラメータと値とを示す。
【０１７１】
【表３】
2004535717.tif 000005
【表４】
2004535717.tif 000006
厳密なサービス品質保証および加入過剰
業務に対する要件は、サービスプロバイダ間でおよび加入者間で異なる。そのためトランシーバノード１２０は、サービス品質保証動作パラメータを実施するにあたり、プロバイダに極めて大きな柔軟性を与える。業務によっては、強固なサービス品質保証を要求する。このような環境は、保守的な規定を必要とする。保守的な規定は、極めて厳密な動作保証を提供できるが、ネットワーク全体の利用を低下させ、結果的に大きな投資支出を伴う。
【０１７２】
他の分野（例えば住宅インターネットアクセス）の場合、サービス品質保証は一般的でなく、望ましくもない。このような環境では、より積極的な規定が効果的であろう。ネットワークが積極的に規定されている場合、意味のあるサービス品質保証を実行することは難しいが、より高い利用率で運用できよう。
【０１７３】
ここでは、厳密なサービス品質保証とやや緩和したサービス品質保証とを検討する。緩和したサービス品質保証は、ネットワーク資源に対して、ある程度の加入過剰を許容する。その代わり、サービスプロバイダは、ネットワーク動作の全局面について厳密な保証を提供できない。
【０１７４】
上り性能
厳密なサービス品質保証環境の場合、サービスプロバイダは、上り性能について厳密な保証を提案できる。この保証は、ピーク速度、持続速度、バーストサイズ、待ち時間、および損失を含む。プロバイダは、これを行う場合、次の制約を守らねばならない。
【０１７５】
・全加入者のピーク速度の合計は、リンク容量より低くなければならない。［ΣＰＵ＜Ｃ］
・各加入者のバーストサイズは、その加入者のラストマイルゲートウエイに合わせた出力バッファサイズと等しくなければならない。［ＢＵ＝ＯＵ∀ＳＯＩ］
これら条件下で、トランシーバノード構成パラメータをサービス品質保証パラメータに直接関連付けることができる。
【０１７６】
【表５】
2004535717.tif 000007
より穏やかな構成は、ピーク速度制限を緩和し、それを持続速度に関する制限で置き換える。この環境での制限は次の通りである。
【０１７７】
・全加入者の持続速度の合計は、リンクまたは上りデータ経路容量より低ければ良い。［ΣＲＵ＜Ｃ］
・各加入者のバーストサイズは、その加入者の光インタフェース１４０内に構成した出力バッファサイズと等しければよい。［ＢＵ＝ＯＵ∀ＳＯＩ］
この構成において、ユーザの最悪ピーク伝送速度は、その設定上りピーク速度より低くて良い。最悪上り待ち時間および損失率も上昇する。サービス品質保証パラメータの正確な閉じた形式の式は、この構成では不可能である。表５は、サービス品質保証契約に適したサービス品質保証パラメータの範囲を示す。
【０１７８】
【表６】
2004535717.tif 000008
前記説明は、本発明の実施例を示すだけであり、請求の範囲に定義した本発明の範囲および要旨を逸脱することなく、多くの変更が前記実施例には可能であると解釈すべきである。
【図面の簡単な説明】
【図１】
本発明に基づく光ネットワーク構成例において、主要構成要素のいくつかを示す機能ブロック図である。
【図２】
本発明の光ネットワーク構成例を示す機能ブロック図である。
【図３】
本発明に基づくトランシーバノード例を示す機能ブロック図である。
【図４】
本発明の一実施例に基づく、単一光導波路によって加入者インタフェースに接続した光タップを示すブロック図である。
【図５】
本発明の第１実施例に基づく、スーパーフレーム内における保証上り帯域幅とプールした上り帯域幅とを示すブロック図である。
【図６】
本発明の第２実施例に基づくスーパーフレームを示すブロック図であり、このスーパーフレームは可変長タイムスロットからなっており、このタイムスロットは１６加入者からなるグループの加入者光インタフェース用である。
【図７】
本発明の第２実施例に基づくデータパケットのグループを示すブロック図であり、このデータパケットグループは単一のタイムスロットで送信する。
【図８】
本発明の第２実施例に基づくデータパケットの内容とフィールドサイズとの例を示すブロック図である。
【図９】
本発明の第２実施例に基づく複数のスーパーフレームを示すブロック図である。
【図１０】
本発明の第２実施例に基づく複数のスーパーフレームと予想される待ち行列および伝送遅延とを示すブロック図である。
【図１１】
本発明が上りデータを管理するために実行する高レベル処理の一実施例を示す論理流れ図である。
【図１３】
図１１のステップ１２２０のサブ処理例を詳細に示す論理流れ図である。
【図１４】
図１２のステップ１３２５のサブ処理例を詳細に示す論理流れ図である。
【図１５】
図１２のステップ１３３０のサブ処理例を詳細に示す論理流れ図である。
【図１６】
図１２のステップ１３３５のサブ処理例を詳細に示す論理流れ図である。
【図１７】
図１２のステップ１３６５のサブ処理例を詳細に示す論理流れ図である。
【図１】
2004535717.tif 000009
【図２】
2004535717.tif 000010
【図３】
2004535717.tif 000011
【図４】
2004535717.tif 000012
【図５】
2004535717.tif 000013
【図６】
2004535717.tif 000014
【図７】
2004535717.tif 000015
【図８】
2004535717.tif 000016
【図９】
2004535717.tif 000017
【図１０】
2004535717.tif 000018
【図１１】
2004535717.tif 000019
【図１２】
2004535717.tif 000020
【図１３】
2004535717.tif 000021
【図１４】
2004535717.tif 000022
【図１５】
2004535717.tif 000023
【図１６】
2004535717.tif 000024
【国際公開パンフレット】
2004535717.tif 000025
2004535717.tif 000026
2004535717.tif 000027
2004535717.tif 000028
2004535717.tif 000029
2004535717.tif 000030
2004535717.tif 000031
2004535717.tif 000032
2004535717.tif 000033
2004535717.tif 000034
2004535717.tif 000035
2004535717.tif 000036
2004535717.tif 000037
2004535717.tif 000038
2004535717.tif 000039
2004535717.tif 000040
2004535717.tif 000041
2004535717.tif 000042
2004535717.tif 000043
2004535717.tif 000044
2004535717.tif 000045
2004535717.tif 000046
2004535717.tif 000047
2004535717.tif 000048
2004535717.tif 000049
2004535717.tif 000050
2004535717.tif 000051
2004535717.tif 000052
2004535717.tif 000053
2004535717.tif 000054
2004535717.tif 000055
2004535717.tif 000056
2004535717.tif 000057
2004535717.tif 000058
2004535717.tif 000059
2004535717.tif 000060
2004535717.tif 000061
2004535717.tif 000062
2004535717.tif 000063
2004535717.tif 000064
2004535717.tif 000065
2004535717.tif 000066
2004535717.tif 000067
2004535717.tif 000068
2004535717.tif 000069
2004535717.tif 000070
2004535717.tif 000071
2004535717.tif 000072
2004535717.tif 000073
2004535717.tif 000074
2004535717.tif 000075
2004535717.tif 000076
2004535717.tif 000077
2004535717.tif 000078
2004535717.tif 000079
2004535717.tif 000080
2004535717.tif 000081
2004535717.tif 000082
2004535717.tif 000083
2004535717.tif 000084
2004535717.tif 000085
2004535717.tif 000086
2004535717.tif 000087
2004535717.tif 000088
【国際公開パンフレット（コレクトバージョン）】
2004535717.tif 000089
2004535717.tif 000090
【国際公開パンフレット（コレクトバージョン）】
2004535717.tif 000091
2004535717.tif 000092
2004535717.tif 000093
2004535717.tif 000094
2004535717.tif 000095
2004535717.tif 000096
2004535717.tif 000097
2004535717.tif 000098
2004535717.tif 000099
2004535717.tif 000100
2004535717.tif 000101
2004535717.tif 000102
2004535717.tif 000103
2004535717.tif 000104
2004535717.tif 000105
2004535717.tif 000106
2004535717.tif 000107
2004535717.tif 000108
2004535717.tif 000109
2004535717.tif 000110
2004535717.tif 000111
2004535717.tif 000112
2004535717.tif 000113
2004535717.tif 000114
2004535717.tif 000115
2004535717.tif 000116
2004535717.tif 000117
2004535717.tif 000118
2004535717.tif 000119
2004535717.tif 000120
2004535717.tif 000121
2004535717.tif 000122
2004535717.tif 000123
2004535717.tif 000124
2004535717.tif 000125
2004535717.tif 000126
2004535717.tif 000127
2004535717.tif 000128
2004535717.tif 000129
2004535717.tif 000130
2004535717.tif 000131
2004535717.tif 000132
2004535717.tif 000133
2004535717.tif 000134
2004535717.tif 000135
2004535717.tif 000136
2004535717.tif 000137
2004535717.tif 000138
2004535717.tif 000139
2004535717.tif 000140
2004535717.tif 000141
2004535717.tif 000142
2004535717.tif 000143
2004535717.tif 000144
2004535717.tif 000145
2004535717.tif 000146
2004535717.tif 000147
2004535717.tif 000148
2004535717.tif 000149
2004535717.tif 000150
2004535717.tif 000151
2004535717.tif 000152
2004535717.tif 000153
2004535717.tif 000154
2004535717.tif 000155
【国際調査報告】
2004535717.tif 000156
2004535717.tif 000157
2004535717.tif 000158