(57)【特許請求の範囲】
【請求項１】
第１の無線端末が、レイヤ２のうちＲａｄｉｏ  Ｌｉｎｋ  Ｃｏｎｔｒｏｌ（ＲＬＣ）レイヤよりも上位レイヤにおいて第２の無線端末と基地局との間で前記第２の無線端末のパケットが伝送されるレイヤ２中継を実行する通信方法であって、
前記第１の無線端末が、前記第１の無線端末が前記レイヤ２中継を可能であること示す情報を送信し、
前記第２の無線端末が、前記情報の受信に応じて、前記レイヤ２中継のための要求を前記第１の無線端末へ送信する通信方法。
【請求項２】
前記レイヤ２中継では、前記ＲＬＣレイヤよりも上位レイヤであり、かつ、Ｐａｃｋｅｔ  Ｄａｔａ  Ｃｏｎｖｅｒｇｅｎｃｅ  Ｐｒｏｔｏｃｏｌ（ＰＤＣＰ）レイヤと異なる特別なレイヤにおいて前記パケットの処理が実行され、
前記基地局及び前記第２の無線端末は、前記特別なレイヤよりも下位レイヤにおいて、前記特別なレイヤで前記パケットが処理されたことを示す情報を前記パケットに含める請求項１に記載の通信方法。
【請求項３】
前記レイヤ２中継では、前記ＲＬＣレイヤよりも上位レイヤであり、かつ、Ｐａｃｋｅｔ  Ｄａｔａ  Ｃｏｎｖｅｒｇｅｎｃｅ  Ｐｒｏｔｏｃｏｌ（ＰＤＣＰ）レイヤと異なる特別なレイヤにおいて前記パケットの処理が実行され、
前記基地局が、前記特別なレイヤを介したパケットの伝送が許可される論理チャネル識別子を前記第１の無線端末へ通知する請求項１に記載の通信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、通信方法に関する。
【背景技術】
【０００２】
移動通信システムの標準化プロジェクトである３ＧＰＰ（３ｒｄ  Ｇｅｎｅｒａｔｉｏｎ  Ｐａｒｔｎｅｒｓｈｉｐ  Ｐｒｏｊｅｃｔ）において、近傍サービス（ＰｒｏＳｅ：Ｐｒｏｘｉｍｉｔｙ−ｂａｓｅｄ  Ｓｅｒｖｉｃｅｓ）の仕様策定が進められている（非特許文献１参照）。【０００３】
ＰｒｏＳｅでは、特定の無線端末（ＰｒｏＳｅ  ＵＥ−ｔｏ−Ｎｅｔｗｏｒｋ  Ｒｅｌａｙ）は、他の無線端末（Ｒｅｍｏｔｅ  ＵＥ）とネットワークとの間でトラフィックを中継することが可能である。
【先行技術文献】
【非特許文献】
【０００４】
【非特許文献１】３ＧＰＰ技術仕様書「ＴＳ３６．３００  Ｖ１３．５．０」  ２０１６年９月２９日
【発明の概要】
【０００５】
一の実施形態に係る通信方法は、第１の無線端末が、レイヤ２のうちＲａｄｉｏ  Ｌｉｎｋ  Ｃｏｎｔｒｏｌ（ＲＬＣ）レイヤよりも上位レイヤにおいて第２の無線端末と基地局との間で前記第２の無線端末のパケットが伝送されるレイヤ２中継を実行する通信方法である。前記第１の無線端末が、前記第１の無線端末が前記レイヤ２中継を可能であること示す情報を送信する。前記第２の無線端末が、前記情報の受信に応じて、前記レイヤ２中継のための要求を前記第１の無線端末へ送信する。
【０００６】
一の実施形態では、第１の無線端末が、レイヤ２のうちＲａｄｉｏ  Ｌｉｎｋ  Ｃｏｎｔｒｏｌ（ＲＬＣ）レイヤよりも上位レイヤにおいて第２の無線端末と基地局との間で前記第２の無線端末のパケットが伝送されるレイヤ２中継を実行する通信方法である。前記基地局が、前記第１の無線端末及び前記第２の無線端末へ、優先度に対応付けられた複数の論理チャネル識別子を通知する。前記複数の論理チャネル識別子は、前記第１の無線端末と前記第２の無線端末との間で前記パケットを伝送するために用いられる。前記第２の無線端末が、前記パケットを前記第１の無線端末へ送信するために、前記複数の論理チャネル識別子の中から、前記パケットの優先度に対応する論理チャネル識別子を選択する。
【０００７】
一の実施形態では、第１の無線端末が、レイヤ２のうちＲａｄｉｏ  Ｌｉｎｋ  Ｃｏｎｔｒｏｌ（ＲＬＣ）レイヤよりも上位レイヤにおいて第２の無線端末と基地局との間で前記第２の無線端末のパケットが伝送されるレイヤ２中継を実行する通信方法である。前記基地局が、前記第１の無線端末及び前記第２の無線端末へ、優先度に対応付けられた複数の識別情報を通知する。前記第２の無線端末が、前記複数の識別情報の中から、前記パケットの優先度に対応する識別情報を選択する。前記第２の無線端末が、前記パケットを前記第１の無線端末へ送信するために、前記選択された識別情報を含むヘッダが付与された前記パケットを生成する。
【０００８】
一の実施形態では、第１の無線端末が、レイヤ２のうちＲａｄｉｏ  Ｌｉｎｋ  Ｃｏｎｔｒｏｌ（ＲＬＣ）レイヤよりも上位レイヤにおいて第２の無線端末と基地局との間で前記第２の無線端末のパケットが伝送されるレイヤ２中継を実行する通信方法である。前記基地局が、前記第２の無線端末のパケット専用の論理チャネル識別子を決定する。前記論理チャネル識別子は、前記第１の無線端末と前記基地局との間で前記パケットを伝送するために用いられる。
【０００９】
一の実施形態では、第１の無線端末が、レイヤ２のうちＲａｄｉｏ  Ｌｉｎｋ  Ｃｏｎｔｒｏｌ（ＲＬＣ）レイヤよりも上位レイヤにおいて第２の無線端末と基地局との間で前記第２の無線端末のパケットが伝送されるレイヤ２中継を実行する通信方法である。前記基地局が、前記第２の無線端末へ割り当てたＲａｄｉｏ  Ｎｅｔｗｏｒｋ  Ｔｅｍｐｏｒａｒｙ  Ｉｄｅｎｔｉｆｉｅｒ（ＲＮＴＩ）を前記第１の無線端末へ通知する。前記第１の無線端末は、前記基地局から受信したパケットのうち、前記ＲＮＴＩを用いてデコードに成功したパケットを前記第２の無線端末のパケットと判定する。
【図面の簡単な説明】
【００１０】
【図１】図１は、ＬＴＥシステムの構成を示す図である。
【図２】図２は、ＬＴＥシステムにおける無線インターフェイスのプロトコルスタック図である。
【図３】図３は、ＬＴＥシステムで使用される無線フレームの構成図である。
【図４】図４は、レイヤ２中継の一例を説明するための図である。
【図５】図５は、レイヤ２中継の一例を説明するための図である。
【図６】図６は、ＵＥ１００のブロック図である。
【図７】図７は、ｅＮＢ２００のブロック図である。
【図８】図８は、動作例１を説明するためのシーケンス図である。
【図９】図９は、動作例２を説明するためのシーケンス図である。
【図１０】図１０は、動作例３を説明するためのフローチャートである。
【図１１】図１１は、動作例３を説明するための図である。
【図１２】図１２は、動作例３を説明するためのフローチャートである。
【図１３】図１３は、動作例４を説明するためのフローチャートである。
【図１４】図１４は、動作例５を説明するための図である。
【図１５】図１５は、動作例５を説明するためのシーケンス図である。
【図１６】図１６は、動作例６を説明するためのシーケンス図である。
【図１７】図１７は、動作例６を説明するための図である。
【図１８】図１８は、動作例６を説明するための図である。
【図１９】図１９は、動作例７を説明するための図である。
【図２０】図２０は、動作例７を説明するためのフローチャートである。
【図２１】図２１は、動作例７を説明するための図である。
【図２２】図２２は、動作例７を説明するための図である。
【図２３】図２３は、動作例８を説明するためのフローチャートである。
【図２４】図２４は、動作例９を説明するためのフローチャートである。
【図２５】図２５は、短距離インターフェイスにおけるＱｏＳ識別の問題を説明するための図である。
【図２６】図２６は、ＵｕインターフェイスにおけるリモートＵＥ識別の問題を説明するための図である。
【発明を実施するための形態】
【００１１】
［実施形態の概要］
近年、レイヤ２中継について議論されている。レイヤ２中継では、レイヤ２のうちＲａｄｉｏ  Ｌｉｎｋ  Ｃｏｎｔｒｏｌ（ＲＬＣ）レイヤよりも上位レイヤにおいて、無線端末（Ｒｅｍｏｔｅ  ＵＥ）のパケットが、特定の無線端末（ＰｒｏＳｅ  ＵＥ−ｔｏ−Ｎｅｔｗｏｒｋ  Ｒｅｌａｙ）を介して、無線端末（Ｒｅｍｏｔｅ  ＵＥ）と基地局（ネットワーク）との間で伝送（中継）される。
【００１２】
しかしながら、レイヤ２中継を適切に制御するための仕組みが存在しないため、レイヤ２中継が適切に実行されない可能性がある。
【００１３】
一の実施形態に係る通信方法は、第１の無線端末が、レイヤ２のうちＲａｄｉｏ  Ｌｉｎｋ  Ｃｏｎｔｒｏｌ（ＲＬＣ）レイヤよりも上位レイヤにおいて第２の無線端末と基地局との間で前記第２の無線端末のパケットが伝送されるレイヤ２中継を実行する通信方法である。前記第１の無線端末が、前記第１の無線端末が前記レイヤ２中継を可能であること示す情報を送信する。前記第２の無線端末が、前記情報の受信に応じて、前記レイヤ２中継のための要求を前記第１の無線端末へ送信する。
【００１４】
前記レイヤ２中継では、前記ＲＬＣレイヤよりも上位レイヤであり、かつ、Ｐａｃｋｅｔ  Ｄａｔａ  Ｃｏｎｖｅｒｇｅｎｃｅ  Ｐｒｏｔｏｃｏｌ（ＰＤＣＰ）レイヤと異なる特別なレイヤにおいて前記パケットの処理が実行されてもよい。前記基地局及び前記第２の無線端末は、前記特別なレイヤよりも下位レイヤにおいて、前記特別なレイヤで前記パケットが処理されたことを示す情報を前記パケットに含めてもよい。
【００１５】
前記レイヤ２中継では、前記ＲＬＣレイヤよりも上位レイヤであり、かつ、Ｐａｃｋｅｔ  Ｄａｔａ  Ｃｏｎｖｅｒｇｅｎｃｅ  Ｐｒｏｔｏｃｏｌ（ＰＤＣＰ）レイヤと異なる特別なレイヤにおいて前記パケットの処理が実行されてもよい。前記基地局が、前記特別なレイヤを介したパケットの伝送が許可される論理チャネル識別子を前記第１の無線端末へ通知してもよい。
【００１６】
一の実施形態では、第１の無線端末が、レイヤ２のうちＲａｄｉｏ  Ｌｉｎｋ  Ｃｏｎｔｒｏｌ（ＲＬＣ）レイヤよりも上位レイヤにおいて第２の無線端末と基地局との間で前記第２の無線端末のパケットが伝送されるレイヤ２中継を実行する通信方法である。前記基地局が、前記第１の無線端末及び前記第２の無線端末へ、優先度に対応付けられた複数の論理チャネル識別子を通知する。前記複数の論理チャネル識別子は、前記第１の無線端末と前記第２の無線端末との間で前記パケットを伝送するために用いられる。前記第２の無線端末が、前記パケットを前記第１の無線端末へ送信するために、前記複数の論理チャネル識別子の中から、前記パケットの優先度に対応する論理チャネル識別子を選択する。
【００１７】
一の実施形態では、第１の無線端末が、レイヤ２のうちＲａｄｉｏ  Ｌｉｎｋ  Ｃｏｎｔｒｏｌ（ＲＬＣ）レイヤよりも上位レイヤにおいて第２の無線端末と基地局との間で前記第２の無線端末のパケットが伝送されるレイヤ２中継を実行する通信方法である。前記基地局が、前記第１の無線端末及び前記第２の無線端末へ、優先度に対応付けられた複数の識別情報を通知する。前記第２の無線端末が、前記複数の識別情報の中から、前記パケットの優先度に対応する識別情報を選択する。前記第２の無線端末が、前記パケットを前記第１の無線端末へ送信するために、前記選択された識別情報を含むヘッダが付与された前記パケットを生成する。
【００１８】
前記選択された識別情報は、前記第１の無線端末とネットワークとの間に確立されるベアラの識別子であってもよい。
【００１９】
前記選択された識別情報は、前記第１の無線端末と前記基地局との間で前記パケットを伝送するために用いられる論理チャネル識別子であってもよい。
【００２０】
前記ヘッダは、前記第２の無線端末の識別子をさらに含んでもよい。
【００２１】
一の実施形態では、第１の無線端末が、レイヤ２のうちＲａｄｉｏ  Ｌｉｎｋ  Ｃｏｎｔｒｏｌ（ＲＬＣ）レイヤよりも上位レイヤにおいて第２の無線端末と基地局との間で前記第２の無線端末のパケットが伝送されるレイヤ２中継を実行する通信方法である。前記基地局が、前記第２の無線端末のパケット専用の論理チャネル識別子を決定する。前記論理チャネル識別子は、前記第１の無線端末と前記基地局との間で前記パケットを伝送するために用いられる。
【００２２】
一の実施形態では、第１の無線端末が、レイヤ２のうちＲａｄｉｏ  Ｌｉｎｋ  Ｃｏｎｔｒｏｌ（ＲＬＣ）レイヤよりも上位レイヤにおいて第２の無線端末と基地局との間で前記第２の無線端末のパケットが伝送されるレイヤ２中継を実行する通信方法である。前記基地局が、前記第２の無線端末へ割り当てたＲａｄｉｏ  Ｎｅｔｗｏｒｋ  Ｔｅｍｐｏｒａｒｙ  Ｉｄｅｎｔｉｆｉｅｒ（ＲＮＴＩ）を前記第１の無線端末へ通知する。前記第１の無線端末は、前記基地局から受信したパケットのうち、前記ＲＮＴＩを用いてデコードに成功したパケットを前記第２の無線端末のパケットと判定する。
【００２３】
前記第２の基地局は、前記第１の無線端末から受信したパケットのうち、前記ＲＮＴＩを用いてデコードに成功したパケットを前記第２の無線端末のパケットと判定してもよい。
【００２４】
［実施形態］
（移動通信システム）
以下において、実施形態に係る移動通信システムであるＬＴＥシステムについて説明する。図１は、ＬＴＥシステムの構成を示す図である。
【００２５】
図１に示すように、ＬＴＥシステムは、ＵＥ（Ｕｓｅｒ  Ｅｑｕｉｐｍｅｎｔ）１００、Ｅ−ＵＴＲＡＮ（Ｅｖｏｌｖｅｄ  Ｕｎｉｖｅｒｓａｌ  Ｔｅｒｒｅｓｔｒｉａｌ  Ｒａｄｉｏ  Ａｃｃｅｓｓ  Ｎｅｔｗｏｒｋ）１０、及びＥＰＣ（Ｅｖｏｌｖｅｄ  Ｐａｃｋｅｔ  Ｃｏｒｅ）２０を備える。
【００２６】
ＵＥ１００は、通信装置（無線端末）に相当する。ＵＥ１００は、移動型の通信装置である。ＵＥ１００は、セル（後述するｅＮＢ２００）と無線通信を行う。ＵＥ１００の構成については後述する。
【００２７】
Ｅ−ＵＴＲＡＮ１０は、無線アクセスネットワークに相当する。Ｅ−ＵＴＲＡＮ１０は、ｅＮＢ２００（ｅｖｏｌｖｅｄ  Ｎｏｄｅ−Ｂ）を含む。ｅＮＢ２００は、基地局に相当する。ｅＮＢ２００は、Ｘ２インターフェイスを介して相互に接続される。ｅＮＢ２００の構成は後述する。
【００２８】
ｅＮＢ２００は、１又は複数のセルを管理する。ｅＮＢ２００は、ｅＮＢ２００が管理するセルとの接続を確立したＵＥ１００との無線通信を行う。ｅＮＢ２００は、無線リソース管理（ＲＲＭ）機能、ユーザデータ（以下、「データ」と称することがある）のルーティング機能、モビリティ制御・スケジューリングのための測定制御機能等を有する。「セル」は、無線通信エリアの最小単位を示す用語として使用される。「セル」は、ＵＥ１００との無線通信を行う機能を示す用語としても使用されてもよい。
【００２９】
ＥＰＣ２０は、コアネットワークに相当する。ＥＰＣ２０は、Ｅ−ＵＴＲＡＮ１０と共にネットワークを構成してもよい。ＥＰＣ２０は、ＭＭＥ（Ｍｏｂｉｌｉｔｙ  Ｍａｎａｇｅｍｅｎｔ  Ｅｎｔｉｔｙ）３００、及びＳＧＷ（Ｓｅｒｖｉｎｇ  Ｇａｔｅｗａｙ）４００、及びＰＧＷ（Ｐａｃｋｅｔ  ｄａｔａ  Ｎｅｔｗｏｒｋ  Ｇａｔｅｗａｙ）５００を含む。
【００３０】
ＭＭＥ３００は、例えば、ＵＥ１００に対する各種モビリティ制御を行う。ＳＧＷ４００は、例えば、データの転送制御を行う。ＭＭＥ３００及びＳＧＷ４００は、Ｓ１インターフェイスを介してｅＮＢ２００と接続される。ＰＧＷ５００は、外部ネットワークから（及び外部ネットワークに）ユーザデータを中継する制御を行う。
【００３１】
図２は、ＬＴＥシステムにおける無線インターフェイスのプロトコルスタック図である。図２に示すように、無線インターフェイスプロトコルは、ＯＳＩ参照モデルの第１層（レイヤ１）乃至第３層（レイヤ３）に区分されている。第１層は、物理（ＰＨＹ）層（物理レイヤ）である。第２層（レイヤ２）は、ＭＡＣ（Ｍｅｄｉｕｍ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ）層（ＭＡＣレイヤ）、ＲＬＣ（Ｒａｄｉｏ  Ｌｉｎｋ  Ｃｏｎｔｒｏｌ）層（ＲＬＣレイヤ）、及びＰＤＣＰ（Ｐａｃｋｅｔ  Ｄａｔａ  Ｃｏｎｖｅｒｇｅｎｃｅ  Ｐｒｏｔｏｃｏｌ）層（ＰＲＣＰレイヤ）を含む。第３層（レイヤ３）は、ＲＲＣ（Ｒａｄｉｏ  Ｒｅｓｏｕｒｃｅ  Ｃｏｎｔｒｏｌ）層（ＲＲＣレイヤ）を含む。
【００３２】
物理レイヤは、符号化・復号化、変調・復調、アンテナマッピング・デマッピング、及びリソースマッピング・デマッピングを行う。ＵＥ１００の物理レイヤとｅＮＢ２００の物理レイヤとの間では、物理チャネルを介してデータ及び制御信号が伝送される。
【００３３】
ＭＡＣレイヤは、データの優先制御、ハイブリッドＡＲＱ（ＨＡＲＱ）による再送処理、及びランダムアクセス手順等を行う。ＵＥ１００のＭＡＣレイヤとｅＮＢ２００のＭＡＣレイヤとの間では、トランスポートチャネルを介してデータ及び制御信号が伝送される。ｅＮＢ２００のＭＡＣレイヤは、スケジューラ（ＭＡＣ  スケジューラ）を含む。スケジューラは、上下リンクのトランスポートフォーマット（トランスポートブロックサイズ、変調・符号化方式（ＭＣＳ：Ｍｏｄｕｌａｔｉｏｎ  ａｎｄ  Ｃｏｄｉｎｇ  Ｓｃｈｅｍｅ））及びＵＥ１００への割当リソースブロックを決定する。
【００３４】
ＲＬＣレイヤは、ＭＡＣレイヤ及び物理レイヤの機能を利用してデータを受信側のＲＬＣレイヤに伝送する。ＵＥ１００のＲＬＣレイヤとｅＮＢ２００のＲＬＣレイヤとの間では、論理チャネルを介してデータ及び制御信号が伝送される。
【００３５】
ＰＤＣＰレイヤは、ヘッダ圧縮・伸張、及び暗号化・復号化を行う。
【００３６】
ＲＲＣレイヤは、制御信号を取り扱う制御プレーンでのみ定義される。ＵＥ１００のＲＲＣレイヤとｅＮＢ２００のＲＲＣレイヤとの間では、各種設定のためのメッセージ（ＲＲＣメッセージ）が伝送される。ＲＲＣレイヤは、無線ベアラの確立、再確立及び解放に応じて、論理チャネル、トランスポートチャネル、及び物理チャネルを制御する。ＵＥ１００のＲＲＣとｅＮＢ２００のＲＲＣとの間にＲＲＣ接続がある場合、ＵＥ１００は、ＲＲＣコネクティッド状態である。ＵＥ１００のＲＲＣとｅＮＢ２００のＲＲＣとの間にＲＲＣ接続がない場合、ＵＥ１００は、ＲＲＣアイドル状態である。
【００３７】
ＲＲＣレイヤの上位に位置するＮＡＳ（Ｎｏｎ−Ａｃｃｅｓｓ  Ｓｔｒａｔｕｍ）レイヤは、例えば、セッション管理及びモビリティ管理を行う。
【００３８】
図３は、ＬＴＥシステムで使用される無線フレームの構成図である。ＬＴＥシステムにおいて、下りリンクにはＯＦＤＭＡ（Ｏｒｔｈｏｇｏｎａｌ  Ｆｒｅｑｕｅｎｃｙ  Ｄｉｖｉｓｉｏｎ  Ｍｕｌｔｉｐｌｅ  Ａｃｃｅｓｓ）が適用される。上りリンクにはＳＣ−ＦＤＭＡ（Ｓｉｎｇｌｅ  Ｃａｒｒｉｅｒ  Ｆｒｅｑｕｅｎｃｙ  Ｄｉｖｉｓｉｏｎ  Ｍｕｌｔｉｐｌｅ  Ａｃｃｅｓｓ）が適用される。
【００３９】
図３に示すように、無線フレームは、時間方向に並ぶ１０個のサブフレームで構成される。各サブフレームは、時間方向に並ぶ２個のスロットで構成される。各サブフレームの長さは１ｍｓである。各スロットの長さは０．５ｍｓである。各サブフレームは、周波数方向に複数のリソースブロック（ＲＢ：Ｒｅｓｏｕｒｃｅ  Ｂｌｏｃｋ）を含む。各サブフレームは、時間方向に複数のシンボルを含む。各リソースブロックは、周波数方向に複数のサブキャリアを含む。１つのシンボル及び１つのサブキャリアにより、１つのリソースエレメント（ＲＥ：Ｒｅｓｏｕｒｃｅ  Ｅｌｅｍｅｎｔ）が構成される。ＵＥ１００には、無線リソース（時間・周波数リソース）が割り当てられる。周波数方向において、無線リソース（周波数リソース）は、リソースブロックにより構成される。時間方向において、無線リソース（時間リソース）は、サブフレーム（又はスロット）により構成される。
【００４０】
下りリンクにおいて、各サブフレームの先頭数シンボルの区間は、下りリンク制御信号を伝送するための物理下りリンク制御チャネル（ＰＤＣＣＨ：Ｐｈｙｓｉｃａｌ  Ｄｏｗｎｌｉｎｋ．  Ｃｏｎｔｒｏｌ  Ｃｈａｎｎｅｌ）として使用可能な領域である。各サブフレームの残りの部分は、下りリンクデータを伝送するための物理下りリンク共有チャネル（ＰＤＳＣＨ：Ｐｈｙｓｉｃａｌ  Ｄｏｗｎｌｉｎｋ  Ｓｈａｒｅｄ  Ｃｈａｎｎｅｌ）として使用可能な領域である。
【００４１】
上りリンクにおいて、各サブフレームにおける周波数方向の両端部は、上りリンク制御信号を伝送するための物理上りリンク制御チャネル（ＰＵＣＣＨ：Ｐｈｙｓｉｃａｌ  Ｕｐｌｉｎｋ  Ｃｏｎｔｒｏｌ  Ｃｈａｎｎｅｌ）として使用可能な領域である。各サブフレームにおける残りの部分は、上りリンクデータを伝送するための物理上りリンク共有チャネル（ＰＵＳＣＨ：Ｐｈｙｓｉｃａｌ  Ｕｐｌｉｎｋ  Ｓｈａｒｅｄ  Ｃｈａｎｎｅｌ）として使用可能な領域である。
【００４２】
（近傍サービス）
近傍サービス（ＰｒｏＳｅ：Ｐｒｏｘｉｍｉｔｙ−ｂａｓｅｄ  Ｓｅｒｖｉｃｅｓ）について説明する。近傍サービスは、互いに近傍にある通信装置（例えば、ＵＥ１００）に基づいて３ＧＰＰシステムにより提供され得るサービスである。
【００４３】
ＰｒｏＳｅでは、ｅＮＢ２００を経由せずにノード間（例えば、ＵＥ間）で直接的な無線リンクを介して各種の無線信号が送受信される。ＰｒｏＳｅにおける直接的な無線リンクは、「サイドリンク（Ｓｉｄｅｌｉｎｋ）」と称される。
【００４４】
サイドリンクは、サイドリンク通信及びサイドリンクディスカバリのためのインターフェイス（例えば、ＵＥとＵＥとの間のインターフェイス）であってもよい。サイドリンク通信は、ＰｒｏＳｅ直接通信（以下、「直接通信」と適宜称する）を可能にする機能（ＡＳ  ｆｕｎｃｔｉｏｎａｌｉｔｙ）である。サイドリンクディスカバリは、ＰｒｏＳｅ直接ディスカバリ（以下、「直接ディスカバリ」と適宜称する）を可能にする機能（ＡＳ  ｆｕｎｃｔｉｏｎａｌｉｔｙ）である。
【００４５】
サイドリンクは、ＰＣ５インターフェイス（ＰＣ５接続）に対応する。ＰＣ５は、ＰｒｏＳｅ直接ディスカバリ、ＰｒｏＳｅ直接通信及びＰｒｏＳｅ  ＵＥ−ｔｏ−ネットワーク中継のための制御プレーン及びユーザプレーンのために用いられるＰｒｏＳｅ使用可能なＵＥ（ＰｒｏＳｅ−ｅｎａｂｌｅｄ  ＵＥ）間の参照ポイントである。
【００４６】
ＰｒｏＳｅは、「直接ディスカバリ（Ｄｉｒｅｃｔ  Ｄｉｓｃｏｖｅｒｙ）」及び「直接通信（Ｄｉｒｅｃｔ  Ｃｏｍｍｕｎｉｃａｔｉｏｎ）」及び「Ｒｅｌａｙ」のモードが規定されている。「Ｒｅｌａｙ」は後述する。
【００４７】
直接ディスカバリは、特定の宛先を指定しないディスカバリメッセージ（ディスカバリ信号）をＵＥ間で直接的に伝送することにより、相手先を探索するモードである。直接ディスカバリは、ＰＣ５を介してＥ−ＵＴＲＡ（Ｅｖｏｌｖｅｄ  Ｕｎｉｖｅｒｓａｌ  Ｔｅｒｒｅｓｔｒｉａｌ  Ｒａｄｉｏ  Ａｃｃｅｓｓ）における直接無線信号を用いて、ＵＥの近傍における他のＵＥを発見するための手順である。或いは、直接ディスカバリは、Ｅ−ＵＴＲＡ技術で２つのＵＥ１００の能力のみを用いて、近傍サービスを実行可能な他のＵＥ１００を発見するために近傍サービスを実行可能なＵＥ１００によって採用される手順である。直接ディスカバリは、ＵＥ１００がＥ−ＵＴＲＡＮ（ｅＮＢ２００（セル））によってサービスが提供される場合にのみ、サポートされる。ＵＥ１００は、セル（ｅＮＢ２００）に接続又はセルに在圏している場合、Ｅ−ＵＴＲＡＮによってサービスが提供され得る。
【００４８】
ディスカバリメッセージ（ディスカバリ信号）の送信（アナウンスメント）のためのリソース割り当てタイプには、「タイプ１」と「タイプ２（タイプ２Ｂ）」とがある。「タイプ１」では、ＵＥ１００が無線リソースを選択する。「タイプ２」では、ｅＮＢ２００が無線リソースを割り当てる。タイプ１では、ＵＥ１００は、ｅＮＢ２００から提供されたリソースプールの中から無線リソースを選択してもよい。
【００４９】
「Ｓｉｄｅｌｉｎｋ  Ｄｉｒｅｃｔ  Ｄｉｓｃｏｖｅｒｙ」プロトコルスタックは、物理（ＰＨＹ）レイヤ、ＭＡＣレイヤ、及びＰｒｏＳｅプロトコルを含む。ＵＥ（Ａ）の物理レイヤとＵＥ（Ｂ）の物理レイヤとの間では、物理サイドリンクディスカバリチャネル（ＰＳＤＣＨ）と称される物理チャネルを介してディスカバリ信号が伝送される。ＵＥ（Ａ）のＭＡＣレイヤとＵＥ（Ｂ）のＭＡＣレイヤとの間では、サイドリンクディスカバリチャネル（ＳＬ−ＤＣＨ）と称されるトランスポートチャネルを介してディスカバリ信号が伝送される。
【００５０】
直接通信は、特定の宛先（宛先グループ）を指定してデータをＵＥ間で直接的に伝送するモードである。直接通信は、いずれのネットワークノードを通過しない経路を介してＥ−ＵＴＲＡ技術を用いたユーザプレーン伝送による、近傍サービスを実行可能である２以上のＵＥ間の通信である。
【００５１】
直接通信のリソース割り当てタイプには、「モード１」と「モード２」とがある。「モード１」では、直接通信の無線リソースをｅＮＢ２００が指定する。「モード２」では、直接通信の無線リソースをＵＥ１００が選択する。モード２では、ＵＥ１００は、ｅＮＢ２００から提供されたリソースプールの中から無線リソースを選択してもよい。
【００５２】
直接通信プロトコルスタックは、物理（ＰＨＹ）レイヤ、ＭＡＣレイヤ、ＲＬＣレイヤ、及びＰＤＣＰレイヤを含む。ＵＥ（Ａ）の物理レイヤとＵＥ（Ｂ）の物理レイヤとの間では、物理サイドリンク制御チャネル（ＰＳＣＣＨ）を介して制御信号が伝送され、物理サイドリンク共有チャネル（ＰＳＳＣＨ）を介してデータが伝送される。物理サイドリンクブロードキャストチャネル（ＰＳＢＣＨ）を介して同期信号等が伝送されてもよい。ＵＥ（Ａ）のＭＡＣレイヤとＵＥ（Ｂ）のＭＡＣレイヤとの間では、サイドリンク共有チャネル（ＳＬ−ＳＣＨ）と称されるトランスポートチャネルを介してデータが伝送される。ＵＥ（Ａ）のＲＬＣレイヤとＵＥ（Ｂ）のＲＬＣレイヤとの間では、サイドリンクトラフィックチャネル（ＳＴＣＨ）と称される論理チャネルを介してデータが伝送される。
【００５３】
（レイヤ２中継（Ｌａｙｅｒ  ２  Ｒｅｌａｙ））
レイヤ２中継の概要について、図４及び図５を用いて説明する。図４は、レイヤ２中継の一例を説明するための図である。図５は、レイヤ２中継の一例を説明するための図である。
【００５４】
図４に示すように、レイヤ２中継において、ＵＥ１００−１は、中継端末（リレーＵＥ）である。ＵＥ１００−１は、ＵＥ１００−２とｅＮＢ２００（ネットワーク）との間で、ＵＥ１００−２のパケットを伝送（中継／転送）する。レイヤ２中継では、レイヤ２のうちＲＬＣレイヤよりも上位レイヤにおいてＵＥ１００（ＵＥ１００−２）のパケットが伝送（中継）される。レイヤ２中継では、レイヤ２のうち、ＰＤＣＰレイヤにおいてパケットの処理が実行されずに、ＵＥ１００（ＵＥ１００−２）のパケットが伝送されてもよい。
【００５５】
ＵＥ１００−１は、ＰｒｏＳｅ  ＵＥ−ｔｏ−Ｎｅｔｗｏｒｋ  Ｒｅｌａｙであってもよい。ＰｒｏＳｅ  ＵＥ−ｔｏ−Ｎｅｔｗｏｒｋ  Ｒｅｌａｙは、リモートＵＥ（Ｒｅｍｏｔｅ  ＵＥ）のためにネットワークへの接続性（ｃｏｎｎｅｃｔｉｖｉｔｙ）をサポートする機能を提供するＵＥであってもよい。
【００５６】
ＵＥ１００−２は、Ｒｅｍｏｔｅ  ＵＥであってもよい。Ｒｅｍｏｔｅ  ＵＥは、ＰｒｏＳｅ  ＵＥ−ｔｏ−Ｎｅｔｗｏｒｋ  Ｒｅｌａｙを介したＰＤＮ（Ｐａｃｋｅｔ  Ｄａｔａ  Ｎｅｔｗｏｒｋ）と通信するＵＥであってもよい。Ｒｅｍｏｔｅ  ＵＥは、ＰｒｏＳｅ−ｅｎａｂｌｅｄ  Ｐｕｂｌｉｃ  Ｓａｆｅｔｙ  ＵＥであってもよい。ＰｒｏＳｅ−ｅｎａｂｌｅｄ  Ｐｕｂｌｉｃ  Ｓａｆｅｔｙ  ＵＥは、ＨＰＬＭＮ（Ｈｏｍｅ  Ｐｕｂｌｉｃ  Ｌａｎｄ  Ｍｏｂｉｌｅ  Ｎｅｔｗｏｒｋ）が公衆安全用途（Ｐｕｂｌｉｃ  Ｓａｆｅｔｙ  ｕｓｅ）のために許可するように構成されたＵＥであってもよい。ＰｒｏＳｅ−ｅｎａｂｌｅｄ  Ｐｕｂｌｉｃ  Ｓａｆｅｔｙ  ＵＥは、ＰｒｏＳｅ可能（ＰｒｏＳｅ−ｅｎａｂｌｅｄ）であってもよい。ＰｒｏＳｅ−ｅｎａｂｌｅｄ  Ｐｕｂｌｉｃ  Ｓａｆｅｔｙ  ＵＥは、ＰｒｏＳｅ手順及び公衆安全に固有の能力をサポートしてもよい。ＰｒｏＳｅ−ｅｎａｂｌｅｄ  Ｐｕｂｌｉｃ  Ｓａｆｅｔｙ  ＵＥは、特別なアクセスクラスの一つと共にＵＳＩＭ（Ｕｎｉｖｅｒｓａｌ  Ｓｕｂｓｃｒｉｂｅｒ  Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ  Ｍｏｄｕｌｅ）を有していてもよい。
【００５７】
ＵＥ１００−１とＵＥ１００−２との間には、３ＧＰＰ（Ｔｈｉｒｄ  Ｇｅｎｅｒａｔｉｏｎ  Ｐａｒｔｎｅｒｓｈｉｐ  Ｐｒｏｊｅｃｔ）アクセス技術により接続が確立されてもよい。例えば、ＵＥ１００−１とＵＥ１００−２との間では、ＰＣ５インターフェイス（ＰＣ５接続）を介してユーザデータ（パケット）及び／又は制御情報が伝送される。
【００５８】
ＵＥ１００−１とＵＥ１００−２との間には、非３ＧＰＰ（Ｎｏｎ−３ＧＰＰ）アクセス技術により接続が確立されてもよい。例えば、ＵＥ１００−１とＵＥ１００−２との間では、ＷＬＡ（Ｗｉｒｅｌｅｓｓ  Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）を介してユーザデータ（パケット）及び／又は制御情報が伝送される。
【００５９】
ＵＥ１００−１とｅＮＢ２００との間には、３ＧＰＰ（Ｔｈｉｒｄ  Ｇｅｎｅｒａｔｉｏｎ  Ｐａｒｔｎｅｒｓｈｉｐ  Ｐｒｏｊｅｃｔ）アクセス技術により接続が確立されてもよい。例えば、ＵＥ１００−１とｅＮＢ２００との間では、Ｕｕインターフェイス（又はＵｎインターフェイス）を介してユーザデータ（パケット）及び／又は制御情報が伝送される。
【００６０】
レイヤ２中継において、ＵＥ１００−１は、物理レイヤ、ＭＡＣレイヤ、及びＲＬＣレイヤを確立してもよい。ＵＥ１００−２は、物理レイヤ、ＭＡＣレイヤ、ＲＬＣレイヤ、ＰＤＣＰレイヤを確立してもよい。ｅＮＢ２００は、物理レイヤ、ＭＡＣレイヤ、ＲＬＣレイヤ、ＰＤＣＰレイヤを確立してもよい。ＵＥ１００−２のＰＤＣＰレイヤとｅＮＢ２００のＰＤＣＰレイヤとの間で、ＵＥ１００−１を介して、ＵＥ１００−２のパケットが伝送される。
【００６１】
図５に示すように、レイヤ２中継が実行される場合、特別なレイヤが確立されてもよい。特別なレイヤは、例えば、アダプテーションレイヤ（Ａｄａｐｔａｔｉｏｎ  Ｌａｙｅｒ）である。アダプテーションレイヤは、レイヤ２において、ＲＬＣレイヤよりも上位のレイヤであってもよい。アダプテーションレイヤは、ＲＬＣレイヤの１つ上の上位レイヤであってもよい。アダプテーションレイヤは、ＰＤＣＰレイヤと異なるレイヤであってもよい。アダプテーションレイヤは、ＰＤＣＰレイヤよりも下位のレイヤであってもよい。アダプテーションレイヤは、ＰＤＣＰレイヤの１つ下の下位レイヤであってもよい。アダプテーションレイヤは、ＲＬＣレイヤとＰＤＣＰレイヤとの間に確立されてもよい。
【００６２】
ＵＥ１００−１のアダプテーションレイヤとＵＥ１００−２のアダプテーションレイヤとの間において、ユーザデータ及び／又は制御情報が伝送される。ＵＥ１００−１のアダプテーションレイヤとｅＮＢ２００のアダプテーションレイヤとの間において、ユーザデータ及び／又は制御情報が伝送される。
【００６３】
アダプテーションレイヤでは、ＵＥ１００−２のパケットの処理が実行される。例えば、アダプテーションレイヤでは、ＵＥ１００−２のパケットに新たなヘッダを付与する処理が実行されてもよい。アダプテーションレイヤでは、ＵＥ１００−２のパケットに付与された新たなヘッダの内容を理解するための処理が実行されてもよい（例えば、後述の動作例３参照）。
【００６４】
（無線端末）
実施形態に係るＵＥ１００（無線端末）について説明する。図６は、ＵＥ１００のブロック図である。図６に示すように、ＵＥ１００は、レシーバ（Ｒｅｃｅｉｖｅｒ：受信部）１１０、トランスミッタ（Ｔｒａｎｓｍｉｔｔｅｒ：送信部）１２０、及びコントローラ（Ｃｏｎｔｒｏｌｌｅｒ：制御部）１３０を備える。レシーバ１１０とトランスミッタ１２０とは、一体化されたトランシーバ（送受信部）であってもよい。
【００６５】
レシーバ１１０は、コントローラ１３０の制御下で各種の受信を行う。レシーバ１１０は、アンテナを含む。レシーバ１１０は、アンテナが受信する無線信号をベースバンド信号（受信信号）に変換する。レシーバ１１０は、ベースバンド信号をコントローラ１３０に出力する。
【００６６】
トランスミッタ１２０は、コントローラ１３０の制御下で各種の送信を行う。トランスミッタ１２０は、アンテナを含む。トランスミッタ１２０は、コントローラ１３０が出力するベースバンド信号（送信信号）を無線信号に変換する。トランスミッタ１３０は、無線信号をアンテナから送信する。
【００６７】
コントローラ１３０は、ＵＥ１００における各種の制御を行う。コントローラ１３０は、プロセッサ及びメモリを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に使用される情報を記憶する。プロセッサは、ベースバンドプロセッサとＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）とを含む。ベースバンドプロセッサは、例えば、ベースバンド信号の変調・復調及び符号化・復号化を行う。ＣＰＵは、メモリに記憶されるプログラムを実行することにより、各種の処理を行う。プロセッサは、音声・映像信号の符号化・復号化を行うコーデックを含んでもよい。プロセッサは、後述する各種の処理及び上述した各種の通信プロトコルを実行する。
【００６８】
ＵＥ１００は、ＧＮＳＳ（Ｇｌｏｂａｌ  Ｎａｖｉｇａｔｉｏｎ  Ｓａｔｅｌｌｉｔｅ  Ｓｙｓｔｅｍ）受信機を備えていてもよい。ＧＮＳＳ受信機は、ＵＥ１００の地理的な位置を示す位置情報を得るために、ＧＮＳＳ信号を受信できる。ＧＮＳＳ受信機は、ＧＮＳＳ信号をコントローラ１３０に出力する。ＵＥ１００は、ＵＥ１００の位置情報を取得するためのＧＰＳ（Ｇｌｏｂａｌ  Ｐｏｓｉｔｉｏｎｉｎｇ  Ｓｙｓｔｅｍ）機能を有していてもよい。
【００６９】
本明細書では、ＵＥ１００が備えるレシーバ１１０、トランスミッタ１２０及びコントローラ１３０の少なくともいずれかが実行する処理を、便宜上、ＵＥ１００が実行する処理（動作）として説明する。
【００７０】
（基地局）
実施形態に係るｅＮＢ２００（基地局）について説明する。図７は、ｅＮＢ２００のブロック図である。図７に示すように、ｅＮＢ２００は、レシーバ（受信部）２１０、トランスミッタ（送信部）２２０、コントローラ（制御部）２３０、及びネットワークインターフェイス２４０を備える。トランスミッタ２１０とレシーバ２２０は、一体化されたトランシーバ（送受信部）であってもよい。
【００７１】
レシーバ２１０は、コントローラ２３０の制御下で各種の受信を行う。レシーバ２１０は、アンテナを含む。レシーバ２１０は、アンテナが受信する無線信号をベースバンド信号（受信信号）に変換する。レシーバ２１０は、ベースバンド信号をコントローラ２３０に出力する。
【００７２】
トランスミッタ２２０は、コントローラ２３０の制御下で各種の送信を行う。トランスミッタ２２０は、アンテナを含む。トランスミッタ２２０は、コントローラ２３０が出力するベースバンド信号（送信信号）を無線信号に変換する。トランスミッタ２２０は、無線信号をアンテナから送信する。
【００７３】
コントローラ２３０は、ｅＮＢ２００における各種の制御を行う。コントローラ２３０は、プロセッサ及びメモリを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に使用される情報を記憶する。プロセッサは、ベースバンドプロセッサとＣＰＵとを含む。ベースバンドプロセッサは、例えば、ベースバンド信号の変調・復調及び符号化・復号化等を行う。ＣＰＵは、メモリに記憶されるプログラムを実行することにより各種の処理を行う。プロセッサは、後述する各種の処理及び上述した各種の通信プロトコルを実行する。
【００７４】
ネットワークインターフェイス２４０は、Ｘ２インターフェイスを介して隣接ｅＮＢ２００と接続される。ネットワークインターフェイス２４０は、Ｓ１インターフェイスを介してＭＭＥ３００及びＳＧＷ４００と接続される。ネットワークインターフェイス２４０は、例えば、Ｘ２インターフェイス上で行う通信及びＳ１インターフェイス上で行う通信に使用される。
【００７５】
本明細書では、ｅＮＢ２００が備えるトランスミッタ２１０、レシーバ２２０、コントローラ２３０、及びネットワークインターフェイス２４０の少なくともいずれかが実行する処理を、便宜上、ｅＮＢ２００が実行する処理（動作）として説明する。
【００７６】
（実施形態に係る動作）
実施形態に係る動作について、動作例１−９を例に挙げて説明する。
【００７７】
（Ａ）動作例１
動作例１について、図８を用いて説明する。図８は、動作例１を説明するためのシーケンス図である。
【００７８】
動作例１では、レイヤ２中継を設定するための動作の一例について説明する。
【００７９】
ＵＥ１００−１は、レイヤ２中継が実行可能なＵＥである。ＵＥ１００−１は、ＰｒｏＳｅ  ＵＥ−ｔｏ−Ｎｅｔｗｏｒｋ  Ｒｅｌａｙであってもよい。ＵＥ１００−１は、ｅＮＢ２００のセルに在圏する。ＵＥ１００−１は、初期状態において、ｅＮＢ２００（セル）とＲＲＣ接続状態であってもよい。ＵＥ１００−１は、初期状態において、ｅＮＢ２００（セル）とＲＲＣアイドル状態であってもよい。
【００８０】
ＵＥ１００−２は、レイヤ２中継により、ＵＥ１００−１を介してネットワークとの通信を実行可能なＵＥである。ＵＥ１００−２は、リモートＵＥであってもよい。ＵＥ１００−２は、レイヤ２中継によりＵＥ１００−１を介してパケットをネットワーク（ｅＮＢ２００）から受け取ってもよい。ＵＥ１００−２は、レイヤ２中継によりＵＥ１００−１を介してパケットをネットワーク（ｅＮＢ２００）へ送ってもよい。
【００８１】
ＵＥ１００−２は、ｅＮＢ２００のセルに在圏してもよい。ＵＥ１００−２は、ｅＮＢ２００のセルに在圏しなくてもよい。ＵＥ１００−２は、セルの圏内（Ｉｎ  Ｃｏｖｅｒａｇｅ）であってもよい。ＵＥ１００−２は、圏外（Ｏｕｔ−ｏｆ−ｃｏｖｅｒａｇｅ）であってもよい。
【００８２】
ＵＥ１００−２は、ウェアラブルＵＥ（ｗＵＥ）であってもよい。ウェアラブルＵＥは、例えば、ユーザが着用可能な通信装置である。ウェアラブルＵＥは、近距離用の装置であってもよい。ウェアラブルＵＥは、サイドリンク動作などの端末間での直接的な無線信号のやり取りが近距離（数ｍ（例えば、２ｍ）の範囲内）で実行されることが想定される通信装置であってもよい。
【００８３】
本明細書において、「近距離」は、通信可能な距離（例えば、数ｍの範囲）によって規定されてもよい。例えば、近距離な装置間（ＵＥ−ｗＵＥ間／ｗＵＥ−ｗＵＥ間）での無線信号（サイドリンク信号）の最大到達距離（最大到達範囲）は、通常のＵＥ間（ＵＥ−ＵＥ間）での無線信号（サイドリンク信号）の最大到達距離よりも短くてもよい。近距離な装置間での無線信号（サイドリンク信号）の最大到達距離は、ＵＥ−ｅＮＢ間の上りリンク信号の最大到達距離よりも短くてもよい。
【００８４】
「近距離」は、近距離な装置間での無線信号（サイドリンク信号）の（最大）送信電力（例えば、最大送信電力が０ｄＢｍ以下）によって規定されてもよい。例えば、近距離な装置間（ＵＥ−ｗＵＥ間／ｗＵＥ−ｗＵＥ間）での無線信号（サイドリンク信号）の最大送信電力は、通常のＵＥ間（ＵＥ−ＵＥ間）での無線信号（サイドリンク信号）の最大送信電力よりも小さくてもよい。近距離な装置間での無線信号（サイドリンク信号）の最大送信電力は、ＵＥ−ｅＮＢ間の上りリンク信号の最大送信電力よりも短くてもよい。
【００８５】
「近距離」は、ウェアラブルＵＥが利用可能なリソースプール（の条件／設定）により、規定されてもよい。
【００８６】
ウェアラブルＵＥは、既存のＵＥ１００と異なり、既存のＳＩＭ（Ｓｕｂｓｃｒｉｂｅｒ  Ｉｄｅｎｔｉｔｙ  Ｍｏｄｕｌｅ  Ｃａｒｄ）の装着が不要であってもよい。ウェアラブルＵＥは、近距離用のＳＩＭ（Ｄ２Ｄ  ＳＩＭ）が装着可能であってもよい。
【００８７】
図８に示すように、ステップＳ１０１において、ＵＥ１００−１は、ＵＥ１００−１がレイヤ２中継を可能であることを示す情報を送信してもよい。当該情報は、例えば、レイヤ２中継の能力を示す情報（Ｌ２  Ｒｅｌａｙ  ｃａｐａｂｉｌｉｔｙ）であってもよい。
【００８８】
ＵＥ１００−１は、中継のための発見メッセージ（Ｒｅｌａｙ  ｄｉｓｃｏｖｅｒｙ）に当該情報を含めてもよい。ＵＥ１００−１は、直接通信を要求するためのメッセージ（Ｄｉｒｅｃｔ  ｃｏｍｍｕｎｉｃａｔｉｏｎ  Ｒｅｑｕｅｓｔ）に当該情報を含めてもよい。
【００８９】
ステップＳ１０１は、省略されてもよい。例えば、ＵＥ１００−１とＵＥ１００−２とが非３ＧＰＰアクセス技術により、端末間通信が実行される／実行されている場合には、ＵＥ１００−１は、レイヤ２中継を可能であることを示す情報の送信を省略してもよい。
【００９０】
ステップＳ１０２において、ＵＥ１００−２は、レイヤ２中継のための要求である第１要求（Ｌ２  ｒｅｌａｙ  Ｒｅｑｕｅｓｔ）をＵＥ１００−１へ送信する。ＵＥ１００−２は、当該要求を示す情報を含むメッセージをＵＥ１００−１へ送信してもよい。ＵＥ１００−２は、例えば、直接通信を要求するためのメッセージ（Ｄｉｒｅｃｔ  Ｃｏｍｍ．Ｒｅｑｕｅｓｔ）にレイヤ２中継の要求を示す情報を含めてもよい。
【００９１】
ＵＥ１００−２は、ＵＥ１００−１がレイヤ２中継を可能であることを示す情報の受信に応じて、レイヤ２中継の要求を示す情報をＵＥ１００−１へ送信してもよい。これにより、ＵＥ１００−２は、レイヤ２中継が可能である場合にのみ、レイヤ２中継の要求を示す情報をＵＥ１００−１へ送信することができる。これにより、ＵＥ１００−２は、ＵＥ１００−１がレイヤ２中継をできないにもかかわらず、レイヤ２中継の要求を示す情報をＵＥ１００−１へ送信することを回避することができる。
【００９２】
ＵＥ１００−２は、ＵＥ１００−１がレイヤ２中継を可能であることを示す情報を受信しない場合であっても、レイヤ２中継の要求を示す情報をＵＥ１００−１へ送信してもよい。例えば、ＵＥ１００−２は、ＵＥ１００−１とＵＥ１００−２とが非３ＧＰＰアクセス技術により、端末間通信が実行される／実行されている場合には、レイヤ２中継の要求を示す情報をＵＥ１００−１へ送信してもよい。
【００９３】
ＵＥ１００−２は、ＰＣ５インターフェイスを介してレイヤ２中継の要求を示す情報をＵＥ１００−１へ送信してもよい。ＵＥ１００−２は、ＰＣ５プロトコルを用いて、レイヤ２中継の要求を示す情報をＵＥ１００−１へ送信してもよい。
【００９４】
ステップＳ１０３において、ＵＥ１００−１は、レイヤ２中継のための要求である第２要求（Ｌ２  ｒｅｌａｙ  Ｒｅｑｕｅｓｔ）をｅＮＢ２００へ送信する。ＵＥ１００−１は、例えば、サイドリンクＵＥ情報（ＳＬ  ＵＥ  Ｉｎｆｏｒｍａｔｉｏｎ）にレイヤ２中継の要求を示す情報を含めてもよい。
【００９５】
ＵＥ１００−１は、例えば、各リモートＵＥ１００から第１要求を受ける度に、第２要求をｅＮＢ２００へ送信してもよい。
【００９６】
ＵＥ１００−１は、複数のリモートＵＥ１００のそれぞれから第１要求を受けた場合、１つのメッセージにより第２要求を送信してもよい。当該メッセージは、複数のリモートＵＥ１００のそれぞれの識別子を含んでいてもよい。
【００９７】
ＵＥ１００−１は、複数のリモートＵＥ１００のそれぞれから第１要求を受けた場合、第２要求を送信しなくてもよい。ＵＥ１００−１は、直接通信用の送信リソースをｅＮＢ２００へ要求してもよい。ＵＥ１００−１は、サイドリンク用のバッファステータスレポート（ＳＬ-ＢＳＲ）をｅＮＢ２００へ送信してもよい。ＳＬ−ＢＳＲは、端末間での送信に利用可能なデータの量についての情報をｅＮＢ（サービングｅＮＢ）２００へ提供するためのものである。例えば、利用可能なデータの量は、レイヤ２中継により伝送すべきデータ（パケット）の量であってもよい。利用可能なデータの量は、複数のＵＥ１００−２が保持する送信すべきデータの合計のデータ量であってもよい。各リモートＵＥ１００は、ステップＳ１０２において、送信すべきデータの量をＵＥ１００−１へ通知してもよい。
【００９８】
ｅＮＢ２００は、第２要求をＵＥ１００−１から受信する。ｅＮＢ２００は、第２要求を許可するか拒否するかを判定してもよい。
【００９９】
ステップＳ１０４において、ｅＮＢ２００は、第２要求に対する応答をＵＥ１００−１へ送信できる。ｅＮＢ２００は、応答メッセージとして、例えば、ＲＲＣ接続再設定メッセージ（ＲＲＣＣｏｎｎ．Ｒｅｃｏｎｆ．）をＵＥ１００−１へ送信してもよい。
【０１００】
ｅＮＢ２００は、レイヤ２中継を許可する場合に、レイヤ２中継を設定するための情報（Ｌ２  ｒｅｌａｙ  ｃｏｎｆｉｇ．）を応答メッセージに含めてもよい。
【０１０１】
ｅＮＢ２００は、レイヤ２中継において特別なレイヤ（例えば、アダプテーションレイヤ）を利用することを示す情報を応答メッセージに含めてもよい。ｅＮＢ２００は、例えば、アダプテーションレイヤを介してレイヤ２中継を実行するか否かを判定してもよい。ｅＮＢ２００は、例えば、アダプテーションレイヤを介してレイヤ２中継が実行されることを示す情報を応答メッセージに含めてもよい。ｅＮＢ２００は、例えば、アダプテーションレイヤを介さずにレイヤ２中継が実行されることを示す情報を応答メッセージに含めてもよい。
【０１０２】
ｅＮＢ２００は、ＵＥ１００−１からＳＬ  ＢＳＲを受け取った場合には、データ量に応じて無線リソースを割り当てても良い。応答メッセージは、割り当てた無線リソースを示す情報を含んでいてもよい。ｅＮＢ２００は、複数の無線リソースにより構成される無線リソースプールを応答メッセージに含めてもよい。
【０１０３】
ｅＮＢ２００は、第２要求を拒否する場合には、拒否を示すメッセージをＵＥ１００−１へ送信してもよい。この場合、ＵＥ１００−１は、レイヤ２中継が拒否されたことを示すメッセージをＵＥ１００−２へ送信してもよい。ＵＥ１００−１は、直接通信の要求を拒否するメッセージ（Ｄｉｒｅｃｔ  Ｃｏｍｍ．Ｒｅｑｕｅｓｔ  ＮＡＣＫ）をＵＥ１００−２へ送信してもよい。
【０１０４】
以下において、ｅＮＢ２００がレイヤ２中継を許可したと仮定して説明を進める。
【０１０５】
ステップＳ１０５において、ＵＥ１００−１は、第１要求に対する応答をＵＥ１００−２へ送信する。ＵＥ１００−１は、直接通信の要求を承認するメッセージ（Ｄｉｒｅｃｔ  Ｃｏｍｍ．Ｒｅｑｕｅｓｔ  ＡＣＫ）をＵＥ１００−２へ送信してもよい。
【０１０６】
ＵＥ１００−１は、レイヤ２中継を設定するための情報（Ｌ２  ｒｅｌａｙ  ｃｏｎｆｉｇ．）をＵＥ１００−２へ送信してもよい。当該情報は、ＵＥ１００−１がｅＮＢ２００から受け取った設定情報であってもよい。
【０１０７】
ＵＥ１００−２は、例えば、ＵＥ１００−１から受け取った情報に基づいて、レイヤ２中継においてアダプテーションレイヤを介したパケットの伝送が許可されるか否かを判定してもよい。
【０１０８】
以後のステップＳ１０６、Ｓ１０８、Ｓ１０９において、レイヤ２中継により、ＵＥ１００−１とＵＥ１００−２との間においてＵＥ１００−２のトラフィック（例えば、ＰＣ５トラフィック）が伝送される。レイヤ２中継により、ＵＥ１００−１とｅＮＢ２００との間においてＵＥ１００−２のトラフィック（例えば、Ｕｕトラフィック）が伝送される。ＵＥ１００−２は、ｅＮＢ２００から割り当てられた無線リソース（無線リソースプール）を用いて、トラフィックを伝送できる。
【０１０９】
ステップＳ１０６において、ＵＥ１００−２は、ＲＲＣ接続を要求するためのメッセージ（ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｑｕｅｓｔ）をＵＥ１００−１を介してｅＮＢ２００へ送信してもよい。
【０１１０】
ステップＳ１０７において、ｅＮＢ２００と上位ノード（ＭＭＥ３００／ＳＧＷ４００）との間で、ＵＥ１００−２に対してＲＲＣ接続を確立するためのシグナリングが伝送されてもよい。
【０１１１】
ステップＳ１０８において、ｅＮＢ２００は、ＲＲＣ接続をセットアップするためのメッセージ（ＲＲＣＣｏｎｎｅｃｔｉｏｎＳｅｔｕｐ）をＵＥ１００−１を介してＵＥ１００−２へ送信してもよい。
【０１１２】
ＵＥ１００−２は、当該メッセージに基づいて、ＲＲＣ接続を確立するためのセットアップを開始する。ＵＥ１００−２は、セットアップが終了した場合に、ステップＳ１０９の処理を実行する。
【０１１３】
ステップＳ１０９において、ＵＥ１００−２は、ＲＲＣ接続のセットアップが完了したこと示すメッセージ（ＲＲＣＣｏｎｎｅｃｔｉｏｎＳｅｔｕｐＣｏｍｐｌｅｔｅ）をＵＥ１００−１を介してｅＮＢ２００へ送信してもよい。
【０１１４】
以上により、ネットワークとＵＥ１００−２との間にＲＲＣ接続が確立されるため、ネットワークは、通常のＵＥ１００と同様に、ＵＥ１００−２に対してサービスを提供することが可能である。例えば、ネットワークは、ＵＥ１００−２（の位置）を特定することができる。ネットワークは、ＵＥ１００−２を呼び出すことができる。ネットワークは、ＵＥ１００−２へデータを届けることができる。
【０１１５】
ＵＥ１００−２は、ＲＲＣ接続が確立された後も、レイヤ２中継により、ＵＥ１００−１を介して、ＵＥ１００−２のトラフィック（ユーザデータ／パケット）が伝送される。
【０１１６】
ＵＥ１００−２は、既存のＵＥ１００と同様に、ＵＥ１００−１を介して、ＲＲＣ接続を解放するための手順を実行できる。
【０１１７】
（Ｂ）動作例２
動作例２について、図９を用いて説明する。図９は、動作例２を説明するためのシーケンス図である。
【０１１８】
動作例２では、ＰＣ５プロトコルを用いずに、レイヤ２中継を設定することができる。上述で説明した内容と同様の説明は省略する。
【０１１９】
ステップＳ２０１において、ＵＥ１００−１は、ＰＣ５メッセージと異なるメッセージにより、ＵＥ１００−１がレイヤ２中継を可能であることを示す情報を送信してもよい。
【０１２０】
例えば、ＵＥ１００−１は、ＭＩＢ−ＳＬ（ＭａｓｔｅｒＩｎｆｏｒｍａｔｉｏｎＢｌｏｃｋ−ＳＬ）メッセージ内にＵＥ１００−１がレイヤ２中継を可能であることを示す情報（Ｌ２  Ｒｅｌａｙ  ｃａｐａｂｉｌｉｔｙ）を含めてもよい。ＵＥ１００−１は、ＳＬＳＳ（Ｓｉｄｅｌｉｎｋ  Ｓｙｎｃｈｒｏｎｉｓａｔｉｏｎ  Ｓｉｇｎａｌ）のシーケンス（信号系列）により、ＵＥ１００−１がレイヤ２中継を可能であることを示してもよい。
【０１２１】
ＭＩＢ−ＳＬメッセージは、サイドリンク共通制御情報を運搬するためのメッセージである。ＭＩＢ−ＳＬメッセージは、ＳＬ−ＢＣＨを介して、ＳＬＳＳを送信するＵＥ（すなわち、同期参照として動作するＵＥ）により送信される情報を含む。
【０１２２】
ＳＬＳＳは、サイドリンクにおける同期信号である。ＳＬＳＳは、ＰＳＳＳ（Ｐｒｉｍａｒｙ  Ｓｉｄｅｌｉｎｋ  Ｓｙｎｃｈｒｏｎｉｓａｔｉｏｎ  Ｓｉｇｎａｌ）及びＳＳＳＳ（Ｓｅｃｏｎｄａｒｙ  Ｓｉｄｅｌｉｎｋ  Ｓｙｎｃｈｒｏｎｉｓａｔｉｏｎ  Ｓｉｇｎａｌ）により構成される。ＵＥ１００−１がレイヤ２中継を可能であることを示すシーケンスは、ＰＳＳＳのシーケンスであってもよい。ＳＳＳＳのシーケンスであってもよい。
【０１２３】
ＵＥ１００−２は、ＵＥ１００−１からのメッセージに基づいて、ＵＥ１００−１がレイヤ２中継が可能であるか否かを判定できる。ＵＥ１００−２は、ＵＥ１００−１がレイヤ２中継が可能である場合、ステップＳ２０２の処理を実行できる。ＵＥ１００−２は、ＵＥ１００−１からＬ２  Ｒｅｌａｙ  ｃａｐａｂｉｌｉｔｙを受け取っていない場合であっても、ステップＳ２０２の処理を実行してもよい。
【０１２４】
ステップＳ２０２において、ＵＥ１００−２は、ＰＣ５メッセージと異なるメッセージにより、レイヤ２中継のための要求（第１要求）をＵＥ１００−１へ送信してもよい。
【０１２５】
例えば、ＵＥ１００−２は、ＭＡＣ  ＣＥ（ＭＡＣ  Ｃｏｎｔｒｏｌ  Ｅｌｅｍｅｎｔ）に第１要求を示す情報を含めてもよい。ＵＥ１００−２は、ＰＤＣＰヘッダに第１要求を示す情報を含めてもよい。ＵＥ１００−２は、ＲＲＣメッセージに第１要求を示す情報を含めてもよい。ＲＬＣレイヤよりも上位レイヤのメッセージに第１要求を示す情報を含めることによって、ＵＥ間でのパケット伝送（中継）が３ＧＰＰアクセス技術か非３ＧＰＰアクセス技術かに関係なく、ＵＥ１００−２は、第１要求をＵＥ１００−２へ送信することができる。
【０１２６】
ステップＳ２０３及びＳ２０４は、ステップＳ１０３及びＳ１０４に対応する。
【０１２７】
ステップＳ２０５において、ＵＥ１００−１は、ＰＣ５メッセージと異なるメッセージにより、第１要求に対する応答をＵＥ１００−２へ送信してもよい。
【０１２８】
例えば、ＵＥ１００−１は、ＭＡＣ  ＣＥに第１要求に対する応答を示す情報を含めてもよい。ＵＥ１００−１は、ＰＤＣＰヘッダに第１要求に対する応答を示す情報を含めてもよい。ＵＥ１００−１は、ＲＲＣメッセージに第１要求に対する応答を示す情報を含めてもよい。ＵＥ１００−１は、ＵＥ１００−２の第１要求と同じタイプの応答を送信してもよい。例えば、ＵＥ１００−１は、ＭＡＣ  ＣＥにより第１要求を受け取った場合は、ＭＡＣ  ＣＥにより第１要求に対する応答を送信してもよい。
【０１２９】
以上によれば、上位レイヤであるＰＣ５プロトコルを用いることなく、ＵＥ１００（ＵＥ１００−２）にレイヤ２中継が設定可能である。このため、ＰＣ５プロトコルに従って設定されるレイヤ３中継よりも早期にレイヤ２中継を開始することができる。
【０１３０】
（Ｃ）動作例３
動作例３について、図１０から図１２を用いて説明する。図１０は、動作例３を説明するためのフローチャートである。図１１は、動作例３を説明するための図である。図１２は、動作例３を説明するためのフローチャートである。
【０１３１】
動作例３では、アダプテーションレイヤを利用したレイヤ２中継の動作の一例を説明する。上述で説明した内容と同様の説明は省略する。
【０１３２】
図１０に示すように、ステップＳ３０１において、ＵＥ１００−２は、アダプテーションレイヤにおいて送信用のパケットを処理する。例えば、ＵＥ１００−２は、送信元のＵＥ（ＵＥ１００−２）を示す識別子をパケットに含めてもよい。ＵＥ１００−２は、アダプテーションレイヤにおいて、パケットに付与するヘッダ（新たなヘッダ）にＵＥ１００−２の識別子を含めてもよい。ＵＥ１００−２の識別子の例は、後述する（動作例７参照）。
【０１３３】
ＵＥ１００−２は、パケットの優先度の情報をパケットに含めてもよい。ＵＥ１００−２は、アダプテーションレイヤにおいて、パケットに付与するヘッダにパケットの優先度の情報を含めてもよい。
【０１３４】
ステップＳ３０２において、ＵＥ１００−２は、アダプテーションレイヤよりも下位レイヤにおいて、アダプテーションレイヤでパケットが処理されたことを示す情報（Ａｄａｐｔａｔｉｏｎ）をパケットに含める。ＵＥ１００−２は、例えば、ＭＡＣレイヤにおいて当該情報をパケットに含めてもよい。
【０１３５】
図１１に示すように、ＵＥ１００−２は、例えば、ＭＡＣ  ＳＤＵ（ＭＡＣ  Ｓｅｒｖｉｃｅ  Ｄａｔａ  Ｕｎｉｔ）毎に生成されるＭＡＣサブヘッダに当該情報（Ａｄａｐｔａｔｉｏｎ）を含めてもよい。ＵＥ１００−２は、ＭＡＣヘッダに当該情報を含めてもよい。
【０１３６】
ＵＥ１００−２は、非３ＧＰＰアクセス技術で伝送されるパケットのヘッダに、当該情報を含めてもよい。例えば、当該情報として、ＬＷＡ（ＬＴＥ  ＷＬＡＮ  Ａｇｇｒｅｇａｔｉｏｎ）において用いられるＬＷＡ  ＥｔｈｅｒＴｙｐｅのパラメータ（ＥｔｈｅｒＴｙｐｅ）が流用されてもよい。ＥｔｈｅｒＴｙｐｅは、受信したパケットがアダプテーションレイヤで処理されるべき（受信したパケットがアダプテーションレイヤへ送られるべき）かどうかを決定するために用いられてもよい。ＵＥ１００−２は、３ＧＰＰアクセス技術で伝送されるパケットのヘッダにＥｔｈｅｒＴｙｐｅを含めてもよい。
【０１３７】
ステップＳ３０３において、ＵＥ１００−２は、ＭＡＣレイヤにおいて処理したパケットを、物理レイヤにおいて処理した後、ＵＥ１００−１を介して、ｅＮＢ２００へ送信する。
【０１３８】
具体的には、ＵＥ１００−１は、ＵＥ１００−２から受け取ったパケットを、ＭＡＣレイヤにおいて処理する場合に、アダプテーションレイヤでパケットが処理されたことを示す情報を検出する。これにより、ＵＥ１００−１は、当該パケットがアダプテーションレイヤでパケットが処理されたことを把握する。すなわち、ＵＥ１００−１は、アダプテーションレイヤを介したトラフィックであると把握する。ＵＥ１００−１は、アダプテーションレイヤにおいて当該パケットを処理する。
【０１３９】
一方、ＵＥ１００−１は、ＵＥ１００−２から受け取ったパケットにおいてアダプテーションレイヤでパケットが処理されたことを示す情報を検出しない場合、アダプテーションレイヤにおける処理を省略する。
【０１４０】
ＵＥ１００−１は、パケットのヘッダに含まれる情報（ＥｔｈｅｒＴｙｐｅ）に基づいて、パケットをアダプテーションレイヤで処理すべきかどうかを判定してもよい。ＵＥ１００−１は、例えば、パケットがアダプテーションレイヤで処理されたことをＥｔｈｅｒＴｙｐｅが示す場合には、アダプテーションレイヤにおいてパケットを処理する。ＵＥ１００−１は、パケットがアダプテーションレイヤで処理されていないことをＥｔｈｅｒＴｙｐｅが示す場合には、アダプテーションレイヤにおける処理を省略する。
【０１４１】
その後、ＵＥ１００−１は、ＵＥ１００−２から受け取ったパケットをｅＮＢ２００へ転送（中継）する。
【０１４２】
ｅＮＢ２００は、ＵＥ１００−１と同様に、ＵＥ１００−１から受け取ったパケット（例えば、ＭＡＣサブヘッダ）からアダプテーションレイヤでパケットが処理されたことを示す情報を検出する。
【０１４３】
ｅＮＢ２００は、当該検出により、当該パケットがアダプテーションレイヤでパケットが処理されたことを把握する。ｅＮＢ２００は、当該パケットをアダプテーションレイヤにおいて処理する。ｅＮＢ２００は、アダプテーションレイヤにおいて、パケットの送信元（パケットの発生元）を示すＵＥ１００−２の識別子が含まれる場合、当該パケットの送信元がＵＥ１００−２であることを把握できる。これにより、ｅＮＢ２００は、アダプテーションレイヤにおいて、パケットの送信元（パケットの発生元）を把握できる。ｅＮＢ２００は、レイヤ３中継のように、上位レイヤであるＩＰレイヤにおいてパケットの送信元（パケットの発生元）を把握する処理を実行しなくてもよい。
【０１４４】
上述では、上りリンクのレイヤ２中継について説明したが、下りリンクのレイヤ２中継においても同様の動作が実行されてもよい。
【０１４５】
図１２に示すように、ステップＳ４０１において、ｅＮＢ２００は、アダプテーションレイヤにおいて送信用のパケットを処理する。例えば、ｅＮＢ２００は、送信先のＵＥ（ＵＥ１００−２）を示す識別子をパケットに含めてもよい。ｅＮＢ２００は、アダプテーションレイヤにおいて、パケットに付与するヘッダ（新たなヘッダ）にＵＥ１００−２の識別子を含めてもよい。識別子は、最終的な送信先の識別子である。
【０１４６】
ステップＳ４０２において、ｅＮＢ２００は、アダプテーションレイヤよりも下位レイヤにおいて、アダプテーションレイヤでパケットが処理されたことを示す情報をパケットに含める。ｅＮＢ２００は、例えば、ＭＡＣレイヤにおいて当該情報をパケットに含めてもよい。
【０１４７】
ステップＳ４０３において、ｅＮＢ２００は、ＭＡＣレイヤにおいて処理したパケットを、物理レイヤにおいて処理した後、ＵＥ１００−１を介して、ＵＥ１００−２へ送信する。
【０１４８】
ＵＥ１００−１は、上述と同様に、ｅＮＢ２００から受け取ったパケットに、アダプテーションレイヤでパケットが処理されたことを示す情報が含まれるか否かを判定する。ＵＥ１００−１は、アダプテーションレイヤを介したトラフィックであると把握した場合、アダプテーションレイヤにおいて処理を実行する。ＵＥ１００−１は、アダプテーションレイヤを介したトラフィックでないと把握した場合、アダプテーションレイヤにおける処理を省略する。
【０１４９】
ＵＥ１００−１は、アダプテーションレイヤにおいて、新たなヘッダに含まれる送信先のＵＥ（ＵＥ１００−２）を示す識別子により、パケットの送信先を把握してもよい。これにより、ＵＥ１００−１は、上位レイヤであるＩＰレイヤにおいてパケットの送信元（パケットの発生元）を把握する処理を実行せずに済む。
【０１５０】
その後、ＵＥ１００−１は、ｅＮＢ２００から受け取ったパケットをＵＥ１００−２へ転送（中継）する。
【０１５１】
（Ｄ）動作例４
動作例４について、図１３を用いて説明する。図１３は、動作例４を説明するためのフローチャートである。
【０１５２】
動作例４では、アダプテーションレイヤを利用したレイヤ２中継の動作の一例を説明する。上述で説明した内容と同様の説明は省略する。
【０１５３】
図１３に示すように、ステップＳ５０１において、ｅＮＢ２００は、レイヤ２中継で用いられる論理チャネル識別子（ＬＣＩＤ：Ｌｏｇｉｃａｌ  Ｃｈａｎｎｅｌ  ＩＤ）をＵＥ１００−１へ割り当てる。当該ＬＣＩＤは、ＵＥ１００−１とｅＮＢ２００との間で用いられるＬＣＩＤである。ｅＮＢ２００は、アダプテーションレイヤを介したパケットの伝送が許可されるＬＣＩＤをＵＥ１００−１へ通知してもよい。すなわち、ｅＮＢ２００は、所定のＬＣＩＤでのみアダプテーションレイヤを介したパケットの伝送を許可してもよい。ｅＮＢ２００は、既に割り当てたＬＣＩＤの中から、所定のＬＣＩＤを決定してもよい。
【０１５４】
ステップＳ５０２において、ＵＥ１００−１とｅＮＢ２００とは、アダプテーションレイヤを介したパケットを伝送する場合、アダプテーションレイヤを介したパケットの伝送が許可されたＬＣＩＤにより示される論理チャネルを用いて当該パケットを伝送する。これにより、ＵＥ１００−１とｅＮＢ２００とは、当該ＬＣＩＤにより示される論理チャネルで伝送されるパケットがアダプテーションレイヤを介したパケットであることを把握することができる。
【０１５５】
（Ｅ）動作例５
動作例５について、図１４及び図１５を用いて説明する。図１４は、動作例５を説明するための図である。図１５は、動作例５を説明するためのシーケンス図である。
【０１５６】
図１４に示すように、既存のレイヤ３中継では、ＵＥ１００−１（Ｒｅｌａｙ  ＵＥ）は、ＵＥ１００−２（Ｒｅｍｏｔｅ  ＵＥ）からのパケットを受信した場合、ＩＰレイヤにおける処理を実行することで、パケットの優先度（ＱｏＳ（Ｑｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅ）／ＰＰＰＰ（ＰｒｏＳｅ  Ｐｅｒ−Ｐａｃｋｅｔ  Ｐｒｉｏｒｉｔｙ）など）を把握することができる。しかしながら、レイヤ２中継では、ＵＥ１００−１は、ＩＰレイヤにおける処理を実行しないため、パケットの優先度を把握することができない。このため、レイヤ２中継において、ＵＥ１００−１からｅＮＢ２００へパケットを伝送する場合に、優先度の高いパケットの遅延が発生する可能性がある。
【０１５７】
そこで、以下の動作が実行されてもよい。上述で説明した内容と同様の説明は省略する。
【０１５８】
図１５に示すように、ステップＳ６０１、Ｓ６０２は、ステップＳ１０２、Ｓ１０３に対応する。ＵＥ１００−２は、後述するように、ＬＣＩＤを通知されるまで、ＰＣ５インターフェイス上で利用可能な所定のＬＣＩＤ（ＬＣＩＤ♯０）を用いて、第１要求（Ｌ２  Ｒｅｌａｙ  Ｒｅｕｑｅｓｔ）をＵＥ１００−１へ送信してもよい。
【０１５９】
ステップＳ６０３において、ステップＳ１０４と同様に、ｅＮＢ２００は、第２要求に対する応答をＵＥ１００−１へ送信できる。
【０１６０】
当該応答は、ＬＣＩＤと優先度とが関連付けられた関連情報（Ａｓｓｏｃｉａｔｉｏｎ  ｉｎｆｏ．）を含んでいてもよい。関連情報は、ＬＣＩＤと優先度とが対応付けられたリストであってもよい。優先度は、ＰＰＰＰ（のクラス）であってもよい。優先度は、ＱｏＳ（のクラス）であってもよい。ＬＣＩＤは、ＵＥ１００−１とＵＥ１００−２との間の論理チャネルの識別子である。ＬＣＩＤは、ＵＥ１００−１とＵＥ１００−２との間でパケットを伝送するために用いられる。このように、ｅＮＢ２００がＰＣ５インターフェイス上で利用可能なＬＣＩＤを指定できる。
【０１６１】
これにより、ｅＮＢ２００は、優先度に対応付けられた複数のＬＣＩＤをＵＥ１００−１へ通知できる。
【０１６２】
ステップＳ６０４において、ステップＳ１０５と同様に、ＵＥ１００−１は、第１要求に対する応答をＵＥ１００−２へ送信する。応答は、関連情報を含んでいてもよい。
【０１６３】
これにより、ｅＮＢ２００は、優先度に対応付けられた複数のＬＣＩＤをＵＥ１００−２へ通知できる。
【０１６４】
ステップＳ６０５において、ＵＥ１００−２は、パケットをＵＥ１００−１へ送信するために、複数のＬＣＩＤの中から、パケットの優先度に対応するＬＣＩＤを選択する。
【０１６５】
例えば、ＵＥ１００−２は、発生したパケットの優先度が高優先度である場合、関連情報に基づいて、高優先度に対応付けられたＬＣＩＤ（例えば、ＬＣＩＤ♯１）を選択する。一方、ＵＥ１００−２は、発生したパケットの優先度が低優先度である場合、関連情報に基づいて、低優先度に対応付けられたＬＣＩＤ（例えば、ＬＣＩＤ♯３）を選択する。
【０１６６】
ＵＥ１００−２は、選択したＬＣＩＤ（例えば、ＬＣＩＤ♯３）を用いて、パケット（トラフィック）をＵＥ１００−１へ送信する。すなわち、ＵＥ１００−２は、選択したＬＣＩＤにより識別される論理チャネルにより、パケットをＵＥ１００−１へ送信する。
【０１６７】
ステップＳ６０６において、ＵＥ１００−１は、ＵＥ１００−２から受信したパケットの送信に用いられたＬＣＩＤにより、パケットの優先度を理解する。ＵＥ１００−１は、関連情報を用いて、パケットの送信に用いられたＬＣＩＤと対応付けられた優先度を、パケットの優先度に決定できる。これにより、ＵＥ１００−１は、パケットの優先度を把握することができる。
【０１６８】
ステップＳ６０７において、ＵＥ１００−１は、パケットの優先度に対応する適切なＬＣＩＤ（無線ベアラ）を介して当該パケットをｅＮＢ２００へ送信する。
【０１６９】
以上により、ＵＥ１００−１は、ＩＰレイヤでの処理によりパケットの優先度を把握しなくても、パケットの優先度を把握することができる。
【０１７０】
（Ｆ）動作例６
動作例６について、図１６から図１８を用いて説明する。図１６は、動作例６を説明するためのシーケンス図である。図１７及び図１８は、動作例６を説明するための図である。
【０１７１】
動作例６では、動作例５と異なる方法により、ＵＥ１００−１がパケットの優先度を把握する。上述で説明した内容と同様の説明は省略する。
【０１７２】
図１６に示すように、ステップＳ７０１及びＳ７０２は、ステップＳ６０１及びＳ６０２に対応する。
【０１７３】
ステップＳ７０３において、ｅＮＢ２００は、第２要求に対する応答をＵＥ１００−１へ送信できる。
【０１７４】
当該応答は、優先度に対応付けられた識別情報を含んでいてもよい。応答は、識別情報と優先度とが対応付けられたリストを含んでいてもよい。
【０１７５】
識別情報は、例えば、ＵＥ１００−１とネットワークとの間に確立されるベアラの識別子である。識別情報は、ＵＥ１００−１（又はＵＥ１００−２）とＰＧＷ５００との間のＥＰＳ（Ｅｖｏｌｖｅｄ  Ｐａｃｋｅｔ  Ｓｙｓｔｅｍ）ベアラの識別子（ＥＰＳ  ｂｅａｒｅｒ  ＩＤ  ｆｏｒ  Ｌ２  Ｒｅｌｙａ）であってもよい。当該ＥＰＳベアラの識別子は、レイヤ２中継に用いられるＥＰＳベラの識別子である。
【０１７６】
識別情報は、ＵＥ１００−１とｅＮＢ２００との間でパケットを伝送するために用いられるＬＣＩＤであってもよい。当該情報は、ＵＥ１００−１とｅＮＢ２００との間でパケットを伝送するために用いられるＤＲＢ  ＩＤ（Ｄａｔａ  Ｒａｄｉｏ  Ｂｅａｒｅｒ  ＩＤ）であってもよい。
【０１７７】
これにより、ｅＮＢ２００は、優先度に対応付けられた複数の識別情報をＵＥ１００−１へ通知できる。
【０１７８】
ステップＳ７０４において、ＵＥ１００−１は、第１要求に対する応答をＵＥ１００−２へ送信する。応答は、識別情報を含んでいてもよい。
【０１７９】
これにより、ｅＮＢ２００は、優先度に対応付けられた複数の識別情報をＵＥ１００−２へ通知できる。
【０１８０】
ステップＳ７０５において、ＵＥ１００−２は、パケットをＵＥ１００−１へ送信するために、複数の識別情報の中から、パケットの優先度に対応する識別情報を選択する。
【０１８１】
例えば、ＵＥ１００−２は、発生したパケットの優先度が高優先度である場合、関連情報に基づいて、高優先度に対応付けられたＥＰＳベアラ  ＩＤ（例えば、ＥＰＳベアラ  ＩＤ♯１）を選択する。一方、ＵＥ１００−２は、発生したパケットの優先度が低優先度である場合、関連情報に基づいて、低優先度に対応付けられたＥＰＳベアラ  ＩＤ（例えば、ＥＰＳベアラ  ＩＤ♯３）を選択する。
【０１８２】
ＵＥ１００−２は、選択した識別情報を含むヘッダが付与されたパケットを生成する。例えば、図１７に示すように、ＵＥ１００−２は、ＰＤＣＰレイヤにおいて、選択したＥＰＳベアラ  ＩＤを含むヘッダが付与されたパケットを生成する。図１８に示すように、ＵＥ１００−２は、ＰＤＣＰレイヤにおいて、選択したＬＣＩＤを含むヘッダが付与されたパケットを生成してもよい。
【０１８３】
ＵＥ１００−２は、サイドリンク用のＰＤＣＰフォーマットではなく、Ｕｕインターフェイス用のＰＤＣＰフォーマットによりパケット（トラフィック）を生成してもよい。これにより、ＵＥ１００−１において、Ｕｕインターフェイス用のＰＤＣＰフォーマットに変換する処理を低減することができる。
【０１８４】
ＵＥ１００−２は、生成したパケット（トラフィック）をＵＥ１００−１へ送信する。
【０１８５】
ステップＳ７０６において、ＵＥ１００−１は、パケットのヘッダに含まれる識別情報により、当該パケットの優先度を把握することができる。ＵＥ１００−１は、パケットの優先度に対応する適切なＤＲＢ（Ｄａｔａ  Ｒａｄｉｏ  Ｂｅａｒｅｒ）を理解する。ＵＥ１００−１は、識別情報に対応付けられた優先度を、パケットの優先度に決定できる。これにより、ＵＥ１００−１は、パケットの優先度を把握することができる。
【０１８６】
ステップＳ７０７において、ＵＥ１００−１は、パケットの優先度に対応する適切なＤＲＢを介して、当該パケットをｅＮＢ２００へ送信（転送）する。
【０１８７】
ＵＥ１００−１は、パケットを送信するために、パケットのヘッダに含まれる識別情報（ＥＰＳベアラＩＤ／ＬＣＩＤ）に対応するＥＰＳベアラ／ＬＣＩＤを用いてもよい。
【０１８８】
以上により、ＵＥ１００−１は、ＩＰレイヤでの処理によりパケットの優先度を把握しなくても、パケットの優先度を把握することができる。
【０１８９】
（Ｇ）動作例７
動作例７について、図１９から図２２を用いて説明する。図１９は、動作例７を説明するための図である。図２０は、動作例７を説明するためのフローチャートである。図２１及び図２２は、動作例７を説明するための図である。
【０１９０】
図１９に示すように、レイヤ２中継では、ＵＥ１００−１は、ＩＰレイヤにおける処理を実行しないため、ｅＮＢ２００からのパケットの中継先（すなわち、ＵＥ１００−２）を把握できない可能性がある。同様に、ｅＮＢ２００は、ＵＥ１００−１からのパケットの発生元（すなわち、ＵＥ１００−２）を把握できない可能性がある。このため、レイヤ２中継が適切に実行されない可能性がある。
【０１９１】
そこで、以下の動作が実行されてもよい。上述で説明した内容と同様の説明は省略する。
【０１９２】
図２０に示すように、ステップＳ８０１において、ＵＥ１００−２は、例えば、ＰＤＣＰレイヤにおいて、ＵＥ１００−２の識別子を含むヘッダを生成する（図２１及び図２２参照）。ＵＥ１００−２は、他のレイヤにおいて、ＵＥ１００−２の識別子を含むヘッダを生成してもよい。
【０１９３】
ＵＥ１００−２の識別子は、例えば、ＰｒｏＳｅを利用するためにネットワークにより割り当てられるＰｒｏＳｅ  ＩＤであってもよい。ＵＥ１００−２の識別子は、送信元を示すＳｏｕｒｃｅ  Ｌ２  ＩＤであってもよい（図２１参照）。ＵＥ１００−２の識別子は、接続中のリモートＵＥのリストのインデックス（Ｄｅｓｔｉｎａｔｉｏｎ  ｉｎｄｅｘ）であってもよい（図２２参照）。当該インデックスは、リレーＵＥがネットワークへ報告する際に用いられる。ＵＥ１００−２は、当該インデックスをＵＥ１００−１又はｅＮＢ２００から通知されてもよい。
【０１９４】
ステップＳ８０２において、ＵＥ１００−２は、生成したヘッダが付与されたパケット（トラフィック）をＵＥ１００−１を介して、ｅＮＢ２００へ送信する。
【０１９５】
ｅＮＢ２００は、ヘッダに含まれるＵＥ１００−２の識別子に基づいて、当該パケットの送信元を把握することができる。
【０１９６】
ｅＮＢ２００は、同様に、例えば、ＰＤＣＰレイヤにおいて、ＵＥ１００−２の識別子を含むヘッダを生成できる。
【０１９７】
ＵＥ１００−１は、ｅＮＢ２００からパケットを受信した場合、ヘッダに含まれるＵＥ１００−２の識別子により、パケットの送信先（中継先）を把握することができる。
【０１９８】
以上により、レイヤ２中継を適切に実行することができる。
【０１９９】
（Ｈ）動作例８
動作例８について、図２３を用いて説明する。図２３は、動作例８を説明するためのフローチャートである。
【０２００】
動作例８では、動作例７と異なる方法により、パケットの送信先／送信元を把握する。上述で説明した内容と同様の説明は省略する。
【０２０１】
ステップＳ９０１において、ｅＮＢ２００は、ＵＥ１００−２のパケット専用のＬＣＩＤを決定する。ｅＮＢ２００は、リモートＵＥ毎に利用可能な専用のＬＣＩＤを決定してもよい。ｅＮＢ２００は、１つのリモートＵＥに対して複数の専用のＬＣＩＤを決定してもよい。ＬＣＩＤは、ＵＥ１００−１とｅＮＢ２００との間でパケットを伝送するためのＬＣＩＤである。
【０２０２】
ステップＳ９０２において、ｅＮＢ２００は、決定されたＬＣＩＤをＵＥ１００−２のパケット専用のＬＣＩＤとして、ＵＥ１００−１へ通知する。
【０２０３】
ステップＳ９０３において、ＵＥ１００−１とｅＮＢ２００とは、ＵＥ１００−２のパケットを決定されたＬＣＩＤを用いて伝送する。これにより、ＵＥ１００−１及びｅＮＢ２００は、当該ＬＣＩＤを用いて伝送されるパケットがＵＥ１００−２のパケットであることを把握することができる。
【０２０４】
以上により、レイヤ２中継を適切に実行することができる。
【０２０５】
（Ｉ）動作例９
動作例９について、図２４を用いて説明する。図２４は、動作例９を説明するためのフローチャートである。
【０２０６】
動作例９では、動作例７及び８と異なる方法により、パケットの送信先／送信元を把握する。上述で説明した内容と同様の説明は省略する。
【０２０７】
図２４に示すように、ステップＳ１００１において、ｅＮＢ２００は、ＵＥ１００−２へＲＮＴＩ（Ｒａｄｉｏ  Ｎｅｔｗｏｒｋ  Ｔｅｍｐｏｒａｒｙ  Ｉｄｅｎｔｉｆｉｅｒ）を割り当てる。ｅＮＢ２００は、第２要求の受信に応じて、ＵＥ１００−２へＲＮＴＩを割り当ててもよい。ＲＮＴＩは、例えば、Ｃ−ＲＮＴＩ（Ｃｅｌｌ−ＲＮＴＩ）であってもよい。
【０２０８】
ステップＳ１００２において、ｅＮＢ２００は、ＵＥ１００−２へ割り当てたＲＮＴＩをＵＥ１００−１へ通知する。
【０２０９】
その後、ｅＮＢ２００は、ＵＥ１００−２のパケットを当該ＲＮＴＩを用いてエンコードする。ｅＮＢ２００は、エンコードされたパケットをＵＥ１００−１へ送信する。
【０２１０】
ステップＳ１００３において、ＵＥ１００−１は、ｅＮＢ２００から受信したパケットに対して、ＵＥ１００−２へ割り当てられたＲＮＴＩを用いてデコードを試みる。
【０２１１】
ステップＳ１００４において、ＵＥ１００−１は、デコードに成功したパケットをＵＥ１００−２のパケットであると判定する。ＵＥ１００−１は、デコードに失敗したパケットをＵＥ１００−２のパケットでないと判定する。
【０２１２】
ＵＥ１００−１は、デコードに成功したパケットをＵＥ１００−２へ転送（中継）する。
【０２１３】
同様に、ＵＥ１００−１は、ＵＥ１００−２からパケットを受信した場合、ＵＥ１００−２のパケットを当該ＲＮＴＩを用いてエンコードする。ＵＥ１００−１は、エンコードされたパケットをＵＥ１００−１へ送信する。
【０２１４】
ｅＮＢ２００は、ＵＥ１００−１から受信したパケットに対して、ＵＥ１００−２へ割り当てられたＲＮＴＩを用いてデコードを試みる。
【０２１５】
ｅＮＢ２００は、デコードに成功したパケットをＵＥ１００−２のパケットであると判定する。ｅＮＢ２００は、デコードに成功したパケットをＵＥ１００−２のパケットとして上位ネットワークへ送る。
【０２１６】
以上により、レイヤ２中継を適切に実行することができる。
【０２１７】
［その他の実施形態］
上述した実施形態によって、本出願の内容を説明したが、この開示の一部をなす論述及び図面は、本出願の内容を限定するものであると理解すべきではない。この開示から当業者には様々な代替実施形態、実施例及び運用技術が明らかとなろう。
【０２１８】
上述において、レイヤ２中継が実行される場合、ＵＥ間では、パケットのヘッダ（例えば、ＰＤＣＰレイヤ）が、レイヤ２中継に関する情報を必ず含んでもよい（動作例６参照）。例えば、レイヤ２中継に関する情報は、例えば、上述で説明した、ベアラＩＤ（ＥＰＳベアラＩＤ、ＤＲＢ  ＩＤ、ＬＣＩＤなど）、ＵＥ１００−２の識別子（リモートＵＥの識別子）、優先度の情報などである。
【０２１９】
レイヤ２中継が実行される場合、ＵＥ間では、アダプテーションレイヤを用いた通信が必ず適用されてもよい。ＵＥ１００−１とＵＥ１００−２間において、アダプテーションレイヤを介した通信が必ず実行されることにより、アダプテーションレイヤを介するかどうかの判断を省略してもよい。
【０２２０】
ＵＥ間では、アダプテーションレイヤを用いた通信が必ず適用される場合、ＵＥ−ｅＮＢ間でも、アダプテーションレイヤを用いた通信が必ず適用されてもよい。ＵＥ１００−１とＵＥ１００−２間においても、ＵＥ１００−１とｅＮＢ２００間においても、アダプテーションレイヤを介した通信が必ず実行されることにより、アダプテーションレイヤを介するかどうかの判断を省略してもよい。
【０２２１】
ＵＥ間では、アダプテーションレイヤを用いた通信が必ず適用される場合、ＵＥ−ｅＮＢ間でも、アダプテーションレイヤを用いた通信が適用されなくてもよい。例えば、ＵＥ−ｅＮＢ間では、リモートＵＥの識別子とＤＲＢ  ＩＤとが関連付けられることにより、アダプテーションレイヤが導入されなくてもよい。ｅＮＢ２００は、リモートＵＥの識別子とＤＲＢ  ＩＤとが関連付け（例えば、リスト）をＵＥ１００−１へ通知できる。ＵＥ１００−１とｅＮＢ２００とは、当該リストに基づいて、パケットの送信に用いられたＤＲＢ  ＩＤにより、どのリモートＵＥのパケットかを把握することができる。
【０２２２】
ＵＥ１００−１とＵＥ１００−２間で完了する通信（中継が必要ない通信）と、ＵＥ１００−１とｅＮＢ２００間の通信（中継が必要な通信）とを見分けるために、ＵＥ１００−２は、アダプテーションレイヤにおいて判定のための識別子をＵＥ１００−１へ通知してもよい。すなわち、ＵＥ１００−２は、判定のための識別子をパケットのヘッダに含めてもよい。判定のための識別子は、１ビットの識別子でもよい。判定のための識別子は、優先度を通知するための識別子であって、かつ、特別な値であってもよい。ＵＥ１００−１は、当該識別子に基づいてＵＥ１００−１とＵＥ１００−２との間で完了する通信（中継が必要ない通信）と、ＵＥ１００−１とｅＮＢ２００との間の通信（中継が必要な通信）とを見分けることができる。
【０２２３】
動作例４では、ｅＮＢ２００は、ＵＥ１００−１とｅＮＢ２００との間で用いられるＬＣＩＤを割り当てる一例を説明した。ｅＮＢ２００は、ＵＥ１００−１とＵＥ１００−２との間で用いられるＬＣＩＤをＵＥ１００−１（及びＵＥ１００−２）へ割り当ててもよい。ｅＮＢ２００は、アダプテーションレイヤを介したパケットの伝送が許可されるＬＣＩＤをＵＥ１００−１（及びＵＥ１００−２）へ通知してもよい。ｅＮＢ２００は、アダプテーションレイヤを介したパケットの伝送が許可されないＬＣＩＤをＵＥ１００−１（及びＵＥ１００−２）へ通知してもよい。ＵＥ１００−１は、当該ＬＣＩＤをＵＥ１００−２へ通知してもよい。
【０２２４】
ＵＥ１００−１は、アダプテーションレイヤを介したパケットの伝送が許可されるＬＣＩＤを用いて、ＵＥ１００−２からパケットを受けとった場合、アダプテーションレイヤを介したパケットの伝送であると把握できる。同様に、ＵＥ１００−２は、アダプテーションレイヤを介したパケットの伝送が許可されるＬＣＩＤを用いて、ＵＥ１００−１からパケットを受けとった場合、アダプテーションレイヤを介したパケットの伝送であると把握できる。
【０２２５】
ＵＥ１００−１は、アダプテーションレイヤを介したパケットの伝送が許可されないＬＣＩＤを用いて、ＵＥ１００−２からパケットを受けとった場合、アダプテーションレイヤを介したパケットの伝送でないと把握できる。同様に、ＵＥ１００−２は、アダプテーションレイヤを介したパケットの伝送が許可されないＬＣＩＤを用いて、ＵＥ１００−１からパケットを受けとった場合、アダプテーションレイヤを介したパケットの伝送でないと把握できる。
【０２２６】
ＵＥ１００−１及びＵＥ１００−２は、パケットに含まれるＬＣＩＤにより、アダプテーションレイヤを介したパケットの伝送であるか否かを把握してもよい。
【０２２７】
ＵＥ１００−１及びＵＥ１００−２は、アダプテーションレイヤを介したパケットの伝送が許可されないＬＣＩＤを、端末間で完結する通信（中継されないパケットの通信）に利用してもよい。
【０２２８】
上述の動作例６では、ＤＲＢで伝送すべきパケットの優先度の把握方法について説明した。同様にして、ＳＲＢ（Ｓｉｇｎａｌｌｉｎｇ  Ｒａｄｉｏ  Ｂｅａｒｅｒ）で伝送すべきパケットの優先度が把握されてもよい。ＳＲＢで伝送すべきパケットは、例えば、ＵＥ１００−１とｅＮＢ２００の間で送信（受信）される制御情報である。ＳＲＢで伝送すべきパケットは、ＵＥ１００−１とＭＭＥ３００の間で送信（受信）される制御情報であってもよい。ＳＲＢで伝送すべきパケットは、ＤＲＢで伝送すべきパケットよりも優先される必要があってもよい。
【０２２９】
ｅＮＢ２００は、ＳＲＢで伝送すべきパケットとＤＲＢで伝送すべきパケットとを区別できるように、ＤＲＢ  ＩＤを指定する情報をＵＥ１００−２（ＵＥ１００−２）へ提供してもよい。例えば、ｅＮＢ２００は、ＳＲＢで伝送すべきパケットには”ＤＲＢ  ＩＤ  ４”を指定してもよい。ｅＮＢ２００は、ＤＲＢで伝送すべきパケットにはそれ以外のＤＲＢ（例えばＤＲＢ  ５）を指定してもよい。ｅＮＢ２００は、識別情報と優先度とが対応付けられたリストをＵＥ１００−２へ提供してもよい。例えば、ＳＲＢで伝送すべきＤＲＢ  ＩＤと高優先度とが対応付けられてもよい。
【０２３０】
ｅＮＢ２００は、ＳＲＢで伝送されるべきパケットを、ＵＥ１００−１とｅＮＢ２００間で使用中のＳＲＢで伝送するよう指定してもよい。ＵＥ１００−１は、あたかも自身の制御信号（制御パケット）であるかのようにＵＥ１００−２から受信したパケットを送信してもよい。
【０２３１】
ｅＮＢ２００は、ＳＲＢで伝送されるべきパケットについては、ＵＥ１００−１が送信する制御信号として扱うように、Ｕ１００−１に対して設定してもよい。ＵＥ１００−１は、ＵＥ１００−２からＳＲＢで伝送されるべきパケットを受信した場合、自身の制御信号内のパラメータとして受信したパケットを格納してもよい。ＵＥ１００−１は、格納したＵＥ１００−２からのパケットを自身の制御信号としてｅＮＢ２００との間に確立されたＳＲＢで送信してもよい。ＵＥ１００−１は、ＵＥ１００−２からのパケットと共に、受信したＵＥ１００−２の識別子も合わせて制御信号内に格納してもよい。
【０２３２】
以上のように、制御パケットとユーザデータパケットとの優先度が区別されてもよい。これにより、制御信号（制御パケット）とデータ（ユーザデータパケット）との優先度を区別して把握することができる。
【０２３３】
上述したアダプテーションレイヤは、既存のＬＴＥシステムのプロトコルに存在しない新規レイヤであってもよい。アダプテーションレイヤは、ＬＴＥシステム上のプロトコルに存在するレイヤ（例えばＰＤＣＰ）の機能が拡張されたものであってもよい。従って、アダプテーションレイヤにおける動作として説明した内容は、例えば、（拡張された）ＰＤＣＰレイヤにおける動作であってもよい。
【０２３４】
上述した実施形態に係る動作（動作例）は、適宜組み合わせて実行されてもよい。上述した各シーケンスにおいて、必ずしも全ての動作が必須の構成ではない。例えば、各シーケンスにおいて、一部の動作のみが実行されてもよい。
【０２３５】
上述した実施形態では特に触れていないが、上述した各ノード（ＵＥ１００、ｅＮＢ２００など）のいずれかが行う各処理をコンピュータに実行させるプログラムが提供されてもよい。プログラムは、コンピュータ読取り可能媒体に記録されていてもよい。コンピュータ読取り可能媒体を用いれば、コンピュータにプログラムをインストールすることが可能である。ここで、プログラムが記録されたコンピュータ読取り可能媒体は、非一過性の記録媒体であってもよい。非一過性の記録媒体は、特に限定されるものではないが、例えば、ＣＤ−ＲＯＭやＤＶＤ−ＲＯＭ等の記録媒体であってもよい。
【０２３６】
或いは、ＵＥ１００及びｅＮＢ２００のいずれかが行う各処理を実行するためのプログラムを記憶するメモリ及びメモリに記憶されたプログラムを実行するプロセッサによって構成されるチップが提供されてもよい。
【０２３７】
上述した実施形態では、移動通信システムの一例としてＬＴＥシステムを説明したが、ＬＴＥシステムに限定されるものではなく、ＬＴＥシステム以外のシステムに本出願に係る内容を適用してもよい。
【０２３８】
［付記］
（検討）
リリース１３では、Ｌ３  ＰｒｏＳｅ  ＵＥ−ｔｏ−ＮＷリレー（Ｌ３リレー）が仕様化される。Ｌ３リレーの場合、リレーＵＥは、どのＱｏＳがリモートＵＥから受信されたトラフィックに適用されるか識別でき、どの受信トラフィックがどのリモートＵＥ宛であるかをＩＰパケット内のヘッダに基づいて識別できる。従って、リレーＵＥによって使用され、リモートＵＥのトラフィックの関連するＱｏＳを識別するために使用できるＡＳ（Ａｃｃｅｓｓ  Ｓｔｒａｔｕｍ）機能はなく、ｅＮＢからのどのトラフィックが特定のリモートＵＥのためであるかをリレーＵＥが識別するための既存の方法も存在しない。しかしながら、ｅＮＢがＬ３リレー動作のためにリモートＵＥを識別する必要はない。
【０２３９】
従って、Ｌ２  ＰｒｏＳｅ  ＵＥ−ｔｏ−ＮＷ  Ｒｅｌａｙでは、短距離インタフェースでリモートＵＥからのトラフィックのＱｏＳがどのように識別され（図２５）、且つ、Ｕｕインタフェース上のトラフィックにマッピングされたリモートＵＥがどのように識別されるかを検討する必要がある（図２６）。
【０２４０】
（１）短距離インタフェース
（１．１）ＱｏＳ識別
リモートＵＥのトラフィックからＱｏＳを識別するいくつかのソリューションがあり、大部分の企業は、短距離インタフェースが非３ＧＰＰアクセスである場合に有益であるべきであるアダプテーションレイヤの導入を検討している。しかしながら、３ＧＰＰアクセスに関しては、アダプテーションレイヤを導入する必要があるかどうかのコンセンサスはない、すなわち、ｅＮＢがＳｉｄｅｌｉｎｋ  無線ベアラ（ＳＬＲＢ）とＵｕ  ＤＲＢ間のマッピングを設定し、リレーＵＥが、サイドリンク上のＬＣＩＤに基づいてリモートＵＥのトラフィックに適したＵｕ  ＤＲＢを識別することをいくつかの企業が提案している。アダプテーションレイヤの導入と、ＳＬ  ＬＣＩＤのＵｕ  ＤＲＢへのマッピングの導入は両方とも実行可能である、しかしながら、目的の１つは、「次のユースケースをサポートする共通のソリューションの可能性を検討することである。（i）非３ＧＰＰアクセス上でのＵＥ−ｔｏ−ネットワーク中継。（ii）ＬＴＥサイドリンク上でのＵＥ−ｔｏ−ネットワーク中継。．．．（省略）」である。従って、短距離インタフェース上でのＱｏＳ識別は、例えば、アダプテーションレイヤの導入、例えば、アダプテーションレイヤ又はＰＤＣＰレイヤの拡張を用いて、ＲＬＣレイヤ上で達成されるべきである。
【０２４１】
提案１：  ３ＧＰＰアクセスと非３ＧＰＰアクセスの両方に共通のソリューションを導入するために、短距離インタフェース上のＱｏＳ識別は、例えば、アダプテーションレイヤ又はＰＤＣＰレイヤの拡張を用いて、ＲＬＣレイヤで達成されるべきである。
【０２４２】
（１．２）トラフィックアドレスの区別（リレーＵＥ又はｅＮＢ）
短距離インタフェースとして非３ＧＰＰアクセスが使用される場合、リレーＵＥは、Ｌ２リレーのための新しいプロトコルが使用されるべきかどうかをリレーＵＥが知る必要があるので、リモートＵＥのトラフィックがリレーＵＥ用かｅＮＢ用かを知る必要がある。ＵＥのトラフィックのアドレスを区別する方法の１つは、リモートＵＥがｅＮＢとのＬ２リレー接続を確立した場合、リモートＵＥがリレーＵＥへ送信するために常に新しいプロトコルを使用するというルールを導入することである。その結果として、リモートＵＥは、トラフィックが、新しいプロトコルにおいて、リレーＵＥ宛てかｅＮＢ宛てかを示すことができ、例えば、トラフィックが、アダプテーションレイヤのヘッダ又は拡張ＰＤＣＰヘッダにおいてｅＮＢのためのものであるかどうかを示すことができる。別の方法は、非３ＧＰＰアクセスを介したＬ２リレーに「ＬＷＡ  ＥｔｈｅｒＴｙｐｅ」と同様のメカニズムを導入することである。ＬＷＡでは、データがＷＬＡＮを介してＵＥに転送されるとき、ＷＴ（ＷＬＡＮ  Ｔｅｒｍｉｎａｔｉｏｎ）は、「ＬＷＡ  ＥｔｈｅｒＴｙｐｅ」を使用して、ＵＥにＬＷＡ操作に関連するデータの到着を通知する。従って、非３ＧＰＰアクセスを介したＬ２リレーに、同様のメカニズムを導入することは有効であるだろう。３ＧＰＰアクセスにも同じ問題が存在する。従って、常に新しいプロトコルを使用するルール又はＬ２リレートラフィックを識別するためのインディケーションが必要だろう。
【０２４３】
提案２：ＲＡＮ２は、短距離インタフェース上のトラフィックのアドレスを区別する方法について検討すべきである。
【０２４４】
（２）Ｕｕインターフェイス
（２．１）リモートＵＥ識別
リモートＵＥ識別のためのいくつかのソリューションがあり、例えば、新しいＭＡＣ  ＣＥを導入すること、ＲＬＣヘッダを拡張すること、アダプテーションレイヤを導入すること、そして、ＰＤＣＰヘッダを拡張することがある。送信側／受信側のリモートＵＥを識別するポイントでは、すべてのソリューションが実行可能である。しかしながら、ＭＡＣ  ＣＥのソリューションに関して、スケジューリング／ＬＣＰ（Ｌｉｎｋ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）の柔軟性を可能にするために、Ｕｕ上でのリモートＵＥ識別のためのソリューションは、異なるリモートＵＥのトラフィックをＭＡＣ  ＰＤＵに多重化することを可能にすべきことが有用である。
【０２４５】
提案３：ＲＡＮ２は、異なるリモートＵＥのトラフィックをＭＡＣ  ＰＤＵに多重化することを可能にする、Ｕｕインタフェース上のリモートＵＥ識別のためのソリューションを導入すべきである。
【０２４６】
（２．２）異なるＱｏＳを持つ複数のＵｕ  ＤＲＢ
Ｕｕ上のベアラモデリングに関して、「Ｕｕ上の単一のＤＲＢにマッピングされた複数のリモートＵＥを有する単一のＵｕ  ＤＲＢモデル」が検討されている。多数のリモートＵＥをサポートするための複雑さを制限する観点から、単一のＵｕ  ＤＲＢモデルが適していると思われる。しかしながら、リモートＵＥから／へのトラフィックのＱｏＳ処理に関して、異なるＱｏＳに対して複数のＵｕ  ＤＲＢを構成するオプションを有することは有益である。リモートＵＥは、スマートウォッチ、心拍モニタ、ＶＲ（Ｖｉｒｔｕａｌ  Ｒｅａｌｉｔｙ）メガネなどの異なる形態で実現可能であると想定できるので、一般にリモートＵＥは、様々なトラフィックを利用することが期待される。
【０２４７】
提案４：リモートＵＥから／へのトラフィックに対するＱｏＳ処理に関して、異なるＱｏＳに対して複数のＵｕ  ＤＲＢを構成するオプションを有することは有益である。
【０２４８】
米国仮出願第６２／４１７５４４号（２０１６年１１月４日出願）の全内容が、参照により、本願明細書に組み込まれている。
【図１】
0006718103.tif 000002
【図２】
0006718103.tif 000003
【図３】
0006718103.tif 000004
【図４】
0006718103.tif 000005
【図５】
0006718103.tif 000006
【図６】
0006718103.tif 000007
【図７】
0006718103.tif 000008
【図８】
0006718103.tif 000009
【図９】
0006718103.tif 000010
【図１０】
0006718103.tif 000011
【図１１】
0006718103.tif 000012
【図１２】
0006718103.tif 000013
【図１３】
0006718103.tif 000014
【図１４】
0006718103.tif 000015
【図１５】
0006718103.tif 000016
【図１６】
0006718103.tif 000017
【図１７】
0006718103.tif 000018
【図１８】
0006718103.tif 000019
【図１９】
0006718103.tif 000020
【図２０】
0006718103.tif 000021
【図２１】
0006718103.tif 000022
【図２２】
0006718103.tif 000023
【図２３】
0006718103.tif 000024
【図２４】
0006718103.tif 000025
【図２５】
0006718103.tif 000026
【図２６】
0006718103.tif 000027