図面 (/)

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

出願人 サムスンエレクトロニクスカンパニーリミテッドユニヴァーシティー-インダストリー・コーペレーション・グループ・オブ・キュン・ヒー・ユニヴァーシティー
発明者 キュン-モ・パクスン-オウ・フワンジェ-ヨン・ソンドウ-ユン・スーヨン-フン・イ
出願日 2017年5月16日 (3年6ヶ月経過) 出願番号 2017-097617
公開日 2017年9月7日 (3年2ヶ月経過) 公開番号 2017-158208
状態 特許登録済
技術分野 広域データ交換
主要キーワード ローバイト 認識ネットワーク 空間的階層 ポート番 リソース判定 テキストパケット ラベルテーブル マルチメディアデータパケット
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2017年9月7日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (8)

課題

本発明はマルチメディアサービスを提供する時にマルチメディアサービスを適応的に提供する方法及び装置を提供することを目的とする。

解決手段

本発明は、マルチメディアデータパケットを送信する方法及び装置に関し、マルチメディアデータパケットを送信する方法は、送信されるマルチメディアデータに関する情報を抽象化するメディア抽象化階層(MAL)情報を生成するステップと、上記メディア抽象化階層情報を含むマルチメディアデータパケットを生成するステップと、上記マルチメディアデータパケットをネットワークエンティティーに送信するステップとを有することを特徴とする。

概要

背景

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

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

まず、BEサービスのQoSを保証するために何のサポートもしない。

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

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

IEEE 802.16(WiBRO及びWIMAX)及びロングタームエボルーション(Long Term Evolution:LTE標準だけではなく、3GPP UMTS(3G)標準でもクラス別QoS及びフロー別QoSをサポートする。しかしながら、QoS方式を使用するためには、上位階層であるメディア階層には、下位階層であるネットワーク間のインターフェースが必要である。

MPEG(Moving Picture Experts Group)−2及びH.264、特に、スケーラブルビデオコーディング(Scalable Video Coding:SVC)を使用する時に、各ビデオパケットは、重要度の観点で相互に異なる。ビデオサービスのQoSを効率的に制御するためには、このようなパケット間の重要度差を識別しなければならない。パケットスイッチング方式の場合に、IPv6では、パケット別重要度を識別するために、5つのタプル(tuples)(すなわち、受信者アドレス送信者アドレス受信者内のサービスのポート番号、送信器内のサービスのポート番号、及び使用されるプロトコル)をIPv6ヘッダーから読み出した後に、パケットの重要度を示すヘッダーデータをビデオパケットのペイロードから読み出さなければならない。このような方式は、パケットごとに処理時間が多くかかり、プロトコル階層独立性違反する。すなわち、ルータは、パケットの処理にあたり、パケットのIPヘッダーだけを読み出すことができなければならないが、これは、実際には不可能である。

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

一方、標準化が進行中であるスケーラブルビデオコーディング(Scalable Video Coding:SVC)又はマルチビュービデオコーディング(Multi-view Video Coding:MVC)は、H.264/AVC(Advanced Video Coding)標準に基づいている。符号化されたデータは、H.264/AVCのネットワーク抽象化層単位(Network Abstraction Layer Unit:NALU)フォーマットビット列に構成される。

図1は、H.264/AVCのビデオ符号化階層(Video Coding Layer:VCL)及びネットワーク抽象化階層(NAL)を示す図である。

H.264/AVCにおいて、ネットワーク抽象化階層(Network Abstraction Layer:NAL)120は、ビデオ符号化を処理するビデオ符号化階層110と符号化された情報の送信及び格納を行う下位階層システム130との間で定義される。したがって、VCL110は、NAL130から分離される。

NAL120は、H.264/AVCファイルフォーマット131、実時間転送プロトコル(Real-time Transport Protocol:RTP)133、及びMPEG−2システム135のようなフォーマットで符号化データ111を下位階層システム130のビット列にマッピングするために、NAL単位(NAL Unit:NALU)でVCLで生成された符号化データ111及びパラメータセット又は付加拡張情報(Supplemental Enhancement Information:SEI)113のような情報を処理する。

NAL単位は、VCL NAL単位123と非(non)VCL NAL単位125とに分けられる。VCL NAL単位123は、VCLで生成された符号化データ111に対応するNAL単位であり、非VCL NAL単位125は、パラメータセット又はSEI113の情報に対応するNAL単位である。

NAL単位は、基本的に、NALヘッダーと、VCLで動映像圧縮の結果から生成されたデータ部分であるローバイトシーケンスペイロード(Raw Byte Sequence Payload:RBSP)とを含む。

図2は、NAL単位のフォーマットを説明するための図である。

図2を参照すると、NAL単位200は、NALヘッダー210とNALペイロード240とを含む。

NALヘッダー210は、一般的に、1乃至5バイトのサイズを有する。NALヘッダー210は、NALUのタイプを示すNALUタイプ情報220とNALUペイロードに含まれる圧縮された元来のデータの階層を識別する階層識別情報(Layer Identification Information)230とを含む。

NALUタイプ情報220は、1ビットの固定ビット(F)フィールド221、NALUが参照ピクチャであるか否かを示す2ビットのNRI(nal_ref_idc)フィールド222と、NALUのタイプを示す識別子である5ビットのNALU Typeフィールド223とを含む。

階層識別情報230は、優先順位、空間階層ベル時間階層レベル、及び/又は品質階層レベルの組み合せを含むことができる。すなわち、階層識別情報230は、圧縮された元来のデータの階層を識別することができるようにNALUの優先順位を示す8ビットのプライオリティ(Priority:以下、“P”と称する)フィールド231、NALUの空間階層レベルを示す3ビット乃至8ビットのディペンデンシー識別子(Dependency_id:以下、“D”と称する)フィールド232、NALUの時間階層レベルを示す3ビット乃至8ビットのテンポラルレベル(Temporal_level:以下、“T”と称する)フィールド233、及び/又はNALUの品質階層レベルを示す2ビット乃至8ビットのクオリティーレベル(Quality_level:以下、“Q”と称する)フィールド234を含む。

参考までに、同一のNALUフォーマットは、MVC(Multi-view Video Coding)でも使用される。しかしながら、MVCにおいて、NALUタイプ情報220及び階層識別情報230の代わりにビューを示すビュー識別情報(View Identification Information)は、NALヘッダーに含まれることがある。

上述したSVC又はMVCに対するNALUフォーマットに従うと、NALUの階層又はビューを識別するためには、NALヘッダーの階層識別情報230又はビュー識別情報をすべてパーシング(parsing)しなければならない。特に、階層識別情報230は、4バイト以下のサイズを有し、NALヘッダー210のパーシングを通してP231、D232、T233、及びQ234の値をすべて認識することができない場合には、対応するNALUが属する階層を判定することができない。しかしながら、NALヘッダー210のP231、D232、T233、及びQ234の値を知るためにNALヘッダー210をすべてパーシングすることは、プロセッサ制約を課し、システムのコストを増加させる。

また、NALヘッダー210は、NRIフィールド222及びPフィールド231に加えて、D232、T233、及びQ234のような階層識別情報230のようにパケットの重要度を識別する様々な情報を含み、これらの情報間の関係が定義されていないので、これを活用するのに難しさがある。例えば、階層識別情報D232、T233、及びQ234について、D232の値として“1”を有するパケットとT233の値として“1”を有するパケットとが存在する時に、符号化過程予測に対する関係が理解されない場合には、2つのパケットの優先順位上の階層を識別することができない。

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

概要

本発明はマルチメディアサービスを提供する時にマルチメディアサービスを適応的に提供する方法及び装置を提供することを目的とする。本発明は、マルチメディアデータパケットを送信する方法及び装置に関し、マルチメディアデータパケットを送信する方法は、送信されるマルチメディアデータに関する情報を抽象化するメディア抽象化階層(MAL)情報を生成するステップと、上記メディア抽象化階層情報を含むマルチメディアデータパケットを生成するステップと、上記マルチメディアデータパケットをネットワークエンティティーに送信するステップとを有することを特徴とする。

目的

本発明の目的は、少なくとも上述した問題点及び/又は不都合に取り組み、少なくとも以下の便宜を提供する

効果

実績

技術文献被引用数
0件
牽制数
0件

この技術が所属する分野

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

マルチメディアデータパケットを送信するための方法であって、少なくとも一つのプロセッサによりメディアデータ関連情報を含むメディアデータパケットが生成されるステップと、前記少なくとも一つのプロセッサにより前記メディアデータパケットが送信されるステップと、を含み、前記メディアデータ関連情報は、送信の遅延感度(delay sensitivity)及び送信優先順位(transmissionpriority)を示すサービス品質(QoS)情報と、ネットワークリソース関連情報を示すフロー(flow)情報を含む、方法。

請求項2

前記送信優先順位は、前記メディアデータパケットの損失優先順位(loss priority)に関連する、請求項1に記載の方法。

請求項3

前記ネットワークリソース関連情報は、セッションの間のリソース予約に対する情報を含む、請求項1に記載の方法。

請求項4

前記メディアデータ関連情報は、ビットレート情報をさらに含む、請求項1に記載の方法。

請求項5

前記メディアデータ関連情報は、バッファ状態をさらに含む、請求項1に記載の方法。

請求項6

マルチメディアデータパケットを送信するための装置であって、送信器と、メディアデータ関連情報を含むメディアデータパケットを生成し、前記生成されたメディアデータパケットを送信するように前記送信器を制御するプロセッサと、を含み、前記メディアデータ関連情報は、送信の遅延感度(delay sensitivity)及び送信優先順位(transmission priority)を示すサービス品質(QoS)情報と、ネットワークリソース関連情報を示すフロー(flow)情報を含む、装置。

請求項7

前記送信優先順位は、前記メディアデータパケットの損失優先順位(loss priority)に関連する、請求項6に記載の装置。

請求項8

前記ネットワークリソース関連情報は、セッションの間のリソース予約に対する情報を含む、請求項6に記載の装置。

請求項9

前記メディアデータ関連情報は、ビットレート情報をさらに含む、請求項6に記載の装置。

請求項10

前記メディアデータ関連情報は、バッファ状態をさらに含む、請求項6に記載の装置。

技術分野

0001

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

背景技術

0002

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

0003

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

0004

まず、BEサービスのQoSを保証するために何のサポートもしない。

0005

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

0006

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

0007

IEEE 802.16(WiBRO及びWIMAX)及びロングタームエボルーション(Long Term Evolution:LTE標準だけではなく、3GPP UMTS(3G)標準でもクラス別QoS及びフロー別QoSをサポートする。しかしながら、QoS方式を使用するためには、上位階層であるメディア階層には、下位階層であるネットワーク間のインターフェースが必要である。

0008

MPEG(Moving Picture Experts Group)−2及びH.264、特に、スケーラブルビデオコーディング(Scalable Video Coding:SVC)を使用する時に、各ビデオパケットは、重要度の観点で相互に異なる。ビデオサービスのQoSを効率的に制御するためには、このようなパケット間の重要度差を識別しなければならない。パケットスイッチング方式の場合に、IPv6では、パケット別重要度を識別するために、5つのタプル(tuples)(すなわち、受信者アドレス送信者アドレス受信者内のサービスのポート番号、送信器内のサービスのポート番号、及び使用されるプロトコル)をIPv6ヘッダーから読み出した後に、パケットの重要度を示すヘッダーデータをビデオパケットのペイロードから読み出さなければならない。このような方式は、パケットごとに処理時間が多くかかり、プロトコル階層独立性違反する。すなわち、ルータは、パケットの処理にあたり、パケットのIPヘッダーだけを読み出すことができなければならないが、これは、実際には不可能である。

0009

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

0010

一方、標準化が進行中であるスケーラブルビデオコーディング(Scalable Video Coding:SVC)又はマルチビュービデオコーディング(Multi-view Video Coding:MVC)は、H.264/AVC(Advanced Video Coding)標準に基づいている。符号化されたデータは、H.264/AVCのネットワーク抽象化層単位(Network Abstraction Layer Unit:NALU)フォーマットビット列に構成される。

0011

図1は、H.264/AVCのビデオ符号化階層(Video Coding Layer:VCL)及びネットワーク抽象化階層(NAL)を示す図である。

0012

H.264/AVCにおいて、ネットワーク抽象化階層(Network Abstraction Layer:NAL)120は、ビデオ符号化を処理するビデオ符号化階層110と符号化された情報の送信及び格納を行う下位階層システム130との間で定義される。したがって、VCL110は、NAL130から分離される。

0013

NAL120は、H.264/AVCファイルフォーマット131、実時間転送プロトコル(Real-time Transport Protocol:RTP)133、及びMPEG−2システム135のようなフォーマットで符号化データ111を下位階層システム130のビット列にマッピングするために、NAL単位(NAL Unit:NALU)でVCLで生成された符号化データ111及びパラメータセット又は付加拡張情報(Supplemental Enhancement Information:SEI)113のような情報を処理する。

0014

NAL単位は、VCL NAL単位123と非(non)VCL NAL単位125とに分けられる。VCL NAL単位123は、VCLで生成された符号化データ111に対応するNAL単位であり、非VCL NAL単位125は、パラメータセット又はSEI113の情報に対応するNAL単位である。

0015

NAL単位は、基本的に、NALヘッダーと、VCLで動映像圧縮の結果から生成されたデータ部分であるローバイトシーケンスペイロード(Raw Byte Sequence Payload:RBSP)とを含む。

0016

図2は、NAL単位のフォーマットを説明するための図である。

0017

図2を参照すると、NAL単位200は、NALヘッダー210とNALペイロード240とを含む。

0018

NALヘッダー210は、一般的に、1乃至5バイトのサイズを有する。NALヘッダー210は、NALUのタイプを示すNALUタイプ情報220とNALUペイロードに含まれる圧縮された元来のデータの階層を識別する階層識別情報(Layer Identification Information)230とを含む。

0019

NALUタイプ情報220は、1ビットの固定ビット(F)フィールド221、NALUが参照ピクチャであるか否かを示す2ビットのNRI(nal_ref_idc)フィールド222と、NALUのタイプを示す識別子である5ビットのNALU Typeフィールド223とを含む。

0020

階層識別情報230は、優先順位、空間階層ベル時間階層レベル、及び/又は品質階層レベルの組み合せを含むことができる。すなわち、階層識別情報230は、圧縮された元来のデータの階層を識別することができるようにNALUの優先順位を示す8ビットのプライオリティ(Priority:以下、“P”と称する)フィールド231、NALUの空間階層レベルを示す3ビット乃至8ビットのディペンデンシー識別子(Dependency_id:以下、“D”と称する)フィールド232、NALUの時間階層レベルを示す3ビット乃至8ビットのテンポラルレベル(Temporal_level:以下、“T”と称する)フィールド233、及び/又はNALUの品質階層レベルを示す2ビット乃至8ビットのクオリティーレベル(Quality_level:以下、“Q”と称する)フィールド234を含む。

0021

参考までに、同一のNALUフォーマットは、MVC(Multi-view Video Coding)でも使用される。しかしながら、MVCにおいて、NALUタイプ情報220及び階層識別情報230の代わりにビューを示すビュー識別情報(View Identification Information)は、NALヘッダーに含まれることがある。

0022

上述したSVC又はMVCに対するNALUフォーマットに従うと、NALUの階層又はビューを識別するためには、NALヘッダーの階層識別情報230又はビュー識別情報をすべてパーシング(parsing)しなければならない。特に、階層識別情報230は、4バイト以下のサイズを有し、NALヘッダー210のパーシングを通してP231、D232、T233、及びQ234の値をすべて認識することができない場合には、対応するNALUが属する階層を判定することができない。しかしながら、NALヘッダー210のP231、D232、T233、及びQ234の値を知るためにNALヘッダー210をすべてパーシングすることは、プロセッサ制約を課し、システムのコストを増加させる。

0023

また、NALヘッダー210は、NRIフィールド222及びPフィールド231に加えて、D232、T233、及びQ234のような階層識別情報230のようにパケットの重要度を識別する様々な情報を含み、これらの情報間の関係が定義されていないので、これを活用するのに難しさがある。例えば、階層識別情報D232、T233、及びQ234について、D232の値として“1”を有するパケットとT233の値として“1”を有するパケットとが存在する時に、符号化過程予測に対する関係が理解されない場合には、2つのパケットの優先順位上の階層を識別することができない。

0024

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

先行技術

0025

米国特許出願公開第2009/0175353号明細書

発明が解決しようとする課題

0026

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

0027

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

0028

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

0029

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

課題を解決するための手段

0030

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

0031

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

0032

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

0033

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

発明の効果

0034

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

0035

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

図面の簡単な説明

0036

H.264/AVCにおけるビデオ符号化階層(VCL)及びネットワーク抽象化階層(NAL)を示す図である。
NAL単位のフォーマットを示す図である。
本発明の一実施形態による送信装置の構成を示す図である。
本発明の一実施形態によるメディア抽象化階層(MAL)情報をIPパケットに挿入する方式を示す図である。
本発明の一実施形態によるMAL情報を含むIPパケットヘッダーの構成を示す図である。
本発明の一実施形態によるメディア認識ネットワーク要素(MANE)の構成を示す図である。
本発明の一実施形態による受信装置の構成を示す図である。

実施例

0037

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

0038

本発明の実施形態は、ビデオデータのための標準であるMPEG−4/AVC(Advanced Video Coding, H.264)、SVC(Scalable Video Coding)、及びMVC(Multi-view Video Coding)で使用しているネットワーク抽象化階層(Network Abstraction Layer:NAL)の概念をビデオデータだけでなく他のメディアデータ(例えば、オーディオデータグラフィックデータ、テキストデータなど)に適用する。

0039

図2を参照して上述したように、従来のNALヘッダー210は、ビデオパケットの重要度を表示する情報を含む。また、SVC NALヘッダーは、時間的階層空間的階層、及び品質階層を示す階層認識情報230を含み、MVCヘッダーは、ビュー(view)番号を示す情報を含む。

0040

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

0041

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

0042

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

0043

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

0044

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

0045

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

0046

メディア抽象化階層部302は、1つのIPパケットをメディアデータ供給部301から受信し(308)、MAL情報を生成し、パケット生成部303に送信する(310)。また、メディア抽象化階層部302は、メディアデータ供給部301から受信したIPパケットをパケット生成部303に送信する(309)。

0047

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

0048

パケット生成部303は、メディア抽象化階層部302から受信されたMAL情報310及びIPパケット309を用いてパケットを生成し、この生成されたパケットを、ネットワーク313を通して送信する。MAL情報に含まれたメディア分類子情報及びラベル情報は、IPパケットのヘッダー又は他の下位プロトコルのパケットのヘッダーに含まれることができる。

0049

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

0050

まず、MALで生成されるメディア分類子を使用するクラス別サービス品質(QoS)方式について説明する。

0051

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

0052

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

0053

この後に、MALで生成されるラベル情報を用いるフロー別(すなわち、ストリーム別)QoS方式について説明する。

0054

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

0055

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

0056

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

0057

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

0058

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

0059

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

0060

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

0061

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

0062

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

0063

例えば、1つのメディアサービスが1つのビデオストリーム、オーディオストリーム、及び字幕をサポートするためのテキストストリームを含む場合に、MALは、各ストリームの送信遅延及び損失要求事項に従ってQoSクラスを抽象化し、これを分類するための形式でメディア分類子値を決定する。選択的に、オーディオストリームの重要度は、ビデオストリームの重要度よりさらに大きいことがある。図4に後述するように、メディア分類子の値は、インターネットプロトコルバージョン4(Internet Protocol version 4:IPv4)ヘッダーのタイプオブサービス(Type-Of-Service:TOS)フィールド又はインターネットプロトコルバージョン6(Internet Protocol version 6:IPv6)ヘッダーのトラフィッククラス(Traffic Class:TC)フィールドに挿入することができる。例えば、このメディア分類子の値が2ビットに設定される場合に、11、10、01、及び00の順序でパケット別重要度を差別化する。すなわち、オーディオパケットは、メディア分類子値11を含み、テキストパケットは、メディア分類子値10を含み、ビデオパケットは、メディア分類子値01を含むことができる。

0064

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

0065

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

0066

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

0067

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

0068

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

0069

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

0070

図4は、本発明の一実施形態によるMAL情報をIPパケットに挿入する方法を示す図である。

0071

図4を参照すると、MALパケットのための仮想ヘッダーは、本発明の一実施形態に従って定義されたMAL情報フォーマットで定義される。この仮想ヘッダーに含まれた内容は、下位階層内のパケットヘッダー(例えば、IPパケットヘッダー)に含めるためのものであり、仮想ヘッダー420は、内部的に、メディア分類子ヘッダー421とラベルヘッダー422とに分類される。

0072

メディア分類子ヘッダー421は、下位階層がクラス別QoS方式を使用する時に適用することができ、メディア分類子ヘッダー421の長さは、システム設定に従って変わり得る。下位階層のクラス別QoSプロトコルとの互換を考慮すると、その長さは、3ビット乃至6ビット程度が好ましい。メディア分類子ヘッダー421は、IPv4ヘッダー410のTOSフィールド411に挿入するか又はIPv6ヘッダー430のTCフィールド431に挿入することができる。

0073

ラベルヘッダー422は、下位階層がフロー別QoS方式を使用する時に適用することができる。8ビットのサイズを有するラベルヘッダー422は、ラベル番号を含む7ビットと必要の時に拡張のための拡張フラグビットの1ビットとを含む。ラベルヘッダー422は、IPv4ヘッダー410の拡張IPヘッダー(extended IP header)413に挿入するか、又はIPv6ヘッダー430のフローラベル(flow label)フィールド433に挿入することができる。

0074

図5は、本発明の一実施形態によるMAL情報を含むIPパケットヘッダーの構成を示す図である。

0075

図5は、リアルタイムメディアストリームに簡素化されたヘッダーを適用するために、複数のパケットのうちUDPヘッダー及びRTPヘッダーで同一に反復される部分を除去し、このような情報をLTに挿入することによりヘッダーを簡素化する方法を示す。参照符号510、530、及び540は、IPv4パケットを示し、参照符号550は、IPv6パケットを示す。図5は、それぞれのパケットでUDPヘッダー及びRTPヘッダーを簡素化することによりラベル情報を生成する一例を示す。

0076

参照符号510は、オンデマンドビデオサービスのようなリアルタイムメディアデータの送信のためのメディアパケットを示す。参照符号560は、UDPヘッダーを示し、参照符号570は、RTPヘッダーを示す。

0077

リアルタイムメディアサービスにおいて、一般的に、秒当たりの数十又は数百のパケットが、1つのセッションに対して送信される。リアルタイムメディアストリームの特性により、送信されるメディアパケットのヘッダーは、1つのセッションの間に送信されるパケットごとに同一に反復されるフィールドを含む。参照符号511、512、514、515、518、519、及び520は、パケットごとに同一に反復されるフィールドであり、参照符号513、516、及び517は、パケットにより差別化されるフィールド(このフィールドは、同一であるか又は他のフィールドと重複することもある)であるが、このフィールドについての詳細な説明は、本発明の要旨を不明瞭にするので省略する。

0078

重要なフィールドの1つは、ネットワーク抽象化階層ヘッダー(Network Abstraction Layer Header:NALH)フィールド520である。このフィールドは、NALヘッダーを示し、図2に示すように、パケットの重要度又は優先順位を含む。

0079

参照符号530で示すパケットにおいて、パケット520のUDPヘッダー560及びRTPヘッダー570で反復されるフィールド511、512、514、515、518、519、及び520は、1つのラベル情報(フローラベルフィールド)531に挿入され、パケットごとに異なり得るフィールド513、516、及び517は、フローラベルフィールド531の後ろに配列される。

0080

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

0081

参照符号540で示すパケットは、参照符号530で示すパケットで重複する長さフィールド532及び受信側で計算可能なTSフィールド534が省略されるパケットを意味する。

0082

参照符号550で示すパケットは、IPv6パケットを示し、IPv6ヘッダー551は、24ビット長さのフローラベルフィールドを有し、本発明に従うMAL情報は、このフィールドを用いてIPv6ヘッダーに挿入することができる。

0083

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

0084

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

0085

一方、MPEG技術において、メディアの重要度及び優先順位情報を理解し、これを活用してフォーワーディングを実行するネットワークエンティティーをメディア認識ネットワーク要素(Media Aware Network Element:MANE)と呼ぶ。MANEの動作を参照すると、例えば、ルータ、IEEE802シリーズメディアアクセスコントロール(Media Access Control:MAC)、又は3GPPのブロードキャストマルチキャストサービスセンター(Broadcast Multicast Service Center:BMSC)のように受信されたメディアパケットをフォーワーディング(forwarding)するネットワークエンティティーは、MAL情報に含まれるメディア分類子情報に従ってパケットの重要度別に適応的にフォーワーディングすることができるMANEとして動作することができる。例えば、差別化サービス(Differentiated Service:Diffserv)ルーティング方式を使用するルータにおいて、データがバッファ超過する場合に、優先順位が低いパケットから廃棄される。このために、MAL情報のメディア分類子値を確認する。

0086

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

0087

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

0088

図6は、本発明の一実施形態によるMANE600の構成を示す図である。

0089

図6を参照すると、MANE600のフォーワーディングポリシー決定部609が送信側からパケットを受信する場合に(606)、フォーワーディングポリシーに従ってパケットを適応的にフォーワーディングする(610)。フォーワーディングポリシーは、受信されたパケットのMAL情報に含まれるメディア分類子値に従って変わり得る。

0090

MANE600がサービスクラス別QoS方式をサポートする場合に、MANE600は、対応するパケットのメディア分類子のクラスを確認し、それに従って、対応するパケットをフォーワーディングするか否かを決定する。一方、MANE600がフロー別(すなわち、ストリーム別)QoS方式をサポートする場合には、MANE600は、ラベル値を確認し、リソース予約テーブル602に保存されている対応するラベルに割り当てられたリソースを確認し(照会:605、照会結果受信:611)、使用可能なリソース判定部604の使用可能なリソース情報を確認し(照会:608、照会結果受信:607)、使用可能なリソース内でフォーワーディングポリシーを決定し、このパケットをフォーワーディングする(610)。

0091

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

0092

受信装置700は、例えば、ユーザー端末(User Equipment)であり得る。

0093

図7を参照すると、受信装置700は、ストリーム別に復号部704を含み、信号を受信する受信部702及び復号部704を制御する制御部706を含む。復号部704は、必要なだけのバッファ(図示せず)を含み得る。

0094

受信部702から受信されたパケットがラベルを含む場合に、制御部706は、ラベルを確認し、パケットに対応する復号部704を確認する。また、受信部702から受信されたパケットがラベルを含まない場合に、制御部706は、TCP又はUDPヘッダーを読み出し、メディアパケットの復号のための復号部704を確認する。

0095

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

0096

上述した動作を、対応するプログラムコードを記憶するメモリ装置を送信装置300、受信装置700、又はMANE600のようなネットワークエンティティー装置内の任意の構成部に含むことにより実現することができる。すなわち、送信装置300、受信装置700、又はMANE600のようなネットワークエンティティー装置の構成部を、メモリ装置内に記憶されたプログラムコードを読み出し実行するプロセッサ又は中央処理装置(Central Processing Unit:CPU)により実現することができる。

0097

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

0098

110ビデオ符号化階層
111VCLで生成された符号化データ
113パラメータセット及びSEIなど
120ネットワーク抽象化階層
123 VCLNAL単位
125 非VCL NAL単位
130システム情報の送信及び格納
131 H.264/AVCファイルフォーマット
135MPEG−2システム

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

この 技術と関連性が強い技術

関連性が強い 技術一覧

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ