(57)【要約】【課題】映像サイズが非常に大きくなり、映像が配信されるとき高伝送帯域幅を招き得る。ユーザは画像全体のごく一部のみを見るので配信中の高帯域幅消費は無駄にされ得る。【解決手段】クライアント中心サービス品質管理のためのシステム、方法、および手段が開示される。３６０度映像の第１のビューポートが決定され得る。３６０度映像は、正距円筒図法、キューブマップ、円柱、角錐、および／または球投影マッピングのうちの１つまたは複数を含むことができる。第１のビューポートは、３６０度映像の空間領域に関連付けられ得る。空間領域の周囲に広がる隣接エリアが決定され得る。３６０度映像の第２のビューポートが決定され得る。３６０度映像に関連付けられたビットストリームが受信され得る。１つまたは複数のエンハンスメントされた領域がビットストリームに含まれ得る。１つまたは複数のエンハンスメントされた領域は、第１のビューポートおよび／または第２のビューポートに対応することができる。【選択図】図１３Ｂ
2020110005.tif 000002
【特許請求の範囲】
【請求項１】
３６０度映像を処理する無線送受信ユニット（ＷＴＲＵ）であって、
前記３６０度映像に関連付けられたメディアプレゼンテーション記述（ＭＰＤ）ファイルを受信し、前記ＭＰＤファイルは、幾何表現と、第１のビューポートと、少なくとも第２のビューポート品質に対して第１のビューポート品質をランク付けする第１のビューポート相対品質ランキングとを示している統一リソース名（ＵＲＮ）を含む補足プロパティ要素を含み、
前記ＵＲＮに基づいて、前記幾何表現が２次元（２Ｄ）投影画像または３次元（３Ｄ）球画像であるかどうかを判定し、
前記ＵＲＮに基づいて、前記第１のビューポートが、前記２次元（２Ｄ）投影画像内の領域または前記３次元（３Ｄ）球画像内の領域であるかどうかを判定し、
前記第１のビューポート相対品質ランキングと、前記第１のビューポートが、前記２次元（２Ｄ）投影画像内の領域または前記３次元（３Ｄ）球画像内の領域であるかどうかとに基づいて、メディアセグメントを決定し、
前記メディアセグメントに対する要求を送り、
前記メディアセグメントを受信し、
前記受信されたメディアセグメントに関連付けられた前記３６０度映像を再構築する
ように構成されたプロセッサを備えたことを特徴とするＷＴＲＵ。
【請求項２】
前記プロセッサは、前記第１のビューポート相対品質ランキングに基づいて、前記メディアセグメントに対するアダプテーションセットおよびリプレゼンテーションを決定するようにさらに構成されたことを特徴とする請求項１に記載のＷＴＲＵ。
【請求項３】
前記補足プロパティ要素は、前記ＭＰＤファイルのアダプテーションセットまたはリプレゼンテーションレベルで提供されることを特徴とする請求項１に記載のＷＴＲＵ。
【請求項４】
前記プロセッサは、前記メディアセグメントが、前記メディアセグメントに関連付けられたビットレートにさらに基づくことを決定するようにさらに構成されたことを特徴とする請求項１に記載のＷＴＲＵ。
【請求項５】
前記補足プロパティ要素は、全方向性メディアアプリケーションフォーマット（ＯＭＡＦ）によって定義されることを特徴とする請求項１に記載のＷＴＲＵ。
【請求項６】
前記補足プロパティ要素は、ｐｌａｔｅ  ｃａｒｒｅｅ、ハーフハイトの側部の極、フルハイトの側部の極、単列、２×３、および１８０度を含む面パッキングレイアウトのセットから面パッキングレイアウトを示していることを特徴とする請求項１に記載のＷＴＲＵ。
【請求項７】
前記プロセッサは、後続の映像ファイルを受信するための投影フォーマットを決定し、前記決定された投影フォーマットに対する要求を送るようにさらに構成されたことを特徴とする請求項１に記載のＷＴＲＵ。
【請求項８】
無線送受信ユニット（ＷＴＲＵ）を用いて３６０度映像を処理する方法であって、
前記３６０度映像に関連付けられたメディアプレゼンテーション記述（ＭＰＤ）ファイルを受信するステップであって、前記ＭＰＤファイルは、幾何表現と、第１のビューポートと、少なくとも第２のビューポート品質に対して第１のビューポート品質をランク付けする第１のビューポート相対品質ランキングとを示している統一リソース名（ＵＲＮ）を含む補足プロパティ要素を含む、ステップと、
前記ＵＲＮに基づいて、前記幾何表現が２次元（２Ｄ）投影画像または３次元（３Ｄ）球画像であるかどうかを判定するステップと、
前記ＵＲＮに基づいて、前記第１のビューポートが前記２次元（２Ｄ）投影画像内の領域または前記３次元（３Ｄ）球画像内の領域であるかどうかを判定するステップと、
前記第１のビューポート相対品質ランキングと、前記第１のビューポートが前記２次元（２Ｄ）投影画像内の領域または前記３次元（３Ｄ）球画像内の領域であるかどうかとに基づいて、メディアセグメントを決定するステップと、
前記メディアセグメントに対する要求を送るステップと、
前記メディアセグメントを受信するステップと、
前記受信されたメディアセグメントに関連付けられた前記３６０度映像を再構築するステップと
を備えたことを特徴とする方法。
【請求項９】
前記第１のビューポート相対品質ランキングに基づいて、前記メディアセグメントに対するアダプテーションセットおよびリプレゼンテーションを決定するステップをさらに備えたことを特徴とする請求項８に記載の方法。
【請求項１０】
前記補足プロパティ要素は、前記ＭＰＤファイルのアダプテーションセットまたはリプレゼンテーションレベルで提供されることを特徴とする請求項８に記載の方法。
【請求項１１】
前記メディアセグメントを決定するステップは、前記メディアセグメントに関連付けられたビットレートにさらに基づくことを特徴とする請求項８に記載の方法。
【請求項１２】
前記補足プロパティ要素は、全方向性メディアアプリケーションフォーマット（ＯＭＡＦ）によって定義されることを特徴とする請求項８に記載の方法。
【請求項１３】
前記補足プロパティ要素は、ｐｌａｔｅ  ｃａｒｒｅｅ、ハーフハイトの側部の極、フルハイトの側部の極、単列、２×３、および１８０度を含む面パッキングレイアウトのセットから面パッキングレイアウトを示していることを特徴とする請求項８に記載の方法。
【請求項１４】
後続の映像ファイルを受信するための投影フォーマットを決定するステップと、前記決定された投影フォーマットに対する要求を送るステップとをさらに備えたことを特徴とする請求項８に記載の方法。
【発明の詳細な説明】
【背景技術】
【０００１】
関連出願の相互参照
本出願は、参照により本明細書に組み込まれている、２０１６年５月２６日に出願された米国特許仮出願第６２／３４２１５８号明細書の優先権および利益を主張するものである。
【０００２】
３６０°映像は、メディア産業で急速に発展しているフォーマットである。３６０°映像は、仮想現実（ＶＲ）デバイスの利用可能性の向上により実現されている。３６０°映像は、見る人に新しい臨場感を提供することができる。直線的（rectilinear）映像（たとえば２Ｄまたは３Ｄ）と比べると、３６０°映像は、映像処理および／または配信に困難な技術的課題をもたらし得る。快適性および／または没入型ユーザ体験を可能にするには、高い映像品質および／または非常に低いレイテンシを必要とし得る。３６０°映像の大きな映像サイズは、３６０°映像を大規模に高品質で配信することの障害となり得る。
【０００３】
３６０°映像アプリケーションおよび／またはサービスは、３６０°映像全体をプログレッシブダウンロードおよび／またはアダプティブストリーミングのための標準準拠ストリームにエンコードすることがある。３６０°映像全体をクライアントに配信することは、低レイテンシレンダリングを可能にし得る（たとえば、クライアントは、３６０°映像コンテンツの全体にアクセスすることができ、および／または、さらなる制限なしに見たい部分をレンダリングするように選択することができる）。サーバの観点からは、同じストリームが、場合によっては異なるビューポートを用いる複数のユーザをサポートすることができる。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
映像サイズが非常に大きくなり、映像が配信されるときに高伝送帯域幅を招くことがある（たとえば、３６０°映像全体が、１眼あたり６０ｆｐｓで４Ｋまたは９０ｆｐｓで６Ｋなどの高品質でエンコードされる必要があるためである）。たとえば、ユーザは画像全体のごく一部（たとえばビューポート）のみを見ることがあるので、配信中の高帯域幅消費は無駄にされることがある。
【課題を解決するための手段】
【０００５】
ビューポート適応（viewport adaptive）３６０°映像配信のためのシステム、方法、および手段が開示される。ビューポートエンハンスメントベースの３６０度映像が、配信および／またはシグナリングされ得る。３６０度映像は、レイヤベースのビューポートオーバーレイを使用して配信され得る。３６０度映像マッピングのシグナリングが提供され得る。
【０００６】
３６０度映像の第１のビューポートが決定され得る。３６０度映像は、正距円筒図法（equirectangular）、キューブマップ（cube-map）、円柱、角錐、および／または球投影（spherical projection）マッピングのうちの１つまたは複数を含むことができる。第１のビューポートは、３６０度映像の空間領域に関連付けられ得る。空間領域の周囲に広がる隣接エリアが決定され得る。３６０度映像の第２のビューポートが決定され得る。３６０度映像に関連付けられたビットストリームが受信され得る。ビットストリームは、１つまたは複数のエンハンスメントされた領域を含むことができる。１つまたは複数のエンハンスメントされた領域は、第１のビューポートおよび／または第２のビューポートに対応することができる。高符号化ビットレートが第１のビューポートおよび／または第２のビューポートに関連付けられ得る。３６０度映像配信に関連付けられた１つまたは複数のビューポートプロパティを示すシグナリングが受信され得る。
【０００７】
３６０度映像を処理するためのＷＴＲＵは、（ｉ）メディアセグメントの多面幾何投影（multi-face geometric projection）フォーマットのための面パッキング（face-packing）レイアウトを示す本質的プロパティ要素を含む３６０度映像に関連付けられたメディアプレゼンテーション記述（media presentation description：ＭＰＤ）を受信することと、（ｉｉ）メディアセグメントを受信することと、（ｉｉｉ）本質的プロパティ要素に基づいて、面パッキングレイアウトのセットから、受信されたメディアセグメントについての少なくとも１つの面パッキングレイアウトを決定することと、（ｉｖ）決定された少なくとも１つの面パッキングレイアウトに基づいて、受信されたメディアセグメントを構築することとのうちの１つまたは複数を行うように（たとえば、メモリに保存された実行可能命令によって）構成されたプロセッサを備えることができる。
【０００８】
面パッキングレイアウトのセットは、ｐｌａｔｅ  ｃａｒｒｅｅ、ハーフハイトの側部の極（poles on the side half height）、フルハイトの側部の極（poles on the side full height）、単列（single row）、２×３、および１８０度を含む。本質的プロパティ要素は、アダプテーション（adaptation）レベル内およびリプレゼンテーション（representation）レベル内のうちの一方であり得る。
【０００９】
ＷＴＲＵプロセッサは、将来のメディアセグメントを要求するために、ＭＰＤに関連付けられたメディアリプレゼンテーションを決定し、決定されたメディアリプレゼンテーションに対する要求を送るように、（たとえば、メモリに保存された実行可能命令によって）構成され得る。
【００１０】
ＭＰＤは、メディアセグメントについての、映像タイプのセットから選択された映像タイプを含むことができる。映像タイプのセットは、直線的、パノラマ、球、およびライトフィールド（lightfield）を含むことができる。ＷＴＲＵプロセッサは、受信されたメディアセグメントについての映像タイプを決定し、および／または決定された映像タイプを使用して受信されたメディアセグメントを構築するように、（たとえば、メモリに保存された実行可能命令によって）構成され得る。
【００１１】
ＭＰＤは、３６０度映像を全方向性（omnidirectional）フォーマットから直線的映像フレームに投影するために使用される少なくとも１つの投影フォーマットを含むことができる。投影フォーマットは、正距円筒図法、キューブ、オフセットされたキューブ（offset cube）、つぶされた球（squished sphere）、角錐、および円柱のうちの１つを含むことができる。ＷＴＲＵプロセッサは、映像ファイルを受信するための投影フォーマットを決定し、および／または決定された投影フォーマットに対する要求を送るように、（たとえば、メモリに保存された実行可能命令によって）構成され得る。３６０度映像は、全方向性メディアアプリケーションフォーマット（Omnidirectional Media Application Format：ＯＭＡＦ）ファイルを含むことができる。
【００１２】
３６０度映像を処理するためのＷＴＲＵを使用する方法は、（ｉ）メディアセグメントの多面幾何投影フォーマットのための面パッキングレイアウトを示す本質的プロパティ要素を含む３６０度映像に関連付けられたメディアプレゼンテーション記述（ＭＰＤ）を受信するステップと、（ｉｉ）メディアセグメントを受信するステップと、（ｉｉｉ）本質的プロパティ要素に基づいて、面パッキングレイアウトのセットから、受信されたメディアセグメントについての少なくとも１つの面パッキングレイアウトを決定するステップと、（ｉｖ）決定された少なくとも１つの面パッキングレイアウトに基づいて、受信されたメディアセグメントを構築するステップとのうちの１つまたは複数を含むことができる。
【００１３】
ＷＴＲＵを使用する上記方法は、将来の受信された映像ファイルを要求するために、ＭＰＤに関連付けられたメディアリプレゼンテーションを決定するステップと、および／または決定されたメディアリプレゼンテーションに対する要求を送るステップとを含むことができる。上記方法は、受信されたメディアセグメントについての映像タイプを決定するステップと、および／または決定された映像タイプを使用して受信されたメディアセグメントを構築するステップとを含むことができる。上記方法は、映像ファイルのための投影フォーマットを決定するステップと、および／または決定された投影フォーマットに対する要求を送るステップとを含むことができる。
【００１４】
３６０度映像を処理するためのＷＴＲＵは、３６０度映像に関連付けられたメディアプレゼンテーション記述（ＭＰＤ）であって、メディアセグメントの多面幾何投影フォーマットのための第１の面パッキングレイアウトを示す第１の本質的プロパティ要素と、メディアセグメントの多面幾何投影フォーマットのための第１の第２のパッキングレイアウトを示す第２の本質的プロパティ要素とを含むメディアプレゼンテーション記述（ＭＰＤ）を受信することと、メディアセグメントについて第１の面パッキングレイアウトを使用するか第２の面パッキングレイアウトを使用するかを決定することと、決定された少なくとも第１の面パッキングレイアウトまたは第２の面パッキングレイアウトを要求することと、メディアセグメントを受信することと、要求された面パッキングレイアウトに基づいて、受信されたメディアセグメントに関連付けられた３６０度映像を再構築することとのうちの１つまたは複数を行うように（たとえば、メモリに保存された実行可能命令によって）構成されたプロセッサを備えることができる。
【発明の効果】
【００１５】
新規なビューポート適応３６０°映像配信のためのシステム、方法、および手段を提供する。
【図面の簡単な説明】
【００１６】
【図１】ヘッドマウントデバイス（ＨＭＤ）上に表示された３６０°映像の例示的な部分を示す図である。
【図２】３６０°映像の例示的な正距円筒図法投影を示す図である。
【図３】例示的な３６０°映像マッピングを示す図である。
【図４】例示的なメディアプレゼンテーション記述（ＭＰＤ）階層データモデルを示す図である。
【図５】映像に関する例示的ダイナミックアダプティブストリーミングオーバーＨＴＴＰ（ＤＡＳＨ）空間関係記述（spatial relationship description：ＳＲＤ）を示す図である。
【図６】例示的なタイルベースの映像分割を示す図である。
【図７】例示的時間的動き（temporal motion）が制約されたタイルセットの図である。
【図８】例示的な３６０°映像ストリーミング品質低下を示す図である。
【図９】関連付けられた隣接エリアを有する例示的ビューポートエリアを示す図である。
【図１０Ａ】例示的なキューブマップレイアウトを示す図である。
【図１０Ｂ】例示的なキューブマップレイアウトを示す図である。
【図１０Ｃ】例示的なキューブマップレイアウトを示す図である。
【図１０Ｄ】例示的なキューブマップレイアウトを示す図である。
【図１１Ａ】例示的な正距円筒座標ビューポートマッピングを示す図である。
【図１１Ｂ】例示的なキューブマップ座標ビューポートマッピングを示す図である。
【図１２】例示的な球面座標ビューポートマッピングを示す図である。
【図１３Ａ】例示的なビューポートエンハンスメントリプレゼンテーションの図である。
【図１３Ｂ】例示的なビューポートエンハンスメントリプレゼンテーションの図である。
【図１４】例示的なレイヤベースの３６０°映像オーバーレイを示す図である。
【図１５】例示的なレイヤベースの３６０°映像リプレゼンテーションを示す図である。
【図１６】例示的なレイヤベースの３６０°映像オーバーレイを示す図である。
【図１７】例示的なレイヤベースの３６０°映像オーバーレイのフローチャートである。
【図１８】複数のビューポートを有する例示的なレイヤベースの３６０°映像オーバーレイを示す図である。
【図１９】側部のハーフハイト極を有する例示的な正距円筒図法リプレゼンテーションを示す図である。
【図２０】側部のフルハイト極を有する例示的な正距円筒図法リプレゼンテーションを示す図である。
【図２１】例示的な単列レイアウトキューブリプレゼンテーションを示す図である。
【図２２】例示的な２×３レイアウトキューブリプレゼンテーションを示す図である。
【図２３】例示的な１８０°キューブマップレイアウトを示す図である。
【図２４Ａ】１つまたは複数の開示されている実施形態が実装され得る例示的な通信システムの図である。
【図２４Ｂ】図２４Ａに示されている通信システム内で使用され得る例示的な無線送受信ユニット（ＷＴＲＵ）のシステム図である。
【図２４Ｃ】図２４Ａの通信システム内で使用され得る例示的な無線アクセスネットワークおよびコアネットワークのシステム図である。
【図２４Ｄ】図２４Ａの通信システム内で使用され得る別の例示的な無線アクセスネットワークおよびコアネットワークのシステム図である。
【図２４Ｅ】図２４Ａの通信システム内で使用され得る別の例示的な無線アクセスネットワークおよびコアネットワークのシステム図である。
【発明を実施するための形態】
【００１７】
ここで、例示的実施形態の詳細な説明が様々な図を参照して説明される。この説明は可能な実装形態の詳細な例を提供するが、詳細は例示的であることが意図され、本出願の範囲を何ら限定するものではないことに留意されたい。
【００１８】
図１は、ヘッドマウントデバイス（ＨＭＤ）上に表示された３６０°映像の例示的な部分を示す。３６０°映像を見るとき、ユーザは、たとえば図１に示されるように、映像の一部分を提示され得る。映像の一部分は、ユーザが画像を見回すおよび／またはズームするときに変更され得る。映像の一部分は、ＨＭＤにより提供されたフィードバック、または他のタイプのユーザインターフェース（たとえば、無線送受信ユニット（ＷＴＲＵ））に基づいて変更され得る。ビューポートは、３６０°映像全体の空間領域であってよく、またはそのような空間領域を含んでよい。ビューポートは、完全にまたは部分的にユーザに提示され得る。ビューポートは、３６０°映像の他の部分とは異なる１つまたは複数の品質を有することができる。
【００１９】
３６０°映像は、（たとえば、任意のビューポートを選ぶ能力をユーザに与えるために、）球上にキャプチャおよび／またはレンダリングされ得る。球映像フォーマットは、従来の映像コーデックを使用して直接配信され得る。３６０°映像（たとえば球映像など）は、投影法を使用して球映像を２Ｄ平面上に投影することによって圧縮され得る。投影された２Ｄ映像は、（たとえば、従来の映像コーデックを使用して）符号化され得る。投影法の例は、正距円筒図法投影を含むことができる。図２は、３６０°映像の例示的な正距円筒図法投影を示す。たとえば、正距円筒図法投影法は、以下の方程式のうちの１つまたは複数を使用して、球上の座標（θ，φ）を有する第１の点Ｐを２Ｄ平面上の座標（ｕ，ｖ）を有する第２の点Ｐにマッピングすることができる。  
ｕ＝φ／（２＊ｐｉ）＋０．５    （１）
ｖ＝０．５−θ／（ｐｉ）    （２）
【００２０】
図３は、例示的な３６０°映像マッピングを示す。たとえば、１つまたは複数の他の投影法（たとえば、マッピング）を使用して、（たとえば、代替的に帯域幅要件を低減するために）３６０°映像を２Ｄ平面映像に変換することができる。たとえば、１つまたは複数の他の投影法は、角錐マップ、キューブマップ、および／またはオフセットされたキューブマップを含むことができる。１つまたは複数の他の投影法は、より少ないデータで球映像を表現するために使用され得る。
【００２１】
ビューポート特有のリプレゼンテーションが使用され得る。図３に示されている投影法のうちの１つまたは複数、たとえば、キューブマップおよび／または角錐投影は、異なるビューポートに対して均一でない品質の表現を提供することがある（たとえば、いくつかのビューポートは、他のビューポートよりも高品質で表現され得る）。異なるターゲットビューポートを有する同じ映像の複数のバージョンが、（たとえば、球映像のすべてのビューポートをサポートするために）サーバ側で生成および／または記憶され得る。たとえば、ＶＲ映像配信のＦａｃｅｂｏｏｋの実装形態では、図３に示されているオフセットされたキューブマップフォーマットが使用されることがある。オフセットされたキューブマップは、最高解像度（たとえば最高品質）をフロントビューポートに提供し、最低解像度（たとえば最低品質）をバックビューに提供し、中間解像度（たとえば中間品質）を１つまたは複数のサイドビューに提供することができる。サーバは、（たとえば、同じコンテンツの異なるビューポートに対するクライアント要求を受け入れるために）同じコンテンツの異なるバージョンを記憶することができる。たとえば、同じコンテンツについて合計１５０個の異なるバージョン（たとえば、３０個のビューポート×ビューポートごとに５個の解像度）。配信（たとえばストリーミング）中に、クライアントは、その現在のビューポートに対応する特定のバージョンを要求することができる。特定のバージョンはサーバによって配信され得る。
【００２２】
３６０映像および／または他の非従来型の映像フォーマット（たとえば、パノラマ映像リプレゼンテーションで使用され得る円柱映像）を表現するために使用され得る様々な投影法を記述するために、ＩＳＯ／ＩＥＣ／ＭＰＥＧは、全方向性メディアアプリケーションフォーマット（ＯＭＡＦ）を定義することができる。本明細書に説明されている投影法のためのＯＭＡＦファイルフォーマットメタデータは、球、キューブ、円柱、および／または角錐上などへの映像に関する投影メタデータのサポートを含むことができる。表１は、つぶされた球、円柱、および角錐などの投影法をサポートするためのＯＭＡＦの構文例を示し得る。
【００２３】
【表１】
2020110005.tif 000003
【００２４】
ＨＴＴＰストリーミングは商用展開では支配的な手法になっている。たとえば、ＡｐｐｌｅのＨＴＴＰ  Ｌｉｖｅ  Ｓｔｒｅａｍｉｎｇ（ＨＬＳ）、ＭｉｃｒｏｓｏｆｔのＳｍｏｏｔｈ  Ｓｔｒｅａｍｉｎｇ（ＳＳ）、および／またはＡｄｏｂｅのＨＴＴＰ  Ｄｙｎａｍｉｃ  Ｓｔｒｅａｍｉｎｇ（ＨＤＳ）などのストリーミングプラットフォームは、基礎となる配信方法としてＨＴＴＰストリーミングを使用することができる。マルチメディアコンテンツのＨＴＴＰストリーミングの標準は、標準ベースのクライアントが任意の標準ベースのサーバからコンテンツをストリーミングすることを可能にし得る（たとえば、それにより、異なるベンダのサーバとクライアントとの間の相互運用を可能にする）。ＭＰＥＧダイナミックアダプティブストリーミングオーバーＨＴＴＰ（ＭＰＥＧ−ＤＡＳＨ）は、変化するネットワーク条件に動的に適応することによって、可能な最良の映像体験をエンドユーザに提供する汎用配信フォーマットであり得る。ＤＡＳＨは、ＨＴＴＰ／ＴＣＰ／ＩＰスタックの上に構築され得る。ＤＡＳＨは、マニフェストフォーマット、メディアプレゼンテーション記述（ＭＰＤ）、ならびにＩＳＯベースメディアファイルフォーマットおよびＭＰＥＧ−２トランスポートストリーム用のセグメントフォーマットを定義することができる。
【００２５】
ダイナミックＨＴＴＰストリーミングは、サーバで利用可能になるマルチメディアコンテンツの様々なビットレート選択肢に関連付けられ得る。マルチメディアコンテンツは、いくつかのメディアコンポーネント（たとえばオーディオ、映像、テキスト）を含むことができ、それらの各々は異なる特徴を有し得る。ＭＰＥＧ−ＤＡＳＨでは、特徴はメディアプレゼンテーション記述（ＭＰＤ）によって記述され得る。
【００２６】
ＭＰＤは、ストリーミングセッション中にアダプティブ様式でＤＡＳＨクライアントが（たとえば、本明細書に説明されているように）映像セグメントにアクセスするために適切なＨＴＴＰ−ＵＲＬを構築するために必要なメタデータを含むＸＭＬドキュメントであり得る。図４は、例示的なメディアプレゼンテーション記述（ＭＰＤ）階層データモデルを示す。ＭＰＤはＰｅｒｉｏｄのシーケンスを記述することができ、Ｐｅｒｉｏｄ中に、メディアコンテンツコンポーネントのエンコードされたバージョンの一貫したセットは変化しない。Ｐｅｒｉｏｄは、開始時間および持続時間を有することができる。Ｐｅｒｉｏｄは、１つまたは複数のアダプテーションセット（たとえばＡｄａｐｔａｔｉｏｎＳｅｔ）から構成され得る。
【００２７】
ＡｄａｐｔａｔｉｏｎＳｅｔは、１つまたは複数の同一のプロパティ（たとえば、言語、メディアタイプ、ピクチャアスペクト比、ロール（role）、アクセシビリティ、視点、および／または評価プロパティなど）を共有する１つまたはいくつかのメディアコンテンツコンポーネントのエンコードされたバージョンのセットを表現することができる。たとえば、第１のＡｄａｐｔａｔｉｏｎＳｅｔは、同じマルチメディアコンテンツの映像コンポーネントの異なるビットレートを含むことができる。第２のＡｄａｐｔａｔｉｏｎＳｅｔは、同じマルチメディアコンテンツのオーディオコンポーネント（たとえば、より低品質のステレオおよび／またはより高品質のサラウンドサウンド）の異なるビットレートを含むことができる。ＡｄａｐｔａｔｉｏｎＳｅｔは、複数のＲｅｐｒｅｓｅｎｔａｔｉｏｎを含むことができる。
【００２８】
Ｒｅｐｒｅｓｅｎｔａｔｉｏｎは、ビットレート、解像度、チャネルの数、および／または他の特徴によって他のリプレゼンテーションと異なる、１つまたはいくつかのメディアコンポーネントの配信可能なエンコードされたバージョンを記述することができる。Ｒｅｐｒｅｓｅｎｔａｔｉｏｎは、１つまたは複数のセグメントを含むことができる。Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ要素の１つまたは複数の属性（たとえば、＠ｉｄ、＠ｂａｎｄｗｉｄｔｈ、＠ｑｕａｌｉｔｙ  Ｒａｎｋｉｎｇ、および＠ｄｅｐｅｎｄｅｎｃｙＩｄなど）が、関連付けられたＲｅｐｒｅｓｅｎｔａｔｉｏｎの１つまたは複数のプロパティを指定するために使用され得る。
【００２９】
Ｓｅｇｍｅｎｔは、単一のＨＴＴＰ要求で取り出されることができるデータの最大のユニットであり得る。セグメントは、ＵＲＬ（たとえば、サーバ上のアドレス可能な場所）を有することができる。セグメントは、ＨＴＴＰ  ＧＥＴまたはバイト範囲を有するＨＴＴＰ  ＧＥＴを使用してダウンロードされ得る。
【００３０】
ＤＡＳＨクライアントは、ＭＰＤ  ＸＭＬドキュメントをパースすることができる。ＤＡＳＨクライアントは、たとえばＡｄａｐｔａｔｉｏｎＳｅｔ要素内に提供された情報に基づいて、その環境に適切なＡｄａｐｔａｔｉｏｎＳｅｔの集合を選択することができる。ＡｄａｐｔａｔｉｏｎＳｅｔ内で、クライアントはＲｅｐｒｅｓｅｎｔａｔｉｏｎを選択することができる。クライアントは、＠ｂａｎｄｗｉｄｔｈ属性の値、クライアント復号能力、および／またはクライアントレンダリング能力に基づいて、Ｒｅｐｒｅｓｅｎｔａｔｉｏｎを選択することができる。クライアントは、選択されたＲｅｐｒｅｓｅｎｔａｔｉｏｎの初期化セグメントをダウンロードすることができる。クライアントは、（たとえば、Ｓｅｇｍｅｎｔ全体またはＳｅｇｍｅｎｔのバイト範囲を要求することによって）コンテンツにアクセスすることができる。プレゼンテーションが開始したとき、クライアントはメディアコンテンツの消費を続けることができる。たとえば、クライアントは、プレゼンテーション中にＭｅｄｉａ  Ｓｅｇｍｅｎｔおよび／またはＭｅｄｉａ  Ｓｅｇｍｅｎｔの一部を要求する（たとえば継続的に要求する）ことができる。クライアントは、メディアプレゼンテーションタイムラインに従ってコンテンツを再生することができる。クライアントは、クライアントの環境からの更新された情報に基づいて、第１のＲｅｐｒｅｓｅｎｔａｔｉｏｎから第２のリプレゼンテーションに切り替えることができる。クライアントは、２つ以上のＰｅｒｉｏｄにわたって継続してコンテンツを再生することができる。クライアントがＲｅｐｒｅｓｅｎｔａｔｉｏｎにおける公表されたメディアの終端に向かってＳｅｇｍｅｎｔに含まれるメディアを消費しているとき、Ｍｅｄｉａ  Ｐｒｅｓｅｎｔａｔｉｏｎが終了されることができ、Ｐｅｒｉｏｄが開始されることができ、および／またはＭＰＤが再フィッチされることができる。
【００３１】
ＭＰＤ記述子要素、Ｄｅｓｃｒｉｐｔｏｒが、（たとえば、適切なスキーム情報を有する１つまたは複数の記述要素をインスタンス化するために）アプリケーションに提供され得る。１つまたは複数のＤｅｓｃｒｉｐｔｏｒ（たとえば、コンテンツ保護、ロール、アクセシビリティ、評価、視点、フレームパッキング、および／またはＵＴＣタイミング記述子など）は、相対スキームを識別するための＠スキームＩｄＵｒｉ属性を含むことができる。
【００３２】
補足プロパティ記述子（ＳｕｐｐｌｅｍｅｎｔａｌＰｒｏｐｅｒｔｙ）は、処理を最適化するためにＤＡＳＨクライアントによって使用され得るメタデータを含むことができる。
【００３３】
本質的プロパティ記述子（ＥｓｓｅｎｔｉａｌＰｒｏｐｅｒｔｙ）は、含む要素を処理するためのメタデータを含むことができる。
【００３４】
Ｒｏｌｅ  ＭＰＤ要素は、＠ｓｃｈｅｍｅＩｄＵｒｉ属性を使用して、メディアコンテンツコンポーネントのロールを識別するために利用されるロールスキームを識別することができる。１つまたは複数のＲｏｌｅは、メディアコンテンツコンポーネントの１つまたは複数の特徴および／または構造的機能を定義および／または記述することができる。Ａｄａｐｔａｔｉｏｎ  Ｓｅｔおよび／またはメディアコンテンツコンポーネントは、（たとえば、同じスキーム内であっても）複数の指定されたロールを有することができる。
【００３５】
ＭＰＥＧ−ＤＡＳＨは、空間関係記述（ＳＲＤ）スキームを提供することができる。ＳＲＤスキームは、２つのＭＰＤ要素（たとえば、ＡｄａｐｔａｔｉｏｎＳｅｔおよびＳｕｂＲｅｐｒｅｓｅｎｔａｔｉｏｎ）において別のフルフレーム映像の空間部分を表現する映像の空間関係を表すことができる。＠ｓｃｈｅｍｅＩｄＵＲＩが「ｕｒｎ：ｍｐｅｇ：ｄａｓｈ：ｓｒｄ：２０１４」に等しいＳｕｐｐｌｅｍｅｎｔａｌＰｒｏｐｅｒｔｙおよび／またはＥｓｓｅｎｔｉａｌＰｒｏｐｅｒｔｙ記述子が、ＡｄａｐｔａｔｉｏｎＳｅｔおよび／またはＳｕｂＲｅｐｒｅｓｅｎｔａｔｉｏｎに関連付けられた空間関係情報を提供するために使用され得る。ＳｕｐｐｌｅｍｅｎｔａｌＰｒｏｐｅｒｔｙおよび／またはＥｓｓｅｎｔｉａｌＰｒｏｐｅｒｔｙ要素の属性＠ｖａｌｕｅは、ｓｏｕｒｃｅ＿ｉｄ、ｏｂｊｅｃｔ＿ｘ、ｏｂｊｅｃｔ＿ｙ、ｏｂｊｅｃｔ＿ｗｉｄｔｈ、ｏｂｊｅｃｔ＿ｈｅｉｇｈｔ、ｔｏｔａｌ＿ｗｉｄｔｈ、ｔｏｔａｌ＿ｈｅｉｇｈｔ、および／またはｓｐａｔｉａｌ＿ｓｅｔ＿ｉｄのようなＳＲＤパラメータに対する１つまたは複数の値を提供することができる。ＳＲＤパラメータの値およびセマンティクスは、表２に示されるように定義され得る。
【００３６】
【表２−１】
2020110005.tif 000004
【００３７】
【表２−２】
2020110005.tif 000005
【００３８】
図５は、例示的なＤＡＳＨ  ＳＲＤ映像を示す。ＳＲＤは、映像ストリームがフルフレーム映像の空間部分を表現することを表すことができる。空間部分は、フルフレーム映像のタイルおよび／または関心領域（ＲＯＩ）であり得る。ＳＲＤは、フルフレーム映像（ｔｏｔａｌ＿ｗｉｄｔｈ、ｔｏｔａｌ＿ｈｅｉｇｈｔ）に対する空間部分の位置（ｏｂｊｅｃｔ＿ｘ、ｏｂｊｅｃｔ＿ｙ）および／またはサイズ（ｏｂｊｅｃｔ＿ｗｉｄｔｈ、ｏｂｊｅｃｔ＿ｈｅｉｇｈｔ）に関して映像ストリームを記述することができる。ＳＲＤ記述は、アダプテーションに関してクライアントのための柔軟性を提供することができる。ＳＲＤ認識ＤＡＳＨクライアントは、１つまたは複数のＳＲＤアノテーションを使用して、フルフレームリプレゼンテーションおよび／またはフルフレームリプレゼンテーションの空間部分を選択することができる。１つまたは複数のＳＲＤを使用してフルフレームリプレゼンテーションまたは空間部分を選択することにより、帯域幅および／またはクライアント側計算を節約することができ、たとえば、フルフレームフェッチ、復号、および／またはクロッピングを回避することができる。１つまたは複数のＳＲＤアノテーションを使用してどのリプレゼンテーションを選択するかを決定することにより、たとえばズーム後の、フルフレーム映像の所与の空間部分（たとえば、関心領域すなわちＲＯＩ）の品質を増大させることができる。たとえば、クライアントは、より高品質を有するＲＯＩ空間部分に対応する第１の映像ストリームを要求することができ、クライアントは、より低い品質を有するＲＯＩに対応しない第２の映像ストリームを要求することができ、全体的ビットレートを増大させることがない。
【００３９】
表３は、図５に示されるようなシナリオに関してＳＲＤをサポートするＭＰＤ例であり、ここでは、各タイルが１９２０×１０８０の解像度を有し、フレーム全体では９個のタイルを有する５７６０×３２４０の解像度を有する。
【００４０】
【表３−１】
2020110005.tif 000006
【００４１】
【表３−２】
2020110005.tif 000007
【００４２】
【表３−３】
2020110005.tif 000008
【００４３】
図６は、例示的なタイルベースの映像分割を示す。２Ｄフレームは、図６に示されるように１つまたは複数のタイルへ分割され得る。ＭＰＥＧ−ＤＡＳＨ  ＳＲＤサポートが与えられたとすると、タイルベースのアダプティブストリーミング（tile based adaptive streaming：ＴＡＳ）が、大きなパノラマでのズーミングおよびパンニング、空間解像度エンハンスメント、ならびに／またはサーバベースのモザイクサービスのような機能をサポートするために使用され得る。ＳＲＤ認識ＤＡＳＨクライアントは、１つまたは複数のＳＲＤアノテーションを使用してフルフレームリプレゼンテーションまたはタイルリプレゼンテーションを選択することができる。１つまたは複数のＳＲＤアノテーションを使用してタイルリプレゼンテーションのフルフレームリプレゼンテーションを選択するかどうかを決定することにより、帯域幅および／またはクライアント側計算を節約することができる（たとえば、フルフレームフェッチ、復号、および／またはクロッピングを回避する）。
【００４４】
図７は、例示的な時間的動きが制約されたタイルセットを示す。フレームは、ＨＥＶＣで指定されるいくつかの時間的動きが制約されたタイルセットを含むビットストリームにエンコードされ得る。時間的動きが制約されたタイルセットの各々は、独立して復号され得る。図７に示されるように、２つ以上の左タイルが、（たとえば、ピクチャ全体を復号することなく）独立して復号されることが可能な動きが制約されたタイルセットを形成することができる。
【００４５】
３６０°映像コンテンツは、主にＨＴＴＰベースのストリーミングソリューションであるプログレッシブダウンロードまたはＤＡＳＨアダプティブストリーミングを介して配信され得る。ＨＴＴＰの代わりにＵＤＰに基づく３６０°映像用のダイナミックストリーミングが、レイテンシを低減させるために（たとえば、Ｆａｃｅｂｏｏｋによって）提案されている。
【００４６】
十分な品質を有する３６０映像を表現するために、２Ｄ投影が高い解像度を有することを必要とし得る。フル２Ｄレイアウトが高品質で符号化されると、結果の帯域幅が効果的な配信ためには大き過ぎることがある。いくつかのマッピングおよび／または投影を使用して、３６０映像の異なる部分が異なる品質で表現されることを可能にすることによって、データの量を減らすことができる。たとえば、フロントビュー（たとえばビューポート）が高品質で表現されてよくバック（たとえば反対の）ビューが低品質で表現されてよい。１つまたは複数の他のビューが１つまたは複数の他の中間品質で表現されてよい。図３に示されているオフセットされたキューブマップおよび角錐マップは、異なる品質で３６０映像の異なる部分を表現するマッピングおよび／または投影の例であり得る。角錐マップはピクセルの数を低減させ、および／または各ビューポートについてのビットレートを節約することができるが、複数のビューポートバージョンが、クライアントが要求し得る異なる見る位置を扱うことができる。３６０映像全体を配信するのと比べると、ビューポート特有のリプレゼンテーションおよび／または配信は、ユーザが見る位置を変更するときに適応するより大きなレイテンシを有する可能性がある。たとえば、オフセットされたキューブマップを使用すると、ユーザの頭分位置が１８０度回転するときに映像品質が低下することがある。
【００４７】
図８は、例示的な３６０映像ストリーミング品質低下を示す。ＤＡＳＨセグメント長および／またはクライアントバッファサイズが表示品質に影響し得る。より長いセグメント長は、より高い符号化効率をもたらすことができる。より長いセグメント長は、ビューポート変化に迅速に適応できないことがある。図８に示されるように、ユーザは、３６０映像の３つのあり得るビューポート（たとえば、Ａ、ＢおよびＣ）を有することができる。１つまたは複数（たとえば３つ）のセグメントタイプ、すなわちＳA、ＳBおよびＳCが、３６０映像に関連付けられ得る。１つまたは複数のセグメントタイプの各々が、より高品質の対応するビューポート、およびより低品質の他のビューポートを受け持つことができる。ユーザは、ビューポートＡ用のより高品質の映像およびビューポートＢおよびＣ用のより低品質の映像を受け持つセグメントＳAの再生中に、時間ｔ1でビューポートＡからビューポートＢにパンニングすることができる。ユーザは、ビューポートＢ用のより高品質の映像およびビューポートＡおよびＣ用のより低品質の映像を受け持つ次のセグメント（ＳB）に切り替わる前に、より低品質のビューポートＢを注視しなければならない可能性がある。そのような負のユーザ体験は、より短いセグメント長で解決され得る。より短いセグメント長は符号化効率を低減させ得る。ユーザのストリーミングクライアントロジックが以前のビューポートに基づいて多すぎるセグメントを予めダウンロードするときに、ユーザは、より低品質の映像を注視しなければならない可能性がある。ユーザのストリーミングクライアントが以前のビューポートに基づいて多すぎるセグメントを予めダウンロードすることを防止するために、ストリーミングバッファサイズが低減されることができる。より小さいストリーミングバッファサイズは、たとえば、より頻繁にバッファアンダーフローを引き起こすことによって、ストリーミング品質適応に影響する可能性がある。
【００４８】
ビューポート適応３６０°映像ストリーミングは、ビューポートエンハンスメントベースの配信および／またはレイヤベースの配信を含むことができる。
【００４９】
効率的な３６０映像ストリーミングは、ビットレート適応およびビューポート適応の両方を考慮することができる。ビューポートエンハンスメントベースの３６０°映像配信は、高品質で３６０映像フレームの１つまたは複数の識別されたビューポートをエンコードすることを含むことができる。たとえば、ビューポートベースのビット割り当てがエンコード中に行われ得る。ビューポートベースのビット割り当ては、ビットのより大きな部分を１つまたは複数のビューポートに割り当て、および／またはそれに応じて低減された量のビットを他のエリアに割り当てることができる。図９は、関連付けられた隣接エリアを有する例示的なビューポートエリアを示す。ビューポートエリア、隣接エリア、および他のエリアが、３６０°映像フレームに対して決定され得る。
【００５０】
ビューポートエリアに対するビットレート重みがαとして定義され得る。隣接エリアに対するビットレート重みがβとして定義され得る。他のエリアに対するビットレート重みがγとして定義され得る。以下の方程式のうちの１つまたは複数が、各エリアについてのターゲットビットレートを決定するために使用され得る。  
α＋β＋γ＝１    （３）
ＢＲHQ＝Ｒ×α    （４）
ＢＲMQ＝Ｒ×β    （５）
ＢＲLQ＝Ｒ×γ    （６）
式中、Ｒは、３６０°映像全体についての一定の符号化ビットレートを表現することができ、ＢＲHQは、ターゲットビューポートエリアについての符号化ビットレートを表現することができ、ＢＲMQは、ビューポート隣接エリアについての符号化ビットレートを表現することができ、および／またはＢＲLQは、他のエリアについての符号化ビットレートを表現することができる。
【００５１】
方程式（３）において、α、β、およびγの値は合計で１になることができ、これは、全体的ビットレートが同じに維持されることを意味することができる。たとえば、ビットは、異なるエリア（たとえば、ビューポート、隣接エリア、および他のエリア）の間で再分配されるだけであり得る。Ｒの全体的ビットレートにおいて、同じ映像が異なるバージョンにエンコードされ得る。異なるバージョンの各々は、異なるビューポート品質レベルに関連付けられ得る。異なるビューポート品質レベルの各々は、異なる値のαに対応することができる。
【００５２】
全体的ビットレートＲは、同じに維持されないことがある。たとえば、ビューポートエリア、隣接エリア、および他のエリアは、ターゲット品質レベルにエンコードされ得る。この場合、エリアの各々についてのリプレゼンテーションビットレートは異なり得る。
【００５３】
本明細書に説明されている投影法（たとえば、オフセットされたキューブマップ、角錐マップなど）は、１つもしくは複数のターゲットビューポートの品質をエンハンスメントし、および／または映像の他のエリアの品質を低減させることができる。
【００５４】
サーバ側において、ＡｄａｐｔａｔｉｏｎＳｅｔは、複数のＲｅｐｒｅｓｅｎｔａｔｉｏｎ要素を含むことができる。３６０映像ストリームのＲｅｐｒｅｓｅｎｔａｔｉｏｎは、特定の解像度および／または特定のビットレートに符号化され得る。Ｒｅｐｒｅｓｅｎｔａｔｉｏｎは、１つまたは複数の特定の品質がエンハンスメントされたビューポートに関連付けられ得る。ビューポート関係記述（Viewport Relationship Description：ＶＲＤ）は、１つまたは複数の対応するビューポート空間座標関係を指定することができる。＠ｓｃｈｅｍｅＩｄＵｒｉが「ｕｒｎ：ｍｐｅｇ：ｄａｓｈ：ｖｉｅｗｐｏｒｔ：２ｄ：２０１６」に等しいＳｕｐｐｌｅｍｅｎｔａｌＰｒｏｐｅｒｔｙおよび／またはＥｓｓｅｎｔｉａｌＰｒｏｐｅｒｔｙ記述子が、ＡｄａｐｔａｔｉｏｎＳｅｔ、Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ、および／またはＳｕｂ−Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ要素に関連付けられたＶＲＤを提供するために使用され得る。
【００５５】
ＶＲＤスキームを使用するＳｕｐｐｌｅｍｅｎｔａｌＰｒｏｐｅｒｔｙおよび／またはＥｓｓｅｎｔｉａｌＰｒｏｐｅｒｔｙ要素の＠ｖａｌｕｅは、ビューポート記述パラメータの値のコンマ区切りリストであり得る。各ＡｄａｐｔａｔｉｏｎＳｅｔ、Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ、および／またはＳｕｂ−Ｒｅｐｒｅｓｅｎｔａｔｉｏｎは、１つまたは複数のエンハンスメントされたビューポートを表現するための１つまたは複数のＶＲＤを含むことができる。エンハンスメントされたビューポートのプロパティは、表４に示されるようにＶＲＤパラメータによって記述され得る。
【００５６】
【表４】
2020110005.tif 000009
【００５７】
表５は、４Ｋ  ３６０映像のＭＰＤ例を提供する。ＡｄａｐｔａｔｉｏｎＳｅｔは、ＶＲＤスキーム識別子「ｕｒｎ：ｍｐｅｇ：ｄａｓｈ：ｖｉｅｗｐｏｒｔ：２ｄ：２０１６」を有する２つのＳｕｐｐｌｅｍｅｎｔａｌＰｒｏｐｅｒｔｙ記述子によって注釈され得る。第１の記述子は、品質レベル３を有する（１５０，１５０）におけるエンハンスメントされた３２０×６４０ビューポート＃１を指定することができる。第２の記述子は、品質レベル５を有する（１０００，１０００）におけるエンハンスメントされた６４０×９６０ビューポート＃２を指定することができる。両方のビューポートは、４０９６×２０４８フルフレーム３６０°映像の空間部分を表現することができる。２つのＲｅｐｒｅｓｅｎｔａｔｉｏｎが存在してよく、第１のＲｅｐｒｅｓｅｎｔａｔｉｏｎはフル解像度であってよく、第２のＲｅｐｒｅｓｅｎｔａｔｉｏｎはハーフ解像度であってよい。Ｒｅｐｒｅｓｅｎｔａｔｉｏｎのビューポート位置および／またはサイズは、ＶＲＤ属性＠ｆｕｌｌ＿ｗｉｄｔｈおよび／もしくは＠ｆｕｌｌ＿ｈｅｉｇｈｔの値、ならびに／またはＲｅｐｒｅｓｅｎｔａｔｉｏｎ属性＠ｗｉｄｔｈおよび／または＠ｈｅｉｇｈｔの値に基づいて識別され得る。たとえば、フル解像度Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ（たとえば、＠ｗｉｄｔｈ＝４０９６および＠ｈｅｉｇｈｔ＝２０４８）でのビューポート＃１は、サイズ３２０×６４０で（１５０，１５０）にあり得る一方、ハーフ解像度Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ（たとえば、＠ｗｉｄｔｈ＝２０４８および＠ｈｅｉｇｈｔ＝１０２４）でのビューポート＃１は、サイズ１６０×３２０で（７５，７５）にあり得る。ユーザのＷＴＲＵの１つまたは複数の能力に応じて、ハーフ解像度はフル解像度に拡張されてよい。
【００５８】
【表５】
2020110005.tif 000010
【００５９】
投影（たとえば、正距円筒図法、キューブマップ、円柱、および角錐）が、球映像の表面を処理のためにフラット画像にマッピングするために使用され得る。１つまたは複数のレイアウトが特定の投影のために利用可能であり得る。たとえば、正距円筒図法および／またはキューブマップ投影フォーマットに対して、異なるレイアウトが使用され得る。図１０Ａ〜図１０Ｄは、例示的なキューブマップレイアウトを示す。キューブマップレイアウトは、キューブレイアウト、２×３レイアウト、側部の極レイアウト、および／または単列レイアウトを含むことができる。
【００６０】
表４のＶＲＤは、特定の投影フォーマット、たとえば、正距円筒図法投影に対して指定され得る。表４のＶＲＤは、特定の投影とレイアウトの組み合わせ、たとえば、キューブマップ投影および２×３レイアウト（たとえば、図１０Ｂに示されるレイアウトＢ）に対して指定され得る。表４のＶＲＤは、表６に示されるように、同時に様々な投影フォーマットならびに／または投影およびレイアウトの組み合わせフォーマットをサポートするように拡張され得る。サーバは、たとえば表６に示されるシグナリングシンタックスを使用して、一般的な投影ならびに／または投影およびレイアウトフォーマットのセットをサポートすることができる。図１１は、正距円筒図法およびキューブマップにおける例示的なビューポート座標を示す。３６０映像の１つまたは複数（たとえば２つ）のビューポートが識別され得る。図示されるように、ビューポートの座標値は、正距円筒図法投影フォーマットとキューブマップ投影フォーマットとで異なり得る。
【００６１】
ＶＲＤは、Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ要素に関連付けられた１つまたは複数のビューポートを指定することができる。表７は、正距円筒図法ＲｅｐｒｅｓｅｎｔａｔｉｏｎとキューブマップＲｅｐｒｅｓｅｎｔａｔｉｏｎの両方が提供され、対応するＶＲＤがしかるべくシグナリングされる、ＭＰＤ例を示す。１つまたは複数の第１のＶＲＤ（たとえば、ＶＲＤ＠ｖｉｅｗｐｏｒｔ＿ｉｄ＝０，１）が、正距円筒図法投影フォーマットにおける１つまたは複数の第１のＲｅｐｒｅｓｅｎｔａｔｉｏｎ（たとえば、Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ＠ｉｄ＝０，１）でのビューポートの１つまたは複数のプロパティを指定することができる。１つまたは複数の第２のＶＲＤ（たとえば、ＶＲＤ＠ｖｉｅｗｐｏｒｔ＿ｉｄ＝２，３）が、キューブマップ投影フォーマットにおける１つまたは複数の第２のＲｅｐｒｅｓｅｎｔａｔｉｏｎ（たとえば、Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ＠ｉｄ＝２，３）でのビューポートの１つまたは複数のプロパティを指定することができる。
【００６２】
ＶＲＤは、（たとえば、関連付けられたＲｅｐｒｅｓｅｎｔａｔｉｏｎが１つの投影／レイアウトフォーマットであっても）１つまたは複数の（たとえばすべての）共通投影／レイアウトフォーマットにおける１つまたは複数のビューポート座標を指定することができる。表８は、正距円筒図法投影のＲｅｐｒｅｓｅｎｔａｔｉｏｎが提供され、正距円筒図法とキューブマップの両方の対応するビューポートのＶＲＤが提供される、ＭＰＤ例を示す。たとえば、投影およびレイアウトフォーマットは、本明細書に説明されているようにＲｅｐｒｅｓｅｎｔａｔｉｏｎレベルでシグナリングされ得る。
【００６３】
サーバは、異なるフォーマットでビューポートを指定することができ、および／または（たとえば、クライアントの能力および／または技術仕様に応じて）適切なビューポートを選ぶための柔軟性をクライアントに与えることができる。クライアントが（たとえば、表４において指定された方法または表において指定された方法のセットから）好ましいフォーマットを見つけることができない場合、クライアントは、１つまたは複数のビューポートを、指定されたフォーマットのうちの１つからクライアントが使用したいフォーマットに変換することができる。たとえば、１つまたは複数のビューポートは、キューブマップフォーマットに指定され得るが、クライアントは正距円筒図法フォーマットを使用したい。ＭＰＤで利用可能な投影および／またはレイアウト記述に基づいて、クライアントは、そのジャイロスコープ、加速度計、および／または磁気計追跡情報からユーザ方位位置を導き出すことができる。クライアントは、方位位置を特定の投影レイアウト上の対応する２Ｄ位置に変換することができる。クライアントは、＠ｖｉｅｗｐｏｒｔ＿ｘ、＠ｖｉｅｗｐｏｒｔ＿ｙ、＠ｖｉｅｗｐｏｒｔ＿ｗｉｄｔｈ、および／または＠ｖｉｅｗｐｏｒｔ＿ｈｅｉｇｈｔなどの１つまたは複数のＶＲＤパラメータの値に基づいて、識別されたビューポートを有するＲｅｐｒｅｓｅｎｔａｔｉｏｎを要求することができる。
【００６４】
【表６】
2020110005.tif 000011
【００６５】
【表７−１】
2020110005.tif 000012
【００６６】
【表７−２】
2020110005.tif 000013
【００６７】
【表８−１】
2020110005.tif 000014
【００６８】
【表８−２】
2020110005.tif 000015
【００６９】
一般的ビューポート記述子が、表９に示されるように提供され得る。一般的ビューポート記述子は、図２に示されているように球面座標（θ，φ）を使用してビューポート位置を記述することができ、ここで、θは傾斜角または極角を表現することができ、φは方位角を表現することができ、および／または正規化半径は１であり得る。
【００７０】
＠ｓｃｈｅｍｅＩｄＵｒｉが「ｕｒｎ：ｍｐｅｇ：ｄａｓｈ：ｖｉｅｗｐｏｒｔ：ｓｐｈｅｒｅ：２０１６」に等しいＳｕｐｐｌｅｍｅｎｔａｌＰｒｏｐｅｒｔｙおよび／またはＥｓｓｅｎｔｉａｌＰｒｏｐｅｒｔｙ記述子が、ＡｄａｐｔａｔｉｏｎＳｅｔ、Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ、および／またはＳｕｂ−Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ要素に関連付けられた球面座標ベースのＶＲＤを提供するために使用され得る。球面座標で指定された領域は、投影後の２Ｄ平面上の矩形領域に対応しないことがある。領域が投影後の２Ｄ平面上の矩形領域に対応しない場合、シグナリングされた領域の境界矩形が、ビューポートを指定するために導き出されおよび／または使用され得る。
【００７１】
ＶＲＤを使用するＳｕｐｐｌｅｍｅｎｔａｌＰｒｏｐｅｒｔｙおよび／またはＥｓｓｅｎｔｉａｌＰｒｏｐｅｒｔｙ要素の＠ｖａｌｕｅは、１つまたは複数のビューポート記述パラメータの値のコンマ区切りリストであり得る。各ＡｄａｐｔａｔｉｏｎＳｅｔ、Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ、および／またはＳｕｂ−Ｒｅｐｒｅｓｅｎｔａｔｉｏｎは、１つまたは複数のエンハンスメントされたビューポートを表現するための１つまたはいくつかのＶＲＤを含むことができる。エンハンスメントされたビューポートのプロパティは、表９に示されるようにパラメータによって記述され得る。
【００７２】
【表９】
2020110005.tif 000016
【００７３】
図１２は、例示的な球面座標ビューポートを示す。（たとえば、図１２ではＶとして示される）ビューポートに関して、ｖｉｅｗｐｏｒｔ＿ｉｎｃは極角θを指定することができ、ｖｉｅｗｐｏｒｔ＿ａｚは方位角（φ）を指定することができ、ｖｉｅｗｐｏｒｔ＿ｄｅｌｔａ＿ｉｎｃはｄθを指定することができ、および／またはｖｉｅｗｐｏｒｔ＿ｄｅｌｔａ＿ａｚはｄφを指定することができる。
【００７４】
２Ｄ座標を使用するＶＲＤ（たとえば、表４または表６）と球面座標を使用するＶＲＤ（たとえば表９）とを区別するために、それぞれの場合において異なる＠ｓｃｈｅｍｅＩｄＵｒｉ値が使用され得る。たとえば、２Ｄビューポート記述子に関して、＠ｓｃｈｅｍｅＩｄＵｒｉ値はｕｒｎ：ｍｐｅｇ：ｄａｓｈ：ｖｉｅｗｐｏｒｔ：２ｄ：２０１６であり得る。球面座標に基づくビューポートに関して、＠ｓｃｈｅｍｅＩｄＵｒｉ値は「ｕｒｎ：ｍｐｅｇ：ｄａｓｈ：ｖｉｅｗｐｏｒｔ：ｓｐｈｅｒｅ：２０１６」であり得る。
【００７５】
球面座標に基づくビューポート記述子を使用すると、ビューポートは１つの座標系（たとえば球面座標系）のみに対して指定され得るので、シグナリングコストを低減させることができる。球面座標に基づくビューポート記述子を使用すると、各クライアントが予め定義された変換プロセスを実装するだけでよいので、クライアント側で単純化された変換プロセスを得ることができる。たとえば、各クライアントは、クライアントが使用するために選ぶ投影フォーマット（たとえば正距円筒図法）と球リプレゼンテーションとの間の変換をすることができる。クライアントがビューポート座標をアライメントするとき、クライアントは同様のロジックを使用して、どのリプレゼンテーションを要求するかを決めることができる。
【００７６】
ＶＲＤは、１つまたは複数のＰｅｒｉｏｄＳｕｐｐｌｅｍｅｎｔａｌＰｒｏｐｅｒｔｙ要素でシグナリングされ得る。ＶＲＤは、利用可能な（たとえば、すべての利用可能な）エンハンスメントされたビューポートをそれぞれリストすることができる。Ｒｅｐｒｅｓｅｎｔａｔｉｏｎは、属性＠ｖｉｅｗｐｏｒｔＩｄを使用して、現在のＲｅｐｒｅｓｅｎｔａｔｉｏｎまたはＳｕｂ−Ｒｅｐｒｅｓｅｎｔａｔｉｏｎにどのエンハンスメントされたビューポートが関連付けられているかを識別するために１つまたは複数のビューポートインデックスをシグナリングすることができる。そのような記述子参照手法を用いて、Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ内のＶＲＤの冗長なシグナリングが回避され得る。異なる関連付けられたビューポート、投影フォーマット、および／またはレイアウトフォーマットを有する１つまたは複数のＲｅｐｒｅｓｅｎｔａｔｉｏｎが、単一のＡｄａｐｔａｔｉｏｎＳｅｔ内に割り当てられ得る。表１０は、Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ要素属性＠ｖｉｅｗｐｏｒｔＩｄおよび＠ｖｉｅｗｐｏｒｔ＿ｑｕａｌｉｔｙの例示的なセマンティクスを示す。
【００７７】
表１０に示されるように、属性＠ｖｉｅｗｐｏｒｔ＿ｑｕａｌｉｔｙは、ＶＲＤの一部として（たとえば、Ｐｅｒｉｏｄレベルの代わりに）Ｒｅｐｒｅｓｅｎｔａｔｉｏｎレベルでシグナリングされ得る。＠ｖｉｅｗｐｏｒｔ＿ｑｕａｌｉｔｙ属性は、クライアントが関心のある１つまたは複数のビューポートについての適切な品質レベルを選択することを可能にする。たとえば、ユーザが頻繁に３６０ビューをナビゲートしている（たとえば、常に頭部の向きを変えて見回している）場合、クライアントは、ビューポートと非ビューポートとの間でバランスのとれた品質を有するＲｅｐｒｅｓｅｎｔａｔｉｏｎを選択することができる。ユーザがビューポートに注目している場合、クライアントは、高いビューポート品質（しかし、たとえば非ビューポートエリアでは比較的低減された品質）を有するＲｅｐｒｅｓｅｎｔａｔｉｏｎを選択することができる。＠ｖｉｅｗｐｏｒｔ＿ｑｕａｌｉｔｙ属性はＲｅｐｒｅｓｅｎｔａｔｉｏｎレベルでシグナリングされ得る。
【００７８】
【表１０】
2020110005.tif 000017
【００７９】
表１１は、関連付けられたビューポートを指定するために表１０に示されたＲｅｐｒｅｓｅｎｔａｔｉｏｎ属性である＠ｖｉｅｗｐｏｒｔＩｄおよび＠ｖｉｅｗｐｏｒｔ＿ｑｕａｌｉｔｙを使用するＭＰＤ例である。２つのＶＲＤがＰｅｒｉｏｄ．ＳｕｐｐｌｅｍｅｎｔａｌＰｒｏｐｅｒｔｙにおいて指定され得る。第１のＲｅｐｒｅｓｅｎｔａｔｉｏｎ（たとえば＠ｉｄ＝０）は、１つまたは複数のビューポート（たとえば＠ｖｉｅｗｐｏｒｔＩｄ＝０）を含むことができ、ビューポート＃０品質レベルは２であり得る。第２のＲｅｐｒｅｓｅｎｔａｔｉｏｎ（たとえば＠ｉｄ＝１）は、第１のＲｅｐｒｅｓｅｎｔａｔｉｏｎ（たとえば＠ｖｉｅｗｐｏｒｔＩｄ＝０）と同じ１つまたは複数のビューポートを含むことができるが、ビューポート＃０の品質レベルは４であり得る。第３のＲｅｐｒｅｓｅｎｔａｔｉｏｎ（たとえば＠ｉｄ＝２）は、品質レベル５を有する１つまたは複数のエンハンスメントされたビューポート（たとえば＠ｖｉｅｗｐｏｒｔＩｄ＝１）を含むことができる。第４のＲｅｐｒｅｓｅｎｔａｔｉｏｎ（たとえば＠ｉｄ＝３）は、最高品質レベル（たとえば、＠ｖｉｅｗｐｏｒｔ＿ｑｕａｌｉｔｙ＝５，５）を有する１つまたは複数のエンハンスメントされたビューポート（たとえば＠ｖｉｅｗｐｏｒｔＩｄ＝０，１）を含むことができる。
【００８０】
【表１１−１】
2020110005.tif 000018
【００８１】
【表１１−２】
2020110005.tif 000019
【００８２】
エンハンスメントされたビューポートエリアは、実際の表示解像度よりも大きくなるように選択されることができ、それにより、ユーザがビューポートを変更する（たとえば、わずかに変更する）ときの品質低下を軽減することができる。エンハンスメントされたビューポートエリアは、セグメントピリオド中に関心のあるターゲットオブジェクトが動き回るエリアをカバーするように（たとえば、同じ高品質でターゲットが動き回るときにユーザがターゲットオブジェクトを注視できるように）選択され得る。たとえば、オリジンサーバまたはＣＤＮにおけるＲｅｐｒｅｓｅｎｔａｔｉｏｎおよび／または対応するメディアストリームの総数を減少させるために、１つまたは複数の最も注視されているビューポートが単一のビットストリームにおいてエンハンスメントされ得る。表４、表６、表９、および／または表１０において指定されたビューポート記述子は、単一ビットストリーム内の複数の品質がエンハンスメントされたビューポートをサポートすることができる。
【００８３】
図１３は、例示的なビューポートエンハンスメントリプレゼンテーションを示す。３６０°映像は、２つの識別された最も見られているビューポート（たとえば、ビューポート＃１およびビューポート＃２）を有することができる。１つまたは複数のＤＡＳＨ  Ｒｅｐｒｅｓｅｎｔａｔｉｏｎは、２つの識別された最も見られているビューポートに対応することができる。高い符号化ビットレート（たとえば２０ｍｂｐｓ）で、両方のビューポートが高品質でエンハンスメントされ得る。両方のビューポートが高品質にエンハンスメントされると、（たとえば、高速ビューポート変更を容易にするため、および／または格納コストを節約するために）１つのＲｅｐｒｅｓｅｎｔａｔｉｏｎに両方のエンハンスメントされたビューポートが提供され得る。中位ビットレートでは、３つのＲｅｐｒｅｓｅｎｔａｔｉｏｎに両方のビューポートまたは個別のビューポートにおける品質エンハンスメントが提供され得る。クライアントは、高速ビューポート変更および／またはビューポートのいずれかの高品質に対する選好に基づいて、異なるリプレゼンテーションを要求することができる。より低いビットレートでは、クライアントが視方向に基づいて適切なビューポート品質を要求できるように、２つのＲｅｐｒｅｓｅｎｔａｔｉｏｎに各ビューポートのエンハンスメントが個別に提供され得る。Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ選択は、低レイテンシビューポート切り替え、より低い格納コスト、および／または適切な表示品質の間の異なるトレードオフを可能にし得る。
【００８４】
アダプティブ３６０°映像ストリーミングセッション中に、クライアントは、利用可能な帯域幅、ユーザが注視しているビューポート、および／または視方向変更（たとえば、ビューポートが変わる速さおよび／または頻度）に基づいて、特定のリプレゼンテーションを要求することができる。クライアントＷＴＲＵは、どのＲｅｐｒｅｓｅｎｔａｔｉｏｎを要求するかを決定するために、１つまたは複数のジャイロスコープ、加速度計、および／または磁気計追跡パラメータを使用して１つまたは複数のユーザ習慣を局所的に分析することができる。たとえば、クライアントＷＴＲＵは、ユーザが視方向を頻繁に変更していないおよび／またはしないことを検出した場合、単体のエンハンスメントされたビューポートを有するＲｅｐｒｅｓｅｎｔａｔｉｏｎを要求することができる。低レイテンシレンダリングおよび／または十分なビューポート品質を保証するために、クライアントＷＴＲＵは、ユーザが視方向を変更し続けるおよび／または変更する傾向があること検出した場合、複数のエンハンスメントされたビューポートを有するＲｅｐｒｅｓｅｎｔａｔｉｏｎを要求することができる。
【００８５】
レイヤベースの３６０映像配信は、３６０°映像ストリーミングのためのビューポート適応手法であり得る。レイヤベースの３６０映像配信は、フレーム全体からビューポートエリアを分離することができる。レイヤベースの３６０映像配信は、様々な仮想および／または現実のオブジェクトの球上へのより柔軟および／または効率的な合成を可能にすることができる。
【００８６】
フレーム全体が、より低い品質、より低いフレームレート、および／またはより低い解像度でフルフレーム映像レイヤとしてエンコードされ得る。１つまたは複数のビューポートが、ビューポートレイヤとして１つまたは複数の品質Ｒｅｐｒｅｓｅｎｔａｔｉｏｎにエンコードされ得る。ビューポートレイヤは、フルフレーム映像レイヤから独立して符号化され得る。ビューポートレイヤは、スケーラブル符号化を使用して、たとえばＨＥＶＣ（ＳＨＶＣ）のスケーラブル拡張を使用して、より効率的にコーディングされることが可能であり、ここで、フルフレーム映像レイヤは、レイヤ間予測を用いて１つまたは複数のビューポートレイヤリプレゼンテーションを符号化するために参照レイヤとして使用される。ユーザは常に、フルフレーム映像レイヤを（たとえば、フォールバックレイヤとして）要求することができる。ユーザＷＴＲＵが十分な追加のリソース（たとえば、帯域幅および／またはコンピューティングリソース）を有するとき、１つまたは複数の高品質エンハンスメントビューポートがフルフレーム映像レイヤ上に重なるように要求され得る。
【００８７】
ビューポートの外部のピクセルがサブサンプリングされ得る。ビューポートの外部のエリアのフレームレートは直接低減されないことがある。レイヤベースの３６０映像配信は、３６０°映像フレーム全体からビューポートを分離することができる。３６０映像配信は、より高いビットレート、より高い解像度、および／またはより高いフレームレートでビューポートが符号化されることを可能にし得る一方で、フルフレーム映像レイヤ３６０°映像は、より低いビットレート、より低い解像度、および／またはより低いフレームレートで符号化され得る。
【００８８】
フルフレーム映像レイヤは、より低い解像度で符号化され、クライアント側でオーバーレイについてアップサンプリングされ得る。クライアント側でフルフレーム映像レイヤをアップサンプリングすることは、格納コストを削減し、および／またはより低いビットレートで許容可能な品質を提供することができる。ビューポートレイヤに関して、ビューポートの複数の品質Ｒｅｐｒｅｓｅｎｔａｔｉｏｎが細かい粒度の品質適応のために生成され得る。
【００８９】
図１４は、例示的なレイヤベースの３６０映像オーバーレイを示す。たとえば、高品質ビューポートが、３６０フルフレーム映像レイヤ上にオーバーレイされ得る。フルフレーム映像レイヤストリームは、より低い品質で３６０°映像全体を含むことができる。エンハンスメントレイヤストリームは、高い品質でエンハンスメントされたビューポートを含むことができる。
【００９０】
１つまたは複数の指向性ローパスフィルタが、突然の品質変化を滑らかにするためにオーバーレイ境界（たとえば、水平および／または垂直の境界）を横切って適用され得る。たとえば、垂直境界に沿って１つまたは複数の水平隣接ピクセルを滑らかにするために、１Ｄまたは２Ｄローパスフィルタが垂直境界上に適用されてよく、および／または水平境界に沿って１つまたは複数の垂直隣接ピクセルを滑らかにするために、同様のローパスフィルタが水平境界上に適用されてよい。
【００９１】
フルフレーム映像レイヤは、正距円筒図法、キューブマップ、オフセットされたキューブマップ、角錐などの異なる投影フォーマットで３６０°映像全体を含むことができる。投影フォーマットは、解像度、ビットレート、および／またはフレームレートなどの異なる品質レベルをサポートする複数のフルフレーム映像レイヤＲｅｐｒｅｓｅｎｔａｔｉｏｎを有することができる。
【００９２】
ビューポートレイヤは、複数のビューポートを含むことができる。ビューポートは、アダプティブストリーミングのための異なる解像度、ビットレート、および／またはフレームレートを有するいくつかの品質Ｒｅｐｒｅｓｅｎｔａｔｉｏｎを有することができる。複数のＲｅｐｒｅｓｅｎｔａｔｉｏｎは、（たとえば、各ビューポートのサイズは３６０°映像全体のサイズと比べて比較的小さいので、）高いストレージおよび／または送信コストを負担することなく、細かい粒度の品質適応をサポートするために提供され得る。
【００９３】
図１５は、例示的なレイヤベースの３６０映像リプレゼンテーションを示す。たとえば、２つ以上のＲｅｐｒｅｓｅｎｔａｔｉｏｎが、異なる解像度（２０４８×１０２４＠３０ｆｐｓおよび４０９６ｘ×２０４８＠３０ｆｐｓ）を有する３６０°映像全体のためにフルフレーム映像レイヤで利用可能であり得る。２つ以上のターゲットビューポート（たとえばビューポート＃１およびビューポート＃２）が、ビューポートレイヤで利用可能であり得る。ビューポート＃１および＃２は、異なる解像度および／または異なるビットレートを有するＲｅｐｒｅｓｅｎｔａｔｉｏｎを有することができる。ビューポートレイヤＲｅｐｒｅｓｅｎｔａｔｉｏｎは、＠ｄｅｐｅｎｄｅｎｃｙＩｄを使用して、依存Ｒｅｐｒｅｓｅｎｔａｔｉｏｎとして特定のフルフレーム映像レイヤＲｅｐｒｅｓｅｎｔａｔｉｏｎを識別することができる。ユーザは、レンダリングのための最終的３６０°映像を合成するために、ターゲットビューポートＲｅｐｒｅｓｅｎｔａｔｉｏｎおよび／またはその依存フルフレーム映像レイヤフルフレームＲｅｐｒｅｓｅｎｔａｔｉｏｎを要求することができる。
【００９４】
ＭＰＥＧ−ＤＡＳＨ  ＳＲＤ要素は、レイヤベースの３６０映像ストリーミングをサポートするために使用され得る。アプリケーションに応じて、ＭＰＤ作成者は、フルフレーム映像レイヤ３６０°フル映像とビューポートレイヤ映像との間の空間的関係を記述するために１つまたは複数のＳＲＤ値を使用することができる。ＳＲＤ要素は、空間オブジェクトの空間関係を指定することができる。ＳＲＤ要素は、１つまたは複数のビューポート映像をフルフレーム映像レイヤ上にどのようにオーバーレイするかを指定できないことがある。ビューポートオーバーレイは、レイヤベースの３６０°映像ストリーミングのストリーミング品質を改善するために指定され得る。
【００９５】
視点（viewpoint）オーバーレイが、ＡｄａｐｔａｔｉｏｎＳｅｔ要素に適用されるＲｏｌｅ記述子と共に使用され得る。＠ｓｃｈｅｍｅＩｄＵＲＩが「ｕｒｎ：ｍｐｅｇ：ｄａｓｈ：ｖｉｅｗｐｏｒｔ：ｏｖｅｒｌａｙ：２０１６」に等しいＲｏｌｅ要素は、どのＲｅｐｒｅｓｅｎｔａｔｉｏｎがビューポートレイヤ映像に関連付けられているか、および／またはどのＲｅｐｒｅｓｅｎｔａｔｉｏｎがフルフレーム映像レイヤに関連付けられているかをシグナリングすることができる。Ｒｏｌｅ要素の＠ｖａｌｕｅは、１つまたは複数のオーバーレイインジケータを含むことができる。たとえば、１つまたは複数のオーバーレイインジケータは、「ｆ」および／または「ｖ」を含むことができ、ここで、「ｆ」は、関連付けられた映像Ｒｅｐｒｅｓｅｎｔａｔｉｏｎがフルフレーム映像レイヤであることを示し、「ｖ」は、関連付けられた映像Ｒｅｐｒｅｓｅｎｔａｔｉｏｎがフルフレーム映像レイヤ上にオーバーレイされることになるビューポート映像であることを示す。１つまたは複数のビューポート映像は、フルフレーム映像レイヤ上にオーバーレイされ得る。＠ｄｅｐｅｎｄｅｎｃｙＩｄは、関連付けられたビューポート映像オーバーレイ合成のために特定のフルフレーム映像レイヤＲｅｐｒｅｓｅｎｔａｔｉｏｎを指定することができる。元のフルフレーム映像レイヤ解像度は、１つまたは複数のＳＲＤパラメータ（たとえば、関連付けられたＡｄａｐｔａｔｉｏｎＳｅｔのｔｏｔａｌ＿ｗｉｄｔｈおよびｔｏｔａｌ＿ｈｅｉｇｈｔ）によって示され得る。ビューポートの元の解像度は、１つまたは複数のＳＲＤパラメータ、関連付けられたＡｄａｐｔａｔｉｏｎＳｅｔのｏｂｊｅｃｔ＿ｗｉｄｔｈおよびｏｂｊｅｃｔ＿ｈｅｉｇｈｔによって示され得る。＠ｗｉｄｔｈおよび＠ｈｅｉｇｈｔによって示されたＲｅｐｒｅｓｅｎｔａｔｉｏｎの解像度が、ＳＲＤによって指定された対応する解像度よりも低いとき、再構築された映像が、オーバーレイのためにフルフレーム映像レイヤおよびエンハンスメントレイヤ映像をアライメントするためにアップサンプリングされ得る。表１２は、図１５に示されるレイヤベースの３６０°映像Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ例のための例示的なＭＰＤ  ＳＲＤアノテーションである。
【００９６】
表１２では、＠ｉｄで識別された２つ以上のフルフレームリプレゼンテーションが、同じＡｄａｐｔａｔｉｏｎＳｅｔに含まれ得る。第１のＲｅｐｒｅｓｅｎｔａｔｉｏｎ（＠ｉｄ＝２）はフル解像度４０９６×２０４８を含むことができ、第２のＲｅｐｒｅｓｅｎｔａｔｉｏｎ（＠ｉｄ＝１）はハーフ解像度を含むことができる。ＡｄａｐｔａｔｉｏｎＳｅｔは、ｏｂｊｅｃｔ＿ｗｉｄｔｈおよびｏｂｊｅｃｔ＿ｈｅｉｇｈｔパラメータがｔｏｔａｌ＿ｗｉｄｔｈおよびｔｏｔａｌ＿ｈｅｉｇｈｔパラメータに等しいので、ＡｄａｐｔａｔｉｏｎＳｅｔ要素が基準空間全体にわたることを記述するＳＲＤを含むことができる。ＡｄａｐｔａｔｉｏｎＳｅｔは、ソースの同じ空間部分を表現するが異なる解像度を有する２つ以上のＲｅｐｒｅｓｅｎｔａｔｉｏｎを含むことができる（たとえば、第１のＲｅｐｒｅｓｅｎｔａｔｉｏｎは４０９６×２０４８解像度を有することができ、第２のＲｅｐｒｅｓｅｎｔａｔｉｏｎは２０４８×１０２４解像度を有することができる）。＠ｓｃｈｅｍｅＩｄＵｒｉが「ｕｒｎ：ｍｐｅｇ：ｄａｓｈ：ｖｉｅｗｐｏｒｔ：ｏｖｅｒｌａｙ：２０１６」に等しく、＠ｖａｌｕｅが「ｂ１」に等しいＡｄａｐｔａｔｉｏｎＳｅｔのＲｏｌｅ要素は、１つまたは複数のＡｄａｐｔａｔｉｏｎＳｅｔ要素がフルフレーム映像レイヤフル映像であることを示すことができる。属性＠ｗｉｄｔｈおよび＠ｈｅｉｇｈｔの値によって指定されたフルフレーム映像レイヤＲｅｐｒｅｓｅｎｔａｔｉｏｎ解像度が、ＳＲＤパラメータ＠ｔｏｔａｌ＿ｗｉｄｔｈおよび＠ｔｏｔａｌ＿ｈｅｉｇｈｔの値に等しくないとき、フルフレーム映像レイヤ映像は、フルフレーム映像レイヤＲｅｐｒｅｓｅｎｔａｔｉｏｎ解像度に合致するようにアップスケーリングされ得る。
【００９７】
エンハンスメントレイヤに関して、ビューポート＃１Ｒｅｐｒｅｓｅｎｔａｔｉｏｎは第１のＡｄａｐｔａｔｉｏｎＳｅｔに含まれてよく、ビューポート＃２Ｒｅｐｒｅｓｅｎｔａｔｉｏｎは第２のＡｄａｐｔａｔｉｏｎＳｅｔに含まれてよい。各ビューポートは、異なる解像度および／または帯域幅を有することができる。ＡｄａｐｔａｔｉｏｎＳｅｔは、ＡｄａｐｔａｔｉｏｎＳｅｔ要素における映像が３６０°映像全体の一部分のみを表現することを記述するＳＲＤを含むことができる（たとえば、そのｏｂｊｅｃｔ＿ｗｉｄｔｈおよびｏｂｊｅｃｔ＿ｈｅｉｇｈｔパラメータがそのｔｏｔａｌ＿ｗｉｄｔｈおよびｔｏｔａｌ＿ｈｅｉｇｈｔよりもそれぞれ小さいため）。＠ｓｃｈｅｍｅＩｄＵｒｉが「ｕｒｎ：ｍｐｅｇ：ｄａｓｈ：ｖｉｅｗｐｏｒｔ：ｏｖｅｒｌａｙ：２０１６」に等しく、＠ｖａｌｕｅが「ｆ」に等しいＡｄａｐｔａｔｉｏｎＳｅｔのＲｏｌｅ要素は、ＡｄａｐｔａｔｉｏｎＳｅｔ要素がビューポート映像であることを示すことができる。属性＠ｗｉｄｔｈおよび＠ｈｅｉｇｈｔの値によって指定されたビューポートＲｅｐｒｅｓｅｎｔａｔｉｏｎ解像度が、ＳＲＤパラメータ＠ｏｂｊｅｃｔ＿ｗｉｄｔｈおよび＠ｏｂｊｅｃｔ＿ｈｅｉｇｈｔの値に等しくないとき、ビューポート映像は元のフルフレーム解像度に合致するようにアップスケーリングされ得る。
【００９８】
１つまたは複数（たとえばすべて）のＡｄａｐｔａｔｉｏｎＳｅｔは、同じ第１のパラメータｓｏｕｒｃｅ＿ｉｄを使用して、ＡｄａｐｔａｔｉｏｎＳｅｔにおける映像が４０９６×２０４８での基準空間内で互いに空間的に関係することを示すことができる。非ＳＲＤ認識クライアントは、ＥｓｓｅｎｔｉａｌＰｒｏｐｅｒｔｙでなくＳｕｐｐｌｅｍｅｎｔａｌＰｒｏｐｅｒｔｙの使用によりフルフレーム映像レイヤフル映像のみを見ることができる。ＳＲＤ認識クライアントは、いずれかのフルフレーム映像レイヤ（＠ｉｄ＝ｌ／２）上にビューポート＃１（＠ｉｄ＝３／４／５）および／またはビューポート＃２（＠ｉｄ＝６／７／８）映像をオーバーレイすることによって（たとえば、必要な場合にアップサンプリングされることよって）３６０°映像を形成することができる。
【００９９】
【表１２−１】
2020110005.tif 000020
【０１００】
【表１２−２】
2020110005.tif 000021
【０１０１】
図１６は、例示的なレイヤベースの３６０映像オーバーレイを示す。たとえば、例示的なレイヤベースの３６０映像オーバーレイは、表１２に列挙されたＲｅｐｒｅｓｅｎｔａｔｉｏｎに関連付けられ得る。クライアントは、ハーフ解像度フルフレーム映像レイヤＲｅｐｒｅｓｅｎｔａｔｉｏｎ（＠ｉｄ＝１）、およびエンハンスメントレイヤビューポート＃１Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ（＠ｉｄ＝５）を要求することができる。ハーフ解像度フルフレーム映像レイヤは、そのＲｅｐｒｅｓｅｎｔａｔｉｏｎ解像度＠ｗｉｄｔｈ＝２０４８および＠ｈｅｉｇｈｔ＝１０２４が、関連付けられたＳＲＤパラメータ＠ｔｏｔａｌ＿ｗｉｄｔｈ＝４０９６および＠ｔｏｔａｌ＿ｈｅｉｇｈｔ＝２０４８よりも小さいので、フル解像度４０９６×２０４８にアップサンプリングされ得る。高品質ビューポートは、関連付けられたＳＲＤパラメータでシグナリングされるようにｏｂｊｅｃｔ＿ｘ（たとえば１００）およびｏｂｊｅｃｔ＿ｙ（たとえば１００）によってシグナリングされた位置において３６０映像上にオーバーレイされ得る。
【０１０２】
図１６に示される映像変換は、（たとえば、Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ解像度、投影および／またはレイアウトが、フルフレーム映像レイヤとビューポート映像との間で一致されないとき、）アップスケーリング、投影変換、および／またはレイアウト変換を行うことができる。
【０１０３】
図１７は、例示的なレイヤベースの３６０映像オーバーレイのフローチャートを示す。
【０１０４】
フルフレーム映像レイヤおよびエンハンスメントレイヤリプレゼンテーションは、異なるフレームレートを有し得る。＠ｗｉｄｔｈ、＠ｈｅｉｇｈｔ、および＠ｂａｎｄｗｉｄｔｈと共に属性＠ｆｒａｍｅＲａｔｅが、ＡｄａｐｔａｔｉｏｎＳｅｔ、Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ、およびＳｕｂ−Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ要素についての共通の属性および要素として指定されるので、＠ｗｉｄｔｈ、＠ｈｅｉｇｈｔ、および＠ｆｒａｍｅＲａｔｅは、ＡｄａｐｔａｔｉｏｎＳｅｔ、Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ、および／またはＳｕｂ−Ｒｅｐｒｅｓｅｎｔａｔｉｏｎに対してシグナリングされ得る。＠ｆｒａｍｅＲａｔｅがＡｄａｐｔａｔｉｏｎＳｅｔレベルでシグナリングされると、ＡｄａｐｔａｔｉｏｎＳｅｔに割り当てられた１つまたは複数のＲｅｐｒｅｓｅｎｔａｔｉｏｎが、同じ値の＠ｆｒａｍｅＲａｔｅを共有することができる。表１３は、ＡｄａｐｔａｔｉｏｎＳｅｔレベルで異なるフレームレートを有するＲｅｐｒｅｓｅｎｔａｔｉｏｎに関するＭＰＤ例である。
【０１０５】
【表１３−１】
2020110005.tif 000022
【０１０６】
【表１３−２】
2020110005.tif 000023
【０１０７】
【表１３−３】
2020110005.tif 000024
【０１０８】
複数のターゲットビューポート映像が要求され、および／または３６０°フル映像球上にオーバーレイされ得る。ユーザ方位位置に基づいて、ユーザは、（たとえば、高速ビューポート変更を容易にするため、および／または全体的システムレイテンシを低減させるために、）同時に複数の高品質ビューポートを要求することができる。１つまたは複数（たとえばすべて）のビューポートレイヤが、基準空間として同じフルフレーム映像レイヤ３６０°映像を共有することができる。クライアントは、それが受信した複数のビューポートをレンダリングのために同じ基準空間上にオーバーレイすることができる。フルフレーム映像レイヤおよびエンハンスメントレイヤビューポートの間で投影およびレイアウトが異なるとき、フルフレーム映像レイヤ映像はアンカーフォーマットとして使用されることができ、および／またはエンハンスメントレイヤビューポートはアンカーフォーマットに変換されることができる（たとえば、それにより、合成位置が、フルフレーム映像レイヤとビューポート映像との間でアライメントされることができる）。
【０１０９】
図１８は、例示的な複数のビューポートオーバーレイを示す。たとえば、２つのエンハンスメントされたビューポートを有するレイヤベースのオーバーレイが、表１３に示されるようにシグナリングされ得る。クライアントは、基準空間としてのフルフレーム映像レイヤ３６０°映像（たとえば、Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ＠ｉｄ＝１）、および／または２つの高品質エンハンスメントレイヤビューポート（たとえば、Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ＠ｉｄ＝５および＠ｉｄ＝８）を要求することができる。２つのエンハンスメントされたビューポートを有するコンポジット映像は、両方のビューポートが短期間（たとえば、同じセグメント持続時間中）注視され得るという決定に基づいて生成され得る。フルフレーム映像レイヤ映像とエンハンスメントレイヤビューポートとの間で映像タイプ、投影、および／またはレイアウトが異なる場合、追加の投影および／またはレイアウト変換が行われ得る。レイヤベースの３６０映像オーバーレイは、より効率的にビューポート変更に適応できる可能性がある。フルフレーム映像レイヤのセグメント長が、（たとえば、フルフレーム映像レイヤ映像は常に配信されるので）符号化効率を改善するために増大され得る。ビューポート映像レイヤのセグメント長は、ビューポート間の速い切り替えに対応するためにより短く維持され得る。
【０１１０】
本明細書に説明されているレイヤベースの３６０映像オーバーレイは、ＳＲＤを使用して、ビューポート映像および／またはオーバーレイの空間関係を記述して、コンポジット映像を形成するためのオーバーレイ手順を記述することができる。ＳＲＤにおいて指定されたｓｏｕｒｃｅ＿ｉｄ、ｏｂｊｅｃｔ＿ｘ、ｏｂｊｅｃｔ＿ｙ、ｏｂｊｅｃｔ＿ｗｉｄｔｈ、ｏｂｊｅｃｔ＿ｈｅｉｇｈｔ、ｔｏｔａｌ＿ｗｉｄｔｈ、および／またはｔｏｔａｌ＿ｈｅｉｇｈｔなどの１つまたは複数の空間パラメータは、ＭＰＤ構造を単純化するためにオーバーレイ＠ｖａｌｕｅにマージされ得る。Ｒｏｌｅ要素の＠ｖａｌｕｅは、ビューポートインジケータ、ｓｏｕｒｃｅ＿ｉｄ、ｏｂｊｅｃｔ＿ｘ、ｏｂｊｅｃｔ＿ｙ、ｏｂｊｅｃｔ＿ｗｉｄｔｈ、ｏｂｊｅｃｔ＿ｈｅｉｇｈｔ、ｔｏｔａｌ＿ｗｉｄｔｈ、および／またはｔｏｔａｌ＿ｈｅｉｇｈｔのコンマ区切りリストを含むことができる。表１４は、マージされたオーバーレイを有するＭＰＤ例を示す。
【０１１１】
【表１４−１】
2020110005.tif 000025
【０１１２】
【表１４−２】
2020110005.tif 000026
【０１１３】
レイヤベースの３６０映像オーバーレイは、＠ｓｃｈｅｍｅＩｄＵｒｉが「ｕｒｎ：ｍｐｅｇ：ｄａｓｈ：ｖｉｅｗｐｏｒｔ：ｏｖｅｒｌａｙ：２０１６」に等しいＳｕｐｐｌｅｍｅｎｔａｌＰｒｏｐｅｒｔｙおよび／またはＥｓｓｅｎｔｉａｌＰｒｏｐｅｒｔｙなどの１つまたは複数の記述子によって提供され得る。
【０１１４】
異なる映像Ｒｅｐｒｅｓｅｎｔａｔｉｏｎは、異なる投影フォーマットにあり得る（たとえば、一方のＲｅｐｒｅｓｅｎｔａｔｉｏｎは正距円筒図法であるのに対して別のＲｅｐｒｅｓｅｎｔａｔｉｏｎはキューブマップである、または一方の映像Ｒｅｐｒｅｓｅｎｔａｔｉｏｎは球映像であるのに対して別の映像Ｒｅｐｒｅｓｅｎｔａｔｉｏｎは直線的である）。映像プロパティは、ＯＭＡＦファイルフォーマットから指定され得る。ＡｄａｐｔａｔｉｏｎＳｅｔ、Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ、および／またはＳｕｂ−Ｒｅｐｒｅｓｅｎｔａｔｉｏｎについて指定された１つまたは複数の共通属性、＠ｖｉｄｅｏＴｙｐｅは、球映像、ライトフィールド映像、および／または直線的映像を示すことができる。球映像の場合、異なる投影フォーマットおよび／または投影＋レイアウトの組み合わせ、たとえば、正距円筒図法、（たとえば、図１０に示されている異なるレイアウトと組み合わせた）キューブマップ、および／また角錐マップなどが、ＡｄａｐｔａｔｉｏｎＳｅｔ、Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ、および／またはＳｕｂ−Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ要素についての共通属性＠ｐｒｏｊｅｃｔｉｏｎおよび／または＠ｌａｙｏｕｔとしてシグナリングされ得る。要素および属性は、ＳｕｐｐｌｅｍｅｎｔａｌＰｒｏｐｅｒｔｙおよび／またはＥｓｓｅｎｔｉａｌＰｒｏｐｅｒｔｙ要素を使用して提供され得る。
【０１１５】
表１５は、映像タイプおよび／または投影属性のセマンティクス例である。投影属性は、クライアントの能力に基づいてユーザが適切な映像を要求するのを支援することができる。たとえば、球映像および／またはライトフィールド映像をサポートしないクライアントは、直線的映像のみを要求することができる。例では、球映像をサポートするクライアントは、利用可能なフォーマットのセットから適切なフォーマット（たとえば、キューブマップの代わりに正距円筒図法）を選択することができる。
【０１１６】
【表１５】
2020110005.tif 000027
【０１１７】
【表１６】
2020110005.tif 000028
【０１１８】
【表１７】
2020110005.tif 000029
【０１１９】
【表１８】
2020110005.tif 000030
【０１２０】
表１８のレイアウトフォーマットは以下の図で例示され得る。
【０１２１】
図１９は、側部のハーフハイト極を有する例示的な正距円筒図法リプレゼンテーションを示す。
【０１２２】
図２０は、側部のフルハイト極を有する例示的な正距円筒図法リプレゼンテーションを示す。
【０１２３】
図２１は、（たとえば、ｒｅｇｉｏｎ＿ｉｄを有する）キューブリプレゼンテーションフォーマットのための例示的な単列レイアウトを示す。
【０１２４】
図２２は、（たとえば、ｒｅｇｉｏｎ＿ｉｄを有する）キューブリプレゼンテーションフォーマットのための例示的な２×３レイアウトを示す。
【０１２５】
図２３は、キューブマップのための例示的な１８０°レイアウトを示す。
【０１２６】
キューブマップ投影のための１８０°レイアウトは、（たとえば、後半分のエリアの幅および高さを半分に減らすことによって）キューブの後半分の解像度を２５％低下させることができ、および／または、結果として図２３に示される領域ａ、ｂ、ｃ、ｄ、およびｅが前半分に属し領域ｆ、ｇ、ｈ、ｉ、およびｊが後半分に属するレイアウトを使用することができる。
【０１２７】
表１９は、そのような共通の属性および要素を使用して正距円筒図法投影とキューブマップ投影の両方をサポートするＭＰＤ例である。
【０１２８】
【表１９−１】
2020110005.tif 000031
【０１２９】
【表１９−２】
2020110005.tif 000032
【０１３０】
図２４Ａは、開示される１つまたは複数の実施形態が実装され得る例示的な通信システム１００の図である。通信システム１００は、音声、データ、映像、メッセージング、ブロードキャストなどのコンテンツを複数の無線ユーザに提供する、多元接続システムとすることができる。通信システム１００は、複数の無線ユーザが、無線帯域幅を含むシステムリソースの共有を通じてそのようなコンテンツにアクセスすることを可能にし得る。たとえば、通信システム１００は、符号分割多元接続（ＣＤＭＡ）、時分割多元接続（ＴＤＭＡ）、周波数分割多元接続（ＦＤＭＡ）、直交ＦＤＭＡ（ＯＦＤＭＡ）、シングルキャリアＦＤＭＡ（ＳＣ−ＦＤＭＡ）など、１つまたは複数のチャネルアクセス方法を利用することができる。
【０１３１】
図２４Ａに示されるように、通信システム１００は、（一般にまたは集合的にＷＴＲＵ１０２と呼ばれることがある）無線送受信ユニット（ＷＴＲＵ）１０２ａ、１０２ｂ、１０２ｃ、および／または１０２ｄ、無線アクセスネットワーク（ＲＡＮ）１０３／１０４／１０５、コアネットワーク１０６／１０７／１０９、公衆交換電話網（ＰＳＴＮ）１０８、インターネット１１０、ならびに他のネットワーク１１２を含むことができるが、開示される実施形態は、任意の数のＷＴＲＵ、基地局、ネットワーク、および／またはネットワーク要素を企図することが理解されよう。ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄの各々は、無線環境で動作および／または通信するように構成された任意のタイプのデバイスとすることができる。例として、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、無線信号を送信および／または受信するように構成されてよく、ユーザ機器（ＵＥ）、移動局、固定もしくは移動加入者ユニット、ページャ、セルラ電話、携帯情報端末（ＰＤＡ）、スマートフォン、ラップトップ、ネットブック、パーソナルコンピュータ、無線センサ、および家電製品などを含むことができる。
【０１３２】
通信システム１００は、基地局１１４ａおよび基地局１１４ｂを含むこともできる。基地局１１４ａ、１１４ｂの各々は、コアネットワーク１０６／１０７／１０９、インターネット１１０、および／またはネットワーク１１２などの１つまたは複数の通信ネットワークへのアクセスを容易にするために、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのうちの少なくとも１つと無線でインターフェース接続するように構成された、任意のタイプのデバイスとすることができる。例として、基地局１１４ａ、１１４ｂは、トランシーバ基地局（ＢＴＳ）、ノードＢ、ｅノードＢ、ホームノードＢ、ホームｅノードＢ、サイトコントローラ、アクセスポイント（ＡＰ）、および無線ルータなどにすることができる。基地局１１４ａ、１１４ｂは各々が単一の要素として示されているが、基地局１１４ａ、１１４ｂは、任意の数の相互接続された基地局および／またはネットワーク要素を含むことができることが理解されよう。
【０１３３】
基地局１１４ａは、ＲＡＮ１０３／１０４／１０５の一部とすることができ、ＲＡＮ１０３／１０４／１０５は、基地局コントローラ（ＢＳＣ）、無線ネットワークコントローラ（ＲＮＣ）、中継ノードなど、他の基地局および／またはネットワーク要素（図示せず）を含むこともできる。基地局１１４ａおよび／または基地局１１４ｂは、セル（図示せず）と呼ばれることがある特定の地理的領域内で、無線信号を送信および／または受信するように構成され得る。セルは、さらにセルセクタに分割され得る。たとえば、基地局１１４ａに関連付けられたセルは、３つのセクタに分割され得る。したがって、一実施形態では、基地局１１４ａは、３つのトランシーバ（Transceiver：無線送受信機）を、たとえば、セルのセクタごとに１つ含むことができる。別の実施形態では、基地局１１４ａは、多入力多出力（ＭＩＭＯ）技術を利用することができ、したがって、セルのセクタごとに複数のトランシーバを利用することができる。
【０１３４】
基地局１１４ａ、１１４ｂは、エアインターフェース１１５／１１６／１１７を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのうちの１つまたは複数と通信することができ、エアインターフェース１１５／１１６／１１７は、任意の適切な無線通信リンク（たとえば、無線周波数（ＲＦ）、マイクロ波、赤外線（ＩＲ）、紫外線（ＵＶ）、可視光など）とすることができる。エアインターフェース１１５／１１６／１１７は、任意の適切な無線アクセス技術（ＲＡＴ）を使用して確立され得る。
【０１３５】
より具体的には、上記されたように、通信システム１００は、多元接続システムとすることができ、ＣＤＭＡ、ＴＤＭＡ、ＦＤＭＡ、ＯＦＤＭＡ、およびＳＣ−ＦＤＭＡなどの１つまたは複数のチャネルアクセス方式を利用することができる。たとえば、ＲＡＮ１０３／１０４／１０５内の基地局１１４ａ、およびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、広帯域ＣＤＭＡ（ＷＣＤＭＡ（登録商標））を使用してエアインターフェース１１５／１１６／１１７を確立できる、ユニバーサル移動体通信システム（ＵＭＴＳ）地上無線アクセス（ＵＴＲＡ）などの無線技術を実装することができる。ＷＣＤＭＡは、高速パケットアクセス（ＨＳＰＡ）および／またはＥｖｏｌｖｅｄ  ＨＳＰＡ（ＨＳＰＡ＋）などの通信プロトコルを含むことができる。ＨＳＰＡは、高速ダウンリンクパケットアクセス（ＨＳＤＰＡ）および／または高速アップリンクパケットアクセス（ＨＳＵＰＡ）を含むことができる。
【０１３６】
別の実施形態では、基地局１１４ａ、およびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ロングタームエボリューション（ＬＴＥ）および／またはＬＴＥアドバンスト（ＬＴＥ−Ａ）を使用してエアインターフェース１１５／１１６／１１７を確立できる、Ｅｖｏｌｖｅｄ  ＵＭＴＳ地上無線アクセス（Ｅ−ＵＴＲＡ）などの無線技術を実装することができる。
【０１３７】
他の実施形態では、基地局１１４ａ、およびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ＩＥＥＥ８０２．１６（たとえば、マイクロ波アクセス用世界的相互運用（ＷｉＭＡＸ））、ＣＤＭＡ２０００、ＣＤＭＡ２０００  １Ｘ、ＣＤＭＡ２０００  ＥＶ−ＤＯ、暫定標準２０００（ＩＳ−２０００）、暫定標準９５（ＩＳ−９５）、暫定標準８５６（ＩＳ−８５６）、移動体通信用グローバルシステム（ＧＳＭ（登録商標））、ＧＳＭエボリューション用拡張データレート（ＥＤＧＥ）、およびＧＳＭ  ＥＤＧＥ（ＧＥＲＡＮ）などの無線技術を実装することができる。
【０１３８】
図２４Ａにおける基地局１１４ｂは、たとえば、無線ルータ、ホームノードＢ、ホームｅノードＢ、またはアクセスポイントとすることができ、職場、家庭、乗り物、およびキャンパスなどの局所的エリアにおける無線接続性を容易にするために任意の適切なＲＡＴを利用することができる。一実施形態では、基地局１１４ｂおよびＷＴＲＵ１０２ｃ、１０２ｄは、ＩＥＥＥ８０２．１１などの無線技術を実装して無線ローカルエリアネットワーク（ＷＬＡＮ）を確立することができる。別の実施形態では、基地局１１４ｂおよびＷＴＲＵ１０２ｃ、１０２ｄは、ＩＥＥＥ８０２．１５などの無線技術を実装して無線パーソナルエリアネットワーク（ＷＰＡＮ）を確立することができる。さらに別の実施形態では、基地局１１４ｂおよびＷＴＲＵ１０２ｃ、１０２ｄは、セルラベースのＲＡＴ（たとえば、ＷＣＤＭＡ、ＣＤＭＡ２０００、ＧＳＭ、ＬＴＥ、ＬＴＥ−Ａなど）を利用してピコセルまたはフェムトセルを確立することができる。図２４Ａに示されるように、基地局１１４ｂは、インターネット１１０への直接接続を有することができる。したがって、基地局１１４ｂは、コアネットワーク１０６／１０７／１０９を介してインターネット１１０にアクセスすることを必要とされなくてよい。
【０１３９】
ＲＡＮ１０３／１０４／１０５は、コアネットワーク１０６／１０７／１０９と通信することができ、コアネットワーク１０６／１０７／１０９は、音声、データ、アプリケーション、および／またはボイスオーバーインターネットプロトコル（ＶｏＩＰ）サービスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのうちの１つまたは複数に提供するように構成された、任意のタイプのネットワークとすることができる。たとえば、コアネットワーク１０６／１０７／１０９は、呼制御、請求サービス、モバイルロケーションベースのサービス、プリペイド通話、インターネット接続性、映像配信などを提供することができ、および／またはユーザ認証などの高レベルセキュリティ機能を実行することができる。図２４Ａに示されていないが、ＲＡＮ１０３／１０４／１０５および／またはコアネットワーク１０６／１０７／１０９は、ＲＡＮ１０３／１０４／１０５と同じＲＡＴまたは異なるＲＡＴを利用する他のＲＡＮとの直接的または間接的な通信が可能であることが理解されよう。たとえば、Ｅ−ＵＴＲＡ無線技術を利用し得るＲＡＮ１０３／１０４／１０５に接続されるのに加えて、コアネットワーク１０６／１０７／１０９は、ＧＳＭ無線技術を利用する別のＲＡＮ（図示せず）と通信することもできる。
【０１４０】
コアネットワーク１０６／１０７／１０９は、ＰＳＴＮ１０８、インターネット１１０、および／または他のネットワーク１１２にアクセスするための、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのためのゲートウェイの役割をすることもできる。ＰＳＴＮ１０８は、基本電話サービス（ＰＯＴＳ）を提供する回線交換電話網を含むことができる。インターネット１１０は、ＴＣＰ／ＩＰインターネットプロトコルスイートにおける伝送制御プロトコル（ＴＣＰ）、ユーザデータグラムプロトコル（ＵＤＰ）、およびインターネットプロトコル（ＩＰ）などの共通の通信プロトコルを使用する、相互接続されたコンピュータネットワークおよびデバイスのグローバルシステムを含むことができる。ネットワーク１１２は、他のサービスプロバイダによって所有および／または運用される有線または無線通信ネットワークを含むことができる。たとえば、ネットワーク１１２は、ＲＡＮ１０３／１０４／１０５と同じＲＡＴまたは異なるＲＡＴを利用できる１つまたは複数のＲＡＮに接続された別のコアネットワークを含むことができる。
【０１４１】
通信システム１００におけるＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄの一部または全部は、マルチモード能力を含むことができ、たとえば、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、異なる無線リンクを介して異なる無線ネットワークと通信するための複数のトランシーバを含むことができる。たとえば、図２４Ａに示されているＷＴＲＵ１０２ｃは、セルラベースの無線技術を利用できる基地局１１４ａ、およびＩＥＥＥ８０２無線技術を利用できる基地局１１４ｂと通信するように構成され得る。
【０１４２】
図２４Ｂは、例示的なＷＴＲＵ１０２のシステム図である。図２４Ｂに示されるように、ＷＴＲＵ１０２は、プロセッサ１１８、トランシーバ１２０、送受信要素１２２、スピーカ／マイクロフォン１２４、キーパッド１２６、ディスプレイ／タッチパッド１２８、着脱不能メモリ１３０、着脱可能メモリ１３２、電源１３４、全地球測位システム（ＧＰＳ）チップセット１３６、および他の周辺機器１３８を含むことができる。ＷＴＲＵ１０２は、実施形態との整合性を保ちながら、上記の要素の任意の部分的組み合わせを含むことができることが理解されよう。また、実施形態は、基地局１１４ａおよび１１４ｂ、ならびに／または基地局１１４ａおよび１１４ｂが表し得るノード、たとえば以下に限定されないが特に、トランシーバ局（ＢＴＳ）、ノードＢ、サイトコントローラ、アクセスポイント（ＡＰ）、ホームノードＢ、ｅｖｏｌｖｅｄホームノードＢ（ｅＮｏｄｅＢ）、ホームｅｖｏｌｖｅｄノードＢ（ＨｅＮＢ）、ホームｅｖｏｌｖｅｄノードＢゲートウェイ、およびプロキシノードなどが、図２４Ｂに示され本明細書で説明される要素の一部または全部を含み得ることを企図している。
【０１４３】
プロセッサ１１８は、汎用プロセッサ、専用プロセッサ、従来型プロセッサ、デジタル信号プロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアと関連した１つまたは複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、他の任意のタイプの集積回路（ＩＣ）、および状態機械などとすることができる。プロセッサ１１８は、信号符号化、データ処理、電力制御、入出力処理、および／またはＷＴＲＵ１０２が無線環境で動作するのを可能にする他の任意の機能性を実行することができる。プロセッサ１１８はトランシーバ１２０に結合されることができ、トランシーバ１２０は送受信要素１２２に結合されることができる。図２４Ｂはプロセッサ１１８とトランシーバ１２０を別々のコンポーネントとして示しているが、プロセッサ１１８とトランシーバ１２０は電子パッケージまたはチップに一緒に統合されてよいことが理解されよう。
【０１４４】
送受信要素１２２は、エアインターフェース１１５／１１６／１１７を介して、基地局（たとえば基地局１１４ａ）に信号を送信し、または基地局から信号を受信するように構成され得る。たとえば、一実施形態では、送受信要素１２２は、ＲＦ信号を送信および／または受信するように構成されたアンテナとすることができる。別の実施形態では、送受信要素１２２は、たとえば、ＩＲ、ＵＶ、または可視光信号を送信および／または受信するように構成されたエミッタ／ディテクタとすることができる。さらに別の実施形態では、送受信要素１２２は、ＲＦ信号と光信号の両方を送信および受信するように構成され得る。送受信要素１２２が無線信号の任意の組み合わせを送信および／または受信するように構成され得ることは理解されよう。
【０１４５】
加えて、図２４Ｂでは送受信要素１２２は単一の要素として示されているが、ＷＴＲＵ１０２は任意の数の送受信要素１２２を含むことができる。より具体的には、ＷＴＲＵ１０２はＭＩＭＯ技術を利用することができる。したがって、一実施形態では、ＷＴＲＵ１０２は、エアインターフェース１１５／１１６／１１７を介して無線信号を送信および受信するための２つ以上の送受信要素１２２（たとえば、複数のアンテナ）を含むことができる。
【０１４６】
トランシーバ１２０は、送受信要素１２２によって送信される信号を変調し、送受信要素１２２によって受信された信号を復調するように構成され得る。上記されたように、ＷＴＲＵ１０２はマルチモード能力を有することができる。したがって、トランシーバ１２０は、たとえばＵＴＲＡおよびＩＥＥＥ８０２．１１などの複数のＲＡＴを介してＷＴＲＵ１０２が通信することを可能にするための、複数のトランシーバを含むことができる。
【０１４７】
ＷＴＲＵ１０２のプロセッサ１１８は、スピーカ／マイクロフォン１２４、キーパッド１２６、および／またはディスプレイ／タッチパッド１２８（たとえば、液晶表示（ＬＣＤ）ディスプレイユニットもしくは有機発光ダイオード（ＯＬＥＤ）表示ユニット）に結合されることができ、それらからユーザ入力データを受信することができる。プロセッサ１１８は、スピーカ／マイクロフォン１２４、キーパッド１２６、および／またはディスプレイ／タッチパッド１２８にユーザデータを出力することもできる。加えて、プロセッサ１１８は、着脱不能メモリ１３０および／または着脱可能メモリ１３２などの任意のタイプの適切なメモリからの情報にアクセスすることができ、それらにデータを記憶することができる。着脱不能メモリ１３０は、ランダムアクセスメモリ（ＲＡＭ）、読み出し専用メモリ（ＲＯＭ）、ハードディスク、または他の任意のタイプのメモリストレージデバイスを含むことができる。着脱可能メモリ１３２は、加入者識別モジュール（ＳＩＭ）カード、メモリスティック、およびセキュアデジタル（ＳＤ）メモリカードなどを含むことができる。他の実施形態では、プロセッサ１１８は、ＷＴＲＵ１０２上に物理的に配置されたメモリではなく、サーバまたはホームコンピュータ（図示せず）上などのメモリからの情報にアクセスすることができ、それらにデータを記憶することができる。
【０１４８】
プロセッサ１１８は、電源１３４から電力を受け取ることができ、ＷＴＲＵ１０２内の他のコンポーネントへの電力の分配および／または制御をするように構成され得る。電源１３４は、ＷＴＲＵ１０２に電力供給するための任意の適切なデバイスとすることができる。たとえば、電源１３４は、１つまたは複数の乾電池（たとえば、ニッケルカドミウム（ＮｉＣｄ）、ニッケル−亜鉛（ＮｉＺｎ）、ニッケル水素（ＮｉＭＨ）、リチウムイオン（Ｌｉ−ｉｏｎ）など）、太陽電池、および燃料電池などを含むことができる。
【０１４９】
プロセッサ１１８は、ＧＰＳチップセット１３６に結合されてもよく、ＧＰＳチップセット１３６は、ＷＴＲＵ１０２の現在位置に関する位置情報（たとえば、経度および緯度）を提供するように構成され得る。ＧＰＳチップセット１３６からの情報に加えてまたは代えて、ＷＴＲＵ１０２は、基地局（たとえば、基地局１１４ａ、１１４ｂ）からエアインターフェース１１５／１１６／１１７を介して位置情報を受信し、および／または２つ以上の近くの基地局から受信された信号のタイミングに基づいてその位置を決定することができる。ＷＴＲＵ１０２は、実施形態との整合性を保ちながら、任意の適切な位置決定方法によって位置情報を取得できることが理解されよう。
【０１５０】
プロセッサ１１８は、他の周辺機器１３８にさらに結合されてよく、他の周辺機器１３８は、追加的な特徴、機能性、および／または有線もしくは無線接続性を提供する１つまたは複数のソフトウェアおよび／またはハードウェアモジュールを含むことができる。たとえば、周辺機器１３８は、加速度計、電子コンパス、衛星トランシーバ、（写真または映像用）デジタルカメラ、ユニバーサルシリアルバス（ＵＳＢ）ポート、振動デバイス、テレビトランシーバ、ハンズフリーヘッドセット、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール、周波数変調（ＦＭ）無線ユニット、デジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、およびインターネットブラウザなどを含むことができる。
【０１５１】
図２４Ｃは、実施形態によるＲＡＮ１０３およびコアネットワーク１０６のシステム図である。上記されたように、ＲＡＮ１０３は、ＵＴＲＡ無線技術を利用して、エアインターフェース１１５を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信することができる。ＲＡＮ１０３は、コアネットワーク１０６と通信することもできる。図２４Ｃに示されるように、ＲＡＮ１０３は、ノードＢ１４０ａ、１４０ｂ、１４０ｃを含むことができ、ノードＢ１４０ａ、１４０ｂ、１４０ｃは各々が、エアインターフェース１１５を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するための１つまたは複数のトランシーバを含むことができる。ノードＢ１４０ａ、１４０ｂ、１４０ｃは各々が、ＲＡＮ１０３内の特定のセル（図示せず）に関連付けられ得る。ＲＡＮ１０３はＲＮＣ１４２ａ、１４２ｂを含むこともできる。ＲＡＮ１０３は、実施形態との整合性を保ちながら、任意の数のノードＢおよびＲＮＣを含むことができることが理解されよう。
【０１５２】
図２４Ｃに示されるように、ノードＢ１４０ａ、１４０ｂはＲＮＣ１４２ａと通信することができる。加えて、ノードＢ１４０ｃはＲＮＣ１４２ｂと通信することができる。ノードＢ１４０ａ、１４０ｂ、１４０ｃは、Ｉｕｂインターフェースを介してそれぞれのＲＮＣ１４２ａ、１４２ｂと通信することができる。ＲＮＣ１４２ａ、１４２ｂは、Ｉｕｒインターフェースを介して互いに通信することができる。ＲＮＣ１４２ａ、１４２ｂの各々は、それが接続されたそれぞれのノードＢ１４０ａ、１４０ｂ、１４０ｃを制御するように構成され得る。加えて、ＲＮＣ１４２ａ、１４２ｂの各々は、アウタループ電力制御、負荷制御、アドミッション制御、パケットスケジューリング、ハンドオーバ制御、マクロダイバーシティ、セキュリティ機能、およびデータ暗号化など、他の機能性を実施またはサポートするように構成され得る。
【０１５３】
図２４Ｃに示されるコアネットワーク１０６は、メディアゲートウェイ（ＭＧＷ）１４４、移動交換局（ＭＳＣ）１４６、サービングＧＰＲＳサポートノード（ＳＧＳＮ）１４８、および／またはゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）１５０を含むことができる。上記の要素の各々はコアネットワーク１０６の部分として示されているが、これらの要素のいずれも、コアネットワークオペレータとは異なるエンティティによって所有および／または運用され得ることが理解されよう。
【０１５４】
ＲＡＮ１０３内のＲＮＣ１４２ａは、ＩｕＣＳインターフェースを介してコアネットワーク１０６内のＭＳＣ１４６に接続され得る。ＭＳＣ１４６はＭＧＷ１４４に接続され得る。ＭＳＣ１４６およびＭＧＷ１４４は、ＰＳＴＮ１０８などの回線交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと従来の陸線通信デバイスとの間の通信を容易にすることができる。
【０１５５】
ＲＡＮ１０３内のＲＮＣ１４２ａは、ＩｕＰＳインターフェースを介してコアネットワーク１０６内のＳＧＳＮ１４８にも接続され得る。ＳＧＳＮ１４８はＧＧＳＮ１５０に接続され得る。ＳＧＳＮ１４８およびＧＧＳＮ１５０は、インターネット１１０などのパケット交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとＩＰ対応デバイスとの間の通信を容易にすることができる。
【０１５６】
上記されたように、コアネットワーク１０６は、ネットワーク１１２にも接続されてよく、ネットワーク１１２は、他のサービスプロバイダによって所有および／または運用される他の有線または無線ネットワークを含むことができる。
【０１５７】
図２４Ｄは、実施形態によるＲＡＮ１０４およびコアネットワーク１０７のシステム図である。上記されたように、ＲＡＮ１０４は、Ｅ−ＵＴＲＡ無線技術を利用して、エアインターフェース１１６を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信することができる。ＲＡＮ１０４はコアネットワーク１０７と通信することもできる。
【０１５８】
ＲＡＮ１０４はｅノードＢ１６０ａ、１６０ｂ、１６０ｃを含むことができるが、ＲＡＮ１０４は、実施形態との整合性を保ちながら、任意の数のｅノードＢを含むことができることが理解されよう。ｅノードＢ１６０ａ、１６０ｂ、１６０ｃは各々が、エアインターフェース１１６を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するための１つまたは複数のトランシーバを含むことができる。一実施形態では、ｅノードＢ１６０ａ、１６０ｂ、１６０ｃはＭＩＭＯ技術を実装することができる。したがって、ｅノードＢ１６０ａは、たとえば、複数のアンテナを使用して、ＷＴＲＵ１０２ａに無線信号を送信し、ＷＴＲＵ１０２ａから無線信号を受信することができる。
【０１５９】
ｅノードＢ１６０ａ、１６０ｂ、１６０ｃの各々は、セル（図示せず）に関連付けられてよく、無線リソース管理決定、ハンドオーバ決定、ならびにアップリンクおよび／またはダウンリンクにおけるユーザのスケジューリングなどを処理するように構成され得る。図２４Ｄに示されるように、ｅノードＢ１６０ａ、１６０ｂ、１６０ｃはＸ２インターフェースを介して互いに通信することができる。
【０１６０】
図２４Ｄに示されるコアネットワーク１０７は、モビリティ管理ゲートウェイ（ＭＭＥ）１６２、サービングゲートウェイ１６４、およびパケットデータネットワーク（ＰＤＮ）ゲートウェイ１６６を含むことができる。上記の要素の各々はコアネットワーク１０７の部分として示されているが、これらの要素のいずれも、コアネットワークオペレータとは異なるエンティティによって所有および／または運用され得ることが理解されよう。
【０１６１】
ＭＭＥ１６２は、Ｓ１インターフェースを介してＲＡＮ１０４内のｅノードＢ１６０ａ、１６０ｂ、１６０ｃの各々に接続されてよく、制御ノードの役割をすることができる。たとえば、ＭＭＥ１６２は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのユーザの認証、ベアラアクティブ化／非アクティブ化、およびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃの初期アタッチ中のサービングゲートウェイの選択などを担当することができる。ＭＭＥ１６２は、ＲＡＮ１０４とＧＳＭまたはＷＣＤＭＡなどの他の無線技術を利用する他のＲＡＮ（図示せず）との間の切り替えのための制御プレーン機能を提供することもできる。
【０１６２】
サービングゲートウェイ１６４は、Ｓ１インターフェースを介してＲＡＮ１０４内のｅノードＢ１６０ａ、１６０ｂ、１６０ｃの各々に接続され得る。サービングゲートウェイ１６４は一般に、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃへ／からのユーザデータパケットのルーティングおよび転送を行うことができる。サービングゲートウェイ１６４は、ｅノードＢ間ハンドオーバ中にユーザプレーンをアンカリングすること、ダウンリンクデータがＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに利用可能なときにページングをトリガすること、ならびにＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのコンテキストを管理および記憶することなど、他の機能を実行することもできる。
【０１６３】
サービングゲートウェイ１６４は、ＰＤＮゲートウェイ１６６に接続されてもよく、ＰＤＮゲートウェイ１６６は、インターネット１１０などのパケット交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとＩＰ対応デバイスとの間の通信を容易にすることができる。
【０１６４】
コアネットワーク１０７は他のネットワークとの通信を容易にすることができる。たとえば、コアネットワーク１０７は、ＰＳＴＮ１０８などの回線交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと従来の陸線通信デバイスとの間の通信を容易にすることができる。たとえば、コアネットワーク１０７は、コアネットワーク１０７とＰＳＴＮ１０８との間のインターフェースとしての役割をするＩＰゲートウェイ（たとえば、ＩＰマルチメディアサブシステム（ＩＭＳ）サーバ）を含むことができ、またはそのようなＩＰゲートウェイと通信することができる。加えて、コアネットワーク１０７は、ネットワーク１１２へのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供することができ、ネットワーク１１２は、他のサービスプロバイダによって所有および／または運用される他の有線または無線ネットワークを含むことができる。
【０１６５】
図２４Ｅは、実施形態によるＲＡＮ１０５およびコアネットワーク１０９のシステム図である。ＲＡＮ１０５は、ＩＥＥＥ８０２．１６無線技術を利用してエアインターフェース１１７を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信する、アクセスサービスネットワーク（ＡＳＮ）とすることができる。以下でさらに説明されるように、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、ＲＡＮ１０５、およびコアネットワーク１０９の異なる機能エンティティの間の通信リンクが、基準点として定義され得る。
【０１６６】
図２４Ｅに示されるように、ＲＡＮ１０５は、基地局１８０ａ、１８０ｂ、１８０ｃおよびＡＳＮゲートウェイ１８２を含むことができるが、ＲＡＮ１０５は、実施形態との整合性を保ちながら、任意の数の基地局およびＡＳＮゲートウェイを含むことができることが理解されよう。基地局１８０ａ、１８０ｂ、１８０ｃは各々が、ＲＡＮ１０５内のセル（図示せず）に関連付けられてよく、各々が、エアインターフェース１１７を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するための１つまたは複数のトランシーバを含むことができる。一実施形態では、基地局１８０ａ、１８０ｂ、１８０ｃはＭＩＭＯ技術を実装することができる。したがって、基地局１８０ａは、たとえば、複数のアンテナを使用して、ＷＴＲＵ１０２ａに無線信号を送信し、ＷＴＲＵ１０２ａから無線信号を受信することができる。基地局１８０ａ、１８０ｂ、１８０ｃは、ハンドオフトリガ、トンネル確立、無線リソース管理、トラフィック分類、およびサービス品質（ＱｏＳ）ポリシ実施などのモビリティ管理機能を提供することもできる。ＡＳＮゲートウェイ１８２は、トラフィック集約点の役割をすることができ、ページング、加入者プロファイルのキャッシング、およびコアネットワーク１０９へのルーティングなどを担当することができる。
【０１６７】
ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとＲＡＮ１０５との間のエアインターフェース１１７は、ＩＥＥＥ８０２．１６仕様を実装するＲ１基準点として定義され得る。加えて、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃの各々は、コアネットワーク１０９との論理インターフェース（図示せず）を確立することができる。ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとコアネットワーク１０９との間の論理インターフェースは、認証、認可、ＩＰホスト構成管理、および／またはモビリティ管理のために使用され得るＲ２基準点として定義され得る。
【０１６８】
基地局１８０ａ、１８０ｂ、１８０ｃの各々の間の通信リンクは、ＷＴＲＵハンドオーバおよび基地局間のデータの転送を容易にするためのプロトコルを含むＲ８基準点として定義され得る。基地局１８０ａ、１８０ｂ、１８０ｃとＡＳＮゲートウェイ１８２との間の通信リンクは、Ｒ６基準点として定義され得る。Ｒ６基準点は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃの各々に関連付けられたモビリティイベントに基づくモビリティ管理を容易にするためのプロトコルを含むことができる。
【０１６９】
図２４Ｅに示されるように、ＲＡＮ１０５はコアネットワーク１０９に接続され得る。ＲＡＮ１０５とコアネットワーク１０９との間の通信リンクは、たとえばデータ転送およびモビリティ管理能力を容易にするためのプロトコルを含むＲ３基準点として定義され得る。コアネットワーク１０９は、モバイルＩＰホームエージェント（ＭＩＰ−ＨＡ）１８４、認証、認可、課金（ＡＡＡ）サーバ１８６、およびゲートウェイ１８８を含むことができる。上記の要素の各々はコアネットワーク１０９の部分として示されているが、これらの要素のいずれも、コアネットワークオペレータとは異なるエンティティによって所有および／または運用され得ることが理解されよう。
【０１７０】
ＭＩＰ−ＨＡは、ＩＰアドレス管理を担当することができ、異なるＡＳＮおよび／または異なるコアネットワークの間でＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃがローミングすることを可能にし得る。ＭＩＰ−ＨＡ１８４は、インターネット１１０などのパケット交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとＩＰ対応デバイスとの間の通信を容易にすることができる。ＡＡＡサーバ１８６は、ユーザ認証、およびユーザサービスのサポートを担当することができる。ゲートウェイ１８８は、他のネットワークとの網間接続を容易にすることができる。たとえば、ゲートウェイ１８８は、ＰＳＴＮ１０８などの回線交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと従来の陸線通信デバイスとの間の通信を容易にすることができる。加えて、ゲートウェイ１８８は、ネットワーク１１２へのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供し、ネットワーク１１２は、他のサービスプロバイダによって所有および／または運用される他の有線または無線ネットワークを含むことができる。
【０１７１】
本明細書に説明されているコンピューティングシステムの各々は、本明細書に説明された機能を実現するために、本明細書に説明されたパラメータを決定し、エンティティ（たとえば、ＷＴＲＵおよびネットワークまたはクライアントおよびサーバ）の間でメッセージを送信および受信することを含む、本明細書に説明された機能を実現するための実行可能命令で構成されたメモリを有する１つもしくは複数のコンピュータプロセッサまたはハードウェアを有することができる。上記に説明されたプロセスは、コンピュータおよび／またはプロセッサによって実行するためのコンピュータ可読媒体に組み込まれたコンピュータプログラム、ソフトウェア、および／またはファームウェアで実装され得る。
【０１７２】
図２４Ｅに示されていないが、ＲＡＮ１０５は他のＡＳＮに接続されてよく、コアネットワーク１０９は他のコアネットワークに接続されてよいことが理解されよう。ＲＡＮ１０５と他のＡＳＮとの間の通信リンクは、ＲＡＮ１０５と他のＡＳＮとの間でＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのモビリティを調整するためのプロトコルを含むことができるＲ４基準点として定義され得る。コアネットワーク１０９と他のコアネットワークとの間の通信リンクは、ホームコアネットワークと訪問先コアネットワークとの間の網間接続を容易にするためのプロトコルを含むことができるＲ５基準点として定義され得る。
【０１７３】
特徴および要素が特定の組み合わせで上記に説明されているが、各特徴または要素は、単独でまたは他の特徴および要素との任意の組み合わせで使用され得ることが当業者には理解されよう。加えて、本明細書に説明された方法は、コンピュータまたはプロセッサによって実行するためのコンピュータ可読媒体に組み込まれたコンピュータプログラム、ソフトウェア、またはファームウェアで実装され得る。コンピュータ可読媒体の例は、（有線または無線接続を介して送信される）電子信号、およびコンピュータ可読記憶媒体を含む。コンピュータ可読記憶媒体の例は、読み出し専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、レジスタ、キャッシュメモリ、半導体メモリデバイス、内蔵ハードディスクおよび着脱可能ディスクなどの磁気媒体、光磁気媒体、ならびにＣＤ−ＲＯＭディスクおよびデジタル多用途ディスク（ＤＶＤ）などの光媒体を含むが、これらに限定されない。ソフトウェアと関連するプロセッサは、ＷＴＲＵ、ＷＴＲＵ、端末、基地局、ＲＮＣ、または任意のホストコンピュータで使用するための無線周波数トランシーバを実装するために使用され得る。
【産業上の利用可能性】
【０１７４】
本発明は、想現実（ＶＲ）デバイスに利用できる。
【符号の説明】
【０１７５】
１００  通信システム
１０２、１０２ａ〜１０２ｄ  ＷＴＲＵ
１０３、１０４、１０５  ＲＡＮ
１０６、１０７、１０８  コアネットワーク
１０８  ＰＳＴＮ
１１０  インターネット
１１２  他のネットワーク
１１４ａ、１１４ｂ  基地局
１１８  プロセッサ
１２０  無線送受信機（トランシーバ）
１２２  アンテナ
【図１】
2020110005.tif 000033
【図２】
2020110005.tif 000034
【図３】
2020110005.tif 000035
【図４】
2020110005.tif 000036
【図５】
2020110005.tif 000037
【図６】
2020110005.tif 000038
【図７】
2020110005.tif 000039
【図８】
2020110005.tif 000040
【図９】
2020110005.tif 000041
【図１０Ａ】
2020110005.tif 000042
【図１０Ｂ】
2020110005.tif 000043
【図１０Ｃ】
2020110005.tif 000044
【図１０Ｄ】
2020110005.tif 000045
【図１１Ａ】
2020110005.tif 000046
【図１１Ｂ】
2020110005.tif 000047
【図１２】
2020110005.tif 000048
【図１３Ａ】
2020110005.tif 000049
【図１３Ｂ】
2020110005.tif 000050
【図１４】
2020110005.tif 000051
【図１５】
2020110005.tif 000052
【図１６】
2020110005.tif 000053
【図１７】
2020110005.tif 000054
【図１８】
2020110005.tif 000055
【図１９】
2020110005.tif 000056
【図２０】
2020110005.tif 000057
【図２１】
2020110005.tif 000058
【図２２】
2020110005.tif 000059
【図２３】
2020110005.tif 000060
【図２４Ａ】
2020110005.tif 000061
【図２４Ｂ】
2020110005.tif 000062
【図２４Ｃ】
2020110005.tif 000063
【図２４Ｄ】
2020110005.tif 000064
【図２４Ｅ】
2020110005.tif 000065
【手続補正書】
【提出日】令和2年4月16日(2020.4.16)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
３６０度映像に関連付けられたメディアプレゼンテーション記述（ＭＰＤ）ファイルを受信し、
前記受信されたＭＤＰファイルに基づいて、第１の品質表現（Quality representation）において、第１の映像レイヤ(video layer)を要求し、前記第１の映像レイヤは前記３６０度映像を含み、
ユーザの第１のビューポートを識別し、
前記ユーザの前記第１のビューポートが利用可能なことを決定し、
前記ユーザの前記第１のビューポートが利用可能である条件で、
前記受信されたＭＤＰファイルに基づいて、第２の品質表現において、第２の映像レイヤからコンテンツを要求し、前記要求されたコンテンツは前記第１のビューポートと関連付けられており、前記要求されたコンテンツは前記３６０度映像の第１の空間サブセットであり、
前記要求されたコンテンツを前記第１の映像レイヤ上にオーバレイして表示し、
前記ユーザの前記第１のビューポートが利用不能である条件で、前記第１の映像レイヤを表示する
よう構成されたプロセッサ
を備えた装置。
【請求項２】
前記プロセッサは、
前記ユーザが前記第１のビューポートを第２のビューポートに変更したと決定し、
前記受信されたＭＤＰファイルに基づいて、第３の品質表現において、第３の映像レイヤからコンテンツを要求し、前記要求されたコンテンツは前記３６０度映像の第２の空間サブセットであり、
前記要求されたコンテンツを前記第１の映像レイヤ上にオーバレイして表示する
よう構成された請求項１の装置。
【請求項３】
前記プロセッサは、
第１のセグメント長に対して、前記第１の品質表現において、前記第１の映像レイヤを要求し、第２のセグメント長に対して、前記第２の品質表現において、前記第２の映像レイヤから前記コンテンツを要求し、前記第１のセグメント長は前記第２のセグメント長よりも長い
よう構成された請求項１の装置。
【請求項４】
前記３６０度映像は、スケーラブル３６０度映像を含む、請求項１の装置。
【請求項５】
前記第１の映像レイヤは、前記スケーラブル３６０度映像に関連付けられたスケーラブルベース映像レイヤを含み、前記第２の映像レイヤは、前記スケーラブル３６０度映像に関連付けられたスケーラブルエンハンスド映像レイヤを含む、請求項４の装置。
【請求項６】
前記第２の品質表現は、前記第１の品質表現よりもより高い品質を有する、請求項１の装置。
【請求項７】
前記第２の映像レイヤは、前記前記第１の映像レイヤよりも、より高いビットレート、より高い分解能、または、より高いフレームレートで符号化される、請求項１の装置。
【請求項８】
３６０度映像に関連付けられたメディアプレゼンテーション記述（ＭＰＤ）ファイルを受信するステップと、
前記受信されたＭＤＰファイルに基づいて、第１の品質表現において、第１の映像レイヤを要求するステップであって、前記第１の映像レイヤは前記３６０度映像を含む、ステップと、
ユーザの第１のビューポートを識別するステップと、
前記ユーザの前記第１のビューポートが利用可能なことを決定するステップと、
前記ユーザの前記第１のビューポートが利用可能である条件で、
前記受信されたＭＤＰファイルに基づいて、第２の品質表現において、第２の映像レイヤからコンテンツを要求するステップであって、前記要求されたコンテンツは前記第１のビューポートと関連付けられており、前記要求されたコンテンツは前記３６０度映像の第１の空間サブセットである、ステップと、
前記要求されたコンテンツを前記第１の映像レイヤ上にオーバレイして表示するステップと、
前記ユーザの前記第１のビューポートが利用不能である条件で、前記第１の映像レイヤを表示するステップと
を備える方法。
【請求項９】
前記ユーザが前記第１のビューポートを第２のビューポートに変更したと決定するステップと、
前記受信されたＭＤＰファイルに基づいて、第３の品質表現において、第３の映像レイヤからコンテンツを要求するステップであって、前記要求されたコンテンツは前記３６０度映像の第２の空間サブセットである、ステップと、
前記要求されたコンテンツを前記第１の映像レイヤ上にオーバレイして表示するステップと
を備える請求項８の方法。
【請求項１０】
第１のセグメント長に対して、前記第１の品質表現において、前記第１の映像レイヤを要求し、第２のセグメント長に対して、前記第２の品質表現において、前記第２の映像レイヤから前記コンテンツを要求するステップであって、前記第１のセグメント長は前記第２のセグメント長よりも長い、ステップ
を備える請求項８の方法。
【請求項１１】
前記３６０度映像は、スケーラブル３６０度映像を含む、請求項８の方法。
【請求項１２】
前記第１の映像レイヤは、前記スケーラブル３６０度映像に関連付けられたスケーラブルベース映像レイヤを含み、前記第２の映像レイヤは、前記スケーラブル３６０度映像に関連付けられたスケーラブルエンハンスド映像レイヤを含む、請求項１１の方法。
【請求項１３】
前記第２の品質表現は、前記第１の品質表現よりもより高い品質を有する、請求項８の方法。
【請求項１４】
前記第２の映像レイヤは、前記前記第１の映像レイヤよりも、より高いビットレート、より高い分解能、または、より高いフレームレートで符号化される、請求項８の方法。