JP6718103B2 - 通信方法 - Google Patents

Description

本開示は、通信方法に関する。

移動通信システムの標準化プロジェクトである３ＧＰＰ（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ）において、近傍サービス（ＰｒｏＳｅ：Ｐｒｏｘｉｍｉｔｙ−ｂａｓｅｄ Ｓｅｒｖｉｃｅｓ）の仕様策定が進められている（非特許文献１参照）。

ＰｒｏＳｅでは、特定の無線端末（ＰｒｏＳｅ ＵＥ−ｔｏ−Ｎｅｔｗｏｒｋ Ｒｅｌａｙ）は、他の無線端末（Ｒｅｍｏｔｅ ＵＥ）とネットワークとの間でトラフィックを中継することが可能である。

３ＧＰＰ技術仕様書「ＴＳ３６．３００ Ｖ１３．５．０」 ２０１６年９月２９日

一の実施形態に係る通信方法は、第１の無線端末が、レイヤ２のうちＲａｄｉｏ Ｌｉｎｋ Ｃｏｎｔｒｏｌ（ＲＬＣ）レイヤよりも上位レイヤにおいて第２の無線端末と基地局との間で前記第２の無線端末のパケットが伝送されるレイヤ２中継を実行する通信方法である。前記第１の無線端末が、前記第１の無線端末が前記レイヤ２中継を可能であること示す情報を送信する。前記第２の無線端末が、前記情報の受信に応じて、前記レイヤ２中継のための要求を前記第１の無線端末へ送信する。

一の実施形態では、第１の無線端末が、レイヤ２のうちＲａｄｉｏ Ｌｉｎｋ Ｃｏｎｔｒｏｌ（ＲＬＣ）レイヤよりも上位レイヤにおいて第２の無線端末と基地局との間で前記第２の無線端末のパケットが伝送されるレイヤ２中継を実行する通信方法である。前記基地局が、前記第１の無線端末及び前記第２の無線端末へ、優先度に対応付けられた複数の論理チャネル識別子を通知する。前記複数の論理チャネル識別子は、前記第１の無線端末と前記第２の無線端末との間で前記パケットを伝送するために用いられる。前記第２の無線端末が、前記パケットを前記第１の無線端末へ送信するために、前記複数の論理チャネル識別子の中から、前記パケットの優先度に対応する論理チャネル識別子を選択する。

一の実施形態では、第１の無線端末が、レイヤ２のうちＲａｄｉｏ Ｌｉｎｋ Ｃｏｎｔｒｏｌ（ＲＬＣ）レイヤよりも上位レイヤにおいて第２の無線端末と基地局との間で前記第２の無線端末のパケットが伝送されるレイヤ２中継を実行する通信方法である。前記基地局が、前記第１の無線端末及び前記第２の無線端末へ、優先度に対応付けられた複数の識別情報を通知する。前記第２の無線端末が、前記複数の識別情報の中から、前記パケットの優先度に対応する識別情報を選択する。前記第２の無線端末が、前記パケットを前記第１の無線端末へ送信するために、前記選択された識別情報を含むヘッダが付与された前記パケットを生成する。

一の実施形態では、第１の無線端末が、レイヤ２のうちＲａｄｉｏ Ｌｉｎｋ Ｃｏｎｔｒｏｌ（ＲＬＣ）レイヤよりも上位レイヤにおいて第２の無線端末と基地局との間で前記第２の無線端末のパケットが伝送されるレイヤ２中継を実行する通信方法である。前記基地局が、前記第２の無線端末のパケット専用の論理チャネル識別子を決定する。前記論理チャネル識別子は、前記第１の無線端末と前記基地局との間で前記パケットを伝送するために用いられる。

一の実施形態では、第１の無線端末が、レイヤ２のうちＲａｄｉｏ Ｌｉｎｋ Ｃｏｎｔｒｏｌ（ＲＬＣ）レイヤよりも上位レイヤにおいて第２の無線端末と基地局との間で前記第２の無線端末のパケットが伝送されるレイヤ２中継を実行する通信方法である。前記基地局が、前記第２の無線端末へ割り当てたＲａｄｉｏ Ｎｅｔｗｏｒｋ Ｔｅｍｐｏｒａｒｙ Ｉｄｅｎｔｉｆｉｅｒ（ＲＮＴＩ）を前記第１の無線端末へ通知する。前記第１の無線端末は、前記基地局から受信したパケットのうち、前記ＲＮＴＩを用いてデコードに成功したパケットを前記第２の無線端末のパケットと判定する。

図１は、ＬＴＥシステムの構成を示す図である。 図２は、ＬＴＥシステムにおける無線インターフェイスのプロトコルスタック図である。 図３は、ＬＴＥシステムで使用される無線フレームの構成図である。 図４は、レイヤ２中継の一例を説明するための図である。 図５は、レイヤ２中継の一例を説明するための図である。 図６は、ＵＥ１００のブロック図である。 図７は、ｅＮＢ２００のブロック図である。 図８は、動作例１を説明するためのシーケンス図である。 図９は、動作例２を説明するためのシーケンス図である。 図１０は、動作例３を説明するためのフローチャートである。 図１１は、動作例３を説明するための図である。 図１２は、動作例３を説明するためのフローチャートである。 図１３は、動作例４を説明するためのフローチャートである。 図１４は、動作例５を説明するための図である。 図１５は、動作例５を説明するためのシーケンス図である。 図１６は、動作例６を説明するためのシーケンス図である。 図１７は、動作例６を説明するための図である。 図１８は、動作例６を説明するための図である。 図１９は、動作例７を説明するための図である。 図２０は、動作例７を説明するためのフローチャートである。 図２１は、動作例７を説明するための図である。 図２２は、動作例７を説明するための図である。 図２３は、動作例８を説明するためのフローチャートである。 図２４は、動作例９を説明するためのフローチャートである。 図２５は、短距離インターフェイスにおけるＱｏＳ識別の問題を説明するための図である。 図２６は、ＵｕインターフェイスにおけるリモートＵＥ識別の問題を説明するための図である。

［実施形態の概要］
近年、レイヤ２中継について議論されている。レイヤ２中継では、レイヤ２のうちＲａｄｉｏ Ｌｉｎｋ Ｃｏｎｔｒｏｌ（ＲＬＣ）レイヤよりも上位レイヤにおいて、無線端末（Ｒｅｍｏｔｅ ＵＥ）のパケットが、特定の無線端末（ＰｒｏＳｅ ＵＥ−ｔｏ−Ｎｅｔｗｏｒｋ Ｒｅｌａｙ）を介して、無線端末（Ｒｅｍｏｔｅ ＵＥ）と基地局（ネットワーク）との間で伝送（中継）される。

しかしながら、レイヤ２中継を適切に制御するための仕組みが存在しないため、レイヤ２中継が適切に実行されない可能性がある。

一の実施形態に係る通信方法は、第１の無線端末が、レイヤ２のうちＲａｄｉｏ Ｌｉｎｋ Ｃｏｎｔｒｏｌ（ＲＬＣ）レイヤよりも上位レイヤにおいて第２の無線端末と基地局との間で前記第２の無線端末のパケットが伝送されるレイヤ２中継を実行する通信方法である。前記第１の無線端末が、前記第１の無線端末が前記レイヤ２中継を可能であること示す情報を送信する。前記第２の無線端末が、前記情報の受信に応じて、前記レイヤ２中継のための要求を前記第１の無線端末へ送信する。

前記レイヤ２中継では、前記ＲＬＣレイヤよりも上位レイヤであり、かつ、Ｐａｃｋｅｔ Ｄａｔａ Ｃｏｎｖｅｒｇｅｎｃｅ Ｐｒｏｔｏｃｏｌ（ＰＤＣＰ）レイヤと異なる特別なレイヤにおいて前記パケットの処理が実行されてもよい。前記基地局及び前記第２の無線端末は、前記特別なレイヤよりも下位レイヤにおいて、前記特別なレイヤで前記パケットが処理されたことを示す情報を前記パケットに含めてもよい。

前記レイヤ２中継では、前記ＲＬＣレイヤよりも上位レイヤであり、かつ、Ｐａｃｋｅｔ Ｄａｔａ Ｃｏｎｖｅｒｇｅｎｃｅ Ｐｒｏｔｏｃｏｌ（ＰＤＣＰ）レイヤと異なる特別なレイヤにおいて前記パケットの処理が実行されてもよい。前記基地局が、前記特別なレイヤを介したパケットの伝送が許可される論理チャネル識別子を前記第１の無線端末へ通知してもよい。

一の実施形態では、第１の無線端末が、レイヤ２のうちＲａｄｉｏ Ｌｉｎｋ Ｃｏｎｔｒｏｌ（ＲＬＣ）レイヤよりも上位レイヤにおいて第２の無線端末と基地局との間で前記第２の無線端末のパケットが伝送されるレイヤ２中継を実行する通信方法である。前記基地局が、前記第１の無線端末及び前記第２の無線端末へ、優先度に対応付けられた複数の論理チャネル識別子を通知する。前記複数の論理チャネル識別子は、前記第１の無線端末と前記第２の無線端末との間で前記パケットを伝送するために用いられる。前記第２の無線端末が、前記パケットを前記第１の無線端末へ送信するために、前記複数の論理チャネル識別子の中から、前記パケットの優先度に対応する論理チャネル識別子を選択する。

一の実施形態では、第１の無線端末が、レイヤ２のうちＲａｄｉｏ Ｌｉｎｋ Ｃｏｎｔｒｏｌ（ＲＬＣ）レイヤよりも上位レイヤにおいて第２の無線端末と基地局との間で前記第２の無線端末のパケットが伝送されるレイヤ２中継を実行する通信方法である。前記基地局が、前記第１の無線端末及び前記第２の無線端末へ、優先度に対応付けられた複数の識別情報を通知する。前記第２の無線端末が、前記複数の識別情報の中から、前記パケットの優先度に対応する識別情報を選択する。前記第２の無線端末が、前記パケットを前記第１の無線端末へ送信するために、前記選択された識別情報を含むヘッダが付与された前記パケットを生成する。

前記選択された識別情報は、前記第１の無線端末とネットワークとの間に確立されるベアラの識別子であってもよい。

前記選択された識別情報は、前記第１の無線端末と前記基地局との間で前記パケットを伝送するために用いられる論理チャネル識別子であってもよい。

前記ヘッダは、前記第２の無線端末の識別子をさらに含んでもよい。

一の実施形態では、第１の無線端末が、レイヤ２のうちＲａｄｉｏ Ｌｉｎｋ Ｃｏｎｔｒｏｌ（ＲＬＣ）レイヤよりも上位レイヤにおいて第２の無線端末と基地局との間で前記第２の無線端末のパケットが伝送されるレイヤ２中継を実行する通信方法である。前記基地局が、前記第２の無線端末のパケット専用の論理チャネル識別子を決定する。前記論理チャネル識別子は、前記第１の無線端末と前記基地局との間で前記パケットを伝送するために用いられる。

一の実施形態では、第１の無線端末が、レイヤ２のうちＲａｄｉｏ Ｌｉｎｋ Ｃｏｎｔｒｏｌ（ＲＬＣ）レイヤよりも上位レイヤにおいて第２の無線端末と基地局との間で前記第２の無線端末のパケットが伝送されるレイヤ２中継を実行する通信方法である。前記基地局が、前記第２の無線端末へ割り当てたＲａｄｉｏ Ｎｅｔｗｏｒｋ Ｔｅｍｐｏｒａｒｙ Ｉｄｅｎｔｉｆｉｅｒ（ＲＮＴＩ）を前記第１の無線端末へ通知する。前記第１の無線端末は、前記基地局から受信したパケットのうち、前記ＲＮＴＩを用いてデコードに成功したパケットを前記第２の無線端末のパケットと判定する。

前記第２の基地局は、前記第１の無線端末から受信したパケットのうち、前記ＲＮＴＩを用いてデコードに成功したパケットを前記第２の無線端末のパケットと判定してもよい。

［実施形態］
（移動通信システム）
以下において、実施形態に係る移動通信システムであるＬＴＥシステムについて説明する。図１は、ＬＴＥシステムの構成を示す図である。

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

ＵＥ１００は、通信装置（無線端末）に相当する。ＵＥ１００は、移動型の通信装置である。ＵＥ１００は、セル（後述するｅＮＢ２００）と無線通信を行う。ＵＥ１００の構成については後述する。

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

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

ＥＰＣ２０は、コアネットワークに相当する。ＥＰＣ２０は、Ｅ−ＵＴＲＡＮ１０と共にネットワークを構成してもよい。ＥＰＣ２０は、ＭＭＥ（Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ）３００、及びＳＧＷ（Ｓｅｒｖｉｎｇ Ｇａｔｅｗａｙ）４００、及びＰＧＷ（Ｐａｃｋｅｔ ｄａｔａ Ｎｅｔｗｏｒｋ Ｇａｔｅｗａｙ）５００を含む。

ＭＭＥ３００は、例えば、ＵＥ１００に対する各種モビリティ制御を行う。ＳＧＷ４００は、例えば、データの転送制御を行う。ＭＭＥ３００及びＳＧＷ４００は、Ｓ１インターフェイスを介してｅＮＢ２００と接続される。ＰＧＷ５００は、外部ネットワークから（及び外部ネットワークに）ユーザデータを中継する制御を行う。

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

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

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

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

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

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

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

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

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

下りリンクにおいて、各サブフレームの先頭数シンボルの区間は、下りリンク制御信号を伝送するための物理下りリンク制御チャネル（ＰＤＣＣＨ：Ｐｈｙｓｉｃａｌ Ｄｏｗｎｌｉｎｋ． Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）として使用可能な領域である。各サブフレームの残りの部分は、下りリンクデータを伝送するための物理下りリンク共有チャネル（ＰＤＳＣＨ：Ｐｈｙｓｉｃａｌ Ｄｏｗｎｌｉｎｋ Ｓｈａｒｅｄ Ｃｈａｎｎｅｌ）として使用可能な領域である。

上りリンクにおいて、各サブフレームにおける周波数方向の両端部は、上りリンク制御信号を伝送するための物理上りリンク制御チャネル（ＰＵＣＣＨ：Ｐｈｙｓｉｃａｌ Ｕｐｌｉｎｋ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）として使用可能な領域である。各サブフレームにおける残りの部分は、上りリンクデータを伝送するための物理上りリンク共有チャネル（ＰＵＳＣＨ：Ｐｈｙｓｉｃａｌ Ｕｐｌｉｎｋ Ｓｈａｒｅｄ Ｃｈａｎｎｅｌ）として使用可能な領域である。

（近傍サービス）
近傍サービス（ＰｒｏＳｅ：Ｐｒｏｘｉｍｉｔｙ−ｂａｓｅｄ Ｓｅｒｖｉｃｅｓ）について説明する。近傍サービスは、互いに近傍にある通信装置（例えば、ＵＥ１００）に基づいて３ＧＰＰシステムにより提供され得るサービスである。

ＰｒｏＳｅでは、ｅＮＢ２００を経由せずにノード間（例えば、ＵＥ間）で直接的な無線リンクを介して各種の無線信号が送受信される。ＰｒｏＳｅにおける直接的な無線リンクは、「サイドリンク（Ｓｉｄｅｌｉｎｋ）」と称される。

サイドリンクは、サイドリンク通信及びサイドリンクディスカバリのためのインターフェイス（例えば、ＵＥとＵＥとの間のインターフェイス）であってもよい。サイドリンク通信は、ＰｒｏＳｅ直接通信（以下、「直接通信」と適宜称する）を可能にする機能（ＡＳ ｆｕｎｃｔｉｏｎａｌｉｔｙ）である。サイドリンクディスカバリは、ＰｒｏＳｅ直接ディスカバリ（以下、「直接ディスカバリ」と適宜称する）を可能にする機能（ＡＳ ｆｕｎｃｔｉｏｎａｌｉｔｙ）である。

サイドリンクは、ＰＣ５インターフェイス（ＰＣ５接続）に対応する。ＰＣ５は、ＰｒｏＳｅ直接ディスカバリ、ＰｒｏＳｅ直接通信及びＰｒｏＳｅ ＵＥ−ｔｏ−ネットワーク中継のための制御プレーン及びユーザプレーンのために用いられるＰｒｏＳｅ使用可能なＵＥ（ＰｒｏＳｅ−ｅｎａｂｌｅｄ ＵＥ）間の参照ポイントである。

ＰｒｏＳｅは、「直接ディスカバリ（Ｄｉｒｅｃｔ Ｄｉｓｃｏｖｅｒｙ）」及び「直接通信（Ｄｉｒｅｃｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）」及び「Ｒｅｌａｙ」のモードが規定されている。「Ｒｅｌａｙ」は後述する。

直接ディスカバリは、特定の宛先を指定しないディスカバリメッセージ（ディスカバリ信号）をＵＥ間で直接的に伝送することにより、相手先を探索するモードである。直接ディスカバリは、ＰＣ５を介してＥ−ＵＴＲＡ（Ｅｖｏｌｖｅｄ Ｕｎｉｖｅｒｓａｌ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ）における直接無線信号を用いて、ＵＥの近傍における他のＵＥを発見するための手順である。或いは、直接ディスカバリは、Ｅ−ＵＴＲＡ技術で２つのＵＥ１００の能力のみを用いて、近傍サービスを実行可能な他のＵＥ１００を発見するために近傍サービスを実行可能なＵＥ１００によって採用される手順である。直接ディスカバリは、ＵＥ１００がＥ−ＵＴＲＡＮ（ｅＮＢ２００（セル））によってサービスが提供される場合にのみ、サポートされる。ＵＥ１００は、セル（ｅＮＢ２００）に接続又はセルに在圏している場合、Ｅ−ＵＴＲＡＮによってサービスが提供され得る。

ディスカバリメッセージ（ディスカバリ信号）の送信（アナウンスメント）のためのリソース割り当てタイプには、「タイプ１」と「タイプ２（タイプ２Ｂ）」とがある。「タイプ１」では、ＵＥ１００が無線リソースを選択する。「タイプ２」では、ｅＮＢ２００が無線リソースを割り当てる。タイプ１では、ＵＥ１００は、ｅＮＢ２００から提供されたリソースプールの中から無線リソースを選択してもよい。

「Ｓｉｄｅｌｉｎｋ Ｄｉｒｅｃｔ Ｄｉｓｃｏｖｅｒｙ」プロトコルスタックは、物理（ＰＨＹ）レイヤ、ＭＡＣレイヤ、及びＰｒｏＳｅプロトコルを含む。ＵＥ（Ａ）の物理レイヤとＵＥ（Ｂ）の物理レイヤとの間では、物理サイドリンクディスカバリチャネル（ＰＳＤＣＨ）と称される物理チャネルを介してディスカバリ信号が伝送される。ＵＥ（Ａ）のＭＡＣレイヤとＵＥ（Ｂ）のＭＡＣレイヤとの間では、サイドリンクディスカバリチャネル（ＳＬ−ＤＣＨ）と称されるトランスポートチャネルを介してディスカバリ信号が伝送される。

直接通信は、特定の宛先（宛先グループ）を指定してデータをＵＥ間で直接的に伝送するモードである。直接通信は、いずれのネットワークノードを通過しない経路を介してＥ−ＵＴＲＡ技術を用いたユーザプレーン伝送による、近傍サービスを実行可能である２以上のＵＥ間の通信である。

直接通信のリソース割り当てタイプには、「モード１」と「モード２」とがある。「モード１」では、直接通信の無線リソースをｅＮＢ２００が指定する。「モード２」では、直接通信の無線リソースをＵＥ１００が選択する。モード２では、ＵＥ１００は、ｅＮＢ２００から提供されたリソースプールの中から無線リソースを選択してもよい。

直接通信プロトコルスタックは、物理（ＰＨＹ）レイヤ、ＭＡＣレイヤ、ＲＬＣレイヤ、及びＰＤＣＰレイヤを含む。ＵＥ（Ａ）の物理レイヤとＵＥ（Ｂ）の物理レイヤとの間では、物理サイドリンク制御チャネル（ＰＳＣＣＨ）を介して制御信号が伝送され、物理サイドリンク共有チャネル（ＰＳＳＣＨ）を介してデータが伝送される。物理サイドリンクブロードキャストチャネル（ＰＳＢＣＨ）を介して同期信号等が伝送されてもよい。ＵＥ（Ａ）のＭＡＣレイヤとＵＥ（Ｂ）のＭＡＣレイヤとの間では、サイドリンク共有チャネル（ＳＬ−ＳＣＨ）と称されるトランスポートチャネルを介してデータが伝送される。ＵＥ（Ａ）のＲＬＣレイヤとＵＥ（Ｂ）のＲＬＣレイヤとの間では、サイドリンクトラフィックチャネル（ＳＴＣＨ）と称される論理チャネルを介してデータが伝送される。

（レイヤ２中継（Ｌａｙｅｒ ２ Ｒｅｌａｙ））
レイヤ２中継の概要について、図４及び図５を用いて説明する。図４は、レイヤ２中継の一例を説明するための図である。図５は、レイヤ２中継の一例を説明するための図である。

図４に示すように、レイヤ２中継において、ＵＥ１００−１は、中継端末（リレーＵＥ）である。ＵＥ１００−１は、ＵＥ１００−２とｅＮＢ２００（ネットワーク）との間で、ＵＥ１００−２のパケットを伝送（中継／転送）する。レイヤ２中継では、レイヤ２のうちＲＬＣレイヤよりも上位レイヤにおいてＵＥ１００（ＵＥ１００−２）のパケットが伝送（中継）される。レイヤ２中継では、レイヤ２のうち、ＰＤＣＰレイヤにおいてパケットの処理が実行されずに、ＵＥ１００（ＵＥ１００−２）のパケットが伝送されてもよい。

ＵＥ１００−１は、ＰｒｏＳｅ ＵＥ−ｔｏ−Ｎｅｔｗｏｒｋ Ｒｅｌａｙであってもよい。ＰｒｏＳｅ ＵＥ−ｔｏ−Ｎｅｔｗｏｒｋ Ｒｅｌａｙは、リモートＵＥ（Ｒｅｍｏｔｅ ＵＥ）のためにネットワークへの接続性（ｃｏｎｎｅｃｔｉｖｉｔｙ）をサポートする機能を提供するＵＥであってもよい。

ＵＥ１００−２は、Ｒｅｍｏｔｅ ＵＥであってもよい。Ｒｅｍｏｔｅ ＵＥは、ＰｒｏＳｅ ＵＥ−ｔｏ−Ｎｅｔｗｏｒｋ Ｒｅｌａｙを介したＰＤＮ（Ｐａｃｋｅｔ Ｄａｔａ Ｎｅｔｗｏｒｋ）と通信するＵＥであってもよい。Ｒｅｍｏｔｅ ＵＥは、ＰｒｏＳｅ−ｅｎａｂｌｅｄ Ｐｕｂｌｉｃ Ｓａｆｅｔｙ ＵＥであってもよい。ＰｒｏＳｅ−ｅｎａｂｌｅｄ Ｐｕｂｌｉｃ Ｓａｆｅｔｙ ＵＥは、ＨＰＬＭＮ（Ｈｏｍｅ Ｐｕｂｌｉｃ Ｌａｎｄ Ｍｏｂｉｌｅ Ｎｅｔｗｏｒｋ）が公衆安全用途（Ｐｕｂｌｉｃ Ｓａｆｅｔｙ ｕｓｅ）のために許可するように構成されたＵＥであってもよい。ＰｒｏＳｅ−ｅｎａｂｌｅｄ Ｐｕｂｌｉｃ Ｓａｆｅｔｙ ＵＥは、ＰｒｏＳｅ可能（ＰｒｏＳｅ−ｅｎａｂｌｅｄ）であってもよい。ＰｒｏＳｅ−ｅｎａｂｌｅｄ Ｐｕｂｌｉｃ Ｓａｆｅｔｙ ＵＥは、ＰｒｏＳｅ手順及び公衆安全に固有の能力をサポートしてもよい。ＰｒｏＳｅ−ｅｎａｂｌｅｄ Ｐｕｂｌｉｃ Ｓａｆｅｔｙ ＵＥは、特別なアクセスクラスの一つと共にＵＳＩＭ（Ｕｎｉｖｅｒｓａｌ Ｓｕｂｓｃｒｉｂｅｒ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ Ｍｏｄｕｌｅ）を有していてもよい。

ＵＥ１００−１とＵＥ１００−２との間には、３ＧＰＰ（Ｔｈｉｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ）アクセス技術により接続が確立されてもよい。例えば、ＵＥ１００−１とＵＥ１００−２との間では、ＰＣ５インターフェイス（ＰＣ５接続）を介してユーザデータ（パケット）及び／又は制御情報が伝送される。

ＵＥ１００−１とＵＥ１００−２との間には、非３ＧＰＰ（Ｎｏｎ−３ＧＰＰ）アクセス技術により接続が確立されてもよい。例えば、ＵＥ１００−１とＵＥ１００−２との間では、ＷＬＡ（Ｗｉｒｅｌｅｓｓ Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）を介してユーザデータ（パケット）及び／又は制御情報が伝送される。

ＵＥ１００−１とｅＮＢ２００との間には、３ＧＰＰ（Ｔｈｉｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ）アクセス技術により接続が確立されてもよい。例えば、ＵＥ１００−１とｅＮＢ２００との間では、Ｕｕインターフェイス（又はＵｎインターフェイス）を介してユーザデータ（パケット）及び／又は制御情報が伝送される。

レイヤ２中継において、ＵＥ１００−１は、物理レイヤ、ＭＡＣレイヤ、及びＲＬＣレイヤを確立してもよい。ＵＥ１００−２は、物理レイヤ、ＭＡＣレイヤ、ＲＬＣレイヤ、ＰＤＣＰレイヤを確立してもよい。ｅＮＢ２００は、物理レイヤ、ＭＡＣレイヤ、ＲＬＣレイヤ、ＰＤＣＰレイヤを確立してもよい。ＵＥ１００−２のＰＤＣＰレイヤとｅＮＢ２００のＰＤＣＰレイヤとの間で、ＵＥ１００−１を介して、ＵＥ１００−２のパケットが伝送される。

図５に示すように、レイヤ２中継が実行される場合、特別なレイヤが確立されてもよい。特別なレイヤは、例えば、アダプテーションレイヤ（Ａｄａｐｔａｔｉｏｎ Ｌａｙｅｒ）である。アダプテーションレイヤは、レイヤ２において、ＲＬＣレイヤよりも上位のレイヤであってもよい。アダプテーションレイヤは、ＲＬＣレイヤの１つ上の上位レイヤであってもよい。アダプテーションレイヤは、ＰＤＣＰレイヤと異なるレイヤであってもよい。アダプテーションレイヤは、ＰＤＣＰレイヤよりも下位のレイヤであってもよい。アダプテーションレイヤは、ＰＤＣＰレイヤの１つ下の下位レイヤであってもよい。アダプテーションレイヤは、ＲＬＣレイヤとＰＤＣＰレイヤとの間に確立されてもよい。

ＵＥ１００−１のアダプテーションレイヤとＵＥ１００−２のアダプテーションレイヤとの間において、ユーザデータ及び／又は制御情報が伝送される。ＵＥ１００−１のアダプテーションレイヤとｅＮＢ２００のアダプテーションレイヤとの間において、ユーザデータ及び／又は制御情報が伝送される。

アダプテーションレイヤでは、ＵＥ１００−２のパケットの処理が実行される。例えば、アダプテーションレイヤでは、ＵＥ１００−２のパケットに新たなヘッダを付与する処理が実行されてもよい。アダプテーションレイヤでは、ＵＥ１００−２のパケットに付与された新たなヘッダの内容を理解するための処理が実行されてもよい（例えば、後述の動作例３参照）。

（無線端末）
実施形態に係るＵＥ１００（無線端末）について説明する。図６は、ＵＥ１００のブロック図である。図６に示すように、ＵＥ１００は、レシーバ（Ｒｅｃｅｉｖｅｒ：受信部）１１０、トランスミッタ（Ｔｒａｎｓｍｉｔｔｅｒ：送信部）１２０、及びコントローラ（Ｃｏｎｔｒｏｌｌｅｒ：制御部）１３０を備える。レシーバ１１０とトランスミッタ１２０とは、一体化されたトランシーバ（送受信部）であってもよい。

レシーバ１１０は、コントローラ１３０の制御下で各種の受信を行う。レシーバ１１０は、アンテナを含む。レシーバ１１０は、アンテナが受信する無線信号をベースバンド信号（受信信号）に変換する。レシーバ１１０は、ベースバンド信号をコントローラ１３０に出力する。

トランスミッタ１２０は、コントローラ１３０の制御下で各種の送信を行う。トランスミッタ１２０は、アンテナを含む。トランスミッタ１２０は、コントローラ１３０が出力するベースバンド信号（送信信号）を無線信号に変換する。トランスミッタ１３０は、無線信号をアンテナから送信する。

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

ＵＥ１００は、ＧＮＳＳ（Ｇｌｏｂａｌ Ｎａｖｉｇａｔｉｏｎ Ｓａｔｅｌｌｉｔｅ Ｓｙｓｔｅｍ）受信機を備えていてもよい。ＧＮＳＳ受信機は、ＵＥ１００の地理的な位置を示す位置情報を得るために、ＧＮＳＳ信号を受信できる。ＧＮＳＳ受信機は、ＧＮＳＳ信号をコントローラ１３０に出力する。ＵＥ１００は、ＵＥ１００の位置情報を取得するためのＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）機能を有していてもよい。

本明細書では、ＵＥ１００が備えるレシーバ１１０、トランスミッタ１２０及びコントローラ１３０の少なくともいずれかが実行する処理を、便宜上、ＵＥ１００が実行する処理（動作）として説明する。

（基地局）
実施形態に係るｅＮＢ２００（基地局）について説明する。図７は、ｅＮＢ２００のブロック図である。図７に示すように、ｅＮＢ２００は、レシーバ（受信部）２１０、トランスミッタ（送信部）２２０、コントローラ（制御部）２３０、及びネットワークインターフェイス２４０を備える。トランスミッタ２１０とレシーバ２２０は、一体化されたトランシーバ（送受信部）であってもよい。

レシーバ２１０は、コントローラ２３０の制御下で各種の受信を行う。レシーバ２１０は、アンテナを含む。レシーバ２１０は、アンテナが受信する無線信号をベースバンド信号（受信信号）に変換する。レシーバ２１０は、ベースバンド信号をコントローラ２３０に出力する。

トランスミッタ２２０は、コントローラ２３０の制御下で各種の送信を行う。トランスミッタ２２０は、アンテナを含む。トランスミッタ２２０は、コントローラ２３０が出力するベースバンド信号（送信信号）を無線信号に変換する。トランスミッタ２２０は、無線信号をアンテナから送信する。

コントローラ２３０は、ｅＮＢ２００における各種の制御を行う。コントローラ２３０は、プロセッサ及びメモリを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に使用される情報を記憶する。プロセッサは、ベースバンドプロセッサとＣＰＵとを含む。ベースバンドプロセッサは、例えば、ベースバンド信号の変調・復調及び符号化・復号化等を行う。ＣＰＵは、メモリに記憶されるプログラムを実行することにより各種の処理を行う。プロセッサは、後述する各種の処理及び上述した各種の通信プロトコルを実行する。

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

本明細書では、ｅＮＢ２００が備えるトランスミッタ２１０、レシーバ２２０、コントローラ２３０、及びネットワークインターフェイス２４０の少なくともいずれかが実行する処理を、便宜上、ｅＮＢ２００が実行する処理（動作）として説明する。

（実施形態に係る動作）
実施形態に係る動作について、動作例１−９を例に挙げて説明する。

（Ａ）動作例１
動作例１について、図８を用いて説明する。図８は、動作例１を説明するためのシーケンス図である。

動作例１では、レイヤ２中継を設定するための動作の一例について説明する。

ＵＥ１００−１は、レイヤ２中継が実行可能なＵＥである。ＵＥ１００−１は、ＰｒｏＳｅ ＵＥ−ｔｏ−Ｎｅｔｗｏｒｋ Ｒｅｌａｙであってもよい。ＵＥ１００−１は、ｅＮＢ２００のセルに在圏する。ＵＥ１００−１は、初期状態において、ｅＮＢ２００（セル）とＲＲＣ接続状態であってもよい。ＵＥ１００−１は、初期状態において、ｅＮＢ２００（セル）とＲＲＣアイドル状態であってもよい。

ＵＥ１００−２は、レイヤ２中継により、ＵＥ１００−１を介してネットワークとの通信を実行可能なＵＥである。ＵＥ１００−２は、リモートＵＥであってもよい。ＵＥ１００−２は、レイヤ２中継によりＵＥ１００−１を介してパケットをネットワーク（ｅＮＢ２００）から受け取ってもよい。ＵＥ１００−２は、レイヤ２中継によりＵＥ１００−１を介してパケットをネットワーク（ｅＮＢ２００）へ送ってもよい。

ＵＥ１００−２は、ｅＮＢ２００のセルに在圏してもよい。ＵＥ１００−２は、ｅＮＢ２００のセルに在圏しなくてもよい。ＵＥ１００−２は、セルの圏内（Ｉｎ Ｃｏｖｅｒａｇｅ）であってもよい。ＵＥ１００−２は、圏外（Ｏｕｔ−ｏｆ−ｃｏｖｅｒａｇｅ）であってもよい。

ＵＥ１００−２は、ウェアラブルＵＥ（ｗＵＥ）であってもよい。ウェアラブルＵＥは、例えば、ユーザが着用可能な通信装置である。ウェアラブルＵＥは、近距離用の装置であってもよい。ウェアラブルＵＥは、サイドリンク動作などの端末間での直接的な無線信号のやり取りが近距離（数ｍ（例えば、２ｍ）の範囲内）で実行されることが想定される通信装置であってもよい。

本明細書において、「近距離」は、通信可能な距離（例えば、数ｍの範囲）によって規定されてもよい。例えば、近距離な装置間（ＵＥ−ｗＵＥ間／ｗＵＥ−ｗＵＥ間）での無線信号（サイドリンク信号）の最大到達距離（最大到達範囲）は、通常のＵＥ間（ＵＥ−ＵＥ間）での無線信号（サイドリンク信号）の最大到達距離よりも短くてもよい。近距離な装置間での無線信号（サイドリンク信号）の最大到達距離は、ＵＥ−ｅＮＢ間の上りリンク信号の最大到達距離よりも短くてもよい。

「近距離」は、近距離な装置間での無線信号（サイドリンク信号）の（最大）送信電力（例えば、最大送信電力が０ｄＢｍ以下）によって規定されてもよい。例えば、近距離な装置間（ＵＥ−ｗＵＥ間／ｗＵＥ−ｗＵＥ間）での無線信号（サイドリンク信号）の最大送信電力は、通常のＵＥ間（ＵＥ−ＵＥ間）での無線信号（サイドリンク信号）の最大送信電力よりも小さくてもよい。近距離な装置間での無線信号（サイドリンク信号）の最大送信電力は、ＵＥ−ｅＮＢ間の上りリンク信号の最大送信電力よりも短くてもよい。

「近距離」は、ウェアラブルＵＥが利用可能なリソースプール（の条件／設定）により、規定されてもよい。

ウェアラブルＵＥは、既存のＵＥ１００と異なり、既存のＳＩＭ（Ｓｕｂｓｃｒｉｂｅｒ Ｉｄｅｎｔｉｔｙ Ｍｏｄｕｌｅ Ｃａｒｄ）の装着が不要であってもよい。ウェアラブルＵＥは、近距離用のＳＩＭ（Ｄ２Ｄ ＳＩＭ）が装着可能であってもよい。

図８に示すように、ステップＳ１０１において、ＵＥ１００−１は、ＵＥ１００−１がレイヤ２中継を可能であることを示す情報を送信してもよい。当該情報は、例えば、レイヤ２中継の能力を示す情報（Ｌ２ Ｒｅｌａｙ ｃａｐａｂｉｌｉｔｙ）であってもよい。

ＵＥ１００−１は、中継のための発見メッセージ（Ｒｅｌａｙ ｄｉｓｃｏｖｅｒｙ）に当該情報を含めてもよい。ＵＥ１００−１は、直接通信を要求するためのメッセージ（Ｄｉｒｅｃｔ ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔ）に当該情報を含めてもよい。

ステップＳ１０１は、省略されてもよい。例えば、ＵＥ１００−１とＵＥ１００−２とが非３ＧＰＰアクセス技術により、端末間通信が実行される／実行されている場合には、ＵＥ１００−１は、レイヤ２中継を可能であることを示す情報の送信を省略してもよい。

ステップＳ１０２において、ＵＥ１００−２は、レイヤ２中継のための要求である第１要求（Ｌ２ ｒｅｌａｙ Ｒｅｑｕｅｓｔ）をＵＥ１００−１へ送信する。ＵＥ１００−２は、当該要求を示す情報を含むメッセージをＵＥ１００−１へ送信してもよい。ＵＥ１００−２は、例えば、直接通信を要求するためのメッセージ（Ｄｉｒｅｃｔ Ｃｏｍｍ．Ｒｅｑｕｅｓｔ）にレイヤ２中継の要求を示す情報を含めてもよい。

ＵＥ１００−２は、ＵＥ１００−１がレイヤ２中継を可能であることを示す情報の受信に応じて、レイヤ２中継の要求を示す情報をＵＥ１００−１へ送信してもよい。これにより、ＵＥ１００−２は、レイヤ２中継が可能である場合にのみ、レイヤ２中継の要求を示す情報をＵＥ１００−１へ送信することができる。これにより、ＵＥ１００−２は、ＵＥ１００−１がレイヤ２中継をできないにもかかわらず、レイヤ２中継の要求を示す情報をＵＥ１００−１へ送信することを回避することができる。

ＵＥ１００−２は、ＵＥ１００−１がレイヤ２中継を可能であることを示す情報を受信しない場合であっても、レイヤ２中継の要求を示す情報をＵＥ１００−１へ送信してもよい。例えば、ＵＥ１００−２は、ＵＥ１００−１とＵＥ１００−２とが非３ＧＰＰアクセス技術により、端末間通信が実行される／実行されている場合には、レイヤ２中継の要求を示す情報をＵＥ１００−１へ送信してもよい。

ＵＥ１００−２は、ＰＣ５インターフェイスを介してレイヤ２中継の要求を示す情報をＵＥ１００−１へ送信してもよい。ＵＥ１００−２は、ＰＣ５プロトコルを用いて、レイヤ２中継の要求を示す情報をＵＥ１００−１へ送信してもよい。

ステップＳ１０３において、ＵＥ１００−１は、レイヤ２中継のための要求である第２要求（Ｌ２ ｒｅｌａｙ Ｒｅｑｕｅｓｔ）をｅＮＢ２００へ送信する。ＵＥ１００−１は、例えば、サイドリンクＵＥ情報（ＳＬ ＵＥ Ｉｎｆｏｒｍａｔｉｏｎ）にレイヤ２中継の要求を示す情報を含めてもよい。

ＵＥ１００−１は、例えば、各リモートＵＥ１００から第１要求を受ける度に、第２要求をｅＮＢ２００へ送信してもよい。

ＵＥ１００−１は、複数のリモートＵＥ１００のそれぞれから第１要求を受けた場合、１つのメッセージにより第２要求を送信してもよい。当該メッセージは、複数のリモートＵＥ１００のそれぞれの識別子を含んでいてもよい。

ＵＥ１００−１は、複数のリモートＵＥ１００のそれぞれから第１要求を受けた場合、第２要求を送信しなくてもよい。ＵＥ１００−１は、直接通信用の送信リソースをｅＮＢ２００へ要求してもよい。ＵＥ１００−１は、サイドリンク用のバッファステータスレポート（ＳＬ-ＢＳＲ）をｅＮＢ２００へ送信してもよい。ＳＬ−ＢＳＲは、端末間での送信に利用可能なデータの量についての情報をｅＮＢ（サービングｅＮＢ）２００へ提供するためのものである。例えば、利用可能なデータの量は、レイヤ２中継により伝送すべきデータ（パケット）の量であってもよい。利用可能なデータの量は、複数のＵＥ１００−２が保持する送信すべきデータの合計のデータ量であってもよい。各リモートＵＥ１００は、ステップＳ１０２において、送信すべきデータの量をＵＥ１００−１へ通知してもよい。

ｅＮＢ２００は、第２要求をＵＥ１００−１から受信する。ｅＮＢ２００は、第２要求を許可するか拒否するかを判定してもよい。

ステップＳ１０４において、ｅＮＢ２００は、第２要求に対する応答をＵＥ１００−１へ送信できる。ｅＮＢ２００は、応答メッセージとして、例えば、ＲＲＣ接続再設定メッセージ（ＲＲＣＣｏｎｎ．Ｒｅｃｏｎｆ．）をＵＥ１００−１へ送信してもよい。

ｅＮＢ２００は、レイヤ２中継を許可する場合に、レイヤ２中継を設定するための情報（Ｌ２ ｒｅｌａｙ ｃｏｎｆｉｇ．）を応答メッセージに含めてもよい。

ｅＮＢ２００は、レイヤ２中継において特別なレイヤ（例えば、アダプテーションレイヤ）を利用することを示す情報を応答メッセージに含めてもよい。ｅＮＢ２００は、例えば、アダプテーションレイヤを介してレイヤ２中継を実行するか否かを判定してもよい。ｅＮＢ２００は、例えば、アダプテーションレイヤを介してレイヤ２中継が実行されることを示す情報を応答メッセージに含めてもよい。ｅＮＢ２００は、例えば、アダプテーションレイヤを介さずにレイヤ２中継が実行されることを示す情報を応答メッセージに含めてもよい。

ｅＮＢ２００は、ＵＥ１００−１からＳＬ ＢＳＲを受け取った場合には、データ量に応じて無線リソースを割り当てても良い。応答メッセージは、割り当てた無線リソースを示す情報を含んでいてもよい。ｅＮＢ２００は、複数の無線リソースにより構成される無線リソースプールを応答メッセージに含めてもよい。

ｅＮＢ２００は、第２要求を拒否する場合には、拒否を示すメッセージをＵＥ１００−１へ送信してもよい。この場合、ＵＥ１００−１は、レイヤ２中継が拒否されたことを示すメッセージをＵＥ１００−２へ送信してもよい。ＵＥ１００−１は、直接通信の要求を拒否するメッセージ（Ｄｉｒｅｃｔ Ｃｏｍｍ．Ｒｅｑｕｅｓｔ ＮＡＣＫ）をＵＥ１００−２へ送信してもよい。

以下において、ｅＮＢ２００がレイヤ２中継を許可したと仮定して説明を進める。

ステップＳ１０５において、ＵＥ１００−１は、第１要求に対する応答をＵＥ１００−２へ送信する。ＵＥ１００−１は、直接通信の要求を承認するメッセージ（Ｄｉｒｅｃｔ Ｃｏｍｍ．Ｒｅｑｕｅｓｔ ＡＣＫ）をＵＥ１００−２へ送信してもよい。

ＵＥ１００−１は、レイヤ２中継を設定するための情報（Ｌ２ ｒｅｌａｙ ｃｏｎｆｉｇ．）をＵＥ１００−２へ送信してもよい。当該情報は、ＵＥ１００−１がｅＮＢ２００から受け取った設定情報であってもよい。

ＵＥ１００−２は、例えば、ＵＥ１００−１から受け取った情報に基づいて、レイヤ２中継においてアダプテーションレイヤを介したパケットの伝送が許可されるか否かを判定してもよい。

以後のステップＳ１０６、Ｓ１０８、Ｓ１０９において、レイヤ２中継により、ＵＥ１００−１とＵＥ１００−２との間においてＵＥ１００−２のトラフィック（例えば、ＰＣ５トラフィック）が伝送される。レイヤ２中継により、ＵＥ１００−１とｅＮＢ２００との間においてＵＥ１００−２のトラフィック（例えば、Ｕｕトラフィック）が伝送される。ＵＥ１００−２は、ｅＮＢ２００から割り当てられた無線リソース（無線リソースプール）を用いて、トラフィックを伝送できる。

ステップＳ１０６において、ＵＥ１００−２は、ＲＲＣ接続を要求するためのメッセージ（ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｑｕｅｓｔ）をＵＥ１００−１を介してｅＮＢ２００へ送信してもよい。

ステップＳ１０７において、ｅＮＢ２００と上位ノード（ＭＭＥ３００／ＳＧＷ４００）との間で、ＵＥ１００−２に対してＲＲＣ接続を確立するためのシグナリングが伝送されてもよい。

ステップＳ１０８において、ｅＮＢ２００は、ＲＲＣ接続をセットアップするためのメッセージ（ＲＲＣＣｏｎｎｅｃｔｉｏｎＳｅｔｕｐ）をＵＥ１００−１を介してＵＥ１００−２へ送信してもよい。

ＵＥ１００−２は、当該メッセージに基づいて、ＲＲＣ接続を確立するためのセットアップを開始する。ＵＥ１００−２は、セットアップが終了した場合に、ステップＳ１０９の処理を実行する。

ステップＳ１０９において、ＵＥ１００−２は、ＲＲＣ接続のセットアップが完了したこと示すメッセージ（ＲＲＣＣｏｎｎｅｃｔｉｏｎＳｅｔｕｐＣｏｍｐｌｅｔｅ）をＵＥ１００−１を介してｅＮＢ２００へ送信してもよい。

以上により、ネットワークとＵＥ１００−２との間にＲＲＣ接続が確立されるため、ネットワークは、通常のＵＥ１００と同様に、ＵＥ１００−２に対してサービスを提供することが可能である。例えば、ネットワークは、ＵＥ１００−２（の位置）を特定することができる。ネットワークは、ＵＥ１００−２を呼び出すことができる。ネットワークは、ＵＥ１００−２へデータを届けることができる。

ＵＥ１００−２は、ＲＲＣ接続が確立された後も、レイヤ２中継により、ＵＥ１００−１を介して、ＵＥ１００−２のトラフィック（ユーザデータ／パケット）が伝送される。

ＵＥ１００−２は、既存のＵＥ１００と同様に、ＵＥ１００−１を介して、ＲＲＣ接続を解放するための手順を実行できる。

（Ｂ）動作例２
動作例２について、図９を用いて説明する。図９は、動作例２を説明するためのシーケンス図である。

動作例２では、ＰＣ５プロトコルを用いずに、レイヤ２中継を設定することができる。上述で説明した内容と同様の説明は省略する。

ステップＳ２０１において、ＵＥ１００−１は、ＰＣ５メッセージと異なるメッセージにより、ＵＥ１００−１がレイヤ２中継を可能であることを示す情報を送信してもよい。

例えば、ＵＥ１００−１は、ＭＩＢ−ＳＬ（ＭａｓｔｅｒＩｎｆｏｒｍａｔｉｏｎＢｌｏｃｋ−ＳＬ）メッセージ内にＵＥ１００−１がレイヤ２中継を可能であることを示す情報（Ｌ２ Ｒｅｌａｙ ｃａｐａｂｉｌｉｔｙ）を含めてもよい。ＵＥ１００−１は、ＳＬＳＳ（Ｓｉｄｅｌｉｎｋ Ｓｙｎｃｈｒｏｎｉｓａｔｉｏｎ Ｓｉｇｎａｌ）のシーケンス（信号系列）により、ＵＥ１００−１がレイヤ２中継を可能であることを示してもよい。

ＭＩＢ−ＳＬメッセージは、サイドリンク共通制御情報を運搬するためのメッセージである。ＭＩＢ−ＳＬメッセージは、ＳＬ−ＢＣＨを介して、ＳＬＳＳを送信するＵＥ（すなわち、同期参照として動作するＵＥ）により送信される情報を含む。

ＳＬＳＳは、サイドリンクにおける同期信号である。ＳＬＳＳは、ＰＳＳＳ（Ｐｒｉｍａｒｙ Ｓｉｄｅｌｉｎｋ Ｓｙｎｃｈｒｏｎｉｓａｔｉｏｎ Ｓｉｇｎａｌ）及びＳＳＳＳ（Ｓｅｃｏｎｄａｒｙ Ｓｉｄｅｌｉｎｋ Ｓｙｎｃｈｒｏｎｉｓａｔｉｏｎ Ｓｉｇｎａｌ）により構成される。ＵＥ１００−１がレイヤ２中継を可能であることを示すシーケンスは、ＰＳＳＳのシーケンスであってもよい。ＳＳＳＳのシーケンスであってもよい。

ＵＥ１００−２は、ＵＥ１００−１からのメッセージに基づいて、ＵＥ１００−１がレイヤ２中継が可能であるか否かを判定できる。ＵＥ１００−２は、ＵＥ１００−１がレイヤ２中継が可能である場合、ステップＳ２０２の処理を実行できる。ＵＥ１００−２は、ＵＥ１００−１からＬ２ Ｒｅｌａｙ ｃａｐａｂｉｌｉｔｙを受け取っていない場合であっても、ステップＳ２０２の処理を実行してもよい。

ステップＳ２０２において、ＵＥ１００−２は、ＰＣ５メッセージと異なるメッセージにより、レイヤ２中継のための要求（第１要求）をＵＥ１００−１へ送信してもよい。

例えば、ＵＥ１００−２は、ＭＡＣ ＣＥ（ＭＡＣ Ｃｏｎｔｒｏｌ Ｅｌｅｍｅｎｔ）に第１要求を示す情報を含めてもよい。ＵＥ１００−２は、ＰＤＣＰヘッダに第１要求を示す情報を含めてもよい。ＵＥ１００−２は、ＲＲＣメッセージに第１要求を示す情報を含めてもよい。ＲＬＣレイヤよりも上位レイヤのメッセージに第１要求を示す情報を含めることによって、ＵＥ間でのパケット伝送（中継）が３ＧＰＰアクセス技術か非３ＧＰＰアクセス技術かに関係なく、ＵＥ１００−２は、第１要求をＵＥ１００−２へ送信することができる。

ステップＳ２０３及びＳ２０４は、ステップＳ１０３及びＳ１０４に対応する。

ステップＳ２０５において、ＵＥ１００−１は、ＰＣ５メッセージと異なるメッセージにより、第１要求に対する応答をＵＥ１００−２へ送信してもよい。

例えば、ＵＥ１００−１は、ＭＡＣ ＣＥに第１要求に対する応答を示す情報を含めてもよい。ＵＥ１００−１は、ＰＤＣＰヘッダに第１要求に対する応答を示す情報を含めてもよい。ＵＥ１００−１は、ＲＲＣメッセージに第１要求に対する応答を示す情報を含めてもよい。ＵＥ１００−１は、ＵＥ１００−２の第１要求と同じタイプの応答を送信してもよい。例えば、ＵＥ１００−１は、ＭＡＣ ＣＥにより第１要求を受け取った場合は、ＭＡＣ ＣＥにより第１要求に対する応答を送信してもよい。

以上によれば、上位レイヤであるＰＣ５プロトコルを用いることなく、ＵＥ１００（ＵＥ１００−２）にレイヤ２中継が設定可能である。このため、ＰＣ５プロトコルに従って設定されるレイヤ３中継よりも早期にレイヤ２中継を開始することができる。

（Ｃ）動作例３
動作例３について、図１０から図１２を用いて説明する。図１０は、動作例３を説明するためのフローチャートである。図１１は、動作例３を説明するための図である。図１２は、動作例３を説明するためのフローチャートである。

動作例３では、アダプテーションレイヤを利用したレイヤ２中継の動作の一例を説明する。上述で説明した内容と同様の説明は省略する。

図１０に示すように、ステップＳ３０１において、ＵＥ１００−２は、アダプテーションレイヤにおいて送信用のパケットを処理する。例えば、ＵＥ１００−２は、送信元のＵＥ（ＵＥ１００−２）を示す識別子をパケットに含めてもよい。ＵＥ１００−２は、アダプテーションレイヤにおいて、パケットに付与するヘッダ（新たなヘッダ）にＵＥ１００−２の識別子を含めてもよい。ＵＥ１００−２の識別子の例は、後述する（動作例７参照）。

ＵＥ１００−２は、パケットの優先度の情報をパケットに含めてもよい。ＵＥ１００−２は、アダプテーションレイヤにおいて、パケットに付与するヘッダにパケットの優先度の情報を含めてもよい。

ステップＳ３０２において、ＵＥ１００−２は、アダプテーションレイヤよりも下位レイヤにおいて、アダプテーションレイヤでパケットが処理されたことを示す情報（Ａｄａｐｔａｔｉｏｎ）をパケットに含める。ＵＥ１００−２は、例えば、ＭＡＣレイヤにおいて当該情報をパケットに含めてもよい。

図１１に示すように、ＵＥ１００−２は、例えば、ＭＡＣ ＳＤＵ（ＭＡＣ Ｓｅｒｖｉｃｅ Ｄａｔａ Ｕｎｉｔ）毎に生成されるＭＡＣサブヘッダに当該情報（Ａｄａｐｔａｔｉｏｎ）を含めてもよい。ＵＥ１００−２は、ＭＡＣヘッダに当該情報を含めてもよい。

ＵＥ１００−２は、非３ＧＰＰアクセス技術で伝送されるパケットのヘッダに、当該情報を含めてもよい。例えば、当該情報として、ＬＷＡ（ＬＴＥ ＷＬＡＮ Ａｇｇｒｅｇａｔｉｏｎ）において用いられるＬＷＡ ＥｔｈｅｒＴｙｐｅのパラメータ（ＥｔｈｅｒＴｙｐｅ）が流用されてもよい。ＥｔｈｅｒＴｙｐｅは、受信したパケットがアダプテーションレイヤで処理されるべき（受信したパケットがアダプテーションレイヤへ送られるべき）かどうかを決定するために用いられてもよい。ＵＥ１００−２は、３ＧＰＰアクセス技術で伝送されるパケットのヘッダにＥｔｈｅｒＴｙｐｅを含めてもよい。

ステップＳ３０３において、ＵＥ１００−２は、ＭＡＣレイヤにおいて処理したパケットを、物理レイヤにおいて処理した後、ＵＥ１００−１を介して、ｅＮＢ２００へ送信する。

具体的には、ＵＥ１００−１は、ＵＥ１００−２から受け取ったパケットを、ＭＡＣレイヤにおいて処理する場合に、アダプテーションレイヤでパケットが処理されたことを示す情報を検出する。これにより、ＵＥ１００−１は、当該パケットがアダプテーションレイヤでパケットが処理されたことを把握する。すなわち、ＵＥ１００−１は、アダプテーションレイヤを介したトラフィックであると把握する。ＵＥ１００−１は、アダプテーションレイヤにおいて当該パケットを処理する。

一方、ＵＥ１００−１は、ＵＥ１００−２から受け取ったパケットにおいてアダプテーションレイヤでパケットが処理されたことを示す情報を検出しない場合、アダプテーションレイヤにおける処理を省略する。

ＵＥ１００−１は、パケットのヘッダに含まれる情報（ＥｔｈｅｒＴｙｐｅ）に基づいて、パケットをアダプテーションレイヤで処理すべきかどうかを判定してもよい。ＵＥ１００−１は、例えば、パケットがアダプテーションレイヤで処理されたことをＥｔｈｅｒＴｙｐｅが示す場合には、アダプテーションレイヤにおいてパケットを処理する。ＵＥ１００−１は、パケットがアダプテーションレイヤで処理されていないことをＥｔｈｅｒＴｙｐｅが示す場合には、アダプテーションレイヤにおける処理を省略する。

その後、ＵＥ１００−１は、ＵＥ１００−２から受け取ったパケットをｅＮＢ２００へ転送（中継）する。

ｅＮＢ２００は、ＵＥ１００−１と同様に、ＵＥ１００−１から受け取ったパケット（例えば、ＭＡＣサブヘッダ）からアダプテーションレイヤでパケットが処理されたことを示す情報を検出する。

ｅＮＢ２００は、当該検出により、当該パケットがアダプテーションレイヤでパケットが処理されたことを把握する。ｅＮＢ２００は、当該パケットをアダプテーションレイヤにおいて処理する。ｅＮＢ２００は、アダプテーションレイヤにおいて、パケットの送信元（パケットの発生元）を示すＵＥ１００−２の識別子が含まれる場合、当該パケットの送信元がＵＥ１００−２であることを把握できる。これにより、ｅＮＢ２００は、アダプテーションレイヤにおいて、パケットの送信元（パケットの発生元）を把握できる。ｅＮＢ２００は、レイヤ３中継のように、上位レイヤであるＩＰレイヤにおいてパケットの送信元（パケットの発生元）を把握する処理を実行しなくてもよい。

上述では、上りリンクのレイヤ２中継について説明したが、下りリンクのレイヤ２中継においても同様の動作が実行されてもよい。

図１２に示すように、ステップＳ４０１において、ｅＮＢ２００は、アダプテーションレイヤにおいて送信用のパケットを処理する。例えば、ｅＮＢ２００は、送信先のＵＥ（ＵＥ１００−２）を示す識別子をパケットに含めてもよい。ｅＮＢ２００は、アダプテーションレイヤにおいて、パケットに付与するヘッダ（新たなヘッダ）にＵＥ１００−２の識別子を含めてもよい。識別子は、最終的な送信先の識別子である。

ステップＳ４０２において、ｅＮＢ２００は、アダプテーションレイヤよりも下位レイヤにおいて、アダプテーションレイヤでパケットが処理されたことを示す情報をパケットに含める。ｅＮＢ２００は、例えば、ＭＡＣレイヤにおいて当該情報をパケットに含めてもよい。

ステップＳ４０３において、ｅＮＢ２００は、ＭＡＣレイヤにおいて処理したパケットを、物理レイヤにおいて処理した後、ＵＥ１００−１を介して、ＵＥ１００−２へ送信する。

ＵＥ１００−１は、上述と同様に、ｅＮＢ２００から受け取ったパケットに、アダプテーションレイヤでパケットが処理されたことを示す情報が含まれるか否かを判定する。ＵＥ１００−１は、アダプテーションレイヤを介したトラフィックであると把握した場合、アダプテーションレイヤにおいて処理を実行する。ＵＥ１００−１は、アダプテーションレイヤを介したトラフィックでないと把握した場合、アダプテーションレイヤにおける処理を省略する。

ＵＥ１００−１は、アダプテーションレイヤにおいて、新たなヘッダに含まれる送信先のＵＥ（ＵＥ１００−２）を示す識別子により、パケットの送信先を把握してもよい。これにより、ＵＥ１００−１は、上位レイヤであるＩＰレイヤにおいてパケットの送信元（パケットの発生元）を把握する処理を実行せずに済む。

その後、ＵＥ１００−１は、ｅＮＢ２００から受け取ったパケットをＵＥ１００−２へ転送（中継）する。

（Ｄ）動作例４
動作例４について、図１３を用いて説明する。図１３は、動作例４を説明するためのフローチャートである。

動作例４では、アダプテーションレイヤを利用したレイヤ２中継の動作の一例を説明する。上述で説明した内容と同様の説明は省略する。

図１３に示すように、ステップＳ５０１において、ｅＮＢ２００は、レイヤ２中継で用いられる論理チャネル識別子（ＬＣＩＤ：Ｌｏｇｉｃａｌ Ｃｈａｎｎｅｌ ＩＤ）をＵＥ１００−１へ割り当てる。当該ＬＣＩＤは、ＵＥ１００−１とｅＮＢ２００との間で用いられるＬＣＩＤである。ｅＮＢ２００は、アダプテーションレイヤを介したパケットの伝送が許可されるＬＣＩＤをＵＥ１００−１へ通知してもよい。すなわち、ｅＮＢ２００は、所定のＬＣＩＤでのみアダプテーションレイヤを介したパケットの伝送を許可してもよい。ｅＮＢ２００は、既に割り当てたＬＣＩＤの中から、所定のＬＣＩＤを決定してもよい。

ステップＳ５０２において、ＵＥ１００−１とｅＮＢ２００とは、アダプテーションレイヤを介したパケットを伝送する場合、アダプテーションレイヤを介したパケットの伝送が許可されたＬＣＩＤにより示される論理チャネルを用いて当該パケットを伝送する。これにより、ＵＥ１００−１とｅＮＢ２００とは、当該ＬＣＩＤにより示される論理チャネルで伝送されるパケットがアダプテーションレイヤを介したパケットであることを把握することができる。

（Ｅ）動作例５
動作例５について、図１４及び図１５を用いて説明する。図１４は、動作例５を説明するための図である。図１５は、動作例５を説明するためのシーケンス図である。

図１４に示すように、既存のレイヤ３中継では、ＵＥ１００−１（Ｒｅｌａｙ ＵＥ）は、ＵＥ１００−２（Ｒｅｍｏｔｅ ＵＥ）からのパケットを受信した場合、ＩＰレイヤにおける処理を実行することで、パケットの優先度（ＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）／ＰＰＰＰ（ＰｒｏＳｅ Ｐｅｒ−Ｐａｃｋｅｔ Ｐｒｉｏｒｉｔｙ）など）を把握することができる。しかしながら、レイヤ２中継では、ＵＥ１００−１は、ＩＰレイヤにおける処理を実行しないため、パケットの優先度を把握することができない。このため、レイヤ２中継において、ＵＥ１００−１からｅＮＢ２００へパケットを伝送する場合に、優先度の高いパケットの遅延が発生する可能性がある。

そこで、以下の動作が実行されてもよい。上述で説明した内容と同様の説明は省略する。

図１５に示すように、ステップＳ６０１、Ｓ６０２は、ステップＳ１０２、Ｓ１０３に対応する。ＵＥ１００−２は、後述するように、ＬＣＩＤを通知されるまで、ＰＣ５インターフェイス上で利用可能な所定のＬＣＩＤ（ＬＣＩＤ♯０）を用いて、第１要求（Ｌ２ Ｒｅｌａｙ Ｒｅｕｑｅｓｔ）をＵＥ１００−１へ送信してもよい。

ステップＳ６０３において、ステップＳ１０４と同様に、ｅＮＢ２００は、第２要求に対する応答をＵＥ１００−１へ送信できる。

当該応答は、ＬＣＩＤと優先度とが関連付けられた関連情報（Ａｓｓｏｃｉａｔｉｏｎ ｉｎｆｏ．）を含んでいてもよい。関連情報は、ＬＣＩＤと優先度とが対応付けられたリストであってもよい。優先度は、ＰＰＰＰ（のクラス）であってもよい。優先度は、ＱｏＳ（のクラス）であってもよい。ＬＣＩＤは、ＵＥ１００−１とＵＥ１００−２との間の論理チャネルの識別子である。ＬＣＩＤは、ＵＥ１００−１とＵＥ１００−２との間でパケットを伝送するために用いられる。このように、ｅＮＢ２００がＰＣ５インターフェイス上で利用可能なＬＣＩＤを指定できる。

これにより、ｅＮＢ２００は、優先度に対応付けられた複数のＬＣＩＤをＵＥ１００−１へ通知できる。

ステップＳ６０４において、ステップＳ１０５と同様に、ＵＥ１００−１は、第１要求に対する応答をＵＥ１００−２へ送信する。応答は、関連情報を含んでいてもよい。

これにより、ｅＮＢ２００は、優先度に対応付けられた複数のＬＣＩＤをＵＥ１００−２へ通知できる。

ステップＳ６０５において、ＵＥ１００−２は、パケットをＵＥ１００−１へ送信するために、複数のＬＣＩＤの中から、パケットの優先度に対応するＬＣＩＤを選択する。

例えば、ＵＥ１００−２は、発生したパケットの優先度が高優先度である場合、関連情報に基づいて、高優先度に対応付けられたＬＣＩＤ（例えば、ＬＣＩＤ♯１）を選択する。一方、ＵＥ１００−２は、発生したパケットの優先度が低優先度である場合、関連情報に基づいて、低優先度に対応付けられたＬＣＩＤ（例えば、ＬＣＩＤ♯３）を選択する。

ＵＥ１００−２は、選択したＬＣＩＤ（例えば、ＬＣＩＤ♯３）を用いて、パケット（トラフィック）をＵＥ１００−１へ送信する。すなわち、ＵＥ１００−２は、選択したＬＣＩＤにより識別される論理チャネルにより、パケットをＵＥ１００−１へ送信する。

ステップＳ６０６において、ＵＥ１００−１は、ＵＥ１００−２から受信したパケットの送信に用いられたＬＣＩＤにより、パケットの優先度を理解する。ＵＥ１００−１は、関連情報を用いて、パケットの送信に用いられたＬＣＩＤと対応付けられた優先度を、パケットの優先度に決定できる。これにより、ＵＥ１００−１は、パケットの優先度を把握することができる。

ステップＳ６０７において、ＵＥ１００−１は、パケットの優先度に対応する適切なＬＣＩＤ（無線ベアラ）を介して当該パケットをｅＮＢ２００へ送信する。

以上により、ＵＥ１００−１は、ＩＰレイヤでの処理によりパケットの優先度を把握しなくても、パケットの優先度を把握することができる。

（Ｆ）動作例６
動作例６について、図１６から図１８を用いて説明する。図１６は、動作例６を説明するためのシーケンス図である。図１７及び図１８は、動作例６を説明するための図である。

動作例６では、動作例５と異なる方法により、ＵＥ１００−１がパケットの優先度を把握する。上述で説明した内容と同様の説明は省略する。

図１６に示すように、ステップＳ７０１及びＳ７０２は、ステップＳ６０１及びＳ６０２に対応する。

ステップＳ７０３において、ｅＮＢ２００は、第２要求に対する応答をＵＥ１００−１へ送信できる。

当該応答は、優先度に対応付けられた識別情報を含んでいてもよい。応答は、識別情報と優先度とが対応付けられたリストを含んでいてもよい。

識別情報は、例えば、ＵＥ１００−１とネットワークとの間に確立されるベアラの識別子である。識別情報は、ＵＥ１００−１（又はＵＥ１００−２）とＰＧＷ５００との間のＥＰＳ（Ｅｖｏｌｖｅｄ Ｐａｃｋｅｔ Ｓｙｓｔｅｍ）ベアラの識別子（ＥＰＳ ｂｅａｒｅｒ ＩＤ ｆｏｒ Ｌ２ Ｒｅｌｙａ）であってもよい。当該ＥＰＳベアラの識別子は、レイヤ２中継に用いられるＥＰＳベラの識別子である。

識別情報は、ＵＥ１００−１とｅＮＢ２００との間でパケットを伝送するために用いられるＬＣＩＤであってもよい。当該情報は、ＵＥ１００−１とｅＮＢ２００との間でパケットを伝送するために用いられるＤＲＢ ＩＤ（Ｄａｔａ Ｒａｄｉｏ Ｂｅａｒｅｒ ＩＤ）であってもよい。

これにより、ｅＮＢ２００は、優先度に対応付けられた複数の識別情報をＵＥ１００−１へ通知できる。

ステップＳ７０４において、ＵＥ１００−１は、第１要求に対する応答をＵＥ１００−２へ送信する。応答は、識別情報を含んでいてもよい。

これにより、ｅＮＢ２００は、優先度に対応付けられた複数の識別情報をＵＥ１００−２へ通知できる。

ステップＳ７０５において、ＵＥ１００−２は、パケットをＵＥ１００−１へ送信するために、複数の識別情報の中から、パケットの優先度に対応する識別情報を選択する。

例えば、ＵＥ１００−２は、発生したパケットの優先度が高優先度である場合、関連情報に基づいて、高優先度に対応付けられたＥＰＳベアラ ＩＤ（例えば、ＥＰＳベアラ ＩＤ♯１）を選択する。一方、ＵＥ１００−２は、発生したパケットの優先度が低優先度である場合、関連情報に基づいて、低優先度に対応付けられたＥＰＳベアラ ＩＤ（例えば、ＥＰＳベアラ ＩＤ♯３）を選択する。

ＵＥ１００−２は、選択した識別情報を含むヘッダが付与されたパケットを生成する。例えば、図１７に示すように、ＵＥ１００−２は、ＰＤＣＰレイヤにおいて、選択したＥＰＳベアラ ＩＤを含むヘッダが付与されたパケットを生成する。図１８に示すように、ＵＥ１００−２は、ＰＤＣＰレイヤにおいて、選択したＬＣＩＤを含むヘッダが付与されたパケットを生成してもよい。

ＵＥ１００−２は、サイドリンク用のＰＤＣＰフォーマットではなく、Ｕｕインターフェイス用のＰＤＣＰフォーマットによりパケット（トラフィック）を生成してもよい。これにより、ＵＥ１００−１において、Ｕｕインターフェイス用のＰＤＣＰフォーマットに変換する処理を低減することができる。

ＵＥ１００−２は、生成したパケット（トラフィック）をＵＥ１００−１へ送信する。

ステップＳ７０６において、ＵＥ１００−１は、パケットのヘッダに含まれる識別情報により、当該パケットの優先度を把握することができる。ＵＥ１００−１は、パケットの優先度に対応する適切なＤＲＢ（Ｄａｔａ Ｒａｄｉｏ Ｂｅａｒｅｒ）を理解する。ＵＥ１００−１は、識別情報に対応付けられた優先度を、パケットの優先度に決定できる。これにより、ＵＥ１００−１は、パケットの優先度を把握することができる。

ステップＳ７０７において、ＵＥ１００−１は、パケットの優先度に対応する適切なＤＲＢを介して、当該パケットをｅＮＢ２００へ送信（転送）する。

ＵＥ１００−１は、パケットを送信するために、パケットのヘッダに含まれる識別情報（ＥＰＳベアラＩＤ／ＬＣＩＤ）に対応するＥＰＳベアラ／ＬＣＩＤを用いてもよい。

以上により、ＵＥ１００−１は、ＩＰレイヤでの処理によりパケットの優先度を把握しなくても、パケットの優先度を把握することができる。

（Ｇ）動作例７
動作例７について、図１９から図２２を用いて説明する。図１９は、動作例７を説明するための図である。図２０は、動作例７を説明するためのフローチャートである。図２１及び図２２は、動作例７を説明するための図である。

図１９に示すように、レイヤ２中継では、ＵＥ１００−１は、ＩＰレイヤにおける処理を実行しないため、ｅＮＢ２００からのパケットの中継先（すなわち、ＵＥ１００−２）を把握できない可能性がある。同様に、ｅＮＢ２００は、ＵＥ１００−１からのパケットの発生元（すなわち、ＵＥ１００−２）を把握できない可能性がある。このため、レイヤ２中継が適切に実行されない可能性がある。

そこで、以下の動作が実行されてもよい。上述で説明した内容と同様の説明は省略する。

図２０に示すように、ステップＳ８０１において、ＵＥ１００−２は、例えば、ＰＤＣＰレイヤにおいて、ＵＥ１００−２の識別子を含むヘッダを生成する（図２１及び図２２参照）。ＵＥ１００−２は、他のレイヤにおいて、ＵＥ１００−２の識別子を含むヘッダを生成してもよい。

ＵＥ１００−２の識別子は、例えば、ＰｒｏＳｅを利用するためにネットワークにより割り当てられるＰｒｏＳｅ ＩＤであってもよい。ＵＥ１００−２の識別子は、送信元を示すＳｏｕｒｃｅ Ｌ２ ＩＤであってもよい（図２１参照）。ＵＥ１００−２の識別子は、接続中のリモートＵＥのリストのインデックス（Ｄｅｓｔｉｎａｔｉｏｎ ｉｎｄｅｘ）であってもよい（図２２参照）。当該インデックスは、リレーＵＥがネットワークへ報告する際に用いられる。ＵＥ１００−２は、当該インデックスをＵＥ１００−１又はｅＮＢ２００から通知されてもよい。

ステップＳ８０２において、ＵＥ１００−２は、生成したヘッダが付与されたパケット（トラフィック）をＵＥ１００−１を介して、ｅＮＢ２００へ送信する。

ｅＮＢ２００は、ヘッダに含まれるＵＥ１００−２の識別子に基づいて、当該パケットの送信元を把握することができる。

ｅＮＢ２００は、同様に、例えば、ＰＤＣＰレイヤにおいて、ＵＥ１００−２の識別子を含むヘッダを生成できる。

ＵＥ１００−１は、ｅＮＢ２００からパケットを受信した場合、ヘッダに含まれるＵＥ１００−２の識別子により、パケットの送信先（中継先）を把握することができる。

以上により、レイヤ２中継を適切に実行することができる。

（Ｈ）動作例８
動作例８について、図２３を用いて説明する。図２３は、動作例８を説明するためのフローチャートである。

動作例８では、動作例７と異なる方法により、パケットの送信先／送信元を把握する。上述で説明した内容と同様の説明は省略する。

ステップＳ９０１において、ｅＮＢ２００は、ＵＥ１００−２のパケット専用のＬＣＩＤを決定する。ｅＮＢ２００は、リモートＵＥ毎に利用可能な専用のＬＣＩＤを決定してもよい。ｅＮＢ２００は、１つのリモートＵＥに対して複数の専用のＬＣＩＤを決定してもよい。ＬＣＩＤは、ＵＥ１００−１とｅＮＢ２００との間でパケットを伝送するためのＬＣＩＤである。

ステップＳ９０２において、ｅＮＢ２００は、決定されたＬＣＩＤをＵＥ１００−２のパケット専用のＬＣＩＤとして、ＵＥ１００−１へ通知する。

ステップＳ９０３において、ＵＥ１００−１とｅＮＢ２００とは、ＵＥ１００−２のパケットを決定されたＬＣＩＤを用いて伝送する。これにより、ＵＥ１００−１及びｅＮＢ２００は、当該ＬＣＩＤを用いて伝送されるパケットがＵＥ１００−２のパケットであることを把握することができる。

以上により、レイヤ２中継を適切に実行することができる。

（Ｉ）動作例９
動作例９について、図２４を用いて説明する。図２４は、動作例９を説明するためのフローチャートである。

動作例９では、動作例７及び８と異なる方法により、パケットの送信先／送信元を把握する。上述で説明した内容と同様の説明は省略する。

図２４に示すように、ステップＳ１００１において、ｅＮＢ２００は、ＵＥ１００−２へＲＮＴＩ（Ｒａｄｉｏ Ｎｅｔｗｏｒｋ Ｔｅｍｐｏｒａｒｙ Ｉｄｅｎｔｉｆｉｅｒ）を割り当てる。ｅＮＢ２００は、第２要求の受信に応じて、ＵＥ１００−２へＲＮＴＩを割り当ててもよい。ＲＮＴＩは、例えば、Ｃ−ＲＮＴＩ（Ｃｅｌｌ−ＲＮＴＩ）であってもよい。

ステップＳ１００２において、ｅＮＢ２００は、ＵＥ１００−２へ割り当てたＲＮＴＩをＵＥ１００−１へ通知する。

その後、ｅＮＢ２００は、ＵＥ１００−２のパケットを当該ＲＮＴＩを用いてエンコードする。ｅＮＢ２００は、エンコードされたパケットをＵＥ１００−１へ送信する。

ステップＳ１００３において、ＵＥ１００−１は、ｅＮＢ２００から受信したパケットに対して、ＵＥ１００−２へ割り当てられたＲＮＴＩを用いてデコードを試みる。

ステップＳ１００４において、ＵＥ１００−１は、デコードに成功したパケットをＵＥ１００−２のパケットであると判定する。ＵＥ１００−１は、デコードに失敗したパケットをＵＥ１００−２のパケットでないと判定する。

ＵＥ１００−１は、デコードに成功したパケットをＵＥ１００−２へ転送（中継）する。

同様に、ＵＥ１００−１は、ＵＥ１００−２からパケットを受信した場合、ＵＥ１００−２のパケットを当該ＲＮＴＩを用いてエンコードする。ＵＥ１００−１は、エンコードされたパケットをＵＥ１００−１へ送信する。

ｅＮＢ２００は、ＵＥ１００−１から受信したパケットに対して、ＵＥ１００−２へ割り当てられたＲＮＴＩを用いてデコードを試みる。

ｅＮＢ２００は、デコードに成功したパケットをＵＥ１００−２のパケットであると判定する。ｅＮＢ２００は、デコードに成功したパケットをＵＥ１００−２のパケットとして上位ネットワークへ送る。

以上により、レイヤ２中継を適切に実行することができる。

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

上述において、レイヤ２中継が実行される場合、ＵＥ間では、パケットのヘッダ（例えば、ＰＤＣＰレイヤ）が、レイヤ２中継に関する情報を必ず含んでもよい（動作例６参照）。例えば、レイヤ２中継に関する情報は、例えば、上述で説明した、ベアラＩＤ（ＥＰＳベアラＩＤ、ＤＲＢ ＩＤ、ＬＣＩＤなど）、ＵＥ１００−２の識別子（リモートＵＥの識別子）、優先度の情報などである。

レイヤ２中継が実行される場合、ＵＥ間では、アダプテーションレイヤを用いた通信が必ず適用されてもよい。ＵＥ１００−１とＵＥ１００−２間において、アダプテーションレイヤを介した通信が必ず実行されることにより、アダプテーションレイヤを介するかどうかの判断を省略してもよい。

ＵＥ間では、アダプテーションレイヤを用いた通信が必ず適用される場合、ＵＥ−ｅＮＢ間でも、アダプテーションレイヤを用いた通信が必ず適用されてもよい。ＵＥ１００−１とＵＥ１００−２間においても、ＵＥ１００−１とｅＮＢ２００間においても、アダプテーションレイヤを介した通信が必ず実行されることにより、アダプテーションレイヤを介するかどうかの判断を省略してもよい。

ＵＥ間では、アダプテーションレイヤを用いた通信が必ず適用される場合、ＵＥ−ｅＮＢ間でも、アダプテーションレイヤを用いた通信が適用されなくてもよい。例えば、ＵＥ−ｅＮＢ間では、リモートＵＥの識別子とＤＲＢ ＩＤとが関連付けられることにより、アダプテーションレイヤが導入されなくてもよい。ｅＮＢ２００は、リモートＵＥの識別子とＤＲＢ ＩＤとが関連付け（例えば、リスト）をＵＥ１００−１へ通知できる。ＵＥ１００−１とｅＮＢ２００とは、当該リストに基づいて、パケットの送信に用いられたＤＲＢ ＩＤにより、どのリモートＵＥのパケットかを把握することができる。

ＵＥ１００−１とＵＥ１００−２間で完了する通信（中継が必要ない通信）と、ＵＥ１００−１とｅＮＢ２００間の通信（中継が必要な通信）とを見分けるために、ＵＥ１００−２は、アダプテーションレイヤにおいて判定のための識別子をＵＥ１００−１へ通知してもよい。すなわち、ＵＥ１００−２は、判定のための識別子をパケットのヘッダに含めてもよい。判定のための識別子は、１ビットの識別子でもよい。判定のための識別子は、優先度を通知するための識別子であって、かつ、特別な値であってもよい。ＵＥ１００−１は、当該識別子に基づいてＵＥ１００−１とＵＥ１００−２との間で完了する通信（中継が必要ない通信）と、ＵＥ１００−１とｅＮＢ２００との間の通信（中継が必要な通信）とを見分けることができる。

動作例４では、ｅＮＢ２００は、ＵＥ１００−１とｅＮＢ２００との間で用いられるＬＣＩＤを割り当てる一例を説明した。ｅＮＢ２００は、ＵＥ１００−１とＵＥ１００−２との間で用いられるＬＣＩＤをＵＥ１００−１（及びＵＥ１００−２）へ割り当ててもよい。ｅＮＢ２００は、アダプテーションレイヤを介したパケットの伝送が許可されるＬＣＩＤをＵＥ１００−１（及びＵＥ１００−２）へ通知してもよい。ｅＮＢ２００は、アダプテーションレイヤを介したパケットの伝送が許可されないＬＣＩＤをＵＥ１００−１（及びＵＥ１００−２）へ通知してもよい。ＵＥ１００−１は、当該ＬＣＩＤをＵＥ１００−２へ通知してもよい。

ＵＥ１００−１は、アダプテーションレイヤを介したパケットの伝送が許可されるＬＣＩＤを用いて、ＵＥ１００−２からパケットを受けとった場合、アダプテーションレイヤを介したパケットの伝送であると把握できる。同様に、ＵＥ１００−２は、アダプテーションレイヤを介したパケットの伝送が許可されるＬＣＩＤを用いて、ＵＥ１００−１からパケットを受けとった場合、アダプテーションレイヤを介したパケットの伝送であると把握できる。

ＵＥ１００−１は、アダプテーションレイヤを介したパケットの伝送が許可されないＬＣＩＤを用いて、ＵＥ１００−２からパケットを受けとった場合、アダプテーションレイヤを介したパケットの伝送でないと把握できる。同様に、ＵＥ１００−２は、アダプテーションレイヤを介したパケットの伝送が許可されないＬＣＩＤを用いて、ＵＥ１００−１からパケットを受けとった場合、アダプテーションレイヤを介したパケットの伝送でないと把握できる。

ＵＥ１００−１及びＵＥ１００−２は、パケットに含まれるＬＣＩＤにより、アダプテーションレイヤを介したパケットの伝送であるか否かを把握してもよい。

ＵＥ１００−１及びＵＥ１００−２は、アダプテーションレイヤを介したパケットの伝送が許可されないＬＣＩＤを、端末間で完結する通信（中継されないパケットの通信）に利用してもよい。

上述の動作例６では、ＤＲＢで伝送すべきパケットの優先度の把握方法について説明した。同様にして、ＳＲＢ（Ｓｉｇｎａｌｌｉｎｇ Ｒａｄｉｏ Ｂｅａｒｅｒ）で伝送すべきパケットの優先度が把握されてもよい。ＳＲＢで伝送すべきパケットは、例えば、ＵＥ１００−１とｅＮＢ２００の間で送信（受信）される制御情報である。ＳＲＢで伝送すべきパケットは、ＵＥ１００−１とＭＭＥ３００の間で送信（受信）される制御情報であってもよい。ＳＲＢで伝送すべきパケットは、ＤＲＢで伝送すべきパケットよりも優先される必要があってもよい。

ｅＮＢ２００は、ＳＲＢで伝送すべきパケットとＤＲＢで伝送すべきパケットとを区別できるように、ＤＲＢ ＩＤを指定する情報をＵＥ１００−２（ＵＥ１００−２）へ提供してもよい。例えば、ｅＮＢ２００は、ＳＲＢで伝送すべきパケットには”ＤＲＢ ＩＤ ４”を指定してもよい。ｅＮＢ２００は、ＤＲＢで伝送すべきパケットにはそれ以外のＤＲＢ（例えばＤＲＢ ５）を指定してもよい。ｅＮＢ２００は、識別情報と優先度とが対応付けられたリストをＵＥ１００−２へ提供してもよい。例えば、ＳＲＢで伝送すべきＤＲＢ ＩＤと高優先度とが対応付けられてもよい。

ｅＮＢ２００は、ＳＲＢで伝送されるべきパケットを、ＵＥ１００−１とｅＮＢ２００間で使用中のＳＲＢで伝送するよう指定してもよい。ＵＥ１００−１は、あたかも自身の制御信号（制御パケット）であるかのようにＵＥ１００−２から受信したパケットを送信してもよい。

ｅＮＢ２００は、ＳＲＢで伝送されるべきパケットについては、ＵＥ１００−１が送信する制御信号として扱うように、Ｕ１００−１に対して設定してもよい。ＵＥ１００−１は、ＵＥ１００−２からＳＲＢで伝送されるべきパケットを受信した場合、自身の制御信号内のパラメータとして受信したパケットを格納してもよい。ＵＥ１００−１は、格納したＵＥ１００−２からのパケットを自身の制御信号としてｅＮＢ２００との間に確立されたＳＲＢで送信してもよい。ＵＥ１００−１は、ＵＥ１００−２からのパケットと共に、受信したＵＥ１００−２の識別子も合わせて制御信号内に格納してもよい。

以上のように、制御パケットとユーザデータパケットとの優先度が区別されてもよい。これにより、制御信号（制御パケット）とデータ（ユーザデータパケット）との優先度を区別して把握することができる。

上述したアダプテーションレイヤは、既存のＬＴＥシステムのプロトコルに存在しない新規レイヤであってもよい。アダプテーションレイヤは、ＬＴＥシステム上のプロトコルに存在するレイヤ（例えばＰＤＣＰ）の機能が拡張されたものであってもよい。従って、アダプテーションレイヤにおける動作として説明した内容は、例えば、（拡張された）ＰＤＣＰレイヤにおける動作であってもよい。

上述した実施形態に係る動作（動作例）は、適宜組み合わせて実行されてもよい。上述した各シーケンスにおいて、必ずしも全ての動作が必須の構成ではない。例えば、各シーケンスにおいて、一部の動作のみが実行されてもよい。

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

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

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

［付記］
（検討）
リリース１３では、Ｌ３ ＰｒｏＳｅ ＵＥ−ｔｏ−ＮＷリレー（Ｌ３リレー）が仕様化される。Ｌ３リレーの場合、リレーＵＥは、どのＱｏＳがリモートＵＥから受信されたトラフィックに適用されるか識別でき、どの受信トラフィックがどのリモートＵＥ宛であるかをＩＰパケット内のヘッダに基づいて識別できる。従って、リレーＵＥによって使用され、リモートＵＥのトラフィックの関連するＱｏＳを識別するために使用できるＡＳ（Ａｃｃｅｓｓ Ｓｔｒａｔｕｍ）機能はなく、ｅＮＢからのどのトラフィックが特定のリモートＵＥのためであるかをリレーＵＥが識別するための既存の方法も存在しない。しかしながら、ｅＮＢがＬ３リレー動作のためにリモートＵＥを識別する必要はない。

従って、Ｌ２ ＰｒｏＳｅ ＵＥ−ｔｏ−ＮＷ Ｒｅｌａｙでは、短距離インタフェースでリモートＵＥからのトラフィックのＱｏＳがどのように識別され（図２５）、且つ、Ｕｕインタフェース上のトラフィックにマッピングされたリモートＵＥがどのように識別されるかを検討する必要がある（図２６）。

（１）短距離インタフェース
（１．１）ＱｏＳ識別
リモートＵＥのトラフィックからＱｏＳを識別するいくつかのソリューションがあり、大部分の企業は、短距離インタフェースが非３ＧＰＰアクセスである場合に有益であるべきであるアダプテーションレイヤの導入を検討している。しかしながら、３ＧＰＰアクセスに関しては、アダプテーションレイヤを導入する必要があるかどうかのコンセンサスはない、すなわち、ｅＮＢがＳｉｄｅｌｉｎｋ 無線ベアラ（ＳＬＲＢ）とＵｕ ＤＲＢ間のマッピングを設定し、リレーＵＥが、サイドリンク上のＬＣＩＤに基づいてリモートＵＥのトラフィックに適したＵｕ ＤＲＢを識別することをいくつかの企業が提案している。アダプテーションレイヤの導入と、ＳＬ ＬＣＩＤのＵｕ ＤＲＢへのマッピングの導入は両方とも実行可能である、しかしながら、目的の１つは、「次のユースケースをサポートする共通のソリューションの可能性を検討することである。（i）非３ＧＰＰアクセス上でのＵＥ−ｔｏ−ネットワーク中継。（ii）ＬＴＥサイドリンク上でのＵＥ−ｔｏ−ネットワーク中継。．．．（省略）」である。従って、短距離インタフェース上でのＱｏＳ識別は、例えば、アダプテーションレイヤの導入、例えば、アダプテーションレイヤ又はＰＤＣＰレイヤの拡張を用いて、ＲＬＣレイヤ上で達成されるべきである。

提案１： ３ＧＰＰアクセスと非３ＧＰＰアクセスの両方に共通のソリューションを導入するために、短距離インタフェース上のＱｏＳ識別は、例えば、アダプテーションレイヤ又はＰＤＣＰレイヤの拡張を用いて、ＲＬＣレイヤで達成されるべきである。

（１．２）トラフィックアドレスの区別（リレーＵＥ又はｅＮＢ）
短距離インタフェースとして非３ＧＰＰアクセスが使用される場合、リレーＵＥは、Ｌ２リレーのための新しいプロトコルが使用されるべきかどうかをリレーＵＥが知る必要があるので、リモートＵＥのトラフィックがリレーＵＥ用かｅＮＢ用かを知る必要がある。ＵＥのトラフィックのアドレスを区別する方法の１つは、リモートＵＥがｅＮＢとのＬ２リレー接続を確立した場合、リモートＵＥがリレーＵＥへ送信するために常に新しいプロトコルを使用するというルールを導入することである。その結果として、リモートＵＥは、トラフィックが、新しいプロトコルにおいて、リレーＵＥ宛てかｅＮＢ宛てかを示すことができ、例えば、トラフィックが、アダプテーションレイヤのヘッダ又は拡張ＰＤＣＰヘッダにおいてｅＮＢのためのものであるかどうかを示すことができる。別の方法は、非３ＧＰＰアクセスを介したＬ２リレーに「ＬＷＡ ＥｔｈｅｒＴｙｐｅ」と同様のメカニズムを導入することである。ＬＷＡでは、データがＷＬＡＮを介してＵＥに転送されるとき、ＷＴ（ＷＬＡＮ Ｔｅｒｍｉｎａｔｉｏｎ）は、「ＬＷＡ ＥｔｈｅｒＴｙｐｅ」を使用して、ＵＥにＬＷＡ操作に関連するデータの到着を通知する。従って、非３ＧＰＰアクセスを介したＬ２リレーに、同様のメカニズムを導入することは有効であるだろう。３ＧＰＰアクセスにも同じ問題が存在する。従って、常に新しいプロトコルを使用するルール又はＬ２リレートラフィックを識別するためのインディケーションが必要だろう。

提案２：ＲＡＮ２は、短距離インタフェース上のトラフィックのアドレスを区別する方法について検討すべきである。

（２）Ｕｕインターフェイス
（２．１）リモートＵＥ識別
リモートＵＥ識別のためのいくつかのソリューションがあり、例えば、新しいＭＡＣ ＣＥを導入すること、ＲＬＣヘッダを拡張すること、アダプテーションレイヤを導入すること、そして、ＰＤＣＰヘッダを拡張することがある。送信側／受信側のリモートＵＥを識別するポイントでは、すべてのソリューションが実行可能である。しかしながら、ＭＡＣ ＣＥのソリューションに関して、スケジューリング／ＬＣＰ（Ｌｉｎｋ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）の柔軟性を可能にするために、Ｕｕ上でのリモートＵＥ識別のためのソリューションは、異なるリモートＵＥのトラフィックをＭＡＣ ＰＤＵに多重化することを可能にすべきことが有用である。

提案３：ＲＡＮ２は、異なるリモートＵＥのトラフィックをＭＡＣ ＰＤＵに多重化することを可能にする、Ｕｕインタフェース上のリモートＵＥ識別のためのソリューションを導入すべきである。

（２．２）異なるＱｏＳを持つ複数のＵｕ ＤＲＢ
Ｕｕ上のベアラモデリングに関して、「Ｕｕ上の単一のＤＲＢにマッピングされた複数のリモートＵＥを有する単一のＵｕ ＤＲＢモデル」が検討されている。多数のリモートＵＥをサポートするための複雑さを制限する観点から、単一のＵｕ ＤＲＢモデルが適していると思われる。しかしながら、リモートＵＥから／へのトラフィックのＱｏＳ処理に関して、異なるＱｏＳに対して複数のＵｕ ＤＲＢを構成するオプションを有することは有益である。リモートＵＥは、スマートウォッチ、心拍モニタ、ＶＲ（Ｖｉｒｔｕａｌ Ｒｅａｌｉｔｙ）メガネなどの異なる形態で実現可能であると想定できるので、一般にリモートＵＥは、様々なトラフィックを利用することが期待される。

提案４：リモートＵＥから／へのトラフィックに対するＱｏＳ処理に関して、異なるＱｏＳに対して複数のＵｕ ＤＲＢを構成するオプションを有することは有益である。

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

Claims (3)

1. 第１の無線端末が、レイヤ２のうちＲａｄｉｏ Ｌｉｎｋ Ｃｏｎｔｒｏｌ（ＲＬＣ）レイヤよりも上位レイヤにおいて第２の無線端末と基地局との間で前記第２の無線端末のパケットが伝送されるレイヤ２中継を実行する通信方法であって、
   前記第１の無線端末が、前記第１の無線端末が前記レイヤ２中継を可能であること示す情報を送信し、
   前記第２の無線端末が、前記情報の受信に応じて、前記レイヤ２中継のための要求を前記第１の無線端末へ送信する通信方法。
2. 前記レイヤ２中継では、前記ＲＬＣレイヤよりも上位レイヤであり、かつ、Ｐａｃｋｅｔ Ｄａｔａ Ｃｏｎｖｅｒｇｅｎｃｅ Ｐｒｏｔｏｃｏｌ（ＰＤＣＰ）レイヤと異なる特別なレイヤにおいて前記パケットの処理が実行され、
   前記基地局及び前記第２の無線端末は、前記特別なレイヤよりも下位レイヤにおいて、前記特別なレイヤで前記パケットが処理されたことを示す情報を前記パケットに含める請求項１に記載の通信方法。
3. 前記レイヤ２中継では、前記ＲＬＣレイヤよりも上位レイヤであり、かつ、Ｐａｃｋｅｔ Ｄａｔａ Ｃｏｎｖｅｒｇｅｎｃｅ Ｐｒｏｔｏｃｏｌ（ＰＤＣＰ）レイヤと異なる特別なレイヤにおいて前記パケットの処理が実行され、
   前記基地局が、前記特別なレイヤを介したパケットの伝送が許可される論理チャネル識別子を前記第１の無線端末へ通知する請求項１に記載の通信方法。

Images