JP6850893B2 - 拡張マルチキャストネットワーク通信 - Google Patents

Description

本発明は、拡張マルチキャストネットワーク通信に関する。

メディアアクセス制御（ＭＡＣ）層におけるデータフレームの従来のネットワーク化された通信は、典型的には、ユニキャストまたはマルチキャスト通信のいずれかを含む。各々のデータフレーム通信の形態には、既知の欠点がある。それらの欠点のため、テレビ（ＴＶ）ストリーミングサービスなどの大量の帯域幅を消費するサービス用のデータフレームの生成およびルーティングに対応する、代替の、また改良した通信の形態が所望される。

変更マルチメディア・データフレームを生成およびルーティングするための、コンピュータ記憶媒体に対しエンコードされたコンピュータプログラムを備える方法、システム、装置。１つの態様では、方法は、第１ネットワークノードが、複数のチャンネルの各チャンネルについて、複数のチャンネルについてのリーフノードのメンバシップを示すデータを含むチャンネルメンバシップデータを維持することと、前記複数のチャンネルの各チャンネルについて、前記チャンネルメンバシップデータに基づいて、前記チャンネルにアクセスするように購読（サブスクライブ）されている前記リーフノードを決定することと、前記チャンネルにアクセスするように購読されている前記リーフノードに基づいて、（ｉ）ハブノード識別子と（ｉｉ）前記チャンネルにアクセスするように購読されている各リーフノードの宛先アドレスを記述するデータと（ｉｉｉ）ペイロードとを含む、前記チャンネルについての変更マルチメディア・データフレームを生成することと、前記第１ネットワークノードが、生成された前記変更マルチメディア・データフレームを第２ネットワークノードに送信することと、の作用を備えてよい。マルチメディアコンテンツデータをネットワークの複数のそれぞれのノードに送信するように複数のユニキャスト・データフレームを用いる代わりに、単一の変更マルチメディア・データフレームが、マルチメディアコンテンツをネットワークの複数のノードに送信するように用いられることが可能であり、それによって、ネットワークトラフィックを減少させ、利用可能な帯域幅を増加させ、その利用可能な帯域幅を用いて追加のデータの送信を可能とする。

他のバージョンは、コンピュータ記憶デバイスに対しエンコードされた方法の作用を行うための、対応するシステム、装置、およびコンピュータプログラムを含む。
これらのバージョンおよび他のバージョンは、以下の特徴のうちの１または複数を任意に含んでよい。例えば、いくつかの実装では、前記変更マルチメディア・データフレームは、ＭＡＣヘッダとペイロードとを含み得るユニキャスト・データフレームを含み、前記ＭＡＣヘッダは宛先アドレスフィールドを含み得る。

いくつかの実装では、変更マルチメディア・データフレームを生成することは、前記チャンネルにアクセスするように購読されている各リーフノードについての宛先アドレスを宛先アドレスのエンコードされたビットマップへとエンコードすることと、前記宛先アドレスフィールドに宛先アドレスの前記エンコードされたビットマップを投入することと、を含んでよい。

いくつかの実装では、方法は、前記第２ネットワークノードが、前記変更マルチメディア・データフレームのうちの１つ以上を受信することと、前記第２ネットワークノードが、宛先アドレスの前記エンコードされたビットマップに基づいて、前記１つ以上の変更マルチメディア・データフレームの宛先である後続のネットワークノードの数を識別することと、前記後続のネットワークノードの数が１ネットワークノードよりも大きいと決定することに応じて、（ｉ）前記後続のネットワークノードの各々の宛先アドレスを記述するデータと（ｉｉ）前記ペイロードのコピーとを含む変更マルチメディア・データフレームを生成することと、を含んでよい。

いくつかの実装では、方法は、前記第２ネットワークノードが、前記変更マルチメディア・データフレームのうちの１つ以上を受信することと、前記第２ネットワークノードが、宛先アドレスの前記エンコードされたビットマップに基づいて、前記１つ以上の変更マルチメディア・データフレームの宛先である後続のネットワークノードの数を識別することと、前記後続のネットワークノードの数が１ネットワークノードに等しいと決定することに応じて、（ｉ）該１つの後続のネットワークノードの宛先アドレスを記述するデータと（ｉｉ）前記ペイロードのコピーとを含むユニキャスト・データフレームを生成することと、を含んでよい。

変更マルチメディア・データフレームを生成およびルーティングするためのシステムの一例のコンテキスト図。 変更マルチメディア・データフレームを生成するための処理の一例のフローチャート。 変更マルチメディア・データフレームをルーティングするための処理の一例のフローチャート。 変更マルチメディア・データフレームを生成およびルーティングするためのシステムのコンポーネントのブロック図。

本開示は、テレビ（ＴＶ）データフレームなどのマルチメディア・データフレームをブロードキャストするためのシステムおよび方法を対象とする。本開示は、例えば、ビットマップアドレスをリーフ・ネットワークノードにマッピングするデータを含み得る１または複数のメンバシップテーブル交換と組合せた使用のための変更されたマルチメディア・データフレームを生成することによって、従来の方法に対する利点を達成する。変更マルチメディア・データフレームは、例えば、複数のリーフ・ネットワークノードの各リーフ・ネットワークノードについての宛先アドレスを記述するデータをユニキャスト・データフレームの宛先アドレスフィールドへ挿入可能な宛先アドレスのビットマップにエンコードするための小型アドレッシングスキームを用いて生成されるデータを通信するために用いられ得るユニキャスト・データフレームを含んでよい。変更マルチメディア・データフレームおよびメンバシップテーブル交換によって、従来のユニキャスト送信に関連してＴＶコンテンツなどのコンテンツをストリーミングするために必要な帯域幅の削減が可能となる。さらに、変更マルチメディア・データフレームおよびメンバシップ交換テーブルによって、ユニキャスト・データフレームを用いたマルチキャストに似たデータフレームブロードキャストも可能となり、従来のマルチキャストブロードキャスティングに必要なマルチキャスト・スパニングツリーの頻繁な再計算に関する費用のかかる処理が避けられる。

図１は、変更マルチメディア・データフレームを生成およびルーティングするためのシステム１００の一例のコンテキスト図である。システム１００は、ネットワーク１０５、１次ノード１１０を含む複数のネットワークノード、１または複数のハブノード１１２−１，１１２−２，１１２−ｎ（ここでｎは１から６４までの任意の正の整数）、無線メッシュネットワーク１２０、および複数のリーフノード“Ａ”１５０，“Ｂ”１５１，“Ｃ”１５２，“Ｄ”１５３，“Ｅ”１５４，“Ｆ”１５５，“Ｇ”１５６，“Ｈ”１５７，“Ｉ”１５８，“Ｊ”１５９を備える。

１次ノード１１０は、インターネットなどのネットワーク１０５と１または複数のハブノード１１２−１，１１２−２，１１２−ｎとの間に配置されているネットワークノードである。１次ノード１１０は、有線接続１０２を通じて有線データフレーム１０７などのデータを受信し、無線ハブ１１２−１，１１２−２，１１２−ｎへの送信用に無線データフレーム、有線データフレーム、またはその両方を生成する。１次ノードは、例えば、ファイバハット（ｆｉｂｅｒ ｈｕｔ）、光ネットワークユニット、マルチメディアフィードサーバ、ＴＶフィードサーバなどを含んでよい。１次ノード１１０は、光信号など１または複数の信号として受信したデータを対応するハブノードにルーティングする中継器として作用してよい。ハブノード１１２−１，１１２−２，１１２−ｎは、１次ノード１１０と１組の１または複数のリーフノード“Ａ”１５０，“Ｂ”１５１，“Ｃ”１５２，“Ｄ”１５３，“Ｅ”１５４，“Ｆ”１５５，“Ｇ”１５６，“Ｈ”１５７，“Ｉ”１５８，“Ｊ”１５９との間に配置されているネットワークノードである。各それぞれのハブノード１１２−１，１１２−２，１１２−ｎは、ファイバ線などの入力データ線を、１または複数のリーフノード“Ａ”１５０，“Ｂ”１５１，“Ｃ”１５２，“Ｄ”１５３，“Ｅ”１５４，“Ｆ”１５５，“Ｇ”１５６，“Ｈ”１５７，“Ｉ”１５８，“Ｊ”１５９の組に対応する束にグループ化する。

１次ノード１１０は、チャンネル購読データを維持するように構成される。チャンネル購読データは、複数のチャンネルの各チャンネルに対するリーフノードのメンバシップを記述するデータを含んでよい。いくつかの実装では、チャンネル購読データは、テーブルを用いてチャンネルごとのベースにて維持されてよい。チャンネル購読データは、各チャンネルについて、そのチャンネルのメンバであるリーフノード“Ａ”１５０，“Ｂ”１５１，“Ｃ”１５２，“Ｄ”１５３，“Ｅ”１５４，“Ｆ”１５５，“Ｇ”１５６，“Ｈ”１５７，“Ｉ”１５８，“Ｊ”１５９などのネットワークノードを決定するようにアクセスされてよい。ネットワークノードがチャンネルのメンバであるのは、例えば、そのネットワークノードが、そのチャンネルによって提供されるコンテンツにそのネットワークノードがアクセスできる購読を有する場合である。チャンネルによって提供されるコンテンツへのアクセスは、例えば、チャンネルによって提供されるコンテンツを閲覧するためのアクセスを含んでよい。チャンネルは、例えば、ＴＶチャンネルを含んでよい。これに代えて、チャンネルは、例えば、ＹｏｕＴｕｂｅ（登録商標）チャンネルなどのインターネットマルチメディアチャンネルを含んでよい。

１次ノード１１０は、複数の変更マルチメディア・データフレーム１３０を生成するように構成される。例えば、１次ノード１１０は、特定のストリーミングサーバによって提供される複数のチャンネルの各チャンネル（各々それぞれのデータストリームと考えられ得る）について、ハブノード１１２−１，１１２−２，１１２−ｎごとに変更マルチメディア・データフレーム１３０を生成してよい。これに代えて、またはこれに加えて、１次ノード１１０は、特定のチャンネルからのコンテンツについてのネットワークノードからの要求に応じて、変更マルチメディア・データフレーム１３０を生成してよい。

変更マルチメディア・データフレーム１３０は、ＭＡＣヘッダ１３２およびペイロード１３４を含む、メディアアクセス制御（ＭＡＣ）層における通信用のユニキャスト・データフレームを含む。変更マルチメディア・データフレーム１３０のＭＡＣヘッダ１３２は、宛先アドレスフィールド１４０を含む。変更マルチメディア・データフレーム１３０の宛先アドレスフィールド１４０は、変更マルチメディア・データフレーム１３０を従来のユニキャスト・データフレームと区別する。変更マルチメディア・データフレーム１３０は、ハブノードＩＤ（ＨｕｂＮｏｄｅＩＤ）１４２、定数１４４、および宛先アドレスデータ１４６を含む。ハブノードＩＤ１４２は、変更マルチメディア・データフレーム１３０がルーティングされるハブノード１１２−１，１１２−２，１１２−ｎを識別するように用いられる。定数１４４は、（ｉ）宛先アドレスデータ１４６がローカルに管理されたアドレスであること、（ｉｉ）データフレームが変更マルチメディア・データフレームであること、または（ｉｉｉ）その両方であることを示すように用いられる。

宛先アドレスデータ１４６は、変更マルチメディア・データフレーム１３０のペイロードについての宛先である、複数のリーフノードの各リーフノードの宛先アドレスを表すデータを含む。これは、従来のユニキャスト・データフレームが、その唯一の宛先である単一のノードの単一の宛先アドレスしか含み得ないのとは異なる。宛先アドレスデータ１４６は、マルチメディア・データフレーム１３０が生成される時に作り出されてよい。いくつかの実装では、１次ノード１１０は、各リーフノードについての宛先アドレスを記述するデータを、ＭＡＣヘッダ１３２の宛先アドレスフィールド１４０の宛先アドレスデータフィールド１４６へと挿入される宛先アドレスのビットマップへとエンコードすることによって、変更マルチメディア・データフレーム１３０を生成してよい。

変更マルチメディア・データフレームのペイロードがＭＡＣヘッダ１３２の宛先アドレスフィールド１４０へとルーティングされる、複数の宛先ノードの各宛先ノードの各宛先アドレスをエンコードすることによって、ネットワーク帯域幅をより効率的に用いるシステムが得られる。これは、マルチメディアコンテンツデータをネットワークの複数のそれぞれのノードに送信するように複数のユニキャスト・データフレームを用いる代わりに、単一の変更マルチメディア・データフレーム１３０が、マルチメディアコンテンツをメッシュネットワーク１２０の複数のノードに送信するように用いられることが可能なためである。これは、ネットワークトラフィックを減少させ、利用可能な帯域幅を増加させ、その利用可能な帯域幅を用いて追加のデータの送信を可能とする。

いくつかの実装では、ＭＡＣヘッダ１３２の宛先アドレスフィールド１４０は、４８ビットからなる６バイトを含む。最上位バイトのうちの最下位２ビットは、０ｘ１１などの定数に固定されてよい。最上位バイトの残り６ビットは、１次ノード１１０の下において特定のハブノード１１２−１，１１２−２，１１２−ｎを識別するように用いられ得るハブノードＩＤ１２である。残る５バイトの各ビットは、宛先アドレスフィールド１４０のハブノードＩＤ１４２によって識別されるハブノードの下のリーフノードに１対１にマッピングされる。そうした実装では、残る４０ビットによって確立される１対１のマッピングによって、各ハブノード１１２−１，１１２−２，１１２−ｎについてアドレス決定可能な４０のリーフノードが得られる。したがって、このアドレッシングスキームは、一般に１次ノードの下の無線トポロジ内の２＾６＊４０＝２５６０のノードをサポートする。４０ビットのビットマップにおける特定のビットへのリーフノードのマッピングは、１次ノード１１０によって事前に各リーフノードと共有され、近傍のトポロジの存続期間中には変化しない。すなわち、４０ビットのビットマップにおける特定のビットへのリーフノードのマッピングは、例えば、比較的珍しいイベントであり得る、新たな購読者（サブスクライバ）が新たな購読を開始する時など、ノードメンバシップの永久的な変化があるときのみ更新されてよい。４０ビットのビットマップにおける特定のビットへのリーフノードのマッピングのこの準静的な状態は、各チャンネル変化についてスパニングツリーの動的な再計算を必要とする従来のマルチキャスティング通信を超えて効率を増加させる。

１次ノード１１０は、変更マルチメディア・データフレーム１３０を、変更マルチメディア・データフレーム１３０のハブノードＩＤ１４２によって識別されるハブノード１１２−ｎにルーティングしてよい。次いで、ハブノード１１２−ｎは、変更マルチメディア・データフレーム１３０を、ハブノード１１２−ｎが関連付けられているリーフノードネットワークのリーフノード“Ａ”１５０などの第１リーフノードに送ってよい。各リーフノード“Ａ”１５０，“Ｂ”１５１，“Ｃ”１５２，“Ｄ”１５３，“Ｅ”１５４，“Ｆ”１５５，“Ｇ”１５６，“Ｈ”１５７，“Ｉ”１５８，“Ｊ”１５９は、購読者の家、職場、または他の場所における受信ユニット（例えば、セットトップボックス、テレビ、デスクトップコンピュータ、ラップトップコンピュータ、スマートフォンなど）など、可能性のあるデータフレームの宛先地点を表す。

「リーフノード」は、（ｉ）宛先エンドポイントとして、変更マルチメディア・データフレームを受信し、マルチメディア・データフレームのペイロードを取得および使用するために変更マルチメディア・データフレームを処理し、また（ｉｉ）必要に応じて、変更マルチメディア・データフレームを１または複数の他のノード（別のリーフノードまたはリーフノードではないノードを含み得る）に送信する、ノードである。しかしながら、リーフノード“Ｈ”１５７，“Ｉ”１５８，“Ｊ”１５９，および“Ｇ”１５６などのいくつかの「リーフノード」は、変更マルチメディア・データフレームの受信と送信との両方を行う能力があるが、リーフノード“Ｈ”１５７，“Ｉ”１５８，“Ｊ”１５９，および“Ｇ”１５６が変更マルチメディア・データフレームを送信する必要がないように、やがて特定時点においてネットワークに配置されてよい。例えば、単にリーフノード“Ｈ”１５７，“Ｉ”１５８，“Ｊ”１５９，および“Ｇ”１５６は、それらのリーフノードが変更マルチメディア・データフレームを他のリーフノードに送信しない特定時点において、特定のネットワーク構成に存在する（例えば、リーフノード“Ｈ”１５７，“Ｉ”１５８，“Ｊ”１５９，および“Ｇ”１５６の後に階層的に配列されるリーフノードがない）からといって、そうしたリーフノードが変更マルチメディア・データフレームを送信することができない、変更マルチメディア・データフレームを過去に送信してない、または変更マルチメディア・データフレームを将来送信しない、ということは意味しない。

例えば、メッシュネットワーク１２０は将来いくつかの地点に再構成されることが可能であり、リーフノード“Ｈ”１５７，“Ｉ”１５８，“Ｊ”１５９，および“Ｇ”１５６の後に階層的に配列される１または複数のリーフノードを得る。そうしたシナリオの下では、リーフノード“Ｈ”１５７，“Ｉ”１５８，“Ｊ”１５９，および“Ｇ”１５６のうちの１または複数が、変更マルチメディア・データフレームを送信する場合が生じてよい。異なる例を参照すると、リーフノード“Ｈ”１５７，“Ｉ”１５８，“Ｊ”１５９，および“Ｇ”１５６のうちの１または複数が、リーフノード“Ｈ”１５７，“Ｉ”１５８，“Ｊ”１５９，および“Ｇ”１５６の後に階層的に配列されていた１または複数のリーフ・ネットワークノードを有し得たように、メッシュネットワーク１２０が過去に異なるように構成され得たことも可能である。そうした場合には、リーフノード“Ｈ”１５７，“Ｉ”１５８，“Ｊ”１５９，および“Ｇ”１５６のうちの１または複数は、変更マルチメディア・データフレームを、“Ｈ”１５７，“Ｉ”１５８，“Ｊ”１５９，および“Ｇ”１５６の後に階層的に配列されている他のリーフノードに送信することが可能である。

各リーフノードは、変更マルチメディア・データフレーム１３０などの変更マルチメディア・データフレームをルーティングするように用いられることが可能なビットマップテーブル１６０などのメンバシップ交換テーブルを記憶してよい。ビットマップテーブル１６０は、１次ノード１１０によって生成されてよく、次いで、１次ノード１１０によって各それぞれのリーフノード“Ａ”１５０，“Ｂ”１５１，“Ｃ”１５２，“Ｄ”１５３，“Ｅ”１５４，“Ｆ”１５５，“Ｇ”１５６，“Ｈ”１５７，“Ｉ”１５８，“Ｊ”１５９に分配されてよい。いくつかの実装では、ビットマップテーブル１６０は、純粋なＪＳＯＮ（ＪａｖａＳｃｒｉｐｔ（登録商標） Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ）フォーマットにおいて共有されてよい。ＪＳＯＮフォーマットは、ファイルにおいて、プロトコルバッファを介して、または１次ノード１１０から各それぞれのリーフノードへのリモートプロシージャコール（ＲＰＣ）によって共有されてよい。テーブルは、購読を開始するリーフノード、購読を解除するリーフノードなどといった１または複数のチャネルに対するリーフノードの購読状態の変化の際にのみ更新される。

いくつかの実装では、１次ノード１１０が、購読を有しないリーフノードに変更マルチメディア・データフレームを送信しないので、リーフノードの購読解除は無視される（また、ビットマップテーブル１６０は更新されない）。したがって、システム１００は、１または複数の新たなリーフノードが購読を開始した後の時点まで１または複数のリーフノードを取り除くように、ビットマップテーブルを更新するのを待機することが可能である。

ビットマップテーブル１６０は、ハブ１１２−ｎなどの特定のハブノードの下に階層的に組織された各リーフノードについてのビットマップアドレスを含む。ビットマップテーブル１６０の各行は、１６１，１６２，１６３，１６４，１６５，１６６，１６７，１６８，１６９，１７０をマッピングするリーフノード１６０ｂに対するビットマップアドレス１６０ａを含む。次いで、リーフノードは、変更マルチメディア・データフレーム１３０についての宛先であるリーフノードの組の各々を決定するように、（ｉ）変更マルチメディア・データフレーム１３０において受信される宛先アドレスのビットマップにエンコードされた１組の宛先アドレスを（ｉｉ）ビットマップテーブル１６０における各リーフノードのビットマップアドレス１６０ａと比較することが可能である。

いくつかの実装では、ビットマップテーブル１６０を受信する各それぞれのリーフノード“Ａ”１５０，“Ｂ”１５１，“Ｃ”１５２，“Ｄ”１５３，“Ｅ”１５４，“Ｆ”１５５，“Ｇ”１５６，“Ｈ”１５７，“Ｉ”１５８，“Ｊ”１５９は、迅速および効率的な分枝（ブランチング）操作を容易にするように用いることが可能なビットマスク対ネクストホップ（次のホップ）のテーブルを作り出すことが可能である。このビットマスク対次のリーフノードのテーブルによって、宛先アドレスの受信されたビットマップについて可能なルーティングの各宛先を事前計算することが可能となる。この場合、宛先アドレスの与えられたビットマップについての宛先ルートが予め決定されており、またビットマップテーブル１６０を用いてリアルタイムに計算される必要がないので、単にビットマップテーブル１６０を用いるよりも分枝操作が効率的となる。

例として、リーフノード“Ａ”１５０は変更マルチメディア・データフレーム１３０を受信してよく、変更マルチメディア・データフレーム１３０をその目標の宛先ノードにルーティングするように分枝操作の実行を開始してよい。リーフノード“Ａ”１５０は、各リーフノードに記憶されているビットマップテーブル１６０を考慮して、宛先アドレスデータ１４６を解析することによって分枝操作の実行を開始することが可能である。宛先アドレスデータ１４６を解析することは、変更マルチメディア・データフレーム１３０から取得される宛先アドレスデータ１４６をビットマップテーブル１６０によって維持されるデータと比較することを含んでよい。

マルチメディア・データフレーム１３０は、宛先アドレスのビットマップを含んでよい。すなわち、宛先アドレスのビットマップの各ビットは、特定のリーフノードが変更マルチメディア・データフレーム１３０の宛先であるか否かを示すことが可能である。例えば、リーフノード“Ａ”１５０にて受信されたマルチメディア・データフレーム１３０が、“０１１１１１０１１０”１８０などの宛先アドレスのビットマップを含むと仮定する。ビットマップテーブル１６０を用いると、リーフノード“Ａ”１５０は、“０１１１１１０１１０”１８０などの宛先アドレスのビットマップがリーフノード“Ｂ”１５１，“Ｃ”１５２，“Ｅ”１５４，“Ｆ”１５５，“Ｇ”１５６，“Ｈ”１５７，および“Ｉ”１５８が変更マルチメディア・データフレーム１３０の宛先であることを示すと決定することが可能である。したがって、リーフノード“Ａ”１５０は、リーフノード“Ａ”１５０が変更マルチメディア・データフレーム１３０の宛先ではないと決定し、変更マルチメディア・データフレーム１３０に関連付けられているペイロードをリーフノード“Ｂ”１５１，“Ｃ”１５２，“Ｅ”１５４，“Ｆ”１５５，“Ｇ”１５６，“Ｈ”１５７，および“Ｉ”１５８に送信するように必要なルーティング動作を実行することが可能である。

リーフノード“Ａ”１５０は、１または複数の次のリーフノード宛先によりリーフノード宛先をグループ化することによって、変更マルチメディア・データフレーム１３０のルーティングを実行し続ける。例えば、リーフノード“Ａ”１５０は、変更マルチメディア・データフレームの宛先アドレスフィールドにエンコードされた宛先アドレスのビットマップに基づいて、次のリーフノード宛先がリーフノード“Ｂ”１５１およびリーフノード“Ｃ”１５２を含むと決定してよい。いくつかの実装では、次のリーフノード宛先を決定するこの段階は、受信された変更マルチメディア・データフレーム１３０に含まれる宛先アドレスのビットマップを、ビットマスク対次のリーフノードのテーブルにアクセスして変更マルチメディア・データフレームがルーティングされる１または複数の次のリーフノードを返す関数に提供することを含んでよい。これに代えて、次のリーフノード宛先は、宛先アドレスのビットマップをビットマップテーブル１６０と比較することによって計算されることが可能である。次いで、リーフノード“Ａ”１５０は、残る宛先アドレスの各々をリーフノード“Ｂ”１５１のカテゴリまたはリーフノード“Ｃ”１５２のカテゴリのいずれかのグループとすることが可能である。上述の例をさらに考慮すると、リーフノード“Ａ”１５０は、リーフノード“Ｈ”１５７、リーフノード“Ｅ”１５４、およびリーフノード“Ｉ”１５８についての宛先アドレスをリーフノード“Ｂ”１５１のカテゴリのグループとし、またリーフノード“Ｆ”１５５およびリーフノード“Ｇ”１５６についての宛先アドレスをリーフノード“Ｃ”１５２のカテゴリのグループとしてよい。

リーフノード“Ａ”１５０は、リーフノード“Ｂ”１５１およびリーフノード“Ｃ”１５２などの１または複数の次のリーフノード宛先の各々が最後のリーフノード宛先であるか否かを決定する。リーフノード“Ａ”１５０は、リーフノード宛先の数が１リーフノード宛先よりも大きいかを決定することによって、１または複数の次のリーフノード宛先の各々が最後のリーフノード宛先であるかを決定してよい。残るリーフノード宛先の数が１よりも大きい場合、リーフノード“Ａ”１５０は次のリーフノード宛先が最後の宛先ノードではないことを決定してよい。残るリーフノード宛先の数が１に等しい場合、リーフノード“Ａ”１５０は、次のリーフノード宛先が最後のリーフノード宛先であると決定してよい。

リーフノード“Ａ”１５０は、リーフノード“Ｂ”のカテゴリおよびリーフノード“Ｃ”のカテゴリが各々２以上のリーフノード宛先アドレスを含み、したがって最後のリーフノード宛先ではないと決定してよい。リーフノード“Ｂ”１５１およびリーフノード“Ｃ”１５２が最後のリーフノード宛先ではないと決定することに応じて、リーフノード“Ａ”１５０は、新たな変更マルチメディア・データフレーム１３１および新たな変更マルチメディア・データフレーム１３２を生成する。これに代えて、異なるシナリオ（例えば、異なる受信された変更マルチメディア・データフレーム１３２）の下では、リーフノード“Ａ”１５０などのリーフノードは、１または複数の次のリーフノードが変更マルチメディア・データフレームについての最後のリーフノード宛先であると代わりに決定してよい。そうした場合には、リーフノード“Ａ”１５０は、最後のリーフノード宛先への送信用のユニキャスト・データフレームを生成してよい。そうした代替は、図１の例を参照して以下においてより詳細に説明される。

変更マルチメディア・データフレーム１３１は、変更マルチメディア・データフレーム１３０の生成と同様の手法にて生成される。詳細には、変更マルチメディア・データフレーム１３１は、変更マルチメディア・データフレーム１３１の宛先アドレスフィールドにエンコードされた宛先アドレスデータに関するものを除いて、変更マルチメディア・データフレーム１３０の複製である。例えば、リーフノード“Ａ”１５０は、リーフノードカテゴリ“Ｂ”にある宛先アドレスの組を、変更マルチメディア・データフレーム１３１の宛先アドレスフィールドへとエンコードするのみである。これによって、リーフノード“Ａ”１５０が宛先アドレス“０１１００１００１０”１８１のビットマップを生成する。宛先アドレス“０１１００１００１０”１８０のビットマップは、変更マルチメディア・データフレーム１３１が、“Ｂ”，“Ｅ”，“Ｈ”，“Ｉ”を含むリーフノード宛先にルーティングされることを示す。次いで、変更マルチメディア・データフレーム１３１は、リーフノード“Ｂ”１５１にルーティングされることが可能である。変更マルチメディア・データフレーム１３１を受信すると、リーフノード“Ｂ”１５１は分枝操作を実行する。

変更マルチメディア・データフレーム１３２も、リーフノード“Ａ”１５０によって、変更マルチメディア・データフレーム１３０の生成と同様の手法にて生成される。詳細には、変更マルチメディア・データフレーム１３２は、変更マルチメディア・データフレーム１３２の宛先アドレスフィールドにエンコードされた宛先アドレスデータに関するものを除いて、変更マルチメディア・データフレーム１３０の複製である。例えば、リーフノード“Ａ”１５０は、リーフノードカテゴリ“Ｃ”にある宛先アドレスの組を、変更マルチメディア・データフレーム１３２の宛先アドレスフィールドへとエンコードするのみである。これによって、リーフノード“Ａ”１５０が宛先アドレス“０００１１００１００”１８２のビットマップを生成する。宛先アドレス“０００１１００１００”１８２のビットマップは、変更マルチメディア・データフレーム１３２が、“Ｃ”，１５２“Ｆ”１５５，および“Ｇ”１５６を含むリーフノード宛先にルーティングされることを示す。次いで、変更マルチメディア・データフレーム１３２は、リーフノード“Ｃ”１５１にルーティングされることが可能である。変更マルチメディア・データフレーム１３２を受信すると、リーフノード“Ｃ”１５２は分枝操作を実行する。

リーフノード“Ｂ”１５１は、変更マルチメディア・データフレーム１３１を受信し、リーフノード“Ａ”１５０と同様の手法にて分枝操作を実行してよい。分枝は、変更マルチメディア・データフレーム１３１の宛先アドレスフィールド１８１によって識別される後続のリーフノード宛先をグループ化するリーフノード“Ｂ”を含む。例えば、リーフノード“Ｂ”１５１は、次のリーフノード宛先がリーフノード“Ｈ”１５７およびリーフノード“Ｅ”１５４を含むと決定してよい。いくつかの実装では、次のリーフノード宛先を決定するこの段階は、受信されたマルチメディア・データフレーム１３１に含まれる宛先アドレスのビットマップを、ビットマスク対次のリーフノードのテーブルにアクセスして変更マルチメディア・データフレームがルーティングされる１または複数の次のリーフノードを返す関数に提供することを含んでよい。これに代えて、次のリーフノード宛先は、宛先アドレスのビットマップをビットマップテーブル１６０と比較することによって計算されることが可能である。次いで、リーフノード“Ｂ”１５１は、残る宛先アドレスの各々をリーフノード“Ｈ”１５７のカテゴリまたはリーフノード“Ｅ”１５４のカテゴリのいずれかのグループとすることが可能である。上述の例をさらに考慮すると、リーフノード“Ｂ”１５１は、リーフノード“Ｈ”１５７についての宛先アドレスをリーフノード“Ｈ”１５７のカテゴリのグループとし、またリーフノード“Ｅ”１５４およびリーフノード“Ｉ”１５８についての宛先アドレスをリーフノード“Ｅ”１５４のカテゴリのグループとしてよい。

リーフノード“Ｂ”１５１は、リーフノード“Ｈ”１５７およびリーフノード“Ｅ”１５４などの１または複数の次のリーフノード宛先の各々が最後のリーフノード宛先であるかを決定する。リーフノード“Ｂ”１５１は、リーフノード宛先の数が１リーフノード宛先よりも大きいかを決定することによって、特定のリーフノード宛先が最後のリーフノード宛先であるかを決定してよい。残るリーフノード宛先の数が１よりも大きい場合、リーフノード“Ｂ”１５１は次のリーフノード宛先が最後の宛先ノードではないと決定してよい。残るリーフノード宛先の数が１に等しい場合、リーフノード“Ｂ”１５１は、次のリーフノード宛先が最後のリーフノード宛先であると決定してよい。

リーフノード“Ｂ”１５０は、リーフノード“Ｈ”のカテゴリが１つのリーフノード宛先アドレスしか含まず、したがって最後のリーフノード宛先であると決定してよい。この場合には、“Ｈ”のカテゴリのメッシュネットワークの次のノード（すなわち、ノード“Ｄ”）がメッセージ１３３の最後の宛先ノードではないので、リーフノード“Ｂ”１５０は“００１０００００００”１８３のアドレスを有する変更マルチメディア・データフレーム１３３を生成し、変更マルチメディア・データフレーム１３３をノード“Ｄ”に送信する。

ノード“Ｄ”は、変更マルチメディア・データフレーム１３３を受信し、前のリーフノード“Ａ”１５０およびリーフノード“Ｂ”１５１と同様の手法にて分枝操作を実行する。例えば、リーフノード“Ｄ”１５３は、次のリーフノード宛先がリーフノード“Ｈ”１５７であると決定してよい。いくつかの実装では、次のリーフノード宛先を決定するこの段階は、受信された変更マルチメディア・データフレーム１３３に含まれる宛先アドレスのビットマップを、ビットマスク対次のリーフノードのテーブルにアクセスして変更マルチメディア・データフレームがルーティングされる１または複数の次のリーフノードを返す関数に提供することを含んでよい。これに代えて、次のリーフノード宛先は、宛先アドレスのビットマップをビットマップテーブル１６０と比較することによって計算されることが可能である。この分枝操作では、リーフノード“Ｄ”１５３は、リーフノード“Ｈ”１５７を超えて宛先アドレスのビットマップに他のリーフノード宛先アドレスがないと決定することが可能である。

リーフノード宛先アドレスのグループ化によって、単一のリーフノード宛先を含む単一のリーフノード“Ｈ”１５７のカテゴリが得られる。リーフノード“Ｄ”１５３は、リーフノード“Ｈ”１５７のカテゴリが単一のリーフノード宛先アドレスを含むのみであると決定することが可能である。リーフノード“Ｈ”１５７のカテゴリが単一のリーフノード宛先アドレスを含むのみであると決定することに応じて、リーフノード“Ｄ”１５３は、リーフノード“Ｈ”１５７の最後のリーフノード宛先への送信用に新たなユニキャストメッセージ１３４を生成する。ユニキャスト・データフレーム１３４の宛先アドレスフィールドは、リーフノード“Ｈ”１５７のアドレス“Ｈ＿Ａｄｄｒ”１８４を含む。アドレス“Ｈ＿Ａｄｄｒ”は、リーフノード“Ｈ”１５７の特定のアドレスである。ユニキャスト・データフレーム１３４は、リーフノード“Ｄ”１５３によってリーフノード“Ｈ”１５７に送信される。

それとは別に、リーフノード“Ｂ”１５１は、リーフノード“Ｅ”１５４のカテゴリが２以上のリーフノード宛先アドレスを含み、したがって最後のリーフノード宛先ではないと決定してよい。リーフノード“Ｅ”１５４が変更マルチメディア・データフレーム１３１についての最後のリーフノード宛先ではないと決定することに応じて、リーフノード“Ｂ”１５１は新たな変更マルチメディア・データフレーム１３５を生成する。

変更マルチメディア・データフレーム１３５は、変更マルチメディア・データフレーム１３１の生成と同様の手法にて生成される。詳細には、変更マルチメディア・データフレーム１３５は、変更マルチメディア・データフレーム１３５の宛先アドレスフィールドにエンコードされた宛先アドレスデータに関するものを除いて、変更マルチメディア・データフレーム１３１の複製である。例えば、リーフノード“Ｂ”１５１は、リーフノードカテゴリ“Ｅ”に関連付けられていると識別される宛先アドレスの組を、変更マルチメディア・データフレーム１３５の宛先アドレスフィールドへとエンコードするのみである。これによって、リーフノード“Ｂ”１５１が、変更マルチメディア・データフレーム１３５の宛先アドレスフィールドに含ませるための宛先アドレス“０１０００１００００”１８５のビットマップを生成する。宛先アドレス“０１０００１００００”１８５のビットマップは、変更マルチメディア・データフレーム１３５が、リーフノード“Ｅ”１５４およびリーフノード“Ｉ”１５８を含むリーフノード宛先にルーティングされることを示す。次いで、変更マルチメディア・データフレーム１３５は、リーフノード“Ｅ”１５４にルーティングされることが可能である。変更マルチメディア・データフレーム１３５を受信すると、リーフノード“Ｅ”１５４は分枝操作を実行する。

リーフノード“Ｅ”１５４は、変更マルチメディア・データフレーム１３５を受信し、前のリーフノード“Ａ”１５０およびリーフノード“Ｂ”１５１と同様の手法にて分枝操作を実行する。例えば、リーフノード“Ｅ”１５４は、次のリーフノード宛先がリーフノード“Ｉ”１５８であると決定してよい。いくつかの実装では、次のリーフノード宛先を決定するこの段階は、受信された変更マルチメディア・データフレーム１３５に含まれる宛先アドレスのビットマップを、ビットマスク対次のリーフノードのテーブルにアクセスして変更マルチメディア・データフレームがルーティングされる１または複数の次のリーフノードを返す関数に提供することを含んでよい。これに代えて、次のリーフノード宛先は、宛先アドレスのビットマップをビットマップテーブル１６０と比較することによって計算されることが可能である。この分枝操作では、リーフノード“Ｅ”１５４は、リーフノード“Ｉ”１５８を超えて宛先アドレスのビットマップに他のリーフノード宛先アドレスがないと決定することが可能である。

リーフノード宛先アドレスをグループ化することによって、単一のリーフノード宛先を含む単一のリーフノード“Ｉ”１５８のカテゴリを得る。リーフノード“Ｅ”１５４は、リーフノード“Ｉ”１５８のカテゴリが単一のリーフノード宛先アドレスを含むのみであると決定することが可能である。リーフノード“Ｉ”１５８のカテゴリが単一のリーフノード宛先アドレスを含むのみであると決定することに応じて、リーフノード“Ｅ”１５４は、リーフノード“Ｉ”１５８の最後のリーフノード宛先への送信用に新たなユニキャストメッセージ１３６を生成する。ユニキャスト・データフレーム１３６の宛先アドレスフィールドは、リーフノード“Ｉ”１５８のアドレス“Ｉ＿Ａｄｄｒ”１８６を含む。アドレス“Ｉ＿Ａｄｄｒ”は、リーフノード“Ｉ”１５８の特定のアドレスである。ユニキャスト・データフレーム１３６は、リーフノード“Ｅ”１５４によってリーフノード“Ｉ”１５８に送信される。

ネットワークシステム１００における１または複数のリーフ・ネットワークノードによって実行される分枝操作の前述の記載は、システム１００が、１次ノードからの変更マルチメディア・データフレームをリーフノードの構成を通じてそれぞれのハブノードにどのようにルーティングするかの一例を提供する。図１の残るリーフノードを通じてマルチメディア・データフレームデータフレームをルーティングするように、同一の処理が用いられてよい。例えば、リーフノード“Ａ”１５０は、変更マルチメディア・データフレーム１３２をリーフノード“Ｃ”に送信してよい。リーフノード“Ｃ”１５２は分枝操作を実行し、それぞれのユニキャスト・データフレーム１３７および１３８を生成する。各それぞれのユニキャスト・データフレーム１３７および１３８は、それぞれのユニキャスト・データフレーム１３７および１３８についての唯一の宛先である特定のリーフノードについてのアドレスを含んでよい。図１の例では、ユニキャストメッセージ１３７は“Ｆ＿Ａｄｄｒ”１８７のアドレスを含み、ユニキャストメッセージ１３８は“Ｇ＿Ａｄｄｒ”のアドレスを含む。次いで、ユニキャスト・データフレーム１３７および１３８は、リーフノード“Ｆ”１５５およびリーフノード“Ｇ”１５６の自身のそれぞれの最後の宛先にそれぞれ送信されてよい。

変更マルチメディア・データフレームの前述のルーティングは、ユニキャスト・データフレームを用いたマルチキャストのような通信を可能とするように変更されている、アドレスフィールドを有するデータフレームを用いることによって、従来の方法に対して大きな利点を提供する。これは、システム１００が、無線ネットワークにおける頻繁なリンク損失とユーザが見たいチャンネルのためのチャンネル間からの検索の間のユーザの素早いチャンネルスイープとに応じてマルチキャストブロードキャスティングシステムにおいて必要とされるマルチキャストルーティングスパニングツリーの頻繁な再計算なしに、変更マルチメディア・データフレームを効率的にルーティングすることを可能とする。従来のマルチキャストブロードキャスティングシステムが用いられた場合、変更マルチメディア・データフレームは、宛先リーフノードに到達することができないか、スパニングツリーのルーティングの再計算中に最適な帯域幅が消費されるよりも大きい。

図１の例は、１０ビットのビットマップを用いてアドレス決定される複数のリーフ・ネットワークノードの一例を提供する。しかしながら、本開示は、最大４０ビットを用いることが可能な宛先アドレスフィールドを担う。６ビットのハブノードＩＤと組み合わせると、これによって単一の１次ノードの下に２＾６＊４０＝２５６０のリーフノードが可能となる。しかしながら、本開示では、より大きなネットワークサイズさえも可能である。例えば、４０ビットの宛先アドレスフィールドの１または複数の最上位・最下位ビットがクラスタｉｄとして用いられることが可能である。例えば、最上位ビットは、ハブノードに関連付けられている第１クラスタノード“１”と同一のハブノードによって識別される第２クラスタノード“０”とを識別するように用いられることが可能である。次いで、残る３９ビットは、単一のハブノードの下の合計７８のリーフ・ネットワークノードについて、“１”の最上位ビットに関連付けられている第１クラスタノードの下の３９のノードと、また“０”の最上位ビットに関連付けられている第２クラスタノードの下の３９のノードとを識別するように用いられることが可能である。この同じ６ビットのハブノードＩＤを用いると、単一の１次ノードの下の２＾６＊２＾１＊３９＝４，９９２のリーフノードに到達することが可能である。クラスタｉｄを用いた変更マルチメディア・データフレームのルーティングは、ハブノードによるクラスタｉｄによって識別される対応するクラスタネットワークノードへの変更マルチメディア・データフレームのルーティングの追加の段階を伴う。変更マルチメディア・データフレームがクラスタネットワークノードによって受信されると、分枝操作は上述の手法にて宛先アドレスの残るビットを用いて実行されることが可能である。したがって、クラスタｉｄとして用いるための宛先アドレスフィールドの１または複数のビットを割り当てることによって、本開示は、より多数のリーフ・ネットワークノードのアドレス決定を行うように、変更マルチメディア・データフレームを用いることが可能である。

上述される図１の例は、リーフノードＡが、宛先アドレスデータ１４６を含む変更マルチメディア・データフレーム１３０を受信する一例を含む。宛先アドレスデータ１４６は、変更マルチメディア・データフレーム１３０のペイロードの宛先である複数のリーフノードの各リーフノードの宛先アドレスを表すデータを含む。宛先アドレスデータ１４６は、例えば、宛先アドレスのエンコードされたビットマップを含んでよい。しかしながら、いくつかの場合には、リーフノードＡは特定のデータフレームの唯一の宛先であってよい。そうした場合には、ハブノード１１２−ｎなどのハブノードは、アドレス“Ａ＿Ａｄｄｒ”１９０ａを含むリーフノードＡへの送信用のユニキャストメッセージ１９０を生成してよい。アドレス“Ａ＿Ａｄｄｒ”１９０ａは、リーフノード“Ａ”１５０の特定のアドレスである。ユニキャストフレーム１９０は、ハブノード１１２−ｎによってリーフノード“Ａ”１５０に送信される。リーフノード“Ａ”１５０などのリーフノードがユニキャストメッセージ１９０などのユニキャストメッセージを受信するそれらの場合には、リーフノード“Ａ”１５０は分枝を実行しない。

図２は変更マルチメディア・データフレームを生成するための処理２００の一例のフローチャートである。便宜上、処理２００は、１または複数の場所に位置する１または複数のコンピュータのシステムによって実行されるとして記載される。例えば、システム１００などのシステムは、処理２００を実行するように本明細書に従って適切にプログラムされることが可能である。

処理２００は、第１ネットワークノードが、複数のチャンネルの各々についてリーフノードのメンバシップを示すデータを含むチャンネルメンバシップデータを維持する（２１０）システムから開始する。いくつかの実装では、チャンネルメンバシップデータは、チャンネルごとのベース上のテーブルを用いて維持されてよい。チャンネル購読データは、各チャンネルについて、そのチャンネルのメンバであるネットワークノードを決定するように用いられてよい。リーフ・ネットワークノードがチャンネルに対するメンバシップを有するのは、例えば、そのリーフ・ネットワークノードが、そのチャンネルによって提供されるコンテンツにそのリーフ・ネットワークノードがアクセスできる購読を有する場合である。チャンネルによって提供されるコンテンツへのアクセスは、例えば、チャンネルによって提供されるコンテンツを閲覧するためのアクセスを含んでよい。チャンネルは、例えば、ＴＶチャンネルを含んでよい。これに代えて、チャンネルは、例えば、ＹｏｕＴｕｂｅチャンネルなどのインターネットマルチメディアチャンネルを含んでよい。

システムは、複数のチャンネルの各チャンネルについて、複数のリーフ・ネットワークノードの各々がチャンネルにアクセスするように購読されているかを決定する（２２０）。リーフノードがチャンネルにアクセスするように購読されているかを決定することは、第１ネットワークノードによって維持されているチャンネルメンバシップデータにアクセスすることを含んでよい。例えば、システムは、チャンネルメンバシップデータテーブルにアクセスすることが可能であり、また１または複数のリーフノードがチャンネルにアクセスするための購読に関連付けられているとしてリストに入れられているかを決定することが可能である。

システムは、購読されている１以上のリーフノードを有する各チャンネルについて、無線ネットワークにおける使用のための変更マルチメディア・データフレームを生成する（２３０）。チャンネル用の生成された変更マルチメディア・データフレームは、（ｉ）ハブノード識別子、（ｉｉ）定数、（ｉｉｉ）チャンネルに関連付けられている各リーフノードについての宛先アドレスを記述する宛先アドレスデータ、および（ｉｖ）ペイロードを含むデータ構造である。ハブノード識別子は、生成された変更マルチメディア・データフレームがルーティングされるハブノードを識別するように用いられる。定数は、変更マルチメディア・データフレームの宛先アドレスデータがローカルに管理されたアドレスであるか、（ｉｉ）データフレームが変更マルチメディア・データフレームであるか、または（ｉｉｉ）その両方を示すように用いられる。ペイロードは、例えば、チャンネルによるコンテンツブロードキャストの一部を含んでよい。

宛先アドレスデータは、変更マルチメディア・データフレームのペイロードについての宛先である複数のリーフノードの各々の宛先アドレスの表示であるデータを含むので、変更マルチメディア・データフレームの宛先アドレスデータは、従来のユニキャスト・データフレームに含まれる宛先アドレスとは異なる。これは、従来のユニキャスト・データフレームの宛先である単一のノードの単一の宛先アドレスのみを含み得る従来のユニキャスト・データフレームとは異なる。宛先アドレスデータは、マルチメディア・データフレームが生成される時に作り出されてよい。いくつかの実装では、変更マルチメディア・データフレームを生成することは、ＭＡＣヘッダの宛先アドレスフィールドに投入（ポピュレート）するように用いられる宛先アドレスのビットマップに各リーフノードについての宛先アドレスを記述するデータをエンコードすることを含む。

システムは、第１ネットワークノードによって、各生成された変更マルチメディア・データフレームを第２ネットワークノードに送信する（２４０）。いくつかの実装では、第２ネットワークノードは、変更マルチメディア・データフレームのハブノード識別子によって識別されるハブノードを含んでよい。

前述の処理を実行するシステムは、１以上の購読者に関連付けられている各チャンネルについて変更マルチメディア・データフレームを生成する。しかしながら、１または複数の特定のチャネルが購読者を有しない場合があり得る。そうした場合には、システムはチャンネルについての変更マルチメディア・データフレームを生成しないことを決めることが可能である。

図３は、変更マルチメディア・データフレームをルーティングするための処理３００の一例のフローチャートである。便宜上、処理３００は、１または複数の場所に位置する１または複数のコンピュータのシステムによって実行されるとして記載される。例えば、システム１００などのシステムは、処理３００を実行するように本明細書に従って適切にプログラムされることが可能である。

処理３００は、変更マルチメディア・データフレームを受信する（３１０）リーフ・ネットワークノードから開始する。受信された変更マルチメディア・データフレームは、チャンネルに関連付けられている各リーフノードについての宛先アドレスを記述する宛先アドレスデータを含むデータ構造である。宛先アドレスデータは、マルチメディア・データフレームが生成された時に作り出されていてよい。いくつかの実装では、宛先アドレスデータは、マルチメディア・データフレームの宛先である各リーフノードについての宛先アドレスのビットマップとしてエンコードされてよい。リーフ・ネットワークノードは、変更マルチメディア・データフレームを受信すると、以下の段階３２０〜３６０によって記載される分枝操作を開始してよい。

システムは、受信された変更マルチメディア・データフレームの宛先アドレスデータを解析する（３２０）。受信された変更マルチメディア・データフレームの宛先アドレスデータを解析すること（３２０）は、例えば、受信された変更マルチメディア・データフレームの宛先アドレスデータを、リーフ・ネットワークノードにて、ビットマップテーブルに記憶されているデータと比較することを含んでよい。リーフ・ネットワークノードは、マルチメディア・データフレームの宛先である１または複数のリーフノードの各々を決定するようにビットマップテーブルを使用してよい。例えば、いくつかの実装では、ビットマップテーブルは、ビットマップ対リーフ・ネットワークノードのマッピングを含んでよい。このようにして、ビットマップテーブルは、宛先アドレスのビットマップを複数のリーフノード宛先アドレスへと解釈するように用いられることが可能である。

システムは、変更マルチメディア・データフレームの宛先である１または複数の次のリーフノードを識別してよい（３３０）。いくつかの実装では、段階３３０は、次のリーフノードの宛先を識別することを含んでよく、次のリーフノードの宛先を識別することは、受信されたマルチメディア・データフレームから取得される宛先アドレスのビットマップを、事前計算された宛先アドレスデータ対次のリーフノードのテーブルにアクセスして変更マルチメディア・データフレームがルーティングされる１または複数の次のリーフノードを返す関数に提供することを含んでよい。いくつかの実装では、宛先アドレスデータ対次のリーフノードのテーブルは、ビットマップ対次のリーフノードのテーブルである。これに代えて、次のリーフノード宛先は、実行時に、宛先アドレスデータを、本明細書に記載されるビットマップテーブルなどのリーフノードにおけるルーティングテーブルと比較することによって計算されることが可能である。

システムは、次のリーフノード宛先に基づく宛先アドレスデータに基づいて識別される複数の宛先アドレスの各々をグループ化してよい（３４０）。宛先アドレスデータに基づいて識別される複数の宛先アドレスの各々をグループ化することは、次のリーフノードに対する各それぞれのリーフノードの階層的な関連性に基づいて次のリーフノード宛先の下の各宛先アドレスをクラスタすることを含む。例えば、次のリーフノード宛先に対する子ノードであるリーフノードが、次のリーフノード宛先とともにグループ化される。

システムは、各それぞれの次のリーフノードが段階３１０にて受信された変更マルチメディア・データフレームの宛先アドレス内にエンコードされる、唯一の残るリーフ・ネットワークノード宛先であるかを決定してよい（３５０）。決定する段階３５０は、段階３１０にて変更マルチメディア・データフレームを受信したリーフ・ネットワークノードによって、１以上の変更マルチメディア・データフレームの宛先である後続のネットワークノードの数を識別することを含んでよい。後続のネットワークノードの数が１リーフ・ネットワークノードよりも大きいと決定することに応じて、リーフ・ネットワークノードは、（ｉ）後続のネットワークノードの各々の宛先アドレスを記述するデータ、および（ｉｉ）ペイロードのコピーを含む変更マルチメディア・データフレームを生成してよい。後続のネットワークノードの各々の宛先アドレスを記述するデータは、後続のネットワークノードの宛先アドレスのビットマップを含んでよい。これに代えて、後続のネットワークノードの数が１リーフ・ネットワークノードに等しいと決定することに応じて、リーフ・ネットワークノードは、（ｉ）１つの後続のネットワークノードの宛先アドレスを記述するデータ、および（ｉｉ）ペイロードのコピーを含むユニキャスト・データフレームを生成してよい。このシナリオでは、１つの後続のノードの宛先アドレスを記述するデータは、単一のリーフノード宛先アドレスしか含まない。

図４は、変更マルチメディア・データフレームを生成およびルーティングするシステムのコンポーネントのブロック図である。
コンピューティングデバイス４００は、ラップトップ、デスクトップ、ワークステーション、個人用情報端末、サーバ、ブレードサーバ、メインフレーム、および他の適切なコンピュータなどの、様々な形態のデジタル・コンピュータを表すように意図されている。モバイルコンピューティングデバイス４５０は、デスクトップ、ラップトップ、タブレット、個人用情報端末、携帯電話、スマートフォン、および他の同様のコンピューティングデバイスなどの、様々な形態のモバイルコンピューティングデバイスを表すよう意図されている。本明細書に示されるコンポーネント、コンポーネント同士の接続および関係と、コンポーネントの機能とは、例示としてのみ意図されており、限定するようには意図されていない。

コンピューティングデバイス４００は、プロセッサ４０２と、メモリ４０４と、記憶デバイス４０６と、メモリ４０４および複数の高速拡張ポート４１０に接続している高速インタフェース４０８と、低速拡張ポート４１４および記憶デバイス４０６に接続している低速インタフェース４１２とを備える。プロセッサ４０２，メモリ４０４，記憶デバイス４０６，高速インタフェース４０８，高速拡張ポート４１０，および低速インタフェース４１２の各々は、様々なバスを用いて相互接続されており、共通のマザーボードに取り付けられていることもあれば、適切な場合には他の態様により取り付けられていることもある。プロセッサ４０２は、高速インタフェース４０８に結合されているディスプレイ４１６などの外部の入出力デバイス上においてグラフィカルユーザインタフェース（ＧＵＩ）用のグラフィカル情報を表示するためのメモリ４０４または記憶デバイス４０６に記憶されている命令を含む、コンピューティングデバイス４００内における実行のための命令を処理することが可能である。他の実装では、複数のプロセッサおよび／または複数のバスは、適切な場合、複数のメモリおよびある種のメモリとともに使用されてよい。さらに、複数のコンピューティングデバイスが接続されて、各デバイスが必要な動作のうちの部分を提供してよい（例えば、サーババンク、ブレードサーバのグループ、またはマルチプロセッサシステム）。

メモリ４０４は、コンピューティングデバイス４００内において情報を記憶する。いくつかの実装では、メモリ４０４は、１つ以上の揮発性メモリユニットである。いくつかの実装では、メモリ４０４は、１つ以上の不揮発性メモリユニットである。さらに、メモリ４０４は、磁気ディスクまたは光学ディスクなどの、別の形態のコンピュータ可読媒体であってもよい。記憶デバイス４０６は、コンピューティングデバイス４００のために大容量の記憶を提供できる。いくつかの実装では、記憶デバイス４０６は、フロッピー（登録商標）ディスクデバイス、ハードディスクデバイス、光ディスクデバイス、もしくはテープデバイス、フラッシュメモリもしくは他の同様のソリッド・ステート・メモリ・デバイス、またはデバイスからなるアレイ（ストレージエリアネットワークまたは他の構成のデバイスを含む）などの、コンピュータ可読媒体であってよい。他の実装では、記憶デバイス４０６は、１または複数のクラウドベースの記憶デバイスを含んでよい。命令は、情報キャリアに記憶されることが可能である。命令は、１または複数の処理デバイス（例えば、プロセッサ４０２）による実行時に、上述した方法などの１つ以上の方法を実行する。命令は、コンピュータ可読または機械可読媒体（例えば、メモリ４０４、記憶デバイス４０６、またはプロセッサ４０２上のメモリ）などの１または複数の記憶デバイスによって記憶されることも可能である。

高速制御部４０８は、コンピューティングデバイス４００のために帯域集約の動作を管理する一方、低速制御部４１２は、比較的低い帯域集約の動作を管理する。機能のそうした割り当ては、例示にすぎない。いくつかの実装では、高速制御部４０８は、メモリ４０４と、ディスプレイ４１６（例えば、グラフィクスのプロセッサまたはアクセラレータを通じて）と、様々な拡張カード（図示せず）を受容し得る高速拡張ポート４１０とに結合されている。その実装では、低速制御部４１２は、記憶デバイス４０６と低速拡張ポート４１４とに結合されている。様々な通信ポート（例えば、ＵＳＢ、Ｂｌｕｅｔｏｏｔｈ（登録商標）、イーサネット（登録商標）、無線イーサネット）を含み得る低速拡張ポート４１４は、キーボード、ポインティングデバイス、スキャナなどの、１つ以上の入出力デバイス、またはスイッチもしくはルータなどのネットワーキングデバイス（例えば、ネットワークアダプタを通じて）に結合されていてよい。

コンピューティングデバイス４００は、図に示すように、多くの異なる形態において実装されてよい。例えば、コンピューティングデバイス４００は、スタンダードサーバ４２０として実装されるか、またはそうしたサーバのグループにおいて複数回にわたって実装されてよい。さらに、コンピューティングデバイス４００は、ラップトップコンピュータ４２２などのパーソナルコンピュータにおいて実装されてよい。さらに、コンピューティングデバイス４００は、ラックサーバシステム４２４の一部として実装されてもよい。これに代えて、コンピューティングデバイス４００のコンポーネントは、モバイルコンピューティングデバイス４５０などのモバイルコンピューティングデバイス（図示せず）における他のコンポーネントと組み合わされてよい。そうしたデバイスの各々は、コンピューティングデバイス４００およびモバイルコンピューティングデバイス４５０のうちの１または複数を含んでよく、システム全体が、互いに通信する複数のコンピューティングデバイスから構成されてもよい。

モバイルコンピューティングデバイス４５０は、プロセッサ４５２と、メモリ４６４と、ディスプレイ４５４などの入出力デバイスと、通信インタフェース４６６と、送受信機４６８とをコンポーネントとして特に備える。モバイルコンピューティングデバイス４５０には、追加の記憶部を提供するために、マイクロドライブまたは他のデバイスなどの記憶デバイスがさらに提供されてよい。プロセッサ４５２，メモリ４６４，ディスプレイ４５４，通信インタフェース４６６，および送受信機４６８の各々は、様々なバスを用いて相互接続されており、コンポーネントのうちのいくつかは、共通のマザーボードに取り付けられていることもあれば、適切な場合には他の態様により取り付けられていることもある。

プロセッサ４５２は、モバイルコンピューティングデバイス４５０内において、メモリ４６４に記憶されている命令を含む命令を実行できる。プロセッサ４５２は、別個の複数のアナログプロセッサおよびデジタルプロセッサを含むチップからなるチップセットとして実装されてよい。プロセッサ４５２は、例えば、ユーザインタフェースの制御などのモバイルコンピューティングデバイス４５０の他のコンポーネントの協調と、モバイルコンピューティングデバイス４５０によって動作させられるアプリケーションと、モバイルコンピューティングデバイス４５０による無線通信とを可能にする。

プロセッサ４５２は、ディスプレイ４５４に結合されている制御インタフェース４５８およびディスプレイインタフェース４５６を通じてユーザと通信し得る。ディスプレイ４５４は、例えば、ＴＦＴ（薄膜トランジスタ液晶ディスプレイ）ディスプレイもしくはＯＬＥＤ（有機発光ダイオード）ディスプレイ、または他の適切なディスプレイ技術であってよい。ディスプレイインタフェース４５６は、グラフィカル情報および他の情報をユーザに提示するためにディスプレイ４５４を動作させるための適切な回路を備えてよい。制御インタフェース４５８は、ユーザからコマンドを受信し、プロセッサ４５２に渡すためにそのコマンドを変換してよい。さらに、外部インタフェース４６２は、他のデバイスとのモバイルコンピューティングデバイス４５０の近領域通信を可能にするように、プロセッサ４５２と通信していてもよい。外部インタフェース４６２は、例えば、いくつかの実装実施形態における有線通信または他の実装における無線通信を可能にする場合があり、さらに、複数のインタフェースが用いられてよい。

メモリ４６４は、モバイルコンピューティングデバイス４５０内において、情報を記憶する。メモリ４６４は、１つ以上のコンピュータ可読媒体と、１つ以上の揮発性メモリユニットと、１つ以上の不揮発性メモリユニットと、のうちの１つ以上として実装されることが可能である。さらに、拡張メモリ４７４が提供されるとともに、例えば、ＳＩＭＭ（シングルインラインメモリモジュール）カードインタフェースを含み得る拡張インタフェース４７２を通じてモバイルコンピューティングデバイス４５０に接続されてよい。その拡張メモリ４７４によって、モバイルコンピューティングデバイス４５０のための余分な記憶スペースが提供される場合もあれば、また、モバイルコンピューティングデバイス４５０のためのアプリケーションまたは他の情報が記憶される場合もある。具体的には、拡張メモリ４７４は、上述した処理を実行し、または補完するための命令を含んでよく、さらに、セキュア情報も含んでいてよい。したがって、例えば、拡張メモリ４７４は、モバイルコンピューティングデバイス４５０のためのセキュリティモジュールとして提供される場合もあり、モバイルコンピューティングデバイス４５０のセキュアな使用を可能にする命令に関しプログラムされていてもよい。さらに、セキュアアプリケーションは、ハッキング不可能な態様により識別情報をＳＩＭＭカード上に配置することなど、追加の情報とともにＳＩＭＭカードを介して提供される場合がある。

メモリは、例えば、下記のように、フラッシュメモリおよび／またはＮＶＲＡＭメモリ（不揮発性ランダムアクセスメモリ）を含み得る。いくつかの実装では、命令は、命令が１または複数の処理デバイス（例えば、プロセッサ４５２）により実行されたときに上述した方法などの１つ以上の方法を実行する、情報キャリアに記憶される。命令は、１または複数のコンピュータ可読または機械可読媒体（例えば、メモリ４６４、拡張メモリ４７４、またはプロセッサ４５２上のメモリ）などの１または複数の記憶デバイスによって記憶されることも可能である。いくつかの実装では、命令は、例えば、送受信機４６８または外部インタフェース４６２を通じて、伝搬信号により受信されることが可能である。

モバイルコンピューティングデバイス４５０は、必要な場合にはデジタル信号処理回路を含み得る通信インタフェース４６６を通じて無線により通信できる。通信インタフェース４６６は、特に、ＧＳＭ（モバイル通信用グローバルシステム）（登録商標）、ＳＭＳ（ショートメッセージサービス）、ＥＭＳ（拡張メッセージサービス）、またはＭＭＳ（マルチメディアメッセージサービス）、ＣＤＭＡ（符号分割多元接続）、ＴＤＭＡ（時分割多元接続）、ＰＤＣ（パーソナルデジタルセルラ）、ＷＣＤＭＡ（広帯域符号分割多元接続）（登録商標）、ＣＤＭＡ２０００、またはＧＰＲＳ（汎用パケット無線システム）など、様々なモードまたはプロトコルの下、通信を可能にし得る。そうした通信は、例えば、無線周波数を用いた送受信機４６８を通じて行われてよい。さらに、狭域通信は、Ｂｌｕｅｔｏｏｔｈ、ＷｉＦｉ（登録商標）、または他のそうした送受信機を用いることなどによって、行われてもよい。さらに、ＧＰＳ（全地球測位システム）受信機モジュール４７０は、航行および場所に関係する追加の無線データをモバイルコンピューティングデバイス４５０に提供でき、その無線データは、適切な場合には、モバイルコンピューティングデバイス４５０上において動作するアプリケーションによって使用されてもよい。

さらに、モバイルコンピューティングデバイス４５０は、ユーザから音声情報を受信し、これを使用に適したデジタル情報に変換できる音声コーデック４６０を用いて可聴の通信を行ってもよい。音声コーデック４６０は、例えば、モバイルコンピューティングデバイス４５０のハンドセットにおいて、スピーカを通じることなどによりユーザに対して可聴音を同様に生成してよい。そうした音は、音声通話からの音を含む場合もあれば、記録された音（例えば、ボイスメッセージ、音楽ファイルなど）を含む場合もあれば、また、モバイルコンピューティングデバイス４５０上において動作するアプリケーションによって生成される音を含む場合もある。

コンピューティングデバイス４５０は、図に示すように、多くの異なる形態により実装されてよい。例えば、コンピューティングデバイス４５０は、携帯電話４８０として実装されてよい。コンピューティングデバイス４５０は、スマートフォン４８２、個人用情報端末、タブレット、ラップトップ、デスクトップ、または他の同様のモバイルコンピューティングデバイスの一部として実装されてもよい。

本明細書に記載される発明の対象の実施形態、機能的な動作および処理は、デジタル電子回路に、有形的に具現化されたコンピュータソフトウェアまたはファームウェアに、本明細書に開示される構造およびそれらの構造の均等物を含むコンピュータハードウェアに、またはそれらのうちの１または複数の組合せにおいて実装されることが可能である。本明細書に記載される発明の対象の実施形態は、１または複数のコンピュータプログラム、すなわち、データ処理装置により実行するための、またはデータ処理装置の動作を制御するための、有形の不揮発性プログラムキャリアに対しエンコードされたコンピュータプログラム命令の１または複数のモジュールとして実装されることが可能である。これに代えて、またはこれに加えて、プログラム命令は、人工的に生成された伝搬信号、例えば、データ処理装置によって実行するための適切な受信装置への送信用に情報をエンコードするように生成される、機械生成される電気、光、または電磁信号に対しエンコードされることが可能である。コンピュータ記憶媒体は、機械可読記憶デバイス、機械可読記憶基板、ランダムもしくはシリアルアクセスメモリデバイス、またはそれらのうちの１または複数の組合せであることが可能である。

「データ処理装置」という用語は、プログラム可能なプロセッサ、コンピュータ、または複数のプロセッサもしくはコンピュータを例として含む、データを処理するための全ての種類の装置、デバイス、および機械を包含する。装置は、専用論理回路、例えば、ＦＰＧＡ（フィールドプログラマブルゲートアレイ）またはＡＳＩＣ（特定用途向け集積回路）を含むことが可能である。装置は、ハードウェアに加えて、当該のコンピュータプログラム用の実行環境を作り出すコード、例えば、プロセッサファームウェア、プロトコルスタック、データベース管理システム、動作システム、またはそれらのうちの１または複数の組合せを構築するコード含むことも可能である。

コンピュータプログラム（プログラムとも呼ばれるかプログラムとも記載されてよく、ソフトウェア、ソフトウェアアプリケーション、モジュール、ソフトウェアモジュール、スクリプト、またはコードであってもよい）は、コンパイルされた言語もしくは解釈された言語、または宣言型言語もしくは手続型言語を含む任意の形態のプログラム言語により記述されることが可能であり、スタンドアローンプログラムまたはモジュール、コンポーネント、サブルーチン、もしくはコンピューティング環境に用いられるのに適した他のユニットとしてのものを含む、任意の形態によりデプロイされることが可能である。コンピュータプログラムは、ファイルシステムにおけるファイルに対応してよいが、する必要はない。プログラムは、他のプログラムまたはデータ（例えば、マークアップ言語文書に記憶されている１または複数のスクリプト）を保持するファイルの一部に、当該プログラム専用のファイルに、または複数の協調ファイルに記憶されることが可能である。コンピュータプログラムは、１地点に位置するか複数地点にわたって分配され通信ネットワークにより相互接続されている１つのコンピュータ上または複数のコンピュータ上において実行されるようにデプロイされることが可能である。

本明細書に記載の処理および論理フローは、入力データを操作して出力を生成することによって機能を実行するために１または複数のコンピュータプログラムを実行する１または複数のプログラマブルプロセッサによって実行することができる。プロセスおよび論理フローは、例えばＦＰＧＡ（フィールドプログラマブルゲートアレイ）またはＡＳＩＣ（特定用途向け集積回路）などの専用論理回路によっても実行することができ、また装置もＦＰＧＡまたはＡＳＩＣとして実装されることができる。

コンピュータプログラムの実行に適したコンピュータは、汎用もしくは特殊用途のマイクロプロセッサ、もしくはその両方、または任意の他の種類の中央処理ユニットを含む。例として、コンピュータプログラムの実行に適したコンピュータは、汎用もしくは特殊用途のマイクロプロセッサ、もしくはその両方、または任意の他の種類の中央処理ユニットに基づくことが可能である。一般に、中央処理ユニットは、読み出し専用メモリ、ランダムアクセスメモリ、またはその両方から命令およびデータを受信する。コンピュータの必須要素は、命令を行うか実行するための中央処理ユニットと、命令およびデータを記憶するための１または複数のメモリデバイスである。一般に、コンピュータは、データを記憶するための１または複数の大容量記憶装置、例えば、磁気、光磁気ディスク、または光ディスクからデータを受信するか、またはそれらにデータを転送するように、またはその両方のために動作可能に結合されるか、またはそれらを含んでいる。しかしながら、コンピュータはそうした装置を有する必要はない。さらに、コンピュータは別のデバイス、例えば、数例を挙げると、携帯電話、個人用情報端末（ＰＤＡ）、モバイルオーディオまたはビデオプレーヤ、ゲームコンソール、全地球測位システム（ＧＰＳ）受信器、またはポータブル記憶デバイス（例えば、ユニバーサルシリアルバス（ＵＳＢ）フラッシュドライブ）に具現化されることが可能である。

コンピュータプログラム命令およびデータを記憶するのに適したコンピュータ可読媒体は、例えば、ＥＰＲＯＭ、ＥＥＰＲＯＭ、およびフラッシュメモリ装置などの半導体メモリ装置、例えば、内蔵ハードディスクまたはリムーバブルディスクなどの磁気ディスク、光磁気ディスク、およびＣＤ−ＲＯＭおよびＤＶＤ−ＲＯＭディスクを例として含む、あらゆる形態の不揮発性メモリ、媒体およびメモリ装置を含む。プロセッサおよびメモリは、特殊目的の論理回路によって追加されるか、またはその中に組み込まれることが可能である。

ユーザとの対話を提供するために、本明細書に記載された発明の対象の実施形態は、情報をユーザに表示するためのディスプレイデバイス（例えば、ＣＲＴ（陰極線管）またはＬＣＤ（液晶ディスプレイ）モニタ）と、ユーザがそれによって入力をコンピュータに提供できるキーボードおよびポインティングデバイス（例えば、マウスまたはトラックボール）と、を有するコンピュータ上において実装されることが可能である。他の種類のデバイスもまた、ユーザとの対話を提供するために使用されることが可能であり、例えば、ユーザに提供されるフィードバックは、任意の形態の感覚フィードバック（例えば、視覚フィードバック、聴覚フィードバック、または触知フィードバック）であることが可能であり、ユーザからの入力は、音響入力、音声入力、または触知入力を含む任意の形態により受信されることが可能である。さらに、コンピュータは、例えば、ユーザのクライアントデバイス上のウェブブラウザから受信される要求に応答して、そのウェブブラウザにウェブページを送信することによって、ユーザによって用いられるデバイスに文書を送信およびそのデバイスから文書を受信することによってユーザと対話することが可能である。

本明細書に記載されたシステムおよび技術は、バックエンドコンポーネント（例えば、データサーバとして）を含むコンピューティングシステム、ミドルウェアコンポーネント（例えば、アプリケーションサーバ）を含むコンピューティングシステム、フロントエンドコンポーネント（例えば、ユーザが本明細書に記載された発明の対象の実装と対話可能なグラフィカルユーザインタフェースまたはウェブブラウザを有するクライアントコンピュータ）を含むコンピューティングシステム、または１または複数のそうしたバックエンドコンポーネント、ミドルウェアコンポーネント、もしくはフロントエンドコンポーネントの任意の組み合わせにより実装されることが可能である。システムのコンポーネントは、デジタルデータ通信の任意の形態または媒体（例えば、通信ネットワーク）によって相互接続されることが可能である。通信ネットワークの例は、ローカルエリアネットワーク（“ＬＡＮ”）および例えばインターネットといったワイドエリアネットワーク（“ＷＡＮ”）を含む。

コンピューティングシステムは、クライアントおよびサーバを含むことができる。クライアントおよびサーバは、一般に、互いに遠く離れており、典型的には、通信ネットワークを介してインタラクトする。クライアントとサーバとの関係は、個々のコンピュータ上で動作し、かつ互いにクライアント−サーバ関係を有するコンピュータプ
本明細書は多くの特定の実装の詳細が含まれる一方、これらは請求される範囲に対する限定として解釈されるものではないが、しかし特定の実施形態に特有であり得る特徴の記載として解釈される。別個の実施形態の文脈において本明細書に記載されるある特徴は、単一の実施形態に組み合わせて実装されることも可能である。反対に、単一の実施形態の文脈に記載される様々な特徴は、複数の実施形態において別個に、または任意の適切な副組合せにおいて実装されることも可能である。さらに、特徴は、ある組合せにおいて作用するものとして上述され、またこのように最初に請求さえもされるが、請求される組合せからの１または複数がいくつかの場合には組合せから取り除かれ、また請求される組合せは副組合せまたは副組合せの変化を対象としてよい。

同様に、動作は特定の順序にて図面に示されるが、これは、そうした動作が特定の順序または逐次的な連続した順序において実行される必要があると理解されるものではなく、または所望の結果を達成するように全ての示される動作が実行されると理解されるものではない。ある状況では、マルチタスクおよび並列処理が有利な場合がある。さらに、上述の実施形態における様々なシステムのコンポーネントの分離は、全ての実施形態においてそうした分離を必要とすると理解されるものではなく、記載されるプログラムコンポーネントおよびシステムは、一般に単一のソフトウェア製品に組み込まれているか、複数のソフトウェア製品にパッケージされていることが可能であると理解される。

発明の対象の特定の実施形態が記載されている。他の実施形態は、以下の特許請求の範囲内である。例えば、特許請求の範囲に記載される作用は、異なる順序で行われ、依然として所望の結果を得ることが可能である。一例として、添付の図面に記載されている処理は、所望の結果を達成するために示された特定の順序または逐次的な順序を必要としない。ある実装では、マルチタスクおよび並列処理が有利である場合がある。記載された処理から他のステップを設けてもよく、またステップを省略してもよい。したがって、他の実装は以下の特許請求の範囲内にある。

Claims (15)

1. コンピュータ実装方法であって、
   第１ネットワークノードが、複数のチャンネルの各チャンネルについて、複数のチャンネルについてのリーフノードのメンバシップを示すデータを含むチャンネルメンバシップデータを維持する工程と、
   前記複数のチャンネルの各チャンネルについて、
   前記チャンネルメンバシップデータに基づいて、前記チャンネルにアクセスするように購読されている前記リーフノードを決定する工程と、
   前記チャンネルにアクセスするように購読されている前記リーフノードに基づいて、（ｉ）前記チャンネルにアクセスするように購読されている前記リーフノードのうちの１つ以上のためのハブノードを識別するハブノード識別子と、（ｉｉ）前記チャンネルにアクセスするように購読されている各リーフノードの宛先アドレスを記述するデータであって、該データの少なくとも一部は、ビットマップに従い各リーフノードの前記宛先アドレスを記述し、前記ビットマップにおける各ビットは、特定のリーフノードを識別し、前記データは、宛先アドレスについてのエンコードされた第１ビットマップである、前記データと、（ｉｉｉ）ペイロードとを含む、前記チャンネルについての変更マルチメディア・データフレームを生成する生成工程と、
   前記第１ネットワークノードが、ユニキャスト・データフレームとして、生成された前記変更マルチメディア・データフレームを第２ネットワークノードに送信する工程と、
   前記第２ネットワークノードにおいて、前記変更マルチメディア・データフレームを受信する工程と、
   宛先アドレスについてのエンコードされた前記第１ビットマップから、複数の子ノードを決定する工程であって、前記複数の子ノードの各々は、前記リーフノードのうちの１つ以上のためのノードである、工程と、
   前記複数の子ノードの各々について、
   当該子ノードに関連付けられ、前記チャンネルにアクセスするように購読されている各リーフノードの前記宛先アドレスを記述する対応するデータを含む、対応する変更マルチメディア・データフレームを生成する工程であって、
   該対応するデータの少なくとも一部は、対応するビットマップに従い各リーフノードの前記宛先アドレスを記述し、前記対応するビットマップにおける各ビットは、当該子ノードに関連付けられている１つ以上の前記リーフノードのみを識別し、
   前記対応するデータは、宛先アドレスについてのエンコードされたビットマップであり、宛先アドレスについてのエンコードされた前記第１ビットマップとは異なっており、別の子ノードに対応する宛先アドレスについてのエンコードされたビットマップとは異なっている、工程と、
   前記第２ネットワークノードから、ユニキャスト・データフレームとして、対応する前記変更マルチメディア・データフレームを各子ノードに送信する工程と、
   を備える方法。
2. 前記複数のチャンネルの各々について、
   前記チャンネルメンバシップデータに基づいて、前記複数のリーフノードのうちの１または複数のリーフノードが前記チャンネルにアクセスするように購読されていないと決定することに応じて、前記チャンネルについての変更マルチメディア・データフレームを生成しない工程をさらに備える、請求項１に記載の方法。
3. 前記変更マルチメディア・データフレームは、ＭＡＣヘッダとペイロードとを含み、
   前記ＭＡＣヘッダは宛先アドレスフィールドを含む、請求項１または２に記載の方法。
4. 各対応する変更マルチメディア・データフレームは、前記ペイロードのコピーを含む、請求項３に記載の方法。
5. 前記後続のネットワークノードの数が１ネットワークノードに等しいと決定することに応じて、（ｉ）該１つの後続のネットワークノードの宛先アドレスを記述するデータと、（ｉｉ）前記ペイロードのコピーとを含むユニキャスト・データフレームを生成する、請求項３に記載の方法。
6. システムであって、
   １または複数のコンピュータと、前記１または複数のコンピュータによる実行時、前記１または複数のコンピュータに、
   第１ネットワークノードが、複数のチャンネルの各チャンネルについて、複数のチャンネルについてのリーフノードのメンバシップを示すデータを含むチャンネルメンバシップデータを維持する工程と、
   前記複数のチャンネルの各チャンネルについて、
   前記チャンネルメンバシップデータに基づいて、前記チャンネルにアクセスするように購読されている前記リーフノードを決定する工程と、
   前記チャンネルにアクセスするように購読されている前記リーフノードに基づいて、（ｉ）前記チャンネルにアクセスするように購読されている前記リーフノードのうちの１つ以上のためのハブノードを識別するハブノード識別子と、（ｉｉ）前記チャンネルにアクセスするように購読されている各リーフノードの宛先アドレスを記述するデータであって、該データの少なくとも一部は、ビットマップに従い各リーフノードの前記宛先アドレスを記述し、前記ビットマップにおける各ビットは、特定のリーフノードを識別し、前記データは、宛先アドレスについてのエンコードされた第１ビットマップである、前記データと、（ｉｉｉ）ペイロードとを含む、前記チャンネルについての変更マルチメディア・データフレームを生成する生成工程と、
   前記第１ネットワークノードが、ユニキャスト・データフレームとして、生成された前記変更マルチメディア・データフレームを第２ネットワークノードに送信する工程と、
   前記第２ネットワークノードにおいて、前記変更マルチメディア・データフレームを受信する工程と、
   宛先アドレスについてのエンコードされた前記第１ビットマップから、複数の子ノードを決定する工程であって、前記複数の子ノードの各々は、前記リーフノードのうちの１つ以上のためのノードである、工程と、
   前記複数の子ノードの各々について、
   当該子ノードに関連付けられ、前記チャンネルにアクセスするように購読されている各リーフノードの前記宛先アドレスを記述する対応するデータを含む、対応する変更マルチメディア・データフレームを生成する工程であって、
   該対応するデータの少なくとも一部は、対応するビットマップに従い各リーフノードの前記宛先アドレスを記述し、前記対応するビットマップにおける各ビットは、当該子ノードに関連付けられている１つ以上の前記リーフノードのみを識別し、
   前記対応するデータは、宛先アドレスについてのエンコードされたビットマップであり、宛先アドレスについてのエンコードされた前記第１ビットマップとは異なっており、別の子ノードに対応する宛先アドレスについてのエンコードされたビットマップとは異なっている、工程と、
   前記第２ネットワークノードから、ユニキャスト・データフレームとして、対応する前記変更マルチメディア・データフレームを各子ノードに送信する工程と、
   を含む動作を行わせるように動作可能な命令を記憶している１または複数の記憶デバイスと、を備えるシステム。
7. 前記動作は、
   前記複数のチャンネルの各々について、
   前記チャンネルメンバシップデータに基づいて、前記複数のリーフノードのうちの１または複数のリーフノードが前記チャンネルにアクセスするように購読されていないと決定することに応じて、前記チャンネルについての変更マルチメディア・データフレームを生成しない工程をさらに含む、請求項６に記載のシステム。
8. 前記変更マルチメディア・データフレームは、ＭＡＣヘッダとペイロードとを含む、請求項６または７に記載のシステム。
9. 各対応する変更マルチメディア・データフレームは、前記ペイロードのコピーを含む、請求項８に記載のシステム。
10. 前記後続のネットワークノードの数が１ネットワークノードに等しいと決定することに応じて、（ｉ）該１つの後続のネットワークノードの宛先アドレスを記述するデータと、（ｉｉ）前記ペイロードのコピーとを含むユニキャスト・データフレームを生成する、請求項８に記載のシステム。
11. 命令を記憶する非一時的なコンピュータ可読記憶デバイスであって、前記命令は、データ処理装置による実行時、前記データ処理装置に、
    第１ネットワークノードが、複数のチャンネルの各チャンネルについて、複数のチャンネルについてのリーフノードのメンバシップを示すデータを含むチャンネルメンバシップデータを維持する工程と、
    前記複数のチャンネルの各チャンネルについて、
    前記チャンネルメンバシップデータに基づいて、前記チャンネルにアクセスするように購読されている前記リーフノードを決定する工程と、
    前記チャンネルにアクセスするように購読されている前記リーフノードに基づいて、（ｉ）前記チャンネルにアクセスするように購読されている前記リーフノードのうちの１つ以上のためのハブノードを識別するハブノード識別子と、（ｉｉ）前記チャンネルにアクセスするように購読されている各リーフノードの宛先アドレスを記述するデータであって、該データの少なくとも一部は、ビットマップに従い各リーフノードの前記宛先アドレスを記述し、前記ビットマップにおける各ビットは、特定のリーフノードを識別し、前記データは、宛先アドレスについてのエンコードされた第１ビットマップである、前記データと、（ｉｉｉ）ペイロードとを含む、前記チャンネルについての変更マルチメディア・データフレームを生成する生成工程と、
    前記第１ネットワークノードが、ユニキャスト・データフレームとして、生成された前記変更マルチメディア・データフレームを第２ネットワークノードに送信する工程と、
    前記第２ネットワークノードにおいて、前記変更マルチメディア・データフレームを受信する工程と、
    宛先アドレスについてのエンコードされた前記第１ビットマップから、複数の子ノードを決定する工程であって、前記複数の子ノードの各々は、前記リーフノードのうちの１つ以上のためのノードである、工程と、
    前記複数の子ノードの各々について、
    当該子ノードに関連付けられ、前記チャンネルにアクセスするように購読されている各リーフノードの前記宛先アドレスを記述する対応するデータを含む、対応する変更マルチメディア・データフレームを生成する工程であって、
    該対応するデータの少なくとも一部は、対応するビットマップに従い各リーフノードの前記宛先アドレスを記述し、前記対応するビットマップにおける各ビットは、当該子ノードに関連付けられている１つ以上の前記リーフノードのみを識別し、
    前記対応するデータは、宛先アドレスについてのエンコードされたビットマップであり、宛先アドレスについてのエンコードされた前記第１ビットマップとは異なっており、別の子ノードに対応する宛先アドレスについてのエンコードされたビットマップとは異なっている、工程と、
    前記第２ネットワークノードから、ユニキャスト・データフレームとして、対応する前記変更マルチメディア・データフレームを各子ノードに送信する工程と、
    を含む動作を行わせるコンピュータ可読記憶デバイス。
12. 前記動作は、
    前記複数のチャンネルの各々について、
    前記チャンネルメンバシップデータに基づいて、前記複数のリーフノードのうちの１または複数のリーフノードが前記チャンネルにアクセスするように購読されていないと決定することに応じて、前記チャンネルについての変更マルチメディア・データフレームを生成しない工程をさらに含む、請求項１１に記載のコンピュータ可読記憶デバイス。
13. 前記変更マルチメディア・データフレームは、ＭＡＣヘッダとペイロードとを含む、請求項１１または１２に記載のコンピュータ可読記憶デバイス。
14. 各対応する変更マルチメディア・データフレームは、前記ペイロードのコピーを含む、請求項１１に記載のコンピュータ可読記憶デバイス。
15. 前記後続のネットワークノードの数が１ネットワークノードに等しいと決定することに応じて、（ｉ）該１つの後続のネットワークノードの宛先アドレスを記述するデータと、（ｉｉ）前記ペイロードのコピーとを含むユニキャスト・データフレームを生成する、請求項１１に記載のコンピュータ可読記憶デバイス。

Images