6472892 異種ネットワーク伝送における動的時間窓およびキャッシュメカニズム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6472892

(24)【登録日】2019年2月1日

(45)【発行日】2019年2月20日

(54)【発明の名称】異種ネットワーク伝送における動的時間窓およびキャッシュメカニズム

(51)【国際特許分類】

   H04N 21/438 20110101AFI20190207BHJP

   H04N 21/442 20110101ALI20190207BHJP

   G06F 13/00 20060101ALI20190207BHJP

【ＦＩ】

   H04N21/438

   H04N21/442

   G06F13/00 351C

【請求項の数】18

【全頁数】38

(21)【出願番号】特願2017-541330(P2017-541330)

(86)(22)【出願日】2016年2月2日

(65)【公表番号】特表2018-509818(P2018-509818A)

(43)【公表日】2018年4月5日

(86)【国際出願番号】CN2016073168

(87)【国際公開番号】WO2016124130

(87)【国際公開日】20160811

【審査請求日】2017年9月29日

(31)【優先権主張番号】201510064427.2

(32)【優先日】2015年2月6日

(33)【優先権主張国】CN

(31)【優先権主張番号】201510341265.2

(32)【優先日】2015年6月18日

(33)【優先権主張国】CN

(31)【優先権主張番号】201510654384.3

(32)【優先日】2015年10月10日

(33)【優先権主張国】CN

(31)【優先権主張番号】201510698388.1

(32)【優先日】2015年10月23日

(33)【優先権主張国】CN

(73)【特許権者】

【識別番号】507190994

【氏名又は名称】上海交通大学

【氏名又は名称原語表記】ＳＨＡＮＧＨＡＩ ＪＩＡＯ ＴＯＮＧ ＵＮＩＶＥＲＳＩＴＹ

(74)【代理人】

【識別番号】100205936

【弁理士】

【氏名又は名称】崔 海龍

(74)【代理人】

【識別番号】100132805

【弁理士】

【氏名又は名称】河合 貴之

(72)【発明者】

【氏名】徐 異凌

(72)【発明者】

【氏名】張 文軍

(72)【発明者】

【氏名】王 成志

(72)【発明者】

【氏名】孫 軍

(72)【発明者】

【氏名】管 云峰

(72)【発明者】

【氏名】何 大治

(72)【発明者】

【氏名】柳 寧

【審査官】 冨田 高史

(56)【参考文献】

【文献】 特開２０１５−０５０７６８（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｎ ２１／００ − ２１／８５８

Ｇ０６Ｆ １３／００

(57)【特許請求の範囲】

【請求項1】

ＭＭＴにおけるシグナリングの部分においてメディアコンテンツのＡｖａｉｌａｂｌｅ＿ＴｉｍｅおよびＡｓｓｅｔ＿Ｓｉｚｅ属性を追加することにより、クライアント端末が対応するメディアコンテンツの獲得可能な時間を取得できるようにするとともに、クライアント端末はネットワークにおける対応する方法によって、現在の広帯域ネットワークにおけるネットワーク帯域幅および広帯域を介してクライアント端末まで伝送されるコンテンツのネットワークにおける遅延を確定し、広帯域ソースコンテンツの獲得可能時間および広帯域チャネルの遅延に基づいて、クライアント端末が予めキャッシュを行う請求を送信する時間区間および端末に必要とされるキャッシュ窓の大きさを演算することを特徴とする、異種ネットワーク伝送における動的時間窓およびキャッシュの演算方法。

【請求項2】

ＭＭＴシグナリングにおいて必要するコンテンツに対して新しい属性であるＡｖａｉｌａｂｌｅ＿ＴｉｍｅおよびＡｓｓｅｔ＿Ｓｉｚｅを追加して、広帯域における伝送待ちの該コンテンツのプロバイダーにおける準備の整え、伝送開始可能時間および該部分のコンテンツの大きさの説明に用い、Ａｖａｉｌａｂｌｅ＿Ｔｉｍｅの値の代入は、以下のルールに従うことを特徴とする請求項１に記載の動的時間窓およびキャッシュの演算方法。
１）時間未知
サーバ側が伝送待ちコンテンツの準備を整える時間を確定できない場合、Ａｖａｉｌａｂｌｅ＿Ｔｉｍｅには「ｕｎｋｎｏｗｎ」を代入し、また、サーバ側から送信してきたシグナリングにおいてＡｖａｉｌａｂｌｅ＿Ｔｉｍｅ属性が含まれなかった場合端末は、Ａｖａｉｌａｂｌｅ＿Ｔｉｍｅは未知であると解析する；
２）随時アクセス可能
サーバ側のメディアコンテンツが随時にアクセスおよび送信できる場合、Ａｖａｉｌａｂｌｅ＿Ｔｉｍｅには「ａｎｙｔｉｍｅ」を代入する；
３）特定の時刻に開始し、その後ずっと有効
サーバ側のコンテンツが特定の時刻からずっと有効である場合、Ａｖａｉｌａｂｌｅ＿Ｔｉｍｅには該特定のＵＴＣ時間、「（ＵＴＣ１）」を代入する；
４）特定の時間区間において有効
サーバ側のコンテンツが特定の時間区間において獲得可能な場合、Ａｖａｉｌａｂｌｅ＿Ｔｉｍｅには該時間区間、「（ＵＴＣ１）−（ＵＴＣ２）」を代入する；
Ａｖａｉｌａｂｌｅ＿Ｔｉｍｅに対する解析作業は端末において行なわれる；

【請求項3】

端末が獲得できるＣＩファイルに含まれている属性は既に対象の正常開始表示時間−ｂｅｇｉｎを含んでおり、ネットワーク内においてＨＲＢＭ ｍｅｓｓａｇｅまたはＡＲＱ情報を送信することによって、現在の広帯域ネットワークにおけるアップリンク遅延−Ｄ_ｆ、ダウンリンク遅延−Ｄ_ｔ、広帯域ネットワークの帯域幅−Ｂａｎｄｗｉｄｔｈを獲得し、シグナリングにおいて広帯域コンテンツが獲得可能な時間の属性Ａｖａｉｌａｂｌｅ＿ＴｉｍｅおよびＡｓｓｅｔ＿Ｓｉｚｅを追加した後、一つの閾値Ｔｈｒｅｓｈｏｌｄを設定して、ダウンリンク遅延Ｄ_ｔが該閾値より小さい場合、該遅延を無視し、システムは広帯域伝送のメディアコンテンツのために例外的なキャッシュを割り当てる必要がなく、一方、Ｄ_ｔが該閾値より大きい場合、広帯域におけるメディアコンテンツを予め送信することを請求する時間区間確定し、端末のためにキャッシュ窓を割り当て、ネットワーク遅延がより大きく、コンテンツのプロバイダーにより提供されるＡｖａｉｌａｂｌｅ＿Ｔｉｍｅが予めキャッシュを行って同期を保持する条件を満たさない場合、該広帯域ネットワークのチャネルにより伝送するコンテンツを直接廃棄する、ことを特徴とする請求項１または２に記載の異種ネットワーク伝送における動的時間窓およびキャッシュの演算方法。

【請求項4】

前記広帯域におけるメディアコンテンツを予め送信することを請求する時間区間確定し、端末のためにキャッシュ窓を割り当てることは、
１）シグナリングにおいて対応するコンテンツのＡｖａｉｌａｂｌｅ＿ＴｉｍｅおよびＡｓｓｅｔ＿Ｓｉｚｅ属性を追加すること、
２）クライアント端末は、ネットワークにおける対応する方法によって、現在の広帯域ネットワークにおけるアップリンク遅延Ｄ_ｆ、ダウンリンク遅延Ｄ_ｔおよび広帯域ネットワークの帯域幅Ｂａｎｄｗｉｄｔｈを獲得すること、
３）クライアントは、シグナリングを解析することによって対応するメディアコンテンツの獲得可能な時間Ａｖａｉｌａｂｌｅ＿Ｔｉｍｅ、正常再生時間ｂｅｇｉｎおよび対応するコンテンツの大きさＡｓｓｅｔ＿Ｓｉｚｅを獲得すること、
４）Ｄ_ｆ＜Ｔｈｒｅｓｈｏｌｄの場合、遅延を無視し、一方、Ｄ_ｔ＞Ｔｈｒｅｓｈｏｌｄの場合、以下の（１）〜（５）の方法によって端末が請求を送信する時間窓および端末が割り当てるキャッシュの大きさを演算すること、
を含むことを特徴とする請求項３に記載の動的時間窓およびキャッシュの演算方法。
（１）プロバイダーが一つのコンテンツユニットを伝送するのに必要な時間Ｄａｔａ＿Ｔｒａｎｓｆｅｒ＿Ｔｉｍｅを演算し、該時間は一つのコンテンツユニットの大きさと現在の広帯域環境におけるビットレートを演算することによって獲得できる；
（２）Ａｖａｉｌａｂｌｅ＿Ｔｉｍｅが“ｕｎｋｎｏｗｎ”であるまたはＣＩにおいて該属性がない場合、処理を行わず、Ａｖａｉｌａｂｌｅ＿Ｔｉｍｅが“ａｎｙｔｉｍｅ”である場合、該ステップを飛ばして（３）に処理を移り、Ａｖａｉｌａｂｌｅ＿Ｔｉｍｅが一つの特定なＵＴＣ時間の区間である場合、最も早い時間をもって「数１」に示す判断を行い、

【数1】

「数１」の条件が成立しない場合、伝送待ちのメディアコンテンツを獲得可能な時間が遅すぎて、現在のネットワークの遅延においては端末に到達できないことを表すため、該部分のコンテンツを廃棄し、一方、「数１」の条件が成立する場合、現在のネットワークの遅延による非同期の問題は予めキャッシュすることによって解決でき、次のステップの演算を行う；
（３）端末が予めメディアコンテンツの送信を請求する時間区間を演算し、具体的には、
もっとも早い請求時間は、「数２」により演算し、

【数2】

もっとも遅い請求時間は、「数３」により演算し、

【数3】

実際の請求時間は二つの時間点の間にあり、「数４」に示すとおりである；

【数4】

（４）端末が一つの請求時間を選択すると、端末によりプロバイダーのデータを受信可能な開始時間は、「数５」により演算し、

【数5】

端末がｂｅｇｉｎ時間点より前にデータを受信する時間は、「数６」により演算する；

【数6】

（５）ＣＩにおいてＡｓｓｅｔ＿Ｓｉｚｅ属性が示された場合、端末が割り当てるキャッシュ窓の大きさは、「数７」により演算し、

【数7】

一方、ＣＩにおいてＡｓｓｅｔ＿Ｓｉｚｅ属性が示されない場合、端末が割り当てるキャッシュ窓の大きさは、「数８」により演算する；

【数8】

【請求項5】

ＭＭＴにおけるシグナリングについて、ＭＰＴ表、ＣＩファイルまたはＭＰＵのシグナリング部分においてメディアコンテンツのＡｖａｉｌａｂｌｅ＿Ｔｉｍｅを追加し、Ａｖａｉｌａｂｌｅ＿Ｔｉｍｅにより対応するメディアコンテンツの獲得可能な時間をクライアント端末に通知し、クライアント端末は現在のネットワークにおけるネットワーク帯域幅およびネットワークのアップリンクおよびダウンリンクの遅延を確定し、ソースコンテンツの獲得可能な時間および遅延に基づいて、クライアント端末が異なるサーバに応じるコンテンツ情報について予めキャッシュを行う請求を送信する時間区間を演算し、
ＭＰＴにおけるＭＭＴ＿ｇｅｎｅｒａｌ＿ｌｏｃａｔｉｏｎ＿ｉｎｆｏ（）の予備フィールドにおいて、ａｓｓｅｔの獲得可能な時間Ａｖａｉｌａｂｌｅ＿Ｔｉｍｅ情報を追加することにより、リソース請求メッセージの処理において異なる処理方法を有するサーバに対して、Ａｖａｉｌａｂｌｅ＿Ｔｉｍｅ時間窓の演算する、
ことを特徴とする異種メディア伝送ネットワークにおけるリソースを動的に請求する方法。

【請求項6】

前記ＭＰＴにおけるＭＭＴ＿ｇｅｎｅｒａｌ＿ｌｏｃａｔｉｏｎ＿ｉｎｆｏ（）の予備フィールドにおいて、ａｓｓｅｔの獲得可能な時間Ａｖａｉｌａｂｌｅ＿Ｔｉｍｅ情報を追加することは、
まず、元のシグナリングにおいて各部分のコンテンツに対してともに新しい属性であるａｖａｉｌａｂｌｅ＿ｂｅｇｉｎおよびａｖａｉｌａｂｌｅ＿ｅｎｄを追加することにより、現在のネットワークにおける伝送待ちの該コンテンツのプロバイダーにおける準備の整え、伝送開始可能時間、およびアクセス終了時間の説明に用い
ＭＰＴにおけるＭＭＴ＿ｇｅｎｅｒａｌ＿ｌｏｃａｔｉｏｎ＿ｉｎｆｏ（）記述子は、メディアリソースおよび関連するシグナリングのソース情報を提供し、ｌｏｃａｔｉｏｎ＿ｔｙｐｅは０ｘ００〜０ｘ０６、０ｘ０Ｃの値が対応するａｓｓｅｔリソースの位置情報、０ｘ０７〜０ｘ０Ｂの値が対応するシグナリングのソース情報、０ｘ０Ｄ〜０ｘ９ＦによるＩＳＯのための予備フィールド、および０ｘＡ０〜０ｘＦＦによるシステム専用のための予備フィールドであり、予備されるｌｏｃａｔｉｏｎ＿ｔｙｐｅフィールドにおいて、位置ソースが異なるリソースの獲得可能な時間情報を追加する、
ことを特徴とする請求項５に記載の異種メディア伝送ネットワークにおけるリソースを動的に請求する方法。

【請求項7】

追加する定義のフィールドａｖａｉｌａｂｌｅ＿ｂｅｇｉｎおよびａｖａｉｌａｂｌｅ＿ｅｎｄは、
ａｖａｉｌａｂｌｅ＿ｂｅｇｉｎ：メディアリソースの最も早い獲得可能な時間であり、フィールドが全部０である場合、該リソースの最も早い獲得可能な時間が未知であることを示し、フィールドが全部１である場合、該リソースの最も早い獲得可能な時間が現在の時間より早いことを示す；
ａｖａｉｌａｂｌｅ＿ｅｎｄ：メディアリソースのもっとも遅い獲得可能な時間であり、フィールドが全部０である場合、該リソースの最も遅い獲得可能な時間が未知であることを示し、フィールドが全部１である場合、該リソースの準備が整えた後にいつでも獲得できることを示す；
ことを特徴とする請求項６に記載の異種メディア伝送ネットワークにおけるリソースを動的に請求する方法。

【請求項8】

ａｖａｉｌａｂｌｅ＿ｂｅｇｉｎおよびａｖａｉｌａｂｌｅ＿ｅｎｄの使い方は、
（１）あるリソースが一つの時間帯において獲得可能である場合、新規追加の属性にそれぞれ以下の値を代入し、
ａｖａｉｌａｂｌｅ＿ｂｅｇｉｎには開始時間「ＵＴＣ１」との値を代入し、ａｖａｉｌａｂｌｅ＿ｅｎｄには終了時間「ＵＴＣ２」との値を代入する；
（２）あるリソースがある時刻からいつでも獲得可能である場合、新規追加の属性にそれぞれ以下の値を代入し、
ａｖａｉｌａｂｌｅ＿ｂｅｇｉｎには開始時間「ＵＴＣ１」との値を代入し、ａｖａｉｌａｂｌｅ＿ｅｎｄフィールドには全部１を代入する；
（３）あるリソースが任意の時間において獲得可能である場合、新規追加の属性にそれぞれ以下の値を代入し、
ａｖａｉｌａｂｌｅ＿ｂｅｇｉｎフィールドには全部１を代入し、ａｖａｉｌａｂｌｅ＿ｅｎｄフィールドには全部１を代入する；
（４）あるリソースの獲得可能な状況が未知である場合、新規追加の属性にそれぞれ以下の値を代入し、
ａｖａｉｌａｂｌｅ＿ｂｅｇｉｎフィールドには全部０を代入し、ａｖａｉｌａｂｌｅ＿ｅｎｄフィールドには全部０を代入する；
ということを特徴とする請求項７に記載の異種メディア伝送ネットワークにおけるリソースを動的に請求する方法。

【請求項9】

前記Ａｖａｉｌａｂｌｅ＿Ｔｉｍｅ時間窓を演算することは、
実際の応用において、サーバｓｅｒｖｅｒは二つタイプがあり、リソース請求を受信した場合、Ａタイプのサーバはリソースの準備が整えていないと、直接エラーメッセージを返し、Ｂタイプのサーバはリソースの準備が整えていないと、すぐにはメッセージを返さず、リソースの準備が整えるまで待ってから、該リソースを送信し、
Ａタイプのサーバについて、クライアント端末がシグナリングを解析してメディアリソースのＡｖａｉｌａｂｌｅ＿Ｔｉｍｅを得た後、「数９」に示すように、動的に該リソースの時間窓を請求し、

【数9】

もっとも早い請求時間Ｅａｒｌｉｅｓｔ＿Ｒｅｑｕｅｓｔ＿Ｔｉｍｅは、「数１０」により演算し、

【数10】

もっとも遅い請求時間Ｌａｔｅｓｔ＿Ｒｅｑｕｅｓｔ＿Ｔｉｍｅは、「数１１」により演算し、

【数11】

実際の請求時間は二つの時間点の間にあり、「数１２」に示すとおりであり、

【数12】

ここで、Ｄ_ｆは現在のメディアネットワークにおけるアップリンク遅延であり、Ｄ_ｔは現在のメディアネットワークにおけるダウンリンク遅延であり、Ｄａｔａ＿Ｔｒａｎｓｆｅｒ＿Ｔｉｍｅは該サーバが該メディアリソースを送信するのに必要な時間であり、
一方、Ｂタイプのサーバの場合、クライアント端末のＡｖａｉｌａｂｌｅ＿Ｔｉｍｅの演算方法は下記のとおりであり、
Ｂタイプのサーバはまずは請求メッセージを受信し、リソースの準備が整えるまで待ってからリソースを送信できるため、クライアント端末はシグナリングを解析してあるリソースの存在を確認することだけでリソースを請求するメッセージを送信するため、Ｂタイプのサーバのクライアントに対して、もっとも早い請求時間Ｅａｒｌｉｅｓｔ＿Ｒｅｑｕｅｓｔ＿Ｔｉｍｅおよびもっとも遅い請求時間Ｌａｔｅｓｔ＿Ｒｅｑｕｅｓｔ＿Ｔｉｍｅは、「数１３」および「数１４」により演算する、

【数13】

【数14】

ことを特徴とする請求項５ないし請求項８のいずれか一項に記載の異種メディア伝送ネットワークにおけるリソースを動的に請求する方法。

【請求項10】

サーバが通知Ａｖａｉｌａｂｌｅ＿Ｔｉｍｅシグナリングを送信する時間窓の演算方法は、
一部のメディア伝送ネットワークにおいて、サーバがあるリソースのＡｖａｉｌａｂｌｅ＿Ｔｉｍｅの時刻がＴ_０であると仮定すると、該Ｔ_０が遅い場合には、送信側がシグナリングを送信してから、クライアント端末が関連するシグナリングを受信する時間も遅くなるため、クライアント端末が正確な請求時間窓を演算したとしても、現在の時刻が既にＬａｔｅｓｔ＿Ｒｅｑｕｅｓｔ＿Ｔｉｍｅより遅いため、リソースの請求は依然として失敗し、
該場合において、サーバがシグナリングの送信時間を確定するメカニズムを以下に示すように、
サーバにおいて、同じ方法によってクライアント端末が動的にリソースを請求する時間窓を演算してから、まずは「数１５」に示す判断を行い、

【数15】

「数１５」の条件が成立しない場合、Ｒｅｃｅｉｖｅｒがもっとも早くてもＬａｔｅｓｔ＿Ｒｅｑｕｅｓｔ＿Ｔｉｍｅの後にシグナリングにおけるＡｖａｉｌａｂｌｅ＿Ｔｉｍｅ属性を獲得するしかないことを示し、リソースを請求できず、関連するシグナリングを送信せず、
一方、「数１５」の条件が成立する場合、ＲｅｃｅｉｖｅｒがＬａｔｅｓｔ＿Ｒｅｑｕｅｓｔ＿Ｔｉｍｅの前にシグナリングにおけるＡｖａｉｌａｂｌｅ＿Ｔｉｍｅ属性を獲得できることを示すため、続いて「数１６」および「数１７」に基づいてシグナリングを送信する時間の区間を獲得すること、

【数16】

【数17】

を設けることを特徴とする請求項９に記載の異種メディア伝送ネットワークにおけるリソースを動的に請求する方法。

【請求項11】

ＭＭＴにおけるシグナリングについて、シグナリング、ＣＩまたはＭＰＵにおいてメディアリソースの獲得可能な時間の属性を追加することにより対応するメディアリソースの獲得可能な時間をクライアント側に通知し、
対応するメディアリソースの獲得可能な時間をクライアント側に通知するための前記メディアリソースの獲得可能な時間の属性の追加は、方法一として、シグナリングにおいて一つの新しい記述子ＡＴ＿ｄｅｓｃｒｉｐｔｏｒを追加することによりメディアリソースの獲得可能な時間を記述することにより実現し、
前記方法一は、
記述子ＡＴ＿ｄｅｓｃｒｉｐｔｏｒにおいてａｓｓｅｔの獲得可能な時間情報を追加し、ＡＴ＿ｄｅｓｃｒｉｐｔｏｒにおいて新しい属性を定義することにより、現在のネットワークにおける伝送待ちの該コンテンツのプロバイダーにおける準備の整え、伝送開始可能時間、及びアクセス終了時間の説明に用い、ＡＴ＿ｄｅｓｃｒｉｐｔｏｒにおいて定義された新しい属性はｌｏｃａｔｉｏｎ＿ｉｎｄｅｘ、ａｖａｉｌａｂｌｅ＿ｂｅｇｉｎとａｖａｉｌａｂｌｅ＿ｅｎｄを含んでおり、さらに選択的属性としてａｖａｉｌａｂｌｅ＿ｔｉｍｅ＿ｃｏｕｎｔとｌｏｃａｔｉｏｎ＿ｃｏｕｎｔとの一つを含むことができる、ことを特徴とする異種メディアネットワークにおける動的にリソースの獲得可能な時間を提供する方法。

【請求項12】

前記方法一において、
ａｖａｉｌａｂｌｅ＿ｔｉｍｅ＿ｃｏｕｎｔは、ＭＰＴにおける異なるｌｏｃａｔｉｏｎ＿ｔｙｐｅの対応する獲得可能な時間の情報の数であり、
ｌｏｃａｔｉｏｎ＿ｃｏｕｎｔは、ＭＰＴにおける異なるｌｏｃａｔｉｏｎソースの数であり、
ｌｏｃａｔｉｏｎ＿ｉｎｄｅｘは、索引番号であり、現在の記述子が記述する情報の対応する異なるアドレスソースのＭＭＴ＿ｇｅｎｅｒａｌ＿ｌｏｃａｔｉｏｎ＿ｉｎｆｏ（）であり、
ａｖａｉｌａｂｌｅ＿ｂｅｇｉｎは、メディアリソースの最も早い獲得できる時間であり、フィールドが全部０である場合、該リソースの最も早い獲得可能な時間が未知であることを示し、フィールドが全部１である場合、該リソースの最も早い獲得可能な時間が現在の時間より早いことを示し、
ａｖａｉｌａｂｌｅ＿ｅｎｄは、メディアリソースの最も遅い獲得可能な時間であり、フィールドが全部０である場合、該リソースの最も遅い獲得可能な時間が未知であることを示し、フィールドが全部１である場合、該リソースの準備が整えた後にいつでも獲得可能であることを示すということを特徴とする請求項１１に記載の異種メディアネットワーク伝送における動的にリソースの獲得可能な時間を提供する方法。

【請求項13】

ＭＭＴにおけるシグナリングについて、シグナリング、ＣＩまたはＭＰＵにおいてメディアリソースの獲得可能な時間の属性を追加することにより対応するメディアリソースの獲得可能な時間をクライアント側に通知し、
対応するメディアリソースの獲得可能な時間をクライアント側に通知するための前記メディアリソースの獲得可能な時間の属性の追加は、方法二として、シグナリングＭＰＴにおいてメディアリソースの獲得可能な時間の属性を追加し、クライアント端末はシグナリングにおけるメディアリソースの獲得可能な時間によって、対応する区間内においてメディアのリソースを予め請求することにより実現し、
前記方法二は、
シグナリングＭＰＴにおけるＭＭＴ＿ｇｅｎｅｒａｌ＿ｌｏｃａｔｉｏｎ＿ｉｎｆｏ（）の予備フィールドにおいて、ａｓｓｅｔの獲得可能な時間情報を追加し、
元のＭＭＴ＿ｇｅｎｅｒａｌ＿ｌｏｃａｔｉｏｎ＿ｉｎｆｏ（）において各部分のコンテンツに対してともに新しい属性であるａｖａｉｌａｂｌｅ＿ｂｅｇｉｎおよびａｖａｉｌａｂｌｅ＿ｅｎｄを追加することにより、現在のネットワークにおける伝送待ちの該コンテンツのプロバイダーにおける準備の整え、伝送開始可能時間、およびアクセス終了時間の説明に用いる、ことを特徴とする異種メディアネットワークにおける動的にリソースの獲得可能な時間を提供する方法。

【請求項14】

前記方法二において、
ａｖａｉｌａｂｌｅ＿ｂｅｇｉｎは、メディアリソースの最も早い獲得可能な時間であり、フィールドが全部０である場合、該リソースの最も早い獲得可能な時間が未知であることを示し、フィールドが全部１である場合、該リソースの最も早い獲得可能な時間が現在の時間より早いことを示し、
ａｖａｉｌａｂｌｅ＿ｅｎｄは、メディアリソースのもっとも遅い獲得可能な時間であり、フィールドが全部０である場合、該リソースの最も遅い獲得可能な時間が未知であることを示し、フィールドが全部１である場合、該リソースの準備が整えた後にいつでも獲得できることを示すということを特徴とする請求項１３に記載の異種メディアネットワーク伝送における動的にリソースの獲得可能な時間を提供する方法。

【請求項15】

ＭＰＴにおけるＭＭＴ＿ｇｅｎｅｒａｌ＿ｌｏｃａｔｉｏｎ＿ｉｎｆｏ（）記述子は、メディアリソースおよび関連するシグナリングのソース情報を提供し、ｌｏｃａｔｉｏｎ＿ｔｙｐｅは０ｘ００〜０ｘ０６、０ｘ０Ｃの値が対応するａｓｓｅｔリソースの位置情報、０ｘ０７〜０ｘ０Ｂの値が対応するシグナリングのソース情報、０ｘ０Ｄ〜０ｘ９ＦによるＩＳＯのための予備フィールド、および０ｘＡ０〜０ｘＦＦによるシステム専用のための予備フィールドであり、予備されるｌｏｃａｔｉｏｎ＿ｔｙｐｅフィールドにおいて、位置ソースが異なるリソースの獲得可能な時間情報を追加する、ことを特徴とする請求項１４に記載の異種メディアネットワーク伝送における動的にリソースの獲得可能な時間を提供する方法。

【請求項16】

ａｖａｉｌａｂｌｅ＿ｂｅｇｉｎおよびａｖａｉｌａｂｌｅ＿ｅｎｄの使い方は、
（１）あるリソースが一つの時間帯において獲得可能である場合、新規追加の属性にそれぞれ以下の値を代入し、
ａｖａｉｌａｂｌｅ＿ｂｅｇｉｎには開始時間「ＵＴＣ１」との値を代入し、ａｖａｉｌａｂｌｅ＿ｅｎｄには終了時間「ＵＴＣ２」との値を代入する；
（２）あるリソースがある時刻からいつでも獲得可能である場合、新規追加の属性にそれぞれ以下の値を代入し、
ａｖａｉｌａｂｌｅ＿ｂｅｇｉｎには開始時間「ＵＴＣ１」との値を代入し、ａｖａｉｌａｂｌｅ＿ｅｎｄフィールドには全部１を代入する；
（３）あるリソースが任意の時間において獲得可能である場合、新規追加の属性にそれぞれ以下の値を代入し、
ａｖａｉｌａｂｌｅ＿ｂｅｇｉｎフィールドには全部１を代入し、ａｖａｉｌａｂｌｅ＿ｅｎｄフィールドには全部１を代入する；
（４）あるリソースの獲得可能な状況が未知である場合、新規追加の属性にそれぞれ以下の値を代入し、
ａｖａｉｌａｂｌｅ＿ｂｅｇｉｎフィールドには全部０を代入し、ａｖａｉｌａｂｌｅ＿ｅｎｄフィールドには全部０を代入する、
ということを特徴とする請求項１１ないし１５のいずれか一項に記載の異種メディアネットワーク伝送における動的にリソースの獲得可能な時間を提供する方法。

【請求項17】

前記方法は、さらに、シグナリングにおいてａｖａｉｌａｂｌｅ＿ｔｉｍｅ＿ｆｌａｇとする予備フィールドを設けることにより、クライアントに現在のメディアリソースの獲得可能な時間を送信できるか否かを通知する、ことを特徴とする請求項１１ないし１５のいずれか一項に記載の異種メディアネットワーク伝送における動的にリソースの獲得可能な時間を提供する方法。

【請求項18】

現時サーバが資源の獲得可能の時間に関するメッセージを発信したかどうかを指示するために、ＭＰＴの予備フィールドにおいて一つのビットをａｖａｉｌａｂｌｅ＿ｔｉｍｅ＿ｆｌａｇとして、現在のサーバがリソースの獲得可能な時間の情報を送信したか否かを示すために用い、ａｖａｉｌａｂｌｅ＿ｔｉｍｅ＿ｆｌａｇフィールドが０である場合、メディアリソースの獲得可能な時間が整えていなくて、関連するシグナリングを発信しないことを示し、フィールドが１である場合、メディアリソースの獲得可能な時間の情報がシグナリングとともに送信されたことを示す、ことを特徴とする請求項１７に記載の異性メディアネットワーク伝送における動的にリソースの獲得可能な時間を提供する方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は異種ネットワーク伝送におけるクライアント端末の動的時間請求窓およびキャッシュメカニズムに関し、具体的には端末のメディアコンテンツの送信を請求する時間区間、およびキャッシュ窓の大きさの配分方法の確定に関する。

【背景技術】

【0002】

時代の変化とともに、人々は、単なる従来のテレビに頼って情報を取得し、レジャーを行うことには満足しなくなり、インターネットに接続するＰＣ、ほぼ一人に一台ほどの携帯電話およびより普及しつつあるタブレットＰＣなど、多くの端末設備が我々の目の前に現れてきている。これらの新しい製品は、既に従来のテレビ業務のシェアを分解している。モバイル通信および広帯域ワイヤレス技術の発展、ならびにマルチメディア業務の成長につれて、異なる技術の融合は既に情報通信分野の発展の流れとなっており、ユーザが簡単にネットワークに接続できるようにし、またより豊かなメディアコンテンツと多様化されたサービスを気楽に利用できるようにしている。

【0003】

これに伴い、メディアコンテンツの表示は単なるビデオ、オーディオ、字幕ではなくなり、メディアのタイプはますます多種多様になりつつある。そして、メディアのソース（出所）も特定のコンテンツ提供者に限らず、より多くの製作者が参入されている。多くの個人ユーザは、コンテンツの提供者であるとともに製作者でもある。いろんな提供者からのコンテンツの間には、各種の関連関係を有しており、異なるユーザの個性化された要請を満たすために、往々にしてはこれらの関連コンテンツを同期に表示する必要がある。このような環境のもとにおいて、次世代ネットワークの発展趨勢となる異種ネットワークの融合は、未来における通信は特定の接続技術ではなくなり、多種類の接続技術が共存し、共同で作業することを十分に説明している。

【0004】

放送および広帯域により構成される異種ネットワークにおいて、端末に表示されるメディアコンテンツは、同時に放送および広帯域チャンネルから伝送されうる。異種ネットワークにおける端末の表示については、表示情報（ＣＩ、Ｃｏｍｐｏｓｉｔｉｏｎ Ｉｎｆｏｒｍａｔｉｏｎ）に基づく多ソースコンテンツ割り当てメカニズムが存在している。ＣＩでは、ＨＴＭＬ５とＸＭＬなどの技術を採用して、メディアデータに関する時間的および空間的情報を提供することによりマルチメディアのデータが端末において多様化に表示できるようにしている。

【0005】

端末は、シグナリングにおける情報に基づいて、サーバ側から関連するコンテンツを請求できるが、サーバ側が請求を受信する場合、関連するコンテンツは、既に整えられている場合もあればそうでない場合もある。そこで、関連するコンテンツが整えられていない場合、端末の請求は失敗してしまい、その後に関連するコンテンツが獲得できるまで請求を続ける必要がある。これは端末に莫大な負担をかけるとともに、ネットワークへの負担も増やしてしまう。

【0006】

なお、現在の広帯域ネットワークは、複数のノードにおいてコンテンツを転送する必要があるため、ネットワークに遅延が生じることやひいてはネットワークが混雑するなどの問題を有する。このため、端末においてコンテンツが再生できない、またはメディアコンテンツが同期に再生できない問題を解決するためには、受信側において予めコンテンツをキャッシュしておく必要がある。

【0007】

しかしながら、キャッシュの導入はまた新しい問題をもたらしてしまう。即ち、端末において予めどのくらいのコンテンツをキャッシュすればよいか、どのタイミングからキャッシュすればよいかは、何れもクライアント端末設備の規格およびシステムの性能に影響を及ぼしてしまう。このため、クライアント側におけるキャッシュ窓の大きさとキャッシュする時間は、解決しなければならない問題となっている。

【0008】

一方で、サーバ側のメディアコンテンツ提供が遅すぎると、端末のユーザは迅速に関連するリソースを獲得できない。このため、特定のネットワークメディアサービスのもとにおいて、サーバ側がメディアの準備を整えた時間を端末に通知するか否か、およびいつ通知するかということも、解決しなければならない問題となっている。

【発明の概要】

【発明が解決しようとする課題】

【0009】

本発明は、既存技術における問題に鑑みてなされたものであり、異種ネットワークにおいて端末が請求時間の窓およびキャッシュ窓の大きさを自己適応的に調節する方法を提供することにより放送および広帯域により構成される異種ネットワークにおける端末において、広帯域の混雑に起因されるコンテンツの同期化ができない問題を解決するとともに、キャッシュによるクライアント側の更なる消費を低減する。

【課題を解決するための手段】

【0010】

本発明の第一の目的として、異種ネットワーク伝送におけるネットワークの混雑などに起因される関連するリソースが同期に再生できない問題を解決するため、本発明に係る異種ネットワーク伝送における動的時間窓およびキャッシュを演算する方法は、ＭＭＴにおけるシグナリング部分においてメディアコンテンツのＡｖａｉｌａｂｌｅ＿ＴｉｍｅおよびＡｓｓｅｔ＿Ｓｉｚｅ属性を追加ことにより対応するメディアコンテンツを獲得可能な時間をクライアント端末に送信し、クライアント端末はネットワークにおける対応する方法によって、現在の広帯域ネットワークにおける帯域幅および広帯域からクライアント端末までのコンテンツのネットワークにおける遅延を確定し、広帯域ソースコンテンツの獲得可能な時間および広帯域チャンネルの遅延に基づいて、クライアント端末が予めキャッシュを行う請求を送信する時間区間および端末に必要とされるキャッシュ窓の大きさを演算する。

【0011】

また、本発明の第二の目的を達成するため、本発明は異種メディア伝送ネットワークにおけるリソースの動的請求方法を提供することにより異種メディアネットワーク伝送におけるサーバがメディアリソースシグナリングを送信し、および端末が該メディアリソースの時間窓を動的請求するメカニズムを実現する。

【0012】

前記異種メディア伝送ネットワークにおけるリソースの動的請求方法は、ＭＭＴにおけるシグナリングについて、ＭＰＴ表、ＣＩファイルまたはＭＰＵのシグナリング部分においてメディアコンテンツのＡｖａｉｌａｂｌｅ＿Ｔｉｍｅを追加し、Ａｖａｉｌａｂｌｅ＿Ｔｉｍｅにより対応するメディアコンテンツの獲得可能な時間をクライアント端末に通知し、クライアント端末は現在のネットワークにおけるネットワーク帯域幅およびネットワークのアップリンクおよびダウンリンクの遅延を確定し、ソースコンテンツの獲得可能な時間および遅延に基づいて、クライアント端末が異なるサーバに応じるコンテンツ情報について予めキャッシュを行う請求を送信する時間区間を演算する。前記方法は、ＭＰＴにおけるＭＭＴ＿ｇｅｎｅｒａｌ＿ｌｏｃａｔｉｏｎ＿ｉｎｆｏ（）の予備フィールドにおいて、ａｓｓｅｔの獲得可能な時間Ａｖａｉｌａｂｌｅ＿Ｔｉｍｅ情報を追加することにより、リソース請求メッセージの処理において異なる処理方法を有するサーバに対して、Ａｖａｉｌａｂｌｅ＿Ｔｉｍｅ時間窓の演算方法を提供する。

【0013】

本発明の第三の目的として、次世代の異種メディアネットワーク伝送システムにおいてリソースの獲得可能な時間を動的に加える問題を解決するため、本発明に係る異種メディアネットワーク伝送におけるリソースの獲得可能な時間を動的に提供する方法は、ＭＭＴにおけるシグナリングについて、シグナリング、ＣＩあるいはＭＰＵにおいてメディアリソースの獲得可能な時間の属性を追加することにより対応するメディアリソースの獲得可能な時間をクライアント側に通知する。ここで、対応するメディアリソースの獲得可能な時間をクライアント側に通知するための前記メディアリソースの獲得可能な時間の属性の追加は、以下の二つの方法のいずれかにより実現する。
方法一：シグナリングにおいて一つの新しい記述子ＡＴ ｄｅｓｃｒｉｐｔｏｒを追加することによりメディアリソースの獲得可能な時間を記述する。
方法二：シグナリングＭＰＴにおいてメディアリソースの獲得可能な時間の属性を追加し、クライアント端末はシグナリングにおけるメディアリソースの獲得可能な時間によって、対応する区間内においてメディアのリソースを予め請求する。

【0014】

さらに、異種メディアネットワーク伝送におけるリソースの獲得可能な時間を動的に提供する前記方法は、同時にシグナリングにおいてａｖａｉｌａｂｌｅ＿ｔｉｍｅ＿ｆｌａｇとする予備フィールドを設けることにより、クライアント側に現在のメディアリソースの獲得可能な時間を送信できるか否かを通知する。

【発明の効果】

【0015】

従来技術に比べると，本発明は以下の有益な効果を有する。
本発明によれば、ＭＭＴにおけるシグナリングについて、シグナリングまたはその他の場所において新しい属性を追加する。クライアント端末は広帯域ネットワークにおける対応する方法により、現在の広帯域ネットワークにおけるネットワーク帯域幅および広帯域からクライアント端末までのコンテンツの一方向ネットワークにおける遅延を確定することによって、広帯域におけるネットワークの混雑によるメディアコンテンツの同期不能という問題を解決し、ＩＰネットワークの渋滞による同期化の関連問題も解決できる。また、異種メディアネットワーク伝送における深刻なネットワーク遅延によるメディアコンテンツが時間通りに表示または同期表示できないという問題を解決できる。さらに、本発明によれば、異種メディアネットワーク伝送において、サーバがメディアリソース品リングを送信することによりメディアネットワークの獲得可能な時間を端末に通知することを実現し、これにより異種メディアネットワーク伝送において、未知なメディアリソースの獲得可能な時間に起因される迅速に請求できないという問題を解決できる。

【図面の簡単な説明】

【0016】

以下、図面を参照しながら、本発明の実施例について詳細に説明することによって、本発明の他の特徴、目的及び利点をより明らかにする。なお、これらの実施例は、本発明を限定するものではない。

【0017】

【図1】異種ネットワークのモデルを示す図である。

【図2】実施例３において異種メディアネットワークのリソース請求モデルを示す図である。

【図3】実施例３においてクライアント側による送信請求の動的時間窓を演算するフローチャートである。

【図4】実施例３においてサーバからのシグナリング送信時間を演算するフローチャートである。

【図5】実施例４において新しいクライアントが新規送信したシグナリングを処理する際のフローチャートである。

【図6】実施例４において古いクライアントが新規送信したシグナリングを処理する際のフローチャートである。

【発明を実施するための形態】

【0018】

以下、具体的な実施形態を例示しながら、本発明について詳しく説明する。以下の実施形態は、いわゆる当業者が本発明をより理解しやすくするための例示であり、いかなる形式により本発明を限定するものではない。また、いわゆる当業者であれば、本発明の要旨から逸脱しない範囲内において、様々な変形や改良を行うことができ、これらも本発明の保護範囲に属することには注意されたい。

【0019】

現在のところ、異種ネットワークに基づく多様化された端末の表示方式はすでに発展の趨勢となってきている。高品質な放送・ビデオ番組を楽しむと同時に、人々の多様化されたネットワークメディアサービスに対する要望も高まりつつある。放送および広帯域ネットワークにより構成される異種システムにおいて、ＣＩによりクライアント側における放送および広帯域のコンテンツに関する時間的および空間的配置を制御し、メディアコンテンツの同期化を実現する。一般的には、放送チャンネルからのメディアコンテンツは小さくて固定の遅延を有するため、同期化に与える影響がない。一方、ビデオ、オーディオ、字幕、マルチメディア応用などの広帯域からのメディアコンテンツは、現在のＩＰネットワークの影響を受けやすく、比較的に大きくて変動する遅延を生じさせるため、コンテンツの同期化に悪影響を与える。また、広帯域からのコンテンツには有効アクセス期限という問題があり、すなわち、ある時刻からアクセス可能で、ある時刻まで有効である。このため、本発明ではコンテンツに関する有効期限の情報を提供し、また端末において予め該情報の送信を請求し、かつ対応するコンテンツのためにキャッシュ窓を割り当てるメカニズムを設計した。

【0020】

〔実施例１〕
本実施例によれば、放送および広帯域により構成される異種ネットワークおいて、端末における広帯域の混雑に起因されるコンテンツの同期不能という問題を解決できるとともに、キャッシュによるクライアント側のさらなる消費を低減できる。本実施例では、表示情報（ＣＩ）ファイルにおいて時間窓の情報を追加する、メディア処理ユニット（ＭＰＵ、Ｍｅｄｉａ Ｐｒｏｃｅｓｓｉｎｎｇ Ｕｎｉｔ）において時間窓の情報を追加する、またはＭＰＴ（ＭＭＴ Ｐａｃｋａｇｅ Ｔａｂｌｅ）においてａｖａｉｌａｂｌｅ＿ｔｉｍｅ＿ｉｎｆｏ（）を追加することによって、時間窓の情報を記述するとともに、時間窓の情報を指定した後の動的請求およびメディアリソースのキャッシュを行う方法を提供する。

【0021】

まず、既存のシグナリングまたはその他の場所において各部分のコンテンツに対してともに新しい属性であるＡｖａｉｌａｂｌｅ＿Ｔｉｍｅを追加して、広帯域における伝送待ちの該コンテンツのプロバイダーにおける準備の整え、伝送開始可能時間、およびアクセス終了時間の説明に用いる。その値の代入は以下のルールに従う。

【0022】

１）時間未知
サーバ側が伝送待ちコンテンツの準備を整える時間を確定できない場合、Ａｖａｉｌａｂｌｅ＿Ｔｉｍｅには「ｕｎｋｎｏｗｎ」を代入する。また、システムの互換性を考慮して、もしサーバ側から送信してきたシグナリングにおいてＡｖａｉｌａｂｌｅ＿Ｔｉｍｅ属性が含まれなかった場合、端末は、Ａｖａｉｌａｂｌｅ＿Ｔｉｍｅは未知であると解析する。

【0023】

２）随時アクセス可能
サーバ側のメディアコンテンツが随時にアクセスおよび送信できる場合、Ａｖａｉｌａｂｌｅ＿Ｔｉｍｅには「ａｎｙｔｉｍｅ」を代入する。

【0024】

３）特定の時刻に開始し、その後ずっと有効
サーバ側のコンテンツが特定の時刻からずっと有効である場合、Ａｖａｉｌａｂｌｅ＿Ｔｉｍｅには該特定のＵＴＣ時間、すなわち「ＵＴＣ１」を代入する。

【0025】

４）特定の時間区間において有効
サーバ側のコンテンツが特定の時間区間において獲得可能な場合、Ａｖａｉｌａｂｌｅ＿Ｔｉｍｅには該時間区間、すなわち「ＵＴＣ１−−ＵＴＣ２」を代入し、括弧内はＵＴＣである。

【0026】

Ａｖａｉｌａｂｌｅ＿Ｔｉｍｅに対する解析作業は端末において行なわれる。

【0027】

同様に、必要に応じてシグナリングまたはその他の場所において各部分のコンテンツに対してＡｓｓｅｔ＿Ｓｉｚｅ属性を追加して、該部分のコンテンツの大きさを表示できる。

【0028】

新規追加の属性であるＡｖａｉｌａｂｌｅ＿ＴｉｍｅとＡｓｓｅｔ＿Ｓｉｚｅのシステムにおける具体的な位置は、必要に応じて異なる場所に追加できる。例えば、ＣＩ、ＭＰＴ、ＭＰＵなどに追加できる。以下ではこれらの位置に追加する例について説明する。

【0029】

以下、ＣＩ、ＭＰＴおよびＭＰＵのそれぞれにおいてＡｖａｉｌａｂｌｅ＿ＴｉｍｅおよびＡｓｓｅｔ＿Ｓｉｚｅ属性を追加する例を示す。
１）ＣＩにおいて新しい属性を追加
ｍｅｄｉａＳｒｃ属性がＭｅｄｉａＳｙｎｃ要素に含まれている場合、新規追加のＡｖａｉｌａｂｌｅ＿ＴｉｍｅおよびＡｓｓｅｔ＿Ｓｉｚｅ属性も、以下の表１に示すとおり、同様に該要素に含ませる。

【表1】

【0030】

一方、ｍｅｄｉａＳｒｃ属性がＭｅｄｉａＳｙｎｃ要素のサブ要素ｓｏｕｒｃｅＬｉｓｔに含まれている場合、新規追加のＡｖａｉｌａｂｌｅ＿ＴｉｍｅおよびＡｓｓｅｔ＿Ｓｉｚｅ属性も、以下の表２に示すとおり、対応するｓｏｕｒｃｅＬｉｓｔに含ませる。

【表2】

【0031】

２）ＭＰＴにおいて新しい属性を追加
ＭＰＴ表における各ａｓｓｅｔにおいて、Ａｓｓｅｔ＿Ｓｉｚｅを追加し、その大きさを説明できる。
コンテンツに複数のソールアドレスがある場合、各ソースアドレスにおける該部分のコンテンツに対してそれぞれ一つのＡｖａｉｌａｂｌｅ＿Ｔｉｍｅを割り当てる。一方、該コンテンツにソースアドレスが一つしかない場合、該アドレスのソースコンテンツに対して一つのＡｖａｉｌａｂｌｅ＿Ｔｉｍｅを割り当てる。具体的な実現方法は複数あるが、以下では二つの方法を例示する。

【0032】

Ａ． ＭＰＴにおいてＡｖａｉｌａｂｌｅ＿Ｔｉｍｅ＿ＴｙｐｅおよびＭＭＴ＿Ａｖａｉｌａｂｌｅ＿Ｔｉｍｅ＿ｉｎｆｏ（）を追加し、四つの場合を例にすると、Ａｖａｉｌａｂｌｅ＿Ｔｉｍｅ＿Ｔｙｐｅに二つのビットを割り当てることにより、Ａｖａｉｌａｂｌｅ＿Ｔｉｍｅの四つの場合を表示することができる。獲得可能な時間に関する分類がさらに多い場合、より多くのビットを割りあてることが考えられる。ＭＭＴ＿Ａｖａｉｌａｂｌｅ＿Ｔｉｍｅ＿ｉｎｆｏ（）では、メディアコンテンツに対する獲得可能な時間または獲得可能な時間区間の情報を説明する。ＭＰＴは、以下の表３および表４に示すとおりである。

【表3】

【表4】

【0033】

Ａｖａｉｌａｂｌｅ＿Ｔｉｍｅ＿Ｔｙｐｅの二つのビットは、獲得可能な時間のタイプを表し、具体的には以下の表５に示すとおりである。

【表5】

【0034】

Ｂ． ＭＰＴにおいてＭＭＴ＿Ａｖａｉｌａｂｌｅ＿Ｔｉｍｅ＿ｉｎｆｏ（）のみを追加し、ＭＭＴ＿Ａｖａｉｌａｂｌｅ＿Ｔｉｍｅ＿ｉｎｆｏ（）では、メディアコンテンツに対する獲得可能な時間または獲得可能な時間区間の情報を説明する。ＭＰＴは、以下の表６および表７に示すとおりである。

【表6】

【表7】

ａｖａｉｌａｂｌｅ＿ｂｅｇｉｎとａｖａｉｌａｂｌｅ＿ｅｎｄの使い方は以下の表８に示すとおりである。

【表8】

【0035】

３）ＭＰＵにおいて新しい属性を追加
ＭＰＵにおいては単一のＭＰＵの大きさを記述しているので、表９に示すとおり、ここではｍｐｕ＿ｓｉｚｅを選択する。

【表9】

【0036】

動的にキャッシュ窓の大きさを割り当てるキャッシュメカニズムの設計思想は、次のとおりである。ＣＩファイルに含まれている既存の属性は既に対象の正常表示開始時間−ｂｅｇｉｎを含んでおり、ＩＣＭＰメッセージを送信する方法などのＩＰネットワークにおける対応する方法により、現在の一方向広帯域ネットワークの遅延ｔ_１と広帯域ネットワークの帯域幅Ｂａｎｄｗｉｄｔｈを獲得できる。シグナリングまたはその他の場所において広帯域コンテンツが獲得可能な時間の属性Ａｖａｉｌａｂｌｅ＿ＴｉｍｅおよびＡｓｓｅｔ＿Ｓｉｚｅを追加した後、一つの閾値Ｔｈｒｅｓｈｏｌｄを設定する。遅延ｔ_１が該閾値より小さい場合、該遅延を無視でき、システムは広帯域伝送のメディアコンテンツのために例外的なキャッシュを割り当てる必要がない。一方、ｔ_１が該閾値より大きい場合、具体的な方法によって広帯域におけるメディアコンテンツを予め送信することを請求する時間区間を確定し、端末のためにキャッシュ窓を割り当てることができる。そして、ネットワークの遅延が非常に大きく、コンテンツのプロバイダーにより提供されるＡｖａｉｌａｂｌｅ＿Ｔｉｍｅが予めキャッシュを行って同期を維持する条件を満たさない場合、該広帯域チャネルにより伝送する補助コンテンツを直接廃棄する。

【0037】

具体的な方法は、以下に示すとおりである（実際の状況に応じて以下のステップを選択し、組み合わせることができる）。

【0038】

１）シグナリングまたはその他の場所において、対応するコンテンツのＡｖａｉｌａｂｌｅ＿ＴｉｍｅおよびＡｓｓｅｔ＿Ｓｉｚｅ属性を追加する。

【0039】

２）クライアント端末は、ＩＣＭＰメッセージを送信する方法などのＩＰネットワークにおける対応する方法により、現在の広帯域ネットワークにおける一方向遅延ｔ_１と広帯域ネットワークの帯域幅Ｂａｎｄｗｉｄｔｈを獲得する。

【0040】

３）クライアント側は、シグナリング（ＭＰＴ、ＣＩなど）を解析することによって対応するメディアコンテンツの獲得可能な時間（Ａｖａｉｌａｂｌｅ＿Ｔｉｍｅ）、正常再生時間（ｂｅｇｉｎ）および対応するコンテンツの大きさ（Ａｓｓｅｔ＿Ｓｉｚｅ）を獲得する。

【0041】

４）ｔ_１＜Ｔｈｒｅｓｈｏｌｄの場合、遅延は無視できる。一方、ｔ_１＞Ｔｈｒｅｓｈｏｌｄの場合、以下の（１）〜（５）の方法によって端末が請求を送信する時間窓および端末が割り当てるキャッシュの大きさを演算する。

【0042】

（１）プロバイダーが一つのコンテンツユニットを伝送するのに必要な時間Ｄａｔａ＿Ｔｒａｎｓｆｅｒ＿Ｔｉｍｅを演算する。該時間は一つのコンテンツユニットの大きさと現在の広帯域環境におけるビットレートを演算することによって獲得できる。

【0043】

（２）Ａｖａｉｌａｂｌｅ＿Ｔｉｍｅが“ｕｎｋｎｏｗｎ”であるまたはＣＩにおいて該属性がない場合、処理を行わない。Ａｖａｉｌａｂｌｅ＿Ｔｉｍｅが“ａｎｙｔｉｍｅ”である場合、該ステップを飛ばして（３）に処理を移る。Ａｖａｉｌａｂｌｅ＿Ｔｉｍｅが一つの特定のＵＴＣ時間、一つの特定のＵＴＣ時間の区間である場合、もっとも早い時間をもって以下の「数１」に示す判断を行う。

【数1】

「数１」の条件が成立しない場合、伝送待ちのメディアコンテンツを獲得可能な時間が遅すぎて、現在のネットワークの遅延においては迅速に端末に到達できないことを表すため、該部分のコンテンツを廃棄する。一方、「数１」の条件が成立する場合、現在のネットワークの遅延による非同期の問題は予めキャッシュすることによって解決できることを表し、次のステップの演算を行う。

【0044】

（３）端末が予めメディアコンテンツの送信を請求する時間区間を演算する。
もっとも早い請求時間は、以下の「数２」により演算できる。

【数2】

もっとも遅い請求時間は、以下の「数３」により演算できる。

【数3】

実際の請求時間は上記二つの時間点の間にあり、以下の「数４」に示すとおりである。

【数4】

【0045】

（４）端末が一つの請求時間を選択すると、端末によりプロバイダーのデータを受信可能な開始時間は、以下の「数５」により演算できる。

【数5】

端末がｂｅｇｉｎ時間点より前にデータを受信する時間は、以下の「数６」により演算できる。

【数6】

【0046】

（５）ＣＩにおいてＡｓｓｅｔ＿Ｓｉｚｅ属性が示された場合、端末が割り当てるキャッシュ窓の大きさは、以下の「数７」により演算できる。

【数7】

一方、ＣＩにおいてＡｓｓｅｔ＿Ｓｉｚｅ属性が示されない場合、端末が割り当てるキャッシュ窓の大きさは、以下の「数８」により演算できる。

【数8】

【0047】

上記方法において使用される変数およびその意味をまとめて表１０に示す。

【表10】

【0048】

以下では、一つの実施例を示す。
クライアント側が対応するシグナリングを受信する場合のシステムの現在の状態は以下の表１１に示すとおりであるとする。ここで、Ｔｈｒｅｓｈｏｌｄを０．１ｓに設定し、Ｄａｔａ＿Ｔｒａｎｓｆｅｒ＿Ｔｉｍｅは一般的には当時のｄａｔａの大きさおよびビットレートに基づいて値が定められ、ここでは３ｓであるとする。

【表11】

【0049】

該シグナリングに含まれている一つの画像およびオーディオファイルの情報は以下の表１２に示すとおりである。

【表12】

【0050】

現在のネットワークの遅延は１０ｓであって、０．１ｓのＴｈｒｅｓｈｏｌｄよりもはるかに大きいことは、１０ｓの広帯域遅延は許容できないことを表し、予めコンテンツの送信を請求することが必要である。

【0051】

Ｉｍａｇｅ．１に対して、その獲得可能な時間は北京時間４：５９：５０以降のあらゆる時間であるが、獲得可能な時間がより後になっているため、上記「数１」の条件を満たさない。すなわち再生するときにコンテンツを端末に送信することができないため、該コンテンツを廃棄する。

【0052】

Ａｕｄｉｏ．１に対して、その獲得可能な時間は北京時間４：５９：２０から４：５９：５０までであり、４：５９：２０は上記「数１」の条件を満たすので、上記「数２」および「数３」によって、以下「数９」に示すように送信を請求する時間区間を演算できる。

【数9】

【0053】

実際の請求時間が、以下の「数１０」に示す時間であるとすると、

【数10】

現在のビットレートが２００Ｋｂ／ｓである場合、各変数パラメータは以下の表１３に示すとおりに取得できる。

【表13】

ここで、Ｂｕｆｆｅｒ＿ＳｉｚｅはΔｔ＊ｂｉｔｒａｔｅとＡｓｓｅｔ＿Ｓｉｚｅとの最小値、即ち２Ｍｂを採用する。

【0054】

上記の実施例において、Ｉｍａｇｅ．１はＡｖａｉｌａｂｌｅ＿Ｔｉｍｅ時間点の確定が遅いため廃棄されるが、Ａｕｄｉｏ．１はＣＩにおいて確定するＡｖａｉｌａｂｌｅ＿ＴｉｍｅとＡｓｓｅｔ＿Ｓｉｚｅによって端末が予め送信を請求すべく時間と準備すべくキャッシュ窓の大きさを取得している。

【0055】

〔実施例２〕
本実施例によれば、放送および広帯域により構成される異種ネットワークにおいて端末における広帯域の混雑に起因されるコンテンツの同期不能という問題を解決できるとともに、キャッシュによるクライアント側の例外的な消費を低減できる。

【0056】

本実施例では、異種ネットワーク伝送におけるリソースを動的に請求する時間窓および端末キャッシュメカニズムを提供し、従来のＭＭＴにおけるシグナリングについて、ＭＰＴ表、ＭＰＵシグナリング部分においてメディアコンテンツのＡｖａｉｌａｂｌｅ＿ＴｉｍｅおよびＡｓｓｅｔ＿Ｓｉｚｅ属性を追加することにより、クライアント端末に対応するメディアコンテンツの獲得可能な時間を知らせる。同時に、クライアント端末はネットワークにおける対応する方法によって、現在の広帯域ネットワークにおけるネットワーク帯域幅およびネットワークのアップリンクとダウンリンクの遅延を確定し、広帯域リソースコンテンツの獲得可能な時間および広帯域チャネルの遅延に基づいて、クライアント端末は予めキャッシュする請求を送信する時間区間および端末が必要とされるキャッシュ窓の大きさを演算する。

【0057】

本実施例では、ＭＰＴ表、ＣＩファイルまたはＭＰＵシグナリング部分においてメディアコンテンツのＡｖａｉｌａｂｌｅ＿ＴｉｍｅおよびＡｓｓｅｔ＿Ｓｉｚｅ属性を追加することにより、クライアント端末に対応するメディアコンテンツの獲得可能な時間を知らせる。該部分の技術的実現方法は実施例１と同様であるが、実施例１と異なる部分は、ネットワークのアップリンクおよびダウンリンクの遅延を確定する方法にある。

【0058】

具体的に、本実施例における動的にキャッシュ窓の大きさを割り当てるキャッシュメカニズムの設計思想は、次のとおりである。ＣＩファイルに含まれている既存の属性は既に対象の正常表示開始時間−ｂｅｇｉｎを含んでおり、ネットワーク内においてＨＲＢＭ ｍｅｓｓａｇｅまたはＡＲＱ情報を送信することによって、現在の広帯域ネットワークにおけるアップリンク遅延−Ｄ_ｆ、ダウンリンク遅延−Ｄ_ｔ、広帯域ネットワークの帯域幅−Ｂａｎｄｗｉｄｔｈを獲得できる。シグナリングまたはその他の場所において広帯域コンテンツが獲得可能な時間の属性Ａｖａｉｌａｂｌｅ＿ＴｉｍｅおよびＡｓｓｅｔ＿Ｓｉｚｅを追加した後、一つの閾値Ｔｈｒｅｓｈｏｌｄを設定する。ダウンリンク遅延Ｄ_ｔが該閾値より小さい場合、該遅延を無視でき、システムは広帯域伝送のメディアコンテンツのために例外的なキャッシュを割り当てる必要がない。一方、Ｄ_ｔが該閾値より大きい場合、具体的な方法によって広帯域におけるメディアコンテンツを予め送信することを請求する時間区間を確定し、端末のためにキャッシュ窓を割り当てることができる。そして、ネットワークの遅延が非常に大きく、コンテンツのプロバイダーにより提供されるＡｖａｉｌａｂｌｅ＿Ｔｉｍｅが予めキャッシュを行って同期を維持する条件を満たさない場合、該広帯域チャネルにより伝送する補助コンテンツを直接廃棄する。

【0059】

具体的な方法は、以下に示すとおりである（実際の状況に応じて以下のステップを選択し、組み合わせることができる）。

【0060】

１）シグナリングまたはその他の場所において、対応するコンテンツのＡｖａｉｌａｂｌｅ＿ＴｉｍｅおよびＡｓｓｅｔ＿Ｓｉｚｅ属性を追加する。

【0061】

２）クライアント端末は、シグナリングを伝送するまたはＡＲＱメッセージを送信するなどのＩＰネットワークにおける対応する方法によって、現在の広帯域ネットワークにおけるアップリンク遅延Ｄ_ｆ、ダウンリンク遅延Ｄ_ｔおよび広帯域ネットワークの帯域幅Ｂａｎｄｗｉｄｔｈを獲得する。

【0062】

３）クライアント側は、シグナリングを解析することによって対応するメディアコンテンツの獲得可能な時間−Ａｖａｉｌａｂｌｅ＿Ｔｉｍｅ、正常再生時間−ｂｅｇｉｎおよび対応するコンテンツの大きさ−Ａｓｓｅｔ＿Ｓｉｚｅを獲得する。

【0063】

４）Ｄ_ｆ＜Ｔｈｒｅｓｈｏｌｄの場合、遅延は無視できる。一方、Ｄ_ｔ＞Ｔｈｒｅｓｈｏｌｄの場合、以下の（１）〜（５）の方法によって端末が請求を送信する時間窓および端末が割り当てるキャッシュの大きさを演算する。

【0064】

（１）プロバイダーが一つのコンテンツユニットを伝送するのに必要な時間Ｄａｔａ＿Ｔｒａｎｓｆｅｒ＿Ｔｉｍｅを演算する。該時間は一つのコンテンツユニットの大きさと現在の広帯域環境におけるビットレートを演算することによって獲得できる。

【0065】

（２）Ａｖａｉｌａｂｌｅ＿Ｔｉｍｅが“ｕｎｋｎｏｗｎ”であるまたはＣＩにおいて該属性がない場合、処理を行わない。Ａｖａｉｌａｂｌｅ＿Ｔｉｍｅが“ａｎｙｔｉｍｅ”である場合、該ステップを飛ばして（３）に処理を移る。Ａｖａｉｌａｂｌｅ＿Ｔｉｍｅが一つの特定のＵＴＣ時間、一つの特定のＵＴＣ時間の区間である場合、もっとも早い時間をもって以下の「数１１」に示す判断を行う。

【数11】

「数１１」の条件が成立しない場合、伝送待ちのメディアコンテンツを獲得可能な時間が遅すぎて、現在のネットワークの遅延においては端末に到達できないことを表すため、該部分のコンテンツを廃棄する。一方、「数１１」の条件が成立する場合、現在のネットワークの遅延による非同期の問題は予めキャッシュすることによって解決できることを表し、次のステップの演算を行う。

【0066】

（３）端末が予めメディアコンテンツの送信を請求する時間区間を演算する。
もっとも早い請求時間は、以下の「数１２」により演算できる。

【数12】

もっとも遅い請求時間は、以下の「数１３」により演算できる。

【数13】

実際の請求時間は上記二つの時間点の間にあり、以下の「数１４」に示すとおりである。

【数14】

【0067】

（４）端末が一つの請求時間を選択すると、端末によりプロバイダーのデータを受信可能な開始時間は、以下の「数１５」により演算できる。

【数15】

端末がｂｅｇｉｎ時間点より前にデータを受信する時間は、以下の「数１６」により演算できる。

【数16】

【0068】

（５）ＣＩにおいてＡｓｓｅｔ＿Ｓｉｚｅ属性が示された場合、端末が割り当てるキャッシュ窓の大きさは、以下の「数１７」により演算できる。

【数17】

一方、ＣＩにおいてＡｓｓｅｔ＿Ｓｉｚｅ属性が示されない場合、端末が割り当てるキャッシュ窓の大きさは、以下の「数１８」により演算できる。

【数18】

【0069】

上記方法において使用される変数およびその意味をまとめて表１４に示す。

【表14】

【0070】

以下では、一つの実施例を示す。
クライアント側が対応するシグナリングを受信する場合のシステムの現在の状態は以下の表１５に示すとおりであるとする。ここで、Ｔｈｒｅｓｈｏｌｄを０．１ｓに設定し、Ｄａｔａ＿Ｔｒａｎｓｆｅｒ＿Ｔｉｍｅは一般的には当時のｄａｔａの大きさおよびビットレートに基づいて値が定められ、ここでは３ｓであるとする。

【表15】

【0071】

該シグナリングに含まれている一つの画像およびオーディオファイルの情報は以下の表１６に示すとおりである。

【表16】

【0072】

現在のネットワークの遅延は１０ｓであって、０．１ｓのＴｈｒｅｓｈｏｌｄよりもはるかに大きいことは、１０ｓの広帯域遅延は許容できないことを表し、予めコンテンツの送信を請求することが必要である。

【0073】

Ｉｍａｇｅ．１に対して、その獲得可能な時間は北京時間４：５９：５０以降のあらゆる時間であるが、獲得可能な時間がより後になっているため、上記「数１１」の条件を満たさない。すなわち再生するときにコンテンツを端末に送信することができないため、該コンテンツを廃棄する。

【0074】

Ａｕｄｉｏ．１に対して、その獲得可能な時間は北京時間４：５９：２０から４：５９：５０までであり、４：５９：２０は上記「数１１」の条件を満たすので、上記「数１２」および「数１３」によって、以下の「数１９」に示すように送信を請求する時間区間を演算できる。

【数19】

【0075】

実際の請求時間は、以下の「数２０」に示す時間であるとすると、

【数20】

現在のビットレートが２００Ｋｂ／ｓである場合、各変数パラメータは以下の表１７に示すとおりに取得できる。

【表17】

ここで、Ｂｕｆｆｅｒ＿ＳｉｚｅはΔｔ＊ｂｉｔｒａｔｅとＡｓｓｅｔ＿Ｓｉｚｅとの最小値、即ち２Ｍｂを採用する。

【0076】

上記の実施例において、Ｉｍａｇｅ．１はＡｖａｉｌａｂｌｅ＿Ｔｉｍｅ時間点の確定が遅いため廃棄されるが、Ａｕｄｉｏ．１はＣＩにおいて確定するＡｖａｉｌａｂｌｅ＿ＴｉｍｅとＡｓｓｅｔ＿Ｓｉｚｅによって端末が予め送信を請求すべく時間と準備すべくキャッシュ窓の大きさを取得している。

【0077】

古いシステムにおいて、受信側がＡｓｓｅｔのＡｖａｉｌａｂｌｅ＿Ｔｉｍｅを獲得できない場合、システムの互換性のために、システムは以下の処理方法を採用できる。端末は、ｂｅｇｉｎ時間の前のある適切な時刻において請求を一回送信し（一回のみ送信する）、アップリンク遅延Ｄ_ｆを経てから、サーバ側は時刻ｔおいて請求を受信する。

【0078】

ａ） 時刻ｔがＡｓｓｅｔのＡｖａｉｌａｂｌｅ＿Ｔｉｍｅの前にあり、かつ受信側の待ち時間窓の大きさに基づいて時間間隔が大きいと判断する場合、サーバ側から受信側にメッセージを送信し、受信側にＡｓｓｅｔのＡｖａｉｌａｂｌｅ＿Ｔｉｍｅを知らせる。サーバは、Ａｖａｉｌａｂｌｅ＿ＴｉｍｅにおいてＡｓｓｅｔを送信する。

【0079】

ｂ） 時刻ｔがＡｓｓｅｔのＡｖａｉｌａｂｌｅ＿Ｔｉｍｅの前にあり、受信側の待ち時間窓の大きさに基づいて時間間隔が大きくないと判断する場合、サーバはＡｖａｉｌａｂｌｅ＿Ｔｉｍｅまで待ってから直接Ａｓｓｅｔを送信する。

【0080】

ｃ） 時刻ｔがＡｓｓｅｔのＡｖａｉｌａｂｌｅ＿Ｔｉｍｅの後である場合、以下の「数２１」に示す判断をする。

【数21】

【0081】

「数２１」が成立する場合、現在Ａｓｓｅｅｔを送信しても受信側が時間とおりに受信できることを示すため、サーバは現在の時刻においてＡｓｓｅｔを送信する。一方、「数２１」が成立しない場合、現在の時刻においてＡｓｓｅｔを送信しても間に合わないことを示すため、該Ａｓｓｅｔを廃棄する。

【0082】

本発明の上記実施例２では、広帯域ネットワークにおける一方向ネットワーク遅延をアップリンクとダウンリンクとのネットワーク遅延に変更し、請求時間窓およびキャッシュ窓の大きさの確定方法を変更した。クライアント端末は、ネットワーク内においてシグナリングを伝送するまたはＡＲＱメッセージを送信する方法によって、現在の広帯域ネットワークにおける帯域幅およびアップリンクとダウンリンクの遅延を獲得し、広帯域リソースコンテンツの獲得可能な時間および広帯域チャネルの遅延に基づいて、クライアント端末は予めキャッシュする請求を送信する時間区間および端末が必要とされるキャッシュ窓の大きさを演算しているため、より良い互換性がある。

【0083】

〔実施例３〕
図２−４に示すとおり、本実施例では、異種メディアネットワーク伝送におけるネットワークの混雑などに起因されるメディア関連リソースが同期に再生できないという問題を解決する。上記の実施例と異なる部分は、ｇｅｎｅｒａｌ＿ｌｏｃａｔｉｏｎ＿ｉｎｆｏ（）において予備フィールドを利用して各異なるソース（出所）のメディアコンテンツのために時間窓情報を追加する方法、また通知シグナリングの送信時間を演算する方法を提供することにある。

【0084】

本実施例の具体的な実施には、以下のような三つの部分が含まれている。
一、ＭＭＴ＿ｇｅｎｅｒａｌ＿ｌｏｃａｔｉｏｎ＿ｉｎｆｏ（）記述子においてリソースのＡｖａｉｌａｂｌｅ＿Ｔｉｍｅ情報を追加する
問題のあるリソースが時間とおりに表示でき、および同期できる問題を解決するために、まず、従来のシグナリングまたはその他の場所において各部分のコンテンツに対してともに新しい属性であるａｖａｉｌａｂｌｅ＿ｂｅｇｉｎおよびａｖａｉｌａｂｌｅ＿ｅｎｄを追加することにより、現在のネットワークにおける伝送待ちの該コンテンツのプロバイダーにおける準備の整え、伝送開始可能時間、およびアクセス終了時間の説明に用いる。

【0085】

上記の実施例１では、既にそれぞれＭＰＴ、ＣＩおよびＭＰＵにおいてＡｖａｉｌａｂｌｅ＿Ｔｉｍｅを追加する方法を提示した。以下は、ＭＰＴのＭＭＴ＿ｇｅｎｅｒａｌ＿ｌｏｃａｔｉｏｎ＿ｉｎｆｏ（）記述子において獲得可能な時間を追加する方法と実施例について説明する。

【0086】

ＭＰＴのＭＭＴ＿ｇｅｎｅｒａｌ＿ｌｏｃａｔｉｏｎ＿ｉｎｆｏ（）記述子は、メディアリソースおよび関連するシグナリングのソース情報を提供する。ｌｏｃａｔｉｏｎ＿ｔｙｐｅは０ｘ００〜０ｘ０６、０ｘ０Ｃの値が対応するａｓｓｅｔリソースの位置情報、０ｘ０７〜０ｘ０Ｂの値が対応するシグナリングのソース情報、０ｘ０Ｄ〜０ｘ９ＦによるＩＳＯのための予備フィールド、および０ｘＡ０〜０ｘＦＦによるシステム専用のための予備フィールドである。古いシステムとの互換性のために、予備のｌｏｃａｔｉｏｎ＿ｔｙｐｅの値において、０ｘＡ０〜０ｘＡ７との八つの予備値を選択する。各種類のｌｏｃａｔｉｏｎ＿ｔｙｐｅの対応するフィールドにおいて、記述される位置情報のフィールド定義は０ｘ００〜０ｘ０６、０ｘ０Ｃと一致し、また各記述位置情報フィールドの最後においてａｖａｉｌａｂｌｅ＿ｂｅｇｉｎおよびａｖａｉｌａｂｌｅ＿ｅｎｄ属性を追加する。

【0087】

追加する定義のフィールドａｖａｉｌａｂｌｅ＿ｂｅｇｉｎおよびａｖａｉｌａｂｌｅ＿ｅｎｄは以下の表１８に示すとおりである。

【表18】

【0088】

ａｖａｉｌａｂｌｅ＿ｂｅｇｉｎ − メディアリソースのもっとも早い（最初）獲得可能な時間である。フィールドが全部０である場合、該リソースのもっとも早い獲得可能な時間が未知であることを示し、フィールドが全部１である場合、該リソースのもっとも早い獲得可能な時間が現在の時間より早いことを示す。
ａｖａｉｌａｂｌｅ＿ｅｎｄ − メディアリソースのもっとも遅い（最後）獲得可能な時間である。フィールドが全部０である場合、該リソースのもっとも遅い獲得可能な時間が未知であることを示し、フィールドが全部１である場合、該リソースの準備が整えた後にいつでも獲得可能であることを示す。

【0089】

ここで、ａｖａｉｌａｂｌｅ＿ｂｅｇｉｎおよびａｖａｉｌａｂｌｅ＿ｅｎｄの使い方は、以下の表１９に示すとおりである。

【表19】

【0090】

（１）あるリソースが一つの時間帯において獲得可能である場合、新規追加の属性にそれぞれ以下の値を代入する。
ａｖａｉｌａｂｌｅ＿ｂｅｇｉｎには開始時間「ＵＴＣ１」との値を代入し、ａｖａｉｌａｂｌｅ＿ｅｎｄには終了時間「ＵＴＣ２」との値を代入する。

【0091】

（２）あるリソースがある時刻からいつでも獲得可能である場合、新規追加の属性にそれぞれ以下の値を代入する。
ａｖａｉｌａｂｌｅ＿ｂｅｇｉｎには開始時間「ＵＴＣ１」との値を代入し、ａｖａｉｌａｂｌｅ＿ｅｎｄフィールドには全部１を代入する。

【0092】

（３）あるリソースが任意の時間において獲得可能である場合、新規追加の属性にそれぞれ以下の値を代入する。
ａｖａｉｌａｂｌｅ＿ｂｅｇｉｎフィールドには全部１を代入し、ａｖａｉｌａｂｌｅ＿ｅｎｄフィールドには全部１を代入する。

【0093】

（４）あるリソースの獲得可能な状況が未知である場合、新規追加の属性にそれぞれ以下の値を代入する。
ａｖａｉｌａｂｌｅ＿ｂｅｇｉｎフィールドには全部０を代入し、ａｖａｉｌａｂｌｅ＿ｅｎｄフィールドには全部０を代入する。

【0094】

ｌｏｃａｔｉｏｎ＿ｔｙｐｅに対応して、ここでは０ｘＡ０〜０ｘＦＦにある予備フィールドを使用するが、０ｘ０Ｄ〜０ｘ９Ｆにある予備フィールドを使用してもよい。新たに定義されたｌｏｃａｔｉｏｎ＿ｔｙｐｅには、それぞれ０ｘ００〜０ｘ０６、０ｘ０Ｃなどのｌｏｃａｔｉｏｎ＿ｔｙｐｅをもとに獲得可能な時間の情報が追加された。

【0095】

新規追加のｌｏｃａｔｉｏｎ＿ｔｙｐｅについての説明は以下の表２０に示すとおりである。

【表20】

【0096】

二、異なるタイプのサーバシステムにおけるクライアント端末の時間請求窓の演算方法
実施例１においては、クライアント端末がシグナリングを解析してメディアリソースのＡｖａｉｌａｂｌｅ＿Ｔｉｍｅを得た後、以下の「数２２」に示すように、動的に該リソースの時間窓を請求する。

【数22】

もっとも早い請求時間Ｅａｒｌｉｅｓｔ＿Ｒｅｑｕｅｓｔ＿Ｔｉｍｅは、以下の「数２３」により演算できる。

【数23】

もっとも遅い請求時間Ｌａｔｅｓｔ＿Ｒｅｑｕｅｓｔ＿Ｔｉｍｅは、以下の「数２４」により演算できる。

【数24】

実際の請求時間は上記二つの時間点の間にあり、以下の「数２５」に示すとおりである。

【数25】

【0097】

ここで、Ｄ_ｆは現在のメディアネットワークにおけるアップリンク遅延であり、Ｄ_ｔは現在のメディアネットワークにおけるダウンリンク遅延であり、Ｄａｔａ＿Ｔｒａｎｓｆｅｒ＿Ｔｉｍｅは該サーバ側が該メディアリソースを送信するのに必要な時間である。

【0098】

実際の応用において、一般的には二つのタイプのサーバｓｅｒｖｅｒがあり、リソース請求を受信した場合、Ａタイプのサーバはリソースの準備が整えていないと、直接エラーメッセージを返す。例えば、ＨＴＴＰ ｓｅｒｖｅｒである。他方、Ｂタイプのサーバはリソースの準備が整えていないと、すぐにはメッセージを返さず、リソースの準備が整えるまで待ってから、該リソースを送信する。例えば、ＭＭＴ ｓｅｒｖｅｒである。

【0099】

実施例１において、請求時間窓の演算は、Ａタイプのサーバに用いるものである。
Ｂタイプのサーバの場合、クライアント端末のＡｖａｉｌａｂｌｅ＿Ｔｉｍｅの演算方法は以下のとおりである。
Ｂタイプのサーバはまずは請求メッセージを受信し、リソースの準備が整えるまで待ってからリソースを送信できるため、クライアント端末はシグナリングを解析してあるリソースの存在を確認することだけでリソースを請求するメッセージを送信できる。したがって、Ｂタイプのサーバのクライアント端末に対して、もっとも早い請求時間Ｅａｒｌｉｅｓｔ＿Ｒｅｑｕｅｓｔ＿Ｔｉｍｅおよびもっとも遅い請求時間Ｌａｔｅｓｔ＿Ｒｅｑｕｅｓｔ＿Ｔｉｍｅは、以下の「数２６」および「数２７」により演算できる。

【数26】

【数27】

【0100】

三、サーバが通知Ａｖａｉｌａｂｌｅ＿Ｔｉｍｅシグナリングを送信する時間窓の演算方法
一部のメディア伝送ネットワークにおいて、サーバがあるリソースのＡｖａｌｉａｂｌｅ＿Ｔｉｍｅの時刻がＴ_０であると取得できたと仮定すると、該Ｔ_０が遅い場合には、送信側がシグナリングを送信してから、クライアント端末が関連するシグナリングを受信する時間も遅くなるため、クライアント端末が正確な請求時間窓を演算したとしても、現在の時刻が既にＬａｔｅｓｔｅｓｔ＿Ｒｅｑｕｅｓｔ＿Ｔｉｍｅより遅いため、該リソースの請求は依然として失敗してしまう。

【0101】

該場合において、サーバがシグナリングの送信時間を確定するメカニズムを以下のように設ける。
サーバにおいて、同じ方法によってクライアント端末が動的にリソースを請求する時間窓を演算してから、まずは以下の「数２８」に示す判断を行う。

【数28】

「数２８」の条件が成立しない場合、Ｒｅｃｅｉｖｅｒがもっとも早くてもＬａｔｅｓｔ＿Ｒｅｑｕｅｓｔ＿Ｔｉｍｅの後にシグナリングにおけるＡｖａｉｌａｂｌｅ＿Ｔｉｍｅ属性を獲得するしかないことを示し、速やかにリソースを請求できない。したがって、この場合では関連するシグナリングを送信しない。一方、「数２８」の条件が成立する場合、ＲｅｃｅｉｖｅｒがＬａｔｅｓｔ＿Ｒｅｑｕｅｓｔ＿Ｔｉｍｅの前にシグナリングにおけるＡｖａｉｌａｂｌｅ＿Ｔｉｍｅ属性を獲得できることを示すため、続いて次の方法に基づいてシグナリングを送信する時間の区間を獲得する。
通知のもっとも遅い時間Ｌａｔｅｓｔ＿Ｎｏｔｉｆｙ＿Ｔｉｍｅは、以下の「数２９」により演算できる。

【数29】

実際のシグナリングの送信時間Ａｃｔｕａｌ＿Ｎｏｔｉｆｙ＿Ｔｉｍｅは、以下の「数３０」に示す区間にある。

【数30】

ここで、Ｄ_ｔは現在のネットワークにおけるダウンリンク遅延である。

【0102】

〔実施例４〕
本実施例では、異種メディアネットワーク伝送におけるメディアリソースの獲得可能時間が未知であることによる速やかに請求できないという問題を解決する。上記の実施例３と異なる部分は、記述子ＡＴ＿ｄｅｓｃｒｉｐｔｏｒ（）を追加することによって異なるソースのメディアリソースの獲得可能な時間の情報を記述する方法を提供し、新旧クライアントに新規追加の記述子を解析するプロセスを与えることにある。従来のシグナリングまたはその他の場所において各部分のメディアリソースコンテンツに対してともに新しい属性であるａｖａｉｌａｂｌｅ ｂｅｇｉｎおよびａｖａｉｌａｂｌｅ ｅｎｄを追加することにより、該メディアリソースがサーバにおいて準備が整えて、獲得を請求可能な時間の説明に用いる。

【0103】

具体的な実施例は以下のとおりである。
一、ＭＰＴの予備フィールドにおいて一つのビットをａｖａｉｌａｂｌｅ＿ｔｉｍｅ＿ｆｌａｇとして、現在のサーバがリソースの獲得可能な時間の情報を送信したか否かを示すために用いる。
従来のシステムの互換性のために、シグナリングにおいてクライアント側にあるリソースの獲得可能な時間が確定できるか否かを通知するため、ＭＰＴの予備フィールドにおいて一つのビットをもっと表示ビットとし、現在のサーバがリソースの獲得可能な時間の情報を送信したか否かを示すために用いる。

【0104】

ＭＰＴの予備フィールドではａｖｉａｌａｂｌｅ＿ｔｉｍｅ＿ｆｌａｇが定義され、具体的には、次のとおりである。
ａｖａｉｌａｂｌｅ＿ｔｉｍｅ＿ｆｌａｇ：メディアリソースの獲得可能な時間を送信するか否かを示すために用いる。フィールドが０である場合、メディアリソースの獲得可能な時間がまだ整えていなくて、送信していないことを示し、フィールドが１である場合、メディアリソースの獲得可能な時間の情報がシグナリングとともに送信されたことを示す。

【0105】

新たに定義されたａｖａｉｌａｂｌｅ＿ｔｉｍｅ＿ｆｌａｇのＭＰＴにおける位置は、以下の表２１に示すとおりである。

【表21】

【0106】

二、メディアリソースの獲得可能な時間の属性を追加
新規追加の属性ａｖａｉｌａｂｌｅ＿ｂｅｇｉｎおよびａｖａｉｌａｂｌｅ＿ｅｎｄは、シグナリング、ＣＩ、ＭＰＵなどの場所に置かれることができる、以下では、二つの具体的な解決方法を説明し、使用する際はそのうちの一つを選択する。
方法一：シグナリングにおいて一つの新しい記述子ＡＴ ｄｅｓｃｒｉｐｔｏｒを追加し、該記述子によりメディアリソースの獲得可能な時間を記述する。
方法二：シグナリングＭＰＴにおいてメディアリソースの獲得可能な時間の属性を追加する。クライアント端末はシグナリングにおけるメディアリソースの獲得可能な時間によって、対応する区間内において予めメディアのリソースを請求する。該方法二の具体的な実現については、実施例３のＭＭＴ＿ｇｅｎｅｒａｌ＿ｌｏｃａｔｉｏｎ＿ｉｎｆｏ（）記述子においてリソースのＡｖａｉｌａｂｌｅ＿Ｔｉｍｅ情報を追加する部分の説明を参照すればよく、ここでは詳細な説明を省略する。

【0107】

以下では、上記方法一の好ましい実施形態について詳細に説明する。
シグナリングにおいて記述子ＡＴ ｄｅｓｃｒｉｐｔｏｒを追加し、メディアリソースの獲得可能な時間を記述する。

【0108】

一つの新しい記述子ＡＴ ｄｅｓｃｒｉｐｔｏｒを追加することによって、現在のメディアリソースの獲得可能な時間の情報の伝送に用いる。送信するときに、ＡＴ ｄｅｓｃｒｉｐｔｏｒをＭＰＴのａｓｓｅｔ＿ｄｅｓｃｒｉｐｔｏｒｓ｛｝とともに送信する。

【0109】

ＡＴ ｄｅｓｃｒｉｐｔｏｒの定義は以下のとおりである。
１．紹介
一つのＡＴ ｄｅｓｃｒｉｐｔｏｒには、送信側がリソースの準備を整え、また獲得可能な時間の情報が含まれている。メディアリソースの獲得可能な時間が既知の場合、ＡＴ ｄｅｓｃｒｉｐｔｏｒはＭＰＴに含まれることも可能である。

【0110】

２．文法
ＡＴ ｄｅｓｃｒｉｐｔｏｒの文法の定義は以下の表２２〜表２４に示す三つの方式がある。

【表22】

【0111】

方式一は、表２２において六つの属性を定義し、それぞれｄｅｓｃｒｉｐｔｏｒ＿ｔａｇ、ｄｅｓｃｒｉｐｔｏｒ＿ｌｅｎｇｔｈ、ａｖａｉｌａｂｌｅ＿ｔｉｍｅ＿ｃｏｕｎｔ、ｌｏｃａｔｉｏｎ＿ｉｎｄｅｘ、ａｖａｉｌａｂｌｅ＿ｂｅｇｉｎ、ａｖａｉｌａｂｌｅ＿ｅｎｄである。この場合、サーバは一つのＡＴ ｄｅｓｃｒｉｐｔｏｒのみを送信し、すべてのソースアドレスの獲得可能な時間の情報を含ませる。ここで、ａｖａｉｌａｂｌｅ＿ｔｉｍｅ＿ｃｏｕｎｔが表示しているのは、ＭＰＴにおける異なるｌｏｃａｔｉｏｎ＿ｔｙｐｅの対応する獲得可能な時間の情報を有する数である。ｌｏｃａｔｉｏｎ＿ｉｎｄｅｘ属性は、現在のサイクルにおける獲得可能な時間の情報に対応するＭＰＴにおける異なるｌｏｃａｔｉｏｎソースアドレスのインデックスを提供し、該インデックスによってリソースを獲得できる獲得可能な時間に対応させる。

【表23】

【0112】

方式二は、表２３において六つの属性を定義し、それぞれｄｅｓｃｒｉｐｔｏｒ＿ｔａｇ、ｄｅｓｃｒｉｐｔｏｒ＿ｌｅｎｇｔｈ、ｌｏｃａｔｉｏｎ＿ｃｏｕｎｔ、ｌｏｃａｔｉｏｎ＿ｉｎｄｅｘ、ａｖａｉｌａｂｌｅ＿ｂｅｇｉｎ、ａｖａｉｌａｂｌｅ＿ｅｎｄである。この場合、サーバは一つのＡＴ ｄｅｓｃｒｉｐｔｏｒのみを送信し、すべてのソースアドレスの獲得可能な時間の情報を含ませる。ここで、ｌｏｃａｔｉｏｎ＿ｃｏｕｎｔが表示しているのは、ＭＰＴにおける異なるｌｏｃａｔｉｏｎソースの数である。ｌｏｃａｔｉｏｎ＿ｉｎｄｅｘ属性は、現在のサイクルにおける獲得可能な時間の情報に対応するＭＰＴにおける異なるｌｏｃａｔｉｏｎソースのインデックスを提供し、該インデックスによってリソースを獲得できる獲得可能な時間に対応させる。あるｌｏｃａｔｉｏｎソースのリソースの獲得可能な時間が未知である場合、ａｖａｉｌａｂｌｅ＿ｂｅｇｉｎおよびａｖａｉｌａｂｌｅ＿ｅｎｄ属性をすべて「０」にする。

【表24】

【0113】

方式三は、表２４において五つの属性を定義し、それぞれｄｅｓｃｒｉｐｔｏｒ＿ｔａｇ、ｄｅｓｃｒｉｐｔｏｒ＿ｌｅｎｇｔｈ、ｌｏｃａｔｉｏｎ＿ｉｎｄｅｘ、ａｖａｉｌａｂｌｅ＿ｂｅｇｉｎ、ａｖａｉｌａｂｌｅ＿ｅｎｄである。この場合、サーバは複数のＡＴ ｄｅｓｃｒｉｐｔｏｒを送信し、それぞれ異なるソースアドレスの獲得可能な時間の情報を示す。ｌｏｃａｔｉｏｎ＿ｉｎｄｅｘ属性は、現在のサイクルにおける獲得可能な時間の情報に対応するＭＰＴにおける異なるｌｏｃａｔｉｏｎソースアドレスのインデックスを提供し、該インデックスによってリソースを獲得できる獲得可能な時間に対応させる。

【0114】

３．語義
ｄｅｓｃｒｉｐｔｏｒ＿ｔａｇ − 現在のｄｅｓｃｒｉｐｔｏｒのタグ値である。該ｄｅｓｃｒｉｐｔｏｒに対応して、ここではｄｅｓｃｒｉｐｔｏｒ予備のタグ値を０ｘ８０００とする。
ｄｅｓｃｒｉｐｔｏｒ＿ｌｅｎｇｔｈ − 次のフィールドから該ｄｅｓｃｒｉｐｔｏｒフィールド終端までの長さを示す。
ｌｏｃａｔｉｏｎ＿ｉｎｄｅｘ − 現在のｄｅｓｃｒｉｐｔｏｒ記述の時間の対応するＭＭＴ＿ｇｅｎｅｒａｌ＿ｌｏｃａｔｉｏｎ＿ｉｎｆｏにおけるアドレス情報インデックスを示す。
ａｖａｉｌａｂｌｅ＿ｂｅｇｉｎ − メディアリソースのもっとも早い獲得可能な時間である。フィールドが全部０である場合、外リソースのもっとも早い獲得可能な時間が未知であることを示し、フィールドが全部１である場合、該リソースのもっとも早い獲得可能な時間が現在の時間より早いことを示す。
ａｖａｉｌａｂｌｅ＿ｅｎｄ − メディアリソースのもっとも遅い獲得可能な時間である。フィールドが全部０である場合、該リソースのもっとも遅い獲得可能な時間が未知であることを示し、フィールドが全部１である場合、該リソースの準備が整えた後にいつでも獲得可能であることを示す。
ａｖａｉｌａｂｌｅ＿ｔｉｍｅ＿ｃｏｕｎｔ − ＭＰＴにおける異なるｌｏｃａｔｉｏｎ＿ｔｙｐｅの対応する獲得可能な時間の情報の数である。
ｌｏｃａｔｉｏｎ＿ｃｏｕｎｔ − ＭＰＴにおける異なるｌｏｃａｔｉｏｎソースの数である。

【0115】

ここで、ａｖａｉｌａｂｌｅ＿ｂｅｇｉｎおよびａｖａｉｌａｂｌｅ＿ｅｎｄの使い方は、以下の表２５に示すとおりである。

【表25】

【0116】

（１）あるリソースが一つの時間帯において獲得可能である場合、新規追加の属性にそれぞれ以下の値を代入する。
ａｖａｉｌａｂｌｅ＿ｂｅｇｉｎには開始時間「ＵＴＣ１」との値を代入し、ａｖａｉｌａｂｌｅ＿ｅｎｄには終了時間「ＵＴＣ２」との値を代入する。

【0117】

（２）あるリソースがある時刻からいつでも獲得可能である場合、新規追加の属性にそれぞれ以下の値を代入する。
ａｖａｉｌａｂｌｅ＿ｂｅｇｉｎには開始時間「ＵＴＣ１」との値を代入し、ａｖａｉｌａｂｌｅ＿ｅｎｄフィールドには全部１を代入する。

【0118】

（３）あるリソースが任意時間において獲得可能である場合、新規追加の属性にそれぞれ以下の値を代入する。
ａｖａｉｌａｂｌｅ＿ｂｅｇｉｎフィールドには全部１を代入し、ａｖａｉｌａｂｌｅ＿ｅｎｄフィールドには全部１を代入する。

【0119】

（４）あるリソースの獲得可能な状況が未知である場合、新規追加の属性にそれぞれ以下の値を代入する。
ａｖａｉｌａｂｌｅ＿ｂｅｇｉｎフィールドには全部０を代入し、ａｖａｉｌａｂｌｅ＿ｅｎｄフィールドには全部０を代入する。

【0120】

この方法において、ａｖａｉｌａｂｌｅ＿ｔｉｍｅ＿ｆｌａｇがいなくても、ＡＴ ｄｅｓｃｒｉｐｔｏｒはｄｅｓｃｒｉｐｔｏｒ ｔａｇから識別されることができるため、ａｖａｉｌａｂｌｅ＿ｔｉｍｅ＿ｆｌａｇは選択的なものである。

【0121】

以下では、ＡＴ ｄｅｓｃｒｉｐｔｏｒを伝送することによってクライアント側に獲得可能な時間を通知する実現方法について説明する（具体的なプロセスは図５−６に示すとおりである）。

【0122】

ＡＴ ｄｅｓｃｒｉｐｔｏｒを使って獲得可能な時間を伝送する方法において、
（１）サーバにおけるメディアリソースの獲得可能な時間が未知である場合、送信するシグナリングにおいてＡＴ ｄｅｓｃｒｉｐｔｏｒを提供しなく、サーバはＭＰＴにおける‘ａｖａｉｌａｂｌｅ＿ｔｉｍｅ＿ｆｌａｇ’識別子を‘０’にする。
（２）該メディアリソースの獲得可能な時間が既知で、かつシグナリングにおけるＡＴ ｄｅｓｃｒｉｐｔｏｒにおいて提供した場合、サーバはＭＰＴにおける‘ａｖａｉｌａｂｌｅ＿ｔｉｍｅ＿ｆｌａｇ’識別子を‘１’にする。
（２−１）新しいクライアントについては、ＡＴ ｄｅｓｃｒｉｐｔｏｒのコンテンツを読み込んで該ａｓｓｅｔの‘ｌｏｃａｔｉｏｎ＿ｔｙｐｅ’、‘ｌｏｃａｔｉｏｎ＿ｉｎｄｅｘ’、‘ａｖａｉｌａｂｌｅ＿ｂｅｇｉｎ’および‘ａｖａｉｌａｂｌｅ＿ｅｎｄ’属性を得て、ｌｏｃａｔｉｏｎ＿ｉｎｄｅｘによって、クライアント側がＭＭＴ＿ｇｅｎｅｒａｌ＿ｌｏｃａｔｉｏｎ＿ｉｎｆｏ（）において記述されたｌｏｃａｔｉｏｎリソースの対応する獲得可能な時間情報を知る。クライアント側は、該獲得可能な時間内において予めリソースを請求できる。
（２−２）古いクライアントについては、ａｖａｉｌａｂｌｅ＿ｔｉｍｅ＿ｆｌａｇが無視され、ｄｅｓｃｒｉｐｔｏｒ＿ｔａｇが０ｘ８０００であるＡＴ ｄｅｓｃｒｉｐｔｏｒを受信すると、古いシステムにとって該ｔａｇは予備フィールドであるため、該ＡＴ ｄｅｓｃｒｉｐｔｏｒを無視し、リソースの獲得可能な時間を知ることができない。クライアント側はコンテンツの準備を整える前に予めリソースを請求できるが、成功できない。

【0123】

以上、本発明の具体的な実施例について説明している。また、本発明は上記特定する実施形態に限定されず、当業者は特許請求の範囲に規定された範囲内において様々な変形や修正を行うことができるが，これらは本発明の実質的な内容に影響を及ぼすことないことに理解すべきである。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】