JP2015502712A - ハイブリッドネットワーキングパス選択および負荷バランシング - Google Patents

Abstract

第１のストリームを送信する伝送媒体を選択するための方法およびシステム。複数の伝送媒体のうちの少なくとも１つは、本質的に、実質的に動的であり得る。複数の伝送媒体の各々のパス特性は、決定され得る。第１の伝送媒体は、決定されたパス特性に基づいて第１のストリームのための複数の伝送媒体から選択され得る。第１のストリームの第１の複数のパケットは、第１の伝送媒体上で送信され得る。【選択図】図４

Description

関連出願

本出願は、２０１１年１１月２１日に出願した米国特許出願第１３／３０１，５７６号の優先権の利益を主張するものである。

本発明は、一般に、通信システムに関し、より詳細には、複数の伝送媒体を含むネットワーク内でストリームを送受信するためのシステムおよび方法に関する。

通信ネットワークを構築するために現在一般的に使用される様々なネットワーク技術がある。様々なネットワーク技術の中でもとりわけ、いくつかの例としては、ワイヤレスローカルエリアネットワーク（ＷＬＡＮ）技術、電力線通信技術、イーサネット（登録商標）、および８０２．１６（ＷｉＭＡＸ（登録商標））がある。複数のそのような通信ネットワークが同じ空間内に存在することは、（たとえば、家庭環境において）比較的一般的ですらある。そのような状況では、複数の異なるネットワーク技術を使用して他のハイブリッドネットワーキングデバイスに連結することができ、それによって、より堅牢なハイブリッドネットワークを形成するハイブリッドネットワーキングデバイスは、特に有用である。

しかしながら、通信メカニズム（たとえば、伝送媒体）、および個別のネットワーキング技術に対するプロトコルの詳細（たとえば、デバイスおよびトポロジの発見、他のネットワークへのブリッジングなど）は、一般に、各ネットワーキング技術に固有である。そのような多様なネットワーキング技術をブリッジングして有効なハイブリッドネットワークを形成することは難しい目標であり、ハイブリッドネットワーキングの様々な分野における改善が望ましい。

本開示の実施形態は、ネットワーキングシステムを改善するために提示される。より具体的には、本開示の実施形態は、複数の伝送媒体を使用してストリームを送受信することが可能なネットワーキングシステムにおける、パス選択、負荷バランシング、ストリームアグリゲーション、パケットロスの最小化、複製パケットの検出、および順序の乱れたパケットの再順序付けするための方法を対象とする。

本開示のいくつかの実施形態は、複数の伝送媒体を介して別の電子デバイス（たとえば、第２のハイブリッドネットワーキングデバイス）に結合された電子デバイス（たとえば、第１のハイブリッドネットワーキングデバイス）によって実施され得る。たとえば、この電子デバイスは、そのうちの少なくともいくつかは異なる伝送媒体を利用して通信を伝えることができる複数タイプのネットワークを介して通信することを可能とすることができる。そのうえ、いくつかの実施形態では、伝送媒体のうち少なくとも１つは、本質的に、実質的に動的であることがあり、たとえば、伝送媒体のうち少なくとも１つのＰＨＹレートは、経時的に大幅に変わることがある。

複数の伝送媒体を介して互いに結合された電子デバイスは、伝送媒体のうちいずれかまたはすべて（または、いくつかの組合せ）を使用して通信することが可能であるという利点を有する。しかしながら、異なる伝送媒体および関連するネットワーキング技術を最適に利用するために、高度な制御アルゴリズムが必要とされることがある。たとえば、いくつかのタイプの通信は、他のタイプの通信よりも、あるタイプのネットワーキング技術および／または伝送媒体に適していることがある。特に媒体特性が経時的に変わる可能性があり、定期的にモニタしなければならないとき、複数の利用可能な伝送媒体からストリームを送信する伝送媒体をインテリジェントに選択することは重要な行為である。このプロセスは、本明細書ではパス選択と呼ばれ、本開示の一組の実施形態は、パス選択のためのシステムおよび方法に関する。

そのうえ、ストリーム特性（たとえば、どれくらい多くの帯域幅をストリームが利用するか）および媒体特性（たとえば、伝送媒体のリンク容量）が経時的に変化するので、オーバーサブスクリプション（ｏｖｅｒｓｕｂｓｃｒｉｐｔｉｏｎ）条件が、１つまたは複数の伝送媒体上で発生することがある。さらに、いくつかの状況下では、伝送媒体に、一時的にまたは永久的に障害が発生することがある。したがって、オーバーサブスクリプションを回避し適切なサービスを様々なタイプのコンテンツストリームに提供しながら利用可能なネットワーク容量の使用を最適化するために、電子デバイス間で複数の伝送媒体を経由して通信されている様々なストリームの平衡を保つことは、本開示の別の重要な態様である。様々な伝送媒体の使用を最適化するために様々な伝送媒体をモニタし、１つまたは複数のストリームを選択して、ある伝送媒体から別の伝送媒体に移動させるプロセスは、本明細書では負荷バランシングと呼ばれ、本開示の一組の実施形態は、負荷バランシングのためのシステムおよび方法に関する。

通信するための複数の伝送媒体の可用性も、複数の伝送媒体を使用してストリームを送信する可能性に役立つ。たとえば、いくつかの状況では、通信ストリームは、何らかの単一の伝送媒体によってその全体が維持できるよりも大きい帯域幅要件を有することができる。これは、極めて大きいストリームの場合に、または、場合によってはより一般的に、いくつかのストリームが各伝送媒体上ですでに通信されており、伝送媒体所与の何らかの上で残存している利用可能なリンク容量が限られている場合に、発生することがある。そのような状況では、通信ストリームの一部が第１の伝送媒体上で通信され、通信ストリームの別の一部が第２の伝送媒体上で通信されていることが望ましいことがある。このプロセスは、（たとえば、ストリームは送信側で分割され、受信側でアグリゲーションされ得るので）本明細書ではストリーム分割およびストリームアグリゲーションと呼ばれ、本開示の一組の実施形態は、ストリーム分割／アグリゲーションのためにストリームを選択するためのシステムおよび方法に関する。パス選択および負荷バランシングと同様に、アグリゲーション／分割のためにストリームを選択し、どのようにストリームを分割するかを決定するプロセスは、伝送媒体のうち１つまたは複数が本質的に動的であることであることによって、複雑化されることがある。いくつかの実施形態では、ストリーム分割／アグリゲーションは、たとえば、より高度な技法として、負荷バランシングのプロセスにおいても使用され得ることに留意されたい。

複数の伝送媒体を使用して２つの電子デバイス間で通信するというアイデアは、多数の明らかな利点を有する。具体的には、それにより、異なるサービス品質（ＱｏＳ）要件または他の必要性を有する異なるタイプのコンテンツに対応するためのより高い柔軟性とともに、より大きな全容量を持つより堅牢なネットワークが作製され得る。しかしながら、受信電子デバイスによって認識され正常に受信されるように、ある伝送媒体から別の伝送媒体へのストリームの移動（部分的には、ストリーム分割／アグリゲーションと同様に、または完全に）を協調させることによって、それ自体の一組の課題が提示される。これは、伝送媒体が本質的に著しく異なり、異なるネットワーキング技術を利用する場合に、特に当てはまることがある。この一例は、パケットの順序付けである。伝送媒体が異なる伝送遅延を有することは、異なるタイプの通信インターフェースでは一般的であり得るが、この場合、切り換え元の伝送媒体上で通信される最後のいくつかのパケットは、切り換え先の伝送媒体上で通信される最初のいくつかのパケットの後で、電子デバイスによって受信されることがある。本開示の一組の実施形態は、受信機がそのような順序の乱れたパケットを検出し、それらのパケットを再順序付けすることを可能にするためのシステムおよび方法に関する。

さらに、複数の伝送媒体を協調的に利用して、２つの電子デバイス間で通信できることによって、ストリームを障害の発生した伝送媒体から依然として機能する伝送媒体に移動させる可能性が提供されるが、障害の発生した伝送媒体によって引き起こされる潜在的なパケットロスを最小にする方法を提供することが望ましい。したがって、本開示の一組の実施形態は、たとえば、パケットバッファ内のパケットのいくつかまたはすべてが元の伝送媒体を介して受信機に正常に通信されなかったと決定される場合、新しい伝送媒体上で再送信できるパケットバッファを維持することによって、ストリームを新しい伝送媒体に切り換えるときの受信機におけるパケットロスを最小にするためのシステムおよび方法に関する。

前述のパケットロスの最小化技法の結果として、または他の理由で、ある伝送媒体から別の伝送媒体にストリームを切り換える際に複製パケットが通信される場合があり得る。たとえば、障害が発生している伝送媒体が、障害が発生する前に送信するようにスケジュールされたパケットのうちいくつかを送信するが、送信電子デバイスがこれを知る方法を持たない場合、このデバイスは、新しい伝送媒体を使用して、これらのパケットを再送信することができる。この場合、受信機は、通信ストリームの少なくともいくつかのパケットの複製コピーを受信することができる。受信機が、複製パケットを破棄するために、好ましくはパケットの内容を検査することを必要とせずに、これをすばやく決定することができることが望ましい。したがって、本開示の一組の実施形態は、複製パケットの検出および除去のためのシステムおよび方法に関する。

本開示の様々な実施形態は、必要に応じて、個別に実施されてもよいし、組み合わせて実施されてもよい。たとえば、一組の実施形態によれば、複数の伝送媒体を介して第２のハイブリッドネットワーキングデバイスに結合された第１のハイブリッドネットワーキングデバイスは、本開示の要素により、複製パケットの検出および除去とともに、パス選択、負荷バランシング、ストリーム分割／アグリゲーション、順序の乱れたパケットの順序変更、およびパケットロスの最小化を実施するように構成され得る。

いくつかの実施形態では、第１のストリームを送信する伝送媒体を選択するデバイスのための方法であって、方法は、複数の伝送媒体の各々のパス特性を決定することと、ここで、複数の伝送媒体のうちの少なくとも１つは、本質的に、実質的に動的である、決定されたパス特性に基づいて第１のストリームのための複数の伝送媒体から第１の伝送媒体を選択することと、第１の伝送媒体上で第１のストリームの第１の複数のパケットを送信することとを備える、方法。

いくつかの実施形態では、パス特性は、伝送媒体のリンク容量、現在の媒体利用率、または最大媒体利用率のうちの１つまたは複数を備える、
いくつかの実施形態では、方法は、第１のストリームの内容のタイプを決定することをさらに備え、第１の伝送媒体を該選択することは、第１のストリームの内容のタイプにさらに基づく。

いくつかの実施形態では、方法は、第１のストリームの優先レベルを決定することをさらに備え、第１の伝送媒体を該選択することは、第１のストリームの優先レベルにさらに基づく。

いくつかの実施形態では、方法は、伝送媒体のパス特性に基づいてストーム内容の複数のタイプの各々のための伝送媒体の好ましい順序を決定することをさらに備える。

いくつかの実施形態では、方法は、少なくとも１つの伝送媒体の少なくとも１つのパス特性の変更を検出することと、少なくとも１つの伝送媒体の少なくとも１つのパス特性の検出された変更に基づいてストリーム内容の複数のタイプのうちの少なくとも１つのための伝送媒体の好ましい順序を修正することとをさらに備える。

いくつかの実施形態では、方法は、第１の伝送媒体の現在の媒体利用率が第１の閾値を超えたと決定することと、第１の伝送媒体上での現在の媒体利用率が第１の閾値を超えたと決定することに基づいて第２の伝送媒体上での送信のために第１のストリームを選択することと、第２の伝送媒体上での送信のために第１のストリームを選択することに基づいて第２の伝送媒体上で第１のストリームの第２の複数のパケットを送信することとをさらに備え、第１のストリームのパケットは、第２の伝送媒体上での送信のために第１のストリームを該選択した後、第１の伝送媒体上で送信されない。

いくつかの実施形態では、デバイスは、複数の伝送媒体を介して第２のデバイスに結合するための複数のポートと、ここで、複数の伝送媒体のうちの少なくとも１つは、本質的に、実質的に動的である、ストリームを送信する伝送媒体を選択することを行うように構成された論理とを備え、論理は、複数の伝送媒体の各々のパス特性を決定することと、決定されたパス特性に基づいて第１のストリームのための複数の伝送媒体から第１の伝送媒体を選択することと、第１の伝送媒体上で第１のストリームの第１の複数のパケットを送信することとをさらに行うように構成される。

いくつかの実施形態では、パス特性は、伝送媒体のリンク容量、現在の媒体利用率、または最大媒体利用率のうちの１つまたは複数を備える。

いくつかの実施形態では、論理は、第１のストリームの内容のタイプを決定することを行うようにさらに構成され、第１の伝送媒体を選択することは、第１のストリームの内容のタイプにさらに基づく。

いくつかの実施形態では、論理は、第１のストリームの優先レベルを決定することを行うようにさらに構成され、第１の伝送媒体を該選択することは、第１のストリームの優先レベルにさらに基づく。

いくつかの実施形態では、論理は、伝送媒体のパス特性に基づいてストーム内容の複数のタイプの各々のための伝送媒体の好ましい順序を決定することを行うようにさらに構成される。

いくつかの実施形態では、論理は、少なくとも１つの伝送媒体の少なくとも１つのパス特性の変更を検出することと、少なくとも１つの伝送媒体の少なくとも１つのパス特性において検出された変更に基づいてストリーム内容の複数のタイプのうちの少なくとも１つのために伝送媒体の好ましい順序を修正することとを行うようにさらに構成される。

いくつかの実施形態では、論理は、第１の伝送媒体の現在の媒体利用率が第１の閾値を超えたと決定することと、第１の伝送媒体の現在の媒体利用率が第１の閾値を超えたと決定することに基づいて第２の伝送媒体上での送信のために第１のストリームを選択することと、第２の伝送媒体上での送信のために第１のストリームを選択することに基づいて第２の伝送媒体上で第１のストリームの第２の複数のパケットを送信することとを行うようにさら構成され、第１のストリームのパケットは、第２の伝送媒体上での送信のために第１のストリームを該選択した後、第１の伝送媒体上で送信されない。

いくつかの実施形態では、コンピュータ可読記憶媒体は、第１のストリームを送信する伝送媒体を選択するデバイスのためのプログラム命令を備え、プログラム命令は、複数の伝送媒体の各々のパス特性を決定することと、ここで、複数の伝送媒体のうちの少なくとも１つは、本質的に、実質的に動的である、決定されたパス特性に基づいて第１のストリームのための複数の伝送媒体から第１の伝送媒体を選択することと、第１の伝送媒体上で第１のストリームの第１の複数のパケットをルーティングすることとを行うために実行可能である、
いくつかの実施形態では、複数の伝送媒体の負荷をバランスするデバイスのための方法であって、複数の伝送媒体のうちの少なくとも１つは、本質的に、実質的に動的であり、方法は、第１の伝送媒体上で第１のストリームの第１の複数のパケットを送信することと、第１の伝送媒体の現在の媒体利用率が第１の閾値を超えたと決定することと、第１の伝送媒体の現在の媒体利用率が第１の閾値を超えたと決定することに基づいて第２の伝送媒体上での送信のために第１のストリームを選択することと、ここで、該選択することは、複数の伝送媒体のうちの１つまたは複数のパス特性および第１のストリームの１つまたは複数の特性にさらに基づく、第２の伝送媒体上で第１のストリームの第２の複数のパケットを送信することとを備え、第１のストリームのパケットは、第２の伝送媒体上での送信のために第１のストリームを該選択した後、第１の伝送媒体上で送信されない。

いくつかの実施形態では、方法は、第２の伝送媒体上で第１のストリームを送信することが第２の閾値を超える第２の伝送媒体の媒体利用率を生じさせないことになると決定することをさらに備え、第２の伝送媒体上での送信のために第１のストリームを該選択することは、第２の伝送媒体上で第１のストリームを送信することが第２の閾値を超える第２の伝送媒体の媒体利用率を生じさせないことになると該決定することに少なくとも部分的に基づく。

いくつかの実施形態では、第１のストリームは、第１の優先レベルを有し、第２の伝送媒体上で送信するために第１のストリームを選択することは、第１の優先レベルに少なくとも部分的に基づく。

いくつかの実施形態では、第１の優先レベルは、第１のストリームの内容のタイプに基づく。

いくつかの実施形態では、第１のストリームの１つまたは複数の特性は、第１のストリームの推定された帯域幅要件を備え、複数の伝送媒体の１つまたは複数のパス特性は、それぞれの伝送媒体ごとに、伝送媒体のリンク容量、現在の媒体利用率、または最大媒体利用率のうちの１つまたは複数を備える。

いくつかの実施形態では、デバイスは、複数の伝送媒体を介して第２のデバイスに結合するためのポートと、ここで、複数の伝送媒体の少なくとも１つは、本質的に、実質的に動的である、複数の伝送媒体の付加をバランスすることを行うように構成された論理とを備え、論理は、複数のポートのうちの第１のポートを介して第１の伝送媒体上で第１のストリームの第１の複数のパケットを送信することと、第１の伝送媒体の現在の媒体利用率が第１の閾値を超えたと決定することと、第１の伝送媒体の現在の媒体利用率が第１の閾値を超えたと決定することに基づいて第２の伝送媒体上での送信のために第１のストリームを選択することと、ここで、該選択することは、複数の伝送媒体のうちの１つまたは複数のパス特性および第１のストリームの１つまたは複数の特性にさらに基づく、複数のポートのうちの第２のポートを介して第２の伝送媒体上で第１のストリームの第２の複数のパケットを送信することとを行うように構成され、第１のストリームのパケットは、第２の伝送媒体上での送信のために第１のストリームを該選択した後、第１の伝送媒体上で送信されない。

いくつかの実施形態では、コンピュータ可読記憶媒体は、複数の伝送媒体の負荷をバランスするためのプログラム命令を備え、プログラム命令は、送信のための第１の伝送媒体に第１のストリームの第１の複数のパケットをルーティングすることと、第１の伝送媒体の現在の媒体利用率が第１の閾値を超えたと決定することと、第１の伝送媒体の現在の媒体利用率が第１の閾値を超えたと決定することに基づいて第２の伝送媒体上での送信のために第１のストリームを選択することと、ここで、該選択することは、複数の伝送媒体のうちの１つまたは複数のパス特性および第１のストリームの１つまたは複数の特性にさらに基づく、第２の伝送媒体上で送信するために第１のストリームを選択することに基づいて送信するための第２の伝送媒体に第１のストリームの第２の複数のパケットをルーティングすることとを行うために実行可能である。

いくつかの実施形態では、双方向ストリームに関連する第１のデバイスのための方法であって、方法は、第１の伝送媒体上で第２のデバイスから第１のストリームの第１の複数のパケットを受信することと、第２のストリームが第１のストリームに関連して生成されることができると決定することと、ここで、第２のストリームは、第２のデバイスに送信するためのものである、第１のストリームが第１の伝送媒体に割り当てられ、第２のストリームが第１のストリームに関連付けられることを示す情報を格納することと、第１の伝送媒体上で第２のデバイスに第２のストリームの第２の複数のパケットを送信することと備え、第１の伝送媒体上で第２のデバイスに第２のストリームの第２の複数のパケットを送信することは、第１のストリームが第１の伝送媒体に割り当てられ、第２のストリームが第１のストリームに関連付けられることを示す情報に基づく。

いくつかの実施形態では、方法は、第２のストリームが第２のデバイスから第１のストリームに関連して生成されることができるインジケーションを受信することをさらに備え、第２のストリームが第１のストリームに関連して生成されることができると決定することは、第２のストリームが第１のストリームに関連して生成されることができるインジケーションを受信することに基づく。

いくつかの実施形態では、第２のストリームの第２の複数のパケットは、第１のストリームの第１の複数のパケットに応じて生成される。

いくつかの実施形態では、第１の複数のパケットは、ＴＣＰデータパケットを備え、第２の複数のパケットは、ＴＣＰ ＡＣＫパケットを備える。

本発明のより良い理解は、以下の実施形態の詳細な説明を以下の図面と併せ読めば、得ることができる。
一実施形態に従う、複数のネットワーキング技術を含む例示的な通信ネットワークを示す図。 一実施形態に従う例示的なデバイスのシステム図。 一実施形態に従う、複数のネットワーキングインターフェースを実施するハイブリッドデバイスのための例示的なプロトコルスタックを示す概念図。 一組の実施形態に従う、複数の伝送媒体を介してストリームを送受信するための方法を示すフローチャート図。 一組の実施形態に従う、複数の伝送媒体を介してストリームを送受信するための方法を示すフローチャート図。 一組の実施形態に従う、複数の伝送媒体を介してストリームを送受信するための方法を示すフローチャート図。 一組の実施形態に従う、複数の伝送媒体を介してストリームを送受信するための方法を示すフローチャート図。 一実施形態に従う、ストリーム分割／ストリームアグリゲーションを取り巻く送信デバイスと受信デバイスの間のメッセージフローを示す通信図。 一実施形態に従う、異なるシナリオによる様々な伝送媒体の仮想リンク容量を示すグラフ。 一実施形態に従う、ストリーム分割／ストリームアグリゲーションが実施され得るシナリオを示すブロック図。 一実施形態に従う、ストリーム分割／ストリームアグリゲーションが実施され得るシナリオを示すブロック図。 一実施形態に従う、アグリゲーションされたパケットストリームのパケット順序付けを維持するために受信デバイスによって使用され得る環状バッファを示す図。

本発明は、様々な変更および代替形態の余地があるが、その特定の実施形態が例として図面に示され、本明細書において詳細に説明される。しかしながら、それに対する図面および詳細な説明は、本発明を開示される特定の形態に限定することを意図するものではなく、逆に、添付の特許請求の範囲によって定義される本発明の趣旨および範囲に含まれるすべての変更物と、均等物と、代替物とを包含することを意図することを理解されたい。

用語
以下は、本出願で使用される用語の用語集である。

記憶媒体−様々なタイプのメモリデバイスまたは記憶デバイスのいずれか。「メモリ」および「記憶媒体」という用語は、インストール媒体、たとえば、ＣＤ−ＲＯＭ、フロッピー（登録商標）ディスク、もしくはテープデバイス、ＤＲＡＭ、ＤＤＲ ＲＡＭ、ＳＲＡＭ、ＥＤＯ ＲＡＭ、Ｒａｍｂｕｓ ＲＡＭなどのコンピュータシステムメモリもしくはランダムアクセスメモリ、または、フラッシュメモリ、ハードウェアレジスタ、磁気媒体（たとえば、ハードドライブ）、もしくは光記憶装置などの不揮発性メモリを含むことを意図する。記憶媒体は、他のタイプのメモリまたはそれらの組合せも備えることができる。「記憶媒体」という用語は、２つ以上の記憶媒体を含むことができる。

コンピュータシステム−パーソナルコンピュータシステム（ＰＣ）、メインフレームコンピュータシステム、ワークステーション、ネットワークアプライアンス、インターネットアプライアンス、携帯電話、スマートフォン、ラップトップ、ノートブック、ネットブック、またはタブレットコンピュータシステム、携帯情報端末（ＰＤＡ）、マルチメディアデバイス、または他のデバイスもしくはデバイスの組合せを含む、様々なタイプのモバイルシステム、または固定型（ｓｔａｔｉｏｎａｒｙ）コンピューティングシステム、または処理システムのいずれか。一般に、「コンピュータシステム」という用語は、記憶媒体からの命令を実行する少なくとも１つのプロセッサを有する何らかのデバイス（またはデバイスの組合せ）を包含するように広く定義され得る。

伝送媒体−有線伝送媒体（ツイストペア、光ファイバ、電話配線、電気配線など）またはワイヤレス伝送媒体（電磁スペクトル内の様々なライセンスされた帯域またはライセンスされていない帯域のいずれかなど）を含む、送信／受信するために使用されることが可能な様々な媒体のいずれか。「動的な伝送媒体」という句は、より具体的には、短時間にわたって、そのＰＨＹレートの大幅な変化を生じやすい伝送媒体を指すことができる。８０２．１１（ＷＬＡＮ／Ｗｉ−Ｆｉ（登録商標））および電力線通信ネットワーク（ＰＬＣ）は、動的な伝送媒体を利用するネットワーキング技術の２つの例である。干渉、チャネルのフェージング、雑音環境などの比較的予測不可能な要因が、８０２．１１ネットワークによって使用されるＩＳＭ帯域と、ＰＬＣネットワークによって使用される電気配線の両方に影響を及ぼすことがある。

ストリーム−「フロー」とも呼ばれる。当業者には一般に理解されるように、ストリームという用語は、何らかの一般的な特性を共有する、経時的に利用できるデータ要素のシーケンスを指すことができる。一例として、ストリームのデータ要素は、同じ送信元アドレスと宛先ＩＰアドレスとポートとを有することがある。いくつかの実施形態では、この句は、一般的に意図された（たとえば、逐次的）順序で、一緒に使用するためのデータパケットのシーケンスを指すために使用されることがある。たとえば、ストリームは、ビデオ（たとえば、ビデオストリーム）を示すために適用によって使用され得るパケットのシーケンスを含むことがある。

図１
図１は、複数のネットワーク（たとえば、異なる伝送媒体、または場合によっては複数の伝送媒体を利用することができるネットワークの各々）を介して結合されたいくつかのデバイス１０２ａ、１０２ｂ、…１０２ｎを含む例示的なハイブリッドネットワーク１００を示す。ネットワーキング技術としては、Ｗｉ−Ｆｉ（たとえば、その伝送媒体として、２．４ＧＨｚ、５ＧＨｚ、および／または別のＩＳＭ帯域を使用する）、電力線通信（たとえば、その伝送媒体として、電気配線を使用する）、イーサネット（たとえば、ツイストペア、光ファイバ、および／または他の有線伝送媒体を使用する）、および／または他の様々なネットワーキング技術／伝送媒体のいずれかがあり得る。図１は１つの考えられるハイブリッドネットワークを示すが、図示のネットワーキング技術に加えて、またはその代わりに、他のネットワーキング技術が、本開示の実施形態により、様々な構成のいずれかの形で使用されてよいことを理解されたい。

図２
図２は、本開示の１つまたは複数の実施形態を実施するように構成された電子デバイス２００の一実施形態のブロック図である。いくつかの実装形態では、電子デバイス２００は、デスクトップコンピュータ、ラップトップコンピュータ、タブレットコンピュータ、携帯電話、スマートアプライアンス、電力線通信デバイス、ゲームコンソール、ネットワークブリッジングデバイス、または複数の通信ネットワークにわたって通信するように構成されたハイブリッド通信ユニットを備える他の電子システムの１つであってよい。電子デバイス２００は、（場合によっては、複数のプロセッサと、複数のコアと、複数のノードとを含む、および／またはマルチスレッドを実施する、など）プロセッサユニット２０２を含む。電子デバイス２００は、メモリユニット２０６を含む。メモリユニット２０６は、システムメモリ（たとえば、キャッシュ、ＳＲＡＭ、ＤＲＡＭ、ゼロコンデンサＲＡＭ、ツイントランジスタＲＡＭ、ｅＤＲＡＭ、ＥＤＯ ＲＡＭ、ＤＤＲ ＲＡＭ、ＥＥＰＲＯＭ（登録商標）、ＮＲＡＭ、ＲＲＡＭ（登録商標）、ＳＯＮＯＳ、ＰＲＡＭなどの１つまたは複数）であってもよいし、機械可読媒体の上記ですでに説明した考えられる実現物のいずれか１つまたは複数であってもよい。電子デバイス２００は、バス２１０（たとえば、ＰＣＩ、ＩＳＡ、ＰＣＩ−Ｅｘｐｒｅｓｓ、ＨｙｐｅｒＴｒａｎｓｐｏｒｔ（登録商標）、ＩｎｆｉｎｉＢａｎｄ（登録商標）、ＮｕＢｕｓ、ＡＨＢ、ＡＸＩなど）、ワイヤレスネットワークインターフェース（たとえば、ＷＬＡＮインターフェース、ブルートゥース（登録商標）インターフェース、ＷｉＭＡＸインターフェース、ＺｉｇＢｅｅ（登録商標）インターフェース、ワイヤレスＵＳＢインターフェースなど）の１つまたは複数を含み得るネットワークインターフェース２０４、および／または有線ネットワークインターフェース（たとえば、電力線通信インターフェース、イーサネットインターフェースなど）も含む。いくつかの実装形態では、電子デバイス２００は、複数のネットワークインターフェースを備えることができる−その各々は、電子デバイス２００を異なる通信ネットワークに結合する。たとえば、電子デバイス２００は、電力線通信インターフェースと、イーサネットインターフェースと、電子デバイス２００を電力線通信ネットワークセグメント、イーサネット、ワイヤレスローカルエリアネットワークにそれぞれ結合するＷＬＡＮインターフェースとを備えることができる。

電子デバイス２００は、通信ユニット２０８も含む。通信ユニット２０８は、ハイブリッド制御エンティティ２１２と、ハイブリッドブリッジ２１４とを備えることができる。ハイブリッド制御エンティティ２１２およびハイブリッドブリッジ２１４は、複数の、場合によっては動的な伝送媒体を使用するストリームの送信および／または受信に関連するいくつかの技術のいずれかを実行するように構成され得る。たとえば、ハイブリッド制御エンティティ２１２および／またはハイブリッドブリッジ２１４は、一組の実施形態による図４〜７の方法のいずれかまたはすべてを実施するように構成され得る。これらの機能のいずれか１つは、ハードウェア内で、および／またはプロセッサユニット２０２（たとえば、メモリユニット２０６などの記憶媒体上に記憶されたプログラム命令を実行する）上で、部分的に（または完全に）実施され得る。たとえば、機能は、特定用途向け集積回路を用いて、プロセッサユニット２０２内で実施される論理内で、またはカード周辺デバイス上のコプロセッサ内などで、実施され得る。さらに、実現物としては、図２で図示されない、上記よりも少ないまたは追加の構成要素（たとえば、ビデオカード、オーディオカード、追加のネットワークインターフェース、周辺デバイスなど）があり得る。プロセッサユニット２０２、メモリユニット２０６、およびネットワークインターフェース２０４は、バス２１０に結合される。メモリユニット２０６は、バス２１０に結合されるように示されているが、プロセッサユニット２０２に結合されてもよい。

図３
一実装形態では、図３に示されるように、ネットワーキング機能のハイブリッドデバイス１０２ａ…１０２ｎは、国際標準化メカニズム（ＩＳＯ）のオープンシステム間相互接続（ＯＳＩ）参照モデルと合致する、「レイヤード」アプローチを使用してサブ機能に分割され得る。ネットワークプロトコルレイヤのセットは、「プロトコルスタック」と呼ばれることがある。図３は、複数のネットワークインターフェースを実施するデバイス１０２のための例示的なプロトコルスタックを示す。図３の例では、ハイブリッドデバイス１０２は、２つの通信インターフェースを含む。したがって、ハイブリッドデバイス１０２は、２つの物理（ＰＨＹ）レイヤ３０２および３０４と、２つの対応するメディアアクセス制御（ＭＡＣ）レイヤ３０６および３０８とを備える。ＭＡＣレイヤ３０６およびＰＨＹ３０２レイヤは、デバイス１０２を１つの通信ネットワークセグメント３２２（たとえば、イーサネット）に結合する。同様に、ＭＡＣレイヤ３０８およびＰＨＹレイヤ３０４は、ハイブリッドデバイス１０２を別の通信ネットワークセグメント３２４（たとえば、電力線通信ネットワーク）に結合する。通信ネットワークセグメント３２２および３２４は各々、ハイブリッド通信ネットワークなどのブリッジ接続された拡張ネットワークの一部分とすることができることに留意されたい。デバイス１０２はネットワークレイヤ３１２を備える。ネットワークレイヤ３１２は、インターネットプロトコルバージョン４（ＩＰｖ４）通信プロトコル、インターネットプロトコルバージョン６（ＩＰｖ６）通信プロトコル、ＡｐｐｌｅＴａｌｋ（登録商標）通信プロトコル、または他の適切なネットワークレイヤプロトコルを実施することができる。デバイス１０２はまた、ネットワークレイヤ３１２とＭＡＣレイヤ３０６および３０８との間で「ハイブリッド適応レイヤ」３１０を実施する。一例では、図３に示されるように、ハイブリッド適応レイヤ３１０は、ハイブリッド制御エンティティ２１２、ハイブリッドブリッジ２１４、および／または本開示の実施形態を実施するように構成された他のモジュールを備えることができる。デバイス１０２は、ネットワークレイヤ３１２を越えて動作するトランスポートレイヤ３１４も備える。ハイブリッドデバイス１０２は、伝送制御プロトコル（ＴＣＰ）、ユーザデータグラムプロトコル（ＵＤＰ）、および／またはハイブリッドデバイス１０２によって実施されるネットワークレイヤプロトコルに応じた他の適切なトランスポートレイヤプロトコルを実施することができる。ハイブリッドデバイス１０２は、他のデバイスとの通信のためにプロトコルスタックを利用することができる３つのアプリケーション３１６と３１８と３２０も備える。

いくつかの実装形態では、アプリケーションレイヤ（アプリケーション３１６と３１８と３２０とを備える）、トランスポートレイヤ３１４、およびネットワークレイヤ３１２は、「上位プロトコルレイヤ」と総称され得る。ＭＡＣレイヤ３０６および３０８ならびにＰＨＹレイヤ３０２および３０４は、「下位プロトコルレイヤ」と総称され得る。ハイブリッド適応レイヤ３１０は、上位プロトコルレイヤ（たとえば、実施される各上位レイヤプロトコル型に対する単一のネットワークレイヤおよびトランスポートレイヤ）の単一セットを用いて、ハイブリッドデバイス１０２内のネットワーク通信を管理するための機能を実施することができるが、複数のネットワークインターフェース（たとえば、複数のＰＨＹレイヤおよびＭＡＣレイヤ）を用いて実施することもできる。一実装形態では、ハイブリッド適応レイヤ３１０は、ネットワークリソースを管理するために、およびプロトコルスタックの上位レイヤに対してトランスペアレントである迅速なパケットルート変更を行うために、下位のＭＡＣレイヤ３０６および３０８とインターフェースすることができる。ハイブリッド適応レイヤ３１０は、送信元ハイブリッドデバイス１０２が単一のＭＡＣレイヤと対応する単一のＰＨＹレイヤとをのみ備えるかのように上位プロトコルレイヤが動作することを可能にすることもできる。図３に示されるプロトコルスタックは、ハイブリッドデバイス１０２のアーキテクチャの一実施形態を示すことに留意されたい。他の実装形態では、ハイブリッドデバイス（複数可）１０２は、ネットワーキング技術および実施され得る任意選択のプロトコルに応じて、他の適切なレイヤまたはサブレイヤを備えることができる。たとえば、いくつかのネットワーキング技術は、ＭＡＣレイヤの上でイーサネットコンバージェンスレイヤを実施することができる。別の例として、いくつかのネットワーキング技術は、論理リンク制御（ＬＬＣ）プロトコルレイヤを含むことができる。そのうえ、いくつかの実装形態では、１つまたは複数の他のサブレイヤが、本明細書において説明する機能を実行することができる。

図４〜図８
図４〜図７は、複数の伝送媒体を使用したネットワーク通信に関連するいくつかの方法を示すフローチャート図である。図４〜図７に関して以下で説明されるステップは特定の順序で示されているが、様々な実施形態によれば、ステップの１つまたは複数は、省略してもよいし、繰り返してもよいし、示されている順序と異なる順序で実行してもよいことに留意されたい。必要に応じて、１つまたは複数の追加ステップが、同じくまたは代替的に追加されてよい。いくつかの実施形態では、方法の１つまたは複数（または方法の１つもしくは複数の１つもしくは複数のステップ）が互いに組み合わされてもよい。

図４は、あるデバイスが第２のデバイスにストリームを送信するための方法の実施形態を示すフローチャート図である。この方法を実施するデバイスは、複数の伝送媒体を介して第２のデバイスに結合され得る。たとえば、いくつかの実施形態では、第１のデバイスおよび第２のデバイスは、図１に示されるデバイスの２つであってよい。方法を実施するシステムは、いくつかの実施形態では、図２に示され、図２に関して説明されるようなシステムであってよい。方法を実施するシステムは、いくつかの実施形態では、図３に示され、図３に関して説明されるようなＯＳＩプロトコルスタックを実施することができる。たとえば、一組の実施形態では、方法は、たとえばハイブリッド制御エンティティ２１２および／またはハイブリッドブリッジ２１４によって、ハイブリッド適応レイヤ３１０で実施され得る。他の実施形態では、方法は、別のレイヤまたはいくつかのレイヤで実施され得る（たとえば、いくつかのレイヤの各々は、方法の要素を実施することができる）。方法は、次のように実行され得る。

４０２では、複数の伝送媒体の各々のパス特性が決定され得る。いくつかの実施形態では、伝送媒体の少なくとも１つは、本質的には、実質的に動的であることがある。たとえば、伝送媒体としては、Ｗｉ−Ｆｉ（たとえば、２．４ＧＨｚ、５ＧＨｚ、および／または別のＩＳＭ周波数帯域を使用する）、ＰＬＣ（たとえば、電気配線を使用する）、および／または様々な要因（たとえば、干渉、チャネルのフェージング、または他の要因を含む）に応じて経時的にＰＨＹレートが変わることができる、１つまたは複数の他の実質的に動的な伝送媒体があり得る。伝送媒体は、本質的には実質的に動的でない１つまたは複数の伝送媒体、すなわち、イーサネットなどの、ＰＨＹレートが実質的に静的であり経時的に予測可能であることができる伝送媒体も含むことができる。

いくつかの実施形態によれば、各伝送媒体に対して決定されるパス特性としては、各伝送媒体の１つもしくは複数の現在の媒体利用率、最大媒体利用率、および／またはリンク容量があり得る。いくつかの実施形態によれば、現在の媒体利用率は、伝送媒体がビジーである時間のパーセンテージとすることができる。最大媒体利用率は、最大許容媒体利用率とすることができる。たとえば、現在の媒体利用率が最大媒体利用率よりも高い場合、伝送媒体はオーバーサブスクライブされる（oversubscribed）または容量超過と見なされることがあり、これにより、１つまたは複数の負荷バランシングの判定がトリガされることがある。いくつかの実施形態では、最大媒体利用率は、１００％未満に設定されることがあり、すなわち、所望の性能を提供するために余裕が維持される、たとえば、個々のストリーム媒体利用率の変化性に相当することができる。言い換えれば、個々のパケットストリームの媒体使用率（個々のストリームの「ストリーム媒体利用率」）は経時的に変わり得るので、媒体上で送信されるようにスケジュールされたトラフィックの量がそのトラフィックをサポートする媒体の容量を超える前にトラフィックを媒体から移すことによって伝送媒体上で通信されるストリームの性能に悪影響を及ぼすことを回避するために、最大媒体利用率を１００％未満に設定することが望ましいことがある。伝送媒体の最大媒体利用率は、伝送媒体／通信インターフェースのタイプによって、および／または様々な実施形態により伝送媒体を使用するようにスケジュールされたストリームのタイプに応じて（たとえば、ストリーム内容、パケットのタイプ、および／または優先レベルに基づいて）、異なってよい。特定の宛先に対する伝送媒体のリンク容量は、送信元デバイスと宛先デバイスの間の伝送媒体の利用可能なデータ搬送容量とすることができる。言い換えれば、伝送媒体のリンク容量は、伝送媒体がどれほど多くの追加データを特定のデバイスに、たとえば、メガビット毎秒（Ｍｂｐｓ）、ギガビット毎秒（Ｇｂｐｓ）、またはデータレートの何らかの他の測定単位で、所与の時刻に送信することが可能であるかの尺度である。いくつかの実施形態では、リンク容量は、各伝送媒体によってアクセス可能である可能な宛先ごとに推定され得る。たとえば、一組の実施形態によれば、デバイスが、ＰＬＣ、２．４ＧＨｚのＷｉ−Ｆｉ、または５ＧＨｚのＷｉ−Ｆｉのいずれかを使用して２つの他のデバイスと通信するように構成される場合、６つのリンク容量が決定され得る。リンク容量は、いくつかの実施形態では、最大媒体利用率、伝送媒体のＰＨＹレート、および誤り率に対応することができる。いくつかの実施形態では、他の要因が、同じくまたは代替的に、リンク容量の計算／推定に含まれてよい。たとえば、一組の実施形態では、優先順位のより高いストリームに対するリンク容量の計算が、優先順位のより低いストリームに代わる可能性をもたらし得るので、伝送媒体のリンク容量は、ストリームのタイプによって、たとえば優先順位および／またはコンテンツタイプに応じて、異なってよい。

いくつかの実施形態では、これらのパス特性が、システムが利用可能な伝送媒体のすべて（動的な伝送媒体と静的な伝送媒体の両方を潜在的に含む）に対して決定され得ることに留意されたい。これらのパス特性に加えて（または、これらのパス特性の１つまたは複数の代わりに）、１つまたは複数の他の特性（場合によっては、媒体固有特性を含む）が伝送媒体の１つまたは複数に対して決定され得る。たとえば、いくつかの実施形態では、有効媒体利用率およびリンク容量がＷｉ−Ｆｉ接続に対して決定され得る。これらの得られたパス特性は、そのような接続はアクセスポイントを通る中継（たとえば、ワイヤレスルータ）を含むことができることの説明となるように調整され得る。さらに、いくつかの実施形態では、各伝送媒体上の個々のストリーム（たとえば、パケットストリーム）の使用特性が決定され得る。たとえば、いくつかの実施形態では、推定されたストリーム媒体利用率が、伝送媒体上で送信される各ストリームに対して決定され得る。上記で述べたように、ストリーム媒体利用率は、どれくらい多くのストリームが伝送媒体を使用しているかの尺度（たとえば、時間のパーセンテージ）とすることができる。

４０４では、第１の伝送媒体は、決定されたパス特性に基づいて、第１のストリームに対する複数の伝送媒体から選択され得る。第１のストリームは、「新しい」ストリーム、すなわち、パケットがまだ送信されていないストリームであってよい。第１のストリームは、複数の伝送媒体を介して第１のデバイスに結合された第２のデバイスへの送信のためのものとすることができる。言い換えれば、第２のデバイスは、第１のデバイスから複数の伝送媒体のいずれかを介して第１のストリームのパケットを受信することを可能とすることができる。したがって、第１のデバイスは、どの伝送媒体（パス）を使用して第１のストリームのパケットを第２のデバイスに最初に送信するか決定することが必要なことがある。

実際のパス選択アルゴリズムは、たとえばどのくらい多くの伝送媒体が利用可能か、および各伝送媒体が第１のストリームの宛先デバイスに対してどのくらい多くのリンク容量を現在有するかに応じて、決定されたパス特性を様々な方法のいずれかにおいて使用することができる。パス選択アルゴリズムはまた、第１のストリームのストリーム特性（たとえば、コンテンツタイプ（ビデオ、音声、その他など）、パケットタイプ（たとえば、ＵＤＰ、ＴＣＰなど）、優先レベル（たとえば、低、中、高））に左右されることがある。場合によっては、これらのストリーム特性は、自動的にまたは手動で相関させることができる。たとえば、いくつかの実施形態では、ビデオコンテンツストリームは、高い優先レベルを自動的に受信することができる。その他の自動または手動による優先権の相関も可能である。

一組の実施形態では、第１の伝送媒体は、複数の伝送媒体の中で最大の利用可能リンク容量を有することに基づいて選択され得る。いくつかの実施形態では、第１の伝送媒体は、第１のストリームのタイプの追加ストリームをサポートするのに十分なリンク容量（たとえば、ある一定の閾値を上回るリンク容量）を有する複数の伝送媒体の中で、第１のストリームのタイプのストリームにとって好ましい媒体とすることができる。

いくつかの実施形態では、パス選択プロセスは、複数のタイプのストリームの各々に対する伝送媒体の好ましい順序を決定することを含むことができる。いくつかの実施形態では、この複数のタイプのストリームの各々に対する伝送媒体の好ましい順序は、新しいストリームに主に適用することができる。たとえば、好ましい順序は、新しいストリームを伝送媒体に割り当てるために使用され得るが、ストリームがいったん伝送媒体に割り当てられると、そのストリームのパケットは、その媒体上に引き続き無期限に（たとえば、オーバーサブスクリプションまたは他のイベントのために再び割り当てられない限り）送信され得る。

一実施形態では、ストリームのカテゴリ化は、ごく単純なことがある。たとえば、ＵＤＰパケットは、第１の好ましい順序の伝送媒体に割り当てられることがあり、非ＵＤＰパケットは、第２の好ましい順序の伝送媒体に割り当てられ得る。いくつかの実施形態では、タイプに基づくストリームの分類またはカテゴリ化は、まったく行われなくてよい。そのような実施形態では、すべてのタイプのストリームは、等しく扱われ得る。しかしながら、一般的に、ストリーム特性に応じてより広範囲のサービス品質を提供するために、ストリームタイプの区別および分類のためのより高い能力を提供することが望ましいことがあり、そのため、いくつかの実施形態では、ストリームは、３つ以上のクラスに分類されることがある。

一般的に言えば、優先順位の高い（たとえば、コンテンツタイプ（たとえば、音声、ビデオ、データなど）、パケット構造（ＴＣＰ、ＵＤＰなど）、手動による割り当て、または別の基準に基づいて）パケットストリームを、（たとえば、最も良い性能を優先順位の高いストリームに提供するために）より高い信頼性および／またはより大きなリンク容量を有する伝送媒体に割り当てることが好ましいことがある。しかしながら、他の要因が、同じくまたは代替的に、所与のタイプのストリームに対する伝送媒体の好ましい順序を決定する際に重要な役割を果たすことがある。

いくつかの実施形態では、異なるストリームタイプに対する伝送媒体の好ましい順序の割り当ては、パス特性の変更に基づいて頻繁に更新され得ることに留意されたい。たとえば、伝送媒体の媒体利用率が著しく増加する、および／または媒体がオーバーサブスクライブした場合、その伝送媒体は、追加ストリームをその伝送媒体に割り当てることを回避するために、それ自体の媒体利用率が減少し、それ自体のリンク容量が増加する（たとえば、１つまたは複数のストリームが終了したまたは異なる伝送媒体に再び割り当てられたので）まで、１つまたは複数のタイプのストリームに対する伝送媒体の好ましい順序の最後になることができる。

いくつかの実施形態では、第１の伝送媒体がいったん第１のストリームの送信のために選択されると、第１のストリームの後続パケットが送信のために第１の伝送媒体にルーティングされるべきであることを示す情報が格納され得る。

４０６では、第１のストリームの第１の複数のパケットが、第１の伝送媒体上で送信され得る。実施形態に応じて、第１のストリームの第１の複数のパケットは、個別におよび／またはバーストで（すなわち、複数のパケットからなるグループで）送信されてもよく、潜在的には、他のストリームの個々のパケットまたはパケットバーストは、第１のストリームの個々のパケットまたはパケットバーストの合間に第１の伝送媒体上で送信される。ステップ４０６では、第１のストリームの第１の複数のパケットが、第１のストリームの送信のための第１の伝送媒体の選択に基づいて、第１の伝送媒体上での送信のために第１の伝送媒体にルーティングされ得る。いくつかの実施形態では、ルーティングは、具体的には、第１のストリームのパケットは送信のために第１の伝送媒体にルーティングされるべきであることを示す格納された情報に基づくことができる。たとえば、いくつかの実施形態では、第１のストリームの新しいパケットが第１のデバイスによって送信のために受信されると、この新しいパケットを第１のストリームの一部と識別する、新しいパケット内の情報が、第１のストリームのパケットは送信のために第１の伝送媒体にルーティングされるべきであることを示す格納された情報と組み合わせて、新しいパケットのルーティングを決定するために使用され得る。

いくつかの実施形態では、１つまたは複数の他のパケットストリームは、たとえば第１のストリームの第１の伝送媒体への割り当ての前および／または後に、複数の伝送媒体の第１の伝送媒体および／または１つもしくは複数の他の伝送媒体に割り当てられ、その上で送信され得る。いくつかの実施形態では、そのような他のストリームのためのパス選択が同様に実行され得る。たとえば、１つまたは複数のテーブルまたは他のデータ構造が、異なるタイプのストリームに対する複数の伝送媒体の現在の好ましい選択順序を追跡するために、およびどの伝送媒体がどのアクティブなパケットストリームに現在割り当てられているか追跡するために、維持され得る。いくつかの実施形態では、パケットストリームがアクティブでなくなると、それらのパケットストリームに関連する格納された情報は、テーブル（複数可）または他のデータ構造（複数可）から除去され得る。

いくつかの実施形態では、各伝送媒体に割り当てられた１つまたは複数のアクティブなパケットストリームは異なる宛先アドレスを有することができることにも留意されたい。たとえば、上記で述べたように、いくつかの実施形態では、各伝送媒体は、方法を実施するデバイスを複数の他のデバイスに連結することができる。したがって、１つまたは複数のストリームが同じ伝送媒体を使用して異なる宛先デバイスに送信され得ることが可能なことがある。

４０８では、第１の伝送媒体の現在の媒体利用率が第１の閾値を超えたと決定され得る。これは、いくつかの実施形態では、たとえば媒体条件の変更および／または追加ストリームが第１の伝送媒体に割り当てられた結果として、第１の複数のパケット（または第１の複数のパケットの少なくとも一部分）が第１の伝送媒体上で送信された後で行われ得る。たとえば、現在の媒体利用率が第１の伝送媒体の最大媒体利用率を超えたと決定され得る。上記で述べたように、これは、本明細書ではオーバーサブスクリプションイベントと呼ばれることがあり、第１の媒体がオーバーサブスクライブしたことを示すことができる。第１の伝送媒体上でのストリームの所望の性能およびサービス品質を維持するために、第１の伝送媒体上で現在送信されている１つまたは複数のストリームを別の伝送媒体に（部分的または完全に）移ることが望ましいことがある。一般的に言えば、たとえば、複数の通信インターフェースを使用する送信ストリームに関連するオーバーヘッドを回避するために、ストリームを伝送媒体間で全体として移ることが好ましいことがある。しかしながら、いくつかの状況（たとえば、利用可能な伝送媒体が、その全体が第１の伝送媒体上で現在送信されている何らかのストリームの送信をサポートするのに十分なリンク容量を持たない）では、ストリームの送信を２つ以上の通信インターフェース間で分割することが望ましいことがある。

４１０ａでは、第１のストリームは、第２の伝送媒体上での送信のために選択され得る。第１のストリームは、第１の伝送媒体の現在の媒体利用率が第１の閾値を超えると決定したことに基づいて、第２の伝送媒体上での送信のために選択され得る。いくつかの実施形態では、（たとえば、第１の伝送媒体の代わりに）第２の伝送媒体上での送信に第１のストリームを選択するためのプロセスは、初期パス選択のためのプロセスとの類似点を含むことができる。たとえば、（すなわち、オーバーサブスクライブした）第１の伝送媒体上で送信される第１のストリームおよび何らかの他のストリームの特性は、第２の伝送媒体に移動されるべき第１のストリームを選択する際に考慮され得る。同様に、第２の伝送媒体および複数の伝送媒体の何らかの他の伝送媒体の特性は、第１のストリームの送信のために第２の伝送媒体を選択する際に考慮され得る。

いくつかの実施形態では、第１の伝送媒体上で現在送信されているストリームを選択して異なる伝送媒体に再び割り当てるプロセスは、第１の媒体上で送信されている各ストリームのストリーム媒体利用率を決定することを含むことができる。一組の実施形態によれば、最大のストリーム媒体利用率を持つストリームは、好ましくは、別の伝送媒体への再割り当てのために選択され得る。別の組の実施形態では、最小のストリーム媒体利用率を持つストリームは、好ましくは、別の伝送媒体への再割り当てのために選択され得る。いくつかの実施形態では、ストリームの優先順位も考慮され得る。たとえば、いくつかの実施形態では、最低の優先レベルを持つストリームが、好ましくは、再割り当てのために選択されてもよいし、最低の優先レベルを持つストリームの中で最大（または最小）のストリーム媒体利用率を持つストリームが、好ましくは、再割り当てのために選択されてもよい。

他の実施形態では、他の要因が、ストリーム優先順位およびストリーム媒体利用率に加えて、またはこれらの代わりに、どのストリームを新しい伝送媒体に再び割り当てるべきか決定する際に考慮され得る。たとえば、伝送媒体の特性自体が、どのストリームが再割り当てのために選択されるかに影響を及ぼすことができる。いくつかの実施形態では、利用可能な伝送媒体の特性が、同じくまたは代替的に、ストリームが再び割り当てられるべき新しい伝送媒体を選択する際に考慮され得る。たとえば、複数の伝送媒体の各々の現在のリンク容量は、新しい伝送媒体（たとえば、第２の伝送媒体）上での送信にストリーム（たとえば、第１のストリーム）を選択する際と、再割り当てのために選択されたストリーム（たとえば、第１のストリーム）をその上で送信するべき新しい伝送媒体（たとえば、第２の伝送媒体）を選択する際の両方で、決定および考慮され得る。上記で述べたように、いくつかの実施形態では、最低の優先順位および／または最大のストリーム媒体利用率を持つストリームを再割り当てのために選択することが好ましいことがある。しかしながら、最低の優先順位および／または最高のストリーム媒体利用率を持つストリームを追加するのに十分なリンク容量を持つ利用可能な伝送媒体がない場合、より高い優先順位および／またはより低いストリーム媒体利用率を持つストリームが、再割り当てのために選択されてよい。

例示的な一組の実施形態では、再割り当てプロセスは、次のように実行され得る。最大の利用可能リンク容量を持つ伝送媒体は、ストリームを第１の伝送媒体からそれ自体に再び割り当てさせるために選択され得る。選択された伝送媒体が、（たとえば、ストリーム優先順位、ストリーム媒体利用率、または他の要因の結果として）再割り当てに好ましく選択されたストリームに対して十分なリンク容量を有するかどうか決定され得る。選択された伝送媒体が、そのストリームに対して十分なリンク容量を有する場合、そのストリームは、選択された伝送媒体に再び割り当てられ得る。選択された伝送媒体が、そのストリームに対して十分なリンク容量を持たない場合、選択された伝送媒体が、次のストリームに対して十分なリンク容量を有するかどうか決定され得る。このプロセスは、許容可能なストリームが、選択された伝送媒体への再割り当てのために選択されるまで、そのような方法で継続され得る。許容可能なストリームが、全体として再割り当てのために選択されない場合（たとえば、第１の伝送媒体上での現在送信されているストリームのいずれかをサポートするのに十分なリンク容量を持つ利用可能な伝送媒体がない場合、または別の理由で）、方法は、あるいは、ストリームが部分的に再び割り当てられる、たとえば分割／アグリゲーションされ得るかどうか決定するために、ステップ４１０ｂに進むことができる。

いくつかの実施形態では、インジケーションが、第１のストリームが第２の伝送媒体に再び割り当てられた第２のデバイスに提供され得る。インジケーションは、１つまたは複数の制御パケットなどの制御メッセージを含んでもよいし、別の形をとってもよい。あるいは、いくつかの実施形態では、インジケーションが提供されなくてもよく、第２のデバイスは、第２の伝送媒体上で第１のストリームのパケットを受信することのみに基づいて、第１のストリームが第２の伝送媒体に再び割り当てられたと決定するように構成され得る。

４１２ａでは、第１のストリームの第２の複数のパケットが第２の伝送媒体上で送信され得る。第１のストリームの第２の複数のパケットは、（たとえば、４１０ａで）第２の伝送媒体上での送信に第１のストリームを選択したことに基づいて、第２の伝送媒体上で送信され得る。第１のストリームが第２の伝送媒体上で送信されるべきであると（たとえば、第１の伝送媒体のオーバーサブスクリプションならびに第２の伝送媒体の１つもしくは複数のパス特性および／または第１のストリームの１つもしくは複数のストリーム特性に基づく選択アルゴリズムの結果として）決定された後で、第１のストリームの後続パケットが第２の伝送媒体にルーティングされるべきであることを示す情報が格納され得る。たとえば、どの伝送媒体に各アクティブなストリームが割り当てられるべきか示す情報を格納するテーブルまたは他のデータ構造がある場合、このテーブルは、第１のストリームのパケットが第２の伝送媒体にルーティングされるべきであることを示すように更新され得る。

第１のストリームが第２の伝送媒体に再び割り当てられた後、第１のストリームのパケットは、たとえば、第１のストリームのパケットが第２の伝送媒体にルーティングされるべきであることを示す更新されたテーブルまたは他のデータ構造に基づいて、第１の伝送媒体上で送信されなくなってもよい。第１の伝送媒体のオーバーサブスクリプションのレベルに応じて、第１の伝送媒体は、第１のストリームの再割り当ての後でオーバサブスクライブしなくなってもよい。この場合、少なくとも、別のオーバーサブスクリプションイベントが発生する（または、伝送媒体が故障する、その場合、伝送媒体上で送信されているすべてのストリームは新しい伝送媒体に再び割り当てられ得る）まで、ストリームのさらなる再割り当てが必要であることがある。しかしながら、第１のストリームの再割り当ての後で第１の伝送媒体が依然としてオーバーサブスクライブする場合、別のオーバーサブスクリプションイベントが発生することができる、いくつかの実施形態では、これによって、第１の伝送媒体から離れるように別のストリームの再割り当てがトリガされることがある。いくつかの実施形態では、オーバーサブスクリプションイベントによりストリームを伝送媒体から移すことと、伝送媒体の媒体利用率を再測定することの間に、遅延（たとえば、構成可能な遅延）があり得ることに留意されたい。これは、更新されたデータ／統計が使用され、伝送媒体がより古いデータ／統計に基づいて、依然としてオーバーサブスクライブしていると誤って決定されないことを確実にするために、望ましいことがある。

上記で述べたように、いくつかの実施形態によれば、第１の伝送媒体上で送信されているストリームが、別の伝送媒体のオーバーサブスクリプションを引き起こすことなく、全体として別の伝送媒体に再び割り当てられ得ない場合、あるストリームが、複数の伝送媒体上での送信のために選択され得る。したがって、そのような場合、ステップ４１０ａの代わりに、４１０ｂにおいて、第１のストリームが、第１の伝送媒体と第２の伝送媒体の両方の上での送信のために選択され得る。したがって、いくつかの実施形態では、第１のストリームは、第１の伝送媒体の現在の媒体利用率が第１の閾値を超えると決定したことに基づいて、および複数の伝送媒体の中で、第１の伝送媒体上で現在送信されているいずれかのストリームが代替伝送媒体上で完全に送信されるのに十分な利用可能なリンク容量（たとえば、伝送媒体によってアクセス可能ないずれかの宛先デバイスに対する）を有する代替伝送媒体がないと決定したことにも基づいて、第１の伝送媒体と第２の伝送媒体の両方の上での送信のために選択され得る。

さらに、いくつかの実施形態では、第２のデバイスはストリームをアグリゲーションするように構成されると決定され得る。この決定は、いくつかの実施形態では、第１のデバイスと第２のデバイスの間で送信される初期構成メッセージに基づいて行われ得る。あるいは、第１のデバイスは、第２のデバイスに問い合わせて、第２のデバイスはストリームをアグリゲーションするように構成されることを示す肯定応答を受信してもよいし、しかしながら、第２のデバイスのストリームをアグリゲーションする機能の確認をせずに、第１のストリームを分割しようとするだけでもよい。しかしながら、一般に、第１のストリームを複数の伝送媒体に分割する前に、第２のデバイスのストリームをアグリゲーションする機能の確認を受信することが好ましいことがある。いくつかの実施形態では、第１のデバイスが、第２のデバイスはストリームをアグリゲーションするように構成されていないというインジケーションを受信した場合、第１のデバイスは、第１のストリームを分割しないことができる。この場合、ストリーム分割／アグリゲーションを伴わない最良の取組みによる負荷バランシングの試みが行われ得る。あるいは、第１の伝送媒体を使用して異なるデバイスに送信されているストリームは、たとえば他のデバイスがストリームアグリゲーションをサポートする場合、分割のために選択され得る。

いくつかの実施形態では、ストリームを再び割り当てるべき２つの伝送媒体の選択は、単一の新しい伝送媒体への再割り当てにストリームを選択するよりも複雑になることがある。上記で述べたように、送信デバイスにおけるストリームの分割および受信デバイスにおける分割されたストリームのアグリゲーションは、著しい追加オーバーヘッドを招くことがあり、すべてのストリームを１つの伝送媒体または別の伝送媒体上で完全に送信するほど効率的でない、個々の伝送媒体の使用となることがある。しかしながら、少なくとも１つの伝送媒体のオーバーサブスクリプションを引き起こすことなくすべてのアクティブなストリームに対応するように複数の伝送媒体を負荷バランシングすることが困難または不可能な状況では、他のオプションが好ましいことがある。というのは、他のオプションは、複数の伝送媒体を全体としてより効率的に使用する機会を与えることができるからである。

いくつかの実施形態では、ストリームを再び割り当てるべき２つの伝送媒体および再び割り当てるべきストリームの選択を決定する選択プロセスは、分割を伴わない再割り当てのための伝送媒体およびストリームの選択で使用される同じ特性の多くの使用を含むことができる。たとえば、様々な伝送媒体のリンク容量ならびに第１の伝送媒体上で送信されている個々のストリームのストリーム媒体利用率および／またはタイプ（たとえば、優先順位）は、第１の媒体と第２の伝送媒体の両方への再割り当てのために第１のストリームを選択する際に決定および使用され得る。例示的な一組の実施形態では、最高のリンク容量を持つ２つの伝送媒体が、ストリームをそれらの伝送媒体に再び割り当てさせるために選択され得る。別の組の実施形態では、第１の伝送媒体は、再割り当てのために選択されたストリームの一部分を送信し続けるために自動的に選択されてもよく、残りの伝送媒体のうち最高のリンク容量を持つ伝送媒体は、第２の伝送媒体として選択され得る。必要に応じて、ストリームを再び割り当てるべき２つの伝送媒体を選択するための他のプロセスが代替的に使用されてもよい。

いくつかの実施形態では、単一のストリームを３つ以上の伝送媒体に分割することが望ましくないことがあり、その理由は、この追加の分割およびアグリゲーションによって引き起こされるオーバーヘッドの増加が望ましくないまたは必要ではないことがあるからであることに留意されたい。たとえば、正常な負荷バランシングが、１つのストリームを２つの伝送媒体に分割することによって達成され得ない場合、単一のストリームを３つ以上の伝送媒体に分割するのではなく、第２のストリームを２つの（たとえば、他の）伝送媒体に分割することが望ましいことがある。しかしながら、ストリームを３つ以上の伝送媒体に分割することは、必要に応じて実行され得る。

上記で述べたように、いくつかの実施形態では、複数の伝送媒体への分割および再割り当てのためのストリームの選択は、ストリームの特性および／または伝送媒体の特性に基づくことができる。たとえば、一組の実施形態では、ストリームを再び割り当てるべき最高のリンク容量を持つ２つの伝送媒体を選択したので、再び割り当てられるべきストリームは、それ自体のストリーム媒体利用率および／またはそれ自体の優先順位に基づいて選択され得る。したがって、一組の実施形態では、ストリーム（たとえば、第１のストリーム）は、最低の優先レベルを有するストリームの中から選択されてもよく、最低の優先レベルを持つストリームの中で選択された伝送媒体によって対応できる最高のストリーム媒体利用率を持つストリームとすることができる。あるいは、たとえば、より低い優先順位を持つ許容できるストリームが見つけられない場合、ストリームは、より高い優先レベルを持つストリームの中から選択されてもよく、より高い優先レベルを有するストリームの中で選択された伝送媒体によって対応できる最高のストリーム媒体利用率を持つストリームとすることができる。他の組の実施形態では、必要に応じて、異なる選択基準を利用することができ、および／または異なる方法で同じ選択基準を使用することができる。たとえば、別の組の実施形態では、最小のストリーム媒体利用率を持つストリームが、好ましくは、選択されてもよく、より高い優先順位を持つストリームは、分割（または何らかの形の再割り当て）から除外されてもよく、および／または最低の優先順位のストリームは、たとえば最良の取組みによる負荷バランシングの試みとして、それ自体が選択された伝送媒体によって対応できるかとは無関係に選択され得る。

いくつかの実施形態では、いったんストリームが再割り当てのために選択されると、ストリーム（たとえば、第１のストリーム）を選択された伝送媒体（たとえば、第１の伝送媒体および第２の伝送媒体）にどのように分割するのが最善か決定するために、さらなる計算が実行され得る。たとえば、どちらの伝送媒体のオーバーサブスクリプションも回避するように第１の伝送媒体にルーティングされる第１のストリームのパケットの割合と、第２の伝送媒体にルーティングされる第１のストリームのパケットの割合とを決定することが望ましいことがある。一組の実施形態では、この計算は、現在の媒体利用率が第１の伝送媒体の最大媒体利用率を超える量を決定することと、少なくとも現在の媒体利用率が第１の伝送媒体の最大媒体利用率を超える量を第２の伝送媒体に再び割り当てる第１のストリームを分割する際に使用するための比を選択することとを含むことができる。

４１２ｂでは、第１のストリームの第２の複数のパケットが、第１の伝送媒体と第２の伝送媒体の両方を使用して送信され得る。第１の伝送媒体と第２の伝送媒体の両方を使用して第１のストリームを送信することは、第１の伝送媒体上で第２の複数のパケットの第１の部分を送信することと、第２の伝送媒体上で第２の複数のパケットの第２の部分を送信することとを含むことができる。いくつかの実施形態では、第１の伝送媒体または第２の伝送媒体のその後のオーバーサブスクリプションを回避するように構成された比（たとえば、おおよその比または正確な比）は、第２の複数のパケットの第１の部分と第２の部分の間で維持され得る。

他のストリーム再割り当て状況と同様に、いくつかの実施形態では、分割／アグリゲーションのために選択されたストリームのパケットは選択された伝送媒体にルーティング可能であることを示す情報は、そのストリームとそれらの伝送媒体とを選択することに基づいて格納され得る。さらに、いくつかの実施形態では、選択されたストリームを分割する際に使用するための比を示す情報が格納され得る。この情報は、テーブルまたは他のデータ構造に格納され得る。たとえば、いくつかの実施形態では、選択されたストリームの以前の伝送媒体割り当てを示す、以前に格納された情報は、選択されたストリームの新しい伝送媒体割り当てと比とを示すために更新され得る。

いくつかの実施形態では、第２の複数のパケットが第１の伝送媒体と第２の伝送媒体の両方を使用して送信されているというインジケーションも、第２のデバイスに提供され得る。一組の実施形態では、アグリゲーション命令（たとえば、アグリゲーションバッファの推奨サイズを含む）を含む制御メッセージは、第１のデバイスによって第２のデバイスに送信されてもよく、第１の伝送媒体と第２の伝送媒体の両方を使用して第２の複数のパケットが送信されていることを示す。これによって、第２のデバイスがアグリゲーションバッファを開始するおよび／または第１のストリームをアグリゲーションするための他の技法を実行することが可能になり得る。いくつかの実施形態では、第２のデバイスが第１のストリームをアグリゲーションする助けとなることを意図する１つまたは複数の技法も実行され得る。

一実施形態では、たとえば第１のストリームがまだシーケンス番号を含んでいない場合、シーケンス番号が第１のストリームのパケットに挿入され得る。シーケンス番号は、第２のデバイスが分割されたストリームを再順序付けする助けとなることができる。ＴＣＰパケットストリームおよびＲＴＰパケットストリームは、本質的に、パケットシーケンス番号を含むことができるが、ＵＤＰパケットストリームは、本質的に、第２のデバイスによってアクセス可能であり、分割されたストリームを再順序付けする際に使用可能なシーケンス番号を含まなくてよい。したがって、いくつかの実施形態では、シーケンス番号は、たとえば、パケットカプセル化（たとえば、ＴＣＰへの変換）、冗長フィールド（いくつかの実施形態ではＶＬＡＮタグなど）へのシーケンス番号の挿入、または別の手段によって、第１のストリームのパケットに挿入され得る。

代替的に、または追加として、いくつかの実施形態では、切り換えマーカパケットが各伝送媒体上のバーストの先頭に挿入され得る。切り換えマーカパケットは、伝送媒体上で通信されているストリームの一部分（「バースト」）の先頭を示すことができる。したがって、１つの伝送媒体上で通信される「ストリームの開始」マーカパケットは、ストリームの次の部分（意図されたパケット順序付けに従って）がその伝送媒体上で通信されていることを示すことができる。いくつかの実施形態では、各ストリームの開始マーカパケットは、その伝送媒体上で送信されようとしているバーストのサイズを示す情報を含むことができる。これによって、いつバーストが完了されたか、したがって場合によっては、いつ次のバーストが異なる伝送媒体上で予想されるはずであるかを受信機が決定することが可能になり得る。

上記で述べたように、いくつかの実施形態では、ストリーム分割／アグリゲーションは、各伝送媒体上で送信されるストリームの割合の比を維持するように実行され得る。これを達成する１つの手段は、各伝送媒体上で異なるバーストサイズを使用することであることができ、バーストサイズは、上記の比に従って構成される。たとえば、２１：３３の比が望ましい場合、２１（または４２などの２１の倍数）パケットのパケットバーストが第１の伝送媒体上で送信されてもよく、一方、３３（または６６などの３３の倍数）のパケットバーストが第２の伝送媒体上で送信され得る。

いくつかの実施形態では、「ストリームの終了」マーカパケットも使用されることがある。たとえば、いくつかの実施形態では、ストリームの開始マーカパケットが、その伝送媒体上で送信されるバーストのサイズを示す情報を含まないことがあるが、ストリームの終了マーカパケットが、バーストが完了された（たとえば、および、現在の時刻において、そのストリームのさらなるパケットがその伝送媒体上で通信されない）ことを受信機に示すためにバーストの終了時に送信され得る。しかしながら、いくつかの実施形態では、ストリームの終了マーカパケットを使用することが望ましくないことがある。その理由は、ストリームの開始マーカパケットにバーストサイズ情報を含むだけに対して、オーバーヘッドの不必要な追加を表すことがあるからである。

したがって、一組の実施形態では、ストリームの開始マーカパケットが、第２の複数のパケットの第１の部分の先頭に挿入され得る（および、いくつかの実施形態では、ストリームの終了マーカパケットが、第２の複数のパケットの第１の部分の終了時に挿入され得る）。同様に、ストリームの開始マーカパケットが、第２の複数のパケットの第２の部分の先頭に挿入され得る（および、いくつかの実施形態では、ストリームの終了マーカパケットが、第２の複数のパケットの第２の部分の終了時に挿入され得る）。切り換えマーカパケットは、意図されたストリームパケット順序に従って第２の複数のパケットをどのようにして再結合するかを第２のデバイスに示すことができ、したがって、受信後、第２の複数のパケットの第１の部分と第２の部分（と、ストリームが分割されている限り、ストリームの開始マーカパケットと、場合によってはストリームの終了マーカパケットとを同様に含むことができる、何らかの後続ストリーム部分）は、順序正しく受信されたかどうかとは無関係に、意図された順序で再結合される。

上記で述べたように、ストリーム分割およびアグリゲーションは、単一の伝送媒体上でストリームを完全に送信することと比較して、追加オーバーヘッドを招くことがある。したがって、いくつかの実施形態では、分割されたストリームを単一の伝送媒体上で完全に送信するのに十分なリンク容量が利用可能になったときに、分割されたストリームを再びマージするために、様々な伝送媒体のリンク容量と様々なストリームのストリーム媒体利用率とをモニタすることが望ましいことがある。たとえば、一組の実施形態では、ある伝送媒体（たとえば、第１の伝送媒体または別の伝送媒体）は、その伝送媒体上で第１のストリームが完全に送信されるのに十分な利用可能なリンク容量を有すると、その後で決定され得る。そのような場合、第１のストリームは、その伝送媒体に完全に再び割り当てられることがあり、第１のストリームの第３の複数のパケットが、その伝送媒体上で送信されてもよく、第３の複数のパケットのすべては、新たに選択された伝送媒体上で送信されてもよい。

図５は、あるデバイスが複数の伝送媒体上で第２のデバイスから第１のストリームを受信するための方法を示すフローチャート図である。いくつかの実施形態によれば、図５の方法のステップは、図４に示され図４に関して説明されるような送信機側の挙動に応答する少なくともいくつかの受信機側の挙動に相当することができる。具体的には、図５は、２つの伝送媒体間でのストリームの分割の開始および／または終了、ならびに分割されたストリームの正常なアグリゲーションおよび正しいパケット順序付けを保証するために受信機によって行われる可能な挙動に関して警告されるプロセスに関連することができる。

この方法を実施するデバイスは、複数の伝送媒体を介して第２のデバイスに結合され得る。たとえば、いくつかの実施形態では、第１のデバイスおよび第２のデバイスは、図１に示されるデバイスのうち２つであってよい。方法を実施するシステムは、いくつかの実施形態では、図２に示され、図２に関して説明されるようなシステムであってよい。方法を実施するシステムは、いくつかの実施形態では、図３に示され、図３に関して説明されるようなＯＳＩプロトコルスタックを実施することができる。たとえば、一組の実施形態では、方法は、たとえばハイブリッド制御エンティティ２１２および／またはハイブリッドブリッジ２１４によって、ハイブリッド適応レイヤ３１０で実施され得る。他の実施形態では、方法は、別のレイヤまたはいくつかのレイヤで実施され得る（たとえば、いくつかのレイヤの各々は、方法の要素を実施することができる）。方法は、次のように実行され得る。

５０２では、第１のストリームの第１の複数のパケットが、第２のデバイスから第１の伝送媒体上で受信され得る。第１の複数のパケットのすべては、第１の伝送媒体上で受信され得る。言い換えれば、第１のストリームは、最初は、単一の伝送媒体上で完全に受信され得る。

５０４では、第１のストリームが第１の伝送媒体と第２の伝送媒体の両方の上で送信されるというインジケーションが、第２のデバイスから受信され得る。デバイスは、第１のストリームが第１の伝送媒体と第２の伝送媒体の両方の上で送信されることを示す情報を格納することができる。いくつかの実施形態では、このインジケーションを受信することは、第１の伝送媒体および第２の伝送媒体上で受信されるパケットのパケット順序付けが損なわれないことを保証するために、アグリゲーションバッファの開始をトリガすることもできる。

５０６では、第１のストリームの第２の複数のパケットが、第２のデバイスから第１の伝送媒体と第２の伝送媒体の両方を使用して受信され得る。第２の複数のパケットの第１の部分（たとえば、第１のバースト）は第１の伝送媒体上で受信されてもよく、一方、第２の複数のパケットの第２の部分（たとえば、第２のバースト）は第２の伝送媒体上で受信され得る。

いくつかの実施形態では、第１のストリームのパケットは、第１の媒体および第２の媒体の上で交互に（たとえば、交互バースト）受信され得る。このため、パケットが意図されたパケット順序付けで受信されないことがあり得、さらには、この可能性が高い。言い換えれば、いくつかの実施形態では、第１のストリームの第２の複数のパケットの少なくとも一部分は、意図されたものとは異なる順序で受信され得る。そのような場合、たとえば、受信されたパケットを再順序付けするために、１つまたは複数のさらなるステップが実行されてよい。

５０８および５１０では、第２の複数のパケットの意図された順序が決定されてもよく、第２の複数のパケットは、第２の複数のパケットの意図された順序に従って再順序付けされ得る。多数の実施形態では、パケットの各部分は、内部で正しく順序付けられ得る。したがって、いくつかの実施形態では、異なる伝送媒体を介して受信された第１のストリームの各部分を再順序付けする（再結合する）ためのメカニズムが設けられ得る。上記で述べたように、一組の実施形態では、このメカニズムは、アグリゲーションバッファを含むことができる。アグリゲーションバッファの性質およびサイズは、実施形態によって変わることができる。いくつかの実施形態では、第２のデバイスから受信されるインジケーションは、たとえば第１のストリームならびに／または第１の伝送媒体および第２の伝送媒体の特性に基づく、推奨されるアグリゲーションバッファサイズを含むことができる。

いくつかのアグリゲーションバッファ技法では、パケットシーケンス番号を利用することができる。したがって、いくつかの実施形態では、第１のストリームのパケットは、シーケンス番号を含むことができる。いくつかのタイプのストリーム（たとえば、ＴＣＰ、ＲＴＰ）は、本質的に、パケット再順序付けに使用できるシーケンス番号を含むことができる。いくつかの他のタイプのストリーム（たとえば、ＵＤＰ）は、本質的には、シーケンス番号を含まなくてよい。そのような場合、シーケンス番号は、たとえば、ストリームパケットをカプセル化すること、またはシーケンス番号を冗長フィールド（たとえば、いくつかの実施形態ではＶＬＡＮタグ）に挿入すること、または別の手段によって、ストリームパケットに挿入され得る。

一組の実施形態では、アグリゲーションバッファは、環状バッファとすることができる。環状バッファを開始および維持することは、基本シーケンス変数を決定および維持することを含むことができ、この基本シーケンス変数は、処理の順番が次のパケット（たとえば、そのパケットのパケットシーケンス番号に基づく）へのポインタであってよい。新たに受信されたパケットは、シーケンス番号に基づいて、基本シーケンスポインタに対してバッファ内の適切な場所に格納されてもよく、必要に応じて、パケットは処理されてもよく、基本シーケンス変数は更新され得る。

今説明したようにパケットシーケンス番号および環状バッファを使用することは、第１のストリームのいくつかのパケットが順序を乱して受信されるかどうかと無関係に、第１のストリームがそれ自体の意図されたパケット順序付けにアグリゲーションできることを保証するための１つの可能な技法とすることができる。しかしながら、上記で述べたように、すべてのタイプのストリームが本質的にシーケンス番号を含むとは限らず、そのような場合、シーケンス番号を人為的に挿入することが負担となる可能性があり、潜在的には、さらなる問題を引き起こし得る。たとえば、いくつかの実施形態では、パケットをカプセル化してシーケンス番号を付与することによって、スイッチによってサポートされるサイズを超えてパケットが拡張されてもよく、一方、タグを冗長フィールドに挿入することは、さらなる複雑さを必要とし、場合によっては、意図されていない目的でフィールドを使用することによって曖昧さをもたらすことがある。

（たとえば、フローに関して、本質的にはシーケンス番号を含まない、または、すべてのフローに関して、一般にシーケンス番号を含まない）１つの可能な代替形態として、いくつかの実施形態では、第１のストリームのパケットの送信が１つの伝送媒体から別の伝送媒体に移動される直前（および、いくつかの実施形態では、その直後）に、切り換えマーカパケットが第１のストリームに挿入され得る。切り換えマーカパケットは、伝送媒体上で通信されているストリームの一部分の開始または終了を示すことができる。したがって、１つの伝送媒体上で通信される「ストリームの開始」マーカパケットは、ストリームの次の部分（意図されたパケット順序に従って）がその伝送媒体上で通信されていることを示すことができる。同様に、「ストリームの終了」マーカパケットは、現在の時刻において、そのストリームのさらなるパケットがその伝送媒体上で通信されていることを示すことができる。

したがって、一組の実施形態では、ストリームの開始マーカパケットが、第２の複数のパケットの第１の部分の先頭で受信されてもよく、ストリームの終了マーカパケットが、第２の複数のパケットの第１の部分の終了時に受信され得る。同様に、ストリームの開始マーカパケットが、第２の複数のパケットの第２の部分の先頭で受信されてもよく、ストリームの終了マーカパケットが、第２の複数のパケットの第２の部分の終了時に受信され得る。切り換えマーカパケットは、意図されたストリームパケット順序に従って第２の複数のパケットをどのようにして再結合するかを第２のデバイスに示すことができ、したがって、受信後、第２の複数のパケットの第１の部分と第２の部分（と、ストリームが分割されている限り、ストリームの開始マーカパケットと、ストリームの終了マーカパケットとを同様に含むことができる、何らかの後続ストリーム部分）は、順序正しく受信されたかどうかに関係なく、意図された順序で再結合される。

たとえば、いくつかの実施形態では、ストリームの開始マーカパケットおよび第２の複数のパケットの第２の部分のいくつかのパケットは、第２の複数のパケットの第１の部分のいくつかのパケットおよびストリームの終了マーカパケットが第１の伝送媒体上で受信される前に、第２の伝送媒体上で受信され得るが、第２の複数のパケットの第２の部分は、第１のストリームの意図された順序付けでは、第２の複数のパケットの第１の部分の後ろであってよい。この場合、第２の複数のパケットの第２の部分の何らかの早期に受信されたパケットは、第２の複数のパケットの第１の部分のパケットのすべてが受信および処理されるまで、アグリゲーションバッファにバッファリングされ得る。いくつかの実施形態では、第２の複数のパケットの第１の部分全体が受信されたことは、第１の伝送媒体上でのストリームの終了マーカパケットの受信によって示され得る。その時点で、バッファリングされたパケットは、処理のためにプロトコルスタックの次のレイヤに送られてもよく、したがって、第２の複数のパケットは、意図された順序で処理され得る。

もちろん、場合によっては、たとえば、ある種のエラーによって、ストリームの終了マーカパケットが受信されないことがあることも可能である。この場合、第１の伝送媒体上で受信されることにならないさらなるパケットを無期限に待機するのを回避するために、たとえば実際の時間またはバッファサイズ（充満度）に基づいた、タイムアウトパラメータがあってもよい。

別の組の実施形態では、ストリームの開始マーカパケットは、ストリームの終了マーカパケットも使用することなく、使用され得る。たとえば、上記で図４に関して述べたように、いくつかの実施形態では、特定の伝送媒体上で受信されるストリームの開始マーカパケットは、その伝送媒体上で送信されようとするバーストのバーストサイズを示す情報を含むことができる。この場合、受信機は、ストリームの開始マーカパケット内のバーストサイズ情報に基づいて、バーストの終了がいつ発生したか（たとえば、ストリームの開始マーカパケット内のバーストサイズ情報によって示されるパケットの数がいつ受信されたか）決定することが可能であることがある。

したがって、いくつかの実施形態では、第１のストリームの第１のストリームの開始マーカパケットが第１の伝送媒体上で受信され得る。この第１のストリームの開始マーカパケットは、第１のバーストサイズを示す情報を含むことができる。次いで、第１のストリームのパケットの第１のバースト（たとえば、第１のバーストサイズを有する）が第１の伝送媒体上で受信され得る。

第１のストリームの第２のストリームの開始マーカパケットも、第２の伝送媒体上で受信され得る。この第２のストリームの開始マーカパケットは、第２のバーストサイズを示す情報を含むことができる。次いで、第１のストリームのパケットの第２のバースト（たとえば、第２のバーストサイズを有する）が第２の伝送媒体上で受信され得る。

いくつかの実施形態では、第１のバーストの第１の部分が第１の伝送媒体上で受信された後、かつ第１のバーストの第２の部分が第１の伝送媒体上で受信される前に、第２のバーストの第１の部分が第２の伝送媒体上で受信され得る。この場合、第１のストリームの開始マーカパケット内の第１のバーストサイズを示す情報に基づいて、第２のバーストの第１の部分が受信されたとき、第１のバーストの第２の部分がまだ受信されていないと決定されることがある。これに基づいて、第１のバーストの第１の部分および第２の部分が処理される間、第２のバーストの第１の部分がバッファに格納されてもよく、（たとえば、意図されたストリーム順序付けでは、第１のバーストのすべてのパケットは、第２のバーストのどのパケットの前にもなることができるので）第１のバーストの第２の部分の処理が完了した後で、第２のバーストの第１の部分が処理され得る。

いくつかの実施形態では、切り換えマーカパケットが上記で説明したように使用されるときなどに、アグリゲーションバッファを環状バッファとして実施する必要がないことがあるが、アグリゲーションバッファは、必要に応じて、依然として環状バッファとして実施されてもよいことに留意されたい。

切り換えマーカパケットはストリーム分割／アグリゲーションの場合に主に使用されるように上記で説明されているが、切り換えマーカパケットは、同じくまたは代替的に、ストリームが全体として新しい伝送媒体に転送されるストリーム再割り当て状況において使用され得ることに留意されたい。

図６は、あるデバイスがストリームを新しい伝送媒体に切り換えるための方法を示すフローチャート図である。図６の方法は、主に「フェイルオーバ」状況、すなわち、ある伝送媒体で障害が発生した（すなわち、通信機能の著しいロスまたは全ロスを被った）状況において使用され得る。しかしながら、図６の方法の一部またはすべては、同じくまたは代替的に、すなわち元の伝送媒体と新しい伝送媒体の両方が通信のために使用され得る、通常の負荷バランシング状況において使用され得る。

この方法を実施するデバイスは、複数の伝送媒体を介して第２のデバイスに結合され得る。たとえば、いくつかの実施形態では、第１のデバイスおよび第２のデバイスは、図１に示されるデバイスのうち２つであってよい。方法を実施するシステムは、いくつかの実施形態では、図２に示され、図２に関して説明されるようなシステムであってよい。方法を実施するシステムは、いくつかの実施形態では、図３に示され、図３に関して説明されるようなＯＳＩプロトコルスタックを実施することができる。たとえば、一組の実施形態では、方法は、たとえばハイブリッド制御エンティティ２１２および／またはハイブリッドブリッジ２１４によって、ハイブリッド適応レイヤ３１０で実施され得る。他の実施形態では、方法は、別のレイヤまたはいくつかのレイヤで実施され得る（たとえば、いくつかのレイヤの各々は、方法の要素を実施することができる）。方法は、次のように実行され得る。

６０２では、第２のデバイスへの送信向けの第１のストリームが受信され得る。この第１のストリーム（たとえば、第１のストリームのパケット）は、より上位のプロトコルレイヤから受信され得る。

６０４では、第１のストリームの第１の複数のパケットが、第２のデバイスに第１の伝送媒体上で送信され得る。第１の複数のパケットは、１つまたは複数のインデックスマーカパケットを含むことができる。各インデックスマーカパケットは、インデックス番号を含むことができる。たとえば、いくつかの実施形態では、最初のインデックスマーカパケットは、１（または必要に応じて何らかの他の番号）というインデックス番号を有することができ、各後続インデックスマーカパケットは、それ自体の前のインデックスマーカパケット内のインデックス番号に対して１だけ増分されたインデックス番号を有することができる。インデックスマーカパケットは、第１のストリームに挿入され得る。インデックスマーカパケットは、規則的な間隔または不規則な間隔で第１のストリームに挿入され得る。一組の実施形態では、インデックスマーカパケットは、ｎ個のパケットごとに第１のストリームに挿入されてもよく、ここで、ｎは、必要に応じて、５０、１００、１０００、５０００、または何らかの他の数であってよい。いくつかの実施形態では、ｎの値は固定されてなくてもよく、いくつかの間隔または間隔ごとにすら、変えられてもよい。

６０６では、第１のストリームの第１の複数のパケットの第１の部分がバッファに格納され得る。いくつかの実施形態では、第１のストリームのパケットの少なくとも一部分が、送信バッファに（たとえば、一時的に）格納され得る。いくつかの実施形態では、インデックスマーカパケットも送信バッファに格納され得る。

６０８では、第１の複数のパケットの少なくとも一部分が第２のデバイスによって受信されていない可能性があると決定されることがある。いくつかの実施形態では、伝送媒体（または、特定の伝送媒体を利用するインターフェース）において、時々、一時的または永久的に障害が発生することがある。伝送媒体の障害は、本明細書で用いる場合、通信機能の（一時的または永久的な）著しいまたは完全なロスによってストリームがもはや伝送媒体上で送信されない状況を指すことを意図する。したがって、第１の伝送媒体で障害が発生したと決定された場合、第１の複数のパケットの少なくとも一部分が第２のデバイスによって受信されていない可能性があると推測されることがある。

第１の伝送媒体で障害が発生した場合、第１の伝送媒体に割り当てられた各ストリームは、新しい伝送媒体に再び割り当てられ得る。選択プロセスは、いくつかの実施形態では、図４に関して上記で説明した負荷バランシングする新しい伝送媒体選択プロセスと類似していてよい。たとえば、第１のストリーム（および、場合によっては他のストリーム）および利用可能な伝送媒体のうち１つまたは複数の特性は、どの伝送媒体（または複数の媒体）が第１のストリーム（および、場合によっては他のストリーム）に最も良く対応できるか決定するために考慮され得る。いくつかの実施形態では、第１のストリームは第２の伝送媒体に再び割り当てられるべきであると決定され得る。

第１の複数のパケットのうちいくつかが第２のデバイスによって受信されていない可能性があるので、送信バッファに格納されたパケットの少なくとも一部分が再び送信されるべきであると決定されることがある。さらに、いくつかの実施形態では、バッファマーカパケットは、「強調された」パケット（すなわち、バッファ開始マーカパケットとバッファ終了マーカパケットの間のパケット）が以前に送信されたパケット（たとえば、第１の複数のパケットの一部として第１の伝送媒体上で送信されたパケット）を複製することができることを受信機に示すために、再送信されたパケットの開始時および終了時に第２のデバイスに第２の伝送媒体上で送信され得る。

いくつかの実施形態では、バッファ開始マーカパケットは情報を含むことができ、この情報は、インデックスマーカパケットを識別し、この識別されたインデックスマーカパケットに相対的な、第１のストリーム内でのバッファ開始マーカパケットの位置を示す。たとえば、いくつかの実施形態では、あるストリーム用のバッファ開始マーカパケットは、バッファ内の第１のパケットの前にあるストリームの最後のインデックスマーカパケットのインデックス番号と、ストリーム内でそのインデックスマーカパケットとバッファ内の第１のパケットとの間にあるパケットの数とを含むことができる。これによって、インデックスマーカが規則的な（たとえば、予測可能な）間隔で挿入されているかどうかとは無関係に、第２のデバイスが何らかの複製パケットを識別および破棄することが可能になり得る。その理由は、第２のデバイスは、１つまたは複数の最近受信されたインデックスマーカパケットのインデックス番号と、それらの１つまたは複数の最近受信されたインデックスマーカパケット以降に受信されたパケットの数とを追跡するだけでよい場合があるからである。

いくつかの実施形態では、バッファ開始マーカパケットは、バッファのサイズを示す情報も含むことができる。たとえば、バッファ終了パケットを送信するのではなく、バッファのサイズ（たとえば、パケットの数）を受信機に示すことだけが有利なことがあり、これによって、受信機は、バッファの全体がいつ受信されたか決定することが可能になり得る。これは、バッファ終了パケット内で実施される追加オーバーヘッドを回避するために望ましいことがある。

いくつかの実施形態では、インデックスマーカパケットは、複製パケットがいつ受信されたか決定し、そのような複製パケットを識別および破棄するための十分な根拠（たとえば、規則的な間隔で挿入された場合）を第２のデバイスに提供することができるので、いくつかの実施形態では、バッファマーカパケットが使用されないことがあることに留意されたい。

６１０では、第１のストリームの第２の複数のパケットが、第２のデバイスに第２の伝送媒体上で送信され得る。第２の複数のパケットは、第１の複数のパケットの少なくともサブセットを含むことができ、１つまたは複数のインデックスマーカパケットの少なくともサブセットも含むことができる。第２の複数のパケットは、たとえば、送信バッファに格納され、かつ第１の複数のパケットの一部でもあった、パケット（何らかのインデックスマーカパケットを含む）を含むことができる。言い換えれば、第２の複数のパケットは、第１の複数のパケットのうちいくつかの複製物を含むことができる。上記で述べたように、これは、第１の複数のパケットのすべてが第２のデバイスによって受信されるとは限らないと決定されるかもしれないので、パケットロスを回避するために望ましいことがある。しかしながら、第２のデバイスに、第１の伝送媒体と第２の伝送媒体の両方の上で正常に受信されたパケット（すなわち、この複製コピー）を識別および除去するための比較的に単純な手段を提供することが望ましいこともある。

上記で述べたように、バッファ終了マーカパケットは、第２の伝送媒体上で第２のデバイスに送信され得る。バッファ終了マーカパケットは、第２の複数のパケットに含まれる第１の複数のパケットの少なくともサブセットを送信した後で、第２のデバイスに送信され得る。言い換えれば、バッファ終了マーカパケットは、たとえば、バッファリングされたパケットのすべて（すなわち、これは、第１の伝送媒体上で送信された第１の複数のパケット内のパケットを複製し得る）が送信され、後続パケットが以前に送信されたパケットを複製しないことがあることを第２のデバイスに示すために、バッファリングされたパケットのすべてが再送信された後で第２のデバイスに送信され得る。

第１のストリームの追加パケット（すなわち、非複製パケット）も、バッファリングされたパケットの終了後に、第２の伝送媒体上で第２のデバイスに送信され得る。いくつかの実施形態では、追加パケットは、複製バッファ内のパケットの送信を調節する（たとえば、自己抑制する（ｓｅｌｆ−ｔｈｒｏｔｔｌｅ））ために使用され得る。たとえば、一組の実施形態では、第１のストリームの追加パケットは、受信機への送信のために受信され得る。追加パケットは、第２の複数のパケットの後で、送信のためにバッファ内に（たとえば、バッファの末尾に）格納され得る。次いで、バッファのヘッドエンドからのあらかじめ選択された数のパケットが、第１のストリームの追加パケットを受信機への送信のために受信したことに基づいて、第２の伝送媒体上で再送信され得る。言い換えれば、追加パケットは、短時間で潜在的に多数のパケット（たとえば、第１の伝送媒体の障害により再送信されることが必要なことがあるパケット）を持つ受信機に負担をかけすぎることを回避するために、バッファからパケットを解放する自動タイマメカニズムとして使用され得る。そのような自己抑制メカニズムは、任意選択であってよく、および／または図７に関して説明するように、代替的に（もしくは追加的に）受信機内で実施され得ることに留意されたい。

上記で述べたように、いくつかの実施形態では、バッファ終了マーカパケットが送信されないことがある。この場合、バッファ開始パケットはバッファサイズを示す情報を含むことができ、その場合、バッファ終了パケットは無関係である。あるいは、いくつかの実施形態では、バッファリングされたパケットの再送信が完了したという、第２のデバイスに提供されるインジケーションがないことがある。たとえば、インデックスマーカパケットが規則的な間隔で第１のストリームに挿入される場合、それらのインデックスマーカパケットは、第２のデバイスがバッファ終了（または、いくつかの実施形態では、バッファ開始）マーカパケットを必要とせずに何らかの複製パケットを識別および破棄するのに十分な根拠を提供することができる。

図７は、デバイスが第２のデバイスから受信された複製パケットを除去するための方法を示すフローチャート図である。図７の方法は、主に「フェイルオーバ（fail-over）」状況、すなわち、ある伝送媒体で障害が発生した（すなわち、通信機能の著しいロスまたは全ロスを被った）状況において使用され得る。しかしながら、図７の方法の一部またはすべては、同じくまたは代替的に、すなわち元の伝送媒体と新しい伝送媒体の両方が通信のために使用され得る、通常の負荷バランシング状況において使用され得る。

この方法を実施するデバイスは、複数の伝送媒体を介して第２のデバイスに結合され得る。たとえば、いくつかの実施形態では、第１のデバイスおよび第２のデバイスは、図１に示されるデバイスのうち２つであってよい。方法を実施するシステムは、いくつかの実施形態では、図２に示され、図２に関して説明されるようなシステムであってよい。方法を実施するシステムは、いくつかの実施形態では、図３に示され、図３に関して説明されるようなＯＳＩプロトコルスタックを実施することができる。たとえば、一組の実施形態では、方法は、たとえばハイブリッド制御エンティティ２１２および／またはハイブリッドブリッジ２１４によって、ハイブリッド適応レイヤ３１０で実施され得る。他の実施形態では、方法は、別のレイヤまたはいくつかのレイヤで実施され得る（たとえば、いくつかのレイヤの各々は、方法の要素を実施することができる）。方法は、次のように実行され得る。

７０２では、第１のストリームの第１の複数のパケットが、第１の伝送媒体上で受信され得る。第１の複数のパケットは、１つまたは複数のインデックスマーカパケットを含むことができる。各インデックスマーカパケットは、インデックス番号を含むことができる。たとえば、いくつかの実施形態では、最初のインデックスマーカパケットは、１（または必要に応じて何らかの他の番号）というインデックス番号を有することができ、各後続インデックスマーカパケットは、それ自体の前のインデックスマーカパケット内のインデックス番号に対して１だけ増分されたインデックス番号を有することができる。インデックスマーカパケットは、規則的な間隔または不規則な間隔で第１のストリームに置かれ得る。一組の実施形態では、インデックスマーカパケットは、ｎ個のパケットごとに第１のストリームに置かれてもよく、ここで、ｎは、必要に応じて、５０、１００、１０００、５０００、または何らかの他の数であってよい。いくつかの実施形態では、ｎの値は固定されてなくてもよく、いくつかの間隔または間隔ごとにすら、変えられてもよい。

７０４では、第１の伝送媒体上で第１のストリーム内で受信された最後のインデックスマーカと最後のインデックスマーカ以降に第１の伝送媒体上で受信された第１のストリームのパケットの数とを示す情報が格納され得る。いくつかの実施形態では、たとえば、インデックスマーカが比較的短いおよび／または不規則な間隔で置かれる場合、以前に受信された複数のインデックスマーカパケットのインデックス番号を示す情報が、場合によってはそれらのインデックスマーカパケットとインデックスマーカパケットの間で受信されたパケットの数を示す情報とともに、格納され得る。

７０６では、バッファ開始マーカパケットが第２の伝送媒体上で受信され得る。いくつかの実施形態では、バッファ開始マーカパケットは情報を含むことができ、この情報は、インデックスマーカパケットを識別し、この識別されたインデックスマーカパケットに関連する、第１のストリーム内でのバッファ開始マーカパケットの位置を示す。たとえば、いくつかの実施形態では、あるストリーム用のバッファ開始マーカパケットは、バッファ内の第１のパケットの前にあるストリームの最後のインデックスマーカパケットのインデックス番号と、ストリーム内でそのインデックスマーカパケットとバッファ内の第１のパケットとの間にあるパケットの数とを含むことができる。これによって、インデックスマーカが規則的な（たとえば、予測可能な）間隔で挿入されているかどうかとは無関係に、第２のデバイスが何らかの複製パケットを識別および破棄することが可能になり得る。その理由は、第２のデバイスは、１つまたは複数の最近受信されたインデックスマーカパケットのインデックス番号と、それらの１つまたは複数の最近受信されたインデックスマーカパケット以降に受信されたパケットの数とを追跡するだけでよい場合があるからである。いくつかの実施形態では、バッファ開始マーカパケットは、バッファのサイズを示す情報も含むことができる。

７０８では、第１のストリームの第２の複数のパケットが第２の伝送媒体上で受信され得る。第２の複数のパケットは、第１の複数のパケットの少なくともサブセットを含むことができ、１つまたは複数のインデックスマーカパケットの少なくともサブセットを含むことができる。第２の複数のパケットは、たとえば、第２のデバイスによって送信バッファに格納され、かつ第１の複数のパケットの一部でもあった、パケット（何らかのインデックスマーカパケットを含む）を含むことができる。言い換えれば、第２の複数のパケットは、第１の複数のパケットのうちいくつかの複製物を含むことができる。

いくつかの実施形態では、バッファ終了マーカパケットも、第２の伝送媒体上で第１のデバイスによって受信され得る。バッファ終了マーカパケットは、第２の複数のパケットに含まれる第１の複数のパケットの少なくともサブセットを受信した後で、第１のデバイスによって受信され得る。言い換えれば、バッファ終了マーカパケットは、バッファリングされたパケットのすべてが受信された後で第１のデバイスによって受信されてもよく、バッファリングされたパケットのすべて（すなわち、これは、第１の伝送媒体上で受信された第１の複数のパケット内のパケットを複製し得る）が送信され、後続パケットが以前に送信されたパケットを複製しないことがあることを第１のデバイスに示すことができる。しかしながら、いくつかの実施形態では、たとえば、バッファ開始マーカパケットが、送信されているバッファのサイズを示す情報を含む場合、バッファ終了マーカパケットが、必要とされないまたは望ましくないことがあることに留意されたい。この場合、受信機は、バッファ開始マーカパケットに含まれる情報に基づいて、バッファの全体がいつ受信されたか決定することが可能であることがある。これは、バッファ終了パケット内で実施される追加オーバーヘッドを回避するために望ましいことがある。

第１のストリームの追加パケット（すなわち、非複製パケット）も、バッファリングされたパケットの後で、第２の伝送媒体上で第１のデバイスによって受信され得る。いくつかの実施形態では、追加パケットは、たとえば、多数のパケットが短時間に受信される場合、バッファリングされたパケットの処理（たとえば、上位プロトコルレイヤに送ること）を調節する（たとえば、自己抑制する）ために使用され得る。これは、上位プロトコルレイヤのうち１つまたは複数に負担をかけすぎることを回避するために望ましいことがあり、これらのレイヤに負担をかけすぎることによって、潜在的に、パケットロスが引き起こされる可能性がある。

たとえば、一組の実施形態では、第２の複数のパケットのうち少なくともいくつかは、たとえば処理の前に、受信バッファに格納され得る。第１のストリームの追加パケットが、第２の伝送媒体上で受信されてもよく、受信バッファのテールエンドに格納され得る。第１のストリームの追加パケットを受信したことに基づいて、受信バッファのヘッドエンドからのあらかじめ選択された数のパケットが、処理され（たとえば、上位プロトコルレイヤに送られ）、バッファのヘッドエンドから除去され得る。したがって、いくつかの実施形態では、追加パケットは、バッファからパケットを解放するために、自動タイマメカニズムとして使用され得る。各さらなる追加パケットを受信すると、一組の実施形態によれば、受信バッファが空になるまで、受信バッファのヘッドエンドからの追加のあらかじめ選択された数のパケットが解放され得る。

さらに、いくつかの実施形態では、インデックスマーカパケットは、複製パケットがいつ受信されたか決定し、そのような複製パケットを識別および破棄するための十分な根拠（たとえば、規則的な間隔で挿入された場合）を第２のデバイスに提供することができるので、いくつかの実施形態では、バッファマーカパケットがまったく使用されないことがあることに留意されたい。

７１０では、第１の伝送媒体上で受信された第１の複数のパケットまたは第２の伝送媒体上で受信された第２の複数のパケットのうち１つまたは複数が複製パケットであると決定され得る。第１の伝送媒体上で受信された第１の複数のパケットまたは第２の伝送媒体上で受信された第２の複数のパケットのうち１つまたは複数が複製パケットであると決定することは、１つまたは複数のインデックスマーカパケットに少なくとも部分的に基づくことができる。いくつかの実施形態では、この決定は、第１の伝送媒体上で第１のストリームの最後のインデックスマーカと第１のストリームの最後のインデックスマーカが第１の伝送媒体上で受信された以降に第１の伝送媒体上で受信された第１のストリームのパケットの数とを示す格納された情報に少なくとも部分的に基づいて行われ得る。たとえば、インデックスマーカパケットが規則的な間隔で挿入される場合、第２の伝送媒体上で受信された第１のインデックスマーカパケットおよびそのインデックスマーカパケットを受信する前に第２の伝送媒体上で受信されたパケットの数を、第１の伝送媒体上で受信された最後のインデックスマーカパケットおよびそのインデックスマーカパケット以降に第１の伝送媒体上で受信されたパケットの数と比較することによって、複製パケットがあるかどうか、およびどのくらい多くのどのパケットが複製パケットであるかについてのインジケーションがもたらされ得る。しかしながら、このプロセスは、インデックスマーカパケットが第２の伝送媒体上で受信されるまで待機することを必要とすることがあり、これは非効率的なことがある。

あるいは、バッファ開始マーカパケットが第１のストリームの何らかのコンテンツパケットの前に第２の伝送媒体上で受信された場合、ストリーム内でのそれ自体の場所を識別するバッファ開始マーカパケット内の情報は、複製パケットの存在を直ちに検出するために使用され得る。たとえば、いくつかの実施形態では、受信された最後のインデックスマーカパケットと前回のインデックスマーカパケット以降に第１の伝送媒体上で受信されたパケットの数とを示す格納された情報は、最新のインデックスマーカパケットに関連する、第１のストリーム内でのバッファ開始マーカパケットの位置を示す情報と比較されて、第１の複数のパケットまたは第２の複数のパケットのいずれかが互いの複製パケットであるかどうか決定することができる。

７１２では、決定された複製パケットが破棄され得る。破棄された複製パケットは、必要に応じて、第１の伝送媒体または第２の伝送媒体のいずれかの上で受信された複製パケットのコピーであってよい。一組の実施形態では、バッファ開始マーカパケットが受信された後に第１のストリームのパケットが第１の伝送媒体上で引き続き受信され、それらのパケットがストリームパケット順序付け内のバッファ開始マーカパケットの場所の後ろにある場合、それらのパケットは破棄され得る（たとえば、それらのパケットが第２の伝送媒体上で再送信されると仮定されることがあるので）。一方、バッファ開始マーカパケットが受信されるとき、第１のストリームのパケットが、ストリームパケット順序付けにおけるバッファ開始マーカパケットの場所を過ぎたある点まで、第１の伝送媒体上ですでに受信された場合、第２の伝送媒体上で受信された第１のストリームのパケットは、非複製パケット（すなわち第１の伝送媒体上で受信されておらず、処理もされていないパケット）が受信されるまで、破棄され得る。その時点では、第１のストリームは、第２の伝送媒体に完全に切り換えられていることができる。いくつかの実施形態では、たとえば、新しい伝送媒体への第１のストリームのさらなる再割り当ての場合、第２の伝送媒体上で最近受信された１つまたは複数のインデックスマーカパケットとそれらの最近受信されたインデックスマーカパケット以後またはそれらの最近受信されたインデックスマーカパケットとパケットの間に受信されたパケットの数とを示す情報は、引き続き格納され得る。

図８〜図１１および追加の考慮事項
図８〜図１１およびそれらと関連して提供される以下の詳細および追加の考慮事項は、図４〜図７の方法に従って使用され得る特定の例示的な実装形態に関する。しかしながら、当業者には理解されるように、詳細に関する異なる実装形態を含む何らかの数の異なる実装形態は図４〜図７の方法とともに使用されてもよく、したがって、以下の考慮事項は、全体として本開示に限定すると見なされるべきである。

図８
図８は、一実施形態による、ストリーム分割／ストリームアグリゲーションを取り巻く送信デバイスと受信デバイスの間のメッセージフロー８００を示す通信図である。

最初に、オーバーサブスクリプションイベントが、送信デバイスによって検出され得る。デバイス（たとえば、図２に示されるハイブリッド制御エンティティ２１２などのハイブリッドネットワーキングレイヤで動作するハイブリッド制御エンティティ、または別のシステム要素）は、ストリームを分割することを決めることができる。デバイスは、たとえばストリームを受信デバイスに分割する判定を示す送信制御パケットによって、受信デバイスに通知することができる。受信デバイス（たとえば、図２に示されるハイブリッドブリッジ２１４などのハイブリッドネットワーキングレイヤで動作するハイブリッドブリッジ、または別のシステム要素）は、アグリゲーション命令（推奨アグリゲーションバッファサイズなど）を含むことができる制御パケットと、制御パケットの受信確認とを受信することができる。

いくつかの実施形態では、分割のために選択されたストリームのパケットを含む新たに受信されたパケットのルーティングを決定するために送信デバイスによって使用されるルーティングテーブルは、ストリームを分割する判定に従って更新され得る。次いで、送信デバイスが、たとえば、分割されたストリームのいくつかのパケットを第１の伝送媒体に、および分割されたストリームのいくつかのパケットを第２の伝送媒体にルーティングすることによって、ストリームを複数のインターフェースに分割することができる。いくつかの実施形態では、選択された伝送媒体の各々にルーティングされる分割されたストリームの割合は、ルーティングテーブルに格納された情報に従って維持され得る。

一方、受信デバイスは、分割されたフローのパケットを複数のインターフェース上で受信し、パケットをアグリゲーションし、再順序付けすることができる。

最終的に、送信デバイスが、ストリームの分割を中止するように決めることができる。その後、送信デバイスは、複数のインターフェースではなく単一のインターフェースを使用して、ストリームのパケットを送信し始めることができる。送信デバイスは、さらなる制御パケットによって受信デバイスに通知することができ、この制御パケットは、受信デバイスによって受信および確認され得る。

したがって、いくつかの実施形態によれば、送信デバイスは、フローの分割ステータスを修正するとき、たとえば、フローを分割し始めるとき、およびフローの分割を中止するとき、コマンドを受信機に送信することができる。

この情報の目的は、受信機が再順序付けバッファを作製し、フローを再順序付けすることを始めることを可能にすることであり得る。再順序付けは、（ＣＰＵとメモリの両方で）比較的高価になることがあり、潜在的には、フローの配送遅延を増加させる可能性がある。したがって、受信機が常にすべてのフローに対してそのようにしないことが望ましいことがある。したがって、いくつかの実施形態では、再順序付け（たとえば、アグリゲーションバッファのセットアップを含む）は、複数の媒体にわたって送信されるフローに対してのみ実行され得る。

いくつかの実施形態によれば、制御パケットは、推奨バッファサイズおよび／または推奨タイムアウトも示すことができる。送信機は、ストリームが分割された両方のインターフェースのフローレートおよび相対的遅延に基づいて、アグリゲーションバッファサイズを推奨することができる。受信機は、一般的に推奨を遵守してよいが、メモリ可用性に応じ無効にしてもよい。送信機はまた、ストリームが分割された両方のインターフェースのフローレートおよび相対的遅延に基づいて、タイムアウトを推奨することができる。この場合も、受信機は、一般的に推奨を遵守してよいが、メモリ可用性に応じて無効にしてもよい。

図９
図９は、一実施形態による、異なるシナリオによる様々な伝送媒体の仮想リンク容量を示すグラフ９００である。図示の実施形態では、３つの利用可能な伝送媒体、すなわち、ＰＬＣ、２．４ＧＨｚスペクトルで動作するＷｉ−Ｆｉ（Ｗ２）、および５ＧＨｚスペクトルで動作するＷｉ−Ｆｉ（Ｗ５）がある。ＰＬＣおよびＷ５は、現在、２５Ｍｂｐｓよりも大きなリンク容量を有し、このリンク容量は、例示的な実施形態では、それを上回ると伝送媒体が新しいトラフィック（たとえば、新しいストリーム）を追加するのに十分な容量よりも多い容量を有すると見なされる閾値として設定されている。Ｗ２も何らかの利用可能なリンク容量を有するが、図示の実施形態では、２５Ｍｂｐｓよりも小さい。

図示のシナリオでは、複数の伝送媒体が新しいトラフィックをサポートするのに十分なリンク容量を有するが、このシナリオは「高可用性」と呼ばれることがある。この状況では、ストリーム自体のマッチング特性に基づいて新しいストリームのための最も適した伝送媒体を選択するために、より大きな自由が存在することがある。たとえば、高い優先順位および／またはいくつかの特定のタイプのコンテンツ（たとえば、音声、ビデオ）を持つストリームは、好ましくは、より高速および／または信頼性のより高い伝送媒体に割り当てられることがあり、一方、低い優先順位および／またはいくつかの特定のタイプのコンテンツ（たとえば、データのダウンロード）を持つストリームは、好ましくは、（たとえば、優先順位のより高いトラフィックのために、より高速および／または信頼性のより高い伝送媒体を確保するために）より低速および／または信頼性のより低い伝送媒体に割り当てられ得る。

たったわずかに１つの伝送媒体が「高可用性」閾値を超えるリンク容量を有するシナリオは、図示のシナリオとは対照的に、「低可用性」と呼ばれることがある。この状況において、少なくともいくつかの実施形態では、新しいストリームは、最高のリンク容量を持つ伝送媒体だけに割り当てられることがあり、新しいストリームの特性を最も適切な伝送媒体と適合させる特別な取組みは行われなくてよい。

図１０Ａ〜図１０Ｂ
図１０Ａおよび図１０Ｂは、パケットアグリゲーションが望ましいことがあるシナリオを示す。１つの基本的な使用事例は、受信可能範囲である。たとえば、家庭での使用についてのシナリオでは、アグリゲーションによって、単一のストリームをサポートするのに不十分な帯域幅を有する住宅の隅に受信可能範囲が提供され得る。そのような場合、ストリームを複数のインターフェースに分割することにより、受信可能範囲が増加する。パケットアグリゲーションはまた、様々な他のシナリオでも望ましいことがある。

図１０Ａに示されるように、一実施形態では、トラフィック生成器１００２は、（たとえば、イーサネット結合を介して）第１のデバイス１００４に結合され得る。第１のデバイスは、１０Ｍｂｐｓ接続を持つＷｉ−Ｆｉを介して、および７Ｍｂｐｓ接続を持つＰＬＣを介して、第２のデバイス１００６に結合され得る。第２のデバイス１００６は、（たとえば、イーサネット結合を介して）トラフィックシンク１００８に結合され得る。

トラフィックシンク１００８が、トラフィック生成器１００２から１２Ｍｂｐｓを必要とするビデオストリームを開始した場合、Ｗｉ−Ｆｉ接続もＰＬＣも、このビデオストリームを個別にサポートする容量を持たない。しかしながら、ストリームの一部がＷｉ−Ｆｉリンク上で送信され、ストリームの一部がＰＬＣリンク上で送信されるようにストリームが分割された場合、これらの接続は、共同でビデオストリームをサポートすることができる。

図１０Ｂは、いくつかのフローにとって十分な帯域幅が利用可能であるシナリオを示す−しかしながら、帯域幅の、ストリーム割り当てによって各媒体内に残る部分は、追加のフローを扱うのに不十分である。この場合、Ｗｉ−Ｆｉは４０Ｍｂｐｓ接続を提供し、ＰＬＣは２０Ｍｂｐｓ接続を提供するが、ストリーム１および２は各々、Ｗｉ−Ｆｉ接続の１５Ｍｂｐｓを利用し、ストリーム３はＰＬＣ接続の１５Ｍｂｐｓを利用する。したがって、Ｗｉ−Ｆｉは１０Ｍｂｐｓの残存リンク容量を有し、ＰＬＣは５Ｍｂｐｓの残存リンク容量を有する。いずれの伝送媒体も、新しいストリーム４（１５Ｍｂｐｓを必要とする）を個別にサポートすることはできないが、新しいストリームを分割することによって、これらの伝送媒体は、共同でビデオストリームをサポートすることができる。

いくつかの実施形態では、パケットアグリゲーションによる主な性能限界（ＣＰＵ使用率）は、受信機側でパケットの再順序付けであることがある。ＣＰＵの制限を想定すれば、これは、アグリゲーションされたストリームの最大サイズと１つのストリームをアグリゲーションしながらサポート可能なアグリゲーションされていない全トラフィックとのトレードオフを提供する。したがって、いくつかの実施形態では、場合によっては、アグリゲーションされていないトラフィックがどのくらい多く存在するかに応じた異なるストリームサイズ制限を含む、アグリゲーションされたストリームのサイズを制限することが望ましいことがある。一例として、他のトラフィックがない場合、最大３０Ｍｂｐｓのアグリゲーションされたストリームがサポートされてもよく、最大５０Ｍｂｐｓの他のトラフィックがある場合、最大２０Ｍｂｐｓのアグリゲーションされたストリームがサポートされ得る。もちろん、これらは単なる例であり、必要に応じて、異なる制限が使用されてよい（または、制限が使用されなくてもよい）。

さらに、アグリゲーションされたストリームを受信するコスト（たとえば、ＣＰＵコスト）が、アグリゲーションされていないストリームを受信するコストよりも高いことがあるので、いくつかの実施形態では、アグリゲーションされるストリームの数を最小にすることが望ましいことがある。たとえば、一組の実施形態では、２つの利用可能な伝送媒体がある場合、多くとも１つのストリームを分割することが望ましいことがあり、３つの利用可能な伝送媒体がある場合、多くとも２つのストリームを分割することが望ましいことがある。

言い換えれば、いくつかの実施形態では、同じデバイス（２つの媒体を持つ）から発生する２つのストリームが両方の媒体に分割される状況が回避され得る。これによって、使いやすさを抑制しないことができる。２つのインターフェースに分割された２つ以上のストリームを、単一のインターフェース実行されている上で１つ以外のすべてのストリームに変換することが、常に可能なことがある。同じ論理は、３つの利用可能な媒体を持つデバイスに適用され得る。

いくつかの実施形態では、アグリゲーションは、（たとえば、送信元とシンクの間の対向する）ハイブリッドデバイス同士の間で行われ得ることに留意されたい。アグリゲーションする（すなわち、ストリームを複数のインターフェースに分割する）判定は、送信元ハイブリッドデバイスにおいて行われ得る。いくつかの実施形態では、すべてのハイブリッド判定は、送信元ハイブリッドデバイスにおいて行われ得る。

図１１
図１１は、一実施形態によるアグリゲーション（再順序付け）バッファ１１００を示す。（他の可能な通信インターフェースの中でもとりわけ）Ｗｉ−ＦｉとＰＬＣの伝送遅延は異なることがあり、したがって、すべてのパケットが適切に配送された場合ですら、パケットが順序を乱して配送されることがあることがあり得る。これは、望ましくないことがある。

パケットを再順序付けすることは、再順序付けバッファを要求しうる。このバッファのサイズは、ストリームが分割された両方のインターフェースのフローレートおよび相対的遅延に基づいて、構成可能とすることができる。実際には、再結合される２つの下位ストリームは内部的には順序が正しいので、このプロセスは、厳密には再順序付けプロセスではなく、むしろ正しい順序における再結合プロセスであることがあることに留意されたい。

再順序付けバッファは、まだ上位レイヤに配送されていない受信されたパケットへのポインタを含むことができる。ＢａｓｅＳｅｑｕｅｎｃｅ変数は、インデックス０に対応するパケットシーケンス番号を含むことができる。再順序付けバッファは、環状バッファとして実施され得る。一実施形態によれば、パケットが受信されるとき、以下の論理が実行され得る。

（ＰａｃｋｅｔＳｅｑｕｅｎｃｅＮｕｍｂｅｒ＜ＢａｓｅＳｅｑｕｅｎｃｅ）の場合、受信されたパケットは、古い順序外れのパケット（たとえば、場合によっては、タイムアウトしたパケット）である。パケットは、必要に応じて、実装形態に応じて、破棄されてもよいし、配信されてもよい。

あるいは、（ＰａｃｋｅｔＳｅｑｕｅｎｃｅＮｕｍｂｅｒ＜ＢａｓｅＳｅｑｕｅｎｃｅ＋Ｓｉｚｅ）の場合、パケットは、バッファ内部にあってよい。パケットは、バッファ内の適切な場所に格納され得る。パケットへのポインタは、インデックス（ＰａｃｋｅｔＳｅｑｕｅｎｃｅＮｕｍｂｅｒ−ＢａｓｅＳｅｑｕｅｎｃｅ）に置かれ得る。そのインデックスがすでに非ＮＵＬＬ（たとえば、パケットポインタがすでにその場所に存在する）場合、（たとえば、パケットが複製パケットであり得るので）パケットは破棄され得る。次いで、どのパケットも配信され得る。バッファインデックス０がパケットポインタを含む場合、パケットは配信されてもよく、インデックスはＮＵＬＬにリセットされ得る。環状バッファポインタは、１だけ前方に移動されてもよく、ＢａｓｅＳｅｑｕｅｎｃｅ変数も増分され得る。これは、バッファインデックス０が、たとえばシーケンス内の次のパケットがまだ受信されていないことを示すＮＵＬＬになる（たとえば、パケットへのポインタを含まない）まで繰り返され得る。

あるいは、（ＰａｃｋｅｔＳｅｑｕｅｎｃｅＮｕｍｂｅｒ≧ＢａｓｅＳｅｑｕｅｎｃｅ＋Ｓｉｚｅ）の場合、パケットは、バッファの外側にあるが、より新しいことができる。これは、たとえば、バッファが余りにも小さいというインジケーションとなることができる。いくつかの実施形態では、シーケンスに空いた場所（ｈｏｌｅ）があるかどうかとは無関係に、この新しいシーケンス番号をバッファに持ち込むのに十分なパケットが配信され得る。

再順序付けバッファはまた、タイムアウトメカニズムを組み込むこともできる。シーケンスに空いた場所がある場合ですら、プログラマブルタイムアウトの後、パケットは上位レイヤに配信され得る。いくつかの実施形態では、タイムアウトメカニズムは、各パケットの受信タイムスタンプの記録を維持することを含むことができる。いくつかの実施形態では、タイムスタンプが固有のタイムスタンプではなくＲＸ時刻であることが望ましいことがあることに留意されたい。タイムアウトメカニズムは、バッファ内の第１の利用可能なパケットのタイムスタンプ、例えばたとえば第１のギャップを越えた（ｐａｓｔ）パケットを維持することをさらに含むことができる。第１の利用可能なパケットのタイムスタンプがタイムアウトする（すなわち、タイムアウト値よりも大きい）場合、そのパケット（およびタイムアウトした何らかの他のパケット）が配信され得る。

パケットはネットワークスタックに送られるので、インデックス０にパケットがないことがあることに留意されたい。この値を計算するには、第１のギャップを通って第１のパケットを検索しなければならないので、これは、比較的コストのかかる動作であることがあることにも留意されたい。

初期シーケンス番号に関して、ＴＣＰとＲＴＰの両方は、初期シーケンス番号をランダム化してシーケンス番号予測攻撃を防止することができることに留意されたい。いくつかの実施形態では、ハイブリッドレベルにおける送信機および受信機は、このシーケンス番号を制御しないことがある。しかしながら、いくつかの実施形態では、ストリームがフローを開始した後にストリーム分割およびアグリゲーションがアクティブ化され得る。さらに、アグリゲーションは、明示的にアクティブ化され得る。たとえば、送信機は、ストリーム（ストリーム識別子を含む）が分割されようとしていることを示すコマンドを受信機に送信することができる。これによって、受信機が、分割が始まる前に現在実行されているシーケンス番号を識別することが可能になり得、初期シーケンス番号のランダム化によって引き起こされ得る潜在的な問題を軽減する。

パケットシーケンス番号を利用する上記で説明した環状バッファは、多数の実施形態では使用されなくてもよいことに留意されたい。たとえば、任意の数の他の環状バッファ技法または他のアグリゲーションバッファ技法は、必要に応じて使用されてよい。本明細書中の他の場所で説明する切り換えマーカ技法の実施形態は、アグリゲーション再順序付けするための１つの可能な代替（または相補的な）オプションを表す。

さらなる考慮事項
データ構造
これまで述べたように、本開示の要素を実施するデバイスは、いくつかの実施形態では、１つまたは複数のメモリに情報を格納することができる。情報は、一組の実施形態では、１つまたは複数のデータ構造に格納され得る。たとえば、一組の実施形態では、ルーティングテーブルが維持されてもよく、このルーティングテーブルに、アクティブなストリームとその様々な特性（たとえば、ルーティング情報）とを識別する情報が格納され得る。たとえば、そのようなルーティングテーブルは、複数のストリームの各々に対して、ストリーム識別子と、ストリームの宛先アドレス（ＤＡ）と、ストリームのタイプと、優先レベルと、１つまたは複数の割り当てられたインターフェース（たとえば、１つまたは複数の伝送媒体を暗黙的または明示的に含む）とを含むことができる。いくつかの実施形態では、たとえば、複数のインターフェースに分割されたストリームに対して、ルーティングテーブルは、複数の割り当てられたインターフェースのうちどれがストリームを送信するために現在使用されているか、各割り当てられたインターフェース上で使用されるバーストサイズ、および／または現在使用されているインターフェース上で送信されている現在のバーストにどのくらい多くのパケットが残っているかを示す情報も含むことができる。

さらに、ストリームの１つまたは複数の宛先アドレスおよび／またはタイプの各々に対する伝送媒体の現在の好ましい順序を示すテーブルが維持され得る。このテーブルは、たとえば媒体利用率の変化、リンク容量などに基づいて、定期的に更新され得る。ルーティングテーブルはまた、たとえば、何らかのルーティングの変化（たとえば、負荷バランシング、フェイルオーバ、ストリームの分割、ストリームの完了の結果として、または何らかの他の理由で）にも基づいて、定期的に更新され得る。

バーストサイズ
大きいバーストは、複数のインターフェースの同時使用を制限することがあるので、いくつかの実施形態では、バーストのサイズを制限することが望ましいことがあり、これは、いくつかの実施形態によれば、ストリーム分割／アグリゲーションという目標に反することがあることに留意されたい。

たとえば、１４００バイトのパケットサイズを持ち１０Ｍｂｐｓで実行されているストリームは８９２ｐｐｓ（パケット毎秒）ということになる。２５５パケットのバーストは０．２８秒になる。言い換えれば、この場合、一方の媒体は０．２８秒間使用される、他方の媒体は使用されない。

デバイスの能力の発見
ストリームを分割する判定が行われるときはいつでも、宛先デバイスの能力を認識することが重要なことがある。たとえば、宛先ハイブリッドデバイスが、アグリゲーションをサポートしないレガシーデバイスであることがある。

デバイスは、トポロジ発見パケットの一部として能力を知らせることができる。たとえば、１つまたは複数の制御パケットの一部分は、アグリゲーションのサポートを宣言するために割り振られ得る。いくつかの実施形態では、デバイスは、この情報を送信し、負荷バランシングの判定中に使用されるネットワーク上のすべてのデバイスに関するそのような情報のデータベースを維持することができる。

パケットロスの最小化および複製パケットの除去
本開示の実施形態は、複数の伝送媒体がストリームの送信に利用可能であるシステムおよびそのようなシステムに関連する様々な技法に関する。実施形態の多くは、ある伝送媒体から別の伝送媒体へのストリームフローの切り換えに関する。パケットのロス、パケットの重複、および順序の乱れたパケット配信を含めて、そのようなパス切り換えによるいくつかのパケットフローの混乱があり得る。

ネットワーキングプロトコルおよびアプリケーションによって、そのようなパケットフローの混乱への反応は異なるが、一般に副作用がある。たとえば、ＴＣＰ／ＩＰは上記のうちいずれかに応じてスループットを抑制し、いくつかのビデオアプリケーションは視覚的欠陥を表示することがある。エンドユーザにシームレスな経験を提供するために、これらの混乱のすべてが、可能ならば最小限にされるかまたは解消されなければならない。

ハイブリッドシステムは、次の２つのシナリオの下でフローを切り換えることができる。すなわち、あるインターフェースに障害が発生し、そのインターフェースからのすべてのストリームが別のインターフェースに切り換えられるフェイルオーバと、媒体がオーバーサブスクライブし、１つまたは複数のストリームがそのストリームから別のインターフェースに切り換えられる負荷バランシングである。

あるインターフェースが依然として動作中であり、いくつかのパケットを送信するときすら、ハイブリッドシステムが、そのインターフェースを「障害が発生した」と見なすことがあり得ることに留意されたい。たとえば、いくつかのインターフェースでは、インターフェースの報告されたＰＨＹレートが閾値（たとえば、５Ｍｂｐｓまたは何らかの他のＰＨＹレート）を下回る場合、ハイブリッドシステムは、そのインターフェースを「障害が発生した」と見なすことがある。

利用することができる２つの一般的な通信インターフェースは、Ｗｉ−Ｆｉネットワークと、電力線ネットワーク（たとえば、ＨｏｍｅＰｌｕｇＡＶ）とを含む。Ｗｉ−ＦｉドライバとＨＰＡＶドライバの両方は、特定のストリームからのパケットの順序正しい配信を保証することができる。両方とも、送信のためにパケットをバッファリングされ得る。いくつかの実施形態によれば、外部アプリケーションは、どのパケットがＨＰＡＶドライバからではなくＷｉ−Ｆｉドライバから正常に送信されたに関する情報を取得することが可能であることがあり、外部アプリケーションは、どちらかのドライバの送信バッファからパケットを除去することが可能でないことがある。したがって、媒体が生きている限り（たとえば、媒体に障害が発生したと見なされる場合ですら）、送信バッファ内のパケットは引き続き送信される。

インターフェースに（本当に）障害が発生すると、そのバッファからそれ以上パケットを送信することができないことがある。バッファ内のパケットのすべてが失われることがあり、そのため、ハイブリッドシステムが、インターフェースに障害が発生したと決定し、新しいインターフェース上でパケットを送信し始めるまで、追加のパケットが送信される。パケットロスを減少させるメカニズムは、パケットはインターフェース上で送信されるとパケットの実行窓（バッファ）を保存し、切り換えるとき、それらのパケットを新しいインターフェース上で（再）送信することである。言い換えれば、パス切り換えがトリガされるときはいつでも、これらのパケットが新しいインターフェース上で送信され得る。

いくつかの実施形態によれば、そのような特徴が全体的にまたはストリームごとに実施され得る。たとえば、特徴が実施される各ストリームは、したがって、バッファサイズ（たとえば、格納できるパケットの数）を持つそれ自体のバッファと、バッファタイムウィンドウ（たとえば、どれくらい（時間的に）パケットを保持するかを指定する）とを有することができる。

特徴を実施するために、一組の実施形態によれば、パケットがインターフェース上で送信されると、そのフローが最初に識別され得る。フローによって、バッファリングが有効にされる場合、パケットがバッファに付加され得る。パケットがタイムウィンドウの外側にある場合、バッファが大きすぎる場合、および／またはパケットが正常に送信された場合、バッファが（たとえば、先頭から末尾まで）通過されることがあり、パケットが除去され得る。したがって、パケットが送信されるとき、バッファが維持され得る。

フローがある媒体から別の媒体に切り換えられているとき、バッファが（たとえば、先頭から末尾まで）通過されることがあり、正常に送信されたパケットが破棄され得る。正常に送信されたことが知られているパケットは、新しいインターフェース上で送信され得る。

パケットが正常に送信されたかどうか決定することは、いくつかのインターフェース（たとえば、Ｗｉ−Ｆｉまたはこの情報へのアクセスを提供する他のインターフェース）からのみ利用可能であってよいことに留意されたい。したがって、いくつかの実施形態では、この情報が、そのようなインターフェースからのパス切り換えにのみ使用され得る。

パケットロスの最小化に使用される、上記で説明したバッファは、パス切り換えが実行されるときはいつでも新しいインターフェース上でパケットを送信するために使用され得る。そのようなバッファ内のパケットの数は、いくつかの実施形態では、インターフェースに障害が発生したことをハイブリッドシステムが検出するのにどれくらいかかるか−数秒かかることがあるプロセス−によって定められ得る。したがって、少なくともいくつかの実施形態では、バッファサイズが＞１０００パケットであることができる。他の実施形態では、任意の数の他の（たとえば、上記より小さいまたは大きい）バッファサイズが使用され得る。

インターフェースを通して＞１０００パケットを送信することは、ドライバ（イーサネット、Ｗｉ−Ｆｉ、埋め込みＰＬＣ）のバッファを（比較的）即時に埋めることができる。したがって、これらの送信を抑制するメカニズムは、実施され得る。いくつかの実施形態では、連続した送信をブロックしないように、送信は、ハイブリッドブリッジの外部から抑制され得る。たとえば、トークンバケットフィルタキューイング規則（ＴＢＦ ｑｄｉｓｃ）は、そのような抑制メカニズムを実施する−それによって、最大レートが指定され得る。

上記で説明した送信バッファ再送信メカニズムは、パケットロスを減少させる働きをすることができる。しかしながら、パケットが古いインターフェース内ですでに発送されて送信中の場合、受信機が複製パケットを受信することができる。この比較的簡単な（部分的な）解決策は、（当初のインターフェース上で）正常に送信されたそれらのパケットをバッファから除去することであることができる。これは、Ｗｉ−Ｆｉインターフェース（上記で述べた）にとって可能であることがあり、しかしながら、（同様に、上記で述べたように）ＨＰＡＶインターフェースにとっては可能でないことがある。この特徴をＷｉ−Ｆｉ上で別のインターフェースパスへの移行に使用してすらも、この問題に完全には対処されないことがある。というのは、元の（Ｗｉ−Ｆｉ）インターフェースのバッファに依然として存在するパケットが除去されないことがあり、インターフェースが本当に死んでいない場合、送信され続けることがある。

より完全だが簡略化された（ＣＰＵコストの面では）解決策は、この特定の複製シナリオのいくつかの特徴を利用することができる。具体的には、ことを利用することができる。１つのインターフェース上で送信されたすべてのパケットは順序正しく受信される。あるインターフェースから別のインターフェースに切り換える判定がいったん行われると、元のインターフェース上でのすべてのさらなる送信が停止される。（たとえば、これは複製物が生成される原因であるので）複製物は複製バッファ内にのみ存在することができる。もちろん、いくつかの実施形態では、この解決策はまた、有利には、異なる条件を含む他のシナリオで使用され得る。

方法の特定の利点は、アルゴリズムが、パケット自体について仮定することができないことであり得る。言い換えれば、いくつかの実施形態では、データパケットの検査が行われる（具体的には、いくつかの実施形態では、シーケンス番号は、パケットに埋め込まれると仮定され得る）。

方法を実施するための送信機（データ送信元）側機能は、インデックスマーカ（Ｍ_I）パケットをＮパケットごとにデータストリームに挿入することを含むことができる。インデックスマーカはインデックス番号を含むことができ、インデックス番号は、各後続のインデックスマーカパケットにより１だけ増分され得る。インデックスマーカパケット（複数可）は、複製バッファの前に挿入され得る。したがって、これらのインデックスマーカパケットは、複製バッファの一部であってよい。

パス切り換えを実行するとき、複製バッファは再送信され得る。バッファマーカパケット（Ｍ_B）は、新しいインターフェース上で複製バッファの先頭および／または終端に挿入され得るそれぞれＭ_B,BおよびＭ_B,Eとする。Ｍ_B,Bでは、複製バッファの外部にある最後のインデックスマーカ（Ｍ_I）パケットのインデックス、ならびにそのインデックスマーカパケット以降にバッファから除去されたそのストリームからのパケットの数は、（正常に送信されたのであろうと、バッファサイズのための経年劣化したまたは除去されたのであろうと）含まれ得る。このデータ対は、（Ｉ_T，Ｌ_T）と呼ばれることがある。

方法を実施するための受信機（データシンク）側機能は、インデックスマーカ（Ｍ_I）パケットを追跡することを含むことができる。たとえば、受信された最後のインデックスおよびそのインデックスマーカ以降に受信されたそのストリームのパケットの数は、格納され得る。このデータ対は、（Ｉ_R，Ｌ_R）と呼ばれることがある。

バッファの先頭すなわちバッファマーカパケット（Ｍ_B,B）を受信するとき、代替インターフェースから入ってくるこのストリームに属するどのパケットも破棄され得る。様々な実施形態によれば、このブロッキングは、ある時間間隔（たとえば、プログラム可能な時間間隔）の後で除去されることもできるし、次のＭ_B,Bが（たとえば、新しいインターフェース上で）観測されるまで保持されることもできる。

さらに、Ｍ_B,Bから観測されたデータ対（Ｉ_T，Ｌ_T）が検査され、（Ｉ_R，Ｌ_R）と比較され得る。Ｉ_T＝Ｉ_RかつＬ_T≧Ｌ_Rの場合、パケットは破棄され得ない−新しいインターフェース上に複製パケットがないことがある。Ｉ_T＝Ｉ_RかつＬ_T＜Ｌ_Rの場合、第１のＬ_R−Ｌ_Tパケットは、元のインターフェース上ですでに受信された可能性があるので、バッファから破棄されることがある。Ｉ_T＜Ｉ_Rの場合、インデックスマーカパケットとインデックスＩ_Rが受信されるまで、複製バッファパケットは破棄され得る。その時点で、追加Ｌ_Rパケットは破棄され得る。（Ｉ_T＞Ｉ_R）の場合、パケットは破棄され得ない。これは、複製バッファが、フェイルオーバによるパケットロスを処理するのに十分なほど大きくなく、複製パケットは受信されていないことを示すことができる。

上記のアルゴリズムは、データの２つの複製ストリーム、すなわち、複製バッファリングされたパケットの受信が始まった後に古いインターフェースに到着するパケットと、フェイルオーバの後だが複製バッファリングされたパケットの受信の前に古いインターフェースに到着したパケットとを処理することができる。

いくつかの実施形態によれば、（上記で述べられた）複製バッファ有効化／無効化は、この特徴を制御するためにも使用され得る。言い換えれば、いくつかの実施形態では、複製バッファがフローに対して有効化された場合、インデックスマーカ（Ｍ_I）のみが挿入され得る。さらに、いくつかの実施形態では、ストリームパラメータにつき１つのインデックスマーカ間隔が構成可能とすることができる。たとえば、パス特性化情報に基づいてインデックスマーカ間隔を動的に調整することを望むことがある。

上記で説明した複製パケット最小化手順では、インデックスマーカパケット（Ｍ_I）がＮパケットごとにストリームに挿入され得ることを指定する。上記のアルゴリズムに基づいて、値Ｎは、固定される必要がないことがあり、時々または間隔ごとに、たとえば、送信されたパケットおよび受信されたパケットの適切なカウントが保持される限り、変えられてもよい。値Ｎはまた、複製バッファのサイズから独立することができる。いくつかの実施形態では、たとえば、Ｎは極めて大きくてよい。しかしながら、パケット誤り率（ＰＥＲ）とＮと受信された複製パケットの数との間に関係があることがある。

ＰＥＲにより、パケットが破棄される−これは、パケットは、送信されるとカウントされ得るが、受信されるとカウントされないことができることを意味する。あらゆるそのような欠落されたパケットの結果、複製パケットが受信されるようになることができる。たとえば、最後のＭ_I，Ｌ_T＝１０の後で１０個のパケットが送信される。しかしながら、ＰＥＲによって９個のパケットのみが受信された場合、Ｌ_R＝９である。この場合、受信機ではパケットは除去されず、その結果、複製パケットが受信され得る。したがって、複製パケットの可能性はＰＥＲ×Ｎに比例することができる。したがって、Ｎを増加させることによって、複製物を受信する可能性が増加することができる。

上記で述べたように、上記で説明したパケットロスの最小化技法は、他の場合は必要とされないことがある追加情報を格納することを必要とすることがある。いくつかの実施形態によれば、送信側に格納された追加情報は、最後のインデックスマーカパケット（ＭＩ）インデックスと、最後のインデックスマーカパケット以降のパケットの数とを含むことができる。

受信側に格納された追加情報は、最後のインデックスマーカパケットインデックスと、最後のインデックスマーカパケット以降のパケットの数と、ストリームインターフェース（たとえば、ストリームが受信されているインターフェース）とを含むことができる。いくつかの実施形態では、ストリームインターフェース上で受信されないすべてのパケットが破棄されるべきであることを示すブロックモードフラグも格納され得る。さらに、インデックスマーカパケットが現在検索されているかどうか（と、そのインデックスマーカパケットのインデックスと）を示す情報が格納されてもよく、および／または、（たとえば、上記で説明したように、複製物であると決定されたパケットの数に基づいて）破棄するパケットの数を示すカウンタが格納され得る。

当業者によって認識されるように、異なる実装形態は、パケットロスの最小化アルゴリズムに関する格納された異なる情報を含むことができる。

サービス品質
本開示の実施形態は、複数の伝送媒体を使用して通信するように構成されたデバイスによって使用され得る様々な技法に関する。これらの技法は、いくつかの実施形態では、必要に応じて、改善されたサービス品質（ＱｏＳ）に関するコンテンツ分類および区別を考慮せずに実施され得る。しかしながら、サービスプロバイダが、たとえば客がテレビのビデオが低品質であることまたは音声伝送が途切れることに動揺しないようにするために、タイムクリティカルなデータ（たとえばＮｅｔｆｌｉｘビデオ）と延期可能なデータ（たとえばファイルのダウンロード）とを区別することを望むことがある−サービスプロバイダはサービス品質を保証したいのである。小売り客も同様に、干渉または遅延を伴わずにインターネットビデオ（たとえばＨｕｌｕまたはＮｅｔｆｌｉｘ）をストリーミング可能であることを望むことがある。無料コンテンツの消費者ですら、サービス品質の保証／区別を予想することがある。

非ハイブリッドネットワークには、データが送信される単一の媒体のみがある。ハイブリッドネットワークには、データを送信するために使用できる複数の媒体があることがある−データの各々は、様々な動的に変化する特性を有する。したがって、ＱｏＳ問題は、別の次元となる。

このセクションでは、一組の実施形態によるハイブリッドネットワーキングシステムによって配信され得るＱｏＳの詳細について説明する。一組の実施形態によれば、ハイブリッドシステムの所望の振る舞い（識別されるサービスのタイプ（有料ビデオと無料ビデオなどとを含む）と、システムの挙動とを含む）と、この機能を配信するための実装アーキテクチャおよびアルゴリズムの記述が含まれる。

２つのタイプのＱｏＳがあることに留意されたい。優先されるＱｏＳは、優先レベルを持つパケットのタグ付けに関連する。パケットは、この優先順位に基づいて処理され得る（たとえば、より高い優先順位は、より低い優先順位とは異なって処理され得る）。パラメータ化されたＱｏＳは、媒体による帯域幅の予約および保証に関連する。帯域幅予約を持つストリームに属するパケットには、最高の優先順位（保証）配信が与えられる。

いくつかの媒体（たとえばＭｏＣＡ）は一種のパラメータ化されたＱｏＳを実施するが、このパラメータ化されたＱｏＳは、エンドツーエンド帯域幅予約と（帯域幅を予約するための）アプリケーションレベルの関与とを必要とすることがあるので、実際には使用されないことがある。したがって、このセクションは、優先されるＱｏＳに焦点を当てる。

ＱｏＳ関連の振る舞いは、ハイブリッドネットワークのいくつかの態様において適切であることがある。これらの態様のうちいくつかとしては、データの異なるタイプのサービス（クラス）への分類、この分類に基づくデータのタグ付け、分類されたデータのパス選択および特定のインターフェースへの割り当て、フェイルオーバおよびフローの再割り当て、過輻輳（ｏｖｅｒ−ｃｏｎｇｅｓｔｉｏｎ）の場合のトラフィックの負荷バランシング、ならびにデータストリームすべてをサポートするのに不十分な帯域幅があるときの異なるデータストリームのストリーム優先順位付与があり得る。

データの分類は、データパケットをストリームに分離することと、ストリームを特定タイプのサービスとして分類することとを伴うことができる。一組の実施形態により分類され得るいくつかの可能なタイプのサービスとしては、インターネットストリーミングビデオ、インターネットストリーミングオーディオ、インターネットリアルタイムオーディオ／ビデオ、および／または他のタイプのサービスがある。

分類は、コンテナのタイプではなくパケットの内容を検査することを含むことができることに留意されたい。したがって、コンテンツタイプの分類は、ＩＰｖ４トラフィックまたはＩＰｖ６トラフィックのどちらかを用いて可能とすることができる。

いくつかのタイプのトラフィックは、すでにクラスに従ってタグ付けされている可能性があるので、分類されないことがあることにも留意されたい。そのようなタイプのトラフィックの例としては、ＩＰＴＶ、ＶｏＤ（通信事業者により提供されるビデオオンデマンド）、およびＶｏＩＰがある。

データは、いったん特定タイプのトラフィックとして分類されても、依然としてタグ付けされる必要があることがある。いくつかの実施形態によれば、いくつかのシステム要素は、異なるレベルのタグ粒度を利用するように構成され得る。たとえば、ハイブリッドシステムは、潜在的には、ネットワークドライバよりも高い粒度の分類を使用することが可能であることがある。たとえば、一実施形態では、「ビデオ」はたった１つのタグを有することができるが、ハイブリッドシステムは、ビデオのＩＰＴＶタイプと、ＶｏＤタイプと、ＯＴＴタイプとを区別するように構成され得る。

ストリームが起動されると、ストリームは、定期的に更新されるデフォルトインターフェースに割り当てられ得る。デフォルトインターフェースを選択するためのアルゴリズムは、各利用可能な媒体のリンク容量（ＬＣ）を最初に考慮することを含むことができる。高可用性シナリオでは、新しいトラフィックをサポートするのに十分なリンク容量（たとえば、２５Ｍｂｐｓなどのあらかじめ設定された閾値または動的な閾値または何らかの他の閾値よりも大きいリンク容量）が、複数の媒体上で利用可能であることができる。この場合、媒体（たとえば、ＬＣ閾値よりも高いＬＣを持つ媒体のみを考慮する）が、プログラム可能な順序たとえば「Ｐ５２」に基づいて選択され得る。低可用性シナリオでは、リンク容量の高い利用可能な媒体がないことがある。この場合、最高のリンク容量を持つ媒体が単に選択され得る。

媒体優先権のプログラム可能な順序はトラフィックのクラスごとに構成可能とすることができることに留意されたい。たとえば、「Ｐ５２」という上記の例は、ＩＰＴＶに適用し、ＩＰＴＶストリームは好ましくは最初にＰＬＣ、続いてＷｉ−Ｆｉ５ＧＨｚ、さらに続いてＷｉ−Ｆｉ２．４ＧＨｚに割り当てられ得ることを示すことができる。

いくつかの実施形態では、「高可用性」と考えられるリンク容量閾値も、トラフィックのクラスごとに構成可能なパラメータとすることができる。もちろん、ストリームが起動されたとき、どれくらい多くの帯域幅を必要とするかが知られていないことがある。この閾値によって、振る舞いをトラフィックのクラスごとにカスタマイズすることができる。たとえば、一組の実施形態によれば、少なくとも２５ＭｂｐｓのＬＣがＩＰＴＶに利用可能であることが望ましいことがあるが、ＯＴＴに関しては、１０ＭｂｐｓのＬＣが十分であることができる。すべてのクラスに単一の閾値を使用することも可能である。

いくつかの実施形態では、一種のトラフィックがいくつかの媒体から除外され得ることに留意されたい。たとえば、利用可能な伝送媒体のうちいくつかのみが伝送媒体の好ましい順序で指定される（たとえば、「２５」という好ましい順序が、Ｗｉ−Ｆｉ２ＧおよびＷｉ−Ｆｉ５Ｇのみが考えられ、Ｗｉ−Ｆｉ２ＧとＷｉ−Ｆｉ５Ｇの両方が無効化された場合であってもフローはＰＬＣインターフェース上に送られないことを意味することがある。この場合、フローは破棄され得る。これは、実装形態に応じて、望ましいオプションであることもあれば、そうでないこともある。

上記で説明したパス選択アルゴリズムは、リンク容量に関する。上記で述べたように、リンク容量は、特定の伝送媒体上で送信元ポイントから宛先に送信できる（一般的にＭｂｐｓ単位で測定される）トラフィックの量とすることができる。リンク容量は、リンクの物理的特性（たとえばＰＨＹレートおよびＰＥＲ）ならびに全体的な媒体の輻輳を考慮に入れることができる。しかしながら、ＱｏＳの観点から、クラス（優先順位）固有であるようにリンク容量を修正することが望ましいことがある。たとえば、いくつかの実施形態では、リンク容量は、送信元ポイントから宛先に（Ｍｂｐｓ単位で）送信できる特定の優先順位クラスに関するトラフィックの量と定義され得る。したがって、特定のハイブリッドデバイスに関して、リンク容量は、ＬＣ［ＤＡ］［Ｐｒｉｏｒｉｔｙ］という二次元配列とすることができる。

チャネルがアイドル状態のとき、特定の宛先へのすべてのリンク容量、すなわちＬＣ［ＤＡ］［＊］は同一であることに留意されたい。しかし、媒体上にトラフィックがあるとき、優先順位の高いデータに対するリンク容量は、優先順位の低いデータに関するよりも高くすることができる−すなわちＬＣ［ＤＡ］［ＨＩＧＨ］≧ＬＣ［ＤＡ］［ＬＯＷ］である。これにより、優先順位のより高いトラフィックが優先順位の低いトラフィックを押しのける可能性を考慮に入れることができる。

いくつかの実施形態では、サポートされる優先順位の数は、下位媒体によって定められてもよく−たとえば、一組の実施形態では、この数は、Ｗｉ−ＦｉとＰＬＣの両方に関して４にすることができる。したがって、この場合、分類により、２つのタイプのストリーム間に、より高い粒度が存在する（たとえば、ＩＰＴＶとＶｏＤを区別することが可能である）場合であっても、利用可能なリンク容量の観点から、これらのストリームは同一とすることができる。他の数のサポートされる優先順位も可能である。

ある媒体に故障が発生すると、ストリームは、他の利用可能な媒体に再び割り当てる。一組の実施形態によれば、故障が発生したインターフェース上の各ストリームに対して、ストリームが代替インターフェースに切り換え可能かどうか決定され得る。このセクションで以前に説明したパス選択アルゴリズムは、代替インターフェースを見つけるために使用され得るすなわち、十分な帯域幅を持つ複数の媒体がある場合、ストリームのその優先順位クラスに関する媒体優先順位構成に基づいて、媒体を選択する。ストリーム固有のリンク容量も使用され得る。十分な容量がない場合、ストリーム優先順位付け方法が使用され得る。

媒体が過剰輻輳（ｏｖｅｒ−ｃｏｎｇｅｓｔｅｄ）になる（媒体利用率が閾値を超える）と、輻輳を緩和するために、いくつかのフローが他の媒体に再び割り当てられる必要があることがある。いくつかの実施形態によれば、優先順位の高いフロー（一組の実施形態によれば、ＩＰＴＶ／ＶｏＤ／ＯＴＴ／ＶｏＩＰなど）は、たとえば欠陥を回避するために、可能な場合は切り換えられるべきでない。言い換えれば、優先順位のより低いフローが切り換えの第１の候補であるべきである。

一組の実施形態によれば、負荷をバランスするために、過剰輻輳した媒体上のストリームのより低い優先レベルから始まって、より高い優先レベルに移動して、以下のステップが行われ得る。最高の媒体利用率を持つ次のストリームが選択され得る。ストリームが代替インターフェースに切り換えられるかどうか決定され得る。これは、このセクションで以前に説明したパス選択アルゴリズム、すなわち、十分な帯域幅を持つ複数の媒体がある場合、ストリームのその優先順位クラスに関する媒体優先順位構成に基づいて、媒体を選択することを含むことができる。ストリーム固有のリンク容量も使用され得る。ストリームが切り換えられ得ない場合、次のストリームが選択され得る。最低の優先レベルのすべてのストリームが切り換えられ得ない場合、次に最も高い優先レベルで最高の媒体利用率を持つストリームが選択され得る。どのストリームも切り換えられるのに十分なリンク容量がない場合、たとえば、他の媒体も過剰輻輳している場合、ストリーム優先順位付け方法が使用され得る。

すべての媒体が過剰輻輳し、負荷バランシングが実行不可能であるとき、媒体上のすべてのストリームの品質が劣化することがある。２つの可能な過剰輻輳シナリオ、すなわち、過剰輻輳を引き起こす優先順位のより高いストリームと優先順位のより低いストリームの混合物があるシナリオ、または等しい優先順位を持つ一組のストリームが過剰輻輳を引き起こしているシナリオがある。

どのシナリオが発生するかに応じて、様々な構成可能な挙動が可能である。ストリームの優先順位が混合している場合、優先順位のより低いストリームが破棄され得る。必要／可能な場合、より細かい粒度の優先順位付けが使用され得る。たとえば、可能な場合、異なるタイプのビデオストリーム（たとえば、ＩＰＴＶ対ＶｏＤ対ＯＴＴなど）間での優先順位の変動が使用され得る。代替オプションは、ＴＣＰストリームのスループットを抑制することとすることができる。しかしながら、そのようなストリームのスループット特定対時間特性を理解するために、ビデオＴＣＰストリーム（たとえば、ＯＴＴストリームまたはＶｏＤストリーム）の特性化が望ましいことがある。たとえば、いくつかの実施形態では、ビデオＴＣＰストリームを抑制しないことが好ましいことがある。

ストリームの優先順位が等しい場合、様々なオプションが存在する。１つの可能性は、ビットレートに対して最も大きなリソースを消費するフローを破棄することである。いくつかの実施形態では、フローの優先順位は、宛先アドレスごとに構成され得る。たとえば、居間のＴＶへのトラフィックは、寝室のＴＶへのトラフィックよりも高い優先順位を有することができる。ＴＣＰストリームのスループットに制限を設けることは、１つのオプションとなることができる。別の可能性は、最も新しいフローを破棄することである。しかしながら、いくつかの実施形態では、たとえば、ユーザがあるＩＰＴＶチャネルから別のチャネルに切り換える場合、すばやいチャネル切り換えがオーバーサブスクリプションの１つの可能な原因であることがある。両方のストリームが切り換え中に同時に実行されてもよく（したがって、「黒い画面」は出現しない）、エンドデバイスは、適切な（たとえば、最も新しい）ストリームを選択して表示することができる。しかしながら、リソースが競合する場合、新しいストリームは、より古いストリームよりもリソースを優先的に受信するべきである。したがって、同じエンドデバイスに向かう複数のフローがある場合、最も古いフローが破棄され得る。

一組の実施形態によれば、必要に応じて、追加のＱｏＳ固有の制約がパケットアグリゲーションに課せられ得る。たとえば、可能な場合、優先順位の高いストリームではなく、優先順位のより低いストリームが分割／アグリゲーションされ得る。さらに、いくつかのトラフィックタイプはアグリゲーションされないと指定することを可能にするように構成可能なパラメータが提供され得る。

いくつかの実施形態では、（たとえば、欠陥の可能性があるために）ＶｏＩＰストリームを分割／アグリゲーションしないことが望ましいことがあることに留意されたい。しかしながら、多数の実施形態では、そのようなストリームは、極めて小さな帯域幅を利用することができ、したがって、一般に、分割／アグリゲーションの好ましい候補でないことがある。

上記で述べたように、ＱｏＳの考慮事項を含むパス特性化は、宛先および優先レベルごとの増大されたリンク容量を利用することができる。実装レベルでは、これは、優先レベルごとの媒体利用率になることができる。というのは、それは、いくつかの実施形態によれば、生のリンク容量から利用可能なリンク容量を決定するために使用され得るからである。

チャネルアクセスは、複数のノードの相互作用およびこれらのノードが送信しなければならないトラフィックの優先順位に左右されることがあることに留意されたい。ＰＬＣの場合、このアクセスは完全に協調することができ、厳密な優先順位を有する。Ｗｉ−Ｆｉの場合、これは、統計学的アクセスとすることができる−この場合、優先順位のより高いトラフィックほど、チャネルにアクセスする高い可能性を有する。ノード内でのアクセスは、たとえどんな送信インターフェースであろうとも、依然として、厳密な優先順位によることができる（たとえば、あるノードが、送信する複数のクラスのトラフィックを有するとき、このノードは、厳密な優先順位を用いて送信することができる）。

いくつかの実施形態によれば、３つのサービス品質レベルがサポートされ得る。これらのサービス品質レベルとしては、高い優先順位（たとえば、緊急転送（ｅｘｐｅｄｉｔｅｄ ｆｏｒｗａｒｄｉｎｇ））、中程度の優先順位、および通常の優先順位があり得る。たとえば、一組の実施形態では、ビデオ、ボイスオーバーＩＰ、または最小のパケットロスおよび低遅延で配信されることが必要な何らかの他のカスタムストリームが、高い優先順位を割り当てられ得る。中程度の優先順位は、何らかの他の優先順位のより高いトラフィックに割り当てられてもよく、通常の優先順位（最良の取組み）は、何らかの他のトラフィックタイプに割り当てられ得る。

いくつかの実施形態によれば、ハイブリッド制御パケットは、様々なハイブリッド制御機能に使用され得る。これらは、少なくともいくつかの実施形態では、システムの適切な振る舞い（トポロジ発見、パス特性化など）にとって極めて重要なことがある。したがって、制御パケットがネットワーク輻輳により宛先に到着しない場合、ハイブリッド機能が損なわれることがある。したがって、いくつかの実施形態によれば、ハイブリッド制御パケットは、一般的に、利用可能な最も高い優先順位を有することができる。

この例外は、マーカパケット（たとえば、バッファ開始マーカパケット／バッファ終了マーカパケット、ストリームの開始マーカパケット／ストリームの終了マーカパケット、および／またはインデックスマーカパケット）とすることができる。一組の実施形態によれば、マーカパケットは、パケットをフローとともに正しい順序で保持するために、アタッチされたフローを模倣することができる。模倣としては、同一の優先順位付け、宛先アドレス、および／または他の特性があり得る。

双方向データ
いくつかの実施形態では、特定のＴＣＰフローのすべてのトラフィックを単一のインターフェース上に強制的に流れさせる機能が実施され得ることに留意されたい。これは、データおよびＡＣＫストリームが異なるインターフェース上にある場合に遅延差がフローを抑制するようにＴＣＰをトリガし得るという懸念から行われることがある。

いくつかの実施形態では、本明細書で説明するパス選択スキームにおいて、あらゆるデバイスが、あらゆる他のデバイスとは無関係に（フェイルオーバまたは負荷バランシングによる）パス選択および切り換えに関して判定を行うと仮定することができる。具体的には、あらゆるデバイスは、それ自体から発生して、それ自体を通ってブリッジングされるストリーム（たとえば、ストリームのパスの次の一部分に対してデバイスが発生させるストリーム）に関して、これらの判定を行うことができる。２つのデバイスの間に、いずれかの方向で、複数のデータストリームがある場合、各々は、媒体に割り当てられ、必要に応じて他のストリームとは無関係に切り換えられ得る。

しかしながら、ＩＰ／ＴＣＰなどのいくつかの高水準プロトコルでは、異なる方向の複数のストリームは、実際には、機能的に互いと関連付けられる。たとえば、ＩＰ／ＴＣＰの場合、ＴＣＰデータは一方向に流れることができ、このデータに対応するＴＣＰ ＡＣＫは他の方向に流れる。多くのネットワーキングプロトコルは、たとえばターンアラウンドタイムを短縮することによって、そのような依存する双方向トラフィックの性能を最適化するように設計され得る。いくつかの実施形態によれば、下位媒体によるそのような最適化は、すべての依存ストリームが同じ媒体を使用している場合のみ行われ得る。したがって、いくつかの実施形態では、ＩＰ／ＴＣＰストリーム（および／または関連する双方向トラフィックを持つ他のストリーム）の場合、そのようなストリームは識別可能であり、すべての依存ストリームは同じ媒体の使用が保証され得る。

これを達成する１つの可能なメカニズムとして、関連する「スレーブ」ストリームをストリームが有することができることを受信デバイスに明示的に通知する送信デバイスがあり得、「スレーブ」ストリームは、「マスタ」ストリームと同じ伝送媒体を利用するべきである。送信デバイスは、１つまたは複数の制御パケットを介して、または別の手段を介して、受信デバイスに通知することができる。

これを達成する別の可能なメカニズムとしては、そのようなストリームを検出および識別する受信デバイスがあり得る。たとえば、受信デバイスは、ストリームの第１の受信されたパケットの検査に基づいて、ストリームを識別することができる。その検査から、パケットが、反対方向の関連するストリームが生成され得るタイプであることが示された場合、受信デバイスは、受信デバイスがそのストリームに関するパス選択または負荷バランシングの判定を行うべきでないことを示す情報を格納することができる。受信デバイスはまた、ストリームが「スレーブ」ストリームである（たとえば、パス選択または負荷バランシングの判定はローカルで行われるべきでない）ことを示す情報を、送信デバイスがストリームの性質を受信デバイスに明示的に通知する上記で説明したメカニズムに格納することができることに留意されたい。

したがって、一組の実施形態では、第１のストリームの第１の複数のパケットが、第２のデバイスから第１の伝送媒体上で受信され得る。第２のストリームが第１のストリームに関連して生成され得ることが決定されてもよく、その場合、第２のストリームは、第２のデバイスへの送信を目的とする。いくつかの実施形態では、第２のストリームが第１のストリームに関連して生成され得るというインジケーションが、第２のデバイスから受信され得る。この場合、第２のストリームが第１のストリームに関連して生成され得ると決定することは、第２のストリームが第１のストリームに関連して生成され得るというインジケーションを受信することに基づくことができる。あるいは、第１のデバイスは、たとえば、第１のストリームの１つまたは複数のパケットを検査してパケットタイプを決定することによって、第２のデバイスからのインジケーションとは無関係に、第２のストリームが第１のストリームに関連して生成され得ると決定することができる。

第１のストリームが第１の伝送媒体に割り当てられ、第２のストリームが第１のストリームと関連付けられることを示す情報が、格納され得る。第２のストリームの第２の複数のパケットは、第１の伝送媒体上で第２のデバイスに送信されてもよく、これは、第１のストリームが第１の伝送媒体に割り当てられ、第２のストリームが第１のストリームと関連付けられることを示す情報に基づくことができる。

いくつかの実施形態では、第１のストリームの第１の複数のパケットを受信したことを受けて、第２のストリームの第２の複数のパケットが生成され得る。たとえば、一組の実施形態では、第１の複数のパケットとしては、ＴＣＰデータパケットがあり得るが、第２の複数のパケットとしては、このＴＣＰデータパケットに応答して生成されたＴＣＰ ＡＣＫパケットがあり得る。

関連する逆方向ストリームを持つストリームが、ストリーム分割およびアグリゲーションに関する追加の問題を提起することがあることに留意されたい。この場合、様々な実施形態によれば、そのようなストリームがストリーム分割から除外され得るか、または（たとえば、可能な場合）「スレーブ」ストリームを引き起こすプロトコル機能（たとえば、ＴＣＰ ＡＣＫ機能）が無効化され得る。

自己抑制
上記で説明したように、いくつかの実施形態によれば、いくつかのデバイスは、送信インターフェース上でパケットをバッファリングすることによって、フェイルオーバ時にロスされるパケットをなくす助けとなるメカニズムを実施することができる。次いで、フェイルオーバの場合、このバッファが新しいインターフェース上で送信され得る。同様に、受信側では、パケットは、順序正しい配信を保証するために、新しいインターフェース上で検出されると、バッファリングされ得る。後者の場合、すべてのパケットが受信されたことがいったん検出されると、バッファリングされたパケットは、すべてプロトコルスタックに送られ得る。いずれの場合も、多数のパケットが短時間に送信され得る。これは、いくつかの実施形態では、メモリ枯渇によるパケットロスを引き起こす可能性を有する。

上記で簡単に言及したあるメカニズムは、よく知られている抑制メカニズム（ＴＢＦなど）を使用して、パケットが宛先に送られる速度を制限することを含むことができる。しかしながら、これらの汎用メカニズムは複雑なことがある−たとえば、これらのメカニズムは、パケットが宛先に送られる速度を調節する助けとなる追加タイマを利用することができる。

より単純なメカニズムは、自己抑制を含むことができる。特定のストリームのパケットは、そのようなイベントの後で引き続き送受信され得るので、そのような送信または受信を、パケットを宛先に送るためのタイマとして使用することが可能なことがある。たとえば、一組の実施形態では、ＦＩＦＯバッファが実施されてもよく、このバッファでは、新しいパケットがバッファの末尾に置かれ、一方、プログラム可能な数のより古いパケットは先頭から除去され、処理される（たとえば、宛先に送られる）ことができる。バッファは、最終的には枯渇することがあり、その時点で、自己抑制フェーズが完了することができる。様々な実施形態によれば、自己抑制型ＦＩＦＯバッファは、必要に応じて送信機側および／または受信機側のいずれかまたは両方で実施され得る。

上記の実施形態についてかなり詳細に説明してきたが、上記の開示が十分に理解されれば、数多くの変形形態および修正形態が当業者に明らかになるであろう。以下の特許請求の範囲は、すべてのそのような変形形態と修正形態とを包含すると解釈されることが意図されている。

Claims (26)

1. 第１のストリームを送信する伝送媒体を選択するデバイスのための方法であって、前記方法は、
   複数の伝送媒体の各々のパス特性を決定することと、ここで、前記複数の伝送媒体のうちの少なくとも１つは、本質的に、実質的に動的である、
   前記決定されたパス特性に基づいて前記第１のストリームのための前記複数の伝送媒体から第１の伝送媒体を選択することと、
   前記第１の伝送媒体上で前記第１のストリームの第１の複数のパケットを送信することと
   を備える、方法。
2. 前記パス特性は、
   前記伝送媒体のリンク容量、
   現在の媒体利用率、または
   最大媒体利用率
   のうちの１つまたは複数を備える、
   請求項１に記載の方法。
3. 前記第１のストリームの内容のタイプを決定することをさらに備え、
   前記第１の伝送媒体を選択することは、前記第１のストリームの内容の前記タイプにさらに基づく、
   請求項１に記載の方法。
4. 前記第１のストリームの優先レベルを決定することをさらに備え、
   第１の伝送媒体を前記選択することは、前記第１のストリームの前記優先レベルにさらに基づく、
   請求項１に記載の方法。
5. 前記伝送媒体の前記パス特性に基づいてストリーム内容の複数のタイプの各々のための伝送媒体の好ましい順序を決定することをさらに備える、
   請求項１に記載の方法。
6. 少なくとも１つの伝送媒体の少なくとも１つのパス特性の変更を検出することと、
   少なくとも１つの伝送媒体の少なくとも１つのパス特性の前記検出された変更に基づいて前記ストリーム内容の複数のタイプのうちの少なくとも１つのための前記伝送媒体の好ましい順序を修正することと
   をさらに備える、請求項５に記載の方法。
7. 前記第１の伝送媒体の現在の媒体利用率が第１の閾値を超えたと決定することと、
   前記第１の伝送媒体上での現在の媒体利用率が前記第１の閾値を超えたと決定することに基づいて第２の伝送媒体上での送信のために前記第１のストリームを選択することと、
   前記第２の伝送媒体上での送信のために前記第１のストリームを選択することに基づいて前記第２の伝送媒体上で前記第１のストリームの第２の複数のパケットを送信することと
   をさらに備え、前記第１のストリームのパケットは、前記第２の伝送媒体上での送信のために前記第１のストリームを前記選択した後、前記第１の伝送媒体上で送信されない、
   請求項１に記載の方法。
8. 複数の伝送媒体を介して第２のデバイスに結合するための複数のポートと、ここで、前記複数の伝送媒体のうちの少なくとも１つは、本質的に、実質的に動的である、
   ストリームを送信する伝送媒体を選択することを行うように構成された論理と
   を備え、前記論理は、
   前記複数の伝送媒体の各々のパス特性を決定することと、
   前記決定されたパス特性に基づいて前記第１のストリームのための前記複数の伝送媒体から第１の伝送媒体を選択することと、
   前記第１の伝送媒体上で前記第１のストリームの第１の複数のパケットを送信することと
   をさらに行うように構成される、
   デバイス。
9. 前記パス特性は、
   前記伝送媒体のリンク容量、
   現在の媒体利用率、または
   最大媒体利用率
   のうちの１つまたは複数を備える、
   請求項８に記載のデバイス。
10. 前記論理は、
    前記第１のストリームの内容のタイプを決定することを行うようにさらに構成され、
    第１の伝送媒体を前記選択することは、前記第１のストリームの内容の前記タイプにさらに基づく、
    請求項８に記載のデバイス。
11. 前記論理は、
    前記第１のストリームの優先レベルを決定することを行うようにさらに構成され、
    第１の伝送媒体を前記選択することは、前記第１のストリームの前記優先レベルにさらに基づく、
    請求項８に記載のデバイス。
12. 前記論理は、
    前記伝送媒体の前記パス特性に基づいてストーム内容の複数のタイプの各々のための伝送媒体の好ましい順序を決定することを行うようにさらに構成される、
    請求項８に記載のデバイス。
13. 前記論理は、
    少なくとも１つの伝送媒体の少なくとも１つのパス特性の変更を検出することと、
    少なくとも１つの伝送媒体の少なくとも１つのパス特性において前記検出された変更に基づいてストリーム内容の前記複数のタイプのうちの少なくとも１つのために前記伝送媒体の好ましい順序を修正することと
    を行うようにさらに構成される、請求項１２に記載のデバイス。
14. 前記論理は、
    前記第１の伝送媒体の現在の媒体利用率が第１の閾値を超えたと決定することと、
    前記第１の伝送媒体の現在の媒体利用率が前記第１の閾値を超えたと決定することに基づいて第２の伝送媒体上での送信のために前記第１のストリームを選択することと、
    前記第２の伝送媒体上での送信のために前記第１のストリームを選択することに基づいて前記第２の伝送媒体上で前記第１のストリームの第２の複数のパケットを送信することと
    を行うようにさら構成され、前記第１のストリームのパケットは、前記第２の伝送媒体上での送信のために前記第１のストリームを前記選択した後、前記第１の伝送媒体上で送信されない、
    請求項８に記載のデバイス。
15. 第１のストリームを送信する伝送媒体を選択するデバイスのためのプログラム命令を備えるコンピュータ可読記憶媒体であって、前記プログラム命令は、
    複数の伝送媒体の各々のパス特性を決定することと、ここで、前記複数の伝送媒体のうちの少なくとも１つは、本質的に、実質的に動的である、
    前記決定されたパス特性に基づいて前記第１のストリームのための前記複数の伝送媒体から第１の伝送媒体を選択することと、
    前記第１の伝送媒体上で前記第１のストリームの第１の複数のパケットをルーティングすることと
    を行うために実行可能である、コンピュータ可読記憶媒体。
16. 複数の伝送媒体の負荷をバランスするデバイスのための方法であって、前記複数の伝送媒体のうちの少なくとも１つは、本質的に、実質的に動的であり、前記方法は、
    第１の伝送媒体上で第１のストリームの第１の複数のパケットを送信することと、
    前記第１の伝送媒体の現在の媒体利用率が第１の閾値を超えたと決定することと、
    前記第１の伝送媒体の現在の媒体利用率が前記第１の閾値を超えたと決定することに基づいて第２の伝送媒体上での送信のために前記第１のストリームを選択することと、ここで、前記選択することは、前記複数の伝送媒体のうちの１つまたは複数のパス特性および前記第１のストリームの１つまたは複数の特性にさらに基づく、
    前記第２の伝送媒体上で前記第１のストリームの第２の複数のパケットを送信することと
    を備え、前記第１のストリームのパケットは、前記第２の伝送媒体上での送信のために前記第１のストリームを前記選択した後、前記第１の伝送媒体上で送信されない、
    方法。
17. 前記第２の伝送媒体上で前記第１のストリームを送信することが第２の閾値を超える前記第２の伝送媒体の媒体利用率を生じさせないことになると決定することをさらに備え、
    前記第２の伝送媒体上での送信のために前記第１のストリームを前記選択することは、前記第２の伝送媒体上で前記第１のストリームを送信することが第２の閾値を超える前記第２の伝送媒体の媒体利用率を生じさせないことになると前記決定することに少なくとも部分的に基づく、
    請求項１６に記載の方法。
18. 前記第１のストリームは、第１の優先レベルを有し、前記第２の伝送媒体上で送信するために前記第１のストリームを前記選択することは、前記第１の優先レベルに少なくとも部分的に基づく、
    請求項１６に記載の方法。
19. 前記第１の優先レベルは、前記第１のストリームの内容のタイプに基づく、
    請求項１８に記載の方法。
20. 前記第１のストリームの前記１つまたは複数の特性は、前記第１のストリームの推定された帯域幅要件を備え、
    前記複数の伝送媒体の前記１つまたは複数のパス特性は、それぞれの伝送媒体ごとに、
    前記伝送媒体のリンク容量、
    現在の媒体利用率、または
    最大媒体利用率
    のうちの１つまたは複数を備える、
    請求項１６に記載の方法。
21. 複数の伝送媒体を介して第２のデバイスに結合するためのポートと、ここで、前記複数の伝送媒体の少なくとも１つは、本質的に、実質的に動的である、
    前記複数の伝送媒体の付加をバランスすることを行うように構成された論理と
    を備え、前記論理は、
    前記複数のポートのうちの第１のポートを介して第１の伝送媒体上で第１のストリームの第１の複数のパケットを送信することと、
    前記第１の伝送媒体の現在の媒体利用率が第１の閾値を超えたと決定することと、
    前記第１の伝送媒体の現在の媒体利用率が前記第１の閾値を超えたと決定することに基づいて第２の伝送媒体上での送信のために前記第１のストリームを選択することと、ここで、前記選択することは、前記複数の伝送媒体のうちの１つまたは複数のパス特性および前記第１のストリームの１つまたは複数の特性にさらに基づく、
    前記複数のポートのうちの第２のポートを介して前記第２の伝送媒体上で前記第１のストリームの第２の複数のパケットを送信することと
    を行うように構成され、前記第１のストリームのパケットは、前記第２の伝送媒体上での送信のために前記第１のストリームを前記選択した後、前記第１の伝送媒体上で送信されない、
    デバイス。
22. 複数の伝送媒体の負荷をバランスするためのプログラム命令を備えるコンピュータ可読記憶媒体であって、前記プログラム命令は、
    送信のための第１の伝送媒体に第１のストリームの第１の複数のパケットをルーティングすることと、
    前記第１の伝送媒体の現在の媒体利用率が第１の閾値を超えたと決定することと、
    前記第１の伝送媒体の現在の媒体利用率が前記第１の閾値を超えたと決定することに基づいて第２の伝送媒体上での送信のために前記第１のストリームを選択することと、ここで、前記選択することは、前記複数の伝送媒体のうちの１つまたは複数のパス特性および前記第１のストリームの１つまたは複数の特性にさらに基づく、
    前記第２の伝送媒体上で送信するために前記第１のストリームを選択することに基づいて送信するための前記第２の伝送媒体に前記第１のストリームの第２の複数のパケットをルーティングすることと
    を行うために実行可能である、コンピュータ可読記憶媒体。
23. 双方向ストリームに関連する第１のデバイスのための方法であって、前記方法は、
    第１の伝送媒体上で第２のデバイスから第１のストリームの第１の複数のパケットを受信することと、
    第２のストリームが前記第１のストリームに関連して生成されることができると決定することと、ここで、前記第２のストリームは、前記第２のデバイスに送信するためのものである、
    前記第１のストリームが前記第１の伝送媒体に割り当てられ、前記第２のストリームが前記第１のストリームに関連付けられることを示す情報を格納することと、
    前記第１の伝送媒体上で前記第２のデバイスに前記第２のストリームの第２の複数のパケットを送信することと
    備え、前記第１の伝送媒体上で前記第２のデバイスに前記第２のストリームの前記第２の複数のパケットを前記送信することは、前記第１のストリームが前記第１の伝送媒体に割り当てられ、前記第２のストリームが前記第１のストリームに関連付けられることを示す前記情報に基づく、
    方法。
24. 前記第２のストリームが前記第２のデバイスから前記第１のストリームに関連して生成されることができるインジケーションを受信することをさらに備え、第２のストリームが前記第１のストリームに関連して生成されることができると前記決定することは、前記第２のストリームが前記第１のストリームに関連して生成されることが前記できるインジケーションを受信することに基づく、
    請求項２３に記載の方法。
25. 前記第２のストリームの前記第２の複数のパケットは、前記第１のストリームの前記第１の複数のパケットに応じて生成される、
    請求項２３に記載の方法。
26. 前記第１の複数のパケットは、ＴＣＰデータパケットを備え、前記第２の複数のパケットは、ＴＣＰ ＡＣＫパケットを備える、
    請求項２５に記載の方法。

Images