JP6654136B2 - 受信端末及び送信端末 - Google Patents

Description

本発明は、Ｄ２Ｄ近傍サービスをサポートする移動通信システムにおいてＤ２Ｄ通信を行う受信端末及び送信端末に関する。

移動通信システムの標準化プロジェクトである３ＧＰＰ（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ）では、リリース１２以降の新機能として、端末間（Ｄｅｖｉｃｅ ｔｏ Ｄｅｖｉｃｅ：Ｄ２Ｄ）近傍サービスの導入が検討されている（非特許文献１参照）。

移動通信システムにおいては、ＰＤＵ（Ｐｒｏｔｏｃｏｌ Ｄａｔａ Ｕｎｉｔ）に含まれるヘッダのオーバヘッドを削減する技術として、ヘッダ圧縮技術が検討されている。具体的には、非圧縮ヘッダは、不変の値を格納する静的ヘッダ及び可変の値を格納する動的ヘッダを含む。一方で、圧縮ヘッダは、静的ヘッダを特定するための識別情報（ＣＩＤ；Ｃｏｎｔｅｘｔ ＩＤ）及び動的ヘッダを含む。すなわち、ヘッダ圧縮技術では、静的ヘッダを識別情報で代替することによって、ヘッダのオーバヘッドが削減されている。

ところで、上述した３ＧＰＰでは、上述したＤ２Ｄ近傍サービス（Ｄ２Ｄ ＰｒｏＳｅ）にもヘッダ圧縮技術を用いることが検討されている。しかしながら、Ｄ２Ｄ近傍サービスでは、受信端末において受信エンティティ（ＰＤＣＰレイヤ）が形成されるタイミングが送信端末において送信エンティティ（ＰＤＣＰレイヤ）が形成されるタイミングと異なる。従って、受信エンティティの形成前に、非圧縮ヘッダを受信することなく圧縮ヘッダを受信すると、受信端末が圧縮ヘッダを解読することができない。

３ＧＰＰ技術報告書 「ＴＲ ３６．８４３ Ｖ１２．０．１」 ２０１４年３月

第１の特徴は、Ｄ２Ｄ近傍サービスをサポートする移動通信システムにおいて送信端末とＤ２Ｄ通信を行う受信端末であって、前記Ｄ２Ｄ通信において、データ及びヘッダによって構成されるデータユニットを前記送信端末から受信する受信部と、前記ヘッダとして圧縮ヘッダが用いられている場合に、前記圧縮ヘッダの解読に失敗しても、前記圧縮ヘッダを含む前記データユニットを所定期間に亘って保持する制御部とを備え、前記Ｄ２Ｄ通信において、前記受信端末において受信エンティティを形成するタイミングは、前記送信端末において送信エンティティを形成するタイミングと異なることを要旨とする。

第２の特徴は、Ｄ２Ｄ近傍サービスをサポートする移動通信システムにおいて送信端末とＤ２Ｄ通信を行う受信端末であって、前記Ｄ２Ｄ通信において、データ及びヘッダによって構成されるデータユニットを前記送信端末から受信する受信部と、前記Ｄ２Ｄ通信において前記データユニットを受信するための受信エンティティを形成する制御部とを備え、前記制御部は、前記受信エンティティとは別に、前記Ｄ２Ｄ通信において前記データユニットに対するフィードバックを送信するためのフィードバック送信エンティティを形成し、前記Ｄ２Ｄ通信において、前記受信エンティティを形成するタイミングは、前記送信端末において前記データユニットを送信するための送信エンティティを形成するタイミングと異なることを要旨とする。

第３の特徴は、Ｄ２Ｄ近傍サービスをサポートする移動通信システムにおいて受信端末とＤ２Ｄ通信を行う送信端末であって、前記Ｄ２Ｄ通信において、データ及びヘッダによって構成されるデータユニットを前記受信端末に送信する送信部と、前記Ｄ２Ｄ通信において前記データユニットを送信するための送信エンティティを形成する制御部とを備え、前記Ｄ２Ｄ通信は、ユニキャストＤ２Ｄ通信、グループキャストＤ２Ｄ通信又はブロードキャストＤ２Ｄ通信を含み、前記制御部は、前記グループキャストＤ２Ｄ通信又は前記ブロードキャストＤ２Ｄ通信において前記ヘッダとして圧縮ヘッダを用いずに、前記ユニキャストＤ２Ｄ通信において前記ヘッダとして前記圧縮ヘッダを用いており、前記Ｄ２Ｄ通信において、前記受信端末において前記データユニットを受信するための受信エンティティを形成するタイミングは、前記送信エンティティを形成するタイミングと異なることを要旨とする。

図１は、第１実施形態に係るＬＴＥシステムの構成図である。 図２は、第１実施形態に係るＵＥ１００のブロック図である。 図３は、第１実施形態に係るｅＮＢ２００のブロック図である。 図４は、第１実施形態に係る無線インターフェイスのプロトコルスタック図である。 図５は、第１実施形態に係るＬＴＥシステムで使用される無線フレームの構成図である。 図６は、第１実施形態に係る動作環境を示す図である。 図７は、第１実施形態に係る動作を示すシーケンス図である。 図８は、変更例１を説明するための図である。 図９は、変更例１を説明するための図である。 図１０は、変更例２を説明するための図である。 図１１は、変更例２を説明するための図である。

以下において、本発明の実施形態に係るＤ２Ｄ近傍サービスについて、図面を参照しながら説明する。なお、以下の図面の記載において、同一又は類似の部分には、同一又は類似の符号を付している。

ただし、図面は模式的なものであり、各寸法の比率などは現実のものとは異なることに留意すべきである。従って、具体的な寸法などは以下の説明を参酌して判断すべきである。また、図面相互間においても互いの寸法の関係や比率が異なる部分が含まれていることは勿論である。

［実施形態の概要］
第１に、実施形態に係る受信端末は、Ｄ２Ｄ近傍サービスをサポートする移動通信システムにおいて送信端末とＤ２Ｄ通信を行う。前記受信端末は、前記Ｄ２Ｄ通信において、データ及びヘッダによって構成されるデータユニットを前記送信端末から受信する受信部と、前記ヘッダとして圧縮ヘッダが用いられている場合に、前記圧縮ヘッダの解読に失敗しても、前記圧縮ヘッダを含む前記データユニットを所定期間に亘って保持する制御部とを備える。前記Ｄ２Ｄ通信において、前記受信端末において受信エンティティを形成するタイミングは、前記送信端末において送信エンティティを形成するタイミングと異なる。

このような実施形態では、受信端末は、圧縮ヘッダの解読に失敗しても、圧縮ヘッダを含むデータユニットを所定期間に亘って保持する。従って、受信端末は、圧縮ヘッダの解読に失敗した後に非圧縮ヘッダを含むデータユニットを受信する場合に、非圧縮ヘッダを参照することによって圧縮ヘッダを解読することができる。これによって、受信エンティティの形成タイミングが送信エンティティの形成タイミングと異なるケース、すなわち、受信エンティティの形成タイミングが送信エンティティの形成タイミングよりも遅いケースであっても、圧縮ヘッダを含むデータユニットの取りこぼしが抑制される。

第２に、実施形態に係る受信端末は、Ｄ２Ｄ近傍サービスをサポートする移動通信システムにおいて送信端末とＤ２Ｄ通信を行う。前記受信端末は、前記Ｄ２Ｄ通信において、データ及びヘッダによって構成されるデータユニットを前記送信端末から受信する受信部と、前記Ｄ２Ｄ通信において前記データユニットを受信するための受信エンティティを形成する制御部とを備える。前記制御部は、前記受信エンティティとは別に、前記Ｄ２Ｄ通信において前記データユニットに対するフィードバックを送信するためのフィードバック送信エンティティを形成する。前記Ｄ２Ｄ通信において、前記受信エンティティを形成するタイミングは、前記送信端末において前記データユニットを送信するための送信エンティティを形成するタイミングと異なる。

このような実施形態では、受信端末は、Ｄ２Ｄ通信においてデータユニットを受信するための受信エンティティとは別に、Ｄ２Ｄ通信においてデータユニットに対するフィードバックを送信するためのフィードバック送信エンティティを形成する。従って、受信エンティティの形成タイミングが送信エンティティの形成タイミングと異なるケース、すなわち、受信エンティティの形成タイミングを送信エンティティが把握していないケースであっても、受信エンティティから送信エンティティに送信されるフィードバックによって、圧縮ヘッダの解読に失敗した受信エンティティの存在を送信エンティティが把握できる。例えば、送信エンティティは、圧縮ヘッダの解読に失敗した旨のフィードバックに応じて、非圧縮ヘッダを含むデータユニットを送信することができる。

なお、３ＧＰＰで仕様化中のＤ２Ｄ通信では、少なくともＬ２（後述するＭＡＣ層、ＲＬＣ層及びＰＤＣＰ層）において受信端末から送信端末へのフィードバックが存在しない通信モード（Ｕ−Ｍｏｄｅ）が規定されている。言い換えると、受信エンティティから送信エンティティに対してフィードバックを送信する機能が存在しない。従って、受信エンティティとは別にフィードバック送信エンティティを形成する必要があることに留意すべきである。

第３に、実施形態に係る送信端末は、Ｄ２Ｄ近傍サービスをサポートする移動通信システムにおいて受信端末とＤ２Ｄ通信を行う。前記送信端末は、前記Ｄ２Ｄ通信において、データ及びヘッダによって構成されるデータユニットを前記受信端末に送信する送信部と、前記Ｄ２Ｄ通信において前記データユニットを送信するための送信エンティティを形成する制御部とを備える。前記Ｄ２Ｄ通信は、ユニキャストＤ２Ｄ通信、グループキャストＤ２Ｄ通信又はブロードキャストＤ２Ｄ通信を含む。前記制御部は、前記グループキャストＤ２Ｄ通信又は前記ブロードキャストＤ２Ｄ通信において前記ヘッダとして圧縮ヘッダを用いずに、前記ユニキャストＤ２Ｄ通信において前記ヘッダとして前記圧縮ヘッダを用いる。前記Ｄ２Ｄ通信において、前記受信端末において前記データユニットを受信するための受信エンティティを形成するタイミングは、前記送信エンティティを形成するタイミングと異なる。

このような実施形態では、送信端末は、グループキャストＤ２Ｄ通信又はブロードキャストＤ２Ｄ通信においてヘッダとして圧縮ヘッダを用いずに、ユニキャストＤ２Ｄ通信においてヘッダとして圧縮ヘッダを用いる。従って、グループキャストＤ２Ｄ通信又はブロードキャストＤ２Ｄ通信に途中から参加するユーザ端末の受信エンティティの形成タイミングを送信エンティティが把握していないケースであっても、圧縮ヘッダの解読失敗が生じる事態が抑制される。一方で、ユニキャストＤ２Ｄ通信では、受信エンティティの形成タイミングが送信エンティティの形成タイミングと異なるため、圧縮ヘッダの解読失敗が生じる可能性があるが、圧縮ヘッダの解読失敗が生じる事態よりも、ヘッダ圧縮技術によって得られるオーバヘッドの削減が優先されていることに留意すべきである。

なお、無線基地局とユーザ端末との間のセルラ通信では、受信エンティティの形成タイミングが送信エンティティの形成タイミングと同じであるため、圧縮ヘッダの解読に失敗するケースが想定されていないことに留意すべきである。すなわち、圧縮ヘッダの解読に失敗する課題は、Ｄ２Ｄ通信の検討で新たに生じた課題であることに留意すべきである。これに対して、発明者等は、鋭意検討の結果、上述した３つの実施形態によって、圧縮ヘッダの解読に失敗する課題を解決していることに留意すべきである。

［第１実施形態］
以下において、移動通信システムとして、３ＧＰＰ規格に基づいたＬＴＥシステムを例に挙げて、第１実施形態を説明する。

（１）システム構成
第１実施形態に係るＬＴＥシステムのシステム構成について説明する。図１は、第１実施形態に係るＬＴＥシステムの構成図である。

図１に示すように、第１実施形態に係るＬＴＥシステムは、ＵＥ（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）１００、Ｅ−ＵＴＲＡＮ（Ｅｖｏｌｖｅｄ−ＵＭＴＳ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ）１０、及びＥＰＣ（Ｅｖｏｌｖｅｄ Ｐａｃｋｅｔ Ｃｏｒｅ）２０を備える。

ＵＥ１００は、ユーザ端末に相当する。ＵＥ１００は、移動型の通信装置であり、ｅＮＢ２００によって形成されるセル（ＵＥ１００がＲＲＣコネクティッド状態である場合には、サービングセル）との無線通信を行う。ＵＥ１００の構成については後述する。

Ｅ−ＵＴＲＡＮ１０は、無線アクセスネットワークに相当する。Ｅ−ＵＴＲＡＮ１０は、ｅＮＢ２００（ｅｖｏｌｖｅｄ Ｎｏｄｅ−Ｂ）を含む。ｅＮＢ２００は、無線基地局に相当する。ｅＮＢ２００は、Ｘ２インターフェイスを介して相互に接続される。ｅＮＢ２００の構成については後述する。

ｅＮＢ２００は、１又は複数のセルを形成しており、自セルとの接続を確立したＵＥ１００との無線通信を行う。ｅＮＢ２００は、無線リソース管理（ＲＲＭ）機能、ユーザデータのルーティング機能、モビリティ制御・スケジューリングのための測定制御機能などを有する。「セル」は、無線通信エリアの最小単位を示す用語として使用される他に、ＵＥ１００との無線通信を行う機能を示す用語としても使用される。

ＥＰＣ２０は、コアネットワークに相当する。ＥＰＣ２０は、ＭＭＥ（Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ）／Ｓ−ＧＷ（Ｓｅｒｖｉｎｇ−Ｇａｔｅｗａｙ）３００を含む。ＭＭＥは、ＵＥ１００に対する各種モビリティ制御などを行う。Ｓ−ＧＷは、ユーザデータの転送制御を行う。ＭＭＥ／Ｓ−ＧＷ３００は、Ｓ１インターフェイスを介してｅＮＢ２００と接続される。なお、Ｅ−ＵＴＲＡＮ１０及びＥＰＣ２０は、ＬＴＥシステムのネットワークを構成する。

図２は、ＵＥ１００のブロック図である。図２に示すように、ＵＥ１００は、複数のアンテナ１０１、無線送受信機１１０、ユーザインターフェイス１２０、ＧＮＳＳ（Ｇｌｏｂａｌ Ｎａｖｉｇａｔｉｏｎ Ｓａｔｅｌｌｉｔｅ Ｓｙｓｔｅｍ）受信機１３０、バッテリ１４０、メモリ１５０、及びプロセッサ１６０を備える。メモリ１５０及びプロセッサ１６０は、制御部を構成する。無線送受信機１１０及びプロセッサ１６０は、送信部及び受信部を構成する。ＵＥ１００は、ＧＮＳＳ受信機１３０を有していなくてもよい。また、メモリ１５０をプロセッサ１６０と一体化し、このセット（すなわち、チップセット）をプロセッサとしてもよい。

アンテナ１０１及び無線送受信機１１０は、無線信号の送受信に用いられる。無線送受信機１１０は、プロセッサ１６０が出力するベースバンド信号（送信信号）を無線信号に変換してアンテナ１０１から送信する。また、無線送受信機１１０は、アンテナ１０１が受信する無線信号をベースバンド信号（受信信号）に変換してプロセッサ１６０に出力する。

ユーザインターフェイス１２０は、ＵＥ１００を所持するユーザとのインターフェイスであり、例えば、ディスプレイ、マイク、スピーカ、及び各種ボタンなどを含む。ユーザインターフェイス１２０は、ユーザからの操作を受け付けて、受け付けた操作の内容を示す信号をプロセッサ１６０に出力する。ＧＮＳＳ受信機１３０は、ＵＥ１００の地理的な位置を示す位置情報を得るために、ＧＮＳＳ信号を受信して、受信した信号をプロセッサ１６０に出力する。バッテリ１４０は、ＵＥ１００の各ブロックに供給すべき電力を蓄える。

メモリ１５０は、プロセッサ１６０により実行されるプログラム、及びプロセッサ１６０による処理に使用される情報を記憶する。プロセッサ１６０は、ベースバンド信号の変調・復調及び符号化・復号などを行うベースバンドプロセッサと、メモリ１５０に記憶されるプログラムを実行して各種の処理を行うＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）とを含む。プロセッサ１６０は、さらに、音声・映像信号の符号化・復号を行うコーデックを含んでもよい。プロセッサ１６０は、後述する各種の処理及び各種の通信プロトコルを実行する。

図３は、ｅＮＢ２００のブロック図である。図３に示すように、ｅＮＢ２００は、複数のアンテナ２０１、無線送受信機２１０、ネットワークインターフェイス２２０、メモリ２３０、及びプロセッサ２４０を備える。メモリ２３０及びプロセッサ２４０は、制御部を構成する。無線送受信機２１０（及び／又はネットワークインターフェイス２２０）及びプロセッサ２４０は、送信部及び受信部を構成する。また、メモリ２３０をプロセッサ２４０と一体化し、このセット（すなわち、チップセット）をプロセッサとしてもよい。

アンテナ２０１及び無線送受信機２１０は、無線信号の送受信に用いられる。無線送受信機２１０は、プロセッサ２４０が出力するベースバンド信号（送信信号）を無線信号に変換してアンテナ２０１から送信する。また、無線送受信機２１０は、アンテナ２０１が受信する無線信号をベースバンド信号（受信信号）に変換してプロセッサ２４０に出力する。

ネットワークインターフェイス２２０は、Ｘ２インターフェイスを介して隣接ｅＮＢ２００と接続され、Ｓ１インターフェイスを介してＭＭＥ／Ｓ−ＧＷ３００と接続される。ネットワークインターフェイス２２０は、Ｘ２インターフェイス上で行う通信及びＳ１インターフェイス上で行う通信に用いられる。

メモリ２３０は、プロセッサ２４０により実行されるプログラム、及びプロセッサ２４０による処理に使用される情報を記憶する。プロセッサ２４０は、ベースバンド信号の変調・復調及び符号化・復号などを行うベースバンドプロセッサと、メモリ２３０に記憶されるプログラムを実行して各種の処理を行うＣＰＵとを含む。プロセッサ２４０は、後述する各種の処理及び各種の通信プロトコルを実行する。

図４は、ＬＴＥシステムにおける無線インターフェイスのプロトコルスタック図である。図４に示すように、無線インターフェイスプロトコルは、ＯＳＩ参照モデルの第１層乃至第３層に区分されており、第１層は物理（ＰＨＹ）層である。第２層は、ＭＡＣ（Ｍｅｄｉｕｍ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）層、ＲＬＣ（Ｒａｄｉｏ Ｌｉｎｋ Ｃｏｎｔｒｏｌ）層、及びＰＤＣＰ（Ｐａｃｋｅｔ Ｄａｔａ Ｃｏｎｖｅｒｇｅｎｃｅ Ｐｒｏｔｏｃｏｌ）層を含む。第３層は、ＲＲＣ（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ）層を含む。

物理層は、符号化・復号、変調・復調、アンテナマッピング・デマッピング、及びリソースマッピング・デマッピングを行う。ＵＥ１００の物理層とｅＮＢ２００の物理層との間では、物理チャネルを介してユーザデータ及び制御情報が伝送される。

ＭＡＣ層は、データの優先制御、ハイブリッドＡＲＱ（ＨＡＲＱ）による再送処理、及びランダムアクセス手順などを行う。ＵＥ１００のＭＡＣ層とｅＮＢ２００のＭＡＣ層との間では、トランスポートチャネルを介してユーザデータ及び制御情報が伝送される。ｅＮＢ２００のＭＡＣ層は、上下リンクのトランスポートフォーマット（トランスポートブロックサイズ、変調・符号化方式（ＭＣＳ））及びＵＥ１００への割当リソースブロックを決定するスケジューラを含む。

ＲＬＣ層は、ＭＡＣ層及び物理層の機能を利用してデータを受信側のＲＬＣ層に伝送する。ＵＥ１００のＲＬＣ層とｅＮＢ２００のＲＬＣ層との間では、論理チャネルを介してユーザデータ及び制御情報が伝送される。

ＰＤＣＰ層は、ヘッダ圧縮・伸張、及び暗号化・復号化を行う。また、ＰＤＣＰ層には、Ｄ２Ｄ通信でデータユニット（ＰＤＣＰ ＰＤＵ）を送信するための送信エンティティ又はＤ２Ｄ通信でデータユニット（ＰＤＣＰ ＰＤＵ）を受信するための受信エンティティが形成されることに留意すべきである。

ＲＲＣ層は、制御情報を取り扱う制御プレーンでのみ定義される。ＵＥ１００のＲＲＣ層とｅＮＢ２００のＲＲＣ層との間では、各種設定のための制御情報（ＲＲＣメッセージ）が伝送される。ＲＲＣ層は、無線ベアラの確立、再確立及び解放に応じて、論理チャネル、トランスポートチャネル、及び物理チャネルを制御する。ＵＥ１００のＲＲＣとｅＮＢ２００のＲＲＣとの間に接続（ＲＲＣ接続）がある場合に、ＵＥ１００はＲＲＣコネクティッド状態であり、ＵＥ１００のＲＲＣとｅＮＢ２００のＲＲＣとの間に接続（ＲＲＣ接続）がない場合に、ＵＥ１００はＲＲＣアイドル状態である。

ＲＲＣ層の上位に位置するＮＡＳ（Ｎｏｎ−Ａｃｃｅｓｓ Ｓｔｒａｔｕｍ）層は、セッション管理及びモビリティ管理などを行う。

図５は、ＬＴＥシステムで使用される無線フレームの構成図である。ＬＴＥシステムは、下りリンクにはＯＦＤＭＡ（Ｏｒｔｈｏｇｏｎａｌ Ｆｒｅｑｕｅｎｃｙ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅｘｉｎｇ Ａｃｃｅｓｓ）、上りリンクにはＳＣ−ＦＤＭＡ（Ｓｉｎｇｌｅ Ｃａｒｒｉｅｒ Ｆｒｅｑｕｅｎｃｙ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ）がそれぞれ適用される。

図５に示すように、無線フレームは、時間方向に並ぶ１０個のサブフレームで構成される。各サブフレームは、時間方向に並ぶ２個のスロットで構成される。各サブフレームの長さは１ｍｓであり、各スロットの長さは０．５ｍｓである。各サブフレームは、周波数方向に複数個のリソースブロック（ＲＢ）を含み、時間方向に複数個のシンボルを含む。各リソースブロックは、周波数方向に複数個のサブキャリアを含む。１つのシンボル及び１つのサブキャリアにより１つのリソースエレメント（ＲＥ）が構成される。また、ＵＥ１００に割り当てられる無線リソース（時間・周波数リソース）のうち、周波数リソースはリソースブロックにより特定でき、時間リソースはサブフレーム（又はスロット）により特定できる。

（２）Ｄ２Ｄ近傍サービス
以下において、Ｄ２Ｄ近傍サービスについて説明する。第１実施形態に係るＬＴＥシステムは、Ｄ２Ｄ近傍サービスをサポートする。

Ｄ２Ｄ近傍サービスは、直接的なＵＥ間通信を可能とするサービスである。Ｄ２Ｄ近傍サービスは、近傍ＵＥを発見する発見手順（Ｄｉｓｃｏｖｅｒｙ）と、直接的なＵＥ間通信であるＤ２Ｄ通信（Ｃｏｍｍｕｎｉｃａｔｉｏｎ）とを含む。Ｄ２Ｄ通信は、Ｄｉｒｅｃｔ ｃｏｍｍｕｎｉｃａｔｉｏｎとも称される。

同期クラスタを形成する全てのＵＥ１００が１以上のセルのカバレッジ内に位置するシナリオを「カバレッジ内（Ｉｎ ｃｏｖｅｒａｇｅ）」という。同期クラスタを形成する全てのＵＥ１００が１以上のセルのカバレッジ外に位置するシナリオを「カバレッジ外（Ｏｕｔ ｏｆ ｃｏｖｅｒａｇｅ）」という。同期クラスタを形成する複数のＵＥ１００のうち、一部のＵＥ１００が１以上のセルのカバレッジ内に位置し、残りのＵＥ１００が１以上のセルのカバレッジ外に位置するシナリオを「部分的カバレッジ（Ｐａｒｔｉａｌ ｃｏｖｅｒａｇｅ）」という。

カバレッジ内では、ｅＮＢ２００がＤ２Ｄ同期元となる。Ｄ２Ｄ非同期元は、Ｄ２Ｄ同期信号を送信せずにＤ２Ｄ同期元に同期する。Ｄ２Ｄ同期元であるｅＮＢ２００は、Ｄ２Ｄ近傍サービスに使用可能な無線リソース（リソースプール）を示すＤ２Ｄリソース情報を含むブロードキャスト信号を報知する。Ｄ２Ｄリソース情報は、例えば、発見手順用のリソースプールを示す情報（Ｄｉｓｃｏｖｅｒｙリソース情報）及びＤ２Ｄ通信用のリソースプールを示す情報（Ｃｏｍｍｕｎｉｃａｔｉｏｎリソース情報）を含む。Ｄ２Ｄ非同期元であるＵＥ１００は、ｅＮＢ２００から受信するＤ２Ｄリソース情報に基づいて、発見手順及びＤ２Ｄ通信を行う。

カバレッジ外又は部分的カバレッジでは、ＵＥ１００がＤ２Ｄ同期元となる。カバレッジ外では、Ｄ２Ｄ同期元であるＵＥ１００は、Ｄ２Ｄ近傍サービスに使用可能な無線リソース（リソースプール）を示すＤ２Ｄリソース情報を送信する。Ｄ２Ｄリソース情報は、例えば、Ｄ２Ｄ同期信号に含まれる。Ｄ２Ｄ同期信号は、端末間同期を確立する同期手順において送信される信号である。Ｄ２Ｄ同期信号は、Ｄ２Ｄ ＳＳ及び物理Ｄ２Ｄ同期チャネル（ＰＤ２ＤＳＣＨ）を含む。ＰＤ２ＤＳＣＨは、ＰＳＢＣＨ （Ｐｈｙｓｉｃａｌ Ｓｉｄｅｌｉｎｋ Ｂｒｏａｄｃａｓｔ Ｃｈａｎｎｅｌ）と称されてもよい。Ｄ２Ｄ ＳＳは、時間及び周波数の同期基準を提供する信号である。ＰＤ２ＤＳＣＨは、Ｄ２Ｄ ＳＳよりも多くの情報を搬送する物理チャネルである。ＰＤ２ＤＳＣＨは、上述したＤ２Ｄリソース情報（Ｄｉｓｃｏｖｅｒｙリソース情報、Ｃｏｍｍｕｎｉｃａｔｉｏｎリソース情報）を搬送する。或いは、Ｄ２Ｄ ＳＳにＤ２Ｄリソース情報を予め関連付けることによって、ＰＤ２ＤＳＣＨの送信が省略されてもよい。

第１実施形態では、Ｄ２Ｄ通信は、１対１の通信であるユニキャストＤ２Ｄ通信、１対多の通信であるグループキャストＤ２Ｄ通信（又はブロードキャストＤ２Ｄ通信）を含む。グループキャストＤ２Ｄ通信では、１つの送信端末から複数の受信端末によって構成されるグループ宛にデータユニットが送信される。ブロードキャストＤ２Ｄ通信では、１つの送信端末からデータユニットがブロードキャストにて送信される。

（３）動作環境
以下において、第１実施形態に係る動作環境について説明する。図６は、第１実施形態に係る動作環境を示す図である。図６では、Ｄ２Ｄ通信としてグループキャストＤ２Ｄ通信が行われるケースについて主として説明する。

第１実施形態では、ＵＥ１００＃１とＵＥ１００＃２との間でグループキャストＤ２Ｄ通信が開始した後に、ＵＥ１００＃３がグループキャストＤ２Ｄ通信に参加するケースを想定する。ここで、ＵＥ１００＃１は送信端末の一例であり、ＵＥ１００＃２及びＵＥ１００＃３は受信端末の一例である。

このようなケースにおいて、ＵＥ１００＃１は、データユニット（ＰＤＣＰ ＰＤＵ）に含まれるヘッダのオーバヘッドを削減する技術としてヘッダ圧縮技術（ＲｏＨＣ；Ｒｏｂｕｓｔｎｅｓｓ Ｈｅａｄｅｒ Ｃｏｍｐｒｅｓｓｉｏｎ）を用いる。非圧縮ヘッダは、不変の値を格納する静的ヘッダ及び可変の値を格納する動的ヘッダを含む。一方で、圧縮ヘッダは、静的ヘッダを特定するための識別情報（ＣＩＤ；Ｃｏｎｔｅｘｔ ＩＤ）及び動的ヘッダを含む。すなわち、ヘッダ圧縮技術では、静的ヘッダを識別情報で代替することによって、ヘッダのオーバヘッドが削減されている。ここで、非圧縮ヘッダを含むデータユニットは定期的に送信されること留意すべきである（リフレッシュ）。

このような動作環境において、ＵＥ１００＃１、ＵＥ１００＃２及びＵＥ１００＃３の動作について図７を参照しながら説明する。図７は、第１実施形態に係る通信方法を示すシーケンス図である。

図７に示すように、ステップＳ１１において、ＵＥ１００＃１の制御部（すなわち、メモリ１５０及びプロセッサ１６０）は、ＰＤＣＰ層においてデータユニット（ＰＤＣＰ ＰＤＵ）を送信するための送信エンティティを形成する。

ステップＳ１２において、ＵＥ１００＃２の制御部（すなわち、メモリ１５０及びプロセッサ１６０）は、ＰＤＣＰ層においてデータユニット（ＰＤＣＰ ＰＤＵ）を受信するための受信エンティティを形成する。ここで、ＵＥ１００＃２において受信エンティティを形成するタイミングは、ＵＥ１００＃１において送信エンティティを形成するタイミングと異なる。さらに、ＵＥ１００＃１の送信エンティティは、ＵＥ１００＃２の受信エンティティの形成タイミングを把握していない。

ステップＳ１３において、ＵＥ１００＃１とＵＥ１００＃２との間でＤ２Ｄ通信（ここでは、グループキャストＤ２Ｄ通信）が開始する。

ステップＳ１４において、ＵＥ１００＃３の制御部（すなわち、メモリ１５０及びプロセッサ１６０）は、ＰＤＣＰ層においてデータユニット（ＰＤＣＰ ＰＤＵ）を受信するための受信エンティティを形成する。ここで、ＵＥ１００＃３において受信エンティティを形成するタイミングは、ＵＥ１００＃１において送信エンティティを形成するタイミングと異なる。さらに、ＵＥ１００＃１の送信エンティティは、ＵＥ１００＃３の受信エンティティの形成タイミングを把握していない。

ステップＳ１５において、ＵＥ１００＃３は、ＵＥ１００＃１とＵＥ１００＃２との間で行われているＤ２Ｄ通信（ここでは、グループキャストＤ２Ｄ通信）に参加する。

ステップＳ１６において、ＵＥ１００＃１は、圧縮ヘッダを含むデータユニット（ＰＤＣＰ ＰＤＵ）を送信する。ここでは、ＵＥ１００＃２がステップＳ１６よりも前に非圧縮ヘッダを含むデータユニット（ＰＤＣＰ ＰＤＵ）を受信しており、ＵＥ１００＃３がステップＳ１６よりも前に非圧縮ヘッダを含むデータユニット（ＰＤＣＰ ＰＤＵ）を受信していないケースを想定する。

ステップＳ１７において、ＵＥ１００＃２は、非圧縮ヘッダを既に受信しているため、圧縮ヘッダの解読に成功する。すなわち、ＵＥ１００＃２は、ステップＳ１６で送信されるデータユニット（ＰＤＣＰ ＰＤＵ）の受信に成功する。

ステップＳ１８において、ＵＥ１００＃３は、非圧縮ヘッダを未だ受信していないため、圧縮ヘッダの解読に失敗する。

ステップＳ１９において、ＵＥ１００＃３は、ステップＳ１６で受信するデータユニット（ＰＤＣＰ ＰＤＵ）を所定期間に亘って保持する。所定期間は、ヘッダとして非圧縮ヘッダを含むデータユニットの受信周期よりも長いことが好ましい。或いは、所定期間は、圧縮ヘッダの解読に失敗してから、ヘッダとして非圧縮ヘッダを含むデータユニットを受信するまでの期間であることが好ましい。

ステップＳ２０において、ＵＥ１００＃１は、非圧縮ヘッダを含むデータユニット（ＰＤＣＰ ＰＤＵ）を送信する。

ステップＳ２１において、ＵＥ１００＃２は、ステップＳ２０で送信されるデータユニット（ＰＤＣＰ ＰＤＵ）の受信に成功する。

ステップＳ２２において、ＵＥ１００＃３は、ステップＳ２０で送信されるデータユニット（ＰＤＣＰ ＰＤＵ）の受信に成功する。さらに、ＵＥ１００＃３は、ステップＳ２０で受信するデータユニット（ＰＤＣＰ ＰＤＵ）に含まれる非圧縮ヘッダを参照して、ステップＳ１６で受信するデータユニット（ＰＤＣＰ ＰＤＵ）に含まれる圧縮ヘッダを解読する。これによって、ＵＥ１００＃３は、ステップＳ１６で送信されるデータユニット（ＰＤＣＰ ＰＤＵ）を解読することができる。

上述したように、第１実施形態では、ＵＥ１００＃３（すなわち、受信端末）の制御部（すなわち、メモリ１５０及びプロセッサ１６０）は、ヘッダとして圧縮ヘッダが用いられている場合に、圧縮ヘッダの解読に失敗しても、圧縮ヘッダを含むデータユニットを所定期間に亘って保持する。所定期間は、ヘッダとして非圧縮ヘッダを含むデータユニットの受信周期よりも長いことが好ましい。或いは、所定期間は、圧縮ヘッダの解読に失敗してから、ヘッダとして非圧縮ヘッダを含むデータユニットを受信するまでの期間であることが好ましい。

図７では、ＵＥ１００＃２（すなわち、受信端末）がステップＳ１６よりも前に非圧縮ヘッダを含むデータユニット（ＰＤＣＰ ＰＤＵ）を既に受信しているケースを例示した。しかしながら、実施形態はこれに限定されるものではない。ＵＥ１００＃２（すなわち、受信端末）がステップＳ１６よりも前に非圧縮ヘッダを含むデータユニット（ＰＤＣＰ ＰＤＵ）を未だ受信していなくてもよい。このような場合には、ＵＥ１００＃２（すなわち、受信端末）は、ＵＥ１００＃３同様に、圧縮ヘッダを含むデータユニットを所定期間に亘って保持することに留意すべきである。

図７では、Ｄ２Ｄ通信としてグループキャストＤ２Ｄ通信が行われるケースを例示した。しかしながら、実施形態はこれに限定されるものではない。Ｄ２Ｄ通信は、ブロードキャストＤ２Ｄ通信であってもよく、ユニキャストＤ２Ｄ通信であってもよい。Ｄ２Ｄ通信がユニキャストＤ２Ｄ通信であっても、受信エンティティの形成タイミングが送信エンティティの形成タイミングと異なるため、受信エンティティが圧縮ヘッダの解読に失敗する可能性があることに留意すべきである。

（作用及び効果）
第１実施形態では、受信端末（例えば、ＵＥ１００＃３）は、圧縮ヘッダの解読に失敗しても、圧縮ヘッダを含むデータユニットを所定期間に亘って保持する。従って、受信端末は、圧縮ヘッダの解読に失敗した後に非圧縮ヘッダを含むデータユニットを受信する場合に、非圧縮ヘッダを参照することによって圧縮ヘッダを解読することができる。これによって、受信エンティティの形成タイミングが送信エンティティの形成タイミングと異なるケース、すなわち、受信エンティティの形成タイミングが送信エンティティの形成タイミングよりも遅いケースであっても、圧縮ヘッダを含むデータユニットの取りこぼしが抑制される。

［変更例１］
以下において、第１実施形態の変更例１について説明する。以下においては、第１実施形態に対する差異について主として説明する。

具体的には、変更例１では、グループキャストＤ２Ｄ通信又はブロードキャストＤ２Ｄ通信におけるヘッダとして非圧縮ヘッダを含むデータユニットの受信周期は、ユニキャストＤ２Ｄ通信におけるヘッダとして非圧縮ヘッダを含むデータユニットの受信周期よりも短い。

詳細には、図８に示すように、ユニキャストＤ２Ｄ通信において、ＵＥ１００＃１（送信端末）は、ＵＥ１００＃２（受信端末）に対して、非圧縮ヘッダを含むデータユニット（ＰＤＣＰ ＰＤＵ）を周期Ｔ１で送信する。一方で、図９に示すように、グループキャストＤ２Ｄ通信又はブロードキャストＤ２Ｄ通信において、ＵＥ１００＃１（送信端末）は、ＵＥ１００＃２（受信端末）に対して、非圧縮ヘッダを含むデータユニット（ＰＤＣＰ ＰＤＵ）を周期Ｔ２で送信する。周期Ｔ２は周期Ｔ１よりも短い。

すなわち、グループキャストＤ２Ｄ通信又はブロードキャストＤ２Ｄ通信において非圧縮ヘッダを含むデータユニットを受信する周期Ｔ２は、ユニキャストＤ２Ｄ通信において非圧縮ヘッダを含むデータユニットを受信する周期Ｔ１よりも短い。

上述したように、受信端末の参加タイミングを把握しにくいグループキャストＤ２Ｄ通信又はブロードキャストＤ２Ｄ通信では、受信端末が非圧縮ヘッダを受信するタイミングを早めることによって、受信端末がデータユニットの受信に成功するタイミングも早まる。一方で、受信端末の参加タイミングを把握しやすいユニキャストＤ２Ｄ通信では、圧縮ヘッダの解読失敗が生じる事態よりも、ヘッダ圧縮技術によって得られるオーバヘッドの削減が優先されていることに留意すべきである。

［変更例２］
以下において、第１実施形態の変更例２について説明する。以下においては、第１実施形態に対する差異について主として説明する。

具体的には、第１実施形態では、受信端末（例えば、ＵＥ１００＃３）は、圧縮ヘッダの解読に失敗しても、圧縮ヘッダを含むデータユニットを所定期間に亘って保持する。一方で、変更例２では、受信端末（例えば、ＵＥ１００＃３）の制御部（すなわち、メモリ１５０及びプロセッサ１６０）は、受信エンティティとは別に、Ｄ２Ｄ通信においてデータユニット（ＰＤＣＰ ＰＤＵ）に対するフィードバックを送信するためのフィードバック送信エンティティを形成する。フィードバックは、例えば、圧縮ヘッダの解読に成功したか否かを示す情報である。

ここで、ＰＤＣＰ層に形成される受信エンティティ及び送信エンティティは、送信元識別子、送信先識別子及び論理チャネル識別子によって識別される。

例えば、Ｄ２Ｄ通信がユニキャストＤ２Ｄ通信であり、ＵＥ１００＃１が送信端末であり、ＵＥ１００＃３が受信端末であるケースについて考える。このようなケースにおいて、ＵＥ１００＃１の送信エンティティは、ＵＥ１００＃１の識別子、ＵＥ１００＃３の識別子及び論理チャネル識別子によってＵＥ１００＃１内で識別される。一方で、ＵＥ１００＃３の受信エンティティは、ＵＥ１００＃３の識別子、ＵＥ１００＃１の識別子及び論理チャネル識別子によってＵＥ１００＃３内で識別される。ＵＥ１００＃１の送信エンティティで用いる論理チャネル識別子は、ＵＥ１００＃３の送信エンティティで用いる論理チャネル識別子と異なっていてもよい。

続いて、Ｄ２Ｄ通信がグループキャストＤ２Ｄ通信（又はブロードキャストＤ２Ｄ通信）であり、ＵＥ１００＃１が送信端末であり、ＵＥ１００＃３が受信端末の一つであるケースについて考える。このようなケースにおいて、ＵＥ１００＃１の送信エンティティは、ＵＥ１００＃１の識別子、グループ識別子（ブロードキャスト識別子）及び論理チャネル識別子によってＵＥ１００＃１内で識別される。一方で、ＵＥ１００＃３の受信エンティティは、グループ識別子（ブロードキャスト識別子）、ＵＥ１００＃１の識別子及び論理チャネル識別子によってＵＥ１００＃３内で識別される。ＵＥ１００＃１の送信エンティティで用いる論理チャネル識別子は、ＵＥ１００＃３の送信エンティティで用いる論理チャネル識別子と異なっていてもよい。

上述したケースにおいて、ＵＥ１００＃３のフィードバック送信エンティティは、ＵＥ１００＃３の識別子、ＵＥ１００＃１の識別子及び論理チャネル識別子によってＵＥ１００＃３内で識別される。ＵＥ１００＃３のフィードバック送信エンティティの論理チャネル識別子は、ＵＥ１００＃１の送信エンティティで用いる論理チャネル識別子と異なってもよい。

但し、Ｄ２Ｄ通信がグループキャストＤ２Ｄ通信（又はブロードキャストＤ２Ｄ通信）である場合には、ＵＥ１００＃３のフィードバック送信エンティティは、グループ識別子（ブロードキャスト識別子）、ＵＥ１００＃１の識別子及び論理チャネル識別子によってＵＥ１００＃３内で識別されてもよい。すなわち、ＵＥ１００＃３のフィードバック送信エンティティは、フィードバックに含まれる送信元識別子として、自端末の識別子ではなくて、グループ識別子（又はブロードキャスト識別子）を用いてもよい。ＵＥ１００＃１の送信エンティティは、データユニット（ＰＤＣＰ ＰＤＵ）で用いられることがないグループ識別子（ブロードキャスト識別子）の検出によって、ＵＥ１００＃３から受信する信号がフィードバックであることを認識することができる。

さらに、フィードバックのフォーマットは、データユニット（ＰＤＣＰ ＰＤＵ）のフォーマットと異なることが好ましい。ＵＥ１００＃１の送信エンティティは、フォーマットの違いによって、ＵＥ１００＃３から受信する信号がフィードバックであることを認識することができる。例えば、フィードバックのフォーマットは、図１０に示すように、データを含まないフォーマットである。図１０に示すように、Ｄ２Ｄ通信のヘッダ圧縮技術で用いるフィードバックのフォーマットは、無線基地局とユーザ端末との間のセルラ通信のヘッダ圧縮技術（例えば、Ｏ−Ｍｏｄｅ（Ｂｉ−ｄｉｒｅｃｔｉｏｎａｌ Ｏｐｔｉｍｉｓｔｉｃ Ｍｏｄｅ）又はＲ−Ｍｏｄｅ（Ｂｉ−ｄｉｒｅｃｔｉｏｎａｌ Ｒｅｌｉａｂｌｅ Ｍｏｄｅ））で用いるフィードバックのフォーマットと同様であってもよい。

変更例２において、受信端末（例えば、ＵＥ１００＃３）の制御部（すなわち、メモリ１５０及びプロセッサ１６０）は、圧縮ヘッダの解読に失敗すると、フィードバック送信エンティティを形成することが好ましい。フィードバック送信エンティティは、圧縮ヘッダの解読に失敗すると、フィードバックを送信することが好ましい。すなわち、フィードバック送信エンティティは、圧縮ヘッダの解読に成功した旨を示す情報をフィードバックとして送信せずに、圧縮ヘッダの解読に失敗した旨を示す情報のみをフィードバックとして送信する。

変更例２において、フィードバック送信エンティティは、所定回数を超えない範囲でフィードバックを送信することが好ましい。言い換えると、フィードバックの送信回数の上限が予め定められている。例えば、フィードバック送信エンティティは、圧縮ヘッダの解読に最初に失敗した場合にのみ、フィードバックを送信することが好ましい。

変更例２において、受信端末（例えば、ＵＥ１００＃３）の制御部（すなわち、メモリ１５０及びプロセッサ１６０）は、Ｄ２Ｄ通信が継続している場合であっても、フィードバックを送信すると、フィードバック送信エンティティを削除することが好ましい。なお、制御部は、フィードバックの送信回数の上限が予め定められている場合には、フィードバックの送信回数が上限に達すると、フィードバック送信エンティティを削除することが好ましい。なお、送信端末（ＵＥ１００＃１）は、Ｄ２Ｄ通信が継続している場合であっても、フィードバックを受信すると、フィードバックを受信するためのフィードバック受信エンティティを削除することが好ましい。なお、送信端末（ＵＥ１００＃１）は、フィードバックの送信回数の上限が予め定められている場合には、フィードバックの受信回数が上限に達すると、フィードバック受信エンティティを削除することが好ましい。

以下において、図６に示す動作環境において、ＵＥ１００＃１、ＵＥ１００＃２及びＵＥ１００＃３の動作について図１１を参照しながら説明する。図１１は、変更例２に係る通信方法を示すシーケンス図である。なお、図１１では、図７と同様の処理について同様の符号を付している。従って、図７と同様の処理の説明については省略する。

図１１に示すように、ステップＳ１９１において、ＵＥ１００＃３は、受信エンティティとは別に、Ｄ２Ｄ通信においてデータユニット（ＰＤＣＰ ＰＤＵ）に対するフィードバックを送信するためのフィードバック送信エンティティを形成する。

ステップＳ１９２において、ＵＥ１００＃３は、圧縮ヘッダの解読に失敗した旨を示すフィードバックをＵＥ１００＃１に送信する。

なお、ステップＳ２０において、ＵＥ１００＃１は、フィードバックの受信に応じて、非圧縮ヘッダを含むデータユニット（ＰＤＣＰ ＰＤＵ）を送信することが好ましい。

ここで、図１１では省略しているが、ＵＥ１００＃３は、図７に示すステップＳ１９と同様に、ステップＳ１６で受信するデータユニット（ＰＤＣＰ ＰＤＵ）を所定期間に亘って保持してもよいことは勿論である。

（作用及び効果）
変更例２では、受信端末（例えば、ＵＥ１００＃３）は、Ｄ２Ｄ通信においてデータユニットを受信するための受信エンティティとは別に、Ｄ２Ｄ通信においてデータユニットに対するフィードバックを送信するためのフィードバック送信エンティティを形成する。従って、受信エンティティの形成タイミングが送信エンティティの形成タイミングと異なるケース、すなわち、受信エンティティの形成タイミングを送信エンティティが把握していないケースであっても、受信エンティティから送信エンティティに送信されるフィードバックによって、圧縮ヘッダの解読に失敗した受信エンティティの存在を送信エンティティが把握できる。例えば、送信エンティティは、圧縮ヘッダの解読に失敗した旨のフィードバックに応じて、非圧縮ヘッダを含むデータユニットを送信することができる。

なお、３ＧＰＰで仕様化中のＤ２Ｄ通信では、少なくともＬ２（後述するＭＡＣ層、ＲＬＣ層及びＰＤＣＰ層）において受信端末から送信端末へのフィードバックが存在しない通信モード（Ｕ−Ｍｏｄｅ）が規定されている。言い換えると、受信エンティティから送信エンティティに対してフィードバックを送信する機能が存在しない。従って、受信エンティティとは別にフィードバック送信エンティティを形成する必要があることに留意すべきである。

［変更例３］
以下において、第１実施形態の変更例３について説明する。以下においては、変更例２に対する差異について主として説明する。

変更例３では、Ｄ２Ｄ通信で用いるリソースとして、ｅＮＢ２００によって割り当てられる第１リソースと、ｅＮＢ２００による割り当てを必要とせずに使用可能な第２リソースとが定められている。受信端末（例えば、ＵＥ１００＃３）のフィードバック送信エンティティは、Ｄ２Ｄ通信で第１リソースが用いられている場合であっても、第２リソースを用いてフィードバックを送信する。

なお、第１リソースは、例えば、カバレッジ内のＤ２Ｄ通信で用いる無線リソース（リソースプール）である。一方で、第２リソースは、カバレッジ外又は部分的カバレッジのＤ２Ｄ通信で用いる無線リソース（リソースプール）である。例えば、第１リソース及び第２リソースは、ｅＮＢ２００から報知されてもよい。或いは、第１リソース及び第２リソースは、予め定められていてもよい。或いは、第１リソースは、ｅＮＢ２００から報知されており、第２リソースは、予め定められていてもよい。

変更例３では、ｅＮＢ２００による割り当てを必要としない第２リソースを用いてフィードバックが送信されるため、受信端末から送信端末へのフィードバックを速やかに送信することができる。

［変更例４］
以下において、第１実施形態の変更例４について説明する。以下においては、第１実施形態に対する差異について主として説明する。

具体的には、第１実施形態では、受信端末（例えば、ＵＥ１００＃３）は、圧縮ヘッダの解読に失敗しても、圧縮ヘッダを含むデータユニットを所定期間に亘って保持する。一方で、変更例４では、送信端末（例えば、ＵＥ１００＃１）の制御部（すなわち、メモリ１５０及びプロセッサ１６０）は、グループキャストＤ２Ｄ通信又はブロードキャストＤ２Ｄ通信においてヘッダとして圧縮ヘッダを用いずに、ユニキャストＤ２Ｄ通信においてヘッダとして圧縮ヘッダを用いる。

なお、受信端末（例えば、ＵＥ１００＃３）は、圧縮ヘッダを用いるユニキャストＤ２Ｄ通信においては、第１実施形態、変更例１〜変更例３と同様の動作を行ってもよい。

（作用及び効果）
変更例４では、送信端末（例えば、ＵＥ１００＃１）は、グループキャストＤ２Ｄ通信又はブロードキャストＤ２Ｄ通信においてヘッダとして圧縮ヘッダを用いずに、ユニキャストＤ２Ｄ通信においてヘッダとして圧縮ヘッダを用いる。従って、グループキャストＤ２Ｄ通信又はブロードキャストＤ２Ｄ通信に途中から参加するユーザ端末の受信エンティティの形成タイミングを送信エンティティが把握していないケースであっても、圧縮ヘッダの解読失敗が生じる事態が抑制される。一方で、ユニキャストＤ２Ｄ通信では、受信エンティティの形成タイミングが送信エンティティの形成タイミングと異なるため、圧縮ヘッダの解読失敗が生じる可能性があるが、圧縮ヘッダの解読失敗が生じる事態よりも、ヘッダ圧縮技術によって得られるオーバヘッドの削減が優先されていることに留意すべきである。

［その他の実施形態］
本発明は上述した実施形態によって説明したが、この開示の一部をなす論述及び図面は、この発明を限定するものであると理解すべきではない。この開示から当業者には様々な代替実施形態、実施例及び運用技術が明らかとなろう。

実施形態では特に触れていないが、ＵＥ１００及びｅＮＢ２００が行う各処理をコンピュータに実行させるプログラムが提供されてもよい。また、プログラムは、コンピュータ読取り可能媒体に記録されていてもよい。コンピュータ読取り可能媒体を用いれば、コンピュータにプログラムをインストールすることが可能である。ここで、プログラムが記録されたコンピュータ読取り可能媒体は、非一過性の記録媒体であってもよい。非一過性の記録媒体は、特に限定されるものではないが、例えば、ＣＤ−ＲＯＭやＤＶＤ−ＲＯＭ等の記録媒体であってもよい。

或いは、ＵＥ１００及びｅＮＢ２００が行う各処理を実行するためのプログラムを記憶するメモリ及びメモリに記憶されたプログラムを実行するプロセッサによって構成されるチップが提供されてもよい。

実施形態では、移動通信システムの一例としてＬＴＥシステムを説明した。しかしながら、実施形態はこれに限定されるものではない。移動通信システムは、ＬＴＥシステム以外のシステムであってもよい。

［付記］
以下において、上述した実施形態の補足事項について説明する。

（ＨＡＲＱ関連）
ＲＬＣ／ＰＤＣＰエンティティが、送信元ＩＤ、送信先ＩＤ及びＬＣＩＤの組み合わせ毎に識別されることで合意されている。

・ＲＬＣエンティティ毎に１つのＰＤＣＰエンティティが存在する。ＰＤＣＰエンティティ及びＲＬＣエンティティの識別のために、Ｓｏｕｒｃｅ Ｌａｙｅｒ２ ＩＤ、Ｄｅｓｔｉｎａｔｉｏｎ Ｌａｙｅｒ２ ＩＤ、及びＬＣＩＤが使用される。ＰｒｏＳｅ直接通信に必要なＲＬＣパラメータは、下位レイヤからの順番通りの送達がない場合は、ｓｎ−ＦｉｅｌｄＬｅｎｇｔｈ及びＴ−ｒｅｏｒｄｅｒｉｎｇである。

しかしながら、ＨＡＲＱエンティティの数及びＨＡＲＱプロセスの数に関して、いくつかの解決策が提案されたが、今のところ合意に至っていない。

セルラ通信の場合、現在は、サービングセル毎に１つのＨＡＲＱエンティティがある。しかしながら、Ｄ２Ｄ通信の場合、ＳＡ、Ｄａｔａ及びＤＭＲＳ中で送信Ｄ２Ｄ ＵＥを識別する手段がない。それ故、受信Ｄ２Ｄ ＵＥは、送信元ＩＤ（Ｓｏｕｒｃｅ Ｌａｙｅｒ２ ＩＤ）毎にＨＡＲＱエンティティを維持することができない。そのためＤ２Ｄ通信の場合は、受信した送信先ＩＤ（Ｓｏｕｒｃｅ Ｌａｙｅｒ２ ＩＤ）に基づいて、ＨＡＲＱエンティティを管理するために、次の選択肢を検討してもよい。

選択肢1：Ｄ２Ｄ通信の場合は、ＨＡＲＱエンティティは１つのみにする。

選択肢2：送信先ＩＤのタイプ（即ち、ユニキャスト、ブロードキャスト又はグループキャスト）毎に、１つのＨＡＲＱエンティティとする。

選択肢3： 送信先ＩＤ毎に、１つのＨＡＲＱエンティティとする。

現在のセルラ通信の場合、ＨＡＲＱエンティティの担当は、ＨＡＲＱ ＡＣＫ／ＮＡＣＫを判定すること、ブロードキャスト又はユニキャストを判定すること、及びＨＡＲＱ再送を管理することである。しかしながら、Ｄ２Ｄ通信の場合、ＨＡＲＱ ＡＣＫ／ＮＡＣＫフィードバックがなく、ブロードキャスト、グループキャスト又はユニキャストデータに同一のＭＡＣ処理が適用されるため、ＨＡＲＱエンティティは１つだけで十分であろう。（選択肢１）

ＨＡＲＱプロセスの数に関しては、セルラ通信の場合、再送データの管理及び再送データの組み合わせは、ＨＡＲＱプロセス毎に行われる。Ｄ２Ｄ通信については、１つのＳＡが、データは同一だが、ＲＶの異なる４つの再送データに対して、リソースを割り当てることができるということで合意されている。それ故、ＨＡＲＱプロセスは、受信したＳＡ毎に確立すべきである。

見解1： Ｄ２Ｄ通信には１つのＨＡＲＱエンティティがサポートされ、ＨＡＲＱプロセスの数は、受信したＳＡの数と同じ数とすべきである。

（ＲｏＨＣ機能）
次のＰＤＣＰの側面が合意される。

・ベースラインとして、Ｌ２の観点から、１：ＭのＤ２Ｄ通信は、一方向であり、Ｌ２（ＭＡＣ／ＲＬＣ／ＰＤＣＰ）にフィードバックが存在しない、ということを仮定している。

・Ｄ２Ｄ通信データは、通常のユーザプレーンのデータ（即ち、ＩＰパケット）として取り扱われるべきである。

・ＰＤＣＰでのヘッダ圧縮／展開は、Ｄ２Ｄ通信にも適用可能である。パブリックセーフティのため、Ｄ２Ｄブロードキャスト動作についてのＰＤＣＰでは、ヘッダ圧縮にＵ−Ｍｏｄｅが使用される。

・セキュリティのサポートは、ＳＡ３による意見（input）に基づき、対処されるであろう。

・ＲＬＣエンティティ毎に１つのＰＤＣＰエンティティが存在する。ＰＤＣＰエンティティ及びＲＬＣエンティティの識別のために、Ｓｏｕｒｃｅ Ｌａｙｅｒ２ ＩＤ、Ｄｅｓｔｉｎａｔｉｏｎ Ｌａｙｅｒ２ ＩＤ、及びＬＣＩＤが、使用される。ＰｒｏＳｅ直接通信に必要なＲＬＣパラメータは、下位レイヤからの順番通りの送達がない場合は、ｓｎ−ＦｉｅｌｄＬｅｎｇｔｈ及びＴ−ｒｅｏｒｄｅｒｉｎｇである。

・ＰＤＣＰエンティティとＲＬＣエンティティは一緒に確立され／解放される。

・Ｔｘ ＰＤＣＰ／ＲＬＣ確立： ＵＥの実装に委ねる。

・Ｒｘ ＰＤＣＰ／ＲＬＣ確立： ＬＣＩＤに対するＳｏｕｒｃｅ Ｌａｙｅｒ２ ＩＤ及びＤｅｓｔｉｎａｔｉｏｎ Ｌａｙｅｒ２ ＩＤのペアからの最初のＵＭＤ ＰＤＵの受信、または、対応する受信ＲＬＣエンティティがまだ存在しない。

・Ｒｘ ＰＤＣＰ／ＲＬＣ解放： ＵＥの実装に委ねる。

・ＰｒｏＳｅ直接通信に必要なＰＤＣＰパラメータは、ｄｉｓｃａｒｄＴｉｍｅｒ、ｍａｘＣＩＤ、ｐｄｃｐ−ＳＮ−Ｓｉｚｅ及びプロファイルである。

上述したように、多くのＰＤＣＰ関連仕様について既に合意しているが、ＲｏＨＣの機能に関して、まだ１つの懸念がある。その懸念とは、いくつかのＤ２Ｄ ＵＥが、進行中のＤ２Ｄ通信に参加する場合があり、これらのＵＥは、ＣＩＤが何を示しているのか、及び、ＰＤＣＰ ＰＤＵをどのように展開するのか、解読できないであろう、ということである。

「Ｌ２にフィードバックが存在しない」という点、及び「パブリックセーフティのため、Ｄ２Ｄブロードキャスト動作についてのＰＤＣＰでは、ヘッダ圧縮にＵ−Ｍｏｄｅが使用される」という点で既に合意している。Ｕ−ｍｏｄｅでは、圧縮されていないヘッダの周期的な送信を使用することによって、圧縮されたヘッダを解読してこの失敗に対処するが、周期はＵＥの実装である。それ故、Ｄ２Ｄ通信の場合、送信ＵＥは、受信ＵＥがいつＤ２Ｄ通信の監視を開始するかを知ることができず、そのため、周期が非常に長く設定されていた場合には、ヘッダの更新に時間がかかり過ぎる場合があり、ＵＥは、ヘッダが更新されるまでデータを受信することができないであろう。圧縮されていないヘッダの周期的な送信は、ＵＥの実装に基づくが、Ｄ２Ｄ通信では、更新に過度に長い周期を使用すべきではない。

見解1： Ｄ２Ｄ通信では、ヘッダ更新前に過度に長い周期を使用すべきではない。

しかしながら、この周期は、ＵＥの実装によって決定されるため、ＲＡＮは、ＲｏＨＣ Ｕ−Ｍｏｄｅのみを使用して上で対処した問題を防ぐことができない場合がある。そのため、圧縮されたヘッダ（例えば、点在したＲＯＨＣフィードバックパケットに対するＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵフォーマットなど）の解読に失敗したことを示すフィードバックが必要かどうかを、再度検討する必要があるかもしれない。

提案1： ＲＡＮ２では、上記のＲｏＨＣ問題に対してフィードバックの導入が必要かどうかについて、再度検討する必要があるかもしれない。

（ＰＤＣＰエンティティとＲＬＣエンティティの解放タイミング）
送信エンティティ及び受信エンティティの確立タイミング、並びに受信エンティティの解放タイミングについて合意されている。しかしながら、送信エンティティの解放タイミングについてはまだ合意していない。次の２つの選択肢が以前に提案された。

・Ｔｘ ＰＤＣＰ／ＲＬＣ解放
選択肢１： インアクティビティタイマ満了
選択肢２： 上位レイヤからの解放指示

現在の合意に基づくと、受信エンティティの解放タイミングは、ＵＥの実装に任せられるため、どちらの選択肢でも、Ｄ２Ｄ通信に対する送信エンティティと受信エンティティとの間の解放タイミングに影響する場合がある。ＲＬＣリオーダリングウインドウ（ｒｅ−ｏｒｄｅｒｉｎｇ ｗｉｎｄｏｗ）が導入され、ウィンドウサイズがゼロでない場合は、解放タイミングの違いにより、ＵＭＤ ＰＤＵのＳＮ値の急激な変化が起こり、不要な破棄が生じる場合がある。この場合、送信エンティティは、ＵＭＤ ＰＤＵ破棄の発生を防ぐため、インアクティビティタイマ満了後、解放されるべきであり、また、受信エンティティは、対応する送信エンティティと共に同一のインアクティビティタイマを共有し、それを受信エンティティにおけるＵＭＤ ＰＤＵ破棄の発生を防ぐための時間基準として使用するべきである。

他方で、ＲＬＣリオーダリングウインドウが導入されないか、又はウィンドウサイズがゼロであった場合、上述の問題は発生せず、不要なＵＭＤ ＰＤＵ破棄を招くことなく、選択肢１又は選択肢２のいずれかをＵＥによって適用し得る。

提案2： ＵＭリオーダリングウインドウがゼロでない場合は、Ｔｘ ＲＬＣエンティティは、ＵＭＤ ＰＤＵ破棄の発生を防ぐため、インアクティビティタイマ満了後、解放されるべきである。

提案3： 提案３が採用される場合、Ｒｘ ＲＬＣエンティティは、対応するＴｘ ＲＬＣと共に同一のインアクティビティタイマを共有し、それをＵＭＤ ＰＤＵ破棄の発生を防ぐための基準として使用するべきでもある。

提案4： ＵＭリオーダリングウインドウサイズが「ゼロ」であった場合、不要なＵＭＤ ＰＤＵ破棄を招くことなく、選択肢１、選択肢２のいずれかをＵＥによって適用し得る。

［相互参照］
米国仮出願第６２／０３５０８８号（２０１４年８月８日出願）及び米国仮出願第６２／０５６０７６号（２０１４年９月２６日出願）の全内容が参照により本願明細書に組み込まれている。

本発明は、移動通信分野において有用である。

Claims (11)

1. Ｄ２Ｄ近傍サービスをサポートする移動通信システムにおいて送信端末とＤ２Ｄ通信を行う受信端末であって、
   前記Ｄ２Ｄ通信において、データ及びヘッダによって構成されるデータユニットを前記送信端末から受信する受信部と、
   前記ヘッダとして圧縮ヘッダが用いられている場合に、前記圧縮ヘッダの解読に失敗しても、前記圧縮ヘッダを含む前記データユニットを所定期間に亘って保持する制御部とを備え、
   前記Ｄ２Ｄ通信において、前記受信端末において受信エンティティを形成するタイミングは、前記送信端末において送信エンティティを形成するタイミングと異なり、
   前記Ｄ２Ｄ通信は、ユニキャストＤ２Ｄ通信、グループキャストＤ２Ｄ通信又はブロードキャストＤ２Ｄ通信を含み、
   前記グループキャストＤ２Ｄ通信又は前記ブロードキャストＤ２Ｄ通信における前記ヘッダとして非圧縮ヘッダを含む前記データユニットの受信周期は、前記ユニキャストＤ２Ｄ通信における前記ヘッダとして前記非圧縮ヘッダを含む前記データユニットの受信周期よりも短いことを特徴とする受信端末。
2. 前記所定期間は、前記ヘッダとして非圧縮ヘッダを含む前記データユニットの受信周期よりも長いことを特徴とする請求項１に記載の受信端末。
3. 前記所定期間は、前記圧縮ヘッダの解読に失敗してから、前記ヘッダとして非圧縮ヘッダを含む前記データユニットを受信するまでの期間であることを特徴とする請求項１に記載の受信端末。
4. Ｄ２Ｄ近傍サービスをサポートする移動通信システムにおいて送信端末とＤ２Ｄ通信を行う受信端末であって、
   前記Ｄ２Ｄ通信において、データ及びヘッダによって構成されるデータユニットを前記送信端末から受信する受信部と、
   前記Ｄ２Ｄ通信において前記データユニットを受信するための受信エンティティを形成する制御部とを備え、
   前記制御部は、前記受信エンティティとは別に、前記Ｄ２Ｄ通信において前記データユニットに対するフィードバックを送信するためのフィードバック送信エンティティを形成し、
   前記Ｄ２Ｄ通信において、前記受信エンティティを形成するタイミングは、前記送信端末において前記データユニットを送信するための送信エンティティを形成するタイミングと異なり、
   前記Ｄ２Ｄ通信で用いるリソースとして、無線基地局によって割り当てられる第１リソースと、前記無線基地局による割り当てを必要とせずに使用可能な第２リソースとが定められており、
   前記受信端末に形成される前記フィードバック送信エンティティは、前記Ｄ２Ｄ通信で前記第１リソースが用いられている場合であっても、前記第２リソースを用いて前記フィードバックを送信することを特徴とする受信端末。
5. 前記送信端末に形成される前記送信エンティティは、前記データユニットに含まれる送信先識別子としてグループ識別子又はブロードキャスト識別子を用いており、
   前記受信端末に形成される前記フィードバック送信エンティティは、前記フィードバックに含まれる送信元識別子として、自端末の識別子ではなくて、前記グループ識別子又は前記ブロードキャスト識別子を用いることを特徴とする請求項４に記載の受信端末。
6. 前記フィードバックのフォーマットは、前記データユニットのフォーマットと異なることを特徴とする請求項４に記載の受信端末。
7. 前記制御部は、前記データユニットに含まれる前記ヘッダとして圧縮ヘッダが用いられている場合に、前記圧縮ヘッダの解読に失敗すると、前記フィードバック送信エンティティを形成することを特徴とする請求項４に記載の受信端末。
8. 前記フィードバック送信エンティティは、前記データユニットに含まれる前記ヘッダとして圧縮ヘッダが用いられている場合に、前記圧縮ヘッダの解読に失敗すると、前記フィードバックを送信することを特徴とする請求項４に記載の受信端末。
9. 前記フィードバック送信エンティティは、所定回数を超えない範囲で前記フィードバックを送信することを特徴とする請求項４に記載の受信端末。
10. 前記制御部は、前記Ｄ２Ｄ通信が継続している場合であっても、前記フィードバックを送信すると、前記フィードバック送信エンティティを削除することを特徴とする請求項４に記載の受信端末。
11. Ｄ２Ｄ近傍サービスをサポートする移動通信システムにおいて受信端末とＤ２Ｄ通信を行う送信端末であって、
    前記Ｄ２Ｄ通信において、データ及びヘッダによって構成されるデータユニットを前記受信端末に送信する送信部と、
    前記Ｄ２Ｄ通信において前記データユニットを送信するための送信エンティティを形成する制御部とを備え、
    前記Ｄ２Ｄ通信は、ユニキャストＤ２Ｄ通信、グループキャストＤ２Ｄ通信又はブロードキャストＤ２Ｄ通信を含み、
    前記制御部は、前記グループキャストＤ２Ｄ通信又は前記ブロードキャストＤ２Ｄ通信において前記ヘッダとして圧縮ヘッダを用いずに、前記ユニキャストＤ２Ｄ通信において前記ヘッダとして前記圧縮ヘッダを用いており、
    前記Ｄ２Ｄ通信において、前記受信端末において前記データユニットを受信するための受信エンティティを形成するタイミングは、前記送信エンティティを形成するタイミングと異なることを特徴とする送信端末。

Images