(57)【要約】  様々な実施形態のシステム、方法、およびデバイスは、修正されたセグメント利用可能時間をデバイスが使用することを可能にする。様々な実施形態では、セグメント利用可能性タイムラインを修正するために、ブロードキャストマルチメディアサービスセンター(BMSC)サーバが有効化され得る。様々な実施形態では、セグメント利用可能時間の調整は、受信機デバイスのサービスレイヤにおいて行われ得る。様々な実施形態では、セグメント利用可能時間の調整は、受信機デバイス上のクライアントアプリケーションによって行われ得る。
2018514098.tif 000002
【特許請求の範囲】
【請求項１】
セグメント利用可能性タイムラインを修正するための方法であって、
デバイスにおいてセグメント利用可能性タイムラインを受信するステップと、
前記デバイスにおいてファイル配信テーブル(FDT)パケットを受信するステップであって、前記FDTパケットはFDTタイムスタンプを含む、ステップと、
前記デバイスにおいてFDT到着時間を決定するステップと、
前記FDT到着時間および前記FDTタイムスタンプに少なくとも部分的に基づいて、前記デバイスにおいて実際の利用可能開始時間を決定するステップと、
前記決定された実際の利用可能開始時間に少なくとも部分的に基づいて、前記セグメント利用可能性タイムラインの開始時間をシフトするステップと
を含む方法。
【請求項２】
前記デバイスにおいて受信されるときの前記セグメント利用可能性タイムラインの前記開始時間は、推定されたワーストケース遅延に少なくとも部分的に基づいた開始時間であり、
前記FDTタイムスタンプは、前記FDTパケットの送信時間+前記推定されたワーストケース遅延であり、
前記FDT到着時間および前記FDTタイムスタンプに少なくとも部分的に基づいて、前記デバイスにおける実際の利用可能開始時間を決定するステップは、前記推定されたワーストケース遅延+前記FDTタイムスタンプに少なくとも部分的に基づいて、実際の利用可能開始時間を前記開始時間として決定するステップを含む、請求項1に記載の方法。
【請求項３】
前記FDTタイムスタンプは、前記FDTパケットを送るデバイスによって決定されるオフセット時間であり、
前記FDT到着時間および前記FDTタイムスタンプに少なくとも部分的に基づいて、前記デバイスにおける実際の利用可能開始時間を決定するステップは、実際の利用可能開始時間を、前記FDT到着時間-前記FDTタイムスタンプとして決定するステップを含む、請求項1に記載の方法。
【請求項４】
前記FDTパケットを送るデバイスによって決定される前記オフセット時間は、最初の利用可能開始時間と、前記FDTパケットを送る前記デバイスによる前記FDTパケットの送信時間との間の時間である、請求項3に記載の方法。
【請求項５】
前記デバイスにおいて受信されるときの前記セグメント利用可能性タイムラインの前記開始時間は、初期開始時間であり、
前記FDTタイムスタンプは、前記FDTパケットの送信時間と、送信遅延と、処理遅延とを含み、
前記FDT到着時間および前記FDTタイムスタンプに少なくとも部分的に基づいて、前記デバイスにおける実際の利用可能開始時間を決定するステップは、前記FDTパケットの前記送信時間、前記送信遅延、および前記処理遅延に少なくとも部分的に基づいて、実際の利用可能開始時間を前記開始時間として決定するステップを含む、請求項1に記載の方法。
【請求項６】
セグメント継続期間を決定するステップをさらに含み、前記FDTパケットの前記送信時間、前記送信遅延、および前記処理遅延に少なくとも部分的に基づいて、実際の利用可能開始時間を前記開始時間として決定するステップは、前記FDTパケットの前記送信時間、前記送信遅延、前記処理遅延、および前記セグメント継続期間に少なくとも部分的に基づいて、実際の利用可能開始時間を前記開始時間として決定するステップを含む、請求項5に記載の方法。
【請求項７】
前記FDTタイムスタンプは前記FDTパケット内に示される、請求項6に記載の方法。
【請求項８】
前記FDTタイムスタンプはALCパケットヘッダの送信側現在時間フィールド内に示される、請求項7に記載の方法。
【請求項９】
前記FDTタイムスタンプはALCまたはFDT拡張ヘッダ内に示される、請求項5に記載の方法。
【請求項１０】
ネットワークジッタ推定値を決定するステップをさらに含み、前記決定された実際の利用可能開始時間に少なくとも部分的に基づいて、前記セグメント利用可能性タイムラインの開始時間をシフトするステップは、前記決定された実際の利用可能開始時間および前記決定されたネットワークジッタ推定値に少なくとも部分的に基づいて、前記セグメント利用可能性タイムラインの開始時間をシフトするステップを含む、請求項1に記載の方法。
【請求項１１】
前記決定された実際の利用可能開始時間および前記決定されたネットワークジッタ推定値に少なくとも部分的に基づいて、前記セグメント利用可能性タイムラインの開始時間をシフトするステップは、前記決定された実際の利用可能開始時間に前記決定されたネットワークジッタ推定値を加えるステップを含む、請求項10に記載の方法。
【請求項１２】
前記セグメント利用可能性タイムラインは、Dynamic Adaptive Streaming Over Hypertext Transfer Protocol(DASH) Media Presentation Description(MPD)である、請求項1に記載の方法。
【請求項１３】
前記デバイスは受信機デバイスまたはブロードキャストマルチメディアサービスセンター(BMSC)サーバである、請求項1に記載の方法。
【請求項１４】
ファイル配信テーブル(FDT)パケットを送信するための方法であって、
前記FDTパケットの送信時間を決定するステップと、
前記FDTパケット内にFDTタイムスタンプを示すステップであって、前記FDTタイムスタンプは、前記決定された送信時間に少なくとも部分的に基づく、ステップと、
前記決定された送信時間に前記FDTパケットを送信するステップと
を含む方法。
【請求項１５】
前記FDTパケットの送信に対するワーストケース遅延を推定するステップをさらに含み、前記FDTタイムスタンプは、前記FDTパケットの前記送信時間+前記推定されたワーストケース遅延である、請求項14に記載の方法。
【請求項１６】
前記FDTタイムスタンプはオフセット時間である、請求項14に記載の方法。
【請求項１７】
前記オフセット時間は、最初の利用可能開始時間と前記FDTパケットの前記送信時間との間の時間である、請求項16に記載の方法。
【請求項１８】
前記FDTタイムスタンプは、前記FDTパケットの送信時間、送信遅延、および処理遅延である、請求項14に記載の方法。
【請求項１９】
前記FDTタイムスタンプはALCパケットヘッダの送信側現在時間フィールド内に示される、請求項18に記載の方法。
【請求項２０】
前記FDTタイムスタンプはALCまたはFDT拡張ヘッダ内に示される、請求項18に記載の方法。
【請求項２１】
Dynamic Adaptive Streaming Over Hypertext Transfer Protocol(DASH) Media Presentation Description(MPD)をシフトし、前記MPDを送るステップをさらに含む、請求項14に記載の方法。
【請求項２２】
動作を実行するようにプロセッサ実行可能命令で構成されたプロセッサを備え、前記動作は、
セグメント利用可能性タイムラインを受信するステップと、
ファイル配信テーブル(FDT)パケットを受信するステップであって、前記FDTパケットはFDTタイムスタンプを含む、ステップと、
FDT到着時間を決定するステップと、
前記FDT到着時間および前記FDTタイムスタンプに少なくとも部分的に基づいて、実際の利用可能開始時間を決定するステップと、
前記決定された実際の利用可能開始時間に少なくとも部分的に基づいて、前記セグメント利用可能性タイムラインの開始時間をシフトするステップと
を含むデバイス。
【請求項２３】
前記デバイスにおいて受信されるときの前記セグメント利用可能性タイムラインの前記開始時間は、推定されたワーストケース遅延に少なくとも部分的に基づいた開始時間であり、
前記FDTタイムスタンプは、前記FDTパケットの送信時間+前記推定されたワーストケース遅延であり、
前記プロセッサは、前記FDT到着時間および前記FDTタイムスタンプに少なくとも部分的に基づいて、実際の利用可能開始時間を決定するステップが、前記推定されたワーストケース遅延+前記FDTタイムスタンプに少なくとも部分的に基づいて、実際の利用可能開始時間を前記開始時間として決定するステップを含むような動作を実施するように、プロセッサ実行可能命令を用いて構成される、請求項22に記載のデバイス。
【請求項２４】
前記FDTタイムスタンプは、前記FDTパケットを送るデバイスによって決定されるオフセット時間であり、
前記プロセッサは、前記FDT到着時間および前記FDTタイムスタンプに少なくとも部分的に基づいて実際の利用可能開始時間を決定するステップが、実際の利用可能開始時間を、前記FDT到着時間-前記FDTタイムスタンプとして決定するステップを含むような動作を実施するように、プロセッサ実行可能命令を用いて構成される、請求項22に記載のデバイス。
【請求項２５】
前記デバイスにおいて受信されるときの前記セグメント利用可能性タイムラインの前記開始時間は、初期開始時間であり、
前記FDTタイムスタンプは、前記FDTパケットの送信時間と、送信遅延と、処理遅延とを含み、
前記プロセッサは、前記FDT到着時間および前記FDTタイムスタンプに少なくとも部分的に基づいて実際の利用可能開始時間を決定するステップが、前記FDTパケットの前記送信時間、前記送信遅延、および前記処理遅延に少なくとも部分的に基づいて、実際の利用可能開始時間を前記開始時間として決定するステップを含むような動作を実施するように、プロセッサ実行可能命令を用いて構成される、請求項22に記載のデバイス。
【請求項２６】
前記プロセッサは、ネットワークジッタ推定値を決定するステップをさらに含む動作を実施するように、プロセッサ実行可能命令を用いて構成され、
前記プロセッサは、前記決定された実際の利用可能開始時間に少なくとも部分的に基づいて前記セグメント利用可能性タイムラインの開始時間をシフトするステップが、前記決定された実際の利用可能開始時間および前記決定されたネットワークジッタ推定値に少なくとも部分的に基づいて、前記セグメント利用可能性タイムラインの開始時間をシフトするステップを含むような動作を実施するように、プロセッサ実行可能命令を用いて構成される、請求項22に記載のデバイス。
【請求項２７】
前記セグメント利用可能性タイムラインは、Dynamic Adaptive Streaming Over Hypertext Transfer Protocol(DASH) Media Presentation Description(MPD)である、請求項22に記載のデバイス。
【請求項２８】
動作を実行するようにプロセッサ実行可能命令で構成されたプロセッサを備え、前記動作は、
ファイル配信テーブル(FDT)パケットの送信時間を決定するステップと、
前記FDTパケット内にFDTタイムスタンプを示すステップであって、前記FDTタイムスタンプは、前記決定された送信時間に少なくとも部分的に基づく、ステップと、
前記決定された送信時間に前記FDTパケットを送信するステップと
を含むデバイス。
【請求項２９】
前記プロセッサは、前記FDTパケットの送信に対するワーストケース遅延を推定するステップをさらに含む動作を実施するように、プロセッサ実行可能命令を用いて構成され、
前記プロセッサは、前記FDTタイムスタンプが前記FDTパケットの前記送信時間+前記推定されたワーストケース遅延となるような動作を実施するように、プロセッサ実行可能命令を用いて構成される、請求項28に記載のデバイス。
【請求項３０】
前記プロセッサは、Dynamic Adaptive Streaming Over Hypertext Transfer Protocol(DASH) Media Presentation Description(MPD)をシフトし、前記MPDを送るステップをさらに含む動作を実施するように、プロセッサ実行可能命令を用いて構成される、請求項22に記載のデバイス。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願
本出願は、その内容全体が参照により本明細書に組み込まれる、2015年2月23日に出願された「Availability Start Time Adjustment By Device For DASH Over Broadcast」という名称の米国仮特許出願第62/119,353号の優先権を主張する。
【背景技術】
【０００２】
ハイパーテキスト転送プロトコル(HTTP)ストリーミングは現在、インターネットを通じてコンテンツを配信する最も一般的な方法である。ライブイベントでは、コンテンツは、不変の期間のセグメントを通じて徐々に利用可能にされる。セグメントの利用可能性は、各々の連続するセグメントがHTTPサーバにおいていつ利用可能になるかを示す、タイムラインに従う。
【０００３】
Dynamic Adaptive Streaming Over Hypertext Transfer Protocol(DASH)は、HTTPストリーミングを実装する規格である。DASHは、Media Presentation Description(MPD)においてセグメントの利用可能性を告知する。MPDは、セグメント、セグメントが利用可能である時間、およびセグメントのサイズを告知する、セグメント利用可能性タイムラインである。
【０００４】
現在のシステムでは、MPDは、オーバージエア(OTA)配信を介して受信機デバイスに提供される。提供されるMPDでは、セグメント利用可能時間は、セグメントのエンコーダ出力と受信機デバイス受信との間に生じると推定される最大経路遅延を考慮するように選択されてもよい。しかしながら、ネットワーク内のすべての受信機デバイスが最大経路遅延を経験するわけではない。したがって、現在のMPDでセグメント利用可能時間を使用する、より低遅延のエリア内の受信機デバイスは、より低遅延のエリア内の受信機デバイスによって経験される実際の遅延よりも最大経路遅延の方が長いため、必要以上に長いチャネル取得およびスイッチ時間を経験し得る。
【発明の概要】
【課題を解決するための手段】
【０００５】
様々な実施形態のシステム、方法、およびデバイスは、修正されたセグメント利用可能時間をデバイスが使用することを可能にする。様々な実施形態では、セグメント利用可能性タイムラインを修正するために、ブロードキャストマルチメディアサービスセンター(BMSC)サーバが有効化され得る。様々な実施形態では、セグメント利用可能時間の調整は、受信機デバイスのサービスレイヤにおいて行われ得る。様々な実施形態では、セグメント利用可能時間の調整は、受信機デバイス上のクライアントアプリケーションによって行われ得る。
【０００６】
様々な実施形態は、デバイスにおいてセグメント利用可能性タイムラインを受信するステップと、デバイスにおいてファイル配信テーブル(FDT)パケットを受信するステップであって、FDTパケットはFDTタイムスタンプを含む、ステップと、デバイスにおいてFDT到着時間を決定するステップと、FDT到着時間およびFDTタイムスタンプに少なくとも部分的に基づいて、デバイスにおいて実際の利用可能開始時間を決定するステップと、決定された実際の利用可能開始時間に少なくとも部分的に基づいて、セグメント利用可能性タイムラインの開始時間をシフトするステップとを含み得る。
【０００７】
様々な実施形態は、FDTパケットの送信時間を決定するステップと、FDTパケット内にFDTタイムスタンプを示すステップであって、FDTタイムスタンプは、決定された送信時間に少なくとも部分的に基づく、ステップと、決定された送信時間にFDTパケットを送信するステップとを含み得る。
【０００８】
さらなる実施形態は、上で要約された方法の動作を実行するようにプロセッサ実行可能命令を用いて構成されたデバイスを含む。さらなる態様は、上で要約した方法の機能を実施するための手段を含むデバイスを含む。さらなる実施形態は、上で要約した方法の動作をデバイスプロセッサに実施させるように構成されたプロセッサ実行可能命令を記憶した非一時的プロセッサ可読記憶媒体を含む。
【０００９】
本明細書に組み込まれ、本明細書の一部を構成する添付の図面は、本発明の例示的な実施形態を示し、上記の一般的な説明および以下の発明を実施するための形態とともに、本発明の特徴について説明するのに役立つ。
【図面の簡単な説明】
【００１０】
【図１】様々な実施形態とともに使用するのに適したネットワークの通信システムのブロック図である。
【図２】ある実施形態による、受信機デバイスのアーキテクチャを示すブロック図である。
【図３Ａ】ある実施形態による、セグメント配信経路とMPDの配信調整との関係を示す図である。
【図３Ｂ】別の実施形態による、セグメント配信経路とMPDの配信調整との関係を示す図である。
【図４】一実施形態による、ネットワークの種々の部における配信経路遅延間の関係を示す図である。
【図５】一実施形態による利用可能性タイムライン、MPD利用可能開始時間、送信時間、および到達時間を示す図である。
【図６Ａ】セグメント利用可能性タイムラインを修正するためのある実施形態の方法を示すプロセスフロー図である。
【図６Ｂ】遅延調整メッセージを生成するためのある実施形態の方法を示すプロセスフロー図である。
【図７】一実施形態による非同期階層符号化(ALC)パケットのデータ構造図である。
【図８】一実施形態によるMPC利用可能開始時間、送信時間、到着時間、およびオフセット時間を示す図である。
【図９Ａ】セグメント利用可能性タイムラインを修正するための別の実施形態の方法を示すプロセスフロー図である。
【図９Ｂ】遅延調整メッセージを生成するための別の実施形態の方法を示すプロセスフロー図である。
【図１０Ａ】ファイル配信テーブル(FDT)内のFDTタイムスタンプを指示するための実施形態の方法を示すプロセスフロー図である。
【図１０Ｂ】FDT内のFDTタイムスタンプを指示するための別の実施形態の方法を示すプロセスフロー図である。
【図１０Ｃ】FDT内のFDTタイムスタンプを指示するための第3の実施形態の方法を示すプロセスフロー図である。
【図１１】遅延調整メッセージに基づいて利用可能時間を調整するためのある実施形態の方法を示すプロセスフロー図である。
【図１２】様々な実施形態とともに使用するのに適した例示的なモバイルデバイスの構成要素図である。
【図１３】様々な実施形態との使用に適した例示的なサーバの構成要素図である。
【発明を実施するための形態】
【００１１】
添付の図面を参照しながら、様々な実施形態について詳細に説明する。可能な場合はいつでも、同じまた同様の部分を指すために、図面全体を通して同じ参照番号が使用される。具体的な例および実装形態への言及は説明のためであり、本発明の範囲または特許請求の範囲を限定するものではない。
【００１２】
「例示的な」という語は、本明細書において、例、実例、または例証としての役割を果たすことを意味するために使用される。本明細書で「例示的」として説明するいかなる実装形態も、必ずしも他の実装形態よりも好ましいか、または有利であると解釈されるべきではない。
【００１３】
本明細書で使用される場合、「モバイルデバイス」および「受信機デバイス」という用語は、携帯電話、スマートフォン、個人用マルチメディアプレーヤーまたはモバイルマルチメディアプレーヤー、携帯情報端末(PDA)、ラップトップコンピュータ、タブレットコンピュータ、スマートブック、パームトップコンピュータ、ワイヤレス電子メール受信機、マルチメディアインターネット対応携帯電話、ワイヤレスゲームコントローラ、および、MPDを受信しMPDをDASHクライアントに対して利用可能にするためのプログラム可能プロセッサとメモリと回路とを含む同様の個人用電子デバイスの、いずれか1つまたはすべてを指すように、本明細書において交換可能に使用される。
【００１４】
本明細書では、マスタ交換サーバ、ウェブサーバ、メールサーバ、ドキュメントサーバ、コンテンツサーバ、または任意の他のタイプのサーバなどのサーバとして機能することが可能な任意のコンピューティングデバイスを指す「サーバ」という用語を使用して、様々な実施形態について説明する。サーバは、専用コンピューティングデバイスであっても、または(たとえば、コンピューティングデバイスをサーバとして動作させることができるアプリケーションを動作させる)サーバモジュールを含むコンピューティングデバイスであってもよい。サーバモジュール(たとえば、サーバアプリケーション)は、全機能搭載サーバモジュールであっても、または受信機デバイス上の動的データベース間の同期サービスを実現するように構成されたライトサーバモジュールもしくは2次サーバモジュール(たとえば、ライトサーバアプリケーションまたは2次サーバアプリケーション)であってもよい。ライトサーバまたは2次サーバは、モバイルデバイス上で実施することができ、それによって本明細書において説明する機能を実現するのに必要な程度にのみ受信機デバイスをインターネットサーバ(たとえば、エンタープライズeメールサーバ)として機能させるのを可能にするサーバ型機能のスリムダウンバージョンであってもよい。
【００１５】
Dynamic Adaptive Streaming Over Hypertext Transfer Protocol(DASH)は、HTTPストリーミングを実装する規格である。DASHは、Media Presentation Description(MPD)においてセグメントの利用可能性を告知する。MPDは、セグメント、セグメントが利用可能である時間、およびセグメントのサイズを告知する、セグメント利用可能性タイムラインである。現在のシステムでは、MPDは、Over-the-Air(OTA)配信を介して受信機デバイスに提供される。第3世代パートナーシッププロジェクト(3GPP)は、Long Term Evolution(LTE)(すなわち、evolved Multimedia Broadcast Multicast Services(eMBMS))を通じたブロードキャスト使用してHTTPストリーミングを提供するために使用されるべき方法として、ダウンロード配信を通じたDASHを標準化した。
【００１６】
異なるアプリケーション/クライアント、ミドルウェア、セグメント利用可能性タイムライン、無線技術、および転送プロトコルの様々な例、特に、DASHクライアント、マルチキャストサービスデバイスクライアント、MPD、eMBMS、およびHTTPが本明細書で論じられる。DASHクライアント、マルチキャストサービスデバイスクライアント、MPD、eMBMS、およびHTTPの議論は、様々な実施形態の態様をより良好に示すための例としてのみ与えられ、いかなる方法でも様々な実施形態を限定することは意図されない。他のアプリケーション/クライアント、ミドルウェア、セグメント利用可能性タイムライン、無線技術、および転送プロトコルが、様々な実施形態とともに使用されてもよく、他のアプリケーション/クライアント、ミドルウェア、セグメント利用可能性タイムライン、無線技術、および転送プロトコルが、本発明の趣旨または範囲から逸脱することなく、様々な例において置換されてもよい。たとえば、様々な実施形態は、開始時間を有し得るHLSインデックスファイルなどの他のセグメント利用可能性タイムラインを使用し得る、HTTPライブストリーミング(「HLS」)などの1つまたは複数の他の適応ストリーミングプロトコルに従ってフォーマットされたセグメントを使用し得る。
【００１７】
様々な実施形態は、デバイス上で使用するための、データストリーム中のデータセグメントの利用可能性(「セグメント利用可能性」)の遅延を、たとえば、受信機デバイス、ブロードキャストマルチメディアサービスセンター(BMSC)サーバなどのデバイスが考慮することを可能にする。ある実施形態では、受信機デバイスは、受信されたセグメントが受信機デバイス上のアプリケーション/クライアント(たとえば、メディアプレーヤーアプリケーションのためのセグメントを取り出すDASHクライアント)に対して利用可能になる実際の時間に基づいて修正されたMPDの列挙を生成するように、ネットワークから受信されるセグメント利用可能性タイムライン(たとえば、BMSCサーバからOTAで受信されるMPD)中の利用可能時間を調整することができる。別の実施形態では、BMSCは、受信されたセグメントがBMSCサーバからの送信に対して利用可能になる実際の時間に基づいて修正されたMPDの列挙を生成するように、ネットワークから受信されるセグメント利用可能性タイムライン(たとえば、エンコーダおよび/またはセグメンタからOTAで受信されるMPD)中の利用可能時間を調整することができる。
【００１８】
様々な実施形態では、受信機デバイス、BMSCサーバなどのデバイスは、エンコーダによって設定された初期開始時間(AST1)またはワーストケース開始時間(AST3)にセグメントの利用可能開始時間(AST)を設定してMPDを受信し得る。ワーストケース開始時間は、ネットワークを介してパケットをデバイスへ送信することに対する推定されたワーストケース遅延(delayMAX)に少なくとも部分的に基づいて選択されたMPDにおいて識別されたセグメントに対する開始時間となり得る。デバイスは、ファイル配信テーブル(FDT)パケットを受信し、そのパケットのFDT到着時間(tnr)を決定し得る。様々な実施形態では、FDTパケットは、FDTパケット送信時間(tnt)に送信遅延(Δ1)と処理遅延(Δ2)とをプラスした時間を反映する、送信デバイス(たとえば、受信機デバイスにパケットを送るBMSCサーバ、BMSCサーバにパケットを送るエンコーダなど)からのFDTパケットに示されたタイムスタンプを含み得る。タイムスタンプは、FDTパケット送信時間(tnt)+遅延(Δ1およびΔ2)を示す単一値(たとえば、(Δ1+Δ2-tnt)に等しい値)であってもよく、または3つの別々の値(たとえば、tnt、Δ1、およびΔ2)であってもよい。MPDがワーストケース遅延開始時間(AST3)を示すとき、FDTパケットの送信時間tntは、MPD開始時間におけるシフトを考慮するために、ワーストケース遅延だけシフトされ得る(たとえば、tnt=tnt+delayMAX)。デバイスは、ネットワークジッタ推定の実際の利用可能開始時間(AST2)を、MPDに示されたセグメントの利用可能開始時間(たとえば、AST1またはAST3)+送信遅延(Δ1)+処理遅延(Δ2)+決定されたFDT到着時間(tnr)-FDTパケット送信時間(tnt)+セグメント継続期間(D)として実施する手段を決定し得る。デバイスは、MPD開始時間(AvailabilityStartTime)を実際の利用可能開始時間(AST2)+決定されたネットワークジッタ推定値にシフトさせ得る。このようにして、FDTパケットのタイムスタンプは、セグメントの完全な到着を待機する必要なしに、MPDの開始時間をシフトさせるために使用され得る。
【００１９】
様々な実施形態では、受信機デバイス、BMSCサーバなどのデバイスは、任意の開始時間にセグメントの利用可能開始時間(AST)を設定してMPDを受信し得る。デバイスは、ファイル配信テーブル(FDT)パケットを受信し、そのパケットのFDT到着時間(t2)を決定し得る。様々な実施形態では、FDTパケットは、送信デバイスが最初に受信したMPDに示された利用可能開始時間(AST1)からのFDTパケットの送信時間(t1)のオフセット時間(PacketOffset)を反映する、送信デバイス(たとえば、受信機デバイスにパケットを送るBMSCサーバ、BMSCサーバにパケットを送るエンコーダなど)からのFDTパケットに示されたタイムスタンプ、たとえば(PacketOffset=t1-AST1)を含み得る。タイムスタンプは、FDTパケット送信時間(t1)-送信デバイスが最初に受信したMPDに示された利用可能開始時間(AST1)を示す単一値(たとえば、(t1-AST1)に等しい値)であってもよく、または2つの分離された値(たとえば、(t1)および(AST1))であってもよい。デバイスは、決定されたFDT到着時間(t2)-オフセット時間(PacketOffset)(たとえば、t1-AST1)として実際の利用可能開始時間(AST2)を決定し得る。デバイスは、MPD開始時間(AvailabilityStartTime)を実際の利用可能開始時間(AST2)+決定されたネットワークジッタ推定値にシフトさせ得る。このようにして、FDTパケットのタイムスタンプは、セグメントの完全な到着を待機する必要なしに、またデバイスによって受信されるMPD内の利用可能開始時間を生成するために使用されるいかなる遅延にも関係なく、MPDの開始時間をシフトさせるために使用され得る。
【００２０】
様々な実施形態では、シフトされたMPD開始時間を有する改善されたMPDは、受信機デバイス、BMSCサーバなどのデバイスのメモリに記憶されてもよく、またセグメントが、修正されたMPDに基づいて、シフトされたMPD開始時間にデバイスによって要求されてもよい。様々な実施形態では、受信機デバイス、BMSCサーバなどのデバイスは、遅延調整メッセージ内に、シフトされたMPD開始時間(AvailabilityStartTime)の指示を格納してもよい。遅延調整メッセージは、遅延調整を含むファイルのような、遅延調整のパラメータおよび/または指示であり得る。一実施形態では、遅延調整メッセージは、受信機デバイス上のクライアントアプリケーションなどの別のアプリケーションが、受信されたセグメントが受信機デバイス上のアプリケーション/クライアント(たとえば、メディアプレーヤーアプリケーションのためのセグメントを取り出すDASHクライアント)に対して利用可能になる実際の時間に基づいて修正されたMPDの列挙を生成するように、ネットワークから受信されるセグメント利用可能性タイムライン(たとえば、ブロードキャストマルチメディアサービスセンター(BMSC)サーバからOTAで受信されるMPD)中の利用可能時間を調整することを可能にし得る。別の実施形態では、遅延調整メッセージは、受信機デバイス上のクライアントアプリケーションなどの別のアプリケーションが、セグメント利用可能性タイムライン自体を修正することなく、受信されたセグメントが受信機デバイス上のアプリケーション/クライアント(たとえば、メディアプレーヤーアプリケーションのためのセグメントを取り出すDASHクライアント)に対して利用可能になる実際の時間に基づいて、セグメントに対する要求のタイミングを調整することを可能にし得る。
【００２１】
ある実施形態では、ネットワークジッタの推定(たとえば、ネットワークジッタ値)は、受信機デバイスに送信されるセグメント利用可能性タイムライン(たとえば、MPD)を記述するマニフェストファイル中で提供され得る。別の実施形態では、ネットワークジッタは、受信機デバイス上で事前に準備され得る(たとえば、製造の時点で受信機デバイスの非揮発性メモリに記憶され得る)。他の実施形態では、ネットワークジッタの推定は、任意のメッセージ中で、たとえばサービス告知の中で、受信機デバイスに配信され得る。ある実施形態では、ネットワークジッタの推定は、その中でMPDが配信され得るメッセージとは無関係なメッセージで受信機デバイスに配信され得る。本明細書で使用される場合、「ジッタ」は、セグメントの利用可能性タイムラインからの差として、セグメントの最早の可能な到達時間と最遅の可能な到達時間との差を指す。
【００２２】
様々な実施形態では、FDTタイムスタンプは、任意の方式でFDTに示され得る。一例として、FDTタイムスタンプは、送信側現在時間フィールド(SCTフィールド)などの標準的なALCパケットヘッダフィールド内に示され得る。別の例として、FDTタイムスタンプを渡すために、64ビットフィールドなどの拡張ヘッダがALC拡張ヘッダとして加えられ得る。さらなる例として、FDTタイムスタンプを渡すために、64ビットフィールドなどの拡張ヘッダがFDT拡張ヘッダとして加えられ得る。さらなる例として、FDTパケット送信時間(tnt)、送信遅延(Δ1)、および処理遅延(Δ2)の各値に対して1つの、3つの別個の32ビットフィールドがALC拡張ヘッダに追加され得る。別の例として、FDTパケット送信時間(tnt)、送信遅延(Δ1)および処理遅延(Δ2)の値の合計値(たとえば、tnt+Δ1+Δ2に等しい値)を示すために、単一の32ビットフィールドがALC拡張ヘッダに追加され得る。
【００２３】
様々な実施形態は、デバイスがセグメントを受信する時間など、単なるデバイス(たとえば、受信機デバイス、BMSCサーバなど)で決定された情報以外の追加情報に基づいて、セグメント利用可能性タイムラインを修正するための方法を提供する。様々な実施形態は、デバイス決定情報(たとえば、FDT到着時間)と、ネットワークによって提供される情報(たとえば、FDTタイムスタンプ)など、デバイスの外部で決定された情報の両方に基づいて、セグメント利用可能性タイムラインを修正するための方法を提供する。たとえば、様々な実施形態は、FDTパケットの決定された送信時間に少なくとも部分的に基づくFDTタイムスタンプを示すFDTパケットを送信するための方法を提供する。デバイスは、FDTタイムスタンプを示すFDTパケットを受信し、FDTパケットがいつ実際にデバイスに到着したか(たとえば、FDT到着時間)と、FDTタイムスタンプによって示されるFDTパケットの送信時間の両方を決定し得る。セグメント利用可能性タイムラインを修正する際に、デバイス決定情報(たとえば、FDT到着時間)とデバイスの外部で決定された情報(たとえば、FDTタイムスタンプ)の両方を使用することにより、結果として、デバイスは、デバイス決定情報(たとえば、FDT到着時間)のみに基づいて実際の利用可能開始時間を決定した場合と比べて、セグメント利用可能性タイムラインに対するより正確な利用可能開始時間を決定することになり得る。
【００２４】
種々のデバイスがMPD利用可能開始時間を修正する様々な例が、特に受信機デバイスおよびBMSCサーバが本明細書で説明される。受信機デバイスおよびBMSCサーバの説明は、様々な実施形態の態様をより良好に示すための例としてのみ与えられ、いかなる方法でも様々な実施形態を限定することは意図されない。他のデバイスがMPDを修正するために様々な実施形態とともに使用されてよく、また他のデバイスは、本発明の範囲から逸脱することなくMPDを修正するために、様々な例で置換されてよい。
【００２５】
図1は、様々な実施形態とともに使用するのに適したセルラーネットワークシステム100を示す。セルラーネットワークシステム100は、受信機デバイス102、1つまたは複数のセルラータワーまたは基地局104、ならびに、インターネット110に接続されたサーバ108および112のような、複数のデバイスを含み得る。受信機デバイス102は、CDMA、TDMA、GSM(登録商標)、PCS、3G、4G、LTE、または任意の他のタイプの接続を含む、1つまたは複数のセルラー接続106を介して、セルラータワーまたは基地局104とデータを交換することができる。セルラータワーまたは基地局104は、インターネット110に接続し得るルータと通信していてもよい。このようにして、セルラータワーまたは基地局104への接続、および/またはインターネット110を介して、受信機デバイス102とサーバ108および112との間でデータが交換され得る。ある実施形態では、サーバ108は、DASHクライアントを介した出力のためにMPDおよびセグメントを提供する、コンテンツプロバイダサーバまたはエンコーダであり得る。ある実施形態では、サーバ112は、エンコーダからMPDおよびセグメントの出力を受信し、受信機デバイス102へのMPDおよびセグメントのOTA送信を制御できる、ブロードキャストマルチメディアサービスセンター(BMSC)サーバであり得る。当然、本明細書で説明される受信機デバイスの特徴は、OTA送信を参照して説明され得るが、これらの特徴は、有線送信、ワイヤレス送信、または有線送信およびワイヤレス送信の組合せに関して使用され得る。したがって、OTA送信は必須ではない。
【００２６】
図2は、ある実施形態による、簡略化された受信機デバイス202のアーキテクチャを示す。受信機デバイス202は、取得、ハンドオフ、リンク維持などのような、受信機デバイス202のすべての無線の態様を管理する、モデムレイヤ208を含み得る。モデムレイヤ208は、受信されたeMBMSベアラ信号を復号し、インターネットプロトコル(IP)パケットをマルチキャストサービスデバイスクライアント(MSDC)206に配信することができる。マルチキャストサービスデバイスクライアント206は、配信されたIPパケットからセグメントを復元し、アプリケーション/DASHクライアント204のようなアプリケーション/クライアントに対してセグメントを利用可能にする、受信機デバイス202のサービスレイヤであり得る。例として、マルチキャストサービスデバイスクライアント206は、受信機デバイス202のオペレーティングシステムの一部であるサービスレイヤであり得る。マルチキャストサービスデバイスクライアント206はまた、配信されたIPパケットからMPDを復元することができる。マルチキャストサービスデバイスクライアント206は、受信機デバイスのメモリに受信されたセグメントを記憶することができる。ある実施形態では、マルチキャストサービスデバイスクライアント206は、MPDを調整して、修正されたMPDを生成し、受信機デバイスのメモリに修正されたMPDを記憶することができ、修正されたMPDをアプリケーション/DASHクライアント204に配信することができる。別の実施形態では、マルチキャストサービスデバイスクライアント206は、MPDに対する遅延調整を決定し、受信機デバイスのメモリに(たとえば、遅延調整メッセージに)MPDに対する遅延調整を記憶し、受信機デバイスのメモリにMPDを記憶することができ、MPDとMPDに対する遅延調整とをアプリケーション/DASHクライアント204に配信することができる。アプリケーション/DASHクライアント204は、DASH対応アプリケーション、および/または、(直接、および/または、メディアプレーヤーのような別のアプリケーションを介して)メディアを表示するためにDASHクライアントを起動するアプリケーションであり得る。ある実施形態では、アプリケーション/DASHクライアント204は、マルチキャストサービスデバイスクライアント206から修正されたMPDの位置(たとえば、Uniform Resource Locator(URL))を取得し、マルチキャストサービスデバイスクライアント206から修正されたMPDを要求し受信することができ、修正されたMPD中の利用可能性タイムラインごとに、マルチキャストサービスデバイスクライアント206からのセグメントを要求することができる。別の実施形態では、アプリケーション/DASHクライアント204は、マルチキャストサービスデバイスクライアント206からMPDの位置(たとえば、Uniform Resource Locator(URL))とMPDの位置(たとえば、URL)に対する遅延調整とを取得し、マルチキャストサービスデバイスクライアント206からMPDとMPDに対する遅延調整とを要求して受信し、MPDに対する遅延調整に従ってMPDを修正して修正されたMPDを生成することができ、修正されたMPD中の利用可能性タイムラインごとにマルチキャストサービスデバイスクライアント206からのセグメントを要求することができる。アプリケーション/DASHクライアント204は、マルチキャストサービスデバイスクライアント206から要求されたセグメントを受信することができ���セグメントのコンテンツを(直接、および/または、メディアプレーヤーのような別のアプリケーションを介して)レンダリングすることができる。さらなる実施形態では、MPDに対する遅延調整を決定するために使用されるマルチキャストサービスデバイスクライアント206の機能は、クライアント206に統合されてよく、クライアント206は、遅延調整を決定し、かつ/または、MPD自体を修正することができる。
【００２７】
図3Aは、ある実施形態による、セグメント配信経路に沿った、MPDのようなセグメント利用可能性タイムラインに対して行われ得る、配信調整を示す。セグメント配信経路は、エンコーダ302、BMSC 304、受信機デバイスのマルチキャストサービスデバイスクライアント306、および受信機デバイスのDASHクライアント308を含み得る。エンコーダ302は、メディアコンテンツをセグメントへと符号化し、セグメントを定期的にBMSC 304に配信することができる。たとえば、セグメントは、eMBMSゲートウェイを介して、エンコーダ302からBMSC 304に定期的に配信され得る。BMSC 304は、セグメントを受信し、ベアラを通じて(たとえば、OTAブロードキャストを介して)セグメントをブロードキャストすることができる。受信機デバイスは、モデムを介してセグメントを受信することができ、マルチキャストサービスデバイスクライアント306は、モデムを介してセグメントを受信し、セグメントを処理して(たとえば、セグメントを復号して、FECを適用して、など)受信機デバイスのDASHクライアント308に対してセグメントを利用可能にすることができる。DASHクライアント308は、セグメントを受信機デバイスのアプリケーション(たとえば、メディアプレーヤー)またはコーデックに提供して、受信機デバイスによるメディアコンテンツの出力を可能にし得る。
【００２８】
セグメントを生成することに加えて、エンコーダ302は、MPD 310を生成することができる。エンコーダにより生成されたMPD 310は、エンコーダ302によって生成された、かつ/または生成されることになるセグメント、セグメントの長さ(たとえば、サイズ)、およびセグメントの利用可能時間を列挙し得る。ある実施形態では、エンコーダにより生成されるMPD 310の中の利用可能時間は、エンコーダ302により生成されるセグメントの出力時間に対応し得る。エンコーダ302は、生成されたMPD 310をBMSC 304に提供することができる。ある実施形態では、BMSC 304は、生成されたMPD 310を受信し、あらゆるOTA配信遅延(たとえば、ネットワークジッタ)を考慮するようにセグメント利用可能性タイムラインを調整して、MPD 312を生成することができる。BMSC 304は、MPD 312を受信機デバイスに送信することができる。MPD 312は、セグメントのOTA利用可能時間に対応するセグメント利用可能時間を列挙し得る。一実施形態では、受信機デバイスはMPD 312を受信することができ、受信機デバイスのマルチキャストサービスデバイスクライアント306は、FDTタイムスタンプごとに利用可能時間を調整して、受信機デバイスにおけるセグメントに対する実際の推定利用可能時間を列挙する修正されたMPD 314を生成することができる。マルチキャストサービスデバイスクライアント306は、修正されたMPD 314をDASHクライアント308に提供することができ、DASHクライアントは、MPD中のセグメント利用可能時間を使用して、受信機デバイスの時計を使用して受信機デバイスのローカルHTTPサーバからのセグメントを要求することができる。別の実施形態では、受信機デバイスのマルチキャストサービスデバイスクライアント306は、FDTタイムスタンプごとにMPD 312中の利用可能時間を調整し、DASHクライアント308に送信されるいかなるMPDとも別個に、利用可能時間に対する調整をDASHクライアント308に通信する。
【００２９】
図3Bは、別の実施形態による、セグメント配信経路に沿った、MPDのようなセグメント利用可能性タイムラインに対して行われ得る、配信調整を示す。図3Bに示される配信調整は、図3Bではマルチキャストサービスデバイスクライアント306がMPDをDASHクライアント308に送信する前にMPDを修正できないことを除き、図3Aに関して上で説明されたものと同様である。ある実施形態では、受信機デバイスはMPD 312を受信することができ、受信機デバイスのマルチキャストサービスデバイスクライアント306はセグメント利用可能時間を修正することなくMPD 312をDASHクライアント308に提供することができる。一実施形態では、マルチキャストサービスデバイスクライアント306は、FDTタイムスタンプごとに利用可能時間を調整し遅延調整を列挙する遅延調整メッセージ316を生成するために使用され得る遅延調整を決定することができる。マルチキャストサービスデバイスクライアント306は、遅延調整メッセージをDASHクライアント308に提供することができる。ある実施形態では、DASHクライアント308は、遅延調整メッセージ316中の遅延調整の指示を使用して、MPD 312中のセグメント利用可能時間を修正して、修正されたMPD 314を生成することができる。DASHクライアント308は、受信機デバイスの時計を使用して、受信機デバイスのローカルHTTPサーバからセグメントを要求することができる。別の実施形態では、DASHクライアント308は、遅延調整メッセージ316を受信し、遅延調整メッセージ316を使用して、修正されたMPD 314を生成することなく受信機デバイスのローカルHTTPサーバからのセグメントに対する要求を修正することができる。
【００３０】
図4は、一実施形態による、ネットワーク400の種々の部分における配信経路遅延Δ1、Δ2、およびΔ3間の関係を示す。エンコーダ402からのコンテンツは、エンコーダ402からセグメンタ404へと流れ、種々のBMSC、すなわちBMSC1およびBMSC2、ならびにそれぞれのeノードB、すなわちeNB1.1、eNB1.2、eNB1.n、eNB2.1、eNB2.2、eNB2.nなどによってサービスされるネットワーク406、408の2つの異なる部分に提供され得る。eノードBのeNB1.2は、第1の部分406において受信機デバイス1(410)にコンテンツを提供することができ、eノードBのeNB2.2は第2の部分408において受信機デバイス2(412)にコンテンツを提供することができる。経路遅延Δ1は、エンコーダからBMSC、すなわちBMSC1、およびBMSC2にセグメントを提供する際に経験される遅延であり得る。経路遅延Δ2は、BMSC、すなわちBMSC1およびBMSC2に対する処理遅延であり得る。経路遅延Δ3は、それぞれのBMSC、すなわちBMSC1またはBMSC2から、それぞれのeノードB、すなわちeNB1.1、eNB1.2、eNB1.n、eNB2.1、eNB2.2、eNB2.nを通じて受信機デバイス1(410)または受信機デバイス2(412)にセグメントをそれぞれ提供する際に経験される遅延であり得る。ネットワーク400に対する推定最悪経路遅延は、任意の経路、たとえば(max(Δ1+Δ2+Δ3))に沿った最大遅延であり得る。第1の部分406における経路遅延は、第2の部分における経路遅延とは異なり得る。したがって、コンテンツの同じセグメントは、異なる部分406、408における異なる経路遅延Δ2およびΔ3のために、受信機デバイス2(412)とは異なる時間に、受信機デバイス1(410)において実際に利用可能となり得る。経路遅延がネットワーク400に対する推定ワーストケース遅延よりも小さいとき、受信機デバイス1(410)または受信機デバイス2(412)におけるコンテンツのセグメントの実際の利用可能時間は、受信機デバイスに提供されるMPDに列挙された利用可能時間よりも早いものとなり得る。様々な実施形態によって、受信機デバイス1(410)および/または受信機デバイス2(412)は、それらの実際に経験する経路遅延Δ1、Δ2、および/またはΔ3を考慮し、コンテンツのセグメントが実際に利用可能となり得るときにそれらを要求することが可能となり得る。
【００３１】
図5は、一実施形態による、利用可能性タイムライン501、502、および503、ならびにそれらのMPD利用可能開始時間AST1、AST2、およびAST3を示している。図5に示すように、エンコーダにおける利用可能性タイムライン501は、利用可能開始時間AST1を示すことができ、受信機デバイスにおける利用可能性タイムライン503は、利用可能開始時間AST2を示すことができる。時間tnにセグメントNは、エンコーダにおいて利用可能となることができ、また時間tnaにセグメントはBMSCに到着することができる。遅延Δ1は、エンコーダからBMSCへの送信遅延、たとえば時間tnaとtnとの差を表し得る。時間tntは、BMSCから受信機デバイスに送られるセグメントNの送信時間のタイムスタンプとなり得る。遅延Δ2は、BMSCにおける処理遅延、たとえば時間tntとtnaとの差を表し得る。時間tnrは、受信機デバイスにおけるセグメントNの到着時間のタイムスタンプとなり得る。遅延Δ3は、BMSCから受信機デバイスへの送信遅延、たとえば時間tnrとtntとの差を表し得る。継続期間Dはセグメント継続期間を表し得、時間tn'は、受信機デバイスにおけるセグメントNに対するセグメント利用可能時間を表し得る。
【００３２】
利用可能時間AST1およびAST2と、遅延Δ1およびΔ2と、送信タイムスタンプtntと、到着タイムスタンプtnaとの関係に基づいて、利用可能開始時間(AST2)は、利用可能開始時間AST1+遅延Δ1+遅延Δ2+到着タイムスタンプtnaと送信タイムスタンプtntとの差+セグメント継続期間D(たとえば、AST2=AST1+Δ1+Δ2+(tnr-tnt)+D)として決定され得る。受信機デバイスは、AST1利用可能時間とともにMPDを受信し得、BMSCは、遅延Δ1およびΔ2の推定値と送信タイムスタンプtntとを受信機デバイスに送信し得る。遅延Δ1およびΔ2の推定値ならびに送信タイムスタンプtntを受信機デバイスに提供することによって、受信機デバイスは、MPDにおける利用可能開始時間AST1を利用可能開始時間AST2に修正し、セグメントが実際に利用可能となり得るときにそれらのセグメントを要求するために使用する修正MPDを生成することが可能となり得る。代替的に、受信機デバイスによって受信されたMPDがAST3ワーストケース遅延利用可能時間(たとえば、AST3=AST1+DelayMAX)を含むとき、パケット送信のためのBMSCタイムスタンプは、同じ遅延(たとえば、tnt=送信時間+DelayMAX)タイムスタンプを考慮し得る。
【００３３】
図6Aは、セグメント利用可能性タイムラインを修正するためのある実施形態の方法600Aを示すプロセスフロー図である。ある実施形態では、方法600Aの動作は、スマートフォンのような、受信機デバイスのプロセッサ上で実行されるマルチキャストサービスデバイスクライアントによって実行され得る。別の実施形態では、方法600Aの動作は、DASHクライアントのような、受信機デバイスのプロセッサ上で実行されるクライアントアプリケーションによって実行され得る。別の実施形態では、方法600Aの動作は、BMSCサーバのプロセッサによって実施され得る。ブロック602において、マルチキャストサービスデバイスクライアント、クライアントアプリケーション、またはBMSCサーバが、MPDを受信することができる。MPDにおける開始時間は、エンコーダによって示される初期開始時間(AST1)であり得るか、またはワーストケース開始時間(AST3)であり得る。一実施形態では、デバイスは、OTA送信を介してMPDを受信することができる。ある実施形態では、MPDは、ネットワークから受信されてよく、ヘッドエンドは、MPD中のセグメントの利用可能時間を設定することができる。ある実施形態では、MPD中の利用可能時間は、ネットワークによって設定されてよく、セグメントを生成するエンコーダから受信機デバイスまでの最悪の場合のエンドツーエンドの転送遅延(たとえば、ネットワークジッタ)を考慮し得る。ある実施形態では、クライアントアプリケーションは、マルチキャストサービスデバイスクライアントを介してMPDを受信することができる。
【００３４】
ブロック603において、マルチキャストサービスデバイスクライアント、クライアントアプリケーション、またはBMSCサーバが、ネットワークジッタを決定することができる。一実施形態では、デバイスは、ユーザサービス記述(USD)においてネットワークジッタ値を受信することができる。他の実施形態では、ネットワークジッタ値は、事前プロビジョニングされ、デバイスのメモリに記憶され得る。
【００３５】
ブロック604において、マルチキャストサービスデバイスクライアント、クライアントアプリケーション、またはBMSCサーバが、FDTを受信し、FDT到着タイムスタンプ(tnr)を決定することができる。一実施形態では、FDTは、FDT送信時間(tnt)、エンコーダからの送信遅延(Δ1)、および/またはBMSCにおける処理遅延(Δ2)などの1つまたは複数の値を示すFDTタイムスタンプを含み得る。MPDにおける開始時間が初期開始時間(AST1)であるとき、FDT送信時間(tnt)は、FDTパケットが送信された実際の時間を表し得る。MPDにおける開始時間がワーストケース開始時間(AST3)であるとき、FDTパケットが送信された実際の時間にワーストケース遅延(delayMAX)を加えて、シフトされた送信時間(tnt=tnt+delayMAX)を生成することによって、ワーストケース遅延(delayMAX)を考慮するように調整され得る。一実施形態では、tnt、Δ1、およびΔ2の別個の値などの値は、FDTタイムスタンプにおいて別々に示され得る。別の実施形態では、それらの値は、Δ1+Δ2-tntの合計など、単一値として示され得る。
【００３６】
ブロック606において、マルチキャストサービスデバイスクライアント、クライアントアプリケーション、またはBMSCサーバが、FDTタイムスタンプ値(tnt、Δ1、およびΔ2)を決定することができる。たとえば、マルチキャストサービスデバイスクライアント、クライアントアプリケーション、またはBMSCサーバは、FDTパケットのヘッダを構文解析(たとえば、ALCヘッダ要素、ALCヘッダ延長部、FDTヘッダ延長部などを構文解析)して、FDTパケットヘッダに示されるFDTタイムスタンプを決定し得る。ブロック607において、マルチキャストサービスデバイスクライアント、クライアントアプリケーション、またはBMSCサーバが、FDTに関連付けられるセグメントのセグメント継続期間(D)を決定し得る。セグメント継続期間(D)は、受信されたMPDに、FDTに、またはマルチキャストサービスデバイスクライアント、クライアントアプリケーション、またはBMSCサーバにとって利用可能な別のデータソースに示され得る。
【００３７】
ブロック608において、マルチキャストサービスデバイスクライアント、クライアントアプリケーション、またはBMSCサーバは、実際の利用可能開始時間(AST2)を、受信されたMPDからの開始時間(たとえば、最初の利用可能開始時間(AST1)またはワーストケース開始時間(AST3))+エンコーダからの送信遅延(Δ1)+BMSCにおける処理遅延(Δ2)+FDT到着時間(tnr)-FDT送信時間(tnt)+セグメント継続期間(D)(たとえば、AST2=(AST1またはAST3)+Δ1+Δ2+(tnr-tnt)+D)として決定する。
【００３８】
ブロック610において、マルチキャストサービスデバイスクライアント、クライアントアプリケーション、またはBMSCサーバは、MPD開始時間(AvailabilityStartTime)を、決定された実際の開始時間(AST2)+ネットワークジッタ(NetworkJitter)にシフトさせ得る。このようにして、MPDは、セグメントが利用可能となり得る実際の時間を反映し、受信機デバイスによって実際に経験される経路遅延を考慮するようにシフトされ得る。任意選択のブロック612において、マルチキャストサービスデバイスクライアント、クライアントアプリケーション、またはBMSCサーバは、マルチキャストサービスデバイスクライアント、クライアントアプリケーション、またはBMSCサーバにとって利用可能なメモリに、修正されたMPDを記憶することができる。一実施形態では、修正されたMPDを記憶するステップは、いくつかまたはすべてのMPDが記憶されるURLと関連付けられる受信機デバイスまたはBMSCサーバ上のメモリ位置に、修正されたMPDを記憶するステップを含み得る。別の実施形態では、クライアントアプリケーションは、修正されたMPDを別個のメモリ位置に特に記憶しなくてよい。むしろ、任意選択のブロック614において、クライアントアプリケーションは、修正されたMPDを使用して、シフトされた利用可能時間においてセグメントを要求するだけであってよい。さらなる実施形態では、方法600Aの動作は、異なる表現中の利用可能時間が独立にシフトされることを可能にするために、表現ごとに繰り返され得る。
【００３９】
図6Bは、遅延調整メッセージを生成するためのある実施形態の方法600Bを示す。実施形態の方法600Bは、セグメント利用可能性タイムラインの移動を示す遅延調整メッセージがセグメント利用可能性タイムラインを必ずしもシフトすることなく生成され得ることを除き、図6Aを参照して上で説明された方法600Aと同様である。一実施形態では、方法600Bの動作は、スマートフォンのような、受信機デバイスのプロセッサ上で実行されるマルチキャストサービスデバイスクライアントによって実行され得る。別の実施形態では、方法600Bの動作は、DASHクライアントのような、受信機デバイスのプロセッサ上で実行されるクライアントアプリケーションによって実行され得る。別の実施形態では、方法600Bの動作は、BMSCサーバのプロセッサによって実施され得る。
【００４０】
ブロック602、603、604、606、607、608、および610において、マルチキャストサービスデバイスクライアント、クライアントアプリケーション、またはBMSCサーバは、図6Aを参照して上で説明された方法600Aの同様に番号が付けられたブロックの動作を実施して、シフトされたMPD開始時間(AvailabilityStartTime)を決定することができる。ブロック616において、マルチキャストサービスデバイスクライアント、クライアントアプリケーション、またはBMSCサーバは、遅延調整メッセージに、シフトされたMPD開始時間(AvailabilityStartTime)の指示を記憶することができる。一実施形態では、遅延調整メッセージは、クライアントアプリケーションが、デバイスにおけるセグメント利用可能性の遅延を考慮するように、1つまたは複数のセグメントの利用可能時間をシフトするために使用され得る遅延調整を決定するのに使用できる、データファイルであり得る。一実施形態では、遅延調整メッセージは、いくつかまたはすべての遅延調整メッセージが記憶されるURLと関連付けられるデバイス上のメモリ位置に、記憶され得る。ブロック618において、たとえば、図11のブロック1106を参照して以下で論じられるように、マルチキャストサービスデバイスクライアント、クライアントアプリケーション、またはBMSCサーバは、1つまたは複数のセグメントの利用可能時間をシフトする際にクライアントアプリケーションが使用するために、遅延調整メッセージをクライアントアプリケーションに送信することができる。別の実施形態では、遅延調整メッセージは送信されなくてよく、むしろ、クライアントアプリケーションによって必要に応じて、記憶されたメモリ位置においてアクセスされてよく、またはそこから要求されてよい。
【００４１】
図7は、一実施形態によるALCパケット700のデータ構造図である。一実施形態では、FDTタイムスタンプは、送信側現在時間(SCT)フィールドなどの標準的なALCパケットヘッダフィールド内に示され得る。他の実施形態では、ALC拡張ヘッダは、FDTタイムスタンプ値を示すために使用され得る。一実施形態では、ALC拡張ヘッダ内の3つの異なる32ビットフィールドに示されたtnt、Δ1、およびΔ2の別個の値などの値は、FDTタイムスタンプにおいて別々に示され得る。別の実施形態では、それらの値は、ALC拡張ヘッダ内の単一の32ビットフィールドに示されたΔ1+Δ2-tntの合計など、単一値として示され得る。
【００４２】
図8は、一実施形態による、MPD801、803、および805と、それらの利用可能開始時間AST1、AST2、およびAST3、送信時間(t1、t2、およびt3)、到着時間、ならびにオフセット時間(PacketOffset)を示している。図8に示すように、BMSCにおいて受信されたMPD 801における利用可能性タイムラインは、利用可能開始時間AST1を示し得、第1のセグメントNは、時間t1にBMSCから受信機デバイスへ送信され得る。BMSCは、受信機デバイスに提供されたMPD 803における第1のセグメントNに対する利用可能開始時間AST3を示すように、遅延に基づいてMPD 801を修正し得る。しかしながら、経路遅延は、推定される遅延よりも小さくなり得るため、セグメントNは、BMSCによって使用される遅延を仮定してセグメントNが到着している時間t3よりも短くなり得る、実際の時間t2に到着することがある。このようにして、セグメントNは、MPD 803に示された時間の前に利用可能となり得、受信機デバイスは、MPD 803に列挙された時間までセグメントNを要求するのを待機する場合、不要な遅延を経験し得る。実際の経路遅延を考慮するために、受信機デバイスは、セグメントNが利用可能となり得る実際の時間を反映するように利用可能開始時間(AST2)をシフトした修正MPD 805を生成し得る。オフセット時間(PacketOffset)は、送信1と利用可能時間AST1との間の時間に対応し得、利用可能開始時間(AST2)は、到着時間t2-オフセット時間(PacketOffset)(たとえば、AST2=t2-PacketOffset)として決定され得る。オフセット時間(PacketOffset)を受信機デバイスに提供することにより、受信機デバイスは、MPD 803における開始時間AST3とは無関係に実際の利用可能開始時間AST2を決定し、実際の利用可能開始時間AST2を反映するように修正MPD 805を生成するために有効化され得る。
【００４３】
図9Aは、セグメント利用可能性タイムラインを修正するためのある実施形態の方法900aを示すプロセスフロー図である。一実施形態では、方法900aの動作は、スマートフォンのような、受信機デバイスのプロセッサ上で実行されるマルチキャストサービスデバイスクライアントによって実行され得る。別の実施形態では、方法900aの動作は、DASHクライアントのような、受信機デバイスのプロセッサ上で実行されるクライアントアプリケーションによって実行され得る。別の実施形態では、方法900aの動作は、BMSCサーバのプロセッサによって実施され得る。ブロック902において、マルチキャストサービスデバイスクライアント、クライアントアプリケーション、またはBMSCサーバが、MPDを受信することができる。MPDにおける開始時間は、ワーストケース開始時間または他の開始時間など、任意の開始時間であり得る。一実施形態では、デバイスは、OTA送信を介してMPDを受信することができる。ある実施形態では、MPDは、ネットワークから受信されてよく、ヘッドエンドは、MPD中のセグメントの利用可能時間を設定することができる。ある実施形態では、クライアントアプリケーションは、マルチキャストサービスデバイスクライアントを介してMPDを受信することができる。
【００４４】
上記で説明したように、ブロック603において、マルチキャストサービスデバイスクライアント、クライアントアプリケーション、またはBMSCサーバが、ネットワークジッタを決定することができる。ブロック903において、マルチキャストサービスデバイスクライアント、クライアントアプリケーション、またはBMSCサーバが、FDTを受信し、FDT到着時間(t2)を決定することができる。一実施形態では、FDTは、送信デバイスにおけるFDTパケットの送信とMPD内の利用可能時間とのオフセット時間(PacketOffset)を示すFDTタイムスタンプを含み得る。ブロック904において、マルチキャストサービスデバイスクライアント、クライアントアプリケーション、またはBMSCサーバが、FDTタイムスタンプ(PacketOffset)を決定することができる。たとえば、マルチキャストサービスデバイスクライアント、クライアントアプリケーション、またはBMSCサーバは、FDTパケットのヘッダを構文解析(たとえば、ALCヘッダ要素、ALCヘッダ延長部、FDTヘッダ延長部などを構文解析)して、FDTパケットヘッダに示されるFDTタイムスタンプを決定し得る。ブロック906において、マルチキャストサービスデバイスクライアント、クライアントアプリケーション、またはBMSCサーバは、実際の利用可能開始時間(AST2)を、FDT到着時間(t2)-FDTタイムスタンプ(PacketOffset)(たとえば、AST2=t2-PacketOffset)として決定する。図6Aを参照しながら上記で説明したように、ブロック610、612、および614において、マルチキャストサービスデバイスクライアント、クライアントアプリケーション、またはBMSCサーバは、MPDをシフトし、修正MPDを記憶し、シフトされたMPDに従ってセグメントを要求し得る。
【００４５】
図9Bは、遅延調整メッセージを生成するためのある実施形態の方法900bを示す。実施形態の方法900bは、セグメント利用可能性タイムラインの移動を示す遅延調整メッセージがセグメント利用可能性タイムラインを必ずしもシフトすることなく生成され得ることを除き、図9Aを参照して上で説明された方法900aと同様である。一実施形態では、方法900bの動作は、スマートフォンのような、受信機デバイスのプロセッサ上で実行されるマルチキャストサービスデバイスクライアントによって実行され得る。別の実施形態では、方法900bの動作は、DASHクライアントのような、受信機デバイスのプロセッサ上で実行されるクライアントアプリケーションによって実行され得る。別の実施形態では、方法900bの動作は、BMSCサーバのプロセッサによって実施され得る。ブロック902、603、903、904、906、および610において、マルチキャストサービスデバイスクライアント、クライアントアプリケーション、またはBMSCサーバは、図9aを参照して上で説明された方法900aの同様に番号が付けられたブロックの動作を実施して、シフトされたMPD開始時間(AvailabilityStartTime)を決定することができる。図6Bを参照しながら上記で説明したように、ブロック616および618において、マルチキャストサービスデバイスクライアント、クライアントアプリケーション、またはBMSCサーバは、シフトされたMPD開始時間の指示を記憶し、遅延メッセージを送信することができる。
【００４６】
図10Aは、FDT内のFDTタイムスタンプを指示するためのある実施形態の方法1000aを示すプロセスフロー図である。一実施形態では、方法1000aの動作は、BMSCサーバのプロセッサによって実施され得る。ブロック1002において、BMSCサーバは、初期開始時間(AST1)の指示を含んだMPDを受信し得る。ブロック1003において、BMSCサーバは、初期開始時間(AST1)の指示を含んだMPDを受信機デバイスへ送信し得る。
【００４７】
ブロック1004において、BMSCサーバは、エンコーダからBMSCサーバへの送信遅延(Δ1)を決定し得る。BMSCサーバは、エンコーダから受信されたパケット内のタイムスタンプを、パケットが受信された実際の時間と比較することによって、送信遅延を推定し得る。代替的に、送信遅延(Δ1)は、BMSCサーバにとって利用可能なメモリ内に記憶された事前プロビジョニング値であってもよい。ブロック1005において、BMSCサーバは、送信のためにパケットを準備する際の処理遅延(Δ2)を決定し得る。処理遅延(Δ2)は、BMSCサーバにとって利用可能なメモリ内に記憶された事前プロビジョニング値であってもよい。
【００４８】
ブロック1006において、BMSCサーバはFDT送信時間(tnt)を決定し得、またブロック1007において、BMSCサーバはFDT内のFDTタイムスタンプ(tnt、Δ1、Δ2)を示し得る。たとえば、FDTタイムスタンプは、FDTのALC要素またはALCもしくはFDTヘッダ拡張部に示され得る。一実施形態では、tnt、Δ1、およびΔ2の別個の値などの値は、FDTタイムスタンプにおいて別々に示され得る。別の実施形態では、それらの値は、Δ1+Δ2-tntの合計など、単一値として示され得る。ブロック1008において、BMSCサーバは、FDT送信時間にFDTを送信し得る。
【００４９】
図10Bは、FDT内のFDTタイムスタンプを指示するためのある実施形態の方法1000bを示すプロセスフロー図である。実施形態の方法1000bは、MPD利用可能開始時間およびFDT送信時間をシフトするためにワーストケース遅延(delayMAX)が使用され得ることを除いて、図10Aを参照しながら上記で説明した方法1000aに類似している。ブロック1002において、BMSCサーバは、初期開始時間(AST1)の指示を含んだMPDを受信し得る。
【００５０】
ブロック1010において、BMSCサーバは、受信機デバイスへセグメントを送信するためにワーストケース遅延(delayMAX)を推定し得る。ブロック1011において、BMSCサーバは、初期開始時間(AST1)および推定されたワーストケース遅延(delayMAX)に少なくとも部分的に基づいて、ワーストケース開始時間(AST3)を決定し得る。たとえば、AST3は、AST1+ワーストケース遅延(delayMAX)(たとえば、AST3=AST1+delayMAX)として決定され得る。
【００５１】
ブロック1012において、BMSCサーバは、MPD開始時間をワーストケース開始時間(AST3)へシフトして、ワーストケース開始時間(AST3)の指示を含んだMPDを生成し得る。ブロック1013において、BMSCサーバは、ワーストケース開始時間(AST3)の指示を含んだMPDを受信機デバイスへ送信し得る。
【００５２】
上記で説明したように、BMSCサーバは、ブロック1004および1005において送信遅延(Δ1)および処理遅延(Δ2)を決定し得る。ブロック1014において、BMSCサーバは、推定されたワーストケース遅延(delayMAX)に対して調整されたFDT送信時間(たとえば、tnt=tnt+delayMAX)を決定し得る。このようにして、BMSCサーバから送られたFDTタイムスタンプは、ワーストケース開始時間(AST3)を有するMPDを生成するために使用されるワーストケース遅延を考慮する送信時間(tnt)を含み得る。上記で説明したように、BMSCサーバは、ブロック1007においてFDTにFDTタイムスタンプ(tnt、Δ1、Δ2)を示すことができ、またBMSCサーバは、ブロック1008において、FDT送信時間にFDTを送信し得る。
【００５３】
図10Cは、FDT内のFDTタイムスタンプを指示するためのある実施形態の方法1000cを示すプロセスフロー図である。実施形態の方法1000cは、送信時間+ワーストケース遅延ではなくオフセット時間(PacketOffset)がFDTタイムスタンプとして使用され得ることを除いて、図10Aを参照しながら上記で説明した方法1000aに類似している。
【００５４】
ブロック1002および1003において、BMSCサーバは、図10Aを参照しながら上記で説明した方法1000aの同様の番号のブロックの動作を実行してMPDを受信および送信し得る。ブロック1015において、BMSCサーバは、FDT送信時間(t1)を決定し得る。ブロック1016において、BMSCサーバは、たとえば、t1からAST1を減算することによって、送信時間(t1)と初期開始時間(AST1)との間のオフセット時間(PacketOffset)を決定し得る。ブロック1017において、BMSCサーバは、FDTにFDTタイムスタンプ(PacketOffset)を示し得る。たとえば、FDTタイムスタンプは、FDTのALC要素またはALCもしくはFDTヘッダ拡張部に示され得る。上記で説明したように、ブロック1008において、BMSCサーバは、FDT送信時間(t1)にFDTを送信し得る。
【００５５】
図11は、遅延調整メッセージ中の指示に基づいて利用可能時間を調整するためのある実施形態の方法を示す。ある実施形態では、方法1100の動作は、DASHクライアントのような、スマートフォンなどの受信機デバイスのプロセッサ上で実行されるクライアントアプリケーションによって実行され得る。ブロック1102において、クライアントアプリケーションは、MPDを受信することができる。ある実施形態では、クライアントアプリケーションは、マルチキャストサービスデバイスクライアントを介して受信機デバイス上でHTTPサーバを介してMPDを受信することができる。ブロック1104において、クライアントアプリケーションは、遅延調整メッセージを受信することができる。ある実施形態では、クライアントアプリケーションは、マルチキャストサービスデバイスクライアントを介して受信機デバイス上でHTTPサーバを介して遅延調整メッセージを受信することができる。ブロック1106において、クライアントアプリケーションは、遅延調整メッセージに基づいて、MPD中のいくつかまたはすべてのセグメントの利用可能時間をシフトすることができる。一実施形態では、遅延調整メッセージに基づいて利用可能時間をシフトするステップは、各セグメントが受信機デバイス上で利用可能になる時間を調整するために、シフトされたMPD利用可能開始時間(AvailabilityStartTime)および/または他の値の指示を使用するステップを含み得る。ある実施形態では、利用可能時間をシフトするステップは、MPD自体を修正して修正されたMPDを生成するステップを含み得る。別の実施形態では、利用可能時間をシフトするステップは、MPD自体を修正することなく、セグメントが受信機デバイス上で利用可能になるときの指示を変更するステップを伴い得る。MPDが修正される実施形態では、任意選択のブロック1108において、クライアントアプリケーションは、クライアントアプリケーションに対して利用可能なメモリに、修正されたMPDを記憶することができる。ブロック1110において、クライアントアプリケーションが、シフトされたMPD開始時間(AvailabilityStartTime)にセグメントを要求し得る。
【００５６】
様々な実施形態(限定はしないが、図3A、図3B、図4、図5、図6A、図6B、図7、図8、図9A、図9B、および図11を参照しながら上記で説明した実施形態を含む)は、様々なモバイルデバイスのうちのいずれか(すなわち、受信機デバイス)において実装される場合があり、その一例が図12に示される。たとえば、モバイルコンピューティングデバイス1200は、タッチスクリーンコントローラ1204と内部メモリ1202とに結合されたプロセッサ1201を含み得る。プロセッサ1201は、汎用または特定の処理タスクに指定された1つまたは複数のマルチコア集積回路(IC)であり得る。内部メモリ1202は揮発性または不揮発性メモリであってもよく、また、セキュアおよび/もしくは暗号化メモリ、または非セキュアおよび/もしくは非暗号化メモリ、あるいはそれらの任意の組合せであってもよい。タッチスクリーンコントローラ1204およびプロセッサ1201は、抵抗感知タッチスクリーン、静電容量感知タッチスクリーン、赤外線感知タッチスクリーンなどのタッチスクリーンパネル1212にも結合され得る。コンピューティングデバイス1200は、1つまたは複数の無線信号トランシーバ1208(たとえば、Peanut(登録商標)、Bluetooth(登録商標)、Zigbee(登録商標)、Wi-Fi、RF、セルラーなど)と、互いにおよび/またはプロセッサ1201に結合された、送受信するためのアンテナ1210とを有し得る。トランシーバ1208およびアンテナ1210は、様々なワイヤレス送信プロトコルスタックおよびインターフェースを実装するために、上述の回路とともに使用され得る。モバイルコンピューティングデバイス1200は、セルラーネットワークを介した通信を可能にし、プロセッサに結合されたセルラーネットワークワイヤレスモデムチップ1216を含み得る。モバイルコンピューティングデバイス1200は、プロセッサ1201に結合された周辺デバイス接続インターフェース1218を含み得る。周辺デバイス接続インターフェース1218は、1つのタイプの接続を受け入れるように単独で構成され得るか、または、USB、FireWire、Thunderbolt、またはPCIeなどの共通またはプロプライエタリの様々なタイプの物理接続および通信接続を受け入れるように複合的に構成され得る。周辺デバイス接続インターフェース1218は、同様に構成された周辺デバイス接続ポート(図示せず)に結合される場合もある。モバイルコンピューティングデバイス1200はまた、オーディオ出力を提供するためのスピーカー1214を含み得る。モバイルコンピューティングデバイス1200はまた、本明細書で説明する構成要素のすべてまたはいくつかを収容するための、プラスチック、金属、または材料の組合せから構築されたハウジング1220を含み得る。モバイルコンピューティングデバイス1200は、使い捨てバッテリーまたは充電式バッテリーなどの、プロセッサ1201に結合された電源1222を含み得る。充電式バッテリーは、モバイルコンピューティングデバイス1200の外部にある電源から充電電流を受けるために、周辺デバイス接続ポートに結合される場合もある。
【００５７】
様々な実施形態(限定はしないが、図3A、図3B、図4、図5、図6A、図6B、図7、図8、図9A、図9B、図10A、図10Bおよび図11を参照しながら上記で説明した実施形態を含む)は、図13に示すサーバ1300などの様々な市販のサーバデバイスのうちのいずれかに実装される場合もある。そのようなサーバ1300は通常、揮発性メモリ1302と、ディスクドライブ1304などの大容量の不揮発性メモリとに結合されたプロセッサ1301を含む。サーバ1300はまた、プロセッサ1301に結合されたフロッピーディスクドライブ、コンパクトディスク(CD)ドライブまたはDVDディスクドライブ1306を含み得る。サーバ1300はまた、他の告知システムコンピュータおよびサーバに結合されたローカルエリアネットワーク、インターネット、公衆交換電話網、ならびに/またはセルラーネットワーク(たとえば、CDMA、TDMA、GSM(登録商標)、PCS、3G、4G、LTE、または任意の他のタイプのセルラーデータネットワーク)のような、通信ネットワーク1307とのネットワークインターフェース接続を確立するための、プロセッサ1301に結合されたネットワークアクセスポートのような1つまたは複数の送受信機1303を含み得る。
【００５８】
プロセッサ1201および1301は、上述した様々な実施形態の機能を含む、様々な機能を実行するようにソフトウェア命令(アプリケーション)によって構成され得る、任意のプログラマブルマイクロプロセッサ、マイクロコンピュータ、または1つもしくは複数の多重プロセッサチップであり得る。いくつかのデバイスでは、ワイヤレス通信機能専用の1つのプロセッサ、および他のアプリケーションの実行専用の1つのプロセッサなどの複数のプロセッサが設けられてもよい。通常、ソフトウェアアプリケーションは、それらがアクセスされプロセッサ1201および1301にロードされる前に、内部メモリに記憶され得る。プロセッサ1201および1301は、アプリケーションソフトウェア命令を記憶するのに十分な内部メモリを含み得る。多くのデバイスでは、内部メモリは、揮発性メモリ、またはフラッシュメモリのような不揮発性メモリ、または両方の混合であり得る。本明細書では、メモリへの一般的な言及は、デバイスに差し込まれる内部メモリまたはリムーバブルメモリと、プロセッサ1201および1301自体の中のメモリとを含む、プロセッサ1201および1301によってアクセス可能なメモリを指す。
【００５９】
上記の方法の説明およびプロセスフロー図は、例示的な例として与えられるものにすぎず、様々な実施形態のステップが、提示された順序で実行されなければならないことを要求または示唆するものではない。当業者なら諒解するように、上記の実施形態におけるステップの順序は、任意の順序で実施することができる。「その後」、「次いで」、「次」などの語は、ステップの順番を限定するものではなく、これらの語は単に、読者に本方法の説明を案内するために使用される。さらに、たとえば冠詞「a」、「an」、または「the」を使用する、請求項の要素に対する単数形でのいかなる参照も、要素を単数形に限定すると解釈されるべきではない。
【００６０】
本明細書で開示した実施形態に関して説明した様々な例示的な論理ブロック、モジュール、回路、およびアルゴリズムステップは、電子ハードウェア、コンピュータソフトウェア、またはその両方の組合せとして実装される場合がある。ハードウェアおよびソフトウェアのこの互換性を明確に示すために、様々な例示的な構成要素、ブロック、モジュール、回路、およびステップを、一般にそれらの機能性に関して上述した。そのような機能性がハードウェアとして実装されるか、またはソフトウェアとして実装されるかは、特定の適用例および全体的なシステムに課される設計制約によって決まる。当業者は、説明した機能性を特定のアプリケーションごとに様々な方法で実装し得るが、そのような実装決定は本発明の範囲からの逸脱を引き起こすものと解釈されるべきではない。
【００６１】
本明細書で開示する態様に関して説明する様々な例示的な論理、論理ブロック、モジュール、および回路を実装するために使用されるハードウェアは、汎用プロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)もしくは他のプログラマブル論理デバイス、個別ゲートもしくはトランジスタ論理、個別ハードウェア構成要素、または本明細書で説明する機能を実行するように設計されたそれらの任意の組合せを用いて実装または実行され得る。汎用プロセッサはマイクロプロセッサであってもよいが、代替的に、プロセッサは任意の従来のプロセッサ、コントローラ、マイクロコントローラ、またはステートマシンであってもよい。プロセッサはまた、コンピューティングデバイスの組合せ(たとえば、DSPおよびマイクロプロセッサの組合せ、複数のマイクロプロセッサ、DSPコアと連携した1つもしくは複数のマイクロプロセッサ、または任意の他のそのような構成)として実現される場合もある。代替的に、いくつかのステップまたは方法は、所与の機能に固有の回路によって実施されてもよい。
【００６２】
1つまたは複数の例示的な態様では、説明する機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せとして実装されてもよい。ソフトウェアで実装される場合、機能は、非一時的コンピュータ可読媒体上または非一時的プロセッサ可読媒体上の1つまたは複数のプロセッサ実行可能命令またはコンピュータ実行可能命令もしくはコードとして記憶されてもよい。本明細書で開示する方法またはアルゴリズムのステップは、非一時的コンピュータ可読記憶媒体または非一時的プロセッサ可読記憶媒体上に存在し得るプロセッサ実行可能ソフトウェアモジュールにおいて具現化され得る。非一時的なサーバ可読記憶媒体、コンピュータ可読記憶媒体またはプロセッサ可読記憶媒体は、コンピュータまたはプロセッサによってアクセスされ得る任意の記憶媒体であってよい。限定ではなく例として、そのような非一時的なサーバ可読記憶媒体、コンピュータ可読媒体またはプロセッサ可読媒体は、RAM、ROM、EEPROM、FLASHメモリ、CD-ROMもしくは他の光ディスク記憶装置、磁気ディスク記憶装置もしくは他の磁気記憶デバイス、または、命令もしくはデータ構造の形式で所望のプログラムコードを記憶するために使用される場合があり、かつコンピュータによってアクセスされる場合がある任意の他の媒体を含んでもよい。本明細書で使用される場合、ディスク(disk)およびディスク(disc)は、コンパクトディスク(disc)(CD)、レーザディスク(disc)、光ディスク(disc)、デジタル多用途ディスク(disc)(DVD)、フロッピーディスク(disk)、およびブルーレイディスク(disc)を含み、ディスク(disk)は、通常、データを磁気的に再生するが、ディスク(disc)は、レーザを用いて光学的にデータを再生する。上記の組合せも、非一時的なサーバ可読記憶媒体、コンピュータ可読媒体およびプロセッサ可読媒体の範囲内に含まれる。加えて、方法またはアルゴリズムの動作は、コンピュータプログラム製品に組み込まれる場合がある、非一時的なサーバ可読媒体、プロセッサ可読媒体および/またはコンピュータ可読媒体上のコードおよび/または命令の、1つまたは任意の組合せ、またはそのセットとして存在してもよい。
【００６３】
開示した実施形態の前述の説明は、いかなる当業者も本発明を作成または使用することができるように記載されている。これらの実施形態に対する様々な修正は当業者には容易に明らかとなり、本明細書で定義した一般原理は、本発明の趣旨または範囲から逸脱することなく、他の実施形態に適用されてもよい。したがって、本発明は、本明細書に示す実施形態に限定されるものではなく、以下の特許請求の範囲、ならびに本明細書で開示する原理および新規の特徴と一致する最も広い範囲を与えられるべきである。
【符号の説明】
【００６４】
100  セルラーネットワークシステム
102  受信機デバイス
104  セルラータワーまたは基地局
106  セルラー接続
108  サーバ
110  インターネット
112  サーバ
202  受信機デバイス
204  アプリケーション/DASHクライアント
206  マルチキャストサービスデバイスクライアント(MSDC)
208  モデムレイヤ
302  エンコーダ
304  BMSC
306  マルチキャストサービスデバイスクライアント
308  DASHクライアント
310  MPD
312  MPD
314  MPD
316  遅延調整メッセージ
400  ネットワーク
402  エンコーダ
404  セグメンタ
406  ネットワーク、第1の部分
408  ネットワーク、第2の部分
410  受信機デバイス1
412  受信機デバイス2
501  利用可能性タイムライン
502  利用可能性タイムライン
503  利用可能性タイムライン
600A  方法
600B  方法
700  ALCパケット
801  MPD
803  MPD
805  MPD
900a  方法
900b  方法
1000a  方法
1000b  方法
1000c  方法
1100  方法
1200  モバイルコンピューティングデバイス
1201  プロセッサ
1202  内部メモリ
1204  タッチスクリーンコントローラ
1208  無線信号トランシーバ、トランシーバ
1210  アンテナ
1212  タッチスクリーンパネル
1214  スピーカー
1216  セルラーネットワークワイヤレスモデムチップ
1218  周辺デバイス接続インターフェース
1222  電源
【図１】
2018514098.tif 000003
【図２】
2018514098.tif 000004
【図３Ａ】
2018514098.tif 000005
【図３Ｂ】
2018514098.tif 000006
【図４】
2018514098.tif 000007
【図５】
2018514098.tif 000008
【図６Ａ】
2018514098.tif 000009
【図６Ｂ】
2018514098.tif 000010
【図７】
2018514098.tif 000011
【図８】
2018514098.tif 000012
【図９Ａ】
2018514098.tif 000013
【図９Ｂ】
2018514098.tif 000014
【図１０Ａ】
2018514098.tif 000015
【図１０Ｂ】
2018514098.tif 000016
【図１０Ｃ】
2018514098.tif 000017
【図１１】
2018514098.tif 000018
【図１２】
2018514098.tif 000019
【図１３】
2018514098.tif 000020
【手続補正書】
【提出日】平成29年8月24日(2017.8.24)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
セグメント利用可能性タイムラインを修正するための方法であって、
デバイスにおいてセグメント利用可能性タイムラインを受信するステップと、
前記デバイスにおいてファイル配信テーブル(FDT)パケットを受信するステップであって、前記FDTパケットはFDTタイムスタンプを含む、ステップと、
前記デバイスにおいてFDT到着時間を決定するステップと、
前記FDT到着時間と前記FDTパケットに含まれた前記FDTタイムスタンプの両方に少なくとも部分的に基づいて、実際の利用可能開始時間を決定するステップであって、前記FDTタイムスタンプは、前記FDTパケットの送信時間または前記FDTパケットを送るデバイスによって決定されたオフセット時間である、ステップと、
前記決定された実際の利用可能開始時間に少なくとも部分的に基づいて、前記セグメント利用可能性タイムラインの開始時間をシフトするステップと
を含む方法。
【請求項２】
前記デバイスにおいて受信されるときの前記セグメント利用可能性タイムラインの前記開始時間は、推定されたワーストケース遅延に少なくとも部分的に基づいた開始時間であり、
前記FDTタイムスタンプは、前記FDTパケットの前記送信時間+前記推定されたワーストケース遅延である、請求項1に記載の方法。
【請求項３】
前記FDTタイムスタンプは、前記FDTパケットを送る前記デバイスによって決定されるオフセット時間であり、
前記FDT到着時間と前記FDTパケットに含まれた前記FDTタイムスタンプの両方に少なくとも部分的に基づいて、前記デバイスにおける前記実際の利用可能開始時間を決定するステップは、前記実際の利用可能開始時間を、前記FDT到着時間-前記FDTタイムスタンプとして決定するステップを含む、請求項1に記載の方法。
【請求項４】
前記FDTパケットを送る前記デバイスによって決定される前記オフセット時間は、最初の利用可能開始時間と、前記FDTパケットを送る前記デバイスによる前記FDTパケットの送信時間との間の時間である、請求項3に記載の方法。
【請求項５】
前記デバイスにおいて受信されるときの前記セグメント利用可能性タイムラインの前記開始時間は、初期開始時間であり、
前記FDTタイムスタンプは、前記FDTパケットの前記送信時間と、送信遅延と、処理遅延とを含み、
前記FDT到着時間と前記FDTパケットに含まれた前記FDTタイムスタンプの両方に少なくとも部分的に基づいて、前記デバイスにおける前記実際の利用可能開始時間を決定するステップは、前記FDTパケットの前記送信時間、前記送信遅延、および前記処理遅延に少なくとも部分的に基づいて、前記実際の利用可能開始時間を前記開始時間として決定するステップを含む、請求項1に記載の方法。
【請求項６】
セグメント継続期間を決定するステップをさらに含み、前記FDTパケットの前記送信時間、前記送信遅延、および前記処理遅延に少なくとも部分的に基づいて、前記実際の利用可能開始時間を前記開始時間として決定するステップは、前記FDTパケットの前記送信時間、前記送信遅延、前記処理遅延、および前記セグメント継続期間に少なくとも部分的に基づいて、前記実際の利用可能開始時間を前記開始時間として決定するステップを含む、請求項5に記載の方法。
【請求項７】
前記FDTタイムスタンプは前記FDTパケット内に示される、請求項6に記載の方法。
【請求項８】
前記FDTタイムスタンプはALCパケットヘッダの送信側現在時間フィールド内に示される、請求項7に記載の方法。
【請求項９】
前記FDTタイムスタンプはALCまたはFDT拡張ヘッダ内に示される、請求項5に記載の方法。
【請求項１０】
ネットワークジッタ推定値を決定するステップをさらに含み、前記決定された実際の利用可能開始時間に少なくとも部分的に基づいて、前記セグメント利用可能性タイムラインの開始時間をシフトするステップは、前記決定された実際の利用可能開始時間および前記決定されたネットワークジッタ推定値に少なくとも部分的に基づいて、前記セグメント利用可能性タイムラインの開始時間をシフトするステップを含む、請求項1に記載の方法。
【請求項１１】
前記決定された実際の利用可能開始時間および前記決定されたネットワークジッタ推定値に少なくとも部分的に基づいて、前記セグメント利用可能性タイムラインの開始時間をシフトするステップは、前記決定された実際の利用可能開始時間に前記決定されたネットワークジッタ推定値を加えるステップを含む、請求項10に記載の方法。
【請求項１２】
前記セグメント利用可能性タイムラインは、Dynamic Adaptive Streaming Over Hypertext Transfer Protocol(DASH) Media Presentation Description(MPD)である、請求項1に記載の方法。
【請求項１３】
前記デバイスは受信機デバイスまたはブロードキャストマルチメディアサービスセンター(BMSC)サーバである、請求項1に記載の方法。
【請求項１４】
ファイル配信テーブル(FDT)パケットを送信するための方法であって、
前記FDTパケットの送信時間を決定するステップと、
前記FDTパケット内のFDTタイムスタンプにおいて前記FDTパケットの前記送信時間またはオフセット時間を示すステップと、
前記決定された送信時間に前記FDTパケットを送信するステップであって、前記FDTパケットを受信するデバイスは、前記パケットのFDT到着時間と前記FDTパケット内に示された前記FDTタイムスタンプの両方に少なくとも部分的に基づいて、実際の利用可能開始時間を決定するように構成される、ステップと
を含む方法。
【請求項１５】
前記FDTパケットの送信に対するワーストケース遅延を推定するステップをさらに含み、前記FDTタイムスタンプは、前記FDTパケットの前記送信時間+前記推定されたワーストケース遅延である、請求項14に記載の方法。
【請求項１６】
前記オフセット時間は前記FDTパケットの前記FDTタイムスタンプ内に示される、請求項14に記載の方法。
【請求項１７】
前記オフセット時間は、最初の利用可能開始時間と前記FDTパケットの前記送信時間との間の時間である、請求項16に記載の方法。
【請求項１８】
前記FDTタイムスタンプは、前記FDTパケットの前記送信時間、送信遅延、および処理遅延を示す、請求項14に記載の方法。
【請求項１９】
前記FDTタイムスタンプはALCパケットヘッダの送信側現在時間フィールド内に示される、請求項18に記載の方法。
【請求項２０】
前記FDTタイムスタンプはALCまたはFDT拡張ヘッダ内に示される、請求項18に記載の方法。
【請求項２１】
Dynamic Adaptive Streaming Over Hypertext Transfer Protocol(DASH) Media Presentation Description(MPD)をシフトし、前記MPDを送るステップをさらに含む、請求項14に記載の方法。
【請求項２２】
動作を実行するようにプロセッサ実行可能命令で構成されたプロセッサを備え、前記動作は、
セグメント利用可能性タイムラインを受信するステップと、
ファイル配信テーブル(FDT)パケットを受信するステップであって、前記FDTパケットはFDTタイムスタンプを含む、ステップと、
FDT到着時間を決定するステップと、
前記FDT到着時間と前記FDTパケットに含まれた前記FDTタイムスタンプの両方に少なくとも部分的に基づいて、実際の利用可能開始時間を決定するステップであって、前記FDTタイムスタンプは、前記FDTパケットの送信時間または前記FDTパケットを送るデバイスによって決定されたオフセット時間である、ステップと、
前記決定された実際の利用可能開始時間に少なくとも部分的に基づいて、前記セグメント利用可能性タイムラインの開始時間をシフトするステップと
を含むデバイス。
【請求項２３】
前記デバイスにおいて受信されるときの前記セグメント利用可能性タイムラインの前記開始時間は、推定されたワーストケース遅延に少なくとも部分的に基づいた開始時間であり、
前記FDTタイムスタンプは、前記FDTパケットの前記送信時間+前記推定されたワーストケース遅延である、請求項22に記載のデバイス。
【請求項２４】
前記FDTタイムスタンプは、前記FDTパケットを送る前記デバイスによって決定されるオフセット時間であり、
前記プロセッサは、前記FDT到着時間と前記FDTパケットに含まれた前記FDTタイムスタンプの両方に少なくとも部分的に基づいて実際の利用可能開始時間を決定するステップが、前記実際の利用可能開始時間を、前記FDT到着時間-前記FDTタイムスタンプとして決定するステップを含むような動作を実施するように、プロセッサ実行可能命令を用いて構成される、請求項22に記載のデバイス。
【請求項２５】
前記デバイスにおいて受信されるときの前記セグメント利用可能性タイムラインの前記開始時間は、初期開始時間であり、
前記FDTタイムスタンプは、前記FDTパケットの前記送信時間と、送信遅延と、処理遅延とを含み、
前記プロセッサは、前記FDT到着時間と前記FDTパケットに含まれた前記FDTタイムスタンプの両方に少なくとも部分的に基づいて実際の利用可能開始時間を決定するステップが、前記FDTパケットの前記送信時間、前記送信遅延、および前記処理遅延に少なくとも部分的に基づいて、前記実際の利用可能開始時間を前記開始時間として決定するステップを含むような動作を実施するように、プロセッサ実行可能命令を用いて構成される、請求項22に記載のデバイス。
【請求項２６】
前記プロセッサは、ネットワークジッタ推定値を決定するステップをさらに含む動作を実施するように、プロセッサ実行可能命令を用いて構成され、
前記プロセッサは、前記決定された実際の利用可能開始時間に少なくとも部分的に基づいて前記セグメント利用可能性タイムラインの開始時間をシフトするステップが、前記決定された実際の利用可能開始時間および前記決定されたネットワークジッタ推定値に少なくとも部分的に基づいて、前記セグメント利用可能性タイムラインの開始時間をシフトするステップを含むような動作を実施するように、プロセッサ実行可能命令を用いて構成される、請求項22に記載のデバイス。
【請求項２７】
前記セグメント利用可能性タイムラインは、Dynamic Adaptive Streaming Over Hypertext Transfer Protocol(DASH) Media Presentation Description(MPD)である、請求項22に記載のデバイス。
【請求項２８】
動作を実行するようにプロセッサ実行可能命令で構成されたプロセッサを備え、前記動作は、
ファイル配信テーブル(FDT)パケットの送信時間を決定するステップと、
前記FDTパケット内のFDTタイムスタンプにおいて前記FDTパケットの前記送信時間またはオフセット時間を示すステップと、
前記決定された送信時間に前記FDTパケットを送信するステップであって、前記FDTパケットを受信するデバイスは、前記パケットのFDT到着時間と前記FDTパケット内に示された前記FDTタイムスタンプの両方に少なくとも部分的に基づいて、実際の利用可能開始時間を決定するように構成される、ステップと
を含むデバイス。
【請求項２９】
前記プロセッサは、前記FDTパケットの送信に対するワーストケース遅延を推定するステップをさらに含む動作を実施するように、プロセッサ実行可能命令を用いて構成され、
前記プロセッサは、前記FDTタイムスタンプが前記FDTパケットの前記送信時間+前記推定されたワーストケース遅延となるような動作を実施するように、プロセッサ実行可能命令を用いて構成される、請求項28に記載のデバイス。
【請求項３０】
前記プロセッサは、Dynamic Adaptive Streaming Over Hypertext Transfer Protocol(DASH) Media Presentation Description(MPD)をシフトし、前記MPDを送るステップをさらに含む動作を実施するように、プロセッサ実行可能命令を用いて構成される、請求項22に記載のデバイス。
【国際調査報告】
2018514098.tif 000021
2018514098.tif 000022
2018514098.tif 000023