(57)【要約】  基地局のセル帯域幅を（オーバーラップしない）狭帯域に分割することによって、基地局がマシンタイプ通信（ＭＴＣ：machine-type-communication）デバイスと通信する通信システムが開示される。基地局は、通信デバイスから受信された通信に基づいて、その通信デバイスが狭帯域間でリチューニングする能力を識別し、その通信デバイスに対し、その通信デバイスが異なる狭帯域間でどのようにリチューニングするかを制御するための制御情報を提供し、 前記制御情報は、その通信デバイスについて識別された、狭帯域間でリチューニングする能力に基づいている。【選択図】図１
2019523614.tif 000002
【特許請求の範囲】
【請求項１】
複数の狭帯域のいずれかを使用して通信可能なユーザ機器（ＵＥ：user equipment）により実行される方法であって、
第１の狭帯域から第２の狭帯域へのＵＥリチューニングのための２つの連続するサブフレーム間のシンボル数を示す情報を、基地局に送信するステップと、
物理アップリンク制御チャネル（ＰＵＣＣＨ：physical uplink control channel）フォーマット及びＵＥリチューニングのための前記シンボル数に従って、前記基地局への送信を制御するステップと、を含み、
短くされたＰＵＣＣＨフォーマットに従って、１つのシンボルがＵＥリチューニングのために使用される場合、前記ＵＥは、第１のサブフレームにおいて、最後のシンボルを使用して送信することはせず、
前記短くされたＰＵＣＣＨフォーマットに従って、２つのシンボルがＵＥリチューニングのために使用される場合、前記ＵＥは、前記第１のサブフレームにおいて、前記最後のシンボルを使用して送信することをしないか、又は、第２のサブフレームの最初のシンボルを使用して送信することはしない、
方法。
【請求項２】
２つの連続するサブフレーム間のシンボル数を示す前記情報は、無線リソース制御（ＲＲＣ：radio resource control）シグナリングを使用して送信される、
請求項１に記載の方法。
【請求項３】
２つの連続するサブフレーム間のシンボル数を示す前記情報は、ＵＥ能力情報要素によって提供される、
請求項１又は２に記載の方法。
【請求項４】
ＵＥリチューニングのための２つの連続するサブフレーム間の前記シンボル数に基づいて、前記基地局から、狭帯域間のリチューニングのためのシンボル数を識別する制御情報を受信するステップをさらに含む、
請求項１から３のいずれか１項に記載の方法。
【請求項５】
ＵＥリチューニングのための２つの連続するサブフレーム間の前記シンボル数に基づいて、前記基地局から、異なる狭帯域間のリチューニングのための、パンクチャリングされた制御フォーマット及び／又は短くされた制御フォーマットの少なくとも１つを識別する制御情報を受信することをさらに含む、
請求項１から４のいずれか１項に記載の方法。
【請求項６】
ＵＥリチューニングのための２つの連続するサブフレーム間の前記シンボル数に基づいて、前記基地局から、周波数ホッピングパターン及び／又は周波数ミラーリングパターンを識別する制御情報を受信するステップをさらに含む、
請求項１から５のいずれか１項に記載の方法。
【請求項７】
前記ＵＥは、限定された帯域幅内で動作するように制限されたＵＥである、
請求項１から６のいずれか１項に記載の方法。
【請求項８】
前記狭帯域は、それぞれ異なる周波数範囲をカバーし、前記狭帯域は、インデックスを有し、前記インデックスは、前記インデックスが表す前記狭帯域によってカバーされる前記周波数範囲でシーケンシャルに増加する物理リソースブロックナンバーが増加する順にナンバリングされている、
請求項１から７のいずれか１項に記載の方法。
【請求項９】
所与のセル帯域幅に対して、狭帯域の数は、次の式を使用して定義され、
【数１】
2019523614.tif 000016
ここで、ＮＢｗｈｏｌｅは、前記セル帯域幅内の狭帯域の数であり、ＮＲＢは、前記セル帯域幅内のリソースブロックの数であり、ｎは、各狭帯域内のリソースブロックの数であり、
【数２】
2019523614.tif 000017
は、床関数（すなわち、“ｘ”を超えない最大の整数）である、
請求項８に記載の方法。
【請求項１０】
複数の狭帯域のいずれかを使用してユーザ機器（ＵＥ：user equipment）と通信可能な基地局により実行される方法であって、
第１の狭帯域から第２の狭帯域へのＵＥリチューニングのための２つの連続するサブフレーム間のシンボル数を示すＵＥ能力情報要素を、前記ＵＥから、無線リソース制御（ＲＲＣ：radio resource control）シグナリングで受信するステップと、
物理アップリンク制御チャネル（ＰＵＣＣＨ：physical uplink control channel）フォーマット及びＵＥリチューニングのための前記シンボル数に従って、前記基地局を制御するステップと、を含み、
短くされたＰＵＣＣＨフォーマットに従って、１つのシンボルがＵＥリチューニングのために使用される場合、前記基地局は、第１のサブフレームにおいて、最後のシンボルを使用して前記ＵＥからの送信を受信することはせず、
前記短くされたＰＵＣＣＨフォーマットに従って、２つのシンボルがＵＥリチューニングのために使用される場合、前記基地局は、前記第１のサブフレームにおいて、前記最後のシンボルを使用して前記ＵＥからの送信を受信することをしないか、又は、第２のサブフレームの最初のシンボルを使用して前記ＵＥからの送信を受信することはしない、
方法。
【請求項１１】
前記基地局は、ＬＴＥ（long term evolution）無線アクセスネットワークの基地局である、
請求項１０に記載の方法。
【請求項１２】
プログラマブル通信デバイスに請求項１又は１０の方法を実行させるためのコンピュータ実装可能命令を含むコンピュータ実装可能命令製品。
【請求項１３】
複数の狭帯域のいずれかを使用して通信可能なユーザ機器（ＵＥ：user equipment）であって、
コントローラ及びトランシーバを備え、
前記コントローラは、
前記トランシーバを制御して、第１の狭帯域から第２の狭帯域へのＵＥリチューニングのための２つの連続するサブフレーム間のシンボル数を示す情報を、基地局に送信し、
物理アップリンク制御チャネル（ＰＵＣＣＨ：physical uplink control channel）フォーマット及びＵＥリチューニングのための前記シンボル数に従って、前記基地局への送信を制御するように動作可能であり、
短くされたＰＵＣＣＨフォーマットに従って、１つのシンボルがＵＥリチューニングのために使用される場合、前記ＵＥは、第１のサブフレームの最後のシンボルにおいて送信することはせず、
前記短くされたＰＵＣＣＨフォーマットに従って、２つのシンボルがＵＥリチューニングのために使用される場合、前記ＵＥは、前記第１のサブフレームの前記最後のシンボルにおいて送信することをしないか、又は、第２のサブフレームの最初のシンボルにおいて送信することはしない、
ユーザ機器。
【請求項１４】
複数の狭帯域のいずれかを使用してユーザ機器（ＵＥ：user equipment）と通信可能な基地局であって、
コントローラ及びトランシーバを備え、
前記コントローラは、
前記トランシーバを制御して、第１の狭帯域から第２の狭帯域へのＵＥリチューニングのための２つの連続するサブフレーム間のシンボル数を示すＵＥ能力情報要素を、前記ＵＥから、無線リソース制御（ＲＲＣ：radio resource control）シグナリングで受信し、
物理アップリンク制御チャネル（ＰＵＣＣＨ：physical uplink control channel）フォーマット及びＵＥリチューニングのための前記シンボル数に従って、前記トランシーバによる受信を制御するように動作可能であり、
短くされたＰＵＣＣＨフォーマットに従って、１つのシンボルがＵＥリチューニングのために使用される場合、前記基地局は、第１のサブフレームの最後のシンボルにおいて、前記ＵＥからの送信を受信することはせず、
前記短くされたＰＵＣＣＨフォーマットに従って、２つのシンボルがＵＥリチューニングのために使用される場合、前記基地局は、前記第１のサブフレームの前記最後のシンボルにおいて、前記ＵＥからの送信を受信することをしないか、又は、第２のサブフレームの最初のシンボルにおいて、前記ＵＥからの送信を受信することはしない、
基地局。
【請求項１５】
請求項１３に記載の基地局と、請求項１４に記載のユーザ機器と、を備えるシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、特に排他的ではないが、３ＧＰＰ（3rd Generation Partnership Project）標準又はこれらの同等物若しくは派生物に従って動作する、モバイル通信デバイス及びネットワークに関する。特に、本発明は、排他的ではないが、“インターネット・オブ・シングス（Internet of Things）”デバイス及び／又は同様の（狭帯域の）マシンタイプの通信デバイスによるデータ送信に関する。
【背景技術】
【０００２】
モバイル（セルラー）通信ネットワークにおいては、（ユーザ）通信デバイス（ユーザ機器（ＵＥ：user equipment）として良く知られており、例えば、モバイル電話）は、基地局を介して、リモートサーバ又は他の通信デバイスと通信を行う。これら相互の通信において、通信デバイス及び基地局は、典型的には周波数帯域及び／又は時間ブロックに分割された、ライセンスされた無線周波数を使用する。
【０００３】
３ＧＰＰ標準の最新の開発は、ＬＴＥ（Long Term Evolution）−Ａｄｖａｎｃｅｄを含む、ＥＰＣ（Evolved Packet Core）ネットワーク及びＥ−ＵＴＲＡＮ（Evolved UMTS Terrestrial Radio Access Network）のＬＴＥとして参照されている。３ＧＰＰ標準の下では、ＮｏｄｅＢ（又はＬＴＥにおけるｅＮＢ）は、通信デバイスがコアネットワークに接続し、他の通信デバイス又はリモートサーバと通信するために経由する基地局となる。説明を簡単にするために、本願は、そのような任意の基地局を参照するために基地局という用語を使用する。通信デバイスは、例えば、モバイル電話、スマートフォン、ユーザ機器、パーソナルデジタルアシスタント、ラップトップ／タブレットコンピュータ、ウェブブラウザ、ｅブックリーダーなどのモバイル通信デバイスであっても良い。このようなモバイル（又は、一般的な固定の）デバイスは、典型的には、ユーザによって操作される。
【０００４】
３ＧＰＰ標準はまた、いわゆる“インターネット・オブ・シングス”（ＩｏＴ：Internet of Things）デバイス（例えば、狭帯域ＩｏＴ（ＮＢ（Narrow-Band）−ＩｏＴ）デバイス）がネットワークに接続することを可能にする。これらのデバイスは、典型的には、様々な測定装置、テレメトリ装置、監視システム、追跡（トラッキング）及びトレーシングデバイス、車載安全システム、車両保守システム、道路センサ、デジタル広告掲示板、ＰＯＳ（point of sale）端末、リモート制御システムなどの、自動化装置である。幾つかのＩｏＴデバイスは、非固定の装置（例えば、車両）に組み込まれるか、又は、監視／追跡される動物若しくは人に取り付けられるものであるが、ＩｏＴデバイスは、自動販売機、路側センサ、ＰＯＳ端末などの（一般的には）固定の装置の一部として実装することができる。効果的には、インターネット・オブ・シングスは、適切な電子機器、ソフトウェア、センサ、ネットワーク接続などを備えたデバイス（又は、“物（things）”）のネットワークであり、これらのデバイスが相互に及び他の通信デバイスとデータの収集及び交換をすることを可能にする。ＩｏＴデバイスは、時々は、マシンタイプ通信（ＭＴＣ：Machine-Type Communication）通信デバイス又はマシンツーマシン（Ｍ２Ｍ：Machine-to-Machine）通信デバイスと呼ばれることもあることを理解されるであろう。
【０００５】
説明を簡単にするために、本願は、明細書においてＭＴＣデバイスを参照するが、説明する技術は、データを送受信するための通信ネットワークに接続可能な任意の（モバイル及び／又は一般的には固定の）通信デバイス上で、そのような通信デバイスが人間の入力又はメモリに格納されたソフトウェア命令によって制御されるかどうかとは無関係に、実現可能であることは理解されるであろう。
【０００６】
ＭＴＣデバイスは、ネットワークに接続し、リモートの“マシン”（例えば、サーバ）又はユーザとの間でデータを送受信する。ＭＴＣデバイスは、モバイル電話又は同様のユーザ機器のために最適化された通信プロトコル及び標準を使用する。しかし、ＭＴＣデバイスは、いったん配置されると、典型的には、人間の監督又は対話を必要とすることなく動作し、内部メモリに格納されたソフトウェア命令に従う。ＭＴＣデバイスはまた、長期間にわたって静止及び／又はインアクティブのままである可能性がある。ＭＴＣ（ＩｏＴ）デバイスをサポートするための特定のネットワーク要件は、３ＧＰＰ  ＴＲ（technical report）  ３６．８８８  Ｖ１２．０．０及び３ＧＰＰ  ＴＲ  ２３．７２０  Ｖ１３．０．０において、取り扱われている。ＭＴＣデバイスに関するさらなるネットワーク要件は、３ＧＰＰ  ＴＳ（technical specification）２２．３６８  Ｖ１３．１．０に開示されている。これらの３ＧＰＰ文書の内容は、参照により本明細書に組み込まれる。
【０００７】
ＭＴＣデバイスに関する３ＧＰＰ標準のリリース１３（Ｒｅｌ−１３）バージョンでは、ダウンリンク及びアップリンクにおいて１．４ＭＨｚの低減された帯域幅をサポートすることが想定されている。そのため、幾つかのＭＴＣデバイス（“低減帯域幅ＭＴＣデバイス（reduced bandwidth MTC devices）”と呼ばれても良い）は、ＬＴＥの帯域幅の合計と比較して、限られた帯域幅（典型的には、１．４ＭＨｚ）のみをサポートするであろう。これにより、より広い帯域幅をサポートする、及び／又は、より複雑なコンポーネントを有するＭＴＣデバイス及び他の通信デバイスと比較して、このような低減帯域幅ＭＴＣデバイスを、（より少ない／より簡単なコンポーネントを用いて、）より経済的にすることが可能になる。
【０００８】
しかし、ＬＴＥシステムの帯域幅は、典型的には、１．４ＭＨｚよりも大きいため（すなわち、２０ＭＨｚまで）、システム帯域幅は、複数の“狭帯域”（又は、“サブ帯域”）に分割され、各狭帯域が最大６つの物理リソースブロック（ＰＲＢ：physical resource blocks）を有し、この数は、１．４ＭＨｚの帯域幅に制限されたＭＴＣデバイスがＬＴＥで使用できるＰＲＢの最大数である。
【０００９】
ｅＭＴＣ（“enhanced” MTC）のフレームワークの一部として、３ＧＰＰは、ＭＴＣ固有の狭帯域を次のように定義している。
・各狭帯域のサイズは６つのＰＲＢである。
・システムの帯域幅におけるダウンリンク（ＤＬ：downlink）の狭帯域の総数（ＮＢｗｈｏｌｅ）は、次のように定義される。
【数１】
2019523614.tif 000003
・システムの帯域幅におけるアップリンク（ＵＬ：uplink）の狭帯域の総数（ＮＢｗｈｏｌｅ）は、次のように定義される。
【数２】
2019523614.tif 000004
・残りのリソースブロック（任意の狭帯域の一部も形成しないもの）は、システム帯域幅の任意の奇数のＰＲＢ（例えば、システム帯域幅が３，５及び１５ＭＨｚのケース）がシステム帯域幅の中心に位置するように、システム帯域幅の両端で均等に分割される（すなわち、システム帯域幅の最低周波数付近及び最高周波数付近のＲＢが同数になるようにする）。
・狭帯域は、ＰＲＢナンバーが増加する順にナンバリングされる。
ここで、
【数３】
2019523614.tif 000005
及び
【数４】
2019523614.tif 000006
は、（それぞれダウンリンク及びアップリンクの）システム帯域幅のＰＲＢの数を表す。
【００１０】
ＭＴＣデバイス（特に、低減帯域幅ＭＴＣデバイス）は、しばしば単純なコンポーネントを有するため、ＭＴＣデバイスの動作が制限されることもある。例えば、ＭＴＣデバイスのトランシーバは、従来のＬＴＥ通信デバイスに対して規定された方法で、周波数リチューニング動作（すなわち、ある周波数帯域から別の周波数帯域へのチューニング）を実行することができない可能性がある。具体的には、３ＧＰＰ文書Ｎｏ．Ｒ１−１５５０５１で結論が出たように、ＭＴＣデバイスは、ＭＴＣデバイスが任意のデータも送信も又は受信もできないリチューニング動作の間に、ＭＴＣデバイスのトランシーバを異なる狭帯域領域間でリチューニングするために、２つのＯＦＤＭ（Orthogonal Frequency Division Multiplexing）シンボル（また、通常のサイクリックプレフィクス（ＣＰ：cyclic prefix）長と仮定した、関連するＣＰも含む）が必要になると、予想されている。従って、（ＲＡＮ４グループの）関連する３ＧＰＰ要件は、ＭＴＣデバイスのための２つのＯＦＤＭシンボルの最大リチューニング時間に基づくものになると予想されている。しかし、幾つかのＭＴＣデバイス（及び、他のＵＥ）は、単一のＯＦＤＭシンボル（通常のＣＰを含む）内で、又は、ＳＣ−ＦＤＭＡ（Single Carrier Frequency Division Multiple Access）が使用される場合は単一のＳＣ−ＦＤＭＡシンボル内で、リチューニングを実行することも予想されている。
【発明の概要】
【発明が解決しようとする課題】
【００１１】
本発明者らは現在、ＭＴＣデバイスに関して、ｅＭＴＣフレームワーク及び関連する標準で定義されているように、基地局は、ＣＰ長を含む２つのＯＦＤＭシンボルの最大リチューニング時間を常に仮定するであろうと認識している。しかし、リチューニングのために２つのシンボルを常に使用することは効率的ではなく、また、少なくとも単一のシンボル内でトランシーバをリチューニングすることが可能なＵＥにとっては、貴重なリソースを浪費してしまう。さらに、許容するリチューニングのために予約された（未使用の）リソースの量は、多数のＭＴＣデバイス（潜在的には、数百万オーダーのＭＴＣデバイス）がオペレータのネットワークに配備されることに伴い、大幅に増加する。その結果、たとえＭＴＣデバイスの幾つか／多くが、高速リチューニング、例えば、１シンボル内のリチューニングが可能であっても、ネットワークリソースの大部分が使用されないことになる。
【００１２】
従って、本発明は、これらの問題に対処するか又は少なくとも軽減する一方で、狭帯域の提供に関する上述の要件も満たすことができるシステム、デバイス、及び方法を提供することを目指すものである。
【課題を解決するための手段】
【００１３】
一態様では、本発明は、通信システムのための基地局を提供する。ここで、前記基地局は、複数の狭帯域であって、各狭帯域がその狭帯域を識別するインデックスを有する複数の狭帯域を含むセル帯域幅を有するセルを動作させるためのコントローラと、前記セル内の複数の通信デバイスと通信するためのトランシーバと、を備え、前記コントローラは、通信デバイスから受信された通信に基づいて、その通信デバイスが狭帯域間でリチューニングする能力を識別し、その通信デバイスに対し、その通信デバイスが異なる狭帯域間でどのようにリチューニングするかを制御するための制御情報を提供するように動作可能であり、前記制御情報は、その通信デバイスについて識別された、狭帯域間でリチューニングする能力に基づくものである。
【００１４】
別の態様では、本発明は、基地局によって動作されるセル内で通信するための通信デバイスを提供する。セルは、複数の狭帯域であって、各狭帯域がその狭帯域を識別するインデックスを有する複数の狭帯域を含む、関連するセル帯域幅を有する。ここで、前記通信デバイスは、狭帯域間でリチューニングする能力を識別する通信を前記基地局に送信すると共に、前記通信デバイスが異なる狭帯域間でどのようにリチューニングするかを制御するための制御情報であって、前記通信デバイスについて識別された、狭帯域間でリチューニングする能力に基づく制御情報を、前記基地局から受信するように動作可能なトランシーバと、前記受信された制御情報に従って、前記基地局との間でデータを通信する場合に前記トランシーバを制御するためのコントローラと、を備える。
【００１５】
本発明の態様は、上記の態様及び可能性又は請求項に記載された方法を実行するようプログラム可能なプロセッサをプログラムするように、及び／又は、請求項のいずれかに記載の装置を提供するために適切に適合したコンピュータをプログラムするように、動作可能な命令を格納したコンピュータ可読媒体などの対応するシステム、方法、及びコンピュータプログラム製品に拡張される。
【００１６】
本明細書（この用語は、特許請求の範囲を含む）及び／又は図面に示された各特徴は、他の開示された及び／又は図示された特徴とは独立して（又は組み合わせて）本発明に組み込まれても良い。特定の独立請求項に従属する請求項のいずれかの特徴は、その独立請求項に任意の組合せで又は個別に導入することができるが、これに限定されない。
【００１７】
本発明の例示的な実施形態を、添付の図面を参照してのみ、例として説明する。
【図面の簡単な説明】
【００１８】
【図１】本発明の例示的な実施形態が適用可能な通信システムを概略的に示す図である。
【図２】ＭＴＣデバイス準拠の狭帯域が図１に示されたシステムに提供される例示的な方法を示す図である。
【図３】図１に示された通信デバイスの主要なコンポーネントを示すブロック図である。
【図４】図１に示された基地局の主要なコンポーネントを示すブロック図である。
【図５】図１に示されたシステムにおけるＭＴＣデバイスのためのリチューニング動作を概略的に示す図である。
【図６】本発明の例示的な実施形態に係る、ＭＴＣデバイス及び基地局により実行される手順を示す例示的なタイミング（シグナリング）図である。
【図７】図１に示されたシステムにおけるＭＴＣデバイスのためのリチューニング期間を実現することができる例示的な方法を示す図である。
【図８】図１に示されたシステムにおけるＭＴＣデバイスのためのリチューニング期間を実現することができる例示的な方法を示す図である。
【図９】図１に示されたシステムにおけるＭＴＣデバイスのためのリチューニング期間を実現することができる例示的な方法を示す図である。
【図１０】図１に示されたシステムにおけるＭＴＣデバイスのためのリチューニング期間を実現することができる例示的な方法を示す図である。
【発明を実施するための形態】
【００１９】
概要
図１は、通信デバイス３（例えば、モバイル電話３−１及びＭＴＣデバイス３−２）が、Ｅ−ＵＴＲＡＮ基地局５（“ｅＮＢ”と表記される）及びコアネットワーク７を介して、相互に及び／又は他の通信ノードと通信可能なモバイル（セルラー）通信システム１を概略的に示している。当業者であれば理解されるように、図１では、１つのモバイル電話３−１、１つのＭＴＣデバイス３−２、及び１つの基地局５が例示の目的で示されているが、システムは、実装されると、通常、他の基地局及び通信デバイスを含むことになるであろう。
【００２０】
基地局５は、Ｓ１インタフェースを介してコアネットワーク７に接続されている。簡略化のために図１から省略されているが、コアネットワーク７は、特に、インターネットなどの他のネットワーク及び／又はコアネットワーク７の外部でホストされるサーバに接続するためのゲートウェイと、通信ネットワーク１内の通信デバイス３（例えば、モバイル電話及びＭＴＣデバイス）のロケーションを追跡し続けるためのモバイル管理エンティティ（ＭＭＥ：mobility management entity）と、加入者関連情報（例えば、どの通信デバイス３がマシンタイプの通信デバイスとして構成されているかを識別する情報）を格納し、各通信デバイス３に固有の制御パラメータを格納するホーム加入者サーバ（ＨＳＳ：home subscriber server）と、を含む。
【００２１】
基地局５は、例えば、物理ダウンリンク制御チャネル（ＰＤＣＣＨ：physical downlink control channel）及び物理アップリンク制御チャネル（ＰＵＣＣＨ：physical uplink control channel）を含む、制御チャネルの数を提供するように構成される。ＰＤＣＣＨは、（典型的には、現在のスケジューリングラウンドでスケジュールされた各通信デバイスにそれぞれのＵＥ固有のダウンリンク制御情報（ＤＣＩ：downlink control information）を送信することによって、）通信デバイス３にリソースを割り当てるために、基地局５によって使用される。ＰＵＣＣＨは、基地局にＵＥ固有のアップリンク制御情報（ＵＣＩ：uplink control information）（例えば、ＤＣＩによって割り当てられたリソースを使用して受信されたダウンリンクデータに対応する適切なＨＡＲＱ  Ａｃｋ／Ｎａｃｋフィードバック）を送信するために、通信デバイス３によって使用される。
【００２２】
このような低減帯域幅ＭＴＣデバイスをそのセル内でサポートするために、図１の基地局５のシステム帯域幅は、複数の重複しない狭帯域に分割される。システム帯域幅内の狭帯域は、Ｒｅｌ−１３の複雑性が低いＭＴＣ  ＵＥのための狭帯域のための効率的なリソース割り当てシグナリングを維持することができるように割り当てられる。
【００２３】
図２に示されるように、各狭帯域は、６つのリソースブロックを含み、また、周波数帯域幅のエッジにて均等に分配される幾つかの残りのリソースブロック（６つ未満のリソースブロック）が存在する。システム帯域幅は、
【数５】
2019523614.tif 000007
の合計で構成され、各ＰＲＢは、
【数６】
2019523614.tif 000008
の範囲内のそれぞれの関連するリソースブロックインデックスを有する。
この例では、合計で８つの狭帯域が存在し、それぞれが、“０”と“７”との間のそれぞれ関連するインデックスを有し、ＰＲＢナンバーが増加する順にナンバリングされている。
【００２４】
具体的には、システム帯域幅内の狭帯域の総数は、以下の式を使用して定義される。
【数７】
2019523614.tif 000009
ここで、ＮＢｗｈｏｌｅは、システム帯域幅内の１．４ＭＨｚの狭帯域の総数（各狭帯域は６つのＰＲＢからなる）である。
【数８】
2019523614.tif 000010
は、システム帯域幅内のダウンリンク（ＤＬ：downlink）リソースブロックの総数である。そして、
【数９】
2019523614.tif 000011
は、床関数（すなわち、“ｘ”を超えない最大の整数）である。
【００２５】
この例では、基地局５のセルにおける（ダウンリンク）システム帯域幅は、５０のＰＲＢ
【数１０】
2019523614.tif 000012
であり、これは周波数帯域幅の約１０ＭＨｚに相当する。
各狭帯域は、６つのＰＲＢ（すなわち、帯域幅が限定されたＭＴＣデバイスが使用可能なＰＲＢの最大数）を含む。従って、システム帯域幅の合計４８個のＰＲＢを占める、最大８個の全狭帯域（すなわち、ＮＢｗｈｏｌｅ＝８）を提供することができる。さらに、残りのリソースブロックは、各々が（システム帯域幅のエッジにある）１つのＰＲＢを含む２つの“部分的狭帯域（partial narrowbands）”に分割される。これらの残りのリソースブロックは、適切であれば、準拠のＭＴＣデバイス（又は他のユーザ機器）に割り当てられても良いことが理解されるであろう。又は、残りのリソースブロックは、他のＵＥによる使用のために（例えば、非ＭＴＣ使用のために）、及び／又は、制御データの送信のために、割り当てられても良い。
【００２６】
有益的には、狭帯域インデックスナンバーは、ＭＴＣデバイスへの狭帯域の効率的な割り当てを容易にする。この例では、ＰＲＢナンバーが増加する順にインデックス付けが行われる。図２には示されていないが、部分的狭帯域には、それぞれのインデックスナンバーも提供できることが理解されるであろう。
【００２７】
ここで図１に戻ると、各通信デバイス３は、ＵＥの１以上のカテゴリに分類されても良い。ＵＥの第１のカテゴリは、基地局５のセル内で利用可能な全帯域幅にわたって通信可能な、モバイル電話などの、従来の（すなわち、非ＭＴＣの）通信デバイスを含む。ＵＥの第２のカテゴリは、基地局５のセル内で利用可能な全帯域幅にわたって通信することができない、帯域幅が低減されたＵＥ（例えば、１．４ＭＨｚの帯域幅のみを使用可能なＲｅｌ−１３のＭＴＣデバイス）を含む。第２のカテゴリのＵＥは、２つのＯＦＤＭシンボルの最大期間内でリチューニング動作を実行可能であっても良い。ＵＥの第３のカテゴリは、１．４ＭＨｚの帯域幅のみを使用して通信するように構成されるが、１つのＯＦＤＭシンボルの最大期間内でリチューニング動作を実行可能な、帯域幅が低減されたＵＥ（例えば、ＭＴＣ機能を備える、幾つかのＭＴＣデバイス／モバイル電話）を含む。
【００２８】
この例では、モバイル電話３−１は、ＵＥの第１カテゴリに分類され、また、（例えば、ＭＴＣアプリケーションを実行している場合には）ＵＥの第３カテゴリにも分類される。従って、モバイル電話３−１は、（要求された、いかなるリチューニングを行うことなく、）一度に全システム帯域幅を使用することができるか、又は、単一のＯＦＤＭシンボル内で（異なる狭帯域間の）リチューニング動作を実行することができる。一方、ＭＴＣデバイス３−２は、ＵＥの第２カテゴリに分類され、また、２つのＯＦＤＭシンボルの最大期間内でリチューニング動作を実行することができる。
【００２９】
有益的には、このシステムの通信デバイス３は、通信デバイス３のリチューニング能力（すなわち、通信デバイス３が１つ又は２つのシンボル内で狭帯域間のリチューニングが可能であるかどうか）を基地局５に通知するように構成される。
【００３０】
あるオプションでは、各通信デバイス３は、無線リソース制御（ＲＲＣ：radio resource control）シグナリングを使用して、そのリチューニング能力について、基地局５に通知するように構成される。例えば、各通信デバイスは、基地局５に送信されるＲＲＣシグナリングメッセージに適切な情報（例えば、１ビットインジケーション／情報要素／フラグ）を含めても良い。このようなリチューニング能力情報は、適切にフォーマットされたＲＲＣコネクション（再）コンフィギュレーションリクエストなどの任意の適切なＲＲＣメッセージ、及び／又は、ランダムアクセス手順に関連するメッセージ（例えば、ランダムアクセス手順のメッセージ＃３又は＃５）に追加されても良いことは、理解されるであろう。
【００３１】
別のオプションでは、リチューニング能力情報（１ビットインジケーション／フラグ）は、フィーチャグループインジケータ（ＦＧＩ：Feature Group Indicator）シグナリング手順のメッセージに追加されても良い。
【００３２】
さらに別のオプションでは、特定のリチューニング能力を示す目的のために、既存のシグナリング情報（例えば、ＭＴＣデバイスに通常関連する適切なＵＥ能力シグナリング）を再利用することが可能である。換言すると、リチューニング能力情報は、別のＵＥ（ＭＴＣ）能力情報と共に、提供されても良い。具体的には、ＭＴＣデバイスに固有の、既存の“ロングアップリンク送信のためのＵＬ送信ギャップ（UL Transmission Gaps for long uplink transmissions）”情報要素（ＩＥ：information element）を使用して、送信側の通信デバイス３が単一のシンボル（通常のＣＰを含む）内でリチューニングを実行できるかどうかを示しても良いことが、理解されるであろう。この場合、特定の通信デバイス３が、ロングアップリンク送信のためのＵＬ送信ギャップを必要であることを、（適切にフォーマットされた“ロングアップリンク送信のためのＵＬ送信ギャップ”ＩＥを送信することによって、）基地局５に示す場合、基地局５は、この情報要素を解釈して、送信側の通信デバイス３が２つのシンボル内でリチューニング可能であることを意味すると判断するように構成されても良い。そうでなければ、基地局５は、（ロングアップリンク送信のためのＵＬ送信ギャップを必要としない）送信側の通信デバイス３が、１つのシンボル内でリチューニング可能であると仮定するように構成されても良い。
【００３３】
どのオプションが選択されても、受信されたリチューニング能力情報は、単純なＯＮ／ＯＦＦタイプのインジケーション（例えば、１ビットインジケーション／フラグに特定の値がセットされている場合には、送信側のＵＥが、２つのシンボルのリチューニング期間を必要としていることを示し、１ビットインジケーション／フラグに他の値がセットされている場合には、送信側のＵＥが、１つのシンボルのリチューニング期間を必要としていることを示すインジケーション）として、基地局５によって解釈されても良い。例えば、ＵＥの第１のカテゴリ又は第３のカテゴリ（又はその両方）に分類される通信デバイス３は、１ビットインジケーション／フラグを値“１”／“ＯＮ”にセットするように構成されても良く、また、ＵＥの第２のカテゴリに分類される通信デバイス３は、１ビットインジケーション／フラグを、“０”／“ＯＦＦ”にセットするように構成されても良い（又はその逆）。
【００３４】
従って、基地局５は、受信されたインジケーション／フラグを次のように解釈するように構成されても良い。
“１”又は“ＯＮ”：この特定のＵＥは、単一のシンボル（ＣＰを含む）内の狭帯域間でリチューニング可能なトランシーバを有している。
“０”又は“ＯＦＦ”：この特定のＵＥは、２つのシンボル（ＣＰを含む）内の狭帯域間でリチューニング可能なトランシーバを有している。
【００３５】
特に有益的な例では、基地局５は、ＵＥの第１のカテゴリ又は第３のカテゴリに属する通信デバイス３（単一のシンボル内でリチューニング可能なＭＴＣデバイス及び他のユーザ機器）のための別個の（専用の）ＰＲＡＣＨリソースを維持するように構成されても良い。従って、１つのＯＦＤＭシンボル内でリチューニング可能な任意の通信デバイスは、このような別個のＰＲＡＣＨリソースであって送信側のＵＥが１つのＯＦＤＭシンボル内でリチューニング可能であることを基地局５に（暗示的に）示しているＰＲＡＣＨリソースを使用して、ＰＲＡＣＨを送信するように構成されても良い。同様に、ＵＥの第２のカテゴリに属するＭＴＣデバイス３（例えば、低度なＭＴＣデバイス（less advanced MTC devices））は、（これらＭＴＣデバイスが高速リチューニングからの恩恵を望むことができない又は望まなければ、）通常の（又はＭＴＣ固有の）ＰＲＡＣＨリソースを使用するように構成されても良い。従って、任意の通信デバイス３は、適切なＰＲＡＣＨリソースを使用することによって、その通信デバイス３が、１つのシンボル内で又は２つのシンボル内でリチューニング可能であるかどうかを基地局５に（暗示的に）示すことができる。
【００３６】
特定の通信デバイスがそのリチューニングを基地局へ示すと、基地局は、有益的には、通信デバイスが１つ又は２つのＯＦＤＭシンボル内でリチューニング可能であるかどうかを考慮して、その通信デバイスに適切な周波数ホッピング（ミラーリング）パターンを割り当てることができる。従って、高速リチューニング（例えば、単一のＯＦＤＭシンボル内のリチューニング）が可能であり、周波数ダイバーシティから恩恵を受けたり、周波数ホッピング／ミラーリングを使用する場合に実現可能な関連する改良（例えば、改良されたスループット、及び／又は、低減された干渉）から恩恵を受けたりするＭＴＣデバイス（及び、他のユーザ機器）のためのリソースの浪費を回避又は少なくとも低減することが可能である。
【００３７】
有益的には、物理アップリンク共有チャネル（ＰＵＳＣＨ：Physical Uplink Shared Channel）を介した送信及び基地局における関連する動作のためにも、かなりのリソースセービングを達成しても良い。ＰＵＳＣＨリソースセービングの量は、周波数ホッピングの周期性（すなわち、特定の通信デバイスが狭帯域間でどの程度頻繁にホッピングを必要とするか）に依存することが理解されるであろう。通信デバイスが１つのシンボル内でリチューニング可能であり、周波数ホッピング期間が１つのサブフレームにセットされている（すなわち、Ｙｃｈ＝１）場合、ＰＲＢ毎に、（通常のＣＰ長に対して、）８．６％のリソースセービングを達成することができる（すなわち、ＲＳのための２つのシンボルを除いて、１１／１２対１０／１２のシンボルを使用することができる）。有益的には、ＰＵＳＣＨリソースセービングは、通信デバイスのためのサブフレームに割り当てられるＰＲＢの数に依存して、スケールアップする。さらに、ＰＵＳＣＨのためのパンクチャリングが少ないために、ＰＵＳＣＨのデコードの性能も基地局において改善されるであろう。
【００３８】
従って、要約すると、通信システムにおいて、サービング基地局は、有益的には、特定のＵＥ／ＭＴＣデバイスが、少なくともアップリンク送信のために、単一のＯＦＤＭ／ＳＣ−ＦＤＭＡシンボル（ＣＰ長を含む）内で、又は、２つのＯＦＤＭシンボル内で、リチューニングを実行可能かどうかを決定し、そのことを知ることができる。従って、所与のＵＥ／ＭＴＣデバイスが単一のＯＦＤＭ／ＳＣ−ＦＤＭＡシンボル（ＣＰ長を含む）内でリチューニングを実行可能であるか否かを知るという、この能力の結果として、かなりのリソースセービングを達成することができる。
【００３９】
通信デバイス
図３は、図１に示される通信デバイス３の主要なコンポーネントを示すブロック図である。通信デバイス３は、ＭＴＣデバイス又はマシンタイプの通信デバイスとして構成されたモバイル（又は、“セルラー”）電話であっても良い。通信デバイス３は、少なくとも１つのアンテナ３３を介して、基地局５との間で信号を送受信するように動作可能なトランシーバ回路３１を含む。典型的には、通信デバイス３は、ユーザが通信デバイス３と相互に作用することを可能にするユーザインタフェース３５も含む。しかし、このユーザインタフェース３５は、幾つかのＭＴＣデバイスでは省略されても良い。
【００４０】
トランシーバ回路３１の動作は、メモリ３９に格納されたソフトウェアに従って、コントローラ３７によって制御される。ソフトウェアは、特に、オペレーティングシステム４１、通信制御モジュール４２、及びＭＴＣモジュール４５を含む。
【００４１】
通信制御モジュール４２は、通信デバイス３と、基地局５及び／又は（基地局５を介した）他の通信ノードと、の間の通信を制御する。図３に示されるように、通信制御モジュール４２は、特に、狭帯域通信モジュール４３及びリチューニングモジュール４４を含む。
【００４２】
ＭＴＣモジュール４５は、マシンタイプの通信タスクを実行するように動作可能である。例えば、ＭＴＣモジュール４５は、基地局５によってＭＴＣデバイス３に割り当てられたリソース上で、（トランシーバ回路３１を介して、）リモートサーバから、（例えば、周期的に、）データを受信しても良い。また、ＭＴＣモジュール４５は、（トランシーバ回路３１を介して、）リモートサーバへ、（例えば、周期的に及び／又はトリガを検出したときに、）送信するためのデータを収集しても良い。
【００４３】
基地局
図４は、図１に示される基地局５の主要なコンポーネントを示すブロック図である。基地局５は、トランシーバ回路５１を含むＥ−ＵＴＲＡＮ基地局（ｅＮＢ）であり、トランシーバ回路５１は、１以上のアンテナ５３を介して、通信デバイス３との間で信号を送受信するように動作可能である。また、基地局５は、適切なコアネットワークインタフェース５５（Ｓ１インタフェースなど）を介して、コアネットワーク７との間で信号を送受信するように動作可能である。
【００４４】
トランシーバ回路５１の動作は、メモリ５９に格納されたソフトウェアに従って、コントローラ５７によって制御される。ソフトウェアは、特に、オペレーティングシステム６１及び通信制御モジュール６２を含む。
【００４５】
通信制御モジュール６２は、通信デバイス３（任意のＭＴＣデバイスを含む）との通信を制御する。また、通信制御モジュール６２は、この基地局５によってサーブされる通信デバイス３によって使用されるリソースをスケジューリングするための責任を負う。図４に示されるように、通信制御モジュール６２は、特に、狭帯域制御モジュール６３及びリチューニング制御モジュール６４を含む。
【００４６】
以上の説明では、理解を容易にするために、多数の別個のモジュールを有するものとして通信デバイス３及び基地局５について説明した。これらのモジュールは、例えば、既存のシステムが本発明を実施するように変更された特定のアプリケーションのために、この方法で提供されても良いが、例えば、当初から本発明の特徴を考慮して設計されたシステムにおいては、これらのモジュールが全体的なオペレーティングシステムやコードに組み込まれていても良く、そのため、これらのモジュールは、別個のエンティティとして認識されなくても良い。
【００４７】
以下では、ＭＴＣデバイスがＬＴＥシステムでリチューニング動作を実行する様々な方法について説明する。
【００４８】
動作
図５は、図１に示されるシステムにおける通信デバイスのための例示的なリチューニング動作を概略的に示している。
【００４９】
図示されるように、この例では、ＵＥ１（例えば、通信デバイス３−１）は、当初は（例えば、２つのサブフレームの継続時間（duration）のための）狭帯域＃７に割り当てられており、それから（例えば、２つのサブフレームのための）狭帯域＃０にホップする必要がある。同じことがＵＥ２（例えば、通信デバイス３−２）にも同様に適用され、ＵＥ２は、当初は狭帯域＃１に割り当てられており、それから狭帯域＃６にホップする。このプロセスは、周波数ミラーリングとも呼ばれ、各通信デバイスによって使用される周波数（狭帯域）は、システム帯域幅の（仮想的な）中心線の周りで定期的に“ミラーリング”される。有益的には、このような割り当てられた狭帯域のミラーリングは、通信デバイスのための周波数ダイバーシティを改善し、これにより、システムスループットの向上に寄与する。
【００５０】
図５に示される例では、連続する狭帯域領域の間の最大リチューニング時間は、ＣＰ長（すなわち、破線の間の空間）を含む、２つのＯＦＤＭシンボルである。しかし、以下で説明するように、このリチューニング時間は、通信デバイス３のリチューニング能力に依存して、異なる通信デバイス３毎に異なっていても良い。
【００５１】
図６は、ＭＴＣデバイス３のリチューニング能力を基地局５にシグナリングすることと、ＭＴＣデバイス３と基地局５との間の送信のための適切な周波数ホッピング（ミラーリング）パターンを使用することと、に関連する手順を示す、例示的なタイミング（シグナリング）図である。
【００５２】
明らかなように、この手順は、ＭＴＣデバイス３（図６では、“ＵＥ”と表記される）が、ＭＴＣデバイス３のリチューニング能力を基地局５へ示すときに開始される。これは、ステップＳ１００に概略的に示されている。
【００５３】
上述したように、ＭＴＣデバイス３が、ＭＴＣデバイス３のリチューニング機能について基地局５に（明示的又は暗示的に）通知するための幾つかのオプションがある。
【００５４】
オプションＡ：ＲＲＣを介したＵＥ能力のシグナリング
このオプションでは、通信デバイス３は、ステップＳ１００において、ＲＲＣシグナリングメッセージを生成して基地局５に送信することによって、通信デバイス３のリチューニング能力について、基地局５に通知する。例えば、ＭＴＣモジュール４５は、（例えば、リチューニングモジュール４４に格納された）リチューニング能力をチェックし、この情報を、適切にフォーマットされたＲＲＣメッセージを生成するために、通信制御モジュール４２に提供するように構成されても良い。
【００５５】
（通信デバイス３の通信制御モジュール４２を使用する）通信デバイス３は、ＲＲＣシグナリングメッセージに適切な情報（例えば、１ビットインジケーション／情報要素／フラグ）を含めても良い。そのようなリチューニング能力情報は、適切にフォーマットされたＲＲＣコネクション（再）コンフィギュレーションリクエストなどの、任意の適切なＲＲＣメッセージに追加されても良いことが、理解されるであろう。
【００５６】
リチューニング能力情報は、通信デバイス３が単一のシンボル（ＣＰを含む）内でリチューニング可能であるか否かを基地局５に通知するための１ビットインジケーション／フラグを、（生成されたＲＲＣメッセージの一部として、）含んでも良い。換言すると、通信デバイス３は、（少なくともこの特定の通信デバイス３のための）単一のシンボル内でリチューニングをＯＮにする（又は、ＯＦＦにする）かどうかを基地局５に指示することができる。
【００５７】
例えば、通信デバイス３は、（適切な１ビットインジケーション／情報要素／フラグにおいて、）以下の値の１つを含むＲＲＣシグナリングを提供するように構成されても良い。
・ＯＮ（又は、“１”）：通信デバイス３は、単一のシンボル（ＣＰを含む）内でリチューニング動作を実行可能である
・ＯＦＦ（又は、“０”）：通信デバイス３は、単一のシンボル内でリチューニング動作を実行することすることはできないが、２つのシンボル（ＣＰを含む）内でリチューニング可能である。
【００５８】
オプションＢ：既存のシグナリング情報の再利用
典型的には、単一のシンボル（通常のＣＰを含む）内でリチューニングを実行可能なＵＥは、より安価な水晶発振器（ＴＣＸＯ）と比較して、ＸＴＡＬ発振器などの、より高度なハードウェアを有するＵＥ／ＭＴＣデバイスを含む。３ＧＰＰ文書Ｎｏ．Ｒ１−１６６０４２は、ＵＥがダウンリンク受信に切り替え可能なギャップ期間の間に、そのアップリンク送信においてＵＥのためのギャップ期間を提供するために、“ロングアップリンク送信のためのＵＬ送信ギャップ”と呼ばれる新しいＵＥ能力シグナリングを提案した。ＵＥは、タイミング同期及び（そのアップリンク送信を継続する前の）周波数オフセットを推定及び訂正するために、ＤＬリファレンス信号（ＲＳ：reference signals）及び同期信号（ＰＳＳ／ＳＳＳ）を監視するために、アップリンク送信から、（少なくとも一時的に、）ダウンリンク受信に切り替える必要があり得る。ロングアップリンク送信のためのＵＬ送信ギャップを必要としないＵＥは、高価なＸＴＡＬ発振器のような高度なハードウェアを有するものであり、従って、単一のシンボル（通常のＣＰを含む）内でもリチューニングを実行可能であることが、理解されるであろう。
【００５９】
従って、このオプションでは、通信デバイス３及び基地局５は、通信デバイス３のリチューニング能力を示すことを目的として、既存のシグナリング情報（例えば、“ロングアップリンク送信のためのＵＬ送信ギャップ”など）を再利用するように構成される。ＵＥリチューニング能力インジケーションは、（別個のＵＥリチューニング能力インジケーションを提供するのではなく、）既存の“ロングアップリンク送信のためのＵＬ送信ギャップ”ＩＥと組み合わせることが可能である。
【００６０】
従って、通信デバイス３が２つのシンボル（通常のＣＰを含む）内でリチューニングを実行可能である場合、通信デバイス３は、ステップＳ１００において、適切にフォーマットされた“ロングアップリンク送信のためのＵＬ送信ギャップ”ＩＥを生成し、基地局５に送信する。この場合、“ロングアップリンク送信のためのＵＬ送信ギャップ”ＩＥの値は、通信デバイス３によって次のようにセットされる。
・ＯＦＦ（又は、“０”）：通信デバイス３は、ロングアップリンク送信のための送信ギャップを必要とせず、単一のシンボル（ＣＰを含む）内でリチューニング動作を実行可能である
・ＯＮ（又は、“１”）：通信デバイス３は、ロングアップリンク送信のための送信ギャップを必要とし、２つのシンボル（ＣＰを含む）内でリチューニング可能である。
【００６１】
オプションＣ：能力シグナリングのその他のタイプ
通信デバイス３は、ステップＳ１００において、適切にフォーマットされたランダムアクセスメッセージを生成し送信することによって、通信デバイス３のリチューニング能力について基地局５に通知しても良い。この場合、（通信デバイス３の通信制御モジュール４２を使用する）通信デバイス３は、ランダムアクセス手順のメッセージ＃３又はメッセージ＃５にリチューニング能力情報（例えば、１ビットインジケーション／情報要素／フラグ）を含めても良い。
【００６２】
リチューニング能力情報（１ビットインジケーション／フラグ）は、ＦＧＩシグナリング手順の一部として送信されるメッセージに追加されても良いことが理解されるであろう。
【００６３】
従って、通信デバイス３は、（適切な１ビットインジケーション／情報要素／フラグにおいて、）以下の値の１つを含むランダムアクセス及び／又はＦＧＩシグナリングを生成して基地局５に送信するように構成されても良い。
・ＯＮ（又は、“１”）：通信デバイス３は、単一のシンボル（ＣＰを含む）内でリチューニング動作を実行可能である
・ＯＦＦ（又は、“０”）：通信デバイス３は、単一のシンボル内でリチューニング動作を実行することができないが、２つのシンボル（ＣＰを含む）内でリチューニング可能である。
【００６４】
オプションＤ：ＰＲＡＣＨ（暗示的な能力シグナリング）のためのリソースの分離
基地局５は、単一のＯＦＤＭ／ＳＣ−ＦＤＭＡシンボル（ＣＰを含む）内でリチューニング可能なＭＴＣデバイス３のための別個の（専用の）ＰＲＡＣＨリソースを維持するように構成されても良い。これらのリソースは、基地局５（図６には図示せず）によってブロードキャストされたシステム情報ブロック（ＳＩＢ：system information block）情報において、通信デバイス３にシグナリングすることができる。従って、通信デバイス３は、単一のシンボル内でリチューニング可能である場合、ステップＳ１００において、予め割り当てられたリソースを使用して、そのＰＲＡＣＨシグナリングを送信し、それにより、通信デバイス３が単一のＯＦＤＭ／ＳＣ−ＦＤＭＡシンボル（ＣＰを含む）内でリチューニング可能であることを基地局５に通知する。同様に、通信デバイス３は、２つのシンボル内でリチューニング可能である場合、ステップＳ１００において、この通信デバイス３が２つのＯＦＤＭ／ＳＣ−ＦＤＭＡシンボル（ＣＰを含む）内でリチューニング可能であることが基地局５によって解釈されるように、予め割り当てされたリソース以外を使用して、そのＰＲＡＣＨシグナリングを送信する。
【００６５】
ここで図６に戻ると、通信デバイス３が、通信デバイス３のリチューニング能力インジケーションを基地局５に送信した後、手順はステップＳ１０１に進み、ここでは、基地局５は、通信デバイス３とのその後の通信のために、リチューニング能力を（基地局５のリチューニング制御モジュール６４に）格納し、（基地局５の狭帯域制御モジュール６３を使用して、）リチューニング能力を提供する。
【００６６】
ステップＳ１０２に概略的に示されるように、基地局５は、モバイル通信デバイス３のための適切な（リチューニング能力に依存する）周波数ホッピングパターンを適用する。例えば、基地局５は、通信デバイス３のためのＰＵＣＣＨ送信のための適切な周波数ホッピングパターン（すなわち、通信デバイスが単一のＯＦＤＭシンボル内でリチューニング可能であることを示す場合には、通信デバイス３のための各周波数ホップの後に単一のＯＦＤＭシンボルを予約するホッピングパターン、又は、通信デバイスが２つのＯＦＤＭシンボル内でリチューニング可能であることを示す場合には、各周波数ホップの後に２つのＯＦＤＭシンボルを予約するホッピングパターン）を設定しても良い。
【００６７】
通信デバイス３は、受信された周波数ホッピングパターンを、通信デバイス３のリチューニングモジュール４４に格納し、基地局５によるＰＵＣＣＨ送信の監視を開始する。ステップＳ１０３及びＳ１０３’に概略的に示されるように、基地局５は、設定された周波数ホッピングパターンで（各ホップの後にリチューニングのために許容された１つ又は２つのＯＦＤＭシンボルのいずれかで）ＰＵＣＣＨ送信を実行する。
【００６８】
（通信デバイス３のリチューニングモジュール４４を使用する）通信デバイス３は、ステップＳ１０２でシグナリングメッセージを介して設定されたような異なる狭帯域間の周波数ホッピングを実行し、各サブフレームにおいて、そのサブフレームに適した狭帯域におけるＰＵＣＣＨ送信を監視する。
【００６９】
ＰＵＣＣＨリチューニング
図７〜図１０は、図１に示されるシステムにおけるＭＴＣデバイス３のために、適切なリチューニング期間が実現され得る、例示的な方法を示している。
【００７０】
いわゆるパンクチャリング技術は、通信デバイスのためのＰＵＣＣＨリチューニングを容易にするために適用されても良いことが理解されるであろう。この場合、図７に示されるように、例えば、パンクチャリングされたＰＵＣＣＨフォーマット１ａの制御情報に続いて、パンクチャリングされたＰＵＣＣＨフォーマット１の制御情報を、これらの間の２つのパンクチャリングされたＯＦＤＭシンボルと共に送信することによって、２つのシンボルがリチューニングのために提供されても良い（ここで、第１のパンクチャリングされたＯＦＤＭシンボルはＰＵＣＣＨフォーマット１ａの最後のシンボルであり、第２のパンクチャリングされたＯＦＤＭシンボルは、ＰＵＣＣＨフォーマット１の最初のシンボルである）。このタイプの送信は、（カバーコードがもはやパンクチャリングのために直交しないため、）ＰＵＣＣＨ性能を劣化させる可能性があるが、第２のＵＥカテゴリのＭＴＣデバイスは、依然として、（２つのパンクチャリングされたシンボルにより表されるリチューニング期間内で、）リチューニングを実行可能である。
【００７１】
図８に示されるように、（少なくとも準拠の通信デバイスのための）単一のシンボルのリチューニング期間を提供するために、パンクチャリングを使用しても良い。この場合、（その最後のシンボルがパンクチャリングされている）ＰＵＣＣＨフォーマット１ａの制御情報の後に、完全なＰＵＣＣＨフォーマット１の送信が続く。この配置は、第２のサブフレームでの直交性の損失がないので、（図７に示される配置と比較して、）ＰＵＣＣＨ性能が改善される。
【００７２】
図９及び図１０は、“レートマッチング”を使用することによる、ＰＵＣＣＨ送信及びリチューニングを示している。
【００７３】
図９では、２つのシンボルがリチューニングのために使用されている。これは、短くされたＰＵＣＣＨフォーマット１ａの制御情報に続いて、短くされたＰＵＣＣＨフォーマット１の制御情報を送信することによって達成される（それぞれが１つのＯＦＤＭシンボルによって短くされ、その結果、２つのＯＦＤＭシンボルの組み合わされたリチューニング期間が効果的に得られる）。明らかなように、リチューニング期間の第１シンボルは、短くされたＰＵＣＣＨフォーマット１ａの最後のシンボルの直後のＯＦＤＭシンボルであり、また、リチューニング期間の第２シンボルは、短くされたＰＵＣＣＨフォーマット１の直前のＯＦＤＭシンボルである。この配置は、（幾つかのケースでは、例えば、異なるユーザに対するＳＦ＝４とＳＦ＝３との間において、カバーコードがもはや直交しないため、）ＰＵＣＣＨ性能を劣化させる可能性があるが、第２のＵＥカテゴリにおけるＭＴＣデバイスは、依然として、（２つのＯＦＤＭシンボルのリチューニング期間内で）リチューニングを実行可能である。
【００７４】
図１０に示されるように、（少なくとも準拠の通信デバイスのための）単一のシンボルのリチューニング期間を提供するために、レートマッチングを使用しても良い。この場合、短くされたＰＵＣＣＨフォーマット１ａの制御情報の後に、１つのシンボルのリチューニング期間後の完全なＰＵＣＣＨフォーマット１の送信が続く。この配置は、第２のサブフレームでの直交性の損失がないので、（図９に示される配置と比較して、）ＰＵＣＣＨ性能が改善される。
【００７５】
変更及び代替
以上、詳細な例示的な実施形態について説明した。当業者には理解されるように、上記の実施の形態は、多くの変更及び代替がなされても良く、そこに具体化される発明についても同様の利点がある。
【００７６】
上記の例示的な実施形態では、システム帯域幅の一部を参照する場合に、用語“狭帯域”を使用して説明しているが、用語“サブバンド”が使用されても良いことが理解されるであろう。従って、狭帯域及びサブバンドという用語は、同じ意味であり、互換的に使用することができる。
【００７７】
通信システムは、Ｅ−ＵＴＲＡＮ基地局（ｅＮＢ）として動作する基地局に関して説明されているが、マクロ基地局又はピコ基地局として動作する基地局、フェムト基地局、基地局機能の要素を提供する中継局、ホーム基地局（ＨｅＮＢ：home base stations）、又は、他のそのような通信ノードに適用されても良いことが、理解されるであろう。
【００７８】
上記の例示的な実施形態では、ＬＴＥ通信システムが説明された。当業者には理解されるように、本願に記載された技術は、以前の３ＧＰＰタイプのシステムを含む他の通信システムで使用することができる。他の通信ノード又はデバイスは、例えば、パーソナルデジタルアシスタント、ラップトップコンピュータ、ウェブブラウザなどのユーザデバイスを含んでも良い。
【００７９】
上記の例示的な実施形態では、基地局及び通信デバイスのそれぞれは、トランシーバ回路を含む。典型的には、この回路は専用のハードウェア回路によって形成される。しかし、幾つかの例示的な実施形態では、トランシーバ回路の一部は、対応するコントローラによって実行されるソフトウェアとして実現されても良い。
【００８０】
上記の例示的な実施形態では、幾つかのソフトウェアモジュールが説明された。当業者には理解されるように、ソフトウェアモジュールは、コンパイルされた形態又はコンパイルされていない形態で提供されても良く、コンピュータネットワーク又は記録媒体上の信号として基地局又は通信デバイスに供給されても良い。さらに、このソフトウェアの一部又は全部によって実行される機能は、１以上の専用のハードウェア回路を使用して実行されても良い。
【００８１】
上記の例示的な実施形態では、マシンタイプの通信デバイス及びモバイル電話が説明されている。しかし、モバイル電話（及び、同様のユーザ機器）も、マシンタイプの通信デバイスとして動作するように構成されても良いことが理解されるであろう。例えば、モバイル電話３−１は、ＭＴＣモジュール４５を含んでも良い（及び／又は、ＭＴＣモジュール４５の機能を提供しても良い）。
【００８２】
ＭＴＣアプリケーションの例
各通信デバイスは、１つ以上のＭＴＣアプリケーションをサポートしても良いことが理解されるであろう。ＭＴＣアプリケーションの幾つかの例は、次の表（参照元：３ＧＰＰ  ＴＳ  ２２．３６８  Ｖ１３．１．０、Ａｎｎｅｘ  Ｂ）にリストされている。このリストは、完全に網羅したものではなく、マシンタイプの通信アプリケーションの範囲を示すことを意図したものである。
【００８３】
【表１】
2019523614.tif 000013
【００８４】
非ｅＭＴＣ  ＵＥ（例えば、上位エンドのＵＥ）のためのソリューション
悪いチャネル状況の下で動作する場合、非ｅＭＴＣ  ＵＥも、（狭帯域サポート、カバレッジ向上技術などを含む）ｅＭＴＣ機能を実装できることが理解されるであろう。しかし、このような非ｅＭＴＣ  ＵＥは、ｅＭＴＣデバイスよりも複雑なハードウェア及び実装を有するため、ＣＰ長内で又は１つのＯＦＤＭ／ＳＣ−ＦＤＭＡシンボル内で依然としてリチューニング可能である。
【００８５】
これらのタイプのＵＥのためのシグナリングを調整するために、上記で提案されたシグナリングは、次のように変更されても良い。例えば、通信デバイスによる１ビットシグナリング（ＯＮ／ＯＦＦインジケーション／フラグ／ＩＥ）は、次のように解釈することができる。
・ＯＮ（又は、“１”）：通信デバイス３は、ＣＰ長内でリチューニング動作を実行可能である
・ＯＦＦ（又は、“０”）：通信デバイス３は、単一のシンボル（ＣＰを含む）内でリチューニング動作を実行可能である
【００８６】
この場合、基地局は、（上述のように）ＵＥ能力を知ると、ＣＰ長又は１つのシンボルのリチューニング期間を適用することができる。そのようなインジケーションがない場合、基地局は、（少なくとも、通信デバイスから、ＵＥリチューニング能力情報を受信するまで、）２つのシンボルの（デフォルトの）リチューニング期間を適用するように構成されても良い。換言すると、基地局は、３つの異なるリチューニング能力で区別されても良い。３つの異なるリチューニング能力は、ｉ）（ＵＥによって示されている場合には、）ＣＰ長内の通常の（ＬＴＥの）リチューニング能力、ｉｉ）（例えば、示されている場合には、通常のＵＥ及び高度なＭＴＣデバイスのための）単一のＯＦＤＭシンボル内のリチューニング、及び、ｉｉｉ）（例えば、何らも示されていない場合には、単純なＭＴＣデバイスのための）２つのＯＦＤＭシンボルのデフォルト期間内のリチューニング、を含む。
【００８７】
通信デバイスから基地局への通信は、その通信デバイスが狭帯域間でリチューニングする能力であって基地局が識別する能力に基づいて、通信デバイスからの少なくとも１つのシグナリングメッセージ（例えば、無線リソース制御メッセージ、ランダムアクセス手順に関連するメッセージ、フィーチャグループインジケータメッセージなど）を含んでも良い。
【００８８】
少なくとも１つのシグナリングメッセージは、通信デバイスが１つのシンボル又は２つのシンボル（例えば、ＯＦＤＭ（Orthogonal Frequency Division Multiplexing）シンボル、又は、ＳＣ−ＦＤＭＡ（Single Carrier Frequency Division Multiple Access）シンボル）内で狭帯域間のリチューニングが可能であるかどうかを基地局にシグナリングするように構成された、フラグ及び適切にフォーマットされた情報要素（例えば、“ロングアップリンク送信のためのＵＬ送信ギャップ”情報要素、“ＭＴＣリチューニング能力”情報要素など）の少なくとも１つを含んでも良い。
【００８９】
通信デバイスのトランシーバは、狭帯域間のリチューニングのためにトランシーバの能力に依存する通信リソースを使用して通信を送信するように動作可能であっても良い。この場合、基地局のコントローラは、その通信デバイスから受信した通信のために使用されるリソースに基づいて、狭帯域間でリチューニングをするために、その通信デバイスの能力を識別するように構成されても良い。
【００９０】
狭帯域は、それぞれ異なる周波数範囲をカバーしても良く、狭帯域のインデックスは、これらインデックスが表す狭帯域によってカバーされる周波数範囲でシーケンシャルに増加しても良い。セル帯域幅内の狭帯域の数は、次の式を使用して定義しても良い。
【数１１】
2019523614.tif 000014
ここで、ＮＢｗｈｏｌｅは、セル帯域幅内の狭帯域の数であり、ＮＢＲＢは、セル帯域幅内のリソースブロックの数であり、ｎは、各狭帯域内のリソースブロックの数である。また、
【数１２】
2019523614.tif 000015
は、床関数（すなわち、“ｘ”を超えない最大の整数）である。
【００９１】
制御情報は、狭帯域間でリチューニングするためのシンボル（例えば、ＯＦＤＭ（Orthogonal Frequency Division Multiplexing）シンボル又はＳＣ−ＦＤＭＡ（Single Carrier Frequency Division Multiple Access）シンボル）の数を識別しても良い。
【００９２】
制御情報は、異なる狭帯域間でリチューニングするための、パンクチャリングされた制御フォーマット及び／又は短くされた制御フォーマット（例えば、物理アップリンク制御チャネル（ＰＵＣＣＨ：Physical Uplink Control Channel）フォーマット１又はＰＵＣＣＨフォーマット１ａ）の少なくとも１つを識別しても良い。
【００９３】
制御情報は、周波数ホッピングパターン及び／又は周波数ミラーリングパターンを識別しても良い。
【００９４】
基地局は、ＬＴＥ（long term evolution）無線アクセスネットワークの基地局であっても良い。通信は、セル帯域幅と比較して低減された帯域幅を使用して通信するように動作可能なマシンタイプ通信（“ＭＴＣ”）デバイスを含んでも良い。
【００９５】
様々な他の変更が当業者には明らかであり、ここではさらに詳細には説明しない。
【００９６】
本出願は、２０１６年８月３日に出願された英国特許出願第１６１３４０７．４号に基づく優先権を主張し、その開示の全体が参照により本明細書に組み込まれる。
【図１】
2019523614.tif 000018
【図２】
2019523614.tif 000019
【図３】
2019523614.tif 000020
【図４】
2019523614.tif 000021
【図５】
2019523614.tif 000022
【図６】
2019523614.tif 000023
【図７】
2019523614.tif 000024
【図８】
2019523614.tif 000025
【図９】
2019523614.tif 000026
【図１０】
2019523614.tif 000027
【手続補正書】
【提出日】平成31年2月1日(2019.2.1)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
複数の狭帯域のいずれかを使用して通信可能なユーザ機器（ＵＥ：user equipment）により実行される方法であって、
第１の狭帯域から第２の狭帯域へのＵＥリチューニングのための２つの連続するサブフレーム間のシンボル数を示す情報を、基地局に送信するステップと、
物理アップリンク制御チャネル（ＰＵＣＣＨ：physical uplink control channel）フォーマット及びＵＥリチューニングのための前記シンボル数に従って、前記基地局への送信を制御するステップと、を含み、
短くされたＰＵＣＣＨフォーマットに従って、１つのシンボルがＵＥリチューニングのために使用される場合、前記ＵＥは、第１のサブフレームにおいて、最後のシンボルを使用して送信することはせず、
前記短くされたＰＵＣＣＨフォーマットに従って、２つのシンボルがＵＥリチューニングのために使用される場合、前記ＵＥは、前記第１のサブフレームにおいて、前記最後のシンボルを使用して送信することをせず、かつ、第２のサブフレームの最初のシンボルを使用して送信することはしない、
方法。
【請求項２】
２つの連続するサブフレーム間のシンボル数を示す前記情報は、無線リソース制御（ＲＲＣ：radio resource control）シグナリングを使用して送信される、
請求項１に記載の方法。
【請求項３】
２つの連続するサブフレーム間のシンボル数を示す前記情報は、ＵＥ能力情報要素によって提供される、
請求項１又は２に記載の方法。
【請求項４】
ＵＥリチューニングのための２つの連続するサブフレーム間の前記シンボル数に基づいて、前記基地局から、狭帯域間のリチューニングのためのシンボル数を識別する制御情報を受信するステップをさらに含む、
請求項１から３のいずれか１項に記載の方法。
【請求項５】
ＵＥリチューニングのための２つの連続するサブフレーム間の前記シンボル数に基づいて、前記基地局から、異なる狭帯域間のリチューニングのための、パンクチャリングされた制御フォーマット及び／又は短くされた制御フォーマットの少なくとも１つを識別する制御情報を受信することをさらに含む、
請求項１から４のいずれか１項に記載の方法。
【請求項６】
ＵＥリチューニングのための２つの連続するサブフレーム間の前記シンボル数に基づいて、前記基地局から、周波数ホッピングパターン及び／又は周波数ミラーリングパターンを識別する制御情報を受信するステップをさらに含む、
請求項１から５のいずれか１項に記載の方法。
【請求項７】
前記ＵＥは、限定された帯域幅内で動作するように制限されたＵＥである、
請求項１から６のいずれか１項に記載の方法。
【請求項８】
前記狭帯域は、それぞれ異なる周波数範囲をカバーし、前記狭帯域は、インデックスを有し、前記インデックスは、前記インデックスが表す前記狭帯域によってカバーされる前記周波数範囲でシーケンシャルに増加する物理リソースブロックナンバーが増加する順にナンバリングされている、
請求項１から７のいずれか１項に記載の方法。
【請求項９】
所与のセル帯域幅に対して、狭帯域の数は、次の式を使用して定義され、
【数１】
2019523614.tif 000028
ここで、ＮＢｗｈｏｌｅは、前記セル帯域幅内の狭帯域の数であり、ＮＲＢは、前記セル帯域幅内のリソースブロックの数であり、ｎは、各狭帯域内のリソースブロックの数であり、
【数２】
2019523614.tif 000029
は、床関数（すなわち、“ｘ”を超えない最大の整数）である、
請求項８に記載の方法。
【請求項１０】
複数の狭帯域のいずれかを使用してユーザ機器（ＵＥ：user equipment）と通信可能な基地局により実行される方法であって、
第１の狭帯域から第２の狭帯域へのＵＥリチューニングのための２つの連続するサブフレーム間のシンボル数を示すＵＥ能力情報要素を、前記ＵＥから、無線リソース制御（ＲＲＣ：radio resource control）シグナリングで受信するステップと、
物理アップリンク制御チャネル（ＰＵＣＣＨ：physical uplink control channel）フォーマット及びＵＥリチューニングのための前記シンボル数に従って、前記基地局を制御するステップと、を含み、
短くされたＰＵＣＣＨフォーマットに従って、１つのシンボルがＵＥリチューニングのために使用される場合、前記基地局は、第１のサブフレームにおいて、最後のシンボルを使用して前記ＵＥからの送信を受信することはせず、
前記短くされたＰＵＣＣＨフォーマットに従って、２つのシンボルがＵＥリチューニングのために使用される場合、前記基地局は、前記第１のサブフレームにおいて、前記最後のシンボルを使用して前記ＵＥからの送信を受信することをせず、かつ、第２のサブフレームの最初のシンボルを使用して前記ＵＥからの送信を受信することはしない、
方法。
【請求項１１】
前記基地局は、ＬＴＥ（long term evolution）無線アクセスネットワークの基地局である、
請求項１０に記載の方法。
【請求項１２】
プログラマブル通信デバイスに請求項１又は１０の方法を実行させるためのプログラム。
【請求項１３】
複数の狭帯域のいずれかを使用して通信可能なユーザ機器（ＵＥ：user equipment）であって、
コントローラ及びトランシーバを備え、
前記コントローラは、
前記トランシーバを制御して、第１の狭帯域から第２の狭帯域へのＵＥリチューニングのための２つの連続するサブフレーム間のシンボル数を示す情報を、基地局に送信し、
物理アップリンク制御チャネル（ＰＵＣＣＨ：physical uplink control channel）フォーマット及びＵＥリチューニングのための前記シンボル数に従って、前記基地局への送信を制御するように動作可能であり、
短くされたＰＵＣＣＨフォーマットに従って、１つのシンボルがＵＥリチューニングのために使用される場合、前記ＵＥは、第１のサブフレームの最後のシンボルにおいて送信することはせず、
前記短くされたＰＵＣＣＨフォーマットに従って、２つのシンボルがＵＥリチューニングのために使用される場合、前記ＵＥは、前記第１のサブフレームの前記最後のシンボルにおいて送信することをせず、かつ、第２のサブフレームの最初のシンボルにおいて送信することはしない、
ユーザ機器。
【請求項１４】
複数の狭帯域のいずれかを使用してユーザ機器（ＵＥ：user equipment）と通信可能な基地局であって、
コントローラ及びトランシーバを備え、
前記コントローラは、
前記トランシーバを制御して、第１の狭帯域から第２の狭帯域へのＵＥリチューニングのための２つの連続するサブフレーム間のシンボル数を示すＵＥ能力情報要素を、前記ＵＥから、無線リソース制御（ＲＲＣ：radio resource control）シグナリングで受信し、
物理アップリンク制御チャネル（ＰＵＣＣＨ：physical uplink control channel）フォーマット及びＵＥリチューニングのための前記シンボル数に従って、前記トランシーバによる受信を制御するように動作可能であり、
短くされたＰＵＣＣＨフォーマットに従って、１つのシンボルがＵＥリチューニングのために使用される場合、前記基地局は、第１のサブフレームの最後のシンボルにおいて、前記ＵＥからの送信を受信することはせず、
前記短くされたＰＵＣＣＨフォーマットに従って、２つのシンボルがＵＥリチューニングのために使用される場合、前記基地局は、前記第１のサブフレームの前記最後のシンボルにおいて、前記ＵＥからの送信を受信することをせず、かつ、第２のサブフレームの最初のシンボルにおいて、前記ＵＥからの送信を受信することはしない、
基地局。
【請求項１５】
請求項１３に記載のユーザ機器と、請求項１４に記載の基地局と、を備えるシステム。
【国際調査報告】
2019523614.tif 000030
2019523614.tif 000031
2019523614.tif 000032
2019523614.tif 000033