JP2015029327A - コンテンツダウンロード及びコンテンツアップロード用ポリシー - Google Patents

Abstract

【課題】メディアコンテンツの信頼のあるダウンロードあるいはアップロードを可能にし、再生を行うユーザが、ネットワークにおける輻輳による影響を受けないようにするコンテンツダウンロード及びコンテンツアップロード用ポリシーを提供する。
【解決手段】方法及び装置は、コンテンツサーバ５からユーザ機器１へＩＰＴＶメディアコンテンツのダウンロードのための、及びユーザ機器からコンテンツサーバへのメディアコンテンツのアップロードのための、ポリシーをセットアップする。このポリシーは、典型的には、帯域幅予約であり、そして、コンテンツダウンロード／アップロードのタイプは、ユーザ機器からの初期リクエスト、例えば、ＩＰＴＶコントロールノード４へ送信されるＳＤＰ（セッション記述プロトコル）オファーに含められることになる。
【選択図】図１ａ

Description

本発明は、ユーザ機器及びＩＰＴＶコントロールノード（ＩＰＴＶ制御ノード）に対する、メディアコンテンツサーバ、ユーザ機器及びＩＰＴＶコントロールノードへのＩＰＴＶメディアコンテンツのアップロードあるいは、メディアコンテンツサーバ、ユーザ機器及びＩＰＴＶコントロールノードからのＩＰＴＶメディアコンテンツのダウンロードの方法に関するものである。

エンドユーザは、ＵＥ（ユーザ機器）が適切な機能を有しているという条件で、例えば、ＩＭＳ（インターネットプロトコルマルチメディアサブシステム）を介して、様々なタイプのＵＥからＩＰＴＶ（インターネットプロトコルテレビ）サービスへアクセスすることができる。このユーザ機器には、例えば、ＴＶ、ＰＣ（パーソナルコンピュータ）あるいは移動電話がある。この適切な機能については、例えば、オープンＩＰＴＶ−フォーラム−仕様書に従って規定されている。

従来、帯域幅は、セッションのセットアップ中に予約することができる。このセッションには、例えば、ユニキャストストリームを使用するビデオオンデマンドセッション、あるいはマルチキャストストリームを使用する一般的なテレビブロードキャストセッションがある。帯域幅予約は、加入者に対する「ラストマイル（last mile）」と集約ネットワークの両方において、サービスを途絶することなくあるいは中断することなく、ユーザに適切な経験を提供するために十分な帯域幅が存在することを補償するものである。また、ラストマイルで利用可能な帯域幅を、２つのセッションが同時に超過する場合がある。このことは、２つのセッション内のパケット群が競合することを生じさせ、その結果、いくつかのパケットが両方のセッション内で破棄されることになる。つまり、一旦、既存のセッションに対して帯域幅が予約されると、その既存のセッションに影響を与える新規のセッションは許可されないことが重要である。

メディアコンテンツは、プログレッシブダウンロードによって、メディアコンテンツサーバからクライアント端末として動作するＵＥへダウンロードすることができ、ＵＥにおいては、ストリーミングダウンロードあるいはアダプティブストリーミングダウンロードによって、メディアコンテンツがローカルバッファに記憶されることで、ダウンロードが完了する前にメディアファイルを再生することを可能にする。ここで、ストリーミングダウンロードでは、メディアコンテンツはコンテンツサーバから、再生のレートでストリーミングされ、ここでは、メディアコンテンツの記憶はなされない。アダプティブストリーミングダウンロードは、コンテンツを様々なビットレートでダウンロードすることができる。同様に、メディアコンテンツは、ＵＥからコンテンツサーバへアップロードすることができ、また、続いて、ダウンロードを使用して他のユーザと共有することもできる。

しかしながら、従来のメディアコンテンツのＨＴＴＰプログレッシブダウンロードは、ベストエフォート型のサービス品質だけをサポートする。即ち、ＱｏＳは保証されない。また、帯域幅は、最大帯域幅でない可能性がある。その結果、メディアコンテンツの解像度が高く、また、ネットワークの帯域幅に制限がある場合、ユーザが経験する再生は貧弱になる可能性がある。例えば、周知のウェブサイトであるＹｏｕＴｕｂｅ（登録商標）からダウンロードされるメディアコンテンツは、ベストエフォート型のサービス品質だけを使用して、ダウンロードされながら表示される。解像度が制限され、かつ高すぎない場合では、利用可能な帯域幅は十分であり、ユーザが経験するディアコンテンツの再生は受け入れられるものとなる。しかしながら、そうでない場合には、ユーザ経験は貧弱になる可能性がある。

また、プログレッシブでダウンロードされるメディアファイルを正常に再生するためには、ＵＥ、即ち、クライアント端末が、大量のメディアコンテンツをバッファできることが要求される。

つまり、ユーザが受け入れ可能なメディアコンテンツの再生を経験することを達成するためには依然として課題が残っている。

本明細書で記載される実施形態の目的は、上述の課題の少なくともいくつかを取り扱うことであり、また、この目的及びその他の目的は、添付の独立請求項に従う方法及び装置によって、また、従属請求項に従う実施形態によって、達成される。

第１の態様に従う実施形態は、コンテンツサーバからＩＰＴＶコンテンツをダウンロードするためのポリシー、あるいはコンテンツサーバへＩＰＴＶコンテンツをアップロードするためのポリシーをセットアップするユーザ機器ための方法を提供する。ユーザ機器は、コンテンツダウンロードあるいはコンテンツアップロードのタイプの指示を有するリクエストを生成し、前記リクエストをＩＰＴＶコントロールノードへ送信する。

第２の態様に従う実施形態は、コンテンツサーバからユーザ機器へＩＰＴＶコンテンツをダウンロードするための、あるいはユーザ機器からコンテンツサーバへＩＰＴＶコンテンツをアップロードするための、ポリシーをセットアップするＩＰＴＶコントロールノードのための方法を提供する。ＩＰＴＶコントロールノードは、前記ユーザ機器からのリクエストとして、コンテンツダウンロードあるいはコンテンツアップロードのタイプの指示を備えるリクエストを受信する。

第３の態様に従う実施形態は、コンテンツサーバからＩＰＴＶコンテンツをダウンロードするためのポリシー、及びコンテンツサーバへＩＰＴＶコンテンツをアップロードするためのポリシーの少なくとも一方をセットアップするように構成されているユーザ機器を提供する。ユーザ機器は、処理回路が提供されている通信デバイスを備え、前記通信デバイスは、コンテンツダウンロード及びコンテンツアップロードの少なくとも一方のタイプの指示を有するリクエストを生成し、前記リクエストをＩＰＴＶコントロールノードへ送信するように構成されている。

第４の態様に従う実施形態は、コンテンツサーバからユーザ機器へＩＰＴＶコンテンツをダウンロードするための、及びユーザ機器からコンテンツサーバへＩＰＴＶコンテンツをアップロードするための少なくとも一方のための、ポリシーをセットアップするように構成されているＩＰＴＶコントロールノードを提供する。ＩＰＴＶコントロールノードは、処理回路が提供されている通信デバイスを備え、前記通信デバイスは、前記ユーザ機器からのリクエストとして、コンテンツダウンロード及びコンテンツアップロードの少なくとも一方のタイプの指示を備えるリクエストを受信するように構成されている。

例示の実施形態に伴う効果は、メディアコンテンツの信頼のあるダウンロードあるいはアップロードを可能にし、そうすることで、再生を行うユーザ経験が、例えば、ネットワークにおける輻輳による影響を受けないようにする。

メディアコンテンツのダウンロード及びアップロードに対する例示のＩＭＳ ＩＰＴＶアーキテクチャを示すブロック図である。 ＯＩＴＦ対応ＵＥを示す図である。 ＩＭＳ ＩＰＴＶアーキテクチャにおける例示のＵＥから開始されるコンテンツダウンロードセッションを示すシグナリング図である。 ＩＭＳ ＩＰＴＶアーキテクチャにおける例示のＵＥから開始されるコンテンツダウンロードセッションを示すシグナリング図である。 プレーンＩＰＴＶに対して例示のＵＥから開始されるコンテンツダウンロードセッションを示すシグナリング図である。 プレーンＩＰＴＶに対して例示のＵＥから開始されるコンテンツダウンロードセッションを示すシグナリング図である。 コンテンツアップロードあるいはコンテンツダウンロードに関連するＵＥに対する方法を示すフロー図である。 コンテンツアップロードあるいはコンテンツダウンロードに関連するＩＰＴＶコントロールノードに対する方法を示すフロー図である。 例示のＵＥを示すブロック図である。 例示のＩＰＴＶコントロールノードを示すブロック図である。

以下では、実施形態とそれに伴う図面を参照して本発明の詳細を説明する。例示の目的で、また、限定する目的ではない、特定の詳細が本発明の全体理解を提供するために説明され、これには、特定の状況、技術等が含まれる。しかしながら、当業者には、本発明が、これらの特定の詳細とは別の実施形態で実施されても良いことが明らかであろう。

また、以下の本明細書で説明される機能及び手段は、プログラム化マイクロプロセッサあるいは汎用コンピュータと協働して動作するソフトウェア、及び特定用途集積回路（ＡＳＩＣ）の少なくとも一方を使用して実現されても良いことは当業者には明らかであろう。また、本発明が主に方法及びデバイスの形式で記載されている一方で、本発明は、コンピュータプログラムだけでなく、コンピュータプロセッサ及びそのコンピュータプロセッサに接続されるメモリを備えるシステムにおいても実現されても良いことも明らかであろう。ここで、メモリには、本明細書で開示される機能群を実行することができる１つ以上のプログラムがエンコードされている。

以下に記載される実施形態の概念は、ユーザ機器から初期リクエストでコンテンツダウンロードあるいはコンテンツアップロードのタイプを示すことで、メディアコンテンツのダウンロード及びアップロードの少なくとも一方に対するポリシーをセットアップする、例えば、適切な帯域幅を予約することである。

更なる実施形態に従えば、コンテンツダウンロードあるいはコンテンツアップロードのタイプは、初期リクエスト内のトランスファー（転送）タイプ属性によって指示され、この属性は、初期リクエスト内に含まれるＳＤＰオファー（SDP Offer：ＳＤＰ提案）に含まれる。別の実施形態に従えば、帯域幅を提案する帯域幅属性は、オプションとして、初期リクエストに含まれる。

このトランスファータイプ属性は、例えば、ＩＭＳとローカルトランスポートポリシーに、セッションが特定の要件でセットアップされるべきであることを示すものである。例えば、トランスファータイプ属性がストリーミングダウンロードを示していて、また、特定の帯域幅が帯域幅属性で示されている場合、ストリーミングダウンロードセッションが、帯域幅属性で示される帯域幅に従って、保証された帯域幅でセットアップされるべきである。つまり、帯域幅属性で示される帯域幅は、円滑な送信を行うために必要とされる期待最大帯域幅を示している。

更なる実施形態に従えば、トランスポートタイプ属性とオプションで提案される帯域幅とを含むリクエストは、そのリクエスト内で指示されるトランスポートのタイプに対して要求される帯域幅がネットワークで利用可能でない場合には拒否されることになる。そうである場合、ユーザ機器は、次のリクエストで異なるトランスポートタイプ属性を含めることができる。

ＩＭＳベースのＩＰＴＶソリューションにおいて、例示の実施形態に従えば、ＱｏＳ（サービス品質）は、ＱｏＳ（サービス品質）は、例えば、ＴＩＳＰＡＮ ＲＡＣＳ−アーキテクチャに従って定義されるように保証されても良い。リニアＴＶ用及びビデオオンデマンド用に要求されるシグナリングは、例えば、ＴＩＳＰＡＮー仕様書及びＯＩＴＦ（オープンＩＰＴＶフォーラム）仕様書で既定されている。

例示の実施形態は、コンテンツのダウンロードとコンテンツのアップロードとの結び付けと、例えば、ＩＭＳ／ＲＡＣＳによって提供される上述のＱｏＳメカニズムを提供し、そうすることで、最小送信速度で、例えば、プログレッシブダウンロード、ストリーミングダウンロード、及びアダプティブストリーミングダウンロードのタイプのダウンロード中に、途切れのないメディアコンテンツの視聴をサポートすることを可能にすることを保証する。

つまり、本発明の実施形態に従えば、上述のトランスファータイプ属性が、コンテンツダウンロード用のＳＤＰオファーに含められ、そうすることで、コンテンツダウンロード用のポリシーを専用にセットアップする。この属性は、ＩＭＳ／ＲＡＣＳにおけるローカルポリシーを制御すること、例えば、帯域幅を予約すること、あるいはアクセスネットワーク内の適切な優先度を選択することの柔軟性を実現する。ＲＡＣＳポリシーは、例えば、標準化ＳＰＤＦ（サービスベースのポリシー決定機能）に従ってセットアップされる。

典型的には、ＨＴＴＰコンテンツダウンロード用のトランスポートタイプは、エンドユーザの動作及びユーザ機器の構成設定（コンフィグレーション）に基づいて、ユーザ機器によって判定される。ユーザが視聴するコンテンツを選択し、かつユーザ機器がコンテンツを記憶するように構成設定されていない場合、コンテンツは、ユーザ機器の再生速度で、コンテンツのストリーミングダウンロードを使用してコンテンツサーバから取得されることになる。

しかしながら、ユーザ機器がコンテンツを記憶するように構成設定される場合、コンテンツは、プログレッシブダウンロードを使用して、コンテンツサーバから取得されることになる。即ち、コンテンツはユーザ機器に記憶されるあるいはバッファされると同時に再生される。

アダプティブストリーミングダウンロードでは、エンドユーザは、コンテンツがアダプティブストリームとして利用可能であるべきことをリクエストし、そうすることで、コンテンツを、特別なスキームに従って、異なるビットレートでダウンロードすることができる。例えば、ユーザ機器は、バッファが空きになることを検出する場合には、より高速なビットレートストリーム用の帯域幅の不足が存在し、かつより低速なダウンロードビットレートへのシフトが存在すると仮定することができる。

上述のように、従来のＨＴＴＰコンテンツダウンロードは、ベストエフォート型の送信であり、ダウンロードの速度は利用可能な帯域幅に制限される。しかしながら、異なるタイプのコンテンツダウンロードとコンテンツアップロードとの差別化を図るために、トランスファータイプ属性が、本発明の実施形態に従って、ユーザ機器からの初期リクエストに含められる。

異なるタイプのコンテンツダウンロードは、ベストエフォートＱｏＳよりもわずかに高いＱｏＳで差別化される。これは、ベストエフォートＱｏＳは、最小送信要件を有さないからである。

上述のように、上述の概念は、例えば、ユーザによって生成されるダウンロード用に適用することができるばかりか、アップロード用にも適用することができる。アップロードコンテンツは、ダウンロードを使用して、他のユーザと連続的に共有することができるので、一定の転送を要求することになる。

図１ａは、例示のＩＭＳ ＩＰＴＶアーキテクチャと、ＩＭＳ ＩＰＴＶにおいて適用可能なプロトコル、即ち、ＳＩＰ（セッション開始プロトコル）及びＨＴＴＰ（ハイパーテキスト転送プロトコル）を示すブロック図であり、この適用可能なプロトコルは、コンテンツサーバからＵＥへメディアをダウンロードするためのもの、あるいはメディアコンテンツをコンテンツサーバへアップロードするためのものである。このアーキテクチャは、ＯＩＴＦ対応（使用可能）ＵＥ１、ＩＭＳゲートウェイ２、図ではＩＭＳ／ＲＡＣＳの円３で示されているＩＭＳメディアサーバあるいはビデオオンデマンドポンプ、ＩＰＴＶコントローラ４、及びメディア制御機能（ＭＣＦ）を備えるコンテンツサーバ５を備えている。ＩＰＴＶコントローラ４は、例えば、オープンＩＰＴＶフォーラムで定義される、例えば、ＩＰＴＶアプリケーションプラットホーム（ＩＡＰ）を備えていても良い。

図１ｂは、ＯＩＴＦ対応ユーザ機器１を示すブロック図であり、これは、オープンＩＰＴＶフォーラム仕様書で定義される、宣言型アプリーケーション環境（ＤＡＥ）用の機能と、ローカルオブジェクトコードを備え、ＤＡＥはＵＥのブラウザを備える。

より具体的には、例示のＵＥによって指示されるユニキャストコンテンツダウンロードセッションでは、発信側のＵＥが初期ＩＮＶＩＴＥ−リクエストを生成する。リクエスト−ＵＲＩ（ユニフォームリソース識別子）は、ダウンロードコンテンツＵＲＩを、ユニキャストロケータ内と、ＴＯ−ヘッダ内に含める。この識別子はサービス選択情報から取得される。また、ＦＲＯＭ−ヘッダは、ユーザのパブリックユーザアイデンティティを指示する。

ＳＤＰオファーは、メディアケイパビリティと、コンテンツダウンロードセッション用に利用可能な要求される帯域幅に従って、ＩＮＶＩＴＥ（招待）リクエストに含められる。

つまり、メディアレベルでの例示の典型的なＳＤＰオファーは、例えば、以下の要素を含んでいても良い。

− ＨＴＴＰダウンロード用の「ｍ＝」ライン、例えば、以下のフォーマットの「ｍ＝」ライン：
ｍ＝＜ｍｅｄｉａ＞＜ｐｏｒｔ＞＜ｔｒａｎｓｐｏｒｔ＞＜ｆｍｔ＞
これは、「アプリケーション（application）」の値を有するメディアフィールドを有し、また、ディスカード（discard）ポートである９の値に設定されるポートフィールドを有し、更には、ＴＣＰに設定されるトランスポートフィールドを有する。また、ｆｍｔ−パラメータが含められ、これは、ｉｐｔｖ＿ｈｔｔｐに設定され、その結果、「ｍ＝アプリケーション ９ ｔｃｐ ｉｐｔｖ＿ｈｔｔｐ」となる。

− 「ａ＝ｓｅｔｕｐ」属性が「アクティブ（active）」に設定され、例えば、ａ＝ｓｅｔｕｐ：ａｃｔｉｖｅとなる。

− 「ａ＝ｃｏｎｎｅｃｔｉｏｎ」属性が「ｎｅｗ」として設定され、例えば、ａ＝ｃｏｎｎｅｃｔｉｏｎ：ｎｅｗとなる。

−「ｃ＝」ラインが、ＩＮに設定される値と、ＩＰ４あるいはＩＰ６に設定されるアドレスタイプと、及び関連するＨＴＴＰチャネルのフローのＩＰアドレスを有するネットワークタイプに含められ、例えば、ｃ＝ＩＮ ＩＰ４ ＜ＩＰ＿ＡＤＤＲＥＳＳ＞となる。

本発明の実施形態に従えば、ＳＤＰオファーの「ｂ＝」ラインは、オプションとして、提案される帯域幅を示す帯域幅属性を含んでいても良い。ユーザが、サービス選択手順中にこの特定のコンテンツ配信チャネルに対して要求される帯域幅をフェッチしている場合、メディアレベルでの帯域幅属性は、「ｂ＝」ラインでこの値が設定され、例えば、ｂ＝ＡＳ：１５０００となる。

従って、コンテンツサーバのＭＣＦ（メディアコンテンツ機能）は、ＩＴＰＶコントローラを介して、ＳＤＰオファーを受信することになり、これは、トランスファータイプー属性と、提案される帯域幅を示す帯域幅属性（「ｂ＝」ラインにおいて）を含んでいても良い。コンテンツサーバのＭＣＦは、ダウンロードあるいはアップロード用のコンテンツを準備する際にＩＰＴＶコントローラをアシストすることになり、そして、受信するトランスファータイプ−属性をＳＤＰアンサーにコピーし、これは、ＩＰＴＶコントローラへ転送される。

加えて、本発明の実施形態に従えば、例えば、「ｆｍｔｐ：ｉｐｔｖ＿ｈｔｔｐ ｔｒａｎｓｆｅｒ−ｔｙｐｅ（トランスファー（転送）タイプ）」属性のような、ＳＤＰオファーに含まれるトランスファータイプ−属性によって、上述のように、コンテンツダウンロードのタイプが、初期ＩＮＶＩＴＥ−リクエストで指示される。本発明の第１の実施形態に従えば、トランスファータイプ−属性に対して適用可能な値は、「プログレッシブ」、「ストリーミング」、及び「アダプティブ」となる。

「プログレッシブ」コンテンツダウンロード−タイプは、ダウンロード中に視聴されるコンテンツを示していて、また、そのコンテンツはＵＥに記憶されるあるいはバッファされるので、比較的大きな帯域幅を要求する。

「ストリーミング」コンテンツダウンロードタイプ、例えば、ＨＴＴＰストリーミングは、記憶することなく、あるいはＲＳＴＰストリーミングと同様に、ＵＥでのバッファリングが制限されて、視聴されるコンテンツを示している。

「アダプティブ」コンテンツダウンロードタイプ、例えば、ＨＴＴＰアダプティブストリーミングは、異なる帯域幅と異なる品質で視聴することができるコンテンツを示している。

「ｂ＝」ラインは、オプションの帯域幅属性であり、そして、最高品質のストリーミング用の帯域幅を示している。

更に例示の実施形態に従えば、トランスファー−タイプ属性の様々な他の値を、コンテンツダウンロードの他の所有タイプ、例えば、ａ＝ｆｍｔｐ：ｉｐｔｖ＿ｈｔｔｐ ｔｒａｎｓｆｅｒ−ｔｙｐｅ＝＜ｔｒａｎｓｆｅｒ−ｔｙｐｅ＞を示すために使用することができる。

図２ａと図２ｂは、ＩＭＳ ＩＰＴＶ−アーキテクチャにおけるクライアント端末として動作するユーザ機器１に対する例示のシグナリングシーケンスを示すシグナリング図を示している。この図は、本発明の実施形態に従えば、帯域幅予約を含む、コンテンツサーバ５からユーザ機器がダウンロードするメディアコンテンツを示している。この図は、また、介在する論理ユニットを示している。

ＵＥ（ＯＩＴＦ）−ボックス１は、ＯＩＴＦ対応ユーザ機器を示していて、これは、オープンＩＰＴＶフォーラムで定義される宣誓型アプリケーション環境（ＤＡＥ）用の機能を備え、更には、ローカルオブジェクトコード（ＬＯＣ）を備えている。また、ＩＧ−ｂｏｘ２はＩＭＳゲートウェイに対応し、ＩＭＳ／ＲＡＣＳ−ｂｏｘ３はＩＭＳメディアサーバあるいはビデオオンデマンドポンプに対応し、また、ＩＰＴＶコントローラ４はＩＰＴＶアプリケーションプラットホーム（ＩＡＰ）を備えている。コンテンツサーバ５は、メディアコントローラ機能（ＭＣＦ）を備える。

図２ａの信号Ｓ１１では、ＵＥ１はダウンロードセッションを示していて、これは信号Ｓ１２で作成される。信号Ｓ１３では、ＳＩＰ ＩＮＶＩＴＥがＩＭＳゲートウェイ２からＩＭＳメディアサーバ３へ転送され、また、信号Ｓ１５で、ＩＰＴＶコントローラ４へ転送される。ここで、ＳＩＰ ＩＮＶＩＴＥはＳＤＰ（セッション記述プロトコル）オファーを含んでいる。そして、ステップ１６で、ＩＰＴＶコントローラ４とコンテンツサーバ５によって、コンテンツがダウンロード用に準備される。

先行するステップ１４では、ＩＭＳ／ＲＡＣＳによってダウンロード用のポリシーがチェックされて、かつ適用され、そして、帯域幅予約が実行される。これには、ＳＩＰ ＩＮＶＩＴＥのＳＤＰオファーで指示されるトランスポート−タイプによって要求される帯域幅が利用可能であるかを判定するために、アクセスネットワーク内のネットワークトポロジーがＲＡＣＳによってチェックされることを含んでいる。利用可能である場合、帯域幅が予約され、信号Ｓ１５で、ＳＩＰ ＩＮＶＩＴＥがＩＰＴＶコントローラへ転送されることになる。しかしながら、要求される帯域幅が利用可能でない場合、ＳＩＰ ＩＮＶＩＴＥは拒否されることになり、その結果、ＳＩＰ ＩＮＶＩＴＥはＩＰＴＶコントローラには転送されない。ＩＰＴＶコントローラが拒否されてないＳＩＰ ＩＮＶＩＴＥを受信する場合、コンテンツは、上述のステップ１６において、ダウンロード用に用意されることになる。

次に、信号Ｓ１７において、ＩＰＴＶコントローラは、ＳＤＰアンサーと、セッションに対するＵＲＬで応答することになる。これは、信号Ｓ１９で、ＩＭＳゲートウェイに転送され、先行するステップ１８において、帯域幅予約が確認される。その後、信号Ｓ２０で、セッションが作成される。ＵＥは、図２ｂの信号Ｓ２１、Ｓ２２及びＳ２３で、コンテンツサーバ５から、コンテンツのダウンロード用に受信されるセッションＵＲＬを使用する。信号Ｓ２４−Ｓ３０で、ステップ２６において、ダウンロードセッションが終了され、これにはネットワークリソースの解放（リリース）が含まれる。最終的には、信号Ｓ３１とＳ３２で、ダウンロードコンテンツが再生される。

上述の図２ａと２ｂは、ダウンロードセッションを示している。しかしながら、同様のシグナリング手順がアップロードセッションに対して使用されても良い。

他の例示の実施形態は、他のプロトコルを使用する非ＩＭＳネットワーク内のプレーンＩＰＴＶに向けられているものであり、この他のプロトコルは、例えば、ＳＩＰに代わる、ＳＯＡＰ（シンプルオブジェクトアクセスプロトコル）あるいはＤＩＡＭＥＴＥＲプロトコルである。

つまり、図２ｃ及び図２ｄは、ＩＭＳゲートウェイを有さない代わりに、ＳＯＡＰを使用し、そして、ＩＰＴＶコントローラ４へのＲＡＣＳインタフェース３を有するプレーンＩＰＴＶアーキテクチャ用の例示のシグナリング図を示している。図２ｃの信号Ｓ１１０で、ＵＥ１はダウンロードセッションを開始し、これは、信号Ｓ１２０で作成される。信号Ｓ１３０で、ＩＰＴＶコントローラは、ＲＡＣＳインタフェースに対してＳＯＡＰ予約帯域幅を発行する。予約が確認される場合、ステップ１４０において、信号Ｓ１５０で、ＳＯＡＰ応答がＩＰＴＶコントローラへ送信される。ステップ１６０において、信号Ｓ１７０で、ＩＰＴＶコントローラはダウンロード用のコンテンツを準備して、そして、セッションが作成される。

ＵＥは、図２ｄの信号Ｓ１８０、Ｓ１９０及びＳ２００で、コンテンツサーバ５から、コンテンツのダウンロード用として受信されるセッションＵＲＬを使用する。信号Ｓ２１０−Ｓ２６０で、ステップＳ２３０において、ダウンロードセッションが終了され、これにはネットワークリソースの解放（リリース）が含まれる。そして、最終的には、信号Ｓ２７０とＳ２８０で、ダウンロードコンテンツが再生される。

図３は、本発明の実施形態に従う、メディアコンテンツのアップロードあるいはダウンロード用のポリシーをセットアップする、ユーザ機器のための方法を示すフロー図である。ステップ３５において、ＵＥは、コンテンツダウンロードあるいはコンテンツアップロードのタイプを示すリクエストを生成し、ステップ３６において、そのリクエストをＩＰＴＶコントロールノードへ送信する。更なる実施形態に従えば、ポリシーは帯域幅予約であり、また、タイプは、初期リクエストのＳＤＰオファー内に含まれるトランスポートタイプ−属性によって指示される。更なる実施形態に従えば、トランスファータイプ−属性は、上述のように、「プログレッシブ」、「ストリーミング」あるいは「アダプティブ」の値の内の１つを有している。図３のステップ３５及びステップ３６は、ダウンロードに向けられる場合には、基本的には、図２ａの信号Ｓ１１−Ｓ１５に対応する。

図４は、本発明の実施形態に従う、メディアコンテンツのアップロードあるいはダウンロード用のポリシーをセットアップする、ＩＰＴＶコントロールノードのための方法を示すフロー図である。ステップ４１において、ＩＰＴＶコントロールノードは、ＵＥからのリクエストを受信する。このリクエストは、コンテンツダウンロードあるいはコンテンツアップロードのタイプを示している。ステップ４２において、ＩＰＴＶコントロールノードは、コンテンツサーバのＭＣＦ（メディア制御機能）を介して、ＳＤＰアンサーにダウンロードあるいはアップロードのタイプをコピーする。更なる実施形態に従えば、ポリシーは帯域幅予約であり、これは、上述のステップ４１においてＵＥから受信される初期リクエストのＳＤＰオファーに含まれるトランスポートタイプ−属性によって指示される、コンテンツダウンロードあるいはコンテンツアップロードのタイプに基づいていて、期待送信速度に従ってセットアップされる。更なる実施形態に従えば、トランスファータイプ−属性の値は、例えば、プログレッシブ、ストリーミングあるいはアダプティブである。

図５は、本発明の実施形態に従う、ユーザ機器１を示すブロック図である。ＵＥ１は、例えば、ＯＩＴＦ対応移動電話、ＰＣ、あるいはＴＶであり、適切なユーザインタフェースを備えていて、また、これには、プロセッサ回路と適切なソフトウェア、例えば、ＩＰＴＶフォーラムで定義される、宣言型アプリケーション環境（ＤＡＥ）に対応するソフトウェアと、ローカルオブジェクトコードが提供される。このソフトウェアは、更に、本発明の実施形態に従う方法を実行するように構成されている。ＵＥは、また、汎用通信デバイス５１が提供され、これは、送信機、受信機及び処理回路５２を備えることで、例えば、ＩＭＳゲートウェイとＩＭＳメディアサーバを介して、ＩＰＴＶコントローラと通信する。例示の実施形態に従えば、ＵＥは、コンテンツダウンロード及びコンテンツアップロードの少なくとも一方のタイプを指示するＳＤＰオファーを含むリクエストを生成し、そして、送信する。

図６は、例示のＩＴＰＶコントロールノード４を示すブロック図であり、これは、ＩＰＴＶアプリケーションプラットホーム（ＩＡＰ）を備えている。ＩＴＰＶコントロールノードには、更に、通信デバイス６１が提供され、これは、送信機、受信機及び処理回路６２を備え、更には、通信デバイスと他の適切なハードウェア及びソフトウェアによって、ＩＰＴＶコントロールノードは、例えば、ＳＤＰオファーに含まれるトランスファータイプ−属性で、ＵＥからのコンテンツダウンロードあるいはコンテンツアップロードのタイプを示すリクエストを受信するように構成されている。更なる実施形態に従えば、通信デバイスは、コンテンツサーバに含まれるＭＣＦ（メディア制御機能）を介して、トランスファータイプ属性をＳＤＰアンサーにコピーするように構成される。実施形態に従えば、ポリシーは帯域幅予約であり、ＩＰＴＶコントロールノードは、受信されるトランスファータイプ−属性に基づいていて、期待送信速度に従う帯域幅を有するセッションをセットアップするように構成されている。

図５及び図６を参照して上述されるエンティティ群及びユニット群は論理的なユニットであり、個別の物理ユニットに対応している必要はない。

つまり、メディアコンテンツのダウンロードに向けられるユーザ機器に対する方法の実施形態に従えば、ユーザ機器１は、コンテンツダウンロード−タイプの指示を備えるリクエストを生成し、そのリクエストをＩＰＴＶ−コントローラ４へ送信することによってサーバからＩＰＴＶ−コンテンツをダウンロードするためのポリシーをセットアップする。

例示の実施形態に従えば、ポリシーは帯域幅予約であり、そして、コンテンツダウンロード−タイプは、標準化トランスファータイプ−属性によって示される。これには、例えば、プログレッシブダウンロードを意味するプログレッシブ、ストリーミングダウンロードを意味するストリーミング、あるいはアダプティブストリーミングダウンロードがある。

更なる例示の実施形態に従えば、ＩＰＴＶはＩＭＳベースであり、コンテンツダウンロードタイプの指示は、リクエストに含まれるＳＤＰオファーに含まれる。また、ＳＤＰオファーは、提案される帯域幅を示す帯域幅属性を含んでも良い。

更なる実施形態に従えば、ユーザ機器は、トランスポートタイプ−属性によって指示されるトランスポート−タイプに対して要求される帯域幅が利用可能でない場合、リクエストの拒否を受信することになり、そして、ユーザ機器は、拒否の受信時に、異なるトランスポートタイプ−属性を備えるリクエストを生成することができる。

アップロードに向けられるユーザ機器に対する同様の方法の実施形態に従えば、ユーザ機器１は、コンテンツアップロード−タイプの指示を備えるリクエストを生成し、そして、そのリクエストをＩＰＴＶ−コントローラ４へ送信することによって、ＩＰＴＶ−コンテンツをサーバへアップロードするためのポリシーをセットアップする。

更なる例示の実施形態に従えば、ポリシーは帯域幅予約であり、これは、期待送信速度に従ってセットアップされ、また、コンテンツアップロード−タイプは、標準化トランスファータイプ−属性、例えば、「プログレッシブ」、「ストリーミング」あるいは「アダプティブ」によって指示される。これらの属性は、それぞれ、プログレッシブアップロード、ストリーミングアップロード、あるいはアダプティブストリーミングアップロードを示している。

他の例示の実施形態に従えば、ＩＰＴＶはＩＭＳベースであり、コンテンツアップロード−タイプの指示は、リクエストに含まれるＳＤＰオファーに含まれる。また、ＳＤＰオファーは、提案される帯域幅を示す帯域幅属性を含んでいても良い。

また更なる実施形態に従えば、ユーザ機器は、トランスポートタイプ−属性によって指示されるトランスポート−タイプに対して要求される帯域幅が利用可能でない場合、リクエストの拒否を受信することになり、そして、ユーザ機器は、拒否の受信時に、異なるトランスポートタイプ−属性を備えるリクエストを生成することができる。

ユーザ機器はＩＰＴＶコントロールノードと通信して、アップロード及びダウンロード用のポリシーをセットアップする。ダウンロードに向けられるＩＰＴＶコントロールノード４に対する方法の実施形態に従えば、ＩＰＴＶコントロールノード４は、コンテンツサーバ５からユーザ機器１へＩＰＴＶコンテンツをダウンロードするためのポリシーをセットアップし、ここで、ＩＰＴＶコントローラはユーザ機器からリクエストを受信し、そのリクエストは、コンテンツダウンロード−タイプの指示を含んでいる。

更なる例示の実施形態に従えば、ポリシーは帯域幅予約であり、これは、コンテンツダウンロードのタイプの受信される指示に基づいていて、期待送信速度に従ってＩＰＴＶコントロールノード４によってセットアップされる。このコンテンツダウンロードタイプは、標準化トランスファータイプ−属性、例えば、「プログレッシブ」、「ストリーミング」あるいは「アダプティブ」によって示される。これらの属性は、それぞれ、プログレッシブアップロード、ストリーミングアップロード、あるいはアダプティブストリーミングアップロードを示している。

更なる他の実施形態に従えば、ＩＰＴＶはＩＭＳベースであり、コンテンツダウンロードタイプの指示は、ＵＥから受信されるリクエストに含まれるＳＤＰオファーに含まれる。また、ＳＤＰオファーは、提案される帯域幅を示す帯域幅属性を備えていても良く、そして、コンテンツダウンロードタイプの指示はＳＤＰアンサーにコピーされても良い。

アップロードに向けられるＩＰＴＶコントロールノードのための方法の実施形態に従えば、ＩＰＴＶコントロールノード４は、ＵＥ１からコンテンツサーバ５へＩＰＴＶコンテンツをアップロードするためのポリシーをセットアップし、ここで、ＩＰＴＶコントローラはユーザ機器からリクエストを受信し、このリクエストはコンテンツアップロードタイプの指示を備えている。

例示の実施形態に従えば、ポリシーは帯域幅予約であり、これは、コンテンツアップロードのタイプの受信される指示に基づいて、期待送信速度に従ってセットアップされる。このコンテンツアップロードタイプは、標準化トランスファータイプ−属性、例えば、「プログレッシブ」、「ストリーミング」あるいは「アダプティブ」によって示される。これらの属性は、それぞれ、プログレッシブアップロード、ストリーミングアップロード、あるいはアダプティブストリーミングアップロードを示している。

更なる例示の実施形態に従えば、ＩＰＴＶはＩＭＳベースであり、コンテンツアップロードタイプの指示は、リクエストに含まれるＳＤＰオファーに含まれる。また、ＳＤＰオファーは、提案される帯域幅を示す帯域幅属性を含み、また、コンテンツアップロードタイプの指示はＳＤＰアンサーにコピーされる。

ユーザ機器１の実施形態に従えば、ＵＥは、コンテンツサーバ５からＩＰＴＶ−コンテンツをダウンロードするためのポリシーをセットアップするように構成されていて、ユーザ機器は、処理回路６２が提供される通信デバイス６１を備え、また、コンテンツダウンロード−タイプの指示を備えるリクエストを生成し、そのリクエストをＩＰＴＶ−コントロールノード４へ送信するように構成されている。

加えて、ユーザ機器の実施形態に従えば、ユーザ機器１は、サーバ５へＩＰＴＶ−コンテンツへアップロードするためのポリシーをセットアップするように構成されていて、ユーザ機器は、処理回路６２が提供される通信デバイス６１を備え、また、コンテンツアップロード−タイプの指示を備えるリクエストを生成し、そのリクエストをＩＰＴＶ−コントロールノードへ送信するように構成されている。

つまり、本発明に従うユーザ機器は、好ましくは、ダウンロードとアップロードの両方に対してポリシーをセットアップするように構成されるが、代替としては、ダウンロードあるいはアップロードに対するポリシーをセットアップするように構成されても良い。

ユーザ機器の更なる例示の実施形態に従えば、ポリシーは帯域幅予約であり、コンテンツダウンロードタイプ及びコンテンツアップロードタイプの少なくとも一方は、標準化トランスファータイプ−属性、例えば、「プログレッシブ」、「ストリーミング」あるいは「アダプティブ」によって示され、これらの属性は、それぞれ、プログレッシブアップロード、ストリーミングアップロード、あるいはアダプティブストリーミングアップロードを示している。

更なる例示の実施形態に従えば、ＩＰＴＶはＩＭＳベースであり、トランスファータイプ属性の指示は、リクエストに含まれるＳＤＰオファーに含まれる。加えて、ＳＤＰオファーは、提案される帯域幅を備え、ＵＥはＯＩＴＦ対応（使用可能）である。

上述の例示の方法と同様に、ユーザ機器は、アップロード及びダウンロード用のポリシーをセットアップするためのＩＰＴＶコントロールノードと通信するように構成されている。ＩＰＴＶコントロールノード４の実施形態に従えば、ＩＰＴＶコントロールノード４は、コンテンツサーバ５からユーザ機器１へＩＰＴＶ−コンテンツをダウンロードするためのポリシーをセットアップするように構成されていて、このＩＰＴＶコントロールノードは、処理回路５２が提供される通信デバイス５１を備え、そして、ユーザ機器からリクエストを受信するように構成されている。ここで、このリクエストは、コンテンツダウンロードタイプの指示を備える。

加えて、ＩＰＴＶコントロールノード４の実施形態に従えば、ＩＰＴＶコントロールノードは、コンテンツサーバ５からユーザ機器１へＩＰＴＶコンテンツをアップロードするためのポリシーをセットアップするように構成され、このノードは、処理回路５２が提供される通信デバイス５１を備え、また、ユーザ機器からのリクエストを受信するように構成されている。ここで、このリクエストは、コンテンツアップロードタイプの指示を備える。

別の例示の実施形態に従えば、ポリシーは帯域幅予約であり、また、ＩＰＴＶ対応コントロールノードは、コンテンツダウンロード及びコンテンツアップロードの少なくとも一方のタイプの受信される指示に基づいていて、期待送信速度に従って、帯域幅予約をセットアップするように構成される。このコンテンツアップロードタイプ及びコンテンツアップロードタイプの少なくとも一方は、標準化トランスファータイプ−属性、例えば、「プログレッシブ」、「ストリーミング」あるいは「アダプティブ」によって示される。これらの属性は、それぞれ、プログレッシブアップロード、ストリーミングアップロード、あるいはアダプティブストリーミングアップロードを示している。

また更なる例示の実施形態に従えば、ＩＰＴＶはＩＭＳベースであり、トランスファータイプ属性は、リクエストに含まれるＳＤＰオファーに含まれ、また、ＳＤＰオファーは、提案される帯域幅を備える。

ＩＰＴＶコントロールノードは、更に、コンテンツアップロードタイプ及びコンテンツダウンロードタイプの少なくとも一方の受信された指示を、コンテンツサーバのＭＣＦを介してＳＤＰアンサーにコピーされるように構成されていても良い。

つまり、実施形態に従うＩＰＴＶコントロールノードは、好ましくは、ダウンロードとアップロードの両方に対するポリシーをセットアップするように構成されるが、選択的には、ダウンロードあるいはアップロードの一方に対するポリシーをセットアップするように構成されていても良い。

図２ｃ及び図２ｄとに記載されるように、例示の実施形態は、非ＩＭＳネットワーク、例えば、いわゆる、プレーンあるいは従来のＩＰＴＶに適用可能である。但し、非ＩＭＳネットワークの場合、ＳＩＰのような個別のプロトコルが、帯域幅を割り当てるための、かつ帯域幅の割当を解除するためのバックエンドを伴うセッションを作成するために要求され、これには、例えば、ＳＯＡＰあるいはＤＩＡＭＥＴＥＲプロトコルがある。選択的には、新規のＨＴＴＰヘッダに、提案される帯域幅及び含められるトランスファータイプを伴って追加することができ、あるいは、情報を、任意の個別のプロトコルを要求することなく、ＨＴＴＰリクエストＵＲＩにカプセル化することができる。

また、上述のかつ記載の実施形態は例示としてのみ与えられ、本発明を制限するものとするべきではない。本願の特許請求の範囲の請求項で定義される発明の範囲内で、他のソリューション、用途、目的及び機能が、当業者にとって明らかであろう。

略語
ＯＩＴＦ＝オープンＩＰＴＶフォーラム
ＳＤＰ＝セッション記述プロトコル
ＭＣＦ＝メディア制御機能
ＩＡＰ＝ＩＰＴＶアプリケーションプラットホーム
ＲＡＣＳ＝リソース及び管理制御サブシステム
ＳＰＤＦ＝サービスベースポリシー決定機能
ＤＡＥ＝宣言型アプリケーション環境
ＱｏＳ＝サービス品質
ＵＲＩ＝ユニフォームリソース識別子
ＳＯＡＰ＝シンプルオブジェクトアクセスプロトコル
ＨＴＴＰ＝ハイパーテキストトランスファー（転送）プロトコル
ＳＩＰ＝セッション開始プロトコル

Claims (22)

1. コンテンツサーバ（５）からＩＰＴＶコンテンツをダウンロードするためのポリシー、あるいはコンテンツサーバ（５）へＩＰＴＶコンテンツをアップロードするためのポリシーをセットアップするユーザ機器（１）の方法であって、
   コンテンツダウンロードあるいはコンテンツアップロードのタイプの指示を有するリクエストを生成するステップ（３１）と、
   前記リクエストをＩＰＴＶコントロールノード（４）へ送信するステップ（３２）と
   を備えることを特徴とする方法。
2. 前記ポリシーは、帯域幅予約である
   ことを特徴とする請求項１に記載の方法。
3. 前記コンテンツダウンロードあるいはコンテンツアップロードのタイプは、トランスファータイプ属性によって指示される
   ことを特徴とする請求項１または２に記載の方法。
4. 前記トランスファータイプ属性は、プログレッシブ、ストリーミングあるいはアダプティブを示す値の１つを有する
   ことを特徴とする請求項３に記載の方法。
5. 前記ＩＰＴＶは、ＩＭＳベースであり、
   トランスファータイプ属性が、前記リクエストに含まれるＳＤＰオファーに含まれる
   ことを特徴とする請求項１乃至４のいずれか１項に記載の方法。
6. 前記ＳＤＰオファーは、更に、提案される帯域幅を含んでいる
   ことを特徴とする請求項５に記載の方法。
7. トランスファータイプ属性によって要求される帯域幅が利用可能でない場合、前記ユーザ機器が、前記リクエストの拒否を受信するステップを更に備える
   ことを特徴とする請求項２乃至６のいずれか１項に記載の方法。
8. 拒否が受信される場合に、異なるトランスファータイプ属性を含むリクエストを生成するステップを更に備える
   ことを特徴とする請求項７に記載の方法。
9. コンテンツサーバ（５）からユーザ機器（１）へＩＰＴＶコンテンツをダウンロードするための、あるいはユーザ機器（１）からコンテンツサーバ（５）へＩＰＴＶコンテンツをアップロードするための、ポリシーをセットアップするＩＰＴＶコントロールノード（４）のための方法であって、
   前記ユーザ機器からのリクエストとして、コンテンツダウンロードあるいはコンテンツアップロードのタイプの指示を備えるリクエストを受信するステップ（４１）を備える
   ことを特徴とする方法。
10. 前記コンテンツダウンロードあるいはコンテンツアップロードのタイプは、トランスファータイプ属性によって指示される
    ことを特徴とする請求項９に記載の方法。
11. 前記ポリシーは、前記コンテンツダウンロードあるいはコンテンツアップロードのタイプに基づく帯域幅予約であり、期待送信速度に従ってセットアップされる
    ことを特徴とする請求項９または１０に記載の方法。
12. 前記コンテンツサーバのＭＣＦ（メディア制御機能）を介して、前記リクエストに含まれるＳＤＰオファーからのトランスファータイプ属性を、応答に含まれるＳＤＰアンサーにコピーするステップを更に備える
    ことを特徴とする請求項１０または１１に記載の方法。
13. コンテンツサーバ（５）からＩＰＴＶコンテンツをダウンロードするためのポリシー、及びコンテンツサーバ（５）へＩＰＴＶコンテンツをアップロードするためのポリシーの少なくとも一方をセットアップするように構成されているユーザ機器（１）であって、
    処理回路（５２）が提供されている通信デバイス（５１）を備え、
    前記通信デバイスは、
    コンテンツダウンロード及びコンテンツアップロードの少なくとも一方のタイプの指示を有するリクエストを生成し、
    前記リクエストをＩＰＴＶコントロールノード（４）へ送信する
    ように構成されている
    ことを特徴とするユーザ機器。
14. 前記ポリシーは、帯域幅予約である
    ことを特徴とする請求項１３に記載のユーザ機器。
15. 前記コンテンツダウンロードあるいはコンテンツアップロードのタイプは、トランスファータイプ属性によって指示される
    ことを特徴とする請求項１３または１４に記載のユーザ機器。
16. 前記トランスファータイプ属性は、プログレッシブ、ストリーミングあるいはアダプティブを示す値の１つを有する
    ことを特徴とする請求項１５に記載のユーザ機器。
17. 前記ＩＰＴＶは、ＩＭＳベースであり、
    前記トランスファータイプ属性は、前記リクエストに含まれるＳＤＰオファーに含まれる
    ことを特徴とする請求項１５また１６に記載のユーザ機器。
18. 前記ＳＤＰオファーは、更に、提案される帯域幅を含んでいる
    ことを特徴とする請求項１７に記載のユーザ機器。
19. コンテンツサーバ（５）からユーザ機器（１）へＩＰＴＶコンテンツをダウンロードするための、及びユーザ機器（１）からコンテンツサーバ（５）へＩＰＴＶコンテンツをアップロードするための少なくとも一方のための、ポリシーをセットアップするように構成されているＩＰＴＶコントロールノード（４）であって、
    処理回路（６２）が提供されている通信デバイス（６１）を備え、
    前記通信デバイスは、
    前記ユーザ機器からのリクエストとして、コンテンツダウンロード及びコンテンツアップロードの少なくとも一方のタイプの指示を備えるリクエストを受信する
    ように構成されている
    ことを特徴とするＩＰＴＶコントロールノード。
20. 前記コンテンツダウンロード及びコンテンツアップロードのタイプの少なくとも一方は、トランスファータイプ属性によって指示される
    ことを特徴とする請求項１９に記載のＩＰＴＶコントロールノード。
21. 前記ポリシーは、前記コンテンツダウンロードあるいはコンテンツアップロードのタイプに基づく帯域幅予約であり、期待送信速度に従ってセットアップされる
    ことを特徴とする請求項１９または２０に記載のＩＰＴＶコントロールノード。
22. 前記コンテンツサーバ（５）のＭＣＦ（メディア制御機能）を介して、前記リクエストに含まれるＳＤＰオファーからの前記トランスファータイプ属性を、応答に含まれるＳＤＰアンサーにコピーするステップを更に備える
    ことを特徴とする請求項２０または２１に記載のＩＰＴＶコントロールノード。

Images