JP7333802B2 - ３６０度適応ストリーミングのエクスペリエンスを改善するためのメトリックおよびメッセージ - Google Patents

Description

本出願は、３６０度適応ストリーミングのエクスペリエンスを改善するためのメトリックおよびメッセージに関する。
関連出願の相互参照
本出願は、それらの内容が参照により組み込まれる、２０１７年３月２３日に出願された米国特許仮出願第６２／４７５，５６３号明細書２０１７年６月２６日に出願された米国特許仮出願第６２／５２５，０６５号明細書、２０１８年２月２８日に出願された米国特許仮出願第６２／６３６，７９５号明細書の利益を主張する。

３６０°ビデオは、メディア産業に現れつつある急成長しているフォーマットである。３６０°ビデオは、バーチャルリアリティ（ＶＲ）デバイスの増大している利用可能性によって可能にされる。３６０°ビデオは、新しい存在感を閲覧者に提供し得る。レクティリニアビデオ（たとえば、２Ｄまたは３Ｄ）と比較して、３６０°ビデオは、ビデオ処理および／または配信に関して困難なエンジニアリング課題を提示することがある。快適および／または没入型ユーザエクスペリエンスを可能にすることは、高いビデオ品質および／または極めて低いレイテンシを要求し得る。３６０°ビデオの大きいビデオサイズは、スケールにおける品質様式で３６０°ビデオを配信するのに妨げになり得る。

３６０°ビデオアプリケーションおよび／またはサービスは、３６０°ビデオ全体をプログレッシブダウンロードおよび／または適応ストリーミングのために規格準拠ストリームに符号化し得る。３６０°ビデオ全体をクライアントに配信することは低レイテンシレンダリングを可能にし得る（たとえば、クライアントは、３６０°ビデオコンテンツの全体へのアクセスを有することがあり、および／またはそれがさらなる制約なしに見ることを望む部分をレンダリングすることを選定することができる）。サーバの観点からは、同じストリームは、場合によっては異なるビューポートをもつ複数のユーザをサポートすることができる。ビデオサイズははなはだ高くなることがあり、（たとえば、３６０°ビデオ全体が眼ごとに４Ｋ＠６０ｆｐｓまたは６Ｋ＠９０ｆｐｓなどの高品質で符号化され得るので）ビデオが配信されるときの高い送信帯域幅を招く。配信中の高帯域幅消費は、たとえば、ユーザがピクチャ全体の小さい部分（たとえば、ビューポート）のみを閲覧し得るので、浪費されることがある。

ストリーミングクライアント、コンテンツオリジンサーバ、測定／分析サーバおよび／または他のビデオストリーミング支援ネットワーク要素の間で情報を交換するためのシステム、方法、および手段が提供され得る。

たとえば、ストリーミングクライアントは、一貫した様式でそれらがサポートするメトリックを生成し、報告し得、様々なネットワーク要素は、ストリーミング支援メッセージを生成し、ストリーミングクライアントにまたは互いに送り得る。異なるクライアント、プレーヤ、デバイスおよびネットワークにわたる性能が監視および比較され得る。リアルタイムでまたはオフラインで問題はデバッグされ得、障害は隔離され得る。

たとえば、サーバおよびネットワーク支援型動的適応ストリーミングオーバーハイパーテキスト転送プロトコル（server and network assisted dynamic adaptive streaming over hypertext transfer protocol）（ＳＡＮＤ）メッセージを介してクライアントからメトリックサーバにビューポートビュー統計が報告され得る。ＶＲデバイスに関係する情報が報告され得る。ビューポート切替えレイテンシ、初期レイテンシおよび整定レイテンシなどの１つまたは複数のレイテンシパラメータが、ストリーミングクライアントによって測定され、報告され得る。ヘッドマウントデバイス（ＨＭＤ）の精度および感度が測定され、オリジンサーバ、コンテンツ配信ネットワークサーバ、およびクライアントまたはメトリックサーバなどのネットワーク要素の間で交換され得る。ＳＡＮＤメッセージを介してＶＲデバイスに初期レンダリング配向情報が送られ得る。

本明細書では動的適応ストリーミングオーバーハイパーテキスト転送プロトコル（dynamic adaptive streaming over hypertext transfer protocol）（ＤＡＳＨ）の用語を使用してシステム、方法、および手段について説明されるが、当業者は、それらが他のストリーミング規格および実装に適用されることを諒解されよう。

メディアコンテンツを受信し表示するためのデバイスが、第１のビューポートを表示し得る。第１のビューポートは、１つまたは複数の動的適応ストリーミングオーバーＨＴＴＰ（ＤＡＳＨ）ビデオセグメントの少なくとも一部分から作り上げられ得る。第１のビューポートは第１の品質を有し得る。デバイスは、第１の時間においてデバイスの運動を判定し得る。デバイスの運動は、第１のビューポートの外部へのデバイスの運動、デバイスの配向変化、またはズーム動作のうちの１つまたは複数を含み得る。デバイスは、１つまたは複数のビューポート切替えパラメータの変化がしきい値以上であるとき、デバイスの運動を検出し得る。ビューポート切替えパラメータは、たとえば、ｃｅｎｔｒｅ＿ａｚｉｍｕｔｈ、ｃｅｎｔｒｅ＿ｅｌｅｖａｔｉｏｎ、ｃｅｎｔｒｅ＿ｔｉｌｔ、ａｚｉｍｕｔｈ＿ｒａｎｇｅ、およびｅｌｅｖａｔｉｏｎ＿ｒａｎｇｅのうちの１つまたは複数を含み得る。

デバイスは第２のビューポートを表示し得る。第２のビューポートは、第２の時間において１つまたは複数のＤＡＳＨビデオセグメントの少なくとも一部分から作り上げられ得る。第２のビューポートは、第１の品質より低い第２の品質を有し得る。代替として、第２のビューポートは、第１の品質以上である第２の品質を有し得る。デバイスは、第１の時間および第２の時間に基づいてビューポート切替えレイテンシメトリックを判定し、ビューポート切替えレイテンシメトリックを送り得る。

デバイスは第３のビューポートを表示し得る。第３のビューポートは、第３の時間において１つまたは複数のＤＡＳＨビデオセグメントの少なくとも一部分から作り上げられ得る。第３のビューポートは、第２の品質より高い第３の品質を有し得る。第３の品質は、第１の品質以上であり得るか、または第３の品質は、品質しきい値以上であるが、第１の品質未満であり得る。一例では、第１の品質と第３の品質との間の絶対差は、品質しきい値以下であり得る。各ＤＡＳＨビデオセグメントは、それぞれの品質を有し得る。デバイスは、それぞれのビューポートを作り上げるために使用される１つまたは複数のＤＡＳＨビデオセグメントの相対的部分およびそれぞれの品質に基づいて第１、第２、または第３の品質を判定し得る。たとえば、デバイスは、ビューポートを作り上げるために使用される１つまたは複数のＤＡＳＨビデオセグメントの各々のそれぞれの品質の平均、最大値、最小値、または加重平均を使用してビューポートの品質を判定し得る。デバイスは、第１の時間と第３の時間との間の差に基づいて品質ビューポート切替えレイテンシメトリックを判定し、品質ビューポート切替えレイテンシメトリックを送り得る。

デバイスは、ビューポートロスと、そのビューポートロスが、表示された第１のビューポート、表示された第２のビューポート、または表示された第３のビューポートのうちの少なくとも１つに影響を及ぼすかどうかとを判定し得る。デバイスは、たとえば、ビューポートロスが、表示された第１のビューポート、表示された第２のビューポート、または表示された第３のビューポートのうちの少なくとも１つに影響を及ぼすという条件に基づいて、ビューポートロスに関連する情報を判定し得る。ビューポートロスに関連する情報は、ビューポートロスの理由、およびビューポートロスに関連するＤＡＳＨビデオセグメントを含み得る。デバイスは、ビューポートロスに関連する情報を示すビューポートロスメトリックを送り得る。ビューポートロスに関連する情報は、ビューポートロスが判定された時間、パケットのソースＵＲＬ、およびビューポートロスのエラータイプのうちの１つまたは複数を含み得る。ビューポートロスの理由は、サーバエラー、クライアントエラー、パケットロス、パケットエラー、またはパケット廃棄のうちの１つを含み得る。

デバイスは、様々なビューポートおよび品質に関連付けられたＤＡＳＨビデオセグメントのセットを要求し得る。デバイスはＤＡＳＨビデオセグメントを表示し得る。デバイスは、ＤＡＳＨビデオセグメントの表示と、デバイスが運動し始めること、デバイスが運動するのを中止すること、デバイスが運動し始めたとデバイスが判定すること、デバイスが運動するのを停止したとデバイスが判定すること、または異なるＤＡＳＨビデオセグメントの表示のうちの１つとの間の時間差に基づいてレイテンシメトリックを判定し得る。異なるＤＡＳＨビデオセグメントは、異なる品質および／または異なるビューポートに関連付けられ得る。

メディアコンテンツを受信し表示するためのデバイスが、第１の時間において第１のビューポートを表示し得る。第１のビューポートは、１つまたは複数のＤＡＳＨビデオセグメントの少なくとも一部分を含み得る。第１のビューポートは第１の品質を有し得る。デバイスは、第２の時間においてデバイスの運動を検出し得る。デバイスは、デバイスが第２のビューポートに関連付けられた第３の時間においてデバイスが運動するのを停止したと判定し得る。デバイスは、第４の時間において第２のビューポートを表示し得る。第２のビューポートは、１つまたは複数のＤＡＳＨビデオセグメントの少なくとも一部分を含み得る。第２のビューポートは第２の品質に関連付けられ得る。デバイスは、第５の時間において第３のビューポートを表示し得る。第３のビューポートは、１つまたは複数のＤＡＳＨビデオセグメントの少なくとも一部分を含み得る。第３のビューポートは、第２の品質より高い第３の品質に関連付けられ得る。第３の品質は、第１の品質以上であり得るか、または第３の品質は、品質しきい値より高いが、第１の品質未満であり得る。デバイスは、第１、第２、第３、第４、および第５の時間のうちの２つ以上の間の時間差に基づいてレイテンシメトリックを判定し、送る。

１つまたは複数の開示される実施形態が実装され得る例示的な通信システムを示すシステム図である。 一実施形態による図１Ａに示されている通信システム内で使用され得る例示的なワイヤレス送受信ユニット（ＷＴＲＵ）を示すシステム図である。 一実施形態による図１Ａに示されている通信システム内で使用され得る例示的な無線アクセスネットワーク（ＲＡＮ）および例示的なコアネットワーク（ＣＮ）を示すシステム図である。 一実施形態による図１Ａに示されている通信システム内で使用され得るさらなる例示的なＲＡＮおよびさらなる例示的なＣＮを示すシステム図である。 ヘッドマウントデバイス（ＨＭＤ）上に表示された３６０°ビデオの例示的な部分を示す図である。 ３６０°ビデオの例示的なエクイレクタングラー投影を示す図である。 例示的な３６０°ビデオマッピングを示す図である。 例示的なメディアプレゼンテーション記述（ＭＰＤ）階層データモデルを示す図である。 ネットワーク要素とクライアントとの間で交換されるＳＡＮＤメッセージの一例を示す図である。 ＶＲメトリッククライアント参照モデルの一例を示す図である。 ３Ｄ動き追跡範囲の一例を示す図である。 複数のセンサーを用いた２Ｄ動き追跡交差範囲の一例を示す図である。 ビューポート切替えイベントの一例を示す図である。 ３６０°ビデオズーム動作の一例を示す図である。 サブピクチャ事例の加重ビューポート品質の一例を示す図である。 領域的品質ランキング（region-wise quality ranking）（ＲＷＱＲ）符号化事例の加重ビューポート品質の一例を示す図である。 等品質ビューポート切替えイベントの一例を示す図である。 ３６０°ビデオズーム例の一例を示す図である。 レイテンシ間隔の一例を示す図である。 ＤＡＮＥとＤＡＳＨクライアントとの間またはＤＡＳＨクライアントとメトリックサーバとの間のＳＡＮＤメッセージのメッセージフローの一例を示す図である。

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

図１Ａに示されているように、通信システム１００は、ワイヤレス送受信ユニット（ＷＴＲＵ）１０２ａ、１０２ｂ、１０２ｃ、１０２ｄ、ＲＡＮ１０４／１１３、ＣＮ１０６／１１５、公衆交換電話ネットワーク（ＰＳＴＮ）１０８、インターネット１１０、および他のネットワーク１１２を含み得るが、開示される実施形態は、任意の数のＷＴＲＵ、基地局、ネットワーク、および／またはネットワーク要素を企図することが諒解されよう。ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄの各々は、ワイヤレス環境において動作および／または通信するように構成された任意のタイプのデバイスであり得る。例として、「局」および／または「ＳＴＡ」といずれも呼ばれることがある、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、ワイヤレス信号を送信および／または受信するように構成されることがあり、ユーザ機器（ＵＥ）、移動局、固定またはモバイル加入者ユニット、サブスクリプションベースのユニット、ページャ、セルラー電話、携帯情報端末（ＰＤＡ）、スマートフォン、ラップトップ、ネットブック、パーソナルコンピュータ、ワイヤレスセンサー、ホットスポットまたはＷｉ－Ｆｉデバイス、モノのインターネット（ＩｏＴ）デバイス、ウォッチまたは他のウェアラブル、ヘッドマウントディスプレイ（ＨＭＤ）、車両、ドローン、医療デバイスおよびアプリケーション（たとえば、遠隔手術）、工業デバイスおよびアプリケーション（たとえば、産業および／または自動処理チェーンコンテキストにおいて動作するロボットおよび／または他のワイヤレスデバイス）、コンシューマーエレクトロニクスデバイス、商用および／または産業ワイヤレスネットワーク上で動作するデバイスなどを含み得る。ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃおよび１０２ｄのいずれも、互換的にＵＥと呼ばれることがある。

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

基地局１１４ａは、基地局コントローラ（ＢＳＣ）、無線ネットワークコントローラ（ＲＮＣ）、リレーノードなど、他の基地局および／またはネットワーク要素（図示せず）をも含み得る、ＲＡＮ１０４／１１３の一部であり得る。基地局１１４ａおよび／または基地局１１４ｂは、セル（図示せず）と呼ばれることがある１つまたは複数のキャリア周波数上でワイヤレス信号を送信および／または受信するように構成され得る。これらの周波数は、認可スペクトル、無認可スペクトル、または認可スペクトルと無認可スペクトルの合成であり得る。セルは、比較的固定であり得るかまたは時間とともに変化し得る特定の地理的エリアにワイヤレスサービスのカバレージを提供し得る。セルは、セルセクタにさらに分割され得る。たとえば、基地局１１４ａに関連するセルは、３つのセクタに分割され得る。したがって、一実施形態では、基地局１１４ａは、３つのトランシーバを含むことがあり、すなわち、セルのセクタごとに１つを含むことがある。一実施形態では、基地局１１４ａは、多入力多出力（ＭＩＭＯ）技術を採用することがあり、セルのセクタごとに複数のトランシーバを利用することがある。たとえば、所望の空間方向に信号を送信および／または受信するためにビームフォーミングが使用されることがある。

基地局１１４ａ、１１４ｂは、任意の好適なワイヤレス通信リンク（たとえば、無線周波数（ＲＦ）、マイクロ波、センチメートル波、マイクロメートル波、赤外線（ＩＲ）、紫外（ＵＶ）、可視光など）であり得るエアインターフェース１１６を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのうちの１つまたは複数と通信し得る。エアインターフェース１１６は、任意の好適な無線アクセス技術（ＲＡＴ）を使用して確立され得る。

より詳細には、上述されたように、通信システム１００は、多元接続システムであることがあり、ＣＤＭＡ、ＴＤＭＡ、ＦＤＭＡ、ＯＦＤＭＡ、ＳＣ－ＦＤＭＡなど、１つまたは複数のチャネルアクセス方式を採用し得る。たとえば、ＲＡＮ１０４／１１３中の基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、広帯域ＣＤＭＡ（ＷＣＤＭＡ）を使用してエアインターフェース１１５／１１６／１１７を確立し得る、ユニバーサルモバイルテレコミュニケーションズシステム（ＵＭＴＳ）地上波無線アクセス（ＵＴＲＡ）などの無線技術を実装し得る。ＷＣＤＭＡは、高速パケットアクセス（ＨＳＰＡ）および／または発展型ＨＳＰＡ（ＨＳＰＡ＋）などの通信プロトコルを含み得る。ＨＳＰＡは、高速ダウンリンク（ＤＬ）パケットアクセス（ＨＳＤＰＡ）および／または高速ＵＬパケットアクセス（ＨＳＵＰＡ）を含み得る。

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

一実施形態では、基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、新無線（New Radio）（ＮＲ）を使用してエアインターフェース１１６を確立し得る、ＮＲ無線アクセスなどの無線技術を実装し得る。

一実施形態では、基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、複数の無線アクセス技術を実装し得る。たとえば、基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、たとえばデュアル接続性（ＤＣ）原理を使用して、ＬＴＥ無線アクセスとＮＲ無線アクセスを一緒に実装し得る。このように、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃによって利用されるエアインターフェースは、複数のタイプの無線アクセス技術、ならびに／または複数のタイプの基地局（たとえば、ｅＮＢおよびｇＮＢ）に／から送られる送信によって特徴づけられ得る。

他の実施形態では、基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ＩＥＥＥ８０２．１１（すなわち、ワイヤレスフィデリティ（ＷｉＦｉ））、ＩＥＥＥ８０２．１６（すなわち、ワールドワイドインターオペラビリティフォーマイクロウェーブアクセス（ＷｉＭＡＸ））、ＣＤＭＡ２０００、ＣＤＭＡ２０００ １ｘ、ＣＤＭＡ２０００ ＥＶ－ＤＯ、インタリム規格２０００（ＩＳ－２０００）、インタリム規格９５（ＩＳ－９５）、インタリム規格８５６（ＩＳ－８５６）、モバイル通信用グローバルシステム（ＧＳＭ）、ＧＳＭ発展型高速データレート（ＥＤＧＥ）、ＧＳＭ ＥＤＧＥ（ＧＥＲＡＮ）などの無線技術を実装し得る。

図１Ａの基地局１１４ｂは、たとえば、ワイヤレスルータ、ホームノードＢ、ホームｅノードＢ、またはアクセスポイントであってよく、ビジネス、ホーム、車両、キャンパス、工業設備、（たとえば、ドローンが使用するための）空中回廊、道路の場所などの局在化エリアにおいてワイヤレス接続性を促進するために任意の好適なＲＡＴを利用し得る。一実施形態では、基地局１１４ｂおよびＷＴＲＵ１０２ｃ、１０２ｄは、ワイヤレスローカルエリアネットワーク（ＷＬＡＮ）を確立するためにＩＥＥＥ８０２．１１などの無線技術を実装し得る。一実施形態では、基地局１１４ｂおよびＷＴＲＵ１０２ｃ、１０２ｄは、ワイヤレスパーソナルエリアネットワーク（ＷＰＡＮ）を確立するためにＩＥＥＥ８０２．１５などの無線技術を実装し得る。また別の実施形態では、基地局１１４ｂおよびＷＴＲＵ１０２ｃ、１０２ｄは、ピコセルまたはフェムトセルを確立するためにセルラーベースのＲＡＴ（たとえば、ＷＣＤＭＡ、ＣＤＭＡ２０００、ＧＳＭ、ＬＴＥ、ＬＴＥ－Ａ、ＬＴＥ－Ａプロ、ＮＲなど）を利用し得る。図１Ａに示されているように、基地局１１４ｂは、インターネット１１０への直接接続を有し得る。したがって、基地局１１４ｂは、ＣＮ１０６／１１５を介してインターネット１１０にアクセスする必要がないことがある。

ＲＡＮ１０４／１１３はＣＮ１０６／１１５と通信していることがあり、ＣＮ１０６／１１５は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのうちの１つまたは複数に音声、データ、アプリケーション、および／またはボイスオーバーインターネットプロトコル（ＶｏＩＰ）サービスを提供するように構成された任意のタイプのネットワークであり得る。データは、異なるスループット要件、レイテンシ要件、エラー許容要件、信頼性要件、データスループット要件、モビリティ要件など、様々なサービス品質（ＱｏＳ）要件を有することがある。ＣＮ１０６／１１５は、呼制御、課金サービス、モバイルロケーションベースのサービス、プリペイド発呼、インターネット接続性、ビデオ配信などを提供し、および／またはユーザ認証などの高レベルセキュリティ機能を実施し得る。図１Ａには示されていないが、ＲＡＮ１０４／１１３および／またはＣＮ１０６／１１５は、ＲＡＮ１０４／１１３と同じＲＡＴまたは異なるＲＡＴを採用する他のＲＡＮと直接または間接通信していることがあることが諒解されよう。たとえば、ＮＲ無線技術を利用していることがあるＲＡＮ１０４／１１３に接続されていることに加えて、ＣＮ１０６／１１５は、ＧＳＭ、ＵＭＴＳ、ＣＤＭＡ２０００、ＷｉＭＡＸ、Ｅ－ＵＴＲＡ、またはＷｉＦｉ無線技術を採用する別のＲＡＮ（図示せず）とも通信していることがある。

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

通信システム１００中のＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄの一部または全部はマルチモード能力を含み得る（たとえば、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、異なるワイヤレスリンクを介して異なるワイヤレスネットワークと通信するための複数のトランシーバを含み得る）。たとえば、図１Ａに示されているＷＴＲＵ１０２ｃは、セルラーベースの無線技術を採用し得る基地局１１４ａ、およびＩＥＥＥ８０２無線技術を採用し得る基地局１１４ｂと通信するように構成され得る。

図１Ｂは、例示的なＷＴＲＵ１０２を示すシステム図である。図１Ｂに示されているように、ＷＴＲＵ１０２は、特に、プロセッサ１１８、トランシーバ１２０、送受信要素１２２、スピーカー／マイクロフォン１２４、キーパッド１２６、ディスプレイ／タッチパッド１２８、非リムーバブルメモリ１３０、リムーバブルメモリ１３２、電源１３４、全地球測位システム（ＧＰＳ）チップセット１３６、および／または他の周辺機器１３８を含み得る。ＷＴＲＵ１０２は、実施形態に合致したままでありながら、上記の要素のどんな部分組合せでも含み得ることが諒解されよう。

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

送受信要素１２２は、エアインターフェース１１６を介して基地局（たとえば、基地局１１４ａ）に信号を送信するか、またはそれから信号を受信するように構成され得る。たとえば、一実施形態では、送受信要素１２２は、ＲＦ信号を送信および／または受信するように構成されたアンテナであり得る。一実施形態では、送受信要素１２２は、たとえば、ＩＲ、ＵＶ、または可視光信号を送信および／または受信するように構成された放出器／検出器であり得る。また別の実施形態では、送受信要素１２２は、ＲＦ信号と光信号の両方を送信および／または受信するように構成され得る。送受信要素１２２は、ワイヤレス信号のどんな合成でも送信および／または受信するように構成され得ることが諒解されよう。

送受信要素１２２は図１Ｂでは単一の要素として図示されているが、ＷＴＲＵ１０２は、任意の数の送受信要素１２２を含み得る。より詳細には、ＷＴＲＵ１０２はＭＩＭＯ技術を採用し得る。このように、一実施形態では、ＷＴＲＵ１０２は、エアインターフェース１１６を介してワイヤレス信号を送信および受信するために２つ以上の送受信要素１２２（たとえば、複数のアンテナ）を含み得る。

トランシーバ１２０は、送受信要素１２２によって送信されるべき信号を変調するように、および送受信要素１２２によって受信された信号を復調するように構成され得る。上述されたように、ＷＴＲＵ１０２はマルチモード能力を有し得る。したがって、トランシーバ１２０は、ＷＴＲＵ１０２が、たとえば、ＮＲおよびＩＥＥＥ８０２．１１など、複数のＲＡＴを介して通信することを可能にするための複数のトランシーバを含み得る。

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

プロセッサ１１８は、電源１３４から電力を受け取ることがあり、ＷＴＲＵ１０２中の他の構成要素への電力を分配および／または制御するように構成され得る。電源１３４は、ＷＴＲＵ１０２に電力供給するための任意の好適なデバイスであり得る。たとえば、電源１３４は、１つまたは複数の乾電池バッテリー（たとえば、ニッケルカドミウム（ＮｉＣｄ）、ニッケル亜鉛（ＮｉＺｎ）、ニッケル金属水素化物（ＮｉＭＨ）、リチウムイオン（Ｌｉイオン）など）、太陽電池、燃料電池などを含み得る。

プロセッサ１１８はＧＰＳチップセット１３６に結合されることもあり、ＧＰＳチップセット１３６は、ＷＴＲＵ１０２の現在ロケーションに関するロケーション情報（たとえば、経度および緯度）を提供するように構成され得る。ＧＰＳチップセット１３６からの情報に加えて、または、それの代わりに、ＷＴＲＵ１０２は、基地局（たとえば、基地局１１４ａ、１１４ｂ）からエアインターフェース１１６を介してロケーション情報を受信し、および／または２つ以上の近くの基地局から受信されている信号のタイミングに基づいてそれのロケーションを判定し得る。ＷＴＲＵ１０２は、実施形態に合致したままでありながら、任意の好適なロケーション判定方法を介してロケーション情報を収集し得ることが諒解されよう。

プロセッサ１１８は他の周辺機器１３８にさらに結合されることがあり、他の周辺機器１３８は、追加の特徴、機能および／またはワイヤードもしくはワイヤレス接続性を提供する１つまたは複数のソフトウェアおよび／またはハードウェアモジュールを含み得る。たとえば、周辺機器１３８は、加速度計、電子コンパス、衛星トランシーバ、（写真および／またはビデオ用の）デジタルカメラ、ユニバーサルシリアルバス（ＵＳＢ）ポート、振動デバイス、テレビジョントランシーバ、ハンズフリーヘッドセット、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール、周波数変調（ＦＭ）無線ユニット、デジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザ、バーチャルリアリティおよび／または拡張現実（ＶＲ／ＡＲ）デバイス、アクティビティトラッカーなどを含み得る。周辺機器１３８は１つまたは複数のセンサーを含むことがあり、センサーは、ジャイロスコープ、加速度計、ホール効果センサー、磁力計、配向センサー、近接センサー、温度センサー、時間センサー、ジオロケーションセンサー、高度計、光センサー、タッチセンサー、磁力計、気圧計、ジェスチャーセンサー、生体センサー、および／または湿度センサーのうちの１つまたは複数であり得る。

ＷＴＲＵ１０２は、（たとえば、（たとえば、送信用の）ＵＬと（たとえば、受信用の）ダウンリンクの両方について特定のサブフレームに関連する）信号の一部または全部の送信と受信がコンカレントおよび／または同時であり得る、全二重無線機を含み得る。全二重無線機は、ハードウェア（たとえば、チョーク）か、またはプロセッサを介した（たとえば、別個のプロセッサ（図示せず）もしくはプロセッサ１１８を介した）信号処理のいずれかを介して自己干渉を低減しおよびまたは実質的になくすための干渉管理ユニットを含み得る。一実施形態では、ＷＴＲＵ１０２は、（たとえば、（たとえば、送信用の）ＵＬまたは（たとえば、受信用の）ダウンリンクのいずれかについて特定のサブフレームに関連付けられた）信号の一部または全部の送信と受信について、半二重無線機を含み得る。

図１Ｃは、一実施形態によるＲＡＮ１０４およびＣＮ１０６を示すシステム図である。上述されたように、ＲＡＮ１０４は、エアインターフェース１１６を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するためにＥ－ＵＴＲＡ無線技術を採用し得る。ＲＡＮ１０４はＣＮ１０６と通信していることもある。

ＲＡＮ１０４はｅノードＢ１６０ａ、１６０ｂ、１６０ｃを含み得るが、ＲＡＮ１０４は、実施形態に合致したままでありながら、任意の数のｅノードＢを含み得ることが諒解されよう。ｅノードＢ１６０ａ、１６０ｂ、１６０ｃは、エアインターフェース１１６を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するための１つまたは複数のトランシーバをそれぞれ含み得る。一実施形態では、ｅノードＢ１６０ａ、１６０ｂ、１６０ｃはＭＩＭＯ技術を実装し得る。このようにして、たとえば、ｅノードＢ１６０ａは、複数のアンテナを使用して、ＷＴＲＵ１０２ａにワイヤレス信号を送信し、および／またはそれからワイヤレス信号を受信し得る。

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

図１Ｃに示されているＣＮ１０６は、モビリティ管理エンティティ（ＭＭＥ）１６２、サービングゲートウェイ（ＳＧＷ）１６４、およびパケットデータネットワーク（ＰＤＮ）ゲートウェイ（またはＰＧＷ）１６６を含み得る。上記の要素の各々はＣＮ１０６の一部として図示されているが、これらの要素のいずれも、ＣＮ事業者以外のエンティティによって所有および／または動作され得ることが諒解されよう。

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

ＳＧＷ１６４は、Ｓ１インターフェースを介してＲＡＮ１０４中のｅノードＢ１６０ａ、１６０ｂ、１６０ｃの各々に接続され得る。ＳＧＷ１６４は、概して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに／からユーザデータパケットをルーティングおよびフォワーディングし得る。ＳＧＷ１６４は、ｅノードＢ間ハンドオーバ中にユーザプレーンをアンカリングすること、ＤＬデータがＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのために利用可能であるときページングをトリガリングすること、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのコンテキストを管理し記憶することなど、他の機能を実施し得る。

ＳＧＷ１６４はＰＧＷ１６６に接続されることがあり、ＰＧＷ１６６は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとＩＰ対応デバイスとの間の通信を促進するために、インターネット１１０などのパケット交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供し得る。

ＣＮ１０６は、他のネットワークと通信を促進し得る。たとえば、ＣＮ１０６は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと従来のランドライン通信デバイスとの間の通信を促進するために、ＰＳＴＮ１０８などの回線交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供し得る。たとえば、ＣＮ１０６は、ＣＮ１０６とＰＳＴＮ１０８との間のインターフェースとして働くＩＰゲートウェイ（たとえば、ＩＰマルチメディアサブシステム（ＩＭＳ）サーバ）を含むか、またはそれと通信し得る。加えて、ＣＮ１０６は、他のサービスプロバイダによって所有および／または動作される他のワイヤードおよび／またはワイヤレスネットワークを含み得る他のネットワーク１１２へのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供し得る。

ＷＴＲＵは図１Ａ～図１Ｄではワイヤレス端末として記載されているが、いくつかの代表的な実施形態では、そのような端末は、通信ネットワークとのワイヤード通信インターフェースを（たとえば、一時的または永続的に）使用し得ることが企図される。

代表的な実施形態では、他のネットワーク１１２はＷＬＡＮであり得る。

インフラストラクチャ基本サービスセット（ＢＳＳ）モードにおけるＷＬＡＮは、ＢＳＳのためのアクセスポイント（ＡＰ）と、ＡＰに関連する１つまたは複数の局（ＳＴＡ）とを有し得る。ＡＰは、ＢＳＳ中におよび／またはそれからトラフィックを搬送する配信システム（ＤＳ）または別のタイプのワイヤード／ワイヤレスネットワークへのアクセスまたはインターフェースを有し得る。ＢＳＳの外部から発信した、ＳＴＡへのトラフィックは、ＡＰを介して到着することがあり、ＳＴＡに配信され得る。ＳＴＡから発信した、ＢＳＳ外の宛先へのトラフィックは、それぞれの宛先に配信されるべきＡＰに送られ得る。ＢＳＳ内のＳＴＡ間のトラフィックはＡＰを介して送られることがあり、たとえば、ソースＳＴＡはＡＰにトラフィックを送ることがあり、ＡＰは宛先ＳＴＡにトラフィックを配信することがある。ＢＳＳ内のＳＴＡ間のトラフィックは、ピアツーピアトラフィックと見なされるおよび／または呼ばれることがある。ピアツーピアトラフィックは、直接リンクセットアップ（ＤＬＳ）を用いてソースＳＴＡと宛先ＳＴＡとの間で（たとえば、それらの間で直接）送られ得る。いくつかの代表的な実施形態では、ＤＬＳは、８０２．１１ｅ ＤＬＳまたは８０２．１１ｚトンネルドＤＬＳ（ＴＤＬＳ）を使用し得る。独立ＢＳＳ（ＩＢＳＳ）モードを使用しているＷＬＡＮはＡＰを有しないことがあり、ＩＢＳＳ内にあるかまたはＩＢＳＳを使用しているＳＴＡ（たとえば、ＳＴＡのすべて）は互いに直接通信し得る。ＩＢＳＳ通信モードは、本明細書では「アドホック」通信モードと時々呼ばれることがある。

８０２．１１ａｃインフラストラクチャ動作モードまたは同様の動作モードを使用しているとき、ＡＰは、１次チャネルなどの固定チャネル上でビーコンを送信し得る。１次チャネルは、固定幅（たとえば、２０ＭＨｚ幅の帯域幅）であるか、またはシグナリングを介した動的に設定される幅であり得る。１次チャネルは、ＢＳＳの動作チャネルであることがあり、ＡＰとの接続を確立するためにＳＴＡによって使用され得る。いくつかの代表的な実施形態では、たとえば８０２．１１システムでは、キャリア検知多重アクセス／衝突回避（ＣＳＭＡ／ＣＡ）が実装され得る。ＣＳＭＡ／ＣＡのために、ＡＰを含むＳＴＡ（たとえば、あらゆるＳＴＡ）は、１次チャネルを検知し得る。特定のＳＴＡによって１次チャネルが検知／検出されおよび／またはビジーであると判定された場合、その特定のＳＴＡはバックオフし得る。所与のＢＳＳにおいて所与の時間に１つのＳＴＡ（たとえば、ただ１つの局）が送信し得る。

高スループット（ＨＴ）ＳＴＡは、たとえば、４０ＭＨｚワイドチャネルを形成するために１次２０ＭＨｚチャネルを隣接するかまたは隣接しない２０ＭＨｚチャネルと合成することを介して、通信のために４０ＭＨｚワイドチャネルを使用することがある。

超高スループット（ＶＨＴ）ＳＴＡは、２０ＭＨｚ、４０ＭＨｚ、８０ＭＨｚ、および／または１６０ＭＨｚワイドチャネルをサポートし得る。４０ＭＨｚおよび／または８０ＭＨｚチャネルは、連続する２０ＭＨｚチャネルを合成することによって形成され得る。１６０ＭＨｚチャネルは、８つの連続する２０ＭＨｚチャネルを合成することによって、または２つの不連続の８０ＭＨｚチャネルを合成することによって形成されることがあり、これは８０＋８０構成と呼ばれることがある。８０＋８０構成では、チャネル符号化の後のデータは、セグメントパーサを通過されることがあり、セグメントパーサは、データを２つのストリームに分割し得る。逆高速フーリエ変換（ＩＦＦＴ）処理、および時間領域処理が、各ストリーム上で別々に行われ得る。ストリームは、２つの８０ＭＨｚチャネル上にマッピングされることがあり、データは送信側ＳＴＡによって送信され得る。受信側ＳＴＡの受信機では、８０＋８０構成についての上記で説明された動作は反転されることがあり、合成されたデータはメディアアクセス制御（ＭＡＣ）に送られ得る。

８０２．１１ａｆおよび８０２．１１ａｈによってサブ１ＧＨｚ動作モードがサポートされる。チャネル動作帯域幅、およびキャリアは、８０２．１１ａｆおよび８０２．１１ａｈでは、８０２．１１ｎおよび８０２．１１ａｃにおいて使用されるものに対して低減される。８０２．１１ａｆは、ＴＶホワイトスペース（ＴＶＷＳ）スペクトルにおいて５ＭＨｚ、１０ＭＨｚおよび２０ＭＨｚ帯域幅をサポートし、８０２．１１ａｈは、非ＴＶＷＳスペクトルを使用して１ＭＨｚ、２ＭＨｚ、４ＭＨｚ、８ＭＨｚ、および１６ＭＨｚ帯域幅をサポートする。代表的な実施形態によれば、８０２．１１ａｈは、マクロカバレージエリアにおけるＭＴＣデバイスなど、メータータイプ制御／マシンタイプ通信をサポートし得る。ＭＴＣデバイスは、いくつかの能力、たとえば、いくつかのおよび／または限られた帯域幅のサポート（たとえば、それのサポートのみ）を含む限られた能力を有することがある。ＭＴＣデバイスは、（たとえば、極めて長いバッテリー寿命を維持するために）しきい値を上回るバッテリー寿命をもつバッテリーを含むことがある。

８０２．１１ｎ、８０２．１１ａｃ、８０２．１１ａｆ、および８０２．１１ａｈなど、複数のチャネル、およびチャネル帯域幅をサポートし得るＷＬＡＮシステムは、１次チャネルと称されることがあるチャネルを含む。１次チャネルは、ＢＳＳ中のすべてのＳＴＡによってサポートされる最大の共通動作帯域幅に等しい帯域幅を有することがある。１次チャネルの帯域幅は、ＢＳＳ中で動作しているすべてのＳＴＡのうち、最小の帯域幅動作モードをサポートするＳＴＡによって設定および／または限定され得る。８０２．１１ａｈの例では、ＢＳＳ中のＡＰおよび他のＳＴＡが、２ＭＨｚ、４ＭＨｚ、８ＭＨｚ、１６ＭＨｚ、および／または他のチャネル帯域幅動作モードをサポートする場合でも、１次チャネルは、１ＭＨｚモードをサポートする（たとえば、それのみをサポートする）ＳＴＡ（たとえば、ＭＴＣタイプデバイス）のために１ＭＨｚワイドであり得る。キャリア検知および／またはネットワーク割振りベクトル（ＮＡＶ）設定は、１次チャネルのステータスに依存することがある。たとえば、ＡＰに送信している（１ＭＨｚ動作モードのみをサポートする）ＳＴＡにより、１次チャネルがビジーである場合、利用可能な周波数帯域全体は、周波数帯域の大部分がアイドルなままで利用可能であり得ても、ビジーであると見なされることがある。

米国では、８０２．１１ａｈによって使用され得る利用可能な周波数帯域は、９０２ＭＨｚから９２８ＭＨｚである。韓国では、利用可能な周波数帯域は９１７．５ＭＨｚから９２３．５ＭＨｚである。日本では、利用可能な周波数帯域は９１６．５ＭＨｚから９２７．５ＭＨｚである。８０２．１１ａｈのために利用可能な総帯域幅は、国コードに応じて６ＭＨｚから２６ＭＨｚである。

図１Ｄは、一実施形態によるＲＡＮ１１３およびＣＮ１１５を示すシステム図である。上述されたように、ＲＡＮ１１３は、エアインターフェース１１６を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するためにＮＲ無線技術を採用し得る。ＲＡＮ１１３はＣＮ１１５と通信していることもある。

ＲＡＮ１１３はｇＮＢ１８０ａ、１８０ｂ、１８０ｃを含み得るが、ＲＡＮ１１３は、実施形態に合致したままでありながら、任意の数のｇＮＢを含み得ることが諒解されよう。ｇＮＢ１８０ａ、１８０ｂ、１８０ｃは、エアインターフェース１１６を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するための１つまたは複数のトランシーバをそれぞれ含み得る。一実施形態では、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃはＭＩＭＯ技術を実装し得る。たとえば、ｇＮＢ１８０ａ、１０８ｂは、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃに信号を送信しおよび／またはそれらから信号を受信するためにビームフォーミングを利用し得る。このようにして、たとえば、ｇＮＢ１８０ａは、複数のアンテナを使用して、ＷＴＲＵ１０２ａにワイヤレス信号を送信し、および／またはそれからワイヤレス信号を受信し得る。一実施形態では、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃはキャリアアグリゲーション技術を実装し得る。たとえば、ｇＮＢ１８０ａは、ＷＴＲＵ１０２ａ（図示せず）に複数のコンポーネントキャリアを送信し得る。これらのコンポーネントキャリアのサブセットは無認可スペクトル上にあり得るが、残りのコンポーネントキャリアは認可スペクトル上にあり得る。一実施形態では、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃは協調マルチポイント（ＣｏＭＰ）技術を実装し得る。たとえば、ＷＴＲＵ１０２ａは、ｇＮＢ１８０ａおよびｇＮＢ１８０ｂ（および／またはｇＮＢ１８０ｃ）から協調送信を受信し得る。

ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、スケーラブルな数秘学に関連する送信を使用してｇＮＢ１８０ａ、１８０ｂ、１８０ｃと通信し得る。たとえば、ＯＦＤＭシンボル離間および／またはＯＦＤＭサブキャリア離間は、異なる送信、異なるセル、および／またはワイヤレス送信スペクトルの異なる部分について変動し得る。ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、（たとえば、変動する数のＯＦＤＭシンボルおよび／または変動する持続長さの絶対時間を含んでいる）様々なまたはスケーラブルな長さのサブフレームまたは送信時間間隔（ＴＴＩ）を使用してｇＮＢ１８０ａ、１８０ｂ、１８０ｃと通信し得る。

ｇＮＢ１８０ａ、１８０ｂ、１８０ｃは、スタンドアロン構成および／または非スタンドアロン構成でＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するように構成され得る。スタンドアロン構成では、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、（たとえば、ｅノードＢ１６０ａ、１６０ｂ、１６０ｃなどの）他のＲＡＮにアクセスすることもなしにｇＮＢ１８０ａ、１８０ｂ、１８０ｃと通信し得る。スタンドアロン構成では、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、モビリティアンカーポイントとしてｇＮＢ１８０ａ、１８０ｂ、１８０ｃのうちの１つまたは複数を利用し得る。スタンドアロン構成では、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、無認可帯域中の信号を使用してｇＮＢ１８０ａ、１８０ｂ、１８０ｃと通信し得る。非スタンドアロン構成では、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ｅノードＢ１６０ａ、１６０ｂ、１６０ｃなどの別のＲＡＮと通信／に接続しながらも、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃと通信／に接続し得る。たとえば、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ＤＣ原理を実装して、１つまたは複数のｇＮＢ１８０ａ、１８０ｂ、１８０ｃおよび１つまたは複数のｅノードＢ１６０ａ、１６０ｂ、１６０ｃと実質的に同時に通信し得る。非スタンドアロン構成では、ｅノードＢ１６０ａ、１６０ｂ、１６０ｃは、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのためのモビリティアンカーとして働くことがあり、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃは、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃをサービスするために追加のカバレージおよび／またはスループットを提供し得る。

ｇＮＢ１８０ａ、１８０ｂ、１８０ｃの各々は、特定のセル（図示せず）に関連付けられることがあり、無線リソース管理決定、ハンドオーバ決定、ＵＬおよび／またはＤＬにおけるユーザのスケジューリング、ネットワークスライシングのサポート、デュアル接続性、ＮＲとＥ－ＵＴＲＡとの間のインターワーキング、ユーザプレーン機能（ＵＰＦ）１８４ａ、１８４ｂのほうへのユーザプレーンデータのルーティング、アクセスおよびモビリティ管理機能（ＡＭＦ）１８２ａ、１８２ｂのほうへの制御プレーン情報のルーティングなどを扱うように構成され得る。図１Ｄに示されているように、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃは、Ｘｎインターフェースを介して互いに通信し得る。

図１Ｄに示されているＣＮ１１５は、少なくとも１つのＡＭＦ１８２ａ、１８２ｂ、少なくとも１つのＵＰＦ１８４ａ、１８４ｂ、少なくとも１つのセッション管理機能（ＳＭＦ）１８３ａ、１８３ｂ、および場合によってはデータネットワーク（ＤＮ）１８５ａ、１８５ｂを含み得る。上記の要素の各々はＣＮ１１５の一部として図示されているが、これらの要素のいずれも、ＣＮ事業者以外のエンティティによって所有および／または動作され得ることが諒解されよう。

ＡＭＦ１８２ａ、１８２ｂは、Ｎ２インターフェースを介してＲＡＮ１１３中のｇＮＢ１８０ａ、１８０ｂ、１８０ｃのうちの１つまたは複数に接続されることがあり、制御ノードとして働き得る。たとえば、ＡＭＦ１８２ａ、１８２ｂは、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのユーザを認証すること、ネットワークスライシングのサポート（たとえば、異なる要件をもつ異なるＰＤＵセッションの扱い）、特定のＳＭＦ１８３ａ、１８３ｂを選択すること、登録エリアの管理、ＮＡＳシグナリングの終了、モビリティ管理などを担当し得る。ネットワークスライシングは、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに利用されているサービスのタイプに基づいてＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのＣＮサポートをカスタマイズするために、ＡＭＦ１８２ａ、１８２ｂによって使用され得る。たとえば、超高信頼低レイテンシ（ＵＲＬＬＣ）アクセスに依拠しているサービス、拡張大容量モバイルブロードバンド（ｅＭＢＢ）アクセスに依拠しているサービス、マシンタイプ通信（ＭＴＣ）アクセスのためのサービスなど、異なる使用事例のために異なるネットワークスライスが確立され得る。ＡＭＦ１８２は、ＲＡＮ１１３と、ＬＴＥ、ＬＴＥ－Ａ、ＬＴＥ－Ａプロ、および／またはＷｉＦｉなどの非３ＧＰＰアクセス技術などの他の無線技術を採用する他のＲＡＮ（図示せず）との間で切り替わるための制御プレーン機能を提供し得る。

ＳＭＦ１８３ａ、１８３ｂは、Ｎ１１インターフェースを介してＣＮ１１５中のＡＭＦ１８２ａ、１８２ｂに接続され得る。ＳＭＦ１８３ａ、１８３ｂはまた、Ｎ４インターフェースを介してＣＮ１１５中のＵＰＦ１８４ａ、１８４ｂに接続され得る。ＳＭＦ１８３ａ、１８３ｂは、ＵＰＦ１８４ａ、１８４ｂを選択し、制御し、ＵＰＦ１８４ａ、１８４ｂを通してトラフィックのルーティングを構成し得る。ＳＭＦ１８３ａ、１８３ｂは、ＵＥ ＩＰアドレスを管理し割り振ること、ＰＤＵセッションを管理すること、ポリシー執行およびＱｏＳを制御すること、ダウンリンクデータ通知を提供することなど、他の機能を実施し得る。ＰＤＵセッションタイプは、ＩＰベース、非ＩＰベース、イーサネットベースなどであり得る。

ＵＰＦ１８４ａ、１８４ｂは、Ｎ３インターフェースを介してＲＡＮ１１３中のｇＮＢ１８０ａ、１８０ｂ、１８０ｃのうちの１つまたは複数に接続されることがあり、それらは、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとＩＰ対応デバイスとの間の通信を促進するために、インターネット１１０などのパケット交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供し得る。ＵＰＦ１８４、１８４ｂは、パケットをルーティングしフォワーディングすること、ユーザプレーンポリシーを執行すること、マルチホームドＰＤＵセッションをサポートすること、ユーザプレーンＱｏＳを扱うこと、ダウンリンクパケットをバッファすること、モビリティアンカリングを提供することなど、他の機能を実施し得る。

ＣＮ１１５は、他のネットワークとの通信を促進し得る。たとえば、ＣＮ１１５は、ＣＮ１１５とＰＳＴＮ１０８との間のインターフェースとして働くＩＰゲートウェイ（たとえば、ＩＰマルチメディアサブシステム（ＩＭＳ）サーバ）を含むか、またはそれと通信し得る。加えて、ＣＮ１１５は、他のサービスプロバイダによって所有および／または動作される他のワイヤードおよび／またはワイヤレスネットワークを含み得る他のネットワーク１１２へのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供し得る。一実施形態では、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ＵＰＦ１８４ａ、１８４ｂへのＮ３インターフェースおよびＵＰＦ１８４ａ、１８４ｂとＤＮ１８５ａ、１８５ｂとの間のＮ６インターフェースを介して、ＵＰＦ１８４ａ、１８４ｂを通してローカルデータネットワーク（ＤＮ）１８５ａ、１８５ｂに接続され得る。

図１Ａ～図１Ｄ、および図１Ａ～図１Ｄの対応する説明に鑑みて、ＷＴＲＵ１０２ａ～ｄ、基地局１１４ａ～ｂ、ｅノードＢ１６０ａ～ｃ、ＭＭＥ１６２、ＳＧＷ１６４、ＰＧＷ１６６、ｇＮＢ１８０ａ～ｃ、ＡＭＦ１８２ａ～ｂ、ＵＰＦ１８４ａ～ｂ、ＳＭＦ１８３ａ～ｂ、ＤＮ１８５ａ～ｂ、および／または本明細書で説明される任意の他のデバイスのうちの１つまたは複数に関して本明細書で説明される機能の１つもしくは複数、またはすべては、１つまたは複数のエミュレーションデバイス（図示せず）によって実施され得る。エミュレーションデバイスは、本明細書で説明される機能の１つもしくは複数、またはすべてをエミュレートするように構成された１つまたは複数のデバイスであり得る。たとえば、エミュレーションデバイスは、他のデバイスをテストするためにならびに／またはネットワークおよび／もしくはＷＴＲＵ機能をシミュレートするために使用され得る。

エミュレーションデバイスは、実験室環境においておよび／または事業者ネットワーク環境において他のデバイスの１つまたは複数のテストを実装するように設計され得る。たとえば、１つまたは複数のエミュレーションデバイスは、ワイヤードおよび／またはワイヤレス通信ネットワーク内で他のデバイスをテストするために通信ネットワークの一部として完全にまたは部分的に実装および／または展開されながら、１つもしくは複数の、またはすべての機能を実施し得る。１つまたは複数のエミュレーションデバイスは、ワイヤードおよび／またはワイヤレス通信ネットワークの一部として一時的に実装／展開されながら、１つもしくは複数の、またはすべての機能を実施し得る。エミュレーションデバイスは、テストのために別のデバイスに直接結合されることがあり、および／またはオーバージエアワイヤレス通信を使用してテストを実施することがある。

１つまたは複数のエミュレーションデバイスは、ワイヤードおよび／またはワイヤレス通信ネットワークの一部として実装／展開されることなしに、すべてを含む１つまたは複数の機能を実施し得る。たとえば、エミュレーションデバイスは、１つまたは複数の構成要素のテストを実装するために、テスト実験室ならびに／または展開されない（たとえば、テスト用）ワイヤードおよび／もしくはワイヤレス通信ネットワークにおけるテストシナリオにおいて利用され得る。１つまたは複数のエミュレーションデバイスはテスト機器であり得る。（たとえば、１つまたは複数のアンテナを含み得る）ＲＦ回路を介した直接ＲＦ結合および／またはワイヤレス通信は、データを送信および／または受信するためにエミュレーションデバイスによって使用され得る。

図２は、ヘッドマウントデバイス（ＨＭＤ）上に表示された３６０°ビデオの例示的な部分を示す。３６０°ビデオを閲覧しているとき、ユーザは、たとえば、図２に示されているように、ビデオの一部を提示され得る。ビデオの一部は、ユーザがビデオの画像を見回すおよび／またはズームするときに変更され得る。ビデオの一部は、ＨＭＤおよび／または他のタイプのユーザインターフェース（たとえば、ワイヤレス送受信ユニット（ＷＴＲＵ））によって提供されるフィードバックに基づいて変化され得る。３６０°ビデオ全体の空間領域はビューポートと呼ばれることがある。ビューポートは、ユーザに完全にまたは部分的に提示され得る。ビューポートは、３６０°ビデオの他の部分とは１つまたは複数の異なる品質を有し得る。

３６０°ビデオは、（たとえば、任意のビューポートを選定するための能力をユーザに与えるために）球体上にキャプチャおよび／またはレンダリングされ得る。球状ビデオフォーマットは、従来のビデオコーデックを使用して直接配信されないことがある。（たとえば、球状ビデオなどの）３６０°ビデオは、投影法を使用して球状ビデオを２Ｄ平面上に投影することによって圧縮され得る。投影された２Ｄビデオは、（たとえば、従来のビデオコーデックを使用して）コーディングされ得る。投影法の一例はエクイレクタングラー投影を含み得る。図３は、３６０°ビデオの例示的なエクイレクタングラー投影を示す。たとえば、エクイレクタングラー投影法は、以下の式のうちの１つまたは複数を使用して、球体上の座標（θ，φ）をもつ第１の点Ｐを２Ｄ平面上の座標（ｕ，ｖ）をもつ第２の点Ｐにマッピングし得る。
ｕ＝φ／（２＊ｐｉ）＋０．５ 式１
ｖ＝０．５－θ／（ｐｉ） 式２

図３は、３６０°ビデオマッピングの例を示す。たとえば、３６０°ビデオを２Ｄプレーナビデオに変換するために（たとえば、代替の、帯域幅要件を低減するために）１つまたは複数の他の投影法（たとえば、マッピング）が使用され得る。たとえば、１つまたは複数の他の投影法は、ピラミッドマップ、キューブマップ、および／またはオフセットキューブマップを含み得る。これらの１つまたは複数の他の投影法は、球状ビデオをより少ないデータで表すために使用され得る。たとえば、キューブマップ投影法は、エクイレクタングラー投影と比較して（たとえば、キューブマップ投影がより少ないワーピングを導入し得るので）２０％少ないピクセルを使用し得る。ピラミッド投影など、これらの１つまたは複数の他の投影法は、（たとえば、投影された２Ｄビデオのサイズを低減するために）閲覧者がおそらく見ない１つまたは複数のピクセルをサブサンプリングし得る。

３６０°ビデオ全体を記憶しおよび／またはサーバとクライアントとの間で配信することの代替としてビューポート固有の表現が使用され得る。図３に示されている投影法のうちの１つまたは複数、たとえば、キューブマップおよび／またはピラミダル投影は、異なるビューポートのために一様でない品質表現を提供し得る（たとえば、いくつかのビューポートは他のビューポートよりも高い品質で表され得る）。異なるターゲットビューポートをもつ同じビデオの複数のバージョンが、（たとえば、球状ビデオのすべてのビューポートをサポートするために）サーバ側において生成および／または記憶される必要があり得る。たとえば、ＶＲビデオ配信のＦａｃｅｂｏｏｋの実装では、図３に示されているオフセットキューブマップフォーマットが使用されることがある。オフセットキューブマップは、フロントビューポートに最も高い解像度（たとえば、最も高い品質）を提供し、バックビューに最も低い解像度（たとえば、最も低い品質）を提供し、１つまたは複数のサイドビューに中間の解像度（たとえば、中間の品質）を提供し得る。サーバは、（たとえば、同じコンテンツの異なるビューポートについてのクライアント要求に適応するために）同じコンテンツの複数のバージョンを記憶し得る。たとえば、同じコンテンツの合計１５０個の異なるバージョン（たとえば、各ビューポートについて３０個のビューポート×５つの解像度）。配信（たとえば、ストリーミング）中に、クライアントは、クライアントの現在のビューポートに対応する特定のバージョンを要求することがある。この特定のバージョンはサーバによって配信され得る。クライアントの現在のビューポートに対応する特定のバージョンを要求するクライアントは、送信帯域幅を節約し得、サーバ上で増加された記憶域要件を含み、および／またはクライアントが第１のビューポートから第２のビューポートに変化する場合／ときのレイテンシを潜在的に増加させ得る。このレイテンシ問題は、そのようなビューポート変化が頻繁であるときはひどくなり得る。

クライアントデバイスは、全方向性メディアフォーマット（ＯＭＡＦ）に従って符号化されたビデオストリームを受信し得る。サブピクチャは、元のコンテンツの空間サブセットを表すピクチャであり得る。サブピクチャビットストリームは、元のコンテンツの空間サブセットを表すビットストリームであり得る。閲覧配向は、ユーザがオーディオビジュアルコンテンツを消費している配向を特徴づける、アジマス、エレベーション、およびチルト角の三つ組であり得る。ビューポートは、ユーザによる表示および閲覧に好適な全方向性画像および／またはビデオの領域であり得る。ビューポイントは、ビューポートの中心点であり得る。コンテンツカバレージは、トラックによってまたは画像項目によって表されるコンテンツによってカバーされる１つまたは複数の球体領域を含み得る。

ＯＭＡＦは、ビューポート非依存ビデオプロファイルおよびビューポート依存ビデオプロファイルを指定し得る。ビューポート非依存ビデオストリーミングでは、３６０°ビデオピクチャはシングルレイヤビットストリームとして符号化され得る。コーディングされたビットストリーム全体がサーバに記憶され、必要な場合、ＯＭＡＦプレーヤに完全に送信され、デコーダによって完全に復号され得る。現在のビューポートに対応する復号されたピクチャのエリアは、ユーザに対してレンダリングされ得る。ビューポート依存ビデオストリーミングでは、ビデオストリーミング手法の１つまたは組合せが利用され得る。ＯＭＡＦプレーヤは、シングルレイヤストリームベースの手法に従って符号化されたビデオを受信し得る。シングルレイヤストリームベースの手法では、複数のシングルレイヤストリームが生成され得る。たとえば、各ストリームは全方向性ビデオ全体を含んでいることがあるが、各ストリームは、領域的品質ランキング（ＲＷＱＲ）メタデータによって示される、異なる高品質符号化された領域をもつことがある。現在のビューポートに応じて、現在のビューポートロケーションのものと一致している、高品質符号化された領域を含んでいるストリームが選択されおよび／またはＯＭＡＦプレーヤに送信され得る。

ＯＭＡＦプレーヤは、サブピクチャストリームベースの手法に従って符号化されたビデオを受信し得る。サブピクチャストリームベースの手法では、３６０°ビデオはサブピクチャシーケンスにスプリットされ得る。（たとえば、各）サブピクチャシーケンスは、全方向性ビデオコンテンツの空間エリアのサブセットをカバーし得る。（たとえば、各）サブピクチャシーケンスは、シングルレイヤビットストリームとして互いに非依存に符号化され得る。ＯＭＡＦプレーヤは、たとえば、ＯＭＡＦプレーヤの配向／ビューポートメタデータに基づいて、ストリーミングされるべきサブピクチャを選択し得る。領域的品質ランキング（ＲＷＱＲ）メタデータによって示される、残りの現在レンダリングされていないエリアをカバーしている品質または解像度と比較して、現在のビューポートでは、より良い品質またはより高い解像度ストリームが受信、復号、および／またはレンダリングされ得る。

ＨＴＴＰストリーミングは商業的展開において支配的手法になった。たとえば、ＡｐｐｌｅのＨＴＴＰ Ｌｉｖｅ Ｓｔｒｅａｍｉｎｇ（ＨＬＳ）、ＭｉｃｒｏｓｏｆｔのＳｍｏｏｔｈ Ｓｔｒｅａｍｉｎｇ（ＳＳ）、および／またはＡｄｏｂｅのＨＴＴＰ Ｄｙｎａｍｉｃ Ｓｔｒｅａｍｉｎｇ（ＨＤＳ）などのストリーミングプラットフォームは、基礎をなす配信方法としてＨＴＴＰストリーミングを使用することがある。マルチメディアコンテンツのＨＴＴＰストリーミングのための規格は、規格ベースのクライアントが、どんな規格ベースのサーバからもコンテンツをストリーミングすることを可能にし得る（たとえば、それにより、異なるベンダーのサーバとクライアントとの間のインターオペラビリティを可能にする）。ＭＰＥＧ動的適応ストリーミングオーバーＨＴＴＰ（ＭＰＥＧ－ＤＡＳＨ）は、変化するネットワーク条件に動的に適応することによって可能な限り最良のビデオエクスペリエンスをエンドユーザに提供するユニバーサル配信フォーマットであり得る。ＤＡＳＨは、ＨＴＴＰ／ＴＣＰ／ＩＰスタックの上に構築され得る。ＤＡＳＨは、ＩＳＯベースメディアファイルフォーマットおよびＭＰＥＧ－２トランスポートストリームのためのマニフェストフォーマット、メディアプレゼンテーション記述（ＭＰＤ）、およびセグメントフォーマットを定義し得る。

動的ＨＴＴＰストリーミングは、サーバにおいて利用可能であるべきマルチメディアコンテンツの様々なビットレート代替を必要とすることがある。マルチメディアコンテンツは、いくつかのメディアコンポーネント（たとえば、オーディオ、ビデオ、テキスト）を含むことがあり、それらの一部または全部は異なる特性を有し得る。ＭＰＥＧ－ＤＡＳＨでは、特性はＭＰＤによって記述され得る。

ＭＰＤは、ストリーミングセッション中に適応様式でＤＡＳＨクライアントが（たとえば、本明細書で説明されるように）ビデオセグメントにアクセスするのに適切なＨＴＴＰ－ＵＲＬを構成するのに必要なメタデータを含むＸＭＬドキュメントであり得る。図５は、例示的なＭＰＤ階層データモデルを示す。ＭＰＤは期間（Period）のシーケンスを記述し得、ここで、メディアコンテンツコンポーネントの符号化バージョンの合致するセットは期間中に変化しない。（たとえば、各）期間は、開始時間および持続時間を有し得る。（たとえば、各）期間は、１つまたは複数の適応セット（たとえば、ＡｄａｐｔａｔｉｏｎＳｅｔ）から組み立てられ得る。ＤＡＳＨストリーミングクライアントは、図８Ａ～図８Ｅに関して本明細書で説明されるＷＴＲＵであり得る。

ＡｄａｐｔａｔｉｏｎＳｅｔは、１つまたは複数の同一のプロパティ（たとえば、言語、メディアタイプ、ピクチャアスペクト比、役割、アクセシビリティ、ビューポイント、および／またはレーティングプロパティなど）を共有している１つまたは複数のメディアコンテンツコンポーネントの符号化バージョンのセットを表し得る。たとえば、第１のＡｄａｐｔａｔｉｏｎＳｅｔは、同じマルチメディアコンテンツのビデオコンポーネントの異なるビットレートを含み得る。第２のＡｄａｐｔａｔｉｏｎＳｅｔは、同じマルチメディアコンテンツのオーディオコンポーネントの異なるビットレート（たとえば、より低品質のステレオおよび／またはより高品質のサラウンド音）を含み得る。（たとえば、各）ＡｄａｐｔａｔｉｏｎＳｅｔは複数の表現（Representation）を含み得る。

表現は、ビットレート、解像度、チャネルの数、および／または他の特性によって他の表現とは異なる、１つまたは複数のメディアコンポーネントの配信可能な符号化バージョンを記述し得る。（たとえば、各）表現は、１つまたは複数のセグメントを含み得る。関連する表現の１つまたは複数のプロパティを指定するために、表現要素の１つまたは複数の属性（たとえば、＠ｉｄ、＠ｂａｎｄｗｉｄｔｈ、＠ｑｕａｌｉｔｙＲａｎｋｉｎｇ、および＠ｄｅｐｅｎｄｅｎｃｙＩｄなど）が使用され得る。

セグメント（Segment）は、単一のＨＴＴＰ要求を用いて取り出されることが可能なデータの最大ユニットであり得る。（たとえば、各）セグメントは、ＵＲＬ（たとえば、サーバ上のアドレス可能なロケーション）を有し得る。（たとえば、各）セグメントは、ＨＴＴＰ ＧＥＴまたはバイト範囲をもつＨＴＴＰ ＧＥＴを使用してダウンロードされ得る。

ＤＡＳＨクライアントは、ＭＰＤ ＸＭＬドキュメントをパースし得る。ＤＡＳＨクライアントは、たとえば、ＡｄａｐｔａｔｉｏｎＳｅｔ要素のうちの１つまたは複数において提供される情報に基づいて、ＤＡＳＨクライアントの環境に好適なＡｄａｐｔａｔｉｏｎＳｅｔの集合を選択し得る。（たとえば、各）ＡｄａｐｔａｔｉｏｎＳｅｔ内で、クライアントは表現を選択し得る。クライアントは、＠ｂａｎｄｗｉｄｔｈ属性の値、クライアント復号能力、および／またはクライアントレンダリング能力に基づいて表現を選択し得る。クライアントは、選択された表現の初期化セグメントをダウンロードし得る。クライアントは、（たとえば、セグメント全体またはセグメントのバイト範囲を要求することによって）コンテンツにアクセスし得る。プレゼンテーションが開始したとき、クライアントはメディアコンテンツを消費し続け得る。たとえば、クライアントは、プレゼンテーション中にメディアセグメント（Media Segment）および／またはメディアセグメントの部分を要求（たとえば、連続的に要求）し得る。クライアントは、メディアプレゼンテーションタイムラインに従ってコンテンツを再生し得る。クライアントは、クライアントの環境からの更新情報に基づいて、第１の表現から第２の表現に切り替わり得る。クライアントは、２つ以上の期間にわたって連続的にコンテンツを再生し得る。クライアントが、表現において告知されたメディアの終了のほうへセグメント中に含まれているメディアを消費するとき、メディアプレゼンテーション（Media Presentation）は終了され得、期間が開始され得、および／またはＭＰＤは再フェッチされ（たとえば、再フェッチされる必要があり）得る。

ＤＡＳＨクライアントなどのストリーミングクライアントとネットワーク要素との間の、または様々なネットワーク要素間のメッセージは、ネットワーク、サーバ、プロキシ、キャッシュ、ＣＤＮのリアルタイム動作特性ならびにＤＡＳＨクライアントの性能およびステータスに関する情報を提供し得る。図６は、ネットワーク要素とクライアントとの間で交換されるサーバおよびネットワーク支援型ＤＡＳＨ（ＳＡＮＤ）メッセージの一例を示す。図示のように、パラメータ拡張配信（parameters enhancing delivery）（ＰＥＤ）メッセージは、ＤＡＳＨアウェアネットワーク要素（たとえば、６０２もしくは６０４）またはＤＡＳＨ支援型ネットワーク要素（DASH assisting network element）（ＤＡＮＥ）（たとえば、６０２もしくは６０４）の間で交換され得る。パラメータ拡張受信（parameters enhancing reception）（ＰＥＲ）メッセージは、ＤＡＮＥ６０２および６０４からＤＡＳＨクライアント６０６に送られ得る。ステータスメッセージは、ＤＡＳＨクライアント６０６からＤＡＮＥ６０２および６０４に送られ得る。ステータスメッセージは、リアルタイム動作をサポートするためにＤＡＳＨクライアント６０６からＤＡＮＥ６０２および６０４にリアルタイムフィードバックを提供し得る。メトリックメッセージは、ＤＡＳＨクライアント６０６からメトリックサーバ６０８に送られ得る。メトリックメッセージは、セッションまたはより長い時間間隔の概要を提供し得る。

ＤＡＳＨクライアントは、一貫した様式でそれらがサポートするメトリックを生成し、報告し得る。異なるクライアント、プレーヤ、デバイスおよびネットワークにわたる性能が監視および比較され得る。リアルタイムでまたはオフラインで問題はデバッグされ得、障害は隔離され得る。メトリックを生成、報告、処理および可視化し得るエンティティは、メッセージ、メトリックおよび報告中に含まれている情報について共通の理解を有し得る。

いくつかのＤＡＳＨメトリックは、従来のメディアをストリーミングしているクライアントにおいてそれらが使用されるのと同じ仕方で、全方向性メディアをストリーミングしているＤＡＳＨクライアントにおいて使用され得る。全方向性メディアは、より高いビットレート要件、より高いレンダリング遅延、およびレイテンシへのより高い感度に関連付けられ得る。いくつかのメトリックは、このメディアタイプをストリーミングしているＤＡＳＨクライアントのために使用され得る。ＳＡＮＤをサポートするＤＡＳＨエンティティのために、特定のＰＥＤ／ＰＥＲメッセージが使用され得る。

ＶＲデバイスは、それの精度および感度を測定し得る。ＶＲデバイスはＨＭＤを含み得る。初期レンダリング配向情報がＶＲデバイスに送られ得る。ビューポートビュー統計が、たとえば、ＶＲデバイスによって報告され得る。関心領域（ＲＯＩ）がファイルフォーマットレベルでシグナリングされ得る。ＲＯＩは、（たとえば、各）セグメントで搬送されるべきイベントとしてシグナリングされ得る。ＤＡＮＥ要素中のデータをプリフェッチするためのシグナリングが、補助ＰＥＤメッセージとともにＭＰＤレベルにあり得る。ＲＯＩ情報は、時間指定メタデータトラック中でまたはイベントストリーム要素中で搬送され得る。

ＶＲメトリッククライアント参照モデルは、たとえば、図６において説明されるように、ストリーミングクライアント、オリジンサーバ、または測定／分析サーバおよび他のＤＡＮＥのうちの１つまたは複数の間で交換される異なるタイプの情報とともに使用され得る。

セマンティクスは、抽象構文を使用して定義され得る。抽象構文中の項目は、整数、実数、ブーリアン、列挙型、文字列、ベクトルなどを含む１つまたは複数の原始型を有し得る。抽象構文中の項目は、１つまたは複数の複合型を有し得る。複合型は、オブジェクト、リストなどを含み得る。オブジェクトは、キーおよび／または値ペアの無順序シーケンスを含み得る。キーは文字列型を有し得る。キーはシーケンス内で一意であり得る。リストは、項目の順序付きリストを含み得る。複数（たとえば、２つ）の種類のタイムスタンプが使用または定義され得る。タイムスタンプの種類は、型Ｒｅａｌ－Ｔｉｍｅをもつリアルタイム（たとえば、壁時計時間）および／または型Ｍｅｄｉａ－Ｔｉｍｅをもつメディア時間を含み得る。

ＶＲメトリッククライアント参照モデルは、メトリック収集および／または処理のために使用され得る。ＶＲメトリッククライアント参照モデルは、メトリック収集および処理のために１つまたは複数の観測点（ＯＰ）を使用または定義し得る。図７は、ＶＲメトリッククライアント参照モデルの一例であり得る。ＶＲデバイスはＶＲクライアント７１８を含み得る。ＶＲデバイスまたはＶＲプレーヤは、ＶＲメトリッククライアント参照モデル７００に基づいて使用され得る。

図７は、ＶＲメトリッククライアント参照モデル７００の機能要素を示し得る。機能要素は、ネットワークアクセス７０６、メディア処理７０８、センサー７１０、メディアプレゼンテーション７１２、ＶＲクライアント制御および管理７１４、またはメトリック収集および処理（ＭＣＰ）７１６のうちの１つまたは複数を含み得る。ＶＲアプリケーションは、没入型ユーザエクスペリエンスを配信するために異なる機能要素と通信し得る。ネットワークアクセス７０６は、ネットワーク７０４にＶＲコンテンツを要求し得る。ネットワークアクセス７０６は、（たとえば、動的センサーデータに基づいて）ビューポート依存ストリーミングについて異なる品質の１つまたは複数のビューポートセグメントを要求し得る。メディア処理要素７０８は、（たとえば、各）メディアサンプルを復号しおよび／または復号されたメディアサンプルをメディアプレゼンテーション７１２に受け渡し得る。メディアプレゼンテーション７１２は、デバイス（たとえば、ＨＭＤ、ラウドスピーカー、またはヘッドフォンのうちの１つまたは複数）を介して、対応するＶＲコンテンツを提示し得る。

センサー７１０は、ユーザの配向および／または運動を検出し得る。センサー７１０は、たとえば、ユーザの配向および／または運動に基づいて、センサーデータを生成し得る。ＶＲクライアント７１８および／またはサーバは、様々な仕方でセンサーデータを使用し得る。たとえば、センサーデータは、要求されるべきビューポートセグメント（たとえば、特定の高品質ビューポートセグメント）を判定するために使用され得る。センサーデータは、デバイス（たとえば、ＨＭＤおよび／もしくはヘッドフォン）上に存在すべきメディアサンプル（たとえば、オーディオおよびビデオ）の部分を判定するか、またはデバイス上にメディアサンプルのどの部分が存在すべきかを判定するために使用され得る。センサーデータは、ユーザ運動（たとえば、最新のユーザ運動）にメディアサンプルプレゼンテーションを一致させるための後処理を適用するために使用され得る。

ＶＲクライアント制御および／または管理モジュール７００は、ＶＲアプリケーションのためにＶＲクライアント７１８を構成し得る。ＶＲクライアント制御および／または管理モジュール７００は、一部または全部の機能要素と対話し得る。ＶＲクライアント制御および／または管理モジュール７００は、ワークフローを管理し得る。ワークフローはエンドツーエンドメディア処理手順を含み得る。たとえば、ワークフローは、ＶＲクライアント７１８のために、メディアデータを受信することからメディアサンプルのプレゼンテーションまでの処理を含み得る。

ＭＣＰ７１６は、たとえば、様々な観測点（ＯＰ）からの、データをアグリゲートし得る。データは、ユーザ位置、イベント時間、メディアサンプルパラメータなどのうちの１つまたは複数を含み得る。ＭＣＰ７１６は、メトリックサーバ７０２によって使用されるかまたはそれに送られる１つまたは複数のメトリックを導出し得る。たとえば、ビューポート切替えレイテンシメトリック導出は、ＯＰ３（たとえば、動きトリガ時間）および／またはＯＰ４（たとえば、ビューポート表示更新時間）からの入力データに基づき得る。

メトリックサーバ７０２は、データ（たとえば、メトリックデータ）を収集し得る。メトリックサーバ７０２は、ユーザ挙動分析、ＶＲデバイス性能比較、または他のデバッグもしくは追跡目的のうちの１つまたは複数のためにデータを使用し得る。全体的な没入型ＶＲエクスペリエンスは、ネットワーク、プラットフォームおよび／またはデバイスにわたって拡張され得る。

ＶＲサービスアプリケーション（たとえば、ＣＤＮサーバ、コンテンツプロバイダ、および／またはクラウドゲーミングセッション）は、たとえば、クライアント能力および性能に基づいて、異なるレベルの品質および／または没入型エクスペリエンスサービスをＶＲクライアント（たとえば、ＶＲクライアント７１８を含むＶＲデバイス）に配信するためにメトリックサーバ７０２によって収集されたメトリックを利用し得る。たとえば、ＶＲクラウドゲーミングサーバは、１つまたは複数のエンドツーエンドレイテンシ、追跡感度および精度、視野などを含むＶＲクライアントの性能メトリックを検査し得る。ＶＲクラウドゲーミングサーバは、ＶＲクライアント７１８がユーザに適切なレベルのＶＲエクスペリエンスを提供することが可能であるかどうかを判定し得る。ＶＲクラウドゲーミングサーバは、認定されたＶＲクライアントにＶＲゲームへのアクセスを認可し得る。認定されたＶＲクライアントは、ユーザに適切なレベルのＶＲエクスペリエンスを提供することが可能であり得る。

ＶＲクラウドゲーミングサーバは、認定されないＶＲクライアントにＶＲゲームへのアクセスを認可しないことがある。認定されないＶＲクライアントは、ユーザに適切なレベルのＶＲエクスペリエンスを提供することが不可能であり得る。たとえば、ＶＲクラウドゲーミングサーバが、クライアント（たとえば、ＶＲクライアント７１８）が比較的高いエンドツーエンドレイテンシを受け、および／または不十分な追跡感度パラメータを有すると判定した場合、ＶＲクラウドゲーミングサーバは、ＶＲクライアントがライブＶＲゲーミングセッションに加わることを可能にしないことがある。ＶＲクラウドゲーミングサーバは、クライアント（たとえば、ＶＲクライアント７１８）に従来のゲーミングセッションを許可し得る。たとえば、クライアントは、没入型エクスペリエンスなしの２Ｄバージョンのゲームのみに加わり得る。ＶＲクラウドゲーミングサーバは、クライアントの動的性能変化を監視し得る。ＶＲクラウドゲーミングサーバは、ＶＲメトリックがオンザフライで性能ダウングレードを示すとき、より低品質のＶＲゲームコンテンツまたはあまり没入型でないＶＲゲームに切り替わり得る。たとえば、ＶＲクラウドゲーミングサーバが、クライアントの等品質ビューポート切替えレイテンシが比較的高いと判定した場合、ＶＲクラウドゲーミングサーバは、品質不具合を低減するためにクライアントにタイル（たとえば、より同様の品質をもつタイル）を配信し得る。ＶＲユーザのＶＲエクスペリエンスは、ネットワーク条件によって影響を及ぼされ得る。コンテンツ配信ネットワーク（ＣＤＮ）またはエッジサーバは、クライアント（たとえば、ＶＲユーザ）により近接したキャッシュにＶＲコンテンツおよび／またはサービスをプッシュし得る。

ＭＣＰ７１６は、様々な様式で様々な観測点（ＯＰ）からのデータをアグリゲートし得る。例示的なＯＰ（ＯＰ１～ＯＰ５）が本明細書で提供されるが、ＭＣＰ７１６は、たとえば、本明細書で説明されるＯＰのどんな順序または組合せからのデータでもアグリゲートし得ることを諒解されたい。ＭＣＰ７１６は、クライアントの一部であり得るかまたはメトリックサーバ（たとえば、メトリックサーバ７０２）中に存在し得る。

ＯＰ１は、ネットワークアクセス７０６からＭＣＰ７１６のほうへのインターフェースに対応し得るかまたはそれを含み得る。ネットワークアクセス７０６は、ネットワーク要求を発行し、ネットワーク７０４からＶＲメディアストリームを受信し、および／またはＶＲメディアストリームをカプセル化解除し得る。ＯＰ１はネットワーク接続のセットを含み得る。（たとえば、各）ネットワーク接続は、宛先アドレス、開始、接続、またはクローズ時間のうちの１つまたは複数によって定義され得る。ＯＰ１は、送信されるネットワーク要求のシーケンスを含み得る。（たとえば、各）送信されるネットワーク要求は、送信時間、コンテンツ、またはネットワーク要求が送られるＴＣＰ接続のうちの１つまたは複数によって定義され得る。ＯＰ１は、（たとえば、各）ネットワーク応答について、受信時間、応答ヘッダのコンテンツ、および／または応答本文の（たとえば、各）バイトの受信時間のうちの１つまたは複数を含み得る。

ＯＰ２は、メディア処理７０８からＭＣＰ７１６のほうへのインターフェースに対応し得るかまたはそれを含み得る。メディア処理７０８は、逆多重化および／または復号（たとえば、オーディオ、画像、ビデオおよび／または明視野復号）を行い得る。ＯＰ２は、符号化されたメディアサンプルを含み得る。（たとえば、各）符号化されたメディアサンプルは、メディアタイプ、メディアコーデック、メディア復号時間、全方向性メディアメタデータ、全方向性メディア投影、全方向性メディア領域的パッキング、全方向ビデオビューポート、フレームパッキング、色空間、ダイナミックレンジなどのうちの１つまたは複数を含み得る。

ＯＰ３は、センサー７１０からＭＣＰ７１６のほうへのインターフェースに対応し得る。センサー７１０は、ユーザの頭部または体の配向および／または運動を捕捉し得る。センサー７１０は、光、温度、磁界、重力および／またはバイオメトリックなどの環境データを捕捉し得る。ＯＰ３は、６ＤｏＦ（Ｘ、Ｙ、Ｚ、ヨー、ピッチ、およびロール）、深度、速度などのうちの１つまたは複数を含むセンサーデータのリストを含み得る。

ＯＰ４は、メディアプレゼンテーション７１２からＭＣＰ７１６のほうへのインターフェースに対応し得る。メディアプレゼンテーション７１２は、たとえば、ユーザに完全な没入型ＶＲエクスペリエンスを提供するために、混合された自然および合成ＶＲメディア要素を同期および／または提示し得る。メディアプレゼンテーション７１２は、（たとえば、各）ＶＲメディア要素のために色変換、投影、メディア組立ておよび／またはビュー合成を行い得る。ＯＰ４は、復号化されたメディアサンプルを含み得る。サンプル（たとえば、各メディアサンプル）は、メディアタイプ、メディアサンプルプレゼンテーションタイムスタンプ、壁時計カウンタ、実際のプレゼンテーションビューポート、実際のプレゼンテーション時間、実際のプレイアウトフレームレート、オーディオ対ビデオ同期などのうちの１つまたは複数を含み得る。

ＯＰ５は、ＶＲクライアント制御および管理７１４からＭＣＰ７１６のほうへのインターフェースに対応し得る。ＶＲクライアント制御および管理要素７１４は、表示解像度、フレームレート、視野（ＦＯＶ）、眼対スクリーン距離、ｌｅｎｓＳｅｐａｒａｔｉｏｎ距離などのクライアントパラメータを管理し得る。ＯＰ５はＶＲクライアント構成パラメータを含み得る。（たとえば、各）パラメータは、表示解像度、（たとえば、ＰＰＩでの）表示密度、（たとえば、度での）水平および垂直ＦＯＶ、（たとえば、ｍｍでの）追跡範囲、（たとえば、ｍｍでの）追跡精度、（たとえば、ｍｓでの）動き予測、メディアコーデックサポート、ＯＳサポートなどのうちの１つまたは複数を含み得る。

ＶＲクライアント制御および管理７１４は、ユーザ（たとえば、ＶＲユーザ）が（たとえば、デバイス情報以外の）パーミッションを許可した場合、ユーザの個人プロファイル情報を収集し得る。個人プロファイル情報は、ＶＲユーザの性別、年齢、ロケーション、人種、宗教などのうちの１つまたは複数を含み得る。ＶＲサービスアプリケーションは、メトリックサーバ７０２から個人プロファイル情報を収集し得る。ＶＲサービスアプリケーションは、（たとえば、ＶＲデバイスを含む）ＶＲクライアント７１８から（たとえば、直接的に）個人プロファイル情報を収集し得る。ＶＲサービスアプリケーションは、（たとえば、個々の）ＶＲユーザのために適切なＶＲコンテンツおよび／またはサービスを識別し得る。

ＶＲストリーミングサービスプロバイダは、異なるユーザに３６０度ビデオタイルの異なるセットを配信し得る。ＶＲストリーミングサービスプロバイダは、異なる潜在的閲覧者の特性に基づいて３６０度ビデオタイルの異なるセットを配信し得る。たとえば、成人は、制限付きコンテンツへのアクセスを含む完全な３６０度ビデオを受信し得る。未成年のユーザは、同じビデオを見得るが、制限付きコンテンツ（たとえば、領域および／またはタイル）へのアクセスをもたない。ＶＲサービスプロバイダは、法律および規制（たとえば、地方自治体の法律および規制）に準拠するためにロケーションにおよび／または時間において（たとえば、特定のロケーションにおよび／または特定の時間において）あるＶＲコンテンツを配信することを停止し得る。ＶＲクラウドゲーミングサーバは、潜在的なシミュレーション疾患を回避するために、異なるシミュレーション疾患感度のユーザ（たとえば、男性、女性、シニア成人、および／または青年）に異なる没入型レベルゲームを配信し得る。ＶＲデバイスは、（たとえば、個人プロファイル情報を使用して）ローカルＶＲプレゼンテーションを制御し得る。たとえば、ＶＲサービスプロバイダは、（たとえば、誰に対しても差別的でない仕方で）制限付きシーンを含む３６０度ビデオをマルチキャスト／ブロードキャストし得る。（たとえば、各）ＶＲ受信機は、個人プロファイル情報に基づいてプレゼンテーションを構成し得る。ＶＲ受信機は、個人プロファイル情報に基づいて制限付きコンテンツ（たとえば、シーン）への異なるレベルのアクセスを許可し得る。たとえば、ＶＲ受信機は、潜在的閲覧者の年齢、人種または宗教情報に基づいて制限付きシーンの一部または全部をフィルタ除去するかまたは不鮮明にし得る。ＶＲ受信機は、潜在的閲覧者の年齢、人種または宗教情報に基づいて制限付きシーンの一部または全部へのアクセスを可能にすることが適切であるかどうかを判定し得る。本明細書の手法および／または技法は、ＶＲサービスプロバイダが、より多数のユーザにおよび／または効率的な仕方でＶＲコンテンツ（たとえば、ＶＲコンテンツの単一のバージョン）を供給することを可能にし得る。

ＭＣＰ７１６は、１つまたは複数のＯＰからメトリックを捕捉しおよび／またはＶＲメトリック（たとえば、レイテンシなどの特定のＶＲメトリック）を導出し得る。

デバイス（たとえば、ＶＲデバイス、ＨＭＤ、電話、タブレット、またはパーソナルコンピュータ）は、閲覧関係のメトリックおよびメッセージを生成および／または報告し得る。閲覧関係のメトリックおよびメッセージは、ビューポートビュー、ビューポート一致、レンダリングデバイス、初期レンダリング配向、ビューポート切替えレイテンシ、品質ビューポート切替えレイテンシ（たとえば、品質ビューポート切替えレイテンシ）、初期レイテンシ、整定レイテンシ、６ＤｏＦ座標、視線データ、フレームレート、ビューポートロス、精度、感度、ＲＯＩなどのうちの１つまたは複数を含み得る。

デバイスは、どの時間にどのビューポートが要求および／または閲覧されたかを示すためのメトリックを使用し得る。メトリックはビューポートビューメトリックを含み得る。ＶｉｅｗｐｏｒｔＶｉｅｗｓなどのメトリックの報告は、どの時間にどのビューポートが要求および閲覧されたかを示し得る。デバイスまたはメトリックサーバは、ＯＰ４から（たとえば、表１に示されている）ビューポートビューメトリックを導出し得る。表１は、ビューポートビューに関する報告の例示的なコンテンツを示す。

エントリ（たとえば、エントリ「ソース」）は、オリジンＶＲメディアサンプルのソースを含み（たとえば、指定し）得る。デバイスは、ＭＰＤのＵＲＬ、ＤＡＳＨストリーミングのメディア要素表現、またはプログレッシブダウンロードのためのメディアサンプルファイルの元のＵＲＬのうちの１つまたは複数からエントリ「ソース」を推論し得る。

エントリ（たとえば、エントリ「タイムスタンプ」）は、メディアサンプルプレゼンテーション時間を含み（たとえば、指定し）得る。

エントリ（たとえば、エントリ「持続時間」）は、どのくらいの時間の間クライアントがそれぞれのビューポート上にとどまるかを報告するためにクライアントによって使用される時間間隔を指定し得る。

エントリ（たとえば、エントリ「ビューポート」）は、メディア時間ｔにおいて存在する全方向性メディアの領域を含み（たとえば、指定し）得る。領域は、ｃｅｎｔｅｒ＿ｙａｗ、ｃｅｎｔｅｒ＿ｐｉｔｃｈ、存在するときはｓｔａｔｉｃ＿ｈｏｒ＿ｒａｎｇｅ、ｓｔａｔｉｃ＿ｖｅｒ＿ｒａｎｇｅ、またはｈｏｒ＿ｒａｎｇｅおよびｖｅｒ＿ｒａｎｇｅのうちの１つまたは複数によって定義され得る。６ＤｏＦのために、エントリ「ビューポート」は、ユーザ位置または追加のユーザ位置（ｘ，ｙ，ｚ）を含み得る。

エントリ（たとえば、エントリ「ビューポート」）は、様々な仕様および実装において使用される表記法または式のうちの１つまたは複数を使用して、閲覧されたビューポートを表し得る。異なるユーザのビューポートビューメトリックは、たとえば、メトリックサーバ（たとえば、メトリックサーバ７０２）によって、互いに比較および／または相関され得る。たとえば、メトリックサーバは、より人気があるビューポートを判定し得る。ネットワーク（たとえば、ＣＤＮ）は、キャッシングのためにまたはコンテンツ制作のために情報（たとえば、エントリ「ビューポート」）を使用し得る。デバイス（たとえば、ＶＲデバイス）は、リプレイのためにある精度で１つまたは複数のビューポートビューを記録し得る。記録されたビューポートビューは、以前に見られた３６０°ビデオの特定のバージョンをリプレイするために（たとえば、別の閲覧者によって）後で使用され得る。ブロードキャスト／マルチキャストサーバまたはＶＲクライアントなどのネットワーク要素は、ビューポートビューメトリックに基づいて複数の閲覧者の閲覧されたビューポートを同期させ得る。閲覧者は、たとえば、リアルタイムで、同様のまたは同じエクスペリエンスを有し得る。

デバイス（たとえば、クライアント）は、（たとえば、周期的に）ビューポートビューメトリックをロギングし、および／または（たとえば、センサーによって検出された）閲覧配向変化によってビューポートビューメトリックを報告するようにトリガされ得る。

デバイスは、推奨ビューポート（たとえば、ディレクターズカット）をクライアントがフォローするかどうかを示すためのメトリックを使用し得る。メトリックはビューポート一致メトリックを含み得る。デバイス（たとえば、クライアント）は、クライアントの閲覧配向を対応する推奨ビューポートメタデータと比較すること、および／またはクライアントの閲覧配向が対応する推奨ビューポートメタデータに一致する場合、一致イベントをロギングすることが可能であり得る。表２は、ビューポート一致メトリックに関する報告の例示的なコンテンツを示す。

エントリ（たとえば、エントリ「フラグ」）は、測定間隔中にビューポート（たとえば、現在のビューポート）が推奨ビューポートに一致するかどうかを指定するブーリアンパラメータであり得る。以下のパラメータのいずれか１つまたは組合せは、エントリ「フラグ」の値が真であるときに提示され得る。エントリ（たとえば、エントリ「ｔｒａｃｋＩｄ」）は、推奨ビューポート時間指定メタデータのシーケンスの識別子であり得、および／または１つもしくは複数の推奨ビューポートの中でどの推奨ビューポートが一致しているかを識別するために使用され得る。エントリ（たとえば、エントリ「カウント」）は、「トラック」によって指定される推奨ビューポートの一致の累積数を指定し得る。エントリ（たとえば、エントリ「持続時間」）は、測定間隔中の連続的ビューポート一致の時間間隔を指定し得る。エントリ（たとえば、エントリ「タイプ」）は、一致したビューポートタイプを指定し得、値０は、推奨ビューポートがディレクターズカットであることを示し得、および／または値１は、推奨ビューポートが閲覧統計に基づいて選択されることを示し得る。デバイス（たとえば、クライアント）は、（たとえば、周期的に）ビューポート一致をロギングし、ならびに／または閲覧配向が変化するかもしくは推奨ビューポート位置および／もしくはサイズが変化するときのイベントによってビューポート一致を報告するようにトリガされ得る。

デバイスは、レンダリングデバイスメトリックおよびメッセージを示すためのメトリックを使用し得る。メトリックはＲｅｎｄｅｒｉｎｇＤｅｖｉｃｅを含み得る。たとえば、メトリックＲｅｎｄｅｒｉｎｇＤｅｖｉｃｅのＶＲデバイスタイプ報告は、（たとえば、全方向性メディアがそこでレンダリングされている）デバイスのブランド、モデル、オペレーティングシステム（ＯＳ）、解像度、密度、ｒｅｆｒｅｓｈｒａｔｅ、コーデック、投影、パッキング、追跡範囲、追跡精度、追跡感度、および／または他のデバイス固有情報のうちの１つまたは複数を示し得る。メトリックサーバは、報告に基づいて、コンテンツがＴＶ対ＨＭＤ上で消費されているかｄａｙｄｒｅａｍタイプのＨＭＤ上で消費されているかを判定し得る。メトリックサーバまたはクライアントは、より良い分析のためにこの情報をコンテンツタイプと相関させ得る。ＶＲデバイスがＨＭＤである場合、サポートされるＨＭＤ固有情報などの情報はメトリック中に含まれ得る。クライアント（たとえば、ＶＲクライアント）は、メトリックサーバに報告するために適切なデバイス情報を判定し得る。メトリックサーバは、ＶＲデバイスに適切な情報を要求し得る。サポートされるＨＭＤ固有情報は、限定はされないが、精度、感度、最大サポートフレームレート、最大サポート解像度および／またはサポートされるコーデック／投影法のリストを含み得る。表３は、ＶＲデバイスに関する報告の例示的なコンテンツ（たとえば、メトリックＲｅｎｄｅｒｉｎｇＤｅｖｉｃｅ）を示す。メトリックサーバは、分析のために表３中の情報などの情報をコンテンツタイプと相関させ得る。たとえば、クライアントまたはメトリックサーバは、ＯＰ５からメトリックＲｅｎｄｅｒｉｎｇＤｅｖｉｃｅおよび／または表３中に含まれるエントリのうちの１つもしくは複数を導出し得る。

エントリ（たとえば、エントリ「ｔｒａｃｋｉｎｇＲａｎｇｅ」）は、ＶＲユーザ動き検出のためにＶＲデバイスによってサポートされる最大のまたは最も大きい２Ｄまたは３Ｄ追跡範囲を含み（たとえば、指定し）得る。最大のまたは最も大きい２Ｄまたは３Ｄ追跡範囲は、この最大のまたは最も大きい２Ｄまたは３Ｄ追跡範囲を越えると動き追跡および検出が不正確になり得ることを暗示し得る。最小のまたは最も小さい範囲は点であり得る。ＴｒａｃｋｉｎｇＲａｎｇｅは、たとえば、（たとえば、ミリメートルの単位で）ＶＲ空間の幅、長さおよび高さとして定義され得る。図８は、３Ｄ追跡範囲の測定の一例を示し得る。エントリＴｒａｃｋｉｎｇＲａｎｇｅは、（たとえば、単一の）追跡センサーを用いて３Ｄ空間８００の幅８０２、高さ８０４、および長さ８０６または２Ｄ範囲の円範囲として定義され得る。エントリ「ｔｒａｃｋｉｎｇＲａｎｇｅ」は、複数の追跡センサーを用いて２Ｄ交差エリアの幅、長さとして定義され得る。図９は、複数のセンサー、たとえば追跡センサー９０４～９１０を用いた２Ｄ動き追跡交差範囲の一例を示す。図９に示されているように、２Ｄ交差エリア９０２の長さおよび幅は、エントリ「ｔｒａｃｋｉｎｇＲａｎｇｅ」を定義し得る。

エントリ（たとえば、エントリ「ｔｒａｃｋｉｎｇＰｒｅｃｉｓｉｏｎ」）は、並進運動（ｘ、ｙ、ｚ）ではミリメートルでの、および回転運動（ヨー、ピッチ、ロール）ではミリ度での追跡表記単位（たとえば、最小追跡表記単位）を含み（たとえば、指定し）得る。

エントリ（たとえば、エントリ「ｔｒａｃｋｉｎｇＳｅｎｓｉｔｉｖｉｔｙ」）は、並進ではミリメートル（Δｘ、Δｙ、Δｚ）で、および回転ではミリ度（Δヨー、Δピッチ、Δロール）でＶＲデバイスによって検出されることが可能な最小動き変位（たとえば、微細な動き）を含み（たとえば、指定し）得る。

エントリ（たとえば、エントリ「ＴｒａｃｋｉｎｇＬａｔｅｎｃｙ」）は、動きと、センサーがその動きを検出しアプリケーションに報告することとの間の時間間隔を示し（たとえば、指定し）得る。

エントリ（たとえば、エントリ「ＲｅｎｄｅｒｉｎｇＬａｔｅｎｃｙ」）は、メディアサンプルがレンダリングモジュールから出力されることと、メディアサンプルがディスプレイおよび／またはヘッドフォン上に存在することとの間の時間間隔を示し（たとえば、指定し）得る。

デバイス（たとえば、ＶＲデバイス）は、初期レンダリング配向メッセージを生成および／または報告し得る。デバイスは、再生がそれから開始されるべきである配向を示すためのメトリックを使用し得る。メトリックはＩｎｉｔｉａｌＲｅｎｄｅｒｉｎｇＯｒｉｅｎｔａｔｉｏｎを含み得る。メトリック「ＩｎｉｔｉａｌＲｅｎｄｅｒｉｎｇＯｒｉｅｎｔａｔｉｏｎ」の初期レンダリング配向報告は、再生がそれから開始されるべきである配向を示し得る。初期配向は、プレゼンテーションの開始においておよび／またはプレゼンテーション全体にわたるいくつかの点（たとえば、シーン変化）において示され得る。コンテンツ制作者がこの指示を提供し得る。初期レンダリング配向メッセージはＰＥＲタイプであり得る。たとえば、初期レンダリング配向メッセージはＤＡＮＥからＤＡＳＨクライアントに送られ得る。この情報（たとえば、ｉｎｉｔｉａｌＲｅｎｄｅｒｉｎｇＯｒｉｅｎｔａｔｉｏｎ）は、時間指定メタデータトラック、イベントストリーム要素またはＳＡＮＤ－ＰＥＲメッセージ中で搬送され得る。メトリックサーバは、（たとえば、シーン変化が起こったとき）ＶＲコンテンツのレンダリング位置の座標をリセットするようにＨＭＤ配向を構成するために初期レンダリング配向メトリックを使用し得る。初期レンダリング配向メッセージとともに、ＨＭＤは、別のビデオエリアを前面に運動させ得る。表４は、初期レンダリング配向メッセージの例示的なコンテンツを示す。メトリックサーバまたはクライアントは、ＯＰ２からこのメトリックおよび／または表４中に含まれるエントリのうちの１つもしくは複数を導出し得る。

デバイスは、ビューポートから別のビューポートに切り替わるときにクライアントが経験するレイテンシを示すためのメトリックを生成し得る。メトリックは「ＶｉｅｗｐｏｒｔＳｗｉｔｃｈｉｎｇＬａｔｅｎｃｙ」を含み得る。たとえば、メトリック「ＶｉｅｗｐｏｒｔＳｗｉｔｃｈｉｎｇＬａｔｅｎｃｙ」のビューポート切替えレイテンシメトリック報告は、ビューポートから別のビューポートに切り替わるときにクライアントが経験するレイテンシを示し得る。ネットワークまたはクライアント（たとえば、ＶＲデバイス）は、閲覧者のエクスペリエンス品質（ＱｏＥ）を測定するためにビューポート切替えレイテンシメトリックを使用し得る。（ＳＡＮＤ）ＤＡＮＥ要素および／またはオリジンサーバは、コンテンツ符号化、パッケージング、キャッシング、または配信のうちの１つまたは複数に対してビューポート切替えレイテンシメトリックを使用し得る。表５は、ビューポート切替えレイテンシメトリックに関する例示的な報告を示す。メトリックサーバまたはクライアントは、ＯＰ３および／またはＯＰ４からビューポート切替えレイテンシメトリックおよび／または表５に示されているエントリのうちの１つもしくは複数を導出し得る。

エントリ（たとえば、エントリ「並進」）は、前／後、上／下、左／右など、ユーザの並進運動を含み（たとえば、指定し）得、および／または変位ベクトル（Δｘ、Δｙ、Δｚ）によって表され得る。

エントリ（たとえば、エントリ「回転」）は、ヨー、ピッチおよびロールなど、ユーザ角運動を含み（たとえば、指定し）得、ならびに／またはラジアンもしくは度で角変位（Δヨー、Δピッチ、Δロール）によって表され得る。

エントリ（たとえば、エントリ「ｆｉｒｓｔ＿ｖｉｅｗｐｏｒｔ」）は、第１のビューポートの中心点座標および第１のビューポートのサイズを含み（たとえば、指定し）得る。

エントリ（たとえば、エントリ「ｓｅｃｏｎｄ＿ｖｉｅｗｐｏｒｔ」）は、第２のビューポートの中心点座標および第２のビューポートのサイズを示し（たとえば、指定し）得る。

エントリ（たとえば、エントリ「レイテンシ」）は、入力された並進および／または回転運動と、ＶＲプレゼンテーション上で更新または表示される１つまたは複数の関係するＶＲメディア要素（ビデオ、オーディオ、画像、明視野など）の対応するビューポートとの間の遅延を含み（たとえば、指定し）得る。たとえば、エントリ「レイテンシ」は、（たとえば、クライアントが頭部運動を検出したとき）第１のビューポートから第２のビューポートへの頭部運動が起こる時間と、対応する第２のビューポートがディスプレイ上に提示される時間との間の時間間隔を指定し得る。

たとえば、ビューポート切替えレイテンシは、どのくらい高速にＨＭＤが頭部運動に応答し、シフトされたビューポートのためのコンテンツをアンパックしレンダリングするかに対応し得る。ビューポート切替えレイテンシは、閲覧者の頭部が運動する（たとえば、ＨＭＤが閲覧者の頭部運動を検出する）時間と、閲覧者の頭部運動が、閲覧者によって観測されるビデオに影響を及ぼす時間との間の時間に対応し得る。たとえば、ビューポート切替えレイテンシは、現在のビューポートから異なるビューポートへの頭部運動と、その異なるビューポートがＨＭＤ上に表示されることとの間で測定され得る。ビューポート切替えレイテンシは、たとえば、対応するビューポートをフェッチおよび／またはレンダリングするためにネットワークまたはクライアントが使用する、ネットワークまたはクライアントの不十分な処理能力によって引き起こされることがある。ネットワークおよび／またはクライアントプレーヤは、ビューポート切替えレイテンシメトリック報告を受信し、タイムラインに沿って分析した後に、ビューポート切替えレイテンシを最小限に抑えるための異なるインテリジェントな手法を使用し得る。

デバイス（たとえば、ＨＭＤ、電話、タブレット、またはパーソナルコンピュータ）は、デバイスの運動（たとえば、頭部運動）を判定し得る。デバイスの運動は、デバイスが現在のビューポートの外部に運動すること、配向変化、ズーム動作などのうちの１つまたは複数を含み得る。デバイスは、デバイスの運動に基づいてビューポート切替えレイテンシを判定し得る。

図１０は、ビューポート切替えイベントの一例を示す。デバイスは、ビューポート切替えイベントに基づいてデバイスの運動を判定し得る。ビューポートは、パラメータのセットによって表され得る。図１０に示されているように、第１のビューポート１００２は、１０１０ｆｉｒｓｔ＿ａｚｉｍｕｔｈ＿ｒａｎｇｅ、１０１２ｆｉｒｓｔ＿ｅｌｅｖａｔｉｏｎ＿ｒａｎｇｅ、ならびに１００６ｆｉｒｓｔ＿ｃｅｎｔｒｅ＿ａｚｉｍｕｔｈおよび／またはｆｉｒｓｔ＿ｃｅｎｔｒｅ＿ｅｌｅｖａｔｉｏｎによって表され得る。第２のビューポート１００４は、１０１４ｓｅｃｏｎｄ＿ａｚｉｍｕｔｈ＿ｒａｎｇｅ、１０１６ｓｅｃｏｎｄ＿ｅｌｅｖａｔｉｏｎ＿ｒａｎｇｅ、ならびに１００８ｓｅｃｏｎｄ＿ｃｅｎｔｒｅ＿ａｚｉｍｕｔｈおよび／またはｓｅｃｏｎｄ＿ｃｅｎｔｒｅ＿ｅｌｅｖａｔｉｏｎによって表され得る。

デバイスは、パラメータのセットのうちの１つまたは複数の変化がしきい値以上である場合、ビューポート切替えイベントを判定し得る。デバイスは、パラメータのセットのうちの１つまたは複数の変化がしきい値以上である場合、デバイスの運動を判定し得る。デバイスは、異なるアプリケーションおよび／またはデバイスにわたって一貫した測定を維持するために、ビューポート切替えイベントを判定したとき、１つまたは複数の制約を適用し得る。

デバイスは、たとえば、第１のビューポート１００２に関連する１つまたは複数のパラメータ１０１０ｆｉｒｓｔ＿ａｚｉｍｕｔｈ＿ｒａｎｇｅ、１０１２ｆｉｒｓｔ＿ｅｌｅｖａｔｉｏｎ＿ｒａｎｇｅ、ならびに１００６ｆｉｒｓｔ＿ｃｅｎｔｒｅ＿ａｚｉｍｕｔｈおよび／またはｆｉｒｓｔ＿ｃｅｎｔｒｅ＿ｅｌｅｖａｔｉｏｎに基づいて、第１のレンダリングされたビューポートに関連する第１のビューポート１００２が、ビューポート切替えイベントの前に安定していると判定し得る。同様に、デバイスは、たとえば、第２のビューポートに関連する１つまたは複数のパラメータ１０１４ ｓｅｃｏｎｄ＿ａｚｉｍｕｔｈ＿ｒａｎｇｅ、１０１６ｓｅｃｏｎｄ＿ｅｌｅｖａｔｉｏｎ＿ｒａｎｇｅ、ならびに１００８ｓｅｃｏｎｄ＿ｃｅｎｔｒｅ＿ａｚｉｍｕｔｈおよび／またはｓｅｃｏｎｄ＿ｃｅｎｔｒｅ＿ｅｌｅｖａｔｉｏｎに基づいて、第２のレンダリングされたビューポートに関連する第２のビューポート１００４が、ビューポート切替えイベントの後に安定していると判定し得る。たとえば、ビューポイントは、たとえば、図１０に示されているように、ｃｅｎｔｒｅ＿ａｚｉｍｕｔｈ、ｃｅｎｔｒｅ＿ｅｌｅｖａｔｉｏｎ、および／またはｃｅｎｔｒｅ＿ｔｉｌｔのうちの１つまたは複数によって表され得る。ｃｅｎｔｒｅ＿ａｚｉｍｕｔｈおよびｃｅｎｔｒｅ＿ｅｌｅｖａｔｉｏｎは、ビューポートの中心を示し得る。ｃｅｎｔｒｅ＿ｔｉｌｔは、（たとえば、グローバル座標軸に対して２^-16度の単位で）ビューポートのチルト角を示し得る。たとえば、第１のビューポイントのｃｅｎｔｒｅ＿ａｚｉｍｕｔｈ、ｃｅｎｔｒｅ＿ｅｌｅｖａｔｉｏｎ、および／またはｃｅｎｔｒｅ＿ｔｉｌｔの値は、ビューポート切替えイベントの前にｎミリ秒以内に２^-16度のｍ単位よりも大きく変化しないことがあり、ｓｅｃｏｎｄ＿ｖｉｅｗｐｏｉｎｔのｃｅｎｔｒｅ＿ａｚｉｍｕｔｈ、ｃｅｎｔｒｅ＿ｅｌｅｖａｔｉｏｎ、および／またはｃｅｎｔｒｅ＿ｔｉｌｔの値は、ビューポート切替えイベントの後にｎミリ秒以内に２^-16度のｍ単位よりも大きく変化しないことがある。ｍとｎの両方は正の整数であり得る。デバイスはｍおよびｎを用いて構成され得る。たとえば、デバイスは、（たとえば、コンテンツサーバからまたはメトリックサーバから）ｍおよびｎの値を受信し得る。デバイスは、ビューポート切替えイベントを識別するために使用されるｍおよびｎを用いてメトリックをロギングおよび／または報告し得る。

ビューポート切替えイベントは、（たとえば、閲覧者の）ビューポイントが、デバイスの現在のレンダリングまたは表示されているビューポートの外部に運動したときにトリガされ得る。デバイスは、（たとえば、閲覧者の）ビューポイントが、現在のレンダリングまたは表示されているビューポートの外部に運動したとき、デバイスの運動を判定し得る。第１のビューポート１００２または第１のレンダリングされたビューポートは、たとえば、図１０に示されているように、第１のビューポート１００２もしくは第１のレンダリングされたビューポートの中心位置１００６（たとえば、ｆｉｒｓｔ＿ｃｅｎｔｒｅ＿ａｚｉｍｕｔｈ、ｆｉｒｓｔ＿ｃｅｎｔｒｅ＿ｅｌｅｖａｔｉｏｎ、ｆｉｒｓｔ＿ｃｅｎｔｒｅ＿ｔｉｌｔ）ならびに／または第１のビューポートもしくは第１のレンダリングされたビューポートの領域（たとえば、ｆｉｒｓｔ＿ａｚｉｍｕｔｈ＿ｒａｎｇｅ１０１０、およびｆｉｒｓｔ＿ｅｌｅｖａｔｉｏｎ＿ｒａｎｇｅ１０１２）によって表され得る。第２のビューポート１００４または第２のレンダリングされたビューポートは、第２のビューポート１００４もしくは第２のレンダリングされたビューポートの中心位置１００８（たとえば、ｓｅｃｏｎｄ＿ｃｅｎｔｒｅ＿ａｚｉｍｕｔｈ、ｓｅｃｏｎｄ＿ｃｅｎｔｒｅ＿ｅｌｅｖａｔｉｏｎ、ｓｅｃｏｎｄ＿ｃｅｎｔｒｅ＿ｔｉｌｔ）ならびに／または第２のビューポートもしくは第２のレンダリングされたビューポートの領域（たとえば、ｓｅｃｏｎｄ＿ａｚｉｍｕｔｈ＿ｒａｎｇｅ１０１４、およびｓｅｃｏｎｄ＿ｅｌｅｖａｔｉｏｎ＿ｒａｎｇｅ１０１６）によって表され得る。

デバイスは、パラメータの変化（たとえば、第１のビューポート１００２のパラメータと第２のビューポート１００４のパラメータとの間の差）がしきい値以上であるとき、ビューポート切替えイベントが起こると判定し得る。たとえば、ビューポート切替えイベントは、ｆｉｒｓｔ＿ｃｅｎｔｒｅ＿ａｚｉｍｕｔｈ１００６とｓｅｃｏｎｄ＿ｃｅｎｔｒｅ＿ａｚｉｍｕｔｈ１００８との間の距離がしきい値（たとえば、ｆｉｒｓｔ＿ａｚｉｍｕｔｈ＿ｒａｎｇｅ／２）以上であるときに起こり得る。ビューポート切替えイベントは、ｆｉｒｓｔ＿ｃｅｎｔｒｅ＿ｅｌｅｖａｔｉｏｎ１００６とｓｅｃｏｎｄ＿ｃｅｎｔｒｅ＿ｅｌｅｖａｔｉｏｎ１００８との間の距離がしきい値（たとえば、ｆｉｒｓｔ＿ｃｅｎｔｒｅ＿ｒａｎｇｅ／２）以上であるときに起こり得る。

ビューポート切替えイベントは、閲覧配向変化についてのデバイスの検出によってトリガされ得る。閲覧配向は、ユーザがオーディオビジュアルコンテンツを消費している配向を特徴づける、アジマス、エレベーション、およびチルト角のトリプレットによって定義され得る。閲覧配向は、ユーザが画像またはビデオを消費しているときのビューポートの配向を特徴づける、アジマス、エレベーション、およびチルト角のトリプレットによって定義され得る。たとえば、デバイスは、デバイスが閲覧配向変化を検出したとき、デバイスの運動を判定し得る。閲覧配向は、たとえば、ビューポートの相対的ロケーションまたは配置に関係し得る。

ビューポート切替えイベントはズーム動作中に起こり得る。たとえば、デバイスは、デバイスがズーム動作中に運動していると判定し得る。たとえば、ズーム動作は、レンダリングまたは表示されたビューポート中心位置が変化しないが、対応するビューポートおよび／または対応する球状エリアのサイズが変化しても起こり得る。図１１は、３６０°ビデオビューポートズームの一例を示し得る。ＶｉｅｗｐｏｒｔＳｗｉｔｃｈｉｎｇＬａｔｅｎｃｙのパラメータｆｉｒｓｔ＿ｖｉｅｗｐｏｉｎｔおよびｓｅｃｏｎｄ＿ｖｉｅｗｐｏｉｎｔは、それぞれ、ズーム動作のために、ｆｉｒｓｔ＿ｖｉｅｗｐｏｒｔサイズ１１０２およびｓｅｃｏｎｄ＿ｖｉｅｗｐｏｒｔサイズ１１０８に置き換えられ得る。パラメータａｚｉｍｕｔｈ＿ｒａｎｇｅおよび／またはｅｌｅｖａｔｉｏｎ＿ｒａｎｇｅは、（たとえば、２^-16度の単位で）レンダリングされているビューポートの中心点を通る範囲を指定し得る。デバイスは、第１のビューポートサイズ１１０２と第２のビューポートサイズ１１０８との間の差がしきい値以上であるとき、ビューポート切替えイベントが起こると判定し得る。第１のビューポートサイズ１１０２および第２のビューポートサイズ１１０８は、第１のビューポートについてはａｚｉｍｕｔｈ＿ｒａｎｇｅ１１０４および／またはｅｌｅｖａｔｉｏｎ＿ｒａｎｇｅ１１０６によって、ならびに第２のビューポートについてはａｚｉｍｕｔｈ＿ｒａｎｇｅ１１１０および／またはｅｌｅｖａｔｉｏｎ＿ｒａｎｇｅ１１１２によって判定され得る。デバイスは、第１のビューポートおよび第２のビューポートがそれぞれ安定していると判定された後に、ビューポート切替えイベントの前のｆｉｒｓｔ＿ｖｉｅｗｐｏｒｔサイズ１１０２、およびビューポート切替えの後のｓｅｃｏｎｄ＿ｖｉｅｗｐｏｒｔサイズ１１０８を判定し得る。たとえば、デバイスは、第１のビューポートサイズ１１０２がビューポート切替えイベントの前にｎミリ秒以内に２^-16度のｍ単位よりも大きく変化しないとき、第１のビューポートが安定していると判定し得、デバイスは、ｓｅｃｏｎｄ＿ｖｉｅｗｐｏｒｔサイズ１１０８がビューポート切替えイベントの後にｎミリ秒以内に２^-16度のｍ単位よりも大きく変化しないとき、第２のビューポートが安定していると判定し得る。

デバイスは、デバイスの運動の変化の後に、表示されるビューポートの品質が品質しきい値に回復するのに要するレイテンシまたは時間を示すためのメトリックを生成し得る。たとえば、デバイスが第１のビューポートから第２のビューポートに運動した後に、デバイスは、たとえば、第２のビューポートの品質が品質しきい値に達したときの、第１のビューポートと第２のビューポートとの間の時間間隔に基づいて、品質ビューポート切替えレイテンシメトリックを判定し得る。たとえば、第２のビューポートの品質が、第１のビューポートの品質、または第１のビューポートの品質よりも良いおよび／もしくはそれより高い品質に達したとき、品質ビューポート切替えレイテンシメトリックは、等品質ビューポート切替えレイテンシメトリックによって表され得る。等品質ビューポート切替えレイテンシメトリックは、品質ビューポート切替えレイテンシメトリックのサブセットであり得る。品質ビューポート切替えレイテンシメトリックについて、第２のビューポートの品質は、第１のビューポートの品質に達することも、達しないこともある。第２のビューポートの品質は、第１のビューポートの品質より低いが、品質しきい値より高いことがあり得る。デバイスは、品質しきい値を用いて構成されるか、または（たとえば、メトリックサーバから）品質しきい値を受信し得る。デバイスは、品質しきい値を判定もしくは指定し、および／または品質しきい値をメトリックサーバに報告し得る。

品質しきい値は、複数（たとえば、２つ）の品質の間の差を使用して定義され得る。たとえば、品質しきい値は、第１のビューポートの品質と第２のビューポートの品質との間の差（たとえば、品質または品質ランキングの絶対差、または絶対値の間の差）がしきい値以下であるとき、達し得る。

デバイスは、現在のビューポートから異なるビューポートに切り替わったとき、およびその異なるビューポートが現在のビューポートと同じまたは同様のプレゼンテーション品質に達するまでデバイスが経験するレイテンシを示すためのメトリックを生成し得る。たとえば、デバイスは、等品質ビューポート切替えレイテンシメトリックを判定し得る。メトリック「ＥＱＶｉｅｗｐｏｒｔＳｗｉｔｃｈｉｎｇＬａｔｅｎｃｙ」の等品質ビューポート切替えレイテンシメトリック報告は、現在のビューポートから異なるビューポートに切り替わったとき、およびその異なるビューポートが現在のビューポートと同じもしくはそれより高い品質に達するまで、またはその異なるビューポートが、品質しきい値を超えるが現在のビューポートの品質より低い品質レベルに達するまでデバイスが経験するレイテンシを示し得る。メトリックサーバは、たとえば、閲覧者のＱｏＥを測定するために等品質ビューポート切替えレイテンシメトリックを使用し得る。表６は、等品質ビューポート切替えレイテンシメトリックに関する例示的な報告を示す。デバイスまたはメトリックサーバは、ＯＰ３および／またはＯＰ４から等品質ビューポート切替えレイテンシメトリックおよび／または表６に示されているエントリのうちの１つもしくは複数を導出し得る。

表６は、等品質ビューポート切替えレイテンシメトリックに関する報告の例示的なコンテンツを示す。

たとえば、ユーザは、品質（たとえば、高品質（ＨＱ））においてビューポートＡを見得るが、そのとき、ユーザは、ビューポートＢを見るために彼／彼女の頭部を運動させる。ビューポートＢの品質は、異なる品質（たとえば、ビューポート適応ストリーミングにより低品質（ＬＱ））であり得る。動き検出、ビューポート要求スケジューリング、およびネットワーク条件のうちの１つまたは複数に応じて、ビューポートＢの品質をＬＱからＨＱに高めるのに時間を要し得る。ユーザは、ビューポートＢの品質がＬＱからＨＱに高まる前に、彼女の頭部をビューポートＣに運動させ得る。品質ビューポート切替えレイテンシメトリックは、ディスプレイ（たとえば、ＨＭＤディスプレイまたは従来のディスプレイ）上での、第１の品質におけるビューポートＡのプレゼンテーションから、品質しきい値より高い品質におけるビューポートＢおよび／またはビューポートＣのプレゼンテーションへの切り替わりの間の時間に対応し得る。等品質ビューポート切替えレイテンシメトリックは、ディスプレイ（たとえば、ＨＭＤディスプレイまたは従来のディスプレイ）上での、第１の品質におけるビューポートＡのプレゼンテーションから、ビューポートＡの第１の品質と同じであるかまたはそれより高い品質におけるビューポートＢおよび／またはビューポートＣのプレゼンテーションへの切り替わりの間の時間に対応し得る。品質しきい値は、第１の品質ビューポートＡ未満であり得る。品質しきい値は、ビューポートＡの第１の品質とビューポートＢおよび／またはビューポートＣの品質との間の差（たとえば、品質または品質ランキングの絶対差、または絶対値の間の差）がしきい値以下であるとき、達し得る。

メトリック「ＥＱＶｉｅｗｐｏｒｔＳｗｉｔｃｈｉｎｇＬａｔｅｎｃｙ」のエントリ（たとえば、エントリ「並進」）は、複数（たとえば、３）の自由度、前／後、上／下、左／右でＨＭＤ位置並進を含み（たとえば、指定し）得、および／またはベクトル（たとえば、定数ベクトル（Δｘ、Δｙ、Δｚ））によって表され得る。エントリ（たとえば、エントリ「回転」）は、複数（たとえば、３）の自由度（たとえば、ヨー、ピッチおよびロール）でＨＭＤ円運動を含み（たとえば、指定し）得、ならびに／またはベクトル（たとえば、定数ベクトル（Δヨー、Δピッチ、Δロール））によって表され得る。エントリ（たとえば、エントリ「ｑｕａｌｉｔｙ＿ｒａｎｋｉｎｇ」）は、（たとえば、終了点における）ビューポート切替えの後にユーザに対してレンダリングされているビューポートの品質を含み（たとえば、指定し）得る。ビューポートの品質は、プレゼンテーションの品質を示し得る。品質ランキング値がより高くなるほど、プレゼンテーションの品質はより低くなる。エントリ（たとえば、エントリ「レイテンシ」）は、入力された並進および／または回転運動と、ＶＲプレゼンテーション上で更新される対応するビューポートの品質との間の遅延を含み（たとえば、指定し）得る。

ビューポートは複数の領域によってカバーされ得る。ビューポートは、１つまたは複数のＤＡＳＨビデオセグメントの１つまたは複数の部分を備え得る。たとえば、ビューポートは、複数のＤＡＳＨビデオセグメントに基づく複数の領域によってカバーされ得る。領域は、１つもしくは複数のＤＡＳＨビデオセグメント、または１つもしくは複数のＤＡＳＨビデオセグメントの１つもしくは複数の部分から組み立てられ得る。ビューポートは品質によって定義され得る。領域（たとえば、各領域）は、たとえば、１つまたは複数の領域的品質ランキング（ＲＷＱＲ）に基づく品質ランキング値によって示される、品質によって定義され得る。領域は、シングルレイヤ表現の独立してコーディングされたサブピクチャ（たとえば、ビデオセグメント）および／または領域的品質ランキング領域であり得る。デバイスまたはメトリックサーバは、領域の品質の平均として、（たとえば、品質ランキング値によって示される）ビューポートの品質を導出し得る。領域の品質は、領域の品質ランキング値、またはビューポートがそれらから組み立てられる領域の品質ランキング値の中の最小もしくは最大品質ランキング値に基づいて判定され得る。ビューポートの品質は、たとえば、ビューポートがそれから組み立てられる各それぞれの領域またはビデオセグメントの品質の加重平均として計算され得る。ビューポートの品質は、たとえば、ビューポートがそれから組み立てられる各それぞれの領域またはビデオセグメントの（たとえば、品質ランキング値によって示される）品質の加重平均として計算され得る。重みは、各それぞれの領域によってカバーされているビューポートのエリア、サイズ、および／または部分に対応し得る。ビューポートの品質は、品質レベル、品質値、および／または品質ランキングによって示され得る。

図１２は、サブピクチャベースのストリーミングの一例である。サブピクチャは、１つもしくは複数のＤＡＳＨビデオセグメント、またはＤＡＳＨビデオセグメントの１つもしくは複数の部分に対応し得る。図１２では、ビューポートは４つのサブピクチャから構成され得、各サブピクチャは、（たとえば、品質ランキング値によって示される）そのサブピクチャ自体の品質を有する。たとえば、サブピクチャＡ１２０２の品質ランキング値は１であり得、サブピクチャＢ１２０４の品質ランキング値は３であり得、サブピクチャＣ１２０６の品質ランキング値は２であり得、サブピクチャＤ１２０８の品質ランキング値は５であり得る。サブピクチャのカバレージは、対応するサブピクチャによってカバーされるビューポートエリアの割合によって表され得る。図１２に示されているように、ビューポートエリアの７０％はサブピクチャＡ１２０２によってカバーされ得、ビューポートエリアの１０％はサブピクチャＢ１２０４によってカバーされ得、ビューポートエリアの１５％はサブピクチャＣ１２０６によってカバーされ得、ビューポートエリアの５％はサブピクチャＤ１２０８によってカバーされ得る。ビューポートの品質は、たとえば、式３を使用して計算され得る。品質（ビューポート）は、ビューポートの品質ランキング値を表し得る。品質（サブピクチャ（ｎ））は、サブピクチャｎの品質ランキング値を表し得る。カバレージ（サブピクチャ（ｎ））は、ビューポート中のサブピクチャｎのエリアの割合を表し得る。

式４は、式３を使用して導出される図１２におけるビューポートの品質ランキング値の一例を提供する。
品質（ビューポート）＝品質（サブピクチャＡ）＊カバレージ（サブピクチャＡ）＋品質（サブピクチャＢ）＊カバレージ（サブピクチャＢ）＋品質（サブピクチャＣ）＊カバレージ（サブピクチャＣ）＋品質（サブピクチャＤ）＊カバレージ（サブピクチャＤ）＝１＊０．７＋３＊０．１＋２＊０．１５＋５＊０．０５＝１．５５ 式４

図１３は、ビューポートが高品質領域（たとえば、領域Ａ１３０６）と低品質領域（たとえば、領域Ｂ１３０４）の両方によってカバーされる領域的品質ランキング（ＲＷＱＲ）符号化事例の一例である。領域品質は、対応するＲＷＱＲ値によって示され得る。領域Ａ１３０６のＲＷＱＲ値は１であり得る。領域Ｂ１３０４のＲＷＱＲ値は５であり得る。ビューポートの９０％が領域Ａによってカバーされ得、ビューポートの１０％が領域Ｂ１３０４によってカバーされ得る。ビューポートの品質ランキング値は、たとえば、式５を使用して計算され得る。
品質（ビューポート）＝品質（領域Ａ）＊カバレージ（領域Ａ）＋品質（領域Ｂ）＊カバレージ（領域Ｂ）＝１＊０．９＋５＊０．１＝１．４ 式５

品質ビューポート切替えイベントは、デバイスによってレンダリングされている第２のビューポートの品質がしきい値品質より高いときに識別され得る。たとえば、品質ビューポート切替えイベントは、レンダリングされている第２のビューポートの品質ランキング値が、切替えの前にレンダリングされている第１のビューポートの品質ランキング値以下であるときに識別され得る。等品質ビューポート切替えイベントは、レンダリングされている第２のビューポートの品質ランキング値が、ビューポート切替えイベントの前の第１のビューポートの品質ランキング値よりも小さいときに識別され得る。

ＥＱＶｉｅｗｐｏｒｔＳｗｉｔｃｈｉｎｇＬａｔｅｎｃｙは、配向変化について等品質ビューポート切替えイベントに関連するレイテンシを定義するために使用され得る。ＥＱＶｉｅｗｐｏｒｔＳｗｉｔｃｈｉｎｇＬａｔｅｎｃｙは、デバイス（たとえば、デバイスのセンサー）が第１のビューポートから第２のビューポートへのユーザ配向変化を検出する時間（たとえば、本明細書のビューポート切替えは等品質ビューポート切替えとして識別され得る）と、第２のビューポートが、第１のビューポートの品質と同じまたは同様の品質でユーザに対して完全にレンダリングされる時間との間の時間間隔であり得る。

図１４は、等品質ビューポート切替えイベントの一例を示す。デバイスは、サブピクチャＡ～Ｆなど、複数のサブピクチャ（たとえば、ＤＡＳＨビデオセグメント）を受信し、復号し得る。サブピクチャＡ～Ｆは、それぞれのビデオセグメント、および（たとえば、品質ランキング値によって示される）それぞれの品質に対応し得る。デバイスは、サブピクチャＢおよびＣを使用してビューポート＃１を生成し得る。デバイスは、ユーザのためにデバイスのディスプレイ上にビューポート＃１をレンダリング（たとえば、表示）し得る。デバイスまたはメトリックサーバは、サブピクチャＢおよびＣの品質ランキング値からビューポート＃１の品質ランキング値を導出し得る。サブピクチャＢおよびＣの品質ランキング値は、ビューポート適応ストリーミングシナリオでは、サブピクチャＡ、Ｄ、ＥおよびＦの品質ランキング値よりも（たとえば、通常）低くなり得る。図１４（ｂ）に示されているように、デバイスが運動し、ユーザ閲覧配向がビューポート＃１からビューポート＃２に運動したとき、ビューポート＃２は、サブピクチャＢおよびＣによってカバーされ得る。ビューポート＃２のサブピクチャＢおよびＣは、ビューポート＃１を作成するために使用されるサブピクチャＢおよびＣと同じであるかまたは異なり得る。ビューポート＃２は、ビューポート＃１の品質と同じ品質を有し得るか、またはビューポート＃２は、ビューポート＃１の品質とは異なる品質を有し得る。デバイスまたはメトリックサーバは、サブピクチャＢおよびＣの品質ランキング値からビューポート＃２の（たとえば、品質ランキング値によって示される）品質を導出し得る。

図１４（ｃ）に示されているように、デバイスが運動し、ユーザ閲覧配向をビューポート＃２からビューポート＃３に運動させたとき、ビューポート＃３は、サブピクチャＣおよびＤによってカバーされ得る。ビューポート＃３を生成するために使用されるサブピクチャＣおよびＤは、クライアントがビューポート＃１および／またはビューポート＃２を提示するときにクライアントによって要求されるサブピクチャＣおよびＤと同じであるかまたは異なり得る。サブピクチャＣおよびＤは、ビューポート＃１およびビューポート＃２を生成するために使用されないことがある。サブピクチャＣおよびＤは、変化（たとえば、急激な閲覧配向変化）を扱うことを要求され得る。デバイスまたはメトリックサーバは、サブピクチャＣおよびＤの品質ランキングからビューポート＃３の品質を導出し得る。デバイスは、ビューポート＃３の品質を、ビューポート＃１、ビューポート＃２の品質、および／またはビューポート＃２の品質より高いがビューポート＃１の品質より低い品質しきい値と比較し得る。デバイスは、たとえば、ビューポート＃３の品質がビューポート＃１の品質より低いかまたはしきい値より低いとデバイスが判定した場合、より良い品質をもつサブピクチャＤの異なる（たとえば、新しい）表現を要求し得る。より良い品質は、たとえば、サブピクチャＤの元の品質ランキング値よりも低品質のランキング値によって表され得る。デバイスは、たとえば、サブピクチャＤの異なる（たとえば、新しい）表現が受信され、ビューポート＃３を生成するために使用されたとき、ビューポート＃３の品質が品質しきい値より高い、またはビューポート＃１の品質以上であるとデバイスが判定したとき（たとえば、等品質ビューポート切替えイベント）、品質ビューポート切替えイベントを判定および／または報告し得る。

図１５は、たとえば、ズーム動作中に等品質ビューポート切替えレイテンシを測定するための３６０°ズームの例を示す。デバイスは、サブピクチャＡ、Ｂ、Ｃ、Ｄ、Ｅ、およびＦなど、複数のサブピクチャを要求し、受信し得る。デバイスは、１５１０に示されているようにサブピクチャＢおよびＣを使用して第１のビューポートを生成し得る。サブピクチャＢおよびＣは高品質サブピクチャであり得る。デバイスは、１５２０に示されているようにズームへの入力を受信し、応答して、第２のビューポートを生成し、表示し得る。第２のビューポートは、サブピクチャＡ、Ｂ、ＣおよびＤにわたる球面領域を含み得る。サブピクチャＢおよびＣは高品質であり得、サブピクチャＡおよびＤは低品質であり得る。したがって、第２のビューポートは、第１のビューポートの品質より低い品質によって定義され得る。デバイスは、１５３０に示されているようにより高い品質（たとえば、より小さい品質ランキング値）をもつサブピクチャＡおよびＤの異なる（たとえば、新しい）表現を要求し、サブピクチャＡおよびＤを低品質から高品質に切り替え、図１５（ｃ）に示されているように、第２のビューポート全体を高品質で生成し得る。

デバイスは、たとえば、等品質ビューポート切替えイベントを判定するために以下のうちのどの１つまたは複数が使用されるかに応じて、たとえば、図１５（ａ）と図１５（ｃ）との間の時間間隔、または図１５（ｂ）と図１５（ｃ）との間の時間間隔に基づいて、ＥＱＶｉｅｗｐｏｒｔＳｗｉｔｃｈｉｎｇＬａｔｅｎｃｙメトリックを生成し得る。ＥＱＶｉｅｗｐｏｒｔＳｗｉｔｃｈｉｎｇＬａｔｅｎｃｙは、第２のビューポート位置におけるユーザの閲覧配向のセンサー検出からの（たとえば、ミリ秒での）時間、および第２のビューポートコンテンツが、以前にレンダリングされている第１のビューポートの品質以上である品質でユーザに対して完全にレンダリングされる時間として測定され得る。ＥＱＶｉｅｗｐｏｒｔＳｗｉｔｃｈｉｎｇＬａｔｅｎｃｙは、第２のビューポート位置におけるユーザの閲覧配向のセンサー検出からの（たとえば、ミリ秒での）時間、および第２のビューポートコンテンツが、第１のビューポートがレンダリングされたときの第２のビューポートの品質よりも高い品質でユーザに対して完全にレンダリングされる時間として測定され得る。

メトリック計算および報告モジュールは、（たとえば、ＲＷＱＲ値の代わりに）対応する表現の相対的品質を判定するためにＤＡＳＨ ＭＰＤ中でシグナリングされる表現ビットレートおよび／または解像度を使用し得る。デバイス（たとえば、メトリック計算および報告モジュール）は、ビューポートをカバーするために要求、復号、またはレンダリングされている表現（たとえば、各表現）のビットレートおよび／または解像度からビューポートの品質を導出し得る。表現が提示されないとき、表現の品質は、デフォルトで最も高い品質ランキング値として導出され得る。

デバイス（たとえば、ＶＲデバイス）は、初期レイテンシメトリックおよびメッセージを生成し、報告し得る。デバイスは、頭部動きの開始と、ＶＲドメインにおける対応するフィードバックのそれとの間の時間差を示すためのメトリックを使用し得る。メトリックは、（たとえば、ＨＭＤが使用されるときの）初期レイテンシメトリックを含み得る。ビューポート切替えレイテンシと比較して、初期レイテンシは、（たとえば、センサーなどに基づく）ＨＭＤ依存の遅延を有することがある。表７は、初期レイテンシメトリックに関する報告の例示的なコンテンツを示す。デバイスまたはメトリックサーバは、ＯＰ３および／またはＯＰ４から初期レイテンシメトリックおよび／または表７に示されているエントリのうちの１つもしくは複数を導出し得る。

表７は、初期レイテンシメトリックに関する報告の例示的なコンテンツを示す。

デバイスは、頭部動きの停止と、ＶＲドメインにおける対応するフィードバックのそれとの間の時間差を示すためのメトリックを使用し得る。メトリックは、（たとえば、ＨＭＤを使用しているときの）整定レイテンシメトリックを含み得る。表８は、整定レイテンシメトリックに関する報告の例示的なコンテンツを示す。デバイスまたはメトリックサーバは、ＯＰ３および／またはＯＰ４から整定レイテンシメトリックおよび／または表８に示されているエントリのうちの１つもしくは複数を導出し得る。

デバイス（たとえば、ＶＲデバイス）は、たとえば、あらゆる閲覧者頭部動きおよび／またはビューポート変化について個々にレイテンシメトリックを報告し得る。デバイスは、たとえば、ある間隔で、所定の時間期間にわたって平均値を計算および／または報告し得る。メトリックサーバは、レイテンシメトリックに基づいて異なるＶＲデバイスのレイテンシ性能を測定し得る。メトリックサーバは、ＶＲデバイス固有の特徴がどのくらいユーザ満足度に影響を及ぼすのかを判定するために、レイテンシメトリックを、コンテンツタイプ、総閲覧時間、およびビューポート変化の頻度のうちの１つまたは複数を含む他のデータと相関させ得る。メトリックサーバは、たとえば、ＨＭＤをベンチマークしおよび／またはベンダーにフィードバックを提供するために、初期レイテンシおよび整定レイテンシを使用し得る。

デバイス（たとえば、ＨＭＤ、電話、タブレットまたは、パーソナルコンピュータ）は、１つまたは複数のＤＡＳＨビデオセグメントを要求し、異なる品質をもつ様々なビューポートとしてＤＡＳＨビデオセグメントを表示し得る。デバイスは、異なるタイプのレイテンシを判定し、レイテンシメトリックとしてレイテンシを報告し得る。デバイスは、現在のビューポートを表示することと、異なる時間点との間の時間差に基づいてレイテンシメトリックを判定し得る。時間点は、デバイスが運動し始めること、デバイスが運動するのを中止すること、デバイスが運動し始めたとプロセッサが判定すること、デバイスが運動するのを停止したとプロセッサが判定すること、または異なるビューポートおよび／もしくは異なる品質の表示のうちの１つまたは複数を含み得る。

図１６は、ＤＡＳＨクライアント（たとえば、ＶＲデバイス）によって報告され得る例示的なレイテンシ間隔を示す。ユーザの頭部／デバイス（たとえば、ＨＭＤ）は、時間ｔ０においてビューポート＃１からビューポート＃２に運動し始め得る。ユーザは、ｔ０において（たとえば、ＨＱで）ビューポート＃１を見得る。デバイスは、ｔ１（ｔ１＞＝ｔ０）においてビューポート＃１からビューポート＃２への運動を検出し得、および／またはＨＭＤの運動に基づいて働き得る。ビューポート＃１からビューポート＃２への運動は、ユーザのＱｏＥに影響を及ぼし得る。たとえば、デバイスは、（たとえば、ＨＭＤディスプレイ上で）そのような頭部運動を反映し得、ビューポート＃１の品質は、ｔ１の後に低下し得る。ｔ０とｔ１との間のレイテンシは、異なるデバイスに応じて（たとえば、センサー、プロセッサなどにより）変動し得る。動き（たとえば、頭部運動）が微細である（たとえば、しきい値よりも小さい）場合、デバイスは動きを検出し得るが、動きに基づいて働かなくてよい。頭部またはデバイスは、ｔ２においてビューポート＃２上に停止し得る。デバイスは、ｔ３（ｔ３＞＝ｔ２）においてビューポート＃２を検出し、ビューポート＃２に基づいて働き得る。たとえば、ｔ３において、デバイスは、ＨＭＤが、所定の時間量（たとえば、ｎミリ秒）の間、ビューポート＃２に関連する位置において停止したと判定し得る。ユーザは、ｔ４においてＨＭＤ（たとえば、ＨＭＤのディスプレイ）のビューポートシフトおよび／または品質変化を観測し得る。ｔ４は、時間的にｔ２よりも小さいか、またはそれの前にあり得る（たとえば、ユーザは彼の頭部を運動させたままであり得る）。ビューポート変化は（たとえば、ｔ５において）完了し得、デバイスは、ｔ５において初期の低品質ビューポートにおいて表示し得る。デバイスにおいて表示される品質が回復し得る。たとえば、デバイスは、ビューポート＃２を生成するためにより高品質で１つまたは複数のビデオセグメント（たとえば、ＤＡＳＨセグメント）を要求し得る。したがって、ビューポート＃２の品質は、高品質（たとえば、ｔ６（ｔ６＞＝ｔ５）において、以前のビューポート＃１の品質と同じ品質、または以前のビューポート＃１より高い品質）になり得る。デバイス（たとえば、メトリック収集および処理（ＭＣＰ）モジュール）は、ＯＰ３から入力タイミング情報を、および／またはＯＰ４においてビューポートプレゼンテーションを収集し得る。デバイス（たとえば、ＭＣＰ要素）は、たとえば、時間ｔ１～ｔ６のうちの１つまたは複数に基づいて、（たとえば、図７のクライアント参照モデルに示されているように）メトリックサーバに報告されるべき、対応するレイテンシメトリックを導出し得る。

様々なレイテンシパラメータは、たとえば、ＶＲデバイスによって測定され得る。ビューポート切替えレイテンシは、ｔ５とｔ１との間の時間差に対応し得る。等品質ビューポート切替えレイテンシは、ｔ６とｔ１との間の時間差に対応し得る。初期レイテンシはｔ４－ｔ０に対応し得る。整定レイテンシは、ｔ５とｔ２との間の時間差に対応し得る。一実施形態では、時間点（たとえば、図１６における特定の時間）がデバイスによって記録および／または報告され得る。たとえば、デバイスはメトリック報告を生成し得、メトリック報告は、頭部動きを検出するとｔ０、ｔ１、ｔ２、ｔ３、ｔ４、ｔ５、およびｔ６を示し得る。

デバイスは、ユーザのロケーション上で指示するためのメトリックを使用し得る。メトリックは、たとえば、表９に記載されているように、６ＤｏＦ座標メトリックを含み得る。デバイス（たとえば、ＶＲデバイス）は、たとえば、メトリックサーバに、６ＤｏＦ座標メトリックを報告し得る。ローカルセンサーは、ユーザのロケーションを提供し得る。デバイスは、ユーザのロケーションおよび／またはＨＭＤビューポートデータに基づいて６ＤｏＦ座標を抽出し得る。６ＤｏＦ位置は、ユーザのＨＭＤの３Ｄ座標（たとえば、Ｘ、Ｙ、Ｚ）を介して表され得る。６ＤｏＦ位置は、ＶＲ空間中のコントローラ位置と、ユーザのＨＭＤまたはコントローラの相対球面座標（たとえば、ヨー、ピッチおよびロール、球面座標中心はＸ、ＹおよびＺであり得る）とを介して表され得る。デバイスまたはユーザは、ユーザが複数のコントローラを装備しているとき、複数の６ＤｏＦ位置をシグナリングし得る。表９は、６ＤｏＦ座標に関する報告の例示的なコンテンツを示す。デバイスまたはメトリックサーバは、ＯＰ３から６ＤｏＦ座標メトリックおよび／または表９に示されているエントリのうちの１つもしくは複数を導出し得る。

デバイス（たとえば、ＶＲデバイス）は視線データを報告し得る。メトリックサーバは、（たとえば、広告をターゲットにする）分析のために視線データを使用し得る。表１０は、視線データに関する報告の例示的なコンテンツを示す。デバイスまたはメトリックサーバは、ＯＰ３から視線データメトリックおよび／または表１０中に含まれるエントリのうちの１つもしくは複数を導出し得る。デバイスは、タイルベースストリーミングをどのように構成および／または改善すべきか（たとえば、タイル構成を選定すること）を決定するために視線データを使用し得る。

デバイス（たとえば、ＶＲデバイス）はフレームレートメトリックを報告し得る。レンダリングされるフレームレートは、ネイティブフレームレートとは異なり得る。表１１は、レンダリングされるフレームレートに関する報告の例示的なコンテンツを示す。デバイスまたはメトリックサーバは、ＯＰ４からフレームレートメトリックおよび／または表１１中に含まれるエントリのうちの１つもしくは複数を導出し得る。

パケット／フレームロス比、フレームエラー比、および／またはフレーム廃棄比などの一般システムサービス品質（ＱｏＳ）メトリックまたはパラメータは、（たとえば、従来のビデオストリーミングの）サービス品質を表し得る。一般ＱｏＳメトリックは、何らかのストリーミングについて（たとえば、タイルベースストリーミングなどのビューポート依存３６０度ビデオストリーミングについて）ＶＲユーザエクスペリエンスを反映しないことがある。従来のビデオストリーミングでは、一部または全部のパケットまたはフレームは、ユーザエクスペリエンスに対して同様のまたは等しい影響を有し得る。タイルベースストリーミングなどのビューポート依存３６０度ビデオストリーミングでは、ユーザエクスペリエンスは、ユーザに提示されるビューポートによって判定され（たとえば、部分的にまたは主に判定され）得る。タイルベースストリーミングなどのビューポート依存３６０度ビデオストリーミングでは、他の非ビューポートタイルのパケットまたはフレームロスは、ユーザエクスペリエンスに影響を及ぼさないことがある。たとえば、ユーザは、他の非ビューポートタイルを見ないことがある。ユーザが見るビューポートタイルのパケットまたはフレームロスは、ユーザエクスペリエンスに影響を及ぼし（たとえば、それに有意な影響を有し）得る。一般ＱｏＳメトリックはＶＲユーザエクスペリエンスを反映しないことがある。

デバイスは、ビューポートロスイベントを示すためのメトリックを使用し得る。メトリックは、たとえば、表１２に記載されているビューポートロスメトリックを含み得る。デバイスは、（たとえば、タイルベースストリーミングなどのビューポート依存３６０度ビデオストリーミングの）ユーザエクスペリエンス分析のためのビューポートロスイベントを報告するためにビューポートロスメトリックを使用し得る。たとえば、クライアントは、ロスイベントが、ユーザに表示されるビューポートに影響を及ぼしたか否かを判定し得、および／またはＶｉｅｗｐｏｒｔＬｏｓｓメトリックを介して、表示されるビューポートに影響を及ぼしたロスイベントのみを報告し得る。ビューポートロスメトリックは、表１２に示されているように、ロスが観測された時間を示すタイミング情報および／または他のロス情報のうちの１つまたは複数を含み得る。デバイスまたはメトリックサーバは、ＯＰ１および／またはＯＰ３からビューポートロスメトリックおよび／または表１２中に含まれるエントリのうちの１つもしくは複数を導出し得る。

ＶｉｅｗｐｏｒｔＬｏｓｓメトリックは、ビューポートセグメントロスのイベントを報告し、および／またはロスステータスに関する情報もしくは追加の情報を提供し得る。エントリ（たとえば、「ｓｏｕｒｃｅＵｒｌ」のエントリ）は、失われたビューポートセグメントのＵＲＬを示し（たとえば、指定し）得る。エントリ（たとえば、「ｌｏｓｓｒｅａｓｏｎ」のエントリ）は、たとえば、本明細書で説明される理由のうちの１つまたは複数を含む、セグメントロスの原因（たとえば、原因）を示し得る。

ＶｉｅｗｐｏｒｔＬｏｓｓメトリックのエントリ（たとえば、エントリ「サーバエラー」）は、サーバがビューポートセグメント要求（たとえば、特定のビューポートセグメント要求）を遂行することに失敗する理由を示し（たとえば、指定し）得る。ＨＴＴＰ応答ステータス５ｘｘサーバエラーコードのリスト、たとえば、「ゲートウェイタイムアウト」の５０４、「サポートされないＨＴＴＰバージョン」の５０５などが使用され得る。ＶｉｅｗｐｏｒｔＬｏｓｓメトリックのエントリ（たとえば、エントリ「クライアントエラー」）は、クライアントが（たとえば、特定の）ビューポートセグメントを要求したときのクライアントエラーを示し（たとえば、指定し）得る。ＨＴＴＰ応答ステータス４ｘｘクライアントエラーコードのリスト、たとえば、「無認可」の４０１、「見つからない」の４０４などが使用され得る。ＶｉｅｗｐｏｒｔＬｏｓｓメトリックのエントリ（たとえば、エントリ「パケットロス」）は、ｓｏｕｒｃｅＵｒｌに関連するビューポートセグメントの１つまたは複数のパケットがそれらの宛先に達することに失敗することを示し（たとえば、指定し）得る。ＶｉｅｗｐｏｒｔＬｏｓｓメトリックのエントリ（たとえば、エントリ「パケットエラー」）は、ｓｏｕｒｃｅＵｒｌに関連するビューポートセグメントの１つまたは複数のパケットが無効であることを示し（たとえば、指定し）得る。ＶｉｅｗｐｏｒｔＬｏｓｓメトリックのエントリ（たとえば、エントリ「パケット廃棄」）は、ｓｏｕｒｃｅＵｒｌに関連するビューポートセグメントの１つまたは複数のパケットが廃棄されることを示し（たとえば、指定し）得る。ＶｉｅｗｐｏｒｔＬｏｓｓメトリックのエントリ（たとえば、エントリ「エラー」）は、詳細な（たとえば、さらに詳細な）エラーメッセージを提供し得る。たとえば、フィールド「エラー」は、「ゲートウェイタイムアウト」に対応する５０４、「サポートされないＨＴＴＰバージョン」に対応する５０５、「無認可」に対応する４０１、「見つからない」に対応する４０４など、ＨＴＴＰ応答エラーコードを提供し得る。本明細書で説明されるＶｉｅｗｐｏｒｔＬｏｓｓメトリックを用いて、メトリックサーバは、ＶＲユーザエクスペリエンスに対するネットワーク条件の影響を分析し、および／または根本原因を追跡することが可能であり得る。

デバイス（たとえば、ＶＲデバイス）は、精度および／または感度などのＨＭＤ関係のメトリックを生成および／または報告し得る。デバイスは、物理的運動と、ＶＲドメインにおける視覚的フィードバックとの間の角度位置決め一貫性を度に関して示すためのメトリックを使用し得る。メトリックは精度メトリックを含み得る。表１３は、ＨＭＤ精度に関する報告の例示的なコンテンツを示す。デバイスまたはメトリックサーバは、ＯＰ３および／またはＯＰ５から精度メトリックおよび／または表１３中に含まれるエントリのうちの１つもしくは複数を導出し得る。

たとえば、時間ｔにおいて、ユーザの頭部は座標Ａに向けられることがあるが、ユーザに表示される像は座標Ｂを反映することがある。精度メトリックは差（たとえば、座標Ｂ－座標Ａ）に対応し得る。たとえば、ユーザは、彼／彼女の頭部を右側に３度運動させることがあり、ＨＭＤ上に表示される像は、ユーザが右側に２．５度および下に０．２度運動させたことを反映することがある。精度メトリックは、測定された差、たとえば、水平０．５度差および垂直０．２度差を示し得る。メトリックはこの差を報告し得る。差はΔ座標の形式（たとえば、ベクトル）であり得る。差は絶対差の形式（たとえば、単一の値）であり得る。ＨＭＤおよび／またはコントローラが精度メトリックを提供し得る。ＨＭＤはＶＲデバイス中に備えられ得る。そのようなΔ値は、センサーとユーザとの間の距離に応じて変動し得る。

デバイスは、微細な動きを知覚し、その後、ユーザにフィードバックを提供するために、ＨＭＤ慣性センサーの能力を示すためのメトリックを使用し得る。メトリックは感度メトリックを含み得る。表１４は、ＨＭＤ感度に関する報告の例示的なコンテンツを示す。デバイスまたはメトリックサーバは、ＯＰ３および／またはＯＰ５から感度メトリックおよび／または表１４中に含まれる１つもしくは複数のエントリを導出し得る。

デバイスおよび／またはメトリックサーバは、様々な仕方で精度および感度を使用し得る。コンテンツプロバイダまたはサーバは、ＨＭＤの精度および／または感度に基づいてカスタマイズされたコンテンツ推奨をユーザに供給し得る。コンテンツプロバイダ、サーバ、またはデバイスは、ＶＲデバイスモデル／ブランドレベルで精度および／もしくは感度メトリックを収集し得、ならびに／またはメトリックを（たとえば、ＶＲデバイスの）製造業者と共有して、問題を修正しおよび／またはデバイスを改善し得る。

デバイス（たとえば、ＶＲデバイス）は、ＰＥＲメッセージとして精度および／または感度を送り得る。ＤＡＮＥは、（たとえば、ＶＲデバイスを含む）ＤＡＳＨクライアントに精度および／または感度メッセージを送り得る。デバイスまたはＤＡＮＥは、選択されたコンテンツのための適切な精度／感度設定を、構成可能なＨＭＤに送り得る。選択されたコンテンツについての閲覧者の閲覧エクスペリエンスが拡張され得る。表１５は、精度メッセージの例示的なコンテンツを示す。表１６は、感度メッセージの例示的なコンテンツを示す。

デバイス（たとえば、ＶＲデバイス）は、ＲＯＩ関係のメッセージを生成し得る。ＲＯＩメッセージはＰＥＲタイプであり得る。ＲＯＩメッセージは、所望のＲＯＩを閲覧者に示し得る。ＤＡＳＨクライアントは、所望のＲＯＩを事前にプリフェッチし得る。ＲＯＩメッセージは、所望のＲＯＩを事前にプリフェッチするようにＤＡＳＨクライアントに指示し得る。ＲＯＩは時間とともに変化し得る。デバイスまたはコンテンツプロバイド（provide）は、ビューポートビュー統計からＲＯＩを推論し得る。デバイスまたはコンテンツプロバイドは、ＲＯＩ（たとえば、ディレクターズカット）を規定し得る。デバイスまたはコンテンツプロバイドは、リアルタイムの分析に基づいてＲＯＩを判定し得る。ＤＡＮＥは、ＤＡＳＨクライアントにＰＥＲメッセージとしてＲＯＩ情報を送り得る。ＲＯＩ情報に基づいて、ＤＡＳＨクライアントは、サーバからどのタイル／セグメント／バイト範囲をフェッチすべきかを判定し得る。たとえば、デバイスまたはメトリックサーバは、ＯＰ４からＲＯＩメッセージを導出し得る。

ＲＯＩは、アピール、重要性または品質に関して高い優先度のＶＲのエリア（たとえば、事前に決定を行うためのユーザへのヒント）を示し得る。ユーザは、一貫して前面を見ることがある。ＲＯＩメッセージとともに、ユーザは、別のエリアを見るようにプロンプトされ得るが、ビデオの前面を依然として見得る。

ＤＡＮＥは、プリフェッチングおよび改善されたキャッシング性能のためにＰＥＤメッセージとしてＲＯＩ情報を受信し得る。ＰＥＤメッセージにおいて、ＲＯＩが提供された場合、ＤＡＮＥは、どのタイル／セグメント／バイト範囲がフェッチされるべきかを判定し得る。ＰＥＤメッセージにおいて、特定のＵＲＬが提供され得る。ＲＯＩ情報メッセージはＤＡＮＥから別のＤＡＮＥに送られ得る。表１７は、ＲＯＩ情報メッセージの例示的なコンテンツを示す。

ＲＯＩ情報は、時間指定メタデータトラック中でまたはイベントストリーム要素中で搬送されることが可能である。

図１７は、ＤＡＮＥとＤＡＳＨクライアントとの間またはＤＡＳＨクライアントとメトリックサーバとの間のＳＡＮＤメッセージのメッセージフローを示す。ＤＡＮＥ１７０４（たとえば、オリジンサーバ）は、ＤＡＮＥ１７０６（たとえば、ＣＤＣ／キャッシュ）にビデオセグメントを送り得る。ＤＡＮＥ１７０６（たとえば、ＣＤＣ／キャッシュ）は、ＤＡＳＨクライアント１７０８にビデオセグメントを送り得る。ＤＡＳＨクライアント１７０８は、メトリックサーバ１７０２にメトリックを送り得る。メトリックは、ビューポートビュー、ｒｅｎｄｉｎｇｄｅｖｉｃｅ、ｖｉｅｗｐｏｒｔｓｗｉｔｃｈｉｎｇｌａｔｅｎｃｙ、ｉｎｉｔｉａｌｌａｔｅｎｃｙ、ｓｅｔｔｌｉｎｇｌａｔｅｎｃｙ、６ＤｏＦＣｏｏｒｄｉｎａｔｅｓ、ＧａｚｅＤａｔａ、フレームレート、精度、感度などのうちの１つまたは複数を含み得る。ＤＡＮＥ１７０４（たとえば、オリジンサーバ）は、ＤＡＳＨクライアント１７０８に情報（たとえば、ｉｎｉｔｉａｌｒｅｎｄｅｒｉｎｇｏｒｉｅｎｔａｔｉｏｎ、精度、感度、ＲＯＩなど）を送り得る。ＤＡＮＥ１７０６（たとえば、ＣＤＣ／キャッシュ）は、ＤＡＳＨクライアント１７０８に情報（たとえば、ｉｎｉｔｉａｌｒｅｎｄｅｒｉｎｇｏｒｉｅｎｔａｔｉｏｎ、精度、感度、ＲＯＩなど）を送り得る。ＤＡＳＨクライアント１７０８は、ＤＡＮＥ１７０６（たとえば、ＣＤＣ／キャッシュ）またはＤＡＮＥ１７０４（たとえば、オリジンサーバ）に情報（たとえば、レンダリングデバイス、ｖｉｅｗｐｏｒｔｓｗｉｔｃｈｉｎｇｌａｔｅｎｃｙ、ｆｒａｍｅｒａｔｅなど）を送り得る。

デバイスは、本明細書のメトリックおよび／またはメトリックの変化を検出し、導出し、ならびに／またはメトリックサーバ上での分析および／もしくは計算のためにメトリックサーバに報告し得る。ＶＲデバイス、メトリックサーバ、および／またはコントローラは、検出、導出、分析、および／または計算のうちの１つまたは複数を実施し得る。

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

Claims (10)

1. メディアコンテンツを受信し表示するためのデバイスであって、
   センサーコンポーネントと結合された第１のインターフェースであって、ユーザの配向と関連付けられた第１のメトリックデータであり、ユーザの頭部動きを示すデータを含む前記第１のメトリックデータを、前記センサーコンポーネントから、受信するように構成された前記第１のインターフェースと、
   レンダリングコンポーネントと結合された第２のインターフェースであって、動的適応ストリーミングオーバーＨＴＴＰ（ＤＡＳＨ）ビデオセグメントをレンダリングすることと関連付けられた第２のメトリックデータであり、メディアサンプルプレゼンテーションタイムスタンプを含む前記第２のメトリックデータを、前記レンダリングコンポーネントから、受信するように構成された前記第２のインターフェースと、
   プロセッサと
   を備え、前記プロセッサは、
   前記センサーコンポーネントと結合された前記第１のインターフェースを介して、前記ユーザの配向と関連付けられた前記第１のメトリックデータを受信し、
   前記レンダリングコンポーネントと結合された前記第２のインターフェースを介して、前記ＤＡＳＨビデオセグメントをレンダリングすることと関連付けられた前記第２のメトリックデータを受信し、
   前記ユーザの配向と関連付けられた前記第１のメトリックデータおよび前記ＤＡＳＨビデオセグメントをレンダリングすることと関連付けられた前記第２のメトリックデータに基づいて、レイテンシメトリックを生成し、
   前記レイテンシメトリックをメトリックサーバへ送信する
   ように構成された、デバイス。
2. 前記プロセッサがメトリック処理コンポーネントを備え、前記メトリック処理コンポーネントが、前記第１のインターフェース、および、前記第２のインターフェースと結合され、レイテンシメトリックが前記メトリック処理コンポーネントによって生成される、請求項１に記載のデバイス。
3. 前記レイテンシメトリックが、ネットワークからの前記ＤＡＳＨビデオセグメントを要求することおよび受信することと関連付けられたメトリックデータ、前記ネットワークから受信された前記ＤＡＳＨビデオセグメントをデコードすることと関連付けられたメトリックデータ、または、前記デバイスに対応する構成パラメータと関連付けられたメトリックデータのうちの１つにさらに基づいて生成される、請求項１に記載のデバイス。
4. 前記レイテンシメトリックが、ビューポート切替えレイテンシメトリック、品質ビューポート切替えレイテンシメトリック、初期レイテンシメトリック、および、整定レイテンシメトリックから構成されるグループから選択される、請求項１に記載のデバイス。
5. ネットワークアクセスコンポーネントが、前記第１のインターフェース、または、前記第２のインターフェースの少なくとも１つに通信ネットワークを介して結合された、請求項１に記載のデバイス。
6. 前記デバイスがバーチャルリアリティクライアントデバイスを含む、請求項１に記載のデバイス。
7. 前記レイテンシメトリックが、比較可能な品質ビューポート切替えレイテンシメトリックを含む、請求項１に記載のデバイス。
8. メディアコンテンツを受信し表示するための方法であって、
   センサーコンポーネントと結合された第１のインターフェースを介してユーザの配向と関連付けられた第１のメトリックデータを受信することであって、前記第１のインターフェースは前記第１のメトリックデータを前記センサーコンポーネントから受信するように構成されており、前記第１のメトリックデータはユーザの頭部動きを示すデータを含む、ことと、
   レンダリングコンポーネントと結合された第２のインターフェースを介して動的適応ストリーミングオーバーＨＴＴＰ（ＤＡＳＨ）ビデオセグメントをレンダリングすることと関連付けられた第２のメトリックデータを受信することであって、前記第２のインターフェースは前記第２のメトリックデータを前記レンダリングコンポーネントから受信するように構成されており、前記第２のメトリックデータはメディアサンプルプレゼンテーションタイムスタンプを含む、ことと、
   前記ユーザの配向と関連付けられた前記第１のメトリックデータおよび前記ＤＡＳＨビデオセグメントをレンダリングすることと関連付けられた前記第２のメトリックデータに基づいて、レイテンシメトリックを生成することと、
   前記レイテンシメトリックをメトリックサーバへ送信することと
   を含む、方法。
9. 前記レイテンシメトリックが、ネットワークからの前記ＤＡＳＨビデオセグメントを要求することおよび受信することと関連付けられたメトリックデータ、前記ネットワークから受信された前記ＤＡＳＨビデオセグメントをデコードすることと関連付けられたメトリックデータ、または、デバイスに対応する構成パラメータと関連付けられたメトリックデータのうちの１つを使用し生成される、請求項８に記載の方法。
10. 前記レイテンシメトリックが、ビューポート切替えレイテンシメトリック、品質ビューポート切替えレイテンシメトリック、初期レイテンシメトリック、および、整定レイテンシメトリックから構成されるグループから選択される、請求項８に記載の方法。

Images