【文献】
Samsung Electronics Co., Ltd.,MBMS Restructuring and Profiling,3GPP TSG SA4 meeting #80 S4-140805,2014年 8月 7日,pp.1-5
【文献】
Technical Specification Group Services and System Aspects;Multimedia Broadcast/Multicast Service (MBMS);Enhanced MBMS Operation,3GPP TSG-SA WG4#81 S4-141350,2014年11月,Release 12,15ページ
(58)【調査した分野】(Int.Cl.,DB名)
前記ソケットAPIは、前記要求されたコンテンツを運搬するマルチキャストストリームのカプセル化(capsuled)されたUDP(user datagram protocol)パケット(packet)を受信し、
前記ソケットAPIを使用して前記マルチキャスト(multicast)ストリーム(stream)の受信をトリガ(trigger)するために、MBMSセッション(session)ディスクリプション(description)をMBMSクライアント(client)に伝達する過程をさらに含む、請求項1に記載の方法。
前方誤り訂正(forward error correction、FEC)フレームワーク(framework)に基づいてMBMSセッションを介して前記コンテンツに対するリソースを受信する過程をさらに含む、請求項1に記載の方法。
前記コンテンツの位置に対する要求は、前記MBMSが使用可能か否かを前記サーバが決定するために前記サーバに送信するMBMS URLを含む、請求項1に記載の方法。
前記コンテンツの位置に対する要求は、前記サーバが前記コンテンツに対するMBMS URLが解決(resolution)可能か否かを判断するために、前記サーバに送信するHTTP(hypertext transmission protocol) URLを含み、
前記コンテンツに対する前記MBMS伝達ディスクリプションは前記MBMS URLが解決された(resolved)後に受信される、請求項1に記載の方法。
前記1以上のプロセッサは、前記コンテンツに対する要求及びしきい値に基づいて、前記MBMSが前記コンテンツに対して使用可能か否かを決定するように構成される、請求項9に記載のサーバ。
前記MBMS伝達ディスクリプションは、通過されるブロードキャストマルチキャストサービスセンター(BM−SC)を介して前記コンテンツを伝達する方法を含む、請求項9に記載のサーバ。
【発明を実施するための形態】
【0014】
以下に説明する
図1乃至
図9、及び、本特許文書において本開示の原理を説明するために用いられる多様な実施形態は、単なる説明のためのものであって、本発明の範囲を制限するように解釈されるべきではない。本開示の属する技術の分野における通常の知識を有する者は、本開示の原理が任意の適切に配列されたシステム又は装置で実現されてもよいことを理解するであろう。
【0015】
大きなユーザグループに同じコンテンツを提供する直観的な方法は、全てのユーザのそれぞれに対して専用のネットワークリソースを割り当てる代わりに、ブロードキャストメカニズムを活用する方法である。TVチャンネルの配信、及び、無線による大規模ソフトウェアアップデートの配信が、ブロードキャストにより大いに恩恵を受けるサービスの例である。
【0016】
LTE(Long Term Evolution)は、MBMSを定義して費用面から最も効率的な方式でこのようなサービスの要求事項を解決した。これは、当初、2つのモード、すなわち、ブロードキャストとマルチキャストを定義した。しかし、マルチキャストモードは、ユーザ空間マルチキャストトラフィックのトンネリングの使用によって費用節減にならず中断された。
【0017】
図1は、本開示による例示的なコンピューティングシステム100を示す。
図1に示すコンピューティングシステム100の実施形態は、単なる説明のためのものである。コンピューティングシステム100の他の実施形態を、本開示の範囲から逸脱することなく使用できる。
【0018】
図1に示すように、システム100は、システム100内の多様な構成要素間の通信を容易にするネットワーク102を含む。例えば、ネットワーク102は、インターネットプロトコル(IP)パケット、フレームリレーフレーム(frame relay frames)、非同期転送モード(ATM)セル、又は、ネットワークアドレス間の他の情報を通信できる。ネットワーク102は、1以上のローカル領域ネットワーク(LAN)、メトロポリタンエリアネットワーク(MAN)、ワイドエリアネットワーク(WAN)、インターネットのようなグローバルネットワークの全部又は一部、又は、1以上の位置での任意の他の通信システム又はシステムを含んでもよい。
【0019】
ネットワーク102は、少なくとも1つのサーバ104と多様なクライアント装置106−114との間の通信を容易にする。各々のサーバ104は、1以上のクライアント装置にコンピューティングサービスを提供できる任意の適切なコンピューティング又は処理装置を含む。例えば、各サーバ104は、1以上の処理装置、命令及びデータを格納する1以上のメモリ、及び、ネットワーク102を介した通信を容易にする1以上のネットワークインタフェースを含んでもよい。
【0020】
各クライアント装置106−114は、ネットワーク102を介して少なくとも1つのサーバ又は他のコンピューティング装置と相互作用する任意の適切なコンピューティング又は処理装置である。この例において、クライアント装置106−114は、デスクトップコンピュータ106、携帯電話又はスマートフォン108、PDA(personal digital assistant)110、ラップトップコンピュータ112、及び、タブレットコンピュータ114を含む。しかし、任意の他の又は追加的なクライアント装置を、コンピューティングシステム100において使用してもよい。
【0021】
この例で、一部のクライアント装置108−114は、ネットワーク102と間接的に通信する。例えば、クライアント装置108−110は、セルラー基地局又はeNodeBのといった1以上の基地局116を介して通信する。また、クライアント装置112−114は、IEEE 802.11無線アクセスポイントといった1以上の無線アクセスポイント118を介して通信する。これらは単なる例示のためのものであって、各々のクライアント装置は、直接的に、又は、任意の適した中間装置又はネットワークを介して間接的に、ネットワーク102と通信してもよいことに留意すべきである。
【0022】
図1は、コンピューティングシステム100の一例を示すが、多様な変更が
図1に対して行われてもよい。例えば、システム100は任意の適切な構成にて任意の数の構成要素を含んでもよい。一般に、コンピューティング及び通信システムは、多様な構成を有し、
図1は、本開示の範囲を任意の特定構成に制限しない。
図1は、本特許文献に開示された多様な特徴を使用できる1つの動作環境を示すが、これらの特徴は任意の他の適したシステムで使用されてもよい。
【0023】
図2及び
図3は、本開示によるコンピューティングシステム内の例示的な装置を示す。特に、
図2は、例示的なサーバ200を示し、
図3は、例示的なクライアント装置300を示す。サーバ200は、
図1のサーバ104を示すことができ、クライアント装置300は、
図1の少なくとも1つのクライアント装置106−114を示すことができる。
【0024】
図2に示すように、サーバ200は、少なくとも1つの処理装置210、少なくとも1つの記憶装置215、少なくとも1つの通信部220及び少なくとも1つの入出力部225の間の通信をサポートするバスシステム205を含む。
【0025】
処理装置210は、メモリ230にロードされる命令を実行する。処理装置210は、任意の適切な構成で任意の適切な数及びタイプのプロセッサ又は他の装置を含んでもよい。例示的な類型の処理装置210は、マイクロプロセッサ、マイクロコントローラ、デジタル信号プロセッサ、フィールドプログラマブルゲートアレイ(FPGA)、特定用途向け集積回路、及び、ディスクリート回路(discrete circuitry)を含む。処理装置210は、認証されたウェアラブル装置により電子装置をロック解除する動作を行うように構成される。
【0026】
メモリ230及び永続性記憶装置(persistent storage)235は、情報(例えば、データ、プログラムコード、及び/又は、一時的又は永久的な他の適切な情報)を格納及び容易に取り出すことができる任意の構造物である記憶装置215の例である。メモリ230は、ランダムアクセスメモリ(RAM)又は任意の他の適切な揮発性又は不揮発性記憶装置である。永続性記憶装置235は、読み出し専用メモリ(ROM)、ハードドライブ、フラッシュメモリ、又は、光学ディスクのようにデータの長期記憶をサポートする1以上の構成要素又は装置を含んでもよい。
【0027】
通信部220は、他のシステム又は装置との通信をサポートする。例えば、通信部220は、ネットワーク102を介した通信を容易にするネットワークインタフェースカード又は無線送受信部を含んでもよい。通信部220は、任意の適切な物理的又は無線通信リンクを介した通信をサポートする。
【0028】
入出力部(input/output(I/O) unit)225は、データの入力及び出力を許容する。例えば、入出力部225は、キーボード、マウス、キーパッド、タッチスクリーン、又は他の適切な入力装置を介したユーザ入力のための接続を提供できる。また、入出力部225は、出力をディスプレイ、プリンタ又は他の適切な出力装置に送信できる。
【0029】
図2は
図1のサーバ104を示すと説明したが、同じ又は類似の構造が、1以上のクライアント装置106−114において使用されてもよいことに注意すべきである。例えば、ラップトップ又はデスクトップコンピュータは、
図2に示すものと同じ又は類似の構造を有してもよい。
【0030】
図3に示すように、クライアント装置300は、アンテナ305、無線周波数(RF)送受信部310、送信(TX)処理回路315、マイクロホン320、及び、受信(RX)処理回路325を含む。また、クライアント装置300は、スピーカ330、メインプロセッサ340、入出力(I/O)インタフェース(IF)345、キーパッド350、ディスプレイ355、及び、メモリ360を含む。メモリ360は、基本的なオペレーティングシステム(OS)プログラム361、及び、1以上のアプリケーション362を含む。
【0031】
RF送受信部310は、システムの他の構成要素によって送信される受信RF信号を、アンテナ305から受信する。RF送受信部310は、受信RF信号を中間周波数(intermediate frequency、IF)又は基底帯域信号を生成するためにダウンコンバートする。IF又は基底帯域信号は、基底帯域又はIF信号をフィルタリング、デコーディング及び/又はデジタル化することによって処理された基底帯域信号を生成する受信処理回路325に送信される。受信処理回路325は、処理された基底帯域信号(音声データなど)をスピーカ330に送信するか、又は、追加処理(ウェブブラウジングデータなど)のためにメインプロセッサ340に送信する。
【0032】
送信処理回路315は、マイクロホン320からアナログ又はデジタル音声データを受信し、メインプロセッサ340から他の発信基底帯域データ(ウェブデータ、電子メール、又は両方向ビデオゲームデータ)を受信する。送信処理回路315は、処理された基底帯域又はIF信号を生成するために発信基底帯域データを、エンコーディング、多重化、及び/又はデジタル化する。RF送受信部310は、発信処理された基底帯域又はIF信号を送信処理回路315から受信し、基底帯域又はIF信号を、アンテナ305を介して送信されるRF信号にアップコンバートする。
【0033】
メインプロセッサ340は、1以上のプロセッサ又は他の処理装置を含んでもよく、クライアント装置300の全体動作を制御するために、メモリ360に格納された基本的なOSプログラム361を実行できる。例えば、メインプロセッサ340は、周知の原理に従って、RF送受信部310、受信処理回路325、及び、送信処理回路315による順方向チャネル信号の受信、及び、逆方向チャネル信号の送信を制御できる。一部の実施形態において、メインプロセッサ340は、少なくとも1つのマイクロプロセッサ又はマイクロコントローラを含む。
【0034】
また、メインプロセッサ340は、MBMSに基づくフレキシブルブロードキャストサービスのための動作のような、他のプロセッサ及びメモリ360に常駐するプログラムを実行できる。メインプロセッサ340は、実行プロセスからの要求に従って、データを、メモリ360内又は外に移動できる。一部の実施形態において、メインプロセッサ340は、OSプログラム361に基づいて、又は、外部装置又はオペレータから受信された信号に応じて、アプリケーション362を実行するように構成される。また、メインプロセッサ340は、クライアント装置300にノートブック及び携帯用コンピュータのような他の装置を接続することを可能とする入出力インタフェース345に結合されている。入出力インタフェース345は、このようなアクセサリとメインプロセッサ340との間の通信経路である。
【0035】
また、メインプロセッサ340は、キーパッド350及びディスプレイ355に結合されている。クライアント装置300のオペレータは、クライアント装置300にデータを入力するためにキーパッド350を使用できる。ディスプレイ355は、液晶ディスプレイ、又は、ウェブサイトからのテキスト及び/又は少なくとも制限されたグラフィックをレンダリング可能なディスプレイであってもよい。
【0036】
メモリ360は、メインプロセッサ340に結合されている。メモリ360の一部はRAMを含んでもよく、メモリ360の他の部分はフラッシュメモリ又はROMを含んでもよい。
【0037】
図2及び
図3は、コンピューティングシステム内の装置の例を示すが、
図2及び
図3に多様な変更が行われてもよい。例えば、
図2及び
図3の多様な構成は、組み合わせたり、細分化したり、省略されてもよく、追加的な構成が特定のニーズに従って追加されてもよい。特定例として、メインプロセッサ340は、1以上の中央処理ユニット(CPU)、及び、1以上のグラフィック処理ユニット(GPU)のような多重プロセッサに分けられてもよい。また、
図3は、携帯電話及びスマートフォンで構成されたクライアント装置300を示すが、クライアント装置は、他の類型のモバイル又は固定装置として構成されてもよい。また、コンピューティング及び通信ネットワークと同様に、クライアント装置及びサーバは、多様な構成を有してもよく、
図2及び
図3は、本開示を、任意の特定クライアント装置又はサーバに限定しない。
【0038】
図4は、ユーザサービス405、伝達方法410、及び、ベアラ(bearer)サービス415間の関係についての例示的な参照モデル400を示す。
図5は、本開示の多様な実施形態によるプロトコルスタック500の例を示す。
図4に示す参照モデル400、及び、
図5のプロトコルスタック500の実施形態は、単なる説明のためのものである。
図4及び
図5は、本開示の範囲を電子装置の任意の特定の実施形態に制限しない。
【0039】
LTEのためのMBMS(eMBMS)は、無線インタフェース上のブロードキャストサポート、ゲートウェイと基地局との間のIPパケット送信のためのIPマルチキャストの使用、及び、MBMSセッションの設定と維持のための特定の手順(procedure)に依存する。MBMSソリューションの重要な構成要素は、MBMSユーザサービス405及びMBMSベアラサービス415である。MBMSベアラサービス415は、モバイルネットワーク及びユーザ装置(UE)において、特定の機能セットを提供するポイント−トゥー−マルチポインティングコンテンツ配布チャネル(point−to−multi−pointing content distribution channel)である。MBMSアーキテクチャの重要なネットワーク要素は、MBMSユーザサービスを構築し、MBMSユーザベアラを生成し、MBMS及び他の機能(セキュリティ、サービス告知、関連伝達過程等)を介してメディア伝達を行うブロードキャストマルチキャストサービスセンター(BM−SC)である。
【0040】
MBMSユーザサービス405は、UEにコンテンツを伝達するためのツールセットのインスタンス化(instantiation)である。これは、1以上の伝達方法、サービスディスクリプション、及び、サービス告知手順、関連伝達手順、セキュリティ及び報告ツールにて構成される。
【0041】
現在、ストリーミング420、ダウンロード425、及び、グループ通信430と定義された3つの異なる伝達方法410が存在する。ストリーミング420は、モバイルTVサービスを提供するためにMBMS Release 6の一部として設計された。ストリーミング420は、メディアデータ伝達のためにRTP(real−time transport protocol)/RTCP(RTP control protocol)プロトコル505に依存し、多数のメディアストリームの保護を共にサポートする前方誤り訂正(forward error correction、FEC)フレームワークを定義する。ダウンロード425伝達方法は、ファイルをUEに信頼可能に伝達する機能を提供する。UEは、FECビルディングブロック(building block)だけでなく、HTTPを介したFLUTE(file delivery over unidirectional transport)プロトコル510に基づくファイル伝達を使用してサービスの信頼性を向上させる。HTTPを介したストリーミングメディアの登場と共に、ストリーミング420伝達方法の価値は、RTP/RTCP505を使用するストリーミングサーバの維持が非常に複雑であるため、著しく減少した。その代わりに、ダウンロード425伝達方法が、FLUTE510を介したHTTPストリーミングコンテンツ伝達をサポートするために若干拡張された。
【0042】
MBMSの伝達方法として追加された3番目の最新の伝達方法は、グループ通信(GC)430伝達方法である。他の2つの方法で提供されるものに比べて高い柔軟性を要求する公共安全サービス及びその他サービスの要求を解決するために、GC430伝達方法が追加された。例えば、サービスは、ダウンロード425及びストリーミング420伝達方法によって定義されたものと異なるプロトコル、フォーマット、及び、サービス告知手順を使用することを希望する場合がある。例えば、ストリーミング420サービス提供者は、FCASTプロトコルを介してHLSフォーマットされたメディアデータを伝達することを希望する場合がある。この場合、ダウンロード425伝達方法は、フォーマット及びプロトコルをサポートしないため、ダウンロード425伝達方法は使用できない。さらに別の例は、非常に低い遅延チャネルを介して暗号化された音声データを送信しようとする公共安全サービスである。BM−SCがサービス提供者の代わりに暗号化を行わなければならず、例えば、FECフレームワークが誘発する遅延がサービス提供者に受け入れられないため、ストリーミング方法はこの場合には適合しない。
【0043】
ファイルダウンロードプロファイルは、オフライン型伝達モードを使用してファイルを伝達するために用いられるよう設計されている。ファイルは、通常予約された時間にBM−SCによって入れられ、ユーザ装置(UE)のアプリケーションにより後ほど使用するためにローカルにキャッシュされる。ファイルダウンロードプロファイルは、“urn:3gpp:mbms:download:2015”といったURI(uniform resource identifier)により識別される。URIは、MBMSユーザサービス説明メタデータフラグメントを運搬するMBMSメタデータエンベロープの一部として提供される。
【0044】
ダウンロードセッション告知の使用は次のうちの1つの方法で提供される:
1.OTA(over the air)−HTTPプッシュベアラは、MBMS USD(user service description)メタデータフラグメントを含む単一メタデータ項目(item)を含むメタデータエンベロープだけを伝達すべきである。ユーザサービスに関心があるUEは、HTTPを使用して全ての参照されたフラグメントを要求すべきである。
【0045】
2.MBMSベアラサービスの設定を、必要に応じて予め構成されたサービス領域を介してトリガするあらかじめ構成されたMBMSユーザサービス。
【0046】
3.MBMSは、オペレータがMBMSによってサービスすると決定した人気のあるコンテンツに対する要求の応答として、オンデマンド(on−demand)で活性化される。
【0047】
USDには次のようなメタデータフラグメントが含まれる:
1.ちょうど1つのassociatedProcedureDescriptionURIを含む、ちょうど1つの伝達方法を含むべきユーザサービス説明メタデータフラグメント。
【0048】
2.associatedProcedureDescriptionフラグメントは、バイト範囲(byte range)の修復をサポートする1つのpostFileRepair要素を含むべきである。
【0049】
3.トランスポートレベルセキュリティのためのprotectionDescriptionは提供されてはならず、コンテンツは、OMA(Open Mobile Alliance)−DRM(digital rights media)のようなコンテンツ保護ソリューションを使用して保護されるべきである。
【0050】
4.スケジュールフラグメントは、各リソースに対する伝送時間を表すために提供されてもよい。スケジュールフラグメントは、OTA−PUSHによって告知されたMBMSサービスに対して存在するべきである。
【0051】
伝達機能は、トランスポートプロトコルとしてFLUTE510を使用する。FLUTEセッションは、1つのみである。
【0052】
また、ユニキャストを介したセッションコンテンツ伝達は、このプロファイルにおいてサポートされない。アップデートされたサービス維持がサポートされるべきである。
【0053】
このプロファイルと互換性のあるUEは、要求に応じてMBMSをサポートするべきである。ユニキャストを介したファイルの受信は、要求されたリソースの受信のためにMBMSにリダイレクト(redirect)されてもよい。UEは、伝達遅延を考慮すべきである。
【0054】
HTTP動的適応ストリーミング(DASH)プロファイル515
DASHプロファイル515は、ハイブリッドユニキャスト/ブロードキャストチャネルを介したDASHコンテンツ伝達のために特別に定義されたプロファイルである。DASHプレゼンテーションは、表現の集合にて構成される。そのうち一部の表現は、ブロードキャスト(主にメインオーディオ及びビデオ表現)を介して伝達され、その他補完的又は代替的な表現は、ユニキャストを介して伝達される。DASHプロファイルは、“urn:3gpp:mbms:dash:2015”とのURIにより識別される。
【0055】
MBMSによるDASHに対するサービス告知は、次のうちの1つの方法で提供される。MBMSメタデータエンベロープを運搬する専用のあらかじめ構成されたMBMSチャネル。実際のMBMSユーザサービスの位置を説明するMPD(Media Presentation Description)及びSDP(Session Description Protocol)ファイルは、同じ告知チャネルを介して伝達されるべきである。他のメタデータフラグメントは、DASHコンテンツを運搬するブロードキャストチャネルを介して伝達されてもよく、ユニキャストを介してフェッチされてもよい。
【0056】
サービス告知には次のようなメタデータフラグメントが含まれる。
【0057】
少なくとも1つの伝達方法を含むUSDメタデータフラグメント。associated−DeliveryProcedureURI又はprotectionDescriptionURIは存在してはならない。フラグメントは、appServiceDescriptionURIのMPDを参照する1つのappService要素を含むべきである。開始部分は、相応する表現を伴うブロードキャストチャネルを介して分配されるべきである。
【0058】
伝達機能は、トランスポートプロトコルとしてFLUTE510を使用する。複数のFLUTEセッションがコンテンツ伝達のために用いられてもよく、ブロードキャスト表現のコンテンツは、1つのFLUTEセッションのみを介して伝達される。ユニキャスト代替サービスがサポートされる。
【0059】
ベアラプロファイル415
ベアラ415プロファイルは、最小限のデータ及び制御平面要素にてMBMSベアラサービスの使用を許容する最小限のユーザサービスを定義する。したがって、MBMS伝達を使用するアプリケーションにより多くの柔軟性を提供できる。ベアラ415プロファイルは、MBMSミドルウェアにおいていかなる付加的な処理遅延を発生することなく、UEが与えられたマルチキャストアドレスに転送されたUDP(user datagram protocol)データグラムを受信できるようにする。
【0060】
ベアラプロファイルのサービス告知は次のように制限される:
サービス告知は、2つのメタデータフラグメント(USDメタデータフラグメントとSDPフラグメントのみ)で構成される。SDPフラグメントは、USDフラグメントによって参照されるべきであって、挿入されてはならない。deliveryMethod要素は、sessionDescriptionURI要素のみを含むべきである。
【0061】
サービス告知は、次のうち1つ方法で伝達される。MBMSアドレス解決(resolution)要求に対する応答として、専用インタフェースを介して送信アプリケーションによってUEに直接提供される。ベアラプロファイルによって使用された伝達機能は、マルチキャストアドレスに伝達されたUDPデータグラムに対するアクセスを提供すべきである。マルチキャストストリームの受信は、例えば、グループ通信イネーブラのGC1インタフェースを使用して、UEによって受信された外部シグナリングを介してトリガされてもよい。
【0062】
より高い柔軟性のために、このプロファイルには、追加的な伝送機能が提供されない。このプロファイルは、例えば、MBMS上でSIP(session initiation protocol)及びRTPを使用してグループ通信サービスを実現できるようにする。SDPは、アプリケーションによって使用されるトランスポートプロトコル及び構成に対する詳細な情報を提供する。
【0063】
図6及び
図7は、本開示の多様な実施形態によってMBMS URLを解決するための例示的なフローチャート600及び700を示す。例えば、
図6及び
図7に示すプロセスは、
図2のサーバ200又は
図3のクライアント装置300によって行われてもよい。
【0064】
過程605にて、UE601は、ネームサーバ602を用いてMBMS URLを解決する。UE601は、サーバからコンテンツを要求する。例えば、ユーザは、クライアント装置300上で視聴するビデオを選択し、クライアント装置300は、ビデオに対する要求を、サーバ200に送信する。サーバ200は、当該要求を受信し、ビデオに対する要求を決定する。サーバ200は、ビデオに対する要求がしきい値より大きい場合、ビデオに対する高い要求を決定し、ビデオに対する要求がしきい値より小さい場合は、低い要求を決定する。しきい値は、サーバの容量、要求の予め決定された数等で決定できる。ビデオに対する要求は、類似した製作者が製作したシリーズ物の以前のビデオの過去データに基づいてもよい。
【0065】
過程610にて、ネームサーバ602は、MBMSディスクリプションをUE601に伝達するか、又は、UE601をHTTP URLにリダイレクトする。コンテンツが高い要求を有する時、サーバ200は、MBMS伝達ディスクリプションをクライアント装置300に送信する。サーバ200がコンテンツに対する要求が低いと判断した場合、サーバ200は、HTTP URLにクライアント装置300をリダイレクトする。MBMS伝達ディスクリプションは、アプリケーションプログラミングインタフェース(API)に従ってBM−SCからコンテンツにアクセスするための情報を含む。ファイル伝達APIがMBMS伝達ディスクリプションを提供する時、受信されたMBMS伝達ディスクリプションは、ファイルがUE601にて使用可能になる時間フレームを有するブロードキャストファイルを含む。DASH APIが伝達ディスクリプションを提供する時、受信されたMBMS伝達ディスクリプションは、コンテンツに対する初期化部分を有するオブジェクトフローのオブジェクト及びコンテンツの部分を一致させる規則を含む。ソケットAPIがMBMS伝達ディスクリプションを提供する時、受信されたMBMS伝達ディスクリプションは、特定マルチキャストアドレスを含むセッションディスクリプションプロトコル(session description protocol)を有するソケットオブジェクトを含む。過程615にて、UE601は、MBMSセッションに参加する。
【0066】
過程620にて、UE601は、BM−SC603から、MBMSによるリソースを受信する。クライアント装置300は、ソースからBM−SCを介してリソースを受信する。リソースは、BM−SCがデータを生成することなく、BM−SCを通過する。
【0067】
過程705にて、UE701は、プロキシサーバ702にHTTP URLを要求する。クライアント装置300は、サーバ200にコンテンツを要求する。サーバ200は、クライアント装置300によって要求されたコンテンツをMBMSが使用可能であるかを決定する。MBMSが使用可能でないと決定した場合、サーバ200は、クライアント装置がコンテンツを受信するためのHTTP URLを送信する(図示せず)。
【0068】
過程710にて、プロキシサーバ702は、UE701をMBMS URLにリダイレクトする。MBMSが使用可能であると決定した場合、サーバ200は、クライアント装置300をMBMS URLにリダイレクトする。
【0069】
過程715にて、UE701は、ネームサーバ703を用いてMBMS URLを解決する。クライアント装置300は、MBMS URLをサーバ200に送信する。サーバ200は、MBMS URLに基づいてMBMS伝達ディスクリプションを決定する。
【0070】
過程720にて、ネームサーバ703は、MBMSディスクリプションをUE701に伝達する。サーバ200は、コンテンツを受信するためにクライアント装置300にMBMS伝達ディスクリプションを送信する。MBMS伝達ディスクリプションは、APIによってBM−SCからコンテンツにアクセスするための情報を含む。ファイル伝達APIがMBMS伝達ディスクリプションを提供する時、受信されたMBMS伝達ディスクリプションは、ファイルがUE601に使用可能になる時間フレームを有するブロードキャストファイルを含む。DASH APIが伝達ディスクリプションを提供する時、受信されたMBMS伝達ディスクリプションは、コンテンツに対する初期化部分を有するオブジェクトフローのオブジェクト及びコンテンツの部分を一致させる規則を含む。ソケットAPIがMBMS伝達ディスクリプションを提供する時、受信されたMBMS伝達ディスクリプションは、特定マルチキャストアドレスを含むセッションディスクリプションプロトコルを有するソケットオブジェクトを含む。過程725にて、UE701は、MBMSセッションに参加する。
【0071】
過程730にて、UE701は、BM−SC704からMBMSによるリソースを受信する。クライアント装置300は、ソースからBM−SCを介してリソースを受信する。リソースは、BM−SCがデータを生成することなく、BM−SCを通過する。
【0072】
MBMS URIスキームは、この仕様において、MBMSによって伝達されるか、又は、MBMSによって潜在的に使用可能になり得るリソース及びストリームへのアクセスを単純化するために定義される。UE601は、MBMS URIスキームを使用する全てのリソース要求を受信するために、MBMSミドルウェアをMBMSプロトコルハンドラに登録する。
【0073】
“MBMS”URIは、次のようなABNF(augmented backus−naur form)シンタックスを有する:
scheme=“mbms”“:”host[“:”port]“/”path
<host>及び<port>はRFC3986に指定されている。
【0074】
“MBMS”URIスキームは、MBMSによって伝達されてもよいリソース又はデータストリームを参照するために用いられる。MBMS URIは、
図6及び
図7で定義された手順を用いて、MBMSプロトコルハンドラによって解決されるべきである。リソース又はストリームがMBMSによって伝達されなかった場合、UE601はユニキャスト伝達代替にリダイレクトされる。
【0075】
アドレス解決手順は、次のステップに構成される:
受信されたMBMS URLを用いて、MBMSプロトコルハンドラを起動する。MBMSプロトコルハンドラは、“URL”の名前を有するNVP(network voice protocol)の値としてのMBMS URLを用いて、あらかじめ構成されたMBMSアドレス解決サーバ(ARS)にPOSTリクエストを送信する。MBMS ARSは、MBMSメタデータエンベロープで応答する。その代案として、MBMS ARSは、UE601を要求されたリソースのユニキャスト位置にリダイレクトする。
【0076】
URLが単一リソースを参照する場合、MBMS URLとFLUTE URL間のマッピングは暗黙的(すなわち、MBMS体系をhttpスキームに置き換える)であるか、アドレス解決応答の一部として明示的に提供されてもよい。また、他の関連リソースもMBMSによって使用できるというクライアントに対するARSの指示子(indication)が、応答の一部として含まれる場合がある。SDPは、UTC(Coordinated Universal Time)時間に提供された伝送に対する時間情報を伝達すべきである。また、スケジュールメタデータフラグメントは、特定リソースの伝達時間を指定するために提供されてもよい。
【0077】
ファイル伝達APIは、MBMSによってファイルを要求して受信するためのクライアント機能を提供するAPIを定義する。APIはリソースを要求し、要求されたファイルの状態に対するイベントを受信し、MBMSによって伝達されたファイルにアクセスする機能を提供するBroadcastFileオブジェクトを定義する。
【0078】
BroadcastFileオブジェクトは、リソースのMBMS URLを取得する方法を提供する。BroadcastFileオブジェクトは、次のような作業を行う:
BroadcastFileオブジェクトは、MBMS URLを解決して、ユニキャスト又はブロードキャストを介して伝達が行われているか否かを決定する。伝達がユニキャストを介して行われると、応答にはユニキャストアドレスへのリダイレクトが含まれるべきである。伝達がブロードキャストを介して行われる場合、応答はファイルがUE601で使用可能になる時間フレームの指示子を含むべきである。ファイルが既に受信された場合、応答は、UE601上のファイルのローカル位置に対するURLを含むべきである。
【0079】
BroadcastFileは次のイベントを定義する:
ファイル受信が進行中の場合、進行イベントが発生する。部分イベント(partial event)は、ファイル受信が中断され使用可能な部分ファイルコンテンツがある場合に発生する。受信されたバイト範囲は、アプリケーションに提供される。受信されたイベントは、要求されたファイルが完全に受信されてフェッチされる準備ができた時に発生する。除去イベントは、要求されたファイルが指定された時間までローカルキャッシュから除去されるようにスケジュールされた場合に発生する。
【0080】
DASH APIは、MBMSによるDASHプレゼンテーションのRepresentationsのコンテンツにアクセスするためのクライアント機能を提供するAPIを定義する。ObjectFlowのオブジェクトは、DASH APIによって定義されて関連ファイルのセットを検索する。ObjectFlowは、関心のあるRepresentationに対する初期化部分のURLと該当Representationの部分を一致させる規則を取る初期化方法を提供する。規則は、RepresentationID、URLテンプレート又は基本URLとできる。
【0081】
ObjectFlowは、次のイベントを定義する:
受信されたイベントは、オブジェクトフローのオブジェクトが受信された時に発生する。受信された最初のオブジェクトは、開始部分でなければならない。部分イベントは、オブジェクトフローの部分オブジェクトが受信された時に発生する。消えたイベントは、MBMS受信がこれ以上使用可能でなく、代わりにユニキャスト受信が用いられなければならない場合に発生した。
【0082】
一般ソケットAPIは、MBMSによって伝達されるUDPデータグラムストリームにアクセスするためのクライアント機能を提供するAPIを定義する。ソケットオブジェクトは、特定マルチキャストデスティネーションアドレスに転送されたUDPデータグラムを開いて受信するために、ソケットAPIによって定義される。ソケットAPIは、MBMS URLを引数とし、セッションのSDPを返す解決関数(resolve function)を提供する。ソケットAPIは、マルチキャストデスティネーションアドレス及びUDPポートを引数とする接続関数(connect function)を提供する。ソケットAPIは、MBMSによって受信されたUDPデータグラムペイロードを受信するために使用される受信関数(receive function)を提供する。パケットは、受信されたときと同じ順序でアプリケーションに伝達される。ソケットAPIは、また、次のイベントを定義する:
準備イベントは、1以上のパケットが受信準備できたことを受信機が通知された時に発生する。消えたイベントは、受信機がMBMS受信がこれ以上使用可能でないという通知を受けると発生する。
【0083】
図6及び
図7は、それぞれMBMS URLを解決するためのフローチャート600及び700の例を示すが、
図6及び
図7に多様な変更が行われてもよい。例えば、一連のステップとして図示されたが、各図面の多様なステップは重なったり、並列的に発生したり、異なる順序で発生したり、又は複数回発生してもよい。
【0084】
図8は、本開示の多様な実施形態によるベアラ伝達方法800に対する例示的なMBMSフレーミング(framing)を示す。
図9は、本開示の多様な実施形態による例示的なMBMSフレーミングヘッダ900を示す。
図8に示すベアラ伝達方法800、及び、
図9に示すMBMSフレーミングヘッダ900に対するMBMSフレーミングの実施形態は、単なる説明のためのものである。
図8及び
図9は、本開示の範囲を電子装置のいかなる特定の形態にも制限しない。
【0085】
構成可能なフレーミングプロトコル、FECフレームワーク、及び、バッファリングモデルは、サービスによる遅延及びエラー要件に基づいて、伝送の品質を調整するために開示される。MBMSフレーミングプロトコル910は、MBMS特定機能を提供するためにユーザ平面UDPパケット905をカプセル化するよう定義される。MBMSフレーミングプロトコル910は、UDPデータグラムのアドレッシング(addressing)及び損失したパケットの検出を許容する。FECを使用すれば、FEC復元データが別途のメディアセッションを介して伝達される。
【0086】
ソースパケットは、UDPヘッダの直後にパケットシーケンス番号915を含むように修正される。UDPチェックサム920は、MBMSフレーミングが行われた後、再計算されるべきである。ベアラ伝達方法に対するSDPは、コンテンツを取り込んだ時にコンテンツ原点によって提供され、BM−SC603に対して透明(transparent)である。SDPは、UE601へのアプリケーションを介してMBMSクライアントに直接提供される。SDPは、少なくとも次のSDPパラメータを含む:宛先IPアドレス及びポート番号、各メディアセッションに対するプロトコルID、MBMSベアラの一時的モバイルグループアイデンティティ(TMGI)、最大遅延許容特性、及びメディアレベル属性としてセクション8.3.2.1で定義されたような要求されたQoE(quality of experience)報告。
【0087】
“最大許容遅延(max−allowed−delay)”は、UDPデータグラムを受信した時間から受信するアプリケーションに伝達する時間まで許容される最大許容遅延を受信機に知らせるメディアレベルSDP属性である。この時間は、FECデコーディングのようなあらゆる演算に消耗される時間に上位境界を設定する。この値は、ミリ秒単位で表示される。
【0088】
MBMSフレーミングプロトコルの識別は、プロトコルIDの一部として提供される。例えば、MBMSフレーミングプロトコルの識別は、MBMSフレーミングプロトコル及びUDPを介して伝達されるRTPトラフィックのためのUDP/MBMS/RTPとできる。
【0089】
本開示の特定の実施形態において、MBMSフレーミングは、UDPデータグラムをMBMS/UDP/IPパケットにカプセル化することによって行われてもよい。本開示の特定の実施形態において、測定されたサービス品質(QoS)に関する情報は、サーバに折り返し報告される。
【0090】
メトリック(metric)“UDP_Datagram_Loss”は、MBMSフレーミングパケットシーケンス番号の差によって検出された、連続的なUDPデータグラム損失の数を表す。この測定項目はベアラ伝達方法にのみ適用される。
【0091】
さらに別のメトリック“UDP_Datagram_Jitter”は、例えば、平均伝送遅延からの偏差で測定された測定遅延ジッタ(jitter)を提供する。この測定を得るために、フレーミングプロトコルは、UDPデータグラムを送信する時、BM−SCが設定した伝達タイムスタンプを有さなければならない。
【0092】
例示的な実施形態を用いて本開示が記載されたが、多様な変更及び修正が当業者に提案されることができる。本開示は添付された請求の範囲内に属するそのような変更及び修正を含むことが意図される。
【0093】
本開示の説明は、特定の要素、段階、又は機能が請求範囲に含まれるべき必須要素であることを暗示すると解釈されるべきではない。特許の範囲は請求範囲によってのみ限定される。