JP2023030191A - 次世代ネットワークを介した３６０度ビデオ配信 - Google Patents

Abstract

【課題】３６０度ビデオストリーミングのためのシステム、方法および手段を提供する。
【解決手段】ビデオストリーミングデバイスはネットワークノードから３６０度ビデオストリームを受信し、当該デバイスおよび／または３６０度ビデオストリームに関連付けられたビューポートを決定できる。ビデオストリーミングデバイスは３６０度ビデオストリームの第１のセグメントおよび第２のセグメントを事前に要求することを（例えば、ビューポートに基づいて）決定し、第１のセグメントおよび第２のセグメントについて相対的な優先度の順序を決定できる。ビデオストリーミングデバイスは予期される要求メッセージを生成し、予期される要求メッセージをネットワークノードに送信できる。予期される要求メッセージは、例えば決定された相対的な優先度の順序に基づいて相対的な優先度を減少させることにより第１のセグメントおよび第２のセグメントをリストすることによって、決定された相対的な優先度の順序を示すことができる。
【選択図】図１７

Description

関連出願の相互参照
本出願は、その全体が参照により本明細書に組み込まれる、２０１７年６月２日に出願された米国仮特許出願第６２／５１４，４０５号の優先権を主張する。

３６０度ビデオは、メディア業界に出現した急速に成長しているフォーマットである。３６０度ビデオは、バーチャルリアリティ（ＶＲ）デバイスの、増大する利用可能性によって可能にされる。３６０度ビデオは、閲覧者に新しい臨場感を提供し得る。直線的なビデオ（たとえば、２Ｄまたは３Ｄ）と比較して、３６０度ビデオは、ビデオ処理および／または配信に対して困難な工学的挑戦課題を提示し得る。快適さおよび／または没入型のユーザエクスペリエンスを可能にすることは、高ビデオ品質および／または極めて低いレイテンシを必要とし得る。大きいビデオサイズの３６０度ビデオは、大規模に品質に留意して３６０度ビデオを配信するのに障害となり得る。

３６０度ビデオストリーミングのためのシステム、方法、および手段が開示される。（たとえば、ワイヤレス送信／受信ユニット（ＷＴＲＵ）などの）ビデオストリーミングデバイスは、ネットワークノードから３６０度ビデオストリームを受信し得る。ネットワークノードは、ネットワークアタッチメントポイント（ＮＡＰ；network attachment point）であり得る。ビデオストリーミングデバイスは、ビデオストリーミングデバイスおよび／または３６０度ビデオストリームに関連するビューポートを決定し得る。ビューポートは、ビデオストリーミングデバイスのユーザーに提示されている３６０度ビデオストリームの空間領域であり得る。ビューポートは、ビデオストリーミングデバイスの向きに基づいて決定され得る。ビデオストリーミングデバイスは、３６０度ビデオストリームの第１のセグメントと３６０度ビデオストリームの第２のセグメントとを事前に要求することを（たとえば、ビューポートに基づいて）決定し得る。３６０度ビデオストリームは、２つ以上の時間フレーム（temporal frame）を含み得る。３６０度ビデオストリームの時間フレームの各々は、複数のタイルに区分され得る。第１のセグメントは、３６０度ビデオストリームの２つ以上の時間フレームのうちのフレームの第１のタイルであり得る。第２のセグメントは、３６０度ビデオストリームの２つ以上の時間フレームのうちのフレームの第２のタイルであり得る。

ビデオストリーミングデバイスは、第１のセグメントと第２のセグメントとのための相対優先順序を決定し得る。相対優先順序は、たとえば、時間優先（time preference）、品質優先（quality preference）、および／またはビューポートに関するロケーションに基づいて第１のセグメントのための第１の優先度と第２のセグメントのための第２の優先度とを決定することによって決定され得る。ビデオストリーミングデバイスは、予期される要求メッセージを生成し得る。予期される要求メッセージは、たとえば、決定された相対優先順序に基づいて降順の相対的優先度で（in decreasing relative priority）第１のセグメントと第２のセグメントとをリストすることによって決定された相対優先順序を示し得る。ビデオストリーミングデバイスは、ネットワークノードに予期される要求メッセージを送り得る。

ネットワークノードは、第１のビデオストリーミングデバイスから、第１の相対優先順序で第１の複数のセグメントを示す第１の予期される要求メッセージを受信し得る。ネットワークノードは、第２のビデオストリーミングデバイスから、第２の相対優先順序で第２の複数のセグメントを示す第２の予期される要求メッセージを受信し得る。ネットワークノードは、ＮＡＰであり得る。ネットワークノードは、（たとえば、第１の相対優先順序に基づいて）第１の複数のセグメントの各々に関連する優先度を決定し、（たとえば、第２の相対優先順序に基づいて）第２の複数のセグメントの各々に関連する優先度を決定し得る。ネットワークノードは、第１の予期される要求メッセージと第２の予期される要求メッセージとによって示された共通セグメントを同じ優先度を有するものとして識別し得る。ネットワークノードは、サーバーに、共通セグメントについての要求を送り得る。ネットワークノードは、共通セグメントを受信し得、第１のビデオストリーミングデバイスと第２のビデオストリーミングデバイスとに共通セグメントをマルチキャストし得る。たとえば、ネットワークノードは、共通セグメントがタイムウインドウ（time window）内で同じ優先度を有する同じビデオセグメントを表すと決定し得る。ネットワークノードは、サーバーに共通セグメントを要求することを決定し得る。ネットワークノードは、第１のビデオストリーミングデバイスと第２のビデオストリーミングデバイスとに異なる優先度を有するものとして示されたセグメントをユニキャストし得る。

ネットワークノードは、第１の複数のセグメントと第２の複数のセグメントとの間でセグメントが共通であると決定し得る。たとえば、ネットワークノードは、第１の予期される要求メッセージと第２の予期される要求メッセージとの中に共通セグメントが示されると決定し得る。共通セグメントは、タイムウインドウ内の同じビデオセグメントを表し得る。ネットワークノードは、第１の予期される要求メッセージによって（たとえば、それに基づいて）示される共通セグメントのための第１の優先度値と第２の予期される要求メッセージによって（たとえば、それに基づいて）示される共通セグメントのための第２の優先度値とを決定し得る。ネットワークノードは、たとえば、サーバーに共通セグメントについての要求を送り得る。ネットワークノードは、たとえば、サーバーから共通セグメントを受信し得る。第１の優先度値と第２の優先度値とが同じであるという条件で、ネットワークノードは、第１のビデオストリーミングデバイスと第２のビデオストリーミングデバイスとに共通セグメントをマルチキャストし得る。第１の優先度値と第２の優先度値とが異なるという条件で、ネットワークノードは、第１のビデオストリーミングデバイスと第２のビデオストリーミングデバイスとに共通セグメントをユニキャストし得る。

３６０度ビデオのための例示的な正距円筒図法（ＥＲＰ：ｅｑｕｉｒｅｃｔａｎｇｕｌａｒ ｐｒｏｊｅｃｔｉｏｎ）を示す図である。 ヘッドマウント式デバイス（ＨＭＤ）上に表示される３６０度ビデオの例示的な一部分を示す図である。 ＥＲＰフォーマットでの３６０度ビデオの例示的な処理および配信を示す図である。 ３６０度ビデオを処理し、配信するための例示的な単一ストリームビューポート適応アプローチを示す図である。 ３６０度ビデオを処理し、配信するための例示的なタイルベースのビューポート適応アプローチを示す図である。 ３６０度ビデオを処理し、配信するための例示的なレイヤベースのビューポート適応アプローチを示す図である。 インターネットプロトコル（ＩＰ）ユニキャストアプローチの一例を示す図である。 情報指向ネットワーキング（ＩＣＮ）アプローチの一例を示す図である。 例示的なＭＰＤ（media presentation description）階層データモデルを示す図である。 ＤＡＳＨサーバープッシュを使用したビデオストリーミングの例示的なワークフローを示す図である。 例示的なタイルベースの３６０度ビデオハイパーテキスト転送プロトコル（ＨＴＴＰ）要求を示す図である。 例示的なレイヤベースの３６０度ビデオＨＴＴＰ要求を示す図である。 例示的なタイルベースの３６０度ビデオＨＴＴＰ要求を示す図である。 例示的なタイルベースのＨＴＴＰ要求時間を示す図である。 例示的なレイヤベースの３６０度ビデオＨＴＴＰ要求を示す図である。 例示的なレイヤベースアプローチのＨＴＴＰ要求時間を示す図である。 マルチキャストを使用したクライアントによって開始される３６０度ビデオストリーミングの例示的なワークフローを示す図である。 タイルベースの３６０度ビデオストリーミングのための例示的なネットワークアタッチメントポイント（ＮＡＰ）のソートおよびマッピングを示す図である。 レイヤベースの３６０度ビデオストリーミングのための例示的なＮＡＰのソートおよびマッピングを示す図である。 ＡｎｔｉｃｉｐａｔｅｄＲｅｑｕｅｓｔｓとローカルストレージバッファとを用いる例示的なマルチキャスト設計を示す図である。 タイルベースの３６０度ビデオセグメントの配信の例（ａ）～（ｃ）を示す図である。 サーバーおよびネットワーク支援による動的適応型ＨＴＴＰストリーミング（ＳＡＮＤ：ｓｅｒｖｅｒ ａｎｄ ｎｅｔｗｏｒｋ ａｓｓｉｓｔｅｄ ｄｙｎａｍｉｃ ａｄａｐｔｉｖｅ ｓｔｒｅａｍｉｎｇ ｏｖｅｒ ＨＴＴＰ）のＲｅｑｕｅｓｔＯｒｄｅｒメッセージの例示的なマルチキャスト利得を示す図である。 ＲｅｑｕｅｓｔＯｒｄｅｒメッセージの例示的なワークフローを示す図である。 サーバープッシュのためのマルチキャスト設計の例示的なワークフローを示す図である。 サーバープッシュを介したタイルベースの３６０度ビデオストリーミングのための例示的なＮＡＰマルチキャスト決定を示す図である。 サーバープッシュを介したレイヤベースの３６０度ビデオストリーミングのための例示的なＮＡＰマルチキャスト決定を示す図である。 フレキシブルなプッシュ順序を用いる例示的なマルチキャストワークフローを示す図である。 ＮＡＰによって開始されるプッシュタイプを用いる例示的なマルチキャストワークフローを示す図である。 １つまたは複数の開示する実施形態が実装され得る例示的な通信システムのシステム図である。 一実施形態による、図２９Ａに示す通信システム内で使用され得る例示的なワイヤレス送信／受信ユニット（ＷＴＲＵ）のシステム図である。 一実施形態による、図２９Ａに示す通信システム内で使用され得る例示的な無線アクセスネットワーク（ＲＡＮ）と例示的なコアネットワーク（ＣＮ）とを示すシステム図である。 一実施形態による、図２９Ａに示す通信システム内で使用され得るさらなる例示的なＲＡＮとさらなる例示的なＣＮとを示すシステム図である。

次に、例示的な実施形態の詳細な説明について、様々な図を参照しながら説明する。この説明が可能な実装形態の詳細な例を提供するが、詳細は例示的なものであり、適用範囲を全く限定しないように意図されていることに留意されたい。

３６０度ビデオは、バーチャルリアリティ（ＶＲ）の構成要素であり得る。３６０度ビデオは、球体上でキャプチャおよび／またはレンダリングされ得る。球状のビデオフォーマットは、一部または全部の利用可能なビデオコーデックを使用して直接配信されないことがある。３６０度ビデオ（たとえば、球状ビデオ）は、何らかの投影方法を使用して２Ｄ平面上に球状ビデオを投影することによって圧縮され得る。投影された２Ｄビデオを、（たとえば、一部または全部の利用可能なビデオコーデックを使用して）コード化することができる。投影方法の一例は、正距円筒図法（ＥＲＰ）を含み得る。

図１に、３６０度ビデオのための例示的なＥＲＰを示す。たとえば、ＥＲＰは、図１に示すように、球体上で座標（θ，Φ）をもつ第１のポイントＰを２Ｄ平面上で座標（ｕ，ｖ）をもつ第２のポイントＰにマッピングするために以下の式のうちの１つまたは複数を使用し得る。
ｕ＝Φ／（２＊ｐｉ）＋０．５ （１）
ｖ＝０．５－θ／（ｐｉ） （２）

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

ＥＲＰまたは他の投影フォーマットで表される３６０度ビデオを、Ｈ．２６４およびＨ．２６５などのいくつかのビデオエンコーダを使用して単一レイヤーのビットストリームとしてエンコードすることができる。コード化されたビットストリーム全体を、サーバーに記憶することができ、レシーバー側に送信することができ、デコーダーによってデコードすることができて、現在のビューポートに対応するデコードされたピクチャの領域を、ユーザーに対してレンダリングすることができる。図３に、ＥＲＰフォーマットでの３６０度ビデオの処理および配信の一例を示す。図３に示すように、ＥＲＰフォーマットでの３６０度ビデオを、適応ストリーミングのために１つまたは複数のビットレートセグメントにエンコードすることができる。ユーザーは、ネットワーク状態に応じて動的に特定のセグメントを選択し得る。デコードされたフレームの領域は、ユーザーの向きおよび／またはビューポートに基づいてユーザーに対してレンダリングされ得る。図３に示す例は、ビデオの小部分がユーザーによって消費される間に没入型のユーザエクスペリエンスを提供するために３６０度ビデオ全体を符号化するために大きい帯域幅を使用し得る。

全方向性ビデオ（たとえば、ビデオ領域全体）は、現在のビューポートに対応し得る１つまたは複数のビデオピクチャによって表され得る。現在のビューポートは、ビデオピクチャによって表されるビデオ領域全体のサブセットであり得る。現在のビューポートは、所与の時間にユーザーによって閲覧され得る。たとえば、全方向性ビデオは、現在のビューポート（たとえば、ユーザーによって現在見られているエリア）を表示し得る。ビデオ全体のサブセット（たとえば、ビューポート）を表示することは、送信帯域幅を低下させ、および／またはデコードの複雑性を低下させることができる。

単一ビットストリームビューポート適応アプローチでは、３６０度ビデオを、単一のビットストリームにエンコードすることができる。多くのビットを、３６０度ビデオフレームの他の領域に関する特定の領域（たとえば、ビューポートに対応する領域）により割り当てることができる。複数のビットストリームを、３６０度ビデオに対してエンコードすることができて、各ビットストリームが、特定のビューポートに対応することができる。１つまたは複数のビットストリームは、異なる特性（たとえば、異なるビットレート）を有する同じビューポートに対してエンコードすることができる。レシーバーは、ネットワーク状態、閲覧者の現在のまたは予測された向き、および／またはビューポートに基づいて特定のビットストリームを選択し得る。全体的なビットレートを、減らすことができ、高品質の画像を、低品質の画像が他の非可視エリアに配信され得る間に可視ビューポートエリアに配信することができる。１つまたは複数のメタデータは、ビューポートエリアを示し得る。

図４に、３６０度ビデオを処理し、配信するための例示的な単一ストリームビューポート適応アプローチを示す。２つ以上のビューポート（たとえば、ビューポート＃１およびビューポート＃２）が３６０度ビデオ中で識別され得る。ビデオフレームの残りのエリアよりもビューポートエリアにより多くのビットが割り振られ得る。たとえば、ストリーム＃１および／またはストリーム＃２は、ビデオフレームの残りのエリアよりもビューポート＃１エリアにより多くのビットを割り振り得る。各ストリームを、異なる帯域幅によりコード化することができる。たとえば、ストリーム＃１を、１ｍｂｐｓにコード化することができ、ストリーム＃２を、５ｍｂｐｓにコード化することができる。ストリーム＃３および／または＃４は、ビデオフレームの残りのエリアよりもビューポート＃２エリアにより多くのビットを割り振り得る。ストリーム＃３を、１ｍｂｐｓにコード化することができ、ストリーム＃４を、５ｍｂｐｓにコード化することができる。ユーザーの閲覧向きおよび／またはネットワーク帯域幅に基づいて、ユーザーは、相応してストリームを選択し得る。本明細書において説明されるユーザーは、次の１つまたは複数、ＷＴＲＵ、クライアント、クライアントＷＴＲＵ、ＤＡＳＨクライアント、ストリーミングクライアント、ビデオストリーミングデバイスなどに対して、参照され、および／または互い交換可能に使用することができる。たとえば、ユーザーの閲覧向きおよび／またはネットワーク帯域幅に基づいて、ユーザーは、低帯域幅（ＢＷ）チャネルを介してビューポート＃１を見るときにストリーム＃１を選択し、高ＢＷチャネルを介してビューポート＃２を見るときにストリーム＃４に切り替え得る。

タイルベースのビューポート適応アプローチは、エンコードの前にタイルシーケンスにソースコンテンツを分割することを含み得る。タイルシーケンスは、全パノラマコンテンツの空間エリアのサブセットをカバーし得る。タイルシーケンスを、単一レイヤーのビットストリームとして互いに独立してエンコードすることができる。１つまたは複数のビットストリームは、同じサブピクチャシーケンスから（たとえば、異なるビットレートに対して）エンコードすることができる。各タイルビットストリームは、トラックとしてファイル中にカプセル化され得、ストリーミングのために利用可能であり得る。レシーバー側において、ストリーミングされるべきトラックは、ユーザーの向きおよび／またはビューポートメタデータに基づいて選択され得る。クライアントは、全方向性コンテンツ全体をカバーする１つまたは複数のタイルトラックを受信し得る。現在のビューポートのためにより高品質のタイルトラックが受信され得、残りのおよび現在非可視のエリアのためにより低品質のタイルトラックが受信され得る。各トラックを、別個のデコーダーによりデコードすることができる。

図５は、３６０度ビデオを処理し、配信するための例示的なタイルベースのビューポート適応アプローチを例示する。図５に示すように、３６０度フレームは１つまたは複数のタイルに区分され得る。タイルは、高品質のビットストリーム（たとえば、Ｈ１、Ｈ２、Ｈ３、および／もしくはＨ４）ならびに／または低品質のビットストリーム（たとえば、Ｌ１、Ｌ２、Ｌ３、および／もしくはＬ４）にエンコードすることができる。レシーバーは、向きおよび／またはビューポートメタデータに基づいて異なるタイルビットストリームを選択し得る。たとえば、ビューポート領域のために高品質のタイル（たとえば、Ｈ１および／またはＨ２）が選択され得、他の領域（たとえば、非可視エリア）のために低品質のタイル（たとえば、Ｌ３および／またはＬ４）が選択され得る。

図６は、３６０度ビデオを処理し、配信するための例示的なレイヤベースのビューポート適応アプローチを例示する。基礎レイヤー（base layer）は、ビデオエンコーディングアプローチを使用して３６０度ビデオ（たとえば、３６０度ビデオ全体）によりコード化することができる。１つまたは複数の関心領域（ＲＯＩ）拡張レイヤー（ＥＬ：enhancement layer）は、スケーラブルビデオコーディングによりエンコードすることができる。たとえば、１つまたは複数のＲＯＩ ＥＬは、インターレイヤ予測ありのスケーラブルビデオコーディングによりエンコードすることができる。別の例では、１つまたは複数のＲＯＩ ＥＬは、インターレイヤ予測なしのスケーラブルビデオコーディングによりエンコードすることができる。たとえば、各々のタイル位置毎の１つまたは複数のレイヤーを、コード化することができ、各々のレイヤーは、異なるビットレートおよび／または解像度を有することができる。ＲＯＩ ＥＬは、空間および／または品質スケーラビリティレイヤーであり得る。１つまたは複数のスケーラブル高効率ビデオコーディング（ＳＨＶＣ）ビットストリームを、異なるビットレートに対してエンコードすることができる。ビットレート適応は、１つまたは複数のＥＬを用いて扱うように構成され得る。図６に示すように、基礎レイヤーは、受信され、デコードされ得る。１つまたは複数のＥＬは、受信および／またはデコードされた現在の閲覧向きに基づいて選択され得る。

次世代ネットワーク（ＮＧＮ）プラットフォームは、情報指向ネットワーキング（ＩＣＮ）に基づいてフレキシブルなルーティングソリューションを提供し得る。ＮＧＮプラットフォームは、ＩＣＮとインターネットプロトコル（ＩＰ）とのハイブリッドであり得る。たとえば、ＮＧＮプラットフォームは、帯域幅の使用を低下させ得るマルチキャストを再導入するように構成され得る。

図７に、例示的なＩＰユニキャストアプローチを示す。図７に示すように、サーバーは、１つまたは複数のＷＴＲＵ要求に応答し得、複数のＷＴＲＵがほぼ同時に同じコンテンツを要求し得る場合でも、各ＷＴＲＵに１つまたは複数の要求されたコンテンツを別々に配信し得る。１つまたは複数のコンテンツ配信ネットワーク（ＣＤＮ）を、全体的なトラフィックを減らすために普及しているコンテンツに使用することができる。ＣＤＮを構成することは、複雑であることがあり、回りくどいことに関連する非効率を生じることがあり、例えば、５Ｇネットワークなどの新たなネットワークにとって持続不可能であることがある。

図８に、例示的なＩＣＮアプローチを示す。図８に示すように、暗示的なマルチキャストは、２つ以上のＷＴＲＵがほぼ同時に同じビデオコンテンツを見ているときに使用されるように構成され得る。ＩＣＮは、ゲートウェイ（たとえば、ネットワークアタッチメントポイント（ＮＡＰ））を使用し得る。ゲートウェイは、２つ以上の顧客からネットワークへのアクセスゲートウェイとして構成され得る。ＮＡＰは、一部または全部のプロトコル（たとえば、ＩＰ、伝送制御プロトコル（ＴＣＰ）、ハイパー転送プロトコル（ＨＴＴＰ）など）を扱うように構成され得、ネットワークアドレス変換（ＮＡＴ）、ファイアウォール、および／または動的ＩＰアドレス割当てなどの標準的なゲートウェイ機能を提供し得る。ＩＣＮネットワークは、ＷＴＲＵには標準的なＩＰネットワークとして見え、および／またはＮＡＰによって実行されるＩＣＮ変換機構にはＨＴＴＰを用いるピアリングネットワークとして見え得る。ＮＡＰは、サーバーへの一部または全部のＷＴＲＵ ＨＴＴＰ要求をパースし得、（たとえば、ほぼ同時に同じコンテンツを閲覧するＷＴＲＵを決定するために）所与のタイムウインドウ（Ｔ）内にサーバーに同じコンテンツを要求するＷＴＲＵを識別し得る。ＮＡＰは、サーバーに要求を送ることができ、システムは、一部または全部のＷＴＲＵに要求されたコンテンツを配信するために暗示的なマルチキャストを与え得る。本明細書で説明する暗示的なマルチキャストアプローチは、全体的な帯域幅および／またはサーバー負荷を低減し得る。異なるコンテンツを要求するＷＴＲＵまたは同じコンテンツを要求するが所与のタイムウインドウ（Ｔ）を超えているＷＴＲＵの場合、サーバーから要求元のＷＴＲＵにコンテンツを配信するためにユニキャストアプローチが使用され得る。本明細書で説明するハイブリッドマルチキャスト／ユニキャストアプローチは、ライブスチーミング、ビデオオンデマンド、ビデオシェアリング、個人用ＶＲアプリケーションなどのビデオストリーミング使用事例のためにネイティブマルチキャストを通したネットワーク利用を与え得る。

ＭＰＥＧ動的適応型ＨＴＴＰストリーミング（ＭＰＥＧ－ＤＡＳＨ）は、変化するネットワーク状態に動的に適応することによって考えられる最高のビデオエクスペリエンスをエンドユーザに与え得る例示的な配信フォーマットであり得る。ＤＡＳＨは、ＨＴＴＰ／ＴＣＰ／ＩＰスタックの上に構築され得る。ＤＡＳＨは、ＭＰＤ（media presentation description）であり得るマニフェストフォーマットおよび／またはセグメントフォーマットを定義し得る。

ＭＰＤは、ストリーミングセッション中に適応方式で（たとえば、本明細書で説明する）ビデオセグメントにアクセスするために適切なＨＴＴＰ－ＵＲＬを構築するためにＤＡＳＨクライアントのためのメタデータを含み得る拡張可能なマーク付け言語（ＸＭＬ）文書を含み得る。図９に、例示的なＭＰＤ階層データモデルを示す。ＭＰＤは、一連のＰｅｒｉｏｄを記述することができ、メディアコンテンツ構成要素のエンコードされたバージョンの一貫したセットが、Ｐｅｒｉｏｄの間に変化しない。各Ｐｅｒｉｏｄは、１つまたは複数の適応セット（たとえば、ＡｄａｐｔａｔｉｏｎＳｅｔ）を含み得る。

ＡｄａｐｔａｔｉｏｎＳｅｔは、（たとえば、言語、メディア種別、ピクチャのアスペクト比、役割、アクセス可能性、視点、および／またはレーティングプロパティなどの）１つまたは複数の同じプロパティを共有する１つまたは複数のメディアコンテンツ構成要素のエンコードされたバージョンのセットを表し得る。たとえば、第１のＡｄａｐｔａｔｉｏｎＳｅｔは、同じマルチメディアコンテンツのビデオ成分の異なるビットレートを含み得る。第２のＡｄａｐｔａｔｉｏｎＳｅｔは、同じマルチメディアコンテンツのオーディオ構成要素（たとえば、より低品質のステレオおよび／またはより高品質のサラウンドサウンド）の異なるビットレートを含み得る。各ＡｄａｐｔａｔｉｏｎＳｅｔは、１つまたは複数のＲｅｐｒｅｓｅｎｔａｔｉｏｎを含み得る。

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

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

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

Ｄｅｓｃｒｉｐｔｏｒと呼ばれることがあるＭＰＤ記述子要素が、適切な方式情報をもつ１つまたは複数の記述要素をインスタンス化するためにアプリケーションに与えられ得る。いくつかのＤｅｓｃｒｉｐｔｏｒ（たとえば、コンテンツ保護、役割、アクセス可能性、レーティング、視点、フレームパッキング、および／またはＵＴＣタイミング記述子）は、相対方式を識別するために＠ｓｃｈｅｍｅＩｄＵｒｉ属性を含み得る。補足プロパティ記述子（たとえば、ＳｕｐｐｌｅｍｅｎｔａｌＰｒｏｐｅｒｔｙ）であり得るＭＰＤ要素は、処理を最適化するためにＤＡＳＨクライアントによって使用され得るメタデータを含み得る。必須のプロパティ記述子（たとえば、ＥｓｓｅｎｔｉａｌＰｒｏｐｅｒｔｙ）であり得るＭＰＤ要素は、ｃｏｎｔａｉｎｉｎｇ要素を処理するためのメタデータを含み得る。

サーバーおよびネットワーク支援によるＤＡＳＨ（ＳＡＮＤ：ｓｅｒｖｅｒ ａｎｄ ｎｅｔｗｏｒｋ ａｓｓｉｓｔｅｄ ＤＡＳＨ）は、ストリーミングクライアントとネットワーク要素との間または様々なネットワーク要素の間で交換するメッセージを指定し得る。ストリーミングクライアント（たとえば、ＤＡＳＨクライアント）とネットワーク要素との間または（たとえば、ＤＡＮＥ（ＤＡＳＨ aware network element）を含む）様々なネットワーク要素の間のメッセージは、ネットワーク、サーバー、プロキシ、キャッシュ、ＣＤＮ、ＤＡＳＨクライアントのパフォーマンスおよびステータスなどのリアルタイム動作特性に関する情報を与え得る。

ＡｎｔｉｃｉｐａｔｅｄＲｅｑｕｅｓｔｓ、ＡｃｃｅｐｔｅｄＡｌｔｅｒｎａｔｉｖｅｓ、ＡｂｓｏｌｕｔｅＤｅａｄｌｉｎｅ、ＤｅｌｉｖｅｒｅｄＡｌｔｅｒｎａｔｉｖｅなどのＳＡＮＤメッセージのうちの１つまたは複数が使用され得る。

ＡｎｔｉｃｉｐａｔｅｄＲｅｑｕｅｓｔｓメッセージにより、ＤＡＳＨクライアントは、セグメントのどの特定のセットにＤＡＳＨクライアントが関心があり得るのかをＤＡＮＥに告知することが可能になり得る。ＡｎｔｉｃｉｐａｔｅｄＲｅｑｕｅｓｔｓメッセージは、ＤＡＳＨクライアントが選択する可能性があり得、まもなく要求し得るリプレゼンテーション中のセグメントのセットをシグナリングし得る。表１に、ＡｎｔｉｃｉｐａｔｅｄＲｅｑｕｅｓｔｓメッセージの例示的なパラメーターを示す。

ＡｃｃｅｐｔｅｄＡｌｔｅｒｎａｔｉｖｅｓメッセージは、メディア配信経路のＤＡＮＥ（たとえば、キャッシングＤＡＮＥ）に、ＤＡＳＨクライアントが、ＤＡＳＨクライアントが他のＤＡＳＨセグメントを代替として受け入れることをいとわないことがある与えられえたＤＡＳＨセグメントを要求するときを通知することを、ＤＡＳＨクライアントに可能にすることができる。クライアントは、クライアントが代替のセグメントを受信する準備ができている場合に代替のセグメントを含み得、代替のセグメントを再生することが可能であり得る。表２に、ＡｃｃｅｐｔｅｄＡｌｔｅｒｎａｔｉｖｅｓメッセージの例示的なパラメーターを示す。

ＡｂｓｏｌｕｔｅＤｅａｄｌｉｎｅメッセージは、要求されたセグメントが完全に受信するのに必要である実時間（wall-clock time）における絶対最終期限（absolute deadline）をＤＡＮＥに示すことを、ＤＡＳＨクライアントに可能することができる。表３に、ＡｂｓｏｌｕｔｅＤｅａｄｌｉｎｅメッセージの例示的なパラメーターを示す。

ＤｅｌｉｖｅｒｅｄＡｌｔｅｒｎａｔｉｖｅメッセージは、ＤＡＳＨクライアントによって送られたＡｃｃｅｐｔｅｄＡｌｔｅｒｎａｔｉｖｅｓメッセージへの応答であり得る。ＤＡＮＥは、要求されたセグメントではなく代替のセグメントを配信し得る。ＤＡＮＥが要求されたセグメントではなく代替のセグメントを配信する場合、ＤＡＮＥは、応答がセグメントオルタナティブ（segment alternative）を含み、要求されたセグメントを含まないことを通知するために、ＤＡＳＨクライアントにＤｅｌｉｖｅｒｅｄＡｌｔｅｒｎａｔｉｖｅメッセージを送り得る。表４に、ＤｅｌｉｖｅｒｅｄＡｌｔｅｒｎａｔｉｖｅメッセージの例示的なパラメーターを示す。

ＭＰＥＧ－ＤＡＳＨ ｏｖｅｒ ＨＴＴＰ／１．１の基本機構は、ＨＴＴＰ／２および／またはＷｅｂＳｏｃｋｅｔなどの最近のＩＰによって与えられ得る特徴および／または能力を利用することによって増強され得る。

図１０に、ＤＡＳＨサーバープッシュを使用したビデオストリーミングの例示的なワークフローを示す。クライアントは、プッシュストラテジー（push strategy）を用いてＭＰＤとメディアセグメントとを要求し得る。たとえば、クライアントは、プッシュストラテジーを使用して、最初に、ＭＰＤを要求し得、そして、メディアセグメントを要求し得る。初期化データは、サーバーによるＭＰＤ要求に関連するプッシュストラテジーに応答してプッシュされ得る。要求されたＭＰＤを受信した後に、クライアントは、それぞれのＤＡＳＨセグメントＵＲＬおよび／またはセグメントプッシュストラテジーを用いてサーバーに１つまたは複数のビデオセグメントを要求し始め得る。サーバーは、要求されたビデオセグメントで応答し、その後、セグメントプッシュストラテジーによって示されるプッシュサイクルが続き得る。最低量のデータが受信された後、クライアントは、ビデオを再生し始め得る。本明細書で説明するプロセスは、メディアストリーミングセッションの終了まで繰り返し得る。

表５に、例示的なプッシュストラテジータイプを示す。表６に、各ＰｕｓｈＴｙｐｅがどの要求に適用され得るのかの一例を示す。

３６０度ビデオは、説得力のある没入型のエクスペリエンスを与えるための高解像度および／または高フレームレートにより大量の帯域幅を消費し得る。ＶＲ共有、ライブＶＲストリーミングおよび／またはソーシャルＶＲアプリケーションなどの使用事例の場合、数百および数千のＶＲユーザーが、異なるビューポートに注視しながら同じ３６０度ビデオを見ることがある。本明細書で説明するビューポート適応アプローチ（たとえば、タイルベースまたはレイヤベースの処理および配信アプローチ）は、ＶＲユーザーのための帯域幅消費量を低減し得る。

ＮＧＮプラットフォームによってサポートされるＩＣＮベースのルーティングアプローチは、複数のＶＲユーザーのための帯域幅を低減する機会を与え得る。たとえば、３６０度ビデオの共通に共有される領域は、（たとえば、１回）サーバーからフェッチされ得、複数のＶＲユーザーに転送され得る。１つまたは複数の一意のビューポートセグメントが、サーバーからフェッチされ得、対応するＷＴＲＵに個々に転送され得る。たとえば、２人のＶＲユーザーがタイルベースのストリーミングアプローチを使用して同じビューポートを見ているとき、両方のユーザーが同じ高品質のビューポートタイルおよび／または残りの低品質のタイルを共有しているので、ＮＧＮはマルチキャスト利得を達成し得る。クライアント側における異なる意思決定ポリシーは、各ＶＲ ＷＴＲＵによって発行されているＨＴＴＰ要求の異なるシーケンスを生じ得る。

図１１に、例示的なタイルベースの３６０度ビデオＨＴＴＰ要求を示す。図１１に示すように、同じビューポートを共有する２つ以上のＷＴＲＵの各々（たとえば、ＷＴＲＵ＃ＡおよびＷＴＲＵ＃Ｂ）は、ＨＴＴＰ要求を送り得る。ＷＴＲＵ＃ＡのユーザーＡは、他のタイル（たとえば、タイルＬ３および／またはＬ４）の前に１つまたは複数のビューポートタイル（たとえば、タイルＨ１および／またはＨ２）を要求し得る。ＷＴＲＵ＃ＢのユーザーＢは、一部または全部の他のタイル（たとえば、タイルＬ３および／またはＬ４）の後にビューポートタイル（たとえば、タイルＨ１および／またはＨ２）を要求し得る。ＤＡＳＨクライアント実装は、ビューポートタイルおよび／または他のタイルの順序を決定するように構成され得る。たとえば、タイルが両方のＷＴＲＵによって共有されるので、ＮＧＮは、両方のＷＴＲＵに各タイルをマルチキャストするように構成され得る。タイルセグメントが、図１１に示すように両方のユーザーからほぼ同時に要求されない場合、ＮＧＮは、ユニキャストとしてサーバーから各共有セグメントを別々にフェッチし得る。

レイヤベースのアプローチでは、インターレイヤ予測が使用され得る。たとえば、レイヤベースのアプローチでは、インターレイヤ予測が使用されないことがある。図６に示すように、図６中のＥＬビットストリームは、図６のＢＬビットストリームから単独で復号可能であり得る。ＢＬビットストリームが単独で復号可能な場合、クライアントが１つまたは複数のＢＬセグメントをフェッチし得る前に、クライアントは、１つまたは複数のＥＬセグメントをフェッチすることを選定し得る。たとえば、クライアントは、最初に、１つまたは複数のビューポート（たとえば、ＥＬセグメント）を受信したいと望み得るので、クライアントは、（たとえば、それが１つまたは複数のＢＬセグメントをフェッチする前に）１つまたは複数のＥＬセグメントをフェッチすることを選定し得る。他の例では、他のクライアントは、（たとえば、１つまたは複数のＥＬセグメントをフェッチする前に）最初に、３６０度ビデオ全体を受信したいと望み得るので、クライアントは、最初に、１つまたは複数のＢＬセグメントをフェッチし得る。この場合、各クライアントのＨＴＴＰ要求は、図１２に示すように、基礎レイヤーセグメントによっておよび／または拡張レイヤーセグメントによって異なる順序であり得る。たとえば、図１２に、例示的なレイヤベースの３６０度ビデオＨＴＴＰ要求を示す。図１２に示すように、ＷＴＲＵ＃Ａは、１つまたは複数の拡張レイヤーセグメント（たとえば、Ｈ２および／またはＨ１）を受信する前に基礎レイヤーセグメント（たとえば、ＢＬ）を有するＨＴＴＰ要求を送り得る。ＷＴＲＵ＃Ｂは、基礎レイヤーセグメント（たとえば、ＢＬ）を受信する前に１つまたは複数の拡張レイヤーセグメント（たとえば、Ｈ２および／またはＨ１）を有するＨＴＴＰ要求を送り得る。

異なるクライアントによって異なるビューポートが見られ得る。図１３に、例示的なタイルベースの３６０度ビデオＨＴＴＰ要求を示す。図１３に示すように、２つ以上のＷＴＲＵ（たとえば、ＷＴＲＵ＃ＡおよびＷＴＲＵ＃Ｂ）は、各ＷＴＲＵが異なるビューポートを見ていることがある間に同じＨＴＴＰ要求順序を有し得る。たとえば、ＷＴＲＵ＃Ａのビューポートは、タイル＃１（たとえば、Ｈ１）を含み得、一方、ＷＴＲＵ＃Ｂのビューポートは、タイル＃３（たとえば、Ｈ３）を含み得る。タイル＃１および／またはタイル＃３が両方のＷＴＲＵによって共有されないことがあるので、タイル＃１および／またはタイル＃３（たとえば、Ｈ１および／またはＨ３）は、ユニキャストを介してストリーミングされ得る。ＮＧＮは、暗示的なマルチキャストを介して１回サーバーから両方のＷＴＲＵのために共通に共有されるタイル＃２および／またはタイル＃４（たとえば、Ｌ２および／またはＬ４）をフェッチするように構成され得る。高品質のタイルのファイルサイズは、低品質のタイルのファイルサイズよりも大きくなり得る。異なるタイルサイズは、図１４に示すように、ＷＴＲＵ間でのＨＴＴＰ要求時間（たとえば、Δｔ）をシフトし得る。図１４に、例示的なタイルベースのＨＴＴＰ要求時間を示す。図１４に示すように、ＷＴＲＵ＃ＡおよびＷＴＲＵ＃Ｂからのタイル＃２のＨＴＴＰ要求は、マルチキャスト決定タイムウインドウを超えることがある（Ｔ＜Δｔ）。決定タイムウインドウ（Ｔ）は、増加するように構成され得、したがって、Ｔは、Δｔよりも大きくなり得る。

図１５に、例示的なレイヤベースの３６０度ビデオＨＴＴＰ要求を示す。たとえば、図１５に示すように、ＷＴＲＵ＃ＡのビューポートのユーザーＡは、ＥＬ領域＃１（たとえば、Ｈ１）の内側にあり得、一方、ＷＴＲＵ＃ＢのビューポートのユーザーＢは、ＥＬ領域＃３および＃４（たとえば、Ｈ３およびＨ４）を交差していることがある。両方のユーザーが拡張レイヤーセグメントを要求する前にユーザーが基礎レイヤーセグメントを要求する場合、基礎レイヤーセグメントについてのＨＴＴＰ要求のずれが時間の経過とともに発生し得る。図１６に、例示的なレイヤベースアプローチのＨＴＴＰ要求時間を示す。図１６に示すように、フレーム＃１に対応するＢＬについての要求が同期され得る。フレーム＃２に対応するＢＬについての要求は、同期から外れていることがある。

サーバーおよびネットワーク支援によるＤＡＳＨ（ＳＡＮＤ）メッセージおよび／またはプッシュストラテジーは、複数のＶＲユーザーが同じ３６０度ビデオをほぼ同時に見ているときにＮＧＮプラットフォームを介して３６０度ビデオを配信するように構成され得る。

ハイブリッドマルチキャスト／ユニキャストネットワーキングアーキテクチャを提供し得る。たとえば、３６０度ビデオ全体を、単一のレイヤーおよび／または単一のチャンクファイルにコード化することができる。ハイブリッドマルチキャスト／ユニキャストネットワーキングアーキテクチャは、２人以上のユーザーが同じ３６０度ビデオの同じビューポートをほぼ同時に見ているときにマルチキャスト利得を達成し得る。

クライアント側のセグメント要求が同期されないことがあるので、ＷＴＲＵが、閲覧セッション中にいくつかの同じセグメントを共有し得るが、ビューポート適応ストリーミングアプローチは十分なマルチキャスト利得を達成することができないことがある。

ＨＴＴＰ／１．１を介したＭＰＥＧ－ＤＡＳＨは、クライアントがサーバーからメディアデータを（たとえば、アクティブに）プルし得るクライアントによって開始される機構に基づき得る。サーバーおよびネットワーク支援によるＤＡＳＨ（ＳＡＮＤ）に関するＤＡＳＨ標準の第５部は、効率的なストリーミングセッションおよび／またはＤＡＳＨコンテンツの効率的な配信のためのＤＡＳＨクライアントとネットワーク要素との間のまたは様々なネットワーク要素間のメッセージを導入し得る。ＳＡＮＤメッセージは、ネットワーク、サーバー、プロキシ、キャッシュ、ＣＤＮ、ＤＡＳＨクライアントのパフォーマンスおよびステータスなどのうちの１つまたは複数のリアルタイムの動作特性に関する信号情報を与え得る。ネットワークアタッチメントポイント（ＮＡＰ）は、タイルベースまたはレイヤベースの３６０度ビデオストリーミングのためのそれのメディア配信戦略を最適化するために本明細書で説明する１つまたは複数のメッセージを使用し得る。

（たとえば、ＤＡＳＨクライアントとＮＡＰとの両方がＤＡＳＨ ＳＡＮＤをサポートすると仮定すると）ＳＡＮＤメッセージは、ＮＡＰによって事前にマルチキャストビデオセグメントを識別するために使用され得る。ＮＡＰは、ＤＡＮＥ（ＤＡＳＨ aware network element）であり得る。

タイルベースの３６０度ビデオストリーミングの場合、ＤＡＳＨクライアントは、事前に要求されるべきタイルセグメントを決定することが可能であり得る。ＤＡＳＨクライアントは、非可視エリアのための低品質のタイルおよび／または可視ビューポートのための高品質のタイルを含め、それの閲覧向きに基づいて事前に要求されるべきタイルセグメントを決定し得る。クライアントは、すぐに要求されるべき一部または全部のタイルセグメントのネットワークノード（たとえば、サーバーまたはＮＡＰ）を通知するためにＡｎｔｉｃｉｐａｔｅｄＲｅｑｕｅｓｔｓメッセージを使用し得る。ＤＡＳＨ ＳＡＮＤは、サーバーが要求されたセグメントからクライアントに１つまたは複数の異なるセグメントを送ることおよび／または異なる順序でセグメントを送ることを可能にする機構を提供し得る。本明細書で説明する機構に基づいて、ＮＡＰは、クライアント要求を再編成し、および／または１つもしくは複数のクライアントＷＴＲＵに共通に共有されるセグメントをマルチキャストし得る。たとえば、ＮＡＰは、同じ優先度を有する２つ以上のクライアントによって要求された共通セグメントをマルチキャストし得る。

たとえば、ＮＡＰは、第１のビデオストリーミングデバイス（たとえば、ＤＡＳＨクライアント）から第１のＡｎｔｉｃｉｐａｔｅｄＲｅｑｕｅｓｔｓメッセージを受信し得る。第１のＡｎｔｉｃｉｐａｔｅｄＲｅｑｕｅｓｔｓメッセージは、第１の相対優先順序で第１の複数のセグメントを示し得る。ＮＡＰは、第２のビデオストリーミングデバイスから第２のＡｎｔｉｃｉｐａｔｅｄＲｅｑｕｅｓｔｓメッセージを受信し得る。第２のＡｎｔｉｃｉｐａｔｅｄＲｅｑｕｅｓｔｓメッセージは、第２の相対優先順序で第２の複数のセグメントを示し得る。ＮＡＰは、たとえば、第１の相対優先順序に基づいて第１の複数のセグメントの各々に関連する優先度を決定し得る。ＮＡＰは、たとえば、第２の相対優先順序に基づいて第２の複数のセグメントの各々に関連する優先度を決定し得る。ＮＡＰは、第１の複数のセグメントと第２の複数のセグメントとの間でセグメントが共通であると決定し得る。たとえば、ＮＡＰは、第１のＡｎｔｉｃｉｐａｔｅｄＲｅｑｕｅｓｔｓメッセージと第２のＡｎｔｉｃｉｐａｔｅｄＲｅｑｕｅｓｔｓメッセージとの中に共通セグメントが示されると決定し得る。共通セグメントは、タイムウインドウ内の同じビデオセグメントを表し得る。ＮＡＰは、第１のＡｎｔｉｃｉｐａｔｅｄＲｅｑｕｅｓｔｓメッセージによって（たとえば、それに基づいて）示される共通セグメントのための第１の優先度値と第２のＡｎｔｉｃｉｐａｔｅｄＲｅｑｕｅｓｔｓメッセージによって（たとえば、それに基づいて）示される共通セグメントのための第２の優先度値とを決定し得る。ＮＡＰは、たとえば、サーバーに共通セグメントについての要求を送り得る。ＮＡＰは、たとえば、サーバーから共通セグメントを受信し得る。第１の優先度値と第２の優先度値とが同じであるという条件で、ＮＡＰは、第１のビデオストリーミングデバイスと第２のビデオストリーミングデバイスとに共通セグメントをマルチキャストし得る。第１の優先度値と第２の優先度値とが異なるという条件で、ＮＡＰは、第１のビデオストリーミングデバイスと第２のビデオストリーミングデバイスとに共通セグメントをユニキャストし得る。

図１７に、マルチキャストを使用したクライアントによって開始される３６０度ビデオストリーミングの例示的なワークフローを示す。たとえば、図１７に、３６０度ビデオストリーミングのためにサーバーとＮＡＰとの間でのマルチキャストを導入するためのＤＡＳＨクライアント（たとえば、ＷＴＲＵ＃ＡおよびＷＴＲＵ＃Ｂ）と、ＮＡＰと、サーバーとの間のワークフローを示す。クライアントの各々は、ＮＡＰにＡｎｔｉｃｉｐａｔｅｄＲｅｑｕｅｓｔｓメッセージを送ることができる。ＡｎｔｉｃｉｐａｔｅｄＲｅｑｕｅｓｔｓメッセージは、要求されるべき一部または全部の潜在的なタイルセグメントおよび／または要求されたセグメントを受信する最終期限を示し得る。各クライアントは、セグメント要求ごとにＡｃｃｅｐｔｅｄＡｌｔｅｒｎａｔｉｖｅｓメッセージを介してクライアントが１つまたは複数のＤＡＳＨセグメントオルタナティブを受け入れるのをいとわないことがあることをＮＡＰに通知することができる。ＡｃｃｅｐｔｅｄＡｌｔｅｒｎａｔｉｖｅｓメッセージの代替のセグメントは、まだ受信されていない一部または全部のタイルのセグメントを含み得る。ＮＡＰは、マルチキャストのための（たとえば、クライアントの間で）共通に共有されるセグメントを選別し、および／またはサーバーからユニキャストのための１つもしくは複数の一意のセグメントを決定し得る。ＮＡＰは、各保留中の要求に対応する代替のセグメントをマッピングし得る。マッピング結果に基づいて、ＮＡＰは、サーバーから対応するマルチキャストセグメントを１回フェッチし得、ＷＴＲＵにセグメントを転送し得、サーバーから対応するユニキャストセグメントをフェッチし得、各ＷＴＲＵに個々に転送し得る。

（たとえば、ＮＡＰによって実行される）ソートプロセスは、複数のＷＴＲＵからのＡｎｔｉｃｉｐａｔｅｄＲｅｑｕｅｓｔｓおよび／またはＡｂｓｏｌｕｔｅＤｅａｄｌｉｎｅメッセージをパースすることを含み得る。ほぼ同じ受信最終期限値をもつ共通に共有されるセグメントは、識別され得、マルチキャストグループに置かれ得る。残りのセグメントは、ユニキャストグループに入れられ得る。保留中の要求のための代替応答順序が決定され得る。

図１８に、タイルベースの３６０度ビデオストリーミングのための例示的なＮＡＰのソートおよびマッピングを示す。ＷＴＲＵ＃Ａは、１つまたは複数の高品質のタイルセグメント（たとえば、Ｈ１および／またはＨ２）と１つまたは複数の低品質のタイルセグメント（たとえば、Ｌ３および／またはＬ４）とを要求するようにスケジュールされ得る。ＷＴＲＵ＃Ｂは、１つまたは複数の高品質のタイルセグメント（たとえば、Ｈ１、Ｈ２、および／またはＨ４）と低品質のタイルセグメント（たとえば、Ｌ３）とを要求するようにスケジュールされ得る。ＷＴＲＵ＃Ａおよび／またはＷＴＲＵ＃Ｂは、セグメントオルタナティブを受け入れることに同意し得る。ＮＡＰは、２つ以上のＷＴＲＵ（たとえば、ＷＴＲＵ＃ＡおよびＷＴＲＵ＃Ｂ）からの予期される要求のリストを選別し得、マルチキャストのための共通の要求（たとえば、Ｈ１、Ｈ２、および／またはＬ３）を識別し得、ユニキャストのための一意の要求（たとえば、Ｌ４および／またはＨ４）を識別し得る。要求ごとのセグメントオルタナティブが決定され得、ＮＡＰは、サーバーからマルチキャストセグメントを１回フェッチし得る。ＮＡＰがＷＴＲＵからセグメント要求および／またはＡｃｃｅｐｔｅｄＡｌｔｅｒｎａｔｉｖｅｓメッセージを受信すると、ＮＡＰは、実際に配信されるコンテンツまたは配信されるべき実際のコンテンツをＷＴＲＵに通知するためにＤｅｌｉｖｅｒｅｄＡｌｔｅｒｎａｔｉｖｅメッセージを用いてマッピング結果に基づいてＷＴＲＵにセグメントオルタナティブを転送し得る。

各クライアントは、ＡｃｃｅｐｔｅｄＡｌｔｅｒｎａｔｉｖｅｓ中に受信されていない一部または全部の予期されるタイルセグメントを入れ得、サーバーは、クライアントの要求時にセグメント（たとえば、正確なセグメント）を配信し得る。クライアントは、ＡｃｃｅｐｔＡｌｔｅｒｎａｔｉｖｅｓメッセージ中に要求された対応する高品質のタイルのための低品質のリプレゼンテーションを追加し得る。図１８に示す例では、クライアント＃Ｂは、ＡｃｃｅｐｔｅｄＡｌｔｅｒｎａｔｉｖｅｓメッセージ中に高品質のセグメント（たとえば、Ｈ４）に対応する低品質のタイルセグメント（たとえば、Ｌ４）を追加し得る。ＮＡＰは、マルチキャストセグメントとしてＬ４をフェッチし得、ユニキャストを介してＨ４を別々に送ることなしにクライアント＃Ａおよび＃Ｂにマルチキャストセグメントを転送し得る。

このようにして、ＮＡＰは、サーバーから一部または全部のタイル（たとえば、Ｈ１、Ｈ２、Ｌ３、および／またはＬ４）を１回フェッチし得、ならびに／またはＷＴＲＵ＃Ａおよび／もしくはＷＴＲＵ＃Ｂにフェッチされたタイルを配信し得る。

クライアントが、同じ基礎レイヤーセグメントおよび／または異なる拡張ビューポートセグメントを要求し得るレイヤベースの３６０度ビューポート適応ストリーミングアプローチに同じ戦略が適用され得る。基礎レイヤーセグメントは、他の拡張セグメントの前に配信されるべきマルチキャストセグメントであり得る。図１９に、レイヤベースの３６０度ビデオストリーミングのための例示的なＮＡＰのソートおよびマッピングを示す。図１９に示すように、２つ以上のＷＴＲＵは、同じ基礎レイヤーセグメント（たとえば、ＢＬ）要求と１つまたは複数の異なる拡張レイヤー（たとえば、Ｅ１、Ｅ２、および／またはＥ３）とを有し得る。ＮＡＰは、マルチキャストフェッチのために基礎レイヤーセグメントを選別し得、ユニキャストフェッチのために拡張レイヤーセグメントをソートし得る。ＤｅｌｉｖｅｒｅｄＡｌｔｅｒｎａｔｉｖｅメッセージは、ＷＴＲＵに実際のコンテンツを通知し得る。

セグメントサイズ、利用可能なネットワーク帯域幅、および／またはクライアント要求スケジューリングに応じて、クライアントＨＴＴＰ要求時間は、ＡｎｔｉｃｉｐａｔｅｄＲｅｑｕｅｓｔｓメッセージ中にシグナリングされる元の推定されたｔａｒｇｅｔＴｉｍｅを超え得る。ＮＡＰは、ＡｎｔｉｃｉｐａｔｅｄＲｅｑｕｅｓｔｓメッセージ中でシグナリングされる情報に基づいてそのような場合を検出および／または決定し得る。クライアントの要求が他のクライアントからの要求と同期しないことになるとＮＡＰが決定する場合、ＮＡＰは、そのような同期外れ要求をユニキャストとして扱い得る。たとえば、ＮＡＰは、サーバーからセグメントをフェッチし得、他のクライアントとは別々に影響を及ぼされた（たとえば、同期外れの）クライアントにフェッチされたセグメントを転送し得る。

ＮＡＰは、ローカルバッファ（たとえば、ＮＡＰのローカルバッファ）であり得るバッファ中にセグメントを記憶し得る。ＮＡＰは、一部または全部のビデオストリーミングデバイス（たとえば、ＷＴＲＵ）から１つまたは複数のＡｎｔｉｃｉｐａｔｅｄＲｅｑｕｅｓｔｓメッセージを受信し得る。ＮＡＰは、１つまたは複数のセグメント（たとえば、共有されたセグメント）についての複数のクライアントへのいくつかの要求を識別し得る。２つ以上のＷＴＲＵによって共有されるべきセグメントについて、ＮＡＰは、サーバーからセグメントを１回フェッチし得、将来の要求のためにバッファ（たとえば、ＮＡＰのローカルバッファ）中にセグメントを記憶し得る。そのようなセグメントの将来の要求がもう保留中でない場合、ＮＡＰは、特定のセグメントのストレージを解放し得る。ＷＴＲＵによって要求されるべきセグメントについて、ＮＡＰは、サーバーからセグメントをフェッチし得、対応するＷＴＲＵにそれらを転送し得る。

図２０に、ＡｎｔｉｃｉｐａｔｅｄＲｅｑｕｅｓｔｓとローカルストレージバッファとを用いる例示的なマルチキャスト設計を示す。図２０に示す例示的なマルチキャストは、図１８に示したタイルベースの３６０度ビデオストリーミングのためのＮＡＰのソートおよびマッピングの例と組み合わされ得る。２つ以上のＷＴＲＵ（たとえば、ＷＴＲＵ＃Ａおよび＃Ｂ）からのＡｎｔｉｃｉｐａｔｅｄＲｅｑｕｅｓｔｓメッセージに基づいて、ＮＡＰは、１つまたは複数のタイルセグメント（たとえば、Ｈ１、Ｈ２、および／またはＬ３）が両方のＷＴＲＵによって要求され、１つまたは複数のタイルセグメント（たとえば、Ｌ４および／またはＨ４）がＷＴＲＵ＃ＡまたはＷＴＲＵ＃Ｂから一度要求され得ると決定し得る。ＮＡＰがセグメントＨ１についてのＷＴＲＵ＃Ａの要求を受信すると、ＮＡＰは、サーバーからＨ１をフェッチし得、それをＷＴＲＵ＃Ａに転送し得る。ＮＡＰは、ＷＴＲＵ＃Ｂからの保留中の要求のためのそれのローカルバッファ中にフェッチされたＨ１を記憶するように構成され得る（たとえば、待機中の要求の番号を決定するために要求カウンターが使用され得る）。同じ調達プロシージャが、Ｈ２および／またはＬ３などのタイルに対して行われ得る。記憶されたタイルセグメントが他のＷＴＲＵによって要求されるとき、ＮＡＰは、要求されたタイルセグメントをサーバーから再びフェッチすることなしに（たとえば、それのローカルバッファから）対応するＷＴＲＵに記憶されたタイルセグメントを転送し得る。ローカルバッファを使用するように構成することによって、ＷＴＲＵは、同じタイルを共有し得、ほぼ同時に同じタイルを要求しないことがある。本明細書で説明するタイルベースのアプローチは、レイヤベースのビューポート適応ストリーミングに適用され得る。

タイルベースの３６０度ビデオストリーミングの場合、クライアント（たとえば、クライアントＷＴＲＵ）は、ビューポートを識別することが可能であり得る。クライアントは、ビデオストリーミングデバイスであり得る。ビデオストリーミングデバイスは、本明細書で説明するワイヤード接続で構成され得る。たとえば、クライアントは、ネットワークノードから３６０度ビデオストリームを受信し得る。クライアントは、ユーザーが閲覧している３６０度ビデオストリームのロケーションおよび／または３６０度ビデオストリームに関連する関心領域に基づいてビューポートを識別し得る。クライアントは、１つまたは複数のセグメント（たとえば、高品質のビューポートセグメント）を要求し得る。クライアントは、識別されたビューポートに基づいて１つまたは複数のセグメントを要求し得る。クライアントは、３６０度ビデオストリームの複数のセグメントを事前に要求することを決定し得る。たとえば、クライアントは、３６０度ビデオストリームの第１のビデオセグメントと３６０度ビデオストリームの第２のビデオセグメントとを要求することを決定し得る。クライアントは、ビューポートに基づいて第１のビデオセグメントと第２のビデオセグメントとを要求することを決定し得る。クライアントは、たとえば、ビューポートタイルが提示最終期限の前に配信され得ることを保証するために他のタイルの前にビューポートタイルセグメントを要求し得る。たとえば、クライアントは、非ビューポートタイルセグメントよりもビューポートタイルセグメントを優先させ得る。本明細書で説明するＳＡＮＤメッセージを使用するマルチキャスト戦略では、対応するビューポート要求が延期され得る。

図２１（ａ）～図２１（ｃ）に、タイルベースの３６０度ビデオセグメントの配信の例を示す。たとえば、図２１（ａ）に、ＳＡＮＤメッセージなしのタイルベースの３６０度ビデオ配信を示す。図２１（ａ）に示すように、ＤＡＳＨ要求順序は、クライアントによって開始され得、ここで、３６０度のフレームは、１つまたは複数のタイル（たとえば、４つのタイル）に分割され得る。各タイルを、１つまたは複数の低品質のタイル（たとえば、Ｌ１、Ｌ２、Ｌ３、および／もしくはＬ４）ならびに／または高品質のタイル（たとえば、Ｈ１、Ｈ２、Ｈ３、および／もしくはＨ４）にエンコードすることができる。ＷＴＲＵ＃Ａは、高品質のビューポート（たとえば、Ｈ２）を要求し得、低品質の他のタイル（たとえば、Ｌ１、Ｌ３および／またはＬ４）を要求し得る。ＷＴＲＵ＃Ｂは、高品質のビューポート（たとえば、Ｈ４）を要求し得、低品質の他のタイル（たとえば、Ｌ１、Ｌ２および／またはＬ３）を要求し得る。２つ以上のＷＴＲＵ（たとえば、ＷＴＲＵ＃ＡおよびＷＴＲＵ＃Ｂ）は、同じ順序でタイルを要求し得る。両方のＷＴＲＵが同じ順序でタイルを要求する場合、タイルＬ１は、ＮＡＰを介した暗示的なマルチキャストを使用してフェッチされ得る。図２１（ｂ）は、ＳＡＮＤメッセージを用いるタイルベースの３６０度ビデオ配信の一例であり得る。図２１（ｂ）では、セグメント配信は並べ替えられ得、１つまたは複数のタイル（たとえば、タイルＬ１および／またはＬ３）がマルチキャストを介して配信され得る。ビューポートセグメント（たとえば、Ｈ２および／またはＨ４）は、配信されるべき最後のセグメントに延期され得る。ネットワーク帯域幅が不意に低下する場合、図２１（ｂ）に示すアプローチは、ビューポートタイルを適時に配信することができないことがある。図２１（ｃ）に、高優先度のビューポートセグメントを用いる例示的なタイルベースの３６０度ビデオ配信を示す。図２１（ｃ）に示すように、ビューポートタイルは、（たとえば、ビューポート配信を保証するために）不可視領域中の他のタイルより前に配信され得る。

たとえば、クライアントが、（たとえば、帯域幅条件により）同じ品質をもついくつかのタイルを要求し得るとき、ＮＡＰは、クライアントの要求からビューポートセグメントを識別しないことがある。ＳＡＮＤメッセージ表示により、１つまたは複数のＤＡＳＨクライアントは、ネットワークノード（たとえば、ＮＡＰ）にセグメントの優先度を示すことが可能になり得る。たとえば、（たとえば、ＤＡＳＨクライアントなどの）クライアントＷＴＲＵは、１つまたは複数のビデオストリームセグメントに関連する優先度を決定し得る。クライアントＷＴＲＵは、ビデオストリーミングデバイスであり得る。ビデオストリーミングデバイスは、本明細書で説明するワイヤレスおよび／またはワイヤード接続で構成され得る。クライアントＷＴＲＵは、ＷＴＲＵとビデオストリームとに関連するビューポートに基づいて優先度を決定し得る。たとえば、クライアントＷＴＲＵは、（たとえば、クライアントＷＴＲＵの向きに基づいて）ビューポートを決定し得る。クライアントＷＴＲＵは、時間優先、品質優先、および／またはビューポートに関するロケーションに基づいて優先度を決定し得る。たとえば、より高い優先度が、別のセグメントの前に表示されるべきセグメントのために決定され得る。より高い優先度が、別のセグメントよりも高い品質で表示されるべきセグメントのために決定され得る。より高い優先度は、ビューポート内におよび／またはそれの極近傍に表示されるべきセグメントのために決定され得る。クライアントＷＴＲＵは、１つまたは複数のビデオストリームセグメントの優先度を示し得る。クライアントＷＴＲＵは、ネットワークノード（たとえば、ＮＡＰ）に１つまたは複数のビデオストリームセグメントの優先度を示し得る。優先度シグナリングは、ネットワークノードにそれのビューポートセグメントを示すためにクライアントによって使用され得る。

たとえば、ビデオストリーミングデバイス（たとえば、クライアントＷＴＲＵ）は、ＡｎｔｉｃｉｐａｔｅｄＲｅｑｕｅｓｔｓメッセージを介して１つまたは複数のセグメントの優先度を示し得る。一例として、優先度パラメーターは、表７に示すように、ＡｎｔｉｃｉｐａｔｅｄＲｅｑｕｅｓｔｓメッセージ中に含まれ得る。表７に、ＡｎｔｉｃｉｐａｔｅｄＲｅｑｕｅｓｔｓメッセージに対する例示的な優先度パラメーターを示す。別の例として、ＡｎｔｉｃｉｐａｔｅｄＲｅｑｕｅｓｔｓメッセージは、降順の相対的優先度で１つまたは複数のセグメントをリストすることによって１つまたは複数のセグメントの優先度を示し得る。表８に、セグメントの優先度を示す例示的なＡｎｔｉｃｉｐａｔｅｄＲｅｑｕｅｓｔｓメッセージを示す。

優先度パラメータ（たとえば、値）は、同じＡｎｔｉｃｉｐａｔｅｄＲｅｑｕｅｓｔｓの他のセグメントに対する関連するセグメントの相対優先順序を示し得る。ＤＡＳＨクライアントがＮＡＰにセグメントのどの特定のセットに関心があるのかを告知するとき、ＤＡＳＨクライアントは、ＮＡＰに各セグメントの優先度を通知し得る。Ｐｒｉｏｒｉｔｙ値は、配信順序および／もしくは時間優先（たとえば、クライアントは、できるだけ早く高優先度のセグメントを受信するのを好むことがある）、または品質優先（たとえば、クライアントは、低品質のセグメントの代わりに高品質のセグメントを受信するのを好むことがある）、または配信優先と品質優先との組合せをシグナリングするために使用され得る。タイルベースのビューポート適応ストリーミングでは、クライアントは、ＡｎｔｉｃｉｐａｔｅｄＲｅｑｕｅｓｔｓメッセージに一部または全部のタイルのセグメントを含み得、ビューポートセグメントに高い優先度値を設定し、他のセグメントに低い優先度値を設定し得る。

ＮＡＰがクライアントからＡｎｔｉｃｉｐａｔｅｄＲｅｑｕｅｓｔｓメッセージを受信すると、ＮＡＰは、配信レイテンシを最小化するために高いＰｒｉｏｒｉｔｙのビューポートセグメントをプリフェッチし得る。ＮＡＰは、（たとえば、ＡｎｔｉｃｉｐａｔｅｄＲｅｑｕｅｓｔｓメッセージを介して）複数のクライアントによって示される１つまたは複数の共通セグメントを同じ優先度を有するものとして識別し得る。たとえば、１つまたは複数の共通セグメントがタイムウインドウ内で同じ優先度を有し得る。ＮＡＰは、たとえば、同じ優先度を有する１つまたは複数の共通セグメントに基づいて複数のクライアントに１つまたは複数の共通セグメントをマルチキャストすることを決定し得る。ＮＡＰは、複数のクライアントに、異なる優先度を有する１つまたは複数のセグメントをユニキャストし得る。ＮＡＰは、複数のクライアントからＡｎｔｉｃｉｐａｔｅｄＲｅｑｕｅｓｔｓメッセージを受信すると、ＮＡＰは、配信レイテンシを最小化するために、低優先度にあり得る最も共通に要求されるセグメントをプリフェッチしないことを選定し得、最初に、共通に要求される高優先度のセグメントをプリフェッチし得る。プリフェッチスケジューリングは、異なるアプリケーションおよび／または異なる実装によって異なり得る。

別の例として、ＡｎｔｉｃｉｐａｔｅｄＲｅｑｕｅｓｔｓメッセージは、たとえば、ｓｏｕｒｃｅＵｒｌに関連する各要求の優先度を示し（たとえば、暗示し）得る。ＡｎｔｉｃｉｐａｔｅｄＲｅｑｕｅｓｔｓメッセージは、（たとえば、クライアントＷＴＲＵによって決定された）相対優先順序を示し得る。たとえば、ＡｎｔｉｃｉｐａｔｅｄＲｅｑｕｅｓｔｓメッセージにリストされているセグメントは、優先度（たとえば、相対優先順序）の順序でリストされ得る。クライアントＷＴＲＵは、ＡｎｔｉｃｉｐａｔｅｄＲｅｑｕｅｓｔｓメッセージにリストされているセグメントのための決定された優先度に基づいて相対優先順序を決定し得る。ビデオセグメントは、降順の相対的優先度でＡｎｔｉｃｉｐａｔｅｄＲｅｑｕｅｓｔｓメッセージにリストされ得る。たとえば、（たとえば、ｓｏｕｒｃｅＵｒｌに関連する）より高い優先度のセグメントは、１つまたは複数のより低い優先度のセグメントの前にリストされ得る。ＮＡＰなどのネットワークノードであり得る受信エンティティは、受信されたリストの順序に基づいて優先度を決定し得る。ＷＴＲＵは、ＮＡＰにリストを送る前にリストの順序（たとえば、優先順序）を決定し得る。表８に、優先度を暗示するＡｎｔｉｃｉｐａｔｅｄＲｅｑｕｅｓｔｓメッセージの順序付けられたリストの一例を示す。

別の例として、どの特定のセットをそれがすぐに見る可能性があり得るのかをＮＡＰに告知するためにＶｉｅｗｐｏｒｔＲｅｑｕｅｓｔｓステータスメッセージがシグナリングされ得る。表９に、ＶｉｅｗｐｏｒｔＲｅｑｕｅｓｔｓメッセージの例示的なデータリプレゼンテーションを示す。各ビューポートセグメントは、バイト範囲および／または受信されるべき絶対最終期限をもつｓｏｕｒｃｅＵｒｌによって指定され得る。

本明細書で説明するＶｉｅｗｐｏｒｔＲｅｑｕｅｓｔｓ ＳＡＮＤメッセージでは、ＮＡＰは、最も望ましいビューポートセグメントのオンタイム配信を保証するためにマルチキャスト要求順序をスケジュールし得る。

要求されたセグメントではなく代替のセグメントが配信されるべきとき、ＡｃｃｅｐｔｅｄＡｌｔｅｒｎａｔｉｖｅｓおよび／またはＤｅｌｉｖｅｒｅｄＡｌｔｅｒｎａｔｉｖｅメッセージがＮＡＰとＤＡＳＨクライアントとの間で交換され得る。クライアントは、たとえば、メッセージ交換オーバーヘッドを回避するために、ＮＡＰによって示唆された望ましい順序で１つまたは複数のセグメントを要求し得る。ＳＡＮＤパラメーター拡張受信（ＰＥＲ：Ｐａｒａｍｅｔｅｒｓ Ｅｎｈａｎｃｉｎｇ Ｒｅｃｅｐｔｉｏｎ）は、３６０度のビデオストリーミングのためにＮＡＰからＤＡＳＨクライアントに送るように構成され得る。

表１０に、ＲｅｑｕｅｓｔｓＯｒｄｅｒ ＰＥＲメッセージの例示的なパラメーターを示す。ＲｅｑｕｅｓｔＯｒｄｅｒ ＰＥＲメッセージは、ＮＡＰに、ＤＡＳＨクライアントからのメッセージ中に明示的にシグナリングされるような優先される順において要求されるセグメントのセットをシグナリングすることが可能にすることができる。

本明細書において説明するように、ＮＡＰは、ＷＴＲＵからＡｎｔｉｃｉｐａｔｅｄＲｅｑｕｅｓｔｓメッセージ中でシグナリングされる１つまたは複数の保留中の要求されたセグメントを見越すことができる。各セグメントの要求周波数、サイズ、および／または絶対受信最終期限に基づいて、ＮＡＰは、要求されたセグメントを選別し得る。たとえば、ＮＡＰは、予想される最も要求されないセグメントまで予想される最も要求されるセグメント、予想される次に最も要求されるセグメント、以下同様を選別し得る。ＮＡＰは、ソートおよび／または分析結果に基づいてＲｅｑｕｅｓｔｓＯｒｄｅｒメッセージを介して各ＷＴＲＵに予想されるセグメント要求順序を告知し得る。ＷＴＲＵが予想されるセグメント要求順序に従うとき、ＡｃｃｅｐｔｅｄＡｌｔｅｒｎａｔｉｖｅｓおよび／またはＤｅｌｉｖｅｒｅｄＡｌｔｅｒｎａｔｉｖｅなどの追加のＳＡＮＤメッセージはスキップおよび／またはバイパスされ得る。

表１１に、３６０度ビデオが１つまたは複数の高品質のタイルセグメント（たとえば、Ｈ１、Ｈ２、Ｈ３、および／またはＨ４）と１つまたは複数の低品質のタイルセグメント（たとえば、Ｌ１、Ｌ２、Ｌ３、および／またはＬ４）とを含む４つのタイルに分割され得る一例を示す。最も頻繁に要求されるセグメントはＬ４であり得る。次に最も頻繁に要求されるセグメントはＨ２、Ｈ３および／またはＬ１であり得る。最も頻繁に要求されないセグメントはＨ１、Ｌ２および／またはＬ３であり得る。（たとえば、表１１で＊とマークされている）ビューポートタイルＨ１、Ｈ２およびＨ３の優先度は、本明細書で説明する残りのタイルよりも高くなり得る。ソートの結果に基づいて、サーバーは、表１１に示されるような優先される要求の順序を告知するためのＰＥＲメッセージのＲｅｑｕｅｓｔｓＯｒｄｅｒを各ＷＴＲＵに送ることができる。

図２２に、ＳＡＮＤ ＲｅｑｕｅｓｔＯｒｄｅｒメッセージの例示的なマルチキャスト利得を示す。図２２に示すように、ＲｅｑｕｅｓｔｓＯｒｄｅｒメッセージを使用することによってマルチキャストを介してより多くのセグメントが配信され得る。

図２３に、ＲｅｑｕｅｓｔＯｒｄｅｒメッセージの例示的なワークフローを示す。図２３に示すように、サーバー、ＮＡＰ、および／または２つ以上のＷＴＲＵが表１１の例からのＲｅｑｕｅｓｔＯｒｄｅｒメッセージを使用し得る。ＮＡＰは、一部または全部のＷＴＲＵからＡｎｔｉｃｉｐａｔｅｄＲｅｑｕｅｓｔｓメッセージを受信し得、たとえば、一部または全部のＷＴＲＵからのＡｎｔｉｃｉｐａｔｅｄＲｅｑｕｅｓｔｓメッセージに基づいて各ＷＴＲＵのための最適な要求順序を識別し得る。ＮＡＰは、優先される要求の順序を示すためのＲｅｑｕｅｓｔｓＯｒｄｅｒメッセージを各ＷＴＲＵに送ることができる。各ＷＴＲＵが、予想される順序で各セグメントを要求するためにＲｅｑｕｅｓｔｓＯｒｄｅｒメッセージに従う場合、ＮＡＰは、サーバーから共通に共有されるセグメント（たとえば、Ｈ２、Ｈ３、Ｌ４および／またはＬ１）を１回フェッチすることができ、複数のＷＴＲＵに共有セグメントを転送することができる。ＳＡＮＤメッセージ交換オーバーヘッドを、減らすことができる。

サーバーは、クライアントがリソースを求めることなくリソースをクライアントにプッシュすることができる。サーバーは、リソースをプッシュすることが望ましいことがあり得ると仮定することができる。サーバープッシュは、遅延のラウンドトリップを減らすことができ、（たとえば、没入型のＶＲエクスペリエンスのための優先される構成要素の１つであり得る）最も低いレイテンシを達成することができる。

ＮＡＰは、レイテンシを減らすためにサーバプッシュプロトコルを利用し得る。図２４に、サーバープッシュのためのマルチキャスト設計の例示的なワークフローを示す。図２４に示すように、２つ以上のＷＴＲＵクライアント（たとえば、ＷＴＲＵ＃ＡおよびＷＴＲＵ＃Ｂ）がＭＰＤを要求し得る。メディアセグメントは、プッシュストラテジーを用いて配信され得る。初期化データは、ＭＰＤ要求に関連するプッシュストラテジーに応答してプッシュされ得る。要求されたＭＰＤが受信されると、クライアントは、それぞれのＤＡＳＨセグメントＵＲＬおよび／またはセグメントプッシュストラテジーを用いてサーバーに１つまたは複数のビデオセグメントを要求し始め得る。プッシュストラテジータイプは、プッシュトランザクション中にプッシュされるべきセグメントを明示的にシグナリングするために、限定はしないが、「ｕｒｎ：ｍｐｅｇ：ｄａｓｈ：ｆｄｈ：２０１６：ｐｕｓｈ－ｌｉｓｔ」、「ｕｒｎ：ｍｐｅｇ：ｄａｓｈ：ｆｄｈ：２０１６：ｐｕｓｈ－ｎｅｘｔ」または「ｕｒｎ：ｍｐｅｇ：ｄａｓｈ：ｆｄｈ：２０１６：ｐｕｓｈ－ｔｅｍｐｌａｔｅ」であり得る。ＮＡＰは、ＷＴＲＵによって共有される共通に要求されるセグメントと各ＷＴＲＵのための一意のセグメントとを選別するためにプッシュ指示値をパースし得る。ＮＡＰは、サーバーからの共通に要求されるセグメントを（たとえば、１回）フェッチし、それをローカルバッファ中に記憶し得る。明示的にシグナリングされたＵＲＬＬｉｓｔまたはＵＲＬテンプレートに基づいて、ＮＡＰは、プッシュトランザクション中にＷＴＲＵに記憶されたセグメントをプッシュし得る。ＷＴＲＵによって要求された一意のセグメントの場合、ＷＴＲＵは、ユニキャストとしてサーバーからセグメントをフェッチし得、対応するＷＴＲＵに一意のセグメントを即座にプッシュし得る。

図２５に、サーバープッシュを介したタイルベースの３６０度ビデオストリーミングのための例示的なＮＡＰマルチキャスト決定を示す。図２５に示すように、ＮＡＰは、マルチキャストプッシュおよび／またはユニキャストプッシュのためのタイルベースの３６０度ビデオセグメントを識別し得る。ＮＡＰは、２つ以上のＷＴＲＵ（たとえば、ＷＴＲＵ＃ＡおよびＷＴＲＵ＃Ｂ）からのセグメントＵＲＬのリストをもつプッシュ指示を受信し得、パースし得る。ＮＡＰは、サーバーからフェッチされるべき１つまたは複数の共通に共有されるセグメント（たとえば、Ｈ１、Ｈ２、および／またはＬ３）を１回識別し得、それ以上将来の要求が保留中でなくなるローカルバッファ（たとえば、ＮＡＰ中のバッファ）中に共通に共有されるセグメントを記憶し得る。ＮＡＰは、プッシュ指示中でシグナリングされるＵＲＬＬｉｓｔおよび／またはＵＲＬテンプレートに基づいてローカルバッファから各ＷＴＲＵに１つまたは複数の共通に共有されるセグメントをプッシュし得る。

図２６に、サーバープッシュを介したレイヤベースの３６０度ビデオストリーミングのための例示的なＮＡＰマルチキャスト決定を示す。図２６に示すように、ＮＡＰは、サーバーからのマルチキャストおよび／またはユニキャストフェッチのためのレイヤベースの３６０度ビデオセグメントを識別し得る。ＮＡＰは、２つ以上のＷＴＲＵ（たとえば、ＷＴＲＵ＃ＡおよびＷＴＲＵ＃Ｂ）からのセグメントＵＲＬのリストをもつプッシュ指示を受信し得、パースし得る。ＮＡＰは、暗示的なマルチキャストフェッチのための１つまたは複数の共通に共有される基礎レイヤーセグメント（たとえば、ＢＬ）を識別し得、ユニキャストフェッチのための各ＷＴＲＵのための１つまたは複数の個々の拡張レイヤーセグメント（たとえば、ＷＴＲＵ＃ＡのためのＥ１およびＥ２ならびにＷＴＲＵ＃ＢのためのＥ３）を識別し得る。ＮＡＰは、サーバーから１つまたは複数の共通に共有されるＢＬセグメントを１回フェッチし得、ローカルバッファ（たとえば、ＮＡＰのローカルバッファ）中に１つまたは複数のＢＬセグメントを記憶し得る。ＮＡＰは、ＷＴＲＵによって明示的にシグナリングされるＵＲＬリストおよび／またはＵＲＬテンプレートに基づいてローカルバッファから各ＷＴＲＵにＢＬセグメントをプッシュし得る。

ＮＡＰは、セグメントを局所的に記憶し得る。サーバープッシュの仕様は、クライアントが、プッシュトランザクション中にプッシュされるべきセグメントを明示的にシグナリングするためにプッシュタイプ（たとえば、ｕｒｎ：ｍｐｅｇ：ｄａｓｈ：ｆｄｈ：２０１６：ｐｕｓｈ－ｌｉｓｔ、ｕｒｎ：ｍｐｅｇ：ｄａｓｈ：ｆｄｈ：２０１６：ｐｕｓｈ－ｎｅｘｔ、および／またはｕｒｎ：ｍｐｅｇ：ｄａｓｈ：ｆｄｈ：２０１６：ｐｕｓｈ－ｔｅｍｐｌａｔｅ）を使用し得ることを指定し得る。表１２に、異なるプッシュタイプによってシグナリングされるセグメントプッシュ順序の例を示す。

ＳＡＮＤメッセージにより、サーバーは、クライアントに要求されたセグメントではなく代替のセグメントを配信することが可能になり得る。サーバープッシュは、同様に働くように構成され得る。たとえば、サーバーは、プッシュタイプでシグナリングされるものとは異なり得るセグメントをプッシュし得る。サーバーは、サーバー負荷、ネットワーク状態、および／または特定のセグメントの重要性のうちの少なくとも１つに基づいてどのセグメントを最初にプッシュすべきかを決定し得る。

ＰｕｓｈＤｉｒｅｃｔｉｖｅのフォーマットは、次のように構成され得る。
ＰＵＳＨ＿ＤＩＲＥＣＴＩＶＥ＝ＰＵＳＨ＿ＴＹＰＥ［ＯＷＳ“；”ＯＷＳ ＱＶＡＬＵＥ］
ＰＵＳＨ＿ＴＹＰＥ＝＜（たとえば、表５および／または表６中で与えられ得る）ＰｕｓｈＴｙｐｅの一例＞
ＱＶＡＬＵＥ＝＜ｑｖａｌｕｅは、以下のように定義され得る。
Ｗｅｉｇｈｔ＝ＯＷＳ“；”ＯＷＳ“ｑ＝”ｑｖａｌｕｅ
ｑｖａｌｕｅ＝（“０”［“．”０＊３ＤＩＧＩＴ］）
／（“１”［“．”０＊３（“０”）］）＞

追加のＰＵＳＨ＿ＯＲＤＥＲは、セグメントが、プッシュタイプで明示的にシグナリングされるように厳密な順序でプッシュされ得るのか、またはＮＡＰによって決定され得るのかを示し得る。
ＯＲＤＥＲ＝＜表１３において定義されている例示的なＰｕｓｈＯｒｄｅｒ＞

本明細書で説明するＰＵＳＨ＿ＯＲＤＥＲを用いるＰｕｓｈＤｉｒｅｃｔｉｖｅは、エッジサーバ、ＣＤＮサーバー、またはオリジンサーバなどのＤＡＳＨサーバープッシュをサポートするネットワーク要素に適用され得る。表１３に、ＰＵＳＨ＿ＯＲＤＥＲのための例示的な有効値を示す。

表１４に、明示的なＰｕｓｈＯｒｄｅｒの例を示す。クライアントは、サーバーが最初に要求されたものの後にＰｕｓｈＴｙｐｅに記載されているように次の２つのセグメント Ｓｅｇｍｅｎｔ２およびｓｅｇｍｅｎｔ３をプッシュすることを要求し得る。たとえば、Ｓｅｇｍｅｎｔ２は、Ｓｅｇｍｅｎｔ３より前にプッシュされ得る。

表１５に、フレキシブルなＰｕｓｈＯｒｄｅｒの例を示す。クライアントは、サーバーが最初に要求されたものの後にＰｕｓｈＴｙｐｅに記載されているように次の２つのセグメント Ｓｅｇｍｅｎｔ２およびｓｅｇｍｅｎｔ３をプッシュすることを要求し得る。Ｓｅｇｍｅｎｔ２は、サーバーの状態によっては、Ｓｅｇｍｅｎｔ３の前か後にプッシュされ得る。

図２７に、フレキシブルなプッシュ順序を用いる例示的なマルチキャストワークフローを示す。図２７に示すように、２つ以上のクライアント（たとえば、ＷＴＲＵ＃ＡおよびＷＴＲＵ＃Ｂ）は、「ｆｌｅｘｉｂｌｅ」に設定されたプッシュ順序パラメータセットを用いてＮＡＰにＰｕｓｈＴｙｐｅを送り得る。ＮＡＰは、２つ以上のＷＴＲＵによって共有されるべき１つまたは複数のマルチキャストセグメント（たとえば、Ｈ１、Ｈ２、および／またはＬ３）とＷＴＲＵのための１つまたは複数のユニキャストセグメント（たとえば、Ｌ４および／またはＨ４）とを識別し得る。ＮＡＰは、サーバーからマルチキャストセグメントを（たとえば、１回）フェッチし得、ＷＴＲＵにプッシュし得、またサーバーからユニキャストセグメントをフェッチし得、対応するＷＴＲＵに個々にプッシュし得る。

図２８に、ＮＡＰによって開始されるプッシュタイプを用いる例示的なマルチキャストワークフローを示す。２つ以上のクライアント（たとえば、ＷＴＲＵ＃ＡおよびＷＴＲＵ＃Ｂ）は、ＮＡＰにＰｕｓｈＴｙｐｅを送り得る。ＮＡＰは、クライアントにプッシュされるべきセグメントの順序を告知するためにプッシュタイプ（たとえば、ｕｒｎ：ｍｐｅｇ：ｄａｓｈ：ｆｄｈ：２０１６：ｐｕｓｈ－ｌｉｓｔ、ｕｒｎ：ｍｐｅｇ：ｄａｓｈ：ｆｄｈ：２０１６：ｐｕｓｈ－ｎｅｘｔおよび／またはｕｒｎ：ｍｐｅｇ：ｄａｓｈ：ｆｄｈ：２０１６：ｐｕｓｈ－ｔｅｍｐｌａｔｅ）を用いてクライアントにプッシュ指示を開始するように構成され得る。ＮＡＰがクライアントから肯定応答を受信すると、ＮＡＰは、サーバーからセグメントをフェッチし得、プッシュタイプ中でシグナリングされた順序でセグメントをプッシュし得る。プッシュ指示がクライアントによって肯定応答されない場合、ＮＡＰは、クライアントから受信したプッシュタイプ中で元々シグナリングされたようにセグメントをプッシュし得るか、またはＮＡＰは、クライアントからのプッシュ指示に肯定応答しないことがある。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Claims (22)

1. 予期される要求メッセージをストリーミングクライアントから受信するように構成されるプロセッサーを備えたネットワークデバイスであって、
   前記予期される要求メッセージは、ビデオストリームの第１のセグメントに対する第１の予期される要求および前記ビデオストリームの第２のセグメントに対する第２の予期される要求を含み、
   前記第１のセグメントに対する前記第１の予期される要求は、第１のリプレゼンテーションの第１のソースＵＲＬ（Uniform Resource Locator）、第１の範囲、および第１の目標時間を含み、前記第２のセグメントに対する前記第２の予期される要求は、第２のリプレゼンテーションの第２のソースＵＲＬ、第２の範囲、および第２の目標時間を含み、
   前記第１の予期される要求および前記第２の予期される要求は、降順の相対優先順序で配置される、
   ネットワークデバイス。
2. 前記プロセッサーは、前記第１のセグメントまたは前記第２のセグメントに関連付けられる受け入れ可能な代替の順序付けられたリストを少なくとも含むａｃｃｅｐｔｅｄａｌｔｅｒｎａｔｉｖｅｓメッセージを受信するようにさらに構成され、前記受け入れ可能な代替の順序付けられたリストは好ましい代替をまずリストし、前記受け入れ可能な代替の１つは、前記受け入れ可能な代替に関連付けられる代替のＵＲＬを含む、請求項１のネットワークデバイス。
3. 前記プロセッサーは、ｄｅｌｉｖｅｒｅｄａｌｔｅｒｎａｔｉｖｅメッセージを送信するように構成され、前記ｄｅｌｉｖｅｒｅｄａｌｔｅｒｎａｔｉｖｅメッセージは、前記ａｃｃｅｐｔｅｄａｌｔｅｒｎａｔｉｖｅｓメッセージに応答して送信され、前記ｄｅｌｉｖｅｒｅｄａｌｔｅｒｎａｔｉｖｅメッセージは、前記第１のセグメントの代わりに第１の代替セグメントを示し、前記ｄｅｌｉｖｅｒｅｄａｌｔｅｒｎａｔｉｖｅメッセージは、ｉｎｉｔｉａｌ ＵＲＬおよびｃｏｎｔｅｎｔｌｏｃａｔｉｏｎ ＵＲＬを含む、請求項２のネットワークデバイス。
4. 前記ｉｎｉｔｉａｌ ＵＲＬは、前記第１のリプレゼンテーションの第１のＵＲＬであり、前記ｃｏｎｔｅｎｔｌｏｃａｔｉｏｎ ＵＲＬは、実際に配信されたコンテンツのＵＲＬである、請求項３のネットワークデバイス。
5. 前記プロセッサーは、前記ストリーミングクライアントにおいて利用可能になる前記第１のセグメントまたは前記第２のセグメントに関連付けられる絶対最終期限を含むａｂｓｏｌｕｔｅｄｅａｄｌｉｎｅメッセージを受信するようにさらに構成される、請求項１のネットワークデバイス。
6. 前記絶対最終期限は、前記第１のセグメントまたは前記第２のセグメントが前記ストリーミングクライアントによって利用可能になることが期待される日時である、請求項５のネットワークデバイス。
7. 前記ネットワークデバイスは、ＤＡＮＥ（ＤＡＳＨ（Dynamic Adaptive Streaming over HTTP） aware network element）であり、前記ストリーミングクライアントは、ＤＡＳＨクライアントである、請求項１のネットワークデバイス。
8. 前記第１のリプレゼンテーションの前記第１のセグメントに関連付けられる第１の優先度または前記第２のリプレゼンテーションの前記第２のセグメントに関連付けられる第２の優先度は、時間優先、品質優先、またはビューポートに関するロケーションのうちの１つまたは複数に基づいており、前記ビューポートは３６０度ビデオストリームに関連付けられる、請求項１のネットワークデバイス。
9. 前記第１の範囲または前記第２の範囲が、第１のＵＲＬまたは第２のＵＲＬによってそれぞれ参照されるコンテンツの一部であるとき、前記第１の範囲または前記第２の範囲は、バイト範囲指定である、請求項１のネットワークデバイス。
10. 前記第１の目標時間または前記第２の目標時間は、前記ストリーミングクライアントが第１のＵＲＬまたは第２のＵＲＬによって識別されるリソースを要求することを期待する時間の表示である、請求項１のネットワークデバイス。
11. 前記ビデオストリームは、１つまたは複数のタイルに区分される時間フレームを少なくとも含み、前記第１のリプレゼンテーションの前記第１のセグメントは、第１の時間フレームの第１のタイルであり、前記第２のリプレゼンテーションの前記第２のセグメントは、第２の時間フレームの第２のタイルである、請求項１のネットワークデバイス。
12. 動的適応型ＨＴＴＰストリーミング（ＤＡＳＨ）を使用するネットワークデバイスによって実行される方法であって、前記方法は、
    予期される要求メッセージをストリーミングクライアントから受信すること
    を含み、
    前記予期される要求メッセージは、ビデオストリームの第１のセグメントに対する第１の予期される要求および前記ビデオストリームの第２のセグメントに対する第２の予期される要求を含み、
    前記第１のセグメントに対する前記第１の予期される要求は、第１のリプレゼンテーションの第１のソースＵＲＬ（Uniform Resource Locator）、第１の範囲、および第１の目標時間を含み、前記第２のセグメントに対する前記第２の予期される要求は、第２のリプレゼンテーションの第２のソースＵＲＬ、第２の範囲、および第２の目標時間を含み、
    前記第１の予期される要求および前記第２の予期される要求は、降順の相対優先順序で配置される、
    方法。
13. 前記第１のセグメントまたは前記第２のセグメントに関連付けられる受け入れ可能な代替の順序付けられたリストを少なくとも含むａｃｃｅｐｔｅｄａｌｔｅｒｎａｔｉｖｅｓメッセージを受信するようにさらに構成され、前記受け入れ可能な代替の順序付けられたリストは好ましい代替をまずリストし、前記受け入れ可能な代替の１つは、前記受け入れ可能な代替に関連付けられる代替のＵＲＬを含む、請求項１２の方法。
14. 前記ａｃｃｅｐｔｅｄａｌｔｅｒｎａｔｉｖｅｓメッセージに応答して、ｄｅｌｉｖｅｒｅｄａｌｔｅｒｎａｔｉｖｅメッセージを送信することをさらに含み、前記ｄｅｌｉｖｅｒｅｄａｌｔｅｒｎａｔｉｖｅメッセージは、前記第１のセグメントの代わりに第１の代替セグメントを示し、前記ｄｅｌｉｖｅｒｅｄａｌｔｅｒｎａｔｉｖｅメッセージは、ｉｎｉｔｉａｌ ＵＲＬおよびｃｏｎｔｅｎｔｌｏｃａｔｉｏｎ ＵＲＬを含む、請求項１３の方法。
15. 前記ｉｎｉｔｉａｌ ＵＲＬは、前記第１のリプレゼンテーションの第１のＵＲＬであり、前記ｃｏｎｔｅｎｔｌｏｃａｔｉｏｎ ＵＲＬは、実際に配信されたコンテンツのＵＲＬである、請求項１４の方法。
16. 前記ストリーミングクライアントにおいて利用可能になる前記第１のセグメントまたは前記第２のセグメントに関連付けられる絶対最終期限を含むａｂｓｏｌｕｔｅｄｅａｄｌｉｎｅメッセージを受信することをさらに含む、請求項１２の方法。
17. 前記絶対最終期限は、前記第１のセグメントまたは前記第２のセグメントが前記ストリーミングクライアントによって利用可能になることが期待される日時である、請求項１６の方法。
18. 前記ネットワークデバイスは、ＤＡＮＥ（DASH aware network element）であり、前記ストリーミングクライアントは、ＤＡＳＨクライアントである、請求項１２の方法。
19. 前記第１のリプレゼンテーションの前記第１のセグメントに関連付けられる第１の優先度または前記第２のリプレゼンテーションの前記第２のセグメントに関連付けられる第２の優先度は、時間優先、品質優先、またはビューポートに関するロケーションのうちの１つまたは複数に基づいており、前記ビューポートは３６０度ビデオストリームに関連付けられる、請求項１３の方法。
20. 前記第１の範囲または前記第２の範囲が、第１のＵＲＬまたは第２のＵＲＬによってそれぞれ参照されるコンテンツの一部であるとき、前記第１の範囲または前記第２の範囲は、バイト範囲指定である、請求項１３の方法。
21. 前記第１の目標時間または前記第２の目標時間は、前記ストリーミングクライアントが第１のＵＲＬまたは第２のＵＲＬによって識別されるリソースを要求することを期待する時間の表示である、請求項１３の方法。
22. 前記ビデオストリームは、１つまたは複数のタイルに区分される時間フレームを少なくとも含み、前記第１のリプレゼンテーションの前記第１のセグメントは、第１の時間フレームの第１のタイルであり、前記第２のリプレゼンテーションの前記第２のセグメントは、第２の時間フレームの第２のタイルである、請求項１３の方法。

Images