(57)【要約】  本発明によるマルチメディアデータパケットを送信する方法は、ボトムアップネットワーク抽象化階層（Ｂ−ＮＡＬ）情報をネットワークエンティティーから受信するステップと、上記受信されたＢ−ＮＡＬ情報に基づいてメディアデータ品質を決定し、上記決定された品質を有するメディアデータを生成するステップと、上記生成されたメディアデータに対するパケットを生成し、上記パケットを送信するステップとを有する。
2014509113.tif 000002
【特許請求の範囲】
【請求項１】
マルチメディアデータパケットを送信する方法であって、
ボトムアップネットワーク抽象化階層（Ｂ−ＮＡＬ）情報をネットワークエンティティーから受信するステップと、
前記受信されたＢ−ＮＡＬ情報に基づいてメディアデータ品質を決定し、前記決定された品質を有するメディアデータを生成するステップと、
前記生成されたメディアデータに対するパケットを生成し、前記パケットを送信するステップと
を有することを特徴とする、方法。
【請求項２】
前記Ｂ−ＮＡＬ情報は、前記ネットワークエンティティーにより生成されたネットワーク状態情報であることを特徴とする、請求項１に記載の方法。
【請求項３】
前記Ｂ−ＮＡＬ情報は、端末により要求されるサービス品質情報及び制御情報のうちの少なくとも１つであることを特徴とする、請求項１に記載の方法。
【請求項４】
前記パケットは、前記生成されたメディアデータ及び前記生成されたメディアデータに関するラベル情報を含むことを特徴とする、請求項１に記載の方法。
【請求項５】
前記ラベル情報は、下位階層ネットワークが前記パケットの重要度、優先順位、及びリソース予約状態のうちの少なくとも１つを認識するために使用されることを特徴とする、請求項４に記載の方法。
【請求項６】
マルチメディアデータパケットを送信する装置であって、
ボトムアップネットワーク抽象化階層（Ｂ−ＮＡＬ）情報をネットワークエンティティーから受信するレジスタと、
前記受信されたＢ−ＮＡＬ情報に基づいてメディアデータ品質を決定し、前記決定された品質を有するメディアデータを生成するメディアデータ生成部と、
前記生成されたメディアデータに対するパケットを生成し、前記パケットをネットワークエンティティーに送信するパケット生成部と
を有することを特徴とする、装置。
【請求項７】
前記メディアデータ生成部は、
前記受信されたＢ−ＮＡＬ情報に基づいて前記メディアデータ品質を決定する相互階層最適化部と、
前記決定された品質を有するメディアデータを生成するメディアデータ供給部と
を有することを特徴とする、請求項６に記載の装置。
【請求項８】
前記Ｂ−ＮＡＬ情報は、前記ネットワークエンティティーにより生成されたネットワーク状態情報であることを特徴とする、請求項６に記載の装置。
【請求項９】
前記Ｂ−ＮＡＬ情報は、端末により要求されるサービス品質情報及び制御情報のうちの少なくとも１つであることを特徴とする、請求項６に記載の装置。
【請求項１０】
前記パケットは、前記生成されたメディアデータ及び前記生成されたメディアデータに関するラベル情報を含むことを特徴とする、請求項６に記載の装置。
【請求項１１】
前記ラベル情報は、下位階層ネットワークが前記パケットの重要度、優先順位、及びリソース予約状態のうちの少なくとも１つを認識するために使用されることを特徴とする、請求項１０に記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、マルチメディアデータパケットを送信する方法及び装置に関し、特に、相互階層最適化を通してマルチメディアデータパケットを送信する方法及び装置に関する。
【背景技術】
【０００２】
マルチメディアサービスとは、画像電話のようなインタラクティブサービスと、ビデオオンデマンド（Video On Demand：ＶｏＤ）ファイルの送信のようなストリーミングサービスと、マルチキャスト及びブロードキャストサービスとを意味する。リアルタイムマルチメディアサービスは、サービスタイプに従って、対話型サービス、インタラクティブサービス、及びストリーミングサービスに分類することができる。また、リアルタイムマルチメディアサービスは、サービスに参加しているユーザーの数に従って、ユニキャスト、マルチキャスト、及びブロードキャストに分類することができる。
【０００３】
マルチメディアサービスを提供するために、ネットワークは、大きく３通りの方式、すなわち、ベストエフォート（Best Effort：ＢＥ）方式、クラス別ＱｏＳ（per class QoS）方式、及びフロー別ＱｏＳ（per flow QoS）方式でサービス品質（Quality of Service：ＱｏＳ）を保証する。ＢＥサービスのＱｏＳを保証するためには何のサポートもしない。
【０００４】
クラス別ＱｏＳサービスは、パケットごとに重要度を異ならせてネットワークでその重要度に従ってパケットを処理する。すなわち、パケットのＱｏＳは、対応するパケットがどんなフローに属しているかに関係なく、対応するパケットの重要度、すなわち、優先順位に従って制御される。クラス別ＱｏＳ方式をサポートするためには、送信装置と受信装置間のリソースの予約が不要である。参考までに、この優先順位は、損失優先順位（loss priority）及び遅延優先順位（delay priority）に分類することができる。
【０００５】
フロー別ＱｏＳサービスは、ストリーム別にリソースを予約する。すなわち、フロー別にリソース（例えば、ビット率及びバッファ状態）又はＱｏＳ（例えば、遅延及び損失率など）を予約する。ここで、フローとは、１つのサービスを提供するために必要とされるストリームを意味する。例えば、ＶｏＤサービスを提供するために必要とされるビデオストリーム、オーディオストリーム、及びテキストストリームは、個別のフローである。
【０００６】
ＩＥＥＥ  ８０２．１６（ＷｉＢＲＯ及びＷＩＭＡＸ）及びロングタームエボルーション（Long Term Evolution：ＬＴＥ）標準だけではなく、３ＧＰＰ  ＵＭＴＳ（３Ｇ）標準でもクラス別ＱｏＳ及びフロー別ＱｏＳをサポートする。しかしながら、ＱｏＳ方式を使用するためには、上位階層であるメディア階層は、下位階層であるネットワーク間のインターフェースが必要である。
【０００７】
従来、リアルタイム転送プロトコル（Real-time Transport Protocol：ＲＴＰ）及びリアルタイム制御プロトコル（Real-Time Control Protocol：ＲＴＣＰ）は、下位階層を考慮せず、サービス終端で累積された情報を用いてネットワークリソース又はＱｏＳを測定するように設計される。従来のＲＴＰ及びＲＴＣＰにおいて、送信を担当するネットワーク部分は、ブラックボックスとして保持されるので、あらゆる変化を正確に認識することは難しい。したがって、正確なＱｏＳ制御のためには、下位階層から直接上がってくるインターフェースを使用しなければならない。
【０００８】
ＭＰＥＧ（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：ＮＡＬＵ）で、ＶＣＬで生成された符号化データ１１１を処理する。
【００１３】
ＮＡＬＵは、ＶＣＬ  ＮＡＬＵ１２１及び非（non）ＶＣＬ  ＮＡＬＵ１２３に分けられる。ＶＣＬ  ＮＡＬＵ１２１は、ＶＣＬで生成された符号化データ１１１に対応するＮＡＬＵであり、非ＶＣＬ  ＮＡＬＵ１２３は、パラメータセット、付加拡張情報（Supplemental Enhancement Information：ＳＥＩ）などに対応するＮＡＬＵである。基本的に、ＮＡＬＵは、ＮＡＬヘッダーと、ＶＣＬのビデオ符号化の結果から生成されたデータ部分であるローバイトシーケンスペイロード（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）しなければならない。特に、階層識別情報２３０は、２乃至４バイトのサイズを有し、ＮＡＬヘッダー２１０のパーシングを通してＰ２３１、Ｄ２３２、Ｔ２３３、及びＱ２３４の値をすべて認識することができない場合には、対応するＮＡＬＵが属する階層を判定することができない。しかしながら、ＮＡＬヘッダー２１０のＰ２３１、Ｄ２３２、Ｔ２３３、及びＱ２３４の値を知るためにＮＡＬヘッダー２１０をすべてパーシングすることは、プロセッサに制約を課し、システムのコストを増加させる。
【００２１】
さらに、ＮＡＬヘッダー２１０は、Ｐフィールド２３１のようにパケットの重要度を判定することができる情報を含む。しかしながら、ルータがＩＰヘッダーのみを読み出した後にパケットを処理するので、ＮＡＬＵヘッダーから重要度識別情報を読み出すことができない。したがって、ルータが重要度識別情報を読み出すことができるようにＩＰヘッダーに重要度識別情報を含ませる必要がある。
【発明の概要】
【発明が解決しようとする課題】
【００２２】
本発明の目的は、少なくとも上述した問題点及び／又は不都合に取り組み、少なくとも以下の便宜を提供することにある。すなわち、本発明の目的は、メディアデータ、ネットワーク状態、及びユーザーの要求に従って適応的にマルチメディアサービスを提供する方法及び装置を提供することにある。
【００２３】
本発明の他の目的は、アプリケーション階層及び下位階層ネットワークエンティティーとの情報を交換する統合ネットワーク抽象化階層（ＮＡＬ）を提供することにある。
【００２４】
本発明のまた他の目的は、メディアデータ状態、ネットワーク状態、及びユーザーの要求状態に従ってマルチメディアサービスを提供するためにこのような状態を抽象化し、エンティティー間で抽象化された状態に関する情報を送受信する方法及び装置を提供することにある。
【課題を解決するための手段】
【００２５】
上記のような目的を達成するために、本発明の実施形態の一態様によれば、マルチメディアデータパケットを送信する方法は、ボトムアップネットワーク抽象化階層（Ｂ−ＮＡＬ）情報をネットワークエンティティーから受信するステップと、上記受信されたＢ−ＮＡＬ情報に基づいてメディアデータ品質を決定し、上記決定された品質を有するメディアデータを生成するステップと、上記生成されたメディアデータに対するパケットを生成し、上記パケットを送信するステップとを有することを特徴とする。
【００２６】
本発明の実施形態の他の態様によれば、マルチメディアデータパケットを送信する装置は、ボトムアップネットワーク抽象化階層（Ｂ−ＮＡＬ）情報をネットワークエンティティーから受信するレジスタと、上記受信されたＢ−ＮＡＬ情報に基づいてメディアデータ品質を決定し、上記決定された品質を有するメディアデータを生成するメディアデータ生成部と、上記生成されたメディアデータに対するパケットを生成し、上記パケットをネットワークエンティティーに送信するパケット生成部とを有することを特徴とする。
【発明の効果】
【００２７】
本発明は、すべてのマルチメディアデータに適用可能な統合ＮＡＬを提供することによりメディアデータの重要度又は優先順位、リソース予約状態、ネットワーク状態、又はユーザーの要求条件を考慮してマルチメディアサービスを提供することができる。
【００２８】
また、上位プロトコル階層と下位プロトコル階層間の情報交換のために情報を抽象化することができる統合ＮＡＬを提供することにより相互階層最適化を通して通信リソースを効率的に使用することができる。
【図面の簡単な説明】
【００２９】
【図１】Ｈ．２６４／ＡＶＣにおけるビデオ符号化階層（Video Coding Layer：ＶＣＬ）及びネットワーク抽象化階層（ＮＡＬ）を示す図である。
【図２】ＮＡＬ単位のフォーマットを示す図である。
【図３】本発明によるマルチメディアデータパケットを送信する装置及び方法を示す図である。
【図４】本発明の実施形態によるトップダウンインターフェース（Ｔ−ＮＡＬ）情報をＩＰパケットに含む方法を示す図である。
【図５】本発明の実施形態によるＴ−ＮＡＬ情報をＩＰパケットに含むことにより最適のＩＰパケットヘッダーを生成する一例を示す図である。
【図６】本発明の実施形態によるストリーム別ボトムアップインターフェース（Ｂ−ＮＡＬ）情報のフォーマットの一例を示す図である。
【図７】本発明の実施形態によるネットワークエンティティー（ＭＡＮＥ）の動作の一例を示す図である。
【発明を実施するための形態】
【００３０】
以下、本発明の望ましい実施形態を添付の図面を参照して詳細に説明する。ここで使用される用語は、実施形態での機能を考慮して選択され、その用語の意味は、ユーザー、運用者の意図、又は慣例によって変わることができる。したがって、特に明記しない限り、上記用語は、当業者が一般的に認識する意味として解釈されなければならない。
【００３１】
本発明の詳細な説明に先立って、本発明の基本的な概念について説明する。
【００３２】
本発明は、ビデオ符号化標準であるＭＰＥＧ−４／ＡＶＣ（Advanced Video Coding, H.264）、ＳＶＣ（Scalable Video Coding）、及びＭＶＣ（Multi-view Video Coding）で使用しているネットワーク抽象化階層（Network Abstraction Layer：ＮＡＬ）の概念をビデオデータだけでなく他のメディアデータ（例えば、オーディオデータ、グラフィックデータ、テキストデータなど）に適用する。
【００３３】
図２を参照して上述したように、従来のＮＡＬヘッダー２１０は、ビデオパケットの重要度を表示する情報を含む。また、ＳＶＣ  ＮＡＬヘッダーは、時間的階層、空間的階層、及び品質階層を示す階層認識情報２３０を含み、ＭＶＣヘッダーは、ビュー（view）番号を示す情報を含む。
【００３４】
上述した情報は、上位プロトコル階層から下位プロトコル階層に伝達されるトップダウン（top-down）インターフェースで抽象化を通して生成される。このような情報が対応するパケットの重要度を示すので、パケットサービスを、ネットワーク状態又は端末状態に従って適応的に提供することができる。
【００３５】
ＮＡＬの概念をすべてのメディアに拡張するために、本発明に従って“label”と呼ばれる識別子を定義する。本発明において、“label”は、それぞれのストリーム（例えば、ビデオストリーム、オーディオストリームなど）を識別する識別子である。
【００３６】
また、本発明は、送信されるメディアデータに関連した情報を抽象化するトップダウン（Top-down）インターフェース、すなわち、Ｔ−ＮＡＬ階層と、ネットワーク状態に関連した情報を抽象化するボトムアップ（Bottom-up）インターフェース、すなわち、Ｂ−ＮＡＬ階層とを提案する。以下では、Ｔ−ＮＡＬ階層で抽象化されたデータ関連情報は、Ｔ−ＮＡＬ情報と呼ばれ、Ｂ−ＮＡＬ階層で抽象化されたネットワーク状態情報は、Ｂ−ＮＡＬ情報と呼ばれる。
【００３７】
一方、送信装置（例えば、サーバ又は端末）は、Ｔ−ＮＡＬ情報を生成し、Ｔ−ＮＡＬ情報をパケットのヘッダーに含んで送信する。ネットワークエンティティー（例えば、ルータ又は基地局（ＢＳ））は、Ｔ−ＮＡＬ情報を用いてパケットの重要度又はリソース予約状態を識別し、したがって、この識別された結果に基づいてパケットを送信することができる。また、ネットワークエンティティーは、Ｂ−ＮＡＬ情報を生成することができる。送信装置は、Ｂ−ＮＡＬ情報に基づいて現在のネットワーク状態に従って適応的にパケットを送信することができる。
【００３８】
以下、本発明について詳細に説明する。
【００３９】
図３は、本発明によるマルチメディアデータパケットを送信する装置及び方法を示す。送信装置３００は、サーバ又は端末であることができる。
【００４０】
図３を参照すると、送信装置３００は、メディアデータ供給部３０１と、パケット生成部３０３と、本発明に特有な構成、すなわち、相互階層最適化（Cross Layer Optimization：ＣＬＯ）部３０２と、Ｂ−ＮＡＬレジスタ３０４とを含む。
【００４１】
Ｂ−ＮＡＬレジスタ３０４は、ネットワーク３１３からＢ−ＮＡＬ情報３１０を受信し記憶する。Ｂ−ＮＡＬ情報は、一般的に、ネットワークエンティティーにより生成されたネットワーク状態情報である。しかしながら、Ｂ−ＮＡＬ情報は、ユーザー端末により要求されるＱｏＳ情報又はメディアデータ制御に適合した制御情報であり得る。例えば、ユーザー端末の状態が高いＱｏＳサービスの受信に不適切である場合に、ユーザーは、低いＱｏＳパケットサービスを要求することができる。送信パケットの遅延及び損失が大きい場合に、特定のメディアは、このような情報をＢ−ＮＡＬレジスタ３０４から取得することができる。この場合に、Ｂ−ＮＡＬ情報は、ユーザーからの要求に従ってユーザー端末により生成された情報であり得る。しかしながら、説明の便宜上、下記の説明では、Ｂ−ＮＡＬ情報がネットワーク状態情報であることを仮定する。
【００４２】
ＣＬＯ部３０２は、Ｂ−ＮＡＬレジスタ３０４からＢ−ＮＡＬ情報を読み出すか又は受信されたＢ−ＮＡＬパケットから読み出し、Ｂ−ＮＡＬ情報に従って送信されるメディアデータの品質を適応的に決定し、この送信されるメディアデータを少なくとも１つのアクセス単位（Access Unit：ＡＵ）でメディアデータ供給部３０１に要求し（３０５）、このメディアデータをメディアデータ供給部３０５から受信する（３０６）。
【００４３】
この後に、ＣＬＯ部３０２は、１つのＩＰパケットを通して送信されるメディアデータをパケット生成部３０３に送信する（３０９）。この時に、ＣＬＯ部３０２は、対応するメディアデータに関するＴ−ＮＡＬ情報、すなわち、ラベル情報を生成し、このラベル情報をパケット生成部３０３に送信する（３０８）。上述したように、このラベル情報は、下位ネットワークがパケットの重要度、優先順位、又はリソース予約状態を認識するために使用することができる。
【００４４】
パケット生成部３０３は、この受信されたラベル情報を含むパケットを生成し、この生成されたパケットを、ネットワーク３１３を通して送信する（３１１）。このラベル情報は、ＩＰパケットのヘッダー又は他の下位プロトコルのパケットヘッダーに含めることができる。
【００４５】
図３に示す構成を有する送信装置からのパケット送信について説明する。
【００４６】
オーディオデータストリームのラベルが１に設定され、テキストデータストリームのラベルが２に設定され、ビデオデータストリームのラベルが３に設定されると仮定する。また、このラベルが設定されたストリームに対する優先順位が送信装置、ネットワークエンティティー、及び受信装置間で設定されると仮定する。ビデオデータパケットを送信する場合に、送信装置は、３に設定されたラベル情報を有するビデオデータパケットを生成し送信する。その後に、ネットワークエンティティー（例えば、ルータ）は、ラベル情報（＝３）に基づいてこの受信されたパケットの重要度、優先順位、又はリソース予約情報を認識することができる。したがって、ネットワークエンティティーは、ネットワーク状態及びこの受信されたパケットの重要度、優先順位、又はリソース予約情報を考慮してパケットを送信することができる。一方、各データストリームのラベル及びこのラベルに対応する重要度、優先順位、又はリソース予約情報を、呼設定の間に、送信装置、受信装置、及びネットワークエンティティー間で設定することができる。
【００４７】
送信装置がビデオパケットを送信する場合にＢ−ＮＡＬ情報を考慮することができる。すなわち、送信装置は、Ｂ−ＮＡＬ情報により示されるネットワーク状態に従ってビデオパケットの送信順位も適応的に変更することができる。
【００４８】
以下では、本発明に従うトップダウンインターフェース情報であるＴ−ＮＡＬ情報について説明する。
【００４９】
パケットは、下位階層ネットワークエンティティーが対応するメディアデータパケットに関するメディアデータパケットの損失レベル、遅延レベル、又は優先順位レベル、又はリソース予約情報を認識することができるようにラベルの形態でＴ−ＮＡＬ情報を含む。一方、本発明のＴ−ＮＡＬ情報フォーマットは、既存の他のプロトコル標準、例えば、ＩＰヘッダープロトコル、ＴＣＰ及びＵＤＰヘッダープロトコル、及びＲＴＰヘッダープロトコルと両立するように使用することができる。Ｔ−ＮＡＬ情報を用いてメディアサービスを提供するためには、送信側ネットワークと受信側ネットワーク間の呼設定過程が必要である。すなわち、この呼設定過程を通して各ネットワークエンティティーは、ラベル値が意味することを約束することができる。
【００５０】
本発明によると、異なるクラス別ＱｏＳ方式及びストリーム別ＱｏＳ方式は、Ｔ−ＮＡＬ情報のために定義される。
【００５１】
クラス別ＱｏＳ方式の場合には、サービスを提供するために送信装置と受信装置との間のリソースを予約する必要がない。したがって、対応するストリームのパケットに関する重要度情報又は優先順位情報をラベルの形式で含む。例えば、１つのビデオストリームは、Ｉフレームストリーム、Ｂフレームストリーム、及びＰフレームストリームに区分され、ラベル値は、このような識別のための形式で決定される。オーディオストリームは、重要度の観点でビデオストリームよりさらに高いことがある。図４を参照して後述するように、ラベル値は、ＩＰｖ４ヘッダーのＴＯＳフィールド又はＩＰｖ６ヘッダーのＴＣフィールドに挿入することができる。例えば、ラベル値が２ビットで示される場合に、パケット重要度レベルは、１１、１０、０１、及び００の順序で定義される。すなわち、ラベル値１１をオーディオパケットに挿入し、ラベル値１０を基本階層ビデオパケットに挿入し、ラベル値０１を向上１階層ビデオパケットに挿入し、ラベル値００を向上２階層ビデオパケットに挿入することができる。ＳＶＣにおいて、映像は、基本階層映像、向上１階層映像、及び向上２階層映像に分類することができる。
【００５２】
フロー別ＱｏＳ方式の場合に、ストリーム別にリソースが予約され、したがって、ラベル情報は、各フローに含まれる。例えば、ラベル値が１に設定されたフローに対して３００ｋｂｐｓのリソースが予約される場合に、送信装置から生成されたパケットは、１に設定されたラベル値を含む。パケット内のラベル値を確認した場合に、ネットワークエンティティーは、ラベル値１に対応する３００ｋｂｐｓのリソースで対応するフローを送信する。しかしながら、この場合に、現在の使用可能なリソースが考慮されなければならない。一方、リソースは、セッション別にも予約されることがある。また、送信側ネットワークと受信側ネットワーク間の呼設定の間にラベルスイッチングをサポートするために、ラベル情報は、リソースが予約された、すなわち、ストリーム単位又はセッション単位で、構成することができる。
【００５３】
また、リソース予約及びラベル値設定は、送信装置と受信装置間の呼設定の間に事前に約束することができる。ネットワークエンティティーがマルチプロトコルラベルスイッチング（Multi Protocol Label Switching：ＭＰＬＳ）をサポートする場合に、本発明のラベルフォーマットが、ＭＰＬＳによりサポートされるラベルフォーマットと互換性を有するように構成されることもある。受信装置が本発明のラベルをＭＰＬＳ方式のラベルと識別することができる場合のみ、既存のＳＶＣ  ＮＡＬヘッダーは送信されなくてもよい。また、既存のＲＴＰヘッダー及びＵＤＰヘッダーの内容のうち１つのセッションの間に変わらない情報を、ラベルに含めることができる。ラベルスイッチングは、３階層のパケットを２階層でルーティングする技術であり、ＩＰアドレスの代わりに、個別のラベルをデータパケットに付加し、このラベルに基づいて高速のスイッチングを可能にする方式である。
【００５４】
以下、Ｔ−ＮＡＬ情報を送信する方式について説明する。
【００５５】
図４は、本発明の実施形態によるＴ−ＮＡＬ情報をＩＰパケットに含む方法を示す。
【００５６】
本発明によると、ＮＡＬパケットのための仮想ヘッダーは、Ｔ−ＮＡＬ情報フォーマットで定義される。この仮想ヘッダーに含まれる情報は、下位階層のパケットヘッダー（例えば、ＩＰパケットヘッダー）に含めるために使用される。仮想ヘッダーのタイプには、短い（ＳＴ）ＮＡＬヘッダー４２１及び長い（ＬＴ）ＮＡＬヘッダー４２０の２つがある。
【００５７】
ＳＴ  ＮＡＬヘッダー４２１は、下位階層がクラス別ＱｏＳ方式を使用する場合に適用可能であり、その長さは、システム設定に基づいて変わることもあるが、その長さは、２ビット程度が好ましい。ＳＴ  ＮＡＬヘッダー４２１は、ＩＰｖ４ヘッダー４１０のＴＯＳフィールド４１１に挿入されるか、又はＩＰｖ６ヘッダー４３０のＴＣフィールド４０４に挿入されることがある。
【００５８】
一方、ＬＴ  ＮＡＬヘッダー４２０は、下位階層がフロー別ＱｏＳ方式を使用する場合に適用可能であり、その長さは、システム設定に基づいて変わることもあるが、その長さは、１乃至２バイト程度が適当である。また、ＬＴ  ＮＡＬヘッダー４２０は、ＩＰｖ４ヘッダー４１０の拡張ＩＰヘッダー４１３に挿入されるか、又はＩＰｖ６ヘッダー４３０のフローラベル（flow label）フィールド４３３に挿入されることがある。
【００５９】
図５は、本発明の実施形態によるＴ−ＮＡＬ情報をＩＰパケットに含むことにより最適なＩＰパケットヘッダーを生成する一例を示す。
【００６０】
図５で説明される例において、リアルタイムメディアストリームに適用するために複数のパケットのうちＵＤＰ及びＲＴＰヘッダーから同一に反復される部分を除去することにより、ヘッダーを簡略化する。参照符号５１０、５３０、及び５４０は、ＩＰｖ４パケットを示し、参照符号５５０は、ＩＰｖ６パケットを示す。各パケットの場合に、ＵＤＰヘッダー及びＲＴＰヘッダーを簡略化することによりラベル情報を生成する。
【００６１】
ＩＰｖ４パケット５１０は、ビデオオンデマンド（ＶｏＤ）サービスのようなリアルタイムメディアデータの送信のためのメディアパケットである。参照符号５６０は、ＵＤＰヘッダーを示し、参照符号５７０は、ＲＴＰヘッダーを示す。
【００６２】
リアルタイムメディアサービスにおいて、通常、秒当たりに数十又は数百のパケットが各セッションで送信される。リアルタイムメディアストリームの特性の観点で、メディアパケットのヘッダーは、１つのセッションの間に送信されるパケットごとに同一に反復されるフィールドを含む。参照符号５１１、５１２、５１４、５１５、５１８、５１９、及び５２０は、同一に反復されるフィールドを示す。注目するフィールドは、ＮＡＬヘッダーを示すＮＡＬＨフィールドである。図２を参照して上述したように、ＮＡＬヘッダーは、パケットの重要度又は優先順位を示す情報を含む。一方、参照符号５１３、５１６、及び５１７は、パケットごとに変わるフィールドを示す。しかしながら、これらのフィールドは、他のフィールドと同一であるか又は重複することがある。ここでは、このフィールドの機能についての具体的な説明は省略する。
【００６３】
パケット５３０は、パケット５２０のＵＤＰヘッダー５６０及びＲＴＰヘッダー５７０内の同一のフィールドを１つのフローラベルフィールド（ラベル情報）５３１に集め、パケットごとに変わるフィールドをフローラベルフィールド５３１の後に配列することにより構成される。
【００６４】
一方、長さフィールド５３２は、パケット５３０内のＩＰヘッダーの長さフィールド（図示せず）と同一である。したがって、長さフィールド５３２は、省略が可能である。また、メディアデータが周期的に生成される場合に、受信装置は、タイムスタンプを示すＴＳフィールド５３４で設定された情報を計算することによりＴＳフィールド５３４を省略することができる。パケット５４０は、パケット５３０から長さフィールド５３２及びＴＳフィールド５３４を除去することにより構成される。ＩＰｖ６パケット５５０は、２４ビットのフローラベルフィールド５５１をＩＰｖ６ヘッダーに含ませる。本発明のラベル情報は、ＩＰｖ６ヘッダーのフローラベルフィールド５５１に含まれることがある。
【００６５】
受信装置ですべてのフィールドをパーシングしなければならない既存のヘッダーに比べて、図５に示す簡素化されたヘッダーについては、フローラベルに対応するフィールドを常にパーシングする必要はない。
【００６６】
以下では、本発明によるボトムアップインターフェース情報であるＢ−ＮＡＬ情報について説明する。
【００６７】
Ｂ−ＮＡＬ情報は、本発明での下位階層のネットワークエンティティーから生成されるネットワーク状態情報であることが一般的である。しかしながら、上述したように、場合によっては、Ｂ−ＮＡＬ情報は、ユーザー端末から生成される要求されたＱｏＳ品質情報であることがある。下記では、Ｂ−ＮＡＬ情報がネットワーク状態情報であると仮定して説明する。
【００６８】
このネットワーク状態情報は、使用可能なビット率（available bitrate）、パケット損失率（Packet Loss Ratio）、遅延（Delay）、又はジッター（Jitter）を特定することができる。このネットワーク状態情報は、ルータバッファ状態又は受信バッファ状態をさらに特定することができる。例えば、このネットワーク状態情報は、リアルタイム制御パケット送信プロトコルであるＲＴＣＰの結果から生じる遅延測定及びパケット損失率測定、又は、ＷＬＡＮ（Wireless Local Area Network）のＭＡＣ（Medium Access Control）階層又は３ＧＰＰ（3rd Generation Partnership Project）ＲＡＮにより測定された結果を含むことができる。ここで、もっとも正確な状態情報を用いてＢ−ＮＡＬレジスタを更新する。
【００６９】
また、Ｂ−ＮＡＬ情報を、ストリーム別又はサービス（又はセッション）別に生成することができる。Ｂ−ＮＡＬ情報がサービス（セッション）単位で生成される場合には、Ｂ−ＮＡＬレジスタを含むエンティティーは、セッション別に個別のＢ−ＮＡＬレジスタを備える。Ｂ−ＮＡＬ情報がストリーム単位で設定される場合には、Ｂ−ＮＡＬレジスタは、ストリーム別に存在することができる。Ｂ−ＮＡＬレジスタを使用する代りにＢ−ＮＡＬパケットを送信する場合にも、セッション別又はストリーム別にＢ−ＮＡＬパケットを送信することができる。
【００７０】
一方、このネットワーク状態情報を、３通りの方式で大きく示すことができる。１つの方式は、絶対値を使用する方式である。例えば、使用可能なビット率をＭｂｐｓで示す。他の方式は、基準値に対する相対値として情報を表示する方式である。例えば、呼設定の間に１Ｍｂｐｓリソースが予約され、現在の使用可能なビット率が８００ｋｂｐｓである場合に、使用可能なビット率は、“８０％”として表示される。もう１つの方式は、対応する情報の変化率を使用する方式である。すなわち、どのくらいの情報が前の時点から変化したかが表示される。
【００７１】
Ｂ−ＮＡＬ情報を、上位階層エンティティー内でアプリケーションシステムのＢ−ＮＡＬレジスタに保存することができ、Ｂ−ＮＡＬレジスタは、１つのサービスを構成するサービス別に又はストリーム別に構成することができる。Ｂ−ＮＡＬレジスタを使用する代りに、Ｂ−ＮＡＬパケットを送信する場合にもセッション別又はストリーム別にＢ−ＮＡＬパケットを送信することができる。
【００７２】
また、Ｂ−ＮＡＬ情報を、周期的又は非周期的に生成することができる。Ｂ−ＮＡＬ情報が下位階層で周期的に生成される場合に、上位階層でも周期的にＢ−ＮＡＬ情報を確認することができる。Ｂ−ＮＡＬ情報が非周期的に生成される場合には、上位階層でも非周期的にＢ−ＮＡＬ情報を確認することができる。この場合に、新たな情報がＢ−ＮＡＬレジスタに記憶されることを示す割り込み（interrupt）を上位階層で発生する場合に、Ｂ−ＮＡＬレジスタに記憶されたＢ−ＮＡＬ情報を確認することができる。
【００７３】
以下では、Ｂ−ＮＡＬ情報を更新し、情報の使用のためにＢ−ＮＡＬ情報を返還し取得する方式について説明する。Ｂ−ＮＡＬフィールドは、状態を更新するか又は返還するＡＰＩを提供する。これは、上述したＱｏＳ情報又はメディア制御に適合したパラメータに対して動作する。各パラメータは、ＡＰＩを有し、個別的な更新又は返還が可能である。各パラメータは、その特性に適合した形態を有する。例えば、ビット率は、符号なし整数（unsigned integer）の形態で保存され、浮動小数点を必要とするパラメータも適合した形態で保存される。ＩＤフィールドは、メディアセッション又はストリームに従ってレジスタを識別するために使用される。また、更新される周期フィールドは、更新される周期情報を提供するために使用される。このフィールドは、メディアデータ供給部のデータ補正周期に従って設定してもよく、ネットワークは、このフィールドの値に従ってレジスタを更新する。このフィールドが設定されない場合に、ネットワークは、初期のセッションを確立する間に、再更新なしに１回Ｂ−ＮＡＬレジスタを更新する。この時に、ＣＬＯ部は、ＱｏＳ制御なしにベストエフォート方式（best effort manner）で動作する。上述した非周期的な動作において、周期フィールドは、すべて１で満たされる。このような方式において、Ｂ−ＮＡＬ情報パラメータが更新される時に割り込みが発生する。
【００７４】
図６は、本発明の実施形態によるストリーム別Ｂ−ＮＡＬ情報のフォーマットの一例を示す。
【００７５】
図６を参照すると、参照符号６１０、６２０、６３０、及び６４０で示すように、Ｂ−ＮＡＬ情報は、ストリーム別に生成され、各ストリームに対応するラベル情報とともに付加される。対応するラベルを有するストリームのＢ−ＮＡＬ情報は、使用可能なビット率パラメータ（Available bitrate parameter）６１１、パケット損失率パラメータ（packet loss rate parameter）６１３、遅延及び／又はジッターパラメータ（delay and/or jitter parameter）６１５などを含む。ラベル情報は、更新周期及びセッション又はフローＩＤを含む。
【００７６】
以上、本発明により定義されたＴ−ＮＡＬ情報及びＢ−ＮＡＬ情報について説明した。ＣＬＯは、Ｔ−ＮＡＬ情報及びＢ−ＮＡＬ情報を使用して可能である。相互階層最適化は、ネットワーク状態を認識してビデオ符号化を実行し（network-aware video coding）、メディアストリームに関する情報、すなわち、メディアストリームの重要度又は優先順位などを認識して動作するメディアネットワークエンティティーによりメディアデータサービスを提供することを意味する。このメディアストリームに関する情報に基づいてサービスするエンティティーをメディア認識ネットワークエレメント（Media Aware Network Element：ＭＡＮＥ）と呼ぶ。下記では、“ＭＡＮＥ”という用語を使用して説明する。
【００７７】
以下では、本発明のネットワークエンティティー、すなわち、ＭＡＮＥの動作について説明する。
【００７８】
ルータ、ＩＥＥＥ８０２シリーズのＭＡＣ階層、及び３ＧＰＰ ＢＭＳＣのように受信されたメディアパケットをフォーワーディング（fowading）するネットワークエンティティーは、Ｔ−ＮＡＬ情報のラベル情報から決定されたパケットの重要度に従ってパケットを適応的にフォーワーディングするＭＡＮＥとして動作することができる。例えば、ｄｉｆｆＳｅｒｖルーティング方式を使用するルータは、データがバッファを超過する場合に、優先順位がもっとも低いパケットから廃棄する。このために、ルータは、Ｔ−ＮＡＬのラベル値を確認する。
【００７９】
クラス別ＱｏＳ方式の場合に、受信されたパケットがどんなサービスに属しているパケットであるかと無関係に、パケットのＩＰヘッダーに含まれている重要度情報、すなわち、ラベル値に従って適応的に処理される。例えば、ラベル値１１を有するオーディオパケット、ラベル値１０を有する基本階層ビデオパケット、ラベル値０１を有する向上１階層ビデオパケット、及びラベル値００を有する向上２階層ビデオパケットが受信され、ネットワーク状態又はルータバッファの容量を超過するデータ量によりパケットのうちのいずれか１つが廃棄されるべき場合に、ラベル値に従ってパケットを廃棄する。すなわち、向上２階層ビデオパケット、向上１階層ビデオパケット、基本階層ビデオパケット、及びオーディオパケットの順序にパケットを廃棄する。ＩＥＥＥ８０２．１１ｅ標準において、パケットのＩＰヘッダーに含まれている重要度情報に従って予め定められたキュー（Queue）にパケットを挿入する。一般的に、パケットは、４つのステップで優先順位が設定され、各キューは、キューを通過するパケットの速度及びパケット損失処理方法の観点で異なることがある。
【００８０】
フロー別ＱｏＳ方式の場合に、ラベル値を確認し、ラベル値に対応する予め定められたリソースを用いてＱｏＳ（ビット率、損失率、及び遅延など）をサポートする。このラベルに対応するリソースは、対応するネットワークエンティティーにストリーム別に予め保存されたリソース予約テーブルを参照して決定することができる。例えば、ＩＥＥＥ８０２．１６において、オーディオストリームに対するＱｏＳクラスがＵＧＳ（Unsolicited Guaranteed Service）である場合に、ＱｏＳクラスに対して予め定められたＱｏＳ要件を保証する。したがって、このリソース予約テーブルは、対応するサービスが終了するまでネットワークエンティティーに保存される。すなわち、送信装置からパケットが受信される場合に、対応するパケットのラベルを確認し、ラベルに対応するストリームのＱｏＳ要件をリソース予約テーブルから検索する。このようなサービスは、ＱｏＳ要件に従うリソースを用いて提供される。
【００８１】
図７は、本発明の実施形態によるＭＡＮＥの動作の一例を示す。
【００８２】
図７を参照すると、ＭＡＮＥ７０１は、リソース予約テーブル７０２と、フォーワーディングポリシー決定部７１１と、使用可能なリソース判定部７０８とを含む。
【００８３】
送信装置からパケットを受信する場合（７０６）に、フォーワーディングポリシー決定部７０９は、フォーワーディングポリシーに従ってパケットを適応的にフォーワーディングする。このフォーワーディングポリシーは、受信されたパケットのＴ−ＮＡＬ情報に含まれているラベル値に基づいて変わる。
【００８４】
ＭＡＮＥ７０１がクラス別ＱｏＳをサポートする場合に、フォーワーディングポリシー決定部７１０は、対応するパケットのクラスを確認した後に、このパケットのクラスに従って対応するパケットをフォーワーディングするか否かを決定する。一方、ＭＡＮＥ７０１がストリーム別ＱｏＳをサポートする場合に、フォーワーディングポリシー決定部７１０は、このパケットのラベル値を確認し、リソース予約テーブル７０２内の対応するラベルに割り当てられたリソースを確認し（７０５及び７１１）、使用可能なリソース判定部７０４から使用可能なリソース情報を受信し（７０７）、使用可能なリソース内のパケットに対するフォーワーディングポリシーを決定した後に、このフォーワーディングポリシーに従ってこのパケットをフォーワーディングする（７１０）。
【００８５】
以下では、本発明の実施形態に従う受信装置の動作について簡単に説明する。
【００８６】
受信装置は、各ストリーム別に復号器を含み、特定の復号器で必要なだけのバッファ容量を確保する。受信されたパケットがラベルを含む場合に、受信装置は、このラベルを確認し、このパケットに対応する復号器を確認する。対応するパケットにラベルが存在しない場合に、受信装置は、ＲＴＰヘッダーを読み出し、このメディアパケットの復号のための復号器を確認することができる。
【００８７】
以下では、Ｂ−ＮＡＬ情報を受信し保存するＢ−ＮＡＬレジスタを有するエンティティーについて説明する。
【００８８】
まず、メディアサービスが１：１画像電話又はＶｏＤのようなユニキャストメディアサービスの場合に、送信装置は、Ｂ−ＮＡＬレジスタを有することができる。この時に、送信装置のアプリケーション階層でのＢ−ＮＡＬレジスタ内のＢ−ＮＡＬ情報は、ＭＡＮＥ又は受信装置から受信されたＢ−ＮＡＬパケットでアップデートされる。この場合に、送信装置は、周期的に又は非周期的にＢ−ＮＡＬレジスタを読み出すことにより適応的にメディアデータを送信する。例えば、使用可能なビット率５４Ｍｂｐｓがあると、ユーザーが陰影地域に進入し、使用可能なビット率が２Ｍｂｐｓまで減少し、パケット損失率が増加する場合には、このようなネットワーク状態情報を、Ｂ−ＮＡＬレジスタに伝達し保存することができる。この場合に、送信装置は、ＳＶＣで最も低い階層の映像を送信し、パケット損失を克服するのに必要なだけのＦＥＣパケットを送信する。
【００８９】
受信装置がメディア品質を要求する場合に、Ｂ−ＮＡＬレジスタは、受信装置に構成される。受信装置は、Ｂ−ＮＡＬ情報をネットワークから受信し、Ｂ−ＮＡＬ情報に従って次の送信パケットに対して適切なＱｏＳレベルを要求する。
【００９０】
他方、マルチポイント画像電話（テレビ会議）のようなマルチキャスト／ブロードキャストパケットの場合に、送信装置は、対応するパケットを最大ＱｏＳを設定して送信する。このパケットは、パケット経路の分岐点で必要とされるＱｏＳレベルに従って転送される。あるいは、受信装置は、自身のＢ−ＮＡＬ情報に基づいてその受信能力を判定し、分岐点の分散されたサービスを選択的に受信する。例えば、１０ＭｂｐｓのＳＶＣ  ＨＤＴＶサービスがＶＤＳＬに接続されたＨＤＴＶ及びＨＳＤＰＡに接続された携帯電話に同時に提供され、２タイプの経路が分岐される経路にＭＡＮＥが存在する場合に、３ＧＰＰ  ＢＭＳＣのようなＭＡＮＥは、Ｂ−ＮＡＬレジスタを有することができる。このような例において、使用可能なビット率が５Ｍｂｐｓであると、陰影地域内のユーザーの存在により使用可能なビット率が２Ｍｂｐｓまで減少し、パケット損失率が増加する場合には、このようなネットワーク状態情報は、ＭＡＮＥのＢ−ＮＡＬレジスタに記録される。この場合に、ＭＡＮＥは、ＳＶＣで最も低い階層の映像をフォーワーディングし、損失率を克服するのに必要なだけのＦＥＣパケットを送信する。この時に、送信されるメディアデータ及びＦＥＣパケットのデータ量は、２Ｍｂｐｓ内でなければならない。
【００９１】
新たなブロードキャスト又はマルチキャストサービスが接続される場合には、ランダムアクセスにより初期の呼設定に必要なデータを１：１通信を通してサーバに要求し受信することができる。あるいは、サーバは、周期的にランダムアクセスに必要とされる情報を送信することができる。サービスが２４時間持続される場合には、特定のデフォルトＴ−ＮＡＬが定義されなければならない。
【００９２】
一方、ユーザーがパケットのＱｏＳ保証を要求する場合に、ユーザーが要求したＱｏＳは、ユーザーアプリケーション階層により提供されるユーザーインターフェース（User Interface：ＵＩ）を通して認識される。ユニキャストサービスである場合には、この要求されたＱｏＳは、送信装置のＢ−ＮＡＬレジスタにシグナリングされ記録される。マルチキャストサービスである場合には、この要求されたＱｏＳは、ユーザー端末に入力されるトラフィックを管理するＭＡＮＥのＢ−ＮＡＬレジスタに記録される。この要求されたＱｏＳがネットワークによりサポートされるＱｏＳ範囲を超過する場合には、このサービスは、サポートされるＱｏＳ範囲に限定される。他方、この要求されたＱｏＳがネットワークによりサポートされるＱｏＳ範囲より小さい場合には、ユーザーの要求通りにサービスを提供する。
【００９３】
以上、本発明を具体的な実施形態を参照して詳細に説明してきたが、本発明の範囲及び趣旨を逸脱することなく様々な変更が可能であるということは、当業者には明らかであり、本発明の範囲は、上述の実施形態に限定されるべきではなく、特許請求の範囲の記載及びこれと均等なものの範囲内で定められるべきである。
【符号の説明】
【００９４】
１１０  ビデオ符号化階層
１１１  ＶＣＬで生成された符号化データ
１１３  パラメータセット及びＳＥＩなど
１２０  ネットワーク抽象化階層
１２３  ＶＣＬ  ＮＡＬ単位
１２５  非ＶＣＬ  ＮＡＬ単位
１３０  システムネットワーク抽象化層
１３１  Ｈ．２６４／ＡＶＣファイルフォーマット
１３５  ＭＰＥＧ−２システム
【図１】
2014509113.tif 000003
【図２】
2014509113.tif 000004
【図３】
2014509113.tif 000005
【図４】
2014509113.tif 000006
【図５】
2014509113.tif 000007
【図６】
2014509113.tif 000008
【図７】
2014509113.tif 000009
【国際調査報告】
2014509113.tif 000010
2014509113.tif 000011
2014509113.tif 000012
2014509113.tif 000013
2014509113.tif 000014
2014509113.tif 000015
2014509113.tif 000016
2014509113.tif 000017
2014509113.tif 000018
2014509113.tif 000019
2014509113.tif 000020
2014509113.tif 000021