JP4995808B2 - データネットワークを通して強化されたコンテンツ配信を行うための方法及び装置 - Google Patents

Description

（米国特許法第１１９条に基づく優先権の主張）
本特許出願は、２００５年４月８日に出願され且つ本出願の譲受人に譲渡され、これにより参照として明確に本明細書に組み込まれる、仮出願第６０／６６９，４０６号への優先権を主張する。

本特許出願は、２００５年９月２３日に出願され且つ本出願の譲受人に譲渡され、これにより参照として明確に本明細書に組み込まれる、仮出願第６０／７２０，０００号への優先権を同様に主張する。

（分野）
本明細書は、一般にデータネットワークを通してのデータの配布に関し、より詳細には、データネットワークを通しての強化されたコンテンツ配信のための方法及び装置に関する。

（背景）
無線通信ネットワークのようなデータネットワークは、単一の端末に対してカスタマイズされるサービスと、多数の端末に提供されるサービスとの間のトレードオフをする必要がある。例えば、マルチメディアコンテンツの、リソースが制限された多数の携帯型デバイス（加入者）への配布は、複雑な問題である。従って、ネットワーク管理者、コンテンツ小売業者、及びサービスプロバイダにとって、コンテンツ及び／又は他のネットワークサービスを、ネットワーク接続されたデバイスに提供するために迅速且つ効率的なやり方で配布する方法を有することが非常に重要である。

現在のコンテンツ配信／メディア流通システムにおいては、リアルタイム及び非リアルタイムサービスが送信フレームの中に詰め込まれ、ネットワーク上のデバイスに配信される。例えば、通信ネットワークが、直交波周波数分割多重（ＯＦＤＭ）を、ネットワークサーバと１つ以上のモバイルデバイスとの間の通信を提供するために使用してもよい。この技術は、配信されるべきサービスが詰まったデータスロットを有しており且つ流通ネットワークを通して送信される、送信フレームを提供する。

残念ながら、従来のシステムは、これらのサービスを非常に非効率的なやり方で、送信フレームの中に詰め込む可能性がある。例えば、サービスは、利用可能な帯域幅を浪費するようなやり方で詰め込まれる可能性があり、又はコンテンツを受信するために大きな電力を使うことを受信デバイスに要求する可能性もある。例えば、デバイスが、コンテンツを受信するために長時間目を覚ましている（すなわち、このデバイスの受信ロジックの電源を入れる）ことを要求される可能性があり、又はコンテンツを受信するために頻繁に目を覚ますことを要求される可能性もある。どちらにしても、このような非効率的な詰め込みは、デバイスによるより多くのバッテリー電力の使用につながり、これはデバイスの連続待ち受け時間を悪化させうる。

従って、必要なのは、従来のシステムの問題を克服し、これにより受信デバイスがコンテンツを電力効率のよいやり方で受信することを可能とする、データネットワーク上でコンテンツを効率的に送信するためのシステムである。

（概要）
１つ以上の実施形態の中では、方法と装置を備え、データネットワークを通しての送信のために１つ以上のコンテンツフローを効率的に多重化する働きをする、多重化システムが提供される。例えば、一態様によれば、このシステムは、送信フレーム内の利用可能なデータスロットの中にコンテンツフローを多重化する働きをする。コンテンツフローに関連するさまざまなパラメータ及び／又は情報に基づいてデータスロットを割り当てる、割り当てアルゴリズムが提供される。一態様によれば、このシステムはまた、利用可能なデータスロットに収まらない１つ以上のコンテンツフローに対してどのようにリサイズを実行するかを制御する働きをして、リサイズされたフローが利用可能なデータスロットの中に収まることができるようにする、リサイズ制御部を備えている。従って、システムは、データネットワークを通しての送信のために、コンテンツフローに関連する要求を満足し、送信コストを低減し、帯域幅の利用を増進させ、且つ受信デバイスの電力要求を低減するような方法で、１つ以上のコンテンツフローを効率的に多重化する働きをする。

一態様によれば、ネットワークを通してサービスを送信する方法が提供される。この方法は、関連する配信要求を有する１つ以上のサービスを受信することと、ネットワーク帯域幅が配信要求を満足することが可能であることを判断することとを備えている。方法はさらに、ネットワーク帯域幅を、配信要求に基づいて１つ以上のサービスに割り当てして、ネットワーク帯域幅割り当てを生成することを備える。

一態様によれば、ネットワークを通してサービスを送信する装置が提供される。この装置は、関連する配信要求を有する１つ以上のサービスを受信するように構成されている、受信ロジックを備えている。装置はさらに、ネットワーク帯域幅は配信要求を満足することが可能であるということとを判断し、ネットワーク帯域幅を１つ以上のサービスに配信要求に基づいて割り当てして、ネットワーク帯域幅割り当てを生成するように構成された、多重化ロジックを備える。

一態様によれば、ネットワークを通してサービスを送信する装置が提供される。この装置は、関連する配信要求を有する１つ以上のサービスを受信する手段と、ネットワーク帯域幅は配信要求を満足することが可能であることを判断する手段とを備えている。装置はさらに、ネットワーク帯域幅を、配信要求に基づいて１つ以上のサービスに割り当てして、ネットワーク帯域幅割り当てを生成する手段を備える。

一態様によれば、命令を備えるコンピュータプログラムを有するコンピュータで読み取り可能な媒体が提供され、これらの命令は、少なくとも１つのプロセッサにより実行されると、ネットワークを通してサービスを送信する働きをする。上記コンピュータプログラムは、関連する配信要求を有する１つ以上のサービスを受信する命令と、ネットワーク帯域幅は配信要求を満足することが可能であるということを判断する命令とを備えている。コンピュータプログラムはさらに、ネットワーク帯域幅を、配信要求に基づいて１つ以上のサービスに割り当てして、ネットワーク帯域幅割り当てを生成する命令を備える。

一態様によれば、ネットワークを通してサービスを送信するための方法を実行するように構成された、少なくとも１つのプロセッサが提供される。この方法は、関連する配信要求を有する１つ以上のサービスを受信することと、ネットワーク帯域幅が配信要求を満足することが可能であることを判断することとを備えている。方法はさらに、ネットワーク帯域幅を、配信要求に基づいて１つ以上のサービスに割り当てして、ネットワーク帯域幅割り当てを生成することを備える。

一態様によれば、ネットワークを通してサービスを送信する方法が提供される。この方法は、関連する配信要求を有する１つ以上のサービスを受信することと、利用可能なネットワーク帯域幅は配信要求を満足することができないということを判断することとを備えている。方法はまた、１つ以上のサービスの少なくとも１つをリサイズして調整された配信要求を生成することと、この調整された配信要求に基づいて１つ以上のサービスに利用可能な帯域幅を割り当てしてネットワーク帯域幅割り当てを生成することとを、備えている。

一態様によれば、ネットワークを通してサービスを送信する装置が提供される。この装置は、関連する配信要求を有する１つ以上のサービスを受信するように構成された受信ロジックと、１つ以上のサービスの少なくとも１つをリサイズして、調整された配信要求を生成するように構成されたリサイズ制御部とを備えている。装置はまた、利用可能なネットワーク帯域幅は前記配信要求を満足させることができないということを判断し、利用可能なネットワーク帯域幅を調整された配信要求に基づいて１つ以上のサービスに割り当てして、ネットワーク帯域幅割り当てを生成するように構成された、多重化ロジックを備える。

一態様によれば、ネットワークを通してサービスを送信する装置が提供される。この装置は、関連する配信要求を有する１つ以上のサービスを受信する手段と、利用可能なネットワーク帯域幅は配信要求を満足することができないということを判断する手段とを備えている。装置はまた、１つ以上のサービスの少なくとも１つをリサイズして調整された配信要求を生成する手段と、この調整された配信要求に基づいて１つ以上のサービスに利用可能な帯域幅を割り当てしてネットワーク帯域幅割り当てを生成する手段とを、備えている。

一態様によれば、命令を備えるコンピュータプログラムを有するコンピュータで読み取り可能な媒体が提供され、このコンピュータプログラムは、少なくとも１つのプロセッサにより実行されると、ネットワークを通してサービスを送信する働きをする。上記コンピュータプログラムは、関連する配信要求を有する１つ以上のサービスを受信する命令と、利用可能なネットワーク帯域幅は配信要求を満足することができないということを判断する命令とを備えている。コンピュータプログラムはまた、１つ以上のサービスの少なくとも１つをリサイズして調整された配信要求を生成する命令と、この調整された配信要求に基づいて１つ以上のサービスに利用可能な帯域幅を割り当てしてネットワーク帯域幅割り当てを生成する命令とを、備えている。

一態様によれば、ネットワークを通してサービスを送信するための方法を実行するように構成された、少なくとも１つのプロセッサが提供される。この方法は、関連する配信要求を有する１つ以上のサービスを受信することと、利用可能なネットワーク帯域幅は配信要求を満足することができないということを判断することとを備えている。方法はまた、１つ以上のサービスの少なくとも１つをリサイズして調整された配信要求を生成することと、この調整された配信要求に基づいて１つ以上のサービスに利用可能な帯域幅を割り当てしてネットワーク帯域幅割り当てを生成することとを、備えている。

これらの実施形態の他の態様は、この後で説明される図面の簡単な説明、発明を実施するための最良の形態、及び特許請求の範囲を調べた後に明確になってくるであろう。

（説明）
本明細書において説明された実施形態の前述の態様は、添付の図面に関連してなされる以下の詳細な説明を参照することにより、より容易に明確となろう。

１つ以上の実施形態の中で、コンテンツフローを、データネットワークを通して送信するための送信フレームの中に多重化する働きをする、多重化システムが提供される。例えば、この多重化されたコンテンツフローは、特定の配置、順番、混合、及び／又はデバイスに送信するためのリアルタイムサービス及び／又は非リアルタイムサービスの選択を備えている。このシステムは、無線ネットワーク環境の中で用いるのに大変適しており、しかしながら、通信ネットワーク、インターネットのようなパブリックネットワーク、仮想プライベートネットワーク（ＶＰＮ）のようなプライベートネットワーク、ローカルエリアネットワーク、広域ネットワーク、長距離ネットワーク、又は他の任意の種類のデータネットワークを含む、しかしこれらに限定されない、任意の種類のネットワーク環境の中で用いてもよい。

この説明のために、多重化システムの１つ以上の実施形態が、ネットワークサーバと１つ以上のモバイルデバイスとの間の通信を提供するために直交波周波数分割多重（ＯＦＤＭ）を用いる通信ネットワークを参照して、本明細書において説明される。例えば、ＯＦＤＭシステムの一実施形態では、時分割多重（ＴＤＭ）パイロット信号、周波数分割多重（ＦＤＭ）パイロット信号、オーバーヘッド情報シンボル（ＯＩＳ）及びデータシンボルを備えるスーパーフレームが定義されている。データスロットが、１つのＯＦＤＭシンボル時間内に間に生じる５００のデータシンボルの組として定義される。加えて、スーパーフレーム内の１つのＯＦＤＭシンボル時間は、７つのデータのスロットを収容する。

多重化システムの１つ以上の実施形態を説明するために、本明細書において以下の定義が用いられる。

フロー：サービスの要素であり、例えば、１つのサービスが２つのフロー、すなわちオーディオフロー及びビデオフロー、を有してもよい。

サービス：１つ以上のフローを有しうるメディアコンテンツ。

ＭＬＣ：データ又は制御情報のために用いるメディアロジカルチャネル（チャネル）。

リサイズ：サービスが、より少ない送信帯域幅しか必要としないようにサイズ変更される手順。

オーバーヘッド情報シンボル（ＯＩＳ）：
スーパーフレーム内のさまざまなＭＬＣの場所についての情報を収容する、スーパーフレーム内のシンボル。

スロット：１つのＯＦＤＭシンボルの上でＭＬＣに割り当てされる最も小さな帯域幅の単位。

図１は、多重化システムの一実施形態を備える、ネットワーク１００を表している。ネットワーク１００は、モバイルデバイス１０２、サーバ１０４、及びデータネットワーク１０６を備えている。これの説明のために、データネットワーク１０６は、ＯＦＤＭ技術を用いて１つ以上の携帯型デバイスと通信する働きをすると仮定されよう。しかしながら、この多重化システムの実施形態は、同様に他の送信技術とともに用いることにも適している。

一実施形態の中では、サーバ１０４は、ネットワーク１０６と通信するデバイスにより契約される可能性のあるサービスを提供する働きをする。サーバ１０４は、通信リンク１０８を通してネットワーク１０６に結合される。通信リンク１０８は、サーバ１０４がネットワーク１０６と通信するのを可能とさせる働きをする、有線及び／又は無線のリンクのような、任意の適切な通信リンクを備えている。ネットワーク１０６は、サービスが、サーバ１０４からデバイス１０２のようなネットワーク１０６と通信するデバイスに配信されることを可能とする、有線及び／又は無線の任意の組み合わせのネットワークを備えている。

ネットワーク１０６は、本実施形態の範囲内の、任意の数及び／又はタイプの携帯型デバイスと通信してもよい、ということに留意されたい。例えば、この多重化システムの実施形態の中で利用するのに適切な他のデバイスには、これらに限定するものではないものの、携帯情報端末（ＰＤＡ）、ｅメールデバイス、ページャ、ノートブックコンピュータ、ｍｐ３プレーヤ、ビデオプレーヤ、又はデスクトップコンピュータが含まれる。無線リンク１１０は、ＯＦＤＭ技術に基づく無線通信リンクを備えているが、他の実施形態の中では、無線リンクは、デバイスがネットワーク１０６と通信することを可能にする働きをする、任意の適切な無線技術を備えてもよい。

この実施形態におけるデバイス１０２は、無線リンク１１０を通してネットワーク１０６と通信する携帯電話を備えている。デバイス１０２は、デバイス１０２がネットワーク１０６を通してサービスを受けるために契約することを可能にする、起動処理に参加する。一実施形態の中では、この起動処理は、サーバ１０４で実行されてもよい。しかし、この起動処理は、同様に他のサーバ、サービスプロバイダ、コンテンツ小売業者、又は他のネットワークエンティティにより実行されてもよい。この説明のために、デバイス１０２は、サーバ１０４とともに起動処理を実行し、サーバ１０４からのサービスの契約及び受け取りの用意ができていると仮定されよう。

一実施形態の中では、サーバ１０４は、１つ以上のリアルタイム（ＲＴ）サービス１１２を含むコンテンツへのアクセスを備える又は有する、リアルタイムメディアサーバ（ＲＴＭＳ）１２６と通信する。サーバ１０４はまた、１つ以上のリアルタイム以外（ＯＲＴ）のサービス１２０へのアクセスを備えるか又は有する、非リアルタイムメディアサーバ（ＮＲＴＭＳ）１２８と通信する。例えば、サービス（１１２、１２０）は、ニュース、スポーツ、天気、金融情報、映画、及び／又はアプリケーション、プログラム、スクリプト、若しくは任意の他のタイプの適切なコンテンツ若しくはサービスを含む、マルチメディアコンテンツを備えている。従って、サービス（１１２、１２０）は、ビデオ、オーディオ、又は他の任意の適切なフォーマットの情報を備えていてもよい。サーバ１０４は、同様に、ＲＴ及び／又はＯＲＴサービスへのアクセスを備える又は有する１つ以上の他のメディアサーバと通信してもよいということに、留意されたい。サービス（１１２、１２０）は、これらに限定するものではないものの、帯域幅、プライオリティ、レーテンシ、サービスのタイプ、及び／又は他の任意のタイプの配信要求を含みうる、関連の配信要求を有する。

サーバ１０４はまた、配信要求に基づいて送信フレーム１２２の中に１つ以上のサービス（１１２、１２０）を効率的に多重化する働きをする、多重化装置（ＭＵＸ）１１４を備えている。例えば、送信フレームは、経路１１８によって示されるように、データネットワーク１０６を通してデバイス１０２に送信される。ＭＵＸ１１４についてのより詳細な説明は、本明細書の他の章の中で提供されている。ＭＵＸ１１４の動作の結果として、サービス（１１２、１２０）は、このサービス（１１２、１２０）についての配信要求（帯域幅、プライオリティ、レーテンシ、サービスのタイプ等）が満たされ、送信フレーム１２２の送信帯域幅が効率的に利用され、受信デバイス１０２における電力が節約されるように、最適に送信フレーム１２２の中に詰め込まれる。例えば、利用可能な帯域幅を効率的に利用することにより、モバイルデバイスは送信されるサービスを短い時間間隔で受信することができ、それによってバッテリー電力を節約する。

一実施形態の中では、ＭＵＸ１１４は、どのようにＲＴサービス１１２及び／又はＯＲＴサービス１２０がリサイズされるかを制御する働きをするリサイズ制御部１１６を備えている。例えば、送信フレーム１２２の中に多重化されるべき選択されたＲＴサービス１１２が、送信フレーム１２２の利用可能な帯域幅の中に収まらない場合は、リサイズ制御部１１６が、これらのサービスを、これらの帯域幅要求を削減するためにどのようにリサイズ（又は再符号化）するかを制御する働きをする。例えば、リサイズ制御部１１６は、特定のＲＴサービスの選択されたリサイズを要求するために、ＲＴＭＳ１２６と通信する。リサイズ制御部１１６はまた、同様な形で、どのように選択されたＯＲＴサービス１２０がリサイズされるかを制御するために、ＮＲＴＭＳ１２８と通信する働きをする。リサイズ制御部１１６の動作の結果として、リサイズされたＲＴ及びＯＲＴサービスは、送信フレーム１２２の利用可能な帯域幅内に収まるであろう。リサイズ制御部１１６のより詳細な説明は、本明細書の他の章の中で提供されている。

一実施形態の中では、デバイス１０２は、送信されるサービス（１１２、１２０）を得るために、送信フレーム１２２を逆多重化する働きをする、デマルチプレクサ（ＤＥ−ＭＵＸ）ロジック１２４を備えている。これらのサービスは効率的に送信フレーム１２２の中に多重化されていることから、ネットワーク帯域幅は節約され、デバイス１０２は送信されるサービスを受信するためにより少ない電力しか使わない。

従って、この多重化システムの実施形態は、以下の機能の１つ以上を実行して、ＲＴ及びＯＲＴサービスの送信フレームへの効率的な多重化を提供する働きをする。

１．ネットワークを通しての送信のために、１つ以上のＲＴ及び／又はＯＲＴサービスを受信するか又はこれらへのアクセスを得る。

２．ＲＴ及び／又はＯＲＴサービスが、送信フレームの利用可能な帯域幅の中に収まるかどうかを判断する。

３．ＲＴ及び／又はＯＲＴサービスが送信フレームの中に収まらない場合は、１つ以上の選択されたＲＴ及び／又はＯＲＴサービスをリサイズして、これらの帯域幅要求を削減する。

４．割り当てアルゴリズムの実施形態を利用して、効率的にフレームに詰め込まれるように、元の及び／又はリサイズされたＲＴサービス、及び元の及び／又はリサイズされたＯＲＴサービスを伴う送信フレームを組み立てる。

５．１つ以上の受信デバイスに、ネットワークを通して上記の送信フレームを送信する。

従って、１つ以上の実施形態の中で、多重化システムは、１つ以上のＲＴ及び／又はＯＲＴサービスを効率的に多重化し、且つこれらをデータネットワーク上のデバイスへと送信するように動作する。この多重化システムは、図１に記述されたインプリメンテーションに限定されず、他のインプリメンテーションが本発明の実施形態の範囲の中で可能であるということに留意されたい。

図２は、多重化システムの中で用いるサーバ２００の一実施形態を示す。例えば、サーバ２００は、図１のサーバ１０４として用いてもよい。サーバ２００は、処理ロジック２０２、メモリ２０４、及びトランシーバロジック２０６を備え、これら全てはデータバス２０８に結合されている。サーバ２００はまた、多重化装置（ＭＵＸ）ロジック２１０及びリサイズ制御部２１２とを備え、これらは同様にデータバス２０８に結合されている。サーバ２００は、ただ１つのインプリメンテーションを表すものであり、他のインプリメンテーションが本実施形態の範囲内で可能であるということに留意されたい。

１つ以上の実施形態の中では、処理ロジック２０２は、ＣＰＵ、プロセッサ、ゲートアレイ、ハードウェアロジック、メモリ要素、バーチャルマシン、ソフトウェア、及び／又はハードウェアとソフトウェアとの任意の組み合わせを備えている。従って、処理ロジック２０２は、一般的に、機械で読み取り可能な命令を実行するための、及びサーバ２００の１つ以上の他の機能要素をデータバス２０８を介して制御するためのロジックを備えている。

トランシーバロジック２０６は、サーバ２００が、通信チャネル２１４を通して、リモートデバイス又はシステムとともにデータ及び／又は他の情報を送信及び受信することを可能とするように動作する、ハードウェア及び／又はソフトウェアを備えている。例えば、一実施形態では、通信チャネル２１４は、サーバ２００が他のサーバ又は１つ以上のデータネットワーク及び／又はこれらのデータネットワークに結合されたデバイスと直接通信することを可能にする、任意の適切なタイプの通信リンクを備えている。

メモリ２０４は、サーバ２００が情報パラメータを格納することができるようにする、任意の適切なタイプの記憶デバイス又は要素を備えている。例えば、一実施形態では、メモリ２０４は、任意のタイプのＲＡＭ、フラッシュメモリ、ハードディスク、又は任意の他のタイプの記憶デバイスを備えている。

一実施形態の中では、処理ロジック２０２は、トランシーバロジック２０８及びチャネル２１４を通して、１つ以上のコンテンツプロバイダと通信する働きをする。例えば、処理ロジック２０２は、ＲＴサービス２１６を受信するためにＲＴＭＳと、ＯＲＴサービス２１８を受信するためにＮＲＴＭＳと通信する。例えば、ＲＴサービス２１６及びＯＲＴサービス２１８は、ネットワーク上のデバイスに配信されるべき１つ以上のコンテンツフローを備えている。更に、ＲＴサービス２１６及びＯＲＴサービス２１８は、限定するものではないものの、帯域幅、プライオリティ、レーテンシ、サービスのタイプ、及び／又は任意の他のタイプの配信要求を含む、関連する配信要求を有する。

１つ以上の実施形態の中では、ＭＵＸロジック２１０は、ＣＰＵ、プロセッサ、ゲートアレイ、ハードウェアロジック、メモリ要素、バーチャルマシン、ソフトウェア、及び／又はハードウェアとソフトウェアとの任意の組み合わせを備えている。ＭＵＸロジック２１０は、トランシーバロジック２０６及びチャネル２１４を用いてのデバイスへの送信のための配信要求に基づいて、送信フレームの中に、１つ以上のＲＴサービス２１６及び／又はＯＲＴサービス２１８を多重化する働きをする。例えば、ＭＵＸロジック２１０は、選択されたＯＲＴサービス２１８、ＲＴサービス２１６、及びベストエフォートサービス（ここでは示されていない）が、送信フレームの利用可能な帯域幅（これらの配信要求に対しての）の中に収まるかどうかを判断する働きをする。例えば、ベストエフォートサービスは、送信が必要な任意のタイプのデータ又は情報を備えている。上記のフローが、利用可能な帯域幅に収まる場合は、ＭＵＸロジック２１０は、本明細書において説明されるアルゴリズムの１つ以上の実施形態に従って、これらを送信フレームの中に詰め込む働きをする。

選択されたＲＴサービス２１６及び／又はＯＲＴサービス２１８が、送信フレームに収まらない場合は、ＭＵＸロジック２１０は、リサイズ制御部２１２に信号を送る。リサイズ制御部２１２は、これらのサービスが送信フレームの利用可能な帯域幅に収まるように、どのようにリサイズされるかを制御する働きをする。一実施形態の中では、リサイズ制御部２１２は、特定のサービスが、これの送信帯域幅要求を削減するためにどれだけの「リサイズ」を必要としているのかを判断し、その後、このサービスに関連するメディアサーバに送信されるリサイズ要求をまとめる働きをする。例えば、リサイズ要求は、トランシーバロジック２０６によって、通信チャネル２１４を使って送信される。メディアサーバは、その後、要求されたようにこのサービスをリサイズする働きをする。帯域幅要求を低減するためにサービスがリサイズされた後、ＭＵＸロジック２１０は、送信フレームの中に、元のサービス及び任意のリサイズされたサービスを効率良く詰め込むことができる。ＭＵＸロジック２１０により提供される割り当てアルゴリズムについてのより詳細な説明は、本明細書の他の章の中で提供されている。

１つ以上の実施形態の中では、リサイズ制御部２１２は、ＣＰＵ、プロセッサ、ゲートアレイ、ハードウェアロジック、メモリ要素、バーチャルマシン、ソフトウェア、及び／又はハードウェアとソフトウェアとの任意の組み合わせを備えている。リサイズ制御部２１２は、ＲＴサービス２１６及びＯＲＴサービス２１８の１つ以上のフローをどのようにリサイズするかを制御する働きをし、これらのフローが送信フレームの利用可能な帯域幅の中に収まるようにする。従って、リサイズ制御部２１２は、１つ以上のサービスを、これに関連する配信要求を調整するためにリサイズする働きをする。例えば、サービスは、これの帯域幅要求が調整（すなわち削減）できるようにリサイズされてもよい。一実施形態の中では、リサイズ制御部２１２は、ＭＵＸロジック２１０の一部である。リサイズ制御部２１２のより詳細の説明は、本明細書の他の章の中で提供されている。

一実施形態では、多重化システムは、コンピュータで読み取り可能な媒体上に格納された１つ以上のプログラム命令（「命令」）を有するコンピュータプログラムを備え、このコンピュータプログラムは、少なくとも１つのプロセッサ、例えば処理ロジック２０２により実行されると、本明細書の中で説明される多重化システムの機能を提供する。例えば、命令は、フロッピー（登録商標）ディスク、ＣＤＲＯＭ、メモリカード、フラッシュメモリデバイス、ＲＡＭ、ＲＯＭ、又はサーバ２００に接続する任意の他のタイプのメモリデバイス若しくはコンピュータで読み取り可能な媒体などの、コンピュータで読み取り可能な媒体から、サーバ２００の中にロードされてもよい。他の実施形態では、命令は、トランシーバロジック２０６を通して、外部のデバイスから又はサーバ２００に接続するネットワークリソースから、サーバ２００の中にダウンロードされてもよい。処理ロジック２０２により実行される時、命令は、本明細書において説明されるような多重化システムの１つ以上の実施形態を提供する。

このように、サーバ２００は、多重化システムの実施形態を提供する働きをし、ネットワーク上のデバイスに送信するための送信フレームの中に、ＲＴサービス２１６及びＯＲＴサービス２１８に関連するフローを効率的に多重化する。

＜送信フレームスロット割り当てアルゴリズム＞
以下の記述は、多重化システムの実施形態の中で用いるスロット割り当てアルゴリズムを説明している。一実施形態では、スロット割り当てアルゴリズムは、利用可能なＲＴ及びＯＲＴサービスに関連するコンテンツフローに、送信フレーム内のスロットを割り当てする働きをする。割り当てアルゴリズムは、効率的な帯域幅利用を実現する働きをし、これにより受信デバイスが電力を節約することを可能にする。１つ以上の実施形態では、割り当てアルゴリズムは、ＭＵＸロジック２１０により及び／又はこれの制御の下で実行される。

この説明のために、送信フレームは、以下においてスーパーフレームと呼ばれよう。スーパーフレームはただ１つのインプリメンテーションであり、この多重化システムの各実施形態は、他のタイプの送信フレームのインプリメンテーションとともに用いるのに適しているということに留意されたい。

一実施形態の中では、スーパーフレームは、帯域幅割り当てに利用されるデータシンボル部を備えている。スーパーフレームのデータシンボル部は、４つの同じ部分に分けられ、これらは以下において「フレーム」と呼ばれる。送信されるべきサービスからのデータ（一実施形態の中では、これはリードソロモン（ＲＳ）ブロックである）は、４つのフレーム全体に平等に分配される。従って、スーパーフレーム全体へのスロット割り当てアルゴリズムの動作は、１つのフレームに対するスロット割り当てアルゴリズムの動作の繰り返しである。従って、以下の記述は１つのフレームへのスロット割り当てを説明するが、しかしながら、これはスーパーフレーム全体に同様に適用可能である。加えて、論じられるスロット配置アルゴリズムは、リアルタイムサービス、非リアルタイムサービス、及びＩＰデータキャストを含む、しかしこれらに限定されない、全てのタイプのサービスに対してスロットを割り当てするために用いてもよい。

（チャネル割り当て）
１つ以上の実施形態では、１つのＭＬＣは同じサービスの１つ以上のフローを伝達する。従って、あらゆるサービスは、ＯＩＳの中に記述された、これらのフレームの中のロケーションを伴う、１つ以上のＭＬＣを有することができる。特定のＭＬＣを受け取りたいと望むデバイスは、ＯＩＳからこのＭＬＣのロケーションを入手する。フレーム内のＭＬＣのロケーションは、以下を用いてＯＩＳの中に記述される。

−開始シンボル
−開始スロット
−最下位スロット
−最上位スロット
−合計スロット
図３は、多重化システムの中で用いられるＭＬＣのスロット割り当てを説明する、フレーム３００の一実施形態を示す。フレーム３００は、７つのスロットのそれぞれに対して、「Ｎ」個のＯＦＤＭシンボルを備えている。ＭＬＣのスロット割り当ては、全体として３０２で示される網掛けされた領域である。スロットの割り当てを記述するために２つの変数が用いられる。すなわち長さ及び高さである。長さはＯＦＤＭシンボルに属し、高さはスロットに属する。

（割り当ての形状）
図４は、多重化システムの中で用いるさまざまなＭＬＣの割り当ての形状を備える、フレーム４００の一実施形態を示す。例えば、ＭＬＣの割り当ては、全体として４０２、４０４、４０６、４０８で示される網掛け領域である。一実施形態の中では、割り当て形状は、これらがフレーム４００のＯＩＳの中に、固定の限定された数のデータフィールドを用いて記述することができるように、選択される。

（割り当ての高さ）
図５は、選択されたＭＬＣ割り当てに対する、送信モードパラメータと最大スロット高さ値との間の関係を説明する、表５００を示す。受信デバイスにあるターボデコーダの最高出力レートは、１つのＯＦＤＭシンボルの中で復号化することができるターボパケットの数を制限する。その結果として、ＭＬＣ割り当ての高さは抑制される可能性がある。最大スロット高さ（「maxSlotHeight」）と呼ばれる変数が、所与の送信モードに対するＭＬＣ割り当ての最大スロット高さを表すために用いられる。例えば、表５００から、送信モード４が３のmaxSlotHeightを有するＭＬＣ割り当てをサポートし、送信モード１が７のmaxSlotHeightを有するＭＬＣ割り当てをサポートすることが分かる。

（割り当てアルゴリズム）
一実施形態では、選択されたサービスの全てのＭＬＣは、これらの割り当てがフレームの中で時間的に隣接するように、グループ化される。これは、受信デバイスがあるサービスについての異なるＭＬＣを受信するために「目を覚ます（ｗａｋｅ ｕｐ）」ために必要な回数を低減する。従って、受信デバイスの電力消費は、低減すなわち節約される。

受信デバイスの電力消費に関しては、ＭＬＣ割り当ての高さは、これのmaxSlotHeightであることが好ましい。これは、このデバイスがこのＭＬＣを受信するための見込みの「オンタイム」を最小化する。しかしながら、詰め込みを簡略化するために、あるサービスについてのグループ化されたＭＬＣの全てが、同じ高さで割り当てされる。従って、「サービスのmaxSlotHeight」の概念は、このサービスのためにグループ化された全てのＭＬＣについての、最小のすなわち最も小さいmaxSlotHeightパラメータとして定義される。この説明の残りについては、サービスの高さは、このサービスの全てのＭＬＣ割り当ての共通の高さを意味するであろう。

図６は、多重化システムの中で用いられる異なるＭＬＣスロット割り当てを説明する、フレーム６００の一実施形態を示す。フレーム６００は、異なる高さのブロックを有する各ＭＬＣ割り当てに分けられる。一実施形態では、ブロック高さは、あるサービスが取ることができる、可能なmaxSlotHeightに相当する。図５に示す表５００から、４つの可能なmaxSlotHeight（すなわち、３、４、６、又は７）があると判断することができる。一実施形態の中では、スロット割り当てアルゴリズムは、maxSlotHeightパラメータに基づいて、異なるブロック割り当ての中にサービスを詰め込む働きをする。例えば、可能なmaxSlotHeight（すなわち、３、４、６、又は７）に基づく割り当てが、それぞれ６０２、６０４、６０６、６０７で示されている。

（割り当てアルゴリズム動作）
以下は、多重化システムの中で用いる割り当てアルゴリズムの実施形態の説明である。一実施形態の中では、ＭＵＸロジック２１０は、割り当てアルゴリズムを実行する働きをし、以下に説明する機能を行う。

割り当てアルゴリズムへの入力は、以下である。

１．あるフレームに対してサービスのチャネルそれぞれが有するデータのスロットの数。

２．各チャネルの送信モードにより決定される、サービスのチャネルそれぞれのmaxSlotHeight。

このアルゴリズムの出力は次の通りである。

１．詰め込みが可能かどうかを示す決定。詰め込みが可能な場合、アルゴリズムは、ＭＬＣ割り当てのロケーションを与える。

２．詰め込みが不可能な場合、スロット割り当てアルゴリズムは、リサイズ制御部２１２が提供している、サービスのリサイズを要求する。一実施形態の中では、リサイズ制御部２１２は、どのサービスに対してリサイズするか、及びどの程度リサイズするかを決定する。リサイズ制御部２１２の動作の詳細な説明は、本明細書の他の章の中で提供されている。

図７は、多重化システムの中で用いる割り当てアルゴリズムを提供するための方法７００の一実施形態を示す。例えば、方法７００は、１つ以上のＲＴサービスにスロットを割り当てする働きをする。一実施形態の中では、ＭＵＸロジック２１０は、以下に説明するような方法７００の機能を提供する働きをする。

ブロック７０２では、テストが実行されて、フレームの中に多重化されるべき全てのＲＴサービスにより要求されるスロットの総数が、利用可能なスロット数よりも大きいかどうかを判断する。例えば、ＭＵＸロジック２１０が、この判断を行う。一実施形態では、利用可能なスロット数は、「フレームあたりのシンボル数」（numOfdmSymbolsPerFrm）の７倍の値を有する。要求されたスロット数が、利用可能なスロットより大きい場合は、方法はブロック７１８に進む。要求されたスロット数が、利用可能なスロットの数より小さいか又は同じ場合は、方法はブロック７０４に進む。

ブロック７１８では、詰め込み失敗が決定される。例えば、一実施形態では、ＭＵＸロジック２１０は、これらのサービスを詰め込む利用可能なスロットが十分に無いと判断し、方法はこの後ブロック７１６で終了する。

ブロック７０４では、各ＲＴサービスに対するmaxSlotHeightパラメータが計算される。例えば、一実施形態では、ＭＵＸロジック２１０は、この計算を実行する働きをする。maxSlotHeightは、それぞれのＲＴサービスに対して許容される、シンボル当たりの最大スロット数を示す。

ブロック７０６では、多重化されるべき各ＲＴサービスは、これらのmaxSlotHeightパラメータに基づいて、「３ブロックサービス」（threeBlkSrvcs）、「４ブロックサービス」（fourBlkSrvcs）、「６ブロックサービス」（sixBlkSrvcs）、及び「７ブロックサービス」（sevenBlkSrvcs）にグループ化される。一実施形態の中では、ＭＵＸロジック２１０は、サービスを、これらのスロット要求によりグループ化する働きをする。

ブロック７０８では、各グループのＲＴサービスは、データスロット数の減少方向にソートされる。例えば、ＲＴサービスは、要求されたデータスロットに対して最大から最小へとソートされる。

ブロック７１０では、長さ変数Ｌ７、Ｌ６、Ｌ４、及びＬ３が計算される。例えば、sevenBlkSrvcsの長さは「Ｌ７］、sixBlkSrvcsの長さは「Ｌ６」、fourBlkSrvcsの長さは「Ｌ４］、threeBlkSrvcsの長さは「Ｌ３」である。例えば、全てのsevenBlkSrvcsの長さは以下のように定義される。

Ｌ７＝ｃｅｉｌ（全てのsevenBlkSrvcsのデータスロットの合計／７）
ここで、ｃｅｉｌ（ｘ）は、ｘより大きい最小の整数である。一実施形態の中では、ＭＵＸロジック２１０は、長さパラメータ（Ｌ７、Ｌ６、Ｌ４、及びＬ３）を計算する働きをする。

ブロック７１２では、１つ以上の不等式チェックが実行される。例えば、以下の不等式がチェックされて、それぞれが真か偽かを判断する。

Ｌ７＋Ｌ３＋Ｌ６＜＝numOfdmSymbolsPerFrm （１）
Ｌ７＋Ｌ４＋Ｌ６＜＝numOfdmSymbolsPerFrm （２）
上記の不等方程式の結果として、４つの不等条件が確定される。最初の不等式（１）は、以下において（１Ｔ、１Ｆ）と呼ばれる、真及び偽の結果を有する。２つ目の不等式（２）は、以下において（２Ｔ、２Ｆ）と呼ばれる、真及び偽の結果を有する。従って、上記の２つの不等式は、多重化システムの１つ以上の実施形態に従ってスロットを割り当てするために用いられる、４つの不等条件（すなわち、１Ｔ２Ｔ、１Ｔ２Ｆ、１Ｆ２Ｔ、１Ｆ２Ｆ）をもたらす。

ブロック７１４で、スロットは、４つの中の１つの不等条件に基づいてＲＴサービスに割り当てされる。例えば、ブロック７１２で実行された不等式チェックの結果は、ＲＴサービスにスロットを割り当てるために用いられる。４つの条件のそれぞれは、本明細書の後続の章において議論される割り当て方法の中で説明されるように、割り当てを決定する。

方法７００は、ただ１つのインプリメンテーションのみを表し、方法７００の変更、追加、削除、複合又は他の修正は、各実施形態の範囲の中で可能であるということに留意されたい。

図８は、多重化システムの中で用いる第１の不等条件に基づいて、ＲＴサービスにスロットを割り当てる方法８００の一実施形態を示す。例えば、方法８００は、（１Ｔ２Ｔ）によって表される第１の不等条件に関連するスロット割り当てを提供する。一実施形態の中では、ＭＵＸロジック２１０は、以下に説明するような方法８００の機能を提供する働きをする。

ブロック８０２では、テストが実行されて、第１の不等式の状態が真（すなわち１Ｔ）かどうかを判断する。第１の不等式（１）の状態が１Ｔでない場合、方法はブロック８０４に進む。第１の不等式（１）の状態が１Ｔの場合、方法はブロック８０６に進む。

ブロック８０４で、方法は、第２の不等条件のテストに進む。例えば、第１の不等式（１）の状態が１Ｔでないことから、方法は、第２の不等条件（１Ｔ２Ｆ）のテストをするために方法９００に進む。

ブロック８０６では、テストが実行されて、第２の不等式（２）の状態が真（すなわち２Ｔ）かどうかを判断する。第２の不等式（２）の状態が２Ｔでない場合、方法はブロック８０４に進む。第２の不等式（２）の状態が２Ｔの場合、方法はブロック８０８に進む。

ブロック８０８で、方法は最終動作に進む。両状態（１Ｔ２Ｔ）が存在することから、方法は、スロット割り当てを完了するために最終動作（以下に記述）に進む。

方法８００は、ただ１つのインプリメンテーションのみを表し、方法８００の変更、追加、削除、複合又は他の修正は、各実施形態の範囲の中で可能であるということに留意されたい。

図９は、多重化システムの中で用いる、第２の不等条件に基づいて、ＲＴサービスにスロットを割り当てる方法９００の一実施形態を示す。例えば、方法９００は、（１Ｔ２Ｆ）で表される第２の不等条件に関連するスロット割り当てを提供する。一実施形態の中では、ＭＵＸロジック２１０は、以下に説明するような方法９００の機能を提供する働きをする。

ブロック９０２では、第１の不等式（１）の状態が真（すなわち１Ｔ）かどうかを判断するために、テストが実行される。第１の不等式（１）の状態が１Ｔでない場合、方法はブロック９０４に進む。第１の不等式（１）の状態が１Ｔの場合、方法はブロック９０６に進む。

ブロック９０４で、方法は、第３の不等条件のテストに進む。例えば、第１の不等式（１）の状態が１Ｔでないことから、方法は、第３の不等条件（１Ｆ２Ｔ）のテストをするために方法１１００に進む。

ブロック９０６では、第２の不等式（２）の状態が偽（すなわち２Ｆ）かどうかを判断するために、テストが実行される。第２の不等式（２）の状態が２Ｆでない場合、方法はブロック９０４に進む。第２の不等式（２）の状態が２Ｆの場合、方法は４ブロックサービスが処理されるブロック９０８に進む。

図１０は、過剰な４ブロックサービスを割り当てする、多重化システムの実施形態の動作を図解する、フレーム１０００を示す。例えば、割り当てブロックは、threeBlk１００２、fourBlk１００４、sixBlk１００６、及びsevenBlk１００８を備える。割り当てブロックはまた、reg2Blk１０１０も含んでいる。フレーム１０００は、方法９００がどのように、過剰な４ブロックサービス（fourBlkSrvc）１０１２を、fourblk１００４、threeBlk１００２、reg2blk１０１０の各割り当てブロックに割り当てする働きをするかを説明する。一実施形態では、方法９００は、図１０に示すフレーム１０００にＲＴサービスを割り当てる働きをする。

再度図９を参照すると、ブロック９０８で、４ブロックサービスが処理されている。例えば、一実施形態の中では、ＭＵＸロジック２１０は、図１０に示すフレーム１０００を参照して以下に説明されるように、４ブロックサービスを処理する働きをする。

ａ．次のようなfourBlkSrvc、すなわち、このfourBlkSrvcまでは、fourBlk１００４が上記の方法８００を参照して説明された第１の不等条件を満足することができる、fourBlkSrvcを探す。次に過剰なfourBlkSrvcs無しで、fourBlk１００４を更新する。

ｂ．過剰なfourBlkSrvcsを、threeBlk１００２とreg2Blk１０１０に移す。

reg2Blk１０１０は、図１０に示すように、高さ１のブロックである。

ｃ．過剰なfourBlkSrvcsを移動する間に、次に続くサービスがfourBlk１００４そのものに収まることができるかどうかもチェックする。

ｄ．以下の条件不等式が真の場合に限り、移動を完了する。

（（Ｌ７＋Ｌ３＋Ｌ６）＜＝numOfdmSymbolsPerFrm）＆＆
（（Ｌ７＋Ｌ４＋Ｌ６）＜＝numOfdmSymbolsPerFrm）＆＆
（（Ｌ７＋Ｌ４＋Ｌｒｅｇ２）＜＝numOfdmSymbolsPerFrm）
ブロック９１０では、テストが実行されて、過剰な４ブロックサービスが上述のように移動され得るかどうかを判断する。過剰なfourBlkSrvcsが、ブロック９０８において、条件不等式を満足させるためにthreeBlk１００２かreg2Blk１０１０かのどちらかに移動できない場合は、方法はブロック９１４に進んで、詰め込み失敗が確定され、方法は停止する。過剰なfourBlkSrvcsを移動できる場合は、方法はブロック９１２に進む。

ブロック９１２で、方法は最終動作に進む。過剰なfourBlkSrvcsが成功裏に移動できたことから、方法は、最終処理に進み、スロット割り当てを完了する。

方法９００は、ただ１つのインプリメンテーションのみを表し、方法９００の変更、追加、削除、複合又は他の修正は、各実施形態の範囲の中で可能であるということに留意されたい。

図１１は、多重化システムの中で用いる、第３の不等条件に基づいて、ＲＴサービスにスロットを割り当てる方法１１００の一実施形態を示す。例えば、方法１１００は、第３の不等条件（１Ｆ２Ｔ）が存在する場合に、割り当てを提供する。一実施形態の中では、ＭＵＸロジック２１０は、以下に説明するような方法１１００の機能を提供する働きをする。

ブロック１１０２では、第１の不等式（１）の状態が偽（すなわち１Ｆ）かどうかを判断するために、テストが実行される。第１の不等式（１）の状態が１Ｆでない場合、方法はブロック１１０４に進む。第１の不等式（１）の状態が１Ｆの場合、方法はブロック１１０６に進む。

ブロック１１０４で、方法は、次に第４の不等条件を処理する。例えば、第１の不等式（１）の状態は１Ｆでないことから、方法は、残っている唯一の条件なので存在するに違いない第４の不等条件（１Ｆ２Ｆ）を処理するために、方法１３００に進む。

ブロック１１０６では、第２の不等式の状態が真（すなわち２Ｔ）かどうかを判断するためにテストが実行される。第２の不等式（２）の状態が２Ｔでない場合、方法はブロック１１０４に進む。第２の不等式（２）の状態が２Ｔの場合、方法はブロック１１０８に進む。

図１２は、過剰な３ブロックサービスを割り当てする、多重化システムの実施形態の動作を図解する、フレーム１２００を示す。例えば、割り当てブロックは、threeBlk１２０２、fourBlk１２０４、sixBlk１２０６、reg2Blk１２０８、reg1Blk１２１０を備える。フレーム１２００は、方法１１００がどのように、過剰な３ブロックサービス（threeBlkSrvcs）１２１２を、threeBlk１２０２、reg1Blk１２１０、及びreg2Blk１２０８の各割り当てブロックに割り当てする働きをするかを説明する。

再度図１１を参照すると、ブロック１１０８で、３ブロックサービス（threeBlkSrvcs）が処理されている。例えば、一実施形態では、ＭＵＸロジック２１０は、以下のようにthreeBlkSrvcsを処理する働きをする。

ａ．次のようなthreeBlkSrvc、すなわち、このthreeBlkSrvcまでは、threeBlk１２０２が上記の方法８００を参照して説明された第１の不等条件を満足することができる、threeBlkSrvcを探す。次に過剰なthreeBlkSrvcs無しで、threeBlk１２０２を更新する。

ｂ．過剰なthreeBlkSrvcsを、reg1Blk１２１０とreg2Blk１２０８に移す。Reg1Blk１２１０は、図１２に示すように、高さ３のブロックである。

ｃ．移動する間に、次に続くサービスがthreeBlk１２０２そのものに収まることができるかどうかもチェックする。

ｄ．以下の条件不等式が真の場合に限り、移動を完了する。

（（Ｌ７＋Ｌ３＋Ｌ６）＜＝numOfdmSymbolsPerFrm）＆＆
（（Ｌ７＋Ｌ４＋Ｌｒｅｇ１＋Ｌ６）＜＝numOfdmSymbolsPerFrm）＆＆
（（Ｌ７＋Ｌ４＋Ｌｒｅｇ２）＜＝numOfdmSymbolsPerFrm）
ブロック１１１０では、テストが実行されて、過剰な３ブロックサービスが移動され得るかどうかを判断する。過剰なthreeBlkSrvcsが、ブロック１１０８において、条件不等式を満足させるためにreg1Blk１２１０かreg2Blk１２０８かのどちらかに移動できない場合は、方法はブロック１１１２に進んで、詰め込み失敗が確定され、方法は停止する。過剰な３ブロックサービスを移動できる場合は、方法はブロック１１１４に進む。

ブロック１１１４で、方法は最終動作に進む。過剰なthreeBlkSrvcsが成功裏に移動できたことから、方法は、最終処理に進み、スロット割り当てを完了する。

方法１１００は、ただ１つのインプリメンテーションのみを表し、方法１１００の変更、追加、削除、複合又は他の修正は、各実施形態の範囲の中で可能であるということに留意されたい。

図１３は、多重化システムの中で用いる、第４の不等条件に基づいてＲＴサービスにスロットを割り当てる方法１３００の、一実施形態を示す。方法１３００は、第１、及び第２、及び第３の不等条件が存在しない場合の割り当てを提供する。この場合、不等方程式の状態は（１Ｆ２Ｆ）で表すことができる。一実施形態の中では、ＭＵＸロジック２１０は、以下に説明するような方法１３００の機能を提供する働きをする。

図１４は、過剰な６ブロックサービスを割り当てする、多重化システムの実施形態の動作を図解する、フレーム１４００を示す。例えば、フレーム１４００は、threeBlk１４０２、fourBlk１４０４、reg2Blk１４０６、sixBlk１４０８の各割り当てブロックを備える。フレーム１４００は、過剰な６ブロックサービス（sixBlkSrvcs）１４１０がどのように割り当てされるかを図解する。

再度図１３を参照すると、ブロック１３０２で、６ブロックサービスが処理されている。例えば、一実施形態では、ＭＵＸロジック２１０は、以下のように６ブロックサービスを処理する働きをする。

ａ．次のようなsixBlkSrvc、すなわち、このsixBlkSrvcまでは、fourBlk１４０４及びsixBlk１４０８が上記の方法８００を参照して説明された第１の不等条件を満足することができる、sixBlkSrvcを探す。次に過剰なサービス無しで、sixBlk１４０８を更新する。

ｂ．過剰なsixBlkSrvcsを、threeBlk１４０２、fourBlk１４０４、及びreg2Blk１４０６に移す。

ｃ．移動する間に、次に続くサービスがsixBlk１４０８そのものに収まることができるかどうかもチェックする。

ｄ．以下の条件不等式が真の場合に限り、移動を完了する。

（（Ｌ７＋Ｌ３＋Ｌ６）＜＝numOfdmSymbolsPerFrm）＆＆
（（Ｌ７＋Ｌ４＋Ｌ６）＜＝numOfdmSymbolsPerFrm）＆＆
（（Ｌ７＋Ｌ４＋Ｌｒｅｇ２）＜＝numOfdmSymbolsPerFrm）
ブロック１３０４では、テストが実行されて、過剰な６ブロックサービスが移動され得るかどうかを判断する。過剰な６ブロックサービスが、ブロック１３０２において、条件不等式を満足させるためにfourBlk１４０４、threeBlk１４０２、又はreg2Blk１４０６に移動できない場合は、方法はブロック１３０６に進んで、詰め込み失敗が確定され、方法は停止する。過剰な６ブロックサービスを移動できる場合は、方法はブロック１３０８に進む。

ブロック１３０８で、方法は最終動作に進む。過剰なsixBlkSrvcsが成功裏に移動できたことから、方法は、最終処理に進み、スロット割り当てを完了する。

方法１３００は、ただ１つのインプリメンテーションのみを表し、方法１３００の変更、追加、削除、複合又は他の修正は、各実施形態の範囲の中で可能であるということに留意されたい。

（最終動作）
このようにして、上記で実行される動作から、どのブロックにそれぞれのＲＴサービスが割り当てられるかに関する情報が得られる。加えて、あるフレームに対してＲＴサービスの各チャネルが有するデータのスロット数は、今や既知である。この情報は、全てのチャネル割り当てのロケーションに到達するに充分である。一実施形態の中では、スロットは、ブロックの最大高さ制約を順守して、ブロック内のチャネルに隣接して割り当てされてもよい。

（詰め込み例）
図１５は、多重化システムの中で用いられる、２つのＲＴサービスを１つの送信フレームの中に詰め込むための割り当てアルゴリズムの実施形態の動作を説明する、フレーム１５００を示す。この例では、この２つのＲＴサービス、すなわちサービスＡ及びＢは、フレーム１５００のfourBlk領域の中に詰め込まれる。説明のために、先行する動作が、双方のＲＴサービスはfourBlk領域の中にあると判断したと仮定しよう。同様に、これらのＲＴサービスの両方は、２つのチャネル、すなわちチャネル１及び２を有すると仮定しよう。更に、各チャネルに対するデータスロットの数は以下の通りであると仮定しよう。

サービスＡのチャネル１＝９
サービスＡのチャネル２＝９
サービスＢのチャネル１＝８
サービスＢのチャネル２＝７
フレーム１５００の中に図解されたように、これらのＲＴサービスは以下のパラメータに従って、fourBlk領域の中に詰め込まれる。

サービスＡチャネル１（１５０２）
開始シンボル＝５
開始スロット＝６
最下位スロット＝４
最上位スロット＝７
合計スロット＝９
サービスＡチャネル２（１５０４）
開始シンボル＝７
開始スロット＝７
最下位スロット＝４
最上位スロット＝７
合計スロット＝９
サービスＢチャネル１（１５０６）
開始シンボル＝１０
開始スロット＝４
最下位スロット＝４
最上位スロット＝７
合計スロット＝８
サービスＢチャネル２（１５０８）
開始シンボル＝１２
開始スロット＝４
最下位スロット＝４
最上位スロット＝７
合計スロット＝７。

（アルゴリズム概要）
１つ以上の実施形態の中では、割り当てアルゴリズムは、フレームの中へのフローの効率的な詰め込みをもたらし、これにより、受信デバイスの「目を覚ます」頻度及び「オンタイム」を最小化する。例えば、サービスのチャネルを一緒にグループ化することは、目を覚ます頻度を低減し、一方maxSlotHeightでのサービスの送信は、オンタイムを削減する。

一実施形態の中では、アルゴリズムにより提供されるスロット割り当てが４つの不等条件の中の１つのために失敗した場合、アルゴリズムは指令を、どのようにサービスをリサイズするか制御するリサイズ制御部２１２に伝える。リサイズ制御部２１２が、これらの指令に基づいてリサイズされたサービスを有している場合は、詰め込みの解決策は保証される。

図１６は、ＲＴサービスを、使用されないスロットが２つの領域にグループ化されるような方法で詰め込む、割り当てアルゴリズムの実施形態の動作を説明する、フレーム１６００を示す。使われないスロットをより少ない領域に集めるということは、割り当てアルゴリズムに入力されるサービスよりも低いプライオリティのサービスによる、これらのスロットのよりよい利用を確実にする。一実施形態では、ＯＲＴサービスがこれらの領域に詰め込まれてもよい。例えば、フレーム１６００の中では、使用されないスロットは領域１６０２及び１６０４の中にグループ化される。

（リアルタイムサービス・リサイズアルゴリズム）
１つ以上の実施形態では、リサイズ制御部１１６は、サービスがフレームの中に詰め込まれることが可能になるように、これらのサービスをどのようにリサイズするかを制御する働きをする。例えば、サービスは、これらの関連する配信要求を調整するためにリサイズされる。一実施形態では、１つ以上のサービスが関連する帯域幅要求を低減するためにリサイズされる。しかしながら、リサイズ制御部１１６は、任意の関連する配信要求を調整するために、サービスをリサイズする働きをする。以下の記述は、ＲＴサービスの中のコンポーネントストリームをリサイズする働きをする、リサイズアルゴリズムを説明している。ＲＴサービスのリサイズを生じさせる条件も、同様に提供される。一実施形態では、リサイズ制御部１１６は、リサイズパラメータを決定するリサイズアルゴリズムを実行する働きをする。これらのパラメータは、次にリサイズ要求の中のＲＴサービスに関連するＲＴＭＳへと送信される。ＲＴＭＳは次に、特定されたＲＴサービスを、上記のリサイズ要求の中のパラメータに従ってリサイズする働きをする。

リサイズ制御部１１６はまた、任意のＯＲＴサービスをリサイズする働きもするということに留意されたい。例えば、リサイズ制御部１１６は、１つ以上のＯＲＴサービスがどのようにリサイズされるべきかを判断し、この決定したリサイズを実行するために任意のＮＲＴＭＳと通信する働きをすることが可能である。結果として、これらのサービスに関連する配信要求が調整される。例えば、リサイズ制御部１１６は、あるＯＲＴサービスの帯域幅要求を低減するためにＮＲＴＭＳと通信しても良く、これによりこのＯＲＴサービスの配信要求を調整する。従って、ＲＴサービスのリサイズを参照して本明細書において説明された実施形態は、ＯＲＴサービスにも同じように適用可能である。

図１に示すように、ＭＵＸ１１４は、コンテンツのフローデータ、及びＲＴＭＳ１２６及びＮＲＴＭＳ１２８からの関連するシグナリングデータを受信する。スーパーフレームごとに、ＭＵＸ１１４は、全てのアクティブなリアルタイムサービスに対してＲＴＭＳ１２６と、且つ随意的にＯＲＴサービスに対してＮＲＴＭＳ１２８と、データ帯域幅を交渉する。一実施形態では、帯域幅交渉は、以下の動作シーケンスを含む。

ａ．ＭＵＸ１１４は、あるスーパーフレームの中で送信すべきＲＴサービスに対するデータのサイズを要求するために、GetDataSize.Requestメッセージを、ＲＴＭＳ１２６に送る。

ｂ．ＲＴＭＳ１２６は、スーパーフレームの中で送信すべき上記ＲＴサービスに対するデータのサイズを指定する、GetDataSize.Responseメッセージを、ＭＵＸ１１４に送る。

ｃ．ＭＵＸ１１４は、ＲＴＭＳ１２６及び他のソースから受信した全てのデータサイズに基づき、コンテンツのスケジューリング（割り当て）を実行する。

ｄ．ＭＵＸ１１４は、ＲＴＭＳ１２６に、ＲＴサービスのフローデータに対する更新されたサイズを、UpdateDataSize.Notificationメッセージの一部として、送信する。

一実施形態の中では、ＭＵＸ１１４は、上述のスロット割り当てアルゴリズムの実施形態を備えるコンテンツスケジューリング機能を提供する働きをする。リサイズ制御部１１６は、リサイズアルゴリズムの実施形態を提供する。このスロット割り当てアルゴリズムは、スーパーフレーム内の全てのメディアサービスに割り当てられるスロット（レート）を、うまく適合させることに関与する。.特定のシステム制約（例えば、デバイス上のターボ復号器の最大スループットが、単一のＯＦＤＭシンボルの中で特定のメディアサービスに与えることができるスロット数を制限する）が、与えられたスロットの合計がスーパーフレーム内の利用可能なスロットの総数を下回るか又はこれと同じにもかかわらず、スロット割り当て手続きの失敗をもたらす可能性がある。また、無線リンクリソースに対する要求を支配すると予想されるリアルタイムのサービスコンポーネントは、ビデオコンテンツである。このコンテンツは、非常に変化しやすいビットレートのフローに帰着する、ソースコーディングを用いて圧縮される。最後に、リアルタイムサービスの送信のために利用可能なスーパーフレーム当たりの容量は、他の同時に起こるメディアサービスの要求のために変化する可能性がある。これらの要因は、以下の割り当て状態の生起につながる。

１．ＲＴサービスにより要求される全てのデータの合計が、利用可能な容量に満たないか又はこれに等しく、スロット割り当てアルゴリズムは成功する。

２．ＲＴサービスにより要求される全てのデータの合計が、利用可能な容量に満たないか又はこれに等しいが、スロット割り当てアルゴリズムは失敗する。

３．ＲＴサービスにより要求される全てのデータの合計が、利用可能な容量を超える。

割り当て状態２及び３は、ＲＴサービスフローにより要求されるデータの量の割り当ての失敗に帰着する。これらのシナリオでは、ＭＵＸ１１４はリサイズ制御部１１６を起動して、ＲＴサービスをリサイズするためにリサイズアルゴリズムを実行する。次の章は、リアルタイムサービスに対する品質の概念と、リサイズアルゴリズムの実施形態の目的を説明する。

（リアルタイムサービスの品質及びリサイズアルゴリズムの目的）
品質の概念は、リアルタイムストリーミングメディアサービスの中のビデオフローに関連する。リアルタイムサービスの品質（Ｑ）は、サービスフローに割り当てられるビットレート（ｒ）の関数であり、またこれは以下で表される品質関数によりモデル化される。

Ｑ＝ｆ（ｒ） （３）
スーパーフレーム毎に、ＲＴＭＳ１２６は、ＭＵＸ１１４がこの関数を評価することを支援する情報を提供する。これは、ＭＵＸ１１４へ、GetDataSize.Responseメッセージの中で送信される。以下の章で説明されるように、ＭＵＸ１１４は、リサイズ手順を手助けして、この情報をリアルタイムサービスの品質見積もりのために用いる。任意の選択された品質測定又は特性は、品質見積もり目的のためにＭＵＸ１１４により用いられるということも同様に注目すべきである。

リサイズアルゴリズムは、レートを（物理レイヤパケット（ＰＬＰ）を単位にして）、スロット割り当てアルゴリズムが成功することができるように、割り当てられたレートの合計がＲＴサービスに対する利用可能な容量より少ないか又はこれと同じになるように、リアルタイムサービスに割り当てる。従って、一実施形態の中では、ＲＴサービスへのレートの割り当ては、ＲＴサービスのビデオフローの品質関数が、以下に従って、これらの重量に比例するようにすべきである。

（Ｑｉ／Ｑｊ）＝（Ｗｉ／Ｗｊ） （４）
ここで、Ｑｉ（Ｗｉ）及びＱｊ（Ｗｊ）は、任意のＲＴサービスｉ、ｊに対する品質関数（フロー重量）である。品質関数は、上記の方程式（３）を用いて見積もられる。フローに関連する重量の値は、他のＲＴビデオフローとの間でのこのフローの相対的な重要性の尺度を与える。一実施形態の中では、ＭＵＸ１１４はこれらのフローの重量値を、「契約プロビジョニングサブシステム」から取得し、このサブシステムは、流通ネットワークに関連するサービス計画・管理機能に同様に関与してもよい。

（リサイズアルゴリズム）
この章では、ＲＴサービスのリサイズアルゴリズムについての実施形態を説明する。このアルゴリズムは、ＲＴサービスの中のビデオコンポーネントストリーム（フロー）に対するレート割り当てに集中する、反復アプローチを用いる。このアルゴリズムは、各ビデオストリームにより要求されるＰＬＰ数（レート）から始まる。アルゴリズムの反復のそれぞれには、レート削減のための候補サービスを特定することが含まれている。候補ストリームは、レート削減に最も鈍感であり、且つ他のストリームと比べて品質上好ましくない削減に苦しむことの無いストリームである。一実施形態では、リサイズアルゴリズムの機能は、図２に示すリサイズ制御部２１２により提供される。

候補ストリームが特定された後、このストリームに割り当てられるレートは削減される。例えば、レートは、２つのリードソロモンコードのブロックに相当する量だけ削減してもよい。ネットワークは、１つのリードソロモンブロックに相当するＰＬＰの数で規定される細かさで、全てのサービスにレートを割り当てする。ビデオストリームは、基本及び強化ビデオコンポーネントを伴って、ネットワークの階層化された送信モードの１つを用いて送信されるものと思われる。加えて、システムは、この２つのビデオコンポーネントの中のデータが同等であるべきとの制約をかける。従って、レート削減の単位として、２つのリードソロモンブロックの選択となる。しかしながら、任意の他の選択された量だけストリームのレートを削減することは、本実施形態の範囲内であるということに留意されたい。

（定数）
以下の定数パラメータが、リサイズ機能を提供するために、多重化システムの実施形態の中で用いられる。

rateReductionBnd
任意のリアルタイムビデオストリームに対するレートの部分削減についての上限。この上限は、ストリームにより要求されるレートに関連してのものである。一実施形態の中では、０．５の値が用いられる。

sysMin
ストリームの品質に対する最小値。これは、レート削減上限に達したストリームが更にレート削減されるのを防ぐために用いられる。

payloadPLP
１つのＰＬＰに対する有効なペイロードであり、これはおよそ９６８ビットである。

（アルゴリズムの入力）
以下の入力が、リサイズ機能を提供するために、多重化システムの実施形態の中で用いられる。

maxRTSOFDMSym
リアルタイムサービスに対して利用可能なスーパーフレーム当たりの、ＯＦＤＭシンボル数における容量。

numRTS
利用可能な容量を共有するリアルタイムサービスの数。

numVStreams
リアルタイムサービスの中のビデオコンポーネントストリームの総数。例えば、VStreamは、それぞれのリアルタイムビデオコンポーネントストリームを記述する構造のリストである。

_weight
ストリームに対する相対的な重量値を保持する。

requestedPLPs
ストリームにより要求される、スーパーフレーム当たりのＰＬＰの数を保持する。requestedPLPs×payloadPLP（９６８ビット）として、要求された生のビット数を見積もることが可能である。

rsCodeParameterK
リードソロモン（Ｎ、Ｋ）コードに対するパラメータＫ。

（変数）
以下の変数が、リサイズ機能を提供するために、多重化システムの実施形態の中で用いられる。

reqPLPs[numVStreams]
ビデオコンポーネントストリームを特定する数（０〜numVStreams−１）によりインデックスが付けられた配列。この配列は、VStream構造のrequestedPLPs部分により指示されるものとしての、このストリームにより要求されるスーパーフレーム当たりのＰＬＰ数を保持する。

assgnPLPs[numVStreams]
ビデオコンポーネントストリームを特定する数（０〜numVStreams−１）によりインデックスが付けられた配列。この配列は、このストリームに割り当てられた、スーパーフレーム当たりのＰＬＰ数を保持する。

tempPLPs[numVStreams]
ビデオコンポーネントストリームを特定する数（０〜numVStreams−１）によりインデックスが付けられた配列。この配列は、ビデオコンポーネントストリームに割り当てられた、スーパーフレーム当たりのＰＬＰ数を保持する。これは、アルゴリズムにより内部的に用いられる一時的変数である。

weight[numVStreams]
ビデオコンポーネントストリームを特定する数（０〜numVStreams−１）によりインデックスが付けられた配列。この配列は、VStream構造の重量部分により表される、ストリームの相対的重量値を保持する。

effQuality[numVStreams]
ビデオコンポーネントストリームを特定する数（０〜numVStreams−１）によりインデックスが付けられた配列。この配列は、リアルタイムサービスストリームに対する見積り品質を保持する。

PLPsPerRSBlk[numVStreams]
ビデオコンポーネントストリームを特定する数（０〜numVStreams−１）によりインデックスが付けられた配列。この配列は、VStream構造のrsCodeParameterK部分により指示されるものとしての、リードソロモンコードブロック当たりのデータＰＬＰ数を保持する。

（アルゴリズムの出力）
以下の出力が、リサイズ機能を提供するために、多重化システムの実施形態の中で用いられる。

successFlag
リサイズアルゴリズムが、制約を満足させるレート割り当てに集中することに成功した場合に、１にセットされるフラグ。そうでなければ、successFlagは０に設定される。

（リサイズアルゴリズムにより呼び出される内部手順）
以下は、多重化システムの実施形態の中で、リサイズアルゴリズムにより呼び出される内部手順である。

reducePLPs()
レート削減のためのビデオストリームを特定し、このストリームに割り当てられるデータの量を削減する、手順。この手順は、メインルーチンに対して定義される変数空間を共有する。

（再符号化アルゴリズムに呼び出される外部アルゴリズム）
以下は、多重化システムの実施形態の中で、リサイズアルゴリズムにより呼び出される外部手順である。

slotAllocation
スロット割り当てアルゴリズムは、スーパーフレーム内の全てのメディアサービスに割り当てられるスロット（レート）をうまく適合させることに関与する。リサイズアルゴリズムは、全てのメディアサービスに対して割り当てられるデータ（レート）を含む、要求される入力引数を伴って、スロット割り当てアルゴリズムを呼び出す。

（アルゴリズム）
以下は、多重化システムの実施形態の中で用いるリサイズアルゴリズムの一実施形態の説明である。一実施形態の中では、リサイズ制御部２１２は、リサイズアルゴリズムを実装し、以下の機能の１つ以上を実行する。

ａ．VStream構造データを用いて、reqPLPs[]、qualityIndex[]、PLPsPerRSBlk[]、及びweight[]の配列を生成する。

ｂ．配列assgnPLPs[]の全ての要素を、reqPLPs[]の中の対応する要素に初期セットする。

ｃ．algorithmFlag＝１及びsuccessFlag＝０に初期セットする。

ｄ．以下の関数を実行する。

While algorithm Flag==1
reducePLPs()
if reduction 0
call slotAllocation Algorithm
if slotAllocation Algorithm succeeds
algorithmFlag=0
success Flag=1
endif
else
/*この状態は、reteReductionBndの限界を尊重しつつ、リサイズに失敗したということを意味する。*/
endif
endwhile
以下の関数が、reducePLPs()手順の一部として実行される。

for i = 0 to numVStreams
tempPLPs[i] = assgnPLPs[i]
tempPLPs[i] = tempPLPs[i] - 2 x PLPsPerRSBlk[i]
/*ストリームに割り当てられたＰＬＰは、２つのリードソロモンブロックに相当する量だけ、削減される。一実施形態の中では、ＲＳブロック１つが、基本及び強化コンポーネントの双方から除去される。システムは、基本及び強化ビデオコンポーネントの中のデータが同等であるべきとの制約をかける。*/
if tempPLPs[i] / reqPLPs[i] > = rateReductionBnd
effQuality[i] = f(tempPLPs[i] x payloadPLP) / weight[i]
else
effQuality[i] = sysMin
endif
endfor
/*ここで、ｆ（）は、品質を評価するために用いることができる任意の適切な関数である。*/
ｅ．配列effQuality[]により与えられる最大有効品質を伴う、サービスのインデックスを特定する。この値にインデックスパラメータをセットする。

ｆ．以下の関数を実行する。

if effQuality[_index] == sysMin
/*この状態は、reteReductionBndの限界を尊重しつつ、リサイズに失敗したということを意味する。*/
reduction = -1
else
reduction = 2 x PLPsPerRSBlkLindex]
assgnPLPsLindex] = tempPLPsLindex]
endif
このようにして、リサイズ制御部２１２は、多重化システムの実施形態の中でサービスをリサイズするための上記の機能を提供する働きをする。例えば、上述の割り当てアルゴリズムの実施形態により提供されるように、ＲＴサービスのレートは削減されて、このサービスがスーパーフレームの利用可能なスロットに割り当てされることを可能とする。

（リアルタイムサービス以外のサービス（ＯＲＴＳ））
さまざまな制約を考慮しており、且つＯＦＤＭシンボルの中でサービスのために送信されるターボパケット数がデバイスにより復号化できるということを確実にする、スロット割り当てアルゴリズムの実施形態が上で説明されている。このアルゴリズムは、デバイスがいつでもただ１つのＲＴサービスを受信することを必要とされることから、ＲＴサービスに望ましい。しかしながら、デバイスは、１つのスーパーフレームの中で複数のＯＲＴサービスを受信している可能性がある。同じアルゴリズムが用いられる場合、このデバイスにより申し込まれた全てのＯＲＴサービスに対する１つのＯＦＤＭシンボル内のパケットの総数は、このデバイスの限界よりも大きくなる可能性がある。これは、「ターボパケット衝突」と称される。ターボパケット衝突は、ＯＲＴサービスデータの紛失につながる。紛失の規模は、ユーザの契約パターンに一般的に依存する。従って、ターボパケット衝突を完全に除去する、ＯＲＴサービスに対するスロット割り当てアルゴリズムの追加の実施形態が提供され、以下に説明される。

図１７は、多重化システムの中で用いる、ＲＴサービスとＯＲＴサービスの領域に分割されたフレーム１７００の実施形態を示す。第１の領域１７０２は、ＲＴサービスのために提供され、第２の領域１７０４はＯＲＴサービスのために提供される。これらの領域にフレームを分割するということは、ＲＴサービスとＯＲＴサービスとの間にターボパケット衝突が無いということを確実にするであろう。ＲＴ領域１７０２とＯＲＴ領域１７０４との間のパーティションは、「ソフト」パーティションである（すなわち、これは、スーパーフレームからスーパーフレームへと、スーパーフレームの中で利用可能なＲＴ及びＯＲＴサービスデータに応じて変化する）。ＲＴサービスは、上述のスロット割り当てアルゴリズム及びリサイズアルゴリズムの実施形態を用いて、ＲＴサービス領域１７０２の中にスロット割り当てされる。ＯＲＴサービスは、以下に説明するＯＲＴサービスアルゴリズムの実施形態を用いて、ＯＲＴサービス領域１７０４にスロット割り当てされる。１つ以上の実施形態の中で、ＯＲＴサービスは同様に、利用可能な帯域幅に収まるようにリサイズされる。ＯＲＴサービスに適用されるリサイズのより詳細な説明は、以下に提供される。

（ＯＲＴサービススロット割り当て）
受信デバイスの電力消費に関しては、ＭＬＣ割り当ての高さは、これのmaxSlotHeightであることが好ましい。これは、このデバイスに対して、このＭＬＣを受信するための見込みの「オンタイム」を最小化する。しかしながら、詰め込みを簡略化するために、あるサービスについてのグループ化されたＭＬＣの全てが、同じ高さで割り当てされる。従って、ＯＲＴサービスに対してさえも、「サービスのmaxSlotHeight」の概念は、このサービスのためにグループ化された全てのＭＬＣについての、最小のすなわち最も小さいmaxSlotHeightパラメータとして定義される。この説明の残りについては、サービスの高さは、このサービスの全てのＭＬＣ割り当ての共通の高さを意味するであろう。

（サービスのチャネルのグループ化）
一実施形態では、サービスの全てのチャネルは、これらの割り当てがフレームの中で時間的に隣接するように、グループ化される。このアプローチは、デバイスがあるサービスについての異なるチャネルを受信するために「目を覚ます」ために必要な回数を低減し、従って、これは、このデバイスが電力消費を低減する助けとなる。

（ＯＲＴＳ領域のブロックへの分割）
図１８は、ＯＲＴＳ領域が異なる高さのブロックに分割される、フレーム１８００の一実施形態を示す。一実施形態では、ブロック高さは、あるサービスが取ることができる、可能なmaxSlotHeightに相当する。表５００から、４つのmaxSlotHeight（すなわち、３、４、６、及び７）が存在するということが分かる。従って、フレーム１８００は、関連するサービスを割り当てするために用いられる、threeBlk１８０２、fourBlk１８０４、sixBlk１８０６、及びsevenBlk１８０８の各領域を示している。ＯＲＴサービススロット割り当てアルゴリズムは、次にmaxSlotHeightに基づき、異なる各ブロックの中にサービスを詰め込む働きをする。

（どのブロックも他の上には存在しない）
一実施形態では、ブロックは、どのブロックも他のブロックの上にならないように、フレーム１８００の中に配置される。これは、どの２つのＯＲＴサービスをとっても、ターボパケット衝突が無いということを確実にする。

（ＯＲＴサービススロットアルゴリズム）
１つ以上の実施形態においては、以下のパラメータがＯＲＴサービススロット割り当てアルゴリズムの実施形態への入力を表す。

ａ．あるフレームに対してあるサービスのそれぞれのＭＬＣが有するデータのスロットの数。

ｂ．各ＭＬＣの送信モードにより決定される、あるサービスのＭＬＣそれぞれのmaxSlotHeight。

ｃ．ＯＲＴサービスのために利用可能なシンボルの総数（numAvailOrtsSymPerFrm）。

１つ以上の実施形態においては、以下のパラメータがＯＲＴサービススロット割り当てアルゴリズムからの出力を表す。

ａ．詰め込みが可能かどうかを示す決定。

ｂ．詰め込みが成功の場合、ＯＲＴサービスにより占有されるシンボルの数（numOccuOrtsSymPerFrm）
図１９は、多重化システムの中で用いる、ＯＲＴサービスにスロットを割り当てる方法１９００の一実施形態を示す。一実施形態の中では、ＭＵＸロジック２１０は、以下に説明するような方法１９００の機能を提供する働きをする。

ブロック１９０２で、各ＯＲＴサービスのmaxSlotHeightの計算が実行される。一実施形態では、ＭＵＸロジック２１０は、この計算を実行する。

ブロック１９０４で、ＯＲＴサービスは、それぞれのサービスのmaxSlotHeightパラメータに基づいて、各ブロックの中にグループ化される。例えば、一実施形態の中では、サービスは、threeBlkSrvcs、fourBlkSrvcs、sixBlkSrvcs、及びsevenBlkSrvcsの中にグループ化される。一実施形態では、ＭＵＸロジック２１０は、この動作を実行する。

ブロック１９０６では、長さ変数Ｌ７、Ｌ６、Ｌ４、及びＬ３が計算される。例えば、Ｌ７＝ｃｅｉｌ（全てのsevenBlkSrvcsの総スロット数／７）であり、ここで、ｃｅｉｌ（ｘ）はｘよりも大きい最小の整数である。一実施形態では、ＭＵＸロジック２１０は、この動作を実行する。

ブロック１９０８では、要求されたシンボルの数が、利用可能なシンボルの数よりも大きいかどうかを判断するためのテストが実行される。例えば、以下の不等式が評価される。

(L7+L6+L4+L3 <= numAvailOrtsSymbolsPerFrm)
一実施形態では、ＭＵＸロジック２１０は、この動作を実行する。上記の不等式が偽の場合には、方法はブロック１９１０に進む。上記の不等式が真の場合には、方法はブロック１９１２に進む。

ブロック１９１０では、詰め込み失敗が決定され、方法はブロック１９１４で終了する。

ブロック１９１２では、詰め込みは成功し、占有されるシンボルの数が以下の方程式から決定される。

numOccuOrtsSymPerFrm = L7+L6+L4+L3
一実施形態では、ＭＵＸロジック２１０は、この動作を実行する。一旦詰め込みが成功すると、各サービスが属するブロックは既知であるため、全てのＭＬＣ割り当てのロケーションに到達するのは容易である。

方法１９００は、ただ１つのインプリメンテーションのみを表し、方法１９００の変更、追加、削除、複合又は他の修正は、各実施形態の範囲の中で可能であるということに留意されたい。

（スロット割り当てアルゴリズム及びリサイズアルゴリズム間の相互作用）
これまでの章の中で、スロット割り当てアルゴリズム及びリサイズアルゴリズムの実施形態が説明されている。以下の章は、多重化システムの実施形態の中で用いるこれらのアルゴリズムの全般的な相互作用についての記述を提供する。

図２０は、多重化システムの中で用いる、スロット割り当て、リサイズ、及び輻輳制御を提供するための方法２０００の一実施形態を示す。例えば、サーバ２００は、以下に説明する機能を提供する働きをする。

ブロック２００２では、高プライオリティ及び中プライオリティのＯＲＴサービスが、スロット割り当てされる。例えば、スーパーフレームごとに、ＭＵＸ１１４は、さまざまなフローデータの量及びこれらの相対的プライオリティを、ＲＴＭＳ１２６及びＮＲＴＭＳ１２８などのコンテンツエンティティからGetDataSize.Response命令を用いて入手する。この情報を用いて、高プライオリティ及び中プライオリティのＯＲＴサービスに対するスロット割り当てが実行される。例えば、一実施形態の中では、ＭＵＸロジック２１０は、上記のアルゴリズムに従って高プライオリティ及び中プライオリティのＯＲＴサービスに対するスロット割り当てを実行する働きをする。

ブロック２００４では、高プライオリティ及び中プライオリティのＯＲＴサービスのスロット割り当てが成功かどうかを判断するテストが実行される。割り当てが成功だった場合には、方法はブロック２００６に進む。割り当てが成功でなかった場合には、方法はブロック２０１８に進む。

ブロック２０１８では、輻輳制御が実行される。高プライオリティ及び中プライオリティのＯＲＴサービスのスロット割り当てが成功でなかったことから、システムは対処の必要な輻輳に悩むことになる。一実施形態では、ＭＵＸロジック２１０は、図２２を参照して説明される輻輳制御アルゴリズムを実行する。輻輳制御から戻り次第、方法はブロック２０２８で停止する。

ブロック２００６では、ＯＲＴサービススロット割り当ての成功に基づいて、ＲＴサービスに対して利用可能なシンボルの数が計算され、反復パラメータが０にセットされる。例えば、一実施形態では、ＭＵＸロジック２１０は、これらの機能を実行する。

ブロック２００８で、ＲＴサービスのスロット割り当てが、フレーム内の残りのシンボルを使って実行される。例えば、上述のスロット割り当てアルゴリズムの実施形態は、ＲＴサービスにスロットを割り当てるために用いられる。

ブロック２０１０では、ＲＴサービスが成功裏に割り当てされたかどうかを判断するテストが実行される。割り当てが成功でなかった場合には、方法はブロック２０１４に進む。割り当てが成功だった場合には、方法はブロック２０１２に進む。

ブロック２０１２で、利用可能なシンボルの数が減じられ、反復パラメータが増加される。例えば、一実施形態では、ＭＵＸロジック２１０は、これらの機能を実行する。方法は次に、ＲＴサービスにスロットを割り当てするためにブロック２００８に進む。

ブロック２０１４では、反復パラメータがゼロより大きいかどうかを判断するテストが実行される。例えば、一実施形態では、ＭＵＸロジック２１０は、これらの機能を実行する。反復パラメータがゼロよりも大きい場合は、方法はブロック２０１６に進む。反復パラメータがゼロよりも大きくない場合は、方法はブロック２０２０に進む。

ブロック２０１６で、ＲＴサービススロット割り当てが、numRTSymbols＋１を用いて実行される。例えば、ＭＵＸロジック２１０は、増加されたnumRTSymbols値を用いて、ＲＴサービスに対してスロット割り当てを実行する。方法は次に、ブロック２０２４に進む。

ブロック２０２０で、選択されたＲＴサービスがリサイズされる。一実施形態の中では、ＲＴサービスのスロット割り当てが成功するように、１つ以上のフローのレートをリサイズするために、リサイズアルゴリズムが用いられる。例えば、リサイズ制御部２１２は、図２２を参照して説明されるリサイズアルゴリズムを実行する働きをする。リサイズアルゴリズムから戻り次第、方法はブロック２０２２に進む。

ブロック２０２２では、ＲＴサービスのリサイズが成功だったかどうかを判断するテストが実行される。例えば、リサイズアルゴリズムが、許容できる下限ビデオ品質又は下限リサイズ率を伴うスロット割り当てに失敗する事態がありうる。リサイズが成功だった場合には、方法はブロック２０２４に進む。リサイズが成功でなかった場合には、この状態は、システムが輻輳していることを意味し、従って、方法は輻輳制御を実行するためにブロック２０１８に進む。

ブロック２０２４で、低プライオリティのＯＲＴサービスが、ランクが増えていく順にスロット割り当てされる。例えば、ＭＵＸロジック２１０が、この機能を行う。

ブロック２０２６では、ベストエフォートＯＲＴサービス又はデータがスロット割り当てされる。例えば、ＭＵＸロジック２１０が、この機能を行う。方法２０００は次に、ブロック２０２８で停止する。

従って、方法２０００の完了時、ＭＵＸ１１４はスーパーフレームで送ることができるさまざまなフローの、正確なデータサイズについての情報を有する。この情報は、ＲＴＭＳ１２６及びＯＲＴＭＳ１２８に、UpdateDataSize.Notificationメッセージを用いて送り戻される。

方法２０００は、ただ１つのインプリメンテーションのみを表し、方法２０００の変更、追加、削除、複合又は他の修正は、各実施形態の範囲の中で可能であるということに留意されたい。

図２１は、多重化システムの中で用いる、リサイズを提供するための方法２１００の一実施形態を示す。例えば、方法２１００は、図２０の中のブロック２０２０として用いるのに適している。一実施形態の中では、リサイズ制御部２１２は、以下に説明する機能を提供する働きをする。

ブロック２１０２では、要求されたスロットの数が評価され、パラメータｎが計算される。一実施形態では、ｎは、あるサービスのために要求されたスロットの数と、利用可能なスロットの数との比率を表す。例えば、リサイズ制御部２１２は、この計算を行う。

ブロック２１０４で、リサイズされるべきフローの品質が評価される。例えば、各フローに対するＭＬＣをｎコードブロックだけ削減した後に、品質評価がなされる。例えば、あるサービスの品質（Ｑ）は、サービスフローに割り当てられたビットレート（ｒ）の関数であり、またこれは上記で表される品質関数によりモデル化される。例えば、リサイズ制御部２１２は、この品質判定を行う。

ブロック２１０６では、結果としての最大品質を伴うフローが決定される（候補）。例えば、リサイズ制御部２１２は、ブロック２１０４において、コードブロックの削減を実行した後に結果として生じるであろう最大品質を伴うフローを決定する。

ブロック２１０８で、最大品質がシステムの最小品質要求よりも大きいかどうかを判断するためのテストが実行される。例えば、リサイズ制御部２１２は、このテストの結果を判断する。最大品質が、システムの最小品質要求よりも大きくない場合は、方法はブロック２１１６に進む。最大品質が、システムの最小品質要求よりも大きい場合は、方法はブロック２１１０に進む。

ブロック２１１０では、最大品質を有するフローがリサイズされ、スロット割り当てが実行される。例えば、最大品質を有するフローがｎコードブロックだけ削減され、スロット割り当てが実行される。例えば、リサイズ制御部２１２はフローをリサイズし、ＭＵＸロジック２１０にスロット割り当てを実行するよう要求する。

ブロック２１１２では、スロット割り当てが成功だったかどうかを判断するテストが実行される。例えば、リサイズ制御部２１２は、ブロック２１１０で実行されたスロット割り当てが成功だったかどうかを示す指標を、ＭＵＸロジック２１０から受信する。スロット割り当てが成功だった場合には、方法はブロック２１１４に進む。スロット割り当てが成功でなかった場合には、方法はブロック２１０２に進む。

ブロック２１１４において、リサイズは成功と判断され、ブロック２１１６において、リサイズは失敗と判断される。例えば、リサイズ制御部２１２は、これらの判断を行う。方法は次に、ブロック２１１８に進み、ここで方法は図２０のブロック２０２０に戻る。

このようにして、方法２１００は、多重化システムの中で用いるリサイズを提供する働きをする。方法２１００は、ただ１つのインプリメンテーションのみを表し、方法２１００の変更、追加、削除、複合又は他の修正は、各実施形態の範囲の中で可能であるということに留意されたい。

図２２は、多重化システムの中で用いる、輻輳制御を提供するための方法２２００の一実施形態を示す。例えば、方法２２００は、図２０の中のブロック２０１８として用いるのに適している。一実施形態の中では、ＭＵＸロジック２１０は、以下に説明する機能を提供する働きをする。

ブロック２２０２では、高プライオリティＯＲＴサービスが、スロット割り当てされる。例えば、ＭＵＸ２１０は、本明細書の中で説明される割り当てアルゴリズムの実施形態に従って、この割り当てを実行する。

ブロック２２０４では、ブロック２２０２で実行された割り当てが成功だったかどうかを判断するテストが実行される。例えば、ＭＵＸ２１０は、この機能を行う。割り当てが成功だった場合には、方法はブロック２２０８に進む。割り当てが成功でなかった場合には、方法はブロック２２０６に進む。

ブロック２２０６で、高プライオリティのＯＲＴサービスが、これらのランクが増えていく順に割り当てられる。例えば、ＭＵＸ２１０は、本明細書の中で説明される割り当てアルゴリズムの実施形態に従って、この割り当てを実行する。方法２２００は次に、ブロック２２１８で停止する。

ブロック２２０８では、全ての可能なＲＴサービスフローが、選択される量だけ削減され、これらのフローのスロット割り当てが実行される。例えば、リサイズ制御部２１２及びＭＵＸ２１０は、本明細書の中で説明される実施形態に従って、これらの動作を実行する。選択される量は、このシステムにおいて既知のレート削減パラメータに基づいている。

ブロック２２１０では、ブロック２２０８で実行されたＲＴサービススロット割り当てが成功だったかどうかを判断するテストが実行される。例えば、ＭＵＸ２１０が、この機能を行う。割り当てが成功だった場合には、方法はブロック２１１２に進む。割り当てが成功でなかった場合には、方法はブロック２２１４に進む。

ブロック２２１２で、中プライオリティのＯＲＴサービスが、ランクが増えていく順にスロット割り当てされる。例えば、ＭＵＸ２１０は、本明細書の中で説明される割り当てアルゴリズムの実施形態に従って、この割り当てを実行する。方法２２００は次に、ブロック２２１８で停止する。

ブロック２２１４で、次に低いランクのサービスを排除するＲＴサービススロット割り当てが実行される。例えば、ＭＵＸ２１０は、本明細書の中で説明される割り当てアルゴリズムの実施形態に従って、この割り当てを実行する。

ブロック２２１６では、ブロック２２１４での割り当てが成功だったかどうかを判断するテストが実行される。例えば、ＭＵＸ２１０は、この機能を行う。割り当てが成功だった場合には、方法はブロック２２１２に進む。割り当てが成功でなかった場合には、方法はブロック２２１４に戻ってもう１つのサービスを排除し、再度スロット割り当てを試みる。

このようにして、方法２２００は、多重化システムの中で用いる輻輳制御を提供する働きをする。方法２２００は、ただ１つのインプリメンテーションのみを表し、方法２２００の変更、追加、削除、複合又は他の修正は、各実施形態の範囲の中で可能であるということに留意されたい。

図２３は、多重化システム２３００の一実施形態を示す。多重化システム２３００は、データを受信する手段（２３０２）と、帯域幅を決定する手段（２３０４）と、データを割り当てする手段（２３０６）と、データをリサイズする手段（２３０８）とを備えている。一実施形態の中では、手段（２３０２〜２３０８）は、コンピュータプログラムを実行する少なくとも１つのプロセッサにより提供されて、本明細書の中で説明されたような多重化システムの実施形態を提供する。

従って、本明細書の中で開示された実施形態に関連して説明された、例示的なさまざまなロジック、ロジッカルブロック、モジュール、及び回路は、汎用プロセッサ、デジタルシグナルプロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）若しくは他のプログラマブルロジックデバイス、個別ゲート若しくはトランジスタロジック、個別ハードウェアコンポーネント、又は、本明細書の中で説明された機能を実行するために設計されたこれらの任意の組み合わせを伴って、実装又は実行されてもよい。汎用プロセッサは、マイクロコンピュータでもよいし、代替的に、プロセッサは任意の従来のプロセッサ、コントローラ、マイクロコントローラ、又は状態機械であってもよい。プロセッサは同様に、例えば、ＤＳＰとマイクロプロセッサ、複数のマイクロプロセッサ、ＤＳＰコアに連動する１つ以上のマイクロプロセッサ、又は他のこのような構成の組み合わせのような、計算デバイスの組み合わせとして提供されてもよい。

本明細書の中で開示される実施形態に関連して説明される方法又はアルゴリズムのステップは、ハードウェア、プロセッサにより実行されるソフトウェアモジュール、又は双方の組み合わせの中に、直接組み込まれてもよい。ソフトウェアモジュールは、ＲＡＭメモリ、フラッシュメモリ、ＲＯＭメモリ、ＥＰＲＯＭメモリ、ＥＥＰＲＯＭメモリ、レジスタ、ハードディスク、リムーバブルディスク、ＣＤ−ＲＯＭ、又は当技術分野において既知である任意の他の形式の記録媒体の中に駐在してもよい。典型的な記憶媒体は、プロセッサが記録媒体から情報を読み取ったり、記録媒体に情報を書き込んだりすることができるように、プロセッサに接続される。別の方法では、記録媒体は、このプロセッサに不可欠としてもよい。プロセッサ及び記録媒体は、ＡＳＩＣの中にあってもよい。ＡＳＩＣは、ユーザ端末の中にあってもよい。別の方法では、プロセッサ及び記録媒体は、ユーザ端末の中に個別コンポーネントとしてあってもよい。

開示された実施形態の説明は、あらゆる当業者が、本発明を行うか又は用いることを可能とするために提供される。これらの実施形態へのさまざまな修正が、当業者には直ちに明白であろうし、本明細書において定義された一般的な原理は、本発明の精神又は範囲から逸脱することなく、例えばインスタントメッセージサービス若しくは任意の一般的な無線データ通信アプリケーションなどの、他の実施形態に適用することができる。従って、本発明は、本明細書において示された実施形態に限定されるものではなく、本明細書において開示された原理及び新規の特徴と一致する最も広い範囲と合致することを意図されている。「典型的な（ｅｘｅｍｐｌａｒｙ）」という言葉は、本明細書において、「例（ｅｘａｍｐｌｅ）、事例（ｉｎｓｔａｎｃｅ）、又は例証（ｉｌｌｕｓｔｒａｔｉｏｎ）の役目をする」ことを意味するものとしてもっぱら用いられる。本明細書において「典型的な」と記述された如何なる実施形態も、必ずしも、他の実施形態全体にわたって好ましい又は好都合であるとは解釈されるべきではない。

従って、多重化システムの実施形態が本明細書において図解され説明されたが、これらの精神又は本質的な特徴から逸脱することなく、多様な変更をこれらの実施形態に対して行うことができるということが理解されよう。それ故に、本明細書の開示及び説明は、以下の特許請求の範囲の中で説明される本発明の範囲の説明に役立つものであり、しかしながら限定するものではないということが意図されている。

多重化システムの一実施形態を備える、ネットワークを示す。 多重化システムの中で用いるサーバの一実施形態を示す。 多重化システムの中で用いられるＭＬＣのスロット割り当てを説明する、フレームの一実施形態を示す。 多重化システムの中で用いるさまざまなＭＬＣの割り当ての形状を備える、フレームの一実施形態を示す。 選択されたＭＬＣ割り当てに対する、送信モードパラメータと最大スロット高さ値との間の関係を説明する、表を示す。 多重化システムの中で用いる異なるＭＬＣスロット割り当てを説明する、フレームの一実施形態を示す。 多重化システムの中で用いる割り当てアルゴリズムの一実施形態を提供する方法を示す。 多重化システムの中で用いる、第１の不等条件に基づいて、ＲＴサービスにスロットを割り当てる方法の一実施形態を示す。 多重化システムの中で用いる、第２の不等条件に基づいて、ＲＴサービスにスロットを割り当てる方法の一実施形態を示す。 過剰な４ブロックサービスを割り当てする、多重化システムの実施形態の動作を図解する、フレームを示す。 多重化システムの中で用いる、第３の不等条件に基づいて、ＲＴサービスにスロットを割り当てる方法の一実施形態を示す。 過剰な３ブロックサービスを割り当てする、多重化システムの実施形態の動作を図解する、フレームを示す。 多重化システムの中で用いる、第４の不等条件に基づいて、ＲＴサービスにスロットを割り当てる方法の一実施形態を示す。 過剰な６ブロックサービスを割り当てする、多重化システムの実施形態の動作を図解する、フレームを示す。 多重化システムの中で用いられる、２つのＲＴサービスを１つの送信フレームの中に詰め込むための割り当てアルゴリズムの実施形態の動作を説明する、フレームを示す。 ＲＴサービスを、使用されないスロットが２つの領域にグループ化されるような方法で詰め込む、割り当てアルゴリズムの実施形態の動作を説明する、フレームを示す。 多重化システムの中で用いる、ＲＴサービスとＯＲＴサービスの領域に分割されたフレームの実施形態を示す。 ＯＲＴサービス領域が異なる高さのブロックに分割される、フレームの一実施形態を示す。 多重化システムの中で用いる、ＯＲＴサービスにスロットを割り当てするための方法の一実施形態を示す。 多重化システムの中で用いる、スロット割り当て、リサイズ、及び輻輳制御を提供するための方法の一実施形態を示す。 多重化システムの中で用いる、リアルタイムサービスのリサイズを提供するための方法の一実施形態を示す。 多重化システムの中で用いる、輻輳制御を提供するための方法の一実施形態を示す。 多重化システムの一実施形態を示す。

Claims (45)

1. ネットワークを通してサービスを送信する方法であって、前記方法は、
   関連する配信要求を有する１つ以上のサービスを受信することと、
   ネットワーク帯域幅が前記配信要求を満たすことが可能であるということを判断することと、
   ネットワーク帯域幅割り当てを生成するために、前記ネットワーク帯域幅を、前記配信要求に基づいて前記１つ以上のサービスに割り当てることとを含み、
   ここで、前記割り当てることは、
   前記１つ以上のサービスに関連する高さパラメータを決定することと、なお前記高さパラメータはフレームのスロットに関連し、
   前記高さパラメータに基づいて、前記１つ以上のサービスを１つ以上のグループにグループ化することと、
   前記１つ以上のグループに対して、長さパラメータを決定することと、なお前記長さパラメータは前記フレームのデータシンボルに関連し、
   前記長さパラメータに基づいて、前記１つ以上のグループに前記ネットワーク帯域幅を割り当てすることと、を含む、
   方法。
2. 前記受信することは、前記関連する配信要求を有する前記１つ以上のサービスを受信することを含み、前記関連する配信要求は、帯域幅要求、レーテンシ要求、及びプライオリティ要求の１つ以上を含む、請求項１に記載の方法。
3. 前記割り当てすることは、
   前記ネットワーク帯域幅を、第１の部分及び第２の部分に分割することと、
   前記第１の部分及び前記第２の部分を前記１つ以上のサービスに割り当てすることとを含み、前記第１の部分はリアルタイムサービスに割り当てされ、前記第２の部分はリアルタイムサービス以外に割り当てされる、請求項１に記載の方法。
4. 前記１つ以上のサービスを、前記ネットワーク帯域幅割り当てを用いてＯＦＤＭネットワークを通して送信することを更に含む、請求項１に記載の方法。
5. ネットワークを通してサービスを送信する装置であって、前記装置は、
   関連する配信要求を有する１つ以上のサービスを受信するように構成されている、受信ロジックと、
   ネットワーク帯域幅が、前記配信要求を満足することが可能であるということとを判断し、前記ネットワーク帯域幅を前記１つ以上のサービスに前記配信要求に基づいて割り当てして、ネットワーク帯域幅割り当てを生成するように構成された、多重化ロジックとを備え、
   ここで前記多重化ロジックは、
   前記１つ以上のサービスに関連する高さパラメータを決定するように構成されたロジックと、なお前記高さパラメータはフレームのスロットに関連し、
   前記高さパラメータに基づいて、前記１つ以上のサービスを１つ以上のグループにグループ化するように構成されたロジックと、
   前記１つ以上のグループに対して、長さパラメータを決定するように構成されたロジックと、なお前記長さパラメータは前記フレームのデータシンボルに関連し、
   前記長さパラメータに基づいて、前記１つ以上のグループに前記ネットワーク帯域幅を割り当てするように構成されたロジックと、を備える、
   装置。
6. 前記関連する配信要求は、帯域幅要求、レーテンシ要求、及びプライオリティ要求の１つ以上を備える、請求項５に記載の装置。
7. 前記多重化ロジックは、
   前記ネットワーク帯域幅を、第１の部分及び第２の部分に分割するように構成されたロジックと、
   前記第１の部分及び第２の部分を前記１つ以上のサービスに割り当てるように構成されたロジックを備え、前記第１の部分はリアルタイムサービスに割り当てされ、前記第２の部分はリアルタイムサービス以外に割り当てされる、請求項５に記載の装置。
8. 前記１つ以上のサービスを、前記ネットワーク帯域幅割り当てを用いてＯＦＤＭネットワークを通して送信するように構成された送信ロジックを更に備える、請求項５に記載の装置。
9. ネットワークを通してサービスを送信する装置であって、前記装置は、
   関連する配信要求を有する１つ以上のサービスを受信する手段と、
   ネットワーク帯域幅が前記配信要求を満たすことが可能であるということを判断する手段と、
   前記ネットワーク帯域幅を、前記配信要求に基づいて前記１つ以上のサービスに割り当てして、ネットワーク帯域幅割り当てを生成する手段と、
   を備え
   ここで前記割り当てする手段は、
   前記１つ以上のサービスに関連する高さパラメータを決定する手段と、なお前記高さパラメータはフレームのスロットに関連し、
   前記高さパラメータに基づいて、前記１つ以上のサービスを１つ以上のグループにグループ化する手段と、
   前記１つ以上のグループに対して、長さパラメータを決定する手段と、なお前記長さパラメータは前記フレームのデータシンボルに関連し、
   前記長さパラメータに基づいて、前記１つ以上のグループに前記ネットワーク帯域幅を割り当てする手段と、を備える、
   装置。
10. 前記受信する手段は、前記関連する配信要求を有する前記１つ以上のサービスを受信する手段を備え、前記関連する配信要求は、帯域幅要求、レーテンシ要求、及びプライオリティ要求の１つ以上を備える、請求項９に記載の装置。
11. 前記割り当てする手段は、
    前記ネットワーク帯域幅を、第１の部分及び第２の部分に分割する手段と、
    前記第１の部分及び前記第２の部分を前記１つ以上のサービスに割り当てする手段とを備え、前記第１の部分はリアルタイムサービスに割り当てされ、前記第２の部分はリアルタイムサービス以外に割り当てされる、請求項９に記載の装置。
12. 前記１つ以上のサービスを、前記ネットワーク帯域幅割り当てを用いてＯＦＤＭネットワークを通して送信する手段を更に備える、請求項９に記載の装置。
13. 命令を備えるコンピュータプログラムを有するコンピュータで読み取り可能な媒体であって、前記命令は、少なくとも１つのプロセッサにより実行される時、ネットワークを通してサービスを送信する働きをし、前記コンピュータプログラムは、
    関連する配信要求を有する１つ以上のサービスを受信する命令と、
    ネットワーク帯域幅が前記配信要求を満たすことが可能であるということを判断する命令と、
    前記ネットワーク帯域幅を、前記配信要求に基づいて前記１つ以上のサービスに割り当てして、ネットワーク帯域幅割り当てを生成する命令と、
    を備え、
    ここで前記割り当てする命令は、
    前記１つ以上のサービスに関連する高さパラメータを決定する命令と、なお前記高さパラメータはフレームのスロットに関連し、
    前記高さパラメータに基づいて、前記１つ以上のサービスを１つ以上のグループにグループ化する命令と、
    前記１つ以上のグループに対して、長さパラメータを決定する命令と、なお前記長さパラメータは前記フレームのデータシンボルに関連し、
    前記長さパラメータに基づいて、前記１つ以上のグループに前記ネットワーク帯域幅を割り当てする命令と、を備える、
    コンピュータで読み取り可能な媒体。
14. 前記受信する命令は、前記関連する配信要求を有する前記１つ以上のサービスを受信する命令を備え、前記関連する配信要求は、帯域幅要求、レーテンシ要求、及びプライオリティ要求の１つ以上を備える、請求項１３に記載のコンピュータで読み取り可能な媒体。
15. 前記割り当てする命令は、
    前記ネットワーク帯域幅を、第１の部分及び第２の部分に分割する命令と、
    前記第１の部分及び前記第２の部分を前記１つ以上のサービスに割り当てする命令とを備え、前記第１の部分はリアルタイムサービスに割り当てされ、前記第２の部分はリアルタイムサービス以外に割り当てされる、請求項１３に記載のコンピュータで読み取り可能な媒体。
16. 前記１つ以上のサービスを、前記ネットワーク帯域幅割り当てを用いてＯＦＤＭネットワークを通して送信する命令を更に備える、請求項１３に記載のコンピュータで読み取り可能な媒体。
17. ネットワークを通してサービスを送信する方法を実行するように構成された少なくとも１つのプロセッサであって、前記方法は、
    関連する配信要求を有する１つ以上のサービスを受信することと、
    ネットワーク帯域幅が前記配信要求を満たすことが可能であるということを判断することと、
    前記ネットワーク帯域幅を、前記配信要求に基づいて前記１つ以上のサービスに割り当てして、ネットワーク帯域幅割り当てを生成することと、
    を含み、
    ここで前記割り当てすることは、
    前記１つ以上のサービスに関連する高さパラメータを決定することと、なお前記高さパラメータはフレームのスロットに関連し、
    前記高さパラメータに基づいて、前記１つ以上のサービスを１つ以上のグループにグループ化することと、
    前記１つ以上のグループに対して、長さパラメータを決定することと、なお前記長さパラメータは前記フレームのデータシンボルに関連し、
    前記長さパラメータに基づいて、前記１つ以上のグループに前記ネットワーク帯域幅を割り当てすることと、を含む、
    プロセッサ。
18. 前記受信することは、前記関連する配信要求を有する前記１つ以上のサービスを受信することを含み、前記関連する配信要求は、帯域幅要求、レーテンシ要求、及びプライオリティ要求の１つ以上を備える、請求項１７に記載のプロセッサ。
19. 前記割り当てすることは、
    前記ネットワーク帯域幅を、第１の部分及び第２の部分に分割することと、
    前記第１の部分及び前記第２の部分を前記１つ以上のサービスに割り当てすることとを含み、前記第１の部分はリアルタイムサービスに割り当てされ、前記第２の部分はリアルタイムサービス以外に割り当てされる、請求項１７に記載のプロセッサ。
20. 前記１つ以上のサービスを、前記ネットワーク帯域幅割り当てを用いてＯＦＤＭネットワークを通して送信することを更に備える、請求項１７に記載のプロセッサ。
21. ネットワークを通してサービスを送信する方法であって、前記方法は、
    関連する配信要求を有する１つ以上のサービスを受信することと、
    利用可能なネットワーク帯域幅が前記配信要求を満たすことができないということを判断することと、
    前記１つ以上のサービスの少なくとも１つをリサイズし、調整された配信要求を生成することと、
    ネットワーク帯域幅割り当てを生成するために、前記利用可能なネットワーク帯域幅を、前記調整された配信要求に基づいて、前記１つ以上のサービスに割当てることと
    を含み、
    ここで前記割り当てることは、
    前記調整された配信要求に基づいて、前記１つ以上のサービスに関連する高さパラメータを決定することと、なお前記高さパラメータはフレームのスロットに関連し、
    前記高さパラメータに基づいて、前記１つ以上のサービスを１つ以上のグループにグループ化することと、
    前記１つ以上のグループに対して、長さパラメータを決定することと、なお前記長さパラメータは前記フレームのデータシンボルに関連し、
    前記長さパラメータに基づいて、前記１つ以上のグループに前記利用可能なネットワーク帯域幅を割り当てすることと、を含む、
    方法。
22. 前記受信することは、前記関連する配信要求を有する前記１つ以上のサービスを受信することを含み、前記関連する配信要求は、帯域幅要求、レーテンシ要求、及びプライオリティ要求の１つ以上を備える、請求項２１に記載の方法。
23. 前記リサイズすることは、前記１つ以上のサービスの少なくとも１つの帯域幅要求を削減することを含む、請求項２１に記載の方法。
24. 前記割り当てすることは、
    前記利用可能なネットワーク帯域幅を、第１の部分及び第２の部分に分割することと、
    前記第１の部分及び前記第２の部分を前記１つ以上のサービスに割り当てすることとを含み、前記第１の部分はリアルタイムサービスに割り当てされ、前記第２の部分はリアルタイムサービス以外に割り当てされる、請求項２１に記載の方法。
25. 前記１つ以上のサービスを、前記ネットワーク帯域幅割り当てを用いてＯＦＤＭネットワークを通して送信することを更に含む、請求項２１に記載の方法。
26. ネットワークを通してサービスを送信する装置であって、前記装置は、
    関連する配信要求を有する１つ以上のサービスを受信するように構成されている、受信ロジックと、
    前記１つ以上のサービスの少なくとも１つをリサイズし、調整された配信要求を生成するように構成されたリサイズ制御部と、
    利用可能なネットワーク帯域幅が、前記配信要求を満足させることができないということとを判断し、前記利用可能なネットワーク帯域幅を前記１つ以上のサービスに前記調整された配信要求に基づいて割り当てして、ネットワーク帯域幅割り当てを生成するように構成された、多重化ロジックと、
    を備え、
    ここで前記多重化ロジックは、
    前記調整された配信要求に基づいて、前記１つ以上のサービスに関連する高さパラメータを決定するように構成されたロジックと、なお前記高さパラメータはフレームのスロットに関連し、
    前記高さパラメータに基づいて、前記１つ以上のサービスを１つ以上のグループにグループ化するように構成されたロジックと、
    前記１つ以上のグループに対して、長さパラメータを決定するように構成されたロジックと、なお前記長さパラメータは前記フレームのデータシンボルに関連し、
    前記長さパラメータに基づいて、前記１つ以上のグループに前記利用可能なネットワーク帯域幅を割り当てするように構成されたロジックと、を備える、
    装置。
27. 前記関連する配信要求は、帯域幅要求、レーテンシ要求、及びプライオリティ要求の１つ以上を備える、請求項２６に記載の装置。
28. 前記リサイズ制御部は、前記１つ以上のサービスの少なくとも１つの帯域幅要求を削減して前記調整された配信要求を生成するように構成されたロジックを備える、請求項２６に記載の装置。
29. 前記多重化ロジックは、
    前記利用可能なネットワーク帯域幅を、第１の部分及び第２の部分に分割するように構成されたロジックと、
    前記第１の部分及び前記第２の部分を前記１つ以上のサービスに割り当てするように構成されたロジックとを備え、前記第１の部分はリアルタイムサービスに割り当てされ、前記第２の部分はリアルタイムサービス以外に割り当てされる、請求項２６に記載の装置。
30. 前記１つ以上のサービスを、前記ネットワーク帯域幅割り当てを用いてＯＦＤＭネットワークを通して送信するように構成された送信ロジックを更に備える、請求項２６に記載の装置。
31. ネットワークを通してサービスを送信する装置であって、前記装置は、
    関連する配信要求を有する１つ以上のサービスを受信する手段と、
    利用可能なネットワーク帯域幅が前記配信要求を満たすことができないということを判断する手段と、
    前記１つ以上のサービスの少なくとも１つをリサイズし、調整された配信要求を生成する手段と、
    前記利用可能なネットワーク帯域幅を、前記調整された配信要求に基づいて前記１つ以上のサービスに割り当てして、ネットワーク帯域幅割り当てを生成する手段と、を備え
    ここで前記割り当てする手段は、
    前記調整された配信要求に基づいて、前記１つ以上のサービスに関連する高さパラメータを決定する手段と、なお前記高さパラメータはフレームのスロットに関連し、
    前記高さパラメータに基づいて、前記１つ以上のサービスを１つ以上のグループにグループ化する手段と、
    前記１つ以上のグループに対して、長さパラメータを決定する手段と、なお前記長さパラメータは前記フレームのデータシンボルに関連し、
    前記長さパラメータに基づいて、前記１つ以上のグループに前記利用可能なネットワーク帯域幅を割り当てする手段と、
    を備える、
    装置。
32. 前記受信する手段は、前記関連する配信要求を有する前記１つ以上のサービスを受信する手段を備え、前記関連する配信要求は、帯域幅要求、レーテンシ要求、及びプライオリティ要求の１つ以上を備える、請求項３１に記載の装置。
33. 前記リサイズする手段は、前記１つ以上のサービスのうち少なくとも１つの帯域幅要求を削減する手段を備える、請求項３１に記載の装置。
34. 前記割り当てする手段は、
    前記利用可能なネットワーク帯域幅を、第１の部分及び第２の部分に分割する手段と、
    前記第１の部分及び前記第２の部分を前記１つ以上のサービスに割り当てする手段とを備え、前記第１の部分はリアルタイムサービスに割り当てされ、前記第２の部分はリアルタイムサービス以外に割り当てされる、請求項３１に記載の装置。
35. 前記１つ以上のサービスを、前記ネットワーク帯域幅割り当てを用いてＯＦＤＭネットワークを通して送信する手段を更に備える、請求項３１に記載の装置。
36. 命令を備えるコンピュータプログラムを有するコンピュータで読み取り可能な媒体であって、前記命令は、少なくとも１つのプロセッサにより実行される時、ネットワークを通してサービスを送信する働きをし、前記コンピュータプログラムは、
    関連する配信要求を有する１つ以上のサービスを受信する命令と、
    利用可能なネットワーク帯域幅が前記配信要求を満たすことができないということを判断する命令と、
    前記１つ以上のサービスの少なくとも１つをリサイズし、調整された配信要求を生成する命令と、
    前記利用可能なネットワーク帯域幅を、前記調整された配信要求に基づいて前記１つ以上のサービスに割り当てして、ネットワーク帯域幅割り当てを生成する命令と、
    を備え、
    ここで前記割り当てする命令は、
    前記調整された配信要求に基づいて、前記１つ以上のサービスに関連する高さパラメータを決定する命令と、なお前記高さパラメータはフレームのスロットに関連し、
    前記高さパラメータに基づいて、前記１つ以上のサービスを１つ以上のグループにグループ化する命令と、
    前記１つ以上のグループに対して、長さパラメータを決定する命令と、なお前記長さパラメータは前記フレームのデータシンボルに関連し、
    前記長さパラメータに基づいて、前記１つ以上のグループに前記利用可能なネットワーク帯域幅を割り当てする命令と、を備える、
    コンピュータで読み取り可能な媒体。
37. 前記受信する命令は、前記関連する配信要求を有する前記１つ以上のサービスを受信する命令を備え、前記関連する配信要求は、帯域幅要求、レーテンシ要求、及びプライオリティ要求の１つ以上を備える、請求項３６に記載のコンピュータで読み取り可能な媒体。
38. 前記リサイズする命令は、前記１つ以上のサービスのうち少なくとも１つの帯域幅要求を削減する命令を備える、請求項３６に記載のコンピュータで読み取り可能な媒体。
39. 前記割り当てする命令は、
    前記利用可能なネットワーク帯域幅を、第１の部分及び第２の部分に分割する命令と、
    前記第１の部分及び前記第２の部分を前記１つ以上のサービスに割り当てする命令とを備え、前記第１の部分はリアルタイムサービスに割り当てされ、前記第２の部分はリアルタイムサービス以外に割り当てされる、請求項３６に記載のコンピュータで読み取り可能な媒体。
40. 前記１つ以上のサービスを、前記ネットワーク帯域幅割り当てを用いてＯＦＤＭネットワークを通して送信する命令を更に備える、請求項３６に記載のコンピュータで読み取り可能な媒体。
41. ネットワークを通してサービスを送信する方法を実行するように構成された少なくとも１つのプロセッサであって、前記方法は、
    関連する配信要求を有する１つ以上のサービスを受信することと、
    利用可能なネットワーク帯域幅が前記配信要求を満たすことができないということを判断することと、
    前記１つ以上のサービスの少なくとも１つをリサイズし、調整された配信要求を生成することと、
    前記利用可能なネットワーク帯域幅を、前記調整された配信要求に基づいて前記１つ以上のサービスに割り当てして、ネットワーク帯域幅割り当てを生成することとを含み、
    ここで前記割り当てすることは、
    前記調整された配信要求に基づいて、前記１つ以上のサービスに関連する高さパラメータを決定することと、なお前記高さパラメータはフレームのスロットに関連し、
    前記高さパラメータに基づいて、前記１つ以上のサービスを１つ以上のグループにグループ化することと、
    前記１つ以上のグループに対して、長さパラメータを決定することと、なお前記長さパラメータは前記フレームのデータシンボルに関連し、
    前記長さパラメータに基づいて、前記１つ以上のグループに前記利用可能なネットワーク帯域幅を割り当てすることと、を含む、
    プロセッサ。
42. 前記受信することは、前記関連する配信要求を有する前記１つ以上のサービスを受信することを備え、前記関連する配信要求は、帯域幅要求、レーテンシ要求、及びプライオリティ要求の１つ以上を含む、請求項４１に記載のプロセッサ。
43. 前記リサイズすることは、前記１つ以上のサービスの少なくとも１つの帯域幅要求を削減することを含む、請求項４１に記載のプロセッサ。
44. 前記割り当てすることは、
    前記利用可能なネットワーク帯域幅を、第１の部分及び第２の部分に分割することと、
    前記第１の部分及び前記第２の部分を前記１つ以上のサービスに割り当てすることとを含み、前記第１の部分はリアルタイムサービスに割り当てされ、前記第２の部分はリアルタイムサービス以外に割り当てされる、請求項４１に記載のプロセッサ。
45. 前記１つ以上のサービスを、前記ネットワーク帯域幅割り当てを用いてＯＦＤＭネットワークを通して送信することを更に含む、請求項４１に記載のプロセッサ。

Images