JP4813602B2 - 時分割多重アクセス媒体アクセス制御層における媒体アクセス制御プロトコル・データ単位集積 - Google Patents

Description

本発明は、無線ビデオ配信（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）に専用の帯域幅が与えられる。ここでの「／」の使用は、同じ構成要素についての代替名を表す。マルチメディア・トラフィックはたいていマスター・デバイスから若干数のリモート・デバイスへの下りなので、各時間割り当てにおける複数PHYパケットに起因するオーバーヘッド（プリアンブル、PHYヘッダ、フレーム間の間隔［InterFrame Spacing］）をなくして、それによりネットワーク効率を上げ、利用可能な正味のビット・レートを上げる機会がある。

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

IEEE802.16も、別個のMPDUが始まるところを示すスーパーMACフレームの始めにおけるMAPを使う、ある形のMPDU集積を含んでいる。いずれの方法も、IEEE802.16リンクの効率を上げるが、MPDUがPHYキャラクタ境界上で始まることを要求する。これは、MAC層とPHY層との間に、望ましいよりも多くの協働を含意する。

いくつかのサービス・プロバイダーは、同軸ケーブル、電話線および／または電力線に基づく、新たな配線のない（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を使用する。現在のところ、IEEE802.15.3はMACレベルの集積を行う機能を含んでいない（MSDUについてもMPDUについても）。よって、集積を追加する際、本発明は、できるだけ標準的な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）に基づくこともできる。時によっては、トラフィックのすべてが下りであることができ（非対称）、いくらか対称的であるときもある。すべての利用可能な時間割り当て／スロットをフルに利用することが望ましい。

従来は、たいていのWLANの通常動作のためには、一つのMACプロトコル・データ単位（MPDU）が各物理（PHY）PDU（PPDU）において無線リンク／チャネルを通じて送信される。しかしながら、その際、CTA内の時間の多くはフレーム間の間隔（IFS: inter-frame spacing）、PHYプリアンブルおよびPHYヘッダのために使われる。本願におけるビデオ／データ・トラフィックは、二つ以上のフレームに付随することができる時間スロットにおいて送信されるので、できるだけ効率的にCTAを使うためにこのオーバーヘッドをなくす機会がある。

本発明において、MACプロトコル層の最下部にあるMPDUは、結果としてのフレームがPHYサービス・データ単位（PSDU: PHY Service Data Unit）としてPHYに渡される前に集積される。この構造は、図１４に示されるようにスーパーMACフレーム（SuperMACFrame）と称される。スーパーMACフレームを生成するためには、MPDU-1についての標準的なMACヘッダがまずフレーム中に入れられ、それにヘッダ訂正コード（HCC: Header Correction Code）が続き、それにペイロード（ビデオ／データ）およびMPDU-1のフレーム検査シーケンス（FCS: frame check sequence）が続く。このプロセスは繰り返され、CTAがいっぱいになるか送信待ち行列が空になるまで、適切な送信待ち行列からMACフレームを引き出す。

本発明の方法は、いくつかの利点がある。IFSならびに中間的なPHYプリアンブルおよびPHYヘッダをなくすことは、MACの効率、したがってスループットを大幅に改善する。これはより少ないオーバーヘッドにつながる。MACヘッダを保護するためにHCCを加えることは、長さフィールドを含む、より早いMPDUヘッダの一つにおける誤りの場合、CTAの終わりに向けて搬送されるMDPUを回復する確率を高める。HCCを使うと、ヘッダを、したがって、受信器においてスーパーMACフレーム内の次のMPDUを位置特定するのに必要な長さを回復するずっとよい可能性がある。誤り検出方式のみが使用される場合には、MPDU長が誤っていたのか他の何らかのMACヘッダ・フィールドが誤っていたのかはわからないだろう。何であれ所与のMPDUの長さを知ることなくしては、スーパーMACフレームから後続のMPDUを回復することは不可能である可能性が高い。これが重要なのは、効率を上げる本発明のシステムのもう一つの側面が、他の多くのWLANについての10%に比べてたった1%のMACパケット誤りレート（PER: Packet Error Rate）をもつことになるからである。さらに、サブヘッダに代わって実際のMACヘッダが本発明のMSDUの集積において使用されるので、標準的なMACの大半が再利用できる（フラグメンテーション（fragmentation）および再組み立て（reassembly）、ブロックACK等を含めて）。唯一の変更は、スーパーMACフレームがPHY層に渡される前のMAC層の最下部においてである。こうして、本発明は、複数のMPDUを一つのPSDUに集積し、IFSならびにPHYヘッダおよびプリアンブルをなくすことによって、各時間スロットにおいて送られる実際のデータ・ビットの数を増す。

物理プロトコル・データ単位においてマルチメディア・ストリーム（たとえばビデオ、声、オーディオなど……）・スーパーMACフレームを生成する方法および装置であって、物理層ヘッダをチャネル時間割り当てに挿入し、前記マルチメディア・ストリーム・スーパーMACフレームを生成することを含むものが記載される。前記生成はさらに、前記物理層ヘッダのあとに媒体アクセス制御ヘッダをアペンドし、ヘッダ訂正コードを計算し、前記媒体アクセス制御ヘッダのあとに前記ヘッダ訂正コードをアペンドし、送信待ち行列からの媒体アクセス制御マルチメディア・ストリーム・ペイロードをアペンドし、フレーム検査シーケンスを計算し、前記媒体アクセス制御マルチメディア・ストリーム・ペイロードのあとに前記フレーム検査シーケンスをアペンドし、前記チャネル時間割り当てがいっぱいになるかすべての送信待ち行列が空になるかの一方まで、前記物理層ヘッダを挿入した後に前記諸動作を繰り返すことを含む。物理プロトコル・データ単位内の受信されたマルチメディア・ストリーム・スーパーMACフレームを復号する方法および装置であって、媒体アクセス制御ヘッダを単離し、ヘッダ訂正コードを単離し、前記媒体アクセス制御ヘッダにおける誤りを検査し訂正し、前記マルチメディア・ストリーム・スーパーMACフレーム内のマルチメディア・ストリーム・ペイロードのある単位について境界を決定し、前記マルチメディア・ストリーム・スーパーMACフレームからすべてのマルチメディア・ストリーム・ペイロードが回復されるまで、上記の諸動作を繰り返し、前記スーパーMACフレーム内の前記マルチメディア・ストリーム・ペイロードをマルチメディア・ストリーム・イーサネット（登録商標）・フレームに変換することを含むものが記載される。

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

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

本発明は、TDMAサービスをサポートするIEEE802.15.3b MACを出発点とする（スーパーフレームの先頭におけるビーコンおよびスーパーフレーム内の諸伝送時間割り当て）。IEEE802.15.3bは、最小IFS（MIFS: minimum IFS）を使ってCTA内でPHYパケットを送信することによるPHY PDU（PPDU）集積をサポートする。このIFSは、（本発明でのように）あるデバイスからのパケットが連続して送られるときに使用できる。しかしながら、各PPDUに関連するMIFSならびにPHYプリアンブルおよびヘッダは、PHY層におけるクロック・ドリフトを最小化するということを除いて何の付加価値もなしでオーバーヘッドを追加する。本発明は、PHYオーバーヘッドの量を減らすことによって、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デコーダおよび無線ハブをも有する。本発明は、必要とされる一般的なIP WAN/LANルーティングはないと想定する。マスター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制御ミドルウェアはCDIドライバ５２５と制御情報を交換する。デバイス・ドライバ５２５は主としてビデオ・データをネットワーク・インターフェース（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制御６２０およびCDIドライバ６２５の両方とインターフェースをもつ。メディア・ストリーム・ミドルウェア６１５はビデオ・データをデバイス・ドライバ６２５から受け容れ、媒体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はビデオ・データおよび制御情報を無線電波インターフェースと交換する。

ここで図７を参照する。図７は、本発明の原理に基づく無線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フレームを優先度を含むイーサネット（登録商標）・フレームに変換する。ソフトウェア・モジュール１２６０は、転送テーブルおよびサービス・フロー情報もデータ記憶ユニット１２６５から受信する。

PNCはイーサネット（登録商標）・フレームを受信し、図１３に示されるようなCTA1〜CTA3でのDEV1〜DEV1への送信のために、ビーコンおよびフレームを構築する。図１３は一つのCTAを示している。ひとたびCTA長が決定されたら、PNCは、図１４に示されるようなスーパーMACフレーム（IEEE802.15.3のMACフレームの非標準的な集合体）を構築する。スーパーMACフレームは、最後のMACフレームのフラグメンテーションを含むCTAを満たすよう構築される。この非標準的な充填は、CTA1、CTA2またはCTA3内で送られるフレームの一例である。スーパーMACフレームは次いで同期送信のためにPHY層に転送される。CTAは、ビーコンにおいて広告された時間ぴったりに始まる。

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

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

ここで図１４を参照すると、各MACペイロードについて、対応するMACヘッダがある。だが、MACヘッダとMACペイロードは別個である。MACは、ペイロード中の誤りを検出するためのフレーム検査シーケンス（FCS）を計算する。しかしながら、標準的なIEEE802.15.3で行われるように、MACヘッダを単一のPHYヘッダと集積して、組み合わされたヘッダを保護するためのヘッダ検査シーケンス（HCS: Header Check Sequence）を計算する代わりに、本発明の方法は、各MACヘッダ内の誤りを訂正するためのヘッダ訂正コード（HCC）を計算する。そのHCCは、MACヘッダの後かつMACペイロードの前に挿入される。MACヘッダは、長さなど、MACペイロードに関する重要な情報を含む。長さは、次のMPDUの開始位置を特定するために必要とされる。それが失われると、そのCTA内の残りのMDPUが失われる。ペイロード内の誤りがFCSを介してのちに検出されるとしても、再送信率をできるだけ低く保つため、できるだけ多くのMDPUを回復することが望ましい。

FCSLが計算され、MACペイロードの後に挿入される。これは、スーパーMACフレームを作り出すために各MACペイロードについてなされる。スーパーMACフレーム長は物理ヘッダの一部である。物理ヘッダは、CTAを作るためにスーパーMACフレームより前に挿入される。スーパーMACフレームは空中を通じた同期送信のためにPHY層に転送される。物理ヘッダは遅い、信頼できるレートで送信される。CTAはビーコンにおいて広告された時間ぴったりに始まる。CTAのスーパーMACフレーム部分は何らかの望ましいレートで送信される。受信MAC層は、MPDUヘッダおよびHCCを使って各MPDUを単離してから、誤りを検査してイーサネット（登録商標）・フレームに変換する。

CTA4、CTA5およびCTA6内のフレームの送信は同様にして送られる。これらのCTAの一つにおいて送られるフレームの一例が図１５に示されている。図１５は、単一の上りCTAの一つ（DEV-xからPNC）を描いている。単一の上りCTAは一つの物理フレームと、保護されたヘッダをもつMACフレームの集合と、CTA内の任意の余った時間を含む。図１３に示された下りCTAと同様、物理フレームは物理プリアンブルおよび物理ヘッダを含む。MACフレームの集合はPNCへの遅延されたACK、PNCへの待ち行列状態情報およびPNCへのデータ・パケットを含む。このCTAが、PNCに待ち行列状態情報を運び戻すフレームを含んでいることを注意しておく。この待ち行列状態情報は待ち行列のサイズ（もし可変なら）、待ち行列中のフレーム数、フレームの平均長および待ち行列の入力におけるフレーム到着レートを含んでいてもよい。

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

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

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

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

Claims (14)

1. 物理プロトコル・データ単位においてマルチメディア・ストリーム・スーパーMACフレームを生成する方法であって：
   物理層ヘッダをチャネル時間割り当てに挿入する段階と；
   前記マルチメディア・ストリーム・スーパーMACフレームを生成する段階とを有し、前記生成する段階がさらに：
   前記物理層ヘッダに媒体アクセス制御ヘッダをアペンドする段階と；
   ヘッダ訂正コードを計算する段階と；
   前記媒体アクセス制御ヘッダに前記ヘッダ訂正コードをアペンドする段階と；
   前記ヘッダ訂正コードに送信待ち行列からの媒体アクセス制御マルチメディア・ストリーム・ペイロードをアペンドする段階と；
   フレーム検査シーケンスを計算する段階と；
   前記媒体アクセス制御マルチメディア・ストリーム・ペイロードに前記フレーム検査シーケンスをアペンドする段階と；
   前記チャネル時間割り当てがいっぱいになるかすべての送信待ち行列が空になるかの一方になるまで、前記物理層ヘッダを挿入した後に前記諸段階を繰り返す段階とを有する、
   方法。
2. 前記物理層ヘッダを第一の所定のレートで送信する段階をさらに有する、請求項１記載の方法。
3. 前記マルチメディア・ストリーム・スーパーMACフレームを、前記第一の所定のレートとは異なる第二の所定のレートで送信する段階をさらに有する、請求項２記載の方法。
4. 前記物理層ヘッダが、前記スーパーMACフレームの長さを含む、請求項１記載の方法。
5. 前記媒体アクセス制御ヘッダが前記マルチメディア・ストリーム・ペイロードの長さを含む、請求項１記載の方法。
6. 前記ヘッダ訂正コードが、前記媒体アクセス制御ヘッダ内の誤りを訂正するために使用される、請求項１記載の方法。
7. 受信されたマルチメディア・ストリーム・スーパーMACフレームを復号する方法であって：
   媒体アクセス制御ヘッダを単離する段階と；
   ヘッダ訂正コードを単離する段階と；
   前記媒体アクセス制御ヘッダにおける誤りを検査し、訂正する段階と；
   前記マルチメディア・ストリーム・スーパーMACフレーム内のマルチメディア・ストリーム・ペイロードのある単位について境界を決定する段階と；
   前記マルチメディア・ストリーム・スーパーMACフレームからすべてのマルチメディア・ストリーム・ペイロードが回復されるまで、上記の諸動作を繰り返す段階と；
   前記マルチメディア・ストリーム・スーパーMACフレームをマルチメディア・イーサネット（登録商標）・フレームに変換する段階とを有する、
   方法。
8. 物理プロトコル・データ単位においてマルチメディア・ストリーム・スーパーMACフレームを生成する装置であって：
   物理層ヘッダをチャネル時間割り当てに挿入する手段と；
   前記マルチメディア・ストリーム・スーパーMACフレームを生成する手段とを有し、前記生成する手段がさらに：
   前記物理層ヘッダに媒体アクセス制御ヘッダをアペンドする手段と；
   ヘッダ訂正コードを計算する手段と；
   前記媒体アクセス制御ヘッダに前記ヘッダ訂正コードをアペンドする手段と；
   前記ヘッダ訂正コードに送信待ち行列からの媒体アクセス制御マルチメディア・ストリーム・ペイロードをアペンドする手段と；
   フレーム検査シーケンスを計算する手段と；
   前記媒体アクセス制御マルチメディア・ストリーム・ペイロードに前記フレーム検査シーケンスをアペンドする手段と；
   前記チャネル時間割り当てがいっぱいになるかすべての送信待ち行列が空になるかの一方になるまで、前記物理層ヘッダを挿入した後に前記諸動作を繰り返す手段とを有する、
   装置。
9. 前記物理層ヘッダを第一の所定のレートで送信する手段をさらに有する、請求項８記載の装置。
10. 前記マルチメディア・ストリーム・スーパーMACフレームを、前記第一の所定のレートとは異なる第二の所定のレートで送信する手段をさらに有する、請求項９記載の装置。
11. 前記物理層ヘッダが、前記スーパーMACフレームの長さを含む、請求項８記載の装置。
12. 前記媒体アクセス制御ヘッダが前記マルチメディア・ストリーム・ペイロードの長さを含む、請求項８記載の装置。
13. 前記ヘッダ訂正コードが、前記媒体アクセス制御ヘッダ内の誤りを訂正するために使用される、請求項８記載の装置。
14. 物理プロトコル・データ単位受信されたマルチメディア・ストリーム・スーパーMACフレームを復号する装置であって：
    物理層ヘッダを単離する手段と；
    媒体アクセス制御ヘッダを単離する手段と；
    ヘッダ訂正コードを単離する手段と；
    前記媒体アクセス制御ヘッダにおける誤りを検査し、訂正する手段と；
    前記マルチメディア・ストリーム・スーパーMACフレーム内のマルチメディア・ストリーム・ペイロードのある単位について境界を決定する手段と；
    前記マルチメディア・ストリーム・スーパーMACフレームからすべてのマルチメディア・ストリーム・ペイロードが回復されるまで、前記物理層ヘッダの後に、上記の諸動作を繰り返す手段と；
    前記マルチメディア・ストリーム・スーパーMACフレームをマルチメディア・ストリーム・イーサネット（登録商標）・フレームに変換する手段とを有する、
    装置。

Images