JP6702875B2 - マルチメディアシステムにおけるメディアデータを送受信するための方法及び装置 - Google Patents

Description

本開示は、メディアデータを送受信するための方法及び装置に関する。より具体的には、本開示は、マルチメディアシステムにおけるメディアデータを送受信するためのデータパケットの生成、送信、及び受信方法及び装置に関する。

マルチメディアサービスにおいて、ブロードキャストネットワークと通信ネットワークとの両方に接続するハイブリッドネットワークと、送信しようとしているマルチメディアデータ、アプリケーション、及びウェブページのようなファイルを含むマルチメディアデータを提供するためのムービングピクチャーエクスパーツグループ（Moving Picture Experts Group：ＭＰＥＧ）メディアトランスポート（MPEG Media Transport：以下、‘ＭＭＴ’と称する）技術が最近に開発されてきた。

‘マルチメディアサービス’との用語は、画像電話のような対話型サービスと、ビデオオンデマンド（VideoOnDemand：ＶｏＤ）サービスのようなストリーミングサービスと、マルチキャスト及びブロードキャストサービスとを意味する。実時間マルチメディアサービスは、サービスタイプに従って、対話型サービス、インタラクティブサービス、及びストリーミングサービスに分類できる。また、実時間マルチメディアサービスは、サービスに参加しているユーザの数に従って、ユニキャスト、マルチキャスト、及びブロードキャストに分類でき、それによる送信要求条件が変わる。

ＭＭＴ技術は、ＭＰＥＧ基盤マルチメディア送信技術に関し、多機能スマートテレビジョン（ＴＶ）、マルチビュー（Multi-view）ＴＶ、Ｎ−スクリーン（N-Screen）デバイスへのブロードキャスト及びマルチメディアサービスのためにＭＰＥＧ−２トランスポートストリーム（TransportStream：ＴＳ）の代わりに使用され、インターネットプロトコル（InternetProtocol：ＩＰ）基づいて変化するマルチメディアサービス環境で効率的なＭＰＥＧトランスポート技術を提供し得る。

また、マルチメディアデータの消費の増加及び技術の発展により、従来の１つ又は２つのマルチメディアソースだけが消費された時代から、上述したマルチメディアデータ、アプリケーション、及びファイルのような様々なタイプのマルチメディアコンテンツを含むマルチメディアデータが登場する時代に変化した。

マルチメディアデータは、様々なタイプのマルチメディアコンテンツを含み得る。マルチメディアデータの送信の間に、マルチメディアデータは、それぞれのマルチメディアコンテンツに分割化又は融合化され、マルチメディアコンテンツは、統合送信ネットワークを通して送信され得る。

例えば、ビデオ、オーディオ、及びウィジェットなどのアプリケーションで構成されたマルチメディアデータは、ビデオ信号送信方法、オーディオ信号送信方法、及びファイル送信方法の特性を考慮してデータパケットで構成され送信され得る。送信されたデータパケットは、受信端末でマルチメディアデータに再構成され得る。

現在まで論議され定義されたネットワークを通してマルチメディアデータを送信する場合に、ネットワーク環境に適合した効率的なサービスを提供することが難しいという問題がある。

したがって、ネットワーク環境に適合した効率的なサービスを提供するために、マルチメディアデータの特性に基づくマルチメディアデータパケットを構成する必要があり、マルチメディアデータの特性に基づくマルチメディアデータパケットを提供するために、対応するマルチメディアコンテンツの構成及び分解に対する技術が要求される。

上述した情報は、本発明の理解を助けるために背景情報としてのみ提示される。本発明に対する先行技術で適用されることができるか否かに関してはいかなる決定及びいかなる主張もない。

本発明の態様は、少なくとも上述した問題点及び／又は不都合を解決し、少なくとも以下の利点を提供することにある。すなわち、本発明の一態様は、マルチメディアシステムにおけるメディアデータを送信するためのデータパケット生成方法及び装置を提供することである。

本発明の他の態様は、マルチメディアサービスの要求事項により、ムービングピクチャーエクスパーツグループ（ＭＰＥＧ）メディアトランスポート（ＭＭＴ）パケットデータヘッダ情報、ペイロード情報、及びＭＭＴパケットを送信するために必要とされる情報を定義するためのデータパケット生成方法及び装置を提供することである。

上記のような目的を達成するために、本発明の一態様によれば、マルチメディアシステムにおけるメディアデータを送信するための方法が提供される。上記方法は、上記メディアデータにより構成されるマルチメディアサービスの送信要求条件により生成されるトランスポートパケットヘッダフォーマット及び送信構造を決定する動作と、上記決定されたトランスポートヘッダフォーマット及び送信構造により上記メディアデータの基本送信単位を生成する動作と、上記生成された基本送信単位に基づいて上記メディアデータを少なくとも１つのパケットにパケット化する動作と、上記パケット化されたメディアデータを送信する動作とを含むことを特徴とする。

本発明の他の態様によれば、マルチメディアシステムにおけるメディアデータを送信するための装置が提供される。上記装置は、上記メディアデータにより構成されるマルチメディアサービスの送信要求条件に基づいてトランスポートパケットヘッダフォーマット及び送信構造を選択し、上記選択されたトランスポートパケットヘッダフォーマット及び送信構造により上記メディアデータの基本送信単位を生成するように構成されるデータパケット生成器と、上記生成された送信単位に基づいて上記マルチメディアデータを少なくとも１つのパケットにパケット化し、上記パケット化されたマルチメディアデータを送信するように構成される送受信器とを含むことを特徴とする。

本発明のさらに他の態様によれば、マルチメディアシステムにおけるメディアデータを受信するための方法が提供される。上記方法は、上記メディアデータを構成するマルチメディアの個数により予め決定されたパケットヘッダフォーマットのうちで選択された１つのパケットヘッダフォーマットにより生成された基本送信単位を受信する動作と、上記基本送信単位のヘッダを決定する動作と、上記決定されたヘッダに関する情報を用いて上記基本送信単位に基づいてパケット化された上記メディアデータを取得する動作とを含むことを特徴とする。

本発明のさらなる他の態様によれば、マルチメディアシステムにおけるメディアデータを受信するための装置が提供される。上記装置は、上記メディアデータを構成するパケットヘッダフォーマットを含む基本送信単位を再構成し受信するように構成される送受信器と、上記受信された基本送信単位のヘッダを決定するように構成されるヘッダ検出器と、上記決定されたヘッダに関する情報を用いて上記基本送信単位に基づいてパケット化された上記メディアデータを受信するように構成される制御器とを含むことを特徴とする。

本発明の実施形態の上述した及び他の様相、特徴、及び利点は、添付の図面が併用された以下の詳細な説明から、より一層明らかになるだろう。

本開示は、マルチメディアデータを伝達するためのデータパケットを構成するために、マルチメディアコンテンツにより対応するデータの構成及び分解のための具体的な送信構造を定義し、上記送信構造に基づいて構成されたデータパケットを送受信することにより、マルチメディアデータの送信の間にネットワーク環境に適合した効率的なサービスを提供できる。

本開示の一実施形態によるメディアトランスポート（ＭＭＴ）でのマルチメディアコンテンツを処理するレイヤーを示す図である。 本開示の一実施形態によるマルチメディアデータを伝達するためのデータパケットを送信する装置を概略的に示す図である。 本開示の一実施形態によるサービスにより可変的なデータ送信構造を示す図である。 本開示の一実施形態によるメディアデータのパケットを生成する動作を示す図である。 本開示の一実施形態によるマルチメディアデータを受信する装置の構造を示す 図である。 本開示の一実施形態による送信装置でのメディアデータを送信するための方法を示す図である。

図面中、同一の図面参照符号が同一の構成要素、特性、又は構造を意味することは、容易に理解できるはずである。

添付の図面を参照した下記の説明は、特許請求の範囲の記載及びこれと均等なものの範囲内で定められるような本発明の実施形態の包括的な理解を助けるために提供するものであり、この理解を助けるために様々な特定の詳細を含むが、唯１つの実施形態に過ぎない。従って、本発明の範囲及び趣旨を逸脱することなく、ここに説明する実施形態の様々な変更及び修正が可能であるということは、当該技術分野における通常の知識を有する者には明らかである。また、明瞭性と簡潔性の観点から、当業者に良く知られている機能や構成に関する具体的な説明は、省略する。

次の説明及び請求項に使用する用語及び単語は、辞典的意味に限定されるものではなく、発明者により本発明の理解を明確且つ一貫性があるようにするために使用する。従って、特許請求の範囲とこれと均等なものに基づいて定義されるものであり、本発明の実施形態の説明が単に実例を提供するためのものであって、本発明の目的を限定するものでないことは、本発明の技術分野における通常の知識を持つ者には明らかである。

本願明細書に記載の各要素は、文脈中に特に明示しない限り、複数形を含むことは、当業者には理解できるはずである。したがって、例えば、“コンポーネント表面（a component surface）”との記載は、１つ又は複数の表面を含む。

“実質的に(substantially)”という用語は、提示された特徴、パラメータ、又は値が正確に設定される必要はないが、許容誤差、測定誤り、測定精度限界及び当業者に知られているか、あるいは当業者により実験なしに得られる要素を含む偏差又は変化が、これらの特性が提供しようとする効果を排除しない範囲内で発生することを意味する。

以下、本発明の実施形態による動作原理について、添付の図面を参照して説明する。

以下では、本開示が適用可能な技術のうちの１つであるムービングピクチャーエクスパーツグループ（Moving Picture Experts Group：ＭＰＥＧ）メディアトランスポート（MPEG Media Transport：以下、‘ＭＭＴ’と称する）技術を例に挙げて説明するが、これは、説明の目的のためのものであるだけであり、本開示が必ずしもＭＭＴ技術のみに適用されるものではなく、他の類似のマルチメディア送信技術にも適用され得ることに留意すべきである。

詳細な説明に先立って、本開示の基本概念が下記で簡略に説明される。

本開示の一実施形態において、ネットワーク環境は、サーバ及びクライアントの接続構造を有し、ブロードキャストのための専用ネットワーク（以下、‘ブロードキャストネットワーク’と称する）及びインターネット通信のためのネットワーク（以下、‘ブロードバンドネットワーク'と称する）を同一のクライアントに提供でき、クライアントが、複数のネットワークを通してサービスを受信できる環境を意味する。また、複数のネットワーク環境を、ブロードキャストネットワークとブロードバンドネットワークとを並列に接続して構成してもよいし、有線又は無線ネットワークを含めて構成してもよい。

以下では、本開示の様々な実施形態について添付の図面を参照して詳細に説明する。

特に、下記の図１乃至図６、及び、本特許文書で開示された内容の原理を記述するために使用される様々な例示的な実施形態は、例示のみのためのものであり、上記開示された内容の範囲を限定するいかなる方式でも解釈されるべきでない。当業者は、上記開示された内容の原理が、適合に配列された通信システムでも実現されることができることを理解するのであろう。様々な実施形態を記述するために使用される用語は例示的なものである。これらの用語は、単純に詳細な説明の理解を助けるために提供されるものであることを留意しなければならない。これらの用語の使用及び定義は、いかなる方法でも本発明の範囲を限定しない。第１、第２などの用語は、同一の技術を有する対象を区別するために使用され、明示的な説明がない限りはいかなる方法でも順序を示すことを意図しない。セット(set）は、少なくとも１つのエレメントを含む空いていない（non-empty）セットとして定義される。

図１は、本開示の一実施形態によるＭＭＴでのマルチメディアコンテンツを処理するレイヤーを示す図である。

図１を参照すると、カプセル化（Encapsulation）レイヤー（E layer）が示され、カプセル化レイヤーは、３つのサブレイヤー（sub layer）のうちの１つ以上を含む。この３つのサブレイヤーは、マルチメディア（メディア）コーデック（Ａ）１００、マルチメディア（メディア）コーデック（Ｂ）１０１、及びＭＭＴ Ｅ．３サブレイヤー１０２に対応していてもよい。

マルチメディアコーデック（Ａ）１００及びマルチメディアコーデック（Ｂ）１０１は、それらの機能の観点で相互に異なる。

例えば、Ｈ．２６４コーデックにおいて、ディジタル圧縮されたビデオマルチメディアにマルチメディアの特性情報及び復号化に必要なシグナリングなどを提供するネットワークアダプテーションレイヤー（NetworkAdaptationLayer：ＮＡＬ）ユニットが、Ｈ．２６４コーデックの出力であってもよい。もう１つの例として、Ｈ．２６２コーデックでは、ディジタル圧縮ビデオマルチメディアだけが、Ｈ．２６２コーデックの出力であってもよい。

例えば、Ｈ．２６４コーデックがマルチメディアコーデック（Ｂ）１０１として使用され、Ｈ．２６２コーデックがマルチメディアコーデック（Ａ）１００として使用されてもよい。しかしながら、場合によっては、Ｈ．２６４コーデックがマルチメディアコーデック（Ａ）１００としても使用されてもよい。したがって、Ｈ．２６４コーデックの出力は、ＭＭＴ Ｅ．３サブレイヤー１０２で生成された情報をさらに含んでいてもよい。

ＭＭＴ Ｅ．３サブレイヤー１０２は、様々なタイプのマルチメディアをソースとして受信することにより、メディアフラグメントユニット（ＭＦＵ）を生成できる。ＭＦＵの機能は、上述したＮＡＬユニットの機能と類似しており、トランスポートパケットの構成に使用できる送信データユニットの範囲内での重要度及び相関情報（すなわち、依存性カウンタ）を含む。しかしながら、ＭＦＵは、ビデオ信号に加えて、音声、テキスト、アプリケーション、及びウェブページのようなすべてのタイプのマルチメディアソースをペイロードとして有することができるという点で、ＮＡＬユニットとは異なる。ＭＭＴ Ｅ．３サブレイヤー１０２の機能は、後述する図２、図３、及び図４に関連して詳細に説明する。

図１に示すように、ＭＭＴ Ｅ．２サブレイヤー１０３は、１つのマルチメディアソースから提供された様々なタイプのＭＦＵを集めることによりメディア処理ユニット（ＭＰＵ）を構成する。ＭＭＴ Ｅ．２サブレイヤー１０３は、ＭＰＵを１つのストリームに構成するＭＭＴアセットを生成する。

図１に示すように、ＭＭＴ Ｅ．１サブレイヤー１０４は、複数のＭＭＴアセットを使用してユーザにサービスできるＭＭＴパッケージを構成する。

本開示の実施形態による送信装置は、上述したＭＰＵ及びＭＦＵでマルチメディアデータ送信のための基本送信単位を構成し、それをパケット化した後に基本送信単位を受信装置に送信する。

ＭＰＵは、消費可能な最小単位であるＭＦＵで構成され、独立した構成が可能である場合に、空間的な間隔単位のバンドル形態でユーザにより消費されるか、又は、ユーザに伝達できるように構成される。また、送信環境により、１つのＭＰＵ内で送信効率性を考慮してＭＦＵの構成を可変的に調節できる。

本開示において、送信装置でのマルチメディアデータを送信するための方法は、パケットヘッダを構成するためのパケットヘッダ構成動作、及び、パケットのペイロードを構成するためのパケットペイロード構成動作を含む。パケットヘッダ構成動作及びパケットペイロード構成動作を、個別に説明する。

ＭＭＴパケットのペイロードは、送信環境により使用される構成情報を含むペイロードヘッダ領域、及び、送信データを含むデータ領域を含み得る。また、ＭＭＴパケットのペイロードは、インターネットプロトコル（ＩＰ）基盤プロトコルである送信制御プロトコル（TransmissionControlProtocol：ＴＣＰ）／ユーザデータグラムプロトコル（UserDatagramProtocol：ＵＤＰ）の環境で動作するＭＭＴトランスポートパケット又はＩＰである実時間トランスポートプロトコル（Real-timeTransportProtocol：ＲＴＰ）のペイロードに含まれることにより端末に送信される。

図２は、本開示の一実施形態によるマルチメディアデータを伝達するためのデータパケットを送信する装置を概略的に示す図である。

図２を参照すると、送信装置２００が図示され、送信装置２００は、送受信部２０５、データパケット生成部２１０、及び制御部２１５のうちの１つ以上を含む。

データパケット生成部２１０は、メディアデータを構成するマルチメディアの個数により予め定められたＭＦＵヘッダフォーマットのうちの１つを選択し、この選択されたヘッダフォーマットに従ってマルチメディアデータのＭＦＵを生成する。

送受信部２０５は、（制御部２１５の指示の下で）基本ＭＦＵによりマルチメディアデータをパケット化し、パケット化されたマルチメディアデータを受信装置に送信する。

制御部２１５は、マルチメディアの個数が第１のしきい値未満であるか否かを判定できる。マルチメディアの個数が第１のしきい値未満である場合に、制御部２１５は、第１のＭＦＵヘッダを選択できる。ここで、第１のＭＦＵヘッダは、ＭＦＵの開始を示す予め定義されたタイプの開始フラグフィールド、ＭＦＵに含まれたメディアのタイプを示すＭＦＵタイプフィールド、及びＭＦＵが特定のマルチメディアデータの最初のＭＦＵであるか（例えば、‘Ｓｔａｒｔ’）、ＭＦＵが最後のＭＦＵであるか（例えば、‘Ｅｎｄ’）、又は新たなＭＦＵがＭＦＵの後に継続するか（例えば、‘Ｃｏｎｔｉ’）を示すラストフラグ（lastflag）フィールドのうちの１つ以上を含む。

制御部２１５は、マルチメディアの個数が第１のしきい値以上である場合に、マルチメディアのうちで所定の基準を満足するマルチメディアの個数が第２のしきい値以上であるか否かを判定する。この所定の基準を満足するマルチメディアの個数が第２のしきい値以上でない場合に、制御部２１５は、第２のＭＦＵヘッダを選択する。ここで、第２のＭＦＵヘッダは、開始フラグフィールド、ＭＦＵタイプフィールド、及びラストフラグフィールドのうちの１つ以上を含む。第２のＭＦＵヘッダのＭＦＵタイプフィールドの長さは、第１のＭＦＵヘッダのＭＦＵタイプフィールドの長さより長いことがある。

制御部２１５は、この所定の基準を満足するマルチメディアの個数が第２のしきい値以上である場合に、第３のＭＦＵヘッダを選択する。ここで、第３のＭＦＵヘッダは、開始フラグフィールド、ＭＦＵタイプフィールド、及びラストフラグフィールドのうちの１つ以上を含み、ＭＦＵタイプ拡張フィールドをさらに含む。ＭＦＵタイプ拡張フィールドは、第３のＭＦＵヘッダのＭＦＵタイプフィールド組み合わされることにより、ＭＦＵに含まれたメディアのタイプを示す。第３のＭＦＵヘッダのラストフラグフィールドは、ＭＦＵタイプ拡張フィールドの存在を示す。

制御部２１５、データパケット生成部２１０、及び送受信部２０５は、必ずしも個別の構成要素として具現されなければならないというわけではなく、例えば、単一のチップ及び／又は単一のチップ上のソフトウェアの形態で１つの構成要素として具現できることは明らかである。

図３は、本開示の一実施形態によるサービスにより可変的なデータ送信構造を示す図である。

図３を参照すると、ＭＰＵファイル３０１が図示され、ＭＰＵファイル３０１は、カプセル化機能レイヤーが送信することを希望するデータを含むファイルであり、ＭＰＵ／ＭＦＵビルディングブロック（BuildingBlock）３１３が図示され、ＭＰＵ／ＭＦＵビルディングブロック３１３は、送信データを構成するためのデータ構造に対応する。ＭＰＵ／ＭＦＵビルディングブロックは、ＭＰＵ／ＭＦＵパケット化ブロックと呼ぶこともできる。

ＭＰＵファイル３０１は、ファイルのタイプを示すファイルタイプ（ＦＴＹＰ）ボックス３０３、ＭＰＵの構成を示すＭＰＥＧメディア処理ユニット（MPEGMediaProcessingUnit：ＭＭＰＵ）ボックス３０５、コーデック構成情報を示すムービー（ＭＯＯＶ）ボックス３０７、ムービーフラグメント（ＭＯＯＦ）ボックス３０９のようなヘッダ情報を含み、複数のビデオサンプル（Videosamples：ＶＳｓ）及び複数のＭＭＴヒントサンプル（HintSamples：ＨＳｓ）で構成されるメディアデータ（ＭＤＡＴ）ボックス３１１をさらに含む。ＭＰＵファイル３０１は、２つ以上のＭＤＡＴボックスを含むこともある。

ＭＭＰＵボックス３０５は、ＭＤＡＴボックス３１１に記憶されたデータのタイプがＭＰＵであることを示し、ＭＯＯＶボックス３０７は、ＭＤＡＴボックス３１１に記憶されたメディアフレームに関する情報を含む。

ＭＰＵ／ＭＦＵビルディングブロック３１３は、ＦＴＹＰ、ＭＭＰＵ、ＭＯＯＶ、及びＭＯＯＦのうちの１つ以上を含むＭＰＵメタデータ３１５を有する。好ましくは、ＭＰＵメタデータ３１５は、ＦＴＹＰ、ＭＭＰＵ、及びＭＯＯＶのうちの少なくとも１つを含み、したがって、ＭＯＯＦは、他のメタデータ（すなわち、ＭＯＯＦメタデータ）に含まれる。ＭＰＵ／ＭＦＵビルディングブロック３１３は、関連した複数のＨＳ及びＶＳの対で構成される１つ以上のＭＦＵ（例えば、３１７、３１９、及び３２１）を有する。例えば、ＨＳ＃１及びＶＳ＃１は、１つのＭＦＵ３１７に含まれ、ＨＳ＃２及びＶＳ＃２は、他のＭＦＵ３１９に含まれる。

ＭＭＴペイロードは、ＭＰＵ／ＭＦＵビルディングブロック３１３に基づいて構成され、ＭＭＴパケットに乗せて伝達できる。

本開示の一実施形態による送信装置がＭＭＴペイロードを構成する具体的な手順は、次のとおりである。

送信装置のデータパケット生成部は、所望するＭＰＵファイルタイプのデータを分析することにより、ＭＰＵデータのヘッダ情報から、タイプ、ＭＰＵの構成情報、コーデックの設定情報、及びデータの開始点及びサイズ（又は長さ）情報を決定できる。

また、データパケット生成部は、ＭＰＵデータを構成するＭＦＵ及びＭＦＵ ＨＳの構造を分析することにより、各ＭＦＵのサイズ、相互の優先順位及び相互接続情報（例えば、長さなど）を含んでいるＭＦＵヘッダ及び実際のメディアデータであるＭＦＵデータを決定し、各ＭＦＵの開始オフセット及び長さを示すＭＦＵ ＨＳに基づいて、各ＭＦＵのサイズを分析することもできる。分析されたＭＰＵタイプに基づいて、トランスポートパケットを構成するためのＭＰＵ／ＭＦＵビルディングブロックを構成できる。ＭＦＵ ＨＳは、ビルディングブロックのＭＦＵヘッダに対応する。

また、データパケット生成部は、複数のＭＦＵ ＨＳから分析された各ＭＦＵのサイズに基づいて各ＭＦＵを送信単位として構成する。ＭＦＵのサイズにより、１つ又は複数のペイロードが構成される。各ペイロードの開始、中間、及び終わりは、選択的なビット（optionalbits）であるｓｔａｒｔ＿ｅｎｄ＿ｉｎｄｉｃａｔｏｒにより示される。ＭＰＵメタデータ３１５は、ＭＰＵ／ＭＦＵビルディングブロック３１３の１つの構成単位とも見なされる。

図４は、本開示の一実施形態によるメディアデータのパケットを生成する動作を示す図である。

図４を参照すると、本開示の実施形態による単一のサイズのＭＰＵを送信する方法において、サービスの要求事項を分析することによりＭＰＵを分割し送信する場合に、送信装置は、ＭＰＵ再生に必要なＦＴＹＰ、ＭＭＰＵ、ＭＯＯＶ、及びＭＯＯＦのうちの１つ以上で構成された制御情報ペイロードを周期的にかつ可変的にパケット化し送信する。一例として、制御情報ペイロードは、ＦＴＹＰ、ＭＭＰＵ、及びＭＯＯＶのうちの少なくとも１つを含むＭＰＵメタデータを有する。他の例として、制御情報ペイロードは、ＭＯＯＦを含むＭＯＯＦメタデータを有する。

その結果、受信装置は、より迅速にＭＰＵを再生させる。制御情報ペイロードは、単一の情報（すなわち、ＭＯＯＶ）を含み、送信装置は、１つ又は複数のＭＦＵの間隔で制御情報ペイロードを反復して挿入することにより制御情報を送信する。

本開示の実施形態による可変長さの送信データは、送信環境により単一のペイロード又は基本単位のサイズに対応する複数のペイロードに分割され、複数のペイロードで送信される。このとき、各ペイロードは、それぞれのパケットでパケット化されることにより送信される。また、複数のペイロードに対して、それらのパケットは、マルチプレキシングされることによりネットワークチャネルを通して送信される。

また、送信装置は、特定の送信機能を考慮して所定の単位でインターリービング機能を提供し、このペイロードは、トランスポートレイヤーの可能な一般的な単位構造（すなわち、相当に簡素な単位構造）として定義される。図４に示すように、送信装置は、動作４０１において、クライアントからマルチメディアのサービス要請を受信し、要請されたメディアデータを送信するためのパケット生成方法を開始し得るが、動作４０１は、常に発生するのでなく、選択的に実行され得る。

動作４０３において、送信装置は、要請されたサービスの送信要求条件（例えば、アセットデリバリ特性（AssetDeliveryCharacteristics：ＡＤＣ））の分析／処理を行う動作を実行する。

動作４０５において、分析／処理の結果として、送信装置は、要請されたサービスが実時間送信を要請するサービスであるか又は非実時間サービスであるかを判定する。選択的に、送信装置は、ビデオオンデマンド（Videoon Demand：ＶｏＤ）サービスであるかを決定する。

動作４０５の結果で、要請されるサービスが非実時間サービスである場合に、送信装置は、動作４１５において、所定のサイズの単位パケットを生成する。

動作４０５の結果で、要請されるサービスが実時間サービス（例えば、ストリーミングサービス）である場合に、送信装置は、動作４０７において、付加の判定を選択的に実行する。

動作４０７において、送信装置は、要請されるサービスが高速の実時間送信を保証しなければならないサービスであるか否かを判定する。要請されるサービスが高速の実時間送信を要請するサービスである場合には、送信装置は、動作４０９において、制御情報ペイロードを含む少なくとも１つのパケットを生成し、周期的なパケット送信（例えば、少なくとも１つのＭＦＵの間隔で）を実行する。一例として、そのような短い間隔でパケットで周期的に送信される制御情報ペイロードは、ＦＴＹＰ、ＭＭＰＵ、及びＭＯＯＶのうちの少なくとも１つを含むＭＰＵメタデータを有する。他の例として、制御情報ペイロードは、ＭＯＯＦを含むＭＯＯＦメタデータを有する。好ましくは、ＭＰＵメタデータは、ＭＯＯＦメタデータよりさらに頻繁に（すなわち、そのような短い間隔で）送信される必要がある。要請されたサービスが実時間送信を要請するとしても、高速の実時間送信を要請しない場合に、送信装置は、動作４１１において、ＭＰＵヘッダを分析し、ＭＰＵの単位でパケットを生成し、制御情報ペイロードを含む生成されたパケットを送信する。

動作４０５において、要請されたサービスがＶｏＤサービスであると判定される場合に、送信装置は、動作４１３において、付加の判定を選択的に実行する。

動作４１３において、送信装置は、要請されるサービスがサービス品質（ＱｏＳ）が保証されなければならないか否かを判定する。要請されるサービスがＱｏＳが保証されなければならないサービスである（例えば、動作４１３において‘ｙｅｓ’である）場合に、送信装置は、動作４１７において、ＭＰＵヘッダを分析し、ＭＰＵの単位でパケットを生成し、生成されたパケットを送信する。要請されるサービスがサービス品質（ＱｏＳ）が保証されなければならないサービスではない（例えば、動作４１３において‘ｎｏ’である）場合に、送信装置は、動作４１５において、非実時間送信の場合と同様に、所定のサイズの単位パケットを生成し、生成された単位パケットを送信する。

図５は、本開示の一実施形態によるマルチメディアデータを受信する装置の構造を示す図である。

図５を参照すると、受信装置５００が図示され、本開示の一実施形態による受信装置５００は、メディアデータを構成するマルチメディアの個数により予め定められたヘッダフォーマットのうちで選択された１つにより生成される基本送信単位を受信する動作と、基本送信単位のヘッダを確認する動作と、得られたヘッダ情報を用いて、基本送信単位によりパケット化されるマルチメディアデータを取得する動作とを実行する。

受信装置５００は、メディアデータを構成するヘッダフォーマットを含む基本送信単位を再構成し受信する送受信部５０５、受信された基本送信単位のヘッダを確認するヘッダ検出部５１０、及び確認されたヘッダ情報を用いて基本送信単位によりパケット化されたマルチメディアデータを受信する制御部５１５のうちの少なくとも１つを含むように構成される。

制御部５１５、ヘッダ検出部５１０、及び送受信部５０５は、 必ずしも個別の構成要素として具現されなければならないというわけではなく、例えば、単一のチップ及び／又は単一のチップ上のソフトウェアの形態で１つの構成要素として具現できることは明らかである。

図６は、本開示の一実施形態による送信装置でのメディアデータを送信するための方法を示す図である。

図６を参照すると、動作６０１において、送信装置は、メディアデータを構成するマルチメディアの送信要求条件により生成されるトランポートパケットヘッダフォーマット及び送信構造を決定する。

送信装置は、動作６０３において、決定されたヘッダフォーマット及び送信構造によりメディアデータの基本送信単位を生成する。

送信装置は、動作６０５において、生成された基本送信単位によりメディアデータをパケット化する。

送信装置は、動作６０７において、パケット化されたメディアデータを送信する。

図１乃至図６に示すレイヤー構成、送信装置及び受信装置、データ送信構造、データ生成方法、及びデータ送信方法は、本開示の範囲を限定するための意図がないことに留意すべきである。言い換えれば、図１乃至図６に示すすべてのデータユニット、特定の構成部、又は動作が本開示の実施のための必須の構成要素であると解析されてはならず、一部のデータユニット、動作、又は構成要素だけを含むとしても、本開示の範囲及び趣旨を逸脱することなく具現できる。

上述した動作は、対応するプログラムコードを記憶するメモリ装置を通信システムの送信装置、サーバ、受信装置、又は端末装置内の任意の構成部に備えることにより実現できる。言い換えれば、送信装置、サーバ、受信装置、又は端末装置の制御部は、プロセッサ又は中央処理ユニット（ＣＰＵ）によりメモリ装置内に記憶されたプログラムコードを読み出し実行することにより、上述した動作を実行できる。

ここで説明される送信装置、サーバ、受信装置、又は端末装置の様々な構成部及びモジュールは、ハードウェア回路（例えば、相補形金属酸化膜半導体（Complementary Metal Oxide Semiconductor：ＣＭＯＳ）をベースとした論理回路）、ファームウェア、ソフトウェア、及び／又は、ハードウェア、ファームウェア、及び／又は機械読み取り可能な媒体に組み込まれたソフトウェアの組み合せのようなハードウェア回路、を使用して動作させてもよい。例えば、様々な電気構造及び方法は、トランジスタ、論理ゲート、及び特定用途向け集積回路（ＡＳＩＣｓ）のような電気回路を使用して実施されることができる。

以上、本発明を具体的な実施形態を参照して詳細に説明してきたが、本発明の範囲及び趣旨を逸脱することなく様々な変更が可能であるということは、当業者には明らかであり、本発明の範囲は、上述の実施形態に限定されるべきではなく、特許請求の範囲の記載及びこれと均等なものの範囲内で定められるべきである。

Claims (10)

1. マルチメディアシステムにおけるメディアデータを送信するための方法であって、
   前記メディアデータにより要求されるマルチメディアサービスのタイプによる送信要求条件、及び前記メディアデータにより要求される前記マルチメディアサービスの前記送信要求条件に基づく送信構造を識別するステップと、
   前記識別された送信構造に基づいて、前記メディアデータのメディア処理ユニット（ＭＰＵ）又は前記メディアデータのメディアフラグメントユニット（ＭＦＵ）から少なくとも一つのパケットを生成するステップと、
   前記生成された少なくとも一つのパケットを送信するステップと、
   を含み、
   複数のＭＦＵは前記ＭＰＵを構成し、
   前記送信要求条件が、前記マルチメディアサービスが実時間送信を保証する条件を含む場合、少なくとも一つのＭＦＵから生成されたパケットが送信される毎に周期的に制御情報を含むパケットが送信される方法。
2. 前記送信要求条件が、前記マルチメディアサービスが非実時間送信を保証する条件を含む場合、前記少なくとも一つのパケットの各々は、予め決定されたサイズを有する請求項１に記載の方法。
3. 前記送信要求条件が、前記マルチメディアサービスがＶｏＤサービスである条件を含む場合、前記少なくとも一つのパケットの各々は、予め決定されたサイズを有するか、それとも、少なくとも一つのＭＰＵの間隔で挿入される制御情報ペイロードを含む請求項１に記載の方法。
4. 前記送信要求条件が、前記マルチメディアサービスがＱｏＳ（ｑｕａｌｉｔｙ ｏｆ ｓｅｒｖｉｃｅ）保証ＶｏＤサービスである条件を含む場合、前記少なくとも一つのパケットは、少なくとも一つのＭＰＵの間隔で挿入される制御情報ペイロードを含む請求項１に記載の方法。
5. 前記識別された送信構造は、前記ＭＰＵを構成する前記ＭＦＵのサイズに基づいて構成される一つ以上のペイロードの構造を含む請求項１に記載の方法。
6. マルチメディアシステムにおけるメディアデータを送信するための装置であって、
   少なくとも一つのプロセッサと、
   前記少なくとも一つのプロセッサに接続された送受信器と、を含み、
   前記少なくとも一つのプロセッサは、
   前記メディアデータにより要求されるマルチメディアサービスのタイプによる送信要求条件、及び前記メディアデータにより要求される前記マルチメディアサービスの前記送信要求条件に基づく送信構造を識別し、
   前記識別された送信構造に基づいて、前記メディアデータのメディア処理ユニット（ＭＰＵ）又は前記メディアデータのメディアフラグメントユニット（ＭＦＵ）から少なくとも一つのパケットを生成するよう構成され、また、
   前記送受信器は、前記生成された少なくとも一つのパケットを送信するように構成され、
   複数のＭＦＵは前記ＭＰＵを構成し、
   前記送信要求条件が、前記マルチメディアサービスが実時間送信を保証する条件を含む場合、少なくとも一つのＭＦＵから生成されたパケットが送信される毎に周期的に制御情報を含むパケットが送信される装置。
7. 前記送信要求条件が、前記マルチメディアサービスが非実時間送信を保証する条件を含む場合、前記少なくとも一つのパケットの各々は、予め決定されたサイズを有する請求項６に記載の装置。
8. 前記送信要求条件が前記マルチメディアサービスがＶｏＤサービスである条件を含む場合、少なくとも一つのパケットの各々は、予め決定されたサイズを有するか、それとも、少なくとも一つのＭＰＵの間隔で挿入される制御情報ペイロードを含む請求項６に記載の装置。
9. 前記送信要求条件がＱｏＳ（ｑｕａｌｉｔｙ ｏｆ ｓｅｒｖｉｃｅ）保証ＶｏＤサービスである条件を含む場合、前記少なくとも一つのパケットは、少なくとも一つのＭＰＵの間隔で挿入される制御情報ペイロードを含む請求項８に記載の装置。
10. 前記識別された送信構造は、前記ＭＰＵを構成する前記ＭＦＵのサイズに基づいて構成される一つ以上のペイロードの構造を含む請求項６に記載の装置。
    

Images