JP6645963B2 - ユーザ端末及び移動通信システム - Google Patents

Description

本出願は、直接的な端末間通信であるＤ２Ｄ通信をサポートする移動通信システムにおいて用いられるユーザ端末及び移動通信システムに関する。

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

Ｄ２Ｄ近傍サービス（Ｄ２Ｄ ＰｒｏＳｅ）は、同期がとられた複数のユーザ端末からなる同期クラスタ内で直接的な端末間通信を可能とするサービスである。Ｄ２Ｄ近傍サービスは、近傍端末を発見するＤ２Ｄ発見手順（Ｄｉｓｃｏｖｅｒｙ）と、直接的な端末間通信であるＤ２Ｄ通信（Ｃｏｍｍｕｎｉｃａｔｉｏｎ）と、を含む。

Ｄ２Ｄ通信において、送信ユーザ端末は、データを送信するために送信ＲＬＣエンティティを確立し、受信ユーザ端末は、データを受信するために受信ＲＬＣエンティティを確立する。現状、受信ＲＬＣエンティティは、ユーザ端末の実装に依存して解放されることが合意されているものの、送信ＲＬＣエンティティの解放については、取り決めがない（非特許文献１参照）。

３ＧＰＰ寄書 ＲＰ−１４０６４８

一の実施形態に係るユーザ端末は、直接的な端末間通信であるＤ２Ｄ通信によってデータを受信するために確立された受信ＲＬＣエンティティにおいて、ウィンドウを前進させることなく受信できるデータのシーケンス番号を規定するために前記受信ＲＬＣエンティティにおいて使用されるウィンドウサイズに基づく所定条件下で、所定のシーケンス番号のデータを破棄する制御を行う制御部を備える。前記制御部は、前記ウィンドウサイズを０に設定する。

図１は、実施形態に係るＬＴＥシステムの構成図である。 図２は、実施形態に係るＵＥのブロック図である。 図３は、実施形態に係るｅＮＢのブロック図である。 図４は、実施形態に係るプロトコルスタック図である。 図５は、実施形態に係る無線フレームの構成図である。 図６は、Ｄ２Ｄ通信におけるＰＤＣＰエンティティ及びＲＬＣエンティティを説明するための図である。 図７は、実施形態に係るＤ２Ｄ通信に用いられる時間・周波数リソースの配置を説明するための一例を示す図である。 図８は、Ｄ２Ｄ通信におけるＵＥ１００の動作を説明するための図である。 図９は、Ｄ２Ｄ通信におけるＵＥ１００の動作（第２の動作）を説明するための図である。 図１０は、カバレッジ外Ｄ２Ｄ通信及びカバレッジ内Ｄ２Ｄ通信の例を示す図である。 図１１は、有効中タイマの例を示す図である。

［実施形態の概要］
既存のセルラ通信では、ユーザ端末−基地局間における受信エンティティ及び送信エンティティの生成（確立）及び解放はそれぞれ、ＲＲＣメッセージによって基地局及びユーザ端末のそれぞれで同時に行われる。このため、ＲＬＣエンティティを確立する度に、データのシーケンス番号値（以下、ＳＮ値）が初期値化されても、受信エンティティと送信ＲＬＣエンティティとで、データのシーケンス番号値（以下、ＳＮ値）にズレは、発生しない。

一方、Ｄ２Ｄ通信では、送信ユーザ端末が、受信ユーザ端末へ送信するための送信ＲＬＣエンティティを解放した後に、新たに確立した送信ＲＬＣエンティティによって当該受信ユーザ端末にデータを送信する場合、当該受信ユーザ端末が、当該送信ユーザ端末からデータを受信するために用いていた受信ＲＬＣエンティティを解放せずに維持しているケースが想定される。

このケースにおいて、既存のセルラ通信のように、新たな送信ＲＬＣエンティティにおいてデータのＳＮ値が初期値化された場合、受信ＲＬＣエンティティを維持している受信ユーザ端末と、新たな送信ＲＬＣエンティティを確立した送信ユーザ端末とで、ＳＮ値にズレが発生する可能性がある。

受信ユーザ端末は、送信ユーザ端末からのデータのＳＮ値に基づいて、新たなデータが既に受信したデータと同一であるか否かを判断するため、ＳＮ値にズレが発生した場合、受信ユーザ端末は、新たなデータを、既に受信したデータとみなし、破棄する虞がある。

そこで、本出願の目的の一つとして、ユーザ端末が、新たなデータを既に受信したデータと見なして破棄することを抑制可能とする技術を提供する。

実施形態に係るユーザ端末（受信ユーザ端末）は、直接的な端末間通信であるＤ２Ｄ通信によってデータを受信するために確立された受信ＲＬＣエンティティにおいて、ウィンドウを前進させることなく受信できるデータのシーケンス番号を規定するために前記受信ＲＬＣエンティティにおいて使用されるウィンドウサイズに基づく所定条件下で、所定のシーケンス番号のデータを破棄する制御を行う制御部を備える。前記制御部は、前記ウィンドウサイズを０に設定する。

実施形態において、前記制御部は、前記Ｄ２Ｄ通信よって送信される情報の種別に応じて、前記ウィンドウサイズを０に設定する。

実施形態において、前記制御部は、前記Ｄ２Ｄ通信よって送信されるデータの宛先に応じて、前記ウィンドウサイズを０に設定する。

実施形態において、前記制御部は、前記Ｄ２Ｄ通信における送信方法に応じて、前記ウィンドウサイズを０に設定する。

実施形態に係るユーザ端末は、直接的な端末間通信であるＤ２Ｄ通信によってデータを受信するための受信ＲＬＣエンティティを確立する制御部を備える。前記制御部は、前記Ｄ２Ｄ通信によって送信される情報の種別に応じて、前記受信ＲＬＣエンティティにおけるウィンドウに関する設定を行う。

実施形態に係るユーザ端末（受信ユーザ端末）は、直接的な端末間通信であるＤ２Ｄ通信によって前記ユーザ端末にデータを送信するための送信ＲＬＣエンティティを確立した他のユーザ端末から、前記送信ＲＬＣエンティティの解放に関する情報を受信する受信部を備える。

実施形態において、前記ユーザ端末は、前記受信部が受信した前記情報に基づいて、前記Ｄ２Ｄ通信によって前記他のユーザ端末からデータを受信するための受信ＲＬＣエンティティを解放する制御部をさらに備える。

実施形態において、前記制御部は、前記情報に基づいて、遅くとも前記他のユーザ端末が前記送信ＲＬＣエンティティを解放する時間を超える前に、前記受信ＲＬＣエンティティを解放する。

実施形態において、前記情報は、前記他のユーザ端末が前記送信ＲＬＣエンティティを解放するために用いるタイマの情報である。

実施形態において、データの繰り返し送信のための期間が時間方向に複数設けられており、前記ユーザ端末は、前記期間である第１の期間内に前記他のユーザ端末からデータを受信した後、前記第１の期間の後に続く前記期間である第２の期間を超えても前記他のユーザ端末からデータを受信しない場合に、前記受信ＲＬＣエンティティを解放する制御部をさらに備える。

実施形態に係るユーザ端末（送信ユーザ端末）は、直接的な端末間通信であるＤ２Ｄ通信によって他のユーザ端末にデータを送信するための送信ＲＬＣエンティティを確立する制御部と、前記他のユーザ端末に前記送信ＲＬＣエンティティの解放に関する情報を送信する送信部と、を備える。

実施形態において、前記情報は、前記ユーザ端末が前記送信ＲＬＣエンティティを解放するために用いるタイマの情報である。

実施形態において、データの繰り返し送信のための期間が時間方向に複数設けられており、前記制御部は、前記期間内に同一データを繰り返して送信する制御を行う場合に、同一データを送信するタイミングをランダムに設定する。

実施形態に係るユーザ端末（受信ユーザ端末）は、直接的な端末間通信であるＤ２Ｄ通信によって他のユーザ端末からデータを受信するための受信ＲＬＣエンティティを確立する制御部と、前記Ｄ２Ｄ通信によって前記他のユーザ端末から送信されるデータの送信開始又は終了の少なくとも一方を示す情報を受信する受信部と、を備える。前記制御部は、前記情報に基づいて、前記受信ＲＬＣエンティティを解放する。

実施形態において、前記情報は、前記他のユーザ端末から送信されるデータの１ブロックの開始から終了までを識別するためのフラグ情報である。

実施形態において、データの繰り返し送信のための期間が時間方向に複数設けられており、前記制御部は、前記期間である第１の期間内に前記他のユーザ端末からデータを受信した後、前記第１の期間の後に続く前記期間である第２の期間を超えても前記他のユーザ端末からデータを受信しない場合に、前記受信ＲＬＣエンティティを解放する。

実施形態に係るユーザ端末（送信ユーザ端末）は、直接的な端末間通信であるＤ２Ｄ通信によって他のユーザ端末にデータを送信するための送信ＲＬＣエンティティを確立する制御部と、前記Ｄ２Ｄ通信によって前記他のユーザ端末に送信するデータの送信開始又は終了の少なくとも一方を示す情報を送信する送信部と、を備える。

実施形態において、前記情報は、前記データの１ブロックの開始から終了までを識別するためのフラグ情報である。

ところで、Ｄ２Ｄ通信において、ＰＤＣＰパラメータ及びＲＬＣパラメータを設定する方法は、まだ規定されていない。そこで、本出願の目的の一つとして、Ｄ２Ｄ通信のために用いられるＰＤＣＰパラメータ及びＲＬＣパラメータを設定する技術を提供する。

実施形態に係る移動通信システムは、Ｄ２Ｄ通信におけるデータの受信のための時間・周波数リソースの位置を示すスケジューリング割当を、ＳＡリソースプール内の時間・周波数リソース使用して送信する第１ユーザ端末と、前記ＳＡリソースプール内の時間・周波数リソースを使用して前記スケジューリング割当を前記第１ユーザ端末から受信する第２ユーザ端末と、を備える。前記第１ユーザ端末は、前記ＳＡリソースプールに対応付けられた設定情報に基づいて、前記Ｄ２Ｄ通信に用いられる送信ＲＬＣエンティティを確立する。前記第２ユーザ端末は、前記ＳＡリソースプールに対応付けられた設定情報に基づいて、前記Ｄ２Ｄ通信に用いられる受信ＲＬＣエンティティを確立する。

実施形態に係る移動通信システムは、Ｄ２Ｄ通信によってデータを送信するための送信ＲＬＣエンティティを確立する第１ユーザ端末と、前記Ｄ２Ｄ通信によってデータを受信するための受信ＲＬＣエンティティを確立する第２ユーザ端末と、を備える。前記第１ユーザ端末は、受信ＲＬＣエンティティの設定情報を含むデータを送信する。前記第２ユーザ端末は、前記受信ＲＬＣエンティティの設定情報に基づいて、前記受信ＲＬＣエンティティを確立する。

実施形態に係る移動通信システムは、Ｄ２Ｄ通信におけるデータの受信のための時間・周波数リソースの位置を示すスケジューリング割当を送信する第１ユーザ端末と、前記スケジューリング割当を前記第１ユーザ端末から受信する第２ユーザ端末と、を備える。前記第１ユーザ端末は、前記Ｄ２Ｄ通信によってデータを受信するための受信ＲＬＣエンティティの設定情報を含む前記スケジューリング割当を送信する。前記第２ユーザ端末は、前記受信ＲＬＣエンティティの設定情報に基づいて、前記受信ＲＬＣエンティティを確立する。

ところで、Ｄ２Ｄ通信において、ＰＤＣＰエンティティにおけるデータの圧縮方法は、まだ規定されていない。そこで、本出願の目的の一つとして、Ｄ２Ｄ通信において、ＰＤＣＰエンティティにおけるデータを圧縮する技術を提供する。

実施形態に係るユーザ端末は、直接的な端末間通信であるＤ２Ｄ通信で用いられるＰＤＣＰエンティティにおいて、変更されないパラメータに基づいて、データの圧縮解除を行う制御部を備える。

実施形態において、前記変更されないパラメータは、コンテキスト識別子の最大値である。

なお、以下の内容も、実施形態の概要に含まれる。

実施形態において、データの繰り返し送信のための期間が時間方向に複数設けられており、（ユーザ端末の）制御部は、前記期間内に同一データを繰り返して送信する制御を行う場合に、同一データを送信するタイミングをランダムに設定する。

実施形態に係るユーザ端末は、直接的な端末間通信であるＤ２Ｄ通信で用いられるＰＤＣＰエンティティにおいて、変更されないパラメータに基づいて、データの圧縮を行う制御部を備える。

実施形態において、前記変更されないパラメータは、コンテキスト識別子の最大値である。

［実施形態］
以下において、本出願の内容をＬＴＥシステムに適用する場合の実施形態を説明する。

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

ＵＥ１００は、ユーザ端末に相当する。ＵＥ１００は、移動型の通信装置であり、接続先のセル（サービングセル）との無線通信を行う。ＵＥ１００の構成については後述する。

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

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

ＥＰＣ２０は、コアネットワークに相当する。Ｅ−ＵＴＲＡＮ１０及びＥＰＣ２０によりＬＴＥシステムのネットワーク（ＬＴＥネットワーク）が構成される。ＥＰＣ２０は、ＭＭＥ（Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ）／Ｓ−ＧＷ（Ｓｅｒｖｉｎｇ−Ｇａｔｅｗａｙ）３００を含む。ＥＰＣ２０は、ＯＡＭ（Ｏｐｅｒａｔｉｏｎ ａｎｄ Ｍａｉｎｔｅｎａｎｃｅ）を含んでもよい。

ＭＭＥは、ＵＥ１００に対する各種モビリティ制御などを行う。Ｓ−ＧＷは、ユーザデータの転送制御を行う。ＭＭＥ／Ｓ−ＧＷ３００は、Ｓ１インターフェイスを介してｅＮＢ２００と接続される。

ＯＡＭは、オペレータによって管理されるサーバ装置であり、Ｅ−ＵＴＲＡＮ１０の保守及び監視を行う。

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

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

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

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

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

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

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

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

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

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

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

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

ＰＤＣＰ層は、ヘッダ圧縮・伸張、及び暗号化・復号化を行う。

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

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

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

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

（Ｄ２Ｄ近傍サービス）
以下において、Ｄ２Ｄ近傍サービスについて説明する。実施形態に係るＬＴＥシステムは、Ｄ２Ｄ近傍サービスをサポートする。Ｄ２Ｄ近傍サービスについては非特許文献１に記載されているが、ここではその概要を説明する。

Ｄ２Ｄ近傍サービス（Ｄ２Ｄ ＰｒｏＳｅ）は、同期がとられた複数のＵＥ１００からなる同期クラスタ内で直接的なＵＥ間通信を可能とするサービスである。Ｄ２Ｄ近傍サービスは、近傍ＵＥを発見するＤ２Ｄ発見手順（Ｄｉｓｃｏｖｅｒｙ）と、直接的なＵＥ間通信であるＤ２Ｄ通信（Ｃｏｍｍｕｎｉｃａｔｉｏｎ）と、を含む。Ｄ２Ｄ通信は、Ｄｉｒｅｃｔ ｃｏｍｍｕｎｉｃａｔｉｏｎとも称される。

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

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

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

Ｄ２Ｄ発見手順は、主にＤ２Ｄ通信をユニキャストで行う場合に利用される。一のＵＥ１００は、他のＵＥ１００とのＤ２Ｄ通信を開始しようとする場合に、Ｄ２Ｄ発見手順に使用可能な無線リソースのうち何れかの無線リソースを用いて、Ｄｉｓｃｏｖｅｒｙ信号（Ｄ２Ｄ発見信号）を送信する。当該他のＵＥ１００は、当該一のＵＥ１００とのＤ２Ｄ通信を開始しようとする場合に、Ｄ２Ｄ発見手順に使用可能な無線リソース内でＤｉｓｃｏｖｅｒｙ信号をスキャンし、Ｄｉｓｃｏｖｅｒｙ信号を受信する。Ｄｉｓｃｏｖｅｒｙ信号は、当該一のＵＥ１００がＤ２Ｄ通信に使用する無線リソースを示す情報を含んでもよい。

（ＰＤＣＰエンティティ及びＲＬＣエンティティ）
以下において、Ｄ２Ｄ通信（Ｃｏｍｍｕｎｉｃａｔｉｏｎ）のために確立されるＰＤＣＰエンティティ及びＲＬＣエンティティについて、図６を用いて説明する。図６は、Ｄ２Ｄ通信におけるＰＤＣＰエンティティ及びＲＬＣエンティティを説明するための図である。

Ｄ２Ｄ通信を行うＵＥ１００は、ＰＤＣＰエンティティ及びＲＬＣエンティティを確立する。ＰＤＣＰエンティティは、Ｄ２Ｄ通信において、上述したＰＤＣＰ層と同様の動作を行い、ＲＬＣエンティティは、Ｄ２Ｄ通信において、上述したＲＬＣ層と同様の動作を行う。なお、本実施形態では、ＲＬＣエンティティは、非確認応答モード（ＵＭ）で動作する。ＵＭでは、データ分割・結合は行うが、ＡＲＱ再送は行わない。

Ｄ２Ｄ通信によってデータを送信するＵＥ１００は、送信ＰＤＣＰエンティティ及び送信ＲＬＣエンティティ（以下、送信エンティティ）を確立する。一方、Ｄ２Ｄ通信によってデータを受信するＵＥ１００は、受信ＰＤＣＰエンティティ及び受信ＲＬＣエンティティ（以下、受信エンティティ）を確立する。

送信エンティティ及び受信エンティティのそれぞれを特定するために、送信元を識別するＩＤ（送信元ＩＤ：Ｓｏｕｒｃｅ Ｌａｙｅｒ ２ ＩＤ）、送信先を識別するＩＤ（送信先ＩＤ：Ｄｅｓｔｉｎａｔｉｏｎ Ｌａｙｅｒ ２ ＩＤ）、論理チャネルを識別するＩＤ（ＬＣＩＤ）が用いられる。

送信エンティティは、Ｄ２Ｄ通信によって送信する（送信すべき）データが発生した場合に確立される。一方、受信エンティティは、Ｄ２Ｄ通信によって最初のデータを受信した場合に、対応する受信ＲＬＣエンティティが確立されていない場合に確立される。従って、最初のデータの各ＩＤ（送信元ＩＤ、送信先ＩＤ、ＬＣＩＤ）が、既存の受信エンティティの各ＩＤと同一でない場合、受信エンティティが確立される。

具体的には、図６に示すように、ＵＥ１００Ａは、ＵＥ１００Ｂへのデータの送信のために、送信ＰＤＣＰエンティティ及び送信ＲＬＣエンティティ（以下、第１の送信エンティティ）を確立する。第１の送信エンティティにおいて、送信元ＩＤが、「Ａ（ＵＥ１００Ａ）」であり、送信先ＩＤは、「Ｂ（ＵＥ１００Ｂ）」であり、ＬＣＩＤは、「１」である。

また、ＵＥ１００Ａは、ＵＥ１００Ｂからのデータの受信のために、受信ＰＤＣＰエンティティ及び受信ＲＬＣエンティティ（以下、第２の受信エンティティ）を確立する。ＵＥ１００Ａは、ＵＥ１００Ｂから受信した最初のデータ（及び各ＩＤ）に基づいて、送信元ＩＤを「Ｂ」とし、送信先ＩＤを「Ａ」とし、ＬＣＩＤを「２」とする第２の受信エンティティを確立する。

また、ＵＥ１００Ａは、上述と同様に、ＵＥ１００Ｃから受信した最初のデータ（及び各ＩＤ）に基づいて、送信元ＩＤを「Ｃ（ＵＥ１００Ｃ）」とし、送信先ＩＤを「Ａ」とし、ＬＣＩＤを「１」とする第３の受信エンティティを確立する。

ＵＥ１００Ａは、第１の送信エンティティによって、ＵＥ１００Ｂへデータを送信し、第２の受信エンティティによって、ＵＥ１００Ｂからのデータを受信し、第３の受信エンティティによって、ＵＥ１００Ｃからのデータを受信する。

（実施形態に係る動作）
以下において、実施形態に係る動作について、図７〜図９を用いて説明する。図７は、本実施形態に係るＤ２Ｄ通信に用いられる時間・周波数リソースの配置を説明するための一例を示す図である。図８は、Ｄ２Ｄ通信におけるＵＥ１００の動作を説明するための図である。図９は、Ｄ２Ｄ通信におけるＵＥ１００の動作（後述の第２の動作）を説明するための図である。

本実施形態では、Ｄ２Ｄ通信によってデータを送信するＵＥ１００は、データの繰り返し送信のための期間内に同一データを繰り返して送信する。当該期間（以下、繰り返し送信期間）は、時間方向に複数設けられている。

ＵＥ１００は、時間方向に周期的に配置されるデータ領域（Ｄａｔａ Ｒｅｇｉｏｎ：データリソースプール）内の時間・周波数リソースの中から、データの送信に用いる無線リソースを選択する。例えば、ＵＥ１００は、時間方向において同一データを送信するタイミングをランダムに設定していた場合、図７に示すように、データ領域の前半の時間・周波数リソースの中から、４つのサブフレームをランダムに選択し、データ領域の後半の時間・周波数リソースの中から、４つのサブフレームをランダムに選択する。ＵＥ１００は、データ領域の前半の時間・周波数リソースの中から選択した４つのサブフレームを用いて、所定のデータを繰り返し送信し、データ領域の前半の時間・周波数リソースの中から選択した４つのサブフレームを用いて、別のデータを繰り返し送信する。この場合、データ領域の前半及び後半のそれぞれの時間長さが繰り返し送信期間に該当する。或いは、ＵＥ１００は、データ領域の時間・周波数リソースの中から選択した８つのサブフレームを用いて、所定のデータを繰り返し送信する。この場合、データ領域の時間長さが繰り返し送信期間に該当する。

ＵＥ１００が、時間方向において同一データを送信するタイミングをランダムに設定することによって、ＵＥ１００から送信されたデータが他のＵＥから送信されたデータと連続的に衝突することを避けることができる。その結果、受信ＵＥは、ＵＥ１００から繰り返し送信される複数のデータ（同一データ）のうち、少なくとも１つのデータを受信することができる。

なお、ＵＥ１００は、時間方向に周期的に配置されるＳＡ領域内（ＳＡ Ｒｅｇｉｏｎ：ＳＡリソースプール）の時間・周波数リソースの中から、Ｄ２Ｄ通信によって送信されるデータ（用の無線リソース）の位置を示すＳＡ（Ｓｃｈｅｄｕｌｉｎｇ Ａｓｓｉｇｎｍｅｎｔ）を送信するための無線リソースを選択する。図７の例では、ＳＡの周波数位置とデータ用の無線リソースの周波数位置は同じであるため、受信ＵＥは、ＳＡの周波数位置によって、データの周波数位置を認識できる。

以下において、Ｄ２Ｄ通信よってＵＥ１００Ｂにデータを送信していたＵＥ１００Ａが、送信ＲＬＣエンティティを解放した後に、新たに送信ＲＬＣエンティティを確立して、ＵＥ１００Ｂにデータを送信するケースを例にして説明する（図８参照）。

まず、Ｄ２Ｄ通信中のＵＥ１００Ａは、所定時刻において、シーケンス番号値（ＳＮ値）がＮであるデータ（具体的には、パケット（ＵＭＤ ＰＤＵ））を送信する。これにより、ＵＥ１００ＡにおけるＶＴ（ＵＳ）は、Ｎ＋１となる。ここで、ＶＴ（ＵＳ）は、新しく生成されるＵＭＤ ＰＤＵに割り当てられるＳＮ値を保持する状態変数である。ＶＴ（ＵＳ）は、例えば、初期値は０に設定されており、ＵＭにおける送信ＲＬＣエンティティが、ＳＮ＝ＶＴ（ＵＳ）であるＵＭＤ ＰＤＵを送信するたびに更新される。

一方、ＵＥ１００Ｂは、ＵＥ１００Ａから、ＳＮ値がＮであるデータ（ＵＭＤ ＰＤＵ）を受信する。これにより、ＵＥ１００ＢのＶＲ（ＵＨ）は、Ｎ＋１になる。また、ＵＥ１００ＢのＶＲ（ＵＲ）は、Ｍ（≦Ｎ＋１）になる。ここで、ＶＲ（ＵＲ）は、ＵＭ受信状態変数であり、まだ並び替えが検討されている最も早いＵＭＤ ＰＤＵのＳＮ値を保持する状態変数である。なお、ＵＥ１００Ｂは、受信ＲＬＣエンティティを確立するトリガとなるデータ（ＵＥ１００Ａから受信した最初のデータ）のＳＮ値をＶＲ（ＵＲ）の初期値に設定することができる。本実施形態では、ＵＥ１００Ａからの最初のデータ（ＵＭＤ ＰＤＵ）のＳＮ値を、ＶＲ（ＵＲ）の初期値に設定する。また、ＶＲ（ＵＨ）は、ＵＭ最高受信状態変数であり、受信したＵＭＤ ＰＤＵのうち最も高いＳＮを有するＵＭＤ ＰＤＵのＳＮ値の次のＳＮ値を保持する状態変数である。ＶＲ（ＵＨ）は、並べ替えウィンドウの高位端の役割をする。なお、ＵＥ１００Ｂは、受信ＲＬＣエンティティを確立するトリガとなるデータ（ＵＥ１００Ａから受信した最初のデータ）のＳＮ値をＶＲ（ＵＨ）の初期値に設定することができる。本実施形態では、ＵＥ１００Ａからの最初のデータ（ＵＭＤ ＰＤＵ）のＳＮ値を、ＶＲ（ＵＨ）の初期値に設定する。

ＵＥ１００Ｂは、受信ＲＬＣエンティティにおいて、並べ替えウィンドウの範囲に位置するシーケンス番号（ＳＮ値）のデータ（ＵＭＤ ＰＤＵ）を所定条件下で破棄する。具体的には、ＳＮ＝ｘであるＵＭＤ ＰＤＵを下位層から受信したＵＥ１００Ｂ（受信ＲＬＣエンティティ）は、もし、「ＶＲ（ＵＲ）＜ｘ＜ＶＲ（ＵＨ）」を満たし、且つ、ＳＮ＝ｘを前に受信している場合、又は、「（ＶＲ（ＵＨ）−ＵＭ＿Ｗｉｎｄｏｗ＿Ｓｉｚｅ）＜＝ｘ＜ＶＲ（ＵＲ）」を満たす場合、受信したデータ（ＵＭＤ ＰＤＵ）を廃棄する。

なお、データのＳＮ値が、「（ＶＲ（ＵＨ）−ＵＭ＿Ｗｉｎｄｏｗ＿Ｓｉｚｅ）＜＝ＳＮ＜ＶＲ（ＵＨ）」を満たす場合、当該ＳＮ値は、並べ替えウィンドウの範囲に位置する（すなわち、並べ替えウィンドウ内に収まる）。従って、ＵＭ＿Ｗｉｎｄｏｗ＿Ｓｉｚｅは、並べ替えウィンドウの範囲を示す。なお、ＵＭ＿Ｗｉｎｄｏｗ＿Ｓｉｚｅは、並べ替えウィンドウを前進させることなく受信できるＵＭＤ ＰＤＵのＳＮを定義するために受信ＲＬＣエンティティによって使用される定数である。

一方、並べ替えウィンドウの範囲に位置するシーケンス番号のデータであり、且つ、上記所定条件を満たさなかったデータは、受信バッファ内に入れられる。受信バッファ内のデータは、ＳＮ順に並び替えられ、且つＲＬＣ ＳＤＵに再構築された後、上位層に転送される。

次に、ＵＥ１００Ａは、ＵＥ１００Ｂに送信すべきデータを送信し終わった場合、送信ＲＬＣエンティティ（及び送信ＰＤＣＰエンティティ）を解放する。その後、ＵＥ１００Ａは、ＵＥ１００Ｂに送信すべき新たなデータが発生することによって、新たな送信ＲＬＣエンティティを確立する。一方、受信ＲＬＣエンティティ（及び受信ＰＤＣＰエンティティ）の解放は、ＵＥ１００Ｂの実装に依存するため、ＵＥ１００Ｂは、受信ＲＬＣエンティティを維持していることがある。このような場合、既存のセルラ通信と同様に、ＵＥ１００Ａが、新たな送信ＲＬＣエンティティにおいて、ＳＮ値を初期値（すなわち「０」）に設定して、データの送信を開始することが想定される。

具体的には、図８に示すように、ＵＥ１００Ａは、ＳＮ値が０である新たなデータ（ＵＭＤ ＰＤＵ）を送信する。これにより、ＵＥ１００ＡのＶＴ（ＵＳ）は、１となる。一方、ＵＥ１００Ｂは、ＵＥ１００Ａから、ＳＮ値が０である新たなデータ（ＵＭＤ ＰＤＵ）を受信する。ここで、ＵＥ１００Ａが、解放した送信ＲＬＣエンティティと新たに確立した送信ＲＬＣエンティティとで、同一のＬＣＩＤを使用した場合、ＵＥ１００Ｂは、維持している受信ＲＬＣエンティティで、ＵＥ１００Ａからの新たなデータを受信する処理を行う。ＵＥ１００Ｂ（受信ＲＬＣエンティティ）のＶＲ（ＵＨ）は、Ｎ＋１であり、ＶＲ（ＵＲ）は、Ｍ（≦Ｎ＋１）であるため、ＵＥ１００ＡとＵＥ１００ＢとでＳＮ値にズレが発生している。従って、図８に示すように、「（ＶＲ（ＵＨ）−ＵＭ＿Ｗｉｎｄｏｗ＿Ｓｉｚｅ）＜＝０（＝ｘ）＜ＶＲ（ＵＲ）」が満たされ、ＵＥ１００Ｂは、受信ＲＬＣエンティティにおいて、受信した新たなデータを廃棄する可能性がある。

そこで、本実施形態では、以下に示す少なくともいずれかの動作（第１〜第３の動作）によって、ＵＥ１００Ｂが、新たなデータを既に受信したデータとみなして破棄することを抑制できる。

（Ａ）第１の動作
まず、第１の動作について説明する。第１の動作では、ＵＥ１００Ａが、送信ＲＬＣエンティティの解放に関する情報（以下、解放情報）をＵＥ１００Ｂに送信する。ＵＥ１００Ｂが、ＵＥ１００Ａから解放情報を受信する。

解放情報は、例えば、ＵＥ１００Ａが送信ＲＬＣエンティティを解放するために用いるタイマ（Ｉｎ−ａｃｔｉｖｉｔｙ ｔｉｍｅｒ）の情報である。ＵＥ１００Ａは、送信ＲＬＣエンティティを解放するために長さが異なる複数のタイマが規定されている場合、複数タイマのうち使用するタイマを示す情報（例えば、フラグ情報）を解放情報として送信する。

解放情報は、ＭＡＣ ＣＥによって、ＵＥ１００ＡからＵＥ１００Ｂに通知することができる。なお、規定された複数のタイマの情報は、ＳＩＢによって、各ＵＥに通知されてもよいし、各ＵＥに事前設定されていてもよい。

ＵＥ１００Ｂは、解放情報に基づいて、ＵＥ１００Ｂからデータを受信するための受信ＲＬＣエンティティを解放することができる。具体的には、ＵＥ１００Ｂは、遅くともＵＥ１００Ａが送信ＲＬＣエンティティを解放する時間を超える前に、受信ＲＬＣエンティティを解放する。ＵＥ１００Ｂは、ＵＥ１００Ｂの実装に依存して、送信ＲＬＣエンティティが解放する時間と同時に、受信ＲＬＣエンティティを解放してもよいし、送信ＲＬＣエンティティが解放する時間よりも前に、受信ＲＬＣエンティティを解放してもよい。

これにより、送信ＲＬＣエンティティが、受信ＲＬＣエンティティよりも先に解放されることを抑制できる。その結果、ＵＥ１００Ｂが、新たなデータを既に受信したデータとみなして破棄することを抑制できる。

なお、送信ＲＬＣエンティティが解放される前に、ＵＥ１００Ｂが、受信ＲＬＣエンティティを解放したとしても、ＵＥ１００Ｂは、ＵＥ１００Ａから送信されたデータのＳＮ値を初期値として、受信ＲＬＣエンティティを確立することによって、ＵＥ１００ＡとＵＥ１００ＢとでＳＮ値にズレが発生しない。従って、受信ＲＬＣエンティティが解放された後に、維持されている送信ＲＬＣエンティティによってデータが送信されても、問題ない。

或いは、ＵＥ１００Ｂは、解放情報に基づいて、送信ＲＬＣエンティティが解放された後にＵＥ１００Ａからデータを受信した場合、受信したデータを新たなデータとみなして、破棄せずに処理してもよい。例えば、ＵＥ１００Ｂは、受信ＲＬＣエンティティを維持していた場合、新たなデータのＳＮ値に補正値を加える処理を行ってもよい。

或いは、ＵＥ１００Ｂは、解放情報に基づいて、ＵＥ１００Ａのタイマ（Ｉｎ−ａｃｔｉｖｉｔｙ ｔｉｍｅｒ）が満了したと判定した場合、受信ＲＬＣエンティティにおいて保持しているデータを全て上位層に転送した後、次に受信したデータを新たなデータとして処理してもよい。例えば、ＵＥ１００Ｂは、解放情報に基づいて設定したタイマが満了した場合、受信バッファ内の全てのデータを上位層に転送した後、少なくとも受信ＲＬＣエンティティのＳＮ値を初期化する処理を行ってもよい。

（Ｂ）第２の動作
次に、第２の動作について、図９を用いて説明する。第２の動作では、ＵＥ１００Ｂが、ＵＭ＿Ｗｉｎｄｏｗ＿Ｓｉｚｅを０に設定する。

上述のように、ＵＭ＿Ｗｉｎｄｏｗ＿Ｓｉｚｅが０より大きい場合、ＵＥ１００Ｂ（受信ＲＬＣエンティティ）は、受信した新たなデータを廃棄する可能性がある。このため、ＵＭ１００Ｂは、受信ＲＬＣエンティティにおいて、ＵＭ＿Ｗｉｎｄｏｗ＿Ｓｉｚｅを０に設定する。これにより、受信したデータのシーケンス番号は、並べ替えウィンドウの範囲に位置しないため、ＵＥ１００Ｂは、受信ＲＬＣエンティティにおいて、受信したデータを破棄せずに、上位層（具体的には、受信ＰＤＣＰエンティティ）に転送する。その結果、新たなデータを既に受信したデータとみなして破棄することを抑制できる。

なお、ＵＭ＿Ｗｉｎｄｏｗ＿Ｓｉｚｅが０に設定された場合、受信ＲＬＣエンティティにおいて、データの並び替えが行われずに、受信データが上位層に転送される。従って、ＵＥ１００は、受信ＲＬＣエンティティにおいて並べ替えを必要としない場合に、ＵＭ＿Ｗｉｎｄｏｗ＿Ｓｉｚｅを０に設定してもよい。

例えば、ＵＥ１００Ｂは、Ｄ２Ｄ通信によって送信されるデータの種別に応じて、ＵＭ＿Ｗｉｎｄｏｗ＿Ｓｉｚｅを０に設定してもよい。具体的には、ＵＥ１００Ｂは、データが音声データや映像データなどのリアルタイムでの処理を要求するデータである（例えば、データの許容遅延が所定値以上である）場合は、ＵＭ＿Ｗｉｎｄｏｗ＿Ｓｉｚｅを０に設定し、データが文書データである場合、ＵＭ＿Ｗｉｎｄｏｗ＿Ｓｉｚｅを通常のサイズに設定してもよい。

或いは、ＵＥ１００Ｂは、Ｄ２Ｄ通信によって送信されるデータの宛先（送信先ＩＤ）に応じて、ＵＭ＿Ｗｉｎｄｏｗ＿Ｓｉｚｅを０に設定してもよい。具体的には、ＵＥ１００Ｂは、送信先ＩＤが、グループキャスト又はブロードキャストを示すＩＤである場合、ＵＭ＿Ｗｉｎｄｏｗ＿Ｓｉｚｅを０に設定し、送信先ＩＤが、ユニキャスト（ＵＥ１００Ｂ）を示すＩＤである場合、ＵＭ＿Ｗｉｎｄｏｗ＿Ｓｉｚｅを通常のサイズに設定してもよい。

或いは、ＵＥ１００Ｂは、Ｄ２Ｄ通信において使用されるアプリケーションに応じて、ＵＭ＿Ｗｉｎｄｏｗ＿Ｓｉｚｅを０に設定してもよい。具体的には、ＵＥ１００Ｂは、当該アプリケーションが、音声通信又は映像通信を目的とするアプリケーションである場合、ＵＭ＿Ｗｉｎｄｏｗ＿Ｓｉｚｅを０に設定し、当該アプリケーションが、文書データの転送を目的とするアプリケーションである場合、ＵＭ＿Ｗｉｎｄｏｗ＿Ｓｉｚｅを通常のサイズに設定してもよい。

（Ｃ）第３の動作
次に、第３の動作について説明する。第３の動作では、ＵＥ１００Ａは、データの送信開始又は終了の少なくとも一方を示す情報を送信する。ＵＥ１００Ｂは、当該情報に基づいて、受信ＲＬＣエンティティを解放する。

例えば、ＵＥ１００Ａは、当該情報として、データの送信開始を示すコードを送信した後に、データの送信を開始する。或いは、ＵＥ１００Ａは、最初のデータと共に当該情報を送信する。ＵＥ１００Ｂは、当該情報を受信することによって、ＵＥ１００Ａがデータの送信を開始したことを認識できる。従って、ＵＥ１００Ｂは、当該情報を受信した後に受信したデータは、新たなデータであると判定することができる。このため、新たなデータを既に受信したデータとみなして破棄することを抑制できる。

ＵＥ１００Ａは、当該情報をＭＡＣ ＣＥによって送信してもよいし、最初のデータのＭＡＣ ｓｕｂｈｅａｄｅｒに当該情報を追加することによって送信してもよい。

或いは、ＵＥ１００Ａは、データの送信を終了した後に、当該情報として、データの送信終了を示すコードを送信する。或いは、ＵＥ１００Ｂは、最後のデータと共に、当該情報を送信する。ＵＥ１００Ｂは、当該情報を受信することによって、ＵＥ１００Ａがデータの送信を終了したことを認識できる。従って、ＵＥ１００Ｂは、当該情報を受信した後に受信したデータは、新たな送信ＲＬＣエンティティによって送信された新たなデータであると判定することができる。このため、新たなデータを既に受信したデータとみなして破棄することを抑制できる。

ＵＥ１００Ａは、当該情報をＭＡＣ ＣＥによって送信してもよいし、最後のデータのＭＡＣ ｓｕｂｈｅａｄｅｒに当該情報を追加することによって送信してもよい。

或いは、ＵＥ１００Ａは、当該情報として、データの１ブロックの開始から終了までを識別するフラグ情報（識別子）を送信する。具体的には、ＵＥ１００Ａは、データのブロックが変わる毎に、フラグ情報を示す変数をインクリメントする。例えば、フラグ情報が１ビットで構成される場合、データのブロックが変わる度に、０，１，０，１，…のようにフラグ情報が変化する。フラグ情報が２ビットで構成される場合、データのブロックが変わる度に、０，１，２，３，０，１，…のようにフラグ情報が変化する。

このため、ＵＥ１００Ｂは、フラグ情報の変化によって、受信したデータが新たなデータのブロックであるか否かを識別することができる。従って、ＵＥ１００Ｂは、受信したデータが破棄される場合であっても、フラグ情報に基づいて、当該データが新たなデータのブロックであると識別した場合には、新たな受信エンティティを確立して、新たな受信エンティティにおいて当該データを処理することができる。或いは、ＵＥ１００Ｂは、新たな受信エンティティにおいて、当該データを破棄せずに、ＳＮ値を補正した上で、当該データを処理してもよい。

フラグ情報は、データが送信される場合に、必ずデータと共に送信されてもよい。この場合、例えば、データのＭＡＣ ｓｕｂｈｅａｄｅｒに、送信元ＩＤ、送信先ＩＤ、ＬＣＩＤと共にフラグ情報を入れることによって、必ずデータと共に送信できる。或いは、フラグ情報は、データの送信が開始される場合とデータの送信が終了する場合に送信されてもよいし、データの送信が行われている場合に、適宜送信されてもよい。この場合、フラグ情報は、ＭＡＣ ＣＥによって送信されてもよいし、専用のＭＡＣ ｓｕｂｈｅａｄｅｒによって送信されてもよい。

なお、第３の動作において、例えば、データが音声データの場合、データの送信開始及び終了は、無声及び／又は有声の検知によって決定することができる。また、データが文書データである場合、１つの文書データが１ブロックとして扱われてもよいし、１つの文書データが分割されることによって生成された複数のデータのそれぞれが１ブロックとして扱われてもよい。また、ＰＴＴ（Ｐｕｓｈ Ｔｏ Ｔａｌｋ）において、ＯＦＦからＯＮへの切り替わりがデータの送信開始であり、ＯＮからＯＦＦへの切り替わりがデータの送信終了であってもよい。

［その他の実施形態］
上述した実施形態では、ＵＥ１００Ａが、繰り返し送信期間内に同一データを繰り返して送信する。この場合において、ＵＥ１００Ｂは、第１の繰り返し送信期間内にＵＥ１００Ａからデータを受信した後、第１の繰り返し送信期間の後に続く第２の繰り返し送信期間を超えてもＵＥ１００Ａからデータを受信しない場合、受信ＲＬＣエンティティを解放してもよい。ＵＥ１００Ｂは、次にＵＥ１００Ａからデータが送信される第２の繰り返し送信期間内においてデータを受信できない場合には、ＵＥ１００Ａからデータの送信が終了したと判定できるためである。これにより、受信ＲＬＣエンティティを維持し続けることによって発生するＳＮ値のズレを抑制することができる。

繰り返し送信期間は、Ｄ２Ｄ通信において使用されるアプリケーションに応じて設定された値であってもよい。例えば、繰り返し送信期間は、音声通信又は映像通信を目的とするアプリケーションの方が、文書データの転送を目的とするアプリケーションよりも、短く設定されてもよい。或いは、繰り返し送信期間は、音声通信又は映像通信を目的とするアプリケーションである場合、にのみ設けられてもよい。

なお、Ｄ２Ｄ通信において繰り返し送信期間内に同一データを繰り返して送信するための設定情報は、各ＵＥ１００（ＵＥ１００Ａ及びＵＥ１００Ｂのそれぞれ）に事前に設定されていてもよいし、ＳＩＢによって各ＵＥ１００に送信されてもよい。これによって、ＵＥ１００ＡとＵＥ１００Ｂとが、繰り返し送信期間を共有することができる。

また、上述した実施形態において、ＵＥ１００Ａは、ブロードキャスト及びグループキャストではなく、ＵＥ１００Ｂを対象として（ユニキャストで）同一データを繰り返して送信する場合、送信の度に、送信アンテナ重みを変更してもよい。これにより、送信アンテナ重みが一定の場合には複数回の送信のうち全ての受信品質が悪い場合であっても、送信の度に送信アンテナ重みを変更することによって、複数の送信のうち少なくとも１回の送信は、受信品質を良好にすることが可能となる。

また、上述した実施形態では、ＳＡの周波数位置とデータ用の無線リソースの周波数位置は同じであったが、これに限られない。例えば、データ用の無線リソースの周波数位置はランダムであってもよい。この場合、ＳＡにデータ用の無線リソースの周波数位置を示す情報が含まれていてもよいし、例えば、ＳＡの周波数位置に応じてデータ用の無線リソースの周波数位置がランダムになるように、ＳＡの周波数位置にデータ用の無線リソースの周波数位置が関連付けられていてもよい。

また、上述した実施形態では、ＵＥ１００Ａが、繰り返し送信期間内に同一データを繰り返して送信していたが、これに限られない。ＵＥ１００が、同一データを繰り返して送信しない（或いは、繰り返し送信期間が設けられない）場合であっても、上述の動作１から３の少なくともいずれかの動作によって、受信ＵＥが、新たなデータを既に受信したデータとみなして破棄することを抑制できる。

また、上述した実施形態において、ＵＥ１００Ａは、Ｄ２Ｄ通信によって音声データ（音声パケット）を送信する場合、１パケットを分割して複数のサブフレームで複数の分割されたパケットを送信するのではなく、１パケットを１サブフレームで送信してもよい。この場合、ＵＥ１００Ｂは、パケットが分割されていないため、受ＲＬＣエンティティにおいてパケット（ＲＬＣ ＰＤＵ）の組み立て処理を行わずに、上位層に転送できる。従って、ＵＭ＿Ｗｉｎｄｏｗ＿Ｓｉｚｅが０に設定されていた場合の上位層での並び替えが不要になるため、第２の動作において特に有効である。

また、上述した実施形態において、ＵＥ１００Ａが、上位レイヤからの指示（シグナリング）によって、送信ＲＬＣエンティティを解放する場合、ＵＥ１００Ａは、当該指示を受信してから所定期間経過するまで、送信ＲＬＣエンティティで使用された送信先ＩＤ、ＬＣＩＤ及び最後に送信したデータのＳＮ値を保持していてもよい。

ＵＥ１００Ａは、所定期間を経過する前に、解放を指示された送信ＲＬＣエンティティによって送信していたＵＥ１００Ｂに対して送信すべき新たなデータが発生した場合、以下のいずれかの方法によって、新たなデータを送信する。

第１に、ＵＥ１００Ａは、保持していたＬＣＩＤと同じＬＣＩＤを用いて、ＵＥ１００Ｂに送信する場合、送信ＲＬＣエンティティにおいて、最後に送信したデータのＳＮ値の次のＳＮ値を初期値として、新たなデータの送信を開始する。これにより、ＵＥ１００Ｂが、受信ＲＬＣエンティティを解放していない場合には、新たなデータのＳＮ値は、以前のデータの続きのＳＮ値であるため、ＵＥ１００Ｂは、受信ＲＬＣエンティティにおいて、新たなデータを破棄することなく、処理することができる。

第２に、ＵＥ１００Ａは、保持していたＬＣＩＤと異なるＬＣＩＤを用いて、ＵＥ１００Ｂに新たなデータを送信する。これにより、ＵＥ１００Ｂは、受信ＲＬＣエンティティを解放していない場合であっても、ＬＣＩＤが異なる新たなデータの受信に応じて、新たな受信ＲＬＣエンティティを確立する。従って、ＵＥ１００Ｂは、新たな受信ＲＬＣエンティティにおいて新たなデータを処理するため、新たなデータを破棄することがない。

なお、ここでの所定期間は、例えば、受信ＲＬＣエンティティが使用されなくなってから解放されるまでのタイマよりも長い期間に設定される。

また、第２の動作では、ＵＭ＿Ｗｉｎｄｏｗ＿Ｓｉｚｅを０に設定していたが、これに限られない。ＵＭ＿Ｗｉｎｄｏｗ＿Ｓｉｚｅを規定値よりも小さい値に設定してもよい。ＬＴＥシステムにおいて、ＵＭ＿Ｗｉｎｄｏｗ＿Ｓｉｚｅの規定値は、２ＳＮ Ｌｅｎｇｔｈ／２（２の「ＳＮビット長／２」乗）であるため、例えば、ＵＭ＿Ｗｉｎｄｏｗ＿Ｓｉｚｅを２ＳＮ Ｌｅｎｇｔｈ／ｘ （Ｘ＞２）に設定してもよい。具体的には、ＵＥ１００Ｂは、ＵＭ＿Ｗｉｎｄｏｗ＿Ｓｉｚｅ＝２ＳＮ Ｌｅｎｇｔｈ／２に設定してもよい。これにより、並べ替えウィンドウの範囲が小さくなるため、受信したデータのシーケンス番号は、並べ替えウィンドウの範囲に位置し難くなるため、受信したデータの破棄を抑制しつつも、並び替え処理を行うことが可能である。

また、ＵＥ１００ＡとＵＥ１００ＢとでＳＮ値にズレが発生することによって、受信ＲＬＣエンティティにおいてデータのＳＮ値が並べ替えウィンドウの範囲外であった場合に、新たなデータのＳＮ値に基づいて並べ替えウィンドウが移動する。この場合、Ｄ２Ｄ通信では、並べ替えウィンドウが移動する前に受信バッファ内にあるデータが処理されない（或いは破棄される）虞がある。しかしながら、第１の動作及び第３の動作では、並べ替えウィンドウの移動を防ぐことができるため、このような問題も解消できる。

また、上述した実施形態において、ＵＥ１００Ｂは、受信ＲＬＣエンティティを確立するトリガとなるデータ（最初のデータ）のＳＮ値をＶＲ（ＵＲ）の初期値に設定していたが、これに限られない。ＵＥ１００Ｂは、ＶＲ（ＵＲ）の初期値を、受信ＲＬＣエンティティを確立するトリガとなるデータのＳＮ値よりも小さい値に設定できる。例えば、ＵＥ１００Ｂは、ＵＥ１００Ａから受信した最初のデータのＳＮ値がＮ＋１である場合、ＶＲ（ＵＲ）の初期値を「（Ｎ＋１）−（ＵＭ＿Ｗｉｎｄｏｗ＿Ｓｉｚｅ／ｘ）」（ｘは任意の数）に設定できる。これにより、以下のケースにおいて、新たなデータを既に受信したデータと見なして破棄することを抑制できる。

まず、ＵＥ１００ＡとＤ２Ｄ通信を行っていたＵＥ１００Ｂが、受信ＲＬＣエンティティを解放した後、送信ＲＬＣエンティティを解放せずに維持しているＵＥ１００ＡからＳＮ値がＮ＋１であるデータを受信する。これにより、ＵＥ１００Ｂは、新たな受信ＲＬＣエンティティを確立してＵＥ１００Ａからのデータを受信する。ＵＥ１００Ｂは、受信ＲＬＣエンティティを確立するトリガとなるデータのＳＮ値であるＮ＋１をＶＲ（ＵＲ）の初期値に設定する。次に、ＵＥ１００Ａが、ＳＮ値の順番通りにデータを送信できず、新たな受信ＲＬＣエンティティによって受信する前のＳＮ値（例えば、Ｎ）を持つデータをＵＥ１００Ｂに送信したと仮定する。例えば、ＵＥ１００Ｂは、繰り返し送信又はＰＨＹレベルで再送した場合、ＳＮ値の順番通りにデータを送信できない。この場合、「（ＶＲ（ＵＨ）−ＵＭ＿Ｗｉｎｄｏｗ＿Ｓｉｚｅ）＜ Ｎ ＜ ＶＲ（ＵＲ）（＝Ｎ＋１）」が満たされ、ＵＥ１００Ｂは、繰り返し送信又はＰＨＹレベルで再送されたデータを、正常に受信できる場合であっても、廃棄する可能性がある。しかしながら、ＵＥ１００Ｂが、ＶＲ（ＵＲ）の初期値を、受信ＲＬＣエンティティを確立するトリガとなるデータのＳＮ値よりも小さい値に設定することによって、データ破棄の対象となる範囲が小さくなるため、新たなデータを既に受信したデータと見なして破棄することを抑制できる。

なお、ＵＥ１００Ｂは、Ｄ２Ｄ通信によって送信されるデータの種別に応じて、ＶＲ（ＵＲ）の初期値を、最初のデータのＳＮ値よりも小さい値に設定してもよいし、前記Ｄ２Ｄ通信よって送信されるデータの宛先に応じて、ＶＲ（ＵＲ）の初期値を、最初のデータのＳＮ値よりも小さい値に設定してもよい。例えば、ＵＥ１００Ｂは、データの種別が、リアルタイムでの処理が要求されないデータである（例えば、データの許容遅延が所定値以上である）場合、ＶＲ（ＵＲ）の初期値を最初のデータのＳＮ値よりも小さい値に設定できる。或いは、ＵＥ１００Ｂは、送信先ＩＤが、グループキャスト又はブロードキャストを示すＩＤである場合、ＶＲ（ＵＲ）の初期値を最初のデータのＳＮ値よりも小さい値に設定できる。これにより、通信品質を低減させることなく、新たなデータを既に受信したデータと見なして破棄することを抑制できる。

また、上述した実施形態では、ＲＬＣエンティティは、ＵＭで動作していたが、これに限られない。ＲＬＣエンティティは、確認応答モード（ＡＭ）で動作してもよい。ＡＭでは、データ分割・組み立てを行うだけでなく、ＲＬＣ ＰＤＵの伝送失敗時のＡＲＱ再送も行う。ＭＡＣレイヤでのＨＡＲＱとＲＬＣエンティティでのＡＲＱとで二重に再送を行うことで、より高い信頼性を得ることができる。

上述した実施形態では、移動通信システムの一例としてＬＴＥシステムを説明したが、ＬＴＥシステムに限定されるものではなく、ＬＴＥシステム以外のシステムに本出願の内容を適用してもよい。

［付記１］
以下に、実施形態の補足事項について付記する。

（１）導入
送信ＰＤＣＰ／ＲＬＣエンティティの解放タイミングは、合意されていない。この付記では、不必要なＵＭＤ ＰＤＵの破棄を抑制する適切な解放手順、及び、送信及び受信ＰＤＣＰ／ＲＬＣ設定を同じ立場で考える必要性について検討する。

（２）考察
Ｄ２Ｄ通信のための手順を以下で説明する（図１０参照）。図１０は、カバレッジ外及びカバレッジ内Ｄ２Ｄ通信の例を示す図である。

カバレッジ外のＤ２Ｄ通信（Ａ）について簡単に説明する。図１０に示すように、カバレッジ外のＤ２Ｄ通信（Ａ）では、ＵＥ１００ＡとＵＥ１００Ｂとがカバレッジ外に位置する。

まず、ＵＥ１００Ａ及びＵＥ１００Ｂは、同期を取る。その後、ＵＥ１００Ａにデータが発生する。このデータは、ＵＥ１００Ｂに送信すべきデータである。ＵＥ１００Ａは、送信ＰＤＣＰ／ＲＬＣエンティティを確立する（ステップ１）。この動作は、ＵＥ実装の動作である。次に、ＵＥ１００Ａは、送信リソースを選択する。ＵＥ１００Ａは、選択した送信リソースを通知するための制御情報（ＳＡ）を送信する。ＵＥ１００Ｂは、制御情報をＵＥ１００Ａから受信する。ＵＥ１００Ｂは、受信したＳＡをデコードする。ＵＥ１００Ｂは、デコードしたＳＡに基づいて、データの送信に用いられる送信リソースを把握する。次に、ＵＥ１００Ａは、データを送信する。ＵＥ１００Ｂは、把握した送信リソースに基づいて、データを受信する。ＵＥ１００Ｂは、Ｌ２ ＩＤ及びＬＣＩＤを取得する。ＵＥ１００Ｂは、受信ＰＤＣＰ／ＲＬＣエンティティを確立する（ステップ２）。次に、ＵＥ１００Ａは、データを送信する。ＵＥ１００Ｂは、データを受信する。ＵＥ１００Ｂは、受信ＰＤＣＰ／ＲＬＣエンティティを解放する。この動作は、ＵＥ実装の動作である。ＵＥ１００Ａは、送信ＰＤＣＰ／ＲＬＣエンティティを解放する（ステップ３）。

次に、カバレッジ内のＤ２Ｄ通信（Ｂ）について簡単に説明する。なお、カバレッジ外のＤ２Ｄ通信（Ａ）と同様の部分は説明を適宜省略する。図１０に示すように、カバレッジ内のＤ２Ｄ通信（Ｂ）では、ＵＥ１００Ａ及びＵＥ１００Ｂは、ｅＮＢ２００のセルのカバレッジ内に位置する。

まず、ｅＮＢ２００は、システム情報ブロック（ＳＩＢ１８）をブロードキャストによって送信する。ＵＥ１００Ａ及びＵＥ１００Ｂは、システム情報ブロックを受信する。

ＵＥ１００Ａにデータが発生する。ＵＥ１００Ａは、送信ＰＤＣＰ／ＲＬＣエンティティを確立する（ステップ１）。ＵＥ１００Ａは、ランダムアクセスプリアンブル（ＲＡ）又はスケジューリング要求（ＳＲ）を送信し、かつ、Ｄ２Ｄ通信におけるバッファステータスレポート（ＢＳＲ）を送る。ｅＮＢ２００は、ＢＳＲに基づいて、ＳＡリソース割り当て及びデータ送信リソース割り当てをＵＥ１００Ａに送信する。ＵＥ１００Ａは、ＳＡリソース割り当てに基づいて、ＳＡをＵＥ１００Ｂに送信する。なお、ＳＡは、ｅＮＢ２００から受信したデータ送信リソース割り当てを示す。ＵＥ１００Ｂは、ＳＡをデコードする。ＵＥ１００Ｂは、デコードしたＳＡに基づいて、データの送信に用いられる送信リソース（データ送信リソース割り当て）を把握する。以後の動作は、カバレッジ外のＤ２Ｄ通信（Ａ）と同様である。

図１０のＰＤＣＰ及びＲＬＣに関連する手順で示されるように、いくつかの未解決な問題、特に、ステップ１、２及び３は、まだ解決する必要がある。これらの問題について、以下で詳細に考察する。

（２．１）ＰＤＣＰ／ＲＬＣ設定不一致
ステップ１及び２に関して、ＰＤＣＰ及びＲＬＣエンティティが確立された場合、ＰＤＣＰ／ＲＬＣ関連パラメータの設定は、まだ決まっていない。設定されるべきパラメータを表１に示す。表１は、ＰＤＣＰ及びＲＬＣ設定のためのパラメータである。

（ＰＤＣＰのための）破棄タイマパラメータ（ｄｉｓｃａｒｄＴｉｍｅｒ）は、送信エンティティにより使用されることのみを意味し、（ＲＬＣのための）再順序パラメータ（ｔ−Ｒｅｐｒｄｅｒｉｎｇ）は、受信エンティティにより使用されることのみを意味するので、これらの値は、送信及び受信エンティティ（Ｔｘ及びＲｘエンティティ）の間で共有される必要がない。しかしながら、表１に列挙した他のパラメータは、ＰＤＵが正しく処理されるために、送信及び受信エンティティ間で共有される必要がある。セルラのための現在の仕様によれば、これらのパラメータは、ＵＥ１００とｅＮＢ２００とが共通の値を共有するように、ＲＲＣシグナリングを介してＵＥ１００に設定される。しかしながら、Ｄ２Ｄに関して、ＲＲＣシグナリングを介して受信ＰＤＣＰ／ＲＬＣエンティティを確立しないことがすでに合意されている。代わりに、受信ＰＤＣＰ／ＲＬＣエンティティは、最初に受信したＵＭＤ ＰＤＵに応じて確立される。特に、カバレッジ外シナリオ（図１０（Ａ））に関して、ＵＥ１００（Ｄ２Ｄ ＵＥ）は、ＲＲＣシグナリングを受信することができず、送信及び受信ＰＤＣＰ／ＲＬＣエンティティの両方が、他の手段を通じて、パラメータの値を協調する必要がある。

カバレッジ外シナリオでは、ＰＤＣＰ／ＲＬＣ設定のためのパラメータ値を協調する最も簡単な方法は、事前設定（ｐｒｅ−ｃｏｎｆｉｇｕｒａｔｉｏｎ）によるものである。表１のすべてのパラメータが１つの可能な値のみを有する場合、事前設定は、実行可能な解決策かもしれない。しかし、各パラメータに対して１以上の値がサポートされる必要がある場合、以下に示すように、代替的な解決策が必要かもしれない。

カバレッジ内シナリオ、特に、セル内配置シナリオ（ｉｎｔｒａ−ｃｅｌｌ ｄｅｐｌｏｙｍｅｎｔ ｓｃｅｎａｒｉｏ）では（図１０（Ｂ））、送信Ｄ２Ｄ ＵＥ（ＵＥ１００Ａ）及び受信Ｄ２Ｄ ＵＥ（ＵＥ１００Ｂ）の両方が、サービングセルからの信号を受信できる。従って、ＵＥ１００（Ｄ２Ｄ ＵＥ）は、ＰＤＣＰ／ＲＬＣ設定のためのパラメータ値を取得するために、ＳＩＢを使用できる。セル間配置シナリオ（ｉｎｔｅｒ−ｃｅｌｌ ｄｅｐｌｏｙｍｅｎｔ ｓｃｅｎａｒｉｏ）に関して、サービングセルのＳＩＢが隣接セルの情報として隣接セルのＰＤＣＰ／ＲＬＣ設定を含む場合、ＵＥ１００（Ｄ２Ｄ ＵＥ）は、ＳＩＢを使用できる。カバレッジ外シナリオに関して、解決策は、表１のすべてのパラメータが１以上の値を有するかどうかによって決まる。

部分的カバレッジシナリオに関して、カバレッジ内ＵＥ１００とカバレッジ外ＵＥ１００とのＰＤＣＰ／ＲＬＣ設定を同じ立場で考えるために、送信ＵＥ１００（Ｔｘ Ｄ２Ｄ ＵＥ）は、ＰＤＣＰ／ＲＬＣ設定のためのパラメータ値を受信ＵＥ１００（Ｒｘ Ｄ２Ｄ ＵＥ）に提供する必要がある。

・提案１：送信ＵＥ１００（送信Ｄ２Ｄ ＵＥ）が、ＰＤＣＰ／ＲＬＣ設定のための所望のパラメータ値を自律的に選択することが許可されるかどうかを検討すべきである。

送信ＵＥ１００は、ＰＤＣＰ／ＲＬＣ設定を自律的に選択することが許可されない場合、１つのＰＤＣＰ／ＲＬＣ設定が、送信及び受信ＰＤＣＰ／ＲＬＣエンティティ間で特定される必要がある。Ｄ２Ｄ通信に関して、送信及び受信ＵＥ１００の両方が、受信ＳＡリソースプールを共有でき、従って、同じＰＤＣＰ／ＲＬＣ設定がＳＡ受信リソースプール毎に共有されるという１つの可能性がある。これは、カバレッジ外、カバレッジ内及び部分的カバレッジシナリオを含む全てのＤ２Ｄシナリオに適用できる可能性を有する。

・提案２：送信ＵＥ１００（送信Ｄ２Ｄ ＵＥ）が、ＰＤＣＰ／ＲＬＣ設定を自律的に選択することが許可されない場合、１つのＰＤＣＰ／ＲＬＣ設定がＳＡ受信リソースプール毎に特定されてもよい。

しかしながら、送信ＵＥ１００（送信Ｄ２Ｄ ＵＥ）が、ＰＤＣＰ／ＲＬＣ設定を自律的に選択することが許可された場合、送信ＵＥ１００が設定されたパラメータ値を受信ＵＥ１００と共有する手段として、以下の代替策を考慮すべきである。

・代替策１：ＭＡＣサブヘッダを介した配信
・代替策２：ＳＡを介した配信
・代替策３：ＰＤ２ＤＳＣＨを介した配信

代替策１及び代替策２は、全てのシナリオに適用できるが、代替策３は、送信ＵＥ１００が同期元でない限り、ＵＥ１００に適用できない。特に、カバレッジ内シナリオに関して、ＵＥ１００（Ｄ２Ｄ ＵＥ）の大多数が同期元でないことが前提であり、代替策３は、除外すべきである。

・提案３：信ＵＥ１００（送信Ｄ２Ｄ ＵＥ）が、ＰＤＣＰ／ＲＬＣ設定を自律的に選択することが許可された場合、２つの代替策（代替策１又は代替策２）のどちらを選択したＰＤＣＰ／ＲＬＣ設定を受信ＵＥ１００（）へ配信するために採用すべきか検討すべきである。

（２．２）ＰＤＣＰ及びＲＬＣエンティティの解放タイミング
ＰＤＣＰ及びＲＬＣ解放タイミングの問題（図１０のステップ３）に関して、ＰＤＣＰエンティティ及びＲＬＣエンティティが一緒に確立され、かつ、解放されなければならないことが想定されている。しかしながら、送信エンティティ及び受信エンティティが協調すべきかどうかについての合意はない。送信ＰＤＣＰ／ＲＬＣエンティティの解放タイミングは、受信ＲＬＣエンティティでのＵＭＤ ＰＤＵの受信成功に影響を与える。ＰＤＣＰ／ＲＬＣエンティティの解放タイミングの影響は、以下においてさらに考察する。

上述の図８に示すように、送信ＲＬＣエンティティ（例えば、送信元ＩＤ：Ａ、送信先ＩＤ：Ｂ、ＬＣＩＤ：０）が、受信ＲＬＣエンティティ（例えば、送信元ＩＤ：Ａ、送信先ＩＤ：Ｂ、ＬＣＩＤ：０）よりも早く解放され、かつ、送信ＲＬＣエンティティ（例えば、送信元ＩＤ：Ａ、送信先ＩＤ：Ｂ、ＬＣＩＤ：０）が、受信ＲＬＣエンティティが解放される前に再び確立された場合、受信ＲＬＣエンティティは、送信ＲＬＣエンティティのＳＮ（例えば、ＳＮ＝０）と受信ＲＬＣエンティティのＳＮ（例えば、ＶＲ（ＵＨ）＆ＶＲ（ＵＲ）＝Ｎ＋１）との間の不一致が原因で、Ｄ２Ｄ通信に関するＵＭＤ ＰＤＵを破棄する。

上記問題は、受信ＲＬＣエンティティの解放タイミングがＵＥ実装次第である場合、生じる。上記問題を解決するために、以下の代替策を考察する。

代替策１：送信ＲＬＣエンティティ及び受信ＲＬＣエンティティ間の共通タイマの導入
受信ＲＬＣエンティティが不必要に長期間有効のまま継続することを抑制するために、最後のＵＭＤ ＰＤＵを受信した後、ＲＬＣエンティティが有効のまま継続してもよい最大時間を示す「有効中タイマ（ｉｎ−ａｃｔｉｖｉｔｙ ｔｉｍｅｒ）」を導入することが有用である。

このタイマが導入された場合、送信ＲＬＣエンティティ及び受信ＲＬＣエンティティの解放タイミングが適切に協調でき、かつ、受信ＲＬＣエンティティでのＵＭＤ ＰＤＵの破棄を防ぐことができる可能性がある。

例えば、送信ＲＬＣエンティティは、有効中タイマが起動している間、解放されることはない。或いは、送信ＲＬＣエンティティは、有効中タイマが起動している間、以前に使用されたものと同じＬＣＩＤを使用することを自制することができる。詳細な手順は、図１１に示す。図１１は、動作に関連する有効中タイマの例を示す。図１０と同様の部分は、説明を省略する。

図１１において、ＵＥ１００Ａは、データを送信した後、有効中タイマをスタートする。ＵＥ１００Ａは、データを送信する度に、有効中タイマを再スタートする。一方、ＵＥ１００Ｂは、ＰＤＣＰ／ＲＬＣエンティティを確立し、有効中タイマをスタートする。ＵＥ１００Ｂは、データを受信する度に、有効中タイマを再スタートする。

ＵＥ１００Ａは、有効中タイマの継続時間（起動時間）よりも長い継続時間Ａが経過した後に、送信ＰＤＣＰ／ＲＬＣエンティティを解放する（ステップＳ３）。すなわち、ＵＥ１００Ａは、有効中タイマが満了した後に、送信ＰＤＣＰ／ＲＬＣエンティティを解放する。一方、ＵＥ１００Ｂは、有効中タイマの継続時間よりも長い継続時間Ｂが経過した後に、受信ＰＤＣＰ／ＲＬＣエンティティを解放する（ステップＳ２）。すなわち、ＵＥ１００Ｂは、有効中タイマが満了する前に、受信ＰＤＣＰ／ＲＬＣエンティティを解放する。

代替策２：再順序ウィンドウ（並べ替えウィンドウ）を「０」に設定
この解決策は、ＭＢＭＳ送信と同じである。Ｄ２Ｄ通信では、再送信スキームがまだ合意されていない。従って、「ゼロサイズ」再順序ウィンドウが、Ｄ２Ｄ通信に関する現在の合意に基づいて役に立つかもしれない。しかしながら、Ｄ２Ｄ通信送信のための繰り返しスキームは、まだ検討下にあり、そのような繰り返しスキームは、下位層から順序がバラバラのＵＭＤ ＰＤＵが配信される可能性がある。この代替策の必要性は、繰り返しスキームが合意に達するか否かに基づく。

上記代替案の長所と短所を考慮して、有効中タイマが満了した後にＵＥ１００（Ｄ２Ｄ ＵＥ）が送信ＲＬＣエンティティを解放すべきことを仮定する（代替案１）。さらに、受信ＲＬＣエンティティは、対応する送信ＲＬＣエンティティとそのような有効中タイマを共有し、ＵＭＤ ＰＤＵ破棄の発生を防ぐための参照として、有効中タイマを使用すべきである。

・提案４：送信ＲＬＣエンティティは、ＵＭＤ ＰＤＵ破棄の発生を防ぐために、有効中タイマが満了した後、解放されるべきである。

・提案５：受信ＲＬＣエンティティは、対応する送信ＲＬＣエンティティとそのような有効中タイマを共有し、ＵＭＤ ＰＤＵ破棄の発生を防ぐための参照として、有効中タイマを使用すべきである。

（３）結論
送信及び受信ＰＤＣＰ／ＲＬＣエンティティの潜在的な不一致について説明した。不必要なＵＭＤ ＰＤＵ破棄を防ぐために、送信及び受信ＲＬＣエンティティの両方で使用される有効中タイマを仕様化することの利点について検討した。

［付記２］
以下に、実施形態の補足事項について付記する。

（１）ＰＤＣＰ／ＲＬＣパラメータ設定
（１．１）課題
セルラ通信では、データベアラで用いられるＰＤＣＰ及びＲＬＣエンティティは、ＵＥ１００が、セルから送信されるＲＲＣシグナリングを受信した際に、生成（確立）される。ＰＤＣＰ及びＲＬＣエンティティが生成する時に使用されるＰＤＣＰパラメータ及びＲＬＣパラメータは、当該ＲＲＣシグナリングによって設定される。

一方、Ｄ２Ｄ通信において、ＰＤＣＰパラメータ及びＲＬＣパラメータを設定する方法は、まだ規定されていない。上述の［付記１］で説明したように、受信ＵＥ１００（受信Ｄ２Ｄ ＵＥ）と送信ＵＥ１００（送信Ｄ２Ｄ ＵＥ）とで、同一のパラメータ値を使用する必要がある。

そこで、以下において、Ｄ２Ｄ通信のために用いられるＰＤＣＰパラメータ及びＲＬＣパラメータを設定する技術を提供することを目的とする。なお、ＰＤＣＰパラメータ及びＲＬＣパラメータの一方のパラメータを設定するために、以下の方法が用いられてもよいことは勿論である。他方のパラメータは、一方のパラメータと別の方法により設定されてもよい。

（１．２）解決方法
第１の方法では、ＳＡ（受信）リソースプール毎に、Ｄ２Ｄベアラ用のＲＬＣ及びＰＤＣＰ設定を規定する。

Ｄ２Ｄベアラ用のＲＬＣ及びＰＤＣＰ設定は、ＵＥ１００（Ｄ２Ｄ ＵＥ）が予め記憶していてもよい（事前設定（Ｐｒｅ−ｃｏｎｆｉｇｕｒｅｄ））。Ｄ２Ｄベアラ用のＲＬＣ及びＰＤＣＰ設定は、ブロードキャストによってｅＮＢ２００からＵＥ１００に通知されてもよい。

送信ＵＥ１００は、ＳＡの送信に用いられるＳＡリソースプールに対応する設定（Ｄ２Ｄベアラ用のＲＬＣ及びＰＤＣＰ設定）を用いて、ＲＬＣ及びＰＤＣＰエンティティの確立を行う。

受信ＵＥ１００は、送信ＵＥ１００から送信されるＳＡの受信に用いられたＳＡリソースプールに対応する設定を用いて、ＲＬＣ及びＰＤＣＰエンティティの確立を行う。

部分的カバレッジでは、カバレッジ内のＵＥ１００と、カバレッジ外のＵＥ１００とが同一のＰＤＣＰパラメータ及びＲＬＣパラメータを利用できる必要がある。このため、カバレッジ内で用いられるＳＡリソースプールと、カバレッジ外で用いられるＳＡリソースプールとの少なくとも一部が一致する。（少なくとも一致部分では、）ＰＤＣＰパラメータ及びＲＬＣパラメータ（すなわち、Ｄ２Ｄベアラ用のＲＬＣ及びＰＤＣＰ設定）が同一である。

サービングセルは、セル端に位置するＵＥ１００（Ｄ２Ｄ ＵＥ）に、上記のＳＡリソースプール（一致部分のＳＡリソースプール）で送信を行うように通知してもよい。

第２の方法では、送信ＵＥ１００は、データのＭＡＣサブヘッダにＰＤＣＰ及びＲＬＣ設定を含めて、当該データを送信する。受信ＵＥ１００は、受信したデータ（ＭＡＣ ＰＤＵ）に含まれる設定を用いて、ＰＤＣＰ及びＲＬＣエンティティを確立する。

第３の方法では、送信ＵＥは、ＳＡにＰＤＣＰ及びＲＬＣ設定を含めて、当該ＳＡを送信する。受信ＵＥ１００は、受信したＳＡに含まれる設定を用いて、ＰＤＣＰ及びＲＬＣエンティティを確立する。

（２）ＰＤＣＰパラメータ設定
（２．１）課題
セルラ通信で利用されているＰＤＣＰエンティティでの暗号化（ｃｉｐｈｅｒｉｎｇ）及びヘッダ圧縮（ＲｏＨＣ、Ｈｅａｄｅｒ ｃｏｍｐｒｅｓｓｉｏｎ／ｄｅ−ｃｏｍｐｒｅｓｓｉｏｎ）を、Ｄ２Ｄ通信で利用した場合、送信ＵＥ１００と受信ＵＥ１００との間でのＰＤＣＰエンティティ内のパラメータが不一致であることにより、受信ＵＥ１００が、ＰＤＣＰ ＰＤＣの暗号化解除及び／又は圧縮解除に失敗し、ＰＤＣＰ ＰＤＵを破棄する可能性がある。この理由は、当該パラメータ（ＨＦＮ（Ｈｙｐｅｒ Ｆｒａｍｅ Ｎｕｍｂｅｒ）、ＣＩＤ（Ｃｏｎｔｅｘｔ Ｉｄｅｎｔｉｆｉｅｒ））が、送信ＰＤＣＰエンティティと受信ＰＤＣＰエンティティとの生成タイミングが同一であることを前提に運用されるためである。

（２．２）解決策
第１の方法では、受信ＵＥ１００は、固定された値（すなわち、変更されない）値をパラメータとして用いて、データの解読及びデータの圧縮解除の少なくとも一方を行う。

例えば、ＨＦＮとして固定された値（例えば、０）を使用する。これにより、送信ＵＥ１００がＤ２Ｄ通信をすでに行っている場合に、受信ＵＥ１００が、Ｄ２Ｄ通信に途中から参加（受信の開始）したとしても、ＨＦＮのズレが発生しない。従って、ＰＤＣＰ ＰＤＵの処理において、受信ＵＥ１００がＨＦＮのズレによるＰＤＵを破棄することを抑制できる。

なお、送信ＵＥ１００が、データの暗号化及びデータの圧縮の少なくとも一方の処理に用いられるパラメータを固定することができる。

第２の方法では、Ｄ２Ｄ通信では、ＣＩＤを用いたＲｏＨＣを実施しない。送信ＵＥ１００が、変化しないヘッダを省略して、その代わりにＣＩＤをデータに付与し、当該データ（ＰＤＣＰ ＰＤＵ）を送信していた場合、Ｄ２Ｄ通信に途中から参加（受信の開始）した受信ＵＥ１００は、ＣＩＤが分からない。従って、ＣＩＤを用いたＲｏＨＣを実施しない（すなわち、変化しないヘッダを省略しない）ことにより、受信ＵＥ１００が、Ｄ２Ｄ通信に途中から参加しても、データを圧縮解除できる。

従って、第２の方法では、送信ＵＥ１００は、送信ＰＤＣＰエンティティにおいて、データフローを示すヘッダ情報が変化しない場合に、ヘッダ情報の代わりにデータフローを特定するＣＩＤをデータに付与する圧縮処理を実行するという前提下で、送信ＰＤＣＰエンティティがＤ２Ｄ通信のために用いられるエンティティである場合には、圧縮処理を中止する（実行しない）。

なお、送信ＵＥ１００は、ヘッダ情報の代わりにデータフローを特定し、かつ、Ｄ２Ｄ通信に用いられるＳＡリソースプールに対応付けられる所定の識別子をデータに付与する圧縮処理を実行してもよい。

第３の方法では、上述の第１の方法を実施するために、Ｄ２Ｄ通信用にセルラ通信よりもビット数が少ないパラメータ（例えば、ｍａｘＣＩＤ）を使用する。

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

以上のように、本実施形態に係るユーザ端末及び移動通信システムによれば、Ｄ２Ｄ通信を適切に制御できるため、移動通信分野において有用である。

Claims (3)

1. ユーザ端末であって、
   直接的な端末間通信であるＤ２Ｄ通信によってデータを受信するために確立された受信ＲＬＣエンティティにおいて、ウィンドウを前進させることなく受信できるデータのシーケンス番号を規定するために前記受信ＲＬＣエンティティにおいて使用されるウィンドウサイズに基づく所定条件下で、所定のシーケンス番号のデータを破棄する制御を行う制御部を備え、
   前記制御部は、前記Ｄ２Ｄ通信によって送信されるデータの許容遅延が閾値以上である場合に、前記ウィンドウサイズを０に設定し、
   前記制御部は、前記許容遅延が閾値未満である場合に、前記ウィンドウサイズを０に設定しないことを特徴とするユーザ端末。
2. 前記制御部は、前記Ｄ２Ｄ通信よって送信されるデータの宛先に応じて、前記ウィンドウサイズを０に設定することを特徴とする請求項１に記載のユーザ端末。
3. 前記制御部は、前記Ｄ２Ｄ通信における送信方法に応じて、前記ウィンドウサイズを０に設定することを特徴とする請求項１に記載のユーザ端末。

Images