JP6353120B2 - マルチメディアデータパケットを送信する方法及び装置 - Google Patents

Description

本発明は、マルチメディアデータパケットを送信する方法及び装置に関し、特に、サービス品質（Quality of Service：ＱｏＳ）方式に従って適応的にマルチメディアデータパケットを送信する方法及び装置に関する。

マルチメディアサービスは、画像電話のような対話型サービスと、ビデオオンデマンド（Video On Demand：ＶｏＤ）ファイルの送信のようなストリーミングサービスと、マルチキャスト及びブロードキャストサービスとを意味する。リアルタイムマルチメディアサービスは、サービスタイプに従って、対話型サービス、インタラクティブサービス、及びストリーミングサービスに分類することができる。また、リアルタイムマルチメディアサービスは、サービスに参加しているユーザーの数に従って、ユニキャスト、マルチキャスト、及びブロードキャストに分類することができる。

マルチメディアサービスを提供するために、ネットワークは、大きく３通りの方式、すなわち、ベストエフォート（Best Effort：ＢＥ）方式、クラス別ＱｏＳ（per class QoS）方式、及びフロー別ＱｏＳ（per flow QoS）方式でサービス品質（Quality of Service：ＱｏＳ）を保証する。

まず、ＢＥサービスのＱｏＳを保証するために何のサポートもしない。

クラス別ＱｏＳサービスは、パケットごとに重要度を異ならせてネットワークでその重要度に従ってパケットを処理する。すなわち、パケットのＱｏＳは、対応するパケットがどんなフローに属しているかに関係なく、対応するパケットの重要度、すなわち、優先順位に従って制御される。クラス別ＱｏＳ方式をサポートするためには、送信装置と受信装置間のリソースの予約が不必要である。参考にまで、この優先順位は、損失優先順位（loss priority）及び遅延優先順位（delay priority）に分類することができる。

フロー別ＱｏＳサービスは、ストリーム別にリソースを予約する。すなわち、フロー別にリソース（例えば、ビット率及びバッファ状態）又はＱｏＳ（例えば、遅延及び損失率など）を予約する。ここで、フローとは、１つのサービスを提供するために必要とされるストリームを意味する。例えば、ＶｏＤサービスを提供するために必要とされるビデオストリーム、オーディオストリーム、及びテキストストリームは、個別のフローである。

ＩＥＥＥ ８０２．１６（ＷｉＢＲＯ及びＷＩＭＡＸ）及びロングタームエボルーション（Long Term Evolution：ＬＴＥ）標準だけではなく、３ＧＰＰ ＵＭＴＳ（３Ｇ）標準でもクラス別ＱｏＳ及びフロー別ＱｏＳをサポートする。しかしながら、ＱｏＳ方式を使用するためには、上位階層であるメディア階層には、下位階層であるネットワーク間のインターフェースが必要である。

ＭＰＥＧ（Moving Picture Experts Group）−２及びＨ．２６４、特に、スケーラブルビデオコーディング（Scalable Video Coding：ＳＶＣ）を使用する時に、各ビデオパケットは、重要度の観点で相互に異なる。ビデオサービスのＱｏＳを効率的に制御するためには、このようなパケット間の重要度差を識別しなければならない。パケットスイッチング方式の場合に、ＩＰｖ６では、パケット別重要度を識別するために、５つのタプル（tuples）（すなわち、受信者アドレス、送信者アドレス、受信者内のサービスのポート番号、送信器内のサービスのポート番号、及び使用されるプロトコル）をＩＰｖ６ヘッダーから読み出した後に、パケットの重要度を示すヘッダーデータをビデオパケットのペイロードから読み出さなければならない。このような方式は、パケットごとに処理時間が多くかかり、プロトコル階層の独立性に違反する。すなわち、ルータは、パケットの処理にあたり、パケットのＩＰヘッダーだけを読み出すことができなければならないが、これは、実際には不可能である。

パケット別重要度を容易に判定できる場合のみ、ルータは、ＱｏＳ（Quality of Service）制御を円滑に実行することができる。例えば、ネットワーク状態が悪い場合に、ルータは、パケット別重要度に従って重要でないパケットを廃棄することができる。

一方、標準化が進行中であるスケーラブルビデオコーディング（Scalable Video Coding：ＳＶＣ）又はマルチビュービデオコーディング（Multi-view Video Coding：ＭＶＣ）は、Ｈ．２６４／ＡＶＣ（Advanced Video Coding）標準に基づいている。符号化されたデータは、Ｈ．２６４／ＡＶＣのネットワーク抽象化階層単位（Network Abstraction Layer Unit：ＮＡＬＵ）フォーマットでビット列に構成される。

図１は、Ｈ．２６４／ＡＶＣのビデオ符号化階層（Video Coding Layer：ＶＣＬ）及びネットワーク抽象化階層（ＮＡＬ）を示す図である。

Ｈ．２６４／ＡＶＣにおいて、ネットワーク抽象化階層（Network Abstraction Layer：ＮＡＬ）１２０は、ビデオ符号化を処理するビデオ符号化階層１１０と符号化された情報の送信及び格納を行う下位階層システム１３０との間で定義される。したがって、ＶＣＬ１１０は、ＮＡＬ１３０から分離される。

ＮＡＬ１２０は、Ｈ．２６４／ＡＶＣファイルフォーマット１３１、実時間転送プロトコル（Real-time Transport Protocol：ＲＴＰ）１３３、及びＭＰＥＧ−２システム１３５のようなフォーマットで符号化データ１１１を下位階層システム１３０のビット列にマッピングするために、ＮＡＬ単位（NAL Unit：ＮＡＬＵ）でＶＣＬで生成された符号化データ１１１及びパラメータセット又は付加拡張情報（Supplemental Enhancement Information：ＳＥＩ）１１３のような情報を処理する。

ＮＡＬ単位は、ＶＣＬ ＮＡＬ単位１２３と非（non）ＶＣＬ ＮＡＬ単位１２５とに分けられる。ＶＣＬ ＮＡＬ単位１２３は、ＶＣＬで生成された符号化データ１１１に対応するＮＡＬ単位であり、非ＶＣＬ ＮＡＬ単位１２５は、パラメータセット又はＳＥＩ１１３の情報に対応するＮＡＬ単位である。

ＮＡＬ単位は、基本的に、ＮＡＬヘッダーと、ＶＣＬで動映像圧縮の結果から生成されたデータ部分であるローバイトシーケンスペイロード（Raw Byte Sequence Payload：ＲＢＳＰ）とを含む。

図２は、ＮＡＬ単位のフォーマットを説明するための図である。

図２を参照すると、ＮＡＬ単位２００は、ＮＡＬヘッダー２１０とＮＡＬペイロード２４０とを含む。

ＮＡＬヘッダー２１０は、一般的に、１乃至５バイトのサイズを有する。ＮＡＬヘッダー２１０は、ＮＡＬＵのタイプを示すＮＡＬＵタイプ情報２２０とＮＡＬＵペイロードに含まれる圧縮された元来のデータの階層を識別する階層識別情報（Layer Identification Information）２３０とを含む。

ＮＡＬＵタイプ情報２２０は、１ビットの固定ビット（Ｆ）フィールド２２１、ＮＡＬＵが参照ピクチャであるか否かを示す２ビットのＮＲＩ（nal_ref_idc）フィールド２２２と、ＮＡＬＵのタイプを示す識別子である５ビットのＮＡＬＵ Ｔｙｐｅフィールド２２３とを含む。

階層識別情報２３０は、優先順位、空間階層レベル、時間階層レベル、及び／又は品質階層レベルの組み合せを含むことができる。すなわち、階層識別情報２３０は、圧縮された元来のデータの階層を識別することができるようにＮＡＬＵの優先順位を示す８ビットのプライオリティ（Priority：以下、“Ｐ”と称する）フィールド２３１、ＮＡＬＵの空間階層レベルを示す３ビット乃至８ビットのディペンデンシー識別子（Dependency_id：以下、“Ｄ”と称する）フィールド２３２、ＮＡＬＵの時間階層レベルを示す３ビット乃至８ビットのテンポラルレベル（Temporal_level：以下、“Ｔ”と称する）フィールド２３３、及び／又はＮＡＬＵの品質階層レベルを示す２ビット乃至８ビットのクオリィティーレベル（Quality_level：以下、“Ｑ”と称する）フィールド２３４を含む。

参考までに、同一のＮＡＬＵフォーマットは、ＭＶＣ（Multi-view Video Coding）でも使用される。しかしながら、ＭＶＣにおいて、ＮＡＬＵタイプ情報２２０及び階層識別情報２３０の代わりにビューを示すビュー識別情報（View Identification Information）は、ＮＡＬヘッダーに含まれることがある。

上述したＳＶＣ又はＭＶＣに対するＮＡＬＵフォーマットに従うと、ＮＡＬＵの階層又はビューを識別するためには、ＮＡＬヘッダーの階層識別情報２３０又はビュー識別情報をすべてパーシング（parsing）しなければならない。特に、階層識別情報２３０は、４バイト以下のサイズを有し、ＮＡＬヘッダー２１０のパーシングを通してＰ２３１、Ｄ２３２、Ｔ２３３、及びＱ２３４の値をすべて認識することができない場合には、対応するＮＡＬＵが属する階層を判定することができない。しかしながら、ＮＡＬヘッダー２１０のＰ２３１、Ｄ２３２、Ｔ２３３、及びＱ２３４の値を知るためにＮＡＬヘッダー２１０をすべてパーシングすることは、プロセッサに制約を課し、システムのコストを増加させる。

また、ＮＡＬヘッダー２１０は、ＮＲＩフィールド２２２及びＰフィールド２３１に加えて、Ｄ２３２、Ｔ２３３、及びＱ２３４のような階層識別情報２３０のようにパケットの重要度を識別する様々な情報を含み、これらの情報間の関係が定義されていないので、これを活用するのに難しさがある。例えば、階層識別情報Ｄ２３２、Ｔ２３３、及びＱ２３４について、Ｄ２３２の値として“１”を有するパケットとＴ２３３の値として“１”を有するパケットとが存在する時に、符号化過程の予測に対する関係が理解されない場合には、２つのパケットの優先順位上の階層を識別することができない。

さらに、従来のネットワークのＮＡＬ階層は、ビデオサービスのみに対して設計されている。したがって、オーディオ、ビデオ、テキスト、ユーザーインターフェースのように様々なメディア構成要素が結合される今後のメディアサービスのために、メディア構成要素のタイプに無関係に抽象化が可能なメディア抽象化階層の導入が必要である。

米国特許出願公開第２００９／０１７５３５３号明細書

本発明の目的は、少なくとも上述した問題点及び／又は不都合に取り組み、少なくとも以下の便宜を提供することにある。すなわち、本発明の目的は、マルチメディアサービスを提供する時にマルチメディアサービスを適応的に提供する方法及び装置を提供することにある。

本発明の他の目的は、様々なメディア要素を抽象化することによりアプリケーション階層内の情報を下位ネットワーク階層で使用できるようにするメディア抽象化階層を通してマルチメディアサービスを提供する方法及び装置を提供することにある。

本発明のまた他の目的は、ＭＰＥＧレベルでの理解に基づいて下位階層のための特定の重要度情報を提供するメディア抽象化階層を通してマルチメディアサービスを提供する方法及び装置を提供することにある。

本発明のさらなる他の目的は、メディア抽象化階層により生成された情報をＩＰヘッダーに挿入することにより下位階層での簡単な処理だけで必要な情報へのアクセスを容易にするマルチメディアサービスを提供する方法及び装置を提供することにある。

上記のような目的を達成するために、本発明の実施形態の一態様によれば、マルチメディアデータパケットを送信する方法は、送信されるマルチメディアデータに関する情報を抽象化するメディア抽象化階層（ＭＡＬ）情報を生成するステップと、上記メディア抽象化階層情報を含むマルチメディアデータパケットを生成するステップと、上記マルチメディアデータパケットをネットワークエンティティーに送信するステップとを有することを特徴とする。

本発明の実施形態の他の態様によれば、ネットワーク上のエンティティーがマルチメディアデータパケットをフォーワーディングする方法は、マルチメディアデータに関する情報を抽象化するメディア抽象化階層（ＭＡＬ）情報を含むマルチメディアデータパケットを送信装置から受信するステップと、上記受信されたメディア抽象化階層情報に基づいて上記マルチメディアデータパケットをフォーワーディングするステップとを有することを特徴とする。

本発明の実施形態のさらに他の態様によれば、マルチメディアデータパケットを送信する装置は、送信されるマルチメディアデータに関する情報を抽象化するメディア抽象化階層（ＭＡＬ）情報を生成するメディア抽象化階層部と、上記メディア抽象化階層情報を含むマルチメディアデータパケットを生成し、上記生成されたマルチメディアデータパケットをネットワークエンティティーに送信するパケット生成部とを有することを特徴とする。

本発明の実施形態のさらなる他の態様によれば、マルチメディアデータパケットをフォーワーディングするネットワークエンティティー装置は、マルチメディアデータに関する情報を抽象化するメディア抽象化階層（ＭＡＬ）情報を含むマルチメディアデータパケットを送信装置から受信し、上記受信されたメディア抽象化階層情報に基づいて上記マルチメディアデータパケットをフォーワーディングするフォーワーディングポリシー決定部を有することを特徴とする。

本発明の実施形態に従って、すべてのマルチメディアデータに適用可能なマルチメディア抽象化階層を提供することにより、メディアデータの重要度又は優先順位、リソース予約状態、ネットワーク状態又はユーザーの要求条件を反映することによりマルチメディアサービスを提供することができる。

また、本発明の実施形態に従って、簡素化されたヘッダー構造を提供し、ＩＰパケットを受信する装置がフローラベルに対応するフィールドをパーシングしなくてもよいので、受信装置の効率的なリソース活用が可能である。

Ｈ．２６４／ＡＶＣにおけるビデオ符号化階層（ＶＣＬ）及びネットワーク抽象化階層（ＮＡＬ）を示す図である。 ＮＡＬ単位のフォーマットを示す図である。 本発明の一実施形態による送信装置の構成を示す図である。 本発明の一実施形態によるメディア抽象化階層（ＭＡＬ）情報をＩＰパケットに挿入する方式を示す図である。 本発明の一実施形態によるＭＡＬ情報を含むＩＰパケットヘッダーの構成を示す図である。 本発明の一実施形態によるメディア認識ネットワーク要素（ＭＡＮＥ）の構成を示す図である。 本発明の一実施形態による受信装置の構成を示す図である。

以下、本発明を実施するための形態を、図面を参照しながら詳細に説明する。下記の説明において、明瞭性と簡潔性の観点から、本発明に関連した公知の機能や構成に関する具体的な説明が本発明の要旨を不明瞭にすると判断される場合には、その詳細な説明を省略する。

本発明の実施形態は、ビデオデータのための標準であるＭＰＥＧ−４／ＡＶＣ（Advanced Video Coding, H.264）、ＳＶＣ（Scalable Video Coding）、及びＭＶＣ（Multi-view Video Coding）で使用しているネットワーク抽象化階層（Network Abstraction Layer：ＮＡＬ）の概念をビデオデータだけでなく他のメディアデータ（例えば、オーディオデータ、グラフィックデータ、テキストデータなど）に適用する。

図２を参照して上述したように、従来のＮＡＬヘッダー２１０は、ビデオパケットの重要度を表示する情報を含む。また、ＳＶＣ ＮＡＬヘッダーは、時間的階層、空間的階層、及び品質階層を示す階層認識情報２３０を含み、ＭＶＣヘッダーは、ビュー（view）番号を示す情報を含む。

このＮＡＬヘッダーに含まれる情報は、上位プロトコル階層から下位プロトコル階層に伝達されるトップダウン（top-down）インターフェースで抽象化され生成される。このような情報が、対応するパケットの重要度を示すので、パケットサービスをネットワーク状態又は端末状態に従って適応的に提供することができる。

本発明は、ＮＡＬの概念をすべてのメディアに拡張するために“メディア分類子（classifier）”及び“ラベル（label）”と呼ばれる識別子（identifier）を定義する。本発明によると、“メディア分類子”は、メディアに関する具体的な理解なしにメディアに含まれる優先順位情報が下位プロトコル階層により使用することができるように抽象化される優先順位情報を提供する。“ラベル”は、それぞれのストリーム（例えば、ビデオストリーム又はオーディオストリームなど）を識別するための識別子である。

また、本発明において、送信されるメディアデータに関連した情報を抽象化するトップダウン（Top-down）インターフェース、すなわち、メディア抽象化階層（Media Abstraction Layer：ＭＡＬ）を提案する。下記の説明において、ＭＡＬで抽象化されたデータ関連情報は、ＭＡＬ情報であると呼ばれる。

一方、本発明において、送信装置（サーバ又は端末）は、ＭＡＬ情報を生成し、パケットのヘッダーとともに送信し、ネットワークエンティティー（ルータ又は基地局など）は、ＭＡＬ情報を用いてパケットの重要度又はリソース予約状態を識別し、したがって、この識別された結果に基づいてパケットを送信することができる。

図３は、本発明の一実施形態による送信装置３００の構成を示す図である。

図３を参照すると、送信装置３００は、メディアデータ供給部３０１と、メディア抽象化階層部３０２と、パケット生成部３０３とを含む。ここで、送信装置３００は、例えば、マルチメディアサービスを提供するサーバであることができる。

メディア抽象化階層部３０２は、１つのＩＰパケットをメディアデータ供給部３０１から受信し（３０８）、ＭＡＬ情報を生成し、パケット生成部３０３に送信する（３１０）。また、メディア抽象化階層部３０２は、メディアデータ供給部３０１から受信したＩＰパケットをパケット生成部３０３に送信する（３０９）。

この時に、メディア抽象化階層部３０２で生成される対応するメディアデータに関するＭＡＬ情報は、メディア分類子情報及びラベル情報を含むことができる。上述したように、メディア分類子情報は、下位ネットワークでメディアパケットの抽象化された重要度情報を認識するために使用することができ、ラベル情報は、下位ネットワークがパケットを識別するために使用することができる。

パケット生成部３０３は、メディア抽象化階層部３０２から受信されたＭＡＬ情報３１０及びＩＰパケット３０９を用いてパケットを生成し、この生成されたパケットを、ネットワーク３１３を通して送信する。ＭＡＬ情報に含まれたメディア分類子情報及びラベル情報は、ＩＰパケットのヘッダー又は他の下位プロトコルのパケットのヘッダーに含まれることができる。

図３に示すような構成に従ってパケットを送信する例を次のように説明する。

まず、ＭＡＬで生成されるメディア分類子を使用するクラス別サービス品質（ＱｏＳ）方式について説明する。

サーバと端末との間でオーディオデータストリームのメディア分類子が１に、テキストデータストリームのメディア分類子が２に、ビデオデータストリームのメディア分類子が３に予め約束（又は設定）されているものと仮定する。また、メディア分類子が設定されたストリームに対する優先順位が送信装置、ネットワークエンティティー、及び受信装置の間で約束されていると仮定する。

ビデオデータパケットを送信する場合に、送信装置は、対応するパケットに含まれるメディア分類子情報を３に設定することによりパケットを生成し送信する。ネットワークエンティティー（例えば、ルータ）は、この受信されたパケットに含まれるメディア分類子情報（すなわち、３）により受信されたパケットのＱｏＳクラスを認識することができる。この後に、ネットワークエンティティーは、ネットワーク状態及びＱｏＳクラスのフォーワーディングポリシーに基づいてパケットをフォーワーディングするか否かを決定することができる。

この後に、ＭＡＬで生成されるラベル情報を用いるフロー別（すなわち、ストリーム別）ＱｏＳ方式について説明する。

サーバと端末との間でオーディオデータストリームのラベルが１に、テキストデータストリームのラベルが２に、ビデオデータストリームのラベルが３に予め約束（又は、設定）されているものと仮定する。

送信装置がビデオパケットを送信する場合に、対応するパケットにラベル情報を３に設定することによりパケットを生成し送信する。ネットワークエンティティー（例えば、ルータ）は、この受信されたパケットのラベル情報（すなわち、３）によりこの受信されたパケットの重要度、優先順位、又はリソース予約情報などを認識することができる。この後に、このネットワークエンティティーは、ネットワーク状態、この受信されたパケットの重要度、優先順位、又はリソース予約情報に基づいてパケットを送信することができる。

このデータストリーム別ラベル、このラベルに従う重要度、優先順位、又はリソース予約情報は、送信装置、受信装置、及びネットワークエンティティー間の呼設定の過程で設定することができる。

以下では、本発明で提案するメディア抽象化階層情報であるＭＡＬ情報について説明する。

パケットに含まれるＭＡＬ情報は、下位階層のネットワークエンティティーにより対応するメディアの抽象化されたＱｏＳクラスを分類するためのメディア分類子情報と、データパケットの損失重要度、遅延重要度、優先順位、又はリソース予約情報を認識するための情報とをラベル（すなわち、タグ）の形式で含む。一方、本発明で提案するＭＡＬ情報のフォーマットは、従来の他のプロトコル標準、例えば、インターネットプロトコル（ＩＰ）ヘッダー、送信制御プロトコル（Transmission Control Protocol：ＴＣＰ）ヘッダー、ユーザーデータグラムプロトコル（User Datagram Protocol：ＵＤＰ）ヘッダー、及びリアルタイム転送プロトコル（ＲＴＰ）ヘッダーとともに使用することができる。

ＭＡＬ情報を用いてメディアサービスを提供するためには、送受信側ネットワーク間の呼設定過程が必要である。すなわち、この呼設定過程を通して各ネットワークエンティティーは、ラベル値が意味することを約束することができる。

各ラベル値が意味する値をリストしたテーブルは、ラベルテーブル（Label Table：ＬＴ）と呼ばれる。放送網のように送受信側ネットワーク間の呼設定過程が不可能である場合に、ＭＰＥＧ−２システムのプログラムマップテーブル（Program Map Tables：ＰＭＴ）のように周期的な時間間隔でＬＴを送信する方法を使用することができる。

一方、本発明の実施形態によるＭＡＬ情報は、クラス別ＱｏＳ方式のためのメディア分類子フォーマットとストリーム別ＱｏＳ方式のためのラベルフォーマットとに分類することができる。

クラス別ＱｏＳ方式は、送信装置と受信装置間のサービス提供のためのリソース予約過程なしに、損失率及び送信遅延に対する要求事項に基づいて対応するメディアを抽象化し、この抽象化されたメディアを分類子の形式で含む。

例えば、１つのメディアサービスが１つのビデオストリーム、オーディオストリーム、及び字幕をサポートするためのテキストストリームを含む場合に、ＭＡＬは、各ストリームの送信遅延及び損失要求事項に従ってＱｏＳクラスを抽象化し、これを分類するための形式でメディア分類子値を決定する。選択的に、オーディオストリームの重要度は、ビデオストリームの重要度よりさらに大きいことがある。図４に後述するように、メディア分類子の値は、インターネットプロトコルバージョン４（Internet Protocol version 4：ＩＰｖ４）ヘッダーのタイプオブサービス（Type-Of-Service：ＴＯＳ）フィールド又はインターネットプロトコルバージョン６（Internet Protocol version 6：ＩＰｖ６）ヘッダーのトラフィッククラス（Traffic Class：ＴＣ）フィールドに挿入することができる。例えば、このメディア分類子の値が２ビットに設定される場合に、１１、１０、０１、及び００の順序でパケット別重要度を差別化する。すなわち、オーディオパケットは、メディア分類子値１１を含み、テキストパケットは、メディア分類子値１０を含み、ビデオパケットは、メディア分類子値０１を含むことができる。

次に、単一ストリームを構成する複数のサブストリームに対して異なるメディア分類子を適用する例は、次のようである。

ＳＶＣのようにビデオストリームが異なる優先順位の３個の階層（基本階層、向上階層１、及び向上階層２）に分類される場合に、基本階層は、より高い重要度を有し、基本階層が他の階層より早く到達しなければならない。したがって、送信遅延及びパケット損失が小さいＱｏＳクラスが基本階層に割り当てられる。基本階層より低い優先順位を有するＱｏＳクラスは、向上階層１及び向上階層２に割り当てられる。上述したように、メディア分類子のサイズが２ビットに設定される場合に、基本階層、向上階層１、及び向上階層２に対するＱｏＳクラスを、１１、１０、及び０１にそれぞれ差別化することができる。

フロー別ＱｏＳ方式において、リソース予約は、ストリーム別に行われ、対応するフローは、リソース予約に関するラベル情報を有する。例えば、ラベル値が１に設定されるフローに対しては、３００ｋｂｐｓのリソースが予約されると仮定する場合に、送信装置で生成されパケットに含まれたラベル値が１であり、ネットワークエンティティーがこのパケットに含まれたラベル値を識別する場合に、対応するフローは、呼設定過程で送信されたＬＴ及びパケットのラベル値に基づいてラベル値１に対応する３００ｋｂｐｓのリソースを使用して送信される。選択的に、この場合に、現在使用可能なリソースも考慮することができる。

また、このリソース予約を、セッション別に行うことができる。すなわち、送受信側ネットワーク間の呼設定の時にラベルスイッチングをサポートするためにリソース予約がなされる単位がストリーム単位であるか又はセッション単位であるかに従って、ラベル情報を、ストリーム単位又はセッション単位で設定することができる。

さらに、このリソース予約過程及びラベル情報設定は、送信側と受信側間の呼設定過程で予め約束することができる。この時、ネットワークエンティティーがマルチプロトコルラベルスイッチング（Multi-Protocol Label Switching：ＭＰＬＳ）をサポートする場合、本発明によるラベルのフォーマットを、ＭＰＬＳによりサポートされるラベルのフォーマットとの互換性を有するように構成することができる。この場合に、受信側が、ＭＰＬＳ方式のラベルと互換性を有する本発明によるラベルを認識することができる場合に、ＳＶＣで定義された従来のＮＡＬヘッダーは送信されなくてもよい。また、既存のＲＴＰヘッダー及びＵＤＰヘッダーの内容のうち、１つのセッションの間に変わらない情報をラベルに挿入することができる。このラベルスイッチングは、３番目の階層のパケットが２番目の階層でルーティングされる技術である。このような技術は、ＩＰアドレスの代わりに個別のラベルをデータパケットに付加し、この付加されたラベルを用いてスイッチングを実行することにより、高速のスイッチングを実行することができるようにする。

次いで、ＭＡＬ情報を送信する方式について説明する。

図４は、本発明の一実施形態によるＭＡＬ情報をＩＰパケットに挿入する方法を示す図である。

図４を参照すると、ＭＡＬパケットのための仮想ヘッダーは、本発明の一実施形態に従って定義されたＭＡＬ情報フォーマットで定義される。この仮想ヘッダーに含まれた内容は、下位階層内のパケットヘッダー（例えば、ＩＰパケットヘッダー）に含めるためのものであり、仮想ヘッダー４２０は、内部的に、メディア分類子ヘッダー４２１とラベルヘッダー４２２とに分類される。

メディア分類子ヘッダー４２１は、下位階層がクラス別ＱｏＳ方式を使用する時に適用することができ、メディア分類子ヘッダー４２１の長さは、システム設定に従って変わり得る。下位階層のクラス別ＱｏＳプロトコルとの互換を考慮すると、その長さは、３ビット乃至６ビット程度が好ましい。メディア分類子ヘッダー４２１は、ＩＰｖ４ヘッダー４１０のＴＯＳフィールド４１１に挿入するか又はＩＰｖ６ヘッダー４３０のＴＣフィールド４３１に挿入することができる。

ラベルヘッダー４２２は、下位階層がフロー別ＱｏＳ方式を使用する時に適用することができる。８ビットのサイズを有するラベルヘッダー４２２は、ラベル番号を含む７ビットと必要の時に拡張のための拡張フラグビットの１ビットとを含む。ラベルヘッダー４２２は、ＩＰｖ４ヘッダー４１０の拡張ＩＰヘッダー（extended IP header）４１３に挿入するか、又はＩＰｖ６ヘッダー４３０のフローラベル（flow label）フィールド４３３に挿入することができる。

図５は、本発明の一実施形態によるＭＡＬ情報を含むＩＰパケットヘッダーの構成を示す図である。

図５は、リアルタイムメディアストリームに簡素化されたヘッダーを適用するために、複数のパケットのうちＵＤＰヘッダー及びＲＴＰヘッダーで同一に反復される部分を除去し、このような情報をＬＴに挿入することによりヘッダーを簡素化する方法を示す。参照符号５１０、５３０、及び５４０は、ＩＰｖ４パケットを示し、参照符号５５０は、ＩＰｖ６パケットを示す。図５は、それぞれのパケットでＵＤＰヘッダー及びＲＴＰヘッダーを簡素化することによりラベル情報を生成する一例を示す。

参照符号５１０は、オンデマンドビデオサービスのようなリアルタイムメディアデータの送信のためのメディアパケットを示す。参照符号５６０は、ＵＤＰヘッダーを示し、参照符号５７０は、ＲＴＰヘッダーを示す。

リアルタイムメディアサービスにおいて、一般的に、秒当たりの数十又は数百のパケットが、１つのセッションに対して送信される。リアルタイムメディアストリームの特性により、送信されるメディアパケットのヘッダーは、１つのセッションの間に送信されるパケットごとに同一に反復されるフィールドを含む。参照符号５１１、５１２、５１４、５１５、５１８、５１９、及び５２０は、パケットごとに同一に反復されるフィールドであり、参照符号５１３、５１６、及び５１７は、パケットにより差別化されるフィールド（このフィールドは、同一であるか又は他のフィールドと重複することもある）であるが、このフィールドについての詳細な説明は、本発明の要旨を不明瞭にするので省略する。

重要なフィールドの１つは、ネットワーク抽象化階層ヘッダー（Network Abstraction Layer Header：ＮＡＬＨ）フィールド５２０である。このフィールドは、ＮＡＬヘッダーを示し、図２に示すように、パケットの重要度又は優先順位を含む。

参照符号５３０で示すパケットにおいて、パケット５２０のＵＤＰヘッダー５６０及びＲＴＰヘッダー５７０で反復されるフィールド５１１、５１２、５１４、５１５、５１８、５１９、及び５２０は、１つのラベル情報（フローラベルフィールド）５３１に挿入され、パケットごとに異なり得るフィールド５１３、５１６、及び５１７は、フローラベルフィールド５３１の後ろに配列される。

参照符号５３０で示すパケットにおいて、長さフィールド５３２は、ＩＰヘッダー内に含まれた長さフィールド（図示せず）と重複する。したがって、長さフィールド５３２は、省略が可能である。また、ＴＳフィールド５３４は、タイムスタンプ（Time Stamp）であり、メディアデータの生成が周期的である場合、タイムスタンプの情報を受信側での計算に従って認識することができ、したがって、この情報は、省略が可能である。

参照符号５４０で示すパケットは、参照符号５３０で示すパケットで重複する長さフィールド５３２及び受信側で計算可能なＴＳフィールド５３４が省略されるパケットを意味する。

参照符号５５０で示すパケットは、ＩＰｖ６パケットを示し、ＩＰｖ６ヘッダー５５１は、２４ビット長さのフローラベルフィールドを有し、本発明に従うＭＡＬ情報は、このフィールドを用いてＩＰｖ６ヘッダーに挿入することができる。

簡素化されない従来のヘッダーを使用する場合に、受信側では、すべてのフィールドをパーシングしなければならない。しかしながら、図５に示すようにヘッダーを簡素化する場合に、フローラベルに対応するフィールドを毎回パーシングする必要はない。

本発明で定義したＭＡＬ情報について説明した。このようなＭＡＬ情報は、メディアストリームに関する理解なしに抽象化された重要度及び優先順位を用いてクラス別ＱｏＳ方式及びフロー別ＱｏＳ方式を保証するサービスを提供することができる。

一方、ＭＰＥＧ技術において、メディアの重要度及び優先順位情報を理解し、これを活用してフォーワーディングを実行するネットワークエンティティーをメディア認識ネットワーク要素（Media Aware Network Element：ＭＡＮＥ）と呼ぶ。ＭＡＮＥの動作を参照すると、例えば、ルータ、ＩＥＥＥ８０２シリーズのメディアアクセスコントロール（Media Access Control：ＭＡＣ）、又は３ＧＰＰのブロードキャストマルチキャストサービスセンター（Broadcast Multicast Service Center：ＢＭＳＣ）のように受信されたメディアパケットをフォーワーディング（forwarding）するネットワークエンティティーは、ＭＡＬ情報に含まれるメディア分類子情報に従ってパケットの重要度別に適応的にフォーワーディングすることができるＭＡＮＥとして動作することができる。例えば、差別化サービス（Differentiated Service：Ｄｉｆｆｓｅｒｖ）ルーティング方式を使用するルータにおいて、データがバッファを超過する場合に、優先順位が低いパケットから廃棄される。このために、ＭＡＬ情報のメディア分類子値を確認する。

クラス別ＱｏＳ方式において、ネットワークエンティティーは、受信されたパケットがどんなサービスに属するパケットであるかに関係なく、ＩＰヘッダーに含まれている重要度、すなわち、メディア分類子値を用いてパケットを適応的に処理する。例えば、オーディオパケットのメディア分類子値が１１であり、基本階層内のビデオパケットのメディア分類子値が１０であり、向上階層１内のビデオパケットのメディア分類子値が０１であり、向上階層２内のビデオパケットのメディア分類子値が００であることが受信される時に、ネットワークエンティティーがネットワーク状態又はルータバッファの超過によりパケットのうちのいずれか１つを廃棄すべき場合に、ネットワークエンティティーは、メディア分類子値に従ってパケットを廃棄しなければならない。すなわち、向上階層２内のビデオパケット、向上階層１内のビデオパケット、基本階層内のビデオパケット、及び基本階層内のオーディオパケットの順序でパケットを廃棄する。例えば、ＩＥＥＥ８０２．１１ｅ標準において、ＩＰヘッダーに含まれている重要度に関する情報に従って定められたキュー（Queue）にパケットを挿入する。通常、優先順位は、４つのレベルに設定され、キューを通過するパケットの速度及びパケット損失の処理方法は、対応するキューごとに異なり得る。

フロー別ＱｏＳ方式において、メディア識別子であるラベル値を確認し、ラベル値に従って予め定められたリソースを用いてＱｏＳ（例えば、ビット率、損失率、又は遅延）をサポートする。予め定められたリソースは、対応するネットワークエンティティーにストリーム別に予め保存されているリソース予約テーブルを検索することにより対応するラベルに対応するリソースに従って決定することができる。例えば、ＩＥＥＥ８０２．１６において、オーディオストリームに対するＱｏＳがアンソリシテッドグラントサービス（Unsolicited Grant Service：ＵＧＳ）で定められる場合に、それに従って予め定められたＱｏＳ要件を保証する。したがって、リソース予約テーブルは、対応するサービスが終了するまでネットワークエンティティーに保存される。すなわち、パケットが送信側から受信される場合に、対応するパケットのラベルを確認することにより、対応するラベルストリームのＱｏＳ要件をリソース予約テーブルで検索し、対応するリソースに従ってサービスを提供するようにする。

図６は、本発明の一実施形態によるＭＡＮＥ６００の構成を示す図である。

図６を参照すると、ＭＡＮＥ６００のフォーワーディングポリシー決定部６０９が送信側からパケットを受信する場合に（６０６）、フォーワーディングポリシーに従ってパケットを適応的にフォーワーディングする（６１０）。フォーワーディングポリシーは、受信されたパケットのＭＡＬ情報に含まれるメディア分類子値に従って変わり得る。

ＭＡＮＥ６００がサービスクラス別ＱｏＳ方式をサポートする場合に、ＭＡＮＥ６００は、対応するパケットのメディア分類子のクラスを確認し、それに従って、対応するパケットをフォーワーディングするか否かを決定する。一方、ＭＡＮＥ６００がフロー別（すなわち、ストリーム別）ＱｏＳ方式をサポートする場合には、ＭＡＮＥ６００は、ラベル値を確認し、リソース予約テーブル６０２に保存されている対応するラベルに割り当てられたリソースを確認し（照会：６０５、照会結果受信：６１１）、使用可能なリソース判定部６０４の使用可能なリソース情報を確認し（照会：６０８、照会結果受信：６０７）、使用可能なリソース内でフォーワーディングポリシーを決定し、このパケットをフォーワーディングする（６１０）。

図７は、本発明の一実施形態による受信装置７００の構成を示す図である。

受信装置７００は、例えば、ユーザー端末（User Equipment）であり得る。

図７を参照すると、受信装置７００は、ストリーム別に復号部７０４を含み、信号を受信する受信部７０２及び復号部７０４を制御する制御部７０６を含む。復号部７０４は、必要なだけのバッファ（図示せず）を含み得る。

受信部７０２から受信されたパケットがラベルを含む場合に、制御部７０６は、ラベルを確認し、パケットに対応する復号部７０４を確認する。また、受信部７０２から受信されたパケットがラベルを含まない場合に、制御部７０６は、ＴＣＰ又はＵＤＰヘッダーを読み出し、メディアパケットの復号のための復号部７０４を確認する。

図３乃至図７に示す構成、動作、又は信号のフローが本発明の範囲を限定するためのものではないことに留意しなければならない。すなわち、図３乃至図７に示す構成及び動作は、それぞれ装置で動作する構成を例示するだけであり、すべての過程が必ず含まれなくても実現可能であり、個別的に実行されなくてもよい。

上述した動作を、対応するプログラムコードを記憶するメモリ装置を送信装置３００、受信装置７００、又はＭＡＮＥ６００のようなネットワークエンティティー装置内の任意の構成部に含むことにより実現することができる。すなわち、送信装置３００、受信装置７００、又はＭＡＮＥ６００のようなネットワークエンティティー装置の構成部を、メモリ装置内に記憶されたプログラムコードを読み出し実行するプロセッサ又は中央処理装置（Central Processing Unit：ＣＰＵ）により実現することができる。

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

１１０ ビデオ符号化階層
１１１ ＶＣＬで生成された符号化データ
１１３ パラメータセット及びＳＥＩなど
１２０ ネットワーク抽象化階層
１２３ ＶＣＬ ＮＡＬ単位
１２５ 非ＶＣＬ ＮＡＬ単位
１３０ システム情報の送信及び格納
１３１ Ｈ．２６４／ＡＶＣファイルフォーマット
１３５ ＭＰＥＧ−２システム

Claims (10)

1. マルチメディアデータパケットを送信するための方法であって、
   少なくとも一つのプロセッサによりメディアデータ関連情報を含むメディアデータパケットが生成されるステップと、
   前記少なくとも一つのプロセッサにより前記メディアデータパケットが送信されるステップと、を含み、
   前記メディアデータ関連情報は、
   送信の遅延感度（delay sensitivity）及び送信優先順位（transmission priority）を示すサービス品質（ＱｏＳ）情報と、ネットワークリソース関連情報を示すフロー（flow）情報を含む、方法。
2. 前記送信優先順位は、前記メディアデータパケットの損失優先順位（loss priority）に関連する、請求項１に記載の方法。
3. 前記ネットワークリソース関連情報は、セッションの間のリソース予約に対する情報を含む、請求項１に記載の方法。
4. 前記メディアデータ関連情報は、ビットレート情報をさらに含む、請求項１に記載の方法。
5. 前記メディアデータ関連情報は、バッファ状態をさらに含む、請求項１に記載の方法。
6. マルチメディアデータパケットを送信するための装置であって、
   送信器と、
   メディアデータ関連情報を含むメディアデータパケットを生成し、前記生成されたメディアデータパケットを送信するように前記送信器を制御するプロセッサと、を含み、
   前記メディアデータ関連情報は、
   送信の遅延感度（delay sensitivity）及び送信優先順位（transmission priority）を示すサービス品質（ＱｏＳ）情報と、ネットワークリソース関連情報を示すフロー（flow）情報を含む、装置。
7. 前記送信優先順位は、前記メディアデータパケットの損失優先順位（loss priority）に関連する、請求項６に記載の装置。
8. 前記ネットワークリソース関連情報は、セッションの間のリソース予約に対する情報を含む、請求項６に記載の装置。
9. 前記メディアデータ関連情報は、ビットレート情報をさらに含む、請求項６に記載の装置。
10. 前記メディアデータ関連情報は、バッファ状態をさらに含む、請求項６に記載の装置。