JP6774957B2 - マルチメディアブロードキャストマルチキャストサービスに基づくフレキシブルブロードキャストサービスのための方法及び装置 - Google Patents

Description

本開示は、一般的には、マルチメディアブロードキャストマルチキャストサービス（ｍｕｌｔｉｍｅｄｉａ ｂｒｏａｄｃａｓｔ ｍｕｌｔｉｃａｓｔ ｓｅｒｖｉｃｅ、ＭＢＭＳ）に関する。より具体的には、本開示は、ＭＢＭＳに基づくフレキシブルブロードキャストサービスのための方法及び装置に関する。

ＭＢＭＳ（ｍｕｌｔｉｍｅｄｉａ ｂｒｏａｄｃａｓｔ ｍｕｌｔｉｃａｓｔ ｓｅｒｖｉｃｅ）仕様（ｓｐｅｃｉｆｉｃａｔｉｏｎ）は、ユーザサービスを構築するために用いられる２つの伝達方法であるダウンロード及びストリーミングを基盤とする。ユーザサービスは、１以上の伝達方法、ファイル復元及び受信報告といった補助伝達手順、及び、サービス選択及びアクセスを可能にするユーザサービスディスクリプション（ｄｅｓｃｒｉｐｔｉｏｎ）で構成される。過去、ＭＢＭＳは、制限されたＭＢＭＳブロードキャスト領域を介したライブイベントのストリーミング、及び、ファームウェアアップデートといった人気の高いファイルの配信に対して最も適切であると知られるようになった。

本開示の一見地は、より高い性能のブロードキャストサービスを提供することにある。

本開示の実施形態は、ＭＢＭＳに基づくフレキシブルブロードキャストサービスのための方法及び装置を提供する。

一実施形態において、ＭＢＭＳに基づくフレキシブルブロードキャストサービスのためのクライアント装置が提供される。上記装置は、メモリ及びメモリに動作可能に結合された１以上のプロセッサを含む。１以上のプロセッサは、コンテンツの位置に対する要求をサーバに送信するように構成される。また、１以上のプロセッサは、マルチメディアブロードキャストマルチキャストサービス（ＭＢＭＳ）がコンテンツに対して使用可能な時に、コンテンツの位置に対するＭＢＭＳ伝達ディスクリプションを受信し、ＭＢＭＳ伝達ディスクリプションに基づいてコンテンツを運搬するＭＢＭＳに対するセッションに参加するよう構成される。１以上のプロセッサは、さらに、ＭＢＭＳがコンテンツに使用可能でない時、コンテンツに対する非ＭＢＭＳ ＵＲＬ（ｕｎｉｆｏｒｍ ｒｅｓｏｕｒｃｅ ｌｏｃａｔｏｒ）を受信するよう構成される。

他の実施形態において、ＭＢＭＳに基づくフレキシブルブロードキャストサービスのための方法が提供される。上記方法は、コンテンツ位置に対する要求をサーバに送信する過程を含む。また、上記方法は、ＭＢＭＳがコンテンツに対して使用可能な時、コンテンツの位置に対するＭＢＭＳ伝達ディスクリプションを受信し、ＭＢＭＳ伝達ディスクリプションに基づいてコンテンツを運搬するＭＢＭＳセッションに参加する過程を含む。上記方法は、ＭＢＭＳがコンテンツに対して使用可能でない時、コンテンツに対する非ＭＢＭＳ ＵＲＬを受信する過程をさらに含む。

他の実施形態において、ＭＢＭＳに基づくフレキシブルブロードキャストサービスのためのサーバが提供される。サーバは、メモリ及びメモリに動作可能に結合された１以上のプロセッサを含む。１以上のプロセッサは、クライアント装置からコンテンツの位置に対する要求を受信するように構成される。また、１以上のプロセッサは、ＭＢＭＳがコンテンツに使用可能か否かを決定するように構成される。また、１以上のプロセッサは、コンテンツに対する高い要求に応じて、コンテンツを運搬するＭＢＭＳに対するセッションにクライアント装置が参加できるように、コンテンツの位置に対するＭＢＭＳ伝達ディスクリプションを送信し、コンテンツに対する低い要求に応じてコンテンツがＭＢＭＳによって使用可能でないことを示す指示子（ｉｎｄｉｃａｔｉｏｎ）を送信するようさらに構成される。

他の技術的特徴は、以下の図面、記載、及び、請求範囲から、本開示が属する技術分野における通常の知識を有する者に容易に明白になり得る。

以下の詳細な説明を行う前に、本特許文書全体にわたって用いられる特定の単語及び句の定義を記述することが好ましいであろう。用語「結合する（ｃｏｕｐｌｅ）」及びその派生語は、２つ以上の要素が互いに物理的に接触しているか否かにかかわらず、直接的又は間接的に通信することを意味する。「送信」、「受信」及び「通信」、並びにそれらの派生語は、直接及び間接通信のいずれをも含む。「含む（ｉｎｃｌｕｄｅ）」及び「構成する（ｃｏｍｐｒｉｓｅ）」、並びにその派生語は、制限なく含むことを意味する。用語「又は」は、包括的であって、「及び／又は」を意味する。「関連づけられる（ａｓｓｏｃｉａｔｅｄ ｗｉｔｈ）」及びその派生語は、含む（ｉｎｃｌｕｄｅ）、〜内に含まれる（ｂｅ ｉｎｃｌｕｄｅｄ ｗｉｔｈｉｎ）、互いに接続する（ｉｎｔｅｒｃｏｎｎｅｃｔ ｗｉｔｈ）、含む（ｃｏｎｔａｉｎ）、〜内に含まれる（ｂｅ ｃｏｎｔａｉｎｅｄ ｗｉｔｈｉｎ）、接続する（ｃｏｎｎｅｃｔ ｔｏ ｏｒ ｗｉｔｈ）、結合する（ｃｏｕｐｌｅ ｔｏ ｏｒ ｗｉｔｈ）、〜と通信できる（ｂｅ ｃｏｍｍｕｎｉｃａｂｌｅ ｗｉｔｈ）、協力する（ｃｏｏｐｅｒａｔｅ ｗｉｔｈ）、インターリーブする（ｉｎｔｅｒｌｅａｖｅ）、並べる（ｊｕｘｔａｐｏｓｅ）、隣接する（ｂｅ ｐｒｏｘｉｍａｔｅ ｔｏ）、縛られる（ｂｅ ｂｏｕｎｄ ｔｏ ｏｒ ｗｉｔｈ）、有する（ｈａｖｅ）、属性を有する（ｈａｖｅ ａ ｐｒｏｐｅｒｔｙ ｏｆ）、関係がある（ｈａｖｅ ａ ｒｅｌａｔｉｏｎｓｈｉｐ ｔｏ ｏｒ ｗｉｔｈ）などを意味する。用語「制御部」は、少なくとも１つの動作を制御する装置、システム又はその一部を意味する。制御部は、ハードウェア又はハードウェアとソフトウェア、及び／又はファームウェア（ｆｉｒｍｗａｒｅ）の組み合わせにより実現される場合がある。特定の制御部と関連づけられた機能は、ローカル（ｌｏｃａｌｌｙ）又は遠隔にて、中央集中されていてもよいし、分散されていてもよい。「少なくとも１つ」は、それが項目のリストと共に用いられる場合、並べられた項目のうち少なくとも１つの互いに異なる組み合わせが用いられる場合があり、リストの１つの項目のみが必要な場合があることを意味する。例えば、「Ａ、Ｂ、及びＣのうち少なくとも１つ」は次の組み合わせ、すなわちＡ、Ｂ、Ｃ、Ａ及びＢ、Ａ及びＣ、Ｂ及びＣ、さらには、Ａ及びＢ及びＣの組み合わせのうちいずれか１つが含まれる。

また、以下で説明される多様な機能は、それぞれがコンピュータ読み取り可能なプログラムコードで形成されコンピュータ読み取り可能な媒体にて実現された１以上のコンピュータプログラムによって実現又はサポートできる。用語「アプリケーション（ａｐｐｌｉｃａｔｉｏｎ）」及び「プログラム（ｐｒｏｇｒａｍ）」は、適したコンピュータ読み取り可能なプログラムコードで実現されるために適応された少なくとも１つのコンピュータプログラム、ソフトウェア構成要素、命令セット、プロシージャ、機能、オブジェクト、クラス（ｃｌａｓｓ）、インスタンス、関連データ、又はその一部を言う。「コンピュータ読み取り可能なプログラムコード」 は、ソースコード（ｓｏｕｒｃｅ ｃｏｄｅ）、オブジェクトコード（ｏｂｊｅｃｔ ｃｏｄｅ）、及び、実行可能なコードを含むあらゆる種類のコンピュータコードを含む。「コンピュータ読み取り可能な媒体」は、ＲＯＭ（ｒｅａｄ ｏｎｌｙ ｍｅｍｏｒｙ）、ＲＡＭ（ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ）、ハードディスクドライブ、コンパクトディスク（ｃｏｍｐａｃｔ ｄｉｓｃ、ＣＤ）、ＤＶＤ（ｄｉｇｉｔａｌ ｖｉｄｅｏ ｄｉｓｋ）、又はその他の任意のタイプのメモリのようなコンピュータがアクセスできる任意のタイプの媒体を含む。「非一時的な（ｎｏｎ−ｔｒａｎｓｉｔｏｒｙ）」コンピュータ読み取り可能な媒体は、一時的な電気的信号又は他の信号を伝送する有線、無線、光学、又は他の通信リンクを除く。非一時的なコンピュータ読み取り可能な媒体は、データが永続的に記憶され得る媒体及び再起録が可能な光ディスク又は消去可能なメモリ装置のようなデータを記憶した後に上書きできる媒体を含む。

他の特定の単語及び表現に対する定義は、本特許文書全体にわたって提供される。本技術の分野における通常の知識を有する者であれば、このような定義が大部分ではないにしても多くの場合、そのように定義された単語及び語句の将来の使用だけでなく、従来の使用にも適用されることを理解するであろう。

ブロードキャストサービスの性能を向上できる。本開示及びその利点をより完全に理解するために、後述する詳細な説明に対して添付された図面と共に、参照番号が提供される。

本開示の多様な実施形態による例示的なコンピューティングシステムを示す図である。 本開示の多様な実施形態によるコンピューティングシステム内の例示的な装置を示す図である。 本開示の多様な実施形態によるコンピューティングシステム内の例示的な装置を示す図である。 本開示の多様な実施形態によるユーザサービス、伝達方法及びベアラ（ｂｅａｒｅｒ）サービスの間の関係に対する例示的な参照モデルを示す図である。 本開示の多様な実施形態による例示的なプロトコルスタックを示す図である。 本開示の多様な実施形態によるＭＢＭＳ ＵＲＬを解決するための例示的なフローチャートを示す図である。 本開示の多様な実施形態によるＭＢＭＳ ＵＲＬを解決するための他の例示的なフローチャートを示す図である。 本開示の多様な実施形態によるベアラ伝達方法のための例示的なＭＢＭＳフレーミング（ｆｒａｍｉｎｇ）を示す図である。 本開示の多様な実施形態による例示的なＭＢＭＳフレーミングヘッダを示す図である。

以下に説明する図１乃至図９、及び、本特許文書において本開示の原理を説明するために用いられる多様な実施形態は、単なる説明のためのものであって、本発明の範囲を制限するように解釈されるべきではない。本開示の属する技術の分野における通常の知識を有する者は、本開示の原理が任意の適切に配列されたシステム又は装置で実現されてもよいことを理解するであろう。

大きなユーザグループに同じコンテンツを提供する直観的な方法は、全てのユーザのそれぞれに対して専用のネットワークリソースを割り当てる代わりに、ブロードキャストメカニズムを活用する方法である。ＴＶチャンネルの配信、及び、無線による大規模ソフトウェアアップデートの配信が、ブロードキャストにより大いに恩恵を受けるサービスの例である。

ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）は、ＭＢＭＳを定義して費用面から最も効率的な方式でこのようなサービスの要求事項を解決した。これは、当初、２つのモード、すなわち、ブロードキャストとマルチキャストを定義した。しかし、マルチキャストモードは、ユーザ空間マルチキャストトラフィックのトンネリングの使用によって費用節減にならず中断された。

図１は、本開示による例示的なコンピューティングシステム１００を示す。図１に示すコンピューティングシステム１００の実施形態は、単なる説明のためのものである。コンピューティングシステム１００の他の実施形態を、本開示の範囲から逸脱することなく使用できる。

図１に示すように、システム１００は、システム１００内の多様な構成要素間の通信を容易にするネットワーク１０２を含む。例えば、ネットワーク１０２は、インターネットプロトコル（ＩＰ）パケット、フレームリレーフレーム（ｆｒａｍｅ ｒｅｌａｙ ｆｒａｍｅｓ）、非同期転送モード（ＡＴＭ）セル、又は、ネットワークアドレス間の他の情報を通信できる。ネットワーク１０２は、１以上のローカル領域ネットワーク（ＬＡＮ）、メトロポリタンエリアネットワーク（ＭＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、インターネットのようなグローバルネットワークの全部又は一部、又は、１以上の位置での任意の他の通信システム又はシステムを含んでもよい。

ネットワーク１０２は、少なくとも１つのサーバ１０４と多様なクライアント装置１０６−１１４との間の通信を容易にする。各々のサーバ１０４は、１以上のクライアント装置にコンピューティングサービスを提供できる任意の適切なコンピューティング又は処理装置を含む。例えば、各サーバ１０４は、１以上の処理装置、命令及びデータを格納する１以上のメモリ、及び、ネットワーク１０２を介した通信を容易にする１以上のネットワークインタフェースを含んでもよい。

各クライアント装置１０６−１１４は、ネットワーク１０２を介して少なくとも１つのサーバ又は他のコンピューティング装置と相互作用する任意の適切なコンピューティング又は処理装置である。この例において、クライアント装置１０６−１１４は、デスクトップコンピュータ１０６、携帯電話又はスマートフォン１０８、ＰＤＡ（ｐｅｒｓｏｎａｌ ｄｉｇｉｔａｌ ａｓｓｉｓｔａｎｔ）１１０、ラップトップコンピュータ１１２、及び、タブレットコンピュータ１１４を含む。しかし、任意の他の又は追加的なクライアント装置を、コンピューティングシステム１００において使用してもよい。

この例で、一部のクライアント装置１０８−１１４は、ネットワーク１０２と間接的に通信する。例えば、クライアント装置１０８−１１０は、セルラー基地局又はｅＮｏｄｅＢのといった１以上の基地局１１６を介して通信する。また、クライアント装置１１２−１１４は、ＩＥＥＥ ８０２．１１無線アクセスポイントといった１以上の無線アクセスポイント１１８を介して通信する。これらは単なる例示のためのものであって、各々のクライアント装置は、直接的に、又は、任意の適した中間装置又はネットワークを介して間接的に、ネットワーク１０２と通信してもよいことに留意すべきである。

図１は、コンピューティングシステム１００の一例を示すが、多様な変更が図１に対して行われてもよい。例えば、システム１００は任意の適切な構成にて任意の数の構成要素を含んでもよい。一般に、コンピューティング及び通信システムは、多様な構成を有し、図１は、本開示の範囲を任意の特定構成に制限しない。図１は、本特許文献に開示された多様な特徴を使用できる１つの動作環境を示すが、これらの特徴は任意の他の適したシステムで使用されてもよい。

図２及び図３は、本開示によるコンピューティングシステム内の例示的な装置を示す。特に、図２は、例示的なサーバ２００を示し、図３は、例示的なクライアント装置３００を示す。サーバ２００は、図１のサーバ１０４を示すことができ、クライアント装置３００は、図１の少なくとも１つのクライアント装置１０６−１１４を示すことができる。

図２に示すように、サーバ２００は、少なくとも１つの処理装置２１０、少なくとも１つの記憶装置２１５、少なくとも１つの通信部２２０及び少なくとも１つの入出力部２２５の間の通信をサポートするバスシステム２０５を含む。

処理装置２１０は、メモリ２３０にロードされる命令を実行する。処理装置２１０は、任意の適切な構成で任意の適切な数及びタイプのプロセッサ又は他の装置を含んでもよい。例示的な類型の処理装置２１０は、マイクロプロセッサ、マイクロコントローラ、デジタル信号プロセッサ、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、特定用途向け集積回路、及び、ディスクリート回路（ｄｉｓｃｒｅｔｅ ｃｉｒｃｕｉｔｒｙ）を含む。処理装置２１０は、認証されたウェアラブル装置により電子装置をロック解除する動作を行うように構成される。

メモリ２３０及び永続性記憶装置（ｐｅｒｓｉｓｔｅｎｔ ｓｔｏｒａｇｅ）２３５は、情報（例えば、データ、プログラムコード、及び／又は、一時的又は永久的な他の適切な情報）を格納及び容易に取り出すことができる任意の構造物である記憶装置２１５の例である。メモリ２３０は、ランダムアクセスメモリ（ＲＡＭ）又は任意の他の適切な揮発性又は不揮発性記憶装置である。永続性記憶装置２３５は、読み出し専用メモリ（ＲＯＭ）、ハードドライブ、フラッシュメモリ、又は、光学ディスクのようにデータの長期記憶をサポートする１以上の構成要素又は装置を含んでもよい。

通信部２２０は、他のシステム又は装置との通信をサポートする。例えば、通信部２２０は、ネットワーク１０２を介した通信を容易にするネットワークインタフェースカード又は無線送受信部を含んでもよい。通信部２２０は、任意の適切な物理的又は無線通信リンクを介した通信をサポートする。

入出力部（ｉｎｐｕｔ／ｏｕｔｐｕｔ（Ｉ／Ｏ） ｕｎｉｔ）２２５は、データの入力及び出力を許容する。例えば、入出力部２２５は、キーボード、マウス、キーパッド、タッチスクリーン、又は他の適切な入力装置を介したユーザ入力のための接続を提供できる。また、入出力部２２５は、出力をディスプレイ、プリンタ又は他の適切な出力装置に送信できる。

図２は図１のサーバ１０４を示すと説明したが、同じ又は類似の構造が、１以上のクライアント装置１０６−１１４において使用されてもよいことに注意すべきである。例えば、ラップトップ又はデスクトップコンピュータは、図２に示すものと同じ又は類似の構造を有してもよい。

図３に示すように、クライアント装置３００は、アンテナ３０５、無線周波数（ＲＦ）送受信部３１０、送信（ＴＸ）処理回路３１５、マイクロホン３２０、及び、受信（ＲＸ）処理回路３２５を含む。また、クライアント装置３００は、スピーカ３３０、メインプロセッサ３４０、入出力（Ｉ／Ｏ）インタフェース（ＩＦ）３４５、キーパッド３５０、ディスプレイ３５５、及び、メモリ３６０を含む。メモリ３６０は、基本的なオペレーティングシステム（ＯＳ）プログラム３６１、及び、１以上のアプリケーション３６２を含む。

ＲＦ送受信部３１０は、システムの他の構成要素によって送信される受信ＲＦ信号を、アンテナ３０５から受信する。ＲＦ送受信部３１０は、受信ＲＦ信号を中間周波数（ｉｎｔｅｒｍｅｄｉａｔｅ ｆｒｅｑｕｅｎｃｙ、ＩＦ）又は基底帯域信号を生成するためにダウンコンバートする。ＩＦ又は基底帯域信号は、基底帯域又はＩＦ信号をフィルタリング、デコーディング及び／又はデジタル化することによって処理された基底帯域信号を生成する受信処理回路３２５に送信される。受信処理回路３２５は、処理された基底帯域信号（音声データなど）をスピーカ３３０に送信するか、又は、追加処理（ウェブブラウジングデータなど）のためにメインプロセッサ３４０に送信する。

送信処理回路３１５は、マイクロホン３２０からアナログ又はデジタル音声データを受信し、メインプロセッサ３４０から他の発信基底帯域データ（ウェブデータ、電子メール、又は両方向ビデオゲームデータ）を受信する。送信処理回路３１５は、処理された基底帯域又はＩＦ信号を生成するために発信基底帯域データを、エンコーディング、多重化、及び／又はデジタル化する。ＲＦ送受信部３１０は、発信処理された基底帯域又はＩＦ信号を送信処理回路３１５から受信し、基底帯域又はＩＦ信号を、アンテナ３０５を介して送信されるＲＦ信号にアップコンバートする。

メインプロセッサ３４０は、１以上のプロセッサ又は他の処理装置を含んでもよく、クライアント装置３００の全体動作を制御するために、メモリ３６０に格納された基本的なＯＳプログラム３６１を実行できる。例えば、メインプロセッサ３４０は、周知の原理に従って、ＲＦ送受信部３１０、受信処理回路３２５、及び、送信処理回路３１５による順方向チャネル信号の受信、及び、逆方向チャネル信号の送信を制御できる。一部の実施形態において、メインプロセッサ３４０は、少なくとも１つのマイクロプロセッサ又はマイクロコントローラを含む。

また、メインプロセッサ３４０は、ＭＢＭＳに基づくフレキシブルブロードキャストサービスのための動作のような、他のプロセッサ及びメモリ３６０に常駐するプログラムを実行できる。メインプロセッサ３４０は、実行プロセスからの要求に従って、データを、メモリ３６０内又は外に移動できる。一部の実施形態において、メインプロセッサ３４０は、ＯＳプログラム３６１に基づいて、又は、外部装置又はオペレータから受信された信号に応じて、アプリケーション３６２を実行するように構成される。また、メインプロセッサ３４０は、クライアント装置３００にノートブック及び携帯用コンピュータのような他の装置を接続することを可能とする入出力インタフェース３４５に結合されている。入出力インタフェース３４５は、このようなアクセサリとメインプロセッサ３４０との間の通信経路である。

また、メインプロセッサ３４０は、キーパッド３５０及びディスプレイ３５５に結合されている。クライアント装置３００のオペレータは、クライアント装置３００にデータを入力するためにキーパッド３５０を使用できる。ディスプレイ３５５は、液晶ディスプレイ、又は、ウェブサイトからのテキスト及び／又は少なくとも制限されたグラフィックをレンダリング可能なディスプレイであってもよい。

メモリ３６０は、メインプロセッサ３４０に結合されている。メモリ３６０の一部はＲＡＭを含んでもよく、メモリ３６０の他の部分はフラッシュメモリ又はＲＯＭを含んでもよい。

図２及び図３は、コンピューティングシステム内の装置の例を示すが、図２及び図３に多様な変更が行われてもよい。例えば、図２及び図３の多様な構成は、組み合わせたり、細分化したり、省略されてもよく、追加的な構成が特定のニーズに従って追加されてもよい。特定例として、メインプロセッサ３４０は、１以上の中央処理ユニット（ＣＰＵ）、及び、１以上のグラフィック処理ユニット（ＧＰＵ）のような多重プロセッサに分けられてもよい。また、図３は、携帯電話及びスマートフォンで構成されたクライアント装置３００を示すが、クライアント装置は、他の類型のモバイル又は固定装置として構成されてもよい。また、コンピューティング及び通信ネットワークと同様に、クライアント装置及びサーバは、多様な構成を有してもよく、図２及び図３は、本開示を、任意の特定クライアント装置又はサーバに限定しない。

図４は、ユーザサービス４０５、伝達方法４１０、及び、ベアラ（ｂｅａｒｅｒ）サービス４１５間の関係についての例示的な参照モデル４００を示す。図５は、本開示の多様な実施形態によるプロトコルスタック５００の例を示す。図４に示す参照モデル４００、及び、図５のプロトコルスタック５００の実施形態は、単なる説明のためのものである。図４及び図５は、本開示の範囲を電子装置の任意の特定の実施形態に制限しない。

ＬＴＥのためのＭＢＭＳ（ｅＭＢＭＳ）は、無線インタフェース上のブロードキャストサポート、ゲートウェイと基地局との間のＩＰパケット送信のためのＩＰマルチキャストの使用、及び、ＭＢＭＳセッションの設定と維持のための特定の手順（ｐｒｏｃｅｄｕｒｅ）に依存する。ＭＢＭＳソリューションの重要な構成要素は、ＭＢＭＳユーザサービス４０５及びＭＢＭＳベアラサービス４１５である。ＭＢＭＳベアラサービス４１５は、モバイルネットワーク及びユーザ装置（ＵＥ）において、特定の機能セットを提供するポイント−トゥー−マルチポインティングコンテンツ配布チャネル（ｐｏｉｎｔ−ｔｏ−ｍｕｌｔｉ−ｐｏｉｎｔｉｎｇ ｃｏｎｔｅｎｔ ｄｉｓｔｒｉｂｕｔｉｏｎ ｃｈａｎｎｅｌ）である。ＭＢＭＳアーキテクチャの重要なネットワーク要素は、ＭＢＭＳユーザサービスを構築し、ＭＢＭＳユーザベアラを生成し、ＭＢＭＳ及び他の機能（セキュリティ、サービス告知、関連伝達過程等）を介してメディア伝達を行うブロードキャストマルチキャストサービスセンター（ＢＭ−ＳＣ）である。

ＭＢＭＳユーザサービス４０５は、ＵＥにコンテンツを伝達するためのツールセットのインスタンス化（ｉｎｓｔａｎｔｉａｔｉｏｎ）である。これは、１以上の伝達方法、サービスディスクリプション、及び、サービス告知手順、関連伝達手順、セキュリティ及び報告ツールにて構成される。

現在、ストリーミング４２０、ダウンロード４２５、及び、グループ通信４３０と定義された３つの異なる伝達方法４１０が存在する。ストリーミング４２０は、モバイルＴＶサービスを提供するためにＭＢＭＳ Ｒｅｌｅａｓｅ ６の一部として設計された。ストリーミング４２０は、メディアデータ伝達のためにＲＴＰ（ｒｅａｌ−ｔｉｍｅ ｔｒａｎｓｐｏｒｔ ｐｒｏｔｏｃｏｌ）／ＲＴＣＰ（ＲＴＰ ｃｏｎｔｒｏｌ ｐｒｏｔｏｃｏｌ）プロトコル５０５に依存し、多数のメディアストリームの保護を共にサポートする前方誤り訂正（ｆｏｒｗａｒｄ ｅｒｒｏｒ ｃｏｒｒｅｃｔｉｏｎ、ＦＥＣ）フレームワークを定義する。ダウンロード４２５伝達方法は、ファイルをＵＥに信頼可能に伝達する機能を提供する。ＵＥは、ＦＥＣビルディングブロック（ｂｕｉｌｄｉｎｇ ｂｌｏｃｋ）だけでなく、ＨＴＴＰを介したＦＬＵＴＥ（ｆｉｌｅ ｄｅｌｉｖｅｒｙ ｏｖｅｒ ｕｎｉｄｉｒｅｃｔｉｏｎａｌ ｔｒａｎｓｐｏｒｔ）プロトコル５１０に基づくファイル伝達を使用してサービスの信頼性を向上させる。ＨＴＴＰを介したストリーミングメディアの登場と共に、ストリーミング４２０伝達方法の価値は、ＲＴＰ／ＲＴＣＰ５０５を使用するストリーミングサーバの維持が非常に複雑であるため、著しく減少した。その代わりに、ダウンロード４２５伝達方法が、ＦＬＵＴＥ５１０を介したＨＴＴＰストリーミングコンテンツ伝達をサポートするために若干拡張された。

ＭＢＭＳの伝達方法として追加された３番目の最新の伝達方法は、グループ通信（ＧＣ）４３０伝達方法である。他の２つの方法で提供されるものに比べて高い柔軟性を要求する公共安全サービス及びその他サービスの要求を解決するために、ＧＣ４３０伝達方法が追加された。例えば、サービスは、ダウンロード４２５及びストリーミング４２０伝達方法によって定義されたものと異なるプロトコル、フォーマット、及び、サービス告知手順を使用することを希望する場合がある。例えば、ストリーミング４２０サービス提供者は、ＦＣＡＳＴプロトコルを介してＨＬＳフォーマットされたメディアデータを伝達することを希望する場合がある。この場合、ダウンロード４２５伝達方法は、フォーマット及びプロトコルをサポートしないため、ダウンロード４２５伝達方法は使用できない。さらに別の例は、非常に低い遅延チャネルを介して暗号化された音声データを送信しようとする公共安全サービスである。ＢＭ−ＳＣがサービス提供者の代わりに暗号化を行わなければならず、例えば、ＦＥＣフレームワークが誘発する遅延がサービス提供者に受け入れられないため、ストリーミング方法はこの場合には適合しない。

ファイルダウンロードプロファイルは、オフライン型伝達モードを使用してファイルを伝達するために用いられるよう設計されている。ファイルは、通常予約された時間にＢＭ−ＳＣによって入れられ、ユーザ装置（ＵＥ）のアプリケーションにより後ほど使用するためにローカルにキャッシュされる。ファイルダウンロードプロファイルは、“ｕｒｎ：３ｇｐｐ：ｍｂｍｓ：ｄｏｗｎｌｏａｄ：２０１５”といったＵＲＩ（ｕｎｉｆｏｒｍ ｒｅｓｏｕｒｃｅ ｉｄｅｎｔｉｆｉｅｒ）により識別される。ＵＲＩは、ＭＢＭＳユーザサービス説明メタデータフラグメントを運搬するＭＢＭＳメタデータエンベロープの一部として提供される。

ダウンロードセッション告知の使用は次のうちの１つの方法で提供される：
１．ＯＴＡ（ｏｖｅｒ ｔｈｅ ａｉｒ）−ＨＴＴＰプッシュベアラは、ＭＢＭＳ ＵＳＤ（ｕｓｅｒ ｓｅｒｖｉｃｅ ｄｅｓｃｒｉｐｔｉｏｎ）メタデータフラグメントを含む単一メタデータ項目（ｉｔｅｍ）を含むメタデータエンベロープだけを伝達すべきである。ユーザサービスに関心があるＵＥは、ＨＴＴＰを使用して全ての参照されたフラグメントを要求すべきである。

２．ＭＢＭＳベアラサービスの設定を、必要に応じて予め構成されたサービス領域を介してトリガするあらかじめ構成されたＭＢＭＳユーザサービス。

３．ＭＢＭＳは、オペレータがＭＢＭＳによってサービスすると決定した人気のあるコンテンツに対する要求の応答として、オンデマンド（ｏｎ−ｄｅｍａｎｄ）で活性化される。

ＵＳＤには次のようなメタデータフラグメントが含まれる：
１．ちょうど１つのａｓｓｏｃｉａｔｅｄＰｒｏｃｅｄｕｒｅＤｅｓｃｒｉｐｔｉｏｎＵＲＩを含む、ちょうど１つの伝達方法を含むべきユーザサービス説明メタデータフラグメント。

２．ａｓｓｏｃｉａｔｅｄＰｒｏｃｅｄｕｒｅＤｅｓｃｒｉｐｔｉｏｎフラグメントは、バイト範囲（ｂｙｔｅ ｒａｎｇｅ）の修復をサポートする１つのｐｏｓｔＦｉｌｅＲｅｐａｉｒ要素を含むべきである。

３．トランスポートレベルセキュリティのためのｐｒｏｔｅｃｔｉｏｎＤｅｓｃｒｉｐｔｉｏｎは提供されてはならず、コンテンツは、ＯＭＡ（Ｏｐｅｎ Ｍｏｂｉｌｅ Ａｌｌｉａｎｃｅ）−ＤＲＭ（ｄｉｇｉｔａｌ ｒｉｇｈｔｓ ｍｅｄｉａ）のようなコンテンツ保護ソリューションを使用して保護されるべきである。

４．スケジュールフラグメントは、各リソースに対する伝送時間を表すために提供されてもよい。スケジュールフラグメントは、ＯＴＡ−ＰＵＳＨによって告知されたＭＢＭＳサービスに対して存在するべきである。

伝達機能は、トランスポートプロトコルとしてＦＬＵＴＥ５１０を使用する。ＦＬＵＴＥセッションは、１つのみである。

また、ユニキャストを介したセッションコンテンツ伝達は、このプロファイルにおいてサポートされない。アップデートされたサービス維持がサポートされるべきである。

このプロファイルと互換性のあるＵＥは、要求に応じてＭＢＭＳをサポートするべきである。ユニキャストを介したファイルの受信は、要求されたリソースの受信のためにＭＢＭＳにリダイレクト（ｒｅｄｉｒｅｃｔ）されてもよい。ＵＥは、伝達遅延を考慮すべきである。

ＨＴＴＰ動的適応ストリーミング（ＤＡＳＨ）プロファイル５１５
ＤＡＳＨプロファイル５１５は、ハイブリッドユニキャスト／ブロードキャストチャネルを介したＤＡＳＨコンテンツ伝達のために特別に定義されたプロファイルである。ＤＡＳＨプレゼンテーションは、表現の集合にて構成される。そのうち一部の表現は、ブロードキャスト（主にメインオーディオ及びビデオ表現）を介して伝達され、その他補完的又は代替的な表現は、ユニキャストを介して伝達される。ＤＡＳＨプロファイルは、“ｕｒｎ：３ｇｐｐ：ｍｂｍｓ：ｄａｓｈ：２０１５”とのＵＲＩにより識別される。

ＭＢＭＳによるＤＡＳＨに対するサービス告知は、次のうちの１つの方法で提供される。ＭＢＭＳメタデータエンベロープを運搬する専用のあらかじめ構成されたＭＢＭＳチャネル。実際のＭＢＭＳユーザサービスの位置を説明するＭＰＤ（Ｍｅｄｉａ Ｐｒｅｓｅｎｔａｔｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ）及びＳＤＰ（Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌ）ファイルは、同じ告知チャネルを介して伝達されるべきである。他のメタデータフラグメントは、ＤＡＳＨコンテンツを運搬するブロードキャストチャネルを介して伝達されてもよく、ユニキャストを介してフェッチされてもよい。

サービス告知には次のようなメタデータフラグメントが含まれる。

少なくとも１つの伝達方法を含むＵＳＤメタデータフラグメント。ａｓｓｏｃｉａｔｅｄ−ＤｅｌｉｖｅｒｙＰｒｏｃｅｄｕｒｅＵＲＩ又はｐｒｏｔｅｃｔｉｏｎＤｅｓｃｒｉｐｔｉｏｎＵＲＩは存在してはならない。フラグメントは、ａｐｐＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎＵＲＩのＭＰＤを参照する１つのａｐｐＳｅｒｖｉｃｅ要素を含むべきである。開始部分は、相応する表現を伴うブロードキャストチャネルを介して分配されるべきである。

伝達機能は、トランスポートプロトコルとしてＦＬＵＴＥ５１０を使用する。複数のＦＬＵＴＥセッションがコンテンツ伝達のために用いられてもよく、ブロードキャスト表現のコンテンツは、１つのＦＬＵＴＥセッションのみを介して伝達される。ユニキャスト代替サービスがサポートされる。

ベアラプロファイル４１５
ベアラ４１５プロファイルは、最小限のデータ及び制御平面要素にてＭＢＭＳベアラサービスの使用を許容する最小限のユーザサービスを定義する。したがって、ＭＢＭＳ伝達を使用するアプリケーションにより多くの柔軟性を提供できる。ベアラ４１５プロファイルは、ＭＢＭＳミドルウェアにおいていかなる付加的な処理遅延を発生することなく、ＵＥが与えられたマルチキャストアドレスに転送されたＵＤＰ（ｕｓｅｒ ｄａｔａｇｒａｍ ｐｒｏｔｏｃｏｌ）データグラムを受信できるようにする。

ベアラプロファイルのサービス告知は次のように制限される：
サービス告知は、２つのメタデータフラグメント（ＵＳＤメタデータフラグメントとＳＤＰフラグメントのみ）で構成される。ＳＤＰフラグメントは、ＵＳＤフラグメントによって参照されるべきであって、挿入されてはならない。ｄｅｌｉｖｅｒｙＭｅｔｈｏｄ要素は、ｓｅｓｓｉｏｎＤｅｓｃｒｉｐｔｉｏｎＵＲＩ要素のみを含むべきである。

サービス告知は、次のうち１つ方法で伝達される。ＭＢＭＳアドレス解決（ｒｅｓｏｌｕｔｉｏｎ）要求に対する応答として、専用インタフェースを介して送信アプリケーションによってＵＥに直接提供される。ベアラプロファイルによって使用された伝達機能は、マルチキャストアドレスに伝達されたＵＤＰデータグラムに対するアクセスを提供すべきである。マルチキャストストリームの受信は、例えば、グループ通信イネーブラのＧＣ１インタフェースを使用して、ＵＥによって受信された外部シグナリングを介してトリガされてもよい。

より高い柔軟性のために、このプロファイルには、追加的な伝送機能が提供されない。このプロファイルは、例えば、ＭＢＭＳ上でＳＩＰ（ｓｅｓｓｉｏｎ ｉｎｉｔｉａｔｉｏｎ ｐｒｏｔｏｃｏｌ）及びＲＴＰを使用してグループ通信サービスを実現できるようにする。ＳＤＰは、アプリケーションによって使用されるトランスポートプロトコル及び構成に対する詳細な情報を提供する。

図６及び図７は、本開示の多様な実施形態によってＭＢＭＳ ＵＲＬを解決するための例示的なフローチャート６００及び７００を示す。例えば、図６及び図７に示すプロセスは、図２のサーバ２００又は図３のクライアント装置３００によって行われてもよい。

過程６０５にて、ＵＥ６０１は、ネームサーバ６０２を用いてＭＢＭＳ ＵＲＬを解決する。ＵＥ６０１は、サーバからコンテンツを要求する。例えば、ユーザは、クライアント装置３００上で視聴するビデオを選択し、クライアント装置３００は、ビデオに対する要求を、サーバ２００に送信する。サーバ２００は、当該要求を受信し、ビデオに対する要求を決定する。サーバ２００は、ビデオに対する要求がしきい値より大きい場合、ビデオに対する高い要求を決定し、ビデオに対する要求がしきい値より小さい場合は、低い要求を決定する。しきい値は、サーバの容量、要求の予め決定された数等で決定できる。ビデオに対する要求は、類似した製作者が製作したシリーズ物の以前のビデオの過去データに基づいてもよい。

過程６１０にて、ネームサーバ６０２は、ＭＢＭＳディスクリプションをＵＥ６０１に伝達するか、又は、ＵＥ６０１をＨＴＴＰ ＵＲＬにリダイレクトする。コンテンツが高い要求を有する時、サーバ２００は、ＭＢＭＳ伝達ディスクリプションをクライアント装置３００に送信する。サーバ２００がコンテンツに対する要求が低いと判断した場合、サーバ２００は、ＨＴＴＰ ＵＲＬにクライアント装置３００をリダイレクトする。ＭＢＭＳ伝達ディスクリプションは、アプリケーションプログラミングインタフェース（ＡＰＩ）に従ってＢＭ−ＳＣからコンテンツにアクセスするための情報を含む。ファイル伝達ＡＰＩがＭＢＭＳ伝達ディスクリプションを提供する時、受信されたＭＢＭＳ伝達ディスクリプションは、ファイルがＵＥ６０１にて使用可能になる時間フレームを有するブロードキャストファイルを含む。ＤＡＳＨ ＡＰＩが伝達ディスクリプションを提供する時、受信されたＭＢＭＳ伝達ディスクリプションは、コンテンツに対する初期化部分を有するオブジェクトフローのオブジェクト及びコンテンツの部分を一致させる規則を含む。ソケットＡＰＩがＭＢＭＳ伝達ディスクリプションを提供する時、受信されたＭＢＭＳ伝達ディスクリプションは、特定マルチキャストアドレスを含むセッションディスクリプションプロトコル（ｓｅｓｓｉｏｎ ｄｅｓｃｒｉｐｔｉｏｎ ｐｒｏｔｏｃｏｌ）を有するソケットオブジェクトを含む。過程６１５にて、ＵＥ６０１は、ＭＢＭＳセッションに参加する。

過程６２０にて、ＵＥ６０１は、ＢＭ−ＳＣ６０３から、ＭＢＭＳによるリソースを受信する。クライアント装置３００は、ソースからＢＭ−ＳＣを介してリソースを受信する。リソースは、ＢＭ−ＳＣがデータを生成することなく、ＢＭ−ＳＣを通過する。

過程７０５にて、ＵＥ７０１は、プロキシサーバ７０２にＨＴＴＰ ＵＲＬを要求する。クライアント装置３００は、サーバ２００にコンテンツを要求する。サーバ２００は、クライアント装置３００によって要求されたコンテンツをＭＢＭＳが使用可能であるかを決定する。ＭＢＭＳが使用可能でないと決定した場合、サーバ２００は、クライアント装置がコンテンツを受信するためのＨＴＴＰ ＵＲＬを送信する（図示せず）。

過程７１０にて、プロキシサーバ７０２は、ＵＥ７０１をＭＢＭＳ ＵＲＬにリダイレクトする。ＭＢＭＳが使用可能であると決定した場合、サーバ２００は、クライアント装置３００をＭＢＭＳ ＵＲＬにリダイレクトする。

過程７１５にて、ＵＥ７０１は、ネームサーバ７０３を用いてＭＢＭＳ ＵＲＬを解決する。クライアント装置３００は、ＭＢＭＳ ＵＲＬをサーバ２００に送信する。サーバ２００は、ＭＢＭＳ ＵＲＬに基づいてＭＢＭＳ伝達ディスクリプションを決定する。

過程７２０にて、ネームサーバ７０３は、ＭＢＭＳディスクリプションをＵＥ７０１に伝達する。サーバ２００は、コンテンツを受信するためにクライアント装置３００にＭＢＭＳ伝達ディスクリプションを送信する。ＭＢＭＳ伝達ディスクリプションは、ＡＰＩによってＢＭ−ＳＣからコンテンツにアクセスするための情報を含む。ファイル伝達ＡＰＩがＭＢＭＳ伝達ディスクリプションを提供する時、受信されたＭＢＭＳ伝達ディスクリプションは、ファイルがＵＥ６０１に使用可能になる時間フレームを有するブロードキャストファイルを含む。ＤＡＳＨ ＡＰＩが伝達ディスクリプションを提供する時、受信されたＭＢＭＳ伝達ディスクリプションは、コンテンツに対する初期化部分を有するオブジェクトフローのオブジェクト及びコンテンツの部分を一致させる規則を含む。ソケットＡＰＩがＭＢＭＳ伝達ディスクリプションを提供する時、受信されたＭＢＭＳ伝達ディスクリプションは、特定マルチキャストアドレスを含むセッションディスクリプションプロトコルを有するソケットオブジェクトを含む。過程７２５にて、ＵＥ７０１は、ＭＢＭＳセッションに参加する。

過程７３０にて、ＵＥ７０１は、ＢＭ−ＳＣ７０４からＭＢＭＳによるリソースを受信する。クライアント装置３００は、ソースからＢＭ−ＳＣを介してリソースを受信する。リソースは、ＢＭ−ＳＣがデータを生成することなく、ＢＭ−ＳＣを通過する。

ＭＢＭＳ ＵＲＩスキームは、この仕様において、ＭＢＭＳによって伝達されるか、又は、ＭＢＭＳによって潜在的に使用可能になり得るリソース及びストリームへのアクセスを単純化するために定義される。ＵＥ６０１は、ＭＢＭＳ ＵＲＩスキームを使用する全てのリソース要求を受信するために、ＭＢＭＳミドルウェアをＭＢＭＳプロトコルハンドラに登録する。

“ＭＢＭＳ”ＵＲＩは、次のようなＡＢＮＦ（ａｕｇｍｅｎｔｅｄ ｂａｃｋｕｓ−ｎａｕｒ ｆｏｒｍ）シンタックスを有する：
ｓｃｈｅｍｅ=“ｍｂｍｓ”“：”ｈｏｓｔ［“：”ｐｏｒｔ］“／”ｐａｔｈ
＜ｈｏｓｔ＞及び＜ｐｏｒｔ＞はＲＦＣ３９８６に指定されている。

“ＭＢＭＳ”ＵＲＩスキームは、ＭＢＭＳによって伝達されてもよいリソース又はデータストリームを参照するために用いられる。ＭＢＭＳ ＵＲＩは、図６及び図７で定義された手順を用いて、ＭＢＭＳプロトコルハンドラによって解決されるべきである。リソース又はストリームがＭＢＭＳによって伝達されなかった場合、ＵＥ６０１はユニキャスト伝達代替にリダイレクトされる。

アドレス解決手順は、次のステップに構成される：
受信されたＭＢＭＳ ＵＲＬを用いて、ＭＢＭＳプロトコルハンドラを起動する。ＭＢＭＳプロトコルハンドラは、“ＵＲＬ”の名前を有するＮＶＰ（ｎｅｔｗｏｒｋ ｖｏｉｃｅ ｐｒｏｔｏｃｏｌ）の値としてのＭＢＭＳ ＵＲＬを用いて、あらかじめ構成されたＭＢＭＳアドレス解決サーバ（ＡＲＳ）にＰＯＳＴリクエストを送信する。ＭＢＭＳ ＡＲＳは、ＭＢＭＳメタデータエンベロープで応答する。その代案として、ＭＢＭＳ ＡＲＳは、ＵＥ６０１を要求されたリソースのユニキャスト位置にリダイレクトする。

ＵＲＬが単一リソースを参照する場合、ＭＢＭＳ ＵＲＬとＦＬＵＴＥ ＵＲＬ間のマッピングは暗黙的（すなわち、ＭＢＭＳ体系をｈｔｔｐスキームに置き換える）であるか、アドレス解決応答の一部として明示的に提供されてもよい。また、他の関連リソースもＭＢＭＳによって使用できるというクライアントに対するＡＲＳの指示子（ｉｎｄｉｃａｔｉｏｎ）が、応答の一部として含まれる場合がある。ＳＤＰは、ＵＴＣ（Ｃｏｏｒｄｉｎａｔｅｄ Ｕｎｉｖｅｒｓａｌ Ｔｉｍｅ）時間に提供された伝送に対する時間情報を伝達すべきである。また、スケジュールメタデータフラグメントは、特定リソースの伝達時間を指定するために提供されてもよい。

ファイル伝達ＡＰＩは、ＭＢＭＳによってファイルを要求して受信するためのクライアント機能を提供するＡＰＩを定義する。ＡＰＩはリソースを要求し、要求されたファイルの状態に対するイベントを受信し、ＭＢＭＳによって伝達されたファイルにアクセスする機能を提供するＢｒｏａｄｃａｓｔＦｉｌｅオブジェクトを定義する。

ＢｒｏａｄｃａｓｔＦｉｌｅオブジェクトは、リソースのＭＢＭＳ ＵＲＬを取得する方法を提供する。ＢｒｏａｄｃａｓｔＦｉｌｅオブジェクトは、次のような作業を行う：
ＢｒｏａｄｃａｓｔＦｉｌｅオブジェクトは、ＭＢＭＳ ＵＲＬを解決して、ユニキャスト又はブロードキャストを介して伝達が行われているか否かを決定する。伝達がユニキャストを介して行われると、応答にはユニキャストアドレスへのリダイレクトが含まれるべきである。伝達がブロードキャストを介して行われる場合、応答はファイルがＵＥ６０１で使用可能になる時間フレームの指示子を含むべきである。ファイルが既に受信された場合、応答は、ＵＥ６０１上のファイルのローカル位置に対するＵＲＬを含むべきである。

ＢｒｏａｄｃａｓｔＦｉｌｅは次のイベントを定義する：
ファイル受信が進行中の場合、進行イベントが発生する。部分イベント（ｐａｒｔｉａｌ ｅｖｅｎｔ）は、ファイル受信が中断され使用可能な部分ファイルコンテンツがある場合に発生する。受信されたバイト範囲は、アプリケーションに提供される。受信されたイベントは、要求されたファイルが完全に受信されてフェッチされる準備ができた時に発生する。除去イベントは、要求されたファイルが指定された時間までローカルキャッシュから除去されるようにスケジュールされた場合に発生する。

ＤＡＳＨ ＡＰＩは、ＭＢＭＳによるＤＡＳＨプレゼンテーションのＲｅｐｒｅｓｅｎｔａｔｉｏｎｓのコンテンツにアクセスするためのクライアント機能を提供するＡＰＩを定義する。ＯｂｊｅｃｔＦｌｏｗのオブジェクトは、ＤＡＳＨ ＡＰＩによって定義されて関連ファイルのセットを検索する。ＯｂｊｅｃｔＦｌｏｗは、関心のあるＲｅｐｒｅｓｅｎｔａｔｉｏｎに対する初期化部分のＵＲＬと該当Ｒｅｐｒｅｓｅｎｔａｔｉｏｎの部分を一致させる規則を取る初期化方法を提供する。規則は、ＲｅｐｒｅｓｅｎｔａｔｉｏｎＩＤ、ＵＲＬテンプレート又は基本ＵＲＬとできる。

ＯｂｊｅｃｔＦｌｏｗは、次のイベントを定義する：
受信されたイベントは、オブジェクトフローのオブジェクトが受信された時に発生する。受信された最初のオブジェクトは、開始部分でなければならない。部分イベントは、オブジェクトフローの部分オブジェクトが受信された時に発生する。消えたイベントは、ＭＢＭＳ受信がこれ以上使用可能でなく、代わりにユニキャスト受信が用いられなければならない場合に発生した。

一般ソケットＡＰＩは、ＭＢＭＳによって伝達されるＵＤＰデータグラムストリームにアクセスするためのクライアント機能を提供するＡＰＩを定義する。ソケットオブジェクトは、特定マルチキャストデスティネーションアドレスに転送されたＵＤＰデータグラムを開いて受信するために、ソケットＡＰＩによって定義される。ソケットＡＰＩは、ＭＢＭＳ ＵＲＬを引数とし、セッションのＳＤＰを返す解決関数（ｒｅｓｏｌｖｅ ｆｕｎｃｔｉｏｎ）を提供する。ソケットＡＰＩは、マルチキャストデスティネーションアドレス及びＵＤＰポートを引数とする接続関数（ｃｏｎｎｅｃｔ ｆｕｎｃｔｉｏｎ）を提供する。ソケットＡＰＩは、ＭＢＭＳによって受信されたＵＤＰデータグラムペイロードを受信するために使用される受信関数（ｒｅｃｅｉｖｅ ｆｕｎｃｔｉｏｎ）を提供する。パケットは、受信されたときと同じ順序でアプリケーションに伝達される。ソケットＡＰＩは、また、次のイベントを定義する：
準備イベントは、１以上のパケットが受信準備できたことを受信機が通知された時に発生する。消えたイベントは、受信機がＭＢＭＳ受信がこれ以上使用可能でないという通知を受けると発生する。

図６及び図７は、それぞれＭＢＭＳ ＵＲＬを解決するためのフローチャート６００及び７００の例を示すが、図６及び図７に多様な変更が行われてもよい。例えば、一連のステップとして図示されたが、各図面の多様なステップは重なったり、並列的に発生したり、異なる順序で発生したり、又は複数回発生してもよい。

図８は、本開示の多様な実施形態によるベアラ伝達方法８００に対する例示的なＭＢＭＳフレーミング（ｆｒａｍｉｎｇ）を示す。図９は、本開示の多様な実施形態による例示的なＭＢＭＳフレーミングヘッダ９００を示す。図８に示すベアラ伝達方法８００、及び、図９に示すＭＢＭＳフレーミングヘッダ９００に対するＭＢＭＳフレーミングの実施形態は、単なる説明のためのものである。図８及び図９は、本開示の範囲を電子装置のいかなる特定の形態にも制限しない。

構成可能なフレーミングプロトコル、ＦＥＣフレームワーク、及び、バッファリングモデルは、サービスによる遅延及びエラー要件に基づいて、伝送の品質を調整するために開示される。ＭＢＭＳフレーミングプロトコル９１０は、ＭＢＭＳ特定機能を提供するためにユーザ平面ＵＤＰパケット９０５をカプセル化するよう定義される。ＭＢＭＳフレーミングプロトコル９１０は、ＵＤＰデータグラムのアドレッシング（ａｄｄｒｅｓｓｉｎｇ）及び損失したパケットの検出を許容する。ＦＥＣを使用すれば、ＦＥＣ復元データが別途のメディアセッションを介して伝達される。

ソースパケットは、ＵＤＰヘッダの直後にパケットシーケンス番号９１５を含むように修正される。ＵＤＰチェックサム９２０は、ＭＢＭＳフレーミングが行われた後、再計算されるべきである。ベアラ伝達方法に対するＳＤＰは、コンテンツを取り込んだ時にコンテンツ原点によって提供され、ＢＭ−ＳＣ６０３に対して透明（ｔｒａｎｓｐａｒｅｎｔ）である。ＳＤＰは、ＵＥ６０１へのアプリケーションを介してＭＢＭＳクライアントに直接提供される。ＳＤＰは、少なくとも次のＳＤＰパラメータを含む：宛先ＩＰアドレス及びポート番号、各メディアセッションに対するプロトコルＩＤ、ＭＢＭＳベアラの一時的モバイルグループアイデンティティ（ＴＭＧＩ）、最大遅延許容特性、及びメディアレベル属性としてセクション８．３．２．１で定義されたような要求されたＱｏＥ（ｑｕａｌｉｔｙ ｏｆ ｅｘｐｅｒｉｅｎｃｅ）報告。

“最大許容遅延（ｍａｘ−ａｌｌｏｗｅｄ−ｄｅｌａｙ）”は、ＵＤＰデータグラムを受信した時間から受信するアプリケーションに伝達する時間まで許容される最大許容遅延を受信機に知らせるメディアレベルＳＤＰ属性である。この時間は、ＦＥＣデコーディングのようなあらゆる演算に消耗される時間に上位境界を設定する。この値は、ミリ秒単位で表示される。

ＭＢＭＳフレーミングプロトコルの識別は、プロトコルＩＤの一部として提供される。例えば、ＭＢＭＳフレーミングプロトコルの識別は、ＭＢＭＳフレーミングプロトコル及びＵＤＰを介して伝達されるＲＴＰトラフィックのためのＵＤＰ／ＭＢＭＳ／ＲＴＰとできる。

本開示の特定の実施形態において、ＭＢＭＳフレーミングは、ＵＤＰデータグラムをＭＢＭＳ／ＵＤＰ／ＩＰパケットにカプセル化することによって行われてもよい。本開示の特定の実施形態において、測定されたサービス品質（ＱｏＳ）に関する情報は、サーバに折り返し報告される。

メトリック（ｍｅｔｒｉｃ）“ＵＤＰ＿Ｄａｔａｇｒａｍ＿Ｌｏｓｓ”は、ＭＢＭＳフレーミングパケットシーケンス番号の差によって検出された、連続的なＵＤＰデータグラム損失の数を表す。この測定項目はベアラ伝達方法にのみ適用される。

さらに別のメトリック“ＵＤＰ＿Ｄａｔａｇｒａｍ＿Ｊｉｔｔｅｒ”は、例えば、平均伝送遅延からの偏差で測定された測定遅延ジッタ（ｊｉｔｔｅｒ）を提供する。この測定を得るために、フレーミングプロトコルは、ＵＤＰデータグラムを送信する時、ＢＭ−ＳＣが設定した伝達タイムスタンプを有さなければならない。

例示的な実施形態を用いて本開示が記載されたが、多様な変更及び修正が当業者に提案されることができる。本開示は添付された請求の範囲内に属するそのような変更及び修正を含むことが意図される。

本開示の説明は、特定の要素、段階、又は機能が請求範囲に含まれるべき必須要素であることを暗示すると解釈されるべきではない。特許の範囲は請求範囲によってのみ限定される。

Claims (15)

1. 通信システムにおけるクライアント（ｃｌｉｅｎｔ）装置の動作方法であって、
   サーバにコンテンツの位置に対する要求を送信する過程と、
   前記コンテンツのためにＭＢＭＳ（ｍｕｌｔｉｍｅｄｉａ ｂｒｏａｄｃａｓｔ／ｍｕｌｔｉｃａｓｔ ｓｅｒｖｉｃｅｓ）が使用可能な場合、前記コンテンツの位置に対するＭＢＭＳ伝達（ｄｅｌｉｖｅｒｙ）ディスクリプション（ｄｅｓｃｒｉｐｔｉｏｎ）に基づいてブロードキャスト（ｂｒｏａｄｃａｓｔ）サービス（ｓｅｒｖｉｃｅ）を受信する過程と、
   前記コンテンツのために前記ＭＢＭＳが使用可能でない場合、前記コンテンツに対する非（ｎоｎ）ＭＢＭＳ ＵＲＬ（ｕｎｉｆｏｒｍ ｒｅｓｏｕｒｃｅ ｌｏｃａｔｏｒ）を受信する過程と、を含み、
   前記ＭＢＭＳ伝達ディスクリプションは、ＢＭ−ＳＣ（ｂｒｏａｄｃａｓｔ ｍｕｌｔｉｃａｓｔ−ｓｅｒｖｉｃｅ ｃｅｎｔｅｒ）に接続するための情報を含み、
   前記ＢＭ−ＳＣ（ｂｒｏａｄｃａｓｔ ｍｕｌｔｉｃａｓｔ−ｓｅｒｖｉｃｅ ｃｅｎｔｅｒ）に接続するための情報は、前記ＭＢＭＳ伝達ディスクリプションを提供するために使用されるＡＰＩ（ａｐｐｌｉｃａｔｉｏｎ ｐｒｏｇｒａｍｍｉｎｇ ｉｎｔｅｒｆａｃｅ）のタイプ（ｔｙｐｅ）に基づいて決定され、
   前記ＡＰＩのタイプはファイル（ｆｉｌｅ）ＡＰＩ、ＤＡＳＨ（ｄｙｎａｍｉｃ ａｄａｐｔｉｖｅ ｓｔｒｅａｍｉｎｇ ｏｖｅｒ ｈｙｐｅｒｔｅｘｔ ｐｒｏｔｏｃｏｌ）ＡＰＩ又はソケット（ｓｏｃｋｅｔ）ＡＰＩのうち少なくとも１つを含む、
   方法。
2. 前記ファイルＡＰＩはＭＢＭＳクライアント（ｃｌｉｅｎｔ）から前記要求されたコンテンツを受信するために使用される、請求項１に記載の方法。
3. 前記ＤＡＳＨ ＡＰＩは少なくとも１つのオブジェクトフローを受信するために使用され、
   前記少なくとも１つのオブジェクトフローの各々は、選択されたＤＡＳＨ表現（ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）に対応する同じオブジェクトフローの少なくとも１つのオブジェクトを含み、
   前記少なくとも１つのオブジェクトの各々は、ＤＡＳＨ部分（ｓｅｇｍｅｎｔ）に対応する、請求項１に記載の方法。
4. 前記ソケットＡＰＩは、前記要求されたコンテンツを運搬するマルチキャストストリームのカプセル化（ｃａｐｓｕｌｅｄ）されたＵＤＰ（ｕｓｅｒ ｄａｔａｇｒａｍ ｐｒｏｔｏｃｏｌ）パケット（ｐａｃｋｅｔ）を受信し、
   前記ソケットＡＰＩを使用して前記マルチキャスト（ｍｕｌｔｉｃａｓｔ）ストリーム（ｓｔｒｅａｍ）の受信をトリガ（ｔｒｉｇｇｅｒ）するために、ＭＢＭＳセッション（ｓｅｓｓｉｏｎ）ディスクリプション（ｄｅｓｃｒｉｐｔｉｏｎ）をＭＢＭＳクライアント（ｃｌｉｅｎｔ）に伝達する過程をさらに含む、請求項１に記載の方法。
5. 前方誤り訂正（ｆｏｒｗａｒｄ ｅｒｒｏｒ ｃｏｒｒｅｃｔｉｏｎ、ＦＥＣ）フレームワーク（ｆｒａｍｅｗｏｒｋ）に基づいてＭＢＭＳセッションを介して前記コンテンツに対するリソースを受信する過程をさらに含む、請求項１に記載の方法。
6. 前記コンテンツの位置に対する要求は、前記ＭＢＭＳが使用可能か否かを前記サーバが決定するために前記サーバに送信するＭＢＭＳ ＵＲＬを含む、請求項１に記載の方法。
7. 前記コンテンツの位置に対する要求は、前記サーバが前記コンテンツに対するＭＢＭＳ ＵＲＬが解決（ｒｅｓｏｌｕｔｉｏｎ）可能か否かを判断するために、前記サーバに送信するＨＴＴＰ（ｈｙｐｅｒｔｅｘｔ ｔｒａｎｓｍｉｓｓｉｏｎ ｐｒｏｔｏｃｏｌ） ＵＲＬを含み、
   前記コンテンツに対する前記ＭＢＭＳ伝達ディスクリプションは前記ＭＢＭＳ ＵＲＬが解決された（ｒｅｓｏｌｖｅｄ）後に受信される、請求項１に記載の方法。
8. 請求項１乃至請求項７のうち何れか一項に記載の方法を実現するように構成された装置。
9. サーバであって、
   メモリと、
   前記メモリに動作可能に結合された１以上のプロセッサを含み、
   前記１以上のプロセッサは、
   クライアント装置からコンテンツの位置に対する要求を受信し、
   前記コンテンツのためにＭＢＭＳ（ｍｕｌｔｉｍｅｄｉａ ｂｒｏａｄｃａｓｔ／ｍｕｌｔｉｃａｓｔ ｓｅｒｖｉｃｅｓ）が使用可能な場合、前記コンテンツの位置に対するＭＢＭＳ伝達（ｄｅｌｉｖｅｒｙ）ディスクリプション（ｄｅｓｃｒｉｐｔｉｏｎ）に基づいてブロードキャスト（ｂｒｏａｄｃａｓｔ）サービスを送信し、
   前記ＭＢＭＳ伝達ディスクリプションは、ＢＭ−ＳＣ（ｂｒｏａｄｃａｓｔ ｍｕｌｔｉｃａｓｔ−ｓｅｒｖｉｃｅ ｃｅｎｔｅｒ）に接続するための情報を含み、
   前記ＢＭ−ＳＣ（ｂｒｏａｄｃａｓｔ ｍｕｌｔｉｃａｓｔ−ｓｅｒｖｉｃｅ ｃｅｎｔｅｒ）に接続するための情報は、前記ＭＢＭＳ伝達ディスクリプションを提供するために使用されるＡＰＩ（ａｐｐｌｉｃａｔｉｏｎ ｐｒｏｇｒａｍｍｉｎｇ ｉｎｔｅｒｆａｃｅ）のタイプ（ｔｙｐｅ）に基づいて決定され、
   前記ＡＰＩのタイプはファイル（ｆｉｌｅ）ＡＰＩ、ＤＡＳＨ（ｄｙｎａｍｉｃ ａｄａｐｔｉｖｅ ｓｔｒｅａｍｉｎｇ ｏｖｅｒ ｈｙｐｅｒｔｅｘｔ ｐｒｏｔｏｃｏｌ）ＡＰＩ又はソケット（ｓｏｃｋｅｔ）ＡＰＩのうち少なくとも１つを含む、
   サーバ。
10. 前記１以上のプロセッサは、前記コンテンツに対する要求及びしきい値に基づいて、前記ＭＢＭＳが前記コンテンツに対して使用可能か否かを決定するように構成される、請求項９に記載のサーバ。
11. 前記ＭＢＭＳ伝達ディスクリプションは、通過されるブロードキャストマルチキャストサービスセンター（ＢＭ−ＳＣ）を介して前記コンテンツを伝達する方法を含む、請求項９に記載のサーバ。
12. 前記１以上のプロセッサは、ＭＢＭＳセッションを介して前記コンテンツに対するリソースを送信するために前方誤り訂正（ｆｏｒｗａｒｄ ｅｒｒｏｒ ｃｏｒｒｅｃｔｉｏｎ、ＦＥＣ）フレームワーク（ｆｒａｍｅｗｏｒｋ）を使用するようさらに構成される、請求項９に記載のサーバ。
13. 前記ファイルＡＰＩはＭＢＭＳクライアント（ｃｌｉｅｎｔ）から前記要求されたコンテンツを受信するために使用される、請求項９に記載のサーバ。
14. 前記ＤＡＳＨ ＡＰＩは少なくとも１つのオブジェクトフローを受信するために使用され、
    前記少なくとも１つのオブジェクトフローの各々は、選択されたＤＡＳＨ表現（ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）に対応する同じオブジェクトフローの少なくとも１つのオブジェクトを含み、
    前記少なくとも１つのオブジェクトの各々は、ＤＡＳＨ部分（ｓｅｇｍｅｎｔ）に対応する、請求項９に記載のサーバ。
15. 前記ソケットＡＰＩは、
    前記要求されたコンテンツを運搬するマルチキャスト（ｍｕｌｔｉｃａｓｔ）ストリーム（ｓｔｒｅａｍ）のカプセル化（ｃａｐｓｕｌｅｄ）されたＵＤＰ（ｕｓｅｒ ｄａｔａｇｒａｍ ｐｒｏｔｏｃｏｌ）パケット（ｐａｃｋｅｔ）を受信し、
    前記１以上のプロセッサは、
    前記ソケットＡＰＩを使用して前記マルチキャストストリーム（ｓｔｒｅａｍ）の受信をトリガ（ｔｒｉｇｇｅｒ）するために、ＭＢＭＳセッション（ｓｅｓｓｉｏｎ）ディスクリプション（ｄｅｓｃｒｉｐｔｉｏｎ）をＭＢＭＳクライアント（ｃｌｉｅｎｔ）に伝達するようにさらに構成される、請求項９に記載のサーバ。
    

Images