図面 (/)

技術 メディアストリーム伝送のためのセッション制御

出願人 テレフオンアクチーボラゲットエルエムエリクソン(パブル)
発明者 ウィリグ,ヨハネスカトレイン,ダニエルハートゥンク,フランクカンプマン,マルクス
出願日 2015年7月1日 (4年0ヶ月経過) 出願番号 2015-133116
公開日 2015年12月10日 (3年7ヶ月経過) 公開番号 2015-222959
状態 特許登録済
技術分野 双方向TV,動画像配信等 計算機間の情報転送 計算機・データ通信
主要キーワード 高速ストリーム 制御レスポンス 伝送属性 品質層 ポート番 メディアパッケージ バックグラウンド情報 プロトコル識別情報
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2015年12月10日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (12)

課題

連続した複数のストリーム要素を有するメディアストリーム伝送を制御する。

解決手段

複数のストリーム要素のうちの最初の要素を示す、メディアストリームのメディア記述を取得するステップ32を有する。最初の要素を求めるリクエストが送信され34、セッションのためのセッション制御手続きが開始される36。メディアストリームは、セッション制御手続きにおけるセッションに関連付けられる38。セッションの制御ルールに従って複数のストリーム要素のうちの後続の要素の伝送が制御される40。

概要

背景

インターネット又は移動体電話ネットワークのような伝送ネットワークの1つの重要な用途は、サーバからクライアントへのメディア配信である。メディアは例えばオーディオビデオでありうる。

IP(インターネットプロトコルベースのネットワークにおけるメディア配信は様々なトランスポートプロトコルを用いうる。伝統的に、リアルタイムストリーミング及びパケットベースストリーミングUDPユーザデータグラムプロトコル)上のRTP(リアルタイムトランスポートプロトコル)が用いられるか、ファイル全体のダウンロードにTCP(トランスミッション制御プロトコル)上のHTTPハイパーテキストトランスファープロトコル)が用いられるかのいずれかであり、HTTPの大半は後での利用のためであるが、生のストリーミングのためでもある。RTPは、クライアントによって測定された利用可能なビットレートへの動的適応を可能にする。RTP及び関連する制御プロトコルであるRTSP(リアルタイムストリーミングプロトコル)の欠点は専用の複雑なサーバソフトウェアが必要なことであるのに対して、HTTPは幅広く使用されている廉価なHTTPサーバソフトウェアを用いうる。最近開発されたアダプティブHTTPストリーミング(AHS)は、両アプローチの利点を組み合わせることを目的とする。AHSは3GPP(第3世代パートナシッププロジェクト)で標準化され、オープンIPTフォーラム(OIPF)でも採用され、わずかに拡張されている。MPEG(ムービングピクチャエキスパートグループ)もAHSに関して作業を行っている。

AHSでは、コンテンツは様々なバージョンで符号化され、通常は様々なビットレートに対応する。コンテンツが例えばビデオトラック及びオーディオトラックを有するビデオであるならば、ビデオトラックは互いに異なるビットレートを有する3つのバージョンで符号化されえ、オーディオトラックは高品質ステレオバージョン及びモノラルバージョンで符号化されうる。各バージョンはさらに、数秒間のセグメントに分割される。例えば、ビデオバージョンは、それぞれが10秒間である連続した多くのセグメントに分割されうる。セグメントは、MEPGファイル形式に従ってフォーマットされてもよいし、MPEG2トランスポートストリーム形式に従ってフォーマットされてもよい。

ビデオトラック及びオーディオトラックの実際の伝送は、クライアントにより開始されるセグメントごとのダウンロードによって実行される。この手続きでは、クライアントは標準HTTPリクエストを用いてセグメントをダウンロードし、これをアンパックし、復号し、レンダリングし、その後、次のセグメントなどにも同じことを行う。クライアントは利用可能な品質バージョンに関する知識と、いわゆるメディアプレゼンテーション記述(MPD)であるメディア記述による時間を通じたセグメント分離(separation)に関する知識を有する。3GPP及びOIPFにおいて規定されるMPDフォーマットはメディアを記述する適切な情報及び属性を含むXML(拡張可能マーク付け言語符号化ファイルである。MPDは、AHSベースのメディア配信を開始するためにクライアントへ送信される最初のリソースである。3GPPで特定されるようなMPDは、様々な利用可能な品質と、これらがどのようにセグメントに編成されるかに関する情報を含む。

各セグメントは、伝送に用いられるネットワークの現在の動作状況の下で利用可能な最大速度でダウンロードされ、クライアントは自身が経験するダウンロード速度監視する。経験したダウンロード速度に基づいて、クライアントは利用可能な品質バージョンのうち最も適切なものを選択する。セグメントごとに、これは異なるバージョンであってもよく、クライアントは現在の動作状況に依存して様々な品質をダウンロードでき、それ故、属性「アダプティブ」HTTPストリーミングである。図1は原理を図示し、再生時間の関数としてコンテンツアイテムのアダプティブHTTPストリーミングのための様々なメディア表現を示す。図1の3つの表現はそれぞれ、コンテンツアイテム、すなわちストリーム高ビットレート表現、中ビットレート表現及び低ビットレート表現に対応する。表現間の滑らかな切り替えが可能なように、相異なる表現のストリームセグメントについての再生時間の最初と最後とが一致する。図1の縦軸は様々なストリーム表現のデータサイズ、例えばこれらのビットレートを示す。クライアントの実装に依存して、ストリームを見たり聞いたりする場合に過度な品質のばらつきを避けるために、例えばヒステリシスを含む表現間の切替のための高度な選択手続きが可能である。

マルチメディア通信における別の傾向は、マルチメディアセッションの開始・制御にIPマルチメディアサブシステムIMS)を使用することである。3GPPでは、IMS制御のRTPストリーミングだけでなく、IMS制御のHTTPプログレッシブダウンロードについて標準化されたソリューションが、IPメディアサブシステム(IMS)ベースのパケット交換ストリーミング(PSS)及びマルチメディアブロードキャストマルチキャストサービス(MBMS)ユーザサービス;プロトコルという名称で3GPP TS26.237V9.3.0(2010年6月)に規定されている。これらのソリューションは、課金、認証又はQoS(サービス品質予約のようなIMSにより提供される標準機能の利益を受ける。

図2は、3GPP TS26.237に規定されるようなIMS制御のHTTPプログレッシブダウンロードの場合の様々なシグナリングテップを示す。セッションは、SDPセッション記述プロトコル)情報を含むSIPセッション開始プロトコルINVITEメッセージで始まる。ダウンロードのためのHTTP URL(ユニフォームリソースロケータ)が、SIP 200OKメッセージを介して、ユーザ機器(UE)、すなわちクライアントへ配信される。さらに、HTTPプログレッシブダウンロードセッションのためのQoS予約が実行されてもよい。プログレッシブダウンロード自体はHTTPサーバへのHTTP GETコマンドを用いてUEによって開始され、HTTPサーバはそれに対して、要求されたコンテンツファイル応答する。より詳細には、以下のステップが実行される。
1.UEは、SDPオファーを含む、IM CNサブシステムへのSIP INVITEを送信することによって、プログレッシブダウンロードを開始する。
2.IM CNサブシステムは、SIP INVITEメッセージをSCFへ転送する。
3.SCFは、要求されたコンテンツへのユーザ権利を検証し、HTTP/SIPアダプタを選択し、SIP INVITEメッセージをHTTP/SIPアダプタへ転送する。
4.HTTP/SIPアダプタはHTTPサーバを選択し、HTTPサーバへ、UEのIPアドレスを含むHTTPPOSTメッセージを送信する。
5.HTTPサーバは、HTTP 200 OKレスポンスでHTTP/SIPアダプタに答える。
6.HTTP/SIPアダプタは、要求されたコンテンツファイルのダウンロードURLをSDPレスポンス内に含むSIP 200 OKアンサをSCFへ送信する。
7.SCFはSIP 200 OKをIM CNサブシステムへ転送する。
8.IM CNサブシステムはSIP 200 OKをUEへ転送する。
9.UEは、SIP 200 OKメッセージから取得されたURLへHTTPリクエストを送信する。
10.HTTPサーバはUEへのHTTPレスポンスにおいてコンテンツファイルを配信する。

例えば3GPP TS26.234トランスポートエンドツーエンドパケット交換ストリーミングサービス(PSS)、オープンIPTVフォーラム、リリース仕様書、HTTPアダプティブストリーミングドラフトV0.06(2010年6月7日)や、マイクロソフトのスムースストリーミングやアップルストリーミング(R.パントス、HTTPライブストリーミング、http://tools.ietf.org/html/draft-pantos-http-live-streaming-01を参照)のような独自のソリューションで特定される現在のAHSコンセプトは、メディアパッケージング、メディア記述及びダウンロードメカニズムを特定するに過ぎない。これらのメカニズムをリソース又はQoS予約メカニズムと組み合わせるための関連は予見されない。よって、QoS予約・制御が可能な管理システムにおいてさえも、AHSはベストエフォートで動作し、従って一般になおもアダプテーションを必要とするだろう。

概要

連続した複数のストリーム要素を有するメディアストリームの伝送を制御する。複数のストリーム要素のうちの最初の要素を示す、メディアストリームのメディア記述を取得するステップ32を有する。最初の要素を求めるリクエストが送信され34、セッションのためのセッション制御手続きが開始される36。メディアストリームは、セッション制御手続きにおけるセッションに関連付けられる38。セッションの制御ルールに従って複数のストリーム要素のうちの後続の要素の伝送が制御される40。

目的

最近開発されたアダプティブHTTPストリーミング(AHS)は、両アプローチの利点を組み合わせることを目的とする

効果

実績

技術文献被引用数
0件
牽制数
0件

この技術が所属する分野

(分野番号表示ON)※整理標準化データをもとに当社作成

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

連続した複数のストリーム要素(84)を有するメディアストリーム伝送を制御するための方法であって、‐前記複数のストリーム要素(84)のうちの最初の要素(92)を示す、前記メディアストリームのメディア記述(100)を取得するステップ(32)と、‐前記最初の要素(92)を求めるリクエストを送信するステップ(34)と、‐セッションのためのセッション制御手続きを開始するステップ(36)と、‐前記メディアストリームを前記セッション制御手続きにおける前記セッションに関連付けるステップ(38)と、‐前記セッションの制御ルールに従って前記複数のストリーム要素のうちの後続の要素(94)の伝送を制御するステップ(40)とを有することを特徴とする方法。

請求項2

前記セッション制御手続きは、‐前記メディアストリームに関連付けられたセッション制御のためのソースを示すリソースロケータを取得するステップと、‐セッション制御のための前記ソースとともに前記セッション制御手続きを開始するためのリクエストを送信するステップとを含むことを特徴とする請求項1に記載の方法。

請求項3

前記リソースロケータは、前記メディア記述(100)に含まれるか、前記メディア記述(100)に関連付けられることを特徴とする請求項2に記載の方法。

請求項4

前記メディア記述(100)は、前記セッション制御手続きにおけるセッションパラメータを特定するための少なくとも1つの情報要素を含むか、当該少なくとも1つの情報要素に関連付けられることを特徴とする請求項1乃至3の何れか1項に記載の方法。

請求項5

前記セッション制御手続きは、‐クライアント(48)により前記セッション制御手続きについてのセッション制御レスポンスを受信するステップと、‐前記セッション制御レスポンスの受信に応じて、前記複数のストリーム要素のうちの前記最初の要素又は前記後続の要素(94)を求めるリクエストを送信するステップとを含むことを特徴とする請求項1乃至4の何れか1項に記載の方法。

請求項6

前記セッション制御レスポンスは、前記セッションを特定するパラメータと、メディアソースの表示と、メディア記述とのうちの少なくとも1つを示すことを特徴とする請求項5に記載の方法。

請求項7

前記セッション制御手続きはリソース予約を含み、前記セッションを特定する前記パラメータは許可されたサービス品質を示すことを特徴とする請求項6に記載の方法。

請求項8

前記後続の要素のためのメディアソースは複数のメディアソースから選択され、前記複数のメディアソースの各メディアソースは前記セッションを特定する異なるパラメータに関連付けられることを特徴とする請求項6又は7に記載の方法。

請求項9

前記セッションを特定する前記パラメータは、前記後続の要素(94)を求めるリクエストに含まれることを特徴とする請求項6乃至8の何れか1項に記載の方法。

請求項10

前記メディア記述は複数の表現記述を含み、各表現記述は前記メディアストリームの異なる表現と、関連付けられたメディアソースとを示し、前記関連付けられたメディアソースの少なくとも1つは前記メディア記述に基づいて選択され、前記最初の要素(92)を求めるリクエストに含まれるか、前記後続の要素(94)を求めるリクエストに含まれることを特徴とする請求項1乃至9の何れか1項に記載の方法。

請求項11

メディアソースとセッション制御のためのソースとのうちの少なくとも1つは前記セッションに固有であることを特徴とする請求項1乃至10の何れか1項に記載の方法。

請求項12

前記最初の要素(92)を求めるリクエストは前記セッション制御手続きの開始前又は開始と同時に送信されることを特徴とする請求項1乃至11の何れか1項に記載の方法。

請求項13

連続した複数のストリーム要素(84)を有するメディアストリームの伝送を制御するためのメディアクライアントにおける方法であって、前記複数のストリーム要素のうちの最初の要素(92)を示す、前記メディアストリームのメディア記述(100)を取得するステップ(32)と、前記最初の要素(92)を求めるリクエストを送信するステップ(34)と、前記メディアストリームの伝送のためのセッション制御手続きを開始するステップ(36)とを有することを特徴とする方法。

請求項14

前記メディアクライアントは請求項1乃至12の何れか1項に記載された方法に適合されることを特徴とする請求項13に記載の方法。

請求項15

送信部(52)及び受信部(54)に結合される制御部(50)を備えるメディアクライアント(48)であって、前記制御部(50)は、連続した複数のストリーム要素(60)を有するメディアストリームの前記受信部(54)への伝送を制御するように適合され、前記制御部(50)は、前記複数のストリーム要素(60)のうちの最初の要素を示す、前記メディアストリームのメディア記述(62)を取得するようにさらに適合され、前記制御部(50)は、前記送信部(52)による前記最初の要素(64)を求めるリクエスト(66)の送信を開始し、前記メディアストリームの伝送のためのセッション制御手続きを開始するように適合されることを特徴とするメディアクライアント。

請求項16

前記メディアクライアントは請求項1乃至12の何れか1項に記載された方法に適合されることを特徴とする請求項15に記載のメディアクライアント。

請求項17

連続した複数のストリーム要素(84)を有するメディアストリームの伝送を、クライアントからの前記複数のストリーム要素を求めるリクエスト(86)に応じて制御する制御部(82)を有するメディアサーバ(80)であって、前記複数のストリーム要素(84)を送信するように適合された送信部(88)と、前記複数のストリーム要素(84)のうちの最初の要素(92)を求めるリクエスト(86)であって、前記最初の要素(92)を示すリクエストを受信し、前記メディアストリームの伝送のためのセッション制御手続きの結果を受信し、前記複数のストリーム要素(84)のうちの後続の要素(94)を求める別のリクエストを受信するための受信部(90)とを備え、前記制御部(82)は前記送信部(88)及び前記受信部(90)に結合され、前記セッション制御手続きの結果に基づいて前記後続の要素(94)の送信を制御するように適合されることを特徴とするメディアサーバ。

請求項18

前記送信部(88)は、前記複数のストリーム要素のうちの前記最初の要素(92)のためのメディアソースを示す、前記メディアストリームのメディア記述(100)を前記クライアント(48)へ送信するように適合されることを特徴とする請求項17に記載のメディアサーバ。

請求項19

前記制御部(102)は、複数の表現記述を有する最初のメディア記述(254)を取得するように適合され、各表現記述は前記メディアストリームの異なる表現を示し、前記制御部(102)は、前記複数の表現記述のうちの少なくとも1つと、当該少なくとも1つの表現記述のメディアソースとを削除又は変更して、変更されたメディア記述(264)を生成するようにさらに適合されることを特徴とする請求項18に記載のメディアサーバ。

請求項20

前記メディアサーバは請求項1乃至12の何れか1項に記載の方法に適合されることを特徴とする請求項17乃至19の何れか1項に記載のメディアサーバ。

請求項21

連続した複数のストリーム要素(84)を有するメディアストリームの伝送を、クライアントからの前記複数のストリーム要素を求めるリクエスト(86)に応じて制御するメディアサーバにおける方法であって、前記複数のストリーム要素のうちの最初の要素(92)を求めるリクエストであって、前記最初の要素(92)を示すリクエストを受信するステップ(110)と、前記示された最初の要素(92)を送信するステップ(112)と、前記メディアストリームの伝送のためのセッション制御手続きの結果を受信するステップ(114)と、前記複数のストリーム要素のうちの後続の要素(94)を求める別のリクエストを受信するステップ(116)と、前記セッション制御手続きの結果に基づいて前記後続の要素(94)の送信を制御するステップ(118)とを有することを特徴とする方法。

請求項22

メディアサーバからの連続した複数のストリーム要素を有するメディアストリームの伝送のためのメディアクライアントとのセッション制御手続きのための制御エンティティ(200)であって、前記メディアストリームの伝送のためのセッション制御手続きのシグナリングを受信するための受信部(202)と、前記シグナリングを終了するための制御部(206)であって、前記受信部(202)に結合され、前記メディアストリームを前記セッション制御手続きにおけるセッションに関連付けるように適合された制御部(206)とを備え、前記制御部(206)は、前記セッションの制御ルールに従って前記複数のストリーム要素のうちの後続の要素の伝送の制御を開始する命令のための送信部(218)に結合されることを特徴とする制御エンティティ。

請求項23

前記制御エンティティは、請求項1乃至12の何れか1項に記載の方法に適合されることを特徴とする請求項22に記載の制御エンティティ。

請求項24

メディアサーバからの連続した複数のストリーム要素を有するメディアストリームの伝送のために、メディアクライアントとのセッション制御手続きを実行するための制御エンティティ(200)における方法であって、前記メディアストリームの伝送のためのセッション制御手続きのシグナリングを受信するステップ(240)と、前記シグナリングを終了し、前記メディアストリームを前記セッション制御手続きにおける前記セッションに関連付けるステップ(242)と、前記セッションの制御ルールに従って、前記複数のストリーム要素のうちの後続の要素の伝送の制御を開始する命令を送信するステップ(244)とを有することを特徴とする方法。

請求項25

サーバからクライアントへメディア記述を転送するためのメディアプロキシ(250)であって、複数の表現記述を有するメディア記述(254)であって、各表現記述は前記メディアストリームの異なる表現を示す、メディア記述を前記サーバから受信するための受信部(252)と、前記複数の表現記述のうちの少なくとも1つと、当該少なくとも1つの表現記述のメディアソースとを前記メディア記述から削除するか変更することによって、前記メディア記述(254)を変更するように適合された処理部(256)と、前記変更されたメディア記述(264)を前記クライアントへ送信するための送信部(262)とを備えることを特徴とするメディアプロキシ。

請求項26

前記メディアプロキシは、請求項1乃至12の何れか1項に記載の方法に適合されることを特徴とする請求項25に記載のメディアプロキシ。

請求項27

サーバからクライアントへメディア記述を転送するためのメディアプロキシにおける方法であって、複数の表現記述を有するメディア記述であって、各表現記述は前記メディアストリームの異なる表現を示す、メディア記述を前記サーバから受信するステップ(280)と、前記複数の表現記述のうちの少なくとも1つと、当該少なくとも1つの表現記述のメディアソースとを前記メディア記述から削除するか変更することによって、前記メディア記述を変更するステップ(282)と、前記変更されたメディア記述を前記クライアントへ送信するステップ(284)とを有することを特徴とする方法。

技術分野

0001

本発明はメディアストリーム伝送を制御するための方法に関する。本発明を実施する装置及びソフトウェアプログラムも記載される。

背景技術

0002

インターネット又は移動体電話ネットワークのような伝送ネットワークの1つの重要な用途は、サーバからクライアントへのメディア配信である。メディアは例えばオーディオビデオでありうる。

0003

IP(インターネットプロトコルベースのネットワークにおけるメディア配信は様々なトランスポートプロトコルを用いうる。伝統的に、リアルタイムストリーミング及びパケットベースストリーミングUDPユーザデータグラムプロトコル)上のRTP(リアルタイムトランスポートプロトコル)が用いられるか、ファイル全体のダウンロードにTCP(トランスミッション制御プロトコル)上のHTTPハイパーテキストトランスファープロトコル)が用いられるかのいずれかであり、HTTPの大半は後での利用のためであるが、生のストリーミングのためでもある。RTPは、クライアントによって測定された利用可能なビットレートへの動的適応を可能にする。RTP及び関連する制御プロトコルであるRTSP(リアルタイムストリーミングプロトコル)の欠点は専用の複雑なサーバソフトウェアが必要なことであるのに対して、HTTPは幅広く使用されている廉価なHTTPサーバソフトウェアを用いうる。最近開発されたアダプティブHTTPストリーミング(AHS)は、両アプローチの利点を組み合わせることを目的とする。AHSは3GPP(第3世代パートナシッププロジェクト)で標準化され、オープンIPTフォーラム(OIPF)でも採用され、わずかに拡張されている。MPEG(ムービングピクチャエキスパートグループ)もAHSに関して作業を行っている。

0004

AHSでは、コンテンツは様々なバージョンで符号化され、通常は様々なビットレートに対応する。コンテンツが例えばビデオトラック及びオーディオトラックを有するビデオであるならば、ビデオトラックは互いに異なるビットレートを有する3つのバージョンで符号化されえ、オーディオトラックは高品質ステレオバージョン及びモノラルバージョンで符号化されうる。各バージョンはさらに、数秒間のセグメントに分割される。例えば、ビデオバージョンは、それぞれが10秒間である連続した多くのセグメントに分割されうる。セグメントは、MEPGファイル形式に従ってフォーマットされてもよいし、MPEG2トランスポートストリーム形式に従ってフォーマットされてもよい。

0005

ビデオトラック及びオーディオトラックの実際の伝送は、クライアントにより開始されるセグメントごとのダウンロードによって実行される。この手続きでは、クライアントは標準HTTPリクエストを用いてセグメントをダウンロードし、これをアンパックし、復号し、レンダリングし、その後、次のセグメントなどにも同じことを行う。クライアントは利用可能な品質バージョンに関する知識と、いわゆるメディアプレゼンテーション記述(MPD)であるメディア記述による時間を通じたセグメント分離(separation)に関する知識を有する。3GPP及びOIPFにおいて規定されるMPDフォーマットはメディアを記述する適切な情報及び属性を含むXML(拡張可能マーク付け言語符号化ファイルである。MPDは、AHSベースのメディア配信を開始するためにクライアントへ送信される最初のリソースである。3GPPで特定されるようなMPDは、様々な利用可能な品質と、これらがどのようにセグメントに編成されるかに関する情報を含む。

0006

各セグメントは、伝送に用いられるネットワークの現在の動作状況の下で利用可能な最大速度でダウンロードされ、クライアントは自身が経験するダウンロード速度監視する。経験したダウンロード速度に基づいて、クライアントは利用可能な品質バージョンのうち最も適切なものを選択する。セグメントごとに、これは異なるバージョンであってもよく、クライアントは現在の動作状況に依存して様々な品質をダウンロードでき、それ故、属性「アダプティブ」HTTPストリーミングである。図1原理を図示し、再生時間の関数としてコンテンツアイテムのアダプティブHTTPストリーミングのための様々なメディア表現を示す。図1の3つの表現はそれぞれ、コンテンツアイテム、すなわちストリーム高ビットレート表現、中ビットレート表現及び低ビットレート表現に対応する。表現間の滑らかな切り替えが可能なように、相異なる表現のストリームセグメントについての再生時間の最初と最後とが一致する。図1縦軸は様々なストリーム表現のデータサイズ、例えばこれらのビットレートを示す。クライアントの実装に依存して、ストリームを見たり聞いたりする場合に過度な品質のばらつきを避けるために、例えばヒステリシスを含む表現間の切替のための高度な選択手続きが可能である。

0007

マルチメディア通信における別の傾向は、マルチメディアセッションの開始・制御にIPマルチメディアサブシステムIMS)を使用することである。3GPPでは、IMS制御のRTPストリーミングだけでなく、IMS制御のHTTPプログレッシブダウンロードについて標準化されたソリューションが、IPメディアサブシステム(IMS)ベースのパケット交換ストリーミング(PSS)及びマルチメディアブロードキャストマルチキャストサービス(MBMS)ユーザサービス;プロトコルという名称で3GPP TS26.237V9.3.0(2010年6月)に規定されている。これらのソリューションは、課金、認証又はQoS(サービス品質予約のようなIMSにより提供される標準機能の利益を受ける。

0008

図2は、3GPP TS26.237に規定されるようなIMS制御のHTTPプログレッシブダウンロードの場合の様々なシグナリングテップを示す。セッションは、SDPセッション記述プロトコル)情報を含むSIPセッション開始プロトコルINVITEメッセージで始まる。ダウンロードのためのHTTP URL(ユニフォームリソースロケータ)が、SIP 200OKメッセージを介して、ユーザ機器(UE)、すなわちクライアントへ配信される。さらに、HTTPプログレッシブダウンロードセッションのためのQoS予約が実行されてもよい。プログレッシブダウンロード自体はHTTPサーバへのHTTP GETコマンドを用いてUEによって開始され、HTTPサーバはそれに対して、要求されたコンテンツファイル応答する。より詳細には、以下のステップが実行される。
1.UEは、SDPオファーを含む、IM CNサブシステムへのSIP INVITEを送信することによって、プログレッシブダウンロードを開始する。
2.IM CNサブシステムは、SIP INVITEメッセージをSCFへ転送する。
3.SCFは、要求されたコンテンツへのユーザ権利を検証し、HTTP/SIPアダプタを選択し、SIP INVITEメッセージをHTTP/SIPアダプタへ転送する。
4.HTTP/SIPアダプタはHTTPサーバを選択し、HTTPサーバへ、UEのIPアドレスを含むHTTPPOSTメッセージを送信する。
5.HTTPサーバは、HTTP 200 OKレスポンスでHTTP/SIPアダプタに答える。
6.HTTP/SIPアダプタは、要求されたコンテンツファイルのダウンロードURLをSDPレスポンス内に含むSIP 200 OKアンサをSCFへ送信する。
7.SCFはSIP 200 OKをIM CNサブシステムへ転送する。
8.IM CNサブシステムはSIP 200 OKをUEへ転送する。
9.UEは、SIP 200 OKメッセージから取得されたURLへHTTPリクエストを送信する。
10.HTTPサーバはUEへのHTTPレスポンスにおいてコンテンツファイルを配信する。

0009

例えば3GPP TS26.234トランスポートエンドツーエンドパケット交換ストリーミングサービス(PSS)、オープンIPTVフォーラム、リリース仕様書、HTTPアダプティブストリーミングドラフトV0.06(2010年6月7日)や、マイクロソフトのスムースストリーミングやアップルストリーミング(R.パントス、HTTPライブストリーミング、http://tools.ietf.org/html/draft-pantos-http-live-streaming-01を参照)のような独自のソリューションで特定される現在のAHSコンセプトは、メディアパッケージング、メディア記述及びダウンロードメカニズムを特定するに過ぎない。これらのメカニズムをリソース又はQoS予約メカニズムと組み合わせるための関連は予見されない。よって、QoS予約・制御が可能な管理システムにおいてさえも、AHSはベストエフォートで動作し、従って一般になおもアダプテーションを必要とするだろう。

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

0010

本発明の目的は、メディアストリームの伝送を制御するための改良された方法及び対応する装置を提供することである。

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

0011

提案される方法は、連続した複数のストリーム要素を有するメディアストリームに関する。本方法では、メディアストリームのメディア記述が取得される。メディア記述は複数のストリーム要素のうちの最初の要素を示す。最初の要素を求めるリクエストが送信される。セッションのためのセッション制御手続きも開始される。セッション制御手続きにおいて、メディアストリームがセッションに関連付けられる。セッションの制御ルールに従って複数のストリーム要素のうちの後続の要素の伝送が制御される。

0012

連続した複数のストリーム要素を有するメディアストリームの伝送を制御するための方法は、メディアクライアントにおいても実行されうる。クライアントにおける本方法は、メディアストリームのメディア記述を取得するステップを有する。メディア記述は、複数のストリーム要素のうちの最初の要素を示す、メディアクライアントは、最初の要素を求めるリクエストを送信する。メディアクライアントはまた、メディアストリームの伝送のためのセッション制御手続きを開始する。

0013

本発明によるメディアクライアントは、送信部及び受信部に結合される制御部を備える。制御部は、受信部へのメディアストリームの伝送を制御するように適合される。メディアストリームは連続した複数のストリーム要素を有する。制御部は、メディアストリームのメディア記述を取得するようにさらに適合される。メディア記述は、複数のストリーム要素のうちの最初の要素を示す。制御部は、送信部による最初の要素を求めるリクエストの送信を開始し、メディアストリームの伝送のためのセッション制御手続きを開始するように適合される。

0014

有利なメディアサーバは、連続した複数のストリーム要素を有するメディアストリームの伝送を、クライアントからの複数のストリーム要素を求めるリクエストに応じて制御する制御部を有する。メディアサーバはまた、複数のストリーム要素を送信するように適合された送信部を有する。メディアサーバはさらに、複数のストリーム要素のうちの最初の要素を求めるリクエストであって、最初の要素を示すリクエストを受信するための受信部を有する。受信部はまた、メディアストリームの伝送のためのセッション制御手続きの結果を受信し、ストリーム要素のうちの後続の要素を求める別のリクエストを受信ように適合される。制御部は送信部及び受信部に結合され、セッション制御手続きの結果に基づいて後続の要素の送信を制御するように適合される。

0015

メディアサーバにおける方法は、連続した複数のストリーム要素を有するメディアストリームの伝送を、クライアントからの複数のストリーム要素を求めるリクエストに応じて制御する。本方法は、複数のストリーム要素のうちの最初の要素を求めるリクエストを受信するステップを有する。リクエストは最初の要素を示す。示された最初の要素が送信される。別のステップで、メディアストリームの伝送のためのセッション制御手続きの結果が受信される。複数のストリーム要素のうちの後続の要素を求める別のリクエストを受信すると、セッション制御手続きの結果に基づいて後続の要素の送信が制御される。

0016

有利な制御エンティティは、メディアサーバからの連続した複数のストリーム要素を有するメディアストリームの伝送のためのメディアクライアントとのセッション制御手続きを実行するのに適する。制御エンティティは、メディアストリームの伝送のためのセッション制御手続きのシグナリングを受信するための受信部を備える。制御部は、シグナリングを終了し、受信部に結合される。制御部はまた、メディアストリームをセッション制御手続きにおけるセッションに関連付けるように適合される。制御部は、セッションの制御ルールに従って複数のストリーム要素のうちの後続の要素の伝送の制御を開始する命令のための送信部に結合される。

0017

制御エンティティにおける方法は、メディアサーバからの連続した複数のストリーム要素を有するメディアストリームの伝送のためのメディアクライアントとのセッション制御手続きのために実行される。本方法は、メディアストリームの伝送のためのセッション制御手続きのシグナリングを受信するステップを有する。シグナリングは終了され、メディアストリームはセッション制御手続きにおけるセッションに関連付けられる。セッションの制御ルールに従って、複数のストリーム要素のうちの後続の要素の伝送の制御を開始する命令が送信される。

0018

メディアプロキシは、サーバからクライアントへメディア記述を転送するのに適する。メディアプロキシは、複数の表現記述を有するメディア記述をサーバから受信するための受信部を備える。各表現記述はメディアストリームの異なる表現を示す、制御部は、複数の表現記述のうちの少なくとも1つと、当該少なくとも1つの表現記述のメディアソースとをメディア記述から削除するか変更することによって、メディア記述を変更するように適合される。送信部は、変更されたメディア記述をクライアントへ送信するように適合される。

0019

サーバからクライアントへメディア記述を転送するためのメディアプロキシにおける方法は、複数の表現記述を有するメディア記述を前記サーバから受信するステップを有する。各表現記述はメディアストリームの異なる表現を示す。複数の表現記述のうちの少なくとも1つと、当該少なくとも1つの表現記述のメディアソースとをメディア記述から削除するか変更することによって、メディア記述が変更される。変更されたメディア記述は前記クライアントへ送信される。

0020

上述の方法はまた、例えば信号のシーケンスとして記述された、データ記憶媒体に格納されるか処理システム又は装置のメモリに読み込み可能でありうるプログラムとして実施されうる。

0021

本発明の上述の目的・機能・利点又はその他の目的・機能・利点は添付の図面で説明される実施形態の以下の詳細な説明から一層明らかになるだろう。

図面の簡単な説明

0022

メディアストリームのメディア表現を説明する図である。
IMS制御のHTTPダウンロードのシグナリング図を示す。
提案される方法のフローチャートを示す。
提案される方法に適合されたメディアクライアントを示す図である。
提案される方法に適合されたメディアサーバを示す図である。
メディアサーバで実行される方法を示す図である。
提案される方法に適合された制御エンティティを示す図である。
制御エンティティで実行される方法を示す図である。
提案される方法に適合されたメディアプロキシを示す図である。
メディアプロキシで実行される方法を示す図である。
提案される方法の実施形態についてのシグナリング図を示す。

実施例

0023

本方法は、連続した複数のストリーム要素を有するメディアストリームの伝送の制御に関する。本方法の第1実施形態が図3に示される。ストリーム要素は例えばHTTPストリーミングで用いられるもののような、例えばストリームセグメントでありうる。セグメントは様々な品質、例えば様々なメディア解像度で利用可能でありうる。ストリームは、例えばビデオトラック又はオーディオ伝送に関してもよく、様々なストリームは互いに関連付けられてもよく、例えばビデオトラックはオーディオトラックに関連付けられてもよい。ストリームは、ユーザにストリームをレンダリングするように適合された任意のユーザ機器、例えばパーソナルコンピュータ移動体電話機でありうるクライアントへ伝送されうる。

0024

本方法では、メディアストリームのメディア記述は、例えばクライアントによってダウンロードされたファイルから取得される(32)。メディア記述はメディア要素のうちの最初の要素を、例えば最初の要素が利用可能となるURIのようなメディアソースとして示す。一般に、ストリームの各要素のためのソースが個別に伝送されなければならないことを回避するために、メディアソースは、クライアントにより要素へのURIを生成するためのテンプレートによって、例えばnの関数としてストリームのn番目の要素のソースを生成するためのルールを提供することによって示されてもよい。本明細書の用語では、ストリーム要素のホストとなり(例えば、記憶し又は生成し)ストリーム要素を提供するプラットフォーム、例えばサーバ又はネットワークとは対照的に、メディアソースはストリーム要素の特定の起源を示す。従って、リクエストは、例えばIPアドレス及びポート番号でプラットフォームにアドレス指定されてもよく、例えばリクエストに含まれるHTTPGETメッセージの形式でメディアソースを含んでもよい。

0025

メディアファイルはまた、ストリームの様々な表現のうちの1つ以上の記述、例えばビデオの様々な画像解像度の表示を含んでもよい。オプションとして、例えばストリームが様々な品質で又は様々なサーバから利用可能であり、クライアントがそのうちの1つを選択できるならば、最初の要素に対して複数のメディアソースが示される。最初のストリーム要素を求めるリクエストは、例えばクライアントによって、メディアソースから最初の要素を取得するためにプラットフォームへ送信される(34)。

0026

メディアストリームの伝送のためのセッション制御手続きも、例えばクライアント又はネットワークによって開始される(36)。セッションは、クライアントと、例えばネットワークのポリシー制御要素によって行使されうる特定された伝送属性で伝送を実行するネットワークとの間の伝送コンテキストである。無線ネットワークでは、セッションは典型的にセッションを輸送する無線アクセスベアラに関連付けられる。セッション制御手続きはメディアストリームをセッションに関連付ける(38)任意の手続きであってもよく、例えばストリームのためのセッション確立であってもよいし、メディアストリームがセッションに関連付けられている既存のセッションの変更であってもよい。関連付けはストリームが伝送されるセッションを特定する。

0027

セッション制御手続きは、リクエストの送信の前に開始されてもよいし、リクエストの送信と同時に開始されてもよいし、リクエストの送信の後に開始されてもよい、実施形態では、セッション制御手続きの開始とリクエストとが本質的に同時に又は互いにわずかに前後して行われるならば有利である。従って、セッション制御手続きが終了する前にメディアストリーミングが開始されうる。

0028

ストリーム要素のうちの後続の要素、すなわちセッション制御手続きの全部の結果又は一部の終結(conclusion)の後に送信されるストリーム要素の伝送は、その後、セッションの制御ルールに従って制御されうる(40)。後続の要素は最初の要素の直後に続く必要はなく、例えばセッション制御手続きの実行時間及びストリーム要素の提示時間に依存して、両者の間に1つ以上の要素が存在する可能性がある。典型的に、制御は任意の後続のストリーム要素について実行される。少なくとも1つの制御ルールは、例えば、セッションについての特定のサービス品質、例えばビットレート、請求手続きの開始、又はユーザが対応する加入契約又は口座残高を欠いているならばセッションの遮断について規定しうる。制御はまた、ストリーミング処理の監視や、他のサービス、例えばストリームにバックグラウンド情報を提供するプッシュサービスや、例えばストリームされた映画サウンドトラック購入可能にする注文サービスとストリーミング処理との統合を含みうる。制御ルールに従う制御は、例えばゲートウェイにおいて、ストリーミングを伝送するポリシー行使ポイントによって実行されてもよく、ストリーム要素は例えば要素のパケットヘッダ内の要素におけるアドレス情報に基づいて識別されうる。

0029

実施形態では、セッション制御手続きは、メディアストリームに関連付けられたセッション制御についてのソースを示すリソースロケータを取得するステップを有する。これにより、セッション制御のついてのソースとともにセッション制御手続きを開始するためのリクエストを対応するプラットフォームへ送信できる。リソースロケータはメディア記述に含まれてもよいし、メディア記述に関連付けられてもよく、例えばメディア記述と同じメッセージで送信される。これらの場合に、両者は同時に利用可能でありうる。

0030

オプションとして、メディア記述は、セッション制御手続きにおけるセッションパラメータを特定する少なくとも1つの情報要素を有するか、これに関連付けられる。例えば、メディア記述又はメディア記述内の個別の表現は、ストリーム又はストリーム表現を伝送するために必要な帯域幅を示してもよい。パラメータは、その後、ストリームが関連付けられるセッションを確立又は変更するための要件として、例えばSDPファイルにおいて特定されうる。

0031

セッション制御手続きは、特にセッション制御手続きがクライアントによって開始されるならば、クライアントによりセッション制御手続きに対するセッション制御レスポンス、例えばSIP200OKメッセージを受信するステップを有しうる。その後、クライアントは、セッション制御レスポンスの受信に応じて、一般的に別のメディアソースを示すストリームの後続の要素又は要素群を求めるリクエストを送信してもよい。例えば、ストリームをセッションに関連付けた後に、別のソースから利用可能な、より高いストリーム品質が要求されうる。後続の要素を求めるリクエストが別のメディアソースを示すならば、これはまた、ポリシー制御のためのストリーム要素の識別を単純にしうる。別のメディアソースは、ストリーム要素の最初のソースと同じプラットフォーム、例えばサーバでホストされてもよいし、別のプラットフォームでホストされてもよい。

0032

セッション制御手続きがクライアントによってセッション制御手続きについてのセッション制御レスポンスを受信するステップを有するならば、クライアントはまた、セッション制御レスポンスの受信に応じて、例えば上述の実施形態とは異なるステップの順番で、ストリームの最初の要素を求めるリクエストを送信してもよい。この場合に、ストリーミングセッションの開始は、記載された他の実施形態と比べて遅らされてもよいが、ストリームの先頭から適切なセッションが存在することが保証されうる。これは、事前の認可なしに受信されるべきではないコンテンツの最初の要素へのアクセスを回避できる。従って、最初のストリーム要素を求めるリクエストを送信するステップは、この実施形態では、セッション制御レスポンスの受信まで遅らされ、伝送を制御するステップは、後続の要素に関連するだけでなく、最初の要素の伝送も含みうる。この場合に、セッション制御手続きについてのセッション制御レスポンス、例えばSIP200OKメッセージを有するクライアントによってのみメディア記述が取得されることが可能であり、レスポンスはまた、後述される別の情報を含みうる。メディアストリームを識別する情報が、例えばクライアントにより提供されて、セッション制御手続きで取得されうることだけが必要である。

0033

セッション制御レスポンスは、セッションを特定する1つ以上のパラメータを示しうる。これは例えば、セッションを処理又は監視することを可能にするセッション識別子でありうる。セッションを特定するパラメータはまた、セッション制御手続きがリソース予約を含むならば、許可されたサービス品質を示しうる。後続のストリーム要素についての別のメディアソースが、後続の要素のついての複数のメディアソースから選択されるならば、複数のものからの各メディアソースはセッションを特定する異なるパラメータに関連付けられうる。これにより、例えば、制御レスポンス内のパラメータに基づくダウンロードのための異なるストリーム品質又はプラットフォームの選択が可能になる。

0034

セッション制御レスポンスはまた、例えばメディアソースのURIとして、又は複数のURIを生成するためのテンプレートとして、メディアソースの表示を含みうる。このように、制御レスポンスは、例えば請求を開始するために事前のセッション制御手続きなしに個別のソースの使用が許可されないならば、例えば関連付けられたソースなしにメディア記述に示されたメディア表現についてのソースを示しうる。

0035

セッション制御レスポンスはまた、例えばメディアストリームの別の表現を有するメディア記述を含みうる。含まれるメディア記述が以前に受信したバージョンから更新されたならば、例えば、開始された請求又はクライアント加入契約のチェックに基づいて事前のセッション制御手続きによりストリームへのアクセスが一般的に許可された後に、高品質のビデオについて要求されたセッションパラメータを取得するためのセッションパラメータを変更するために、例えばQoS再交渉のような別のセッション制御手続きを、更新されたメディア記述の受信が引き起こすことが可能である。

0036

セッションを特定するパラメータはまた、後続の要素を求めるリクエストに含まれうる。これにより、例えば、クライアントが別のメディアソースからのメディアにアクセスすること又はセッションについての制御エンティティからのメッセージにセッションを関連付けることが許可されることを認証することをセッション識別情報が可能にする。

0037

別のメディアリソースとセッション制御のためのソースとの両方はセッションに固有であってもよく、すなわちこれらはセッションに関連付けられてもよい。例えば、別のメディアソースはセッション開始に応じて生成されてもよく、容易に推測できず、このセッションだけのためのアクセスを提供するように、無作為な又は擬似的に無作為な要素を含んでもよい。また、セッション制御についての個別のソースは、個別化されたメッセージ又はメディア記述で送信されてもよい。これにより、無許可のアクセス及びサービス妨害攻撃を回避できる。また、最初のメディアソースがメディア記述又は実施形態によってはセッションに固有であることも可能である。

0038

別の実施形態では、メディア記述は複数の表現記述を含み、各表現記述はメディアソースの異なる表現及び関連付けられたメディアソースを示す。最初のメディアソースと別のメディアソースとの両方はその後、例えばメディアストリームの様々な品質レベルを取得するために、メディア記述に基づいて選択されうる。選択されたメディアソースはその後、最初の要素を求めるリクエスト又は後続の要素を求めるリクエストに含められうる。

0039

クライアント、例えばUEは、連続した複数のストリーム要素を有するメディアストリームの伝送を制御するための方法を実行するように適合されうる。本方法に従って、クライアントは例えばリクエストに応じたメッセージで受信することによって、又は他の任意の方法によって、メディアストリームのメディア記述を取得する。メディア記述は、最初の要素が要求されうるURIのようなメディアソースとして、ストリーム要素のうちの最初の要素を示す。従って、クライアントはメディアソースからの最初のストリーム要素を求めるリクエストを、例えば関連付けられたプラットフォームへ送信する。クライアントはまた、メディアストリームの伝送のためのセッション制御手続きを開始する。最初のストリーム要素は、セッション制御手続きの終結、例えばセッション確立や、メディアストリームが関連付けられうるセッションの変更を待つことなく要求されてもよい。これに対応して、ストリーム制御の追加のオプションを提供しうるセッションの確立を待ちつつ、例えば所定のQoSを処理しつつ、例えばベストエフォート品質を有する最初の伝送が迅速に実行されうる。これは特に、ストリーム再生を開始する際にユーザ体験を向上しうる。

0040

上記の方法の側面を実行するように適合されたメディアクライアント48が図4に示される。これは、送信部52及び受信部54に結合された制御部50を備える。送信部52及び受信部54は、例えば送受信部の一部として、固定通信システム又は無線通信システム無線伝送を送受信するように適合されうる。伝送は、例えばHTTPリクエスト及びHTTPレスポンスを有するIPパケットとして送信されうる。制御部50は、例えばソフトウェアプログラムによって実施される制御ルーチンを実行する、メモリ58を有する処理システム56内に例えば実装されうる。

0041

制御部50は、連続した複数のストリーム要素60を有するメディアストリームの伝送を制御し、メディアストリームのメディア記述62を取得するように適合されうる。伝送制御は、受信部により開始された制御メッセージによって、特にメディアソースからストリーム要素を求めるリクエスト66によって、実行されうる。メディア記述は例えばメディアソースとして、ストリーム要素のうちの最初の要素64を示す。制御部50はさらに、送信部52による最初のストリーム要素を求めるリクエスト66の送信を、例えばメディアソースをホストするプラットフォームへ送信することを開始し、メディアストリームの伝送のためのセッション制御手続きを開始するように適合される。

0042

図示されるメディアクライアントはまた、受信したストリームをユーザへレンダリングするためにスクリーン70又はスピーカ72のようなハードウェアを備える。このために、クライアントは、処理システム56に実装されてもよい再生ロジック74を有する。再生ロジック74は受信部54からストリーム要素60を受信し、スクリーン70又はスピーカ72による再生のためにこれらをアンパックし復号する。制御部50はまた、再生のために必要な場合に1つ以上の別のストリーム要素60を要求し、メディア記述62内の情報及び受信したストリーム要素の監視されたデータレートに基づいてメディアストリームの表現を選択し、個別の表現について送信部52によるリクエスト66を開始するように適合される。データレートの監視は例えばストリーム要素のサイズを検出し、これらの伝送時間を測定することによって実行されうる。AHSの場合に、特定のリクエスト66は図の要素ラベルで示されるような特定のストリーム要素60に対応する。

0043

上記の方法の側面を実行するように適合されたメディアサーバ80が図5に示される。これは、クライアント、例えば図4に関して記載されたクライアントからのストリーム要素を求めるリクエスト86に応じて連続した複数のストリーム要素84を有するメディアストリームの伝送を制御するための制御部82を備える。メディアサーバ80は、クライアントへ向けてストリーム要素84を送信するための送信部88と、受信部90とを備える。送信部及び受信部は、無線伝送に適合されてもよいし、有線伝送に適合されてもよい。受信部90は、ストリーム要素のうちの最初の要素92を求めるリクエスト86を受信するように適合され、このリクエスト86は例えばURIのようなメディアソースとして最初の要素92を示す。受信部90はまた、例えばメディアストリームを伝送するネットワークの制御エンティティから、メディアストリームの伝送のためのセッション制御手続きの結果を受信し、これを制御部82に転送するように適合される。

0044

受信部90は、ストリーム要素のうちの後続する要素94を求める別のリクエストを受信するようにさらに適合される。別のリクエストは、後続する要素の別のメディアソースをさらに有しうる。AHSの場合に、特定のリクエスト86は、図の要素ラベルによって示されるような特定のストリーム要素84に対応する。

0045

制御部82は送信部88及び受信部90に結合され、成功したセッション制御手続きの結果に基づいて後続するストリーム要素94の送信を制御するように適合される。例えば、セッション制御手続きの確認が受信されるならば送信が実行されてもよく、確認が取得されないならば送信が遮断されてもよい。また、制御部82が、結果に基づいてストリーム要素の特定の表現への、例えば高解像度ビデオのセグメントへのアクセスを許可又は遮断するか、要求されたものとは異なる表現、例えば低品質表現を返すことも可能である。複数の別のオプションが考えられる。

0046

メディアサーバ80は典型的に、メモリ98に格納された情報に基づいて、又は別の受信部106を介して又は高位プロトコルレイヤから受信した情報に基づいて、伝送のためにストリーム要素84を符号化するストリーム生成部86も備える。移動体電話のカメラ又はマイクロフォンで記録されたコンテンツをストリーミングする場合にメディアサーバ自体がユーザ機器である場合もある。

0047

メディアサーバ80の実施形態では、送信部88は、メディアストリームのメディア記述100をクライアントへ送信するように適合される。メディア記述100の伝送は、図示されないクライアントからのリクエストによっても開始されうる。メディア記述100は、ストリーム要素のうちの最初の要素92のためのメディアソースを示し、場合によっては後続するストリーム要素94の別のメディアソースも示す。

0048

この実施形態では、処理部102は、それぞれがメディアストリームの異なる表現を示す複数の表現記述と、場合によっては関連付けられたメディアソースの表示とを有する最初のメディア記述を例えばメモリ98から取得するように適合されうる。処理部102は、伝送のためのメディア記述100を特定するために、最初のメディア記述から表現記述のうちの少なくとも1つを削除するようにさらに適合されうる。処理部はまた、表現記述を、例えばクライアントによる選択を回避する値に変更しうる。ソース表示が存在するならば、例えば高品質ソースを低品質ソースに置き換えるために、これが削除又は変更されうる。オプションとして、関連付けられたソースを入手せずに表現の存在に関して受信部が通知されるように、処理部は表現記述を維持しつつ、単にメディアソースを削除してもよい。同様に、関連付けられたソースを有する表現記述を単に削除する代わりに、削除された表現の代わりにタグが含められてもよく、タグは少なくとも1つの別の表現が利用可能であることをクライアントへ示す。このように、サーバは、セッション制御手続きの前に使用されうる変更されたメディア記述を生成しうる。処理部102は処理システム104の一部であってもよい。

0049

図5aは、クライアントからのストリーム要素を求めるリクエストに応じて連続した複数のストリーム要素を有するメディアストリームの伝送を制御するメディアサーバにおける対応する方法を示す。本方法は、ストリーム要素のうちの最初の要素を求めるリクエストを受信するステップ(110)で始まる。リクエストは、例えばストリーム要素を識別するメディアソースとして、最初の要素を示す。リクエストに応じて、最初の要素がクライアントへ向けて送信される(112)。本方法の任意の時点で、メディアストリームの伝送のためのセッション制御手続きの結果がメディアサーバにより受信される(114)。メディアサーバがストリーム要素のうちの後続する要素を求める別のリクエストを受信した場合に(116)、セッション制御手続きの結果に基づいて後続する要素の送信を制御しうる(118)。

0050

図6はメディアサーバ、例えば上述のサーバから連続した複数のストリーム要素を有するメディアストリームの伝送のためにメディアクライアントとのセッションを制御するための制御エンティティ200を示す。制御エンティティは例えばHTTP/SIPアダプタとして実装されうる。制御エンティティ200は、メディアストリームの伝送のためのセッション制御手続きのシグナリングメッセージ204、例えばSIPメッセージを受信するための受信部202を備える。メッセージは例えば上述のメディアクライアントによって開始され、別のネットワーク要素によって転送される。別のネットワーク要素はセッション制御手続きからセッション関連情報を取得してもよく、それ故セッションに関連する制御動作を実行又は開始できる。

0051

制御部206はシグナリングを終了する。すなわち、これはシグナリングのエンドポイントである。従って、これはシグナリングメッセージ204を処理し、送信部210によるレスポンス208の送信を開始しうる。このために、制御部206は受信部202及び送信部210に結合される。制御部206はさらに、メディアストリームをセッション制御手続きのセッションに関連付けるように適合される。例えば、制御部206はメディアストリームを伝送するために既存のセッションを選択してもよく、場合によってはこの目的のためにセッションパラメータを変更してもよく、または制御部はメディアストリームのための新たなセッションを確立してもよい。メモリ212は、セッションについての情報を格納し、読み出すことを可能にする。制御部は制御エンティティ200の処理システム214内に実装されてもよい。

0052

セッション制御手続きの結果に基づいて、制御部206は送信部218による命令216の送信を開始する。命令216は、セッションの制御ルールに従ってストリーム要素のうちの後続の要素の伝送の制御を開始し、メディアストリームを送信するメディアサーバへ、又はセッションのポリシー行使ポイントへ送信されうる。送信部218に対応する受信部220は、例えば命令216に対する確認222を受信することを可能にする。制御エンティティはまた、受信部220を介して情報を取得してもよく、この情報はクライアントへ送信されうるか、セッションパラメータ、例えばメディア記述又はメディアソースを規定するのに用いられうる。送信部218及び受信部220は、送信部210及び受信部202と同一であってもよいし、異なるエンティティであってもよく、これらは、場合によっては受信側に依存して異なるプロトコル、例えばHTTPを用いてもよい。送信部218及び受信部220はまた、命令が同一のプラットフォームで実装されるエンティティへ送信されるならば、装置の内部インタフェースに対応してもよい。

0053

メディアサーバから連続した複数のストリーム要素を有するメディアストリームの伝送のためのメディアクライアントとのセッション制御手続きを実行するための制御エンティティにおける方法は、メディアストリームの伝送のためのセッション制御手続きのシグナリングを受信するステップ(240)で始まる。制御エンティティはシグナリングを終了し(242)、メディアストリームをセッション制御手続きにおけるセッションに関連付ける。セッション制御手続きに基づいて、制御エンティティは、セッションの制御ルールに従ってストリーム要素のうちの1つ以上の後続のストリームの伝送制御を開始又は変更する命令を送信する(244)。

0054

サーバからクライアントへメディア記述を転送するためのメディアプロキシ250が図7に説明される。一般に、メディアプロキシはクライアントとサーバとの間の複数の他のメッセージ、リクエスト及びレスポンス、例えばストリーム要素及びストリーム要素を求めるリクエストも転送する。メディアプロキシ250は、複数の表現記述を有するメディア記述254をサーバから受信するための受信部252を備える。各表現記述はメディアストリームの異なる表現を示す。この例では、メディア記述254は、各表現について関連付けられたソースS1〜S3を有するメディアストリームの3つの表現R1〜R3の記述を有する。表現記述R4について示されるような、メディアソースを有しない表現の記述をメディア記述が有することも可能である。この場合に、クライアントは、表現の存在に関して通知されるが、ソースを取得する前に、例えばメディアストリームのセッションとの関連付けを行う別のステップを実行する必要がある。

0055

処理システム258の一部であってもよい処理部256はメディア記述254から表現記述及び/又は関連付けられたソースの少なくとも1つを削除又は変更することによってメディア記述を変更するように適合される。この例では、例えばクライアントがアタッチされる無線ネットワークが、要求されるデータレートをサポートしないならば、関連付けられたソースS2と一緒に表現R2の記述が削除される。表現R3について、例えば必要なサービス品質を保証するためにメディアストリームに事前のセッションセットアップ必要ならば、又は表現のために請求が実行されるならば、ソースS3だけが削除される。例えばベストエフォートベアラを用いて再生が開始可能にするために、最初のソースがクライアントに利用可能であるように、ソースS1を有する表現R1はメディア記述に残る。メモリ260は、メディア記述を変更するために必要なデータを格納し、読み出すことを可能にする。

0056

送信部262は、変更されたメディア記述264をクライアントへ向けて送信する。一般に、逆方向の対応する伝送を可能にするために送信部262に対して対応する受信部266が存在し、受信部252に対して送信部268が存在する。両方の送信部の機能が同じ物理装置によって実行されることが可能である。受信部についても同じことが当てはまる

0057

処理部256について記載されたメディア記述の変更のための処理はまた、他のエンティティ、例えばメディアサーバでも実行されうる。

0058

サーバからクライアントへメディア記述を転送するためのメディアプロキシにおける方法は、メディア記述を受信するステップ(280)を有する。メディア記述はサーバから受信され、それぞれがメディアストリームの異なる表現を示す複数の表現記述を有する。メディアプロキシは、表現記述のうちの少なくとも1つと、当該少なくとも1つの表現記述のメディアソースとをメディア記述から削除又は変更することによってメディア記述を変更する(282)。最後に、変更されたメディア記述がクライアントへ向けて送信される(284)。

0059

メディアクライアント、メディアサーバ、制御エンティティ及びメディアプロキシを含むグループのうちの任意のエンティティだけでなく、個別のエンティティで実行される各方法は、説明される任意の実施形態で用いられてもよく、それ故、各エンティティに関する方法の実施形態のこれらの側面を実施するように適合されうる。

0060

提案される方法は、例えばアダプティブHTTPストリーミングについてのIMSベースのQoS予約に用いられうる。この場合に、これは、SIPベースの制御シグナリングを有するアダプティブHTTPストリーミングを、IMS制御の基盤と統合するコンセプトを特定し、QoS、請求、認証などのIMS固有の機能をアダプティブHTTPストリーミングで可能にする。提案される統合は、IMS非対応装置へのAHS後方互換性、高速サービスセットアップ及びサービス差別化を可能にする。統合はIMS制御情報、例えばSIP URI(ユニフォームリソース識別子)をMPDに含めるというアイデアに基づく。

0061

以下では、上記の一般的なコンセプトの一部を採用する実施形態の、より詳細な技術説明が、IMS制御のAMSの観点でなされる。クライアントが任意の手段、例えばHTML内リンクとして、又はメッセージ内のリンクとして、メディアプレゼンテーション記述(MPD)ファイルのURLを取得していると想定する。図8は影響するエンティティ、例えばノードの順次相互作用を説明する。

0062

メッセージフロー関与するエンティティは、メディアクライアントの一例としてのユーザ機器(UE)、例えば移動体電話機と、例えばUEのモビリティを可能にする無線アクセスネットワークを有する移動体電話システムコアネットワークでありうるIPマルチメディアコアネットワークサブシステム(IMCNサブシステム)である。セッション制御機能(SCF)は、サービスロジックと、このようなロジックの実行をサポートするために必要な機能とを提供し、これは例えばサービスへのアクセス又はメディア機能の選択を許可又は拒否するためにユーザのサービス加入契約をチェックするセッション開始中及びセッション変更中のサービス認可を含みうる。このような機能及びこれらの起動のルールは事業者の実装に従う。制御エンティティの一例としてのHTTP/SIPアダプタはSIPシグナリングを終了し、メディアサーバの一例としてメディアのストリーミングを実行するHTTPサーバと通信する。

0063

説明される手続きの多くの実施形態では、IMCNサブシステム及びSCFは標準IMSコンポーネントでありえ、よって、メディア伝送を制御するためのルール及び要素を実装することによってのみ影響される。例えばMPD及び様々なメディア品質が様々なサーバを介して配布される場合に、2つ以上のHTTPサーバがメディアストリーミングに用いられてもよい。さらに、コンテンツ配布ネットワーク(CDN)がHTTPサーバの代わりに用いられてもよい。HTTP/SIPアダプタ及びHTTPサーバは、同じハードウェア上のコンポーネントとして実装されてもよいし、単一のソフトウェア内で実装されさえしてもよい。この場合に、2つのコンポーネント間のインタフェースは図8に示される例とは異なっていてもよく、すなわちHTTPの基づかなくてもよい。その代わりに、インタフェースはAPI(アプリケーションプログラミングインタフェース)呼び出しに基づいてもよい。

0064

図8信号フローでは、UEはMPD URL、すなわちMPDを提供するHTTPサーバへHTTPリクエスト10aを実行する。HTTPサーバは、すべての品質レベルについての、又は1つの実施形態としてネットワーク内のベストエフォート伝送に適すると考えられる品質レベルだけについての表現記述を含むMPDで応答する。HTTPレスポンス10bにおいて返されるMPDは、SIP対応端末がAHSセッションのためのセッションセットアップを要求することを可能にするSIPURIを伴う。SIP URIは、例えば標準化された新たなMPD属性として含まれてもよく、既存のMPD要素内にパッケージされてもよく、HTTPリクエストへのレスポンス10bの一部、例えば複数のHTTP又は他の要素を有するマルチパートレスポンスの一部であってもよい。

0065

これらのステップに対していくつかのオプションが存在する。
・リクエスト10aは、ネットワーク内、例えばIMCNサブシステム内に位置しうるアプリケーション層ゲートウェイALG)によって代理されうる。ALGは例えばメディアプロキシのものであり、MPDファイルを求めるリクエストをスキャンし、表現を削除し、セッションのためのQoSを要求するSIPURIを追加しうる。
・MPDにSIP URIを含める代わりに、これは別個の要素として含まれてもよく、レスポンス10bのマルチパートメッセージで輸送されてもよい。
・MPDを含むレスポンス10bはまた、後続のSIPINVITEメッセージ1についてSDPファイルを生成するためにUEが利用可能である追加の情報を含んでもよい。例えば、これはSDPメディア部分又はUEがテンプレートの可変部分の完了の後に使用しうるSDPテンプレートを構築するために用いられうるメディアに関する追加の情報であってもよい。このように、UEは、SDPメディア部分を構築するために格納された情報及びルーチンを使用するか、ポート又はメディア形式のような記入されるべき特定の情報要素を含むリクエストに対するテンプレートを受信しうる。
・SIP URIをMPDに含める代わりに、例えばリダイレクトによってSIP URIに解決されうる別のタイプのURI(例えば、HTTPURL)が含まれてもよい。

0066

ステップ10cで、IMS対応UEとIMS非対応UEとの両方がAHSセッションを開始する。これは、高速ストリーム起動時間を可能にし、例えばIM CNサブシステムへのデフォルトのベアラで、ベストエフォート接続を用いて行われうる。このように、後方互換性も可能であり、IMS非対応UEは提供されるSIPURIを無視しうる。

0067

IMS対応である装置は、AHSセッション起動と並行して、SIPINVITEメッセージ11〜13をSIP/HTTPアダプタへ送信する。INVITEは以前に通信したSIP URIを宛先とする。INVITEメッセージはSDPを含まないか、クライアントによって生成されたSDPファイルを含むか、クライアントがレスポンス10bにおけるMPDアンサとともに受信していたかもしれない記入済みのSDPテンプレートを含むかのいずれかである。

0068

SIP/HTTPアダプタ及びHTTPサーバが2つの別個のエンティティであるならば、SIP/HTTPアダプタは、元のMPDへのURL及び/又はレスポンス15で返された元のMPD自体を取得するためにHTTPサーバへHTTPリクエスト14、例えばPOSTリクエスト又はGETリクエストを発行する。「元の」という用語は、レスポンス10bに含まれるMPDが表現の一部を削除されうるが、このMPDがサーバで利用可能なメディア表現記述フィルタされていないリストを有しうることを意味する。元のMPDの情報に起因して、SIP/HTTPアダプタは、ステップ10cで既に進行中のAHSセッションに関する情報を含むSDPを含むSIp 200OKメッセージを発行できる。SIP 200 OKメッセージはステップ17、18でUEへ転送される。例えば、UE、すなわちクライアントが様々なメディア品質へのアクセスを入手する場合に、SIP 200 OKメッセージは、レスポンス10bに含まれるMPDと比較して1つ以上の追加のメディア表現を有しうる更新されたMPD URIを含みうる。更新されたMPDは元のMPDであるか、例えばSIP/HTTPアダプタ又はプロキシによって編集されたバージョンの何れかでありうる。

0069

データの伝送中に、IMCNは、オプションとしてベアラ更新を含むメディアセッションのための特定されたポリシー、例えばQoSの行使を開始する。QoS予約及びポリシー行使は、ポリシー・課金制御アーキテクチャという名称の3GPP TS23.203で規定された標準3GPPメカニズムを使用しうる。例えば、MPDからの情報やクライアントIPアドレス、ポートなどを使用して、対応するポリシー・課金制御(PCC)ルールが作成されうる。PCCルールは、ゲートウェイのようなポリシー行使ポイントが、HTTPストリーミングセッションに属するパケットを識別し優先することを可能にする。帯域幅合意を超えるパケットは輻輳を示すようにマークされてもよく、破棄されてもよい。例えばポリシー行使ポイントで詳細なパケット調査により識別されうるサーバに関係することによって、IPアドレス又はポート以外の要素を考慮するPCCルールは、HTTPサーバがキャッシュ又は複数のロケーションからコンテンツがストリーミングされうるCDNによって置き換わる場合に、説明されたメカニズムの使用を可能にする。

0070

メディアストリーミングセッションのためのポリシー行使及びQoS提供の結果として、ストリーミングクライアントは、セッションに固有であるネットワークの動作状況、例えば観察されるダウンロード速度を観察する。従って、クライアントは、対応するシグナリングを必要としない伝送監視の既存のAHSメカニズムを用いてネットワークにより提供される伝送状況に適合されうる。

0071

UEがメッセージ200 OK 18を受信し、確立したQoSを認識した後、これはオプションとしてHTTPリクエスト19a及びレスポンス19bでMPDの更新についてHTTPサーバをチェックしてもよい。HTTPサーバは、メッセージ14で受信された情報に基づいて、又はメディアストリームのセッションとの関連付けの別の確認によって、更新を提供しうる。レスポンス10bが高品質メディア表現を含まない場合に、UEはこの段階で利用可能なQoSに従ってすべての表現を有する更新されたMPDを受信する。

0072

ステップ20で、AHSの適合アルゴリズムに基づいて、UEは、任意の新たに利用可能な表現、例えば、より高い品質レベルに従って、要求されたメディア品質を適合しうる。このように、ネットワーク事業者は異なるユーザへのサービス差別化と、個別のメディア品質への要求されたQoSとの両方を提供しうる。

0073

IMS非対応装置について、ステップ20はメディア品質の更新なしに、ステップ10cの後すぐに実行される。

0074

手続きの別のオプションの機能及び実施形態が可能である。
・レスポンス10bに応じて、帯域幅属性を含むが、<InitialisationSegmentURL>または<sourceURL>要素、すなわちメディアへのリンクのようなメディアソースを含まない、例えば特定のタグを通じて、又はより多くの表現を通じて、より多くの利用可能な品質レベルの表示が与えられてもよい。
・セッションについてのSDPオファーは、UEによって、又はSIP/HTTPアダプタによって生成されうる。要求された情報、例えば送信者IPアドレス及び受信者IPアドレス、メディアトランスポートフォーマット及びポート、必要な帯域幅は、通信パス及びMPDを通じて提供される。
・メッセージ10bで、例えばサーバ又はプロキシによって、MPDからよりよい品質表現を削除することはオプションである。表現が削除されないならば、提案される手続きはサービス品質予約を可能にする。他の場合に、これは、所定のパッケージを予約したユーザ又はIMSで提供される請求を介してこれを取得できるユーザの識別情報を有するクライアントについて、サービス差別化を可能にする。
・MPDで提供されるURIは、MPD内の情報なしに容易にアクセスすることができないように、より高い品質層についてのURIを推測しづらくする個別の方法で、例えばユーザに個別化されて生成されうる。
・一部の場合に、IP 5タプル(IP-5-tuples)に基づくポリシー行使ポイントの単純なフィルタ、すなわちソースアドレス、ソースポート、宛先アドレス宛先ポート及びプロトコル識別情報を含むグループからの少なくとも1つの要素に基づいてパケットを許可又は制限するフィルタは、QoS行使、例えば、CDNからのコンテンツのストリーミングに適さない。このような場合に、PCCルールは他の情報を含んでもよい。例えば、HTTPストリーミングセッションからパケットを識別するためのQoS行使ポイントにおける詳細なパケットの調査の間に用いられうるヘッダのようなHTTP固有情報が含まれてもよい。
・HTTPサーバは、成功したSIP INVITE手続きの表示を受信した後に、所定のメディア品質、すなわち特定の表現のストリームセグメントへのアクセスだけを許可してもよい。これをチェックするために、HTTPサーバ、SIP/HTTPアダプタ及び/又はIM CNの間で追加の通信が存在してもよい。例えば、SIP/HTTPアダプタ又はHTTPサーバは、SIP INVITEの間にUEのIPアドレスを登録し、GETリクエストのソースIPが登録済みのUEに属するならばステップ10a、19aのようにHTTP GETリクエストをチェックしてもよい。

0075

特定の実施形態に依存する利点は、リソース予約メカニズムの利用可能性から利益を受け、QoS予約、制御、AHSに関連する能力を含む。集中型のソリューションはIMSクライアントと非IMSクライアントとの両方をサポートできる。実施形態の利点はまた、以下を含みうる。
・IMS QoS確立のための遅延の場合でさえも、ストリーミングの高速セットアップ
・既存の標準AHSメカニズムへの後方互換性
・IMSを介したQoSが用いられる場合に、よりよい品質を利用可能にすることによりサービス差別化対応
・ベストエフォート使用にどの品質レベルが利用可能であるべきかを決定を事業者の制御下に置く。これにより、現在の状況に起因するネットワーク使用の動的制御が可能になる。

0076

上記の実施形態は本発明の目的を見事に達成する。しかしながら、特許請求の範囲のみによって限定される本発明の範囲から逸脱せずに、当業者が逸脱を行いうることが理解されるだろう。

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

該当するデータがありません

関連する公募課題

該当するデータがありません

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

(分野番号表示ON)※整理標準化データをもとに当社作成

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

該当するデータがありません

この 技術と関連する公募課題

該当するデータがありません

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ