JP6316967B2 - Ｄａｓｈのためのコマンドを信号伝達するクライアント／サーバ - Google Patents

Description

モバイルデバイスにおいては、デジタルビデオコンテンツがますます消費されるようになっているため、マルチメディアストリーミングサービスは、新しいモバイルブロードバンドの技術と標準の進化を促進するのに役立っている。多くのビデオストリーミングアプリケーションが、娯楽、通信、及び他の目的のために、モバイルデバイスにおいて頻繁に使用されている。たとえば、オンラインビデオストリーミングは、ＹｏｕＴｕｂｅ（登録商標）、Ｈｕｌｕ（商標）、Ｎｅｔｆｌｉｘ（商標）、Ａｍａｚｏｎ Ｉｎｓｔａｎｔ Ｖｉｄｅｏ（商標）、及びＷａｔｃｈＥＳＰＮ（商標）などの大衆向けのサービスによって提供されている。２０１１年においては、ＹｏｕＴｕｂｅ（登録商標）により、１兆を超える世界的な視聴が得られた。それらの視聴のうちの１０パーセントは、モバイルフォン又はタブレットを介してアクセスされた。購入されるスマートフォン、タブレット、及び他のモバイルコンピューティングデバイスが増すにつれて、メディアサーバは、多数のクライアントデバイスからのストリーミング要求という重い負荷にますます直面することになる。メディア圧縮及びワイヤレスネットワークインフラストラクチャの発展とのマルチメディアサービスの結び付きを求める消費者需要がそのような高い状況にあっては、今後のセルラ及びモバイルブロードバンドシステムのマルチメディアサービス機能を高め、消費者に対して高い体感品質（ｑｕａｌｉｔｙ ｏｆ ｅｘｐｅｒｉｅｎｃｅ：ＱｏＥ（経験品質））をもたらすようにし、それによって、どんな場所からでも、どんな時でも、どんなデバイス及び技術を用いても、ビデオコンテンツ及びサービスへのユビキタスなアクセスを確保することは関心事である。

本開示の特徴及び利点は、例として、本開示の特徴をともに示す添付の図面と併せて解釈される、後に続く詳細な説明から明らかになろう。

例に従って、メディアプレゼンテーション記述（ｍｅｄｉａ ｐｒｅｓｅｎｔａｔｉｏｎ ｄｅｓｃｒｉｐｔｉｏｎ：ＭＰＤ）メタデータファイル構成を示すブロック略図である。 例に従って、経時的に変動するハイパーテキスト転送プロトコル（ｈｙｐｅｒｔｅｘｔ ｔｒａｎｓｆｅｒ ｐｒｏｔｏｃｏｌ：ＨＴＴＰ）適応型ストリーム（ａｄａｐｔｉｖｅ ｓｔｒｅａｍ：ＨＡＳ）の例を示す図である。 例に従って、ハイパーテキスト転送プロトコル（ＨＴＴＰ）ストリーミングを示すブロック略図である。 例に従って、ハイパーテキスト転送プロトコルベースの（ＨＴＴＰベースの）ビデオストリーミングのためのエネルギー特徴付けを意識した無線アクセスネットワーク（ｒａｄｉｏ ａｃｃｅｓｓ ｎｅｔｗｏｒｋ：ＲＡＮ）アーキテクチャを示すブロック略図である。 例に従って、利用可能な表現及び利用可能なセグメントを含むＭＰＤファイルの例を提供する表である。 例に従って、選定されたサーバ帯域幅について利用可能な表現コードの例を提供する表である。 例に従って、ＨＴＴＰ適応型ストリーミングを提供するように動作可能なサーバのコンピュータ回路の機能を示す図である。 例に従って、ＨＴＴＰ適応型ストリーミングを提供するように動作可能なモバイルデバイスのコンピュータ回路の機能を示す図である。 例に従って、サーバから複数のクライアントにマルチメディアの可変ビットレート適応型ストリーミングを提供するための方法を示すブロック略図である。 例に従って、ワイヤレスデバイス（たとえば、ＵＥ）を示す略図である。

次に、図示の例示的な実施形態を参照し、これを説明するために本明細書においては、特定の文言が使用されることになる。それでもなお、それによって、本発明の範囲を限定することを意図するものは何もないことが理解されよう。

本発明が開示され、説明される前に、本発明が、本明細書において開示される特定の構造、方法ステップ、又は材料に限定されるのではなく、当業者によって認識されるであろうようにその均等物にまで拡張されることを理解されたい。また、本明細書において採用される専門用語は、特定の例を説明する目的のためにのみ使用されるにすぎず、限定しているように意図していないことも理解すべきである。異なる図面の中の同じ参照符号は、同じ要素を表している。流れ図及び方法の中に与えられる番号は、図示するステップ及び動作において明瞭にするために与えられており、必ずしも特定の順番又は順序を示しているわけではない。

技術的実施形態の最初の概観が、以下に与えられ、次いで、特定の技術的実施形態が、その後にさらに詳細に説明される。この最初の概要は、本技術をより迅速に理解する際に役立つように意図されているのであって、本技術の主要な特徴若しくは基本的な特徴を特定するようにも、又は特許請求される主題の範囲を限定するようにも意図していない。

適応型マルチメディアストリーミングは、マルチメディアがストリーミングされている間に、種々のバージョンの同じマルチメディアファイルにモバイルデバイスがアクセスすることを可能にする。無線リンク状態の変更により、モバイルデバイスにおける利用可能な帯域幅は、低減又は増加し得る。マルチメディアファイルの種々のバージョンへの変更を、ファイルがモバイルデバイスにおいて提示される間に行うことによって「適応させる」機能により、帯域幅の低下が生じるときであっても、提示を継続させることが可能になる。

プログレッシブダウンロード及びＨＴＴＰを介した動的適応型ストリーミング（ｄｙｎａｍｉｃ ａｄａｐｔｉｖｅ ｓｔｒｅａｍｉｎｇ ｏｖｅｒ ＨＴＴＰ：ＤＡＳＨ）などのハイパーテキスト転送プロトコル（ＨＴＴＰ）ベースのストリーミングサービスを含む、現在の適応型マルチメディアストリーミング標準及び仕様は、ある種の条件下でユーザの体感品質を低減させ得る限界を有する。

たとえば、現在のところ、クライアントは、予定されたメンテナンス（又は何らかの他の理由）のためにメディアサーバがオフラインになるとき、事前に予測することができない。クライアントは、いくつかの要求が満たされなかった後、及びいくつかのバッファリングイベントが生じた後に、サーバがオフラインになったことを推測しなくてはならないことがある。加えて、クライアントはまた、いくつかのバッファリングイベントが生じた後に、メディアサーバのアップロード速度が変更したことを推測しなくてはならないこともある。いずれの状況も、結果的には、減退したクライアントＱｏＥ（体感品質）をもたらし得る。

別の例においては、所望のコンテンツを有する第１のメディアサーバがオーバーロードしているとき、クライアントは、より遅い速度でコンテンツをストリーミングするように強制される場合がある。同様のコンテンツを有する１つ又は複数の追加のサーバが、オンラインになる場合がある。しかしながら、クライアントは、追加のサーバがオンラインになっていることを意識していない場合があり、そのため、引き続き第１のサーバからより遅い速度でコンテンツをストリーミングする場合がある。この状況もやはり、所望のコンテンツが追加のサーバからストリーミング可能であることをクライアントが意識した場合に達成可能になるＱｏＥ（体感品質）に対して、結果的には、減退したクライアントＱｏＥをもたらし得る。

別の例においては、ＨＴＴＰを通じた動的適応型ストリーミング（ＤＡＳＨ）は、サーバ上の利用可能な種々のフォーマット、バージョン、及びセグメントのメディアコンテンツについての情報を提供するメディアプレゼンテーション記述（ＭＰＤ）メタデータファイルのためのフォーマットを指定する。ＭＰＤメタデータファイルは、追加のコンテンツがサーバを通じて利用可能になるとき、サーバによって更新され得る。しかしながら、クライアントは、クライアントが、具体的に、ＭＰＤ更新をサーバに要求するまでの時間期間の間、追加のコンテンツが利用可能であることを意識していない場合がある。その時間期間中、ＱｏＥがすぐに改善可能になるクライアントは、追加のコンテンツにより利用可能になるいずれの利益も享受していない。

別の例においては、メディアサーバは、トランスコーディング（たとえば所望のフォーマット又はビットレートを達成するための、あるエンコーディングから別のエンコーディングへの直接的な変換）をサポートする場合がある。いくつかのクライアントは、サーバ上で容易には利用できなくても、サーバのトランスコーディング機能を使用すれば利用可能になり得るメディアコンテンツのエンコーディングによって、さらに良くサービス提供され得る。しかしながら、これらのクライアントは、サーバのトランスコーディング機能について意識していない場合があり、そのため、それによって提供される利益を享受していない場合がある。

別の例においては、ネットワーク転送速度は、モバイルデバイスが、ある場所から別の場所に移送されるとき、突然、低下することがある。しかしながら、モバイルデバイスが、すでに、表現の高ビットレートセグメントをサーバに要求済みである場合、高ビットレートセグメントの要求を自動的に取り消し、それを、低減したネットワーク転送速度により適したより低いビットレートセグメントの要求と置き換えるやり方は、現在のところ、存在しない。これにより、クライアントは、バッファリングイベントを受けることになる場合があり、それは、クライアントＱｏＥを低下させ得る。

ワイヤレスマルチメディア標準
モバイルコンピューティングデバイスに、モバイルコンピューティングデバイスから、又はモバイルコンピューティングデバイス間でマルチメディアを通信できるようにするために開発されているいくつかのマルチメディア標準がある。ビデオをストリーミングする際の例としては、第三世代パートナシッププロジェクト（ｔｈｉｒｄ ｇｅｎｅｒａｔｉｏｎ ｐａｒｔｎｅｒｓｈｉｐ ｐｒｏｊｅｃｔ：３ＧＰＰ）が、オンデマンド又はライブコンテンツのユニキャストストリーミングのためのリアルタイムストリーミングプロトコル（ｒｅａｌ−ｔｉｍｅ ｓｔｒｅａｍｉｎｇ ｐｒｏｔｏｃｏｌ：ＲＴＳＰ）に基づくパケット交換型ストリーミングサービス（ｐａｃｋｅｔ−ｓｗｉｔｃｈｅｄ ｓｔｒｅａｍｉｎｇ ｓｅｒｖｉｃｅ：ＰＳＳ）について記載する技術仕様（ｔｅｃｈｎｉｃａｌ ｓｐｅｃｉｆｉｃａｔｉｏｎ：ＴＳ）２６．２３４（たとえば、Ｒｅｌｅａｓｅ１１．０．０）を開発している。加えて、プログレッシブダウンロード及びＨＴＴＰを介した動的適応型ストリーミング（ＤＡＳＨ）を含む、ハイパーテキスト転送プロトコル（ＨＴＴＰ）ベースのストリーミングサービスが、３ＧＰＰ ＴＳ２６．２４７（たとえば、Ｒｅｌｅａｓｅ１１．０．０）の中に記載されている。３ＧＰＰベースのマルチメディアブロードキャスト及びマルチキャストサービス（ｍｕｌｔｉｍｅｄｉａ ｂｒｏａｄｃａｓｔ ａｎｄ ｍｕｌｔｉｃａｓｔ ｓｅｒｖｉｃｅ：ＭＢＭＳ）仕様ＴＳ２６．３４６（たとえば、Ｒｅｌｅａｓｅ１１．０．０）は、マルチキャスト／ブロードキャストコンテンツ配信のためのストリーミング及びダウンロードの技法を指定している。したがって、ユーザ機器（ｕｓｅｒ ｅｑｕｉｐｍｅｎｔ：ＵＥ）など、ＤＡＳＨ／ＰＳＳ／ＭＢＭＳベースのモバイルコンピューティングデバイスは、ＵＥデバイスにおいて、ストリーミングされたビデオをデコードし、レンダリングする。３ＧＰＰ ＴＳ２６．２４４（たとえば、Ｒｅｌｅａｓｅ１１．０．０）における３ＧＰファイルフォーマット向けのサポートは、ファイルダウンロード及びＨＴＴＰベースのストリーミングユースケースをサポートするために、これらの仕様のすべてにおいて委任されている。

上述の標準は、マルチメディアデバイスに、マルチメディアデバイスから、及び／又はマルチメディアデバイス間でマルチメディアファイルを伝達するのに使用可能であるワイヤレスマルチメディア標準の例として与えられている。諸例は、限定しているように意図していない。追加の標準が、ストリーミングビデオ又はビデオ共有を提供するために使用されてもよい。

ストリーミングメディア標準
ＨＴＴＰストリーミング及びＤＡＳＨ標準のより詳細な説明は、本発明の実施形態の文脈の中で、本明細書において与えられる。詳細な説明は、限定しているように意図していない。続く諸段落の中でさらに説明するように、本開示の中で説明する諸例は、ＤＡＳＨ設定におけるクライアントＱｏＥを改善し得るクライアントとサーバとの間の伝達を容易にするために使用され得る。

Ｉｎｔｅｒｎｅｔビデオのハイパーテキスト転送プロトコル（ＨＴＴＰ）ストリーミング配信。ＨＴＴＰストリーミングにおいては、マルチメディアファイルは、１つ又は複数のセグメントに区分化され、ＨＴＴＰプロトコルを使用してクライアントに配信され得る。ＨＴＴＰベースの配信は、ＨＴＴＰプロトコルと、ＨＴＴＰの下層にある伝送制御プロトコル（ｔｒａｎｓｍｉｓｓｉｏｎ ｃｏｎｔｒｏｌ ｐｒｏｔｏｃｏｌ：ＴＣＰ）／インターネットプロトコル（ｉｎｔｅｒｎｅｔ ｐｒｏｔｏｃｏｌ：ＩＰ）を含むプロトコルとの双方の幅広い採用により、信頼性及び配備簡素化を提供することができる。ＨＴＴＰベースの配信は、ネットワークアドレス変換（ｎｅｔｗｏｒｋ ａｄｄｒｅｓｓ ｔｒａｎｓｌａｔｉｏｎ：ＮＡＴ）及びファイヤーウォールのトラバーサル問題を回避することによって、簡素化されたストリーミングサービスを可能にすることができる。ＨＴＴＰベースの配信又はストリーミングはまた、専用のストリーミングサーバではなく、標準ＨＴＴＰサーバ及びキャッシュを使用する能力をもたらすこともできる。ＨＴＴＰベースの配信は、サーバ側における最小の、又は縮小された状態情報により、スケーラビリティをもたらすことができる。ＨＴＴＰストリーミング技術の例には、Ｍｉｃｒｏｓｏｆｔ（商標）ＩＩＳ Ｓｍｏｏｔｈ Ｓｔｒｅａｍｉｎｇ、Ａｐｐｌｅ（商標）ＨＴＴＰ Ｌｉｖｅ Ｓｔｒｅａｍｉｎｇ、及びＡｄｏｂｅ（商標）ＨＴＴＰ Ｄｙｎａｍｉｃ Ｓｔｒｅａｍｉｎｇを含めることができる。

ＤＡＳＨは、標準化されたＨＴＴＰストリーミングプロトコルである。図１に示すように、ＤＡＳＨは、メディアプレゼンテーション記述（ＭＰＤ）メタデータファイル１０２について種々のフォーマットを指定することができる。ＭＰＤメタデータファイル１０２は、サーバ（ならびにセグメントフォーマット）において記憶されたメディアコンテンツ表現の構造に関する情報と種々のバージョンに関する情報とを提供することができる。ＭＰＤメタデータファイルは、メディアプレーヤの初期化セグメント及びメディアセグメントについての情報を含んでいる。ＭＰＤメタデータファイルによって提供されるこの情報は、メディアプレーヤによって、コンテナフォーマット及びメディアタイミング情報を確定するのに使用され得る。これにより、メディアプレーヤは、セグメントをメディアプレゼンテーションタイムラインにマッピングして、プレゼンテーションを他の表現と切り換え、同期させることが可能になる。ＤＡＳＨ技術はまた、Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ（ＭＰＥＧ）、Ｏｐｅｎ ＩＰＴＶ Ｆｏｒｕｍ（ＯＩＰＦ）、及びＨｙｂｒｉｄ Ｂｒｏａｄｃａｓｔ Ｂｒｏａｄｂａｎｄ ＴＶ（ＨｂｂＴＶ）など、他の組織によっても標準化されている。

ＤＡＳＨクライアントは、一連のＨＴＴＰ要求／応答トランザクションを通じて、セグメントをダウンロードすることによって、マルチメディアコンテンツを受け取ることができる。ＤＡＳＨは、モバイルデバイスに利用可能な帯域幅が変わるにつれてメディアコンテンツの種々のビット速度表現間の動的に切り換わる能力をもたらすことができる。したがって、ＤＡＳＨは、（１）変わるネットワーク及びワイヤレスリンクの状態、（２）ディスプレイ解像度など、ユーザ選好及びデバイス機能、（３）種々のタイプのセントラルプロセッシングユニット（ｃｅｎｔｒａｌ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ：ＣＰＵ）、並びに（４）種々のメモリリソースなど、に対する速い適応を可能にすることができる。ＤＡＳＨの動的適応は、他のストリーミングプロトコルよりも短い起動遅延及び少ない再バッファリングイベントにより、より良い体感品質（ＱｏＥ）をユーザにもたらすことができる。

ＤＡＳＨにおいては、メディアプレゼンテーション記述（ＭＰＤ）メタデータ１０２は、図２ｂに示すウェブ／メディアサーバ２１２の中に記憶されたメディアコンテンツ表現の構造についての情報と種々のバージョンについての情報とを提供することができる。図１に示す例においては、ＭＰＤメタデータは、この例では、６０秒など、時間的に、所定の長さである期間に分割される。各期間は、複数の適応セット１０４を含むことができる。各適応セットは、１つ又は複数のメディア成分についての情報にいくつかのエンコードされた選択肢を与えることができる。たとえば、この例における適応セット０は、ビット速度による種々の選択肢、及びモノラル、ステレオ、又はサラウンドのサウンドによる選択肢など、多様な異なるエンコードされたオーディオ選択肢を含むことが可能になる。期間ＩＤにわたってマルチメディアプレゼンテーションに異なる品質のオーディオを提供することに加えて、適応セットはまた、種々の言語の中にオーディオを含むこともできる。適応セットの中に提供された種々の選択肢は、表現１０６と称される。

図１においては、適応セット１は、５メガビット毎秒（Ｍｂｐｓ）、２Ｍｂｐｓ、５００キロビット毎秒（ｋｂｐｓ）、又はトリックモードなど、種々のビットレートにおいてビデオを提供するように示されている。トリックモードは、マルチメディアストリーミングファイルの中の検索、早送り、巻戻し、又は場所の他の変更を行うのに使用され得る。加えて、ビデオはまた、２次元（２Ｄ）、又は３次元（３Ｄ）ビデオなど、種々のフォーマットにおいても利用でき得る。各表現１０６は、セグメント情報１０８を含むことができる。セグメント情報は、初期化情報１１０、及び実際のメディアセグメントデータ１１２を含むことができる。この例においては、ＭＰＥＧ４（ＭＰ４）ファイルが、サーバからモバイルデバイスにストリーミングされる。ＭＰ４がこの例においては使用されているが、先に論じたように、幅広く多様な異なるコーデックが使用され得る。

適応セットの中のマルチメディアは、より小さいセグメントにさらに分割可能である。図１の例においては、適応セット１の６０秒ビデオセグメントは、１５秒ごとの４つのサブセグメント１１２にさらに分割される。これらの例は、限定しているように意図していない。適応セット及び各メディアセグメント又はサブセグメントの実際の長さは、メディアのタイプ、システム要件、及び干渉の潜在的タイプなどに依存する。実際のメディアセグメント又はサブセグメントは、１秒未満の長さから数分の長さに及ぶ長さとすることができる。

図２ａは、経時的に変動するＨＴＴＰ適応型ストリーム（ＨＡＳ）２１０の例図を提供している。第１の３０秒期間においては、クライアントはまず、高品質表現２０２からセグメント２０８を取り出す。この例におけるセグメントは、約１０秒の長さである。しかしながら、これは、限定しているように意図していない。セグメントは、サーバにおいて任意の所望の長さであるように構成可能である。加えて、サブセグメントもまた、ダウンロード可能である。

次いで、クライアントは、中位品質表現２０４の中の２つのセグメントを取り出す。１０秒持続時間の第２の期間においては、クライアントは、再度、切り換え、低位品質表現２０６からセグメントを取り出す。クライアントは、マルチメディアサーバによる無線リンク品質の変更により、低位品質表現に切り換えることができる。２０秒持続時間の第３の期間においては、クライアントは、図２ａに示すように、中位品質表現２０４に戻るように切り換える。クライアントは、サーバからマルチメディアデバイスにおいて動作するクライアントまでのマルチメディアファイルのＨＡＳの全長にわたって、引き続き、選定された表現にセグメントを要求することができる。

図２ｂに示すように、ＭＰＤメタデータ情報は、クライアント２２０に伝達可能である。クライアントは、モバイルデバイスにおいて動作することができる。モバイルデバイスは、ストリーミングメディアを受け取り、表示するように構成されたワイヤレスデバイスとすることができる。１つの実施形態においては、モバイルデバイスは、ストリーミングメディアを受け取り、次いで、それを別のデバイス、又はディスプレイデバイスに伝達して、レンダリングするなど、この機能のほんの一部しか行うことができない。モバイルデバイスは、クライアント２２０を動作させるように構成可能である。クライアントは、ＨＴＴＰ ＧＥＴ２４０メッセージ、又は一連の部分的ＧＥＴメッセージを使用して、セグメントを要求することができる。クライアントは、たとえば、オンタイム要求、及び一連のセグメントのスムーズなプレイアウトを管理することによって、或いはワイヤレスリンク、デバイスの状態、若しくはユーザ選好の変更に反応するようにビットレート又は他の属性を調節することによって、ストリーミングセッションを制御することができる。

図２ｂは、ＤＡＳＨベースのストリーミングフレームワークを示している。ウェブ／メディアサーバ２１２の中のメディアエンコーダ２１４は、オーディオ／ビデオ入力２１０からの入力メディアを、記憶又はストリーミングのためのフォーマットにエンコードすることができる。メディアセグメンタ２１６が、入力メディアを一連のセグメント２３２に分けるのに使用可能であり（２３２）、それは、ウェブサーバ２１８に提供され得る。クライアント２２０は、ウェブサーバ（たとえば、ＨＴＴＰサーバ）に送られたＨＴＴＰ ＧＥＴメッセージを使用して、セグメントの中の新規データを要求することができる（２３４）。

たとえば、クライアント２２０のウェブブラウザ２２２は、ＨＴＴＰ ＧＥＴメッセージ２４０を使用して、マルチメディアコンテンツを要求することができる。ウェブサーバ２１８は、マルチメディアコンテンツのためのＭＰＤ２４２をクライアントに提供することができる。ＭＰＤは、関連のメタデータ情報に示される各セグメント、及びセグメントの対応する位置のインデックスを運ぶのに使用可能である（２５２）。ウェブブラウザは、２３６に示すように、ＭＰＤ２４２に従って、一セグメントごとに、サーバからメディアをプルすることができる。例として、ウェブブラウザは、ＨＴＴＰ ＧＥＴ ＵＲＬ（ｆｒａｇ １ ｒｅｑ）２４４を使用して、第１のセグメントを要求することができる。ユニフォームリソースロケータ（ｕｎｉｆｏｒｍ ｒｅｓｏｕｒｃｅ ｌｏｃａｔｏｒ：ＵＲＬ）又はユニバーサルリソースロケータは、クライアントがどのセグメントを要求すべきであるかをウェブサーバに教えるのに使用可能である（２５４）。ウェブサーバは、第１のフラグメント（すなわち、セグメント１ ２４６）を提供することができる。後続のセグメントに関しては、ウェブブラウザは、ＨＴＴＰ ＧＥＴ ＵＲＬ（ｆｒａｇ ｉ ｒｅｑ）２４８を使用して、セグメントｉを要求することができ、ただし、ｉは、セグメントの整数インデックスである。結果として、ウェブサーバは、セグメントｉ ２５０を提供することができる。セグメントは、メディアデコーダ／プレーヤ２２４を介してクライアントに提示され得る。

図３は、マルチメディアコンテンツを提供するＨＴＴＰサーバ３１０と、ＵＥ３３６などのモバイルデバイスにおいて動作する３ＧＰＰクライアント３３８との間のマルチメディアコンテンツ３１２の流れを示している。ＨＴＴＰサーバは、ワイヤレス広域ネットワーク（ｗｉｒｅｌｅｓｓ ｗｉｄｅ ａｒｅａ ｎｅｔｗｏｒｋ：ＷＷＡＮ）のコアネットワーク３２４と通じているパブリック若しくはプライベートネットワーク３２２（又はＩｎｔｅｒｎｅｔ）とインターフェースを取ることができる。１つの実施形態においては、ＷＷＡＮは、３ＧＰＰ ＬＴＥベースのネットワーク（たとえば、Ｒｅｌ．１１若しくは１２）、又はＩＥＥＥ８０２．１６ベースのネットワーク（たとえば、８０２．１６−２００９若しくは８０２．１６ｍ−２０１１）とすることができる。コアネットワークは、無線アクセスネットワーク（ＲＡＮ）３３２を介して、発展型パケットシステム（ｅｖｏｌｖｅｄ ｐａｃｋｅｔ ｓｙｓｔｅｍ：ＥＰＳ）などのワイヤレスネットワーク３３０にアクセスすることができる。ＲＡＮは、ノード（たとえば、発展型ＮｏｄｅＢ（ｅＮＢ）３３４）を介して、ＵＥにおいて動作するクライアントにマルチメディアコンテンツを提供することができる。

ＱｏＥを意識した適応型ストリーミング
ＨＴＴＰ適応型ストリーミング（ＨＡＳ）の体感品質（ＱｏＥ）は、表現及び対応するセグメントをホスティングする１つ又は複数のサーバによって影響され得る。先に論じたように、現在の仕様は、すべてのサーバ（ベースユニフォームリソースロケータ（ＵＲＬ））がそれぞれ、表現及び対応するセグメントをすべて含んでいることを仮定している。これは、部分的コンテンツしか有していないサーバは、ＭＰＤファイルの中にリストされ得ないことを意味している。部分的コンテンツを有するサーバがＭＰＤファイルの中にリストされる場合、それらのサーバは、ある特定のサーバに要求が行われ、それが満たされないことになるまでは、ある種の表現又はセグメントを有しないことをクライアントは確定することができなくなる。これが生じるとき、欠落したセグメントを取り出す際の遅延を起因として、クライアントＱｏＥは、急激に下がる可能性がある。

サーバは、限定された動作容量を有する可能性がある。特定のサーバがオーバーロードされるようになり、適正な時間フレームにおいてコンテンツを配信することができない場合、潜在的なセグメント取出し遅延、又は大きいパケット損失を回避するために、サーバからのそのダウンロード速度を低減することを、サーバが、モバイルデバイスにおいて動作する１つ又は複数のクライアントに知らせるやり方はない。

加えて、サーバは、限定された帯域幅を有する可能性がある。多数のクライアントが、共通の限定された帯域幅を共有し、リソースについて争うとき、多数のユーザに対するいくつかのＤＡＳＨストリームの存在は、輻輳を生じさせ、クライアントにおける再生体感を損なわせることが起こり得る。サーバによるセグメントを提供する能力を抑えることは、クライアントにおける望ましくない再バッファリングにつながる可能性がある。このことは、特に、多数のクライアントがサーバからの同じＤＡＳＨコンテンツをフェッチしようと試みているイベントについて真実であり得る。

メディアストリーミングには、しばしば、相対的に大きい帯域幅リソースが必要であるので、メディアサーバの負荷が、しばしば、非常に重いことがあり得る。メディアサーバにおける負荷を低減させるのに役立つことができる１つの手法が、ピアアシストＤＡＳＨ（ｐＤＡＳＨ）である。ピアアシストＤＡＳＨを使用する手法においては、メディアコンテンツの特定のセグメントをすでにダウンロードし、キャッシュしているクライアントは、それらのセグメントをピアツーピア構成で他のクライアントに提供することができる。この方式においては、クライアントは、他のクライアントから少なくともいくつかのセグメントをストリーミングすることができる。これにより、それは、クライアントが、限定された容量の中でアシスタントサーバとして機能することによって負荷の一部を担うことを可能にするので、メディアサーバにおける負荷が低減される。１つの実施形態によれば、メディアサーバは、ピアツーピア（ｐｅｅｒ−ｔｏ−ｐｅｅｒ：Ｐ２Ｐ）キャッシング利用可能性伝達を送ることによって、ピアツーピアキャッシング及びストリーミングが利用可能であることをクライアントに通知し得る。ピアリングデバイス間のキャッシング及びストリーミングのスケジュールは、Ｐ２Ｐサーバによって確定され得る。メディアサーバは、Ｐ２Ｐサーバの識別情報についてクライアントに通知するために、Ｐ２Ｐサーバ識別情報ベースの伝達をクライアントに送ることができる。

別の実施形態によれば、サーバは、ＭＰＤなど、マニフェストファイルの中の、クライアントに提供されるＤＡＳＨ表現のセットを修正することができる。修正は、サーバが、利用可能な表現及び／若しくはセグメント、利用可能なサーバ容量、並びに／又は利用可能なサーバ帯域幅若しくはスループットなどの情報をクライアントに伝達することを可能にすることができる。次いで、クライアントは、活発に利用可能である表現を要求することができる。より大きい容量又は帯域幅を有する別のサーバが利用可能でない場合、クライアントは、利用可能なサーバ容量及び帯域幅をオーバーロードしない表現又はセグメントを選定することができる。

典型的には、サーバは、＜Ｂａｓｅ ＵＲＬ＞ｈｔｔｐ：／／１９２．１６８．１０．１０／ｓｉｎｔｅｌ／，／Ｂａｓｅ ＵＲＬ＞など、サーバインターネットプロトコル（ＩＰ）アドレスを含む、サポートされたベースＵＲＬサイトを伝達する。サーバＩＰアドレスに加えて、選定された表現がサーバにおいて利用可能であるか否かを示す、各表現に対応するバイナリコードが含められ得る。たとえば、表現利用可能性は、利用可能な表現コード（ａｖａｉｌａｂｌｅ ｒｅｐｒｅｓｅｎｔａｔｉｏｎ ｃｏｄｅ：ＡＲＣ）と称されるバイナリコードを使用して伝達され得る。サーバからの伝達は、＜Ｂａｓｅ ＵＲＬ ａｒｃ＝”００１１００１１１１”＞ｈｔｔｐ：／／１９２．１６８．１０．１０／ｓｉｎｔｅｌ／＜／ＢａｓｅＵＲＬ＞など、ＡＲＣメッセージを含むことができる。これは、続く諸段落の中でより完全に論じられよう。

表現の利用可能性を伝達する能力により、サーバが、利用可能な表現について、更新されたバイナリコードを用いてクライアントに動的に通知することを可能にすることができる。このバイナリコードは、サーバの機能及び／又はスループットに負担をかけることになる、表現に対するクライアント要求を制限するのにサーバによって使用可能である。クライアントは、そのビットレート適応ロジックの中に、更新されたバイナリコードを含み、活発に利用可能なリスト内の表現のみを要求することができる。フィードバック機構により、サーバによってサービス提供されるクライアントは、サーバにおける輻輳問題を回避するのに役立つことになる決定を行うことが可能になり、それによって、再バッファリングイベントを低減し、クライアントに伝達可能な表現レベルを増加させることによって、クライアントデバイスにおけるＱｏＥが高められる。

利用可能な表現コード
実施形態によれば、ＡＲＣなどのバイナリコードは、ＭＰＤファイルなど、マニフェストファイルの中の各表現についてあらかじめ確定され得る。１つの例においては、各ＡＲＣは、表現ごとに「０」又は「１」のいずれかとすることができるビットを割り当てることができ、それは、表現アクセスビット（ｒｅｐｒｅｓｅｎｔａｔｉｏｎ ａｃｃｅｓｓ ｂｉｔ：ＲＡＢ）と称される。ランタイム時に、サーバは、クライアントにサービス提供されているストリーミングメディアについてのサーバのアップロード速度をコンピュータ計算し、動的にＡＲＣを更新することができ、それは、次いで、それに従って各クライアントに通知するのに使用される。

ＡＲＣは、いくつかの異なるやり方で伝達可能である。１つの例においては、ＡＲＣは、ＭＰＤの中のＢａｓｅＵＲＬ要素に属性として追加可能である。次いで、クライアントは、更新されたＡＲＣ値を用いて、ＭＰＤを定期的に要求することができる。しかしながら、頻繁なＭＰＤ更新は、ネットワーク接続にわたる余分なオーバーヘッドトラフィックにつながる可能性がある。別の例においては、ＡＲＣは、クライアントに、ＨＴＴＰ Ｐｏｓｔ要求を介して送られてもよい。この手法が使用されるとき、クライアントは、そのようなＨＴＴＰポスト要求をリッスンすることができる単純なＨＴＴＰサーバを実装することができる。別の例においては、ＡＲＣは、クライアントに送られているセグメントパケットのヘッダ値として、又は１番目のｎビットとしてアペンドされ得る（ただし、ｎは、利用可能な表現の数である）。

セグメント利用可能性コード

ｐＤＡＳＨ構成においては、参加ピアデバイスは、概して、同時にキャッシュされた表現のセグメントをすべて有するとは限らないことになる。結果として、セグメント利用可能性を伝達する効率的なやり方が、ｐＤＡＳＨ構成でピアツーピアストリーミングを体系化し調整するためには非常に役に立つことになる。別の実施形態によれば、セグメント利用可能性は、セグメント利用可能性コード（ｓｅｇｍｅｎｔ ａｖａｉｌａｂｉｌｉｔｙ ｃｏｄｅ：ＳＡＣ）と称されるバイナリコードを使用して伝達され得る。サーバからのこの伝達は、＜Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ＿ＩＤ＞：｛０｜１｝_ｍなど、メッセージの中にＳＡＣを含むことができ、ただし、ｍは、指定された表現の中のセグメントの数である。これは、続く諸段落の中でより完全に論じられよう。

クライアントにセグメント利用可能性を伝達することによって、サーバは、どのセグメントがサーバにより利用可能でないかについて事前にクライアントに通知することができる。この情報があると、ストリーミング中に、あるサーバにおいて利用可能でないセグメントに当たるクライアントは、すぐに、代わりのサーバにセグメントを要求することができる（ピアアシストＤＡＳＨにおいては、ピアデバイスは、サーバとして機能していることができる）。これにより、クライアントは、セグメントがサーバにおいて利用可能でないことを推測する前に、いくつかの満たされていない要求をサーバに送る必要性、すなわち、バッファリングイベントを受ける可能性がなくなる。

実施形態によれば、ＳＡＣなどのバイナリコードは、ＭＰＤファイルなどのマニフェストファイルの中の表現においてセグメントごとにあらかじめ確定され得る。１つの例においては、各ＳＡＣは、セグメントごとに、０又は１のいずれかとすることができるビットを割り当てることができる。ランタイム時に、サーバは、１つ又は複数のセグメントの利用可能性が変更するとき、ＳＡＣを動的に更新することができる。

図４は、利用可能な表現の利用可能なセグメントを含むＭＰＤファイルの例を示す表を提供している。この例においては、ＭＰＤファイルは、異なる６表現を含み、各表現は、０から５に及ぶ表現識別情報番号（ｒｅｐｒｅｓｅｎｔａｔｉｏｎ ｉｄｅｎｔｉｆｉｃａｔｉｏｎ ｎｕｍｂｅｒ：ＲｅｐＩＤ）を用いてラベル付けされている。各表現は、異なるビットレートを有する。この例においては、ＲｅｐＩＤ０は、最低ビットレートを有し、ＲｅｐＩＤ５は、最高ビットレートを有し、ビットレートは、キロビット毎秒（Ｋｂｉｔ／秒）の単位で測定される。各表現ＲｅｐＩＤはまた、速度利用可能性ビット（ｒａｔｅ ａｖａｉｌａｂｉｌｉｔｙ ｂｉｔ：ＲＡＢ）が割り当てられ、図示のように、表現ＲｅｐＩＤ０は、ＲＡＢ５に割り当てられ、ＲｅｐＩＤ５は、ＲＡＢ０に割り当てられる。認識され得るように、代替の構成もまた可能である。

例のＭＰＤファイルは、６の表現を含んでいるので、対応するＡＲＣは、ＲＡＢ５〜ＲＡＢ０を含む６の表現アクセスビット（ｒｅｐｒｅｓｅｎｔａｔｉｏｎ ａｃｃｅｓｓ ｂｉｔ：ＲＡＢ）を含むことができる。この例の実装形態においては、最上位ビットが、最低ビットレートを有する表現に対応し、その逆も同様である。この例は、限定しているように意図していない。いくつかの異なるタイプのコードが、サーバから各クライアントにＡＲＣを伝達するのに使用され得る。

加えて、異なる各表現については、０から１９に及ぶセグメント識別情報番号（ｓｅｇｍｅｎｔ ｉｄｅｎｔｉｆｉｃａｔｉｏｎ ｎｕｍｂｅｒ：ＳｅｇｌＤ）を用いてラベル付けされた２０の異なるセグメントがある。この例においては、各ＳｅｇＩＤはまた、セグメント利用可能性ビット（ｓｅｇｍｅｎｔ ａｖａｉｌａｂｉｌｉｔｙ ｂｉｔ：ＳＡＢ）が割り当てられ、図示のように、ＳｅｇＩＤ０は、ＳＡＢ０に割り当てられる。例のＭＰＤファイルの中に記述される各表現は、２０のセグメントを含んでいるので、各表現に対応するＳＡＣは、ＳＡＢ０〜ＳＡＢ１９を含む２０ビット（たとえばＳＡＢ）を含むことができる。ＳＡＢ値０は、対応するセグメントが利用可能でないことを表し、一方ＳＡＢ値１は、対応するセグメントが利用可能であることを表す。ＳｅｇＩＤのＳＡＢに対する代替のマッピングもまた、ビット値のセグメント利用可能性に対する代替のマッピングと同様に可能であるが、この例は、限定しているように意図していない。さらには、上に説明したように、多くの異なる数のセグメントが可能であり、２０のセグメントは、図４を過度に大きく又は難解にしないようにするために、この非限定的な例において使用されている。

図５は、サーバにおける選定された利用可能な帯域幅速度を示すのに使用されるＡＲＣコードの表の例を提供している。わかるように、サーバにおける各表現については、対応する利用可能な表現ビットが、「０」などの選定されたバイナリ値に設定されるとき、クライアントによる表現アクセスは、無効にされる。利用可能な表現ビットが、「１」などの逆のバイナリ値に設定されるとき、表現アクセスは有効にされる。これにより、各クライアントは、どの表現がクライアントに利用可能であるかを知ることが可能になる。

前諸段落の中の例においては、どの表現がサーバにおいて利用可能であるかを伝達するために、コードが使用される。コードは、各ＭＰＤファイルにおいて伝達される。しかしながら、コードは、いかに速くサーバ帯域幅又はサーバ容量の変更がＨＡＳシステムにおいて生じるかによって決まる所望の周波数における他のやり方でも伝達され得る。

さらなる例においては、ストリーミングセッション中、サーバ及びクライアントは、各クライアントによってＱｏＥを高めるために、伝達及び他の動作の組を行うことができる。サーバは、各クライアントからフィードバック情報を受け取って、ユーザごとに割り当てられるべき帯域幅をコンピュータ計算することができる。フィードバック情報は、ＨＡＳセッション中に、ユーザによって知覚された平均的な品質、及びクライアントが受けた再バッファリングイベントの数を含むことができる。１つの実施形態においては、ユーザによって知覚された品質は、各セグメントと関連付けられた、且つ達成されることになる平均オピニオン評点（ｍｅａｎ ｏｐｉｎｉｏｎ ｓｃｏｒｅ：ＭＯＳ）を大まかに推定する、あらかじめ計算された品質係数とすることができる。このあらかじめ計算された品質係数は、ＭＰＤなど、マニフェストファイルの中に含められ得る。帯域幅割当てに使用されるアルゴリズムは、続く諸段落においてさらに論じられよう。

サーバは、１つ又は複数のクライアントのダウンロード速度が、サーバによる被最大サポート帯域幅速度、又は特定のクライアントによる被最大サポート速度を超えないように、ＡＲＣを動的に修正することができる。次いで、サーバは、更新されたＡＲＣをユーザＨＴＴＰ要求に対する応答を通じてユーザに送信することができる。ＡＲＣ情報を伝達することの例には、ＭＰＤなどのマニフェストファイルにおいてＡＲＣ情報を送信すること、カスタムＨＴＴＰヘッダにおいてＡＲＣ情報を送信すること、ＨＡＳを伝達するのに使用される無線チャネル以外の別個の無線チャネルを介してＡＲＣ情報を送信すること、より高いレイヤの信号伝達（ｓｉｇｎａｌｉｎｇ）を介してＡＲＣを送信すること、ＨＴＴＰポスト要求を介してＡＲＣを送信すること、又はクライアントに送られるセグメントパケットにＡＲＣをアペンドすることによってＡＲＣを送信することが含まれる。その場合、クライアントは、ＡＲＣを受け取り、後続の要求を行うときにクライアントのビット速度適応アルゴリズムにおいてその情報を使用することができる。

加えて、クライアントについての改善されたＱｏＥを容易にすることができるいくつかの追加的なタイプの伝達がある。上に説明したように、サーバは、特定のメディアコンテンツに対応するＡＲＣを更新することができる。そのようなＡＲＣ更新は、サーバが、いくつかのクライアントについてのＱｏＥを最大にしようと試みるとき、多様な理由で行われることがあり得る。たとえば、ネットワークトラフィックがあまりに重過ぎて、サーバがすべてのクライアントに対して最高ビットレートを伴う表現をストリーミングできない場合、サーバは、クライアント間の何らかのＱｏＥ不均衡を緩和するために、最高ビットレートを伴う表現を利用できなくすることができる。一方、サーバ上の負荷が低減される場合、サーバは、再度、表現を利用可能にすることができる。いずれの場合においても、ＡＲＣは、表現の変更された利用可能性を表すために更新されることになる。そのような更新が行われるとき、サーバは、１つ又は複数のクライアントにＡＲＣ変更伝達を送って、変更がＡＲＣにおいて行われたことをクライアントに通知することができる。クライアントは、次いで、すぐに、ＡＲＣの更新されたバージョンの要求を送ることができる。

別の例においては、ストリーミングセッション中、サーバにおけるＭＰＤファイルが、更新され得る。この更新は、たとえば、利用可能な表現における変更、或いは１つ又は複数の表現について利用可能なセグメントにおける変更を示すことが可能になる。サーバは、複数のクライアントに、ＭＰＤファイルが変更されたことを示すＭＰＤ変更伝達を送ることができる。クライアントは、次いで、いくつかの所定の定期的スケジュールに従って要求を行うために待機するのではなく、ＭＰＤファイルの更新されたバージョンをすぐに要求することができる。ＭＰＤファイルの更新されたバージョンは、クライアントに、クライアントＱｏＥを高めることを可能にする情報を提供することができる。たとえば、更新されたＭＰＤファイルは、クライアントが、現在、ストリーミングしているメディアコンテンツについて、より高いビットレートを伴う新規表現が利用可能であることを示すことが可能になる。クライアントは、後続のセグメントが、より高いビットレートを伴う新規表現から選定されることをすぐに要求することができる。

別の例においては、サーバは、複数のクライアントに、メディアサーバが指定された時刻にオフラインになることを示すサーバ利用可能性伝達を送ることができる。この伝達を受け取るクライアントは、今度は、この情報を使用して、いくつかのやり方で、それらの動作を調節し得る。たとえば、サーバに対して行われた要求が、指定された時刻前に満たされなかった場合、クライアントは、指定された時刻に達すると、すぐに代替のサーバに要求を送ることができる。さらには、クライアントは、すぐに代替のサーバに任意の後続の要求を送ることができる。両方の場合において、クライアントは、要求がサーバにより満たされることになるのを待機するという無駄について事前に知らされることになる。

別の例においては、ストリーミングセッション中、サーバは、（たとえば、種々のローディング状態に応答して）そのアップロード速度を調節し得る。サーバが、そのような調節を行うとき、サーバは、複数のクライアントに、アップロード速度が変更になったことを示すアップロード速度伝達を送ることができる。これにより、ストリーミング性能変更が観察されるとき、クライアントが、待機し、最終的には、アップロード速度が変更になったことを推測することの必要性がなくなる。したがって、クライアントは、すぐにいくつかのやり方でそれらの動作を調節することができる。たとえば、アップロード速度が低下した場合、クライアントは、より低いビットレートを伴う表現に後続のセグメントを要求するようにすぐに選択して、バッファリングイベントを回避することができる。一方、アップロード速度が向上した場合、クライアントは、より高いビットレートを伴う表現に後続のセグメントを要求し得る。

別の例においては、ストリーミングセッション中、第１のサーバは、サーバにおけるＭＰＤファイルと共通する少なくとも１つの表現を有する第２のサーバが、最近、オンラインになったことの通知を受け取ることができる。第１のサーバは、次いで、複数のクライアントに、クライアントが所望のメディアコンテンツをストリーミングし得る選択肢として、第２のサーバが利用可能であることを示す新規サーバ伝達を送ることができる。クライアントは、次いで、第１のサーバから引き続き所望のコンテンツをストリーミングするか、又は第２のサーバから所望のコンテンツのストリーミングを開始するかのいずれかである、情報に基づいた決定を行うことができる。第１のサーバによる不十分な転送速度を受けたクライアントは、より良い転送速度において所望のメディアコンテンツを受け取るために、たとえば、第２のサーバからのストリーミングを開始するようにすぐに選択することができる。

いくつかの場合に、クライアントデバイスは、メディアサーバにおいてすぐには利用できないが、トランスコーディングを通じたメディアサーバによって提供され得るエンコーディングにおけるメディアコンテンツを受け取ることから利益を受ける場合がある。たとえば、クライアントデバイスは、限定された記憶容量を有する場合があり、そのため、ファイルサイズを低減させることから利益を受ける場合がある。クライアントデバイスはまた、メディアコンテンツ表現がメディアサーバにおいて記憶されているフォーマットのうちのいずれをもサポートしない場合がある。これらのタイプの問題に対処するために、メディアサーバは、あるエンコーディングが別のエンコーディングに直接、それによって変換され得るトランスコーディング機能を提供することができる。固定ビット速度（ｃｏｎｓｔａｎｔ ｂｉｔ ｒａｔｅ：ＣＢＲ）トランスコーディング、可変ビット速度（ｖａｒｉａｂｌｅ ｂｉｔ ｒａｔｅ：ＶＢＲ）トランスコーディング、及び２パス可変ビット速度（２−ｐａｓｓ ｖａｒｉａｂｌｅ ｂｉｔ ｒａｔｅ：２−Ｐａｓｓ ＶＢＲ）トランスコーディングなど、多くの異なるトランスコーディング法が使用され得る。ＤＡＳＨの文脈においては、メディアサーバは、複数のクライアントに、メディアサーバがＤＡＳＨメディアコンテンツをトランスコーディングできることをクライアントに知らせるために、トランスコーディング機能伝達を送ることができる。メディアサーバはまた、複数のクライアントに、コーデック、カプセル化フォーマット、ＭＩＭＥタイプ、ビットレート、解像度、及びフレーム速度を変換するための利用可能な構成を含む、いずれの特定のタイプのトランスコーディングをメディアサーバがサポートするかを示すトランスコーディングサポート伝達を送ることもできる。それに応答して、クライアントは、いずれかがある場合に、どのタイプのトランスコーディングをクライアントが選定するかを示す伝達を送ることができる。

ストリーミングセッション中、クライアントは、ＱｏＥの変更を受ける場合がある。クライアントＱｏＥを改善する際にメディアサーバを補助するためには、クライアントは、サーバに、平均的なＱｏＥを示す伝達を定期的に送ることができる。この伝達は、平均的なダウンロード速度、バッファリングイベントの数、及び平均的な平均オピニオン評点（ＭＯＳ）など、１つ又は複数の測定基準に付随する情報を含むことができる。メディアサーバは、このタイプのクライアントフィードバックを使用して、ストリーミングクライアント間の負荷均衡をいかに最良に行うべきかを動的に確定することができる。

加えて、クライアントユーザ機器は、ＵＥがストリーミングセッション中にＱｏＥの変更を受けたときを検出するように構成され得る。そのような変更が行われたとき、クライアントＵＥは、表現の新規セグメントの要求を自動的に送るように構成可能であり、このセグメントは、検出されたＱｏＥ変更に一部基づいて選択される。たとえば、ダウンロード速度が低下したためにＱｏＥが変更した場合、ＵＥは、可能性としてバッファリングイベントがほとんどなくなるように、より低いビットレートを伴う新規セグメントを要求することができる。一方、ダウンロード速度が向上した場合、ＵＥは、より高いビットレートを伴う新規セグメントを要求することができる。加えて、ＵＥはまた、メディアサーバに、新規セグメントの要求の前に要求されていた任意のダウンロードに関する取消し要求を自動的に送るように構成可能である。これにより、メディアサーバは、任意の先に要求されたセグメントの送信をすぐに中止することが可能になる。

ピアアシストＤＡＳＨ（ｐＤＡＳＨ）設定においては、クライアントＵＥはまた、ＵＥがピアツーピア（Ｐ２Ｐ）ストリーミングモードをサポートしているかどうかを示すＰ２Ｐキャッシング利用可能性伝達を送ることもできる。Ｐ２Ｐサーバは、このタイプの伝達を複数のＵＥから受け取り、それに従って、デバイスをピアするためのキャッシング及びストリーミングのスケジュールを生み出すことができる。

メディアサーバがトランスコーディングサービスを提供する場合、ＵＥはまた、メディアサーバに、コーデック、カプセル化、ＭＩＭＥタイプ、ビットレート、解像度、及び／又はフレーム速度のフォーマットのいずれがＵＥに推奨されるかを示すＤＡＳＨ表現推奨伝達を送るようにも構成可能である。これにより、メディアサーバは、ＵＥに適切な表現及び表現セグメントを選定することが可能になる。

図６は、図６の中のフローチャートで示すように、ハイパーテキスト転送プロトコル（ＨＴＴＰ）適応型ストリーミングを提供し、クライアントに、いくつかの異なるタイプの伝達を送るように動作可能なメディアサーバのコンピュータ回路の機能６００を示している。６１０に示すように、メディアサーバは、複数のクライアントに、メディアサーバが、指定された時刻にオフラインになることを示すサーバ利用可能性伝達を送ることができる。６２０に示すように、メディアサーバは、複数のクライアントに、メディアサーバのアップロード速度の変更を示すアップロード速度伝達を送ることができる。６３０に示すように、メディアサーバは、複数のクライアントに、メディアサーバにおけるＭＰＤファイルと共通する少なくとも１つの表現を有する新規サーバが利用可能になるときを示す新規サーバ伝達を送ることができる。６４０に示すように、メディアサーバは、メディアサーバから複数のクライアントに、少なくとも１つの変更がメディアサーバにおけるＭＰＤファイルに対して行われたときを示すメディアプレゼンテーション記述（ＭＰＤ）ＭＰＤ変更伝達を送ることができる。これらのメッセージのうちの１つ又は複数が、必要に応じて、送られてよい。異なるタイプのメッセージがまた、任意の順序で送られてもよい。１つの例においては、メディアサーバは、利用可能な表現コード（ＡＲＣ）をメディアサーバにおいて利用可能な表現と関連付けするようにさらに構成された回路を有することができる。ＡＲＣは、バイナリ文字列を含むことができ、ただし、各ビットが、メディアサーバにおいて利用可能な表現に対応する。いくつかの実施形態においては、ＡＲＣの中のビット値１は、そのビットに対応する表現が利用可能であることを表すことができる。ＡＲＣの中の１つ又は複数のビットは、ＨＴＴＰポスト要求を介してクライアントに送られ得る。ＡＲＣはまた、クライアントに送られるセグメントパケットにアペンドされても、又はセグメントパケットのヘッダの中に含まれていてもよい。ＡＲＣはまた、ＭＰＤメタファイルの中に属性として含まれていてもよい。さらには、メディアサーバはまた、変更がＡＲＣに対して行われるときはいつでも、複数のクライアントに、ＡＲＣ変更伝達を自動的に送るように構成された回路を有することができる。

別の例においては、メディアサーバは、セグメント利用可能性コード（ＳＡＣ）をメディアプレゼンテーション記述（ＭＰＤ）メタファイルと関連付けるように構成された回路を有することができる。ＳＡＣは、バイナリ文字列を含むことができ、ただし、各ビットが、ＭＰＤメタファイルと関連付けられた表現の中のセグメントの利用可能性に対応する。いくつかの実施形態においては、ＳＡＣの中のビット値１は、そのビットに対応するセグメントが利用可能であることを表すことができる。

別の例においては、メディアサーバは、複数のクライアントに、ピアツーピア（Ｐ２Ｐ）キャッシング及びストリーミングが利用可能であるかどうかを示すＰ２Ｐキャッシング利用可能性伝達を送るように構成された回路を有することができる。加えて、メディアサーバは、複数のクライアントに、ピアリングデバイス間のキャッシング及びストリーミングのスケジュールを管理することを担うＰ２Ｐサーバの識別情報を示すＰ２Ｐサーバ識別情報伝達を送るように構成された回路を有することができる。

図７は、図７の中のフローチャートで示すように、ハイパーテキスト転送プロトコル（ＨＴＴＰ）適応型ストリーミングを提供し、クライアントに、いくつかの異なるタイプのトランスコーディング伝達を送るように動作可能なメディアサーバのコンピュータ回路の機能７００を示している。７１０に示すように、メディアサーバにおけるコンピュータ回路は、クライアントに、メディアサーバがＨＴＴＰを介した動的適応型ストリーミング（ＤＡＳＨ）メディアコンテンツをトランスコーディングできることを示すトランスコーディング機能伝達を送るように構成可能である。７２０に示すように、メディアサーバにおけるコンピュータ回路はまた、クライアントに、メディアサーバがサポートするトランスコーディングのタイプを示すトランスコーディングサポート伝達を送るように構成可能である。トランスコーディングサポート伝達は、コーデック、カプセル化フォーマット、ＭＩＭＥタイプ、ビットレート、解像度、及びフレーム速度を変換するための利用可能な構成を含むことができる。トランスコーディングサポート伝達はまた、メディアサーバが、固定ビット速度（ＣＢＲ）トランスコーディング、可変ビット速度（ＶＢＲ）トランスコーディング、及び２パス可変ビット速度（２−ＰＡＳＳ ＶＢＲ）トランスコーディングをサポートするかどうかを示すことができる。７３０に示すように、メディアサーバにおけるコンピュータ回路はまた、クライアントから、クライアントによって選定されたトランスコーディングタイプを示す伝達を受け取るように構成可能である。７４０に示すように、メディアサーバは、クライアントに、選定されたトランスコーディングコンテンツとともにＤＡＳＨメディアコンテンツを送ることができる。

図８は、図８の中のフローチャートで示すように、ハイパーテキスト転送プロトコル（ＨＴＴＰ）適応型ストリーミングを使用し、メディアサーバと通信するように動作可能なＵＥのコンピュータ回路の機能８００を示している。８１０に示すように、ＵＥにおける回路は、ＵＥが、受け取ったストリーミングメディアにおける体感品質（ＱｏＥ）の変更を受けたときを検出するように構成可能である。８２０に示すように、ＵＥにおける回路はまた、メディアサーバに、ＤＡＳＨ表現における新規セグメントの要求を送るように構成可能である。８３０に示すように、ＵＥにおける回路はまた、新規セグメントの要求の前に要求されていたセグメントダウンロードの取消し要求をメディアサーバに送って、メディアサーバが、新規セグメントの要求の前に要求されていたセグメントダウンロードの送信を中止することを可能にするように構成可能である。

別の例においては、ＵＥにおける回路はまた、メディアサーバに、ＵＥがピアツーピア（Ｐ２Ｐ）ストリーミングモードをサポートするかどうかを示すＰ２Ｐキャッシング利用可能性伝達を送るように構成可能である。ＵＥにおける回路はまた、サーバに、メディアサーバへのストリーミングイベント中に受け取ったストリーミングメディアの平均的な体感品質を示すＱｏＥ伝達を送るように構成可能である。ＵＥにおける回路はまた、メディアサーバに、コーデック、カプセル化、ＭＩＭＥタイプ、ビットレート、解像度、及び／又はフレーム速度のフォーマットのいずれがＵＥに推奨されるかを示すＤＡＳＨ表現推奨伝達を送るように構成可能である。ＵＥにおける回路はまた、ユーザがストリーミングメディアと関連付けられるシーク動作を行うとき、自動的に、ＤＡＳＨ表現における新規セグメントの要求と、取消し要求とを送るように構成可能である。ＵＥにおける回路はまた、ストリーミングメディアのＱｏＥが閾値を下回るとき、自動的に、ＤＡＳＨ表現における新規セグメントの要求と、取消し要求とを送るように構成可能である。

図９は、ユーザ機器（ＵＥ）、移動局（ｍｏｂｉｌｅ ｓｔａｔｉｏｎ：ＭＳ）、モバイルワイヤレスデバイス、モバイル通信デバイス、タブレット、ハンドセット、又は他のタイプのワイヤレスデバイスなど、ワイヤレスデバイスの例図を提供している。ワイヤレスデバイスは、基地局（ｂａｓｅ ｓｔａｔｉｏｎ：ＢＳ）、発展型ＮｏｄｅＢ（ｅＮＢ）、ベースバンドユニット（ｂａｓｅｂａｎｄ ｕｎｉｔ：ＢＢＵ）、遠隔無線ヘッド（ｒｅｍｏｔｅ ｒａｄｉｏ ｈｅａｄ：ＲＲＨ）、遠隔無線機器（ｒｅｍｏｔｅ ｒａｄｉｏ ｅｑｕｉｐｍｅｎｔ：ＲＲＥ）、中継局（ｒｅｌａｙ ｓｔａｔｉｏｎ：ＲＳ）、無線機器（ｒａｄｉｏ ｅｑｕｉｐｍｅｎｔ：ＲＥ）、遠隔無線ユニット（ｒｅｍｏｔｅ ｒａｄｉｏ ｕｎｉｔ：ＲＲＵ）、セントラルプロセッシングモジュール（ｃｅｎｔｒａｌ ｐｒｏｃｅｓｓｉｎｇ ｍｏｄｕｌｅ：ＣＰＭ）、若しくは他のタイプのワイヤレス広域ネットワーク（ＷＷＡＮ）アクセスポイントなど、ノード又は送信局と通信するように構成された１つ或いは複数のアンテナを含むことができる。ワイヤレスデバイスは、３ＧＰＰ ＬＴＥ、ＷｉＭＡＸ、Ｈｉｇｈ Ｓｐｅｅｄ Ｐａｃｋｅｔ Ａｃｃｅｓｓ（ＨＳＰＡ）、Ｂｌｕｅｔｏｏｔｈ（登録商標）、及びＷｉＦｉを含む少なくとも１つのワイヤレス通信標準を使用して通信するように構成可能である。ワイヤレスデバイスは、各ワイヤレス通信標準について別個のアンテナを、又は多数のワイヤレス通信標準について共有のアンテナを使用して通信することができる。ワイヤレスデバイスは、ワイヤレスローカルエリアネットワーク（ｗｉｒｅｌｅｓｓ ｌｏｃａｌ ａｒｅａ ｎｅｔｗｏｒｋ：ＷＬＡＮ）、ワイヤレスパーソナルエリアネットワーク（ｗｉｒｅｌｅｓｓ ｐｅｒｓｏｎａｌ ａｒｅａ ｎｅｔｗｏｒｋ：ＷＰＡＮ）、及び／又はＷＷＡＮにおいて通信することができる。諸例は、モバイルワイヤレスデバイスについて与えられているが、デバイスは、必ずしもワイヤレスである必要はない。ワイヤードのデバイスもまた、ＨＡＳに使用可能である。

図９はまた、ワイヤレスデバイスからのオーディオ入力と出力に使用可能なマイクロフォン及び１つ又は複数のスピーカの例示を提供している。ディスプレイ画面は、液晶ディスプレイ（ｌｉｑｕｉｄ ｃｒｙｓｔａｌ ｄｉｓｐｌａｙ：ＬＣＤ）画面、又は有機発光ダイオード（ｏｒｇａｎｉｃ ｌｉｇｈｔ ｅｍｉｔｔｉｎｇ ｄｉｏｄｅ：ＯＬＥＤ）ディスプレイなどの他のタイプのディスプレイ画面であってよい。ディスプレイ画面は、タッチ画面として構成可能である。タッチ画面は、容量性、抵抗性、又は別のタイプのタッチ画面技術を使用し得る。アプリケーションプロセッサ及びグラフィックスプロセッサが、内部メモリに連結されて、処理機能及び表示機能を提供することができる。不揮発性メモリポートもまた、ユーザにデータ入力／出力のオプションを提供するために使用可能である。不揮発性メモリポートはまた、ワイヤレスデバイスのメモリ機能を拡張するのにも使用され得る。キーボードが、追加的なユーザ入力を提供するために、ワイヤレスデバイスと一体化されても、又はワイヤレスデバイスにワイヤレスで接続されてもよい。仮想キーボードもまた、タッチ画面を使用して提供され得る。

様々な技法、又は特定の態様、若しくはその一部分が、フロッピーディスク、コンパクトディスク読取り専用メモリ（ｃｏｍｐａｃｔ ｄｉｓｃ−ｒｅａｄ−ｏｎｌｙ ｍｅｍｏｒｙ：ＣＤ−ＲＯＭ）、ハードドライブ、非一時的コンピュータ可読記憶媒体、又は任意の他の機械可読記憶媒体などの有形媒体において実装されたプログラムコード（すなわち、命令）の形態をとることができ、ただし、プログラムコードが、コンピュータなどの機械にロードされ、機械によって実行されるとき、機械は、様々な技法を実施するための装置になる。回路は、ハードウェア、ファームウェア、プログラムコード、実行可能なコード、コンピュータ命令、及び／又はソフトウェアを含むことができる。非一時的コンピュータ可読記憶媒体は、信号を含まないコンピュータ可読記憶媒体とすることができる。プログラマブルコンピュータにおけるプログラムコード実行の場合には、コンピューティングデバイスは、プロセッサと、プロセッサによって読取り可能な記憶媒体（揮発性及び不揮発性メモリ、及び／又は記憶要素を含む）と、少なくとも１つの入力デバイスと、少なくとも１つの出力デバイスとを含むことができる。揮発性及び不揮発性メモリ、及び／又は記憶要素は、ランダムアクセスメモリ（ｒａｎｄｏｍ−ａｃｃｅｓｓ ｍｅｍｏｒｙ：ＲＡＭ）、消去可能プログラマブル読取り専用メモリ（ｅｒａｓａｂｌｅ ｐｒｏｇｒａｍｍａｂｌｅ ｒｅａｄ ｏｎｌｙ ｍｅｍｏｒｙ：ＥＰＲＯＭ）、フラッシュドライブ、光ドライブ、磁気ハードドライブ、ソリッドステートドライブ、又は電子データを記憶するための他の媒体とすることができる。ノード及びワイヤレスデバイスはまた、送受信機モジュール（すなわち、送受信機）、カウンタモジュール（すなわち、カウンタ）、プロセッシングモジュール（すなわち、プロセッサ）、及び／又はクロックモジュール（すなわち、クロック）若しくはタイマモジュール（すなわち、タイマ）を含むことができる。本明細書において説明した様々な技法を実装する、若しくは利用することができる１つ又は複数のプログラムは、アプリケーションプログラミングインターフェース（ａｐｐｌｉｃａｔｉｏｎ ｐｒｏｇｒａｍｍｉｎｇ ｉｎｔｅｒｆａｃｅ：ＡＰＩ）、及び再利用可能制御部などを使用することができる。そのようなプログラムは、コンピュータシステムと通信するように、高レベルな手続き型又はオブジェクト指向型のプログラミング言語において実装され得る。しかしながら、プログラムは、必要ならば、アセンブリ言語又は機械言語において実装され得る。いずれの場合でも、言語は、コンパイルされた言語、又は解釈された言語であってよく、ハードウェア実装形態と組み合わされてもよい。

本明細書において説明した機能ユニットの多くは、それらの実装形態の独立性をより具体的に強調するために、モジュールとしてラベル付けされていることを理解すべきである。たとえば、モジュールは、カスタム超大規模集積（ｖｅｒｙ−ｌａｒｇｅ−ｓｃａｌｅ ｉｎｔｅｇｒａｔｉｏｎ：ＶＬＳＩ）回路、若しくはゲートアレイ、ロジックチップなどの既製半導体、トランジスタ、又は他の個別構成要素を含むハードウェア回路として実装され得る。モジュールはまた、フィールドプログラマブルゲートアレイ、プログラマブルアレイロジック、又はプログラマブルロジックデバイスなどのプログラマブルハードウェアデバイスにおいて実装され得る。

モジュールはまた、様々なタイプのプロセッサによって実行されるように、ソフトウェアにおいて実装され得る。例として、実行可能なコードの識別されたモジュールは、例として、オブジェクト、手続き、若しくは機能として体系化され得るコンピュータ命令の１つ又は複数の物理的若しくは論理的ブロックを含み得る。にもかかわらず、識別されたモジュールの実行可能ファイルは、物理的に一緒に置かれている必要はなく、種々の場所に記憶された異種命令を含むことができ、この異種命令は、論理的に一緒に結び付けられると、モジュールを含み、モジュールについて明記された目的を達成する。

実際には、実行可能コードのモジュールは、単一の命令であっても、又は数多くの命令であってもよく、いくつかの異なるコードセグメントにわたって、異なるプログラムの中で、且ついくつかのメモリデバイスにまたがって分散されてもよい。同様に、動作データは、本明細書においてはモジュール内で識別及び例示され得、任意の適した形態で実装され得、任意の適したタイプのデータ構造内で体系化され得る。動作データは、単一のデータセットとして収集されても、又は種々の記憶デバイスを介することを含む、種々の場所を介して分散されてもよく、単にシステム又はネットワーク上の電子信号として少なくとも部分的に存在してもよい。モジュールは、所望の機能を行うように動作可能なエージェントを含んだ、受動型又は能動型とすることができる。

本明細書全体を通じて、「例（ａｎ ｅｘａｍｐｌｅ）」又は「例示的な（ｅｘｅｍｐｌａｒｙ）」を参照することは、例と関連して説明した特定の特徴、構造、又は特性が、本発明の少なくとも１つの実施形態の中に含まれていることを意味する。したがって、本明細書全体を通じて様々な所に、句「例において（ｉｎ ａｎ ｅｘａｍｐｌｅ）」又は語「例示的な（ｅｘｅｍｐｌａｒｙ）」が登場しても、必ずしもすべて同じ実施形態を示しているとは限らない。

本明細書に使用されるとき、複数の項目、構造的要素、組成要素、及び／又は材料は、便宜上、共通のリストの中に提示され得る。しかしながら、これらのリストは、リストの各メンバが、別個で独自のメンバとして個々に識別されるかのように解釈すべきである。したがって、そのようなリストの個々のメンバは、共通のグループにおけるそれらの提示にのみ基づいて、その反対を示すことなしに、同じリストの任意の他のメンバの事実上の均等物と見なされるべきものはまったくない。加えて、本発明の様々な実施形態及び例は、その様々な構成要素の代替形態とともに本明細書においては示され得る。そのような実施形態、例、及び代替形態は、互いの事実上の均等物と解釈されるべきではなく、本発明の別個で自律的な表現と解釈されるべきであることが理解される。

さらには、説明した特徴、構造、又は特性は、１つ又は複数の実施形態における任意の適した形で組合せられてもよい。以下の説明においては、本発明の実施形態の完全な理解を提供するために、レイアウト、距離の例、ネットワーク例などの多数の具体的な詳細が提供される。しかしながら、当業者は、本発明が、具体的な詳細のうちの１つ又は複数がなくても、或いは他の方法、構成要素、レイアウトなどを用いて実践可能であることを認識するであろう。他の例においては、よく知られている構造、材料、又は動作は、本発明の態様を曖昧にしないようにするために、詳細に示されず、又は説明されていない。

前述の例は、１つ又は複数の特定の適用例における本発明の原理を示しているが、実装形態の形態、使用法、及び詳細における多数の修正形態が発明的能力を働かせることなく、並びに本発明の原理及び概念から逸脱することなく行われ得ることは、当業者には明らかになろう。したがって、本発明は、特許請求の範囲によって後述されている場合を除き、限定されることを意図していない。

Claims (11)

1. ハイパーテキスト転送プロトコル（ＨＴＴＰ）適応型ストリーミングを提供するように動作可能なメディアサーバであって、コンピュータ回路を有し、前記コンピュータ回路は、
   複数のクライアントに、前記メディアサーバが、指定された時刻にオフラインになることを示すサーバ利用可能性伝達を送ることと、
   前記複数のクライアントに、前記メディアサーバのアップロード速度の変更を示すアップロード速度伝達を送ることと、
   前記複数のクライアントに、新規サーバが利用可能であるときを示す新規サーバ伝達を送ることであって、前記新規サーバが、前記メディアサーバにおけるメディアプレゼンテーション記述（ＭＰＤ）ファイルと共通する少なくとも１つの表現を有する、新規サーバ伝達を送ることと、
   前記メディアサーバから前記複数のクライアントに、少なくとも１つの変更が前記メディアサーバにおけるＭＰＤファイルに行われたときを示すＭＰＤ変更伝達を送ることと
   を行って、前記メディアサーバが前記ＨＴＴＰ適応型ストリーミングを効率的に配信することを可能にするように構成されている、メディアサーバであって、
   利用可能表現コード（ＡＲＣ）を前記メディアサーバにおいて利用可能である前記表現と関連付けるようにさらに構成されたコンピュータ回路を有し、前記ＡＲＣは、各ビットが前記メディアサーバにおいて利用可能である表現に対応するバイナリ文字列を含む、メディアサーバ。
2. クライアントに対する前記ＡＲＣの中の少なくとも１ビット値をＨＴＴＰ Ｐｏｓｔ要求を介して前記クライアントに送るようにさらに構成されたコンピュータ回路を有する、請求項１に記載のメディアサーバ。
3. 前記ＡＲＣをセグメントパケットにアペンドして、クライアントに送るようにさらに構成されたコンピュータ回路を有する、請求項１に記載のメディアサーバ。
4. 前記ＡＲＣをセグメントパケットにヘッダとしてアペンドして、クライアントに送るようにさらに構成されたコンピュータ回路を有する、請求項１に記載のメディアサーバ。
5. 前記ＡＲＣをメディアプレゼンテーション記述（ＭＰＤ）メタファイルの中に属性として含むようにさらに構成されたコンピュータ回路を有する、請求項１に記載のメディアサーバ。
6. 変更が前記ＡＲＣに行われるときはいつでも、前記複数のクライアントに、ＡＲＣ変更伝達を自動的に送るようにさらに構成されたコンピュータ回路を有する、請求項１に記載のメディアサーバ。
7. 前記ＡＲＣの中のビット値１が、前記ビットに対応する前記表現が利用可能であることを表す、請求項１に記載のメディアサーバ。
8. セグメント利用可能性コード（ＳＡＣ）をメディアプレゼンテーション記述（ＭＰＤ）メタファイルと関連付けるようにさらに構成されたコンピュータ回路を有し、前記ＳＡＣは、各ビットが、前記ＭＰＤメタファイルと関連付けられた表現におけるセグメントの利用可能性に対応するバイナリ文字列を含む、請求項１に記載のメディアサーバ。
9. 前記ＳＡＣの中のビット値１が、前記ビットに対応する前記セグメントが利用可能であることを表す、請求項８に記載のメディアサーバ。
10. 複数のクライアントに、ピアツーピア（Ｐ２Ｐ）キャッシング及びストリーミングが利用可能であることを示すＰ２Ｐキャッシング利用可能性伝達を送るようにさらに構成されたコンピュータ回路を有する、請求項１に記載のメディアサーバ。
11. 複数のクライアントに、ピアリングデバイス間のキャッシング及びストリーミングのスケジュールを管理することを担うＰ２Ｐサーバの識別情報を示すＰ２Ｐサーバ識別情報伝達を送るようにさらに構成されたコンピュータ回路を有する、請求項１０に記載のメディアサーバ。

Images