ＴＣＰＡＣＫの管理によるＬＡＮにおけるスループット改善
【課題】受け取り確認を管理する方法および装置を提供する。
【解決手段】受け取り確認を管理する方法および装置であって、データ・パケットおよび受け取り確認をある接続と同定し、受け取り確認のどれが消去できるかを判定し、消去できる受け取り確認を単一の受け取り確認で置き換え、該単一の受け取り確認を送信することを含むものが記載される。受け取り確認を管理するための代替的な方法および装置であって、データ・セグメントを受信し、接続を追跡し、所定数のチャネル時間割り当てのための十分なデータ・セグメントがあるかどうかを判定し、前記所定数のチャネル時間割り当てのための十分なデータ・セグメントがある場合に、選択された接続についての受け取り確認を生成することを含むものが記載される。
【解決手段】受け取り確認を管理する方法および装置であって、データ・パケットおよび受け取り確認をある接続と同定し、受け取り確認のどれが消去できるかを判定し、消去できる受け取り確認を単一の受け取り確認で置き換え、該単一の受け取り確認を送信することを含むものが記載される。受け取り確認を管理するための代替的な方法および装置であって、データ・セグメントを受信し、接続を追跡し、所定数のチャネル時間割り当てのための十分なデータ・セグメントがあるかどうかを判定し、前記所定数のチャネル時間割り当てのための十分なデータ・セグメントがある場合に、選択された接続についての受け取り確認を生成することを含むものが記載される。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、無線ビデオ配信（distribution）システムにおける、セットトップボックス（STB）のようなマスター・デバイスからSTBのようなリモート・デバイスへの圧縮されたマルチメディア／ビデオの配信に関する。
【背景技術】
【０００２】
ケーブル・ビデオ・サービスのためには、個別のビデオ番組が典型的にはケーブル上で独自の専用周波数帯において放送される。家庭にあるいかなるテレビも、その周波数に同調することによって、いかなる個別の番組にも同調できる。より新しいテレビ・サービス（たとえば、衛星テレビ配信、インターネット・テレビ配信）の場合、番組は、マスターSTBにおいて「同調〔チューニング〕され」、次いでリモートSTBに家庭ネットワークを通じて配信される。多くの場合、家庭ネットワーク（または家庭配信システム）が設置される必要がある。有線（同軸ケーブル、撚り線対など）は信頼性が高いが、設置が高価になることがあり、家の所有者は設置業者が設置のために壁にドリルで穴を開けるのを好まないことがありうる。それを念頭に、業界では、ビデオ番組の再配信（redistribution）システム問題への無線ソリューションに関心が寄せられている。
【０００３】
たいていの既存の家庭内デジタル・ビデオ配信システムは、配信媒体としてイーサネット（登録商標）を使う。たいていのイーサネット（登録商標）設備は少なくとも1000Mbpsのリンク速度を使用し、トラフィックをアドレス指定されたデバイスを含む分枝にのみ選択的に送信するスイッチを使用するので、制御されたトラフィック速度をもつビデオ再配信システムにおいて使用されるときには、QoS問題はほとんどない。何らかの型のQoS保護なしで同じネットワーク上に一般的なIPデータ・トラフィックを送信したとしたら、イーサネット（登録商標）で問題が生じうる。現在のところ、イーサネット（登録商標）には一つの型の媒体アクセス制御（MAC）レベルQoSが利用可能である。それは優先度に基づく方式であり、仮想ローカル・エリア・ネットワーク（VLAN）タグ内のユーザー優先度フィールドを使用する。パラメータ化されたQoS（帯域幅要求、帯域幅保証、受け容れコントロールなど）の追加が、現在、IEEE802ネットワーク・ブリッジングについてのIEEE802.1サブ委員会内の作業部会の一つの主題である。しかしながら、イーサネット（登録商標）は、運用のために有線を必要とするという欠点があり、新たな配線のない設置技術を有することが望ましい。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
必要とされるのは、MACレベルのブリッジングを通じたイーサネット（登録商標）配信を置き換えることのできる無線配信システムである。多くの家庭ネットワークは、IPプロトコルを使ってビデオを配信しているが、多くの可能性がある。ビデオは、実時間転送プロトコル（RTP: real time transport protocol）によって規定されるUDPを使って送られる場合もあれば、ビデオがTCPを通じて配信される場合もある（たとえば、デジタル・リビング・ネットワーク・アライアンス（DLNA: Digital Living Network Alliance））。UDPは一方向の通信しか要求しない一方、TCPは双方向の通信を要求する。さらなる可能性もある。すでにイーサネット（登録商標）・インターフェースがあるときにはマスターおよびリモート・デバイス／STBにいかなる修正も必要としない（すなわち、帯域幅予約なし、無線ブリッジ・デバイスへのトーキング（talking）なしなど）家庭配信システムを有することが望ましいであろう。また、媒体が無線であり、したがって帯域制限された共通媒体であるので、MAC層がきわめて効率的であることも望ましい。そのため、本発明は、TDMA MAC方式を使う。TDMA MAC方式では、時間割り当てが割り振られて、各クライアント／リモート・デバイス（STB）に専用の帯域幅が与えられる。本稿での「／」の使用は、同じ構成要素についての代替名を表す。ビデオの正確なビットレートおよび他の特性が、マスターSTBにさえ、先験的にはわかっていないこともありうる。たとえビデオの正確なビットレートが先験的にわかっていたとしても、マスターSTBが無線デバイス（リモートSTBおよび／またはマスター・ブリッジング・ノード）と何らかの特別なまたは新たな通信をもつことを要求しないことが望ましい。マルチメディア・トラフィックはたいていマスター・デバイスから若干数のリモート・デバイスへの下りなので、オーバーヘッドをなくす機会がある。マルチメディア・ストリームを配信するのにTCPが使われるときは、上りトラフィックの大半はTCP ACKである。これらのTCP ACKのいくつかをなくすことは、送信されるオーバーヘッドの量を減らし、利用可能なBW〔帯域幅〕のより多くが実際にマルチメディア・ストリーム情報を搬送するために割かれることを許容する。
【０００５】
リモートSTB／デバイスからマスター・デバイス／STBへの戻り経路／上り経路に割り当てられる時間は、ビデオ配信のための下り経路には利用可能でない時間である。ビデオ配信が目標システムの主たる機能なので、TCP ACKによって引き起こされるオーバーヘッドを減らし、TCPスライディング・ウィンドウの負の効果を減らすことが望ましい。
【０００６】
IEEEにおいて現在標準化中であるIEEE802.11Nはビデオ配信のための手段として求められている。IEEE802.11Nの主題である技術に関してはいくつかの懸念がある。第一に、それは相変わらずCSMA（IEEE802.11）に基づいている。この型のMAC層は本来的に非効率的であり、QoS保証を提供しない。多くのMACレベルQoS向上がIEEE802.11Nに追加されているが、CSMAベースのMACがTDMA MACほど効率的になりうるとは考えにくい。QoS向上は、IEEE802.11Eからの優先度ベースのQoS、何らかの形のポーリングならびにMACプロトコル・データ単位（MPDU: MAC protocol data unit）およびMACサービス・データ単位（MSDU: MAC service data unit）の集積（aggregation）の追加を含む。これらの向上は、IEEE802.11ネットワークのリソースを管理することにおいて非常に有用でありうるが、無線家庭ビデオ配信システムのために必要または望ましいQoS保証をするものではない。ポーリングは、本発明を運用する基盤となるTDMA様のサービスを作り出すために使用できるが、ポーリング自身がMAC効率の妨げになる。MAC効率は、無線ネットワークについては、家庭のよりリモートな領域に利用可能な限られたリンク速度のため、より一層重要である。たいていの現行の無線ローカル・エリア・ネットワーク（WLAN: wireless local area network）は、共通伝送媒体（すなわち、同じ伝送周波数での無線スペクトル）を利用する。そのため、MACはその媒体を共有する機構を必要とする。なお、ひとたび送信機会がCSMAを介して獲得されるかポーリングを介して割り振られるかしたら、本発明が適用されうる。
【０００７】
いくつかのサービス・プロバイダーは、同軸ケーブル、電話線および／または電力線に基づく、新たな配線のない（no-new-wire）技術に目を向けている。多くの異なる可能性があり、そのほとんどは何らかの形の優先度またはパラメータ化されたQoSをもつ。これらの解決策に内在する問題は、たとえ同軸ケーブルまたは電話線がすでに家庭内にあったとしても、それでも、それらの線が正しいスポットに結線されていないことがあり、あるいは当該技術が扱うのが難しいトポロジーであることがありうるということである。これらの技術のほとんどはまた、他の家庭と帯域幅を共有していることもあり（たとえば、一つの電力用変圧器に最高4世帯のための電力線がある）、現在のところ信頼性を欠く。パラメータ化されたサービスのためには、STBは各リンクについて予約すべき帯域幅がどれくらいかを知る必要がある。ビデオ家庭配信システムについては、トラフィックは制御下にないことがあり、バースト的であることがあり、少なくとも部分的に未知である。
【０００８】
本発明は、上記で浮き彫りにした問題を解決する家庭マルチメディア・ストリーム配信システムを包含する。
【課題を解決するための手段】
【０００９】
たいていの現行の無線LANは、共通伝送媒体（すなわち、同じ伝送周波数での無線スペクトル）を利用する。そのため、媒体アクセス制御（MAC: media access control）層はその媒体を共有する機構を必要とする。たいていの機構は、キャリア検知多重アクセス（CSMA: carrier sense multiple access）MAC層に基づいている（たとえばIEEE802.11）。この型のMAC層は本来的に非効率的であり、サービス品質（QoS: quality of service）保証を提供しない。MAC効率は、無線ネットワークについては、家庭のよりリモートな領域に利用可能な限られたリンク速度のため、より一層重要である。非常に高い効率およびQoS保証を達成するため、本発明は、時分割多重アクセス（TDMA: time division multiple access）IEEE802.15.3bに基づいたMACを使用する。基本的なTDMA機能については標準的なMACが使用されるが、TCP ACKに起因するネットワーク負荷を減らす機能が追加される。
【００１０】
本発明が設計される対象となる典型的なシステムは、三つまでのクライアント／リモート・デバイスにインターネット・プロトコル（IP）ベースのビデオを配信するマスター・デバイスを含む。前記デバイスは、イーサネット（登録商標）／無線式のMACレベル・ブリッジ・デバイスであり、実際のビデオ同調およびレンダリングはイーサネット（登録商標）・ベースのSTBにおいて行われる。本発明はSTBを使って記載されるが、等価なまたは同様の機能をもついかなるデバイスも、そのデバイスの名前にかかわりなく、本発明によって考えられている。一般に、純粋なMACブリッジは、同じでも異なっていてもよいLANセグメントどうしを接続する。ブリッジによって相互接続された異なるLAN技術の集合はブリッジ・ローカル・エリア・ネットワーク（bridge local area network）として知られている。MACブリッジはMACサービス境界の下で動作し、MACブリッジ・サービス境界の上で使われるプロトコルにとっては、QoSの違いがある可能性を除いては、透明である。
【００１１】
本発明のシステムおよび方法は、三つのリモートSTBへの制約された通信（すなわち、すべての通信がマスターSTBへ／マスターSTBから）をもつ例示的な家庭ビデオ配信システムを使って記載される。本稿で記載される技法は、より一般的な家庭ネットワークに簡単に拡張できる。今日まで、三つの高精細度ビデオ・ストリームを家庭内の三つのリモート位置に配信できる無線家庭配信システムがないことを注意しておくべきであろう。本発明はビデオ・ストリーミングを含む例示的な実施形態を使って記載されるが、用語「ビデオ」はデジタル・オーディオのような他のストリーミング・メディアを含む「マルチメディア・ストリーム」を含むよう拡張できることはすぐ明白であるはずであることも注意しておくべきであろう。
【００１２】
すべてのトラフィックは、マスター・ブリッジング・デバイスへ／マスター・ブリッジング・デバイスからに制約される。マスター・ブリッジング・デバイスは、チャネル時間割り当て（CTAs: channel time allocations）を計画するビーコンを周期的に送信する。CTA内で各デバイスはそのデータを送信する。ビーコンに、次のビーコンまでのすべてのCTAを加えたものが、「スーパーフレーム（superframe）」と呼ばれ、図８に示されている。CTA1、2および3は下りトラフィック（たいていはビデオ）のためであり、CTA4、5および6は上りトラフィック（たいていはTCP受け取り確認（ACK）およびその他の管理／制御フレーム）のためである。マスター・ブリッジ・デバイスは、ビーコン送信に先立ってCTA割り当てを決定する。一般に、CTAは、マスター・デバイス（マスターSTB）によって決定されるか、リモート・デバイス（リモートSTB）によって要求される固定された時間スロットであることができる。すべての利用可能な時間割り当て／スロットをフルに利用することが望ましい。
【００１３】
本発明はまた、ビデオを搬送するプロトコルを含むビデオ・システム・ミドルウェアにいかなる変更も要求しないという利点もある。
【００１４】
上記の応用において、ビデオはTCPを通じて配信される。TCPは、プロトコル・スタックにおいてIPの上に層として重ねられる、接続指向の双方向プロトコルである。TCP ACKはインターネットを通じた伝送のために有用であるが、本発明におけるようなビデオ・ストリーミングにおける使用のための信頼できるLANにおけるその有用性には疑問がある。しかしながら、TCPは、ブリッジング・デバイスにおいてミドルウェアとして利用可能なものであり、既存のミドルウェアを変更するのではなく、増強し、向上させることが望ましい。低い物理層（PHY）パケット誤り率およびMAC層における再送信を通じて、高い信頼性が達成できる。リモートSTBによって返されるTCP ACKによって引き起こされるオーバーヘッドおよびTCPスライディング・ウィンドウに対する負の効果を減らすことも望ましい。
【００１５】
本稿に記載されるのは、TCP ACKによって引き起こされるオーバーヘッドを減らす三つの方法である。最初の二つの方法が組み合わされて第三の方法を形成する。（記述の目的のための）本発明の例示的な実施形態はTDMA MACに基づいているので、リモートSTBからマスターSTBへの送信は、スーパーフレームの長さに依存して5または10msec毎にバルクで起こる。この送信のために、リモートSTBは、その送信待ち行列からパケットを取り出し、送信のための一連のフレーム（または集積されたフレーム［aggregated frames］）に組み立てる。この例示的な実施形態では、このトラフィックのすべては、マスターSTBを宛先とされている。第一の方法については、リモート・ブリッジ・デバイスは、その送信待ち行列内のフレームのIPおよびTCPヘッダを調べ、ACKのどれを消去できるかを決定する。フレームの内容に依存して、いくつかのTCP ACKが一つのTCP ACKで置き換えられる。これは、より短いCTAがリモート・デバイス／STBに割り当てられることを許容し、マスター・デバイス／STBに割り当てられるCTAのためにより多くの時間を、よって下りビデオのために割り当てられるより多くの時間を残す。
【００１６】
第二の方法では、マスターSTBに戻るTCP ACKがマスター・ブリッジ・デバイスによって生成される。この場合、マスターSTBはだまされて、パケットがすでにリモートSTBによって受信されたと思い込まされる。マスター・ブリッジ・デバイスはTCPスライディング・ウィンドウ、TCPシーケンス番号、最大セグメント・サイズ（MSS: maximum segment size）およびそれ自身の送信待ち行列を追跡する。TCPフレームがマスターSTBから頻繁に到着しすぎる場合、マスター・ブリッジ・デバイスは、待ち行列レベルが下がるまでTCP ACKを差し控える。これはフロー制御の一つの形である。マスター・ブリッジ・デバイスはまた、リモートSTBから実際に返されるTCP ACKを途中で捕らえ、それがマスターSTBに転送されないようにする。あるいはまた、TCP ACKはリモート・ブリッジ・デバイスによって途中で捕らえられることもでき、必要ならマスター・ブリッジ・デバイスに要約レポートが送られることもできる。リモート・ブリッジ・デバイスが途中で捕らえられたTCP ACKを破棄することも可能である。この第二の方法は、オーバーヘッドを減らすことに加えて、小さなTCPスライディング・ウィンドウの負の効果を減らすことができるという利点がある。
【００１７】
第三の方法は、上記の二つの方法を組み合わせる。TCP ACKは、第二の方法におけるように、ブリッジ・デバイス（マスターまたはリモート）の一つによってローカルに生成されるが、リモートSTBによって返されるTCP ACKは第一の方法に記載されるように組み合わされる。これらの方法は、MAC、IPおよびTCP層／機能に関わり、ブリッジ／MAC層に存在するので、層横断型（crosslayering）と考えることができる。その恩恵は、STBには何の変更も要求せずに、TCPを通じてストリーミングする負の効果を減らすことである。ブリッジ・デバイスは限られた量のTCP/IP処理を識別し、実行する。一般的なデータ・ネットワーク・トラフィックについて、業界はだいたいのところ、層のすべてを別個かつ独立に保ってきた。MAC層は通例、そのフレームのペイロードにおいて搬送されているデータ・トラフィックの種別を意識しない。たとえば、家庭用イーサネット（登録商標）・スイッチは、TCPやIPについて何の知識ももたず、実際、通例、何のセットアップも必要としない。ブリッジはネットワークに対して透明であり、MAC層において動作する。いかなる配信システムのいかなる従来技術の方法も、MAC／ブリッジ層の関与を通じてTCP ACKを減らそうとしたことはない。
【００１８】
受け取り確認を管理する方法および装置であって、データ・パケットおよび受け取り確認をある接続と同定し、受け取り確認のどれが消去できるかを判定し、消去できる受け取り確認を単一の受け取り確認で置き換え、該単一の受け取り確認を送信することを含むものが記載される。受け取り確認を管理するための代替的な方法および装置であって、データ・セグメントを受信し、接続を追跡し（keep track of）、所定数のチャネル時間割り当てのための十分なデータ・セグメントがあるかどうかを判定し、前記所定数のチャネル時間割り当てのための十分なデータ・セグメントがある場合に、選択された接続についての受け取り確認を生成することを含むものが記載される。上記二つの方法の組み合わせであるさらにもう一つの代替的な方法も記載される。
【００１９】
本発明は、以下の詳細な記述を付属の図面との関連で読むことから最もよく理解される。図面は以下の図を含む。
【図面の簡単な説明】
【００２０】
【図１】本発明の原理に基づく例示的な無線家庭ビデオ配信システムを示す図である。
【図２】MACレベル・ブリッジを示す図である。
【図３】一般的な無線ブリッジを示す図である。
【図４】本発明のある例示的な実施形態における、無線家庭ビデオ配信に好適な、制約された経路をもつ無線ブリッジを示す図である。
【図５】マスターSTBおよび無線MACブリッジのサーバー側のソフトウェアのブロック図（論理構造）を示す図である。
【図６】リモート／クライアントSTBおよび無線MACブリッジのクライアント側のソフトウェアのブロック図（論理構造）を示す図である。
【図７】本発明の原理に基づいてDTAがどのように使用されるかを示す、無線MACブリッジのブロック図である。
【図８】本発明に基づくスーパーフレームを描いた図である。
【図９】ビデオ・サーバー（マスターSTB）に接続されたPNCのための高レベルの送信パケット流れ図である。
【図１０】ビデオ・サーバー（マスターSTB）に接続されたPNCのための高レベルの受信パケット流れ図である。
【図１１】ビデオ・クライアント（リモートSTB）に接続されたDEV-xのための高レベルの送信パケット流れ図である。
【図１２】ビデオ・クライアント（リモートSTB）に接続されたDEV-xのための高レベルの受信パケット流れ図である。
【図１３】単一の下りCTA（PNCからDEV-x）を描いた図である。
【図１４】スーパーMAC（MACフレームの非標準的な集積体）および物理フレーム・フォーマットを描いた図である。
【図１５】単一の上りCTA（DEV-xからPNC）を描いた図である。
【図１６】TCP/IPカプセル化を描いた図である。
【図１７】IPヘッダを描いた図である。
【図１８】TCPヘッダを描いた図である。
【図１９】TCPスライディング・ウィンドウ動作を描いた図である。
【図２０】リモート・ブリッジング・デバイスにおける処理の例示的な実施形態の高レベルのフローチャートである。
【図２１】マスター・ブリッジング・デバイスにおける処理の第二の例示的な実施形態の高レベルの送信フローチャートである。
【図２２】マスター・ブリッジング・デバイスにおけるリモート受け取り確認（ACK: acknowledgement）転送の高レベルのフローチャートである。
【図２３】リモート・ブリッジング・デバイスにおける前記第二の実施形態の高レベルのフローチャートである。
【発明を実施するための形態】
【００２１】
本発明は、TDMAサービスをサポートするIEEE802.15.3b MACを出発点とする（スーパーフレームの先頭におけるビーコンおよびスーパーフレーム内の諸伝送時間割り当て）。IEEE802.15bは、パーソナル・ネットワークとなるべく設計されたものであり、したがって、LANや都市圏ネットワーク（MAN）のために設計された技術よりも「軽い」。他のTDMA MACもあり、使うことができる（たとえばIEEE802.16）が、従来技術においては、純粋にMAC層にとって利用可能なトラフィック特性に基づいて動的にCTA長さを割り当てる試みはされていない。IEEE802.16は無線都市圏ネットワーク（WMAN: wireless metropolitan area network）のために設計されたものであり、サービス加入者へのインターネット配信のために使用される。IEEE802.16はサービス・プロバイダーが自らのネットワークをカスタマイズすることを許容する多くの機能およびオプションを含んでいる。本発明の例示的な実施形態はIEEE802.15.3bに関して記載されるが、その概念はIEEE802.16の実施形態にも等しく適用できる。パースするヘッダが若干多くなる。
【００２２】
CTAを設定するときに考慮されなければならないTCPのいくつかの特徴がある。TCPは、32ビットのシーケンス番号および要求番号ならびに16ビットのスライディング・ウィンドウ長さフィールドを利用する転送プロトコルである。これら三つの数は、「停止して待機（Stop-and-Wait）」または「N個戻る（Go-Back-N）」ARQ〔自動再送要求〕エラー修復方式を実装するために使われる。送信待ち行列内および送信される過程にあるTCPパケットは「ネットワーク内にある」ので、TCPウィンドウは、それらのパケットが未決（outstanding）であることを許容するために宛先によって十分大きく設定されなければならない。一般に、MACレベルのブリッジング・デバイスはそのウィンドウのサイズを設定することに対して制御をもたないが、CTAおよびスーパーフレーム長さの初期選択は、問題を最小化するのに十分短く選ぶことができる。スーパーフレームの長さは、変化するTCPウィンドウ・サイズを扱えるよう、調節可能（または適応可能）にされてもよい。
【００２３】
10msecのスーパーフレームについては、約19個の1400バイトTCPパケットが10msec毎に送信される。これで26,600バイトになる。例示的な実施形態の以下の記述の目的のために、約165キロバイトの送信バッファ待ち行列を選んだ。TCPウィンドウ・サイズは64キロバイトを超える未決データを許容しないので、TCPトラフィックについては送信バッファ待ち行列は決してオーバーフローしない。ウィンドウが、CTAが完全に満たされることすら許容しないほど十分小さいことさえありうる。このため、短いスーパーフレーム（5msec）で始めるほうがよい。すると、送信バッファ待ち行列は、少なくとも単一のTCPセッションを扱うことができるためには、51キロバイトより大きい必要はない。しかしながら、UDPを通じて送られるビデオの場合に紛失パケットを回避するため、165キロバイトの送信バッファ待ち行列を選んだ。
【００２４】
ARQエラー修復方式の数学的モデルは待ち行列理論の分野内で開発され、必要ならTCPパフォーマンスをより精密にモデル化するために使用できることを注意しておく。ウィンドウ・サイズは、他のものがCTA内にある間、いくつかに対する十分な未決TCPパケットが待ち行列内にあることを許容するために十分大きいと想定される。5回までの再送信が許される例示的な実施形態では、CTAは、そのデータの約5倍が送信バッファ待ち行列内に逗留することができるほど十分小さいべきである。5msecのスーパーフレームは、最大サイズのTCPウィンドウが使用されたら、これを達成するであろう。
【００２５】
初期アプリケーションはTCPを使ってビデオをストリーミングすることになる一方、一般的な意味における良好なパフォーマンスを保証する唯一の方法がトラフィック・パターンに適応することを許容することであるよう、実装の十分な不確定さがある。
【００２６】
リアルタイムの、長さが柔軟なスーパーフレーム構築が可能である。これは、システムの堅牢性を増し、システム・パフォーマンスを改善すると考えられる。スーパーフレームの長さは、例示的な実施形態において三つの個別ビデオ待ち行列の長さ、下り伝送チャネル条件および他の任意の可能な点に依存しうる。長さが柔軟なスーパーフレームの場合、ビーコンは、後続のCTAの長さをブロードキャストしなければならず、各リモートSTBは該リモートSTBに専用のCTAの長さについて通知される。
【００２７】
上記したように、TCP受信ウィンドウがCTAの長さに対して十分小さいと、サーバーは前のパケットからのACKを受信するまで次のパケットを放出せず、ソースにおけるストリームを事実上遅くすることがありうる。そのレートは、所望されるリアルタイムのストリーミング・レートを下回ることもありうる。これを避けるため、本発明は、この飢餓条件につながらないCTAサイズを選択する。適正なレートを維持するために、CTAは、サイズを小さくされれば、より頻繁に生起する必要がある。これは、スーパーフレームのサイズを小さくすることによって、あるいはスーパーフレーム当たりそのリンクに二つ以上のCTAを割り当てることによって起こる。
【００２８】
さらに上記したように、TCPウィンドウ・サイズについての不確定さは、スーパーフレーム長さが変化する可能性につながる。これは、MAC層では、TCPヘッダを見ることに基づいてスーパーフレーム変化をトリガーすることによって、あるいはより適正には、送信バッファ待ち行列をモニタリングして送信バッファ待ち行列があまりにしばしば空になってCTAが送信すべきデータが足りない状態になる場合にはスーパーフレームを短くすることによってできる。例示的な実施形態では、初期には、固定されたスーパーフレーム長さが使用された。固定されたスーパーフレーム長さが与えられて、トラフィック特性に適応するためにCTA長さを修正することが調査される。その場合、たいていTCP ACKのために意図されたCTAにどのくらいの時間を割り当てるべきかのいくらかの不確定性がある。というのも、STB中のTCPスタックは複数のACKをグループ化することがあり、および／またはデータを含むパケットのヘッダにACKを含むことがあるからである。
【００２９】
最低限、どんな所与の送信待ち行列の平均出力パケット・レートも、平均パケット到着レートより下に保たれねばならないことはわかっている。そうでなければ、待ち行列はオーバーフローする。しかしながら、たとえ平均到着レートが平均出発レートより低くても、入力ストリームの統計的性質のため、入力レートが一時的に出力レートを超えることはありうる。平均出力レートを平均入力レートより高く保つことは、必要ではあるが、十分ではない。IPトラフィックの特定性の欠如のため、システムを適応的にすることが最善である。
【００３０】
適応を許容するために、全スーパーフレームについての待ち行列情報が記録される。待ち行列情報は、待ち行列のサイズ（固定なら送る必要はない）、待ち行列中のパケット数、待ち行列中のパケットの平均長さおよび入力パケット・レートの推定値を含む。この情報が、各DEVまたはリモートSTBへの信頼性のあるリンク速度についての情報とともに、適応アルゴリズムへの入力として使われる。適応アルゴリズムの目標は、パケットを落とさないこと、そしてその目標に達するような仕方でスーパーフレーム時間をCTAに分配することである。適応アルゴリズムは、各待ち行列中の期待されるパケット数を最小化しようと（よって遅延を最小にしようと）、および／または待ち行列がオーバーフローする確率を最小にしようと努める。待ち行列レベルをモニタリングすることによって、MACはスーパーフレームごとに、最も満たされている待ち行列に送信優先を与えるよう、CTAを調節しうる。
【００３１】
本発明は、圧縮されたビデオをマスターSTBからリモートSTBに配信する無線ビデオ・サービス配信システムのMAC層およびブリッジング層に関する。本システムはIEEE802.15.3b TDMA MACを部分的に利用し、したがってその規格からの用語をいくらか使う。その技術をSTBに組み込んだ例示的なシステムを図１に示す。
【００３２】
マスターSTB１０５は、高度テレビ方式委員会（ATSC: Advanced Television Systems Committee）アンテナ（デジタル・テレビ）、衛星アンテナおよび広域ネットワーク（WAN）モデムを含む多様なビデオ・ソースから入力を受信する。マスターSTBは、顧客スイッチに接続された、コンポジット全米テレビ方式委員会（NTSC: National Television Standards Committee）ビデオ・ディスプレイ、高精細度マルチメディア・インターフェース（HDMI: High Definition Multi-media Interface）コンポーネント・ビデオ・ディスプレイおよびローカル・エリア・ネットワーク（LAN）を含むビデオ・ディスプレイ１１０（たとえばテレビ）に出力を提供する。マスターSTBは5つの衛星チューナーを有する（電子番組ガイド（EPG: electronic program guide）チューナー、メイン・チューナー、三つのリモート・チューナーおよびレコーディング・チューナー）。メイン・チューナーは、マスターSTBと通信しているディスプレイのユーザーが望む番組に同調するためのものである。三つのリモート・チューナーは、リモート・ディスプレイの各ユーザーが望む番組に同調するためのものである。EPGチューナーは、電子番組ガイドに同調するためのものである。レコーディング・チューナーは、マスターSTBと通信しているディスプレイのユーザーが、メイン衛星チューナーによって同調されている番組を視聴している間に記録したい番組に同調するためのものである。マスターSTBは二つのATSCチューナーを有する―メイン・チューナーおよびレコーディング・チューナーである。メイン・チューナーは、マスターSTBと通信しているディスプレイのユーザーが望む番組に同調するためのものである。レコーディング・チューナーは、マスターSTBと通信しているディスプレイのユーザーが、メインATSCチューナーによって同調されている番組を視聴している間に記録したい番組に同調するためのものである。マスターSTBは、デマルチプレクサ（多重分離器）、パーソナル・ビデオ・レコーダ（PVR）、リモコン装置とともに使用するための赤外（IR）受信器、衛星／ATSCデコーダおよび無線ハブをも有する。マスターSTB１０５は各リモートSTBに約20Mbpsでビデオを送信できる。マスターSTB１０５は衛星ベンダーのIPトラフィックを各リモートSTBと交換できる。マスターSTB１０５は、各リモートSTBと制御情報を交換できる。
【００３３】
マスターSTBは三つのリモートSTB（リモートSTB1 １１５、リモートSTB2 １２５およびリモートSTB3 １３５）と通信状態にある。リモートSTB1 １１５はビデオ・ディスプレイ１２０と通信状態にある。リモートSTB2 １２５はビデオ・ディスプレイ１３０と通信状態にある。リモートSTB3はビデオ・ディスプレイ１４０と通信状態にある。各リモートSTBの構成は同様なので、リモートSTB1についてのみ述べる。リモートSTB1 １１５は衛星／ATSCデコーダ、リモコン装置とともに使うためのIR受信器および無線ステーションを有する。リモートSTB1 １１５は、マスターSTB１０５から約20Mbpsでビデオを受信できる。リモートSTB1は、自分自身とマスターSTB1 １０５との間で衛星ベンダーのIPトラフィックを交換できる。リモートSTB1 １１５は、マスターSTB１０５と制御情報を交換できる。
【００３４】
本発明は、MACレベルの無線ブリッジとして構築される（図２参照）。一般に、MACブリッジは、同じでも異なっていてもよいLANセグメントどうしを接続する。ブリッジによって相互接続された異なるLAN技術の集まりはブリッジ・ローカル・エリア・ネットワークとして知られる。MACブリッジはMACサービス境界の下で動作し、MACブリッジ・サービス境界の上で使われるプロトコルにとっては、QoSの違いがある可能性を除いては、透明である。MACサービス・ユーザーはMACサービス境界（MAC services boundary）の上にあり、MACサービス・プロバイダーはMACサービス境界の下にある。MAC層ブリッジは、各LANセグメント／コンポーネントとのインターフェースをもつためにリレーを含む。
【００３５】
一般的な無線ブリッジが図３に示されている。無線ブリッジ３０５はイーサネット（登録商標）（Ethernet（登録商標））接続を介してサーバーと通信する。二つのサーバー３１０、３１５が示されている。無線ブリッジ３０５は、クライアントともイーサネット（登録商標）接続を介して通信する。四つのクライアント３２０、３２５、３３０、３３５が示されている。この一般的な無線ブリッジ内にはDEV0がある。これはピコネット・コントローラ（PNC: piconet controller）３４０である。PNC３４０は複数のデバイスと無線で通信する。三つのデバイスDEV1 ３４５、DEV2 ３５０およびDEV3 ３５５が示されている。DEV0/PNC ３４０はサーバー３１０、３１５と通信する。DEV1 ３４５はクライアント３２０と通信する。DEV2 ３５０はクライアント３２５と通信する。DEV3 ３５５はクライアント３３０、３３５と通信する。
【００３６】
しかしながら、本発明の例示的な実施形態は、無線家庭ビデオ・サービス配信用途に適する経路を制約している。可能なデータ経路は図４で破線で示されている。無線ブリッジ４０５はマスターSTB４１０と無線で通信する。無線ブリッジ４０５はリモートSTB４１５、４２０、４２５とも無線で通信する。無線ブリッジ４０５は内部的には図２に示されるような構成である。すべてのトラフィックはマスターSTB４１０に行く、またはマスターSTB４１０からくる。
【００３７】
図５はサーバー側（マスターSTBおよびブリッジ・デバイス）のソフトウェア・アーキテクチャを示す。マスター・ブリッジ・デバイスはIEEE802.15.3に記載されるようなピコネット・コントローラ（PNC）でもあることを注意しておく。マスターSTB５０５はマスターSTB５０５内のミドルウェア・ビデオ・サーバー・アプリケーション５１０を有する。マルチメディア・ストリーム・ミドルウェア５１５は媒体QoS制御５２０およびデバイス・ドライバ５２５の両方とインターフェースをもつ。マルチメディア・ストリーム・ミドルウェア５１５はビデオ・データをデバイス・ドライバ５２５に転送し、媒体QoS制御ミドルウェア５２０と制御情報を交換する。媒体QoS制御ミドルウェアはデバイス・ドライバ５２５と制御情報を交換する。デバイス・ドライバ５２５は主としてビデオ・データをネットワーク・インターフェース（IEEE802.3）５３０と交換する。デバイス・ドライバ５２５内には、媒体ストリーム・ミドルウェア５１５からビデオ・データおよび制御情報を受信して媒体QoS制御ミドルウェア５２０と情報を交換するポータブル・オペレーティング・システム・ユニックス（POSIX: portable operating system Unix（登録商標））ドライバ５３５のサブセットがある。POSIXドライバのサブセットは、TCP/IP５４０および媒体ストリーム・プロトコル５４５およびQoS管理および制御５５０とのスタックにあるQoSミドルウェアと情報を交換する。PNC５５５は、無線MACビデオ・サーバー・ブリッジ・アプリケーション５６０を有し、この無線MACビデオ・サーバー・ブリッジ・アプリケーション５６０は、複数のソフトウェア・モジュールを含むソフトウェア５６５と制御情報を交換する。ソフトウェア５６５は無線電波インターフェース５７０およびIEEE802.3ドライバ５７５とビデオ・データおよび制御情報を交換する。IEEE802.3ドライバは主としてIEEE802.3ネットワーク・インターフェース５８０とビデオ・データを交換する。IEEE802.3ネットワーク・インターフェース５８０はIEEE802.3ネットワーク・インターフェース５３０とインターフェースをもち、そのビデオ情報を交換する。ソフトウェア５６５はIEEE802.1Dブリッジング・モジュールを含むいくつかのソフトウェア・コンポーネントを含み、このIEEE802.1Dブリッジング・モジュールは、無線デバイス管理エンティティ（DME: device management entity）およびIEEE802.2フレーム収束サブ層（FCSL: frame convergence sublayer）サービス・アクセス・ポイント（SAP: service access point）上に層として重ねられる。無線MACビデオ・サーバー・ブリッジ・アプリケーション５６０は無線DME管理SAPとインターフェースをもつ。無線DME管理SAPおよび無線DMEおよびIEEE802.2 FCSL SAPはいずれもIEEE802.2 FCSL DMEの上に層として重ねられる。IEEE802.2FCSL DMEはIEEE802.15.3b PNCの機能を実行し、QoSスケジューリングを行い、ブリッジ機能性を管理する。IEEE802.2 FCSL DMEはIEEE802.15.3b MAC SAPおよびIEEE802.15.3b MAC層管理エンティティ（MLME: MAC layer management entity） SAPの上に層として重ねられる。IEEE802.15.3b MAC層管理エンティティ（MLME）SAPはIEEE802.15.3b MLME上に層として重ねられ、このIEEE802.15.3b MLMEは物理層管理エンティティ（PLME: physical layer management entity）の上に層として重ねられる。IEEE802.15.3b MAC SAPはIEEE802.15.3b MACサブ層の上に層として重ねられ、このIEEE802.15.3b MACサブ層は無線物理SAPの上に層として重ねられる。IEEE802.15.3b MAC SAPは無線物理層の上に層として重ねられる。無線物理層管理エンティティ（PLME）SAPは無線物理層PLMEの上に層として重ねられる。無線PLMEは無線物理層と通信する。IEEE802.15.3b MACサブ層はIEEE802.15.3b MLMEと通信する。無線物理層および無線PLMEはビデオ・データおよび制御情報をそれぞれ無線電波インターフェースと交換する。
【００３８】
図６は、クライアント側（リモートSTBおよびブリッジ・デバイス）のSW〔ソフトウェア〕アーキテクチャを示す。本発明はブリッジ・デバイス内にあるが、コンテキストのためにSTBが示されていることを注意しておく。リモート／クライアント・ブリッジ・デバイスもIEEE802.15.3に記載されるようなDEV-x（非PNCデバイス）であることを注意しておく。リモート／クライアントSTB６０５はリモート／クライアントSTB６０５内のミドルウェア・ビデオ・クライアント・アプリケーション６１０を有する。メディア・ストリーム・ミドルウェア６１５は媒体QoS制御６２０およびデバイス・ドライバ６２５の両方とインターフェースをもつ。メディア・ストリーム・ミドルウェア６１５はビデオ・データをデバイス・ドライバ６２５に受け容れ、媒体QoS制御ミドルウェア６２０と制御情報を交換する。媒体QoS制御ミドルウェアはデバイス・ドライバと制御情報を交換する。デバイス・ドライバ６２５はたいていビデオ・データをネットワーク・インターフェース（IEEE802.3）６３０と交換する。デバイス・ドライバ６２５内には、媒体ストリーム・ミドルウェア６１５に主としてビデオ・データを送って媒体QoS制御ミドルウェア６２０と情報を交換するPOSIXドライバ６３５のサブセットがある。POSIXドライバのサブセットは、TCP/IP６４０および媒体ストリーム・プロトコル５４５およびQoS管理および制御６５０とのスタックにあるQoSミドルウェアと情報を交換する。Dev-x６５５は、無線MACビデオ・クライアント・ブリッジ・アプリケーション６６０を有し、この無線MACビデオ・クライアント・ブリッジ・アプリケーション６６０は、複数のソフトウェア・モジュールを含むソフトウェア６６５とビデオ・データおよび制御情報を交換する。ソフトウェア６６５は無線電波インターフェース６７０およびIEEE802.3ドライバ６７５とビデオ・データおよび制御情報を交換する。IEEE802.3ドライバは主としてIEEE802.3ネットワーク・インターフェース６８０とビデオ・データを交換する。IEEE802.3ネットワーク・インターフェース６８０はIEEE802.3ネットワーク・インターフェース６３０とインターフェースをもち、そのビデオ・データを交換する。ソフトウェア６６５はIEEE802.1Dブリッジング・モジュールを含むいくつかのソフトウェア・コンポーネントを含み、このIEEE802.1Dブリッジング・モジュールはDMEおよびIEEE802.2 FCSL SAP上に層として重ねられる。無線MACビデオ・クライアント・ブリッジ・アプリケーション６６０は無線DME管理SAPとインターフェースをもつ。無線DME管理SAPおよび無線DMEおよびIEEE802.2 FCSL SAPはいずれもIEEE802.2 FCSL DMEの上に層として重ねられ、このIEEE802.2 FCSL DMEはIEEE802.15.3b DEV-xの機能を実行し、QoSスケジューリングのために状態をPNCに送り、ブリッジ機能性を管理する。IEEE802.2 FCSL DMEはIEEE802.15.3b MAC SAPおよびIEEE802.15.3b MLME SAPの上に層として重ねられる。IEEE802.15.3b MLME SAPはIEEE802.15.3b MLME上に層として重ねられ、このIEEE802.15.3b MLMEは物理層管理エンティティ（PLME）の上に層として重ねられる。IEEE802.15.3b MAC SAPはIEEE802.15.3b MACサブ層の上に層として重ねられ、このIEEE802.15.3b MACサブ層は無線物理SAPの上に層として重ねられる。IEEE802.15.3b MAC SAPは無線物理層の上に層として重ねられる。無線PLME SAPは無線物理層PLMEの上に層として重ねられる。無線PLMEは無線物理層と通信する。IEEE802.15.3b MACサブ層はIEEE802.15.3b MLMEと通信する。無線物理層および無線PLMEはビデオ・データおよび制御情報を無線電波インターフェースと交換する。ソフトウェア６６５および６６０が、CTAについての情報をもつビーコン信号を受信し、それらの下りCTA内の再配信されたビデオ／メディアを受信し、適切な上りCTAにおいてMACレベルのACKまたはNAKを送信する。これらのACKは、TCPが使われるときにビデオ・クライアントにおいて生成されうるTCP ACKとは異なることを注意しておく。
【００３９】
ここで図７を参照する。図７は、本発明の原理に基づく無線MACブリッジのブロック図である。PNC７０５は、割り当てられたCTAにおいてリモートSTB７１０、７１５、７２０へデータ／情報を送信し、リモートSTB７１０、７１５、７２０からデータ／情報を受信する。マスター・デバイス７０５は、チャネル時間割り当て（CTA）を取り決めるビーコンを周期的に送信する。CTA内で各デバイスはそのデータを送信する。CTA１、２および３は下りトラフィック（たいていはビデオ）のためである。CTA４、５および６は上りトラフィック（たいていはTCP ACKおよび他の管理フレーム）のためである。
【００４０】
図８にスーパーフレームが示されている。マスター・デバイスはビーコン送信に先立って諸CTAを決定する。一般に、CTAは、マスター・デバイス／PNCによって決定されるかリモート・デバイス／STBによって要求される固定した時間スロットであることができる。具体的には、IEEE802.15.3bについては、規格が、リモートSTB／デバイスが「CTReq」メッセージをPNCに送ることによって帯域幅を要求する（request）ことを規定している。しかしながら、どんなCTA時間が要求または設定されても、デバイスのいずれも真にIPトラフィック特性の全てを先験的に知ることはない。トラフィックは、UDP（ACK返信なし）に基づくことができ、あるいはTCPに基づくこともできる。時によっては、トラフィックのすべてが下りであることができ（非対称）、いくらか対称的であるときもある。トラフィックの流れを最適にするよう諸CTA内の時間の量を適応させることによって、すべての利用可能な時間をフルに利用することが望ましい。スーパーフレームの左端の部分が最初に空中に送信され、スーパーフレームの右端の部分が最後に空中に送信される。ビーコンに続いて、CTAが送信されるが、下りCTAが先に送信され、その後上りCTAが送信される順序となる。本発明のコンテキストにおけるスーパーフレームは、5msecから10msecまでの間で変わりうる。
【００４１】
マスターSTBに接続されているPNCについての例示的なパケット流れ図が図９および図１０に示されている。リモートSTBに接続されているDEV-x（すなわち非PNCデバイス）についての例示的なパケット流れ図が図１１および図１２に示されている。上記したように、例示的な高精細度ビデオ配信システムの無線MACブリッジは制約されたブリッジとして作用する。
【００４２】
ここで図９を参照すると、PNCはイーサネット（登録商標）・ビデオ・データ・フレームをイーサネット（登録商標）・ポート９０５で受信する（たいていはビデオ）。PNCはスーパーフレームおよび各CTAの長さを決定する。PNCは、宛先MACアドレスに依存してフレームを適正な送信待ち行列９１０ａ、９１０ｂ、９１０ｃに入れる。PNCは、IEEE802.1Dに記載されるようにあふれ（flooding）を通じてMACアドレスを学習することができ、あるいはフィルタリング／ルーティング・テーブルが手動で埋められることができる。図の乱雑を減らす目的で、本発明は（各DEV-x／リモートSTB用に定められた）送信ポート当たり一つの待ち行列しかないと想定して記述される。すなわち、各優先度グループ（priority group）について一つの待ち行列である。イーサネット（登録商標）・ビデオ・データ・フレームは待ち行列に分けられる。例示的な実施形態では、待ち行列はそれぞれ165キロバイトであり、スーパーフレームは5msecから10msecまでの長さである。待ち行列からのビデオ・データ・フレームはソフトウェア・モジュール９１５に転送され、ソフトウェア・モジュール９１５がイーサネット（登録商標）・ビデオ・データ・フレームを、優先度マッピング、フレーム検査シーケンス（FCS: frame check sequence）、フラグメンテーションおよびヘッダ訂正コード（HCC: header correction code）計算を含むIEEE802.15.3b MACフレームへの変換を行う。ソフトウェア・モジュール９１５は、受信したイーサネット（登録商標）・ビデオ・データ・フレームを処理するための転送テーブル（forwarding tables）およびサービス・フロー（service flows）をデータ記憶ユニット９２０から受信する。ソフトウェア・モジュール９１５は、送信MACサービス・データ単位（MSDU: transmit MAC service data unit）を記憶するバッファ９２５と通信する。ソフトウェア・モジュール９３０は、スーパーフレームを構築するために、MACフレームをソフトウェア・モジュール９１５から要求する。ソフトウェア・モジュール９１５は複数のMSDUをソフトウェア・モジュール９３０に転送する。ソフトウェア・モジュール９３０は、スーパーフレームを構築するために、データ記憶ユニット９３５から物理的な特性およびパラメータを、バッファ９４０から直前のサービス・フレームからのMSDU受け取り確認（ACK）を受信する。データ記憶ユニット９４５は、CTA長が変えられるようローカルおよびリモートのDEV（STB）待ち行列長さとして記憶されているMAC帯域幅管理コマンドを、直前のスーパーフレームから受信する。この情報はMAC帯域幅管理エンティティ９５０に転送され、このMAC帯域幅管理エンティティ９５０は、スーパーフレームの構築をさらに支援するため、CTA長をソフトウェア・モジュール９３０に転送する。ソフトウェア・モジュール９３０は、直前のフレームから再送信されるべきMSDUをも、スーパーフレーム再送信バッファ９５５から受信する。このスーパーフレーム再送信バッファ９５５は、各リモートSTB MACプロトコル・データ単位（MPDU）において複数のMSDUを記憶しており、受け取り確認がされたMSDUを破棄する。ソフトウェア・モジュール９３０によって構築されたスーパーフレームはスーパーフレーム構築バッファ９６０に記憶される。ソフトウェア・モジュール９３０によって構築されたスーパーフレームは下りMPDUおよび上り時間を含む。スーパーフレーム構築バッファ９６０は構築されたスーパーフレームを、各リモートSTB MPDU内の複数MSDUの形で、スーパーフレーム送信バッファ９６５に転送する。スーパーフレーム送信バッファ９６５はスーパーフレーム構築バッファから受信したスーパーフレームを、スーパーフレーム再送信バッファ９５５に転送する。スーパーフレーム送信バッファ９６５は完全なMPDUをソフトウェア・モジュール９７０に転送する。ソフトウェア・モジュールは、遅延されたACKを受信期間の間にリモートSTBから受信し、時間クロック９７５からタイミング情報を受信する。ソフトウェア・モジュール９７０は複数のMSDUを各MPDUにまとめ、それらを送信のために物理層モジュール９８０に転送する。ソフトウェア・モジュール９７０は、ビーコン内のタイミングに基づくタイミングを使い、送信データ、送信データ・レート、送信長、送信電力レベルおよび送信アンテナ制御を物理層モジュール９８０に転送し、この物理層モジュール９８０が物理データ・プロトコル単位（PPDU: physical data protocol unit）をPNCから指定されたリモートSTBに送信する。
【００４３】
図１０は受信パケットの流れを描いているので、記述は図の右側から始まって進行する。PPDUが物理層ソフトウェア・モジュール１００５で受信される。この物理層ソフトウェア・モジュール１００５は時間クロック１０１０からも入力を受信する。物理層ソフトウェア・モジュールは受信したデータ、長さ、リンク品質指標（LQI: link quality indicator）、受信信号強度指標（RSSI: received signal strength indicator）およびPHY受信エラーをソフトウェア・モジュール１０１５に転送する。ソフトウェア・モジュール１０１５は、タイミング・ビーコンに基づくタイミングを使って、PPDUを、MSDUを集積したものであるMPDUに分解し、MPDUをソフトウェア・モジュール１０２０に転送する。ソフトウェア・モジュール１０２０はHCC計算を実行し、完全なMSDUフレームまたはフラグメントを単離し、フレーム検査シーケンスを処理し、正しく受信されたMSDUを追跡し、遅延されたACK要求に応答して遅延されたACKを構築し、MSDUをフィルタ処理し、それにより、サーバーのために意図された正しいMSDUのみがサーバー（マスターSTB）に渡されるようにする。ソフトウェア・モジュール１０２０は受信されたMSDUについての遅延されたACKを転送し、サーバー（マスターSTB）のために意図されていないMSDUを破棄する。ソフトウェア・モジュール１０２０は、上記の機能を実行するために、物理的特性およびパラメータをデータ記憶ユニット１０２５から受信する。ソフトウェア・モジュール１０２０は、遅延されたACKおよび帯域幅管理メッセージのようなMACコマンドを、ソフトウェア・モジュール１０３０に転送する。このソフトウェア・モジュール１０３０は、MACコマンドを分離し、MSDU ACKをMSDU ACKバッファ１０３５に転送し、MAC帯域幅情報要素（IE: information element）をMAC帯域幅管理エンティティ１０４０に転送する。ソフトウェア・モジュール１０２０は、MSDU（たいていはTCP ACK）をソフトウェア・モジュール１０４５に転送しもする。このソフトウェア・モジュール１０４５が、フラグメントから完成されたMSDUを再構築し、不完全なMSDUのフラグメントを記憶し、MSDUのフラグメントを適正な順序にする。ソフトウェア・モジュール１０４５は並べ替えフレーム構築バッファ１０５０および受信MSDUフラグメント・バッファ１０５５と通信する。ソフトウェア・モジュール１０４５は完全なMSDUをソフトウェア・モジュール１０６０に転送し、そこで、完全なMSDUは、フレーム検査シーケンスおよび優先度マッピングを含むイーサネット（登録商標）・フレームに変換される。ソフトウェア・モジュールは転送テーブルおよびサービス・フロー情報をデータ記憶ユニット１０６５から受信し、イーサネット（登録商標）・フレームをサーバー（マスターSTB）に転送する。
【００４４】
図１１は、リモートSTB（ビデオ・クライアント）に接続されているDEV-xについての高レベルの送信パケット流である。イーサネット（登録商標）・フレームは、ソフトウェア・モジュール１１０５によって受信される。このソフトウェア・モジュール１１０５はビデオ・クライアントからのはいってくるフレームをフィルタ処理し、分類する。ソフトウェア・モジュール１１０５は、イーサネット（登録商標）・フレームをフレーム待ち行列１１１０に転送する。すべてのトラフィックはサーバー（マスターSTB）に行くはずなので、一つの待ち行列しかない。しかしながら、複数の優先度が望まれる場合には、複数の待ち行列が実装される――各優先度グループ（priority group）について一つの待ち行列である。待ち行列内のデータはソフトウェア・モジュール１１１５に転送される。このソフトウェア・モジュール１１１５はイーサネット（登録商標）・フレームを、優先度マッピング、フレーム検査シーケンス、フラグメンテーションおよびHCC計算を含むIEEE802.15.3 MACフレームに変換する。ソフトウェア・モジュール１１１５は転送テーブルおよびサービス・フロー情報をデータ記憶ユニット１１２０から受信する。ソフトウェア・モジュール１１１５は送信MSDU送信バッファ１１２５とも通信する。ソフトウェア・モジュールは複数のMSDUをソフトウェア・モジュール１１３０に転送する。このソフトウェア・モジュール１１３０は次のスーパーフレーム内での送信のために、上りMPDUを構築する。ソフトウェア・モジュール１１１５はまた、ソフトウェア・モジュール１１３０からの要求も受信する。ソフトウェア・モジュール１１３０は直前のスーパーフレームからのMSDU ACKをバッファ１１３５から受信する。ソフトウェア・モジュール１１３０は、物理的特性およびパラメータをデータ記憶ユニット１１４０から受信し、CTA情報をデータ記憶ユニット１１４５からのビーコンから受信する。ソフトウェア・モジュール１１３０はMAC帯域幅管理コマンドをソフトウェア・モジュール１１５０から受信し、このソフトウェア・モジュール１１５０は、データ記憶ユニット１１５５から受信されたローカルな待ち行列長さ情報およびデータ記憶ユニット１１６０からの直前のスーパーフレームからのMAC帯域幅要求応答（待ち行列情報を交換するために非標準的な仕方で使用されるIEEE802.15.3 MACコマンド）を使って、帯域幅管理メッセージを構築する。ソフトウェア・モジュール１１３０は、直前のスーパーフレームからの再送信されるべきMSDUをスーパーフレーム再送信バッファ１１６５から受信する。各MPDUには複数のMSDUがある。スーパーフレーム再送信バッファ１１６５は、受け取り確認されたMSDUの破棄もする。ソフトウェア・モジュール１１３０は構築バッファ１１７０と通信する。この構築バッファ１１７０は次のスーパーフレームのための上りMPDUのためのバッファである。構築バッファ１１７０は上りMPDUをスーパーフレーム送信バッファ１１７５に転送する。このスーパーフレーム送信バッファ１１７５は上りMPDUをソフトウェア・モジュール１１８０に転送する。スーパーフレーム送信バッファ１１７５は上りMPDUをスーパーフレーム再送信バッファ１１６５にも転送する。ソフトウェア・モジュール１１８０は、ビーコンに基づくタイミングを使って、複数のMSDUを各MPDUにまとめ、MPDUを送信のために物理層ソフトウェア・モジュール１１８５に渡す。ソフトウェア・モジュールは時間クロック１１９０から時間を受信し、サーバー（マスターSTB）から受信期間の間に遅延されたACKを受信する。ソフトウェア・モジュール１１８０は送信データ、送信データ・レート、送信長さ、送信電力レベルおよび送信アンテナ制御を物理層ソフトウェア・モジュール１１８５に転送する。
【００４５】
リモートDEVにおける受信プロセスの近似が図１２に示されている。受信プロセスは、主として、スーパーフレームの分解と、次いでフラグメント化したフレームを再び集めることを含むイーサネット（登録商標）・フレームの再構築からなる。受信側もエラーがないかどうか検査し、PNCへの返送のためにDLY ACK（バルクACKの一つの型）を用意する。DLY ACKは、そのパケットが到着したCTAの反対方向を向いて、CTAの最初において送られる。これは、規格からのもう一つの逸脱である。
【００４６】
図１２は、ビデオ・クライアント（リモートSTB）に接続されたDEV-xについての高レベルの受信パケットの流れ図である。よって、記述は図の右側から始まって進行する。ソフトウェア・モジュール１２０５はPPDUを受信し、受信されたデータ、受信されたエラー、長さ、LQIおよびRSSIをソフトウェア・モジュール１２１５に転送する。ソフトウェア・モジュール１２０５は受信アンテナ制御情報をソフトウェア・モジュール１２１５から受信し、タイミング情報を時間クロック１２１０から受信する。ソフトウェア・モジュール１２１５はMPDUを物理層ソフトウェア・モジュール１２０５から受信する。複数のMSDUが各MPDUにまとめられる。ソフトウェア・モジュール１２１５は時間クロック１２１０からタイミングを受信する。ソフトウェア・モジュール１２１５は、MPDUの諸片をソフトウェア・モジュール１２２０に転送する。このソフトウェア・モジュール１２２０がHCC計算を実行し、完全なMSDUまたはフラグメントを単離し、フレーム検査シーケンスを処理し、正しく受信されたMSDUを追跡し、遅延されたACK要求に応答して遅延されたACＫを構築し、MSDUをフィルタ処理し、サーバー（マスターSTB）のために意図された正しく受信されたMSDUのみを転送する。ソフトウェア・モジュールは、物理的特性およびパラメータをデータ記憶ユニット１２２５から受信し、受信されたMSDUについての遅延されたACKを転送する。ソフトウェア・モジュール１２２０は、そのビデオ・クライアント（リモートSTB）のために意図されていないMSDUは破棄し、MACコマンドをソフトウェア・モジュール１２３０に転送する。このソフトウェア・モジュール１２３０はMAC管理メッセージを分離し、MAC帯域幅応答をデータ記憶ユニット１２３５に転送し、リモートSTBからのMSDU ACKをMSDUバッファ１２４０に転送する。ソフトウェア・モジュール１２２０はMSDUをソフトウェア・モジュール１２４５に転送し、このソフトウェア・モジュール１２４５がフラグメントから完成されたMSDUを再構築し、不完全なMSDUのフラグメントを記憶し、MSDUを適正な順序にする。ソフトウェア・モジュール１２４５は並べ替えおよびフレーム構築バッファ１２５０および受信MSDUフラグメント・バッファ１２５５と通信する。ソフトウェア・モジュール１２４５は完全なMSDUをソフトウェア・モジュール１２６０に転送し、このソフトウェア・モジュール１２６０はMACフレームを優先度を含むイーサネット（登録商標）・フレームに変換する。ソフトウェア・モジュール１２６０は、転送テーブルおよびサービス・フロー情報もデータ記憶ユニット１２６５から受信する。
【００４７】
図１３を参照すると、物理プリアンブルおよび物理ヘッダがCTA当たり一つの物理フレームをなす。リモートSTBへの遅延されたACK、リモートSTBへの待ち行列状態情報要求およびリモートSTBへの複数データ・パケットが、保護されたMACヘッダとともにMACフレームの集合をなす。上記がそのCTA内での任意の余っている時間と連結されたものが、リモートSTBへのそのPNCのための下りCTAをなす。
【００４８】
ここで図１４を参照すると、各MACペイロードについて、対応するMACヘッダがある。HCCが計算され、MACヘッダの後かつMACペイロードの前に挿入される。FCSが計算され、MACペイロードの後に挿入される。これは、スーパーMACフレームを作り出すために各MACペイロードについてなされる。スーパーMACフレーム長は物理ヘッダの一部である。物理ヘッダは、変調され空中を通じて送信されるCTAを作るためにスーパーMACフレームより前に挿入される。物理ヘッダは遅い、信頼できるレートで送信され、CTAのスーパーMACフレーム部分は何らかの望ましいレートで送信される。
【００４９】
CTA4、CTA5およびCTA6内のフレームの送信は同様にして送られる。これらのCTAの一つにおいて送られるフレームの一例が図１５に示されている。図１５は、単一の上りCTAの一つ（DEV-xからPNC）を描いている。単一の上りCTAは一つの物理フレームと、保護されたヘッダをもつMACフレームの集合と、CTA内の任意の余った時間を含む。本発明については、上りトラフィックの多くはTCP ACKであろう。図１３に示された下りCTAと同様、物理フレームは物理プリアンブルおよび物理ヘッダを含む。MACフレームの集合はPNCへの遅延されたACK、PNCへの待ち行列状態情報およびPNCへのデータ・パケットを含む。このCTAが、PNCに待ち行列状態情報を運び戻すフレームを含んでいることを注意しておく。この待ち行列状態情報は待ち行列のサイズ（もし可変なら）、待ち行列中のフレーム数、フレームの平均長および待ち行列の入力におけるフレーム到着レートを含んでいてもよい。
【００５０】
本発明については、ビデオ・ストリーミング・パケット（下り）はTCPを使ってマスターSTBから送られると想定される。このため、ビデオとは反対方向（上り）にTCP ACKが生成されることになる。これらのTCP ACKはオーバーヘッドを追加し、もしそのオーバーヘッドが解消されれば、より実際のトラフィック（すなわち下りのビデオ）のために時間を解放できる。さらに、TCPに組み込まれたフロー制御機構のため、および（バッファおよびCTAに起因して）無線ブリッジによって追加される追加的な遅延のため、TCPは、ビデオ・ストリームが、それが本当に達する必要のあるレートに達することを妨げうる。
【００５１】
まず、問題がよりよく理解されるよう、TCPについて手短に述べる。次いで、その問題を解決する助けとなりうる、高レベルでの若干数の層横断型の修正を呈示する。なお、マスターSTBおよびリモートSTBにおけるTCPパラメータそのものの変更が、この問題を解決するためのもう一つの方法であるが、何度か述べたように、これは可能ではないと想定されることを注意しておく。
【００５２】
TCPは、全二重の接続指向の（connection-oriented）転送プロトコルである。TCPはデータ・ストリームのセグメントを送る。UDPは呈示されるパケットを送る。TCPの一つの特徴は、信頼できる送達である。これは、TCP ACKの使用を通じて保証される。この機構はインターネット・トラフィックについて有益であることが立証されているが、信頼できる送達を生じるその恩恵は、すでに高い信頼性をもつLAN上では疑問がある。よって、TCP ACKは著しいオーバーヘッドを追加する。無線のような帯域幅制限されたネットワークの場合、そのオーバーヘッドの不利は多大である。
【００５３】
TCPカプセル化が図１６に示されている。TCPヘッダがTCPペイロードの前に付加される。これら両者の前にIPヘッダが付加される。TCPペイロードとTCPヘッダの組み合わせはTCPセグメント（TCP segment）とも呼ばれる。TCPセグメントとIPヘッダの組み合わせはIPデータグラム（IP datagram）とも呼ばれる。
【００５４】
IPヘッダおよびTCPヘッダがそれぞれ図１７および図１８に示されている。IPヘッダは宛先IPアドレスおよびソースIPアドレスを含む。さらに、IPヘッダは、そのペイロードを識別するために使われるプロトコル番号を含む。TCPの場合、この番号は17である。UDPなら6である。TCPヘッダは宛先ポート番号およびソース・ポート番号を含む。ポート番号は、各端におけるデバイスによって、そのTCP接続に関連付けられたソフトウェア・アプリケーションまたはコードを識別するために使用される。
【００５５】
さらに、TCPヘッダは、本発明の動作に重要ないくつかの他のフィールドを含む。TCPは全二重接続なので、各端は別個のシーケンス番号カウンタを維持する。32ビットのシーケンス番号はバイト・カウンタであり、出ていくパケット毎に、同じTCP接続の一部であるソース・デバイスによってインクリメントされる。このヘッダはまた、32ビットの受け取り確認番号をも含む。これは、送信側に、受信器が期待する次のバイトが何であるかを（換言すれば、受信器がバイト−1まで成功裏に受信したということを）通知するために使われる。全二重TCP接続の反対方向も同じ手順をたどる。
【００５６】
受信器が受信しうる最大セグメント・サイズ（バイト単位）を示す最大セグメント・サイズ（MSS）が受信器から送信器に送られる。典型的なTCP MSSは1024（一般的）、536（一端が他端からMSSを受信しないときのデフォルト）、イーサネット（登録商標）上での1460などである。536というデフォルトは、IPが最小サイズ576バイトのパケット（ペイロードおよびTCPおよびIPヘッダ）を扱える必要があるという事実を反映している。よって、インターネットに送られるトラフィックは通例、この数に制限される。外部ルート対内部ルートは、経路最大転送単位（MTU: maximum transfer unit）発見によって決定される。
【００５７】
チェックサムは、TCPヘッダおよびデータをカバーし、フレームが正しく受信されたかどうかを判定するために使用される。最も一般的なオプション・フィールドは最大セグメント・サイズ（MSS）である。これは、接続が確立されようとしているときに送られる。ACKフィールドは、受け取り確認値が有効であることを意味する。
【００５８】
シーケンス番号は、選択的な再送信や否定受け取り確認なしにスライディング・ウィンドウ・プロトコルを実装するために使われる。シーケンス番号は、「N個戻る（Go-Back-N）」方式または「停止して待機（Stop-n-Wait）」方式において使用できる。TCPスライディング・ウィンドウ動作は図１９に示されている。基本的に、任意の所与の時点において、「ネットワーク内」には受け取り確認されていないバイトが限られた数だけ許容される。バイトが受け取り確認されるときに、ウィンドウの後端部分（trailing part）が左に動く。バイトが受け取り確認されるおよび／またはより大きなウィンドウが広告されるときに、ウィンドウの先端（leading end）が左に動く。使用可能なウィンドウ内に残されるバイト数はウィンドウ・サイズおよびすでに送られたバイトが何バイトかに依存する。宛先は、受信できるバイト数に基づいて（おそらくは受信バッファ・サイズに基づいて）ウィンドウ・サイズを設定する。スライディング・ウィンドウは、次に示すよく知られた帯域幅遅延積制限（bandwidth delay product limitation）を与える。
【００５９】
ウィンドウ・サイズ（容量）＝有効帯域幅（ビット／秒）×往復時間（秒）
TCPはもともと、16ビットのウィンドウ・サイズをもつだけであった。これは、TCP受信器がウィンドウ・サイズをその最大に設定したとき、ネットワーク内に許容されるのはたった64キロバイトであったことを意味していた。ウィンドウ・サイズは、ネットワーク中のずっと多くのバイトが受け取り確認されないでいることを許容するスケーリング・オプションを含むよう修正された。しかしながら、レガシー実装のため、そしてそれが「たいていの場合」機能するので、多くの実装はいまだに16ビットのスライディング・ウィンドウを使うのみである。有限のTCPスライディング・ウィンドウは、ビデオのために必要とされる広帯域幅およびTDMA MAC無線ブリッジのために必要とされる遅延に起因する目標アプリケーションにおける問題を引き起こすことができる。
【００６０】
スライディング・ウィンドウが例示的なブリッジング・システムにどのように負の影響を与えることができるかを見るために、次の例を考える。スーパーフレームの長さが5msecまたは10msecに固定されており、CTAが固定されている場合については、表１がいくつかの代表的な値を示す。表２は、本稿に示されるMPDU集積（MPDU aggregation）の方法および他の若干の個別的な想定（たとえば、ビデオ・パケット・サイズ）を使って各CTA内に期待しうるパケットの概数を示す。往復時間（RTT: round trip time）は、TCPパケットが送られたときからそのセグメントのみに関連付けられたTCP ACKが受信される時刻までの時間である。スーパーフレームが10msecであれば、RTTは少なくとも20msecである。実際には、送信待ち行列内のパケットおよびMACレベルでの再送信のため、より高くなる。20Mbpsおよび20msecの遅延では、スライディング・ウィンドウは、ストリームが意図されるレートで流れることを許容するためには、少なくとも50キロバイトである必要がある。追加的なバッファリングおよびデータがCTAの開始と非同期ではいってくるという事実のため、ストリームがこの例において遅くなる可能性が高い。さらに、TCPスライディング・ウィンドウは、50キロバイトより遅い何らかの値に設定されてもよい。
【００６１】
【表１】
【００６２】
【表２】
いくつかの有利なタイムアウトもある。再送信タイムアウトは、RTTの測定に基づくことができるが、典型的には500msecに設定される。再送信タイムアウトは、受け取り確認されていないTCPセグメントの再送信を開始するために使用される。もう一つのタイマーは、TCP ACKが送信器に返される時を遅延させるために時々使用される。これは、データがペイロードについて利用可能になることを許容するためである。このタイマーは、典型的には200msecについて設定され、本願のためのRTTを増すことになる。
【００６３】
TCP受信器が誤りをもつパケットを受信する場合、TCP受信器は、そのパケットを破棄し、送信側がそのパケットを再送信するのを待つ。TCP送信者がタイムアウト期間、典型的には500msec以内にACKを受信しない場合、TCP送信者はそのパケットを再送信する。ビデオ・ストリーミング・アプリケーションについては、これでは受信側が使用するには遅すぎ、そのパケットも破棄されうる。
【００６４】
「遅いスタート（Slow Start）」は比較的新しめのTCP機能である。この機能では、新しいパケットがネットワークに注入されるべきレートは、受け取り確認が反対側から返されるレートである。これは、事実上、送信者のTCPに、輻輳窓（congestion window）として知られるもう一つのウィンドウを追加する。これは主として、ルーターを通じて行くときに輻輳を回避するために使われる。
【００６５】
本発明においては、TCP ACKオーバーヘッドおよびTCPウィンドウの効果を減らし、輻輳を管理する二つの方法がある。二つの方法は組み合わされて第三の方法を形成することができる。本発明の前記諸方法は、MAC層がTCP ACKプロセスにおいて限られた仕方で参加することに関わる。ビデオ・ストリーム・パケットおよび戻りACKは、TCP接続の一部として識別される。同じ接続（またはストリーム）に属するTCPパケットが宛先IPアドレス、ソースIPアドレス、TCPソース・ポート番号およびTCP宛先ポート番号によって一意的に識別できることはよく知られている。目標アプリケーションについては、同じ送信待ち行列内のパケットの大半は、同じTCP接続に属する可能性が高い。よって、有効なシーケンス番号をもつTCP ACKは、TCPヘッダ内のACKフラグを見ることによって決定できる。
【００６６】
第一の方法では、無線リンクを通じてリモート・ブリッジ・デバイスおよびマスター・ブリッジング・デバイスから実際に転送されるTCP ACKの数を減らすことが望ましい。本発明はTDMA MACを使用するので、リモートSTBからマスターSTBへの送信は、スーパーフレームの長さに依存して5または10msec毎にまとまって起こる。リモートSTB／デバイスからマスターSTB／デバイスへの送信のために、リモートSTBは、その送信待ち行列からパケットを取り出し、送信のための一連のフレーム（または集積されたフレーム［aggregated frames］）に組み立てる。この例示的な適用では、このトラフィックのすべては、マスターSTBを宛先とされている。
【００６７】
リモート・ブリッジ・デバイスは、送信待ち行列内のフレームのIPおよびTCPヘッダを調べ、どれが同じTCP接続からのTCP ACKであるかを判定する。それらのパケットについて、次いで、TCPヘッダ内のシーケンス番号が読まれる。それらのパケット内にペイロードがないと想定すると、リモート・ブリッジ・デバイスは最高のシーケンス番号を送る必要があるだけである。というのも、TCPでは、そのシーケンス番号がすべてのより低いシーケンス番号を含むからである。パケットの一つがペイロードを含む場合、その特定のパケットが、ヘッダ内に適正なシーケンス番号を設定されて返されるパケットであることができる。TCP ACKパケットの二つ以上がそのペイロードにデータを含んでいる場合には、それもシーケンス番号を繰り返して送られる。これは事実上、送信待ち行列から冗長な「TCP ACKのみ」パケットをすべて消去する。これは、より短いCTAがリモート・デバイス／STBに割り当てられることを許容し、マスター・デバイス／STBに割り当てられるCTAのためにより多くの時間を、よって下りビデオ送信のために割り当てられる、より多くの時間を残す。
【００６８】
図２０は、リモート・ブリッジ・デバイスにおいて実施される、本発明の第一の方法の高レベルのフローチャートである。２００５では、リモート・ブリッジ・デバイスは、マスター・ブリッジ・デバイスに転送されるべきいくつかのTCP ACKを受信する。２０１０では、リモート・ブリッジ・デバイスはその送信待ち行列をスキャンし、ペイロードをもたない隣り合うTCP ACKを、そのTCP ACKの集合のうちからの最高のシーケンス番号を受け取り確認する単一のTCP ACKで置き換える。２０１５では、単一の集積TCP ACK（aggregate TCP ACK）がマスター・ブリッジ・デバイスにCTA内において転送される。このプロセスは２００５から繰り返される。
【００６９】
この第一の方法はTCP送信ACKのオーバーヘッドを減らすが、それでも、TCPパケットが遅すぎ、TCPレベルで再送信される可能性がある。TCP再送信はかなり長いタイムアウトに基づくので、リアルタイムのビデオ・ストリームのためにはそれほど有用ではない。多くのビデオ・コーダ・デコーダ（コーデック）は誤り隠蔽方式を含んでいるので、当該パケットが若干の誤りをもって時間通りに到着した場合よりも、TCPレベルの再送信のほうが一層悪い問題を引き起こしうる。
【００７０】
本発明の第二の方法では、マスター・デバイス／STBに返されるローカルなTCP ACKがマスター・ブリッジ・デバイスによって生成される。つまり、マスター・デバイス／STBはだまされて、下りパケットがすでにリモート・デバイス／STBによって受信されたと思い込まされる。マスター・デバイス／STBはTCP ACKを受信するので、そのデータ／情報を再送信はしない。よって、何らかの理由で下りデータが誤って受信される場合、数回のMACレベルの再送信後であっても、下りビデオ・データは相変わらずリモート・デバイス／STBに転送される。しかしながら、指摘したように、ビデオ・ストリーミングのためには、「遅くて正しい」よりも、「若干の誤りはあるが比較的時間通り」のほうがよい。
【００７１】
前記方法は、マスター・デバイス／STBからのあらゆるTCPトラフィックに対して使用できるし、あるいはある特定のTCP接続に対してのみ使用されることもできる。いずれの場合でも、マスター・ブリッジ・デバイスは各TCP接続を別個に追跡する。先に指摘したように、TCPトラフィックは、IPヘッダにおいて、プロトコル番号によって識別され、ストリーム自身はソースおよび宛先IPアドレスならびにソースおよび宛先TCPポート番号によって一意的に識別される。
【００７２】
この方法は、いくつかの理由で、ビデオ・ストリームそのものについてのみ使用することが最善である。ビデオ・ストリーム・パケットがリモート・デバイス／STBに、たとえ誤りがあっても時間通りに渡されることが最善ではあるが、頻度がより低い他のデータ・トラフィック（たとえばボックス制御［box control］）は正しく到着する必要があることがありうる。さらに、各TCP接続は別個に管理される必要があるが、N個のTCP接続を管理するには、各リモート・デバイス／STBへの一つのTCP接続を管理するよりN倍多くの資源（すなわち、データ構造等）が必要とされる。さらに、例示的なアプリケーションは下りのビデオ配信なので、潜在的な効率向上の大半は、ビデオ・ストリームにおいて得られる。このすべてのため、ローカルTCP ACKを、目標アプリケーションであるビデオ・ストリーム接続についてのみ生成することが望ましい。
【００７３】
マスター・ブリッジング・デバイスは、ビデオ・ストリームを識別するためにいくつかの方法の一つを使用できる。いくつかのアプリケーションでは、STBおよびブリッジング・デバイスは一つの製造業者からのものであることがありうる。ビデオ配信に使われるTCPポート番号はブリッジ・デバイスにあらかじめ知られている（すなわち、設計時に組み込まれる）のでもよいし、あるいはその情報を、直接またはネットワークもしくは他のインターフェースを通じて、ブリッジング・デバイスに手動で入力することが可能であってもよい。ブリッジング・デバイスがストリームを他の何らかの仕方で、可能性としてはサービス・プロバイダーのネットワークと直接通信していることがありうるSTBとの直接通信で、識別することが可能である。
【００７４】
マスター・ブリッジング・デバイスがビデオ・ストリームをその特性から識別することが可能である。たいていのビデオ・ストリーム（放送事業者からの）は1〜2Mbpsの範囲にある。高精細度ビデオは15〜20Mbpsにより近い。マスター・ブリッジング・デバイスはTCP接続セットアップ・パケットをかぎつけて（sniff）、次いでそのストリームを何らかの時間期間（たとえば1秒）にわたって監視することができる。それが一定のストリームであるように見えれば、マスター・ブリッジ・デバイスはこの方法を使うことを開始できる。
【００７５】
マスター・ブリッジ・デバイスはTCPスライディング・ウィンドウ、TCPシーケンス番号およびそれ自身の送信待ち行列を追跡する。マスター・デバイス／STBからのTCPフレームの到着が頻繁すぎる場合、マスター・ブリッジ・デバイスは、待ち行列レベルが下がるまでTCP ACKを差し控える。本発明の本方法はフロー制御の一つの形である。
【００７６】
図２１は、マスター・ブリッジング・デバイスで実施される本発明の第二の方法の高レベルの送信フローチャートである。任意的に、TCPセットアップの間に２１０５で、マスター・ブリッジ・デバイスはマスター・デバイス／STBにローカルに、最適セグメント・サイズならびにバッファリングおよびCTAに起因するシステム遅延をカバーするのに十分大きなTCPウィンドウ・サイズをもって応答する。２１１０で、マスター・ブリッジ・デバイスはマスター・デバイス／STBからTCPデータ・セグメントを受信する。２１１５で試験が実行され、送信待ち行列が所定数のCTA（たとえば二つのCTA）のために十分なTCPデータを含んでいるかどうかが判定される。十分なTCPデータがあれば、動作２１１０が再び実行される。十分なTCPデータ・セグメントがなければ、２１２０でマスター・ブリッジ・デバイスが、マスター・デバイス／STBに返すためのローカルなTCP ACKを生成し、動作２１１０が再び実行される。
【００７７】
TCP接続は全二重接続なので、リモート・デバイス／STBから論理的にマスター・デバイス／STBに向かうACKもある。この場合、マスター・デバイスSTBが下りパケットに対して実行したのと同じプロセスを、リモート・デバイス／STBが上りパケットに対して実行する。
【００７８】
マスター・ブリッジ・デバイスはまた、リモート・デバイス／STBから実際に返されるTCP ACKを途中で捕らえ、それがマスター・デバイス／STBに送られないようにする。マスター・ブリッジ・デバイスはこれらのTCP ACK内の情報を使って、到来パケットの処理に関してリモート・デバイス／STBがどこにあるかを判定する。あるいはまた、TCP ACKはリモート・ブリッジ・デバイスによって途中で捕らえられることもでき、望むならマスター・ブリッジ・デバイスに要約レポートが送られる。リモート・ブリッジ・デバイスが途中で捕らえられたTCP ACKを捨てることも可能である。
【００７９】
図２２は、マスター・ブリッジ・デバイスにおいてリモートTCP ACKを転送するための高レベルのフローチャートである。２２０５で、マスター・ブリッジ・デバイスはリモート・デバイス／STBからTCP ACK（ペイロードなし）を受信する。２２１０で試験が実行されて、受信されたデータ・セグメントがすでに受け取り確認されているかどうかが判定される。そのデータ・セグメントがすでに受け取り確認されていれば、２２１５でTCP ACKは破棄され、プロセスは２２０５から繰り返される。そのデータ・セグメントがまだ受け取り確認されていなければ、２２２０で単一のTCP ACKがマスター・デバイス／STBに転送される。
【００８０】
リモート・ブリッジ・デバイスは、何度かMACレベルで送信されたパケットを意識する。それらのパケットは遅いかもしれず、ひとたび最終的にリモート・ブリッジ・デバイスにおいて受信されたときに誤っていることさえありうる。いずれにせよ、リモート・デバイス／STBもどのバイトが受信および受け取り確認されたかを追跡しているので、そのデータ・セグメントはやはりリモート・デバイス／STBに転送される。
【００８１】
図２３は、リモート・デバイスにおいて実施される本発明の前記第二の方法の高レベルのフローチャートである。２３０５では、リモート・ブリッジ・デバイスはマスター・ブリッジ・デバイスからTCPデータ・セグメント（ペイロードなし）を受信する。２３１０で試験が実行されて、フレームが正しいかどうか（フレームがフレーム検査シーケンスに合格したかどうか）が判定される。フレームが正しければ、そのフレームは２３１５でリモート・デバイス／STBに転送され、プロセスは２３０５から繰り返される。フレームが正しくなければ、２３２０で別の試験が実行されて、これがMAC層による再送信の最後の試行（五回目の試み）であるかどうかが判定される。これが最後の試行でなければ、プロセスは２３０５から繰り返される。これが最後の試行であれば、２３２５で、そのデータに一致するよう新しいフレーム検査シーケンスが計算され、新しいTCPフレームが構築される。この新しいフレームは正しく見えるが、不正な／正しくないデータを有しており、低頻度で起こるべきである。
【００８２】
本発明のこの第二の方法の利点は、ソースをだましてパケットが受け取り確認されたと思い込ませることができることである。これは、より多くのパケットが通信経路内にあることを許容し、実効的に、ウィンドウを長くし、結果としての平均ビットレートを増す。この平均ビットレートは、ビデオの自然なストリーミング・レートより上に保たれねばならない。
【００８３】
第三の方法は、上記した二つの方法を組み合わせる。TCP ACKは、前記第二の方法におけるようにブリッジ・デバイス（マスターまたはリモート）の一つによってローカルに生成されるが、リモートSTBによって返されるTCP ACKは前記第一の方法において記載されたように組み合わされる。
【００８４】
上記の記述は、高精細度ビデオ配信用途に好適な一つのマスターおよび三つのリモート・デバイスをもつ無線ブリッジング・システムに焦点を当ててきたが、当業者には、上記のような本発明の方法が一般的な無線CSMAまたはTDMA MACに、またさらには共通媒体（たとえば電力線）上で走る有線MACにも拡張できることは明らかなはずである。
【００８５】
本発明がさまざまな形のハードウェア、ソフトウェア、ファームウェア、特殊目的プロセッサまたはそれらの組み合わせにおいて実装されうることは理解しておくものとする。好ましくは、本発明はハードウェアおよびソフトウェアの組み合わせとして実装される。さらに、ソフトウェアは好ましくは、プログラム記憶デバイス上に具体的に具現されたアプリケーション・プログラムとして実装される。アプリケーション・プログラムは、いかなる好適なアーキテクチャを有する機械にアップロードされ、これにより実行されてもよい。好ましくは、その機械は、一つまたは複数の中央処理装置（CPU）、ランダム・アクセス・メモリ（RAM）および入出力（I/O）インターフェースといったハードウェアをもつコンピュータ・プラットフォーム上で実装される。コンピュータ・プラットフォームはまた、オペレーティング・システムおよびマイクロ命令コードをも含む。本稿に記載されるさまざまなプロセスおよび機能は、前記マイクロ命令コードの一部または前記アプリケーション・プログラムの一部（またはそれらの組み合わせ）であってもよい。それはオペレーティング・システムを介して実行される。さらに、追加的なデータ記憶装置および印刷装置のようなさまざまな他の周辺装置が前記コンピュータ・プラットフォームに接続されてもよい。
【００８６】
付属の図面に描かれている構成要素となるシステム・コンポーネントおよび方法ステップのいくつかは好ましくはソフトウェアで実装されるので、システム・コンポーネント（またはプロセス・ステップ）どうしの間の実際の接続は、本発明がプログラムされる仕方に依存して異なることがありうることを理解しておくべきである。本稿の教示を与えられれば、当業者は本発明のこれらおよび同様の実装または構成を考えることができるであろう。
【００８７】
原出願の出願時の特許請求の範囲をここでも開示しておく。
〔請求項１〕
受け取り確認を管理する方法であって：
データ・パケットおよび受け取り確認を接続と同定する段階と；
前記受け取り確認のどれが消去できるかを判定する段階と；
消去できる前記受け取り確認を、単一の受け取り確認で置き換える段階と；
該単一の受け取り確認を送信する段階とを有する、
方法。
〔請求項２〕
前記同定する段階がさらに、送信待ち行列内のヘッダを調べる段階を有する、請求項１記載の方法。
〔請求項３〕
前記調べる段階がさらに、前記ヘッダ内のフラグを調べる段階を有する、請求項２記載の方法。
〔請求項４〕
前記判定する段階がさらに、どの受け取り確認が共通の接続からであるかを判定する段階を有する、請求項２記載の方法。
〔請求項５〕
前記ヘッダ内のシーケンス番号を読むことをさらに含む、請求項４記載の方法。
〔請求項６〕
前記単一の受け取り確認が受け取り確認される前記データ・パケットの最高のシーケンス番号をもつ、請求項５記載の方法。
〔請求項７〕
送信されるべきペイロード・パケットがあるかどうかを判定する段階と；
前記ペイロード・パケット内において前記単一の受け取り確認を送信する段階とをさらに有する、
請求項１記載の方法。
〔請求項８〕
前記接続がTCP接続である、請求項１記載の方法。
〔請求項９〕
前記受け取り確認がTCP受け取り確認であり、前記単一の受け取り確認がTCP受け取り確認である、請求項１記載の方法。
〔請求項１０〕
受け取り確認を管理する方法であって：
データ・セグメントを受信する段階と；
接続を追跡する段階と；
所定数のチャネル時間割り当てのための十分なデータ・セグメントがあるかどうかを判定する段階と；
前記所定数のチャネル時間割り当てのための十分なデータ・セグメントがある場合に、ある選択された接続について前記受け取り確認を生成する段階とを有する、
方法。
〔請求項１１〕
フレームが到着するのが頻繁すぎる場合に受け取り確認を差し控えることをさらに含む、請求項１０記載の方法。
〔請求項１２〕
請求項１０記載の方法であって、
リモート・デバイスによって転送されたセグメント受け取り確認を途中で捕らえる段階と；
前記セグメントがすでに受け取り確認されているかどうかを判定する段階と；
前記セグメントがすでに受け取り確認されていれば、前記セグメント受け取り確認を破棄する段階と；
前記セグメントがまだ受け取り確認されていなければ、前記セグメント受け取り確認を転送する段階とを有する、
方法。
〔請求項１３〕
要約レポートを受信する段階をさらに有する、請求項１０記載の方法。
〔請求項１４〕
前記接続がTCP接続である、請求項１０記載の方法。
〔請求項１５〕
前記受け取り確認がTCP受け取り確認である、請求項１０記載の方法。
〔請求項１６〕
前記受け取り確認を単一の受け取り確認に集積する段階をさらに含む、請求項１０記載の方法。
〔請求項１７〕
受け取り確認を管理する装置であって：
データ・パケットおよび受け取り確認を接続と同定する手段と；
前記受け取り確認のどれが消去できるかを判定する手段と；
消去できる前記受け取り確認を、単一の受け取り確認で置き換える手段と；
該単一の受け取り確認を送信する手段とを有する、
装置。
〔請求項１８〕
前記同定する手段がさらに、送信待ち行列内のヘッダを調べる手段を有する、請求項１７記載の装置。
〔請求項１９〕
前記調べる手段がさらに、前記ヘッダ内のフラグを調べる手段を有する、請求項１８記載の装置。
〔請求項２０〕
前記判定する手段がさらに、どの受け取り確認が共通の接続からであるかを判定する手段を有する、請求項１８記載の装置。
〔請求項２１〕
前記ヘッダ内のシーケンス番号を読む手段をさらに有する、請求項２０記載の装置。
〔請求項２２〕
前記単一の受け取り確認が受け取り確認される前記データ・パケットの最高のシーケンス番号をもつ、請求項２１記載の装置。
〔請求項２３〕
送信されるべきペイロード・パケットがあるかどうかを判定する手段と；
前記ペイロード・パケット内において前記単一の受け取り確認を送信する手段とをさらに有する、
請求項１７記載の装置。
〔請求項２４〕
前記接続がTCP接続である、請求項１７記載の装置。
〔請求項２５〕
前記受け取り確認がTCP受け取り確認であり、前記単一の受け取り確認がTCP受け取り確認である、請求項１７記載の装置。
〔請求項２６〕
受け取り確認を管理する装置であって：
データ・セグメントを受信する手段と；
接続を追跡する手段と；
所定数のチャネル時間割り当てのための十分なデータ・セグメントがあるかどうかを判定する手段と；
前記所定数のチャネル時間割り当てのための十分なデータ・セグメントがある場合に、ある選択された接続について前記受け取り確認を生成する手段とを有する、
装置。
〔請求項２７〕
フレームが到着するのが頻繁すぎる場合に受け取り確認を差し控える手段をさらに有する、請求項２６記載の装置。
〔請求項２８〕
請求項２６記載の装置であって、
リモート・デバイスによって転送されたセグメント受け取り確認を途中で捕らえる手段と；
前記セグメントがすでに受け取り確認されているかどうかを判定する手段と；
前記セグメントがすでに受け取り確認されていれば、前記セグメント受け取り確認を破棄する手段と；
前記セグメントがまだ受け取り確認されていなければ、前記セグメント受け取り確認を転送する手段とを有する、
装置。
〔請求項２９〕
要約レポートを受信する手段をさらに有する、請求項１６記載の装置。
〔請求項３０〕
前記接続がTCP接続である、請求項１６記載の装置。
〔請求項３１〕
前記受け取り確認がTCP受け取り確認である、請求項２６記載の装置。
〔請求項３２〕
前記受け取り確認を単一の受け取り確認に集積する手段をさらに含む、請求項２６記載の装置。
【００８８】
さらにいくつかの態様を開示しておく。
〔態様１〕
無線ブリッジング・デバイスによって実行される、リモート・デバイスによって送られマスター・デバイスに宛てられた受け取り確認を管理する方法であって：
データおよび受け取り確認を、前記リモート・デバイスと前記マスター・デバイスの間の接続と同定する段階と；
前記受け取り確認のどれが冗長であるかを判定する段階と；
前記冗長な受け取り確認を、単一の受け取り確認で置き換える段階と；
該単一の受け取り確認を送信する段階とを有する、
方法。
〔態様２〕
前記同定する段階がさらに、送信待ち行列内のヘッダを調べる段階を有する、態様１記載の方法。
〔態様３〕
前記調べる段階がさらに、前記ヘッダ内のフラグを調べる段階を有する、態様２記載の方法。
〔態様４〕
前記判定する段階がさらに、どの受け取り確認が共通の接続からであるかを判定する段階を有する、態様２記載の方法。
〔態様５〕
前記ヘッダ内のシーケンス番号を読むことをさらに含む、態様４記載の方法。
〔態様６〕
前記単一の受け取り確認が受け取り確認される前記データの最高のシーケンス番号をもつ、態様５記載の方法。
〔態様７〕
送信されるべきペイロード・パケットがあるかどうかを判定する段階と；
前記ペイロード・パケットを、前記単一の受け取り確認として送信する段階とをさらに有する、
態様１記載の方法。
〔態様８〕
前記接続がTCP接続である、態様１記載の方法。
〔態様９〕
前記受け取り確認がTCP受け取り確認であり、前記単一の受け取り確認がTCP受け取り確認である、態様１記載の方法。
〔態様１０〕
無線ブリッジング・デバイスによって実行される、リモート・デバイスによって送られマスター・デバイスに宛てられた受け取り確認を管理する方法であって：
前記リモート・デバイスによって送られたデータを受信する段階と；
前記リモート・デバイスと前記マスター・デバイスの間の接続を追跡する段階と；
特定のデータについて所定数の再送信後にも受け取り確認が受信されない場合、該特定のデータについての受け取り確認を生成する段階と；
生成された受け取り確認を前記マスター・デバイスに送信する段階とを有する、
方法。
〔態様１１〕
データが到着するのが頻繁すぎる場合に受け取り確認を差し控えることをさらに含む、態様１０記載の方法。
〔態様１２〕
態様１０記載の方法であって、
特定のデータについて前記リモート・デバイスによって送られた受け取り確認を途中で捕らえる段階と；
前記特定のデータがすでに受け取り確認されているかどうかを判定する段階と；
前記特定のデータがすでに受け取り確認されていれば、前記受け取り確認を破棄する段階と；
前記特定のデータがまだ受け取り確認されていなければ、前記受け取り確認を前記マスター・デバイスに転送する段階とを有する、
方法。
〔態様１３〕
前記リモート・デバイスによって送られた受け取り確認を途中で捕らえた別の無線ブリッジング・デバイスから要約レポートを受信する段階をさらに有する、態様１０記載の方法。
〔態様１４〕
前記接続がTCP接続である、態様１０記載の方法。
〔態様１５〕
前記受け取り確認がTCP受け取り確認である、態様１０記載の方法。
〔態様１６〕
前記受け取り確認を単一の受け取り確認に集積する段階をさらに含む、態様１０記載の方法。
〔態様１７〕
リモート・デバイスによって送られ、マスター・デバイスに宛てられた受け取り確認を管理する無線ブリッジング・デバイスであって：
データおよび受け取り確認を前記リモート・デバイスと前記マスター・デバイスの間の接続と同定する手段と；
前記受け取り確認のどれが冗長であるかを判定する手段と；
前記冗長な受け取り確認を、単一の受け取り確認で置き換える手段と；
該単一の受け取り確認を送信する手段とを有する、
無線ブリッジング・デバイス。
〔態様１８〕
前記同定する手段がさらに、送信待ち行列内のヘッダを調べる手段を有する、態様１７記載の無線ブリッジング・デバイス。
〔態様１９〕
前記調べる手段がさらに、前記ヘッダ内のフラグを調べる手段を有する、態様１８記載の無線ブリッジング・デバイス。
〔態様２０〕
前記判定する手段がさらに、どの受け取り確認が共通の接続からであるかを判定する手段を有する、態様１８記載の無線ブリッジング・デバイス。
〔態様２１〕
前記ヘッダ内のシーケンス番号を読む手段をさらに有する、態様２０記載の無線ブリッジング・デバイス。
〔態様２２〕
前記単一の受け取り確認が受け取り確認される前記データの最高のシーケンス番号をもつ、態様２１記載の無線ブリッジング・デバイス。
〔態様２３〕
送信されるべきペイロード・パケットがあるかどうかを判定する手段と；
前記ペイロード・パケットを前記単一の受け取り確認として送信する手段とをさらに有する、
態様１７記載の無線ブリッジング・デバイス。
〔態様２４〕
前記接続がTCP接続である、態様１７記載の無線ブリッジング・デバイス。
〔態様２５〕
前記受け取り確認がTCP受け取り確認であり、前記単一の受け取り確認がTCP受け取り確認である、態様１７記載の無線ブリッジング・デバイス。
〔態様２６〕
リモート・デバイスによって送られ、マスター・デバイスに宛てられた受け取り確認を管理する無線ブリッジング・デバイスであって：
データを受信する手段と；
接続を追跡する手段と；
所定数のチャネル時間割り当てのための十分なデータがあるかどうかを判定する手段と；
前記所定数のチャネル時間割り当てのための十分なデータがある場合に、ある選択された接続について前記受け取り確認を生成する手段とを有する、
無線ブリッジング・デバイス。
〔態様２７〕
データが到着するのが頻繁すぎる場合に受け取り確認を差し控える手段をさらに有する、態様２６記載の無線ブリッジング・デバイス。
〔態様２８〕
態様２６記載の無線ブリッジング・デバイスであって、
特定のデータについてリモート・デバイスによって送られた受け取り確認を途中で捕らえる手段と；
前記特定のデータがすでに受け取り確認されているかどうかを判定する手段と；
前記特定のデータがすでに受け取り確認されていれば、前記受け取り確認を破棄する手段と；
前記特定のデータがまだ受け取り確認されていなければ、前記受け取り確認を前記マスター・デバイスに転送する手段とを有する、
無線ブリッジング・デバイス。
〔態様２９〕
前記リモート・デバイスによって送られた受け取り確認を途中で捕らえた別の無線ブリッジング・デバイスから要約レポートを受信する手段をさらに有する、態様１６記載の無線ブリッジング・デバイス。
〔態様３０〕
前記接続がTCP接続である、態様１６記載の無線ブリッジング・デバイス。
〔態様３１〕
前記受け取り確認がTCP受け取り確認である、態様２６記載の無線ブリッジング・デバイス。
〔態様３２〕
前記受け取り確認を単一の受け取り確認に集積する手段をさらに含む、態様２６記載の無線ブリッジング・デバイス。
〔態様３３〕
無線ブリッジング・デバイスによって実行される、マスター・デバイスからリモート・デバイスへのデータ送信を管理する方法であって：
前記マスター・デバイスによって送られたデータを受信する段階と；
前記データに含まれる検査データを使うことによって前記データが正しいかどうかを判定する段階と；
前記データが正しくないと判定され、所定回数の再送信がすでに試行されている場合、前記データに含まれる前記検査データを、前記正しくないデータに合うよう計算された新しい検査データに変更する段階と；
前記データを前記リモート・デバイスに転送する段階とを含む、
方法。
〔態様３４〕
マスター・デバイスからリモート・デバイスへのデータ送信を管理する無線ブリッジング・デバイスであって：
前記マスター・デバイスによって送られたデータを受信する手段と；
前記データに含まれる検査データを使うことによって前記データが正しいかどうかを判定する手段と；
前記データが正しくないと判定され、所定回数の再送信がすでに試行されている場合、前記データに含まれる前記検査データを、前記正しくないデータに合うよう計算された新しい検査データに変更する手段と；
前記データを前記リモート・デバイスに転送する手段とを含む、
無線ブリッジング・デバイス。
【技術分野】
【０００１】
本発明は、無線ビデオ配信（distribution）システムにおける、セットトップボックス（STB）のようなマスター・デバイスからSTBのようなリモート・デバイスへの圧縮されたマルチメディア／ビデオの配信に関する。
【背景技術】
【０００２】
ケーブル・ビデオ・サービスのためには、個別のビデオ番組が典型的にはケーブル上で独自の専用周波数帯において放送される。家庭にあるいかなるテレビも、その周波数に同調することによって、いかなる個別の番組にも同調できる。より新しいテレビ・サービス（たとえば、衛星テレビ配信、インターネット・テレビ配信）の場合、番組は、マスターSTBにおいて「同調〔チューニング〕され」、次いでリモートSTBに家庭ネットワークを通じて配信される。多くの場合、家庭ネットワーク（または家庭配信システム）が設置される必要がある。有線（同軸ケーブル、撚り線対など）は信頼性が高いが、設置が高価になることがあり、家の所有者は設置業者が設置のために壁にドリルで穴を開けるのを好まないことがありうる。それを念頭に、業界では、ビデオ番組の再配信（redistribution）システム問題への無線ソリューションに関心が寄せられている。
【０００３】
たいていの既存の家庭内デジタル・ビデオ配信システムは、配信媒体としてイーサネット（登録商標）を使う。たいていのイーサネット（登録商標）設備は少なくとも1000Mbpsのリンク速度を使用し、トラフィックをアドレス指定されたデバイスを含む分枝にのみ選択的に送信するスイッチを使用するので、制御されたトラフィック速度をもつビデオ再配信システムにおいて使用されるときには、QoS問題はほとんどない。何らかの型のQoS保護なしで同じネットワーク上に一般的なIPデータ・トラフィックを送信したとしたら、イーサネット（登録商標）で問題が生じうる。現在のところ、イーサネット（登録商標）には一つの型の媒体アクセス制御（MAC）レベルQoSが利用可能である。それは優先度に基づく方式であり、仮想ローカル・エリア・ネットワーク（VLAN）タグ内のユーザー優先度フィールドを使用する。パラメータ化されたQoS（帯域幅要求、帯域幅保証、受け容れコントロールなど）の追加が、現在、IEEE802ネットワーク・ブリッジングについてのIEEE802.1サブ委員会内の作業部会の一つの主題である。しかしながら、イーサネット（登録商標）は、運用のために有線を必要とするという欠点があり、新たな配線のない設置技術を有することが望ましい。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
必要とされるのは、MACレベルのブリッジングを通じたイーサネット（登録商標）配信を置き換えることのできる無線配信システムである。多くの家庭ネットワークは、IPプロトコルを使ってビデオを配信しているが、多くの可能性がある。ビデオは、実時間転送プロトコル（RTP: real time transport protocol）によって規定されるUDPを使って送られる場合もあれば、ビデオがTCPを通じて配信される場合もある（たとえば、デジタル・リビング・ネットワーク・アライアンス（DLNA: Digital Living Network Alliance））。UDPは一方向の通信しか要求しない一方、TCPは双方向の通信を要求する。さらなる可能性もある。すでにイーサネット（登録商標）・インターフェースがあるときにはマスターおよびリモート・デバイス／STBにいかなる修正も必要としない（すなわち、帯域幅予約なし、無線ブリッジ・デバイスへのトーキング（talking）なしなど）家庭配信システムを有することが望ましいであろう。また、媒体が無線であり、したがって帯域制限された共通媒体であるので、MAC層がきわめて効率的であることも望ましい。そのため、本発明は、TDMA MAC方式を使う。TDMA MAC方式では、時間割り当てが割り振られて、各クライアント／リモート・デバイス（STB）に専用の帯域幅が与えられる。本稿での「／」の使用は、同じ構成要素についての代替名を表す。ビデオの正確なビットレートおよび他の特性が、マスターSTBにさえ、先験的にはわかっていないこともありうる。たとえビデオの正確なビットレートが先験的にわかっていたとしても、マスターSTBが無線デバイス（リモートSTBおよび／またはマスター・ブリッジング・ノード）と何らかの特別なまたは新たな通信をもつことを要求しないことが望ましい。マルチメディア・トラフィックはたいていマスター・デバイスから若干数のリモート・デバイスへの下りなので、オーバーヘッドをなくす機会がある。マルチメディア・ストリームを配信するのにTCPが使われるときは、上りトラフィックの大半はTCP ACKである。これらのTCP ACKのいくつかをなくすことは、送信されるオーバーヘッドの量を減らし、利用可能なBW〔帯域幅〕のより多くが実際にマルチメディア・ストリーム情報を搬送するために割かれることを許容する。
【０００５】
リモートSTB／デバイスからマスター・デバイス／STBへの戻り経路／上り経路に割り当てられる時間は、ビデオ配信のための下り経路には利用可能でない時間である。ビデオ配信が目標システムの主たる機能なので、TCP ACKによって引き起こされるオーバーヘッドを減らし、TCPスライディング・ウィンドウの負の効果を減らすことが望ましい。
【０００６】
IEEEにおいて現在標準化中であるIEEE802.11Nはビデオ配信のための手段として求められている。IEEE802.11Nの主題である技術に関してはいくつかの懸念がある。第一に、それは相変わらずCSMA（IEEE802.11）に基づいている。この型のMAC層は本来的に非効率的であり、QoS保証を提供しない。多くのMACレベルQoS向上がIEEE802.11Nに追加されているが、CSMAベースのMACがTDMA MACほど効率的になりうるとは考えにくい。QoS向上は、IEEE802.11Eからの優先度ベースのQoS、何らかの形のポーリングならびにMACプロトコル・データ単位（MPDU: MAC protocol data unit）およびMACサービス・データ単位（MSDU: MAC service data unit）の集積（aggregation）の追加を含む。これらの向上は、IEEE802.11ネットワークのリソースを管理することにおいて非常に有用でありうるが、無線家庭ビデオ配信システムのために必要または望ましいQoS保証をするものではない。ポーリングは、本発明を運用する基盤となるTDMA様のサービスを作り出すために使用できるが、ポーリング自身がMAC効率の妨げになる。MAC効率は、無線ネットワークについては、家庭のよりリモートな領域に利用可能な限られたリンク速度のため、より一層重要である。たいていの現行の無線ローカル・エリア・ネットワーク（WLAN: wireless local area network）は、共通伝送媒体（すなわち、同じ伝送周波数での無線スペクトル）を利用する。そのため、MACはその媒体を共有する機構を必要とする。なお、ひとたび送信機会がCSMAを介して獲得されるかポーリングを介して割り振られるかしたら、本発明が適用されうる。
【０００７】
いくつかのサービス・プロバイダーは、同軸ケーブル、電話線および／または電力線に基づく、新たな配線のない（no-new-wire）技術に目を向けている。多くの異なる可能性があり、そのほとんどは何らかの形の優先度またはパラメータ化されたQoSをもつ。これらの解決策に内在する問題は、たとえ同軸ケーブルまたは電話線がすでに家庭内にあったとしても、それでも、それらの線が正しいスポットに結線されていないことがあり、あるいは当該技術が扱うのが難しいトポロジーであることがありうるということである。これらの技術のほとんどはまた、他の家庭と帯域幅を共有していることもあり（たとえば、一つの電力用変圧器に最高4世帯のための電力線がある）、現在のところ信頼性を欠く。パラメータ化されたサービスのためには、STBは各リンクについて予約すべき帯域幅がどれくらいかを知る必要がある。ビデオ家庭配信システムについては、トラフィックは制御下にないことがあり、バースト的であることがあり、少なくとも部分的に未知である。
【０００８】
本発明は、上記で浮き彫りにした問題を解決する家庭マルチメディア・ストリーム配信システムを包含する。
【課題を解決するための手段】
【０００９】
たいていの現行の無線LANは、共通伝送媒体（すなわち、同じ伝送周波数での無線スペクトル）を利用する。そのため、媒体アクセス制御（MAC: media access control）層はその媒体を共有する機構を必要とする。たいていの機構は、キャリア検知多重アクセス（CSMA: carrier sense multiple access）MAC層に基づいている（たとえばIEEE802.11）。この型のMAC層は本来的に非効率的であり、サービス品質（QoS: quality of service）保証を提供しない。MAC効率は、無線ネットワークについては、家庭のよりリモートな領域に利用可能な限られたリンク速度のため、より一層重要である。非常に高い効率およびQoS保証を達成するため、本発明は、時分割多重アクセス（TDMA: time division multiple access）IEEE802.15.3bに基づいたMACを使用する。基本的なTDMA機能については標準的なMACが使用されるが、TCP ACKに起因するネットワーク負荷を減らす機能が追加される。
【００１０】
本発明が設計される対象となる典型的なシステムは、三つまでのクライアント／リモート・デバイスにインターネット・プロトコル（IP）ベースのビデオを配信するマスター・デバイスを含む。前記デバイスは、イーサネット（登録商標）／無線式のMACレベル・ブリッジ・デバイスであり、実際のビデオ同調およびレンダリングはイーサネット（登録商標）・ベースのSTBにおいて行われる。本発明はSTBを使って記載されるが、等価なまたは同様の機能をもついかなるデバイスも、そのデバイスの名前にかかわりなく、本発明によって考えられている。一般に、純粋なMACブリッジは、同じでも異なっていてもよいLANセグメントどうしを接続する。ブリッジによって相互接続された異なるLAN技術の集合はブリッジ・ローカル・エリア・ネットワーク（bridge local area network）として知られている。MACブリッジはMACサービス境界の下で動作し、MACブリッジ・サービス境界の上で使われるプロトコルにとっては、QoSの違いがある可能性を除いては、透明である。
【００１１】
本発明のシステムおよび方法は、三つのリモートSTBへの制約された通信（すなわち、すべての通信がマスターSTBへ／マスターSTBから）をもつ例示的な家庭ビデオ配信システムを使って記載される。本稿で記載される技法は、より一般的な家庭ネットワークに簡単に拡張できる。今日まで、三つの高精細度ビデオ・ストリームを家庭内の三つのリモート位置に配信できる無線家庭配信システムがないことを注意しておくべきであろう。本発明はビデオ・ストリーミングを含む例示的な実施形態を使って記載されるが、用語「ビデオ」はデジタル・オーディオのような他のストリーミング・メディアを含む「マルチメディア・ストリーム」を含むよう拡張できることはすぐ明白であるはずであることも注意しておくべきであろう。
【００１２】
すべてのトラフィックは、マスター・ブリッジング・デバイスへ／マスター・ブリッジング・デバイスからに制約される。マスター・ブリッジング・デバイスは、チャネル時間割り当て（CTAs: channel time allocations）を計画するビーコンを周期的に送信する。CTA内で各デバイスはそのデータを送信する。ビーコンに、次のビーコンまでのすべてのCTAを加えたものが、「スーパーフレーム（superframe）」と呼ばれ、図８に示されている。CTA1、2および3は下りトラフィック（たいていはビデオ）のためであり、CTA4、5および6は上りトラフィック（たいていはTCP受け取り確認（ACK）およびその他の管理／制御フレーム）のためである。マスター・ブリッジ・デバイスは、ビーコン送信に先立ってCTA割り当てを決定する。一般に、CTAは、マスター・デバイス（マスターSTB）によって決定されるか、リモート・デバイス（リモートSTB）によって要求される固定された時間スロットであることができる。すべての利用可能な時間割り当て／スロットをフルに利用することが望ましい。
【００１３】
本発明はまた、ビデオを搬送するプロトコルを含むビデオ・システム・ミドルウェアにいかなる変更も要求しないという利点もある。
【００１４】
上記の応用において、ビデオはTCPを通じて配信される。TCPは、プロトコル・スタックにおいてIPの上に層として重ねられる、接続指向の双方向プロトコルである。TCP ACKはインターネットを通じた伝送のために有用であるが、本発明におけるようなビデオ・ストリーミングにおける使用のための信頼できるLANにおけるその有用性には疑問がある。しかしながら、TCPは、ブリッジング・デバイスにおいてミドルウェアとして利用可能なものであり、既存のミドルウェアを変更するのではなく、増強し、向上させることが望ましい。低い物理層（PHY）パケット誤り率およびMAC層における再送信を通じて、高い信頼性が達成できる。リモートSTBによって返されるTCP ACKによって引き起こされるオーバーヘッドおよびTCPスライディング・ウィンドウに対する負の効果を減らすことも望ましい。
【００１５】
本稿に記載されるのは、TCP ACKによって引き起こされるオーバーヘッドを減らす三つの方法である。最初の二つの方法が組み合わされて第三の方法を形成する。（記述の目的のための）本発明の例示的な実施形態はTDMA MACに基づいているので、リモートSTBからマスターSTBへの送信は、スーパーフレームの長さに依存して5または10msec毎にバルクで起こる。この送信のために、リモートSTBは、その送信待ち行列からパケットを取り出し、送信のための一連のフレーム（または集積されたフレーム［aggregated frames］）に組み立てる。この例示的な実施形態では、このトラフィックのすべては、マスターSTBを宛先とされている。第一の方法については、リモート・ブリッジ・デバイスは、その送信待ち行列内のフレームのIPおよびTCPヘッダを調べ、ACKのどれを消去できるかを決定する。フレームの内容に依存して、いくつかのTCP ACKが一つのTCP ACKで置き換えられる。これは、より短いCTAがリモート・デバイス／STBに割り当てられることを許容し、マスター・デバイス／STBに割り当てられるCTAのためにより多くの時間を、よって下りビデオのために割り当てられるより多くの時間を残す。
【００１６】
第二の方法では、マスターSTBに戻るTCP ACKがマスター・ブリッジ・デバイスによって生成される。この場合、マスターSTBはだまされて、パケットがすでにリモートSTBによって受信されたと思い込まされる。マスター・ブリッジ・デバイスはTCPスライディング・ウィンドウ、TCPシーケンス番号、最大セグメント・サイズ（MSS: maximum segment size）およびそれ自身の送信待ち行列を追跡する。TCPフレームがマスターSTBから頻繁に到着しすぎる場合、マスター・ブリッジ・デバイスは、待ち行列レベルが下がるまでTCP ACKを差し控える。これはフロー制御の一つの形である。マスター・ブリッジ・デバイスはまた、リモートSTBから実際に返されるTCP ACKを途中で捕らえ、それがマスターSTBに転送されないようにする。あるいはまた、TCP ACKはリモート・ブリッジ・デバイスによって途中で捕らえられることもでき、必要ならマスター・ブリッジ・デバイスに要約レポートが送られることもできる。リモート・ブリッジ・デバイスが途中で捕らえられたTCP ACKを破棄することも可能である。この第二の方法は、オーバーヘッドを減らすことに加えて、小さなTCPスライディング・ウィンドウの負の効果を減らすことができるという利点がある。
【００１７】
第三の方法は、上記の二つの方法を組み合わせる。TCP ACKは、第二の方法におけるように、ブリッジ・デバイス（マスターまたはリモート）の一つによってローカルに生成されるが、リモートSTBによって返されるTCP ACKは第一の方法に記載されるように組み合わされる。これらの方法は、MAC、IPおよびTCP層／機能に関わり、ブリッジ／MAC層に存在するので、層横断型（crosslayering）と考えることができる。その恩恵は、STBには何の変更も要求せずに、TCPを通じてストリーミングする負の効果を減らすことである。ブリッジ・デバイスは限られた量のTCP/IP処理を識別し、実行する。一般的なデータ・ネットワーク・トラフィックについて、業界はだいたいのところ、層のすべてを別個かつ独立に保ってきた。MAC層は通例、そのフレームのペイロードにおいて搬送されているデータ・トラフィックの種別を意識しない。たとえば、家庭用イーサネット（登録商標）・スイッチは、TCPやIPについて何の知識ももたず、実際、通例、何のセットアップも必要としない。ブリッジはネットワークに対して透明であり、MAC層において動作する。いかなる配信システムのいかなる従来技術の方法も、MAC／ブリッジ層の関与を通じてTCP ACKを減らそうとしたことはない。
【００１８】
受け取り確認を管理する方法および装置であって、データ・パケットおよび受け取り確認をある接続と同定し、受け取り確認のどれが消去できるかを判定し、消去できる受け取り確認を単一の受け取り確認で置き換え、該単一の受け取り確認を送信することを含むものが記載される。受け取り確認を管理するための代替的な方法および装置であって、データ・セグメントを受信し、接続を追跡し（keep track of）、所定数のチャネル時間割り当てのための十分なデータ・セグメントがあるかどうかを判定し、前記所定数のチャネル時間割り当てのための十分なデータ・セグメントがある場合に、選択された接続についての受け取り確認を生成することを含むものが記載される。上記二つの方法の組み合わせであるさらにもう一つの代替的な方法も記載される。
【００１９】
本発明は、以下の詳細な記述を付属の図面との関連で読むことから最もよく理解される。図面は以下の図を含む。
【図面の簡単な説明】
【００２０】
【図１】本発明の原理に基づく例示的な無線家庭ビデオ配信システムを示す図である。
【図２】MACレベル・ブリッジを示す図である。
【図３】一般的な無線ブリッジを示す図である。
【図４】本発明のある例示的な実施形態における、無線家庭ビデオ配信に好適な、制約された経路をもつ無線ブリッジを示す図である。
【図５】マスターSTBおよび無線MACブリッジのサーバー側のソフトウェアのブロック図（論理構造）を示す図である。
【図６】リモート／クライアントSTBおよび無線MACブリッジのクライアント側のソフトウェアのブロック図（論理構造）を示す図である。
【図７】本発明の原理に基づいてDTAがどのように使用されるかを示す、無線MACブリッジのブロック図である。
【図８】本発明に基づくスーパーフレームを描いた図である。
【図９】ビデオ・サーバー（マスターSTB）に接続されたPNCのための高レベルの送信パケット流れ図である。
【図１０】ビデオ・サーバー（マスターSTB）に接続されたPNCのための高レベルの受信パケット流れ図である。
【図１１】ビデオ・クライアント（リモートSTB）に接続されたDEV-xのための高レベルの送信パケット流れ図である。
【図１２】ビデオ・クライアント（リモートSTB）に接続されたDEV-xのための高レベルの受信パケット流れ図である。
【図１３】単一の下りCTA（PNCからDEV-x）を描いた図である。
【図１４】スーパーMAC（MACフレームの非標準的な集積体）および物理フレーム・フォーマットを描いた図である。
【図１５】単一の上りCTA（DEV-xからPNC）を描いた図である。
【図１６】TCP/IPカプセル化を描いた図である。
【図１７】IPヘッダを描いた図である。
【図１８】TCPヘッダを描いた図である。
【図１９】TCPスライディング・ウィンドウ動作を描いた図である。
【図２０】リモート・ブリッジング・デバイスにおける処理の例示的な実施形態の高レベルのフローチャートである。
【図２１】マスター・ブリッジング・デバイスにおける処理の第二の例示的な実施形態の高レベルの送信フローチャートである。
【図２２】マスター・ブリッジング・デバイスにおけるリモート受け取り確認（ACK: acknowledgement）転送の高レベルのフローチャートである。
【図２３】リモート・ブリッジング・デバイスにおける前記第二の実施形態の高レベルのフローチャートである。
【発明を実施するための形態】
【００２１】
本発明は、TDMAサービスをサポートするIEEE802.15.3b MACを出発点とする（スーパーフレームの先頭におけるビーコンおよびスーパーフレーム内の諸伝送時間割り当て）。IEEE802.15bは、パーソナル・ネットワークとなるべく設計されたものであり、したがって、LANや都市圏ネットワーク（MAN）のために設計された技術よりも「軽い」。他のTDMA MACもあり、使うことができる（たとえばIEEE802.16）が、従来技術においては、純粋にMAC層にとって利用可能なトラフィック特性に基づいて動的にCTA長さを割り当てる試みはされていない。IEEE802.16は無線都市圏ネットワーク（WMAN: wireless metropolitan area network）のために設計されたものであり、サービス加入者へのインターネット配信のために使用される。IEEE802.16はサービス・プロバイダーが自らのネットワークをカスタマイズすることを許容する多くの機能およびオプションを含んでいる。本発明の例示的な実施形態はIEEE802.15.3bに関して記載されるが、その概念はIEEE802.16の実施形態にも等しく適用できる。パースするヘッダが若干多くなる。
【００２２】
CTAを設定するときに考慮されなければならないTCPのいくつかの特徴がある。TCPは、32ビットのシーケンス番号および要求番号ならびに16ビットのスライディング・ウィンドウ長さフィールドを利用する転送プロトコルである。これら三つの数は、「停止して待機（Stop-and-Wait）」または「N個戻る（Go-Back-N）」ARQ〔自動再送要求〕エラー修復方式を実装するために使われる。送信待ち行列内および送信される過程にあるTCPパケットは「ネットワーク内にある」ので、TCPウィンドウは、それらのパケットが未決（outstanding）であることを許容するために宛先によって十分大きく設定されなければならない。一般に、MACレベルのブリッジング・デバイスはそのウィンドウのサイズを設定することに対して制御をもたないが、CTAおよびスーパーフレーム長さの初期選択は、問題を最小化するのに十分短く選ぶことができる。スーパーフレームの長さは、変化するTCPウィンドウ・サイズを扱えるよう、調節可能（または適応可能）にされてもよい。
【００２３】
10msecのスーパーフレームについては、約19個の1400バイトTCPパケットが10msec毎に送信される。これで26,600バイトになる。例示的な実施形態の以下の記述の目的のために、約165キロバイトの送信バッファ待ち行列を選んだ。TCPウィンドウ・サイズは64キロバイトを超える未決データを許容しないので、TCPトラフィックについては送信バッファ待ち行列は決してオーバーフローしない。ウィンドウが、CTAが完全に満たされることすら許容しないほど十分小さいことさえありうる。このため、短いスーパーフレーム（5msec）で始めるほうがよい。すると、送信バッファ待ち行列は、少なくとも単一のTCPセッションを扱うことができるためには、51キロバイトより大きい必要はない。しかしながら、UDPを通じて送られるビデオの場合に紛失パケットを回避するため、165キロバイトの送信バッファ待ち行列を選んだ。
【００２４】
ARQエラー修復方式の数学的モデルは待ち行列理論の分野内で開発され、必要ならTCPパフォーマンスをより精密にモデル化するために使用できることを注意しておく。ウィンドウ・サイズは、他のものがCTA内にある間、いくつかに対する十分な未決TCPパケットが待ち行列内にあることを許容するために十分大きいと想定される。5回までの再送信が許される例示的な実施形態では、CTAは、そのデータの約5倍が送信バッファ待ち行列内に逗留することができるほど十分小さいべきである。5msecのスーパーフレームは、最大サイズのTCPウィンドウが使用されたら、これを達成するであろう。
【００２５】
初期アプリケーションはTCPを使ってビデオをストリーミングすることになる一方、一般的な意味における良好なパフォーマンスを保証する唯一の方法がトラフィック・パターンに適応することを許容することであるよう、実装の十分な不確定さがある。
【００２６】
リアルタイムの、長さが柔軟なスーパーフレーム構築が可能である。これは、システムの堅牢性を増し、システム・パフォーマンスを改善すると考えられる。スーパーフレームの長さは、例示的な実施形態において三つの個別ビデオ待ち行列の長さ、下り伝送チャネル条件および他の任意の可能な点に依存しうる。長さが柔軟なスーパーフレームの場合、ビーコンは、後続のCTAの長さをブロードキャストしなければならず、各リモートSTBは該リモートSTBに専用のCTAの長さについて通知される。
【００２７】
上記したように、TCP受信ウィンドウがCTAの長さに対して十分小さいと、サーバーは前のパケットからのACKを受信するまで次のパケットを放出せず、ソースにおけるストリームを事実上遅くすることがありうる。そのレートは、所望されるリアルタイムのストリーミング・レートを下回ることもありうる。これを避けるため、本発明は、この飢餓条件につながらないCTAサイズを選択する。適正なレートを維持するために、CTAは、サイズを小さくされれば、より頻繁に生起する必要がある。これは、スーパーフレームのサイズを小さくすることによって、あるいはスーパーフレーム当たりそのリンクに二つ以上のCTAを割り当てることによって起こる。
【００２８】
さらに上記したように、TCPウィンドウ・サイズについての不確定さは、スーパーフレーム長さが変化する可能性につながる。これは、MAC層では、TCPヘッダを見ることに基づいてスーパーフレーム変化をトリガーすることによって、あるいはより適正には、送信バッファ待ち行列をモニタリングして送信バッファ待ち行列があまりにしばしば空になってCTAが送信すべきデータが足りない状態になる場合にはスーパーフレームを短くすることによってできる。例示的な実施形態では、初期には、固定されたスーパーフレーム長さが使用された。固定されたスーパーフレーム長さが与えられて、トラフィック特性に適応するためにCTA長さを修正することが調査される。その場合、たいていTCP ACKのために意図されたCTAにどのくらいの時間を割り当てるべきかのいくらかの不確定性がある。というのも、STB中のTCPスタックは複数のACKをグループ化することがあり、および／またはデータを含むパケットのヘッダにACKを含むことがあるからである。
【００２９】
最低限、どんな所与の送信待ち行列の平均出力パケット・レートも、平均パケット到着レートより下に保たれねばならないことはわかっている。そうでなければ、待ち行列はオーバーフローする。しかしながら、たとえ平均到着レートが平均出発レートより低くても、入力ストリームの統計的性質のため、入力レートが一時的に出力レートを超えることはありうる。平均出力レートを平均入力レートより高く保つことは、必要ではあるが、十分ではない。IPトラフィックの特定性の欠如のため、システムを適応的にすることが最善である。
【００３０】
適応を許容するために、全スーパーフレームについての待ち行列情報が記録される。待ち行列情報は、待ち行列のサイズ（固定なら送る必要はない）、待ち行列中のパケット数、待ち行列中のパケットの平均長さおよび入力パケット・レートの推定値を含む。この情報が、各DEVまたはリモートSTBへの信頼性のあるリンク速度についての情報とともに、適応アルゴリズムへの入力として使われる。適応アルゴリズムの目標は、パケットを落とさないこと、そしてその目標に達するような仕方でスーパーフレーム時間をCTAに分配することである。適応アルゴリズムは、各待ち行列中の期待されるパケット数を最小化しようと（よって遅延を最小にしようと）、および／または待ち行列がオーバーフローする確率を最小にしようと努める。待ち行列レベルをモニタリングすることによって、MACはスーパーフレームごとに、最も満たされている待ち行列に送信優先を与えるよう、CTAを調節しうる。
【００３１】
本発明は、圧縮されたビデオをマスターSTBからリモートSTBに配信する無線ビデオ・サービス配信システムのMAC層およびブリッジング層に関する。本システムはIEEE802.15.3b TDMA MACを部分的に利用し、したがってその規格からの用語をいくらか使う。その技術をSTBに組み込んだ例示的なシステムを図１に示す。
【００３２】
マスターSTB１０５は、高度テレビ方式委員会（ATSC: Advanced Television Systems Committee）アンテナ（デジタル・テレビ）、衛星アンテナおよび広域ネットワーク（WAN）モデムを含む多様なビデオ・ソースから入力を受信する。マスターSTBは、顧客スイッチに接続された、コンポジット全米テレビ方式委員会（NTSC: National Television Standards Committee）ビデオ・ディスプレイ、高精細度マルチメディア・インターフェース（HDMI: High Definition Multi-media Interface）コンポーネント・ビデオ・ディスプレイおよびローカル・エリア・ネットワーク（LAN）を含むビデオ・ディスプレイ１１０（たとえばテレビ）に出力を提供する。マスターSTBは5つの衛星チューナーを有する（電子番組ガイド（EPG: electronic program guide）チューナー、メイン・チューナー、三つのリモート・チューナーおよびレコーディング・チューナー）。メイン・チューナーは、マスターSTBと通信しているディスプレイのユーザーが望む番組に同調するためのものである。三つのリモート・チューナーは、リモート・ディスプレイの各ユーザーが望む番組に同調するためのものである。EPGチューナーは、電子番組ガイドに同調するためのものである。レコーディング・チューナーは、マスターSTBと通信しているディスプレイのユーザーが、メイン衛星チューナーによって同調されている番組を視聴している間に記録したい番組に同調するためのものである。マスターSTBは二つのATSCチューナーを有する―メイン・チューナーおよびレコーディング・チューナーである。メイン・チューナーは、マスターSTBと通信しているディスプレイのユーザーが望む番組に同調するためのものである。レコーディング・チューナーは、マスターSTBと通信しているディスプレイのユーザーが、メインATSCチューナーによって同調されている番組を視聴している間に記録したい番組に同調するためのものである。マスターSTBは、デマルチプレクサ（多重分離器）、パーソナル・ビデオ・レコーダ（PVR）、リモコン装置とともに使用するための赤外（IR）受信器、衛星／ATSCデコーダおよび無線ハブをも有する。マスターSTB１０５は各リモートSTBに約20Mbpsでビデオを送信できる。マスターSTB１０５は衛星ベンダーのIPトラフィックを各リモートSTBと交換できる。マスターSTB１０５は、各リモートSTBと制御情報を交換できる。
【００３３】
マスターSTBは三つのリモートSTB（リモートSTB1 １１５、リモートSTB2 １２５およびリモートSTB3 １３５）と通信状態にある。リモートSTB1 １１５はビデオ・ディスプレイ１２０と通信状態にある。リモートSTB2 １２５はビデオ・ディスプレイ１３０と通信状態にある。リモートSTB3はビデオ・ディスプレイ１４０と通信状態にある。各リモートSTBの構成は同様なので、リモートSTB1についてのみ述べる。リモートSTB1 １１５は衛星／ATSCデコーダ、リモコン装置とともに使うためのIR受信器および無線ステーションを有する。リモートSTB1 １１５は、マスターSTB１０５から約20Mbpsでビデオを受信できる。リモートSTB1は、自分自身とマスターSTB1 １０５との間で衛星ベンダーのIPトラフィックを交換できる。リモートSTB1 １１５は、マスターSTB１０５と制御情報を交換できる。
【００３４】
本発明は、MACレベルの無線ブリッジとして構築される（図２参照）。一般に、MACブリッジは、同じでも異なっていてもよいLANセグメントどうしを接続する。ブリッジによって相互接続された異なるLAN技術の集まりはブリッジ・ローカル・エリア・ネットワークとして知られる。MACブリッジはMACサービス境界の下で動作し、MACブリッジ・サービス境界の上で使われるプロトコルにとっては、QoSの違いがある可能性を除いては、透明である。MACサービス・ユーザーはMACサービス境界（MAC services boundary）の上にあり、MACサービス・プロバイダーはMACサービス境界の下にある。MAC層ブリッジは、各LANセグメント／コンポーネントとのインターフェースをもつためにリレーを含む。
【００３５】
一般的な無線ブリッジが図３に示されている。無線ブリッジ３０５はイーサネット（登録商標）（Ethernet（登録商標））接続を介してサーバーと通信する。二つのサーバー３１０、３１５が示されている。無線ブリッジ３０５は、クライアントともイーサネット（登録商標）接続を介して通信する。四つのクライアント３２０、３２５、３３０、３３５が示されている。この一般的な無線ブリッジ内にはDEV0がある。これはピコネット・コントローラ（PNC: piconet controller）３４０である。PNC３４０は複数のデバイスと無線で通信する。三つのデバイスDEV1 ３４５、DEV2 ３５０およびDEV3 ３５５が示されている。DEV0/PNC ３４０はサーバー３１０、３１５と通信する。DEV1 ３４５はクライアント３２０と通信する。DEV2 ３５０はクライアント３２５と通信する。DEV3 ３５５はクライアント３３０、３３５と通信する。
【００３６】
しかしながら、本発明の例示的な実施形態は、無線家庭ビデオ・サービス配信用途に適する経路を制約している。可能なデータ経路は図４で破線で示されている。無線ブリッジ４０５はマスターSTB４１０と無線で通信する。無線ブリッジ４０５はリモートSTB４１５、４２０、４２５とも無線で通信する。無線ブリッジ４０５は内部的には図２に示されるような構成である。すべてのトラフィックはマスターSTB４１０に行く、またはマスターSTB４１０からくる。
【００３７】
図５はサーバー側（マスターSTBおよびブリッジ・デバイス）のソフトウェア・アーキテクチャを示す。マスター・ブリッジ・デバイスはIEEE802.15.3に記載されるようなピコネット・コントローラ（PNC）でもあることを注意しておく。マスターSTB５０５はマスターSTB５０５内のミドルウェア・ビデオ・サーバー・アプリケーション５１０を有する。マルチメディア・ストリーム・ミドルウェア５１５は媒体QoS制御５２０およびデバイス・ドライバ５２５の両方とインターフェースをもつ。マルチメディア・ストリーム・ミドルウェア５１５はビデオ・データをデバイス・ドライバ５２５に転送し、媒体QoS制御ミドルウェア５２０と制御情報を交換する。媒体QoS制御ミドルウェアはデバイス・ドライバ５２５と制御情報を交換する。デバイス・ドライバ５２５は主としてビデオ・データをネットワーク・インターフェース（IEEE802.3）５３０と交換する。デバイス・ドライバ５２５内には、媒体ストリーム・ミドルウェア５１５からビデオ・データおよび制御情報を受信して媒体QoS制御ミドルウェア５２０と情報を交換するポータブル・オペレーティング・システム・ユニックス（POSIX: portable operating system Unix（登録商標））ドライバ５３５のサブセットがある。POSIXドライバのサブセットは、TCP/IP５４０および媒体ストリーム・プロトコル５４５およびQoS管理および制御５５０とのスタックにあるQoSミドルウェアと情報を交換する。PNC５５５は、無線MACビデオ・サーバー・ブリッジ・アプリケーション５６０を有し、この無線MACビデオ・サーバー・ブリッジ・アプリケーション５６０は、複数のソフトウェア・モジュールを含むソフトウェア５６５と制御情報を交換する。ソフトウェア５６５は無線電波インターフェース５７０およびIEEE802.3ドライバ５７５とビデオ・データおよび制御情報を交換する。IEEE802.3ドライバは主としてIEEE802.3ネットワーク・インターフェース５８０とビデオ・データを交換する。IEEE802.3ネットワーク・インターフェース５８０はIEEE802.3ネットワーク・インターフェース５３０とインターフェースをもち、そのビデオ情報を交換する。ソフトウェア５６５はIEEE802.1Dブリッジング・モジュールを含むいくつかのソフトウェア・コンポーネントを含み、このIEEE802.1Dブリッジング・モジュールは、無線デバイス管理エンティティ（DME: device management entity）およびIEEE802.2フレーム収束サブ層（FCSL: frame convergence sublayer）サービス・アクセス・ポイント（SAP: service access point）上に層として重ねられる。無線MACビデオ・サーバー・ブリッジ・アプリケーション５６０は無線DME管理SAPとインターフェースをもつ。無線DME管理SAPおよび無線DMEおよびIEEE802.2 FCSL SAPはいずれもIEEE802.2 FCSL DMEの上に層として重ねられる。IEEE802.2FCSL DMEはIEEE802.15.3b PNCの機能を実行し、QoSスケジューリングを行い、ブリッジ機能性を管理する。IEEE802.2 FCSL DMEはIEEE802.15.3b MAC SAPおよびIEEE802.15.3b MAC層管理エンティティ（MLME: MAC layer management entity） SAPの上に層として重ねられる。IEEE802.15.3b MAC層管理エンティティ（MLME）SAPはIEEE802.15.3b MLME上に層として重ねられ、このIEEE802.15.3b MLMEは物理層管理エンティティ（PLME: physical layer management entity）の上に層として重ねられる。IEEE802.15.3b MAC SAPはIEEE802.15.3b MACサブ層の上に層として重ねられ、このIEEE802.15.3b MACサブ層は無線物理SAPの上に層として重ねられる。IEEE802.15.3b MAC SAPは無線物理層の上に層として重ねられる。無線物理層管理エンティティ（PLME）SAPは無線物理層PLMEの上に層として重ねられる。無線PLMEは無線物理層と通信する。IEEE802.15.3b MACサブ層はIEEE802.15.3b MLMEと通信する。無線物理層および無線PLMEはビデオ・データおよび制御情報をそれぞれ無線電波インターフェースと交換する。
【００３８】
図６は、クライアント側（リモートSTBおよびブリッジ・デバイス）のSW〔ソフトウェア〕アーキテクチャを示す。本発明はブリッジ・デバイス内にあるが、コンテキストのためにSTBが示されていることを注意しておく。リモート／クライアント・ブリッジ・デバイスもIEEE802.15.3に記載されるようなDEV-x（非PNCデバイス）であることを注意しておく。リモート／クライアントSTB６０５はリモート／クライアントSTB６０５内のミドルウェア・ビデオ・クライアント・アプリケーション６１０を有する。メディア・ストリーム・ミドルウェア６１５は媒体QoS制御６２０およびデバイス・ドライバ６２５の両方とインターフェースをもつ。メディア・ストリーム・ミドルウェア６１５はビデオ・データをデバイス・ドライバ６２５に受け容れ、媒体QoS制御ミドルウェア６２０と制御情報を交換する。媒体QoS制御ミドルウェアはデバイス・ドライバと制御情報を交換する。デバイス・ドライバ６２５はたいていビデオ・データをネットワーク・インターフェース（IEEE802.3）６３０と交換する。デバイス・ドライバ６２５内には、媒体ストリーム・ミドルウェア６１５に主としてビデオ・データを送って媒体QoS制御ミドルウェア６２０と情報を交換するPOSIXドライバ６３５のサブセットがある。POSIXドライバのサブセットは、TCP/IP６４０および媒体ストリーム・プロトコル５４５およびQoS管理および制御６５０とのスタックにあるQoSミドルウェアと情報を交換する。Dev-x６５５は、無線MACビデオ・クライアント・ブリッジ・アプリケーション６６０を有し、この無線MACビデオ・クライアント・ブリッジ・アプリケーション６６０は、複数のソフトウェア・モジュールを含むソフトウェア６６５とビデオ・データおよび制御情報を交換する。ソフトウェア６６５は無線電波インターフェース６７０およびIEEE802.3ドライバ６７５とビデオ・データおよび制御情報を交換する。IEEE802.3ドライバは主としてIEEE802.3ネットワーク・インターフェース６８０とビデオ・データを交換する。IEEE802.3ネットワーク・インターフェース６８０はIEEE802.3ネットワーク・インターフェース６３０とインターフェースをもち、そのビデオ・データを交換する。ソフトウェア６６５はIEEE802.1Dブリッジング・モジュールを含むいくつかのソフトウェア・コンポーネントを含み、このIEEE802.1Dブリッジング・モジュールはDMEおよびIEEE802.2 FCSL SAP上に層として重ねられる。無線MACビデオ・クライアント・ブリッジ・アプリケーション６６０は無線DME管理SAPとインターフェースをもつ。無線DME管理SAPおよび無線DMEおよびIEEE802.2 FCSL SAPはいずれもIEEE802.2 FCSL DMEの上に層として重ねられ、このIEEE802.2 FCSL DMEはIEEE802.15.3b DEV-xの機能を実行し、QoSスケジューリングのために状態をPNCに送り、ブリッジ機能性を管理する。IEEE802.2 FCSL DMEはIEEE802.15.3b MAC SAPおよびIEEE802.15.3b MLME SAPの上に層として重ねられる。IEEE802.15.3b MLME SAPはIEEE802.15.3b MLME上に層として重ねられ、このIEEE802.15.3b MLMEは物理層管理エンティティ（PLME）の上に層として重ねられる。IEEE802.15.3b MAC SAPはIEEE802.15.3b MACサブ層の上に層として重ねられ、このIEEE802.15.3b MACサブ層は無線物理SAPの上に層として重ねられる。IEEE802.15.3b MAC SAPは無線物理層の上に層として重ねられる。無線PLME SAPは無線物理層PLMEの上に層として重ねられる。無線PLMEは無線物理層と通信する。IEEE802.15.3b MACサブ層はIEEE802.15.3b MLMEと通信する。無線物理層および無線PLMEはビデオ・データおよび制御情報を無線電波インターフェースと交換する。ソフトウェア６６５および６６０が、CTAについての情報をもつビーコン信号を受信し、それらの下りCTA内の再配信されたビデオ／メディアを受信し、適切な上りCTAにおいてMACレベルのACKまたはNAKを送信する。これらのACKは、TCPが使われるときにビデオ・クライアントにおいて生成されうるTCP ACKとは異なることを注意しておく。
【００３９】
ここで図７を参照する。図７は、本発明の原理に基づく無線MACブリッジのブロック図である。PNC７０５は、割り当てられたCTAにおいてリモートSTB７１０、７１５、７２０へデータ／情報を送信し、リモートSTB７１０、７１５、７２０からデータ／情報を受信する。マスター・デバイス７０５は、チャネル時間割り当て（CTA）を取り決めるビーコンを周期的に送信する。CTA内で各デバイスはそのデータを送信する。CTA１、２および３は下りトラフィック（たいていはビデオ）のためである。CTA４、５および６は上りトラフィック（たいていはTCP ACKおよび他の管理フレーム）のためである。
【００４０】
図８にスーパーフレームが示されている。マスター・デバイスはビーコン送信に先立って諸CTAを決定する。一般に、CTAは、マスター・デバイス／PNCによって決定されるかリモート・デバイス／STBによって要求される固定した時間スロットであることができる。具体的には、IEEE802.15.3bについては、規格が、リモートSTB／デバイスが「CTReq」メッセージをPNCに送ることによって帯域幅を要求する（request）ことを規定している。しかしながら、どんなCTA時間が要求または設定されても、デバイスのいずれも真にIPトラフィック特性の全てを先験的に知ることはない。トラフィックは、UDP（ACK返信なし）に基づくことができ、あるいはTCPに基づくこともできる。時によっては、トラフィックのすべてが下りであることができ（非対称）、いくらか対称的であるときもある。トラフィックの流れを最適にするよう諸CTA内の時間の量を適応させることによって、すべての利用可能な時間をフルに利用することが望ましい。スーパーフレームの左端の部分が最初に空中に送信され、スーパーフレームの右端の部分が最後に空中に送信される。ビーコンに続いて、CTAが送信されるが、下りCTAが先に送信され、その後上りCTAが送信される順序となる。本発明のコンテキストにおけるスーパーフレームは、5msecから10msecまでの間で変わりうる。
【００４１】
マスターSTBに接続されているPNCについての例示的なパケット流れ図が図９および図１０に示されている。リモートSTBに接続されているDEV-x（すなわち非PNCデバイス）についての例示的なパケット流れ図が図１１および図１２に示されている。上記したように、例示的な高精細度ビデオ配信システムの無線MACブリッジは制約されたブリッジとして作用する。
【００４２】
ここで図９を参照すると、PNCはイーサネット（登録商標）・ビデオ・データ・フレームをイーサネット（登録商標）・ポート９０５で受信する（たいていはビデオ）。PNCはスーパーフレームおよび各CTAの長さを決定する。PNCは、宛先MACアドレスに依存してフレームを適正な送信待ち行列９１０ａ、９１０ｂ、９１０ｃに入れる。PNCは、IEEE802.1Dに記載されるようにあふれ（flooding）を通じてMACアドレスを学習することができ、あるいはフィルタリング／ルーティング・テーブルが手動で埋められることができる。図の乱雑を減らす目的で、本発明は（各DEV-x／リモートSTB用に定められた）送信ポート当たり一つの待ち行列しかないと想定して記述される。すなわち、各優先度グループ（priority group）について一つの待ち行列である。イーサネット（登録商標）・ビデオ・データ・フレームは待ち行列に分けられる。例示的な実施形態では、待ち行列はそれぞれ165キロバイトであり、スーパーフレームは5msecから10msecまでの長さである。待ち行列からのビデオ・データ・フレームはソフトウェア・モジュール９１５に転送され、ソフトウェア・モジュール９１５がイーサネット（登録商標）・ビデオ・データ・フレームを、優先度マッピング、フレーム検査シーケンス（FCS: frame check sequence）、フラグメンテーションおよびヘッダ訂正コード（HCC: header correction code）計算を含むIEEE802.15.3b MACフレームへの変換を行う。ソフトウェア・モジュール９１５は、受信したイーサネット（登録商標）・ビデオ・データ・フレームを処理するための転送テーブル（forwarding tables）およびサービス・フロー（service flows）をデータ記憶ユニット９２０から受信する。ソフトウェア・モジュール９１５は、送信MACサービス・データ単位（MSDU: transmit MAC service data unit）を記憶するバッファ９２５と通信する。ソフトウェア・モジュール９３０は、スーパーフレームを構築するために、MACフレームをソフトウェア・モジュール９１５から要求する。ソフトウェア・モジュール９１５は複数のMSDUをソフトウェア・モジュール９３０に転送する。ソフトウェア・モジュール９３０は、スーパーフレームを構築するために、データ記憶ユニット９３５から物理的な特性およびパラメータを、バッファ９４０から直前のサービス・フレームからのMSDU受け取り確認（ACK）を受信する。データ記憶ユニット９４５は、CTA長が変えられるようローカルおよびリモートのDEV（STB）待ち行列長さとして記憶されているMAC帯域幅管理コマンドを、直前のスーパーフレームから受信する。この情報はMAC帯域幅管理エンティティ９５０に転送され、このMAC帯域幅管理エンティティ９５０は、スーパーフレームの構築をさらに支援するため、CTA長をソフトウェア・モジュール９３０に転送する。ソフトウェア・モジュール９３０は、直前のフレームから再送信されるべきMSDUをも、スーパーフレーム再送信バッファ９５５から受信する。このスーパーフレーム再送信バッファ９５５は、各リモートSTB MACプロトコル・データ単位（MPDU）において複数のMSDUを記憶しており、受け取り確認がされたMSDUを破棄する。ソフトウェア・モジュール９３０によって構築されたスーパーフレームはスーパーフレーム構築バッファ９６０に記憶される。ソフトウェア・モジュール９３０によって構築されたスーパーフレームは下りMPDUおよび上り時間を含む。スーパーフレーム構築バッファ９６０は構築されたスーパーフレームを、各リモートSTB MPDU内の複数MSDUの形で、スーパーフレーム送信バッファ９６５に転送する。スーパーフレーム送信バッファ９６５はスーパーフレーム構築バッファから受信したスーパーフレームを、スーパーフレーム再送信バッファ９５５に転送する。スーパーフレーム送信バッファ９６５は完全なMPDUをソフトウェア・モジュール９７０に転送する。ソフトウェア・モジュールは、遅延されたACKを受信期間の間にリモートSTBから受信し、時間クロック９７５からタイミング情報を受信する。ソフトウェア・モジュール９７０は複数のMSDUを各MPDUにまとめ、それらを送信のために物理層モジュール９８０に転送する。ソフトウェア・モジュール９７０は、ビーコン内のタイミングに基づくタイミングを使い、送信データ、送信データ・レート、送信長、送信電力レベルおよび送信アンテナ制御を物理層モジュール９８０に転送し、この物理層モジュール９８０が物理データ・プロトコル単位（PPDU: physical data protocol unit）をPNCから指定されたリモートSTBに送信する。
【００４３】
図１０は受信パケットの流れを描いているので、記述は図の右側から始まって進行する。PPDUが物理層ソフトウェア・モジュール１００５で受信される。この物理層ソフトウェア・モジュール１００５は時間クロック１０１０からも入力を受信する。物理層ソフトウェア・モジュールは受信したデータ、長さ、リンク品質指標（LQI: link quality indicator）、受信信号強度指標（RSSI: received signal strength indicator）およびPHY受信エラーをソフトウェア・モジュール１０１５に転送する。ソフトウェア・モジュール１０１５は、タイミング・ビーコンに基づくタイミングを使って、PPDUを、MSDUを集積したものであるMPDUに分解し、MPDUをソフトウェア・モジュール１０２０に転送する。ソフトウェア・モジュール１０２０はHCC計算を実行し、完全なMSDUフレームまたはフラグメントを単離し、フレーム検査シーケンスを処理し、正しく受信されたMSDUを追跡し、遅延されたACK要求に応答して遅延されたACKを構築し、MSDUをフィルタ処理し、それにより、サーバーのために意図された正しいMSDUのみがサーバー（マスターSTB）に渡されるようにする。ソフトウェア・モジュール１０２０は受信されたMSDUについての遅延されたACKを転送し、サーバー（マスターSTB）のために意図されていないMSDUを破棄する。ソフトウェア・モジュール１０２０は、上記の機能を実行するために、物理的特性およびパラメータをデータ記憶ユニット１０２５から受信する。ソフトウェア・モジュール１０２０は、遅延されたACKおよび帯域幅管理メッセージのようなMACコマンドを、ソフトウェア・モジュール１０３０に転送する。このソフトウェア・モジュール１０３０は、MACコマンドを分離し、MSDU ACKをMSDU ACKバッファ１０３５に転送し、MAC帯域幅情報要素（IE: information element）をMAC帯域幅管理エンティティ１０４０に転送する。ソフトウェア・モジュール１０２０は、MSDU（たいていはTCP ACK）をソフトウェア・モジュール１０４５に転送しもする。このソフトウェア・モジュール１０４５が、フラグメントから完成されたMSDUを再構築し、不完全なMSDUのフラグメントを記憶し、MSDUのフラグメントを適正な順序にする。ソフトウェア・モジュール１０４５は並べ替えフレーム構築バッファ１０５０および受信MSDUフラグメント・バッファ１０５５と通信する。ソフトウェア・モジュール１０４５は完全なMSDUをソフトウェア・モジュール１０６０に転送し、そこで、完全なMSDUは、フレーム検査シーケンスおよび優先度マッピングを含むイーサネット（登録商標）・フレームに変換される。ソフトウェア・モジュールは転送テーブルおよびサービス・フロー情報をデータ記憶ユニット１０６５から受信し、イーサネット（登録商標）・フレームをサーバー（マスターSTB）に転送する。
【００４４】
図１１は、リモートSTB（ビデオ・クライアント）に接続されているDEV-xについての高レベルの送信パケット流である。イーサネット（登録商標）・フレームは、ソフトウェア・モジュール１１０５によって受信される。このソフトウェア・モジュール１１０５はビデオ・クライアントからのはいってくるフレームをフィルタ処理し、分類する。ソフトウェア・モジュール１１０５は、イーサネット（登録商標）・フレームをフレーム待ち行列１１１０に転送する。すべてのトラフィックはサーバー（マスターSTB）に行くはずなので、一つの待ち行列しかない。しかしながら、複数の優先度が望まれる場合には、複数の待ち行列が実装される――各優先度グループ（priority group）について一つの待ち行列である。待ち行列内のデータはソフトウェア・モジュール１１１５に転送される。このソフトウェア・モジュール１１１５はイーサネット（登録商標）・フレームを、優先度マッピング、フレーム検査シーケンス、フラグメンテーションおよびHCC計算を含むIEEE802.15.3 MACフレームに変換する。ソフトウェア・モジュール１１１５は転送テーブルおよびサービス・フロー情報をデータ記憶ユニット１１２０から受信する。ソフトウェア・モジュール１１１５は送信MSDU送信バッファ１１２５とも通信する。ソフトウェア・モジュールは複数のMSDUをソフトウェア・モジュール１１３０に転送する。このソフトウェア・モジュール１１３０は次のスーパーフレーム内での送信のために、上りMPDUを構築する。ソフトウェア・モジュール１１１５はまた、ソフトウェア・モジュール１１３０からの要求も受信する。ソフトウェア・モジュール１１３０は直前のスーパーフレームからのMSDU ACKをバッファ１１３５から受信する。ソフトウェア・モジュール１１３０は、物理的特性およびパラメータをデータ記憶ユニット１１４０から受信し、CTA情報をデータ記憶ユニット１１４５からのビーコンから受信する。ソフトウェア・モジュール１１３０はMAC帯域幅管理コマンドをソフトウェア・モジュール１１５０から受信し、このソフトウェア・モジュール１１５０は、データ記憶ユニット１１５５から受信されたローカルな待ち行列長さ情報およびデータ記憶ユニット１１６０からの直前のスーパーフレームからのMAC帯域幅要求応答（待ち行列情報を交換するために非標準的な仕方で使用されるIEEE802.15.3 MACコマンド）を使って、帯域幅管理メッセージを構築する。ソフトウェア・モジュール１１３０は、直前のスーパーフレームからの再送信されるべきMSDUをスーパーフレーム再送信バッファ１１６５から受信する。各MPDUには複数のMSDUがある。スーパーフレーム再送信バッファ１１６５は、受け取り確認されたMSDUの破棄もする。ソフトウェア・モジュール１１３０は構築バッファ１１７０と通信する。この構築バッファ１１７０は次のスーパーフレームのための上りMPDUのためのバッファである。構築バッファ１１７０は上りMPDUをスーパーフレーム送信バッファ１１７５に転送する。このスーパーフレーム送信バッファ１１７５は上りMPDUをソフトウェア・モジュール１１８０に転送する。スーパーフレーム送信バッファ１１７５は上りMPDUをスーパーフレーム再送信バッファ１１６５にも転送する。ソフトウェア・モジュール１１８０は、ビーコンに基づくタイミングを使って、複数のMSDUを各MPDUにまとめ、MPDUを送信のために物理層ソフトウェア・モジュール１１８５に渡す。ソフトウェア・モジュールは時間クロック１１９０から時間を受信し、サーバー（マスターSTB）から受信期間の間に遅延されたACKを受信する。ソフトウェア・モジュール１１８０は送信データ、送信データ・レート、送信長さ、送信電力レベルおよび送信アンテナ制御を物理層ソフトウェア・モジュール１１８５に転送する。
【００４５】
リモートDEVにおける受信プロセスの近似が図１２に示されている。受信プロセスは、主として、スーパーフレームの分解と、次いでフラグメント化したフレームを再び集めることを含むイーサネット（登録商標）・フレームの再構築からなる。受信側もエラーがないかどうか検査し、PNCへの返送のためにDLY ACK（バルクACKの一つの型）を用意する。DLY ACKは、そのパケットが到着したCTAの反対方向を向いて、CTAの最初において送られる。これは、規格からのもう一つの逸脱である。
【００４６】
図１２は、ビデオ・クライアント（リモートSTB）に接続されたDEV-xについての高レベルの受信パケットの流れ図である。よって、記述は図の右側から始まって進行する。ソフトウェア・モジュール１２０５はPPDUを受信し、受信されたデータ、受信されたエラー、長さ、LQIおよびRSSIをソフトウェア・モジュール１２１５に転送する。ソフトウェア・モジュール１２０５は受信アンテナ制御情報をソフトウェア・モジュール１２１５から受信し、タイミング情報を時間クロック１２１０から受信する。ソフトウェア・モジュール１２１５はMPDUを物理層ソフトウェア・モジュール１２０５から受信する。複数のMSDUが各MPDUにまとめられる。ソフトウェア・モジュール１２１５は時間クロック１２１０からタイミングを受信する。ソフトウェア・モジュール１２１５は、MPDUの諸片をソフトウェア・モジュール１２２０に転送する。このソフトウェア・モジュール１２２０がHCC計算を実行し、完全なMSDUまたはフラグメントを単離し、フレーム検査シーケンスを処理し、正しく受信されたMSDUを追跡し、遅延されたACK要求に応答して遅延されたACＫを構築し、MSDUをフィルタ処理し、サーバー（マスターSTB）のために意図された正しく受信されたMSDUのみを転送する。ソフトウェア・モジュールは、物理的特性およびパラメータをデータ記憶ユニット１２２５から受信し、受信されたMSDUについての遅延されたACKを転送する。ソフトウェア・モジュール１２２０は、そのビデオ・クライアント（リモートSTB）のために意図されていないMSDUは破棄し、MACコマンドをソフトウェア・モジュール１２３０に転送する。このソフトウェア・モジュール１２３０はMAC管理メッセージを分離し、MAC帯域幅応答をデータ記憶ユニット１２３５に転送し、リモートSTBからのMSDU ACKをMSDUバッファ１２４０に転送する。ソフトウェア・モジュール１２２０はMSDUをソフトウェア・モジュール１２４５に転送し、このソフトウェア・モジュール１２４５がフラグメントから完成されたMSDUを再構築し、不完全なMSDUのフラグメントを記憶し、MSDUを適正な順序にする。ソフトウェア・モジュール１２４５は並べ替えおよびフレーム構築バッファ１２５０および受信MSDUフラグメント・バッファ１２５５と通信する。ソフトウェア・モジュール１２４５は完全なMSDUをソフトウェア・モジュール１２６０に転送し、このソフトウェア・モジュール１２６０はMACフレームを優先度を含むイーサネット（登録商標）・フレームに変換する。ソフトウェア・モジュール１２６０は、転送テーブルおよびサービス・フロー情報もデータ記憶ユニット１２６５から受信する。
【００４７】
図１３を参照すると、物理プリアンブルおよび物理ヘッダがCTA当たり一つの物理フレームをなす。リモートSTBへの遅延されたACK、リモートSTBへの待ち行列状態情報要求およびリモートSTBへの複数データ・パケットが、保護されたMACヘッダとともにMACフレームの集合をなす。上記がそのCTA内での任意の余っている時間と連結されたものが、リモートSTBへのそのPNCのための下りCTAをなす。
【００４８】
ここで図１４を参照すると、各MACペイロードについて、対応するMACヘッダがある。HCCが計算され、MACヘッダの後かつMACペイロードの前に挿入される。FCSが計算され、MACペイロードの後に挿入される。これは、スーパーMACフレームを作り出すために各MACペイロードについてなされる。スーパーMACフレーム長は物理ヘッダの一部である。物理ヘッダは、変調され空中を通じて送信されるCTAを作るためにスーパーMACフレームより前に挿入される。物理ヘッダは遅い、信頼できるレートで送信され、CTAのスーパーMACフレーム部分は何らかの望ましいレートで送信される。
【００４９】
CTA4、CTA5およびCTA6内のフレームの送信は同様にして送られる。これらのCTAの一つにおいて送られるフレームの一例が図１５に示されている。図１５は、単一の上りCTAの一つ（DEV-xからPNC）を描いている。単一の上りCTAは一つの物理フレームと、保護されたヘッダをもつMACフレームの集合と、CTA内の任意の余った時間を含む。本発明については、上りトラフィックの多くはTCP ACKであろう。図１３に示された下りCTAと同様、物理フレームは物理プリアンブルおよび物理ヘッダを含む。MACフレームの集合はPNCへの遅延されたACK、PNCへの待ち行列状態情報およびPNCへのデータ・パケットを含む。このCTAが、PNCに待ち行列状態情報を運び戻すフレームを含んでいることを注意しておく。この待ち行列状態情報は待ち行列のサイズ（もし可変なら）、待ち行列中のフレーム数、フレームの平均長および待ち行列の入力におけるフレーム到着レートを含んでいてもよい。
【００５０】
本発明については、ビデオ・ストリーミング・パケット（下り）はTCPを使ってマスターSTBから送られると想定される。このため、ビデオとは反対方向（上り）にTCP ACKが生成されることになる。これらのTCP ACKはオーバーヘッドを追加し、もしそのオーバーヘッドが解消されれば、より実際のトラフィック（すなわち下りのビデオ）のために時間を解放できる。さらに、TCPに組み込まれたフロー制御機構のため、および（バッファおよびCTAに起因して）無線ブリッジによって追加される追加的な遅延のため、TCPは、ビデオ・ストリームが、それが本当に達する必要のあるレートに達することを妨げうる。
【００５１】
まず、問題がよりよく理解されるよう、TCPについて手短に述べる。次いで、その問題を解決する助けとなりうる、高レベルでの若干数の層横断型の修正を呈示する。なお、マスターSTBおよびリモートSTBにおけるTCPパラメータそのものの変更が、この問題を解決するためのもう一つの方法であるが、何度か述べたように、これは可能ではないと想定されることを注意しておく。
【００５２】
TCPは、全二重の接続指向の（connection-oriented）転送プロトコルである。TCPはデータ・ストリームのセグメントを送る。UDPは呈示されるパケットを送る。TCPの一つの特徴は、信頼できる送達である。これは、TCP ACKの使用を通じて保証される。この機構はインターネット・トラフィックについて有益であることが立証されているが、信頼できる送達を生じるその恩恵は、すでに高い信頼性をもつLAN上では疑問がある。よって、TCP ACKは著しいオーバーヘッドを追加する。無線のような帯域幅制限されたネットワークの場合、そのオーバーヘッドの不利は多大である。
【００５３】
TCPカプセル化が図１６に示されている。TCPヘッダがTCPペイロードの前に付加される。これら両者の前にIPヘッダが付加される。TCPペイロードとTCPヘッダの組み合わせはTCPセグメント（TCP segment）とも呼ばれる。TCPセグメントとIPヘッダの組み合わせはIPデータグラム（IP datagram）とも呼ばれる。
【００５４】
IPヘッダおよびTCPヘッダがそれぞれ図１７および図１８に示されている。IPヘッダは宛先IPアドレスおよびソースIPアドレスを含む。さらに、IPヘッダは、そのペイロードを識別するために使われるプロトコル番号を含む。TCPの場合、この番号は17である。UDPなら6である。TCPヘッダは宛先ポート番号およびソース・ポート番号を含む。ポート番号は、各端におけるデバイスによって、そのTCP接続に関連付けられたソフトウェア・アプリケーションまたはコードを識別するために使用される。
【００５５】
さらに、TCPヘッダは、本発明の動作に重要ないくつかの他のフィールドを含む。TCPは全二重接続なので、各端は別個のシーケンス番号カウンタを維持する。32ビットのシーケンス番号はバイト・カウンタであり、出ていくパケット毎に、同じTCP接続の一部であるソース・デバイスによってインクリメントされる。このヘッダはまた、32ビットの受け取り確認番号をも含む。これは、送信側に、受信器が期待する次のバイトが何であるかを（換言すれば、受信器がバイト−1まで成功裏に受信したということを）通知するために使われる。全二重TCP接続の反対方向も同じ手順をたどる。
【００５６】
受信器が受信しうる最大セグメント・サイズ（バイト単位）を示す最大セグメント・サイズ（MSS）が受信器から送信器に送られる。典型的なTCP MSSは1024（一般的）、536（一端が他端からMSSを受信しないときのデフォルト）、イーサネット（登録商標）上での1460などである。536というデフォルトは、IPが最小サイズ576バイトのパケット（ペイロードおよびTCPおよびIPヘッダ）を扱える必要があるという事実を反映している。よって、インターネットに送られるトラフィックは通例、この数に制限される。外部ルート対内部ルートは、経路最大転送単位（MTU: maximum transfer unit）発見によって決定される。
【００５７】
チェックサムは、TCPヘッダおよびデータをカバーし、フレームが正しく受信されたかどうかを判定するために使用される。最も一般的なオプション・フィールドは最大セグメント・サイズ（MSS）である。これは、接続が確立されようとしているときに送られる。ACKフィールドは、受け取り確認値が有効であることを意味する。
【００５８】
シーケンス番号は、選択的な再送信や否定受け取り確認なしにスライディング・ウィンドウ・プロトコルを実装するために使われる。シーケンス番号は、「N個戻る（Go-Back-N）」方式または「停止して待機（Stop-n-Wait）」方式において使用できる。TCPスライディング・ウィンドウ動作は図１９に示されている。基本的に、任意の所与の時点において、「ネットワーク内」には受け取り確認されていないバイトが限られた数だけ許容される。バイトが受け取り確認されるときに、ウィンドウの後端部分（trailing part）が左に動く。バイトが受け取り確認されるおよび／またはより大きなウィンドウが広告されるときに、ウィンドウの先端（leading end）が左に動く。使用可能なウィンドウ内に残されるバイト数はウィンドウ・サイズおよびすでに送られたバイトが何バイトかに依存する。宛先は、受信できるバイト数に基づいて（おそらくは受信バッファ・サイズに基づいて）ウィンドウ・サイズを設定する。スライディング・ウィンドウは、次に示すよく知られた帯域幅遅延積制限（bandwidth delay product limitation）を与える。
【００５９】
ウィンドウ・サイズ（容量）＝有効帯域幅（ビット／秒）×往復時間（秒）
TCPはもともと、16ビットのウィンドウ・サイズをもつだけであった。これは、TCP受信器がウィンドウ・サイズをその最大に設定したとき、ネットワーク内に許容されるのはたった64キロバイトであったことを意味していた。ウィンドウ・サイズは、ネットワーク中のずっと多くのバイトが受け取り確認されないでいることを許容するスケーリング・オプションを含むよう修正された。しかしながら、レガシー実装のため、そしてそれが「たいていの場合」機能するので、多くの実装はいまだに16ビットのスライディング・ウィンドウを使うのみである。有限のTCPスライディング・ウィンドウは、ビデオのために必要とされる広帯域幅およびTDMA MAC無線ブリッジのために必要とされる遅延に起因する目標アプリケーションにおける問題を引き起こすことができる。
【００６０】
スライディング・ウィンドウが例示的なブリッジング・システムにどのように負の影響を与えることができるかを見るために、次の例を考える。スーパーフレームの長さが5msecまたは10msecに固定されており、CTAが固定されている場合については、表１がいくつかの代表的な値を示す。表２は、本稿に示されるMPDU集積（MPDU aggregation）の方法および他の若干の個別的な想定（たとえば、ビデオ・パケット・サイズ）を使って各CTA内に期待しうるパケットの概数を示す。往復時間（RTT: round trip time）は、TCPパケットが送られたときからそのセグメントのみに関連付けられたTCP ACKが受信される時刻までの時間である。スーパーフレームが10msecであれば、RTTは少なくとも20msecである。実際には、送信待ち行列内のパケットおよびMACレベルでの再送信のため、より高くなる。20Mbpsおよび20msecの遅延では、スライディング・ウィンドウは、ストリームが意図されるレートで流れることを許容するためには、少なくとも50キロバイトである必要がある。追加的なバッファリングおよびデータがCTAの開始と非同期ではいってくるという事実のため、ストリームがこの例において遅くなる可能性が高い。さらに、TCPスライディング・ウィンドウは、50キロバイトより遅い何らかの値に設定されてもよい。
【００６１】
【表１】
【００６２】
【表２】
いくつかの有利なタイムアウトもある。再送信タイムアウトは、RTTの測定に基づくことができるが、典型的には500msecに設定される。再送信タイムアウトは、受け取り確認されていないTCPセグメントの再送信を開始するために使用される。もう一つのタイマーは、TCP ACKが送信器に返される時を遅延させるために時々使用される。これは、データがペイロードについて利用可能になることを許容するためである。このタイマーは、典型的には200msecについて設定され、本願のためのRTTを増すことになる。
【００６３】
TCP受信器が誤りをもつパケットを受信する場合、TCP受信器は、そのパケットを破棄し、送信側がそのパケットを再送信するのを待つ。TCP送信者がタイムアウト期間、典型的には500msec以内にACKを受信しない場合、TCP送信者はそのパケットを再送信する。ビデオ・ストリーミング・アプリケーションについては、これでは受信側が使用するには遅すぎ、そのパケットも破棄されうる。
【００６４】
「遅いスタート（Slow Start）」は比較的新しめのTCP機能である。この機能では、新しいパケットがネットワークに注入されるべきレートは、受け取り確認が反対側から返されるレートである。これは、事実上、送信者のTCPに、輻輳窓（congestion window）として知られるもう一つのウィンドウを追加する。これは主として、ルーターを通じて行くときに輻輳を回避するために使われる。
【００６５】
本発明においては、TCP ACKオーバーヘッドおよびTCPウィンドウの効果を減らし、輻輳を管理する二つの方法がある。二つの方法は組み合わされて第三の方法を形成することができる。本発明の前記諸方法は、MAC層がTCP ACKプロセスにおいて限られた仕方で参加することに関わる。ビデオ・ストリーム・パケットおよび戻りACKは、TCP接続の一部として識別される。同じ接続（またはストリーム）に属するTCPパケットが宛先IPアドレス、ソースIPアドレス、TCPソース・ポート番号およびTCP宛先ポート番号によって一意的に識別できることはよく知られている。目標アプリケーションについては、同じ送信待ち行列内のパケットの大半は、同じTCP接続に属する可能性が高い。よって、有効なシーケンス番号をもつTCP ACKは、TCPヘッダ内のACKフラグを見ることによって決定できる。
【００６６】
第一の方法では、無線リンクを通じてリモート・ブリッジ・デバイスおよびマスター・ブリッジング・デバイスから実際に転送されるTCP ACKの数を減らすことが望ましい。本発明はTDMA MACを使用するので、リモートSTBからマスターSTBへの送信は、スーパーフレームの長さに依存して5または10msec毎にまとまって起こる。リモートSTB／デバイスからマスターSTB／デバイスへの送信のために、リモートSTBは、その送信待ち行列からパケットを取り出し、送信のための一連のフレーム（または集積されたフレーム［aggregated frames］）に組み立てる。この例示的な適用では、このトラフィックのすべては、マスターSTBを宛先とされている。
【００６７】
リモート・ブリッジ・デバイスは、送信待ち行列内のフレームのIPおよびTCPヘッダを調べ、どれが同じTCP接続からのTCP ACKであるかを判定する。それらのパケットについて、次いで、TCPヘッダ内のシーケンス番号が読まれる。それらのパケット内にペイロードがないと想定すると、リモート・ブリッジ・デバイスは最高のシーケンス番号を送る必要があるだけである。というのも、TCPでは、そのシーケンス番号がすべてのより低いシーケンス番号を含むからである。パケットの一つがペイロードを含む場合、その特定のパケットが、ヘッダ内に適正なシーケンス番号を設定されて返されるパケットであることができる。TCP ACKパケットの二つ以上がそのペイロードにデータを含んでいる場合には、それもシーケンス番号を繰り返して送られる。これは事実上、送信待ち行列から冗長な「TCP ACKのみ」パケットをすべて消去する。これは、より短いCTAがリモート・デバイス／STBに割り当てられることを許容し、マスター・デバイス／STBに割り当てられるCTAのためにより多くの時間を、よって下りビデオ送信のために割り当てられる、より多くの時間を残す。
【００６８】
図２０は、リモート・ブリッジ・デバイスにおいて実施される、本発明の第一の方法の高レベルのフローチャートである。２００５では、リモート・ブリッジ・デバイスは、マスター・ブリッジ・デバイスに転送されるべきいくつかのTCP ACKを受信する。２０１０では、リモート・ブリッジ・デバイスはその送信待ち行列をスキャンし、ペイロードをもたない隣り合うTCP ACKを、そのTCP ACKの集合のうちからの最高のシーケンス番号を受け取り確認する単一のTCP ACKで置き換える。２０１５では、単一の集積TCP ACK（aggregate TCP ACK）がマスター・ブリッジ・デバイスにCTA内において転送される。このプロセスは２００５から繰り返される。
【００６９】
この第一の方法はTCP送信ACKのオーバーヘッドを減らすが、それでも、TCPパケットが遅すぎ、TCPレベルで再送信される可能性がある。TCP再送信はかなり長いタイムアウトに基づくので、リアルタイムのビデオ・ストリームのためにはそれほど有用ではない。多くのビデオ・コーダ・デコーダ（コーデック）は誤り隠蔽方式を含んでいるので、当該パケットが若干の誤りをもって時間通りに到着した場合よりも、TCPレベルの再送信のほうが一層悪い問題を引き起こしうる。
【００７０】
本発明の第二の方法では、マスター・デバイス／STBに返されるローカルなTCP ACKがマスター・ブリッジ・デバイスによって生成される。つまり、マスター・デバイス／STBはだまされて、下りパケットがすでにリモート・デバイス／STBによって受信されたと思い込まされる。マスター・デバイス／STBはTCP ACKを受信するので、そのデータ／情報を再送信はしない。よって、何らかの理由で下りデータが誤って受信される場合、数回のMACレベルの再送信後であっても、下りビデオ・データは相変わらずリモート・デバイス／STBに転送される。しかしながら、指摘したように、ビデオ・ストリーミングのためには、「遅くて正しい」よりも、「若干の誤りはあるが比較的時間通り」のほうがよい。
【００７１】
前記方法は、マスター・デバイス／STBからのあらゆるTCPトラフィックに対して使用できるし、あるいはある特定のTCP接続に対してのみ使用されることもできる。いずれの場合でも、マスター・ブリッジ・デバイスは各TCP接続を別個に追跡する。先に指摘したように、TCPトラフィックは、IPヘッダにおいて、プロトコル番号によって識別され、ストリーム自身はソースおよび宛先IPアドレスならびにソースおよび宛先TCPポート番号によって一意的に識別される。
【００７２】
この方法は、いくつかの理由で、ビデオ・ストリームそのものについてのみ使用することが最善である。ビデオ・ストリーム・パケットがリモート・デバイス／STBに、たとえ誤りがあっても時間通りに渡されることが最善ではあるが、頻度がより低い他のデータ・トラフィック（たとえばボックス制御［box control］）は正しく到着する必要があることがありうる。さらに、各TCP接続は別個に管理される必要があるが、N個のTCP接続を管理するには、各リモート・デバイス／STBへの一つのTCP接続を管理するよりN倍多くの資源（すなわち、データ構造等）が必要とされる。さらに、例示的なアプリケーションは下りのビデオ配信なので、潜在的な効率向上の大半は、ビデオ・ストリームにおいて得られる。このすべてのため、ローカルTCP ACKを、目標アプリケーションであるビデオ・ストリーム接続についてのみ生成することが望ましい。
【００７３】
マスター・ブリッジング・デバイスは、ビデオ・ストリームを識別するためにいくつかの方法の一つを使用できる。いくつかのアプリケーションでは、STBおよびブリッジング・デバイスは一つの製造業者からのものであることがありうる。ビデオ配信に使われるTCPポート番号はブリッジ・デバイスにあらかじめ知られている（すなわち、設計時に組み込まれる）のでもよいし、あるいはその情報を、直接またはネットワークもしくは他のインターフェースを通じて、ブリッジング・デバイスに手動で入力することが可能であってもよい。ブリッジング・デバイスがストリームを他の何らかの仕方で、可能性としてはサービス・プロバイダーのネットワークと直接通信していることがありうるSTBとの直接通信で、識別することが可能である。
【００７４】
マスター・ブリッジング・デバイスがビデオ・ストリームをその特性から識別することが可能である。たいていのビデオ・ストリーム（放送事業者からの）は1〜2Mbpsの範囲にある。高精細度ビデオは15〜20Mbpsにより近い。マスター・ブリッジング・デバイスはTCP接続セットアップ・パケットをかぎつけて（sniff）、次いでそのストリームを何らかの時間期間（たとえば1秒）にわたって監視することができる。それが一定のストリームであるように見えれば、マスター・ブリッジ・デバイスはこの方法を使うことを開始できる。
【００７５】
マスター・ブリッジ・デバイスはTCPスライディング・ウィンドウ、TCPシーケンス番号およびそれ自身の送信待ち行列を追跡する。マスター・デバイス／STBからのTCPフレームの到着が頻繁すぎる場合、マスター・ブリッジ・デバイスは、待ち行列レベルが下がるまでTCP ACKを差し控える。本発明の本方法はフロー制御の一つの形である。
【００７６】
図２１は、マスター・ブリッジング・デバイスで実施される本発明の第二の方法の高レベルの送信フローチャートである。任意的に、TCPセットアップの間に２１０５で、マスター・ブリッジ・デバイスはマスター・デバイス／STBにローカルに、最適セグメント・サイズならびにバッファリングおよびCTAに起因するシステム遅延をカバーするのに十分大きなTCPウィンドウ・サイズをもって応答する。２１１０で、マスター・ブリッジ・デバイスはマスター・デバイス／STBからTCPデータ・セグメントを受信する。２１１５で試験が実行され、送信待ち行列が所定数のCTA（たとえば二つのCTA）のために十分なTCPデータを含んでいるかどうかが判定される。十分なTCPデータがあれば、動作２１１０が再び実行される。十分なTCPデータ・セグメントがなければ、２１２０でマスター・ブリッジ・デバイスが、マスター・デバイス／STBに返すためのローカルなTCP ACKを生成し、動作２１１０が再び実行される。
【００７７】
TCP接続は全二重接続なので、リモート・デバイス／STBから論理的にマスター・デバイス／STBに向かうACKもある。この場合、マスター・デバイスSTBが下りパケットに対して実行したのと同じプロセスを、リモート・デバイス／STBが上りパケットに対して実行する。
【００７８】
マスター・ブリッジ・デバイスはまた、リモート・デバイス／STBから実際に返されるTCP ACKを途中で捕らえ、それがマスター・デバイス／STBに送られないようにする。マスター・ブリッジ・デバイスはこれらのTCP ACK内の情報を使って、到来パケットの処理に関してリモート・デバイス／STBがどこにあるかを判定する。あるいはまた、TCP ACKはリモート・ブリッジ・デバイスによって途中で捕らえられることもでき、望むならマスター・ブリッジ・デバイスに要約レポートが送られる。リモート・ブリッジ・デバイスが途中で捕らえられたTCP ACKを捨てることも可能である。
【００７９】
図２２は、マスター・ブリッジ・デバイスにおいてリモートTCP ACKを転送するための高レベルのフローチャートである。２２０５で、マスター・ブリッジ・デバイスはリモート・デバイス／STBからTCP ACK（ペイロードなし）を受信する。２２１０で試験が実行されて、受信されたデータ・セグメントがすでに受け取り確認されているかどうかが判定される。そのデータ・セグメントがすでに受け取り確認されていれば、２２１５でTCP ACKは破棄され、プロセスは２２０５から繰り返される。そのデータ・セグメントがまだ受け取り確認されていなければ、２２２０で単一のTCP ACKがマスター・デバイス／STBに転送される。
【００８０】
リモート・ブリッジ・デバイスは、何度かMACレベルで送信されたパケットを意識する。それらのパケットは遅いかもしれず、ひとたび最終的にリモート・ブリッジ・デバイスにおいて受信されたときに誤っていることさえありうる。いずれにせよ、リモート・デバイス／STBもどのバイトが受信および受け取り確認されたかを追跡しているので、そのデータ・セグメントはやはりリモート・デバイス／STBに転送される。
【００８１】
図２３は、リモート・デバイスにおいて実施される本発明の前記第二の方法の高レベルのフローチャートである。２３０５では、リモート・ブリッジ・デバイスはマスター・ブリッジ・デバイスからTCPデータ・セグメント（ペイロードなし）を受信する。２３１０で試験が実行されて、フレームが正しいかどうか（フレームがフレーム検査シーケンスに合格したかどうか）が判定される。フレームが正しければ、そのフレームは２３１５でリモート・デバイス／STBに転送され、プロセスは２３０５から繰り返される。フレームが正しくなければ、２３２０で別の試験が実行されて、これがMAC層による再送信の最後の試行（五回目の試み）であるかどうかが判定される。これが最後の試行でなければ、プロセスは２３０５から繰り返される。これが最後の試行であれば、２３２５で、そのデータに一致するよう新しいフレーム検査シーケンスが計算され、新しいTCPフレームが構築される。この新しいフレームは正しく見えるが、不正な／正しくないデータを有しており、低頻度で起こるべきである。
【００８２】
本発明のこの第二の方法の利点は、ソースをだましてパケットが受け取り確認されたと思い込ませることができることである。これは、より多くのパケットが通信経路内にあることを許容し、実効的に、ウィンドウを長くし、結果としての平均ビットレートを増す。この平均ビットレートは、ビデオの自然なストリーミング・レートより上に保たれねばならない。
【００８３】
第三の方法は、上記した二つの方法を組み合わせる。TCP ACKは、前記第二の方法におけるようにブリッジ・デバイス（マスターまたはリモート）の一つによってローカルに生成されるが、リモートSTBによって返されるTCP ACKは前記第一の方法において記載されたように組み合わされる。
【００８４】
上記の記述は、高精細度ビデオ配信用途に好適な一つのマスターおよび三つのリモート・デバイスをもつ無線ブリッジング・システムに焦点を当ててきたが、当業者には、上記のような本発明の方法が一般的な無線CSMAまたはTDMA MACに、またさらには共通媒体（たとえば電力線）上で走る有線MACにも拡張できることは明らかなはずである。
【００８５】
本発明がさまざまな形のハードウェア、ソフトウェア、ファームウェア、特殊目的プロセッサまたはそれらの組み合わせにおいて実装されうることは理解しておくものとする。好ましくは、本発明はハードウェアおよびソフトウェアの組み合わせとして実装される。さらに、ソフトウェアは好ましくは、プログラム記憶デバイス上に具体的に具現されたアプリケーション・プログラムとして実装される。アプリケーション・プログラムは、いかなる好適なアーキテクチャを有する機械にアップロードされ、これにより実行されてもよい。好ましくは、その機械は、一つまたは複数の中央処理装置（CPU）、ランダム・アクセス・メモリ（RAM）および入出力（I/O）インターフェースといったハードウェアをもつコンピュータ・プラットフォーム上で実装される。コンピュータ・プラットフォームはまた、オペレーティング・システムおよびマイクロ命令コードをも含む。本稿に記載されるさまざまなプロセスおよび機能は、前記マイクロ命令コードの一部または前記アプリケーション・プログラムの一部（またはそれらの組み合わせ）であってもよい。それはオペレーティング・システムを介して実行される。さらに、追加的なデータ記憶装置および印刷装置のようなさまざまな他の周辺装置が前記コンピュータ・プラットフォームに接続されてもよい。
【００８６】
付属の図面に描かれている構成要素となるシステム・コンポーネントおよび方法ステップのいくつかは好ましくはソフトウェアで実装されるので、システム・コンポーネント（またはプロセス・ステップ）どうしの間の実際の接続は、本発明がプログラムされる仕方に依存して異なることがありうることを理解しておくべきである。本稿の教示を与えられれば、当業者は本発明のこれらおよび同様の実装または構成を考えることができるであろう。
【００８７】
原出願の出願時の特許請求の範囲をここでも開示しておく。
〔請求項１〕
受け取り確認を管理する方法であって：
データ・パケットおよび受け取り確認を接続と同定する段階と；
前記受け取り確認のどれが消去できるかを判定する段階と；
消去できる前記受け取り確認を、単一の受け取り確認で置き換える段階と；
該単一の受け取り確認を送信する段階とを有する、
方法。
〔請求項２〕
前記同定する段階がさらに、送信待ち行列内のヘッダを調べる段階を有する、請求項１記載の方法。
〔請求項３〕
前記調べる段階がさらに、前記ヘッダ内のフラグを調べる段階を有する、請求項２記載の方法。
〔請求項４〕
前記判定する段階がさらに、どの受け取り確認が共通の接続からであるかを判定する段階を有する、請求項２記載の方法。
〔請求項５〕
前記ヘッダ内のシーケンス番号を読むことをさらに含む、請求項４記載の方法。
〔請求項６〕
前記単一の受け取り確認が受け取り確認される前記データ・パケットの最高のシーケンス番号をもつ、請求項５記載の方法。
〔請求項７〕
送信されるべきペイロード・パケットがあるかどうかを判定する段階と；
前記ペイロード・パケット内において前記単一の受け取り確認を送信する段階とをさらに有する、
請求項１記載の方法。
〔請求項８〕
前記接続がTCP接続である、請求項１記載の方法。
〔請求項９〕
前記受け取り確認がTCP受け取り確認であり、前記単一の受け取り確認がTCP受け取り確認である、請求項１記載の方法。
〔請求項１０〕
受け取り確認を管理する方法であって：
データ・セグメントを受信する段階と；
接続を追跡する段階と；
所定数のチャネル時間割り当てのための十分なデータ・セグメントがあるかどうかを判定する段階と；
前記所定数のチャネル時間割り当てのための十分なデータ・セグメントがある場合に、ある選択された接続について前記受け取り確認を生成する段階とを有する、
方法。
〔請求項１１〕
フレームが到着するのが頻繁すぎる場合に受け取り確認を差し控えることをさらに含む、請求項１０記載の方法。
〔請求項１２〕
請求項１０記載の方法であって、
リモート・デバイスによって転送されたセグメント受け取り確認を途中で捕らえる段階と；
前記セグメントがすでに受け取り確認されているかどうかを判定する段階と；
前記セグメントがすでに受け取り確認されていれば、前記セグメント受け取り確認を破棄する段階と；
前記セグメントがまだ受け取り確認されていなければ、前記セグメント受け取り確認を転送する段階とを有する、
方法。
〔請求項１３〕
要約レポートを受信する段階をさらに有する、請求項１０記載の方法。
〔請求項１４〕
前記接続がTCP接続である、請求項１０記載の方法。
〔請求項１５〕
前記受け取り確認がTCP受け取り確認である、請求項１０記載の方法。
〔請求項１６〕
前記受け取り確認を単一の受け取り確認に集積する段階をさらに含む、請求項１０記載の方法。
〔請求項１７〕
受け取り確認を管理する装置であって：
データ・パケットおよび受け取り確認を接続と同定する手段と；
前記受け取り確認のどれが消去できるかを判定する手段と；
消去できる前記受け取り確認を、単一の受け取り確認で置き換える手段と；
該単一の受け取り確認を送信する手段とを有する、
装置。
〔請求項１８〕
前記同定する手段がさらに、送信待ち行列内のヘッダを調べる手段を有する、請求項１７記載の装置。
〔請求項１９〕
前記調べる手段がさらに、前記ヘッダ内のフラグを調べる手段を有する、請求項１８記載の装置。
〔請求項２０〕
前記判定する手段がさらに、どの受け取り確認が共通の接続からであるかを判定する手段を有する、請求項１８記載の装置。
〔請求項２１〕
前記ヘッダ内のシーケンス番号を読む手段をさらに有する、請求項２０記載の装置。
〔請求項２２〕
前記単一の受け取り確認が受け取り確認される前記データ・パケットの最高のシーケンス番号をもつ、請求項２１記載の装置。
〔請求項２３〕
送信されるべきペイロード・パケットがあるかどうかを判定する手段と；
前記ペイロード・パケット内において前記単一の受け取り確認を送信する手段とをさらに有する、
請求項１７記載の装置。
〔請求項２４〕
前記接続がTCP接続である、請求項１７記載の装置。
〔請求項２５〕
前記受け取り確認がTCP受け取り確認であり、前記単一の受け取り確認がTCP受け取り確認である、請求項１７記載の装置。
〔請求項２６〕
受け取り確認を管理する装置であって：
データ・セグメントを受信する手段と；
接続を追跡する手段と；
所定数のチャネル時間割り当てのための十分なデータ・セグメントがあるかどうかを判定する手段と；
前記所定数のチャネル時間割り当てのための十分なデータ・セグメントがある場合に、ある選択された接続について前記受け取り確認を生成する手段とを有する、
装置。
〔請求項２７〕
フレームが到着するのが頻繁すぎる場合に受け取り確認を差し控える手段をさらに有する、請求項２６記載の装置。
〔請求項２８〕
請求項２６記載の装置であって、
リモート・デバイスによって転送されたセグメント受け取り確認を途中で捕らえる手段と；
前記セグメントがすでに受け取り確認されているかどうかを判定する手段と；
前記セグメントがすでに受け取り確認されていれば、前記セグメント受け取り確認を破棄する手段と；
前記セグメントがまだ受け取り確認されていなければ、前記セグメント受け取り確認を転送する手段とを有する、
装置。
〔請求項２９〕
要約レポートを受信する手段をさらに有する、請求項１６記載の装置。
〔請求項３０〕
前記接続がTCP接続である、請求項１６記載の装置。
〔請求項３１〕
前記受け取り確認がTCP受け取り確認である、請求項２６記載の装置。
〔請求項３２〕
前記受け取り確認を単一の受け取り確認に集積する手段をさらに含む、請求項２６記載の装置。
【００８８】
さらにいくつかの態様を開示しておく。
〔態様１〕
無線ブリッジング・デバイスによって実行される、リモート・デバイスによって送られマスター・デバイスに宛てられた受け取り確認を管理する方法であって：
データおよび受け取り確認を、前記リモート・デバイスと前記マスター・デバイスの間の接続と同定する段階と；
前記受け取り確認のどれが冗長であるかを判定する段階と；
前記冗長な受け取り確認を、単一の受け取り確認で置き換える段階と；
該単一の受け取り確認を送信する段階とを有する、
方法。
〔態様２〕
前記同定する段階がさらに、送信待ち行列内のヘッダを調べる段階を有する、態様１記載の方法。
〔態様３〕
前記調べる段階がさらに、前記ヘッダ内のフラグを調べる段階を有する、態様２記載の方法。
〔態様４〕
前記判定する段階がさらに、どの受け取り確認が共通の接続からであるかを判定する段階を有する、態様２記載の方法。
〔態様５〕
前記ヘッダ内のシーケンス番号を読むことをさらに含む、態様４記載の方法。
〔態様６〕
前記単一の受け取り確認が受け取り確認される前記データの最高のシーケンス番号をもつ、態様５記載の方法。
〔態様７〕
送信されるべきペイロード・パケットがあるかどうかを判定する段階と；
前記ペイロード・パケットを、前記単一の受け取り確認として送信する段階とをさらに有する、
態様１記載の方法。
〔態様８〕
前記接続がTCP接続である、態様１記載の方法。
〔態様９〕
前記受け取り確認がTCP受け取り確認であり、前記単一の受け取り確認がTCP受け取り確認である、態様１記載の方法。
〔態様１０〕
無線ブリッジング・デバイスによって実行される、リモート・デバイスによって送られマスター・デバイスに宛てられた受け取り確認を管理する方法であって：
前記リモート・デバイスによって送られたデータを受信する段階と；
前記リモート・デバイスと前記マスター・デバイスの間の接続を追跡する段階と；
特定のデータについて所定数の再送信後にも受け取り確認が受信されない場合、該特定のデータについての受け取り確認を生成する段階と；
生成された受け取り確認を前記マスター・デバイスに送信する段階とを有する、
方法。
〔態様１１〕
データが到着するのが頻繁すぎる場合に受け取り確認を差し控えることをさらに含む、態様１０記載の方法。
〔態様１２〕
態様１０記載の方法であって、
特定のデータについて前記リモート・デバイスによって送られた受け取り確認を途中で捕らえる段階と；
前記特定のデータがすでに受け取り確認されているかどうかを判定する段階と；
前記特定のデータがすでに受け取り確認されていれば、前記受け取り確認を破棄する段階と；
前記特定のデータがまだ受け取り確認されていなければ、前記受け取り確認を前記マスター・デバイスに転送する段階とを有する、
方法。
〔態様１３〕
前記リモート・デバイスによって送られた受け取り確認を途中で捕らえた別の無線ブリッジング・デバイスから要約レポートを受信する段階をさらに有する、態様１０記載の方法。
〔態様１４〕
前記接続がTCP接続である、態様１０記載の方法。
〔態様１５〕
前記受け取り確認がTCP受け取り確認である、態様１０記載の方法。
〔態様１６〕
前記受け取り確認を単一の受け取り確認に集積する段階をさらに含む、態様１０記載の方法。
〔態様１７〕
リモート・デバイスによって送られ、マスター・デバイスに宛てられた受け取り確認を管理する無線ブリッジング・デバイスであって：
データおよび受け取り確認を前記リモート・デバイスと前記マスター・デバイスの間の接続と同定する手段と；
前記受け取り確認のどれが冗長であるかを判定する手段と；
前記冗長な受け取り確認を、単一の受け取り確認で置き換える手段と；
該単一の受け取り確認を送信する手段とを有する、
無線ブリッジング・デバイス。
〔態様１８〕
前記同定する手段がさらに、送信待ち行列内のヘッダを調べる手段を有する、態様１７記載の無線ブリッジング・デバイス。
〔態様１９〕
前記調べる手段がさらに、前記ヘッダ内のフラグを調べる手段を有する、態様１８記載の無線ブリッジング・デバイス。
〔態様２０〕
前記判定する手段がさらに、どの受け取り確認が共通の接続からであるかを判定する手段を有する、態様１８記載の無線ブリッジング・デバイス。
〔態様２１〕
前記ヘッダ内のシーケンス番号を読む手段をさらに有する、態様２０記載の無線ブリッジング・デバイス。
〔態様２２〕
前記単一の受け取り確認が受け取り確認される前記データの最高のシーケンス番号をもつ、態様２１記載の無線ブリッジング・デバイス。
〔態様２３〕
送信されるべきペイロード・パケットがあるかどうかを判定する手段と；
前記ペイロード・パケットを前記単一の受け取り確認として送信する手段とをさらに有する、
態様１７記載の無線ブリッジング・デバイス。
〔態様２４〕
前記接続がTCP接続である、態様１７記載の無線ブリッジング・デバイス。
〔態様２５〕
前記受け取り確認がTCP受け取り確認であり、前記単一の受け取り確認がTCP受け取り確認である、態様１７記載の無線ブリッジング・デバイス。
〔態様２６〕
リモート・デバイスによって送られ、マスター・デバイスに宛てられた受け取り確認を管理する無線ブリッジング・デバイスであって：
データを受信する手段と；
接続を追跡する手段と；
所定数のチャネル時間割り当てのための十分なデータがあるかどうかを判定する手段と；
前記所定数のチャネル時間割り当てのための十分なデータがある場合に、ある選択された接続について前記受け取り確認を生成する手段とを有する、
無線ブリッジング・デバイス。
〔態様２７〕
データが到着するのが頻繁すぎる場合に受け取り確認を差し控える手段をさらに有する、態様２６記載の無線ブリッジング・デバイス。
〔態様２８〕
態様２６記載の無線ブリッジング・デバイスであって、
特定のデータについてリモート・デバイスによって送られた受け取り確認を途中で捕らえる手段と；
前記特定のデータがすでに受け取り確認されているかどうかを判定する手段と；
前記特定のデータがすでに受け取り確認されていれば、前記受け取り確認を破棄する手段と；
前記特定のデータがまだ受け取り確認されていなければ、前記受け取り確認を前記マスター・デバイスに転送する手段とを有する、
無線ブリッジング・デバイス。
〔態様２９〕
前記リモート・デバイスによって送られた受け取り確認を途中で捕らえた別の無線ブリッジング・デバイスから要約レポートを受信する手段をさらに有する、態様１６記載の無線ブリッジング・デバイス。
〔態様３０〕
前記接続がTCP接続である、態様１６記載の無線ブリッジング・デバイス。
〔態様３１〕
前記受け取り確認がTCP受け取り確認である、態様２６記載の無線ブリッジング・デバイス。
〔態様３２〕
前記受け取り確認を単一の受け取り確認に集積する手段をさらに含む、態様２６記載の無線ブリッジング・デバイス。
〔態様３３〕
無線ブリッジング・デバイスによって実行される、マスター・デバイスからリモート・デバイスへのデータ送信を管理する方法であって：
前記マスター・デバイスによって送られたデータを受信する段階と；
前記データに含まれる検査データを使うことによって前記データが正しいかどうかを判定する段階と；
前記データが正しくないと判定され、所定回数の再送信がすでに試行されている場合、前記データに含まれる前記検査データを、前記正しくないデータに合うよう計算された新しい検査データに変更する段階と；
前記データを前記リモート・デバイスに転送する段階とを含む、
方法。
〔態様３４〕
マスター・デバイスからリモート・デバイスへのデータ送信を管理する無線ブリッジング・デバイスであって：
前記マスター・デバイスによって送られたデータを受信する手段と；
前記データに含まれる検査データを使うことによって前記データが正しいかどうかを判定する手段と；
前記データが正しくないと判定され、所定回数の再送信がすでに試行されている場合、前記データに含まれる前記検査データを、前記正しくないデータに合うよう計算された新しい検査データに変更する手段と；
前記データを前記リモート・デバイスに転送する手段とを含む、
無線ブリッジング・デバイス。
【特許請求の範囲】
【請求項１】
リモート・デバイスと通信する、時分割多重アクセス・トラフィック制約無線媒体アクセス制御ブリッジによって受け取り確認を管理する方法であって：
個別のユニキャスト接続のデータおよび受け取り確認を、前記時分割多重アクセス・トラフィック制約無線媒体アクセス制御ブリッジのクライアント側によって同定する段階と；
前記受け取り確認のどれが消去できるかを、前記時分割多重アクセス・トラフィック制約無線媒体アクセス制御ブリッジの前記クライアント側によって判定する段階と；
消去できる前記受け取り確認を、前記時分割多重アクセス・トラフィック制約無線媒体アクセス制御ブリッジの前記クライアント側によって単一の受け取り確認で置き換える段階と；
該単一の受け取り確認を、前記時分割多重アクセス・トラフィック制約無線媒体アクセス制御ブリッジの前記クライアント側によって、前記時分割多重アクセス・トラフィック制約無線媒体アクセス制御ブリッジのマスター側に送信する段階とを有する、
方法。
【請求項２】
前記同定する段階がさらに、送信待ち行列内のデータ・フレーム内のヘッダを調べる段階を有する、請求項１記載の方法。
【請求項３】
前記調べる段階がさらに、前記ヘッダ内のフラグを調べる段階を有する、請求項２記載の方法。
【請求項４】
前記判定する段階がさらに、どの受け取り確認が共通のユニキャスト接続からであるかを判定する段階を有する、請求項２記載の方法。
【請求項５】
前記ヘッダ内のシーケンス番号を読むことをさらに含む、請求項４記載の方法。
【請求項６】
前記単一の受け取り確認が受け取り確認される前記データの最高のシーケンス番号をもつ、請求項５記載の方法。
【請求項７】
送信されるべきペイロード・パケットがあるかどうかを判定する段階と；
前記ペイロード・パケット内において前記単一の受け取り確認を送信する段階とをさらに有する、
請求項１記載の方法。
【請求項８】
前記接続がTCP接続である、請求項１記載の方法。
【請求項９】
前記受け取り確認がTCP受け取り確認であり、前記単一の受け取り確認がTCP受け取り確認である、請求項１記載の方法。
【請求項１０】
マスター・デバイスと通信する時分割多重アクセス・トラフィック制約無線媒体アクセス制御ブリッジによって受け取り確認を管理する方法であって：
前記時分割多重アクセス・トラフィック制約無線媒体アクセス制御ブリッジのマスター側によって、データを受信する段階と；
前記時分割多重アクセス・トラフィック制約無線媒体アクセス制御ブリッジの前記マスター側によって、個々のユニキャスト接続を追跡する段階と；
所定数のチャネル時間割り当てを満たすのに十分なデータがあるかどうかを、前記時分割多重アクセス・トラフィック制約無線媒体アクセス制御ブリッジの前記マスター側によって判定する段階と；
前記所定数のチャネル時間割り当てのための十分なデータがない場合、前記時分割多重アクセス・トラフィック制約無線媒体アクセス制御ブリッジの前記マスター側によって、ある選択されたユニキャスト接続について前記受け取り確認を生成する段階と、
前記時分割多重アクセス・トラフィック制約無線媒体アクセス制御ブリッジの前記マスター側によって、前記データを、前記所定数のチャネル時間割り当てにおいて、ユニキャストでリモート・デバイスに送信する段階とを有する、
方法。
【請求項１１】
データが到着するのが頻繁すぎる場合に受け取り確認を差し控えることをさらに含む、請求項１０記載の方法。
【請求項１２】
請求項１０記載の方法であって、
リモート・デバイスによって転送されたセグメント受け取り確認を途中で捕らえる段階と；
前記データがすでに受け取り確認されているかどうかを判定する段階と；
前記データがすでに受け取り確認されていれば、前記セグメント受け取り確認を破棄する段階と；
前記データがまだ受け取り確認されていなければ、前記セグメント受け取り確認を転送する段階とを有する、
方法。
【請求項１３】
要約レポートを受信する段階をさらに有する、請求項１０記載の方法。
【請求項１４】
前記接続がTCP接続である、請求項１０記載の方法。
【請求項１５】
前記受け取り確認がTCP受け取り確認である、請求項１０記載の方法。
【請求項１６】
前記受け取り確認を単一の受け取り確認に集積する段階をさらに含む、請求項１０記載の方法。
【請求項１７】
受け取り確認を管理する、時分割多重アクセス・トラフィック制約無線媒体アクセス制御ブリッジであって：
当該時分割多重アクセス・トラフィック制約無線媒体アクセス制御ブリッジのクライアント側によって、個別のユニキャスト接続のデータおよび受け取り確認を同定する手段と；
当該時分割多重アクセス・トラフィック制約無線媒体アクセス制御ブリッジの前記クライアント側によって、前記受け取り確認のどれが消去できるかを判定する手段と；
当該時分割多重アクセス・トラフィック制約無線媒体アクセス制御ブリッジの前記クライアント側によって、消去できる前記受け取り確認を、単一の受け取り確認で置き換える手段と；
当該時分割多重アクセス・トラフィック制約無線媒体アクセス制御ブリッジの前記クライアント側によって、当該時分割多重アクセス・トラフィック制約無線媒体アクセス制御ブリッジのマスター側に、該単一の受け取り確認を送信する手段とを有する、
トラフィック制約された無線ブリッジ。
【請求項１８】
前記同定する手段がさらに、送信待ち行列内のデータ・フレーム内のヘッダを調べる手段を有する、請求項１７記載のトラフィック制約された無線ブリッジ。
【請求項１９】
前記調べる手段がさらに、前記ヘッダ内のフラグを調べる手段を有する、請求項１８記載のトラフィック制約された無線ブリッジ。
【請求項２０】
前記判定する手段がさらに、どの受け取り確認が共通のユニキャスト接続からであるかを判定する手段を有する、請求項１８記載のトラフィック制約された無線ブリッジ。
【請求項２１】
前記ヘッダ内のシーケンス番号を読む手段をさらに有する、請求項２０記載のトラフィック制約された無線ブリッジ。
【請求項２２】
前記単一の受け取り確認が受け取り確認される前記データ・パケットの最高のシーケンス番号をもつ、請求項２１記載のトラフィック制約された無線ブリッジ。
【請求項２３】
送信されるべきペイロード・パケットがあるかどうかを判定する手段と；
前記ペイロード・パケット内において前記単一の受け取り確認を送信する手段とをさらに有する、
請求項１７記載のトラフィック制約された無線ブリッジ。
【請求項２４】
前記接続がTCP接続である、請求項１７記載のトラフィック制約された無線ブリッジ。
【請求項２５】
前記受け取り確認がTCP受け取り確認であり、前記単一の受け取り確認がTCP受け取り確認である、請求項１７記載のトラフィック制約された無線ブリッジ。
【請求項２６】
受け取り確認を管理する、時分割多重アクセス・トラフィック制約無線媒体アクセス制御ブリッジであって、当該ブリッジはマスター・デバイスと通信しており：
当該時分割多重アクセス・トラフィック制約無線媒体アクセス制御ブリッジのマスター側によって、データを受信する手段と；
当該時分割多重アクセス・トラフィック制約無線媒体アクセス制御ブリッジの前記マスター側によって、個々のユニキャスト接続を追跡する手段と；
当該時分割多重アクセス・トラフィック制約無線媒体アクセス制御ブリッジの前記マスター側によって、所定数のチャネル時間割り当てのための十分なデータがあるかどうかを判定する手段と；
前記所定数のチャネル時間割り当てのための十分なデータがない場合に、当該時分割多重アクセス・トラフィック制約無線媒体アクセス制御ブリッジの前記マスター側によって、ある選択された接続について前記受け取り確認を生成する手段と；
当該時分割多重アクセス・トラフィック制約無線媒体アクセス制御ブリッジの前記マスター側によって、前記データを、前記所定数のチャネル時間割り当てにおいて、ユニキャストでリモート・デバイスに送信する手段とを有する、
トラフィック制約された無線ブリッジ。
【請求項２７】
データが到着するのが頻繁すぎる場合に受け取り確認を差し控える手段をさらに有する、請求項２６記載のトラフィック制約された無線ブリッジ。
【請求項２８】
請求項２６記載のトラフィック制約された無線ブリッジであって、
リモート・デバイスによって転送されたセグメント受け取り確認を途中で捕らえる手段と；
前記データがすでに受け取り確認されているかどうかを判定する手段と；
前記データがすでに受け取り確認されていれば、前記セグメント受け取り確認を破棄する手段と；
前記データがまだ受け取り確認されていなければ、前記セグメント受け取り確認を転送する手段とを有する、
トラフィック制約された無線ブリッジ。
【請求項２９】
要約レポートを受信する手段をさらに有する、請求項２６記載のトラフィック制約された無線ブリッジ。
【請求項３０】
前記接続がTCP接続である、請求項２６記載のトラフィック制約された無線ブリッジ。
【請求項３１】
前記受け取り確認がTCP受け取り確認である、請求項２６記載のトラフィック制約された無線ブリッジ。
【請求項３２】
前記受け取り確認を単一の受け取り確認に集積する手段をさらに含む、請求項２６記載のトラフィック制約された無線ブリッジ。
【請求項１】
リモート・デバイスと通信する、時分割多重アクセス・トラフィック制約無線媒体アクセス制御ブリッジによって受け取り確認を管理する方法であって：
個別のユニキャスト接続のデータおよび受け取り確認を、前記時分割多重アクセス・トラフィック制約無線媒体アクセス制御ブリッジのクライアント側によって同定する段階と；
前記受け取り確認のどれが消去できるかを、前記時分割多重アクセス・トラフィック制約無線媒体アクセス制御ブリッジの前記クライアント側によって判定する段階と；
消去できる前記受け取り確認を、前記時分割多重アクセス・トラフィック制約無線媒体アクセス制御ブリッジの前記クライアント側によって単一の受け取り確認で置き換える段階と；
該単一の受け取り確認を、前記時分割多重アクセス・トラフィック制約無線媒体アクセス制御ブリッジの前記クライアント側によって、前記時分割多重アクセス・トラフィック制約無線媒体アクセス制御ブリッジのマスター側に送信する段階とを有する、
方法。
【請求項２】
前記同定する段階がさらに、送信待ち行列内のデータ・フレーム内のヘッダを調べる段階を有する、請求項１記載の方法。
【請求項３】
前記調べる段階がさらに、前記ヘッダ内のフラグを調べる段階を有する、請求項２記載の方法。
【請求項４】
前記判定する段階がさらに、どの受け取り確認が共通のユニキャスト接続からであるかを判定する段階を有する、請求項２記載の方法。
【請求項５】
前記ヘッダ内のシーケンス番号を読むことをさらに含む、請求項４記載の方法。
【請求項６】
前記単一の受け取り確認が受け取り確認される前記データの最高のシーケンス番号をもつ、請求項５記載の方法。
【請求項７】
送信されるべきペイロード・パケットがあるかどうかを判定する段階と；
前記ペイロード・パケット内において前記単一の受け取り確認を送信する段階とをさらに有する、
請求項１記載の方法。
【請求項８】
前記接続がTCP接続である、請求項１記載の方法。
【請求項９】
前記受け取り確認がTCP受け取り確認であり、前記単一の受け取り確認がTCP受け取り確認である、請求項１記載の方法。
【請求項１０】
マスター・デバイスと通信する時分割多重アクセス・トラフィック制約無線媒体アクセス制御ブリッジによって受け取り確認を管理する方法であって：
前記時分割多重アクセス・トラフィック制約無線媒体アクセス制御ブリッジのマスター側によって、データを受信する段階と；
前記時分割多重アクセス・トラフィック制約無線媒体アクセス制御ブリッジの前記マスター側によって、個々のユニキャスト接続を追跡する段階と；
所定数のチャネル時間割り当てを満たすのに十分なデータがあるかどうかを、前記時分割多重アクセス・トラフィック制約無線媒体アクセス制御ブリッジの前記マスター側によって判定する段階と；
前記所定数のチャネル時間割り当てのための十分なデータがない場合、前記時分割多重アクセス・トラフィック制約無線媒体アクセス制御ブリッジの前記マスター側によって、ある選択されたユニキャスト接続について前記受け取り確認を生成する段階と、
前記時分割多重アクセス・トラフィック制約無線媒体アクセス制御ブリッジの前記マスター側によって、前記データを、前記所定数のチャネル時間割り当てにおいて、ユニキャストでリモート・デバイスに送信する段階とを有する、
方法。
【請求項１１】
データが到着するのが頻繁すぎる場合に受け取り確認を差し控えることをさらに含む、請求項１０記載の方法。
【請求項１２】
請求項１０記載の方法であって、
リモート・デバイスによって転送されたセグメント受け取り確認を途中で捕らえる段階と；
前記データがすでに受け取り確認されているかどうかを判定する段階と；
前記データがすでに受け取り確認されていれば、前記セグメント受け取り確認を破棄する段階と；
前記データがまだ受け取り確認されていなければ、前記セグメント受け取り確認を転送する段階とを有する、
方法。
【請求項１３】
要約レポートを受信する段階をさらに有する、請求項１０記載の方法。
【請求項１４】
前記接続がTCP接続である、請求項１０記載の方法。
【請求項１５】
前記受け取り確認がTCP受け取り確認である、請求項１０記載の方法。
【請求項１６】
前記受け取り確認を単一の受け取り確認に集積する段階をさらに含む、請求項１０記載の方法。
【請求項１７】
受け取り確認を管理する、時分割多重アクセス・トラフィック制約無線媒体アクセス制御ブリッジであって：
当該時分割多重アクセス・トラフィック制約無線媒体アクセス制御ブリッジのクライアント側によって、個別のユニキャスト接続のデータおよび受け取り確認を同定する手段と；
当該時分割多重アクセス・トラフィック制約無線媒体アクセス制御ブリッジの前記クライアント側によって、前記受け取り確認のどれが消去できるかを判定する手段と；
当該時分割多重アクセス・トラフィック制約無線媒体アクセス制御ブリッジの前記クライアント側によって、消去できる前記受け取り確認を、単一の受け取り確認で置き換える手段と；
当該時分割多重アクセス・トラフィック制約無線媒体アクセス制御ブリッジの前記クライアント側によって、当該時分割多重アクセス・トラフィック制約無線媒体アクセス制御ブリッジのマスター側に、該単一の受け取り確認を送信する手段とを有する、
トラフィック制約された無線ブリッジ。
【請求項１８】
前記同定する手段がさらに、送信待ち行列内のデータ・フレーム内のヘッダを調べる手段を有する、請求項１７記載のトラフィック制約された無線ブリッジ。
【請求項１９】
前記調べる手段がさらに、前記ヘッダ内のフラグを調べる手段を有する、請求項１８記載のトラフィック制約された無線ブリッジ。
【請求項２０】
前記判定する手段がさらに、どの受け取り確認が共通のユニキャスト接続からであるかを判定する手段を有する、請求項１８記載のトラフィック制約された無線ブリッジ。
【請求項２１】
前記ヘッダ内のシーケンス番号を読む手段をさらに有する、請求項２０記載のトラフィック制約された無線ブリッジ。
【請求項２２】
前記単一の受け取り確認が受け取り確認される前記データ・パケットの最高のシーケンス番号をもつ、請求項２１記載のトラフィック制約された無線ブリッジ。
【請求項２３】
送信されるべきペイロード・パケットがあるかどうかを判定する手段と；
前記ペイロード・パケット内において前記単一の受け取り確認を送信する手段とをさらに有する、
請求項１７記載のトラフィック制約された無線ブリッジ。
【請求項２４】
前記接続がTCP接続である、請求項１７記載のトラフィック制約された無線ブリッジ。
【請求項２５】
前記受け取り確認がTCP受け取り確認であり、前記単一の受け取り確認がTCP受け取り確認である、請求項１７記載のトラフィック制約された無線ブリッジ。
【請求項２６】
受け取り確認を管理する、時分割多重アクセス・トラフィック制約無線媒体アクセス制御ブリッジであって、当該ブリッジはマスター・デバイスと通信しており：
当該時分割多重アクセス・トラフィック制約無線媒体アクセス制御ブリッジのマスター側によって、データを受信する手段と；
当該時分割多重アクセス・トラフィック制約無線媒体アクセス制御ブリッジの前記マスター側によって、個々のユニキャスト接続を追跡する手段と；
当該時分割多重アクセス・トラフィック制約無線媒体アクセス制御ブリッジの前記マスター側によって、所定数のチャネル時間割り当てのための十分なデータがあるかどうかを判定する手段と；
前記所定数のチャネル時間割り当てのための十分なデータがない場合に、当該時分割多重アクセス・トラフィック制約無線媒体アクセス制御ブリッジの前記マスター側によって、ある選択された接続について前記受け取り確認を生成する手段と；
当該時分割多重アクセス・トラフィック制約無線媒体アクセス制御ブリッジの前記マスター側によって、前記データを、前記所定数のチャネル時間割り当てにおいて、ユニキャストでリモート・デバイスに送信する手段とを有する、
トラフィック制約された無線ブリッジ。
【請求項２７】
データが到着するのが頻繁すぎる場合に受け取り確認を差し控える手段をさらに有する、請求項２６記載のトラフィック制約された無線ブリッジ。
【請求項２８】
請求項２６記載のトラフィック制約された無線ブリッジであって、
リモート・デバイスによって転送されたセグメント受け取り確認を途中で捕らえる手段と；
前記データがすでに受け取り確認されているかどうかを判定する手段と；
前記データがすでに受け取り確認されていれば、前記セグメント受け取り確認を破棄する手段と；
前記データがまだ受け取り確認されていなければ、前記セグメント受け取り確認を転送する手段とを有する、
トラフィック制約された無線ブリッジ。
【請求項２９】
要約レポートを受信する手段をさらに有する、請求項２６記載のトラフィック制約された無線ブリッジ。
【請求項３０】
前記接続がTCP接続である、請求項２６記載のトラフィック制約された無線ブリッジ。
【請求項３１】
前記受け取り確認がTCP受け取り確認である、請求項２６記載のトラフィック制約された無線ブリッジ。
【請求項３２】
前記受け取り確認を単一の受け取り確認に集積する手段をさらに含む、請求項２６記載のトラフィック制約された無線ブリッジ。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【公開番号】特開２０１３−１３０９３（Ｐ２０１３−１３０９３Ａ）
【公開日】平成２５年１月１７日（２０１３．１．１７）
【国際特許分類】
【出願番号】特願２０１２−１６１２９８（Ｐ２０１２−１６１２９８）
【出願日】平成２４年７月２０日（２０１２．７．２０）
【分割の表示】特願２００９−５５４４９５（Ｐ２００９−５５４４９５）の分割
【原出願日】平成１８年１２月２０日（２００６．１２．２０）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＨＤＭＩ
【出願人】（５０１２６３８１０）トムソン ライセンシング (2,848)
【氏名又は名称原語表記】Ｔｈｏｍｓｏｎ Ｌｉｃｅｎｓｉｎｇ
【住所又は居所原語表記】１−５， ｒｕｅ Ｊｅａｎｎｅ ｄ’Ａｒｃ， ９２１３０ ＩＳＳＹ ＬＥＳ ＭＯＵＬＩＮＥＡＵＸ， Ｆｒａｎｃｅ
【Ｆターム（参考）】
【公開日】平成２５年１月１７日（２０１３．１．１７）
【国際特許分類】
【出願日】平成２４年７月２０日（２０１２．７．２０）
【分割の表示】特願２００９−５５４４９５（Ｐ２００９−５５４４９５）の分割
【原出願日】平成１８年１２月２０日（２００６．１２．２０）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＨＤＭＩ
【出願人】（５０１２６３８１０）トムソン ライセンシング (2,848)
【氏名又は名称原語表記】Ｔｈｏｍｓｏｎ Ｌｉｃｅｎｓｉｎｇ
【住所又は居所原語表記】１−５， ｒｕｅ Ｊｅａｎｎｅ ｄ’Ａｒｃ， ９２１３０ ＩＳＳＹ ＬＥＳ ＭＯＵＬＩＮＥＡＵＸ， Ｆｒａｎｃｅ
【Ｆターム（参考）】
[ Back to top ]