JP6893988B2 - 自由空間光通信のための効率的な自動再送要求 - Google Patents

Description

関連出願の相互参照
［0001］ 本出願は、その開示が参照により本明細書に組み込まれる、２０１６年１２月２９日に出願された、米国特許出願第１５／３９３,３７７号の継続出願である。

［0002］ ネットワークまたは他のシステムにおける通信端末は、自由空間光リンクを通して光信号を送信および受信し得る。光信号は、しばしば、データフレームとして送られる。システムが適切に動作するために、データフレームの信頼できる送信および受信が必要である。残念ながら、そのようなフレームは、様々な理由により、ルート中で損失するかまたは破損することがある。この問題に対処するための１つの技法は、送信中の誤り訂正を可能にするために、送信する前に誤り訂正符号（ＥＣＣ）を用いてデータを符号化することである。受信した誤りのあるデータフレームの再送を、受信機デバイスが送信機デバイスに要求する別の技法が、自動再送要求（ＡＲＱ）として知られている。しかしながら、自由空間光環境は非常に厳しく、したがって、データフレームの不要な再送信がない信頼できるデータ送信レートを保証するために、高度な技法が必要とされ得る。

［0003］ 自由空間光通信（ＦＳＯＣ）とともに使用するためのいくつかのＡＲＱ関連技法が提供される。ブロック選択的ＡＲＱ、適応再送信遅延、およびランダムシードスクランブリングを含むこれらの技法は、フレーム損失またはデータ破損を伴う様々な問題に対処する。ＦＳＯＣシステムは、そのような問題を扱うこと、および合理化された再送信プロセスを用いて復元することが可能である。ブロック選択的ＡＲＱは、受信機から送信機への戻りストリーム中のフレームの可変長ブロックに確認応答することを伴う。適応再送信遅延を適用することは、遅延が、選択された限界まで、受信機によるフィードバックの不在下で増大することを可能にする。および、ランダムシードサンプリングは、フレーム同期化を補助するためにスクランブリングシーケンスを採用する。

［0004］ 本開示の態様によれば、自由空間光通信システムにおいて使用するための自動再送要求（ＡＲＱ）方法が提供される。本方法は、送信機デバイスによって、自由空間光通信システムの受信機デバイスに１つまたは複数のフレームを送信することと、送信時に、再送信バッファに１つまたは複数のフレームを記憶することとを含む。本方法は、再シーケンス化バッファの現在状態を識別する現在状態情報を取得することと、現在状態情報に従って、最も進んだ送信されたフレームと最も古い未解決のフレームとを追跡することと、送信機デバイスによって、追跡された最も進んだ送信されたフレームと最も古い未解決のフレームとに従って、送信のためのフレームを選択することとをも含む。本方法は、選択されたフレームを再送信バッファから取り出すことと、取り出されたフレームを受信機デバイスに再送信することとをさらに含む。

［0005］ １つのシナリオでは、再シーケンス化バッファの現在状態情報を取得することは、受信機デバイスから現在状態情報を受信することを含む。ここで、現在状態情報は、受信機デバイスによるフレーム確認応答の一部として受信機デバイスから受信され得る。別のシナリオでは、現在状態情報は、ＲＳ先頭（ｈｒｓ）シーケンスデータと、ＲＳ受信（ｒｒｓ）シーケンスデータと、ＲＳ送達（ｄｒｓ）シーケンスデータとを含む。および、さらなるシナリオでは、最も進んだ送信されたフレームが、フレームシーケンス番号に対して決定される。

［0006］ 本開示の態様によれば、自由空間光通信システムにおいて使用するための自動再送要求（ＡＲＱ）方法が提供される。本方法は、送信機デバイスによって、自由空間光通信システムの受信機デバイスに１つまたは複数のフレームを送信することと、送信時に、再送信バッファに１つまたは複数のフレームを記憶することとを含む。本方法は、フレーム状態、送信時間、およびシーケンス番号を、再送信バッファに記憶された各それぞれのフレームに関連付けることをも含む。本方法は、送信デバイスによって、最後の送信からの時間が損失時間Ｔ_ｌｏｓｔを超えたかどうかを評価することよって、再送信バッファに記憶された１つまたは複数のフレームのうちの所与のものを再送信すべきかどうかを決定することをさらに含む。これは、以下の式に従って行われる。
Ｔ_ｌｏｓｔ（ｔ）＝ｍｉｎ｛ＲＴＴ＋（ｔ−ｔ’），Ｔ_{ｌｏｓｔ，ｍａｘ}｝
ここで、ｔは現在時間であり、ｔ’は、最後のフィードバックフレームが送信機デバイスによって正しく受信された時間であり、ＲＴＴは、推定されたラウンドトリップ時間である。Ｔ_ｌｏｓｔを超えたと決定すると、本方法は、再送信バッファに記憶されたフレームのうちの所与のものを選択することと、選択されたフレームを受信機デバイスに再送信することとを含む。

［0007］ １つのシナリオでは、所与のフレームの選択は、フレーム状態、送信時間およびシーケンス番号のうちの少なくとも１つに従って実施される。別のシナリオでは、所与のフレームの選択は、再送信バッファ内に記憶された未解決のフレームに限定される。さらなるシナリオでは、未解決のフレームは、最も古い未解決のフレームと最も進んだ送信されたフレームとの間のフレームに限定される。一例によれば、ＲＴＴは２．０ｍｓ以下であり得る。および、別の例によれば、Ｔ_ｌｏｓｔはＲＴＴと２０ｍｓとの間にある。

［0008］ 本開示の他の態様によれば、自由空間光通信システムとともに使用するためのデータ送信方法が提供される。本方法は、処理要素によって、受信機デバイスへの送信のためのデータフレームを選択することと、情報ブロックを形成するために、データフレームに再シーケンス化バッファの現在状態を付加することとを含む。本方法は、スクランブルされたデータを生成するために、スクランブリングシーケンスを用いて情報ブロックをスクランブルすることと、フレームを取得するために、スクランブルされたデータに誤り訂正符号を適用することと、送信機デバイスによって、自由空間光通信システムの受信機デバイスにフレームを送信することとをも含む。

［0009］ １つのシナリオでは、送信方法は、フレームの送信のためのライン符号を実装しない。別のシナリオでは、スクランブリングシーケンスは、後続の情報ブロックのスクランブリングのために変化する。さらなるシナリオでは、スクランブリングシーケンスは、所定のフィードバック多項式を使用して生成される。ここで、所定のフィードバック多項式は、線形フィードバックシフトレジスタを使用して形成され得る。別のシナリオによれば、スクランブリングシーケンスは、送信機デバイスによって記憶されない。

［0010］ また別のシナリオでは、本方法は、フレームが、受信機デバイスによって適切に受信されなかったと決定することと、受信機デバイスへの再送信のためにデータフレームを選択することと、情報ブロックを形成するために、データフレームに再シーケンス化バッファの現在状態を付加することと、新しいスクランブルされたデータを生成するために、新しいスクランブリングシーケンスを用いて情報ブロックをスクランブルすることと、再送信フレームを取得するために、新しいスクランブルされたデータに誤り訂正符号を適用することと、送信機デバイスによって、受信機デバイスに再送信フレームを送信することとをさらに含む。

［0011］ 本開示の態様によれば、自動再送要求（ＡＲＱ）通信デバイスが提供される。ＡＲＱ通信デバイスは、自由空間光通信（ＦＳＯＣ）を使用して他の通信デバイスと通信するように構成された光学システムを含む。それは、光学システムに動作可能に結合され、他の通信デバイスに光学システムによってＦＳＯＣを介して送られるべきフレームをアセンブルするように構成された送信機デバイスをも含む。受信機デバイスが、光学システムに動作可能に結合され、受信機デバイスは、他の通信デバイスから光学システムによって受信されたフレームを逆アセンブルするように構成される。ＡＲＱ通信デバイスのメモリは、入力バッファ（ＩＢ）、再送信バッファ（ＲＴ）および再シーケンス化バッファ（ＲＳ）を含む。ＡＲＱ通信デバイスは、メモリ、送信機デバイス、受信機デバイスおよび光学システムに動作可能に結合された１つまたは複数のプロセッサをも含む。１つまたは複数のプロセッサは、１つまたは複数のフレームにアセンブルするために、ＩＢまたはＲＴからのフレームデータを選択することと、選択されたフレームデータを送信機デバイスに与えることとを行うように構成される。前に送信されたフレームのセットが、ＲＴに記憶される。１つまたは複数のプロセッサは、前に送信されたフレームのセットの現在状態情報を追跡することと、現在状態情報がしきい値条件を満たしたかどうかを決定することと、現在状態情報がしきい値条件を満たしたとき、ＲＴからフレームデータの特定のセットを取り出し、フレームデータの特定のセットを送信機デバイスに与えることと、光学システムにフレームデータの特定のセットに対応するフレームを他の通信デバイスに送信させることとを行うようにさらに構成される。

［0012］ １つのシナリオでは、現在状態情報は、他の通信デバイスの再シーケンス化バッファのステータス、または損失時間Ｔ_ｌｏｓｔのいずれかを含む。ここで、ＡＲＱ通信デバイスは、現在状態情報に従って、最も進んだ送信されたフレームと最も古い未解決のフレームとを追跡することと、追跡された最も進んだ送信されたフレームと最も古い未解決のフレームとに従って、ＲＴからフレームデータの特定のセットを取り出すこととを行うようにさらに構成され得る。

［0013］ １つまたは複数のプロセッサは、以下の式に従って、最後の送信からの時間が損失時間Ｔ_ｌｏｓｔを超えたかどうかを評価することよって、現在状態情報がしきい値条件を満たしたかどうかを決定するように構成され得る。
Ｔ_ｌｏｓｔ（ｔ）＝ｍｉｎ｛ＲＴＴ＋（ｔ−ｔ’），Ｔ_{ｌｏｓｔ，ｍａｘ}｝
ここで、ｔは現在時間であり、ｔ’は、最後のフィードバックフレームが送信機デバイスによって正しく受信された時間であり、ＲＴＴは、推定されたラウンドトリップ時間である。

［0014］ 別のシナリオによれば、送信機デバイスは、フレームアセンブリ中に、選択されたフレームデータにスクランブリングシーケンスを適用するようにさらに構成される。この場合、送信機デバイスは、情報ブロックを形成するために、選択されたフレームデータに所与の再シーケンス化バッファの現在状態を付加することと、スクランブルされたデータを生成するために、スクランブリングシーケンスを用いて情報ブロックをスクランブルすることと、スクランブルされたフレームを取得するために、スクランブルされたデータに誤り訂正符号を適用することとによってスクランブリングシーケンスを適用するように構成され得る。

［0015］本開示の態様による、例示的な通信ネットワークの絵図である。 ［0016］本開示の態様による、通信デバイスのペアのブロック図である。 ［0017］本開示の態様による、図２の通信デバイスのペアの機能システム図である。 ［0018］本開示の態様による、例示的な送信機モジュールおよび受信機モジュールならびに例示的なフレームフォーマットを示す。 ［0018］本開示の態様による、例示的な送信機モジュールおよび受信機モジュールならびに例示的なフレームフォーマットを示す。 ［0018］本開示の態様による、例示的な送信機モジュールおよび受信機モジュールならびに例示的なフレームフォーマットを示す。 ［0019］本開示の態様による、フレームの送信および受信に関する絵図である。 ［0019］本開示の態様による、フレームの送信および受信に関する絵図である。 ［0020］本開示の態様による、再送信バッファの例である。 ［0021］本開示の態様による、再シーケンス化バッファの例である。 ［0022］誤フレーム同期シナリオの可能性を示す。 ［0023］本開示の態様による、線形フィードバックシフトレジスタスクランブラを示す。 ［0024］本開示の態様による、例示的な流れ図である。 ［0025］本開示の態様による、別の例示的な流れ図である。 ［0026］本開示の態様による、さらなる例示的な流れ図である。

概要
［0027］ 本技術は、例として、自由空間光通信システムにおいて使用するための様々なＦＳＯＣ関連技法に関する。ＦＳＯＣシステムでは、様々な理由で個々におよびバーストでデータフレームを損失する可能性がある。たとえば、送信機デバイスと受信機デバイスとの間の光リンクが失われるポインティングエラーがあり得る。シンチレーション、結合損失、および他の問題など、受信電力変動の他の原因も、バーストでのフレームの損失の原因となり得る。本明細書で説明される技法は、システムが、再送信プロセスを合理化することよって、データフレームの損失または破損からすばやく、効率的に復元することを可能にする。これは、全体的な通信プロセスをよりロバストにし、また、不要な再送信に関連するオーバーヘッドコストを低減する。
例示的なシステム

［0028］ 上記のように、通信ネットワークまたは他のシステムが、様々な通信デバイスの間でデータを転送するために使用される光通信リンクを含み得る。通信デバイスは、建築物上に、地上に、あるいは移動デバイス（たとえば、高高度プラットフォームまたは衛星上に配置されたジンバル支持されたデバイス）上に配置され得るが、通信デバイスを配置するための他の構造も想定される。したがって、通信リンクは、建築物、地面、および移動デバイスの間でデータを転送するために使用される。各光リンクは、２つの通信デバイス間の通信を可能にする。送信機デバイスは、光ビームを送信するように構成され、受信機デバイスは、送信機デバイスからの光ビームを検出し、したがって、通信リンクを形成するように構成される。もちろん、通信デバイスは、任意の所与の時点において送信機デバイスおよび／または受信機デバイスとして機能し得る。

［0029］ 図１を参照すると、例示的な通信ネットワーク１００は、固定通信端末１０２および１０４などの様々な通信端末、衛星１０６、および飛行機または無人航空機（ＵＡＶ）１０８であり得る航空機などの高高度プラットフォーム（ＨＡＰ）、ならびに通信気球１１０を含む。１つまたは複数の通信デバイスが、各通信端末に関連付けられる。様々な通信端末の通信デバイスは、互いに直接または間接的に通信し得る。固定通信端末は、建築物の屋上にまたは地上に配置され得るが、他の場所が想定される。航空機１０８は、ＵＡＶまたは機内に人間のパイロットがいない他の航空機であり得る。ＵＡＶは、自律的であるか、リモートで操縦されるか、またはその両方であり得る。通信気球１１０は、たとえば、地球の表面上の１１から２３マイルの間の高度に到達するために地球の成層圏中に放たれ、（３Ｇまたは４Ｇなどの）地上波ワイヤレスデータサービスに匹敵する速度で直径が２５マイルの地面エリアに接続性を提供し得る。通信気球１１０は、一例では、民間飛行機および気象の２倍の高度（たとえば、地球の表面上の２０ｋｍ程度）で成層圏中で浮動し得る。通信気球１１０は、風によって地球の周りを運ばれ、所望の方向に移動する風がある高度に上昇または下降することによってステアリングされ得る。成層圏中の風は通常一定であり、約５および２０ｍｐｈでゆっくり移動し、風の各層は方向および大きさが異なる。

［0030］ 固定通信端末１０２、１０４は、別の固定端末（図示せず）、衛星１０６、またはＨＡＰ１０８から（図１中で点線として示されている）通信信号を受信し、別の固定端末、衛星、またはＨＡＰに通信信号を再ルーティングし得る。ＨＡＰ１０８および／または他の通信端末１０２、１０４、１０６および１１０は、対象とするエリアに通信サービスを提供するために、メッシュネットワークまたは他の構成中に配置され得る。いくつかの例では、通信信号は、少なくとも１つの通信端末から、それらの各々が、それぞれ、ユーザ１１６または１１８に関連し得る１つまたは複数のユーザデバイス１１２または１１４に直接または間接的に送られ得る。たとえば、ユーザデバイス１１２は、たとえば、セルラー通信を介して通信端末１０２と通信しているモバイルフォンであり得る。また、ユーザデバイス１１４は、たとえばＷｉＦｉホットスポット１２０を介して通信端末１０４と通信していることがある。

［0031］ 衛星１０６は、対地同期軌道（ＧＥＯ）を含む、低軌道（ＬＥＯ）、中軌道（ＭＥＯ）、または高軌道（ＨＥＯ）中にあり得る。ＨＡＰ１０８は、高高度（たとえば、地表上の１７〜２２ｋｍ）において動作し得る。一例では、通信気球１１０またはＵＡＶ１０８は、対象とするエリアに通信サービスを提供するために成層圏中で動作するように構成され得る。そのようなＨＡＰ１０８は、たとえば、地上から、航空機から発射することによって地球の大気中に放たれるか、または所望の高度に飛ばされ得る。

［0032］ 本開示の１つの特定の例では、通信ネットワーク１００は、電気通信またはコンピュータネットワーキングのためのデータをワイヤレス送信するために自由空間中を伝搬する光を使用する光通信技術である、ＦＳＯＣを採用する。したがって、通信ネットワーク１００は、図１に示されているように通信端末のペアの間で光通信信号を送信するように構成される。

［0033］ 図２を参照すると、この図は、通信デバイス２００ａおよび２００ｂの例示的なペアを示すブロック図である。上述のように、１つまたは複数の通信デバイスが、ＦＳＯＣを採用する通信端末の各々に含まれる。通信デバイス２００ａ、２００ｂは、２つの通信端末間の光通信リンク２０２ａおよび２０２ｂを確立し、通信信号２０４ａおよび２０４ｂが、ある通信端末別のものから送信されることを可能にするように構成され得る。

［0034］ 通信信号２０４は、通信ネットワーク１００（図１参照）にわたって自由空間２０８を介してルーティングされる、インターネットプロトコル（ＩＰ）パケットなど、データ２０６を含む。各通信デバイス２００（たとえば、２００ａ、２００ｂ）は、１つまたは複数のプロセッサ２１０、たとえば、２１０ａまたは２１０ｂと、メモリ２２０、たとえば、２２０ａまたは２２０ｂとを含み得る。通信デバイスは、トランシーバ２４２、たとえば、２４２ａおよび２４２ｂとして配置され得る、１つまたは複数の送信機デバイス２３０、たとえば、２３０ａまたは２３０ｂと、受信機デバイス２４０、たとえば、２４０ａまたは２４０ｂとをも含む。通信デバイスは、光学システム２５０、たとえば、２５０ａまたは２５０ｂと、ポインティング／ステアリングハードウェア２６０、たとえば、２６０ａまたは２６０ｂとをも含む。

［0035］ （１つまたは複数の）プロセッサ２１０は、中央処理装置（ＣＰＵ）または他のマイクロプロセッサ、専用フィールドプログラマブルゲートアレイ（ＦＰＧＡ）論理、他のハードウェアベース処理構成要素およびそれらの任意の組合せを備え得る。１つまたは複数のプロセッサ２１０は、１つまたは複数のプロセッサ２１０によって実行可能な命令など、情報を非一時的に記憶するメモリ２２０に動作可能に結合される。各通信デバイス２００のメモリ２２０はまた、自由空間光リンクにわたって送信されるべきデータに関する情報を記憶するように構成される。メモリ２２０は、以下で詳細に説明される様々なバッファを含むように物理的にまたは論理的にのいずれかで配置された１つまたは複数のメモリモジュールを備え得る。

［0036］ １つまたは複数のプロセッサ２１０は、送信機デバイス２３０および受信機デバイス２４０に動作可能に結合される。１つまたは複数のプロセッサ２１０は、したがって、（１つまたは複数の）送信機デバイス２３０を介して、光ビームの形態で通信情報およびデータを送信するように構成され得、また、（１つまたは複数の）受信機デバイス２４０を介して、光ビームの形態で通信およびデータを受信するように構成され得る。受信された光ビームは、通信情報およびデータを抽出するために、１つまたは複数のプロセッサ２１０によって処理され得る。

［0037］ １つまたは複数のプロセッサ２１０は、抽出された通信情報およびデータに従って、様々なＡＲＱ技法を実装するようにさらに構成される。これは、現在移動中でないいくつかの確認応答がないフレーム（たとえば、１つまたは複数のデータパケット）を再送信すべきかどうかを決定することを含み得る。また、フィードバックが受信機デバイスによって与えられたかどうかに応じて、再送信遅延を適応的に変動させることを含み得る。さらに、誤フレームマーカーの可能性を回避するために、スクランブリングシーケンスを与えることを含み得る。これらのＡＲＱ技法は、以下で詳細に説明される。

［0038］ １つまたは複数のプロセッサ２１０はまた、光学システム２５０に動作可能に結合され、リンク２０２を確立するために、光学システム２５０の調整された位置を決定し得る。さらに、１つまたは複数のプロセッサ２１０は、光学システム２５０を調整するためのポインティング／ステアリングハードウェア２６０に動作可能に結合され、光学システム２５０のポインティング調整を提供するように構成され得る。ポインティング／ステアリングハードウェア２６０は、ヨーおよびピッチなど、少なくとも２つの自由度で移動するように構成され得る。光学システム２５０に対する調整は、他の通信デバイス２００とのリンクを取得し接続を確立するために行われ得る。

［0039］ 送信機デバイス２３０は、発光ダイオード（ＬＥＤ）またはレーザーダイオードなど、半導体デバイスであり得る。いくつかの例では、送信機デバイス２３０は、ファイバーレーザーまたは固体レーザーであり得る。レーザーダイオードは直接変調され得る、すなわち、光出力は、送信機２３０に直接印加される電流によって制御され得る。送信機デバイス２３０は、１つの光学モードをサポートするシングルモードレーザーダイオードであり得るか、または送信機デバイス２３０は、複数のトランスバース光学モードをサポートするマルチモードレーザーダイオードであり得る。光学モードは、ビームの伝搬方向に直交する（すなわち、トランスバースな）平面において測定される放射の特定の電磁フィールドパターンである。送信機デバイス２３０は、順次、電気信号を受信し、電気信号を変調する変調器（図示せず）から、変調された通信信号を受信し得る。

［0040］ 送信機デバイス２３０は、変調された電気信号を受信し、電気信号を光通信ビームに変換し、光学システム２５０に向かう光ファイバーに光通信ビームを出力し得る。送信機デバイス２３０はまた、ある通信デバイスが別の通信デバイスを見つけることを可能にするビーコンビームを出力するように構成される。たとえば、通信デバイス２００ｂの送信機デバイス２３０ｂは、通信デバイス２００ａが、デバイス２００ｂを見つけ、通信デバイス２００ｂとの通信リンク２０２ａを確立することを可能にするために、ビーコンビームを出力し得る。通信デバイス２００ａの送信機デバイス２３０ａは、同様に、通信デバイス２００ｂが、デバイス２００ａを見つけ、通信デバイス２００ａとの通信リンク２０２ｂを確立することを可能にするために、ビーコンビームを出力し得る。したがって、通信リンク２０２ａ、２０２ｂは、２つの通信デバイス２００ａおよび２００ｂの間の通信信号２０４ａおよび２０４ｂを可能にし得る。

［0041］ 受信機デバイス２４０は、入射光ビームを検出するために、光位置検知デバイスを含む。いくつかの例では、光位置検知デバイスは、限定はしないが、光ビーコンレーザーを検出するために、横方向位置デバイス、電荷結合素子（ＣＣＤ）カメラ、光検出器、またはクワッドセルを含む。受信機デバイス２４０は、光電効果を使用して、受信された光ビームを電気信号に変換する。

［0042］ 光学システム２５０は、通信ビームまたはビーコンビームなど、光ビームを送信すること、ならびに光ビームを受信し、受信された光ビームを受信機デバイス２４０に与えることを行うように構成される。光ビームを受信するために、光学システム２５０および／または受信機デバイス２４０は、限定はしないが、デマルチプレクサ、光前置増幅器、フォトダイオード、光受信機、トランスインピーダンス増幅器、クロック／位相復元回路、決定回路、および／または前方誤り訂正（ＦＥＣ）回路を含み得る。

［0043］ 光学システム２５０の構成は、受信機光学系とは別個である送信機光学系を含み得る。したがって、通信リンク２０２ａは、ある通信デバイスの送信機光学系と、別の通信デバイスの受信機光学系との間で形成され得る。たとえば、通信デバイス２００ａは、通信デバイス２００ａの光学システム２５０ａ中の送信機光学系と、第２の通信デバイス２００ｂの光学システム２５０ｂ中の受信機光学系とを使用して、通信デバイス２００ｂとの通信リンク２０２ａを形成し得る。通信リンク２０２ａが形成されると、１つまたは複数のプロセッサ２１０ａは、データ２０６を含む通信信号２０４ａを通信デバイス２００ｂに送ることができる。同様に、通信デバイス２００ｂにおける光学システム２５０ｂ中の送信機光学系は、光ビーコンビームを送信し得、通信デバイス２００ａにおける光学システム２５０ａ中の受信機光学系は、通信リンク２０２ｂを形成するために、光ビーコンビームを見つけ、識別する。通信リンク２０２ｂが形成されると、１つまたは複数のプロセッサ２１０ｂは、データ２０６を含む通信信号２０４ｂを通信デバイス２００ａに送ることができる。

［0044］ 上述のように、通信デバイス２００は、固定通信端末、およびＨＡＰ１０８など、モバイル通信端末を含む通信端末に組み込まれ得る。いくつかの例では、通信気球１１０の通信デバイス２００中の１つまたは複数のプロセッサ２１０は、高高度気球１１０が、適切な通信カバレッジ、たとえば、メッシュネットワークにおける特定の位置または局を提供するために到達する必要がある場所および／または高度を決定するように構成され得る。１つまたは複数のプロセッサ２１０は、通信気球１１０を、それが行くべきであるところへ連れて行き得る方向に吹く風の層に気球を移動させ、それにより、正しい場所に通信気球をステアリングするようにさらに構成され得る。

［0045］ 図３を参照すると、この図は、図２の通信デバイス２００ａおよび２００ｂに機能的に対応する、通信デバイス３０２ａおよび３０２ｂのペアを含む例示的なシステム３００を示す。図示のように、各通信デバイス３０２は、入力バッファ（ＩＢ）３０４（３０４ａまたは３０４ｂ）、出力バッファ（ＯＢ）３０６（３０６ａまたは３０６ｂ）、送信機セクション３０８（３０８ａまたは３０８ｂ）および受信機セクション３１０（３１０ａまたは３１０ｂ）を有する。例として、入力バッファ３０４ａおよび３０４ｂならびに出力バッファ３０６ａおよび３０６ｂは、それぞれ、メモリ２２０ａおよび２２０ｂの部分を備え得る。送信機セクション３０８ａおよび３０８ｂは、それぞれ、送信機デバイス２３０ａおよび２３０ｂ、ならびに光学システム３５０ａまたは３５０ｂの対応する部分を含み得る。同様に、受信機セクション３１０ａおよび３１０ｂは、それぞれ、受信機デバイス２４０ａおよび２４０ｂ、ならびに光学システム３５０ａまたは３５０ｂの対応する部分を含み得る。

［0046］ 図３の例示的なシステム３００では、通信デバイス３０２ａの送信機３０８ａは、光通信リンク３１２ａを介して通信デバイス３０２ｂの受信機３１０ｂにデータフレームを送るように構成される。この特定の例では、通信デバイス３０２ｂの送信機３０８ｂは、光通信リンク３１２ｂを介して通信デバイス３０２ａの受信機３１０ａに確認応答フレームおよび他の情報を送るように構成される。図に示されているように、通信デバイス３０２ｂは、再シーケンス化バッファの現在状態を伝達するシーケンス情報（ｈ，ｒ，ｄ）を通信デバイス３０２ａに与え得るため、通信デバイス３０２ａの（１つまたは複数の）プロセッサは、以下で詳細に説明されるいくつかのＡＲＱ技法を実装することができる。

［0047］ 図４Ａ〜図４Ｃを参照すると、これらの図は、例示的なフレーム構成とともに、それぞれ、データフレームをアセンブルおよび逆アセンブルする例示的な送信機モジュール４００および例示的な受信機モジュール４４０を示す。モジュールは、図３の送信機３０８ａおよび３０８ｂならびに受信機３１０ａおよび３１０ｂのある機能性と、図２の送信機デバイス２３０ａおよび２３０ｂならびに受信機デバイス２４０ａおよび２４０ｂの対応する機能性とを実装する。図４Ａに示されているように、送信機モジュール４００は、フレームソース４０２とマルチプレクサ４０４、４０６および４０８とを含む。フレームソース４０２は、入力バッファ４１０および再送信バッファ（ＲＴ）４１２を含む。技術の態様によれば、（１つまたは複数の）プロセッサのＡＲＱ論理は、入力バッファ４１０または再送信バッファ４１２からの送信のために、またはアイドルフレーム４１４としてフレームを選択することができる。フレームソース４０２は、必要に応じて、たとえば、アイドルフレームフラグ（ｉｄ）、シーケンス番号（ＳＮ））、フレーム長（ｌ）およびフレームデータフィールド（ｄ）などのフレーム情報、ならびにフィルバイト（ｆ）を含む、選択されたフレームをマルチプレクサ４０４に与える。

［0048］ マルチプレクサ４０４は、第１の多重化された情報４１８を取得するために、フレームを再シーケンス化バッファ（ＲＳ）からのデータと多重化する。このデータは、再シーケンス化バッファの現在状態を受信機に伝達する、再シーケンス化先頭情報（ｈ_ｒｓ）、再シーケンス化受信情報（ｒ_ｒｓ）、および再シーケンス化送達情報（ｄ_ｒｓ）を含む。ｈ_ｒｓ、ｒ_ｒｓおよびｄ_ｒｓ情報は、シーケンス番号を備え得る。スクランブラ４２０によって供給されたスクランブリングシーケンスが、第１の多重化された情報４１８にノード４２２を介して適用され、その結果、スクランブルされたブロック４２４が得られる。スクランブラ４２０は、線形フィードバックシフトレジスタ（ＬＦＳＲ）ベーススクランブラであり得る。マルチプレクサ４０６は、スクランブルされたブロック４２４のヘッダにスクランブラ４２０の初期状態を付加し、その結果、第２の多重化された情報４２６が得られる。

［0049］ 第２の多重化された情報４２６は、符号化ブロック４２８におけるリードソロモンＥＣＣなど、誤り訂正符号で符号化される。一例では、誤り訂正符号は、（ｎ；ｋ）＝（２５５，２２３）リードソロモン符号である。ここで、エンコーダは、２２３個の情報バイトからなるブロックのための３２個のパリティバイトを算出し、コードワード長は、したがって、２５５バイトである。マルチプレクサ４０８は、ＥＣＣ符号化されたデータ４３０に（１つまたは複数の）フレーム同期マーカーを付加し、ＦＳＯＣを介した送信の準備ができているフレーム４３２を形成する。

［0050］ 図４Ｂを参照すると、この図は、本開示の態様による、１つの可能なフレームフォーマットを示す。ここで、単位は、バイト（８，１，３２，．．．）またはビット（１５ｂ，１ｂ）からなる。ＦＳ＝フレーム同期、ｌ_ｉ＝ｉ番目のパケットの長さフィールド、ｄ_ｉ＝ｉ番目のパケット（情報バイト）、ｆ＝フィルバイト、およびｐ_ｉ＝ｉ番目のコードワードのパリティバイト。パリティバイトは、ＥＣＣに従って（パリティバイト自体を除く）２２３個のバイトごとに挿入される。この例では、最小フレーム長は好ましくは２５５バイトであり、最大フレーム長は３５７０バイトである。

［0051］ フレームは、Ｐ個のパケットを含んでいる。パケットの数は、着信パケットストリームによって決定され、｛１，２，．．．，２３｝の値を取る。パケットはフレームに追加され、２バイトの長さフィールドがパケット長を符号化する。ｉ番目のパケットの長さフィールドはｌ_ｉと示され、ｌ_ｉバイトのパケットはｄ_ｉと示される。フレーム中のパケットの集合は、以下によって示される。
（ｌ，ｄ）_Ｐ＝｛（ｌ_０，ｄ_０），（ｌ_１，ｄ_１），．．．，（ｌ_Ｐ−１，ｄ_Ｐ−１）｝

［0052］ この例では、パケットの連続ストリームが利用可能であるとき、長さフィールドおよびパケットデータが１４８０バイトを超える、すなわち、｜（ｌ；ｄ）｜≧１４８０になるまで、フレームを形成するためにパケットが収集される。フレームを１４８０バイトに拡張するために利用可能なパケットがない場合、フレームは完成したと見なされる。フレーム中にパケットがない場合、ヘッダ中のアイドルフレームフラグｉｄは１に設定され、データフィールドは、最小フレーム長に対応するオールゼロに設定される。ヘッダを加えたフレーム長が２２３バイトの倍数になるように、オールゼロバイトのフィルバイトパターンが各フレームに追加される。

［0053］ フレームの送信の要求時に、図４Ａに従って上記で説明されたように、この例では、フレーム｛ｉｄ，（ｌ，ｄ），ｆ｝が、再シーケンス化バッファの、割り当てられたシーケンス番号および６バイトの現在状態（ｈ_ｒｓ，ｒ_ｒｓ，ｄ_ｒｓ）が付加される。ブロックはスクランブルされる。初期の２バイトのスクランブラ状態またはシードが、ブロックに付加される（状態はスクランブルされない）。２２３個のスクランブルされたバイトからなるあらゆるブロックが、ＲＳコードによって符号化され、３２個のパリティバイトを生成する。３２個のパリティバイトが、それらが符号化する２２３個のバイトの後に挿入される（パリティバイトはスクランブルされない）。最小フレーム長は２５５バイトである。１５２０バイトの最大入力パケット長の場合、最大フレーム長は３５７０バイトである。

［0054］ 受信されたフレームを復号およびデスクランブルするために、等価な逆方向プロセスが採用され、これは、受信機モジュール４４０におけるデータ処理を示す図４Ｃに示されている。フレーム同期モジュール４４４は、フレーム（ビットストリーム）４４２の開始および終了にあるフレーム同期パターンを見つける。これから、フレーム同期モジュール４４４はＫ、すなわち、フレーム中のＥＣＣコードワードの数を決定する。Ｋと符号化されたデータの両方が、符号化されたデータブロック中のいくつかの誤りを検出し、場合によっては訂正するように構成されたＥＣＣ復号ブロック４４６に与えられる。たとえば、（２５５，２２３）リードソロモン符号を使用して、デコーダは、最高ｔ＝１６バイトの誤りを訂正することができる。１に近い確率の場合、１６バイト以上の誤りをもつコードワードが、デコーダによって検出され、信頼性のないコードワードとしてフラグを付けられる。フレーム中のＫ個のコードワードのいずれかが、信頼性がないとしてフラグを付けられた場合、フレーム全体が廃棄される。復号されているコードワードとともに、パリティバイトは、デコーダによって取り去られる。誤りがない、または誤りが訂正可能であると仮定すると、ＥＣＣ復号ブロックは、スクランブラシード４４８を抽出し、デスクランブラ４５０に出力し、また、ノード４５４に復号されたデータストリーム４５２を出力する。

［0055］ 正常に復号されたフレームについて、スクランブラシードは、デスクランブラ４５０を初期化するために使用され、デスクランブラ４５０は、次いで、ノード４５４においてフレームをデスクランブルする。この情報は、ブロック４５６においてデマルチプレクスされ、ブロック４５６は、ある情報を、ブロック４５８における再シーケンス化バッファＲＳと、ブロック４６０における再送信バッファＲＴとに出力する。特に、シーケンス番号｛ｈ_ｒｓ，ｒ_ｒｓ，ｄ_ｒｓ｝は、再送信状態を更新するために、取り去られ、ＲＴに送られる。非アイドルフレーム（たとえば、ここで、ｉｄ＝０）について、フレームデータ（フレーム長（ｌ）およびフレームデータフィールド（ｄ））ならびにシーケンス番号ＳＮが、ＲＳに送信される。
例示的なプロセス

［0056］ 本明細書で説明されるＡＲＱシステムおよび技法は、ＦＳＯＣ端末上でのトラフィックを制御し、チャネルアウテージを通した信頼できるデータ送信を可能にする。ＡＲＱ動作は以下を含む。送信機において、着信フレームは、送信を要求されるまで、入力バッファＩＢに保持される。送信され、未解決であり得るフレームは、再送信バッファＲＴに保持される。送信され、確認応答された（ＡＣＫされた）場合、フレームは、送信機において解決されたと見なされる。送信されたが、ＡＣＫがない場合、フレームは、未解決であると見なされる。受信機において、着信フレームは、再シーケンス化バッファＲＳに保持される。ＲＳは、着信トラフィックから損失フレームを推論する。順序正しく受信され、誤りがないフレームは、ＲＳバッファから発信イーサネットストリームに送達される。ＲＳの状態は、戻りトラフィックを用いて送信機に送信される。
ブロック選択的ＡＲＱ

［0057］ 上述の構成を用いて実装され得る１つの手法は、ブロック選択的ＡＲＱである。上述のように、様々な理由でバーストでデータフレームを損失する可能性がある。たとえば、光リンクが失われるポインティングエラーがあり得る。シンチレーション、結合損失、および他の問題など、受信電力変動の他の原因も、バーストでのフレームの損失の原因となり得る。これらの問題に対処するために、ブロック選択的ＡＲＱが採用され得る。この技法は、高速および低速フェージングチャネルに好適であり、従来の選択的再送（ＳＲ）よりも低い複雑さと、Ｇｏ?Ｂａｃｋ?Ｎ（ＧｂＮ）技法よりも良好な性能とを有する。

［0058］ ブロック選択的ＡＲＱは、受信機から送信機への戻りストリーム中のフレームの可変長ブロックに確認応答する。受信側では、すべての受信されたフレームは、ＲＳに保持される。順序正しく受信され、誤りがないフレームは、次いで、別の通信端末にまたはエンドユーザに与えられ得る発信イーサネットストリームへの挿入のために、ＲＳから出力バッファＯＢにフォワーディングされる。ＲＳとともに（１つまたは複数の）プロセッサは、受信された着信トラフィックから損失フレームを推論する。受信機は、図３に示されているように、（シーケンス番号に関して）最も進んだ受信されたフレームｈと、最も最近の受信されたフレームｒと、フォワーディング（または送達）されていない最も古いフレームｄとを追跡する。

［0059］ 図５Ａおよび図５Ｂを参照すると、これらの図は、確認応答がないフレームにシステムがどのように対処し得るかを図式的に表す。第１の表現５００（図５Ａ）は、第２の通信デバイス（たとえば、図３のそれぞれ通信デバイス３０２ａおよび３０２ｂ）にフレームを送る第１の通信デバイスが、様々な送信されたデータフレームをどのように追跡し得るかを示す。ここで、ｈは最も進んだ送信されたフレームを示し、ｕは最も古い確認応答がない（未解決の）フレームを示す。ｈとｕとの間の影付き領域中のフレームは、移動中であるか、損失したか、または確認応答されたものであり得る。

［0060］ 第２の表現５１０（図５Ｂ）は、第２の通信デバイスが、様々な受信されたデータフレームをどのように追跡し得るかを示す。ここで、第２の通信デバイスの再シーケンス化バッファＲＳ中の情報に基づいて、ｈは最も進んだ受信されたフレームを示し、ｄは送達されていない最も古いフレームを示し、ｒは、最も最近の受信されたフレームを示す。（ｈ，ｒ，ｄ）によって伝達されたＲＳの状態は、戻りトラフィックを用いて送信側に戻される。これは、送信側へのＡＣＫの集合として働く。例として、シーケンス番号（ｈ，ｒ，ｄ）は、戻りデータ、特にフレームのヘッダ中に埋め込まれる。戻りデータがない場合、アイドルフレームが生成され、（ｈ，ｒ，ｄ）はアイドルフレーム中に埋め込まれる。システムは、（ｈ，ｒ，ｄ）データに従って、ＡＣＫの不在によって、特定のフレームについての確認応答の欠如を推論し、それにより、フレームを再送信するためにＡＲＱプロセスを実装し得る。

［0061］ たとえば、各バッファは、Ｎ_ｗｉｎ＝２０４８個のフレームのウィンドウを保持し得る。ウィンドウサイズは、最大損失持続時間に適応するように設定される。あいまいさ（たとえば、２つ以上のフレームを指す１つのシーケンス番号）を回避するためには、最大シーケンス番号が２Ｎ_ｗｉｎであることで十分である。１つのシナリオによれば、最大シーケンス番号はＳＮ_ｍａｘ＝２^１６＝６５５３６であり得る。シーケンス番号の以下の集合が、この例においてバッファの状態を追跡するために使用される。

［0062］ 任意のバッファ中のフレームの数は常にＮ_ｗｉｎであるので、このシナリオでは、先頭を保持し、先頭場所から末尾を算出すれば十分である。

［0063］ 上述のように、入力バッファＩＢは、送信されなかったフレームを保持する。１つの例示的なシナリオによれば、入力バッファは、先入れ先出しキューとして構成される。上記に示された先頭ポインタｈ_ｉｂおよび末尾ポインタｔ_ｉｂは、入力バッファの状態を追跡し、最大入力バッファインデックスを法としてラッピングする。このシナリオでは、ｈ_ｉｂ＝ｔ_ｉｂであるとき、入力バッファは空であり、リセット時に、システムはｈ_ｉｂ＝ｔ_ｉｂを設定する。データがストールし、バッファが一杯になった場合、フレームは、バッファの先頭または末尾のいずれかから削除され得る。フレームは、入力バッファ中で許容される最大時間、たとえば、入力バッファタイムアウトをも有し得る。入力バッファタイムアウトよりも長くバッファにあったフレームは、このシナリオでは、キューから削除される。

［0064］ このシナリオでは、再送信バッファＲＴは、送信され、それらのステータスが未解決であり得る、Ｎ_ｗｉｎ＝２０４８個のフレームを保持するように構成される。２つのアドレス｛ｈ_ｒｔ，ｕ_ｒｔ｝は、ＲＴバッファ状態を追跡する。［ｔ_ｒｔ，ｕ_ｒｔ−１］からのフレームは解決された（たとえば、送達またはスキップされた）。

［0065］ 再シーケンス化バッファＲＳは、受信されたが、（たとえば、誤ってまたは順序が狂って受信されたことにより）送達されないことがあるフレームを保持する。また、このシナリオでは、ＲＳバッファの状態は、３つのシーケンス番号｛ｈ_ｒｓ，ｒ_ｒｓ，ｄ_ｒｓ｝を用いて追跡される。ここで、ｈ_ｒｓは受信された最も進んだフレームであり、ｄ_ｒｓは送達されるべき次のフレームであり、ｒ_ｒｓは最も最近受信されたフレームである。したがって、ｈ_ｒｓおよびｒ_ｒｓは、誤りのないフレームを常に指し、［ｔ_ｒｓ，ｄ_ｒｓ−１］からのすべてのフレームは、解決され（送達またはタイムアウトのいずれかをされ）、ｄ_ｒｓは、受信されなかったフレームを指す（ウィンドウ全体が送達される場合、ｄ_ｒｓはｈ_ｒｓ＋１を指す）。ＲＳバッファにおいて、フレームは、それらが順序正しく受信されると送達される。送達されたアドレスｄ_ｒｓは、送達されるべき次のフレームを指すために進められる。

［0066］ 送信側では、システムは、受信されたＲＳ状態情報を使用し、図５Ａに見られるように、最も進んだ送信されたフレーム（ｈ）と、最も古い未解決の（ＡＣＫがない）フレーム（ｕ）とを追跡する。送信機は、現在移動中でない最も古い確認応答がないフレームを送信するように構成される。
適応再送信遅延

［0067］ ＦＳＯＣに好適な別のＡＲＱ技法は、適応再送信遅延である。再送信遅延は、フレームが損失したと推論する（およびそれを再送信の候補にする）まで送信機が待つ最小時間である。１つのシナリオでは、再送信遅延は、ラウンドトリップ時間（ＲＴＴ）に名目上設定される。しかしながら、フレームについての確認応答情報が損失した場合、システムは、正しく受信されたフレームを誤って再送信することがある。これは、送信機が、新しいフレームを送ることの代わりに、適切に受信されたフレームの再送信に処理および送信リソースを消費するので、システムの効率に悪影響を及ぼす。この状況に対処するために、システムは、再送信遅延が、何らかの定義された限界まで、受信機によるフィードバックの不在下で増大することを可能にする。ここで、受信機から有効なフレームを受信すると、送信機は遅延をリセットする。

［0068］ 送信時に、フレームはＲＴに記憶され、フレームが送信された時間（Ｔ_ｔｍｔ）は、たとえば、そのバッファに記録される。１つのシナリオでは、ＲＴは、フレーム状態、シーケンス番号およびＴ_ｔｍｔを保持する。たとえば、図６を参照すると、ＲＴバッファは、図示のように情報を記憶し得、ここで、Ａ＝確認応答された（すなわち、ＡＣＫ）、Ｃ＝再利用のためにクリアされた、およびＵ＝未解決の、である。ここで、各列は単一のフレームに対応し、ｈ_ｒｔは送信された最も進んだシーケンス番号であり、ｕ_ｒｔは未解決である最も進んでいないシーケンス番号である。Ｔ_ｌｏｓｔは損失持続時間であり、ＲＴＴはラウンドトリップ時間である。図７を参照すると、ＲＳは、図示のように情報を記憶し得、ここで、Ａ＝受信された（確認応答された）、Ｎ＝受信されていない、およびＤ＝送達された、である。ｈ_ｒｓは受信された（ＡＣＫされた）最も進んだシーケンス番号であり、ｒ_ｒｓは最も最近の受信されたＳＮであり、ｄ_ｒｓは送達されるべき次のＳＮである。

［0069］ この例では、フレームは、最後の送信からの時間がＲＴパラメータＴ_ｌｏｓｔを超えたとき、再送信の候補になる。Ｔ_ｌｏｓｔは、以下の式に従って決定される。
Ｔ_ｌｏｓｔ（ｔ）＝ｍｉｎ｛ＲＴＴ＋（ｔ−ｔ’），Ｔ_{ｌｏｓｔ，ｍａｘ}｝

［0070］ ここで、ｔは現在時間であり、ｔ’は、最後のフィードバックフレーム（ＡＣＫ）が正しく受信された時間であり、ＲＴＴはラウンドトリップ時間である。Ｔ_ｌｏｓｔを超えたと決定すると、送信機の処理システムは、選択されたフレームを再送信することを決定し得る。１つのシナリオでは、一般的なＲＴＴは０から１．３ｍｓの間にあり、Ｔ_ｌｏｓｔはＲＴＴと１０ｍｓとの間にあり得る。他のＦＳＯＣシナリオでは、ＲＴＴは、１．３ｍｓを超え、たとえば、１．０ｍｓと５ｍｓとの間にあるか、または１０ｍｓ未満であり得る。Ｔ_ｌｏｓｔは、同様に、１０ｍｓを超え、たとえば、１０から２５ｍｓの間にあるか、または４０ｍｓ未満であり得る。他のＦＳＯＣ状況は、さらにより大きい（またはより小さい）ＲＴＴおよびＴ_ｌｏｓｔ時間を有し得る。

［0071］ より簡単には、待つべき時間（τ）＝ＲＴＴ＋δであり、ここで、δは、戻りトラフィック（たとえば、確認応答）がダウンしたかまたはさもなければ正しく受信されなかった時間である。この手法は、信頼できないフィードバックチャネルによる誤再送信を低減するのを助ける。

［0072］ 新しいフレームが他のデバイスから受信されたとき、ＲＴバッファは更新される。一例では、損失持続時間は、まず、（処理遅延を含むものと考えられる）最小値ＲＴＴに設定され得る。（値｛ｈ_ｒｓ，ｒ_ｒｓ，ｄ_ｒｓ｝に基づく）送信機ウィンドウ外にあるアドレスを有するフレームは、無視される。（シーケンス番号に関して）最も古い未解決のフレームが確認応答されたとき、考慮中のフレームのためのウィンドウは進む。

［0073］ システムは、さらに、タイムアウトＴ_ｏｕｔを有する。Ｔ_ｏｕｔよりも長くＲＴにあったフレームは、もはや再送信の候補でない。本開示の態様によれば、フレームがＴ_ｏｕｔよりも長くＲＴにあったとき、それの状態は、Ｕ（確認応答がない）またはＡ（確認応答された）からＣ（再利用のためにクリアされた）に変更される。ＲＳバッファにおいてこれに適応するためのいくつかの方法がある。一例では、Ｎ_ｗｉｎウィンドウは、有効なシーケンス番号の数よりもはるかに小さい。ＲＴがフレームをタイムアウトしたとき、［ｈ_ｒｓ，ｄ_ｒｓ］におけるシーケンス番号のウィンドウを越えてｈ_ｒｓポインタを進ませるシーケンス番号をもつフレームの送信が可能になる。ＲＳがそのようなシーケンス番号を受信したとき、それは、新しいフレームに適応するためにそれのウィンドウを進める。これは、ｄ_ｒｓポインタを進ませ得、その場合、それは、ｄ_ｒｓがＤ（送達された）まで進んだすべてのフレームの状態をリセットする。このようにして、ＲＳバッファは、ＲＴがもはや送信していないフレームにハングアップしない。

［0074］ トラフィック要求または他の要求に基づいてサービス品質を設定することも可能である。ここで、システムは、タイムアウトをよりすばやく発生させるためにこの情報を考慮に入れるか、または場合によっては決してタイムアウトしないことがある。たとえば、レイテンシ条件付きトラフィックは、ゼロのタイムアウトを有し得、したがって、それらは決して再送信されない。
ランダムにシードされたスクランブリング

［0075］ 本開示の態様による別のＡＲＱ技法は、ランダムシードスクランブリングを伴う。いくつかのデジタル通信システムでは、データ中の１または０のロングランを回避するために、また、データがＤＣバランスされることを保証するために、ライン符号が使用されることがある。ライン符号は、クロックおよびデータ復元に関してシステムを助ける。デジタル通信システムはまた、フレームの開始および終了を見つけるための方法を必要とする。これは、特殊フレーム同期（ＦＳ）シーケンスをデータシーケンス中に埋め込むことによって可能にされ得る。ライン符号はまた、データ中のＦＳの発生を禁止するように設計され得る。しかし、ライン符号はまた、オーバーヘッド、コーディング複雑さおよび復号における誤り伝搬を導入する。これらは、通信システムの性能に著しく影響を及ぼすことがある。そのような問題を回避するために、ライン符号の代わりに、スクランブリングシーケンスが使用され得る。スクランブリングシーケンスの場合、データは、データがランダムに現れる可能性が高くなるように、たとえば、ビットの２を法とする加算によってスクランブリングシーケンスと組み合わせられる。

［0076］ レート１を有するスクランブリングシーケンスは、依然として、同期がデータ中に現れるという可能性（あるいは１または０の問題になるラン）を許容する。図８を参照すると、これは、誤（たとえば、重複）フレーム同期（ＦＳ）に関して示されている。誤ＦＳが現れたとき、受信機はそれに不正確にロックすることがあり、フレームは損失する。誤ＦＳ問題は、ここでは、フレームが再送信されるときにスクランブリングシーケンスのために異なるシードを使用することによって対処される。したがって、フレームが損失し、再送信される必要があるならば、それは、それに適用される異なるスクランブリングシーケンスを有する。データが異なるシーケンスを用いてスクランブルされたとき、誤ＦＳが現れることは極めて可能性が低い。上記で説明されたように、スクランブリングシードは、受信機による復元のためにフレーム内に組み込まれる。図４Ａを再び参照すると、スクランブラ４２０からのスクランブリングシーケンスまたはシード（ｒ）が、誤り訂正符号の適用より前に、送信されるべきフレームに適用されることが示されている。

［0077］ 図９を参照すると、この図は、特に線形フィードバックシフトレジスタ（ＬＦＳＲ）を使用する、スクランブラ４２０の一実施形態を示す。この場合、スクランブリングシーケンスは、特定のフィードバック多項式を有するＬＦＳＲによって生成される。結果は、フレームに付加される２バイトのスクランブラ状態（またはシードフィールド）であり、第１のスクランブルされたビットは、アイドルフィールドである。単に例として、フィードバック多項式は、ｚ^１５＋ｚ^１＋ｚ^０であり得る。他のフィードバック多項式も採用され得る。また、ＬＦＳＲ状態は反復ごとに変化するので、スクランブラシーケンスは、したがって、あるフレームから後続のフレームにかけて変化する。

［0078］ スクランブリングの後、たとえば、図４Ａのノード４２２に関して上記で説明されたように、ＥＣＣが適用され、データブロックが受信機に送信される。フレームを受信すると、誤り訂正および検出がＥＣＣに従って実施された後、スクランブリングシードｒは、図４Ｃに示されているように抽出され、デスクランブラを初期化するために使用される。スクランブラ状態が記憶される必要がないので、フレームが再送信される必要があるとき、適切なスクランブラ状態がその時点において再生成される。この手法によれば、ライン符号が省略され得、その結果、低減されたオーバーヘッド、コーディング簡略化および復号における誤り伝搬の回避が得られる。
例示的な方法

［0079］ 図１０〜図１２を参照すると、これらの図は、上記で説明されたプロセスの例示的な流れ図を与える。たとえば、図１０は、ブロック１００２において自由空間光通信システムの受信機デバイスに１つまたは複数のフレームを送信することを伴う、プロセス１０００を示す。（１つまたは複数の）フレームが、ブロック１００４において再送信バッファに記憶され、ブロック１００６において、システムは、再シーケンス化バッファの現在状態を識別する現在状態情報を取得する。ブロック１００８において、プロセスは、現在状態情報に従って、最も進んだ送信されたフレームと最も古い未解決のフレームとを追跡する。次いで、ブロック１０１０において、システムは、追跡された最も進んだ送信されたフレームと最も古い未解決のフレームとに従って、送信のためのフレームを選択する。ブロック１０１２において、対象とするフレームが再送信バッファから取り出され、ブロック１０１４において、取り出されたフレームは、ＦＳＯＣを使用して受信機デバイスに送信される。

［0080］ 図１１を参照すると、この図は、１つまたは複数のフレームが、ブロック１１０２において自由空間光通信システムの受信機デバイスに送信されるプロセス１１００を示す。ブロック１１０４において、（１つまたは複数の）フレームが、再送信バッファに記憶される。ブロック１１０６に示されているように、フレーム状態、送信時間およびシーケンス番号が、再送信バッファに記憶された各それぞれのフレームに関連付けられる。ブロック１１０８において、システムは、最後の送信からの時間が損失時間（Ｔ_ｌｏｓｔ）を超えたかどうかを評価することよって、再送信バッファに記憶された所与のフレームを再送信すべきかどうかを決定する。これは、以下の式に従って行われる。
Ｔ_ｌｏｓｔ（ｔ）＝ｍｉｎ｛ＲＴＴ＋（ｔ−ｔ’），Ｔ_{ｌｏｓｔ，ｍａｘ}｝
ここで、ｔは現在時間であり、ｔ’は、最後のフィードバックフレームが送信機デバイスによって正しく受信された時間であり、ＲＴＴは、推定されたラウンドトリップ時間である。ブロック１１１０において、Ｔ_ｌｏｓｔを超えたと決定すると、システムは、再送信バッファに記憶されたフレームのうちの所与のフレームを選択し、ブロック１１１２において、システムは、選択されたフレームを受信機デバイスに再送信する。

［0081］ 図１２を参照すると、この図は、ブロック１２０２ごとに受信機デバイスへの送信のためのデータフレームを選択することを伴うプロセス１２００を示す。システムは、ブロック１２０４において、情報ブロックを形成するために、データフレームに再シーケンス化バッファの現在状態を付加し、ブロック１２０６において、スクランブルされたデータを生成するために、スクランブリングシーケンスを用いて情報ブロックをスクランブルする。次いで、ブロック１２０８において、システムは、フレームを取得するために、スクランブルされたデータに誤り訂正符号を適用し、ブロック１２１０において、自由空間光通信システムの受信機デバイスにフレームを送信する。

［0082］ 上記で説明された特徴は、ＦＳＯＣシステムにおける２つの通信デバイスの間のフレームのＡＲＱ再送信を扱うための効率的な手法を提供し得る。これらの技法は、システムオーバーヘッドおよび処理コストを低減し、情報のより信頼できる送信および受信を保証する。様々な技法が、個々にまたは任意の組合せで使用され得、その結果、低速フェージングおよび他のバーストフレーム損失状況を扱うことができるロバストな通信アーキテクチャが得られる。

［0083］ 別段に明記されていない限り、上記の代替例は、相互排他的ではなく、独自の利点を達成するために様々な組合せで実装され得る。上記で説明された特徴のこれらおよび他の変形形態および組合せが、特許請求の範囲によって定義される主題から逸脱することなく利用され得るので、実施形態の上記の説明は、特許請求の範囲によって定義される主題の限定としてではなく例として解釈されるべきである。さらに、本明細書で説明される例の提供、ならびに「など」、「を含む」などとして言い表される節は、特定の例に特許請求の範囲の主題を限定するものと解釈されるべきではなく、むしろ、例は、多くの可能な実施形態のうちの１つのみを示すものである。さらに、異なる図面中の同じ参照番号は、同じまたは同様の要素を識別することがある。

［0084］ 本技術は、限定はしないが、自由空間光通信システムにおける信頼できるデータ送信を含む、広い産業上の利用可能性を享受する。

Claims (8)

1. 自由空間光通信システムにおいて使用するための自動再送要求（ＡＲＱ）方法であって、前記方法が、
   送信機デバイスによって、前記自由空間光通信システムの受信機デバイスに１つまたは複数のフレームを送信することと、
   送信時に、再送信バッファに前記１つまたは複数のフレームを記憶することと、
   前記送信機デバイスの再シーケンス化バッファの現在状態を識別する現在状態情報を取得することと、
   前記現在状態情報に従って、最も進んだ送信されたフレームと最も古い未解決のフレームとを追跡することと、
   前記送信機デバイスによって、前記追跡された最も進んだ送信されたフレームと前記最も古い未解決のフレームとに従って、送信のためのフレームを選択することと、
   前記選択されたフレームを前記再送信バッファから取り出すことと、
   前記取り出されたフレームを前記受信機デバイスに再送信することと
   を備える、自動再送要求（ＡＲＱ）方法。
2. 前記再シーケンス化バッファの前記現在状態情報を取得することが、前記受信機デバイスから前記現在状態情報を受信することを含む、請求項１に記載のＡＲＱ方法。
3. 前記現在状態情報が、前記受信機デバイスによるフレーム確認応答の一部として前記受信機デバイスから受信される、請求項２に記載のＡＲＱ方法。
4. 前記現在状態情報が、再シーケンス化先頭情報（ｈ_rs ）と、再シーケンス化受信情報（ｒ_rs ）と、再シーケンス化送達情報（ｄ_rs ）とを含む、請求項１に記載のＡＲＱ方法。
5. 前記最も進んだ送信されたフレームが、フレームシーケンス番号に関して決定される、請求項１に記載のＡＲＱ方法。
6. 前記取り出されたフレームを前記受信機デバイスに再送することが、前記現在状態情報の少なくとも一部を前記取り出されたフレームとともに多重化することを含む、請求項１に記載のＡＲＱ方法。
7. 前記現在状態情報の前記少なくとも一部を多重化することが、前記送信機デバイスの前記再シーケンス化バッファの前記現在状態を受信機デバイスに伝達する、再シーケンス化先頭情報（ｈ _rs ）、再シーケンス化受信情報（ｒ _rs ）、又は再シーケンス化送達情報（ｄ _rs ）の少なくとも１つを多重化することを含む、請求項６に記載のＡＲＱ方法。
8. 前記現在状態情報の前記少なくとも一部を多重化することが、再シーケンス化先頭情報（ｈ _rs ）、再シーケンス化受信情報（ｒ _rs ）、及び再シーケンス化送達情報（ｄ _rs ）のそれぞれを多重化することを含む、請求項７に記載のＡＲＱ方法。
   

Images