JP5095751B2

JP5095751B2 - Ｔｄｍａｍａｃ層における適応時間割り当て

Info

Publication number: JP5095751B2
Application number: JP2009541273A
Authority: JP
Inventors: スタール，トマス，アンソニー; ティアン，チンジャン; ローズ，ロバート，アンドリュー
Original assignee: Thomson Licensing SAS
Current assignee: Thomson Licensing SAS
Priority date: 2006-12-13
Filing date: 2006-12-13
Publication date: 2012-12-12
Anticipated expiration: 2026-12-13
Also published as: EP2123034A4; EP2123034B1; US9084177B2; CN101569190B; US20100054215A1; WO2008073089A1; CN101569190A; KR101303513B1; EP2123034A1; JP2010514255A; KR20090089413A

Description

本発明は、無線ビデオ・サーバー・システムにおける、セットトップボックス（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）と何らかの特別なまたは新たな通信をもつことを要求しないことが望ましい。したがって、現在配信されているMACレベルのトラフィックの型に適応する家庭配信システムを有することが望ましい。

IEEEにおいて現在標準化中であるIEEE802.11Nはビデオ配信のための手段として求められている。IEEE802.11Nの主題である技術に関してはいくつかの懸念がある。第一に、それは相変わらずCSMA（IEEE802.11）に基づいている。この型のMAC層は本来的に非効率的であり、QoS保証を提供しない。多くのMACレベルQoS向上がIEEE802.11Nに追加されているが、CSMAベースのMACがTDMA MACほど効率的になりうるとは考えにくい。QoS向上は、IEEE802.11Eからの優先度ベースのQoSおよび何らかの形のポーリングを含む。これらの向上は、IEEE802.11ネットワークのリソースを管理することにおいて非常に有用でありうるが、無線家庭ビデオ配信システムのために必要または望ましいQoS保証をするものではない。ポーリングは、本発明を運用する基盤となるTDMA様のサービスを作り出すために使用できるが、ポーリング自身がMAC効率の妨げになる。MAC効率は、無線ネットワークについては、家庭のよりリモートな領域に利用可能な限られたリンク速度のため、より一層重要である。たいていの現行の無線LANは、共通伝送媒体（すなわち、同じ伝送周波数での無線スペクトル）を利用する。そのため、MACはその媒体を共有する機構を必要とする。

いくつかのサービス・プロバイダーは、同軸ケーブル、電話線および／または電力線に基づく、新たな配線のない（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）に基づいたMACを使用する。基本的なTDMA機能については標準的なMACが使用されるが、アプリケーションやミドルウェア・ソフトウェアを変更することなくデータ・トラフィック・パターンに適応する機能が追加される。

本発明が設計される対象となる典型的なシステムは、三つまでのクライアント／リモート・デバイスにインターネット・プロトコル（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）によって要求される固定された時間スロットであることができる。しかしながら、CTA時間が要求されるにしろ設定されるにしろ、IPトラフィック特性の全てを先験的に本当に知っているデバイスはない。トラフィックは、ユーザー・データグラム・プロトコル（UDP: user datagram protocol）（ACK返信なし）に基づくことができ、伝送制御プロトコル（TCP: transmission control protocol）に基づくこともできる。時によっては、トラフィックのすべてが下りであることができ（非対称）、いくらか対称的であるときもある。すべての利用可能な時間割り当て／スロットをフルに利用することが望ましい。

本発明のある側面によれば、マスター・ブリッジング・デバイスがCTA時間を適応的な仕方で設定する。マスター・ブリッジング・デバイスはすべての送信待ち行列（各CTA時間について一つ）の状態に関する情報を受信する。状態情報は、待ち行列内のパケット数、待ち行列内のパケットの平均長さおよびパケット待ち行列到着レートといったものの最小限の集合を含む。各送信待ち行列についてのサービス・レートは、対応するCTA時間の長さに比例する。CTAは、合計するとスーパーフレームの長さにならなければならず、そのスーパーフレームは通例周期的な割合で生起するという意味で制約されている。よって、本発明では、マスターSTBは、より満たされているおよび／またはより高い入力到着レートをもつ待ち行列に、より多くの時間を割り当てる。使用される基準の詳細に依存して、多くの異なる適応アルゴリズムが可能である。本発明では、平均待ち行列レベルは、従来の技法を使って推定される。それらの表式（すなわち、各CTAに関連付けられたパフォーマンス基準、この場合は平均待ち行列レベル）を和、平均二乗誤差などといった全体的な計量〔メトリック〕に組み合わせる。次いで、適応的な処理技術を使ってCTAを割り当てる。割り当ては、ある意味で最適である、メトリックの最小のまわりで動作するような仕方で行われる。本発明のシステムは、任意の所与の定常状態トラフィック・パターンについてスループットを最大にするような仕方でCTAを割り当てるように迅速に適応できるが、その上、新しいパターンにも数スーパーフレーム以内に迅速に適応できるという利点がある。前記システムはまた、これらの最適な割り当てがトラフィック・パターンに基づいて決定されるという利点もある。トラフィック・パターンに対する制御はなく、各デバイスについて固定量の帯域幅（BW）を「予約する」ために十分な情報はないと想定されている。本発明はまた、アプリケーション・レベル（この場合には、ビデオを搬送するプロトコルを含むビデオ・システム・ミドルウェア）にいかなる変更も要求しないという利点もある。

マルチメディア・ストリームを無線で再配信する方法および装置であって、マスター・デバイスにおいてソースからマルチメディア・ストリームを受信し、送信待ち行列および送信チャネル条件についての状態情報に応じてチャネル時間割り当てを適応的に決定し、前記マルチメディア・ストリームから、前記下りチャネル時間割り当てに挿入するためのスーパーフレームを構築し、チャネル時間割り当てを無線送信して前記マルチメディア・ストリームのリモート・デバイスへの再配信を実施することを含むものが記載される。また、再配信されたマルチメディア・ストリームを無線で受信する方法であって、ビーコン信号およびチャネル時間割り当てを受信し、前記再配信されたマルチメディア・ストリームを受信することを含むものも記載される。

本発明は、以下の詳細な記述を付属の図面との関連で読むことから最もよく理解される。図面は以下の図を含む。

本発明の原理に基づく例示的な無線家庭ビデオ配信システムを示す図である。 MACレベル・ブリッジを示す図である。一般的な無線ブリッジを示す図である。本発明のある例示的な実施形態における、無線家庭ビデオ配信に好適な、制約された経路をもつ無線ブリッジを示す図である。マスターSTBおよび無線MACブリッジのサーバー側のソフトウェアのブロック図（論理構造）を示す図である。リモート／クライアントSTBおよび無線MACブリッジのクライアント側のソフトウェアのブロック図（論理構造）を示す図である。本発明の原理に基づいてCTAがどのように使用されるかを示す、無線高精細度（high definition）MACブリッジのブロック図である。本発明に基づくスーパーフレームを描いた図である。ビデオ・サーバー（マスターSTB）に接続されたPNCのための高レベルの送信パケット流れ図である。ビデオ・サーバー（マスターSTB）に接続されたPNCのための高レベルの受信パケット流れ図である。ビデオ・クライアント（リモートSTB）に接続されたDEV-xのための高レベルの送信パケット流れ図である。ビデオ・クライアント（リモートSTB）に接続されたDEV-xのための高レベルの受信パケット流れ図である。一般的なMACスイッチ転送機能の図である。単一の下りCTA（PNCからDEV-x）を描いた図である。スーパーMAC（MACフレームの非標準的な集積体）および物理フレーム・フォーマットを描いた図である。単一の上りCTA（DEV-xからPNC）を描いた図である。本発明の原理に基づくPNCのフローチャートである。本発明の原理に基づく単一待ち行列モデルを描いた図である。本発明の原理に基づく複数無線送信待ち行列を描いた図である。

本発明は、TDMAサービスをサポートするIEEE802.15.3B MACを出発点とする（スーパーフレームの先頭におけるビーコンおよびスーパーフレーム内の諸伝送時間割り当て）。他のTDMA MACもあり、使うことができる（たとえばIEEE802.16）が、従来技術においては、純粋にMAC層にとって利用可能なトラフィック特性に基づいて動的にCTA長さを割り当てる試みはされていない。

CTAを設定するときに考慮されなければならないTCPのいくつかの特徴がある。TCPは、32ビットのシーケンス番号および要求番号ならびに16ビットのスライディング・ウィンドウ長さフィールドを利用する転送プロトコルである。これら三つの数は、「停止して待機（Stop-and-Wait）」または「N個戻る（Go-Back-N）」ARQ〔自動再送要求〕エラー修復方式を実装するために使われる。送信待ち行列内および送信される過程にあるTCPパケットは「ネットワーク内にある」ので、TCPウィンドウは、それらのパケットが未決（outstanding）であることを許容するために宛先によって十分大きく設定されなければならない。本発明は、そのウィンドウのサイズを設定することに対して制御をもたないが、CTAおよびスーパーフレーム長さの初期選択は、問題を最小化するのに十分短く選ぶことができる。スーパーフレームの長さは、変化するTCPウィンドウ・サイズを扱えるよう、調節可能（または適応可能）にされてもよい。

10msecのスーパーフレームについては、約19個の1400バイトTCPパケットが10msec毎に送信される。これで26,600バイトになる。例示的な実施形態の以下の記述の目的のために、約165キロバイトの送信バッファ待ち行列を選んだ。TCPウィンドウ・サイズは64キロバイトを超える未決データを許容しないので、TCPトラフィックについては送信バッファ待ち行列は決してオーバーフローしない。ウィンドウが、CTAが完全に満たされることすら許容しないほど十分小さいことさえありうる。このため、短いスーパーフレーム（5msec）で始めるほうがよい。すると、送信バッファ待ち行列は、少なくとも単一のTCPセッションを扱うことができるためには、51キロバイトより大きい必要はない。しかしながら、例示的な実施形態のために165キロバイトの送信バッファ待ち行列を選んだのは、UDPを通じて送られるビデオの場合に紛失パケットを回避するためである。

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にどのくらいの時間を割り当てるべきかのいくらかの不確定性がある。というのも、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.13.3b MAC層管理エンティティ（MLME: MAC layer management entity） SAPの上に層として重ねられる。IEEE802.13.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はビデオ・データおよび制御情報をそれぞれ無線電波インターフェースと交換する。ソフトウェア５６５および５６０が、CTAを適応的に決定し、ビーコン信号および下りパケットを下りCTA内において送信し、再配信されたビデオ／メディアが受信されたというMACレベルのACK／NAKを受信する。

図６は、クライアント側（リモート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.13.3b MLME SAPの上に層として重ねられる。IEEE802.13.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フレームを優先度を含むイーサネット（登録商標）・フレームに変換する。ソフトウェア・モジュール１２６０は、転送テーブルおよびサービス・フロー情報もデータ記憶ユニット１２６５から受信する。

IEEE802.1Dに記載されるような一般的なスイッチ転送機能の図が図１３に示されている。図１３における一つの送信待ち行列は図９における送信待ち行列の組に対応する。一般的な優先度サポートのため、図１３では、送信ポート当たり複数の待ち行列がある。その機能は図９および図１１では明示的には示されていない。他の機能のいくつかの順序は、この図と図９および図１１とではわずかに異なっている（たとえば、フレームがいつIEEE802.3からIEEE802.15.3に変換されるかなど）が、最終的な機能性は同じである。PNCはイーサネット（登録商標）・フレームを受信し、図１４に示されるようなCTA1〜CTA3でのDEV1〜DEV1への送信のために、ビーコンおよびフレームを構築する。図１４は一つのCTAを示している。ひとたびCTA長が決定されたら、PNCは、図１５に示されるようなスーパーMACフレーム（IEEE802.15.3のMACフレームの非標準的な集合体）を構築する。スーパーMACフレームは、最後のMACフレームのフラグメンテーションを含むCTAを満たすよう構築される。この非標準的な充填は、CTA1、CTA2またはCTA3内で送られるフレームのほんの一例であり、MAC PDUが単一のPHYパケットにまとめられることは必須ではない。スーパーフレームは次いで同期送信のためにPHY層に転送される。CTAは、ビーコンにおいて広告された時間ぴったりに始まる。

図１４を参照すると、物理プリアンブルおよび物理ヘッダがCTA当たり一つの物理フレームをなす。リモートSTBへの遅延されたACK、リモートSTBへの待ち行列状態情報要求およびリモートSTBへの複数データ・パケットが、保護されたMACヘッダとともにMACフレームの集合をなす。上記がそのCTA内での任意の余っている時間と連結されたものが、リモートSTBへのそのPNCのための下りCTAをなす。

CTAに入れられる最初および／または最後のMPDUはもとのMACペイロードのフラグメントからなっていていもよいことを注意しておく。IEEE802.15.3のMACヘッダはフラグメンテーションおよび再組み立てのための情報を含むので、本稿で記載される方法は、さらなる説明なしで、フラグメンテーション（fragmentation）および再組み立て（reassembly）を含むことができることを理解しておくべきである。

ここで図１５を参照すると、各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内の任意の余った時間を含む。図１４に示された下りCTAと同様、物理フレームは物理プリアンブルおよび物理ヘッダを含む。MACフレームの集合はPNCへの遅延されたACK、PNCへの待ち行列状態情報およびPNCへのデータ・パケットを含む。このCTAが、PNCに待ち行列状態情報を運び戻すフレームを含んでいることを注意しておく。この待ち行列状態情報は待ち行列のサイズ（もし可変なら）、待ち行列中のフレーム数、フレームの平均長および待ち行列の入力におけるフレーム到着レートを含んでいてもよい。

本発明は、固定長の5msecまたは10msecのスーパーフレームを使用する。スーパーフレームおよびCTAの長さが固定されている場合については、表１がいくつかの合理的な値を示す。表２はいくつかの個別的な想定のもとで各CTA内で期待されるパケットの概数を示す。しかしながら、先に述べたように、本発明は、待ち行列オーバーフローを最小にし、時間の利用を最大にし、それにより高い効率を達成するために、CTAの長さと、および可能性としてはスーパーフレーム長さえをも適応させることを含む。

本発明では、PNCは諸CTAおよび可能性としてはスーパーフレームの長さを適応的な仕方で決定する。これを行うため、PNCは送信される必要のあるトラフィックについての情報を必要とする。PNCは明らかに、それに埋め込まれた三つの送信待ち行列についての情報を得ることができる。リモートDEVの送信待ち行列についての情報を得るために、リモートDEVが、スーパーフレーム毎に、そのCTA内において、待ち行列状態情報を（新しいコマンドにおいて）送る。動作の流れは図１７のフローチャートに従う。PNCはすべての送信待ち行列（各CTAについて一つ）に関する情報を受信する。状態情報は、待ち行列中のパケット数、待ち行列中のパケットの平均長およびパケット待ち行列到着レートおよびもし可変なら待ち行列サイズのようなものの最小限の集合を含む。

例示的な実施形態でマスターSTBに関連付けられているPNCにおける適応のための高レベルのフローチャートが図１７に示されている。１７０５において、PNCは、はいってくるトラフィックが短いTCPウィンドウを示す場合、スーパーフレームの長さを短くする。はいってくるトラフィックが短いTCPウィンドウを示すことは、戻りトラフィックがマスターSTBに送られた後に、はいってくるトラフィックの短いバーストがある場合に真である。１７１０で、PNCは待ち行列状態（ローカルおよびリモート）についての情報を取得する。PNCは、１７１５において待ち行列状態情報およびリンク速度情報を処理して新しいCTA長を計算し、スーパーフレームの出ていく部分を構築してそれを送信のために物理層に転送する。１７２５では、はいってくるパケット（CTA4〜6）が受信され、MACフレームが単離され、待ち行列状態情報が記憶され、MACデータ・フレームがイーサネット（登録商標）・フレームに変換されて、マスターSTBに転送される。１７３０でスーパーフレームが所定の数、たとえば5で割れるかどうかを判定する試験が行われる。その所定の数で割れれば、処理は１７０５に進む（すなわち、スーパーフレーム長は5スーパーフレームに一回調節される）。スーパーフレームがその所定の数で割れなければ、処理は１７１０に進む。

図１８は、本発明の原理に基づく、単一待ち行列モデルを描いている。図１９は、本発明の原理に基づく複数無線待ち行列を描いている。

送信待ち行列についてのパケット・サービス・レートは、対応するCTAの長さに比例する。CTAは、合計するとスーパーフレームの長さにならなければならないという点で制約されている。本発明では、マスターSTBは、より満たされているおよび／または入力到着レートがより高い待ち行列により多くの時間を割り当てる。本発明では、平均待ち行列レベルが従来技術の諸方法を使って推定される。平均待ち行列レベルは、和、平均二乗誤差などといった全体的な計量〔メトリック〕に組み合わされる。適応的な処理技術を使ってシステムにCTA時間を割り当てさせる。割り当ては、ある意味で最適である、メトリックの最小のまわりでシステムが動作するような仕方で行われる。システムは、任意の所与の定常状態トラフィック・パターンについてスループットを最大にするような仕方でCTAを割り当てるように迅速に適応できるが、いくつかのスーパーフレーム内で新しいパターンに迅速に適応できるという利点がある。本発明はまた、これらの最適な割り当てをトラフィック・パターンに基づいて見出すという利点もある。トラフィック・パターンに対する制御はなく、各デバイスについて固定量の帯域幅を「予約する」ために十分な情報はないと想定されている。

上記の記述は、高精細度ビデオ配信用途に好適な一つのマスターおよび三つのクライアント・デバイスをもつ無線ブリッジング・システムに焦点を当ててきたが、当業者には、それらの方法が一般的な無線TDMA MACに、またさらには共通媒体（たとえば電力線）上で走る有線TDMA MACにも拡張できることは明らかなはずである。

本発明がさまざまな形のハードウェア、ソフトウェア、ファームウェア、特殊目的プロセッサまたはそれらの組み合わせにおいて実装されうることは理解しておくものとする。好ましくは、本発明はハードウェアおよびソフトウェアの組み合わせとして実装される。さらに、ソフトウェアは好ましくは、プログラム記憶デバイス上に具体的に具現されたアプリケーション・プログラムとして実装される。アプリケーション・プログラムは、いかなる好適なアーキテクチャを有する機械にアップロードされ、これにより実行されてもよい。好ましくは、その機械は、一つまたは複数の中央処理装置（CPU）、ランダム・アクセス・メモリ（RAM）および入出力（I/O）インターフェースといったハードウェアをもつコンピュータ・プラットフォーム上で実装される。コンピュータ・プラットフォームはまた、オペレーティング・システムおよびマイクロ命令コードをも含む。本稿に記載されるさまざまなプロセスおよび機能は、前記マイクロ命令コードの一部または前記アプリケーション・プログラムの一部（またはそれらの組み合わせ）であってもよい。それはオペレーティング・システムを介して実行される。さらに、追加的なデータ記憶装置および印刷装置のようなさまざまな他の周辺装置が前記コンピュータ・プラットフォームに接続されてもよい。

付属の図面に描かれている構成要素となるシステム・コンポーネントおよび方法ステップのいくつかは好ましくはソフトウェアで実装されるので、システム・コンポーネント（またはプロセス・ステップ）どうしの間の実際の接続は、本発明がプログラムされる仕方に依存して異なることがありうることを理解しておくべきである。本稿の教示を与えられれば、当業者は本発明のこれらおよび同様の実装または構成を考えることができるであろう。

Claims

マルチメディア・ストリームを無線で再配信する方法であって：
マスター・デバイスにおいてソースからマルチメディア・ストリームを受信する段階と；
複数のリモート・デバイスに対応する複数の送信待ち行列についての状態情報および送信チャネル条件に応答してチャネル時間割り当てを適応的に決定する段階と；
前記マルチメディア・ストリームから下りチャネル時間割り当てに挿入するためのスーパーフレームを構築する段階と；
前記マルチメディア・ストリームのリモート・デバイスへの再配信を実施するために前記下りチャネル時間割り当てを無線で送信する段階とを有する、
方法。
前記構築する段階がさらに：
ビーコン信号、前記チャネル割り当て時間を送信する段階と；
前記マルチメディア・ストリームを、該マルチメディア・ストリームのリモート受信器に再配信する段階とを有する、
請求項１記載の方法。
前記再配信されたマルチメディア・ストリームが前記リモート受信器によって受信されたという受け取り確認を受信する段階をさらに有する、請求項２記載の方法。
前記ソースからの前記マルチメディア・ストリームがイーサネット（登録商標）・フレームとしてパッケージ化されており、当該方法がさらに：
前記イーサネット（登録商標）・マルチメディア・フレームをフィルタリングして送信待ち行列に分類する段階と；
前記イーサネット（登録商標）・マルチメディア・フレームから媒体アクセス制御層フレームを構築する段階をさらに有する、
請求項１記載の方法。
前記送信待ち行列のうちで、より充填されている、より高い入力到着レートをもつ、およびより充填された待ち行列かつより高い入力到着レートの組み合わせのうちの一つであるものにより多くのチャネル時間を割り当てることをさらに含む、請求項４記載の方法。
前記決定する段階が、前記送信待ち行列の状態に関して受信された情報に基づく、請求項１記載の方法。
前記送信待ち行列の状態に関する前記情報が、各送信待ち行列中のパケット数、各送信待ち行列中のパケットの平均長さおよび推定された入力パケット到着レートを含む、請求項６記載の方法。
前記チャネル割り当て時間および前記ビーコン信号の和が前記スーパーフレームの長さに等しい、請求項２記載の方法。
前記スーパーフレームの長さが前記送信待ち行列の長さおよび下りチャネル条件に基づいて調節可能である、請求項４記載の方法。
前記チャネル時間割り当てが前記リモート受信器から受信された待ち行列状態情報に基づいて適応的に決定される、請求項２記載の方法。
前記チャネル時間割り当てが、ある計量を最小化することに基づいて適応的に決定される、請求項２記載の方法。
前記チャネル時間割り当てが、利用可能なトラフィック特性に基づいて適応的に決定される、請求項２記載の方法。
前記チャネル時間割り当てが、各送信待ち行列内の期待されるパケット数を最小化することに基づいて適応的に決定される、請求項４記載の方法。
前記チャネル時間割り当てが、前記送信待ち行列のいずれかがオーバーフローする確率を最小化することに基づいて適応的に決定される、請求項２記載の方法。
マルチメディア・ストリームを無線で再配信する装置であって：
マスター・デバイスにおいてソースからマルチメディア・ストリームを受信する手段と；
複数のリモート・デバイスに対応する複数の送信待ち行列についての状態情報および送信チャネル条件に応答してチャネル時間割り当てを適応的に決定する手段と；
前記マルチメディア・ストリームから下りチャネル時間割り当てに挿入するためのスーパーフレームを構築する手段と；
前記マルチメディア・ストリームのリモート・デバイスへの再配信を実施するために前記下りチャネル時間割り当てを無線で送信する手段とを有する、
装置。
前記構築する手段がさらに：
ビーコン信号、前記チャネル割り当て時間を送信する手段と；
前記マルチメディア・ストリームを、該マルチメディア・ストリームのリモート受信器に再配信する手段とを有する、
請求項１５記載の装置。
前記再配信されたマルチメディア・ストリームが前記リモート受信器によって受信されたという受け取り確認を受信する手段をさらに有する、請求項１６記載の装置。
前記ソースからの前記マルチメディア・ストリームがイーサネット（登録商標）・フレームとしてパッケージ化されており、当該装置がさらに：
前記イーサネット（登録商標）・マルチメディア・フレームをフィルタリングして送信待ち行列に分類する手段と；
前記イーサネット（登録商標）・マルチメディア・フレームから媒体アクセス制御層フレームを構築する手段をさらに有する、
請求項１５記載の装置。
前記送信待ち行列のうちで、より充填されている、より高い入力到着レートをもつ、およびより充填された待ち行列かつより高い入力到着レートの組み合わせのうちの一つであるものにより多くのチャネル時間を割り当てる手段をさらに含む、請求項１８記載の装置。
前記決定する動作が、前記送信待ち行列の状態に関して受信された情報に基づく、請求項１５記載の装置。
前記送信待ち行列の状態に関する前記情報が、各送信待ち行列中のパケット数、各送信待ち行列中のパケットの平均長さおよび推定された入力パケット到着レートを含む、請求項２０記載の装置。
前記チャネル割り当て時間および前記ビーコン信号の和が前記スーパーフレームの長さに等しい、請求項１６記載の装置。
前記スーパーフレームの長さが前記送信待ち行列の長さおよび下りチャネル条件に基づいて調節可能である、請求項１８記載の装置。
前記チャネル時間割り当てが前記リモート受信器から受信された待ち行列状態情報に基づいて適応的に決定される、請求項１６記載の装置。
前記チャネル時間割り当てが、ある計量を最小化することに基づいて適応的に決定される、請求項１６記載の装置。
前記チャネル時間割り当てが、利用可能なトラフィック特性に基づいて適応的に決定される、請求項１６記載の装置。
前記チャネル時間割り当てが、各送信待ち行列内の期待されるパケット数を最小化することに基づいて適応的に決定される、請求項１８記載の装置。
前記チャネル時間割り当てが、前記送信待ち行列のいずれかがオーバーフローする確率を最小化することに基づいて適応的に決定される、請求項１６記載の装置。
無線媒体アクセス制御ブリッジである、請求項１５記載の装置。