JP2017169227A - 観視条件への適応をサポートするビデオ配信のための方法およびシステム - Google Patents

Abstract

【課題】マルチメディアコンテンツの観視条件への適応をサポートする、ビデオ配信のための方法及びシステムを提供する。【解決手段】観視パラメータを決定し、観視パラメータに基づきマルチメディアコンテンツを求める要求をネットワークに送信し、マルチメディアコンテンツをネットワークから受信し、マルチメディアコンテンツは観視パラメータに従ったレートで処理される。観視パラメータは、ユーザ観視パラメータ、デバイス観視パラメータ、またはコンテンツ観視パラメータの少なくとも１つを含む。【選択図】図２９

Description

本発明は、観視条件への適応をサポートするビデオ配信のための方法およびシステムに関する。

無線ネットワークおよび有線ネットワーク上のストリーミングコンテンツは、ネットワークにおける可変帯域幅に起因して、適応を利用することができる。ストリーミングコンテンツプロバイダは、複数のレートおよび／または解像度で符号化されたコンテンツを発行することができる。これは、クライアントが、変化するチャネル帯域幅に適応することを可能にすることができる。ＭＰＥＧ／３ＧＰＰ ＤＡＳＨ規格は、無線ネットワークおよび有線ネットワーク上のストリーミングサービスの効率的で高品質の配信を可能にし得るエンドツーエンドサービスを設計するためのフレームワークを定義することができる。

本明細書では、マルチメディアコンテンツの観視条件適応に関連する方法およびシステムが説明される。デバイスを用いてネットワークからマルチメディアコンテンツを受信するための方法は、観視パラメータを決定するステップと、前記マルチメディアコンテンツを求める要求を前記ネットワークに送信するステップであって、前記要求が前記観視パラメータに基づき得る、ステップとを含むことができる。前記方法は、前記マルチメディアコンテンツを前記ネットワークから受信するステップであって、前記マルチメディアコンテンツが前記観視パラメータに従ったレートで処理され得る、ステップをさらに含むことができる。デバイスは、マルチメディアコンテンツをネットワークから受信するように構成され得る。前記デバイスは、観視パラメータを決定することと、前記マルチメディアコンテンツを求める要求を前記ネットワークに送信することであって、前記要求が前記観視パラメータに基づき得る、送信することとを行うように構成され得るプロセッサを含むことができる。前記プロセッサは、前記マルチメディアコンテンツを前記ネットワークから受信することであって、前記マルチメディアコンテンツが前記観視パラメータに従ったレートで処理され得る、受信することを行うようにさらに構成され得る。前記デバイスは、例えば、無線送受信ユニット、ストリーミングビデオプレーヤ、ビデオチャットアプリケーション、ビデオアプリケーション、またはビデオゲームアプリケーションとすることができる。

マルチメディアコンテンツをネットワークからデバイスに配信するための方法は、観視パラメータを決定するステップと、前記決定された観視パラメータに適したビデオ符号化の特性を決定するステップと、前記ビデオ符号化の決定された特性に従って符号化されたビデオコンテンツを送信するステップとを含むことができる。

前記マルチメディアコンテンツは、ビデオファイルとすることができる。前記方法は、前記デバイスのＤＡＳＨクライアントを介して実行され得る。前記プロセッサは、前記デバイスのＤＡＳＨクライアントの一部とすることができる。

前記レートは、前記マルチメディアコンテンツの符号化レート、前記マルチメディアコンテンツの空間分解能、前記マルチメディアコンテンツの時間分解能、量子化パラメータ、レート制御パラメータ、前記マルチメディアコンテンツの目標ビットレート、前記マルチメディアコンテンツの空間フィルタリング、または前記マルチメディアコンテンツの時間フィルタリングのうちの少なくとも１つの関数とすることができる。

前記観視パラメータは、ユーザ観視パラメータ、デバイス観視パラメータ、またはコンテンツ観視パラメータのうちの少なくとも１つを含むことができる。前記ユーザ観視パラメータは、ユーザの存在、前記デバイスの画面に対するユーザの位置、前記デバイスの画面に対するユーザの向き、前記デバイスの画面に対するユーザの視野角、前記デバイスの画面からのユーザの距離、ユーザの視力、周囲の照明条件、前記デバイスの画面を観視するユーザの人数、またはユーザの注視点のうちの少なくとも１つを含むことができる。

前記デバイス観視パラメータは、前記デバイスのモビリティ、前記デバイスの画面のサイズ、前記デバイスの画面の解像度、前記デバイスの画面のピクセル密度、前記デバイス上の前記マルチメディアコンテンツを表示するウィンドウのサイズ、または前記デバイス上の前記マルチメディアコンテンツを表示するウィンドウの位置のうちの少なくとも１つを含むことができる。

前記コンテンツ観視パラメータは、前記マルチメディアコンテンツのコントラスト、前記マルチメディアコンテンツの色域、３次元のマルチメディアコンテンツの存在、または前記マルチメディアコンテンツの３次元コンテンツの深度の範囲のうちの少なくとも１つを含むことができる。

前記観視パラメータは、前記デバイスの画面のサイズ、前記デバイスの画面の解像度、前記デバイスの画面の角度、前記デバイスの画面のピクセル密度、前記デバイスの画面のコントラスト比、ユーザ近接センサ、前向きカメラ、後向きカメラ、光センサ、赤外線イメージングデバイス、超音波センサ、マイクロフォン、加速度計、コンパス、またはジャイロスコープセンサのうちの少なくとも１つを使用して決定され得る。

前記デバイスによって送信される前記要求は、前記デバイスによって受信されるマルチメディアコンテンツの前記レートを決定することができる。前記ネットワークは、前記デバイスによって受信される前記マルチメディアコンテンツの前記レートを、前記要求に従って決定することができる。例えば、前記要求は、前記観視パラメータを含むマルチメディアプレゼンテーション記述（ＭＰＤ：ｍｕｌｔｉｍｅｄｉａ ｐｒｅｓｅｎｔａｔｉｏｎ ｄｅｓｃｒｉｐｔｉｏｎ）ファイルとすることができる。

前記方法は、マニフェストファイル（例えば、マルチメディアプレゼンテーション記述（ＭＰＤ）ファイル）を前記ネットワークから受信するステップをさらに含むことができる。前記プロセッサは、マルチメディアプレゼンテーション記述（ＭＰＤ）ファイルを前記ネットワークから受信するようにさらに構成され得る。前記ＭＰＤファイルは、前記マルチメディアコンテンツの前記レートに関する情報を含むことができる。前記レートに関する前記情報は、前記観視パラメータに関するディスクリプタを含むことができる。前記ＭＰＤファイルは、前記ディスクリプタが必須か、それとも任意かを示すことができる。必須のディスクリプタは、前記レートで処理された前記マルチメディアコンテンツを受信するために、前記デバイスが前記ディスクリプタの前記要件を満たさなければならないことを示すことができる。任意のディスクリプタは、前記レートで処理された前記マルチメディアコンテンツを受信するために、前記デバイスが前記ディスクリプタの前記要件を満たすことがあることを示すことができる。

スネレン（Snellen）、ランドルトＣ（Landolt C）、および「非識字者用Ｅ（Illiterate E）」視力表の例を示す図である。 「２０／２０視力（20/20-vision）」行の文字Ｅの特性の一例を示す図である。 スネレンのＥ表から優位空間周波数を導出する一例を示す図である。 コントラスト感度関数（ＣＳＦ：Ｃｏｎｔｒａｓｔ Ｓｅｎｓｉｔｉｖｉｔｙ Ｆｕｎｃｔｉｏｎ）と重ね合わされた、キャンベル−ロブソン（Campbell-Robson）の一例を示す図である。 グレースケール（輝度）、赤−緑、および青−黄チャネルに関するＣＳＦ曲線の例示的な比較を示す図である。 中心窩からの度数を単位とする相対視力（左目）の一例を示す図である。 固定点からの角度につれての視力の変化を示す例示的な検査を示す図である。 例示的なＤＡＳＨの高水準システムアーキテクチャの図である。 例示的なＤＡＳＨクライアントモデルの図である。 例示的なＤＡＳＨメディア提示の高水準データモデルの図である。 ストリームアクセスポイントのパラメータの一例についての図である。 ＤＡＳＨにおけるプロファイルの一例についての図である。 モバイルビデオストリーミングシステムの例示的なアーキテクチャを示す図である。 異なるビットレートで符号化されたマルチメディアコンテンツの一例を示す図である。 帯域幅適応マルチメディアストリーミングの一例を示す図である。 モバイルビデオ電話システムの例示的なアーキテクチャを示す図である。 モバイル観視セットアップのパラメータの一例を示す図である。 観視距離の分布の形状の一例についてのグラフである。 画面のコントラストとそれが再生し得る空間周波数の可視範囲との間の関係の一例を示す図である。 様々な観視状況における輻輳距離と焦点距離の一例を示す図である。 両眼単一明視域（ＺＣＳＢＶ：ｚｏｎｅ ｏｆ ｃｌｅａｒ ｓｉｎｇｌｅ ｂｉｎｏｃｕｌａｒ ｖｉｓｉｏｎ）の一例を示す図である。 事前フィルタリングを用いる空間周波数の可視範囲に対する適応の一例を示す図である。 前向きカメラを使用してユーザの存在およびユーザの画角を検出する一例を示す図である。 瞳孔間距離（ＩＰＤ）を使用することによって画面からのユーザの距離を検出する例を示す図である。 瞳孔間距離（ＩＰＤ）を使用することによって画面からのユーザの距離を検出する例を示す図である。 ユーザが認識し得る最小のフォントサイズを検出するためのインターフェースの一例を示す図である。 ユーザが最小の空間的細部を見ることができる最長の距離を検出するためのインターフェースの一例を示す図である。 観視条件適応ストリーミングシステムの一例を示す図である。 そのようなシステムの例示的なアーキテクチャおよび機能の説明についての図である。 視軸からの傾きの関数としてのＣＦＦ値のトポグラフィック図の一例を示す図である。 視野角アルファは同じであるが、交角ベータが異なる、２つの環境の例についての図である。 ユーザの挙動および観視条件に対して適応する例示的なストリーミングシステムの図である。 １または複数の開示される実施形態が実施され得る例示的な通信システムのシステム図である。 図３０Ａに示された通信システム内で使用され得る例示的な無線送受信ユニット（ＷＴＲＵ）のシステム図である。 図３０Ａに示された通信システム内で使用され得る例示的な無線アクセスネットワークおよび例示的なコアネットワークのシステム図である。 図３０Ａに示された通信システム内で使用され得る別の例示的な無線アクセスネットワークおよび別の例示的なコアネットワークのシステム図である。 図３０Ａに示された通信システム内で使用され得る別の例示的な無線アクセスネットワークおよび別の例示的なコアネットワークのシステム図である。

例示的な実施形態についての詳細な説明が、様々な図を参照して、今から説明される。この説明は、可能な実施についての詳細な例を提供するが、細部は、例示的なものであることが意図されており、決して本出願の範囲を限定するものではないことに留意されたい。

ビデオ配信システムは、ビデオは理想的な再生環境（例えば、減光された部屋、ハイコントラストディスプレイ、広い視野角など）で観視されるという仮定の下で符号化されたビデオを送信することがある。これは、画面上に表示され得る視覚的情報（例えば、ビデオ、ゲームなど）を符号化し、搬送するために、大量の帯域幅を必要とし得る。本明細書で説明される実施は、再生環境が理想的な再生環境から逸脱することがある状況で（例えば、モバイル状況で）利用され得る。例えば、本明細書で説明される実施は、例えば、観視者が視覚的コンテンツを見るときに存在する観視条件を考慮することによって、あまり理想的ではない再生環境でコンテンツを配信し、表示する際により効率的になり得る、適応システムを提供することができる。

人間の視覚のいくつかの現象／特性が、本明細書で説明される実施によって利用され得る。視力は、視覚処理系の空間分解能の尺度とすることができる。それは、図１Ａ〜図１Ｃに示される、スネレン、ランドルトＣ、および／または「非識字者用Ｅ」表などの、しかし、それらに限定されない、検眼表を使用することによって測定され得る。例えば、「２０／２０視力」という用語は、成人の通常の視力を表すために使用され得る。それは、２０フィート（約６メートル）離れて見た場合に、最小の空間的細部（例えば、一画、間隙）が１分の弧（例えば、１／６０度の視角）を構成するようにデザインされた文字を含む行を読む能力を意味することができる。そのような一例が、図１Ｂに示されている。「２０／２０視力」は、１分の弧（例えば、１／６０度の視角）に相当する小ささの細部を解像する能力を意味することができる。

空間周波数限界が利用され得る。視力と人間の視覚系の空間周波数限界との間には関係があり得る。これは、例えば、図１Ｃに例示されるような、スネレンのＥの格子への変換を示すことによって説明され得る。２０／２０（６／６）行の文字Ｅの場合、１サイクル内に２分の弧が存在し得ることが観測され得る。１度は６０分とすることができるので、１度は３０サイクルを含むことができる。２０／２０（６／６）文字では、１度あたり３０サイクル（ｃｐｄ：ｃｙｃｌｅｓ ｐｅｒ ｄｅｇｒｅｅ）が存在し得る。例えば、「２０／２０視力」という用語は、３０サイクル／度に相当する高さの空間周波数を解像する能力に対応し得る。

コントラスト感度関数（ＣＳＦ）が利用され得る。視力は、ハイコントラスト文字（例えば、白い背景上の黒いシンボル）を使用して測定され得る。「コントラスト感度関数」（ＣＳＦ）は、異なるコントラストの像を考察することによって獲得される、ＨＶＳ限界のより完全な特徴付けとなり得る。ＣＳＦは、例えば、図２に示される、キャンベル−ロブソンチャートと重ね合わされたときに、最も良く理解され得る。図２を参照すると、ピクセルの輝度は、水平次元に沿って正弦的に変調され得る。変調の周波数（例えば、空間周波数）は、（例えば、周波数の左から右への実質的に指数的な増加とともに）対数的に増加し得る。コントラストは、１００％から約０．５％まで（例えば、下部から上部に）対数的に変化し得る。

図２に示されるように、ＣＳＦは、コントラスト／空間周波数空間における可視領域の境界を例示することができる。ＣＳＦの最も左の点は、視力限界（例えば、ハイコントラストにおけるカットオフ周波数）と一致し得る。ＣＳＦは、高い周波数では、視力限界に達するまで単調に減少し得る。ＣＳＦは、低い周波数では、減少し得る。これは、異なる神経生物学的現象によって引き起こされ得る。ＣＳＦのピークは、６サイクル／度付近とすることができる。網膜照度のレベルに基づいて、ＣＳＦの形状が変化し得ることに留意することができる。低光量条件の下では、感度は、大幅に減少され得る。

色覚の制限が利用され得る。人間の網膜は、広いスペクトルに応答する要素（例えば、桿体細胞）とは対照的に、はるかに少数の色感知要素（例えば、錐体細胞）を含み得る。これは、色覚のはるかに低い空間分解能として現れ得る。図３は、グレースケール、赤−緑、および青−黄チャネルに対して生成されたＣＳＦ曲線を比較した一例を示している。図３に例示されるように、青−黄および赤−緑チャネルは、より早い減少を有し、約１０〜１５サイクル／度においてカットオフに達し得る。これは、輝度に関する視力限界よりも低いものであり得る。色関連のＣＳＦは、全体的な網膜照度によって、輝度に関するＣＳＦよりも大きな影響を受け得る。低光量条件の下では、我々は色が見えないことがある。この現象は、暗所視と呼ばれることがある。

色覚の角度限界が利用され得る。人間は、視野内の狭い角度内で色を見ることができる。これは、人間の網膜上での桿体細胞と錐体細胞の非対称分布に関連し得る。

中心視覚と周辺視覚の比較、および相対視力が利用され得る。中心窩では錐体細胞および神経節細胞の集中度が高いので、この領域では、視力能力がより高くなり得る。標準的な視力検査は、中心窩領域に関する視力を評価することができる。中心窩の外側では、視力は急激に低下し得る。中心窩からの角度の関数としての相対視力の例示的なプロットが、図４に示されている。

図５は、固視点からの角度につれての視力の変化を示す例示的な検査を示している。この検査は、中央に焦点を合わせた場合、すべての文字が等しく鮮明に見えることを示し得る。この検査は、最小の文字と最大の文字との間の空間角が約２度になり得る、快適な観視距離で行われ得る。最小の文字と最大の文字との間の線形サイズ差は、約１：８であり得る。

この現象が暗示することは、ピクチャの小さな部分がいつも常にフル解像度で観察され得ることであり得る。この現象を使用する潜在的な節約の限界を推定するために、水平および垂直ピクセル密度が同じであり、したがって、節約は面積によって近似され得ると仮定することができる。画面の対角線サイズをＤ、アスペクト比をｒとすると、画面サイズは、

とすることができる。

「高解像度」領域は、角度β（例えば、約２°）によって定義される外側正方形を含むことができ、観視距離ｄに依存し得、
Ａ’＝４ｄ²（ｔａｎβ）²
によって与えることができる。

低解像度（例えば、焦点領域の外）は、焦点領域よりも低い解像度を用いて、例えば、係数Ｒによって、符号化され得ると仮定することができる。（例えば、この技法を用いるものから、用いないものまで）ピクセルカウント比は、

とすることができる。

Ｄ＝９．７インチ、ｒ＝９／１６、Ｒ＝８、ｄ＝２５、およびβ＝２°とすると、比は、約１５％になり得、これは、８５％の節約になり得る。（例えば、空間および／または時間における）タイル間の変化を滑らかにすると、より僅かな節約にしかなり得ないが、より良いユーザエクスペリエンスをもたらすことができる。

動的適応ＨＴＴＰストリーミング（ＤＡＳＨ：Ｄｙｎａｍｉｃ Ａｄａｐｔｉｖｅ ＨＴＴＰ Ｓｔｒｅａｍｉｎｇ）が、本明細書で説明され、利用され得る。ＤＡＳＨは、ＨＴＴＰストリーミングのためのいくつかの手法を統合することができる。例えば、ＭＰＥＧ ＤＡＳＨは、３ＧＰＰリリース１０で説明される「３ＧＰ−ＤＡＳＨ」の拡張とすることができる。ＤＡＳＨは、無線ネットワークおよび有線ネットワークにおいて可変帯域幅に対処するために使用され得る。ＤＡＳＨは、コンテンツプロバイダおよびデバイスによってサポートされ得る。ＤＡＳＨは、任意のアクセスネットワーク上での任意のデバイスに対するマルチメディアストリーミングサービスを可能にすることができる。

ＤＡＳＨは、適切なフォーマットで準備され得るライブおよび／またはオンデマンドコンテンツを配信し得る、１組のＨＴＴＰサーバとして配備され得る。クライアントは、ＨＴＴＰサーバから直接的に、および／または例えば、図６に示されるような、コンテンツ配信ネットワーク（ＣＤＮ）から、コンテンツを入手することができる。図６は、例示的なＤＡＳＨの高水準システムアーキテクチャの図を示している。ＣＤＮは、コンテンツをキャッシュし得、クライアントに近く、ネットワークの縁に配置され得るので、多数のクライアントが予想される配備のために使用され得る。

ＤＡＳＨでは、ストリーミングセッションは、ＨＴＴＰを使用してセグメントを要求し、コンテンツプロバイダおよび／またはＣＤＮから受信されたときに、それらを一緒に接合することによって、クライアントによって制御され得る。インテリジェンスをネットワークからクライアントに効果的に移転することで、クライアントは、メディアレートをモニタし（例えば、継続的にモニタし）、ネットワーク状態（例えば、パケット誤り率、遅延ジッタ）、ならびに自らの状態（例えば、バッファ満杯、ユーザ挙動およびプリファレンス）に基づいて、メディアレートを調整することができる。

ＤＡＳＨ規格の設計は、例えば、図７に示されるような、参考的なクライアントモデルに基づくことができる。図７は、例示的なＤＡＳＨクライアントモデルの図を示している。図７は、概念的なＤＡＳＨクライアントモデルの論理構成要素の一例を示している。ＤＡＳＨアクセスエンジンは、メディアプレゼンテーション記述ファイル（ＭＰＤ）を受け取り、要求を構成し、発行すること、および／またはセグメントもしくはセグメントの部分を受け取ることができる。ＤＡＳＨアクセスエンジンの出力は、ＭＰＥＧコンテナフォーマット（例えば、ＭＰ４ファイルフォーマットまたはＭＰＥＧ−２トランスポートストリーム）のメディアと、メディアの内部タイミングを提示のタイムラインにマッピングするタイミング情報とから成ることができる。メディアの符号化されたチャンクとタイミング情報との組み合わせは、コンテンツの正しい表示のために十分であり得る。

ＤＡＳＨが符号化されたメディアセグメントに課すほとんどの制約は、復号、後処理、および／または再生が、それらのセグメントが何であるか、および／またはそれらがどのように配信されたかについて何も知らないメディアエンジンによって行われ得るという前提に基づき得る。メディアエンジンは、ＤＡＳＨアクセスエンジンによってチャンクとして供給された、連続的なメディアファイルを復号し、再生し得るにすぎない。例えば、アクセスエンジンは、ｊａｖａスクリプトとすることができ、一方、メディアエンジンは、ブラウザ、ブラウザプラグイン（例えば、Ｆｌａｓｈ（登録商標）もしくはＳｉｌｖｅｒｌｉｇｈｔ（登録商標））、および／またはオペレーティングシステムによって提供される何かとすることができる。

図８は、例示的なＤＡＳＨメディア提示の高水準データモデルの図を示している。ＤＡＳＨでは、マルチメディア提示の組織化は、階層データモデルに基づくことができる。メディアプレゼンテーション記述（ＭＰＤ）は、ＤＡＳＨメディア提示（例えば、マルチメディアコンテンツ）を構成する期間（period）のシーケンスを記述し得る。期間は、メディアコンテンツの一貫性のある１組の符号化バージョンが利用可能であり得る、メディアコンテンツ期間を表し得る。期間中、利用可能なビットレート、言語、および／またはキャプションの組は、変化することができる。

適応セット（adaptation set）は、１または複数のメディアコンテンツ構成要素の１組の交換可能な符号化バージョンを表現し得る。例えば、ビデオのための適応セット、１次オーディオのための適応セット、２次オーディオのための適応セット、および／またはキャプションのための適応セットが存在し得る。適応セットは、多重化することもでき、その場合、多重化の交換可能なバージョンが、単一の適応セットとして記述され得る。例えば、適応セットは、期間のためのビデオおよびメインオーディオを含むことができる。

表現（representation）は、１または複数のメディアコンテンツ構成要素の配信可能な符号化バージョンを記述し得る。表現は、１または複数のメディアストリーム（例えば、多重化内の各メディアコンテンツ構成要素のためのもの）を含み得る。適応セット内のいずれか１つの表現だけで、含まれるメディアコンテンツ構成要素を表示するのに十分であり得る。例えば、クライアントは、例えば、ネットワーク状態および／または他の要因に適応するために、適応セット内で表現から表現に切り換えることができる。クライアントは、それがサポートしないコーデック／プロファイル／パラメータを使用する表現を無視することができる。

セグメントは、時間的に固定長または可変長のセグメントに分割され得る表現内のコンテンツとすることができる。ＵＲＬが、各セグメントに提供され得る。セグメントは、単一のＨＴＴＰ要求を用いて取り出され得るデータの最大単位とすることができる。メディアプレゼンテーション記述（ＭＰＤ）は、ＤＡＳＨクライアントがＨＴＴＰ−ＵＲＬを構成して、セグメントにアクセスし、ストリーミングサービスをユーザに提供するためのメタデータを含む、ＸＭＬ文書とすることができる。

ＭＰＤ内のベースＵＲＬは、メディア提示内のセグメントおよび他のリソースを求めるＨＴＴＰ ＧＥＴ要求を生成するために、クライアントによって使用され得る。ＨＴＴＰ部分ＧＥＴ要求は、バイト範囲を使用することによって（例えば、「Ｒａｎｇｅ」ＨＴＴＰヘッダを介して）、セグメントの限られた部分にアクセスするために使用され得る。ベースＵＲＬは、ロケーションが利用可能でない場合に、提示へのアクセスを可能にするために指定され、マルチメディアストリームの配信に冗長性を提供し、ならびに／またはクライアントサイドのロードバランシングおよび並列ダウンロードを可能にする。

ＭＰＤは、「静的」または「動的」とすることができる。静的ＭＰＤタイプは、メディア提示中、変化し得ず、オンデマンド提示のために使用され得る。動的ＭＰＤタイプは、メディア提示中、更新され得、ライブ提示のために使用され得る。ＭＰＤは、各表現のためのセグメントのリストを拡張するため、新しい期間を導入するため、および／またはメディア提示を終了するために更新され得る。

ＤＡＳＨでは、異なるメディアコンテンツ構成要素（例えば、ビデオ、オーディオなど）の符号化バージョンが、共通のタイムラインを共有し得る。メディアコンテンツ内のアクセスユニットの提示時間は、メディア提示タイムラインと呼ばれることがある、大域的な共通の提示タイムラインにマッピングされ得る。これは、異なるメディア構成要素の同期を可能にすることができ、および／または同じメディア構成要素の異なる符号化バージョン（例えば、表現）のシームレスな切り換えを可能にすることができる。

セグメントは、実際の区分けされたメディアストリームを含むことができる。それらは、切り換え、および／または他の表現との同期提示のために、メディアストリームをメディア提示タイムラインにどのようにマッピングするかについての追加の情報を含むことができる。

セグメント利用可能性タイムラインは、指定されたＨＴＴＰ ＵＲＬにおけるセグメントの利用可能性時間（availability time）をクライアントに伝えるために使用され得る。例えば、これらの時間は、実時間（wall-clock time）で提供され得る。指定されたＨＴＴＰ ＵＲＬにおけるセグメントにアクセスする前に、クライアントは、実時間をセグメント利用可能性時間と比較することができる。

オンデマンドコンテンツの場合、いくつかまたはすべてのセグメントの利用可能性時間は、同一とすることができる。いずれかのセグメントがひとたび利用可能になると、メディア提示のいくつかまたはすべてのセグメントがサーバ上で利用可能になり得る。ＭＰＤは、静的な文書とすることができる。

ライブコンテンツの場合、セグメントの利用可能性時間は、メディア提示タイムライン内におけるセグメントの位置に依存し得る。セグメントは、時間とともにコンテンツが生成されるにつれて、利用可能になり得る。ＭＰＤは、提示内における時間につれての変化を反映するために、定期的に更新され得る。例えば、新しいセグメントのためのセグメントＵＲＬが、ＭＰＤに追加され得、もはや利用可能ではない旧いセグメントが、ＭＰＤから削除され得る。例えば、セグメントＵＲＬがテンプレートを使用して記述される場合、ＭＰＤの更新は、必要ではないことがある。

セグメントの持続時間は、通常のスピードで提示されるときにセグメント内に含まれるメディアの持続時間に相当し得る。表現内のいくつかまたはすべてのセグメントは、同じまたはほぼ同様の持続時間を有することができる。セグメント持続時間は、表現ごとに異なり得る。ＤＡＳＨ提示は、相対的に短いセグメント（例えば、数秒）、または表現全体のための単一のセグメントを含む、より長いセグメントを用いて構成され得る。

短いセグメントは、（例えば、エンドツーエンド待ち時間を短くすることによって）ライブコンテンツに適することができ、セグメントレベルにおける高い切り換え粒度を可能にすることができる。短いセグメントは、提示内のファイルの数を増加させ得る。長いセグメントは、提示内のファイルの数を減少させることによって、キャッシュ性能を高めることができる。それらは、クライアントが、（例えば、バイト範囲要求を使用することによって）要求サイズを柔軟にすることを可能にすることができる。長いセグメントは、セグメントインデックスの使用を必要とし得、ライブイベントには適し得ない。セグメントは、時間につれて拡張されることがあり、または拡張されることがない。セグメントは、全体として利用可能にされ得る、完全な個別のユニットとすることができる。

セグメントは、サブセグメントにさらに細分化され得る。サブセグメントは、数々の完全なアクセスユニットを含むことができる。「アクセスユニット」は、メディア提示時間が割り当てられた、メディアストリームのユニットとすることができる。セグメントがサブセグメントに分割される場合、サブセグメントは、セグメントインデックスによって記述され得る。セグメントインデックスは、提示内における提示時間範囲、および各サブセグメントによって占められるセグメント内の対応するバイト範囲を提供することができる。クライアントは、このインデックスを事前にダウンロードし、その後、ＨＴＴＰ部分ＧＥＴ要求を使用して、個々のサブセグメントを求める要求を発行することができる。セグメントインデックスは、メディアセグメント内に、例えば、ファイルの先頭に含まれ得る。セグメントインデックス情報は、別個のインデックスセグメントでも提供され得る。

ＤＡＳＨは、初期化セグメント、メディアセグメント、インデックスセグメント、およびビットストリーム切り換えセグメントを定義することができる。初期化セグメントは、表現にアクセスするための初期化情報を含むことができる。初期化セグメントは、提示時間が割り当てられたメディアデータを含むことができ、または含むことができない。初期化セグメントは、メディアエンジンを初期化して、含まれる表現のメディアセグメントの再生（play-out）を可能にするために、クライアントによって処理され得る。

メディアセグメントは、メディアセグメント内で記述される、および／もしくは表現の初期化セグメントによって記述されるメディアストリームを含むこと、ならびに／またはカプセル化することができる。メディアセグメントは、数々の完全なアクセスユニットを含むことができる。メディアセグメントは、含まれる各メディアストリームに対して、少なくとも１つのストリームアクセスポイント（ＳＡＰ）を含むことができる。

インデックスセグメントは、メディアセグメントに関連し得る情報を含むことができる。インデックスセグメントは、メディアセグメントのためのインデックス情報を含むことができる。インデックスセグメントは、１または複数のメディアセグメントについての情報を提供することができる。インデックスセグメントは、メディアフォーマット固有とすることができる。インデックスセグメントをサポートする各メディアフォーマットについて、詳細が定義され得る。

ビットストリーム切り換えセグメントは、それが割り当てられ得る表現に切り換えるために利用され得るデータを含むことができる。それは、メディアフォーマット固有とすることができ、ビットストリーム切り換えセグメントを許可する各メディアフォーマットについて、詳細が定義され得る。各表現に対して、１つのビットストリーム切り換えセグメントが定義され得る。

クライアントは、メディア内の任意のポイントで、適応セット内において表現から表現に切り換えることができる。任意の位置における切り換えは、例えば、表現内の符号化依存性、および他の要因のために、複雑になり得る。「オーバラップする」データ（例えば、複数の表現から同じ期間のメディア）をダウンロードすることは、回避され得る。切り換えは、新しいストリーム内のランダムアクセスポイントにおいて最も簡単になり得る。

ＤＡＳＨは、ストリームアクセスポイント（ＳＡＰ）のコーデック独立の概念を定義し、ＳＡＰの様々なタイプを識別することができる。ストリームアクセスポイントタイプは、適応セットのプロパティの１つとして伝達され得る（例えば、適応セット内のいくつかまたはすべてのセグメントが同じＳＡＰタイプを有することが仮定され得る）。

ＳＡＰは、メディアストリーム（複数可）のファイルコンテナへのランダムアクセスを可能にし得る。ＳＡＰは、コンテナ内の位置とすることができ、コンテナ内に含まれるその位置以降の情報、ならびに／またはコンテナの他の部分（複数可）からの、および／もしくは外部的に入手可能な可能な初期化データを使用して、識別されたメディアストリームの再生が開始されることを可能にする、

ファイルコンテナプロパティは、Ｔ_SAPを含むことができる。Ｔ_SAPは、メディアストリームのアクセスユニットの最も早い提示時間とすることができ、例えば、Ｔ_SAPより大きいまたは等しい提示時間を有するメディアストリームのいくつかまたはすべてのアクセスユニットは、Ｉ_SAPで開始するビットストリーム内のデータを使用して正しく復号され得、Ｉ_SAPの前にはデータがない可能性がある。Ｉ_SAPは、ビットストリーム内の最も大きい位置とすることができ、Ｔ_SAPより大きいまたは等しい提示時間を有するメディアストリームのいくつかまたはすべてのアクセスユニットは、Ｉ_SAPで開始するビットストリームデータを使用して正しく復号され得、Ｉ_SAPの前にはデータがない可能性がある。Ｉ_SAUは、メディアストリーム内の復号順で最も遅いアクセスユニットのビットストリーム内における開始位置とすることができ、Ｔ_SAPより大きいまたは等しい提示時間を有するメディアストリームのいくつかまたはすべてのアクセスユニットは、この最も遅いアクセスユニットおよび復号順で後続するアクセスユニットを使用して正しく復号され得、復号順でより早いアクセスユニットはない可能性がある。Ｔ_DECは、Ｉ_SAUで開始するビットストリーム内のデータを使用して正しく復号され得る、メディアストリームの任意のアクセスユニットの最も早い提示時間とすることができ、Ｉ_SAUの前にはデータがない可能性がある。Ｔ_EPTは、ビットストリームにおいてＩ_SAUで開始するメディアストリームの任意のアクセスユニットの最も早い提示時間とすることができる。Ｔ_PTFは、ビットストリームにおいてＩ_SAUで開始するメディアストリームの復号順で最初のアクセスユニットの提示時間とすることができる。

これらのパラメータを有するストリームアクセスポイントの一例が、図９に示されている。この例では、３つの異なるタイプのフレーム、すなわち、Ｉ、Ｐ、およびＢを有する符号化ビデオストリームの例が示されている。Ｐフレームは、復号されるのに、先行するＩまたはＰフレームを利用することができ、一方、Ｂフレームは、先行および後続するＩおよび／またはＰフレームの両方を利用することができる。送信順、復号順、および／または提示順に相違が存在し得る。

図９は、ストリームアクセスポイントのパラメータの図を示している。６つのＳＡＰタイプが提供され得る。異なるＳＡＰタイプの使用は、プロファイルに限定され得る（例えば、いくつかのプロファイルについては、ＳＡＰタイプのサブセットのみが利用され得る）。

ＤＡＳＨ ＳＡＰタイプは、どのアクセスユニットが正しく復号可能であるか、および／または提示順でのそれらの配置に依存し得る。例えば、タイプ１の場合、Ｔ_EPT＝Ｔ_DEC＝Ｔ_SAP＝Ｔ_PFTである。このＳＡＰタイプは、「クローズドＧｏＰランダムアクセスポイント」と呼ばれることがあるものに対応し得る。Ｉ_SAPから開始する（例えば、復号順での）アクセスユニットは、正しく復号され得る。結果は、ギャップのない、正しく復号されたアクセスユニットの連続的な時間シーケンスになり得る。復号順で最初のアクセスユニットが、提示順で最初のアクセスユニットになり得る。

例えば、タイプ２の場合、Ｔ_EPT＝Ｔ_DEC＝Ｔ_SAP＜Ｔ_PFTである。このＳＡＰタイプは、「クローズドＧｏＰランダムアクセスポイント」と呼ばれることがあるものに対応し得、Ｉ_SAUから開始するメディアストリーム内の復号順で最初のアクセスユニットが、提示順で最初のアクセスユニットにならないことがある。最初の２つのフレームは、（例えば、Ｈ．２６４および他のいくつかのコーデックでは前方限定の（forward-only）Ｂフレームとして構文的に符号化され得る）後方予測される（backward predicted）Ｐフレームとすることができ、それらは、第３のフレームが最初に復号されることを必要とし得る。

例えば、タイプ３の場合、Ｔ_EPT＜Ｔ_DEC＝Ｔ_SAP≦Ｔ_PFTである。このＳＡＰタイプは、「オープンＧｏＰランダムアクセスポイント」と呼ばれることがあるものに対応し得、正しく復号されないことがあり、Ｔ_SAPよりも小さい提示時間を有し得る、復号順でＩ_SAUに後続するいくつかのアクセスユニットが存在し得る。

例えば、タイプ４の場合、Ｔ_EPT≦Ｔ_PFT＜Ｔ_DEC＝Ｔ_SAPである。このＳＡＰタイプは、「グラデュアル復号リフレッシュ（ＧＤＲ：Ｇｒａｄｕａｌ Ｄｅｃｏｄｉｎｇ Ｒｅｆｒｅｓｈ）ランダムアクセスポイント」（例えば、または「ダーティ（dirty）」ランダムアクセス）と呼ばれることがあるものに対応し得、正しく復号されないことがあり、Ｔ_SAPよりも小さい提示時間を有し得る、復号順でＩ_SAUから開始し、それに後続するいくつかのアクセスユニットが存在し得る。

イントラリフレッシュ（intra refreshing）プロセスが、ＧＤＲの一例であり得る。イントラリフレッシュプロセスは、Ｎ個のフレームにわたって拡張され得、フレームの一部は、イントラＭＢを用いて符号化され得る。オーバラップしない部分は、Ｎ個のフレームにわたってイントラ符号化され得る。このプロセスは、フレーム全体がリフレッシュされるまで繰り返され得る。

例えば、タイプ５の場合、Ｔ_EPT＝Ｔ_DEC＜Ｔ_SAPである。このＳＡＰタイプは、正しく復号されないことがあり、Ｔ_DECよりも大きい提示時間を有し得る、復号順でＩ_SAPから開始する少なくとも１つのアクセスユニットが存在し得る場合に対応し得、ここで、Ｔ_DECは、Ｉ_SAUから開始する任意のアクセスユニットの最も早い提示時間とし得る。

例えば、タイプ６の場合、Ｔ_EPT＜Ｔ_DEC＜Ｔ_SAPである。このＳＡＰタイプは、正しく復号されないことがあり、Ｔ_DECよりも大きい提示時間を有し得る、復号順でＩ_SAPから開始する少なくとも１つのアクセスユニットが存在し得る場合に対応し得、ここで、Ｔ_DECは、Ｉ_SAUから開始する任意のアクセスユニットの最も早い提示時間とし得ない。

ＤＡＳＨのプロファイルは、相互運用性、および特徴（feature）の使用の伝達を可能にするために定義され得る。プロファイルは、１組の特定の制約を課すことができる。それらの制約は、メディアプレゼンテーション記述（ＭＰＤ）文書およびセグメントフォーマットの特徴に課すことができる。制約は、メディアコンテンツタイプ、メディアフォーマット（複数可）、コーデック（複数可）、および／もしくは保護フォーマットなどの、しかし、それらに限定されない、セグメント内で配信されるコンテンツに、ならびに／またはビットレート、セグメント持続時間、セグメントサイズ、水平視覚提示サイズ、および／もしくは垂直視覚提示サイズなどの、しかし、それらに限定されない、定量的な尺度に課すことができる。

図１０は、ＤＡＳＨにおける６つのプロファイルの例の図を示している。プロファイルは、セグメントのために使用されるファイルコンテナのタイプに基づいて、２つの主要なカテゴリに組織化され得る。３つのプロファイルは、ＩＳＯベースメディアファイルコンテナを使用することができ、２つのプロファイルは、ＭＰＥＧ−２トランスポートストリーム（ＴＳ）ベースのファイルコンテナを使用することができ、１つのプロファイルは、両方のファイルコンテナタイプをサポートすることができる。どちらのコンテナタイプも、コーデック独立とすることができる。

ＩＳＯベースメディアファイルフォーマットオンデマンドプロファイルは、オンデマンドコンテンツに対するサポートを提供することができる。このプロファイルは、各表現が単一のセグメントとして提供され得ること、サブセグメントが適応セット内の表現にわたってアラインメントされ得ること、および／またはサブセグメントがストリームアクセスポイントから開始し得ることを指定することができる。このプロファイルは、最小量のコンテンツ管理を用いて、大きなＶｏＤライブラリをサポートするために使用され得る。それは、ＨＴＴＰサーバのスケーラブルな効率の良い使用を可能にすることができ、および／またはシームレスな切り換えを単純化することができる。

ＩＳＯベースメディアファイルフォーマットライブプロファイルは、持続時間が相対的に短いＩＳＯファイルフォーマットの単一のムービーフラグメントから成るセグメントのライブ符号化および低待ち時間配信のために利用され得る。各ムービーフラグメントは、テンプレート生成のＵＲＬを使用して、利用可能なときに要求され得る。各セグメント要求の前にＭＰＤ更新を要求することは不要にすることができる。このプロファイルでは、セグメントは、セグメント境界で連結され得るように制約され得る。セグメントは、適応セット内の表現の適応切り換えにも関わらず、メディアデータ内にギャップおよび／またはオーバラップを有さずに暗号解除され得る。このプロファイルは、非ライブコンテンツを配信するために使用され得る。例えば、ライブメディア提示は終了され得たとしても、オンデマンドサービスとして利用可能に保たれ得る。

ＩＳＯベースメディアファイルフォーマットメインプロファイルは、ＩＳＯベースメディアファイルフォーマットオンデマンドおよびライブプロファイルのスーパーセットとすることができる。

ＭＰＥＧ−２ ＴＳメインプロファイルは、ＭＰＥＧ−２トランスポートストリーム（ＴＳ）コンテンツのためのメディアセグメントフォーマットに制約を課すことができる。例えば、表現は、例えば、クライアントにおいてメディアストリーム（例えば、オーディオおよびビデオ）の結合が必要とされなくてよいように、多重化され得る。セグメントは、ＭＰＥＧ−２ ＴＳパケットの整数番号を含むことができる。インデックス付けおよびセグメントアラインメントが推奨され得る。

ＭＰＥＧ−２ ＴＳシンプルプロファイルは、ＭＰＥＧ−２ ＴＳメインプロファイルのサブセットとすることができる。それは、例えば、シームレスな切り換えの簡単な実施を可能にするために、コンテンツ符号化および多重化に制約を課すことができる。例えば、シームレスな切り換えは、ＩＳＯ／ＩＥＣ １３８１８−１に準拠するメディアエンジン（例えば、ＭＰＥＧ−２システム）が、同じ適応セット内の任意の表現からの連続するセグメントを連結することによって生成された任意のビットストリームを再生し得ることを保証することによって達成され得る。

フルプロファイルは、ＩＳＯベースメディアファイルフォーマットメインプロファイルおよびＭＰＥＧ−２ ＴＳメインプロファイルのスーパーセットとすることができる。

モバイルデバイスの画面上に表示される視覚情報の目的地は、それを持っているユーザとすることができる。しかしながら、ユーザの観視セットアップは変化し得る。例えば、ユーザは、モバイルデバイスを目の近くに持つことがあり、または腕を伸ばして持つことがある。これは、視野角、および／または画面上の細部を見るユーザの能力に影響し得る。照明などの、しかし、それに限定されない、他の外的要因も変化し、ユーザの観視エクスペリエンスを変化させ得る。例えば、ユーザは、オフィス、日光が直射する屋外、日陰、または完全に暗いエリアにいることがある。ユーザは、デバイスの画面上のコンテンツに細心の注意を払っていることがあり、または何か別のことで忙しく、モバイルデバイスの画面は時々見るにすぎないことがある。デバイス（例えば、モバイルデバイス）とは、例えば、無線送受信ユニット、ストリーミングビデオプレーヤ、ビデオチャットアプリケーション、ビデオアプリケーション、またはビデオゲームアプリケーションのこととすることができる。

モバイルデバイスの観視条件の変動性の例が説明され得る。そのような条件は、ユーザが視覚情報をどの程度受け取り得るかを示すことができる。それらは、視覚情報をユーザに配信する通信システムにおける最終リンクとしての役割を果たし得る、「視覚チャネル」の容量を定義するために利用され得る。

モバイルデバイスへの視覚情報の配信は、可能な限り最良のユーザエクスペリエンスを実現し、ならびに／または無線ネットワークのリソース（例えば、帯域幅、容量など）および／もしくはモバイルデバイスのリソース（例えば、電力）を節約するように、ユーザ挙動および／または観視条件に適応することができる。モバイルビデオストリーミングおよびモバイルビデオ電話のためのアプリケーションが提供され得る。例えば、観視セットアップのパラメータ、照明のタイプ、モバイル画面の制限、人間の視覚系の制限など、視覚リンクの特性およびそれに影響する要因が利用され得る。

視覚コンテンツの観視条件適応符号化および配信によって改善され得るアプリケーションが存在し得る。例えば、これらは、限定することなく、モバイルビデオストリーミング、モバイルＴＶ、モバイルビデオ電話、ビデオゲーム、および拡張現実を含むことができる。本明細書で説明されるそのようなアプリケーションのクラスは、限定することなく、モバイルビデオストリーミングおよびビデオ電話を含む。モバイルビデオストリーミングまたはモバイルマルチメディアストリーミングは、メディアファイル全体が配信されるのを待つことなく、リアルタイム再生およびＶＣＲタイプのナビゲーションを可能にし得る、マルチメディアコンテンツの増加的配信のための技法とすることができる。

図１１はストリーミングメディアコンテンツのモバイルデバイスへの配信に関連する構成要素および通信リンクの例を示している。ストリーミング配信のために、コンテンツが獲得され、符号化され得る。例えば、これは、Ｒｅａｌ Ｐｒｏｄｕｃｅｒ（登録商標）、Ｗｉｎｄｏｗｓ Ｍｅｄｉａ Ｅｎｃｏｄｅｒ（登録商標）、およびＡｄｏｂｅ Ｍｅｄｉａ Ｅｎｃｏｄｅｒ（登録商標）などの、しかし、それらに限定されない、専用符号化ソフトウェアによって行われ得る。その後、コンテンツは、ストリーミング技術に応じて、専用ストリーミングサーバ、標準的なＨＴＴＰサーバなどとすることができる、サーバ上に配置され得る。コンテンツは、例えば、配信能力を拡大するために、いわゆるコンテンツ配信ネットワーク（ＣＤＮ）を形成する、複数のサーバ上にも配置され得る。ストリーミングメディアコンテンツの消費者は、ユーザとすることができ、ユーザは、モバイルデバイス上でストリーミングメディアプレーヤまたはウェブブラウザなどのソフトウェアを使用していることがある。メディアプレーヤは、サーバとの接続を開始し、維持することができる。今度は、サーバが、符号化メディアのセグメントをプレーヤに送信することができ、次に、プレーヤが、それを画面上に表示することができる。

ストリーミングメディアコンテンツの配信には、いくつかの通信リンクが関連し得る。これらは、ストリーミングサーバと無線ネットワークゲートウェイ（ＧＷ）の間のインターネット接続およびルーティング経路、ユーザデバイス（例えば、ＵＥ）と基地局（例えば、ｅＮＢ）の間の無線リンク、ならびにユーザの目とモバイルデバイスのディスプレイの間の「視覚リンク」を含むが（例えば、図１１を参照）、それらに限定されない。

帯域幅適応が利用され得る。帯域幅適応ストリーミングでは、マルチメディアコンテンツは、いくつかの異なるビットレートで符号化され得、その一例が、図１２に示されている。図１３は、帯域幅適応マルチメディアストリーミングの一例を示している。レートが異なるビデオコンテンツは、空間分解能も異なるように符号化され得る。マルチメディアコンテンツは、異なるレートのストリーム間での移行が一定の時間間隔（例えば、２〜５秒）で可能なように準備され得る。異なるストリームによって異なる空間分解能が使用される場合、解像度の変化が目立ち得ないように、メディアプレーヤは、ビデオをスケーリングして、画面上の同じ領域を満たすことができる。

符号化の後、コンテンツは、ストリーミングサーバから利用可能にすることができ、要求時にはクライアントに配信され得る。初めに、サーバは、デフォルトの初期ビットレートでコンテンツをストリーミングすることができる。ビットレートは、例えば、ネットワークで利用可能な帯域幅に基づいて、ストリーミングセッション中に変化し得る。レートは、クライアントの要求に応じて直接的に変化することができ、またはサーバが、クライアントからのフィードバックに基づいて判断を下すことができる。

マルチメディアコンテンツの配信のために利用され得る配信メカニズムは、ＨＴＴＰストリーミングおよびＲＴＰ／ＲＴＳＰストリーミングを含むが、それらに限定されない。ＨＴＴＰストリーミングでは、区分けされたコンテンツ（例えば、長さが数秒のセグメントに分割されたコンテンツ）が、ＨＴＴＰを介して配信され得る。セグメントは、再送に起因する遅延が生じ得ることを代償として、確実に配信されることが保証され得る。ＲＴＰ／ＲＴＳＰストリーミングでは、コンテンツは、パケット化され、ＵＤＰを介して配信され得る。これは、パケットが失われ得ることを代償として、再送遅延を回避することができる。ＨＴＴＰストリーミングシステムの例は、ＭＰＥＧ／３ＧＰＰ ＤＡＳＨ（登録商標）、およびＡｐｐｌｅ（登録商標）のＨＬＳ（登録商標）である。Ｒｅａｌ Ｎｅｔｗｏｒｋｓ（登録商標）のＨｅｌｉｘ（登録商標）サーバは、様々なＨＴＴＰおよびＲＴＰ／ＲＴＳＰストリーミングプロトコルをサポートすることが可能であり得る。

モバイルストリーミングのための帯域幅適応が利用され得る。ストリーミングビデオが無線上で配信される場合、（例えば、ユーザデバイスを基地局に接続する（例えば、図１１を参照））無線リンクの負荷および他の特性によって引き起こされる帯域幅変動が予想され得る。帯域幅適応ロジックは、基地局（例えば、ｅノードＢ）、および／または無線リンクの近くに配置され得る別のサーバ（例えば、プロキシ）上で実施され得る。これは、より高速な応答、および達成され得る適応の粒度をもたらすことができる。そのようなサーバは、例えば、複合的な１組の符号化ストリームを受信し、スケーラブルな符号化を行うことによって、および／またはリンク上で送信される情報の動的トランスコーディングを実施することによって、適応を実施することができる。

モバイルビデオ電話は、異なる場所にいるユーザによって発信されたオーディオ−ビデオ信号を受信および配信するための技術を含むことができる。目的は、彼らの間でリアルタイム通信を可能にすることとすることができる。

本明細書で説明される実施は、例えば、消費者レベルのビデオ通信／メッセージングアプリケーション、モバイルビデオ会議アプリケーション、モバイルビデオ電話アプリケーションに適用可能とすることができる。そのようなシステムのアーキテクチャの一例が、図１４に示されている。モバイルデバイスは、オーディオおよびビデオ情報をキャプチャし、それを符号化し、ならびに／またはそれを無線リンクおよび／もしくは有線リンクの組み合わせを通して他のデバイスに送信することができる。この情報が（例えば、モバイルデバイスを介して）ひとたび受信されると、それは、復号され、ユーザに提示され得る。ビデオおよびオーディオデータは、ＲＴＰ／ＵＤＰパケットとして送信され得るが、その理由は、例えば、そのようなシステムのリアルタイム性にある。ＲＴＰ／ＵＤＰパケットは、送信中に失われることがある。品質をコントロールするために、モバイルデバイス（例えば、ビデオフォン）は、ＲＴＣＰなどの、しかし、それに限定されない、フィードバックプロトコルを利用することができる。電話は、ＳＩＰまたはＩＴＵ−Ｔ Ｈ．３２３／Ｈ．２２５などの、しかし、それらに限定されない、標準的なセッション開始プロトコルを使用してかけることができる。

いくつかの通信リンクが、モバイルビデオ電話アプリケーションにおける情報の送信に関連し得る。例えば、通信リンクは、無線ネットワークゲートウェイ（ＧＷ）間のインターネット接続／ルーティング経路、ユーザデバイス（例えば、ＵＥ）と基地局（例えば、ｅＮＢ）の間の無線リンク、ならびにユーザとモバイルデバイスのディスプレイおよびカメラとの間の「視覚リンク」を含み得るが（例えば、図１４を参照）、それらに限定されない。

インターネットおよび無線リンクの特性、挙動、および／または制限が、理解され得、ビデオフォンシステムは、いくつかのメカニズムを利用して、それらに適応することができる。そのようなメカニズムは、例えば、帯域幅適応ビデオ符号化、フィードバックの使用、誤り耐性、および誤り隠蔽技法を含むことができる。本明細書で説明される実施は、例えば、ビデオ送信および／または通信を改善するために、変化する観視距離、照明、および画面に払うユーザの注意などの、しかし、それらに限定されない、「視覚リンク」の特性および制限要因を利用することができる。

ディスプレイとユーザによって形成されるリンクとすることができる「視覚リンク」の特性が、本明細書で説明され得る。モバイル観視セットアップのパラメータの例が、図１５に示されている。例えば、水平スライスが示されており、例えば、水平約１２０°の視野が、両眼視によって形成され得ることが仮定され得る。視覚パラメータは、画面サイズ、画面までの距離、画面解像度、（例えば、ピクセル／インチ単位の）画面密度、または視野角を含むことができるが、それらに限定されない。いくつかの視角パラメータは、相互に関連し得る。例えば、（例えば、図１５に示されるような）視野角は、

と計算され得る。

視野角は、ユーザが獲得し得る「有益な」視覚情報の量を制約し得る。映画館またはリビングルームにおいて使用されるものなどの静止観視環境では、視野角は、例えば、約３０°以上など、大きくすることができる。規格（例えば、ＳＭＰＴＥ ＥＧ−１８−１９９４）は、映画再生のための最小許容可能視野角として３０°を宣言し得る。モバイル環境では、視野角は、例えば、モバイル画面の小さいサイズのせいで、はるかに小さいことがある。より多くを見るために、観視者は、フォンを目により近づけることができる。しかしながら、人々が異なる観視距離を使用すること、および多くの場合、そのような距離がモバイル画面の小さい寸法を補償するのに十分な短さになり得ないことには、いくつかの自然な限界および理由が存在し得る。

観視距離の範囲は、個人個人、様々であり得る。異なる距離にある物体を見る能力は、人間の目の調節と呼ばれるメカニズムのおかげであり得る。それは、遠くの光源から来る光が網膜上に焦点を結ぶように、人間の目の水晶体の湾曲が変化し得るプロセスとすることができる。湾曲のそのような変化は、毛様筋によって引き起こされ得る。毛様筋が弛緩しているとき、目は、無限遠に焦点を合わせることができる。緊張を加えることによって、水晶体の湾曲が増し、より近い物体からの光が網膜上に焦点を結ぶことが可能になる。しかし、水晶体は、無限に「絞る」ことはできない。水晶体によって光が網膜上に焦点を結ぶようにし得る最短距離は、明視距離（ＬＤＤＶ：ｌｅａｓｔ ｄｉｓｔａｎｃｅ ｏｆ ｄｉｓｔｉｎｃｔ ｖｉｓｉｏｎ）と呼ばれる。通常の視力を有する大多数の成人の場合、ＬＤＤＶは、約２５ｃｍ（１０インチ）とすることができる。この数は、若者の場合は、より小さくなり得るが、年齢とともに（例えば、毛様筋の働きが鈍るので）増加し得る。

ＬＤＤＶは、モバイルデバイスの観視距離の下限を設定し得る。他の自然の限界は、ユーザの腕の長さであり得る。この数は、ユーザの身長に関連し得る（例えば、身長が５フィート９インチの人の場合、約２６インチ）。モバイルデバイスのサイズ／タイプ、環境、および／または異なる人々が異なる観視距離にそのようなデバイスを持つもしくは置く原因であり得る個人的な快適感を含むが、それらに限定されない、他の要因も存在し得る。いくつかの限界内で、ユーザは、画面をより近くまたは遠くに持つことによって、最良の知覚品質を達成しようと努めることもできる。観視距離の範囲は、約７．５インチから２３．６インチとすることができる。平均観視距離は、約１２．７インチとすることができ、標準偏差は、約３インチとすることができる。これは、かなり広がった分布を意味し得る。±１σの範囲は、９．７インチから１５．７インチの距離の範囲に対応し得る。±２σの範囲は、６．７インチから１８．７インチの距離の範囲を意味し得る。図１６は、この分布の近似的な形状の一例を示している。

空間密度制限が説明され、利用され得る。視覚情報の量は、空間密度によって制限され得る。限界は、例えば、モバイルデバイス上の画面の空間密度、および／または人間の視覚の空間感度限界を含むことができる。

ディスプレイの空間密度または解像度は、ピクセル／インチ（ｐｐｉ）などの、しかし、それに限定されない、絶対メトリックで報告され得る。１°の視野角に対応するピクセルの数などの、しかし、それに限定されない、角度特性が、本明細書では使用され得る。観視距離が知られている場合、１°の視野角に対応するピクセルの数は、

と計算され得る。

人間の視覚系（ＨＶＳ）は、それ自体の限界を空間分解能に設け得る。視力限界は、通常の（例えば、いわゆる「２０／２０」）視力を有する人々が、１°の視野角の１／６０に相当する小ささの空間的細部を認識し得ることを表明し得る。これは、人間の視力限界に適合する、またはそれを超えるには、画面密度および画面までの観視者の距離を、結果の角密度が１°の視野角当たり少なくとも６０ピクセルであるようにすればよいことを意味し得る。この限界をかなりの程度超えたとしても、通常の視力を有するユーザはそれを認識し得ないので、それは低下したリターンをもたらし得る。

観視環境の例が、本明細書で説明され得る。表１は、いくつかの可能な観視環境のパラメータの例を提供している。表１は、ラップトップ、タブレット、およびスマートフォンなどの、しかし、それらに限定されない、現代のモバイルデバイスのいくつかのクラスと、様々な可能な観視距離とを考察し得る。下線を引いたケースは、従来の環境でＴＶまたは映画を見るには十分に広いと考えられ得る、視野角が３０°以上であり得る場合とすることができる。二重下線を引いたケースは、再生セットアップの角密度が視力限界を超え得る場合とすることができる。

いくつかのモバイルデバイス（例えば、スマートフォン）は、例えば、５°未満（ｓｕｂ−５°）から２０°台半ば（ｍｉｄ−２０°）まで、非常に広い範囲で変動する視野角を有し得る。しかし、非常に短い観視距離であっても、それらは、いくつかの再生セットアップにとって望ましい３０°に達し得ない。より大型のデバイス（例えば、ラップトップまたはタブレット）は、３０°以上の視野角に対応し得る。モバイル画面によって達成可能な角密度は、人間の視覚の視力限界に適合すること、またはそれを超えることがある。モバイルディスプレイ技術は、観視者がもはや受け取り、認識し得ない密度で、視覚コンテンツを再生することが可能であり得る。例えば、観視距離が長くなるほど、角密度は高くなり、視覚リンクにおける送信機（例えば、ディスプレイ）と受信機（例えば、人間の目）の能力のアンバランスも大きくなる。将来のディスプレイ技術では、このアンバランスが増大し得る。そのような状況下では、画面によってサポートされる最高の空間分解能で自然な視角コンテンツを符号化し、配信することは、ますます無駄になり得る。

照明の効果が説明され、利用され得る。変化する観視距離および角度に加えて、モバイル観視エクスペリエンスは、様々な照明環境によっても影響され得る。これらの環境は、観視場所（例えば、屋内もしくは屋外）、時刻、季節、地理位置、および／または他の多くの要因によって変化し得る。

モバイル画面によって発せられる光は、様々な周辺光源から反射される光と「混合」され得る。結果として、画面に投影される画像の色は、「洗い落され」得る。これは、例えば、コントラストの低下、色域の減少、およびカラーバランスのシフトに関して定量化され得る。例えば、コントラスト比は、総表示輝度をそれぞれ白状態と黒状態に分けることによって計算され得る。周辺照明下のディスプレイからの総輝度は、

と計算され得る。Ｌ_displayは、ディスプレイから発せられる輝度とすることができ、Ｌ_specおよびＬ_diffは、直接光源および拡散光源からの照度とすることができ、Ｒ_specおよびＲ_diffは、モバイル画面の正反射率特性および拡散反射率特性とすることができる。コントラストは、適度の照度であっても、速やかに低下し得る。

画面のコントラストの低下がもたらす結果の１つは、人間の観察者が見ることのできる空間周波数の範囲の減少であり得る。これは、人間の視覚のいわゆるコントラスト感度関数（ＣＳＦ）を考察することによって説明され得る。この関数の例示的なプロットが、図１７に示されている。

コントラストが非常に高い場合、可視周波数の範囲は、例えば、図１７の最右端によって示されるように、視力限界によって制限され得る。コントラスト比が小さい場合、それは、１点または２点でＣＳＦに接触する下側境界を定め得る。右側の点は、最大可視空間周波数を定め得る。左側の点は、最小可視空間周波数を定め得る。コントラストをさらに下げることによって、可視周波数の範囲は、例えば、ＣＳＦ曲線のピークに対応する範囲まで減少させられ得る。そのピークは、視角の度数当たり３〜６サイクルの間にあり得る。それは、視力限界から約５〜１０倍の隔たりであり得る。

照度は、例えば、瞳孔の狭まりを通して、視覚に対する付加的な影響を有し得る。高い照度では、瞳孔が狭まり得、角膜（例えば、「水晶体」）の不完全性によって引き起こされる歪みを低下させ得る。これは、上で説明された効果を（例えば、ある程度）打消し得る。

画面の傾きが説明され、利用され得る。モバイル画面の傾きとは、面に対する法線とユーザの観視方向（例えば、視軸）との間の角度のこととし得る。例えば、図１５に示されるように、傾きは、０°にすることができる。傾きは、変化し得る。傾き角度は、例えば、明るさ、コントラスト、色などに影響し得る。例えば、ｉＰｈｏｎｅ ４（登録商標）の３０°の傾きは、明るさの５７％の減少、およびコントラスト比の２倍を超える低下を引き起こし得る。

関心ポイントが説明され、利用され得る。ユーザが画面を見ているとき、その目は、画面上のある領域に焦点を合わせ得る。人間の視力は、そのような焦点において最大になり得（例えば、中心窩の投影像）、どの方向でもそれから離れるにつれて衰え得る。例えば、視覚情報の約５０％は、固視点から僅か２°の範囲内で獲得され得る。

３Ｄコンテンツにおいて知覚される深度への影響が説明され、利用され得る。３Ｄビデオの再生が利用される場合、観視者の距離についての情報が利用され得る。例えば、３Ｄビデオ試作品の知覚される３Ｄ深度が影響され得る。例えば、知覚される深度は、

によって表現され得、ここで、Ｄは、知覚される深度とすることができ、ｆは、画面までの距離とすることができ、αは、ピクセル密度とすることができ、ｂは、２つの目の間の基線距離（例えば、ユーザのＩＰＤ）とすることができ、ｄは、画面上の対象物の（例えば、ピクセル単位での）視差とすることができる。

画面までの観視者の距離は、視差を調整するために、および／または別のビューを取り出し、示して、深度歪みを補償するために使用され得る。３Ｄ観視のための観視者距離に基づいた適応は、人間の視覚の輻輳距離と焦点距離の間の差、および関連する「快適ゾーン（zone of comfort）」の概念を考察することによって理解され得る。

図１８は、様々な観視状況における輻輳距離と焦点距離の一例を示している。左側の３つの欄は、自然視（Ｎ）、光学補正（例えば、眼鏡）を施した自然視（Ｇ）、およびステレオ３Ｄ視（Ｓ）の例を示している。自然視では、輻輳刺激および焦点刺激は、同じ距離にあり得、したがって、互いに整合性があり得る。屈折異常に対する光学補正（例えば、眼鏡またはコンタクトレンズ）を施した自然視では、補正による焦点力（focal power）の一定の減少または増加のために、焦点距離は、輻輳距離と異なり得る。ステレオ視は、例えば、輻輳距離は画像内容に応じて変化し得るのに対して、焦点距離は一定であり続け得るので、輻輳距離と焦点距離の間に不一致を生み出し得る。

図１８の右側は、左側に例示された６つの観視条件について、ジオプタ（diopter）単位の輻輳距離の関数として、ジオプタ単位の焦点距離の例示的なプロットを示している。緑の線は、自然視の一例を示し、青の線は、光学補正を施した自然視の一例を示し、赤の線は、ステレオ表示を見る場合の一例を示している。軸上には近距離および遠距離が示されている。

図１９は、両眼単一明視域（ＺＣＳＢＶ：ｚｏｎｅ ｏｆ ｃｌｅａｒ ｓｉｎｇｌｅ ｂｉｎｏｃｕｌａｒ ｖｉｓｉｏｎ）の一例を示している。焦点距離および輻輳距離が、それぞれ縦座標および横座標にジオプタ単位でプロットされ得る。破線の対角線は、自然視に関連する輻輳刺激および焦点刺激の一例を表し得る。「最小相対輻輳」と表記された線は、各焦点距離において、観視者が刺激ターゲットの単一の焦点が合った像を維持し得る、最小の輻輳距離を表し得る。「最大相対輻輳」と表記された線は、観視者が単一の焦点が合った像を維持し得る、最大の輻輳距離を表し得る。

観視条件に対する適応を提供し得る実施が説明され、利用され得る。ユーザがモバイルデバイスを持ち得る方法には変動性が存在し得、それが、ユーザが獲得し得る視覚情報の量に影響し得る。例えば、表１に例示されるように、モバイルフォン画面の異なる観視距離および向きは、例えば、約５°から２５°までの、視野角の変化を引き起こし得る。これは、高密度のモバイル画面を仮定すると、視覚リンクの帯域幅の５倍の変動性を意味し得る。周囲照度は、コントラスト比が、数桁低下する原因になり得る。コントラストの低下は、（例えば、図２０に示されるように）可視空間帯域幅を著しく低下させ得る。明るさおよびコントラストのさらなる２倍の低下は、フォンの画面の傾きによって引き起こされ得る。

ユーザは、画面に細心の注意を払っていることがあり、またはどこか別の所を見ていることがある。ユーザが画面に細心の注意を払っている場合、ユーザは、配信される可能な限り最良のビデオ品質から利益を得ることができる。ユーザが画面に細心の注意を払っていない場合、ユーザに少しも不便を感じさせることなく、品質を低下させ得る。ユーザは、画面の一部だけに注意を集中していることがある。（例えば、その関心領域から２〜３度よりも大きく）空間的に離れた場所に存在する細部は、観察され得ない。

本明細書で説明される実施は、１または複数の観視／視覚パラメータ（例えば、本明細書で説明されるパラメータ）を利用するシステム設計において改善を提供し得る。観視／視覚パラメータは、例えばネットワーク上の負荷、電力利用を低減するために、また最良の感知可能な品質の視覚情報をユーザに配信するために使用され得る。観視／視覚パラメータを利用する実施は、本明細書では、観視条件適応と呼ばれることがある。

本明細書で説明される実施は、ユーザへのコンテンツの配信における異なるポイントに配備され得る。利用される視覚パラメータ（複数可）の有効性は、ユーザのデバイス、視覚、および／または他の特性に依存し得る。例えば、低密度画面を使用し、および／または２０／２０よりも良い視力を有するユーザは、観視距離適応を利用する実施から利益を得られないことがあるが、他の技法が有益なことがある。

ビデオ処理チェーンツールが提供され得る。観視条件適応は、例えば、モバイルビデオストリーミング、ビデオ電話アプリケーションなど、視覚情報を配信し、および／またはそれをモバイル画面上に投影するシステムの一部とすることができる。そのようなシステムは、ビデオビットレートと品質をトレードオフするための手段を有することができる。そのような手段は、（例えば、ストリーミングビデオのために）複数レートのまたはスケーラブルなビデオ符号化／復号を行う機能、（例えば、ビデオ電話アプリケーションにおいて）コーデック／ビデオ符号化／復号チェーンのパラメータを動的に変更する機能などを含むことができるが、それらに限定されない。

符号化ビデオの空間分解能の変更は、異なるビットレート（例えば、空間帯域幅）を達成するための１つの方法であり得る。これは、例えば、（例えば、コーデックが解像度の動的変更をサポートする場合）コーデック内で、または前処理および／もしくは後処理ロジックを用いて達成され得る。

プリプロセッサは、ビデオの解像度を引き下げる（例えば、動的に引き下げる）ことができる。ポストプロセッサは、ビデオをアップサンプリングするように構成され得る。ローパスフィルタリングが、プリプロセッサにおいて適用され得る。処理チェーンの残りは、元のままに維持され得る。一例が、図２０に示されている。そのようなフィルタは、例えば、低コントラストレジーム（regime）で動作する場合は、バンドパスとすることができる。バンドパスフィルタは、不可視の低周波数を取り除くことができる。信号の帯域幅が低いほど、コーデックは、より低く生成することができる。これは、新しい目標レートまたは量子化ステップサイズ（ＱＰ）パラメータを符号化器に渡すことによって実施され得る。

適応システムにおいてビデオのビットレートと品質をトレードするための手段は、フレームレートを低減すること、「スライドショー」モードに切り換えることなどを含むことができるが、それらに限定されない。これらの手段は、例えば、ユーザに不便さを感じさせることなく品質を低下させ得る場合に（例えば、ユーザが画面に注意を払っていない場合に）、適応ロジックによって起動され得る。

観視条件適応実施のスピードおよび粒度が提供され得る。人間の視覚の自然な限界は、適応が一定の遅延を伴って実行されることを可能にし得る。例えば、１つの特性は、調節遅延と呼ばれることがある。調節遅延は、人間の目が１つの距離から別の距離に焦点を変更するのに要する時間とすることができる。調節遅延は、成人の場合、約３５０ｍｓとすることができる。例えば、これは、ユーザが注意を逸らしていたが（例えば、モバイルデバイスの画面以外の対象を見ていたが）、その後、モバイルデバイスの画面に視線を戻した場合、ユーザの目がモバイルデバイスの画面に焦点を合わせ直すのに、約３５０ｍｓかかり得ることを意味し得る。

一方向通信遅延は、（例えば、ＬＴＥ無線ネットワークでは）１００〜３００ｍｓ以内とすることができる。これは、例えば、モバイルビデオ電話アプリケーションのための範囲とすることができる。遅延は、本明細書で説明される実施を実行して、ユーザに気づかれ得ない方法で観視条件の変更を実行するのに十分であり得る。そのような遅延は、実施が基地局で実行される場合は、より遅くすることができる。そのようなシステムは、（例えば、スケーラブル／階層化方式で符号化された場合）任意の与えられた時間に無線でＷＴＲＵに送信されるビデオのトランスコーディングまたはレイヤの選択を実行することができる。視覚的再生の空間帯域幅が変更され得る。僅かな増加（例えば、オクターブ当たり３〜５ステップ）の変更が導入される場合、変更は、あまり気づかれ得ない。

観視条件適応を利用する実施が説明され、利用され得る。配信システムによって利用され得る適応技法が、本明細書で説明され得る。ユーザの存在の検出およびそれに対する適応、画面の傾きの検出およびそれに対する適応、画面からのユーザの距離の推定およびそれに対する適応、較正試験を用いた画面からのユーザの距離およびユーザの視覚に対する適応、照明条件の推定およびそれに対する適応、ならびにユーザの関心／注意ポイントの推定およびそれに対する適応のうちの１または複数を含むが、それらに限定されない、適応技法の組み合わせのサブセットが利用され得る。

ユーザの存在の検出およびそれに対する適応。ユーザが存在しない場合、システムは、ビデオレートを、例えば、最低の「有料」品質表現に抑制すること、それをスライドショーに切り換えること、および／またはビデオをオフにすることができる。例えば、専用の「ユーザ近接」センサを使用することによって、フォンの前向きカメラを使用することによって、赤外線撮像デバイスを使用することによって、超音波センサを使用することによって、マイクロフォンからの入力を使用することによって、動きセンサを使用することによってなど、ユーザの存在を検出するために利用され得る、いくつかのセンサおよび技法が存在する。

近接センサは、ユーザが電話で話をしているときに、画面のバックライトをオフにするために使用され得る。このセンサからの入力は、コンテンツ（例えば、ビデオ）が配信されているビットレートを停止、または調整（例えば、低減）するために使用され得る。他のセンサからの入力を使用する場合、この入力は、ユーザの存在を示すインジケータに変換され得る。このインジケータは、配信されるコンテンツ（例えば、ビデオ）のレート、品質などについての決定を行うために使用され得る。

前向きカメラからの入力を使用して使用され得る検出ロジックが、本明細書で説明され得る。システムは、前向きカメラから画像を獲得することができる。画像内における顔の位置を見出すために、顔検出アルゴリズムが使用され得る。例えば、システムは、ヴィオラ−ジョーンズ（Viola-Jones）検出器を利用して、顔を検出することができる。顔が見出された場合、ユーザが存在するという決定が下され得る。顔が見出されない場合、ユーザは前向きカメラの視野の外側、または顔認識アルゴリズムの範囲外にいるという決定が下され得る。そのような一例が、図２１に示されている。広角カメラおよび狭角ディスプレイの場合、画面上に表示されたコンテンツをユーザが見ることができないことが推測され得る。ユーザが範囲外にいる場合、ユーザは、フル画面解像度を知覚し得ないことがある。

画面の傾きの検出およびそれに対する適応が、本明細書で説明され得る。モバイルデバイスは、モバイルデバイスの画面に対するユーザの位置および／または向きを推定するために使用され得るセンサを含むことができる。例えば、センサは、フォンの前向きカメラ、赤外線センサ、超音波センサ、マイクロフォンアレイなどを含むことができるが、それらに限定されない。システムは、フォンの前方の場の（例えば、可視光、ＩＲ、ソナーベースなどの）画像を獲得することができる。システムは、人間の顔の位置を検出することができる。システムは、その位置に関する角度を計算することができる。例えば、カメラがセンサとして使用される場合、カメラ（例えば、前向きカメラ）からの画像が、キャプチャされ、人間の顔を検出するために利用され得る。ヴィオラ−ジョーンズ検出器などの、しかし、それに限定されない、顔検出技法が利用され得る。顔が検出されない場合、システムは、ユーザの観視方向がカメラの画角の少なくとも半分は逸れていると推測し得る。例えば、これは、図２１に例示され得る。ユーザの顔が検出された場合、傾きは、

と計算され得る。

傾きがひとたび決定されると、視野角の関数としてのコントラストおよび／または明るさなどの、しかし、それらに限定されない、モバイル画面の１または複数の観視特性が、デバイスのセットアップを用いて達成可能であり得る明るさおよび／またはコントラストの限界を獲得するために利用され得る。システムは、（例えば、おそらくは照明についての情報と組み合わされる）１または複数の特性を利用して、画面上の可視空間周波数の範囲を検出することができる。１または複数の特性は、（例えば、周波数の範囲が検出された後）コンテンツの符号化のために使用され得る、空間分解能および／またはフィルタパラメータについての決定を推進するために使用され得る。

画面からのユーザの距離の推定およびそれに対する適応が説明され得る。画面に対するユーザの距離を検出するために利用され得るセンサおよび技法が存在し得る。これは、例えば、フォンの前向きカメラ、赤外線撮像、超音波センサを使用することによって、またはこれらのセンサからの入力の任意の組み合わせによって行われ得る。

動きセンサは、観視距離の可能な変化を検出するために使用され得る。観視距離の変化は、前向きカメラからの入力を使用して決定され得る。例えば、瞳孔間距離（ＩＰＤ）などの、しかし、それに限定されない、人間の顔特徴は、ユーザの観視距離を分析するために使用され得るメトリックとして利用され得る。

このロジックの一例は、図２２Ａ〜図２２Ｂを参照して説明され得る。関与し得る２つの角度は、フォンの仕様書から知られ得るカメラの画角と、ユーザの目の間の角度（α）である。画像が顔検出器によってキャプチャおよび／または処理される場合、その画像内の（例えば、ピクセル単位で測定される）ユーザの目の間の距離が測定され得る。ユーザの目の間の角度は、

と計算され得る。

この角度は、ユーザとフォンの間の距離ｄに関連し得る。

したがって、この距離は、

と計算され得る。

知り得ない変数は、ユーザのＩＰＤであり得る。ユーザのＩＰＤは、推定され、および／または入力パラメータとして（例えば、特定のユーザのためにカスタマイズされた）アプリケーションに提供され得る。例えば、大多数の成人のＩＰＤは、５０から７５ｍｍの範囲内で様々であり得る。そのような範囲は、推定値として使用され得る。ユーザが自分の正確なＩＰＤをパラメータとして入力した場合、システムの性能は、より正確になり得る。例えば、適応ロジックのためには、観視者距離の下限推定値が分かれば（例えば、分かりさえすれば）十分であり得る。画面を見ている観視者が複数いる場合、画面の最も近くに存在し得る観視者の距離を検出すれば十分であり得る。

ユーザのＩＰＤに基づいてユーザの距離を検出するために利用される実施は、以下のこと、すなわち、ユーザの瞳孔間距離（ＩＰＤ）を推定し、および／またはパラメータとして入力すること、解像度およびカメラの角度などの、しかし、それらに限定されない、カメラパラメータを獲得すること、前向きカメラを使用して画像をキャプチャすること、画像内における人間の顔の存在、および／または位置を検出すること、画像内でユーザの目の間の距離（例えば、ピクセルレベルの距離）を測定すること、ならびに知られた量に基づいて画面までのユーザの距離を計算すること（の、例えば、すべてまたはサブセット）を含むことができる。

画像内での顔（例えば、人間の顔）の検出は、例えば、ヴィオラ−ジョーンズ検出器を使用して達成され得る。検出器は、いくつかの標準的な画像特徴（例えば、ＩＰＤ）のピクセルレベルのサイズを計算することができる。画像内で２以上の顔が検出された場合、画面から顔の１または複数までの距離は安定（stable）され得る。画面に最も近い顔が利用され得る。ユーザの距離は、画面上での可視空間周波数の範囲を検出するために、（例えば、おそらくは照明および視野角についての情報と組み合わせて）利用され得る。可視周波数の範囲は、例えば、ビデオ符号化／復号のために使用される、空間分解能および／もしくはフィルタパラメータを決定するために、ならびに／またはそのようなパラメータを使用して符号化されるストリームに切り換えるために利用され得る。

較正試験を用いた画面からのユーザの距離およびユーザの視覚に対する適応が説明され得る。異なる観視距離において視覚的細部を認識するユーザの能力を検出するための技法は、１または複数の試験を介して決定され得る。例えば、ユーザは、画面を見て、図２３および図２４に示される質問など、しかし、それらに限定されない、一連の質問に答えるように指示され得る。図２３は、最も快適な位置でユーザが見ることができる最小の空間的細部の検出を可能にし得る例示的な質問を示している。図２４の例示的な質問を使用して、ユーザは、そのような細部をまだ見ることができる最も遠い地点までカメラ／画面を動かすように命令され得る。ユーザがそのようにしたことを確認すると（例えば、ＯＫを押すと）、ユーザの写真が撮られ、その顔が検出され、（例えば、ピクセル領域で）ＩＰＤが計算され得、それは、ユーザの観視距離に対応し得る。これは、将来、ユーザがより短いまたはより長い距離にいる状況を検出することができる。１または複数の距離／可視解像度ポイントが決定され得る。例えば、２つの可能な文字サイズを使用して、確認する（例えば、「ＯＫ」を押す）ようにユーザに求めることによって（例えば、図２４の試験を参照）、２つの距離／可視解像度ポイントが獲得され得、それは、任意の距離に対する適応のために十分であり得る。

照明条件の推定およびそれに対する適応が説明され、利用され得る。照明条件は、周囲光センサ情報、前向きカメラ、後向きカメラなどの、しかし、それらに限定されない、１または複数のセンサを使用して評価され得る。そのような情報は（例えば、画面の明るさ設定に関連する情報と一緒になって）、画面の達成可能なコントラストおよび総照明の量を推定するために利用され得る。

推定は、画面の傾きについての情報を使用して精緻化され得る。推定された総照明は、適切なコントラスト感度曲線を選択するために使用され得る。画面のコントラストは、適切なコントラスト感度曲線上の動作範囲を検出するために使用され得る。これは、画面上での可視空間周波数の範囲をもたらし得る。

前面照明および背面照明は、異なる方法でユーザの知覚に影響し得る。例えば、前面照明は、画面から反射され得る。背面照明は、瞳孔の拡張を変化させ得る。ひとたび周波数の範囲が検出され、および／または画面までのユーザの距離が分かると、コンテンツを符号化するために使用される空間分解能および／もしくはフィルタパラメータを決定するために、ならびに／またはそのようなパラメータを使用して符号化されるストリームに切り換えるために、前面照明および／または背面照明が利用され得る。

観視者の注視点の推定およびそれに対する適応が説明され、利用され得る。ユーザは、本明細書で「注視点（point of attention）」（ＰＯＡ）と呼ばれることがある、画面の小さな部分において、ピクチャ細部を知覚することができる。ユーザのＰＯＡの外側の画面領域における解像度は、ユーザに影響を気づかれることなく、低減させ得る。（例えば、より広い視野角において）ユーザが画面から非常に近い距離にいる場合、ユーザのＰＯＡの推定は、有益であり得る。例えば、ユーザのＰＯＡは、コンテンツ導出の顕著点を用いる顕著性ベースの符号化において使用され得る。ユーザのＰＯＡが推定され、ユーザのエクスペリエンスを改善するために使用され得る。ユーザのＰＯＡは、この情報を用いて符号化され得なかった旧式の素材のストリーミングにおいて使用され得る。

ユーザのＰＯＡは、例えば、瞳孔と角膜レンズからの反射との間の角度を測定することによって、前向きカメラを使用して推定され得る。ユーザは、この測定のために近くにいなければならないことがあるが、これは、測定に関連する時間とすることができる。

以下のうちの１または複数が、ユーザのＰＯＡを利用して実施され得、すなわち、各セクション／タイルが数々の解像度またはレイヤで符号化され得る、セクションまたはタイルへのピクチャの分割をサポートする符号化器、前面カメラおよびユーザの観視点を推定するための手順を有するモバイルデバイス、各タイルに最適な解像度を計算するために使用される実施、セクション／タイルに対してどの解像度が使用され得るかをネットワークに知らせるために利用されるシグナリング実施、ならびに適応ネットワークエンティティが、実施され得る。エンティティが符号化器／復号器でない場合、いくつかのレイヤ／レートが、符号化器／復号器および／またはサーバから送信され得、適応エンティティが、それらから選択を行う。適応は、例えば、適応時間を短縮するために、ネットワークノード（例えば、ノードＢ）において実行され得る。表示アルゴリズムが、セクション／タイルを一緒にステッチングすることができる。

コンピュータビジョンおよび／またはコンピュータグラフィックスが利用され得る。例えば、ヴィオラ−ジョーンズ顔検出器およびアイトラッカ（eye tracker）が、固視点を識別するために使用され得る。タイルステッチングは、例えば、スケール不変特徴変換（ＳＩＦＴ：Ｓｃａｌｅ−Ｉｎｖａｒｉａｎｔ Ｆｅａｔｕｒｅ Ｔｒａｎｓｆｏｒｍ）特徴などの、しかし、それに限定されない、局所的特徴を使用することによって行われ得る。

図２５は、観視条件適応システムの一例を示している。モバイルストリーミングビデオシステムは、観視条件に対する適応のための、本明細書で説明される実施のうちの１または複数を含むことができる。図１１は、ストリーミングシステムのアーキテクチャの一例を示し得る。（例えば、ＷＴＲＵ内に存在する）ストリーミングクライアントによって使用される構成要素およびロジックの例は、図２５に示され得る。このクライアントは、異なるレートおよび／または空間分解能で符号化された複数のビデオストリームを記憶し得る、ストリーミングまたはＨＴＴＰサーバと通信することができる。クライアントデバイスは、観視距離および／または照明レベルを推定するために、前面カメラを使用することができる。例えば、（例えば、利用可能な帯域幅についてのクライアントの見解に加えて）これらのパラメータは、クライアントがコンテンツ（例えば、ビデオストリーム）を要求し得る最良の解像度を決定するために使用され得る。

ストリーミングサーバは、クライアントの要求に反応することができる。例えば、ストリーミングサーバは、市販のレート適応ＨＴＴＰおよび／またはＲＴＳＰ／ＲＴＰ準拠サーバとすることができる。システムは、本明細書で説明される実施のすべてまたは任意のサブセットを利用することができる。

無線ネットワークおよび有線ネットワークにおけるストリーミングは、例えば、ネットワークにおける輻輳および他の可能な障害を理由に、可変帯域幅に対する適応を利用することができる。いくつかの目標レートへのマルチメディアコンテンツの同時符号化が利用され得る。これは、クライアントアプリケーションにおけるシグナリングおよびレート切り換えロジックと結合され得る。図２６は、そのようなシステムの例示的なアーキテクチャおよび機能の説明を示している。図２６の例は、適応ＨＴＴＰベースストリーミングシステムの動作を示している。

ストリーミングシステムでは、ストリーム切り換えが、約２〜１０秒とし得る、一定の粒度で可能にされ得る。クライアントが符号化ストリーム間で切り換えを行い得るポイントは、切り換えポイントと呼ばれることがある。切り換えポイントの間の符号化コンテンツの部分は、セグメントと呼ばれることがある。

ストリーミングセッション中、ストリーミングクライアントは、各セグメントの配信のレートを計算することができ、それは、次のセグメントを受信するために利用可能であり得る、ネットワークの帯域幅の推定値をクライアントに与えることができる。この推定値に基づいて、クライアントは、次のセグメントのために使用する次の符号化／レートをどれにするかを決定することができる。クライアントは、そのようなモデルを利用して、変化するネットワーク状態に対して適応することができる。（例えば、おそらくは符号化ストリームのレートを含む）符号化ストリームについての情報（例えば、高水準情報）は、マニフェストファイルまたはマルチメディアプレゼンテーション記述（ＭＰＤ）ファイル内に記憶され得る。ストリーム内の各符号化セグメントについてのオフセットおよびタイミング情報は、セグメントインデックスファイル内に記憶され得る。

符号化メディアセグメント、セグメントインデックス、および／またはメディアプレゼンテーション記述（ＭＰＤ）ファイルのフォーマットが定義され得る。ストリーム切り換えを可能にし得る共通の属性を有する符号化の組は、適応セットと呼ばれることがある。適応セットの要素は、表現と呼ばれることがある。適応セットは、構成要素としてサブ表現を含むことができる。表現およびサブ表現は、オーディオ、ビデオ、テキストなどの、しかし、それらに限定されない、１または複数のメディアコンテンツ構成要素を含むことができる。

ＭＰＥＧ−ＤＡＳＨ適応セット、表現、および／またはサブ表現は、共通の属性を共有することができる。例えば、それらがビデオである場合、それらは、＠ｗｉｄｔｈ、＠ｈｅｉｇｈｔ、＠ｓａｒ、および／または＠ｆｒａｍｅｒａｔｅ属性を有することができる。それらがオーディオである場合、それらは、＠ａｕｄｉｏＳａｍｐｌｉｎｇＲａｔｅ属性を含むことができる。属性は、＠ｍｉｍｅＴｙｐｅ、および＠ｃｏｄｅｃｓ属性を含むことができる。属性は、必須であることも、または必須でないこともある。表現は、＠ｉｄ、＠ｂａｎｄｗｉｄｔｈ、＠ｑｕａｌｉｔｙＲａｎｋｉｎｇなどの、しかし、それらに限定されない、独自の属性を有することができる。

ＭＰＥＧ−ＤＡＳＨストリーミング規格は、例えば、ＴＶセット、コンピュータ、タブレット、およびスマートフォンを含むが、それらに限定されない、再生デバイスに情報を配信するために、汎用的に使用され得る。異なる再生デバイスを使用するときの観視セットアップの特性は、異なり得る。例えば、モバイルデバイスでビデオを見る場合、快適な距離に持たれているとき、それらの小さい画面は、５〜１０°の視野角をもたらし得る。ユーザがデバイスを手に持っている場合、そのような距離は、もはや固定されていないことがあり、例えば、それは、ユーザの姿勢およびコンテンツに払う注意とともに変化し得る。図７および図８は、モバイル環境における観視セットアップのパラメータおよび観視距離の分布の例を示す、図およびチャートを示している。

本明細書で説明されるように、表１は、様々なモバイルデバイスを用いた場合の観視環境の例を示している。モバイル観視は、視野角の広い分布をもたらし得るが、フォームファクタが小さいデバイスの場合、それは小さくなり得る（５〜１０°）。視覚的コンテンツの有効密度は、視力限界を超えることがある。

視覚の時間的特性が考察され得る。１つの時間的特性は、臨界フリッカー周波数（ＣＦＦ：Ｃｒｉｔｉｃａｌ Ｆｌｉｃｋｅｒ Ｆｒｅｑｕｅｎｃｙ）であり得る。図２７は、視軸からの傾きの関数としてのＣＦＦ値のトポグラフィック図の例を示している。これらの測定は、右目について行うことができる。黒い領域は、盲点に対応し得る。図２７から、中央（中心窩）領域では、ＣＦＦが約５５Ｈｚであり得ることが観察され得る。周辺領域では、ＣＦＦは、約８５Ｈｚであり得る。臨界融合周波数（Critical Fusion Frequency）の偏心（例えば、内側の円は、視軸からの３０°のシフトに対応し得る）が、図２７に示され得る。これは、（例えば、広角再生の場合とは対照的に）狭角（例えば、５〜１０°）再生を用いる場合は、ビデオコンテンツの符号化において、より低いフレームレートが利用され得ることを示唆する。

従来の（例えば、３０〜４０°角の）観視のために行われるビデオ符号化は、狭い（例えば、５〜１０°）視野角再生を用いるモバイルユーザが見る、および／または認識し得るよりも、（例えば、空間的および時間的細部に関して）はるかに多くの情報を配信することができる。

狭い視野角再生に対して配信を最適化するために、コンテンツ発行者は、数々の技法を利用することができる。例えば、コンテンツ生成者は、任意の許容可能な組み合わせで、空間的および／または時間的にビデオをダウンサンプリングすること、空間的または時間的な事前フィルタリング技法を適用すること、（例えば、特定の再生セットアップ向けに調整され得るコスト関数と結合され得る、フレーム／スライスレベルおよびＭＢレベルのＲＤ決定モードなどの、しかし、それらに限定されない）符号化器レベルの最適化を使用することなどを行うことができる。

ダウンサンプリングは、ツールを使用して実行され得、任意の追加の属性またはシグナリングを必要とすることも、または必要としないこともある。例えば、ＤＡＳＨ ＭＰＤフォーマットは、＠ｗｉｄｔｈ、＠ｈｅｉｇｈｔ、および／または＠ｆｒａｍｅｒａｔｅ属性を含むことができる。例えば、モバイルデバイスがネイティブで７２０ｐ解像度をサポートする場合、そのような空間分解能で符号化された、しかし、事前フィルタリングおよび符号レベルの最適化を用いて知覚冗長性が除去された、ビデオデータを送信することが望ましいことがある。

例えば、与えられた固定視野角に対してコンテンツ（例えば、ビデオ）を最適化するために、他の実施も使用され得る。自由度の１つである視野角を除外することによって、各符号化の有効性が改善され得る。

例えば、ＤＡＳＨにおいてそのようなカスタマイズされたストリームの使用を可能にするための、追加の属性が、本明細書で開示され得る。ＤＡＳＨ ＭＰＤシンタックスにおける属性は、与えられた表現または適応セット内の符号化コンテンツを観視するための意図された（例えば、最適化）視野角を指定する属性とし得る、＠ｖｉｅｗｉｎｇＡｎｇｌｅを含むことができるが、それに限定されない。＠ｍｉｎＶｉｅｗｉｎｇＡｎｇｅおよび＠ｍａｘＶｉｅｗｉｎｇＡｎｇｌｅは、与えられた表現または適応セットによってサポートされる符号化のための観視距離／レンジの範囲を識別する属性とし得る。

ＤＡＳＨは、＠ｃｕｔＯｆｆおよび／または＠ｆｒｅｑｕｅｎｃｙＲｅｓｐｏｎｓｅを含むことができ、それらは、コンテンツが、符号化される前に、与えられたカットオフ周波数パラメータを用いてローパスフィルタリングされたことを示す属性とし得る。＠ｃｕｔＯｆｆおよび／または＠ｆｒｅｑｕｅｎｃｙＲｅｓｐｏｎｓｅパラメータは、空間的事前フィルタリングを用いるカスタマイズを実施するために十分であり得る。＠ｖｉｅｗｉｎｇＡｎｇｌｅ属性は、そのような決定を符号化器／復号器に委ねることができる。＠ｍｉｎＶｉｅｗｉｎｇＡｎｇｅおよび＠ｍａｘＶｉｅｗｉｎｇＡｎｇｌｅの導入は、範囲を可能にし得、符号化ストリームの記述において使用され得る。

視野角は、少なくとも、画面の物理的サイズ（例えば、画面幅）および観視者と画面の間の距離の組み合わせによって伝達され得る。例えば、視野角は、

によって伝達され得る。

画面の物理的サイズおよび観視者と画面の間の距離は、観視セットアップの特性を提供し得る。例えば、２Ｄ画像／ビデオの再生の場合、視野角が利用され得る。３Ｄ画像／ビデオの再生では、少なくともさらに１以上の自由度が存在し得、したがって、画面の物理的サイズおよび観視者と画面の間の距離の伝達が利用され得る。そのような一例が、図２８に示されている。

図２８は、視野角（α）は同じだが、交角（βおよびβ’）が異なる、２つの環境の例についての図を示している。図２８を参照すると、視野角（α）は、両方の環境で同じであり得る。交角（βおよびβ’）は、異なり得る。交角の差は、観視距離と瞳孔間距離（ＩＰＤ）の間の比が増加するにつれて減少し得る。ＩＰＤは、人によって様々であり得る。例えば、成人の典型的なＩＰＤは、約５０〜７５ｍｍ（１．９６〜２．９５インチ）の間にわたり得る。したがって、３Ｄ再生のための観視環境の伝達は、ユーザのＩＰＤを考慮することができる。

図２８を参照すると、視野角（α）および交角（β）が利用され得る。これらのパラメータは、画面の物理的サイズ、ユーザの目と画面の間の距離、およびユーザのＩＰＤなどの、しかし、それらに限定されない、属性を含むディスクリプタから導出され得る。ディスクリプタは、サブセットが利用され得る、いくつかのパラメータの任意の組み合わせを列挙するようにも定義され得る。例えば、ディスクリプタは、画面の物理的サイズ、ユーザの目と画面の間の距離、および／または視野角などの、しかし、それらに限定されない、パラメータを用いて定義され得る。パラメータの任意の２つは、第３のものを導出するために利用され得る。

本明細書で開示される観視セットアップのパラメータの任意の組み合わせは、適応セット、表現、および／またはサブ表現の事前定義された属性として、ＤＡＳＨ規格のＭＰＤファイル内に含まれ得る。観視セットアップのパラメータの任意の組み合わせは、例えば、ＤＡＳＨ ＭＰＤファイル内の汎用ディスクリプタを用いて伝達され得る。そのような伝達の一例が、以下に示され得る。

そのような伝達の別の例が、以下に示され得る。

例えば、「ｓｃｈｅｍｅＩｄＵｒｉ」は、この属性を使用する仕様および／または配備システムの識別子を提供することができる。Ｂｅｈａｖｉｏｒ属性は、汎用クライアント（例えば、ストリーミングクライアント）がどのようにディスクリプタに反応し得るか（例えば、どれが観視パラメータに関連し得るか）を示すことができる。例えば、ディスクリプタが、必要（例えば、「ｒｅｑｕｉｒｅｄ」、「ｅｓｓｅｎｔｉａｌ」など）と指定される場合、このディスクリプタ（例えば、観視パラメータ）を理解し、および／または利用し得るクライアント（例えば、クライアントだけ）が、そのような表現を使用することができる。「ｂｅｈａｖｉｏｒ」が、任意（例えば、「ｏｐｔｉｏｎａｌ」、「ｓｕｐｐｌｅｍｅｎｔａｌ」など）と指定される場合、クライアントは、ディスクリプタ（例えば、観視パラメータ）を理解しない場合でも、表現を使用することができる。「ｖａｌｕｅ」は、このディスクリプタが１または複数の値を含むことを指定することができる。例えば、本明細書で提供される例では、ｖａｌｕｅは、視野角に関することができる。

例えば、「ｓｃｈｅｍｅＩｄＵｒｉ」は、この属性を使用する仕様および／または配備システムの識別子を提供することができる。例えば、「ｂｅｈａｖｉｏｒ」が、「ｒｅｑｕｉｒｅｄ」と指定される場合、このディスクリプタ（例えば、観視パラメータ）を理解し、および／または利用し得るクライアント（例えば、クライアントだけ）が、表現を使用することができる。「ｂｅｈａｖｉｏｒ」が、「ｏｐｔｉｏｎａｌ」と指定される場合、クライアントは、ディスクリプタ（例えば、観視パラメータ）を理解しない場合でも、表現を使用することができ、または使用できない。「ｖａｌｕｅ」は、このディスクリプタが１または複数の値を含むことを指定することができる。例えば、本明細書で提供される例では、ｖａｌｕｅは、視野角に関することができる。

ディスクリプタは、適応セットレベルで定義することができる。ディスクリプタは、表現および／またはサブ表現レベルで定義することができる。「ｕｒｎ：ｓｄｏ：ｄａｓｈ−ｅｘｔｌ：ｖｉｅｗｉｎｇ−ａｎｇｌｅ」、「ｕｒｎ：ｓｄｏ：ｄａｓｈ−ｅｘｔｌ：ｍｉｎ−ｖｉｅｗｉｎｇ−ａｎｇｌｅ」、および「ｕｒｎ：ｓｄｏ：ｄａｓｈ−ｅｘｔｌ：ｍａｘ−ｖｉｅｗｉｎｇ−ａｎｇｌｅ」などの、しかし、それらに限定されない、ＵＲＩは、視野角の最小値、最大値、および／または望ましい値を識別するために使用され得る。同様のＵＲＩが、例えば、ディスプレイサイズおよび観視距離パラメータの組み合わせなどの、しかし、それに限定されない、そのような情報を伝達する代替方法のために定義され得る。

例えば、ＤＡＳＨストリームクライアントにおいて、視覚的属性を使用するいくつかの方法が存在し得る。例えば、中央値観視距離および／または１もしくは複数の視野角パラメータが利用され得る。例えば、ＤＡＳＨストリーミングアプリケーションは、ＯＳ供給のＡＰＩを使用して、それが動作しているデバイスの物理的パラメータを獲得することができる。そのようなパラメータは、（例えば、ネットワーク接続のタイプから推測され得る）デバイスのモビリティ、画面のネイティブ解像度、画面または画面対角線のピクセルの密度、表示がウィンドウ内で行われ得るかどうか（例えば、ウィンドウのサイズおよびその位置）などを含むことができるが、それらに限定されない。

デバイス上で動作するＤＡＳＨクライアントは、そのサイズも推測することができる。例えば、デバイスがモバイルであり、５インチまたはより小型の画面を有する場合、ＤＡＳＨクライアントは、デバイスがハンドヘルドデバイスであると推測することができる。ＤＡＳＨクライアントは、中央値観視距離特性を選択することができる（例えば、図２６を参照）。クライアントは、視野角を推定することができる。推定値を使用して、クライアントは、例えば、＠ｖｉｅｗｉｎｇＡｎｇｌｅ（および／または＠ｍｉｎＶｉｅｗｉｎｇＡｎｇｅ、＠ｍａｘＶｉｅｗｉｎｇＡｎｇｌｅ、もしくは＠ｃｕｔＯｆｆ、もしくは＠ｆｒｅｑｕｅｎｃｙＲｅｓｐｏｎｓｅ）値を可能な目標として利用する、適応セットおよび表現を選択することができる。

動的に推定される観視距離および／または視野角パラメータが使用され得る。コンテンツ発行者／配信者は、インテリジェントなモバイルストリーミングクライアントアプリケーションを配備することができる。アプリケーションは、センサを使用して、ユーザとデバイスとの間の距離を推定することができる。アプリケーションは、ユーザがコンテンツを見ている（例えば、ビデオを見ている）ときに存在し得る視野角を決定することができる。

図２９は、ユーザの挙動および観視条件に対して適応する例示的なストリーミングシステムの図を示している。クライアントは、（例えば、本明細書で説明された視覚的特性の１または複数を含み得る）そのセットアップに対して最良の適合を達成するストリームを採用することができる。例えば、ユーザの挙動および観視条件、ならびに１または複数の事前に符号化されたストリームに基づいて、クライアントは、異なる視野角に対してコンテンツの配信を最適化することができる。

ＭＰＥＧ−ＤＡＳＨ規格は、ＨＴＴＰベースの適応ストリーミングシステムを設計するためのフレームワークを提供することができる。それは、コンテンツプロパティを説明するための１組の属性を提供して、ストリーミングクライアントが、表現の選択およびコンテンツの表示についての決定を知らされることを可能にすることができる。例えば、ＤＡＳＨにおける符号化ビデオは、＠ｃｏｄｅｃ−使用されるコーデックタイプ、プロファイル、およびレベル、＠ｂａｎｄｗｉｄｔｈ−セグメントを符号化するために使用される目標レート、＠ｗｉｄｔｈ、＠ｈｅｉｇｈｔ、＠ｓａｒ、＠ｆｒａｍｅｒａｔｅ−ビデオ解像度、アスペクトレート、フレームレート、ならびに＠ｑｕａｌｉｔｙＲａｎｋｉｎｇ−適応セット内の他の符号化と比較した品質ランクのうちの１または複数によって記述され得る。

１または複数の属性を使用して、ＤＡＳＨクライアントは、特定のデバイスの表示能力に最も良く適合するコーデックおよびビデオ特性を有する、適応セットおよび／または表現を決定することができる。利用可能なネットワーク帯域幅への調整は、＠ｂａｎｄｗｉｄｔｈ属性を検査すること、および／または異なるレートで符号化されたストリーム間で切り換えを行うことによって達成され得る。

観視位置は、例えば、映画館およびリビングルームなど、しかし、それらに限定されない、観視環境において、画面の広い（例えば、２５〜４０°）視野を達成するために選択され得る。例えば、ＴＨＸは、映画再生に最適な視野角として３６°を提案する。同様に、ＳＭＰＴＥ ＥＧ−１８−１９９４は、少なくとも３０°の広さの視野角を提案する。ユーザがモバイルデバイス（例えば、スマートフォンまたはタブレット）でビデオを見ている場合、視野角は、提案されるそれらよりも小さく（例えば、５〜２０°）することができる。その理由は、モバイルデバイスの制限された物理的寸法、および／またはモバイルデバイスの画面からユーザまでの距離にあり得る。

モバイル観視セットアップのパラメータの例が、図１５に示されている。これらのパラメータは、例えば、以下に従って相互に関連し得る。

表１が以下に再掲されている。表１は、いくつかの可能な観視環境のパラメータの例を提供する。表１では、静止観視セットアップの特性が、モバイルデバイスの例を使用して、可能な環境において比較され得る。

両方の画面の向きに対する視野角が計算され得る。画面上の情報についての結果の空間密度が計算され得る。例えば、空間密度は、

によって表され得る。

例えば、表１に示されるように、モバイル環境における視野角は、小さくすることができる（例えば、フォームファクタが小さいデバイスの場合、５〜１０°）。これは、ＴＶを見ているユーザによって経験される視野角よりも３〜６倍小さいことがある。結果の空間密度は、視力限界と呼ばれることがある、１／６０度に相当する視野角限界を超える。そのような場合の例が、表１に示され得る。場合によっては、密度は、視力限界の２倍を超え得る。

広角視野のために準備されたビデオ内の精細な空間的細部は、モバイル画面上で見えることもあり、または見えないこともある。いくつかまたはすべての空間周波数の可視性は、スケール／角度のシフトによって影響され得る。狭い視野角は、より高い時間的感度を有し得る視覚の周辺領域を排除することができ、潜在的に、広角再生のために通常利用されるよりも低いレートでビデオを表示することが可能になる。

ストリーミングは、異なるデバイスおよび／または再生環境に合せて最適化され得る。例えば、静止（例えば、広角）再生を仮定するビデオの符号化は、小型のモバイルデバイスに配信するために使用される場合、効率的でないことがある。例えば、狭い視野角セットアップを使用して再生が行われ得ることが分かっている場合、同じユーザエクスペリエンスを達成するために、はるかに僅かなビットが利用され得る。

１または複数のコーデックレベルおよび／または事前処理ツールが、狭い視野角セットアップを用いるデバイスのためのコンテンツ（例えば、ビデオ）を符号化および／または処理するために利用され得る。ツールは、符号化前の空間的および／または時間的なビデオのダウンサンプリング、空間的および／または時間的な事前フィルタリング（例えば、符号化前のローパスフィルタリング）、コーデックレベルツール（例えば、量子化、Ｒ／Ｄ決定ツールなど）の使用などを含むが、それらに限定されない。

本明細書で説明される実施は、多くのデバイスで使用され得る符号化ストリームおよび／またはＭＰＤファイルの生成、必要とされるより僅かな符号化および／またはＭＰＤファイル、異なる再生環境のために符号化されるストリーム（例えば、ビットレートおよび／または解像度は同じだが、アピアランス（appearance）が異なるストリーム）の一意的な識別、ならびに（例えば、クライアントが、再生環境およびデバイスに従って、適切な表現を選択することを可能にする）ＤＡＳＨクライアントにおける適応ロジックのうちの１または複数を可能にする属性を提供することができる。例えば、本明細書で説明される実施に従って符号化コンテンツを見るために意図された視野角を記述する１または複数の属性が追加され得る。

本明細書で説明される実施に従って、例えば、表２、表３、および表４に示されるように、以下のうちの１または複数が追加され得る。

符号化は、デバイス特性（例えば、デバイスの観視特性）に基づいて最適化され得る。例えば、適応セットおよび／または表現の存在下では、＠ｖｉｅｗｉｎｇＡｎｇｌｅパラメータのいくつかの異なる値の中で、クライアント（例えば、ＤＡＳＨクライアント）は、どの値を使用すべきかに関して決定を行うことができる。例えば、クライアントアプリケーションは、それが（例えば、ＯＳ供給のＡＰＩを使用して）動作しているデバイスの特性を獲得することができる。そのような特性は、（例えば、ネットワーク接続のタイプから推測され得る）デバイスのモビリティ、表示用に使用され得る画面および／または画面の領域の解像度、画面および／または画面対角線のピクセルの密度などを含むことができるが、それらに限定されない。クライアントは、例えば、デバイスのモビリティタイプおよび画面のサイズに基づいて、デバイスを（例えば、スマートフォン、タブレット、固定デバイスとして）分類することができる。クライアントは、使用され得る観視距離および／または視野角を選択することができる。例えば、スマートフォンの場合、知られた統計に基づいた観視距離の中間値が使用され得る。同様のデータが、他のタイプのデバイスについても存在し得る。クライアントは、例えば、観視距離および／もしくは視野角の推定値を使用して、ならびに／または表現および／もしくは適応セットの＠ｖｉｅｗｉｎｇＡｎｇｌｅ属性の宣言値を使用して、使用すべき適応セットおよび／または表現を選択することができる。例えば、プレーヤ（例えば、ＤＡＳＨプレーヤ）は、特定のデバイスにおける最良の観視のために採用されるストリームの選択を達成することができる。コンテンツおよび／またはＭＰＤファイルのカスタム（例えば、デバイス別の）オーサリング（authoring）は、不要にすることができる。

符号化は、動的に推定される観視距離および／または視野角パラメータに基づいて最適化され得る。適応セットおよび／または表現の存在下では、＠ｖｉｅｗｉｎｇＡｎｇｌｅパラメータのいくつかの異なる値の中で、ＤＡＳＨクライアントは、以下のロジックを使用することによって、どの値を使用すべきかについて決定を行うことができ、すなわち、ＤＡＳＨクライアントアプリケーションは、デバイスセンサ（例えば、ユーザ近接センサ、ＩＲ、および／または前向きカメラ）を使用して、ユーザの存在を検出することができ、ユーザが存在する場合は、画面までのユーザの距離を検出することができ、獲得された距離および画面の特性を使用して、ＤＡＳＨクライアントは、視野角を計算することができ、視野角ならびに表現および／または適応セットの＠ｖｉｅｗｉｎｇＡｎｇｌｅ属性の宣言値を使用して、クライアントは、その後、使用するのに最も適切な適応セットおよび／または表現を選択することができる。ＤＡＳＨクライアントにおけるこのロジックの例示的な図説が、図２９に提供されている。図２９に示されるシステムでは、ユーザが存在しない、および／または画面に注意を払っていない場合、クライアントは、インテリジェントな決定を行うこともできる。そのような決定は、ビデオ品質および／もしくはレートを引き下げること、ならびに／または再生を停止することを含むことができるが、それらに限定されない。

本明細書で説明されるように、実施は、マルチメディアコンテンツの観視条件適応に関連する方法およびシステムを提供することができる。例えば、マルチメディアコンテンツ（例えば、ビデオ）は、デバイス（例えば、モバイルデバイス、パーソナルコンピュータ、ビデオ会議デバイスなど）によって、ネットワーク（例えば、ストリーミングサーバ、ＨＴＴＰサーバなどの、しかし、それらに限定されない、ネットワークノード）から受信され得る。ユーザ、デバイス、および／またはコンテンツに関連する観視パラメータ（例えば、複数の観視パラメータ）が、例えば、デバイスによって決定され得る。観視パラメータは、ユーザ観視パラメータ、デバイス観視パラメータ、またはコンテンツ観視パラメータのうちの少なくとも１つを含むことができる。観視パラメータは、複数の観視パラメータを含むことができる。

本明細書で説明されるように、ユーザ観視パラメータは、ユーザの存在、デバイスの画面に対するユーザの位置、デバイスの画面に対するユーザの向き、デバイスの画面に対するユーザの視野角、デバイスの画面からのユーザの距離、ユーザの視力、周囲の照明条件（例えば、周辺光の強度）、デバイスの画面を観視するユーザの人数、またはユーザの注視点のうちの少なくとも１つを含むことができる。

本明細書で説明されるように、デバイス観視パラメータは、デバイスのモビリティ、デバイスの画面のサイズ、デバイスの画面の解像度、デバイスの画面のピクセル密度、デバイスの画面のコントラスト、デバイスの画面の明るさ、デバイス上のマルチメディアコンテンツを表示するウィンドウのサイズ、またはデバイス上のマルチメディアコンテンツを表示するウィンドウの位置のうちの少なくとも１つを含むことができる。本明細書で説明されるように、コンテンツ観視パラメータは、マルチメディアコンテンツのコントラスト、マルチメディアコンテンツの色域、３次元のマルチメディアコンテンツの存在、またはマルチメディアコンテンツの３次元コンテンツの深度の範囲のうちの少なくとも１つを含むことができる。

観視パラメータは、デバイス（例えば、デバイスのプロセッサ、デバイス上のＤＡＳＨクライアント、デバイス上に存在するソフトウェアなど）によって実行され得る。観視パラメータは、デバイスの画面のサイズ、デバイスの画面の解像度、デバイスの画面の角度、デバイスの画面のピクセル密度、デバイスの画面のコントラスト比、ユーザ近接センサ、前向きカメラ、後向きカメラ、光センサ、赤外線撮像デバイス、超音波センサ、マイクロフォン、加速度計、コンパス、またはジャイロスコープセンサのうちの少なくとも１つを使用して決定され得る。例えば、デバイスのセンサ（例えば、ユーザ近接センサ、前向きカメラ、後向きカメラ、光センサ、赤外線撮像デバイス、超音波センサ、マイクロフォン、加速度計、コンパス、またはジャイロスコープセンサ）が、観視パラメータを決定するために使用され得、または観視パラメータを決定するために利用される情報を決定するために使用され得る。

マルチメディアコンテンツを求める要求が、デバイスによってネットワークに送信され得る。要求は、観視パラメータに基づくことができる。例えば、要求は、観視パラメータに関する情報を含むことができる。要求は、ネットワークによって受信され、処理され得る。ネットワークは、（例えば、要求に基づいて）マルチメディアコンテンツのためのレートを決定することができる。例えば、ネットワークは、観視パラメータに基づいて、マルチメディアコンテンツのためのレートを決定することができる。例えば、レートは、観視パラメータに関連付けられ得る。マルチメディアコンテンツは、デバイスによってネットワークから受信され得る。ネットワークから受信されたマルチメディアコンテンツは、観視パラメータに従ったレートで処理され得る。マルチメディアコンテンツは、デバイスの画面上に表示され得る。

マルチメディアコンテンツは、複数の異なるレートで処理され得る。例えば、各レートは、マルチメディアコンテンツの符号化レート、マルチメディアコンテンツの空間分解能、マルチメディアコンテンツの時間分解能、量子化パラメータ、レート制御パラメータ、マルチメディアコンテンツの目標ビットレート、マルチメディアコンテンツの空間フィルタリング、またはマルチメディアコンテンツの時間フィルタリングのうちの少なくとも１つの関数とすることができる。各レートは、少なくとも１つの観視パラメータに関連付けられ得る。したがって、マルチメディアコンテンツは、異なるレートを介して、観視パラメータに合せてカスタマイズされ得る。例えば、マルチメディアコンテンツは、ユーザのエクスペリエンスに従ってカスタマイズされ得る。

観視パラメータは、動的に変化し得る。デバイスに提供されるマルチメディアコンテンツのレートは、例えば、動的に変化する観視パラメータに従って、動的に変更され得る。例えば、マルチメディアコンテンツのレートは、マルチメディアコンテンツの所定の量ごとに（例えば、１つのセグメントから次のセグメントまで）、所定の期間ごとなどに変化し得る。例えば、第１のレートで処理されたマルチメディアコンテンツの第１のセグメントが、ネットワークから受信され得る。第１のレートは、観視パラメータに基づいてもよく、または基づかなくてもよい。観視パラメータ（例えば、以降の観視パラメータまたは変更された観視パラメータ）が、決定され得、マルチメディアコンテンツの第２のセグメントを求める要求が、ネットワークに送信され得る。観視パラメータ（例えば、以降の観視パラメータまたは変更された観視パラメータ）に従って第２のレートで処理されたマルチメディアコンテンツの第２のセグメントが、ネットワークから受信され得る。マルチメディアコンテンツの後続のセグメントの処理レートは、変化することもあり、または例えば、マルチメディアコンテンツ全体がデバイスに配信されるまで、もしくは接続がキャンセルされるまで、変化しないこともある。

ネットワークに送信された要求は、デバイスによって受信されるマルチメディアコンテンツのレートを決定し得る。例えば、要求は、デバイスによって要求されたマルチメディアコンテンツの特定のレートを含むことができる。ネットワークは、要求に従って、デバイスによって受信されるマルチメディアコンテンツのレートを決定することができる。例えば、要求は、例えば、観視パラメータを含み得る、マニフェストファイル（例えば、マルチメディアプレゼンテーション記述（ＭＰＤ）ファイル）、ＳＥＩメッセージ、または他のメッセージングとすることができる。ネットワークは、観視パラメータを利用して、マルチメディアコンテンツのレートを選択することができる。

マニフェストファイル（例えば、マルチメディアプレゼンテーション記述（ＭＰＤ）ファイル）、ＳＥＩメッセージ、または他のメッセージングは、デバイスによってネットワークから受信され得る。マニフェストファイル（例えば、ＭＰＤファイル）、ＳＥＩメッセージ、または他のメッセージングは、マルチメディアコンテンツのレート（例えば、すべての利用可能なレート）に関する情報を含むことができる。レートに関する情報は、観視パラメータに関連付けられたディスクリプタを含むことができる。マニフェストファイル（例えば、ＭＰＤファイル）、ＳＥＩメッセージ、または他のメッセージングは、ディスクリプタが必須か、それとも任意かを示すことができる。必須のディスクリプタは、当該レートで処理されたマルチメディアコンテンツを受信するために、デバイスがディスクリプタの要件を満たさなければならないことを示すことができる。例えば、必須のディスクリプタが、「少なくとも３６°の視野角」という観視パラメータを指定する場合、少なくとも３６°の計算された視野角を有する（例えば、ディスクリプタを満たす）デバイス（例えば、デバイスのみ）が、そのレートで処理されたマルチメディアコンテンツを受信することができる。任意のディスクリプタは、当該レートで処理されたマルチメディアコンテンツを受信するために、デバイスがディスクリプタの要件を満たすことがあるが、ディスクリプタの要件を満たす必要はないことを示すことができる。

本明細書で説明される実施は、ビデオ会議のために利用され得る。例えば、第１のデバイス（例えば、第１のビデオ会議デバイス）は、例えば、本明細書で説明されるように（例えば、ＳＥＩメッセージ、要求、シグナリングを介して、いかなるシグナリングも用いずになど）第２のデバイス（例えば、第２のビデオ会議デバイス）の観視パラメータ（例えば、複数の観視パラメータ）を決定することができる。観視パラメータに適したビデオ符号化の特性が、第１のビデオ会議デバイスによって決定され得る。ビデオ符号化の特性は、例えば、本明細書で説明されるように、ビデオコンテンツが処理されるレートを含むことができる。ビデオ符号化の決定された特性に従って符号化されたビデオコンテンツは、第１のビデオ会議デバイスから第２のビデオ会議デバイスに送信され得る。ビデオ会議について本明細書で説明される実施は、任意の数の接続されたビデオ会議デバイスのために／によって利用され得る。

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

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

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

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

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

より具体的には、上で言及したように、通信システム１００は、多元接続システムとすることができ、ＣＤＭＡ、ＴＤＭＡ、ＦＤＭＡ、ＯＦＤＭＡ、およびＳＣ−ＦＤＭＡなどの、１または複数のチャネルアクセス方式を利用することができる。例えば、ＲＡＮ１０３／１０４／１０５内の基地局１１４ａ、およびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、広帯域ＣＤＭＡ（ＷＣＤＭＡ）を使用してエアインターフェース１１５／１１６／１１７を確立できる、ユニバーサル移動体通信システム（ＵＭＴＳ）地上無線アクセス（ＵＴＲＡ）などの無線技術を実施することができる。ＷＣＤＭＡは、高速パケットアクセス（ＨＳＰＡ）および／または進化型ＨＳＰＡ（ＨＳＰＡ＋）などの通信プロトコルを含むことができる。ＨＳＰＡは、高速ダウンリンクパケットアクセス（ＨＳＤＰＡ）および／または高速アップリンクパケットアクセス（ＨＳＵＰＡ）を含むことができる。

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

他の実施形態では、基地局１１４ａ、およびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ＩＥＥＥ８０２．１６（すなわち、マイクロ波アクセス用の世界的相互運用性（ＷｉＭＡＸ））、ＣＤＭＡ２０００、ＣＤＭＡ２０００ １Ｘ、ＣＤＭＡ２０００ ＥＶ−ＤＯ、暫定標準２０００（ＩＳ−２０００）、暫定標準９５（ＩＳ−９５）、暫定標準８５６（ＩＳ−８５６）、移動体通信用グローバルシステム（ＧＳＭ）、ＧＳＭエボリューション用の高速データレート（ＥＤＧＥ）、およびＧＳＭ ＥＤＧＥ（ＧＥＲＡＮ）などの無線技術を実施することができる。

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

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

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

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

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

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

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

加えて、図３０Ｂでは、送信／受信要素１２２は単一の要素として示されているが、ＷＴＲＵ１０２は、任意の数の送信／受信要素１２２を含むことができる。より具体的には、ＷＴＲＵ１０２は、ＭＩＭＯ技術を利用することができる。したがって、一実施形態では、ＷＴＲＵ１０２は、エアインターフェース１１５／１１６／１１７を介して無線信号を送信および受信するための２つ以上の送信／受信要素１２２（例えば、複数のアンテナ）を含むことができる。

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

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

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

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

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

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

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

図３０Ｃに示されるコアネットワーク１０６は、メディアゲートウェイ（ＭＧＷ）１４４、モバイル交換センタ（ＭＳＣ）１４６、サービングＧＰＲＳサポートノード（ＳＧＳＮ）１４８、および／またはゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）１５０を含むことができる。上記の要素の各々は、コアネットワーク１０６の部分として示されているが、これらの要素は、どの１つをとっても、コアネットワーク運営体とは異なる主体によって所有および／または運営できることが理解されよう。

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

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

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

図３０Ｄは、一実施形態による、ＲＡＮ１０４およびコアネットワーク１０７のシステム図である。上で言及したように、ＲＡＮ１０４は、エアインターフェース１１６を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するために、Ｅ−ＵＴＲＡ無線技術を利用することができる。ＲＡＮ１０４は、コアネットワーク１０７と通信することもできる。

ＲＡＮ１０４は、ｅノードＢ１６０ａ、１６０ｂ、１６０ｃを含むことができるが、ＲＡＮ１０４は、一実施形態との整合性を保ちながら、任意の数のｅノードＢを含むことができることが理解されよう。ｅノードＢ１６０ａ、１６０ｂ、１６０ｃは、各々が、エアインターフェース１１６を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するための１または複数の送受信機を含むことができる。一実施形態では、ｅノードＢ１６０ａ、１６０ｂ、１６０ｃは、ＭＩＭＯ技術を実施することができる。したがって、ｅノードＢ１６０ａは、例えば、複数のアンテナを使用して、ＷＴＲＵ１０２ａに無線信号を送信し、ＷＴＲＵ１０２ａから無線信号を受信することができる。

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

図３０Ｄに示されるコアネットワーク１０７は、モビリティ管理ゲートウェイ（ＭＭＥ）１６２、サービングゲートウェイ１６４、およびパケットデータネットワーク（ＰＤＮ）ゲートウェイ１６６を含むことができる。上記の要素の各々は、コアネットワーク１０７の部分として示されているが、これらの要素は、どの１つをとっても、コアネットワーク運営体とは異なる主体によって所有および／または運営できることが理解されよう。

ＭＭＥ１６２は、Ｓ１インターフェースを介して、ＲＡＮ１０４内のｅノードＢ１６０ａ、１６０ｂ、１６０ｃの各々に接続することができ、制御ノードとしての役割を果たすことができる。例えば、ＭＭＥ１６２は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのユーザの認証、ベアラアクティブ化／非アクティブ化、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃの初期接続中における特定のサービングゲートウェイの選択などを担うことができる。ＭＭＥ１６２は、ＲＡＮ１０４とＧＳＭまたはＷＣＤＭＡなどの他の無線技術を利用する他のＲＡＮ（図示されず）との間の交換のためのコントロールプレーン機能を提供することもできる。

サービングゲートウェイ１６４は、Ｓ１インターフェースを介して、ＲＡＮ１０４内のｅノードＢ１６０ａ、１６０ｂ、１６０ｃの各々に接続することができる。サービングゲートウェイ１６４は、一般に、ユーザデータパケットのＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃへの／からの経路選択および転送を行うことができる。サービングゲートウェイ１６４は、ｅノードＢ間ハンドオーバ中におけるユーザプレーンのアンカリング（anchoring）、ダウンリンクデータがＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに利用可能な場合に行う一斉呼出のトリガ、ならびにＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのコンテキストの管理および記憶など、他の機能を実行することもできる。

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

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

図３０Ｅは、一実施形態による、ＲＡＮ１０５およびコアネットワーク１０９のシステム図である。ＲＡＮ１０５は、ＩＥＥＥ８０２．１６無線技術を利用して、エアインターフェース１１７を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信する、アクセスサービスネットワーク（ＡＳＮ）とすることができる。以下でさらに説明するように、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、ＲＡＮ１０５、およびコアネットワーク１０９の異なる機能エンティティ間の通信リンクは、参照点として定義することができる。

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

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

基地局１８０ａ、１８０ｂ、１８０ｃの各々の間の通信リンクは、ＷＴＲＵハンドオーバおよび基地局間でのデータの転送を円滑化するためのプロトコルを含む、Ｒ８参照点として定義することができる。基地局１８０ａ、１８０ｂ、１８０ｃとＡＳＮゲートウェイ１８２の間の通信リンクは、Ｒ６参照点として定義することができる。Ｒ６参照点は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃの各々に関連するモビリティイベントに基づいたモビリティ管理を円滑化するためのプロトコルを含むことができる。

図３０Ｅに示されるように、ＲＡＮ１０５は、コアネットワーク１０９に接続することができる。ＲＡＮ１０５とコアネットワーク１０９の間の通信リンクは、例えばデータ転送およびモビリティ管理機能を円滑化するためのプロトコルを含む、Ｒ３参照点として定義することができる。コアネットワーク１０９は、モバイルＩＰホームエージェント（ＭＩＰ−ＨＡ）１８４と、認証認可課金（ＡＡＡ）サーバ１８６と、ゲートウェイ１８８とを含むことができる。上記の要素の各々は、コアネットワーク１０９の部分として示されているが、これらの要素は、どの１つをとっても、コアネットワーク運営体とは異なる主体によって所有および／または運営できることが理解されよう。

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

図３０Ｅには示されていないが、ＲＡＮ１０５は、他のＡＳＮに接続でき、コアネットワーク１０９は、他のコアネットワークに接続できることが理解されよう。ＲＡＮ１０５と他のＡＳＮの間の通信リンクは、Ｒ４参照点として定義することができ、Ｒ４参照点は、ＲＡＮ１０５と他のＡＳＮの間で、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのモビリティを調整するためのプロトコルを含むことができる。コアネットワーク１０９と他のコアネットワークの間の通信リンクは、Ｒ５参照点として定義することができ、Ｒ５参照点は、ホームコアネットワークと在圏コアネットワークの間の網間接続を円滑化するためのプロトコルを含むことができる。

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

Claims (1)

1. デバイスを用いてネットワークからマルチメディアコンテンツを受信する方法であって、前記方法は、
   前記マルチメディアコンテンツの第１のセグメントを前記ネットワークから受信するステップであって、前記第１のセグメントは、第１のレートで処理される、ステップと、
   前記デバイスの画面からのユーザの距離、および前記デバイスの前記画面のピクセル密度、ならびに前記デバイスの前記画面の明るさ、または周囲の照明条件を決定するステップと、
   前記マルチメディアコンテンツの第２のセグメントに対する要求を前記ネットワークへ送信するステップであって、前記要求は、前記デバイスの前記画面からの前記ユーザの距離、および前記デバイスの前記画面の前記ピクセル密度、ならびに前記デバイスの前記画面の前記明るさ、または前記周囲の照明条件に基づく、ステップと、
   前記マルチメディアコンテンツの前記第２のセグメントを前記ネットワークから受信するステップであって、前記第２のセグメントは、前記デバイスの前記画面からの前記ユーザの距離、および前前記デバイスの前記画面の前記ピクセル密度、ならびに前記デバイスの前記画面の前記明るさ、または前記周囲の照明条件に従った第２のレートで処理される、ステップと
   を含むことを特徴とする方法。