JP4862052B2 - ストリーミングメディアネットワークシステム、ストリーミングメディアサービス実現方法、およびストリーミングメディアサービスイネーブラ - Google Patents

Description

発明の詳細な説明

本出願は、２００６年２月１８日に、同一出願人によって出願された中国特許出願第２００６１００３３７６７号.Ｘ、「ＩＭＳベースのストリーミングメディアネットワークシステム」に対して優先権を主張するものであり、参照によりその内容は本明細書に含まれている。

〔本発明の分野〕
本発明は、ストリーミングメディア技術に関し、特にＩＭＳベースのストリーミングメディアサービスを実現する技術に関する。

〔背景〕
ストリーミングメディアサービスは、近年急速に発展した新しいサービスであり、映像および音声データなどのマルチメディアコンテンツデータを、ストリーミング送信技術を用いてパケット交換網に送信するサービスである。ストリーミング送信技術の主な特徴は、連続した映像および音声データが処理後にウェブサイトのサーバに置かれ、これによってユーザは、使用するユーザ端末にファイル全体がダウンロードされた後ではなく、ダウンロードされている最中に視聴することができる点である。

インターネットプロトコルテレビ（ＩＰＴＶ）サービスは、ストリーミング分野における典型的なサービスである。図１に示すように、現在のＩＰＴＶネットワークアーキテクチャは、主に以下を含んでいる：
課金、認証、コンテンツ管理、およびデジタル著作権管理などの機能を提供する動作サポートシステム。

コンテンツコーディング／デコーディング変換、圧縮、暗号化などの前処理、ユーザのサービス管理、電子番組ガイドの生成およびダウンロード、並びに、ビデオオンデマンド（Video on Demand; ＶＯＤ）、テレビ（Television; ＴＶ）、および広告などのネットワークポータルおよびアプリケーション機能を提供するサービスアプリケーション層。

コンテンツ／メディア配信ネットワークは、セントラルメディアサーバ（ＣＳ）、エッジメディアサーバ（ＥＳ）、およびメディアのスケジューリングおよび配信制御を行うサーバを含んでいる。コンテンツ／メディア配信ネットワークは、ネットワーク上におけるストリーミングメディアサービスの負荷を緩和するために、コンテンツリソースを、ユーザによって必要とされるエッジメディアサーバへ配信するように構成されている。

転送層は、ストリーミングメディアサービスフローを転送し、マルチキャスティングへのサポートを要求し、そしてサービス品質（quality of service; ＱｏＳ）保証を提供するように構成されている。

図１に示すＩＰＴＶネットワークアーキテクチャは、ストリーミングメディアサービスを実現することができる。しかしこのアーキテクチャは、独立したサービスシステムであり、他のサービスネットワークとサポートシステム（例えばユーザ管理、認証、および課金）を共有することができないため、キャリアの運用コストが増加する。

ＩＰマルチメディアアプリケーションに対する需要が増すので、それに対応するために、第３世代パートナーシッププロジェクト（3rd Generation Partnership Project; ３ＧＰＰ）は、パケット転送ネットワークに基づいた純粋なＩＰサービスネットワークアーキテクチャのＩＰマルチメディアサブシステム（IP Multimedia Subsystem; ＩＭＳ）を導入する。ＩＭＳは、上位層制御シグナリングおよびメディア送信のための転送チャネルとしてパケット領域を用い、サービス制御プロトコルとしてセッション開始プロトコル（session initiation protocol; ＳＩＰ）を導入し、ＳＩＰの単純性・拡張の容易性・メディア結合の利便性を利用し、またサービス制御と転送制御とを分離することによって、リッチなマルチメディアサービスを提供する。

図２に示すように、ＩＭＳネットワークアーキテクチャは、Ｐ／I／Ｓ−ＣＳＣＦ、すなわち、ＩＭＳネットワークアーキテクチャの関連機能（例えば、加入者ブローカー、セッション制御、ルーティング、サービスのトリガ、および、異なるＩＭＳ領域間における通信）を提供する呼び出しステータス制御機能エンティティと、ＭＧＣＦ／Ｔ−ＭＧＦ、すなわち、ＩＭＳネットワークアーキテクチャ内のユーザと従来の公衆交換電話網（Public Switching Telephone Network; ＰＳＴＮ）内のユーザとの通信を行うメディアゲートウェイ制御機能、メディアゲートウェイ機能、およびシグナリングゲートウェイ機能と、互いに異なる複数のＩＭＳ領域のＭＧＣＦ間をアドレスおよびルーティングするブレークアウトゲートウェイ制御機能（ＢＧＣＦ）と、複数のユーザプロファイルサーバ機能（user profile server function; ＵＰＳＦ）の中から選択するＳＬＦと、ＩＭＳ領域間における通信用の機能エンティティとしてのＩＢＣＦおよびＩ−ＢＧＦと、ＭＲＦ、すなわち、メディアリソース機能コントローラ（ＭＲＦＣ）およびメディアリソース機能プロセッサ（ＭＲＦＰ）などのメディアリソースに対し、割り当て、制御、処理を行うメディアリソース機能と、ユーザに対してアクセス認証およびアドレス割り当てを行うネットワーク接続サブシステムと、ＩＭＳなどのサービス層の要求に従って転送ネットワークを制御するリソースアクセス制御システムとを含んでいる。

ＩＭＳネットワークアーキテクチャは、ユーザ管理、認証、および課金サブシステムなどのサポートシステムを、他のサービスネットワークと共有することができる。しかし、現在のＩＭＳネットワークアーキテクチャは、セッションサービスを効果的にサポートすることができるのみで、コンテンツ管理、コンテンツ保護、および電子番組ガイド配送などのストリーミングメディアサービスを実施するために必要な機能を有していないため、ストリーミングメディアサービスをサポートすることができない。

〔概要〕
本発明の実施形態は、ＩＭＳベースのストリーミングメディアネットワークシステム、ストリーミングメディアサービス実現方法、および、ＩＭＳネットワークアーキテクチャに基づいてストリーミングメディアサービスを実現する際の問題に対処するためのストリーミングメディアサービスイネーブラを提供することを目的としている。

上記目的を達成するために、本発明の実施形態は、ストリーミングメディアサービス記述情報をユーザ端末へ供給するストリーミングメディアサービスイネーブラと、当該ストリーミングメディアサービスイネーブラによって供給された上記サービス記述情報に基づいて上記ユーザ端末がストリーミングメディアサービスを選択した後および上記ユーザ端末から送られたストリーミングメディアサービス要求を受信した後に、メディアリソース要求を送信するように構成されており、且つ、メディアリソース配送処理機能エンティティに関する情報を取得した後、ストリーミングメディアコンテンツを記憶するメディアリソース配送処理機能エンティティに関する情報を上記ユーザ端末に供給するアプリケーションサーバと、上記ストリーミングメディアコンテンツを記憶する上記メディアリソース配送処理機能エンティティに関する上記情報を、上記アプリケーションサーバから送られた上記メディアリソース要求に基づいて、上記アプリケーションサーバに供給するメディアサーバとを含んでいる、ＩＭＳベースのストリーミングメディアネットワークシステムを提供する。

本発明の実施形態はさらに、事前設定されたサービス記述情報を記憶するように、またはサービス記述情報を取得するサービス記述情報記憶または取得ユニットと、上記サービス記述情報をユーザ端末へ供給するサービス記述情報供給ユニットとを備えた、ＩＭＳベースのストリーミングメディアサービスイネーブラを提供する。

本発明の実施形態はさらに、ストリーミングメディアサービスイネーブラが、ストリーミングメディアサービス記述情報をユーザ端末へ供給する工程と、当該サービス記述情報に基づいて、上記ユーザ端末が、ストリーミングメディアサービスを１つ選択する工程と、上記アプリケーションサーバが上記ユーザ端末から上記ストリーミングメディアサービス要求を受信した後に、メディアリソース要求を送信する工程と、メディアサーバが、ストリーミングメディアコンテンツを記憶するメディアリソース配送処理機能エンティティに関する情報を、上記メディアリソース要求に基づいて上記アプリケーションサーバへ供給する工程と、上記アプリケーションサーバが、上記メディアリソース配送処理機能エンティティに関する上記情報を、上記ユーザ端末へ供給する工程とを含んでいる、ＩＭＳベースのストリーミングメディアサービス実現方法を提供する。

本発明の実施形態では、上記ストリーミングメディアサービスイネーブラは、ユーザ端末へサービス記述情報を提供することができる。当該ユーザ端末は、当該サービス記述情報に従ってストリーミングメディアサービスを１つ選択するとともに上記アプリケーションサーバへストリーミングメディアサービス要求を送信する。上記アプリケーションサーバは、１つのメディアサーバに関する情報を上記ユーザ端末へ供給する。上記ユーザ端末は、上記メディアサーバに関する情報を用いてストリーミングメディアコンテンツを取得する。これによって、ＩＭＳベースのネットワークアーキテクチャに基づいて、ストリーミングメディアサービスを実現する上記目的が達成される。

〔詳細な説明〕
本発明の実施形態について、添付図面を参照しながら以下に詳述する。

本発明の実施形態では、ＳＩＰの単純性、拡張の容易性、およびメディア結合の利便性を利用して、既存のＩＭＳネットワークシステムに少なくとも１つの機能エンティティを加えて、ストリーミングメディアを制御する。図３に示すように、本発明の一実施形態に係るＩＭＳネットワークシステムは、Ｐ／Ｓ／Ｉ−ＣＳＣＦ（プロキシ／サービス／問い合わせ−コールセッション制御機能）、ＭＲＦ（メディアリソース機能）、およびＡＳ（アプリケーションサーバ）を含んでいる。ネットワークシステムに加えられる機能エンティティは、ＭＲＬＦ／ＭＲＢＦ（メディアリソース位置指定機能／メディアリソースブローカー機能）、ＳＧＦ（サービスガイド機能）エンティティ、ＣＭＦ（コンテンツ管理機能）エンティティ、ＫＭＦ（鍵管理機能）エンティティ、およびＲＩＦ（権利発行機能）エンティティを含んでいる。

上述の機能エンティティおよび上述の機能エンティティ間のインターフェースについて、以下に説明する。

Ｐ／Ｓ／Ｉ−ＣＳＣＦは、セッション制御、ルーティング、およびサービストリガなどの関連機能を提供し、他の機能エンティティは、認証、課金、ＱｏＳ、およびセキュリティーなどの関連サポート機能を提供する。これらの機能エンティティはＡＳと協働するが、前者はサービスをサポートし、後者はサービスを提供するものである。マルチメディア呼び出し音サービスを例に取ると、ＡＳは、ユーザが申し込んだマルチメディア呼び出し音はどの曲であるのか、その曲がどのように再生されるのか等を処理する。ＡＳおよびＰ／Ｓ／Ｉ−ＣＳＣＦ以外のエンティティは、ユーザ認証（例えば、そのユーザが正規のユーザであるか否か）、ユーザセッションの確立（すなわち、ダイアルアップ）等を処理する。さらに、ＭＲＬＦ／ＭＲＢＦは、申し込んだマルチメディア呼び出し音の曲が記憶されている位置、および、ユーザに最も近いＭＲＦを探す方法を処理する。ＭＲＦは、ユーザに対して曲を再生する。

ＭＲＦは、ストリーミングメディアネットワーク内においてメディアサーバの機能を提供するものであり、ＭＲＦＣおよびＭＲＦＰを含んでいる。ＭＲＦがネットワーク内のどの位置に配置されるのかに応じて、セントラルメディアサーバまたはエッジメディアサーバが、実際のメディアコンテンツ供給のために選択される。一般的に、ユーザにメディアコンテンツを提供するためには、そのユーザに最も近いエッジメディアサーバが用いられる。しかしエッジメディアサーバが、ユーザが要求するメディアコンテンツを有していない場合、ユーザが要求するメディアコンテンツは、まずセントラルメディアサーバからエッジメディアサーバへ供給され、当該エッジメディアサーバがユーザにメディアコンテンツを提供する。もしユーザが、同じメディアコンテンツを再度要求した場合は、エッジメディアサーバから当該メディアコンテンツをユーザに直接提供することができる。

ＡＳは、ネットワークシステム内の他の機能エンティティによるサポートのもと、ストリーミングメディアサービスに対して論理制御を行う。具体的には、ＩＭＳの確立されたセッション制御機構に基づいて、ストリーミングメディアセッションを確立してもよいし、あるいは、ＡＳにおいてそれぞれ異なるサービス論理を処理することによって、統合リアルタイムセッションサービスおよびストリーミングメディアサービスなどのリッチなサービスを提供してもよい。

ＭＲＬＦ／ＭＲＢＦ、ＳＧＦ、ＣＭＦ、ＫＭＦ、およびＲＩＦは、著作権管理、コンテンツ情報管理、電子番組ガイド作成、およびストリーミングメディアサービス加入などのストリーミングメディア、あるいはＩＰＴＶネットワーク特殊機能を提供する。

ＭＲＬＦ／ＭＲＢＦは、このＩＭＳ領域内またはネットワーク全体におけるメディアリソース配信情報およびＭＲＦステータス情報の収集、検索、位置指定、および配信など、メディアリソース処理機能を提供し、またＣＭＦおよびＭＲＦと共にコンテンツ配信ネットワーク（ＣＤＮ）の機能を提供することができる。ＭＲＬＦ／ＭＲＢＦは、ストリーミングメディアサービスにおいて必要とされるメディアリソース配信またはスケジューリング機能を提供することができる。ＭＲＬＦ／ＭＲＢＦはまた、音声および映像ファイルの位置指定、並びにＭＲＦの検索あるいは配信などの非ストリーミングメディアサービスに対しても、同一のサービスを提供することができる。ＣＤＮは、ストリーミングメディアサービスの重要な補助機能である。例えば、大規模なストリーミングメディアネットワークにおいては、数十万のユーザが中央のストリーミングメディアサーバに同時に要求を出した場合、ネットワーク帯域幅は耐えることができない。このため、プログラムコンテンツを配置する際には、人気のあるプログラムコンテンツを、ユーザの近辺にあるエッジメディアサーバ（例えば深川）に事前に配信しておくか、あるいは、まずセントラルメディアサーバ（例えば北京）を介してユーザの近辺にあるエッジメディアサーバへ配信し、その後でエッジメディアサーバが当該人気のあるプログラムコンテンツをユーザへ配信する必要がある。ユーザは、同一のプログラムコンテンツを再度要求した場合は、そのプログラムコンテンツをエッジメディアサーバから直接取得することができる。

具体的には、ＭＲＬＦ／ＭＲＢＦは、以下の機能を提供することができる：
リソース配信情報およびＭＲＦステータス情報を収集する。当該ＭＲＦステータス情報は、負荷状態などの情報であってよい。

ＡＳ／Ｓ−ＣＳＣＦからの要求メッセージ、リソース配信情報、およびＭＲＦステータス情報に基づいて適切なＭＲＦを選択し、当該選択結果をＳ−ＣＳＣＦ／ＡＳへ戻す。上記ＡＳ／Ｓ−ＣＳＣＦからの要求メッセージは、メディアコンテンツ、ユーザの位置、ＱｏＳなどの情報を含んでいてもよい。また、Ｓ−ＣＳＣＦ／ＡＳへ選択結果を戻す上記機能は、ＭＲＬＦ特有の機能である。

ＡＳ／Ｓ−ＣＳＣＦからＭＲＦへのメディアリソース要求メッセージのルーティングを行いルーティングポリシーに従って、ＡＳ／Ｓ−ＣＳＣＦとＭＲＦとの間におけるその後のメッセージのやりとりから抜ける。ＡＳ／Ｓ−ＣＳＣＦとＭＲＦとの間におけるその後のメッセージのやりとりに参加するか否かの決定は、ＭＲＢＦ特有の機能である。

図３では、ＭＲＬＦ／ＭＲＢＦは、ＡＳに接続することができ、またＳ−ＣＳＣＦに接続することができる。ＭＲＬＦ／ＭＲＢＦはさらに、いずれか一方であってもよい。すなわち、ＭＲＬＦ／ＭＲＢＦは、ＭＲＬＦまたはＭＲＢＦのいずれかであってもよい。ＭＲＬＦである場合は、ＭＲＬＦとＡＳ／Ｓ−ＣＳＣＦとの間のインターフェースは、クエリインターフェースであり、当該クエリインターフェースを介してＭＲＦの選択結果がＡＳ／Ｓ−ＣＳＣＦへ戻される。また、ＭＲＢＦである場合は、ＭＲＢＦとＡＳ／Ｓ−ＣＳＣＦとの間のインターフェースは、メディアリソース要求メッセージインターフェースである。ＭＲＢＦは、選択されたＭＲＦへメディアリソース要求メッセージをルーティングし、それと同時に、ＡＳ／Ｓ−ＣＳＣＦとＭＲＦとの後のメッセージ双方向通信に参加するか否かを決定することができる。ＭＲＢＦは、メディアリソース要求メッセージをルーティングする際に、メディアリソース要求メッセージのＲｅｃｏｒｄ−ＲｏｕｔｅまたはＲｏｕｔｅヘッダ領域に自身のＵＲＩを組み込まない場合は、後のメッセージのやりとりには参加しない。

ＳＧＦは、キャリアの業務運用サポートシステム（business operation support system; ＢＯＳＳ）またはその他のサポートシステムからサービス記述情報を取得し、そしてＣＭＦからコンテンツメタ情報を取得する。これと同時に、ＳＧＦはまた、ＵＰＳＦからユーザプロファイル情報を取得し、当該情報に従って電子番組ガイドを作成する。上記サービス記述情報は、映画の視聴およびゲームのプレーなどのストリーミングメディアサービスを記述した情報である。上記コンテンツメタ情報は、映画の名前およびコンテンツなどのコンテンツ情報を記述した情報である。

ＣＭＦは、以下の機能を提供することができる：
フロントエンドと双方向通信して、メディアコンテンツ管理機能を実行し、コンテンツメタ情報を生成および管理する。

ＫＭＦと双方向通信して、メディアコンテンツの保護機能を実行する。当該保護機能は、コンテンツ暗号鍵の保存および取得を含んでいてもよい。

キャリアの配信設定およびポリシー情報に従ってＭＲＦ／コンテンツシステム（content system; ＣＳ）と双方向通信して、メディアリソースの配信を行う。元のコンテンツプロバイダによって供給されたコンテンツソースは、フロントエンドによって処理された後にＣＳ内に記憶される。そして、キャリアによって設定された配信ポリシーおよび後のプロセスにおいて収集される情報に従って、コンテンツがＣＳを介してＭＲＦへ配信される。上記コンテンツソースは、ＩＰＴＶコンテンツプロバイダによって供給された、ストリーミングメディアおよび映画ソースまたはテレビ番組であってよい。

ＣＭＦはまた、ＭＲＬＦ／ＭＲＢＦ／ＭＲＦＣなどの機能エンティティから、メディアサーバのメディアリソース情報（例えば、メディアリソースの配信情報）、および／または、メディアサーバの負荷情報を取得することができる。ＣＭＦはまた、これらのメディアリソース情報を他の機能エンティティ（例えばＡＳ）へ供給し、他の機能エンティティ（例えばＡＳ）がメディアリソース情報を問い合わせることを可能にする。

ＫＭＦは、以下の機能を提供することができる：
ＣＭＦと双方向通信して、プログラム識別子（ＩＤ）、および対応する暗号鍵を記憶する。コンテンツが暗号化によって保護されている場合、ＣＭＦは、ＫＭＦに鍵を供給し、ＫＭＦは、それらの鍵とコンテンツとの対応関係を記憶する。

ＣＭＦと双方向通信して、コンテンツ保護鍵を生成し、当該コンテンツ保護鍵をＣＭＦへ戻し、そして当該鍵とコンテンツとの対応関係を記憶する。コンテンツが暗号化されていない場合、ＣＭＦは、ＫＭＦからコンテンツ暗号鍵を要求する。そして、ＫＭＦは、鍵を割り当てるとともにＣＭＦへ返却する。これと同時に、ＫＭＦは、プログラム識別子と暗号鍵との対応関係を記憶する。

ＫＭＦはまた、プログラム識別子および鍵に関する情報をＲＩＦへ供給する。

ＲＩＦは、以下の機能を提供することができる。

ＵＰＳＦと双方向通信して、ユーザのプロファイルサービスおよび権限情報を取得する。また、ＫＭＦと双方向通信して、ユーザが要求したメディアコンテンツの鍵情報を取得し、そして上記情報に従ってユーザの権利オブジェクトを生成する。

ユーザからの要求を受信し、ユーザの権利オブジェクトを戻す。当該ユーザは、ＩＭＳ内に構成されたユーザ装置（user equipment; ＵＥ）であってよく、また、セットトップボックス（set top box; ＳＴＢ）およびパーソナルコンピュータ（personal computer; ＰＣ）など他のユーザ端末であってもよい。ユーザとＲＩＦとの間のインターフェースは、インターフェースＩ１であってよく、プロトコルは、権利オブジェクト取得プロトコル（ＲＯＡＰ）であってもよい。

ＫＭＦと協働して、ストリーミングメディアまたはＩＰＴＶ内の特定のデジタル著作権管理（ＤＲＭ）モジュールの機能を行う。ＫＭＦは、ＲＩＦエンティティ内に組み込まれ、１つの機能エンティティとして統合されていてもよい。

ＣＭＦおよびＳＧＦは、互いに協働して、コンテンツソースによって送信された情報を管理し、そして電子番組ガイドを生成できることに留意されたい。

また、ＳＧＦ、ＫＭＦ、ＣＭＦ、およびＲＩＦは、メディアコンテンツにコーディング変換およびデコーディング変換、圧縮、および暗号化などの処理を行うストリーミングメディアサービスイネーブラであってよいことにも留意されたい。

図３に示すインターフェースについて、以下に説明する。

インターフェースＩ１は、ユーザ端末とＲＩＦとの間における双方向通信インターフェースである。ユーザ端末は、当該インターフェースを介して権利オブジェクトを取得することができる。当該インターフェースのプロトコルは、ＲＯＡＰであってもよい。

インターフェースＩ２は、ユーザ端末とＳＧＦとの間における双方向通信インターフェースである。ユーザ端末は、当該インターフェースを介して、電子番組ガイドを要求して、番組を申し込むことができる。当該インターフェースのプロトコルは、ＨＴＴＰであってよい。

インターフェースＩ３は、ＳＧＦとＵＰＳＦとの間における双方向通信インターフェースである。ＳＧＦは、当該インターフェースを介して、プロファイルサービスおよびユーザの権限情報をＵＰＳＦに要求することができ、また、ユーザが申し込んだプログラム情報をＵＰＳＦ内に記憶することができる。当該インターフェースのプロトコルは、ダイアメータプロトコル（Diamter protocol）であってよく、当該ダイアメータプロトコルは、次世代ＡＡＡプロトコルである。

インターフェースＩ４は、ＡＳ／Ｓ−ＣＳＣＦとＭＲＬＦ／ＭＲＢＦとの間における双方向通信インターフェースである。ＡＳ／Ｓ−ＣＳＣＦは、当該インターフェースを介して、ＭＲＬＦに適切なＭＲＦを要求することができ、また、ＭＲＢＦにメディアリソースを要求することができる。ＡＳ／Ｓ−ＣＳＣＦとＭＲＬＦとの間におけるプロトコルは、ダイアメータプロトコルであってよく、ＡＳ／Ｓ−ＣＳＣＦとＭＲＢＦとの間のプロトコルは、ＳＩＰであってよい。

インターフェースＩ５は、ＭＲＬＦ／ＭＲＢＦとＭＲＦＣとの間における双方向通信インターフェースである。ＭＲＬＦ／ＭＲＢＦは、当該インターフェースを介して、メディアリソース配信情報およびＭＲＦＰステータス情報をＭＲＦＣと交換することができ、この情報の交換によって適切なＭＲＦを選択することができる。

インターフェースＩ６は、ＣＭＦとＫＭＦとの間における双方向通信インターフェースである。当該インターフェースを介して、ＣＭＦとＫＭＦとの間において、コンテンツ保護情報が交換される。

インターフェースＩ７は、ＲＩＦとＫＭＦとの間における双方向通信インターフェースである。ＲＩＦは、当該インターフェースを介して、プログラム識別子およびコンテンツ保護鍵に関する情報をＫＭＦに要求することができる。

インターフェースＩ８は、ＳＧＦとＣＭＦとの間における双方向通信インターフェースである。ＳＧＦは、当該インターフェースを介して、ＣＭＦにコンテンツメタ情報を要求することができる。

インターフェースＩ９は、ＲＩＦとＵＰＳＦとの間における双方向通信インターフェースである。ＲＩＦは、当該インターフェースを介して、ＵＰＳＦにユーザのプロファイルサービスおよび権限情報を要求することができる。当該インターフェースのプロトコルは、ダイアメータプロトコルであってよい。

図３では、ＭＲＬＦ／ＭＲＢＦは、ＭＲＦに関する情報を収集して適切なＭＲＦを選択する機能を行うことができる。実際のアプリケーションでは、ＭＲＬＦ／ＭＲＢＦによって実現される機能は、ＭＲＦＣの機能を拡張することによっても実現することができる。このような拡張方法の１つとしては、ネットワーク全体における全てのＭＲＦＣをピアツーピアネットワークのノードとして用いて、これらのＭＲＦＣにピアツーピアノードの機能（例えば、ノードメンバグループの管理、認証、リソース発行、検索、要求、およびサービス提供）を実行させて、ＭＲＦＣ間の双方向通信によってＣＤＮの機能を完成させる方法がある。ＣＤＮは、ストリーミングメディアサービスの重要な補助機能である。例えば、大規模なストリーミングネットワークにおいて、数十万のユーザがストリーミングサーバに同時に要求メッセージを送信した場合、ネットワーク帯域幅は耐えることができない。このため、プログラムコンテンツが配置される際には、人気のあるプログラムコンテンツを、ユーザ付近のエッジメディアサーバ（例えば深川）に事前に配信しておくか、あるいは、まずセントラルメディアサーバ（例えば北京）を介してユーザ付近のエッジメディアサーバへ配信し、その後でエッジメディアサーバが当該人気のあるプログラムコンテンツをユーザへ配信する必要がある。ユーザは、同一のプログラムコンテンツを再度要求した場合は、そのプログラムコンテンツをエッジメディアサーバから直接取得することができる。

図４は、本発明の第２の実施形態に係るＩＭＳネットワークシステムを示している。図４に示すように、ＭＲＦＣは、ネットワーク全体または任意のＩＭＳ領域のメディアリソース配信情報およびＭＲＦステータス情報を、検索、位置指定、および配信する機能を行う。ＭＲＦＣとＭＲＦＣとの間には、双方向通信インターフェースが配置されている。ネットワーク全体または任意のＩＭＳ領域において、ＭＲＦＣ間の双方向通信によって、メディアリソース配信情報およびＭＲＦステータス情報の双方向通信が行われ、ネットワーク全体または任意のＩＭＳ領域のメディアリソース配信情報およびＭＲＦステータス情報が取得される。これによって、ＡＳ／Ｓ−ＣＳＣＦが、任意のＩＭＳ領域に対してメディアリソース要求メッセージを出すことができ、またＭＲＦＣは、双方向通信によって取得されたメディアリソース配信情報およびＭＲＦステータス情報に従って、メディアリソース要求メッセージを適切なＭＲＦＣへルーティングする。

ＭＲＦＣ間の双方向通信は、ピアツーピア（peer-to-peer; Ｐ２Ｐ）技術によって行うことができる。すなわち、各ＭＲＦＣは、Ｐ２Ｐネットワーク内の１つのノードに対応しており、メディアリソースを配信およびスケジューリングする機能は、Ｐ２Ｐ技術に基づいて行われる。Ｐ２Ｐ技術は、ノードメンバグループの管理、認証、リソース発行、サーチ、要求、およびサービス提供を含んでいる。

ＭＲＦＣは、ネットワーク全体または任意のＩＭＳ領域のメディアリソース配信情報およびＭＲＦステータス情報を、ＭＲＦＣ間の双方向通信によって取得することができる。このため、ＣＭＦはまた、ＭＲＦＣのいずれかと双方向通信した場合、ネットワーク全体または任意のＩＭＳ領域のメディアリソース配信情報およびＭＲＦステータス情報を取得し、そして、設定されたコンテンツ配信ポリシーに従って管理されたコンテンツをＭＲＦに配信することができる。ＣＭＦはまた、所定のＭＲＦへコンテンツソースを配信し、そして必要に応じて、ＭＲＦＣ間に形成されたＰ２Ｐネットワークに基づいて、ネットワーク全体または任意のＩＭＳ領域のＭＲＦ間にコンテンツソースを配信することができる。ＣＭＦはまた、Ｐ２Ｐネットワークの中心ノードをＭＲＦＣとして直接構成し、そして必要に応じて、Ｐ２Ｐネットワークの配信技術に直接従って、ネットワーク全体または任意のＩＭＳ領域のＭＲＦ間にコンテンツソースを配信することができる。

図４では、ＡＳ／Ｓ−ＣＳＣＦが、ユーザからストリーミングメディアサービス要求を受信すると、ＭＲＬＦに適切なＭＲＦを問い合わせるのではなく、ＭＲＦＣにメディアリソース要求を送信する。これは、ＡＳ／Ｓ−ＣＳＣＦによって、所定の構成されたＭＲＦＣのアドレス、または、所定の汎用ＭＲＦＣのＳＩＰ・ＵＲＩ、および、ＤＮＳ解決のポリシーによって上記所定のＭＲＦＣへ返却されたＩＰアドレスに従って決定される。さらに、ＡＳによって送信されるメディアリソース要求は、ストリーミングメディアサービス要求と同一であってよい。すなわち、単に、ストリーミングメディアサービス要求を転送してもよい。ＡＳはまた、当該ストリーミングメディアサービス要求が有するパラメータに応じて、ストリーミングメディアサービスに変更を加えるか、あるいは、新しい要求メッセージを生成することができる。この場合、メディアリソース要求は、ストリーミングメディアサービス要求と同一ではない。メディアリソース要求を受信したＭＲＦＣは、当該メディアリソース要求を、ＡＳによって供給された情報（例えば、ユーザの位置、ＩＰアドレス、ユーザのコーディングおよびデコーディング性能、ＱｏＳ要求、ユーザ端末のタイプ、メディアコンテンツＩＤ）、並びに、ＭＲＦＣによって形成されたＰ２Ｐネットワークが取得した、ネットワーク全体または任意のＩＭＳ領域のメディアリソース配信情報およびＭＲＦＣステータス情報に従って、適切なＭＲＦＣにルーティングすることができる。そして、適切なＭＲＦＣが、ＭＲＦＰを制御して、対応するメディアコンテンツをユーザへ供給する。ＭＲＦＣは、インターフェースＩ４と双方向通信することによって、メディアリソース配信情報およびＭＲＦステータス情報を取得し、それぞれ異なるＭＲＦＰ間におけるメディアリソースのコンテンツ配信およびスケジューリングを制御することができる。

実際の利用においては、ＭＲＬＦ／ＭＲＢＦは、ＭＲＢＦのみであってよい。図５は、本発明の第３の実施形態に係るＩＭＳネットワークシステムを示す図である。図５に示すように、ＭＲＢＦは、ＩＭＳ領域内において、ＭＲＦの照合、位置指定、およびルーティングを行うだけではなく、領域を超えたメディアリソースアクセスを可能にするために、他のＩＭＳ領域内のＭＲＢＦと双方向通信するという、さらなる機能を有している。

さらに、それぞれ異なるＩＭＳ領域のＭＲＢＦ同士が双方向通信するために、ＭＲＢＦとＭＲＢＦとの間に、インターフェースＩ１０が配置されている。インターフェースＩ１０は、領域を超えたメディアリソースの検索、位置指定、およびルーティングを行うインターフェース機能を有している。

ＣＭＦが管理するコンテンツソースを、ＭＲＢＦを介してＭＲＦＣへ配信するために、ＣＭＦとＭＲＢＦとの間にインターフェースＩ１１が配置されている。いずれのＭＲＦＣにコンテンツソースが配信されるのかは、ＭＲＢＦによって収集されたＭＲＦステータス情報、および、ＣＭＦによって構成されたコンテンツ配信ポリシーに依存している。

ＭＲＬＦ／ＭＲＢＦは、図３〜図５に示すように、ＩＭＳネットワークアーキテクチャ内に配置されているが、実際の利用においては、ＭＲＬＦ／ＭＲＢＦとＡＳ／Ｓ−ＣＳＣＦとＭＲＦＣとの間にインターフェースが配置されているのであれば、ＩＭＳネットワークアーキテクチャ外に配置されていてもよい点に留意されたい。

図３〜図５は、本発明の３つの実施形態に係るシステムを示している。本発明はさらに、ＩＭＳベースのストリーミングメディアサービス実現方法の一実施形態を提供する。本方法実施形態の技術的解決法は、ストリーミングメディアサービスイネーブラが、ストリーミングメディアサービス記述情報をユーザ端末に供給する工程と、当該ユーザ端末が、上記サービス記述情報に従ってストリーミングメディアサービスを選択する工程と、アプリケーションサーバが、上記ユーザ端末からストリーミングメディアサービス要求を受信した後にメディアリソース要求を送信する工程と、メディアサーバが、ストリーミングメディアコンテンツを記憶するメディアリソース配送処理機能エンティティに関する情報を、アプリケーションサーバに供給する工程と、当該アプリケーションサーバが、当該メディアリソース配送処理機能エンティティに関する情報を、上記ユーザ端末へ供給する工程とを含んでいる。

上記方法は、上記ユーザ端末が、上記ストリーミングメディアサービス要求を開始する前に上記ストリーミングメディアサービスイネーブラからプログラム情報を取得する工程をさらに含んでいてもよい。

上記方法は、上記アプリケーションサーバが、上記ストリーミングメディアサービス要求を処理する際に上記ストリーミングメディアサービスイネーブラからストリーミングメディアコンテンツメタ情報を取得する工程をさらに含んでいてもよい。

上記アプリケーションサーバは、上記アプリケーションサーバがメディアサーバに関する情報をＭＲＬＦに問い合わせる工程と、ＭＲＬＦが少なくとも１つのメディアサーバからメディアサーバを１つ選択し、選択されたメディアサーバに関する情報を上記アプリケーションサーバに戻す工程と、上記アプリケーションサーバが上記メディアリソース要求を選択されたメディアサーバへ送信する工程とに従って、上記メディアリソース要求を送信することができる。

上記アプリケーションサーバは、上記アプリケーションサーバが上記メディアリソース要求をＭＲＢＦへ送信する工程と、ＭＲＢＦが少なくとも１つのメディアサーバからメディアサーバを１つ選択し、選択されたメディアサーバへ上記メディアリソース要求を転送する工程とに従って、上記メディアリソース要求を送信することができる。

上記アプリケーションサーバは、上記アプリケーションサーバが上記メディアリソース要求を上記メディアサーバ内のメディアリソース制御機能エンティティへ送信する工程と、上記メディアリソース制御機能エンティティが少なくとも１つのメディアサーバからメディアサーバを１つ選択し、選択されたメディアサーバへ上記メディアリソース要求を転送する工程とに従って、上記メディアリソース要求を送信することができる。

上記方法は、上記アプリケーションサーバが、上記メディアリソース配送処理機能エンティティに関する情報を上記ユーザ端末に供給した後、上記ユーザ端末および上記メディアリソース配送処理機能エンティティが、配送ネゴシエーションを行う工程をさらに含んでいてもよい。当該ネゴシエーションは、上記メディアサーバと上記端末との間におけるメディア制御チャネルに関する記述情報のネゴシエーション、および／または、上記メディアサーバと上記端末との間におけるメディア転送チャネルに関する記述情報のネゴシエーション、および／または、上記メディアサーバと上記端末との間におけるネットワークトランスポート層リソースの予約のネゴシエーションを含んでいてもよい。上記メディア転送チャネルは、ストリーミングメディアコンテンツ（例えば、ＴＣＰ接続またはＵＤＰメディアストリーム）を転送するネットワークトランスポート層保有チャネルであり、上記メディア転送チャネルに関する記述情報は、メディア転送チャネル（例えば、ＩＰアドレスおよびＵＤＰポート番号）を特徴付ける関連パラメータである。上記メディア制御チャネルは、メディア制御信号（例えば、ストリーミングメディアコンテンツの送信を制御する信号）を転送するネットワークトランスポート層保有チャネルであり、上記メディア制御チャネルに関する記述情報は、メディア制御チャネル（例えば、ＩＰアドレス、ＵＤＰポート番号）を特徴付ける関連パラメータである。これらのチャネルにおいて双方向通信する信号を制御することによって、ストリーミングメディアコンテンツの送信を制御（例えば、開始、一時停止、順再生、および逆再生）することができる。さらに、上記ユーザ端末および上記メディアリソース配送処理機能エンティティは、直接、またはＡＳあるいはその他の機能エンティティの制御下において、配送ネゴシエーションを行うことができる。

上記方法は、上記ユーザ端末および上記メディアリソース配送処理機能エンティティが上記配送ネゴシエーションを行った後、上記ユーザ端末が、上記メディアリソース配送処理機能エンティティによって供給されたストリーミングメディアコンテンツを直接受信する工程か、あるいは、上記ユーザ端末が、上記ネットワークトランスポート層に転送要求を送って配送を行った後、上記ユーザ端末が、上記メディアリソース配送処理機能エンティティによって供給されたストリーミングメディアコンテンツを受信する工程をさらに含んでいてもよい。

また、上記ユーザ端末は、上記ストリーミングメディアサービスイネーブラから取得した権利オブジェクトおよび／または鍵情報を用いて、上記ストリーミングメディアコンテンツを復号することができる。

上記ユーザ端末と上記メディアリソース配送処理機能エンティティとの間における配送ネゴシエーションは、上記メディアサーバと上記端末との間におけるメディア制御チャネルの記述情報に関するネゴシエーション、および／または、上記メディアサーバと上記端末との間におけるメディア転送チャネルの記述情報に関するネゴシエーション、および／または、上記メディアサーバと上記端末との間におけるネットワークトランスポート層のリソースの予約に関するネゴシエーションを含んでいてもよい。

以下では、再びＶＯＤを例として取り上げて、本発明の実施形態に係るＩＭＳネットワークシステムのストリーミングメディアサービス実現方法について説明する。

まず図６を参照すると、第１の実施形態に係る方法が説明されている。第１の実施形態では、図６に示すように、ＵＥは、コンテンツ保護モードによって、ＲＩＦからインターフェースＩ１を介して権利オブジェクト（ＲＯ）を取得して、暗号化されたコンテンツを復号する。

Ｓ６００：ＵＥが、ＳＧＦからインターフェースＩ２を介して電子番組ガイドを取得する。

Ｓ６０１：ＵＥが、上記電子番組ガイドが有するユーザリソースＩＤ（ＵＲＩ、ＳＩＰ・ＵＲＩ）に基づいて、サービス要求メッセージを出す。当該サービス要求メッセージは、ＳＩＰメッセージであってよく、また少なくとも、要求されたコンテンツ／サービスに関するＩＤ情報を含んでいる。さらに、上記サービス要求メッセージは、ＡＳのＵＲＩ、および関連するメディア記述情報（ＳＤＰ、セッション記述プロトコル）さらに含んでいてもよい。

Ｓ６０１．１：Ｐ−ＣＳＣＦが、上記サービス要求メッセージを受信した後、ＵＥの位置情報をＣＬＦに要求する。ＣＬＦは、ＵＥの位置情報を記憶するための、ＮＧＮネットワークアーキテクチャのＮＡＳＳサブシステム内における機能エンティティである。

Ｓ６０１．２：ＣＬＦが、ＵＥの位置情報をＰ−ＣＳＣＦへ戻す。

Ｓ６０１．３：Ｐ−ＣＳＣＦが、ＵＥによって送信されたサービス要求メッセージ内に含まれるＳＤＰに基づいて、リソース送信要求をＳＰＤＦへ送信する。このリソース送信要求は、トランスポート層保有ネットワークのリソース要求である。ＳＰＤＦは、ＮＧＮネットワークアーキテクチャのＲＡＣＳサブシステム内における機能エンティティである。ＳＰＤＦは、サービス層から要求を受信し、そしてＲＡＣＳサブシステムの他の機能エンティティと共に、保有ネットワークのリソースを制御する。この工程は、単に、リソースの使用が許可されるか否かを決定するための、ポリシー決定処理の１つであってよい。

Ｓ６０１．４：ＳＰＤＦが、フィードバック処理結果を含むリソース送信応答をＰ−ＣＳＣＦへ戻す。

Ｓ６０２：Ｐ−ＣＳＣＦが、サービス要求メッセージ内にＵＥの位置情報を加え、そしてサービス要求メッセージをＳ−ＣＳＣＦへ転送する。

Ｓ６０３：Ｓ−ＣＳＣＦは、上記サービス要求メッセージ内に含まれるコンテンツおよびサービストリガ規則に基づいて、サービス要求メッセージをトリガにして、ＡＳにサービス／コンテンツを処理させる。トリガ条件は、サービス／コンテンツのＩＤ、またはＡＳのＵＲＩであってもよい。

Ｓ６０４：ＡＳが、特定のサービス論理を処理する。Ｓ−ＣＳＣＦによってトリガされた上記サービス要求メッセージが、メディアコンテンツの使用を伴っている場合、メディアリソースサービスの供給に使用できるＭＲＦＣを決定する必要がある。ＡＳは、この時点において、ＭＲＬＦに対してリソース位置指定要求を出す必要がある。当該リソース位置指定要求は、コンテンツ識別情報、コンテンツコーディング形式、圧縮形式要件、ＵＥの位置情報、およびＵＥのＩＤを含んでいてもよい。

Ｓ６０５：ＭＲＬＦが、ＭＲＦＣと双方向通信することによって取得したメディアリソース配信情報およびＭＲＦステータス情報、ＵＥの位置情報、およびリソース要求に基づいて、サービスの供給に使用できるＭＲＦを決定する。そしてＭＲＬＦは、リソース検索応答をＡＳに戻す。当該リソース検索応答は、決定されたＭＲＦを戻した結果を含んでいる。

ＭＲＬＦは、以下の方法によって、メディアリソース配信情報およびＭＲＦステータス情報を取得することができる：
ＭＲＬＦ、ＣＭＦ、およびＭＲＦＣ同士が、互いに双方向通信し、メディアリソースの配信を制御する。ＭＲＦＣが、メディアリソースの配信結果を収集し、それをＭＲＬＦへ供給する。そしてＭＲＬＦが、メディアリソースの配信を取得した後、メディアリソースの配信を、ＭＲＦＣを選択するための条件として用いる。

メディアリソースの配信処理は、ＭＲＬＦを用いずに行うこともできる。この場合、メディアリソースの配信結果は、ＭＲＦＣによってＭＲＬＦへ供給される。

さらに、メディアリソースを配信するための固定的なポリシーがあってもよい。そのポリシーは、ＭＲＦＣを選択するための基準としてＭＲＬＦに導入することができる。

Ｓ６０６：ＡＳが、ＭＲＬＦから戻されたＭＲＦＣのアドレス情報に基づいて、ＭＲＦＣに対してメディアリソース要求メッセージを出す。

Ｓ６０７：上記メディアリソース制御ＭＲＦＣが、ＭＲＦＰと双方向通信することによって、メディアリソース情報を取得する。当該メディアリソース情報は、リアルタイムストリーミングプロトコル（Realtime Streaming Protoco; ＲＴＳＰ）アドレス／ポート、リアルタイム転送／リアルタイム転送制御プロトコル（ＲＴＰ／ＲＴＣＰ）アドレス／ポートなどの情報を含んでいる。

Ｓ６０８：ＭＲＦＣが、ＭＲＦＰのＳＤＰをＡＳへ返却する。ＳＤＰは、決定されたＲＴＳＰ／ＲＴＰ／ＲＴＣＰアドレス／ポートなどの情報を含んでいる。

Ｓ６０９：ＡＳが、サービス応答をＳ−ＣＳＣＦへ返却する。

Ｓ６１０：Ｓ−ＣＳＣＦが、上記サービス応答をＰ−ＣＳＣＦへ転送する。ＱｏＳリソースを予約している間、サービス要件（マルチキャスティングが必要である、等）に基づいて、保有ネットワークに対してマルチキャスティング制御を行うことができる。

Ｓ６１０．１：Ｐ−ＣＳＣＦが、ＳＰＤＦに対してリソース予約要求を出す。

Ｓ６１０．２：ＳＰＤＦが、リソース予約結果をＰ−ＣＳＣＦへ返却する。

Ｓ６１１：Ｐ−ＣＳＣＦが、サービス応答をＵＥへ転送する。当該サービス応答は、メディアネゴシエーションの結果を含んでいる。

Ｓ６１２：ＵＥが、上記サービス応答に基づいて、ＡＳとＳＩＰシグナリングのインタラクションを行い、ＡＳから返却された応答“２００（ｏｋ）”を受信すると、ネゴシエーション処理を完了する。：
Ｓ６１２．１：Ｐ−ＣＳＣＦが、最終的なネゴシエーション確認情報に基づいて、ＳＰＤＦ予約リソースを修正およびコミットし、保有ネットワークのゲート制御を開始する。

Ｓ６１２．２：ＳＰＤＦが、上記コミット要求に対して確認応答を返却する。

Ｓ６１３：ＡＳおよびＭＲＦＣが、ＳＩＰシグナリングのインタラクションを行って、ネゴシエーション処理を完了させる。

Ｓ６１４：ＭＲＦＣが、最終的なネゴシエーションの結果に基づいてＭＲＦＰを制御する。

Ｓ６１５：メディア制御チャネルが構築される。本工程では、ＵＥが、サービスストリーム制御、すなわちＶＣＲ制御を行うために、最終的なネゴシエーションの結果に基づいて、ＭＲＦＰとのＲＴＳＰ接続を行う。

Ｓ６１６：ＵＥおよびＭＲＦＰが、メディアストリームを送信するために、ＲＴＰ／ＲＴＣＰメディア送信チャネルを構築する。

ＵＥは、メディアストリームを受信した後、ＲＩＦから取得した権利オブジェクト内に含まれるコンテンツ暗号鍵を用いて当該メディアストリームを復号し、メディアプログラムを再生する。これと同時に、ＵＥは、ＭＲＦＰに対して構築した上記ＲＴＳＰチャネルによって、上記メディアプログラムに制御（例えば、一時停止、早送り、および再生）を加えることができる。

図７は、本発明の第２の実施形態に係る方法を示すフローチャートである。図７に示すように、本実施形態では、ＭＲＦの機能を拡張することによってメディアリソースの配信およびスケジューリングが実現される。ＭＲＦＣ間における双方向通信によって、メディアリソース配信情報およびＭＲＦステータス情報のやりとりが完了し、ネットワーク全体のリソース情報を取得する。これによって、ＡＳ／Ｓ−ＣＳＣＦが、任意のＩＭＳ領域内においてＭＲＦＣにリソース要求を出すことができ、ＭＲＦＣは、双方向通信によって取得した情報に基づいて、適切なＭＲＦＣにメディアリソース要求メッセージをルーティングすることができる。

図８は、本発明の第３の実施形態に係る方法を示すフローチャートである。本実施形態では、ＡＳは、最適なＭＲＦＣを決定することができ、また、ＣＭＦ、ＭＲＬＦ、ＭＲＢＦ、またはＭＲＦＣからメディアリソース配信情報およびＭＲＦステータス情報を収集または問い合わせることができる。ＣＭＦは、ＭＲＬＦ、ＭＲＢＦ、またはＭＲＦＣから、メディアリソース配信情報およびＭＲＦステータス情報を収集または問い合わせることができる。

図８の工程Ｓ８０１〜Ｓ８０３および工程Ｓ８０６〜Ｓ８１６は、図６の工程Ｓ６０１〜Ｓ６０３および工程Ｓ６０６〜Ｓ６１６と同一である。図８の工程Ｓ８０４およびＳ８０５は、それぞれ以下の通りである：
Ｓ８０４：メディアリソース情報の取得。ＡＳは、ＣＭＦ／ＭＲＬＦと双方向通信して、メディアリソース情報（例えばメディアリソース配信情報および／またはメディアサーバの負荷情報）を取得する。

Ｓ８０５：最適なＭＲＦＣの決定。決定は、ＵＥから送られたサービス要求メッセージに含まれているコンテンツＩＤおよびユーザの位置、並びにＣＭＦ／ＭＲＬＦから取得されたメディアリソース配信情報、および／あるいは、メディアサーバの負荷情報に基づいて行われる。

図３〜図５に示すシステムおよび図６〜図８に示す方法の実施形態では、ＳＧＦ、ＣＭＦ、ＫＭＦ、およびＲＩＦは、電子番組ガイド、コンテンツメタ情報、暗号鍵、および著作権保護などの情報を提供するストリーミングメディアサービスイネーブラを構成することができる点に留意されたい。実際の利用においては、ストリーミングメディアサービスイネーブラは、他の機能エンティティまたは機能ユニットをさらに含んでいてよく、また、これら機能エンティティまたは機能ユニットは、上記情報、そして当然ながら、他の機能または情報をも提供することができる。

ストリーミングメディアサービスイネーブラの構成が変更された場合、ストリーミングメディアネットワークシステムに含まれるトリーミングメディアサービスイネーブラも変更される。以下では、ストリーミングメディアネットワークシステムの実施形態について、図９と併せて説明する。

図９に示すように、コンテンツ領域は、以下の３つの部分を含んでいる：
コンテンツ操作ユニット。当該コンテンツ操作ユニットは、ＶＯＤシステムに最新の動画を追加する、ボクシングの試合のために一時的な新しい生放送チャネルを設置する、あるいは既存の番組チャネルを調節するなど、ＩＰＴＶサービスコンテンツを管理するためのＩＭＳ外からのコマンドである。その内部操作は、運用サポートシステム、または専用保守運用プラットフォームを通じて行われてもよい。

コンテンツソース。当該コンテンツソースは、ＩＰＴＶサービスに関するコンテンツのソースである。当該コンテンツは、コンテンツプロバイダから直接送られるコンテンツ（例えば、衛星ネットワークからの生番組メディアストリーム）であってよく、あるいは所定のセントラルサーバ内に記憶されたコンテンツ（例えば、フィルムライブラリ内のファイル）であってよく、あるいはユーザ端末から供給される共有ビデオストリームであってもよい。

デジタル著作権管理（Digital Rights Management ; ＤＲＭ）。ＤＲＭは、外部のデジタル著作権管理システムである。コンテンツプロバイダによって供給されたコンテンツが暗号化されている場合、ユーザ端末は、ＤＲＭを介してコンテンツプロバイダから直接供給されるコンテンツ暗号鍵および権利オブジェクトなどの著作権情報を取得する必要がある。

図９に示すアクセスネットワーク層は、有線または無線アクセスネットワークを含んでいる。これらの有線または無線アクセスネットワークは、イーサネット（登録商標）、デジタル加入者回線（ｘＤＳＬ）、第３世代移動体通信ネットワーク（３Ｇ）、無線ローカルエリアネットワーク（ＷＬＡＮ）／ＷｉＭａｘネットワーク、デジタルビデオ放送規格（ＤＶＢ−Ｔ／Ｈ）ネットワークなどのＩＰ技術をサポートしている。アクセスネットワークは、ＩＰＴＶサービスの特徴に基づいて、ユニキャスト／マルチキャスト／ブロードキャストをサポートして、一定のサービス品質（ＱｏＳ）を保証する性能を有している必要がある。さらに、上位アプリケーションは、アクセスネットワークのタイプに基づいて、それに対応する制御モードを利用可能であるべきである。アクセスネットワークは、ＴＩＳＰＡＮ（Telecoms & Internet converged Services & Protocols for Advanced Networks ; ＮＧＮ研究のために設立された国際標準化団体）によって規定されたＮＡＳＳおよびＲＡＣＳインターフェースをサポートできなければならない。

図９に示すトランスポート層は、２つの部分、すなわちトランスポート制御と配送および配信とに分割することができる。

上記トランスポート制御は、ＴＩＳＰＡＮ・ＮＧＮによって規定される２つの機能サブシステム（すなわちＮＡＳＳおよびＲＡＣＳ）を直接用いる。ＮＡＳＳおよびＲＡＣＳは、ＩＰＴＶサービスネットワークと転送ネットワークとの間に導入された転送制御層であって、サービスと転送とを関連付ける。これら２つのサブシステム同士が協働することによって、上記転送層は、ユーザ端末の認識、サービスの区別、及び品質の制御を可能にする。

ＮＡＳＳは、ＩＰＴＶサービスの接続前に、ユーザ端末に対して、アクセスレベルの登録および初期化を行うことができる。これは、ネットワーク層内のデバイスに対するＩＤ、認証、ＩＰアドレス割り当て、およびアクセス許可を含んでいる。ＮＡＳＳは、ローミングするユーザ端末に対し一貫したサービス体験を保障するため、及びサービスの正確な運用のために、ユーザ端末の認証、及び位置指定を実行することにより、ユーザ端末の管理およびセキュリティーの強化に基礎を置いている。

ＲＡＣＳは、ＩＰＴＶアプリケーションのためのネットワークリソースの要求および予約機構を提供する。生放送のテレビ（ＬＴＶ）、ＶＯＤ、ビデオ会議、およびオンラインゲームなどリアルタイムのＩＰＴＶサービスでは、ＲＡＣＳによって、ネットワークにおけるリソース予約制御、パーミッションの制御、およびポリシー制御を行うことができる。ＲＡＣＳは、セッションに基づいてリソース管理および制御を行い、また、サービスからは独立している。

ＩＰＴＶサービスでは、全メディア配送配信制御機能は、３つの機能エンティティ、すなわちＭＲＢＦ、ＭＲＦＣ、およびＭＲＦＰを組み合わせて実現することができる。ＭＲＢＦおよびＭＲＦＣは、制御層に属しており、それぞれ、メディア配送及び配信機能、並びにメディアリソース制御機能を提供する。ＭＲＢＦは、メディア配信および配送に関する決定を行い、ＭＲＦＣは、ＭＲＦＰが実際のメディア配信および配送処理を行うのを制御する。

ＭＲＦＰは、トランスポート層に配置されており、ＭＲＦＣの制御のもとにメディアの配信、配送、および処理を行う。ＩＭＳベースのＩＰＴＶシステムでは、ＭＲＦＰは、ＭＲＦＣの制御のもとに、特定のストリーミングメディアコンテンツの配信記憶および配送送信をサポートする。ＭＲＦＰは、従来のＩＰＴＶシステムにおけるメディアサーバであってよい。ＭＲＦＰは、ネットワーク内におけるＭＲＦＰの配置の位置に応じて、実際のストリーミングメディアコンテンツを供給するためのセントラルメディアサーバまたはエッジメディアサーバであってよい。配信処理では、ＭＲＦＰは、コンテンツソースからストリーミングメディアコンテンツを取得し、そしてＭＲＦＣの制御下において、ＭＲＢＦによるコンテンツ配信を介して、ストリーミングメディアコンテンツを記憶することができる。

配送処理では、ＭＲＢＦが、ユーザ端末からのストリーミングメディアコンテンツの要求を、特定のポリシー下において最適なＭＲＦＰへリダイレクトする。そして最終的に、ＭＲＦＰが、ストリーミングメディアコンテンツをユーザ端末へ供給する。

具体的には、ＭＲＦＰは、様々な方法によってストリーミングメディアコンテンツを取得および記憶し、記憶されたストリーミングメディアコンテンツを素早く取り出す機能と、ＭＲＦＣの要求に基づいて、負荷状態、リソースの状態、およびストリーミングメディアコンテンツの状態など、特定の情報を報告する機能と、コーディング／デコーディング形式の変換、映像コンテンツの圧縮、および映像コンテンツの混合などのストリーミングメディア形式を処理する機能と、複数の方法によってストリーミングメディアコンテンツを配信して、それぞれ異なる配信方法間において変換を行う機能と、特定の鍵を用いてストリーミングメディアコンテンツをリアルタイムで暗号化するための、ストリーミングメディアコンテンツ暗号化機能とを行うことができる。

図９に示す制御層は、主に、ＩＰＴＶサービスセッションの管理を行う。ＩＭＳベースのＩＰＴＶシステムでは、ＩＰＴＶサービスの実行特性および性能に応じていくらかの拡張がなされた点、既存の機能エンティティ（例えばＣＳＣＦ、ＣＦ、ＵＰＳＦ、およびＭＲＦＣ）に対して新しい要求が提案された点、新しい機能エンティティＭＲＢＦが追加された点を除いては、上記制御層は、ＩＭＳの制御層アーキテクチャを完全に採用している。

ＭＲＢＦは、メディアリソースの検索、位置指定、配信、並びに、ネットワーク全体または一定の管理領域内のメディアリソースステータス情報といったリソースのポリシー制御を行う。ＭＲＢＦは、メディアの配送および配信を制御し、一定のポリシーに従ってコンテンツの配信を決定し、そして、ＭＲＦＣを介してＭＲＦＰを制御することによって、コンテンツソースからＭＲＦＰへストリーミングメディアコンテンツを配信する。ＭＲＢＦは、ＭＲＦＣと双方向通信することによって、メディア発行ステータス情報を取得し、上記メディア発行ステータス情報に基づいて、ＭＲＦＰが配送するかを決定し、そしてＭＲＦＣを介してＭＲＦＰを制御することによって配送を行う。ＭＲＢＦは、主に、メディアリソースステータス情報（例えば、使用可能なリソースに関するステータス、負荷ステータス、ＱｏＳ、および使用可能な帯域幅）をＭＲＦＣから収集する機能と、ＣＭＦによって取得されたメディア配信情報、およびＡＳ／Ｓ−ＣＳＣＦからの要求に従ってＭＲＦＣによって収集されたメディア配信点の負荷ステータスから、適切なＭＲＦＰを選択する機能と（ＡＳ／Ｓ−ＣＳＣＦからの上記要求は、ストリーミングメディアコンテンツＩＤ、ユーザアクセス位置またはＩＰアドレス、ユーザ端末のタイプ、およびＱｏＳ要求を含んでいる）、ＡＳ／Ｓ−ＣＳＣＦからＭＲＦへメディアリソース要求メッセージをルーティングし、これと同時に、ルーティングポリシーに従ってＡＳ／Ｓ−ＣＳＣＦとＭＲＦとの間におけるその後の双方向通信への関与を終了する選択を行う機能とを有している。ＭＲＢＦとＡＳおよび／またはＳ−ＣＳＣＦとの間には、インターフェースがあってよい。

ＩＭＳベースのＩＰＴＶシステムでは、ＭＲＦＣは、既存のＩＭＳの機能に加えて、ＭＲＦＰを制御してストリーミングメディアコンテンツを取得し、コンテンツソースからＭＲＦＰへストリーミングメディアコンテンツへの配信処理を制御する機能と、ＭＲＦＰを制御してストリーミングメディアコンテンツの配送を行い、互いに異なる様々な配送モードを制御し、またユニキャストとマルチキャストとの切り替えを制御する機能と、ＭＲＦＰを制御してメディア形式を処理する機能（例えば、メディア形式変換の制御、映像圧縮の制御、および映像混合の制御）と、ＭＲＦＰを制御して、ストリーミングメディアコンテンツをリアルタイムで暗号化する機能と、ストリーミングメディアコンテンツ配信情報、負荷ステータス、ＱｏＳ、およびＭＲＦＰのネットワーク情報を取得して、それらの情報をＭＲＢＦを供給する機能と、リアルタイムストリームプロトコル（ＲＴＳＰ）などのメディア双方向通信制御プロトコルをサポートして、ＲＴＳＰサービス側の機能を実現するための機能と、ＲＴＳＰクライアントの機能を行うための、メディアインタラクション制御プロキシ機能とをさらに有していてもよい。

図９に示す制御層は、様々な課金方法を提供するための課金機能をさらに有していてもよい。上記様々な課金方法には、例えば、オンライン／オフライン課金、セッションに基づく課金、イベントに基づく課金、ＩＰＴＶシステムにおけるＬＴＶ、ＶＯＤサービスのネットワークリソース占有に基づく課金、がある。

図９には、ＵＰＳＦが備えられていてもよく、ＵＰＳＦは、全ユーザに関連する情報を記憶するための、ストリーミングメディアネットワークシステムのセントラルデータサーバであってよい。ＩＰＴＶシステムでは、ＵＰＳＦは、ユーザのＩＰＴＶサービスプロファイル情報を記憶することができる。

図９に示すアプリケーション層は、ＩＰＴＶサービスの実現に非常に重要である。当該アプリケーション層は、２つの部分、すなわちＩＰＴＶサービスイネーブラとＩＰＴＶアプリケーションとを含んでいてもよい。

上記ＩＰＴＶサービスイネーブラは、ＩＰＴＶサービスの実施に必要とされる所定の機能であって、ＩＭＳ制御層の上位であってＩＰＴＶアプリケーション層の下位に位置している。ＩＰＴＶサービスは、例えばサービスの実行性能（ユニキャスト／マルチキャスト、サービス識別、ストリーミングメディアコンテンツメタ情報管理、ストリーミングメディアコンテンツ配置、番組ガイド管理、安全な著作権保護、装置の性能管理、コンテキスト管理など、多数の所定の機能により実現される。これらの所定の性能が、セッション制御およびアプリケーションによって呼び出される異なるサービスイネーブラとして抽出される場合は、ＩＰＴＶサービスを実行することができる。これらのサービスイネーブラは、サービス提供機能（ＳＰＦ）エンティティと、ＩＰＴＶサービスを制御するサービス制御機能（ＳＣＦ）エンティティと、ユーザ端末性能を記憶するデバイスプロファイル機能（ＤＰＦ）エンティティと、コンテキスト管理を行うコンテキストマネージャ（ＣＭ）と、ストリーミングメディアコンテンツサポート機能を行うストリーミングメディアコンテンツ保護機能（ＣＰＦ）エンティティと、を備えていてもよい。

ＳＰＦは、サービスの発見および選択機能を行うサービス発見機能（service discovery function; ＳＤＦ）ユニットと、番組ガイドを管理する番組ガイド機能（ＰＧＦ）ユニットと、サービスのスケジューリングを行うサービススケジューラ機能（ＳＳＦ）ユニットと、ストリーミングメディアのコンテンツ管理を行うストリーミングメディアコンテンツメタ情報管理機能（ＣＭＦ）ユニットと、を含んでいてもよい。

ＳＣＦは、ＩＰＴＶサービスの基本的な性能を制御することができる。ＳＣＦは、ＩＭＳ制御層とＩＰＴＶアプリケーション層との間に位置するＩＰＴＶサービスを実現するための鍵サービスイネーブラである。ＳＣＦは、また、セッション制御とアプリケーションとの間の接続制御エンティティであり、様々なＩＰＴＶアプリケーションに対して、基本的なサービス制御性能およびストリーミングメディアコンテンツ配送制御性能を提供することができる。ＳＣＦの基本的なサービス制御性能とは、主に、ユニキャスト／マルチキャストに対するセッション制御性能である。これは、ＩＰＴＶサービスを行うために必要な性能である。これらのセッション制御性能は、互いに異なるサービスによって共有することができる。ＳＣＦのコンテンツ配送制御性能では、ＳＣＦは、ＣＭＦからコンテンツメタデータおよびコンテンツソース位置情報を取得し、配送されるコンテンツをユーザのコンテキストに従って決定し、そしてＭＲＢＦおよびＭＲＦを介して配送を行う。上記ユーザのコンテキストとは、例えば、ユーザの習慣および信用度である。ＳＣＦによって供給されるものは全て、ＩＰＴＶサービスを行うために必要な基本的性能である。ＳＣＦは、別のＩＰＴＶ・ＡＳとして、別のＩＰＴＶアプリケーションと組み合わせることができる。例えば、ＳＣＦは、ＳＩＰ・ＩＰＴＶ・ＡＳとして、ＳＩＰ・ＩＰＴＶアプリケーションと組み合わせることができる。実際のネットワーク配置では、ＳＣＦは、１つの独立したエンティティとして、複数のＩＰＴＶアプリケーションによって用いられることができる。さらに、一部のＡＳは、それ自身によってＳＣＦを構成することもできる。図１０は、ＳＣＦがＩＰＴＶアプリケーションによって用いられることを示す図である。図１０に示すように、ＡＳ１、ＡＳ２、およびＡＳ３は、共通のＳＣＦ機能を用いる。Ａｐｐ１、Ａｐｐ２、およびＳＣＦ１間のインターフェースは、アプリケーションプログラムインターフェース（ＡＰＩ）であり、Ａｐｐ３とＳＣＦ１との間のインターフェースは、内部インターフェースである。ＡＳ４およびＡＳ５は、自身によってＳＣＦ機能を行う。ＡＰＰ４とＳＣＦ４との間のインターフェース、およびＡＰＰ５とＳＣＦ５との間のインターフェースは、内部インターフェースである。

ＳＰＦは、ＩＰＴＶサービスに関連する必要なサービス性能を提供する。ＳＰＦは、複数のサービス性能であり、サービス発見、サービスのスケジューリング、ストリーミングメディアコンテンツメタ情報管理、および番組ガイドを含んでいる。

ＳＤＦは、ＩＰＴＶサービスに対して、サービス発見、および選択可能なサービス機能を提供する。ＳＤＦは、例えば、ユーザに対して、電子番組ガイド（ＥＰＧ）システムのプログラム情報を提供する。ＥＰＧサーバが複数ある場合は、例えば、異なる複数のサービスプロバイダまたはサードパーティのサービスプロバイダ（サードパーティのサービスに対して独立したＥＰＧサーバがある場合）がある場合、ＥＰＧアクセスポイントは統合される。

ＰＧＦは、サービス閲覧およびサーチエンジン機能を提供する。ＰＧＦは、また、ユーザに対しては、オンデマンドの番組、生放送、および循環放送のインタラクティブなインターフェースを提供する、すなわち、ＥＰＧの生成機能を行う。

ＳＳＦは、ＩＰＴＶサービスの配置および構成を行う。ＳＳＦは、次の機能を有している。マルチキャスティングサービスにおいては、サービス配置の主要な機能は、マルチキャスティングアドレスの割り当ておよび管理、プログラム識別子（ＩＤ）およびマルチキャスティングアドレスの関連付け、マルチキャスティングの確立、マルチキャスティングソースの制御である。オンデマンドの番組サービスにおいては、サービス配置の主要な機能は、メタデータおよびコンテンツ識別子（content identifier; ＣＩＤ）の関連付け、コンテンツ配信のトリガ、およびコンテンツ配信ポリシーの決定である。

ＰＧＦは、電子番組ガイド（ユニキャストおよびマルチキャストを含む）を生成するために必要なサービス情報を、サービス配置および構成情報から取得することができる。ＰＧＦはまた、サービス要求処理中に、静的なサービス配置および動的なサービス配置をサポートすることができる。

ＣＭＦは、ストリーミングメディアコンテンツメタ情報の管理を行う。ここで、ストリーミングメディアコンテンツメタ情報とは、配信前のコンテンツである。従って、ＣＭＦによる管理は、ストリーミングメディアコンテンツ配信前の管理であり、配信後のストリーミングメディアコンテンツは含まれない。当該ストリーミングメディアコンテンツメタ情報は、コンテンツＩＤ、コンテンツメタデータ、およびコンテンツソース位置情報を含んでいる。上記コンテンツＩＤは、ＩＰＴＶシステムが提供できる全てのコンテンツまたはチャネルに固有の参照ＩＤである。上記コンテンツメタデータは、コンテンツまたはチャネルの記述（例えば、コンテンツの簡単な紹介、チャネルの説明、およびメディア形式）を含んでいる。上記コンテンツソース位置情報は、サービスプロバイダ自身の集中した記憶場所であってよく、あるいはコンテンツプロバイダからの一部の記憶アドレス、あるいは生放送コンテンツプロバイダからのメディアポート情報であってよい。ＣＭＦは、他の機能エンティティからのコンテンツの追加、削除、変更、および問い合わせをする機能をサポートすることができる。ＣＭＦはさらに、コンテンツプロバイダからコンテンツ更新通知を受信し、その内部のメタデータおよびソース位置情報を受信し、新しいストリーミングメディアコンテンツのためのコンテンツＩＤを生成し、またコンテンツＩＤ、コンテンツメタデータ、およびコンテンツソース位置情報間のマッピングを行うことができる。さらに、コンテンツプロバイダは、特定のプロトコル（例えばＳＩＰまたはＨＴＴＰ）を介してＣＭＦと双方向通信するコンテンツ管理エンティティを有していてもよい。

ＣＭは、コンテキスト情報の収集、記憶、構成、および送信の機能を備えていてもよい。例えば、ＣＭは、異なる複数の情報ソースから関連情報を収集する機能、異なる複数のアプリケーションへ必要な情報を送信する機能を行うことができる。ＩＰＴＶサービスの実施に影響を与える全ての情報は、コンテキストとして記憶および管理することができる点に留意されたい。コンテキストは、一般的には、ユーザコンテキスト、ネットワークコンテキスト、およびコンテンツコンテキストという３つの種類に分類される。上記ユーザコンテキストは、ユーザに現在用いられているユーザ端末、ユーザが接続するアクセスネットワーク、ユーザの位置、ユーザ端末の有無、および現在のサービスに関する情報を有していてもよい。上記ネットワークコンテキストは、転送ネットワークに関する情報、ＩＰＴＶサービス（例えば、マルチキャスティングに対するコアネットワークのサポート）を確立するために通過すべきネットワークエンティティに関する情報、およびアクセスネットワークの帯域幅に関する情報を含んでいてもよい。上記コンテンツコンテキストは、コンテンツ分類、コンテンツのパーミッション、および人気度を含んでいてもよい。

ＣＰＦは、コンテンツの著作権侵害を防止するために、ＩＰＴＶサービスに配送されたストリーミングメディアコンテンツに対して、著作権セキュリティー保護機構を提供することができる。ＣＰＦは、ＤＲＭ、ＣＡ、およびサービス層保護など、複数の機構を採用することができる。ＣＰＦは、ストリーミングメディアコンテンツ鍵を生成することができ、また、権利オブジェクトを生成および管理することができる。上記ストリーミングメディアコンテンツ鍵は、コンテンツ保護鍵およびサービス保護鍵を含んでいてもよい。

ＤＰＦは、ユーザ端末の性能情報（例えば画面サイズ、解像度、バッテリー容量、メモリ使用量）を記憶することができる。この情報は、ＩＰＴＶサービスを行うために必要な拡張情報であり、上位サービスに、ユーザ端末の性能およびリアルタイムステータス情報をよりよく把握させることができる。この情報はまた、特定のアプリケーションと共に、サービス提示の調整を行う。ユーザ端末は、ＤＰＦとの双方向通信機構を確立して、装置の性能情報をリアルタイム更新することができる。ＤＰＦは、単なるデータベース以上のものであってよい。ＤＰＦはさらに、設定条件が上位アプリケーションの問い合わせ負荷を十分に軽減できるものである場合は、情報収集および記憶機能に加えて、上層アプリケーションの要求に従って情報のアクティブレポートを実行することができる。例えば、上位アプリケーションは、ＤＰＦにポリシーを発行し、ＤＰＦは、当該ポリシーに従って、ユーザ端末の情報を収集、構成、および報告する。

ＩＰＴＶアプリケーションは、ＩＰＴＶサービスに対して論理制御を行うためにサービスイネーブラから独立していてよく、また、サービスイネーブラを用いて具体的なサービス機能を実現することができる。ＩＰＴＶアプリケーションは、ＩＰＴＶサービスを行うために、ＳＣＦと共にＩＰＴＶ・ＡＳを構成することができる。ＩＰＴＶ・ＡＳの構造は、図１１に示す。具体的には、ＩＰＴＶアプリケーションは、ＳＩＰ・ＩＰＴＶアプリケーションおよびサードパーティアプリケーションを含んでいてもよい。ＳＩＰ・ＩＰＴＶアプリケーションおよびＳＣＦは、ＳＩＰ・ＩＰＴＶ・ＡＳを構成し、これらの間のインターフェースは、内部インターフェース（例えばＩＳＣ）である。ＳＩＰ・ＩＰＴＶアプリケーションおよびＳＣＦは、ＩＰＴＶサービスの基本的なサービスを行うために、ＳＩＰを介して双方向通信することができる。一般的には、ＳＩＰ・ＩＰＴＶ・ＡＳは、ＩＰＴＶシステムの一部であると見なすことができる。上記サードパーティアプリケーションおよびＳＣＦは、これらの間のインターフェースとして、ＡＰＩと共にサードパーティＡＳを構成する。上記サードパーティアプリケーションは、ＳＣＦによって提供されるＡＰＩによって、ＩＭＳと双方向通信することができる。上記サードパーティアプリケーションはまた、ＡＰＩを介してＳＣＦ機能を呼び出し、サードパーティＩＰＴＶ付加価値サービスを行うことができる。

上述した全ての実施形態では、ＭＲＦＣの機能の全部または一部は、ＭＲＦＣの機能エンティティから独立して実現することができ、また、そのような機能エンティティおよびＭＲＦＣは、一般的にはメディアリソース制御機能エンティティと称されることに留意されたい。同様に、ＭＲＦＰの機能の全部または一部は、ＭＲＦＰの機能エンティティから独立して行うことができ、また、そのような機能エンティティおよびＭＲＦＰは、一般的にはメディアリソース配送処理機能エンティティと称される。

本発明の実施形態では、ＡＳにおいて様々なサービス論理を実行することによって、ＵＥに対して豊かなサービスを提供することができる。これらのサービスは、基本的なストリーミングメディアサービス、様々な付加価値サービス、およびストリーミングメディアと組み合わせた個別のサービスを含んでいる。一方、これら全てのサービスの処理機構（例えば、セッション制御、ルーティング、サービストリガ、ユーザ認証、管理方法、課金、サービス品質の保証、およびマルチキャスティング制御）は同一である。

本発明の実施形態に係るストリーミングメディアネットワークシステムは、プログラムコンテンツを効果的に管理することができ、所定のポリシーに従ってコンテンツを配信することができ、そして当該コンテンツを安全にＵＥへ転送することができる。一方、ＵＥは、直観的な番組のインタラクションによって、ストリーミングメディアサービスを享受することができる。本発明の実施形態に係るストリーミングメディアネットワークシステムは、既存のＩＭＳネットワークアーキテクチャに基づいてストリーミングメディアサービスを提供し、また、ＩＭＳネットワークアーキテクチャの発展した機能（例えば、ユーザ管理、認証、課金、セッションルーティング、およびサービストリガ）を共有し、これによってキャリアの運用コストを低減することができる。さらに、本発明の実施形態は、ＩＭＳネットワークアーキテクチャのセッションの集中制御下において、リアルタイムセッション型サービスとテレビ型サービスとが組み合わされた、より豊かなマルチメディアサービスを提供することができる。これは例えば、電話で友人を招いて、注文したテレビ番組を一緒に鑑賞し、鑑賞中に番組の制御操作（例えば、リアルタイムコメント、一時停止、および再生）を行うことなどである。

既存のＩＰＴＶネットワークアーキテクチャの略概図である。 既存のＩＭＳネットワークアーキテクチャの略概図である。 本発明の第１の実施形態に係るストリーミングメディアネットワークシステムの略概図である。 本発明の第２の実施形態に係るストリーミングメディアネットワークシステムの略概図である。 本発明の第３の実施形態に係るストリーミングメディアネットワークシステムの略概図である。 本発明の第１の実施形態に係るストリーミングメディアサービス実現方法のフローチャートである。 本発明の第２の実施形態に係るストリーミングメディアサービス実現方法のフローチャートである。 本発明に係るストリーミングメディアサービス実現方法の第３の実施形態のフローチャートである。 本発明の第４の実施形態に係るストリーミングメディアネットワークシステムの略概図である。 図９のＳＣＦがＩＰＴＶアプリケーションによって使用されていることを示す略概図である。 図９のＩＰＴＶ・ＡＳの概略構成図である。

Claims (15)

1. ストリーミングメディアのサービス記述情報をユーザ端末へ供給するストリーミングメディアサービスイネーブラと、
   上記ストリーミングメディアサービスイネーブラによって供給された上記サービス記述情報に基づいて上記ユーザ端末がストリーミングメディアサービスを選択した後および上記ユーザ端末から送信されたストリーミングメディアサービス要求を受信した後に、メディアリソース要求を送信し、かつ、ストリーミングメディアコンテンツを記憶するメディアリソース配送処理機能エンティティに関する情報を取得した後、当該メディアリソース配送処理機能エンティティに関する当該情報を上記ユーザ端末に供給するアプリケーションサーバと、
   上記ストリーミングメディアコンテンツを記憶する上記メディアリソース配送処理機能エンティティに関する上記情報を、上記アプリケーションサーバから送信された上記メディアリソース要求に基づいて、上記アプリケーションサーバに供給するメディアサーバとを備え、
   さらに、メディアサーバとのインターフェースを有する、メディアリソース位置指定機能エンティティ（ＭＲＬＦ）またはメディアリソースブローカーエンティティ（ＭＲＢＦ）であって、上記メディアサーバ上の上記ストリーミングメディアコンテンツの配信情報と上記メディアサーバのステータス情報とを収集または問い合わせるとともに、上記ユーザ端末に対して上記ストリーミングメディアコンテンツを供給するメディアサーバを１台選択する、メディアリソース位置指定機能エンティティ（ＭＲＬＦ）またはメディアリソースブローカーエンティティ（ＭＲＢＦ）を、備え、
   上記メディアリソース配送処理機能エンティティは、記憶されている上記ストリーミングメディアコンテンツを上記ユーザ端末に供給するように構成されており、
   上記メディアサーバは、メディアリソース制御機能エンティティおよびメディアリソース配送処理機能エンティティを含んでおり、
   上記メディアリソース制御機能エンティティは、１つのメディアリソース配送処理機能エンティティを制御し、
   上記メディアリソース配送処理機能エンティティは、上記ストリーミングメディアコンテンツを記憶して、上記ストリーミングメディアコンテンツを上記ユーザ端末へ供給するように構成されており、
   上記メディアリソース制御機能エンティティは、上記ユーザ端末または上記アプリケーションサーバに対して、上記ストリーミングメディアコンテンツを供給するメディアリソース配送処理機能エンティティを選択することを特徴とする、ＩＰマルチメディアサブシステム（ＩＭＳ）ベースのストリーミングメディアネットワークシステム。
2. 上記ストリーミングメディアサービスイネーブラは、
   上記ストリーミングメディアコンテンツを記述するストリーミングメディアコンテンツメタ情報を取得または生成し、当該ストリーミングメディアコンテンツメタ情報を上記アプリケーションサーバへ供給するコンテンツ管理機能エンティティ（ＣＭＦ）と、
   取得された上記サービス記述情報、上記ストリーミングメディアコンテンツメタ情報、上記ユーザ端末が属するユーザのプロファイル情報、およびコンテキスト情報のうちの少なくともいずれか１つに基づいて電子番組ガイドを生成し、当該電子番組ガイドを他の機能エンティティまたはユーザ端末へ供給するサービスガイド機能エンティティ（ＳＧＦ）と、
   ストリーミングメディアコンテンツの保護に必要な鍵を生成するか、または、コンテンツプロバイダから取得された上記ストリーミングメディアコンテンツの保護に必要な上記鍵を記憶し、上記ストリーミングメディアコンテンツの保護に必要な上記鍵を他の機能エンティティまたはユーザ端末へ供給する鍵管理機能エンティティ（ＫＭＦ）と、
   上記ＫＭＦから取得された上記ストリーミングメディアコンテンツの保護に必要な上記鍵、または、サービスプロファイルサービスエンティティから取得された上記ユーザ端末が属する上記ユーザの上記プロファイル情報に基づいて、上記ストリーミングメディアコンテンツを使用するのに必要な権利オブジェクトを生成し、当該権利オブジェクトを他の機能エンティティまたはユーザ端末へ供給する権利発行機能エンティティ（ＲＩＦ）と、のうちの少なくともいずれか１つのエンティティを含んでいることを特徴とする、請求項１に記載のストリーミングメディアネットワークシステム。
3. 上記ユーザ端末が属する上記ユーザの上記プロファイル情報を上記ＳＧＦまたは上記ＲＩＦに供給するサービスプロファイルサービスエンティティをさらに含んでいることを特徴とする、請求項２に記載のストリーミングメディアネットワークシステム。
4. 上記アプリケーションサーバは、上記メディアリソース位置指定機能エンティティ（ＭＲＬＦ）を含んでいることを特徴とする、請求項１に記載のストリーミングメディアネットワークシステム。
5. 上記メディアサーバは、本ＩＭＳ領域内または他のＩＭＳ領域内のメディアサーバとＰ２Ｐによる双方向通信を行うことによって、上記ユーザ端末に対して、ストリーミングメディアコンテンツを供給するメディアサーバを１つ選択することを特徴とする、請求項１に記載のストリーミングメディアネットワークシステム。
6. 上記ストリーミングメディアサービスイネーブラは、
   ストリーミングメディアサービスに関するサービス記述情報を提供するサービス提供機能エンティティ（ＳＰＦ）と、
   ユーザ端末の性能情報を記憶または供給するデバイスプロファイル機能エンティティ（ＤＰＦ）と、
   コンテキスト情報を収集、記憶、構成、および送信するコンテキストマネージャ（ＣＭ）と、
   ストリーミングメディアコンテンツの暗号鍵および／または権利オブジェクトを生成または供給するストリーミングメディアコンテンツ保護機能エンティティ（ＣＰＦ）と、のうちの少なくともいずれか１つを含んでいることを特徴とする、請求項１に記載のストリーミングメディアネットワークシステム。
7. 上記ＳＰＦは、
   ストリーミングメディアコンテンツメタ情報を取得または生成し、当該ストリーミングメディアコンテンツメタ情報をアプリケーションサーバへ供給するコンテンツ管理機能エンティティ（ＣＭＦ）と、
   上記ストリーミングメディアサービスの配置および構成情報を供給するサービススケジューラ機能ユニット（ＳＳＦ）と、
   電子番組ガイドを生成するために必要なサービス記述情報を上記配置および構成情報から取得し、取得された当該サービス記述情報に基づいて上記電子番組ガイドを生成する番組ガイド機能ユニット（ＰＧＦ）と、
   上記サービス記述情報を供給し、上記電子番組ガイドを上記ユーザ端末へ供給するサービス発見機能ユニット（ＳＤＦ）と、のうちの少なくともいずれか１つを含んでいることを特徴とする、請求項６に記載のストリーミングメディアネットワークシステム。
8. 上記ＳＳＦは、マルチキャスティングサービスのための機能である、マルチキャスティングアドレスの割り当ておよび管理と、プログラム識別子および上記マルチキャスティングアドレスの関連付けと、上記マルチキャスティングの構築と、マルチキャスティングソースの制御と、のうち少なくともいずれか１つを提供することを特徴とする、請求項７に記載のストリーミングメディアネットワークシステム。
9. 上記ＳＳＦは、オンデマンド番組サービスのための機能である、メタデータおよびコンテンツ識別子の関連付けと、コンテンツ配信のトリガと、コンテンツ配信ポリシーの形成と、のうち少なくともいずれか１つを提供することを特徴とする、請求項８に記載のストリーミングメディアネットワークシステム。
10. 上記アプリケーションサーバは、
    ストリーミングメディアサービスを論理制御するストリーミングメディアサービスアプリケーション機能ユニットと、
    ユニキャスト／マルチキャストセッションを制御し、配送されるストリーミングメディアコンテンツを決定するサービス制御機能ユニット（ＳＣＦ）と、を含んでいることを特徴とする、請求項１に記載のストリーミングメディアネットワークシステム。
11. 上記メディアサーバはメディアリソース配送処理機能エンティティおよびメディアリソース制御機能エンティティを備え、
    上記メディアリソース制御機能エンティティは、
    上記メディアリソース配送処理機能エンティティを制御して、ストリーミングメディアコンテンツを取得するストリーミングメディアコンテンツ取得用の制御ユニットと、
    ストリーミングメディアコンテンツを配送する複数の方法の制御および変換を制御するストリーミングメディアコンテンツ配送用の制御ユニットと、
    上記メディアリソース配送処理機能エンティティを制御して、メディア形式を処理するメディア形式処理用の制御ユニットと、
    上記メディアリソース配送処理機能エンティティを制御して、ストリーミングメディアコンテンツを暗号化するストリーミングメディアコンテンツ暗号化用の制御ユニットと、
    ストリーミングメディアコンテンツ配信情報および負荷ステータスを、上記メディアリソース配送処理機能エンティティから取得する配信情報および負荷ステータス取得ユニットと、のうち少なくともいずれか１つを含んでいることを特徴とする、請求項１に記載のストリーミングメディアネットワークシステム。
12. 上記メディアリソース配送処理機能エンティティは、
    ストリーミングメディアコンテンツを取得および記憶するストリーミングメディアコンテンツ取得および記憶ユニットと、
    ストリーミングメディアコンテンツ配信情報および負荷ステータスを、メディアリソース制御機能エンティティに報告する配信情報および負荷ステータス報告ユニットと、
    メディア形式を処理するメディア形式処理ユニットと、
    特定のストリーミングメディアコンテンツ暗号鍵に基づいて上記ストリーミングメディアコンテンツを暗号化するストリーミングメディアコンテンツ暗号化ユニットと、を含んでいることを特徴とする、請求項１０に記載のストリーミングメディアネットワークシステム。
13. 上記メディアリソース制御機能エンティティは、メディアリソース機能コントローラ（ＭＲＦＣ）または当該ＭＲＦＣと独立した機能エンティティであり、
    上記メディアリソース配送処理機能エンティティは、メディアリソース機能プロセッサ（ＭＲＦＰ）または当該ＭＲＦＰと独立した機能エンティティであることを特徴とする、請求項１１に記載のストリーミングメディアネットワークシステム。
14. 事前設定されたサービス記述情報を記憶するサービス記述情報記憶ユニットおよびサービス記述情報を取得するサービス記述情報取得ユニットのいずれか一方のユニットと、
    上記サービス記述情報をユーザ端末へ供給するサービス記述情報供給ユニットと、を含んでおり、
    メディアサーバが、アプリケーションサーバから送信されるメディアリソース要求に基づいて、ストリーミングメディアコンテンツを記憶するメディアリソース配送処理機能エンティティに関する情報を上記アプリケーションサーバに供給するようになっており、
    上記ユーザ端末は、上記サービス記述情報供給ユニットによって供給される上記サービス記述情報に基づいてストリーミングメディアサービスを選択するとともに、ストリーミングメディアサービス要求を上記アプリケーションサーバに送信し、
    上記アプリケーションサーバは、上記ストリーミングメディアサービス要求を受信した後に、上記ストリーミングメディアコンテンツを記憶する上記メディアリソース配送処理機能エンティティに関する情報を上記ユーザ端末に供給し、
    ストリーミングメディアコンテンツを記憶する上記メディアリソース配送処理機能エンティティは、記憶されている上記ストリーミングメディアコンテンツを上記ユーザ端末に供給し、
    上記メディアサーバは、上記メディアサーバ上の上記ストリーミングメディアコンテンツの配信情報と上記メディアサーバのステータス情報とを問い合わせる、メディアリソース位置指定機能エンティティ（ＭＲＬＦ）またはメディアリソースブローカーエンティティ（ＭＲＢＦ）であって、上記ユーザ端末に対して上記ストリーミングメディアコンテンツを供給するメディアサーバを１つ選択する、メディアリソース位置指定機能エンティティ（ＭＲＬＦ）またはメディアリソースブローカーエンティティ（ＭＲＢＦ）とのインターフェースを有しており、
    上記メディアサーバは、メディアリソース制御機能エンティティおよびメディアリソース配送処理機能エンティティを含んでおり、
    上記メディアリソース制御機能エンティティは、１つのメディアリソース配送処理機能エンティティを制御し、
    上記メディアリソース配送処理機能エンティティは、上記ストリーミングメディアコンテンツを記憶して、上記ストリーミングメディアコンテンツを上記ユーザ端末へ供給するように構成されており、
    上記メディアリソース制御機能エンティティは、上記ユーザ端末または上記アプリケーションサーバに対して、上記ストリーミングメディアコンテンツを供給するメディアリソース配送処理機能エンティティを選択することを特徴とする、ＩＰマルチメディアサブシステム（ＩＭＳ）ベースのストリーミングメディアサービスイネーブラ。
15. ストリーミングメディアサービスイネーブラが、ユーザ端末へストリーミングメディアサービス記述情報を供給する工程と、
    上記サービス記述情報に基づいて、上記ユーザ端末がストリーミングメディアサービスを１つ選択する工程と、
    アプリケーションサーバが、上記ユーザ端末から上記ストリーミングメディアサービスの要求を受信した後にメディアリソース要求を送信する工程と、
    上記メディアリソース要求に従って、メディアサーバが、ストリーミングメディアコンテンツを記憶するメディアリソース配送処理機能エンティティに関する情報を上記アプリケーションサーバへ供給する工程と、
    上記アプリケーションサーバが、上記メディアリソース配送処理機能エンティティに関する上記情報を上記ユーザ端末へ供給する工程と、
    上記メディアリソース配送処理機能エンティティが、記憶されている上記ストリーミングメディアコンテンツを上記ユーザ端末に供給する工程と、を含み、
    上記アプリケーションサーバが上記メディアリソース要求を送信する工程は、
    上記アプリケーションサーバが、メディアサーバに関する情報をメディアリソース位置指定機能エンティティ（ＭＲＬＦ）に問い合わせる工程と、
    上記メディアリソース位置指定機能エンティティ（ＭＲＬＦ）が、少なくとも１台以上のメディアサーバの中からメディアサーバを１台選択するとともに、選択された上記メディアサーバに関する情報を上記アプリケーションサーバに返却する工程と、
    上記アプリケーションサーバが、選択された上記メディアサーバに上記メディアリソース要求を送信する工程と、を含んでおり、
    上記メディアサーバは、メディアリソース制御機能エンティティおよびメディアリソース配送処理機能エンティティを含んでおり、
    上記メディアリソース制御機能エンティティは、１つのメディアリソース配送処理機能エンティティを制御し、
    上記メディアリソース配送処理機能エンティティは、上記ストリーミングメディアコンテンツを記憶して、上記ストリーミングメディアコンテンツを上記ユーザ端末へ供給するように構成されており、
    上記メディアリソース制御機能エンティティは、上記ユーザ端末または上記アプリケーションサーバに対して、上記ストリーミングメディアコンテンツを供給するメディアリソース配送処理機能エンティティを選択することを特徴とする、ＩＰマルチメディアサブシステム（ＩＭＳ）ベースのストリーミングメディアサービス実現方法。

Images