以下、添付の図面を参照しながら、本発明の実施形態を詳細に説明する。実施形態の以下の説明は、限定的な意味で解釈されないものとすることを理解されたい。本発明の範囲は、単に例示的なものに過ぎない図面又は以下で説明する実施形態によって限定されないものとする。
図面は概略表現であるとみなされ、図面に示される要素は、必ずしも縮尺通りに示されていない。むしろ、様々な要素は、それらの機能及び一般的な目的が当業者に明らかになるように表される。図面に示されている、又は本明細書に記載されている機能ブロック、デバイス、構成要素、又は他の物理的又は機能的ユニット間の任意の接続又は結合は、間接的な接続又は結合によっても実装され得る。構成要素間の結合は、ワイヤレス接続を介して確立されてもよい。
機能ブロックは、ハードウェア、ファームウェア、ソフトウェア、又はそれらの組み合わせで実装され得る。
以下では、一方では、第1のスペクトル内のリソースを含み、第1のRATに従って動作する少なくとも1つの狭帯域キャリア上の通信、他方では、第2のスペクトル内のリソースを含み、第2のRATに従って動作する広帯域キャリア上の通信を、同時配備する技法が開示されている。
同時配備は、狭帯域キャリアと広帯域キャリアとの間の干渉が存在する、少なくとも重複する地理エリアにおける第1及び第2のRATを介した通信を可能にすることを指し得る。同時配備は、第1及び第2のRAT上の通信間の干渉を回避するために、制御された干渉緩和を含むことができる。したがって、同時配備は、調整された方法で第1及び第2のRATを介して通信することに対応し得る。例えば、少なくともロールアウト中などに、集中調整が適用されてもよい。例えば、同時配備は、第1及び第2のRATの配備を調整する1つ以上のネットワークオペレータに対応し得る。
RATは、無線リンク上で通信するための物理的接続技術に対応し得る。したがって、RATは、無線リンク上での通信を可能にする1組のルールを指定することがある。RATは、RATのキャリアに関連付けられたスペクトルの周波数帯域の帯域幅、送信時間間隔(TTI)の持続時間、例えばターボコード、畳み込み符号化、インターリービングなどの変調及び符号化方式(MCS)、例えば直交周波数分割多重化(OFDM)、バイナリ位相シフトキーイング(BPSK)、ガウス型最小シフトキーイング(GMSK)などの変調を含むグループから選択された要素を指定し得る。異なるRATは、そのようなルールの少なくとも1つに関して異なり得る。
RATは、キャリア上で実装され得る。キャリアは、所定のRATに係る通信を実装することができるリソースの特定の組を指定する。したがって、各キャリアは、あるスペクトルを含み、あるスペクトル上で通信するための1つ以上の論理チャネルを実装し得る。典型的には、比較的大きい総帯域幅の1つ以上の周波数帯域を有するスペクトルを含むキャリアは、広帯域キャリアと呼ばれ、これは、典型的には狭帯域キャリアと呼ばれる、比較的小さい総帯域幅の1つ以上の周波数帯域を有するスペクトルを含むキャリアとは対照的である。ここで、狭帯域キャリア及び広帯域キャリアは、同時配備のシナリオでは、互いに関して相対的に定義され得る。
狭帯域キャリア及び広帯域キャリアの第1及び第2のスペクトルはそれぞれ、両方とも1つ以上の周波数帯域を含み得る。スペクトルの周波数帯域は、連続的に配置される必要はない。いくつかの例では、第1及び第2のスペクトルは重複しない場合があり、すなわち、第1のスペクトルと第2のスペクトルの両方によって含まれる共有スペクトルが存在しない場合がある。さらなる例では、第1及び第2のスペクトルは、共有スペクトルを含み、共有スペクトルは、周波数ドメインにおける重複を画定し得る。
特に、以下では、広帯域キャリアに対する狭帯域キャリアの帯域内シナリオの技法が開示される。帯域内配置は、第1のスペクトルが少なくとも部分的に第2のスペクトル内に配置されることに対応し得る。例えば、帯域内配備のシナリオでは、第1のスペクトルの1つ以上の周波数帯域が、例えば保護帯域(guard bands)なしで、第2のスペクトルの1つ以上の周波数帯域に隣接して配置され得る。
この文脈において、以下では、それぞれ少なくとも1つの狭帯域キャリア及び広帯域キャリアへのリソース割振りを柔軟に調整することを可能にする例が開示される。例えば、少なくとも1つの狭帯域キャリア上の通信がより高いデータレートを必要とするシナリオでは、追加のリソースを少なくとも1つの狭帯域キャリアに割り振る場合があり、ここでは、少なくとも1つの狭帯域キャリアのための追加のリソースが広帯域キャリアから取り除かれる可能性がある。
第1の例では、複数の狭帯域キャリア上での通信を実装することができる。複数の狭帯域キャリア上の通信は、いくつかのシナリオで、狭帯域キャリアアグリゲーション(CA)によって実装され得る。CAは、複数の狭帯域キャリアの各々について、第1のRATのそれぞれの通信プロトコルスタックの物理層の分離された、又は大きく分離された下端を実装し、通信プロトコルスタックを、例えば、メディアアクセス層又は物理層の上位のサブレイヤなど、下端の物理層より上のあるポイントにボンディングすることに対応し得る。CAは、複数のキャリアを介して単一の端末に通信することに対応する。複数の狭帯域キャリアを使用することによって、第1のスペクトルにおいて利用可能なリソースの量が増加し、それによって、第1のRATに係る通信のためのデータレートも増加させることができる。
第2の例では、少なくとも1つの狭帯域キャリアがそれに従って動作する第1のRATの第1のスペクトルと、広帯域キャリアがそれに従って動作する第2のRATの第2のスペクトルの両方が、共有スペクトルを含む。共有スペクトル内のリソースは、例えば、少なくとも1つの狭帯域キャリアの必要なデータレート、トラフィックスループットなどに応じて、少なくとも1つの狭帯域キャリア又は広帯域キャリアのいずれかに柔軟に割り振られ得る。したがって、第1及び第2のRATにわたる集中スケジューリングを実装することができる。例えば、スケジューリング方式は、少なくとも1つの狭帯域キャリアと広帯域キャリアとの間で、時分割多重化(TDM)方式で、共有スペクトル内のリソースを割り振り得る。
本明細書に開示される様々な例は、LTE及び/又はMTCに関するNB−IoTの同時配備シナリオの特定の適用例を見出すことができる。特に、NB−IoTの単一キャリアは、典型的には、例えば180kHzの帯域幅に関連付けられているが、LTEの単一キャリアは、1.4MHz〜20MHzの範囲内の帯域幅を有する。また、MTCの単一キャリアは、例えば1.4MHzの帯域幅を有する。したがって、NB−IoTキャリアは、LTEキャリア(広帯域LTEキャリア)及び/又はMTCキャリア(広帯域MTCキャリア)によって実装される広帯域キャリアに対して、狭帯域キャリア(狭帯域NB−IoTキャリア)を実装することができる。
したがって、少なくとも1つの狭帯域NB−IoTキャリア及び広帯域LTEキャリア若しくは広帯域MTCキャリアの文脈で様々なシナリオを説明するが、本明細書に開示される技法は、他の種類の広帯域キャリア及び/又は狭帯域キャリアに容易に適用することができる。例えば、広帯域キャリアに関しては、同様の技法を、GSM(Global Systems for Mobile Communications)、WCDMA(Wideband Code Division Multiplex)、GPRS(General Packet Radio Service)、EDGE(Enhanced Data Rates for GSM Evolution)、EGPRS(Enhanced GPRS)、UMTS(Universal Mobile Telecommunications System)、及びHSPA(High Speed Packet Access)などの様々な種類の3GPP指定のRAT、並びに関連のセルラーネットワークの対応するアーキテクチャに容易に適用することができる。例えば、狭帯域キャリアに関しては、同様の技法を、LTE−M(LTE-Machine to Machine)などの様々な種類の他のRATに容易に適用することができる。
図1は、すなわちLTE技術に係る、NB−IoT RAT191及びE−UTRA RAT192の同時配備シナリオの態様を概略的に示す。図1の例では、第1のアクセスノード112−1は、無線リンク101上に実装された狭帯域NB−IoTキャリア上で第1の端末130−1(図1ではユーザ機器、UEと表示)と通信する。狭帯域NB−IoTキャリアは、NB−IoT RATに従って動作する。第2のアクセスノード112−2は、無線リンク101上に実装された広帯域LTEキャリア上で第2の端末130−2と通信する。広帯域LTEキャリアは、E−UTRA RATに従って動作する。
図1の例では、第1の端末130−1及び第2の端末130−2は、所与の地理的エリアに配置され、したがって、原則として、狭帯域NB−IoTキャリア上の通信が広帯域LTEキャリア上の通信を妨害する可能性がある。したがって、図1の例では、制御シグナリングは、第1のアクセスノード112−1と第2のアクセスノード112−2との間で干渉緩和を容易にするよう実装される。いくつかの例では、第1のアクセスノード112−1及び第2のアクセスノード112−2が同一の場所に配置され(co-located)、単一のアクセスノードによって実装されることも可能である。そのようなシナリオが図2に示される。
図2は、いくつかの例示的な実装形態に係るセルラーネットワーク100のアーキテクチャを示す。特に、図2の例に係るセルラーネットワーク100は、時として発展型パケットシステム(EPS)と呼ばれることがある、3GPP LTEアーキテクチャを実装する。EPSはNB−IoTをサポートするように拡張されている。
第2の端末130−2は、無線リンク101を介して、セルラーネットワーク100のアクセスノード112に接続されている。アクセスノード112及び端末130−2は、E−UTRA RATを実装し、したがって、アクセスポイントノード112はeNB112である。例えば、第2の端末130−2は、スマートフォン、携帯電話、テーブル、ノート、コンピュータ、スマートテレビなどを含むグループから選択され得る。
第1の端末130−1は、無線リンク101を介してeNB112に接続されている。しかし、第1の端末130−1及びeNB112は、NB−IoT RATに従って通信する。例えば、第1の端末130−1は、IoTデバイスであってもよい。
IoTデバイスは、典型的には、例えばLTEデバイス又はMTCデバイスと比較すると、データトラフィック量に対する要求が低く、レイテンシ要件が緩やかなデバイスである。さらに、IoTデバイスを使用する通信は、低複雑度及び低コストを達成するはずである。特に、無線周波数(RF)モデムは低複雑度を有するはずである。さらに、IoTデバイスのエネルギー消費は、バッテリー電源式デバイスが比較的長い持続時間にわたって機能することを可能にするために、比較的低いはずである。バッテリー寿命は、例えば最大10年間の通信ケイパビリティを提供するほど十分に長いはずである。
eNB112は、サービングゲートウェイ(SGW)117によって実装されるゲートウェイノードに接続される。SGW117は、ペイロードデータをルーティング及び転送し、端末130−1、130−2のハンドオーバ中のモビリティアンカーとして働き得る。
SGW117は、パケットデータネットワークゲートウェイ(PGW)118によって実装されるゲートウェイノードに接続される。PGW118は、パケットデータネットワーク(PDN、図2には図示せず)に向かうデータのためのセルラーネットワーク110の出口点及び入口点として働き、このために、PGW118は、パケットデータネットワークのアクセスポイントノード121に接続される。アクセスポイントノード121は、アクセスポイント名(APN)によって一意に識別される。APNは、端末130−1、130−2によってパケットデータネットワークへのアクセスを求めるために使用される。
PGW118は、端末130−1、130−2のパケット化されたペイロードデータについてのエンドツーエンド接続(図2には図示せず)のエンドポイントとすることができる。エンドツーエンド接続は、特定のサービスのデータを通信するために使用され得る。異なるサービスは、異なるエンドツーエンド接続を使用してもよく、又は、少なくとも部分的に、あるエンドツーエンド接続を共有してもよい。エンドツーエンド接続は、サービス固有のデータを通信するために使用される1つ以上のベアラによって実装され得る。QoSクラス識別子(QCI)によって示される、あるサービス品質パラメータの組によって特徴付けられるEPSベアラ。
図3は、参照実装に係る同時配備シナリオにおける無線リンク101上の通信の態様を示す。図3は、広帯域LTEキャリア312と狭帯域NB−IoTキャリア311との間のリソース308の分布を示す。図3は、時間周波数リソースグリッドを示す。
図3では、特定のリソース308は、強調表示されており、NB−IoT RAT191に係るeNB112と端末130−1との間のデータパケット350を含むDLペイロードメッセージの通信のためのダウンリンク(DL)スケジューリング割当てによって識別される(以下の図において同じグラフィカル表記に従う)。
図3の例では、リソース308の各々は、所与の冗長バージョンに従って符号化されたデータパケット350を搬送し、図3の例では、データパケット350が繰り返し送信される。他の例では、例えばHARQ再送ごとに、データパケット350の単一の反復のみが送信されることも可能である。
図3は、データパケット350のDL通信について例示されているが、それぞれの技法は、アップリンク(UL)スケジューリング許可(grant)にも容易に適用され得る。ここでは、UL通信のために特定のリソース308が識別される。
各リソース308は、例えば、あるビット数を無線リンク101上で通信することができる時間周波数リソースブロックを指定することができる。MCSに応じて、リソース308当たりのビット数は変わり得る。リソース308は、時間ドメイン(図3の垂直軸)において明確な持続時間を有する。リソース308の持続時間は、時としてサブフレーム309と呼ばれることがあるTTIの持続時間に対応する。所与の持続時間の間に、ある数のシンボルがその後通信されることがある。同様に、リソース308は、周波数ドメイン(図3の水平軸)において明確な幅を有する。例えば、幅は180kHzになり得る。典型的には、各リソース308は、シンボルが直交変調される複数のサブキャリアを含む。
わかるように、広帯域LTEキャリア312は、第2のスペクトル302内のリソース308を含む。第2のスペクトル302は、2つの不連続に配置された周波数帯域を含む。第2のスペクトル302の範囲内に、狭帯域NB−IoTキャリア311の第1のスペクトル301のリソース308が配置される。第1のスペクトル301は、図3の例では単一の周波数帯域のみを含む。例えば、第1のスペクトル301の単一の周波数帯域は、180kHzの帯域幅を有している可能性があり、これは、単一のリソース308の周波数幅に対応し得る。第1のスペクトル301の単一の周波数帯域は、第2のスペクトル302の2つの周波数帯域に隣接して配置される。
図3の例における第1及び第2のスペクトル301、302は、周波数領域において重複しないので、狭帯域NB−IoTキャリア311上で通信することと、広帯域LTEキャリア312上で通信することとの間の干渉が緩和される。
狭帯域NB−IoTキャリア311と広帯域LTEキャリア312の両方は、例えば、あるアプリケーションの上位層のユーザデータを含むデータパケットを搬送するペイロードメッセージを通信するための1つ以上のペイロードチャネルを実装し得る。特に、ペイロードチャネルは、UL通信及びDL通信を容易にする可能性がある。例えば、広帯域LTEキャリア312の場合、DLペイロードチャネルは、時として物理ダウンリンク共有チャネル(PDSCH)と呼ばれることがある。例えば、広帯域LTEキャリア312の場合、ULペイロードチャネルは、時として物理アップリンク共有チャネル(PUSCH)と呼ばれることがある。狭帯域NB−IoTキャリア311についてのいくつかのシナリオでは、同様の表記が使用され得る。
狭帯域NB−IoTキャリア311と広帯域LTEキャリア312の両方は、それぞれのRAT191、192に従って通信を構成するための制御情報を搬送する制御メッセージを通信するための1つ以上の制御チャネルを実装し得る。例えば、広帯域LTEキャリア312の場合、特定のDL制御チャネルは、スケジューリング制御メッセージ、電力制御メッセージ、無線リソース制御(RRC)制御シグナリングなどの通信に使用される物理ダウンリンク制御チャネル(PDCCH)である。制御チャネルのさらなる例には、PCFICH(Physical Control Format Indicator Channel)、再送を制御することによってデータの通信を保護する自動再送要求(ARQ)プロトコルの肯定応答メッセージを通信するためのPHICH(Physical Hybrid-ARQ Indicator Channel)、及びPBCH(Physical Broadcast Channel)がある。PBCHは、ネットワークへのアクセスを要求する端末のためのシステム情報を搬送することができる。システム情報は、マスター情報ブロック(MIB)制御メッセージ又はシステム情報ブロック(SIB)制御メッセージを含み得る。広帯域LTEキャリア312に関して上記で開示したのと同様の制御チャネルが、狭帯域NB−IOTキャリア311についても実装され得る。
図3の例では、狭帯域NB−IoTキャリア311上のNB−IoT RAT191に係るメッセージの通信に利用可能な第1のスペクトル301の周波数帯域の帯域幅は、180kHzに制限される。このため、データレートも制限される。
また、図3の例では、通信のレイテンシは比較的長い。これは、データパケット350を通信するために、4つの後続のサブフレーム309が必要とされるからである。詳細には、図3のような参照実装によれば、同じ冗長バージョンの符号化データのある回数の反復送信(図3の例では、同じ冗長バージョンの4回の送信が、データパケット350の通信に使用される)。したがって、ARQプロトコル内の符号化データの各冗長バージョンは、ある回数反復される。ここでは、典型的には、同一の冗長バージョンを搬送するメッセージの反復が、無線リンク上で実装されるチャネルの連続/後続のサブフレーム309において通信されるメッセージのバンドルされた送信セット351によって実装されると仮定されており、例えば、3GPP Technical Report(TR)45.820 V13.0.0(2015−08),Section6.2.1.3又は3GPP TR 36.888 V12.0.0(2013−6)を参照されたい。バンドルされた送信セット351を使用することによって、無線リンク上で通信する条件が悪いシナリオでも、送信の成功の可能性を高めることができる。それによって、MTC及びNB−IoTドメイン内で想定される低送信電力の場合であっても、セルラーネットワークのカバレージをかなり強化することができる。これは、時としてカバレージ強化(CE)と呼ばれることがある。
以下では、NB−IoT RAT191に係る通信に利用可能な総帯域幅の柔軟な調整を可能にする様々な技法が開示され、それによって、NB−IoT RAT191に係る通信のデータレートも柔軟に調整することができ、代替又は追加として、例えば、同じ冗長バージョンのデータの送信を調整することによって、送信レイテンシを低減することも可能である。
以下に開示される技法は、IoTデバイスを実装する端末130−1の限られたRFモデムの複雑さが、典型的に、その利用される無線帯域幅及びピークデータレートのみによって、又は主にそれらによって決定されないことを知ることによって動機付けられる。特に、RFサブシステム又はRFモデムのアナログフロントエンドなどのいくつかの他のパラメータは、サイズ及びコスト、したがって複雑さを定義する。この結果として、一部のRFモデムベンダーは、例えば規模の経済の恩恵を受けるために、MTCとNB−IoT RFモデムの両方のためにハードウェア構成要素の設計を再利用することがある。したがって、NB−IoT RFモデムは、単一の狭帯域NB−IoTキャリア(図3参照)に対応する、例えば180kHzよりも大きい帯域幅及びデータレートを利用することができるハードウェアであり得る。ハードウェアのケイパビリティがそのような帯域幅の増加をサポートする可能性があるので、これは、NB−IoT RAT191に係る通信に利用可能な帯域幅の増加を促す。
図4は、NB−IoT RAT191に係る通信により大きい総帯域幅を使用するリソース308の分布の第1の例である。図3及び図4の比較から、図4の例のNB−IoT RAT191に係る通信は、複数の狭帯域NB−IoTキャリア311−1、311−2を使用することがわかる。図4の例では、2つの狭帯域NB−IoTキャリア311−1、311−2は、帯域内不連続配備シナリオで配置される。第1のスペクトル301の周波数帯域の総帯域幅は2倍になる。それによって、総データレートをも増加させることができる。
図5は、NB−IoT RAT191に係る通信により大きい総帯域幅を使用するリソース308の分布の第2の例である。図3及び図5の比較から、図5の例のNB−IoT RAT191に係る通信は、複数の狭帯域NB−IoTキャリア311−1、311−2、311−3を使用することがわかる。図5の例では、3つの狭帯域NB−IoTキャリア311−1、311−2、311−3は、帯域内連続配備シナリオで配置される。第1のスペクトル301の周波数帯域の総帯域幅は3倍になる。それによって、総データレートをも増加させることができる。
図6は、NB−IoT RAT191に係る通信により大きい総帯域幅を使用するリソース308の分布の第3の例である。図3及び図6の比較から、図6の例のNB−IoT RAT191に係る通信は、複数のNB−IoTキャリア311−1、311−2を使用することがわかる。図6の例では、2つの狭帯域NB−IoTキャリア311−1、311−2は、帯域内/保護帯域に混在する不連続配備シナリオで配置される。第1のスペクトル301の周波数帯域の総帯域幅は2倍になる。それによって、総データレートも増加させることができる。
図4〜図6のシナリオでは、図3の参照実装と比較すると、NB−IoT RAT191の総帯域幅が増加する。したがって、追加の狭帯域NB−IoTキャリア311−1、311−2、311−3の拡張された帯域幅で通信する端末130−1のケイパビリティ、例えば、ハードウェア及び/又はソフトウェアのケイパビリティを確保することが望ましい場合がある。このために、ケイパビリティ制御メッセージが狭帯域NB−IoTキャリア311−1、311−2、311−3の制御チャネルで通信されることが可能であり、ケイパビリティ制御メッセージは、第1の端末130−1の第1のスペクトル301での通信のケイパビリティを示すインジケータを含む。
したがって、図4〜図6に係るシナリオでは、複数の狭帯域キャリア311−1、311−2、311−3が使用され、第1のスペクトル301は、第2のスペクトル302の範囲内に少なくとも部分的に配置される。例えば、図6を参照すると、第1のスペクトル301の帯域内周波数帯域は、第2のスペクトル302の周波数帯域に隣接し、第1のスペクトル301の保護帯域周波数帯域は、第2のスペクトル302の周波数帯域に隣接しない。
図4〜図6では、2つ又は3つのNB−IoTキャリア、311−1、311−2、311−3が使用される例が開示されているが、他の例では、より多くの数のNB−IoTキャリア、例えば、4つ、5つ、最高10などのNB−IoTキャリアが使用され得る。図4〜図6の特定の時間周波数割振り方式は、説明の目的でのみ提供される。図4〜図6に示す例は、互いに組み合わせることができる。
図6Aは、バンドリングポリシーの態様を示す。バンドリングポリシーは、所与の冗長バージョンに従って符号化されたデータを含むメッセージをバンドルされた送信セット351として通信することに対応する。これらの技法は、UL及びDLに使用することができる。バンドリングポリシーは、所与の冗長バージョンに従って符号化された同じデータパケットが複数の反復を使用してどのように通信されるかを指定する。バンドリングポリシーの適用はオプションである。バンドリングポリシーが適用される様々な例が開示されているが、バンドリングポリシーは、本明細書に開示された技法には密接な関係がなく、例えば、CAシナリオなど、複数の異なる狭帯域NB−IoTキャリア上での通信を使用する技法には、密接な関係はない。例えば、各HARQ再送内で、所与の冗長バージョン371〜373の単一の反復のみが通信されることが可能である。
図6Aは、バンドリングポリシー下でペイロードチャネルを介して通信されるペイロードメッセージを示す。ペイロードメッセージは、第1の冗長バージョン371(図6AにはRV0と表示)に従って符号化されたデータパケット350を含む。図6Aからわかるように、メッセージは、後続のサブフレーム309において連続して通信され、それによって、バンドルされた送信セット351を実装する。例えば、バンドルされた送信セット351は、20よりも大きい、又は50よりも大きい、又は100よりも大きい数のペイロードメッセージを含んでいてもよく、すべてデータパケット350の冗長な反復を搬送する。
データパケット350を搬送する後続のサブフレーム309は、異なる狭帯域NB−IoTキャリア311−1、311−2にわたって分布する。いくつかの例では、バンドルされた送信セット351のサブフレーム309の時間的配置及び/又は数は、異なる狭帯域NB−IoTキャリア311−1、311−2にわたって対称的に分布していてもよい(図6Aに示すように)。さらなる例では、バンドルされた送信セット351のサブフレーム309の時間的配置及び/又は数は、異なる狭帯域NB−IoTキャリア311−1、311−2、311−3にわたって非対称的に分布していてもよい(図6Aには図示せず)。
図6Aに示されているメッセージの特定の時間周波数配置は、一例にすぎない。他の例が考えられる。
図6Aでは、ペイロードメッセージが通信されるシナリオが示されているが、同様の技法は、他の種類及びタイプのメッセージ、例えば制御メッセージに容易に適用され得る。
図6Bは、異なる冗長バージョン371〜373に従ってデータパケット350を符号化する態様を示す。図6Bからわかるように、データパケット350は、一連のビットを含む。例えば、データパケット350は、MAC層サービスデータユニット(SDU)の少なくとも一部とすることができる。データパケット350は、RRCコマンド、又はACK、NACK、UL許可、若しくはDL割当てなど他の制御データに対応することも可能である。
データパケット350を符号化することは、データパケット350にチェックサム412を追加することに対応し得る。リードソロモン符号化、ターボ畳み込み符号化、畳み込み符号化など、様々な符号化の技法を使用することができる。チェックサム412の提供は、コーディング方式に係る対応するメッセージの破損したビットの再構成を容易にすることができる。典型的には、チェックサム412が長い(短い)ほど、ノイズ及びチャネルの不完全性に対する対応するメッセージの通信がより強固になり(より強固でなくなり)、したがって、データパケット350を正常に受信する確率は、チェックサムの長さによって調整することができる。代替又は追加として、データを符号化することは、データパケット350のビットがシャッフルされるインターリーブを適用することに対応し得る(図6Bには図示せず)。
典型的には、異なる冗長バージョン371〜373は、異なる長さのチェックサム412に対応する(図6Bに図示されるように)。他の例では、異なる冗長バージョン371〜373は同じ長さの、しかし、異なるコーディング方式に従って符号化されたチェックサム412を使用することも可能である。代替又は追加として、異なる冗長バージョンは、異なるインターリーブ方式を使用し得る。
以下では、異なる冗長バージョンを構築する例示的な実装形態が与えられる。
異なる冗長バージョンを構築するステップ1:情報ビットのブロック、すなわち送信されるデータパケット350が符号化される。ここで、追加の冗長ビットが、すなわち、データパケット350に加えて、生成される。Nを情報ビット数とすると、例えば、E−UTRA RATの場合、符号化されたビットの総数(すなわち、情報ビット及び冗長ビットの合計)は3Nに達し得る。すべての3Nビットを受信するデコーダは、典型的には、BERが高いために受信ビットに多数のビットエラーが存在するとしても、情報ビットを復号することができる。
異なる冗長バージョンを構築するステップ2:したがって、送信の過剰なオーバーヘッドを回避するために、冗長ビットの一部分のみが選択される。情報ビット及び選択された冗長ビットは、第1の冗長バージョン371を形成する。したがって、第1の冗長バージョンに係る符号化ビットの量は371、上記の例を使用すると、Nと3Nとの間のどこかである。一部分を選択することによって冗長ビットを取り除くプロセスは、時としてパンクチャリングと呼ばれることがある。この第1の冗長バージョン371は、次いで、受信機に送信され得る。
異なる冗長バージョンを構築するステップ3:HARQプロトコルに従って再送が要求される場合、新しい冗長バージョン372、373が送信される。より高次の冗長バージョン372、373は、ステップ2において予めパンクチャリングされたものからの追加の冗長ビットを含み、典型的には、この場合も同じ情報ビットを含む。このようにして、数回の反復の後、3Nビット全体が少なくとも1回送信されている。
ペイロードメッセージ及び制御メッセージについての所与の冗長バージョン371〜373に従って符号化されたデータを含むメッセージの冗長送信又は反復を使用して、バンドルされた送信セット351を実装することが可能である。
受信機がデータパケット350の複数の反復を受信する場合、復号は、複数の反復の受信信号の組み合わせに基づくことができる。それによって、復号の成功の可能性を高めることができる。送信の成功を容易にするために送信電力をブーストする代わりに、又はそれに加えて、複数の反復を実装することを実装することができる。
図4〜図6と図3との比較から、所与のデータパケットを通信するためのバンドルされた送信セット351の持続時間を大幅に短縮できることがわかる。したがって、レイテンシを短縮することができる。これは、データパケット350の同じ冗長バージョンを異なる狭帯域NB−IoTキャリア311−1、311−2、311−3上で通信することによって達成される。すなわち、所与の冗長バージョン371〜373に従って符号化されたデータパケット350を含む第1のメッセージは、第1の狭帯域NB−IoTキャリア311−1、311−2、311−3上で通信され、同じ所与の冗長バージョン371〜373に従って符号化されたデータパケット350を含む第2のメッセージは、第1の狭帯域NB−IoTキャリア311−1、311−2、311−3とは異なる第2の狭帯域NB−IoTキャリア311−1、311−2、311−3上で通信されることが可能である。すなわち、所与の冗長バージョン371、372、373に従って符号化されたデータパケット350の第1の複数の反復は、1次キャリア311−1上で通信され、同一の所与の冗長バージョン371、372、373に従って符号化されたデータパケットの第2の複数の反復は、2次キャリア311−2上で通信されることが可能である。
例えば、同じ所与の冗長バージョン371、372、373に従って符号化されたデータパケット350の第1及び第2の複数の反復は、サブフレーム309など、重複するTTIにおいて少なくとも部分的に通信されてもよい。第1及び第2の複数の反復は、少なくとも部分的に並行に通信されてもよい。
例えば、第1の複数の反復の数は、第2の複数の反復の数に等しくてもよい。また、第1の複数の反復の数と第2の複数の反復の数との間の非対称性が実装され得る。
図4〜図6の例では、データパケット350の様々な冗長バージョンは、例えば後続のサブフレーム309において、バンドルされた送信セット351の一部として、異なる狭帯域NB−IoTキャリア311−1、311−2、311−3を介して通信される。他の例では、同じ所与の冗長バージョン371〜373に従って符号化されたデータパケット350の複数の反復は、不連続的に配置されたサブフレーム309において通信されてもよい。
図4〜図6、図6A、図6Bの例では、NB−IoT RAT191に係る通信に利用可能な第1のスペクトル301の総帯域幅を増加させることによって、利用可能なデータレートの増加をすでに達成することができる。以下では、利用可能なデータレートをなお一層増加させることを可能にするさらなる同時配備シナリオが開示される。さらなるシナリオによって、利用可能なデータレートをさらに増加させることができ、これは、実装を単純化し、第1のスペクトル301の所与の利用可能な総帯域幅についての制御シグナリングオーバーヘッドを低減することによって達成され得る。さらなるシナリオは、複数の狭帯域キャリア311−1、311−2、311−3の間の制御メッセージ及び制御信号及び送信電力の少なくとも1つの非対称の分布に基づく。
図7は、複数の狭帯域キャリア311−1、311−2、311−3の間で制御メッセージ及び制御信号を非対称に分布させる態様を示す。図7を参照すると、3つの狭帯域キャリア311−1、311−2、311−3に依拠する例について、制御メッセージ及び制御シグナリングを非対称に分布させる概念が示されているが、それぞれの概念は、任意の数の狭帯域キャリアについて容易に適用され得る。
図7の例では、1次キャリア311−1が定義されており、さらに、2つの2次キャリア311−2、311−3が定義される。1次キャリア311−1は、2次キャリア311−2、311−3に関して、制御機能をホストし得る。
詳細には、制御メッセージ及び制御信号は、一方では1次キャリア311−1と他方では2次キャリア311−2、311−3との間で非対称に分布している。特に、非対称の分布は、制御シグナリングのオーバーヘッドが、2次キャリア311−2、311−3から1次キャリア311−1に移動され、2次キャリア311−2、311−3が、制御メッセージ及び/又は制御信号を含まないか、又はより少ない数の制御メッセージ及び/又は制御信号を含むようにする。これに関連して、1次チャネル311−1上で通信される制御メッセージ及び制御信号は、2次キャリア311−2、311−3を対象とする情報を含む可能性がある。このため、2次キャリア311−2、311−3は、ペイロードチャネル(図7には図示せず)のためのリソースをより多く提供することができ、「クリーンチャネル」と呼ばれ得る。オーバーヘッドを低減することができるので、NB−IoT RAT191に係る通信の全体的なデータレートをさらに増加させることができる。
詳細には、図7に示すように、1次キャリア311−1は、制御チャネル403を含み、2次キャリア311−2、311−3は、制御チャネル403を含まない。例えば、NB−IoT RAT191に係る制御チャネル403は、E−UTRA RAT192に係るPDCCH又はPUCCH又はPHICH(すべて図2には図示せず)に相当し得る。制御チャネル403は、1次キャリア311−1上、及び2次キャリア311−2、311−3上の両方での通信に関連付けられた制御メッセージを含むことができる。例えば、制御チャネル403上で通信される制御メッセージは、DL通信での第1のスペクトル301内のリソース308を識別するDLスケジューリング割当て、UL通信での第1のスペクトル301内のリソース308を識別するULスケジューリング許可、1次キャリア311−1又は2次キャリア311−2、311−3のうちの1つのペイロードチャネル上で通信されるペイロードメッセージの肯定応答メッセージ又は否定応答メッセージなどのARQ肯定応答メッセージ、及びRRC制御メッセージを含むグループから選択され得る。制御チャネル403は、ユニキャストチャネルであってもよく、すなわち、特に端末130−1を対象としてもよい。
さらに、図7に示すように、1次キャリア311−1は、特定の端末を対象としないブロードキャスト制御チャネル401を含み、2次キャリア311−2、311−3は、ブロードキャスト制御チャネル401を含まない。例えば、NB−IoT RAT191のブロードキャスト制御チャネル401は、E−UTRA RAT192(図2には図示せず)に係るPBCHに相当し得る。ブロードキャスト制御チャネル401は、1次キャリア311−1上、及び2次キャリア311−2、311−3上の両方での通信に関連付けられた制御メッセージを含むことができる。例えば、ブロードキャスト制御チャネル401上で通信される制御メッセージは、NB−IoT RAT191を介してセルラーネットワーク100にアクセスするためのキャリアアクセスシステム情報制御メッセージに対応し得る。そのような制御メッセージは、E−UTRA RAT MIB又はSIBに対応し得る。例示的な情報は、フレーム番号付け、キャリア固有の情報、及びランダムアクセスのためのスケジューリング割振りを含む。
制御チャネル401、403に関して上述したように、1次キャリア311−1上の制御チャネル401、403上で通信される所与の制御メッセージに含まれる情報は、2次キャリア311−2、311−3のうちの1つを対象とすることが可能である。すなわち、所与の制御メッセージは、複数の狭帯域NB−IoTキャリア311−1、311−2、311−3の1次キャリア311−1上で通信することと関連付けられてもよく、及び/又は2次キャリア311−2、311−3のうちの1つ以上での通信に関連付けられてもよい。制御チャネル401、403上で通信された所与の制御メッセージが向けられる特定のキャリア311−1、311−2、311−3の識別を容易にするために、それぞれのインジケータを使用することができる。受信機側では、この識別は、情報の処理のために使用され得る。例えば、制御メッセージは、1次キャリア311−1又は2次キャリア311−2、311−3のうちの1つを示すインジケータを含み得る。これらは明示的なインジケータ又は暗示的なインジケータであり得る。例えば、3ビット数が使用されてもよい。例えば、制御メッセージがE−UTRA RAT192 MIBに対応する場合、3GPP Technical Specification(TS)36.331 Rel.12,Section6.2.2に係る予約済みビットを、1次キャリア311−1又は2次キャリア311−2、311−3のうちの1つを示すために使用することができる。
さらに、図7に示すように、基準信号402の時間密度(時間当たりの数)は、2次キャリア311−2と比較すると、1次キャリア311−1においてより大きい。同様に、基準信号402の時間密度は、2次キャリア311−3と比較すると、2次キャリア311−2においてより大きい。基準信号は、復調を容易にし(復調基準信号、DMRS)、及び/又は通信のための電力基準を提供する(サウンディング基準信号、SRS)、又はビームフォーミングのためのセル固有の情報を提供する、若しくはチャネル推定をサポートする(セル固有の基準信号、RS)ことができる。また、図7に示すように、同期信号404は、1次キャリア311−1上でのみ通信され、2次キャリア311−2、311−3上では通信されない。そのような同期信号404は、端末130−2によるeNB112、112−1、112−2のタイミング基準の一時的取得を容易にすることができる。
したがって、概して、1次キャリア311−1は、時間当たりの第1の数の制御信号402、404に関連付けられ、2次キャリア311−2、311−3は、時間当たりの第2の数の制御信号402、404に関連付けられ得る。第1の数は、例えば、1.2倍、1.5倍、2倍、10倍、50倍、又はそれより大きい倍率だけ、第2の数よりも大きくてよい。いくつかのシナリオでは、制御信号402、404が1次キャリア311−1上でのみ通信されることさえ可能である。制御信号402、404に関する非対称を使用することによって、オーバーヘッドの量を低減することができる。これは、NB−IoT RAT191に係る通信に利用可能なデータレートを増加させる。
したがって、図7からわかるように、異なる例では、1次キャリア311−1と2次キャリア311−2、311−3との間の制御メッセージ及び/又は制御信号の非対称の分布の異なる実装が考えられる。送信電力の観点から、1次キャリア311−1と2次キャリア311−2、311−3との間のさらなる非対称性が実装されてもよい。
図8Aは、送信電力870に関する態様を示す。例えば、図8Aの送信電力は、電力スペクトル密度(PSD)を示し得る。例えば、1次キャリア311−1は、2次キャリア311−2、311−3の第2の送信電力872と比較すると、例えば、少なくとも2dB、好ましくは少なくとも6dB、より好ましくは少なくとも10dBの係数875だけブーストされた第1の送信電力871を実装するように構成されることが可能である。
非対称の送信電力を実装することによって、1次キャリア311−1上で通信される制御メッセージ及び/又は制御信号の送信の成功の可能性を向上させることができ、それによって、1次キャリア311−1上で通信される制御メッセージ及び/又は制御信号が、2次キャリア311−2、311−3上でも通信することに関連する場合、すべてのキャリア311、311−1、311−2、311−3にわたるNB−IoT RAT191の全体的な通信信頼性が増加され得る。
さらなる例では、1次キャリア311−1は、例えばNB−IoT RAT191及び/又はE−UTRA RAT192のすべてのリソース308の平均送信電力と比較すると、ブーストされた第1の送信電力871を実装するように構成されてもよい。
上記では、送信電力、並びに制御メッセージ及び制御信号のうちの少なくとも1つに関する非対称性についての例が示されている。代替又は追加として実装され得るさらなる非対称性は、同じ冗長バージョンのデータの複数の反復を含むバンドルされた送信セット351に関連し得る。例えば、バンドルされた送信セット351のサブフレームの時間的配置及び/又は数は、異なる狭帯域NB−IoTキャリア311−1、311−2、311−3にわたって非対称的に分布されてもよい。例えば、1次キャリア311−1は、2次キャリア311−2、311−3(図6参照)と比較すると、バンドルされた送信セット351のより多くの反復を搬送することができる。例えば、1次キャリア311−1は、2次キャリア311−2、311−3(図6参照)と比較すると、バンドルされた送信セット351の反復の通信をより早期に開始し得る。
例えば、送信電力、並びに/又は制御メッセージ及び/若しくは制御信号のうちの少なくとも1つ、並びに/又はバンドルされた送信セット351に関するそのような非対称性の実装は、NB−IoT RAT191の狭帯域NB−IoTキャリア301、301−1、301−2、301−3の第1のスペクトル301の比較的小さい総帯域幅によって、及び/又は狭帯域NB−IoTキャリア301、301−1、301−2、301−3の各々の比較的小さい帯域幅によって、容易にされ得る。例えば、1次キャリア311−1と2次キャリア311−2、311−3との間の周波数空間における距離が比較的小さい(各個々のキャリア311−1、311−2、311−3の小さい帯域幅のために可能である)場合、1次キャリア311−1上で通信される基準信号は、2次キャリア311−2、311−3にとって重要であり得る。これは、特に、帯域内連続配備シナリオに適用することができる(図4参照)。また、各個々のキャリア311−1、311−2、311−3の帯域幅が小さい場合、キャリア当たりに必要とされる基準信号の数は比較的少なくてもよい。さらに、個々の2次キャリア311−2、311−3が独立して、すなわち、付随する1次キャリア311−1なしに、動作することができない場合、1次キャリア311−1上でのみ同期制御信号404を通信することが可能であり、そのようなシナリオでは、例えばフレーム又はサブフレームなど、TTIが1次キャリア311−1と2次キャリア311−2、311−3との間で同期されることが可能である。1次キャリア311−1においてのみ制御メッセージをスケジューリングすることを含めて、制御チャネル403を使用することによって、クロスキャリアスケジューリングが容易になる。周波数ホッピングを使用することができる。
図8Bは、NB−IoT RAT191の通信プロトコルスタック800を示す。特に、図8Bは、CAシナリオの態様を示す。わかるように、図8BのCAシナリオでは、通信プロトコルスタック800の別個の物理層803が、複数の狭帯域NB−IoTキャリア311−1、311−2の各々について実装される。すなわち、より大きい(より小さい)数のNB−IoTキャリアが使用される場合、物理層803の、より大きい(より小さい)数の共存するインスタンスが実装される。
各キャリア311−1、311−2のペイロードチャネル上で通信されるペイロードメッセージのアグリゲーションは、通信プロトコルスタック800のメディアアクセス層(MAC)802の上端に実装される。さらに上位層は、無線リンク制御(RLC)層、PDCP(Packet Data Convergence Protocol)層、及びRRC層を含む。
他のCAシナリオでは、アグリゲーションは、例えば、物理層803内のどこか、又はMAC層802の下端の近くなど、通信プロトコルスタック800の他のレベルにおいて実装されてもよい。特に、図8Bのシナリオでは、ARQプロトコル機能及び前方誤り訂正(FEC)機能を含むハイブリッドARQ(HARQ)プロトコルは、各キャリア311−1、311−2について独立して各対応するサブレイヤ852−1、852−2によって実装され、他の例では、CAは、単一のHARQインスタンスのみを使用して実装されてもよい。
図8Bはさらに、物理層803のトランスポートブロック(TB)サブレイヤ853−1、853−2に関する態様を示す。TBサブレイヤ853−1、853−2は、上位層のデータパケット、例えば、MACパケットデータユニット(PDU)を、サブフレーム309にマッピングされたTBにアセンブルする。ここでは、MCSに応じて、各TB(ビットローディング)に異なる数のビットを含めることができる。
いくつかの例では、2つのキャリア311−1、311−2のサブレイヤ853−1、853−2が互いに独立して動作することが可能である。次いで、各キャリア311−1、311−2のTBについて独立してビットローディングが選択され得る。
他の例(図8Bに水平の破線で示す)では、2つのキャリア311−1、311−2のサブレイヤ853−1、853−2の間に調整が存在する可能性がある。例えば、そのような調整は、異なるキャリア311−1、311−2の時間重複サブフレーム309について、異なるキャリア311−1、311−2において、同じサイズ、すなわち同じビット数を含むTBを使用することを実装することが可能である。例えば、異なるキャリア311−1、311−2のTTIが同期している場合、同じ瞬間に、異なるキャリア311−1、311−2にわたって同じサイズのTBが使用されてもよい。したがって、ビットローディングは、狭帯域NB−IoTキャリア311−1、311−2にわたって同期され得る。例えば、同じサイズのTBが使用される場合、HARQプロセス852−1、852−2(図8Bに水平の破線で示す)間の調整を追加で含むことが好ましい場合がある。いくつかの例では、同一のHARQプロセスがすべてのキャリア311−1、311−2に使用されてもよく、又はボンディングがHARQプロセスより下でもよい。
いくつかの例では、ビットローディングは、NB−IoT RAT191のすべてのキャリア311−1、311−2、311−3にわたって最適化されてもよい。さらなる例では、ビットローディングは、1次キャリア311−1に関して選択的に最適化されてもよい。特に、TBのビット数は、1次キャリア311−1上で前記通信する品質を示す周波数選択的な測定360(図4〜図6参照)に基づくことが可能である。
そのような測定は、1次キャリア311−1上で通信されるペイロードメッセージに関連付けられたHARQプロトコルのいくつかの肯定応答メッセージ、1次キャリア311−1上で通信されるペイロードメッセージに関連付けられたHARQプロトコルのいくつかの否定応答メッセージ、1次キャリア311−1上の通信のチャネル品質インジケータ(CQI)などを含むグループから選択された要素を含み得る。
NB−IoT RAT191の第1のスペクトル301の全体的な帯域幅が小さいため、1次キャリア311−1について行われた測定360は、2次キャリア311−2、311−3上での通信にも重要であり得る。1次キャリア311−1について行われた測定360を2次キャリア311−2、311−3に再利用することによって、システムの複雑さを低減することができ、さらに、2次キャリア311−2、311−3上の、例えばCQI報告の、制御シグナリングの必要性が低減され得る。制御シグナリングオーバーヘッドが低減し、それによって、データレートが増加し得る。
前述の図4〜図8Bに関して、狭帯域NB−IoTキャリア311、311−1、311−2、311−3の第1のスペクトル301が広帯域LTEキャリア312の第2のスペクトル302と重複しない例が開示されている。したがって、第1のスペクトル301は、NB−IoTキャリア311、311−1、311−2、311−3に専用であり、第1のスペクトル301及び第2のスペクトル302は、共有スペクトルを含まない可能性がある。ここで、利用可能なデータレートの増加はむしろ、例えば、CAの実装に係る、複数の狭帯域NB−IoTキャリア311−1、311−2、311−3を使用することによって達成される。追加のリソース308は、狭帯域NB−IoTキャリア311−1、311−2、311−3に専用である。
リソース308をそのように狭帯域NB−IoT RAT191に専用とすることは、比較的固定的であり得る。したがって、動作中、例えば短い時間スケールで、RAT191、192間のリソース308の分布を微調整することは、可能ではない、又は限られた程度にしか可能ではない可能性がある。そのような微調整は、例えば、NB−IoT RAT191に従って通信されるデータのトラフィックが変化する場合に望ましい。以下、RAT191、192間のリソース308の分布の微調整を可能にする技法が開示される。これらの技法は、共有スペクトルを利用することに依拠する。そのような技法は、複数の狭帯域NB−IoTキャリアに依拠して上記で開示した技法と組み合わせることができる。
図9は、共有スペクトル305を使用することに関する態様を示す。図9からわかるように、狭帯域NB−IoTキャリア311の第1のスペクトル301と、広帯域LTEキャリア312の第2のスペクトル302の両方は、共有スペクトル305を含む。共有スペクトル305は、狭帯域NB−IoTキャリア311によってのみ占有される専用スペクトル306に隣接して配置される。
共有スペクトル305のリソース308は、必要に応じて、NB−IoT RAT192に係る通信、又はE−UTRA RAT312に係る通信のいずれかに割り振られる。例えば、図9からわかるように、共有スペクトル内の第1のリソース308は、狭帯域NB−IoTキャリア311に割り振られ、共有スペクトル305内の第2のリソース308は、広帯域LTEキャリア312に割り振られる。この割振りは、異なるキャリア311、312に割り振られた第1及び第2のリソース308が互いに直交するようにTDM方式で行われ、それによって、NB−IoT RAT191とE−UTRA RAT192との間の干渉を緩和することができる。
RAT191、192に共通の集中スケジューリングプロセスが実装されてもよい。集中スケジューリングプロセスは、TDMスケジューリングを実装することによって、共有スペクトル305における干渉緩和を容易にし得る。これは、非同一の場所に配置された(non-colocated)アクセスノード112−1、112−2(図1参照)間の制御シグナリングを含み得る。
第1のリソース308を示すインジケータを含むスケジューリング制御メッセージは、狭帯域NB−IoTキャリア311(図9には図示せず)の制御チャネル上で通信することができる。例えば、RRC制御シグナリングが使用され得る。これは、端末130−1に、共有スペクトル305上で使用することができるリソース308について通知する。第2のリソース308を示すインジケータを含むさらなるスケジューリング制御メッセージは、広帯域LTEキャリア312(図9には図示せず)の制御チャネル上で通信することができる。例えば、PDCCHを使用することができる。RRC制御シグナリングが使用され得る。これは、端末130−2に、共有スペクトル305上で使用することができるリソース308について通知する。
共有スペクトル305は、第2のスペクトル302と共有されない第1のスペクトル301の専用スペクトル306を超えて拡張するので、第1の端末130−1は、より広い周波数帯域での通信をサポートする必要がある。第1の端末130−1が共有スペクトル305の周波数上で通信することができることを確実にするために、少なくとも1つのNB−IOTキャリア311の制御チャネル上でケイパビリティ制御メッセージを通信することができ、ケイパビリティ制御メッセージは、第1の端末130−1の共有スペクトル305における通信のケイパビリティを示すインジケータを含む(ケイパビリティ制御メッセージは図9には図示せず)。
図8Bに関して上記に開示したように、共有スペクトル305に位置するリソース308のMCSを決定するとき、専用スペクトル306内の狭帯域キャリア311上で通信する品質を示す測定360に依拠することが可能である。したがって、時間重複サブフレーム309における共有スペクトル305及び専用スペクトル306で通信されるTBはすべて、同じビット数を含み得る。図8Bの例について上記で開示された技法は、共有スペクトル305に依拠するシナリオにも適用することができる。
NB−IoT RAT191及びE−UTRA RAT192の同時配備シナリオに関して上述したような概念を、他のRATを含む同時配備シナリオに代替的又は追加的に適用することが可能である。別のRATの例はMTC RATである。
図10は、共有スペクトル305を使用することに関する態様を示す。ここで、共有スペクトル305は、狭帯域NB−IoTキャリア311の第1のスペクトル301の一部であり、広帯域LTEキャリア312の第2のスペクトル302のさらなる一部であり、広帯域MTCキャリア313の第3のスペクトル303のまたさらなる一部である。
図9及び図10に関して上記に示したような共有スペクトル305を使用するシナリオは、図4〜図8Bに関して上記に示したように、複数の狭帯域NB−IoTキャリア311−1、311−2、311−3を使用するシナリオと容易に組み合わせることができる。
図11は、端末130−1、130−2、例えば、IoTデバイスを概略的に示す。端末は、プロセッサ131−1、例えばシングルコア又はマルチコアプロセッサを備える。分散処理が使用されてもよい。プロセッサ131−1は、メモリ131−2、例えば、不揮発性メモリに結合される。メモリ131−2は、プロセッサ131−1によって実行可能なプログラムコードを記憶し得る。プログラムコードを実行することによって、プロセッサ131−1は、例えば、1つ以上の狭帯域NB−IoTキャリア311、311−1、311−2、311−2及び/又は1つ以上の広帯域LTEキャリア312若しくは広帯域MTCキャリア313上で通信することに関する、本明細書に開示された技法を実行する。インターフェース131−3は、アナログフロントエンド及び/又はデジタルフロントエンドを含み得る。インターフェース131−3は、例えば、3GPP E−UTRA RAT191に係る、及び/又は3GPP NB−IoT RAT191に係る通信プロトコルスタック800を実装し得る。通信プロトコルスタック800は、物理層、MAC層などを含み得る。
図12は、eNB112、112−1、112−2を概略的に示す。eNB112、112−1、112−2は、プロセッサ113−1、例えばシングルコア又はマルチコアプロセッサを含む。分散処理が使用されてもよい。プロセッサ113−1は、メモリ113−2、例えば、不揮発性メモリに結合される。メモリ113−2は、プロセッサ113−1によって実行可能なプログラムコードを記憶し得る。プログラムコードを実行することによって、プロセッサ113−1は、例えば、1つ以上の狭帯域NB−IoTキャリア311、311−1、311−2、311−2上で通信すること、及び/又は1つ以上の広帯域LTEキャリア312若しくは広帯域MTCキャリア313上で通信すること、共有スペクトル305内のリソースを狭帯域NB−IoTキャリア311、311−1、311−2、311−2、又は1つ以上の広帯域LTEキャリア312若しくは広帯域MTCキャリア313に割り振ることに関する、本明細書に開示された技法を実行することができる。eNB112、1112−1、112−2は、無線リンク101上で端末130−1、130−2と通信するように構成されたインターフェース113−3をも備える。インターフェース113−3は、アナログフロントエンド及び/又はデジタルフロントエンドを含み得る。インターフェース113−3は、例えば、3GPP E−UTRA RAT191に係る、及び/又は3GPP NB−IoT RAT191に係る通信プロトコルスタック800を実装し得る。通信プロトコルスタック800は、物理層、MAC層などを含み得る。
図13は、様々な実施形態に係る方法のフローチャートである。まず、2001で、NB−IoTキャリア311、311−1、311−2、311−3のような少なくとも1つの狭帯域キャリア上での通信が実行される。例えば、2001は、端末130−1及び/又はアクセスノード112、112−1によって実行され得る。通信は、送信及び/又は受信を含み得る。
通信は、例えばCAを使用して、複数の狭帯域キャリア上で実行されてもよい。したがって、この方法は、MAC層802において複数の狭帯域キャリアのペイロードチャネル上で通信されるペイロードメッセージをアグリゲートすることをさらに含み得る。他の例では、アグリゲーションは、通信プロトコルスタック800内の異なる位置、例えば、物理層803の上端で行われ得る。前記アグリゲーションは、様々な狭帯域キャリアのボンディングに対応し得る。
少なくとも1つの狭帯域キャリアは、第1のスペクトル301内のリソース308を含み、第1のRATに従って、例えばNB−IoT RAT191に従って動作する。第1のスペクトル301は、少なくとも部分的に第2のスペクトル302の範囲内に配置される。
随意に、2002で、広帯域LTEキャリア312及び/又は広帯域MTCキャリア313などの広帯域キャリア上での通信が実行される。広帯域キャリアは、第2のスペクトル302内のリソース308を含む。
いくつかの例では、第1及び第2のスペクトル301、302の両方が共有スペクトル305を含む。そのような場合、方法は、随意に、共有スペクトル305内の第1のリソース308を少なくとも1つの狭帯域キャリアに割り振ること、及び共有スペクトル305内の第2のリソース308を広帯域キャリアに割り振ることをさらに含むことが可能である。ここでは、狭帯域キャリア及び広帯域キャリアに関連付けられた両方のRATにわたる集中スケジューリングを実装することができる。それぞれのスケジューリング制御メッセージは、第1のリソース及び/又は第2のリソースを示す方法の一部として通信されてもよい。
いくつかの例では、2001及び2002での通信は、調整されたやり方で、すなわち、同時配備のシナリオで行われてもよい。このために、それぞれのアクセスノード間の制御シグナリングを実装することができ、同時配備シナリオに係る調整が達成されるように、それぞれのアクセスノードが静的に構成されることも可能である。
要約すると、1つの狭帯域キャリア又は複数の狭帯域キャリア上で通信するときの柔軟なリソース割振りの上記の技法が例示されている。この技法は、複数の狭帯域キャリア上で通信すること、及び/又は少なくとも1つの狭帯域キャリアと1つ以上の広帯域キャリアとの間で共有される共有スペクトル上で通信することに依拠する。
上記で開示された技法によって、少なくとも1つの狭帯域キャリアに関連付けられたRATに係る通信のデータレートを柔軟に増加又は調整することが可能である。
さらに、上記で開示された技法によって、例えば、後続のTTIにおいて同じ冗長バージョンの符号化データを搬送するバンドルされた送信セットが使用されるシナリオにおいて、データ送信のレイテンシを低減することが可能である。
特に、いくつかの例では、本明細書に開示された技法は、NB−IoT RATに係る通信に適用され得る。NB−IoT RATによって達成可能なデータレートを柔軟に増加させることによって、MTC RATとNB−IoT技術との間のギャップを埋めることができる。NB−IoTの配備をターゲットとし、並びに、一方ではNB−IoT RATと、他方ではMTC RAT又はE−UTRA RATとの間の使用事例の柔軟性をサポートするオペレータにとって、柔軟なリソース割振りが可能になる。
本発明は、いくつかの好ましい実施形態に関して図示され説明されているが、本明細書を読み、理解すると、当業者には均等物及び修正が心に浮かぶであろう。本発明は、そのような均等物及び修正のすべてを含み、添付の特許請求の範囲によってのみ限定される。
例えば、上記で、主に、NB−IoT RAT及びE−UTRA RATの同時配備シナリオに関して例が与えられているが、他の例では、NB−IoT RAT及びMTC RATなど、他のRATを同時配備することができる。また、例えば、NB−IoT RAT、MTC RAT、及びE−UTRA RATなど、より多くの数のRATが同時に配備されてもよい。
例えば、複数の狭帯域キャリア、又は共有スペクトルに依拠する上記の例が主に開示されているが、他の例では、複数の狭帯域キャリアを使用する概念は、共有スペクトルを使用する概念と容易に組み合わせることができる。
例えば、第1のRATに従って少なくとも1つの狭帯域キャリア上で通信することに関して、上記の様々な例が主に与えられているが、他の例では、さらに、第2のRATに係る1つ以上の広帯域キャリア上の通信は、実施形態に従うことができる。
例えば、端末とセルラーネットワークとの間のDL通信に関して、上記の様々な例が与えられているが、他の例では、それぞれの技法をUL通信に容易に適用することができる。
例えば、所与の冗長バージョンに従って符号化されたデータパケットの複数の反復が少なくとも1つの狭帯域キャリア上で通信されるバンドルされた送信セットを使用する文脈で、上記の様々な例が開示されているが、他の例では、同じ冗長バージョンのそのような反復の通信は、少なくとも1つの狭帯域キャリア上で通信するために実装される必要はない。例えば、さらなる例では、複数の反復を通信する代わりに、送信電力を増加させることができる。