IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ ヴィド スケール インコーポレイテッドの特許一覧

特開2023-116547ビューポート適応360度映像配信の方法および装置
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2023116547
(43)【公開日】2023-08-22
(54)【発明の名称】ビューポート適応360度映像配信の方法および装置
(51)【国際特許分類】
   H04N 21/431 20110101AFI20230815BHJP
【FI】
H04N21/431
【審査請求】有
【請求項の数】12
【出願形態】OL
(21)【出願番号】P 2023088008
(22)【出願日】2023-05-29
(62)【分割の表示】P 2020051176の分割
【原出願日】2017-05-26
(31)【優先権主張番号】62/342,158
(32)【優先日】2016-05-26
(33)【優先権主張国・地域又は機関】US
【公序良俗違反の表示】
(特許庁注:以下のものは登録商標)
1.FACEBOOK
(71)【出願人】
【識別番号】514041959
【氏名又は名称】ヴィド スケール インコーポレイテッド
(74)【代理人】
【識別番号】110001243
【氏名又は名称】弁理士法人谷・阿部特許事務所
(72)【発明者】
【氏名】ヨン・ヘー
(72)【発明者】
【氏名】ヤン・イエ
(72)【発明者】
【氏名】スリニヴァス・グヅマス
(72)【発明者】
【氏名】エドゥアルド・アスブン
(72)【発明者】
【氏名】アームド・ハムザ
(57)【要約】
【課題】映像サイズが非常に大きくなり、映像が配信されるとき高伝送帯域幅を招き得る。ユーザは画像全体のごく一部のみを見るので配信中の高帯域幅消費は無駄にされ得る。
【解決手段】クライアント中心サービス品質管理のためのシステム、方法、および手段が開示される。360度映像の第1のビューポートが決定され得る。360度映像は、正距円筒図法、キューブマップ、円柱、角錐、および/または球投影マッピングのうちの1つまたは複数を含むことができる。第1のビューポートは、360度映像の空間領域に関連付けられ得る。空間領域の周囲に広がる隣接エリアが決定され得る。360度映像の第2のビューポートが決定され得る。360度映像に関連付けられたビットストリームが受信され得る。1つまたは複数のエンハンスメントされた領域がビットストリームに含まれ得る。1つまたは複数のエンハンスメントされた領域は、第1のビューポートおよび/または第2のビューポートに対応することができる。
【選択図】図13B
【特許請求の範囲】
【請求項1】
360度映像に関連付けられた複数のリプレゼンテーションを含むメディアプレゼンテーションディスクリプション(MPD)ファイルを受信することであって、前記複数のリプレゼンテーションは、第1のリプレゼンテーションおよび第2のリプレゼンテーションを含み、前記第1のリプレゼンテーションは、第1の品質にて前記360度映像に対する第1のビデオレイヤに関連付けられ、前記第2のリプレゼンテーションは、第2の品質にて前記360度映像の1または複数の空間サブセットに対する第2のビデオレイヤに関連付けられる、ことと、
前記受信されたMPDファイルに基づいて、前記第1のリプレゼンテーションの前記第1のビデオレイヤを要求することと、
表示されると予想されるユーザのビューポートを識別することと、
前記ユーザの前記識別されたビューポートおよび前記受信されたMPDファイルに基づいて前記第2のリプレゼンテーションの前記360度映像の空間サブセットに対応する前記第2のビデオレイヤを要求することと、
前記ユーザの現在のビューポートをレンダリングすることであって、前記現在のビューポートは、前記第1のリプレゼンテーションの前記第1のビデオレイヤにオーバーレイされた前記第2のリプレゼンテーションの前記第2のビデオレイヤを含み、前記第2の品質は、前記第1の品質よりも高い品質を有する、ことと
を実行するように構成されたプロセッサ
を備えた装置。
【請求項2】
前記第1のビデオレイヤは、前記360度映像に関連付けられたフルフレームビデオレイヤであり、前記第2のビデオレイヤは、前記360度映像の前記1または複数の空間サブセットである、請求項1の装置。
【請求項3】
前記360度映像は、スケーラブル360度映像を含む、請求項1の装置。
【請求項4】
前記第1のビデオレイヤは、前記360度映像に関連付けられたスケーラブルベースレイヤであり、前記第2のビデオレイヤは、前記360度映像に関連付けられたスケーラブルエンハンスメントレイヤである、請求項1の装置。
【請求項5】
前記第2のビデオレイヤは、前記第1のビデオレイヤよりも、より高いビットレート、より高い分解能、および、より高いフレームレートのうちの1または複数で符号化される、請求項1の装置。
【請求項6】
前記第2のビデオレイヤは、前記第1のビデオレイヤとは独立して符号化される、請求項1の装置。
【請求項7】
360度映像に関連付けられた複数のリプレゼンテーションを含むメディアプレゼンテーションディスクリプション(MPD)ファイルを受信することであって、前記複数のリプレゼンテーションは、第1のリプレゼンテーションおよび第2のリプレゼンテーションを含み、前記第1のリプレゼンテーションは、第1の品質にて前記360度映像に対する第1のビデオレイヤに関連付けられ、前記第2のリプレゼンテーションは、第2の品質にて前記360度映像の1または複数の空間サブセットに対する第2のビデオレイヤに関連付けられる、ことと、
前記受信されたMPDファイルに基づいて、前記第1のリプレゼンテーションの前記第1のビデオレイヤを要求することと、
表示されると予想されるユーザのビューポートを識別することと、
前記ユーザの前記識別されたビューポートおよび前記受信されたMPDファイルに基づいて前記第2のリプレゼンテーションの前記360度映像の空間サブセットに対応する前記第2のビデオレイヤを要求することと、
前記ユーザの現在のビューポートをレンダリングすることであって、前記現在のビューポートは、前記第1の品質の前記第1のリプレゼンテーションの前記第1のビデオレイヤにオーバーレイされた前記第2の品質の前記第2のリプレゼンテーションの前記第2のビデオレイヤを含み、前記第2の品質は、前記第1の品質よりも高い品質を有する、ことと
を備える方法。
【請求項8】
前記第1のビデオレイヤは、前記360度映像に関連付けられたフルフレームビデオレイヤであり、前記第2のビデオレイヤは、前記360度映像の前記1または複数の空間サブセットである、請求項7の方法。
【請求項9】
前記360度映像は、スケーラブル360度映像を含む、請求項7の方法。
【請求項10】
前記第1のビデオレイヤは、前記360度映像に関連付けられたスケーラブルベースレイヤであり、前記第2のビデオレイヤは、前記360度映像に関連付けられたスケーラブルエンハンスメントレイヤである、請求項7の方法。
【請求項11】
前記第2のビデオレイヤは、前記第1のビデオレイヤよりも、より高いビットレート、より高い分解能、および、より高いフレームレートのうちの1または複数で符号化される、請求項7の方法。
【請求項12】
前記第2のビデオレイヤは、前記第1のビデオレイヤとは独立して符号化される、請求項7の方法。
【発明の詳細な説明】
【背景技術】
【0001】
関連出願の相互参照
本出願は、参照により本明細書に組み込まれている、2016年5月26日に出願された米国特許仮出願第62/342158号明細書の優先権および利益を主張するものである。
【0002】
360°映像は、メディア産業で急速に発展しているフォーマットである。360°映像は、仮想現実(VR)デバイスの利用可能性の向上により実現されている。360°映像は、見る人に新しい臨場感を提供することができる。直線的(rectilinear)映像(たとえば2Dまたは3D)と比べると、360°映像は、映像処理および/または配信に困難な技術的課題をもたらし得る。快適性および/または没入型ユーザ体験を可能にするには、高い映像品質および/または非常に低いレイテンシを必要とし得る。360°映像の大きな映像サイズは、360°映像を大規模に高品質で配信することの障害となり得る。
【0003】
360°映像アプリケーションおよび/またはサービスは、360°映像全体をプログレッシブダウンロードおよび/またはアダプティブストリーミングのための標準準拠ストリームにエンコードすることがある。360°映像全体をクライアントに配信することは、低レイテンシレンダリングを可能にし得る(たとえば、クライアントは、360°映像コンテンツの全体にアクセスすることができ、および/または、さらなる制限なしに見たい部分をレンダリングするように選択することができる)。サーバの観点からは、同じストリームが、場合によっては異なるビューポートを用いる複数のユーザをサポートすることができる。
【発明の概要】
【発明が解決しようとする課題】
【0004】
映像サイズが非常に大きくなり、映像が配信されるときに高伝送帯域幅を招くことがある(たとえば、360°映像全体が、1眼あたり60fpsで4Kまたは90fpsで6Kなどの高品質でエンコードされる必要があるためである)。たとえば、ユーザは画像全体のごく一部(たとえばビューポート)のみを見ることがあるので、配信中の高帯域幅消費は無駄にされることがある。
【課題を解決するための手段】
【0005】
ビューポート適応(viewport adaptive)360°映像配信のためのシステム、方法、および手段が開示される。ビューポートエンハンスメントベースの360度映像が、配信および/またはシグナリングされ得る。360度映像は、レイヤベースのビューポートオーバーレイを使用して配信され得る。360度映像マッピングのシグナリングが提供され得る。
【0006】
360度映像の第1のビューポートが決定され得る。360度映像は、正距円筒図法(equirectangular)、キューブマップ(cube-map)、円柱、角錐、および/または球投影(spherical projection)マッピングのうちの1つまたは複数を含むことができる。第1のビューポートは、360度映像の空間領域に関連付けられ得る。空間領域の周囲に広がる隣接エリアが決定され得る。360度映像の第2のビューポートが決定され得る。360度映像に関連付けられたビットストリームが受信され得る。ビットストリームは、1つまたは複数のエンハンスメントされた領域を含むことができる。1つまたは複数のエンハンスメントされた領域は、第1のビューポートおよび/または第2のビューポートに対応することができる。高符号化ビットレートが第1のビューポートおよび/または第2のビューポートに関連付けられ得る。360度映像配信に関連付けられた1つまたは複数のビューポートプロパティを示すシグナリングが受信され得る。
【0007】
360度映像を処理するためのWTRUは、(i)メディアセグメントの多面幾何投影(multi-face geometric projection)フォーマットのための面パッキング(face-packing)レイアウトを示す本質的プロパティ要素を含む360度映像に関連付けられたメディアプレゼンテーション記述(media presentation description:MPD)を受信することと、(ii)メディアセグメントを受信することと、(iii)本質的プロパティ要素に基づいて、面パッキングレイアウトのセットから、受信されたメディアセグメントについての少なくとも1つの面パッキングレイアウトを決定することと、(iv)決定された少なくとも1つの面パッキングレイアウトに基づいて、受信されたメディアセグメントを構築することとのうちの1つまたは複数を行うように(たとえば、メモリに保存された実行可能命令によって)構成されたプロセッサを備えることができる。
【0008】
面パッキングレイアウトのセットは、plate carree、ハーフハイトの側部の極(poles on the side half height)、フルハイトの側部の極(poles on the side full height)、単列(single row)、2×3、および180度を含む。本質的プロパティ要素は、アダプテーション(adaptation)レベル内およびリプレゼンテーション(representation)レベル内のうちの一方であり得る。
【0009】
WTRUプロセッサは、将来のメディアセグメントを要求するために、MPDに関連付けられたメディアリプレゼンテーションを決定し、決定されたメディアリプレゼンテーションに対する要求を送るように、(たとえば、メモリに保存された実行可能命令によって)構成され得る。
【0010】
MPDは、メディアセグメントについての、映像タイプのセットから選択された映像タイプを含むことができる。映像タイプのセットは、直線的、パノラマ、球、およびライトフィールド(lightfield)を含むことができる。WTRUプロセッサは、受信されたメディアセグメントについての映像タイプを決定し、および/または決定された映像タイプを使用して受信されたメディアセグメントを構築するように、(たとえば、メモリに保存された実行可能命令によって)構成され得る。
【0011】
MPDは、360度映像を全方向性(omnidirectional)フォーマットから直線的映像フレームに投影するために使用される少なくとも1つの投影フォーマットを含むことができる。投影フォーマットは、正距円筒図法、キューブ、オフセットされたキューブ(offset cube)、つぶされた球(squished sphere)、角錐、および円柱のうちの1つを含むことができる。WTRUプロセッサは、映像ファイルを受信するための投影フォーマットを決定し、および/または決定された投影フォーマットに対する要求を送るように、(たとえば、メモリに保存された実行可能命令によって)構成され得る。360度映像は、全方向性メディアアプリケーションフォーマット(Omnidirectional Media Application Format:OMAF)ファイルを含むことができる。
【0012】
360度映像を処理するためのWTRUを使用する方法は、(i)メディアセグメントの多面幾何投影フォーマットのための面パッキングレイアウトを示す本質的プロパティ要素を含む360度映像に関連付けられたメディアプレゼンテーション記述(MPD)を受信するステップと、(ii)メディアセグメントを受信するステップと、(iii)本質的プロパティ要素に基づいて、面パッキングレイアウトのセットから、受信されたメディアセグメントについての少なくとも1つの面パッキングレイアウトを決定するステップと、(iv)決定された少なくとも1つの面パッキングレイアウトに基づいて、受信されたメディアセグメントを構築するステップとのうちの1つまたは複数を含むことができる。
【0013】
WTRUを使用する上記方法は、将来の受信された映像ファイルを要求するために、MPDに関連付けられたメディアリプレゼンテーションを決定するステップと、および/または決定されたメディアリプレゼンテーションに対する要求を送るステップとを含むことができる。上記方法は、受信されたメディアセグメントについての映像タイプを決定するステップと、および/または決定された映像タイプを使用して受信されたメディアセグメントを構築するステップとを含むことができる。上記方法は、映像ファイルのための投影フォーマットを決定するステップと、および/または決定された投影フォーマットに対する要求を送るステップとを含むことができる。
【0014】
360度映像を処理するためのWTRUは、360度映像に関連付けられたメディアプレゼンテーション記述(MPD)であって、メディアセグメントの多面幾何投影フォーマットのための第1の面パッキングレイアウトを示す第1の本質的プロパティ要素と、メディアセグメントの多面幾何投影フォーマットのための第1の第2のパッキングレイアウトを示す第2の本質的プロパティ要素とを含むメディアプレゼンテーション記述(MPD)を受信することと、メディアセグメントについて第1の面パッキングレイアウトを使用するか第2の面パッキングレイアウトを使用するかを決定することと、決定された少なくとも第1の面パッキングレイアウトまたは第2の面パッキングレイアウトを要求することと、メディアセグメントを受信することと、要求された面パッキングレイアウトに基づいて、受信されたメディアセグメントに関連付けられた360度映像を再構築することとのうちの1つまたは複数を行うように(たとえば、メモリに保存された実行可能命令によって)構成されたプロセッサを備えることができる。
【発明の効果】
【0015】
新規なビューポート適応360°映像配信のためのシステム、方法、および手段を提供する。
【図面の簡単な説明】
【0016】
図1】ヘッドマウントデバイス(HMD)上に表示された360°映像の例示的な部分を示す図である。
図2】360°映像の例示的な正距円筒図法投影を示す図である。
図3】例示的な360°映像マッピングを示す図である。
図4】例示的なメディアプレゼンテーション記述(MPD)階層データモデルを示す図である。
図5】映像に関する例示的ダイナミックアダプティブストリーミングオーバーHTTP(DASH)空間関係記述(spatial relationship description:SRD)を示す図である。
図6】例示的なタイルベースの映像分割を示す図である。
図7】例示的時間的動き(temporal motion)が制約されたタイルセットの図である。
図8】例示的な360°映像ストリーミング品質低下を示す図である。
図9】関連付けられた隣接エリアを有する例示的ビューポートエリアを示す図である。
図10A】例示的なキューブマップレイアウトを示す図である。
図10B】例示的なキューブマップレイアウトを示す図である。
図10C】例示的なキューブマップレイアウトを示す図である。
図10D】例示的なキューブマップレイアウトを示す図である。
図11A】例示的な正距円筒座標ビューポートマッピングを示す図である。
図11B】例示的なキューブマップ座標ビューポートマッピングを示す図である。
図12】例示的な球面座標ビューポートマッピングを示す図である。
図13A】例示的なビューポートエンハンスメントリプレゼンテーションの図である。
図13B】例示的なビューポートエンハンスメントリプレゼンテーションの図である。
図14】例示的なレイヤベースの360°映像オーバーレイを示す図である。
図15】例示的なレイヤベースの360°映像リプレゼンテーションを示す図である。
図16】例示的なレイヤベースの360°映像オーバーレイを示す図である。
図17】例示的なレイヤベースの360°映像オーバーレイのフローチャートである。
図18】複数のビューポートを有する例示的なレイヤベースの360°映像オーバーレイを示す図である。
図19】側部のハーフハイト極を有する例示的な正距円筒図法リプレゼンテーションを示す図である。
図20】側部のフルハイト極を有する例示的な正距円筒図法リプレゼンテーションを示す図である。
図21】例示的な単列レイアウトキューブリプレゼンテーションを示す図である。
図22】例示的な2×3レイアウトキューブリプレゼンテーションを示す図である。
図23】例示的な180°キューブマップレイアウトを示す図である。
図24A】1つまたは複数の開示されている実施形態が実装され得る例示的な通信システムの図である。
図24B図24Aに示されている通信システム内で使用され得る例示的な無線送受信ユニット(WTRU)のシステム図である。
図24C図24Aの通信システム内で使用され得る例示的な無線アクセスネットワークおよびコアネットワークのシステム図である。
図24D図24Aの通信システム内で使用され得る別の例示的な無線アクセスネットワークおよびコアネットワークのシステム図である。
図24E図24Aの通信システム内で使用され得る別の例示的な無線アクセスネットワークおよびコアネットワークのシステム図である。
【発明を実施するための形態】
【0017】
ここで、例示的実施形態の詳細な説明が様々な図を参照して説明される。この説明は可能な実装形態の詳細な例を提供するが、詳細は例示的であることが意図され、本出願の範囲を何ら限定するものではないことに留意されたい。
【0018】
図1は、ヘッドマウントデバイス(HMD)上に表示された360°映像の例示的な部分を示す。360°映像を見るとき、ユーザは、たとえば図1に示されるように、映像の一部分を提示され得る。映像の一部分は、ユーザが画像を見回すおよび/またはズームするときに変更され得る。映像の一部分は、HMDにより提供されたフィードバック、または他のタイプのユーザインターフェース(たとえば、無線送受信ユニット(WTRU))に基づいて変更され得る。ビューポートは、360°映像全体の空間領域であってよく、またはそのような空間領域を含んでよい。ビューポートは、完全にまたは部分的にユーザに提示され得る。ビューポートは、360°映像の他の部分とは異なる1つまたは複数の品質を有することができる。
【0019】
360°映像は、(たとえば、任意のビューポートを選ぶ能力をユーザに与えるために、)球上にキャプチャおよび/またはレンダリングされ得る。球映像フォーマットは、従来の映像コーデックを使用して直接配信され得る。360°映像(たとえば球映像など)は、投影法を使用して球映像を2D平面上に投影することによって圧縮され得る。投影された2D映像は、(たとえば、従来の映像コーデックを使用して)符号化され得る。投影法の例は、正距円筒図法投影を含むことができる。図2は、360°映像の例示的な正距円筒図法投影を示す。たとえば、正距円筒図法投影法は、以下の方程式のうちの1つまたは複数を使用して、球上の座標(θ,φ)を有する第1の点Pを2D平面上の座標(u,v)を有する第2の点Pにマッピングすることができる。
u=φ/(2*pi)+0.5 (1)
v=0.5-θ/(pi) (2)
【0020】
図3は、例示的な360°映像マッピングを示す。たとえば、1つまたは複数の他の投影法(たとえば、マッピング)を使用して、(たとえば、代替的に帯域幅要件を低減するために)360°映像を2D平面映像に変換することができる。たとえば、1つまたは複数の他の投影法は、角錐マップ、キューブマップ、および/またはオフセットされたキューブマップを含むことができる。1つまたは複数の他の投影法は、より少ないデータで球映像を表現するために使用され得る。
【0021】
ビューポート特有のリプレゼンテーションが使用され得る。図3に示されている投影法のうちの1つまたは複数、たとえば、キューブマップおよび/または角錐投影は、異なるビューポートに対して均一でない品質の表現を提供することがある(たとえば、いくつかのビューポートは、他のビューポートよりも高品質で表現され得る)。異なるターゲットビューポートを有する同じ映像の複数のバージョンが、(たとえば、球映像のすべてのビューポートをサポートするために)サーバ側で生成および/または記憶され得る。たとえば、VR映像配信のFacebookの実装形態では、図3に示されているオフセットされたキューブマップフォーマットが使用されることがある。オフセットされたキューブマップは、最高解像度(たとえば最高品質)をフロントビューポートに提供し、最低解像度(たとえば最低品質)をバックビューに提供し、中間解像度(たとえば中間品質)を1つまたは複数のサイドビューに提供することができる。サーバは、(たとえば、同じコンテンツの異なるビューポートに対するクライアント要求を受け入れるために)同じコンテンツの異なるバージョンを記憶することができる。たとえば、同じコンテンツについて合計150個の異なるバージョン(たとえば、30個のビューポート×ビューポートごとに5個の解像度)。配信(たとえばストリーミング)中に、クライアントは、その現在のビューポートに対応する特定のバージョンを要求することができる。特定のバージョンはサーバによって配信され得る。
【0022】
360映像および/または他の非従来型の映像フォーマット(たとえば、パノラマ映像リプレゼンテーションで使用され得る円柱映像)を表現するために使用され得る様々な投影法を記述するために、ISO/IEC/MPEGは、全方向性メディアアプリケーションフォーマット(OMAF)を定義することができる。本明細書に説明されている投影法のためのOMAFファイルフォーマットメタデータは、球、キューブ、円柱、および/または角錐上などへの映像に関する投影メタデータのサポートを含むことができる。表1は、つぶされた球、円柱、および角錐などの投影法をサポートするためのOMAFの構文例を示し得る。
【0023】
【表1】
【0024】
HTTPストリーミングは商用展開では支配的な手法になっている。たとえば、AppleのHTTP Live Streaming(HLS)、MicrosoftのSmooth Streaming(SS)、および/またはAdobeのHTTP Dynamic Streaming(HDS)などのストリーミングプラットフォームは、基礎となる配信方法としてHTTPストリーミングを使用することができる。マルチメディアコンテンツのHTTPストリーミングの標準は、標準ベースのクライアントが任意の標準ベースのサーバからコンテンツをストリーミングすることを可能にし得る(たとえば、それにより、異なるベンダのサーバとクライアントとの間の相互運用を可能にする)。MPEGダイナミックアダプティブストリーミングオーバーHTTP(MPEG-DASH)は、変化するネットワーク条件に動的に適応することによって、可能な最良の映像体験をエンドユーザに提供する汎用配信フォーマットであり得る。DASHは、HTTP/TCP/IPスタックの上に構築され得る。DASHは、マニフェストフォーマット、メディアプレゼンテーション記述(MPD)、ならびにISOベースメディアファイルフォーマットおよびMPEG-2トランスポートストリーム用のセグメントフォーマットを定義することができる。
【0025】
ダイナミックHTTPストリーミングは、サーバで利用可能になるマルチメディアコンテンツの様々なビットレート選択肢に関連付けられ得る。マルチメディアコンテンツは、いくつかのメディアコンポーネント(たとえばオーディオ、映像、テキスト)を含むことができ、それらの各々は異なる特徴を有し得る。MPEG-DASHでは、特徴はメディアプレゼンテーション記述(MPD)によって記述され得る。
【0026】
MPDは、ストリーミングセッション中にアダプティブ様式でDASHクライアントが(たとえば、本明細書に説明されているように)映像セグメントにアクセスするために適切なHTTP-URLを構築するために必要なメタデータを含むXMLドキュメントであり得る。図4は、例示的なメディアプレゼンテーション記述(MPD)階層データモデルを示す。MPDはPeriodのシーケンスを記述することができ、Period中に、メディアコンテンツコンポーネントのエンコードされたバージョンの一貫したセットは変化しない。Periodは、開始時間および持続時間を有することができる。Periodは、1つまたは複数のアダプテーションセット(たとえばAdaptationSet)から構成され得る。
【0027】
AdaptationSetは、1つまたは複数の同一のプロパティ(たとえば、言語、メディアタイプ、ピクチャアスペクト比、ロール(role)、アクセシビリティ、視点、および/または評価プロパティなど)を共有する1つまたはいくつかのメディアコンテンツコンポーネントのエンコードされたバージョンのセットを表現することができる。たとえば、第1のAdaptationSetは、同じマルチメディアコンテンツの映像コンポーネントの異なるビットレートを含むことができる。第2のAdaptationSetは、同じマルチメディアコンテンツのオーディオコンポーネント(たとえば、より低品質のステレオおよび/またはより高品質のサラウンドサウンド)の異なるビットレートを含むことができる。AdaptationSetは、複数のRepresentationを含むことができる。
【0028】
Representationは、ビットレート、解像度、チャネルの数、および/または他の特徴によって他のリプレゼンテーションと異なる、1つまたはいくつかのメディアコンポーネントの配信可能なエンコードされたバージョンを記述することができる。Representationは、1つまたは複数のセグメントを含むことができる。Representation要素の1つまたは複数の属性(たとえば、@id、@bandwidth、@quality Ranking、および@dependencyIdなど)が、関連付けられたRepresentationの1つまたは複数のプロパティを指定するために使用され得る。
【0029】
Segmentは、単一のHTTP要求で取り出されることができるデータの最大のユニットであり得る。セグメントは、URL(たとえば、サーバ上のアドレス可能な場所)を有することができる。セグメントは、HTTP GETまたはバイト範囲を有するHTTP GETを使用してダウンロードされ得る。
【0030】
DASHクライアントは、MPD XMLドキュメントをパースすることができる。DASHクライアントは、たとえばAdaptationSet要素内に提供された情報に基づいて、その環境に適切なAdaptationSetの集合を選択することができる。AdaptationSet内で、クライアントはRepresentationを選択することができる。クライアントは、@bandwidth属性の値、クライアント復号能力、および/またはクライアントレンダリング能力に基づいて、Representationを選択することができる。クライアントは、選択されたRepresentationの初期化セグメントをダウンロードすることができる。クライアントは、(たとえば、Segment全体またはSegmentのバイト範囲を要求することによって)コンテンツにアクセスすることができる。プレゼンテーションが開始したとき、クライアントはメディアコンテンツの消費を続けることができる。たとえば、クライアントは、プレゼンテーション中にMedia Segmentおよび/またはMedia Segmentの一部を要求する(たとえば継続的に要求する)ことができる。クライアントは、メディアプレゼンテーションタイムラインに従ってコンテンツを再生することができる。クライアントは、クライアントの環境からの更新された情報に基づいて、第1のRepresentationから第2のリプレゼンテーションに切り替えることができる。クライアントは、2つ以上のPeriodにわたって継続してコンテンツを再生することができる。クライアントがRepresentationにおける公表されたメディアの終端に向かってSegmentに含まれるメディアを消費しているとき、Media Presentationが終了されることができ、Periodが開始されることができ、および/またはMPDが再フィッチされることができる。
【0031】
MPD記述子要素、Descriptorが、(たとえば、適切なスキーム情報を有する1つまたは複数の記述要素をインスタンス化するために)アプリケーションに提供され得る。1つまたは複数のDescriptor(たとえば、コンテンツ保護、ロール、アクセシビリティ、評価、視点、フレームパッキング、および/またはUTCタイミング記述子など)は、相対スキームを識別するための@スキームIdUri属性を含むことができる。
【0032】
補足プロパティ記述子(SupplementalProperty)は、処理を最適化するためにDASHクライアントによって使用され得るメタデータを含むことができる。
【0033】
本質的プロパティ記述子(EssentialProperty)は、含む要素を処理するためのメタデータを含むことができる。
【0034】
Role MPD要素は、@schemeIdUri属性を使用して、メディアコンテンツコンポーネントのロールを識別するために利用されるロールスキームを識別することができる。1つまたは複数のRoleは、メディアコンテンツコンポーネントの1つまたは複数の特徴および/または構造的機能を定義および/または記述することができる。Adaptation Setおよび/またはメディアコンテンツコンポーネントは、(たとえば、同じスキーム内であっても)複数の指定されたロールを有することができる。
【0035】
MPEG-DASHは、空間関係記述(SRD)スキームを提供することができる。SRDスキームは、2つのMPD要素(たとえば、AdaptationSetおよびSubRepresentation)において別のフルフレーム映像の空間部分を表現する映像の空間関係を表すことができる。@schemeIdURIが「urn:mpeg:dash:srd:2014」に等しいSupplementalPropertyおよび/またはEssentialProperty記述子が、AdaptationSetおよび/またはSubRepresentationに関連付けられた空間関係情報を提供するために使用され得る。SupplementalPropertyおよび/またはEssentialProperty要素の属性@valueは、source_id、object_x、object_y、object_width、object_height、total_width、total_height、および/またはspatial_set_idのようなSRDパラメータに対する1つまたは複数の値を提供することができる。SRDパラメータの値およびセマンティクスは、表2に示されるように定義され得る。
【0036】
【表2-1】
【0037】
【表2-2】
【0038】
図5は、例示的なDASH SRD映像を示す。SRDは、映像ストリームがフルフレーム映像の空間部分を表現することを表すことができる。空間部分は、フルフレーム映像のタイルおよび/または関心領域(ROI)であり得る。SRDは、フルフレーム映像(total_width、total_height)に対する空間部分の位置(object_x、object_y)および/またはサイズ(object_width、object_height)に関して映像ストリームを記述することができる。SRD記述は、アダプテーションに関してクライアントのための柔軟性を提供することができる。SRD認識DASHクライアントは、1つまたは複数のSRDアノテーションを使用して、フルフレームリプレゼンテーションおよび/またはフルフレームリプレゼンテーションの空間部分を選択することができる。1つまたは複数のSRDを使用してフルフレームリプレゼンテーションまたは空間部分を選択することにより、帯域幅および/またはクライアント側計算を節約することができ、たとえば、フルフレームフェッチ、復号、および/またはクロッピングを回避することができる。1つまたは複数のSRDアノテーションを使用してどのリプレゼンテーションを選択するかを決定することにより、たとえばズーム後の、フルフレーム映像の所与の空間部分(たとえば、関心領域すなわちROI)の品質を増大させることができる。たとえば、クライアントは、より高品質を有するROI空間部分に対応する第1の映像ストリームを要求することができ、クライアントは、より低い品質を有するROIに対応しない第2の映像ストリームを要求することができ、全体的ビットレートを増大させることがない。
【0039】
表3は、図5に示されるようなシナリオに関してSRDをサポートするMPD例であり、ここでは、各タイルが1920×1080の解像度を有し、フレーム全体では9個のタイルを有する5760×3240の解像度を有する。
【0040】
【表3-1】
【0041】
【表3-2】
【0042】
【表3-3】
【0043】
図6は、例示的なタイルベースの映像分割を示す。2Dフレームは、図6に示されるように1つまたは複数のタイルへ分割され得る。MPEG-DASH SRDサポートが与えられたとすると、タイルベースのアダプティブストリーミング(tile based adaptive streaming:TAS)が、大きなパノラマでのズーミングおよびパンニング、空間解像度エンハンスメント、ならびに/またはサーバベースのモザイクサービスのような機能をサポートするために使用され得る。SRD認識DASHクライアントは、1つまたは複数のSRDアノテーションを使用してフルフレームリプレゼンテーションまたはタイルリプレゼンテーションを選択することができる。1つまたは複数のSRDアノテーションを使用してタイルリプレゼンテーションのフルフレームリプレゼンテーションを選択するかどうかを決定することにより、帯域幅および/またはクライアント側計算を節約することができる(たとえば、フルフレームフェッチ、復号、および/またはクロッピングを回避する)。
【0044】
図7は、例示的な時間的動きが制約されたタイルセットを示す。フレームは、HEVCで指定されるいくつかの時間的動きが制約されたタイルセットを含むビットストリームにエンコードされ得る。時間的動きが制約されたタイルセットの各々は、独立して復号され得る。図7に示されるように、2つ以上の左タイルが、(たとえば、ピクチャ全体を復号することなく)独立して復号されることが可能な動きが制約されたタイルセットを形成することができる。
【0045】
360°映像コンテンツは、主にHTTPベースのストリーミングソリューションであるプログレッシブダウンロードまたはDASHアダプティブストリーミングを介して配信され得る。HTTPの代わりにUDPに基づく360°映像用のダイナミックストリーミングが、レイテンシを低減させるために(たとえば、Facebookによって)提案されている。
【0046】
十分な品質を有する360映像を表現するために、2D投影が高い解像度を有することを必要とし得る。フル2Dレイアウトが高品質で符号化されると、結果の帯域幅が効果的な配信ためには大き過ぎることがある。いくつかのマッピングおよび/または投影を使用して、360映像の異なる部分が異なる品質で表現されることを可能にすることによって、データの量を減らすことができる。たとえば、フロントビュー(たとえばビューポート)が高品質で表現されてよくバック(たとえば反対の)ビューが低品質で表現されてよい。1つまたは複数の他のビューが1つまたは複数の他の中間品質で表現されてよい。図3に示されているオフセットされたキューブマップおよび角錐マップは、異なる品質で360映像の異なる部分を表現するマッピングおよび/または投影の例であり得る。角錐マップはピクセルの数を低減させ、および/または各ビューポートについてのビットレートを節約することができるが、複数のビューポートバージョンが、クライアントが要求し得る異なる見る位置を扱うことができる。360映像全体を配信するのと比べると、ビューポート特有のリプレゼンテーションおよび/または配信は、ユーザが見る位置を変更するときに適応するより大きなレイテンシを有する可能性がある。たとえば、オフセットされたキューブマップを使用すると、ユーザの頭分位置が180度回転するときに映像品質が低下することがある。
【0047】
図8は、例示的な360映像ストリーミング品質低下を示す。DASHセグメント長および/またはクライアントバッファサイズが表示品質に影響し得る。より長いセグメント長は、より高い符号化効率をもたらすことができる。より長いセグメント長は、ビューポート変化に迅速に適応できないことがある。図8に示されるように、ユーザは、360映像の3つのあり得るビューポート(たとえば、A、BおよびC)を有することができる。1つまたは複数(たとえば3つ)のセグメントタイプ、すなわちSA、SBおよびSCが、360映像に関連付けられ得る。1つまたは複数のセグメントタイプの各々が、より高品質の対応するビューポート、およびより低品質の他のビューポートを受け持つことができる。ユーザは、ビューポートA用のより高品質の映像およびビューポートBおよびC用のより低品質の映像を受け持つセグメントSAの再生中に、時間t1でビューポートAからビューポートBにパンニングすることができる。ユーザは、ビューポートB用のより高品質の映像およびビューポートAおよびC用のより低品質の映像を受け持つ次のセグメント(SB)に切り替わる前に、より低品質のビューポートBを注視しなければならない可能性がある。そのような負のユーザ体験は、より短いセグメント長で解決され得る。より短いセグメント長は符号化効率を低減させ得る。ユーザのストリーミングクライアントロジックが以前のビューポートに基づいて多すぎるセグメントを予めダウンロードするときに、ユーザは、より低品質の映像を注視しなければならない可能性がある。ユーザのストリーミングクライアントが以前のビューポートに基づいて多すぎるセグメントを予めダウンロードすることを防止するために、ストリーミングバッファサイズが低減されることができる。より小さいストリーミングバッファサイズは、たとえば、より頻繁にバッファアンダーフローを引き起こすことによって、ストリーミング品質適応に影響する可能性がある。
【0048】
ビューポート適応360°映像ストリーミングは、ビューポートエンハンスメントベースの配信および/またはレイヤベースの配信を含むことができる。
【0049】
効率的な360映像ストリーミングは、ビットレート適応およびビューポート適応の両方を考慮することができる。ビューポートエンハンスメントベースの360°映像配信は、高品質で360映像フレームの1つまたは複数の識別されたビューポートをエンコードすることを含むことができる。たとえば、ビューポートベースのビット割り当てがエンコード中に行われ得る。ビューポートベースのビット割り当ては、ビットのより大きな部分を1つまたは複数のビューポートに割り当て、および/またはそれに応じて低減された量のビットを他のエリアに割り当てることができる。図9は、関連付けられた隣接エリアを有する例示的なビューポートエリアを示す。ビューポートエリア、隣接エリア、および他のエリアが、360°映像フレームに対して決定され得る。
【0050】
ビューポートエリアに対するビットレート重みがαとして定義され得る。隣接エリアに対するビットレート重みがβとして定義され得る。他のエリアに対するビットレート重みがγとして定義され得る。以下の方程式のうちの1つまたは複数が、各エリアについてのターゲットビットレートを決定するために使用され得る。
α+β+γ=1 (3)
BRHQ=R×α (4)
BRMQ=R×β (5)
BRLQ=R×γ (6)
式中、Rは、360°映像全体についての一定の符号化ビットレートを表現することができ、BRHQは、ターゲットビューポートエリアについての符号化ビットレートを表現することができ、BRMQは、ビューポート隣接エリアについての符号化ビットレートを表現することができ、および/またはBRLQは、他のエリアについての符号化ビットレートを表現することができる。
【0051】
方程式(3)において、α、β、およびγの値は合計で1になることができ、これは、全体的ビットレートが同じに維持されることを意味することができる。たとえば、ビットは、異なるエリア(たとえば、ビューポート、隣接エリア、および他のエリア)の間で再分配されるだけであり得る。Rの全体的ビットレートにおいて、同じ映像が異なるバージョンにエンコードされ得る。異なるバージョンの各々は、異なるビューポート品質レベルに関連付けられ得る。異なるビューポート品質レベルの各々は、異なる値のαに対応することができる。
【0052】
全体的ビットレートRは、同じに維持されないことがある。たとえば、ビューポートエリア、隣接エリア、および他のエリアは、ターゲット品質レベルにエンコードされ得る。この場合、エリアの各々についてのリプレゼンテーションビットレートは異なり得る。
【0053】
本明細書に説明されている投影法(たとえば、オフセットされたキューブマップ、角錐マップなど)は、1つもしくは複数のターゲットビューポートの品質をエンハンスメントし、および/または映像の他のエリアの品質を低減させることができる。
【0054】
サーバ側において、AdaptationSetは、複数のRepresentation要素を含むことができる。360映像ストリームのRepresentationは、特定の解像度および/または特定のビットレートに符号化され得る。Representationは、1つまたは複数の特定の品質がエンハンスメントされたビューポートに関連付けられ得る。ビューポート関係記述(Viewport Relationship Description:VRD)は、1つまたは複数の対応するビューポート空間座標関係を指定することができる。@schemeIdUriが「urn:mpeg:dash:viewport:2d:2016」に等しいSupplementalPropertyおよび/またはEssentialProperty記述子が、AdaptationSet、Representation、および/またはSub-Representation要素に関連付けられたVRDを提供するために使用され得る。
【0055】
VRDスキームを使用するSupplementalPropertyおよび/またはEssentialProperty要素の@valueは、ビューポート記述パラメータの値のコンマ区切りリストであり得る。各AdaptationSet、Representation、および/またはSub-Representationは、1つまたは複数のエンハンスメントされたビューポートを表現するための1つまたは複数のVRDを含むことができる。エンハンスメントされたビューポートのプロパティは、表4に示されるようにVRDパラメータによって記述され得る。
【0056】
【表4】
【0057】
表5は、4K 360映像のMPD例を提供する。AdaptationSetは、VRDスキーム識別子「urn:mpeg:dash:viewport:2d:2016」を有する2つのSupplementalProperty記述子によって注釈され得る。第1の記述子は、品質レベル3を有する(150,150)におけるエンハンスメントされた320×640ビューポート#1を指定することができる。第2の記述子は、品質レベル5を有する(1000,1000)におけるエンハンスメントされた640×960ビューポート#2を指定することができる。両方のビューポートは、4096×2048フルフレーム360°映像の空間部分を表現することができる。2つのRepresentationが存在してよく、第1のRepresentationはフル解像度であってよく、第2のRepresentationはハーフ解像度であってよい。Representationのビューポート位置および/またはサイズは、VRD属性@full_widthおよび/もしくは@full_heightの値、ならびに/またはRepresentation属性@widthおよび/または@heightの値に基づいて識別され得る。たとえば、フル解像度Representation(たとえば、@width=4096および@height=2048)でのビューポート#1は、サイズ320×640で(150,150)にあり得る一方、ハーフ解像度Representation(たとえば、@width=2048および@height=1024)でのビューポート#1は、サイズ160×320で(75,75)にあり得る。ユーザのWTRUの1つまたは複数の能力に応じて、ハーフ解像度はフル解像度に拡張されてよい。
【0058】
【表5】
【0059】
投影(たとえば、正距円筒図法、キューブマップ、円柱、および角錐)が、球映像の表面を処理のためにフラット画像にマッピングするために使用され得る。1つまたは複数のレイアウトが特定の投影のために利用可能であり得る。たとえば、正距円筒図法および/またはキューブマップ投影フォーマットに対して、異なるレイアウトが使用され得る。図10A図10Dは、例示的なキューブマップレイアウトを示す。キューブマップレイアウトは、キューブレイアウト、2×3レイアウト、側部の極レイアウト、および/または単列レイアウトを含むことができる。
【0060】
表4のVRDは、特定の投影フォーマット、たとえば、正距円筒図法投影に対して指定され得る。表4のVRDは、特定の投影とレイアウトの組み合わせ、たとえば、キューブマップ投影および2×3レイアウト(たとえば、図10Bに示されるレイアウトB)に対して指定され得る。表4のVRDは、表6に示されるように、同時に様々な投影フォーマットならびに/または投影およびレイアウトの組み合わせフォーマットをサポートするように拡張され得る。サーバは、たとえば表6に示されるシグナリングシンタックスを使用して、一般的な投影ならびに/または投影およびレイアウトフォーマットのセットをサポートすることができる。図11は、正距円筒図法およびキューブマップにおける例示的なビューポート座標を示す。360映像の1つまたは複数(たとえば2つ)のビューポートが識別され得る。図示されるように、ビューポートの座標値は、正距円筒図法投影フォーマットとキューブマップ投影フォーマットとで異なり得る。
【0061】
VRDは、Representation要素に関連付けられた1つまたは複数のビューポートを指定することができる。表7は、正距円筒図法RepresentationとキューブマップRepresentationの両方が提供され、対応するVRDがしかるべくシグナリングされる、MPD例を示す。1つまたは複数の第1のVRD(たとえば、VRD@viewport_id=0,1)が、正距円筒図法投影フォーマットにおける1つまたは複数の第1のRepresentation(たとえば、Representation@id=0,1)でのビューポートの1つまたは複数のプロパティを指定することができる。1つまたは複数の第2のVRD(たとえば、VRD@viewport_id=2,3)が、キューブマップ投影フォーマットにおける1つまたは複数の第2のRepresentation(たとえば、Representation@id=2,3)でのビューポートの1つまたは複数のプロパティを指定することができる。
【0062】
VRDは、(たとえば、関連付けられたRepresentationが1つの投影/レイアウトフォーマットであっても)1つまたは複数の(たとえばすべての)共通投影/レイアウトフォーマットにおける1つまたは複数のビューポート座標を指定することができる。表8は、正距円筒図法投影のRepresentationが提供され、正距円筒図法とキューブマップの両方の対応するビューポートのVRDが提供される、MPD例を示す。たとえば、投影およびレイアウトフォーマットは、本明細書に説明されているようにRepresentationレベルでシグナリングされ得る。
【0063】
サーバは、異なるフォーマットでビューポートを指定することができ、および/または(たとえば、クライアントの能力および/または技術仕様に応じて)適切なビューポートを選ぶための柔軟性をクライアントに与えることができる。クライアントが(たとえば、表4において指定された方法または表において指定された方法のセットから)好ましいフォーマットを見つけることができない場合、クライアントは、1つまたは複数のビューポートを、指定されたフォーマットのうちの1つからクライアントが使用したいフォーマットに変換することができる。たとえば、1つまたは複数のビューポートは、キューブマップフォーマットに指定され得るが、クライアントは正距円筒図法フォーマットを使用したい。MPDで利用可能な投影および/またはレイアウト記述に基づいて、クライアントは、そのジャイロスコープ、加速度計、および/または磁気計追跡情報からユーザ方位位置を導き出すことができる。クライアントは、方位位置を特定の投影レイアウト上の対応する2D位置に変換することができる。クライアントは、@viewport_x、@viewport_y、@viewport_width、および/または@viewport_heightなどの1つまたは複数のVRDパラメータの値に基づいて、識別されたビューポートを有するRepresentationを要求することができる。
【0064】
【表6】
【0065】
【表7-1】
【0066】
【表7-2】
【0067】
【表8-1】
【0068】
【表8-2】
【0069】
一般的ビューポート記述子が、表9に示されるように提供され得る。一般的ビューポート記述子は、図2に示されているように球面座標(θ,φ)を使用してビューポート位置を記述することができ、ここで、θは傾斜角または極角を表現することができ、φは方位角を表現することができ、および/または正規化半径は1であり得る。
【0070】
@schemeIdUriが「urn:mpeg:dash:viewport:sphere:2016」に等しいSupplementalPropertyおよび/またはEssentialProperty記述子が、AdaptationSet、Representation、および/またはSub-Representation要素に関連付けられた球面座標ベースのVRDを提供するために使用され得る。球面座標で指定された領域は、投影後の2D平面上の矩形領域に対応しないことがある。領域が投影後の2D平面上の矩形領域に対応しない場合、シグナリングされた領域の境界矩形が、ビューポートを指定するために導き出されおよび/または使用され得る。
【0071】
VRDを使用するSupplementalPropertyおよび/またはEssentialProperty要素の@valueは、1つまたは複数のビューポート記述パラメータの値のコンマ区切りリストであり得る。各AdaptationSet、Representation、および/またはSub-Representationは、1つまたは複数のエンハンスメントされたビューポートを表現するための1つまたはいくつかのVRDを含むことができる。エンハンスメントされたビューポートのプロパティは、表9に示されるようにパラメータによって記述され得る。
【0072】
【表9】
【0073】
図12は、例示的な球面座標ビューポートを示す。(たとえば、図12ではVとして示される)ビューポートに関して、viewport_incは極角θを指定することができ、viewport_azは方位角(φ)を指定することができ、viewport_delta_incはdθを指定することができ、および/またはviewport_delta_azはdφを指定することができる。
【0074】
2D座標を使用するVRD(たとえば、表4または表6)と球面座標を使用するVRD(たとえば表9)とを区別するために、それぞれの場合において異なる@schemeIdUri値が使用され得る。たとえば、2Dビューポート記述子に関して、@schemeIdUri値はurn:mpeg:dash:viewport:2d:2016であり得る。球面座標に基づくビューポートに関して、@schemeIdUri値は「urn:mpeg:dash:viewport:sphere:2016」であり得る。
【0075】
球面座標に基づくビューポート記述子を使用すると、ビューポートは1つの座標系(たとえば球面座標系)のみに対して指定され得るので、シグナリングコストを低減させることができる。球面座標に基づくビューポート記述子を使用すると、各クライアントが予め定義された変換プロセスを実装するだけでよいので、クライアント側で単純化された変換プロセスを得ることができる。たとえば、各クライアントは、クライアントが使用するために選ぶ投影フォーマット(たとえば正距円筒図法)と球リプレゼンテーションとの間の変換をすることができる。クライアントがビューポート座標をアライメントするとき、クライアントは同様のロジックを使用して、どのリプレゼンテーションを要求するかを決めることができる。
【0076】
VRDは、1つまたは複数のPeriodSupplementalProperty要素でシグナリングされ得る。VRDは、利用可能な(たとえば、すべての利用可能な)エンハンスメントされたビューポートをそれぞれリストすることができる。Representationは、属性@viewportIdを使用して、現在のRepresentationまたはSub-Representationにどのエンハンスメントされたビューポートが関連付けられているかを識別するために1つまたは複数のビューポートインデックスをシグナリングすることができる。そのような記述子参照手法を用いて、Representation内のVRDの冗長なシグナリングが回避され得る。異なる関連付けられたビューポート、投影フォーマット、および/またはレイアウトフォーマットを有する1つまたは複数のRepresentationが、単一のAdaptationSet内に割り当てられ得る。表10は、Representation要素属性@viewportIdおよび@viewport_qualityの例示的なセマンティクスを示す。
【0077】
表10に示されるように、属性@viewport_qualityは、VRDの一部として(たとえば、Periodレベルの代わりに)Representationレベルでシグナリングされ得る。@viewport_quality属性は、クライアントが関心のある1つまたは複数のビューポートについての適切な品質レベルを選択することを可能にする。たとえば、ユーザが頻繁に360ビューをナビゲートしている(たとえば、常に頭部の向きを変えて見回している)場合、クライアントは、ビューポートと非ビューポートとの間でバランスのとれた品質を有するRepresentationを選択することができる。ユーザがビューポートに注目している場合、クライアントは、高いビューポート品質(しかし、たとえば非ビューポートエリアでは比較的低減された品質)を有するRepresentationを選択することができる。@viewport_quality属性はRepresentationレベルでシグナリングされ得る。
【0078】
【表10】
【0079】
表11は、関連付けられたビューポートを指定するために表10に示されたRepresentation属性である@viewportIdおよび@viewport_qualityを使用するMPD例である。2つのVRDがPeriod.SupplementalPropertyにおいて指定され得る。第1のRepresentation(たとえば@id=0)は、1つまたは複数のビューポート(たとえば@viewportId=0)を含むことができ、ビューポート#0品質レベルは2であり得る。第2のRepresentation(たとえば@id=1)は、第1のRepresentation(たとえば@viewportId=0)と同じ1つまたは複数のビューポートを含むことができるが、ビューポート#0の品質レベルは4であり得る。第3のRepresentation(たとえば@id=2)は、品質レベル5を有する1つまたは複数のエンハンスメントされたビューポート(たとえば@viewportId=1)を含むことができる。第4のRepresentation(たとえば@id=3)は、最高品質レベル(たとえば、@viewport_quality=5,5)を有する1つまたは複数のエンハンスメントされたビューポート(たとえば@viewportId=0,1)を含むことができる。
【0080】
【表11-1】
【0081】
【表11-2】
【0082】
エンハンスメントされたビューポートエリアは、実際の表示解像度よりも大きくなるように選択されることができ、それにより、ユーザがビューポートを変更する(たとえば、わずかに変更する)ときの品質低下を軽減することができる。エンハンスメントされたビューポートエリアは、セグメントピリオド中に関心のあるターゲットオブジェクトが動き回るエリアをカバーするように(たとえば、同じ高品質でターゲットが動き回るときにユーザがターゲットオブジェクトを注視できるように)選択され得る。たとえば、オリジンサーバまたはCDNにおけるRepresentationおよび/または対応するメディアストリームの総数を減少させるために、1つまたは複数の最も注視されているビューポートが単一のビットストリームにおいてエンハンスメントされ得る。表4、表6、表9、および/または表10において指定されたビューポート記述子は、単一ビットストリーム内の複数の品質がエンハンスメントされたビューポートをサポートすることができる。
【0083】
図13は、例示的なビューポートエンハンスメントリプレゼンテーションを示す。360°映像は、2つの識別された最も見られているビューポート(たとえば、ビューポート#1およびビューポート#2)を有することができる。1つまたは複数のDASH Representationは、2つの識別された最も見られているビューポートに対応することができる。高い符号化ビットレート(たとえば20mbps)で、両方のビューポートが高品質でエンハンスメントされ得る。両方のビューポートが高品質にエンハンスメントされると、(たとえば、高速ビューポート変更を容易にするため、および/または格納コストを節約するために)1つのRepresentationに両方のエンハンスメントされたビューポートが提供され得る。中位ビットレートでは、3つのRepresentationに両方のビューポートまたは個別のビューポートにおける品質エンハンスメントが提供され得る。クライアントは、高速ビューポート変更および/またはビューポートのいずれかの高品質に対する選好に基づいて、異なるリプレゼンテーションを要求することができる。より低いビットレートでは、クライアントが視方向に基づいて適切なビューポート品質を要求できるように、2つのRepresentationに各ビューポートのエンハンスメントが個別に提供され得る。Representation選択は、低レイテンシビューポート切り替え、より低い格納コスト、および/または適切な表示品質の間の異なるトレードオフを可能にし得る。
【0084】
アダプティブ360°映像ストリーミングセッション中に、クライアントは、利用可能な帯域幅、ユーザが注視しているビューポート、および/または視方向変更(たとえば、ビューポートが変わる速さおよび/または頻度)に基づいて、特定のリプレゼンテーションを要求することができる。クライアントWTRUは、どのRepresentationを要求するかを決定するために、1つまたは複数のジャイロスコープ、加速度計、および/または磁気計追跡パラメータを使用して1つまたは複数のユーザ習慣を局所的に分析することができる。たとえば、クライアントWTRUは、ユーザが視方向を頻繁に変更していないおよび/またはしないことを検出した場合、単体のエンハンスメントされたビューポートを有するRepresentationを要求することができる。低レイテンシレンダリングおよび/または十分なビューポート品質を保証するために、クライアントWTRUは、ユーザが視方向を変更し続けるおよび/または変更する傾向があること検出した場合、複数のエンハンスメントされたビューポートを有するRepresentationを要求することができる。
【0085】
レイヤベースの360映像配信は、360°映像ストリーミングのためのビューポート適応手法であり得る。レイヤベースの360映像配信は、フレーム全体からビューポートエリアを分離することができる。レイヤベースの360映像配信は、様々な仮想および/または現実のオブジェクトの球上へのより柔軟および/または効率的な合成を可能にすることができる。
【0086】
フレーム全体が、より低い品質、より低いフレームレート、および/またはより低い解像度でフルフレーム映像レイヤとしてエンコードされ得る。1つまたは複数のビューポートが、ビューポートレイヤとして1つまたは複数の品質Representationにエンコードされ得る。ビューポートレイヤは、フルフレーム映像レイヤから独立して符号化され得る。ビューポートレイヤは、スケーラブル符号化を使用して、たとえばHEVC(SHVC)のスケーラブル拡張を使用して、より効率的にコーディングされることが可能であり、ここで、フルフレーム映像レイヤは、レイヤ間予測を用いて1つまたは複数のビューポートレイヤリプレゼンテーションを符号化するために参照レイヤとして使用される。ユーザは常に、フルフレーム映像レイヤを(たとえば、フォールバックレイヤとして)要求することができる。ユーザWTRUが十分な追加のリソース(たとえば、帯域幅および/またはコンピューティングリソース)を有するとき、1つまたは複数の高品質エンハンスメントビューポートがフルフレーム映像レイヤ上に重なるように要求され得る。
【0087】
ビューポートの外部のピクセルがサブサンプリングされ得る。ビューポートの外部のエリアのフレームレートは直接低減されないことがある。レイヤベースの360映像配信は、360°映像フレーム全体からビューポートを分離することができる。360映像配信は、より高いビットレート、より高い解像度、および/またはより高いフレームレートでビューポートが符号化されることを可能にし得る一方で、フルフレーム映像レイヤ360°映像は、より低いビットレート、より低い解像度、および/またはより低いフレームレートで符号化され得る。
【0088】
フルフレーム映像レイヤは、より低い解像度で符号化され、クライアント側でオーバーレイについてアップサンプリングされ得る。クライアント側でフルフレーム映像レイヤをアップサンプリングすることは、格納コストを削減し、および/またはより低いビットレートで許容可能な品質を提供することができる。ビューポートレイヤに関して、ビューポートの複数の品質Representationが細かい粒度の品質適応のために生成され得る。
【0089】
図14は、例示的なレイヤベースの360映像オーバーレイを示す。たとえば、高品質ビューポートが、360フルフレーム映像レイヤ上にオーバーレイされ得る。フルフレーム映像レイヤストリームは、より低い品質で360°映像全体を含むことができる。エンハンスメントレイヤストリームは、高い品質でエンハンスメントされたビューポートを含むことができる。
【0090】
1つまたは複数の指向性ローパスフィルタが、突然の品質変化を滑らかにするためにオーバーレイ境界(たとえば、水平および/または垂直の境界)を横切って適用され得る。たとえば、垂直境界に沿って1つまたは複数の水平隣接ピクセルを滑らかにするために、1Dまたは2Dローパスフィルタが垂直境界上に適用されてよく、および/または水平境界に沿って1つまたは複数の垂直隣接ピクセルを滑らかにするために、同様のローパスフィルタが水平境界上に適用されてよい。
【0091】
フルフレーム映像レイヤは、正距円筒図法、キューブマップ、オフセットされたキューブマップ、角錐などの異なる投影フォーマットで360°映像全体を含むことができる。投影フォーマットは、解像度、ビットレート、および/またはフレームレートなどの異なる品質レベルをサポートする複数のフルフレーム映像レイヤRepresentationを有することができる。
【0092】
ビューポートレイヤは、複数のビューポートを含むことができる。ビューポートは、アダプティブストリーミングのための異なる解像度、ビットレート、および/またはフレームレートを有するいくつかの品質Representationを有することができる。複数のRepresentationは、(たとえば、各ビューポートのサイズは360°映像全体のサイズと比べて比較的小さいので、)高いストレージおよび/または送信コストを負担することなく、細かい粒度の品質適応をサポートするために提供され得る。
【0093】
図15は、例示的なレイヤベースの360映像リプレゼンテーションを示す。たとえば、2つ以上のRepresentationが、異なる解像度(2048×1024@30fpsおよび4096x×2048@30fps)を有する360°映像全体のためにフルフレーム映像レイヤで利用可能であり得る。2つ以上のターゲットビューポート(たとえばビューポート#1およびビューポート#2)が、ビューポートレイヤで利用可能であり得る。ビューポート#1および#2は、異なる解像度および/または異なるビットレートを有するRepresentationを有することができる。ビューポートレイヤRepresentationは、@dependencyIdを使用して、依存Representationとして特定のフルフレーム映像レイヤRepresentationを識別することができる。ユーザは、レンダリングのための最終的360°映像を合成するために、ターゲットビューポートRepresentationおよび/またはその依存フルフレーム映像レイヤフルフレームRepresentationを要求することができる。
【0094】
MPEG-DASH SRD要素は、レイヤベースの360映像ストリーミングをサポートするために使用され得る。アプリケーションに応じて、MPD作成者は、フルフレーム映像レイヤ360°フル映像とビューポートレイヤ映像との間の空間的関係を記述するために1つまたは複数のSRD値を使用することができる。SRD要素は、空間オブジェクトの空間関係を指定することができる。SRD要素は、1つまたは複数のビューポート映像をフルフレーム映像レイヤ上にどのようにオーバーレイするかを指定できないことがある。ビューポートオーバーレイは、レイヤベースの360°映像ストリーミングのストリーミング品質を改善するために指定され得る。
【0095】
視点(viewpoint)オーバーレイが、AdaptationSet要素に適用されるRole記述子と共に使用され得る。@schemeIdURIが「urn:mpeg:dash:viewport:overlay:2016」に等しいRole要素は、どのRepresentationがビューポートレイヤ映像に関連付けられているか、および/またはどのRepresentationがフルフレーム映像レイヤに関連付けられているかをシグナリングすることができる。Role要素の@valueは、1つまたは複数のオーバーレイインジケータを含むことができる。たとえば、1つまたは複数のオーバーレイインジケータは、「f」および/または「v」を含むことができ、ここで、「f」は、関連付けられた映像Representationがフルフレーム映像レイヤであることを示し、「v」は、関連付けられた映像Representationがフルフレーム映像レイヤ上にオーバーレイされることになるビューポート映像であることを示す。1つまたは複数のビューポート映像は、フルフレーム映像レイヤ上にオーバーレイされ得る。@dependencyIdは、関連付けられたビューポート映像オーバーレイ合成のために特定のフルフレーム映像レイヤRepresentationを指定することができる。元のフルフレーム映像レイヤ解像度は、1つまたは複数のSRDパラメータ(たとえば、関連付けられたAdaptationSetのtotal_widthおよびtotal_height)によって示され得る。ビューポートの元の解像度は、1つまたは複数のSRDパラメータ、関連付けられたAdaptationSetのobject_widthおよびobject_heightによって示され得る。@widthおよび@heightによって示されたRepresentationの解像度が、SRDによって指定された対応する解像度よりも低いとき、再構築された映像が、オーバーレイのためにフルフレーム映像レイヤおよびエンハンスメントレイヤ映像をアライメントするためにアップサンプリングされ得る。表12は、図15に示されるレイヤベースの360°映像Representation例のための例示的なMPD SRDアノテーションである。
【0096】
表12では、@idで識別された2つ以上のフルフレームリプレゼンテーションが、同じAdaptationSetに含まれ得る。第1のRepresentation(@id=2)はフル解像度4096×2048を含むことができ、第2のRepresentation(@id=1)はハーフ解像度を含むことができる。AdaptationSetは、object_widthおよびobject_heightパラメータがtotal_widthおよびtotal_heightパラメータに等しいので、AdaptationSet要素が基準空間全体にわたることを記述するSRDを含むことができる。AdaptationSetは、ソースの同じ空間部分を表現するが異なる解像度を有する2つ以上のRepresentationを含むことができる(たとえば、第1のRepresentationは4096×2048解像度を有することができ、第2のRepresentationは2048×1024解像度を有することができる)。@schemeIdUriが「urn:mpeg:dash:viewport:overlay:2016」に等しく、@valueが「b1」に等しいAdaptationSetのRole要素は、1つまたは複数のAdaptationSet要素がフルフレーム映像レイヤフル映像であることを示すことができる。属性@widthおよび@heightの値によって指定されたフルフレーム映像レイヤRepresentation解像度が、SRDパラメータ@total_widthおよび@total_heightの値に等しくないとき、フルフレーム映像レイヤ映像は、フルフレーム映像レイヤRepresentation解像度に合致するようにアップスケーリングされ得る。
【0097】
エンハンスメントレイヤに関して、ビューポート#1Representationは第1のAdaptationSetに含まれてよく、ビューポート#2Representationは第2のAdaptationSetに含まれてよい。各ビューポートは、異なる解像度および/または帯域幅を有することができる。AdaptationSetは、AdaptationSet要素における映像が360°映像全体の一部分のみを表現することを記述するSRDを含むことができる(たとえば、そのobject_widthおよびobject_heightパラメータがそのtotal_widthおよびtotal_heightよりもそれぞれ小さいため)。@schemeIdUriが「urn:mpeg:dash:viewport:overlay:2016」に等しく、@valueが「f」に等しいAdaptationSetのRole要素は、AdaptationSet要素がビューポート映像であることを示すことができる。属性@widthおよび@heightの値によって指定されたビューポートRepresentation解像度が、SRDパラメータ@object_widthおよび@object_heightの値に等しくないとき、ビューポート映像は元のフルフレーム解像度に合致するようにアップスケーリングされ得る。
【0098】
1つまたは複数(たとえばすべて)のAdaptationSetは、同じ第1のパラメータsource_idを使用して、AdaptationSetにおける映像が4096×2048での基準空間内で互いに空間的に関係することを示すことができる。非SRD認識クライアントは、EssentialPropertyでなくSupplementalPropertyの使用によりフルフレーム映像レイヤフル映像のみを見ることができる。SRD認識クライアントは、いずれかのフルフレーム映像レイヤ(@id=l/2)上にビューポート#1(@id=3/4/5)および/またはビューポート#2(@id=6/7/8)映像をオーバーレイすることによって(たとえば、必要な場合にアップサンプリングされることよって)360°映像を形成することができる。
【0099】
【表12-1】
【0100】
【表12-2】
【0101】
図16は、例示的なレイヤベースの360映像オーバーレイを示す。たとえば、例示的なレイヤベースの360映像オーバーレイは、表12に列挙されたRepresentationに関連付けられ得る。クライアントは、ハーフ解像度フルフレーム映像レイヤRepresentation(@id=1)、およびエンハンスメントレイヤビューポート#1Representation(@id=5)を要求することができる。ハーフ解像度フルフレーム映像レイヤは、そのRepresentation解像度@width=2048および@height=1024が、関連付けられたSRDパラメータ@total_width=4096および@total_height=2048よりも小さいので、フル解像度4096×2048にアップサンプリングされ得る。高品質ビューポートは、関連付けられたSRDパラメータでシグナリングされるようにobject_x(たとえば100)およびobject_y(たとえば100)によってシグナリングされた位置において360映像上にオーバーレイされ得る。
【0102】
図16に示される映像変換は、(たとえば、Representation解像度、投影および/またはレイアウトが、フルフレーム映像レイヤとビューポート映像との間で一致されないとき、)アップスケーリング、投影変換、および/またはレイアウト変換を行うことができる。
【0103】
図17は、例示的なレイヤベースの360映像オーバーレイのフローチャートを示す。
【0104】
フルフレーム映像レイヤおよびエンハンスメントレイヤリプレゼンテーションは、異なるフレームレートを有し得る。@width、@height、および@bandwidthと共に属性@frameRateが、AdaptationSet、Representation、およびSub-Representation要素についての共通の属性および要素として指定されるので、@width、@height、および@frameRateは、AdaptationSet、Representation、および/またはSub-Representationに対してシグナリングされ得る。@frameRateがAdaptationSetレベルでシグナリングされると、AdaptationSetに割り当てられた1つまたは複数のRepresentationが、同じ値の@frameRateを共有することができる。表13は、AdaptationSetレベルで異なるフレームレートを有するRepresentationに関するMPD例である。
【0105】
【表13-1】
【0106】
【表13-2】
【0107】
【表13-3】
【0108】
複数のターゲットビューポート映像が要求され、および/または360°フル映像球上にオーバーレイされ得る。ユーザ方位位置に基づいて、ユーザは、(たとえば、高速ビューポート変更を容易にするため、および/または全体的システムレイテンシを低減させるために、)同時に複数の高品質ビューポートを要求することができる。1つまたは複数(たとえばすべて)のビューポートレイヤが、基準空間として同じフルフレーム映像レイヤ360°映像を共有することができる。クライアントは、それが受信した複数のビューポートをレンダリングのために同じ基準空間上にオーバーレイすることができる。フルフレーム映像レイヤおよびエンハンスメントレイヤビューポートの間で投影およびレイアウトが異なるとき、フルフレーム映像レイヤ映像はアンカーフォーマットとして使用されることができ、および/またはエンハンスメントレイヤビューポートはアンカーフォーマットに変換されることができる(たとえば、それにより、合成位置が、フルフレーム映像レイヤとビューポート映像との間でアライメントされることができる)。
【0109】
図18は、例示的な複数のビューポートオーバーレイを示す。たとえば、2つのエンハンスメントされたビューポートを有するレイヤベースのオーバーレイが、表13に示されるようにシグナリングされ得る。クライアントは、基準空間としてのフルフレーム映像レイヤ360°映像(たとえば、Representation@id=1)、および/または2つの高品質エンハンスメントレイヤビューポート(たとえば、Representation@id=5および@id=8)を要求することができる。2つのエンハンスメントされたビューポートを有するコンポジット映像は、両方のビューポートが短期間(たとえば、同じセグメント持続時間中)注視され得るという決定に基づいて生成され得る。フルフレーム映像レイヤ映像とエンハンスメントレイヤビューポートとの間で映像タイプ、投影、および/またはレイアウトが異なる場合、追加の投影および/またはレイアウト変換が行われ得る。レイヤベースの360映像オーバーレイは、より効率的にビューポート変更に適応できる可能性がある。フルフレーム映像レイヤのセグメント長が、(たとえば、フルフレーム映像レイヤ映像は常に配信されるので)符号化効率を改善するために増大され得る。ビューポート映像レイヤのセグメント長は、ビューポート間の速い切り替えに対応するためにより短く維持され得る。
【0110】
本明細書に説明されているレイヤベースの360映像オーバーレイは、SRDを使用して、ビューポート映像および/またはオーバーレイの空間関係を記述して、コンポジット映像を形成するためのオーバーレイ手順を記述することができる。SRDにおいて指定されたsource_id、object_x、object_y、object_width、object_height、total_width、および/またはtotal_heightなどの1つまたは複数の空間パラメータは、MPD構造を単純化するためにオーバーレイ@valueにマージされ得る。Role要素の@valueは、ビューポートインジケータ、source_id、object_x、object_y、object_width、object_height、total_width、および/またはtotal_heightのコンマ区切りリストを含むことができる。表14は、マージされたオーバーレイを有するMPD例を示す。
【0111】
【表14-1】
【0112】
【表14-2】
【0113】
レイヤベースの360映像オーバーレイは、@schemeIdUriが「urn:mpeg:dash:viewport:overlay:2016」に等しいSupplementalPropertyおよび/またはEssentialPropertyなどの1つまたは複数の記述子によって提供され得る。
【0114】
異なる映像Representationは、異なる投影フォーマットにあり得る(たとえば、一方のRepresentationは正距円筒図法であるのに対して別のRepresentationはキューブマップである、または一方の映像Representationは球映像であるのに対して別の映像Representationは直線的である)。映像プロパティは、OMAFファイルフォーマットから指定され得る。AdaptationSet、Representation、および/またはSub-Representationについて指定された1つまたは複数の共通属性、@videoTypeは、球映像、ライトフィールド映像、および/または直線的映像を示すことができる。球映像の場合、異なる投影フォーマットおよび/または投影+レイアウトの組み合わせ、たとえば、正距円筒図法、(たとえば、図10に示されている異なるレイアウトと組み合わせた)キューブマップ、および/また角錐マップなどが、AdaptationSet、Representation、および/またはSub-Representation要素についての共通属性@projectionおよび/または@layoutとしてシグナリングされ得る。要素および属性は、SupplementalPropertyおよび/またはEssentialProperty要素を使用して提供され得る。
【0115】
表15は、映像タイプおよび/または投影属性のセマンティクス例である。投影属性は、クライアントの能力に基づいてユーザが適切な映像を要求するのを支援することができる。たとえば、球映像および/またはライトフィールド映像をサポートしないクライアントは、直線的映像のみを要求することができる。例では、球映像をサポートするクライアントは、利用可能なフォーマットのセットから適切なフォーマット(たとえば、キューブマップの代わりに正距円筒図法)を選択することができる。
【0116】
【表15】
【0117】
【表16】
【0118】
【表17】
【0119】
【表18】
【0120】
表18のレイアウトフォーマットは以下の図で例示され得る。
【0121】
図19は、側部のハーフハイト極を有する例示的な正距円筒図法リプレゼンテーションを示す。
【0122】
図20は、側部のフルハイト極を有する例示的な正距円筒図法リプレゼンテーションを示す。
【0123】
図21は、(たとえば、region_idを有する)キューブリプレゼンテーションフォーマットのための例示的な単列レイアウトを示す。
【0124】
図22は、(たとえば、region_idを有する)キューブリプレゼンテーションフォーマットのための例示的な2×3レイアウトを示す。
【0125】
図23は、キューブマップのための例示的な180°レイアウトを示す。
【0126】
キューブマップ投影のための180°レイアウトは、(たとえば、後半分のエリアの幅および高さを半分に減らすことによって)キューブの後半分の解像度を25%低下させることができ、および/または、結果として図23に示される領域a、b、c、d、およびeが前半分に属し領域f、g、h、i、およびjが後半分に属するレイアウトを使用することができる。
【0127】
表19は、そのような共通の属性および要素を使用して正距円筒図法投影とキューブマップ投影の両方をサポートするMPD例である。
【0128】
【表19-1】
【0129】
【表19-2】
【0130】
図24Aは、開示される1つまたは複数の実施形態が実装され得る例示的な通信システム100の図である。通信システム100は、音声、データ、映像、メッセージング、ブロードキャストなどのコンテンツを複数の無線ユーザに提供する、多元接続システムとすることができる。通信システム100は、複数の無線ユーザが、無線帯域幅を含むシステムリソースの共有を通じてそのようなコンテンツにアクセスすることを可能にし得る。たとえば、通信システム100は、符号分割多元接続(CDMA)、時分割多元接続(TDMA)、周波数分割多元接続(FDMA)、直交FDMA(OFDMA)、シングルキャリアFDMA(SC-FDMA)など、1つまたは複数のチャネルアクセス方法を利用することができる。
【0131】
図24Aに示されるように、通信システム100は、(一般にまたは集合的にWTRU102と呼ばれることがある)無線送受信ユニット(WTRU)102a、102b、102c、および/または102d、無線アクセスネットワーク(RAN)103/104/105、コアネットワーク106/107/109、公衆交換電話網(PSTN)108、インターネット110、ならびに他のネットワーク112を含むことができるが、開示される実施形態は、任意の数のWTRU、基地局、ネットワーク、および/またはネットワーク要素を企図することが理解されよう。WTRU102a、102b、102c、102dの各々は、無線環境で動作および/または通信するように構成された任意のタイプのデバイスとすることができる。例として、WTRU102a、102b、102c、102dは、無線信号を送信および/または受信するように構成されてよく、ユーザ機器(UE)、移動局、固定もしくは移動加入者ユニット、ページャ、セルラ電話、携帯情報端末(PDA)、スマートフォン、ラップトップ、ネットブック、パーソナルコンピュータ、無線センサ、および家電製品などを含むことができる。
【0132】
通信システム100は、基地局114aおよび基地局114bを含むこともできる。基地局114a、114bの各々は、コアネットワーク106/107/109、インターネット110、および/またはネットワーク112などの1つまたは複数の通信ネットワークへのアクセスを容易にするために、WTRU102a、102b、102c、102dのうちの少なくとも1つと無線でインターフェース接続するように構成された、任意のタイプのデバイスとすることができる。例として、基地局114a、114bは、トランシーバ基地局(BTS)、ノードB、eノードB、ホームノードB、ホームeノードB、サイトコントローラ、アクセスポイント(AP)、および無線ルータなどにすることができる。基地局114a、114bは各々が単一の要素として示されているが、基地局114a、114bは、任意の数の相互接続された基地局および/またはネットワーク要素を含むことができることが理解されよう。
【0133】
基地局114aは、RAN103/104/105の一部とすることができ、RAN103/104/105は、基地局コントローラ(BSC)、無線ネットワークコントローラ(RNC)、中継ノードなど、他の基地局および/またはネットワーク要素(図示せず)を含むこともできる。基地局114aおよび/または基地局114bは、セル(図示せず)と呼ばれることがある特定の地理的領域内で、無線信号を送信および/または受信するように構成され得る。セルは、さらにセルセクタに分割され得る。たとえば、基地局114aに関連付けられたセルは、3つのセクタに分割され得る。したがって、一実施形態では、基地局114aは、3つのトランシーバ(Transceiver:無線送受信機)を、たとえば、セルのセクタごとに1つ含むことができる。別の実施形態では、基地局114aは、多入力多出力(MIMO)技術を利用することができ、したがって、セルのセクタごとに複数のトランシーバを利用することができる。
【0134】
基地局114a、114bは、エアインターフェース115/116/117を介してWTRU102a、102b、102c、102dのうちの1つまたは複数と通信することができ、エアインターフェース115/116/117は、任意の適切な無線通信リンク(たとえば、無線周波数(RF)、マイクロ波、赤外線(IR)、紫外線(UV)、可視光など)とすることができる。エアインターフェース115/116/117は、任意の適切な無線アクセス技術(RAT)を使用して確立され得る。
【0135】
より具体的には、上記されたように、通信システム100は、多元接続システムとすることができ、CDMA、TDMA、FDMA、OFDMA、およびSC-FDMAなどの1つまたは複数のチャネルアクセス方式を利用することができる。たとえば、RAN103/104/105内の基地局114a、およびWTRU102a、102b、102cは、広帯域CDMA(WCDMA(登録商標))を使用してエアインターフェース115/116/117を確立できる、ユニバーサル移動体通信システム(UMTS)地上無線アクセス(UTRA)などの無線技術を実装することができる。WCDMAは、高速パケットアクセス(HSPA)および/またはEvolved HSPA(HSPA+)などの通信プロトコルを含むことができる。HSPAは、高速ダウンリンクパケットアクセス(HSDPA)および/または高速アップリンクパケットアクセス(HSUPA)を含むことができる。
【0136】
別の実施形態では、基地局114a、およびWTRU102a、102b、102cは、ロングタームエボリューション(LTE)および/またはLTEアドバンスト(LTE-A)を使用してエアインターフェース115/116/117を確立できる、Evolved UMTS地上無線アクセス(E-UTRA)などの無線技術を実装することができる。
【0137】
他の実施形態では、基地局114a、およびWTRU102a、102b、102cは、IEEE802.16(たとえば、マイクロ波アクセス用世界的相互運用(WiMAX))、CDMA2000、CDMA2000 1X、CDMA2000 EV-DO、暫定標準2000(IS-2000)、暫定標準95(IS-95)、暫定標準856(IS-856)、移動体通信用グローバルシステム(GSM(登録商標))、GSMエボリューション用拡張データレート(EDGE)、およびGSM EDGE(GERAN)などの無線技術を実装することができる。
【0138】
図24Aにおける基地局114bは、たとえば、無線ルータ、ホームノードB、ホームeノードB、またはアクセスポイントとすることができ、職場、家庭、乗り物、およびキャンパスなどの局所的エリアにおける無線接続性を容易にするために任意の適切なRATを利用することができる。一実施形態では、基地局114bおよびWTRU102c、102dは、IEEE802.11などの無線技術を実装して無線ローカルエリアネットワーク(WLAN)を確立することができる。別の実施形態では、基地局114bおよびWTRU102c、102dは、IEEE802.15などの無線技術を実装して無線パーソナルエリアネットワーク(WPAN)を確立することができる。さらに別の実施形態では、基地局114bおよびWTRU102c、102dは、セルラベースのRAT(たとえば、WCDMA、CDMA2000、GSM、LTE、LTE-Aなど)を利用してピコセルまたはフェムトセルを確立することができる。図24Aに示されるように、基地局114bは、インターネット110への直接接続を有することができる。したがって、基地局114bは、コアネットワーク106/107/109を介してインターネット110にアクセスすることを必要とされなくてよい。
【0139】
RAN103/104/105は、コアネットワーク106/107/109と通信することができ、コアネットワーク106/107/109は、音声、データ、アプリケーション、および/またはボイスオーバーインターネットプロトコル(VoIP)サービスをWTRU102a、102b、102c、102dのうちの1つまたは複数に提供するように構成された、任意のタイプのネットワークとすることができる。たとえば、コアネットワーク106/107/109は、呼制御、請求サービス、モバイルロケーションベースのサービス、プリペイド通話、インターネット接続性、映像配信などを提供することができ、および/またはユーザ認証などの高レベルセキュリティ機能を実行することができる。図24Aに示されていないが、RAN103/104/105および/またはコアネットワーク106/107/109は、RAN103/104/105と同じRATまたは異なるRATを利用する他のRANとの直接的または間接的な通信が可能であることが理解されよう。たとえば、E-UTRA無線技術を利用し得るRAN103/104/105に接続されるのに加えて、コアネットワーク106/107/109は、GSM無線技術を利用する別のRAN(図示せず)と通信することもできる。
【0140】
コアネットワーク106/107/109は、PSTN108、インターネット110、および/または他のネットワーク112にアクセスするための、WTRU102a、102b、102c、102dのためのゲートウェイの役割をすることもできる。PSTN108は、基本電話サービス(POTS)を提供する回線交換電話網を含むことができる。インターネット110は、TCP/IPインターネットプロトコルスイートにおける伝送制御プロトコル(TCP)、ユーザデータグラムプロトコル(UDP)、およびインターネットプロトコル(IP)などの共通の通信プロトコルを使用する、相互接続されたコンピュータネットワークおよびデバイスのグローバルシステムを含むことができる。ネットワーク112は、他のサービスプロバイダによって所有および/または運用される有線または無線通信ネットワークを含むことができる。たとえば、ネットワーク112は、RAN103/104/105と同じRATまたは異なるRATを利用できる1つまたは複数のRANに接続された別のコアネットワークを含むことができる。
【0141】
通信システム100におけるWTRU102a、102b、102c、102dの一部または全部は、マルチモード能力を含むことができ、たとえば、WTRU102a、102b、102c、102dは、異なる無線リンクを介して異なる無線ネットワークと通信するための複数のトランシーバを含むことができる。たとえば、図24Aに示されているWTRU102cは、セルラベースの無線技術を利用できる基地局114a、およびIEEE802無線技術を利用できる基地局114bと通信するように構成され得る。
【0142】
図24Bは、例示的なWTRU102のシステム図である。図24Bに示されるように、WTRU102は、プロセッサ118、トランシーバ120、送受信要素122、スピーカ/マイクロフォン124、キーパッド126、ディスプレイ/タッチパッド128、着脱不能メモリ130、着脱可能メモリ132、電源134、全地球測位システム(GPS)チップセット136、および他の周辺機器138を含むことができる。WTRU102は、実施形態との整合性を保ちながら、上記の要素の任意の部分的組み合わせを含むことができることが理解されよう。また、実施形態は、基地局114aおよび114b、ならびに/または基地局114aおよび114bが表し得るノード、たとえば以下に限定されないが特に、トランシーバ局(BTS)、ノードB、サイトコントローラ、アクセスポイント(AP)、ホームノードB、evolvedホームノードB(eNodeB)、ホームevolvedノードB(HeNB)、ホームevolvedノードBゲートウェイ、およびプロキシノードなどが、図24Bに示され本明細書で説明される要素の一部または全部を含み得ることを企図している。
【0143】
プロセッサ118は、汎用プロセッサ、専用プロセッサ、従来型プロセッサ、デジタル信号プロセッサ(DSP)、複数のマイクロプロセッサ、DSPコアと関連した1つまたは複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)回路、他の任意のタイプの集積回路(IC)、および状態機械などとすることができる。プロセッサ118は、信号符号化、データ処理、電力制御、入出力処理、および/またはWTRU102が無線環境で動作するのを可能にする他の任意の機能性を実行することができる。プロセッサ118はトランシーバ120に結合されることができ、トランシーバ120は送受信要素122に結合されることができる。図24Bはプロセッサ118とトランシーバ120を別々のコンポーネントとして示しているが、プロセッサ118とトランシーバ120は電子パッケージまたはチップに一緒に統合されてよいことが理解されよう。
【0144】
送受信要素122は、エアインターフェース115/116/117を介して、基地局(たとえば基地局114a)に信号を送信し、または基地局から信号を受信するように構成され得る。たとえば、一実施形態では、送受信要素122は、RF信号を送信および/または受信するように構成されたアンテナとすることができる。別の実施形態では、送受信要素122は、たとえば、IR、UV、または可視光信号を送信および/または受信するように構成されたエミッタ/ディテクタとすることができる。さらに別の実施形態では、送受信要素122は、RF信号と光信号の両方を送信および受信するように構成され得る。送受信要素122が無線信号の任意の組み合わせを送信および/または受信するように構成され得ることは理解されよう。
【0145】
加えて、図24Bでは送受信要素122は単一の要素として示されているが、WTRU102は任意の数の送受信要素122を含むことができる。より具体的には、WTRU102はMIMO技術を利用することができる。したがって、一実施形態では、WTRU102は、エアインターフェース115/116/117を介して無線信号を送信および受信するための2つ以上の送受信要素122(たとえば、複数のアンテナ)を含むことができる。
【0146】
トランシーバ120は、送受信要素122によって送信される信号を変調し、送受信要素122によって受信された信号を復調するように構成され得る。上記されたように、WTRU102はマルチモード能力を有することができる。したがって、トランシーバ120は、たとえばUTRAおよびIEEE802.11などの複数のRATを介してWTRU102が通信することを可能にするための、複数のトランシーバを含むことができる。
【0147】
WTRU102のプロセッサ118は、スピーカ/マイクロフォン124、キーパッド126、および/またはディスプレイ/タッチパッド128(たとえば、液晶表示(LCD)ディスプレイユニットもしくは有機発光ダイオード(OLED)表示ユニット)に結合されることができ、それらからユーザ入力データを受信することができる。プロセッサ118は、スピーカ/マイクロフォン124、キーパッド126、および/またはディスプレイ/タッチパッド128にユーザデータを出力することもできる。加えて、プロセッサ118は、着脱不能メモリ130および/または着脱可能メモリ132などの任意のタイプの適切なメモリからの情報にアクセスすることができ、それらにデータを記憶することができる。着脱不能メモリ130は、ランダムアクセスメモリ(RAM)、読み出し専用メモリ(ROM)、ハードディスク、または他の任意のタイプのメモリストレージデバイスを含むことができる。着脱可能メモリ132は、加入者識別モジュール(SIM)カード、メモリスティック、およびセキュアデジタル(SD)メモリカードなどを含むことができる。他の実施形態では、プロセッサ118は、WTRU102上に物理的に配置されたメモリではなく、サーバまたはホームコンピュータ(図示せず)上などのメモリからの情報にアクセスすることができ、それらにデータを記憶することができる。
【0148】
プロセッサ118は、電源134から電力を受け取ることができ、WTRU102内の他のコンポーネントへの電力の分配および/または制御をするように構成され得る。電源134は、WTRU102に電力供給するための任意の適切なデバイスとすることができる。たとえば、電源134は、1つまたは複数の乾電池(たとえば、ニッケルカドミウム(NiCd)、ニッケル-亜鉛(NiZn)、ニッケル水素(NiMH)、リチウムイオン(Li-ion)など)、太陽電池、および燃料電池などを含むことができる。
【0149】
プロセッサ118は、GPSチップセット136に結合されてもよく、GPSチップセット136は、WTRU102の現在位置に関する位置情報(たとえば、経度および緯度)を提供するように構成され得る。GPSチップセット136からの情報に加えてまたは代えて、WTRU102は、基地局(たとえば、基地局114a、114b)からエアインターフェース115/116/117を介して位置情報を受信し、および/または2つ以上の近くの基地局から受信された信号のタイミングに基づいてその位置を決定することができる。WTRU102は、実施形態との整合性を保ちながら、任意の適切な位置決定方法によって位置情報を取得できることが理解されよう。
【0150】
プロセッサ118は、他の周辺機器138にさらに結合されてよく、他の周辺機器138は、追加的な特徴、機能性、および/または有線もしくは無線接続性を提供する1つまたは複数のソフトウェアおよび/またはハードウェアモジュールを含むことができる。たとえば、周辺機器138は、加速度計、電子コンパス、衛星トランシーバ、(写真または映像用)デジタルカメラ、ユニバーサルシリアルバス(USB)ポート、振動デバイス、テレビトランシーバ、ハンズフリーヘッドセット、Bluetooth(登録商標)モジュール、周波数変調(FM)無線ユニット、デジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、およびインターネットブラウザなどを含むことができる。
【0151】
図24Cは、実施形態によるRAN103およびコアネットワーク106のシステム図である。上記されたように、RAN103は、UTRA無線技術を利用して、エアインターフェース115を介してWTRU102a、102b、102cと通信することができる。RAN103は、コアネットワーク106と通信することもできる。図24Cに示されるように、RAN103は、ノードB140a、140b、140cを含むことができ、ノードB140a、140b、140cは各々が、エアインターフェース115を介してWTRU102a、102b、102cと通信するための1つまたは複数のトランシーバを含むことができる。ノードB140a、140b、140cは各々が、RAN103内の特定のセル(図示せず)に関連付けられ得る。RAN103はRNC142a、142bを含むこともできる。RAN103は、実施形態との整合性を保ちながら、任意の数のノードBおよびRNCを含むことができることが理解されよう。
【0152】
図24Cに示されるように、ノードB140a、140bはRNC142aと通信することができる。加えて、ノードB140cはRNC142bと通信することができる。ノードB140a、140b、140cは、Iubインターフェースを介してそれぞれのRNC142a、142bと通信することができる。RNC142a、142bは、Iurインターフェースを介して互いに通信することができる。RNC142a、142bの各々は、それが接続されたそれぞれのノードB140a、140b、140cを制御するように構成され得る。加えて、RNC142a、142bの各々は、アウタループ電力制御、負荷制御、アドミッション制御、パケットスケジューリング、ハンドオーバ制御、マクロダイバーシティ、セキュリティ機能、およびデータ暗号化など、他の機能性を実施またはサポートするように構成され得る。
【0153】
図24Cに示されるコアネットワーク106は、メディアゲートウェイ(MGW)144、移動交換局(MSC)146、サービングGPRSサポートノード(SGSN)148、および/またはゲートウェイGPRSサポートノード(GGSN)150を含むことができる。上記の要素の各々はコアネットワーク106の部分として示されているが、これらの要素のいずれも、コアネットワークオペレータとは異なるエンティティによって所有および/または運用され得ることが理解されよう。
【0154】
RAN103内のRNC142aは、IuCSインターフェースを介してコアネットワーク106内のMSC146に接続され得る。MSC146はMGW144に接続され得る。MSC146およびMGW144は、PSTN108などの回線交換ネットワークへのアクセスをWTRU102a、102b、102cに提供して、WTRU102a、102b、102cと従来の陸線通信デバイスとの間の通信を容易にすることができる。
【0155】
RAN103内のRNC142aは、IuPSインターフェースを介してコアネットワーク106内のSGSN148にも接続され得る。SGSN148はGGSN150に接続され得る。SGSN148およびGGSN150は、インターネット110などのパケット交換ネットワークへのアクセスをWTRU102a、102b、102cに提供して、WTRU102a、102b、102cとIP対応デバイスとの間の通信を容易にすることができる。
【0156】
上記されたように、コアネットワーク106は、ネットワーク112にも接続されてよく、ネットワーク112は、他のサービスプロバイダによって所有および/または運用される他の有線または無線ネットワークを含むことができる。
【0157】
図24Dは、実施形態によるRAN104およびコアネットワーク107のシステム図である。上記されたように、RAN104は、E-UTRA無線技術を利用して、エアインターフェース116を介してWTRU102a、102b、102cと通信することができる。RAN104はコアネットワーク107と通信することもできる。
【0158】
RAN104はeノードB160a、160b、160cを含むことができるが、RAN104は、実施形態との整合性を保ちながら、任意の数のeノードBを含むことができることが理解されよう。eノードB160a、160b、160cは各々が、エアインターフェース116を介してWTRU102a、102b、102cと通信するための1つまたは複数のトランシーバを含むことができる。一実施形態では、eノードB160a、160b、160cはMIMO技術を実装することができる。したがって、eノードB160aは、たとえば、複数のアンテナを使用して、WTRU102aに無線信号を送信し、WTRU102aから無線信号を受信することができる。
【0159】
eノードB160a、160b、160cの各々は、セル(図示せず)に関連付けられてよく、無線リソース管理決定、ハンドオーバ決定、ならびにアップリンクおよび/またはダウンリンクにおけるユーザのスケジューリングなどを処理するように構成され得る。図24Dに示されるように、eノードB160a、160b、160cはX2インターフェースを介して互いに通信することができる。
【0160】
図24Dに示されるコアネットワーク107は、モビリティ管理ゲートウェイ(MME)162、サービングゲートウェイ164、およびパケットデータネットワーク(PDN)ゲートウェイ166を含むことができる。上記の要素の各々はコアネットワーク107の部分として示されているが、これらの要素のいずれも、コアネットワークオペレータとは異なるエンティティによって所有および/または運用され得ることが理解されよう。
【0161】
MME162は、S1インターフェースを介してRAN104内のeノードB160a、160b、160cの各々に接続されてよく、制御ノードの役割をすることができる。たとえば、MME162は、WTRU102a、102b、102cのユーザの認証、ベアラアクティブ化/非アクティブ化、およびWTRU102a、102b、102cの初期アタッチ中のサービングゲートウェイの選択などを担当することができる。MME162は、RAN104とGSMまたはWCDMAなどの他の無線技術を利用する他のRAN(図示せず)との間の切り替えのための制御プレーン機能を提供することもできる。
【0162】
サービングゲートウェイ164は、S1インターフェースを介してRAN104内のeノードB160a、160b、160cの各々に接続され得る。サービングゲートウェイ164は一般に、WTRU102a、102b、102cへ/からのユーザデータパケットのルーティングおよび転送を行うことができる。サービングゲートウェイ164は、eノードB間ハンドオーバ中にユーザプレーンをアンカリングすること、ダウンリンクデータがWTRU102a、102b、102cに利用可能なときにページングをトリガすること、ならびにWTRU102a、102b、102cのコンテキストを管理および記憶することなど、他の機能を実行することもできる。
【0163】
サービングゲートウェイ164は、PDNゲートウェイ166に接続されてもよく、PDNゲートウェイ166は、インターネット110などのパケット交換ネットワークへのアクセスをWTRU102a、102b、102cに提供して、WTRU102a、102b、102cとIP対応デバイスとの間の通信を容易にすることができる。
【0164】
コアネットワーク107は他のネットワークとの通信を容易にすることができる。たとえば、コアネットワーク107は、PSTN108などの回線交換ネットワークへのアクセスをWTRU102a、102b、102cに提供して、WTRU102a、102b、102cと従来の陸線通信デバイスとの間の通信を容易にすることができる。たとえば、コアネットワーク107は、コアネットワーク107とPSTN108との間のインターフェースとしての役割をするIPゲートウェイ(たとえば、IPマルチメディアサブシステム(IMS)サーバ)を含むことができ、またはそのようなIPゲートウェイと通信することができる。加えて、コアネットワーク107は、ネットワーク112へのアクセスをWTRU102a、102b、102cに提供することができ、ネットワーク112は、他のサービスプロバイダによって所有および/または運用される他の有線または無線ネットワークを含むことができる。
【0165】
図24Eは、実施形態によるRAN105およびコアネットワーク109のシステム図である。RAN105は、IEEE802.16無線技術を利用してエアインターフェース117を介してWTRU102a、102b、102cと通信する、アクセスサービスネットワーク(ASN)とすることができる。以下でさらに説明されるように、WTRU102a、102b、102c、RAN105、およびコアネットワーク109の異なる機能エンティティの間の通信リンクが、基準点として定義され得る。
【0166】
図24Eに示されるように、RAN105は、基地局180a、180b、180cおよびASNゲートウェイ182を含むことができるが、RAN105は、実施形態との整合性を保ちながら、任意の数の基地局およびASNゲートウェイを含むことができることが理解されよう。基地局180a、180b、180cは各々が、RAN105内のセル(図示せず)に関連付けられてよく、各々が、エアインターフェース117を介してWTRU102a、102b、102cと通信するための1つまたは複数のトランシーバを含むことができる。一実施形態では、基地局180a、180b、180cはMIMO技術を実装することができる。したがって、基地局180aは、たとえば、複数のアンテナを使用して、WTRU102aに無線信号を送信し、WTRU102aから無線信号を受信することができる。基地局180a、180b、180cは、ハンドオフトリガ、トンネル確立、無線リソース管理、トラフィック分類、およびサービス品質(QoS)ポリシ実施などのモビリティ管理機能を提供することもできる。ASNゲートウェイ182は、トラフィック集約点の役割をすることができ、ページング、加入者プロファイルのキャッシング、およびコアネットワーク109へのルーティングなどを担当することができる。
【0167】
WTRU102a、102b、102cとRAN105との間のエアインターフェース117は、IEEE802.16仕様を実装するR1基準点として定義され得る。加えて、WTRU102a、102b、102cの各々は、コアネットワーク109との論理インターフェース(図示せず)を確立することができる。WTRU102a、102b、102cとコアネットワーク109との間の論理インターフェースは、認証、認可、IPホスト構成管理、および/またはモビリティ管理のために使用され得るR2基準点として定義され得る。
【0168】
基地局180a、180b、180cの各々の間の通信リンクは、WTRUハンドオーバおよび基地局間のデータの転送を容易にするためのプロトコルを含むR8基準点として定義され得る。基地局180a、180b、180cとASNゲートウェイ182との間の通信リンクは、R6基準点として定義され得る。R6基準点は、WTRU102a、102b、102cの各々に関連付けられたモビリティイベントに基づくモビリティ管理を容易にするためのプロトコルを含むことができる。
【0169】
図24Eに示されるように、RAN105はコアネットワーク109に接続され得る。RAN105とコアネットワーク109との間の通信リンクは、たとえばデータ転送およびモビリティ管理能力を容易にするためのプロトコルを含むR3基準点として定義され得る。コアネットワーク109は、モバイルIPホームエージェント(MIP-HA)184、認証、認可、課金(AAA)サーバ186、およびゲートウェイ188を含むことができる。上記の要素の各々はコアネットワーク109の部分として示されているが、これらの要素のいずれも、コアネットワークオペレータとは異なるエンティティによって所有および/または運用され得ることが理解されよう。
【0170】
MIP-HAは、IPアドレス管理を担当することができ、異なるASNおよび/または異なるコアネットワークの間でWTRU102a、102b、102cがローミングすることを可能にし得る。MIP-HA184は、インターネット110などのパケット交換ネットワークへのアクセスをWTRU102a、102b、102cに提供して、WTRU102a、102b、102cとIP対応デバイスとの間の通信を容易にすることができる。AAAサーバ186は、ユーザ認証、およびユーザサービスのサポートを担当することができる。ゲートウェイ188は、他のネットワークとの網間接続を容易にすることができる。たとえば、ゲートウェイ188は、PSTN108などの回線交換ネットワークへのアクセスをWTRU102a、102b、102cに提供して、WTRU102a、102b、102cと従来の陸線通信デバイスとの間の通信を容易にすることができる。加えて、ゲートウェイ188は、ネットワーク112へのアクセスをWTRU102a、102b、102cに提供し、ネットワーク112は、他のサービスプロバイダによって所有および/または運用される他の有線または無線ネットワークを含むことができる。
【0171】
本明細書に説明されているコンピューティングシステムの各々は、本明細書に説明された機能を実現するために、本明細書に説明されたパラメータを決定し、エンティティ(たとえば、WTRUおよびネットワークまたはクライアントおよびサーバ)の間でメッセージを送信および受信することを含む、本明細書に説明された機能を実現するための実行可能命令で構成されたメモリを有する1つもしくは複数のコンピュータプロセッサまたはハードウェアを有することができる。上記に説明されたプロセスは、コンピュータおよび/またはプロセッサによって実行するためのコンピュータ可読媒体に組み込まれたコンピュータプログラム、ソフトウェア、および/またはファームウェアで実装され得る。
【0172】
図24Eに示されていないが、RAN105は他のASNに接続されてよく、コアネットワーク109は他のコアネットワークに接続されてよいことが理解されよう。RAN105と他のASNとの間の通信リンクは、RAN105と他のASNとの間でWTRU102a、102b、102cのモビリティを調整するためのプロトコルを含むことができるR4基準点として定義され得る。コアネットワーク109と他のコアネットワークとの間の通信リンクは、ホームコアネットワークと訪問先コアネットワークとの間の網間接続を容易にするためのプロトコルを含むことができるR5基準点として定義され得る。
【0173】
特徴および要素が特定の組み合わせで上記に説明されているが、各特徴または要素は、単独でまたは他の特徴および要素との任意の組み合わせで使用され得ることが当業者には理解されよう。加えて、本明細書に説明された方法は、コンピュータまたはプロセッサによって実行するためのコンピュータ可読媒体に組み込まれたコンピュータプログラム、ソフトウェア、またはファームウェアで実装され得る。コンピュータ可読媒体の例は、(有線または無線接続を介して送信される)電子信号、およびコンピュータ可読記憶媒体を含む。コンピュータ可読記憶媒体の例は、読み出し専用メモリ(ROM)、ランダムアクセスメモリ(RAM)、レジスタ、キャッシュメモリ、半導体メモリデバイス、内蔵ハードディスクおよび着脱可能ディスクなどの磁気媒体、光磁気媒体、ならびにCD-ROMディスクおよびデジタル多用途ディスク(DVD)などの光媒体を含むが、これらに限定されない。ソフトウェアと関連するプロセッサは、WTRU、WTRU、端末、基地局、RNC、または任意のホストコンピュータで使用するための無線周波数トランシーバを実装するために使用され得る。
【産業上の利用可能性】
【0174】
本発明は、想現実(VR)デバイスに利用できる。
【符号の説明】
【0175】
100 通信システム
102、102a~102d WTRU
103、104、105 RAN
106、107、108 コアネットワーク
108 PSTN
110 インターネット
112 他のネットワーク
114a、114b 基地局
118 プロセッサ
120 無線送受信機(トランシーバ)
122 アンテナ
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10A
図10B
図10C
図10D
図11A
図11B
図12
図13A
図13B
図14
図15
図16
図17
図18
図19
図20
図21
図22
図23
図24A
図24B
図24C
図24D
図24E