(57)【要約】【課題】  無線通信装置間でマルチホップ無線通信を行う際に、より効率的に安定した無線通信を行うことができる【解決手段】  本発明は、無線通信装置に関する。そして、無線通信装置は、データ伝達方向により異なる通信方式により無線通信を行ない、受信したデータを中継転送する際に、自装置が中継転送しようとするデータと、当該データ受信とは異なる通信方式で受信したデータをネットワークコーディングし、そのネットワークコーディングにより得られたネットワークコーディングデータを中継転送することを特徴とする。【選択図】      図１
2015162878.tif 000002
【特許請求の範囲】
【請求項１】
データ伝達方向により異なる通信方式により無線通信を行ない、受信したデータを中継転送する際に、自装置が中継転送しようとするデータと、当該データ受信とは異なる通信方式で受信したデータをネットワークコーディングし、そのネットワークコーディングにより得られたネットワークコーディングデータを中継転送する無線通信手段
を有することを特徴とする無線通信装置。
【請求項２】
第１の伝達方向の中継転送に係る第１の通信方式で受信した受信情報を一時的に保留して、ネットワークコーディングに適用するためのバッファ手段をさらに備え、
上記無線通信手段は、第２の伝達方向にのみ中継転送が発生し上記バッファ手段の保留状態が空の場合には、予め既定したダミーデータを用いてネットワークコーディングを行う
ことを特徴とする請求項１に記載の無線通信装置。
【請求項３】
上記無線津新手段は、ネットワークコーディングを行おうとする際に、上記バッファ手段の保留状態が空の場合、所定期間待機し、待機した結果上記第１の伝達方向の中継転送が発生して上記バッファ手段に受信情報が保留された場合、その受信情報を用いて、ネットワークコーディングを行うことを特徴とする請求項２に記載の無線通信装置。
【請求項４】
上記無線通信手段は、データ伝達方向に応じて異なるプロトコルを用いて無線通信を行うことを特徴とする請求項１に記載の無線通信装置。
【請求項５】
上記無線通信手段は、マルチホップ通信に係る中継転送を行なう際、次ホップの無線通信装置がさらに中継転送したか否かによって、次ホップの無線通信装置への中継転送が成功したか否かを判断する確認応答代替処理を行うことを特徴とする請求項４に記載の無線通信装置。
【請求項６】
自装置を宛先とするデータを受信した場合、当該データの送信元の方向へ中継転送するデータに対して、当該データを正しく受信したことを知らせるフラグを付加することを特徴とする請求項４又は５に記載の無線津新装置。
【請求項７】
無線通信装置が行う無線通信方法において、
無線通信手段を備え、
データ伝達方向により異なる通信方式により無線通信を行ない、受信したデータを中継転送する際に、自装置が中継転送しようとするデータと、当該データ受信とは異なる通信方式で受信したデータをネットワークコーディングし、そのネットワークコーディングにより得られたネットワークコーディングデータを中継転送する
ことを特徴とする無線通信方法。
【請求項８】
複数の無線通信装置を備える通信システムにおいて、それぞれの上記無線通信装置として請求項１〜６のいずれかに記載の無線通信装置を備えることを特徴とする通信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信装置及び通信方法、並びに通信システムに関し、例えば、車両に搭載した無線通信装置により形成されるアドホックネットワークに適用し得る。
【背景技術】
【０００２】
空間ブロック符号化（ＳＴＢＣ：Ｓｐａｃｅ−Ｔｉｍｅ  Ｂｌｏｃｋ  Ｃｏｄｉｎｇ）とＭＩＭＯ（Ｍｕｌｔｉｐｌｅ  Ｉｎｐｕｔ  Ｍｕｌｔｉｐｌｅ  Ｏｕｔｐｕｔ）を使った上で、ネットワークコーディングを行なうことで、高効率・高信頼の双方向無線通信中継伝送を行なう方法が、特許文献１に記載されている。ＭＩＭＯ及びＳＴＢＣを搭載していない無指向性アンテナ利用アドホック無線通信システムには適していない。
【０００３】
指向性アンテナを用いた場合に発生する隠れ端末問題（デフネス問題）の対策として、ＲＴＳ／ＣＴＳ（Ｒｅｑｕｅｓｔ  Ｔｏ  Ｓｅｎｄ  ／Ｃｌｅａｒ  Ｔｏ  Ｓｅｎｄ）をベースとする手法が提案されている（非特許文献１）が、特許文献２、特許文献３では、不明確であり、このデフネス問題からも、車両アドホック無線通信にそのまま適用とはいかない。
【０００４】
非特許文献２では、双方向トラフィック通信において、ネットワークコーディングを適用して、特性を改善する手法として、データを一括伝送し、Ｂｌｏｃｋ  Ａｃｋを返信する方法が提案されている。しかしながら、音声通話の様に、双方向でかつ、リアルタイム性が要求される場合、例えば、ＶｏＩＰ（Ｇ．７２６（ＡＤＰＣＭ：Ａｄａｐｔｉｖｅ  Ｄｉｆｆｅｒｅｎｔｉａｌ  Ｐｕｌｓｅ  Ｃｏｄｅ  Ｍｏｄｕｌａｔｉｏｎ））では２０ｍｓｅｃ間隔で８０Ｂｙｔｅのデータを送信する必要があり（非特許文献４に各種コーデックのデータサイズ、送信頻度が記載あり）、一括伝送すると、許容遅延をこえてしまう、遅延時間の変動が大きい、スループットが低下してしまう可能性があり、車々間のアドホック無線通信にそのまま適用とはいかない。
【０００５】
特許文献４では、送信レートの異なるリンクに対して、ネットワークコーディングする方法が述べられている。特許文献４の課題・解決手段は本件の課題・解決手段とは異なり、車両アドホック無線通信にそのまま適用しても、車々間のアドホック無線通信でのスループット向上の効果は少ない。
【０００６】
ネットワークコーディングでは、中継局において受信したパケットのいずれか、もしくは全てに誤りがあった場合、ネットワークコーディングを行なうことで正しく受信した誤りがないパケットにも誤り伝搬が発生し、全ての端末において必ず誤りが発生してしまうことが、特許文献５に記載されている（特許文献５の段落「００１０」参照）。そのために、特許文献５ではＩＰ層でのネットワークコーディングとＰＨＹ層でのネットワークコーディングのハイブリッド化を行なった手法が記載されている（特許文献５、非特許文献３）。しかしながら、現在、車々間通信の仕様として、ガイドライン化が進んでいる（ＡＲＩＢ  ＳＴＤ−Ｔ１０９、ＲＣ−００５）の仕様では、必ずしもＩＰ層を持っているとは限らない、ＰＨＹ層にまで修正が必要になり、そのまま適用とはいかない。また、ネットワークコーディングをＩＰ層だけではなく、ＰＨＹ層においても行なう必要があり、処理時間がかかってしまう。
【０００７】
特許文献６によると、混信防止を目的として、車両の進行方向の方位によって、異なる無線周波数を設定すると記載されている（段落「００４２」「００９１」参照）。また、特許文献中の図３を見ると、ＣＨ１からＣＨ１４まで使用する旨が記載されている。これは、日本の５．８  ＧＨｚ  ＤＳＲＣ  Ｕｐｌｉｎｋ  ７チャネル、Ｄｏｗｎ  ｌｉｎｋ  ７チャネル分の全てを使用する方法と考えられる。この方法では、１４ＣＨ分の無線機を用意する必要がある。また、自車両は１ＣＨのみで送信するが、周辺の状況を監視するという意味では全ての周波数チャネルを監視する必要がある（消費電力もｎ倍必要になる）。
【０００８】
特許文献７によると、無線の中継装置で、中継送信アンテナと中継受信アンテナについて相互方向に指向性を持たせる方法について、記載されているが、ＭＩＭＯ伝送方式を用いる必要がある。本発明はＡＲＩＢ  Ｔ７５、Ｔ１０９、５．８ＧＨｚ帯１１ｐの様な既に実用化されているもの、あるいは近い将来実用化（車両無線装置として）されるもの、また、一般的な無線ＬＡＮ（Ｗｉ−Ｆｉ）を想定している。これらの無線機には、ＭＩＭＯ伝送機能は組込まれていない。よって、ネットワーク制御部を追加するのみで対応が可能であるが、ＭＩＭＯ伝送装置では、全ての装置を入れ替えになることから、特許文献７をそのまま適用するには難しい。
【０００９】
特許文献８によると、順方向中継と逆方向中継で異なる周波数を使用するようにした無線中継装置（段落「００７１」参照）では、位置情報を用いずに、異なる周波数を使用する記載であるが、特許文献８では、干渉抑制のために、異なる周波数を用いることが目的であるが、本件では、ネットワークコーディング化によって、帯域を増やすことなく、２回送信した場合と同等の効果が得られる。そのために、単に、周波数チャネルを分けるだけでは、不十分である。
【先行技術文献】
【特許文献】
【００１０】
【特許文献１】特開２００９−２３２４４０号公報
【特許文献２】特開２０１１−２５００１４号公報
【特許文献３】特開２００９−２２５０６３号公報
【特許文献４】特開２０１２−１２００７２号公報
【特許文献５】特開２０１１−８２８２１号公報
【特許文献６】特開２００７−１０８８３７号公報
【特許文献７】特開２００６−１４８４８２号公報
【特許文献８】特開２００１−１４４６６４号公報
【非特許文献】
【００１１】
【非特許文献１】横田翔子、萬代雅希、渡辺尚、「隠れ端末及びデフネス問題を解決する指向性ＭＡＣプロトコルについて」、“マルチメディア、分散、協調とモバイル  （ＤＩＣＯＭＯ  ２００９）  シンポジウム”、Ｐ５８５−５９２、平成２１年７月発行
【非特許文献２】原田諭、宮本伸一、三瓶政一、“マルチホップ無線ネットワークにおける双方向トラヒックのネットワークコーディング適用による伝送特性の改善効果に関する検討，”、信学技報、ＩＮ２００６−１１５、ｐｐ．７−１２、Ｄｅｃ．  ２００６．
【非特許文献３】大槻暢明、浅井裕介、杉山隆利著、「高効率マルチホップ無線システムを実現する無線ネットワークコーディング技術の研究開発」、ＮＴＴ技術ジャーナル、日本電信電話株式会社、２００９年１２月発行
【非特許文献４】Ｎｅｗｐｏｒｔ  Ｎｅｔｗｏｒｋｓ，「ＶｏＩＰ  Ｂａｎｄｗｉｄｔｈ  Ｃａｌｃｕｌａｔｉｏｎ」，[Online]，INTERNET，[２０１４年２月７日検索]，＜ＵＲＬ：http://www.cs.ru.ac.za/courses/honours/RTMM/software/52-VoIP-Bandwidth.pdf＞
【非特許文献５】一般社団法人電波産業会編，「ＡＲＩＢ  ＳＴＤ−Ｔ１０９  ７００  ＭＨｚ帯高度道路交通システム  ２０１２年２月  １．０版策定」，[Online]，INTERNET，[２０１４年２月７日検索]，＜ＵＲＬ：http://www.arib.or.jp/english/html/overview/doc/1-STD-T109v1_0.pdf＞
【非特許文献６】ＩＴＳ情報通信システム推進会議編，「５．８ＧＨｚを用いた車々間通信システムの実験用ガイドライン  ＩＴＳ  ＦＯＲＵＭ  ＲＣ−００５  １．０版」，[Online]，INTERNET，[２０１４年２月７日検索]，＜ＵＲＬ：http://www.itsforum.gr.jp/Public/J7Database/p32/ITSFORUMRC005V1_0.pdf＞
【発明の概要】
【発明が解決しようとする課題】
【００１２】
ところで、ＩＴＳ（Ｉｎｔｅｌｌｉｇｅｎｔ  Ｔｒａｎｓｐｏｒｔ  Ｓｙｓｔｅｍｓ）の動向から想定すると、将来、車々間通信には、５．８ＧＨｚ帯か７６０ＭＨｚを利用することが考えられる。あるいは、車々間通信には、将来Ｗｉ−ｆｉを用いて２．４  ＧＨｚ帯、５ＧＨｚ帯も想定される。また、１４ＣＨのうち、４ＣＨは現在ＥＴＣで使用されている。これらは一例であるが、このような帯域を利用して、マルチホップ通信を行うことを考える。
【００１３】
ここで、マルチホップ通信時には、トラフィックが増大することから、中継点においてボトルネックが発生してしまい通信品質が劣化することが考えられる。このため、マルチプロトコル化、ネットワークコーディング、転送パケット受信によるＡｃｋ軽減の手法を利用して、トラフィック量の軽減・安定化をはかることが望まれる。
【００１４】
言い換えると、上述のような問題点に鑑みて、無線通信装置間でマルチホップ無線通信を行う際に、より効率的に安定した無線通信を行うことができる通信装置及び通信方法、並びに通信システムが望まれている。
【課題を解決するための手段】
【００１５】
第１の本発明の無線通信装置は、データ伝達方向により異なる通信方式により無線通信を行ない、受信したデータを中継転送する際に、自装置が中継転送しようとするデータと、当該データ受信とは異なる通信方式で受信したデータをネットワークコーディングし、そのネットワークコーディングにより得られたネットワークコーディングデータを中継転送する無線通信手段を有することを特徴とする。
【００１６】
第２の本発明は、無線通信装置が行う無線通信方法において、データ伝達方向により異なる通信方式により無線通信を行ない、受信したデータを中継転送する際に、自装置が中継転送しようとするデータと、当該データ受信とは異なる通信方式で受信したデータをネットワークコーディングし、そのネットワークコーディングにより得られたネットワークコーディングデータを中継転送することを特徴とする。
【００１７】
第３の本発明は、複数の無線通信装置を備える通信システムにおいて、それぞれの上記無線通信装置として第１の本発明の無線通信装置を備えることを特徴とする。
【発明の効果】
【００１８】
本発明によれば、無線通信装置間でマルチホップ無線通信を行う際に、より効率的に安定した無線通信を行うことができる。
【図面の簡単な説明】
【００１９】
【図１】第１の実施形態に係る端末（車両に搭載される端末）の機能的構成について示したブロック図である。
【図２】第１の実施形態に係る通信システムの全体構成について示したブロック図である。
【図３】第１の実施形態に係る端末（車両に搭載される端末）のハードウェア構成について示したブロック図である。
【図４】第１の実施形態に係る通信システムの動作概要について示した説明図（その１）である。
【図５】第１の実施形態に係る通信システムの動作概要について示した説明図（その２）である。
【図６】第１の実施形態に係る通信システムの動作詳細について示した説明図（その１）である。
【図７】第１の実施形態に係る通信システムの動作詳細について示した説明図（その２）である。
【図８】第１の実施形態に係る通信システムの端末間で送受信されるパケットフォーマットについて示した説明図である。
【図９】第１の実施形態に係る通信システムの端末間で行われるマルチプロトコル＆ネットワークコーディング通信処理の詳細について示した説明図である。
【図１０】第１の実施形態に係る通信システムの端末間で行われるマルチプロトコル＆ネットワークコーディング通信処理の詳細について示したシーケンス図である。
【図１１】第１の実施形態に係る通信システムを構成する端末がパケット送信する際の動作について示したフローチャート（その１）である。
【図１２】第１の実施形態に係る通信システムを構成する端末がパケット送信する際の動作について示したフローチャート（その２）である。
【図１３】第１の実施形態に係る通信システムを構成する端末で行われるプロトコル選択処理について示した説明図である。
【図１４】第１の実施形態に係る通信システムを構成する端末がパケット受信する際の動作について示したフローチャート（その１）である。
【図１５】第１の実施形態に係る通信システムを構成する端末がパケット受信する際の動作について示したフローチャート（その２）である。
【図１６】第１の実施形態に係る通信システムを構成する端末がパケット受信する際の動作について示したフローチャート（その３）である。
【図１７】第１の実施形態に係る端末で表示される表示画面の構成例について示した説明図である。
【図１８】第２の実施形態に係る通信システムの全体構成について示したブロック図である。
【図１９】第２の実施形態に係る通信システムを構成する端末の動作概要について示した説明図（その１）である。
【図２０】第２の実施形態に係る通信システムを構成する端末の動作概要について示した説明図（その２）である。
【図２１】第３の実施形態に係る通信システムの全体構成について示したブロック図である。
【図２２】第３の実施形態に係る通信システムを構成する端末の動作概要について示した説明図である。
【図２３】第３の実施形態に係る通信システムを構成する端末がパケット送信する際の動作について示したフローチャートである。
【発明を実施するための形態】
【００２０】
（Ａ）第１の実施形態
以下、本発明による通信装置及び通信方法、並びに通信システムの第１の実施形態を、図面を参照しながら詳述する。以下では、本発明の通信装置を「端末」に適用した例について説明する。
【００２１】
（Ａ−１）第１の実施形態の構成
図２は、この実施形態の通信システム１０００の全体構成を示すブロック図である。
【００２２】
通信システム１０００は、無線マルチホップネットワークであり、無線マルチホップ通信を行う端末１００（１００−Ａ、１００−Ｂ、１００−Ｃ）により構成されているものとするなお、通信システム１０００を構成する端末１００の数や配置位置等は限定されないものである。また、以下では、端末１００−Ａ、１００−Ｂ、１００−Ｃを、それぞれ、端末Ａ、端末Ｂ、端末Ｃとも呼ぶものとする。また、端末１００−Ａ〜１００−Ｃは、それぞれ車両に搭載されているものとする。そして、以下では、端末１００−Ａ〜１００−Ｃを搭載する車両を、それぞれ車両Ａ〜車両Ｃと呼ぶものとする。ここでは、各端末１００は全て同じ構成であるものとする。
【００２３】
図３は、各端末１００のハードウェア構成について示したブロック図である。
【００２４】
端末１００は、第１の無指向性アンテナ１１１、第２の無指向性アンテナ１１２、第１の無線ユニット１２１、第２の無線ユニット１２２、Ｌ３スイッチ１３０、ＧＰＳ装置１４０、及びネットワーク制御部１５０を有している。
【００２５】
第１の無指向性アンテナ１１１、第２の無指向性アンテナ１１２は、それぞれ、任意の２つのプロトコル（以下、この２つのプロトコルを「プロトコル１」、「プロトコル２」と呼ぶ）に係る電波送受信を行うためのアンテナである。
【００２６】
第１の無線ユニット１２１、第２の無線ユニット１２２は、それぞれ、それぞれ、プロトコル１、プロトコル２に係る無線信号の送受信処理（第１の無指向性アンテナ１１１、又は第２の無指向性アンテナ１１２を用いた無線信号の送受信処理）を行うものである。
【００２７】
Ｌ３スイッチ1３０は、端末１００内部でのフレーム転送処理を実行するものである。この実施形態では、端末１００は、第１の無線ユニット１２１、第２の無線ユニット１２２、及びネットワーク制御部１５０の間のフレーム転送処理を実行する。この実施形態では、はネットワーク制御部１５０と各無線ユニットはＬ３スイッチ１３０を介して接続されているが、例えば、同一プロトコルで、時間軸チャネルを使用する、あるいは異なる周波数チャネルを使用する場合、あるいは複数のプロトコルであるが、インターフェイスを専用にする場合には、Ｌ３スイッチ１３０を用いなくても良い。
【００２８】
ネットワーク制御部１５０は、端末１００に係る通信制御処理を実行するものである。端末１００の内部構成については後述する。
【００２９】
ＧＰＳ装置１４０は、当該端末１００の位置情報取得等のＧＰＳ（Ｇｌｏｂａｌ  Ｐｏｓｉｔｉｏｎｉｎｇ  Ｓｙｓｔｅｍ）に係る処理を行うものである。ネットワーク制御部１５０にＧＰＳ装置１４０を接続しているのは、車載端末の位置情報を利用して、周辺の車両との位置関係を把握するためであり、単にマルチホップのネットワークトポロジー状態を把握するのみであれば、必須ではない。
【００３０】
図１は、端末１００の機能的構成について示したブロック図であり、上述の図３と同一又は対応する部分には、同一又は対応する符号を付している。
【００３１】
図２に示すように、端末１００は、機能的に、プロトコル１のパケット組立や送信処理を行う第１の送信信号処理部１２６、送信信号処理部１２６から供給されたパケットを電気信号に変換して第１の無指向性アンテナ１１１を用いて電波送信を行う第１の物理送信部１２３、プロトコル２のパケット組立や送信処理を行う第２の信号送信処理部１２８、第２の信号送信処理部１２８から供給されたパケットのデータを電気信号に変換して第２の無指向性アンテナ１１２を用いて電波送信を行う第２の物理送信部１２５を有している。また、端末１００は、機能的に、第１の無指向性アンテナ１１１又は第２の無指向性アンテナ１１２で捕捉した電波に含まれる信号（電気信号）を取得する第１・第２の物理受信部１２４、第１・第２の物理受信部１２４が取得した信号から、プロトコル１及びプロトコル２のパケットを抽出する第１・第２の信号受信処理部１２７を有している。
【００３２】
なお、第１・第２の信号受信処理部１２７では、プロトコル１、プロトコル２について受信処理を行うものとして説明するが、当該端末１００が対応するプロトコルの数に応じて対応するプロトコルについても変更するようにしてもよい。なお、第１・第２の信号受信処理部１２７は、予め、経路が固定状態になっており、（例えば、経路構築後、一時的、あるいは一定期間の間、車両は移動させない等）使用するプロトコルが限定されるのであれば、全てのプロトコルを受信する必要はなく、必要なプロトコルのみを受信状態にしても良い。
【００３３】
なお、上述の第１の物理送信部１２３、第１・第２の物理受信部１２４、第２の物理送信部１２５、第１の送信信号処理部１２６、第１・第２の信号受信処理部１２７、及び第２の信号送信処理部１２８は、第１の無線ユニット１２１及び第２の無線ユニット１２２により構成されている。
【００３４】
図１に示すように、ネットワーク制御部１５０は、マルチホップ制御部１５１、プロトコル選択部１５２、周辺端末監視部１５３、自端末情報部１５４、バッファ１５５、ＮＣ符号化部１５６、及びＮＣ復号部１５７を有している。なお、ここでＮＣとはネットワークコーディングの略である。また、ネットワーク制御部１５０では、送信情報１５８、受信情報１５９の情報が、制御処理に用いられる。 
ネットワーク制御部１５０は、自局が送信元、あるいは、中継局となり、送信する送信情報１５８とバッファ１５５の情報の排他的論理和演算を行なってＮＣ符号化部１５６でネットワークコーディング（ネットワーク符号化）したデータを取得して、パケット送信する。また、ネットワーク制御部１５０は、マルチホップ通信を行なう際、常にネットワークコーディングを行なうのではなく、所定の条件に応じて、ネットワークコーディングの処理を行なうか否かの判断をする。ネットワーク制御部１５０がネットワークコーディングを行う条件については後述する。
【００３５】
受信情報１５９は、自端末宛の情報であれば、上位層１６０（アプリケーション等の上位層の構成要素）へ供給される情報である。先に記載した様に、上位層１６０（アプリケーション）の利用の仕方によっては、ＧＰＳ装置１４０は必須ではない。
【００３６】
ＮＣ符号化部１５６はネットワークコーディング符号化を行うものであり、ＮＣ復号部１５７はネットワークコーディング復号を行うものである。ＮＣ符号化部１５６及びＮＣ復号部１５７の処理詳細については後述する。
【００３７】
ネットワーク制御部１５０は、受信側の処理では、送信側と逆の処理を行なう必要があり、プロトコル１あるいは、プロトコル２を通して、受信した情報とバッファ１５５に一時保存されている情報とで、排他的論理和演算を行なって、元の情報を得る。ネットワーク制御部１５０は、受信側の処理では、ネットワーク復号処理を行なう際、パケットによって、処理を行なっている場合と行なっていない場合があり、この条件判定についても後述する。
【００３８】
（Ａ−２）第１の実施形態の動作
次に、以上のような構成を有する第１の実施形態の通信システム１０００の動作を説明する。
【００３９】
まず、ネットワークコーディングの例について図４、図５を用いて説明する。なお、図４、図５では、端末１００−Ａ〜１００−Ｃ（端末Ａ、端末Ｂ、端末Ｃ）について、それぞれ円にＡ、Ｂ、又はＣのいずれかを付した図形で表している。
【００４０】
図４に示す図４（ａ）〜図４（ｄ）は、それぞれ、端末１００−Ａ〜１００−Ｃでネットワークコーディングが行われない場合の処理について示している。図５は、端末１００−Ａ〜１００−Ｃでネットワークコーディングが行われる場合の処理の例について示している。
【００４１】
まず、時刻Ｔにおいて、端末Ａが端末Ｂ宛にパケットαを送信したものとする（図４（ａ）参照）。
【００４２】
次に、時刻２Ｔにおいて、端末Ｂがパケットαを端末Ｃ宛に送信したものとする（図４（ｂ））。
【００４３】
次に、時刻３Ｔにおいて、端末Ｃが端末Ｂ宛にパケットβを送信し（図４（ｃ）参照）、時刻４Ｔにおいて、端末Ｂは端末Ａ宛にパケットβを送信したものとする（図４（ｄ）参照）。なお、端末Ａ、Ｂ、Ｃの間において、経路検索は、種々の経路制御（例えば、ＡＯＤＶ、ＯＬＳＲ等）により、経路構築された状態とする。上記に記載した様に、端末Ｂを中継端末として、端末Ａ及び端末Ｃは、それぞれの宛先である端末Ｃ及び端末Ａに対して、マルチホップ通信が可能になる。図４において、α、β及びγはパケット中のデータ、即ち、アプリケーションデータ（ＬＳＤＵ（ＬＬＣ  Ｓｅｒｖｉｃｅ  Ｄａｔａ  Ｕｎｉｔ）部）を意味し、ネットワーク符号化・復号処理、即ち、排他的論理和演算を行なうのは、アプリケーションデータ部のみである。図４ではネットワーク処理を説明するために簡略している。しかし、実際に空中を飛び交っているパケットは、ＬＳＤＵ部に、ＰＲ、ＵＷ、ＭＡＣヘッダ等を付加した状態で送受信するものとする。
【００４４】
端末Ａ、Ｂ、Ｃ間での具体的なパケットフォーマットについては後述する。
【００４５】
次に、通信システム１０００において、ネットワークコーディングを用いて、マルチホップ通信を行なう通信例について、図５を用いて説明する。
【００４６】
ここでは、端末Ａ、Ｂ、Ｃ間での経路制御は種々の方式のいずれかを採用して構築済であるものとする。また、端末Ａは端末Ｃ宛に、端末Ｃは端末Ａ宛にパケットをマルチホップ通信するとする。
【００４７】
まず、時刻Ｔにおいて、端末Ａが端末Ｂに向けて、パケットαを送信したものとする（図５（ａ）参照））。
【００４８】
次に、時刻２Ｔに、端末Ｃが端末Ｂ宛にパケットβを送信したものとする（図５（ｂ）参照）。このとき、端末Ｂは２つの端末から受信したパケットの排他的論理和を取り（γ＝α  ＸＯＲ  β）、パケットγを送信する（図５（ｃ）参照）。上記と同様に、α、β及びγは、パケット中のＬＳＤＵ部分を意味しているが、空間で飛び交っているものは、ＰＲ、ＵＷ、ＭＡＣヘッダ部等を含むパケットである。端末Ａでは、自身が送信したパケットのデータがαであると認識しており、下記の（１）式により、端末Ｃから送られた情報βを取得することができる。
【００４９】
（受信パケット）ＸＯＲ（既知情報）＝γ  ＸＯＲ  α  ＝β  …（１）
同様に端末Ｃは自身が送信したパケットのデータがβであると認識しており、以下の（２）式で、端末Ａから送られた情報αを取得することができる。
【００５０】
（受信パケット）ＸＯＲ（既知情報）＝γ  ＸＯＲ  β＝α  …（２）
ここで、上記の（１）式、（２）式の簡単な具体例を示す。端末Ａから、（１０１１）（４ビットのｂｉｎａｒｙの情報）を、端末Ｂを経由して、端末Ｃ宛に届けるとする。また、端末Ｃから、（１００１）（４ビットのｂｉｎａｒｙ）の情報を、端末Ｂを経由して、端末Ａ宛に届けるとする。よって、端末Ｂでは、ネットワークコーディングしたγとして（１０１１）ＸＯＲ（１００１）＝（００１０）を送信することになる。よって、端末Ａでは、ネットワークコーディングによって、（００１０）ＸＯＲ（１０１１）＝（１００１）をネットワークコーディング復号できる。また、端末Ｃでは、ネットワークコーディングによって、（００１０）ＸＯＲ（１００１）＝（１０１１）をネットワークコーディング復号できる。
【００５１】
次に、図６〜図８を用いて、通信システム１０００を構成する端末１００−Ａ〜１００−Ｃ（端末Ａ、端末Ｂ、端末Ｃ）の動作詳細について説明する。
【００５２】
図６（ａ）は、通信システム１０００を構成する端末１００−Ａ〜１００−Ｃ（端末Ａ〜端末Ｃ）のトポロジ構成図である。ここでは、図６（ａ）に示すように送信元は端末Ａ及び端末Ｃ、端末Ｂは中継局である。なお、図６〜図８では、簡単化のために、ネットワークコーディング処理する際の片方の符号はα、βで記載した。
【００５３】
図６（ｂ）及び図６（ｃ）は、通信システム１０００（端末Ａ〜端末Ｃ）において、ネットワークコーディングを用いない場合で、Ａｃｋを送信しない場合とＡｃｋを送信する場合のパケット送受信の簡易的な手順と発生パケット数を記載したタイミングチャートである。
【００５４】
図７（ａ）は、図６（ａ）と比較して、通信システム１０００（端末Ａ〜端末Ｃ）において、通常のネットワークコーディングを行なった場合の動作について示したタイミングチャートである。図７（ａ）の例では、図６（ａ）、図６（ｂ）と比較して、発生パケットが１個削減（４個から３個に削減）可能になるために、２５％トラフィックが軽減できる。
【００５５】
図７（ｂ）では、図７（ａ）の通常ネットワークコーディングの処理をさらに拡張した処理（以下、「マルチプロトコル＆ネットワークコーディング通信処理」と呼ぶ）を適用した例となっている。
【００５６】
図７では、時刻Ｔにおいて、端末ＡはＤａｔａ＿ａを送信している。また、端末Ｂは端末Ａのパケットを受信後、自身は先に記載したルーティングアルゴリズムで、中継端末である旨は認識しており、Ｄａｔａ＿ａとαをネットワークコーディングした後、端末Ｃへ送信する（時刻２Ｔ）。
【００５７】
本来、端末Ｂが送信したパケットを端末Ａは復調しないが、このパケットを受信・復調することで、Ａｃｋの代用とすることができ（図７（ｂ）中の一点鎖線）、Ａｃｋ送信のトラフィックを削減することが可能になる。このとき、端末ＡはＡｃｋ受信で再送するか否かを判断することなく、端末Ａ自身が送信後、予め、既定しておいた時間内に、端末Ｂが中継しなければ、再送すれば良い。
【００５８】
図７（ｂ）の例では、端末Ｃから、端末Ａに送信する際、Ｄａｔａ＿ｃだけでなく、Ｄａｔａ＿ａを端末Ｃで受信できたことを意味するＡｃｋ＿ＦｌａｇをＭＡＣヘッダ中に付けておくことで、隣の端末からのＡｃｋだけでなく、最終宛先端末からのＡｃｋも認識することが可能になる（時刻３Ｔ）。
【００５９】
図８は、このＡｃｋ＿Ｆｌａｇ利用方法について示し説明図（パケット構成及びタイミングチャート）である。
【００６０】
図８（ａ）は、Ａｃｋ＿Ｆｌａｇのパケットの構成について示した説明図である。図８（ｂ）は、通信システム１０００（端末Ａ〜端末Ｃ）でＡｃｋ＿Ｆｌａｇのパケットを利用した場合の動作について示したシーケンス図（上述の図６（ｂ）と同様のシーケンス図）である。
【００６１】
図８に示すように、端末Ｂは端末Ａ向けパケットを送信する際、Ｄａｔａ＿ｃとβでネットワークコーディング処理を行ない、送信する。端末Ｃは端末Ｂが送信した端末Ａ宛の中継パケットを受信・復調することで、先に記載した様に、Ａｃｋ代用とすることが可能になる。
【００６２】
図７（ｃ）は、通信システム１０００の端末Ａ〜端末Ｃ（端末１００−Ａ〜１００−Ｃ）を用いることの効果を示した説明図である。通信システム１０００の端末Ａ〜端末Ｃ（端末１００−Ａ〜１００−Ｃ）では、複数のプロトコルを用いて、データ伝達の方向、即ち、上り・下りに対して、プロトコルを選択し、双方向で独立した通信路にする。また、通信システム１０００の端末Ａ〜端末Ｃ（端末１００−Ａ〜１００−Ｃ）では、上記の様に、双方向で独立化した通信路において、ネットワークコーディング処理を行ない送信することでトラフィックを増やすことなく、データ送信の２重化が可能になる。即ち、通信システム１０００の端末Ａ〜端末Ｃ（端末１００−Ａ〜１００−Ｃ）では、トラフィックを増やすことなく、２回送信した場合と同等の効果を得られる、通信品質を改善できる。
【００６３】
次に、図９を用いて、通信システム１０００の端末Ａ〜端末Ｃ（端末１００−Ａ〜１００−Ｃ）におけるネットワークコーディング処理（マルチプロトコル＆ネットワークコーディング通信処理）について説明する。図９では、マルチプロトコル通信＆マルチホップ通信処理で、上り方向と下り方向で異なるプロトコルを使う通信方法において、一方のプロトコルで受信したデータと、もう一方のプロトコルで受信したデータとをネットワークコーディング処理して、それぞれのプロトコルで流すことによりデータの二重化を行なう方法の具体例を説明している。
【００６４】
図９（ａ）は、仮に通信システム１０００の端末Ａ〜端末Ｃにおいて、ネットワークコーディング処理を用いない場合の通信（マルチプロトコル通信＆マルチホップ通信の例）の例を示している。さらに図９（ａ）の例において、通信システム１０００の端末Ａ〜端末Ｃでは、端末Ａから端末Ｃ宛に対して、マルチホップ通信し、端末Ｃから端末Ａ宛にマルチホップ通信すると仮定する。この時、通信システム１０００の端末Ａ〜端末Ｃでは、隠れ端末・さらされ端末によって生じるスループット低下及び双方向通信時の中継端末でのボトルネックを軽減するために、端末Ａ→端末Ｃの通信と端末Ｃ→端末Ａの通信で、データ通信の方向でプロトコルを分けることで、上記の問題を回避する。
【００６５】
図９（ｂ）（図９（ｂ１）〜図９（ｂ５））がネットワークコーディング処理を用いて、マルチプロトコル通信＆マルチホップ通信を行なう場合の例である。
【００６６】
まず、端末Ａは（Ａ＿１）のパケットを端末Ｂに対して送信し、端末Ｃは端末Ｂ宛に（Ｃ＿１）のパケットを送信したものとする（図９（ｂ１）参照）。
【００６７】
次に、（Ａ＿１）及び（Ｃ＿１）で最初のアルファベットは端末番号、次の数値はシーケンス番号を意味するデータ領域部である。（Ａ＿１）及び（Ｃ＿１）のパケットを端末Ｂが受信する（図９（ｂ２）参照）。
【００６８】
次に、（Ａ＿１）と（Ｃ＿１）の排他的論理和をとり、（ＮＣ＿１）を作る。この時、（Ａ＿１）のパケットはプロトコル１で、（Ｂ＿１）のパケットはプロトコル２で受信する（図９（ｂ３）参照）。
【００６９】
次に、端末Ｂはプロトコル１及び２を使って、ネットワークコーディング符号化したパケット（ＮＣ＿１）を送信する。端末Ａ及びＣは、プロトコル１及び２から、送信元の情報を復号することができるために、２回、同じパケットを中継端末である端末Ｂが送信したことと同じになり、通信品質を改善することが可能になる（図９（ｂ４）、図９（ｂ５）参照）。マルチホップ通信では、当然のことながら、全ての中継端末から、正しく受信しなければ、Ｅｎｄ−ｔｏ−Ｅｎｄ端末間（送信元の端末から宛先の端末までの間）での通信品質は保てない。
【００７０】
図９（ａ）、図９（ｂ）に示すように、ネットワークコーディングした場合としない場合の発生パケット数は変わらないので、マルチホップ数が多くなる程、ネットワークコーディングを用いずに、再送２回で通信を行なうと、パケット数は大幅に増える。
【００７１】
以下では、例として、ＮＣ（ネットワークコーディング）の有無で場合分けをして、Ｅｎｄ−ｔｏ−Ｅｎｄ端末数（送信元の端末から宛先までの端末数）と発生するパケット数との関係を説明する。なお、以下の例では、マルチホップ時のみ、再送を２回行うものとして説明する。なお、Ｅｎｄ−ｔｏ−Ｅｎｄ端末数には、送信元の端末及び宛先の端末も含む。例えば、上述の図５（ａ）のようなトポロジの場合（端末Ａ、端末Ｂ、端末Ｃで直列したトポロジ）の場合、Ｅｎｄ−ｔｏ−Ｅｎｄ端末数は３となる。
【００７２】
上述の条件で、ＮＣ無しの場合、Ｅｎｄ−ｔｏ−Ｅｎｄ端末数「３」の場合上下でパケット数が「（２＋１）×２＝６個」、Ｅｎｄ−ｔｏ−Ｅｎｄ端末数「５」の場合上下で「（４＋３）×２＝１４個」、Ｅｎｄ−ｔｏ−Ｅｎｄ端末数「８」の場合上下で「（７＋６）×２＝２６個」、Ｅｎｄ−ｔｏ−Ｅｎｄ端末数「ｎ」の場合上下で「（ｎ−１）＋（ｎ−２）×２＝４ｎ−６個」となる。
【００７３】
これに対して、ＮＣ有りの場合、Ｅｎｄ−ｔｏ−Ｅｎｄ端末数「３」の場合上下でパケット数が「（２）×２＝２個」、Ｅｎｄ−ｔｏ−Ｅｎｄ端末数「５」の場合上下で「（４）×２＝８個」、Ｅｎｄ−ｔｏ−Ｅｎｄ端末数「８」の場合上下で「（７）×２＝１４個」、Ｅｎｄ−ｔｏ−Ｅｎｄ端末数「ｎ」の場合上下で「（ｎ−１）×２個＝２ｎ−２個」となる。
【００７４】
図５（ｃ）に示す様に、通信システム１０００（端末Ａ〜端末Ｃ）において、ネットワークコーディングはマルチホップ中継を行なう端末のみが行ない、送信元（図中では端末Ａ及びＣ）はネットワークコーディング処理したパケットは送信しないものとする。
【００７５】
通信システム１０００（端末Ａ〜端末Ｃ）では、データ発生が片方向からのみの場合（例えば、端末Ａ→端末Ｂ→端末Ｃのみ、データ発生、ＣからＡは通信なしの場合）、中継局である端末Ｂは端末Ｃからパケットを受信しなくても、プロトコル２を用いて、既知データ（例えば、”Ｆ…．Ｆ”）の情報を送信するべき情報として、端末Ａからの情報でネットワークコーディングする。そして、この場合、端末Ｂが端末Ａ宛に送信し、そのパケットを端末Ｃで受信することで、端末Ｃからの送信パケットが発生しなくても、双方向通信を行ない、データの２重化を行なっている状態と同じになり、通信品質の改善を図ることが可能になる。また、通信システム１０００（端末Ａ〜端末Ｃ）では、データのビットパターンとして、上述の既知データ（”Ｆ…．Ｆ”）を取りうるのならば、「ＭＡＣヘッダに既知データとして、送る旨のフラグを付ける」、あるいは、「数ビットの情報をデータのテイルに付ける、あるいは既定の位置に埋めるとすることで、（”Ｆ…．Ｆ”）はデータのビットパターンとはならない」、という要件を満たすことにより、片方が既知情報となり、ネットワークコーディング復号が可能になる。
【００７６】
次に、簡単な例を示すために、仮に、通信システム１０００（端末Ａ〜端末Ｃ）において、データが８ビットの任意のビットパターンを送る場合で、かつ、片方向通信しかしていない場合、”ＦＦ”をデータとして送信する例について説明する。この場合、通信システム１０００（端末Ａ〜端末Ｃ）では、双方向で送信した場合の”ＦＦ”の情報なのか、あるいは、片方向通信時なので、ネットワークコーディング化するために、既知情報として”ＦＦ”を送信したのか、受信側では不明になる。その場合、通信システム１０００の各端末Ａ〜端末Ｃにおいて、例えば、テイル４ビットを付加すると、アプリケーションデータとして扱うのは１２ビット中、“００”＋”０”から”ＦＦ”＋”０”にしかならないので、”ＦＦ”＋”Ｆ”を受信した場合は片方向通信だったと認識することが可能になる。
【００７７】
図１０は、通信システム１０００（端末Ａ〜端末Ｃ）において、ネットワークコーディング（マルチプロトコル＆ネットワークコーディング通信処理）を行なう際の送受信処理を更に具体化した説明図である
図１０（ａ）は、通信システム１０００（端末Ａ〜端末Ｃ）において、ネットワークコーディング（マルチプロトコル＆ネットワークコーディング通信処理）を行なう際の送受信処理について示したシーケンス図である。また、図１０（ｂ）は、通信システム１０００（端末Ａ〜端末Ｃ）において、ネットワークコーディング（マルチプロトコル＆ネットワークコーディング通信処理）を行なう際のトポロジ及びプロトコルについて示した説明図である。
【００７８】
図１０では、端末Ａ→端末Ｂ→端末Ｃの方向の通信が、プロトコル１を使った通信であり、端末Ｃ→端末Ｂ→端末Ａの方向の通信がプロトコル２を使った通信であるものとする。また、以下では、これらのマルチホップで受信できる情報を「ネイティブ情報」と呼ぶものとする。また、通信システム１０００（端末Ａ〜端末Ｃ）では、端末Ａ→端末Ｂ→端末Ｃがプロトコル２を使った通信、端末Ｃ→端末Ｂ→端末Ａがプロトコル１を使った通信で、ネットワークコーディング符号化された情報をネットワークコーディング復号することで、情報に読み込めるこれらの情報をネイティブ情報と呼ぶ。
【００７９】
次に、以下、の説明で用いているネイティブ情報とネットワークコーディング情報を定義する。ネイティブ情報とは、受信側でネットワークコーディング復号処理を行なわず、受信情報として読み取れる、言い換えると、ネットワーク復号処理なしに、受信側で正しく復調できる情報である。これに対して、ネットワークコーディング情報とは受信後、ネットワークコーディング復号処理を行なった後の情報である。パケット誤りがなく、ネットワークコーディング復号処理が正しく行なえば、ネイティブ情報＝ネットワークコーディング情報となる。
【００８０】
次に図１０（ａ）に示す各ステップの処理について説明する。
【００８１】
まず、ステップＳ１において、端末Ａが（Ａ＿１）の情報パケットをプロトコル１で送信したものとする。ここで、端末Ａは、送信元であるために、ネットワークコーディング処理はしない。
【００８２】
次に、ステップＳ２で、端末Ｂがプロトコル１で、マルチホップ中継通信を行なうことで、端末Ｃが（Ａ＿１）を受信可能になる。
【００８３】
次に、ステップＳ３で、端末Ｃが（Ｃ＿１）の情報パケットをプロトコル２で送信する。ここで、端末Ｃは、送信元であるために、ネットワークコーディング処理はしない。
【００８４】
次に、ステップＳ４で、端末Ｂが（Ｃ＿１  ｘｏｒ  Ａ＿１）を、プロトコル２に対して、送信する。このときの端末Ｂで行われるＮＣ符号化処理は、「（Ｃ＿１）ｘｏｒ（Ａ＿１）」となる。
【００８５】
次に、ステップＳ５では、ステップＳ４で送信したネットワークコーディングパケット「（Ｃ＿１ｘｏｒＡ＿１）」を端末Ａで、プロトコル２を使って、受信する。端末Ａは、受信後、ネットワークコーディング復号処理によって、ネイティブ情報（Ｃ＿１）を得る。この時、端末Ａで行われるＮＣ復号処理は、「｛（Ｃ＿１）ｘｏｒ（Ａ＿１）｝ｘｏｒ（Ａ＿１）＝（Ｃ＿１）」となる。
【００８６】
次に、ステップＳ６では、端末Ｃが、ステップＳ４で送信したネットワークコーディングパケット「（Ｃ＿１ｘｏｒＡ＿１）について、自局宛ではないがプロトコル２を使って受信し、ネットワークコーディング復号処理を行なう。このとき、端末Ｃは、ネットワークコーディング復号処理によって、ネットワークコーディング情報（Ａ＿１）を得る。このとき、端末Ｃで行われるＮＣ復号処理は、「｛（Ｃ＿１）ｘｏｒ（Ａ＿１）｝ｘｏｒ（Ｃ＿１）＝（Ａ＿１）」となる。
【００８７】
次に、ステップＳ７では、端末Ａが、（Ａ＿２）の情報パケットをプロトコル１で送信する（ネットワークコーディング処理なし）。
【００８８】
次に、ステップＳ８では、端末Ｂが、先に受信している（Ｃ＿１）と（Ａ＿２）でネットワークコーディング符号化処理を行ない、プロトコル１で送信する。このとき、端末Ｂで行われるＮＣ符号化処理は、「（Ｃ＿１）ｘｏｒ（Ａ＿１）」となる。
【００８９】
次に、ステップＳ９で、端末Ｃは、端末Ｂが送信したパケット「｛（Ａ＿２）ｘｏｒ（Ｃ＿１）｝」を受信する。このとき、端末Ｃで行われるＮＣ復号処理は、「｛（Ａ＿２）ｘｏｒ（Ｃ＿１）｝ｘｏｒ（Ｃ＿１）｝＝（Ａ＿２）」となる（ネイティブ情報（Ａ＿２）を復調、プロトコル１使用）。
【００９０】
次に、ステップＳ１０で、端末Ａが、端末Ｂから送信されたパケット「｛（Ａ＿２）ｘｏｒ（Ｃ＿１）｝」を受信する。このとき、端末Ａで行われるＮＣ復号処理は、「｛（Ａ＿２）  ｘｏｒ（Ｃ＿１）｝ｘｏｒ（Ａ＿２）＝（Ｃ＿１）」となるＮＣ情報（（Ｃ＿１）受信、プロトコル１使用）。
【００９１】
次に、通信システム１０００を構成する各端末１００（端末Ａ〜端末Ｃ）がパケット送信を行う場合の動作について図１１、図１２のフローチャートを用いて説明する。以下では、通信システム１０００を構成する任意の端末１００の動作について説明する。
【００９２】
なお、図１２のフローチャートは、図１１のフローチャートで、２点鎖線で囲った部分（ステップＳ１０４〜Ｓ１１８）の詳細を示したものである。
【００９３】
上述の通り、通信システム１０００を構成する各端末１００（端末Ａ〜端末Ｃ）で、ネットワークコーディング処理を行なうのは、中継端末（中継車両）、かつ、分岐点の場合である。
【００９４】
端末１００は、パケット送信のイベントが発生（Ｓ１０４）すると、送信元として送信するパケットか、中継パケットとして送信するのかを判断する（Ｓ１０５）。
【００９５】
そして、端末１００は、自局（自車両）が送信元であれば、ネットワークコーディングせずに送信（Ｓ１１４、Ｓ１１８、Ｓ１１９）する。
【００９６】
このとき端末１００（パケット送信処理部）は、各プロトコルに既定の方法（所定のデータリンク層の通信仕様）でパケット送信を実施する。例えば、端末１００が、ＲＣ−００５、Ｔ１０９、８０２．１１系無線ＬＡＮ等のプロトコルで、パケット送受信を行う場合は自律分散型であるＣＳＭＡ／ＣＡ方式で、送受信する。
【００９７】
次に、端末１００は、中継端末（中継車両）、かつ、分岐点であるか否かの判断（Ｓ１０６）を行ない、更に、中継転送が必要か否かを判断（Ｓ１１５）する。中継転送が不要ならば、パケットを破棄（Ｓ１２０）して、終了（Ｓ１２１）する。
【００９８】
端末１００は、ルーティングテーブル及びルーティングアルゴリズムより、中継転送が必要と判断された場合には、プロトコル選定（Ｓ１１６）し、受信パケット中のｆｌａｇ状態をそのまま送信パケットＭＡＣ中のｆｌａｇに書込み（Ｓ１１７）、パケット送信処理（Ｓ１１９）を行なう。端末１００によるパケット送信処理は上述の通りである。
【００９９】
次に、端末１００において、上述のステップＳ１０６でＹｅｓとなった場合（“中継車両、かつ、分岐点の条件でＹｅｓとなった場合）の処理について説明する。
【０１００】
この場合（上述のステップＳ１０６でＹｅｓとなった場合）、端末１００は、一方のプロトコルで受信した情報と、もう一方のプロトコルで受信した情報で排他的論理和演算を行なう。そのために、このとき、端末１００は、上記記載のもう一方で受信した情報があるか否かを調べる（Ｓ１０７）。
【０１０１】
端末１００は、バッファ１５５に一時的に蓄えておくもう一方の受信情報が空状態である場合（例えば、双方向通信ではなく、同報型の場合、あるいは、時間差で片方向のデータのみ発生している場合）には、ダミー情報を使用してネットワークコーディング演算処理（符号化処理）を行なう（Ｓ１０８、Ｓ１０９）。
【０１０２】
次に、端末１００が、どちらのプロトコルで送信するかを選択する処理方法について図１３を用いて説明する。
【０１０３】
図１３において、「α１，  α２，  α３，  α４  ，…」及び「β１，  β２，  β３，  β４，…」は端末Ａ及び端末Ｂから発生するパケットである。また、図１３において、「γ１，  γ２，  γ３，  γ４，…」は端末Ｂでネットワークコーディング処理したデータである。
【０１０４】
図１３（ａ）は、中継端末Ｂを基準に上り・下りで、プロトコルを切り替える場合の例について示しており、図１３（ｂ）は、Ｅｎｄ−ｔｏ−Ｅｎｄ間の系列で、プロトコルを決定する場合の例について示している。
【０１０５】
図１３（ａ）の場合、送信元は常に上り方向のプロトコルで送信し、受信するべき情報はプロトコル２で受けることになる。ただし、中継転送されたか否かを確認する、２つのプロトコルに対するルーティング情報を受け取る必要があるので、２つのプロトコル共に、送受信処理は行なっている。また、図１３（ｂ）の場合は送信元で、プロトコルが決まり、中継車両は受信したプロトコルで中継転送する（図１１のステップＳ１１１、Ｓ１１２）。
【０１０６】
そして図１１の説明に戻ると、端末１００は、ネットワークコーディング処理を行なって送信するので、ＮＣ＿ｆｌａｇは「１」に設定され、ＭＡＣヘッダに書き込む処理（ステップＳ１１３）。その後、端末１００は、パケット送信処理（Ｓ１１９）を経て、処理を終了（Ｓ１２１）する。
【０１０７】
次に、上述の図１１で、２点鎖線で囲んだ部分（ステップ）の詳細処理を図１２のフローチャートを用いて説明する。
【０１０８】
端末１００は、パケット送信のイベントが発生（Ｓ２０１）すると、送信元として送信するパケットか、中継パケットとして送信するのかを判断する（Ｓ２０２）。上述の図７で、既に記載している様に、送信元端末（送信元車両）から中継端末（中継車両）までの通信は、ネットワークコーディングでの通信品質改善ではなく、次ホップ先が中継パケットを送信したか否かでＡＣｋ代用とするために、所定時間（ΔＴ）以内に、次ホップ端末の送信を確認できない場合には再送する（Ｓ２０３）。
【０１０９】
そして、端末１００は、既定回数、既に送信済の場合には、終了する。
【０１１０】
一方、端末１００は、既定回数に至っていない場合には、ネットワークコーディング処理を行なわず（Ｓ２０４）、上述のプロトコル選択ルールに従って（Ｓ２０５）、パケットを送信する（Ｓ２０６）。
【０１１１】
端末１００が中継端末としての処理（中継車両の処理）を行なう場合を次に説明する。ここでは簡単化のために、フローの条件として、送信元端末（送信元車両）が送信する場合と中継端末（中継車両）が送信する場合（Ｓ２１１）に限って記載し、中継転送処理が必要のない場合（即ち、送信元からのパケットを受信したが、ルーティングアルゴリズムで、中継の必要がないと判断された場合）の例について説明する。端末装置１００が、中継転送する場合、先に記載している、「もう一方のプロトコルで受信した情報」を一時保存しておくバッファ１５５が空か否かを判断する（Ｓ２１２）。端末１００は、バッファ１５５が空の場合には、予め決めておくダミーデータとで、ネットワークコーディング処理を行なうことになる（Ｓ２１６）。
【０１１２】
そして、端末１００は、次の「リアルタイム性要求」において、もう一方のプロトコルからの受信データを待ってから、ネットワークコーディング処理を行なうか、あるいはリアルタイム性が要求されるアプリケーションのために、データ受信を待たずに、ダミーデータを使って、ネットワークコーディング処理を行なう。例えば、端末１００が最新に送信しようとしているパケットが音声データの際はリアルタイム性が要求されるので、データ受信を待たずに、ダミーデータでネットワークコーディング処理を行なって送信するようにしてもよい（Ｓ２１３、Ｓ２１４）。
【０１１３】
また、端末１００は、ファイルダウンロード等、リアルタイム性が要求されないものは、既定時間待機状態にし（Ｓ２１５）、更に、受信データが受け取れない場合に、ダミーデータとネットワークコーディング処理を行なって送信するようにしてもよい。ステップＳ２１７〜Ｓ２１９は既に説明したプロトコル変更、パケット送信の部分である。
【０１１４】
次に、通信システム１０００を構成する各端末１００（端末Ａ〜端末Ｃ）がパケット受信を行う場合の動作について図１４〜図１６のフローチャートを用いて説明する。以下では、通信システム１０００を構成する任意の端末１００の動作について説明する。図１４は全体の概略フロー、図１５は詳細フローである。
【０１１５】
まず、図１４を用いて、端末１００でパケットの受信処理が行われる処理全体の概略について説明する。
【０１１６】
端末１００におけるパケットの受信処理は、宛先の確認、データの確認、中継転送処理あるいは上位層へデータのＵｐ処理に分けられる。
【０１１７】
まず、ここでは、端末１００では、受信イベントが発生し（Ｓ３０１）すると、中継端末（中継車両）であるか、中継転送が必要であるかが判断される（Ｓ３０２）。
【０１１８】
端末１００では、宛先ＩＤ、中継宛先ＩＤ及びルーティングテーブルを用いて判断される。端末１００では、自局が中継端末（中継車両）で中継転送処理が必要な場合は、後述するステップＳ３０３の処理へ進む。また、端末１００は、自局（自車両）が、受信したパケットの宛先ＩＤの時には、後述するステップＳ３０７の処理へ進む。
【０１１９】
端末１００は、ステップＳ３０３又はステップＳ３０７の処理で、ＮＣ（ネットワークコーディング）復号処理が必要か否かをＭＡＣヘッダ中のｆｌａｇで確認をして、必要時はダミーデータあるいはもう一方のプロトコル受信データを使って、ネットワークコーディング復号処理を行なう。端末１００は、ネットワークコーディング復号処理結果にビット誤りがあるか否か、遅延時間許容内か否かを確認する。
【０１２０】
そして、端末１００では、ネットワークコーディング復号処理結果についてデータが正しく、遅延時間許容内であれば、次の判定（ステップＳ３０４又はＳ３０８）で「Ｙｅｓ」となり、中継転送処理（ステップＳ３０５）、あるいは上位層へのデータＵｐ処理（ステップＳ３０９）を行なう。
【０１２１】
端末１００がステップＳ３０５で行う中継転送処理については、既に送信フロー中で説明したので、ここでは詳細説明を割愛する。端末１００がアプリケーションとして、リアルタイム性が要求されない場合であれば、ビット誤りがあるか否かで、データがＯＫか否かの判定を行なう。このとき、端末１００は、リアルタイム性が要求される場合の許容遅延時間ｔ１（例えば、１００ｍｓｅｃ）、リアルタイム性が要求されない場合の許容遅延時間ｔ２（例えば、１０ｓｅｃ）と予め、決めておき、この既定値と比較して、遅延時間が許容内か否かを判定しても良い。端末１００は、送信元端末（送信元車両）が、受信パケットに記載したタイムスタンプと、宛先端末（宛先車両）で受信した時の受信時刻から、遅延時間を算出する。端末１００は、逐次的に受信しているデータで、シーケンス番号に抜けがなく、受信しているか、シーケンス番号Ｓｅｑ＿ｉのパケットを宛先車両で受信した時刻とシーケンス番号Ｓｅｑ＿ｉ＋１のパケットを宛先車両で受信した時刻の差から、遅延時間を見積もって、その見積り値から、遅延時間許容内か否かを求めても良い。
【０１２２】
次に、図１５のフローチャートを用いて、端末１００がパケット受信を行う場合の詳細処理について説明する。
【０１２３】
端末１００は、受信イベントを開始し（Ｓ４０１）、２つのプロトコルで受信確認（Ｓ４０２）を行なう。
【０１２４】
以後の端末１００の動作については、１つのプロトコルの動作を示しており、全て２つのプロトコルで同様の動作する者として説明する。
【０１２５】
次に、端末１００は、ステップＳ４０３以後で、１つのプロトコルの動作を示しており、もう一方のプロトコルに関しても、同じ処理が独立に動作しているものとする。すなわち、端末１００では、第１及びプロトコル２について、それぞれ、ステップＳ４０３以後のステップの処理が実行される。
【０１２６】
端末１００は、ステップＳ４０３では、受信したパケットについて自局が分岐点（中継端末、中継車両）となるか、宛先端末（最終宛先車両）となるかを判断する。端末１００は、自局が分岐点（中継端末、中継車両）の場合、後述する処理（ステップＳ４０７Ａ、Ｓ４１３Ａ、Ｓ４１５の処理）を行い、自局が宛先端末（最終宛先車両）である場合には、後述する処理（ステップＳ４０７Ｂ、Ｓ４１３Ｂ、Ｓ４１６の処理）を行う。また、端末１００は、受信したパケットについて自局が分岐点（中継端末、中継車両）でも、宛先端末（最終宛先車両）でもない場合には、当該パケットを廃棄（Ｓ４０６）して上述のステップＳ４０１の処理に戻って動作する。
【０１２７】
端末１００は、ステップＳ４０７Ａ又はＳ４０７Ｂでは、ネットワークコーディング処理が必要か、不要かを判断し、必要時には復号処理を行なう。復号処理が必要か不要かは、受信パケットのＭＡＣヘッダ中のＮＣ＿ｆｌａｇで確認できる。必要時には、もう一方の受信データを確認して、情報があれば、その情報を用いて、なければ、予め、ルールで決めておくダミーデータを用いて、ネットワークコーディング復号処理を行なう（ステップＳ４０８〜Ｓ４１２）。
【０１２８】
また、端末１００は、ステップＳ４１３Ａ又はＳ４１３Ｂにおいて、復号したデータがＯＫか否かの確認を行ない、次の中継転送処理（ステップＳ４１５）、あるいは上位層への供給処理（ステップＳ４１６）を行ない、復号したデータがＮＧの場合には、ステップＳ４０６から動作してパケットを廃棄する処理を行うことになる。
【０１２９】
次に、通信システム１０００を構成する端末１００（端末Ａ、端末Ｂ、端末Ｃ）で、パケット受信処理（プロトコル１とプロトコル２で区別した受信処理）を行う動作について図１６のフローチャートを用いて説明する。
【０１３０】
図１６（ａ）は、端末１００のパケット受信動作の詳細について示したフローチャートであり、図１６（ｂ）は、通信システム１０００に係るトポロジ構成の例について示している。
【０１３１】
以下では、端末Ａ→端末Ｂ→端末Ｃ（車両Ａ→車両Ｂ→車両Ｃ）のデータ伝送の場合、「通常のプロトコル」＝プロトコル１、「もう片方のプロトコル」＝プロトコル２となるものとする。また、以下では、逆に端末Ｃ→端末Ｂ→端末Ａのデータ伝送の場合、「通常のプロトコル」＝プロトコル２、「もう片方のプロトコル」＝プロトコル１となるものとする。即ち、以下では、ネットワークコーディングの符号化・復号処理を行なわずに、データの復調ができる方を「通常のプロトコル」、ネットワークコーディング符号化・復号処理によって、データの復調ができる方を「もう片方のプロトコル」と呼ぶものとする。
【０１３２】
端末１００において、ネットワークコーディングを行う際、自局が中継端末の場合、既に受信している情報と新規に送りたい情報を排他的論理和で処理化して送信する。そのために、図１６（ａ）の受信フローでは「通常のプロトコル」、すなわちネイティブ情報が先に受信することになる。端末１００において、受信フローでの処理側が「通常のプロトコル」の場合、ネイティブ情報の受信処理にあたることになる（Ｓ５０２〜Ｓ５０４）。図１６では、端末１００は、正しくパケット受信した後（Ｓ５０２でＹｅｓの場合）、当該パケットのヘッダ部に含むタイムスタンプ情報から、パケット到達遅延時間が許容時間内か否かを判断し、許容時間内であれば、上位層にその情報上げる（Ｓ５０４）。また、端末１００は、許容時間を超えている場合には、情報が古いと判断し、上位層へ上げずに廃棄する処理を行う（Ｓ５０５）。これは、端末１００が、アプリケーションとして、ベストエフォート型の通信である場合の例である。なお、端末１００のアプリケーションがギャランティ型（帯域保障型）であり、上位層で受信データをシーケンス番号に並び変える順序制御を行なう場合には、上述のステップＳ５０３、及びＳ５０５の処理は必須ではない。
【０１３３】
ステップＳ５０６〜Ｓ５０８の処理は、端末１００が行う「もう片方のプロトコル」の、ネットワークコーディング情報の受信処理である。こちらの復調情報はネイティブ情報が正しく復調できなかった場合、ステップＳ５０４の処理により上位層へ上げれば良い。なお、端末１００は、「もう片方のプロトコル」の、ネットワークコーディング情報の受信処理においても、ステップＳ５０８により、許容遅延時間内か否かを判定する。
【０１３４】
次に、図８を用いて、端末１００が送受信するパケットフォーマットについて説明する。
【０１３５】
このパケットフォーマットでは、プロトコルを上り・下りで分け、ネットワークコーディングを行なうために、ＭＡＣヘッダ部にはプロトコル１の領域とプロトコル２の領域が確保されている。このパケットフォーマットでは、ネットワークコーディングする領域は図中に示したＤａｔａ部である。このパケットフォーマットでは、プロトコル１と２の間で、データ長が異なる場合には、長い方に合わせ、短い方のデータに、不足分’０’埋め（’１’埋め、あるいは予め、既定しておいたパターンであっても良い）する。
【０１３６】
以下、図８に示すＭＡＣヘッダを構成する各フィールドについて、説明する。
【０１３７】
ＭＡＣヘッダを構成する「ＳＩＤ」のフィールドは、送信元ＩＤ（オリジナルパケット送信端末のＩＤ、中継端末は中継転送する際、受信したパケット内の情報をそのまま使用する）を示している。
【０１３８】
ＭＡＣヘッダを構成する「ＤＩＤ」のフィールドは、宛先ＩＤ（最終端末、Ｅｎｄ端末のＩＤ、中継端末はＳＩＤと同様に、そのまま使用する）を示している。
【０１３９】
ＭＡＣヘッダを構成する「Ｒ＿ＳＩＤ」のフィールドは、中継送信元ＩＤを示している。
【０１４０】
ＭＡＣヘッダを構成する「Ｒ＿ＤＩＤ」のフィールドは、中継宛先ＩＤを示している。
【０１４１】
ＭＡＣヘッダを構成する「Ｓｅｑ．  Ｎｏ．」のフィールドには、パケットシーケンス番号、又は受信パケットの番号（自局が中継端末の場合）がそのまま適用される。
【０１４２】
ＭＡＣヘッダを構成する「Ｔｉｍｅ  Ｓｔａｍｐ」のフィールドは、送信元端末（送信元車両）が送信する際の時刻が埋め込まれている。「Ｔｉｍｅ  Ｓｔａｍｐ」のフィールドは、受信パケットが、古いか否か、パケット到達にどれだけの時間がかかっているかを算出するために用いられる。
【０１４３】
ＭＡＣヘッダを構成する「Ａｃｋ＿Ｆｌｇ（１＋２）」のフィールド（Ａｃｋ＿Ｆｌｇ１、Ａｃｋ＿Ｆｌｇ２を含むフィールド）において、Ａｃｋ＿Ｆｌｇ１はパケット受信成功か否かのフラグであり、Ａｃｋ＿Ｆｌｇ２はその時のシーケンス番号である。図８では、パケット１個の成功か否かを付加しているが、複数個まとめて、付加しても良く、あるいはパケット廃棄となったものだけを付加して、知らせる様にしても良い。
【０１４４】
ＭＡＣヘッダを構成する「ＮＣ＿Ｆｌｇ」のフィールドには、ネットワークコーディング無を示す「０」、又はネットワークコーディング有を示す「１」のいずれかが設定される。「ＮＣ＿Ｆｌｇ」のフィールドには、送信元がパケット送信時には常に「０」、中継端末で、ネットワークコーディングする際は「１」が設定される。例えば、オリジナル送信元の端末１００では、ＭＡＣヘッダに送信時「ＳＩＤ  ＝  Ｒ＿ＳＩＤ、ＮＣ＿Ｆｌｇ＝’０’」が設定される。また、例えば、中継端末として動作する端末１００が、パケットを中継転送する際、そのパケットのＭＡＣヘッダには、「ＳＩＤ≠Ｒ＿ＳＩＤ、ＮＣ＿Ｆｌｇ  ＝  ‘１’」が設定される。したがって、端末１００において、ＮＣ＿Ｆｌｇは用いずに、ＳＩＤとＲ＿ＳＩＤが一致するか否かで、ネットワークコーディングに係る判断を行い、ＭＡＣヘッダ部からＮＣ＿Ｆｌｇを削除して、ＭＡＣヘッダ部を短くするようにしても良い。
【０１４５】
第１の実施形態では、端末１００が搭載する機能として、「データ伝達方向でプロトコルを分けるマルチプロトコル化機能」、「Ａｃｋを返信するのではなく、次ホップ先が送信したか否かで、次ホップ先に正しく届いたか否かを判断するＡｃｋ代替機能」、及び「双方向通信で、Ｅｎｄ端末が正しく受信した旨を知らせる機能」について説明した。しかし、この実施形態に端末１００において、上述の全ての機能を装備するのではなく、装備する機能を限定しても良い。例えば、端末１００がベストエフォート型の端末として利用される場合には、パケットが正しく届いたか否かは保証しないので、その場合、上述の「双方向通信で、Ｅｎｄ端末が正しく受信した旨を知らせる機能」の機能は具備しなくても良い。
【０１４６】
各端末１００において、図１７に示すような表示画面を表示（例えば、図示しないディスプレイ等の表示装置で表示）するようにしてもよい。
【０１４７】
図１７に示す表示画面では、端末１００−Ａ、端末１００−Ｂ、端末１００−Ｃについて、それぞれ車両１（図１７での識別子は「１」）、車両２（図１７での識別子は「２」）、車両３（図１７での識別子は「３」）に搭載されているものとして表示されている。
【０１４８】
図１７で示した画面は、通信状況確認及びネットワーク接続状況確認のための画面であり、必ずしも核端末１００で必須となる構成要素ではない。
【０１４９】
図１７（ａ）及び図１７（ｂ）は車両１及び車両２における表示である。図１７（ａ）に示す画像Ｇ１０１及び、図１７（ｂ）に示す画像Ｇ２０１はＰＨＹ層に関わる状況確認（ｏｎ，  ｏｆｆ表示）である。また、図１７（ａ）に示すＧ１０２及び図１７（ｂ）に示すＧ２０２は、ネットワーク層、マルチホップ通信に関わるものである。中継車両では複数の車両と通信を行なうために、経路毎、あるいは、車両毎に通信状況を表示しても良い。
【０１５０】
また、図１７（ａ）に示す画像Ｇ１０３及び図１７（ｂ）に示す画像Ｇ２０３は、各端末１００間のトポロジを示したものである。図１７に示すトポロジ表示では、直接通信できるものと、マルチホップ通信で通信が可能なものである。
【０１５１】
図１７（ｃ）に示す画像Ｇ３００は、図１７（ａ）に示す画像Ｇ１０１及び図１７（ｂ）に示す画像Ｇ２０１のＯｎ／ｏｆｆ表示方法である。ここでは、上述のＯｎ又はｏｆｆ色による２段階表示（Ｏｎ／ｏｆｆ表示）としているが、複数段階、あるいは数値による表示でも良い。例えば、各端末１００では、受信状態として、通信品質に応じて「通信品質：良、通信品質：中、通信品質：悪」等と表示しても良い。また、各端末１００では、受信電力値を表示しても良い。
【０１５２】
（Ａ−３）第１の実施形態の効果
第１の実施形態によれば、以下のような効果を奏することができる。
【０１５３】
通信システム１０００を構成する各端末１００（車両）では、上り方向と下り方向で異なるプロトコルを使う通信方法において、一方のプロトコルで受信したデータと、もう一方の受信データとをネットワークコーディングすることで、送信トラフィックを増やすことなく、通信品質を改善できる。例えば、通信システム１０００では、マルチホップ通信において、隠れ端末による通信品質劣化を低減し、ネットワークコーディングを用いて、通信の不安定性を改善することができる。特に、通信システム１０００を構成する各端末１００（車両）は、ＩＴＳで検討されている７００ＭＨｚ帯車々間通信、及び５．８ＧＨｚ帯車々間通信に適用することで大きな効果を得られる。
【０１５４】
また、複数の経路が交わる中継点はトラフィック負荷が大きくなるので、ボトルネックになってしまい、スループットの低下を招いてしまう。そこで、通信システム１０００では、中継端末におけるボトルネックはマルチプロトコルを用いて、データ伝送の方向で、プロトコルを区別し、ネットワークコーディングを用いている。これにより、通信システム１０００では、中継端末が送信するパケットに対して、ネットワークコーディング処理を行なうことで、複数回受信できる様にすることで、トラフィック量を増やすことなく、通信品質を改善することができる。
【０１５５】
さらに、通信システム１０００では、次ホップ先の中継端末が送信したパケットを監視することで、Ａｃｋ代用として、トラフィック負荷を上げずに、パケット廃棄か否かを監視することである。これによって、安定したスループットを得ることができる。
【０１５６】
（Ｂ）第２の実施形態
以下、本発明による通信装置及び通信方法、並びに通信システムの第２の実施形態を、図面を参照しながら詳述する。以下では、本発明の通信装置を「端末」に適用した例について説明する。
【０１５７】
（Ｂ−１）第２の実施形態の構成
図１８は、第２の実施形態の通信システム１０００の全体構成について示したブロック図である。
【０１５８】
この実施形態の通信システム１０００には、５台の端末１００−Ａ〜１００−Ｅが配置されているものとして説明する。なお、以下では、車両Ａ〜車両Ｅは、それぞれ端末１００−Ａ〜１００−Ｅが搭載された車両である。
【０１５９】
第２の実施形態の通信システム１０００を構成する各端末１００−Ａ〜１００−Ｅ（車両Ａ〜車両Ｅ）の内部構成については、第１の実施形態と同様に図１、図３を用いて説明することができるため、以下では、第２の実施形態について第１の実施形態との差異を説明する。
【０１６０】
第１の実施形態では、第１の無線ユニット１２１と第２の無線ユニット１２２とで、異なるプロトコルを設定する例について示したが、第２の実施形態では、第１の無線ユニット１２１と第２の無線ユニット１２２とで、同じプロトコルを用いつつ異なる２周波数チャネルＣＨ１、ＣＨ２を適用した通信（異なる通信方式の通信）を行う点で第１の実施形態と異なる。第１の無線ユニット１２１と第２の無線ユニット１２２とで、同じプロトコルを用いつつ異なる２周波数チャネルＣＨ１、ＣＨ２を適用する場合、端末１００としてハードウェア的に、図１、図３と異なる構成としてもよいが、同一のハードウェア等を用いて設定変更により適用可能とする構成としてもよい。
【０１６１】
第２の実施形態では、１つの端末１００内部で、１つのプロトコルについて２つの周波数チャネルＣＨを用いる場合、周波数チャネルＣＨ毎に独立に通信処理が動作し、お互いに干渉しないものとする。また、各端末１００内部では、１つのプロトコルについて２つの周波数チャネルＣＨを用いる場合、通信チャネルＣＨごとにルーティングアルゴリズムも独立に動作し、ルーティングテーブルも周波数ＣＨ１とＣＨ２で独立に保持しているとする。各端末において、上述の図１、図３では、第１の無線ユニット１２１と第２の無線ユニット１２２の機能（ＣＨ１とＣＨ２の通信処理機能）をそれぞれ独立のブロックで示しているが、例えば、送受信アンテナは共有化して、無線ユニットの中で、該当するチャネルの部分の信号をフィルタ帯域制限によって、取り出すようにしても良い。
【０１６２】
第２の実施形態では、通信システム１０００を構成する端末１００−Ａ〜１００−Ｅにおいて（送信元が４車両の場合において）、２つのプロトコルでネットワークコーディング処理を行う第１の構成例と、１つのプロトコルで、かつ、１つのプロトコル内の周波数チャネルが異なるチャネルを用いて、２つのプロトコルの代用とする第２の構成例の２つの構成例について説明する。
【０１６３】
（Ｂ−２）第２の実施形態の動作
次に、以上のような構成を有する第１の実施形態の通信システム１０００の動作を説明する。
【０１６４】
（Ｂ−２−１）第１の構成例（送信車両４台、２プロトコル＆１周波数チャネル）
まず、通信システム１０００を構成する端末１００−Ａ〜１００−Ｅにおいて（送信元が４端末（４車両）の場合において）、２つのプロトコルでネットワークコーディング処理を行う第１の構成例の動作について図１９を用いて説明する。
【０１６５】
図１９（ａ）は、通信システム１０００を構成する車両Ａ〜車両Ｅ（端末１００−Ａ〜１００−Ｅ）
図１９（ａ）の例では、車両Ａが車両Ｂを介して車両Ｃへパケット送信し、車両Ｃが車両Ｂを介して車両Ａへパケット送信し、車両Ｄが車両Ｂを介して車両Ｅへパケット送信し、車両Ｅが車両Ｂを介して車両Ｄへパケット送信するトポロジとなっている。
【０１６６】
また、以下では、車両Ａ、車両Ｃ、車両Ｄ、車両Ｅから送信するパケット情報を、それぞれ、α、β、γ及びδと表す。ここでは簡単化のために、パケットを記号１文字で記載しているが、実際には各車両（端末１００）は、順次パケットを送受信しているものとする。そして、車両Ａ〜車両Ｅが送信するパケット系列を、それぞれ、α（α１，α２，α３，α４，…）、β（β１，β２，β３，β４，…）、γ（γ１，γ２，γ３，γ４，…，）、δ（δ１，δ２，δ３，δ４，…）と表すものとする。
【０１６７】
次に図１９（ａ）のトポロジの通信システム１０００における、２プロトコルの利用方法について、図１９（ｂ）を用いて説明する。
【０１６８】
図１９（ｂ−１）は、通信システム１０００（車両Ａ〜車両Ｅ）において、Ｅｎｄ−ｔｏ−Ｅｎｄ間のデータの流れ毎に、同じプロトコルを利用する場合について示している。この場合、通信システム１０００（車両Ａ〜車両Ｅ）において、中継車両となる車両Ｂは受信したプロトコルを使って、中継転送する。
【０１６９】
図１９（ｂ−２）は、通信システム１０００（車両Ａ〜車両Ｅ）において、中継車両を基準に、中継車両から車両は下り方向、車両から中継車両を上り方向と定義し、上り方向をプロトコル１、下り方向をプロトコル２と定義し、使用する場合について示している。よって、図１９（ｂ−２）の場合、通信システム１０００（車両Ａ〜車両Ｅ）において、中継車両は、受信したプロトコルと異なるプロトコルを用いることになる。
【０１７０】
第１の実施形態では、送信車両(送信端末)が２車両（２端末）であり、ネットワークコーディングする際に用いる情報は、もう一方の情報を使えば、論理和演算できる。これに対して第２の実施形態では、ネットワークコーディングする他方の情報をどの様にして、選ぶかが問題となる。そこで、図１９（ｂ−２）では、第２の実施形態において、中継車両となる車両Ｂが、他の４車両から受け取ったα、β、γ、δの情報をＮＣ処理するかが問題となる。
【０１７１】
車両Ｂは、受信した情報に対して、ＳＩＤ、ＤＩＤ及び、データを抜粋し、ＤＩＤとＳＩＤを入れ替えると、中継転送時に必要なＮＣ処理の情報となる。具体的には、車両Ｂは、車両Ａからαを受信し、車両Ｃからβを受信しており、この２車両がお互いに情報を送り合いたいので（ＭＡＣヘッダのＳＩＤ，ＤＩＤ，ＲＳＩＤ，ＲＤＩＤからこれらのことが分かる）、「αＸＯＲβ」をプロトコル１及び２を使って、中継転送すれば良い（図１９（ｃ）、図１９（ｃ−２）参照）。
【０１７２】
同様に、車両Ｂは、車両Ｄからγ、車両Ｅからδを受信するため、（γＸＯＲδ）をプロトコル１及び２を使って、中継転送すれば良い（図１９（ｃ−１）、図１９（ｃ−２）参照）。
【０１７３】
その他の送信フロー、受信フロー及びパケットフォーマットについては、第１の実施形態と同じであり、ここでは詳細説明を省略する。
【０１７４】
（Ｂ−２−２）第２の構成例（送信車両４台、１プロトコル＆１周波数チャネル）
次に図１９（ａ）のトポロジの通信システム１０００における、２プロトコルの利用方法について図１９（ｂ）を用いて説明する。
【０１７５】
第２の実施形態では、通信システム１０００を構成する端末１００−Ａ〜１００−Ｅにおいて（送信元が４車両の場合において）、２つのプロトコルの代用とする第２の構成例の２つの構成例について、図２０を用いて説明する。
【０１７６】
図２０（ａ）、図２０（ｂ）に示すように、第２の構成例の通信システム１０００（車両Ａ〜車両Ｅ）におけるトポロジは、上述の第１の構成例と同様である。なお、第２の構成例に係る図２０（ｂ）の構成では、プロトコル１で周波数チャネルＣＨのみを変更して、同一経路の通信を多重している。なお、第２の実施形態を第２の構成例として構築した場合、通信システム１０００（車両Ａ〜車両Ｅ）の各処理は、第１の実施形態同様であるため、詳しい説明を省略する。
【０１７７】
（Ｂ−３）第２の実施形態の効果
第２の実施形態によれば、第１の実施形態の効果に加えて以下のような効果を奏することができる。
【０１７８】
第２の実施形態の通信システム１０００を構成する端末１００（車両）では、上り方向と下り方向で異なるプロトコルを使う通信方法において、１つのプロトコルのみでも適用が可能になる。
【０１７９】
（Ｃ）第３の実施形態
以下、本発明による通信装置及び通信方法、並びに通信システムの第３の実施形態を、図面を参照しながら詳述する。以下では、本発明の通信装置を「端末」に適用した例について説明する。
【０１８０】
（Ｃ−１）第３の実施形態の構成
第１、第２の実施例では最大ホップ数が２（中継通信端末が２）の例について説明したが、第３の実施形態の通信システム１０００では、最大ホップ数が３以上（中継通信端末が４以上）の構成となっている。
【０１８１】
図２１に示すように、この実施形態の通信システム１０００には、４台の端末１００−Ａ〜１００−Ｄが１列に並べて配置されているものとして説明する。なお、以下では、車両Ａ〜車両Ｄは、それぞれ端末１００−Ａ〜１００−Ｄが搭載された車両である。例えば、１本の道路上に、端末１００−Ａ〜１００−Ｄを搭載した車両Ａ〜車両Ｄが配置されると、図２１のような状態となる。
【０１８２】
第３の実施形態の通信システム１０００を構成する各端末１００−Ａ〜１００−Ｄ（車両Ａ〜車両Ｄ）の内部構成については、第１の実施形態と同様に図１、図３を用いて説明することができるため、以下では、第１の実施形態について第１の実施形態との差異を説明する。
【０１８３】
（Ｃ−２）第３の実施形態の動作
次に、以上のような構成を有する第３の実施形態の通信システム１０００の動作を説明する。
【０１８４】
第３の実施形態を構成する通信システム１０００（端末１００−Ａ〜１００−Ｄ、車両Ａ〜Ｄ）においてネットワークコーディングによる２重化を行なうためには、中継転送時に、ネットワークコーディングを行なっておく必要がある。よって、第３の実施形態の通信システム１０００（車両Ａ〜車両Ｄ）では、中継転送の１回目（１回目のホップ）は受信情報をネットワークコーディング符号化のみを行なえば良いが、中継転送の２回目以降（２回目以後のホップ）を行う車両は、ネットワークコーディング復号を行なった後、再度、ネットワークコーディング符号化を行ない、２つのプロトコルを使って送信する。
【０１８５】
次に、第３の実施形態の通信システム１０００（車両Ａ〜車両Ｄ）の動作について図２２を用いて説明する。
【０１８６】
まず、図２２で、図示している各パケットに係る番号の定義について説明する。
【０１８７】
図２２では、１００番第（１００〜１９９）の番号は、各車両から送信するパケット情報を示しているものとする。
【０１８８】
また、図２２では、２００番台（２００〜２９９）の番号は、空間に飛んでいるパケット（送信パケット、中継転送パケットを含む）を示しているものとする。なお、１００番台と２００番台で、アプリケーション情報ＬＳＤＵ部分は共に同じであるが、１００番台は無線機から送信する前の、通信イベントで発生する情報。これに対して、２００番台は、実際に空間に飛んでいるパケット情報に付き、ＰＲ、ＵＷ、ＭＡＣ等のヘッダ情報を付けたものを意味する。
【０１８９】
さらに、図２２では、３００番台（３００〜３９９）の番号は、ネットワークコーディングする際に、もう一方の受信情報を一時的にバッファに蓄えている情報を示しているものとする。
【０１９０】
図２２（ａ）では、通信システム１０００を構成する車両Ａ〜車両Ｄのトポロジ及び使用するプロトコルはについて示している。図２２（ａ）に示すように、通信システム１０００では、車両Ａ，車両Ｂ、車両Ｃ，車両Ｄの順序で１列に直列されたトポロジとなっているものとする。
【０１９１】
そして、通信システム１０００では、車両Ａから車両Ｄの方向への通信については、プロトコル１を用いた通信を行うものとする。図２２（ａ）に示すように、車両Ａから車両Ｄの方向へは、プロトコル１に従ったα（α１，α２，α３，α４，…）のパケット系列が送信・転送される。また、図２２（ａ）に示すように、車両Ｄから車両Ａの方向への通信については、プロトコル２を用いた通信を行うものとする。車両Ｄから車両Ａの方向へは、プロトコル２に従ったβ（β１，β２，β３，β４，…）のパケット系列が送信・転送される。ここで、αｉ、βｉが１回に送信するパケットを意味し、逐次送信するパケット（α１，α２，α３，α４，…）全体をまとめて、αと表記するものとする。βについても同様である。
【０１９２】
次に、通信システム１０００（車両Ａ〜車両Ｄ）において、車両Ａから、車両Ｄに向けて、パケットαを送信する動作例について図２２（ｂ）を用いて説明する。
【０１９３】
なお、パケットフォーマット中にあるＮＣ＿ｆｌａｇ２は、どのネットワークコーディング方法を用いているかを認識するために付加されるフラグである。この実施形態では、通信システム１０００において、所定のエリア内においては、全車両は同じネットワークコーティング方法を用いるものとする。通信システム１０００において、予め、ネットワークコーディング方法が固定で、決まっていれば、ＮＣ＿ｆｌａｇ２のフラグはパケットから削除しても良い。
【０１９４】
まず、車両ＡがパケットαをＮＣ処理なしで送信したものとする。このときパケットαのヘッダでは、「ＮＣ＿ｆｌａｇ＝０」、「ＮＣ＿ｆｌａｇ＝０」につき、「ＮＣ＿ｆｌａｇ３」は「０」でも「１」でも良い。パケットαについてＮＣ＿ｆｌａｇ３の項目は受信側で無視されることになる。ＮＣ＿ｆｌａｇ２については、上記に記載した通りである（下記の例では「ＮＣ＿ｆｌａｇ２＝１」とする）。
【０１９５】
このとき、車両Ｄからのマルチホップ情報がまだ届いていないため、車両Ｂにおいて、プロトコル２に対するバッファが「空」状態であるものとする。そのために、車両Ｂは（α  ＸＯＲ  Ｆ）のパケットを送信する。ここで、「Ｆ」はダミー情報であるものとする。（α  ＸＯＲ  Ｆ）のパケットについて「ＮＣ＿ｆｌａｇ３＝１」がセットされる。
【０１９６】
次に、車両ＤがパケットβをＮＣ処理なしで送信したものとする。このとき、パケットβには、「ＮＣ＿ｆｌａｇ＝０」、「ＮＣ＿ｆｌａｇ２＝１」、及び「ＮＣ＿ｆｌａｇ３＝Ｘ」が設定される。
【０１９７】
次に、車両Ｃにおいて、車両Ｄからパケットβが受信され、車両Ｃのプロトコル２側バッファが「Ｆ」から「β」に変更される。
【０１９８】
そして、車両Ｃにおいて、車両Ｂから送出されたパケット（α  ＸＯＲ  Ｆ）が受信される。車両Ｃでは、パケット（α  ＸＯＲ  Ｆ）のヘッダ情報から、ネットワークコーディング処理有、ダミー情報使用と認識される。そして、車両Ｃでネットワーク復号処理が実行され「（α  ＸＯＲ  Ｆ）  ＸＯＲ  Ｆ＝α」が得られる。車両Ｃは、プロトコル１側からの受信情報（α）とプロトコル２側のバッファ情報（β）とネットワークコーディング処理（符号化）して、（α  ＸＯＲ  β）を送信する。
【０１９９】
そして、車両Ｄにおいて、自身がプロトコル２側で送信したパケットβとプロトコル１側での受信情報（α  ＸＯＲ  β）とで、ネットワークコーディング復号処理（（α  ＸＯＲ  β）ＸＯＲ  β）を行なうことで、車両Ａからのパケット情報αを得ることができる。
【０２００】
同様に、車両Ｄから車両Ａに対しても、ネットワークコーディング処理を行なって、送信することで、通信システム１０００では、接続の二重化を図ることが可能となる。
【０２０１】
以上のように第３の実施形態の通信システム１０００では、プロトコル１及びプロトコル２は、データが伝達される方向で、トラフィックが独立になる様に分けている。従って、第３の実施形態の通信システム１０００を構成する各車両の端末１００は、プロトコル１で受信した場合は、プロトコル１の送信タイミングに従い、プロトコル２で受信した場合は、プロトコル２の送信タイミングに従って送信する。よって、第３の実施形態の通信システム１０００を構成する各車両の端末１００は、送信処理フローでリアルタイム性要求か否かで、受信情報が届くまで待つか否かの処理を削除して行なう。
【０２０２】
次に、第３の実施形態の通信システム１０００を構成する各車両（端末１００）が行うパケットの送信処理について図２３のフローチャートを用いて説明する。図２３のフローチャートは、ほぼ第１の実施形態のフローチャート（上述の図１２）と同様であるため、上述の図１２との差分のみ説明する。図２３のフローチャートは、バッファが空状態に際（ステップＳ２１２でＹｅｓの場合に待ち時間を挿入する処理等（ステップＳ２１３、Ｓ２１５の処理）が省略されている点で、第１の実施形態（上述の図１２）と異なっている。
【０２０３】
第１の実施形態の通信システム１０００を構成する各車両（各端末１００）のそれ以外の処理については、第１の実施形態とほぼ同様であるため詳しい説明は省略する。
【０２０４】
（Ｃ−３）第３の実施形態の効果
第３の実施形態によれば、以下のような効果を奏することができる。
【０２０５】
第３の実施形態の通信システム１０００では、中継転送数が複数である場合においても、第１、及び第２の実施形態と同様の効果を奏することができる。
【０２０６】
（Ｄ）他の実施形態
本発明は、上記の各実施形態に限定されるものではなく、以下に例示するような変形実施形態も挙げることができる。
【０２０７】
（Ｄ−１）上記の各実施形態において、各端末１００で、Ｌ３スイッチ１３０以下の層、ＰＨＹ層、ＭＡＣ層に関わる部分は無線ＬＡＮ（Ｗｉ−ｆｉ）を用いて、システムを構成しても良い。また、端末１００について、車々間通信の様な移動体通信のみならず、固定中継局を用いるマルチホップ通信にも適応可能である。
【符号の説明】
【０２０８】
１０００…通信システム、１００…端末（車両）、１１１…第１の無指向性アンテナ、１１２…第２の無指向性アンテナ、１２１…第１の無線ユニット、１２２…第２の無線ユニット、１２３…第１の物理送信部、１２４…第１・第２の物理受信部、１２５…第２の物理送信部、１２６…第１の送信信号処理部、１２７…第１・第２の信号受信処理部、１２８…第２の信号送信処理部、１３０…Ｌ３スイッチ、１４０…ＧＰＳ装置、１５０…ネットワーク制御部、１５１…マルチホップ制御部、１５２…プロトコル選択部、１５３…周辺端末監視部、１５４…自端末情報部、１５５…バッファ、１５６…ＮＣ符号化部、１５７…ＮＣ復号部、１５８…送信情報、１５９…受信情報、１６０…上位層。
【図１】
2015162878.tif 000003
【図２】
2015162878.tif 000004
【図３】
2015162878.tif 000005
【図４】
2015162878.tif 000006
【図５】
2015162878.tif 000007
【図６】
2015162878.tif 000008
【図７】
2015162878.tif 000009
【図８】
2015162878.tif 000010
【図９】
2015162878.tif 000011
【図１０】
2015162878.tif 000012
【図１１】
2015162878.tif 000013
【図１２】
2015162878.tif 000014
【図１３】
2015162878.tif 000015
【図１４】
2015162878.tif 000016
【図１５】
2015162878.tif 000017
【図１６】
2015162878.tif 000018
【図１７】
2015162878.tif 000019
【図１８】
2015162878.tif 000020
【図１９】
2015162878.tif 000021
【図２０】
2015162878.tif 000022
【図２１】
2015162878.tif 000023
【図２２】
2015162878.tif 000024
【図２３】
2015162878.tif 000025
【手続補正書】
【提出日】平成27年5月11日(2015.5.11)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
データ伝達方向により異なる通信方式により無線通信を行ない、受信したデータを中継転送する際に、自装置が中継転送しようとするデータと、当該データ受信とは異なる通信方式で受信したデータをネットワークコーディングし、そのネットワークコーディングにより得られたネットワークコーディングデータを中継転送する無線通信手段を有し、
上記無線通信手段は、中継転送の１回目のデータについては当該データのネットワークコーディング符号化を行って次の送信先に中継転送し、中継転送の２回目以降のデータを受信した場合は当該データをネットワークコーディング復号して復号後のデータを用いてネットワークコーディング符号化を行って次の送信先に中継転送する
ことを特徴とする無線通信装置。
【請求項２】
第１の伝達方向の中継転送に係る第１の通信方式で受信した受信情報を一時的に保留して、ネットワークコーディングに適用するためのバッファ手段をさらに備え、
上記無線通信手段は、第２の伝達方向にのみ中継転送が発生し上記バッファ手段の保留状態が空の場合には、予め既定したダミーデータを用いてネットワークコーディングを行う
ことを特徴とする請求項１に記載の無線通信装置。
【請求項３】
上記無線通信手段は、ネットワークコーディングを行おうとする際に、上記バッファ手段の保留状態が空の場合、所定期間待機し、待機した結果上記第１の伝達方向の中継転送が発生して上記バッファ手段に受信情報が保留された場合、その受信情報を用いて、ネットワークコーディングを行うことを特徴とする請求項２に記載の無線通信装置。
【請求項４】
上記無線通信手段は、データ伝達方向に応じて異なるプロトコルを用いて無線通信を行うことを特徴とする請求項１に記載の無線通信装置。
【請求項５】
上記無線通信手段は、マルチホップ通信に係る中継転送を行なう際、次ホップの無線通信装置がさらに中継転送したか否かによって、次ホップの無線通信装置への中継転送が成功したか否かを判断する確認応答代替処理を行うことを特徴とする請求項４に記載の無線通信装置。
【請求項６】
自装置を宛先とするデータを受信した場合、当該データの送信元の方向へ中継転送するデータに対して、当該データを正しく受信したことを知らせるフラグを付加することを特徴とする請求項４又は５に記載の無線通信装置。
【請求項７】
無線通信装置が行う無線通信方法において、
無線通信手段を備え、
上記無線通信手段は、データ伝達方向により異なる通信方式により無線通信を行ない、受信したデータを中継転送する際に、自装置が中継転送しようとするデータと、当該データ受信とは異なる通信方式で受信したデータをネットワークコーディングし、そのネットワークコーディングにより得られたネットワークコーディングデータを中継転送し、
上記無線通信手段は、中継転送の１回目のデータについては当該データのネットワークコーディング符号化を行って次の送信先に中継転送し、中継転送の２回目以降のデータを受信した場合当該データをネットワークコーディング復号して復号後のデータを用いてネットワークコーディング符号化を行って次の送信先に中継転送する
ことを特徴とする無線通信方法。
【請求項８】
複数の無線通信装置を備える通信システムにおいて、それぞれの上記無線通信装置として請求項１〜６のいずれかに記載の無線通信装置を備えることを特徴とする通信システム。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】００１５
【補正方法】変更
【補正の内容】
【００１５】
第１の本発明の無線通信装置は、（１）データ伝達方向により異なる通信方式により無線通信を行ない、受信したデータを中継転送する際に、自装置が中継転送しようとするデータと、当該データ受信とは異なる通信方式で受信したデータをネットワークコーディングし、そのネットワークコーディングにより得られたネットワークコーディングデータを中継転送する無線通信手段を有し、（２）上記無線通信手段は、中継転送の１回目のデータについては当該データのネットワークコーディング符号化を行って次の送信先に中継転送し、中継転送の２回目以降のデータを受信した場合当該データをネットワークコーディング復号して復号後のデータを用いてネットワークコーディング符号化を行って次の送信先に中継転送することを特徴とする。
【手続補正３】
【補正対象書類名】明細書
【補正対象項目名】００１６
【補正方法】変更
【補正の内容】
【００１６】
第２の本発明は、無線通信装置が行う無線通信方法において、（１）無線通信手段を備え、（２）上記無線通信手段は、データ伝達方向により異なる通信方式により無線通信を行ない、受信したデータを中継転送する際に、自装置が中継転送しようとするデータと、当該データ受信とは異なる通信方式で受信したデータをネットワークコーディングし、そのネットワークコーディングにより得られたネットワークコーディングデータを中継転送し、（３）上記無線通信手段は、中継転送の１回目のデータについては当該データのネットワークコーディング符号化を行って次の送信先に中継転送し、中継転送の２回目以降のデータを受信した場合当該データをネットワークコーディング復号して復号後のデータを用いてネットワークコーディング符号化を行って次の送信先に中継転送することを特徴とする。