特許 7140881 ビデオストリーミングに対する電力認識適応

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2022-09-12

(45)【発行日】2022-09-21

(54)【発明の名称】ビデオストリーミングに対する電力認識適応

(51)【国際特許分類】

   H04N 21/438 20110101AFI20220913BHJP

   G06F 13/00 20060101ALI20220913BHJP

【ＦＩ】

H04N21/438

G06F13/00

【請求項の数】 20

(21)【出願番号】P 2021086819

(22)【出願日】2021-05-24

(62)【分割の表示】P 2019159271の分割

【原出願日】2014-03-06

(65)【公開番号】P2021132402

(43)【公開日】2021-09-09

【審査請求日】2021-05-24

(31)【優先権主張番号】61/773,379

(32)【優先日】2013-03-06

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】61/936,828

(32)【優先日】2014-02-06

(33)【優先権主張国・地域又は機関】US

(73)【特許権者】

【識別番号】510030995

【氏名又は名称】インターデイジタル パテント ホールディングス インコーポレイテッド

(74)【代理人】

【識別番号】110001243

【氏名又は名称】弁理士法人谷・阿部特許事務所

(72)【発明者】

【氏名】ホー ユーウェン

(72)【発明者】

【氏名】マルクス クンストナー

(72)【発明者】

【氏名】イエ イエン

(72)【発明者】

【氏名】ラルフ ネフ

【審査官】大西 宏

(56)【参考文献】

【文献】特開２００４－２４２３０８（ＪＰ，Ａ）

【文献】米国特許出願公開第２０１２／０１４１０８９（ＵＳ，Ａ１）

【文献】米国特許出願公開第２０１３／０２８７０９５（ＵＳ，Ａ１）

【文献】国際公開第２０１１／０８４９１３（ＷＯ，Ａ２）

【文献】中国特許出願公開第１５２２０７４（ＣＮ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｈ０４Ｎ ７／１０

Ｈ０４Ｎ ７／１４ － ７／１７３

Ｈ０４Ｎ ７／２０ － ７／５６

Ｈ０４Ｎ ２１／００ －２１／８５８

Ｇ０６Ｆ １３／００

Ｈ０４Ｎ ７／１２

Ｈ０４Ｎ １９／００ －１９／９８

(57)【特許請求の範囲】

【請求項1】

無線送信／受信ユニット（ＷＴＲＵ）であって、
メモリと、
マルチメディアコンテンツのための複数のリプレゼンテーションを識別するメディアプレゼンテーションディスクリプション（ＭＰＤ）ファイルを受信し、
前記複数のリプレゼンテーションに対する複雑度情報を示す少なくとも１つのメタデータファイルを受信し、前記少なくとも１つのメタデータファイルは、ＭＰＤファイルとは異なるファイルであり、
前記少なくとも１つのメタデータファイルの中の前記複数のリプレゼンテーションに対する前記複雑度情報に基づいて第１のビデオセグメントをダウンロードするための第１のリプレゼンテーションを決定し、
前記第１のリプレゼンテーションの前記第１のビデオセグメントを要求し、
前記第１のリプレゼンテーションの前記第１のビデオセグメントを受信し、
前記第１のビデオセグメントを復号する
ように構成されたプロセッサと
を備えた、ＷＴＲＵ。

【請求項2】

前記プロセッサは、複数のメタデータファイルを受信するように構成され、前記複数のメタデータファイルは、前記複数のリプレゼンテーションに対する前記複雑度情報を示す、請求項１のＷＴＲＵ。

【請求項3】

前記第１のリプレゼンテーションの決定は、前記第１のリプレゼンテーションの第１の複雑度情報に基づいており、
前記プロセッサは、
前記第１のリプレゼンテーションの第１の複雑度情報および前記第１のリプレゼンテーションの電力消費に基づいて第２のビデオセグメントの第２のリプレゼンテーションを選択するための第２の複雑度情報を決定し、
前記第２の複雑度情報に基づいて前記第２のビデオセグメントを要求するための前記第２のリプレゼンテーションを決定し、
前記第２のリプレゼンテーションの前記第２のビデオセグメントを要求し、
前記第２のリプレゼンテーションの前記第２のビデオセグメントを受信し、
前記第２のビデオセグメントを復号する
ように構成される、請求項１のＷＴＲＵ。

【請求項4】

前記プロセッサは、前記第１のリプレゼンテーションの前記第１のビデオセグメントを復号する間の継続時間中に消費される電力に基づいて前記第１のリプレゼンテーションの電力消費を決定するように構成される、請求項３のＷＴＲＵ。

【請求項5】

前記プロセッサは、前記第２の複雑度情報の決定に基づいて、動作を削減するように構成される、請求項３のＷＴＲＵ。

【請求項6】

前記少なくとも１つのメタデータファイルは、前記複数のリプレゼンテーションに対する複雑度情報を運び、ＭＰＤは、前記複数のリプレゼンテーションに対する前記複雑度情報の利用可能性を示す情報を含む、請求項３のＷＴＲＵ。

【請求項7】

前記プロセッサは、
前記マルチメディアコンテンツの長さを決定し、
前記第１の複雑度情報および前記マルチメディアコンテンツの長さに基づいて、前記マルチメディアコンテンツを再生するために必要な電力を決定し、
前記マルチメディアコンテンツを再生するために必要な前記電力に基づいて、前記第２の複雑度情報を決定する
ようにさらに構成される、請求項３のＷＴＲＵ。

【請求項8】

前記プロセッサは、
前記第１の複雑度情報が、前記マルチメディアコンテンツの再生に使用される電力がバッテリ残容量を超えることを示していると決定し、
前記バッテリ残容量内で前記マルチメディアコンテンツを再生できるように前記第２の複雑度情報を決定する
ようにさらに構成される、請求項３のＷＴＲＵ。

【請求項9】

前記少なくとも１つのメタデータファイルは、ムービングピクチャエキスパートグループ（ＭＰＥＧ）グリーンによって定義されたメタデータファイルを含む、請求項１のＷＴＲＵ。

【請求項10】

前記少なくとも１つのメタデータファイルは、前記複数のリプレゼンテーションのそれぞれに対する相対的な複雑度基準を示す、請求項１のＷＴＲＵ。

【請求項11】

マルチメディアコンテンツのための複数のリプレゼンテーションを識別するメディアプレゼンテーションディスクリプション（ＭＰＤ）ファイルを受信することと、
前記複数のリプレゼンテーションに対する複雑度情報を示す少なくとも１つのメタデータファイルを受信することであって、前記少なくとも１つのメタデータファイルは、ＭＰＤファイルとは異なるファイルである、ことと、
前記少なくとも１つのメタデータファイルの中の前記複数のリプレゼンテーションに対する前記複雑度情報に基づいて第１のビデオセグメントをダウンロードするための第１のリプレゼンテーションを決定することと、
前記第１のリプレゼンテーションの前記第１のビデオセグメントを要求することと、
前記第１のリプレゼンテーションの前記第１のビデオセグメントを受信することと、
前記第１のビデオセグメントを復号することと
を備える方法。

【請求項12】

複数のメタデータファイルを受信することをさらに備え、前記複数のメタデータファイルは、前記複数のリプレゼンテーションに対する前記複雑度情報を示す、請求項１１の方法。

【請求項13】

前記第１のリプレゼンテーションを決定することは、前記第１のリプレゼンテーションの第１の複雑度情報に基づいており、
前記方法は、
前記第１のリプレゼンテーションの第１の複雑度情報および前記第１のリプレゼンテーションの電力消費に基づいて第２のビデオセグメントの第２のリプレゼンテーションを選択するための第２の複雑度情報を決定することと、
前記第２の複雑度情報に基づいて前記第２のビデオセグメントを要求するための前記第２のリプレゼンテーションを決定することと、
前記第２のリプレゼンテーションの前記第２のビデオセグメントを要求することと、
前記第２のリプレゼンテーションの前記第２のビデオセグメントを受信することと、
前記第２のビデオセグメントを復号することと
を備える、請求項１１の方法。

【請求項14】

前記第１のリプレゼンテーションの前記第１のビデオセグメントを復号する間の継続時間中に消費される電力に基づいて前記第１のリプレゼンテーションの電力消費を決定することをさらに備える、請求項１３の方法。

【請求項15】

前記第２の複雑度情報の決定に基づいて、動作を削減することをさらに備える、請求項１３の方法。

【請求項16】

前記少なくとも１つのメタデータファイルは、前記複数のリプレゼンテーションに対する複雑度情報を運び、ＭＰＤは、前記複数のリプレゼンテーションに対する前記複雑度情報の利用可能性を示す情報を含む、請求項１３の方法。

【請求項17】

前記マルチメディアコンテンツの長さを決定することと、
前記第１の複雑度情報および前記マルチメディアコンテンツの長さに基づいて、前記マルチメディアコンテンツを再生するために必要な電力を決定することと、
前記マルチメディアコンテンツを再生するために必要な前記電力に基づいて、前記第２の複雑度情報を決定することと
をさらに備える、請求項１３の方法。

【請求項18】

前記第１の複雑度情報が、前記マルチメディアコンテンツの再生に使用される電力がバッテリ残容量を超えることを示していると決定することと、
前記バッテリ残容量内で前記マルチメディアコンテンツを再生できるように前記第２の複雑度情報を決定することと
をさらに備える、請求項１３の方法。

【請求項19】

前記少なくとも１つのメタデータファイルは、ムービングピクチャエキスパートグループ（ＭＰＥＧ）グリーンによって定義されたメタデータファイルを含む、請求項１１の方法。

【請求項20】

前記少なくとも１つのメタデータファイルは、前記複数のリプレゼンテーションのそれぞれに対する相対的な複雑度基準を示す、請求項１１の方法。

【発明の詳細な説明】

【技術分野】

【0001】

本出願は、２０１３年３月６日に出願された米国仮特許出願第６１／７７３，３７９号、および２０１４年２月６日に出願された米国仮特許出願第６１／９３６，８３８号の利益を主張し、両出願の開示内容は、参照により本明細書に組み込まれる。

【背景技術】

【0002】

モバイルデバイスの計算能力は、ＣＰＵ周波数、ＣＰＵコアの数およびメモリサイズの点で向上している。システムオンチップ（ＳｏＣ）および無線通信技術（例えば、４ＧおよびＷｉＦｉ）の進歩と共に、モバイルプラットフォームは、社会において重要な役割を果たしており、モバイルユーザの数が増加し、モバイルデバイスが音声通話以上の役割を担っている。例えば、ユーザは、モバイルデバイスを使用して、いつの時点でもサービスにアクセスすることができる。

【発明の概要】

【発明が解決しようとする課題】

【0003】

ビデオストリーミングは、無線ネットワークで動作するモバイルプラットフォームに対してリクエストされることが多いビデオサービスである。リソースの制約があり、かつ異種のモバイルデバイス上で高品質のビデオサービスを提供するには多くの課題が存在することがある。このような課題は、ネットワーク条件が変わること、表示サイズが変わること、処理能力が変わること、およびバッテリ寿命を含むことがある。

【課題を解決するための手段】

【0004】

電力認識ビデオストリーミングシステムに対する電力認識適応（power aware adaptation）は、異なる方法で搬送することができる、複雑度情報（complexity information）に基づいてもよい。ビデオデータストリームなどの、データストリームの複雑度レベルは、無線送信／受信ユニット（ＷＴＲＵ）のバッテリ残電力、ならびにＷＴＲＵによって記憶および／または管理することができる、複数の状態の組（state sets）の状態の組に応じて選択されてもよい。これらの状態の組は、例えば、異なるコンテンツソースおよび／または異なる複雑度推定アルゴリズムに対応してもよく、ならびにデータストリームの複雑度レベル（complexity level）を選択するために使用されてもよい。次いで、データストリームは、選択された複雑度レベルにおいて受信されてもよい。データストリームの複雑度レベルおよび／またはビットレートは、例えば、バッテリ残電力および／または他の環境に順応するように適応されてもよい。適応は、使用事例の目的に従ってカスタマイズされてもよい。

【0005】

追跡状態の組において使用することができるメモリ量を削減するために、ＷＴＲＵなどの、デコーダデバイスは、そのデコーダデバイスが追跡することができる状態の組の数を制限してもよく、およびこの制限を超えることがあるとき、状態の組を削除してもよい。デコーダデバイスは、電力散逸率（ＰＤＲ：power dissipation rate）状態に対する複雑度レベルと類似することがある状態の組を結合してもよく、および複雑度レベルＰＤＲ状態に量子化してもよい。

【0006】

電力認識ストリーミングのためのデバイスを提供することができる。デバイスは、いくつかの動作を実行することができるプロセッサを含んでもよい。データセグメントに対する複雑度レベルが判定されてもよい。例えば、データセグメントに対する複雑度は、サーバから。または信号を介して受信されてもよい。データセグメントは、ビデオストリームのセグメントであってよい。例えば、プロセッサは、デコーダによって使用することができるデータセグメントに対する複雑度レベルを判定してもよい。複雑度レベルに対するＰＤＲは、データセグメントを復号する間に散逸する（dissipate）ことがある電力に基づいてもよい。複雑度レベルに対するＰＤＲは、第１のバッテリレベルおよび第２のバッテリレベルを使用して判定されてもよい。ＰＤＲ状態などの状態は、ＰＤＲを使用して算出されてもよい。複雑度レベルに対する第２のＰＤＲが判定されてもよい。

【0007】

複雑度レベルに対するＰＤＲ状態などの状態は、第１のＰＤＲおよび第２のＰＤＲを使用して算出されてもよい。例えば、ＰＤＲ状態は、第１のＰＤＲおよび第２のＰＤＲの重み付け平均を算出することによって算出されてもよい。別の例として、ＰＤＲ状態は、第１の重みを第１のＰＤＲに適用することによって第１の重み付けＰＤＲを算出し、第２の重みを第２のＰＤＲに適用することによって第２の重み付けＰＤＲを算出し、ならびにＰＤＲ状態を第１の重み付けＰＤＲおよび第２の重み付けＰＤＲの平均値に設定することによって算出されてもよい。

【0008】

ビデオストリームを再生する電力の量が判定されてもよい。例えば、ビデオストリームの長さまたは継続時間が判定されてもよい。複雑度レベルにおいてビデオストリームを再生するために必要な電力は、ビデオストリームの長さまたは継続時間に複雑度レベルに対するＰＤＲ（例えば、ＰＤＲ状態）を乗算することによって算出されてもよい。

【0009】

バッテリ残容量が判定されてもよい。複雑度レベルにおいてビデオストリームを復号および／または再生するために使用することができる電力が判定されてもよい。電力がバッテリ残容量を超えるかに関する判定がなされてもよい。電力がバッテリ残容量を超える場合、バッテリ残容量内で、ビデオストリームを復号および再生するために、別の複雑度レベルが使用されてもよい。

【0010】

電力認識ストリーミングのためのデバイスを提供することができる。デバイスは、いくつかの動作を実行するように構成することができるプロセッサを含んでもよい。例えば、データセグメントに対し、第１の複雑度レベルが判定されてもよい。データセグメントに対する複雑度レベルは、サーバから、または信号を介して複雑度レベルを受信することによって判定されてもよい。デコーダに対する計算負荷が判定されてもよい。計算閾値が判定されてもよい。計算閾値は、ユーザによって設定されてもよい。計算負荷が計算閾値を上回り、または下回ることがあることを判定されてもよい。第２の複雑度レベルは、計算負荷を使用して選択されてもよい。データセグメントに対してビットレートが判定されてもよい。

【0011】

発明の概要は、発明を実施するための形態においてさらに説明される概念の選択を簡易な形式で導入するために提供される。この発明の概要は、特許請求される主題の重要なまたは重要な特徴を特定することを意図せず、特許請求される主題の範囲を限定するために使用されることも意図しない。さらに、特許請求される主題は、本開示のいずれかの部分において記載されているいずれかまたは全ての欠点を解決する制限に限定されない。

【図面の簡単な説明】

【0012】

添付図面と共に例として与えられる以下の説明からより詳細な理解を得ることができる。

【図1】例示的なＨＴＴＰベースのビデオストリーミングシステムを示す図である。

【図2】例示的なブロックベースのビデオエンコーダを示す図である。

【図3】例示的なブロックベースのビデオデコーダを示す図である。

【図4】例示的なビデオ再生シナリオにおける電力使用量の例を示す図である。

【図5】例示的な電力認識ストリーミングシステムを示す図である。

【図6】解像度、ビットレート、および複雑度を考慮することによって、サーバ側で生成することができる例示的なコンテンツを示す図である。

【図7】複雑度認識メディアプレゼンテーションディスクリプション（ＭＰＤ）ファイルの例を示す図である。

【図8】品質モードに対する電力適応論理（power adaptation logic）によって実装することができる例示的なプロセスを示す図である。

【図9】マルチタスキング環境に対する電力適応論理によって実装することができる例示的なプロセスを示す図である。

【図10】デコーダデバイスが複数の異なるコンテンツソースからメディアコンテンツをストリームすることができる例示的なシステムを示す図である。

【図11】複雑度レベルを量子化する例を示す図である。

【図12】削減された状態の組を使用する電力散逸状態の計算におけるバイアスの例を示す

【図13】削減された状態の組の電力散逸状態を更新する時にバイアスを削減または消去する補間（interpolation）の例を示す図である。

【図14A】１または複数の開示された実施形態を実装することができる例示的な通信システムのシステム図である。

【図14B】図１Ａに示した通信システム内で使用することができる例示的な無線送信／受信ユニット（ＷＴＲＵ）のシステム図である。

【図14C】図１Ａに示した通信システム内で使用することができる例示的な無線アクセスネットワークおよび例示的なコアネットワークのシステム図である。

【図14D】図１Ａに示した通信システム内で使用することができる別の例示的な無線アクセスネットワークおよび別の例示的なコアネットワークのシステム図である。

【図14E】図１Ａに示した通信システム内で使用することができる別の例示的な無線アクセスネットワークおよび別の例示的なコアネットワークのシステム図である。

【発明を実施するための形態】

【0013】

ここで、具体的な例の詳細な説明をさまざまな図面を参照して説明する。この説明は、可能な実装の詳細な例を提供するが、それらの詳細は、例示目的であり、適用の範囲を限定するものではないことに留意されたい。

【0014】

電力認識ビデオストリーミングシステムに対する電力認識適応は、いくつかの方法で搬送することができる、複雑度情報に基づいてもよい。ビデオデータストリームなどのデータストリームの複雑度レベルは、無線送信／受信ユニット（ＷＴＲＵ）のバッテリ残電力、ならびにＷＴＲＵによって記憶および／または管理することができる複数の状態の組の状態の組でＷＴＲＵに応じて選択されてもよい。これらの状態の組は、例えば、異なるコンテンツソースおよび／または異なる複雑度推定アルゴリズムに対応してもよく、ならびにデータストリームの複雑度レベルを選択するために使用されてもよい。次いで、データストリームは、選択された複雑度レベルにおいて受信されてもよい。データストリームの複雑度レベルおよび／またはビットレートは、例えば、バッテリ残電力および／または他の環境に順応するように適応されてもよい。その適応は、使用事例の目的に従ってカスタマイズされてもよい。

【0015】

追跡状態の組において使用することができるメモリの量を削減するために、ＷＴＲＵなどのデコーダデバイスは、それが追跡することができる状態の組の数に制限を設定してもよく、およびこの制限を超えるときに状態の組を削除してもよい。デコーダデバイスは、電力散逸率（ＰＤＲ）状態と類似することがある状態の組を結合してもよく、および／または複雑度レベルをＰＤＲ状態に量子化してもよい。

【0016】

電力認識ストリーミングのためのデバイスを提供することができる。デバイスは、いくつかの動作を実行することができるプロセッサを含んでもよい。データセグメントに対する複雑度レベルが判定されてもよい。例えば、データセグメントに対する複雑度は、サーバから、または信号を介して受信されてもよい。データセグメントは、ビデオストリームのセグメントであってもよい。例えば、プロセッサは、デコーダによって使用することができるデータセグメントに対する複雑度レベルを判定してもよい。複雑度レベルに対するＰＤＲは、データセグメントを復号する間に散逸することがある電力に基づいてもよい。複雑度レベルに対するＰＤＲは、第１のバッテリレベルおよび第２のバッテリレベルを使用して判定されてもよい。ＰＤＲ状態などの状態は、ＰＤＲを使用して算出されてもよい。複雑度レベルに対する第２のＰＤＲが判定されてもよい。

【0017】

複雑度レベルに対するＰＤＲ状態などの状態は、第１のＰＤＲおよび第２のＰＤＲを使用して算出されてもよい。例えば、ＰＤＲ状態は、第１のＰＤＲと第２のＰＤＲの重み付け平均を算出することによって算出されてもよい。別の例として、ＰＤＲ状態は、第１の重みを第１のＰＤＲに適用することによって第１の重み付けＰＤＲを算出し、第２の重みを第２のＰＤＲに適用することによって第２の重み付けＰＤＲを算出し、ならびにＰＤＲ状態を第１の重み付けＰＤＲおよび第２の重み付けＰＤＲの平均値に設定することによって算出されてもよい。

【0018】

ビデオストリームを再生する電力の量が判定されてもよい。例えば、ビデオストリームの長さまたは継続時間が判定されてもよい。複雑度レベルにおいてビデオストリームを再生するために必要な電力は、ビデオストリームの長さまたは継続時間に複雑度レベルに対するＰＤＲ（例えば、ＰＤＲ状態）を乗算することによって算出されてもよい。

【0019】

バッテリ残容量が判定されてもよい。複雑度レベルにおいてビデオストリームを復号および／または再生するために使用することができる電力が判定されてもよい。電力がバッテリ残容量を超えるかに関する判定がなされてもよい。電力がバッテリ残容量を超える場合、バッテリ残容量内で、ビデオストリームを復号および再生するために、別の複雑度レベルが使用されてもよい。

【0020】

電力認識ストリーミングのためのデバイスを提供することができる。デバイスは、いくつかの動作を実行するように構成することができるプロセッサを含んでもよい。例えば、データセグメントに対して、第１の複雑度レベルが判定されてもよい。データセグメントに対する複雑度レベルは、サーバから、または信号を介して複雑度レベルを受信することによって判定されてもよい。デコーダに対する計算負荷が判定されてもよい。計算閾値が判定されてもよい。計算閾値は、ユーザによって設定されてもよい。計算負荷が計算閾値を上回り、または下回ることがあることを判定されてもよい。第２の複雑度レベルは、計算負荷を使用して選択されてもよい。データセグメントに対して、ビットレートが判定されてもよい。

【0021】

本明細書で説明されるように、電力適応は、クライアント側で実行されてもよい。例えば、電力適応は、電力認識ストリーミングシステムで適用されてもよい。電力散逸状態は、ＷＴＲＵなどのデコーダデバイスによって追跡、維持、および使用されてもよい。例えば、コンテンツプロバイダまたはコンテンツソースは、コンテンツの復号と関連付けられた電力散逸に関係することがあるコンテンツの複雑度を推定するために異なるアルゴリズムを使用してもよい。デコーダデバイスは、これらの異なるアルゴリズムを認識および適応することができる。

【0022】

ビデオストリーミングは、無線ネットワークで動作することができるモバイルプラットフォームに対する要求されたビデオサービスであってよい。リソースの制約があることがあるモバイルデバイス上で品質の良いビデオサービスを提供することに多くの課題が存在することがある。例えば、ネットワーク条件が変わることがあり、表示サイズが変わることがあり、および処理能力が変わることがあり、そしてバッテリ寿命が存在することがある。多くのサービスプロバイダは、Ｄｙｎａｍｉｃ ａｄａｐｔｉｖｅ ｓｔｒｅａｍｉｎｇ ｏｖｅｒ ＨＴＴＰ（ＤＡＳＨ）ソリューションを採用し、なぜならば、それらは、サービスプロバイダに既存のネットワークインフラストラクチャ、特に、ＣＤＮネットワークを再使用させることが可能であり、およびファイアウォールを超える（traverse）することができるからである。例えば、ＥｄｇｅＣａｓｔおよびＬｅｖｅｌ ３は、Ｍｉｃｒｏｓｏｆｔ社のＳｍｏｏｔｈ Ｓｔｒｅａｍｉｎｇを使用し、ＡｋａｍａｉおよびＣｌｏｕｄＦｒｏｎｔは、Ａｄｏｂｅ社のＤｙｎａｍｉｃ ＨＴＴＰ Ｓｔｒｅａｍｉｎｇを使用する。ｉＯＳデバイスは、Ａｐｐｌｅ社のＨＴＴＰ Ｌｉｖｅ Ｓｔｒｅａｍｉｎｇをサポートすることができる。

【0023】

ＤＡＳＨにおいて、媒体は、復号可能とすることができるセグメントに編成（organize）されてもよい。コンテンツは、異なる品質または解像度にエンコードされてもよく、およびセグメントに細分化（chopped into）されてもよい。ビットレート、バイト範囲、およびＵＲＬなどのこれらのコンテンツの情報は、メディアプレゼンテーションディスクリプション（ＭＰＤ）と呼ばれる、ＸＭＬベースのマニフェストファイル（ＭＦ）で記述されてもよい。クライアントは、ＨＴＴＰを通じてこのコンテンツにアクセスすることができ、およびＭＰＤファイルに従ってセグメントの帯域幅または解像度基準を満たすことができるセグメントを選択することができる。

【0024】

図１は、システム２００などの、例示的なＨＴＴＰベースのビデオストリーミングシステムを示している。捕捉されたコンテンツは、圧縮されてもよく、および小さいセグメントに細分化されてもよい。例えば、一部のストリーミングシステムおいてセグメントは、２秒と１０秒との間の長さであってもよい。２０２において、セグメントは、１もしくは複数のＨＴＴＰストリーミングサーバに記憶されてもよく、および／またはコンテンツデリバリネットワーク（ＣＤＮ）介して分散されてもよい。ストリーミングセッションの開始時に、２０２において、クライアントは、ＨＴＴＰストリーミングサーバにＭＰＤファイルを要求および受信してもよい。クライアントは、セグメントの表示解像度および利用可能帯域幅などの能力に従って、どのセグメントを要求するかを決定してもよい。クライアントは、２０２において、ビデオセグメントをその要求毎にクライアントに送信することができるサーバから適切なセグメントを要求してもよい。２０４において、ＨＴＴＰを介して送信されるセグメントは、ＨＴＴＰキャッシュサーバにキャッシュされてもよい。これによって、キャッシュされたセグメントが他のユーザに対して再使用されることが可能となり、およびシステムが大規模にストリーミングサービスを提供することを可能にすることができる。

【0025】

一部のストリーミングシステムにおいて、伝送帯域幅およびストレージを節約するために、単一レイヤビデオ符号化が使用されて、ビデオコンテンツを圧縮、および異なるビットストリームを作成してもよい。図２は、ストリーミングシステム２００などの、ストリーミングシステムに対してビットストリームを作成するために使用することができる例示的なブロックベースのレイヤビデオエンコーダ３００を示すブロック図である。効率的な圧縮を実現するために、単一レイヤエンコーダは、例えば、３０２において空間予測（イントラ予測と称されてもよい）、および／または３０４において時間予測（インター予測および／または動き補償予測と称されてもよい）を使用して、入力ビデオ信号を予測してもよい。エンコーダはまた、例えば、レートおよび歪みの考慮の組み合わせなど、一定の基準に基づいて、予測の形式（例えば、最も適した形式）を選択することができるモード決定論理３０６を有してもよい。エンコーダは、予測残差（入力信号と予測信号間の差分信号とすることができる）を３０８において変換し、３１０において量子化してもよい。量子化された残差は、モード情報（例えば、イントラまたはインター予測）および予測情報（動きベクトル、基準ピクチャインデックス、イントラ予測モードなど）と一緒にさらに、エントロピーコーダ３１２において圧縮され、そして出力ビデオビットストリーム３１４にパッキングされてもよい。図２に示すように、エンコーダはまた、３１６における逆量子化および３１８における逆変換を量子化された残差に適用することによって、再構築されたビデオ信号を生成して、再構築された残差を取得し、および３２０においてそれを予測信号に再度、追加してもよい。再構築されたビデオ信号は、ループフィルタプロセス３２２、例えば、デブロッキングフィルタ、Ｓａｍｐｌｅ Ａｄａｐｔｉｖｅ Ｏｆｆｓｅｔｓ、またはＡｄａｐｔｉｖｅ Ｌｏｏｐ Ｆｉｌｔｅｒｓを通ってもよく、およびビデオ信号を予測するために使用することができる基準ピクチャストア３２４に記憶されてもよい。

【0026】

図３は、エンコーダ３００などのエンコーダによって生成されるビデオビットストリームを受信することができ、およびビデオ信号が表示されるように再構築することができる例示的なブロックベースの単一レイヤデコーダ４００のブロック図である。デコーダ４００において、ビットストリームは、エントロピーデコーダ４０２によって構文解析される。残差係数は、４０４において逆量子化され、４０６において逆変換されて、再構築された残差を取得する。符号化モードおよび予測情報は、空間予測４０８および／または時間予測４１０を使用して予測信号を取得するために使用されてもよい。４１２において、予測信号と再構築された残差がともに追加されて、再構築されたビデオを得てもよい。再構築されたビデオは、４１４においてループフィルタリングと通ってもよく、基準ピクチャストア４１６に記憶されてもよく、４１８において表示されてもよく、および／またはビデオ信号を復号するために使用されてもよい。エンコーダ３００などのブロックベースのエンコーダ、およびデコーダ４００などのブロックベースのデコーダを使用することができるいくつかのビデオ符号化規格は、ＭＰＥＧ－２ Ｖｉｄｅｏ、ＭＰＥＧ４ Ｖｉｓｕａｌ、Ｈ．２６４／ＡＶＣ、およびＨＥＶＣを含む。

【0027】

モバイルデバイスの電力耐性（power endurance）は、アプリケーション性能に影響を与えることがある。基準モバイルプラットフォームに対する電力使用量は、さまざまな条件下で分析されてもよい。例えば、コンポーネント、例えば、プロセッサ、ディスプレイ、内部および外部メモリ、および無線（例えば、ＧＳＭ（登録商標）／３Ｇ／４Ｇ／ＷｉＦｉ）の電力消費が評価されてもよい。異なるアプリケーションにおいて、それらの間の電力消費率は異なることがある。例えば、ビデオ再生は、それが計算とメモリアクセスの両方を含むので、集中した電力消費アプリケーションになることがある。さらに、ビデオ再生は、ピクチャを十分な輝度レベルで表示することがあり、これもまた、多くの電力を消費することがある。図４は、ＣＰＵ、グラフィックス、およびディスプレイ（バックライトおよびＬＣＤ）部分が電力を消費することがある、例示的なビデオ再生シナリオにおける電力使用量の例を示している。

【0028】

省電力アプローチは、システム状態に従って作業モードを適応的に切り替えることができる。例えば、システム状態がアイドルである時、デバイスプロセッサは、低電力状態に移行して、電力消費を削減するように動作している要求されたモジュールを維持してもよい。他の省電力アプローチは、プロセッサの周波数を適応的に切り替えることができる。例えば、プロセッサの周波数が低下するとき、電源の電圧も低下して、電力消費を削減することができる。チップによって消費される（dissipated）電力は、
Ｐ＝ＣＶ²ｆ
によって、定式化され、Ｃは、静電容量であり、Ｖは、電圧であり、ｆは、切り替え周波数である。プロセッサの周波数は、異なるタスクに対して構成されてもよい。例えば、復号化複雑度がピクチャに対して異なることがあるので、プロセッサのクロック周波数は、ピクチャの復号が容易な復号化ときに低下することがある。エンコードされたピクチャサイズは、ピクチャの復号時間を推定するために使用されてもよい。プロセッサの周波数は、例えば、推定されたピクチャの復号時間がピクチャの継続時間よりも短いときに低下することがある。モバイルデバイス上での全長ビデオ再生を提供するために、電力は、ディスプレイ、復号化モジュールなどの、異なるモジュールに割り当てられてもよい。例えば、クライアントデバイスは、システムが残りのビデオを再生するために残電力が十分ではないと判定する場合、ディスプレイの輝度を低下させ、および／または一部のフレーム復号化をスキップしてもよい。

【0029】

バッテリ耐性を長くし、および全長ビデオ再生を提供するための電力使用量効率の改善は、モバイルプラットフォームへのビデオストリーミングアプリケーションによる満足なユーザ体験をもたらすことを促進できる。しかしながら、ＤＡＳＨなどの一部のストリーミングシステムは、ネットワーク帯域幅のバリエーションに重点を置いているが、それらの設計において電力使用量の問題を考慮してない場合もある。省電力方法は、クライアント側の技術であることがあり、フレーム欠落および／またはモーションジャーキネス（jerkiness）という代償を払ってでも全長再生を回避することができる。モバイルデバイスに対する省電力問題は、電力認識計算（power aware computing）に基づいて対処されてもよい。例えば、サーバおよびクライアントは協働してもよい。例えば、サーバは、電力消費を考慮してビデオコンテンツ作成してもよく、およびクライアントは、利用可能帯域幅、バッテリ残量、および残りのビデオ再生時間に従って、異なる複雑度を有するプレゼンテーションを受け取ってもよい（subscribe to）。

【0030】

クライアントは、サーバからビデオセグメントを受信した後、ビデオを復号および再生しようと試みることがある。ソフトウェアデコーダの場合、復号化および再生は、時間基準を満たすためにプロセッサのリソースの一部を占有することがある。プロセッサのリソースに負担がかかることを回避する方法が使用されてもよく、この方法は、プロセッサがリアルタイムでビデオの復号に取り組んでいるときに、クライアントがビデオを円滑に再生することが不可能となることを回避することができる。例えば、クライアントがフレームの欠落または非同期のオーディオおよびビデオの提示を回避するための方法が使用されてもよい。別の例として、方法によって、マルチタスク指向環境においてシステムの応答時間の改善を可能にする。

【0031】

電力認識適応方法は、電力認識ビデオストリーミングシステムにおいて電力認識適応制御モジュールによって使用されてもよい。これらの電力認識適応方法は、省電力および／またはより良いプロセッサの負荷分散を実現することができる。電力適応は、電力認識ストリーミングシステムに適用することができるクライアント側で実装されてもよい。

【0032】

図５は、例示的な電力認識ストリーミングシステム６００を示すブロック図である。電力認識ストリーミングシステム６００は、電力認識ビデオエンコーダ６０２、複雑度認識ＭＰＤ８００、電力認識適応制御モジュール６０４、および／または電力センシングモジュール６０６を含んでもよい。電力認識適応制御モジュール６０４および／または電力センシングモジュール６０６は、例えば、電力認識ストリーミングクライアント６０８において実装されてもよい。電力認識ビデオエンコーダ６０２は、異なる複雑度レベルで種々のバージョンのビデオセグメントを生成してもよい。図６は、サーバ側において解像度、ビットレート、および複雑度を考慮することによって生成することができる、例示的なコンテンツを比較したグラフを示している。図６に示した例において、いくつかの複雑度レベルは、７０２、７０４および７０６におけるような、ビットレートに対して利用可能であってもよい。

【0033】

ＤＡＳＨ技術または他の同様のＨＴＴＰストリーミング技術を使用するビデオストリーミングシステムにおいて、複雑度レベル情報は、ＭＰＤファイル、メディア記述ファイル、またはクライアントにシグナルすることができる他のタイプのマニフェストファイルに追加されてもよい。図７は、複雑度認識ＭＰＤファイル８００の例を示している。表現要素（representation element）の記述８０２は、ビットストリームの複雑度レベルを示すことができるｃｏｍｐｌｅｘｉｔｙＬｅｖｅｌ属性８０４を含んでもよい。

【0034】

複雑度情報を搬送するためにＭＰＤファイルまたは他のタイプのマニフェストファイルを本開示の例として使用することができるが、他のタイプのビットストリームレベルまたはシステムレベルのシグナリングを使用して、複雑度情報を搬送することができることが当業者には認識されよう。例えば、複雑度情報は、ビデオパラメータセット（ＶＰＳ：Video Parameter Set）、シーケンスパラメータセット（ＳＰＳ：Sequence Parameter Set）などの、高レベルのパラメータセットを使用してビデオストリームに組み込まれてもよい。複雑度情報は、ＭＰＥＧメディアトランスポート（ＭＭＴ）によって伝達されてもよい。例えば、複雑度情報は、ＭＭＴアセット(MMT Asset)のプロパティ要素として符号化されてもよく、またはクライアントへのＭＭＴメッセージとして伝達されてもよい。Ｇｒｅｅｎ ＭＰＥＧ Ｃａｌｌ ｆｏｒ Ｐｒｏｐｏｓａｌｓ（ＣｆＰ）は、デバイス上の電力消費を削減する有益な情報を搬送するために使用することができるメタデータファイルを定義できる。このようなメタデータファイルは、複雑度情報を伝達するために使用されてもよい。

【0035】

クライアント側の電力認識適応制御は、帯域幅センシング、電力センシング、および／またはＣＰＵ負荷状態から取得することができる情報に従って、受信機に対するセグメントを適応的に選択することができる。適応論理は、デバイス上のバッテリ残電力を使用して、許容可能な、例えば、改善されたビデオ品質を実現し、現在利用可能な帯域幅を満たし、および／またはＣＰＵ負荷分散を実現して、全長再生を促進することができる。

【0036】

再度図５を参照すると、電力適応論理６０４は、異なるアプリケーションの目的に基づいてカスタマイズされてもよい。例えば、電力適応論理６０４は、ユーザがクライアントを品質モードに構成する場合などの、さまざまな使用事例において使用されてもよい。ユーザが電力よりも品質を優先する場合、電力適応論理６０４は、残電力および最良の利用可能なビデオ品質で全長再生を優先付けてもよい。ユーザがクライアントを、例えば、マルチタスキング環境における、負荷分散モードに構成する場合、電力適応論理６０４は、プロセッサの負荷バジェット（load budget）内で全長再生を優先付けてもよい。ユーザがクライアントを省電力モードに構成する場合、例えば、ユーザがバッテリ残電力の節約を優先する場合、電力適応論理６０４は、プロセッサの負荷バジェット内で全長再生および／またはできるだけ少ない電力の消費を優先付けてもよい。

【0037】

図５の電力センシングモジュール６０６を使用して、電力認識クライアント６０８は、バッテリレベル（ＢＬ）を測定してもよく、および／またはバッテリ使用量を判定してもよい。電力センシングモジュール６０６は、現在のバッテリレベルを提供することができるインタフェースを使用してもよい。例えば、電力センシングモジュール６０６は、全バッテリ容量の残率を示すことができる、例えば、Ａｎｄｒｏｉｄオペレーティングシステムなどのオペレーティングシステムによって提供することができる電力管理インタフェースを定期的に使用してもよい。電力センシングモジュール６０６は、アプリケーションまたはプロセスによってバッテリ使用量をレポートするインタフェースを使用してもよい。例えば、Ａｎｄｒｏｉｄオペレーティングシステムは、１もしくは複数のアプリケーション（例えば、１つのアプリケーション）の電力およびプロセッサに対する使用量統計ならびに／またはディスプレイに対する電力使用量を提供することができるインタフェースを有してもよい。電力センシングモジュール６０６は、マルチタスクまたはマルチプロセス環境においてビデオの復号化および表示によって電力使用量を判定してもよい。電力認識クライアント６０８は、その後、電力適応論理６０４を適用して、効率的な電力使用量を保証することができる。適応は、構成可能な目的を満たすための電力散逸率（ＰＤＲ）の更新および複雑度レベル（ＣＬ）の適応を含んでもよい。

【0038】

複雑度レベルに対する電力散逸率（ＰＤＲ：power dissipation rate）は、例えば、以下の式に従って、定期的に測定および更新されてもよい。

【0039】

【数1】

【0040】

ｋは、複雑度レベルであり、ｔ_jは、ｉ番目のセグメントの時間であり、ＣＬ_MINおよびＣＬ_MAXはそれぞれ、システムにおける最小複雑度レベルと最大複雑度レベルであってもよく、ＣＬ_iは、ｉ番目のセグメントの複雑度レベルであってもよく、ＰＤＲ（ＣＬ_i，ｔ_j）は、時間ｔ_jにおける複雑度レベルＣＬ_iのＰＤＲ値であってもよく、ＢＬ_iは、時間ｔ_jにおける残りのバッテリレベルであってもよく、αは、更新速度を制御する因子であってもよく、例えば、その因子を０．６に設定することができ、この場合、ＰＤＲ値は、式（１）を使用して更新されてもよく、ならびに現在のＰＤＲ観察の６倍と以前のＰＤＲ状態の４倍とを組み合わせで重み付けされてもよい。αの値は、０≦α≦１を満たしてもよい。αのより大きい値は、より大きい重みを現在のＰＤＲ観察に与え、およびより高速の更新速度をもたらすために使用されてもよく、αのより小さい値は、より大きい重みを以前のＰＤＲ状態によって表された時の過去のＰＤＲ履歴に与え、およびより低速の更新速度をもたらすために使用されてもよい。最小で、初期のＰＤＲ観察を、更なる更新をしないで現行で使用することができるように、α＝０の値が使用されてもよい。最大で、最新のＰＤＲ観察が常に使用され、およびより古いＰＤＲ履歴が破棄されるように、α＝１の値が使用されてもよい。ビデオセッションの開始時の複雑度値のＰＤＲ値（例えば、全ての複雑度値）が０に初期化されてもよい。複雑度レベルのＰＤＲ値が更新されてもよい。バッテリレベルが変更されない場合、ＰＤＲ統計は維持されてもよい。そうでない場合、ＰＤＲ統計は、それに応じて更新されてもよい。

【0041】

複雑度レベル（ＣＬ）が構成可能な目的を満たすように適応される場合、ＰＣ（ＣＬ_i，ｔ_j）として示される、複雑度レベルＣＬ_iを有する残りのビデオを再生するために要求される電力量は、式（２）
ＰＣ（ＣＬ_i，ｔ_i）＝ＰＤＲ（ＣＬ_i，ｔ_i）＊（Ｔ－ｔ_i）
式（２）
として推定されてもよい。ＰＤＲは、上記の式（１）で算出されてもよく、Ｔは、全再生時間である。

【0042】

クライアントは、カスタマイズされた目的に従って、現在の複雑度レベルを切り替え、または維持するかどうかを決定してもよい。電力適応論理６０４は、バッテリ電力が使い果たされる前に、全長ビデオ再生を実現しようと試みることがある。

【0043】

図８は、品質モードの電力適応論理によって実装することができる例示的なプロセスを示している。例えば、例示的なプロセス９００は、ビデオ品質に所与の残りのバッテリレベルおよび可用帯域幅を提供することができる、品質モードに対する電力適応論理６０４（図５に示した）によって実装されてもよい。９０２と９０４においてそれぞれ、現在の複雑度レベル（ＣＬ）に対する帯域幅統計および電力統計を更新されてもよい。９０６において、残りのビデオ再生に対する１または複数の複雑度レベルに対して、電力消費（ＰＣ）が推定されてもよい。

【0044】

９０８において、現在の複雑度レベルに対する電力消費が残りのバッテリ寿命（ＢＬ_rem）よりも小さいか、現在の複雑度レベルが最大複雑度レベルよりも低いか、次のより高い複雑度レベルに対する電力消費が残りのバッテリ寿命よりも小さいか、例えば所与の残りのバッテリ寿命が与えられる次のより高い複雑度レベルにおいて残りのビデオを再生することが実現可能かどうか、が判定されてもよい。これは、クライアントが非常に頻繁に切り替えることを回避することができ、および復号されたビデオ品質をより円滑に促進することができる。この決定は、再生の間に前の統計から学習したＰＤＲに基づいて行われてもよい。これらの条件を満たされる場合、９１０において、デコーダは、通常の復号化モードに切り替えることを通知され、および複雑度レベルは、上方に切り替えられてもよい。９１２において、セグメントは、調整された複雑度レベルおよび選択されたビットレートにおいてダウンロードされてもよい。

【0045】

９０８において、条件が真ではないと判定される場合、９１４において、現在の複雑度レベルに対する電力消費が残りのバッテリ寿命よりも大きいか、および現在の複雑度レベルが最小複雑度レベルよりも高いかどうかが判定されてもよい。そうである場合、９１６において、複雑度レベルは、下方に切り替えられてもよい。複雑度レベルは、次のより低い複雑度レベルに切り替えることによって下方に切り替えられてもよい。複雑度レベルを下方に切り替えるこのアプローチは、より円滑な品質移行が可能となるように、複雑度レベルが徐々に切り替えられることを可能にする。

【0046】

複雑度レベルはまた、残電力が残りのビデオを再生するのに十分となり得る複雑度レベルを探索することによって、下方に切り替えられてもよい。これを、例えば、以下の表１を使用して行われてもよい。

【0047】

【表1】

【0048】

このアプローチは、電力をより多く節約するために複雑度レベルをより速く下方に切り替えることができる。しかしながら、この切り替え方法が誤ってあまりにも多くのレベルを下方に切り替えることを決定する場合、例えば、式（１）によって与えられたＰＤＲ推定が十分正確でない場合、電力適応論理は、後に複雑度レベルを再度上方に切り替えることを決定してもよい。どのように複雑度レベルが下方に切り替えられるかに関係なく、９１２において、セグメントは、調整された複雑度レベルおよび選択されたビットレートにおいてダウンロードされてもよい。

【0049】

同様に、クライアントが複雑度レベルをスイッチアップするか否かを決定するときに、段階的またはより肯定的な論理も適用されてもよい。例えば、より段階的な上方への切り替え方法は、図８に示すように、複雑度レベルによって一度に上方に切り替えられてもよく、より肯定的な上方への切り替え方法は、実現可能とすることができる次の最高複雑度レベルまで上方に切り替えられてもよい。より肯定的な方法は、複雑度レベルを下方に切り替える場合のように、より頻繁な切り替えのため、ビデオ品質の変更をさらに大きくするだけでなく、全長再生が実現される前にバッテリ電力を使い果たすという危険性がより高くなることがある。

【0050】

９１４において、現在の複雑度レベルに対する電力消費が残りのバッテリ寿命よりも大きくないこと、例えば、現在の複雑度レベルにおいてビデオを再生するためのバッテリ電力が不十分であるか、または現在の複雑度レベルが最小複雑度レベルよりも高くない（例えば、サーバから利用可能な最低複雑度レベルが既に使用されている）ことが判定されてもよい。９１８および９２０において、現在の（例えば、最小の）複雑度レベルに対する電力消費が残りのバッテリ寿命よりも大きいか、および／またはビットレート（ＢＲ）が最小ビットレートであるかが判定されてもよい。最低ビットレートに到達し、現在の（例えば、最小の）複雑度レベルに対する電力消費が残りのバッテリ寿命よりも大きい場合、例えば、現在の（例えば、最小の）複雑度レベルにおいてビデオを再生するためのバッテリ電力が不十分である場合、９２２において、現在の（例えば、最小の）複雑度レベルが維持されてもよく、およびデコーダは、より低い電力の復号化モードに切り替えられてもよい。例えば、ＨＥＶＣにおけるデブロッキングおよび／またはＳＡＯなどの、インループフィルタリングは、非基準フレームに対してバイパスされてもよい。９１２において、セグメントは、その後、その複雑度レベルおよびビットレートにおいてダウンロードされてもよい。

【0051】

現在の複雑度レベルに対する電力消費が残りのバッテリ寿命よりも大きいが、最小ビットレートに到達していない場合、９２４において、ビットレートは、より低いビットレートに切り替えられてもよく、および複雑度レベルは、より低いビットレートにおける新しい複雑度レベル、例えば、より低いビットレートにおけるより高い複雑度レベルまたは最高複雑度レベルに設定されてもよい。９１２において、セグメントは、その新しい（例えば、より高いまたは最高の）複雑度レベル、およびより低いビットレートにおいてダウンロードされてもよい。

【0052】

９１８において、現在の複雑度レベルに対する電力消費が残りのバッテリ寿命よりも大きくないことが判定される場合、９２６において、複雑度レベルが最高複雑度レベルであるか、およびビットレートが最大ビットレートよりも小さいかが判定されてもよい。これらの両方の条件が真である場合、９２８において、ビットレートは、より高いビットレートに切り替えられてもよく、および複雑度レベルは、より高いビットレートにおける新しい複雑度レベル、例えば、より高いビットレートにおけるより低いまたは最小複雑度レベルに設定されてもよい。そうでない場合、９３０において、現在の複雑度レベルが維持されてもよい。

【0053】

図９は、マルチタスキング環境に対する電力適応論理６０４（図５に示した）などの、電力適応論理によって実装することができる例示的なプロセス１０００を示している。プロセス１０００において実行される決定および動作の一部は、プロセス９００において遂行される決定および動作と同一であってもよく、同一の参照符号によって示されてもよい。プロセス１０００は、プロセス９００において実行されないことがあるいくつかの決定および動作を含んでもよい。プロセス１０００は、全長再生を提供することを試みている間、クライアントによってシステム負荷を分散するために使用することができる決定および動作を含んでもよい。残電力をチェックする前に、１０３２において、クライアントは、短期間の間に平均ＣＰＵ使用量を測定することによってシステムが過負荷であるか否かをチェックしてもよい。システムが過負荷である場合、１０３４において、システムは、複雑度レベルが最小限度ＣＬ_MINに到達するまで複雑度レベルを下方に切り替えてもよい。システムがＣＬ_MINにおいてなおも過負荷である場合、１０３６において、クライアントは、現在のビットレートが最低ビットレート（ＢＲ…ｍｉｎ）よりも大きい場合に、より低いビットレート表現に切り替えてもよく、および複雑度レベルを新しい複雑度レベル（例えば、より高いまたは最高複雑度レベル）に設定してもよい。クライアントが最低ビットレートおよび最低複雑度レベルに到達する場合、１０３８において、クライアントは、デコーダに低い複雑度の復号化モードを適用することを通知して、例えば、非基準フレームの一部の内部ループフィルタリング動作をスキップすることによって動作を削減してもよい。システムプロセッサが過負荷でない場合、システムプロセッサは、プロセス９００のように、同じ電力認識適応論理を適用して、全長再生提供してもよい。図９に示していないが、システムが過負荷になった場合、クライアントは、複雑度レベルを下方に切り替える前に、ビットレートを下方に切り替えてもよい。例えば、クライアントは、最小複雑度レベルＣＬ_MINに到達する前に、より低いビットレートに切り替えてもよいし、またはクライアントは、複雑度レベルを無視して、より低いビットレートに切り替えるだけでもよい。

【0054】

省電力モードにおいて、クライアントは、最低ビットレートにおける最低複雑度レベルを選択して、ビデオ再生中の電力消費を最小にすることができる。全長再生のための残電力が十分でない場合、クライアントは、本明細書で説明したような、追加的な省電力復号化モードを適用することをデコーダに通知してもよい。

【0055】

複雑度を十分に削減することができないことがある、利用可能なより低い複雑度およびより低いビットレートのコンテンツバージョンに切り替える場合、図８および図９の論理内で追加的な省電力モードが使用されてもよい。例えば、一部の内部ループフィルタリングがスキップされてもよく、プロセッサの切り替え頻度が削減されてもよく、表示電力が削減されてもよく、一部のフレームの復号化がスキップされてもよい、などである。

【0056】

適応決定は、残りのバッテリレベル、異なる複雑度レベルおよびビットレートにおけるマルチメディアコンテンツセグメントの利用可能性、ならびに／またはデコーダデバイスによって追跡される電力散逸状態などの、因子に基づいてもよい。例えば、デコーダデバイスは、式（１）に従って電力散逸状態を追跡してもよい。結果として生じる電力散逸状態ＰＤＲ（ｋ，ｔ_j）は、いくつかの複雑度レベルｋに対して予測することができる電力散逸率のデバイス固有の理解を提供することができる。

【0057】

電力散逸状態は、ＷＴＲＵなどの、デコーダデバイスによって追跡、維持、および使用されてもよい。異なるコンテンツプロバイダまたはコンテンツソースは、複雑度を推定する異なるアルゴリズムを使用してもよい。１つのコンテンツソースからシグナリングされた複雑度レベル値は、異なるコンテンツソースからシグナリングされた複雑度レベルとは異なる電力散逸率にマッピングされてもよい。デコーダデバイスは、これを認識してもよく、および複雑度を推定する異なるアルゴリズムの使用に適応してもよい。

【0058】

デコーダデバイスによって観察される電力散逸データが疎らである（sparse）ことがあり、例えば、所与の複雑度レベルにおいて観察可能なデータがあまりないことがある。これは、例えば、ストリーミングセッションの開始時に（例えば、電力散逸状態が十分に観察されたデータを使用して更新される前に）真となり、およびコンテンツプロバイダが複雑度レベル値を細かい粒度、例えば、複雑度レベル（ＣＬ）＝１，２，３，…５００でシグナリングする場合に常に真となることがある。

【0059】

デコーダデバイスは、状態追跡（state tracking）が制限されたメモリを有することがある。デコーダデバイスは、電力散逸状態をさらに正確に追跡する間に状態メモリを管理することができる。

【0060】

図１０は、デコーダデバイス１１０２、例えば、ＷＴＲＵ、が複数の異なるコンテンツソース１１０４、１１０６、１１０８、１１１０からメディアコンテンツをストリームすることができる例示的なシステム１１００を示している。これらのコンテンツソースは、異なるコンテンツウェブサイト、コンテンツプロバイダ、コンテンツサービスなどであってよい。例えば、第１のソース１１０４は、ＹｏｕＴｕｂｅ（登録商標）であってよく、第２のソース１１０６は、ＣＮＮ（登録商標）Ｖｉｄｅｏであってよい。本明細書で説明されるように、異なるコンテンツソースは、異なる複雑度レベルおよび／または異なるビットレートにおけるコンテンツの複数のバージョンを提供することができる。利用可能なコンテンツバージョンに対し、複雑度レベル推定が提供されてもよい。異なるコンテンツソースからのメディアコンテンツは、異なるエンコード化ツールを使用してエンコードされていてもよい。例えば、ソース１１０４は、第１のビデオエンコーダを使用してエンコードされたコンテンツを提供してもよく、ソース１１０６は、第２のビデオエンコーダを使用してエンコードされたコンテンツを提供してもよい。異なるエンコード化ツールは、例えば、異なるエンコーダベンダーによって提供されてもよい。

【0061】

複雑度推定アルゴリズムは、コンテンツソースにわたって標準化されてもよい。しかしながら、本明細書で開示されるように、デコーダデバイスは、シグナリングされたさまざまな複雑度レベルにおいてビデオを再生するときに、デコーダデバイス自身によるバッテリ使用量の観察に基づいて電力散逸状態を追跡することができる。これによって、デコーダが電力散逸性能を考慮して、異なる復号化リソースに対する複雑度レベルを解釈することが可能になる。コンテンツソースによって使用される複雑度推定アルゴリズムは、コンテンツソースにわたって標準化されなくてもよい。コンテンツソースは、自身の要求に基づいて、複雑度推定アルゴリズムをカスタマイズすることができ、ならびに複雑度推定アルゴリズムはまた、時間にわたって変更および改善されてもよい。デコーダデバイスは、複雑度推定アルゴリズムの変更に適応することができる。

【0062】

異なるコンテンツソースは、異なる複雑度推定アルゴリズムを使用して生成される複雑度レベル推定を提供することができる。１つのコンテンツソースによって提供される複雑度推定レベルは、異なるコンテンツソースによって提供される複雑度レベル推定との互換性を有さなくてもよい。例えば、第１のコンテンツソースは、１から１０の整数を使用して複雑度レベル推定を提供することができ、そして第２のコンテンツソースは、１から１００の整数を使用して複雑度レベル推定を提供することができる。異なる値範囲または複雑度スケールによって非互換性が生じることがあるが、他のアルゴリズムの差異も、１つのコンテンツソースからの複雑度推定を、別のコンテンツソースからの複雑度推定と互換性を有しなくさせることがある。例えば、１つのコンテンツソースは、複雑度推定値を生成するとき、特定の重み付けを加算演算に与え、および異なる重み付けを乗算演算に与えてもよい。別のコンテンツソースは、複雑度推定に対する専用の復号化ハードウェアの利用可能性の因子（factor in the availability of specialized decoding hardware to the complexity estimate））であってもよい。デコーダデバイスの観点から、第１のコンテンツソースによってシグナリングされる複雑度レベル値（例えば、“ＣｏｍｐｌｅｘｉｔｙＬｅｖｅｌ＝１”）は、１つの電力散逸率に対応してもよく、および第２のコンテンツソースによってシグナリングされる同じ複雑度レベル値は、異なる電力散逸率に対応してもよい。

【0063】

デコーダデバイス１１０２は、異なるコンテンツソースによって使用することができる異なる複雑度推定アルゴリズムに対応することができる複数の状態の組を追跡してもよい。図１０に示すように、デコーダデバイス１１０２は、複数の状態の組１１１２を有してもよく、および複数の状態の組１１１２を生成および管理するために使用することができる状態マネージャコンポーネント１１１４を有してもよい。複数の状態の組は、広告された異なる複雑度レベルにおいてビデオのさまざまなセグメントを復号する間、電力散逸の観察から計算された電力散逸状態の組を備えてもよい。例えば、状態の組は、式（１）を使用して計算される電力散逸状態ＰＤＲ（ｋ，ｔ_j）を有してもよい。状態の組は、単一のストリーミングセッションの間に観察される電力散逸データから構築されてもよく、または複数のストリーミングセッションにわたって観察されるデータから構築されてもよい。簡潔にするために、ｔ_jは、表記ＰＤＲ（ｋ，ｔ_j）から省略されてもよく、したがって、表記ＰＤＲ（ｋ）は、複雑度レベルｋの最新の電力散逸率状態を表してもよい。

【0064】

状態の組は、異なるコンテンツソースに対応してもよい。例えば、図１０に示すように、デコーダデバイスは、コンテンツソースに対する異なる状態の組を維持してもよい。異なる状態の組は、異なるコンテンツウェブサイト、コンテンツプロバイダ、またはコンテンツサービスに対応してもよい。例えば、デコーダデバイスは、ドメイン名を使用してコンテンツソースを区別する（例えば、ｙｏｕｔｕｂｅ．ｃｏｍ対ｃｎｎ．ｃｏｍ）ことができ、およびコンテンツをそこからストリームすることができる各ドメインに対し異なる状態の組を維持することができる。互換性を有する観察を適切な状態の組に収集することができるように、状態の組は複数のストリーミングセッションにわたって維持されてもよい。この技術は、データの疎らさ（sparsity）の問題を解決することができ、およびデコーダデバイスが、すでに開発されている状態モデルでのストリーミングセッションを開始することを可能にする。

【0065】

デコーダデバイス１１０２は、コンテンツをＹｏｕＴｕｂｅからストリームすることができる第１のストリーミングセッションを有してもよい。それに応じて、状態マネージャ１１１４は、新しい状態の組を生成および初期化してもよく、状態の組は、さまざまなコンテンツセグメントに対してＹｏｕＴｕｂｅによって提供される複雑度レベルラベルを考慮して電力散逸率の観察に基づいて漸次更新されてもよい。電力散逸状態は、例えば、式（１）を使用して第１のストリーミングセッションの間に更新されてもよい。デコーダデバイスは、第１のストリーミングセッションを終了させてもよく、および他のコンテンツサイトとの他のストリーミングセッションに従事してもよく、結果として追加的な（例えば、別個の）状態の組が生成または更新されることになる。デコーダデバイスは、コンテンツをＹｏｕＴｕｂｅからストリームすることができる第２のストリーミングセッションを有してもよい。デコーダデバイスは、ＹｏｕＴｕｂｅに対する状態の組が存在することを認識することができる。例えば、デコーダデバイスは、新しいストリーミングセッションからのドメイン名（ｙｏｕｔｕｂｅ．ｃｏｍ）を、既存の状態の組と関連付けられた同じドメイン名と一致させてもよい。この認識／一致に基づいて、デコーダデバイスは、既存のＹｏｕｔｕｂｅの状態の組を第２のストリーミングセッションに利用することができる。例えば、デコーダデバイスは、既存の状態の組からの発展した電力散逸状態を有する第２のストリーミングセッションを開始してもよい。デコーダデバイスは、このような以前に記憶された電力散逸状態を使用して、第２のストリーミングセッションの開始から適応決定を推進（drive）することができる。デコーダデバイスは、第２のストリーミングセッションからの電力散逸率の観察を使用して、例えば、式（１）に基づいて、既存の状態の組を漸次更新してもよい。

【0066】

状態の組は、コンテンツソースに関わらず、異なる複雑度推定アルゴリズムに対応してもよい。例えば、第１のコンテンツソースは、Ａｃｍｅ Ｅｎｃｏｄｅｒ ｖ１．０などの、第三者エンコード化ツールを使用してエンコードされたコンテンツを提供することができ、このエンコード化ツールは、それがエンコード化するビデオセグメントの複雑度を推定するビルトインアルゴリズムを有してもよい。第２のコンテンツソースは、同じ第三者エンコード化ツールを使用してエンコードされた異なるコンテンツを提供することができる。第１のコンテンツソースおよび第２のコンテンツソース（例えば、２つの異なるコンテンツソース）は、第三者エンコード化ツールに組み込まれた複雑度推定アルゴリズムなどの、同じ複雑度推定アルゴリズムによって生成された複雑度レベル推定を提供することができる。識別子、例えば、複雑度推定識別子（ＣＥＩＤ）は、復号化デバイスが異なる複雑度推定アルゴリズムを区別することができるように、複雑度レベル推定とともに復号化デバイスに提供されてもよい。復号化デバイスは、コンテンツソースに関わらず、それが直面する（encounter）ことがある異なる複雑度推定アルゴリズム毎に異なる状態の組を生成および／または保持してもよい。

【0067】

ＣＥＩＤは、例えば、複雑度推定アルゴリズムを識別する識別文字列または識別番号であってもよい。ＣＥＩＤは、登録機関によって割り当てられてもよい。代わりに、ＣＥＩＤは、複雑度推定アルゴリズムのプロバイダによって生成、割り当て、またはランダムに作成されてもよい。例えば、プロバイダは、識別文字列、例えば、「Ａｃｍｅ－ＣＥＩＤ－Ｖｅｒｓｉｏｎ－１－０．５」、またはグローバル一意識別子（ＧＵＩＤ）番号、例えば、「１３８２９４５７８３２１」を作成して、Ａｃｍｅビデオエンコード化ソフトウェアの特定のバージョンによって提供される複雑度推定を区別することができる。このようなＧＵＩＤ番号は、ランダムであってもよい。プロバイダは、そのソフトウェアの異なるバージョンによって提供される複雑度推定を区別するために、異なる識別文字列または異なる乱数を提供することができる。コンテンツソースがＣＥＩＤを複雑度レベル推定値とともにデコーダデバイスにシグナリングすることができるように、プロバイダは、エンコード化ソフトウェアを使用するコンテンツソースに対しＣＥＩＤを使用可能にしてもよい。これは、自動化された方法で行われてもよい。例えば、エンコーダソフトウェアのバージョンは、そのソフトウェアに組み込まれた複雑度レベル推定アルゴリズムに対応するＣＥＩＤを認識することができ、ソフトウェアは、コンテンツをエンコードするときに複雑度レベル推定に従ってＣＥＩＤを出力することができる。ソフトウェアは、エンコードされたコンテンツを広告するＭＰＤファイルに含ませる生データを作成する能力ことが可能であり、またはＭＰＤ自体を作成することが可能である。ソフトウェアによって生成されるデータまたはＭＰＤは、複雑度レベル推定に加え、ＣＥＩＤをも含んでもよい。フィールド（例えば、ｃｏｍｐｌｅｘｉｔｙＥｓｔｉｍａｔｉｏｎＡｌｇ＝「Ａｃｍｅ－ＣＥＩＤ－Ｖｅｒｓｉｏｎ－１－０．５」）は、ＭＰＤ内または別の適したシグナリングチャネル内でＣＥＩＤを搬送することができる。

【0068】

デコーダデバイスは、異なるコンテンツソースからコンテンツをストリームするとき、同じＣＥＩＤを認識することができ、そのようなコンテンツと関連付けられた複雑度レベル推定値が、同じ複雑度推定アルゴリズムによって生成されたことを認識することができ、および同じ状態の組を、広告された同じＣＥＩＤを有するコンテンツに利用することができる。

【0069】

デコーダデバイスは、コンテンツソースから利用可能な一部のコンテンツが、第１のＣＥＩＤに対応する第１の複雑度推定アルゴリズムを使用して生成されていてもよいこと、および同じコンテンツソースから利用可能な他のコンテンツが、第２のＣＥＩＤに対応する第２の複雑度推定アルゴリズムを使用して生成されていてもよいことを認識することができる。デコーダデバイスは、２つの異なるＣＥＩＤに対応するコンテンツに対する電力散逸率を追跡するために２つの異なる状態の組を使用してもよい。例えば、コンテンツサイトは、そのエンコード化ソフトウェアおよび／またはその複雑度推定アルゴリズムをある日付に更新して、それによって、その日付の前にエンコードされたコンテンツが、１つのＣＥＩＤと関連付けられるようになし、およびその日付の後にエンコードされたコンテンツが異なるＣＥＩＤと関連付けられるようになる。デコーダデバイスは、２つの明確に異なる（distinct）ＣＥＩＤを認識することができ、および２つの異なるＣＥＩＤに対応する２つの異なる状態の組を維持することができる。

【0070】

デコーダデバイスは、状態の組と関連付けられているとそのデコーダデバイスが認識するＣＥＩＤと直面するとき、状態の組を利用することができる。デコーダデバイスがストリーミングの間に直面するＣＥＩＤに対応する状態の組を有していない場合、そのデコーダデバイスは、新しく直面したＣＥＩＤと関連付けられた状態の組を生成してもよい。

【0071】

デコーダデバイス、例えば、デコーダデバイス上の状態マネージャは、デコーダデバイスが追跡する状態の組の数を削減するまたは制限する管理機能を有してもよく、および／またはそれを使用してもよい。例えば、管理機能は、状態の組がある期間の間に使用されなかった（例えば、２週間使用されなかった）とき、または状態の組がほとんど使用されていない（例えば、３か月期間に２回以下の使用）ときを検出することができる。これは、例えば、コンテンツソースが人気のあるコンテンツソースではない場合、またはデコーダデバイスのユーザが特定のコンテンツソースから頻繁にストリームしない場合に当てはまる。これはまた、例えば、ＣＥＩＤに対応する複雑度推定アルゴリズムが、デコーダデバイスが直面する可能性が高いコンテンツソースによってほとんど使用されない場合も当てはまる。管理機能は、使用されていない、またはほとんど使用されていない状態の組を削除することができ、よって、デコーダデバイスのメモリを節約することができる。

【0072】

デコーダデバイスは、そのデコーダデバイスが追跡することができる状態の組の数、および／またはそのデコーダデバイスが状態の組を追跡するために使用することができるメモリの量を制限（例えば、上限）してもよい。管理機能は、このような制限を超えるときを検出することができ、および１または複数の状態の組を削除して、状態の組または状態の組を記憶するために使用されるメモリの数を制限内に戻すことができる。状態の組は、逆の優先順序に基づいて削除されてもよく、例えば、最小頻度で使用される状態の組が最初に削除されてもよい。

【0073】

状態の組メモリを削減するための状態の組の削除は、ストリーミングセッションの間に実行されてもよい。例えば、ストリーミングセッションが状態の組の生成に関与し、および状態の組の生成によってデコーダデバイスが状態の組の最大数を超える場合、ストリーミングセッションの間に管理機能が呼び出されて、最低優先度の（例えば、最小頻度で使用される）既存の状態の組を削除して、新しい状態の組の場所を確保してもよい。状態の組の削除は、各ストリーミングセッションの間、またはアイドル期間の間に実行されてもよい。

【0074】

デコーダデバイスは、後のストリーミングセッションに有益となることがある状態の組を削除してもよい。デコーダデバイスは、状態の組を生成してもよく、およびストリーミングセッションの開始時に電力散逸状態の追跡を開始してもよい。この場合、既存の状態の組を使用する利点を失うことがあるが、システムは、さらに機能することができ、新しく生成された状態の組に基づいて適応決定を行うことが可能になる。

【0075】

状態の組は、日和見的に統合されてもよい。デコーダデバイスは、２つの状態の組を統合することができるように、その状態の組が同一であることを検出してもよい。例えば、２以上のコンテンツソースは、同じ複雑度レベル推定アルゴリズムを使用してもよいが、ＣＥＩＤを広告しなくてもよく、それによって、デコーダデバイスは、複雑度レベル推定アルゴリズムが同じであることをトップレベルのシグナリングによって知らせることができない場合もある。デコーダデバイスは、２つの状態の組を比較してもよく、および類似度を判定してもよい。類似度が判定される場合、デコーダデバイスは、２つの状態の組を統合し、およびデコーダデバイスによって維持されている状態の組の全体数を削減してもよい。状態の組にわたる類似度の検出は、さまざまな因子に基づいてもよい。

【0076】

状態の組は、評価または比較が可能となるのに十分進化されてもよい。例えば、デコーダデバイスは、状態の組を構築するために使用される電力散逸観察の数、または状態の組を構築するために観察される総再生時間を追跡してもよい。デコーダデバイスは、閾値を適用して、比較に十分成熟した（mature）状態の組を考慮してもよい。閾値は、状態の組に対してグローバルであってもよい。例示的な閾値は、状態の組が少なくとも８分のビデオ再生を使用して更新されたときに比較が可能となるのに十分成熟することがある閾値であってもよい。閾値は、電力散逸状態毎に適用されてもよい。例示的な閾値は、電力散逸状態ＰＤＲ（ｋ）が少なくとも５つのビデオ再生セグメントに基づいて更新されると、比較を可能にするのに十分成熟した閾値であってもよい。

【0077】

状態の組は、評価または比較が可能となる互換性のある複雑度レベル値を有してもよい。例えば、第１の状態の組は、ｋ∈｛１，２，３，…１０｝を有するＰＤＲ（ｋ）に対する状態を有するように進化されてもよい。第１の状態の組は、第２の状態の組と比較されてもよく、第２の状態の組もｋ∈｛１，２，３，…１０｝を有するＰＤＲ（ｋ）に対する状態を有するように進化されてもよい。第１の状態の組を、ｋ∈｛２０，２５，３０，３５，４０，４５，５０｝を有するＰＤＲ（ｋ）に対する状態を有するように進化されていてもよい第３の状態の組と比較することは困難である。シグナリングされた複雑度レベル値の異なる組または異なる範囲に基づいて２つの状態の組が生成される場合、基礎となる複雑度推定アルゴリズムは、直接には互換性がないことがある。図７に示していないが、追加的なシグナリングは、ＭＰＤに追加されてもよく、ならびに／または外部／代替的手段を介して送信されて、サーバおよび／もしくはエンコーダによって使用される複雑度レベル値の全範囲を表示してもよい。これによってデバイスが、異なるコンテンツソース、サーバ、および／またはエンコーダによって使用される複雑度レベル値の全範囲をより容易に検出することが可能になり（例えば、複数のビデオセグメントにおける複雑度レベルの複数の観察を行わなければならない代わりに）、ならびに異なるコンテンツソース、サーバ、および／またはエンコーダによって使用される基礎となる複雑度推定アルゴリズムの類似度をより容易に評価することが可能になる。ＣＥＩＤが使用される場合、複雑度レベルの全範囲は、各ＣＥＩＤとともにシグナリングされてもよい。

【0078】

状態の組は、適切な比較基準を使用して比較されてもよい。両方の状態の組が比較のために十分進化することができ、および両方の状態の組が互換性のある複雑度レベル値を有することができる状態の組のペアの場合、状態の組は、比較基準を使用して比較されてもよい。例えば、電力散逸状態はベクトル形式にされてもよく、および２つの状態ベクトルの間の差のノルムを計算してもよい。ノルムは、例えば、Ｌ¹ノルムまたはＬ²ノルムであってもよい。差のノルムは、閾値と比較されてもよく、およびノルムが閾値より未満である場合、２つの状態の組は、その状態の組を統合することができるのに十分に同一であると見なされる。他の比較基準が使用されてもよい。例えば、デコーダデバイスは、１つの状態の組と別の状態の組とに対応する状態間の差を計算してもよく、および２つの状態の組が統合するのに十分に同一であるかを判定するために、この基準を閾値と比較してもよい。

【0079】

一部の例では、状態の組は、状態の組の一部の状態が、まだデータ観察を有しておらず、またはシグナルされた複雑度レベルにおける電力散逸に対して信頼できる基準と見なされるにはデータ観察が不十分であるという可能性を考慮するために、シグナリングされた複雑度レベル値の異なる組または異なる範囲に基づいて生成されるかを比較されてもよい。例えば、状態の組は、ｋ∈｛１，２，３，４，５，７，８，９，１０｝を有するＰＤＲ（ｋ）に対する成熟した状態値を有してもよいが、ｋ＝６に対する状態を更新するデータが不十分であり、またはそのようなデータを有しないことがある。データなしの状態を有しているにも関わらず、残りの成熟した状態は、他の状態の組との比較を可能にする状態の組を十分に特徴付けることができる。

【0080】

このような場合、状態の組は、他の状態の組と比較されてもよい。例えば、成熟していないことがある状態、または２つの状態の組のいずれかが比較において利用可能でない状態は、比較から除去されてもよく、および成熟した対応する状態（例えば、閾値によって判定されるときの、データの最小量などの、少量のデータを使用して更新された）は、類似度を判定するために比較されてもよい。例えば、ｋ＝６に対する状態が、第１の状態の組において成熟していない、または使用可能でないと判定される場合、第１の状態の組は、両方の状態の組からｋ＝６に対する状態値を除去することによって、と第２の状態の組と比較されてもよく、および比較基準（例えば、削減された状態の組ベクトルの間の差のＬ²ノーム）を使用して、結果として削減された状態の組を比較する。状態の組において成熟していない状態、または利用可能でない状態は、同じ状態の組において成熟していることがある隣接状態から補間（interpolated）されてもよい。例えば、欠損したまたは未成熟な状態を埋めて、別の状態の組との完全な比較を可能にするために、線形補間が使用されてもよい。

【0081】

デコーダデバイスが、状態の組の（例えば、本明細書で開示されたような）間の十分な類似度を判定する場合、デコーダデバイスは、その状態の組を統合してもよい。これは、メモリを節約することができる、デコーダデバイスによって追跡される状態の組の総数を削減することができる。

【0082】

統合されることになる２つの状態の組の状態に対するデータは、統合された状態の組の対応する状態を生成するために平均化されてもよい。これは、単純平均として行われてもよく、または重み付け平均、例えば、
ＰＤＲ_merged（ｋ）＝Ａ×ＰＤＲ₁（ｋ）＋Ｂ×ＰＤＲ₂（ｋ）
として行われてもよい。

【0083】

重みＡおよびＢによって、コンポーネントの状態の組を構築するためにどのくらいのデータが使用されたかに基づく重み付けが可能となる。例えば、ＰＤＲ₁（ｋ）に対応する第１の状態の組を構築および更新するために２８分のビデオデータが使用された場合、ならびにＰＤＲ₂（ｋ）に対応する第２の状態の組を構築および更新するために１２分のデータが使用された場合、その重みは、総データの一部として計算され、例えば、Ａは、２８／（２８＋１２）＝０．７であってもよく、およびＢは、１２／（２８＋１２）＝０．３であってもよい。

【0084】

統合された状態の組は、統合されたコンポーネントの状態の組に有効であったコンテキストと関連付けられてもよい。例えば、ＹｏｕＴｕｂｅに対応する第１の状態の組は、ＣＮＮビデオに対応する第２の状態の組と統合される場合、結果として統合された状態の組は、ＹｏｕＴｕｂｅおよびＣＮＮビデオの両方と関連付けられてもよい。状態の組は、例えば、ドメイン名、コンテンツサービス名もしくは識別子、および／または本明細書で開示されたようなＣＥＩＤを介して、コンテキストと関連付けられてもよい。統合された組は、複数の統合の結果となることがある、そのような２以上のコンテキストに対応してもよい。統合された状態の組が生成され、および適切なコンテキストと関連付けられるとき、統合に寄与したコンポーネントの状態の組が削除されてもよい。

【0085】

デコーダデバイスまたはその状態マネージャは、ストリーミングセッションの間に状態の組の比較および統合を実行してもよい（例えば、使用中の現在の状態の組に応答して、それが比較に十分に成熟することができる時点まで、または統合されることになる別の既存の状態の組にそれが十分同一とすることができる時点まで進化する）。比較および統合は、アクティブなストリーミングセッションの外側で、例えば、維持作業（housekeeping activity）として定期的に、またはアイドル期間の間に行われてもよい。

【0086】

状態の組の統合は、全体的な状態の組のメモリ要件を削減でき、そしてデコーダデバイスによって追跡することができる明確に異なる状態の組の数を削減することができる。２以上の同様の状態の組からのデータを組み合わせることによって、データが疎らの問題を解決することができる。

【0087】

ＰＤＲ状態は、量子化されてもよい。式（１）によって説明された状態追跡技術は、コンテンツソースによってシグナルすることができる複雑度レベルｋに状態を割り当ててもよい。例えば、コンテンツソースがｋ∈｛１，２，３，…１０｝を有する複雑度レベルｋにシグナリングする場合、状態の組は、１０の対応する値、ｋ∈｛１，２，３，…１０｝を有するＰＤＲ（ｋ）で生成される。コンテンツソースが複雑度レベルの細かい粒度（例えば、ｋ∈｛１，２，３，…１０００｝を有する複雑度レベルｋ）を使用することがある場合、可能な複雑度レベルに対する状態の追跡は、その状態の組の追跡に使用されるメモリを増加させることがあり、その結果としてデータの疎ら問題が生じることもある。例えば、デコーダデバイスは、複雑度レベルにおいて対応する電力散逸状態を信頼性できるように計算するために十分なデータを確かめることができないことがある。

【0088】

デコーダデバイスは、複雑度レベル間隔（space）をいくつかの明確に異なるビン（discrete bin）に量子化できる。ビンは、電力散逸率状態に対応することができる。複数の隣接複雑度レベルからのデータ観察は、ビンに供給されてもよく、および状態の組の記憶サイズおよび追跡複雑度は、削減されるおよび／または制限されることがある。

【0089】

図１１は、複雑度レベルを量子化する例を示している。図１１に示すように、コンテンツソースによってシグナリングすることができる複雑度レベル１２０２は、ＣＬ_minからＣＬ_maxまでの範囲となる。デコーダデバイスは、この範囲を１２０４、１２０６、１２０８、１２１０、および１２１２におけるなどの、いくつかのビンに分割することができる。図１１は、５つのビン１２０４、１２０６、１２０８、１２１０、１２１２の例を示しているが、これよりも多いまたは少ないビンが使用されてもよい。例えば、より大きい数（例えば、１０ビンまたは２０ビン）ビンを使用して、複雑度レベルと電力散逸率との間の関係を特徴付けることができる。

【0090】

デコーダデバイスは、シグナリングされる複雑度レベルＣＬと関連付けられたビデオセグメントを要求および／または受信してもよい。ビデオセグメントを再生する間、デコーダデバイスは、バッテリレベルの変更を観察することができ、および／またはビデオセグメントの再生の電力散逸率を計算することができる。図１１に示すように、デコーダデバイスは、シグナリングされた複雑度レベルを適切なビンにマッピングすることができる。デコーダデバイスは、観察されたバッテリレベルおよび／または計算された電力散逸率を使用して、マッピングされたビンに対応する電力散逸率状態を更新することができる。更新は、シグナリングされた複雑度レベルＣＬを、マッピングされたビンｋに適切にマッピングする、式（１）に従って行われてもよい。

【0091】

少数の状態を有する状態の組（例えば、図１１に示すような５つの状態）は、コンテンツソースによってシグナリングされる複雑度レベルに対するより高密度（dense）の組から生成されてもよい。この小さい状態の組からの値ＰＤＲ（ｋ）は、ビンｋの中央の複雑度レベル（ＣＬ）値の電力散逸率に対応することができる。これは、図１１のビンの中央における白円１２１４、１２１６、１２１８、１２２０、１２２２によって示される。値ＰＤＲ（ｋ）を使用して、ビンの中央に対応する電力散逸率を予測することができる。ＣＬの他の値に対応する電力散逸率を予測するために、補間が使用されてもよい。例えば、線形補間または多項式補間を使用して、ＰＤＲ（ｋ）の隣接値の間で補間することができる。削減された状態の組を使用して、ＣＬの任意にシグナリングされた値に対する電力散逸率を予測することができ、および削減された状態モデルを使用して、適応決定を駆動することができる。図１１に示していないが、複雑度レベル値の全範囲の非一様な量子化が使用されもよい。例えば、より細かい量子化を中央の複雑度レベル値に適用することができ（すなわち、中央のビンは、少数の複雑度レベル、例えば、図示した６個の複雑度レベルではなく３個の複雑度レベル値にマッピングされてもよい）、および粗い量子化を左側／右側の複雑度レベル値に適用することができる（すなわち、左側／右側のビンは、より大きい数の複雑度レベル、例えば、図示した６個の複雑度レベルではなく９個の複雑度レベル値に及んでもよい（span））。

【0092】

ビン分割器（divider）に対する複雑度値の調節は、削減された状態の組モデルが使用されることがあるときに、バイアスを導入されて電力散逸率を更新することができる。複雑度レベルの使用の頻度は、バイアスを取り入れることがある。例えば、図１２に示すように、ビン１３０６の端１３０４近くに配列されたシグナルされた複雑度レベル１３０２は、削減された状態の組の進化の間に頻繁に再生される、ビン１３０６範囲内の他のシグナリングされた複雑度レベル１３０８は、あまり頻繁に再生されない。ビン１３０６を表現するために使用されるデータは、ビン１３０６の片側にバイアスされ、その結果となる状態値ＰＤＲ（ｋ）は、ビン１３０６のコンテンツを正確に表現しないことがある。

【0093】

このバイアスのソースを削減または消去するために、バッテリレベルの変更または電力散逸の観察または計算された値は、電力散逸率状態ＰＤＲ（ｋ）を更新するためにこのような値を使用する前に、ビンｋの中央に対応する同等値に再マッピングされてもよい。例えば、デコーダデバイスは、複雑度レベルＣＬ、および元の複雑度レベル間隔に対応する電力散逸率ＰＤＲ_orig（ＣＬ）の観察を記憶してもよい。図１３に示すように、デコーダデバイスは、（ＣＬ，ＰＤＲ_orig（ＣＬ））の隣接値１４０２、１４０４の間で補間をして、ビンｋの中央に対応する電力散逸率のマッピングされた値１４０６を判定するために補間を使用してもよい。このマッピングされた電力散逸率を使用して、削減された状態の組のビンｋに対応する電力散逸率状態、ＰＤＲ（ｋ）を更新してもよい。

【0094】

図１３は、線形補間の使用を示しているが、他のタイプの補間（例えば、多項式補間など）も使用されてもよい。補間を使用して、元の電力散逸率をビンの中央における同等率（equivalent rate）に再マッピングしてもよい。例えば、デコーダデバイスは、電力散逸観察と隣接ビンの電力散逸率状態値との間で補間してもよい。図１３において、これは、補間の右側の（ＣＬ₂，ＰＤＲ_orig（ＣＬ₂））を、隣のより高いビンの中央における同等の複雑度レベルおよび電力散逸率に対応する、（ＣＬ_equiv（ｋ＋１），ＰＤＲ（ｋ＋１））との置換に対応する。補間は、現在の複雑度レベル観察ＣＬ₁がビンｋの中央のそれぞれ、左または右であるかどうかに応じて、隣のより高いビン（例えば、ｋ＋１）または隣のより低いビン（例えば、ｋ－１）のいずれかを使用して行われてもよい。ビンｋの中央の再マッピングは、複数の電力散逸率値を記憶しないで実行されてもよい。

【0095】

デコーダデバイスは、同数に削減された状態の組Ｎを有する複数の削減された状態の組を発展させるための、本明細書で開示されるアプローチを使用することができる。例えば、デコーダデバイスは、複数の状態の組（例えば、異なるコンテンツソースに対応する）を生成および保持してもよく、状態の組は、状態値ＰＤＲ（ｋ），ｋ∈｛１，２，３，…Ｎ｝を備える、削減された状態の組であってもよい。状態の組が、複雑度レベルｋの同じ削減された組に基づいてもよいので、状態の組を、統合のためにより容易に比較することができる。次数Ｎの削減された状態の組の状態の組のペアは、互換性を有する複雑度レベル値を有してもよく、その値は、評価または比較を可能にする。比較を可能にする十分に成熟したデータを有することができる、次数Ｎの削減された状態の組のペアに対し、潜在的統合に対する比較が実行されてもよい。

【0096】

図１４Ａは、開示された１または複数の実施形態を実装することができる例示的な通信システム１００の図である。通信システム１００は、音声、データ、ビデオ、メッセージング、ブロードキャストなどのコンテンツを複数の無線ユーザに提供する、多元接続システムであってよい。通信システム１００は、複数の無線ユーザが、無線帯域幅を含むシステムリソースの共有を通じてそのようなコンテンツにアクセスすることを可能にする。例えば、通信システム１００は、符号分割多元接続（ＣＤＭＡ）、時分割多元接続（ＴＤＭＡ）、周波数分割多元接続（ＦＤＭＡ）、直交ＦＤＭＡ（ＯＦＤＭＡ）、シングルキャリアＦＤＭＡ（ＳＣ－ＦＤＭＡ）などの、１または複数のチャネルアクセス方法を採用してもよい。

【0097】

図１４Ａに示すように、通信システム１００は、無線送信／受信ユニット（ＷＴＲＵ）１０２ａ、１０２ｂ、１０２ｃ、および／または１０２ｄ（ＷＴＲＵ１０２と総称されてもよい）、無線アクセスネットワーク（ＲＡＮ）１０３／１０４／１０５、コアネットワーク１０６／１０７／１０９、公衆交換電話網（ＰＳＴＮ）１０８、インターネット１１０、および他のネットワーク１１２を含んでもよいが、開示された実施形態は、任意の数のＷＴＲＵ、基地局、ネットワーク、および／またはネットワーク要素を意図することが認識されよう。ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのそれぞれは、無線環境で動作および／または通信するように構成された任意のタイプのデバイスであってよい。一例として、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、無線信号を送信および／または受信するように構成されてもよく、ユーザ機器（ＵＥ）、移動局、固定または移動加入者ユニット、ページャ、セルラー電話、携帯情報端末（ＰＤＡ）、スマートフォン、ラップトップ、ネットブック、パーソナルコンピュータ、無線センサ、家庭用電化製品などを含んでもよい。

【0098】

通信システム１００はまた、基地局１１４ａと基地局１１４ｂを含んでもよい。基地局１１４ａ、１１４ｂのそれぞれは、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのうちの少なくとも１つと無線でインタフェースして、コアネットワーク１０６／１０７／１０９、インターネット１１０、および／またはネットワーク１１２などの、１または複数の通信ネットワークへのアクセスを促進するように構成された任意のタイプのデバイスであってもよい。一例として、基地局１１４ａ、１１４ｂは、ベーストランシーバ基地局（ＢＴＳ）、ノードＢ、ｅノードＢ、ホームノードＢ、ホームｅノードＢ、サイトコントローラ、アクセスポイント（ＡＰ）、無線ルータなどであってよい。基地局１１４ａ、１１４ｂはそれぞれ、単一要素として示されているが、基地局１１４ａ、１１４ｂは、相互接続された任意の数の基地局および／またはネットワーク要素を含んでもよいことが認識されよう。

【0099】

基地局１１４ａは、基地局コントローラ（ＢＳＣ）、無線ネットワークコントローラ（ＲＮＣ）、中継ノードなどの、他の基地局および／またはネットワーク要素（図示せず）を含むこともできる、ＲＡＮ１０３／１０４／１０５の一部であってもよい。基地局１１４ａおよび／または基地局１１４ｂは、セル（図示せず）と称されることがある、特定の地理的領域内で無線信号を送信および／または受信するように構成されてもよい。セルは、セルセクタにさらに分割されてもよい。例えば、基地局１１４ａと関連付けられたセルは３つのセクタに分割されてもよい。従って、一実施形態において、基地局１１４ａは、３つの送受信機、すなわち、セルの各セクタに１つの送受信機を含んでもよい。別の実施形態において、基地局１１４ａは、多入力多出力（ＭＩＭＯ）技術を採用してもよく、従って、セルの各セクタに複数の送受信機を利用してもよい。

【0100】

基地局１１４ａ、１１４ｂは、任意の適切な無線通信リンク（例えば、無線周波数（ＲＦ）、マイクロ波、赤外線（ＩＲ）、紫外線（ＵＶ）、可視光線など）とすることができる、エアインタフェース１１５／１１６／１１７を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのうちの１または複数と通信してもよい。エアインタフェース１１５／１１６／１１７は、任意の適切な無線アクセス技術（ＲＡＴ）を使用して確立されてもよい。

【0101】

より詳細には、上述したように、通信システム１００は、多元接続システムであってよく、ＣＤＭＡ、ＴＤＭＡ、ＦＤＭＡ、ＯＦＤＭＡ、ＳＣ－ＦＤＭＡなどの、１または複数のチャネルアクセススキームを採用してもよい。例えば、ＲＡＮ１０３／１０４／１０５内の基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ＷＣＤＭＡ（広域帯ＣＤＭ）を使用してエアインタフェース１１５／１１６／１１７を確立することができる、ユニバーサル移動体通信システム（ＵＭＴＳ）地上波無線アクセス（ＵＴＲＡ）などの無線技術を実装してもよい。ＷＣＤＭＡ（登録商標）は、高速パケットアクセス（ＨＳＰＡ）および／または発展型ＨＳＰＡ（ＨＳＰＡ＋）などの通信プロトコルを含んでもよい。ＨＳＰＡは、高速ダウンリンクパケットアクセス（ＨＳＤＰＡ）および／または高速アップリンクパケットアクセス（ＨＳＵＰＡ）を含んでもよい。

【0102】

別の実施形態において、基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ＬＴＥ（ロングタームエボリューション）および／またはＬＴＥ－Ａ（ＬＴＥアドバンスト）を使用して、エアインタフェース１１５／１１６／１１７を確立することができる、発展型ＵＭＴＳ地上波無線アクセス（Ｅ－ＵＴＲＡ）などの無線技術を実装できる。

【0103】

他の実施形態において、基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ＩＥＥＥ８０２．１６（すなわち、Ｗｏｒｌｄｗｉｄｅ Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ ｆｏｒ Ｍｉｃｒｏｗａｖｅ Ａｃｃｅｓｓ（ＷｉＭＡＸ）、ＣＤＭＡ２０００、ＣＤＭＡ２０００１Ｘ、ＣＤＭＡ２０００ＥＶ－ＤＯ、Ｉｎｔｅｒｉｍ Ｓｔａｎｄａｒｄ ２０００（ＩＳ－２０００）、Ｉｎｔｅｒｉｍ Ｓｔａｎｄａｒｄ ９（ＩＳ－９５）、Ｉｎｔｅｒｉｍ Ｓｔａｎｄａｒｄ ８５６（ＩＳ－８５６）、Ｇｌｏｂａｌ Ｓｙｓｔｅｍ ｆｏｒ Ｍｏｂｉｌｅ ｃｏｍｍｕｎｉｃａｔｉｏｎｓ（ＧＳＭ）、Ｅｎｈａｎｃｅｄ Ｄａｔａ ｒａｔｅｓ ｆｏｒ ＧＳＭ Ｅｖｏｌｕｔｉｏｎ（ＥＤＧＥ）、ＧＳＭ ＥＤＧＥ（ＧＥＲＡＮ）などの無線技術を実装してもよい。

【0104】

図１４Ａの基地局１１４ｂは、例えば、無線ルータ、ホームノードＢ、ホームｅノードＢ、またはアクセスポイントであってよく、職場、家庭、車、キャンパスなどの、ローカルエリアで無線接続性を促進にするのに適切な任意のＲＡＴを利用してもよい。一実施形態において、基地局１１４ｂおよびＷＴＲＵ１０２ｃ、１０２ｄは、無線ローカルエリアネットワーク（ＷＬＡＮ）を確立するＩＥＥＥ８０２．１１などの、無線技術を実装してもよい。別の実施形態において、基地局１１４ｂおよびＷＴＲＵ１０２ｃ、１０２ｄは、無線パーソナルエリアネットワーク（ＷＰＡＮ）を確立するＩＥＥＥ８０２．１５などの、無線技術を実装してもよい。さらに別の実施形態において、基地局１１４ｂおよびＷＴＲＵ１０２ｃ、１０２ｄは、セルベースのＲＡＴ（例えば、ＷＣＤＭＡ、ＣＤＭＡ２０００、ＧＳＭ、ＬＴＥ、ＬＴＥ－Ａなど）を利用して、ピコセルまたはフェムトセルを確立してもよい。図１４Ａに示すように、基地局１１４ｂは、インターネット１１０に直接接続してもよい。従って、基地局１１４ｂは、コアネットワーク１０６／１０７／１０９を介してインターネット１１０にアクセスしなくてもよい。

【0105】

ＲＡＮ１０３／１０４／１０５は、音声、データ、アプリケーション、および／またはＶｏＩＰ（ボイスオーバーインターネットプロトコル）サービスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのうち１または複数に提供するように構成された任意のタイプのネットワークとすることができる、コアネットワーク１０６／１０７／１０９と通信してもよい。例えば、コアネットワーク１０６／１０７／１０９は、呼制御、課金サービス、モバイルロケーションベースのサービス、プリペイド電話、インターネット接続性、ビデオ配信などを提供してもよく、および／またはユーザ認証などのハイレベルのセキュリティ機能を実行してもよい。図１４Ａに示していないが、ＲＡＮ１０３／１０４／１０５および／またはコアネットワーク１０６／１０７／１０９は、ＲＡＮ１０３／１０４／１０５と同じＲＡＴまたは異なるＲＡＴを採用することができる、他のＲＡＴとの直接的または間接的に通信してもよいことが認識されよう。例えば、Ｅ－ＵＴＲＡ無線技術を利用することができるＲＡＮ１０３／１０４／１０５に接続されることに加えて、コアネットワーク１０６／１０７／１０９はまた、ＧＳＭ無線技術を使用した別のＲＡＮ（図示せず）と通信してもよい。

【0106】

コアネットワーク１０６／１０７／１０９はまた、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄがＰＳＴＮ１０８、インターネット１１０、および／または他のネットワーク１１２にアクセスするためのゲートウェイとして機能してもよい。ＰＳＴＮ１０８は、旧来の音声電話サービス（ＰＯＳＴ）を提供する回線交換電話網を含んでもよい。インターネット１１０は、ＴＣＰ／ＩＰインターネットプロトコルスイートにおける伝送制御プロトコル（ＴＣＰ）、ユーザデータグラムプロトコル（ＵＤＰ）およびインターネットプロトコル（ＩＰ）などの、共通の通信プロトコルを使用して相互接続されたコンピュータネットワークおよびデバイスのグローバルシステムを含んでもよい。ネットワーク１１２は、他のサービスプロバイダによって所有および／または運用される有線または無線通信ネットワークを含んでもよい。例えば、ネットワーク１１２は、ＲＡＮ１０３／１０４／１０５と同じＲＡＴまたは異なるＲＡＴを採用することができる、１または複数のＲＡＮに接続された別のコアネットワークを含んでもよい。

【0107】

通信システム１００内のＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄの一部またはすべては、マルチモード能力を含んでもよい。すなわち、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、異なる無線リンクを介して異なる無線ネットワークと通信する複数の送受信機を含んでもよい。例えば、図１４Ａに示したＷＴＲＵ１０２ｃは、セルベースの無線技術を採用することができる基地局１１４ａと、ＩＥＥＥ８０２無線技術を採用することができる基地局１１４ｂとの通信を行うように構成されてもよい。

【0108】

図１４Ｂは、例示的なＷＴＲＵ１０２のシステム図である。図１４Ｂに示すように、ＷＴＲＵ１０２は、プロセッサ１１８、送受信機１２０、送信／受信要素１２２、スピーカ／マイクロフォン１２４、キーパッド１２６、ディスプレイ／タッチパッド１２８、着脱不能メモリ１３０、着脱可能メモリ１３２、電源１３４、全地球測位システム（ＧＰＳ）チップセット１３６、および他の周辺機器１３８を含んでもよい。ＷＴＲＵ１０２は、実施形態と整合性を維持しながら、上述の要素の任意のサブコンビネーションを含んでもよいことが認識されよう。また、実施形態は、基地局１１４ａおよび１１４ｂ、ならびに／または、トランシーバ基地局（ＢＴＳ）、ノードＢ、サイトコントローラ、アクセスポイント（ＡＰ）、ホームノードＢ、発展型ホームノードＢ（ｅノードＢ）、ホーム発展型ノードＢ（ＨｅＮＢ）、ホーム発展型ノードＢゲートウェイ、およびプロキシノードを、基地局１１４ａおよび１１４ｂが表すことができるノードが、図１４Ｂおよび本明細書で説明される要素の一部またはすべてを含んでもよいことを意図する。

【0109】

プロセッサ１１８は、汎用プロセッサ、専用プロセッサ、従来型プロセッサ、デジタルシグナルプロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアと連動する１または複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、その他のタイプの集積回路（ＩＣ）、ステートマシンなどであってよい。プロセッサ１１８は、信号コーディング、データ処理、電力制御、入力／出力処理、および／またはＷＴＲＵ１０２を無線環境で動作可能にするその他の機能を実行してもよい。プロセッサ１１８は、送信／受信要素１２２に結合することができる送受信機１２０に結合されてもよい。図１４Ｂは、プロセッサ１１８および送受信機１２０を個別の構成要素として示しているが、プロセッサ１１８および送受信機１２０は、電子パッケージまたはチップ内に統合されてもよいことを認識されよう。

【0110】

送信／受信要素１２２は、エアインタフェース１１５／１１６／１１７を介して基地局（例えば、基地局１１４ａ）に信号を送信し、または基地局から信号を受信するように構成されてもよい。例えば、一実施形態において、送信／受信要素１２２は、ＲＦ信号を送信および／または受信するように構成されたアンテナであってもよい。別の実施形態において、送信／受信要素１２２は、例えば、ＩＲ、ＵＶ、または可視光信号を送信および／または受信するように構成されたエミッタ／ディテクタであってよい。さらに別の実施形態において、送信／受信要素１２２は、ＲＦ信号と光信号との両方を送受信するように構成されてもよい。送信／受信要素１２２は、無線信号の任意の組み合わせを送信および／または受信するように構成されてもよいことを認識されよう。

【0111】

さらに、送信／受信要素１２２を単一要素として図１４Ｂに示しているが、ＷＴＲＵ１０２は、任意の数の送信／受信要素１２２を含んでもよい。より詳細には、ＷＴＲＵ１０２は、ＭＩＭＯ技術を採用してもよい。従って、一実施形態において、ＷＴＲＵ１０２は、エアインタフェース１１５／１１６／１１７を介して無線信号を送受信する、２以上の送信／受信要素１２２（例えば、複数のアンテナ）を含んでもよい。

【0112】

送受信機１２０は、送信／受信要素１２２によって送信される信号を変調し、および送信／受信要素１２２によって受信された信号を復調するように構成されてもよい。上述したように、ＷＴＲＵ１０２は、マルチモード能力を有してもよく、従って、送受信機１２０は、例えば、ＵＴＲＡおよびＩＥＥＥ８０２．１１などの、複数のＲＡＴを介して、ＷＴＲＵ１０２が通信することを可能にする複数の送受信機を含んでもよい。

【0113】

ＷＴＲＵ１０２のプロセッサ１１８は、スピーカ／マイクロフォン１２４、キーパッド１２６、および／またはディスプレイ／タッチパッド１２８（例えば、液晶ディスプレイ（ＬＣＤ）ディスプレイユニットまたは有機発光ダイオード（ＯＬＥＤ）ディスプレイユニット）に結合されて、それらからユーザ入力データを受信してもよい。プロセッサ１１８はまた、スピーカ／マイクロフォン１２４、キーパッド１２６、および／またはディスプレイ／タッチパッド１２８にユーザデータを出力してもよい。さらに、プロセッサ１１８は、着脱不能メモリ１３０および／または着脱可能メモリ１３２などの、任意の適切なタイプのメモリからの情報にアクセスし、それらのメモリにデータを記憶してもよい。着脱不能メモリ１３０は、ランダムアクセスメモリ（ＲＡＭ）、リードオンリーメモリ（ＲＯＭ）、ハードディスク、またはその他のタイプのメモリ記憶デバイスを含んでもよい。着脱可能メモリ１３２は、加入者識別モジュール（ＳＩＭ）カード、メモリスティック、セキュアデジタル（ＳＤ）メモリカードなどを含んでもよい。他の実施形態において、プロセッサ１１８は、サーバまたはホームコンピュータ（図示せず）などの、物理的にＷＴＲＵ１０２に位置しないメモリから情報にアクセスし、それらのメモリにデータを記憶してもよい。

【0114】

プロセッサ１１８は、電源１３４から電力を受け取ってもよく、その電力をＷＴＲＵ１０２内の他のコンポーネントに分配および／または制御するように構成されてもよい。電源１３４は、ＷＴＲＵ１０２に電力供給する、任意の適切なデバイスであってもよい。例えば、電源１３４は、１または複数の乾電池（例えば、ニッケルカドミウム（ＮｉＣｄ）、ニッケル亜鉛（ＮｉＺｎ）、ニッケル水素（ＮｉＭＨ）、リチウムイオン（Ｌｉ－ｉｏｎ）など）、太陽電池、燃料電池などを含んでもよい。

【0115】

プロセッサ１１８はまた、ＷＴＲＵ１０２の現在の位置に関する位置情報（例えば、経緯度）を提供するように構成することができる、ＧＰＳチップセット１３６にも結合されてもよい。ＧＰＳチップセット１３６からの情報に加え、またはその代わりに、ＷＴＲＵ１０２は、基地局（例えば、基地局１１４ａ、１１４ｂ）からエアインタフェース１１５／１１６／１１７を介して位置情報を受信し、および／または２または３以上の近隣の基地局から受信される信号のタイミングに基づいてＷＴＲＵの位置を判定してもよい。ＷＴＲＵ１０２は、実施形態と整合性を維持したまま、任意の適切な位置判定方法によって位置情報を取得してもよいことを認識されよう。

【0116】

プロセッサ１１８は、付加的な特徴、機能性および／または有線または無線接続性を提供する、１または複数のソフトウェアモジュールおよび／またはハードウェアモジュールを含むことができる、他の周辺機器１３８にさらに結合されてもよい。例えば、周辺機器１３８は、加速度計、電子コンパス、衛星送受信機、デジタルカメラ（写真またはビデオ用）、ユニバーサルシリアルバス（ＵＳＢ）ポート、振動デバイス、テレビ送受信機、ハンズフリーヘッドセット、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール、周波数変調（ＦＭ）無線ユニット、デジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザなどを含んでもよい。

【0117】

図１４Ｃは、実施形態に従ったＲＡＮ１０３およびコアネットワーク１０６のシステム図である。上述したように、ＲＡＮ１０３は、ＵＴＲＡ無線技術を使用して、エアインタフェース１１５を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信してもよい。ＲＡＮ１０３はさらに、コアネットワーク１０６と通信してもよい。図１４Ｃに示すように、ＲＡＮ１０３は、エアインタフェース１１５を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するための１または複数の送受信機を含むことができる、ノードＢ１４０ａ、１４０ｂ、１４０ｃを含んでもよい。ノードＢ１４０ａ、１４０ｂ、１４０ｃのそれぞれは、ＲＡＮ１０３内の特定のセル（図示せず）と関連付けられてもよい。ＲＡＮ１０３はさらに、ＲＮＣ１４２ａ、１４２ｂを含んでもよい。ＲＡＮ１０３は、実施形態と整合性を維持したまま、任意の数のノードＢおよびＲＮＣを含んでもよいことを認識されよう。

【0118】

図１４Ｃに示すように、ノードＢ１４０ａ、１４０ｂは、ＲＮＣ１４２ａと通信してもよい。加えて、ノードＢ１４０ｃは、ＲＮＣ１４２ｂと通信してもよい。ノードＢ１４０ａ、１４０ｂ、１４０ｃは、Ｉｕｂインタフェースを介してそれぞれＲＮＣ１４２ａ、１４２ｂと通信してもよい。ＲＮＣ１４２ａ、１４２ｂは、Ｉｕｒインタフェースを介して互いに通信してもよい。１４２ａ、１４２ｂのそれぞれは、接続されているノードＢ１４０ａ、１４０ｂ、１４０ｃのそれぞれを制御するように構成されてもよい。さらに、ＲＮＣ１４２ａ、１４２ｂのそれぞれは、外側ループ電力制御、負荷制御、アドミッション制御、パケットスケジューリング、ハンドオーバー制御、マクロダイバーシティ、セキュリティ機能、データ暗号化などの、他の機能性を実行またはサポートするように構成されてもよい。

【0119】

図１４Ｃに示したコアネットワーク１０６は、メディアゲートウェイ（ＭＧＷ）１４４、モバイルスイッチングセンタ（ＭＳＣ）１４６、サービングＧＰＲＳサポートノード（ＳＧＳＮ）１４８、および／またはゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）１５０を含んでもよい。上述した要素のそれぞれは、コアネットワーク１０６の一部として示されているが、これらの要素のいずれもが、コアネットワーク通信業者以外のエンティティによって所有および／または運用されてもよいことを認識されよう。

【0120】

ＲＡＮ１０３内のＲＮＣ１４２ａは、ＩｕＣＳインタフェースを介してコアネットワーク１０６内のＭＳＣ１４６に接続されてもよい。ＭＳＣ１４６はＭＧＷ１４４に接続されてもよい。ＭＳＣ１４６およびＭＧＷ１４４は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃにＰＳＴＮ１０８などの回路交換ネットワークへのアクセスを提供して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと従来の固定電話回線による通信デバイスとの間の通信を促進することができる。

【0121】

ＲＡＮ１０３内のＲＮＣ１４２ａはまた、ＩｕＰＳインタフェースを介して、コアネットワーク１０６内のＳＧＳＮ１４８にも接続されてもよい。ＳＧＳＮ１４８はＧＣＳＮ１５０に接続されてもよい。ＳＧＳＮ１４８およびＧＣＳＮ１５０は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃにインターネット１１０などの、パケット交換ネットワークへのアクセスを提供して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとＩＰ対応デバイスとの間の通信を促進することができる。

【0122】

上述したように、コアネットワーク１０６はまた、他のサービスプロバイダによって所有および／または運用される他の有線または無線ネットワークを含むことができる、ネットワーク１１２にも接続されてもよい。

【0123】

図１４Ｄは、別の実施形態に従ったＲＡＮ１０４およびコアネットワーク１０７のシステム図である。上述したように、ＲＡＮ１０４は、Ｅ－ＵＴＲＡ無線技術を使用して、エアインタフェース１１６を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信してもよい。ＲＡＮ１０４はまた、コアネットワーク１０７と通信してもよい。

【0124】

ＲＡＮ１０４は、ｅノードＢ１６０ａ、１６０ｂ、１６０ｃを含んでもよいが、ＲＡＮ１０４は、実施形態と整合性を維持したまま、任意の数のｅノードＢを含んでもよいことを認識されよう。ｅノードＢ１６０ａ、１６０ｂ、１６０ｃはそれぞれ、エアインタフェース１１６を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するための１または複数の送受信機を含んでもよい。一実施形態において、ｅノードＢ１６０ａ、１６０ｂ、１６０ｃは、ＭＩＭＯ技術を実装してもよい。従って、ｅノードＢ１６０ａは、例えば、ＷＴＲＵ１０２ａに無線信号を送信し、およびＷＴＲＵから無線信号を受信するための複数のアンテナを使用してもよい。

【0125】

ｅノードＢ１６０ａ、１６０ｂ、１６０ｃのそれぞれは、特定のセル（図示せず）と関連付けられてもよく、ならびに無線リソース管理決定、ハンドオーバー決定、アップリンクおよび／またはダウンリンクのユーザのスケジューリングなどを処理するように構成されてもよい。図１４Ｄに示すように、ｅノードＢ１６０ａ、１６０ｂ、１６０ｃは、Ｘ２インタフェースを介して互いに通信してもよい。

【0126】

図１４Ｄに示したコアネットワーク１０７は、ＭＭＥモビリティ管理ゲートウェイ（ＭＭＥ）１６２、サービングゲートウェイ１６４、およびパケットデータネットワーク（ＰＤＮ）ゲートウェイ１６６を含んでもよい。上述した要素のそれぞれは、コアネットワーク１０７の一部として示されているが、これらの要素のいずれも、コアネットワーク通信業者以外のエンティティによって所有および／または運用されてもよいことを認識されよう。

【0127】

ＭＭＥ１６２は、Ｓ１インタフェースを介してＲＡＮ１０４内のｅノードＢ１６０ａ、１６０ｂ、１６０ｃのそれぞれに接続されてもよく、および制御ノードとして機能してもよい。例えば、ＭＭＥ１６２は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのユーザを認証すること、ベアラのアクティブ化／非アクティブ化、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃの初期接続のときに特定のサービングゲートウェイを選択することなどに関与してもよい。ＭＭＥ１６２はまた、ＲＡＮ１０４と、ＧＳＭまたはＷＣＤＭＡなどの他の無線技術を使用する他のＲＡＮ（図示せず）とを切り替える制御プレーン機能を提供してもよい。

【0128】

サービングゲートウェイ１６４は、Ｓ１インタフェースを介してＲＡＮ１０４内のｅノードＢ１６０ａ、１６０ｂ、１６０ｃのそれぞれに接続されてもよい。サービングゲートウェイ１６４は一般に、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃへの／からのユーザデータパケットをルーティングおよび転送してもよい。サービングゲートウェイ１６４は、ｅノードＢ間のハンドオーバー時にユーザプレーンをアンカリングすること、ダウンリンクデータがＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに使用可能になった時にページングをトリガすること、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのコンテキストを管理および記憶することなどの、他の機能も実行してもよい。

【0129】

サービングゲートウェイ１６４はまた、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃにインターネット１１０などの、パケット交換ネットワークへのアクセスを提供して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとＩＰ対応デバイスとの間の通信を促進にすることができる、ＰＤＮゲートウェイ１６６にも接続されてもよい。

【0130】

コアネットワーク１０７は、他のネットワークとの通信を促進することができる。例えば、コアネットワーク１０７は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃにＰＳＴＮ１０８などの回路交換ネットワークへのアクセスを提供して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと従来の固定電話回線による通信デバイスとの間の通信を促進することができる。例えば、コアネットワーク１０７は、コアネットワーク１０７とＰＳＴＮ１０８との間のインタフェースとして機能するＩＰゲートウェイ（例えば、ＩＰマルチメディアサブシステム（ＩＭＳ）サーバ）を含んでもよく、またはこれと通信してもよい。さらに、コアネットワーク１０７は、他のサービスプロバイダによって所有および／または運用される他の有線または無線通信ネットワークを含むことができる、ネットワーク１１２へのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供してもよい。

【0131】

図１４Ｅは、別の実施形態に従ったＲＡＮ１０５およびコアネットワーク１０９のシステム図である。ＲＡＮ１０５は、ＩＥＥＥ８０２．１６無線技術を使用して、エアインタフェース１１７を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するアクセスサービスネットワーク（ＡＳＮ）であってもよい。以下にさらに論じられるように、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃの異なる機能エンティティとＲＡＮ１０５とコアネットワーク１０９との間の通信リンクを基準ポイントとして定義してもよい。

【0132】

図１４Ｅに示すように、ＲＡＮ１０５は、基地局１８０ａ、１８０ｂ、１８０ｃおよびＡＳＮゲートウェイ１８２を含んでもよいが、ＲＡＮ１０５は、実施形態と整合性を維持したまま、任意の数の基地局およびＡＳＮゲートウェイを含んでもよいことを認識されよう。基地局１８０ａ、１８０ｂ、１８０ｃはそれぞれ、ＲＡＮ１０５内の特定のセル（図示せず）と関連付けられてもよく、およびエアインタフェース１１７を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するための１または複数の送受信機を含んでもよい。一実施形態において、基地局１８０ａ、１８０ｂ、１８０ｃは、ＭＩＭＯ技術を実装してもよい。従って、基地局１８０ａは、例えば、ＷＴＲＵ１０２ａに無線信号を送信し、およびそのＷＴＲＵから無線信号を受信するための複数のアンテナを使用してもよい。基地局１８０ａ、１８０ｂ、１８０ｃはさらに、ハンドオフトリガリング、トンネル確立、無線リソース管理、トラフィック分類、サービス品質（ＱｏＳ）ポリシー施行などの、モビリティ管理機能を提供してもよい。ＡＳＮゲートウェイ１８２は、トラフィック集約ポイントとして機能してもよく、およびページング、加入者プロファイルのキャッシング、コアネットワーク１０９へのルーティングなどに関与してもよい。

【0133】

ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとＲＡＮ１０５との間のエアインタフェース１１７は、ＩＥＥＥ８０２．１６仕様を実装するＲ１基準ポイントとして定義されてもよい。さらに、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのそれぞれは、コアネットワーク１０９との論理インタフェース（図示せず）を確立してもよい。ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとコアネットワーク１０９との間の論理インタフェースは、認証、認可、ＩＰホスト構成管理、および／またはモビリティ管理に使用することができる、Ｒ２基準ポイントとして定義されてもよい。

【0134】

基地局１８０ａ、１８０ｂ、１８０ｃのそれぞれの間の通信リンクは、ＷＴＲＵハンドオーバーおよび基地局間のデータ転送を容易にするためのプロトコルを含むＲ８基準ポイントとして定義されてもよい。基地局１８０ａ、１８０ｂ、１８０ｃとＡＳＮゲートウェイ１８２との間の通信リンクをＲ６基準ポイントとして定義されてもよい。Ｒ６基準ポイントは、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのそれぞれと関連付けられるモビリティイベントに基づいてモビリティ管理を容易にするためのプロトコルを含んでもよい。

【0135】

図１４Ｅに示すように、ＲＡＮ１０５はコアネットワーク１０９に接続されてもよい。ＲＡＮ１０５とコアネットワーク１０９との間の通信リンクは、例えば、データ転送およびモビリティ管理能力を容易にするためのプロトコルを含むＲ３基準ポイントとして定義されてもよい。コアネットワーク１０９は、モバイルＩＰホームエージェント（ＭＩＰ－ＨＡ）１８４、認証、認可、アカウンティング（ＡＡＡ）サーバ１８６、およびゲートウェイ１８８を含んでもよい。上述した要素のそれぞれは、コアネットワーク１０９の一部として示されているが、これらの要素のいずれも、コアネットワーク通信業者以外のエンティティによって所有および／または運用されてもよいことを認識されよう。

【0136】

ＭＩＰ－ＨＡは、ＩＰアドレス管理に関与してもよく、およびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃが、異なるＡＳＮおよび／または異なるコアネットワーク間でローミングすることを可能にする。ＭＩＰ－ＨＡ１８４は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃにインターネット１１０などパケット交換ネットワークへのアクセスを提供して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとＩＰ対応のデバイスとの間の通信を促進することができる。ＡＡＡサーバ１８６は、ユーザ認証およびユーザサービスのサポートに関与してもよい。ゲートウェイ１８８は、他のネットワークとの相互作用を促進することができる。例えば、ゲートウェイ１８８は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃにＰＳＴＮ１０８など回線交換ネットワークへのアクセスを提供して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと従来の固定電話回線による通信デバイスとの間の通信を促進することができる。さらに、ゲートウェイ１８８は、他のサービスプロバイダによって所有および／または運用される他の有線または無線ネットワークを含むことができる、ネットワーク１１２へのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供してもよい。

【0137】

図１４Ｅに示していないが、ＲＡＮ１０５は他のＡＳＮに接続されてもよく、およびコアネットワーク１０９は他のコアネットワークに接続されてもよいことを認識されよう。ＲＡＮ１０５と他のＡＳＮとの間の通信リンクは、ＲＡＮ１０５と他のＡＳＮとの間のＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのモビリティを調整するためのプロトコルを含むことができる、Ｒ４基準ポイントとして定義されてもよい。コアネットワーク１０９と他のコアネットワークとの間の通信リンクは、ホームコアネットワークと移動先コアネットワークとの間の相互作用を促進するためのプロトコルを含むことができる、Ｒ５基準ポイントとして定義されてもよい。

【0138】

本明細書で説明されるプロセスおよび手段は、任意の組み合わせにおいて適応されてもよく、他の無線技術、および他のサービスに適用されてもよい。

【0139】

ＷＴＲＵは、物理的デバイスの識別、または例えば、ＭＳＩＳＤＮ、ＳＩＰ ＵＲＩなど、加入関連識別（subscription related identity）などのユーザ識別を参照してもよい。ＷＴＲＵは、アプリケーションベースの識別、例えば、アプリケーション毎に使用され得るユーザ名を参照してもよい。

【0140】

特定の組み合わせにおいて特徴および要素を上述しているが、特徴または要素は、単独で、または他の特徴および要素との任意の組み合わせにおいて使用されてよいことが当業者には認識されよう。さらに、本明細書で説明される方法は、コンピュータまたはプロセッサによって実行するためのコンピュータ可読媒体に組み込まれるコンピュータプログラム、ソフトウェア、またはファームウェアに実装され得る。コンピュータ可読媒体の例は、（有線および／または無線接続を介して送信される）電子信号および／またはコンピュータ可読記憶媒体を含む。コンピュータ可読記憶媒体の例は、限定されるわけではないが、リードオンリーメモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、レジスタ、キャッシュメモリ、半導体メモリデバイス、内部ハードディスクおよびリムーバブルディスクなどの磁気媒体、光磁気媒体、およびＣＤ－ＲＯＭディスク、およびデジタル多用途ディスク（ＤＶＤ）などの光媒体を含む。ソフトウェアと連動するプロセッサを使用して、ＷＴＲＵ、ＵＥ、端末機、基地局、ＲＮＣ、および／または任意のホストコンピュータで使用するための無線周波数送受信機を実装してもよい。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14A】

【図14B】

【図14C】

【図14D】

【図14E】