[LTE(Long Term Evolution)]
WCDMA(登録商標)無線アクセス技術をベースとする第3世代移動通信システム(3G)は、世界中で広範な規模で配備されつつある。この技術を機能強化または発展・進化させるうえでの最初のステップとして、高速ダウンリンクパケットアクセス(HSDPA:High-Speed Downlink Packet Access)と、エンハンストアップリンク(高速アップリンクパケットアクセス(HSUPA:High-Speed Uplink Packet Access)とも称する)とが導入され、これにより、極めて競争力の高い無線アクセス技術が提供されている。
ユーザからのますます増大する需要に対応し、新しい無線アクセス技術に対する競争力を確保する目的で、3GPPは、LTE(Long Term Evolution)と称される新しい移動通信システムを導入した。LTEは、今後10年間にわたり、データおよびメディアの高速伝送ならびに大容量の音声サポートに要求されるキャリアを提供するように設計されている。高いビットレートを提供する能力は、LTEにおける重要な方策である。
LTE(Long Term Evolution)に関する作業項目(WI:working item)の仕様は、E−UTRA(Evolved UMTS Terrestrial Radio Access)およびE−UTRAN(Evolved UMTS Terrestrial Radio Access Network)と称され、最終的にリリース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)の送信出力が限られていることを考えれば、ピークデータレートを向上させるよりも広いカバレッジエリアを提供することが優先されるからである。LTEリリース8/9では、数多くの主要なパケット無線アクセス技術(例えば、MIMO(Multiple-Input Multiple-Output)チャネル伝送技術)が採用され、高効率の制御シグナリング構造が達成されている。
[LTEのアーキテクチャ]
図1は、LTEの全体的なアーキテクチャを示し、図2は、E−UTRANのアーキテクチャをより詳細に示している。E−UTRANはeNodeBから構成され、eNodeBは、ユーザ機器(UE:User Equipment)に向かう、E−UTRAのユーザプレーン(PDCP/RLC/MAC/PHY)プロトコルおよび制御プレーン(RRC)プロトコルを終端させる。eNodeB(eNB)は、物理(PHY)レイヤ、媒体アクセス制御(MAC:Medium Access Control)レイヤ、無線リンク制御(RLC:Radio Link Control)レイヤ、およびパケットデータ制御プロトコル(PDCP:Packet Data Control Protocol)レイヤ(これらのレイヤはユーザプレーンのヘッダ圧縮および暗号化の機能を含む)をホストする。eNBは、制御プレーンに対応する無線リソース制御(RRC:Radio Resource Control)機能も提供する。eNBは、無線リソース管理、アドミッション制御、スケジューリング、交渉によるアップリンクサービス品質(QoS:Quality of Service)の実施、セル情報のブロードキャスト、ユーザプレーンデータおよび制御プレーンデータの暗号化/復号化、ダウンリンク/アップリンクのユーザプレーンパケットヘッダの圧縮/復元など、多くの機能を実行する。複数のeNodeBは、X2インタフェースによって互いに接続されている。
また、複数のeNodeBは、S1インタフェースによってEPC(Evolved Packet Core)、より具体的には、S1−MMEによってMME(Mobility Management Entity:移動管理エンティティ)、S1−Uによってサービングゲートウェイ(SGW:Serving Gateway)に接続されている。S1インタフェースは、MME/サービングゲートウェイとeNodeBとの間の多対多関係をサポートする。SGWは、ユーザデータパケットをルーティングして転送する一方で、eNodeB間のハンドオーバー時におけるユーザプレーンのモビリティアンカーとして機能し、さらに、LTEと別の3GPP技術との間のモビリティのためのアンカー(S4インタフェースを終端させ、2G/3GシステムとPDN GWとの間でトラフィックを中継する)として機能する。SGWは、アイドル状態のユーザ機器に対しては、ダウンリンクデータ経路を終端させ、そのユーザ機器へのダウンリンクデータが到着したときにページングをトリガーする。SGWは、ユーザ機器のコンテキスト(例えばIPベアラサービスのパラメータ、ネットワーク内部ルーティング情報)を管理および格納する。さらに、SGWは、合法傍受(lawful interception)の場合にユーザトラフィックの複製を実行する。
MMEは、LTEのアクセスネットワークの主要な制御ノードである。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インタフェースを終端させる。
[LTEにおけるコンポーネントキャリア構造]
3GPP LTEシステムのダウンリンクコンポーネントキャリアは、いわゆるサブフレームにおける時間−周波数領域でさらに分割される。3GPP LTEで、各サブフレームは、図3に示すように2つのダウンリンクスロットに分割され、そこにおいて、第1のダウンリンクスロットは、第1のOFDMシンボル内の制御チャネル領域(PDCCH領域)を備える。各サブフレームは、時間領域内の所与の数のOFDMシンボルで構成され(3GPP LTE(リリース8)では12個または14個のOFDMシンボル)、各OFDMシンボルはコンポーネントキャリアの帯域幅全体に広がる。したがって、OFDMシンボルは、各々、図4にも示すように、NDL RB×NRB sc個のそれぞれのサブキャリアで送信されるいくつかの変調シンボルで構成される。
例えば3GPP LTEにおいて使用されるようなOFDMを使用する、マルチキャリア通信システムを想定すると、スケジューラによって割り当てることができるリソースの最小単位は、1つの「リソースブロック」である。物理リソースブロック(PRB:Physical Resource Block)は、図4に例示されているように、時間領域におけるNDL symb個の連続するOFDMシンボル(例:7個のOFDMシンボル)と、周波数領域におけるNRB sc本の連続するサブキャリア(例:コンポーネントキャリアの12本のサブキャリア)として定義される。したがって、3GPP LTE(リリース8)では、物理リソースブロックは、時間領域における1つのスロットおよび周波数領域における180kHzに対応する、NDL symb×NRB sc個のリソースエレメントで構成される(ダウンリンクリソースグリッドについてさらに詳しくは、例えば、3GPPのウェブサイトで入手可能であり、参照により本明細書に組み込まれている、非特許文献1の6.2節を参照)。
1個のサブフレームは2つのスロットからなり、したがって、いわゆる「通常の」サイクリックプレフィックス(normal CP)が使用されているときにはサブフレームに14個のOFDMシンボルが存在し、いわゆる「拡張」サイクリックプレフィックス(extended CP)が使用されているときにはサブフレームに12個のOFDMシンボルが存在する。専門用語として、以下では、サブフレーム全体にわたる、同一のNRB sc本の連続するサブキャリアに等しい時間−周波数リソースを、「リソースブロックペア」、または同じ意味で「RBペア」または「PRB(物理リソースブロック)ペア」と称する。
用語「コンポーネントキャリア(Component Carrier)」は、周波数領域におけるいくつかのリソースブロックの組合せを意味する。LTEの将来のリリースでは、「コンポーネントキャリア」という用語はもはや使用されず、その代わりに、その専門用語はダウンリンクおよびオプションでアップリンクリソースの組合せを示す「セル」に変更される。ダウンリンクリソースのキャリア周波数とアップリンクリソースのキャリア周波数との間のリンク付けは、ダウンリンクリソースで送信されるシステム情報において指示される。
コンポーネントキャリアの構造の同様の想定は、以降のリリースにも適用される。
[より広い帯域幅をサポートするためのLTE−Aにおけるキャリアアグリゲーション]
世界無線通信会議2007(WRC−07)において、IMT−Advancedの周波数スペクトルが決定された。IMT−Advancedのための全体的な周波数スペクトルは決定されたが、実際に利用可能な周波数帯域幅は、地域や国によって異なる。しかしながら、利用可能な周波数スペクトルのアウトラインの決定に続いて、3GPPにおいて無線インタフェースの標準化が開始された。3GPPでは、3GPP TSG RAN #39会合において、「Further Advancements for E-UTRA (LTE-Advanced)」に関する検討項目(Study Item)の記述が承認された。この検討項目は、E−UTRAを進化・発展させるうえで(例えば、IMT−Advancedの要求条件を満たすために)考慮すべき技術要素をカバーしている。
LTEアドバンストシステムがサポートすることができる帯域幅は100MHzであり、一方、LTEシステムは20MHzのみをサポートすることができる。今日、無線スペクトルの欠如がワイヤレスネットワークの開発のボトルネックになり、結果として、LTEアドバンストシステムのために十分広いスペクトル帯域を見つけることは困難である。したがって、より広い無線スペクトル帯域を獲得するための方法を見つけることは急務であり、ここにおいて、可能性のある答えは、キャリアアグリゲーション機能である。
キャリアアグリゲーションでは、最大で100MHzの広い送信帯域幅をサポートする目的で、2つ以上のコンポーネントキャリア(CC)がアグリゲートされる。LTE−Advancedシステムでは、LTEシステムにおけるいくつかのセルが、より広い1つのチャネルにアグリゲートされ、このチャネルは、たとえLTEにおけるこれらのセルが異なる周波数帯域である場合でも100MHzに対して十分に広い。
アグリゲートされるコンポーネントキャリアの数がアップリンクとダウンリンクとで少なくとも同じであるとき、すべてのコンポーネントキャリアをLTEリリース8/9互換として設定することができる。ユーザ機器によってアグリゲートされるすべてのコンポーネントキャリアが必ずしもLTEリリース8/9互換でなくてよい。リリース8/9のユーザ機器がコンポーネントキャリアにキャンプオンすることを回避するため、既存のメカニズム(例:バーリング(barring))を使用することができる。
ユーザ機器は、自身の能力に応じて1つまたは複数のコンポーネントキャリア(複数のサービングセルに対応する)を同時に受信または送信することができる。キャリアアグリゲーションのための受信能力もしくは送信能力またはその両方を備えた、LTE−Aリリース10のユーザ機器は、複数のサービングセル上で同時に受信する、もしくは送信する、またはその両方を行うことができ、これに対して、LTEリリース8/9のユーザ機器は、コンポーネントキャリアの構造がリリース8/9の仕様に従う場合、1つのみのサービングセル上で受信および送信を行うことができる。
キャリアアグリゲーションは、連続するコンポーネントキャリアおよび不連続なコンポーネントキャリアの両方においてサポートされ、この場合、コンポーネントキャリアそれぞれは、3GPP LTE(リリース8/9)の計算方式を使用するとき周波数領域における最大110個のリソースブロックに制限される。
同じeNodeB(基地局)から送信される、場合によってはアップリンクおよびダウンリンクにおいて異なる帯域幅の異なる数のコンポーネントキャリアをアグリゲートするように、3GPP LTE−A(リリース10)互換のユーザ機器を構成することが可能である。設定することのできるダウンリンクコンポーネントキャリアの数は、ユーザ機器のダウンリンクのアグリゲーション能力に依存する。逆に、設定することのできるアップリンクコンポーネントキャリアの数は、ユーザ機器のアップリンクのアグリゲーション能力に依存する。ダウンリンクコンポーネントキャリアよりもアップリンクコンポーネントキャリアが多くなるように移動端末を構成することはできない。
一般的なTDD配備では、コンポーネントキャリアの数および各コンポーネントキャリアの帯域幅は、アップリンクとダウンリンクとで同じである。同じeNodeBから送信されるコンポーネントキャリアは、必ずしも同じカバレッジを提供する必要はない。
連続的にアグリゲートされるコンポーネントキャリアの中心周波数の間隔は、300kHzの倍数である。これは、3GPP LTE(リリース8/9)の100kHzの周波数ラスターとの互換性を保つと同時に、15kHz間隔のサブキャリアの直交性を維持するためである。アグリゲーションのシナリオによっては、連続するコンポーネントキャリアの間に少数の使用されないサブキャリアを挿入することによって、n×300kHzの間隔あけを容易にすることができる。
複数のキャリアをアグリゲートする影響は、MACレイヤに及ぶのみである。MACレイヤには、アップリンクおよびダウンリンクの両方において、アグリゲートされるコンポーネントキャリアごとに1つのHARQエンティティが要求される。コンポーネントキャリアあたりのトランスポートブロックは最大1個である(アップリンクにおけるSU−MIMOを使用しない場合)。トランスポートブロックおよびそのHARQ再送信(発生時)は、同じコンポーネントキャリアにマッピングする必要がある。
図5および図6は、それぞれ、ダウンリンクおよびアップリンクにおける、キャリアアグリゲーションが設定されたL2レイヤ構造を示している。
キャリアアグリゲーションが設定されているとき、移動端末はネットワークとの1つのRRC接続を有するのみである。RRC接続の確立/再確立時には、LTEリリース8/9と同様に、1つのセルが、セキュリティ入力(1つのECGI、1つのPCI、および1つのARFCN)と、非アクセス層(NAS)モビリティ情報(例:TAI)とを提供する。RRC接続の確立/再確立の後、そのセルに対応するコンポーネントキャリアをダウンリンクプライマリセル(PCell)と称する。接続状態では、ユーザ機器あたりつねに1つのダウンリンクPCell(DL PCell)および1つのアップリンクPCell(UL PCell)が設定される。設定されているコンポーネントキャリアのセットの中のプライマリセル以外のセルを、セカンダリセル(SCell)と称し、SCellのキャリアは、ダウンリンクセカンダリコンポーネントキャリア(DL SCC)およびアップリンクセカンダリコンポーネントキャリア(UL SCC)である。
コンポーネントキャリアの設定および再設定、ならびに追加および削除は、RRCによって実行することができる。アクティブ化および非アクティブ化は、MAC制御要素を介して行われる。LTE内ハンドオーバー時、RRCによって、ターゲットセルで使用するためのSCellを追加、削除、または再設定することもできる。新しいSCellを追加するときには、(LTEリリース8/9におけるハンドオーバー時と同様に)専用のRRCシグナリングを使用して、SCellのシステム情報(この情報は送信/受信に必要である)を送る。
キャリアアグリゲーションを使用するようにユーザ機器が構成されているとき、アップリンクコンポーネントキャリアとダウンリンクコンポーネントキャリアの一対が常にアクティブである。この対のうちのダウンリンクコンポーネントキャリアは、「ダウンリンクアンカーキャリア」と称されることもある。同じことはアップリンクについてもあてはまる。
キャリアアグリゲーションが設定されているとき、同時に複数のコンポーネントキャリアについてユーザ機器をスケジューリングすることができるが、一度に行うことのできるランダムアクセス手順は最大で1つである。クロスキャリアスケジューリング(cross-carrier scheduling)では、コンポーネントキャリアのPDCCHによって別のコンポーネントキャリアのリソースをスケジューリングすることができる。この目的のため、それぞれのDCIフォーマットにコンポーネントキャリア識別フィールド(「CIF」と称する)が導入されている。
クロスキャリアスケジューリングが行われていないときには、アップリンクコンポーネントキャリアとダウンリンクコンポーネントキャリアとをリンクすることによって、グラントが適用されるアップリンクコンポーネントキャリアを識別することができる。アップリンクコンポーネントキャリアへのダウンリンクコンポーネントキャリアのリンクは、必ずしも1対1である必要はない。言い換えれば、同じアップリンクコンポーネントキャリアに複数のダウンリンクコンポーネントキャリアをリンクすることができる。一方で、1つのダウンリンクコンポーネントキャリアは、1つのアップリンクコンポーネントキャリアのみにリンクすることができる。
[LTEにおけるRRC状態]
LTEは、2つのみの主状態、すなわち「RRC_IDLE」および「RRC_CONNECTED」に基づく。
RRC_IDLE状態では、無線は有効ではないが、ネットワークによってIDが割り当てられて追跡されている。より具体的には、RRC_IDLEモードの移動端末は、セルの選択および再選択を実行する(言い換えれば、キャンプオンするセルを決定する)。セルの(再)選択プロセスでは、適用可能な無線アクセス技術(RAT:Radio Access Technology)それぞれの適用可能な各周波数の優先順位、無線リンクの品質、およびセルのステータス(すなわちセルが禁止または予約されているか)が考慮される。RRC_IDLEモードの移動端末は、ページングチャネルを監視して着呼を検出し、さらにシステム情報を取得する。システム情報は、主として、セルの(再)選択プロセスと移動端末がネットワークにアクセスする方法とをネットワーク(E−UTRAN)が制御するためのパラメータからなる。RRCは、RRC_IDLE状態にある移動端末に適用される制御シグナリング(すなわちページングおよびシステム情報)を指定する。RRC_IDLE状態にある移動端末の挙動については、非特許文献2の4節「General description of Idle mode」(参照によって本明細書に組み込まれている)にさらに詳細に規定されている。
RRC_CONNECTED状態では、移動端末は、eNodeBとのアクティブな無線動作を有する。E−UTRANでは、共有データチャネルを介して(ユニキャスト)データを伝送することができるように、移動端末に無線リソースが割り当てられる。この動作をサポートするため、移動端末は、時間および周波数の共有送信リソースの動的な割当てを示すために使用される対応する制御チャネルを監視する。移動端末は、E−UTRANが移動端末にとって最適なセルを選択できるように、自身のバッファ状態およびダウンリンクチャネル品質の報告と、隣接セルの測定情報とを、ネットワークに提供する。これらの測定報告には、別の周波数や無線アクセス技術(RAT)を使用するセルが含まれる。さらに、ユーザ機器は、送信チャネルを使用するために要求される情報から主として構成されるシステム情報を受信する。RRC_CONNECTED状態のユーザ機器は、自身のバッテリの寿命を延ばすため、不連続受信(DRX)サイクルを使用するように構成することができる。RRCとは、RRC_CONNECTED状態のユーザ機器の挙動をE−UTRANが制御するためのプロトコルである。
RRCプロトコルにおける移動端末のさまざまな機能(接続モードを含む)については、非特許文献3の4節「Functions」(参照によって本明細書に組み込まれている)に記載されている。
[LTEにおけるアップリンクアクセス方式]
アップリンク送信では、カバレッジを最大にするため、ユーザ端末による電力効率の高い送信が必要である。E−UTRAのアップリンク送信方式としては、シングルキャリア伝送と、動的な帯域幅割当てのFDMAとを組み合わせた方式が選択されている。シングルキャリア伝送が選択された主たる理由は、マルチキャリア信号(OFDMA)と比較して、ピーク対平均電力比(PAPR:Peak to Average Power Ratio)が低く、これに対応して電力増幅器の効率が改善され、カバレッジの向上が見込まれるためである(与えられる端末ピーク電力に対してデータレートが高い)。各時間間隔において、NodeBは、ユーザデータを送信するための固有の時間/周波数リソースをユーザに割り当て、これによってセル内の直交性が確保される。アップリンクにおける直交多元接続によって、セル内干渉が排除されることでスペクトル効率が高まる。マルチパス伝搬に起因する干渉については、送信信号にサイクリックプレフィックスを挿入することにより基地局(NodeB)において対処する。
データを送信するために使用される基本的な物理リソースは、1つの時間間隔(例えば0.5msのサブフレーム)にわたるサイズBWgrantの周波数リソースから構成される(符号化された情報ビットはこのリソースにマッピングされる)。なお、サブフレーム(送信時間間隔(TTI:Transmission Time Interval)とも称する)は、ユーザデータを送信するための最小の時間間隔である。しかしながら、サブフレームを連結することにより、1TTIよりも長い時間にわたる周波数リソースBWgrantをユーザに割り当てることも可能である。
[LTEにおけるアップリンクのスケジューリング方式]
アップリンクの方式として、スケジューリング制御式の(すなわちeNBによって制御される)アクセスと、コンテンション(競合)ベースのアクセスの両方を使用することができる。
スケジューリング制御式アクセスの場合、アップリンクデータを送信するための特定の時間長の特定の周波数リソース(すなわち時間/周波数リソース)が、ユーザ機器に割り当てられる。しかしながら、コンテンションベースのアクセス用に、いくらかの時間/周波数リソースを割り当てることができる。コンテンションベースの時間/周波数リソースの範囲内では、ユーザ機器は、最初にスケジューリングされることなく送信することができる。ユーザ機器がコンテンションベースのアクセスを行う1つのシナリオは、例えばランダムアクセスであり、すなわち、ユーザ機器があるセルへの最初のアクセスを行うとき、またはアップリンクリソースを要求するために最初のアクセスを行うときである。
スケジューリング制御式アクセスの場合、NodeBのスケジューラが、アップリンクデータ送信のための固有の周波数/時間リソースをユーザに割り当てる。より具体的には、スケジューラは以下を決定する。
・ 送信を許可する(1つまたは複数の)ユーザ機器
・ 物理チャネルリソース(周波数)
・ 移動端末が送信に使用するべきトランスポートフォーマット(MCS(Modulation and Coding Scheme))
割当て情報は、L1/L2制御チャネルで送られるスケジューリンググラントを介してユーザ機器にシグナリングされる。以下では、説明を簡潔にするため、このチャネルをアップリンクグラントチャネルと称する。スケジューリンググラントメッセージには、情報として、周波数帯域のうちユーザ機器による使用を許可する部分と、グラントの有効期間と、これから行うアップリンク送信にユーザ機器が使用しなければならないトランスポートフォーマットとが、少なくとも含まれる。最も短い有効期間は1サブフレームである。グラントメッセージには、選択される方式に応じて追加の情報も含めることができる。アップリンク共有チャネル(UL−SCH)で送信する権利を許可するグラントとしては、「各ユーザ機器に対する」グラントのみが使用される(すなわち、「各ユーザ機器における各無線ベアラに対する」グラントは存在しない)。したがってユーザ機器は、割り当てられたリソースを何らかの規則に従って無線ベアラの間で配分する必要がある。トランスポートフォーマットは、HSUPAの場合とは異なり、ユーザ機器側では選択しない。eNBが、何らかの情報(例えば、報告されたスケジューリング情報およびQoS情報)に基づいてトランスポートフォーマットを決定し、ユーザ機器は、選択されたトランスポートフォーマットに従わなければならない。HSUPAでは、NodeBが最大限のアップリンクリソースを割り当てて、UEは、それに応じてデータ送信用の実際のトランスポートフォーマットを選択する。
無線リソースのスケジューリングは、サービス品質を決めるうえで、共有チャネルアクセスネットワークにおいて最も重要な機能であるため、効率的なサービス品質(QoS)管理を可能にする目的で、LTEにおけるアップリンクスケジューリング方式が満たしているべき要件がいくつかある。
・ 優先順位の低いサービスのリソース不足を避けるべきである。
・ 個々の無線ベアラ/サービスにおいてサービス品質(QoS)が明確に区別されるべきである。
・ どの無線ベアラ/サービスのデータが送信されるのかをeNBのスケジューラが識別できるように、アップリンク報告において、きめ細かいバッファ報告(例えば、無線ベアラごとの報告、または無線ベアラグループごとの報告)を可能にするべきである。
・ 異なるユーザのサービスの間でサービス品質(QoS)を明確に区別できるようにするべきである。
・ 無線ベアラごとに最小限のビットレートを提供できるようにするべきである。
上に挙げた条件から理解できるように、LTEのスケジューリング方式の1つの重要な側面は、事業者が、自身の総セル容量を、異なるQoSクラスの個々の無線ベアラの間で分配することを制御できるメカニズムを提供することである。無線ベアラのQoSクラスは、前述したようにサービングゲートウェイからeNBにシグナリングされる対応するSAEベアラのQoSプロファイルによって識別される。事業者は、自身の総セル容量のうちの特定の量を、特定のQoSクラスの無線ベアラに関連付けられる総トラフィックに割り当てることができる。クラスに基づくこの方法を採用する主たる目的は、パケットの処理を、パケットが属するQoSクラスに応じて区別できるようにすることである。
[(ブロードキャスト)システム情報の構造]
3GPPの専門用語においては、(ブロードキャスト)システム情報は、BCCH情報とも称され、すなわち、UEが接続されている(アクティブ状態)またはアタッチされている(アイドル状態)無線セルのブロードキャスト制御チャネル(論理チャネルである)で伝えられる情報を意味する。
システム情報には、一般的には、マスター情報ブロック(MIB:Master Information Block)と、いくつかのシステム情報ブロック(SIB:System Information Block)とが含まれる。マスター情報ブロック(MIB)には、各システム情報ブロックに関する制御情報が含まれる。各システム情報ブロック(SIB)に関連付けられる制御情報は、次の構造を有することができる。すなわち、SIBに関連付けられるそれぞれの制御情報は、SIBが送信されるトランスポートチャネル上での、共通のタイミング基準に対するSIBの位置を示すことができる(例えば、OFDM無線アクセスの場合の時間−周波数平面における位置、すなわち各SIBの送信用に割り当てられている特定のリソースブロック)。さらには、SIBの繰り返し周期を示すことができる。この繰り返し周期は、各SIBが送信される周期を示す。さらに、制御情報は、SIB情報のタイマベースの更新メカニズムのタイマ値、あるいは、SIB情報のタグベースの更新の場合の値タグを含むこともできる。
次の表は、非特許文献4の8.1.1節(参照によって本明細書に組み込まれている)に定義されている、UMTSレガシーシステムにおけるシステム情報ブロック(SIB)の分類およびタイプの概要を示している。システム情報はLTEシステムにおいても定義され、詳細については、非特許文献5の6.3.1節(参照によって本明細書に組み込まれている)に記載されている。
後の節でさらに詳しく説明するように、装置間(D2D:Device to Device)通信技術は、LTEリリース12において実施される予定である。現在3GPPによる標準化作業では、特に、ProSe直接通信および直接発見に関連するいくつかの情報が含まれるようにシステム情報ブロックタイプ18(SIBタイプ18:SystemInformationBlock Type 18)の定義が進められている。SIB18の以下の定義は、非特許文献3を対象としてProSeに関してこれまでに合意された現在検討されている変更要求r2−143565からの抜粋である。ただしこれは最終的に決定されたものではなく、単なる例として理解されたい。
上のシステム情報から明らかであるように、commIdleTxPoolフィールド(commSA-TxResourcePoolCommonサブフィールドを含む)は共通リソースを示し、SIB18を受信しかつ依然としてアイドル状態にあるUEは、この共通リソースから(競合(コンテンション)ベース方式で)リソースを使用することができる。言い換えれば、ネットワーク事業者は、すべてのUEのための無線リソースを共通に定義することができ、ただしこれらの無線リソースは、UEが依然としてアイドル状態にあるときにのみ使用可能である。後から説明するように、commIdleTxPoolによって定義されるこれらの無線リソースは、モード2のリソース(UEによって自律的に使用される)として分類される。
[バッファ状態報告]
バッファ状態報告手順は、UEのアップリンクバッファの中の送信できる状態にあるデータの量に関する情報を、サービングeNBに提供するために使用される。RRCレイヤは、2つのタイマperiodicBSR−TimerおよびretxBSR−Timerを設定し、さらにオプションとして、論理チャネルを論理チャネルグループ(LCG)に割り当てるlogicalChannelGroupを各論理チャネルについてシグナリングすることによって、バッファ状態報告(BSR)を制御する。バッファ状態報告に関するさらなる詳細は、非特許文献6の5.4.5節(参照によって本明細書に組み込まれている)に記載されている。
[LTEの装置間(D2D)近傍サービス(ProSe)]
近傍性に基づくアプリケーションおよびサービスは、ソーシャル技術の新しいトレンドである。識別される分野としては、事業者およびユーザにとって関心のある商用サービスおよび公共安全に関連するサービスが挙げられる。LTEに近傍サービス(ProSe)機能を導入することにより、3GPP業界は、この成長の見込まれる市場にサービスを提供することができると同時に、連係してLTEを使用するいくつかの公共安全コミュニティの緊急なニーズに応えることができる。
装置間(D2D)通信は、LTEリリース12における技術要素である。装置間(D2D)通信技術によって、セルラーネットワークに対するアンダーレイ(下層)としてのD2Dにおいてスペクトル効率を高めることができる。例えば、セルラーネットワークがLTEである場合、データを伝えるすべての物理チャネルは、D2DシグナリングにおいてSC−FDMAを使用する。
[LTEにおけるD2D通信]
LTEにおけるD2D通信は、発見および通信という2つの分野に焦点をあてている。
D2D通信では、UEは、基地局(BS)を経由せずに、セルラーリソースを使用して直接的なリンクを通じて互いにデータ信号を送信する。D2Dのユーザは、直接通信するが、基地局の制御下のままである(少なくともeNBのカバレッジ内であるとき)。したがってD2Dでは、セルラーリソースを再利用することによってシステムの性能を改善することができる。
D2Dは、アップリンクLTEスペクトル(FDDの場合)において動作する、またはカバレッジを提供しているセルのアップリンクサブフレーム(TDDの場合、ただしカバレッジ外のときを除く)において動作するものと想定する。さらに、D2D送信/受信では、与えられたキャリアにおける全二重を使用しない。個々のユーザ機器の観点からは、与えられたキャリアにおいて、D2D信号受信とLTEアップリンク送信とによる全二重を使用しない(すなわちD2D信号受信およびLTEアップリンク送信を同時に行うことはできない)。
D2D通信では、特定の1基のUE1が送信の役割であるとき(送信側ユーザ機器または送信側端末)、UE1がデータを送信し、別のUE2(受信側ユーザ機器)がそれを受信する。UE1およびUE2は、送信の役割と受信の役割を交換することができる。UE1からの送信は、UE2に類似する1基または複数基のUEによって受信することができる。
ユーザプレーンのプロトコルに関して、D2D通信に関連する合意内容を以下に示す(非特許文献7の9.2.2節(参照によって本明細書に組み込まれている)も参照)。
− PDCP:
・ 1:M D2Dブロードキャスト通信データ(すなわちIPパケット)は、通常のユーザプレーンデータとして扱うべきである。
・ 1:M D2Dブロードキャスト通信データには、PDCPにおけるヘッダ圧縮/圧縮解除を適用することができる。
・ 公共安全に関連するD2Dブロードキャスト動作では、PDCPにおけるヘッダ圧縮にUモードを使用する。
− RLC:
・ 1:M D2Dブロードキャスト通信にはRLC UMを使用する。
・ セグメント化および再構築はRLC UMによってL2においてサポートされる。
・ 受信側ユーザ機器は、送信側のピアユーザ機器あたり少なくとも1つのRLC UMエンティティを維持する必要がある。
・ 最初のRLC UMデータユニットを受信する前に受信機のRLC UMエンティティを設定する必要はない。
・ 現時点では、ユーザプレーンデータを送信するD2D通信においてRLC AMまたはRLC TMの必要性は認識されていない。
− MAC:
・ 1:M D2Dブロードキャスト通信ではHARQフィードバックを想定しない。
・ 受信側ユーザ機器は、受信機のRLC UMエンティティを識別する目的で送信元IDを認識する必要がある。
・ MACヘッダには、MACレイヤにおけるパケットフィルタリングを可能にするL2送信先IDが含まれる。
・ L2送信先IDは、ブロードキャストアドレス、グループキャストアドレス、またはユニキャストアドレスとすることができる。
・ L2グループキャスト/ユニキャスト: MACヘッダにおいて伝えられるL2送信先IDによって、受信されたRLC UM PDUを、たとえそれを受信機のRLCエンティティに渡す前であっても破棄することが可能となる。
・ L2ブロードキャスト: 受信側ユーザ機器は、すべての送信機からの受信されたすべてのRLC PDUを処理し、再構築してIPパケットを上位レイヤに渡す。
・ MACサブヘッダには、(複数の論理チャネルを区別するための)論理チャネルID(LCID)が含まれる。
・ D2Dでは、少なくとも多重化/逆多重化、優先順位の処理、およびパディングが有用である。
[無線リソースの割当て]
送信側UEの観点からは、近傍サービスに対応するUE(ProSe対応UE)は、リソース割当ての次の2つのモードで動作することができる。
モード1は、eNBがリソース割当てをスケジューリングする方式を意味し、この場合、UEは、eNB(またはリリース10の中継ノード)からの送信リソースを要求し、それを受けてeNB(またはリリース10の中継ノード)は、ユーザ機器が「直接」データおよび「直接」制御情報(例:スケジューリング割当て(SA:Scheduling Assignment))を送信するために使用する正確なリソースをスケジューリングする。UEは、データを送信するためにはRRC_CONNECTED状態にある必要がある。具体的には、UEは、スケジューリング要求(専用スケジューリング要求(D−SR)またはランダムアクセス)をeNBに送り、次いでバッファ状態報告(BSR:Buffer State Report)を通常の方法で送る(次節「D2D通信における送信手順」も参照)。eNBは、バッファ状態報告(BSR)に基づいて、ユーザ機器がProSe直接通信によって送信するデータを有するものと判断し、送信に必要なリソースを推定することができる。
これに対して、モード2は、UEが自律的にリソースを選択する方式を意味し、この場合、UEは、「直接」データおよび「直接」制御情報を送信するためのリソース(時間および周波数)を、自身でリソースプールから選択する。1つのリソースプールが、例えば(前の節で説明した)SIB18の内容によって(すなわちcommIdleTxPoolフィールドによって)定義され、この特定のリソースプールがセル内でブロードキャストされ、そのセル内の依然としてRRC_IDLE状態にあるすべてのUEに共通して利用可能である。これに代えて、またはこれに加えて、eNBが別のリソースプールを定義して特定のUEを対象として(すなわちcommTxResourcePoolフィールドを使用することによって)シグナリングすることができる。まだ最終的に決定されていないが、非特許文献3を対象として変更要求r2−143565に従って、対応するProSe情報エレメントについて現在標準化が進められている。したがって、以下の定義は単なる例として理解されたい。
このProSeCommConfig情報エレメントは、D2D通信を実行しようとするUEによる対応する要求に応えてeNBによって送信されるネットワーク応答の一部とすることができる。例えば図16に示したように、UEは、D2D通信を実行することを望む場合、D2D通信関心通知(D2D Communication Interest Indication)をeNBに送信することができる。この場合、(例えばRRCCommunicationReconfigurationの一部としての)D2D通信応答に、上述したProseCommConfig情報エレメントを含めることができる。
さらには、eNBのセルのカバレッジ外であるUEが、スケジューリング割当て(SA)またはデータのD2D通信用に利用することのできる事前に設定される無線リソースも、モード2のリソースとして分類することができる。
UEがどちらのリソース割当てモードを使用するかは、上述したようにeNBによって設定可能である。さらに、UEがD2Dデータ通信用にどちらのリソース割当てモードを使用するかは、RRC状態(すなわちRRC_IDLEまたはRRC_CONNECTED)と、UEのカバレッジ状態(すなわちカバレッジ内またはカバレッジ外)によっても決まるようにすることができる。UEがサービングセルを有する(すなわちUEがRRC_CONNECTED状態にある、またはRRC_IDLE状態において特定のセルにキャンプオンしている)場合、そのUEはカバレッジ内であるとみなされる。
3GPPにおける現在までの合意によると(R2−143672における非特許文献8への変更要求(リソース割当てに関する節)を参照)、リソース割当てモードに関する次の規則がUEに適用される。
・ UEがカバレッジ外である場合、そのUEはモード2のみを使用することができる。
・ UEがカバレッジ内である場合、UEがモード1を使用できるようにeNBによって設定されているならば、そのUEはモード1を使用することができる。
・ UEがカバレッジ内である場合、UEがモード2を使用できるようにeNBによって設定されているならば、そのUEはモード2を使用することができる。
・ 例外条件が存在しないときには、モードを変更するようにeNBによってUEが設定される場合にのみ、UEはモード1からモード2に、またはモード2からモード1に変更することができる。UEがカバレッジ内である場合、例外的なケースの1つが発生しない限り、UEはeNBの設定によって示されるモードのみを使用する。
・ 例えばT311またはT301が実行中である間、UEは、自身を例外条件下にあるものとみなす。
・ 例外的なケースが発生したとき、UEは、たとえモード1を使用するように設定されていても一時的にモード2を使用することが許可される。
ユーザ機器は、E−UTRAセルのカバレッジ領域内にある間は、そのセルによって割り当てられるリソースにおいてのみアップリンクキャリアでのProSe直接通信送信を実行する(たとえそのキャリアのリソースが例えばUICC(汎用ICカード:Universal Integrated Circuit Card)において事前に設定されている場合でも)。
RRC_IDLE状態にあるUEに対しては、eNBは次のオプションの一方を選択することができる。
・ eNBは、モード2の送信リソースプールをSIB(システム情報ブロック)の中で提供する。ProSe直接通信が許可されているUEは、RRC_IDLE状態においてProSe直接通信用にこれらのリソースを使用する。
・ eNBは、自身がD2DをサポートしているがProSe直接通信用のリソースを提供しないことをSIBの中で示す。UEは、ProSe直接通信送信を実行するためにはRRC_CONNECTED状態に入る必要がある。
RRC_CONNECTED状態にあるUEに関しては、次のようにすることができる。
・ RRC_CONNECTED状態にありProSe直接通信送信を実行することが許可されているUEは、ProSe直接通信送信を実行する必要があるとき、ProSe直接通信送信の実行を希望することをeNBに示す。
・ eNBは、RRC_CONNECTED状態にあるUEがProSe直接通信送信を許可されているかを、MMEから受信されるUEコンテキストを使用して確認する。
・ eNBは、RRC_CONNECTED状態にあるUEに対して、そのUEがRRC_CONNECTED状態である間は制約なしで使用することのできるモード2リソース割当て方式の送信リソースプールを、専用シグナリングによって設定することができる。これに代えて、eNBは、RRC_CONNECTED状態にあるUEに対して、例外的なケースにおいてのみそのUEが使用することのできるモード2のリソース割当て方式の送信リソースプールを、専用シグナリングによって設定することができ、例外的なケースでない場合、UEはモード1に従う。
リソース割当てに関するUEの上記の挙動は、図7および図8に状態図として単純化して示してある。図7は、UEがRRC_IDLE状態にある場合を示しており、カバレッジ内とカバレッジ外とを区別している。カバレッジ外でありRRC_IDLE状態にあるUEは、モード2のリソース割当てを使用することができることに留意されたい。現在のところ、RRC_IDLE状態にあるUEに対しては例外的なケースは定義されていない。これに対して図8は、UEがRRC_CONNECTED状態にある場合を示しており、カバレッジ内と例外的なケースとを区別している。図から明らかであるように、接続状態かつ例外的なケースにあるUEは、モード2のリソース割当てを使用することができる。
図9は、オーバーレイ(LTE)およびアンダーレイ(D2D)システムにおける送信/受信リソースの使用を示している。
UEがモード1の送信を適用するかモード2の送信を適用するかは、基本的にはeNodeBが制御する。UEは、D2D通信を送信(または受信)することのできるリソースを認識すると、現在の最新の技術においては、対応するリソースを、対応する送信/受信にのみ使用する。例えば図9において、D2Dサブフレームは、D2D信号を受信または送信する目的にのみ使用される。D2D装置としてのUEは、半二重モードで動作するため、任意の時点においてD2D信号の受信または送信のいずれかを行うことができる。同様に、図9に示したそれ以外のサブフレームは、LTE(オーバーレイ)の送信および/または受信に使用することができる。
[D2D通信における送信手順]
D2Dデータの送信手順は、リソース割当てモードに応じて異なる。上述したように、モード1の場合には、スケジューリング割当て(SA)およびD2Dデータを伝えるためのリソースを、UEからの対応する要求の後にeNBが明示的にスケジューリングする。具体的には、D2D通信は基本的に許可されるがモード2のリソース(すなわちリソースプール)が提供されないことを、eNBがUEに通知することができる。この通知は、例えば、図16に示したようにUEによるD2D通信関心通知と、対応する応答であるD2D通信応答を交換することによって、行うことができ、この場合、前述した対応する例示的なProseCommConfigの情報エレメントにcommTxREsourcePoolが含まれず、すなわち、送信を含む直接通信の開始を望むUEは、個々の送信ごとにリソース割当てをE−UTRANに要求しなければならない。したがってこのような場合、UEは、個々の送信それぞれのリソースを要求しなければならず、以下に、このモード1のリソース割当ての場合の要求/割当て手順の一連のステップを例示的に示す。
− ステップ1 UEがSR(スケジューリング要求)を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データを送信する。
スケジューリング割当て(SA)は、制御情報(例えば対応するD2Dデータを送信するための時間−周波数リソースを指すポインタ)を含むコンパクトな(低ペイロードの)メッセージである。スケジューリング割当て(SA)の内容は、基本的には上のステップ4において受信されるグラントに従う。D2Dグラントおよびスケジューリング割当て(SA)の内容の詳細は、現時点では決定されていないが、スケジューリング割当て(SA)の内容に関する具体的な想定として、以下の合意がなされている。
・ 周波数リソースは、リリース8のアップリンクタイプ0のリソース割当てによって示される(システム帯域幅に応じて5〜13ビット)
・ 1ビットの周波数ホッピングインジケータ(リリース8による)
・ モード2において設定されるリソースプールの範囲外の物理リソースブロック(PRB)がホッピングによって使用されないように、インデクシングの何らかの再解釈が定義される予定である。
・ シングルクラスタのリソース割当てのみが有効である
・ すなわち周波数領域においてリソースプールにギャップが存在する場合、リソース割当てはギャップをまたがない。
・ スケジューリング割当て(SA)においてはRVインデックスは使用されない。データのRVパターンは、{0,2,3,1}である。
これに対して、モード2のリソース割当ての場合、上のステップ1〜ステップ4は基本的に不要であり、UEは、スケジューリング割当て(SA)およびD2Dデータを送信するためのリソースを、eNBによって設定および提供される(1つまたは複数の)送信リソースプールから自律的に選択する。
図10は、2基のUE(UE−AおよびUE−B)の場合のスケジューリング割当て(SA)およびD2Dデータの送信を例示的に示している。スケジューリング割当て(SA)を送るためのリソースは周期的であり、D2Dデータの送信に使用されるリソースは、対応するスケジューリング割当て(SA)によって示される。
[スケジューリング割当て(SA)およびD2Dデータのためのリソースプール]
UEがカバレッジ外であるときのスケジューリング割当て(SA)およびD2Dデータのためのリソースプールは、以下のように設定することができる。
− スケジューリング割当て(SA)の受信に使用されるリソースプールは、事前に設定される。
− スケジューリング割当て(SA)の送信に使用されるリソースプールは、事前に設定される。
− D2Dデータの受信に使用されるリソースプールは、事前に設定される。
− D2Dデータの送信に使用されるリソースプールは、事前に設定される。
UEがカバレッジ内であるときのスケジューリング割当て(SA)のためのリソースプールは、以下のように設定することができる。
− スケジューリング割当て(SA)の受信に使用されるリソースプールは、eNBによって、RRCを介して専用シグナリングまたはブロードキャストシグナリングにおいて設定される。
− スケジューリング割当て(SA)の送信に使用されるリソースプールは、モード2のリソース割当てが使用される場合、eNBによってRRCを介して設定される。
− スケジューリング割当て(SA)の送信に使用されるリソースプールは、モード1のリソース割当てが使用される場合、UEに知らされない。
− モード1のリソース割当てが使用される場合、スケジューリング割当て(SA)の送信に使用するための特定のリソースをeNBがスケジューリングする。eNBによって割り当てられる特定のリソースは、UEに提供されるスケジューリング割当て(SA)受信用のリソースプールの範囲内である。
[D2DにおけるUEのカバレッジ状態]
すでに前述したように(例えば図7および図8を参照)、D2D通信におけるリソース割当て方法は、RRC状態(すなわちRRC_IDLEおよびRRC_CONNECTED)以外に、UEのカバレッジ状態(すなわちカバレッジ内およびカバレッジ外)にも依存する。UEがサービングセルを有する(すなわちUEがRRC_CONNECTED状態にある、またはRRC_IDLE状態において特定のセルにキャンプオンしている)場合、そのUEはカバレッジ内であるとみなされる。
ここまでに説明した2つのカバレッジ状態(すなわちカバレッジ内(IC)およびカバレッジ外(OOC:Out of Coverage))は、D2Dの場合のサブ状態にさらに区別される。図11は、D2D UEに関連付けることのできる4つの異なる状態を示しており、これらの状態は以下のように要約することができる。
− 状態1: UE1は、アップリンクカバレッジおよびダウンリンクカバレッジを有する。この状態においては、各D2D通信セッションをネットワークが制御する。さらにネットワークは、UE1がリソース割当てモード1を使用するべきかリソース割当てモード2を使用するべきかを設定する。
− 状態2: UE2は、ダウンリンクカバレッジを有するがアップリンクカバレッジを有さない(すなわちダウンリンクカバレッジのみを有する)。ネットワークが(競合ベースの)リソースプールをブロードキャストする。この状態においては、送信側UEは、スケジューリング割当て(SA)およびデータに使用するリソースを、ネットワークによって設定されるリソースプールから選択する。この状態においては、D2D通信用にモード2によるリソース割当てのみが可能である。
− 状態3: UE3は、アップリンクカバレッジおよびダウンリンクカバレッジを有さないため、厳密に言えばすでにカバレッジ外(OOC)とみなされる。しかしながらUE3は、それ自体がセルのカバレッジ内にある何基かのUE(例:UE1)のカバレッジ内であり、すなわちこれらのUEをCP中継UEと称することもでき、図11における状態3のUEの領域は、CP UE中継カバレッジ領域と称することができる。この状態3におけるUEは、カバレッジ外(OOC)状態3 UEとも称される。この状態においては、UEは、セルに固有ないくつかの情報を受信し、この情報は、eNBによって送られて(SIB)、セルのカバレッジ内のCP UE中継UEによってPD2DSCHを介して状態3カバレッジ外(OOC)UEに転送される。ネットワークによって制御される(競合ベースの)リソースプールがPD2DSCHによってシグナリングされる。
− 状態4: UE4はカバレッジ外であり、セルのカバレッジ内にある別のUEからPD2DSCHを受信しない。この状態(状態4カバレッジ外(OOC)とも称する)においては、送信側UEは、データ送信に使用するリソースを、事前に設定されるリソースのプールから選択する。
状態3カバレッジ外(OOC)と状態4カバレッジ外(OOC)とを区別する理由は、主として、カバレッジ外の装置からのD2D送信と、レガシーE−UTRA送信との間に発生しうる強い干渉を回避するためである。一般的にD2D対応UEは、カバレッジ外であるときに使用するための、D2D SAおよびデータの送信用の事前に設定されるリソースプールを有する。これらのカバレッジ外のUEが、これらの事前に設定されるリソースプールを使用してセルの境界付近で送信すると、そのD2D送信と、カバレッジ内のレガシー送信との間の干渉が、セル内の通信に悪影響を及ぼすことがある。カバレッジ内のD2D対応UEが、セル境界付近のこれらのカバレッジ外の装置にD2Dリソースプールの設定を転送するならば、カバレッジ外のUEは、自身の送信を、eNodeBによって指定されるこれらのリソースに制限することができ、したがってカバレッジ内のレガシー送信との干渉を最小にすることができる。したがってRAN1は、カバレッジ内のUEが、リソースプール情報およびD2Dに関連する他の設定を、カバレッジ領域のすぐ外側の装置(状態3のUE)に転送するメカニズムを導入した。
カバレッジ内D2Dリソースプールに関するこの情報をネットワーク内で近傍に位置するUEに伝える目的には、物理D2D同期チャネル(PD2DSCH)が使用され、したがってネットワークの近傍の範囲内のリソースプールが調整される。PD2DSCHの詳細な内容については、まだ最終合意されていない。
[D2D発見]
ProSe(近傍サービス)直接発見(ProSe Direct Discovery)は、ProSe対応ユーザ機器が、近傍の別の(1基または複数基の)ProSe対応ユーザ機器を、PC5インタフェースを介してE−UTRA直接無線信号を使用して発見するために使用される手順と定義されている。図12は、装置間の直接発見のためのPC5インタフェースを概略的に示している。
上位レイヤは、発見情報のアナウンスおよび監視の許可を処理する。この目的のため、ユーザ機器は、事前に定義された信号(発見信号(discovery signal)と称する)を交換しなければならない。ユーザ機器は、必要なときに通信リンクを確立する目的で、発見信号を周期的にチェックすることによって、近傍のユーザ機器のリストを維持する。発見信号は、たとえ信号対雑音比(SNR:Signal to Noise Ratio)が低い環境においても高い信頼性で検出される必要がある。発見信号を周期的に送信することができるように、発見信号用のリソースを割り当てる必要がある。
ProSe直接発見には2つのタイプがあり、すなわちオープン型(open)と制限型(restricted)である。オープン型は、発見されるユーザ機器からの明示的な許可が必要ない場合であり、制限型の発見は、発見されるユーザ機器からの明示的な許可があるときにのみ行われる。
ProSe直接発見は、発見する側のユーザ機器におけるスタンドアロンのサービスイネーブラ(service enabler)とすることができ、このサービスイネーブラは、特定のアプリケーションにおいて、発見する側のユーザ機器が発見される側のユーザ機器からの情報を使用することを可能にする。ProSe直接発見において送信される情報は、一例として、「近くでタクシーを見つけて」、「コーヒーショップを見つけて」、「最寄りの警察署を見つけて」などとすることができる。発見する側のユーザ機器は、ProSe直接発見を通じて、必要な情報を取得することができる。さらに、得られる情報に応じて、ProSe直接発見を使用して遠隔通信システムにおける以降の動作(例えばProSe直接通信を開始するなど)を行うことができる。
[ProSe直接発見のモデル]
ProSe直接発見は、いくつかの発見モデルに基づく。以下に概要を示す。ProSe直接発見のモデルは、非特許文献9の5.3節(参照によって本明細書に組み込まれている)にさらに詳細に定義されている。
モデルA(「私はここです」)
モデルAは、「私はここです」とも表される。なぜなら、アナウンスする側のユーザ機器が自身に関する情報(自身のProSeアプリケーションの識別情報やProSe UEの識別情報など)を発見メッセージの中でブロードキャストし、これにより自身の身元を明らかにし、自身が利用可能であることを通信システムの他の装置に伝えるためである。
モデルAによると、ProSe直接発見に関与しているProSe対応ユーザ機器の2つの役割が定義されている。ProSe対応ユーザ機器は、アナウンスする側のユーザ機器と監視する側のユーザ機器の機能を有することができる。アナウンスする側のユーザ機器は、発見の許可を有する近傍のユーザ機器が使用することのできる特定の情報をアナウンスする。監視する側のユーザ機器は、アナウンスする側のユーザ機器の近傍において、関心のある特定の情報を監視する。
このモデルAでは、アナウンスする側のユーザ機器が、事前に定義される発見間隔で発見メッセージをブロードキャストし、これらのメッセージに関心のある監視する側のユーザ機器が、メッセージを読み取って処理する。
モデルB(「そこにいるのは誰ですか?」/「あなたはそこにいますか?」)
このモデルは、ProSe直接発見に関与するProSe対応UEの次の2つの役割を定義する。
− 発見する側のUE: このUEは、自身が発見したい対象に関する特定の情報を含む要求を送信する。
− 発見される側のUE: 要求メッセージを受信したUEは、発見する側のUEの要求に関連する何らかの情報で応答することができる。
モデルBは、「そこにいるのは誰ですか?/あなたはそこにいますか?」と同等である。なぜなら、発見する側のユーザ機器が、応答を受け取りたい対象の別のユーザ機器に関する情報を送信するためである。送信される情報は、例えば、グループに対応するProSeアプリケーションIDに関する情報とすることができる。グループのメンバーは、この送信された情報に応答することができる。
このモデルBによると、ProSe直接発見に関与しているProSe対応ユーザ機器の2つの役割が定義されており、すなわち発見する側のユーザ機器と発見される側のユーザ機器である。発見する側のユーザ機器は、自身が発見したい対象に関する特定の情報を含む要求を送信する。一方で、この要求メッセージを受信した発見される側のユーザ機器は、発見する側のユーザ機器の要求に関連する何らかの情報によって応答することができる。
発見情報の内容は、アクセス層(AS)に透過的であり、アクセス層(AS)は発見情報の内容を認識していない。したがってアクセス層では、ProSe直接発見のさまざまなモデルが区別されず、またProSe直接発見のタイプも区別されない。ProSeプロトコルは、アナウンスする有効な発見情報のみをアクセス層(AS)に渡す。
ユーザ機器は、eNBの設定によるRRC_IDLE状態およびRRC_CONNECTED状態の両方において、発見情報のアナウンスおよび監視に関与することができる。ユーザ機器は、半二重の制約を受ける発見情報をアナウンスおよび監視する。
[発見のタイプ]
図13は、D2D通信において発見用リソースを受信するときのIDLEモードおよびCONNECTEDモードを、リソース割当て手順に関して示した図である。
D2D通信は、ネットワークによって制御する(この場合には直接送信(D2D)と従来のセルラーリンクとの間の切り替えを通信事業者が管理する)、または、通信事業者の制御なしで直接リンクを装置によって管理することができる。D2Dでは、インフラストラクチャモードとアドホック通信を組み合わせることができる。
一般的には、装置の発見は周期的に必要である。さらにD2D装置は、発見メッセージのシグナリングプロトコルを利用して装置の発見を実行する。例えば、D2D対応ユーザ機器が、自身の発見メッセージを送信することができ、別のD2D対応ユーザ機器がこの発見メッセージを受信し、この情報を使用して通信リンクを確立することができる。ハイブリッドネットワークの利点として、D2D装置がネットワークインフラストラクチャの通信範囲内でもある場合、eNBなどのネットワークエンティティが発見メッセージの送信や設定を追加的に支援することができる。発見メッセージの送信や設定をeNBによって調整/制御することは、D2Dのメッセージングと、そのeNBによって制御されているセルラートラフィックとの干渉が発生しないようにするうえでも重要である。さらには、たとえ装置のいくつかがネットワークカバレッジの範囲外である場合でも、カバレッジ内の装置がアドホック発見プロトコルを支援することができる。
説明においてさらに使用される専門用語を定義する目的で、少なくとも以下の2つのタイプの発見手順が定義されている。
− タイプ1: 発見情報をアナウンスするためのリソースが特定のユーザ機器を対象とせずに割り当てられ、さらに以下を特徴とするリソース割当て手順。
○ 発見情報のアナウンスに使用されるリソースプールの設定をeNBがユーザ機器に提供する。設定はSIBにおいてシグナリングすることができる。
○ ユーザ機器は、示されたリソースプールから(1つまたは複数の)無線リソースを自律的に選択し、発見情報をアナウンスする。
○ ユーザ機器は、各発見期間中、ランダムに選択される発見用リソースで発見情報をアナウンスすることができる。
− タイプ2: 発見情報をアナウンスするためのリソースが特定のユーザ機器を対象として割り当てられ、さらに以下を特徴とするリソース割当て手順。
○ RRC_CONNECTEDモードにあるユーザ機器は、発見情報をアナウンスするためのeNBからのリソースをRRCを介して要求することができる。eNBはRRCを介してリソースを割り当てる。
○ リソースは、監視するユーザ機器に設定されるリソースプール内に割り当てられる。
タイプ2の手順によると、リソースは例えば発見信号の送信用にセミパーシステントに割り当てられる。
ユーザ機器がRRC_IDLEモードにある場合、eNBは以下のオプションの1つを選択することができる。
− eNBは、発見情報をアナウンスするためのタイプ1のリソースプールをSIBにおいて提供することができる。ProSe直接発見を許可されているユーザ機器は、RRC_IDLEモードにおいてこれらのリソースを使用して発見情報をアナウンスする。
− eNBは、自身がD2Dをサポートしているが、発見情報をアナウンスするためのリソースを提供しないことを、SIBにおいて示すことができる。ユーザ機器は、発見情報をアナウンスするためのD2Dリソースを要求するためには、RRC_CONNECTEDモードに入る必要がある。
RRC_CONNECTED状態にあるユーザ機器については、ProSe直接発見のアナウンスを実行することが許可されているユーザ機器は、D2D発見のアナウンスの実行を望むことをeNBに知らせる。するとeNBは、そのユーザ機器がProSe直接発見のアナウンスを許可されているかを、MMEから受信したUEコンテキストを使用して確認する。eNBは、発見情報のアナウンス用にタイプ1のリソースプールまたはタイプ2の専用リソースを使用するように、専用のRRCシグナリングを介してユーザ機器を設定することができる(またはリソースなし)。eNBによって割り当てられたリソースは、a)eNBがそのリソースをRRCシグナリングによって設定解除する(de-configure)まで、またはb)ユーザ機器がIDLEモードに入るまで、有効である。
RRC_IDLEモードおよびRRC_CONNECTEDモードにある受信側ユーザ機器は、許可されるタイプ1およびタイプ2の発見用リソースプールの両方を監視する。eNBは、発見情報を監視するために使用されるリソースプールの設定をSIBにおいて提供する。SIBは、隣接セルにおいてアナウンスするために使用される発見用リソースも含むことができる。
[無線プロトコルのアーキテクチャ]
図14は、ProSe直接発見のための無線プロトコルスタック(AS:Access Stratum)を概略的に示している。
ASレイヤは、上位レイヤ(ProSeプロトコル)とのインタフェースとして機能する。したがって、MACレイヤは上位レイヤ(ProSeプロトコル)から発見情報を受け取る。この場合、発見情報を送信するのにIPレイヤは使用されない。さらに、ASレイヤはスケジューリング機能を有し、MACレイヤはこのスケジューリング機能に従って、上位レイヤから受け取った発見情報をアナウンスするために使用するべき無線リソースを決定する。これに加えてASレイヤは、発見PDUを生成する機能を有し、MACレイヤはこの機能に従って、発見情報を伝えるMAC PDUを構築し、そのMAC PDUを、決定した無線リソースにおいて送信できるように物理レイヤに渡す。MACヘッダは追加されない。
ユーザ機器において、RRCプロトコルは、発見用リソースプールをMACレイヤに知らせる。さらにRRCは、送信用に割り当てられたタイプ2のリソースをMACレイヤに知らせる。MACヘッダの必要はない。発見に関するMACヘッダには、L2においてフィルタリングを実行するときに基づくフィールドが含まれない。MACレベルにおいて発見メッセージをフィルタリングしても、上位レイヤにおいてProSe UE IDやProSeアプリケーションIDに基づいてフィルタリングを実行することと比較して、処理量や電力が節約されるとは考えられない。受信側MACレイヤは、受け取った発見メッセージすべてを上位レイヤに渡す。このときMACレイヤは、正しく受信されたメッセージのみを上位レイヤに渡す。
以下では、発見メッセージが正しく受信されたかをL1(PHY)がMACレイヤに示すものと想定する。さらに、上位レイヤは必ず有効な発見情報のみをASレイヤに渡すものと想定する。
[D2Dの同期]
同期の主たる役割は、受信機が時間および周波数の基準を取得できるようにすることである。このような基準は、少なくとも次の2つの目的に利用することができる。1)D2Dチャネルを検出するときに受信窓および周波数補正を合わせる、2)D2Dチャネルを送信するときに送信機のタイミングおよびパラメータを合わせる。3GPPでは、現在のところ同期を目的として以下のチャネルが定義されている。
− D2DSS D2D同期信号
− PD2DSCH 物理D2D同期チャネル
− PD2DSS プライマリD2D同期信号
− SD2DSS セカンダリD2D同期信号
さらに3GPPでは、同期に関する以下の専門用語が合意されており、これらの専門用語は本出願の残りの部分において例示的に使用する。
− D2D同期源: 少なくともD2D同期信号を送信するノード。D2D同期源は、基本的にはeNBまたはD2D UEとすることができる。
− D2D同期信号: UEがそこからタイミングおよび周波数の同期を取得することのできる信号。
D2Dの同期は、LTEのセルサーチに類似する手順として理解することができる。部分的カバレッジ内シナリオおよびカバレッジ外シナリオにおいてネットワーク制御および効率的な同期の両方を可能にする目的で、現在3GPPにおいて、受信機および送信機の以下の同期手順が検討されている。
[受信機の同期]
ProSe対応UEは、LTEセル(LTEのモビリティ手順に従う)と、同期源(SS:Synchronization Source)UEによって送信されるD2DSS/PD2DSCHとを、定期的に探索する。
適切なセルが見つかると、UEはそのセルにキャンプオンし、セル同期(LTEのレガシー手順による)に従う。
SS(同期源)UEによって送信される適切なD2DSS/PD2DSCHが見つかると、UEは、入ってくるすべてのD2DSS/PD2DSCH(UEの能力による)に自身の受信機を同期させ、入ってくる接続(スケジューリング割当て)がないかそれらを監視する。なお、eNodeBであるD2D同期源によって送信されるD2DSSは、リリース8のPSS/SSS(プライマリ同期信号/セカンダリ同期信号)であることに留意されたい。eNodeBであるD2D同期源は、UEであるD2D同期源よりも高い優先順位を有する。
[送信機の同期]
ProSe対応UEは、LTEセル(LTEのモビリティ手順に従う)と、SS(同期源)UEによって送信されるD2DSS/PD2DSCHとを、定期的に探索する。
適切なセルが見つかると、UEはそのセルにキャンプオンし、D2D信号を送信できるようにセル同期に従う。このような場合、ネットワークは、セル同期に従ってD2DSS/PD2DSCHを送信するようにUEを設定することができる。
適切なセルが見つからない場合、UEは、入ってくるD2DSS/PD2DSCHのいずれかをさらに中継できる(すなわち最大ホップカウントに達していない)かを確認し、(a)さらに中継できる入ってくるD2DSS/PD2DSCHが見つかった場合、UEは自身の送信機の同期をその信号に合わせ、それに応じてD2DSS/PD2DSCHを送信する、または、(b)さらに中継できる入ってくるD2DSS/PD2DSCHが見つからない場合、UEは独立した同期源として動作し、任意の内部同期基準に従ってD2DSS/PD2DSCHを送信する。
D2Dにおける同期手順のさらなる詳細は、非特許文献9の7節(参照によって本明細書に組み込まれている)に記載されている。
[セルの選択およびRRC接続の確立]
図15は、セルを選択してRRC接続を確立するための、UEとeNBの間の従来技術のメッセージ交換を、簡略的かつ例示的に示している。ステップ2におけるセルの選択は、例えば非特許文献11の例えば5.2.3節(参照によって本明細書に組み込まれている)に基づく。WAN(ワイドエリアネットワーク、例:LTE)セルにキャンプオンしていないUEは、カバレッジ外(OOC)とみなされる。セルへのキャンプオンは、非特許文献11の5.2.3節に定義されているセル選択基準/プロセスに基づくことができる。したがってステップ2を完了する前は、一般にUEはカバレッジ外(OOC)とみなされる。セルの選択に成功し、UEが(適切なセルまたは許容されるセルに)キャンプオンすると、そのUEはRRCアイドル状態にある。UEは、ステップ7まで(すなわちネットワークからRRCConnectionSetupメッセージを受信するまで)RRCアイドル状態のままであり、そのあとRRC接続状態に変わる。
以下の実施形態は、例えば、背景技術のセクションにおいて説明した3GPP LTE−A(リリース10/11/12)などの移動通信システムにおいて有利に利用することができるが、これらの実施形態は、この特定の例示的な通信ネットワークにおける使用に限定されないことに留意されたい。
移動局またはモバイルノードまたはユーザ端末は、通信ネットワーク内の物理的なエンティティである。1つのノードが、いくつかの機能エンティティを有することができる。機能エンティティとは、所定の一連の機能を実施する、もしくは、ノードまたはネットワークの別の機能エンティティに所定の一連の機能を提供する、またはその両方であるソフトウェアモジュールまたはハードウェアモジュールを意味する。ノードは、自身を通信機器または通信媒体にアタッチする1つまたは複数のインタフェースを有することができ、ノードはこれらのインタフェースを通じて通信することができる。同様に、ネットワークエンティティは、機能エンティティを通信機器または通信媒体にアタッチする論理インタフェースを有することができ、ネットワークエンティティは論理インタフェースを通じて別の機能エンティティやコレスポンデントノードと通信することができる。
特許請求の範囲および本出願において使用されている「送信側端末」は、送信機の役割のユーザ端末を意味する。逆に、「受信側端末」は、受信機の役割のユーザ端末を意味する。形容詞である「送信側」および「受信側」は、一時的な動作/役割を明確にすることを意図しているにすぎない。
特許請求の範囲および本出願において使用されている「直接通信送信」は、一例として、LTEリリース12において現在検討されている装置間(D2D)通信を意味する。これに対応して、用語「直接リンク接続」は、一例として、2基のD2Dユーザ端末を直接接続するPC5インタフェースを通じての接続チャネルまたは通信チャネルであって、ネットワークの関与なしにデータの直接的な交換を可能にする接続チャネルまたは通信チャネル、を意味する。言い換えれば通信チャネルは、通信システムにおいて、データを直接交換するのに十分に近い2基のユーザ機器の間に、eNodeB(基地局)をバイパスして確立される。
特許請求の範囲および本出願において使用されている用語「無線接続確立手順」は、ランダムアクセス手順を含む手順、または含まない手順として理解することができる。したがって、無線接続確立手順を開始することは、ランダムアクセス手順のプリアンブルを送信することと等価であるものとして、または、RRC接続要求メッセージを送信することと等価であるものとして、理解することができる。したがって、3GPP LTEの文脈においては、無線接続確立手順は、RRC接続確立手順が後に続くランダムアクセス手順とすることができる。
特許請求の範囲および本出願において使用されている用語「専用無線リソース」は、基地局(eNodeB)によって特定の端末に明示的に割り当てられる無線リソースとして理解されたい。専用無線リソースは、それ自体は、背景技術のセクションにおいて説明したように、モード1のリソースまたはモード2のリソースのいずれかとすることができる。この用語は、セル内の端末によって共通に使用することのできる「共通無線リソース」と対照される語として理解されたい。例えば、システム情報(例えばSIB18)によって定義される送信用無線リソースプールがセル内でブロードキャストされ、したがってこの無線リソースは、このシステム情報を受信する端末によって使用することができる。
「無線接続確立手順を開始する」という表現および類似する表現は、基地局との無線接続の確立を試みることが端末に要求されることと理解されるものとし、ただし無線接続確立手順は失敗してもよいことに留意されたい。言い換えれば、無線接続の確立を試みることが端末に要求されるが、端末は、対応する無線接続確立手順を開始することのみに成功し、その無線接続確立手順をそのまま続けて無線接続を正常に確立することに成功しなくてもよい。したがって、この表現において、無線接続確立手順を開始するというこの必要条件は、その結果、すなわち、無線接続の確立に成功する(例えばRRC接続設定メッセージを受信する)、または失敗する(例えばRRC接続拒否メッセージを受信する)かには無関係であることを理解されたい。
特許請求の範囲および本出願において使用されている「送信用無線リソースプールが使用可能である」という表現(および類似する表現)は、端末が(例えばスケジューリング割当て(SA)または直接通信データの)直接通信送信を実行することを望む場合に、端末が送信用無線リソースプールから(必須ではないが)リソースを選択して使用することができるという意味として、広義に理解されたい。これに対応して、送信用無線リソースプールが使用されるという表現(および類似する表現)は、端末が直接通信送信を実行することを実際に意図しており、送信用無線リソースプールから適切なリソースを選択し、選択されたそのリソースにおいてその直接通信送信を実行するという意味として、広義に理解されたい。
特許請求の範囲および本出願において使用されている「カバレッジ内」という表現は、端末がセルを正常に選択していれば、端末がアイドル状態にあるか接続状態にあるかには無関係に、その端末はカバレッジ内であるとみなされるという意味として、広義に理解されたい。セルの選択の基準は、非特許文献2に定義されている。すべてのカバレッジ内UEは、(アイドル状態または接続状態において)ブロードキャストメッセージを使用して、または接続状態において専用(すなわちUEとネットワークとの間の1対1の)メッセージを使用して、ネットワークからシグナリングを受信することができる。例えば、UEがサービングセルを有する(すなわちUEがRRC_CONNECTED状態にある、またはRRC_IDLE状態においてセルにキャンプオンしている)場合、そのUEはカバレッジ内であるとみなされる。したがって、「カバレッジ外」という表現は、この逆の意味として理解されたい。
特許請求の範囲および本出願において使用されている用語「事前に設定されている」は、たとえ無線アクセスから何らの情報も受信しなくても、リソースプールの対応するリソースが端末に既知である、すなわち、事前に設定されている無線リソースプールは、セルおよびセル内のシステム情報ブロードキャストとは無関係に利用可能であるという意味として、広義に理解されたい。
特許請求の範囲および本出願において使用されている用語「無線リソース」は、物理無線リソース(時間−周波数リソースなど)を意味するものと広義に理解されたい。
背景技術のセクションにおいて説明したように、UEは、その状態およびeNBによる設定に応じて、別のUEとのD2D直接通信用に異なるリソースを使用することができる。本発明者は、直接通信の現在考えられている実装形態(すなわち3GPP D2D通信)に関して多くの問題点および欠点を認識した。以下のさまざまなシナリオおよび問題が存在し、これらについて図18に関連して説明する。図18(図15の拡張である)は、図15に加えて、UEがD2D通信への関心を示し、このUEがD2D通信の送信用の専用無線リソースを要求するステップと、さまざまな異なる期間0,1,2,A,B,C,Dを示している。図18には示していないが、背景技術のセクションにおいて説明したように、UEは、セルのカバレッジ外であるとき、スケジューリング割当て(SA)およびD2Dデータの受信/送信用に、事前に設定されるモード2のリソースを有することができる。
eNBは、自身のネットワーク内において、UEがRRCアイドル状態にあるときにモード2のリソース割当てができないことを決定することができる。説明を目的として、このようなタイプのネットワークをタイプAのネットワークと称する。特に、タイプAのネットワークにおいては、UEは、D2Dが許可されることをSIB18の中で認識するが、D2D用にブロードキャストされる共通のモード2のリソース(例:モード2によるリソースプール)が存在しないため、UEは最初にRRC接続を確立しなければならない(図15を参照)。次いでUEは、(例えばD2D通信関心通知および対応するD2D通信応答を使用して(図16を参照))D2Dに関して適切に設定された後、(eNBによるUEに対する設定(D2D通信応答メッセージに対応する)によっては)送信用にモード2のリソースにアクセスすることができる。D2D通信用に(例えば専用のモード2のリソースプールとして)使用可能なリソースが、D2D通信応答によって提供されない場合、背景技術のセクションで前述したように(節「D2D通信における送信手順」内のステップ1〜5を参照)、UEはD2Dに関連するリソースを、専用シグナリング(スケジューリング要求、バッファ状態報告)を使用して明示的に要求する必要があり、これによりさらなる時間がかかる(期間Cを参照)。
さらには、図18に示した期間Dは、対応するD2Dグラントを受信した後に最初のD2Dを送るときの遅延である。この遅延は無視できるとも考えられるが、無視できないことがあり、なぜなら本発明者による計算によると、各スケジューリング割当て(SA)およびデータ用のリソースプールのビットマップの周期、それらのオフセット(例えばSFN(システムフレーム番号)0からのオフセット)、割り当てられるT−RPT(送信の時間リソースパターン(time resource pattern of Transmission))などのリソース設定によっては、期間Dだけで約300〜400msにもなりうる。
結果としてUEは、図18に示した期間2が終わるまでにD2D通信を実行することができず、さらには、eNBからのD2D通信応答によってD2Dが許可されても、この通信応答によってUEに専用のモード2のリソースが提供されない場合(この場合にはUEは特定のD2D送信用のリソースのグラントを明示的に要求する必要がある)、期間Cおよび期間DにわたってもD2D通信を実行することができない。
タイプAのネットワークでは、ネットワーク事業者はリソースの使用を完全に制御することができる。なぜならネットワーク事業者は、D2Dを実行しているUEの数を認識し、したがってD2D用途とLTE用途との間でリソースを分配できるためである。しかしながら、このようなタイプAのネットワーク内のUEは、アイドル状態においてはいかなるD2D通信も実行することができない。さらには、RRC接続状態になった後も、UEはD2D通信関心通知メッセージを送信し、少なくとも明示的なネットワーク応答を待機してD2D通信リソースを受信しなければならず、通信データを実際に送信できるまでには、さらなる時間(期間Cおよび/または期間D)待たなければならない。この遅延は、合計すると容易に2秒以上になりうる。リリース12においては、D2D通信は主として公共安全性の用途を対象としているため、特にVoIP/音声/会話のサービスクラスの場合、たとえ2秒の遅延/中断も許容されない。このことは、特に、カバレッジ外状況とカバレッジ内状況との間を行き来することのあるセル周縁部のUEにあてはまる。図17は、セルの周縁部において移動するUEを示している。
この問題は、RRCアイドル状態において使用される共通のモード2のD2D通信リソースがeNBによるネットワーク配備によって提供される別のタイプのネットワークにおいて限定的に緩和される。このようなネットワークは、説明を目的としてタイプBのネットワークと称することができる。このようなタイプBのネットワークにおいては、UEは、SIB18(対応するモード2のアイドル状態リソース(idle resource)の設定(例:commIdleTxPool)を含む)を取得した後に(したがってタイプAのネットワークにおけるよりも早く)、このようなモード2のアイドル状態リソースを使用してD2D通信を開始する。したがってこれらのUEは、期間B,C,Dにおいて再び中断が発生する少し前にD2Dデータ通信を実行することができる。したがってUEは、期間0においてD2D通信を実行することはできないが、期間Aの間にD2D通信を実行することができる。
しかしながら、タイプBのネットワークにおいても、UEは、特定のタイミングにおいて、D2D通信を実行することが抑制され、これにより望ましくない遅延および/または中断が発生する。UEは、RRCアイドル状態にある限りはモード2のアイドル状態リソースを継続して使用することができる。SIB18を介しての最新の技術のモード2のアイドル状態リソースは、RRCアイドル状態においてのみ使用することができる。しかしながら、(何らかの理由で、例えばWANの理由で(例:インターネットにアクセスするために))UEがRRC接続を確立し、したがってRRC接続状態に変わると(図15のステップ7を参照)、そのUEは、D2D通信を続行または開始する目的に(すなわち図15のステップ7の時点で)、SIB18によって定義されるモード2のリソースプールのこれらのリソースをもはや使用することができない。このような場合、以前に開始したD2D通信を再開する、または新しいD2D通信を開始するためには、UEは少なくともD2D通信関心通知メッセージを送信し、明示的なネットワーク応答を待機して、モード2のD2D通信リソースを受け取らなければならない(またはD2D通信の送信手順のステップ1〜5に関連して上述したように、特定のD2D送信用のリソースのグラントを明示的に要求する必要があるときにはさらに長い時間待機しなければならない)。このことは通信の遅延および/または中断につながる。UEは、期間B,C(,およびD)においてD2D通信を実行することができない。
図20は、図18において説明したさまざまな期間をブロックとして示しており、タイプAのネットワークとタイプBのネットワークについて、UEがD2D通信の送信を行うことのできない期間の差を図解している。
図19は、図18に似ているが、RRC接続の確立に失敗する場合を示している。図から明らかであるように、RRC接続の確立を開始した後、確立に失敗する(例えば、RRC接続がeNBによって拒否されるため、または、セルの再選択など別の理由で、あるいはT300が切れることも起こり得る)。いずれの場合にも、UEはRRCアイドル状態のままである。タイプAのネットワークにおいては、このような状況は特に不利である。なぜならUEは、アイドル状態にある間はD2D通信をまったく実行することができないためである。これに対してタイプBのネットワークの場合、モード2のアイドル状態リソースの設定を含むSIB18を取得した後に(すなわち期間Aの間に、およびそれ以降において)、D2D通信が可能である。
タイプBのネットワークの場合の1つの適切な(かつ容易に実施される)解決策は、少なくとも、直接通信送信に使用可能である専用リソースがeNodeBによって端末に割り当てられるまでは(図18の期間B+C(+D)を参照)、モード2のアイドル状態リソース(commIdleTxPool)が、RRC接続状態にある端末によっても使用可能であるようにすることである。
本発明者は、上述した問題を緩和するため、以下の第1の例示的な実施形態および第2の例示的な実施形態を着想した。
以下では、いくつかの例示的な実施形態について詳しく説明する。これらの実施形態のいくつかは、3GPP標準規格によって与えられる幅広い仕様(背景技術のセクションでその一部を説明した)の中で実施されるように意図されており、特に重要な特徴について、以下にさまざまな実施形態に関連して説明する。なお、これらの実施形態は、例えば背景技術のセクションで説明した3GPP LTE−A(リリース10/11/12)通信システムなどの移動通信システムにおいて有利に使用することができるが、これらの実施形態は、この特定の例示的な通信ネットワークにおける使用に限定されないことに留意されたい。
以下の説明は、本開示の範囲を制限するものではなく、本開示を深く理解するための実施形態の単なる例であるものと理解されたい。当業者には、請求項に記載されている本開示の一般的な原理を、さまざまなシナリオに、本明細書に明示的に説明されていない方法で、適用できることが認識されるであろう。したがって、さまざまな実施形態を説明する目的で想定される以下のシナリオは、本発明をそのようなシナリオに制限するものではない。
[第1の実施形態]
以下では、第1の一連の実施形態について説明する。第1の実施形態の原理の説明を簡略化するため、いくつかの想定を行うが、これらの想定は、特許請求の範囲によって広く定義されている本出願の範囲を限定するものとして解釈されるべきではないことに留意されたい。
第1の態様によると、直接通信送信を実行するための追加の送信用無線リソースプールを、ネットワーク事業者によって定義し、この追加のリソースプールは、従来技術からすでに公知であるアイドル状態送信用無線リソースプールとはいくつかの点で異なる。背景技術のセクションで説明したように、ネットワーク事業者がこのようにすることを決定するならば、送信用無線リソースプールに関する情報を基地局によってそのセル内でブロードキャストすることができる。したがって、このシステム情報ブロードキャストを受信した端末は、別の端末との直接通信の実行を望む場合、この送信用無線リソースプールからのリソースを自律的に使用することができる。従来技術の送信用無線リソースプール(便宜上、アイドル状態送信用無線リソースプールと称する)は、アイドル状態にある間に端末によって使用可能であるが、端末の状態が接続状態に変わると、上述した問題のいくつかが発生する。
これに対して、この第1の態様に従って導入される追加の送信用無線リソースプール(便宜上、一時的な送信用無線リソースプールと称する)は、一時的にのみ(すなわち限られた時間長に渡り)使用されるが、端末がアイドル状態にあるか接続状態にあるかには無関係である。ネットワーク事業者は、この一時的な送信用無線リソースプールが使用可能である時間長を、システム情報ブロードキャストの中の対応する追加の指示情報(設定情報)によって制御することができる。この一時的な送信用無線リソースプールの使用可能性を制限することは、いくつかの異なる方法で実施することができ、そのうちのいくつかを後から例示的に説明するが、いずれの方法においても、この一時的リソースを使用できる時間が制限され、基地局(すなわちネットワーク事業者)によって制御することができる。
ネットワーク事業者は、システム情報ブロードキャストを介してアイドル状態送信用無線リソースプールを端末に共通に利用可能にすることに躊躇して、自社の無線リソースに対する完全な制御(または少なくともできる限り多くの制御)が維持されるように、特定の端末に特定の専用リソースプールを割り当てる、あるいは各端末に特定の専用物理リソースのみを割り当てることを選ぶことができる。したがって、ネットワーク事業者は、端末が自身のセル内で従来技術のアイドル状態送信用無線リソースプールを自律的に使用することを望まないことがある。その理由としては、例えば、(端末がアイドル状態にある限り)端末はこのアイドル状態送信用無線リソースプールからのリソースをほぼ無制限に使用することができる、あるいは自律的に使用する場合、何基のUEがこれらのアイドルモードD2Dリソースを実際に使用しているかをネットワークが認識せず、なぜならネットワークはこのようなUEの数に関して知ることができないためである(アイドルモードのUEはセルレベルでは認識されず、セルレベルより十分に大きいトラッキングエリアのレベルでのみ認識される)。このためネットワークは、このアイドルモードD2Dリソースが少なすぎる(すなわちD2Dリソースの使用において多くの衝突が発生する)のか、多すぎる(すなわち本来ならばLTEのリソースが不必要に消費される)のかを判断することができない。これに対して、追加の一時的な送信用無線リソースプールの場合には、ネットワーク事業者は、(程度の差はあるが)設定可能な時間長に渡り使用可能である物理リソースを正確に定義することができる。当然ながらこの方法の直接的な恩恵として、端末は、一時的な送信用無線リソースプールに関する情報を含む対応するシステム情報ブロードキャストを受信して処理した時点で、直ちに直接通信送信用のリソースにアクセスすることができる。その一方で、ネットワーク事業者は、このようなリソースが端末のセル内で端末に共通に利用可能になる時間を柔軟に制御することができる。RRC接続を確立しているUEの数は、セル内のアイドルモードにあるUEの総数よりも非常に少ないため、追加の一時的な送信用無線リソースプールは、SIB18においてブロードキャストされる従来技術の(モード2の)アイドル状態送信用無線リソースプールと比較して、サイズの面で十分に効率的/少量とすることができる。追加の一時的な送信用無線リソースプールは、このようなアイドル状態送信用無線リソースプールを実際に提供しないセル内に存在する端末にとって、特に有利である。しかしながら、追加の一時的な送信用無線リソースプールは、アイドル状態送信用無線リソースプールを実際にブロードキャストする他方のタイプのセル内の端末にとっても有利である。なぜなら、その場合、端末がすでに接続状態にあるが直接通信送信に使用するための専用リソースが基地局によってまだ割り当てられていないとき、または端末がD2D通信のデータをまだ実際に送信していないときにも、直接通信送信用のリソースが利用可能であるためである。
要約すると、従来技術のアイドル状態送信用無線リソースプールの代わりに、またはこれに加えて、第1の態様の一時的な送信用無線リソースプールを、セルのシステム情報ブロードキャストの中で提供することによって、端末の直接通信の遅延または中断が減少する、またはほぼ排除され、それと同時に、ネットワーク事業者には、このようなリソースに対するできる限り多くの制御が与えられる。具体的な実装によって異なるが、タイプAのネットワークのセル(すなわちシステム情報にアイドル状態送信用無線リソースプールが含まれない)においては、端末は、上述した一時的な送信用無線リソースプールを受け取った後、すなわち図18に示した期間A、期間B、期間C、および期間Dの間、このリソースプールからリソースを使用することができる。タイプBのネットワークのセルにおいては、端末は、期間B+C+Dの間、一時的な送信用無線リソースプールからリソースを使用することができる。
第1の態様のさらなる実装形態は、セル内の送信側端末によって一時的な送信用無線リソースプールが使用可能である時間長を、設定情報によって制限する方法に関する。例えば、システム情報ブロードキャストが、一時的な送信用無線リソースプールの適切な時間長(例:10ms、100ms、2000ms)を直接示すことができる。この場合、具体的な実装によって異なるが、端末は、この示された時間長を、例えばシステム情報ブロードキャストを受信した後にその特定の時間に渡り一時的な送信用無線リソースプールが使用可能であるものと解釈する。あるいは、端末がシステム情報ブロードキャストを受信したときにタイマを起動する代わりに、送信側端末が(例えば直接通信送信において別の端末にスケジューリング割当てを送信することによって)一時的な送信用無線リソースプールの使用を開始したときに、タイマを起動することができる。いずれの場合にも、この方法の具体的な恩恵として、このような設定は無線接続の確立手順およびその結果とは無関係であり、したがって基地局によって予測可能である。
時間長を直接示す代わりに、またはそれに加えて、端末がこのリソースをそれ以上使用することを停止させる特定の条件/イベントを指定することよって、一時的な送信用無線リソースプールが使用可能である時間を「間接的に」制限することができる。例えば、一時的な送信用無線リソースプールに関連する指示として、これらのリソースの使用を望む端末は、その端末がアイドル状態を維持してこのようなリソースを無制限に使用することを回避するため、基地局との無線接続の確立をさらに試みなければならないという指示を、システム情報ブロードキャストに含めることができる。この場合、端末には、接続が確立されて基地局によって専用無線リソースが端末に割り当てられるまでの間のみ(図18の期間A+B+Cを参照)、その一時的な送信用無線リソースプールからリソースを使用することが許可され、専用無線リソースが割り当てられた後の直接通信送信には、代わりにその専用無線リソースが使用される。または、接続を確立することができない、あるいは接続が拒否される場合、その確立の失敗について端末に通知されるまでの間のみ(図19の期間Aを参照)、一時的な送信用無線リソースプールからリソースを使用することが端末に許可される。または、その時点において基地局が、端末との接続は確立するが、端末が直接通信送信を実行することを許可しないことがある(図18の期間A+Bを参照)。さらには、基地局によって端末に割り当てられた専用無線リソースを端末が実際に使用するまでにかかる時間が長くなりうることを考慮して、さらなる代替方式では、端末が(基地局との無線接続を確立し、直接通信送信用の専用無線リソースを基地局から受信した後)、基地局によって端末に割り当てられたこれらの専用無線リソースを使用してスケジューリング割当て(SA)またはデータの直接通信送信を実際に実行する時点まで(図18の期間A+B+C+Dを参照)、一時的な送信用無線リソースプールが使用可能である時間を延長することができる。
接続を確立させる実際の指示は、例えば、具体的な時間長であって、その時間内に端末が接続の確立を(少なくとも)開始する(例えばシステム情報ブロードキャストを受信した直後、または一時的な送信用無線リソースプールの使用を開始した直後に開始する)必要のある時間長を示すことができる。さらに別のオプションとして、直接通信送信用に一時的な送信用無線リソースプールから無線リソースを使用することが許可される前に、端末が接続の確立を開始するように要求する。この目的においては、端末は、一例としてランダムアクセス手順のプリアンブルを送信することによって、基地局との接続の確立を開始するものと理解することができる。
これに加えて、第1の態様においては、従来技術のアイドル状態送信用無線リソースプールの場合と同様に、一時的な送信用無線リソースプールにおいて、スケジューリング割当て(SA)を直接リンクを通じて別の端末に直接通信送信するために利用可能なリソースと、「直接」データを直接リンクを通じて別の端末に直接通信送信するために利用可能なリソースとを、区別することができる。したがってセルは、スケジューリング割当て(SA)の送信用とデータの送信用に、異なるリソースを提供することができる。
ここまで、第1の態様のいくつかの異なる実装形態を説明してきた。以下では、この第1の態様およびその実装形態の背後の原理を、LTEシステム(背景技術のセクションで説明したLTEシステムなど)に例示的に適用する。
特に、3GPPによる現在の標準化では、ProSe直接通信および直接発見に関連するいくつかの情報を、SIB18を使用して含めることが考慮されている。したがって、上述した一時的な送信用無線リソースプールに関する情報およびその設定情報を、このSIBタイプ18の一部とすることができる。当然ながら、この第1の態様の目的には、任意の別のタイプのシステム情報ブロックを使用してこの情報を伝えることができることに留意されたい。さらに、具体的な例においては、一時的な送信用無線リソースプールおよびその設定情報を伝えるための、システム情報ブロック内の選択されたフィールドは、「commTxPoolTemp」と称する。この場合にも、この態様の目的には、このフィールドに対して任意の別の名前を選ぶことができる、あるいは一時的な送信用無線リソースプールに関する情報を、対応する設定情報の別のフィールドに挿入できることに留意されたい。特定の変数commSA-TxResourcePoolCommonTempおよびcommData-TxResourcePoolCommonTempに選択される名前およびフォーマットにも、同じことがあてはまる。
したがって、システム情報ブロックタイプ18の情報エレメントの以下の定義は、単なる例として理解されたい。
第1の態様において、従来技術と比較してこの例示的なシステム情報ブロックタイプ18の情報エレメントに導入された重要な変更箇所は、容易に認識できるように太字とし下線を引いてある。表から明らかであるように、この特定の例においては、設定情報は変数「allowedTime」として実施されており、この変数は、上述したように例示的な時間の値として100ms、200msなどをとり、したがって時間長を直接制限する。当然ながら、これらの具体的な時間値と、設定可能である時間値の数は、単なる例として理解されたい。任意の別の時間値と、設定可能な時間値の数を適宜選択することができる。端末は、変数「allowedTime」によって示される値を読み取ることによって、そのシステム情報ブロードキャストを受信した後に(または直接通信を実行するために端末が一時的な送信用無線リソースプールからのリソースの使用を開始した後に)一時的な送信用無線リソースプールが使用可能である時間長を求めることができる。UEは、対応するタイマを設定および起動して、監視することができる。
さらなる代替として、SIB18の定義の別の例を以下に示す。上の例示的な定義の場合と同様に、変数に付けられている名前と、変数に与えられた具体的な値は、単なる例として理解されたい。
第1の態様において、従来技術と比較してこの例示的なシステム情報ブロックタイプ18の情報エレメントに導入された重要な変更箇所は、容易に認識できるように太字とし下線を引いてある。上の表から明らかであるように、一時的な送信用無線リソースプール(すなわちcommTxPoolTemp)の使用を、後から説明するように異なる終了条件に基づいて間接的に制限するため、設定変数timeToInitiateRRCConnEstが含まれている。この設定変数timeToInitiateRRCConnEstを使用することによって、UEには、上に示したように例示的な時間である1msまたは5msなどの時間内にeNBとのRRC接続の確立を試みるように指示される。UEのさまざまな挙動に応じて、例えば、RRC接続が確立されてeNBが専用無線リソースを端末に割り当てるまで、または、RRC接続の確立に失敗したことをUEが認識するまで、または、セル内では直接通信の実行が許可されないことをeNBがUEに通知するまで、または、eNBによってUEに割り当てられた専用リソースを使用してスケジューリング割当て(SA)またはデータの直接通信を実際に実行するまで、UEに、一時的な送信用無線リソースプールのリソースの使用を許可することができる。
さらに、この新規のフィールドcommTxPoolTempは、SIB18におけるオプションであり、したがってこのフィールドをセル内でブロードキャストするか否かの決定はネットワーク事業者に委ねられることに留意されたい。commIdleTxPoolフィールド(最新の技術においてすでに定義されている)もオプションであるため、結果としてネットワーク事業者は、必要に応じてcommIdleTxPoolフィールドおよびcommTxPoolTempフィールドの一方または両方を(eNBを介して)設定する、またはいずれも設定しないことができる。
当然ながら、上に示したSIB18の複数の定義を組み合わせることも可能であり、これにより、commTxPoolTempフィールドに変数「allowedTime」および「timeToInitiateRRCConnEst」が含まれるように設定することができる。
[第2の実施形態]
本発明の第2の態様も、従来技術に内在する上述した問題を解決するが、異なる方法で解決する。第1の態様において行ったようにシステム情報ブロードキャストの中に追加の送信用無線リソースプールを定義する代わりに、この第2の態様は、事前に設定される送信用無線リソースプールを、(従来技術において現在定義されているように)端末がセルのカバレッジ外であるときのみならず、端末がセルのカバレッジ内であるときにも、直接通信送信用に使用するという発想に基づく。この文脈において「事前に設定される」は、基地局からのシステム情報ブロードキャストによって設定される、「設定される」リソースとは区別される。言い換えれば、事前に設定されるリソースは、例えば、たとえ無線アクセスから何らの情報を受信しなくても端末(および基地局)に既知であり、すなわちセルおよびセル内のシステム情報ブロードキャストとは無関係である。事前に設定される無線リソースは、それ自体は最新の技術に属し、セルのカバレッジ外である(すなわちセルの基地局から何らのシステム情報ブロードキャストも受信していない)UEによってすでに使用されている。
例えば、事前に設定される送信用無線リソースプールは、ネットワーク事業者によって定義し、最も一般的な携帯電話に挿入して使用することのできる共通のsim/USIMカードにハードコーディングすることができる。これに代えて、そのような事前に設定される送信用無線リソースプールに関する適切な情報を、上位レイヤシグナリングを使用して(例えばコアネットワークからインターネットプロトコルまたは非アクセス層プロトコルを介して)端末に提供することができる。
端末は、セルのカバレッジ内であるときにも、事前に設定される送信用無線リソースプールから無線リソースを使用することによって、直接通信送信を実行することができる。このことは、自身がシステム情報ブロードキャストを受信するか、システム情報ブロードキャストにリソースプールに関する情報が含まれているか、無線接続が確立されているか否か、端末が現在どの状態(アイドル状態または接続状態)にあるか、には無関係である。したがって端末は、直接通信送信に関して抑制される、遅延される、または中断されることがない。したがって第1の実施形態とは異なり、第2の態様によると、端末は、期間A,B,C,Dに加えて期間0においても直接通信送信を実行することができる。
1つのオプションは、カバレッジ外の端末を対象として最新の技術においてすでに定義されている、事前に設定される送信用無線リソースプールを、基地局のセルのカバレッジ内である端末にも適用されるように再設定することである。
その一方で、代替のオプションは、カバレッジ外の端末を対象として最新の技術においてすでに定義されている、事前に設定される送信用無線リソースプールに加えて、新規の事前に設定されるカバレッジ内送信用無線リソースプール(in-coverage preconfigured transmission radio resource pool)を設定することであり、この事前に設定されるカバレッジ内送信用無線リソースプールは、カバレッジ内である端末に適用されるが、依然として基地局のセルのカバレッジ外である端末が使用することはできない。この場合、最新の技術のカバレッジ外を対象とする事前に設定される送信用無線リソースプールと、第2の態様による、事前に設定されるカバレッジ内送信用無線リソースプールの両方を、sim/USIMカードに記憶する、またはこれに代えて、上述したように上位レイヤシグナリングによって定義することができる。
第2の態様のさらなる発展形態においては、ネットワーク事業者は、この事前に設定される送信用無線リソースプールが、(たとえ特定の端末に対してこのリソースプールが事前に設定されている場合でも)自社のセル内で実際に使用可能であるかに関して一部の制御を行う。例えばネットワーク事業者は、自社のセル内では、これらの事前に設定される送信用無線リソースプールのリソースが端末に利用可能ではないことを決定することができる。これを目的として、セルのカバレッジ内である端末に、事前に設定される送信用無線リソースプールの使用が許可されるか否かを、システム情報ブロードキャストが適切に示す。
これを示すための1つの可能かつ単純な方法は、システム情報の中の1ビットのフラグであり、一方のビット値は、セルのカバレッジ内の端末に対して、事前に設定される送信用無線リソースプールの使用が許可されることを示し、他方のビット値は、許可されないことを示す。
これに代えて、システム情報は、事前に設定される送信用無線リソースプールの設定情報をオプションとして含むことができ、この設定情報が存在しないときには、端末は、事前に設定される送信用無線リソースプールが使用されないことを認識する。これに対して、事前に設定される送信用無線リソースプールに関する設定情報がシステム情報の中に存在する。したがってセルにアタッチされている端末によって受信されるときには、その端末は、直接通信送信用に、事前に設定される送信用無線リソースプールを引き続き使用できるが、このリソースプールの使用に関してその設定情報がさらに適用されることを認識する。
設定情報は、さまざまな形をとることができる。例えば、第2の態様の改良形態によると、セルのカバレッジ内である間の、この事前に設定される送信用無線リソースプールの使用を時間的にも制限することが有利である。第1の態様に関連して説明したように、特定の無線リソースプールが端末に使用可能である時間長を制限する方法として、いくつかの可能な方法がある。したがって、事前に設定される送信用無線リソースプールの設定情報は、一時的な送信用無線リソースプールの場合に上述した設定情報に類似する、または同じとすることができる。
詳細には、システム情報ブロードキャストは、事前に設定される送信用無線リソースプールの適切な時間長を例えば直接示す(例:10ms,100ms,2000ms)ことができる。この場合、具体的な実装によって異なるが、端末は、この示された時間長を、事前に設定される送信用無線リソースプールが、例えばシステム情報ブロードキャストを受信した後にその特定の時間にわたり使用可能であるものと解釈する。あるいは、端末がシステム情報ブロードキャストを受信したときにタイマを起動する代わりに、送信側端末が(例えば直接通信送信においてスケジューリング割当て(SA)を別の端末に送信することによって)事前に設定される送信用無線リソースプールの使用を開始したときに、タイマを起動することができる。
時間長を直接示す代わりに、またはこれに加えて、端末がこのリソースをそれ以上使用することを停止させる特定の条件/イベントを指定することよって、事前に設定される送信用無線リソースプールが使用可能である時間を「間接的に」制限することができる。例えば、事前に設定される送信用無線リソースプールに関連付けられる指示として、これらのリソースの使用を望む端末は、その端末がアイドル状態を維持してこのようなリソースを無制限に使用することを回避するため、基地局との無線接続の確立をさらに試みなければならないという指示を、システム情報ブロードキャストに含めることができる。この場合、端末には、接続が確立されて基地局が専用無線リソースを端末に割り当てるまでの間のみ(図18の期間0+A+B+Cを参照)、その事前に設定される送信用無線リソースプールからリソースを使用することが許可され、専用無線リソースが割り当てられた後の直接通信送信には、代わりにその専用無線リソースが使用される。または、接続を確立することができない、あるいは接続が拒否される場合、その確立の失敗について端末に通知されるまでの間のみ(図19の期間0+Aを参照)、一時的な送信用無線リソースプールからリソースを使用することが端末に許可される。または、その時点において基地局が、端末との接続は確立するが、端末が直接通信送信を実行することを許可しないことがある(図18の期間0+A+Bを参照)。さらには、基地局によって端末に割り当てられた専用無線リソースを端末が実際に使用するまでにかかる時間が長くなりうることを考慮して、さらなる代替方式では、端末が(基地局との無線接続を確立し、直接通信送信用の専用無線リソースを基地局から受信した後)、基地局によって端末に割り当てられたこれらの専用無線リソースを使用してスケジューリング割当て(SA)またはデータの直接通信送信を実際に実行する時点まで(図18の期間0+A+B+C+Dを参照)、事前に設定される送信用無線リソースプールが使用可能である時間を延長することができる。
接続を確立させる実際の指示は、例えば、具体的な時間長であって、その時間内に端末が接続の確立を(少なくとも)開始する(例えばシステム情報ブロードキャストを受信した直後、または事前に設定される送信用無線リソースプールの使用を開始した直後に開始する)必要のある時間長を示すことができる。さらに別のオプションとして、直接通信送信用に、事前に設定される送信用無線リソースプールからの無線リソースを使用することが許可される前に、端末が接続の確立を開始するように要求する。この目的においては、端末は、一例としてランダムアクセス手順のプリアンブルを送信することによって、基地局との接続の確立を開始するものと理解することができる。
事前に設定される送信用無線リソースプールは、実際の物理無線リソース(すなわち時間および周波数)を定義することができ、オプションとして、物理無線リソースに関連付けられる特定の送信フォーマットまたは送信電力も定義することができる。さらに、端末がカバレッジ内であり、事前に設定される送信用無線リソースプールを直接通信送信用に使用するとき、それらの送信の電力を基地局によって(通常の方法で)制御することができる。
ここまで、第2の態様のいくつかの異なる実装形態について説明してきた。以下では、第2の態様およびその実装形態の背後の原理を、LTEシステム(背景技術のセクションで説明したLTEシステムなど)に例示的に適用する。
第2の態様に関連して上述したいくつかの実装形態によると、カバレッジ内であるときに事前に設定される送信用無線リソースプールの使用を許可する/許可しないため、および/または、このリソースの使用を設定するため、基地局からのシステム情報ブロードキャストを修正する。
第1の態様において説明したように、3GPPによる現在の標準化では、ProSe直接通信および直接発見に関連するいくつかの情報を、SIB18を使用して含めることが考慮されており、SIB18は、上述したフラグや設定情報を伝えることができる。当然ながら、この第2の態様の目的において、任意の別のタイプのシステム情報ブロックを使用してこれらの情報を伝えることができることに留意されたい。以下では、極めて具体的な例を示す。設定および設定変数には具体的な名前が付けられており(すなわち、usePreconfigResInCoverage、allowedTime、timeToInitiateRRCConnEst)、これらの変数は具体的に設定されている(すなわち、ms100、ms200、ms300など、ms01、ms05など)。この場合も、この第2の態様の目的において、フィールドに対して任意の別の名前を選ぶことができ、変数の実際の値は、異なる値とすることができることに留意されたい。
第2の態様において、従来技術と比較してこの例示的なシステム情報ブロックタイプ18の情報エレメントに導入された重要な変更箇所は、容易に認識できるように太字とし下線を引いてある。
上の表から明らかであるように、設定情報のフィールド「usePreconfigResInCoverage」はオプションであり、したがってシステム情報ブロードキャストの中にこのフィールドが存在しているときには、UEは、カバレッジ内であるときに、対応する事前に設定される送信用無線リソースプール(モード2のリソース)が利用可能であることを認識することができる。逆に、このフィールドが存在しないときには、UEは、対応する事前に設定される送信用無線リソースプールがそのセル内で利用可能ではないことを認識する。
設定変数「allowedTime」および「timeToInitiateRRCConnEst」は、それ自体は第1の態様においてすでに説明したものであり、この第2の態様においても同様に定義される。上の例から明らかであるように、これらの設定変数は同時に定義することもでき(eNBがそのように決定した場合)、これにより、事前に設定されるカバレッジ内送信用無線リソースプールが使用可能である時間長を直接的および/または間接的に制限することができる。したがって、この特定の例においては、設定情報の一部は変数「allowedTime」として実施されており、例示的な時間の値は、上に示したように100ms、200msなどであり、したがって時間長を直接制限する。端末は、変数「allowedTime」によって示される値を読み取ることによって、システム情報ブロードキャストを受信した後(または端末が直接通信を実行するために一時的な送信用無線リソースプールからのリソースの使用を開始した後)、事前に設定される送信用無線リソースプールが使用可能である時間長を求めることができる。UEは、対応するタイマを設定、起動、および監視することができる。
同様に、一時的な送信用無線リソースプール(すなわちcommTxPoolTemp)の使用を、後から説明するように異なる終了条件に基づいて間接的に制限するため、設定変数「timeToInitiateRRCConnEst」を含めることができる。この設定変数timeToInitiateRRCConnEstを使用することによって、上に示したように例示的な時間である1msまたは5msなどの間にeNBとのRRC接続の確立を試みるようにUEに指示される。UEのさまざまな挙動に応じて、例えば、RRC接続が確立されてeNBが専用無線リソースを端末に割り当てるまで、または、RRC接続の確立に失敗したことをUEが認識するまで、または、セル内での直接通信の実行が許可されないことをeNBがUEに通知するまで、または、eNBによってUEに割り当てられた専用リソースを使用してスケジューリング割当て(SA)またはデータの直接通信を実際に実行するまで、UEに、事前に設定される送信用無線リソースプールのリソースの使用を許可することができる。
さらには、この第2の実施形態は、第1の実施形態とは異なる単独の解決策として説明したが、一般的には、この第2の実施形態を第1の実施形態と組み合わせることができる。
[第3の実施形態]
本発明者は、D2D通信および現在の発展形態に関連してさらなる問題点を認識した。より詳細には、さまざまなシナリオにおいてUEがさまざまな期間に渡りD2D通信の実行を抑制されることに関する上述した問題とは別に、もう1つの問題は、状態3カバレッジ外(OOC)UEと状態4カバレッジ外(OOC)UEに関連する。具体的には、特定のUEが、自身が状態3(CP UE中継)にあるのか状態4にあるのかを認識する方法がまだ明確ではない。このことはさらなる問題につながり、UEは、D2D通信を実行するために使用するべきリソースおよび送信電力が明らかではない。
図11と、背景技術のセクションの対応する説明箇所には、UEがとりうる4つの一般的な状態について説明してある。これらの状態は、次のように要約される。
状態1: セルのカバレッジ内(IC)(セルの中央に極めて近い)
状態2: セルのカバレッジ内(IC)(セルの周縁部)
状態3: セルのカバレッジ外(セルのすぐ外側)。このようなUEは、衝突するリソースにおいて高い送信電力で送信する「ならば」、何らかのWAN干渉を発生させうる。
状態4: セルの「真の」カバレッジ外。たとえ衝突するリソースにおいて高い送信電力で送信しても、いかなる種類のWAN干渉も発生させることはない。
明らかに、状態3および状態4のいずれにおいてもUEはセルのカバレッジ外であるが、UEが状態3と状態4を区別する方法は不明確である。なぜなら、UEは、自身がセルのカバレッジ内ではない(すなわちいかなるWANセルにもキャンプオンしていない)ことを認識するのみであるためである。
以下の解決策が可能である。
UEは、PD2DSCHを受信した場合、自身が状態3であるとみなし、特定の事前に定義された(または設定可能な)時間に渡りPD2DSCHを受信しない場合、UEは自身を状態4であるとみなす。PD2DSCHは、背景技術のセクションで説明したように、eNBによって何基かのカバレッジ内(IC)UEを介してOOC(カバレッジ外)UEに送られる物理レイヤ情報である(カバレッジ内(IC)UEはPD2DSCHを転送する)。PD2DSCHは、D2D通信用のいくらかのリソースをシグナリングする。OOC(カバレッジ外)UEによって受信された場合、D2D通信用にPD2DSCHにおいて受信されたリソースは、OOC(カバレッジ外)UEに利用可能である事前に設定されるモード2のリソースよりも優先される。これは有利であり、なぜならこのような方策をとらない場合、これらのUEは自身を状態4にあるとみなし、矛盾するリソースにおいて高い送信電力で送信することがあり、事前に設定されるモード2のリソースを使用することによって何らかのWAN干渉が発生しうる。
状態3のUEは、PD2DSCHまたはD2DSS(D2D同期信号)の受信が、事前に定義された期間に渡り停止したとき、自身を再び状態4のUEとみなす。
このようにUEが状態3と状態4を区別する方法を指定することによって、WAN通信との何らの問題(干渉)も引き起こされないように、D2D通信を実行するのにUEが使用するべきリソースおよび送信電力を効率的に選択/計算することができる。
なお、上に説明した第3の実施形態は、前述した第1の実施形態および/または第2の実施形態と組み合わせることができることに留意されたい。
[第4の実施形態]
D2D通信に関して認識される別の問題として、現在の標準化では、どのUEがPD2DSCHをカバレッジ外(OOC)UEに転送する役割を担うかが不明確である。
以下の代替解決策が可能である。以下の解決策を組み合わせることも可能である。
一般的には、十分にセルのカバレッジ内であり(例えばサービングセルのRSRPおよびRSRQの測定値が良好)、ただしセルの中央付近ではないUEは、PD2DSCHを転送するうえでの良好な候補であり得る。具体的には、特定の無線受信値が事前に定義されたしきい値の間である(例:RSRP(基準信号受信電力)/RSRQ(基準信号受信品質)の測定値が特定のしきい値「x」としきい値「y」との間である)UEである。このような場合、しきい値xおよびしきい値yがPD2DSCHの内容と一緒にブロードキャストされる。
PD2DSCHを転送する別の可能な候補は、D2DSSを送信/転送するUEである。PD2DSCHの内容はブロードキャストされる。
別の可能な解決策は、PD2DSCHを転送するように、ネットワークが特定のUEに専用シグナリングにおいて明示的に要求することである。PD2DSCHの内容は、ブロードキャストされる、または専用シグナリングによってUEにシグナリングされる。
上の解決策の1つの可能な組合せは、D2DSSをすでに転送しており、かつ十分にセルのカバレッジ内である(すなわちRSRPまたはRSRQが対応するしきい値の間である)UEである。
なお、第4の実施形態は、第1の実施形態、第2の実施形態、および第3の実施形態のうちのいずれかと一緒に、またはこれらの任意の組合せと一緒に、使用できることに留意されたい。
[第5の実施形態]
D2D通信に関して認識されるさらに別の問題は、D2D通信における受信/送信動作に関連する。背景技術のセクションで説明したように、D2D通信の送信動作は、リソース割当てモードに応じてわずかに異なる。モード1のD2D通信の場合、eNBがD2Dグラント(すなわちD2D−RNTIによってスクランブルされた(E)PDCCH)を、D2D送信側UEに発行し、このD2Dグラントは、スケジューリング割当て(SA)の送信用のリソースのみならず、データ(ProSe/D2Dデータ)用のリソースも割り当てる。より詳細には、このD2Dグラントは、少なくとも、スケジューリング割当て(SA)リソースのインデックス(SAリソースインデックス)(スケジューリング割当て(SA)を送信するのにD2D送信側UEによって使用される、SAリソースプール内の時間/周波数リソースを指す)と、T−RPTインデックスフィールドおよびデータRB割当てフィールド(基本的にはD2Dデータ送信用の時間/周波数リソースを示す)とを含む。T−RPTインデックスフィールドは、すべての利用可能なT−RPTパターンをリストしたテーブル(このテーブルは例えば128個のエントリを含む)内の1つのエントリを参照する。送信の時間リソースパターン(T−RPTパターン)は、D2Dデータリソースプール内のD2Dデータ送信の時間リソースパターンを定義する。
D2D送信側UEは、eNBからD2Dグラントを受信すると、スケジューリング割当て(SA)メッセージの送信または再送信に使用するべきサブフレームおよび周波数リソースをSAリソースプール内で求める目的で、SAリソースインデックスを使用する。さらに、D2D送信側UEは、D2DデータPDUの送信に使用するべきサブフレーム(および場合によっては、D2Dグラント内で伝えられた何らかの別の情報に基づく周波数リソース)を求める目的で、少なくとも、D2Dグラントの中で受信したT−RPTインデックス情報を使用する。D2DデータPDUの送信用のサブフレームを導くための関数は、モード1のD2D送信とモード2のD2D送信とで異なる。モード2のD2D送信の場合、D2D送信側UEは、リソースプールのビットマップの中で1として表されるサブフレームに、T−RPTパターンを適用する。基本的にD2D送信側UEは、モード2のD2Dデータ送信用リソースプールに従ってモード2送信に使用可能なD2Dサブフレームとして定義されているサブフレームに、T−RPTパターンを適用する。一例を図22に示してある。
送信リソースプールのビットマップの中の1は、いわゆるD2Dサブフレーム(すなわちモード2のD2D送信用に予約されたサブフレーム)を表す。これらのD2DサブフレームにT−RPTパターンが適用される。図22において理解できるように、対応するT−RPTエントリが1であるD2Dサブフレーム(リソースプールのビットマップのエントリとT−RPTビットマップのエントリの両方が1であるサブフレーム)が、D2DデータPDUの送信に使用される。背景技術においてすでに説明したように、モード2のリソース割当ての場合、D2D送信側UEは、T−RPTパターンを自律的に選択してそれをスケジューリング割当て(SA)の中でシグナリングする。したがってD2D受信側UEは、(スケジューリング割当て(SA)を正常に復号した後、)受信されたT−RPTパターンに基づいて、D2Dデータ送信の時間/周波数リソースを求めることができる。モード2のD2D送信の場合、D2Dグラントは存在しない。
モード1のD2D送信の場合、すでに上述したように、eNBが、D2D送信に使用されるT−RPTパターンを割り当てて、それをD2DグラントによってD2D送信側UEにシグナリングする。
モード1の場合にはD2D送信用のリソースプールが存在しないことを考慮して、T−RPTのパラメータが物理アップリンクサブフレームに直接適用される。なぜなら、すべてのアップリンクサブフレームをD2Dサブフレームとすることができるためである。例示的な一実施形態によると、D2D送信側UEは、D2Dグラントの中のT−RPTパターンインデックスによって示されるT−RPTパターンを、リソースプールのビットマップ内のすべてのサブフレーム(すなわちビットマップのエントリが1であるサブフレームおよび0であるサブフレーム)に適用する。モード1のD2Dデータ送信の場合の例を、図21に示してある。
図から理解できるように、この場合も、モード2のD2D送信を説明した例示的なシナリオにおいて使用されたものと同じT−RPTパターンを例として使用する。しかしながらモード1の場合、T−RPTパターンはリソースプール内のすべての(アップリンク)サブフレームに適用される。モード1の場合、データ送信用のリソースプールが定義/設定されないため、D2D送信側UEは、T−RPTパターンを、モード2のデータ送信用リソースプールあるいはデータ受信用リソースプールのいずれかに適用することができる。重要なことは、モード1の場合にT−RPTパターンを適用するときの何らかの基準サブフレーム、すなわち開始サブフレームが必要であることである。これに代えて、D2Dデータの最初の送信とスケジューリング割当て(SA)との間の何らかのタイミング関係を事前に定義することができる。例えば、モード1でのD2Dデータの最初の送信機会(すなわちこれはT−RPTパターンの開始サブフレームである)は、スケジューリング割当て(SA)メッセージの前回の送信からx ms後に発生する。
D2D送信側UEによってモード1のD2Dデータ送信が使用されるかモード2のD2Dデータ送信が使用されるかに応じて、T−RPTパターンの使用方法が異なる。したがってD2D受信側UEは、モード1のD2Dデータ送信とモード2のD2Dデータ送信とを区別できる必要がある。より詳細には、D2D受信側UEは、SAリソースプール内でスケジューリング割当て(SA)を受信するとき、T−RPTパターンを正しく解釈することができるように(すなわち対応するD2Dデータ送信の正しい時間/周波数リソースを求める目的で)、そのスケジューリング割当て(SA)がモード1のD2Dデータ送信によって送信されたのかモード2のD2Dデータ送信によって送信されたのかを認識できる必要がある。別の例示的な実施形態によると、スケジューリング割当て(SA)メッセージには、D2D通信に使用されたリソース割当てモードの明示的なインジケータが含まれる。すなわち、スケジューリング割当て(SA)メッセージの中の新規のフィールドが、D2Dデータ送信にモード1が使用されたかモード2が使用されたかを示す。
代替の解決策として、送信/リソース割当てモードは、スケジューリング割当て(SA)メッセージの中でシグナリングされるT−RPTパターンによって暗黙的に示される。事前に設定されるかまたはテーブル形式で与えられる利用可能なT−RPTパターンが2つのセットに分割され、T−RPTパターンの一方のセットがモード1の送信に使用され、T−RPTパターンの2番目のセットがモード2に使用される。例えば、128個の異なるT−RPTパターンを想定すると、パターン0〜63をモード1のD2D送信に使用することができ、インデックス64〜127のT−RPTパターンはモード2用に予約される。D2D受信側UEは、スケジューリング割当て(SA)の中の受信されたT−RPTインデックスに基づいて、送信側UEがリソース割当てモード1を使用しているのかモード2を使用しているかを認識することができる。
さらに別の例示的な実施形態によるさらなる代替の解決策として、リソース割当て/送信モードを、スケジューリング割当て(SA)に含まれているTAフィールドの値から導くことができる。モード1の送信とモード2の送信では、異なる送信タイミングを使用するため、受信側UEは、モード1の送信とモード2の送信とを、TAフィールドの値に基づいて区別することができる。例えば、モード2の送信の場合のTA値はつねに0であるのに対して、モード1ではTA値はUEのNTA値に設定される(すなわちUEは、モード1のD2D送信においてはレガシーアップリンク送信タイミングを使用する)。
さらなる代替策として、リソース割当て/送信モードを、スケジューリング割当て(SA)メッセージの送信に使用される周波数リソースによって暗黙的に示すことができる。例えば、モード2の送信側UEによって送信されるスケジューリング割当て(SA)メッセージと、モード1の送信側UEによって送信されるスケジューリング割当て(SA)は、使用される周波数リソースが異なる。より詳細には、モード2の場合のSA送信リソースプールは、スケジューリング割当て(SA)の送信用にeNBによって割り当てられるリソース(モード1)とは異なる。
本発明のさらなる例示的な実施形態によるさらに別の代替の解決策は、モード1の送信とモード2の送信とを区別する必要がないように、T−RPTパターンのビットマップの長さを定義することである。より詳細には、T−RPTパターンのビットマップの長さは、T−RPTパターンが適用されるリソースプールのビットマップの長さと同じであるべきである。上に説明した図21および図22に示した例をとると、T−RPTパターンの長さは30ビットであるべきである。
モード1およびモード2の両方のT−RPTパターンは同じ開始サブフレーム(例えばリソースプールの開始サブフレーム)に適用されるため、D2D受信側UEは、モード2の送信とモード1の送信とを区別する必要がない。
なお、第5の実施形態は、第1の実施形態、第2の実施形態、第3の実施形態、および第4の実施形態のうちのいずれかと一緒に、またはこれらの任意の組合せと一緒に、使用できることに留意されたい。
[ハードウェアおよびソフトウェアによる本開示の実施]
別の例示的な実施形態は、上述したさまざまな実施形態を、ハードウェアおよびソフトウェアを使用して実施することに関する。これに関連して、ユーザ機器(移動端末)およびeNodeB(基地局)を提供する。ユーザ端末および基地局は、本明細書に記載されている方法を実行するようにされている。
本発明のさまざまな実施形態は、コンピューティングデバイス(プロセッサ)を使用して実施または実行され得るものとさらに認識される。コンピューティングデバイスまたはプロセッサは、例えば、汎用プロセッサ、デジタル信号プロセッサ(DSP:Digital Signal Processor)、特定用途向け集積回路(ASIC:Application Specific Integrated Circuit)、フィールドプログラマブルゲートアレイ(FPGA:Field Programmable Gate Arrary)、または、その他プログラマブルロジックデバイスなどである。本発明のさまざまな実施形態は、これらのデバイスの組合せによっても実行または具体化され得る。
さらに、本発明のさまざまな実施形態は、ソフトウェアモジュールによっても実施され得る。これらのソフトウェアモジュールは、プロセッサによって実行され、または、ハードウェアにおいて直接実行される。また、ソフトウェアモジュールとハードウェア実装の組合せも可能である。ソフトウェアモジュールは、任意の種類のコンピュータ可読記憶媒体、例えば、RAM又はEPROM、EEPROM、フラッシュメモリ、レジスタ、ハードディスク、CD−ROM、DVDなどに格納され得る。
さらには、複数の異なる実施形態の個々の特徴は、個別に、または任意の組合せにおいて、別の実施形態の主題とすることができることに留意されたい。
具体的な実施形態において示した本開示には、さまざまな変更もしくは修正またはその両方を行うことができることが、当業者には理解されるであろう。したがって、本開示の実施形態は、あらゆる点において例示的であり、本発明を制限するものではないものとみなされたい。