JP6527957B2 - ｅＭＢＭＳを介するＨＴＴＰライブストリーミングのための技法 - Google Patents

Description

関連出願
本出願は、その内容全体が参照により本明細書に組み込まれている、2015年4月3日に出願した米国仮出願第62/142,975号の利益を主張するものである。

本開示は、一般に通信システムに関し、より詳細には、発展型マルチメディアブロードキャストマルチキャストサービス(eMBMS)を介するハイパーテキスト転送プロトコル(HTTP)ライブストリーミング(HLS)のための技法に関する。

ワイヤレス通信システムは、電話、ビデオ、データ、メッセージング、およびブロードキャストなど、様々な電気通信サービスを提供するために広く展開されている。通常のワイヤレス通信システムは、利用可能なシステムリソース(たとえば、帯域幅、送信電力)を共有することによって複数のユーザとの通信をサポートすることが可能な多元接続技術を利用することができる。そのような多元接続技術の例としては、符号分割多元接続(CDMA)システム、時分割多元接続(TDMA)システム、周波数分割多元接続(FDMA)システム、直交周波数分割多元接続(OFDMA)システム、シングルキャリア周波数分割多元接続(SC-FDMA)システム、および時分割同期符号分割多元接続(TD-SCDMA)システムがある。

これらの多元接続技術は、様々なワイヤレスデバイスが自治体、国家、地域、さらには地球規模で通信することを可能にする共通プロトコルを提供するために、様々な電気通信規格において採用されている。例示的な電気通信規格は、ロングタームエボリューション(LTE)である。LTEは、第3世代パートナーシッププロジェクト(3GPP)によって公表されたUniversal Mobile Telecommunications System(UMTS)モバイル規格に対する拡張のセットである。LTEは、スペクトル効率を改善することによってモバイルブロードバンドインターネットアクセスをより良くサポートすること、コストを下げること、サービスを改善すること、新しいスペクトルを利用すること、ならびに、ダウンリンク(DL)上のOFDMA、アップリンク(UL)上のSC-FDMA、および多入力多出力(MIMO)アンテナ技術を使用して他のオープン規格とより良く統合することを行うように設計されている。しかしながら、モバイルブロードバンドアクセスに対する需要が増加し続けるのに伴い、LTE技術のさらなる改善が必要である。好ましくは、これらの改善は、他の多元接続技術、およびこれらの技術を利用する電気通信規格に適用可能であるべきである。

本開示の一態様では、方法、ユーザ機器、コンピュータプログラム製品、および装置が提供される。

いくつかの態様では、方法は、ユーザ機器(UE)によって、メディアコンテンツにアクセスするための複数のユニフォームリソース識別子(URI)を生成するためのテンプレートを識別するテンプレート情報を受信するステップを含むことができる。この方法は、UEによって、テンプレートに基づいて、メディアコンテンツの1つまたは複数の部分にアクセスするための複数のURIのうちの1つまたは複数のURIを生成するステップを含むことができる。この方法は、UEによって、1つまたは複数のURIをプレイリストファイル内に記憶するステップを含むことができる。

いくつかの態様では、ユーザ機器は、メディアコンテンツにアクセスするための複数のURIを生成するためのテンプレートを識別するテンプレート情報を受信するための手段を含むことができる。このユーザ機器は、テンプレートに基づいて、メディアコンテンツの1つまたは複数の部分にアクセスするための複数のURIのうちの1つまたは複数のURIを生成するための手段を含むことができる。このユーザ機器は、1つまたは複数のURIをプレイリストファイル内に記憶するための手段を含むことができる。このユーザ機器は、ユーザ機器のハイパーテキスト転送プロトコル(HTTP)ライブストリーミング(HLS)クライアントにプレイリストファイルを提供するための手段を含むことができる。HLSクライアントは、1つまたは複数のURIを変更せずにメディアコンテンツの1つまたは複数の部分にアクセスするのにプレイリストファイルを使用することができる。

いくつかの態様では、ユーザ機器は、メモリと、メモリに結合され、メディアコンテンツにアクセスするための複数のURIを生成するためのテンプレートを識別するテンプレート情報を受信するように構成された少なくとも1つのプロセッサとを含むことができる。メモリに結合された少なくとも1つのプロセッサは、テンプレートに基づいて、メディアコンテンツの1つまたは複数の部分にアクセスするための複数のURIのうちの1つまたは複数のURIを生成するように構成され得る。メモリに結合された少なくとも1つのプロセッサは、1つまたは複数のURIをプレイリストファイル内に記憶するように構成され得る。

いくつかの態様では、コンピュータプログラム製品は、ワイヤレス通信のためのコンピュータ実行可能コードを記憶した非一時的コンピュータ可読媒体を含むことができる。コードは、ユーザ機器によって、メディアコンテンツにアクセスするための複数のURIを生成するためのテンプレートを識別するテンプレート情報を受信するためのコードを含むことができる。コードは、ユーザ機器によって、テンプレートに基づいて、メディアコンテンツの1つまたは複数の部分にアクセスするための複数のURIのうちの1つまたは複数のURIを生成するためのコードを含むことができる。コードは、ユーザ機器によって、1つまたは複数のURIをプレイリストファイル内に記憶するためのコードを含むことができる。

ネットワークアーキテクチャの一例を示す図である。 アクセスネットワークの一例を示す図である。 LTEにおけるダウンリンク(DL)フレーム構造の一例を示す図である。 LTEにおけるアップリンク(UL)フレーム構造の一例を示す図である。 ユーザプレーンおよび制御プレーンの無線プロトコルアーキテクチャの一例を示す図である。 アクセスネットワーク中の発展型ノードBおよびユーザ機器の一例を示す図である。 マルチキャストブロードキャスト単一周波数ネットワークにおける発展型マルチメディアブロードキャストマルチキャストサービスチャネル構成の一例を示す図である。 マルチキャストチャネルスケジューリング情報(MSI)メディアアクセス制御(MAC)の制御要素のフォーマットを示す図である。 eMBMSを介するHLSを可能にするように構成された例のシステムを示す図である。 eMBMSを介するHLSを可能にするように構成された別の例のシステムを示す図である。 eMBMSを介するHLSを可能にするように構成された追加の例のシステムを示す図である。 eMBMSを介するHLSを可能にするように構成された追加の例のシステムを示す図である。 ワイヤレス通信の方法のフローチャートである。 ワイヤレス通信の方法のフローチャートである。 ワイヤレス通信の方法のフローチャートである。 ワイヤレス通信の方法のフローチャートである。 ワイヤレス通信の方法のフローチャートである。 例示的な装置における異なるモジュール/手段/構成要素間のデータフローを示す概念的なデータフロー図である。 処理システムを利用する装置のためのハードウェア実装形態の一例を示す図である。

添付の図面に関して以下に説明される詳細な説明は、種々の構成を説明することを意図しており、本明細書において説明される概念を実践することができる構成を表すことは意図していない。詳細な説明は、様々な概念の完全な理解を与えるために具体的な詳細を含む。しかしながら、これらの概念がこれらの具体的な詳細なしに実践され得ることは当業者に明らかであろう。場合によっては、そのような概念を曖昧にすることを回避するために、よく知られている構造および構成要素がブロック図の形態で示されている。

次に、電気通信システムのいくつかの態様が、様々な装置および方法を参照して提示される。これらの装置および方法は、以下の詳細な説明に記載され、様々なブロック、モジュール、コンポーネント、回路、ステップ、プロセス、アルゴリズムなど(「要素」と総称される)によって添付の図面に示される。これらの要素は、電子ハードウェア、コンピュータソフトウェア、またはそれらの任意の組合せを使用して実装されてよい。そのような要素をハードウェアとして実装するか、またはソフトウェアとして実装するかは、特定の適用例および全体的なシステムに課された設計制約に依存する。

例として、要素、もしくは要素の任意の部分、または要素の任意の組合せは、1つまたは複数のプロセッサを含む「処理システム」で実装され得る。プロセッサの例としては、マイクロプロセッサ、マイクロコントローラ、デジタル信号プロセッサ(DSP)、フィールドプログラマブルゲートアレイ(FPGA)、プログラマブル論理デバイス(PLD)、ステートマシン、ゲート論理、個別ハードウェア回路、および本開示全体にわたって説明される様々な機能を実施するように構成された他の適切なハードウェアがある。処理システム内の1つまたは複数のプロセッサは、ソフトウェアを実行し得る。ソフトウェアは、ソフトウェア、ファームウェア、ミドルウェア、マイクロコード、ハードウェア記述言語と呼ばれるか、または他の名称で呼ばれるかどうかにかかわらず、命令、命令セット、コード、コードセグメント、プログラムコード、プログラム、サブプログラム、ソフトウェアモジュール、アプリケーション、ソフトウェアアプリケーション、ソフトウェアパッケージ、ルーチン、サブルーチン、オブジェクト、実行可能ファイル、実行スレッド、プロシージャ、関数などを意味するように広く解釈されるべきである。

したがって、1つまたは複数の例示的な実施形態では、説明する機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せで実装されてよい。ソフトウェアに実装される場合、機能は、コンピュータ可読媒体上の1つまたは複数の命令またはコードとして、記憶または符号化することができる。コンピュータ可読媒体は、コンピュータ記憶媒体を含む。記憶媒体は、コンピュータによってアクセスされ得る任意の利用可能な媒体であり得る。限定ではなく例として、そのようなコンピュータ可読メディアは、ランダムアクセスメモリ(RAM)、読取専用メモリ(ROM)、電気消去可能プログラマブルROM(EEPROM)、コンパクトディスクROM(CD-ROM)もしくは他の光ディスク記憶装置、磁気ディスク記憶装置もしくは他の磁気記憶デバイス、前述のタイプのコンピュータ可読メディアの組合せ、またはコンピュータによってアクセス可能な命令もしくはデータ構造の形態でコンピュータ実行可能コードを記憶するために使用可能である任意の他のメディアを含むことができる。

図1は、LTEネットワークアーキテクチャ100を示す図である。LTEネットワークアーキテクチャ100は、発展型パケットシステム(EPS)100と呼ばれ得る。EPS100は、1つまたは複数のユーザ機器(UE)102と、発展型UMTS地上波無線アクセスネットワーク(E-UTRAN:UMTS Terrestrial Radio Access Network)104と、発展型パケットコア(EPC:Evolved Packet Core)110と、事業者のインターネットプロトコル(IP)サービス122とを含んでもよい。EPSは、他のアクセスネットワークと相互接続することができるが、簡単のために、それらのエンティティ/インターフェースは図示されていない。図示のように、EPSはパケット交換サービスを提供するが、当業者が容易に諒解するように、本開示全体にわたって提示される様々な概念は、回線交換サービスを提供するネットワークに拡張され得る。

E-UTRANは、発展型ノードB(eNB)106と他のeNB108とを含み、マルチキャスト協調エンティティ(MCE)128を含んでもよい。eNB106は、UE102に対してユーザプレーンプロトコル終端および制御プレーンプロトコル終端を提供する。eNB106は、バックホール(たとえばX2インターフェース)を介して他のeNB108に接続されてよい。MCE128は、発展型マルチメディアブロードキャストマルチキャストサービス(MBMS)(eMBMS)に関する時間/周波数無線リソースを割り振り、eMBMSに関する無線構成(たとえば、変調およびコーディング方式(MCS))を判定する。MCE128は、別個のエンティティであっても、あるいはeNB106の一部であってもよい。eNB106は、基地局、ノードB、アクセスポイント、トランシーバ基地局、無線基地局、無線トランシーバ、トランシーバ機能、基本サービスセット(BSS)、拡張サービスセット(ESS)、または他の何らかの適切な用語で呼ばれる場合もある。eNB106は、UE102にEPC110へのアクセスポイントを提供する。UE102の例には、携帯電話、スマートフォン、セッション開始プロトコル(SIP)電話、ラップトップ、携帯情報端末(PDA)、衛星無線、全地球測位システム、マルチメディアデバイス、ビデオデバイス、デジタルオーディオプレーヤ(たとえば、MP3プレーヤ)、カメラ、ゲームコンソール、タブレット、または同様に機能する任意の他のデバイスが含まれる。UE102はまた、当業者により、移動局、加入者局、モバイルユニット、加入者ユニット、ワイヤレスユニット、リモートユニット、モバイルデバイス、ワイヤレスデバイス、ワイヤレス通信デバイス、リモートデバイス、モバイル加入者局、アクセス端末、モバイル端末、ワイヤレス端末、リモート端末、ハンドセット、ユーザエージェント、モバイルクライアント、クライアント、または他の何らかの適切な用語で呼ばれる場合もある。

eNB106はEPC110に接続される。EPC110は、モビリティ管理エンティティ(MME)112と、ホーム加入者サーバ(HSS)120と、他のMME114、サービングゲートウェイ116と、マルチメディアブロードキャストマルチキャストサービス(MBMS)ゲートウェイ124と、ブロードキャストマルチキャストサービスセンター(BM-SC)126と、パケットデータネットワーク(PDN)ゲートウェイ118とを含んでもよい。MME112は、UE102とEPC110との間のシグナリングを処理する制御ノードである。一般に、MME112は、ベアラおよび接続の管理を提供する。すべてのユーザIPパケットは、サービングゲートウェイ116を通じて転送され、サービングゲートウェイ116自体は、PDNゲートウェイ118に接続される。PDNゲートウェイ118は、UEのIPアドレスの割当てだけでなく、他の機能を提供する。PDNゲートウェイ118およびBM-SC126はIPサービス122に接続されている。IPサービス122は、インターネット、イントラネット、IPマルチメディアサブシステム(IMS)、PSストリーミングサービス(PSS)、および/または他のIPサービスを含んでもよい。BM-SC126は、MBMSユーザサービスのプロビジョニングおよび送達のための機能を実現することができる。BM-SC126は、コンテンツプロバイダのMBMS送信用のエントリポイントとして働くことができ、PLMN内のMBMSベアラサービスを認証し開始するために使用することができ、MBMS送信をスケジュールし送達するために使用することができる。MBMSゲートウェイ124は、特定のサービスをブロードキャストしているマルチキャストブロードキャスト単一周波数ネットワーク(MBSFN)領域に属するeNB(たとえば、106、108)にMBMSトラフィックを分散するために使用することができ、セッション管理(開始/停止)、およびeMBMS関連の課金情報の収集を担当することができる。

図2は、LTEネットワークアーキテクチャにおけるアクセスネットワーク200の一例を示す図である。この例では、アクセスネットワーク200は、いくつかのセルラー領域(セル)202に分割されている。1つまたは複数の低電力クラスeNB208は、セル202のうちの1つまたは複数と重複するセルラー領域210を有してもよい。低電力クラスeNB208は、フェムトセル(たとえば、ホームeNB(HeNB))、ピコセル、マイクロセル、またはリモート無線ヘッド(RRH)であり得る。マクロeNB204は、各々がそれぞれのセル202に割り当てられ、セル202内のすべてのUE206にEPC110へのアクセスポイントを提供するように構成される。アクセスネットワーク200のこの例では集中型コントローラはないが、代替構成では集中型コントローラが使用される場合がある。eNB204は、無線ベアラ制御、アドミッション制御、モビリティ制御、スケジューリング、セキュリティ、およびサービングゲートウェイ116への接続を含む、すべての無線関連機能を担う。eNBは、(セクタとも呼ばれる)1つまたは複数(たとえば、3つ)のセルをサポートする場合がある。「セル」という用語は、特定のカバレージエリアにサービスするeNBおよび/またはeNBサブシステムの最小カバレージエリアを指すことができる。さらに、「eNB」、「基地局」、および「セル」という用語は、本明細書では互換的に使用される場合がある。

アクセスネットワーク200によって利用される変調および多元接続方式は、展開されている特定の電気通信規格に応じて異なる場合がある。LTEの適用例では、DL上ではOFDMが使用され、UL上ではSC-FDMAが使用されて、周波数分割複信(FDD)と時分割複信(TDD)の両方をサポートする。当業者が以下の詳細な説明から容易に諒解するように、本明細書で提示する様々な概念は、LTEの適用例に好適である。しかしながら、これらの概念は、他の変調技法および多元接続技法を利用する他の電気通信規格に容易に拡張され得る。例として、これらの概念は、エボリューションデータオプティマイズド(EV-DO)またはウルトラモバイルブロードバンド(UMB)に拡張され得る。EV-DOおよびUMBは、CDMA2000規格ファミリーの一部として第3世代パートナーシッププロジェクト2(3GPP2)によって公表されたエアインターフェース規格であり、CDMAを利用して移動局にブロードバンドインターネットアクセスを提供する。これらの概念はまた、広帯域CDMA(W-CDMA)およびTD-SCDMAなどのCDMAの他の変形形態を利用するユニバーサル地上波無線アクセス(UTRA)、TDMAを利用するモバイル通信用グローバルシステム(GSM(登録商標))、ならびにOFDMAを利用する発展型UTRA(E-UTRA)、IEEE802.11(Wi-Fi)、IEEE802.16(WiMAX)、IEEE802.20、およびFlash-OFDMに拡張され得る。UTRA、E-UTRA、UMTS、LTE、およびGSM(登録商標)は、3GPP団体からの文書に記載されている。CDMA2000およびUMBは、3GPP2団体からの文書に記載されている。利用される実際のワイヤレス通信規格および多元接続技術は、特定の適用例およびシステムに課された全体的な設計制約に依存する。

eNB204は、MIMO技術をサポートする複数のアンテナを有し得る。MIMO技術の使用により、eNB204が空間領域を活用して、空間多重化、ビームフォーミング、および送信ダイバーシティをサポートすることが可能になる。同じ周波数で同時に様々なデータのストリームを伝送するために、空間多重化が使用される場合がある。データストリームは、データレートを増大させるために単一のUE206に送信されてよく、または全体的なシステム容量を増大させるために複数のUE206に送信されてもよい。これは、各データストリームを空間的にプリコーディングし(すなわち、振幅および位相のスケーリングを適用し)、次いで、空間的にプリコーディングされた各ストリームをDL上で複数の送信アンテナを通じて送信することによって実現される。空間的にプリコーディングされたデータストリームは、異なる空間シグネチャとともにUE206に到達し、これにより、UE206の各々は、そのUE206に向けられた1つまたは複数のデータストリームを復元することが可能になる。UL上では、各UE206は、空間的にプリコーディングされたデータストリームを送信し、これにより、eNB204は、空間的にプリコーディングされた各データストリームのソースを特定することが可能になる。

空間多重化は、一般に、チャネル条件が良いときに使用される。チャネル条件があまり良好でないとき、送信エネルギーを1つまたは複数の方向に集中させるために、ビームフォーミングが使用され得る。これは、複数のアンテナを通じた伝送のためにデータを空間的にプリコーディングすることによって実現される場合がある。セルのエッジにおいて良好なカバレージを実現するために、単一ストリームのビームフォーミング送信が、送信ダイバーシティと組み合わせて使用され得る。

以下の詳細な説明では、アクセスネットワークの様々な態様が、DL上でOFDMをサポートするMIMOシステムを参照して説明される。OFDMは、OFDMシンボル内でいくつかのサブキャリアにわたってデータを変調するスペクトル拡散技法である。サブキャリアは、正確な周波数で離間される。離間は、受信機がサブキャリアからのデータを復元することを可能にする「直交性」をもたらす。時間領域では、OFDMシンボル間干渉をなくすために、ガードインターバル(たとえば、サイクリックプレフィックス)が各OFDMシンボルに追加され得る。ULは、SC-FDMAをDFT拡散OFDM信号の形態で使用して、高いピーク対平均電力比(PAPR)を補償することができる。

図3は、LTEにおけるDLフレーム構造の一例を示す図300である。フレーム(10ミリ秒)は、等しいサイズの10個のサブフレームに分割され得る。各サブフレームは、連続する2つの時間スロットを含み得る。リソースグリッドは、2つの時間スロットを表すために使用され得、各時間スロットはリソースブロックを含む。リソースグリッドは、複数のリソース要素に分割される。LTEにおいて、ノーマルサイクリックプレフィックスの場合、リソースブロックは、合計で84個のリソース要素に関して、周波数領域では12個の連続的なサブキャリアを含み、時間領域では7個の連続的なOFDMシンボルを含む。拡張サイクリックプレフィックスの場合、リソースブロックは、合計で72個のリソース要素に関して、周波数領域では12個の連続的なサブキャリアを含み、時間領域では6個の連続的なOFDMシンボルを含む。R302、R304として示されたリソース要素のうちのいくつかは、DL基準信号(DL-RS)を含む。DL-RSは、(共通RSと呼ばれることもある)セル固有RS(CRS)302、およびUE固有RS(UE-RS)304を含む。UE-RS304は、対応する物理DL共有チャネル(PDSCH)がマッピングされるリソースブロック上で送信される。各リソース要素によって搬送されるビット数は、変調方式に依存する。したがって、UEが受信するリソースブロックが多いほど、かつ変調方式が高いほど、UE向けのデータレートは高くなる。

図4は、LTEにおけるULフレーム構造の一例を示す図400である。ULのために利用可能なリソースブロックは、データセクションおよび制御セクションに区分化され得る。制御セクションは、システム帯域幅の2つの縁部に形成され得、構成可能なサイズを有し得る。制御セクション内のリソースブロックは、制御情報の送信のためにUEに割り当てられ得る。データセクションは、制御セクションに含まれないすべてのリソースブロックを含み得る。ULフレーム構造により、データセクションは連続的なサブキャリアを含むことになり、これにより、単一のUEが、データセクション内の連続するサブキャリアのすべてを割り当てられることが可能になり得る。

UEは、制御情報をeNBに送信するために、制御セクション内のリソースブロック410a、410bを割り当てられ得る。UEはまた、データをeNBに送信するために、データセクション内のリソースブロック420a、420bを割り当てられ得る。UEは、制御セクションの中で割り当てられたリソースブロック上の物理UL制御チャネル(PUCCH)内で、制御情報を送信し得る。UEは、データセクションの中で割り当てられたリソースブロック上の物理UL共有チャネル(PUSCH)内で、データ、またはデータと制御情報の両方を送信し得る。UL送信は、サブフレームの両方のスロットにまたがることができ、周波数にわたってホップすることができる。

初期システムアクセスを実施し、物理ランダムアクセスチャネル(PRACH)430内でUL同期を実現するために、1組のリソースブロックを使用することができる。PRACH430は、ランダムシーケンスを搬送し、いかなるULデータ/シグナリングも搬送できない。各ランダムアクセスプリアンブルは、連続する6つのリソースブロックに対応する帯域幅を占有する。開始周波数は、ネットワークによって指定される。すなわち、ランダムアクセスプリアンブルの送信は、特定の時間リソースおよび周波数リソースに制限される。PRACHの場合、周波数ホッピングは存在しない。PRACHの試行は、単一のサブフレーム(1ミリ秒)内で、または少数の連続するサブフレームのシーケンス内で搬送され、UEは、フレーム(10ミリ秒)ごとに単一のPRACHの試行を行うことができる。

図5は、LTEにおけるユーザプレーンおよび制御プレーンのための無線プロトコルアーキテクチャの一例を示す図500である。UEおよびeNBのための無線プロトコルアーキテクチャは、レイヤ1、レイヤ2、およびレイヤ3という3つのレイヤで示される。レイヤ1(L1レイヤ)は最下位レイヤであり、様々な物理レイヤ信号処理機能を実装する。本明細書では、L1レイヤは物理レイヤ506と呼ばれる。レイヤ2(L2レイヤ)508は、物理レイヤ506の上にあり、物理レイヤ506を介したUEとeNBとの間のリンクを担う。

ユーザプレーンでは、L2レイヤ508は、媒体アクセス制御(MAC)サブレイヤ510、無線リンク制御(RLC)サブレイヤ512、およびパケットデータコンバージェンスプロトコル(PDCP)サブレイヤ514を含み、これらはネットワーク側のeNBで終端される。図示されていないが、UEは、L2レイヤ508の上にいくつかの上位レイヤを有する場合があり、これらは、ネットワーク側のPDNゲートウェイ118で終端されるネットワークレイヤ(たとえば、IPレイヤ)と、接続の他端(たとえば、遠端UE、サーバなど)で終端されるアプリケーションレイヤとを含む。

PDCPサブレイヤ514は、異なる無線ベアラと論理チャネルとの間で多重化を実現する。PDCPサブレイヤ514はまた、無線送信のオーバーヘッドを低減するための上位レイヤのデータパケット用のヘッダ圧縮、データパケットを暗号化することによるセキュリティ、およびeNB間のUE用のハンドオーバのサポートを実現する。RLCサブレイヤ512は、上位レイヤのデータパケットのセグメント化および再構築、失われたデータパケットの再送信、ならびに、ハイブリッド自動再送要求(HARQ)による順序の狂った受信を補償するためのデータパケットの再順序付けを行う。MACサブレイヤ510は、論理チャネルとトランスポートチャネルとの間の多重化を実現する。MACサブレイヤ510はまた、1つのセルの中の様々な無線リソース(たとえば、リソースブロック)をUEの間で割り振ることを担う。MACサブレイヤ510はまた、HARQ動作を担う。

制御プレーンでは、UEおよびeNB用の無線プロトコルアーキテクチャは、制御プレーン用のヘッダ圧縮機能がないことを除いて、物理レイヤ506およびL2レイヤ508の場合と実質的に同じである。制御プレーンはまた、レイヤ3(L3レイヤ)内に無線リソース制御(RRC)サブレイヤ516を含む。RRCサブレイヤ516は、無線リソース(たとえば、無線ベアラ)を取得すること、および、eNBとUEとの間のRRCシグナリングを使用して下位レイヤを構成することを担う。

図6は、アクセスネットワーク中でUE650と通信するeNB610のブロック図である。DLでは、コアネットワークからの上位レイヤパケットが、コントローラ/プロセッサ675に供給される。コントローラ/プロセッサ675は、L2レイヤの機能性を実装する。DLでは、コントローラ/プロセッサ675は、ヘッダ圧縮、暗号化、パケットのセグメント化および並べ替え、論理チャネルとトランスポートチャネルとの間の多重化、ならびに、様々な優先順位基準に基づくUE650への無線リソース割振りを行う。コントローラ/プロセッサ675はまた、HARQ動作、紛失したパケットの再送信、およびUE650へのシグナリングを担当する。

送信(TX)プロセッサ616は、L1レイヤ(すなわち、物理レイヤ)のための様々な信号処理機能を実装する。信号処理機能は、UE650での順方向誤り訂正(FEC)を容易にするコーディングおよびインターリービング、ならびに様々な変調方式(たとえば、2位相シフトキーイング(BPSK)、直交位相シフトキーイング(QPSK)、M位相シフトキーイング(M-PSK)、M直交振幅変調(M-QAM))に基づく信号コンスタレーションへのマッピングを含む。次いで、コーディングおよび変調されたシンボルは、並列ストリームに分割される。次いで、各ストリームは、OFDMサブキャリアにマッピングされ、時間領域および/または周波数領域で基準信号(たとえば、パイロット)と多重化され、次いで、逆高速フーリエ変換(IFFT)を使用して一緒に結合されて、時間領域のOFDMシンボルストリームを搬送する物理チャネルを生成する。OFDMストリームは、空間的にプリコーディングされて、複数の空間ストリームを生成する。チャネル推定器674からのチャネル推定値は、コーディングおよび変調方式を決定するために、ならびに空間処理のために使用され得る。チャネル推定値は、UE650によって送信された基準信号および/またはチャネル状態フィードバックから導出され得る。次いで、各空間ストリームは、別個の送信機618TXを介して異なるアンテナ620に提供されてよい。各送信機618TXは、送信用のそれぞれの空間ストリームでRFキャリアを変調し得る。

UE650において、各受信機654RXは、それぞれのアンテナ652を介して信号を受信する。各受信機654RXは、RFキャリア上に変調された情報を復元し、その情報を受信(RX)プロセッサ656に供給する。RXプロセッサ656は、L1レイヤの様々な信号処理機能を実装する。RXプロセッサ656は、情報に対して空間処理を実施して、UE650に宛てられた任意の空間ストリームを復元し得る。複数の空間ストリームがUE650に宛てられた場合、それらは、RXプロセッサ656によって単一のOFDMシンボルストリームに合成される場合がある。次いで、RXプロセッサ656は、高速フーリエ変換(FFT)を使用して、OFDMシンボルストリームを時間領域から周波数領域に変換する。周波数領域信号は、OFDM信号のサブキャリアごとに別個のOFDMシンボルストリームを含む。各サブキャリア上のシンボル、および基準信号は、eNB610によって伝送された最も可能性の高い信号コンスタレーションポイントを決定することによって、復元および復調される。これらの軟判定は、チャネル推定器658によって計算されたチャネル推定値に基づき得る。次いで、軟判定は復号およびデインターリーブされて、物理チャネル上でeNB610によって元々送信されたデータおよび制御信号を復元する。次いで、データおよび制御信号は、コントローラ/プロセッサ659に供給される。

コントローラ/プロセッサ659はL2レイヤを実装する。コントローラ/プロセッサは、プログラムコードおよびデータを記憶するメモリ660と関連付けることができる。メモリ660は、コンピュータ可読媒体と呼ばれることがある。ULでは、コントローラ/プロセッサ659は、トランスポートチャネルと論理チャネルとの間の逆多重化、パケット再アセンブリ、暗号化解除、ヘッダ圧縮解除、制御信号処理を実現して、コアネットワークからの上位レイヤパケットを復元する。次いで、上位レイヤパケットはデータシンク662に与えられ、データシンク662はL2レイヤの上のすべてのプロトコルレイヤを表す。様々な制御信号も、L3処理のためにデータシンク662に供給され得る。コントローラ/プロセッサ659はまた、HARQ動作をサポートするために、確認応答(ACK)および/または否定応答(NACK)のプロトコルを使用する誤り検出を担う。

ULでは、コントローラ/プロセッサ659に上位レイヤパケットを与えるために、データソース667が使用される。データソース667は、L2レイヤの上のすべてのプロトコルレイヤを代表する。eNB610によるDL送信に関して説明した機能と同様に、コントローラ/プロセッサ659は、ヘッダ圧縮、暗号化、パケットのセグメント化および並べ替え、ならびに、eNB610による無線リソース割振りに基づく論理チャネルとトランスポートチャネルとの間の多重化を実現することによって、ユーザプレーンおよび制御プレーンのためのL2レイヤを実装する。コントローラ/プロセッサ659はまた、HARQ動作、紛失したパケットの再送信、およびeNB610へのシグナリングを担う。

eNB610によって送信された基準信号またはフィードバックからチャネル推定器658によって導出されたチャネル推定値は、適切なコーディングおよび変調方式を選択し、空間処理を容易にするために、TXプロセッサ668によって使用され得る。TXプロセッサ668によって生成された空間ストリームは、別個の送信機654TXを介して異なるアンテナ652に供給され得る。各送信機654TXは、送信用のそれぞれの空間ストリームを用いてRFキャリアを変調し得る。

UL送信は、UE650での受信機機能に関連して説明された方式と同様の方式で、eNB610で処理される。各受信機618RXは、それぞれのアンテナ620を通じて信号を受信する。各受信機618RXは、RFキャリア上に変調された情報を復元し、その情報をRXプロセッサ670に供給する。RXプロセッサ670は、L1レイヤを実装し得る。

コントローラ/プロセッサ675はL2レイヤを実装する。コントローラ/プロセッサ675は、プログラムコードおよびデータを記憶するメモリ676と関連付けることができる。メモリ676は、コンピュータ可読媒体と呼ばれることがある。ULでは、コントローラ/プロセッサ675は、トランスポートチャネルと論理チャネルとの間の逆多重化、パケット再アセンブリ、暗号化解除、ヘッダ圧縮解除、制御信号処理を実現して、UE650からの上位レイヤパケットを復元する。コントローラ/プロセッサ675からの上位レイヤパケットは、コアネットワークに提供されてよい。コントローラ/プロセッサ675はまた、HARQ動作をサポートするために、ACKおよび/またはNACKプロトコルを使用する誤り検出を担う。

図7Aは、MBSFNにおける発展型MBMS(eMBMS)チャネル構成の一例を示す図750である。セル752'内のeNB752は第1のMBSFNエリアを形成することができ、セル754'内のeNB754は第2のMBSFNエリアを形成することができる。eNB752、754は、各々他のMBSFNエリア、たとえば、合計8つまでのMBSFNエリアと関連付けることができる。MBSFNエリア内のセルは、予約セルに指定することができる。予約セルは、マルチキャスト/ブロードキャストのコンテンツを供給しないが、セル752'、754'に時間同期され、MBSFNエリアへの干渉を制限するために、MBSFNリソース上で規制された電力を有することができる。MBSFNエリア内の各eNBは、同じeMBMSの制御情報およびデータを同期して送信する。各エリアは、ブロードキャストサービス、マルチキャストサービス、およびユニキャストサービスをサポートすることができる。ユニキャストサービスは、特定のユーザを対象とするサービス、たとえば、音声通話である。マルチキャストサービスは、あるグループのユーザによって受信され得るサービス、たとえば、サブスクリプションビデオサービスである。ブロードキャストサービスは、すべてのユーザによって受信され得るサービス、たとえば、ニュース放送である。図7Aを参照すると、第1のMBSFNエリアは、特定のニュース放送をUE770に供給することなどによって、第1のeMBMSブロードキャストサービスをサポートすることができる。第2のMBSFNエリアは、異なるニュース放送をUE760に供給することなどによって、第2のeMBMSブロードキャストサービスをサポートすることができる。各MBSFNエリアは、1つまたは複数の物理マルチキャストチャネル(PMCH)(たとえば、15個のPMCH)をサポートする。各PMCHは、マルチキャストチャネル(MCH)に対応する。各MCHは、複数(たとえば、29個)のマルチキャスト論理チャネルを多重化することができる。各MBSFNエリアは、1つのマルチキャスト制御チャネル(MCCH)を有し得る。したがって、1つのMCHは、1つのMCCHおよび複数のマルチキャストトラフィックチャネル(MTCH)を多重化することができ、残りのMCHは、複数のMTCHを多重化することができる。

UEは、eMBMSサービスアクセスおよび対応するアクセス層構成の利用可能性を発見するために、LTEセルにキャンプオンすることができる。最初に、UEは、システム情報ブロック(SIB)13(SIB13)を取得することができる。続いて、UEは、SIB13に基づいて、MCCH上でMBSFNエリア構成メッセージを取得することができる。続いて、UEは、MBSFNエリア構成メッセージに基づいて、MCHスケジューリング情報(MSI)MAC制御要素を取得することができる。SIB13は、(1)セルによってサポートされる各MBSFNエリアのMBSFNエリア識別子、(2)MCCH反復期間(たとえば、32、64、…、256フレーム)などMCCHを取得するための情報、MCCHオフセット(たとえば、0、1、…、10フレーム)、MCCH変更期間(たとえば、512、1024フレーム)、シグナリング変調および符号化方式(MCS)、反復期間およびオフセットによって示されるように、無線フレームのどのサブフレームがMCCHを送信することができるかを示すサブフレーム割振り情報、および(3)MCCH変更通知構成を含むことができる。MBSFNエリアごとに1つのMBSFNエリア構成メッセージがある。MBSFNエリア構成メッセージは、(1)一時的モバイルグループ識別情報(TMGI)およびPMCH内の論理チャネル識別子によって識別される各MTCHのオプションのセッション識別子、(2)MBSFNエリアの各PMCHおよびエリアにおけるすべてのPMCHに割り振られたリソースの割振り期間(たとえば、4、8、…、256フレーム)を送信するための割り振られたリソース(すなわち、無線フレームおよびサブフレーム)、および(3)MSI MAC制御要素が送信されるMCHスケジューリング期間(MSP)(たとえば、8、16、32、…または1024無線フレーム)を示すことができる。

図7Bは、MSI MAC制御要素のフォーマットを示す図790である。MSI MAC制御要素は、各MSPに1度送られ得る。MSI MAC制御要素は、PMCHの各スケジューリング期間の第1のサブフレームにおいて送られ得る。MSI MAC制御要素は、PMCH内の各MTCHの停止フレームおよびサブフレームを示し得る。MBSFNエリア当たりPMCH当たり1つのMSIがあり得る。

HLSにおいて、UEは、HTTPを介してメディアセグメントを取り出すことと、正しい順序でメディアセグメントを再生することとによってメディア再生を達成することができる。UEは、メディアセグメントがアクセスされ得る位置とメディアセグメントが再生されるべき順序とを識別するために、メディアセグメントのURIを含むプレイリストファイルを使用することができる。ライブコンテンツがブロードキャストされまたはマルチキャストされつつある(たとえば、eMBMSを介して)ときに、メディアセグメントが、プレイリストファイルサイズを小さく保つためまたは類似物のために除去される(たとえば、すべてのUEがライブコンテンツの同一のファイルまたは同一の少数のファイルを再生している可能性が高いので、古いファイルが、プレイリストから除去され得る)ので、プレイリストファイルは、メディアセグメントが生成されるときに頻繁に更新され得る。プレイリストファイルが更新されるときに、更新は、eMBMSを使用してUEにブロードキャストされまたはマルチキャストされ得る。しかしながら、UEが、プレイリストファイルに対する更新をブロードキャストしまたはマルチキャストしつつあるeNBとの通信を失う場合に、UEは、プレイリストファイルに対する更新を受信しない可能性がある。この場合に、UEは、プレイリストファイルがメディアセグメントのURIを含むために更新されなかったので、取り出されるべきメディアセグメントを識別できない可能性がある。これが発生するときには、メディアコンテンツの再生が、失速する可能性がある。本明細書で説明される技法は、UEがメディアセグメントのURIを生成するのに使用するためのテンプレートを提供することによって、メディアコンテンツの再生の失速を防ぐ上でUEを支援する。UEは、UEがプレイリストファイルに対する更新を介してURIを受信できない(たとえば、UEがeNBとの通信を失ったので)場合であっても、メディアセグメントが識別され、取り出され得るようにするために、URIを生成することができる。さらなる詳細は、本明細書で説明される。

図8は、eMBMSを介するHLSを可能にするように構成された例のシステム800を示す図である。図8に示されているように、例のシステム800は、BM-SC810(たとえば、図1のBM-SC126などを含むことができる)、eNB820(たとえば、図1のeNB106、108、図2のeNB204、208、図6のeNB610、図7のeNB752、754などのうちの1つまたは複数を含むことができる)、UE830(たとえば、図1のUE102、図2のUE206、図6のUE650、図7のUE760、770などのうちの1つまたは複数を含むことができる)、およびビデオサーバ840を含むことができる。

図8に示されているように、BM-SC810は、eNB820を介して、ユーザサービス記述(USD)850をUE830に提供することができる。USD850は、メディアコンテンツ(たとえば、ストリーミングビデオ、ストリーミングオーディオなど)にアクセスするための複数のユニフォームリソース識別子(URI)を生成するためのテンプレートを識別するテンプレート情報を含むことができる。テンプレートは、「http://www.example.com/cars/video_」および「mp4.」として示された、URIごとに同一である静的部分を識別することができる。テンプレートは、「$number$」として示されたURIごとに異なる動的部分を識別することもできる。

UE830(たとえば、UE830上で実行中のミドルウェア)は、テンプレートを使用してURIを生成することができ、プレイリストファイル860内にURIを記憶することができる。いくつかの態様では、UE830上で実行中のミドルウェアは、UE830のHLSクライアントにプレイリストファイル860を供給することができ、その結果、URIが、メディアコンテンツにアクセスする(たとえば、HLSクライアントによって)のに使用され得るようになる。いくつかの態様では、HLSクライアントは、ミドルウェアからプレイリストファイル860を受信しまたは取り出すことができ、プレイリストファイル860内に記憶されたURIを使用して、メディアコンテンツにアクセスすることができる。このようにして、UE830が、メディアコンテンツにアクセスするためのURIを含むプレイリストファイル860および/またはプレイリストファイル860に対する更新を受信できない場合に、UE830は、テンプレートに基づいてURIを生成することができる。たとえば、図示されているように、UE830は、「http://www.example.com/cars/video_34.mp4」、「http://www.example.com/cars/video_35.mp4」、および「http://www.example.com/cars/video_36.mp4」として示された、連続するURIの動的部分の番号(たとえば、「$number$」)を置換することができる。図示されているように、UE830は、メディアコンテンツにアクセスする(たとえば、ビデオサーバ840から)のに、生成されたURIを使用することができる。メディアコンテンツにアクセスするのに使用されるURIを生成することによって、UE830は、URIの受信の失敗(たとえば、UE830がeNB820の範囲外にいるとき、UE830がeNB820との通信を失うときなど)に起因するメディアコンテンツの再生の中断を防ぐことができる。

上で示したように、図8に示された800は、例として提供される。他の例が可能であり、図8に関連して説明されたものとは異なる可能性がある。

図9は、eMBMSを介するHLSを可能にするように構成された別の例のシステム900を示す図である。図9に示されているように、例のシステム900は、eNB910(図1のeNB106、108、図2のeNB204、208、図6のeNB610、図7のeNB752、754、図8のeNB820などのうちの1つまたは複数を含むことができる)、UE920(たとえば、図1のUE102、図2のUE206、図6のUE650、図7のUE760、770、図8のUE830などのうちの1つまたは複数を含むことができる)、およびeNB910に関連するセル930(たとえば、図2のセル202、210、図7のセル752'、754'などのうちの1つまたは複数を含むことができる)を含むことができる。

図9に示されているように、eNB910は、ユーザサービス記述(USD)940をUE920に提供することができる。USD940は、マルチメディアブロードキャストマルチキャストサービス(たとえば、eMBMS)に関連するユーザサービスディスカバリ手順の一部としてUE920によって受信され得る。USD940は、メディアコンテンツ(たとえば、ストリーミングビデオ、ストリーミングオーディオなど)にアクセスするための複数のユニフォームリソース識別子(URI)を生成するためのテンプレートを識別するテンプレート情報を含むことができる。図8に関連して上で説明したように、テンプレートは、「http://www.ex.com/video_」および「mp4」として示された、URIごとに同一である静的部分と、「$number$」として示されたURIごとに異なる動的部分とを識別することができる。さらに図示されているように、USD940は、午後1:00として示された、メディアコンテンツの開始時刻などのメディアコンテンツのスケジュール(たとえば、ブロードキャストが開始する時刻、マルチキャストが開始する時刻など)と、1分として示された、URIによって識別されるメディアセグメントのセグメント持続時間(たとえば、各メディアセグメントは、長さにおいて1分とすることができる)とを示すことができる。

さらに示されているように、eNB910は、番号0および1を含む動的部分を有するURI(たとえば、「www.ex.com/video_0.mp4」および「www.ex.com/video_1.mp4」)を含むプレイリストファイル950を送信することができる。UE920は、プレイリストファイル950を受信することができる。後刻に、eNB910は、番号2および3を含む動的部分を有する追加のURI(たとえば、「www.ex.com/video_2.mp4」および「www.ex.com/video_3.mp4」)を含むプレイリストファイル更新960を送信することができる(たとえば、プレイリストファイル950を更新するために)。そのときに、UE920がセル930を去っており、プレイリストファイル更新960を受信できないと仮定する。したがって、UE920は、本明細書で説明される技法を使用しなければ、プレイリストファイル更新960内に含まれるURIに関連するメディアセグメントにアクセスすることができない。

さらに示されているように、UE920は、メディアコンテンツにアクセスするための1つまたは複数のURIを生成するのに、テンプレート情報(たとえば、URIテンプレート、開始時刻、およびセグメント持続時間)を使用することができる。いくつかの態様では、UE920は、URIを生成するために現在時刻を開始時刻と比較することができる。たとえば、UE920は、午後1:00の開始時刻、1分の持続時間、および午後1:02の現在時刻に基づいて、「www.ex.com/video_2.mp4」というURIを生成することができる(たとえば、第1の分に関連するメディアセグメントのURIの0の動的部分、第2の分に関連するメディアセグメントのURIの1の動的部分、および第3の分に関連するメディアセグメントのURIの2の動的部分)。さらに示されているように、UE920は、URIの第4の分に関連するメディアセグメントの「www.ex.com/video_3.mp4」というURIを生成することができる。

それに加えてまたはその代わりに、UE920は、サーバの供給したURIがプレイリストファイルに存在しないことの判定に基づいてURIを生成することができる(たとえば、メディアコンテンツの再生の前に、メディアコンテンツの再生中になど)。たとえば、「video_1.mp4」の再生中に、UE920は、次のファイル(たとえば、「video_2.mp4」)のURIがプレイリストファイルに存在しないと判定することができる。メディアコンテンツの長さ(たとえば、USD940内で示され得る)に基づいて、UE920は、「video_2.mp4」のURIがプレイリストファイル950内に存在しなければならないと判定することができ、この判定に基づいてURIを生成することができる(たとえば、「www.ex.com/video_2.mp4」というURIを生成することができる)。

UE920は、生成されたURIをプレイリストファイル950内に記憶することができ、生成されたURIを使用してメディアコンテンツのメディアセグメントにアクセスすることができる。このようにして、UE920は、メディアセグメントのURIがeNB910から受信されないときであっても、通信(たとえば、ブロードキャスト通信、マルチキャスト通信、eMBMS通信など)のメディアセグメントにアクセスすることができる。たとえば、UE920は、UE920がeNB910に関連するセル930を去ったので、UE920がeNB910との接続を失ったので、または類似物のゆえに、サーバの生成したURI(たとえば、BM-SC、ビデオサーバ、オーディオサーバなどによって生成された)を受信できない場合がある。この場合に、UE920は、UE920がセル930に再進入するときおよび/または別のセルに遷移するときに、URIを生成することができ、生成されたURIを使用してメディアセグメントにアクセスすることができる。このようにして、UE920は、ユーザ経験を改善することができ(たとえば、コンテンツの連続再生を可能にすることによって)、ネットワークリソースを節約することができ(たとえば、減らされた回数のプレイリストファイル更新の送信を可能にすることによって、UEがサーバからURIを受信するのではなくUEがURIを生成するためのテンプレート情報を有するのでプレイリストファイルまたはプレイリストファイル更新のサーバ送信を除去することによって、など)、または類似物を行うことができる。

いくつかの態様では、UE920は、マルチメディアブロードキャストマルチキャストサービス(たとえば、eMBMS)の一部としてテンプレート情報(たとえば、URIテンプレート、スケジュールなど)を受信することができる。たとえば、UE920は、eMBMS内のユーザサービスディスカバリ手順の一部として、ユーザサービスアナウンスメントの一部として、または類似物としてUSD940を受信することができる。いくつかの態様では、UE920は、生成されたURIを使用して、マルチメディアブロードキャストマルチキャストサービスを介してメディアコンテンツにアクセスすることができる。いくつかの態様では、UE920は、生成されたURIを使用して、ユニキャストサービスを介してメディアコンテンツにアクセスすることができる。このようにして、UE920は、通信がUE920とマルチメディアブロードキャストマルチキャストサービスとの間で失われる場合であっても、コンテンツの連続再生を可能にすることができる。

上で示したように、図9に示されたシステム900は、例として提供される。他の例が可能であり、図9に関連して説明されたものとは異なる可能性がある。

図10Aおよび図10Bは、eMBMSを介するHLSを可能にするように構成された追加の例のシステム1000および1000'を示す図である。図10Aおよび図10Bに示されているように、システム1000および1000'は、BM-SC1010(たとえば、図1のBM-SC126、図8のBM-SC810などを含むことができる)、eNB1020(たとえば、図1のeNB106、108、図2のeNB204、208、図6のeNB610、図7のeNB752、754、図8のeNB820、図9のeNB910などのうちの1つまたは複数を含むことができる)、UE1030(たとえば、図1のUE102、図2のUE206、図6のUE650、図7のUE760、770、図8のUE830、図9のUE920などのうちの1つまたは複数を含むことができる)、ビデオサーバ1040(たとえば、図8のビデオサーバ840などを含むことができる)、およびオーディオサーバ1050を含むことができる。

図10Aに示されているように、BM-SC1010は、eNB1020を介して、ユーザサービス記述(USD)1060をUE1030に提供することができる。USD1060は、複数のメディアプレイリストファイルの情報を含むマスタプレイリストファイルを含むことができる。メディアプレイリストファイルは、メディアプレイリストファイルに関連するメディアコンテンツにアクセスするための複数のユニフォームリソース識別子(URI)を生成するためのテンプレートを識別するテンプレート情報を含むことができる。それに加えてまたはその代わりに、メディアプレイリストファイルは、ビデオ、オーディオ、テキスト、または類似物などのメディアタイプに関連付けられ得る。それに加えてまたはその代わりに、メディアプレイリストファイルは、英語、スペイン語、中国語、日本語または類似物などの言語に関連付けられ得る。

図示されているように、第1のメディアプレイリストファイル(たとえば、「メディアプレイリストファイル1」)は、ビデオのメディアタイプを有することができ、第1のメディアプレイリストファイルに関連するURIの静的部分(たとえば、「www.media.com/video_」および「.mp4」)および第1のメディアプレイリストファイルに関連するURIの動的部分(たとえば、「$#$」、ただし、各URIは、$文字の間に異なる数字を有する)を識別するテンプレート情報を含むことができる。

第2のメディアプレイリストファイル(たとえば、「メディアプレイリストファイル2」)は、オーディオのメディアタイプを有することができ、オーディオは、英語とすることができる。第2のメディアプレイリストファイルは、第2のメディアプレイリストファイルに関連するURIの静的部分(たとえば、「www.media.com/audio_eng_」および「.mp3」)および第2のメディアプレイリストファイルに関連するURIの動的部分(たとえば、「$#$」、ただし、各URIは、$文字の間に異なる数字を有する)を識別するテンプレート情報を含むことができる。

第3のメディアプレイリストファイル(たとえば、「メディアプレイリストファイル3」)は、オーディオのメディアタイプを有することができ、オーディオは、スペイン語とすることができる。第3のメディアプレイリストファイルは、第3のメディアプレイリストファイルに関連するURIの静的部分(たとえば、「www.media.com/audio_spa_」および「.mp3」)および第3のメディアプレイリストファイルに関連するURIの動的部分(たとえば、「$#$」、ただし、各URIは、$文字の間に異なる数字を有する)を識別するテンプレート情報を含むことができる。

図示されているように、UE1030は、eNB1020を介して、マスタプレイリストファイルおよびメディアプレイリストファイルを含むUSD1060を受信することができる。いくつかの態様では、USD1060、マスタプレイリストファイルおよび/またはメディアプレイリストファイルは、メディアコンテンツの1つまたは複数の部分(たとえば、セグメント)の持続時間、プレイリストファイルに関連するプロトコルのバージョン、プレイリストファイルに関連する開始メディアシーケンス識別子(たとえば、開始メディアシーケンス番号)、または類似物などのプレイリスト情報を含むことができる。UE1030は、プレイリストファイル(たとえば、メディアプレイリストファイル)および/またはプレイリストファイル内に記憶される1つまたは複数のURIを生成するときに、プレイリスト情報を使用することができる。

図10Bに示されているように、UE1030は、UE1030によってアクセスされるメディアコンテンツの1つまたは複数のパラメータを示すユーザ入力を受信することができる。たとえば、ユーザが、ユーザが英語のビデオを見ることを望むことを示す入力を提供すると仮定する。メディアタイプ(たとえば、ビデオおよびビデオに関連するオーディオ)および言語(たとえば、英語)を識別するこのユーザ入力に基づいて、UE1030は、テンプレート情報に基づいてメディアプレイリストファイルのURIを生成することができる。

この場合に、UE1030は、ビデオの第1のメディアプレイリストファイル1070(たとえば、「メディアプレイリストファイル1」)のURIおよび英語のオーディオの第2のメディアプレイリストファイル1080(たとえば、「メディアプレイリストファイル2」)のURIを生成することができる。たとえば、図示されているように、UE1030は、第1のメディアプレイリストファイル1070のために「www.media.com/video_1.mp4」、「www.media.com/video_2.mp4」、「www.media.com/video_3.mp4」などのURIを生成するのにテンプレートを使用することができる。さらに図示されているように、UE1030は、第2のメディアプレイリストファイル1080のために「www.media.com/audio_eng_1.mp3」、「www.media.com/audio_eng_2.mp3」、「www.media.com/audio_eng_2.mp3」などのURIを生成するのにテンプレートを使用することができる。

図示されているように、UE1030は、ビデオサーバ1040からビデオコンテンツにアクセスするのに第1のメディアプレイリストファイル1070から生成されたURIを使用することができ、オーディオサーバ1050から英語のオーディオコンテンツ(たとえば、ビデオコンテンツに関連する)にアクセスするのに第2のメディアプレイリストファイル1080から生成されたURIを使用することができる。このようにして、UE1030は、URIが、URIを生成するサーバから(たとえば、URIをブロードキャストし、かつ/またはマルチキャストするeNBを介して)受信されない場合であってもUE1030がメディアコンテンツにアクセスできるように、メディアコンテンツに関する異なるメディアタイプ、異なる言語などにアクセスするためのURIを生成するのにテンプレートを使用することができる。

上で示したように、図10Aおよび図10Bに示された例のシステム1000および1000'は、例として提供される。他の例が可能であり、図10Aおよび図10Bに関連して説明されたものとは異なる可能性がある。

図11は、ワイヤレス通信の方法のフローチャート1100である。いくつかの態様では、この方法は、UE(たとえば、図1のUE102、図2のUE206、図6のUE650、図7のUE760、770、図8のUE830、図9のUE920、図10Aおよび/または図10BのUE1030、図16の装置1602、図17の装置1602'などのうちの1つまたは複数)によって実行され得る。

1102において、UEは、メディアコンテンツにアクセスするための複数のユニフォームリソース識別子(URI)を生成するためのテンプレートを識別するテンプレート情報を受信することができる。たとえば、上で図8に関連して説明したように、UE830は、eNB820からテンプレート情報を受信することができる(たとえば、USD850の一部として)。テンプレート情報は、メディアコンテンツにアクセスするための複数のURIを生成するためのテンプレートを識別することができる。たとえば、テンプレート情報は、URIの静的部分およびURIの動的部分を含むURIテンプレートを識別することができる。静的部分は、異なるURIに関して同一である文字列を示すことができる。動的部分は、異なるURIに関して異なる(たとえば、URIごとに一意の)文字列を示すことができる。テンプレート情報は、URIの動的部分をどのように生成すべきかを記述した情報を含むことができる。たとえば、動的部分は、周期的インターバルにおいて生成される連続するURI内に含まれる時間(たとえば、秒単位、ミリ秒単位など)、シーケンス内の番号(たとえば、連続するURIの動的部分に関して特定の量だけ増分される)、または類似物を含むことができる。時間は、たとえば、現在時刻、ブロードキャストの開始から経過した時間の長さ、または類似物を含むことができる。URIは、ビデオセグメント、オーディオセグメント、テキストセグメント、または類似物などのメディアセグメント(たとえば、メディアコンテンツの全体より短い、メディアコンテンツの部分)に関連付けられ得る。

1104において、UEは、テンプレートに基づいて、メディアコンテンツの1つまたは複数の部分にアクセスするための複数のURIのうちの1つまたは複数のURIを生成することができる。たとえば、上で図8に関連して説明したように、UE830は、メディアコンテンツの1つまたは複数の部分にアクセスするための1つまたは複数のURIを生成するのにテンプレートを使用することができる。生成されるURIは、生成されるURIごとに同一とすることのできる静的部分と、生成されるURIごとに異なるものとすることのできる動的部分とを含むことができる。

1106において、UEは、1つまたは複数のURIをプレイリストファイル内に記憶することができる。たとえば、上で図8に関連して説明したように、UE830は、プレイリストファイル860内に1つまたは複数のURIを記憶することができる(たとえば、URIがメディアセグメントにアクセスするのに使用されるシーケンスを示す順序において)。いくつかの態様では、UE830は、ユーザサービスアナウンスメント(たとえば、eMBMSに関連する)に基づいてプレイリストファイル860を受信する(たとえば、eNB820から)ことができ、プレイリストファイル860内に1つまたは複数のURIを記憶することができる。いくつかの態様では、UE830は、プレイリストファイル860を生成することができる。

いくつかの態様では、プレイリストファイル860は、メディアコンテンツの1つまたは複数の部分(たとえば、セグメント)の持続時間、プレイリストファイルに関連するプロトコルのバージョン、プレイリストファイルに関連する開始メディアシーケンス識別子、または類似物などのプレイリスト情報を含むことができる。いくつかの態様では、UE830は、ユーザサービスアナウンスメントに少なくとも部分的に基づいてプレイリスト情報を受信することができ、プレイリストファイル860内にプレイリスト情報を記憶することができる。UE830は、プレイリストファイル860を生成するときおよび/またはプレイリストファイル860内に記憶される1つまたは複数のURIを生成するときに、プレイリスト情報を使用することができる。

UE830は、プレイリストファイル860内に記憶された生成されたURIを使用して、メディアコンテンツの諸部分にアクセスすることができる(たとえば、ビデオサーバ840および/または別のデバイスから)。たとえば、UE830上で実行中のミドルウェアが、UE830上で実行中のHLSクライアントにプレイリストファイル860を供給することができる。HLSクライアントは、プレイリストファイル860内に記憶された生成されたURIを使用して、メディアコンテンツの諸部分にアクセスすることができる。このようにして、UE830がプレイリストファイル860に対する更新(たとえば、プレイリストファイル860内に含まれるべき1つまたは複数のURIを識別する更新)を受信できない場合に、UE830は、受信されなかったURIを生成することができ、メディアコンテンツにアクセスし、再生し続ける(たとえば、シームレスな形において)ことができる。

図11は、ワイヤレス通信の方法の例のブロックを示すが、いくつかの態様では、この方法は、追加のブロック、より少数のブロック、異なるブロック、または図11に示されたブロックとは異なって配置されたブロックを含むことができる。それに加えてまたはその代わりに、図11に示された2つ以上のブロックが、並列に実行され得る。

図12は、ワイヤレス通信の方法のフローチャート1200である。いくつかの態様では、この方法は、UE(たとえば、図1のUE102、図2のUE206、図6のUE650、図7のUE760、770、図8のUE830、図9のUE920、図10Aおよび/または図10BのUE1030、図16の装置1602、図17の装置1602'などのうちの1つまたは複数)によって実行され得る。

1202において、UEは、マルチメディアブロードキャストマルチキャストサービスに関連するユーザサービスディスカバリ手順の一部としてユーザサービス記述(USD)を受信することができる。たとえば、上で図8に関連して説明したように、UE830は、USD850を受信することができる。いくつかの態様では、UE830は、eMBMSなどのマルチメディアブロードキャストマルチキャストサービスに関連するサービスディスカバリ手順の一部としてUSD850を受信することができる。

1204において、UEは、メディアコンテンツにアクセスするための複数のユニフォームリソース識別子(URI)を生成するためのテンプレートを識別するテンプレート情報を、USDに少なくとも部分的に基づいて受信することができる。たとえば、上で図11に関連して(たとえば、1102において)説明したように、UEは、テンプレート情報を受信することができる。テンプレート情報は、本明細書の他所でより詳細に説明するように、メディアコンテンツにアクセスするための複数のURIを生成するためのテンプレートを識別することができる。いくつかの態様では、UEは、USDに少なくとも部分的に基づいてテンプレート情報を受信することができる。たとえば、テンプレート情報は、USD内に含められ得る。それに加えてまたはその代わりに、テンプレート情報は、マルチメディアブロードキャストマルチキャストサービス(たとえば、eMBMS)を介して受信され得る。

1206において、UEは、テンプレートに基づいて、メディアコンテンツの1つまたは複数の部分にアクセスするための複数のURIのうちの1つまたは複数のURIを生成することができる。たとえば、上で図11に関連して(たとえば、1104において)説明したように、UEは、メディアコンテンツの1つまたは複数の部分にアクセスするための1つまたは複数のURIを生成することができる。

1208において、UEは、1つまたは複数のURIをプレイリストファイル内に記憶することができる。たとえば、上で図11に関連して(たとえば、1106において)説明したように、UEは、プレイリストファイル内の1つまたは複数のURIを記憶することができる。

1210において、UEは、プレイリストファイル内に記憶された複数のURIのうちの1つまたは複数のURIを使用してメディアコンテンツの1つまたは複数の部分にアクセスすることができる。たとえば、上で図8に関連して説明したように、UE830(たとえば、HLSクライアント)は、プレイリストファイル860内に記憶された1つまたは複数の生成されたURIを使用して、メディアコンテンツの1つまたは複数の部分にアクセスすることができる。たとえば、メディアコンテンツの1つまたは複数の部分は、1つまたは複数のサーバ(たとえば、ビデオサーバ840、ビデオサーバ1040、オーディオサーバ1050など)によって記憶され得、UE830は、1つまたは複数の生成されたURIを使用して、1つまたは複数のサーバによって記憶されたメディアコンテンツの1つまたは複数の部分にアクセスすることができる。

一例として、メディアコンテンツの1つまたは複数の部分は、メディアコンテンツの第1の部分およびメディアコンテンツの第2の部分を含むことができ、複数のURIは、第1のURIおよび第2のURIを含むことができ、第1のURIおよび第2のURIは、プレイリストファイル内に含められ得る。UEは、プレイリストファイル内に含まれる第1のURIに基づいてメディアコンテンツの第1の部分にアクセスすることができ、プレイリストファイル内に含まれる第2のURIに基づいてメディアコンテンツの第2の部分にアクセスすることができる。

いくつかの態様では、UEは、eMBMSなどのマルチメディアブロードキャストマルチキャストサービスを使用してメディアコンテンツの1つまたは複数の部分にアクセスすることができる。いくつかの態様では、UEは、ユニキャストサービスを使用してメディアコンテンツの1つまたは複数の部分にアクセスすることができる。このようにして、UEは、UEがメディアコンテンツの1つまたは複数の部分に対応する1つまたは複数のURIを受信できない(たとえば、UEがプレイリストファイル更新内で1つまたは複数のURIを供給するeNBの範囲外にあることに起因して、プレイリストファイル更新内のエラーに起因してなど)場合であっても、メディアコンテンツの1つまたは複数の部分にアクセスすることができる。この場合において、UEは、1つまたは複数のURIを受信するのではなく、1つまたは複数のURIを生成することができる。

図12は、ワイヤレス通信の方法の例のブロックを示すが、いくつかの態様では、この方法は、追加のブロック、より少数のブロック、異なるブロック、または図12に示されたブロックとは異なって配置されたブロックを含むことができる。それに加えてまたはその代わりに、図12に示された2つ以上のブロックが、並列に実行され得る。

図13は、ワイヤレス通信の方法のフローチャート1300である。いくつかの態様では、この方法は、UE(たとえば、図1のUE102、図2のUE206、図6のUE650、図7のUE760、770、図8のUE830、図9のUE920、図10Aおよび/または図10BのUE1030、図16の装置1602、図17の装置1602'などのうちの1つまたは複数)によって実行され得る。

1302において、UEは、プレイリストファイルに対するサーバ提供の更新がないと判定することができる。たとえば、上で図9に関連して説明したように、UE920は、セル930を去る場合があり、eNB910からプレイリストファイル950に対する更新を受信できない場合がある。eNB910は、BM-SC、ビデオサーバ、オーディオサーバ、または類似物などのサーバからプレイリストファイル950に対する更新を受信することができる。プレイリストファイル950に対する更新は、メディアコンテンツの1つまたは複数の部分にアクセスするための1つまたは複数のURIを含むことができる。UE920が、これらのURIを受信できない場合がある。

いくつかの態様では、UE920は、メディアコンテンツの再生の前またはメディアコンテンツの再生中に、URIがプレイリストファイル950にないと判定することができる。たとえば、UE920は、メディアコンテンツの第1の部分にアクセスするのに第1のURIを使用することができ、メディアコンテンツの第2の部分にアクセスするのに使用されるべき第2のURIがプレイリストファイル950にないと判定することができる。

1304において、UEは、サーバ提供の更新がないとの判定に基づいて、メディアコンテンツの1つまたは複数の部分にアクセスするための複数のURIのうちの1つまたは複数のURIを生成することができる。たとえば、上で図9に関連して説明したように、UE920は、1つまたは複数のURIの受信の失敗に基づいて、1つまたは複数のURIを生成することができる。いくつかの態様では、UE920は、URIがプレイリストファイル950にないと判定することができ、URIがプレイリストファイル950にないとの判定に基づいてURIを生成することができる。いくつかの態様では、UE920は、URIがプレイリストファイル950にないと判定せずにURIを生成することができる。たとえば、USDは、HLSコンテンツを提供するユーザサービスを示すことができ、テンプレート情報(および/またはマスタプレイリストファイル、メディアプレイリストファイル、もしくは類似物などの他の情報)を提供することができ、かつ/またはUE920がテンプレート情報を使用してメディアプレイリストファイルを生成すべきであることを示すことができる。この場合において、UE920は、プレイリストファイル950を生成することができる(たとえば、テンプレート情報の受信に基づいて)。UE920は、本明細書の他所でより詳細に説明するように、テンプレートを使用してURIを生成することができる。

いくつかの態様では、テンプレートは、複数のURIに関連するスケジュールを識別することができ、UE920は、スケジュールに基づいて1つまたは複数のURIを生成することができる。たとえば、スケジュールは、メディアコンテンツの開始時刻、メディアコンテンツの一部のセグメント持続時間、または類似物を含むことができる。上で図9に関連して説明したように、UE920は、現在時刻を識別することができ、メディアコンテンツの開始時刻およびメディアコンテンツの一部のセグメント持続時間を判定することができ、現在時刻、開始時刻、およびセグメント持続時間を使用して、テンプレートに基づいて1つまたは複数のURIを生成することができる。いくつかの態様では、UE920は、本明細書の他所でより詳細に説明するように、プレイリストファイル内に1つまたは複数のURIを記憶することができる。このようにして、UE920は、UE920がメディアコンテンツにアクセスするためのURIを受信できないときであっても、メディアコンテンツを再生し続けることができる。

図13は、ワイヤレス通信の方法の例のブロックを示すが、いくつかの態様では、この方法は、追加のブロック、より少数のブロック、異なるブロック、または図13に示されたブロックとは異なって配置されたブロックを含むことができる。それに加えてまたはその代わりに、図13に示された2つ以上のブロックが、並列に実行され得る。

図14は、ワイヤレス通信の方法のフローチャート1400である。いくつかの態様では、この方法は、UE(たとえば、図1のUE102、図2のUE206、図6のUE650、図7のUE760、770、図8のUE830、図9のUE920、図10Aおよび/または図10BのUE1030、図16の装置1602、図17の装置1602'などのうちの1つまたは複数)によって実行され得る。

1402において、UEは、ハイパーテキスト転送プロトコル(HTTP)ライブストリーミング(HLS)プロトコルに関連するマスタプレイリストファイルを受信することができる。たとえば、上で図10Aに関連して説明したように、UE1030は、マスタプレイリストファイルを受信することができる。いくつかの態様では、マスタプレイリストファイルは、USD1060内に含められ得る。それに加えてまたはその代わりに、マスタプレイリストファイルは、HLSプロトコルに関連する1つまたは複数のメディアプレイリストファイルを識別することができる。メディアプレイリストファイルは、メディアコンテンツにアクセスするための1つまたは複数のURIを含むことができる。異なるメディアプレイリストファイル内に含まれる異なるURIは、異なるメディアタイプ、異なる言語、異なるビットレート、または類似物など、異なるパラメータに関連付けられ得る。

1404において、UEは、HLSプロトコルに関連するメディアプレイリストファイルを生成することができる。いくつかの態様では、UE1030は、マスタプレイリストファイル内に含められるべきメディアプレイリストファイルを生成することができる。それに加えてまたはその代わりに、UE1030は、メディアプレイリストファイルを受信することができる(たとえば、eNB1020から)。

1406において、UEは、メディアプレイリストファイルにアクセスするためのプレイリストURIをマスタプレイリストファイル内に記憶することができる。たとえば、UE1030は、マスタプレイリストファイル内にプレイリストURIを記憶することができる。プレイリストURIは、メディアプレイリストにアクセスするのに使用され得る(たとえば、アクセスされるべきメディアコンテンツに関連するパラメータに基づいて)。

1408において、UEは、テンプレートに基づいて、メディアコンテンツの1つまたは複数の部分にアクセスするための複数のURIのうちの1つまたは複数のURIを生成することができる。たとえば、上で図11、図12、および図13に関連して(たとえば、1104、1206、および1304において)説明したように、UE1030は、メディアコンテンツの1つまたは複数の部分にアクセスするための複数のURIのうちの1つまたは複数のURIを生成することができる。

1410において、UEは、1つまたは複数のURIをプレイリストファイル内に記憶することができる。たとえば、上で図10Bに関連して説明したように、UE1030は、1つまたは複数の生成されたURIをメディアプレイリストファイル内に記憶することができる。たとえば、UE1030は、第1のパラメータに関連する1つまたは複数のURIを第1のメディアプレイリストファイル1070内に記憶することができ、第2のパラメータに関連する1つまたは複数のURIを第2のメディアプレイリストファイル1080内に記憶することができる。

このようにして、UE1030は、1つまたは複数のメディアプレイリストファイルのURIを生成することができ、UE1030がeNB1020からURIを受信できない場合であっても、そのURIを使用して、メディアコンテンツの1つまたは複数の部分にアクセスすることができる。複数のメディアプレイリストファイルのURIを生成することによって、UE1030は、UE1030がURIを受信するのを防ぐサービス中断中であっても、異なるパラメータ(たとえば、異なるメディアタイプ、異なる言語など)を有するメディアコンテンツが連続再生のためにアクセスされることを可能にすることができる。UE1030は、マスタプレイリストファイル内にメディアプレイリストファイルのプレイリストURIを記憶することができ、これによって、メディアプレイリストファイル(および関連するURI)がマスタプレイリストファイルを使用してアクセスされることを可能にする。

図14は、ワイヤレス通信の方法の例のブロックを示すが、いくつかの態様では、この方法は、追加のブロック、より少数のブロック、異なるブロック、または図14に示されたブロックとは異なって配置されたブロックを含むことができる。それに加えてまたはその代わりに、図14に示された2つ以上のブロックが、並列に実行され得る。

図15は、ワイヤレス通信の方法のフローチャート1500である。いくつかの態様では、この方法は、UE(たとえば、図1のUE102、図2のUE206、図6のUE650、図7のUE760、770、図8のUE830、図9のUE920、図10Aおよび/または図10BのUE1030、図16の装置1602、図17の装置1602'などのうちの1つまたは複数)によって実行され得る。

1502において、UEは、メディアコンテンツのメディアタイプを記述するメディアタイプ情報および/またはメディアコンテンツに関連する言語を識別する言語情報を受信することができる。たとえば、上で図10Aに関連して説明したように、UE1030は、メディアコンテンツに関連するメディアタイプ(たとえば、ビデオメディアタイプ、オーディオメディアタイプなど)を記述するメディアタイプ情報を受信することができる。それに加えてまたはその代わりに、UE1030は、メディアコンテンツに関連する言語(たとえば、英語、スペイン語など)を識別する言語情報を受信することができる。いくつかの態様では、UE1030は、メディアコンテンツに関連する他のパラメータを識別する情報(たとえば、ビットレート、フォーマットなど)を受信することができる。

1504において、UEは、テンプレートに基づいて、メディアコンテンツの1つまたは複数の部分にアクセスするための複数のURIのうちの1つまたは複数のURIを生成することができる。たとえば、上で図11、図12、図13、および図14に関連して(たとえば、1104、1206、1304、および1408において)説明したように、UE1030は、メディアコンテンツの1つまたは複数の部分にアクセスするために複数のURIのうちの1つまたは複数のURIを生成することができる。いくつかの態様では、UE1030は、1つまたは複数のURIを生成するのにテンプレートを使用することができる。それに加えてまたはその代わりに、テンプレートは、異なるパラメータ(たとえば、異なるメディアタイプ、異なる言語など)に関連するURIに関して異なるものとすることができる。たとえば、テンプレートは、異なるパラメータに関連するURIの異なる静的部分を識別することができ、異なるパラメータに関連するURIの異なる動的部分を識別することができる。

1506において、UEは、メディアタイプ情報および/または言語情報に基づいて、プレイリストファイルを識別することができる。たとえば、上で図10Bに関連して説明したように、UE1030は、メディアタイプ情報、言語情報、または類似物に基づいて、1つまたは複数の生成されたURIを記憶するためにプレイリストファイル(たとえば、メディアプレイリストファイル)を識別することができる。一例として、UE1030は、ビデオメディアタイプに基づいて、ビデオメディアコンテンツにアクセスするための1つまたは複数の生成されたURIを記憶するために第1のメディアプレイリストファイル1070を識別することができる。別の例として、UE1030は、オーディオメディアタイプおよび英語の言語に基づいて、英語のオーディオメディアコンテンツにアクセスするための1つまたは複数の生成されたURIを記憶するために第2のメディアプレイリストファイル1080を識別することができる。

1508において、UEは、1つまたは複数のURIをプレイリストファイル内に記憶することができる。たとえば、上で図11、図12、および図14に関連して(たとえば、1106、1208、および1410において)説明したように、UE1030は、プレイリストファイル内に1つまたは複数のURIを記憶することができる。一例として、上で図10Bに関連して説明したように、UE1030は、第1のメディアプレイリストファイル1070内に、ビデオメディアタイプに関連する1つまたは複数の生成されたURIを記憶することができる。別の例として、UE1030は、第2のメディアプレイリストファイル1080内に、オーディオメディアタイプおよび英語の言語に関連する1つまたは複数の生成されたURIを記憶することができる。

このようにして、UE1030は、UE1030が異なるパラメータを有するメディアコンテンツにアクセスするためのURIを受信できないときであっても、異なるパラメータを有するメディアコンテンツがアクセスされることを可能にすることができる。

図15は、ワイヤレス通信の方法の例のブロックを示すが、いくつかの態様では、この方法は、追加のブロック、より少数のブロック、異なるブロック、または図15に示されたブロックとは異なって配置されたブロックを含むことができる。それに加えてまたはその代わりに、図15に示された2つ以上のブロックが、並列に実行され得る。

図16は、例示的な装置1602内の異なるモジュール/手段/構成要素の間のデータフローを示す概念データフロー図1600である。装置1602は、UEとすることができる。図示されているように、装置1602は、受信モジュール1604、生成モジュール1606、記憶モジュール1608、アクセスモジュール1610、送信モジュール1612、判定モジュール1614、および識別モジュール1616を含むことができる。

受信モジュール1604は、本明細書の他所でより詳細に説明するように、テンプレート情報、ユーザサービス記述(USD)、マスタプレイリストファイル、メディアタイプ情報、言語情報、または類似物を含むことのできるデータ1618を受信することができる。いくつかの態様では、装置1602は、eNB1650(たとえば、図1のeNB106、108、図2のeNB204、208、図6のeNB610、図7のeNB752、754、図8のeNB820、図9のeNB910、図10Aおよび図10BのeNB1020などのうちの1つまたは複数を含むことができる)から入力としてデータ1618を受信することができる。図示されているように、受信モジュール1604は、生成モジュール1606(たとえば、データ1620として)、判定モジュール1614(たとえば、データ1628として)、識別モジュール1616(たとえば、データ1634として)、および/または送信モジュール1612(たとえば、データ1638として)への出力としてデータ1618(たとえば、受信モジュール1604によって処理され得る)を供給することができる。

生成モジュール1606は、受信モジュール1604からデータ1620を受信することができる。データ1620に基づいて、生成モジュール1606は、メディアコンテンツの1つまたは複数の部分にアクセスするための複数のURIのうちの1つまたは複数のURIを生成することができ、プレイリストファイル(たとえば、マスタプレイリストファイル、メディアプレイリストファイルなど)を生成することができ、あるいは類似物を行うことができる。図示されているように、生成モジュール1606は、出力を記憶モジュール1608に(たとえば、データ1622として)供給することができる。

記憶モジュール1608は、生成モジュール1606からデータ1622を受信することができ、かつ/または識別モジュール1616からデータ1640を受信することができる。データ1622および/またはデータ1640に基づいて、記憶モジュール1608は、プレイリストファイル内に1つまたは複数のURI(たとえば、1つまたは複数の受信されたURI、1つまたは複数の生成されたURIなど)を記憶することができ、マスタプレイリストファイル内にプレイリストURI(たとえば、メディアプレイリストファイルを識別する)を記憶することができ、あるいは類似物を行うことができる。図示されているように、記憶モジュール1608は、出力をアクセスモジュール1610に(たとえば、データ1624として)供給することができる。

アクセスモジュール1610は、記憶モジュール1608からデータ1624を受信することができ、かつ/または判定モジュール1614からデータ1630を受信することができる。データ1624および/またはデータ1630に基づいて、アクセスモジュール1610は、プレイリストファイル内に記憶された複数のURIのうちの1つまたは複数のURIを使用してメディアコンテンツの1つまたは複数の部分にアクセスすることができ、プレイリストファイル内に含まれる第1のURIに基づいてメディアコンテンツの第1の部分にアクセスすることができ、プレイリストファイル内に含まれる第2のURIに基づいてメディアコンテンツの第2の部分にアクセスすることができ、マルチメディアブロードキャストマルチキャストサービスを介してメディアコンテンツの1つまたは複数の部分にアクセスすることができ、ユニキャストサービスを介してメディアコンテンツの1つまたは複数の部分にアクセスすることができ、あるいは類似物を行うことができる。図示されているように、アクセスモジュール1610は、送信モジュール1612にデータ1626を供給することができる。いくつかの態様では、アクセスモジュール1610は、HLSクライアント内に含まれ得る。

送信モジュール1612は、メディアコンテンツおよび/またはメディアコンテンツの諸部分にアクセスする際にアクセスモジュール1610を支援することができる。送信モジュール1612は、アクセスモジュール1610からデータ1626を、判定モジュール1614からデータ1632を、識別モジュール1616からデータ1636を、および/または受信モジュール1604からデータ1638を受信することができる。データ1626、データ1632、データ1636、および/またはデータ1638のうちの1つまたは複数に基づいて、送信モジュール1612は、メディアコンテンツおよび/またはメディアコンテンツの諸部分にアクセスする際にアクセスモジュール1610を支援するために、eNB1650にデータ1642を送信することができる(たとえば、ビデオサーバ、オーディオサーバ、または類似物など、メディアコンテンツおよび/またはメディアコンテンツの部分を供給するデバイスに向けてデータ1642を送信することができる)。いくつかの態様では、送信モジュール1612は、eNB1650にデータ1642を送信しなくてもよい。たとえば、データ1642が、装置1602によって既に入手されたメディアコンテンツの要求を含む(たとえば、装置1602が、eNB1650からメディアコンテンツを成功裡に受信したので)場合に、データ1642は、装置1602において(たとえば、装置1602のミドルウェアにおいて)終端することができる。

判定モジュール1614は、受信モジュール1604からデータ1628を受信することができる。データ1628に基づいて、判定モジュール1614は、プレイリストファイルに対するサーバの供給する更新がないと判定することができる(たとえば、メディアコンテンツの再生の前、メディアコンテンツの再生中、または類似物)。図示されているように、判定モジュール1614は、アクセスモジュール1610にデータ1630を供給することができ、かつ/または送信モジュール1612にデータ1632を供給することができる。

識別モジュール1616は、受信モジュール1604からデータ1634を受信することができる。データ1634に基づいて、識別モジュール1616は、メディアタイプ情報および/または言語情報に基づいて、複数のプレイリストファイルからプレイリストファイルを識別することができる。図示されているように、識別モジュール1616は、送信モジュール1612にデータ1636を供給することができる。

装置は、図11、図12、図13、図14、および/または図15の前述のフローチャート内のアルゴリズムのブロックの各々を実施する追加のモジュールを含むことができる。したがって、図11、図12、図13、図14、および/または図15の前述のフローチャート内の各ブロックは、モジュールによって実施されてよく、装置は、これらのモジュールの1つまたは複数を含むことができる。モジュールは、指定されたプロセス/アルゴリズムを実行するように明確に構成され、指定されたプロセス/アルゴリズムを実施するように構成されたプロセッサによって実装され、プロセッサによる実装のためにコンピュータ可読媒体内に記憶された、1つもしくは複数のハードウェア構成要素、またはそれらの何らかの組合せであり得る。

図16に示されたモジュールの個数および配置は、例として提供される。実際には、追加のモジュール、より少数のモジュール、異なるモジュール、または図16に示されたモジュールとは異なって配置されたモジュールを含むことができる。さらに、図16に示された2つ以上のモジュールが、単一のモジュール内で実施され得、あるいは、図16に示された単一のモジュールが、複数の分散されたモジュールとして実施され得る。それに加えてまたはその代わりに、図16に示されたモジュールのセット(たとえば、1つまたは複数のモジュール)が、図16に示されたモジュールの別のセットによって実行されるものとして説明された1つまたは複数の機能を実行することができる。

図17は、処理システム1714を利用する装置1602'についてのハードウェア実装形態の一例を示す図1700である。処理システム1714は、バス1724によって全般に表されるバスアーキテクチャで実装され得る。バス1724は、処理システム1714の特定の適用例および全体的な設計制約に応じて、任意の数の相互接続するバスおよびブリッジを含み得る。バス1724は、プロセッサ1704、モジュール1604、1606、1608、1610、1612、1614、および1616、ならびにコンピュータ可読媒体/メモリ1706によって表される、1つまたは複数のプロセッサおよび/またはハードウェアモジュールを含む様々な回路を互いにリンクさせる。バス1724は、タイミングソース、周辺機器、電圧レギュレータ、および/または電力管理回路などの種々の他の回路をリンクすることもできるが、これらの回路は当技術分野でよく知られており、したがって、これ以上は説明されない。

処理システム1714は、トランシーバ1710に結合されてよい。トランシーバ1710は、1つまたは複数のアンテナ1720に結合される。トランシーバ1710は、送信媒体上の様々な他の装置と通信するための手段を提供する。トランシーバ1710は、1つまたは複数のアンテナ1720から信号を受信し、受信された信号から情報を抽出し、抽出された情報を処理システム1714、具体的には受信モジュール1604に提供する。加えて、トランシーバ1710は、処理システム1714、詳細には送信モジュール1612から情報を受信し、受信された情報に基づいて、1つまたは複数のアンテナ1720に印加されるべき信号を生成する。処理システム1714は、コンピュータ可読媒体/メモリ1706に結合されたプロセッサ1704を含む。プロセッサ1704は、コンピュータ可読媒体/メモリ1706上に記憶されたソフトウェアの実行を含む、一般的な処理を担う。ソフトウェアは、プロセッサ1704によって実行されると、処理システム1714に、任意の特定の装置について上で説明した様々な機能を実施させる。コンピュータ可読媒体/メモリ1706は、ソフトウェアの実行時にプロセッサ1704によって操作されるデータを記憶するために使用することもできる。処理システムはさらに、モジュール1604、1606、1608、1610、1612、1614、および/または1616のうちの少なくとも1つを含む。モジュールは、プロセッサ1704内で実行中のソフトウェアモジュールでもよく、コンピュータ可読媒体/メモリ1706内に常駐している/記憶されたソフトウェアモジュールでもよく、プロセッサ1704に結合された1つまたは複数のハードウェアモジュールでもよく、それらの何らかの組合せでもよい。処理システム1714は、(たとえば、本明細書で説明する1つまたは複数の他のUEを含み得る)UE650の構成要素であってよく、メモリ660、ならびに/または、TXプロセッサ668、RXプロセッサ656、およびコントローラ/プロセッサ659のうちの少なくとも1つを含んでよい。

一構成では、ワイヤレス通信のための装置1602/1602'は、メディアコンテンツにアクセスするための複数のユニフォームリソース識別子(URI)を生成するためのテンプレートを識別するテンプレート情報を受信するための手段、メディアコンテンツの1つまたは複数の部分にアクセスするための複数のURIのうちの1つまたは複数のURIを生成するための手段、1つまたは複数のURIをプレイリストファイル内に記憶するための手段、HLSクライアントにプレイリストファイルを提供するための手段、マルチメディアブロードキャストマルチキャストサービスに関連するユーザサービスディスカバリ手順の一部としてユーザサービス記述(USD)を受信するための手段、プレイリストファイル内に含まれる第1のURIに基づいてメディアコンテンツの第1の部分にアクセスするための手段、プレイリストファイル内に含まれる第2のURIに基づいてメディアコンテンツの第2の部分にアクセスするための手段、プレイリストファイル内に記憶された複数のURIのうちの1つまたは複数のURIを使用してメディアコンテンツの1つまたは複数の部分にアクセスするための手段、プレイリストファイルに対するサーバ提供の更新がないと判定するための手段、ハイパーテキスト転送プロトコル(HTTP)ライブストリーミング(HLS)プロトコルに関連するマスタプレイリストファイルを受信するための手段、プレイリストファイルを生成するための手段、プレイリストURIをマスタプレイリストファイル内に記憶するための手段、メディアコンテンツのメディアタイプを記述するメディアタイプ情報を受信するための手段、メディアタイプ情報に基づいて、プレイリストファイルを識別するための手段、メディアコンテンツに関連する言語を識別する言語情報を受信するための手段、および/または言語情報に基づいて、プレイリストファイルを識別するための手段を含む。上記の手段は、装置1602の上記のモジュール、および/または上記の手段によって列挙された機能を実施するように構成された装置1602'の処理システム1714のうちの1つまたは複数であり得る。上記で記載されたように、処理システム1714は、TXプロセッサ668、RXプロセッサ656、およびコントローラ/プロセッサ659を含む場合がある。そのため、一構成では、上記の手段は、上記の手段によって列挙された機能を実施するように構成された、TXプロセッサ668、RXプロセッサ656、およびコントローラ/プロセッサ659であり得る。

開示されたプロセス/フローチャートにおけるブロックの特定の順序または階層は、例示的手法の一例であることが理解されよう。設計の選好に基づいて、プロセス/フローチャートにおけるブロックの特定の順序または階層を並べ替えてもよいことが理解されよう。さらに、いくつかのブロックを組み合わせてもよく、省略してもよい。添付の方法クレームは、見本の順序における様々なブロックの要素を提示しており、提示された特定の順序または階層に限定されることを意味するものではない。

上記の説明は、本明細書で説明する様々な態様を当業者が実践できるようにするために提供される。これらの態様に対する様々な修正は、当業者に容易に明らかになり、本明細書で定義する一般原理は、他の態様に適用され得る。したがって、特許請求の範囲は本明細書に示された態様に限定されるものではなく、文言通りの特許請求の範囲に整合するすべての範囲を与えられるべきであり、単数形の要素への言及は、そのように明記されていない限り、「唯一無二の」を意味することを意図せず、「1つまたは複数の」を意味する。「例示的」という用語は、本明細書では、「例、事例、または例示として機能する」ことを意味するために使用される。「例示的」として本明細書において説明されるいずれの態様も、必ずしも他の態様よりも好ましいか、または有利であると解釈されるとは限らない。特に別段の定めがない限り、「いくつか(some)」という用語は、1つまたは複数を指す。「A、BまたはCのうちの少なくとも1つ」、「A、BおよびCのうちの少なくとも1つ」、および「A、B、C、またはこれらの任意の組合せ」などの組合せは、A、Bおよび/またはCの任意の組合せを含み、複数のA、複数のB、または複数のCを含み得る。具体的に言うと、「A、BまたはCのうちの少なくとも1つ」、「A、BおよびCのうちの少なくとも1つ」、および「A、B、C、またはこれらの任意の組合せ」などの組合せは、Aのみ、Bのみ、Cのみ、AおよびB、AおよびC、BおよびCであってよく、またはAおよびBおよびCであってよく、ここで、任意のそのような組合せは、A、BまたはCの1つまたは複数のメンバーを含んでよい。当業者に知られているまたは後で知られているようになる、本開示を通して説明された様々な態様の要素に対するすべての構造的および機能的な等価物は、参照により本明細書に明確に組み込まれており、特許請求の範囲によって包含されることが意図されている。さらに、本明細書で開示する内容は、そのような開示が特許請求の範囲において明示的に列挙されているかどうかにかかわらず、公に供されるものではない。いかなるクレーム要素も、要素が「ための手段」という語句を使用して明確に列挙されていない限り、ミーンズプラスファンクションとして解釈されるべきではない。

100 ロングタームエボリューション(LTE)ネットワークアーキテクチャ、発展型パケットシステム(EPS)
102 ユーザ機器(UE)
104 発展型UMTS地上波無線アクセスネットワーク(E-UTRAN)
106 発展型ノードB(eNB)
108 eNB
110 発展型パケットコア(EPC)
112 モビリティ管理エンティティ(MME)
114 MME
116 サービングゲートウェイ
118 パケットデータネットワーク(PDN)ゲートウェイ
120 ホーム加入者サーバ(HSS)
122 事業者のインターネットプロトコル(IP)サービス
124 マルチメディアブロードキャストマルチキャストサービス(MBMS)ゲートウェイ
126 ブロードキャストマルチキャストサービスセンター(BM-SC)
128 マルチキャスト協調エンティティ(MCE)
200 アクセスネットワーク
202 セルラー領域(セル)
204 マクロeNB
206 UE
208 低電力クラスeNB
210 セルラー領域
300 図
302 セル固有RS(CRS)
304 UE固有RS(UE-RS)
400 図
410a 制御セクション内のリソースブロック
410b 制御セクション内のリソースブロック
420a データセクション内のリソースブロック
420b データセクション内のリソースブロック
430 物理ランダムアクセスチャネル(PRACH)
500 図
506 物理レイヤ
508 レイヤ2(L2レイヤ)
510 媒体アクセス制御(MAC)サブレイヤ
512 無線リンク制御(RLC)サブレイヤ
514 パケットデータコンバージェンスプロトコル(PDCP)サブレイヤ
516 無線リソース制御(RRC)サブレイヤ
610 eNB
616 送信(TX)プロセッサ
618TX 送信機
618RX 受信機
620 アンテナ
650 UE
652 アンテナ
654TX 送信機
654RX 受信機
656 受信(RX)プロセッサ
658 チャネル推定器
659 コントローラ/プロセッサ
660 メモリ
662 データシンク
667 データソース
668 TXプロセッサ
670 RXプロセッサ
674 チャネル推定器
675 コントローラ/プロセッサ
676 メモリ
750 図
752 eNB
752' セル
754 eNB
754' セル
760 UE
770 UE
790 図
800 システム
810 BM-SC
820 eNB
830 UE
840 ビデオサーバ
850 ユーザサービス記述(USD)
860 プレイリストファイル
900 システム
910 eNB
920 UE
930 セル
940 ユーザサービス記述(USD)
950 プレイリストファイル
960 プレイリストファイル更新
1000 システム
1000' システム
1010 BM-SC
1020 eNB
1030 UE
1040 ビデオサーバ
1050 オーディオサーバ
1060 ユーザサービス記述(USD)
1070 第1のメディアプレイリストファイル
1080 第2のメディアプレイリストファイル
1100 フローチャート
1200 フローチャート
1300 フローチャート
1400 フローチャート
1500 フローチャート
1600 概念データフロー図
1602 装置
1602' 装置
1604 受信モジュール
1606 生成モジュール
1608 記憶モジュール
1610 アクセスモジュール
1612 送信モジュール
1614 判定モジュール
1616 識別モジュール
1618 データ
1620 データ
1622 データ
1624 データ
1626 データ
1628 データ
1630 データ
1632 データ
1634 データ
1636 データ
1638 データ
1640 データ
1642 データ
1650 eNB
1704 プロセッサ
1706 コンピュータ可読媒体/メモリ
1710 トランシーバ
1714 処理システム
1720 アンテナ
1724 バス

Claims (23)

1. ワイヤレス通信のための方法であって、
   ユーザ機器(UE)によって、マルチメディアブロードキャストマルチキャストサービスに関連するユーザサービスディスカバリ手順の一部としてユーザサービス記述(USD)を受信するステップであって、前記USDは、メディアコンテンツにアクセスするための複数のユニフォームリソース識別子(URI)を生成するためのテンプレートを識別するテンプレート情報と、前記メディアコンテンツの長さを示す前記USDとを含む、ステップと、 前記UEによって、前記メディアコンテンツの前記長さに少なくとも部分的に基づいて、プレイリストファイルに対するサーバ提供の更新がないことを判定するステップであって、前記プレイリストファイルは、前記メディアコンテンツの第1の部分にアクセスするための少なくとも前記複数のURIの第1のURIを含む、ステップと、
   プレイリストファイルに対するサーバ提供の更新がないとの判定に応答して、前記UEによって、前記テンプレートに基づいて、前記メディアコンテンツの1つまたは複数の次の部分にアクセスするための前記複数のURIのうちの1つまたは複数の次のURIを生成するステップと、
   前記UEによって、前記1つまたは複数の次のURIを前記プレイリストファイル内に記憶するステップと
   を含む、方法。
2. 前記UEのハイパーテキスト転送プロトコル(HTTP)ライブストリーミング(HLS)クライアントに前記プレイリストファイルを提供するステップをさらに含み、
   前記HLSクライアントは、前記1つまたは複数の次のURIを変更せずに前記メディアコンテンツの前記1つまたは複数の次の部分にアクセスするのに前記プレイリストファイルを使用する
   請求項1に記載の方法。
3. 前記HLSクライアントは、前記プレイリストファイルを使用して前記メディアコンテンツの前記1つまたは複数の次の部分にアクセスするアクセスモジュールを含む、請求項2に記載の方法。
4. 生成する前記ステップおよび記憶する前記ステップは、前記UEのミドルウェアによって実行され、
   前記ミドルウェアは、前記プレイリストファイルを前記HLSクライアントに提供する
   請求項2に記載の方法。
5. 前記プレイリストファイル内に記憶された前記複数のURIのうちの前記1つまたは複数の次のURIを使用して前記メディアコンテンツの前記1つまたは複数の次の部分にアクセスするステップ
   をさらに含む、請求項1に記載の方法。
6. ユニキャストサービスを介して前記メディアコンテンツの前記1つまたは複数の次の部分にアクセスするステップ
   を含む、請求項1に記載の方法。
7. 前記テンプレートは、前記複数のURIに関連するスケジュールを識別し、
   前記1つまたは複数の次のURIは、前記スケジュールに基づいて生成される
   請求項1に記載の方法。
8. 前記テンプレートは、前記複数のURIの各URIの静的部分および前記複数のURIの各URIの動的部分を識別し、前記動的部分は、前記複数のURIのURIごとに異なり、
   前記1つまたは複数の次のURIは、それぞれ、前記静的部分および前記動的部分を含む
   請求項1に記載の方法。
9. ハイパーテキスト転送プロトコル(HTTP)ライブストリーミング(HLS)プロトコルに関連するマスタプレイリストファイルを受信するステップと、
   前記プレイリストファイルを生成するステップであって、前記プレイリストファイルは、前記HLSプロトコルに関連するメディアプレイリストファイルである、生成するステップと、
   前記メディアプレイリストファイルにアクセスするためのプレイリストURIを前記マスタプレイリストファイル内に記憶するステップと
   をさらに含む、請求項1に記載の方法。
10. 前記プレイリストファイルは、
    前記メディアコンテンツの前記1つまたは複数の部分の持続時間、
    前記プレイリストファイルに関連するプロトコルのバージョン、
    前記プレイリストファイルに関連する開始メディアシーケンス識別子、または、
    その任意の組合せ
    を識別するプレイリスト情報を含む、請求項1に記載の方法。
11. 前記メディアコンテンツのメディアタイプを記述するメディアタイプ情報を受信するステップと、
    前記メディアタイプ情報に基づいて、複数のプレイリストファイルから前記プレイリストファイルを識別するステップとをさらに含み、
    前記1つまたは複数の次のURIは、前記メディアコンテンツの前記メディアタイプに基づいて前記プレイリストファイル内に記憶される
    請求項1に記載の方法。
12. 前記メディアコンテンツに関連する言語を識別する言語情報を受信するステップと、
    前記言語情報に基づいて、複数のプレイリストファイルから前記プレイリストファイルを識別するステップとをさらに含み、
    前記1つまたは複数の次のURIは、前記メディアコンテンツに関連する前記言語に基づいて前記プレイリストファイル内に記憶される
    請求項1に記載の方法。
13. ワイヤレス通信のためのユーザ機器であって、
    マルチメディアブロードキャストマルチキャストサービスに関連するユーザサービスディスカバリ手順の一部としてユーザサービス記述(USD)を受信するための手段であって、前記USDは、メディアコンテンツにアクセスするための複数のユニフォームリソース識別子(URI)を生成するためのテンプレートを識別するテンプレート情報と、前記メディアコンテンツの長さを示す前記USDとを含む、手段と、
    前記メディアコンテンツの前記長さに少なくとも部分的に基づいて、プレイリストファイルに対するサーバ提供の更新がないことを判定するための手段であって、前記プレイリストファイルは、前記メディアコンテンツの第1の部分にアクセスするための少なくとも前記複数のURIの第1のURIを含む、手段と、
    プレイリストファイルに対するサーバ提供の更新がないとの判定に応答して、前記テンプレートに基づいて、前記メディアコンテンツの1つまたは複数の次の部分にアクセスするための前記複数のURIのうちの1つまたは複数の次のURIを生成するための手段と、
    前記1つまたは複数の次のURIを前記プレイリストファイル内に記憶するための手段と、
    前記ユーザ機器のハイパーテキスト転送プロトコル(HTTP)ライブストリーミング(HLS)クライアントに前記プレイリストファイルを提供するための手段とを含み、
    前記HLSクライアントは、前記1つまたは複数の次のURIを変更せずに前記メディアコンテンツの前記1つまたは複数の次の部分にアクセスするのに前記プレイリストファイルを使用するように構成される、ユーザ機器。
14. 前記HLSクライアントは、前記プレイリストファイル内に記憶された前記1つまたは複数の次のURIを使用して前記メディアコンテンツの前記1つまたは複数の次の部分にアクセスするように構成されたモジュールを含む、請求項13に記載のユーザ機器。
15. 前記HLSクライアントに前記プレイリストファイルを提供するための前記手段は、前記HLSクライアントに前記プレイリストファイルを提供するように構成されたミドルウェアを含む、請求項13に記載のユーザ機器。
16. ワイヤレス通信のためのユーザ機器であって、
    メモリと、
    前記メモリに結合され、
    マルチメディアブロードキャストマルチキャストサービスに関連するユーザサービスディスカバリ手順の一部としてユーザサービス記述(USD)を受信することであって、前記USDは、メディアコンテンツにアクセスするための複数のユニフォームリソース識別子(URI)を生成するためのテンプレートを識別するテンプレート情報と、前記メディアコンテンツの長さを示す前記USDとを含む、ことと、
    前記メディアコンテンツの前記長さに少なくとも部分的に基づいて、プレイリストファイルに対するサーバ提供の更新がないことを判定することであって、前記プレイリストファイルは、前記メディアコンテンツの第1の部分にアクセスするための少なくとも前記複数のURIの第1のURIを含む、ことと、
    前記テンプレートに基づいて、前記メディアコンテンツの1つまたは複数の次の部分にアクセスするための前記複数のURIのうちの1つまたは複数の次のURIを生成することと、
    前記1つまたは複数の次のURIを前記プレイリストファイル内に記憶することと
    を行うように構成された少なくとも1つのプロセッサと
    を含む、ユーザ機器。
17. 前記少なくとも1つのプロセッサは、
    前記ユーザ機器のハイパーテキスト転送プロトコル(HTTP)ライブストリーミング(HLS)クライアントに前記プレイリストファイルを提供するようにさらに構成され、
    前記HLSクライアントは、前記メディアコンテンツの前記1つまたは複数の次の部分にアクセスするのに前記プレイリストファイル内に記憶された前記1つまたは複数の次のURIを使用するように構成される
    請求項16に記載のユーザ機器。
18. 前記HLSクライアントは、前記プレイリストファイル内に記憶された前記1つまたは複数の次のURIを使用して前記メディアコンテンツの前記1つまたは複数の次の部分にアクセスするように構成されたアクセスモジュールを含む、請求項17に記載のユーザ機器。
19. 前記生成および前記記憶は、前記ユーザ機器のミドルウェアによって実行され、
    前記ミドルウェアは、前記プレイリストファイルを前記HLSクライアントに提供するように構成される
    請求項17に記載のユーザ機器。
20. ワイヤレス通信のためのコンピュータ実行可能コードを記憶した非一時的コンピュータ可読媒体であって、
    ユーザ機器によって、マルチメディアブロードキャストマルチキャストサービスに関連するユーザサービスディスカバリ手順の一部としてユーザサービス記述(USD)を受信することであって、前記USDは、メディアコンテンツにアクセスするための複数のユニフォームリソース識別子(URI)を生成するためのテンプレートを識別するテンプレート情報と、前記メディアコンテンツの長さを示す前記USDとを含む、ことと、
    前記ユーザ機器によって、前記メディアコンテンツの前記長さに少なくとも部分的に基づいて、プレイリストファイルに対するサーバ提供の更新がないことを判定することであって、前記プレイリストファイルは、前記メディアコンテンツの第1の部分にアクセスするための少なくとも前記複数のURIの第1のURIを含む、ことと、
    プレイリストファイルに対するサーバ提供の更新がないとの判定に応答して、前記ユーザ機器によって、前記テンプレートに基づいて、前記メディアコンテンツの1つまたは複数の次の部分にアクセスするための前記複数のURIのうちの1つまたは複数の次のURIを生成することと、
    前記ユーザ機器によって、前記1つまたは複数の次のURIをプレイリストファイル内に記憶することと
    を行うためのコードを含む、非一時的コンピュータ可読媒体。
21. 前記ユーザ機器のハイパーテキスト転送プロトコル(HTTP)ライブストリーミング(HLS)クライアントに前記プレイリストファイルを提供することと、
    前記HLSクライアントによって、前記プレイリストファイル内に記憶された前記1つまたは複数の次のURIを変更せずに前記メディアコンテンツの前記1つまたは複数の次の部分にアクセスすることと
    を行うためのコードをさらに含む、請求項20に記載の非一時的コンピュータ可読媒体。
22. 前記HLSクライアントは、前記プレイリストファイルを使用して前記メディアコンテンツの前記1つまたは複数の次の部分にアクセスするアクセスモジュールを含む、請求項21に記載の非一時的コンピュータ可読媒体。
23. 生成および記憶は、前記ユーザ機器のミドルウェアによって実行され、
    前記ミドルウェアは、前記プレイリストファイルを前記HLSクライアントに提供する
    請求項21に記載の非一時的コンピュータ可読媒体。