特表 2018-525857 リモートＵＥに応対するＰＲＯＳＥリレーのための改善されたスケジューリングメカニズム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公表特許公報(A)

(11)【公表番号】特表2018-525857(P2018-525857A)

(43)【公表日】2018年9月6日

(54)【発明の名称】リモートＵＥに応対するＰＲＯＳＥリレーのための改善されたスケジューリングメカニズム

(51)【国際特許分類】

   H04W 88/04 20090101AFI20180810BHJP

   H04W 72/04 20090101ALI20180810BHJP

   H04W 72/12 20090101ALI20180810BHJP

   H04W 92/18 20090101ALI20180810BHJP

【ＦＩ】

   H04W88/04

   H04W72/04

   H04W72/12

   H04W92/18

【審査請求】未請求

【予備審査請求】未請求

【全頁数】67

(21)【出願番号】特願2017-558767(P2017-558767)

(86)(22)【出願日】2016年6月21日

(85)【翻訳文提出日】2017年11月9日

(86)【国際出願番号】JP2016002974

(87)【国際公開番号】WO2017022164

(87)【国際公開日】20170209

(31)【優先権主張番号】15179352.8

(32)【優先日】2015年7月31日

(33)【優先権主張国】EP

(81)【指定国】 AP(BW,GH,GM,KE,LR,LS,MW,MZ,NA,RW,SD,SL,ST,SZ,TZ,UG,ZM,ZW),EA(AM,AZ,BY,KG,KZ,RU,TJ,TM),EP(AL,AT,BE,BG,CH,CY,CZ,DE,DK,EE,ES,FI,FR,GB,GR,HR,HU,IE,IS,IT,LT,LU,LV,MC,MK,MT,NL,NO,PL,PT,RO,RS,SE,SI,SK,SM,TR),OA(BF,BJ,CF,CG,CI,CM,GA,GN,GQ,GW,KM,ML,MR,NE,SN,TD,TG),AE,AG,AL,AM,AO,AT,AU,AZ,BA,BB,BG,BH,BN,BR,BW,BY,BZ,CA,CH,CL,CN,CO,CR,CU,CZ,DE,DK,DM,DO,DZ,EC,EE,EG,ES,FI,GB,GD,GE,GH,GM,GT,HN,HR,HU,ID,IL,IN,IR,IS,JP,KE,KG,KN,KP,KR,KZ,LA,LC,LK,LR,LS,LU,LY,MA,MD,ME,MG,MK,MN,MW,MX,MY,MZ,NA,NG,NI,NO,NZ,OM,PA,PE,PG,PH,PL,PT,QA,RO,RS,RU,RW,SA,SC,SD,SE,SG,SK,SL,SM,ST,SV,SY,TH,TJ,TM,TN,TR,TT,TZ,UA,UG,US

(71)【出願人】

【識別番号】514136668

【氏名又は名称】パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ

【氏名又は名称原語表記】Ｐａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ

(74)【代理人】

【識別番号】100105050

【弁理士】

【氏名又は名称】鷲田 公一

(72)【発明者】

【氏名】ローア ヨアキム

(72)【発明者】

【氏名】バス マリック プラティーク

(72)【発明者】

【氏名】堀 貴子

【テーマコード（参考）】

5K067

【Ｆターム（参考）】

5K067AA11

5K067DD17

5K067DD34

5K067EE02

5K067EE10

5K067EE25

5K067HH22

(57)【要約】

本開示は、リモートユーザ機器（ＵＥ）に対するリレーとして働くリレーＵＥのために無線リソースをスケジュールするための方法に関する。リモートデータが、リモートＵＥとＢＳとの間でリレーＵＥによって中継される。リモートスケジューリング識別情報が、リモートデータを通知するリモート論理チャネルをアドレス指定するために設定される。リレースケジューリング識別情報が、リレーデータを通知する１つまたは複数のリレー論理チャネルをアドレス指定するために設定される。リレーＵＥは、ＢＳとリモートデータを交換するためにリレーＵＥに無線リソースを割り当てるリモートリソース割当てをＢＳから受信し、リモートリソース割当てはリモートスケジューリング識別情報にアドレス指定される。リレーＵＥは、ＢＳとリレーデータを交換するためにリレーＵＥに無線リソースを割り当てるリレーリソース割当てをＢＳからさらに受信し、リレーリソース割当てはリレースケジューリング識別情報にアドレス指定される。

【特許請求の範囲】

【請求項1】

移動通信システムにおけるリレーユーザ機器のために無線リソースをスケジュールするための方法であって、前記リレーユーザ機器が、それぞれ１つまたは複数のリモートユーザ機器に対するリレーとして働くことが可能であるためのリレー機能性をサポートし、そのため前記１つまたは複数のリモートユーザ機器から発信する、または前記リモートユーザ機器に宛てられるリモートデータが、前記１つまたは複数のリモートユーザ機器と無線基地局との間で前記リレーユーザ機器によって中継され、
リモートスケジューリング識別情報が、前記リレーユーザ機器と前記無線基地局との間で前記リモートデータを通知する１つまたは複数のリモート論理チャネルをアドレス指定するために設定され、リレースケジューリング識別情報が、前記リレーユーザ機器と前記無線基地局との間で、前記リレーユーザ機器から発信する、または前記リレーユーザ機器に宛てられるリレーデータを通知する１つまたは複数のリレー論理チャネルをアドレス指定するために設定され、
前記リレーユーザ機器によって行われる以下のステップ：
前記無線基地局と前記リモートデータを交換するために前記リレーユーザ機器に無線リソースを割り当てるリモートリソース割当てを前記無線基地局から受信するステップであって、前記リモートリソース割当てが前記リモートスケジューリング識別情報にアドレス指定される、ステップと、
前記無線基地局と前記リレーデータを交換するために前記リレーユーザ機器に無線リソースを割り当てるリレーリソース割当てを前記無線基地局から受信するステップであって、前記リレーリソース割当てが前記リレースケジューリング識別情報にアドレス指定される、ステップと、
を含む、方法。

【請求項2】

リレーメディアアクセス制御（ＭＡＣ）エンティティおよびリモートＭＡＣエンティティが前記リレーユーザ機器に構成され、前記リレーＭＡＣエンティティが、前記リレーデータを扱うための前記リレー論理チャネルと関連づけられ、前記リモートＭＡＣエンティティが、前記リモートデータを扱うための前記リモート論理チャネルと関連づけられ、
前記リモートスケジューリング識別情報が前記リモート論理チャネルと、および／または前記リモートＭＡＣエンティティと関連づけられ、前記リレースケジューリング識別情報が前記リレー論理チャネルと、および／または前記リレーＭＡＣエンティティと関連づけられ、
好ましくは、ハイブリッド自動再送要求（ＨＡＲＱ）エンティティが、前記リモートデータの送信および前記リレーデータの送信に再送信制御を提供するために前記リモートＭＡＣエンティティと前記リレーＭＡＣエンティティとの間で共有され、または前記リモートＭＡＣエンティティがリモートＨＡＲＱエンティティを備え、かつ前記リレーＭＡＣエンティティがリレーＨＡＲＱエンティティを備え、
好ましくは、リレー論理チャネルグループが前記リレーＭＡＣエンティティに対して規定され、前記リレー論理チャネルの各々が前記リレー論理チャネルグループの１つに割り当てられ、かつリモート論理チャネルグループが前記リモートＭＡＣエンティティに対して規定され、前記リモート論理チャネルの各々が前記リモート論理チャネルグループの１つに割り当てられ、
好ましくは、リレー論理チャネルＩＤが前記リレーＭＡＣエンティティに対して規定され、前記リレー論理チャネルの各々に前記リレー論理チャネルＩＤの１つが割り当てられ、かつリモート論理チャネルＩＤが前記リモートＭＡＣエンティティに対して規定され、前記リモート論理チャネルの各々に前記リモート論理チャネルＩＤの１つが割り当てられる、
請求項１に記載の方法。

【請求項3】

前記リレーユーザ機器によって行われる以下のステップ：
前記無線基地局への送信のために利用可能な前記リモートデータを有する前記リモート論理チャネルに、前記リモートリソース割当てで割り当てられる前記無線リソースを割り当てるように、リモート論理チャネル優先順位付け（ＬＣＰ）手順を行い、好ましくはそれによって、前記リモートデータを通知する１つまたは複数のトランスポートブロックを生成するステップ、および／または、
前記無線基地局への送信のために利用可能な前記リレーデータを有する前記リレー論理チャネルに、前記リレーリソース割当てで割り当てられる前記無線リソースを割り当てるように、リレー論理チャネル優先順位付け（ＬＣＰ）手順を行い、好ましくはそれによって、前記リレーデータを通知する１つまたは複数のトランスポートブロックを生成するステップ、
をさらに含む、請求項１または２に記載の方法。

【請求項4】

前記リレーユーザ機器によって行われる以下のステップ：
前記無線基地局に送信されるために前記リレーユーザ機器でバッファされる前記リレーデータの量に基づいてリレーバッファ状況報告を生成するステップと、
前記無線基地局に送信されるために前記リレーユーザ機器でバッファされる前記リモートデータの量に基づいてリモートバッファ状況報告を生成するステップと、
前記無線基地局に前記リレーバッファ状況報告および前記リモートバッファ状況報告を送信するステップと、
をさらに含む、請求項１から３のいずれか一項に記載の方法。

【請求項5】

少なくとも１つのリモートサイドリンク論理チャネルが、前記リモートデータをそれぞれ通知するために、前記リレーユーザ機器と前記１つまたは複数のリモートユーザ機器のそれぞれ各々との間に確立され、
前記リレーユーザ機器によって行われる以下のステップ：
第１の論理チャネル優先度の前記少なくとも１つのリモートサイドリンク論理チャネルの各々を、前記対応する同じまたは同様の第１の論理チャネル優先度のリモート論理チャネルに多重化するステップ、および／または、
第１の論理チャネル優先度の前記リモート論理チャネルを、前記対応する同じまたは同様の第１の論理チャネル優先度のリモートサイドリンク論理チャネルに逆多重化するステップ、
を含む、請求項１から４のいずれか一項に記載の方法。

【請求項6】

無線リソースがスケジュールされるためのリレーユーザ機器であって、
前記リレーユーザ機器が、それぞれ１つまたは複数のリモートユーザ機器に対するリレーとして働くことが可能であるためのリレー機能性をサポートし、そのため前記１つまたは複数のリモートユーザ機器から発信する、または前記リモートユーザ機器に宛てられるリモートデータが、前記１つまたは複数のリモートユーザ機器と無線基地局との間で前記リレーユーザ機器によって中継され、
リモートスケジューリング識別情報が、前記リレーユーザ機器と前記無線基地局との間で前記リモートデータを通知する１つまたは複数のリモート論理チャネルをアドレス指定するために設定され、リレースケジューリング識別情報が、前記リレーユーザ機器と前記無線基地局との間で、前記リレーユーザ機器から発信する、または前記リレーユーザ機器に宛てられるリレーデータを通知する１つまたは複数のリレー論理チャネルをアドレス指定するために設定され、
前記無線基地局と前記リモートデータを交換するために前記リレーユーザ機器に無線リソースを割り当てるリモートリソース割当てを前記無線基地局から受信するように構成され、前記リモートリソース割当てが前記リモートスケジューリング識別情報にアドレス指定される、受信器を備え、
前記受信器は、前記無線基地局と前記リレーデータを交換するために前記リレーユーザ機器に無線リソースを割り当てるリレーリソース割当てを前記無線基地局から受信するように構成され、前記リレーリソース割当てが前記リレースケジューリング識別情報にアドレス指定される、リレーユーザ機器。

【請求項7】

リレーメディアアクセス制御（ＭＡＣ）エンティティおよびリモートＭＡＣエンティティを備え、前記リレーＭＡＣエンティティが、前記リレーデータを扱うための前記リレー論理チャネルと関連づけられ、前記リモートＭＡＣエンティティが、前記リモートデータを扱うための前記リモート論理チャネルと関連づけられ、
前記リモートスケジューリング識別情報が前記リモート論理チャネルと、および／または前記リモートＭＡＣエンティティと関連づけられ、前記リレースケジューリング識別情報が前記リレー論理チャネルと、および／または前記リレーＭＡＣエンティティと関連づけられ、
好ましくは、ハイブリッド自動再送要求（ＨＡＲＱ）エンティティが、前記リモートデータの送信および前記リレーデータの送信に再送信制御を提供するために、リモートＭＡＣエンティティと前記リレーＭＡＣエンティティとの間で共有され、または前記リモートＭＡＣエンティティがリモートＨＡＲＱエンティティを備え、かつ前記リレーＭＡＣエンティティがリレーＨＡＲＱエンティティを備え、
好ましくは、リレー論理チャネルグループが前記リレーＭＡＣエンティティに対して規定され、前記リレー論理チャネルの各々が前記リレー論理チャネルグループの１つに割り当てられ、かつリモート論理チャネルグループが前記リモートＭＡＣエンティティに対して規定され、前記リモート論理チャネルの各々が前記リモート論理チャネルグループの１つに割り当てられ、
好ましくは、リレー論理チャネルＩＤが前記リレーＭＡＣエンティティに対して規定され、前記リレー論理チャネルの各々に前記リレー論理チャネルＩＤの１つが割り当てられ、かつリモート論理チャネルＩＤが前記リモートＭＡＣエンティティに対して規定され、前記リモート論理チャネルの各々に前記リモート論理チャネルＩＤの１つが割り当てられる、
請求項６に記載のリレーユーザ機器。

【請求項8】

前記無線基地局への送信のために利用可能な前記リモートデータを有する前記リモート論理チャネルに、前記リモートリソース割当てで割り当てられる前記無線リソースを割り当てるように、リモート論理チャネル優先順位付け（ＬＣＰ）手順を行い、好ましくはそれによって、前記リモートデータを通知する１つまたは複数のトランスポートブロックを生成するように構成されるプロセッサ、および／または、
前記無線基地局への送信のために利用可能な前記リレーデータを有する前記リレー論理チャネルに、前記リレーリソース割当てで割り当てられる前記無線リソースを割り当てるように、リレー論理チャネル優先順位付け（ＬＣＰ）手順を行い、好ましくはそれによって、前記リレーデータを通知する１つまたは複数のトランスポートブロックを生成するように構成されるプロセッサ、
をさらに備える、請求項６または７に記載のリレーユーザ機器。

【請求項9】

前記無線基地局に送信されるために前記リレーユーザ機器でバッファされる前記リレーデータの量に基づいてリレーバッファ状況報告を生成するように構成されるプロセッサであって、
前記無線基地局に送信されるために前記リレーユーザ機器でバッファされる前記リモートデータの量に基づいてリモートバッファ状況報告を生成するようにさらに構成されるプロセッサと、
前記無線基地局に前記リレーバッファ状況報告および前記リモートバッファ状況報告を送信するように構成される送信器と、
をさらに備える、請求項６から９のいずれか一項に記載のリレーユーザ機器。

【請求項10】

移動通信システムにおけるリレーユーザ機器のために無線リソースをスケジュールするための方法であって、前記リレーユーザ機器が、それぞれ１つまたは複数のリモートユーザ機器に対するリレーとして働くことが可能であるためのリレー機能性をサポートし、そのため前記１つまたは複数のリモートユーザ機器から発信する、または前記リモートユーザ機器に宛てられるリモートデータが、前記１つまたは複数のリモートユーザ機器と無線基地局との間で前記リレーユーザ機器によって中継され、
１つまたは複数のリレー論理チャネルが、前記リレーユーザ機器と前記無線基地局との間で、前記リレーユーザ機器から発信する、または前記リレーユーザ機器に宛てられるリレーデータを通知するために確立され、
１つまたは複数のリモート論理チャネルが、前記リレーユーザ機器と前記無線基地局との間で、前記１つまたは複数のリモートユーザ機器から発信する、または前記リモートユーザ機器に宛てられるリモートデータを通知するために確立され、
リレー論理チャネルグループが規定され、前記リレー論理チャネルの各々が前記リレー論理チャネルグループの１つに割り当てられ、かつリモート論理チャネルグループが規定され、前記リモート論理チャネルの各々が前記リモート論理チャネルグループの１つに割り当てられ、
前記リレーユーザ機器によって行われる以下のステップ：
リレー論理チャネルグループに対して１つのバッファサイズフィールドを備えるリレーバッファ状況報告を生成するステップであって、前記１つのバッファサイズフィールドが、前記リレー論理チャネルグループのすべてのリレー論理チャネルに渡って送信のために利用可能な総リレーデータ量を示す、ステップと、
リモート論理チャネルグループに対して１つのバッファサイズフィールドを備えるリモートバッファ状況報告を生成するステップであって、前記１つのバッファサイズフィールドが、前記リモート論理チャネルグループのすべてのリモート論理チャネルに渡って送信のために利用可能な総リモートデータ量を示す、ステップと、
前記無線基地局に前記リレーバッファ状況報告および前記リモートバッファ状況報告を送信するステップと、
前記無線基地局に前記リモートデータおよび前記リレーデータを送信するために前記リレーユーザ機器に無線リソースを割り当てるアップリンクリソース割当てを前記無線基地局から受信するステップであって、前記アップリンクリソース割当てが、前記リレーバッファ状況報告および前記リモートバッファ状況報告に基づいて前記無線基地局によって生成される、ステップと、
を含む、方法。

【請求項11】

メディアアクセス制御（ＭＡＣ）エンティティが前記リレーユーザ機器に構成され、前記ＭＡＣエンティティが、前記リモートデータおよび前記リレーデータを扱うための前記リレー論理チャネルおよび前記リモート論理チャネルと関連づけられ、
好ましくは、リレー論理チャネルＩＤが前記ＭＡＣエンティティに対して規定され、前記リレー論理チャネルの各々に前記リレー論理チャネルＩＤの１つが割り当てられ、かつリモート論理チャネルＩＤが前記ＭＡＣエンティティに対して規定され、前記リモート論理チャネルの各々に前記リモート論理チャネルＩＤの１つが割り当てられる、
請求項１０に記載の方法。

【請求項12】

前記リレーユーザ機器によって行われる以下のステップ：
前記無線基地局への送信のために利用可能な前記リモートデータを有する前記リモート論理チャネルに、および、
前記無線基地局への送信のために利用可能な前記リレーデータを有する前記リレー論理チャネルに、
前記アップリンクリソース割当てで割り当てられる前記無線リソースを割り当てるように、論理チャネル優先順位付け（ＬＣＰ）手順を行い、
好ましくはそれによって、前記リモートデータおよび前記リレーデータを通知する１つまたは複数のトランスポートブロックを生成するステップと、
好ましくは、前記ＬＣＰ手順の間、無線リソースを、送信のために利用可能なデータを持つ前記リレー論理チャネルおよび前記リモート論理チャネルに、前記リレー論理チャネルおよび前記リモート論理チャネルの各々が関連づけられる論理チャネル優先度の降順に割り当てるステップと、
好ましくは、前記ＬＣＰ手順の間、特定の論理チャネル優先度を有するリモート論理チャネルを、同じ特定の論理チャネル優先度を有するリレー論理チャネルより優先させるステップと、
をさらに含む、請求項１０または１１に記載の方法。

【請求項13】

少なくとも１つのリモートサイドリンク論理チャネルが、前記リモートデータをそれぞれ通知するために、前記リレーユーザ機器と前記１つまたは複数のリモートユーザ機器のそれぞれ各々との間に確立され、
前記リレーユーザ機器によって行われる以下のステップ：
第１の論理チャネル優先度の前記少なくとも１つのリモートサイドリンク論理チャネルの各々を、前記対応する同じまたは同様の第１の論理優先度のリモート論理チャネルに多重化するステップ、および／または、
第１の論理チャネル優先度の前記リモート論理チャネルを、前記対応する同じまたは同様の第１の論理チャネル優先度のリモートサイドリンク論理チャネルに逆多重化するステップ、
を含む、請求項１０から１２のいずれか一項に記載の方法。

【請求項14】

無線リソースがスケジュールされるためのリレーユーザ機器であって、
前記リレーユーザ機器が、それぞれ１つまたは複数のリモートユーザ機器に対するリレーとして働くことが可能であるためのリレー機能性をサポートし、そのため前記１つまたは複数のリモートユーザ機器から発信する、または前記リモートユーザ機器に宛てられるリモートデータが、前記１つまたは複数のリモートユーザ機器と無線基地局との間で前記リレーユーザ機器によって中継され、
１つまたは複数のリレー論理チャネルが、前記リレーユーザ機器と前記無線基地局との間で、前記リレーユーザ機器から発信する、または前記リレーユーザ機器に宛てられるリレーデータを通知するために確立され、
１つまたは複数のリモート論理チャネルが、前記リレーユーザ機器と前記無線基地局との間で、前記１つまたは複数のリモートユーザ機器から発信する、または前記リモートユーザ機器に宛てられるリモートデータを通知するために確立され、
リレー論理チャネルグループが規定され、前記リレー論理チャネルの各々が前記リレー論理チャネルグループの１つに割り当てられ、かつリモート論理チャネルグループが規定され、前記リモート論理チャネルの各々が前記リモート論理チャネルグループの１つに割り当てられ、
リレー論理チャネルグループに対して１つのバッファサイズフィールドを備えるリレーバッファ状況報告を生成するように構成され、前記１つのバッファサイズフィールドが、前記リレー論理チャネルグループのすべてのリレー論理チャネルに渡って送信のために利用可能な総リレーデータ量を示す、プロセッサであって、
リモート論理チャネルグループに対して１つのバッファサイズフィールドを備えるリモートバッファ状況報告を生成するようにさらに構成され、前記１つのバッファサイズフィールドが、前記リモート論理チャネルグループのすべてのリモート論理チャネルに渡って送信のために利用可能な総リモートデータ量を示す、プロセッサと、
前記無線基地局に前記リレーバッファ状況報告および前記リモートバッファ状況報告を送信するように構成される送信器と、
前記無線基地局に前記リモートデータおよび前記リレーデータを送信するために前記リレーユーザ機器に無線リソースを割り当てるアップリンクリソース割当てを前記無線基地局から受信するように構成され、前記アップリンクリソース割当てが、前記リレーバッファ状況報告および前記リモートバッファ状況報告に基づいて前記無線基地局によって生成される、受信器と、
を備える、リレーユーザ機器。

【請求項15】

前記プロセッサが、
前記無線基地局への送信のために利用可能な前記リモートデータを有する前記リモート論理チャネルに、および、
前記無線基地局への送信のために利用可能な前記リレーデータを有する前記リレー論理チャネルに、
前記アップリンクリソース割当てで割り当てられる前記無線リソースを割り当てるように、論理チャネル優先順位付け（ＬＣＰ）手順を行い、
好ましくはそれによって、前記リモートデータおよび前記リレーデータを通知する１つまたは複数のトランスポートブロックを生成するように構成され、
好ましくは、前記プロセッサが、前記ＬＣＰ手順の間、無線リソースを、送信のために利用可能なデータを持つ前記リレー論理チャネルおよび前記リモート論理チャネルに、前記リレー論理チャネルおよび前記リモート論理チャネルの各々が関連づけられる論理チャネル優先度の降順に割り当てるようにさらに構成される、
請求項１４に記載のリレーユーザ機器。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、リモートユーザ機器に対するリレーとして働くリレーユーザ機器に無線リソースをスケジュールするための方法に関する。本開示は、本明細書に記載される方法に関与するためのリレーユーザ機器および無線基地局も提供している。

【背景技術】

【0002】

＜ロングタームエボリューション（ＬＴＥ：Long Term Evolution）＞
ＷＣＤＭＡ（登録商標）無線アクセス技術に基づく第３世代移動システム（３Ｇ）が世界中至る所で広範に展開されつつある。この技術を強化または進化させる際の第１段階は、競争力の高い無線アクセス技術をもたらす、ＨＳＤＰＡ（High-Speed Downlink Packet Access）および、ＨＳＵＰＡ（High Speed Uplink Packet Access）とも称される強化型アップリンクを導入することを伴う。

【0003】

さらに増加するユーザ需要に備え、かつ新たな無線アクセス技術に対して競争力があるために、３ＧＰＰは、ＬＴＥと呼ばれる新たな移動通信システムを導入した。ＬＴＥは、次の１０年間、高速データおよびメディア転送の他に大容量音声サポートの通信事業者要求を満たすように設計されている。

【0004】

Ｅｖｏｌｖｅｄ ＵＴＲＡ（UMTS Terrestrial Radio Access）および進化型ＵＴＲＡＮ（UMTS Terrestrial Radio Access Network）と呼ばれるＬＴＥに関する作業項目（ＷＩ：work item）仕様がＲｅｌｅａｓｅ８（ＬＴＥ Ｒｅｌ．８）として完成されている。ＬＴＥシステムは、低遅延および低コストでフルＩＰベースの機能性を提供する効率的なパケットベースの無線アクセスおよび無線アクセスネットワークを表している。ＬＴＥでは、所与のスペクトルを用いて柔軟なシステム展開を達成するために、１．４、３．０、５．０、１０．０、１５．０および２０．０ＭＨｚなどのスケーラブルな複数の送信帯域幅が設定される。ダウンリンクでは、直交周波数分割多重（ＯＦＤＭ：Orthogonal Frequency Division Multiplexing）ベースの無線アクセスが、低シンボルレートによるマルチパス干渉（ＭＰＩ）に対するその固有の耐性、サイクリックプレフィックス（ＣＰ：Cyclic Prefix）の使用、および異なる送信帯域幅の配置に対するその親和性のために採用された。ユーザ機器（ＵＥ：User Equipment）の制限される送信電力を考慮すると、ピークデータレートの向上よりも広域カバレージを備えることが優先されるため、アップリンクではシングルキャリア周波数分割多元接続（ＳＣ−ＦＤＭＡ：Single-Carrier Frequency Division Multiple Access）ベースの無線アクセスが採用された。ＬＴＥ Ｒｅｌ．８／９では、多くの主要なパケット無線アクセス技法が、ＭＩＭＯ（Multiple Input Multiple Output）チャネル送信技術を含めて利用され、高効率の制御シグナリング構造が達成される。

【0005】

＜ＬＴＥアーキテクチャ＞
全体的なＬＴＥアーキテクチャを図１に示す。Ｅ−ＵＴＲＡＮはｅＮｏｄｅＢから構成され、ユーザ機器（ＵＥ）に向けたＥ−ＵＴＲＡユーザプレーン（ＰＤＣＰ／ＲＬＣ／ＭＡＣ／ＰＨＹ）プロトコルの終端および制御プレーン（ＲＲＣ）プロトコルの終端を提供する。ｅＮｏｄｅＢ（ｅＮＢ）は、物理（ＰＨＹ）、メディアアクセス制御（ＭＡＣ）、無線リンク制御（ＲＬＣ）および、ユーザプレーンヘッダ圧縮および暗号化の機能を含むパケットデータ制御プロトコル（ＰＤＣＰ）レイヤをホストする。ｅＮｏｄｅＢは、制御プレーンに対応する無線リソース制御（ＲＲＣ：Radio Resource Control）機能も提供する。ｅＮｏｄｅＢは、無線リソース管理、アドミッションコントロール、スケジューリング、ネゴシエートされたアップリンクサービス品質（ＱｏＳ：Quality of Service）の実施、セル情報ブロードキャスト、ユーザおよび制御プレーンデータの暗号化／解読、ならびにダウンリンク／アップリンクユーザプレーンパケットヘッダの圧縮／解凍を含む多くの機能を行う。ｅＮｏｄｅＢは、Ｘ２インタフェースを用いて相互接続される。

【0006】

ｅＮｏｄｅＢはまた、Ｓ１インタフェースを用いてＥＰＣ（Evolved Packet Core）に、より詳細には、Ｓ１−ＭＭＥを用いてＭＭＥ（Mobility Management Entity）に接続され、Ｓ１−Ｕを用いてサービングゲートウェイ（ＳＧＷ：Serving Gateway）に接続される。Ｓ１インタフェースは、ＭＭＥ／サービングゲートウェイとｅＮｏｄｅＢとの間の多対多の関係をサポートする。ＳＧＷは、ユーザデータパケットをルーティングおよび転送する一方で、ｅＮｏｄｅＢ間でのハンドオーバ中にユーザプレーンのためのモビリティアンカとして、および、（Ｓ４インタフェースを終端し、２Ｇ／３ＧシステムとＰＤＮ ＧＷとの間のトラヒックを中継する）ＬＴＥと他の３ＧＰＰ技術との間のモビリティのためのアンカとして機能する。アイドル（Idle）状態のユーザ機器に対しては、ＳＧＷはダウンリンクデータを終端し、ユーザ機器に対してダウンリンクデータが到着するとページングをトリガする。ＳＧＷはユーザ機器コンテキスト、例えば、ＩＰベアラサービスのパラメータ、またはネットワーク内部ルーティング情報を管理および記憶する。ＳＧＷは、合法的傍受の場合にはユーザトラヒックの複製も行う。

【0007】

ＭＭＥは、ＬＴＥアクセスネットワークにとって主要な制御ノードである。ＭＭＥは、再送を含むアイドルモードのユーザ機器のトラッキングおよびページング手順に対する役割を担う。ＭＭＥはベアラアクティブ化／非アクティブ化プロセスに関与し、かつ初期アタッチ時およびコアネットワーク（ＣＮ：Core Network）ノード再配置を伴うＬＴＥ内ハンドオーバ時にユーザ機器に対するＳＧＷを選択する役割も担う。ＭＭＥは、（ＨＳＳと対話することによって）ユーザを認証する役割を担う。非アクセス層（ＮＡＳ：Non-Access Stratum）シグナリングはＭＭＥで終端し、ＭＭＥは一時的な識別子の生成およびユーザ機器への割当ての役割も担う。ＭＭＥは、サービスプロバイダのＰＬＭＮ（Public Land Mobile Network）にキャンプするためにユーザ機器の認証を確認し、ユーザ機器のローミング制限を実施する。ＭＭＥは、ＮＡＳシグナリングに対する暗号化／整合性保護のためのネットワークにおける終端点であり、セキュリティキー管理を扱う。シグナリングの合法的傍受もＭＭＥによってサポートされる。ＭＭＥは、Ｓ３インタフェースがＳＧＳＮからＭＭＥで終端して、ＬＴＥおよび２Ｇ／３Ｇアクセスネットワーク間のモビリティのための制御プレーン機能も提供する。ＭＭＥは、ローミングユーザ機器に対してホームＨＳＳに向けたＳ６ａインタフェースも終端する。

【0008】

＜ＬＴＥにおけるコンポーネントキャリア構造＞
３ＧＰＰ ＬＴＥシステムのダウンリンクコンポーネントキャリアは、時間−周波数領域で、いわゆるサブフレームに分割される。３ＧＰＰ ＬＴＥでは、図２に図示すように、各サブフレームは２つのダウンリンクスロットに分割され、ここでは第１のダウンリンクスロットは第１のＯＦＤＭシンボル内に制御チャネル領域（ＰＤＣＣＨ領域）を備える。各サブフレームは時間領域で所与の数のＯＦＤＭシンボル（３ＧＰＰ ＬＴＥ（Ｒｅｌｅａｓｅ８）では１２または１４個のＯＦＤＭシンボル）から成り、ここでは各ＯＦＤＭシンボルはコンポーネントキャリアの帯域幅全体に渡る。ＯＦＤＭシンボルは、したがって各々、それぞれのサブキャリアで送信されるいくつかの変調シンボルから成る。ＬＴＥでは、各スロットでの送信信号は、Ｎ^ＤＬ_ＲＢ＊Ｎ^ＲＢ_ＳＣ個のサブキャリアとＮ^ＤＬ_ｓｙｍｂ個のＯＦＤＭシンボルのリソースグリッドによって描写される。Ｎ^ＤＬ_ＲＢは帯域幅内のリソースブロックの数である。量Ｎ^ＤＬ_ＲＢはセルに構成されるダウンリンク送信帯域幅に依存し、
Ｎ^{ｍｉｎ，ＤＬ}_ＲＢ≦Ｎ^ＤＬ_ＲＢ≦Ｎ^{ｍａｘ，ＤＬ}_ＲＢ
を満たすものとし、式中、Ｎ^{ｍｉｎ，ＤＬ}_ＲＢ＝６およびＮ^{ｍａｘ，ＤＬ}_ＲＢ＝１１０はそれぞれ、仕様の現行バージョンによってサポートされる最小および最大ダウンリンク帯域幅である。Ｎ^ＲＢ_ＳＣは１つのリソースブロック内のサブキャリアの数である。通常サイクリックプレフィックスサブフレーム構造の場合、Ｎ^ＲＢ_ＳＣ＝１２およびＮ^ＤＬ_ｓｙｍｂ＝７である。

【0009】

例えば、３ＧＰＰ ＬＴＥに使用されるような、ＯＦＤＭを利用するマルチキャリア通信システムを前提とすると、スケジューラによって割り当てられることができるリソースの最小単位は１つの「リソースブロック」である。物理リソースブロック（ＰＲＢ：Physical Resource Block）は、時間領域では連続するＯＦＤＭシンボル（例えば７つのＯＦＤＭシンボル）、および、周波数領域では図２に例示するように連続するサブキャリア（例えばコンポーネントキャリアにとして１２個のサブキャリア）として定義される。３ＧＰＰ ＬＴＥ（Ｒｅｌｅａｓｅ８）では、物理リソースブロックはリソースエレメントから成り、時間領域では１つのスロットに、かつ周波数領域では１８０ｋＨｚに対応する（ダウンリンクリソースグリッドに関するさらなる詳細については、例えばｈｔｔｐ：／／ｗｗｗ．３ｇｐｐ．ｏｒｇで入手可能であり、かつ参照により本明細書に援用される非特許文献１の６．２節を参照のこと）。

【0010】

１つのサブフレームは２つのスロットから成り、その結果、いわゆる「通常（normal）」ＣＰ（サイクリックプレフィックス）が使用されるときにはサブフレームに１４個のＯＦＤＭシンボルがあり、いわゆる「拡張（extended）」ＣＰが使用されるときにはサブフレームに１２個のＯＦＤＭシンボルがある。専門用語のために、以下では、サブフレーム全体に渡る同じ連続するサブキャリアに相当する時間−周波数リソースを、「リソースブロックペア」または同意義の「ＲＢペア」もしくは「ＰＲＢペア」と呼ぶ。「コンポーネントキャリア」という用語は、周波数領域でのいくつかのリソースブロックの組合せを指す。ＬＴＥの将来のリリースでは、「コンポーネントキャリア」という用語はもはや使用されず、代わりに専門用語は、ダウンリンクおよび任意選択でアップリンクリソースの組合せを指す「セル」に変更される。ダウンリンクリソースのキャリア周波数とアップリンクリソースのキャリア周波数との間の関連づけ（リンキング）は、ダウンリンクリソースで送信されるシステム情報に示される。コンポーネントキャリア構造に対する同様の前提が、後のリリースにも当てはまることになる。

【0011】

＜より広帯域幅のサポートのためのＬＴＥ−Ａでのキャリアアグリゲーション＞
ＩＭＴ−Ａｄｖａｎｃｅｄのための周波数スペクトルがＷＲＣ−０７（World Radio communication Conference 2007）で決定された。ＩＭＴ−Ａｄｖａｎｃｅｄのための全周波数スペクトルが決定されたとは言え、実際に利用可能な周波数帯域幅は各地域または国によって異なる。しかしながら、利用可能な周波数スペクトル概要に関する決定に続いて、無線インタフェースの標準化が第３世代パートナーシッププロジェクト（３ＧＰＰ：3rd Generation Partnership Project）で始まった。

【0012】

ＬＴＥ−Ａｄｖａｎｃｅｄシステムがサポートすることができる帯域幅が１００ＭＨｚである一方で、ＬＴＥシステムは２０ＭＨｚしかサポートすることができない。最近では、電波スペクトルの不足がワイヤレスネットワークの発展のボトルネックになっており、結果として、ＬＴＥ−Ａｄｖａｎｃｅｄシステムのために十分に広いスペクトル帯を見つけることは困難である。結果的に、より広い電波スペクトル帯を得る方途を見つけることが急務であり、ここで考え得る解答がキャリアアグリゲーション機能である。

【0013】

キャリアアグリゲーションでは、１００ＭＨｚまでのより広い送信帯域幅をサポートするために、２つ以上のコンポーネントキャリアがアグリゲートされる。ＬＴＥシステムでのいくつかのセルがアグリゲートされて、たとえＬＴＥでのこれらのセルが異なる周波数帯にあるとしても、１００ＭＨｚに対して十分に広いＬＴＥ−Ａｄｖａｎｃｅｄシステムでの１つのより広いチャネルになる。すべてのコンポーネントキャリアは、少なくともコンポーネントキャリアの帯域幅がＬＴＥ Ｒｅｌ．８／９セルのサポートされる帯域幅を超えない場合、ＬＴＥ Ｒｅｌ．８／９互換性があるように構成されることができる。ユーザ機器によってアグリゲートされるすべてのコンポーネントキャリアが必ずしもＲｅｌ．８／９互換性があるわけではなくてもよい。現存のメカニズム（例えば禁止（ｂａｒｒｉｎｇ））を使用して、Ｒｅｌ−８／９ユーザ機器がコンポーネントキャリアにキャンプすることを回避してもよい。

【0014】

ユーザ機器は、その能力に応じて１つまたは複数のコンポーネントキャリア（複数のサービングセルに対応する）を同時に受信または送信してもよい。キャリアアグリゲーションのための受信および／または送信能力を持つＬＴＥ−Ａ Ｒｅｌ．１０ユーザ機器は、複数のサービングセルで同時に受信および／または送信することができる一方で、ＬＴＥ Ｒｅｌ．８／９ユーザ機器は、コンポーネントキャリアの構造がＲｅｌ．８／９仕様に従うとの条件で、単一のサービングセルのみで受信および送信することができる。

【0015】

キャリアアグリゲーションは連続および非連続コンポーネントキャリア両方に対してサポートされるが、各コンポーネントキャリアは（３ＧＰＰ ＬＴＥ（Ｒｅｌｅａｓｅ８／９）のニューメロロジー（numerology）を用いて）周波数領域で最大で１１０個のリソースブロックに制限される。

【0016】

３ＧＰＰ ＬＴＥ−Ａ（Ｒｅｌｅａｓｅ１０）互換のユーザ機器を、同じｅＮｏｄｅＢ（基地局）から発信し、かつ場合によりアップリンクおよびダウンリンクで異なる帯域幅の異なる数のコンポーネントキャリアをアグリゲートするように構成することが可能である。構成することができるダウンリンクコンポーネントキャリアの数はＵＥのダウンリンクアグリゲーション能力に依存する。反対に、構成することができるアップリンクコンポーネントキャリアの数はＵＥのアップリンクアグリゲーション能力に依存する。移動端末をダウンリンクコンポーネントキャリアよりアップリンクコンポーネントキャリアが多くなるように構成することは、現在、可能でなくてもよい。典型的なＴＤＤ展開では、アップリンクおよびダウンリンクでのコンポーネントキャリアの数および各コンポーネントキャリアの帯域幅は同じである。同じｅＮｏｄｅＢから発信するコンポーネントキャリアが同じカバレージを提供する必要はない。

【0017】

連続してアグリゲートされるコンポーネントキャリアの中心周波数間の間隔は３００ｋＨｚの倍数であるものとする。これは、３ＧＰＰ ＬＴＥ（Ｒｅｌｅａｓｅ８／９）の１００ｋＨｚ周波数ラスタ（raster）と互換性があり、かつ同時に１５ｋＨｚ間隔を持つサブキャリアの直交性を保持するためである。アグリゲーションシナリオに応じて、ｎ＊３００ｋＨｚ間隔は、連続したコンポーネントキャリア間への少数の未使用サブキャリアの挿入によって容易にされることができる。

【0018】

複数のキャリアのアグリゲーションの性質は、ＭＡＣレイヤまでしか明らかにされていない。アップリンクおよびダウンリンク両方に関して、各アグリゲートされるコンポーネントキャリアごとにＭＡＣで１つのＨＡＲＱエンティティが必要とされる。（アップリンクに対するＳＵ−ＭＩＭＯの不在下では）コンポーネントキャリア当たり多くとも１つのトランスポートブロックがある。トランスポートブロックおよびその潜在的なＨＡＲＱ再送信は同じコンポーネントキャリアにマッピングされる必要がある。

【0019】

キャリアアグリゲーションが構成されるとき、移動端末は、ネットワークとは１つのＲＲＣ接続しか有しない。ＲＲＣ接続確立／再確立時に、１つのセルが、ＬＴＥ Ｒｅｌ．８／９と同様に、セキュリティ入力（１つのＥＣＧＩ、１つのＰＣＩおよび１つのＡＲＦＣＮ）ならびに非アクセス層モビリティ情報（例えばＴＡＩ）を提供する。ＲＲＣ接続確立／再確立後に、そのセルに対応するコンポーネントキャリアはダウンリンクプライマリセル（ＰＣｅｌｌ：Primary Cell）と称される。接続状態のユーザ機器当たり常に１つであり、１つだけのダウンリンクＰＣｅｌｌ（ＤＬ ＰＣｅｌｌ）および１つのアップリンクＰＣｅｌｌ（ＵＬ ＰＣｅｌｌ）が構成される。構成された一組のコンポーネントキャリア内で、他のセルはセカンダリセル（ＳＣｅｌｌ：Secondary Cell）と称され、ＳＣｅｌｌのキャリアはＤＬ ＳＣＣ（Downlink Secondary Component Carrier）およびＵＬ ＳＣＣ（Uplink Secondary Component Carrier）である。当座は、ＰＣｅｌｌを含めて最大５つのサービングセルが１つのＵＥに対して構成されることができる。

【0020】

コンポーネントキャリアの構成および再構成の他に、追加および削除はＲＲＣによって行われることができる。アクティブ化および非アクティブ化は、例えばＭＡＣ制御要素を介して行われる。ＬＴＥ内ハンドオーバ時に、ＲＲＣは、ターゲットセルでの使用のためにＳＣｅｌｌを追加、削除または再構成することもできる。新たなＳＣｅｌｌを追加するとき、ＳＣｅｌｌのシステム情報を送るために個別ＲＲＣシグナリングが使用されるが、情報は（Ｒｅｌ−８／９でのハンドオーバのためと同様に）送受信のために必要である。各ＳＣｅｌｌには、ＳＣｅｌｌが１つのＵＥに追加されるときにサービングセルインデックスが設定されるが、ＰＣｅｌｌは常にサービングセルインデックス０を有する。

【0021】

ユーザ機器にキャリアアグリゲーションが構成されると、少なくとも一対のアップリンクおよびダウンリンクコンポーネントキャリアが常にアクティブである。その対のダウンリンクコンポーネントキャリアは「ＤＬアンカキャリア」とも称されることがある。同じことがアップリンクに関しても当てはまる。キャリアアグリゲーションが構成されると、ユーザ機器は、複数のコンポーネントキャリアに同時にスケジュールされてもよいが、多くとも１つのランダムアクセス手順がいかなる時にも進行中であるものとする。クロスキャリアスケジューリングは、コンポーネントキャリアのＰＤＣＣＨが別のコンポーネントキャリア上のリソースをスケジュールするのを許容する。この目的で、コンポーネントキャリア識別フィールドがそれぞれのＤＣＩ（Downlink Control Information）フォーマットに導入され、ＣＩＦと呼ばれている。

【0022】

アップリンクおよびダウンリンクコンポーネントキャリア間の、ＲＲＣシグナリングによって確立される関連づけは、クロスキャリアスケジューリングがないときに、グラントが適用されるアップリンクコンポーネントキャリアを特定することを許容する。アップリンクコンポーネントキャリアへのダウンリンクコンポーネントキャリアの関連づけは、必ずしも１対１である必要はない。言い換えると、２つ以上のダウンリンクコンポーネントキャリアが、同じアップリンクコンポーネントキャリアに関連することができる。同時に、ダウンリンクコンポーネントキャリアは、１つのアップリンクコンポーネントキャリアにしか関連することができない。

【0023】

＜レイヤ２−ＭＡＣレイヤ／エンティティ、ＲＲＣレイヤ＞
ＬＴＥレイヤ２ユーザプレーン／制御プレーンプロトコルスタックは、４つのサブレイヤ（ＲＲＣ、ＰＤＣＰ、ＲＬＣおよびＭＡＣ）を備える。ＭＡＣ（Medium Access Control）レイヤはＬＴＥ無線プロトコルスタックのレイヤ２アーキテクチャにおける最下位サブレイヤであり、例えば非特許文献２によって規定される。下位の物理レイヤへの接続はトランスポートチャネルを通じてであり、上位のＲＬＣレイヤへの接続は論理チャネルを通じてである。ＭＡＣレイヤはしたがって、論理チャネルとトランスポートチャネルとの間の多重化および逆多重化を行い、送信側のＭＡＣレイヤは、論理チャネルを通じて受け取られるＭＡＣ ＳＤＵから、トランスポートブロックとして知られるＭＡＣ ＰＤＵを構築し、受信側のＭＡＣレイヤは、トランスポートチャネルを通じて受け取られるＭＡＣ ＰＤＵからＭＡＣ ＳＤＵを復元する。

【0024】

図３は、参照により本明細書にその全体が援用される非特許文献２の４．２．１節「MAC Entities」に提示される、ＵＥ側ＭＡＣエンティティのための１つの可能な構造を例示する。以下の機能が一般にＵＥでＭＡＣサブレイヤによってサポートされる：
− 論理チャネルとトランスポートチャネルとの間のマッピング；
− １つまたは異なる論理チャネルからのＭＡＣ ＳＤＵの、トランスポートチャネルで物理レイヤに送出されるべきトランスポートブロック（ＴＢ：transport block）への多重化；
− トランスポートチャネルで物理レイヤから送出されるトランスポートブロック（ＴＢ）からの、１つまたは異なる論理チャネルからのＭＡＣ ＳＤＵの逆多重化；
− スケジューリング情報報告；
− ＨＡＲＱによる誤り訂正；
− 論理チャネル優先順位付け；
− ＳＬのための無線リソース選択。

【0025】

図３から明らかなように、ＭＡＣエンティティは対応して、ハイブリッドＨＡＲＱ（ＨＡＲＱ）エンティティ、多重化および逆多重化エンティティ、（アップリンクのためだけの）論理チャネル優先順位付けエンティティ、ならびにＭＡＣエンティティのために様々な制御機能を行うコントローラなど、さらなるエンティティ（機能）を備える。ＭＡＣエンティティ／機能は、その全体が参照により本明細書に援用される非特許文献２の、例えば５節「MAC procedure」に詳細に規定される。

【0026】

ＨＡＲＱエンティティ（参照により本明細書に援用される非特許文献２の５．３．２項を参照のこと）は送信および受信ＨＡＲＱ動作を担う。送信ＨＡＲＱ動作は、トランスポートブロックの送信および再送信、ならびにＡＣＫ／ＮＡＣＫシグナリングの受信および処理を含む。受信ＨＡＲＱ動作は、トランスポートブロックの受信、受信データの結合、およびＡＣＫ／ＮＡＣＫシグナリングの生成を含む。先行のトランスポートブロックが復号されている間に連続送信を可能にするために、８つまでの並列なＨＡＲＱプロセスを使用してマルチプロセス動作をサポートする。

【0027】

多重化および逆多重化エンティティでは、いくつかの論理チャネルからのデータが１つのトランスポートチャネルに／から（逆）多重化されることができる。多重化エンティティは、新たな送信のために無線リソースが利用可能であるときにＭＡＣ ＳＤＵからＭＡＣ ＰＤＵを生成するが、このプロセスは、論理チャネルからのデータに優先順位を付けて、各ＭＡＣ ＰＤＵにどのくらいのデータが、どの論理チャネルから含まれるべきかを決定することを含む。

【0028】

ランダムアクセス手順は、ＵＥにアップリンク無線リソースが割り当てられていないが、送信すべきデータを有するときに、またはＵＥがアップリンク方向に時間同期されていないときに使用される。ＲＡＣＨ手順の詳細は、参照により本明細書に援用される非特許文献２の５．１項に規定される。

【0029】

コントローラエンティティは、とりわけ不連続受信（ＤＲＸ：discontinuous reception）、ランダムアクセスチャネル（ＲＡＣＨ：random access channel）手順、データスケジューリング手順、およびアップリンクタイミングアライメントを維持することを含む、いくつかの機能を担う。

【0030】

ＭＡＣレイヤは、制御データ（例えばＲＲＣシグナリング）を通知する制御論理チャネルか、またはユーザプレーンデータを通知するトラヒック論理チャネルかである論理チャネルを通じてＲＬＣレイヤにデータ転送サービス（参照により本明細書に援用される非特許文献２の５．４および５．３項を参照のこと）を提供する。以下の制御論理チャネルが、図３に例示されるように規定される：ブロードキャスト制御チャネル（ＢＣＣＨ：broadcast control channel）、ページング制御チャネル（ＰＣＣＨ：paging control channel）、共通制御チャネル（ＣＣＣＨ：common control channel）、マルチキャスト制御チャネル（ＭＣＣＨ：multicast control channel）および個別制御チャネル（ＤＣＣＨ：dedicated control channel）。トラヒック論理チャネルは個別トラヒックチャネル（ＤＴＣＨ：dedicated traffic channel）およびマルチキャストトラヒックチャネル（ＭＴＣＨ：multicast traffic channel）である。

【0031】

論理チャネルは、例えば、後に詳細に説明することになるように、バッファ状況報告の目的で、ＬＣＧ ＩＤ０〜３を持つ４つの異なる論理チャネルグループ（ＬＣＧ：Logical Channel Group）のうちの１つと関連づけられる。

【0032】

他方で、ＭＡＣレイヤからのデータは、ダウンリンクまたはアップリンクと分類されるトランスポートチャネルを通じて物理レイヤと交換される。データは、それがどのように無線で送信されるかに応じてトランスポートチャネルに多重化される。以下のダウンリンクトランスポートチャネルが規定される：ブロードキャストチャネル（ＢＣＨ：Broadcast channel）、ダウンリンク共有チャネル（ＤＬ−ＳＣＨ：downlink shared channel）、ページングチャネル（ＰＣＨ：paging channel）およびマルチキャストチャネル（ＭＣＨ：multicast channel）。以下のアップリンクトランスポートチャネルが規定される：アップリンク共有チャネル（ＵＬ−ＳＣＨ：uplink shared channel）およびランダムアクセスチヤネル（ＲＡＣＨ）。論理チャネルおよびトランスポートチャネルおよびそれらの間のマッピングに関するさらなる情報は、参照により本明細書にその全体が援用される非特許文献２の４．５節「Channel Structure」に見られることができる。

【0033】

無線リソース制御（ＲＲＣ）レイヤは、無線インタフェースでのＵＥとｅＮＢとの間の通信、およびいくつかのセルを渡って移動するＵＥのモビリティを制御する。ＲＲＣプロトコルはＮＡＳ情報の転送もサポートする。ＲＲＣ＿ＩＤＬＥのＵＥに対して、ＲＲＣは、着呼のネットワークからの通知をサポートする。ＲＲＣ接続制御は、ページング、測定構成および報告、無線リソース構成、初期セキュリティアクティブ化、ならびにシグナリング無線ベアラ（ＳＲＢ：Signalling Radio Bearer）の、およびユーザデータを通知する無線ベアラ（データ無線ベアラ（ＤＲＢ：Data Radio Bearer））の確立を含む、ＲＲＣ接続の確立、修正および解除に関連したすべての手順を包含する。

【0034】

個別ＲＲＣメッセージはシグナリング無線ベアラを渡って輸送されて、論理チャネル−接続確立中に共通制御チャネル（ＣＣＣＨ）か、またはＲＲＣ＿ＣＯＮＮＥＣＴＥＤで個別制御チャネル（ＤＣＣＨ）かに、ＰＤＣＰおよびＲＬＣレイヤを介してマッピングされる。システム情報およびページングメッセージは論理チャネル、それぞれブロードキャスト制御チャネル（ＢＣＣＨ）およびページング制御チャネル（ＰＣＣＨ）に直接マッピングされる。

【0035】

ＬＴＥ（Long Term Evolution）アーキテクチャを使用する移動ネットワークでは、ベアラは、ユーザ機器をインターネットなどのパケットデータネットワーク（ＰＤＮ：Packet Data Network）に接続するために使用される「トンネル」である。ＬＴＥネットワークでは、ＱｏＳがＵＥとＰＤＮゲートウェイとの間に実装され、一組のベアラに適用される。「ベアラ」は基本的に仮想概念であり、かつ一組のトラヒックに特別な処理を提供する一組のネットワーク構成であり、例えばＶｏＩＰパケットはウェブブラウザトラヒックと比較してネットワークによって優先される。本質的に、異なる特性（例えば遅延、配信時間、スループット、ＳＮＲ、誤り率ジッタなど）の各ストリームが異なるベアラにマッピングされる。したがって、ベアラはＱｏＳ制御の単位であり、一組のＱｏＳ要件を満たすために１つのベアラが使用される。ＬＴＥでは、ＱｏＳは、総称的に図４に図示するＥＰＳベアラと呼ばれる、無線ベアラ、Ｓ１ベアラおよびＳ５／Ｓ８ベアラに適用される。図４は、リレーＵＥとリレーＵＥによって応対されるリモートＵＥとの間のサイドリンク無線ベアラも例示する（ＰｒｏＳｅサイドリンクに関する情報については後節を参照のこと）。

【0036】

ＬＴＥ移動ネットワークでは、ユーザ機器装置がアクティブ化される（これは、ユーザ機器がオンであり、かつ認証を行ったことを意味する）ときはいつでも、デフォルトＰ−ＧＷに対して１つのデフォルトベアラが確立される。１つのデフォルトＰ−ＧＷに対して少なくとも１つのデフォルトベアラがなければならないが、単一のユーザ機器装置に対して同じまたは他のＰ−ＧＷに対する１１個までの他のベアラがアクティブであることができる。ベアラは、ＧＰＲＳトンネリングプロトコル、ユーザプレーン（ＧＴＰ−Ｕ：GPRS tunneling protocol, user plane）でユーザデータをカプセル化する。ＧＴＰ−Ｕ情報は、次いでＵＤＰで、かつＩＰパケット内で送られる。あらゆるユーザ機器装置が、それが接続する各Ｐ−ＧＷに対して「常にオンである」デフォルトベアラを有する。例えば、ユーザ機器が１つのＰ−ＧＷを通してインターネットに、および別のＰ−ＧＷを通して企業イントラネットに接続する場合、２つのデフォルトベアラがアクティブであることになる。加えて、ユーザ機器は、サービス品質（ＱｏＳ）要件に基づいて、他のＰＤＮに対して他の個別ベアラを確立することができる。例えば、インターネットを通じてストリーミングビデオを見ることは、個別ベアラを通じて行われることができる。個別ベアラが帯域保証（保証ビットレート、もしくはＧＢＲ：guaranteed bit rate）を使用することができるか、またはユーザ機器が非ＧＢＲベアラを確立することができる。

【0037】

ＬＴＥには２種類の無線ベアラがある：制御シグナリング、例えばＲＲＣシグナリング／ＮＡＳ情報を通知するシグナリング無線ベアラ（ＳＲＢ）（ＬＴＥには数種類のＳＲＢがある：ＳＲＢ０、ＳＲＢ１およびＳＲＢ２）、ならびにユーザプレーントラヒック／データを通知するデータ無線ベアラ（ＤＲＢ）。ＵＥは８つまでのＤＲＢをサポートする。

【0038】

ＥＰＳベアラ自体は、以下の順に確立される、（非ローミング状況で）３つの部分から成る連結トンネルである。
− Ｓ５ベアラ−このトンネルはサービングゲートウェイ（Ｓ−ＧＷ）をＰ−ＧＷに接続する。（トンネルはＰ−ＧＷからＰＤＮサービスネットワークまで延長することができるが、これはここでは考慮されない。）
− Ｓ１ベアラ−このトンネルは進化型ＮｏｄｅＢ（ｅＮｏｄｅＢまたはｅＮＢ）無線セルをＳ−ＧＷと接続する。ハンドオーバがエンドツーエンド接続のために新たなＳ１ベアラを確立する。
− 無線ベアラ−このトンネルはユーザ機器をｅＮｏｄｅＢ（ｅＮＢ）に接続する。このベアラは、移動ユーザが１つのセルから別のセルに移動するときに無線ネットワークがハンドオーバを行うにあたり、ＭＭＥ（Mobile Management Entity）の指示の下でユーザに追従する。

【0039】

以上列記されたすべての異なる種類のベアラに関して、１対１マッピングの関係がある。言い換えると、ＥＰＳベアラとＥ−ＲＡＢとの間、Ｅ−ＲＡＢと無線ベアラとの間、および無線ベアラとＳ１ベアラとの間に、固有の対応がある。

【0040】

各ベアラは一組のＱｏＳパラメータを使用して、ビットレート、パケット遅延、パケットロス、ビット誤り率およびスケジューリングポリシーなどの、トランスポートチャネルのプロパティを記述する。４つのキーパラメータがここで概説される。

【0041】

ＱｏＳクラスインジケータ（ＱＣＩ：QoS class indicator）：ＱＣＩは基本的にベアラの固有の期待される処理を規定し、たとえネットワークノードが異なるベンダによって開発されるとしても、同じＱＣＩのベアラの同様の取扱いを提供するものと意図される。受信されるＱＣＩ値に基づいて、各ネットワークノードが対応する関連ベアラの取扱い方を知ることになり、すなわちＱＣＩ値がベアラに関連づけられている。現行の規定されたＱＣＩ値の一覧が非特許文献３の６．１．７節に見られることができる。

【0042】

割当ておよび保持優先度（ＡＲＰ：allocation and retention priority）：ＡＲＰは、ベアラが受け取る制御プレーントラヒックに対する転送処理を特定する。ＡＲＰは、ベアラ確立および修正の他に、接続設定および解除を可能にする。例えば、ＡＲＰは、リソース限界またはトラヒック輻輳中にどのベアラが解除されるべきかを決定するためにＥＰＳによって使用されることができる。

【0043】

最大ビットレート（ＭＢＲ：maximum bit rate）：ＭＢＲは、リアルタイムサービスに対してのみ適用可能であり、ＧＢＲベアラに対して規定される。ＭＢＲは、ベアラ上のトラヒックが超えてはいけないビットレートである。

【0044】

保証ビットレート（ＧＢＲ）：ＧＢＲは、ネットワークがそのベアラに対して（例えばアドミッションコントロール機能の使用を通じて）保証するビットレートを特定する。３ＧＰＰ Ｒｅｌｅａｓｅ８以降では、ＭＢＲはＧＢＲに等しく設定されなければならず、すなわち保証レートはシステムによって許容される最大レートでもある。

【0045】

＜アップリンク／ダウンリンクスケジューリング＞
ｅＮｏｄｅＢでのＭＡＣ機能はスケジューリングを指し、それによってｅＮＢは、１つのセルで利用可能な無線リソースをＵＥに、および各ＵＥに対する無線ベアラに分配する。原則として、ｅＮｏｄｅＢは、それぞれ、ｅＮｏｄｅＢにバッファされるダウンリンクデータに基づいて、およびＵＥから受信されるバッファ状況報告（ＢＳＲ：buffer status report）に基づいて、各ＵＥにダウンリンクおよびアップリンクリソースを割り当てる。このプロセスでは、ｅＮｏｄｅＢは、各設定された無線ベアラのＱｏＳ要件を考慮し、ＭＡＣ ＰＤＵのサイズを選択する。

【0046】

スケジューリングの通例のモードは、ダウンリンク送信リソースの割当てのためのダウンリンクグラント／割当てメッセージ（ＤＣＩ）およびアップリンク送信リソースの割当てのためのアップリンクグラント／割当てメッセージを用いた、動的スケジューリングである。それらは、意図されるＵＥを識別するセル無線ネットワーク一時識別子（Ｃ−ＲＮＴＩ：cell radio network temporary identifier）を使用して物理ダウンリンク制御チャネル（ＰＤＣＣＨ：physical downlink control channel）で送信される。動的スケジューリングに加えて、永続スケジューリングが規定され、これは無線リソースが半静的に設定されて１つのサブフレームより長い時限の間ＵＥに割り当てられることを可能にし、したがって各サブフレームに対するＰＤＣＣＨ上での特定のダウンリンク割当てメッセージまたはアップリンクグラントメッセージの必要性を回避する。永続スケジュールの設定または再設定のために、ＲＲＣシグナリングは、無線リソースが周期的に割り当てられるリソース割当て間隔を示す。永続スケジュールを設定または再設定するためにＰＤＣＣＨが使用されるとき、永続スケジュールに該当するスケジューリングメッセージを動的スケジューリングのために使用されるそれらから区別することが必要である。この目的のため、特別なスケジューリング識別情報が使用され、各ＵＥにとって動的スケジューリングメッセージのために使用されるＣ−ＲＮＴＩと異なる半永続スケジューリングＣ−ＲＮＴＩ（ＳＰＳ−Ｃ−ＲＮＴＩ：semi-persistent scheduling C-RNTI）として知られる。

【0047】

スケジュールされたユーザに彼らの割当て状況、トランスポートフォーマットおよび他の送信関連情報（例えばＨＡＲＱ情報、送信電力制御（ＴＰＣ：transmit power control）指令）について通知するために、Ｌ１／Ｌ２制御シグナリングがデータと共にダウンリンクで送信される。Ｌ１／Ｌ２制御シグナリングはサブフレームでダウンリンクデータと多重化され、ユーザ割当てがサブフレームごとに変化することができることを前提とする。ユーザ割当てがＴＴＩ（Transmission Time Interval：送信時間間隔）ベースで行われることもあり、ここでＴＴＩ長がサブフレームの倍数であることができることに留意するべきである。ＴＴＩ長は、すべてのユーザに対するサービス範囲で固定されてもよいし、異なるユーザに対して異なってもよいし、または各ユーザに対して動的であってさえもよい。概して、Ｌ１／Ｌ２制御シグナリングはＴＴＩ当たり一度送信されさえすればよい。一般性を失うことなく、以下はＴＴＩが１つのサブフレームに相当することを前提とする。

【0048】

Ｌ１／Ｌ２制御シグナリングは物理ダウンリンク制御チャネル（ＰＤＣＣＨ）で送信される。ＰＤＣＣＨはダウンリンク制御情報（ＤＣＩ）としてのメッセージを通知し、それはほとんどの場合、移動端末またはＵＥのグループに対するリソース割当ておよび他の制御情報を含む。概して、いくつかのＰＤＣＣＨが１つのサブフレームで送信されることができる。

【0049】

ダウンリンク制御情報は、全体サイズが、かつそれらのフィールドに含まれる情報も異なるいくつかのフォーマットで出現する。ＬＴＥのために現在規定されている異なるＤＣＩフォーマットは、（現行バージョンｖ１２．５．０がｈｔｔｐ：／／ｗｗｗ．３ｇｐｐ．ｏｒｇで入手可能であり、かつ参照により本明細書に援用される）非特許文献４の５．３．３．１節に詳細に記載される。ＤＣＩフォーマットに関する詳細な情報およびＤＣＩで送信される特定の情報については、前述の技術標準を、または参照により本明細書に援用される、LTE - The UMTS Long Term Evolution - From Theory to Practice, Edited by Stefanie Sesia, Issam Toufik, Matthew Baker, Chapter 9.3を参照されたい。追加のフォーマットが将来規定されるかもしれない。

【0050】

＜論理チャネル優先順位付け（ＬＣＰ：Logical Channel Prioritization）手順＞
アップリンクについて、ＵＥが、割り当てられた無線リソースを使用して送信されることになるＭＡＣ ＰＤＵを作成するプロセスは完全に標準化されるが、ＬＣＰ手順は、最適でかつ異なるＵＥ実装間で一貫した方途でＵＥが各構成された無線ベアラのＱｏＳを充足することを保証するように設計される。ＰＤＣＣＨでシグナリングされるアップリンク送信リソースグラントメッセージに基づいて、ＵＥは、新たなＭＡＣ ＰＤＵに含まれるべき各論理チャネルに対するデータ量を決定しなければならず、必要ならば、ＭＡＣ制御要素のためにスペースも割り当てなければならない。

【0051】

複数の論理チャネルからのデータでＭＡＣ ＰＤＵを構築する際、最も単純かつ最も直観的な方法は絶対優先度ベースの方法であり、この方法ではＭＡＣ ＰＤＵスペースは論理チャネル優先度の降順に論理チャネルに割り当てられる。つまり、最高優先度の論理チャネルからのデータがＭＡＣ ＰＤＵで最初に扱われ、次の最高優先度の論理チャネルからのデータが後続し、ＭＡＣ ＰＤＵスペースが尽きるまで続く。絶対優先度ベースの方法はＵＥ実装の点で非常に単純であるとは言え、その方法は時には低優先度の論理チャネルからのデータの枯渇につながる。枯渇は、高優先度の論理チャネルからのデータがすべてのＭＡＣ ＰＤＵスペースを占めるために低優先度の論理チャネルからのデータが送信されることができないことを意味する。

【0052】

ＬＴＥでは、重要性の順にデータを送信するが、しかしより低い優先度を持つデータの枯渇を回避もするために、優先ビットレート（ＰＢＲ：Prioritized Bit Rate）が各論理チャネルに対して規定される。ＰＢＲは、論理チャネルに対して保証される最小データレートである。たとえ論理チャネルが低優先度を有するとしても、ＰＢＲを保証するために、少なくとも小量のＭＡＣ ＰＤＵスペースが割り当てられる。したがって、ＰＢＲを使用することによって、枯渇の問題は回避されることができる。

【0053】

ＰＢＲを持つＭＡＣ ＰＤＵを構築することは、２つのラウンドから成る。第１のラウンドでは、各論理チャネルは論理チャネル優先度の降順に扱われるが、ＭＡＣ ＰＤＵに含まれる各論理チャネルからのデータ量は、最初、論理チャネルの設定されたＰＢＲ値に対応する量に制限される。すべての論理チャネルがそれらのＰＢＲ値まで扱われた後、ＭＡＣ ＰＤＵに残された余地があれば、第２のラウンドが行われる。第２のラウンドでは、各論理チャネルは優先度の降順に再び扱われる。第１のラウンドと比較した第２のラウンドについての大きな違いは、より高い優先度のすべての論理チャネルがもはや送信するデータを有しない場合だけ、より低い優先度の各論理チャネルがＭＡＣ ＰＤＵスペースを割り当てられることができることである。

【0054】

ＭＡＣ ＰＤＵは、各設定された論理チャネルからのＭＡＣ ＳＤＵだけでなくＭＡＣ ＣＥも含んでもよい。パディングＢＳＲを除いて、ＭＡＣ ＣＥは、それがＭＡＣレイヤの動作を制御するので、論理チャネルからのＭＡＣ ＳＤＵより高い優先度を有する。したがって、ＭＡＣ ＰＤＵが構成されるとき、ＭＡＣ ＣＥが存在すれば、それが含まれるべき最初のものであり、残りのスペースが論理チャネルからのＭＡＣ ＳＤＵのために使用される。次いで、追加のスペースが残され、それがＢＳＲを含むのに十分大きければ、パディングＢＳＲがトリガされてＭＡＣ ＰＤＵに含められる。

【0055】

論理チャネル優先順位付けは、例えば参照によって本明細書に援用される非特許文献２の５．４．３．１項に標準化される。
論理チャネル優先順位付け（ＬＣＰ：Logical Channel Prioritization）手順は、新たな送信が行われるときに適用される。

【0056】

ＲＲＣは、各論理チャネルに対するシグナリングによって、アップリンクデータのスケジューリングを制御する：
− 大きい優先度値ほど低い優先度レベルを示すpriority、
− 優先ビットレート（ＰＢＲ：Prioritized Bit Rate）を設定するprioritisedBitRate、
− バケットサイズ継続時間（ＢＳＤ：Bucket Size Duration）を設定するbucketSizeDuration。

【0057】

ＵＥは、各論理チャネルｊのための変数Ｂｊを維持するものとする。Ｂｊは、関連した論理チャネルが確立されるときにゼロに初期化され、各ＴＴＩごとに積ＰＢＲ×ＴＴＩ継続時間だけインクリメントされるものとし、ここでＰＢＲは論理チャネルｊの優先ビットレートである。しかしながら、Ｂｊの値は決してバケットサイズを超えることができず、Ｂｊの値が論理チャネルｊのバケットサイズより大きければ、Ｂｊの値はバケットサイズに設定されるものとする。論理チャネルのバケットサイズはＰＢＲ×ＢＳＤに等しく、ここでＰＢＲおよびＢＳＤは上位のレイヤによって設定される。

【0058】

ＵＥ（ＭＡＣエンティティ）は、新たな送信が行われるときに以下の論理チャネル優先順位付け手順を行うものとする：
− ＵＥ（ＭＡＣエンティティ）は、以下のステップで論理チャネルにリソースを割り当てるものとする：
−− ステップ１：Ｂｊ＞０のすべての論理チャネルが優先度降順にリソースを割り当てられる。無線ベアラのＰＢＲが「無限大」に設定されれば、ＵＥは、より低い優先度無線ベアラのＰＢＲを満たす前に、無線ベアラでの送信のために利用可能であるすべてのデータのためにリソースを割り当てるものとする。
−− ステップ２：ＵＥ（ＭＡＣエンティティ）は、ステップ１で論理チャネルｊに分配されるＭＡＣ ＳＤＵの総サイズだけＢｊをデクリメントするものとする。
注：Ｂｊの値は負でありえる。

【0059】

−− ステップ３：任意のリソースが残れば、どちらが先にせよその論理チャネルのためのデータかまたはＵＬグラントかいずれかが尽きるまで、すべての論理チャネルが（Ｂｊの値に関係なく）厳密な優先度降順に扱われる。等しい優先度が設定される論理チャネルは等しく扱われるべきである。
− ＵＥ（ＭＡＣエンティティ）は、以上のスケジューリング手順の間、以下の規則にも従うものとする：
−− ＵＥ（ＭＡＣエンティティ）は、全体のＳＤＵ（または部分的に送信されるＳＤＵもしくは再送信されるＲＬＣ ＰＤＵ）が残りのリソースに収まれば、ＲＬＣ ＳＤＵ（または部分的に送信されるＳＤＵもしくは再送信されるＲＬＣ ＰＤＵ）をセグメント化するべきでない。
−− ＵＥ（ＭＡＣエンティティ）が論理チャネルからのＲＬＣ ＳＤＵをセグメント化する場合、ＵＥは、可能な限りグラントを満たすようにセグメントのサイズを最大化するものとする。
−− ＵＥ（ＭＡＣエンティティ）はデータの送信を最大化するべきである。
−− ＵＥ（ＭＡＣエンティティ）が、送信のために利用可能なデータを有しつつ、４バイト以上であるＵＬグラントサイズを与えられれば、ＵＥ（ＭＡＣエンティティ）は、パディングＢＳＲおよび／またはパディングのみを送信することはしないものとする（ＵＬグラントサイズが７バイト未満であり、かつＡＭＤ ＰＤＵセグメントが送信される必要がある場合を除く）。

【0060】

ＵＥは、停止されている無線ベアラに対応する論理チャネルのためのデータを送信しないものとする（無線ベアラが停止されていると考えられるときの条件は、TS 36.211に規定される）。

【0061】

論理チャネル優先順位付け手順に関して、ＵＥは以下の相対的優先度を降順に考慮するものとする：
− Ｃ−ＲＮＴＩに関するＭＡＣ制御要素またはＵＬ−ＣＣＣＨからのデータ；
− パディングのために含まれるＢＳＲを除くＢＳＲに関するＭＡＣ制御要素；
− ＰＨＲもしくは拡張ＰＨＲまたは二重接続ＰＨＲに関するＭＡＣ制御要素；
− ＵＬ−ＣＣＣＨからのデータを除く、任意の論理チャネルからのデータ；
− パディングのために含まれるＢＳＲに関するＭＡＣ制御要素。

【0062】

ＵＥが１つのＴＴＩに複数のＭＡＣ ＰＤＵを送信するように要求されるとき、ステップ１〜３および関連する規則が各グラントに独立してか、またはグラントの容量の和にかいずれかで適用されてもよい。また、グラントが処理される順序は、ＵＥ実装次第である。ＵＥが１つのＴＴＩに複数のＭＡＣ ＰＤＵを送信するように要求されるとき、どのＭＡＣ ＰＤＵにＭＡＣ制御要素が含まれるか決定することはＵＥ実装次第である。

【0063】

＜バッファ状況報告＞
前述したように、スケジューリングのモードは動的スケジューリングである。ｅＮｏｄｅＢがアップリンクリソースを割り当てること、すなわちアップリンクスケジューリングを支援するために、ＵＥからｅＮｏｄｅＢへのバッファ状況報告（ＢＳＲ）が使用される。ダウンリンクの場合に関して、ｅＮＢスケジューラは各ＵＥに配信されるべきデータ量を明らかに認識しているが、しかしながら、アップリンク方向に関しては、スケジューリング決定がｅＮＢで行われ、データのためのバッファがＵＥにあるので、ＵＬ−ＳＣＨを通じて送信される必要があるデータ量を示すために、ＵＥからｅＮＢにＢＳＲが送信されなければならない。

【0064】

ＬＴＥのためのバッファ状況報告ＭＡＣ制御要素は、長いＢＳＲ（４つのＬＣＧ ＩＤ＃０〜３に対応する４つのバッファサイズフィールドを持つ）か、または、短いＢＳＲ（１つのＬＣＧ ＩＤフィールドおよび１つの対応するバッファサイズフィールドを持つ）かいずれかから成る。バッファサイズフィールドは、論理チャネルグループのすべての論理チャネルに渡って利用可能な総データ量を示し、異なるバッファサイズレベルの指標として符合化されるバイト数で示される（参照により本明細書に援用される非特許文献２の現行バージョン１２．６．０の６．１．３．１項も参照のこと）。

【0065】

短いまたは長いＢＳＲいずれかのどちらのＢＳＲがＵＥによって送信されるかは、トランスポートブロックでの利用可能な送信リソース、どれくらいの論理チャネルのグループが空でないバッファを有するか、および、特定のイベントがＵＥでトリガされるかどうか、に依存する。長いＢＳＲが４つの規定された論理チャネルグループ（すなわちＬＣＧ ＩＤ０〜３）のためのデータ量を報告する一方で、短いＢＳＲは最高の論理チャネルグループのみのためにバッファされるデータ量を示す。

【0066】

論理チャネルグループ概念を導入する理由は、たとえＵＥが５つ以上の論理チャネルを設定されてもよいとしても、各個々の論理チャネルに対するバッファ状況を報告することが、あまりに多くのシグナリングオーバーヘッドを引き起こすだろうということである。したがって、ｅＮＢは各論理チャネルを論理チャネルグループに割り当て、好ましくは同じ／同様のＱｏＳ要件を持つ論理チャネルが同じ論理チャネルグループ内に割り当てられるべきである。

【0067】

送信失敗に対してロバストであるために、ＬＴＥにＢＳＲ再送信メカニズムが規定されており、アップリンクグラントが受信されるたびに再送信ＢＳＲタイマが始動または再始動され、再送信ＢＳＲタイマが満了する前にアップリンクグラントが受信されなければ、別のＢＳＲがＵＥによってトリガされる。

【0068】

ＢＳＲは、以下のイベントなどについてトリガされる。
− バッファが空でない（すなわちバッファが先だってデータを含んだ）論理チャネルより高い優先度を有する論理チャネルに対してデータが到着するたびに、
− 送信のために利用可能なデータが先だってない（すなわちすべてのバッファが先だって空になる）ときに任意の論理チャネルのためにデータが利用可能になるたびに、
− 再送信ＢＳＲタイマが満了するたびに、
− 定期的なＢＳＲ報告が予定される、すなわちｐｅｒｉｏｄｉｃＢＳＲタイマが満了するたびに、
− ＢＳＲを収容することができる予備のスペースがトランスポートブロックにあるたびに。

【0069】

ＢＳＲおよび特にそれをトリガすることに関するより詳細な情報が、参照により本明細書に援用される非特許文献２のバージョン１２．６．０の５．４．５項に説明される。

【0070】

ＢＳＲがトリガされるときに、ＵＥがトランスポートブロックにＢＳＲを含むために割り当てられるアップリンクリソースを有しなければ、ＵＥは、ＢＳＲを送信するアップリンクリソースを割り当てられるように、ｅＮｏｄｅＢにスケジューリング要求（ＳＲ：Scheduling Request）を送信する。単一ビットスケジューリング要求がＰＵＣＣＨを通じて送信される（個別スケジューリング要求、Ｄ−ＳＲ：Dedicated Scheduling Request）か、またはランダムアクセス手順（ＲＡＣＨ：Random Access Procedure）が行われるかいずれかで、ＢＳＲを送信するためのアップリンク無線リソースの割当てを要求する。

【0071】

＜ＬＴＥデバイスツーデバイス（Ｄ２Ｄ：Device to Device）近接サービス（ＰｒｏＳｅ：Proximity Services）＞
近接ベースのアプリケーションおよびサービスが、新興の社会的技術的傾向を表している。特定される領域は、事業者およびユーザにとって関心があろう商用サービスおよび公衆安全（Public Safety）に関連したサービスを含む。ＬＴＥへの近接サービス（ＰｒｏＳｅ）能力の導入は、３ＧＰＰ業界がこの発展市場に応対するのを許容するであろうし、同時に、ＬＴＥに共同で関与するいくつかの公衆安全地域の急務を満たすであろう。

【0072】

デバイスツーデバイス（Ｄ２Ｄ：Device to Device）通信は、セルラネットワークに対するアンダーレイとしてのＤ２Ｄがスペクトル効率を上昇させるのを許容するＬＴＥ−Ｒｅｌ．１２により導入される技術要素である。例えば、セルラネットワークがＬＴＥであれば、すべてのデータ通知用物理チャネルはＤ２ＤシグナリングのためにＳＣ−ＦＤＭＡを使用する。Ｄ２Ｄ通信では、ユーザ機器は、無線基地局を通しての代わりにセルラリソースを使用する直接リンクを通じて互いにデータ信号を送信する。本開示を通して、「Ｄ２Ｄ」、「ＰｒｏＳｅ」および「サイドリンク」という用語は交換可能である。

【0073】

＜ＬＴＥでのＤ２Ｄ通信＞
ＬＴＥでのＤ２Ｄ通信は２つの領域：発見および通信に重点を置いている。
ＰｒｏＳｅ（近接ベースのサービス）直接発見（Direct Discovery）が、ＰｒｏＳｅ対応ＵＥによって、ＰＣ５インタフェースを介してＥ−ＵＴＲＡ直接無線信号を使用してその近接の他のＰｒｏＳｅ対応ＵＥを発見するために使用される手順として規定され、後により詳細に記載することになる。

【0074】

Ｄ２Ｄ通信では、ＵＥは、基地局（ＢＳ：Base Station）を通しての代わりにセルラリソースを使用する直接リンクを通じて互いにデータ信号を送信する。Ｄ２Ｄユーザは、ＢＳ下で制御されたまま、すなわち少なくともｅＮＢのカバレージにいるときに直接通信する。したがって、Ｄ２Ｄは、セルラリソースを再使用することによってシステム性能を向上させることができる。

【0075】

Ｄ２Ｄは、（ＦＤＤの場合）アップリンクＬＴＥスペクトル、または、（カバレージ外の場合を除き、ＴＤＤの場合）カバレージを与えるセルのアップリンクサブフレームで動作することを前提とする。さらには、Ｄ２Ｄ送信／受信は所与のキャリアで全二重を使用しない。個々のＵＥの観点から、所与のキャリアで、Ｄ２Ｄ信号受信およびＬＴＥアップリンク送信は全二重を使用しない、すなわちＤ２Ｄ信号受信およびＬＴＥ ＵＬ送信の同時は不可能である。

【0076】

Ｄ２Ｄ通信では、１つの特定のＵＥ１が送信の役割を有するとき（送信ユーザ機器または送信端末）、ＵＥ１はデータを送信し、別のＵＥ２（受信ユーザ機器）がそのデータを受信する。ＵＥ１およびＵＥ２はそれらの送信および受信役割を交換することができる。ＵＥ１からの送信は、ＵＥ２のような１つまたは複数のＵＥによって受信されることができる。

【0077】

ユーザプレーンプロトコルに関して、Ｄ２Ｄ通信の観点からのＭＡＣに対する取決めの一部を以下に挙げる（さらなる詳細については、参照により本明細書に援用される非特許文献５の９．２．２節も参照のこと）。
−ＭＡＣ：
−− １：Ｍ Ｄ２Ｄブロードキャスト通信に対して、ＨＡＲＱフィードバックは前提とされない。
−− 受信ＵＥは、受信側ＲＬＣ ＵＭエンティティを識別するためにソースＩＤを知る必要がある。
−− ＭＡＣヘッダは、ＭＡＣレイヤでパケットをフィルタリングすることを許容するＬ２ターゲットＩＤを備える。
−− Ｌ２ターゲットＩＤはブロードキャスト、グループキャストまたはユニキャストアドレスでもよい。
−−− Ｌ２グループキャスト／ユニキャスト：ＭＡＣヘッダで通知されるＬ２ターゲットＩＤは、受信ＲＬＣ ＵＭ ＰＤＵをＲＬＣ受信側エンティティに送る前にさえそれを破棄することを許容するであろう。
−−− Ｌ２ブロードキャスト：受信ＵＥは、すべての送信機からのすべての受信ＲＬＣ ＰＤＵを処理し、ＩＰパケットを再構築して上位のレイヤに送ろうとするであろう。
−− ＭＡＣサブヘッダは、複数の論理チャネルを区別するＬＣＩＤを含む。
−− 少なくとも多重化／逆多重化、優先度処理およびパディングはＤ２Ｄに対して有用である。

【0078】

＜ＰｒｏＳｅ直接通信レイヤ２リンク＞
要するに、２つのＵＥ間にＰＣ５上の安全なレイヤ２リンクを確立することによって、ＰｒｏＳｅ直接１対１通信が実現される。各ＵＥは、それがレイヤ２リンクで送信するあらゆるフレームのソースレイヤ２ＩＤフィールドに、およびそれがレイヤ２リンクで受信するあらゆるフレームの宛先レイヤ２ＩＤに含まれるユニキャスト通信のためのレイヤ２ＩＤを有する。ＵＥは、ユニキャスト通信のためのレイヤ２ＩＤが少なくともローカルで一意であることを保証する必要がある。そこで、ＵＥは、不特定のメカニズムを使用して隣接するＵＥとのレイヤ２ＩＤ競合を取り扱う（例えば、競合が検出されると、ユニキャスト通信のための新たなレイヤ２ＩＤを自己割り当てする）備えができているべきである。ＰｒｏＳｅ１対１直接通信のためのレイヤ２リンクは、２つのＵＥのレイヤ２ＩＤの組合せによって識別される。これは、ＵＥが、同じレイヤ２ＩＤを使用してＰｒｏＳｅ１対１直接通信のための複数のレイヤ２リンクに係わることができることを意味する。

【0079】

ＰｒｏＳｅ１対１直接通信は、参照により本明細書に援用される非特許文献６の７．１．２節に詳細に説明される以下の手順で構成される。
− ＰＣ５上の安全なレイヤ２リンクの確立。
− ＩＰアドレス／プレフィックス割当て。
− ＰＣ５上のレイヤ２リンク維持。
− ＰＣ５上のレイヤ２リンク解除。
図５は、ＰＣ５インタフェース上の安全なレイヤ２リンクの確立のさせ方を開示する。
１. ＵＥ−１が、相互認証をトリガするためにＵＥ−２に直接通信要求（Direct Communication Request）メッセージを送信する。リンクイニシエータ（ＵＥ−１）は、ステップ１を実行するためにピア（ＵＥ−２）のレイヤ２ＩＤを知る必要がある。例として、リンクイニシエータは、最初に発見手順を実行することによって、またはピアを含むＰｒｏＳｅ一対多通信に関与したことによってピアのレイヤ２ＩＤを学習してもよい。
２. ＵＥ−２が、相互認証のための手順を開始する。認証手順の完了成功が、ＰＣ５上の安全なレイヤ２リンクの確立を完了する。
ＰＣ５上のレイヤ２リンク解除は、他方のＵＥに送信される切断要求（Disconnect Request）メッセージを使用することによって行われることができ、これはすべての関連するコンテキストデータも削除する。切断要求メッセージの受信に応じて、他方のＵＥは、切断応答（Disconnect Response）メッセージで応答し、レイヤ２リンクと関連づけられるすべてのコンテキストデータを削除する。

【0080】

＜ＰｒｏＳｅ直接通信関連識別情報＞
非特許文献７の現行バージョン１３．０．０が、ＰｒｏＳｅ直接通信のために使用する以下の識別情報を８．３項に規定する：
− ＳＬ−ＲＮＴＩ：ＰｒｏＳｅ直接通信スケジューリングのために使用される固有の識別；
− ソースレイヤ２ＩＤ：サイドリンクＰｒｏＳｅ直接通信でデータの送信側を識別する。ソースレイヤ２ＩＤは長さ２４ビットであり、受信側でのＲＬＣ ＵＭエンティティおよびＰＤＣＰエンティティの識別のためのＰｒｏＳｅレイヤ２宛先ＩＤおよびＬＣＩＤと共に使用される；
− 宛先レイヤ２ＩＤ：サイドリンクＰｒｏＳｅ直接通信でデータのターゲットを識別する。宛先レイヤ２ＩＤは長さ２４ビットであり、ＭＡＣレイヤで２つのビット列に分割される：
−− １つのビット列は宛先レイヤ２ＩＤのＬＳＢ部（８ビット）であり、サイドリンク制御レイヤ１ＩＤとして物理レイヤに転送される。これはサイドリンク制御の意図されたデータのターゲットを識別し、物理レイヤでパケットフィルタリングのために使用される。
−− 第２のビット列は宛先レイヤ２ＩＤのＭＳＢ部（１６ビット）であり、ＭＡＣヘッダ内で通知される。これはＭＡＣレイヤでパケットフィルタリングのために使用される。

【0081】

アクセス層シグナリングは、グループ形成のために、ならびにＵＥでソースレイヤ２ＩＤ、宛先レイヤ２ＩＤおよびサイドリンク制御Ｌ１ＩＤを設定するために必要とされない。これらの識別情報は上位レイヤによって提供されるか、または上位レイヤによって提供される識別情報から導出されるかいずれかである。グループキャストおよびブロードキャストの場合には、上位レイヤによって提供されるＰｒｏＳｅ ＵＥ ＩＤはソースレイヤ２ＩＤとして直接使用され、上位レイヤによって提供されるＰｒｏＳｅレイヤ２グループＩＤはＭＡＣレイヤで宛先レイヤ２ＩＤとして直接使用される。

【0082】

＜近接サービスのための無線リソース割当て＞
送信ＵＥの観点から、近接サービス対応ＵＥ（ＰｒｏＳｅ対応ＵＥ）は、リソース割当てのための２つのモードで動作することができる。
モード１はｅＮＢスケジュールリソース割当てを指し、ここでＵＥがｅＮＢ（またはリリース１０中継ノード）に送信リソースを要求し、ｅＮｏｄｅＢ（またはリリース１０中継ノード）は次いで直接データおよび直接制御情報を送信するためにＵＥによって使用されるリソースをスケジュールする（例えばスケジューリング割当て）。ＵＥは、データを送信するためにＲＲＣ＿ＣＯＮＮＥＣＴＥＤである必要がある。特に、ＵＥはｅＮＢにスケジューリング要求（Ｄ−ＳＲまたはランダムアクセス）を送信し、通例のようにバッファ状況報告（ＢＳＲ：Buffer Status Report）が後続する（以下の章「Ｄ２Ｄ通信のための送信手順」も参照のこと）。ＢＳＲに基づいて、ｅＮＢは、ＵＥがＰｒｏＳｅ直接通信送信のためのデータを有すると判定することができ、送信のために必要とされるリソースを推定することができる。

【0083】

他方では、モード２はＵＥ自律リソース選択を指し、ここでＵＥが、直接データおよび直接制御情報を送信するためにリソースプールからリソース（時間および周波数）を単独で選択する（すなわちＳＡ）。１つのリソースプールが、例えばＳＩＢ１８の内容によって、すなわちフィールドｃｏｍｍＴｘＰｏｏｌＮｏｒｍａｌＣｏｍｍｏｎによって規定され、この特定のリソースプールはセルでブロードキャストされ、次いでなおＲＲＣ＿Ｉｄｌｅ状態のセルにおけるすべてのＵＥに共通に利用可能である。実際上、ｅＮＢは、上記プールの４つまでの異なるインスタンス、それぞれＳＡメッセージおよび直接データの送信のための４つのリソースプールを規定してもよい。しかしながら、たとえ現行のリリース、すなわちＲｅｌ．−１２に従って複数のリソースプールを設定されたとしても、ＵＥは列記に規定される第１のリソースプールを常に使用するものとする。

【0084】

代替策として、別のリソースプールがｅＮＢによって規定され、ＳＩＢ１８で、すなわちフィールドｃｏｍｍＴｘＰｏｏｌＥｘｃｅｐｔｉｏｎａｌを使用することによってシグナリングされることができ、そのリソースプールは例外的な場合にＵＥによって使用されることができる。

【0085】

ＵＥがどのリソース割当てモードを使用する予定かは、ｅＮＢによって設定可能である。さらには、ＵＥがＤ２Ｄデータ通信のためにどのリソース割当てモードを使用する予定かは、また、ＲＲＣ状態、すなわちＲＲＣ＿ＩＤＬＥまたはＲＲＣ＿ＣＯＮＮＥＣＴＥＤ、およびＵＥのカバレージ状態、すなわちカバレージ内、カバレージ外に依存してもよい。ＵＥは、それがサービングセルを有する（すなわちＵＥがＲＲＣ＿ＣＯＮＮＥＣＴＥＤであるかまたはＲＲＣ＿ＩＤＬＥのセルにキャンプしている）とすれば、カバレージ内と考えられる。

【0086】

図６は、オーバーレイ（ＬＴＥ）およびアンダーレイ（Ｄ２Ｄ）システムのための送信／受信リソースの使用を例示する。
基本的に、ｅＮｏｄｅＢは、ＵＥがモード１またはモード２送信を適用してもよいかどうかを制御する。一旦ＵＥが、それがＤ２Ｄ通信を送信（または受信）することができるそのリソースを知ると、ＵＥは対応する送信／受信のための対応するリソースのみを使用する。例えば、図６で、Ｄ２Ｄサブフレームは、Ｄ２Ｄ信号を受信または送信するためにのみ使用されることになる。Ｄ２ＤデバイスとしてのＵＥは半二重モードで動作するであろうから、ＵＥは任意の時点でＤ２Ｄ信号を受信かまたは送信かいずれかすることができる。同様に、図６に例示するその他のサブフレームは、ＬＴＥ（オーバーレイ）送信および／または受信のために使用することができる。

【0087】

＜Ｄ２Ｄ通信のための送信手順＞
Ｄ２Ｄデータ送信手順は、リソース割当てモードに応じて異なる。モード１について上記したように、ｅＮＢは、ＵＥからの対応する要求後、スケジューリング割当ておよびＤ２Ｄデータ通信のためのリソースを明示的にスケジュールする。特に、ＵＥは、Ｄ２Ｄ通信が通常許容されるが、しかしモード２リソース（すなわちリソースプール）は提供されないことをｅＮＢによって通知されてもよく；これは、例えばＵＥによるＤ２Ｄ通信関心インジケーションおよび対応する応答（Ｄ２Ｄ通信応答）の交換で行われてもよく、ここで、上述した対応する例示的なＰｒｏｓｅＣｏｍｍＣｏｎｆｉｇ情報要素はｃｏｍｍＴｘＰｏｏｌＮｏｒｍａｌＣｏｍｍｏｎを含まないであろうから、送信を伴う直接通信を開始したいＵＥがＥ−ＵＴＲＡＮに各個々の送信のためのリソースを割り当てるように要求しなければならないことを意味する。したがって、そのような場合に、ＵＥは各個々の送信のためのリソースを要求しなければならず、以下に要求／グラント手順の異なるステップがこのモード１リソース割当てに関して例示的に列記される：

【0088】

− ステップ１：ＵＥがＰＵＣＣＨを介してｅＮＢにＳＲ（スケジューリング要求）を送信する；
− ステップ２：ｅＮＢがＰＤＣＣＨを介して（ＵＥがＢＳＲを送信するための）ＵＬリソースを、Ｃ−ＲＮＴＩによってスクランブルして許可する；
− ステップ３：ＵＥがＰＵＳＣＨを介してバッファ状況を示すＤ２Ｄ ＢＳＲを送信する；
− ステップ４：ｅＮＢがＰＤＣＣＨを介して（ＵＥがデータを送信するための）Ｄ２Ｄリソースを、Ｄ２Ｄ−ＲＮＴＩによってスクランブルして許可する。
− ステップ５：Ｄ２Ｄ Ｔｘ ＵＥがステップ４で受信したグラントに従ってＳＡ／Ｄ２Ｄデータを送信する。

【0089】

ＳＣＩ（Sidelink Control Information：サイドリンク制御情報）とも名付けられるスケジューリング割当て（ＳＡ：Scheduling Assignment）は、制御情報、例えば対応するＤ２Ｄデータ送信のための時間／周波数リソースへのポインタ、変調および符号体系ならびにグループ宛先ＩＤ（Group Destination ID）を含むコンパクトな（低ペイロード）メッセージである。ＳＣＩは、１つの（ＰｒｏＳｅ）宛先ＩＤに対するサイドリンクスケジューリング情報を搬送する。ＳＡ（ＳＣＩ）の内容は基本的に、上記ステップ４で受信したグラントに従う。Ｄ２ＤグラントおよびＳＡ内容（すなわちＳＣＩ内容）は、参照により本明細書に援用される非特許文献４の５．４．３項に規定され、特にＳＣＩ ｆｏｒｍａｔ０を規定する。

【0090】

他方では、モード２リソース割当てに関して、上記ステップ１〜４は基本的に必要でなく、ＵＥは、ｅＮＢによって設定および提供される送信リソースプールからＳＡおよびＤ２Ｄデータ送信のためのリソースを自律的に選択する。

【0091】

図７は、２つのＵＥ（ＵＥ−ＡおよびＵＥ−Ｂ）に対するスケジューリング割当ておよびＤ２Ｄデータの送信を例示的に示し、ここでスケジューリング割当てを送信するためのリソースは周期的であり、Ｄ２Ｄデータ送信のために使用されるリソースは対応するスケジューリング割当てによって示される。

【0092】

＜ＰｒｏＳｅネットワークアーキテクチャおよびＰｒｏＳｅエンティティ＞
図８は、それぞれのＵＥ ＡおよびＢにおける異なるＰｒｏＳｅアプリケーションの他に、ネットワークにおけるＰｒｏＳｅアプリケーションサーバおよびＰｒｏＳｅ機能を含む、非ローミングケースについての高レベルの例示的なアーキテクチャを例示する。図８のアーキテクチャ例は、参照により本明細書に援用される非特許文献８のバージョン１３．０．０の４．２章「Architectural Reference Model」から取られている。

【0093】

機能エンティティは、参照により本明細書に援用される、上記引用した非特許文献８の４．４項「Functional Entities」に詳細に提示および説明されている。ＰｒｏＳｅ機能は、ＰｒｏＳｅのために必要とされるネットワーク関連行動のために使用される論理機能であり、ＰｒｏＳｅの特徴の各々のための異なる役割を果たす。ＰｒｏＳｅ機能は３ＧＰＰのＥＰＣの一部であり、近接サービスに関連した、許可、認証、データ操作などのようなすべての関連するネットワークサービスを提供する。ＰｒｏＳｅ直接発見および通信に関して、ＵＥは、ＰＣ３基準点を通じてＰｒｏＳｅ機能から、特定のＰｒｏＳｅ ＵＥ識別情報、他の構成情報の他に許可を得てもよい。ネットワークには複数のＰｒｏＳｅ機能を展開することができるが、例解の容易さのために、単一のＰｒｏＳｅ機能を提示する。ＰｒｏＳｅ機能は、ＰｒｏＳｅ特徴に応じて異なる役割を行う３つの主な副機能：直接供給機能（ＤＰＦ：Direct Provision Function）、直接発見名管理機能およびＥＰＣレベル発見機能から成る。ＤＰＦは、ＰｒｏＳｅ直接発見およびＰｒｏＳｅ直接通信を使用するために、ＵＥに必要なパラメータを供給するために使用される。上記関連で使用される用語「ＵＥ」は、以下などのＰｒｏＳｅ機能性をサポートするＰｒｏＳｅ対応ＵＥを指す。

【0094】

ＰｒｏＳｅアプリケーションサーバは、ＥＰＣ ＰｒｏＳｅユーザＩＤおよびＰｒｏＳｅ機能ＩＤの記憶、ならびにアプリケーションレイヤユーザＩＤおよびＥＰＣ ＰｒｏＳｅユーザＩＤのマッピングをサポートする。ＰｒｏＳｅアプリケーションサーバ（ＡＳ：Application Server）は３ＧＰＰの範囲外のエンティティである。ＵＥにおけるＰｒｏＳｅアプリケーションは、アプリケーションレイヤ基準点ＰＣ１を介してＰｒｏＳｅ ＡＳと通信する。ＰｒｏＳｅ ＡＳはＰＣ２基準点を介して３ＧＰＰネットワークに接続される。

【0095】

＜Ｄ２ＤのためのＵＥカバレージ状態＞
既に前述したように、Ｄ２Ｄ通信のためのリソース割当て方法は、ＲＲＣ状態、すなわちＲＲＣ＿ＩＤＬＥおよびＲＲＣ＿ＣＯＮＮＥＣＴＥＤとは別に、ＵＥのカバレージ状態、すなわちカバレージ内、カバレージ外にも依存する。ＵＥは、それがサービングセルを有する（すなわちＵＥがＲＲＣ＿ＣＯＮＮＥＣＴＥＤであるかまたはＲＲＣ＿ＩＤＬＥのセルにキャンプしている）とすれば、カバレージ内と考えられる。

【0096】

ここまで述べた２つのカバレージ状態、すなわちカバレージ内（ＩＣ：in-coverage）およびカバレージ外（ＯＯＣ：out-of-coverage）は、Ｄ２Ｄに関して下位状態にさらに区別される。図９は、Ｄ２Ｄ ＵＥが関連づけられることができる４つの異なる状態を示し、それらは以下の通りに要約されることができる：
− 状態１：ＵＥ１はアップリンクおよびダウンリンクカバレージを有する。この状態では、ネットワークは各Ｄ２Ｄ通信セッションを制御する。さらには、ネットワークは、ＵＥ１がリソース割当てモード１かまたはモード２かどちらを使用するべきかを設定する。
− 状態２：ＵＥ２はアップリンクを除いたダウンリンクカバレージ、すなわちＤＬカバレージのみを有する。ネットワークは（競合ベースの）リソースプールをブロードキャストする。この状態では、送信ＵＥは、ネットワークによって設定されるリソースプールからＳＡおよびデータのために使用されるリソースを選択するが、リソース割当ては、そのような状態のＤ２Ｄ通信のためのモード２に従って可能であるのみである。
− 状態３：ＵＥ３はアップリンクおよびダウンリンクカバレージを有しないので、ＵＥ３は厳密に言えば、既にカバレージ外（ＯＯＣ：out-of-coverage）として考えられる。しかしながら、ＵＥ３は、それら自体（例えばＵＥ１）セルのカバレージ内であるいくつかのＵＥのカバレージ内であり、すなわちそれらのＵＥはＣＰ中継ＵＥまたは単にリレーＵＥとも称されることができる（ＰｒｏＳｅリレーに関する後章も参照のこと）。したがって、図９における状態３ＵＥの領域は、ＣＰ ＵＥ中継カバレージ範囲として示されることができる。この状態３のＵＥはＯＯＣ状態３ＵＥとも称される。この状態では、ＵＥは、ｅＮＢ（ＳＩＢ）によって送信してもよく、セルのカバレージ内のＣＰ ＵＥ中継ＵＥによってＰＤ２ＤＳＣＨを介してＯＯＣ状態３ＵＥに転送される何らかのセル固有情報を受信してもよい。（競合ベースの）ネットワーク制御リソースプールがＰＤ２ＤＳＣＨによってシグナリングされる。
− 状態４：ＵＥ４はカバレージ外であり、セルのカバレージ内である他のＵＥからＰＤ２ＤＳＣＨを受信しない。状態４ＯＯＣとも称されるこの状態では、送信ＵＥは、リソースの予め設定されたプールからデータ送信のために使用されるリソースを選択する。

【0097】

状態３ＯＯＣと状態４ＯＯＣとの間で区別する理由は、主にカバレージ外デバイスからのＤ２Ｄ送信とレガシーＥ−ＵＴＲＡ送信との間の潜在的に強い干渉を回避するためである。概して、Ｄ２Ｄ可能ＵＥは、カバレージ外の間に使用するためにＤ２Ｄ ＳＡおよびデータの送信のためのリソースプールを予め設定しているだろう。これらのカバレージ外ＵＥがセル境界付近でこれらの予め設定されたリソースプールで送信する場合、Ｄ２Ｄ送信とカバレージ内レガシー送信との間の干渉がセル内の通信に悪影響を及ぼすはずである。カバレージ内のＤ２Ｄ対応ＵＥがセル境界付近でそれらのカバレージ外デバイスにＤ２Ｄリソースプール設定を転送するとすれば、カバレージ外ＵＥはｅＮｏｄｅ Ｂによって特定されるリソースにそれらカバレージ外ＵＥの送信を限定し、したがってカバレージ内のレガシー送信との干渉を最小化することができるだろう。したがって、ＲＡＮ１は、カバレージ内ＵＥがカバレージ範囲すぐ外のそれらのデバイス（状態３ＵＥ）にリソースプール情報および他のＤ２Ｄ関連設定を転送するメカニズムを導入した。

【0098】

物理Ｄ２Ｄ同期チャネル（ＰＤ２ＤＳＣＨ：Physical D2D synchronization channel）を使用してネットワーク近接のＵＥにカバレージ内Ｄ２Ｄリソースプールについてのこの情報を通知し、その結果ネットワーク近接内のリソースプールは同調される。

【0099】

＜Ｄ２Ｄ発見−モデルおよびリソース割当て＞
ＰｒｏＳｅ直接発見は、ＰｒｏＳｅ対応ＵＥによって、ＰＣ５を介してＥ−ＵＴＲＡ直接無線信号を使用してその近接の他のＰｒｏＳｅ対応ＵＥを発見するために使用される手順として規定される。上位のレイヤが、発見情報のアナウンスおよびモニタリングのための許可を取り扱う。この目的のため、ＵＥは、「発見信号」と称される所定の信号を交換しなければならない。発見信号を周期的に確認することによって、ＵＥは、必要とされるときに通信リンクを確立するために近接ＵＥの一覧を維持する。発見信号は、低信号対雑音比（ＳＮＲ：Signal-to-Noise Ratio）環境でさえ、確実に検出されるべきである。発見信号が周期的に送信されるのを許容するために、発見信号のためのリソースが割り当てられるべきである。

【0100】

二種類のＰｒｏＳｅ直接発見がある：無制限および制限付。無制限は、発見されているＵＥから明示的な許可が必要とされない場合である一方で、制限付発見は、発見されているＵＥからの明示的な許可を伴ってのみ生じる。

【0101】

ＰｒｏＳｅ直接発見は、例えば発見されるＵＥからの情報を、この情報、例えば「近くでタクシーを見つけて」、「私にコーヒー店を見つけて」を使用するのを許可されるＵＥにおける一定のアプリケーションのために使用することがありえるスタンドアロンサービスを可能にすることであることができる。付加的に、得られた情報に応じて、ＰｒｏＳｅ直接発見は、例えばＰｒｏＳｅ直接通信を開始する後続の行動のために使用されることができる。

【0102】

ＰｒｏＳｅ直接発見のための以下のモデルが、参照により本明細書に援用される非特許文献８の５．３節およびそのすべての項に規定される。

【0103】

モデルＡ（「私はここにいます」）：
このモデルは、ＰｒｏＳｅ直接発見に関与しているＰｒｏＳｅ対応ＵＥのための２つの役割を規定する。
− アナウンスＵＥ（Announcing UE）：ＵＥは、発見する許可を有する近接のＵＥによって使用されることがありえる一定の情報をアナウンスする。
− モニタリングＵＥ（Monitoring UE）：アナウンスＵＥの近接の関心を引く一定の情報をモニタリングするＵＥ。

【0104】

このモデルでは、アナウンスＵＥは所定の発見間隔で発見メッセージをブロードキャストし、これらのメッセージに関心があるモニタリングＵＥはそれらを読み、それらを処理する。このモデルは、アナウンスＵＥがそれ自体についての情報、例えばそのＰｒｏＳｅアプリケーションコードを発見メッセージでブロードキャストすることになるので、「私はここにいます」と称されてもよい。

【0105】

モデルＢ（「誰がそこにいますか？」／「あなたはそこにいますか？」）：
このモデルは、ＰｒｏＳｅ直接発見に関与しているＰｒｏＳｅ対応ＵＥのための２つの役割を規定する。
− 発見者ＵＥ（Discoverer UE）：ＵＥは、それが何を発見することに関心があるかについての一定の情報を含む要求を送信する。
− 被発見者ＵＥ：要求メッセージを受信するＵＥは、発見者の要求に関連した何らかの情報で応答することができる。

【0106】

それは、発見者ＵＥが応答を受信することを望む他のＵＥに対する情報を送信する、例えば、情報がグループに対応するＰｒｏＳｅアプリケーション識別情報についてであることができ、かつグループのメンバーが応答することができるので、「誰がそこにいますか／あなたはそこにいますか」と称されることができる。

【0107】

発見情報の内容はアクセス層（ＡＳ：Access Stratum）にとって透過的であり、ＡＳではＰｒｏＳｅ直接発見モデルおよびＰｒｏＳｅ直接発見の種類に関して区別はなされない。ＰｒｏＳｅプロトコルは、それが、アナウンスの場合、有効な発見情報のみをＡＳに送出することを保証する。

【0108】

ＵＥは、ｅＮＢ構成に従ってＲＲＣ＿ＩＤＬＥおよびＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態の両方で発見情報のアナウンスおよびモニタリングに関与することができる。ＵＥは、半二重制約を条件としてその発見情報をアナウンスおよびモニタリングする。

【0109】

概して、デバイス発見は周期的に必要とされる。さらに、Ｄ２Ｄデバイスは、発見メッセージシグナリングプロトコルを利用してデバイス発見を行う。例えば、Ｄ２Ｄ対応ＵＥがその発見メッセージを送信することができ、別のＤ２Ｄ対応ＵＥがこの発見メッセージを受信し、その情報を使用して直接通信リンクを確立することができる。ハイブリッドネットワークの利点は、Ｄ２Ｄデバイスがネットワークインフラの通信距離にもあれば、ｅＮＢのようなネットワークエンティティが発見メッセージの送信または設定を付加的に支援することができるということである。発見メッセージの送信または設定でのｅＮＢによる協調／制御も、Ｄ２ＤメッセージングがｅＮＢによって制御されるセルラトラヒックとの干渉を引き起こさないことを保証するために重要である。付加的に、たとえデバイスのいくつかがネットワークカバレージ範囲の外であるとしても、カバレージ内デバイスがアドホック発見プロトコルを支援することができる。

【0110】

少なくとも以下の二種類の発見手順が、記載にさらに使用される専門用語定義の目的で規定される。
− ＵＥ自律リソース選択（以降１型と呼ばれる）：発見情報をアナウンスするためのリソースが非ＵＥ特定ベースで割り当てられるリソース割当て手順であり、以下によってさらに特徴付けられる。
−− ｅＮＢは、発見情報のアナウンスのために使用されるリソースプール設定をＵＥに提供する。設定は例えばＳＩＢでシグナリングされてもよい。
−− ＵＥは、示されたリソースプールから無線リソースを自律的に選択し、発見情報をアナウンスする。
−− ＵＥは、各発見期間の間、ランダムに選択された発見リソースで発見情報をアナウンスすることができる。
−スケジュールリソース割当て（以降２型と呼ばれる）：発見情報をアナウンスするためのリソースがＵＥ特定ベースで割り当てられるリソース割当て手順であり、以下によってさらに特徴付けられる。
−− ＲＲＣ＿ＣＯＮＮＥＣＴＥＤのＵＥは、ＲＲＣを介してｅＮＢに発見情報のアナウンスのためのリソースを要求してもよい。ｅＮＢはＲＲＣを介してリソースを割り当てる。
−− リソースは、モニタリングのためにＵＥに設定されるリソースプール内で割り当てられる。

【0111】

ＲＲＣ＿ＩＤＬＥのＵＥに対して、ｅＮＢは以下のオプションの１つを選択してもよい。
− ｅＮＢは、発見情報アナウンスのための１型リソースプールをＳＩＢで提供してもよい。ＰｒｏＳｅ直接発見に許可されているＵＥが、これらのリソースを、ＲＲＣ＿ＩＤＬＥで発見情報をアナウンスするために使用する。
− ｅＮＢは、それがＤ２Ｄをサポートするが、しかし発見情報アナウンスのためのリソースは提供しないことをＳＩＢで示してもよい。ＵＥは、発見情報アナウンスのためのＤ２Ｄリソースを要求するためにＲＲＣ Ｃｏｎｎｅｃｔｅｄに入る必要がある。

【0112】

ＲＲＣ＿ＣＯＮＮＥＣＴＥＤのＵＥに対して：
− ＰｒｏＳｅ直接発見アナウンスを行う許可を与えられているＵＥが、それがＤ２Ｄ発見アナウンスを行いたいことをｅＮＢに示す。
− ｅＮＢは、ＭＭＥから受信されるＵＥコンテキストを使用して、ＵＥがＰｒｏＳｅ直接発見アナウンスに許可されているかどうかを確認する。
− ｅＮＢは、個別ＲＲＣシグナリングを介して、発見情報アナウンスのために１型リソースプールまたは個別２型リソースを使用するようにＵＥを構成してもよい（またはリソースなし）。
− ｅＮＢによって割り当てられるリソースは、ａ）ｅＮＢがＲＲＣシグナリングによってリソースを構成解除する、またはｂ）ＵＥがＩＤＬＥに入るまで有効である。

【0113】

ＲＲＣ＿ＩＤＬＥおよびＲＲＣ＿ＣＯＮＮＥＣＴＥＤの受信ＵＥが、許可されるように、１型および２型発見リソースプール両方をモニタリングする。ｅＮＢは、発見情報モニタリングのために使用されるリソースプール設定をＳＩＢで提供する。ＳＩＢは、隣接セルでのアナウンスのために使用される発見リソースも含んでもよい。

【0114】

＜Ｄ２Ｄ（サイドリンク）論理チャネルのためのＬＣＰ手順＞
Ｄ２ＤのためのＬＣＰ手順は、「通常の」ＬＴＥデータのための以上提示したＬＣＰ手順とは異なることになる。以下の情報は、非特許文献２の、ＰｒｏＳｅのためのＬＣＰを記載する５．１４．１．３．１項から取られており、それは参照によりその全体が本明細書に援用される。

【0115】

すべてのＤ２Ｄ（サイドリンク）論理チャネル、例えばＳＴＣＨ（Sidelink Traffic CHannel：サイドリンクトラヒックチャネル）が、ＬＣＧＩＤが「１１」に設定される同じ論理チャネルグループ（ＬＣＧ）に割り当てられる（非特許文献２の５．１４．１．４項「Buffer Status Reporting」を参照のこと）。Ｒｅｌ−１２では、Ｄ２Ｄ（サイドリンク）論理チャネル／グループのための優先順位付けメカニズムはない。本質的に、すべてのサイドリンク論理チャネルはＵＥの観点から同じ優先度を有し、すなわちサイドリンク論理チャネルが扱われる順序はＵＥ実装次第である。

【0116】

＜ＰｒｏＳｅのためのバッファ状況報告＞
バッファ状況報告はＰｒｏＳｅに適合され、現在、参照により本明細書に援用される非特許文献２の５．１４．１．４項「Buffer Status Reporting」に規定される。

【0117】

（Ｄ２Ｄ）サイドリンクバッファ状況報告手順は、他方のＵＥへの送信のために利用可能なＵＥのサイドリンクバッファにおけるサイドリンクデータ量についての情報をサービングｅＮＢに提供するために使用される。ＲＲＣは、２つのタイマＰｅｒｉｏｄｉｃ−ＰｒｏｓｅＢＳＲ−ＴｉｍｅｒおよびＲｅｔｘＰｒｏｓｅＢＳＲ−Ｔｉｍｅｒを設定することによってサイドリンクＢＳＲ報告を制御する。各サイドリンク論理チャネル（ＳＴＣＨ）は、ＬＣＧＩＤが「１１」に設定されるＬＣＧに割り当てられ、ＰｒｏＳｅ宛先グループに帰属する。

【0118】

サイドリンクバッファ状況報告（ＢＳＲ）は、非特許文献２の５．１４．１．４項に詳細に明記されるように、何らかの特定のイベントが発生する場合にトリガされるものとする。

【0119】

さらには、参照により本明細書に援用される非特許文献２の６．１．３．１ａ項が、以下の通りにＰｒｏＳｅ ＢＳＲ ＭＡＣ制御要素およびその対応する内容を規定する。ＰｒｏＳｅバッファ状況報告（ＢＳＲ：Buffer Status Report）ＭＡＣ制御要素は、報告されるＤ２Ｄ宛先グループごとに１つのグループインデックスフィールド、１つのＬＣＧ ＩＤフィールドおよび１つの対応するバッファサイズフィールドから成る。より詳細には、各含まれるＰｒｏＳｅ宛先グループに対して、以下のフィールドが規定される：
− グループインデックス：グループインデックスフィールドはＰｒｏＳｅ宛先グループを識別する。このフィールドの長さは４ビットである。値は、ｄｅｓｔｉｎａｔｉｏｎＩｎｆｏＬｉｓｔで報告される宛先識別情報のインデックスに設定される；
− ＬＣＧ ＩＤ：論理チャネルグループＩＤフィールドは、バッファ状況が報告されている論理チャネルのグループを識別する。フィールドの長さは２ビットであり、それは「１１」に設定される；
− バッファサイズ：バッファサイズフィールドは、ＴＴＩに対するすべてのＭＡＣ ＰＤＵが構築された後にＰｒｏＳｅ宛先グループのすべての論理チャネルに渡って利用可能な総データ量を識別する。データ量は、バイト数で示される。
− Ｒ：予約ビット、「０」に設定される。

【0120】

図１０は、以上引用した非特許文献２の６．１．３．１ａ項から取られる、Ｎ（ＰｒｏＳｅ宛先グループの数）にも対するＰｒｏＳｅ ＢＳＲ ＭＡＣ制御要素を示す。

【0121】

＜ＰｒｏＳｅ ＵＥ−ネットワークリレー（ＵＥ−ｔｏ−Ｎｅｔｗｒｏｋ Ｒｅｌａｙ）＞
ＵＥはまた、ＰｒｏＳｅ ＵＥ−ネットワークリレーとして作用して、その結果リモートＵＥがＰＣ５基準点を通じてＰｒｏＳｅ ＵＥ−ネットワークリレーと通信するように、機能性および手順をサポートしてもよい。ＰｒｏＳｅ ＵＥ−ネットワークリレー動作は、３ＧＰＰ Ｒｅｌｅａｓｅ１３内で明記されるであろう。ここまで、初期取決めのみが３ＧＰＰ ＲＡＮ作業グループでなされてきたが、そのいくつかが、例えば、参照により本明細書に援用される非特許文献８および非特許文献６から理解されることができる。それらの取決めのいくつかが以下列記されることになる。しかしながら、この作業項目がごく最近導入され、したがって依然標準化の最中であることに留意するべきである。結果的に、以下に前提とされるいかなる取決めも依然変更または破棄される可能性があり、考察目的で前提とされる以下の取決めは、しかしながら、標準化のこの非常に初期段階で本開示をこの特定の３ＧＰＰ実装に限定するとは理解されないものとする。

【0122】

− ＰｒｏＳｅ ＵＥ−ネットワークリレー発見およびＰｒｏＳｅリレー（再）選択に関して、リモートＵＥがカバレージ内およびカバレージ外である両シナリオが対処されることができる。
− リレーＵＥは常にカバレージ内であろう。ｅＮＢが無線レベルで、ＵＥがリレーとして作用することができるかどうかを制御することができる一方で、ネットワーク制御がリレーＵＥごと、セル（ブロードキャスト設定）ごと、もしくは両方、または何か他のことであるかどうかは依然未決定である。
− リモートＵＥがリレー発見目的でカバレージ内であるとき、発見のためのモニタリングおよび送信リソースは、例えばＲｅｌ−１２メカニズム（アイドルモード用のブロードキャストおよび接続モード用の個別シグナリング）を使用してｅＮＢによって提供されることができる。リモートＵＥは、いつモニタリングを開始するべきかを決定することができる。
− リモートＵＥがカバレージ外であるとき、発見および通信（実際のデータ転送）のためのモニタリングおよび送信リソースは、例えば、ＵＥがどのリソースを使用するべきかを正確に知るように、事前設定によって、すなわち仕様／オペレータ設定（ＵＳＩＭでなど）を通じて提供されることができる。

【0123】

ＰｒｏＳｅ ＵＥ−ネットワークリレー（再）選択：
− リモートＵＥは、ＰｒｏＳｅ ＵＥ−ネットワークリレー選択手順に対して、ＰＣ５無線リンク品質の無線レベル測定値を考慮に入れることができる。
− リモートＵＥがカバレージ外である場合に関して、無線レベル測定値は、他の上位レイヤ判定基準と共にリモートＵＥによって使用されてリレー選択を行うことができる。
− リモートＵＥがカバレージ外である場合に関して、再選択のための判定基準は、ＰＣ５測定値（ＲＳＲＰまたは他のＲＡＮ１約定測定値）および上位レイヤ判定基準に基づく。リレー再選択はリモートＵＥによってトリガされることができる。
− リモートＵＥがカバレージ内である場合に関して、これらの測定値（ＰＣ５測定値）が使用されるかどうか、およびどのように使用されるかはまだ決定されていない（例えば、測定値はＵＥによって使用されてカバレージ外の場合と同様の選択を行うことができる、またはそれらはｅＮＢに報告されることができる）。

【0124】

ＰｒｏＳｅ ＵＥ−ネットワークリレーはレイヤ３パケット転送を使用してもよい。ＰｒｏＳｅ ＵＥ間の制御情報が、例えばＵＥ−ネットワークリレー検出およびＰｒｏＳｅ直接発見のために、ＰＣ５基準点を通じて交換されることができる。

【0125】

ＰｒｏＳｅ対応ＵＥがまた、ＰＣ３基準点を通じた別のＰｒｏＳｅ対応ＵＥとＰｒｏＳｅ機能との間のＰｒｏＳｅ制御情報の交換をサポートするであろう。ＰｒｏＳｅ ＵＥ−ネットワークリレーの場合には、リモートＵＥはＰＣ５ユーザプレーンを通じてこの制御情報を送信し、ＰｒｏＳｅ機能に向けてＬＴＥ−Ｕｕインタフェースを通じて中継されることになる。

【0126】

ＰｒｏＳｅ ＵＥ−ネットワークリレーエンティティは、ｅＮＢのカバレージ範囲内でない、すなわちＥ−ＵＴＲＡＮに接続されていないリモートＵＥに、「ユニキャスト」サービスへの接続性をサポートする機能性を提供する。図１１は、ＰｒｏＳｅ ＵＥ−ネットワークリレーシナリオを示す。ＰｒｏＳｅ ＵＥ−ネットワークリレーは、リモートＵＥとネットワークとの間のユニキャストトラヒック（ＵＬおよび／またはＤＬ）を中継するものとする。ＰｒｏＳｅ ＵＥ−ネットワークリレーは、公衆安全通信に関連するいかなる種類のトラヒックも中継することができる一般的な機能を提供するものとする。

【0127】

リモートＵＥとＰｒｏＳｅ ＵＥ−ネットワークリレーとの間の１対１直接通信は以下の特性を有する。
− ＰＣ５基準点を通じた通信はコネクションレスである。
− ＰｒｏＳｅベアラは双方向である。所与のＰｒｏＳｅベアラ上の無線レイヤに渡されるＩＰパケットは、関連するＬ２宛先アドレスを持つ物理レイヤによって送信されるであろう。同じＰｒｏＳｅベアラ上の無線レイヤから上方へ渡されるＩＰパケットは、同じＬ２宛先にアドレス指定される無線で受信されるであろう。

【0128】

ＰｒｏＳｅ ＵＥ−ネットワークリレーは以下の機能を含んでもよい。
− モデルＡまたはモデルＢに従うＰｒｏＳｅ直接発見は、リモートＵＥが近接のＰｒｏＳｅ ＵＥ−ネットワークリレーを発見するのを許容するために使用されることができる。
− ＰｒｏＳｅ ＵＥ−ネットワークリレーのＬ２アドレスがＰｒｏＳｅ ＵＥ−ネットワークリレーによってサポートされる特定のＰＤＮ接続に対応するＩＰアドレス割当ておよびユーザプレーントラヒックのためにリモートＵＥによって使用されるのをリモートＵＥが発見するのを許容するために使用されることができるＰｒｏＳｅ直接発見。
− 直接発見をサポートするＰＣ５基準点上の「アナウンス」または「被発見者」ＵＥとして作用する。
−ＵＥ−ＰｒｏＳｅ ＵＥ−ネットワークリレーポイントツーポイントリンクと対応するＰＤＮ接続との間でＩＰパケットを転送する、リモートＵＥに対するデフォルトルータとして作用する。
− ＩＥＴＦ ＲＦＣ４８６１に規定されるルータ要請およびルータ広告メッセージを取り扱う。
− ＤＨＣＰｖ４サーバおよびステートレスＤＨＣＰｖ６リレーエージェントとして作用する。
− ＩＰｖ４が使用される場合ＮＡＴとして作用し、リモートＵＥのローカルに割り当てられたＩＰｖ４アドレスをそれ自体のものに置き換える。
− 宛先レイヤ２ＩＤとしてリモートＵＥによって使用されるＬ２リンクＩＤを、ＰｒｏＳｅ ＵＥ−ネットワークリレーによってサポートされる対応ＰＤＮ接続にマッピングする。

【0129】

ＰｒｏＳｅ ＵＥ−ネットワークリレーのためのユーザプレーンプロトコルアーキテクチャが図１２に示される。２つのＰｒｏＳｅ ＵＥ間の通例のＲｅｌ．−１２直接発見に関して上述したように、モデルＡおよびモデルＢ発見の両方がサポートされ、ここでモデルＡは単一の発見プロトコルメッセージ（ＵＥ−ネットワークリレー発見アナウンス）を使用し、モデルＢは２つの発見プロトコルメッセージ（ＵＥ−ネットワークリレー発見要請およびＵＥ−ネットワークリレー発見応答）を使用する。リレー発見に関する詳細は、参照により本明細書に援用される非特許文献６の６節に見られることができる。

【0130】

＜ＰｒｏＳｅ ＵＥ−ネットワークリレーを介するＰｒｏＳｅ方向通信＞
ＵＥ−ネットワークリレー機能は、上述した非特許文献８に既に文書化されたＰｒｏＳｅ機能性の進化に基づいて明記されることになる。

【0131】

ＰｒｏＳｅ ＵＥ−ネットワークリレー可能ＵＥがネットワークにアタッチし（それが既に接続されていない場合）、必要なリレートラヒックを可能にするＰＤＮ接続に接続してもよく、またはそれは、リモートＵＥに向けてリレートラヒックを提供するために追加のＰＤＮ接続に接続する必要があってもよい。ＵＥ−ネットワークリレーをサポートするＰＤＮ接続は、リモートＰｒｏＳｅ ＵＥリレートラヒックのためにのみ使用されるものとする。

【0132】

以上説明したように、３ＧＰＰは、主要な作業項目として、リレー発見およびリレー直接通信を含むＰｒｏＳｅリレー機能性を導入する。ＰｒｏＳｅリレーのための現在規定されているメカニズムのいくつかはかなり非効率的である。他のメカニズムは、リレー可能ＰｒｏＳｅ ＵＥがどのように、およびいつリレーとして実際に作用し始める、すなわち無線セルにリレーサービスを提供し始めるかなど、全く承認されていない。

【先行技術文献】

【非特許文献】

【0133】

【非特許文献1】3GPP TS 36.211、「Evolved Universal Terrestrial Radio Access (E-UTRA); Physical Channels and Modulation」、version 12.6.0

【非特許文献2】3GPP TS 36.321、version 12.6.0

【非特許文献3】3GPP TS 23.203、v13.4.0

【非特許文献4】3GPP 36.212、「Multiplexing and channel coding」、version 12.5.0

【非特許文献5】3GPP、TR 36.843、version 12.0.1

【非特許文献6】3GPP、TR 23.713、version v1.4.0

【非特許文献7】3GPP、TS 36.300、version 13.0.0

【非特許文献8】3GPP、TS 23.303、version 13.0.0

【発明の概要】

【課題を解決するための手段】

【0134】

非限定的かつ例証的な実施形態が、リモート機器に対するリレーとして働いているリレーユーザ機器のために無線リソースをスケジュールするための改善された方法を提供する。独立請求項が非限定的かつ例示的な実施形態を提供する。有利な実施形態は従属請求項に従う。

【0135】

本明細書に記載されるいくつかの態様によれば、リレーＵＥと無線基地局との間で行われる無線リソーススケジューリングが改善される。これらの態様を論ずるために、以下の前提が立てられる。

【0136】

特に、関連したリレーユーザ機器が他のリモートユーザ機器との直接通信を（すなわちそれぞれの直接サイドリンク接続を介して）行うことが可能であることを前提とする。さらには、「リレー可能ユーザ機器」という用語は、ユーザ機器が、それぞれ１つまたは複数のリモートユーザ機器に対するリレーとして働くことが可能であるためのリレー機能性をサポートするという点で理解されるものとする。１つまたは複数のリモートユーザ機器がリレーＵＥとリレー発見手順を行い、リレーＵＥを選択した上で、選択したリレーＵＥとの直接サイドリンクインタフェース（ＰＣ５）を介する直接サイドリンク接続を確立したことをさらに前提とする。１つまたは複数のリモートユーザ機器と（リレーユーザ機器が接続される）無線基地局との間の通信が、確立した直接リンク（例えばＰＣ５インタフェース上のサイドリンク無線ベアラ）を介して、およびリレーＵＥと無線基地局との間の対応する論理チャネルを介してリレーユーザ機器によって中継されるものとする。

【0137】

結果的に、リモートデータおよびリレーデータが無線基地局とリレーＵＥとの間で交換されることになるが、リモートデータはこの場合、リモートＵＥから発信する、またはリモートＵＥに宛てられるデータを指し、リレーデータはこの場合、リレーＵＥから発信する、またはリレーＵＥに宛てられるデータを指す。アップリンクの場合には、リレーＵＥは、無線基地局への送信のために利用可能なそのバッファにリモートデータおよびリレーデータを有することになる。無線基地局でのリソーススケジューリング機能は、したがって、リレーＵＥが無線基地局とリモートデータおよびリレーデータの両方を交換（すなわち送信／受信）することができるであろうことを確認しなければならないことになる。

【0138】

第１の態様によれば、リレーＵＥと無線基地局との間で行われる無線リソーススケジューリング手順は、リモートデータを送信／受信するための無線リソースおよびリレーデータを送信／受信するための無線リソースを別々にアドレス指定することを許容することによって改善される。上記の点で、リレーＵＥのための異なるスケジューリング識別情報が、リレーデータかまたはリモートデータかいずれかに向けられることになるそれぞれのリソース割当てに含まれるように設けられる。特に、リモートスケジューリングＩＤが、１つまたは複数のリモート論理チャネル、すなわち１つまたは複数のリモートＵＥから発信する、またはリモートＵＥに宛てられるリモートデータを通知するためにリレーＵＥと無線基地局との間に確立される論理チャネルをアドレス指定するように設定されることができる。他方で、リレースケジューリングＩＤが、１つまたは複数のリレー論理チャネル、すなわちリレーＵＥから発信する、またはリレーＵＥに宛てられるリレーデータを通知するためにリレーＵＥと無線基地局との間に確立される論理チャネルをアドレス指定するように設定されることができる。

【0139】

対応して、無線基地局は、リレーＵＥに無線リソースを、詳細にはリモートデータかまたはリレーデータかいずれかに関連してのみ使用されるように割り当てることができる。例えば、無線基地局は、詳細には対応するリモート論理チャネルに対するリモートスケジューリングＩＤを介してアドレス指定されるリモートリソース割当てを準備することができ、したがってリレーＵＥが無線基地局とリモートデータを交換（すなわち送信／受信）するために使用してもよい無線リソースを割り当てる。同様に、無線基地局は、詳細には対応するリレー論理チャネルに対するリレースケジューリングＩＤを介してアドレス指定されるリレーリソース割当てを準備することができ、したがってリレーＵＥが無線基地局とリレーデータを交換（すなわち送信／受信）するために使用してもよい無線リソースを割り当てる。

【0140】

全体として、無線基地局が１つのリレーＵＥに「異なる」リソース割当てを送信することができるように、リレーＵＥには２つの異なるリソーススケジューリングＩＤが設定されることになる。結果的に、無線基地局は、したがって、リソーススケジューリングを行うときにリモートおよびリレーデータ間を（すなわちリモートおよびリレー論理チャネル間を）区別することを可能にされる。

【0141】

第１の態様の変形によれば、リレーＵＥには、リモートおよびリレーデータを扱うように、対応する別々のＭＡＣエンティティ、すなわち、リレーデータを扱うためのリレーＭＡＣエンティティおよびリモートデータを扱うためのリモートＭＡＣエンティティが設定される。この変形では、リモートスケジューリングＩＤは、直接にか（上記を参照のこと）またはリモートＭＡＣエンティティと関連づけられることを介してかいずれかで、リモート論理チャネルと関連づけられる。同様に、リレースケジューリングＩＤは、直接にか（上記を参照のこと）またはリレーＭＡＣエンティティと関連づけられることを介してかいずれかで、リレー論理チャネルと関連づけられる。さらには、異なるＭＡＣ機能がこれらの２つのＭＡＣエンティティにどのように分配または重複されるかに関するいくつかの異なる可能な実装がある。例えば、ＨＡＲＱエンティティはこれらの２つのＭＡＣエンティティ間で共有されることも、または別々のＨＡＲＱエンティティが、各ＭＡＣエンティティに１つのＨＡＲＱエンティティで、設けられることもできる。さらなる例として、ＲＡＣＨ手順は、リレーＭＡＣエンティティによってのみサポートされてもよい。

【0142】

その上、第１の態様の１つの有利な実装が、別々の（異なる）リソース割当てを扱うように、別々のＬＣＰ手順（例えば別々のＭＡＣエンティティにそれぞれ１つ）を提供する。特に、（例えばリモートＭＡＣエンティティでの）リモートＬＣＰ手順は、無線基地局への送信のために利用可能なリモートデータを有するリモート論理チャネルに、対応するリモートリソース割当てで割り当てられる無線リソースを分配することを許容する。このようにして生成されるトランスポートブロックは、リレーデータでなくリモートデータを通知するものである。他方で、（例えばリレーＭＡＣエンティティでの）リレーＬＣＰ手順は、無線基地局への送信のために利用可能なリレーデータを有するリレー論理チャネルに、対応するリレーリソース割当てで割り当てられる無線リソースを分配することを許容する。このようにして生成されるトランスポートブロックは、リモートデータでなくリレーデータを通知するものである。

【0143】

その上、第１の態様の有利な実装が、第１の態様に関して上論した改善されたスケジューリング手順を支援するようにバッファ状況報告手順をさらに改善する。無線基地局がリレーＵＥにリモートおよびリレーデータのために無線リソースを別々に割り当てるのを許容するために、リレーＵＥは、バッファされたリレーデータおよびバッファされたリモートデータを別々に報告するものとする。特に、リレーＵＥは、リレーＵＥの対応するバッファにおける無線基地局への送信のために利用可能であるリレーデータ量に関するリレーＢＳＲ報告を生成する。反対に、リレーＵＥは、リレーＵＥの対応するバッファにおける無線基地局への送信のために利用可能であるリモートデータ量に関するリモートＢＳＲ報告も生成する。ＢＳＲ報告をさらに改善するように、追加の論理チャネルグループがリモートデータに対して規定されることができる。特に、背景で説明したように、一組の（リレー）論理チャネルグループが既に規定され、ＢＳＲ報告に関連して使用されてＬＣＧ当たりのバッファサイズを報告する。これらの（リレー）論理チャネルグループに加えて、さらなるリモート論理チャネルグループが規定されることができ、リモート論理チャネルの各々はリモート論理チャネルグループの１つに割り当てられる。対応して、リモートバッファ状況報告は、したがって、これらのリモート論理チャネルグループに基づいて、すなわち、各リモート論理チャネルグループに対してバッファ状況フィールドを設けることによって（例えば、バッファ状況フィールドは、上記リモート論理チャネルグループのすべてのリモート論理チャネルに渡って無線基地局への送信のために利用可能なデータ量を示す）、リモートデータ量を報告することができるであろう。対応するリモートバッファ状況報告は、規定されたリモート論理チャネルグループのすべてに対してバッファ状況フィールドを備える必要はなくてもよく、その１つまたは複数に対してバッファ状況フィールドを備えるのみでもよいことに留意するべきである。

【0144】

第１の態様のさらなる有利な変形が、リモートサイドリンク論理チャネル（リレーＵＥとリモートＵＥの各々との間のリモートサイドリンク論理チャネル）の、（リレーＵＥと無線基地局との間の）対応するリモート論理チャネルへのマッピングに関する。１つの変形によれば、アップリンクでは、論理チャネルのｎ対１マッピングが、それらのそれぞれの論理チャネル優先度（または論理チャネルのＱｏＳ要件）に基づいて規定されることができる。特に、特定の論理チャネル優先度／ＱｏＳのリモートサイドリンク論理チャネルの各々は、同じまたは同様の特定の論理チャネル優先度／ＱｏＳを持つ対応するリモート論理チャネルに多重化される。対応して、リレーＵＥによってリモートＵＥから受信されるリモートデータが多重化されて、対応するＱｏＳを持つリモート論理チャネルを通じて通知され、それによってリモートデータの特定のＱｏＳ要件が実際に満たされることを保証する。

【0145】

反対に、ダウンリンクでは、論理チャネルの１対ｎマッピングが、やはりそれらのそれぞれの論理チャネル優先度／関連するＱｏＳ要件に基づいて規定されることができる。特に、特定の論理チャネル優先度／ＱｏＳのリモート論理チャネルが、同じまたは同様の特定の論理チャネル優先度／ＱｏＳを有する、対応する（どれくらいのリモートサイドリンク論理チャネルが実際に存在するかに応じて）１つまたは複数のリモートサイドリンク論理チャネルに逆多重化される。対応して、リレーＵＥによって無線基地局から受信されるリモートデータが逆多重化されて、対応するＱｏＳを持つそれぞれのリモートサイドリンク論理チャネルを通じてリモートＵＥに通知され、それによってリモートデータの特定のＱｏＳ要件が実際に満たされることを保証する。

【0146】

以下に記載される第２の態様は、第１の態様に関して説明したものと同様のシナリオを前提とするものとする。この第２の態様によれば、リレーＵＥと無線基地局との間で行われる無線リソーススケジューリング手順は、リレーＵＥによるバッファ状況報告がリモートデータとリレーデータとの間を区別するという点で改善される。特に、第２の態様は、リモートデータおよびリレーデータに対する別々のバッファ状況報告を送信することに基づき、さらにリモートデータおよびリレーデータのための別々の論理チャネルグループを規定することに基づく。背景で説明したように、一組の（リレー）論理チャネルグループが既に規定され、ＢＳＲ報告に関連して使用される。この一組のリレー論理チャネルグループに加えて、追加の論理チャネルグループがリモートデータに対して規定され、ここでリモート論理チャネルの各々は、リレー論理チャネルがリレー論理チャネルグループの１つに割り当てられるのと同様にして、リモート論理チャネルグループの１つに割り当てられる。したがって、リレーＵＥは、バッファ状況報告を行うときに、以下に説明することになるように、リレー論理チャネルで通知されるデータとリモート論理チャネルで通知されるデータとの間を区別することができる。

【0147】

特に、リレーＵＥは、リレーＵＥにおける（すべてリモート論理チャネルに渡って）無線基地局への送信のために利用可能なリモートデータ量を示すようにリモートバッファ状況報告を準備する。リモートバッファ状況報告の内容は、１つの（バッファサイズフィールドとも名付けられる）バッファ状況フィールドがリモート論理チャネルグループの各々に対してリモートバッファ状況報告に設けられるように、リモート論理チャネルグループに基づいて分割され、このバッファ状況フィールドは、上記特定のリモート論理チャネルグループのすべてのリモート論理チャネルに渡って無線基地局への送信のために利用可能なデータ量を示す。対応するリモートバッファ状況報告は、特にリモート論理チャネルグループのいくつかに対して、バッファ状況フィールドがゼロを示す（すなわち、送信されることになるリモートデータがない）可能性があることを考慮して、規定されたリモート論理チャネルグループのすべてに対してバッファ状況フィールドを備える必要はなくてもよく；対応して、リモートバッファ状況報告は、それがすべてのリモート論理チャネルに渡って無線基地局への送信のために利用可能な総リモートデータ量を示すべきであるとは言え、リモート論理チャネルグループの１つまたは複数に対してバッファ状況フィールドを備えるのみでもよいことに留意するべきである。

【0148】

このようにして用意されるリモートバッファ状況報告およびリレーバッファ状況報告は無線基地局に送信され、無線基地局が次いで、適切なアップリンクリソース割当てを準備するように報告の情報を使用し、無線基地局にアップリンクでリモートデータおよびリレーデータを送信するためにリレーユーザ機器に無線リソースを割り当てる。

【0149】

対応して、リレーＵＥはこのアップリンクリソース割当てを受信し、対応する論理チャネル優先順位付け（ＬＣＰ）手順の間に、示された無線リソースを、無線基地局への送信のために利用可能なデータを有するリモート論理チャネルおよびリレー論理チャネルの両方に割り当てる。より詳細には、対応して生成されるトランスポートブロックがリレーデータおよびリモートデータの両方を備えてもよいようにリモートおよびリレー両方の論理チャネルを考慮する単一のＬＣＰ手順がリレーＵＥによって行われる。背景で説明したように、ＬＣＰ手順は、（リレーおよびリモート）論理チャネルをそれらの論理チャネル優先度の降順に考慮してもよい。さらには、リモート論理チャネルがリレー論理チャネルと同じ論理チャネル優先度を有する場合には、ＬＣＰ手順はリレー論理チャネルよりリモート論理チャネルを優先してもよく、そうするとＬＣＰ手順は無線リソースを、まずリモート論理チャネルに、次いで（リソースが依然利用可能であれば）リレー論理チャネルに割り当て、その逆もまた同じである。

【0150】

リレーＵＥによって行われることになるＬＣＰ手順のためのさらなる改善は、リレーＢＳＲよりリモートＢＳＲの優先、またはその逆に関する。特に、バッファ状況報告は、概してＬＣＰ手順の間、通常のユーザデータより優先されるＭＡＣ制御要素を使用して送信されてもよい。さらには、この改善によれば、リモートバッファ状況報告を通知するＭＡＣ ＣＥがリレーバッファ状況報告を通知するＭＡＣ ＣＥより優先されるものとし、その逆もまた同じである。

【0151】

対応して、１つの一般的な第１の態様では、ここで開示する技術は、移動通信システムにおけるリレーユーザ機器のために無線リソースをスケジュールするための方法を特徴とする。リレーユーザ機器は、それぞれ１つまたは複数のリモートユーザ機器に対するリレーとして働くことが可能であるためのリレー機能性をサポートし、そうすると１つまたは複数のリモートユーザ機器から発信する、またはリモートユーザ機器に宛てられるリモートデータが、１つまたは複数のリモートユーザ機器と無線基地局との間でリレーユーザ機器によって中継される。リモートスケジューリング識別情報が、リレーユーザ機器と無線基地局との間でリモートデータを通知する１つまたは複数のリモート論理チャネルをアドレス指定するために設定される。リレースケジューリング識別情報が、リレーユーザ機器と無線基地局との間で、リレーユーザ機器から発信する、またはリレーユーザ機器に宛てられるリレーデータを通知する１つまたは複数のリレー論理チャネルをアドレス指定するために設定される。本方法は、リレーユーザ機器によって行われる以下のステップを含む。リレーＵＥは、無線基地局とリモートデータを交換するためにリレーユーザ機器に無線リソースを割り当てるリモートリソース割当てを無線基地局から受信し、ここでリモートリソース割当てはリモートスケジューリング識別情報にアドレス指定される。リレーＵＥは、無線基地局とリレーデータを交換するためにリレーユーザ機器に無線リソースを割り当てるリレーリソース割当てを無線基地局から受信し、ここでリレーリソース割当てはリレースケジューリング識別情報にアドレス指定される。

【0152】

対応して、１つの一般的な第１の態様では、ここで開示する技術は、無線リソースがスケジュールされるためのリレーユーザ機器を特徴とする。リレーユーザ機器は、それぞれ１つまたは複数のリモートユーザ機器に対するリレーとして働くことが可能であるためのリレー機能性をサポートし、そうすると１つまたは複数のリモートユーザ機器から発信する、またはリモートユーザ機器に宛てられるリモートデータが、１つまたは複数のリモートユーザ機器と無線基地局との間でリレーユーザ機器によって中継される。リモートスケジューリング識別情報が、リレーユーザ機器と無線基地局との間でリモートデータを通知する１つまたは複数のリモート論理チャネルをアドレス指定するために設定される。リレースケジューリング識別情報が、リレーユーザ機器と無線基地局との間で、リレーユーザ機器から発信する、またはリレーユーザ機器に宛てられるリレーデータを通知する１つまたは複数のリレー論理チャネルをアドレス指定するために設定される。リレーＵＥの受信器が、無線基地局とリモートデータを交換するためにリレーユーザ機器に無線リソースを割り当てるリモートリソース割当てを無線基地局から受信し、ここでリモートリソース割当てはリモートスケジューリング識別情報にアドレス指定される。受信器は、無線基地局とリレーデータを交換するためにリレーユーザ機器に無線リソースを割り当てるリレーリソース割当てを無線基地局からさらに受信し、ここでリレーリソース割当てはリレースケジューリング識別情報にアドレス指定される。

【0153】

対応して、１つの一般的な第１の態様では、ここで開示する技術は、移動通信システムにおけるリレーユーザ機器のために無線リソースをスケジュールするための無線基地局を特徴とする。リレーユーザ機器は、それぞれ１つまたは複数のリモートユーザ機器に対するリレーとして働くことが可能であるためのリレー機能性をサポートし、そうすると１つまたは複数のリモートユーザ機器から発信する、またはリモートユーザ機器に宛てられるリモートデータが、１つまたは複数のリモートユーザ機器と無線基地局との間でリレーユーザ機器によって中継される。リモートスケジューリング識別情報が、リレーユーザ機器と無線基地局との間でリモートデータを通知する１つまたは複数のリモート論理チャネルをアドレス指定するために設定される。リレースケジューリング識別情報が、リレーユーザ機器と無線基地局との間で、リレーユーザ機器から発信する、またはリレーユーザ機器に宛てられるリレーデータを通知する１つまたは複数のリレー論理チャネルをアドレス指定するために設定される。無線基地局のプロセッサが、無線基地局とリモートデータを交換するためにリレーユーザ機器に無線リソースを割り当てるリモートリソース割当てを生成し、ここでリモートリソース割当てはリモートスケジューリング識別情報にアドレス指定される。プロセッサは、無線基地局とリレーデータを交換するためにリレーユーザ機器に無線リソースを割り当てるリレーリソース割当てをさらに生成し、ここでリレーリソース割当てはリレースケジューリング識別情報にアドレス指定される。無線基地局の送信器が、リレーＵＥにリモートリソース割当ておよび／またはリレーリソース割当てを送信する。

【0154】

対応して、１つの一般的な第２の態様では、ここで開示する技術は、移動通信システムにおけるリレーユーザ機器のために無線リソースをスケジュールするための方法を特徴とする。リレーユーザ機器は、それぞれ１つまたは複数のリモートユーザ機器に対するリレーとして働くことが可能であるためのリレー機能性をサポートし、そうすると１つまたは複数のリモートユーザ機器から発信する、またはリモートユーザ機器に宛てられるリモートデータが、１つまたは複数のリモートユーザ機器と無線基地局との間でリレーユーザ機器によって中継される。１つまたは複数のリレー論理チャネルが、リレーユーザ機器と無線基地局との間で、リレーユーザ機器から発信する、またはリレーユーザ機器に宛てられるリレーデータを通知するために確立される。１つまたは複数のリモート論理チャネルが、リレーユーザ機器と無線基地局との間で、１つまたは複数のリモートユーザ機器から発信する、またはリモートユーザ機器に宛てられるリモートデータを通知するために確立される。リレー論理チャネルグループが規定され、ここではリレー論理チャネルの各々はリレー論理チャネルグループの１つに割り当てられる。リモート論理チャネルグループが規定され、ここではリモート論理チャネルの各々はリモート論理チャネルグループの１つに割り当てられる。本方法は、リレーユーザ機器によって行われる以下のステップを含む。リレーバッファ状況報告が、リレー論理チャネルグループに対して１つのバッファサイズフィールドを備えて、リレーＵＥによって生成され、１つのバッファサイズフィールドは、上記リレー論理チャネルグループのすべてのリレー論理チャネルに渡って送信のために利用可能な総リレーデータ量を示す。リモートバッファ状況報告が、リモート論理チャネルグループに対して１つのバッファサイズフィールドを備えて、ＵＥによって生成され、１つのバッファサイズフィールドは、上記リモート論理チャネルグループのすべてのリモート論理チャネルに渡って送信のために利用可能な総リモートデータ量を示す。リレーＵＥは次いで、無線基地局にリレーバッファ状況報告およびリモートバッファ状況報告を送信する。応答して、リレーＵＥは、無線基地局にリモートデータおよびリレーデータを送信するためにリレーユーザ機器に無線リソースを割り当てるアップリンクリソース割当てを無線基地局から受信し、アップリンクリソース割当ては、リレーバッファ状況報告およびリモートバッファ状況報告に基づいて無線基地局によって生成されている。

【0155】

対応して、１つの一般的な第２の態様では、ここで開示する技術は、無線リソースがスケジュールされるためのリレーユーザ機器を特徴とする。リレーユーザ機器は、それぞれ１つまたは複数のリモートユーザ機器に対するリレーとして働くことが可能であるためのリレー機能性をサポートし、そうすると１つまたは複数のリモートユーザ機器から発信する、またはリモートユーザ機器に宛てられるリモートデータが、１つまたは複数のリモートユーザ機器と無線基地局との間でリレーユーザ機器によって中継される。１つまたは複数のリレー論理チャネルが、リレーユーザ機器と無線基地局との間で、リレーユーザ機器から発信する、またはリレーユーザ機器に宛てられるリレーデータを通知するために確立される。１つまたは複数のリモート論理チャネルが、リレーユーザ機器と無線基地局との間で、１つまたは複数のリモートユーザ機器から発信する、またはリモートユーザ機器に宛てられるリモートデータを通知するために確立される。リレー論理チャネルグループが規定され、ここではリレー論理チャネルの各々はリレー論理チャネルグループの１つに割り当てられる。リモート論理チャネルグループが規定され、ここではリモート論理チャネルの各々はリモート論理チャネルグループの１つに割り当てられる。リレーＵＥのプロセッサが、リレー論理チャネルグループに対して１つのバッファサイズフィールドを備えるリレーバッファ状況報告を生成し、１つのバッファサイズフィールドは、上記リレー論理チャネルグループのすべてのリレー論理チャネルに渡って送信のために利用可能な総リレーデータ量を示す。プロセッサは、リモート論理チャネルグループに対して１つのバッファサイズフィールドを備えるリモートバッファ状況報告をさらに生成し、１つのバッファサイズフィールドは、上記リモート論理チャネルグループのすべてのリモート論理チャネルに渡って送信のために利用可能な総リモートデータ量を示す。リレーＵＥの送信器が、無線基地局にリレーバッファ状況報告およびリモートバッファ状況報告を送信する。リレーＵＥの受信器が、無線基地局にリモートデータおよびリレーデータを送信するためにリレーユーザ機器に無線リソースを割り当てるアップリンクリソース割当てを無線基地局から受信し、アップリンクリソース割当ては、リレーバッファ状況報告およびリモートバッファ状況報告に基づいて無線基地局によって生成されている。

【0156】

対応して、１つの一般的な第２の態様では、ここで開示する技術は、移動通信システムにおけるリレーユーザ機器のために無線リソースをスケジュールするための無線基地局を特徴とする。リレーユーザ機器は、それぞれ１つまたは複数のリモートユーザ機器に対するリレーとして働くことが可能であるためのリレー機能性をサポートし、そうすると１つまたは複数のリモートユーザ機器から発信する、またはリモートユーザ機器に宛てられるリモートデータが、１つまたは複数のリモートユーザ機器と無線基地局との間でリレーユーザ機器によって中継される。１つまたは複数のリレー論理チャネルが、リレーユーザ機器と無線基地局との間で、リレーユーザ機器から発信する、またはリレーユーザ機器に宛てられるリレーデータを通知するために確立される。１つまたは複数のリモート論理チャネルが、リレーユーザ機器と無線基地局との間で、１つまたは複数のリモートユーザ機器から発信する、またはリモートユーザ機器に宛てられるリモートデータを通知するために確立される。リレー論理チャネルグループが規定され、ここではリレー論理チャネルの各々はリレー論理チャネルグループの１つに割り当てられる。リモート論理チャネルグループが規定され、ここではリモート論理チャネルの各々はリモート論理チャネルグループの１つに割り当てられる。無線基地局の受信器が、リレー論理チャネルグループに対して１つのバッファサイズフィールドを備えるリレーバッファ状況報告を受信し、１つのバッファサイズフィールドは、上記リレー論理チャネルグループのすべてのリレー論理チャネルに渡って送信のために利用可能な総リレーデータ量を示す。受信器は、リモート論理チャネルグループに対して１つのバッファサイズフィールドを備えるリモートバッファ状況報告をさらに受信し、１つのバッファサイズフィールドは、上記リモート論理チャネルグループのすべてのリモート論理チャネルに渡って送信のために利用可能な総リモートデータ量を示す。無線基地局のプロセッサが、無線基地局にリモートデータおよびリレーデータを送信するためにリレーユーザ機器に無線リソースを割り当てるアップリンクリソース割当てを生成し、アップリンクリソース割当ては、リレーバッファ状況報告およびリモートバッファ状況報告に基づいてプロセッサによって生成される。無線基地局の送信器が、リレーＵＥに生成されたアップリンクリソース割当てを送信する。

【0157】

開示した実施形態の追加の利益および利点は本明細書および図から明らかだろう。利益および／または利点は、明細書および図面の開示の様々な実施形態および特徴によって個々に提供されてもよく、同利益および／または利点の１つまたは複数を得るためにすべて提供される必要があるわけではない。
これらの一般的なおよび特定の態様はシステム、方法およびコンピュータプログラム、ならびにシステム、方法およびコンピュータプログラムの任意の組合せを使用して実装されてもよい。

【0158】

以下では、例示的な実施形態が添付の図および図面を参照しつつより詳細に記載される。

【図面の簡単な説明】

【0159】

【図1】３ＧＰＰ ＬＴＥシステムの例示的なアーキテクチャを示す図である。

【図2】３ＧＰＰ ＬＴＥ（Ｒｅｌｅａｓｅ８／９）に定義されるサブフレームのダウンリンクスロットの例示的なダウンリンクリソースグリッドを示す図である。

【図3】ＵＥ側の例示的なＭＡＣ構造を示す図である。

【図4】ＬＴＥのためのベアラアーキテクチャを示す図である。

【図5】ＰｒｏＳｅ通信のためのＰＣ５上のレイヤ２リンクの確立のさせ方を概略的に示す図である。

【図6】オーバーレイ（ＬＴＥ）およびアンダーレイ（Ｄ２Ｄ）システムのための送信／受信リソースの使用を示す図である。

【図7】２つのＵＥに対するスケジューリング割当ておよびＤ２Ｄデータの送信を示す図である。

【図8】非ローミングシナリオについてのＰｒｏＳｅのための例示的なアーキテクチャモデルを示す図である。

【図9】Ｄ２Ｄ ＵＥが関連づけられることができる４つの異なる状態に関するセルカバレージを示す図である。

【図10】偶数のＰｒｏＳｅ宛先グループの場合の例示的なＰｒｏＳｅバッファ状況報告ＭＡＣ制御要素を示す図である。

【図11】ＰｒｏＳｅ ＵＥ−ネットワークリレーシナリオを示す図である。

【図12】ＰｒｏＳｅ ＵＥ−ネットワークリレーのためのユーザプレーンプロトコルアーキテクチャを示す図である。

【図13】第１の実施形態の例示的な実装に係るリレーＵＥのための２つのＭＡＣエンティティの構造を示す図である。

【図14】第１の実施形態の別の例示的な実装に係るリレーＵＥのための２つのＭＡＣエンティティの別の構造を示す図である。

【図15】第１および第２の実施形態に関連して使用されることになるサイドリンク無線ベアラとリモート無線ベアラとの間の論理チャネルマッピングを示す図である。

【図16】第２の実施形態の例示的な実装に係るリレーＵＥのためのＭＡＣエンティティの構造を示す図である。

【発明を実施するための形態】

【0160】

移動局または移動ノードまたはユーザ端末またはユーザ機器は、通信ネットワーク内の物理エンティティである。１つのノードがいくつかの機能エンティティを有してもよい。機能エンティティは、所定の機能の集合をノードの他の機能エンティティまたはネットワークに実装および／または提供するソフトウェアまたはハードウェアモジュールを指す。ノードは、ノードが通信するために介することができる通信機構または媒体にノードを取り付ける１つまたは複数のインタフェースを有してもよい。同様に、ネットワークエンティティは、機能エンティティが他の機能エンティティまたは対応ノードと通信するために介してもよい通信機構または媒体に機能エンティティを取り付ける論理インタフェースを有してもよい。

【0161】

「リレーユーザ機器」は、本願の請求項でおよび本出願で使用する場合、（「リモートユーザ機器」と名付けられる）別のユーザ機器に対するリレーとして働くことが可能であるユーザ機器を指すとして広く理解しなければならない。これは、直接に２つのユーザ機器間の直接通信送信をサポートする能力も伴う（以下Ｄ２ＤまたはＰｒｏＳｅを参照のこと）。１つの実装によれば、リレーユーザ機器は、３ＧＰＰ ＬＴＥ−Ａに規定されるように、および背景に記載したようにリレー機能性をサポートするものとする。上記の関連で、用語「リモートユーザ機器」は単に、リレーユーザ機器のピアである、すなわち直接通信を確立するリレーを探しているとしてのユーザ機器の役割を示すだけのものとする。

【0162】

用語「無線リソース」は、本願の請求項でおよび本出願で使用する場合、時間−周波数リソースなどの物理無線リソースを指すとして広く理解しなければならない。

【0163】

用語「直接通信送信」は、本願の請求項でおよび本出願で使用する場合、直接に２つのユーザ機器間の、すなわち無線基地局（例えばｅＮＢ）を介さない送信として広く理解しなければならない。対応して、直接通信送信は「直接サイドリンク接続」を通じて行われ、これは直接に２つのユーザ機器間に確立される接続のために使用される用語である。例えば、３ＧＰＰでは、Ｄ２Ｄ（デバイスツーデバイス）通信またはＰｒｏＳｅ通信またはサイドリンク通信の専門用語が使用される。用語「直接サイドリンク接続」は、本願の請求項でおよび本出願で使用する場合、背景に記載したＰＣ５インタフェースとして広く理解しなければならず、かつ３ＧＰＰコンテキストで理解することができる。

【0164】

用語「リレー機能性」は、本願の請求項でおよび本出願で使用する場合、リレーとして作用するユーザ機器の能力として広く理解しなければならない。１つの例示的な実装では、リレー機能性は、背景で詳細に説明したように３ＧＰＰ作業項目で現在標準化されている機能性である。

【0165】

用語「リモートデータ」は、本願の請求項でおよび本出願で使用する場合、リモートユーザ機器、すなわち無線基地局にリレーユーザ機器を介して接続されているユーザ機器から発信する（すなわちアップリンク）またはリモートユーザ機器に宛てられる（すなわちダウンリンク）データとして広く理解しなければならない。言い換えると、リモートデータは、リモートユーザ機器によって生成されてリレーＵＥを介して無線基地局に（そして、例えば、さらにピアユーザ機器に向けて）アップリンクで送信されるか、または別のピアユーザ機器によって生成されるが、リモートユーザ機器に宛てられる（したがって、リレーユーザ機器を介してリモートユーザ機器によって受信される）。他方で、「リレーデータ」は、本願の請求項でおよび本出願で使用する場合、リレーユーザ機器、すなわちリモートユーザ機器に対するリレーとして働くことが可能であるようにリレー機能性を有するユーザ機器から発信する（すなわちアップリンク）またはリレーユーザ機器に宛てられる（すなわちダウンリンク）データとして広く理解しなければならない。そのため、「リモートデータ」および「リレーデータ」は異なるソース／宛先からのデータを指し、そうするとリレーユーザ機器は、それ自体のリレーデータに加えて、１つまたは複数のリモートユーザ機器のためにアップリンク／ダウンリンクでリモートデータを送信しなければならないことがある。

【0166】

３ＧＰＰは、現在ＰｒｏＳｅ可能ユーザ機器のためのリレー機能性を導入する最中である。いくつかの初期取決めが既になされた（そのいくつかは背景で詳細に説明される）とは言え、ＰｒｏＳｅリレー機能性に関していくつかの重要な問題についてはまだ取決めがなされることはない。詳細な背景で以上説明したように、先だってＥ−ＵＴＲＡＮのカバレージ範囲（すなわちｅＮｏｄｅＢのカバレージ）内であったＵＥが、（例えばセルエッジ領域に、または建物内に移動するときに低ジオメトリなどの劣悪なチャネル環境により）Ｅ−ＵＴＲＡＮへの接続を失うと、ＰｒｏＳｅ ＵＥ−ネットワークリレーＵＥが、（リモートＵＥとも名付けられる）このＵＥに対して「ユニキャスト」サービスへの接続性をサポートする機能性を提供するものとする。特に、リモートＵＥがＰＣ５インタフェース（すなわちＰｒｏＳｅ直接通信）を通じてリレーＵＥと通信する一方で、リレーＵＥはｅＮｏｄｅＢとＵｕインタフェースを介して接続される。対応して、１つまたは複数のサイドリンク論理チャネルが、リモートＵＥの各々とそれぞれのリモートデータがＰＣ５インタフェースを介して交換されるために介することができるリレーＵＥとの間に確立される。他方で、通例のレガシー論理チャネルがリレーＵＥとｅＮｏｄｅＢとの間に確立されてリレーデータを通知する。これらの異なる論理チャネルの各々は、それら自体のＩＤ、優先度および満たされるべきＱｏＳ要件を有する。

【0167】

したがって、そのようなシナリオでの１つの重要な問題は、すべての論理チャネル／データの様々なＱｏＳ要件が満たされることを保証するように１つまたは複数のリモートユーザ機器に対するリレーとして働くリレーユーザ機器へのリソース割当て機能の効率的な提供のし方である。

【0168】

例えば、（リレーＵＥからｅＮｏｄｅＢへリモートデータを通知するために別の論理チャネルが設定／構成されることを前提として）、ｅＮｏｄｅＢがどのようにリモート論理チャネルをリレー論理チャネルから区別することができるものであるかは不明である。ｅＮｏｄｅＢがリモートおよびリレー論理チャネル間を適切に区別することを保証する１つの可能な方途は、サイドリンク論理チャネル（リモートＵＥとリレーＵＥとの間のサイドリンク無線ベアラ）と、リレーＵＥとｅＮｏｄｅＢとの間の対応する（リモート）論理チャネルとの間の１対１マッピングを提供することである。特に、ＰＣ５インタフェースの各サイドリンク論理チャネル／サイドリンク無線ベアラは、Ｕｕインタフェースの１つの論理チャネル／無線ベアラにマッピングされる。しかしながら、限定数の論理チャネルＩＤ（ＤＲＢ ＩＤ）のみが利用可能である（現在の標準化では８）ことに鑑みて、この手法は非常に限定的であることがあり、そうすると、これは、複数のリモートＵＥが１つのリレーＵＥに接続されるいくつかのシナリオに不十分であることがある。さらには、論理チャネルグループの数も現在わずか４に限定されるという課題があり、そうすると、（リモートデータを通知するＵｕインタフェースの）リモート論理チャネルおよびリレー論理チャネルは同じ論理チャネルグループに分類されることがある／されなければならない。結果として、論理チャネルグループ当たりのバッファサイズを示すバッファ状況報告、および、したがってバッファ状況報告を受信するｅＮｏｄｅＢは、リモート論理チャネルとリレー論理チャネルとの間を区別することができないことになる。

【0169】

以上説明した１つまたは複数の課題を軽減するために、以下の例示的な実施形態が発明者らによって考えられる。

【0170】

様々な実施形態の特定の実装が、様々な実施形態に関連して以下で説明するように特定の主要な特徴を追加しつつ、３ＧＰＰ規格によって与えられ、かつ背景で部分的に説明したような広範な仕様で実装されるものである。実施形態は、例えば上記技術背景に記載したように、３ＧＰＰ ＬＴＥ−Ａ（Ｒｅｌｅａｓｅ１０／１１／１２／１３）通信システムなどの移動通信システムに有利に使用されることができるが、しかし実施形態はこの特定の例示的な通信ネットワークでのその使用に限定されないことに留意するべきである。
説明は、本開示の範囲を限定するとしてではなく、本開示をよりよく理解するための実施形態の単なる例として理解するべきである。当業者は、請求項に述べるような本開示の一般的な原理が異なるシナリオに、かつ本明細書に明記しない方途で適用されることができることを認識しているべきである。例示目的で、いくつかの前提が立てられるが、しかしながら、それらは以下の実施形態の範囲を限定するものではない。

【0171】

さらには、上述したように、以下の実施形態は、３ＧＰＰ ＬＴＥ−Ａ（Ｒｅｌ．１２／１３）環境で実装されてもよい。様々な実施形態は主に、特定のメカニズム（リソーススケジューリング自体、ＢＳＲ、ＬＣＰなど）を変更／改善することによって、リレーＵＥとｅＮｏｄｅＢとの間で行われる改善されたスケジューリング手順を可能にするが、他の機能性（すなわち様々な実施形態によって変更されない機能性）は、しかしながら、背景で説明したのと厳密に同じままでもよいし、または様々な実施形態へのいかなる影響もなしで変更されてもよい。これは、例えば、ＵＥおよびｅＮｏｄｅＢでＭＡＣエンティティによって提供される様々な機能（例えばＨＡＲＱ、ＲＡＣＨ、（非）多重化、制御機能）または、リレーＵＥを発見し、中継が起きている発見したリレーＵＥとの直接サイドリンク接続を確立するような正確な手順にとっての他に、データがリモートユーザ機器とリレーユーザ機器との間でどのように中継されるかなどという正確な手順にとって真実である。

【0172】

ユーザ機器がＰｒｏＳｅ通信（ＰｒｏＳｅ対応ＵＥ）、すなわちｅＮｏｄｅＢを介する迂回のない直接にＵＥ間の直接Ｄ２Ｄ送信を行うことを可能にされるシナリオを前提としてもよい。さらには、シナリオにおけるこれらの（ＰｒｏＳｅ対応）ＵＥの少なくとも１つは、例えば３ＧＰＰ規格のＲｅｌｅａｓｅ１３における具体的な実装に関して背景で説明したように、リレー機能性をサポートするものとする。言い換えると、（無線セルに設けられ、無線セルを制御する対応無線基地局に接続される）このリレーＵＥは、他の（ＰｒｏＳｅ対応）ＵＥ（１つまたは複数のリモートＵＥ）に対してリレーとして働くことが可能であり、それによって、これらのリモートＵＥがリレーを介してｅＮＢに接続するのを許容するものとする。さらに、１つまたは複数のリモートＵＥがリレーＵＥを実際にリレーとして選択し、したがってそれらの各々がそのリモートデータ（すなわち、そのリモートＵＥから発信する、またはリモートＵＥに宛てられるデータ）をリレーを介して無線基地局と交換していることを前提とする。１つまたは複数の適切なサイドリンクリモート論理チャネルが、２つのＵＥ間でこのリモートデータを通知するようにリレーＵＥと各リモートＵＥとの間に設定される。さらには、リレーＵＥが、リレーＵＥと無線基地局との間に設定される対応する（リレー）論理チャネルを使用することによってリレーデータ（すなわち、リレーＵＥから発信する、またはリレーＵＥに宛てられるデータ）を交換することによって、無線基地局とアクティブに通信することも前提とする。

【0173】

（第１の実施形態）
以下に、上記の課題を解決するための第１の実施形態を詳細に記載することにする。第１の実施形態の異なる実装を以下に詳細に説明することにする。第１の実施形態によれば、Ｕｕインタフェースに対する、ｅＮｏｄｅＢによって行われ、かつリレーＵＥによって支援される無線リソーススケジューリングが改善される。特に、第１の実施形態は、異なるスケジューリングＲＮＴＩ（スケジューリング識別情報）が、リレーＵＥにリソースをスケジュールするために設定され、一方はリレーデータを交換するための取扱いリソース割当てのため、他方はリモートデータを交換するためのリソース割当てを扱うためであることに基づく。要するに、異なるスケジューリングＲＮＴＩを提供することによって、ｅＮｏｄｅＢによって行われるスケジューリングは、ｅＮｏｄｅＢが割り当てるリソースがリモートデータを交換するためか、またはリレーデータを交換するためかに応じて、リソース割当てが２つのスケジューリングＲＮＴＩの１つにアドレス指定されるように、２つの異なる種類のデータ（すなわちリモートおよびリレーデータ）間を区別することができる。リレーＵＥはこれらの異なるリソース割当てに従い、リレーかまたはリモートかいずれかのデータを送信／受信する。

【0174】

より詳細には、背景で説明したように、異なるモード／種類のスケジューリングが可能であり、対応するＲＮＴＩによって互いから区別され、Ｃ−ＲＮＴＩを用いて動的スケジューリング、ＳＰＳ−Ｃ−ＲＮＴＩを用いて半永続スケジューリング、およびＭＢＭＳ−ＲＮＴＩ（Ｍ−ＲＮＴＩ）を用いてマルチキャスト（ＭＢＭＳ）スケジューリングとなる。したがって、（Ｅ）−ＰＤＣＣＨを通じて送信されるリソース割当て、例えばＤＣＩが対応するＲＮＴＩにアドレス指定され、そうするとＵＥは、リソース割当てをそれ自体に宛てられていると識別することができ、かつＵＥは、リソース割当てが動的スケジューリング、半永続スケジューリングまたはマルチキャストスケジューリングのいずれに関連するかをさらに区別することができる。

【0175】

ｅＮｏｄｅＢは、必要に応じて、特定のＵＥにこれらのＲＮＴＩの各々の１つを設定する。第１の実施形態によれば、追加のＲＮＴＩが、詳細にはリモートデータを扱うように、それぞれの異なる種類のスケジューリングモードのために、ｅＮｏｄｅＢによってリレーＵＥに割り当てられることができる。例えば、動的スケジューリングの場合、リモートＣ−ＲＮＴＩ（Ｒ−Ｃ−ＲＮＴＩ）が、リレーＵＥとｅＮｏｄｅＢとの間でリモートデータを通知する１つまたは複数のリモート論理チャネルをアドレス指定するように、ｅＮｏｄｅＢによってリレーＵＥに割り当てられることができる。対応して、（考察目的で以下「リレーＣ−ＲＮＴＩ」と例示的に名付けられる）先行技術から既に知られているＣ−ＲＮＴＩは、したがってリレーＵＥとｅＮｏｄｅＢとの間でリレーデータを通知する１つまたは複数のリレー論理チャネルをアドレス指定しているにすぎない。

【0176】

同様に、半永続スケジューリングの場合、リモートＳＰＳ−Ｃ−ＲＮＴＩ（Ｒ−ＳＰＳ−Ｃ−ＲＮＴＩ）が、リレーＵＥとｅＮｏｄｅＢとの間でリモートデータを通知する１つまたは複数のリモート論理チャネルをアドレス指定するように、ｅＮｏｄｅＢによってリレーＵＥに割り当てられることができる。対応して、（考察目的で以下「リレーＳＰＳ−Ｃ−ＲＮＴＩ」と例示的に名付けられる）先行技術から既に知られているＳＰＳ−Ｃ−ＲＮＴＩは、したがってリレーＵＥとｅＮｏｄｅＢとの間でリレーデータを通知する１つまたは複数のリレー論理チャネルをアドレス指定しているにすぎない。

【0177】

以上はマルチキャストスケジューリングに同様に当てはまり、ここでリモートＭ−ＲＮＴＩ（Ｒ−Ｍ−ＲＮＴＩ）が、ＭＢＭＳのためのリソース割当てをリモートデータとリレーデータとの間で区別するために、通例のＭ−ＲＮＴＩに加えて、ｅＮｏｄｅＢによってリレーＵＥに割り当てられることができる。

【0178】

（リモートデータ用の）追加のスケジューリングＲＮＴＩは、例えば、現在標準化されているＲＮＴＩ、Ｃ−ＲＮＴＩ、ＳＰＳ−Ｃ−ＲＮＴＩ、Ｍ−ＲＮＴＩなどに関して既になされたのと同様にしてｅＮｏｄｅＢによって設定され、かつ割り当てられる。特に、ｅＮｏｄｅＢとのリレーＵＥの接続確立の間、ｅＮｏｄｅＢは、例えばＣ−ＲＮＴＩを通例の動的スケジューリングのために割り当てるであろうが、リレーＵＥがリレーとして作用する可能性があることをｅＮｏｄｅＢが学習すると、例えばＲ−Ｃ−ＲＮＴＩを付加的に割り当てるであろう。

【0179】

以下の考察は、第１の実施形態の変形および実装の記載を容易にするように動的スケジューリングのみを前提とすることになり、すなわち追加のリモートＣ−ＲＮＴＩがリレーＵＥに対して設定される。しかしながら、本開示は、半永続スケジューリング（追加のＲ−ＳＰＳ−Ｃ−ＲＮＴＩを伴う）の他に、マルチキャストスケジューリング（追加のＲ−Ｍ−ＲＮＴＩを伴う）にも当てはまることに留意すべきである。

【0180】

リモートデータのためのスケジューリングとリレーデータのためのスケジューリングとの間を区別するために２つの異なるＣ−ＲＮＴＩを伴う上記のシステム設定では、ｅＮｏｄｅＢは、詳細にはＣ−ＲＮＴＩかまたはリモートＣ−ＲＮＴＩかいずれかにリソース割当てをアドレス指定することができることになる。これは、リモートまたはリレーデータに対するダウンリンクリソース割当ておよびアップリンクリソースグラントの両方に当てはまる。

【0181】

ダウンリンクに関して、ｅＮｏｄｅＢによって行われるリソーススケジューリングは、リモート論理チャネルおよびリレー論理チャネルに対するｅＮｏｄｅＢのバッファ状況を考慮して、次いでリレーＵＥにリレーデータかまたはリモートデータかいずれかを送信するために（ダウンリンク）無線リソースを割り当てることになる。通常、対応するダウンリンクリソース割当て（例えばＦｏｒｍａｔ１Ａ、Ｂ、Ｃ；ＤのＤＣＩまたは対応するＦｏｒｍａｔ２ＤＬ関連ＤＣＩ）が（Ｅ）−ＰＤＣＣＨを通じてリレーＵＥに送信され、リレーＵＥがｅＮｏｄｅＢからダウンリンクリモートまたはリレーデータを受信するべきである無線リソースを示すことができる。このダウンリンクリソース割当ては、対応して、リレーＣ−ＲＮＴＩにアドレス指定され、それによってダウンリンクリソース割当てがリレー論理チャネル（リレーデータ）に適用可能であることを示すことも、またはリモートＣ−ＲＮＴＩにアドレス指定され、それによってダウンリンクリソース割当てがリモート論理チャネル（リモートデータ）に適用可能であることを示すこともできる。リレーＵＥは、受信することになるデータがリモートかまたはリレーかいずれかのデータであることを、受信されたダウンリンクリソース割当てに含まれる特定のＲＮＴＩから知り、さらに示された無線リソースでダウンリンクリモート／リレーデータを受信することができることになる。付加的に、リモートデータの場合には、リレーＵＥは、後により詳細に説明することになるように、このダウンリンクリモートデータをリモートＵＥに向けてさらに中継することになる。

【0182】

アップリンクに関して、ｅＮｏｄｅＢによって行われるリソーススケジューリングは、後に説明することになるように、リレーＵＥによってバッファ状況報告を使用してｅＮｏｄｅＢに報告される、リモートおよびリレー論理チャネルに対するリレーＵＥにおけるバッファ状況を考慮することになる。ｅＮｏｄｅＢは、したがって、リレーＵＥがｅＮｏｄｅＢにリレーデータかまたはリモートデータかいずれかを送信するためにリレーＵＥに割り当てるアップリンク無線リソースを決定する。通常、対応するアップリンクリソースグラント（例えばＦｏｒｍａｔ０のＤＣＩ）が（Ｅ）−ＰＤＣＣＨを通じてリレーに送信され、リレーＵＥがｅＮｏｄｅＢにリレーまたはリモートデータを送信するために使用してもよい無線リソースを示すことができる。ｅＮｏｄｅＢは、アップリンクリソースグラントがリレー論理チャネル（リレーデータ）またはリモート論理チャネル（リモートデータ）に適用可能であるべきであるかに応じて、アップリンクリソースグラントにリレーＣ−ＲＮＴＩかまたはリモートＣ−ＲＮＴＩかいずれかを含むことになる。リレーＵＥは、それがリレーデータまたはリモートデータを送信するためのアップリンクリソースグラントに示される無線リソースを使用するべきかどうかを、アップリンクリソースグラントに含まれたＲＮＴＩから、対応して学習する。アップリンクデータを生成するために、概して、背景で説明したように、論理チャネル優先順位付け手順が（リレー）ＵＥによって使用される。

【0183】

対応して、ｅＮｏｄｅＢから上述したアップリンクリソースグラントを受信した上で、リレーＵＥは、論理チャネル優先順位付け（ＬＣＰ）手順を同様に行ってアップリンクデータを準備および生成してもよい。第１の実施形態の１つの実装によれば、別々のＬＣＰ手順がリレーＵＥに設けられ、一方のＬＣＰ手順はリレー論理チャネルおよび対応するリレーデータを扱うため、他方のＬＣＰ手順はリモート論理チャネルおよび対応するリモートデータを扱うためである。言い換えると、リレーＬＣＰ手順は（リモート論理チャネルでなく）リレー論理チャネルのみを考慮することになり、反対に、リモートＬＣＰ手順は（リレー論理チャネルでなく）リモート論理チャネルのみを考慮することになる。第１の実施形態の対応する３ＧＰＰ実装では、別々のＬＣＰ手順は、背景および様々な技術的３ＧＰＰ規格に詳細に記載されるように別途機能してもよい。例えば、リレー／リモート論理チャネルは、それらの対応する論理チャネル優先度の降順にリレー／リモートＬＣＰ手順の間、考慮されてもよい。

【0184】

リレーＣ−ＲＮＴＩにアドレス指定されるアップリンクリソースグラントを受信した上で、リレーＵＥはリレーＬＣＰ手順を行い、それによってリレー論理チャネルおよび対応するバッファにおけるリレーデータのみを考慮することになる。リレーＬＣＰ手順は、リレーデータを通知することになるリレー論理チャネル間で示された無線リソースを分配してＭＡＣ ＰＤＵ（トランスポートブロック）を生成することになる。その結果、トランスポートブロックが、リモートデータでなく、リレーデータ（およびおそらくさらなる制御データ、例えばＭＡＣ ＣＥ）から構成されて、リレーＬＣＰ手順によって生成される。反対に、リモートＣ−ＲＮＴＩにアドレス指定されるアップリンクリソースグラントを受信した上で、リレーＵＥはリモートＬＣＰ手順を行い、それによってリモート論理チャネルおよび対応するバッファにおけるリモートデータのみを考慮することになる。リモートＬＣＰ手順は、リモートデータを通知することになるリモート論理チャネル間で示された無線リソースを分配してＭＡＣ ＰＤＵ（トランスポートブロック）を生成することになる。その結果、トランスポートブロックが、リレーデータでなく、リモートデータ（およびおそらくさらなる制御データ、例えばＭＡＣ ＣＥ）から構成されて、リモートＬＣＰ手順によって生成される。

【0185】

このようにして生成された（リレーデータかまたはリモートデータかいずれかを持つ）トランスポートブロックは次いで、リレーＵＥによって、示された無線リソースを使用してｅＮｏｄｅＢに送信されることになる。

【0186】

第１の実施形態の別の実装によれば、リモートデータおよびリレーデータを扱うための別々の論理チャネル優先順位付け手順を設ける代わりに、共通の論理チャネル優先順位付け手順がリレーＵＥに設けられる。上記の場合には、しかしながら、リレーＵＥは、共通のＬＣＰ手順の間、アップリンクリソース割当てが適用可能でない特定のリレー／リモート論理チャネルを選択的に無視しなければならない。特に、共通のＬＣＰ手順は、リレーＵＥに対して設定される論理チャネルのすべて、すなわちリレー論理チャネルおよびリモート論理チャネルの両方を考慮することができるように設定される。しかしながら、リレーＣ−ＲＮＴＩかまたはリモートＣ−ＲＮＴＩかいずれかにアドレス指定されている特定のアップリンクリソースグラントを受信した上で、共通のＬＣＰ手順は、関連した論理チャネルがリモートまたはリレーいずれの論理チャネルであろうと、それのみを考慮する一方で、無関係な論理チャネルがリモートまたはリレーいずれの論理チャネルであろうと、それを無視するものとする。先行の実装と同様に、リレーＵＥは、したがって、リレーデータかまたはリモートデータかいずれか（およびおそらくさらなる制御データ）から構成されるＭＡＣ ＰＤＵ（トランスポートブロック）を生成することになり、次いで生成したトランスポートブロックをｅＮｏｄｅＢに送信することになる。

【0187】

第１の実施形態の１つの特定の実装では、２つの別々のＭＡＣエンティティがリレーＵＥに提供され、すなわち通例の（リレー）データを扱うための通例のＭＡＣエンティティ、およびリモートデータを扱うための追加のＭＡＣエンティティである。図１３は、第１の実施形態のこの実装に係るリレーＵＥにおける２つのＭＡＣエンティティの構造を例示的に示す。明らかなように、図１３の左側の通例のリレーＭＡＣエンティティは、図３を参照しつつ背景で論じたものと基本的に同じであるが、但しＭＢＭＳ受信（ＭＣＣＨおよびＭＴＣＨへのＭＣＨ逆多重化）は簡略化ため図１３では省略される。図１３の右側の追加のリモートＭＡＣエンティティは、通例のリレーＭＡＣエンティティと同じエンティティ、すなわちＬＣＰ手順、ＨＡＲＱエンティティ、制御機能、および（逆）多重化エンティティを基本的に含む。リモートＭＡＣエンティティの構造は単に例であることに留意するべきである。既に前述したように、別々のＬＣＰ手順、リレーＭＡＣエンティティにリレーＬＣＰ手順およびリモートＭＡＣエンティティにリモートＬＣＰ手順を設ける代わりに、（例えばリレーＭＡＣエンティティに設けられる）共通のＬＣＰ手順が使用されることができる。リレーＵＥにおけるリモートＭＡＣエンティティのさらなる変形が図１４に示され、ここでリレーＭＡＣエンティティの（共通の）ＨＡＲＱエンティティはリモートデータ再送信のためにも再使用される。

【0188】

別々のＭＡＣエンティティがリレーＵＥに設けられて異なるリレーおよびリモートデータを扱うので、リレーＣ−ＲＮＴＩはリレーＵＥのリレーＭＡＣエンティティに対応して関連づけられることになる一方で、リモートＣ−ＲＮＴＩはリレーＵＥのリモートＭＡＣエンティティに対応して関連づけられることになる。以下により詳細に説明することになるように、追加のＭＡＣエンティティも、バッファ状況報告を改善するために追加の論理チャネルグループと関連づけられる他に、追加のリモート論理チャネルＩＤ（ＤＲＢ ＩＤ）と関連づけられて、先行技術の予め設定された論理チャネルＩＤの数が十分でないシナリオのためでさえ、リレーＵＥとｅＮｏｄｅＢとの間でリモートデータを通知するための個別論理チャネル／無線ベアラを設定することができることになる。データ無線ベアラのみが、リモートデータを通知するためにリレーＵＥとｅＮｏｄｅＢとの間に設定されてもよいことに留意するべきである。リレーＵＥがＥ−ＵＴＲＡＮ／ｅＮＢとのＲＲＣ接続を１つだけ有するので、リレーＵＥとｅＮｏｄｅＢとの間にリモートシグナリング無線ベアラも確立する必要はない。すべてのＲＲＣ／ＮＡＳシグナリングメッセージは、既に確立されている、すなわちレガシー（リレー）ＭＡＣエンティティと関連づけられているＳＲＢによって搬送されてもよい。したがって、リレーＵＥの観点から、リモートデータは単にデータトラヒックと考えられ、例えばＤＴＣＨ／ＤＲＢがリモートデータのためにリレーＵＥとｅＮｏｄｅＢとの間に確立される。にもかかわらず、ＮＡＳシグナリングのような制御シグナリングまたは上位レイヤ制御メッセージも、リモート論理チャネル／リモートＤＲＢと送信されることができる。

【0189】

さらには、同じＤＬ−ＳＣＨおよびＵＬ−ＳＣＨが両ＭＡＣエンティティによって使用されることになるように、ＭＡＣレイヤ（エンティティ）のトランスポートチャネルは変更されないことになる。例解の容易さのために、図１３は下部で両ＭＡＣエンティティに対してＤＬ−ＳＣＨおよびＵＬ−ＳＣＨを繰り返すが、しかしながら、リレーＭＡＣエンティティに関連して例示されるＤＬ−ＳＣＨおよびＵＬ−ＳＣＨは、リモートＭＡＣエンティティに関連して例示されるＤＬ−ＳＣＨおよびＵＬ−ＳＣＨと同じであるものとする。

【0190】

第１の実施形態のさらなる実装によれば、リレーＵＥによって行われるバッファ状況報告手順も改善されて、ｅＮｏｄｅＢが別々のアップリンクリソース割当てを生成するのを効果的に支援するであろう。以上に説明したように、ｅＮｏｄｅＢは、バッファ状況報告によって提供される情報を使用して、どれくらいの無線リソースが特定の（リレー）ＵＥに割り当てられることになるかを決定することになる。有利には、リレーＵＥは、リレーＵＥバッファにおける無線基地局への送信のために利用可能なリレーデータおよびリモートデータを別々に報告するべきである。対応して、リレーＵＥは、リレーバッファ状況報告を生成して、ｅＮｏｄｅＢへの送信のためにリレーＵＥでバッファされるリレーデータ量を示してもよい。反対に、リレーＵＥは、リモートバッファ状況報告を付加的に生成して、ｅＮｏｄｅＢへの送信のためにリレーＵＥでバッファされるリモートデータ量を示してもよい。

【0191】

３ＧＰＰの既に標準化されているバッファ報告手順ができる限り再使用される例示的な変形では、第１の実施形態のリレーおよびリモートバッファ状況報告は、（論理チャネルが割り当てられる）論理チャネルグループにも基づくものとする。バッファ状況報告内の異なるリレー／リモート論理チャネル間を区別することができるために、リモート論理チャネルに対して追加の論理チャネルグループが規定され、リモート論理チャネルの各々が追加のリモート論理チャネルグループの１つに割り当てられる。グループの１つへのリモート論理チャネルのリモート論理チャネルグループ設定および割当ては、通例の（リレー）論理チャネルおよび（リレー）論理チャネルグループに対応するように行われることができる。特に、リレー／リモート論理チャネルグループは予め規定され（例えば４つのリモートまたはレガシー（リレー）論理チャネルグループ）、かつ対応する優先度と関連づけられ、ｅＮｏｄｅＢは、同様の優先度が１つの論理チャネルグループに分類されるように、リレー／リモート論理チャネルを対応するリレー／リモート論理チャネルグループに割り当てる。

【0192】

要約すると、リレーＵＥとｅＮｏｄｅＢとの間に設定されるリレー／リモート論理チャネル／無線ベアラは、各々対応するリレー／リモート論理チャネルグループに割り当てられることになる。論理チャネルグループ当たりのバッファされたデータを報告する通例の３ＧＰＰバッファ状況報告は、このシナリオにも適用されることができる。その結果、リレーバッファ状況報告は、各リレー論理チャネルグループに対してバッファ状況フィールドを備えることによってすべてのリレー論理チャネルに渡るリレーデータ量を報告するものであり、このバッファ状況フィールドは、上記リレー論理チャネルグループのすべてのリレー論理チャネルに渡って無線基地局への送信のために利用可能なリレーデータ量を示す（背景におけるＢＳＲも参照のこと）。他方で、リモートバッファ状況報告は、各リモート論理チャネルグループに対してバッファ状況フィールドを備えることによって、すべてのリモート論理チャネルに渡るリモートデータ量を報告するものであり、このバッファ状況フィールドは、上記リモート論理チャネルグループのすべてのリモート論理チャネルに渡って無線基地局への送信のために利用可能なリモートデータ量を示す。

【0193】

リモートバッファ状況報告の形式および内容は、通例のリレーバッファ状況報告、例えば背景で説明した長いまたは短いＢＳＲと同じ方式であることができ、長いＢＳＲは４つのＬＣＧ０〜３に対応する４つのバッファサイズフィールドを備え、短いＢＳＲは１つのＬＣＧに対する１つのバッファサイズフィールドを含む。代替的に、リモートバッファ状況報告に対して異なる形式が予期されることができ、例えばリモート論理チャネルが実際にリモートデータを通知するリモート論理チャネルグループに対してのみバッファサイズフィールドを含む（すなわちゼロデータを示すバッファサイズフィールドがない）。

【0194】

その上、２つの別々のＭＡＣエンティティを持つ図１３および１４に係る第１の実施形態の実装では、追加のリモートＭＡＣエンティティは、通例の／レガシー（リレー）ＭＡＣエンティティと同じ方式で４つの論理チャネルグループをサポートすることもできる。１つの実装では、追加のリモートＭＡＣエンティティのための別のＢＳＲ手順がありえ、ｅＮｏｄｅＢに送信されることになる（リモートデータに対する）リモートバッファ状況報告を生成し、リレーＭＡＣエンティティでの対応するＢＳＲ手順は、リレーデータに対するリレーバッファ状況報告を生成することになる。この実装によれば、リモートＢＳＲ手順は、レガシー（リレー）ＢＳＲ手順と比較して、それ自体の別の独立したＢＳＲ関連タイマ／カウンタを有するものである。１つの例示的な実装では、（リモートＢＳＲ ＭＡＣ ＣＥにおける）リモートバッファ状況報告は、リモートＭＡＣ ＰＤＵ／トランスポートブロック、すなわちリモート論理チャネルまたはリモートＣ−ＲＮＴＩに割り当てられるアップリンクリソースでのみ送信されるものである。反対に、レガシー（リレー）バッファ状況報告は、レガシー（リレー）ＭＡＣ ＰＤＵ／トランスポートブロック、すなわちリレー論理チャネルまたはレガシー（リレー）Ｃ−ＲＮＴＩに割り当てられるアップリンクリソースにのみ含まれるものである。

【0195】

２つのＭＡＣエンティティに２つの別々のＢＳＲ手順を独立して設けるときにおいても、ＰＵＣＣＨで送信されてアップリンクリソースを要求する個別スケジュール要求など、リレーＵＥにおけるいくつかのスケジューリング関連機能は、共通して使用されてもよい。より詳細には、両ＢＳＲ手順は共通のＰＵＣＣＨチャネルを使用するものであり、またはバッファ状況報告の送信のためのアップリンクリソースを要求するために、スケジューリング要求手順は、例えばＲＡＣＨ手順でもありえる。

【0196】

いくつかの代替の実装によれば、（例えばリモートＢＳＲ ＭＡＣ ＣＥにおける）リモートバッファ状況報告は、レガシー（リレー）ＭＡＣ ＰＤＵ／トランスポートブロック、すなわちレガシー（リレー）ＲＮＴＩに割り当てられるアップリンクリソースでも送信される。ｅＮＢは、リレーＵＥがデータ送信を意図する対象がリモート論理チャネルかまたはリレー論理チャネルか、あるいはリモートＢＳＲ ＭＡＣ ＣＥかまたはレガシー（リレー）ＢＳＲ ＭＡＣ ＣＥかをＰＵＣＣＨで送信される個別スケジューリング要求に基づいて、またはＲＡＣＨプリアンブルに基づいて区別することができないので、ｅＮＢは、受信したスケジューリング要求に応答して、レガシー（リレー）ＲＮＴＩ、例えばＣ−ＲＮＴＩにアドレス指定されるアップリンクリソース割当てのみを割り当ててもよい。したがって、リモートＢＳＲ ＭＡＣ ＣＥの送信を遅延させないために、リレーＵＥは、レガシー（リレー）ＭＡＣ ＰＤＵ／トランスポートブロックにリモートＢＳＲ ＭＡＣ ＣＥも含む。対応して、レガシー（リレー）ＢＳＲ ＭＡＣ ＣＥもリモートＭＡＣ ＰＤＵ／トランスポートブロック内で送信されてもよい。

【0197】

さらには、２つのバッファ状況報告は、同じまたは別々のＭＡＣ ＣＥで提供されることができる。別々のＭＡＣ ＣＥを使用する場合には、有利には、ＬＣＰ手順を行うときに、リモートＢＳＲを通知するＭＡＣ ＣＥは、それらのリレーＢＳＲを通知するＭＡＣ ＣＥより優先される。

【0198】

さらに別の代替の実装によれば、ｅＮＢのスケジューリングを支援するために、たとえ新たな追加のリモートバッファ状況報告が生成されることになるとしても、リレーＵＥで共通のＢＳＲ手順が使用されることができる。この場合、新たなリモートＢＳＲトリガ条件がレガシー（リレー）バッファ状況報告手順に追加されることになり、リモートバッファ状況報告を生成するためのイベントを規定することになる。この場合、新たな追加のＢＳＲ関連タイマは必要ないであろう。

【0199】

第１の実施形態のさらなる実装は、リモートサイドリンク論理チャネルとリモート論理チャネルとの間のマッピングに関する。特に、リレーＵＥと無線基地局との間に１つまたは複数のリモート論理チャネルが設定されて、アップリンクおよびダウンリンクでリモートデータを通知するものであることを前提とする。しかしながら、第一に、どれくらいのリモート論理チャネルが設定されるべきか、さらにこれらのリモート論理チャネルおよび対応するリモートサイドリンク論理チャネル（すなわちリレーＵＥとリモートＵＥとの間の論理チャネル）のマッピングがどのようであるべきかが不明である。

【0200】

例えば、たった１つのリモート論理チャネルがリレーＵＥとｅＮｏｄｅＢとの間のすべてのリモートデータを通知するものであることがありえる。代替的に、リレーＵＥとリモートＵＥとの間に設定される各リモートサイドリンク論理チャネルに対して、リレーＵＥとｅＮｏｄｅＢとの間の対応するリモート論理チャネルが設定され、さらにこれら２つを１対１方式で連結するように、１対１マッピングが設定されることができる。対応して、リモート論理チャネルによって通知されるリモートデータは対応するリモートサイドリンク論理チャネルに多重化されるものであり、その逆もまた同じである。

【0201】

さらに代替的に、リモート論理チャネルが、既存のリモートデータ通信について満たされることになるＱｏＳ優先度ごとに（ＱＣＩごとに）設定されることができる。特に、リレーＵＥおよびｅＮｏｄｅＢは、リモートデータの送信／中継について満たされる必要があるＱｏＳ要件に基づいて、リモート論理チャネルを設定することになる。

【0202】

いずれの場合も、第１の実施形態の１つの変形が、リモートデータの中継に関連して使用するためのさらなる論理チャネルＩＤ（ＤＲＢ ＩＤ）の定義を含む。８つの異なるＤＲＢ ＩＤが現在３ＧＰＰ規格に規定されている。例えば、追加の８つのＤＲＢ ＩＤが、リモート論理チャネル間を区別するために予期されることがありえる。

【0203】

第１の実施形態の１つの実装によれば、リモート論理チャネルとリモートサイドリンク論理チャネルとの間の特定のＱｏＳ／優先度ベースのマッピングが提供される。より詳細には、アップリンクでは、特定の優先度またはＱｏＳ要件のリモートサイドリンク論理チャネルを上記同じまたは同様の特定の優先度またはＱｏＳ要件の１つの対応するリモート論理チャネルにマッピングするｎ対１マッピング規則が規定されることができる。結果として、同じまたは同様の優先度またはＱｏＳ要件を有する１つまたは複数のリモートＵＥからリレーＵＥで受信されるリモートデータが、同じまたは同様の優先度と関連づけられており、したがって対応するＱｏＳ要件を満たすことができるリモート論理チャネルに多重化されることになる。

【0204】

反対に、ダウンリンクでは、特定の優先度またはＱｏＳ要件の１つの特定のリモート論理チャネルを同じまたは同様の特定の優先度またはＱｏＳ要件を有する対応するリモートサイドリンク論理チャネルに（１つまたは複数のリモートＵＥに）マッピングする１対ｎマッピング規則が規定されることができる。結果として、無線基地局から真のＵＥで受信されるリモートデータが、同じまたは同様の優先度と関連づけられており、したがって対応するＱｏＳ要件を満たすことができる様々なリモートサイドリンク論理チャネルに（１つまたは複数のリモートＵＥに）逆多重化されることになる。

【0205】

これらのマッピング規則を図１５に示し、以上説明したように、リレーＵＥによって行われるｎ対１および１対ｎマッピングを例示する。

【0206】

第１の実施形態のさらなる改善は、複数のトランスポートブロックが１つのサブフレームで送信されなければならないことになることを回避するように、ｅＮｏｄｅＢが、リレーデータまたはリモートデータいずれを送信することになろうと、送信時間間隔（例えばサブフレーム）で１つのスケジューリンググラント（例えばアップリンクリソース割当て）のみを発行するべきであることを予期する。この改善のため、サブフレーム当たりトランスポートブロックが送信されるコンポーネントキャリア（サービングセル）が１つだけ設定されることを前提とする。他方で、キャリアアグリゲーションがＵｕインタフェースで使用される場合、いくつかのトランスポートブロックが送信されることができ、ｅＮｏｄｅＢはいくつかのグラント、例えば１つのリレーリソース割当ておよび１つのリモートリソース割当ても発行してもよいが、但しそれでも、サービングセルでのシングルキャリアプロパティを無効にしないために、１つのサービングセル／コンポーネントキャリアにスケジューリンググラント、すなわちアップリンクリソース割当ては１つのみとする。より詳細には、かつ追加または代替の改善によれば、リレーＵＥがキャリアアグリゲーションモードで動作しているとき、リモートデータおよびリレーデータは異なるキャリア（セル）を介して無線基地局に送信される。

【0207】

（第２の実施形態）
さらには、以下に、上論した課題の１つまたは複数を解決するために、第２の実施形態ならびにその異なる変形および実装を説明することにする。リレーＵＥがｅＮｏｄｅＢと通信しており、かつ１つまたは複数のリモートＵＥに対するリレーとして働いていることなど、第１の実施形態に関して同様の前提が立てられることができる。結果的に、１つまたは複数の適切なサイドリンクリモート論理チャネルがリレーＵＥと各リモートＵＥとの間に設定されて、２つのＵＥ間でリモートデータを通知する。加えて、１つまたは複数のリモート論理チャネルが、リモートデータを通知するためにリレーＵＥとｅＮｏｄｅＢとの間に確立されることができる。さらには、リレーＵＥが、リレーＵＥと無線基地局との間に設定される対応する（リレー）論理チャネルを使用することによってリレーデータ（すなわち、リレーＵＥから発信する、またはリレーＵＥに宛てられるデータ）を交換することによって、無線基地局とアクティブに通信することも前提とする。

【0208】

第１の実施形態と同様に、第２の実施形態は、リレーＵＥによってデータを受信または送信するために使用されることになるＵｕインタフェース上のリソースを割り当てるために、ｅＮｏｄｅＢによって行われ、かつリレーＵＥによって支援されるリソーススケジューリングを改善するものとする。しかしながら、第１の実施形態でのようにリモートデータおよびリレーデータを扱うための別々のスケジューリング識別情報を提供する代わりに、第２の実施形態は現在の標準化で提供されるスケジューリングＲＮＴＩを変更せず、すなわち、したがって例えば動的スケジューリングのためにＣ−ＲＮＴＩ、半永続スケジューリングのためにＳＰＳ−Ｃ−ＲＮＴＩ、およびＭＢＭＳスケジューリングのためにＭ−ＲＮＴＩを使用する。

【0209】

第２の実施形態によれば、リレーＵＥによって行われてｅＮｏｄｅＢでのアップリンクリソース割当て手順を支援するバッファ状況報告手順が改善される。ｅＮｏｄｅＢへの送信のためにリレーＵＥで保留しているリレーデータおよびリモートデータに対して、別々のバッファ状況報告が生成および送信される。加えて、別々の論理チャネルグループが、上述した別々のバッファ状況報告のために規定される。

【0210】

背景で説明したように、３ＧＰＰの既に標準化されているバッファ報告手順は（論理チャネルが割り当てられる）論理チャネルグループに基づき、それによって論理チャネルグループ当たりの保留データをバッファ状況報告で示す。対応して、４つのレガシー／リレー論理チャネルグループが規定され、ｅＮｏｄｅＢは、同様の／同じ優先度／ＱｏＳが１つのリレー論理チャネルグループに分類されるように、レガシー／リレー論理チャネルを４つのリレー論理チャネルグループの１つに割り当てる。加えて、（例えば同じく４つの）さらなるリモート論理チャネルグループがリモート論理チャネルのために導入される／規定されることができ、リモート論理チャネルの各々は、例えばリレー論理チャネルおよびリレー論理チャネルグループに対してなされる対応するように、追加のリモート論理チャネルグループの１つに割り当てられてもよい。特に、リレー／リモート論理チャネルグループは予め規定され（例えば４つのリモートまたはレガシー（リレー）論理チャネルグループ）、ｅＮｏｄｅＢは、同様の優先度（ＱｏＳが１つの論理チャネルグループに分類されるように、リレー／リモート論理チャネルを対応するリレー／リモート論理チャネルグループに割り当てる。

【0211】

次いで、リレーＵＥでバッファ状況報告がトリガされ、バッファ状況報告を生成するとき、リレーバッファ状況報告は、各リレー論理チャネルグループに対してバッファ状況フィールドを備えることによってすべてのリレー論理チャネルに渡るリレーデータ量を報告するものであり、このバッファ状況フィールドは、上記特定のリレー論理チャネルグループのすべてのリレー論理チャネルに渡って無線基地局への送信のために利用可能なリレーデータ量を示す（背景に記載したＢＳＲ報告も参照のこと）。同様に、リモートバッファ状況報告は、各リモート論理チャネルグループに対してバッファ状況フィールドを備えることによって、すべてのリモート論理チャネルに渡るリモートデータ量に関して報告するようにリレーＵＥによって生成されるものであり、このバッファ状況フィールドは、上記特定のリモート論理チャネルグループのすべてのリモート論理チャネルに渡って無線基地局への送信のために利用可能なリモートデータ量を示す。

【0212】

リモートバッファ状況報告の形式および内容は、通例のレガシーリレーバッファ状況報告、例えば背景で詳細に説明した長いまたは短いＢＳＲと対応するようにあることができ、ここで長いＢＳＲは４つのＬＣＧに対応する４つのバッファサイズフィールドを備え、短いＢＳＲは１つのＬＣＧに対する１つのバッファサイズフィールドを含む。代替的に、リモートバッファ状況報告に対して異なる形式が予期されることができ、例えばリモート論理チャネルが実際にリモートデータを通知するリモート論理チャネルグループに対してのみバッファサイズフィールドを含む（すなわちゼロデータを示すバッファサイズフィールドがない）。

【0213】

したがって、リレーＵＥは、バッファ状況報告に従ってリレーデータとリモートデータとの間を区別することができる。

【0214】

さらには、２つのバッファ状況報告は、同じまたは別々のＭＡＣ ＣＥで提供されることができる。別々のＭＡＣ ＣＥを使用する場合には、リモートバッファ状況報告を含む新たなＭＡＣ制御要素が導入される。１つの例示的な実装によれば、ＭＡＣ ＰＤＵを生成するとき、リモートバッファ状況報告を通知する新たなＭＡＣ ＣＥの優先度が規定される必要がある。１つの実装に従って、ＬＣＰ手順を行うとき、リモートＢＳＲを通知するＭＡＣ ＣＥは、リレーＢＳＲを通知するＭＡＣ ＣＥより優先される。別の代替の実装によれば、ＢＳＲがトリガされたとき、リレーＵＥは、例えば両ＭＡＣ ＣＥを含むことによって、常にリモートバッファ状況およびリレーバッファ状況の両方を報告する。２つのバッファ状況報告が１つの共通のＭＡＣ ＣＥで送信される場合について、すべての論理チャネルグループ、すなわちリモート論理チャネルグループおよびリレー論理チャネルグループに対するバッファ状況情報を通知する、何らかの新たなＭＡＣ ＣＥが規定される必要がある。例えば、新たなＢＳＲ ＭＡＣ ＣＥは、８つのＬＣＧに対するバッファ状況情報を通知するものである。

【0215】

１つの実装によれば、リモートおよびリレーベアラ（論理チャネル）に対する共通のＢＳＲ手順がある。対応して、一組のＢＳＲ関連タイマ／カウンタがあるものである。リモートＢＳＲを報告するためのいくつかの新たなトリガイベントが導入されてもよく、レガシーリレー論理チャネル／ベアラに対してと同じ方途で規定されることができる。例えば、リモートＢＳＲが、ＵＬデータの場合に、リモートＬＣＧに帰属するリモート論理チャネルに対してトリガされてもよく、ＲＬＣエンティティでの、またはＰＤＣＰエンティティでの送信のために利用可能になり、そして任意のリモートＬＣＧに帰属し、かつデータが送信のために既に利用可能であるリモート論理チャネルの優先度より高い優先度を持つリモート論理チャネルに、データが帰属するか、またはリモートＬＣＧに帰属するリモート論理チャネルのいずれに対しても送信のために利用可能なデータがない。技術背景に記載したのと同様のトリガイベントがリモートＢＳＲに対して規定されることができる。

【0216】

異なるリレー／リモートバッファ状況報告を生成した上で、リレーＵＥはそれらをｅＮｏｄｅＢに送信することになり、これが次いで２つの報告に提供される情報を使用して、リレーＵＥに割り当てられることになる無線リソースを決定することができる。リレーＵＥのＣ−ＲＮＴＩにアドレス指定される、対応するアップリンクリソースグラント（例えばＦｏｒｍａｔ０のＤＣＩ）がｅＮｏｄｅＢによって準備されて（Ｅ）−ＰＤＣＣＨを通じてリレーＵＥに送信され、リレーＵＥがｅＮｏｄｅＢにリレーおよび／またはリモートデータを送信するために使用してもよい無線リソースを示すことができる。背景で説明したように、概して、アップリンクリソースグラントを受信したときに、論理チャネル優先順位付け手順が（リレー）ＵＥによって使用されてアップリンクデータを生成する。

【0217】

対応して、第２の実施形態の１つの実装によれば、リレーＵＥは、ｅＮｏｄｅＢから上述したアップリンクリソースグラントを受信した上で、そのような論理チャネル優先順位付け（ＬＣＰ）手順を行ってアップリンクデータを準備および生成してもよい。特に、リレーＵＥによって行われるＬＣＰ手順は、示された無線リソースを、ｅＮｏｄｅＢへの送信のために利用可能なデータを有するリモート論理チャネルおよびリレー論理チャネルの両方に分配することになる。この第２の実施形態の対応する３ＧＰＰ実装では、（共通の）ＬＣＰ手順は、背景および様々な技術的３ＧＰＰ規格に詳細に記載されるように別途機能してもよい。例えば、リレーおよびリモート論理チャネルは、それらの対応する論理チャネル優先度の降順に、共通のＬＣＰ手順の間、考慮されてもよい。加えて、リモート論理チャネルがリレー論理チャネルと同じ論理チャネル優先度を有する場合、リレーＵＥはＬＣＰ手順の間、リレー論理チャネルよりリモート論理チャネルを優先してもよく、その逆もまた同じである。対応して、ＬＣＰ手順は無線リソースを、まずリモート論理チャネルに、次いで（無線リソースが依然分配されるのに利用可能であれば）リレー論理チャネルに割り当てるものである。その結果、ＭＡＣ ＰＤＵ（トランスポートブロック）が、おそらくリレーデータおよびリモートデータを（可能なさらなる制御データ、例えばＭＡＣ ＣＥに加えて）備えて、共通のＬＣＰ手順によって生成される。このようにして生成されたトランスポートブロックは次いで、リレーＵＥによって、示されたアップリンクリソースを使用してｅＮｏｄｅＢに送信されることになる。

【0218】

第２の実施形態のいくつかの代替の実装によれば、リモート論理チャネルは、リレー論理チャネルを次いで扱う前に、共通のＬＣＰ手順によって最初に扱われることができる。結果として、いかなるリモートデータも、リレーデータが送信されることができる前に、ＭＡＣ ＰＤＵで送信されることになる。

【0219】

第２の実施形態に対するさらなる相違は、さらなる追加のＭＡＣエンティティが、リモートデータを別々に扱うためにはリレーＵＥに提供されない。図１６から明らかなように、単一のＭＡＣエンティティがリレーＵＥに提供されるが、しかしながら、追加のリモート論理チャネルを扱うために拡張される（図１６で太字、ＤＴＣＨ、データ無線ベアラ）。例えば、たった１つのリモート論理チャネルがリレーＵＥとｅＮｏｄｅＢとの間のすべてのリモートデータを通知するものであることがありえる。代替的に、リレーＵＥとリモートＵＥとの間に設定される各リモートサイドリンク論理チャネルに対して、リレーＵＥとｅＮｏｄｅＢとの間の対応するリモート論理チャネルが設定され、さらにこれら２つを１対１方式で連結するように、１対１マッピングが設定されることができる。対応して、リモート論理チャネルによって通知されるリモートデータは対応するリモートサイドリンク論理チャネルに多重化されるものであり、その逆もまた同じである。

【0220】

さらに代替的に、リモート論理チャネルが、既存のリモートデータ通信について満たされることになるＱｏＳ優先度ごとに（ＱＣＩごとに）設定されることができる。特に、リレーＵＥおよびｅＮｏｄｅＢは、リモートデータの送信／中継について満たされる必要があるＱｏＳ要件に基づいて、リモート論理チャネルを設定することになる。いずれの場合も、第２の実施形態の１つの変形が、リモートデータの中継に関連して使用するためのさらなる論理チャネルＩＤ（ＤＲＢ ＩＤ）の定義を含む。８つの異なるＤＲＢ ＩＤが現在３ＧＰＰ規格に規定されている。例えば、追加で８つの（リモートＤＴＣＨ用の）ＤＲＢ ＩＤが、リモート論理チャネル間を区別するために予期されることがありえる。

【0221】

第１の実施形態に関して同じ方式で、第２の実施形態の１つの実装によれば、リモート論理チャネルとリモートサイドリンク論理チャネルとの間の特定のＱｏＳ／優先度ベースのマッピングが提供される。より詳細には、アップリンクでは、特定の優先度またはＱｏＳ要件のリモートサイドリンク論理チャネルを上記同じまたは同様の特定の優先度またはＱｏＳ要件の１つの対応するリモート論理チャネルにマッピングするｎ対１マッピング規則が規定されることができる。結果として、同じまたは同様の優先度またはＱｏＳ要件を有する１つまたは複数のリモートＵＥからリレーＵＥで受信されるリモートデータが、同じまたは同様の優先度と関連づけられており、したがって対応するＱｏＳ要件を満たすことができるリモート論理チャネルに多重化されることになる。

【0222】

反対に、ダウンリンクでは、特定の優先度またはＱｏＳ要件の１つの特定のリモート論理チャネルを同じまたは同様の特定の優先度またはＱｏＳ要件を有する対応するリモートサイドリンク論理チャネルに（１つまたは複数のリモートＵＥに）マッピングする１対ｎマッピング規則が規定されることができる。結果として、同じまたは同様の優先度と関連づけられている、かつ、このようにして、対応するＱｏＳ要件を満たすことができる様々なリモートサイドリンク論理チャネル（１つまたは複数のリモートＵＥに）に、無線基地局からリレーＵＥにおいて受信されるリモートデータは、逆多重化されるだろう。

【0223】

これらのマッピング規則を図１５に示し、以上説明したように、リレーＵＥによって行われるｎ対１および１対ｎマッピングを例示する。

【0224】

（第３の実施形態）
上論した課題の１つまたは複数を解決するために、以下の第３の実施形態ならびにその異なる変形および実装を説明することにする。リレーＵＥがｅＮｏｄｅＢと通信しており、かつ１つまたは複数のリモートＵＥに対するリレーとして働いていることなど、第１の２つの実施形態に関して同様の前提が立てられることができる。結果的に、１つまたは複数の適切なサイドリンクリモート論理チャネルがリレーＵＥと各リモートＵＥとの間に設定されて、２つのＵＥ間でリモートデータを通知する。加えて、１つまたは複数のリモート論理チャネルが、リモートデータを通知するためにリレーＵＥとｅＮｏｄｅＢとの間に確立されることができる。さらには、リレーＵＥが、リレーＵＥと無線基地局との間に設定される対応する（リレー）論理チャネルを使用することによってリレーデータ（すなわち、リレーＵＥから発信する、またはリレーＵＥに宛てられるデータ）を交換することによって、無線基地局とアクティブに通信することも前提とする。

【0225】

第３の実施形態によれば、すべてのリモートサイドリンク論理チャネル／無線ベアラ、すなわち１つまたは複数のリモートＵＥとリレーＵＥとの間のサイドリンク論理チャネル／無線ベアラは、リレーＵＥとｅＮｏｄｅＢとの間のＵｕインタフェース上の１つのリモート論理チャネルにマッピングされることになる。より詳細には、この場合、すべてのリモートデータは、リレーＵＥとｅＮｏｄｅＢとの間の同じ論理チャネル／無線ベアラを介して送信されることになる。実施形態の１つの実装によれば、この単一のリモート論理チャネルは、予約レガシー論理チャネルグループにマッピングされることになる。より詳細には、規定された４つのＬＣＧの１つが予約され／リモート論理チャネルのために／によってのみ使用されることになる。これは、バッファ状況報告がリモートおよびリレーデータに対して別々であることを保証する。さらには、単一のリモート論理チャネルは、実施形態の１つの実装によれば、リレーＵＥでのすべての設定された論理チャネルの中で最高優先度を与えられる。結果として、ＬＣＰ手順の間にＭＡＣ ＰＤＵを生成するとき、リモートデータは最高優先度で処理されることになる。

【0226】

すべての３つの実施形態に適用可能なさらなる改善は、そのようなリレーシナリオでＰＣ５インタフェースで使用されるリソース割当てモードに関する。特に、そのようなリレーシナリオでは、リモートＵＥはｅＮｏｄｅＢのカバレージ内である／ではないものとする。結果的に、ｅＮｏｄｅＢによってＰｒｏＳｅ直接通信リソースをスケジュールしても意味がない。それよりも、ＵＥ自律リソース割当てモードのみが、リレーＵＥとリモートＵＥとの間のＰｒｏＳｅ通信および発見のために使用されるべきである。

【0227】

ＵＥ自律リソース割当てモードＰｒｏＳｅ通信および／または発見を許容するために、リレーＵＥは、ＵＥ自律リソース割当てモードのために使用される通信プール／発見プール（任意選択で、１型発見のための発見プールも）をリモートＵＥに通知するべきである。このプール情報は、１つの実装によれば、ｅＮＢによってリレーＵＥに提供される。代替的に、リモートＵＥはカバレージ外ＲＥＬ−１２ＰｒｏＳｅ対応ＵＥとして動作すると考えられることがあり、これは結果として、予め設定されたプールがＰｒｏＳｅ通信／発見のために使用されることを意味する。

【0228】

３つの実施形態に適用可能ないくつかのさらなる改善は、リレーＵＥと１つまたは複数のリモートＵＥとの間のＰＣ５インタフェースを通じた、ＲＲＣまたはＮＡＳシグナリング、例えばページングメッセージまたはハンドオーバコマンドの送信に関する。これをサポートするために、ＲＲＣシグナリングもしくはＮＡＳシグナリングのような制御シグナリングまたはいずれか他の上位レイヤ制御シグナリングを通知するサイドリンク論理チャネル／無線ベアラが確立される必要がある。

【0229】

（さらなる実施形態）
第１の変形によれば、移動通信システムにおけるリレーユーザ機器のために無線リソースをスケジュールするための方法が提供される。リレーユーザ機器は、それぞれ１つまたは複数のリモートユーザ機器に対するリレーとして働くことが可能であるためのリレー機能性をサポートし、そうすると１つまたは複数のリモートユーザ機器から発信する、またはリモートユーザ機器に宛てられるリモートデータが、１つまたは複数のリモートユーザ機器と無線基地局との間でリレーユーザ機器によって中継される。リモートスケジューリング識別情報が、リレーユーザ機器と無線基地局との間でリモートデータを通知する１つまたは複数のリモート論理チャネルをアドレス指定するために設定される。リレースケジューリング識別情報が、リレーユーザ機器と無線基地局との間で、リレーユーザ機器から発信する、またはリレーユーザ機器に宛てられるリレーデータを通知する１つまたは複数のリレー論理チャネルをアドレス指定するために設定される。本方法は、リレーユーザ機器によって行われる以下のステップを含む。リレーＵＥは、無線基地局とリモートデータを交換するためにリレーユーザ機器に無線リソースを割り当てるリモートリソース割当てを無線基地局から受信し、ここでリモートリソース割当てはリモートスケジューリング識別情報にアドレス指定される。リレーＵＥは、無線基地局とリレーデータを交換するためにリレーユーザ機器に無線リソースを割り当てるリレーリソース割当てを無線基地局からさらに受信し、ここでリレーリソース割当てはリレースケジューリング識別情報にアドレス指定される。

【0230】

第１の変形に加えて提供される第２の変形によれば、リレーメディアアクセス制御（ＭＡＣ）エンティティおよびリモートＭＡＣエンティティがリレーユーザ機器に構成され、リレーＭＡＣエンティティはリレーデータを扱うためのリレー論理チャネルと関連づけられ、リモートＭＡＣエンティティはリモートデータを扱うためのリモート論理チャネルと関連づけられる。リモートスケジューリング識別情報はリモート論理チャネルと、および／またはリモートＭＡＣエンティティと関連づけられ、リレースケジューリング識別情報はリレー論理チャネルと、および／またはリレーＭＡＣエンティティと関連づけられる。任意選択で、ハイブリッド自動再送要求（ＨＡＲＱ：Hybrid Automatic Repeat Request）エンティティが、リモートデータの送信およびリレーデータの送信に再送信制御を提供するために、リモートＭＡＣエンティティとリレーＭＡＣエンティティとの間で共有され、またはリモートＭＡＣエンティティはリモートＨＡＲＱエンティティを備え、リレーＭＡＣエンティティはリレーＨＡＲＱエンティティを備える。任意選択で、リレー論理チャネルグループがリレーＭＡＣエンティティに対して規定され、リレー論理チャネルの各々はリレー論理チャネルグループの１つに割り当てられ、ここではリモート論理チャネルグループがリモートＭＡＣエンティティに対して規定され、リモート論理チャネルの各々がリモート論理チャネルグループの１つに割り当てられる。任意選択で、リレー論理チャネルＩＤがリレーＭＡＣエンティティに対して規定され、リレー論理チャネルの各々にリレー論理チャネルＩＤの１つが割り当てられ、ここではリモート論理チャネルＩＤがリモートＭＡＣエンティティに対して規定され、リモート論理チャネルの各々にリモート論理チャネルＩＤの１つが割り当てられる。

【0231】

第１のまたは第２の変形に加えて提供される第３の変形によれば、本方法は、リレーユーザ機器によって行われる以下のステップを含む。リモート論理チャネル優先順位付け（ＬＣＰ）手順が、無線基地局への送信のために利用可能なリモートデータを有するリモート論理チャネルに、リモートリソース割当てで割り当てられる無線リソースを割り当てるようにリレーＵＥによって行われる。有利には、リモートデータを通知する１つまたは複数のトランスポートブロックがそれによって生成される。加えて、または代替的に、リレー論理チャネル優先順位付け（ＬＣＰ）手順が、無線基地局への送信のために利用可能なリレーデータを有するリレー論理チャネルに、リレーリソース割当てで割り当てられる無線リソースを割り当てるように行われる。有利には、リレーデータを通知する１つまたは複数のトランスポートブロックがそれによって生成される。

【0232】

第１、第２または第３の変形に加えて提供される第４の変形によれば、本方法は、リレーユーザ機器によって行われる以下のステップを含む。リレーバッファ状況報告は、無線基地局に送信されるためにリレーユーザ機器でバッファされるリレーデータ量に基づいて生成される。リモートバッファ状況報告は、無線基地局に送信されるためにリレーユーザ機器でバッファされるリモートデータ量に基づいてリレーＵＥによって生成される。リレーバッファ状況報告およびリモートバッファ状況報告は両方とも、無線基地局に送信される。

【0233】

第１〜第４の変形のいずれかに加えて提供される第５の変形によれば、少なくとも１つのリモートサイドリンク論理チャネルが、リモートデータをそれぞれ通知するために、リレーユーザ機器と１つまたは複数のリモートユーザ機器のそれぞれ各々との間に確立される。リレーユーザ機器は、第１の論理チャネル優先度の少なくとも１つのリモートサイドリンク論理チャネルの各々を、対応する同じまたは同様の第１の論理チャネル優先度のリモート論理チャネルに多重化する。加えて、または代替的に、リレーＵＥは、第１の論理チャネル優先度のリモート論理チャネルを、対応する同じまたは同様の第１の論理チャネル優先度のリモートサイドリンク論理チャネルに逆多重化する。

【0234】

第１〜第５の変形のいずれかに加えて提供される第６の変形によれば、リモートおよびリレースケジューリング識別情報は、セル無線ネットワーク一時識別子（Ｃ−ＲＮＴＩ）、半永続スケジューリングＣ−ＲＮＴＩ（ＳＰＳ Ｃ−ＲＮＴＩ）、またはＭＢＭＳ ＲＮＴＩ（Ｍ−ＲＮＴＩ）の１つであることができる。

【0235】

第１〜第６の変形のいずれかに加えて提供される第７の変形によれば、リレーユーザ機器は１つのセルを介して無線基地局に接続され、無線基地局は、リモートリソース割当てまたはリレーリソース割当ていずれであろうと、送信時間間隔当たり１つのリソース割当てを発行する。代替的に、リレーユーザ機器は少なくとも２つのセルを介して無線基地局に接続され、ここではリモートデータおよびリレーデータは異なるセルを介して無線基地局に送信される。

【0236】

第８の変形によれば、無線リソースがスケジュールされるためのリレーユーザ機器が提供される。リレーユーザ機器は、それぞれ１つまたは複数のリモートユーザ機器に対するリレーとして働くことが可能であるためのリレー機能性をサポートし、そうすると１つまたは複数のリモートユーザ機器から発信する、またはリモートユーザ機器に宛てられるリモートデータが、１つまたは複数のリモートユーザ機器と無線基地局との間でリレーユーザ機器によって中継される。リモートスケジューリング識別情報が、リレーユーザ機器と無線基地局との間でリモートデータを通知する１つまたは複数のリモート論理チャネルをアドレス指定するために設定される。リレースケジューリング識別情報が、リレーユーザ機器と無線基地局との間で、リレーユーザ機器から発信する、またはリレーユーザ機器に宛てられるリレーデータを通知する１つまたは複数のリレー論理チャネルをアドレス指定するために設定される。リレーＵＥの受信器が、無線基地局とリモートデータを交換するためにリレーユーザ機器に無線リソースを割り当てるリモートリソース割当てを無線基地局から受信し、ここでリモートリソース割当てはリモートスケジューリング識別情報にアドレス指定される。リレーＵＥの受信器は、無線基地局とリレーデータを交換するためにリレーユーザ機器に無線リソースを割り当てるリレーリソース割当てを無線基地局から受信し、ここでリレーリソース割当てはリレースケジューリング識別情報にアドレス指定される。

【0237】

第８の変形に加えて提供される第９の変形によれば、リレーＵＥはリレーメディアアクセス制御（ＭＡＣ）エンティティおよびリモートＭＡＣエンティティを備え、リレーＭＡＣエンティティはリレーデータを扱うためのリレー論理チャネルと関連づけられ、リモートＭＡＣエンティティはリモートデータを扱うためのリモート論理チャネルと関連づけられる。リモートスケジューリング識別情報はリモート論理チャネルと、および／またはリモートＭＡＣエンティティと関連づけられ、リレースケジューリング識別情報はリレー論理チャネルと、および／またはリレーＭＡＣエンティティと関連づけられる。任意選択で、ハイブリッド自動再送要求（ＨＡＲＱ）エンティティが、リモートデータの送信およびリレーデータの送信に再送信制御を提供するために、リモートＭＡＣエンティティとリレーＭＡＣエンティティとの間で共有され、またはリモートＭＡＣエンティティはリモートＨＡＲＱエンティティを備え、リレーＭＡＣエンティティはリレーＨＡＲＱエンティティを備える。任意選択で、リレー論理チャネルグループがリレーＭＡＣエンティティに対して規定され、リレー論理チャネルの各々はリレー論理チャネルグループの１つに割り当てられ、ここではリモート論理チャネルグループがリモートＭＡＣエンティティに対して規定され、リモート論理チャネルの各々がリモート論理チャネルグループの１つに割り当てられる。任意選択で、リレー論理チャネルＩＤがリレーＭＡＣエンティティに対して規定され、リレー論理チャネルの各々にリレー論理チャネルＩＤの１つが割り当てられ、ここではリモート論理チャネルＩＤがリモートＭＡＣエンティティに対して規定され、リモート論理チャネルの各々にリモート論理チャネルＩＤの１つが割り当てられる。

【0238】

第８または第９の変形に加えて提供される第１０の変形によれば、リレーＵＥのプロセッサが、無線基地局への送信のために利用可能なリモートデータを有するリモート論理チャネルに、リモートリソース割当てで割り当てられる無線リソースを割り当てるように、リモート論理チャネル優先順位付け（ＬＣＰ）手順を行い、好ましくはそれによって、リモートデータを通知する１つまたは複数のトランスポートブロックを生成する。加えて、または代替的に、リレーＵＥのプロセッサは、無線基地局への送信のために利用可能なリレーデータを有するリレー論理チャネルに、リレーリソース割当てで割り当てられる無線リソースを割り当てるように、リレー論理チャネル優先順位付け（ＬＣＰ）手順を行い、好ましくはそれによって、リレーデータを通知する１つまたは複数のトランスポートブロックを生成する。

【0239】

第８〜第１０の変形のいずれかに加えて提供される第１１の変形によれば、リレーＵＥのプロセッサが、無線基地局に送信されるためにリレーユーザ機器でバッファされるリレーデータ量に基づいて、リレーバッファ状況報告を生成する。プロセッサは、無線基地局に送信されるためにリレーユーザ機器でバッファされるリモートデータ量に基づいて、リモートバッファ状況報告を生成する。リレーＵＥの送信器が、無線基地局にリレーバッファ状況報告およびリモートバッファ状況報告を送信する。

【0240】

第８〜第１１の変形のいずれかに加えて提供される第１２の変形によれば、少なくとも１つのリモートサイドリンク論理チャネルが、リモートデータをそれぞれ通知するために、リレーユーザ機器と１つまたは複数のリモートユーザ機器のそれぞれ各々との間に確立される。リレーＵＥのマルチプレクサが、第１の論理チャネル優先度の少なくとも１つのリモートサイドリンク論理チャネルの各々を、対応する同じまたは同様の第１の論理チャネル優先度のリモート論理チャネルに多重化する。加えて、または代替的に、リレーＵＥのデマルチプレクサが、第１の論理チャネル優先度のリモート論理チャネルを、対応する同じまたは同様の第１の論理チャネル優先度のリモートサイドリンク論理チャネルに逆多重化する。

【0241】

第１３の変形によれば、移動通信システムにおけるリレーユーザ機器のために無線リソースをスケジュールするための無線基地局が提供される。リレーユーザ機器は、それぞれ１つまたは複数のリモートユーザ機器に対するリレーとして働くことが可能であるためのリレー機能性をサポートし、そうすると１つまたは複数のリモートユーザ機器から発信する、またはリモートユーザ機器に宛てられるリモートデータが、１つまたは複数のリモートユーザ機器と無線基地局との間でリレーユーザ機器によって中継される。リモートスケジューリング識別情報が、リレーユーザ機器と無線基地局との間でリモートデータを通知する１つまたは複数のリモート論理チャネルをアドレス指定するために設定される。リレースケジューリング識別情報が、リレーユーザ機器と無線基地局との間で、リレーユーザ機器から発信する、またはリレーユーザ機器に宛てられるリレーデータを通知する１つまたは複数のリレー論理チャネルをアドレス指定するために設定される。無線基地局のプロセッサが、無線基地局とリモートデータを交換するためにリレーユーザ機器に無線リソースを割り当てるリモートリソース割当てを生成し、ここでリモートリソース割当てはリモートスケジューリング識別情報にアドレス指定される。プロセッサは、無線基地局とリレーデータを交換するためにリレーユーザ機器に無線リソースを割り当てるリレーリソース割当てを生成し、ここでリレーリソース割当てはリレースケジューリング識別情報にアドレス指定される。無線基地局の送信器が、リレーＵＥにリモートリソース割当ておよび／またはリレーリソース割当てを送信する。

【0242】

第１３の変形に加えて提供される第１４の変形によれば、無線基地局の受信器が、無線基地局に送信されるためにリレーユーザ機器でバッファされるリレーデータの量を示す、リレーユーザ機器からのリレーバッファ状況報告を受信する。受信器は、無線基地局に送信されるためにリレーユーザ機器でバッファされるリモートデータの量を示すリレーユーザ機器からのリモートバッファ状況報告をさらに受信する。プロセッサは、リモートリソース割当ておよび／またはリレーリソース割当てを生成するときにリレーバッファ状況報告およびリモートバッファ状況報告を考慮する。

【0243】

第１５の変形によれば、移動通信システムにおけるリレーユーザ機器のために無線リソースをスケジュールするための方法が提供される。リレーユーザ機器は、それぞれ１つまたは複数のリモートユーザ機器に対するリレーとして働くことが可能であるためのリレー機能性をサポートし、そうすると１つまたは複数のリモートユーザ機器から発信する、またはリモートユーザ機器に宛てられるリモートデータが、１つまたは複数のリモートユーザ機器と無線基地局との間でリレーユーザ機器によって中継される。１つまたは複数のリレー論理チャネルが、リレーユーザ機器と無線基地局との間で、リレーユーザ機器から発信する、またはリレーユーザ機器に宛てられるリレーデータを通知するために確立される。１つまたは複数のリモート論理チャネルが、リレーユーザ機器と無線基地局との間で、１つまたは複数のリモートユーザ機器から発信する、またはリモートユーザ機器に宛てられるリモートデータを通知するために確立される。リレー論理チャネルグループが規定され、ここではリレー論理チャネルの各々はリレー論理チャネルグループの１つに割り当てられる。リモート論理チャネルグループが規定され、ここではリモート論理チャネルの各々はリモート論理チャネルグループの１つに割り当てられる。本方法は、リレーユーザ機器によって行われる以下のステップを含む。リレーバッファ状況報告が、リレー論理チャネルグループに対して１つのバッファサイズフィールドを備えて、リレーＵＥによって生成され、１つのバッファサイズフィールドは、上記リレー論理チャネルグループのすべてのリレー論理チャネルに渡って送信のために利用可能な総リレーデータ量を示す。リモートバッファ状況報告が、リモート論理チャネルグループに対して１つのバッファサイズフィールドを備えて、リレーＵＥによって生成され、１つのバッファサイズフィールドは、上記リモート論理チャネルグループのすべてのリモート論理チャネルに渡って送信のために利用可能な総リモートデータ量を示す。リレーバッファ状況報告およびリモートバッファ状況報告は無線基地局に送信される。リレーＵＥは、無線基地局にリモートデータおよびリレーデータを送信するためにリレーユーザ機器に無線リソースを割り当てるアップリンクリソース割当てを無線基地局から受信し、アップリンクリソース割当ては、リレーバッファ状況報告およびリモートバッファ状況報告に基づいて無線基地局によって生成される。

【0244】

第１５の変形に加えて提供される第１６の変形によれば、メディアアクセス制御（ＭＡＣ）エンティティがリレーユーザ機器に構成され、ＭＡＣエンティティはリモートデータおよびリレーデータを扱うためのリレー論理チャネルおよびリモート論理チャネルと関連づけられる。任意選択で、リレー論理チャネルＩＤがＭＡＣエンティティに対して規定され、リレー論理チャネルの各々にリレー論理チャネルＩＤの１つが割り当てられ、ここではリモート論理チャネルＩＤがＭＡＣエンティティに対して規定され、リモート論理チャネルの各々にリモート論理チャネルＩＤの１つが割り当てられる。

【0245】

第１５または第１６の変形に加えて提供される第１７の変形によれば、論理チャネル優先順位付け（ＬＣＰ）手順が、１）無線基地局への送信のために利用可能なリモートデータを有するリモート論理チャネルに、および２）無線基地局への送信のために利用可能なリレーデータを有するリレー論理チャネルに、アップリンクリソース割当てで割り当てられる無線リソースを割り当てるようにリレーＵＥによって行われ、好ましくはそれによって、リモートデータおよびリレーデータを通知する１つまたは複数のトランスポートブロックを生成する。任意選択で、無線リソースが、ＬＣＰ手順の間、送信のために利用可能なデータを持つリレー論理チャネルおよびリモート論理チャネルに、リレー論理チャネルおよびリモート論理チャネルの各々が関連づけられる論理チャネル優先度の降順に割り当てられる。任意選択で、ＬＣＰ手順の間、特定の論理チャネル優先度を有するリモート論理チャネルが、同じ特定の論理チャネル優先度を有するリレー論理チャネルよりリレーＵＥによって優先される。

【0246】

第１５〜第１７の変形のいずれかに加えて提供される第１８の変形によれば、少なくとも１つのリモートサイドリンク論理チャネルが、リモートデータをそれぞれ通知するために、リレーユーザ機器と１つまたは複数のリモートユーザ機器のそれぞれ各々との間に確立される。リレーＵＥは、第１の論理チャネル優先度の少なくとも１つのリモートサイドリンク論理チャネルの各々を、対応する同じまたは同様の第１の論理優先度のリモート論理チャネルに多重化する。加えて、または代替的に、リレーＵＥは、第１の論理チャネル優先度のリモート論理チャネルを、対応する同じまたは同様の第１の論理チャネル優先度のリモートサイドリンク論理チャネルに逆多重化する。

【0247】

第１５〜第１８の変形のいずれかに加える第１９の変形によれば、リモート論理チャネルおよびリレー論理チャネルに、アップリンクリソース割当てで割り当てられる無線リソースを割り当てるように行われる論理チャネル優先順位付け（ＬＣＰ）手順の間、リモートバッファ状況報告を通知する第１のメディアアクセス制御制御要素（ＭＡＣ ＣＥ）が、リレーバッファ状況報告を通知する第２のＭＡＣ ＣＥより優先される。

【0248】

第２０の変形によれば、無線リソースがスケジュールされるためのリレーユーザ機器が提供される。リレーユーザ機器は、それぞれ１つまたは複数のリモートユーザ機器に対するリレーとして働くことが可能であるためのリレー機能性をサポートし、そうすると１つまたは複数のリモートユーザ機器から発信する、またはリモートユーザ機器に宛てられるリモートデータが、１つまたは複数のリモートユーザ機器と無線基地局との間でリレーユーザ機器によって中継される。１つまたは複数のリレー論理チャネルが、リレーユーザ機器と無線基地局との間で、リレーユーザ機器から発信する、またはリレーユーザ機器に宛てられるリレーデータを通知するために確立される。１つまたは複数のリモート論理チャネルが、リレーユーザ機器と無線基地局との間で、１つまたは複数のリモートユーザ機器から発信する、またはリモートユーザ機器に宛てられるリモートデータを通知するために確立される。リレー論理チャネルグループが規定され、ここではリレー論理チャネルの各々はリレー論理チャネルグループの１つに割り当てられる。リモート論理チャネルグループが規定され、ここではリモート論理チャネルの各々はリモート論理チャネルグループの１つに割り当てられる。リレーＵＥのプロセッサが、リレー論理チャネルグループに対して１つのバッファサイズフィールドを備えるリレーバッファ状況報告を生成し、１つのバッファサイズフィールドは、上記リレー論理チャネルグループのすべてのリレー論理チャネルに渡って送信のために利用可能な総リレーデータ量を示す。プロセッサは、リモート論理チャネルグループに対して１つのバッファサイズフィールドを備えるリモートバッファ状況報告をさらに生成し、１つのバッファサイズフィールドは、上記リモート論理チャネルグループのすべてのリモート論理チャネルに渡って送信のために利用可能な総リモートデータ量を示す。リレーＵＥの送信器が、無線基地局にリレーバッファ状況報告およびリモートバッファ状況報告を送信する。リレーＵＥの受信器が、無線基地局にリモートデータおよびリレーデータを送信するためにリレーユーザ機器に無線リソースを割り当てるアップリンクリソース割当てを無線基地局から受信し、アップリンクリソース割当ては、リレーバッファ状況報告およびリモートバッファ状況報告に基づいて無線基地局によって生成される。

【0249】

第２０の変形に加えて提供される第２１の変形によれば、リレーＵＥは、リモートデータおよびリレーデータを扱うためのリレー論理チャネルおよびリモート論理チャネルと関連づけられているメディアアクセス制御（ＭＡＣ）エンティティを備える。任意選択で、リレー論理チャネルＩＤがＭＡＣエンティティに対して規定され、リレー論理チャネルの各々にリレー論理チャネルＩＤの１つが割り当てられ、ここではリモート論理チャネルＩＤがＭＡＣエンティティに対して規定され、リモート論理チャネルの各々にリモート論理チャネルＩＤの１つが割り当てられる。

【0250】

第２０または第２１の変形に加えて提供される第２２の変形によれば、プロセッサが、１）無線基地局への送信のために利用可能なリモートデータを有するリモート論理チャネルに、および２）無線基地局への送信のために利用可能なリレーデータを有するリレー論理チャネルに、アップリンクリソース割当てで割り当てられる無線リソースを割り当てるように、論理チャネル優先順位付け（ＬＣＰ）手順を行い、好ましくはそれによって、リモートデータおよびリレーデータを通知する１つまたは複数のトランスポートブロックを生成する。任意選択で、プロセッサはさらに、ＬＣＰ手順の間、無線リソースを、送信のために利用可能なデータを持つリレー論理チャネルおよびリモート論理チャネルに、リレー論理チャネルおよびリモート論理チャネルの各々が関連づけられる論理チャネル優先度の降順に割り当てる。

【0251】

第２０〜第２２の変形のいずれかに加えて提供される第２３の変形によれば、少なくとも１つのリモートサイドリンク論理チャネルが、リモートデータをそれぞれ通知するために、リレーユーザ機器と１つまたは複数のリモートユーザ機器のそれぞれ各々との間に確立される。リレーＵＥのマルチプレクサは、第１の論理チャネル優先度の少なくとも１つのリモートサイドリンク論理チャネルの各々を、対応する同じまたは同様の第１の論理チャネル優先度のリモート論理チャネルに多重化する。加えて、または代替的に、リレーＵＥのデマルチプレクサが、第１の論理チャネル優先度のリモート論理チャネルを、対応する同じまたは同様の第１の論理チャネル優先度のリモートサイドリンク論理チャネルに逆多重化する。

【0252】

第２０〜第２３の変形のいずれかに加えて提供される第２４の変形によれば、プロセッサは、リモート論理チャネルおよびリレー論理チャネルに、アップリンクリソース割当てで割り当てられる無線リソースを割り当てるように行われる論理チャネル優先順位付け（ＬＣＰ）手順の間、リモートバッファ状況報告を通知する第１のメディアアクセス制御制御要素（ＭＡＣ ＣＥ）を、リレーバッファ状況報告を通知する第２のＭＡＣ ＣＥより優先させる。

【0253】

第２５の変形によれば、移動通信システムにおけるリレーユーザ機器のために無線リソースをスケジュールするための無線基地局が提供される。リレーユーザ機器は、それぞれ１つまたは複数のリモートユーザ機器に対するリレーとして働くことが可能であるためのリレー機能性をサポートし、そうすると１つまたは複数のリモートユーザ機器から発信する、またはリモートユーザ機器に宛てられるリモートデータが、１つまたは複数のリモートユーザ機器と無線基地局との間でリレーユーザ機器によって中継される。１つまたは複数のリレー論理チャネルが、リレーユーザ機器と無線基地局との間で、リレーユーザ機器から発信する、またはリレーユーザ機器に宛てられるリレーデータを通知するために確立される。１つまたは複数のリモート論理チャネルが、リレーユーザ機器と無線基地局との間で、１つまたは複数のリモートユーザ機器から発信する、またはリモートユーザ機器に宛てられるリモートデータを通知するために確立される。リレー論理チャネルグループが規定され、ここではリレー論理チャネルの各々はリレー論理チャネルグループの１つに割り当てられる。リモート論理チャネルグループが規定され、ここではリモート論理チャネルの各々はリモート論理チャネルグループの１つに割り当てられる。無線基地局の受信器が、リレー論理チャネルグループに対して１つのバッファサイズフィールドを備えるリレーバッファ状況報告を受信し、１つのバッファサイズフィールドは、上記リレー論理チャネルグループのすべてのリレー論理チャネルに渡って送信のために利用可能な総リレーデータ量を示す。受信器は、リモート論理チャネルグループに対して１つのバッファサイズフィールドを備えるリモートバッファ状況報告をさらに受信し、１つのバッファサイズフィールドは、上記リモート論理チャネルグループのすべてのリモート論理チャネルに渡って送信のために利用可能な総リモートデータ量を示す。無線基地局のプロセッサが、無線基地局にリモートデータおよびリレーデータを送信するためにリレーユーザ機器に無線リソースを割り当てるアップリンクリソース割当てを生成し、アップリンクリソース割当ては、リレーバッファ状況報告およびリモートバッファ状況報告に基づいてプロセッサによって生成される。無線基地局の送信器が、リレーＵＥに生成されたアップリンクリソース割当てを送信する。

【0254】

＜本開示のハードウェアおよびソフトウェア実装＞
他の例示的な実施形態は、ハードウェア、ソフトウェア、またはハードウェアと協働したソフトウェアを使用する上記した様々な実施形態の実装に関する。これに関連して、ユーザ端末（移動端末）およびｅＮｏｄｅＢ（基地局）が提供される。ユーザ端末および基地局は、受信器、送信器、プロセッサなど、本明細書に記載した方法に適切に関与する対応するエンティティを含め、同方法を行う。

【0255】

様々な実施形態がコンピューティング装置（プロセッサ）を使用して実装されてもまたは行われてもよいとさらに認識される。コンピューティング装置またはプロセッサは、例えば汎用プロセッサ、デジタル信号プロセッサ（ＤＳＰ：Digital Signal Processor）、特定用途向け集積回路（ＡＳＩＣ：Application Specific Integrated Circuit）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ：Field Programmable Gate Array）または他のプログラマブル論理装置などでもよい。様々な実施形態はこれらの装置の組合せによって行われてもまたは具象化されてもよい。特に、上記した各実施形態の記載に使用される各機能ブロックは、集積回路としてのＬＳＩによって実現されることができる。それらはチップとして個々に形成されてもよいし、または１つのチップが、機能ブロックの一部または全部を含むように形成されてもよい。それらは、そこに結合されるデータ入出力を含んでもよい。ＬＳＩはここで、集積度の相違に応じて、ＩＣ、システムＬＳＩ、超ＬＳＩまたは極超ＬＳＩと称されてもよい。しかしながら、集積回路を実装する技術はＬＳＩに限定されず、専用回路または汎用プロセッサを使用することによって実現されてもよい。加えて、ＬＳＩの製造後にプログラムされることができるＦＰＧＡ（Field Programmable Gate Array）、またはＬＳＩ内部に設けられる回路セルの接続および設定が再構成されることができる再構成可能プロセッサが使用されてもよい。

【0256】

さらに、様々な実施形態はソフトウェアモジュールを用いて実装されてもよく、ソフトウェアモジュールはプロセッサによってまたはハードウェアで直接実行される。また、ソフトウェアモジュールおよびハードウェア実装の組合せも可能だろう。ソフトウェアモジュールは任意の種類のコンピュータ可読記憶媒体、例えばＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、レジスタ、ハードディスク、ＣＤ−ＲＯＭ、ＤＶＤなどに記憶されてもよい。異なる実施形態の個々の特徴が個々にまたは任意の組合せで別の実施形態の主題であることにさらに留意するべきである。

【0257】

当業者によって、多数の変形および／または修正が具体的な実施形態に示すように本開示になされてもよいことが認識されるであろう。本実施形態は、したがって、すべての点で例示的であり限定的でないと考えられるべきである。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【国際調査報告】