【文献】
Panasonic,Discussion on resource allocation mechanism in V2X[online],3GPP TSG-RAN WG1#83 R1-156963,2015年11月22日,Internet<URL:http://www.3gpp.org/ftp/tsg_ran/WG1_RL1/TSGR1_83/Docs/R1-156963.zip>
【文献】
Ericsson,Discussion on V2X PC5 Scheduling, Resource Pools and Resource Patterns[online],3GPP TSG-RAN WG1#85 R1-165276,2016年 4月15日,Internet<URL:http://www.3gpp.org/ftp/tsg_ran/WG1_RL1/TSGR1_1382/Docs/R1-165276.zip>
【文献】
Samsung,Semi-persistent transmission support for SL[online],3GPP TSG-RAN WG1#84b R1-162677,2016年 4月15日,Internet<URL:http://www.3gpp.org/ftp/tsg_ran/WG1_RL1/TSGR1_84b/Docs/R1-162677.zip>
【文献】
LG Electronics Inc.,SL SPS enhancement for V2V[online],3GPP TSG-RAN WG2#93bis R2-162927,2016年 4月15日,Internet<URL:http://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_93bis/Docs/R2-162927.zip>
【文献】
Panasonic,Radio resource selection behaviour for sensing and semi-persistent transmissions[online],3GPP TSG-RAN WG2#95 R2-164849,2016年 8月26日,Internet<URL:http://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_95/Docs/R2-164849.zip>
【文献】
Panasonic,Radio resource selection behaviour for autonomous resource allocation mode[online],3GPP TSG-RAN WG2#95bis R2-166643,2016年10月14日,Internet<URL:http://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_95bis/Docs/R2-166643.zip>
(58)【調査した分野】(Int.Cl.,DB名)
周期的データをサイドリンクインタフェースを介して1つまたは複数の受信装置に送信する送信装置であって、前記送信装置は、周期的データおよび非周期的データを前記サイドリンクインタフェースを介して送信するための無線リソースを自律的に選択し、前記送信装置は、
第1の周期的データを第1のスケジューリング情報とともに前記1つまたは複数の受信装置に送信し、前記第1のスケジューリング情報が、前記第1の周期的データを送信するために使用される無線リソースを示し、第2の周期的データを送信するために前記送信装置によって、前記第1の周期的データを送信した後の時点において使用可能な予約された無線リソースをさらに示す、送信機と、
前記第2の周期的データを前記第1の周期的データを送信した後の時点まで遅延させるプロセッサと、
を備え、
前記送信機は、前記第1の周期的データを送信した後の時点において前記第2の周期的データを前記第1のスケジューリング情報によって示された前記予約された無線リソースを使用して送信し、
前記送信機は、前記第1の周期的データおよび前記第2の周期的データ以外の他のデータを、送信可能な状態になったときに遅延なしに送信する、
送信装置。
前記プロセッサは、データが前記第1の周期的データと同じ論理チャネルに属しているかを判定することによって、送信可能な状態になる前記データが、前記無線リソースが予約されている前記第2の周期的データであるか否かを判定し、
前記データが前記第1の周期的データと同じ論理チャネルに属している場合、前記プロセッサは、前記無線リソースが予約されているか否かを判定し、結果が肯定的である場合、前記無線リソースが予約されている前記第1の周期的データを送信した後の時点まで前記第2の周期的データを遅延させることを決定し、
前記データが前記第1の周期的データと同じ論理チャネルに属していない場合、前記プロセッサは、前記データを、送信可能な状態になったときに遅延なしに送信することを決定し、前記データの前記送信に使用される他の無線リソースを自律的に選択する、
請求項1に記載の送信装置。
前記プロセッサは、データが特定の論理チャネルに属しているかに基づいて、送信可能な状態になる前記データが前記第1の周期的データであるか否かを判定し、結果が肯定的である場合、前記第1の周期的データを送信した後の時点のための無線リソースを予約することを決定し、
前記特定の論理チャネルは、前記送信装置における上位レイヤによって提供される、前記第1の周期的データの優先順位の指示および/または周期の指示に基づいて設定され、
前記周期的データの前記周期は、前記送信装置における前記上位レイヤによって、前記優先順位の指示とともに、または個別に指示される、
請求項1または2に記載の送信装置。
前記周期的データは、更新された車両状態情報を提供するために周期的にトリガーされる協調認識メッセージ(CAM:Cooperative Awareness Messages)を含み、
前記非周期的データは、車両に関連する安全性イベントによってトリガーされる分散型環境通知メッセージ(DENM:Decentralized Environmental Notification Messages)を含む、
請求項1から11のいずれか1項に記載の送信装置。
前記送信機は、前記第2の周期的データを送信するために使用される前記予約された無線リソースを示す第2のスケジューリング情報を、前記第2の周期的データとともに送信する、
請求項1から12のいずれか1項に記載の送信装置。
周期的データをサイドリンクインタフェースを介して送信装置から1つまたは複数の受信装置に送信する方法であって、前記送信装置は、周期的データおよび非周期的データを前記サイドリンクインタフェースを介して送信するための無線リソースを自律的に選択し、前記方法は、前記送信装置によって実行される以下のステップ、すなわち、
第1の周期的データを第1のスケジューリング情報とともに前記1つまたは複数の受信装置に送信し、前記第1のスケジューリング情報が、前記第1の周期的データを送信するために使用される無線リソースを示し、第2の周期的データを送信するために前記送信装置によって、第1の周期的データを送信した後の時点において使用可能な予約された無線リソースをさらに示す、ステップと、
前記第2の周期的データを前記第1の周期的データを送信した後の時点まで遅延させるステップと、
前記第1の周期的データを送信した後の時点において前記第2の周期的データを前記第1のスケジューリング情報によって示された前記予約された無線リソースを使用して送信するステップと、
前記第1の周期的データおよび前記第2の周期的データ以外の他のデータを、送信可能な状態になったときに遅延なしに送信するステップと、
を含む方法。
【背景技術】
【0002】
[Long Term Evolution(LTE)]
WCDMA(登録商標)無線アクセス技術をベースとする第3世代の移動通信システム(3G)は、世界中で広範な規模で配備されつつある。この技術を機能強化または発展・進化させるうえでの最初のステップとして、高速ダウンリンクパケットアクセス(HSDPA:High-Speed Downlink Packet Access)、および、エンハンストアップリンク(高速アップリンクパケットアクセス(HSUPA:High-Speed Uplink Packet Access)とも称する)とが導入され、これにより、極めて競争力の高い無線アクセス技術が提供されている。
【0003】
ユーザからのますます増大する需要に対応し、新しい無線アクセス技術(new radio access technologies)に対する競争力を確保する目的で、3GPPは、Long Term Evolution(LTE)と称される新しい移動通信システムを導入した。LTEは、今後10年間にわたり、データおよびメディアの高速伝送ならびに大容量の音声サポートに要求されるキャリアを提供するように設計されている。高いビットレートを提供する能力は、LTEにおける重要な方策である。
【0004】
E−UTRA(Evolved UMTS Terrestrial Radio Access(UTRA))およびUTRAN(UMTS Terrestrial Radio Access Network)と称される、LTEに関する作業項目(WI:work item)の仕様は、最終的にリリース8(LTEリリース8)として公開される。LTEシステムは、パケットベースの効率的な無線アクセスおよび無線アクセスネットワークであり、IPベースの全機能を低遅延かつ低コストで提供する。LTEでは、与えられたスペクトルを用いてフレキシブルなシステム配備を達成するために、スケーラブルな複数の送信帯域幅(例えば、1.4MHz、3.0MHz、5.0MHz、10.0MHz、15.0MHz、および20.0MHz)が指定されている。ダウンリンクには、OFDM(Orthogonal Frequency Division Multiplexing:直交周波数分割多重)をベースとする無線アクセスが採用されている。なぜなら、かかる無線アクセスは、低いシンボルレートのため本質的にマルチパス干渉(MPI:multipath interference)を受けにくく、また、サイクリックプレフィックス(CP:Cyclic Prefix)を使用しており、さらに、様々な送信帯域幅の構成に対応可能だからである。アップリンクには、SC−FDMA(Single-Carrier Frequency Division Multiple Access)をベースとする無線アクセスが採用されている。なぜなら、ユーザ機器(UE:User Equipment)の送信出力が限られていることを考えれば、ピークデータレートを向上させるよりも広いカバレッジエリアを提供することが優先されるからである。LTEリリース8/9では、数多くの主要なパケット無線アクセス技術(例えば、MIMO(Multiple Input Multiple Output)チャネル伝送技術)が採用され、高効率の制御シグナリング構造が達成されている。
【0005】
[LTEのアーキテクチャ]
図1は、LTEの全体的なアーキテクチャを示す。E−UTRANはeNodeBから構成され、eNodeBは、ユーザ機器(UE)に向けのE−UTRAのユーザプレーン(PDCP/RLC/MAC/PHY)プロトコルおよび制御プレーン(RRC:Radio Resource Control)プロトコルを終端させる。eNodeB(eNB)は、物理(PHY)レイヤ、媒体アクセス制御(MAC:Medium Access Control)レイヤ、無線リンク制御(RLC:Radio Link Control)レイヤ、およびパケットデータ制御プロトコル(PDCP:Packet Data Control Protocol)レイヤ(これらのレイヤはユーザプレーンのヘッダ圧縮および暗号化の機能を含む)をホストする。eNBは、制御プレーンに対応する無線リソース制御(RRC)機能も提供する。eNBは、無線リソース管理、アドミッション制御、スケジューリング、交渉によるアップリンクサービス品質(QoS:Quality of Service)の実施、セル情報のブロードキャスト、ユーザプレーンデータおよび制御プレーンデータの暗号化/復号、ダウンリンク/アップリンクのユーザプレーンパケットヘッダの圧縮/復元など、多くの機能を実行する。複数のeNodeBは、X2インタフェースによって互いに接続されている。
【0006】
また、複数のeNodeBは、S1インタフェースによってEPC(Evolved Packet Core)、より具体的には、S1−MMEによってMME(Mobility Management Entity:移動管理エンティティ)、S1−Uによってサービングゲートウェイ(SGW:Serving Gateway)に接続されている。S1インタフェースは、MME/サービングゲートウェイとeNodeBとの間の多対多関係をサポートする。SGWは、ユーザデータパケットをルーティングして転送する一方で、eNodeB間のハンドオーバー時におけるユーザプレーンのモビリティアンカーとして機能する。さらに、SGWは、LTEと別の3GPP技術との間のモビリティのためのアンカー(S4インタフェースを終端させ、2G/3GシステムとPDN GWとの間でトラフィックを中継する)として機能する。SGWは、アイドル状態のユーザ機器に対しては、ダウンリンクデータ経路を終端させ、そのユーザ機器へのダウンリンクデータが到着したときにページングをトリガーする。SGWは、ユーザ機器のコンテキスト(例えばIPベアラサービスのパラメータ、またはネットワーク内部ルーティング情報)を管理および格納する。さらに、SGWは、合法傍受(lawful interception)の場合にユーザトラフィックの複製を実行する。
【0007】
MMEは、LTEのアクセスネットワークの主要な制御ノードである。MMEは、アイドルモードのユーザ機器の追跡およびページング手順(再送信を含む)の役割を担う。MMEは、ベアラのアクティブ化/非アクティブ化プロセスに関与する。さらには、MMEは、最初のアタッチ時と、コアネットワーク(CN:Core Network)ノードの再配置を伴うLTE内ハンドオーバー時とに、ユーザ機器のSGWを選択する役割も担う。MMEは、(HSSと対話することによって)ユーザを認証する役割を担う。非アクセス層(NAS:Non-Access Stratum)シグナリングはMMEにおいて終端される。MMEは、一時的なIDを生成してユーザ機器に割り当てる役割も担う。MMEは、サービスプロバイダのPLMN(Public Land Mobile Network)に入るためのユーザ機器の認証をチェックし、ユーザ機器のローミング制約を実施する。MMEは、NASシグナリングの暗号化/完全性保護においてネットワーク内の終端点であり、セキュリティキーの管理を行う。シグナリングの合法傍受も、MMEによってサポートされる。さらに、MMEは、LTEのアクセスネットワークと2G/3Gのアクセスネットワークとの間のモビリティのための制御プレーン機能を提供し、SGSNからのS3インタフェースを終端させる。さらに、MMEは、ローミングするユーザ機器のためのホームHSSに向かうS6aインタフェースを終端させる。
【0008】
[LTEにおけるコンポーネントキャリア構造]
3GPP LTEシステムのダウンリンクコンポーネントキャリアは、いわゆるサブフレームにおける時間−周波数領域でさらに分割される。3GPP LTEにおいて、各サブフレームは、
図2に示すように2つのダウンリンクスロットに分割される。第1のダウンリンクスロットは、第1のOFDMシンボル内の制御チャネル領域(PDCCH領域)を備える。各サブフレームは、時間領域内の所与の数のOFDMシンボルで構成され(3GPP LTE(リリース8)では12個または14個のOFDMシンボル)、各OFDMシンボルはコンポーネントキャリアの帯域幅全体に広がる。したがって、OFDMシンボルの各々は、各サブキャリアで送信されるいくつかの変調シンボルで構成される。LTEでは、各スロットにおける送信信号は、N
DLRB×N
RBsc本のサブキャリアとN
DLsymb個のOFDMシンボルのリソースグリッドによって記述される。N
DLRBは、帯域幅の中のリソースブロックの数である。N
DLRBは、セルにおいて設定されているダウンリンク送信帯域幅に依存し、N
min,DLRB≦N
DLRB≦N
max,DLRBを満たす。この場合、N
min,DLRB=6およびN
max,DLRB=110は、それぞれ、現在のバージョンの仕様によってサポートされている最小ダウンリンク帯域幅および最大ダウンリンク帯域幅である。N
RBscは、1個のリソースブロックの中のサブキャリアの数である。通常のサイクリックプレフィックスのサブフレーム構造の場合、N
RBsc=12、N
DLsymb=7である。
【0009】
例えば、3GPP LTEにおいて使用されるような、例えばOFDMを使用するマルチキャリア通信システムを想定すると、スケジューラによって割り当てることができるリソースの最小単位は、1つの「リソースブロック」である。物理リソースブロック(PRB:Physical Resource Block)は、
図2に例示したように、時間領域における連続するOFDMシンボル(例えば7個のOFDMシンボル)および周波数領域における連続するサブキャリア(例えば、コンポーネントキャリアの12本のサブキャリア)として定義される。したがって、3GPP LTE(リリース8)では、物理リソースブロックはリソースエレメントから構成され、時間領域における1つのスロットおよび周波数領域における180kHzに対応する(ダウンリンクリソースグリッドに関するさらなる詳細は、例えば非特許文献1の6.2節(3GPPのウェブサイトで入手可能であり、参照により本明細書に組み込まれている)を参照)。
【0010】
1つのサブフレームは、2つのスロットで構成される。いわゆる「通常の(normal)」CP(Cyclic Prefix)が使用されるときにはサブフレーム内に14個のOFDMシンボルが存在し、いわゆる「拡張(extended)」CPが使用されるときにはサブフレーム内に12個のOFDMシンボルが存在する。専門用語を目的として、以下で、サブフレーム全体に広がる同じ連続するサブキャリアと同等の時間−周波数リソースは、「リソースブロックペア(resource block pair)」または同意義の「RBペア(RB pair)」もしくは「PRBペア(PRB pair)」と呼ばれる。
【0011】
「コンポーネントキャリア(Component Carrier)」という用語は、周波数領域におけるいくつかのリソースブロックの組み合わせを示す。LTEの将来のリリースでは、「コンポーネントキャリア」という用語はもはや使用されず、その代わりに、その専門用語はダウンリンクリソースおよびオプションでアップリンクリソースの組み合わせを示す「セル」に変更される。ダウンリンクリソースのキャリア周波数とアップリンクリソースのキャリア周波数との間のリンク付けは、ダウンリンクリソースで送信されるシステム情報において指示される。
【0012】
コンポーネントキャリアの構造に関する同様の想定は、以降のリリースにも適用される。
【0013】
[より広い帯域幅のサポートのためのLTE−Aにおけるキャリアアグリゲーション]
World Radio communication Conference 2007(WRC−07)において、IMT−Advancedの周波数スペクトルが決定された。IMT−Advancedのための全体的な周波数スペクトルは決定されたが、実際に利用可能な周波数帯域幅は、地域または国によって異なる。しかしながら、利用可能な周波数スペクトルのアウトラインの決定に続いて、3GPP(3rd Generation Partnership Project)において無線インタフェースの標準化が開始された。3GPP TSG RAN #39 meetingにおいて、「Further Advancements for E-UTRA (LTE-Advanced)」に関する検討項目(study item)の記述が承認された。この検討項目は、E−UTRAを進化・発展させるうえで(例えば、IMT−Advancedの要求条件を満たすために)考慮すべき技術要素をカバーしている。
【0014】
LTEシステムが20MHzのみをサポートできるのに対して、LTE-Advancedシステムがサポートできる帯域幅は100MHzである。今日、無線スペクトルの欠如がワイヤレスネットワークの開発のボトルネックになり、結果として、LTE-Advancedシステムのために十分広いスペクトル帯域を見つけることは困難である。したがって、より広い無線スペクトル帯域を獲得するための方法を見つけることは急務であり、ここにおいて、可能性のある答えは、キャリアアグリゲーション機能である。
【0015】
キャリアアグリゲーションでは、最大で100MHzのより広い送信帯域幅をサポートする目的で、2つ以上のコンポーネントキャリアがアグリゲートされる。LTE−Advancedシステムでは、LTEシステムにおけるいくつかのセルが、より広い1つのチャネルにアグリゲートされる。このチャネルは、たとえLTEにおけるこれらのセルが異なる周波数帯域にある場合でも100MHzに対して十分に広い。
【0016】
少なくとも、コンポーネントキャリアの帯域幅が、LTEリリース8/9のセルのサポートされる帯域幅を超えないときには、全てのコンポーネントキャリアをLTEリリース8/9互換であるように設定できる。ユーザ機器によってアグリゲートされる全てのコンポーネントキャリアが必ずしもLTEリリース8/9互換でなくてよい。リリース8/9のユーザ機器がコンポーネントキャリアにキャンプオンすることを回避するため、既存のメカニズム(例:バーリング:barring)を使用できる。
【0017】
ユーザ機器は、ユーザ機器の能力に応じて1つまたは複数のコンポーネントキャリア(複数のサービングセルに対応する)を同時に受信または送信できる。キャリアアグリゲーションのための受信能力および/または送信能力を備えた、LTE−Aリリース10のユーザ機器は、複数のサービングセル上で同時に受信および/または送信できる。これに対して、LTEリリース8/9のユーザ機器は、コンポーネントキャリアの構造がリリース8/9の仕様に従う場合、1つのサービングセル上で受信および送信を行うことができる。
【0018】
キャリアアグリゲーションは、連続するコンポーネントキャリアおよび不連続なコンポーネントキャリアの両方においてサポートされ、各コンポーネントキャリアは、(3GPP LTE(リリース8/9)のnumerologyを使用して)周波数領域における最大110個のリソースブロックに制限される。
【0019】
同じeNodeB(基地局)から送信される、場合によってはアップリンクおよびダウンリンクにおいて異なる帯域幅の異なる数のコンポーネントキャリアをアグリゲートするように、3GPP LTE−A(リリース10)互換のユーザ機器を構成することが可能である。設定することのできるダウンリンクコンポーネントキャリアの数は、ユーザ機器のダウンリンクのアグリゲーション能力に依存する。一方、設定することのできるアップリンクコンポーネントキャリアの数は、ユーザ機器のアップリンクのアグリゲーション能力に依存する。現時点では、ダウンリンクコンポーネントキャリアよりもアップリンクコンポーネントキャリアが多い状態に移動端末を設定することはできない。一般的なTDD配備では、コンポーネントキャリアの数および各コンポーネントキャリアの帯域幅は、アップリンクとダウンリンクとで同じである。同じeNodeBから送信されるコンポーネントキャリアは、同じカバレッジを提供する必要はない。
【0020】
連続的にアグリゲートされるコンポーネントキャリアの中心周波数の間隔は、300kHzの整数倍である。これは、3GPP LTE(リリース8/9)の100kHzの周波数ラスターとの互換性を保つと同時に、15kHz間隔のサブキャリアの直交性を維持するためである。アグリゲーションのシナリオによっては、連続するコンポーネントキャリアの間に少数の使用されないサブキャリアを挿入することによって、n×300kHzの間隔あけを容易にすることができる。
【0021】
複数のキャリアをアグリゲートする影響は、MACレイヤに及ぶのみである。MACレイヤには、アップリンクおよびダウンリンクの両方において、アグリゲートされるコンポーネントキャリアごとに1つのHARQエンティティが要求される。コンポーネントキャリアあたりのトランスポートブロックは最大1個である(アップリンクにおけるSU−MIMOを使用しない場合)。トランスポートブロックおよびそのHARQ再送信(発生時)は、同じコンポーネントキャリアにマッピングする必要がある。
【0022】
キャリアアグリゲーションが設定されているとき、移動端末はネットワークとの1つのRRC接続のみを有する。RRC接続の確立/再確立時、1つのセルが、LTEリリース8/9と同様に、セキュリティ入力(1つのECGI、1つのPCI、および1つのARFCN)と、非アクセス層(NAS:non-access stratum)モビリティ情報(例:TAI)とを提供する。RRC接続の確立/再確立の後、そのセルに対応するコンポーネントキャリアは、ダウンリンクプライマリセル(PCell:Primary Cell)と称される。接続状態では、ユーザ機器あたり常に1つのダウンリンクPCell(DL PCell)および1つのアップリンクPCell(UL PCell)が設定される。コンポーネントキャリアの設定されたセットおいて、他のセルはセカンダリセル(SCell:Secondary Cell)と呼ばれ、SCellのキャリアはダウンリンクセカンダリコンポーネントキャリア(DL SCC)およびアップリンクセカンダリコンポーネントキャリア(UL SCC)である。1つのUEに対して最大5つのサービングセル(PCellを含む)を設定できる。
【0023】
[MACレイヤ/MACエンティティ、RRCレイヤ、物理レイヤ]
LTEのLayer 2のユーザプレーン/制御プレーンのプロトコルスタックは、4つのサブレイヤ、すなわちRRC、PDCP、RLCおよびMACを備えている。媒体アクセス制御(MAC)レイヤは、LTEの無線プロトコルスタックのLayer 2アーキテクチャにおける最も下のサブレイヤであり、例えば3GPP技術規格である非特許文献2によって定義されている。下の物理レイヤとはトランスポートチャネルを通じて接続されており、上のRLCレイヤとは論理チャネルを通じて接続されている。MACレイヤは、論理チャネルとトランスポートチャネルとの間の多重化および逆多重化を実行する。送信側におけるMACレイヤは、論理チャネルを通じて受け取るMAC SDUからMAC PDU(トランスポートブロックとしても知られている)を構築する。受信側におけるMACレイヤは、トランスポートチャネルを通じて受け取るMAC PDUからMAC SDUを復元する。
【0024】
MACレイヤは、論理チャネルを通じてRLCレイヤにデータ伝送サービスを提供し(参照により本明細書に組み込まれている非特許文献2の5.4節および5.3節を参照)、この論理チャネルは、制御データ(例えばRRCシグナリング)を伝える制御論理チャネル、またはユーザプレーンデータを伝えるトラフィック論理チャネルのいずれかである。その一方で、MACレイヤからのデータはトランスポートチャネル(ダウンリンクまたはアップリンクとして分類される)を通じて物理レイヤと交換される。無線を通じた送信方式に応じて、データがトランスポートチャネルに多重化される。
【0025】
物理レイヤは、データおよび制御情報をエアインタフェースを介して実際に送信する役割を担う。すなわち、物理レイヤは、送信側ではMACトランスポートチャネルからの全ての情報をエアインタフェースを通じて伝える。物理レイヤによって実行されるいくつかの重要な機能としては、符号化および変調、リンクアダプテーション(AMC)、電力制御、セルサーチ(最初の同期およびハンドオーバーを目的とする)、RRCレイヤのための他の測定(LTEシステムの内側およびシステム間)が挙げられる。物理レイヤは、送信パラメータ(変調方式、符号化率(すなわち変調・符号化方式(MCS:Modulation and Coding Scheme))、物理リソースブロックの数など)に基づいて、送信を実行する。物理レイヤの機能に関するさらなる情報は、非特許文献3(参照により本明細書に組み込まれている)に記載されている。
【0026】
無線リソース制御(RRC)レイヤは、無線インタフェースにおけるUEとeNBとの間の通信と、いくつかのセルを横切って移動するUEのモビリティを制御する。RRCプロトコルは、NAS情報の伝送もサポートする。RRC_IDLEのUEに対しては、RRCはネットワークからの着信呼の通知をサポートする。RRC接続制御は、RRC接続の確立、変更および解除に関連する全ての手順(ページング、測定の設定および報告、無線リソースの設定、最初のセキュリティ起動、シグナリング無線ベアラ(SRB:Signalling Radio Bearer)およびユーザデータを伝える無線ベアラ(データ無線ベアラ(DRB:Data Radio Bearer))の確立を含む)をカバーする。
【0027】
無線リンク制御(RLC:Radio Link Control)サブレイヤは、主としてARQ(自動再送要求)機能を備えており、また、データの分割および連結をサポートしている。すなわち、RLCレイヤは、RLC SDUのフレーミングを実行し、MACレイヤによって示されるサイズにする。後者の2つによって、データレートとは無関係にプロトコルオーバーヘッドが最小になる。RLCレイヤは、論理チャネルを介してMACレイヤに接続されている。各論理チャネルは、様々なタイプのトラフィックを伝える。RLCレイヤの上のレイヤは、一般にはPDCPレイヤであるが、場合によってはRRCレイヤである。すなわち、論理チャネルBCCH(Broadcast Control Channel)、PCCH(Paging Control Channel)、およびCCCH(Common Control Channel)で送信されるRRCメッセージは、セキュリティ保護を必要とせず、したがってPDCPレイヤをバイパスしてRLCレイヤに直接渡される。
【0028】
[LTEにおけるアップリンクアクセス方式]
アップリンク送信では、カバレッジを最大にするため、ユーザ端末は高い電力効率で送信する必要がある。E−UTRAのアップリンク送信方式としては、シングルキャリア伝送と、動的な帯域幅割当てのFDMAとを組み合わせた方式が選択されている。シングルキャリア伝送が選択された主たる理由は、マルチキャリア信号(OFDMA)と比較して、ピーク対平均電力比(PAPR:peak to average power ratio)が低く、これに対応して電力増幅器の効率が改善され、カバレッジも改善されるためである(与えられる端末ピーク電力に対してデータレートがより高い)。各時間間隔において、eNodeBは、ユーザデータを送信するための固有の時間/周波数リソースをユーザに割り当てる。これによってセル内の直交性が確保される。アップリンクにおける直交多元接続によって、セル内干渉が排除されることでスペクトル効率が高まる。マルチパス伝搬に起因する干渉については、送信信号にサイクリックプレフィックスを挿入することにより基地局(eNodeB)において対処する。
【0029】
データを送信するために使用される基本的な物理リソースは、1つの時間間隔(例えばサブフレーム)にわたるサイズBW
grantの周波数リソースから構成される(符号化された情報ビットはこのリソースにマッピングされる)。なお、サブフレーム(送信時間間隔(TTI:Transmission Time Interval)とも称する)は、ユーザデータを送信するための最小の時間間隔である。しかしながら、サブフレームを連結することにより、1TTIより長い時間にわたる周波数リソースBW
grantをユーザに割り当てることも可能である。
【0030】
[Layer 1/Layer 2制御シグナリング]
スケジューリング対象のユーザに、ユーザの割当て状態、トランスポートフォーマット、およびその他の送信関連情報(例:HARQ情報、送信電力制御(TPC:Transmit Power Control)コマンド)を通知する目的で、L1/L2制御シグナリングがデータと共にダウンリンクで送信される。L1/L2制御シグナリングは、サブフレーム内でダウンリンクデータと共に多重化される(ユーザ割当てがサブフレーム単位で変化しうるものと想定する)。なお、ユーザ割当てをTTI(送信時間間隔)ベースで実行することもできる。その場合、TTI長をサブフレームの整数倍とすることができることに留意されたい。TTI長は、サービスエリア内で全てのユーザに対して一定とする、または異なるユーザに対して異なる長さとする、さらにはユーザ毎に動的とすることもできる。L1/L2制御シグナリングは、一般的にはTTIあたり1回送信すればよい。以下では、一般性を失うことなく、TTIが1サブフレームに等しいものと想定する。
【0031】
L1/L2制御シグナリングは、物理ダウンリンク制御チャネル(PDCCH:Physical Downlink Control Channel)で送信される。PDCCHは、ダウンリンク制御情報(DCI:Downlink Control Information)としてのメッセージを伝える。DCIには、ほとんどの場合、移動端末またはUEのグループへのリソース割当ておよびその他の制御情報が含まれる。いくつかのPDCCHを1つのサブフレーム内で送信できる。
【0032】
アップリンク無線リソースまたはダウンリンク無線リソースを割り当てる目的でL1/L2制御シグナリングで送られる情報は(特にLTE(−A)リリース10)、一般的には以下の項目に分類できる。
− ユーザ識別情報(User Identity): 割り当てる対象のユーザを示す。この情報は、一般には、CRCをユーザの識別情報によってマスクすることによってチェックサムに含まれる。
− リソース割当て情報(Resource allocation information): ユーザに割り当てられるリソース(例:リソースブロック(RB:Resource Block))を示す。あるいはこの情報はリソースブロック割当て(RBA:resource block assignment)と称される。なお、ユーザに割り当てられるリソースブロック(RB)の数は動的とすることができる。
− キャリアインジケータ(Carrier indicator): 第1のキャリアで送信される制御チャネルが、第2のキャリアに関連するリソース(すなわち第2のキャリアのリソースまたは第2のキャリアに関連するリソース)を割り当てる場合に使用される(クロスキャリアスケジューリング)。
− 変調・符号化方式(Modulation and Coding Scheme): 採用される変調方式および符号化率を決める。
− HARQ情報: データパケットまたはその一部の再送信時に特に有用である、新規データインジケータ(NDI:New Data Indicator)または冗長バージョン(RV:Redundancy Version)など。
− 電力制御コマンド: 割当て対象のアップリンクのデータまたは制御情報の送信時の送信電力を調整する。
− 参照信号情報: 割当ての対象の参照信号の送信または受信に使用される、適用されるサイクリックシフトまたは 直交カバーコード(OCC:Orthogonal Cover Code)インデックスなど。
− アップリンク割当てインデックスまたはダウンリンク割当てインデックス: 割当て(assignment)の順序を識別するために使用され、TDDシステムにおいて特に有用である。
− ホッピング情報: 例えば、周波数ダイバーシチを増大させる目的でリソースホッピングを適用するかどうか、および適用方法の指示情報。
− CSI要求: 割り当てられるリソースにおいてチャネル状態情報(Channel State Information)を送信するようにトリガーするために使用される。
− マルチクラスタ情報: シングルクラスタ(RBの連続的なセット)またはマルチクラスタ(連続的なリソースブロックの少なくとも2つの不連続なセット)で送信を行うかを指示して制御するために使用されるフラグである。マルチクラスタ割当ては、3GPP LTE−(A)リリース10によって導入された。
【0033】
なお、上記リストは、全てを網羅したものではなく、また、使用されるDCIフォーマットによっては、リストした情報項目全てを各PDCCH送信に含める必要はないことに留意されたい。
【0034】
ダウンリンク制御情報はいくつかのフォーマットの形をとる。これらのフォーマットは、全体のサイズと、上述したフィールドに含まれる情報とが異なる。LTEにおいて現在定義されている様々なDCIフォーマットは以下のとおりであり、非特許文献4の5.3.3.1節(3GPPのウェブサイトで入手可能であり、参照により本明細書に組み込まれている)に詳しく記載されている。3GPP技術規格である非特許文献4の5.4.3節(参照により本明細書に組み込まれている)には、サイドリンクインタフェースのための制御情報が定義されている。
【0035】
[セミパーシステントスケジューリング(SPS)]
スケジューリングを行うeNodeBは、ダウンリンクおよびアップリンクにおいて、各送信時間間隔においてリソースを(1つまたは複数の)L1/L2制御チャネル(PDCCH)を介してユーザ機器に動的に割り当てる。この場合、ユーザ機器はそれぞれの固有のC−RNTIによってアドレッシングされる。前述したように、PDCCHのCRCは、アドレッシングされるユーザ機器のC−RNTIによってマスクされる(いわゆる動的PDCCH)。一致するC−RNTIを有するユーザ機器のみが、PDCCHの内容を正しく復号することができ、すなわちCRCチェックに合格する。この種類のPDCCHシグナリングは、ダイナミックグラント(dynamic grant)又はダイナミックスケジューリンググラント(scheduling dynamic grant)とも称する。ユーザ機器は、自身に割り振られているかもしれない割当て(ダウンリンクおよびアップリンク)を見つける目的で、ダイナミックグラントが存在していないか、各送信時間間隔において(1つまたは複数の)L1/L2制御チャネルをモニタ(monitor)する。
【0036】
これに加えて、E−UTRANでは、1回目のHARQ送信のためのアップリンク/ダウンリンクリソースをパーシステントに(持続的に)割り当てることができる。再送信が必要な場合、再送信は、(1つまたは複数の)L1/L2制御チャネルを介して明示的にシグナリングされる。再送信が動的にスケジューリングされるため、この種類の動作をセミパーシステントスケジューリング(SPS)と称する。すなわち、リソースはセミパーシステントベースで(半持続的に)ユーザ機器に割り当てられる(セミパーシステントなリソース割当て)。その恩恵は、1回目のHARQ送信のためのPDCCHリソースが節約されることである。セミパーシステントスケジューリングは、リリース10ではPCellにおいて使用できるが、SCellでは使用できない。
【0037】
セミパーシステントスケジューリングを使用してスケジューリングすることのできるサービスの一例は、ボイスオーバーIP(VoIP)である。トーク・スパート(talk-spurt)の間、コーデックにおいて20msごとにVoIPパケットが生成される。したがってeNodeBは、アップリンクリソースまたはダウンリンクリソースを20msごとにパーシステントに割り当てることができ、これらのリソースを使用してボイスオーバーIPのパケットを送信できる。一般的に、セミパーシステントスケジューリングは、トラフィック挙動が予測可能であるサービス(すなわちビットレートが一定であり、パケットが周期的に到着する)において恩恵がある。
【0038】
ユーザ機器は、1回目の送信のためのリソースがパーシステントに(持続的に)割り当てられているサブフレームにおいて、PDCCHをモニタする。ダイナミック(スケジューリング)グラント(すなわちC−RNTIによってマスクされたCRCを有するPDCCH)は、セミパーシステントなリソース割当てよりも優先させることができる。ユーザ機器が、セミパーシステントにリソースが割り当てられたサブフレームにおいて(1つまたは複数の)L1/L2制御チャネル上にユーザ機器自身のC−RNTIを見つけた場合、その送信時間間隔においては、そのL1/L2制御チャネル割当てがパーシステントなリソース割当てよりも優先され、ユーザ機器は、そのダイナミックグラントに従う。ダイナミックグラントが見つからないときには、ユーザ機器はセミパーシステントなリソース割当てに従って送信/受信を行う。
【0039】
セミパーシステントスケジューリングの設定は、RRCシグナリングによって行われる。例えば、パーシステント割当ての周期(例:PS_PERIOD)は、無線リソース制御(RRC)シグナリングの中で伝えられる。パーシステント割当ての有効化(activation)および正確なタイミングと、物理リソースおよびトランスポートフォーマットのパラメータは、PDCCHシグナリングを介して送られる。セミパーシステントスケジューリングが有効になると、ユーザ機器は、PS_PERIODごとに、SPS有効化PDCCH(SPS activation PDCCH)によるセミパーシステントなリソース割当てに従う。原則的には、ユーザ機器は、SPS有効化PDCCHの内容を格納し、シグナリングされた周期においてPDCCHに従う。
【0040】
動的なPDCCHと、セミパーシステントスケジューリングを有効にするPDCCH(SPS有効化PDCCH(SPS activation PDCCH)とも称する)とを区別する目的で、個別の識別情報が導入される。基本的には、SPS有効化PDCCHのCRCを、この追加の識別情報(以下ではSPS C−RNTIと称する)によってマスクする。SPS C−RNTIのサイズも、通常のC−RNTIと同じ16ビットである。さらにSPS C−RNTIは、ユーザ機器に固有である。すなわちセミパーシステントスケジューリングについて設定される各ユーザ機器に、一意のSPS C−RNTIが割り当てられる。
【0041】
ユーザ機器は、セミパーシステントリソース割当てが有効にされることを、対応するSPS有効化PDCCHによって検出した場合、PDCCHの内容(すなわちセミパーシステントリソース割当て)を格納し、セミパーシステントスケジューリング間隔(すなわちRRCを介してシグナリングされる周期)ごとに、その内容を適用する。前述したように、動的な割当て(すなわち動的なPDCCHでシグナリングされる割当て)は、「1回だけの割当て」であるにすぎない。SPS割当ての再送信も、SPS C−RNTIを使用してシグナリングされる。SPS有効化とSPS再送信を区別する目的で、NDI(New Data Indicator。新規データインジケータ)が使用される。SPS有効化は、NDIビットを0に設定することによって示される。NDIビットが1に設定されたSPS PDCCHは、セミパーシステントにスケジューリングされた1回目の送信の再送信を示す。
【0042】
eNodeBは、セミパーシステントスケジューリングを有効にするのと同様に、セミパーシステントスケジューリングを無効(deactivate)にすることもできる(SPSリソースリリース(SPS resource release)とも称する)。セミパーシステントスケジューリングの割当てリリースをシグナリングする方法には、いくつかのオプションが存在する。1つのオプションは、何らかのPDCCHフィールドが何らかの事前定義された値に設定されたPDCCHシグナリングを使用する(すなわちSPS PDCCHがサイズ0のリソース割当てを示す)ことである。もう1つのオプションは、MAC制御シグナリングを使用することである。
【0043】
以下では、UEによって周期的データが送信されるか、及び、SPS設定を確立することのできるタイミングを、eNBがどのように認識するかについてさらに説明する。
【0044】
非特許文献5における専用のベアラ有効化手順によれば、新規のベアラが確立されるときには、MMEが、ベアラ確立要求(Bearer Setup Request)(EPSベアラID(EPS Bearer Identity)、EPSベアラQoS(EPS Bearer QoS)、セッション管理要求(Session Management Request)、S1−TEID)メッセージをeNodeBにシグナリングする。eNodeBは、EPSベアラQoSを無線ベアラQoS(Radio Bearer QoS)にマッピングする。次いでeNodeBは、RRC接続再設定(RRC Connection Reconfiguration)(無線ベアラQoS、セッション管理要求、EPS RB ID(EPS RB Identity))メッセージをUEにシグナリングする。
【0045】
EPSベアラQoSプロファイルは、パラメータQCI、ARP(割当ておよび保持優先順位)、GBR(保証ビットレート)、およびMBR(最大ビットレート)を含む。各EPSベアラ(GBRおよび非GBR)は、以下のベアラレベルのQoSパラメータに関連付けられる。
− QoSクラス識別子(QCI:QoS Class Identifier)
− 割当ておよび保持優先順位(ARP:Allocation and Retention Priority)
【0046】
QCIは、ベアラレベルのパケット転送処理を制御する、アクセスノードに固有なパラメータ(例:スケジューリングの重み、アドミッションしきい値、キュー管理しきい値、リンクレイヤプロトコル設定など)への参照として使用されるスカラーである。QCIは、アクセスノード(例:eNodeB)を所有する事業者によって事前に設定されている。非特許文献6には、下の表(非特許文献6の中の表に基づいている)に示したように、標準化されているQCI値と標準化されている特性の1対1のマッピングが記載されている。
【表1】
【0047】
この表から明らかであるように、QCI値1は、「音声通話」(すなわちボイスオーバーIP(VoIP))に対応する。eNBは、QCI値1の「ベアラ確立要求」メッセージを受信したときには、そのベアラがVoIP用に確立されることを認識し、UEがVoIPデータを送信するための周期的リソースを割り当てるため、SPS設定を適用できる。
【0048】
[論理チャネル優先順位付け(LCP:Logical Channel Prioritization)手順]
アップリンクの場合、割り当てられた無線リソースを使用して送信されるMAC PDUをUEが作成するプロセスは、完全に標準化されている。LCP(論理チャネル優先順位付け)手順は、UEの異なる実装の間でも最適かつ一貫した方式で、設定されている各無線ベアラのQoSをUEが満たすように設計されている。UEは、新しいMAC PDUに含める、各論理チャネルのデータ量を、PDCCHでシグナリングされるアップリンク送信リソースグラントメッセージに基づいて決定しなければならず、必要な場合、さらにMAC制御エレメント(MAC Control Element)のためのスペースを割り当てなければならない。
【0049】
複数の論理チャネルからのデータによってMAC PDUを構築するとき、最も簡単かつ最も直感的な方法は、絶対的な優先順位に基づく方法である。この方法では、MAC PDUのスペースを、論理チャネルの優先順位の降順に論理チャネルに割り当てる。すなわち、最も高い優先順位の論理チャネルからのデータをMAC PDUにおいて最初に処理し、続いて、次に高い優先順位の論理チャネルからのデータを処理し、これをMAC PDUのスペースが全て占有されるまで続ける。絶対的な優先順位に基づく方法は、UEの実装の観点において極めて簡単であるが、場合によっては低い優先順位の論理チャネルからのデータのリソース不足につながることがある。リソース不足とは、高い優先順位の論理チャネルからのデータがMAC PDUのスペース全てを占有するため、低い優先順位の論理チャネルからのデータを送信できないことを意味する。
【0050】
LTEでは、重要度の順にデータが送信される。ただし、低い優先順位のデータのリソース不足も回避する目的で、各論理チャネルに優先ビットレート(PBR:Prioritized Bit Rate)が定義される。PBRは、論理チャネルに対して保証される最小データレートである。たとえ論理チャネルの優先順位が低い場合でも、PBRを保証するため少なくとも少量のMAC PDUスペースが割り当てられる。したがってリソース不足の問題は、PBRを使用することによって回避できる。
【0051】
論理チャネル優先順位付け(Logical Channel Prioritization)は、例えば非特許文献2の5.4.3.1節(参照により本明細書に組み込まれている)に標準化されている。論理チャネル優先順位付け(LCP)手順は、新しい送信が実行されるときに適用される。
【0052】
[LTEの装置間(D2D:Device to Device)近接サービス(ProSe:Proximity Services)]
近接性に基づくアプリケーションおよびサービスは、ソーシャル技術の新しいトレンドである。識別される分野としては、事業者およびユーザにとって関心のある商用サービスおよび公共安全に関連するサービスが挙げられる。LTEに近接サービス(ProSe)機能を導入することにより、3GPP業界は、この成長市場にサービスを提供できると同時に、連係してLTEを使用するいくつかの公共安全機関の緊急なニーズに応えることができる。
【0053】
D2D通信は、LTEリリース12によって導入された技術要素である。この技術によって、セルラーネットワークに対するアンダーレイ(下層)としてのD2Dにおいてスペクトル効率を高めることができる。例えば、セルラーネットワークがLTEである場合、データを伝える全ての物理チャネルは、D2DシグナリングにおいてSC−FDMAを使用する。D2D通信では、ユーザ機器は、無線基地局を経由せずに、セルラーリソースを使用する直接的なリンクを通じて互いにデータ信号を送信する。本発明全体を通じて、用語「D2D」、「ProSe」、および「サイドリンク」は同義である。
【0054】
LTEにおけるD2D通信は、ディスカバリおよび通信という2つの分野に焦点をあてている。
【0055】
ProSe(近接サービス)直接ディスカバリ(ProSe Direct Discovery)は、ProSe対応ユーザ機器が、近傍の別の(1つまたは複数の)ProSe対応ユーザ機器を、PC5インタフェースを介してE−UTRA直接無線信号を使用して発見するために使用される手順と定義されている。
【0056】
D2D通信では、UEは、基地局(BS:Base Station)を経由せずに、セルラーリソースを使用して直接的なリンクを通じて互いにデータ信号を送信する。D2Dユーザは、直接通信するが、基地局の制御下のままである(少なくともeNBのカバレッジ内にあるとき)。したがって、D2Dでは、セルラーリソースを再利用することによってシステム性能を改善できる。
【0057】
D2Dは、アップリンクLTE周波数帯(FDDの場合)、または、カバレッジを提供しているセルのアップリンクサブフレーム(TDDの場合、ただしカバレッジ外のときを除く)において動作することを想定する。さらに、D2D送信/受信では、与えられたキャリアにおいて全二重を使用しない。個々のユーザ機器の観点からは、与えられたキャリアにおいて、D2D信号受信およびLTEアップリンク送信が全二重を使用しない(すなわちD2D信号受信およびLTEアップリンク送信を同時に行うことはできない)。
【0058】
D2D通信では、特定の1つのUE1が送信の役割であるとき(送信ユーザ機器または送信端末)、UE1がデータを送信し、別のUE2(受信ユーザ機器)がそれを受信する。UE1およびUE2は、送信の役割と受信の役割を交換できる。UE1からの送信は、1つまたは複数のUE(UE2など)によって受信できる。
【0059】
[ProSe直接通信のレイヤ2リンク]
簡潔に言えば、2つのUEの間でPC5を通じてセキュアなレイヤ2リンクを確立することによって、1対1のProSe直接通信が実現される。各UEは、ユニキャスト通信用のレイヤ2 IDを有する。このレイヤ2 IDは、UEがレイヤ2リンクで送信する各フレームのSource Layer-2 ID(送信元レイヤ2 ID)フィールドと、UEがレイヤ2リンクで受信する各フレームのDestination Layer-2 ID(宛先レイヤ2 ID)に含まれる。UEは、ユニキャスト通信用のレイヤ2 IDが少なくともローカル範囲内で一意であることを確保する必要がある。したがって、UEは、隣接するUEとのレイヤ2 IDの衝突を、規定されていないメカニズム(例えば、衝突が検出されたときユニキャスト通信用の新しいレイヤ2 IDをUE自身で割り当てる)を使用して処理するように構成されているべきである。1対1のProSe直接通信のためのレイヤ2リンクは、2つのUEのレイヤ2 IDの組み合わせによって識別される。すなわち、UEは、同じレイヤ2 IDを使用して、1対1のProSe直接通信のための複数のレイヤ2リンクに関与できる。
【0060】
1対1のProSe直接通信は、非特許文献7の7.1.2節(参照により本明細書に組み込まれている)に詳しく説明されているように、次の手順から構成される。
・ PC5を通じてセキュアなレイヤ2リンクを確立する
・ IPアドレス/プレフィックスを割り当てる
・ PC5を通じてレイヤ2リンクを維持・管理する
・ PC5を通じてレイヤ2リンクをリリースする
【0061】
図3は、PC5インタフェースを通じてセキュアなレイヤ2リンクを確立する方法を示す。
1. 相互認証をトリガーする目的で、UE−1が直接通信要求(Direct Communication Request)メッセージをUE−2に送信する。ステップ1を実行するためには、リンク開始側(UE−1)が相手側(UE−2)のレイヤ2 IDを知っている必要がある。一例として、リンク開始側は、最初にディスカバリ手順を実行することによって、または相手側を含む1対多のProSe通信に参加することによって、相手側のレイヤ2 IDを認識できる。
2. UE−2が相互認証の手順を開始する。認証手順が正常に終了すると、PC5を通じてのセキュアなレイヤ2リンクの確立が完了する。
【0062】
単独の(中継されない)1対1通信に関与するUEは、リンクローカルアドレスを使用することもできる。PC5シグナリングプロトコルは、UEがProSe通信範囲内ではないときに検出するために使用されるキープアライブ機能をサポートする。したがって、このようなUEは、レイヤ2リンクの暗黙的なリリースに進むことができる。PC5を通じてのレイヤ2リンクのリリースは、他方のUEに送信される接続解除要求(Disconnect Request)メッセージを使用することによって実行できる。他方のUEは、関連する全てのコンテキストデータも削除する。他方のUEは、接続解除要求メッセージを受信した時点で、接続解除応答(Disconnect Response)メッセージによって応答し、レイヤ2リンクに関連付けられる全てのコンテキストデータを削除する。
【0063】
[ProSe直接通信に関連する識別情報]
非特許文献8の8.3節には、ProSe直接通信に使用するための次の識別情報が定義されている。
・ SL−RNTI(サイドリンク無線ネットワーク一時識別子): ProSe直接通信のスケジューリングに使用される一意の識別情報
・ 送信元レイヤ2 ID(Source Layer 2 ID): サイドリンクProSe直接通信におけるデータの送信者を識別する。送信元レイヤ2 IDは24ビット長であり、受信機におけるRLC UMエンティティおよびPDCPエンティティを識別するため、ProSeレイヤ2宛先IDおよびLCIDと共に使用される。
・ 宛先レイヤ2 ID(Destination Layer 2 ID): サイドリンクProSe直接通信におけるデータの対象者を識別する。宛先レイヤ2 IDは24ビット長であり、MACレイヤにおいて2つのビット列に分割される。
【0064】
・ 一方のビット列は、宛先レイヤ2 IDの最下位部分(8ビット)であり、サイドリンク制御レイヤ1 IDとして物理レイヤに転送される。これは、サイドリンク制御における意図するデータの対象者を識別し、物理レイヤにおいてパケットをフィルタリングするために使用される。
【0065】
・ 2番目のビット列は、宛先レイヤ2 IDの最上位部分(16ビット)であり、MACヘッダ内で伝えられる。これは、MACレイヤにおいてパケットをフィルタリングするために使用される。
【0066】
UEにおいてグループを形成するためと、送信元レイヤ2 ID、宛先レイヤ2 ID、およびサイドリンク制御レイヤ1 IDを設定するために、非アクセス層シグナリングが必要である。これらの識別情報は、上位レイヤによって提供される、または上位レイヤによって提供される識別情報から導かれる。グループキャストおよびブロードキャストの場合、上位レイヤによって提供されるProSe UE IDが送信元レイヤ2 IDとして直接使用され、上位レイヤによって提供されるProSeレイヤ2グループIDが、MACレイヤにおいて宛先レイヤ2 IDとして直接使用される。1対1の通信の場合、上位レイヤが送信元レイヤ2 IDおよび宛先レイヤ2 IDを提供する。
【0067】
[近接サービスにおける無線リソース割当て]
送信側UEの観点からは、近接サービスに対応するUE(Proximity-Service-enabled UE。ProSe対応UE)は、リソース割当ての以下の2つのモードで動作できる。
【0068】
モード1は、eNBによってスケジューリングされるリソース割当てモードを意味する。この場合、UEが、eNB(またはリリース10の中継ノード)からの送信リソースを要求する。eNodeB(またはリリース10の中継ノード)は、UEが「直接」データおよび「直接」制御情報(例えばスケジューリング割当て(SA:Scheduling Assignment))を送信するために使用するリソースをスケジューリングする。UEは、データを送信するためにはRRC_CONNECTEDである必要がある。具体的には、UEは、スケジューリング要求(D−SRまたはランダムアクセス)をeNBに送信し、続いてサイドリンクバッファ状態報告(BSR:Buffer Status Report)を通常の方法で送信する(次節「D2D通信における送信手順」も参照)。eNBは、BSRに基づいて、UEがProSe直接通信によって送信するデータを有すると判断し、送信に必要なリソースを推定できる。
【0069】
これに対して、モード2は、UEによる自律的なリソース選択モードを意味する。この場合、UEは、「直接」データおよび「直接」制御情報(すなわちSA(スケジューリング割当て))を送信するためのリソース(時間および周波数)を、(1つまたは複数の)リソースプールからUE自身で選択する。少なくとも1つのリソースプールが、例えばSIB18の内容によって(すなわちcommTxPoolNormalCommonフィールドによって)定義される。これらの特定のリソースプールは、セル内でブロードキャストされ、そのセル内の依然としてRRC_IDLE状態にある全てのUEに共通して利用可能である。実際には、eNBは、このプールの最大4つの異なるインスタンス(すなわちSAメッセージおよび「直接」データを送信するための4つのリソースプール)を定義できる。しかしながら、リリース12では、UEは、たとえUE自身に複数のリソースプールが設定された場合でも、リスト内に定義されている最初のリソースプールを常に使用する。この制約はリリース13では削除され、UEは1つのSC期間内に、設定されているリソースプールのうちの複数のリソースプールで送信できる。以下では、UEが送信用のリソースプールを選択する方法についてさらに説明する(非特許文献2にさらに規定されている)。
【0070】
これに代えて、eNBが別のリソースプールを定義してSIB18で(すなわちcommTxPoolExceptionalフィールドを使用することによって)シグナリングし、UEは例外的なケースにおいてこのリソースプールを使用できる。
【0071】
UEがどのリソース割当てモードを使用するかは、eNBによって設定可能である。さらに、UEがD2Dデータ通信用にどのリソース割当てモードを使用するかを、RRC状態(すなわちRRC_IDLEまたはRRC_CONNECTED)と、UEのカバレッジ状態(すなわちカバレッジ内またはカバレッジ外)とによっても決定できる。UEがサービングセルを有する(すなわちUEがRRC_CONNECTEDである、またはRRC_IDLEにおいて特定のセルにキャンプオンしている)場合、そのUEはカバレッジ内にあるとみなされる。
【0072】
図4は、オーバーレイ(LTE)システムおよびアンダーレイ(D2D)システムにおける送信/受信リソースの使用を示す。
【0073】
UEがモード1の送信を適用するかモード2の送信を適用するかを、基本的にはeNodeBが制御する。UEは、D2D通信を送信(または受信)できるリソースを認識すると、対応するリソースを、対応する送信/受信にのみ使用する。例えば、
図4において、D2Dサブフレームは、D2D信号を受信または送信する目的にのみ使用される。D2D装置としてのUEは、半二重モードで動作するため、任意の時点においてD2D信号の受信または送信のいずれかを行うことができる。同様に、
図4に示したそれ以外のサブフレームは、LTE(オーバーレイ)の送信および/または受信に使用できる。
【0074】
[D2D通信における送信手順]
リリース12/13によるD2Dデータ送信手順は、リソース割当てモードに応じて異なる。上述したように、モード1の場合には、スケジューリング割当て(SA)およびD2Dデータを伝えるためのリソースを、UEからの対応する要求の後にeNBが明示的にスケジューリングする。特に、D2D通信は基本的に許可されるがモード2のリソース(すなわち、リソースプール)が提供されないことを、eNBがUEに通知できる。この通知は、例えば、UEによるD2D通信関心通知(D2D communication Interest Indication)と、対応する応答であるD2D通信応答(D2D Communication Response)を交換することによって、行うことができる。この場合、対応する例示的なProseCommConfig Information ElementにcommTxPoolNormalCommonが含まれない。すなわち、送信を含む直接通信の開始を望むUEは、個々の送信ごとにリソース割当てをE−UTRANに要求しなければならない。したがって、このような場合、UEは、個々の送信のリソースを要求しなければならない。以下、モード1のリソース割当ての場合の要求/割当て手順の一連のステップを例示的に示す。
・ ステップ1 UEがスケジューリング要求(SR:Scheduling Request)をPUCCHを介してeNBに送信する。
・ ステップ2 eNBが、(UEがサイドリンクBSR(バッファ状態報告)を送信するための)アップリンクリソースを、C−RNTIによってスクランブルされたPDCCHを介して許可する。
・ ステップ3 UEが、バッファの状態を示すD2D/サイドリンクBSRをPUSCHを介して送信する。
・ ステップ4 eNBが、(UEがデータを送信するための)D2Dリソースを、D2D−RNTIによってスクランブルされたPDCCHを介して割り当てる。
・ ステップ5 D2D送信側UEが、ステップ4で受信したグラントに従って、SA(スケジューリング割当て)/D2Dデータを送信する。
【0075】
スケジューリング割当て(SA)(SCI(サイドリンク制御情報)とも称する)は、制御情報(例えば、対応するD2Dデータを送信するための時間−周波数リソースを示すポインタ、変調・符号化方式、グループ宛先ID)を含むコンパクトな(低ペイロードの)メッセージである。SCIは、1つの(ProSE)宛先IDのサイドリンクスケジューリング情報を伝える。SA(SCI)の内容は、基本的には上述したステップ4で受信されるグラントに従う。D2DグラントおよびSAの内容(すなわちSCIの内容)は、特に、SCIフォーマット0を定義している非特許文献4の5.4.3節(参照により本明細書に組み込まれている)に定義されている(前述のSCIフォーマット0の内容を参照)。
【0076】
これに対して、モード2のリソース割当ての場合、上記ステップ1〜4は基本的に不要である。UEは、SAおよびD2Dデータを送信するための無線リソースを、eNBによって設定および提供される(1つまたは複数の)送信リソースプールから自律的に選択する。
【0077】
図5は、2つのUE(UE−1およびUE−2)の場合のスケジューリング割当て(SA)およびD2Dデータの送信を例示的に示す。スケジューリング割当てを送信するためのリソースは周期的であり、D2Dデータの送信に使用されるリソースは、対応するスケジューリング割当て(SA)によって示される。
【0078】
図6は、1つのSA/データ期間(SC期間(サイドリンク制御期間)としても知られている)中の、モード2(自律的スケジューリング)におけるD2D通信タイミングの1例を示す。
図7は、1つのSA/データ期間中の、モード1(eNBが割当てをスケジューリングする)におけるD2D通信タイミングを示す。3GPPリリース13では、SC期間は、スケジューリング割当て(SA)およびその対応するデータの送信から構成される時間期間として定義されている。
図6から理解できるように、UEは、SAオフセット時間の後、モード2におけるスケジューリング割当て用の送信プールリソース(SA_Mode2_Tx_pool)を使用して、スケジューリング割当て(SA)を送信する。SAの最初の送信の後、同じSAメッセージを例えば3回再送信する。次いで、UEは、(SA_offsetによって与えられる)SAリソースプールの最初のサブフレームから、設定されているオフセット(Mode2data_offset)の後に、D2Dデータ送信(より具体的にはT−RPTビットマップ/パターン))を開始する。MAC PDU(すなわちトランスポートブロック)の1回のD2Dデータ送信は、その1回目の最初の送信と、何回かの再送信とから構成される。
図6(および
図7)においては、3回の再送信(すなわち同じMAC PDUの2回目、3回目、および4回目の送信)の実行を想定している。モード2のT−RPTビットマップ(送信の時間リソースパターン(T−RPT:time resource pattern of transmission))は、基本的に、MAC PDUの送信(最初の送信)およびその再送信(2回目、3回目、および4回目の送信)のタイミングを定義する。SAパターンは、基本的には、SAの最初の送信とその再送信(2回目、3回目、および4回目の送信)のタイミングを定義する。
【0079】
標準規格に現在規定されているように、1つのサイドリンクグラント(例えばeNBによって送られる、またはUE自身によって選択される)において、UEは複数のトランスポートブロック(MAC PDU)を(サブフレーム(TTI)あたり1つのみ、すなわち順々に)送信できるが、1つのProSe宛先グループにのみ送信できる。さらに、1つのトランスポートブロックの再送信は、次のトランスポートブロックの最初の送信が開始される前に完了しなければならない。すなわち、複数のトランスポートブロックを送信するためのサイドリンクグラントあたり1つのみのHARQプロセスが使用される。さらには、UEは、SC期間あたりいくつかのサイドリンクグラントを有して使用できるが、各サイドリンクグラントに対して異なるProSe宛先が選択される。したがって、1つのSC期間において、UEは、1つのProSe宛先には1回のみ送信できる。
【0080】
図7から明らかであるように、eNBによってスケジューリングされるリソース割当てモード(モード1)の場合、D2Dデータ送信(より具体的にはT−RPTパターン/ビットマップ)は、SAリソースプール内でのSA送信の最後の繰り返し後の次のULサブフレームにおいて開始される。
図6ですでに説明したように、モード1のT−RPTビットマップ(送信の時間リソースパターン(T−RPT))は、基本的に、MAC PDUの送信(最初の送信)およびその再送信(2回目、3回目、および4回目の送信)のタイミングを定義する。
【0081】
サイドリンクデータの送信手順は、3GPP標準規格書である非特許文献2の5.14節(参照により本明細書に組み込まれている)に記載されている。この文書には、モード2の自律的なリソース選択が詳しく記載されており、1つの無線リソースプールまたは複数の無線リソースプールが設定されている場合が区別されている。
【0082】
上述した内容は、D2D通信に関する3GPP標準規格の現在の状況である。しかしながら、D2D通信をさらに改良および強化する方策について検討が進められており、結果として今後のリリースにおいてD2D通信にいくつかの変更が導入される可能性が高いことに留意されたい。後から説明する本発明は、そのような今後のリリースにも適用可能であるものとする。
【0083】
例えば現在開発中の3GPPリリース14では、上述したようにSC期間に基づくのではなく、異なる基準に基づく(例えばUuインタフェースでの送信と同じかまたは類似してサブフレームに基づく)ように、送信タイミングが変更されることもありうる。したがって、サイドリンク(PC5)インタフェースを通じて送信を実行する方法に関する上述した例は、一例にすぎず、リリース13には適用できるが、今後のリリースの対応する3GPP標準規格には適用できない可能性がある。
【0084】
[ProSeネットワークのアーキテクチャおよびProSeエンティティ]
図8は、非ローミングの場合の高レベルの例示的なアーキテクチャを示し、UE AおよびUE Bにおける異なるProSeアプリケーションと、ネットワーク内のProSeアプリケーションサーバおよびProSe機能を含む。
図8のアーキテクチャの例は、非特許文献9の4.2節「Architectural Reference Model(アーキテクチャの基準モデル)」(参照により本明細書に組み込まれている)からの引用である。
【0085】
これらの機能エンティティは、非特許文献9の4.4節「Functional Entities(機能エンティティ)」(参照により本明細書に組み込まれている)に提示および詳しく説明されている。ProSe機能は、ProSeに要求されるネットワーク関連動作に使用される論理機能であり、ProSeの特徴それぞれにおいて異なる役割を果たす。ProSe機能は、3GPPのEPC(Evolved Packet Core)の一部であり、近接サービスに関係する認可、認証、データ処理など、関連するネットワークサービス全てを提供する。ProSe直接ディスカバリおよび直接通信において、UEは、固有のProSe UE識別情報、他の設定情報、および認証を、ProSe機能からPC3基準点(PC3 reference point)を通じて取得できる。ネットワーク内に複数のProSe機能を配備できるが、説明を容易にするため、1つのProSe機能を示してある。ProSe機能は、ProSeの特徴に応じた異なる役割を実行する3つのメインのサブ機能、すなわち直接提供機能(DPF:Direct Provision Function)、直接ディスカバリネーム管理機能(Direct Discovery Name Management Function)、およびEPCレベルディスカバリ機能(EPC-level Discovery Function)、から構成されている。DPFは、ProSe直接ディスカバリおよびProSe直接通信を使用するための必要なパラメータをUEに提供するために使用される。
【0086】
この文脈において使用される用語「UE」は、例えば以下のProSe機能(Prose Functionality)をサポートするProSe対応UEを意味する。
・ ProSe対応UEとProSe機能との間でPC3基準点を通じてProSe制御情報を交換する。
・ PC5基準点を通じての、別のProSe対応UEのオープンProSe直接ディスカバリの手順
・ PC5基準点を通じた1対多のProSe直接通信の手順
・ ProSe UEとネットワークとの間の中継器として動作するための手順。遠隔のUEは、PC5基準点を通じて、ProSe UEとネットワークとの間の中継器と通信する。ProSe UEとネットワークとの間の中継器は、レイヤ3パケット転送を使用する。
・ 例えば、UEとネットワークとの間の中継器の検出およびProSe直接ディスカバリのために、PC5基準点を通じてProSe UEの間で制御情報を交換する。
・ 別のProSe対応UEとProSe機能との間でPC3基準点を通じてProSe制御情報を交換する。ProSe UEとネットワークとの間の中継器の場合、遠隔のUEは、この制御情報を、LTE−Uuインタフェースを通じてProSe機能に中継されるようにPC5ユーザプレーンを通じて送信する。
・ パラメータ(例えば、IPアドレス、ProSeレイヤ2グループID、グループセキュリティマテリアル(Group security material)、無線リソースパラメータを含む)を設定する。これらのパラメータは、UEにおいて事前設定することができ、または、カバレッジ内にある場合、PC3基準点を通じたシグナリングによってネットワーク内のProSe機能に提供できる。
【0087】
ProSeアプリケーションサーバは、EPC ProSeユーザIDおよびProSe機能IDの格納と、アプリケーションレイヤユーザIDとEPC ProSeユーザIDのマッピングをサポートする。ProSeアプリケーションサーバ(AS:Application Server)は、3GPPの範囲外のエンティティである。UEにおけるProSeアプリケーションは、アプリケーションレイヤ基準点PC1を介してProSe ASと通信する。ProSe ASは、PC2基準点を介して3GPPネットワークに接続されている。
【0088】
[D2Dサイドリンク論理チャネルのためのLCP手順]
リリース13によるD2DにおけるLCP(論理チャネル優先順位付け)手順は、「通常の」LTEデータの場合の上述したLCP手順とは異なる。以下の情報は、ProSeにおけるLCP手順を記述した非特許文献2の5.14.1.3.1節(その全体が参照により本明細書に組み込まれている)からの引用である。
【0089】
論理チャネル優先順位付け手順は、新しい送信が実行されるときに適用される。各サイドリンク論理チャネルは、関連付けられる優先順位を有する。この優先順位は、PPPP(ProSeパケットごとの優先順位(ProSe per packet priority)、後述する)とすることができる。複数のサイドリンク論理チャネルが、同じ関連付けられる優先順位を有することができる。優先順位とLCID(論理チャネルID)との間のマッピングは、UEの実装に委ねられる。
【0090】
MACエンティティは、SC期間内に送信される各SCIに対して以下の論理チャネル優先順位付け手順を実行する。
− MACエンティティは、以下のステップにおいてサイドリンク論理チャネルにリソースを割り当てる。
− ステップ0: 送信可能な状態のデータを有するサイドリンク論理チャネルのうち最も高い優先順位のサイドリンク論理チャネルを有し、かつそのSC期間において前に選択されていないProSe宛先を選択する。
− ステップ1: 選択されたProSe宛先に属しており、かつ送信可能な状態のデータを有するサイドリンク論理チャネルのうち、最も高い優先順位を有するサイドリンク論理チャネルにリソースを割り当てる。
− ステップ2: リソースが残っている場合、(1つまたは複数の)サイドリンク論理チャネルのデータ、またはSLグラントのいずれかが最初に使い切られるまで、選択されたProSe宛先に属すサイドリンク論理チャネルを、優先順位の降順に処理する。等しい優先順位に設定されているサイドリンク論理チャネルは、同等に処理するべきである。
− さらにUEは、上のスケジューリング手順時、以下の規則にも従う。
【0091】
UEは、次の規則に従ってサイドリンク論理チャネルにリソースを割り当てる。
− RLC SDU全体(または部分的に送信されるSDU)が残りのリソースに収まる場合、UEはそのRLC SDU(または部分的に送信されるSDU)を分割するべきではない。
− UEは、サイドリンク論理チャネルからのRLC SDUを分割する場合、グラントをできる限り満たすようにセグメントのサイズを最大にする。
− UEは、データの送信を最大にするべきである。
− 送信可能な状態のデータを有するときに、10バイト以上のサイドリンクグラントサイズがMACエンティティに与えられる場合、MACエンティティはパディングのみを送信しない。
注: 上記の規則では、サイドリンク論理チャネルが処理される順序は、UEの実装に委ねられることを意味する。
【0092】
一般的にMACエンティティは、1つのMAC PDUにおいて、同じ送信元レイヤ2 IDと宛先レイヤ2 IDのペアを有する論理チャネルのみを考慮する。すなわち、UEにおけるMACエンティティは、1つのMAC PDUにおいて、同じProSe宛先グループの論理チャネルのみを考慮する。すなわち、基本的には、UEはLCP手順時にProSe宛先を選択する。リリース13においては、SC期間内に2つ以上のサイドリンクグラントを有することが許可される。UEは、リリース12のように、各サイドリンクグラントにおいて、1つのProSe宛先グループのデータのみを送信する。しかしながら、1つのSC期間内に2つ以上の有効なサイドリンクグラントを有するようにUEを設定できるため、送信側UEは、複数の異なるProSe宛先にデータを送信することができ、すなわち、各SLグラントにおいて異なるProSe宛先にデータを送信しなければならない。
【0093】
[ProSeにおけるQoSのサポート]
リリース13では、1対多のProSe通信において一般にQoSがサポートされる。この理由のため、例えば非特許文献6においていわゆるPPPP(ProSeパケットごとの優先順位)が導入された。PPPP(ProSeパケットごとの優先順位)は、プロトコルデータユニット(例えばIPパケット)に関連付けられるスカラー値である。PPPPの値は、そのプロトコルデータユニットの送信に適用される優先順位の扱い(すなわちPC5インタフェースで送信するための優先順位の扱い)を定義する。言い換えれば、ProSe PPPは、ProSe UE間およびProSe中継の場合を含むProSe直接通信を使用するときにパケットの優先順位付けを可能にするために使用されるメカニズムである。
【0094】
ProSe上位レイヤ(すなわちPC5アクセス層より上)が、送信するプロトコルデータユニットをPC5アクセス層に渡すとき、ProSe上位レイヤは、8つの可能な値の範囲からPPPP(ProSeパケットごとの優先順位)を提供する。
【0095】
PPPP(ProSeパケットごとの優先順位)は、宛先レイヤ2 IDとは独立しており、1対1および1対多のProSe直接通信の両方に適用される。PPPP(ProSeパケットごとの優先順位)は、例えば本明細書の範囲外である様々な基準(音声パケット伝送などのサービスの遅延要件、又は、フロア制御に関連するシグナリングなどの制御シグナリングなど)に基づいて、アプリケーションレイヤによって選択される。
【0096】
PPPP(ProSeパケットごとの優先順位)は、UEが媒体にアクセスするモード(すなわちProSe通信用にスケジューリング式リソース割当てモードが使用されるか自律式リソース割当てモードが使用されるか)とは無関係である。ProSeアクセス層は、上位レイヤから受け取るプロトコルデータユニットに関連付けられるPPPP(ProSeパケットごとの優先順位)を使用して、別のUE内送信(intra-UE transmissions)(すなわち同じUEの内側で送信を待機している、様々な優先順位に関連付けられているプロトコルデータユニット)およびUE間送信(inter-UE transmissions)(すなわち異なるUEの内側で送信を待機している、様々な優先順位に関連付けられているプロトコルデータユニット)に関連して、送信を優先順位付けする。
【0097】
優先順位キュー(UE内およびUE間の両方)は、優先順位の厳密な順序で処理されることが予期される。すなわち、UEまたはeNBは、PPPP(ProSeパケットごとの優先順位)Nに関連付けられる全てのパケットを、優先順位N+1に関連付けられるパケットを処理する前に処理する(小さい数ほど高い優先順位を意味する)。
【0098】
PC5インタフェース自体における優先順位の扱いは、非特許文献2に規定され、すなわち、論理チャネル優先順位付け(LCP)手順である。各サイドリンク論理チャネルに対して、関連付けられる優先順位(例えばレガシーLTEのアップリンク動作における論理チャネルの優先順位に類似する)が存在する。サイドリンク論理チャネルの作成は、リリース12と同様にUEの実装に委ねられる。UEは、論理チャネルを作成するとき、パケットの送信元ID/宛先IDを考慮することに加えて、パケットの優先順位も考慮する。基本的には、同じPPPP値(および同じ送信元ID/宛先ID)を有するプロトコルデータユニットは、PPPPと同じである特定の論理チャネル優先順位が関連付けられている1つのサイドリンク論理チャネルによって処理される。
【0099】
上述したように、UEは、SLグラントを受信したときの論理チャネル優先順位付け手順時、SLデータを有するサイドリンク論理チャネルのうち、PPPPが最も高いサイドリンク論理チャネルを有するProSeグループを選択する。次いで、UEは、選択されたProSe宛先グループに属する全てのサイドリンク論理チャネルを、優先順位の降順に処理する。
【0100】
[車両通信: V2Xサービス]
新しいLTE機能(近接サービス(ProSe)およびLTEベースのブロードキャストサービスを含む)の、自動車業界における有用性を検討する目的で、リリース14では、3GPPにおいて新たな検討項目が設けられた。ProSe機能は、V2Xサービスのための優れた基礎部分を提供すると考えられる。車両のシナリオにおける協調的サービス(cooperative service)は、ITS(高度道路交通システム:Intelligent Transportation Systems)の研究分野の中の将来的な接続された車両において不可欠になりつつある。協調的サービスによって、交通死亡事故が減り、道路のキャパシティが改善され、道路輸送の二酸化炭素排出量が減少し、走行中のユーザの体感が向上するはずである。
【0101】
V2X通信とは、車両から、車両に影響を与えうるエンティティに、またはこの逆方向に、情報を渡すことである。この情報交換を使用して、安全性、移動性、および環境的なアプリケーションを向上させ、運転者支援型の車両の安全性、速度調整および警告、緊急時対応、走行情報、ナビゲーション、交通運用(traffic operations)、商業的車両計画(commercial fleet planning)、および支払処理を含めることができる。
【0102】
V2XサービスのためのLTEのサポートには、以下の3つのタイプの異なるユースケースが含まれる。
・ V2V: 車両間のLTEベースの通信をカバーする
・ V2P: 車両と、個人が携帯する装置(例:歩行者、サイクリスト、運転者、または同乗者が携帯する携帯情報端末)との間のLTEベースの通信をカバーする
・ V2I: 車両と道路側ユニットと間のLTEベースの通信をカバーする
【0103】
これら3つのタイプのV2Xでは、「協調認識(co-operative awareness)」を使用して、エンドユーザ向けのよりインテリジェントなサービスを提供できる。すなわち輸送エンティティ(車両、道路側インフラストラクチャ、歩行者など)は、よりインテリジェントなサービス(協調的な衝突警告又は自動運転など)を提供する目的で、それぞれの局所的な環境の情報(例えば近くの別の車両やセンサー機器から受信される情報)を収集して、それらの情報を処理および共有できる。
【0104】
V2V通信に関しては、E−UTRANでは、互いに近接している(車両)UEが、許可基準、権限基準、および近接基準が満たされているとき、E−UTRA(N)を使用してV2V関連情報を交換できる。近接基準は、MNO(移動体通信事業者:Mobile Network Operator)によって設定できる。ただし、V2VサービスをサポートしているUEは、V2XサービスをサポートするE−UTRANによってサーブされているかに依らず、そのような情報を交換できる。
【0105】
V2Vアプリケーションをサポートしている装置(車両UE)は、アプリケーションレイヤ情報(例:V2Vサービスの一部としてのUE自身の位置、動態(dynamics)、属性)を送信する。様々な情報コンテンツに対応する目的で、V2Vペイロードは柔軟性がなければならず、情報は、MNOによって提供される設定に従って周期的に送信できる。
【0106】
V2Vは、主としてブロードキャストベースである。V2Vには、個別の装置間でV2V関連アプリケーション情報を直接交換すること、および/または、V2Vの直接通信範囲が限られているため、V2Xサービスをサポートするインフラストラクチャ(例:RSU(道路側ユニット)、アプリケーションサーバなど)を介して個別の装置間でV2V関連アプリケーション情報を交換すること、が含まれる。
【0107】
V2I通信に関しては、V2Iアプリケーションをサポートしている装置が、道路側ユニットにアプリケーションレイヤ情報を送信し、道路側ユニットが、V2Iアプリケーションをサポートしている装置のグループまたは装置にアプリケーションレイヤ情報を送信できる。
【0108】
V2N(車両−ネットワーク(eNB/CN))も導入されている。V2Nでは一方がUEであり他方がサービングエンティティであり、両方がV2Nアプリケーションをサポートしており、LTEネットワークを介して互いに通信する。
【0109】
V2P通信に関しては、E−UTRANでは、互いに近接しているUEが、許可基準、権限基準、および近接基準が満たされているとき、E−UTRANを使用してV2P関連情報を交換できる。近接基準は、MNO(移動体通信事業者)によって設定できる。しかしながら、V2PサービスをサポートしているUEは、V2XサービスをサポートするE−UTRANによってサーブされていないときにも、そのような情報を交換できる。
【0110】
V2PアプリケーションをサポートしているUEは、アプリケーションレイヤ情報を送信する。このような情報は、V2XサービスをサポートしているUEを有する車両によってブロードキャストする(例:歩行者への警告)、および/または、V2XサービスをサポートしているUEを有する歩行者によってブロードキャストする(例:車両への警告)ことができる。
【0111】
V2Pには、個別のUE(一方が車両のUE、他方が歩行者のUE)の間でV2P関連アプリケーション情報を直接交換すること、および/または、V2Pの直接通信範囲が限られているため、V2Xサービスをサポートするインフラストラクチャ(例:RSU(道路側ユニット)、アプリケーションサーバなど)を介して個別のUE間でV2P関連アプリケーション情報を交換すること、が含まれる。
【0112】
この新しい検討項目V2Xを対象に、3GPPは、特定の用語および定義を非特許文献10の中で規定しており、これらの用語および定義は本出願においてそのまま使用できる。
【0113】
道路側ユニット(RSU:Road Side Unit): V2Iサービスをサポートしているエンティティであり、V2Iアプリケーションを使用しているUEに送信する、およびUEから受信できる。RSUは、eNBまたは固定されたUE内に実施できる。
【0114】
V2Iサービス: V2Xサービスの1つのタイプであり、一方のエンティティがUE、他方のエンティティがRSUであり、両方がV2Iアプリケーションを使用する。
【0115】
V2Nサービス: V2Xサービスの1つのタイプであり、一方のエンティティがUE、他方のエンティティがサービングエンティティであり、両方がV2Nアプリケーションを使用し、LTEネットワークエンティティを介して互いに通信する。
【0116】
V2Pサービス: V2Xサービスの1つのタイプであり、通信の両方のエンティティが、V2Pアプリケーションを使用するUEである。
【0117】
V2Vサービス: V2Xサービスの1つのタイプであり、通信の両方のエンティティが、V2Vアプリケーションを使用するUEである。
【0118】
V2Xサービス: 通信サービスの一種であり、3GPP伝送を介してV2Vアプリケーションを使用する送信側UEまたは受信側UEを含む。V2Xサービスは、通信に関与する他方のエンティティに基づいて、V2Vサービス、V2Iサービス、V2Pサービス、およびV2Nサービスにさらに分けることができる。
【0119】
多くのITSサービスは、以下の共通の通信要件を有する。
・ 周期的な状態の交換。ITSサービスでは、一般に、車両端末の状態または道路側端末の状態に関して認識している必要がある。すなわち、位置、速度、識別子などに関する情報を有するデータパケットを周期的に交換する。
・ 非同期の通知。この種類のメッセージは、特定のサービスイベントを通知するために使用される。前の状態メッセージとは異なり、これらのメッセージを1基の端末または端末のグループに高い信頼性で配信することは、通常では重要な要件である。
【0120】
最初の通信タイプの使用例は、車両遠隔監視(車両から周期的な状態データを集める)などの交通効率サービス(traffic efficiency services)、または協調的な衝突回避(衝突の可能性を検出するため周囲の車両に関する運動学的情報を必要とする)などの安全性サービスに見出すことができる。非同期の通知は、主として安全性サービス(滑りやすい道路又は衝突後の警告など)に見出される。
【0121】
V2V通信には様々なタイプのメッセージが定義されており、今後も定義されるであろう。高度道路交通システム(ITS)には以下の2種類のメッセージがETSIによってすでに定義されている(対応する欧州規格書である非特許文献11および非特許文献12を参照)。
・ 協調認識メッセージ(CAM:Cooperative Awareness Messages): このメッセージは、車両の状態を反映するため車両の動態によって継続的にトリガーされる。
・ 分散型環境通知メッセージ(DENM:Decentralized Environmental Notification Messages): このメッセージは、車両に関連する安全性イベント(safety event)が発生したときにのみトリガーされる。
【0122】
V2VおよびITSの標準化は始まったばかりであるため、将来的には別のメッセージも定義されうると予測される。
【0123】
CAMは、ITS局(ITS−S:ITS-Station)によって、別のITS−Sと状態情報を交換するために継続的に(周期的に)ブロードキャストされるので、イベントによってトリガーされる(非周期的な)DENMメッセージよりもトラフィック負荷に大きく影響する。本質的にCAMメッセージは、存在、位置、温度、および基本状態の情報を提供する目的で各車両によって近くのITS局に周期的にブロードキャストされる一種のハートビートメッセージである。これに対してDENMは、危険なイベントを道路の使用者に警告するためにブロードキャストされるイベントトリガー型メッセージである。この理由のため、ITSを対象にETSIによって定義されているCAMメッセージのトラフィック特性は、V2Vトラフィックをよく表しているとみなされる。
【0124】
協調認識メッセージ(CAM)は、互いの認識を形成してそれを維持し、道路ネットワークを使用して車両の協調的能力をサポートする目的で、ITS−Sの間でITSネットワークにおいて交換されるメッセージである。CAMの送信にはポイントツーマルチポイント通信が使用される。したがって、CAMは、送信元のITS−Sから、送信元ITS−Sの直接通信の範囲内に位置している受信側ITS−Sに送信される。CAMの生成は、協調認識基本サービス(Cooperative Awareness basic service)(2つの連続するCAMの生成の間の間隔を定義する)によってトリガーおよび管理される。現在のところ、送信間隔の上限および下限は、100ms(すなわち10HzのCAM生成速度)および1000ms(すなわち1HzのCAM生成速度)である。ETSI ITSの基礎をなす考え方は、共有する新しい情報(例:新しい位置、新しい加速、新しい進路の値)が存在するときにCAMを送ることである。したがって、車両がゆっくりと一定の進路および速度で移動しているときには、CAMの生成速度が高くても、CAMはわずかな差を示すのみであり、実際の恩恵はない。1台の車両のCAMの送信頻度は、車両の動態(例:速度、加速度、進路)の関数として1Hz〜10Hzの間で変化する。例えば、車両がゆっくり走行しているほど、トリガーされて送信されるCAMの数が少ない。車両の速度は、CAMトラフィックの生成に影響する主要因である。
【0125】
上記では、周期的な協調認識メッセージを説明した。ただし、上述した情報のいくつかはすでに標準化されているが、それ以外の情報(周期およびメッセージのサイズなど)はまだ標準化されておらず、想定に基づいていることに留意されたい。さらには、これらの標準化は将来において変更されることがある。したがって、CAMがどのように生成されて送信されるかの態様も変更されうる。
【0126】
したがって、上述した詳細なCAMの説明は、実例を目的として着想された一例として理解されたい。本発明の基礎となる原理を説明する目的で、上述したCAMメッセージが本出願全体を通じて使用される。本発明において重要なことは、V2V通信では車両UEが様々なデータを周期的に送信することが要求され、その周期は車両の動態((相対)速度、角度、進路など)、および場合によっては車間距離など他の要因の関数として短時間で変化しうることが予測されることである。したがって、課題は、車両UEが、異なるメッセージサイズのいくつかの周期的パケットを、様々な変化する周期で送信できることである。
【0127】
車両UEが、CAMを送信するためにサイドリンクにおける無線リソースを取得する目的で、上述したようにモード1および/またはモード2の無線リソース割当てが想定される。モード1の無線リソース割当ての場合、eNBが、SAメッセージおよび各SA期間のデータのためのリソースを割り当てる。しかしながら、多量のトラフィック(例えば高頻度の周期的トラフィック)が存在するときには、UEからeNBへのUuリンクにおけるオーバーヘッドが大きくなることがある。
【0128】
上記から明らかであるように、多量のV2Vトラフィックは周期的である。したがって、3GPPでは、サイドリンクV2V通信のモード1(すなわちeNBが無線リソース割当てをスケジューリングする)の場合、サイドリンクのセミパーシステント無線リソース割当てがeNBおよびUEによってサポートされることが合意された。
【0129】
UEによる自律的なリソース割当てモード(モード2)の場合、衝突の問題(すなわち2つ以上の送信側UEが同じリソースブロックを選択してメッセージを送信する)が、ユーザに実際に提供されるQoSに影響することは明らかである。リリース12/13では、UEによる自律的なリソース割当てモードにおけるデータ(PSSCH)衝突の問題については検討されない。なぜなら、PC5/サイドリンクのQoSは重要な要件ではなかったためである。しかしながら、V2Xサービスでは、UEによる自律的なリソース割当てモードにおけるQoSを改善することは避けられない。3GPPでは、センシング(sensing)および「セミパーシステント」送信(無線リソース予約とも称される)によって、UEによる自律的なリソース選択におけるQoSを改善することが基本的に合意された。
【0130】
さらに詳細には、V2Xサイドリンクにおける自律的なリソース制御/選択メカニズムとして、セミパーシステント送信とともにセンシングメカニズムをサポートすることが合意された。UEは、リソースの選択が行われるまで周期的に発生する選択されたリソースのセットに関するデータを有することを、PSSCH(SA/SCI)の中で示す。他のUEによってすでに確保/予約されているリソースが、無線リソースの選択対象として考慮されないように、このリソース予約情報(SCIの中でシグナリングされる)は、リソースを選択してV2Xメッセージを送信しようとしている別のUEによって使用できる。このリソース確保/予約手順は、特定の周期でパケットが到着するトラフィック(例:CAMメッセージ)にのみ適用される。
【0131】
上述した、スケジューリング情報の中の予約済み無線リソースの指示情報は、他の(車両)装置によって監視する(「センシングする」)ことができる。センシングは、一般的には、送信用の候補リソースのセットを識別するときに使用される。この目的のため、センシングプロセスでは、周波数リソースを以下のように異なるグループに分類する。
・ 「利用不可(unavailable)」のリソース。これは、別のUEによってすでに予約/確保されているため、そのリソースで送信することがUEに許可されないリソースである。
・ 「候補リソース(candidate resource)」。これは、UEがそのリソースで送信を実行してもよい/することができるリソースであり、さらに「プライマリリソース」と「セカンダリリソース」とに分類できる。
【0132】
UEの複雑さが増大しすぎないようにする目的で、センシングは、簡単な方法で実施可能であるべきである。また、センシングアルゴリズムを実施する方法に関して複数の方法/オプションが存在しうることに留意されたい。1つの可能な実施オプションは、全てのUEそれぞれが、次のサブフレームから始まり最大で例えば1秒に渡る周波数リソースの予測を含むマップを有することである。すなわち、UEのバッファにパケットが到着する時刻Pにおいて、UEは、サブフレームPからサブフレームLにおける全ての周波数リソースのマップを有する。Lは、基本的に、リソースそれぞれが「利用不可」であるか候補であるかにかかわらず、それまでにパケットを送信するべき(QoSに従っての)最大期間を表す。
【0133】
「利用不可」のリソースは、SCIの復号(リソースの予約/確保)に基づいて求められる。なお、(リソース候補のセットからの)送信用の実際のリソースの選択の詳細については、3GPPにおいてまだ最終的に決定されておらず、依然として検討中であることに留意されたい。1つの例示的な方法は、送信に使用される実際のリソースの選択が、候補リソースのセットの中でランダムに実行される(全ての選択肢に等しい確率が割り振られる)ことである。類似するリソースマップを有するUEが異なるリソースを選択するようにするためには、ランダム性は適切でありうる。候補リソースのセットが十分に大きい限りは、ランダムな選択を使用することによって、観測値に相関のあるUEが同じリソースを選択する確率が低いことが確保される。基本的にUEは、トランスポートブロックの(再)送信用に、候補リソースとして分類されている最も近いリソースを考慮する。候補リソースが、レイテンシ又は帯域幅など関連する別の要件を満たすようにするため、さらなる制約を適用できる。これらのリソース全てが、送信用の候補リソースのセットを構成する。
【0134】
もう1つの方法は、候補リソースの中から実際の送信リソースを選択する目的で、(ランダムな選択とは異なり)エネルギに基づくさらなるセンシングの結果も使用することである。エネルギに基づくセンシング(energy-based sensing)とは、UEがPSSCHリソースおよび/またはPSCCHリソースにおける受信信号強度を測定するプロセスを意味する。エネルギに基づくセンシングは、主として、UEが無線リソースの候補リストの中でリソースをランク付けすることを支援する。エネルギに基づくセンシングによって、干渉者の遠近を識別することが本質的に支援される。より具体的には、検出されるエネルギが比較的低い無線リソースを選択するべきであるのに対して、エネルギが比較的高いリソースを選択しない。
【0135】
なお、リソースブロック(RB:Resource Block)レベルにおける情報を含むマップを有することによって、UEは十分な柔軟性を有し、センシングするときに、スケジューリングするトランスポートブロックのサイズを認識している必要がないことに留意されたい。
【0136】
しかしながら、PC5インタフェースを通じたV2X送信のためのセンシングおよびリソース予約に関して基本的な合意には達したが、これらの新しいセンシングおよびリソース予約のメカニズムを考慮する目的での現在の標準規格のさらなる変更は、現在のところ予測されていない。したがって、これらのメカニズムを現在のシステムの中に実施することによって、問題および非効率性がもたらされることがありうる。
【発明を実施するための形態】
【0151】
「移動局(mobile station)」、「移動ノード(mobile node)」、「ユーザ端末(user terminal)」または「ユーザ機器(user equipment)」は、通信ネットワーク内の物理エンティティである。1つのノードがいくつかの機能エンティティを有することができる。機能エンティティとは、所定の一連の機能を実施する、および/または、所定の一連の機能をノードまたはネットワークの別の機能エンティティに提供するソフトウェアモジュールまたはハードウェアモジュールを意味する。ノードは、通信機器または通信媒体にノードをアタッチする1つまたは複数のインタフェースを有することができ、ノードはこれらのインタフェースを通じて通信できる。同様に、ネットワークエンティティは、機能エンティティを通信機器または通信媒体にアタッチする論理インタフェースを有することができ、ネットワークエンティティは論理インタフェースを通じて別の機能エンティティや通信相手ノードと通信できる。
【0152】
特許請求の範囲および本出願において使用されている用語「無線リソース(radio resource)」は、物理無線リソース(時間−周波数リソースなど)を意味するものと広義に理解されたい。
【0153】
本出願において使用されている用語「直接通信送信(direct communication transmission)」は、2つのユーザ機器の間の直接的な(すなわち無線基地局(例えばeNB)を介さない)送信として広義に理解されたい。また、直接通信送信は、「直接サイドリンク接続」を通じて実行され、「直接サイドリンク接続(direct sidelink connection)」は、2つのユーザ機器の間に直接確立される接続に対して使用される用語である。例えば3GPPでは、D2D(装置間)通信、ProSe通信、またはサイドリンク通信という専門用語が使用される。用語「直接サイドリンク接続(direct sidelink connection)」、「サイドリンクインタフェース(sidelink interface)」は、広義に理解されるものとし、3GPPの文脈では背景技術のセクションで説明したPC5インタフェースとして理解できる。
【0154】
本出願において使用されている用語「ProSe」またはその非短縮形である「近接サービス(Proximity Services)」は、背景技術のセクションで例示的に説明したように、LTEシステムでは近接性に基づくアプリケーションおよびサービスの文脈において適用される。この文脈では、近接サービスにおける装置間通信を意味する目的で、「D2D」などの別の専門用語も使用される。
【0155】
本出願全体を通じて使用されている用語「車両移動端末(vehicular mobile terminal)」は、背景技術のセクションで説明した3GPPの新しい検討項目または作業項目であるV2X(車両通信)の文脈において理解されるものとする。したがって、車両移動端末は、車両通信を実行する(すなわち、例えば安全性あるいは運転者の支援を目的として車両に関連する情報を他のエンティティ(車両、インフラストラクチャ、歩行者など)に渡す)ために、特に車両(例:自動車、商用トラック、オートバイなど)に取り付けられている移動端末として、広義に理解されるものとする。オプションとして、車両移動端末は、ナビゲーションシステム(同様に自動車に取り付けられている場合)において利用可能な情報(地図情報など)にアクセスできる。
【0156】
背景技術のセクションで説明したように、3GPPは、LTEによって支援される車両通信に関する新しい検討項目を導入し、この車両通信は、ProSe手順に基づいて、様々な車両移動端末と別の局との間でV2Xトラフィックを交換する。さらには、V2Xトラフィック用に、一種のセミパーシステントな無線リソース割当てがサポートされ、この目的を達成するため、特に、UEによる自律的なリソース割当てモード(モード2とも称する)における無線リソースの予約およびセンシングのためのメカニズムがサポートされることが合意された。しかしながら、センシングおよび無線リソースの予約に関して基本的な合意に達したにすぎず、これらをどのように実施するかと、効率的かつ欠陥のない動作を確保するために他のメカニズムをどのように適合させるかに関する詳細は提供されていない。
【0157】
例えば、センシングおよび無線リソースの予約は、(車両)UEがどのように無線リソースを選択してPC5インタフェースを通じてデータを送信するかに、大きく影響する。車両UEは、モード2では、適切なリソースプールから無線リソースを自律的に選択する。特に、UEがセンシングおよびリソースの予約/確保を行うときに、セミパーシステントな割当てをどのように実施できるかは明らかではない。
【0158】
本発明者は、上に説明した問題点を緩和するため、以下の例示的な実施形態を着想した。
【0159】
様々な実施形態の特定の実装形態は、3GPP標準規格によって与えられる、一部を背景技術のセクションで説明した幅広い仕様の中で実施され、特に重要な特徴は、以下の実施形態において説明するように追加される。なお、これらの実施形態は、例えば、背景技術のセクションで説明した3GPP LTE−A(リリース10/11/12/13/14)通信システムなどの移動通信システムにおいて有利に使用できるが、これらの実施形態はこれらの特定の例示的な通信ネットワークでの使用に限定されないことに留意されたい。
【0160】
以下の説明は、本開示の範囲を制限するものとしてではなく、本開示を深く理解するための実施形態の単なる例として理解されたい。当業者には、請求項に記載されている本開示の一般的な原理を、様々なシナリオに、以下に明示的には記載されていない方法で適用できることが認識されるであろう。説明を目的として、いくつかの想定がなされているが、これらの想定は以下の実施形態の範囲を制限するものではない。
【0161】
様々な実施形態は、主として、送信装置からサイドリンクインタフェースを介して1つまたは複数の受信装置への周期的データおよび非周期的データの改良された送信、を提供する。改良された送信には、送信装置による、例えば自律的に制御される無線リソースの割当ても含まれる。それ以外の機能(すなわち様々な実施形態によって変更されない機能)は、背景技術のセクションで説明した機能とまったく同じままとする、または、様々な実施形態に何ら影響しない範囲で変更できる。このような機能としては、例えば、送信装置が周期的データの送信を実行する正確な方法、あるいは様々な送信装置が互いに発見する方法などの別の手順が挙げられる。
【0162】
様々な実施形態を適用することのできる1つの例示的なシナリオは、背景技術のセクションにおいて例示したV2X通信である。したがって、送信装置および受信装置は、例えば、車両におけるUE、道路側ユニット、歩行者が携帯している「通常の」移動端末などとすることができる。さらに、周期的データは、様々な車両エンティティの間で継続的に交換される車両データ(例:CAMメッセージ)とすることができる。
【0163】
以下の例示的な実施形態は、実例を目的として、このようなV2X通信のシナリオに関連して説明するが、本発明はこれに限定されないものとする。そうではなく、本発明は、より一般的に、別の(車両以外の)シナリオ、例えば「通常の」UEが、周期的データおよび非周期的データを、Uuインタフェースを介してeNBに送信する、またはPC5インタフェース(サイドリンク接続)を介して他の(1つまたは複数の)UEに送信するシナリオにも、適用できる。
【0164】
(第1の実施形態)
以下では、上述した(1つまたは複数の)問題点を解決するための第1の実施形態について詳しく説明する。第1の実施形態の様々な実装形態およびバリエーションも説明する。
【0165】
すでに上で例示的に述べたように、車両に取り付けられており、かつ本出願の背景技術のセクションで説明したようにD2Dのフレームワークに基づいて車両通信を実行することのできる車両UE、を想定する。したがって、車両データ(例:周期的データおよび非周期的データ)は、そのデータに関心のある別のエンティティに、車両UEによって送信される。
【0166】
車両UEによって送信される周期的データは、背景技術のセクションで詳しく説明した協調認識メッセージ(CAM)によって例示される。本発明に関連するCAMの特徴として、CAMは周期的に送信されるので、一般的にはセミパーシステントなリソース割当てに適している。しかしながら、CAMは、セミパーシステントスケジューリングのシナリオの通常のVoIPの使用シナリオとは著しく異なる点として、様々な、場合によっては変化する送信周期、および/または、様々なメッセージサイズ(すなわち車両UEがそのための無線リソースを必要とする送信されるデータの量)が存在する。VoIPは、一定の周期および一定のメッセージサイズを示し、これらは、eNodeBによって実行される周知のセミパーシステントな無線リソース割当てによって扱うことができる。
【0167】
なお、CAMは、このような周期的データの一例にすぎず、車両通信または車両以外の通信において標準化されている、または将来的に標準化される別のタイプのデータにも、本発明を適用できることに留意されたい。特に車両通信においては、車両UEは、(状態および属性)データを、様々な、および/または場合によっては変化する周期で周期的にブロードキャストしなければならない可能性が高い。したがって、車両UEは、様々な量のデータを有する異なる周期のメッセージを、様々な時刻インスタンスにおいて送信しなければならない。PC5インタフェースを通じたV2X通信のために実施されるセミパーシステントな無線リソース割当てでは、このことを考慮しなければならない。
【0168】
以下では、非周期的データは、背景技術のセクションで紹介したDENMメッセージによって例示される。なぜなら、DENMメッセージは、車両に関連する安全性イベントによってトリガーされ、周期的ではないためである。一方で、DENMメッセージは、トリガーされた後には、受信装置がこのメッセージを確実に受信するように、特定の時間長に渡り繰り返し送信されることがある。したがって、DENMメッセージは、その短い期間中は周期的データとなる。しかしながら、以下の例示的な実施形態およびそのバリエーションにおいては、周期的データはCAMメッセージであると想定し、DENMメッセージは非周期的データであるとみなす。
【0169】
背景技術のセクションで説明したように、センシングおよび無線リソースの予約は、今後の標準規格の(1つまたは複数の)リリースに含められることが3GPPによってほぼ承認されている。特に、送信側で無線リソースを予約することによって、例えば、周期的データのパケットを、現在使用されているリソースと同じリソースを使用して送信できるように、1つまたは複数の後からの時刻インスタンス用にも、現在使用されているリソースと同じリソースを予約することにより、一種の「セミパーシステントな」無線リソース割当てを実施できる。したがって、車両UEは、後からの時刻インスタンスにおいては、周期的データを送信できるようにするためにリソースの選択/要求(モード2またはモード1のリソース割当て)を再び実行する必要がない。以下では、ほとんどの場合、リソースの予約が周期の次の時刻インスタンスのみを対象に実行されるものと想定する(例えば
図9を参照)。ただし、(第1の)実施形態は、より長い期間に渡る(すなわち2つ以上の時刻インスタンスを対象とする)無線リソースの予約が可能であるシナリオにも等しく適用可能である。
【0170】
無線リソースの予約は、様々な方法で実施することができ、3GPPによってまだ決定されていない。サイドリンクデータとともに送信されるスケジューリング情報(SCI)は、送信に使用される無線リソースを識別する。したがって、スケジューリング情報によって、受信側エンティティは、サイドリンクデータを正しく受信して処理/復号できる。これに加えてスケジューリング情報は、例えば、無線リソースが予約されている時刻(例:サブフレーム)を受信側エンティティが判断できるように、データの時刻または周期を示すことによって、無線リソースの予約を示す目的にも使用することができる。一例においては、スケジューリング情報は、(そのスケジューリング情報に示されている)リソースがさらに予約されている(1つまたは複数の)後の時刻インスタンスを示すための対応するフィールドを含むことができる。このフィールドの値は、無線予約が適用される対象のデータ(より一般的には論理チャネル)の周期から求めることができる。すなわち、例えば、CAMメッセージの周期が100msであるとき、スケジューリング情報の対応する周期フィールドはこの100msを示す。
【0171】
オプションとして、スケジューリング情報は、リソースの予約が適用される周期の時刻インスタンスの数を、このフィールド(または個別のフィールド)の中でさらに示すことができる。ただし、これは、そのように明示的に示すことが実際に必要である場合である。なぜなら、この数はUEによって別の方法で求めることもできる(例えばあらかじめ決める、または例えばRRCプロトコルによって設定するなど)ためである。
【0172】
スケジューリング情報の中で既に示された(すなわち今回の送信に使用される)無線リソースは、後の時刻インスタンスに対しても予約される可能性が高い。この方式の利点として、センシング動作がサポートされ、衝突の確率を小さくすることによってリソース予約メカニズムがより効率的になる。しかしながら、このことは絶対的には必要ではない。例えば、スケジューリング情報の中で別の無線リソースを追加的に示すことによって、または周期的データの送信用に今回使用されるようにすでに識別されている無線リソースから、(例えば予約された無線リソースを導くための所定の規則を使用することにより)別の無線リソースを暗黙的に求めることによって、別の無線リソースを予約することもできる。
【0173】
最初に想定することとして、UEは、モード2の無線リソース割当てをサポートしており、主としてこの無線リソース割当てを実行する。さらに、UEには、スケジューリング情報およびデータをPC5(サイドリンク)インタフェースを介して送信するための無線リソースを自律的に選択できるように必要な(1つまたは複数の)リソースプールが適切に設定されている。
【0174】
周期的なCAMメッセージを効率的に送信する目的で、UEの新規の挙動を提供する。この挙動について、
図9(時刻インスタンスt1〜t4におけるデータの周期的な送信を示す)に関連して例示的に説明する。この実施形態の図解および説明を容易にする目的で、いくつかの想定を行う。例えば、スケジューリング情報とデータが同じサブフレームにおいて送信されることを例示的に想定する。ただし、データの実際の送信より前のサブフレームの1つにおいてスケジューリング情報が送信されることも同等に可能である。3GPP会合において現在検討されているように、(リリース14の時点で)PC5インタフェースを介してのD2D送信における送信タイミングは、以前のリリース12/13において使用されていた、
図6および
図7に示したタイミングと比較して、今後のリリースにおいて変更されることもありうる。したがって、
図9において例示的に想定したように、SCIとD2Dデータを同じサブフレームにおいて送信するように決定されることもありうる。
【0175】
さらに、UEは、使用する無線リソースが解放されるまで待機しなければならないのではなく、送信可能な状態になるデータを直ちに送信できると想定する。
【0176】
時刻t0において、車両アプリケーションが周期的データ(例:CAMメッセージ)の生成を初めて開始し、PC5インタフェースを介して送信できるようにCAMメッセージを下位レイヤに転送する。このときアプリケーションレイヤが、周期的データとともに、優先順位の指示情報(PPPP(ProSeパケットごとの優先順位)など)を下位レイヤに伝えると想定する。下位レイヤは、例えば周期的データのPPPP(優先順位の指示情報)に応じて、周期的データのための対応するサイドリンク論理チャネルを設定する。車両UEは、設定されているモード2のUEによる自律的なリソース割当てに従って、CAMメッセージを送信するため適切なリソースプールからの無線リソースの選択を開始する。UEによって選択されるリソースの量は、CAMメッセージのサイズによって決まる。
【0177】
ここで留意すべき点として、車両アプリケーションレイヤ(CAMメッセージを周期的に生成する)は、正確な周期ではデータを生成しない。周期的データの生成は変動することがある。したがって、CAMメッセージは、実際には、CAMメッセージの周期によって与えられる特定の時刻付近で生成される。周期的データの生成における変動は、(例えば(V2X)アプリケーションおよびオペレーティングシステムのタイミングクロックに起因して)送信装置において発生するジッタが原因となることがある。さらには、CAMメッセージ生成のタイミングオフセットが発生することがある。具体的には、所与の周期のCAMにおいて、何らかの運転イベント(加速、急ブレーキ、緊急旋回など)によっていくらかの速度変化/進路変化が突然起こり、このとき対応するトリガー条件が満たされていると、CAMの元の周期に従わない間隔で1つまたは2つのCAMメッセージが生成されることがある。次いで、これらの突然かつ偶発的なイベントから回復した後、CAMの周期は前と同じ周期に戻りうるが、その後の一連のCAMのタイミングオフセットは、CAMの元のトラフィックパターン(すなわち速度または進路が突然変化する前のCAM)と比較して変更される。
【0178】
したがって、UEによるリソース選択において、周期的データの到着を基準とするオフセットを伴って無線リソース(その後、セミパーシステント式に継続的に使用される)を選択することによって、メッセージの生成におけるこのジッタ/オフセットをすでに考慮できる。オフセット量は、無線リソースが予約されている時刻よりも(わずかに)後にCAMメッセージが送信可能な状態になることを回避する目的で、以降のCAMメッセージの生成が、予約された無線リソースの時刻より前に実際に起こるように、選ぶことができる。車両UEは、時刻t1において、選択された無線リソースを使用して最初のCAMメッセージを送信する。車両UEは、CAMメッセージが特定の(現在の)周期(例:100ms)を有することを、例えば周期に関する特定の指示情報を受け取ることによって、またはPPPPに符号化されている情報から、上位レイヤから認識している。したがってUEは、さらなるCAMメッセージを以降の時刻インスタンス(例えば約t
1)+100msにおける次の時刻インスタンス)において送信しなければならないことを予期できる。したがって、車両UEは、時刻t2(例えば単純にはt1+100msとすることができる)(すなわち次のCAMメッセージが予期されるのみならず、リソースの選択に最初に適用された生成ジッタおよびオフセットも考慮された時刻)における対応するリソースを、さらに予約する。
【0179】
時刻t2の前に(例えば時刻t2よりいくつかのサブフレームだけ前に)、CAMメッセージのデータが実際に送信可能な状態になる。しかしながら、車両UEは、周期的なCAMメッセージ用に予約されている無線リソースを認識しているため、無線リソースの選択を実行せずに、時刻t1における送信によって無線リソースが予約されている時刻t2まで、その周期的データを遅延させる。CAMメッセージの送信を遅延させた後、車両UEは、時刻t2において、予約されている無線リソースを使用して新しいCAMメッセージを送信する。結果として、このセミパーシステントなリソース割当てによって、無線リソースをさらに選択する必要性が回避され、すでに予約されている無線リソースを効率的に使用できる。このプロセスのさらなる利点として、たとえCAMメッセージが早すぎるタイミングで送信可能な状態になる場合でも、CAMメッセージを送信するために別の無線リソースが突然使用されることはないので、予約された無線リソースが無駄にならない。さらには、別の(車両)装置(予約された無線リソースを識別するためにセンシングを継続的に実行している)が、無線リソースの選択を実行するときに、予約済みの無線リソースを正しく回避する。
【0180】
車両UEは、時刻t2においても同様に、時刻t2においてCAMメッセージとともに送信されるスケジューリング情報の中で時刻t3の無線リソースを適切に示すことによって、時刻t3(例:t3=t2+100ms)におけるさらなるCAMメッセージの送信用に無線リソースを予約する。新しいCAMメッセージは、予測されたように時刻t3より前に車両アプリケーションによって生成されて下位レイヤのバッファに到着する。車両UEは、このCAMメッセージを、予約されている無線リソースがそのCAMメッセージの送信に利用可能である時刻t3まで遅延させる。時刻t3においてCAMメッセージの送信が実行される。以降も、無線リソースを予約して周期的データを遅延させる同じプロセスが、継続的に実行される。
【0181】
なお、
図9に関連して説明したCAMメッセージの遅延は、周期的なCAMメッセージのみに限定することができる。したがって、それ以外のデータ(周期的データまたは非周期的データ)は、遅延無しに(すなわち送信可能な状態になったときにできる限り早い時点で)送信されることに留意されたい。特に、車両UEの車両アプリケーションは、送信される非周期的データ(DENMメッセージなど)も生成するものと例示的に想定する。したがって、この場合にも、PC5インタフェースを介しての送信用にモード2のリソース割当てを想定する。UEの下位レイヤがアプリケーションレイヤからDENMメッセージを受け取り、UEがそのDENMメッセージを送信する。DENMメッセージの送信は、無線リソースを選択するステップと、次いでDENMメッセージを、必要な場合には対応するスケジューリング情報とともに実際に送信するステップとを含む。
図10は簡単な図解を示す。この場合、時刻t5において非周期的データが送信可能な状態になり、直ちに送信される(送信するための無線リソースが直ちに利用可能である場合)。また、この例示的なケースでは、車両UEは、この非周期的データとともに送信されるスケジューリング情報を通じて無線リソースの予約を実行しない。なぜなら、データは非周期的であり、したがって以降の送信を予測できないためである。
【0182】
これに代えて、最初のDENMがトリガーされた後の特定の期間の間の、DENMメッセージの繰り返しを考慮するときには、無線リソースを予約するステップと、オプションとしてDENMメッセージの(1つまたは複数の)繰り返しを遅延させるステップとを、DENMの繰り返しの送信に(少なくとも一時的に)適用できる。
【0183】
全体として、車両UEの異なるタイプのスケジューリング挙動が予測される。特定の周期的データ(CAMメッセージなど)は、セミパーシステントに予約された無線リソースを使用して送信され(すなわち上述した無線リソースの予約を使用して、以降のCAMメッセージの送信を示し)、予約された無線リソースを使用して周期的データを送信できるように、必要に応じて遅延させる。これに対して、それ以外のデータ(非周期的データ(例:DENMメッセージ)または別の周期的データなど)については、対応するデータができる限り早く(すなわち遅延無しに)送信されるように、無線リソースの選択プロセスを直ちにトリガーすることができる(動的スケジューリングとも称される)。
【0184】
上述した実施形態は、周期的データの送信に焦点をあてており、周期的データを対象にリソース予約が実行され、周期的データは、予約された無線リソースの時刻まで遅延される。上記で簡潔に触れたように、車両UEは、特定のタイプの周期的データ(例:上述したCAMメッセージ)の最初の送信時に、その周期的データの優先順位および/または周期に固有な対応するサイドリンク論理チャネルを、車両UE自身で(すなわち基地局なしに)作成する。無線リソースの予約は、特定のデータ(すなわちCAMメッセージ)自体に依存するのではなく、サイドリンク論理チャネルに依存させることができる。したがって無線リソースの予約は、同じサイドリンク論理チャネルに属す(同じかまたは同程度の優先順位および/または周期を有する)全てのタイプのデータの送信のみに使用可能である。簡潔に言えば、CAMメッセージおよび別の類似する周期的データ(すなわちCAMメッセージ以外)を扱う特定のサイドリンク論理チャネルのデータは、予約された無線リソースを使用して送信することができる(この場合には遅延させる必要がありうる)。一方で、別のサイドリンク論理チャネルからの他のデータ(周期的データまたは非周期的データ)は、予約された無線リソースを使用できるべきではない。後者の他のデータは、例えば無線リソースを適切に選択または要求し、その選択/要求した無線リソースを使用してデータを送信することによって、個別に送信しなければならない。したがって、無線リソースの予約と、無線リソースが予約されている対象の周期的データの遅延は、論理チャネルに依存する。
【0185】
上述した実施形態の例示的な一実装形態では、送信されるトランスポートブロックを生成する目的で、予約された無線リソースを割り当てるためにサイドリンク論理チャネルの優先順位付け手順をどのように適用するかを変更する。背景技術のセクションで説明したように、サイドリンク論理チャネルの優先順位付け手順では、通常、送信待ち状態のデータを有する論理チャネル全てを考慮する。これに対して、予約された無線リソースが周期的データ(例:CAMメッセージ)の送信にのみ使用されるようにする目的で、無線リソースが予約されている特定の時刻に実行されるサイドリンクLCP(論理チャネル優先順位付け)手順を、無線リソースが事前に予約されている対象のサイドリンク論理チャネルのみが考慮されるように実行できる。他の全ての論理チャネルは、その時刻インスタンスにおいてはLCP手順から除外される。これにより、周期的データ(CAMメッセージ)が送信されることが、より高い優先順位のデータによって阻止されることが回避される。欠点としては、その時刻インスタンスにおいて、周期的データを送信するのに、予約されている無線リソースの全てが必要ではない場合、使用されない予約されている無線リソースが無駄になる。なぜなら、予約されている無線リソースは、そのサイドリンク論理チャネルに属すデータ以外のデータを送信する目的には使用できないためである。
【0186】
したがって、代替形態においては、無線リソースが予約されている対象の論理チャネルのデータが、最も高い優先順位を有するものとみなされるように、サイドリンクLCP手順を適合させることができる。これにより、予約されている無線リソースが、最初に、その特定の論理チャネルのデータを送信するために割り当てられる一方で、それと同時に、予約されている無線リソースが残る場合には他のデータも送信する柔軟性が維持されることが達成される。
【0187】
上述した実施形態のさらなる例示的な実装形態では、送信されるトランスポートブロックを生成する目的で、無線リソースを割り当てるためにサイドリンク論理チャネルの優先順位付け手順をどのように適用されるかを変更する。スケジューリング制御情報によって明示的に予約されていない(すなわち動的に選択される、または割り当てられるとも称する)無線リソースについては、送信側UEは、予約された無線リソースを使用することになっていない論理チャネルのみを考慮する。予約された無線リソースを使用するサイドリンク論理チャネルを考慮しないことによって、これらの「セミパーシステントな」サイドリンク論理チャネルのデータは、予約されたリソースまで遅延され、早い時点で送信されないことが保証される。
【0188】
上述した実施形態のさらなるバリエーションでは、以下の説明から明らかになるように、実施上の有利な細部を提供する。上述した
図9および
図10から明らかであるように、最初のCAMメッセージの送信後に次のCAMメッセージの送信用の無線リソースが事前に予約され、(送信の時点で)受信装置にすでに認識されているが、データ送信それぞれとともにスケジューリング情報が送信される。このように時刻インスタンスごとにスケジューリング情報を送信することによって、次の時刻インスタンスのための無線リソースを引き続き予約する(例:時刻t3を対象に時刻t2において予約する)ことが可能であるのみならず、スケジューリング情報のこの追加的な送信によって、前のスケジューリング情報を(すなわち時刻t2において)受信しなかった別の受信装置も、時刻t3において周期的データを正しく受信できる。
【0189】
さらには、
図10では、各時刻インスタンスにおいて周期的データが「早く」到着するものと想定されている。この早い到着は、予約されている無線リソースが利用可能である時刻まで送信を遅延させることによって「補正(compensated)」される。タイミングのオフセット/ジッタを考慮するためにオフセットを適切に設定することによって、周期的データが遅れて(すなわち無線リソースが予約されている時刻より後に)到着することを回避するべきである。別のケースでは、オフセットにもかかわらず、またはオフセットが適切に設定されていない、あるいはまったく設定されていない理由で、または何らかの別の理由(速度の変化など)に起因して、周期的データが、予測されているより遅れて(すなわち無線リソースが予約されている時刻より後に)到着することがある。これは
図11に示している。
図11は、周期的な無線リソースが時刻t4に予約されており、周期的データが時刻t5に到着する状況を示す。周期的データが遅れて到着するため、時刻t4における予約済みの無線リソースを使用することができない。さらに、車両UEは、このデータを遅延させることができず、遅れた周期的データは、送信可能な状態になったときにできる限り早い時点で送信する(時刻t5においてただちに送信されるものと例示的に想定する)。周期的データのこの動的な送信は、無線リソースを適切に選択する(モード2)ステップと、次いでこの選択された無線リソースを使用して周期的データを送信するステップとを含む。時刻t4のために予約された無線リソースは無駄になり、この無線リソースが時刻t4用に予約されていることを識別した別のエンティティによってもおそらく使用されない。遅延要件を満たす目的で、遅れた周期的データは、これを遅延させるのではなく、できる限り早く送信される。
【0190】
これに加えて、周期的データの時刻t5における遅れた動的な送信は、この場合も、後の時点(t6)のための無線リソースを適切に予約する目的に使用することができる。なぜなら、さらなる周期的データの送信を予測できるためである。さらなる無線リソースを予約するべき時刻t6を求める方法に関して、いくつかのオプションが存在する。例えば、無線リソースの予約を基本的に前と同じ周期で継続することができる(すなわちt3とt4の間の期間と、t4とt6の間の期間とが同じである)。この場合、スケジューリング情報の中の時刻の指示情報は、これに応じて計算する(t6=t4+周期1)べきである(
図11に示す)。これに代えて、前の無線リソースの予約が完全には適切な時刻に設定されなかった結果として、予約された無線リソースを使用する機会を逸したことを考慮して、新しい無線リソースの予約を、この逸したタイミングが考慮されるようにわずかに適合させることができる。したがって、例えば時刻t6=t5+周期1を対象に無線リソースを予約できる(
図11には示していない)。
【0191】
この実施形態のさらなるバリエーションによれば、UEは、周期的データが遅れて到着する、または早く到着することが、データの周期の変化を示すと想定できる。
図12に例示的に示したように、変化した周期2は、周期的データが遅れて到着したことが原因である。車両UEは、周期的データの以降の送信に、変化した周期を想定し、それに応じて、時刻t6=t5+周期2に無線リソースを予約する。この方式は、周期的データが著しく早く到着した場合にも同じように適用できる。オプションとして、
図12には示していないが、時刻t0におけるリソース割当てと同様に、オフセットを追加的に考慮できる。さらに、本実施形態のこのバリエーションは、周期的データの予測される到着と、周期的データが実際に到着したときとの間の差に依存させることもできる。例えば、この差がわずかである場合、車両UEは、この差が上位レイヤにおける周期的データの生成の「通常の」変動(すなわちジッタ)の範囲内であると想定できる。これに対して、差が特定の上限より大きい場合、車両UEは、周期的データの周期が(例えば車両の速度の変化に起因して)変化したものと想定できる。
【0192】
上述した(1つまたは複数の)実施形態の別のバリエーションによれば、周期的データを遅延させることのできる最大時間を定義できる。このような最大時間は、例えば上位レイヤによって(PPPPと同様に)周期的データとともに(例えば優先順位の指示情報(PPPP)とは個別に、または一緒に)示すことができる。オプションとして、最大時間は、一度だけ(例えば周期的データを初めて生成してそれを下位レイヤに転送するときに)示すことができる。これに代えて、最大遅延時間は、特定の周期的データによって与えられる特定の遅延要件から決定できる、または、車両UEにおいて別の方法で決定できる。いずれの場合にも、車両UEは、上述した最大遅延時間よりも遅延が小さい(または等しい)場合にのみ、周期的データを遅延させることを決定する。遅延が大きい(例えば最大遅延時間に等しいかまたはそれより大きい)場合には、車両UEは、周期的データを遅延させずに、ただちに送信する。したがって、車両UEは、できる限り早く送信を実行するため別の無線リソースを選択する。
【0193】
本実施形態のさらに別のバリエーションによれば、下位レイヤは、アプリケーションからのパケットが到着した(例えばPDCPバッファに到着した)とき、そのパケットとともにアプリケーションレイヤによって提供される対応する最大遅延時間値に設定された値を用いてタイマーを起動する。送信装置は、タイマーが切れたとき、対応するパケットを破棄する。なぜなら、配信の最大許容時間を超えたためである。
【0194】
例えば、上述した
図9および
図10(無線リソースが予約されている時刻よりわずかに前に周期的データが到着する)においては、上述した(1つまたは複数の)実施形態によって課せられる遅延が、最大遅延時間より小さいと想定できる。これに対して、周期的データがより早い時点において到着する場合、課せられる遅延が大きすぎることがある。したがって、車両UEは、予約された無線リソースを待つのではなく、その早く到着した周期的データを直ちに送信することを決定できる。
【0195】
同様に、2つ以上の時刻インスタンスを対象とする無線リソースの予約を想定するときには、データが遅れて(例えば無線リソースが予約されている時刻よりもわずかに後に(
図11を参照))到着する場合、その遅れた周期的データは多くの場合、直ちに送信するべきである。なぜなら、次の時刻インスタンスを対象として予約されている無線リソースまで遅延させると大きな遅延となり、次の予約済み無線リソースが周期的データの次の送信に使用されるためである。
【0196】
さらには、最大遅延時間を超えたことを、周期的データの周期が変化したことの示唆として使用することができる。したがって、変化した新しい周期を想定するように車両UEをトリガーすることができ、以降のデータ送信のための無線リソースの予約はその周期に基づいて実行される。これに代えて、堅牢性を保証する目的で、車両UEが周期の変化を想定するためには、その前に特定の回数だけ最大遅延時間を超えなければならず、それまで車両UEは、引き続き「古い」周期に基づいて無線リソースを予約する。
【0197】
ここまでは、詳しく説明することなく、無線リソースの予約が、CAMメッセージを送信するために車両UEによって使用されると想定している。車両UEが、上述した実施形態を周期的データに対して実行するか否か、あるいはどの周期的データに対して実行するかは、以下の例の1つに従って制御できる。一般的に(車両)UEは、CAMメッセージを、例えば、PC5インタフェースを通じたそのCAMメッセージの送信に適用される優先順位の扱いを定義するPPPP(ProSeパケットごとの優先順位)とともに、上位のアプリケーションレイヤから受け取る(PPPPに関するさらなる詳細については背景技術のセクションも参照)。UEのアクセス層は、このようなデータを初めて受け取ると、上述したように、PPPPが関連付けられるCAMメッセージのための対応するサイドリンク論理チャネルを設定する。以降に、同じPPPPとともに受け取った(および同じ送信元/宛先ペアまたはアプリケーションを対象とする)データは、この同じサイドリンク論理チャネルによって扱われる。
【0198】
さらには、車両UEのアクセス層は、上位レイヤからのCAMメッセージの周期についても認識する。例えば、周期情報を、一例においては、例えば追加の値を提供することによってPPPPの中に符号化することができる。したがって、UEは、データの周期を優先順位の指示情報から直接認識する。これに代えて、個別の周期指示情報を、データとともに上位レイヤから提供できる。いずれの場合にも、UEの下位レイヤは、上位レイヤから受け取るデータの周期を求めることができる。明示的な指示情報を提供する代わりに、車両UEの下位レイヤ(例:MACレイヤまたはPDCPレイヤ)が、レイヤ2バッファ(例:PDCPバッファ)へのパケットの到着に基づいてデータの周期を認識することもできる。ただし、パケットの到着に基づくデータの周期は、時間をかけて初めてUEに認識される。例えば、推定される周期は、考慮されるサイドリンク論理チャネルの、前のN(整数)個のパケットがPDCPレイヤ/レイヤ2に到着する時刻に基づいて、線形的に外挿される。これに対して、アプリケーションレイヤがアクセス層(UEの下位レイヤ)に周期を通知する場合には、車両UEはこの情報を即座に認識し(いくつかのパケットを受け取るまで待つ必要がない)、無線予約手順にこの情報を使用できる。
【0199】
さらには、車両UEが、上述したセミパーシステントなリソース割当てを周期的データに適用するか否かは、例えばUEの実装に委ねることができる、または、基地局によって(例えば一般にはシステム情報またはRRCシグナリングを使用して)制御できる、またはProSe機能またはアプリケーションレイヤによって制御できる。
【0200】
いずれの場合にも、車両UEは、特定のサイドリンク論理チャネルの周期的データの送信にリソースの予約を適用するか否かを決定する。
【0201】
車両UEは、2つ以上の周期的なサイドリンク論理チャネルを有することができる。例えば、上述したCAMメッセージ以外に、車両UEは例えばeコール(e-Call)をサポートすることもできる。eコールは、(音声)データの周期的な送信が発生することにおいてボイスオーバーIP(VoIP)に似ている。将来的には、より多くのタイプの周期的データがサポートされうる。したがって、車両UEは、これらの周期的なサイドリンク論理チャネルそれぞれに、無線リソースの予約メカニズムを適用できる。一方で、その場合に生じうる欠点として、多くの無線リソースが各車両UEによって予約される。
【0202】
上述した実施形態のバリエーションによれば、多くの無線リソースが1つの車両UEによって予約されることを回避するため、並行する無線リソース予約の最大数を予測できる。したがって、特定の数の同時に存在する「SPS」サイドリンク論理チャネルのみが許可されるように、車両UEを設定できる。したがって、残りの周期的なサイドリンク論理チャネルについては、通常の動的なスケジューリングが実行される。したがって、車両UEは、データが送信可能な状態になった後、できる限り早く(すなわちリソースを予約してデータを遅延させることなく)無線リソースを選択/要求して送信を実行する。
【0203】
同時に存在する論理チャネルの最大数は、3GPP標準規格の中で決めておく、もしくは装置において事前に設定する、または、基地局によって(例えばシステム情報またはRRCメッセージを使用することによって)柔軟に設定できる。これに代えて、ProSe機能またはアプリケーションレイヤが、同時に使用することが車両装置に許可される予約の最大数を設定できる。
【0204】
本実施形態のさらなるバリエーションによれば、無線リソースの予約では、特定の(例えば特定のサイドリンク論理チャネルの)周期的データのための無線リソースのみを予約する。特に、本実施形態について上述したように、車両UEは、最初の送信においてサイドリンク論理チャネルの周期的データを送信し、それと同時に、後の時点のための(同じかまたは別の)リソースを予約する。1つのバリエーションにおいては、予約された無線リソースは、前の送信のSCIによって無線リソースが予約された対象の特定のサイドリンク論理チャネルのデータを送信する目的にのみ使用できる。しかしながら、これらの無線リソースを排他的に予約することによって、無線リソースが必ずしも使用されないことがある。例を挙げれば、サイドリンク論理チャネルのデータを受け取るタイミングが遅すぎて、予約された無線リソースを使用できない場合である。したがって、別のバリエーションにおいては、予約された無線リソースは特定の論理チャネルのデータ(例:CAMメッセージ)を送信するために使用されることが好ましいが、予定の時刻に周期的データが送信可能な状態ではない場合、UEは、その予約された無線リソースを別のデータを送信するために使用することが許可される。
【0205】
上記の実施形態においては、1つの論理チャネルのデータのためにのみ無線リソースが予約されるが(ProSeのLCP手順において論理チャネルの多重化がサポートされているため)、車両UEが1つのトランスポートブロックの中で2つ以上のサイドリンク論理チャネルを送信し、これらのサイドリンク論理チャネルを対象とする以降に使用するための無線リソースを予約することも可能である。予約された無線リソースは、一般的には、前の送信のSCIによって無線リソースが予約された対象の特定の1つまたは複数のサイドリンク論理チャネルのデータを送信するためにのみ使用できる。さらには、車両UEは、いくつかの論理チャネルの周期が同じである場合、これらの論理チャネルのデータのための無線リソースのみを予約する。
【0206】
上記の実施形態のさらなるバリエーションによれば、UEの本挙動では、動作中に起こりうる周期的データ(例:CAMメッセージ)の周期の変化も考慮する。前述したように、上位レイヤにおける周期的データの生成は、完全には周期的ではなく、わずかに変動し、この場合、周期自体は変化しない。一方で、例えば車両の動態(速度、角度、方向など)の変化に起因して、周期が著しく変化することがある。1つのバリエーションによれば、周期的データを生成する上位のアプリケーションレイヤは、周期的データが生成される周期が変化するときに下位レイヤに通知できる。この通知は、例えば、周期的データとともに上位レイヤによって転送される対応する周期指示情報を使用することによって、実施することができる。周期指示情報は、周期が変化するときに単純に1つの異なる値を含む。したがって、周期指示情報を受け取る、車両UEの(1つまたは複数の)下位レイヤは、変化する周期を認識する。これに代えて、(例えば
図12に関連して前に説明したように)データの変化した到着タイミングから、下位レイヤによって周期の変化を推測することもできる。
【0207】
本実施形態の1つのバリエーションでは、周期の変化を認識した時点で、たとえ無線リソースがすでに予約されている場合にも、その周期的データが直ちに送信される。なぜなら、予約されている無線リソースは、周期的データの変化した周期にもはや従わないためである。したがって、車両UEは、データが送信可能な状態になった後、直ちに無線リソースの選択を開始し、(利用可能な無線リソースに応じて)できる限り早く、選択された無線リソースを使用して周期的データを送信する。周期が変化した後の周期的データのこの最初の送信に基づいて、以降の1つまたは複数の送信のための無線リソースが、変化した周期を考慮して予約され、それに対応してスケジューリング情報の中で無線リソースの予約を示す。こうして無線リソースの予約を、変化する周期に適合させることができる。
【0208】
さらに、CAMメッセージの内容(サイズ)が変化することがある。この場合、予約された無線リソースが、CAMメッセージ全体を送信するのに十分ではないことがある。周期の変化とともにサイズの変化が起こるときには、車両UEは、動的なリソース割当てを実行し、十分な量のリソースと適切な周期を最初に選択する機会を有する。これに対して、周期の変化なしにCAMメッセージのサイズが大きくなる場合、車両UEは、同様にリソース予約を無視して動的なリソース割当てを実行し、選択されたリソースに従ってCAMメッセージを送信する。これと同時に、スケジューリング情報の中に適切な指示情報を含めることによって、新たに割り当てられた無線リソースが、以降の1つまたは複数の時刻インスタンスにおいて同様に予約される。これによって、以降の無線リソースは、より大きいCAMメッセージを送信するのにも十分であることが確保される。
【0209】
さらなるバリエーションによれば、前に行われた無線リソースの予約を破棄することが可能である。例えば、上述したように、以降の無線リソースの予約が使用されないことをUEがすでに認識している場合、前に行われた無線リソースの予約の破棄をブロードキャストすることが可能である。これは例えば、破棄するべき無線リソースを、「破棄」に設定された専用フィールドによって示すSCI(スケジューリング制御情報)を送ることによって行うことができる。この専用フィールドは追加のビット/フラグとすることができる。または、これに代えて、SCIに含まれるフィールドの事前定義される特定の組み合わせを使用して、前に予約された無線リソースの「破棄」を示すことができる。
【0210】
本実施形態の上の例示的な説明においては、予約されたリソースが以降の時刻インスタンスにおいて利用可能である(すなわちそのようなリソースを別のUEが予約していない)ものと想定した。しかしながら、UEは、予約がもはや有効ではない時刻インスタンスでは、わずかに異なる周期で新しい無線リソースを選択しなければならないことがある(再選択とも称する)。したがって、(別のUEによる予約に起因して利用可能なリソースが存在しない場合には)周期は一定ではなく、長い期間の間にはわずかに変化することが起こりうる。
【0211】
上記の実施形態においては、車両UEが主としてモード2のリソース割当てを使用するものと想定してきた。これに対して車両UEは、eNodeBからのリソースを要求するため、モード1のリソース割当てをサポートすることもできる。モード1においてPC5インタフェースを介してのProSeデータの送信用にセミパーシステントなリソース割当てを実施する目的で、Uuインタフェースを介してのセミパーシステントな割当てのために現在予測されている方法に類似する方法を使用できる。したがって車両UEが、PC5インタフェースを介して周期的データを送信するためのリソースを要求するとき、eNodeBは、セミパーシステントなリソース割当てを使用することを決定できる。PC5インタフェースを介して周期的データを送信するために使用可能である無線リソースを周期的に割り当てる対応するセミパーシステントグラントを、車両UEに提供できる。オプションとして、セミパーシステントグラントは、CAMメッセージの生成のジッタ/オフセットをすでに考慮していることができる。
【0212】
さらなる実施形態によれば、特定の論理チャネルについては、スケジューリング要求(それに続くバッファ状態報告)のトリガーが抑制される。特に、たとえセミパーシステントな無線リソースが利用可能ではない時点において、その特定の論理チャネルの周期的データが利用可能になるときにも、車両UEは、eNodeBからの無線リソースを動的に要求するためのスケジューリング要求および対応するバッファ状態報告の送信のいずれもトリガーしない。代わりに、送信可能な状態になる周期的データを、セミパーシステントなリソースが再び利用可能になるさらに後の時刻インスタンスまで遅延させる。すなわち、車両UEは、周期的データを送信するために新しい動的なグラントを要求するのではなく、セミパーシステントに割り当てられるリソースを使用する。
【0213】
PC5インタフェースを通じたV2Xメッセージの送信では、1対全(one−to−all)のProSe直接通信が採用される。「1対全のProSe直接通信」はコネクションレスであるため、eNBのスケジューラは、SPSの設定/割当てを確立/構成するときにUEによって支援される。より具体的には、車両UEは、必要な周期およびオフセットを示すことによって、SPSを設定するための支援情報をeNBに提供できる。eNodeBは、変化する周期に適切なセミパーシステントな無線リソースを決定して車両UEに割り当てる。さらに、例えば車両の動態の変化に起因する、車両の周期的データ(例:CAMメッセージ)の様々な変化する周期を考慮する目的で、車両UEは、周期の変化をeNodeBに通知できる。
【0214】
本実施形態のさらなるバリエーションによれば、特定の論理チャネルに対してUEがSR/BSRをトリガーすることを抑制するべきである新しいUEの挙動または規則が導入される。より具体的には、SPSの設定のためにUEがUE支援情報をeNBに提供した論理チャネルのデータが到着したことによってトリガーされるバッファ状態報告(BSR)では、それによってスケジューリング要求(SR)がトリガーされない。
【0215】
これに代えて、セミパーシステントに割り当てられたリソース(例えばSPS RNTIによってスクランブルされたDCI(ダウンリンク制御情報)によって割り当てられた無線リソース)で送信される、サイドリンク論理チャネルのデータについては、車両UEは、データの到着によるバッファ状態報告(BSR)のトリガーに起因するスケジューリング要求(SR)をトリガーしない。
【0216】
[ハードウェアおよびソフトウェアによる本開示の実施]
別の例示的な実施形態は、上述した様々な実施形態を、ハードウェア、ソフトウェア、またはハードウェアと連携したソフトウェアを使用して実施することに関する。これに関連して、ユーザ端末(移動端末)を提供する。本ユーザ端末は、本明細書に記載されている方法を実行するように構成されており、これらの方法に適切に関与する対応するエンティティ(受信機、送信機、プロセッサなど)を含む。
【0217】
様々な実施形態は、コンピューティングデバイス(プロセッサ)を使用して実施または実行され得るものとさらに認識される。コンピューティングデバイスまたはプロセッサは、例えば、汎用プロセッサ、デジタル信号プロセッサ(DSP:Digital Signal Processor)、特定用途向け集積回路(ASIC:Application Specific Integrated Circuit)、フィールドプログラマブルゲートアレイ(FPGA:Field Programmable Gate Array)、または、その他プログラマブルロジックデバイスなどである。様々な実施形態は、これらのデバイスの組み合わせによっても実行または具体化され得る。特に、上述した各実施形態の説明に用いた各機能ブロックは、集積回路であるLSIによって実施できる。これらの機能ブロックは、個々のチップから構成されてもよいし、機能ブロックの一部または全てを含むように一つのチップから構成されてもよい。これらのチップは、自身に結合されているデータの入力と出力を含むことができる。LSIは、集積度の違いにより、IC、システムLSI、スーパーLSI、またはウルトラLSIと呼称される。しかしながら、集積回路を実施する技術は、LSIに限るものではなく、専用回路または汎用プロセッサを使用することによって達成できる。さらには、LSI製造後にプログラムすることが可能なFPGA、またはLSI内部の回路セルの接続または設定を再設定可能なリコンフィギャラブル・プロセッサを利用してもよい。
【0218】
さらに、様々な実施形態は、ソフトウェアモジュールによっても実施され得る。これらのソフトウェアモジュールは、プロセッサによって実行され、または、ハードウェアにおいて直接実行される。また、ソフトウェアモジュールとハードウェア実装の組み合わせも可能である。ソフトウェアモジュールは、任意の種類のコンピュータ可読記憶媒体、例えば、RAMやEPROM、EEPROM、フラッシュメモリ、レジスタ、ハードディスク、CD−ROM、DVDなどに格納され得る。さらには、複数の異なる実施形態の個々の特徴は、個々に、または任意の組み合わせにおいて、別の実施形態の主題できることに留意されたい。
【0219】
具体的な実施形態に示した本開示には、広義に記載されている本発明の概念または範囲から逸脱することなく、様々な変更および/または修正を行うことができることが、当業者には理解されるであろう。したがって、本明細書に示した実施形態は、あらゆる点において例示的であり、本発明を制限するものではないものとみなされる。