JP2020511015A - Ｖ２ｘ通信装置及びそのマルチメディアコンテンツの送信／受信方法 - Google Patents

Abstract

Ｖ２Ｘ（Vehicle to everything）通信装置のマルチメディアコンテンツメッセージの受信方法を開示する。本発明の実施形態によるＶ２Ｘ通信装置のマルチメディアコンテンツメッセージの受信方法は、マルチメディアコンテンツメッセージを受信する段階と、前記マルチメディアコンテンツメッセージをパージングする段階と、前記マルチメディアコンテンツメッセージに含まれるマルチメディアコンテンツ又はマルチメディアコンテンツの一部であるコンテンツセグメントを取得する段階とを含む。【選択図】図１

Description

本発明は、Ｖ２Ｘ（Vehicle to Everything）通信装置及びそのマルチメディアコンテンツの送受信方法に関し、特に、マルチメディアコンテンツを含むマルチメディアコンテンツメッセージを受信し、メッセージに含まれる情報に基づいてマルチメディアコンテンツを処理する方法に関する。

最近の車両（vehicle）は、機械工学中心から電気、電子、通信技術が融合した複合的な産業技術の結果物となってきており、このような面で車両はスマートカーとも呼ばれる。スマートカーは、運転者、車両、交通インフラなどを連結して、交通安全／複雑解消などの伝統的な意味の車両技術だけでなく、多様なユーザカスタマイズ型の移動サービスを提供するようになった。このような連結性は、Ｖ２Ｘ（Vehicle to Everything）通信技術を用いて実現されることができる。

車両間に安全関連メッセージ以外にもマルチメディアコンテンツの通信が必要となることがある。ただし、車両通信の特性上、マルチメディアコンテンツの送受信は迅速かつ安定的に行われ、過度な通信トラフィックを発生させてはならない。本発明は、車両間のマルチメディアコンテンツ通信のためのメッセージフォーマット及び送受信プロトコルに関して提案する。

前述した技術的課題を解決するために、Ｖ２Ｘ通信装置及びＶ２Ｘ通信装置のマルチメディアコンテンツメッセージ受信方法を開示する。

本発明の実施形態によるマルチメディアコンテンツメッセージの受信方法は、マルチメディアコンテンツメッセージを受信する段階と、前記マルチメディアコンテンツメッセージをパージング（parsing）する段階と、前記マルチメディアコンテンツメッセージに含まれるマルチメディアコンテンツ又はマルチメディアコンテンツの一部であるコンテンツセグメントを取得する段階とを含み、前記マルチメディアコンテンツメッセージは、プロトコルバージョン及びメッセージＩＤを含むヘッダーと、ＭＣＭ（Multimedia Content Message）マネジメント及びＭＣＤ（Multimedia Content Dissemination）プロトコル関連情報を含むマネジメントコンテナと、イベントを記述する情報を含む状況（situation）コンテナと、前記イベントの位置情報を含む位置（location）コンテナと、前記マルチメディアコンテンツを含むマルチメディアコンテンツコンテナとを含み、前記マネジメントコンテナは、前記マルチメディアコンテナに含まれるマルチメディアデータユニットの数を示すマルチメディアデータユニットの数（numberOfMultimediaUnit）情報と、前記マルチメディアコンテナに含まれる前記マルチメディアコンテンツに対するマルチメディアフォーマットタイプ（multimediaFormatType）情報とを含む。

本発明の実施形態によるマルチメディアコンテンツメッセージの受信方法において、前記マネジメントコンテナは、前記マルチメディアコンテンツ又は前記マルチメディアコンテンツのセグメントの少なくとも１つに関するサイズ情報をさらに含み、前記マルチメディアコンテンツメッセージの受信方法は、前記サイズ情報及び前記Ｖ２Ｘ通信装置のストレージ情報に基づいて前記マルチメディアコンテンツ又はコンテンツセグメントを保存するか否か決定する段階をさらに含む。

本発明の実施形態によるマルチメディアコンテンツメッセージの受信方法において、前記マネジメントコンテナは、マルチメディアコンテンツ識別子情報をさらに含み、前記マルチメディアコンテンツメッセージの受信方法は、前記マルチメディアコンテンツ識別子情報に基づいて前記マルチメディアコンテンツメッセージのマルチメディアコンテンツ又はコンテンツセグメントが既に受信したマルチメディアコンテンツと重複しているか否かを決定する段階をさらに含む。

本発明の実施形態によるマルチメディアコンテンツメッセージの受信方法において、前記マネジメントコンテナは、ＵＲＬ情報をさらに含み、前記マルチメディアコンテンツメッセージの受信方法は、前記ＵＲＬ情報が示すＵＲＬに接続して前記マルチメディアコンテンツを受信する段階をさらに含む。

本発明の実施形態によるマルチメディアコンテンツメッセージの受信方法において、前記マネジメントコンテナは、前記マルチメディアコンテンツの言語を示す言語情報をさらに含み、前記マルチメディアコンテンツメッセージの受信方法は、前記言語情報に基づいて前記マルチメディアコンテンツの前記言語が許容可能（acceptable）言語であるか否かを決定する段階をさらに含む。

本発明の実施形態によるマルチメディアコンテンツメッセージの受信方法において、前記マネジメントコンテナは、有効時間情報をさらに含み、前記マルチメディアコンテンツメッセージの受信方法は、前記有効時間情報に基づいて前記マルチメディアコンテンツを提供又はフォワーディングするか否かを決定する段階をさらに含む。

本発明の実施形態によるＶ２Ｘ通信装置は、データを保存するメモリと、無線信号を送受信する通信ユニットと、前記通信ユニットを制御するプロセッサとを含み、前記Ｖ２Ｘ通信装置は、マルチメディアコンテンツメッセージを受信し、前記マルチメディアコンテンツメッセージをパージングし、前記マルチメディアコンテンツメッセージに含まれるマルチメディアコンテンツ又はマルチメディアコンテンツの一部であるコンテンツセグメントを取得し、前記マルチメディアコンテンツメッセージは、プロトコルバージョン及びメッセージＩＤを含むヘッダーと、ＭＣＭ（Multimedia Content Message）マネジメント及びＭＣＤ（Multimedia Content Dissemination）プロトコル関連情報を含むマネジメントコンテナと、イベントを記述する情報を含む状況（situation）コンテナと、前記イベントの位置情報を含む位置（location）コンテナと前記マルチメディアコンテンツを含むマルチメディアコンテンツコンテナとを含み、前記マネジメントコンテナは、前記マルチメディアコンテナに含まれるマルチメディアデータユニットの数を示すマルチメディアデータユニットの数（numberOfMultimediaUnit）情報と前記マルチメディアコンテナに含まれる前記マルチメディアコンテンツに対するマルチメディアフォーマットタイプ（multimediaFormatType）情報とを含む。

本発明のＭＣＤプロトコルは、交通安全（road safety）、トラフィックマネジメント、ＰＯＩ（Point Of Interest）、国家遺産（national patrimony）、コマーシャル（commecial）、個人（personal）などに関する情報をマルチメディアコンテンツとして記述（describe）してＶ２Ｘ通信を可能にする。また、本発明のＭＣＤプロトコルは、マルチメディアコンテンツを複数のセグメントに分離して伝播し、受信端でセグメントを合併してマルチメディアコンテンツを復旧することができる。

サイズ情報を含むＭＣＭを送信することにより、受信機は、ストレージ状態に基づいてマルチメディアコンテンツ／セグメントを伝達するＭＣＭをアプリケーションに伝達するか、又は無視するかを決定することができる。従って、不要な受信プロセシング及びストレージの浪費を防止することができる。

マルチメディアコンテンツ識別情報（ファイル名、ＵＲＩ、ＭＤ５）を含むＭＣＭを送信することにより、受信機は、受信コンテンツが重複したマルチメディアコンテンツであるか否かを把握し、該当コンテンツ／セグメントをアプリケーションに伝達するか、又は無視するかを決定することができる。従って、不要な受信プロセシング及びストレージの浪費を防止することができる。

ＵＲＬ情報を含むＭＣＭを送信することにより、他のアクセスレイヤ又はトランスポートレイヤ技術に基づいてマルチメディアコンテンツを送信することができる。この場合、マルチメディアココンテンツの送信によるＶ２Ｘ通信周波数使用を最小化することができる。

言語情報を含むＭＣＭを送信することにより、受信機は、マルチメディアコンテンツがユーザに許容可能であるか否かを把握し、該当コンテンツ／セグメントをアプリケーションに伝達するか、又は無視するかを決定することができる。従って、不要な受信プロセシング及びストレージの浪費を防止することができる。

有効時間情報を含むＭＣＭを送信することにより、受信機は、マルチメディアコンテンツの有効時間を把握し、該当コンテンツ／セグメントをアプリケーションに伝達するか、無視するか、又はフォワーディングするかを決定することができる。従って、不要な送受信プロセシング、ストレージの浪費、非有効情報の活用を防止することができる。

本発明に関する理解を助けるために含まれ、本出願に含まれてその一部を構成する添付図面は、本発明の原理を説明する詳細な説明と共に本発明の実施形態を示す。
本発明に関する理解を助けるために含まれ、本出願に含まれてその一部を構成する添付図面は、本発明の原理を説明する詳細な説明と共に本発明の実施形態を示す。
本発明の実施形態による高度道路交通システム（Intelligent Transport System：ＩＴＳ ）を示す図である。 本発明の実施形態によるＶ２Ｘ送受信システムを示す図である。 本発明の実施形態によるＶ２Ｘシステムの構成を示す図である。 本発明の実施形態によるネットワーク／トランスポートレイヤのパケット構造を示す図である。 本発明の他の実施形態によるＶ２Ｘシステムの構成を示す図である。 本発明の実施形態によるＷＳＭＰ（WAVE short message protocol）パケット構成を示す図である。 本発明の実施形態によるマルチチャネル運用（Multi-channel Operation：ＭＣＯ）を行うＭＡＣサブレイヤのコンセプト的な（conceptual）内部アーキテクチャを示す図である。 本発明の実施形態によるＥＤＣＡ（Enhanced Dedicated Channel Access）のユーザ優先順位とＡＣ（Access Category）との関係を示す図である。 本発明の実施形態によるＶ２Ｘ送信装置のフィジカルレイヤ構成を示す図である。 本発明の実施形態によるＭＣＭフォーマットを示す図である。 本発明の実施形態によるＩＴＳステーションアーキテクチャであり、特に、ＭＣＤプロトコルによるメッセージプロセシングのためのアーキテクチャを示す図である。 本発明の実施形態によるＭＣＭの送信／受信方法を示す図である。 本発明の実施形態によるＭＣＭの送信／受信方法を示す図である。 本発明の実施形態によるＭＣＭの送信／受信方法を示す図である。 本発明の実施形態によるＭＣＭの送信／受信方法を示す図である。 本発明の実施形態によるＭＣＭのマネジメントコンテナ構成を示す図である。 本発明の実施形態による、サイズ情報を含むＭＣＭの送信／受信方法を示す図である。 本発明の実施形態による、サイズ情報を含むＭＣＭの送信／受信方法を示す図である。 本発明の実施形態による、サイズ情報を含むＭＣＭの送信／受信方法を示す図である。 本発明の実施形態による、サイズ情報を用いたＭＣＤ動作を示す図である。 本発明の実施形態によるＭＣＭのマネジメントコンテナ構成を示す図である。 本発明の実施形態によるＭＣＭの送信／受信方法を示す図である。 本発明の実施形態によるＭＣＭの送信／受信方法を示す図である。 本発明の実施形態によるＭＣＭの送信／受信方法を示す図である。 本発明の実施形態によるマルチメディアコンテンツ識別子情報を用いたＭＣＤ動作を示す図である。 本発明の実施形態によるＭＣＭのマネジメントコンテナ構成を示す図である。 本発明の実施形態によるＭＣＭの送信／受信方法を示す図である。 本発明の実施形態による、ＵＲＬ情報を用いたＭＣＤ動作を示す図である。 本発明の実施形態によるＭＣＭのマネジメントコンテナ構成を示す図である。 本発明の実施形態によるＭＣＭの送信／受信方法を示す図である。 本発明の実施形態によるＭＣＭの送信／受信方法を示す図である。 本発明の実施形態によるＭＣＭの送信／受信方法を示す図である。 本発明の実施形態による、マルチメディア言語情報を用いたＭＣＤ動作を示す図である。 本発明の実施形態によるＭＣＭのマネジメントコンテナ構成を示す図である。 は本発明の実施形態によるＭＣＭのマネジメントコンテナ及びジオネットワーキングベーシックヘッダーを示す図である。 本発明の実施形態による、有効時間情報を用いたＭＣＤ動作を示す図である。 本発明の実施形態によるＶ２Ｘ通信装置を示す図である。 本発明の実施形態によるＶ２Ｘ通信装置のマルチメディアコンテンツメッセージの受信方法を示す図である。

＜発明を実施するための最善の形態＞
本発明の好ましい実施形態について具体的に説明し、その例は添付された図面に示す。添付図面を参照した以下の詳細な説明は、本発明の実施形態によって実現できる実施形態のみ示すよりは本発明の好ましい実施形態を説明するためのものである。次の詳細な説明は本発明に対する徹底した理解を提供するために細部事項を含むが、本発明がこのような細部事項を全て必要とすることではない。本発明は、以下で説明される実施形態はそれぞれ別に用いられるものではない。複数の実施形態又は全ての実施形態が共に用いられることができ、特定実施形態は組み合わせとして用いられることもできる。

本発明で用いられる大部分の用語は当該分野において周知の一般的なものから選択されるが、一部用語は出願人によりランダムに選択され、その意味は必要に応じて次の説明で詳細に記述する。従って、本発明は、用語の単純な名称や意味ではない用語の意図された意味に基づいて理解されるべきである。

本発明は、Ｖ２Ｘ通信装置に関し、Ｖ２Ｘ通信装置は、ＩＴＳ（Intelligent Transport System）システムに含まれ、ＩＴＳシステムの全部又は一部機能を実行することができる。Ｖ２Ｘ通信装置は、車両と車両、車両とインフラ、車両と自転車、モバイル機器などとの通信を行うことができる。Ｖ２Ｘ通信装置はＶ２Ｘ装置ということもできる。実施形態として、Ｖ２Ｘ装置は、車両のオンボードユニット（On Board Unit：ＯＢＵ）に該当するか、ＯＢＵに含まれることもできる。ＯＢＵは、ＯＢＥ（On Board Equipment）ということもできる。Ｖ２Ｘ装置は、インフラストラクチャーのＲＳＵ（Road Side Unit）に該当するか、ＲＳＵに含まれることもできる。ＲＳＵは、ＲＳＥ（RoadSide Equipment）と称することもできる。または、Ｖ２Ｘ通信装置は、ＩＴＳステーションに該当するか、ＩＴＳステーションに含まれることもできる。Ｖ２Ｘ通信を行う任意のＯＢＵ、ＲＳＵ及びモバイル装置などを全てＩＴＳステーション又はＶ２Ｘ通信装置と称することもできる。

図１は、本発明の実施形態による高度道路交通システム（Intelligent Transport System：ＩＴＳ）を示す図である。

高度道路交通システムは、自動車、バス、汽車などの交通手段と信号灯、電光板などの道路周辺に設置された交通施設に電子制御及び通信装置のような情報通信技術（information and communication technology）を適用することにより効率的かつ安全な交通サービスを提供するシステムを意味する。ＩＴＳを支援するために、Ｖ２Ｘ（Vehicle to everything）技術が用いられることができる。Ｖ２Ｘ通信技術は、車両と車両又は車両と周辺機器との通信技術を示す。

Ｖ２Ｘ通信を支援する車両はＯＢＵを装着しており、ＯＢＵはＤＳＲＣ（Dedicated Short-Range Communication：狭域通信）モデムを含む。信号灯のように道路周辺に設置されたＶ２Ｘモジュールを含むインフラストラクチャーは、ＲＳＵと称することができる。ＶＲＵ（Vulnerable Road Users）は、交通弱者であり、歩行者、自転車、車椅子などがＶＲＵに該当する。ＶＲＵは、Ｖ２Ｘ通信が可能であることがある。

Ｖ２Ｖ（Vehicle to Vehicle）は、Ｖ２Ｘ通信装置を含む車両間の通信又は通信技術を示す。Ｖ２Ｉ（Vehicle to Infra-structure）は、Ｖ２Ｘ通信装置を含む車両とインフラストラクチャー間の通信又は通信技術を示す。その他に、車両と交通弱者間の通信はＶ２Ｏと称することができ、インフラストラクチャーと交通弱者間の通信はＩ２Ｏと称することができる。

図２は、本発明の実施形態によるＶ２Ｘ送受信システムを示す。

Ｖ２Ｘ送受信システムは、Ｖ２Ｘ送信機２１００及びＶ２Ｘ受信機２２００から構成され、送信機と受信機はデータを送信及び受信する役割によって区分したものであり、装置の構成の差はない。Ｖ２Ｘ送信機２１００及びＶ２Ｘ受信機２２００は、両方ともＶ２Ｘ通信装置に該当する。

Ｖ２Ｘ送信機２１００は、全地球的航法衛星システム（Global Navigation Satellite System：ＧＮＳＳ）受信機２１１０、ＤＳＲＣラジオ（DSRC Radio）２１２０、ＤＳＲＣデバイスプロセッサ（DSRC device processor）２１３０、アプリケーションＥＣＵ（Electronic Control Unit）２１４０、センサ（Sensor）２１５０、及びヒューマンインタフェース（Human Interface）２１６０を含む。

ＤＳＲＣラジオ２１２０は、ＷＬＡＮ（Wireless Local Area Network）ベースのＩＥＥＥ ８０２．１１標準及び／又は米国自動車技術学会であるＳＡＥ（Society of Automotive Engineer）のＷＡＶＥ（Wireless Access in Vehicular Environments）標準に基づいて通信を行うことができる。ＤＳＲＣラジオ２１２０は、フィジカルレイヤとＭＡＣレイヤの動作を行うことができる。

ＤＳＲＣデバイスプロセッサ２１３０は、ＤＳＲＣラジオ２１２０が受信したメッセージをデコーディングするか、送信するメッセージをデコーディングすることができる。ＧＮＳＳ受信機２１１０はＧＮＳＳを処理し、位置情報及び時間情報を取得することができる。実施形態として、ＧＮＳＳ受信機２１１０は、ＧＰＳ（Global Positioning System）装置となることができる。

アプリケーションＥＣＵ２１４０は、特定アプリケーションサービスを提供するためのマイクロプロセッサになることができる。アプリケーションＥＣＵは、サービスを提供するためにセンサ情報及びユーザ入力に基づいて動作／メッセージを生成し、ＤＳＲＣデバイスプロセッサを用いてメッセージを送受信する。センサ２１５０は、車両状態及び周辺センサ情報を取得することができる。ヒューマンインタフェース２１６０は、入力ボタンやモニタなどのインタフェースを介してユーザの入力を受信するか、メッセージを表示／提供することができる。

Ｖ２Ｘ受信機２２００は、ＧＮＳＳ受信機２２１０、ＤＳＲＣラジオ２２２０、ＤＳＲＣデバイスプロセッサ２２３０、アプリケーションＥＣＵ２２４０、センサ２２５０、及びヒューマンインタフェース２２６０を含む。Ｖ２Ｘ受信機２２００の構成については、前述したＶ２Ｘ送信機２１００の構成に関する説明が適用される。

ＤＳＲＣラジオとＤＳＲＣデバイスプロセッサは、通信ユニットの１つの実施形態に該当する。通信ユニットは、３ＧＰＰ、ＬＴＥ（Long Term Evolution）などのセルラー通信技術に基づいて通信を行うこともできる。

図３は、本発明の実施形態によるＶ２Ｘシステムの構成を示す。

実施形態として、図３のＶ２Ｘシステムは、ＩＳＯ２１２１７／ＥＮ３０２６６５で定義するＩＴＳステーション参照アーキテクチャに該当する。図３は、ＩＴＳステーションが参照アーキテクチャに基づくＩＴＳステーションの例示を示す。図３は、エンドツーエンド通信のための階層的アーキテクチャを示す。車両間にメッセージが通信される場合、送信車両／ＩＴＳシステムで１つのレイヤずつ下へ各レイヤを通過してメッセージが伝達され、受信車両／ＩＴＳシステムで１つのレイヤずつ上へメッセージが上位レイヤに伝達される。各レイヤに関する説明は以下の通りである。

アプリケーションレイヤ：アプリケーションレイヤは、多様なユースケース（use case）を実現及び支援することができる。例えば、アプリケーションは、交通安全（Road Safety）、効率的交通情報（Efficient Traffic Information）、その他のアプリケーション情報（Other application）を提供することができる。

アプリケーションレイヤは、ＩＴＳアプリケーションを分類及び定義し、下位レイヤによりエンド車両／利用者／インフラにサービスを提供することができる。アプリケーションは、ユースケース（use-case）別に定義／適用されることができ、又は、ユースケースを交通安全（road-safety）、トラフィック効率（traffic efficiency）、ローカルサービス、インフォテインメント（infotainment）のようにグルーピングされて定義／適用されることもできる。実施形態として、アプリケーション分類（classification）、ユースケースなどは、新しいアプリケーションシナリオが発生するとアップデートされる。レイヤマネジメントは、アプリケーションレイヤの運営及びセキュリティに関する情報を管理及びサービスすることができる。情報及びサービスは、ＭＡ（interface between management entity and application layer）とＳＡ（interface between security entity and ITS-S applications）又はＳＡＰ（Service Access Point）（例えば、ＭＡ−ＳＡＰ、ＳＡ−ＳＡＰ）を介して双方向に伝達及び共有されることができる。アプリケーションレイヤからファシリティ（facilities）レイヤへの要求又はファシリティレイヤからアプリケーシレイヤへの情報伝達は、ＦＡ（interface between facilities layer and ITS-S applications）又はＦＡ−ＳＡＰを介して行われることができる。

ファシリティ（facilities）レイヤ：ファシリティレイヤは、アプリケーションレイヤで定義された多様なユースケースを効果的に実現できるように支援することができる。例えば、ファシリティレイヤは、アプリケーション支援（application support）、情報支援（information support）、セッション／通信支援（session/communication support）を行うことができる。

ファシリティレイヤは、基本的にＯＳＩモデルの上位３つのレイヤである、セッションレイヤ、プレゼンテーションレイヤ、アプリケーションレイヤ機能を支援することもできる。ファシリティレイヤは、さらにＩＴＳシステムのためにアプリケーション支援、情報支援、セッション／通信支援などの進化したファシリティを提供することができる。ファシリティは、機能（functionality）、情報（information）、データ（data）を提供するコンポーネントを意味する。

ファシリティは、コモンファシリティとドメインファシリティに分類される。コモンファシリティはＩＴＳの基本的なアプリケーションセットとＩＴＳステーション動作に必要なコアサービス又は機能を提供することができる。例えば、時間マネジメント（management）、ポジションマネジメント、サービスマネジメントなどが提供される。ドメインファシリティは、１つ又は複数のＩＴＳの基本的なアプリケーションセットに特別なサービスや機能を提供することができる。例えば、ドメインファシリティは、ＲＨＷ（Road Hazard Warning applications）のためのＤＥＮＭ（DEcentralized Notification Messages）マネジメントを提供することができる。ドメインファシリティは、選択的な（optional）機能であり、ＩＴＳステーションにより支援されないと使用されないこともある。

ネットワーク及びトランスポート（Networking & Transport）レイヤ：ネットワーク／トランスポートレイヤは、多様なトランスポートプロトコル及びネットワークプロトコルを用いることにより同種（homogenous）／異種（heterogenous）ネットワーク間の車両通信のためのネットワークを構成することができる。例えば、ネットワーク／トランスポートレイヤは、ＴＣＰ／ＵＤＰ＋ＩＰｖ６などインターネットプロトコルを用いたインターネット接続とルーティング（routing）を提供することができる。または、ネットワーク／トランスポートレイヤは、ＢＴＰ（Basic Transport Protocol）／ジオネットワーキング（GeoNetworking）など地理的｛ちり てき｝位置情報（Geographical position）ベースプロトコルを用いて車両ネットワークを構成することができる。

トランスポートレイヤは、上位レイヤ（セッションレイヤ、プレゼンテーションレイヤ、アプリケーションレイヤ）と下位レイヤ（ネットワークレイヤ、データリンクレイヤ、フィジカルレイヤ）で提供するサービス間の接続レイヤに該当する。トランスポートレイヤは、ユーザが送信したデータが目的地に正確に到着するように管理する役割を果たす。送信側において、トランスポートレイヤは、効率的なデータ送信のためにデータを送信に適当なサイズのパケットに分割する役割を果たす。受信側において、トランスポートレイヤは、受信したパケットを元のファイルに再結合する役割を果たす。実施形態として、トランスポートプロトコルは、ＴＣＰ／ＵＤＰが用いられることができ、ＶＴＳなどのＩＴＳのためのトランスポートプロトコルが用いられることもできる。

ネットワークレイヤは、論理的なアドレスを割り当ててパケット伝達経路を決定することができる。ネットワークレイヤは、トランスポートレイヤで生成されたパケットを受信し、目的地の論理的なアドレスを含むネットワークヘッダーを付加することができる。パケット経路設計の例として、車両間、車両と固定ステーション間、固定ステーション間のユニキャスト／ブロードキャストが考慮されることができる。実施形態として、ＩＴＳのためのネットワークプロトコルとして、ジオネットワーキング（Geo-Networking）、移動性支援を有する（with movility support）ＩＰｖ６ネットワーキング、ＩＰｖ６ ｏｖｅｒ ジオネットワーキングなどのプロトコルが考慮されることができる。

アクセス（Access）レイヤ：アクセスレイヤは、上位レイヤから受信したメッセージ／データを物理的チャネルで送信することができる。例えば、アクセスレイヤは、ＩＥＥＥ ８０２．１１及び／又は８０２．１１ｐ標準ベースの通信技術、ＩＥＥＥ ８０２．１１及び／又は８０２．１１ｐ標準のフィジカル送信技術ベースのＩＴＳ−Ｇ５無線通信技術、衛星／広帯域無線移動通信を含む２Ｇ／３Ｇ／４Ｇ（ＬＴＥ）／５Ｇ無線セルラー通信技術、ＤＶＢ−Ｔ／Ｔ２／ＡＴＳＣなど広域地上波デジタル放送技術、ＧＰＳ技術、ＩＥＥＥ １６０９ ＷＡＶＥ技術などに基づいてデータ通信を実行／支援することができる。

車両通信及びネットワーキングのためのＩＴＳシステムは、多様なユースケース（use-case）の提供のために多様な接続技術、ネットワークプロトコル、通信インタフェースを考慮して有機的に設計できる。また、各レイヤの役割及び機能は増強又は補強されることもできる。

図４は、本発明の実施形態によるネットワーク／トランスポートレイヤのパケット構造を示す図である。

図４は、ネットワーク／トランスポートレイヤのパケット構造を示し、トランスポートレイヤはＢＴＰパケットを生成し、ネットワークレイヤはジオネットワーキングパケットを生成することができる。ジオネットワーキングパケットは、ＬＬＣ（logical link control）パケットのデータに該当し、ＬＬＣパケットに含まれることができる。ジオネットワーキングパケットは、ＬＬＣパケットにカプセル化（encapsulation）されることができる。図４の実施形態において、データはメッセージセットを含み、メッセージセットはベーシックセーフティメッセージになることができる。

ＢＴＰは、ファシリティレイヤで生成したＣＡＭ、ＤＥＮＭなどのメッセージを下位（lower）レイヤに送信するためのプロトコルである。ＢＴＰヘッダーは、Ａタイプ、Ｂタイプで構成される。ＡタイプのＢＴＰヘッダーは、インタラクティブ（interactive）パケット送信のために送受信に必要な、目的地／デスティネーション（destination）ポート及びソースポートを含むことができる。Ｂタイプのヘッダーは、非インタラクティブ（non-interactive）パケット送信のために送信に必要な、デスティネーションポート及びデスティネーションポート情報を含むことができる。ヘッダーに含まれるフィールド／情報に関する説明は以下の通りである。

デスティネーションポート（Destination Port）：デスティネーションポートは、ＢＴＰパケットに含まれるデータ（ＢＴＰ−ＰＤＵ）の目的地に該当するファシリティエンティティを識別する。

ソースポート（Source Port）：ＢＴＰ−Ａタイプの場合に生成されるフィールドであり、該当パケットが送信されるソースでのファシリティレイヤのプロトコルエンティティのポートを示す。このフィールドは、１６ビットのサイズを有する。

デスティネーションポート情報（Destination Port Info）：ＢＴＰ−Ｂタイプの場合に生成されるフィールドであり、デスティネーションポートが最も周知のポートである場合、追加情報を提供することができる。このフィールドは、１６ビットのサイズを有する。

ジオネットワーキングパケット（Geonetworking packet）は、ネットワークレイヤのプロトコルによってベーシックヘッダー及びコモンヘッダーを含み、ジオネットワーキングモードによってエクステンション（Extension）ヘッダーを選択的に（optional）含む。

ベーシックヘッダーは、３２ビット（４バイト）になることができる。ベーシックヘッダーは、バージョンフィールド、ＮＨ（Next Header）フィールド、ＬＴ（LifeTime）フィールド、ＲＨＬ（Remaining Hop Limit）フィールドの少なくとも１つを含むことができる。ベーシックヘッダーに含まれるフィールドに関する説明は以下の通りである。各フィールドを構成するビットサイズは実施形態にすぎないものであり、変更されることもできる。

Ｖｅｒｓｉｏｎ（４ビット）：バージョン（version）フィールドはジオネットワーキングプロトコルのバージョンを示す。

ＮＨ（４ビット）：ＮＨ（Next Header）フィールドは、後続ヘッダー／フィールドのタイプを示す。フィールド値が１であると、コモンヘッダーが後続し、２であるとセキュリティ設定されたセキュリティ（secured）パケットが後続することができる。

ＬＴ（８ビット）：ＬＴ（LifeTime）フィールドは、該当パケットの最大生存時間を示す。

ＲＨＬ（８ビット）：ＲＨＬ（Remaining Hop Limit）フィールドは、残余ホップ制限を示す。ＲＨＬフィールド値は、ジオアドホック（GeoAdhoc）ルータでフォワーディングする度に１ずつ減少することができる。ＲＨＬフィールド値が０になると、該当パケットはこれ以上フォワーディングされない。

コモンヘッダーは、６４ビット（８バイト）になることができる。コモンヘッダーは、ＮＨ（Next Header）フィールド、ＨＴ（Header Type）フィールド、ＨＳＴ（Header Sub-Type）フィールド、ＴＣ（Traffic Class）フィールド、フラグ（Flags）フィールド、ＰＬ（Payload Length）フィールド、ＭＨＬ（Maximum Hop Limit）フィールドの少なくとも１つを含むことができる。各フィールドに関する説明は以下の通りである。

ＮＨ（４ビット）：ＮＨ（Next Header）フィールドは、後続ヘッダー／フィールドのタイプを示す。フィールド値が０であると、定義されない「ＡＮＹ」タイプを示し、１であると、ＢＴＰ−Ａタイプパケットを、２であると、ＢＴＰ−Ｂタイプパケットを、３であると、ＩＰｖ６のＩＰダイアグラムをそれぞれ示すことができる。

ＨＴ（４ビット）：ヘッダータイプフィールドは、ジオネットワーキングタイプを示す。ジオネットワーキングタイプはビーコン（Beacon）、ジオユニキャスト（GeoUnicast）、ジオエニーキャスト（GeoAnycast）、ジオブロードキャスト（GeoBroadcast）、ＴＳＢ（Topologically-Scoped Broadcast）、ＬＳ（Location Service）を含む。

ＨＳＴ（４ビット）：ヘッダーサブタイプフィールドは、ヘッダータイプと共に詳細なタイプを示す。実施形態として、ＨＴタイプがＴＳＢに設定されると、ＨＳＴ値が「０」である場合はシングルホップを示し、「１」である場合はマルチホップを示すことができる。

ＴＣ（８ビット）：トラフィッククラスフィールドは、ＳＣＦ（Store-Carry-Forward）、チャネルオフロード（Channel Offload）、及びＴＣ ＩＤを含むことができる。ＳＣＦフィールドは、パケットを伝達する隣がない場合、パケットを保存するか否かを示す。チャネルオフロードフィールドは、マルチャネルオペレーションの場合は他のチャネルにパケットが伝達できることを示す。ＴＣ ＩＤフィールドは、ファシリティレイヤでパケット伝達時に割り当てられる値であり、フィジカルレイヤでコンテンション（contention）ウィンドウ値の設定に用いられる。

フラグ（８ビット）：フラグフィールドは、ＩＴＳ装置が移動型（mobile）であるか固定型（stationary）であるかを示し、実施形態として、最後の１ビットになる。

ＰＬ（８ビット）：ペイロード長さフィールドはジオネットワーキングヘッダーに後続するデータ長さをバイト単位で示す。例えば、ＣＡＭを運搬（carry）するジオネットワーキングパケットの場合、ＰＬフィールドはＢＴＰヘッダーとＣＡＭの長さを示すことができる。

ＭＨＬ（８ビット）：ＭＨＬ（Maximum Hop Limit）フィールドは最大ホッピング数を示すことができる。

ジオネットワーキングパケットにＬＬＣヘッダーが加えられてＬＬＣパケットが生成される。ＬＬＣヘッダーは、ＩＰデータとジオネットワーキングデータを区別して送信する機能を提供する。ＩＰデータとジオネットワーキングデータは、ＳＮＡＰのイーサタイプ（Ethertype）により区別されることができる。実施形態として、ＩＰデータが送信される場合、イーサタイプは０×８６ＤＤに設定されてＬＬＣヘッダーに含まれることができる。実施形態として、ジオネットワーキングデータが送信される場合、イーサタイプは０×８６ＤＣに設定されてＬＬＣヘッダーに含まれることができる。受信機はＬＬＣパケットヘッダーのイーサタイプフィールドを確認し、その値によってパケットをＩＰデータ経路又はジオネットワーキング経路にフォワーディング及び処理することができる。

図５は、本発明の他の実施形態によるＶ２Ｘシステムの構成を示す。

図５は、図３のＶ２Ｘシステムの他の実施形態に該当する階層アーキテクチャを示す。実施形態として、北米Ｖ２Ｘシステムは、ＩＥＥＥ ８０２．１１のＰＨＹ技術とＭＡＣ技術とを用い、さらにＩＥＥＥ １６０９．４のＭＡＣ技術を用いることができる。ネットワーク／トランスポートレイヤ技術において、ＬＬＣブロックにはＩＥＥＥ ８０２．２標準の技術が適用され、ＷＳＭＰ（WAVE short message protocol）にはＩＥＥＥ １６０９．３技術が適用される。ファシリティレイヤは、ＳＡＥのＪ２７３５標準のメッセージセットを用いることができ、アプリケーションレイヤは、Ｊ２９４５標準でＶ２Ｖ、Ｖ２Ｉ、Ｖ２Ｏ用に定義されたアプリケーションを用いることができる。

アプリケーションレイヤは、ユースケースを実現して支援する機能を実行することができる。アプリケーションは、ユースケースによって選択的に用いられる。各ユースケースのシステム要求（requirement）は、Ｊ２９４５標準で定義されることができる。Ｊ２９４５／１は、Ｖ２Ｖ安全通信のようなＶ２Ｖ技術のアプリケーションを定義する。

Ｊ２９４５／１文書は、ＥＥＢＬ（emergency electronic brake lights）、ＦＣＷ（forward crash warning）、ＢＳＷ（blind spot warning）、ＬＣＷ（lane change warning）、ＩＭＡ（intersection movement assist）、ＣＬＷ（control loss warning）などのアプリケーションを定義する。実施形態として、ＦＣＷ技術は、先行車両との衝突を警告するＶ２Ｖ安全通信技術である。Ｖ２Ｘ通信装置を備えた車両が急停車をしたり、事故で止まったりする場合、後続車両の衝突を防止するためにＦＣＷ安全メッセージを送信することができる。後続車両は、ＦＣＷメッセージを受信して運転者に警告をしたり、速度減速又は車線変更などの制御を行うことができる。特に、停車した車両と運転車両との間に他の車両がある場合も、ＦＣＷにより停車した車両の状態を把握することができるという利点がある。ＦＣＷ安全メッセージは、車両の位置情報（緯度、経度、車線）、車両情報（車両種類、長さ、方向、速度）、イベント情報（停止、急停止、徐行）を含むことができ、このような情報は、ファシリティレイヤの要求に応じて生成される。

ファシリティレイヤは、ＯＳＩレイヤ５（セッションレイヤ）、レイヤ６（プレゼンテーションレイヤ）、レイヤ７（アプリケーションレイヤ）に該当する。ファシリティレイヤは、アプリケーションを支援するために状況に応じたメッセージセットを生成することができる。メッセージセットは、Ｊ２７３５標準で定義され、ＡＳＮ．１（Abstract Syntax Notation 1）を通じて記述／復号されることができる。メッセージセットは、ＢａｓｉｃＳａｆｅｔｙＭｅｓｓａｇｅメッセージ、ＭａｐＤａｔａメッセージ、ＳＰＡＴメッセージ、ＣｏｍｍｏｎＳａｆｅｔｙＲｅｑｕｅｓｔメッセージ、ＥｍｅｒｇｅｎｃｙＶｅｈｉｃｌｅＡｌｅｒｔメッセージ、ＩｎｔｅｒｓｅｃｔｉｏｎＣｏｌｌｉｓｉｏｎメッセージ、ＰｒｏｂｅＶｅｈｉｃｌｅＤａｔａメッセージ、ＲｏａｄＳｉｄｅＡｌｅｒｔメッセージ、ＰｅｒｓｏｎａｌＳａｆｅｔｙＭｅｓｓａｇメッセージを含む。

ファシリティレイヤは、上位レイヤで送信する情報を集合してメッセージセットを生成することができる。メッセージセットは、ＡＳＮ．１方式で表示される。ＡＳＮ．１は、データ構造を記述するのに用いる表記法であり、エンコーディング／デコーディング規則も定めることができる。ＡＳＮ．１は、特定装置、データ表現方式、プログラミング言語、ハードウェアプラットフォームなどに従属しない。ＡＳＮ．１は、プラットフォームに関係なくデータを記述する言語であり、ＣＣＩＴＴ（Consultative Committee on International Telegraphy and Telephony, X.208）とＩＳＯ（international Organization for Standardization, ISO 8824）の共同標準である。

メッセージセットは、Ｖ２Ｘ動作に関するメッセージの集まりであり、上位アプリケーションの状況に合うメッセージセットが存在する。メッセージセットはデータフレームの形式で表現され、少なくとも１つのエレメントを含むことができる。各エレメントは、データフレーム又はデータエレメントを含むことができる。

データフレームは、２つ以上のデータ羅列を表示する。データフレームは、データエレメントの羅列構造又はデータフレームの羅列構造になる。実施形態として、ＤＶ＿ｖｅｈｉｃｌｅＤａｔａは、自動車の情報を示すデータフレーム構造であり、複数のデータエレメント（例えば、Ｈｅｉｇｈｔ、 Ｎｕｍｂｅｒｓ、ｍａｓｓ、ｔｒａｉｌｅｒｗｅｉｇｈｔ）を含むことができる。データエレメントは、データ要素に関する説明を定義する。実施形態として、データフレームで用いるＨｅｉｇｈｔというエレメントは、ＤＥ＿ＶｅｈｉｃｌｅＨｅｉｇｈｔに定義され、車両の高さを表現することができる。実施形態として、車両の高さは０〜１２７まで表現され、ＬＢＳ単位は５ｃｍ単位で増加し、最大６．３５メートルまで表現される。

実施形態として、ベーシック安全メッセージ（BasicSafetyMessage）が送信されることができる。ＢａｓｉｃＳａｆｅｔｙＭｅｓｓａｇｅは、メッセージセットのうち最も基本的で重要なメッセージであり、車両の基本情報を周期的に送信するのに用いられる。該当メッセージは、ＢＳＭｃｏｒｅＤａｔａと定義されたｃｏｒｅＤａｔａと選択的（Optional）であるＰａｒｔＩＩとｒｅｇｉｏｎａｌデータを含むことができる。ｃｏｒｅＤａｔａは、ｍｓｇＣｎｔ、ｉｄ、ｌａｔ、ｌｏｎｇ、ｅｌｅｖ、ｓｐｅｅｄ、ｄｅａｄｉｎｇ、ｂｒｅａｋ、ｓｉｚｅなどのデータエレメントを含むことができる。ｃｏｒｅＤａｔａは、データエレメントを用いることにより、メッセージカウント、ＩＤ、緯度、経度、高度、速度、方向、ブレーキ、車両サイズなどを表示する。該当ＢＳＭは、ｃｏｒｅＤａｔａに該当する情報を一般的に１００ｍｓｅｃ（１秒に１０回）周期で送信することができる。

ネットワーク／トランスポートレイヤは、ＯＳＩレイヤ３（ネットワークレイヤ）、レイヤ４（トランスポートレイヤ）に該当する。上位レイヤで伝達されるＷＳＭ（WAVE Short Message）を送信するためにＷＳＭＰ（WAVE short message protocol）が用いられる。さらに、従来のＩＰ信号を処理するためにＩＰｖ６／ＴＣＰプロトコルが用いられる。ＬＬＣブロックは、ＩＥＥＥ ８０２．２標準が用いられ、ＩＰダイアグラムとＷＳＭパケットを区別することができる。

アクセスレイヤは、ＯＳＩレイヤ１（フィジカルレイヤ）、レイヤ２（データリンクレイヤ）に該当する。アクセスレイヤは、ＩＥＥＥ ８０２．１１のＰＨＹ技術とＭＡＣ技術を用いることができ、さらに、車両通信を支援するためにＩＥＥＥ １６０９．４のＭＡＣ技術を用いることができる。

セキュリティエンティティ（security entity）とマネジメントエンティティは、全区間で連結されて動作することができる。

図６は、本発明の実施形態によるＷＳＭＰパケット構成を示す。

図５のネットワーク／トランスポートレイヤは、ＢＳＭなどの車両安全メッセージをＷＳＭＰを通じて送信することができる。ＷＳＭＰプロトコルは、ＩＥＥＥ １６０９．３文書に記述され、さらにＩＰデータを送信するためにＩＰｖ６とＴＣＰ／ＵＤＰも支援されることができる。

ＷＳＭＰは、ファシリティレイヤでＡＳＮ．１方式で生成したＷＡＶＥショートメッセージを下位レイヤに伝達するためのプロトコルである。図６に示すように、ＷＳＭＰパケットは、ＷＳＭＰヘッダーとメッセージを含むＷＳＭデータを含む。ＷＳＭＰヘッダーは、バージョン（version）フィールド、ＰＳＩＤフィールド、エクステンションフィールド（extension field）、ＷＳＭ ＷＡＶＥエレメントＩＤフィールド、及び長さ（length）フィールドを含む。

バージョンフィールドは、４ビットの実際のＷＳＭＰバージョンを示すＷＳＭＰＶｅｒｓｉｏｎフィールドと４ビットのｒｅｓｅｒｖｅｄフィールドに定義されることができる。ＰＳＩＤフィールドは、プロバイダサービス識別子（provider service identifier）として、上位レイヤでアプリケーションによって割り当てられることができる。ＰＳＩＤフィールドは、受信機側で適切な上位レイヤを決定するのに役立てる。エクステンションフィールドは、ＷＳＭＰヘッダーを拡張するためのフィールドであり、チャネルナンバー（channel number）、データレート（data-rate）、使用送信電力（transmit power used）などの情報が挿入される。ＷＳＭＰ ＷＡＶＥエレメントＩＤフィールドは、送信されるＷＡＶＥショートメッセージのタイプを指定することができる。長さフィールドは、１２ビットのＷＳＭＬｅｍｇｔｈフィールドを通じて送信されるＷＳＭデータの長さをオクテット（octets）単位で指定することができる。

ＬＬＣヘッダーは、ＩＰデータとＷＳＭＰデータを区別して送信する機能を提供する。ＩＰデータとＷＳＭＰデータは、ＳＮＡＰのイーサタイプ（Ethertype）により区別されることができる。実施形態として、ＬＬＣヘッダーとＳＮＡＰヘッダー構造は、ＩＥＥＥ ８０２．２の文書で定義されることができる。ＩＰデータが送信される場合、イーサタイプは０×８６ＤＤに設定されてＬＬＣヘッダーに含まれることができる。実施形態として、ＷＳＭＰデータが送信される場合、イーサタイプは０×８６ＤＣに設定されてＬＬＣヘッダーに含まれることができる。受信機は、ＬＬＣパケットヘッダーのイーサタイプフィールドを確認し、その値によってパケットをＩＰデータ経路又はＷＳＭＰ経路にフォワーディング及び処理することができる。

図７は、本発明の実施形態によるマルチチャネル運用（Multi-channel Operation：ＭＣＯ）を行うＭＡＣサブレイヤのコンセプト的な（conceptual）内部アーキテクチャを示す。

実施形態として、図７のアーキテクチャは、図５のアクセスレイヤに含まれるか、アクセスレイヤのＭＡＣレイヤに含まれることができる。図７のＭＣＯ構造は、チャネルアクセスが定義されるチャネルコーディネーション、ＰＨＹ−ＭＡＣレイヤ間の全般的なデータ及びマネジメントフレームの動作過程を定義するチャネルルーティング、送信フレームの優先順位（priority）を決定及び定義するＥＤＣＡ（Enhanced Dedicated Channel Access）、上位レイヤから受信したフレームを貯蔵するデータバッファ（又はキュー(queue)）を含むことができる。チャネルコーディネーションブロックは図７では示されず、チャネルコーディネーションは図５のＭＡＣサブレイヤ全体により行われることもできる。

チャネルコーディネーション：実施形態としてＣＣＨ（Control Channel）とＳＣＨ（Service Channel）に対するチャネルアクセスがコントロールされることができる。チャネルアクセスコーディネーションについては後述する。実施形態として、ＣＣＨを介してはＷＳＭ（WAVE Short Message）及び が送信されることができ、ＳＣＨを介しては、ＷＳＭ及び／又はＩＰデータが送信されることができる。

データバッファ（キュー）：データバッファは、上位レイヤから受信されるデータフレームを定義されたＡＣ（Access Category）によって保存することができる。図３の実施形態において、ＡＣ別にデータバッファが備えられることができる。

チャネルルーティング（Channel routing）：チャネルルーティングブロックは、上位レイヤから入力されるデータをデータバッファに伝達することができる。上位レイヤの送信要求に対して前述したチャネルコーディネーション（Channel Coordination）及びフレーム送信のためのチャネルナンバー、送信電力及びデータレートなどの送信動作パラメータを呼び出すことができる。

ＥＤＣＡ：既存のＩＥＥＥ ８０２．１１ｅＭＡＣレイヤでＱｏＳを保証するための方式であり、トラフィックの種類によって４つのＡＣ（Access Category）に区分して各カテゴリー毎に差別化された優先順位を付け、ＡＣ別に差別化されたパラメータを割り当てて、高い優先順位のトラフィックにはより多くの送信機会を与えるようにする競争（contention）ベースのミディアムアクセス方式である。優先順位を含むデータ送信のためにＥＤＣＡブロックは、０〜７まで８つの優先順位を指定し、優先順位に従ってＭＡＣレイヤに到着するデータを４つのＡＣにマッピングすることができる。

図８は、本発明の実施形態によるＥＤＣＡのユーザ優先順位とＡＣ（Access Category）の関係を示す。

ＥＤＣＡのユーザ優先順位とＡＣの関係は図８の通りである。図において順位は、ＡＣの数字が大きくなるほど優先順位が高くなる。全てのＡＣは、それぞれの送信キューとＡＣパラメータを有し、ＡＣ間の優先順位の差は、相異なるように設定されたＡＣパラメータ値に基づいて決定される。相異なるように設定されたＡＣパラメータ値がバックオフ（Back-off）に接続されて相異なるチャネル接近順位を有するようになる。該当ＡＣのパラメータ値は、それぞれＡＩＦＳ［ＡＣ］、ＣＷｍｉｎ［ＡＣ］、ＣＷｍａｘ［ＡＣ］を用い、ここで、ＡＩＦＳ（Arbitration Inter-Frame Space）は、送信を進行する前にチャネルがアイドル（idle）であるか否かを確認するための最小時間をいう。ＡＩＦＳ［ＡＣ］とＣＷｍｉｎ［ＡＣ］の値が小さいほど高い優先順位を有し、これにより、チャネル接近遅延が短くなって、与えられたトラフィック環境でより多くの帯域を使用できるようになる。

フレーム送信中にステーション間の衝突が発生した場合、送信機は、新しいバックオフカウンタを生成する。ＩＥＥＥ ８０２．１１ ＭＡＣに定義された４つのＡＣ別の送信キューは、１つのステーション内で無線｛むせん｝メディアアクセスのために個別に互いに競争する。それぞれのＡＣは、互いに独立したバックオフカウンタを有しているので、仮想衝突（virtual collision）が発生することがある。もし、同時にバックオフを終えたＡＣが２つ以上存在する場合は最も高い優先順位のＡＣのデータがまず送信され、他のＡＣはＣＷ値を増加させて再びバックオフカウンタを更新する。このような衝突解決過程を仮想衝突処理過程という。また、ＥＤＣＡは、送信機会（Transmission Opportunity：ＴＸＯＰ）を通じてデータ送信時にチャネルに接続できるようにする。もし、１つのフレームが長すぎて一回のＴＸＯＰ中に送信できない場合、小さいフレームに分割して送信することもできる。

図９は、本発明の実施形態によるＶ２Ｘ送信装置のフィジカルレイヤ構成を示す。

実施形態として、図９は、ＩＥＥＥ ８０２．１１又はＩＴＳ−Ｇ５のフィジカルレイヤ信号処理ブロック図を示す。ただし、図９は、本発明の実施形態によるフィジカルレイヤ構成を示し、前述した送信標準技術に限定的に適用されるものではない。

図９のフィジカルレイヤプロセッサは、スクランブラ（scrambler）９０１０、ＦＥＣエンコーダ（FEC encoder）９０２０、インターリーバ（interleaver）９０３０、マッパー（mapper）９０４０、パイロット挿入ブロック（pilot insertion）９０５０、ＩＦＦＴブロック（IFFT）９０６０、ガード挿入ブロック（guard insertion）９０７０、プリアンブル挿入ブロック（preamble insertion）９０８０の少なくとも１つを含むＰＬＣＰ（Physical Layer Convergence Protocol）サブレイヤベースバンド（baseband）信号処理部分及び波形整形（WAVE shaping）ブロック９０９０、Ｉ／Ｑ変調ブロック（I/Q Modulation）９１００）及びＤＡＣ９１１０の少なくとも１つを含むＰＭＤ（Physical Medimu Dependant）サブレイヤＲＦ帯域信号処理部分を含むことができる。各ブロックに関する機能説明は次の通りである。

スクランブラ９０１０は、入力ビットストリームをＰＲＢＳ（Pseudo Random Binary Sequence）にＸＯＲ(exclusive OR：排他的論理和)させてランダム化（randomize）することができる。ＦＥＣエンコーダ９０２０は、送信チャネル上のエラーを受信側で訂正できるように送信データにリダンダンシーを付加することができる。インターリーバ９０３０は、バースト（burst）エラーに対応できるように入力データ／ビットストリームをインターリービングルールに基づいてインターリーブすることができる。実施形態として、ＱＡＭシンボルにディープフェージング（deep fading）又は削除（erasure）が加えられた場合、各ＱＡＭシンボルにはインターリーブされたビットがマッピングされているので、コードワードビット全体の中で連続したビットにエラーが発生することを防止することができる。マッパー９０４０は、入力されたビットワードを１つのコンスタレーション（constellation）に割り当てることができる。パイロット挿入ブロック９０５０は、信号ブロックの決められた位置にレファレンス信号を挿入する。このようなレファレンス信号を用いることにより、受信機はチャネル推定、周波数オフセット及びタイミングオフセットなどチャネル歪み現象を推定することができる。

ＩＦＦＴブロック９０６０、すなわち、インバースウェーブフォームトランスフォーム （Inverse waveform transform）ブロックは、送信チャネルの特性とシステム構造を考慮して送信効率及び柔軟性（flexibility）が向上するように入力信号を変換することができる。実施形態として、ＯＦＤＭシステムの場合、ＩＦＦＴブロック９０６０は、インバースＦＦＴオペレーションを用いて周波数領域の信号を時間領域に変換することができる。ＩＦＦＴブロック９０６０は、シングルキャリアシステムの場合は使用されないか、省略されることもできる。ガード挿入ブロック９０７０は、送信チャネルの遅延拡散（delay spread）の影響を最小化するために隣接信号ブロック間にガードインターバルを挿入することができる。実施形態として、ＯＦＤＭシステムの場合、ガード挿入ブロック９０７０は、ガードインターバル区間にサイクリックプレフィックス（cyclic prefix）を挿入することができる。プリアンブル挿入ブロック９０８０は、受信機がターゲット信号を速く効率的に検出（detection）できるように送受信期間が既に決定されているタイプの信号、すなわち、プリアンブルを送信信号に挿入することができる。実施形態として、ＯＦＤＭシステムの場合、プリアンブル挿入ブロック９０８０は、複数のＯＦＤＭシンボルを含む信号ブロック／信号フレームを定義し、信号ブロック／信号フレームの開始部分にプリアンブルシンボルを挿入することができる。

波形整形ブロック９０９０は、チャネル送信特性に基づいて入力ベースバンド信号をウェーブフォームプロセシングすることができる。実施形態として、波形整形ブロック９０９０は、送信信号の帯域外（out-of-band）エミッション（emission）の基準を得るためにＳＲＲＣ（square-root-raised cosine）フィルタリングを行うこともできる。マルチキャリアシステムの場合、波形整形ブロック９０９０は使用されないか、省略されることもできる。Ｉ／Ｑモジュレータ９１００は、同相（In-phase）及び直交（Quadrature）変調を行うことができる。ＤＡＣ（Digigal to Analog Converter）９１１０ブロックは、入力デジタル信号をアナログ信号に変換して出力することができる。出力アナログ信号は、出力アンテナを介して送信されることができる。

図９に示されて説明されたブロックのそれぞれは省略されるか、又は類似するか同一の機能を有する他のブロックにより代替されることもできる。図９のブロックは、必要に応じて全部又は一部の組み合わせで構成されることもできる。本発明において、Ｖ２Ｘ通信装置は、図７ないし図９で説明したＤＳＲＣ技術及びＷＡＶＥ技術に基づいて通信を行うことができる。ただし、Ｖ２Ｘ通信装置は、ＬＴＥ、ＬＴＥ−Ａ、５Ｇなどのセルラー技術を含む他の通信技術に基づいて通信を行うこともできる。

以下ではＭＣＤ（Multimedia Content Dissemination）サービスについて説明する。

ＭＣＤベーシックサービスは、交通安全（road safety）、トラフィックマネジメント、ＰＯＩ（Point Of Interest）、国家遺産（national patrimony）、コマーシャル（commecial）、個人（personal）などに関する情報をマルチメディアコンテンツとして記述（describe）するＶ２Ｘ技術である。車両ＩＴＳステーション（Vehicle ITS-S）又は路辺／ロードサイドＩＴＳステーション（Roadside ITS-S）が他の車両ＩＴＳステーション又はロードサイドＩＴＳステーションにＭＣＭ（Multimedia Content Message）を送信することができる。ＩＴＳステーションは、ＭＣＭをブロードキャスト、地理的（geographical）ブロードキャスト、マルチキャスト又はピアツーピア（peer-to-peer）方式で送信することができる。ＭＣＭを送信する一連の過程及び規則をＭＣＤプロトコルと称することができる。

図１０は、本発明の実施形態によるＭＣＭフォーマットを示す。

ＭＣＭは、特定イベントをマルチメディアコンテンツとして記述するためのメッセージである。ＭＣＭは、ＩＴＳ ＰＤＵヘッダー、マネジメントコンテナ（Management Container）、状況／シチュエーションコンテナ（Situation Container）、位置／ロケーションコンテナ（Location Container）、アプリケーションコンテナ（APPIL Container）、及びマルチメディアコンテンツコンテナ（Multimedia Content Container）を含む。

ＩＴＳ ＰＤＵヘッダーは、プロトコルバージョン情報、メッセージタイプ情報及びＩＴＳステーションＩＤ情報のうち少なくとも１つを含む。マネジメントコンテナは、ＭＣＭのマネジメントとＭＣＤプロトコルに関する情報を含む。状況コンテナは、ＭＣＤのトリガリング（triggering）ソースに関する情報を含む。状況コンテナは、イベントの種類、イベントのタイプに関する情報を提供することができる。位置コンテナは、イベントの発生位置に関する情報を提供することができる。アプリケーションコンテナは、ＭＣＭを用いるアプリケーションのアプリケーション特定情報を提供することができる。マルチメディアコンテンツコンテナは、マルチメディアコンテンツ自体を包含又は提供することができる。

マネジメントコンテナは、ＭＣＭを送信するタイム情報、メッセージＩＤ、リンク可能な特定ＤＥＮ（DEcentralized Nocification）メッセージのＩＤ、マルチメディアコンテンツのファイルフォーマット情報のうち少なくとも１つを含むことができる。

ＭＣＭのサイズが大きすぎる場合、ＩＴＳステーションは保存空間が不足してメッセージを受信又は処理できないこともある。また、１つのマルチメディアコンテンツを構成するＭＣＭを全て受信することができないと、該当マルチメディアコンテンツがレンダリングできないこともある。現在のＭＣＤプロトコルではコンテンツのサイズが分からないため、受信機が保存空間の不足によりＭＣＭを全部受信することができない場合、又は、不要ながら受信を行う場合が発生することがある。

また、ＩＴＳステーションが特定マルチメディアコンテンツを有しているが、同一マルチメディアコンテンツが他のＩＴＳステーションにより送信されることがある。このような場合も、ＩＴＳステーションは送信中のマルチメディアコンテンツと現在有しているマルチメディアコンテンツが同一コンテンツであることを確認することができないため、同一マルチメディアコンテンツを重複して受信することがある。

また、マルチメディアコンテンツがＩＴＳステーション間の通信より他の経路（例えば、ブロードバンド）を介した受信にさらに適合することもある。

さらに、特定マルチメディアコンテンツは特定言語に最適化したコンテンツであるが、マルチメディアコンテンツを一応受信してレンダリングをしてこそ、不適合な言語が適用されたコンテンツであることを把握できる場合が発生することがある。

従って、以下では、前述した問題を解決できるＭＣＭ構造及びＭＣＤプロトコルについて説明する。

図１１は、本発明の実施形態によるＩＴＳステーションアーキテクチャであり、特に、ＭＣＤプロトコルによるメッセージプロセシングのためのアーキテクチャを示す。

ＭＣＤアプリケーション（MCD application）は、多様な目的のためにマルチメディアを用いることによりイベントを記述（describe）するアプリケーションである。多様な目的は、例えば、交通安全、トラフィックマネジメント、ドライバー支援、旅行情報の提供、商業情報の提供、個人／コミュニティ情報の提供などがある。

ＭＣＤベーシックサービス（MCD Basic Service）：送信ＩＴＳ−Ｓにおいて、ファシリティレイヤは、アプリケーションレイヤからマルチメディアコンテンツ及び他のイベント説明／デスクリプション（description）を受信し、受信ＩＴＳ−Ｓに送信されるように受信したコンテンツ及びデスクリプションをネットワーク／トランスポートレイヤに伝達する。ファシリティレイヤは、受信したマルチメディアコンテンツ及びデスクリプションをＭＣＭの形態（form）で伝達することができる。ファシリティレイヤはマルチメディアコンテンツを複数の（multiple）セグメントに分割し、複数のＭＣＭをネットワーク／トランスポートレイヤに伝達することができる。このようなＭＣＤプロトコルによって動作するエンティティをＭＣＤベーシックサービスエンティティと称することができる。

受信ＩＴＳ−Ｓにおいて、ファシリティレイヤは、ネットワーク／トランスポートレイヤからＭＣＭを受信及びパージングし、ＭＣＭのマルチメディアコンテンツ及び他のイベントデスクリプションをアプリケーションレイヤに伝達することができる。複数のＭＣＭがマルチメディアコンテンツのセグメントを含む場合、ファシリティレイヤは、これらをマルチメディアコンテンツに併合（merge）して併合されたマルチメディアコンテンツをアプリケーションレイヤに伝達することができる。または、ファシリティレイヤは、パージングされたそれぞれのセグメントをそのままアプリケーションレイヤに伝達することもできる。このような過程において、マルチメディアコンテンツ又はセグメントはローカルストレージに保存される。ＭＣＭをパージングした後、ファシリティレイヤはストレージの状態（status）テストを行い、状態タイプ及び該当する受信機の動作を決定することができる。また、ファシリティレイヤは、重複確認／チェッキング（checking）、言語チェッキング及び有効性（validity）チェッキングなどの動作を行うことができる。ＭＣＭからＵＲＬが発見された場合、ファシリティレイヤはＵＲＬを適切な下位レイヤに伝達することができ、下位レイヤは受信したＵＲＬに接続することによりマルチメディアコンテンツ又はセグメントを受信／回収（retrieve）することができる。

図１１に示す各モジュールは、別途のモジュールとして備えられるか、ソフトウェアで実現されて動作する論理的なオブジェクトになることができる。図１１のＭＣＭベーシックサービス提供のために備えられるモジュールに関する説明は以下の通りである。

ネットワーク／トランスポートレイヤに対するＭＣＭインターフェーシングモジュール（MCM Interfacing module with N&T layers）：送信ＩＴＳ−ＳのＭＣＤベーシックサービスにおいて、ＭＣＭインターフェーシングモジュールは、アプリケーションレイヤから受信したマルチメディアコンテンツ及び他のイベントデスクリプションをＭＣＭの形態でネットワーク／トランスポートレイヤに伝達することができる。受信ＩＴＳ−ＳのＭＣＤベーシックサービスにおいて、ＭＣＭインターフェーシングモジュールは、ネットワーク／トランスポートレイヤからＭＣＭを受信及びパージングし、ＭＣＭのマルチメディアコンテンツ及び他のデスクリプションをアプリケーションレイヤに伝達することができる。

ＭＣＭ生成モジュール（MCM Generating module）：送信ＩＴＳ−ＳのＭＣＭ生成モジュールは、マルチメディアコンテンツ、セグメント及び他のイベントデスクリプションの少なくとも１つからＭＣＭを生成する。

アプリケーションレイヤに対するＭＣＭインターフェーシングモジュール（MCM Interfacing model with Application layer）：送信ＩＴＳ−Ｓにおいて、このＭＣＭインターフェーシングモジュールは、マルチメディアコンテンツ及び他のイベントデスクリプションをアプリケーションレイヤから受信し、これらをＭＣＭの形態でネットワーク／トランスポートレイヤに伝達することができる。受信ＩＴＳ−Ｓにおいて、このＭＣＭインターフェーシングモジュールは、ネットワーク／トランスポートレイヤから受信したＭＣＭのマルチメディアコンテンツ及び他のイベントデスクリプションをアプリケーションレイヤに伝達することができる。

ＭＣＭセグメントモジュール（MCM Segment module）：ＭＣＭセグメントモジュールは、マルチメディアコンテンツを複数の（multile）セグメントに分割することができる。

ＭＣＭ併合モジュール（MCM Merging module）：受信ＩＴＳ−ＳのＭＣＭ併合モジュールは複数のセグメントをマルチメディアコンテンツに併合することができる。

ＭＣＭパージングモジュール（MCM Parsing module）：受信ＩＴＳ−ＳのＭＣＭパージングモジュールは、ＭＣＭからマルチメディアコンテンツ、セグメント又は他のイベントデスクリプションの少なくとも１つを抽出することができる。

マルチメディアコンテンツ保存モジュール（Multimedia Content Storing module）：マルチメディアコンテンツ保存モジュールは、マルチメディアコンテンツ又はセグメントをローカルストレージなどの保存空間に保存することができる。

ストレージ状態テスティングモジュール（Storage Status Testing module）：ストレージ状態テスティングモジュールは、ローカルストレージの状態テストを行うことができる。ストレージ状態テスティングモジュールのテストは、ストレージ状態タイプ及び該当動作の決定に用いられることができる。

マルチメディアコンテンツ重複チェッキングモジュール（Multimedia Content Duplication Checking module）：マルチメディアコンテンツ重複チェッキングモジュールは、マルチメディアコンテンツの重複チェックを行うことができる。

マルチメディアコンテンツ言語チェッキングモジュール（Multimedia Content Language Checking module）：マルチメディアコンテンツ言語チェッキングモジュールは、コンテンツに対する言語チェックを行うことができる。

マルチメディア有効性チェッキングモジュール（MCM Validity Checking module）：マルチメディア有効性チェッキングモジュールは、ＭＣＭ有効性（時間面で(in time-wise)）チェッキングを行うことができる。

図１２は、本発明の実施形態によるＭＣＭの送信／受信方法を示す。

ＭＣＤを通じて送信ＩＴＳ−Ｓ（Sender ITS Station）１０００と受信ＩＴＳ−Ｓ（Receiver ITS Station）２０００間で伝達される情報は、マルチメディアコンテンツ及びマルチメディアコンテンツに関連するメタデータを含むイベントデスクリプションを含むことができる。マルチメディアコンテンツ及びイベントデスクリプションは、ＭＣＭに含まれて伝達されることができる。

図１２は、マルチメディアコンテンツが１つのＭＣＭに含まれて伝達される場合のＭＣＤ動作を示す。

送信ＩＴＳステーション１０００の動作は次の通りである。

アプリケーション（Application）は、マルチメディアコンテンツ及び他のイベントデスクリプションをファシリティレイヤのＭＣＤベーシックサービスエンティティに伝達する。ＭＣＤベーシックサービスエンティティ（MCD basic service）は、マルチメディアコンテンツ及びイベントデスクリプションをフォーマッティングしてＭＣＭを下位レイヤ（Lower Layers）に伝達する。下位レイヤは、下位レイヤにおける通信のためのヘッダーを有するＭＣＭを送信する。

本明細書において、下位レイヤは、ネットワーク／トランスポートレイヤ又はアクセスレイヤの少なくとも１つを含むことができる。

受信ＩＴＳステーション２０００の動作は次の通りである。

下位レイヤは、下位レイヤにおける通信のためのヘッダーを有するＭＣＭを受信し、下位レイヤのプロセシングを行う。下位レイヤは、ＭＣＭをＭＣＤベーシックサービスエンティティに伝達する。ＭＣＤベーシックサービスエンティティは、ＭＣＭに対してメッセージパージングを行う。ＭＣＤベーシックサービスエンティティは、パージングされたマルチメディアコンテンツ及びイベントデスクリプションをアプリケーションに伝達する。

図１３は、本発明の実施形態によるＭＣＭの送信／受信方法を示す。

ＭＣＤを通じて送信ＩＴＳ−Ｓ（Sender ITS Station）１０００と受信ＩＴＳ−Ｓ（Receiver ITS Station）２０００間で伝達される情報は、マルチメディアコンテンツ及びマルチメディアコンテンツに関連するメタデータを含むイベントデスクリプションを含むことができる。マルチメディアコンテンツ及びイベントデスクリプションはＭＣＭに含まれて伝達される。

図１３は、マルチメディアコンテンツが複数のＭＣＭに分離されて伝達される場合のＭＣＤ動作を示す。

送信ＩＴＳステーション１０００の動作は次の通りである。

アプリケーション（Application）は、マルチメディアコンテンツ及び他のイベントデスクリプションをファシリティレイヤのＭＣＤベーシックサービスエンティティに伝達する。ＭＣＤベーシックサービスエンティティ（MCD basic service）は、マルチメディアコンテンツを複数のセグメント（ｓｅｇｍｅｎｔ♯１〜♯ｎ）に分割することができる。ＭＣＤベーシックサービスエンティティは、複数のコンテンツセグメントをフォーマッティングし、各コンテンツセグメントに対する複数のＭＣＭ（ＭＣＭ♯１〜♯ｎ）を下位レイヤに伝達する。下位レイヤは、下位レイヤにおける通信のためのヘッダーを有する複数のＭＣＭ（ＭＣＭ♯１〜♯ｎ）を送信する。

受信ＩＴＳステーション２０００の動作は次の通りである。

下位レイヤは、下位レイヤにおける通信のためのヘッダーを有する複数のＭＣＭ（ＭＣＭ♯１〜♯ｎ）を受信し、下位レイヤのプロセシングを行う。下位レイヤは、複数のＭＣＭ（ＭＣＭ♯１〜♯ｎ）をＭＣＤベーシックサービスエンティティに伝達する。ＭＣＤベーシックサービスエンティティは、複数のＭＣＭに対してメッセージパージングを行うことによりコンテンツセグメントを取得する。ＭＣＤベーシックサービスエンティティは、生成したコンテンツセグメントをキャッシング又は保存することができる。１つのマルチメディアコンテンツのための複数のＭＣＭに対するパージングが完了すると、ＭＣＤベーシックサービスエンティティは、パージングされた複数のコンテンツに対するコンテンツ併合（content mergence）を行う。ＭＣＤベーシックサービスエンティティは、マルチメディアコンテンツ及びイベントデスクリプションをアプリケーションに伝達する。

図１４は、本発明の実施形態によるＭＣＭの送信／受信方法を示す。

ＭＣＤを通じて送信ＩＴＳ−Ｓ（Sender ITS Station）１０００と受信ＩＴＳ−Ｓ（Receiver ITS Station）２０００間で伝達される情報は、マルチメディアコンテンツ及びマルチメディアコンテンツに関連するメタデータを含むイベントデスクリプションを含むことができる。マルチメディアコンテンツ及びイベントデスクリプションはＭＣＭに含まれて伝達される。

図１４は、マルチメディアコンテンツが複数のＭＣＭに分離されて伝達される場合として、受信ＩＴＳステーション２０００側のコンテンツ併合をアプリケーションが行う実施形態を示す。図１３と同じ説明は繰り返さない。

受信ＩＴＳステーション２０００の動作は次の通りである。

下位レイヤは、下位レイヤにおける通信のためのヘッダーを有する複数のＭＣＭ（ＭＣＭ♯１〜♯ｎ）を受信し、下位レイヤのプロセシングを行う。下位レイヤは、複数のＭＣＭ（ＭＣＭ♯１〜♯ｎ）をＭＣＤベーシックサービスエンティティに伝達する。ＭＣＤベーシックサービスエンティティは、複数のＭＣＭに対してメッセージパージングを行うことにより複数のコンテンツセグメント又は複数のマルチメディアコンテンツを取得することができる。この場合、複数のマルチメディアコンテンツは、１つのマルチメディアコンテンツに対するセグメントを含むことができる。ＭＣＤベーシックサービスエンティティは、取得した複数のコンテンツセグメント又は複数のマルチメディアコンテンツをアプリケーションに伝達することができる。

アプリケーションは、複数のマルチメディアコンテンツ又は複数のコンテンツセグメントをキャッシング又は保存することができる。また、アプリケーションはコンテンツ併合を行うことができる。

図１５は、本発明の実施形態によるＭＣＭの送信／受信方法を示す。

ＭＣＤを通じて送信ＩＴＳ−Ｓ（Sender ITS Station）１０００と受信ＩＴＳ−Ｓ（Receiver ITS Station）２０００間で伝達される情報は、マルチメディアコンテンツ及びマルチメディアコンテンツに関連するメタデータを含むイベントデスクリプションを含むことができる。マルチメディアコンテンツ及びイベントデスクリプションはＭＣＭに含まれて伝達される。

図１５は、マルチメディアコンテンツが複数のＭＣＭに分離されて伝達される場合として、受信ＩＴＳステーション２０００側のコンテンツ併合はファシリティレイヤで行われるが、他のイベントデスクリプションは直ちにアプリケーションレイヤに伝達される実施形態を示す。図１３と同じ説明は繰り返さない。

受信ＩＴＳステーション２０００の動作は次の通りである。

下位レイヤは、下位レイヤにおける通信のためのヘッダーを有する複数のＭＣＭ（ＭＣＭ♯１〜♯ｎ）を受信し、下位レイヤのプロセシングを行う。下位レイヤは、複数のＭＣＭ（ＭＣＭ♯１〜♯ｎ）をＭＣＤベーシックサービスエンティティに伝達する。ＭＣＤベーシックサービスエンティティは、複数のＭＣＭに対してメッセージパージングを行うことにより複数のコンテンツセグメント及びイベントデスクリプションを取得することができる。

ＭＣＤベーシックサービスエンティティは、パージングされた複数のＭＳＭから取得したイベントデスクリプションそれぞれをアプリケーションに伝達することができる。ＭＣＤベーシックサービスエンティティは、生成したコンテンツセグメントをキャッシング又は保存することができる。１つのマルチメディアコンテンツのための複数のＭＣＭに対するパージングが完了すると、ＭＣＤベーシックサービスエンティティは、パージングされた複数のコンテンツに対するコンテンツ併合（content mergence）を行う。ＭＣＤベーシックサービスエンティティは、併合されたマルチメディアコンテンツをアプリケーションに伝達する。

図１６は、本発明の実施形態によるＭＣＭのマネジメントコンテナの構成を示す。

図１６は、図１０に示すＭＣＭに含まれるマネジメントコンテナの構成を示し、図１０で説明したフィールド／データに関する説明は繰り返さない。

図１６（ａ）はサイズ情報を含むＭＣＭフォーマットを示し、図１６（ｂ）はサイズ情報を有するマネジメントコンテナフォーマットを示す。マネジメントコンテナに含まれる情報／フィールドに関する説明は以下の通りである。

ｒｅｑｕｅｓｔフィールド：リクエストフィールドは、ＭＣＭメッセージがリクエスト／要求メッセージであるか、レスポンス（response）／応答メッセージであるかを示す（indicate）。

ｒｅｆｅｒｅｎｃｅＴｉｍｅフィールド：基準時間フィールドはＭＣＭ生成（generation）時間を示す。

ａｃｔＩＤフィールド：アクションＩＤフィールドはｏｒｇｉｎａｔｉｎｇＳｔａｔｉｏｎＩＤとｓｅｑｕｅｎｃｅＮｕｍｂｅｒの組み合わせとしてメッセージを識別する。

ｌｉｎｋｅｄＤｅｎｍ：リンクドＤＥＮＭフィールドは関連するＤＥＮＭを識別する。

ｎｕｍｂｅｒｏｆＭｕｌｔｉｍｅｄｉａＤａｔａＵｎｉｔ：マルチメディアデータユニットの数フィールドはマルチメディアコンテナ内のマルチメディアデータユニットの数を示す。

ｔｏｔａｌＮｕｍｂｅｒＯｆＵｎｉｔｓ：データユニットの総数フィールドはマルチメディアコンテンツ内のセグメントの数を示す。

ｕｎｉｔＮｕｍｂｅｒ：ユニットナンバーフィールドはマルチメディアコンテンツのセグメントのシーケンスナンバーを示す。

ｍｕｌｔｉｍｅｄｉａＦｏｒｍａｔＴｙｐｅ：マルチメディアフォーマットタイプフィールドはマルチメディアコンテンツのフォーマットを示す。

ｓｉｚｅＯｆＭｕｌｔｉｍｅｄｉａ：マルチメディアのサイズフィールドは少なくとも１つのＭＣＭにより伝達されるマルチメディアコンテンツのサイズをバイトで示す。少なくとも１つのＭＣＭは同一のアクションＩＤを有する。

ｓｉｚｅＯｆＳｅｇｍｅｎｔ：このＭＣＭで伝達されるマルチメディアコンテンツのセグメントのサイズをバイトで示す。

表１は、ｓｉｚｅＩｎＢｙｔｅデータエレメントの定義を示す。マルチメディアサイズ情報及びセグメントサイズ情報は、ｓｉｚｅＩｎＢｙｔｅのデータエレメントとしてマネジメントコンテナに含まれてデータサイズを定義することができる。ｓｉｚｅＩｎＢｙｔｅデータエレメントは任意のコンテンツのサイズをバイト単位で定義することができる。

受信ＩＴＳ−ＳのファシリティレイヤのＭＣＤベーシックサービスエンティティは、マルチメディアサイズ情報、セグメントサイズ情報及びローカルストレージ情報に基づいてストレージ状態（status）テストを行うことができる。受信ＩＴＳ−Ｓは、ストレージ状態テストに基づいて状態タイプを決定することができる。決定された状態タイプに基づいて、ＭＣＤベーシックサービスエンティティは、ｉ）受信したＭＣＭをアプリケーションに伝達するか否か、ｉｉ）今後受信するＭＣＭセグメントをアプリケーションレイヤに伝達するか否か、ｉｉｉ）今後受信するＭＣＭセグメントに対してストレージ状態テストを行うか否か決定することができる。

ＩＴＳ−Ｓは、ストレージ状態テストを行うコンディション及びタイプを決定し、決定されたタイプによる動作を行うことができる。表２は、ＩＴＳ−Ｓのストレージ状態テストのためのコンディション、状態タイプ及びそれによる動作を示す。

図１７は、本発明の実施形態による、サイズ情報を含むＭＣＭ送信／受信方法を示す。

ＭＣＤを通じて送信ＩＴＳ−Ｓ（Sender ITS Station）１０００と受信ＩＴＳ−Ｓ（Receiver ITS Station）２０００間で伝達される情報は、マルチメディアコンテンツ及びマルチメディアコンテンツに関連するメタデータを含むイベントデスクリプションを含むことができる。マルチメディアコンテンツ及びイベントデスクリプションはＭＣＭに含まれて伝達される。

図１７は、マルチメディアコンテンツが複数のＭＣＭに分離されて伝達される場合のＭＣＤ動作を示し、特に、サイズ情報がＭＣＭに含まれる場合の実施形態を示す。図１３ないし図１５と同じ説明は繰り返さない。

受信ＩＴＳステーション２０００の動作は次の通りである。

下位レイヤは、下位レイヤにおける通信のためのヘッダーを有する複数のＭＣＭ（ＭＣＭ♯１〜♯n）を受信し、下位レイヤのプロセシングを行う。下位レイヤは、プロセシングされた複数のＭＣＭをファシリティＭＣＤベーシックサービスエンティティに伝達する。

ＭＣＤベーシックサービスエンティティはＭＣＭをパージングし、状態テストを行う。状態テストは、表２及び前述の説明のように行われる。すなわち、ＭＣＤベーシックサービスエンティティは、ＭＣＭからマルチメディアサイズ情報及びセグメントサイズ情報を取得し、受信ＩＴＳ−Ｓのストレージの利用可能サイズとサイズ情報を比較する。

ＭＣＤベーシックサービスエンティティは、パージングされたＭＣＭ♯ｎに先行して受信及びパージングされたＭＣＭ（ＭＣＭ♯１〜♯ｎ−１）のテストされた状態が＃２−ｂ又は＃３に該当するか否かを決定することができる。先行のＭＣＭ（ＭＣＭ♯１〜♯ｎ−１）のテストされた状態が＃２−ｂ又は＃３に該当する場合、ＭＣＤベーシックサービスエンティティは、ＭＣＭ♯ｎを受信しないか、無視することができる。すなわち、ＭＣＤベーシックサービスエンティティは、パージングされたセグメント＃ｎを廃棄（discard）することができる。

ＭＣＤベーシックサービスエンティティは、パージングされたＭＣＭ♯ｎに先行して受信及びパージングされたＭＣＭ（ＭＣＭ♯１〜♯ｎ−１）のテストされた状態が＃２−ｂ又は＃３に該当しない場合、先行ＭＣＭ（ＭＣＭ♯１〜♯ｎ−１）のテストされた状態が＃１に該当するかを追加で決定することができる。先行のＭＣＭのテストされた状態が＃１にも該当しない場合、ＭＣＤベーシックサービスエンティティは、ＭＣＭ♯ｎに対する状態テストを行う。先行のＭＣＭのテストされた状態が＃１に該当する場合、ＭＣＤベーシックサービスエンティティは、コンテンツセグメント＃ｎをキャッシング又は保存することができる。

ＭＣＤベーシックサービスエンティティは、ＭＣＭ♯ｎ、すなわちセグメント＃ｎに対して状態テストを行うことができる。テストされた状態が＃２−ｂ又は＃３である場合、ＭＣＤベーシックサービスエンティティは、ＭＣＭ♯ｎを受信するか、無視することができる。すなわち、ＭＣＤベーシックサービスエンティティは、パージングされたセグメント＃ｎを廃棄（discard）することができる。テストされた状態が＃１又は＃２−ａである場合、ＭＣＤベーシックサービスエンティティは、コンテンツセグメント＃ｎをキャッシング又は保存することができる。

図１７の実施形態において、ＭＣＤベーシックサービスエンティティは、コンテンツを併合することができる。実施形態として、ＭＣＤベーシックサービスエンティティは、１つのマルチメディアコンテンツに該当する全てのセグメントが受信された場合、コンテンツ併合を行うことができる。ＭＣＤベーシックサービスエンティティは、併合されたコンテンツ及び他のイベントデスクリプションをアプリケーションに伝達することができる。

図１８は、本発明の実施形態による、サイズ情報を含むＭＣＭの送信／受信方法を示す。

ＭＣＤを通じて送信ＩＴＳ−Ｓ（Sender ITS Station）１０００と受信ＩＴＳ−Ｓ（Receiver ITS Station）２０００間で伝達される情報は、マルチメディアコンテンツ及びマルチメディアコンテンツに関連するメタデータを含むイベントデスクリプションを含むことができる。マルチメディアコンテンツ及びイベントデスクリプションは、ＭＣＭに含まれて伝達される。

図１８は、マルチメディアコンテンツが複数のＭＣＭに分離されて伝達される場合のＭＣＤ動作を示し、特に、サイズ情報がＭＣＭに含まれる場合の実施形態を示す。図１８は、受信ＩＴＳステーション２０００側のコンテンツ併合をアプリケーションが行う実施形態を示す。図１３ないし図１５及び図１７と同じ説明は繰り返さない。

受信ＩＴＳステーション２０００の動作は次の通りである。

図１８の実施形態において、受信ＩＴＳ−Ｓは、図１７における方法と同一の方法でＭＣＭに対して状態テストを行う。ただし、図１８の場合、ＭＣＤベーシックサービスエンティティは、取得した複数のコンテンツセグメント又は複数のマルチメディアコンテンツをアプリケーションに伝達することができる。

アプリケーションは、複数のマルチメディアコンテンツ又は複数のコンテンツセグメントをキャッシング又は保存することができる。また、アプリケーションは、コンテンツ併合を行うことができる。実施形態として、アプリケーションは、１つのマルチメディアコンテンツに該当する全てのセグメントが受信された場合、コンテンツ併合を行うことができる。

図１９は、本発明の実施形態による、サイズ情報を含むＭＣＭの送信／受信方法を示す。

ＭＣＤを通じて送信ＩＴＳ−Ｓ（Sender ITS Station）１０００と受信ＩＴＳ−Ｓ（Receiver ITS Station）２０００間で伝達される情報は、マルチメディアコンテンツ及びマルチメディアコンテンツに関連するメタデータを含むイベントデスクリプションを含むことができる。マルチメディアコンテンツ及びイベントデスクリプションは、ＭＣＭに含まれて伝達される。

図１９は、マルチメディアコンテンツが複数のＭＣＭに分離されて伝達される場合のＭＣＤ動作を示し、特に、サイズ情報がＭＣＭに含まれる場合の実施形態を示す。図１９は、受信ＩＴＳステーション２０００側のコンテンツ併合はファシリティレイヤで行われるが、他のイベントデスクリプションは直ちにアプリケーションレイヤに伝達される実施形態を示す。図１３と同じ説明は繰り返さない。図１３ないし図１５及び図１７及び図１８と同じ説明は繰り返さない。

図１９の実施形態において、受信ＩＴＳ−Ｓは、図１７における方法と同一の方法でＭＣＭに対して状態テストを行う。ただし、図１９の場合、ＭＣＤベーシックサービスエンティティは、パージングされたＭＳＭから取得したイベントデスクリプションそれぞれをアプリケーションに伝達することができる。ＭＣＤベーシックサービスエンティティは、生成したコンテンツセグメントをキャッシング又は保存することができる。１つのマルチメディアコンテンツのための複数のＭＣＭに対するパージングが完了すると、ＭＣＤベーシックサービスエンティティは、パージングされた複数のコンテンツに対するコンテンツ併合（content mergence）を行う。実施形態として、ＭＣＤサービスエンティティは、１つのマルチメディアコンテンツに該当する全てのセグメントが受信された場合、コンテンツ併合を行うことができる。ＭＣＤベーシックサービスエンティティは、併合されたマルチメディアコンテンツをアプリケーションに伝達する。

図２０は、本発明の実施形態による、サイズ情報を用いたＭＣＤ動作を示す。

図２０において、ＲＳＵはビデオファイルを送信する。ビデオ５メガバイトのビデオクリップに該当する。ビデオクリップは１メガバイトサイズの５つのセグメントに分割されて送信される。現在送信されるＭＣＭ♯１はビデオセグメント１を含む。ＭＣＭは、マルチメディアコンテンツサイズ情報、セグメント数情報、セグメントサイズ情報を含む。図２０の実施形態において、コンテンツサイズ情報は５メガバイトを、セグメント数情報は５を、ビデオセグメントサイズ情報は１メガバイトをそれぞれ示すことができる。

各車両のＶ２Ｘ装置、すなわちＩＴＳ−Ｓの利用可能保存空間のサイズ及びデコーディング性能は相異なる。車両（ａ）の場合、利用可能ストレージ容量は１０メガである。車両（ｂ）の場合、利用可能ストレージ容量は３メガバイトであり、ＩＴＳ−Ｓは部分的なコンテンツレンダリングが可能である。車両（ｃ）の場合、利用可能ストレージ容量は０．５メガバイトであり、部分的なコンテンツレンダリングが可能である。車両（ｄ）の場合、利用可能ストレージ容量は４メガバイトであり、部分的なコンテンツレンダリングは不可能である。

各車両は、前述したように状態テストを行う。車両（ａ）の場合、テストされた状態は状態＃１に該当する。従って、車両（ａ）は、全てのコンテンツセグメントを受信し、追加的な状態テストは必要でない。車両（ｂ）の場合、テストされた状態は状態＃２−ａに該当する。従って、車両（ｂ）は、該当コンテンツセグメントを受信し、追加的な状態テストは必要である。車両（ｃ）の場合、テストされた状態は状態＃２−ｂに該当する。従って、車両（ｃ）は、コンテンツセグメントを受信しなく、追加的なテストも必要でない。車両（ｄ）の場合、テストされた状態は状態＃３に該当する。従って、車両（ｄ）は、コンテンツセグメントを受信しなく、追加的なテストも必要でない。

図２１は、本発明の実施形態によるＭＣＭのマネジメントコンテナの構成を示す。

図２１は、図１０に示すＭＣＭに含まれるマネジメントコンテナの構成を示し、前述したフィールド／データに関する説明は繰り返さない。

図２１（ａ）は、ファイル名（fileName）情報、ＵＲＩ（Uniform Resource Identifier）情報及びＭＤ５情報を含むＭＣＭフォーマットを示し、図２１（ｂ）は、ファイル名情報、ＵＲＩ情報及びＭＤ５情報を含むマネジメントコンテナフォーマットを示す。ファイル名情報、ＵＲＩ情報及びＭＤ５情報を除いた、マネジメントコンテナに含まれる情報／フィールドに関する説明は図１６と関連した前述の説明を参照する。

図２１及び表３ないし表５の実施形態において、マルチメディアコンテンツを識別する情報をマルチメディアコンテンツ識別子情報又はマルチメディアファイル識別子情報と称することができる。ＭＣＭは、マルチメディア識別子情報を含むことができる。マルチメディア識別子情報は。ファイル名情報、ＵＲＩ情報又はＭＤ５情報のうち少なくとも１つを含むことができる。

表３は、ファイル名データエレメントの定義を示す。ファイル名情報は、マルチメディアコンテンツのファイル名を定義することができる。

表４は、ＵＲＩデータエレメントの定義を示す。ＵＲＩ情報は、マルチメディアコンテンツのＵＲＩを定義することができる。

表５は、ＭＤ５データエレメントの定義を示す。ＭＤ５情報は、マルチメディアコンテンツのＭＤ５値を定義することができる。

図２２は、本発明の実施形態によるＭＣＭの送信／受信方法を示す。

ＭＣＤを通じて送信ＩＴＳ−Ｓ（Sender ITS Station）１０００と受信ＩＴＳ−Ｓ（Receiver ITS Station）２０００間で伝達される情報は、マルチメディアコンテンツ及びマルチメディアコンテンツに関連するメタデータを含むイベントデスクリプションを含むことができる。マルチメディアコンテンツ及びイベントデスクリプションは、ＭＣＭに含まれて伝達される。

図２２は、マルチメディアコンテンツが複数のＭＣＭに分離されて伝達される場合のＭＣＤ動作を示す。特に、図２２は、ＭＣＭがマルチメディアコンテンツ識別子情報を含む実施形態を示す。図１３ないし図１５と同じ説明は繰り返さない。

受信ＩＴＳステーション２０００は、ＭＣＭをパージングし、重複チェック（duplication check）を行う。ＭＣＤベーシックサービスエンティティは、ＭＣＭから取得したマルチメディアコンテンツ識別子情報に基づいて受信メッセージが送信するコンテンツが既に受信又は処理したコンテンツであるか否かを確認することができる。受信ＭＣＭのコンテンツが既に処理したコンテンツと重複するコンテンツである場合、受信ＩＴＳステーション２０００は、このＭＣＭと同一のメッセージＩＤを有するＭＣＭは受信しないか、無視／廃棄することができる。受信ＭＣＭのコンテンツが既に処理したコンテンツと重複するコンテンツでない場合、受信ＩＴＳステーション２０００は、図１３で説明したように、ＭＣＭをプロセシングすることができる。

図２３は、本発明の実施形態によるＭＣＭの送信／受信方法を示す。

ＭＣＤを通じて送信ＩＴＳ−Ｓ（Sender ITS Station）１０００と受信ＩＴＳ−Ｓ（Receiver ITS Station）２０００間で伝達される情報は、マルチメディアコンテンツ及びマルチメディアコンテンツに関連するメタデータを含むイベントデスクリプションを含むことができる。マルチメディアコンテンツ及びイベントデスクリプションはＭＣＭに含まれて伝達される。

図２３は、マルチメディアコンテンツが複数のＭＣＭに分離されて伝達される場合のＭＣＤ動作を示す。特に、図２３は、ＭＣＭがマルチメディアコンテンツ識別子情報を含む実施形態を示す。図１３ないし図１５と同じ説明は繰り返さない。

受信ＩＴＳステーション２０００は、ＭＣＭをパージングし、重複チェック（duplication check）を行う。ＭＣＤベーシックサービスエンティティは、ＭＣＭから取得したマルチメディアコンテンツ識別子情報に基づいて受信メッセージが伝達するコンテンツが既に受信又は処理したコンテンツであるか否かを確認することができる。受信ＭＣＭのコンテンツが既に処理したコンテンツと重複するコンテンツである場合、受信ＩＴＳステーション２０００は、このＭＣＭと同一のメッセージＩＤを有するＭＣＭは受信しないか、無視／廃棄することができる。受信ＭＣＭのコンテンツが既に処理したコンテンツと重複するコンテンツでない場合、受信ＩＴＳステーション２０００は、図１４で説明したように、ＭＣＭをプロセシングすることができる。

図２４は、本発明の実施形態によるＭＣＭの送信／受信方法を示す。

ＭＣＤを通じて送信ＩＴＳ−Ｓ（Sender ITS Station）１０００と受信ＩＴＳ−Ｓ（Receiver ITS Station）２０００間で伝達される情報は、マルチメディアコンテンツ及びマルチメディアコンテンツに関連するメタデータを含むイベントデスクリプションを含むことができる。マルチメディアコンテンツ及びイベントデスクリプションはＭＣＭに含まれて伝達される。

図２４は、マルチメディアコンテンツが複数のＭＣＭに分離されて伝達される場合として、受信ＩＴＳステーション２０００側のコンテンツ併合はファシリティレイヤで行われるが、他のイベントデスクリプションは直ちにアプリケーションレイヤに伝達される実施形態を示す。特に、図２４は、ＭＣＭがマルチメディアコンテンツ識別子情報を含む実施形態を示す。図１３ないし図１５と同じ説明は繰り返さない。

受信ＩＴＳステーション２０００は、ＭＣＭをパージングし、重複チェック（duplication check）を行う。ＭＣＤベーシックサービスエンティティはＭＣＭから取得したマルチメディアコンテンツ識別子情報に基づいて受信メッセージが伝達するコンテンツが既に受信又は処理したコンテンツであるか否かを確認することができる。受信ＭＣＭのコンテンツが既に処理したコンテンツと重複するコンテンツである場合、受信ＩＴＳステーション２０００はこのＭＣＭと同一のメッセージＩＤを有するＭＣＭは受信しないか、無視／廃棄することができる。受信ＭＣＭのコンテンツが既に処理したコンテンツと重複するコンテンツでない場合、受信ＩＴＳステーション２０００は、図１５で説明したように、ＭＣＭをプロセシングすることができる。

図２５は、本発明の実施形態による、マルチメディアコンテンツ識別子情報を用いたＭＣＤ動作を示す。

図２５において、ＲＳＵは停止イメージファイルを送信する。イメージファイルのファイル名は「Ｇａｓ＿Ｓｔａｔｉｏｎ＿１２３４.ｊｐｇ」である。ＲＳＵがイメージファイルを送信する場合、イメージファイルを含むＭＣＭヘッダーは前述したマルチメディアコンテンツ識別子情報を含む。図２５の実施形態において、ＭＣＭヘッダーはファイル名情報を含み、ファイル名情報は「Ｇａｓ＿Ｓｔａｔｉｏｎ＿１２３４.ｊｐｇ」を示すことができる。

ビデオ５メガバイトのビデオクリップに該当する。ビデオクリップは１メガバイトサイズの５つのセグメントに分割されて送信される。現在送信されるＭＣＭ♯１はビデオセグメント１を含む。ＭＣＭは、マルチメディアコンテンツサイズ情報、セグメント数情報、セグメントサイズ情報を含むことができる。図２０の実施形態において、コンテンツサイズ情報は５メガバイトを、セグメント数情報は５を、ビデオセグメントサイズ情報は１メガバイトをそれぞれ示すことができる。

各車両のＶ２Ｘ装置、すなわちＩＴＳ−Ｓの状態は相異なる。車両（ａ）の場合、「Ｇａｓ＿Ｓｔａｔｉｏｎ＿１２３４.ｊｐｇ」ファイルは既に保存されている。車両（ｂ）の場合、「Ｇａｓ＿Ｓｔａｔｉｏｎ＿１２３４.ｊｐｇ」ファイルは保存されていない。

各車両は、前述したように重複チェックを行う。車両（ａ）の場合、重複したファイルが既に保存されている。従って、車両（ａ）はＭＣＭを無視してＭＣＭをアプリケーションレイヤに伝達しない。すなわち、車両（ａ）は、重複ファイルに該当するＭＣＭを廃棄（discard）することができる。車両（ｂ）の場合、受信ＭＣＭは新しいファイルを伝達する。従って、車両（ｂ）は、ＭＣＭを受信してプロセシングし、プロセシングされたファイル／セグメントをアプリケーションレイヤに伝達する。

図２６は、本発明の実施形態によるＭＣＭのマネジメントコンテナの構成を示す。

図２６は、図１０に示すＭＣＭに含まれるマネジメントコンテナの構成を示し、前述したフィールド／データに関する説明は繰り返さない。

図２６（ａ）は、ＵＲＬ（Uniform Resource Locator）情報を含むＭＣＭフォーマットを示し、図２６（ｂ）は、ＵＲＬ情報を有するマネジメントコンテナフォーマットを示す。ＵＲＬフィールド／情報を除いた、マネジメントコンテナに含まれる情報／フィールドに関する説明は図１６と関連して前述した説明を参照する。

表６は、ＵＲＬデータエレメントの定義を示す。ＵＲＬ情報はリソースのＵＲＬを定義することができる。すなわち、ＵＲＬ情報はマルチメディアコンテンツをダウンロードできるＵＲＬを示すことができる。

図２７は、本発明の実施形態によるＭＣＭの送信／受信方法を示す。

ＭＣＤを通じて送信ＩＴＳ−Ｓ（Sender ITS Station）１０００と受信ＩＴＳ−Ｓ（Receiver ITS Station）２０００間で伝達される情報は、マルチメディアコンテンツ及びマルチメディアコンテンツに関連するメタデータを含むイベントデスクリプションを含むことができる。マルチメディアコンテンツ及びイベントデスクリプションはＭＣＭに含まれて伝達される。

図２７は、ＭＣＭがＵＲＬ情報を含む場合の実施形態を示す。

送信ＩＴＳステーション１０００の動作は次の通りである。

アプリケーション（Application）は、マルチメディアコンテンツに対するＵＲＬ及び他のイベントデスクリプションをファシリティレイヤのＭＣＤベーシックサービスエンティティに伝達する。ＭＣＤベーシックサービスエンティティは、コンテンツに対するＭＣＭを生成して下位レイヤに伝達する。生成されたＭＣＭはＵＲＬ情報を含む。下位レイヤは、下位レイヤにおける通信のためのヘッダーを有するＭＣＭを送信する。

受信ＩＴＳステーション２０００の動作は次の通りである。

下位レイヤは、下位レイヤにおける通信のためのヘッダーを有するＭＣＭを受信し、下位レイヤのプロセシングを行う。下位レイヤは、ＭＣＭをＭＣＤベーシックサービスエンティティに伝達する。ＭＣＤベーシックサービスエンティティは、メッセージをパージングし、ＵＲＬ情報をチェックする。ＭＣＤベーシックサービスエンティティは他の下位レイヤにＵＲＬ情報を伝達する。

受信ＩＴＳステーション２０００の他の下位レイヤはＵＲＬに接続することによりコンテンツを取得することができる。受信ＩＴＳステーションは、ＵＲＬに基づいてコンテンツ受信が可能なプロトコルに基づいて動作する、下位レイヤ（ネットワークレイヤ、トランスポートレイヤ、ＭＡＣレイヤ、フィジカルレイヤの少なくとも１つ）を用いることができる。

他の下位レイヤ、ＵＲＬに接続して受信したマルチメディアコンテンツをＭＣＤベーシックサービスエンティティに伝達することができる。ＭＣＤベーシックサービスエンティティは、マルチメディアコンテンツ及び他のイベントデスクリプションをアプリケーションに提供することができる。

図２８は、本発明の実施形態による、ＵＲＬ情報を用いたＭＣＤ動作を示す。

図２８において、車両（ａ）はＵＲＬ情報を含むＭＣＭを車両（ｂ）に送信することができる。車両（ｂ）はＭＣＭを受信及びパージングしてＵＲＬ情報を取得することができる。車両（ｂ）は、ＵＲＬにアクセスして、マルチメディアコンテンツをダウンロードすることができる。ＵＲＬは、接続してマルチメディアコンテンツをダウンロードできる任意のインターネットアドレスになることもできる。

図２９は、本発明の実施形態によるＭＣＭのマネジメントコンテナの構成を示す。

図２９は、図１０に示すＭＣＭに含まれるマネジメントコンテナの構成を示し、前述したフィールド／データに関する説明は繰り返さない。

図２９（ａ）は、マルチメディア言語（Multimedia Language）情報を含むＭＣＭフォーマットを示し、図２９（ｂ）は、マルチメディア言語情報を含むマネジメントコンテナフォーマットを示す。マルチメディア言語情報を除いた、マネジメントコンテナに含まれる情報／フィールドに関する説明は図１６と関連して前述した説明を参照する。

表７は、マルチメディア言語（MultimediaLanguate）データエレメントの定義を示す。マルチメディア言語情報はマルチメディアコンテンツにより用いられる言語を定義することができる。マルチメディア言語情報は、ＩＳＯ ６３９−１のような標準化された言語コードを示すことができる。または、マルチメディア言語情報は、フォーマットサイズを小さくするためにキャラクタ値になった（character-valued）言語コードがマッピングされた数値（numeric value）を示すこともできる。

受信ＩＴＳ−Ｓは、ＭＣＭに含まれるマルチメディア言語情報に基づいて言語チェック（language check）を行うことができる。言語チェックは、言語チェックエンティティの位置によって相異なるモードで行われることができる。

１．言語チェックモードＡ：言語チェックエンティティがＭＣＤベーシックサービスエンティティである場合

モードＡにおいて、ＭＣＤベーシックサービスのファシリティレイヤエンティティが許容可能（acceptable）言語のセットを維持するか接続（access）することができる。ＭＣＤベーシックサービスは、受信したＭＣＭの言語情報が許容可能言語のセットとマッチングされるかをチェックすることができる。

２．言語チェックモードＢ：言語チェックエンティティがアプリケーションである場合

モードＢにおいて、ＭＣＤベーシックサービスのファシリティレイヤエンティティは、許容可能言語のセットを維持するか接続しない。ＭＣＤベーシックサービスが言語情報を受信又は取得する場合、ＭＣＤベーシックサービスは言語情報をアプリケーションに伝達する。アプリケーションは許容可能（acceptable）言語のセットを維持するか接続（access）することができる。アプリケーションは、受信したＭＣＭの言語情報が許容可能言語のセットとマッチングされるかをチェックすることができる。

３．言語チェックモードＣ：ファシリティレイヤのＨＭＩ（Human Machine Interface）を用いる場合

モードＣにおいて、ＭＣＤベーシックサービスのファシリティレイヤエンティティは、許容可能言語のセットを維持するか接続しない。ＭＣＤベーシックサービスが言語情報を受信又は取得する場合、ＩＴＳ−Ｓは、ＨＩＭを通じて該当言語が許容可能であるか否かをユーザ／ドライバーに質問する（ask）ことができる。

４．言語チェックモードＤ：アプリケーションがユーザ／ドライバーに質問する（ask）場合

モードＤにおいて、ＭＣＤベーシックサービスのファシリティレイヤエンティティは、許容可能言語のセットを維持するか接続しない。ＭＣＤベーシックサービスが言語情報を受信又は取得する場合、ＭＣＤベーシックサービスは言語情報をアプリケーションに伝達する。アプリケーションは、ＨＩＭを通じて／又は直接、該当言語が許容可能であるかをユーザ／ドライバーに質問する（ask）ことができる。

図３０は、本発明の実施形態によるＭＣＭの送信／受信方法を示す図である。

ＭＣＤを通じて送信ＩＴＳ−Ｓ（Sender ITS Station）１０００と受信ＩＴＳ−Ｓ（Receiver ITS Station）２０００間で伝達される情報は、マルチメディアコンテンツ及びマルチメディアコンテンツに関連するメタデータを含むイベントデスクリプションを含むことができる。マルチメディアコンテンツ及びイベントデスクリプションはＭＣＭに含まれて伝達される。

図３０は、マルチメディアコンテンツが複数のＭＣＭに分離されて伝達される場合のＭＣＤ動作を示す。特に、図３０は、ＭＣＭがマルチメディア言語情報を含む実施形態を示す。図１３ないし図１５と同じ説明は繰り返さない。

図３０は、前述した言語チェックモードＡを示す。すなわち、ＭＣＤベーシックサービスエンティティが言語チェックを行う。

受信ＩＴＳステーション２０００は、ＭＣＭをパージングし、言語チェック（language check）を行う。ＭＣＤベーシックサービスエンティティは、ＭＣＭから取得したマルチメディア言語情報を用いて、コンテンツの言語が許容可能な言語であるか否かを確認することができる。ＭＣＤベーシックサービスエンティティは、許容可能言語のセットに基づいてコンテンツの言語が許容可能な言語であるか否かを確認することができる。受信ＭＣＭのコンテンツの言語が許容可能な言語でない場合、受信ＩＴＳステーション２０００は、このＭＣＭと同一のメッセージＩＤを有するＭＣＭは受信しないか、無視／廃棄することができる。受信ＭＣＭのコンテンツの言語が許容可能な言語である場合、ＭＣＤベーシックサービスは、マルチメディアセグメント＃１をキャッシング／保存し、残ったＭＣＭを受信することができる。

図３１は、本発明の実施形態によるＭＣＭの送信／受信方法を示す。

ＭＣＤを通じて送信ＩＴＳ−Ｓ（Sender ITS Station）１０００と受信ＩＴＳ−Ｓ（Receiver ITS Station）２０００間で伝達される情報は、マルチメディアコンテンツ及びマルチメディアコンテンツに関連するメタデータを含むイベントデスクリプションを含むことができる。マルチメディアコンテンツ及びイベントデスクリプションはＭＣＭに含まれて伝達される。

図３１は、マルチメディアコンテンツが複数のＭＣＭに分離されて伝達される場合のＭＣＤ動作を示す。特に、図３１は、ＭＣＭがマルチメディア言語情報を含む実施形態を示す。図１３ないし図１５と同じ説明は繰り返さない。

図３１は、前述した言語チェックモードＢを示す。すなわち、アプリケーションが言語チェックを行う。

受信ＩＴＳステーション２０００は、ＭＣＭをパージングし、取得した言語情報をアプリケーションに伝達する。アプリケーションは言語チェック（language check）を行う。アプリケーションは、マルチメディア言語情報を用いて、コンテンツの言語が許容可能な言語であるか否かを確認することができる。アプリケーションは許容可能言語のセットに基づいてコンテンツの言語が許容可能な言語であるか否かを確認することができる。アプリケーションは、言語チェック結果をＭＣＤベーシックサービスエンティティに伝達することができる。受信ＭＣＭのコンテンツの言語が許容可能な言語でない場合、受信ＩＴＳステーション２０００は、このＭＣＭと同一のメッセージＩＤを有するＭＣＭは受信しないか、無視／廃棄することができる。受信ＭＣＭのコンテンツの言語が許容可能な言語である場合、ＭＣＤベーシックサービスは、マルチメディアセグメント＃１をキャッシング／保存し、残ったＭＣＭを受信することができる。

図３２は、本発明の実施形態によるＭＣＭの送信／受信方法を示す。

ＭＣＤを通じて送信ＩＴＳ−Ｓ（Sender ITS Station）１０００と受信ＩＴＳ−Ｓ（Receiver ITS Station）２０００間で伝達される情報は、マルチメディアコンテンツ及びマルチメディアコンテンツに関連するメタデータを含むイベントデスクリプションを含むことができる。マルチメディアコンテンツ及びイベントデスクリプションはＭＣＭに含まれて伝達される。

図３２は、マルチメディアコンテンツが複数のＭＣＭに分離されて伝達される場合のＭＣＤ動作を示す。特に、図３２は、ＭＣＭがマルチメディア言語情報を含む実施形態を示す。図１３ないし図１５と同じ説明は繰り返さない。

図３２は、前述した言語チェックモードＣ又はＤを示す。すなわち、ＭＣＤベーシックサービスエンティティ又はアプリケーションはユーザに言語チェックを要求／問い合わせする。

受信ＩＴＳステーション２０００は、ＭＣＭをパージングし、取得した言語情報をアプリケーションに伝達する。ＭＣＤベーシックサービスエンティティは、言語情報をアプリケーションに伝達するか、ＨＩＭ（Human Machine Interface）に伝達する。ＭＣＤベーシックサービスは、ＨＭＩを通じてユーザに言語チェックを要求することができる。または、アプリケーションが直接又はＨＭＩを通じてユーザに言語チェックを要求することができる。

受信ＭＣＭのコンテンツの言語が許容可能な言語でない場合、受信ＩＴＳステーション２０００は、このＭＣＭと同一のメッセージＩＤを有するＭＣＭは受信しないか、無視／廃棄することができる。受信ＭＣＭのコンテンツの言語が許容可能な言語である場合、ＭＣＤベーシックサービスはマルチメディアセグメント＃１をキャッシング／保存し、残ったＭＣＭを受信することができる。

図３３は、本発明の実施形態による、マルチメディア言語情報を用いたＭＣＤ動作を示す。

図３３において、ＲＳＵは、英語オーディオファイルを送信する。英語オーディオファイルを送信するＭＣＭのマルチメディア言語情報は英語を示す。

各車両のＶ２Ｘ装置、すなわちＩＴＳ−Ｓの状態は相異なる。車両（ａ）の場合、運転者は英語が理解できないことがある。車両（ｂ）を場合、運転者は英語が理解できることがある。

各車両は、前述したように言語チェックを行う。車両（ａ）はＭＣＭを無視してＭＣＭをアプリケーションレイヤに伝達しないことがある。すなわち、車両（ａ）はＭＣＭを廃棄（discard）することがある。車両（ｂ）はＭＣＭを受信してプロセシングし、プロセシングされたファイル／セグメントをアプリケーションレイヤに伝達することができる。

図３４は、本発明の実施形態によるＭＣＭのマネジメントコンテナの構成を示す。

図３４は、図１０に示すＭＣＭに含まれるマネジメントコンテナの構成を示し、前述したフィールド／データに関する説明は繰り返さない。

図３４（ａ）は、有効時間（validTimeUntil）情報を含むＭＣＭフォーマットを示し、図３４（ｂ）は、有効時間（validTimeUntil）情報を含むマネジメントコンテナフォーマットを示す。有効時間（validTimeUntil）情報を除いた、マネジメントコンテナに含まれる情報／フィールドに関する説明は、図１６と関連して前述した説明を参照する。

有効時間情報は、タイムスタンプ（TimestampsIts）をデータタイプとして用いることができる。

受信ＩＴＳ−Ｓは、受信マルチメディアコンテンツの有効時間情報に基づいて、有効時間前に受信したマルチメディアコンテンツであっても有効時間が経過すると、該当マルチメディアコンテンツを提供しないことができる。すなわち、有効時間後に、ＭＣＤベーシックサービスエンティティはアプリケーションに該当マルチメディアコンテンツを送信しない。有効時間後に、アプリケーションは該当マルチメディアコンテンツを用いない。有効時間後に、ＭＣＤベーシックサービスエンティティ又はマネジメントエンティティは、該当マルチメディアコンテンツをストレージ又はキャッシュ（cache）から削除することができる。

図３５は、本発明の実施形態によるＭＣＭのマネジメントコンテナ及びジオネットワーキングベーシックヘッダーを示す。

ベーシックヘッダーは、バージョンフィールド、ＮＨ（Next Header）フィールド、ＬＴ（LifeTime）フィールド、ＲＨＬ（Remaining Hop Limit）フィールドの少なくとも１つを含むことができる。ベーシックヘッダーに含まれるフィールドに関する説明は以下の通りである。各フィールドを構成するビットサイズは、実施形態にすぎないものであり、変更されることもできる。

Ｖｅｒｓｉｏｎ（４ビット）：バージョン（version）フィールドはジオネットワーキングプロトコルのバージョンを示す。

ＮＨ（４ビット）：ＮＨ（Next Header）フィールドは、後続ヘッダー／フィールドのタイプを示す。フィールド値が１であるとコモンヘッダーが後続し、２であるとセキュリティ設定されたセキュリティ（secured）パケットが後続する。

ＬＴ（８ビット）：ＬＴ（LifeTime）フィールドは該当パケットの最大生存時間を示す。

ＲＨＬ（８ビット）：ＲＨＬ（Remaining Hop Limit）フィールドは、残余ホップ制限を示す。ＲＨＬフィールド値はジオアドホック（GeoAdhoc）ルータでフォワーディングする度に１ずつ減ることができる。ＲＨＬフィールド値が０になると該当パケットはこれ以上フォワーディングされない。

マルチメディアコンテンツをジオネットワーキングプロトコルを用いてマルチホップフォワーディングすることができる。この場合、チャネルを過度に占有しないように、有効時間が経過するとマルチメディアコンテンツがこれ以上フォワーディングされないように設定できる。すなわち、ＩＴＳ−Ｓは、ＬＴフィールドの時間が経過した場合、該当パケットのフォワーディングを中断することができる。フォワーディングするＩＴＳ−Ｓは、ファシリティレイヤの情報を確認せずにフォワーディングを行うことができる。ＩＴＳステーションは、このような有効時間を確認せずにフォワーディングを行うことができる。従って、ＩＴＳ−Ｓは、ジオネットワーキングＰＤＵのベーシックヘッダーのＬＴフィールドの値を、ＭＣＭフィールドの有効時間フィールドの値と同一か又は小さく設定して送信することができる。

ＬＴは、ジオネットワーキングベーシックヘッダー内の生存時間（LifeTime）フィールドの値を示す。ＶＴＵは、ＭＣＤベーシックサービスエンティティからのＰＤＵ（Protocol Data Unit）のマネジメントコンテナ内の有効時間（validTimeUntil）フィールドの値を示す。ＣＴは、ジオネットワーキングＰＤＵが生成される時間を示す。この場合、ＬＴは、ＶＴＵからＣＴを減算した値以下に設定されることができる（ＬＴ≦ＶＴＵ−ＣＴ）。ＬＴの値は、有効時間とジオネットワーキングＰＤＵが生成される時間との差を超過してはならない。

図３６は、本発明の実施形態による、有効時間情報を用いたＭＣＤ動作を示す。

図３６において、ＲＳＵはＭＣＭ−ｘｙｚを送信する。ＲＳＵは、ＭＣＭをジオブロードキャストする。すなわち、ＲＳＵは。地域「Ｃ」でメッセージがブロードキャストされるようにメッセージをジオネットワーキング送信する。ＲＳＵがＭＣＭを送信する時点はｔ０であり、有効時間（validTimeUntil）情報はｔ５を示す。

車両（ａ）はＲＳＵからＭＣＭを受信し、ｔ＝２時点でＭＣＭをフォワーディングする。

車両（ｂ）は車両（ａ）からＭＣＭを受信し、ｔ＝４時点でＭＣＭをフォワーディングする。

車両（ｃ）は、車両（ｂ）からＭＣＭを受信し、まだメッセージが地域「Ｃ」に到着していないので、ＭＣＭをフォワーディングしなければならない。しかしながら、車両（ｃ）がＭＣＭをフォワーディングする時点はｔ０からｔ＝５が経過した。従って、車両（ｃ）はＭＣＭをフォワーディングしない。

マルチメディアコンテンツのサイズが特定基準より大きい場合、ＩＴＳ−Ｓは、マルチメディアコンテンツを１つのＭＣＭで送信する代わりに、複数のセグメントに分割し、複数のＭＣＭとして送信することができる。一度に送信できるメッセージの最大サイズはメッセージ送信に用いられるアクセスレイヤ技術に基づいて決定されることができる。送信に用いられるアクセスレイヤ技術の選択は、アプリケーションレイヤ、ファシリティレイヤ、ネットワーク／トランスポートレイヤ又はマネジメントエンティティの少なくとも１つにより行われることができる。

アクセスレイヤ技術が決定されると、最大メッセージサイズが決定される。また、各レイヤでＰＤＵ（Protocol Data Unit）を生成して下位レイヤに伝達する場合、以下のような方式が適用できる。

レイヤＡが最大メッセージサイズを知っている場合：下位レイヤで追加されるヘッダーサイズを予想して、最終的にエア（over-the-air）で送信されるメッセージサイズが最大メッセージサイズを超過しないレイヤＡの最大ＰＤＵのサイズを算出する。上位（upper）レイヤから受信した上位レイヤＰＤＵがレイヤＡの最大ＰＤＵサイズより大きい場合、レイヤＡの最大ＰＤＵサイズより小さくなるようにセグメントすることによりレイヤＡ ＰＤＵを生成する。また、生成されたレイヤＡ ＰＤＵを下位レイヤに伝達する。伝達された上位レイヤＰＤＵは、レイヤＡがアプリケーションレイヤである場合はメディアコンテンツファイルになることができる。

レイヤＡが最大メッセージサイズを知っていない場合：上位レイヤから受信した上位レイヤＰＤＵをセグメントせずにレイヤＡのＰＤＵを生成する。また、生成されたレイヤＡ ＰＤＵを下位レイヤに伝達する。伝達された上位レイヤＰＤＵは、レイヤＡがアプリケーションレイヤである場合はメディアコンテンツファイルになることができる。

図３７は、本発明の実施形態によるＶ２Ｘ通信装置を示す。

図３７において、Ｖ２Ｘ通信装置３７０００は、メモリ３７０１０、プロセッサ３７０２０及び通信ユニット３７０３０を含むことができる。前述したように、Ｖ２Ｘ通信装置は、ＯＢＵ（On Board Unit）又はＲＳＵ（Road Side Unit）に該当するか、ＯＢＵ又はＲＳＵに含まれることもできる。Ｖ２Ｘ通信装置はＩＴＳステーションに含まれるか、ＩＴＳステーションに該当することもできる。

通信ユニット３７０３０は、プロセッサ３７０２０に接続されて無線信号を送信／受信することができる。通信ユニット３７０３０は、プロセッサ３７０２０から受信したデータを送受信帯域にアップコンバートして信号を送信することができる。通信ユニットは、アクセスレイヤの動作を実現することができる。実施形態として、通信ユニットは、アクセスレイヤに含まれるフィジカルレイヤの動作を実現するか、さらにＭＡＣレイヤの動作を実現することもできる。通信ユニットは、複数の通信プロトコルによって通信を行うために複数のサブ通信ユニットを含むこともできる。

プロセッサ３７０２０は、通信ユニット３７０３０に接続されてＩＴＳシステム又はＷＡＶＥシステムによるレイヤの動作を実現することができる。プロセッサ３７０２０は、前述した図面及び説明による本発明の多様な実施形態による動作を行うように構成される。また、前述した本発明の多様な実施形態によるＶ２Ｘ通信装置３７０００の動作を実現するモジュール、データ、プログラム又はソフトウェアの少なくとも１つがメモリ３７０１０に保存され、プロセッサ３７０２０により実行できる。

メモリ３７０１０は、プロセッサ３７０２０に接続され、プロセッサ３７０２０を駆動するための様々な情報を保存する。メモリ３７０１０は、プロセッサ３７０２０の内部に含まれるか又はプロセッサ３７０２０の外部に設置されてプロセッサ３７０２０と公知の手段により接続される。メモリは、セキュリティ／非セキュリティ保存装置を含むか、セキュリティ／非セキュリティ保存装置に含まれることもできる。実施形態によって、メモリはセキュリティ／非セキュリティ保存装置と称されることもできる。

図３７のＶ２Ｘ通信装置３７０００の具体的な構成は、前述した本発明の多様な実施形態が独立して適用されるか、又は２以上の実施形態が共に適用されるように実現できる。

図２に関連して、ＧＮＳＳ受信機及びＤＳＲＤラジオは、図３７の通信ユニット３７０３０に含まれることができる。ＤＳＲＣデバイスプロセッサは、図３７の通信ユニット３７０３０に含まれるか、プロセッサ３７０２０に含まれることができる。

図３８は、本発明の実施形態によるＶ２Ｘ通信装置のマルチメディアコンテンツメッセージの受信方法を示す。

Ｖ２Ｘ通信装置は、マルチメディアコンテンツメッセージを受信することができる（Ｓ３８０１０）。Ｖ２Ｘ通信装置は、多様な通信プロトコルに基づいてマルチメディアコンテンツメッセージを受信することができる。

Ｖ２Ｘ通信装置は、マルチメディアコンテンツメッセージをパージングすることができる（Ｓ３８０２０）。Ｖ２Ｘ通信装置は、マルチメディアコンテンツメッセージをパージングし、メッセージに関する多様な情報を取得することができる。

Ｖ２Ｘ通信装置は、マルチメディアコンテンツ又はコンテンツセグメントを取得することができる（Ｓ３８０３０）。Ｖ２Ｘ通信装置は、前述したようにコンテンツ又はコンテンツセグメントを保存／プロセシングしてアプリケーションを介してユーザに提供することができる。また、Ｖ２Ｘ通信装置は、前述したようにメッセージに関する情報に基づいてコンテンツ又はコンテンツセグメントを保存／プロセシングせずに廃棄することができる。

マルチメディアコンテンツメッセージは、プロトコルバージョン及びメッセージＩＤを含むヘッダーと、ＭＣＭ（Multimedia Content Message）マネジメント及びＭＣＤ（Multimedia Content Dissemination）プロトコル関連情報を含むマネジメントコンテナと、イベントを記述する情報を含む状況（situation）コンテナと、前記イベントの位置情報を含む位置（location）コンテナと、前記マルチメディアコンテンツを含むマルチメディアコンテンツコンテナとの少なくとも１つを含む。

マネジメントコンテナは、マルチメディアコンテナに含まれるマルチメディアデータユニットの数を示すマルチメディアデータユニットの数（numberOfMultimediaUnit）情報、マルチメディアコンテナに含まれるマルチメディアコンテンツに対するマルチメディアフォーマットタイプ（multimediaFormatType）情報のうち少なくとも１つを含む。

マルチメディアコンテンツメッセージ及びマネジメントコンテナに関する説明は前述した通りである。

図１６〜図２０の実施形態に関して前述したように、マネジメントコンテナは、マルチメディアコンテンツ又はマルチメディアコンテンツのセグメントの少なくとも１つに関するサイズ情報をさらに含むことができる。Ｖ２Ｘ通信装置は、サイズ情報及びＶ２Ｘ通信装置のストレージ情報に基づいてマルチメディアコンテンツ又はマルチメディアセグメントを保存するか否か決定することができる。

図２１ないし図２５の実施形態に関連して前述したように、マネジメントコンテナは、マルチメディアコンテンツ識別子情報をさらに含むことができる。Ｖ２Ｘ通信装置は、マルチメディアコンテンツ識別子情報に基づいてマルチメディアコンテンツメッセージのマルチメディアコンテンツ又はセグメントが既に受信したマルチメディアコンテンツと重複しているか否かを決定することができる。

図２６ないし図２８の実施形態に関連して前述したように、マネジメントコンテナは、ＵＲＬ情報をさらに含むことができる。Ｖ２Ｘ通信装置は、ＵＲＬ情報が示すＵＲＬに接続してマルチメディアコンテンツを受信することができる。

図２９ないし図３３の実施形態に関連して前述したように、マネジメントコンテナは、マルチメディアコンテンツの言語を示す言語情報をさらに含むことができる。Ｖ２Ｘ通信装置は、言語情報に基づいてマルチメディアコンテンツの言語が許容可能（acceptable）言語であるか否かを決定することができる。

図３４ないし図３６の実施形態に関連して前述したように、マネジメントコンテナは、有効時間情報をさらに含むことができる。Ｖ２Ｘ通信装置は、有効時間情報に基づいてマルチメディアコンテンツを提供又はフォワーディングするか否かを決定することができる。

以上で説明された実施形態は本発明の構成要素と特徴が所定の形態に結合されたものである。各構成要素または特徴は別途の明示的な言及がない限り、選択的なものとして考慮されなければならない。各構成要素または特徴は他の構成要素や特徴と結合されない形態で実施できる。また、一部の構成要素及び／又は特徴を結合して本発明の実施形態を構成することも可能である。本発明の実施形態で説明される動作の順序は変更できる。ある実施形態の一部の構成や特徴は他の実施形態に含まれることができ、または他の実施形態の対応する構成または特徴と取替できる。特許請求の範囲で明示的な引用関係がない請求項を結合して実施形態を構成するか、または出願後の補正により新たな請求項に含めることができることは自明である。

本発明に従う実施形態は、多様な手段、例えば、ハードウェア、ファームウェア（firmware）、ソフトウェア、またはそれらの結合などにより実現できる。ハードウェアによる実現の場合、本発明の一実施形態は１つまたはその以上のＡＳＩＣｓ（application specific integrated circuits）、ＤＳＰｓ（digital signal processors）、ＤＳＰＤｓ（digital signal processing devices）、ＰＬＤｓ（programmable logic devices）、ＦＰＧＡｓ（field programmable gate arrays）、プロセッサ、コントローラ、マイクロコントローラ、マイクロプロセッサなどにより実現できる。

ファームウェアやソフトウェアによる実現の場合、本発明の一実施形態は以上で説明された機能または動作を実行するモジュール、手順、関数などの形態に実現できる。ソフトウェアコードはメモリに格納されてプロセッサにより駆動できる。前記メモリは前記プロセッサの内部または外部に位置し、既に公知された多様な手段により前記プロセッサとデータをやり取りすることができる。

本発明は、本発明の必須の特徴を逸脱しない範囲で他の特定の形態に具体化できることは通常の技術者に自明である。したがって、前述した詳細な説明は全ての面で制限的に解釈されてはならず、例示的なものとして考慮されなければならない。本発明の範囲は添付した請求項の合理的な解釈により決定されなければならず、本発明の等価的な範囲内での全ての変更は本発明の範囲に含まれる。

＜発明を実施するための形態＞
本発明の思想または範囲から逸脱することなく、本発明において多様な変更及び変形が可能であることは当業者に理解されるはずである。従って、本発明は、添付された請求項及びそれと同等の範囲内で提供される本発明の変更及び変形を含むことを意図する。

本明細書で装置及び方法の発明が全て言及され、装置及び方法の発明の両方の説明は、互いに補完して適用されることができる。

多様な実施形態が本発明を実施するための最善の形態で説明された。

本発明は、一連の車両通信分野において用いられる。

本発明の思想または範囲から逸脱することなく、本発明において多様な変更及び変形が可能であることは当業者にとって明らかである。従って、本発明は、添付された請求項及びそれと同等の範囲内で提供される本発明の変更及び変形を含むことを意図する。

Claims (12)

1. Ｖ２Ｘ（Vehicle to everything）通信装置のマルチメディアコンテンツメッセージの受信方法において、
   マルチメディアコンテンツメッセージを受信する段階と、
   前記マルチメディアコンテンツメッセージをパージングする段階と、
   前記マルチメディアコンテンツメッセージに含まれるマルチメディアコンテンツ又はマルチメディアコンテンツの一部であるコンテンツセグメントを取得する段階と、を含み、
   前記マルチメディアコンテンツメッセージは、プロトコルバージョン及びメッセージＩＤを含むヘッダーと、ＭＣＭ（Multimedia Content Message）マネジメント及びＭＣＤ（Multimedia Content Dissemination）プロトコル関連情報を含むマネジメントコンテナと、イベントを記述する情報を含む状況（situation）コンテナと、前記イベントの位置情報を含む位置（location）コンテナと、前記マルチメディアコンテンツを含むマルチメディアコンテンツコンテナとを含み、
   前記マネジメントコンテナは、前記マルチメディアコンテナに含まれるマルチメディアデータユニットの数を示すマルチメディアデータユニットの数（numberOfMultimediaUnit）情報と、前記マルチメディアコンテナに含まれる前記マルチメディアコンテンツに対するマルチメディアフォーマットタイプ（multimediaFormatType）情報とを含むことを特徴とする、マルチメディアコンテンツメッセージの受信方法。
2. 前記マネジメントコンテナは、前記マルチメディアコンテンツ又は前記マルチメディアコンテンツのセグメントの少なくとも１つに関するサイズ情報をさらに含み、
   前記マルチメディアコンテンツメッセージの受信方法は、前記サイズ情報及び前記Ｖ２Ｘ通信装置のストレージ情報に基づいて前記マルチメディアコンテンツ又はコンテンツセグメントを保存するか否か決定する段階をさらに含むことを特徴とする、請求項１に記載のマルチメディアコンテンツメッセージの受信方法。
3. 前記マネジメントコンテナは、マルチメディアコンテンツ識別子情報をさらに含み、
   前記マルチメディアコンテンツメッセージの受信方法は、前記マルチメディアコンテンツ識別子情報に基づいて前記マルチメディアコンテンツメッセージのマルチメディアコンテンツ又はコンテンツセグメントが既に受信したマルチメディアコンテンツと重複するか否かを決定する段階をさらに含むことを特徴とする、請求項１に記載のマルチメディアコンテンツメッセージの受信方法。
4. 前記マネジメントコンテナは、ＵＲＬ情報をさらに含み、
   前記マルチメディアコンテンツメッセージの受信方法は、前記ＵＲＬ情報が示すＵＲＬに接続して前記マルチメディアコンテンツを受信する段階をさらに含むことを特徴とする、請求項１に記載のマルチメディアコンテンツメッセージの受信方法。
5. 前記マネジメントコンテナは、前記マルチメディアコンテンツの言語を示す言語情報をさらに含み、
   前記マルチメディアコンテンツメッセージの受信方法は、前記言語情報に基づいて前記マルチメディアコンテンツの前記言語が許容可能（acceptable）言語であるか否かを決定する段階をさらに含むことを特徴とする、請求項１に記載のマルチメディアコンテンツメッセージの受信方法。
6. 前記マネジメントコンテナは、有効時間情報をさらに含み、
   前記マルチメディアコンテンツメッセージの受信方法は、前記有効時間情報に基づいて前記マルチメディアコンテンツを提供又はフォワーディングするか否かを決定する段階をさらに含むことを特徴とする、請求項１に記載のマルチメディアコンテンツメッセージの受信方法。
7. Ｖ２Ｘ通信装置において、
   データを保存するメモリと、
   無線信号を送受信する通信ユニットと、
   前記通信ユニットを制御するプロセッサと、を含み、
   前記Ｖ２Ｘ通信装置は、
   マルチメディアコンテンツメッセージを受信し、
   前記マルチメディアコンテンツメッセージをパージングし、
   前記マルチメディアコンテンツメッセージに含まれるマルチメディアコンテンツ又はマルチメディアコンテンツの一部であるコンテンツセグメントを取得し、
   前記マルチメディアコンテンツメッセージは、プロトコルバージョン及びメッセージＩＤを含むヘッダーと、ＭＣＭ（Multimedia Content Message）マネジメント及びＭＣＤ（Multimedia Content Dissemination）プロトコル関連情報を含むマネジメントコンテナと、イベントを記述する情報を含む状況（situation）コンテナと、前記イベントの位置情報とを含む位置（location）コンテナと、前記マルチメディアコンテンツを含むマルチメディアコンテンツコンテナとを含み、
   前記マネジメントコンテナは、前記マルチメディアコンテナに含まれるマルチメディアデータユニットの数を示すマルチメディアデータユニットの数（numberOfMultimediaUnit）情報と、前記マルチメディアコンテナに含まれる前記マルチメディアコンテンツに対するマルチメディアフォーマットタイプ（multimediaFormatType）情報とを含むことを特徴とする、Ｖ２Ｘ通信装置。
8. 前記マネジメントコンテナは、前記マルチメディアコンテンツ又は前記マルチメディアコンテンツのセグメントの少なくとも１つに関するサイズ情報をさらに含み、
   前記Ｖ２Ｘ通信装置は、前記サイズ情報及び前記Ｖ２Ｘ通信装置のストレージ情報に基づいて前記マルチメディアコンテンツ又はコンテンツセグメントを保存するか否か決定することを特徴とする、請求項７に記載のＶ２Ｘ通信装置。
9. 前記マネジメントコンテナは、マルチメディアコンテンツ識別子情報をさらに含み、
   前記Ｖ２Ｘ通信装置は、前記マルチメディアコンテンツ識別子情報に基づいて前記マルチメディアコンテンツメッセージのマルチメディアコンテンツ又はコンテンツセグメントが既に受信したマルチメディアコンテンツと重複しているか否かを決定することを特徴とする、請求項７に記載のＶ２Ｘ通信装置。
10. 前記マネジメントコンテナは、ＵＲＬ情報をさらに含み、
    前記Ｖ２Ｘ通信装置は、前記ＵＲＬ情報が示すＵＲＬに接続して前記マルチメディアコンテンツを受信することを特徴とする、請求項７に記載のＶ２Ｘ通信装置。
11. 前記マネジメントコンテナは、前記マルチメディアコンテンツの言語を示す言語情報をさらに含み、
    前記Ｖ２Ｘ通信装置は、前記言語情報に基づいて前記マルチメディアコンテンツの前記言語が許容可能（acceptable）言語であるか否かを決定することを特徴とする、請求項７に記載のＶ２Ｘ通信装置。
12. 前記マネジメントコンテナは、有効時間情報をさらに含み、
    前記Ｖ２Ｘ通信装置は、前記有効時間情報に基づいて前記マルチメディアコンテンツを提供又はフォワーディングするか否かを決定することを特徴とする、請求項７に記載のＶ２Ｘ通信装置。

Images