コンテンツダウンロード及びコンテンツアップロード用ポリシー
方法及び装置は、コンテンツサーバ(5)からユーザ機器(1)へIPTVメディアコンテンツのダウンロードのための、及びユーザ機器からコンテンツサーバへのメディアコンテンツのアップロードのための、ポリシーをセットアップする。このポリシーは、典型的には、帯域幅予約であり、そして、コンテンツダウンロード/アップロードのタイプは、ユーザ機器からの初期リクエスト、例えば、IPTVコントロールノード(4)へ送信されるSDPオファーに含められることになる。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、ユーザ機器及びIPTVコントロールノード(IPTV制御ノード)に対する、メディアコンテンツサーバ、ユーザ機器及びIPTVコントロールノードへのIPTVメディアコンテンツのアップロードあるいは、メディアコンテンツサーバ、ユーザ機器及びIPTVコントロールノードからのIPTVメディアコンテンツのダウンロードの方法に関するものである。
【背景技術】
【0002】
エンドユーザは、UE(ユーザ機器)が適切な機能を有しているという条件で、例えば、IMS(インターネットプロトコルマルチメディアサブシステム)を介して、様々なタイプのUEからIPTV(インターネットプロトコルテレビ)サービスへアクセスすることができる。このユーザ機器には、例えば、TV、PC(パーソナルコンピュータ)あるいは移動電話がある。この適切な機能については、例えば、オープンIPTV−フォーラム−仕様書に従って規定されている。
【0003】
従来、帯域幅は、セッションのセットアップ中に予約することができる。このセッションには、例えば、ユニキャストストリームを使用するビデオオンデマンドセッション、あるいはマルチキャストストリームを使用する一般的なテレビブロードキャストセッションがある。帯域幅予約は、加入者に対する「ラストマイル(last mile)」と集約ネットワークの両方において、サービスを途絶することなくあるいは中断することなく、ユーザに適切な経験を提供するために十分な帯域幅が存在することを補償するものである。また、ラストマイルで利用可能な帯域幅を、2つのセッションが同時に超過する場合がある。このことは、2つのセッション内のパケット群が競合することを生じさせ、その結果、いくつかのパケットが両方のセッション内で破棄されることになる。つまり、一旦、既存のセッションに対して帯域幅が予約されると、その既存のセッションに影響を与える新規のセッションは許可されないことが重要である。
【0004】
メディアコンテンツは、プログレッシブダウンロードによって、メディアコンテンツサーバからクライアント端末として動作するUEへダウンロードすることができ、UEにおいては、ストリーミングダウンロードあるいはアダプティブストリーミングダウンロードによって、メディアコンテンツがローカルバッファに記憶されることで、ダウンロードが完了する前にメディアファイルを再生することを可能にする。ここで、ストリーミングダウンロードでは、メディアコンテンツはコンテンツサーバから、再生のレートでストリーミングされ、ここでは、メディアコンテンツの記憶はなされない。アダプティブストリーミングダウンロードは、コンテンツを様々なビットレートでダウンロードすることができる。同様に、メディアコンテンツは、UEからコンテンツサーバへアップロードすることができ、また、続いて、ダウンロードを使用して他のユーザと共有することもできる。
【発明の概要】
【発明が解決しようとする課題】
【0005】
しかしながら、従来のメディアコンテンツのHTTPプログレッシブダウンロードは、ベストエフォート型のサービス品質だけをサポートする。即ち、QoSは保証されない。また、帯域幅は、最大帯域幅でない可能性がある。その結果、メディアコンテンツの解像度が高く、また、ネットワークの帯域幅に制限がある場合、ユーザが経験する再生は貧弱になる可能性がある。例えば、周知のウェブサイトであるYouTubeからダウンロードされるメディアコンテンツは、ベストエフォート型のサービス品質だけを使用して、ダウンロードされながら表示される。解像度が制限され、かつ高すぎない場合では、利用可能な帯域幅は十分であり、ユーザが経験するディアコンテンツの再生は受け入れられるものとなる。しかしながら、そうでない場合には、ユーザ経験は貧弱になる可能性がある。
【0006】
また、プログレッシブでダウンロードされるメディアファイルを正常に再生するためには、UE、即ち、クライアント端末が、大量のメディアコンテンツをバッファできることが要求される。
【0007】
つまり、ユーザが受け入れ可能なメディアコンテンツの再生を経験することを達成するためには依然として課題が残っている。
【0008】
本明細書で記載される実施形態の目的は、上述の課題の少なくともいくつかを取り扱うことであり、また、この目的及びその他の目的は、添付の独立請求項に従う方法及び装置によって、また、従属請求項に従う実施形態によって、達成される。
【課題を解決するための手段】
【0009】
第1の態様に従う実施形態は、コンテンツサーバからIPTVコンテンツをダウンロードするためのポリシー、あるいはコンテンツサーバへIPTVコンテンツをアップロードするためのポリシーをセットアップするユーザ機器ための方法を提供する。ユーザ機器は、コンテンツダウンロードあるいはコンテンツアップロードのタイプの指示を有するリクエストを生成し、前記リクエストをIPTVコントロールノードへ送信する。
【0010】
第2の態様に従う実施形態は、コンテンツサーバからユーザ機器へIPTVコンテンツをダウンロードするための、あるいはユーザ機器からコンテンツサーバへIPTVコンテンツをアップロードするための、ポリシーをセットアップするIPTVコントロールノードのための方法を提供する。IPTVコントロールノードは、前記ユーザ機器からのリクエストとして、コンテンツダウンロードあるいはコンテンツアップロードのタイプの指示を備えるリクエストを受信する。
【0011】
第3の態様に従う実施形態は、コンテンツサーバからIPTVコンテンツをダウンロードするためのポリシー、及びコンテンツサーバへIPTVコンテンツをアップロードするためのポリシーの少なくとも一方をセットアップするように構成されているユーザ機器を提供する。ユーザ機器は、処理回路が提供されている通信デバイスを備え、前記通信デバイスは、コンテンツダウンロード及びコンテンツアップロードの少なくとも一方のタイプの指示を有するリクエストを生成し、前記リクエストをIPTVコントロールノードへ送信するように構成されている。
【0012】
第4の態様に従う実施形態は、コンテンツサーバからユーザ機器へIPTVコンテンツをダウンロードするための、及びユーザ機器からコンテンツサーバへIPTVコンテンツをアップロードするための少なくとも一方のための、ポリシーをセットアップするように構成されているIPTVコントロールノードを提供する。IPTVコントロールノードは、処理回路が提供されている通信デバイスを備え、前記通信デバイスは、前記ユーザ機器からのリクエストとして、コンテンツダウンロード及びコンテンツアップロードの少なくとも一方のタイプの指示を備えるリクエストを受信するように構成されている。
【0013】
例示の実施形態に伴う効果は、メディアコンテンツの信頼のあるダウンロードあるいはアップロードを可能にし、そうすることで、再生を行うユーザ経験が、例えば、ネットワークにおける輻輳による影響を受けないようにする。
【図面の簡単な説明】
【0014】
【図1a】メディアコンテンツのダウンロード及びアップロードに対する例示のIMS IPTVアーキテクチャを示すブロック図である。
【図1b】OITF対応UEを示す図である。
【図2a】IMS IPTVアーキテクチャにおける例示のUEから開始されるコンテンツダウンロードセッションを示すシグナリング図である。
【図2b】IMS IPTVアーキテクチャにおける例示のUEから開始されるコンテンツダウンロードセッションを示すシグナリング図である。
【図2c】プレーンIPTVに対して例示のUEから開始されるコンテンツダウンロードセッションを示すシグナリング図である。
【図2d】プレーンIPTVに対して例示のUEから開始されるコンテンツダウンロードセッションを示すシグナリング図である。
【図3】コンテンツアップロードあるいはコンテンツダウンロードに関連するUEに対する方法を示すフロー図である。
【図4】コンテンツアップロードあるいはコンテンツダウンロードに関連するIPTVコントロールノードに対する方法を示すフロー図である。
【図5】例示のUEを示すブロック図である。
【図6】例示のIPTVコントロールノードを示すブロック図である。
【発明を実施するための形態】
【0015】
以下では、実施形態とそれに伴う図面を参照して本発明の詳細を説明する。例示の目的で、また、限定する目的ではない、特定の詳細が本発明の全体理解を提供するために説明され、これには、特定の状況、技術等が含まれる。しかしながら、当業者には、本発明が、これらの特定の詳細とは別の実施形態で実施されても良いことが明らかであろう。
【0016】
また、以下の本明細書で説明される機能及び手段は、プログラム化マイクロプロセッサあるいは汎用コンピュータと協働して動作するソフトウェア、及び特定用途集積回路(ASIC)の少なくとも一方を使用して実現されても良いことは当業者には明らかであろう。また、本発明が主に方法及びデバイスの形式で記載されている一方で、本発明は、コンピュータプログラムだけでなく、コンピュータプロセッサ及びそのコンピュータプロセッサに接続されるメモリを備えるシステムにおいても実現されても良いことも明らかであろう。ここで、メモリには、本明細書で開示される機能群を実行することができる1つ以上のプログラムがエンコードされている。
【0017】
以下に記載される実施形態の概念は、ユーザ機器から初期リクエストでコンテンツダウンロードあるいはコンテンツアップロードのタイプを示すことで、メディアコンテンツのダウンロード及びアップロードの少なくとも一方に対するポリシーをセットアップする、例えば、適切な帯域幅を予約することである。
【0018】
更なる実施形態に従えば、コンテンツダウンロードあるいはコンテンツアップロードのタイプは、初期リクエスト内のトランスファー(転送)タイプ属性によって指示され、この属性は、初期リクエスト内に含まれるSDPオファー(SDP Offer:SDP提案)に含まれる。別の実施形態に従えば、帯域幅を提案する帯域幅属性は、オプションとして、初期リクエストに含まれる。
【0019】
このトランスファータイプ属性は、例えば、IMSとローカルトランスポートポリシーに、セッションが特定の要件でセットアップされるべきであることを示すものである。例えば、トランスファータイプ属性がストリーミングダウンロードを示していて、また、特定の帯域幅が帯域幅属性で示されている場合、ストリーミングダウンロードセッションが、帯域幅属性で示される帯域幅に従って、保証された帯域幅でセットアップされるべきである。つまり、帯域幅属性で示される帯域幅は、円滑な送信を行うために必要とされる期待最大帯域幅を示している。
【0020】
更なる実施形態に従えば、トランスポートタイプ属性とオプションで提案される帯域幅とを含むリクエストは、そのリクエスト内で指示されるトランスポートのタイプに対して要求される帯域幅がネットワークで利用可能でない場合には拒否されることになる。そうである場合、ユーザ機器は、次のリクエストで異なるトランスポートタイプ属性を含めることができる。
【0021】
IMSベースのIPTVソリューションにおいて、例示の実施形態に従えば、QoS(サービス品質)は、QoS(サービス品質)は、例えば、TISPAN RACS−アーキテクチャに従って定義されるように保証されても良い。リニアTV用及びビデオオンデマンド用に要求されるシグナリングは、例えば、TISPANー仕様書及びOITF(オープンIPTVフォーラム)仕様書で既定されている。
【0022】
例示の実施形態は、コンテンツのダウンロードとコンテンツのアップロードとの結び付けと、例えば、IMS/RACSによって提供される上述のQoSメカニズムを提供し、そうすることで、最小送信速度で、例えば、プログレッシブダウンロード、ストリーミングダウンロード、及びアダプティブストリーミングダウンロードのタイプのダウンロード中に、途切れのないメディアコンテンツの視聴をサポートすることを可能にすることを保証する。
【0023】
つまり、本発明の実施形態に従えば、上述のトランスファータイプ属性が、コンテンツダウンロード用のSDPオファーに含められ、そうすることで、コンテンツダウンロード用のポリシーを専用にセットアップする。この属性は、IMS/RACSにおけるローカルポリシーを制御すること、例えば、帯域幅を予約すること、あるいはアクセスネットワーク内の適切な優先度を選択することの柔軟性を実現する。RACSポリシーは、例えば、標準化SPDF(サービスベースのポリシー決定機能)に従ってセットアップされる。
【0024】
典型的には、HTTPコンテンツダウンロード用のトランスポートタイプは、エンドユーザの動作及びユーザ機器の構成設定(コンフィグレーション)に基づいて、ユーザ機器によって判定される。ユーザが視聴するコンテンツを選択し、かつユーザ機器がコンテンツを記憶するように構成設定されていない場合、コンテンツは、ユーザ機器の再生速度で、コンテンツのストリーミングダウンロードを使用してコンテンツサーバから取得されることになる。
【0025】
しかしながら、ユーザ機器がコンテンツを記憶するように構成設定される場合、コンテンツは、プログレッシブダウンロードを使用して、コンテンツサーバから取得されることになる。即ち、コンテンツはユーザ機器に記憶されるあるいはバッファされると同時に再生される。
【0026】
アダプティブストリーミングダウンロードでは、エンドユーザは、コンテンツがアダプティブストリームとして利用可能であるべきことをリクエストし、そうすることで、コンテンツを、特別なスキームに従って、異なるビットレートでダウンロードすることができる。例えば、ユーザ機器は、バッファが空きになることを検出する場合には、より高速なビットレートストリーム用の帯域幅の不足が存在し、かつより低速なダウンロードビットレートへのシフトが存在すると仮定することができる。
【0027】
上述のように、従来のHTTPコンテンツダウンロードは、ベストエフォート型の送信であり、ダウンロードの速度は利用可能な帯域幅に制限される。しかしながら、異なるタイプのコンテンツダウンロードとコンテンツアップロードとの差別化を図るために、トランスファータイプ属性が、本発明の実施形態に従って、ユーザ機器からの初期リクエストに含められる。
【0028】
異なるタイプのコンテンツダウンロードは、ベストエフォートQoSよりもわずかに高いQoSで差別化される。これは、ベストエフォートQoSは、最小送信要件を有さないからである。
【0029】
上述のように、上述の概念は、例えば、ユーザによって生成されるダウンロード用に適用することができるばかりか、アップロード用にも適用することができる。アップロードコンテンツは、ダウンロードを使用して、他のユーザと連続的に共有することができるので、一定の転送を要求することになる。
【0030】
図1aは、例示のIMS IPTVアーキテクチャと、IMS IPTVにおいて適用可能なプロトコル、即ち、SIP(セッション開始プロトコル)及びHTTP(ハイパーテキスト転送プロトコル)を示すブロック図であり、この適用可能なプロトコルは、コンテンツサーバからUEへメディアをダウンロードするためのもの、あるいはメディアコンテンツをコンテンツサーバへアップロードするためのものである。このアーキテクチャは、OITF対応(使用可能)UE1、IMSゲートウェイ2、図ではIMS/RACSの円3で示されているIMSメディアサーバあるいはビデオオンデマンドポンプ、IPTVコントローラ4、及びメディア制御機能(MCF)を備えるコンテンツサーバ5を備えている。IPTVコントローラ4は、例えば、オープンIPTVフォーラムで定義される、例えば、IPTVアプリケーションプラットホーム(IAP)を備えていても良い。
【0031】
図1bは、OITF対応ユーザ機器1を示すブロック図であり、これは、オープンIPTVフォーラム仕様書で定義される、宣言型アプリーケーション環境(DAE)用の機能と、ローカルオブジェクトコードを備え、DAEはUEのブラウザを備える。
【0032】
より具体的には、例示のUEによって指示されるユニキャストコンテンツダウンロードセッションでは、発信側のUEが初期INVITE−リクエストを生成する。リクエスト−URI(ユニフォームリソース識別子)は、ダウンロードコンテンツURIを、ユニキャストロケータ内と、TO−ヘッダ内に含める。この識別子はサービス選択情報から取得される。また、FROM−ヘッダは、ユーザのパブリックユーザアイデンティティを指示する。
【0033】
SDPオファーは、メディアケイパビリティと、コンテンツダウンロードセッション用に利用可能な要求される帯域幅に従って、INVITE(招待)リクエストに含められる。
【0034】
つまり、メディアレベルでの例示の典型的なSDPオファーは、例えば、以下の要素を含んでいても良い。
【0035】
− HTTPダウンロード用の「m=」ライン、例えば、以下のフォーマットの「m=」ライン:
m=<media><port><transport><fmt>
これは、「アプリケーション(application)」の値を有するメディアフィールドを有し、また、ディスカード(discard)ポートである9の値に設定されるポートフィールドを有し、更には、TCPに設定されるトランスポートフィールドを有する。また、fmt−パラメータが含められ、これは、iptv_httpに設定され、その結果、「m=アプリケーション 9 tcp iptv_http」となる。
【0036】
− 「a=setup」属性が「アクティブ(active)」に設定され、例えば、a=setup:activeとなる。
【0037】
− 「a=connection」属性が「new」として設定され、例えば、a=connection:newとなる。
【0038】
−「c=」ラインが、INに設定される値と、IP4あるいはIP6に設定されるアドレスタイプと、及び関連するHTTPチャネルのフローのIPアドレスを有するネットワークタイプに含められ、例えば、c=IN IP4 <IP_ADDRESS>となる。
【0039】
本発明の実施形態に従えば、SDPオファーの「b=」ラインは、オプションとして、提案される帯域幅を示す帯域幅属性を含んでいても良い。ユーザが、サービス選択手順中にこの特定のコンテンツ配信チャネルに対して要求される帯域幅をフェッチしている場合、メディアレベルでの帯域幅属性は、「b=」ラインでこの値が設定され、例えば、b=AS:15000となる。
【0040】
従って、コンテンツサーバのMCF(メディアコンテンツ機能)は、ITPVコントローラを介して、SDPオファーを受信することになり、これは、トランスファータイプー属性と、提案される帯域幅を示す帯域幅属性(「b=」ラインにおいて)を含んでいても良い。コンテンツサーバのMCFは、ダウンロードあるいはアップロード用のコンテンツを準備する際にIPTVコントローラをアシストすることになり、そして、受信するトランスファータイプ−属性をSDPアンサーにコピーし、これは、IPTVコントローラへ転送される。
【0041】
加えて、本発明の実施形態に従えば、例えば、「fmtp:iptv_http transfer−type(トランスファー(転送)タイプ)」属性のような、SDPオファーに含まれるトランスファータイプ−属性によって、上述のように、コンテンツダウンロードのタイプが、初期INVITE−リクエストで指示される。本発明の第1の実施形態に従えば、トランスファータイプ−属性に対して適用可能な値は、「プログレッシブ」、「ストリーミング」、及び「アダプティブ」となる。
【0042】
「プログレッシブ」コンテンツダウンロード−タイプは、ダウンロード中に視聴されるコンテンツを示していて、また、そのコンテンツはUEに記憶されるあるいはバッファされるので、比較的大きな帯域幅を要求する。
【0043】
「ストリーミング」コンテンツダウンロードタイプ、例えば、HTTPストリーミングは、記憶することなく、あるいはRSTPストリーミングと同様に、UEでのバッファリングが制限されて、視聴されるコンテンツを示している。
【0044】
「アダプティブ」コンテンツダウンロードタイプ、例えば、HTTPアダプティブストリーミングは、異なる帯域幅と異なる品質で視聴することができるコンテンツを示している。
【0045】
「b=」ラインは、オプションの帯域幅属性であり、そして、最高品質のストリーミング用の帯域幅を示している。
【0046】
更に例示の実施形態に従えば、トランスファー−タイプ属性の様々な他の値を、コンテンツダウンロードの他の所有タイプ、例えば、a=fmtp:iptv_http transfer−type=<transfer−type>を示すために使用することができる。
【0047】
図2aと図2bは、IMS IPTV−アーキテクチャにおけるクライアント端末として動作するユーザ機器1に対する例示のシグナリングシーケンスを示すシグナリング図を示している。この図は、本発明の実施形態に従えば、帯域幅予約を含む、コンテンツサーバ5からユーザ機器がダウンロードするメディアコンテンツを示している。この図は、また、介在する論理ユニットを示している。
【0048】
UE(OITF)−ボックス1は、OITF対応ユーザ機器を示していて、これは、オープンIPTVフォーラムで定義される宣誓型アプリケーション環境(DAE)用の機能を備え、更には、ローカルオブジェクトコード(LOC)を備えている。また、IG−box2はIMSゲートウェイに対応し、IMS/RACS−box3はIMSメディアサーバあるいはビデオオンデマンドポンプに対応し、また、IPTVコントローラ4はIPTVアプリケーションプラットホーム(IAP)を備えている。コンテンツサーバ5は、メディアコントローラ機能(MCF)を備える。
【0049】
図2aの信号S11では、UE1はダウンロードセッションを示していて、これは信号S12で作成される。信号S13では、SIP INVITEがIMSゲートウェイ2からIMSメディアサーバ3へ転送され、また、信号S15で、IPTVコントローラ4へ転送される。ここで、SIP INVITEはSDP(セッション記述プロトコル)オファーを含んでいる。そして、ステップ16で、IPTVコントローラ4とコンテンツサーバ5によって、コンテンツがダウンロード用に準備される。
【0050】
先行するステップ14では、IMS/RACSによってダウンロード用のポリシーがチェックされて、かつ適用され、そして、帯域幅予約が実行される。これには、SIP INVITEのSDPオファーで指示されるトランスポート−タイプによって要求される帯域幅が利用可能であるかを判定するために、アクセスネットワーク内のネットワークトポロジーがRACSによってチェックされることを含んでいる。利用可能である場合、帯域幅が予約され、信号S15で、SIP INVITEがIPTVコントローラへ転送されることになる。しかしながら、要求される帯域幅が利用可能でない場合、SIP INVITEは拒否されることになり、その結果、SIP INVITEはIPTVコントローラには転送されない。IPTVコントローラが拒否されてないSIP INVITEを受信する場合、コンテンツは、上述のステップ16において、ダウンロード用に用意されることになる。
【0051】
次に、信号S17において、IPTVコントローラは、SDPアンサーと、セッションに対するURLで応答することになる。これは、信号S19で、IMSゲートウェイに転送され、先行するステップ18において、帯域幅予約が確認される。その後、信号S20で、セッションが作成される。UEは、図2bの信号S21、S22及びS23で、コンテンツサーバ5から、コンテンツのダウンロード用に受信されるセッションURLを使用する。信号S24−S30で、ステップ26において、ダウンロードセッションが終了され、これにはネットワークリソースの解放(リリース)が含まれる。最終的には、信号S31とS32で、ダウンロードコンテンツが再生される。
【0052】
上述の図2aと2bは、ダウンロードセッションを示している。しかしながら、同様のシグナリング手順がアップロードセッションに対して使用されても良い。
【0053】
他の例示の実施形態は、他のプロトコルを使用する非IMSネットワーク内のプレーンIPTVに向けられているものであり、この他のプロトコルは、例えば、SIPに代わる、SOAP(シンプルオブジェクトアクセスプロトコル)あるいはDIAMETERプロトコルである。
【0054】
つまり、図2c及び図2dは、IMSゲートウェイを有さない代わりに、SOAPを使用し、そして、IPTVコントローラ4へのRACSインタフェース3を有するプレーンIPTVアーキテクチャ用の例示のシグナリング図を示している。図2cの信号S110で、UE1はダウンロードセッションを開始し、これは、信号S120で作成される。信号S130で、IPTVコントローラは、RACSインタフェースに対してSOAP予約帯域幅を発行する。予約が確認される場合、ステップ140において、信号S150で、SOAP応答がIPTVコントローラへ送信される。ステップ160において、信号S170で、IPTVコントローラはダウンロード用のコンテンツを準備して、そして、セッションが作成される。
【0055】
UEは、図2dの信号S180、S190及びS200で、コンテンツサーバ5から、コンテンツのダウンロード用として受信されるセッションURLを使用する。信号S210−S260で、ステップS230において、ダウンロードセッションが終了され、これにはネットワークリソースの解放(リリース)が含まれる。そして、最終的には、信号S270とS280で、ダウンロードコンテンツが再生される。
【0056】
図3は、本発明の実施形態に従う、メディアコンテンツのアップロードあるいはダウンロード用のポリシーをセットアップする、ユーザ機器のための方法を示すフロー図である。ステップ35において、UEは、コンテンツダウンロードあるいはコンテンツアップロードのタイプを示すリクエストを生成し、ステップ36において、そのリクエストをIPTVコントロールノードへ送信する。更なる実施形態に従えば、ポリシーは帯域幅予約であり、また、タイプは、初期リクエストのSDPオファー内に含まれるトランスポートタイプ−属性によって指示される。更なる実施形態に従えば、トランスファータイプ−属性は、上述のように、「プログレッシブ」、「ストリーミング」あるいは「アダプティブ」の値の内の1つを有している。図3のステップ35及びステップ36は、ダウンロードに向けられる場合には、基本的には、図2aの信号S11−S15に対応する。
【0057】
図4は、本発明の実施形態に従う、メディアコンテンツのアップロードあるいはダウンロード用のポリシーをセットアップする、IPTVコントロールノードのための方法を示すフロー図である。ステップ41において、IPTVコントロールノードは、UEからのリクエストを受信する。このリクエストは、コンテンツダウンロードあるいはコンテンツアップロードのタイプを示している。ステップ42において、IPTVコントロールノードは、コンテンツサーバのMCF(メディア制御機能)を介して、SDPアンサーにダウンロードあるいはアップロードのタイプをコピーする。更なる実施形態に従えば、ポリシーは帯域幅予約であり、これは、上述のステップ41においてUEから受信される初期リクエストのSDPオファーに含まれるトランスポートタイプ−属性によって指示される、コンテンツダウンロードあるいはコンテンツアップロードのタイプに基づいていて、期待送信速度に従ってセットアップされる。更なる実施形態に従えば、トランスファータイプ−属性の値は、例えば、プログレッシブ、ストリーミングあるいはアダプティブである。
【0058】
図5は、本発明の実施形態に従う、ユーザ機器1を示すブロック図である。UE1は、例えば、OITF対応移動電話、PC、あるいはTVであり、適切なユーザインタフェースを備えていて、また、これには、プロセッサ回路と適切なソフトウェア、例えば、IPTVフォーラムで定義される、宣言型アプリケーション環境(DAE)に対応するソフトウェアと、ローカルオブジェクトコードが提供される。このソフトウェアは、更に、本発明の実施形態に従う方法を実行するように構成されている。UEは、また、汎用通信デバイス51が提供され、これは、送信機、受信機及び処理回路52を備えることで、例えば、IMSゲートウェイとIMSメディアサーバを介して、IPTVコントローラと通信する。例示の実施形態に従えば、UEは、コンテンツダウンロード及びコンテンツアップロードの少なくとも一方のタイプを指示するSDPオファーを含むリクエストを生成し、そして、送信する。
【0059】
図6は、例示のITPVコントロールノード4を示すブロック図であり、これは、IPTVアプリケーションプラットホーム(IAP)を備えている。ITPVコントロールノードには、更に、通信デバイス61が提供され、これは、送信機、受信機及び処理回路62を備え、更には、通信デバイスと他の適切なハードウェア及びソフトウェアによって、IPTVコントロールノードは、例えば、SDPオファーに含まれるトランスファータイプ−属性で、UEからのコンテンツダウンロードあるいはコンテンツアップロードのタイプを示すリクエストを受信するように構成されている。更なる実施形態に従えば、通信デバイスは、コンテンツサーバに含まれるMCF(メディア制御機能)を介して、トランスファータイプ属性をSDPアンサーにコピーするように構成される。実施形態に従えば、ポリシーは帯域幅予約であり、IPTVコントロールノードは、受信されるトランスファータイプ−属性に基づいていて、期待送信速度に従う帯域幅を有するセッションをセットアップするように構成されている。
【0060】
図5及び図6を参照して上述されるエンティティ群及びユニット群は論理的なユニットであり、個別の物理ユニットに対応している必要はない。
【0061】
つまり、メディアコンテンツのダウンロードに向けられるユーザ機器に対する方法の実施形態に従えば、ユーザ機器1は、コンテンツダウンロード−タイプの指示を備えるリクエストを生成し、そのリクエストをIPTV−コントローラ4へ送信することによってサーバからIPTV−コンテンツをダウンロードするためのポリシーをセットアップする。
【0062】
例示の実施形態に従えば、ポリシーは帯域幅予約であり、そして、コンテンツダウンロード−タイプは、標準化トランスファータイプ−属性によって示される。これには、例えば、プログレッシブダウンロードを意味するプログレッシブ、ストリーミングダウンロードを意味するストリーミング、あるいはアダプティブストリーミングダウンロードがある。
【0063】
更なる例示の実施形態に従えば、IPTVはIMSベースであり、コンテンツダウンロードタイプの指示は、リクエストに含まれるSDPオファーに含まれる。また、SDPオファーは、提案される帯域幅を示す帯域幅属性を含んでも良い。
【0064】
更なる実施形態に従えば、ユーザ機器は、トランスポートタイプ−属性によって指示されるトランスポート−タイプに対して要求される帯域幅が利用可能でない場合、リクエストの拒否を受信することになり、そして、ユーザ機器は、拒否の受信時に、異なるトランスポートタイプ−属性を備えるリクエストを生成することができる。
【0065】
アップロードに向けられるユーザ機器に対する同様の方法の実施形態に従えば、ユーザ機器1は、コンテンツアップロード−タイプの指示を備えるリクエストを生成し、そして、そのリクエストをIPTV−コントローラ4へ送信することによって、IPTV−コンテンツをサーバへアップロードするためのポリシーをセットアップする。
【0066】
更なる例示の実施形態に従えば、ポリシーは帯域幅予約であり、これは、期待送信速度に従ってセットアップされ、また、コンテンツアップロード−タイプは、標準化トランスファータイプ−属性、例えば、「プログレッシブ」、「ストリーミング」あるいは「アダプティブ」によって指示される。これらの属性は、それぞれ、プログレッシブアップロード、ストリーミングアップロード、あるいはアダプティブストリーミングアップロードを示している。
【0067】
他の例示の実施形態に従えば、IPTVはIMSベースであり、コンテンツアップロード−タイプの指示は、リクエストに含まれるSDPオファーに含まれる。また、SDPオファーは、提案される帯域幅を示す帯域幅属性を含んでいても良い。
【0068】
また更なる実施形態に従えば、ユーザ機器は、トランスポートタイプ−属性によって指示されるトランスポート−タイプに対して要求される帯域幅が利用可能でない場合、リクエストの拒否を受信することになり、そして、ユーザ機器は、拒否の受信時に、異なるトランスポートタイプ−属性を備えるリクエストを生成することができる。
【0069】
ユーザ機器はIPTVコントロールノードと通信して、アップロード及びダウンロード用のポリシーをセットアップする。ダウンロードに向けられるIPTVコントロールノード4に対する方法の実施形態に従えば、IPTVコントロールノード4は、コンテンツサーバ5からユーザ機器1へIPTVコンテンツをダウンロードするためのポリシーをセットアップし、ここで、IPTVコントローラはユーザ機器からリクエストを受信し、そのリクエストは、コンテンツダウンロード−タイプの指示を含んでいる。
【0070】
更なる例示の実施形態に従えば、ポリシーは帯域幅予約であり、これは、コンテンツダウンロードのタイプの受信される指示に基づいていて、期待送信速度に従ってIPTVコントロールノード4によってセットアップされる。このコンテンツダウンロードタイプは、標準化トランスファータイプ−属性、例えば、「プログレッシブ」、「ストリーミング」あるいは「アダプティブ」によって示される。これらの属性は、それぞれ、プログレッシブアップロード、ストリーミングアップロード、あるいはアダプティブストリーミングアップロードを示している。
【0071】
更なる他の実施形態に従えば、IPTVはIMSベースであり、コンテンツダウンロードタイプの指示は、UEから受信されるリクエストに含まれるSDPオファーに含まれる。また、SDPオファーは、提案される帯域幅を示す帯域幅属性を備えていても良く、そして、コンテンツダウンロードタイプの指示はSDPアンサーにコピーされても良い。
【0072】
アップロードに向けられるIPTVコントロールノードのための方法の実施形態に従えば、IPTVコントロールノード4は、UE1からコンテンツサーバ5へIPTVコンテンツをアップロードするためのポリシーをセットアップし、ここで、IPTVコントローラはユーザ機器からリクエストを受信し、このリクエストはコンテンツアップロードタイプの指示を備えている。
【0073】
例示の実施形態に従えば、ポリシーは帯域幅予約であり、これは、コンテンツアップロードのタイプの受信される指示に基づいて、期待送信速度に従ってセットアップされる。このコンテンツアップロードタイプは、標準化トランスファータイプ−属性、例えば、「プログレッシブ」、「ストリーミング」あるいは「アダプティブ」によって示される。これらの属性は、それぞれ、プログレッシブアップロード、ストリーミングアップロード、あるいはアダプティブストリーミングアップロードを示している。
【0074】
更なる例示の実施形態に従えば、IPTVはIMSベースであり、コンテンツアップロードタイプの指示は、リクエストに含まれるSDPオファーに含まれる。また、SDPオファーは、提案される帯域幅を示す帯域幅属性を含み、また、コンテンツアップロードタイプの指示はSDPアンサーにコピーされる。
【0075】
ユーザ機器1の実施形態に従えば、UEは、コンテンツサーバ5からIPTV−コンテンツをダウンロードするためのポリシーをセットアップするように構成されていて、ユーザ機器は、処理回路62が提供される通信デバイス61を備え、また、コンテンツダウンロード−タイプの指示を備えるリクエストを生成し、そのリクエストをIPTV−コントロールノード4へ送信するように構成されている。
【0076】
加えて、ユーザ機器の実施形態に従えば、ユーザ機器1は、サーバ5へIPTV−コンテンツへアップロードするためのポリシーをセットアップするように構成されていて、ユーザ機器は、処理回路62が提供される通信デバイス61を備え、また、コンテンツアップロード−タイプの指示を備えるリクエストを生成し、そのリクエストをIPTV−コントロールノードへ送信するように構成されている。
【0077】
つまり、本発明に従うユーザ機器は、好ましくは、ダウンロードとアップロードの両方に対してポリシーをセットアップするように構成されるが、代替としては、ダウンロードあるいはアップロードに対するポリシーをセットアップするように構成されても良い。
【0078】
ユーザ機器の更なる例示の実施形態に従えば、ポリシーは帯域幅予約であり、コンテンツダウンロードタイプ及びコンテンツアップロードタイプの少なくとも一方は、標準化トランスファータイプ−属性、例えば、「プログレッシブ」、「ストリーミング」あるいは「アダプティブ」によって示され、これらの属性は、それぞれ、プログレッシブアップロード、ストリーミングアップロード、あるいはアダプティブストリーミングアップロードを示している。
【0079】
更なる例示の実施形態に従えば、IPTVはIMSベースであり、トランスファータイプ属性の指示は、リクエストに含まれるSDPオファーに含まれる。加えて、SDPオファーは、提案される帯域幅を備え、UEはOITF対応(使用可能)である。
【0080】
上述の例示の方法と同様に、ユーザ機器は、アップロード及びダウンロード用のポリシーをセットアップするためのIPTVコントロールノードと通信するように構成されている。IPTVコントロールノード4の実施形態に従えば、IPTVコントロールノード4は、コンテンツサーバ5からユーザ機器1へIPTV−コンテンツをダウンロードするためのポリシーをセットアップするように構成されていて、このIPTVコントロールノードは、処理回路52が提供される通信デバイス51を備え、そして、ユーザ機器からリクエストを受信するように構成されている。ここで、このリクエストは、コンテンツダウンロードタイプの指示を備える。
【0081】
加えて、IPTVコントロールノード4の実施形態に従えば、IPTVコントロールノードは、コンテンツサーバ5からユーザ機器1へIPTVコンテンツをアップロードするためのポリシーをセットアップするように構成され、このノードは、処理回路52が提供される通信デバイス51を備え、また、ユーザ機器からのリクエストを受信するように構成されている。ここで、このリクエストは、コンテンツアップロードタイプの指示を備える。
【0082】
別の例示の実施形態に従えば、ポリシーは帯域幅予約であり、また、IPTV対応コントロールノードは、コンテンツダウンロード及びコンテンツアップロードの少なくとも一方のタイプの受信される指示に基づいていて、期待送信速度に従って、帯域幅予約をセットアップするように構成される。このコンテンツアップロードタイプ及びコンテンツアップロードタイプの少なくとも一方は、標準化トランスファータイプ−属性、例えば、「プログレッシブ」、「ストリーミング」あるいは「アダプティブ」によって示される。これらの属性は、それぞれ、プログレッシブアップロード、ストリーミングアップロード、あるいはアダプティブストリーミングアップロードを示している。
【0083】
また更なる例示の実施形態に従えば、IPTVはIMSベースであり、トランスファータイプ属性は、リクエストに含まれるSDPオファーに含まれ、また、SDPオファーは、提案される帯域幅を備える。
【0084】
IPTVコントロールノードは、更に、コンテンツアップロードタイプ及びコンテンツダウンロードタイプの少なくとも一方の受信された指示を、コンテンツサーバのMCFを介してSDPアンサーにコピーされるように構成されていても良い。
【0085】
つまり、実施形態に従うIPTVコントロールノードは、好ましくは、ダウンロードとアップロードの両方に対するポリシーをセットアップするように構成されるが、選択的には、ダウンロードあるいはアップロードの一方に対するポリシーをセットアップするように構成されていても良い。
【0086】
図2c及び図2dとに記載されるように、例示の実施形態は、非IMSネットワーク、例えば、いわゆる、プレーンあるいは従来のIPTVに適用可能である。但し、非IMSネットワークの場合、SIPのような個別のプロトコルが、帯域幅を割り当てるための、かつ帯域幅の割当を解除するためのバックエンドを伴うセッションを作成するために要求され、これには、例えば、SOAPあるいはDIAMETERプロトコルがある。選択的には、新規のHTTPヘッダに、提案される帯域幅及び含められるトランスファータイプを伴って追加することができ、あるいは、情報を、任意の個別のプロトコルを要求することなく、HTTPリクエストURIにカプセル化することができる。
【0087】
また、上述のかつ記載の実施形態は例示としてのみ与えられ、本発明を制限するものとするべきではない。本願の特許請求の範囲の請求項で定義される発明の範囲内で、他のソリューション、用途、目的及び機能が、当業者にとって明らかであろう。
【0088】
略語
OITF=オープンIPTVフォーラム
SDP=セッション記述プロトコル
MCF=メディア制御機能
IAP=IPTVアプリケーションプラットホーム
RACS=リソース及び管理制御サブシステム
SPDF=サービスベースポリシー決定機能
DAE=宣言型アプリケーション環境
QoS=サービス品質
URI=ユニフォームリソース識別子
SOAP=シンプルオブジェクトアクセスプロトコル
HTTP=ハイパーテキストトランスファー(転送)プロトコル
SIP=セッション開始プロトコル
【技術分野】
【0001】
本発明は、ユーザ機器及びIPTVコントロールノード(IPTV制御ノード)に対する、メディアコンテンツサーバ、ユーザ機器及びIPTVコントロールノードへのIPTVメディアコンテンツのアップロードあるいは、メディアコンテンツサーバ、ユーザ機器及びIPTVコントロールノードからのIPTVメディアコンテンツのダウンロードの方法に関するものである。
【背景技術】
【0002】
エンドユーザは、UE(ユーザ機器)が適切な機能を有しているという条件で、例えば、IMS(インターネットプロトコルマルチメディアサブシステム)を介して、様々なタイプのUEからIPTV(インターネットプロトコルテレビ)サービスへアクセスすることができる。このユーザ機器には、例えば、TV、PC(パーソナルコンピュータ)あるいは移動電話がある。この適切な機能については、例えば、オープンIPTV−フォーラム−仕様書に従って規定されている。
【0003】
従来、帯域幅は、セッションのセットアップ中に予約することができる。このセッションには、例えば、ユニキャストストリームを使用するビデオオンデマンドセッション、あるいはマルチキャストストリームを使用する一般的なテレビブロードキャストセッションがある。帯域幅予約は、加入者に対する「ラストマイル(last mile)」と集約ネットワークの両方において、サービスを途絶することなくあるいは中断することなく、ユーザに適切な経験を提供するために十分な帯域幅が存在することを補償するものである。また、ラストマイルで利用可能な帯域幅を、2つのセッションが同時に超過する場合がある。このことは、2つのセッション内のパケット群が競合することを生じさせ、その結果、いくつかのパケットが両方のセッション内で破棄されることになる。つまり、一旦、既存のセッションに対して帯域幅が予約されると、その既存のセッションに影響を与える新規のセッションは許可されないことが重要である。
【0004】
メディアコンテンツは、プログレッシブダウンロードによって、メディアコンテンツサーバからクライアント端末として動作するUEへダウンロードすることができ、UEにおいては、ストリーミングダウンロードあるいはアダプティブストリーミングダウンロードによって、メディアコンテンツがローカルバッファに記憶されることで、ダウンロードが完了する前にメディアファイルを再生することを可能にする。ここで、ストリーミングダウンロードでは、メディアコンテンツはコンテンツサーバから、再生のレートでストリーミングされ、ここでは、メディアコンテンツの記憶はなされない。アダプティブストリーミングダウンロードは、コンテンツを様々なビットレートでダウンロードすることができる。同様に、メディアコンテンツは、UEからコンテンツサーバへアップロードすることができ、また、続いて、ダウンロードを使用して他のユーザと共有することもできる。
【発明の概要】
【発明が解決しようとする課題】
【0005】
しかしながら、従来のメディアコンテンツのHTTPプログレッシブダウンロードは、ベストエフォート型のサービス品質だけをサポートする。即ち、QoSは保証されない。また、帯域幅は、最大帯域幅でない可能性がある。その結果、メディアコンテンツの解像度が高く、また、ネットワークの帯域幅に制限がある場合、ユーザが経験する再生は貧弱になる可能性がある。例えば、周知のウェブサイトであるYouTubeからダウンロードされるメディアコンテンツは、ベストエフォート型のサービス品質だけを使用して、ダウンロードされながら表示される。解像度が制限され、かつ高すぎない場合では、利用可能な帯域幅は十分であり、ユーザが経験するディアコンテンツの再生は受け入れられるものとなる。しかしながら、そうでない場合には、ユーザ経験は貧弱になる可能性がある。
【0006】
また、プログレッシブでダウンロードされるメディアファイルを正常に再生するためには、UE、即ち、クライアント端末が、大量のメディアコンテンツをバッファできることが要求される。
【0007】
つまり、ユーザが受け入れ可能なメディアコンテンツの再生を経験することを達成するためには依然として課題が残っている。
【0008】
本明細書で記載される実施形態の目的は、上述の課題の少なくともいくつかを取り扱うことであり、また、この目的及びその他の目的は、添付の独立請求項に従う方法及び装置によって、また、従属請求項に従う実施形態によって、達成される。
【課題を解決するための手段】
【0009】
第1の態様に従う実施形態は、コンテンツサーバからIPTVコンテンツをダウンロードするためのポリシー、あるいはコンテンツサーバへIPTVコンテンツをアップロードするためのポリシーをセットアップするユーザ機器ための方法を提供する。ユーザ機器は、コンテンツダウンロードあるいはコンテンツアップロードのタイプの指示を有するリクエストを生成し、前記リクエストをIPTVコントロールノードへ送信する。
【0010】
第2の態様に従う実施形態は、コンテンツサーバからユーザ機器へIPTVコンテンツをダウンロードするための、あるいはユーザ機器からコンテンツサーバへIPTVコンテンツをアップロードするための、ポリシーをセットアップするIPTVコントロールノードのための方法を提供する。IPTVコントロールノードは、前記ユーザ機器からのリクエストとして、コンテンツダウンロードあるいはコンテンツアップロードのタイプの指示を備えるリクエストを受信する。
【0011】
第3の態様に従う実施形態は、コンテンツサーバからIPTVコンテンツをダウンロードするためのポリシー、及びコンテンツサーバへIPTVコンテンツをアップロードするためのポリシーの少なくとも一方をセットアップするように構成されているユーザ機器を提供する。ユーザ機器は、処理回路が提供されている通信デバイスを備え、前記通信デバイスは、コンテンツダウンロード及びコンテンツアップロードの少なくとも一方のタイプの指示を有するリクエストを生成し、前記リクエストをIPTVコントロールノードへ送信するように構成されている。
【0012】
第4の態様に従う実施形態は、コンテンツサーバからユーザ機器へIPTVコンテンツをダウンロードするための、及びユーザ機器からコンテンツサーバへIPTVコンテンツをアップロードするための少なくとも一方のための、ポリシーをセットアップするように構成されているIPTVコントロールノードを提供する。IPTVコントロールノードは、処理回路が提供されている通信デバイスを備え、前記通信デバイスは、前記ユーザ機器からのリクエストとして、コンテンツダウンロード及びコンテンツアップロードの少なくとも一方のタイプの指示を備えるリクエストを受信するように構成されている。
【0013】
例示の実施形態に伴う効果は、メディアコンテンツの信頼のあるダウンロードあるいはアップロードを可能にし、そうすることで、再生を行うユーザ経験が、例えば、ネットワークにおける輻輳による影響を受けないようにする。
【図面の簡単な説明】
【0014】
【図1a】メディアコンテンツのダウンロード及びアップロードに対する例示のIMS IPTVアーキテクチャを示すブロック図である。
【図1b】OITF対応UEを示す図である。
【図2a】IMS IPTVアーキテクチャにおける例示のUEから開始されるコンテンツダウンロードセッションを示すシグナリング図である。
【図2b】IMS IPTVアーキテクチャにおける例示のUEから開始されるコンテンツダウンロードセッションを示すシグナリング図である。
【図2c】プレーンIPTVに対して例示のUEから開始されるコンテンツダウンロードセッションを示すシグナリング図である。
【図2d】プレーンIPTVに対して例示のUEから開始されるコンテンツダウンロードセッションを示すシグナリング図である。
【図3】コンテンツアップロードあるいはコンテンツダウンロードに関連するUEに対する方法を示すフロー図である。
【図4】コンテンツアップロードあるいはコンテンツダウンロードに関連するIPTVコントロールノードに対する方法を示すフロー図である。
【図5】例示のUEを示すブロック図である。
【図6】例示のIPTVコントロールノードを示すブロック図である。
【発明を実施するための形態】
【0015】
以下では、実施形態とそれに伴う図面を参照して本発明の詳細を説明する。例示の目的で、また、限定する目的ではない、特定の詳細が本発明の全体理解を提供するために説明され、これには、特定の状況、技術等が含まれる。しかしながら、当業者には、本発明が、これらの特定の詳細とは別の実施形態で実施されても良いことが明らかであろう。
【0016】
また、以下の本明細書で説明される機能及び手段は、プログラム化マイクロプロセッサあるいは汎用コンピュータと協働して動作するソフトウェア、及び特定用途集積回路(ASIC)の少なくとも一方を使用して実現されても良いことは当業者には明らかであろう。また、本発明が主に方法及びデバイスの形式で記載されている一方で、本発明は、コンピュータプログラムだけでなく、コンピュータプロセッサ及びそのコンピュータプロセッサに接続されるメモリを備えるシステムにおいても実現されても良いことも明らかであろう。ここで、メモリには、本明細書で開示される機能群を実行することができる1つ以上のプログラムがエンコードされている。
【0017】
以下に記載される実施形態の概念は、ユーザ機器から初期リクエストでコンテンツダウンロードあるいはコンテンツアップロードのタイプを示すことで、メディアコンテンツのダウンロード及びアップロードの少なくとも一方に対するポリシーをセットアップする、例えば、適切な帯域幅を予約することである。
【0018】
更なる実施形態に従えば、コンテンツダウンロードあるいはコンテンツアップロードのタイプは、初期リクエスト内のトランスファー(転送)タイプ属性によって指示され、この属性は、初期リクエスト内に含まれるSDPオファー(SDP Offer:SDP提案)に含まれる。別の実施形態に従えば、帯域幅を提案する帯域幅属性は、オプションとして、初期リクエストに含まれる。
【0019】
このトランスファータイプ属性は、例えば、IMSとローカルトランスポートポリシーに、セッションが特定の要件でセットアップされるべきであることを示すものである。例えば、トランスファータイプ属性がストリーミングダウンロードを示していて、また、特定の帯域幅が帯域幅属性で示されている場合、ストリーミングダウンロードセッションが、帯域幅属性で示される帯域幅に従って、保証された帯域幅でセットアップされるべきである。つまり、帯域幅属性で示される帯域幅は、円滑な送信を行うために必要とされる期待最大帯域幅を示している。
【0020】
更なる実施形態に従えば、トランスポートタイプ属性とオプションで提案される帯域幅とを含むリクエストは、そのリクエスト内で指示されるトランスポートのタイプに対して要求される帯域幅がネットワークで利用可能でない場合には拒否されることになる。そうである場合、ユーザ機器は、次のリクエストで異なるトランスポートタイプ属性を含めることができる。
【0021】
IMSベースのIPTVソリューションにおいて、例示の実施形態に従えば、QoS(サービス品質)は、QoS(サービス品質)は、例えば、TISPAN RACS−アーキテクチャに従って定義されるように保証されても良い。リニアTV用及びビデオオンデマンド用に要求されるシグナリングは、例えば、TISPANー仕様書及びOITF(オープンIPTVフォーラム)仕様書で既定されている。
【0022】
例示の実施形態は、コンテンツのダウンロードとコンテンツのアップロードとの結び付けと、例えば、IMS/RACSによって提供される上述のQoSメカニズムを提供し、そうすることで、最小送信速度で、例えば、プログレッシブダウンロード、ストリーミングダウンロード、及びアダプティブストリーミングダウンロードのタイプのダウンロード中に、途切れのないメディアコンテンツの視聴をサポートすることを可能にすることを保証する。
【0023】
つまり、本発明の実施形態に従えば、上述のトランスファータイプ属性が、コンテンツダウンロード用のSDPオファーに含められ、そうすることで、コンテンツダウンロード用のポリシーを専用にセットアップする。この属性は、IMS/RACSにおけるローカルポリシーを制御すること、例えば、帯域幅を予約すること、あるいはアクセスネットワーク内の適切な優先度を選択することの柔軟性を実現する。RACSポリシーは、例えば、標準化SPDF(サービスベースのポリシー決定機能)に従ってセットアップされる。
【0024】
典型的には、HTTPコンテンツダウンロード用のトランスポートタイプは、エンドユーザの動作及びユーザ機器の構成設定(コンフィグレーション)に基づいて、ユーザ機器によって判定される。ユーザが視聴するコンテンツを選択し、かつユーザ機器がコンテンツを記憶するように構成設定されていない場合、コンテンツは、ユーザ機器の再生速度で、コンテンツのストリーミングダウンロードを使用してコンテンツサーバから取得されることになる。
【0025】
しかしながら、ユーザ機器がコンテンツを記憶するように構成設定される場合、コンテンツは、プログレッシブダウンロードを使用して、コンテンツサーバから取得されることになる。即ち、コンテンツはユーザ機器に記憶されるあるいはバッファされると同時に再生される。
【0026】
アダプティブストリーミングダウンロードでは、エンドユーザは、コンテンツがアダプティブストリームとして利用可能であるべきことをリクエストし、そうすることで、コンテンツを、特別なスキームに従って、異なるビットレートでダウンロードすることができる。例えば、ユーザ機器は、バッファが空きになることを検出する場合には、より高速なビットレートストリーム用の帯域幅の不足が存在し、かつより低速なダウンロードビットレートへのシフトが存在すると仮定することができる。
【0027】
上述のように、従来のHTTPコンテンツダウンロードは、ベストエフォート型の送信であり、ダウンロードの速度は利用可能な帯域幅に制限される。しかしながら、異なるタイプのコンテンツダウンロードとコンテンツアップロードとの差別化を図るために、トランスファータイプ属性が、本発明の実施形態に従って、ユーザ機器からの初期リクエストに含められる。
【0028】
異なるタイプのコンテンツダウンロードは、ベストエフォートQoSよりもわずかに高いQoSで差別化される。これは、ベストエフォートQoSは、最小送信要件を有さないからである。
【0029】
上述のように、上述の概念は、例えば、ユーザによって生成されるダウンロード用に適用することができるばかりか、アップロード用にも適用することができる。アップロードコンテンツは、ダウンロードを使用して、他のユーザと連続的に共有することができるので、一定の転送を要求することになる。
【0030】
図1aは、例示のIMS IPTVアーキテクチャと、IMS IPTVにおいて適用可能なプロトコル、即ち、SIP(セッション開始プロトコル)及びHTTP(ハイパーテキスト転送プロトコル)を示すブロック図であり、この適用可能なプロトコルは、コンテンツサーバからUEへメディアをダウンロードするためのもの、あるいはメディアコンテンツをコンテンツサーバへアップロードするためのものである。このアーキテクチャは、OITF対応(使用可能)UE1、IMSゲートウェイ2、図ではIMS/RACSの円3で示されているIMSメディアサーバあるいはビデオオンデマンドポンプ、IPTVコントローラ4、及びメディア制御機能(MCF)を備えるコンテンツサーバ5を備えている。IPTVコントローラ4は、例えば、オープンIPTVフォーラムで定義される、例えば、IPTVアプリケーションプラットホーム(IAP)を備えていても良い。
【0031】
図1bは、OITF対応ユーザ機器1を示すブロック図であり、これは、オープンIPTVフォーラム仕様書で定義される、宣言型アプリーケーション環境(DAE)用の機能と、ローカルオブジェクトコードを備え、DAEはUEのブラウザを備える。
【0032】
より具体的には、例示のUEによって指示されるユニキャストコンテンツダウンロードセッションでは、発信側のUEが初期INVITE−リクエストを生成する。リクエスト−URI(ユニフォームリソース識別子)は、ダウンロードコンテンツURIを、ユニキャストロケータ内と、TO−ヘッダ内に含める。この識別子はサービス選択情報から取得される。また、FROM−ヘッダは、ユーザのパブリックユーザアイデンティティを指示する。
【0033】
SDPオファーは、メディアケイパビリティと、コンテンツダウンロードセッション用に利用可能な要求される帯域幅に従って、INVITE(招待)リクエストに含められる。
【0034】
つまり、メディアレベルでの例示の典型的なSDPオファーは、例えば、以下の要素を含んでいても良い。
【0035】
− HTTPダウンロード用の「m=」ライン、例えば、以下のフォーマットの「m=」ライン:
m=<media><port><transport><fmt>
これは、「アプリケーション(application)」の値を有するメディアフィールドを有し、また、ディスカード(discard)ポートである9の値に設定されるポートフィールドを有し、更には、TCPに設定されるトランスポートフィールドを有する。また、fmt−パラメータが含められ、これは、iptv_httpに設定され、その結果、「m=アプリケーション 9 tcp iptv_http」となる。
【0036】
− 「a=setup」属性が「アクティブ(active)」に設定され、例えば、a=setup:activeとなる。
【0037】
− 「a=connection」属性が「new」として設定され、例えば、a=connection:newとなる。
【0038】
−「c=」ラインが、INに設定される値と、IP4あるいはIP6に設定されるアドレスタイプと、及び関連するHTTPチャネルのフローのIPアドレスを有するネットワークタイプに含められ、例えば、c=IN IP4 <IP_ADDRESS>となる。
【0039】
本発明の実施形態に従えば、SDPオファーの「b=」ラインは、オプションとして、提案される帯域幅を示す帯域幅属性を含んでいても良い。ユーザが、サービス選択手順中にこの特定のコンテンツ配信チャネルに対して要求される帯域幅をフェッチしている場合、メディアレベルでの帯域幅属性は、「b=」ラインでこの値が設定され、例えば、b=AS:15000となる。
【0040】
従って、コンテンツサーバのMCF(メディアコンテンツ機能)は、ITPVコントローラを介して、SDPオファーを受信することになり、これは、トランスファータイプー属性と、提案される帯域幅を示す帯域幅属性(「b=」ラインにおいて)を含んでいても良い。コンテンツサーバのMCFは、ダウンロードあるいはアップロード用のコンテンツを準備する際にIPTVコントローラをアシストすることになり、そして、受信するトランスファータイプ−属性をSDPアンサーにコピーし、これは、IPTVコントローラへ転送される。
【0041】
加えて、本発明の実施形態に従えば、例えば、「fmtp:iptv_http transfer−type(トランスファー(転送)タイプ)」属性のような、SDPオファーに含まれるトランスファータイプ−属性によって、上述のように、コンテンツダウンロードのタイプが、初期INVITE−リクエストで指示される。本発明の第1の実施形態に従えば、トランスファータイプ−属性に対して適用可能な値は、「プログレッシブ」、「ストリーミング」、及び「アダプティブ」となる。
【0042】
「プログレッシブ」コンテンツダウンロード−タイプは、ダウンロード中に視聴されるコンテンツを示していて、また、そのコンテンツはUEに記憶されるあるいはバッファされるので、比較的大きな帯域幅を要求する。
【0043】
「ストリーミング」コンテンツダウンロードタイプ、例えば、HTTPストリーミングは、記憶することなく、あるいはRSTPストリーミングと同様に、UEでのバッファリングが制限されて、視聴されるコンテンツを示している。
【0044】
「アダプティブ」コンテンツダウンロードタイプ、例えば、HTTPアダプティブストリーミングは、異なる帯域幅と異なる品質で視聴することができるコンテンツを示している。
【0045】
「b=」ラインは、オプションの帯域幅属性であり、そして、最高品質のストリーミング用の帯域幅を示している。
【0046】
更に例示の実施形態に従えば、トランスファー−タイプ属性の様々な他の値を、コンテンツダウンロードの他の所有タイプ、例えば、a=fmtp:iptv_http transfer−type=<transfer−type>を示すために使用することができる。
【0047】
図2aと図2bは、IMS IPTV−アーキテクチャにおけるクライアント端末として動作するユーザ機器1に対する例示のシグナリングシーケンスを示すシグナリング図を示している。この図は、本発明の実施形態に従えば、帯域幅予約を含む、コンテンツサーバ5からユーザ機器がダウンロードするメディアコンテンツを示している。この図は、また、介在する論理ユニットを示している。
【0048】
UE(OITF)−ボックス1は、OITF対応ユーザ機器を示していて、これは、オープンIPTVフォーラムで定義される宣誓型アプリケーション環境(DAE)用の機能を備え、更には、ローカルオブジェクトコード(LOC)を備えている。また、IG−box2はIMSゲートウェイに対応し、IMS/RACS−box3はIMSメディアサーバあるいはビデオオンデマンドポンプに対応し、また、IPTVコントローラ4はIPTVアプリケーションプラットホーム(IAP)を備えている。コンテンツサーバ5は、メディアコントローラ機能(MCF)を備える。
【0049】
図2aの信号S11では、UE1はダウンロードセッションを示していて、これは信号S12で作成される。信号S13では、SIP INVITEがIMSゲートウェイ2からIMSメディアサーバ3へ転送され、また、信号S15で、IPTVコントローラ4へ転送される。ここで、SIP INVITEはSDP(セッション記述プロトコル)オファーを含んでいる。そして、ステップ16で、IPTVコントローラ4とコンテンツサーバ5によって、コンテンツがダウンロード用に準備される。
【0050】
先行するステップ14では、IMS/RACSによってダウンロード用のポリシーがチェックされて、かつ適用され、そして、帯域幅予約が実行される。これには、SIP INVITEのSDPオファーで指示されるトランスポート−タイプによって要求される帯域幅が利用可能であるかを判定するために、アクセスネットワーク内のネットワークトポロジーがRACSによってチェックされることを含んでいる。利用可能である場合、帯域幅が予約され、信号S15で、SIP INVITEがIPTVコントローラへ転送されることになる。しかしながら、要求される帯域幅が利用可能でない場合、SIP INVITEは拒否されることになり、その結果、SIP INVITEはIPTVコントローラには転送されない。IPTVコントローラが拒否されてないSIP INVITEを受信する場合、コンテンツは、上述のステップ16において、ダウンロード用に用意されることになる。
【0051】
次に、信号S17において、IPTVコントローラは、SDPアンサーと、セッションに対するURLで応答することになる。これは、信号S19で、IMSゲートウェイに転送され、先行するステップ18において、帯域幅予約が確認される。その後、信号S20で、セッションが作成される。UEは、図2bの信号S21、S22及びS23で、コンテンツサーバ5から、コンテンツのダウンロード用に受信されるセッションURLを使用する。信号S24−S30で、ステップ26において、ダウンロードセッションが終了され、これにはネットワークリソースの解放(リリース)が含まれる。最終的には、信号S31とS32で、ダウンロードコンテンツが再生される。
【0052】
上述の図2aと2bは、ダウンロードセッションを示している。しかしながら、同様のシグナリング手順がアップロードセッションに対して使用されても良い。
【0053】
他の例示の実施形態は、他のプロトコルを使用する非IMSネットワーク内のプレーンIPTVに向けられているものであり、この他のプロトコルは、例えば、SIPに代わる、SOAP(シンプルオブジェクトアクセスプロトコル)あるいはDIAMETERプロトコルである。
【0054】
つまり、図2c及び図2dは、IMSゲートウェイを有さない代わりに、SOAPを使用し、そして、IPTVコントローラ4へのRACSインタフェース3を有するプレーンIPTVアーキテクチャ用の例示のシグナリング図を示している。図2cの信号S110で、UE1はダウンロードセッションを開始し、これは、信号S120で作成される。信号S130で、IPTVコントローラは、RACSインタフェースに対してSOAP予約帯域幅を発行する。予約が確認される場合、ステップ140において、信号S150で、SOAP応答がIPTVコントローラへ送信される。ステップ160において、信号S170で、IPTVコントローラはダウンロード用のコンテンツを準備して、そして、セッションが作成される。
【0055】
UEは、図2dの信号S180、S190及びS200で、コンテンツサーバ5から、コンテンツのダウンロード用として受信されるセッションURLを使用する。信号S210−S260で、ステップS230において、ダウンロードセッションが終了され、これにはネットワークリソースの解放(リリース)が含まれる。そして、最終的には、信号S270とS280で、ダウンロードコンテンツが再生される。
【0056】
図3は、本発明の実施形態に従う、メディアコンテンツのアップロードあるいはダウンロード用のポリシーをセットアップする、ユーザ機器のための方法を示すフロー図である。ステップ35において、UEは、コンテンツダウンロードあるいはコンテンツアップロードのタイプを示すリクエストを生成し、ステップ36において、そのリクエストをIPTVコントロールノードへ送信する。更なる実施形態に従えば、ポリシーは帯域幅予約であり、また、タイプは、初期リクエストのSDPオファー内に含まれるトランスポートタイプ−属性によって指示される。更なる実施形態に従えば、トランスファータイプ−属性は、上述のように、「プログレッシブ」、「ストリーミング」あるいは「アダプティブ」の値の内の1つを有している。図3のステップ35及びステップ36は、ダウンロードに向けられる場合には、基本的には、図2aの信号S11−S15に対応する。
【0057】
図4は、本発明の実施形態に従う、メディアコンテンツのアップロードあるいはダウンロード用のポリシーをセットアップする、IPTVコントロールノードのための方法を示すフロー図である。ステップ41において、IPTVコントロールノードは、UEからのリクエストを受信する。このリクエストは、コンテンツダウンロードあるいはコンテンツアップロードのタイプを示している。ステップ42において、IPTVコントロールノードは、コンテンツサーバのMCF(メディア制御機能)を介して、SDPアンサーにダウンロードあるいはアップロードのタイプをコピーする。更なる実施形態に従えば、ポリシーは帯域幅予約であり、これは、上述のステップ41においてUEから受信される初期リクエストのSDPオファーに含まれるトランスポートタイプ−属性によって指示される、コンテンツダウンロードあるいはコンテンツアップロードのタイプに基づいていて、期待送信速度に従ってセットアップされる。更なる実施形態に従えば、トランスファータイプ−属性の値は、例えば、プログレッシブ、ストリーミングあるいはアダプティブである。
【0058】
図5は、本発明の実施形態に従う、ユーザ機器1を示すブロック図である。UE1は、例えば、OITF対応移動電話、PC、あるいはTVであり、適切なユーザインタフェースを備えていて、また、これには、プロセッサ回路と適切なソフトウェア、例えば、IPTVフォーラムで定義される、宣言型アプリケーション環境(DAE)に対応するソフトウェアと、ローカルオブジェクトコードが提供される。このソフトウェアは、更に、本発明の実施形態に従う方法を実行するように構成されている。UEは、また、汎用通信デバイス51が提供され、これは、送信機、受信機及び処理回路52を備えることで、例えば、IMSゲートウェイとIMSメディアサーバを介して、IPTVコントローラと通信する。例示の実施形態に従えば、UEは、コンテンツダウンロード及びコンテンツアップロードの少なくとも一方のタイプを指示するSDPオファーを含むリクエストを生成し、そして、送信する。
【0059】
図6は、例示のITPVコントロールノード4を示すブロック図であり、これは、IPTVアプリケーションプラットホーム(IAP)を備えている。ITPVコントロールノードには、更に、通信デバイス61が提供され、これは、送信機、受信機及び処理回路62を備え、更には、通信デバイスと他の適切なハードウェア及びソフトウェアによって、IPTVコントロールノードは、例えば、SDPオファーに含まれるトランスファータイプ−属性で、UEからのコンテンツダウンロードあるいはコンテンツアップロードのタイプを示すリクエストを受信するように構成されている。更なる実施形態に従えば、通信デバイスは、コンテンツサーバに含まれるMCF(メディア制御機能)を介して、トランスファータイプ属性をSDPアンサーにコピーするように構成される。実施形態に従えば、ポリシーは帯域幅予約であり、IPTVコントロールノードは、受信されるトランスファータイプ−属性に基づいていて、期待送信速度に従う帯域幅を有するセッションをセットアップするように構成されている。
【0060】
図5及び図6を参照して上述されるエンティティ群及びユニット群は論理的なユニットであり、個別の物理ユニットに対応している必要はない。
【0061】
つまり、メディアコンテンツのダウンロードに向けられるユーザ機器に対する方法の実施形態に従えば、ユーザ機器1は、コンテンツダウンロード−タイプの指示を備えるリクエストを生成し、そのリクエストをIPTV−コントローラ4へ送信することによってサーバからIPTV−コンテンツをダウンロードするためのポリシーをセットアップする。
【0062】
例示の実施形態に従えば、ポリシーは帯域幅予約であり、そして、コンテンツダウンロード−タイプは、標準化トランスファータイプ−属性によって示される。これには、例えば、プログレッシブダウンロードを意味するプログレッシブ、ストリーミングダウンロードを意味するストリーミング、あるいはアダプティブストリーミングダウンロードがある。
【0063】
更なる例示の実施形態に従えば、IPTVはIMSベースであり、コンテンツダウンロードタイプの指示は、リクエストに含まれるSDPオファーに含まれる。また、SDPオファーは、提案される帯域幅を示す帯域幅属性を含んでも良い。
【0064】
更なる実施形態に従えば、ユーザ機器は、トランスポートタイプ−属性によって指示されるトランスポート−タイプに対して要求される帯域幅が利用可能でない場合、リクエストの拒否を受信することになり、そして、ユーザ機器は、拒否の受信時に、異なるトランスポートタイプ−属性を備えるリクエストを生成することができる。
【0065】
アップロードに向けられるユーザ機器に対する同様の方法の実施形態に従えば、ユーザ機器1は、コンテンツアップロード−タイプの指示を備えるリクエストを生成し、そして、そのリクエストをIPTV−コントローラ4へ送信することによって、IPTV−コンテンツをサーバへアップロードするためのポリシーをセットアップする。
【0066】
更なる例示の実施形態に従えば、ポリシーは帯域幅予約であり、これは、期待送信速度に従ってセットアップされ、また、コンテンツアップロード−タイプは、標準化トランスファータイプ−属性、例えば、「プログレッシブ」、「ストリーミング」あるいは「アダプティブ」によって指示される。これらの属性は、それぞれ、プログレッシブアップロード、ストリーミングアップロード、あるいはアダプティブストリーミングアップロードを示している。
【0067】
他の例示の実施形態に従えば、IPTVはIMSベースであり、コンテンツアップロード−タイプの指示は、リクエストに含まれるSDPオファーに含まれる。また、SDPオファーは、提案される帯域幅を示す帯域幅属性を含んでいても良い。
【0068】
また更なる実施形態に従えば、ユーザ機器は、トランスポートタイプ−属性によって指示されるトランスポート−タイプに対して要求される帯域幅が利用可能でない場合、リクエストの拒否を受信することになり、そして、ユーザ機器は、拒否の受信時に、異なるトランスポートタイプ−属性を備えるリクエストを生成することができる。
【0069】
ユーザ機器はIPTVコントロールノードと通信して、アップロード及びダウンロード用のポリシーをセットアップする。ダウンロードに向けられるIPTVコントロールノード4に対する方法の実施形態に従えば、IPTVコントロールノード4は、コンテンツサーバ5からユーザ機器1へIPTVコンテンツをダウンロードするためのポリシーをセットアップし、ここで、IPTVコントローラはユーザ機器からリクエストを受信し、そのリクエストは、コンテンツダウンロード−タイプの指示を含んでいる。
【0070】
更なる例示の実施形態に従えば、ポリシーは帯域幅予約であり、これは、コンテンツダウンロードのタイプの受信される指示に基づいていて、期待送信速度に従ってIPTVコントロールノード4によってセットアップされる。このコンテンツダウンロードタイプは、標準化トランスファータイプ−属性、例えば、「プログレッシブ」、「ストリーミング」あるいは「アダプティブ」によって示される。これらの属性は、それぞれ、プログレッシブアップロード、ストリーミングアップロード、あるいはアダプティブストリーミングアップロードを示している。
【0071】
更なる他の実施形態に従えば、IPTVはIMSベースであり、コンテンツダウンロードタイプの指示は、UEから受信されるリクエストに含まれるSDPオファーに含まれる。また、SDPオファーは、提案される帯域幅を示す帯域幅属性を備えていても良く、そして、コンテンツダウンロードタイプの指示はSDPアンサーにコピーされても良い。
【0072】
アップロードに向けられるIPTVコントロールノードのための方法の実施形態に従えば、IPTVコントロールノード4は、UE1からコンテンツサーバ5へIPTVコンテンツをアップロードするためのポリシーをセットアップし、ここで、IPTVコントローラはユーザ機器からリクエストを受信し、このリクエストはコンテンツアップロードタイプの指示を備えている。
【0073】
例示の実施形態に従えば、ポリシーは帯域幅予約であり、これは、コンテンツアップロードのタイプの受信される指示に基づいて、期待送信速度に従ってセットアップされる。このコンテンツアップロードタイプは、標準化トランスファータイプ−属性、例えば、「プログレッシブ」、「ストリーミング」あるいは「アダプティブ」によって示される。これらの属性は、それぞれ、プログレッシブアップロード、ストリーミングアップロード、あるいはアダプティブストリーミングアップロードを示している。
【0074】
更なる例示の実施形態に従えば、IPTVはIMSベースであり、コンテンツアップロードタイプの指示は、リクエストに含まれるSDPオファーに含まれる。また、SDPオファーは、提案される帯域幅を示す帯域幅属性を含み、また、コンテンツアップロードタイプの指示はSDPアンサーにコピーされる。
【0075】
ユーザ機器1の実施形態に従えば、UEは、コンテンツサーバ5からIPTV−コンテンツをダウンロードするためのポリシーをセットアップするように構成されていて、ユーザ機器は、処理回路62が提供される通信デバイス61を備え、また、コンテンツダウンロード−タイプの指示を備えるリクエストを生成し、そのリクエストをIPTV−コントロールノード4へ送信するように構成されている。
【0076】
加えて、ユーザ機器の実施形態に従えば、ユーザ機器1は、サーバ5へIPTV−コンテンツへアップロードするためのポリシーをセットアップするように構成されていて、ユーザ機器は、処理回路62が提供される通信デバイス61を備え、また、コンテンツアップロード−タイプの指示を備えるリクエストを生成し、そのリクエストをIPTV−コントロールノードへ送信するように構成されている。
【0077】
つまり、本発明に従うユーザ機器は、好ましくは、ダウンロードとアップロードの両方に対してポリシーをセットアップするように構成されるが、代替としては、ダウンロードあるいはアップロードに対するポリシーをセットアップするように構成されても良い。
【0078】
ユーザ機器の更なる例示の実施形態に従えば、ポリシーは帯域幅予約であり、コンテンツダウンロードタイプ及びコンテンツアップロードタイプの少なくとも一方は、標準化トランスファータイプ−属性、例えば、「プログレッシブ」、「ストリーミング」あるいは「アダプティブ」によって示され、これらの属性は、それぞれ、プログレッシブアップロード、ストリーミングアップロード、あるいはアダプティブストリーミングアップロードを示している。
【0079】
更なる例示の実施形態に従えば、IPTVはIMSベースであり、トランスファータイプ属性の指示は、リクエストに含まれるSDPオファーに含まれる。加えて、SDPオファーは、提案される帯域幅を備え、UEはOITF対応(使用可能)である。
【0080】
上述の例示の方法と同様に、ユーザ機器は、アップロード及びダウンロード用のポリシーをセットアップするためのIPTVコントロールノードと通信するように構成されている。IPTVコントロールノード4の実施形態に従えば、IPTVコントロールノード4は、コンテンツサーバ5からユーザ機器1へIPTV−コンテンツをダウンロードするためのポリシーをセットアップするように構成されていて、このIPTVコントロールノードは、処理回路52が提供される通信デバイス51を備え、そして、ユーザ機器からリクエストを受信するように構成されている。ここで、このリクエストは、コンテンツダウンロードタイプの指示を備える。
【0081】
加えて、IPTVコントロールノード4の実施形態に従えば、IPTVコントロールノードは、コンテンツサーバ5からユーザ機器1へIPTVコンテンツをアップロードするためのポリシーをセットアップするように構成され、このノードは、処理回路52が提供される通信デバイス51を備え、また、ユーザ機器からのリクエストを受信するように構成されている。ここで、このリクエストは、コンテンツアップロードタイプの指示を備える。
【0082】
別の例示の実施形態に従えば、ポリシーは帯域幅予約であり、また、IPTV対応コントロールノードは、コンテンツダウンロード及びコンテンツアップロードの少なくとも一方のタイプの受信される指示に基づいていて、期待送信速度に従って、帯域幅予約をセットアップするように構成される。このコンテンツアップロードタイプ及びコンテンツアップロードタイプの少なくとも一方は、標準化トランスファータイプ−属性、例えば、「プログレッシブ」、「ストリーミング」あるいは「アダプティブ」によって示される。これらの属性は、それぞれ、プログレッシブアップロード、ストリーミングアップロード、あるいはアダプティブストリーミングアップロードを示している。
【0083】
また更なる例示の実施形態に従えば、IPTVはIMSベースであり、トランスファータイプ属性は、リクエストに含まれるSDPオファーに含まれ、また、SDPオファーは、提案される帯域幅を備える。
【0084】
IPTVコントロールノードは、更に、コンテンツアップロードタイプ及びコンテンツダウンロードタイプの少なくとも一方の受信された指示を、コンテンツサーバのMCFを介してSDPアンサーにコピーされるように構成されていても良い。
【0085】
つまり、実施形態に従うIPTVコントロールノードは、好ましくは、ダウンロードとアップロードの両方に対するポリシーをセットアップするように構成されるが、選択的には、ダウンロードあるいはアップロードの一方に対するポリシーをセットアップするように構成されていても良い。
【0086】
図2c及び図2dとに記載されるように、例示の実施形態は、非IMSネットワーク、例えば、いわゆる、プレーンあるいは従来のIPTVに適用可能である。但し、非IMSネットワークの場合、SIPのような個別のプロトコルが、帯域幅を割り当てるための、かつ帯域幅の割当を解除するためのバックエンドを伴うセッションを作成するために要求され、これには、例えば、SOAPあるいはDIAMETERプロトコルがある。選択的には、新規のHTTPヘッダに、提案される帯域幅及び含められるトランスファータイプを伴って追加することができ、あるいは、情報を、任意の個別のプロトコルを要求することなく、HTTPリクエストURIにカプセル化することができる。
【0087】
また、上述のかつ記載の実施形態は例示としてのみ与えられ、本発明を制限するものとするべきではない。本願の特許請求の範囲の請求項で定義される発明の範囲内で、他のソリューション、用途、目的及び機能が、当業者にとって明らかであろう。
【0088】
略語
OITF=オープンIPTVフォーラム
SDP=セッション記述プロトコル
MCF=メディア制御機能
IAP=IPTVアプリケーションプラットホーム
RACS=リソース及び管理制御サブシステム
SPDF=サービスベースポリシー決定機能
DAE=宣言型アプリケーション環境
QoS=サービス品質
URI=ユニフォームリソース識別子
SOAP=シンプルオブジェクトアクセスプロトコル
HTTP=ハイパーテキストトランスファー(転送)プロトコル
SIP=セッション開始プロトコル
【特許請求の範囲】
【請求項1】
コンテンツサーバ(5)からIPTVコンテンツをダウンロードするためのポリシー、あるいはコンテンツサーバ(5)へIPTVコンテンツをアップロードするためのポリシーをセットアップするユーザ機器(1)の方法であって、
コンテンツダウンロードあるいはコンテンツアップロードのタイプの指示を有するリクエストを生成するステップ(31)と、
前記リクエストをIPTVコントロールノード(4)へ送信するステップ(32)と
を備えることを特徴とする方法。
【請求項2】
前記ポリシーは、帯域幅予約である
ことを特徴とする請求項1に記載の方法。
【請求項3】
前記コンテンツダウンロードあるいはコンテンツアップロードのタイプは、トランスファータイプ属性によって指示される
ことを特徴とする請求項1または2に記載の方法。
【請求項4】
前記トランスファータイプ属性は、プログレッシブ、ストリーミングあるいはアダプティブを示す値の1つを有する
ことを特徴とする請求項3に記載の方法。
【請求項5】
前記IPTVは、IMSベースであり、
トランスファータイプ属性が、前記リクエストに含まれるSDPオファーに含まれる
ことを特徴とする請求項1乃至4のいずれか1項に記載の方法。
【請求項6】
前記SDPオファーは、更に、提案される帯域幅を含んでいる
ことを特徴とする請求項5に記載の方法。
【請求項7】
トランスファータイプ属性によって要求される帯域幅が利用可能でない場合、前記ユーザ機器が、前記リクエストの拒否を受信するステップを更に備える
ことを特徴とする請求項2乃至6のいずれか1項に記載の方法。
【請求項8】
拒否が受信される場合に、異なるトランスファータイプ属性を含むリクエストを生成するステップを更に備える
ことを特徴とする請求項7に記載の方法。
【請求項9】
コンテンツサーバ(5)からユーザ機器(1)へIPTVコンテンツをダウンロードするための、あるいはユーザ機器(1)からコンテンツサーバ(5)へIPTVコンテンツをアップロードするための、ポリシーをセットアップするIPTVコントロールノード(4)のための方法であって、
前記ユーザ機器からのリクエストとして、コンテンツダウンロードあるいはコンテンツアップロードのタイプの指示を備えるリクエストを受信するステップ(41)を備える
ことを特徴とする方法。
【請求項10】
前記コンテンツダウンロードあるいはコンテンツアップロードのタイプは、トランスファータイプ属性によって指示される
ことを特徴とする請求項9に記載の方法。
【請求項11】
前記ポリシーは、前記コンテンツダウンロードあるいはコンテンツアップロードのタイプに基づく帯域幅予約であり、期待送信速度に従ってセットアップされる
ことを特徴とする請求項9または10に記載の方法。
【請求項12】
前記コンテンツサーバのMCF(メディア制御機能)を介して、前記リクエストに含まれるSDPオファーからのトランスファータイプ属性を、応答に含まれるSDPアンサーにコピーするステップを更に備える
ことを特徴とする請求項10または11に記載の方法。
【請求項13】
コンテンツサーバ(5)からIPTVコンテンツをダウンロードするためのポリシー、及びコンテンツサーバ(5)へIPTVコンテンツをアップロードするためのポリシーの少なくとも一方をセットアップするように構成されているユーザ機器(1)であって、
処理回路(52)が提供されている通信デバイス(51)を備え、
前記通信デバイスは、
コンテンツダウンロード及びコンテンツアップロードの少なくとも一方のタイプの指示を有するリクエストを生成し、
前記リクエストをIPTVコントロールノード(4)へ送信する
ように構成されている
ことを特徴とするユーザ機器。
【請求項14】
前記ポリシーは、帯域幅予約である
ことを特徴とする請求項13に記載のユーザ機器。
【請求項15】
前記コンテンツダウンロードあるいはコンテンツアップロードのタイプは、トランスファータイプ属性によって指示される
ことを特徴とする請求項13または14に記載のユーザ機器。
【請求項16】
前記トランスファータイプ属性は、プログレッシブ、ストリーミングあるいはアダプティブを示す値の1つを有する
ことを特徴とする請求項15に記載のユーザ機器。
【請求項17】
前記IPTVは、IMSベースであり、
前記トランスファータイプ属性は、前記リクエストに含まれるSDPオファーに含まれる
ことを特徴とする請求項15また16に記載のユーザ機器。
【請求項18】
前記SDPオファーは、更に、提案される帯域幅を含んでいる
ことを特徴とする請求項17に記載のユーザ機器。
【請求項19】
コンテンツサーバ(5)からユーザ機器(1)へIPTVコンテンツをダウンロードするための、及びユーザ機器(1)からコンテンツサーバ(5)へIPTVコンテンツをアップロードするための少なくとも一方のための、ポリシーをセットアップするように構成されているIPTVコントロールノード(4)であって、
処理回路(62)が提供されている通信デバイス(61)を備え、
前記通信デバイスは、
前記ユーザ機器からのリクエストとして、コンテンツダウンロード及びコンテンツアップロードの少なくとも一方のタイプの指示を備えるリクエストを受信する
ように構成されている
ことを特徴とするIPTVコントロールノード。
【請求項20】
前記コンテンツダウンロード及びコンテンツアップロードのタイプの少なくとも一方は、トランスファータイプ属性によって指示される
ことを特徴とする請求項19に記載のIPTVコントロールノード。
【請求項21】
前記ポリシーは、前記コンテンツダウンロードあるいはコンテンツアップロードのタイプに基づく帯域幅予約であり、期待送信速度に従ってセットアップされる
ことを特徴とする請求項19または20に記載のIPTVコントロールノード。
【請求項22】
前記コンテンツサーバ(5)のMCF(メディア制御機能)を介して、前記リクエストに含まれるSDPオファーからの前記トランスファータイプ属性を、応答に含まれるSDPアンサーにコピーするステップを更に備える
ことを特徴とする請求項20または21に記載のIPTVコントロールノード。
【請求項1】
コンテンツサーバ(5)からIPTVコンテンツをダウンロードするためのポリシー、あるいはコンテンツサーバ(5)へIPTVコンテンツをアップロードするためのポリシーをセットアップするユーザ機器(1)の方法であって、
コンテンツダウンロードあるいはコンテンツアップロードのタイプの指示を有するリクエストを生成するステップ(31)と、
前記リクエストをIPTVコントロールノード(4)へ送信するステップ(32)と
を備えることを特徴とする方法。
【請求項2】
前記ポリシーは、帯域幅予約である
ことを特徴とする請求項1に記載の方法。
【請求項3】
前記コンテンツダウンロードあるいはコンテンツアップロードのタイプは、トランスファータイプ属性によって指示される
ことを特徴とする請求項1または2に記載の方法。
【請求項4】
前記トランスファータイプ属性は、プログレッシブ、ストリーミングあるいはアダプティブを示す値の1つを有する
ことを特徴とする請求項3に記載の方法。
【請求項5】
前記IPTVは、IMSベースであり、
トランスファータイプ属性が、前記リクエストに含まれるSDPオファーに含まれる
ことを特徴とする請求項1乃至4のいずれか1項に記載の方法。
【請求項6】
前記SDPオファーは、更に、提案される帯域幅を含んでいる
ことを特徴とする請求項5に記載の方法。
【請求項7】
トランスファータイプ属性によって要求される帯域幅が利用可能でない場合、前記ユーザ機器が、前記リクエストの拒否を受信するステップを更に備える
ことを特徴とする請求項2乃至6のいずれか1項に記載の方法。
【請求項8】
拒否が受信される場合に、異なるトランスファータイプ属性を含むリクエストを生成するステップを更に備える
ことを特徴とする請求項7に記載の方法。
【請求項9】
コンテンツサーバ(5)からユーザ機器(1)へIPTVコンテンツをダウンロードするための、あるいはユーザ機器(1)からコンテンツサーバ(5)へIPTVコンテンツをアップロードするための、ポリシーをセットアップするIPTVコントロールノード(4)のための方法であって、
前記ユーザ機器からのリクエストとして、コンテンツダウンロードあるいはコンテンツアップロードのタイプの指示を備えるリクエストを受信するステップ(41)を備える
ことを特徴とする方法。
【請求項10】
前記コンテンツダウンロードあるいはコンテンツアップロードのタイプは、トランスファータイプ属性によって指示される
ことを特徴とする請求項9に記載の方法。
【請求項11】
前記ポリシーは、前記コンテンツダウンロードあるいはコンテンツアップロードのタイプに基づく帯域幅予約であり、期待送信速度に従ってセットアップされる
ことを特徴とする請求項9または10に記載の方法。
【請求項12】
前記コンテンツサーバのMCF(メディア制御機能)を介して、前記リクエストに含まれるSDPオファーからのトランスファータイプ属性を、応答に含まれるSDPアンサーにコピーするステップを更に備える
ことを特徴とする請求項10または11に記載の方法。
【請求項13】
コンテンツサーバ(5)からIPTVコンテンツをダウンロードするためのポリシー、及びコンテンツサーバ(5)へIPTVコンテンツをアップロードするためのポリシーの少なくとも一方をセットアップするように構成されているユーザ機器(1)であって、
処理回路(52)が提供されている通信デバイス(51)を備え、
前記通信デバイスは、
コンテンツダウンロード及びコンテンツアップロードの少なくとも一方のタイプの指示を有するリクエストを生成し、
前記リクエストをIPTVコントロールノード(4)へ送信する
ように構成されている
ことを特徴とするユーザ機器。
【請求項14】
前記ポリシーは、帯域幅予約である
ことを特徴とする請求項13に記載のユーザ機器。
【請求項15】
前記コンテンツダウンロードあるいはコンテンツアップロードのタイプは、トランスファータイプ属性によって指示される
ことを特徴とする請求項13または14に記載のユーザ機器。
【請求項16】
前記トランスファータイプ属性は、プログレッシブ、ストリーミングあるいはアダプティブを示す値の1つを有する
ことを特徴とする請求項15に記載のユーザ機器。
【請求項17】
前記IPTVは、IMSベースであり、
前記トランスファータイプ属性は、前記リクエストに含まれるSDPオファーに含まれる
ことを特徴とする請求項15また16に記載のユーザ機器。
【請求項18】
前記SDPオファーは、更に、提案される帯域幅を含んでいる
ことを特徴とする請求項17に記載のユーザ機器。
【請求項19】
コンテンツサーバ(5)からユーザ機器(1)へIPTVコンテンツをダウンロードするための、及びユーザ機器(1)からコンテンツサーバ(5)へIPTVコンテンツをアップロードするための少なくとも一方のための、ポリシーをセットアップするように構成されているIPTVコントロールノード(4)であって、
処理回路(62)が提供されている通信デバイス(61)を備え、
前記通信デバイスは、
前記ユーザ機器からのリクエストとして、コンテンツダウンロード及びコンテンツアップロードの少なくとも一方のタイプの指示を備えるリクエストを受信する
ように構成されている
ことを特徴とするIPTVコントロールノード。
【請求項20】
前記コンテンツダウンロード及びコンテンツアップロードのタイプの少なくとも一方は、トランスファータイプ属性によって指示される
ことを特徴とする請求項19に記載のIPTVコントロールノード。
【請求項21】
前記ポリシーは、前記コンテンツダウンロードあるいはコンテンツアップロードのタイプに基づく帯域幅予約であり、期待送信速度に従ってセットアップされる
ことを特徴とする請求項19または20に記載のIPTVコントロールノード。
【請求項22】
前記コンテンツサーバ(5)のMCF(メディア制御機能)を介して、前記リクエストに含まれるSDPオファーからの前記トランスファータイプ属性を、応答に含まれるSDPアンサーにコピーするステップを更に備える
ことを特徴とする請求項20または21に記載のIPTVコントロールノード。
【図1a】
【図1b】
【図2a】
【図2b】
【図2c】
【図2d】
【図3】
【図4】
【図5】
【図6】
【図1b】
【図2a】
【図2b】
【図2c】
【図2d】
【図3】
【図4】
【図5】
【図6】
【公表番号】特表2013−513992(P2013−513992A)
【公表日】平成25年4月22日(2013.4.22)
【国際特許分類】
【出願番号】特願2012−543049(P2012−543049)
【出願日】平成22年11月30日(2010.11.30)
【国際出願番号】PCT/SE2010/051317
【国際公開番号】WO2011/071439
【国際公開日】平成23年6月16日(2011.6.16)
【公序良俗違反の表示】
(特許庁注:以下のものは登録商標)
1.YouTube
【出願人】(598036300)テレフオンアクチーボラゲット エル エム エリクソン(パブル) (2,266)
【Fターム(参考)】
【公表日】平成25年4月22日(2013.4.22)
【国際特許分類】
【出願日】平成22年11月30日(2010.11.30)
【国際出願番号】PCT/SE2010/051317
【国際公開番号】WO2011/071439
【国際公開日】平成23年6月16日(2011.6.16)
【公序良俗違反の表示】
(特許庁注:以下のものは登録商標)
1.YouTube
【出願人】(598036300)テレフオンアクチーボラゲット エル エム エリクソン(パブル) (2,266)
【Fターム(参考)】
[ Back to top ]