(57)【要約】  基地局装置と通信端末装置との間の通信動作を安定して行うことができる通信システムを提供する。ＵＥは、ＭｅＮＢと直接またはＳｅＮＢを介して通信可能である。ＭｅＮＢに送信する送信データのデータ量が、予め定める閾値Ｔｈを超える場合、ＵＥは、送信データをＭｅＮＢおよびＳｅＮＢに送信するように設定され、閾値Ｔｈ以下である場合、送信データをＭｅＮＢに送信し、ＳｅＮＢに送信しないように設定される。ＳｅＮＢが、周期的に割り当てられる無線リソースを用いてＵＥと通信するように設定されると、送信データのデータ量が閾値Ｔｈ以下である場合に、送信データがＭｅＮＢおよびＳｅＮＢに送信されるように、閾値Ｔｈが変更される。例えば、閾値Ｔｈが０に設定される。
2017135159.tif 000002
【特許請求の範囲】
【請求項１】
第１の基地局装置と、第２の基地局装置と、前記第１の基地局装置および前記第２の基地局装置と無線通信可能な通信端末装置とを備える通信システムであって、
前記通信端末装置は、
前記第１の基地局装置と直接通信を行う第１の経路と、前記第２の基地局装置を介して前記第１の基地局装置と通信を行う第２の経路とによって、前記第１の基地局装置と通信可能であり、
前記第１の基地局装置に送信する送信データのデータ量が、予め定める閾値を超える場合、前記送信データを前記第１の基地局装置および前記第２の基地局装置に送信するように設定され、前記送信データのデータ量が前記閾値以下である場合、前記送信データを前記第１の基地局装置に送信し、前記第２の基地局装置に送信しないように設定され、
前記第２の基地局装置が、周期的に割り当てられる無線リソースを用いて前記通信端末装置と通信するように設定されると、前記送信データのデータ量が前記閾値以下である場合に、前記送信データが前記第１の基地局装置および前記第２の基地局装置に送信されるように、前記閾値が変更されることを特徴とする通信システム。
【請求項２】
第１の基地局装置と、第２の基地局装置と、前記第１の基地局装置および前記第２の基地局装置と無線通信可能な通信端末装置とを備える通信システムであって、
前記通信端末装置は、
前記第１の基地局装置と直接通信を行う第１の経路と、前記第２の基地局装置を介して前記第１の基地局装置と通信を行う第２の経路とによって、前記第１の基地局装置と通信可能であり、
前記第１の基地局装置に送信する送信データのデータ量が、予め定める閾値以上である場合、前記送信データを前記第１の基地局装置および前記第２の基地局装置に送信するように設定され、前記送信データのデータ量が前記閾値未満である場合、前記送信データを前記第１の基地局装置に送信し、前記第２の基地局装置に送信しないように設定され、
前記第２の基地局装置が、周期的に割り当てられる無線リソースを用いて前記通信端末装置と通信するように設定されると、前記送信データのデータ量が前記閾値未満である場合に、前記送信データが前記第１の基地局装置および前記第２の基地局装置に送信されるように、前記閾値が変更されることを特徴とする通信システム。
【請求項３】
第１の基地局装置と、第２の基地局装置と、前記第１の基地局装置および前記第２の基地局装置と無線通信可能な通信端末装置とを備える通信システムであって、
前記通信端末装置は、
前記第１の基地局装置と直接通信を行う第１の経路と、前記第２の基地局装置を介して前記第１の基地局装置と通信を行う第２の経路とによって、前記第１の基地局装置と通信可能であり、
前記第１の基地局装置に送信する送信データのデータ量が、予め定める閾値を超える場合、前記送信データを前記第１の基地局装置および前記第２の基地局装置に送信するように設定され、前記送信データのデータ量が前記閾値以下である場合、前記送信データを前記第１の基地局装置に送信し、前記第２の基地局装置に送信しないように設定され、
前記第２の基地局装置が、周期的に割り当てられる無線リソースを用いて前記通信端末装置と通信するように設定されると、前記通信端末装置は、前記送信データのデータ量が前記閾値以下である場合に、前記送信データを前記第１の基地局装置に送信するとともに、前記周期的に割り当てられる無線リソースを用いた通信の終了を表す終了信号を前記第２の基地局装置に送信するように設定されることを特徴とする通信システム。
【請求項４】
第１の基地局装置と、第２の基地局装置と、前記第１の基地局装置および前記第２の基地局装置と無線通信可能な通信端末装置とを備える通信システムであって、
前記通信端末装置は、
前記第１の基地局装置と直接通信を行う第１の経路と、前記第２の基地局装置を介して前記第１の基地局装置と通信を行う第２の経路とによって、前記第１の基地局装置と通信可能であり、
前記第１の基地局装置に送信する送信データのデータ量が、予め定める閾値以上である場合、前記送信データを前記第１の基地局装置および前記第２の基地局装置に送信するように設定され、前記送信データのデータ量が前記閾値未満である場合、前記送信データを前記第１の基地局装置に送信し、前記第２の基地局装置に送信しないように設定され、
前記第２の基地局装置が、周期的に割り当てられる無線リソースを用いて前記通信端末装置と通信するように設定されると、前記通信端末装置は、前記送信データのデータ量が前記閾値未満である場合に、前記送信データを前記第１の基地局装置に送信するとともに、前記周期的に割り当てられる無線リソースを用いた通信の終了を表す終了信号を前記第２の基地局装置に送信するように設定されることを特徴とする通信システム。
【請求項５】
前記通信端末装置は、前記周期的に割り当てられる無線リソースのリリースを停止することを示すリリース停止情報を受信すると、前記周期的に割り当てられる無線リソースのリリースを停止することを特徴とする請求項３または４に記載の通信システム。
【請求項６】
前記通信端末装置は、前記周期的に割り当てられる無線リソースのリリースを再開することを示すリリース再開情報を受信すると、前記周期的に割り当てられる無線リソースのリリースを再開することを特徴とする請求項５に記載の通信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、移動端末装置などの通信端末装置と基地局装置との間で無線通信を行う通信システムに関する。
【背景技術】
【０００２】
移動体通信システムの規格化団体である３ＧＰＰ（3rd Generation Partnership Project）において、無線区間についてはロングタームエボリューション（Long Term Evolution：ＬＴＥ）と称し、コアネットワークおよび無線アクセスネットワーク（以下、まとめて、ネットワークとも称する）を含めたシステム全体構成については、システムアーキテクチャエボリューション（System Architecture Evolution：ＳＡＥ）と称される通信方式が検討されている（例えば、非特許文献１〜１０）。この通信方式は３．９Ｇ（3.9 Generation）システムとも呼ばれる。【０００３】
ＬＴＥのアクセス方式としては、下り方向はＯＦＤＭ（Orthogonal Frequency Division Multiplexing）、上り方向はＳＣ−ＦＤＭＡ（Single Carrier Frequency Division Multiple Access）が用いられる。また、ＬＴＥは、Ｗ−ＣＤＭＡ（Wideband Code Division Multiple Access）とは異なり、回線交換を含まず、パケット通信方式のみになる。【０００４】
非特許文献１（５章）に記載される、３ＧＰＰでの、ＬＴＥシステムにおけるフレーム構成に関する決定事項について、図１を用いて説明する。図１は、ＬＴＥ方式の通信システムで使用される無線フレームの構成を示す説明図である。図１において、１つの無線フレーム（Radio frame）は１０ｍｓである。無線フレームは１０個の等しい大きさのサブフレーム（Subframe）に分割される。サブフレームは、２個の等しい大きさのスロット（slot）に分割される。無線フレーム毎に１番目および６番目のサブフレームに下り同期信号（Downlink Synchronization Signal）が含まれる。同期信号には、第一同期信号（Primary Synchronization Signal：Ｐ−ＳＳ）と、第二同期信号（Secondary Synchronization Signal：Ｓ−ＳＳ）とがある。【０００５】
３ＧＰＰでの、ＬＴＥシステムにおけるチャネル構成に関する決定事項が、非特許文献１（５章）に記載されている。ＣＳＧ（Closed Subscriber Group）セルにおいてもｎｏｎ−ＣＳＧセルと同じチャネル構成が用いられると想定されている。【０００６】
物理報知チャネル（Physical Broadcast Channel：ＰＢＣＨ）は、基地局装置（以下、単に「基地局」という場合がある）から移動端末装置（以下、単に「移動端末」という場合がある）などの通信端末装置（以下、単に「通信端末」という場合がある）への下り送信用のチャネルである。ＢＣＨトランスポートブロック（transport block）は、４０ｍｓ間隔中の４個のサブフレームにマッピングされる。４０ｍｓタイミングの明白なシグナリングはない。【０００７】
物理制御フォーマットインジケータチャネル（Physical Control Format Indicator Channel：ＰＣＦＩＣＨ）は、基地局から通信端末への下り送信用のチャネルである。ＰＣＦＩＣＨは、ＰＤＣＣＨｓのために用いるＯＦＤＭ（Orthogonal Frequency Division Multiplexing）シンボルの数を、基地局から通信端末へ通知する。ＰＣＦＩＣＨは、サブフレーム毎に送信される。【０００８】
物理下り制御チャネル（Physical Downlink Control Channel：ＰＤＣＣＨ）は、基地局から通信端末への下り送信用のチャネルである。ＰＤＣＣＨは、後述のトランスポートチャネルの１つである下り共有チャネル（Downlink Shared Channel：ＤＬ−ＳＣＨ）のリソース割り当て（allocation）情報、後述のトランスポートチャネルの１つであるページングチャネル（Paging Channel：ＰＣＨ）のリソース割り当て（allocation）情報、ＤＬ−ＳＣＨに関するＨＡＲＱ（Hybrid Automatic Repeat reQuest）情報を通知する。ＰＤＣＣＨは、上りスケジューリンググラント（Uplink Scheduling Grant）を運ぶ。ＰＤＣＣＨは、上り送信に対する応答信号であるＡｃｋ（Acknowledgement）／Ｎａｃｋ（Negative Acknowledgement）を運ぶ。ＰＤＣＣＨは、Ｌ１／Ｌ２制御信号とも呼ばれる。【０００９】
物理下り共有チャネル（Physical Downlink Shared Channel：ＰＤＳＣＨ）は、基地局から通信端末への下り送信用のチャネルである。ＰＤＳＣＨには、トランスポートチャネルである下り共有チャネル（ＤＬ−ＳＣＨ）、およびトランスポートチャネルであるＰＣＨがマッピングされている。【００１０】
物理マルチキャストチャネル（Physical Multicast Channel：ＰＭＣＨ）は、基地局から通信端末への下り送信用のチャネルである。ＰＭＣＨには、トランスポートチャネルであるマルチキャストチャネル（Multicast Channel：ＭＣＨ）がマッピングされている。【００１１】
物理上り制御チャネル（Physical Uplink Control Channel：ＰＵＣＣＨ）は、通信端末から基地局への上り送信用のチャネルである。ＰＵＣＣＨは、下り送信に対する応答信号（response signal）であるＡｃｋ／Ｎａｃｋを運ぶ。ＰＵＣＣＨは、ＣＱＩ（Channel Quality Indicator）レポートを運ぶ。ＣＱＩとは、受信したデータの品質、もしくは通信路品質を示す品質情報である。またＰＵＣＣＨは、スケジューリングリクエスト（Scheduling Request：ＳＲ）を運ぶ。【００１２】
物理上り共有チャネル（Physical Uplink Shared Channel：ＰＵＳＣＨ）は、通信端末から基地局への上り送信用のチャネルである。ＰＵＳＣＨには、トランスポートチャネルの１つである上り共有チャネル（Uplink Shared Channel：ＵＬ−ＳＣＨ）がマッピングされている。【００１３】
物理ＨＡＲＱインジケータチャネル（Physical Hybrid ARQ Indicator Channel：ＰＨＩＣＨ）は、基地局から通信端末への下り送信用のチャネルである。ＰＨＩＣＨは、上り送信に対する応答信号であるＡｃｋ／Ｎａｃｋを運ぶ。物理ランダムアクセスチャネル（Physical Random Access Channel：ＰＲＡＣＨ）は、通信端末から基地局への上り送信用のチャネルである。ＰＲＡＣＨは、ランダムアクセスプリアンブル（random access preamble）を運ぶ。【００１４】
下り参照信号（リファレンスシグナル（Reference Signal）：ＲＳ）は、ＬＴＥ方式の通信システムとして既知のシンボルである。以下の５種類の下りリファレンスシグナルが定義されている。セル固有参照信号（Cell-specific Reference Signal：ＣＲＳ）、ＭＢＳＦＮ参照信号（MBSFN Reference Signal）、ＵＥ固有参照信号（UE-specific Reference Signal）であるデータ復調用参照信号（Demodulation Reference Signal：ＤＭ−ＲＳ）、位置決定参照信号（Positioning Reference Signal：ＰＲＳ）、チャネル状態情報参照信号（Channel State Information Reference Signal：ＣＳＩ−ＲＳ）。通信端末の物理レイヤの測定として、リファレンスシグナルの受信電力（Reference Signal Received Power：ＲＳＲＰ）測定がある。【００１５】
非特許文献１（５章）に記載されるトランスポートチャネル（Transport channel）について、説明する。下りトランスポートチャネルのうち、報知チャネル（Broadcast Channel：ＢＣＨ）は、その基地局（セル）のカバレッジ全体に報知される。ＢＣＨは、物理報知チャネル（ＰＢＣＨ）にマッピングされる。【００１６】
下り共有チャネル（Downlink Shared Channel：ＤＬ−ＳＣＨ）には、ＨＡＲＱ（Hybrid ARQ）による再送制御が適用される。ＤＬ−ＳＣＨは、基地局（セル）のカバレッジ全体への報知が可能である。ＤＬ−ＳＣＨは、ダイナミックあるいは準静的（Semi-static）なリソース割り当てをサポートする。準静的なリソース割り当ては、パーシステントスケジューリング（Persistent Scheduling）ともいわれる。ＤＬ−ＳＣＨは、通信端末の低消費電力化のために通信端末の間欠受信（Discontinuous reception：ＤＲＸ）をサポートする。ＤＬ−ＳＣＨは、物理下り共有チャネル（ＰＤＳＣＨ）へマッピングされる。【００１７】
ページングチャネル（Paging Channel：ＰＣＨ）は、通信端末の低消費電力を可能とするために通信端末のＤＲＸをサポートする。ＰＣＨは、基地局（セル）のカバレッジ全体への報知が要求される。ＰＣＨは、動的にトラフィックに利用できる物理下り共有チャネル（ＰＤＳＣＨ）のような物理リソースへマッピングされる。【００１８】
マルチキャストチャネル（Multicast Channel：ＭＣＨ）は、基地局（セル）のカバレッジ全体への報知に使用される。ＭＣＨは、マルチセル送信におけるＭＢＭＳ（Multimedia Broadcast Multicast Service）サービス（ＭＴＣＨとＭＣＣＨ）のＳＦＮ合成をサポートする。ＭＣＨは、準静的なリソース割り当てをサポートする。ＭＣＨは、ＰＭＣＨへマッピングされる。【００１９】
上りトランスポートチャネルのうち、上り共有チャネル（Uplink Shared Channel：ＵＬ−ＳＣＨ）には、ＨＡＲＱ（Hybrid ARQ）による再送制御が適用される。ＵＬ−ＳＣＨは、ダイナミックあるいは準静的（Semi-static）なリソース割り当てをサポートする。ＵＬ−ＳＣＨは、物理上り共有チャネル（ＰＵＳＣＨ）へマッピングされる。【００２０】
ランダムアクセスチャネル（Random Access Channel：ＲＡＣＨ）は、制御情報に限られている。ＲＡＣＨは、衝突のリスクがある。ＲＡＣＨは、物理ランダムアクセスチャネル（ＰＲＡＣＨ）へマッピングされる。【００２１】
ＨＡＲＱについて説明する。ＨＡＲＱとは、自動再送要求（Automatic Repeat reQuest：ＡＲＱ）と誤り訂正（Forward Error Correction）との組合せによって、伝送路の通信品質を向上させる技術である。ＨＡＲＱには、通信品質が変化する伝送路に対しても、再送によって誤り訂正が有効に機能するという利点がある。特に、再送にあたって初送の受信結果と再送の受信結果との合成をすることで、更なる品質向上を得ることも可能である。【００２２】
再送の方法の一例を説明する。受信側にて、受信データが正しくデコードできなかった場合、換言すればＣＲＣ（Cyclic Redundancy Check）エラーが発生した場合（ＣＲＣ＝ＮＧ）、受信側から送信側へ「Ｎａｃｋ」を送信する。「Ｎａｃｋ」を受信した送信側は、データを再送する。受信側にて、受信データが正しくデコードできた場合、換言すればＣＲＣエラーが発生しない場合（ＣＲＣ＝ＯＫ）、受信側から送信側へ「Ａｃｋ」を送信する。「Ａｃｋ」を受信した送信側は次のデータを送信する。【００２３】
非特許文献１（６章）に記載される論理チャネル（ロジカルチャネル：Logical channel）について、説明する。報知制御チャネル（Broadcast Control Channel：ＢＣＣＨ）は、報知システム制御情報のための下りチャネルである。論理チャネルであるＢＣＣＨは、トランスポートチャネルである報知チャネル（ＢＣＨ）、あるいは下り共有チャネル（ＤＬ−ＳＣＨ）へマッピングされる。【００２４】
ページング制御チャネル（Paging Control Channel：ＰＣＣＨ）は、ページング情報（Paging Information）およびシステム情報（System Information）の変更を送信するための下りチャネルである。ＰＣＣＨは、通信端末のセルロケーションをネットワークが知らない場合に用いられる。論理チャネルであるＰＣＣＨは、トランスポートチャネルであるページングチャネル（ＰＣＨ）へマッピングされる。【００２５】
共有制御チャネル（Common Control Channel：ＣＣＣＨ）は、通信端末と基地局との間の送信制御情報のためのチャネルである。ＣＣＣＨは、通信端末がネットワークとの間でＲＲＣ接続（connection）を有していない場合に用いられる。下り方向では、ＣＣＣＨは、トランスポートチャネルである下り共有チャネル（ＤＬ−ＳＣＨ）へマッピングされる。上り方向では、ＣＣＣＨは、トランスポートチャネルである上り共有チャネル（ＵＬ−ＳＣＨ）へマッピングされる。【００２６】
マルチキャスト制御チャネル（Multicast Control Channel：ＭＣＣＨ）は、１対多の送信のための下りチャネルである。ＭＣＣＨは、ネットワークから通信端末への１つあるいはいくつかのＭＴＣＨ用のＭＢＭＳ制御情報の送信のために用いられる。ＭＣＣＨは、ＭＢＭＳ受信中の通信端末のみに用いられる。ＭＣＣＨは、トランスポートチャネルであるマルチキャストチャネル（ＭＣＨ）へマッピングされる。【００２７】
個別制御チャネル（Dedicated Control Channel：ＤＣＣＨ）は、１対１にて、通信端末とネットワークとの間の個別制御情報を送信するチャネルである。ＤＣＣＨは、通信端末がＲＲＣ接続（connection）である場合に用いられる。ＤＣＣＨは、上りでは上り共有チャネル（ＵＬ−ＳＣＨ）へマッピングされ、下りでは下り共有チャネル（ＤＬ−ＳＣＨ）にマッピングされる。【００２８】
個別トラフィックチャネル（Dedicated Traffic Channel：ＤＴＣＨ）は、ユーザ情報の送信のための個別通信端末への１対１通信のチャネルである。ＤＴＣＨは、上りおよび下りともに存在する。ＤＴＣＨは、上りでは上り共有チャネル（ＵＬ−ＳＣＨ）へマッピングされ、下りでは下り共有チャネル（ＤＬ−ＳＣＨ）へマッピングされる。【００２９】
マルチキャストトラフィックチャネル（Multicast Traffic channel：ＭＴＣＨ）は、ネットワークから通信端末へのトラフィックデータ送信のための下りチャネルである。ＭＴＣＨは、ＭＢＭＳ受信中の通信端末のみに用いられるチャネルである。ＭＴＣＨは、マルチキャストチャネル（ＭＣＨ）へマッピングされる。【００３０】
ＣＧＩとは、セルグローバル識別子（Cell Global Identifier）のことである。ＥＣＧＩとは、Ｅ−ＵＴＲＡＮセルグローバル識別子（E-UTRAN Cell Global Identifier）のことである。ＬＴＥ、後述のＬＴＥ−Ａ（Long Term Evolution Advanced）およびＵＭＴＳ（Universal Mobile Telecommunication System）において、ＣＳＧ（Closed Subscriber Group）セルが導入される。【００３１】
ＣＳＧ（Closed Subscriber Group）セルとは、利用可能な加入者をオペレータが特定しているセル（以下「特定加入者用セル」という場合がある）である。特定された加入者は、ＰＬＭＮ（Public Land Mobile Network）の１つ以上のセルにアクセスすることが許可される。特定された加入者がアクセスを許可されている１つ以上のセルを「ＣＳＧセル（ＣＳＧ  ｃｅｌｌ（ｓ））」と呼ぶ。ただし、ＰＬＭＮにはアクセス制限がある。【００３２】
ＣＳＧセルは、固有のＣＳＧアイデンティティ（CSG identity：ＣＳＧ  ＩＤ；ＣＳＧ−ＩＤ）を報知し、ＣＳＧインジケーション（CSG Indication）にて「ＴＲＵＥ」を報知するＰＬＭＮの一部である。予め利用登録し、許可された加入者グループのメンバーは、アクセス許可情報であるところのＣＳＧ−ＩＤを用いてＣＳＧセルにアクセスする。【００３３】
ＣＳＧ−ＩＤは、ＣＳＧセルまたはセルによって報知される。ＬＴＥ方式の通信システムにＣＳＧ−ＩＤは複数存在する。そして、ＣＳＧ−ＩＤは、ＣＳＧ関連のメンバーのアクセスを容易にするために、通信端末（ＵＥ）によって使用される。【００３４】
通信端末の位置追跡は、１つ以上のセルからなる区域を単位に行われる。位置追跡は、待受け状態であっても通信端末の位置を追跡し、通信端末を呼び出す、換言すれば通信端末が着呼することを可能にするために行われる。この通信端末の位置追跡のための区域をトラッキングエリアと呼ぶ。【００３５】
３ＧＰＰにおいて、Ｈｏｍｅ−ＮｏｄｅＢ（Ｈｏｍｅ−ＮＢ；ＨＮＢ）、Ｈｏｍｅ−ｅＮｏｄｅＢ（Ｈｏｍｅ−ｅＮＢ；ＨｅＮＢ）と称される基地局が検討されている。ＵＴＲＡＮにおけるＨＮＢ、およびＥ−ＵＴＲＡＮにおけるＨｅＮＢは、例えば家庭、法人、商業用のアクセスサービス向けの基地局である。非特許文献２には、ＨｅＮＢおよびＨＮＢへのアクセスの３つの異なるモードが開示されている。具体的には、オープンアクセスモード（Open access mode）と、クローズドアクセスモード（Closed access mode）と、ハイブリッドアクセスモード（Hybrid access mode）とが開示されている。【００３６】
また３ＧＰＰでは、リリース１０として、ロングタームエボリューションアドヴァンスド（Long Term Evolution Advanced：ＬＴＥ−Ａ）の規格策定が進められている（非特許文献３、非特許文献４参照）。ＬＴＥ−Ａは、ＬＴＥの無線区間通信方式を基本とし、それにいくつかの新技術を加えて構成される。【００３７】
ＬＴＥ−Ａシステムでは、１００ＭＨｚまでのより広い周波数帯域幅（transmission bandwidths）をサポートするために、二つ以上のコンポーネントキャリア（Component Carrier：ＣＣ）を集約する（「アグリゲーション（aggregation）する」とも称する）、キャリアアグリゲーション（Carrier Aggregation：ＣＡ）が検討されている。ＣＡについては、非特許文献１に記載されている。【００３８】
ＣＡが構成される場合、ＵＥはネットワーク（Network：ＮＷ）と唯一つのＲＲＣ接続（RRC connection）を有する。ＲＲＣ接続において、一つのサービングセルがＮＡＳモビリティ情報とセキュリティ入力を与える。このセルをプライマリセル（Primary Cell：ＰＣｅｌｌ）と呼ぶ。下りリンクで、ＰＣｅｌｌに対応するキャリアは、下りプライマリコンポーネントキャリア（Downlink Primary Component Carrier：ＤＬ  ＰＣＣ）である。上りリンクで、ＰＣｅｌｌに対応するキャリアは、上りプライマリコンポーネントキャリア（Uplink Primary Component Carrier：ＵＬ  ＰＣＣ）である。【００３９】
ＵＥの能力（ケーパビリティ（capability））に応じて、セカンダリセル（Secondary Cell：ＳＣｅｌｌ）が、ＰＣｅｌｌとサービングセルとの組を形成するために構成される。下りリンクで、ＳＣｅｌｌに対応するキャリアは、下りセカンダリコンポーネントキャリア（Downlink Secondary Component Carrier：ＤＬ  ＳＣＣ）である。上りリンクで、ＳＣｅｌｌに対応するキャリアは、上りセカンダリコンポーネントキャリア（Uplink Secondary Component Carrier：ＵＬ  ＳＣＣ）である。【００４０】
一つのＵＥに対して、一つのＰＣｅｌｌと、一つ以上のＳＣｅｌｌからなるサービングセルとの組が構成される。【００４１】
また、ＬＴＥ−Ａでの新技術としては、より広い帯域をサポートする技術（Wider bandwidth extension）、および多地点協調送受信（Coordinated Multiple Point transmission and reception：ＣｏＭＰ）技術などがある。３ＧＰＰでＬＴＥ−Ａのために検討されているＣｏＭＰについては、非特許文献１に記載されている。【００４２】
モバイルネットワークのトラフィック量は、増加傾向にあり、通信速度も高速化が進んでいる。ＬＴＥおよびＬＴＥ−Ａが本格的に運用を開始されると、更に通信速度が高速化されることが見込まれる。【００４３】
また、３ＧＰＰにおいて、将来の膨大なトラフィックに対応するために、スモールセルを構成するスモールｅＮＢ（以下「小規模基地局装置」という場合がある）を用いることが検討されている。例えば、多数のスモールｅＮＢを設置して、多数のスモールセルを構成することによって、周波数利用効率を高めて、通信容量の増大を図る技術などが検討されている。具体的には、ＵＥが２つのｅＮＢと接続して通信を行うデュアルコネクティビティ（Dual Connectivity；略称：ＤＣ）などがある。ＤＣについては、非特許文献１に記載されている。【００４４】
デュアルコネクティビティ（ＤＣ）を行うｅＮＢのうち、一方を「マスターｅＮＢ（略称：ＭｅＮＢ）」といい、他方を「セカンダリｅＮＢ（略称：ＳｅＮＢ）」という場合がある。【００４５】
さらに、高度化する移動体通信に対して、２０２０年以降にサービスを開始することを目標とした第５世代（以下「５Ｇ」という場合がある）無線アクセスシステムが検討されている。例えば、欧州では、ＭＥＴＩＳという団体で５Ｇの要求事項がまとめられている（非特許文献５参照）。【００４６】
５Ｇ無線アクセスシステムでは、ＬＴＥシステムに対して、システム容量は１０００倍、データの伝送速度は１００倍、データの処理遅延は１０分の１（１／１０）、通信端末の同時接続数は１００倍として、更なる低消費電力化、および装置の低コスト化を実現することが要件として挙げられている。【００４７】
このような要求を満たすために、周波数を広帯域で使用してデータの伝送容量を増やすこと、ならびに周波数利用効率を上げてデータの伝送速度を上げることが検討されている。これらを実現するために、空間多重を可能とする、多素子アンテナを用いたＭＩＭＯ（Multiple Input Multiple Output）およびビームフォーミングなどの技術が検討されている。
【先行技術文献】
【非特許文献】
【００４８】
【非特許文献１】３ＧＰＰ  ＴＳ３６．３００  Ｖ１３．０．０
【非特許文献２】３ＧＰＰ  Ｓ１−０８３４６１
【非特許文献３】３ＧＰＰ  ＴＲ  ３６．８１４  Ｖ９．０．０
【非特許文献４】３ＧＰＰ  ＴＲ  ３６．９１２  Ｖ１０．０．０
【非特許文献５】”Scenarios, requirements and KPIs for 5G mobile and wireless system”、［online］、平成２５（２０１３）年４月３０日、ＩＣＴ−３１７６６９−ＭＥＴＩＳ／Ｄ１．１、［平成２８年１月２５日検索］、インターネット<https://www.metis2020.com/documents/deliverables/>
【非特許文献６】３ＧＰＰ  Ｒ２−１４４６６２
【非特許文献７】３ＧＰＰ  Ｒ２−１５２３５９
【非特許文献８】３ＧＰＰ  ＴＳ  ３６．１４１  Ｖ１３．０．０
【非特許文献９】３ＧＰＰ  ＴＳ３６．３２１  Ｖ１２．８．０
【非特許文献１０】３ＧＰＰ  Ｒ２−１５６６６８
【発明の概要】
【発明が解決しようとする課題】
【００４９】
ＤＣでは、スプリットベアラがサポートされている。スプリットベアラでは、ＭｅＮＢだけでなく、ＳｅＮＢに対しても、ＳＰＳ（Semi-Persistent Scheduling）がサポートされている（非特許文献６参照）。【００５０】
３ＧＰＰにおいて、上りスプリットベアラを実行しているときのバッファ状態報告（Buffer Status Report；略称：ＢＳＲ）の送信方法について、二重報告および閾値（Double Reporting And Threshold；略称：ＤＲＡＴ）による方法とすることが提案されている（非特許文献７参照）。上りスプリットベアラでＤＲＡＴが実行される場合、ＵＥは、上りデータのデータ量がＤＲＡＴの閾値以下のときには、予め定める１つのｅＮＢに対してデータの送信を行い、もう１つのｅＮＢに対しては、データの送信を行わない。【００５１】
しかし、上りデータのデータ量がＤＲＡＴの閾値以下になったときのＳＰＳの動作、例えばＵＥによるパディング送信の可否などについては規定が無く、また、何ら議論もされていない。【００５２】
ＳＰＳの動作の規定がないと、パディング送信によるインプリシットリリース機能が正常に働かない。これによって、ｅＮＢとＵＥとの間で不安定な動作が生じる。ひいては、誤動作が引き起こされる可能性が生じてしまう。【００５３】
本発明の目的は、基地局装置と通信端末装置との間の通信動作を安定して行うことができる通信システムを提供することである。
【課題を解決するための手段】
【００５４】
本発明の通信システムは、第１の基地局装置と、第２の基地局装置と、前記第１の基地局装置および前記第２の基地局装置と無線通信可能な通信端末装置とを備える通信システムであって、前記通信端末装置は、前記第１の基地局装置と直接通信を行う第１の経路と、前記第２の基地局装置を介して前記第１の基地局装置と通信を行う第２の経路とによって、前記第１の基地局装置と通信可能であり、前記第１の基地局装置に送信する送信データのデータ量が、予め定める閾値を超える場合、前記送信データを前記第１の基地局装置および前記第２の基地局装置に送信するように設定され、前記送信データのデータ量が前記閾値以下である場合、前記送信データを前記第１の基地局装置に送信し、前記第２の基地局装置に送信しないように設定され、前記第２の基地局装置が、周期的に割り当てられる無線リソースを用いて前記通信端末装置と通信するように設定されると、前記送信データのデータ量が前記閾値以下である場合に、前記送信データが前記第１の基地局装置および前記第２の基地局装置に送信されるように、前記閾値が変更されることを特徴とする。【００５５】
また本発明の通信システムは、第１の基地局装置と、第２の基地局装置と、前記第１の基地局装置および前記第２の基地局装置と無線通信可能な通信端末装置とを備える通信システムであって、前記通信端末装置は、前記第１の基地局装置と直接通信を行う第１の経路と、前記第２の基地局装置を介して前記第１の基地局装置と通信を行う第２の経路とによって、前記第１の基地局装置と通信可能であり、前記第１の基地局装置に送信する送信データのデータ量が、予め定める閾値以上である場合、前記送信データを前記第１の基地局装置および前記第２の基地局装置に送信するように設定され、前記送信データのデータ量が前記閾値未満である場合、前記送信データを前記第１の基地局装置に送信し、前記第２の基地局装置に送信しないように設定され、前記第２の基地局装置が、周期的に割り当てられる無線リソースを用いて前記通信端末装置と通信するように設定されると、前記送信データのデータ量が前記閾値未満である場合に、前記送信データが前記第１の基地局装置および前記第２の基地局装置に送信されるように、前記閾値が変更されることを特徴とする。【００５６】
また本発明の通信システムは、第１の基地局装置と、第２の基地局装置と、前記第１の基地局装置および前記第２の基地局装置と無線通信可能な通信端末装置とを備える通信システムであって、前記通信端末装置は、前記第１の基地局装置と直接通信を行う第１の経路と、前記第２の基地局装置を介して前記第１の基地局装置と通信を行う第２の経路とによって、前記第１の基地局装置と通信可能であり、前記第１の基地局装置に送信する送信データのデータ量が、予め定める閾値を超える場合、前記送信データを前記第１の基地局装置および前記第２の基地局装置に送信するように設定され、前記送信データのデータ量が前記閾値以下である場合、前記送信データを前記第１の基地局装置に送信し、前記第２の基地局装置に送信しないように設定され、前記第２の基地局装置が、周期的に割り当てられる無線リソースを用いて前記通信端末装置と通信するように設定されると、前記通信端末装置は、前記送信データのデータ量が前記閾値以下である場合に、前記送信データを前記第１の基地局装置に送信するとともに、前記周期的に割り当てられる無線リソースを用いた通信の終了を表す終了信号を前記第２の基地局装置に送信するように設定されることを特徴とする。【００５７】
また本発明の通信システムは、第１の基地局装置と、第２の基地局装置と、前記第１の基地局装置および前記第２の基地局装置と無線通信可能な通信端末装置とを備える通信システムであって、前記通信端末装置は、前記第１の基地局装置と直接通信を行う第１の経路と、前記第２の基地局装置を介して前記第１の基地局装置と通信を行う第２の経路とによって、前記第１の基地局装置と通信可能であり、前記第１の基地局装置に送信する送信データのデータ量が、予め定める閾値以上である場合、前記送信データを前記第１の基地局装置および前記第２の基地局装置に送信するように設定され、前記送信データのデータ量が前記閾値未満である場合、前記送信データを前記第１の基地局装置に送信し、前記第２の基地局装置に送信しないように設定され、前記第２の基地局装置が、周期的に割り当てられる無線リソースを用いて前記通信端末装置と通信するように設定されると、前記通信端末装置は、前記送信データのデータ量が前記閾値未満である場合に、前記送信データを前記第１の基地局装置に送信するとともに、前記周期的に割り当てられる無線リソースを用いた通信の終了を表す終了信号を前記第２の基地局装置に送信するように設定されることを特徴とする。
【発明の効果】
【００５８】
本発明の通信システムによれば、第２の基地局装置が、周期的に割り当てられる無線リソースを用いて通信端末装置と通信するように設定されると、送信データのデータ量が閾値以下である場合に、送信データが第１の基地局装置および第２の基地局装置に送信されるように、閾値が変更される。これによって、第２の基地局装置においても、周期的に割り当てられる無線リソースを用いた通信端末装置との通信を実行することができる。したがって、第１および第２の基地局装置と通信端末装置との間の通信動作を安定して行うことができる通信システムを提供することができる。【００５９】
また本発明の通信システムによれば、第２の基地局装置が、周期的に割り当てられる無線リソースを用いて通信端末装置と通信するように設定されると、送信データのデータ量が閾値未満である場合に、送信データが第１の基地局装置および第２の基地局装置に送信されるように、閾値が変更される。これによって、第２の基地局装置においても、周期的に割り当てられる無線リソースを用いた通信端末装置との通信を実行することができる。したがって、第１および第２の基地局装置と通信端末装置との間の通信動作を安定して行うことができる通信システムを提供することができる。【００６０】
また本発明の通信システムによれば、第２の基地局装置が、周期的に割り当てられる無線リソースを用いて通信端末装置と通信するように設定されると、通信端末装置は、送信データのデータ量が閾値以下である場合に、送信データを第１の基地局装置に送信するとともに、周期的に割り当てられる無線リソースを用いた通信の終了を表す終了信号を第２の基地局装置に送信するように設定される。これによって、第２の基地局装置では、周期的に割り当てられる無線リソースを用いた通信端末装置との通信を終了することができる。したがって、第１および第２の基地局装置と通信端末装置との間の通信動作を安定して行うことができる通信システムを提供することができる。【００６１】
また本発明の通信システムによれば、第２の基地局装置が、周期的に割り当てられる無線リソースを用いて通信端末装置と通信するように設定されると、通信端末装置は、送信データのデータ量が閾値未満である場合に、送信データを第１の基地局装置に送信するとともに、周期的に割り当てられる無線リソースを用いた通信の終了を表す終了信号を第２の基地局装置に送信するように設定される。これによって、第２の基地局装置では、周期的に割り当てられる無線リソースを用いた通信端末装置との通信を終了することができる。したがって、第１および第２の基地局装置と通信端末装置との間の通信動作を安定して行うことができる通信システムを提供することができる。【００６２】
本発明の目的、特徴、局面、および利点は、以下の詳細な説明と添付図面とによって、より明白となる。
【図面の簡単な説明】
【００６３】
【図１】ＬＴＥ方式の通信システムで使用される無線フレームの構成を示す説明図である。
【図２】３ＧＰＰにおいて議論されているＬＴＥ方式の通信システム２００の全体的な構成を示すブロック図である。
【図３】本発明に係る通信端末である図２に示す移動端末２０２の構成を示すブロック図である。
【図４】本発明に係る基地局である図２に示す基地局２０３の構成を示すブロック図である。
【図５】本発明に係るＭＭＥの構成を示すブロック図である。
【図６】ＬＴＥ方式の通信システムにおいて通信端末（ＵＥ）が行うセルサーチから待ち受け動作までの概略を示すフローチャートである。
【図７】マクロｅＮＢとスモールｅＮＢとが混在する場合のセルの構成の概念を示す図である。
【図８】上りリンクのＳＰＳの動作例を説明する図である。
【図９】ＤＲＡＴによる送信方法について説明するための図である。
【図１０】ＤＲＡＴによる送信方法について説明するための図である。
【図１１】ＵＬスプリットベアラが設定された場合に、ＳＰＳが設定された場合の問題点を説明する図である。
【図１２】ＳＰＳが設定された場合に、ＤＲＡＴの閾値に０を設定した場合を説明する図である。
【図１３】２ｎｄ−ｅＮＢに対してＳＰＳが設定された場合にインプリシットリリースをサポートする方法を説明する図である。
【図１４】ＤＲＡＴの閾値よりも小さいデータ量の上り送信データが発生する場合を説明する図である。
【図１５】上りＳＰＳの設定を無効にしないようにする方法を説明する図である。
【図１６】上りＳＰＳの設定を無効にすることを示す情報を用いる方法を説明する図である。
【図１７】上り送信データが無い場合のパディング送信と、上り送信データが有る場合のパディング送信とを異ならせる方法を説明する図である。
【図１８】上り送信データが無い場合のパディング送信と、上り送信データが有る場合のパディング送信とを異ならせる方法を説明する図である。
【図１９】上り送信データが無い場合のパディング送信と、上り送信データが有る場合のパディング送信とを異ならせる方法を説明する図である。
【図２０】上り送信データが無い場合のパディング送信と、上り送信データが有る場合のパディング送信とを異ならせる方法を説明する図である。
【図２１】１ｓｔ−ｅＮＢに対して、２ｎｄ−ｅＮＢに対して行ったＳＰＳの設定と同じＳＰＳの設定を行う方法について説明する図である。
【図２２】インプリシットリリースが行われない場合にパディング送信をしないとする方法を説明する図である。
【図２３】パディング送信をしない場合のＨＡＲＱの方法について説明する図である。
【図２４】パディング送信を間引いた場合のインプリシットリリース方法を説明する図である。
【図２５】パディング送信を間引いた場合のインプリシットリリース方法の他の例を示す図である。
【図２６】多素子アンテナを用いたビームフォーミングを説明する図である。
【図２７】実施の形態１２におけるビーム切替処理の時間短縮方法に関するシーケンスの一例を示す図である。
【図２８】実施の形態１３におけるビーム切替処理の時間短縮方法に関するシーケンスの一例を示す図である。
【図２９】実施の形態１３の変形例１におけるビーム切替処理の時間短縮方法に関するシーケンスの一例を示す図である。
【図３０】実施の形態１３の変形例１におけるビーム切替処理の時間短縮方法に関するシーケンスの一例を示す図である。
【図３１】実施の形態１３の変形例２におけるＨＡＲＱ処理中のデータの初送からターゲットビームで行う方法に関するシーケンスの一例を示す図である。
【図３２】実施の形態１３の変形例２におけるＨＡＲＱ処理中のデータの初送からターゲットビームで行う方法に関するシーケンスの他の例を示す図である。
【図３３】実施の形態１３の変形例２におけるＨＡＲＱ処理中のデータの再送からターゲットビームで行う方法に関するシーケンスの一例を示す図である。
【図３４】実施の形態１３の変形例２におけるＨＡＲＱ処理中のデータの送達成功（Ａｃｋ）／送達失敗（Ｎａｃｋ）からターゲットビームで行う方法に関するシーケンスの一例を示す図である。
【発明を実施するための形態】
【００６４】
実施の形態１．
図２は、３ＧＰＰにおいて議論されているＬＴＥ方式の通信システム２００の全体的な構成を示すブロック図である。図２について説明する。無線アクセスネットワークは、Ｅ−ＵＴＲＡＮ（Evolved Universal Terrestrial Radio Access Network）２０１と称される。通信端末装置である移動端末装置（以下「移動端末（User Equipment：ＵＥ）」という）２０２は、基地局装置（以下「基地局（E-UTRAN NodeB：ｅＮＢ）」という）２０３と無線通信可能であり、無線通信で信号の送受信を行う。
【００６５】
ここで、「通信端末装置」とは、移動可能な携帯電話端末装置などの移動端末装置だけでなく、センサなどの移動しないデバイスも含んでいる。以下の説明では、「通信端末装置」を、単に「通信端末」という場合がある。
【００６６】
移動端末２０２に対する制御プロトコル、例えばＲＲＣ（Radio Resource Control）と、ユーザプレイン、例えばＰＤＣＰ（Packet Data Convergence Protocol）、ＲＬＣ（Radio Link Control）、ＭＡＣ（Medium Access Control）、ＰＨＹ（Physical layer）とが基地局２０３で終端するならば、Ｅ−ＵＴＲＡＮは１つあるいは複数の基地局２０３によって構成される。
【００６７】
移動端末２０２と基地局２０３との間の制御プロトコルＲＲＣ（Radio Resource Control）は、報知（Broadcast）、ページング（paging）、ＲＲＣ接続マネージメント（RRC connection management）などを行う。ＲＲＣにおける基地局２０３と移動端末２０２との状態として、ＲＲＣ＿ＩＤＬＥと、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤとがある。
【００６８】
ＲＲＣ＿ＩＤＬＥでは、ＰＬＭＮ（Public Land Mobile Network）選択、システム情報（System Information：ＳＩ）の報知、ページング（paging）、セル再選択（cell re-selection）、モビリティなどが行われる。ＲＲＣ＿ＣＯＮＮＥＣＴＥＤでは、移動端末はＲＲＣ接続（connection）を有し、ネットワークとのデータの送受信を行うことができる。またＲＲＣ＿ＣＯＮＮＥＣＴＥＤでは、ハンドオーバ（Handover：ＨＯ）、隣接セル（Neighbour cell）の測定（メジャメント（measurement））などが行われる。
【００６９】
基地局２０３は、ｅＮＢ２０７と、Ｈｏｍｅ−ｅＮＢ２０６とに分類される。通信システム２００は、複数のｅＮＢ２０７を含むｅＮＢ群２０３−１と、複数のＨｏｍｅ−ｅＮＢ２０６を含むＨｏｍｅ−ｅＮＢ群２０３−２とを備える。またコアネットワークであるＥＰＣ（Evolved Packet Core）と、無線アクセスネットワークであるＥ−ＵＴＲＡＮ２０１とで構成されるシステムは、ＥＰＳ（Evolved Packet System）と称される。コアネットワークであるＥＰＣと、無線アクセスネットワークであるＥ−ＵＴＲＡＮ２０１とを合わせて、「ネットワーク」という場合がある。
【００７０】
ｅＮＢ２０７は、移動管理エンティティ（Mobility Management Entity：ＭＭＥ）、あるいはＳ−ＧＷ（Serving Gateway）、あるいはＭＭＥおよびＳ−ＧＷを含むＭＭＥ／Ｓ−ＧＷ部（以下「ＭＭＥ部」という場合がある）２０４とＳ１インタフェースにより接続され、ｅＮＢ２０７とＭＭＥ部２０４との間で制御情報が通信される。一つのｅＮＢ２０７に対して、複数のＭＭＥ部２０４が接続されてもよい。ｅＮＢ２０７間は、Ｘ２インタフェースにより接続され、ｅＮＢ２０７間で制御情報が通信される。
【００７１】
Ｈｏｍｅ−ｅＮＢ２０６は、ＭＭＥ部２０４とＳ１インタフェースにより接続され、Ｈｏｍｅ−ｅＮＢ２０６とＭＭＥ部２０４との間で制御情報が通信される。一つのＭＭＥ部２０４に対して、複数のＨｏｍｅ−ｅＮＢ２０６が接続される。あるいは、Ｈｏｍｅ−ｅＮＢ２０６は、ＨｅＮＢＧＷ（Home-eNB GateWay）２０５を介してＭＭＥ部２０４と接続される。Ｈｏｍｅ−ｅＮＢ２０６とＨｅＮＢＧＷ２０５とは、Ｓ１インタフェースにより接続され、ＨｅＮＢＧＷ２０５とＭＭＥ部２０４とはＳ１インタフェースを介して接続される。
【００７２】
一つまたは複数のＨｏｍｅ−ｅＮＢ２０６が一つのＨｅＮＢＧＷ２０５と接続され、Ｓ１インタフェースを通して情報が通信される。ＨｅＮＢＧＷ２０５は、一つまたは複数のＭＭＥ部２０４と接続され、Ｓ１インタフェースを通して情報が通信される。
【００７３】
ＭＭＥ部２０４およびＨｅＮＢＧＷ２０５は、上位装置、具体的には上位ノードであり、基地局であるｅＮＢ２０７およびＨｏｍｅ−ｅＮＢ２０６と、移動端末（ＵＥ）２０２との接続を制御する。ＭＭＥ部２０４は、コアネットワークであるＥＰＣを構成する。基地局２０３およびＨｅＮＢＧＷ２０５は、Ｅ−ＵＴＲＡＮ２０１を構成する。
【００７４】
さらに３ＧＰＰでは、以下のような構成が検討されている。Ｈｏｍｅ−ｅＮＢ２０６間のＸ２インタフェースはサポートされる。すなわち、Ｈｏｍｅ−ｅＮＢ２０６間は、Ｘ２インタフェースにより接続され、Ｈｏｍｅ−ｅＮＢ２０６間で制御情報が通信される。ＭＭＥ部２０４からは、ＨｅＮＢＧＷ２０５はＨｏｍｅ−ｅＮＢ２０６として見える。Ｈｏｍｅ−ｅＮＢ２０６からは、ＨｅＮＢＧＷ２０５はＭＭＥ部２０４として見える。
【００７５】
Ｈｏｍｅ−ｅＮＢ２０６が、ＨｅＮＢＧＷ２０５を介してＭＭＥ部２０４に接続される場合および直接ＭＭＥ部２０４に接続される場合のいずれの場合も、Ｈｏｍｅ−ｅＮＢ２０６とＭＭＥ部２０４との間のインタフェースは、Ｓ１インタフェースで同じである。
【００７６】
基地局２０３は、１つのセルを構成してもよいし、複数のセルを構成してもよい。各セルは、移動端末２０２と通信可能な範囲であるカバレッジとして予め定める範囲を有し、カバレッジ内で移動端末２０２と無線通信を行う。１つの基地局２０３が複数のセルを構成する場合、１つ１つのセルが、移動端末２０２と通信可能に構成される。
【００７７】
図３は、本発明に係る通信端末である図２に示す移動端末２０２の構成を示すブロック図である。図３に示す移動端末２０２の送信処理を説明する。まず、プロトコル処理部３０１からの制御データ、およびアプリケーション部３０２からのユーザデータが、送信データバッファ部３０３へ保存される。送信データバッファ部３０３に保存されたデータは、エンコーダー部３０４へ渡され、誤り訂正などのエンコード処理が施される。エンコード処理を施さずに、送信データバッファ部３０３から変調部３０５へ直接出力されるデータが存在してもよい。エンコーダー部３０４でエンコード処理されたデータは、変調部３０５にて変調処理が行われる。変調されたデータは、ベースバンド信号に変換された後、周波数変換部３０６へ出力され、無線送信周波数に変換される。その後、アンテナ３０７から基地局２０３に送信信号が送信される。
【００７８】
また、移動端末２０２の受信処理は、以下のように実行される。基地局２０３からの無線信号がアンテナ３０７により受信される。受信信号は、周波数変換部３０６にて無線受信周波数からベースバンド信号に変換され、復調部３０８において復調処理が行われる。復調後のデータは、デコーダー部３０９へ渡され、誤り訂正などのデコード処理が行われる。デコードされたデータのうち、制御データはプロトコル処理部３０１へ渡され、ユーザデータはアプリケーション部３０２へ渡される。移動端末２０２の一連の処理は、制御部３１０によって制御される。よって制御部３１０は、図３では省略しているが、各部３０１〜３０９と接続している。
【００７９】
図４は、本発明に係る基地局である図２に示す基地局２０３の構成を示すブロック図である。図４に示す基地局２０３の送信処理を説明する。ＥＰＣ通信部４０１は、基地局２０３とＥＰＣ（ＭＭＥ部２０４など）、ＨｅＮＢＧＷ２０５などとの間のデータの送受信を行う。他基地局通信部４０２は、他の基地局との間のデータの送受信を行う。ＥＰＣ通信部４０１および他基地局通信部４０２は、それぞれプロトコル処理部４０３と情報の受け渡しを行う。プロトコル処理部４０３からの制御データ、ならびにＥＰＣ通信部４０１および他基地局通信部４０２からのユーザデータおよび制御データは、送信データバッファ部４０４へ保存される。
【００８０】
送信データバッファ部４０４に保存されたデータは、エンコーダー部４０５へ渡され、誤り訂正などのエンコード処理が施される。エンコード処理を施さずに、送信データバッファ部４０４から変調部４０６へ直接出力されるデータが存在してもよい。エンコードされたデータは、変調部４０６にて変調処理が行われる。変調されたデータは、ベースバンド信号に変換された後、周波数変換部４０７へ出力され、無線送信周波数に変換される。その後、アンテナ４０８より一つもしくは複数の移動端末２０２に対して送信信号が送信される。
【００８１】
また、基地局２０３の受信処理は以下のように実行される。一つもしくは複数の移動端末２０２からの無線信号が、アンテナ４０８により受信される。受信信号は、周波数変換部４０７にて無線受信周波数からベースバンド信号に変換され、復調部４０９で復調処理が行われる。復調されたデータは、デコーダー部４１０へ渡され、誤り訂正などのデコード処理が行われる。デコードされたデータのうち、制御データはプロトコル処理部４０３あるいはＥＰＣ通信部４０１、他基地局通信部４０２へ渡され、ユーザデータはＥＰＣ通信部４０１および他基地局通信部４０２へ渡される。基地局２０３の一連の処理は、制御部４１１によって制御される。よって制御部４１１は、図４では省略しているが、各部４０１〜４１０と接続している。
【００８２】
図５は、本発明に係るＭＭＥの構成を示すブロック図である。図５では、前述の図２に示すＭＭＥ部２０４に含まれるＭＭＥ２０４ａの構成を示す。ＰＤＮ  ＧＷ通信部５０１は、ＭＭＥ２０４ａとＰＤＮ  ＧＷとの間のデータの送受信を行う。基地局通信部５０２は、ＭＭＥ２０４ａと基地局２０３との間のＳ１インタフェースによるデータの送受信を行う。ＰＤＮ  ＧＷから受信したデータがユーザデータであった場合、ユーザデータは、ＰＤＮ  ＧＷ通信部５０１から、ユーザプレイン通信部５０３経由で基地局通信部５０２に渡され、１つあるいは複数の基地局２０３へ送信される。基地局２０３から受信したデータがユーザデータであった場合、ユーザデータは、基地局通信部５０２から、ユーザプレイン通信部５０３経由でＰＤＮ  ＧＷ通信部５０１に渡され、ＰＤＮ  ＧＷへ送信される。
【００８３】
ＰＤＮ  ＧＷから受信したデータが制御データであった場合、制御データは、ＰＤＮ  ＧＷ通信部５０１から制御プレイン制御部５０５へ渡される。基地局２０３から受信したデータが制御データであった場合、制御データは、基地局通信部５０２から制御プレイン制御部５０５へ渡される。
【００８４】
ＨｅＮＢＧＷ通信部５０４は、ＨｅＮＢＧＷ２０５が存在する場合に設けられ、情報種別によって、ＭＭＥ２０４ａとＨｅＮＢＧＷ２０５との間のインタフェース（ＩＦ）によるデータの送受信を行う。ＨｅＮＢＧＷ通信部５０４から受信した制御データは、ＨｅＮＢＧＷ通信部５０４から制御プレイン制御部５０５へ渡される。制御プレイン制御部５０５での処理の結果は、ＰＤＮ  ＧＷ通信部５０１経由でＰＤＮ  ＧＷへ送信される。また、制御プレイン制御部５０５で処理された結果は、基地局通信部５０２経由でＳ１インタフェースにより１つあるいは複数の基地局２０３へ送信され、またＨｅＮＢＧＷ通信部５０４経由で１つあるいは複数のＨｅＮＢＧＷ２０５へ送信される。
【００８５】
制御プレイン制御部５０５には、ＮＡＳセキュリティ部５０５−１、ＳＡＥベアラコントロール部５０５−２、アイドルステート（Idle State）モビリティ管理部５０５−３などが含まれ、制御プレインに対する処理全般を行う。ＮＡＳセキュリティ部５０５−１は、ＮＡＳ（Non-Access Stratum）メッセージのセキュリティなどを行う。ＳＡＥベアラコントロール部５０５−２は、ＳＡＥ（System Architecture Evolution）のベアラの管理などを行う。アイドルステートモビリティ管理部５０５−３は、待受け状態（アイドルステート（Idle State）；ＬＴＥ−ＩＤＬＥ状態、または、単にアイドルとも称される）のモビリティ管理、待受け状態時のページング信号の生成および制御、傘下の１つあるいは複数の移動端末２０２のトラッキングエリアの追加、削除、更新、検索、トラッキングエリアリスト管理などを行う。
【００８６】
ＭＭＥ２０４ａは、１つまたは複数の基地局２０３に対して、ページング信号の分配を行う。また、ＭＭＥ２０４ａは、待受け状態（Idle State）のモビリティ制御（Mobility control）を行う。ＭＭＥ２０４ａは、移動端末が待ち受け状態のとき、および、アクティブ状態（Active State）のときに、トラッキングエリア（Tracking Area）リストの管理を行う。ＭＭＥ２０４ａは、ＵＥが登録されている（registered）追跡領域（トラッキングエリア：Tracking Area）に属するセルへ、ページングメッセージを送信することで、ページングプロトコルに着手する。ＭＭＥ２０４ａに接続されるＨｏｍｅ−ｅＮＢ２０６のＣＳＧの管理、ＣＳＧ−ＩＤの管理、およびホワイトリストの管理は、アイドルステートモビリティ管理部５０５−３で行われてもよい。
【００８７】
次に通信システムにおけるセルサーチ方法の一例を示す。図６は、ＬＴＥ方式の通信システムにおいて通信端末（ＵＥ）が行うセルサーチから待ち受け動作までの概略を示すフローチャートである。通信端末は、セルサーチを開始すると、ステップＳＴ６０１で、周辺の基地局から送信される第一同期信号（Ｐ−ＳＳ）、および第二同期信号（Ｓ−ＳＳ）を用いて、スロットタイミング、フレームタイミングの同期をとる。
【００８８】
Ｐ−ＳＳとＳ−ＳＳとを合わせて、同期信号（Synchronization Signal：ＳＳ）という。同期信号（ＳＳ）には、セル毎に割り当てられたＰＣＩに１対１に対応するシンクロナイゼーションコードが割り当てられている。ＰＣＩの数は５０４通りが検討されている。この５０４通りのＰＣＩを用いて同期をとるとともに、同期がとれたセルのＰＣＩを検出（特定）する。
【００８９】
次に同期がとれたセルに対して、ステップＳＴ６０２で、基地局からセル毎に送信される参照信号（リファレンスシグナル：ＲＳ）であるセル固有参照信号（Cell-specific Reference Signal：ＣＲＳ）を検出し、ＲＳの受信電力（Reference Signal Received Power：ＲＳＲＰ）の測定を行う。参照信号（ＲＳ）には、ＰＣＩと１対１に対応したコードが用いられている。そのコードで相関をとることによって他セルと分離できる。ステップＳＴ６０１で特定したＰＣＩから、該セルのＲＳ用のコードを導出することによって、ＲＳを検出し、ＲＳの受信電力を測定することが可能となる。
【００９０】
次にステップＳＴ６０３で、ステップＳＴ６０２までで検出された一つ以上のセルの中から、ＲＳの受信品質が最もよいセル、例えば、ＲＳの受信電力が最も高いセル、つまりベストセルを選択する。
【００９１】
次にステップＳＴ６０４で、ベストセルのＰＢＣＨを受信して、報知情報であるＢＣＣＨを得る。ＰＢＣＨ上のＢＣＣＨには、セル構成情報が含まれるＭＩＢ（Master Information Block）がマッピングされる。したがってＰＢＣＨを受信してＢＣＣＨを得ることで、ＭＩＢが得られる。ＭＩＢの情報としては、例えば、ＤＬ（ダウンリンク）システム帯域幅（送信帯域幅設定（transmission bandwidth configuration：dl-bandwidth）とも呼ばれる）、送信アンテナ数、ＳＦＮ（System Frame Number）などがある。
【００９２】
次にステップＳＴ６０５で、ＭＩＢのセル構成情報をもとに該セルのＤＬ−ＳＣＨを受信して、報知情報ＢＣＣＨの中のＳＩＢ（System Information Block）１を得る。ＳＩＢ１には、該セルへのアクセスに関する情報、セルセレクションに関する情報、他のＳＩＢ（ＳＩＢｋ；ｋ≧２の整数）のスケジューリング情報が含まれる。また、ＳＩＢ１には、トラッキングエリアコード（Tracking Area Code：ＴＡＣ）が含まれる。
【００９３】
次にステップＳＴ６０６で、通信端末は、ステップＳＴ６０５で受信したＳＩＢ１のＴＡＣと、通信端末が既に保有しているトラッキングエリアリスト内のトラッキングエリア識別子（Tracking Area Identity：ＴＡＩ）のＴＡＣ部分とを比較する。トラッキングエリアリストは、ＴＡＩリスト（TAI list）とも称される。ＴＡＩはトラッキングエリアを識別するための識別情報であり、ＭＣＣ（Mobile Country Code）と、ＭＮＣ（Mobile Network Code）と、ＴＡＣ（Tracking Area Code）とによって構成される。ＭＣＣは国コードである。ＭＮＣはネットワークコードである。ＴＡＣはトラッキングエリアのコード番号である。
【００９４】
通信端末は、ステップＳＴ６０６で比較した結果、ステップＳＴ６０５で受信したＴＡＣがトラッキングエリアリスト内に含まれるＴＡＣと同じならば、該セルで待ち受け動作に入る。比較して、ステップＳＴ６０５で受信したＴＡＣがトラッキングエリアリスト内に含まれなければ、通信端末は、該セルを通して、ＭＭＥなどが含まれるコアネットワーク（Core Network，ＥＰＣ）へ、ＴＡＵ（Tracking Area Update）を行うためにトラッキングエリアの変更を要求する。
【００９５】
コアネットワークを構成する装置（以下「コアネットワーク側装置」という場合がある）は、ＴＡＵ要求信号とともに通信端末から送られてくる該通信端末の識別番号（ＵＥ−ＩＤなど）をもとに、トラッキングエリアリストの更新を行う。コアネットワーク側装置は、通信端末に更新後のトラッキングエリアリストを送信する。通信端末は、受信したトラッキングエリアリストに基づいて、通信端末が保有するＴＡＣリストを書き換える（更新する）。その後、通信端末は、該セルで待ち受け動作に入る。
【００９６】
スマートフォンおよびタブレット型端末装置の普及によって、セルラー系無線通信によるトラフィックが爆発的に増大しており、世界中で無線リソースの不足が懸念されている。これに対応して周波数利用効率を高めるために、小セル化し、空間分離を進めることが検討されている。
【００９７】
従来のセルの構成では、ｅＮＢによって構成されるセルは、比較的広い範囲のカバレッジを有する。従来は、複数のｅＮＢによって構成される複数のセルの比較的広い範囲のカバレッジによって、あるエリアを覆うように、セルが構成されている。
【００９８】
小セル化された場合、ｅＮＢによって構成されるセルは、従来のｅＮＢによって構成されるセルのカバレッジに比べて範囲が狭いカバレッジを有する。したがって、従来と同様に、あるエリアを覆うためには、従来のｅＮＢに比べて、多数の小セル化されたｅＮＢが必要となる。
【００９９】
以下の説明では、従来のｅＮＢによって構成されるセルのように、カバレッジが比較的大きいセルを「マクロセル」といい、マクロセルを構成するｅＮＢを「マクロｅＮＢ」という。また、小セル化されたセルのように、カバレッジが比較的小さいセルを「スモールセル」といい、スモールセルを構成するｅＮＢを「スモールｅＮＢ」という。
【０１００】
マクロｅＮＢは、例えば、非特許文献７に記載される「ワイドエリア基地局（Wide Area Base Station）」であってもよい。
【０１０１】
スモールｅＮＢは、例えば、ローパワーノード、ローカルエリアノード、ホットスポットなどであってもよい。また、スモールｅＮＢは、ピコセルを構成するピコｅＮＢ、フェムトセルを構成するフェムトｅＮＢ、ＨｅＮＢ、ＲＲＨ（Remote Radio Head）、ＲＲＵ（Remote Radio Unit）、ＲＲＥ（Remote Radio Equipment）またはＲＮ（Relay Node）であってもよい。また、スモールｅＮＢは、非特許文献７に記載される「ローカルエリア基地局（Local Area Base Station）」または「ホーム基地局（Home Base Station）」であってもよい。
【０１０２】
図７は、マクロｅＮＢとスモールｅＮＢとが混在する場合のセルの構成の概念を示す図である。マクロｅＮＢによって構成されるマクロセルは、比較的広い範囲のカバレッジ７０１を有する。スモールｅＮＢによって構成されるスモールセルは、マクロｅＮＢ（マクロセル）のカバレッジ７０１に比べて範囲が小さいカバレッジ７０２を有する。
【０１０３】
複数のｅＮＢが混在する場合、あるｅＮＢによって構成されるセルのカバレッジが、他のｅＮＢによって構成されるセルのカバレッジ内に含まれる場合がある。図７に示すセルの構成では、参照符号「７０４」または「７０５」で示されるように、スモールｅＮＢによって構成されるスモールセルのカバレッジ７０２が、マクロｅＮＢによって構成されるマクロセルのカバレッジ７０１内に含まれる場合がある。
【０１０４】
また、参照符号「７０５」で示されるように、複数、例えば２つのスモールセルのカバレッジ７０２が、１つのマクロセルのカバレッジ７０１内に含まれる場合もある。移動端末（ＵＥ）７０３は、例えばスモールセルのカバレッジ７０２内に含まれ、スモールセルを介して通信を行う。
【０１０５】
また図７に示すセルの構成では、参照符号「７０６」で示されるように、マクロｅＮＢによって構成されるマクロセルのカバレッジ７０１と、スモールｅＮＢによって構成されるスモールセルのカバレッジ７０２とが複雑に重複する場合が生じる。
【０１０６】
また、参照符号「７０７」で示されるように、マクロｅＮＢによって構成されるマクロセルのカバレッジ７０１と、スモールｅＮＢによって構成されるスモールセルのカバレッジ７０２とが重複しない場合も生じる。
【０１０７】
さらには、参照符号「７０８」で示されるように、多数のスモールｅＮＢによって構成される多数のスモールセルのカバレッジ７０２が、１つのマクロｅＮＢによって構成される１つのマクロセルのカバレッジ７０１内に構成される場合も生じる。
【０１０８】
デュアルコネクティビティ（ＤＣ）では、スプリットベアラがサポートされている。スプリットベアラとは、ＭｅＮＢとＵＥとの間の直接のパスと、ＳｅＮＢを介したＭｅＮＢとＵＥとの間のパスとに分割（スプリット（split））されたベアラをいう。
【０１０９】
スプリットベアラでは、ＭｅＮＢだけでなく、ＳｅＮＢに対しても、ＳＰＳ（Semi-Persistent Scheduling）がサポートされている（非特許文献６参照）。ＳＰＳは、ＭｅＮＢ、ＳｅＮＢに対して同時、かつ独立に設定可能である。
【０１１０】
ＳＰＳは、複数のサブフレームの長期間にわたって、無線リソースをＵＥに準静的に割当てることを可能にするスケジューリング方法である。これによって、ｅＮＢは、ＰＤＣＣＨおよびＥＰＤＣＣＨなどの個別制御チャネル上のＤＬ割当情報、あるいはＵＬグラント情報を、各サブフレームでＵＥに送信することを不要とすることができる。
【０１１１】
３ＧＰＰにおけるＳＰＳについては、非特許文献９に記載されている。
【０１１２】
ＲＲＣ個別シグナリングで、ＳＰＳの間隔、ＳＰＳ用のＣ−ＲＮＴＩ（Cell Radio Network Temporary Identifier）およびＵＬのインプリシットリリース前の空送信回数（以下「リリース前空送信回数」という場合がある）などの設定がＵＥに通知される。これによって、ＳＰＳが実行可能となる。リリース前空送信回数として、「implicitReleaseAfter」というパラメータが用いられる。以下の説明では、リリース前空送信回数を記号「ｎ」で表す場合がある。
【０１１３】
また、ＲＲＣ個別シグナリングによってＳＰＳを無効にする。これによって、対応するＤＬ割当情報あるいはＵＬグラント情報は廃棄される。ＳＰＳ用のＣ−ＲＮＴＩは、ＳＰＳ  Ｃ−ＲＮＴＩと称される場合がある。
【０１１４】
ＳＰＳは、ＰＤＣＣＨあるいはＥＰＤＣＣＨによって、実行開始（アクティベート）、および実行終了（デアクティベート）される。このＰＤＣＣＨあるいはＥＰＤＣＣＨのＣＲＣに、ＳＰＳ  Ｃ−ＲＮＴＩがマスクされる。
【０１１５】
特に、上りリンクのＳＰＳについては、インプリシットリリース（implicit release）と称されるＳＰＳの実行終了方法が決められている。ＵＥは、上り送信データが無い場合、パディングビットおよびパディングＢＳＲの少なくとも一方を含むＭＡＣ  ＰＤＵ（Protocol Data Unit）を送信する。この送信は、空送信またはパディング（padding）送信と称される場合がある。該送信が前述のＵＬのインプリシットリリース前の空送信回数として設定される回数、連続して行われた場合、直ちに上りグラント情報をクリアする。
【０１１６】
これによって、ｅＮＢにおいても、ＵＥからの該送信を、ＵＬのインプリシットリリース前の空送信回数として設定される回数連続して受信した場合に、上りＳＰＳの設定を無効にする。ｅＮＢは、ＳＰＳの設定を無効にすることによって、ＳＰＳの設定で割当てていた無線リソースを、他のＵＥに対して使用することが可能となる。
【０１１７】
図８は、上りリンクのＳＰＳの動作例を説明する図である。
【０１１８】
ステップＳＴ８０１において、ｅＮＢは、ＲＲＣ個別シグナリングで、ＳＰＳリソースの構成およびＰＤＣＣＨ受信時に用いるＳＰＳ  Ｃ-ＲＮＴＩをＵＥに通知する。
【０１１９】
ステップＳＴ８０１でＳＰＳリソースの構成およびＳＰＳ  Ｃ-ＲＮＴＩを受信したＵＥは、ＰＤＣＣＨをＳＰＳ  Ｃ-ＲＮＴＩで検出する。
【０１２０】
ステップＳＴ８０２において、ｅＮＢは、ＳＰＳの実行開始（アクティベート）指示をＵＥに通知する。ステップＳＴ８０２でＳＰＳの実行開始指示を受信したＵＥは、最初のスケジューリングを検出した場合、ＳＰＳをアクティベート（activate）される。すなわち、ＳＰＳの実行が開始される。そして、該スケジューリングは、デアクティベート（deactivate）される、すなわちＳＰＳの実行が終了されるまで継続される。
【０１２１】
ステップＳＴ８０３およびステップＳＴ８０４において、ｅＮＢとＵＥとの間で、該スケジューリングされたＳＰＳリソースでＳＰＳが実行される。ステップＳＴ８０３およびステップＳＴ８０４において、ＵＥは、設定されたＳＰＳリソースで、ｅＮＢに上りデータの送信を行う。
【０１２２】
ステップＳＴ８０５において、ＵＥは、設定されたＳＰＳリソースで送信データが無くなった場合、パディング送信を行う。
【０１２３】
ステップＳＴ８０５およびステップＳＴ８０６において、ＵＥは、パディング送信を、リリース前空送信回数として設定される回数連続して行った場合、ステップＳＴ８０７において、ＳＰＳをクリアする。ここでは、リリース前空送信回数を２回としている。
【０１２４】
ステップＳＴ８０５およびステップＳＴ８０６において、ｅＮＢも、ＵＥからのパディング送信を、リリース前空送信回数として設定される回数連続して受信した場合、ステップＳＴ８０７において、上りＳＰＳの設定をリリースする。
【０１２５】
前述したように、ＤＣでは、スプリットベアラがサポートされている。３ＧＰＰにおいて、上りスプリットベアラを実行しているときのバッファ状態報告（Buffer Status Report；略称：ＢＳＲ）の送信方法について、二重報告および閾値（Double Reporting And Threshold；略称：ＤＲＡＴ）による方法とすることが提案されている（非特許文献７参照）。
【０１２６】
図９および図１０は、ＤＲＡＴによる送信方法について説明するための図である。図９は、上りＰＤＣＰのデータ量が予め定める閾値（Ｔｈ）以下の場合を示している。図１０は、上りＰＤＣＰのデータ量が予め定める閾値（Ｔｈ）より大きい場合を示している。
【０１２７】
図９において、ＵＥ９０５は、ＭＡＣ（Medium Access Control）９０７、ＲＬＣ（Radio Link Control）９０８、ＭＡＣ９０９、ＲＬＣ９１０およびＰＤＣＰ（Packet Data Convergence Protocol）９１１を含む。ＭＡＣ９０７は、ＭｅＮＢ９０１に対して用いられる。ＲＬＣ９０８は、ＭｅＮＢ９０１に対して用いられる。ＭＡＣ９０９は、ＳｅＮＢ９０２に対して用いられる。ＲＬＣ９１０は、ＳｅＮＢ９０２に対して用いられる。
【０１２８】
図１０において、ＵＥ９０６は、ＭＡＣ９１２、ＲＬＣ９１３、ＭＡＣ９１４、ＲＬＣ９１５およびＰＤＣＰ９１６を含む。ＭＡＣ９１２は、ＭｅＮＢ９０３に対して用いられる。ＲＬＣ９１３は、ＭｅＮＢ９０３に対して用いられる。ＭＡＣ９１４は、ＳｅＮＢ９０４に対して用いられる。ＲＬＣ９１５は、ＳｅＮＢ９０４に対して用いられる。
【０１２９】
ＤＲＡＴでは、図９に示すように、ＰＤＣＰ９１１のデータ量が予め定める閾値以下である場合は、一つのｅＮＢ、すなわちＭｅＮＢ９０１あるいはＳｅＮＢ９０２に、バッファ状態（Buffer Status；略称：ＢＳ）を報告する。ＭｅＮＢ９０１およびＳｅＮＢ９０２のどちらのｅＮＢにＢＳを報告するかは、ＲＲＣシグナリングによって設定される。ＢＳを報告するｅＮＢとして設定された一つのｅＮＢを「１ｓｔ−ｅＮＢ」とする。図９では、ＭｅＮＢ９０１にＢＳを報告する場合を示している。
【０１３０】
図１０に示すように、ＰＤＣＰ９１６のデータ量が予め定める閾値よりも大きい場合は、両方のｅＮＢ、すなわち、１ｓｔ−ｅＮＢおよび２ｎｄ−ｅＮＢに、同じＰＤＣＰ９１６のデータ量のＢＳを報告する。図１０では、１ｓｔ−ｅＮＢをＭｅＮＢ９０３とし、２ｎｄ−ｅＮＢをＳｅＮＢ９０４とする。予め定める閾値は、ラジオベアラ（Radio bearer：ＲＢ）毎に設定される。
【０１３１】
図９を、上りＰＤＣＰのデータ量が予め定める閾値（Ｔｈ）よりも小さい場合とし、図１０を、上りＰＤＣＰのデータ量が予め定める閾値（Ｔｈ）以上である場合としてもよい。
【０１３２】
さらに、３ＧＰＰでは、バッファ状態報告（ＢＳＲ）のトリガと、データを送信するｅＮＢとは一致させることが提案されている。
【０１３３】
これに従うと、ＤＲＡＴでは、送信データのデータ量が閾値以下の場合は、設定された一つのｅＮＢ（１ｓｔ−ｅＮＢ）にデータを送信する。送信データのデータ量が閾値よりも大きい場合は、両方のｅＮＢ（１ｓｔ−ｅＮＢ、２ｎｄ−ｅＮＢ）にデータを送信する。
【０１３４】
ＵＬスプリットベアラが設定された状態で、２ｎｄ−ｅＮＢに対してＳＰＳが設定され、実行開始（アクティベート）された場合を考える。ＤＲＡＴによって、ＵＥは、上りデータのデータ量が閾値以下になった場合、２ｎｄ−ｅＮＢにデータの送信を行わないことになる。
【０１３５】
２ｎｄ−ｅＮＢに対して設定されたＳＰＳリソースにおいて、上りデータのデータ量が閾値以下になり、２ｎｄ−ｅＮＢにデータの送信を行わないようになった場合の動作については何ら規定が無く、何ら議論もされていない。
【０１３６】
したがって、上りデータのデータ量が閾値以下の場合、２ｎｄ−ｅＮＢにデータの送信が行われないので、設定されたＳＰＳリソースで何も送信されず、パディング送信も行われない可能性が生じる。
【０１３７】
パディング送信が行われないと、インプリシットリリースが正常に行われなくなるので、ＵＥは、ＳＰＳリソースをクリアして良いか否かの判断ができない。また、ｅＮＢは、ＳＰＳリソースをリリースして良いか否かの判断ができない。したがって、ｅＮＢとＵＥとの間で不安定な動作が生じ、ひいては誤動作を引き起こす可能性が生じてしまう。
【０１３８】
図１１は、ＵＬスプリットベアラが設定された場合に、ＳＰＳが設定された場合の問題点を説明する図である。１ｓｔ−ｅＮＢをＭｅＮＢとし、２ｎｄ−ｅＮＢをＳｅＮＢとする。図１１では、ＭｅＮＢとＳｅＮＢとに、ぞれぞれ、ＳＰＳが設定された場合を示している。
【０１３９】
ステップＳＴ１００１において、ＭｅＮＢは、ＵＥに、ＰＤＣＣＨを用いて、上りＳＰＳの上りグラントでアクティベートを通知する。ＵＥは、該ＰＤＣＣＨを受信して、上りＳＰＳをアクティベートする。すなわち、上りＳＰＳの実行を開始する。
【０１４０】
ステップＳＴ１００２からステップＳＴ１００７において、ＵＥは、ＭｅＮＢに対して設定された上りＳＰＳリソースで、上りデータをＭｅＮＢに送信する。
【０１４１】
ステップＳＴ１００８において、ＳｅＮＢは、ＵＥに、ＰＤＣＣＨを用いて、上りＳＰＳの上りグラントでアクティベートを通知する。ＵＥは、該ＰＤＣＣＨを受信して、上りＳＰＳをアクティベートする。
【０１４２】
ステップＳＴ１００９において、ＵＥは、ＳｅＮＢに対して設定された上りＳＰＳリソースで、上りデータをＳｅＮＢに送信する。ＵＥで発生する送信データのデータ量は、ＤＲＡＴにおける閾値以上であるとする。図示はしていないが、ＵＥは、ＭｅＮＢにもデータを送信する。
【０１４３】
したがって、ＵＥで発生した上りデータの一部は、ＭｅＮＢに送信され、残りの上りデータがＳｅＮＢに送信される。
【０１４４】
ステップＳＴ１０１０において、ＳｅＮＢに対して設定された上りＳＰＳリソースで、ＵＥで上りデータが発生しなかった場合を考える。この場合、上りデータのデータ量がＤＲＡＴにおいて閾値以下となるので、ＵＥは、ＳｅＮＢに上りデータの送信を行わないと判断し、パディング送信も行わない。
【０１４５】
ステップＳＴ１０１０およびステップＳＴ１０１１において、ＳｅＮＢに対して設定された上りＳＰＳリソースで、連続してＵＥで上りデータが発生しない場合、同様に、上りデータのデータ量がＤＲＡＴにおいて閾値以下となるので、ＵＥは、ＳｅＮＢに上りデータの送信を行わないと判断し、パディング送信も行わない。
【０１４６】
たとえ、リリース前空送信回数（図１１では２回とする）連続して上り送信データが発生しなかったとしても、パディング送信が行われない。したがって、ステップＳＴ１０１２において、ＵＥはＳＰＳリソースをクリアして良いか否かの判断ができなくなる。また、ｅＮＢもＳＰＳリソースをリリースして良いか否かの判断ができなくなってしまう。
【０１４７】
したがって、ｅＮＢとＵＥとの間で不安定な動作が生じ、ひいては誤動作を引き起こす可能性が生じてしまう。
【０１４８】
以上のことから、上りスプリットベアラでＤＲＡＴが実行された場合にＳＰＳを可能とし、高速で安定な通信システムを提供することが求められる。
【０１４９】
本実施の形態では、このような問題を解決する方法を開示する。
【０１５０】
ＳＰＳが設定された場合は、１ｓｔ−ｅＮＢにも、２ｎｄ−ｅＮＢにも上りデータを送信する。
【０１５１】
このようにする方法として、例えば、ＳＰＳが設定された場合は、ＤＲＡＴの閾値を設けない。あるいは、ＳＰＳが設定された場合は、設定されたＤＲＡＴの閾値を無効とする。これらのようにすることによって、ＳＰＳが設定された場合に、閾値が無くなり、あるいは閾値が無効となり、１ｓｔ−ｅＮＢにも、２ｎｄ−ｅＮＢにも上りデータが送信されることになる。
【０１５２】
ＳＰＳ用のＤＲＡＴの閾値を設けてもよい。ＳＰＳ用のＤＲＡＴの閾値を設けることによって、ＳＰＳ用のＤＲＡＴの閾値を、ＳＰＳで無い場合のＤＲＡＴの閾値と異なる値を設定することができ、ＳＰＳの場合のＤＲＡＴの動作を、ＳＰＳで無い場合のＤＲＡＴと動作を異ならせることが可能となる。
【０１５３】
両方のｅＮＢに上りデータを送信するようにする他の方法として、例えば、ＳＰＳ用のＤＲＡＴの閾値として負の値を設定する。上りデータのデータ量がＤＲＡＴの閾値よりも大きい場合において両ｅＮＢに送信する場合に適用するとよい。
【０１５４】
あるいは、ＳＰＳ用のＤＲＡＴの閾値として０を設定する。上りデータのデータ量がＤＲＡＴの閾値以上の場合において両ｅＮＢに送信する場合に適用するとよい。
【０１５５】
これらのようにすることによって、ＳＰＳが設定された場合に、１ｓｔ−ｅＮＢにも、２ｎｄ−ｅＮＢにも上りデータが送信されることになる。
【０１５６】
これらの方法を用いることによって、ＳＰＳが設定された場合、１ｓｔ−ｅＮＢにも、２ｎｄ−ｅＮＢにも上りデータが送信されることになるので、パディング送信も可能となる。したがって、インプリシットリリースが可能となる。
【０１５７】
ＳＰＳが設定された場合は、１ｓｔ−ｅＮＢにも、２ｎｄ−ｅＮＢにも上りデータを送信することは、予め規格などで静的に決めておいてもよいし、ＳＰＳの設定とともにＵＥに通知してもよい。あるいは、ＳＰＳアクティベートとともにＵＥに通知してもよい。
【０１５８】
例えば、ＳＰＳが設定された場合は、ＤＲＡＴの閾値を設けないこと、あるいは、設定されたＤＲＡＴの閾値を無効とすること、あるいは、ＤＲＡＴの閾値を負の値にすること、あるいは、ＤＲＡＴの閾値を０にすることを予め規格などで静的に決めておく。これによって、ｅＮＢとＵＥとの間で共通の認識を得ることが可能となる。また、これらの情報をシグナリングする必要がなくなるので、シグナリングの負荷を低減することができる。
【０１５９】
他の例として、設定されたＤＲＡＴの閾値を無効とする情報を設け、該情報をＳＰＳの設定とともにＵＥに通知するとよい。あるいは、ＤＲＡＴの閾値として、負の値、あるいは０を、ＳＰＳの設定とともにＵＥに通知するとよい。
【０１６０】
これらの通知は、ＳＰＳの設定とは別途ＵＥに通知してもよい。設定されたＤＲＡＴの閾値を無効とする情報をＳＰＳの設定とともに通知することによって、シグナリングの負荷を低減することができる。また、ＳＰＳの設定とタイミングを同じにすることが可能となるので、不安定な動作および誤動作が発生する可能性を低減することができる。これらの通知には、ＵＥ個別のＲＲＣシグナリングを用いるとよい。
【０１６１】
他の例として、設定されたＤＲＡＴの閾値を無効とする情報を設け、該情報をＳＰＳアクティベートとともにＵＥに通知するとよい。あるいは、ＤＲＡＴの閾値として、負の値、あるいは０を、ＳＰＳアクティベートとともにＵＥに通知するとよい。
【０１６２】
これらの通知は、ＳＰＳアクティベートとは別途ＵＥに通知してもよい。設定されたＤＲＡＴの閾値を無効とする情報をＳＰＳのアクティベートとともに通知することによって、シグナリングの負荷を低減することができる。また、ＳＰＳのアクティベートとタイミングを同じにすることが可能となるので、不安定な動作および誤動作が発生する可能性を低減することができる。これらの通知には、Ｌ１／Ｌ２制御信号を用いるとよい。
【０１６３】
前述のようにして設定された、１ｓｔ−ｅＮＢにも、２ｎｄ−ｅＮＢにも上りデータが送信される状態を解除する方法を開示する。
【０１６４】
前述と同様に、ＳＰＳの設定が解除された場合、該状態を解除することを予め規格などで静的に決めておく。これによって、前述と同様の効果を得ることができる。
【０１６５】
あるいは、設定されたＤＲＡＴの閾値を有効とする情報を設け、該情報を、ＳＰＳの設定を無効にするシグナリングに含めてＵＥに通知するとよい。あるいは、再度設定するＤＲＡＴの閾値を、ＳＰＳの設定を無効にするシグナリングに含めてＵＥに通知するとよい。あるいは、ＳＰＳの設定を無効にするシグナリングによって該状態を解除することとしてもよい。これによって、ＤＲＡＴの閾値を従来の値に戻すことができ、前述と同様の効果を得ることができる。
【０１６６】
あるいは、設定されたＤＲＡＴの閾値を有効とする情報を設け、該情報を、ＳＰＳデアクティベートに含めてＵＥに通知するとよい。あるいは、再度設定するＤＲＡＴの閾値を、ＳＰＳデアクティベートに含めてＵＥに通知するとよい。あるいは、ＳＰＳデアクティベートによって該状態を解除することとしてもよい。これによって、ＤＲＡＴの閾値を従来の値に戻すことができ、前述と同様の効果を得ることができる。
【０１６７】
以上に開示した方法を用いることによって、ＳＰＳが設定された場合、１ｓｔ−ｅＮＢにも、２ｎｄ−ｅＮＢにも上りデータが送信されることになるので、パディング送信も可能となる。したがって、インプリシットリリースが可能となる。
【０１６８】
これによって、ｅＮＢとＵＥとの間で不安定な動作が生じ、ひいては誤動作を引き起こす可能性を低減させることができる。
【０１６９】
図１２は、ＳＰＳが設定された場合に、ＤＲＡＴの閾値に０を設定した場合を説明する図である。上りデータのデータ量がＤＲＡＴの閾値よりも小さい場合には１ｓｔ−ｅＮＢのみに送信し、上りデータのデータ量がＤＲＡＴの閾値以上の場合には１ｓｔ−ｅＮＢおよび２ｎｄ−ｅＮＢの両ｅＮＢに送信する場合である。１ｓｔ−ｅＮＢをＭｅＮＢとし、２ｎｄ−ｅＮＢをＳｅＮＢとする。ＭｅＮＢとＳｅＮＢとにそれぞれＳＰＳが設定された場合を示している。
【０１７０】
図１２は、図１１と類似しているので、主として異なる部分について説明する。
【０１７１】
ＤＲＡＴの閾値１１０３は、０に設定される。
【０１７２】
ステップＳＴ１００８において、ＳｅＮＢは、ＵＥに、ＰＤＣＣＨを用いて、上りＳＰＳの上りグラントでアクティベートを通知する。該アクティベートの通知に、ＤＲＡＴの閾値に０を設定する情報を含ませる。ＵＥは、該ＰＤＣＣＨを受信して、上りＳＰＳをアクティベートするとともに、ＤＲＡＴの閾値を０に設定する。
【０１７３】
ステップＳＴ１００９において、ＵＥは、ＳｅＮＢに対して設定された上りＳＰＳリソースで、上りデータをＳｅＮＢに送信する。ＤＲＡＴの閾値を０としたので、ＵＥで発生した上り送信データは、ＳｅＮＢに送信することが可能となる。図示はしていないが、ＭｅＮＢにもデータを送信することが可能となる。したがって、ＵＥで発生した上りデータの一部はＭｅＮＢに送信され、残りの上りデータがＳｅＮＢに送信される。
【０１７４】
ステップＳＴ１１０１において、ＳｅＮＢに対して設定された上りＳＰＳリソースで、ＵＥで上りデータが発生しなかった場合を考える。この場合、ＤＲＡＴの閾値が０であるので、たとえ上りデータの発生が０であったとしても、ＳｅＮＢに送信することが可能となる。したがって、パディング送信も可能と判断し、ＳｅＮＢに、パディング送信を行う。このように、ＳｅＮＢとＵＥとの間で上り送信データが無いときも、パディング送信が可能となる。
【０１７５】
ステップＳＴ１１０１からステップＳＴ１１０２において、ＳｅＮＢに対して設定された上りＳＰＳリソースで、連続してＵＥで上りデータが発生しない場合、同様に、上りデータのデータ量がＤＲＡＴの閾値以上となるので、ＵＥは、ＳｅＮＢに上りデータを送信することが可能となる。したがって、パディング送信が可能と判断し、パディング送信を行う。
【０１７６】
リリース前空送信回数として設定される回数連続して上り送信データが発生せず、パディング送信が行われた場合、ステップＳＴ１０１２において、ＵＥは、ＳＰＳリソースをクリアし、ｅＮＢもＳＰＳリソースをリリースする。
【０１７７】
これによって、ｅＮＢとＵＥとの間で、インプリシットリリースが正常に行われる。
【０１７８】
以上に開示した方法の場合、ＳＰＳリソースが割当てられたタイミングだけでなく、ＳＰＳが設定あるいはアクティベートされたタイミングから、解除あるいはデアクティベートまでの間中、両ｅＮＢに上りデータの送信が可能となる。データが発生することになる。
【０１７９】
したがって、ＳＰＳが設定あるいはアクティベートされたタイミングから、解除あるいはデアクティベートまでの間、ＵＥに発生する上り送信データのデータ量が小さい場合でも、常に２ｎｄ−ｅＮＢにも上りデータの送信を行うことになるので、ＵＥの消費電力は増大してしまう。
【０１８０】
このような問題を解決する方法を開示する。
【０１８１】
ＳＰＳのリソース割当のタイミングのみ、１ｓｔ−ｅＮＢにも、２ｎｄ−ｅＮＢにも上りデータを送信する。ＳＰＳのリソース割当のタイミングに合わせて、１ｓｔ−ｅＮＢにも、２ｎｄ−ｅＮＢにも上りデータを送信する。
【０１８２】
このようにすることによって、２ｎｄ−ｅＮＢに対しても上りデータを送信する期間を短縮することができる。したがって、ＵＥの消費電力の増大を抑制することが可能となる。
【０１８３】
以上のように本実施の形態によれば、ＳｅＮＢが、ＳＰＳを設定される、すなわち周期的に割り当てられる無線リソースを用いて通信端末装置と通信するように設定されると、送信データのデータ量が閾値Ｔｈ以下である場合に、送信データがＭｅＮＢおよびＳｅＮＢに送信されるように、閾値Ｔｈが変更される。例えば、本実施の形態のように、閾値Ｔｈがゼロ（０）に設定される。
【０１８４】
これによって、ＳｅＮＢにおいても、ＳＰＳによる通信を実行することができる。したがって、ＭｅＮＢおよびＳｅＮＢとＵＥとの間の通信動作を安定して行うことができる通信システムを提供することができる。すなわち、上りスプリットベアラでＤＲＡＴが実行された場合にＳＰＳを可能とすることができるので、高速で安定な通信システムを提供することができる。
【０１８５】
閾値Ｔｈの変更は、送信データのデータ量が閾値Ｔｈ未満である場合に行なわれてもよい。具体的には、ＳｅＮＢが、ＳＰＳを設定される、すなわち周期的に割り当てられる無線リソースを用いて通信端末装置と通信するように設定されると、送信データのデータ量が閾値Ｔｈ未満である場合に、送信データがＭｅＮＢおよびＳｅＮＢに送信されるように、閾値Ｔｈが変更されるように構成されてもよい。この場合、例えば、本実施の形態のように、閾値Ｔｈがゼロ（０）に設定される。
【０１８６】
これによって、本実施の形態と同様の効果を得ることができる。具体的には、ＳｅＮＢにおいても、ＳＰＳによる通信を実行することができる。したがって、ＭｅＮＢおよびＳｅＮＢとＵＥとの間の通信動作を安定して行うことができる通信システムを提供することができる。すなわち、上りスプリットベアラでＤＲＡＴが実行された場合にＳＰＳを可能とすることができるので、高速で安定な通信システムを提供することができる。
【０１８７】
実施の形態２．
実施の形態１で開示した方法を用いた場合、ＤＲＡＴの閾値を実質的に設定できないことになる。したがってＵＥの消費電力が増大することとなる。
【０１８８】
また、ＤＲＡＴの閾値は、ＵＥにおいて、ＰＤＣＰからＲＬＣ／ＭＡＣへの上り送信データの分配時に用いられる。したがって、設定されたＳＰＳのリソース割当タイミングに合わせて両ｅＮＢに上りデータを送信するには、上り送信データの分配のときに、ＳＰＳのタイミングに合わせた細かい時間管理が必要となる。
【０１８９】
このような場合、上り送信データの発生タイミングの変動、およびＰＤＣＰの処理時間の変動などによって、誤動作が生じる可能性がある。
【０１９０】
したがって、実施の形態１に記載した問題を解決するために、本実施の形態では、実施の形態１で開示した方法とは異なる方法を開示する。
【０１９１】
２ｎｄ−ｅＮＢに対してもインプリシットリリースをサポートする。ＵＥは、２ｎｄ−ｅＮＢにＳＰＳが設定された場合、２ｎｄ−ｅＮＢに対してパディング送信を可能とする。ＵＥは、２ｎｄ−ｅＮＢにＳＰＳが設定された場合、設定されたＳＰＳリソースで、上り送信データのデータ量がＤＲＡＴの閾値よりも小さい場合でも、２ｎｄ−ｅＮＢに対してパディング送信を行う。このようにすることによって、インプリシットリリースが可能となる。
【０１９２】
パディング送信は、従来のように、パディングビットおよびパディングＢＳＲの少なくとも一方を含むＭＡＣ  ＰＤＵを送信する。このように、従来と同じパディング送信とすることによって、ｅＮＢおよびＵＥにおける制御を簡易にすることができる。
【０１９３】
また、ＵＥは、２ｎｄ−ｅＮＢに、パディング送信を、リリース前空送信回数として設定される回数連続して行った場合、ＳＰＳの設定をクリアする。２ｎｄ−ｅＮＢもまた、ＵＥからパディング送信を、リリース前空送信回数として設定される回数連続して受信した場合、ＳＰＳリソースをリリースする。
【０１９４】
図１３は、２ｎｄ−ｅＮＢに対してＳＰＳが設定された場合にインプリシットリリースをサポートする方法を説明する図である。１ｓｔ−ｅＮＢをＭｅＮＢとし、２ｎｄ−ｅＮＢをＳｅＮＢとする。ＭｅＮＢ、ＳｅＮＢともにＳＰＳが設定された場合を示している。図１３は、図１１および図１２と類似しているので、主として異なる部分について説明する。
【０１９５】
ＤＲＡＴの閾値１２０１は、任意の値Ｔｈに設定されている。
【０１９６】
ステップＳＴ１００８において、ＳｅＮＢは、ＵＥに、ＰＤＣＣＨを用いて、上りＳＰＳの上りグラントでアクティベートを通知する。通常のアクティベートでよい。
【０１９７】
ステップＳＴ１２０２において、ＳｅＮＢに対して設定された上りＳＰＳリソースで、ＵＥで上りデータが発生しなかった場合を考える。この場合、上りデータのデータ量がＤＲＡＴの閾値よりも小さくなるが、ＳｅＮＢに対してＳＰＳが設定されている場合は、ＳｅＮＢに対してパディング送信が可能であるので、ＵＥは、ＳｅＮＢにパディング送信を行う。
【０１９８】
このようにすることによって、ＳｅＮＢとＵＥとの間で上り送信データが無いときも、パディング送信が可能となる。
【０１９９】
ステップＳＴ１２０２からステップＳＴ１２０３において、ＳｅＮＢに対して設定された上りＳＰＳリソースで、連続してＵＥで上りデータが発生しない場合、同様に、上りデータのデータ量がＤＲＡＴの閾値以上となるので、ＵＥは、ＳｅＮＢに上りデータの送信が可能となる。したがって、パディング送信が可能と判断し、パディング送信を行う。
【０２００】
リリース前空送信回数として設定される回数連続して上り送信データが発生せず、パディング送信が行われた場合、ステップＳＴ１２０４において、ＵＥは、ＳＰＳリソースをクリアし、ｅＮＢもＳＰＳリソースをリリースする。
【０２０１】
これによって、ＳｅＮＢとＵＥとの間で、インプリシットリリースが正常に行われる。
【０２０２】
本実施の形態で開示した方法を用いることによって、ＵＬスプリットベアラにおいて、２ｎｄ−ｅＮＢにＳＰＳが設定された場合に、インプリシットリリースをサポートすることが可能となる。
【０２０３】
ｅＮＢおよびＵＥは、インプリシットリリースによって、ＳＰＳリソースをリリースする判断が可能となり、不安定な動作および誤動作の発生を低減させることができる。
【０２０４】
したがって、ＵＬスプリットベアラにおいて２ｎｄ−ｅＮＢにＳＰＳが設定された場合に、従来のＳＰＳ動作が可能となる。
【０２０５】
また、実施の形態１の方法とは異なり、２ｎｄ−ｅＮＢに対するＤＲＡＴの閾値も任意の値を設定することが可能となる。したがって、ＳＰＳが設定されてから無効になるまでの間に、少量の上り送信データが発生したとしても、上りデータのデータ量がＤＲＡＴの閾値よりも小さい場合は、２ｎｄ−ｅＮＢに上りデータを送信する必要が無くなる。したがって、ＵＥの消費電力の増大を低減させることが可能となる。
【０２０６】
また、ＤＲＡＴの閾値設定において動的に細かい制御が不要になるので、誤動作の発生を抑制することが可能となる。
【０２０７】
以上のように本実施の形態によれば、ＳｅＮＢが、ＳＰＳを設定される、すなわち周期的に割り当てられる無線リソースを用いて通信端末装置と通信するように設定されると、送信データのデータ量が閾値Ｔｈ以下である場合に、送信データをＭｅＮＢに送信するとともに、周期的に割り当てられる無線リソースを用いた通信の終了を表す終了信号をＳｅＮＢに送信するように、具体的にはパディング送信を行うように設定される。
【０２０８】
これによって、ＳｅＮＢでは、ＳＰＳによる通信を終了することができる。したがって、ＭｅＮＢおよびＳｅＮＢとＵＥとの間の通信動作を安定して行うことができる通信システムを提供することができる。すなわち、上りスプリットベアラでＤＲＡＴが実行された場合にＳＰＳを可能とすることができるので、高速で安定な通信システムを提供することができる。
【０２０９】
以上のパディング送信を行うような設定は、送信データのデータ量が閾値Ｔｈ未満である場合に行なわれてもよい。具体的には、ＳｅＮＢが、ＳＰＳを設定される、すなわち周期的に割り当てられる無線リソースを用いて通信端末装置と通信するように設定されると、送信データのデータ量が閾値Ｔｈ未満である場合に、送信データをＭｅＮＢに送信するとともに、周期的に割り当てられる無線リソースを用いた通信の終了を表す終了信号をＳｅＮＢに送信するように、具体的にはパディング送信を行うように設定されるように構成されてもよい。
【０２１０】
これによって、本実施の形態と同様の効果を得ることができる。具体的には、ＳｅＮＢでは、ＳＰＳによる通信を終了することができる。したがって、ＭｅＮＢおよびＳｅＮＢとＵＥとの間の通信動作を安定して行うことができる通信システムを提供することができる。すなわち、上りスプリットベアラでＤＲＡＴが実行された場合にＳＰＳを可能とすることができるので、高速で安定な通信システムを提供することができる。
【０２１１】
実施の形態２  変形例１．
実施の形態２で示した課題を解決するための他の方法を開示する。送信データが無いことを示す情報を設け、ＵＥからｅＮＢへ、上りＬ１／Ｌ２制御信号を用いて該情報を送信する。上りＬ１/Ｌ２制御信号として、例えば、ＰＵＣＣＨを用いる。ＵＥは、設定されたＳＰＳのタイミングで、送信データが無い場合、送信データが無いことを示す情報をＰＵＣＣＨにマッピングして、ｅＮＢに送信する。ｅＮＢは、設定したＳＰＳのタイミングで、ＵＥからのＰＵＣＣＨを受信し、送信データが無いことを示す情報を得ることによって、上り送信データが無いことを認識する。
【０２１２】
ＵＥは、送信データが無いことを示す情報を、リリース前空送信回数として設定される回数連続して送信した場合、ＳＰＳリソースをクリアする。ｅＮＢは、ＵＥから送信データが無いことを示す情報を、リリース前空送信回数として設定される回数連続して受信した場合、ＳＰＳリソースをリリースする。
【０２１３】
このようにすることによって、インプリシットリリースをサポートすることが可能となる。
【０２１４】
送信データが無いことを示す情報をマッピングするＰＵＣＣＨの構成は、ｅＮＢが設定し、予めＵＥに通知される。ＰＵＣＣＨの構成として、周波数軸方向のリソース、時間軸方向のリソース、ＰＵＣＣＨに用いるリファレンスシグナル（Reference Signal：ＲＳ）に用いるシーケンスなどがある。
【０２１５】
周波数軸方向のリソースとしては、例えば、サブキャリア、リソースブロックなどを設定するとよい。最小リソースとしてもよい。最小リソースは、送信における最小単位としてもよい。最小単位は、例えば、１物理リソースブロック（Physical Resource Block；略称：ＰＲＢ）としてもよい。時間軸方向のリソースとしては、ＰＵＣＣＨを送信するタイミングを設定するとよい。ＰＵＣＣＨを送信するタイミングは任意に設定してもよいが、ＳＰＳリソースが設定されたタイミングとしてもよい。これによって、ＵＥおよびｅＮＢにおけるタイミングの制御を簡易にすることが可能となる。
【０２１６】
ＰＵＣＣＨに用いるＲＳ用シーケンスとしては、セル毎あるいはビーム毎としてもよい。ＰＵＣＣＨの周波数軸方向のリソースをＵＥ毎に異ならせることによって、同じＳＰＳリソースタイミングで複数のＵＥのＰＵＣＣＨ送信が発生しても、ｅＮＢは受信することが可能となる。あるいは、ＰＵＣＣＨに用いるＲＳ用シーケンスとしては、ＵＥ個別としてもよい。複数のＵＥに対して、周波数軸方向のリソースおよび時間軸方向のリソースが同じＰＵＣＣＨを共有することができる。同じリソースに複数のＵＥのＰＵＣＣＨが存在しても、ＵＥ個別のＲＳを用いることによって、ｅＮＢは各ＵＥのＰＵＣＣＨを受信することが可能となる。
【０２１７】
ｅＮＢは、ＰＵＣＣＨの構成をＳＰＳの設定に含めてＵＥに通知してもよい。あるいは、ｅＮＢは、ＰＵＣＣＨの構成をＳＰＳアクティベートに含めてＵＥに通知してもよい。
【０２１８】
送信データが無いことを示す情報をマッピングするＰＵＣＣＨの構成として、従来のＰＵＣＣＨの構成を用いてもよい。ＵＥは、設定されたＳＰＳリソースタイミングで上り送信データが無い場合、送信データが無いことを示す情報を従来のＰＵＣＣＨ構成を用いてＰＵＣＣＨにマッピングする。ＵＥは、設定されたＳＰＳリソースのタイミングで該ＰＵＣＣＨを送信する。従来のＰＵＣＣＨの構成を用いることによって、ｅＮＢは、別途送信データが無いことを示す情報をマッピングするＰＵＣＣＨを設定しなくてもよい。
【０２１９】
他の方法として、送信データが無いことを示す情報をＰＵＳＣＨにマッピングするようにしてもよい。ＵＥは、設定されたＳＰＳのタイミングで、送信データが無い場合、送信データが無いことを示す情報をＰＵＳＣＨにマッピングして、ｅＮＢに送信する。
【０２２０】
ｅＮＢは、設定したＳＰＳのタイミングで、ＵＥからのＰＵＳＣＨを受信し、送信データが無いことを示す情報を得ることによって、上り送信データが無いことを認識する。
【０２２１】
既にＳＰＳのタイミングにおいてＳＰＳリソースが設定されている。ＳＰＳリソースとして、上りデータの送信のためのリソースが設定される。上りデータの送信には、ＰＵＳＣＨが用いられるので、ＰＵＳＣＨのリソースが設定される。
【０２２２】
既にＵＥは、ｅＮＢから設定されたＳＰＳのためのＰＵＳＣＨリソースに対する上りグラントを得ている。したがって、ＵＥは、設定されたＳＰＳのためのＰＵＳＣＨ送信用のリソースを使用することが可能である。
【０２２３】
既にＳＰＳのタイミングで設定されているＳＰＳのためのＰＵＳＣＨリソースを用いることによって、ＰＵＣＣＨの構成を別途設定する必要が無くなる。これによって、リソースの使用効率の向上およびシグナリング負荷の低減が可能となる。
【０２２４】
送信データが無いことを示す情報を送信するためのＰＵＳＣＨのリソースは、ＳＰＳのタイミングで設定されているＳＰＳのためのＰＵＳＣＨリソースの一部または全部であってもよい。
【０２２５】
ＰＵＳＣＨに用いるＲＳ用シーケンスは、前述のＰＵＣＣＨで送信する場合の方法を適用するとよい。
【０２２６】
他の方法として、ＳＲＳ（Sounding Reference Signal）を用いて送信データが無いことを示すようにしてもよい。送信データが無いことを示す特定のＳＲＳリソースを設定する。時間軸上の最小リソースは、１シンボルとしてもよい。ｅＮＢは、該ＳＲＳリソースの設定をＵＥに通知する。ＵＥは、設定されたＳＰＳのタイミングで送信データが無い場合、該ＳＲＳリソースを用いてＳＲＳを送信する。ｅＮＢは、ＳＰＳのタイミングにおいて該ＳＲＳリソースでＵＥからのＳＲＳを受信した場合、送信データが無いことを認識できる。
【０２２７】
ＳＲＳに用いるＲＳ用シーケンスは、前述のＰＵＣＣＨで送信する場合の方法を適用するとよい。
【０２２８】
他の方法として、送信データが無いことを示すＲＳのシーケンスを設けて、ＰＵＣＣＨあるいはＰＵＳＣＨあるいはＳＲＳのＲＳに該シーケンスを用いてもよい。ＰＵＣＣＨ、ＰＵＳＣＨ、ＳＲＳのいずれを使用するかは予め静的に決めておいてもよいし、ｅＮＢからＵＥへ通知してもよい。この場合、該チャネルあるいは信号のためのリソースは、ＵＥ個別に設定しておくとよい。
【０２２９】
ＵＥは、設定されたＳＰＳのタイミングで送信データが無い場合、該ＲＳシーケンスを用いた予め定めるチャネルあるいは信号を送信する。ｅＮＢは、ＳＰＳのタイミングにおいて予め定めるチャネルあるいは信号を受信した場合、送信データが無いことを認識できる。
【０２３０】
本変形例で開示した方法を用いることによって、送信に必要となる無線リソースを最小限に限定することが可能となる。したがって、最小限のリソースで送信できるので、ＵＥの消費電力の増大をさらに低減することができる。
【０２３１】
また、本変形例で開示した方法を、２ｎｄ−ｅＮＢに設定されたＳＰＳのタイミングにおいて送信データが無い場合のみに用いてもよい。他に設定されたＳＰＳについては、通常のパディング送信を用いるとよい。
【０２３２】
実施の形態３．
ＵＬスプリットベアラにおいて、２ｎｄ−ｅＮＢに対して設定されたＳＰＳのタイミングで、ＤＲＡＴの閾値よりも小さいデータ量の上り送信データが発生する場合がある。
【０２３３】
実施の形態２あるいは実施の形態２の変形例１で開示した方法を適用した場合、以下のような問題が生じる。
【０２３４】
ＵＥにおいて、２ｎｄ−ｅＮＢに対して設定されたＳＰＳのタイミングで、ＤＲＡＴの閾値よりも小さいデータ量の上り送信データが発生する場合、該上り送信データがあるにも関わらず、２ｎｄ−ｅＮＢに対しては上り送信データが発生しないことになる。したがって、ＵＥは、２ｎｄ−ｅＮＢに対してパディング送信を行うことになる。このようなパディング送信が、リリース前空送信回数として設定される回数連続して発生すると、インプリシットリリースによって、ＵＥおよび２ｎｄ−ｅＮＢで、ＳＰＳの設定が無効となり、ＳＰＳリソースがリリースされてしまう。つまり、設定されたＳＰＳのタイミングで上り送信データがあるにも関わらず、インプリシットリリースによって、ＳＰＳリソースがリリースされてしまう場合が発生する。
【０２３５】
インプリシットリリースによってＳＰＳリソースがリリースされた後、ＵＥにおいて、２ｎｄ−ｅＮＢに対して設定されていたＳＰＳのタイミングで、ＤＲＡＴの閾値以上の上り送信データが発生する場合、２ｎｄ−ｅＮＢに設定されたＳＰＳが適用されなくなってしまう。
【０２３６】
ＵＥは、設定されていたＳＰＳのタイミングで上り送信データが発生しても、該ＳＰＳリソースを用いて上りデータの送信を行うことができなくなってしまう。
【０２３７】
このように、ＵＥは、設定されたＳＰＳのタイミングで上り送信データが発生し、上りデータを送信しているにも関わらず、２ｎｄ−ｅＮＢに対するＳＰＳリソースがリリースされてしまうので、２ｎｄ−ｅＮＢに対しては、設定されたＳＰＳリソースを用いて上りデータの送信を行うことができなくなってしまうのである。
【０２３８】
図１４は、ＤＲＡＴの閾値よりも小さいデータ量の上り送信データが発生する場合を説明する図である。実施の形態２で開示した、２ｎｄ−ｅＮＢに対してＳＰＳが設定された場合にインプリシットリリースをサポートする方法を実行した場合について示している。
【０２３９】
１ｓｔ−ｅＮＢをＭｅＮＢとし、２ｎｄ−ｅＮＢをＳｅＮＢとする。ＭｅＮＢ、ＳｅＮＢともにＳＰＳが設定された場合を示している。図１４は、図１３と類似しているので、主として異なる部分について説明する。
【０２４０】
ステップＳＴ１２０２において、ＳｅＮＢに対して設定された上りＳＰＳリソースで、ＵＥでＤＲＡＴの閾値よりも小さいデータ量の上りデータが発生した場合を考える。
【０２４１】
この場合、ステップＳＴ１３０１において、ＵＥは、ＭｅＮＢに上りデータを送信する。
【０２４２】
ＳｅＮＢに対しては上り送信データが発生しないので、ステップＳＴ１２０２において、ＵＥは、ＳｅＮＢに、パディング送信を行うことになる。
【０２４３】
ステップＳＴ１２０２からステップＳＴ１２０３において、ＳｅＮＢに対して設定された上りＳＰＳリソースで、連続してＵＥでＤＲＡＴ閾値よりも小さいデータ量の上りデータが発生した場合、同様に、ステップＳＴ１３０１からステップＳＴ１３０２において、ＵＥは、ＭｅＮＢに上りデータの送信を行う。ＵＥは、ＳｅＮＢに対してはパディング送信を行う。
【０２４４】
ＳｅＮＢに対して、リリース前空送信回数として設定される回数連続して上り送信データが発生せず、パディング送信が行われた場合、インプリシットリリースによって、ステップＳＴ１２０４において、ＵＥは、ＳＰＳリソースをクリアし、ｅＮＢもＳＰＳリソースをリリースする。
【０２４５】
しかし、インプリシットリリース後、ステップＳＴ１３０３において、ＳｅＮＢに対して設定されていた上りＳＰＳリソースで、ＵＥでＤＲＡＴの閾値以上のデータ量の上りデータが発生した場合を考える。
【０２４６】
この場合、図示はしていないが、ＵＥは、ＭｅＮＢに上りデータを送信する。
【０２４７】
ＳｅＮＢに対しても上り送信データが発生するので、ステップＳＴ１３０３において、ＵＥは、ＳｅＮＢに上りデータの送信を行うことになる。しかし、既にＳＰＳリソースはリリースされているので、該上りデータの送信にＳＰＳリソースを用いることができない。
【０２４８】
このような場合、ＵＥは、ＳｅＮＢに対する上り送信データ用のリソースが割り当てられていないので、新たにスケジューリング要求（Scheduling Request：ＳＲ）信号の送信から開始しなければならない。ＵＥは、ＳｅＮＢにＳＲ信号を送信し、ＳｅＮＢからのＵＬグラントを受信しなければならい。
【０２４９】
このことは、ＵＥの消費電力の増大、ＰＤＣＣＨリソースの増大によるリソースの使用効率の低下、およびデータ送信の遅延の増大を引き起こす。本実施の形態では、このような課題を解決する方法を開示する。
【０２５０】
上りスプリットベアラが設定されている場合、上りＳＰＳの設定を無効にしない。上りスプリットベアラが設定されている場合、上りＳＰＳリソースをリリースしないとしてもよい。上りスプリットベアラが設定されている場合、インプリシットリリースを行わないとしてもよい。
【０２５１】
ＵＥは、上りスプリットベアラが設定されている場合において、２ｎｄ−ｅＮＢに上りＳＰＳが設定された場合、たとえリリース前空送信回数として設定される回数連続してパディング送信を行ったとしても、設定されたＳＰＳリソースをクリアしない。２ｎｄ−ｅＮＢは、たとえリリース前空送信回数として設定される回数連続してパディング送信を受信したとしても、設定されたＳＰＳリソースをリリースしない。
【０２５２】
上りＳＰＳの設定を無効にしないようにする方法の具体例として、以下の（１），（２）の２つを開示する。
【０２５３】
（１）予め規格などで静的に決めておく。
【０２５４】
（２）上りＳＰＳの設定を無効にしないことを示す情報を設けて、ｅＮＢからＵＥに通知する。
【０２５５】
前述の（１）の方法では、上りスプリットベアラが設定されている場合は、上りＳＰＳの設定を無効にしないことを、静的に決めておく。これを予め規格などで決めておくことによって、ｅＮＢとＵＥとで認識することが可能となるので、整合のとれた動作が可能となり、誤動作を低減させることができる。
【０２５６】
前述の（２）の方法では、上りＳＰＳの設定を無効にしないことを示す情報をｅＮＢからＵＥに通知することによって、上りスプリットベアラが設定されている場合に上りＳＰＳの設定を無効にしないことを、動的に設定することが可能となる。これによって、通信状況および負荷状況に応じて、柔軟な運用が可能となる。
【０２５７】
前述の（２）の方法における上りＳＰＳの設定を無効にしないことを示す情報として、前述のＵＬのリリース前空送信回数を用いてもよい。リリース前空送信回数として、ＳＰＳの設定を無効にしないことを示す値を設ける。あるいは、リリース前空送信回数として、無限大を示す値を設ける。既存の値とは別に新たに設けてもよい。
【０２５８】
前述の（２）の方法における上りＳＰＳの設定を無効にしないことを示す情報は、ｅＮＢからＵＥに通知するとよい。通知するｅＮＢは、１ｓｔ−ｅＮＢであってもよいし、２ｎｄ−ｅＮＢであってもよい。例えば、２ｎｄ−ｅＮＢからＵＥに通知するときに、２ｎｄ−ｅＮＢから直接ＵＥに通知してもよいし、２ｎｄ−ｅＮＢから１ｓｔ−ｅＮＢを介してＵＥに通知してもよい。ｅＮＢ間の情報の通知には、Ｘ２シグナリングを用いてもよい。あるいは、ＭＭＥを介してＳ１シグナリングを用いてもよい。
【０２５９】
該情報をｅＮＢからＵＥに通知するためのシグナリング方法の具体例として、以下の（１）〜（３）の３つを開示する。
【０２６０】
（１）ＲＲＣシグナリング。例えば、ＳＰＳ構成の設定のためのシグナリングに含めて通知してもよい。
【０２６１】
（２）ＭＡＣシグナリング。例えば、該情報を含むＭＡＣ  ＣＥ（Control Element）を設けて、ＭＡＣシグナリングによって通知してもよい。
【０２６２】
（３）Ｌ１／Ｌ２シグナリング。例えば、ＰＤＣＣＨあるいはＥＰＤＣＣＨ。例えば、ＳＰＳアクティベートに含めて通知してもよい。
【０２６３】
このような方法で、ｅＮＢは、上りＳＰＳの設定を無効にしないことを示す情報を、ＵＥに通知する。該情報を受信したＵＥは、上りＳＰＳの設定を無効にしない。ＵＥは、上りスプリットベアラが設定されている場合に、２ｎｄ−ｅＮＢに上りＳＰＳが設定された場合、たとえリリース前空送信回数として設定される回数連続してパディング送信を行ったとしても、インプリシットリリースを行わず、設定されたＳＰＳリソースをクリアしない。
【０２６４】
図１５は、上りＳＰＳの設定を無効にしないようにする方法を説明する図である。上りＳＰＳの設定を無効にしないことを示す情報をＳＰＳアクティベートに含めて通知する方法の場合を示している。
【０２６５】
１ｓｔ−ｅＮＢをＭｅＮＢとし、２ｎｄ−ｅＮＢをＳｅＮＢとする。ＭｅＮＢ、ＳｅＮＢともにＳＰＳが設定された場合を示している。図１５は、図１４と類似しているので、主として異なる部分について説明する。
【０２６６】
ステップＳＴ１００８において、ＳｅＮＢは、ＵＥに、ＰＤＣＣＨを用いて、上りＳＰＳの上りグラントでアクティベートを通知する。該アクティベートに、上りＳＰＳの設定を無効にしないことを示す情報を含める。
【０２６７】
ＳｅＮＢからＳＰＳのアクティベートを受信したＵＥは、設定されたリソースでＳＰＳを実行するとともに、上りＳＰＳの設定を無効にしない。たとえ、ＵＥがＳｅＮＢに対して予め定める回数パディング送信を行ったとしても、ｅＮＢ、ＵＥともにインプリシットリリースを行わず、ＳＰＳの設定を無効にしないように設定する。
【０２６８】
ステップＳＴ１２０２において、ＳｅＮＢに対して設定されたＳＰＳのタイミングで、ＵＥでＤＲＡＴの閾値よりも小さいデータ量の上りデータが発生した場合を考える。
【０２６９】
この場合、ステップＳＴ１３０１において、ＵＥは、ＭｅＮＢに上りデータを送信する。
【０２７０】
ＳｅＮＢに対しては上り送信データが発生しないので、ステップＳＴ１２０２において、ＵＥは、ＳｅＮＢに対して、パディング送信を行うことになる。
【０２７１】
ステップＳＴ１２０２からステップＳＴ１２０３において、ＳｅＮＢに対して設定されたＳＰＳのタイミングで、連続してＵＥでＤＲＡＴ閾値よりも小さいデータ量の上りデータが発生しない場合、同様に、ステップＳＴ１３０１からステップＳＴ１３０２において、ＵＥは、ＭｅＮＢに上りデータの送信を行う。ＵＥは、ＳｅＮＢに対しては、パディング送信を行う。
【０２７２】
ＳｅＮＢに対して、リリース前空送信回数として設定される回数連続して上り送信データが発生せず、パディング送信が行われた場合でも、上りＳＰＳの設定を無効にしない設定に従い、ステップＳＴ１２０４において、ＵＥは、ＳＰＳリソースをクリアしない。ｅＮＢもＳＰＳリソースをリリースしない。ステップＳＴ１２０４において、インプリシットリリースが行われず、ＳＰＳリソースがリリースされない。
【０２７３】
したがって、ＳｅＮＢに対して、リリース前空送信回数として設定される回数連続してパディング送信が行われた後、ステップＳＴ１２０４において、ＳｅＮＢに対して設定されたＳＰＳのタイミングで、ＵＥでＤＲＡＴの閾値以上のデータ量の上りデータが発生した場合、ステップＳＴ１４０１において、ＵＥは、ＳｅＮＢに対して、設定されているＳＰＳリソースで、上りデータの送信を行うことが可能となる。
【０２７４】
本実施の形態で開示した方法を用いることによって、設定されたＳＰＳのタイミングで上り送信データが発生し、ＵＥが上りデータを送信しているにも関わらず、２ｎｄ−ｅＮＢに対するＳＰＳリソースがリリースされてしまうということを無くすことができる。したがって、設定されたＳＰＳリソースで上りデータが発生した場合に２ｎｄ−ｅＮＢに送信を行うことができず、ＳＲ信号の送信からの開始を余儀なくされる状況を無くすことが可能となる。
【０２７５】
これによって、ＵＥの消費電力の増大、ＰＤＣＣＨリソースの増大によるリソースの使用効率の低下、およびデータ送信の遅延の増大を抑制することが可能となる。
【０２７６】
以上のように本実施の形態では、ＵＥは、上りＳＰＳの設定を無効にしないことを示す情報を受信すると、ＳＰＳで割り当てられる無線リソースであるＳＰＳリソースのリリースを停止する。上りＳＰＳの設定を無効にしないことを示す情報は、ＳＰＳリソースのリリースを停止することを示すリリース停止情報に相当する。すなわち、ＵＥは、リリース停止情報を受信すると、ＳＰＳリソースのリリースを停止する。
【０２７７】
これによって、設定されたＳＰＳリソースで上りデータが発生した場合にＳｅＮＢに送信を行うことができなくなることを防ぎ、ＳＲ信号の送信からの開始を余儀なくされる状況を無くすことができる。したがって、ＵＥの消費電力の増大、ＰＤＣＣＨリソースの増大によるリソースの使用効率の低下、およびデータ送信の遅延の増大を抑制することが可能となる。
【０２７８】
実施の形態４．
実施の形態３で開示した方法では、設定されたＳＰＳのタイミングで、実際に送信データが無い場合でも、インプリシットリリースが行われないことになり、ＳＰＳリソースはリリースされなくなる。
【０２７９】
ＳＰＳリソースがリリースされないと、２ｎｄ−ｅＮＢは、ＳＰＳのタイミングでＳＰＳリソースをＵＥに対して割当て続けることになる。
【０２８０】
このように、送信データが無くなったＵＥに対して、ＰＵＳＣＨリソースを割当て続けることは無駄であり、リソースの使用効率を低下させる。本実施の形態では、このような課題を解決する方法を開示する。
【０２８１】
ＳＰＳの設定を無効にしない期間のタイマを設ける。ｅＮＢは、ＳＰＳの設定を無効にしない期間を設定してＵＥに通知する。
【０２８２】
例えば、上りＳＰＳの設定を無効にしない設定が行われた場合に、インプリシットリリースの機能を開始するために、前述のタイマを用いる。ｅＮＢは、ＵＥに、ＳＰＳの設定を無効にしない期間を、上りＳＰＳの設定を無効にしないことを示す情報とともに通知する。ＵＥは、上りＳＰＳの設定を無効にしないことが設定されると、該タイマを開始して、ＳＰＳの設定を無効にしない期間が経過した場合、インプリシットリリースを開始してタイマを停止する。このようにすることによって、パディング送信が、リリース前空送信回数として設定される回数連続して行われた場合に、インプリシットリリースが行われ、上りＳＰＳリソースがリリースされるようになる。
【０２８３】
ＳＰＳの設定を無効にしない期間としては、時間、無線フレーム数、サブフレーム数、スロット数、およびシンボル数であってもよい。ＳＰＳの設定を無効にしない期間は、設定されたＳＰＳのタイミング間隔の正の整数倍としてもよい。ＳＰＳの設定を無効にしない期間は、予め規格などで静的に決められてもよい。
【０２８４】
他の方法として、パディング送信回数が予め定める回数続いた場合にインプリシットリリースを開始する、としてもよい。本実施の形態で開示したパディング送信の連続する予め定める回数を、従来のリリース前空送信回数と異ならせるとよい。
【０２８５】
具体的には、パディング送信の連続する予め定める回数を表すパラメータを「implicitReleaseAfter_Ｂ」とし、従来のリリース前空送信回数を表すパラメータを「implicitReleaseAfter」としたとき、implicitReleaseAfter_B＞implicitReleaseAfterとするとよい。
【０２８６】
あるいは、implicitReleaseAfter_B＝ｎ（ｎは正の整数）×implicitReleaseAfterとしてもよい。
【０２８７】
これらのようにすることによって、上り送信データが無い期間に応じて、インプリシットリリースを開始することが可能となる。上り送信データの発生状況に応じて、上りＳＰＳの設定を無効にする期間を設定することが可能となる。
【０２８８】
本実施の形態で開示した方法を用いることによって、上りＳＰＳの設定を無効にしないことが設定されたまま、常にインプリシットリリースが行われない状態を無くすことができる。
【０２８９】
したがって、長期にわたるＳＰＳリソースのリザーブが不要となり、ＰＵＳＣＨリソースの無駄を削減することが可能となる。これによって、リソースの使用効率の向上が可能となる。
【０２９０】
実施の形態４  変形例１．
実施の形態４で示した課題を解決する他の方法を開示する。インプリシットリリースを開始することを示す情報を設けて、ｅＮＢからＵＥに通知する。例えば、上りＳＰＳの設定を無効にしないことが設定されている状態において、インプリシットリリースを開始することを示す情報を、ｅＮＢからＵＥに通知する。該情報の通知によって、ｅＮＢ、ＵＥともに、インプリシットリリースを再開する。このようにすることによって、ＵＥからｅＮＢに、パディング送信が、リリース前空送信回数として設定される回数連続して発生した場合に、インプリシットリリースが実行され、上りＳＰＳの設定が無効になる。
【０２９１】
ｅＮＢからＵＥに、インプリシットリリースを開始することを示す情報を通知することによって、任意のタイミングでインプリシットリリースを開始することが可能となる。これによって、通信状況および負荷状況に応じて柔軟な運用が可能となる。
【０２９２】
インプリシットリリースを開始することを示す情報として、前述のＵＬのリリース前空送信回数を用いてもよい。リリース前空送信回数として、既存の値を設定するとよい。リリース前空送信回数が設定された場合に、インプリシットリリースを開始する。
【０２９３】
インプリシットリリースを開始することを示す情報は、ｅＮＢからＵＥに通知するとよい。通知するｅＮＢは、１ｓｔ−ｅＮＢであってもよいし、２ｎｄ−ｅＮＢであってもよい。例えば、２ｎｄ−ｅＮＢからＵＥに通知するときに、２ｎｄ−ｅＮＢから直接ＵＥに通知してもよいし、２ｎｄ−ｅＮＢから１ｓｔ−ｅＮＢを介してＵＥに通知してもよい。ｅＮＢ間の情報の通知にはＸ２シグナリングを用いてもよい。あるいは、ＭＭＥを介してＳ１シグナリングを用いてもよい。
【０２９４】
インプリシットリリースを開始することを示す情報をｅＮＢからＵＥへ通知するためのシグナリング方法の具体例として、以下の（１）〜（３）の３つを開示する。
【０２９５】
（１）ＲＲＣシグナリング。
【０２９６】
（２）ＭＡＣシグナリング。例えば、インプリシットリリースを開始することを示す情報を含むＭＡＣ  ＣＥを設けて、ＭＡＣシグナリングによって通知してもよい。
【０２９７】
（３）Ｌ１／Ｌ２シグナリング。例えば、ＰＤＣＣＨあるいはＥＰＤＣＣＨで通知してもよい。
【０２９８】
本変形例で開示した方法を用いることによって、実施の形態４で開示した方法と同様の効果を得ることができる。
【０２９９】
また、任意のタイミングでインプリシットリリースを開始することが可能となるので、ＳＰＳリソースの柔軟な設定が可能となる。したがって、より一層ＰＵＳＣＨリソースの使用効率の向上が可能となる。
【０３００】
以上のように本変形例では、ＵＥは、インプリシットリリースを開始することを示す情報を受信すると、ＳＰＳリソースのリリースを再開する。インプリシットリリースを開始することを示す情報は、ＳＰＳリリースを再開することを示すリリース再開情報に相当する。すなわち、ＵＥは、リリース再開情報を受信すると、ＳＰＳリソースのリリースを再開する。
【０３０１】
これによって、実施の形態４と同様の効果を得ることができる。具体的には、上りＳＰＳの設定を無効にしないことが設定されたまま、常にインプリシットリリースが行われない状態を無くすことができる。これによって、長期にわたるＳＰＳリソースのリザーブが不要となるので、ＰＵＳＣＨリソースの無駄を削減することが可能となる。したがって、リソースの使用効率の向上が可能となる。
【０３０２】
実施の形態４  変形例２．
実施の形態４で示した課題を解決する他の方法を開示する。上りＳＰＳの設定を無効にすることを示す情報を設けて、ｅＮＢからＵＥに通知する。例えば、上りＳＰＳの設定を無効にしないことが設定されている状態において、上りＳＰＳの設定を無効にすることを示す情報を、ｅＮＢからＵＥに通知する。ｅＮＢは、上りＳＰＳの設定を無効にするか否かを判断する。ｅＮＢが上りＳＰＳの設定を無効にすることを決定した場合、ｅＮＢは、ＵＥに、上りＳＰＳの設定を無効にすることを示す情報を通知し、上りＳＰＳの設定を無効にする。ＵＥは、ｅＮＢから上りＳＰＳの設定を無効にすることを示す情報を受信することによって、上りＳＰＳの設定を無効にする。このとき、インプリシットリリースを行わずに、上りＳＰＳの設定を無効にする。
【０３０３】
ｅＮＢからＵＥに、上りＳＰＳの設定を無効にすることを示す情報を通知することによって、任意のタイミングで上りＳＰＳの設定を無効にすることが可能となる。これによって、通信状況および負荷状況に応じて柔軟な運用が可能となる。
【０３０４】
上りＳＰＳの設定を無効にすることを示す情報として、前述のＵＬのリリース前空送信回数を用いてもよい。リリース前空送信回数として、既存の値を設定するとよい。リリース前空送信回数が設定された場合に、上りＳＰＳの設定を無効にすることを示すようにするとよい。
【０３０５】
上りＳＰＳの設定を無効にすることを示す情報は、ｅＮＢからＵＥに通知するとよい。通知するｅＮＢは、１ｓｔ−ｅＮＢであってもよいし、２ｎｄ−ｅＮＢであってもよい。例えば、２ｎｄ−ｅＮＢからＵＥに通知するときに、２ｎｄ−ｅＮＢから直接ＵＥに通知してもよいし、２ｎｄ−ｅＮＢから１ｓｔ−ｅＮＢを介してＵＥに通知してもよい。ｅＮＢ間の情報の通知にはＸ２シグナリングを用いてもよい。あるいは、ＭＭＥを介してＳ１シグナリングを用いてもよい。
【０３０６】
上りＳＰＳの設定を無効にすることを示す情報をｅＮＢからＵＥへ通知するためのシグナリング方法の具体例として、以下の（１）〜（３）の３つを開示する。
【０３０７】
（１）ＲＲＣシグナリング。
【０３０８】
（２）ＭＡＣシグナリング。例えば、上りＳＰＳの設定を無効にすることを示す情報を含むＭＡＣ  ＣＥを設けて、ＭＡＣシグナリングによって通知してもよい。
【０３０９】
（３）Ｌ１／Ｌ２シグナリング。例えば、ＰＤＣＣＨあるいはＥＰＤＣＣＨで通知してもよい。
【０３１０】
図１６は、上りＳＰＳの設定を無効にすることを示す情報を用いる方法を説明する図である。１ｓｔ−ｅＮＢをＭｅＮＢとし、２ｎｄ−ｅＮＢをＳｅＮＢとする。ＭｅＮＢ、ＳｅＮＢともにＳＰＳが設定された場合を示している。図１６は、図１５と類似しているので、主として異なる部分について説明する。
【０３１１】
ステップＳＴ１００８において、ＳｅＮＢは、ＵＥに、ＰＤＣＣＨを用いて、上りＳＰＳの上りグラントでアクティベートを通知する。該アクティベートに、上りＳＰＳの設定を無効にしないことを示す情報を含める。
【０３１２】
ステップＳＴ１２０２からステップＳＴ１２０３において、ＳｅＮＢに対して、リリース前空送信回数として設定される回数連続して上り送信データが発生せず、パディング送信が行われた場合でも、上りＳＰＳの設定を無効にしない設定に従い、ＵＥは、ＳＰＳリソースをクリアしない。ｅＮＢもＳＰＳリソースをリリースしない。インプリシットリリースが行われず、ＳＰＳリソースがリリースされない。
【０３１３】
ステップＳＴ１５０１において、ＳｅＮＢは、上りＳＰＳの設定を無効にすることを示す情報を設定し、ＵＥに通知する。ｅＮＢは、上りＳＰＳの設定を無効にすることを示す情報の通知によって、上りＳＰＳの設定を無効にし、ＵＥは、上りＳＰＳの設定を無効にすることを示す情報を受信することによって、上りＳＰＳの設定を無効にする。
【０３１４】
上りＳＰＳの設定が無効になるので、以降のＳＰＳのタイミングであるステップＳＴ１２０４では、設定されたＳＰＳリソースがリリースされる。これによって、ｅＮＢは、該ＳＰＳリソースを他のＵＥに対して割当て可能となる。
【０３１５】
ｅＮＢが、上りＳＰＳの設定を無効にするか否かを判断する方法の具体例として、以下の（１）〜（６）の６つを開示する。
【０３１６】
（１）ＳＰＳの設定からの期間。
【０３１７】
（２）ＳＰＳの設定を無効にしないことを設定してからの期間。
【０３１８】
（３）パディング送信の連続受信回数。
【０３１９】
（４）自ｅＮＢにおける負荷量。
【０３２０】
（５）ＵＥとの通信品質。
【０３２１】
（６）１ｓｔ−ｅＮＢに対する上り送信データ発生状況。
【０３２２】
前述の（１）の方法では、上りＳＰＳの設定から予め定める期間が経過した場合に、上りＳＰＳの設定を無効にすると決定する。予め定める期間としては、時間、無線フレーム数、サブフレーム数、スロット数、およびシンボル数であってもよい。予め定める期間は、設定されたＳＰＳのタイミング間隔の正の整数倍としてもよい。
【０３２３】
前述の（２）の方法では、上りＳＰＳの設定を無効にしないことを設定してから予め定める期間が経過した場合に、上りＳＰＳの設定を無効にすると決定する。
【０３２４】
前述の（３）の方法では、パディング送信を予め定める回数連続して受信した場合に、上りＳＰＳの設定を無効にすると決定する。パディング送信を受信する予め定める回数としては、前述のリリース前空送信回数であってもよい。あるいは、リリース前空送信回数よりも大きい値であってもよい。
【０３２５】
前述の（４）の方法では、自ｅＮＢの負荷量を用いて判断する。負荷が予め定める値以上の場合、ＳＰＳの設定を無効にすると決定する。負荷が予め定める値よりも低い場合、ＳＰＳの設定を無効にしないと決定する。負荷が予め定める値よりも高い場合には、ＳＰＳ用に割当てたリソースをリリースして、他のＵＥに割当て可能とすることによって、負荷が高い場合に生じるリソース不足を低減する。
【０３２６】
前述の（５）の方法では、ＵＥとの通信品質を用いて判断する。通信品質が予め定める値よりも小さい場合、ＳＰＳの設定を無効にすると決定する。通信品質が予め定める値以上の場合、ＳＰＳの設定を無効にしないと決定する。通信品質が低い原因が、既に設定したＳＰＳ用のリソースの通信品質が悪いためである場合がある。このような場合、ＳＰＳ用のリソースを再度割当てることによって、通信品質が向上する。したがって、通信品質が低い場合にＳＰＳの設定を無効にして、必要に応じて再度ＳＰＳを設定可能とするとよい。これによって、通信品質の向上を図ることができる。また、通信品質の悪いリソースを早期にリリースすることができるので、リソースの使用効率を向上させることができる。
【０３２７】
前述の（６）の方法では、２ｎｄ−ｅＮＢが、１ｓｔ−ｅＮＢに対する上り送信データの発生状況を認識して、上りＳＰＳの設定を無効にするか否かを決定する。
【０３２８】
２ｎｄ−ｅＮＢが、１ｓｔ−ｅＮＢに対する上り送信データの発生状況を認識する方法の具体例として、以下の（６−１），（６−２）の２つを開示する。
【０３２９】
（６−１）２ｎｄ−ｅＮＢは、１ｓｔ−ｅＮＢから、上り送信データの発生に関する情報を取得する。
【０３３０】
１ｓｔ−ｅＮＢは、２ｎｄ−ｅＮＢに、２ｎｄ−ｅＮＢに対して設定されたＳＰＳのタイミングで、自ｅＮＢ（１ｓｔ−ｅＮＢ）への上り送信データが発生したか否かを通知するとよい。
【０３３１】
２ｎｄ−ｅＮＢは、自ｅＮＢに対して設定されたＳＰＳのタイミングを予め１ｓｔ−ｅＮＢに通知しておくとよい。これによって、１ｓｔ−ｅＮＢは、２ｎｄ−ｅＮＢに対して設定されたＳＰＳのタイミングで、ＵＥからの上り送信データを受信したか否かを認識することができる。１ｓｔ−ｅＮＢは、２ｎｄ−ｅＮＢに対して設定されたＳＰＳのタイミングでＵＥからの上り送信データを受信した場合、上り送信データの発生が有ると判断する。１ｓｔ−ｅＮＢは、前記ＵＥからの上り送信データを受信しなかった場合は、上り送信データの発生が無いと判断する。
【０３３２】
１ｓｔ−ｅＮＢは、自ｅＮＢに対する上り送信データの発生の有無を、２ｎｄ−ｅＮＢに通知する。自ｅＮＢに対する上り送信データの発生が無い場合にのみ、あるいは有る場合にのみ通知してもよい。
【０３３３】
２ｎｄ−ｅＮＢは、自ｅＮＢに対する上り送信データの発生の有無の情報を受信することによって、１ｓｔ−ｅＮＢに対して上り送信データが存在したか否かを判断することが可能となる。２ｎｄ−ｅＮＢは、自ｅＮＢに対する上り送信データの発生の有無の情報を用いて、上りＳＰＳの設定を無効にするか否かを決定する。
【０３３４】
例えば、１ｓｔ−ｅＮＢに対する上り送信データが無い情報を、予め定める回数連続して受信した場合に、上りＳＰＳの設定を無効にすると決定するとよい。
【０３３５】
２ｎｄ−ｅＮＢは、１ｓｔ−ｅＮＢに対して、どのベアラに対して、２ｎｄ−ｅＮＢでＳＰＳを設定したかを通知してもよい。
【０３３６】
１ｓｔ−ｅＮＢは、該ベアラで上り送信データが発生したか否かを判断してもよい。
【０３３７】
これによって、特定のベアラに対してＳＰＳが設定されるような場合に、該ベアラを特定することができるので有効である。
【０３３８】
１ｓｔ−ｅＮＢは、２ｎｄ−ｅＮＢに、上り送信データが発生しなかった場合が連続何回続いたかを表す連続回数を通知してもよい。
【０３３９】
あるいは、２ｎｄ−ｅＮＢが１ｓｔ−ｅＮＢに、予め、該連続回数を通知しておいてもよい。１ｓｔ−ｅＮＢは、２ｎｄ−ｅＮＢに設定されたＳＰＳのタイミングで上り送信データを受信できなかった回数をカウントし、該連続回数になったとき、２ｎｄ−ｅＮＢに、その旨を通知する。
【０３４０】
ｅＮＢ間で、ＳＰＳの設定の無効を要求するメッセージを新たに設けてもよい。例えば、１ｓｔ−ｅＮＢは、２ｎｄ−ｅＮＢに設定されたＳＰＳのタイミングで上り送信データを受信できなかった回数をカウントし、該連続回数になったとき、２ｎｄ−ｅＮＢに、ＳＰＳの設定の無効を要求するメッセージを通知する。
【０３４１】
ＳＰＳの設定の無効を要求するメッセージを受信した２ｎｄ−ｅＮＢは、上りＳＰＳの設定を無効にすると決定してもよい。
【０３４２】
前述の情報をｅＮＢ間で通知するためには、Ｘ２シグナリングあるいはＳ１シグナリングを用いてもよい。Ｘ２シグナリングで通知、あるいはＭＭＥを介してＳ１シグナリングで通知してもよい。
【０３４３】
（６−２）２ｎｄ−ｅＮＢは、ＳＰＳのタイミングの、１ｓｔ−ｅＮＢでの上り電力を測定して検出する。
【０３４４】
１ｓｔ−ｅＮＢは、２ｎｄ−ｅＮＢに、予め、１ｓｔ−ｅＮＢの上りキャリア周波数、帯域幅を通知しておくとよい。２ｎｄ−ｅＮＢに対して設定されたＳＰＳのタイミングで、１ｓｔ−ｅＮＢもＳＰＳを設定している場合、該ＳＰＳリソースを２ｎｄ−ｅＮＢに通知してもよい。
【０３４５】
２ｎｄ−ｅＮＢは、設定したＳＰＳのタイミングにおいて、１ｓｔ−ｅＮＢのキャリア周波数、帯域幅で、上り電力を測定する。前述のように１ｓｔ−ｅＮＢがＳＰＳを設定している場合、該ＳＰＳリソースにおける上り電力を測定してもよい。
【０３４６】
上り電力としては、受信信号強度（Received Signal Strength Indicator；略称：ＲＳＳＩ）、ＩｏＴ（Interference over Thermal noise）などを測定するとよい。
【０３４７】
測定した上り電力が、予め定める閾値よりも高い場合、１ｓｔ−ｅＮＢでデータが送信されたと判断する。予め定める閾値よりも低い場合、１ｓｔ−ｅＮＢでデータが送信されなかったと判断する。
【０３４８】
１ｓt−ｅＮＢでデータが送信されなかったと判断した場合、２ｎｄ−ｅＮＢは、上りＳＰＳの設定を無効にすると決定してもよい。
【０３４９】
本変形例で開示した、ｅＮＢが、上りＳＰＳの設定を無効にするか否かを判断する方法は、実施の形態４の変形例１で開示した、インプリシットリリースを開始することを判断する方法にも適用することができる。
【０３５０】
本変形例で開示した方法を用いることによって、実施の形態４の変形例１で開示した方法と同様の効果を得ることができる。
【０３５１】
また、インプリシットリリースを行う必要がなく、即座に、ＳＰＳの設定を無効にして、ＳＰＳリソースをリリースすることが可能となる。したがって、より一層ＰＵＳＣＨリソースの使用効率の向上が可能となる。
【０３５２】
実施の形態５．
実施の形態４で示した課題を解決する他の方法を開示する。設定されたＳＰＳのタイミングで上り送信データが無い場合のパディング送信と、設定されたＳＰＳのタイミングで上り送信データが有る場合のパディング送信とを異ならせる。
【０３５３】
ＵＥは、上り送信データが無い場合は、上り送信データが無い場合のパディング送信を行う。ＵＥは、上り送信データが有る場合は、上り送信データが有る場合のパディング送信を行う。ｅＮＢは、異なるパディング送信を受信することによって、設定されたＳＰＳのタイミングでＵＥからの上り送信データの有無を判断する。ｅＮＢは、上り送信データが無い場合のパディング送信を受信した場合、上り送信データが無いと判断して、インプリシットリリースを行う。ｅＮＢは、上り送信データが有る場合のパディング送信を受信した場合、上り送信データが有ると判断して、上り送信データが無い場合のパディング送信とはカウントしない。あるいは、上りインプリシットリリースを行わないとしてもよい。
【０３５４】
図１７および図１８は、上り送信データが無い場合のパディング送信と、上り送信データが有る場合のパディング送信とを異ならせる方法を説明する図である。１ｓｔ−ｅＮＢをＭｅＮＢとし、２ｎｄ−ｅＮＢをＳｅＮＢとする。上り送信データのデータ量がＤＲＡＴの閾値（Ｔｈ）以下の場合を示している。ＳｅＮＢにＳＰＳが設定された場合を示している。
【０３５５】
図１７は、ＳｅＮＢに対して設定されたＳＰＳのタイミングで上り送信データが無い場合を示している。図１８は、ＳｅＮＢに対して設定されたＳＰＳＳＰＳのタイミングで上り送信データが有る場合を示している。上り送信データが無い場合のパディング送信を、「パディング（Ａ）送信」とする。上り送信データが有る場合のパディング送信を、「パディング（Ｂ）送信」とする。
【０３５６】
図１７および図１８は、図９と類似しているので、主として異なる部分について説明する。
【０３５７】
図１７に示すように、ＵＥ９０５は、ＳｅＮＢ９０２に対して設定されたＳＰＳのタイミングで、上り送信データが無い場合、矢符「１６０１」に示すように、ＳｅＮＢ９０２に対してパディング（Ａ）送信を行う。上り送信データが無いので、ＵＥ９０５からＭｅＮＢ９０１に上りデータは送信されない。
【０３５８】
図１８に示すように、ＵＥ９０５は、ＳｅＮＢ９０２に対して設定されたＳＰＳのタイミングで、上り送信データが有る場合、矢符「１６０２」に示すように、ＳｅＮＢ９０２に対してパディング（Ｂ）送信を行う。上り送信データが有るので、矢符「１６０３」に示すように、ＵＥ９０５からＭｅＮＢ９０１に上りデータが送信される。
【０３５９】
図１９および図２０は、上り送信データが無い場合のパディング送信と、上り送信データが有る場合のパディング送信とを異ならせる方法を説明する図である。上り送信データが無い場合のパディング送信を、「パディング（Ａ）送信」とする。上り送信データが有る場合のパディング送信を、「パディング（Ｂ）送信」とする。
【０３６０】
１ｓｔ−ｅＮＢをＭｅＮＢとし、２ｎｄ−ｅＮＢをＳｅＮＢとする。ＭｅＮＢ、ＳｅＮＢともにＳＰＳが設定された場合を示している。図１９は図１３と、図２０は図１５と類似しているので、主として異なる部分について説明する。
【０３６１】
図１９は、上り送信データが無い場合のパディング（Ａ）送信について示している。
【０３６２】
ステップＳＴ１００８において、ＳｅＮＢは、ＵＥに、ＰＤＣＣＨを用いて、上りＳＰＳの上りグラントでアクティベートを通知する。
【０３６３】
ＳｅＮＢからＳＰＳのアクティベートを受信したＵＥは、設定されたリソースでＳＰＳを実行する。
【０３６４】
ステップＳＴ１７０１において、ＳｅＮＢに対して設定されたＳＰＳのタイミングで、ＵＥで上りデータが発生しない場合を考える。
【０３６５】
この場合、ステップＳＴ１７０１において、ＵＥは、ＳｅＮＢに対して、上り送信データが無い場合のパディング（Ａ）送信を行う。
【０３６６】
ステップＳＴ１７０１からステップＳＴ１７０２において、ＳｅＮＢに対して設定されたＳＰＳのタイミングで、連続してＵＥで上りデータが発生しない場合、同様に、ＵＥは、ＳｅＮＢに対してパディング（Ａ）送信を行う。
【０３６７】
ＳｅＮＢに対して、リリース前空送信回数として設定される回数連続して上り送信データが発生せず、パディング（Ａ）送信が行われた場合、インプリシットリリースを行う。
【０３６８】
インプリシットリリースによって、ステップＳＴ１２０４において、ｅＮＢは、設定されたＳＰＳリソースをリリースする。ステップＳＴ１２０４において、ＵＥは、設定されたＳＰＳリソースをクリアする。
【０３６９】
図２０は、上り送信データが有る場合のパディング（Ｂ）送信について示している。
【０３７０】
ステップＳＴ１００８において、ＳｅＮＢは、ＵＥに、ＰＤＣＣＨを用いて、上りＳＰＳの上りグラントでアクティベートを通知する。
【０３７１】
ＳｅＮＢからＳＰＳのアクティベートを受信したＵＥは、設定されたリソースでＳＰＳを実行する。
【０３７２】
ステップＳＴ１８０１において、ＳｅＮＢに対して設定されたＳＰＳのタイミングで、ＵＥで上りデータが発生する場合を考える。ここで、発生する上りデータがＤＲＡＴの閾値よりも小さいデータ量のデータであるとする。この場合、ＭｅＮＢに上りデータが送信されるが、ＳｅＮＢには上りデータが送信されない。実施の形態３で開示した方法を適用し、ＳｅＮＢに対して、パディング送信を行うこととする。
【０３７３】
ただし、本実施の形態で開示する方法では、ステップＳＴ１８０１において、ＵＥは、ＳｅＮＢに対して上り送信データが有る場合のパディング（Ｂ）送信を行う。
【０３７４】
ステップＳＴ１８０１からステップＳＴ１８０２において、ＳｅＮＢに対して設定されたＳＰＳのタイミングで、連続してＵＥで上りデータが発生するが、ＤＲＡＴの閾値よりも小さいデータ量のデータで、ＳｅＮＢに対して上りデータが送信されない場合、同様に、ＵＥは、ＳｅＮＢに対してパディング（Ｂ）送信を行う。
【０３７５】
ＳｅＮＢに対して、リリース前空送信回数として設定される回数連続してパディング（Ｂ）送信が行われたとしても、インプリシットリリースを行わない。
【０３７６】
したがって、ステップＳＴ１２０４において、ｅＮＢは、設定されたＳＰＳリソースをリリースせず、ステップＳＴ１２０４において、ＵＥは、設定されたＳＰＳリソースをクリアしない。
【０３７７】
したがって、ＳｅＮＢに対してリリース前空送信回数として設定される回数連続してパディング（Ｂ）送信が行われた後、ステップＳＴ１２０４において、ＳｅＮＢに対して設定されたＳＰＳのタイミングで、ＵＥでＤＲＡＴの閾値以上のデータ量の上りデータが発生した場合、ステップＳＴ１４０１において、ＵＥは、ＳｅＮＢに、設定されているＳＰＳリソースで、上りデータの送信を行うことが可能となる。
【０３７８】
このようにすることによって、上り送信データがあるにも関わらず、インプリシットリリースが行われてしまうことを防ぐことができる。ＵＥでＤＲＡＴの閾値以上の上り送信データが発生した場合に、ＳｅＮＢで設定されたＳＰＳリソースを該上りデータの送信に用いることが可能となる。
【０３７９】
前述のように、上り送信データが無い場合のパディング送信と、上り送信データが有る場合のパディング送信とを異ならせることによって、ｅＮＢは、設定されたＳＰＳのタイミングでＵＥからの上り送信データの有無を判断することが可能となる。
【０３８０】
ｅＮＢは、上り送信データが無い場合のパディング送信を受信した場合、上り送信データが無いと判断することができる。ＵＥからの上り送信データが無いので、ｅＮＢは、インプリシットリリースを行う場合のパディング送信としてカウントすればよい。
【０３８１】
ｅＮＢは、上り送信データが有る場合のパディング送信を受信した場合、上り送信データが有ると判断することができる。ＵＥからの上り送信データが有るので、ｅＮＢは、インプリシットリリースを行う場合のパディング送信としてカウントしないようにする。
【０３８２】
ＵＥからの上り送信データが無い場合のパディング送信のみをカウントすることによって、ＵＥからの上り送信データの発生が実際に無い場合のパディング送信が、リリース前空送信回数として設定される回数連続して行われた場合に、インプリシットリリースを行うことが可能となる。
【０３８３】
上り送信データが無い場合のパディング送信と、上り送信データが有る場合のパディング送信とを異ならせる方法を開示する。
【０３８４】
上り送信データが無い場合のパディング送信については、実施の形態１で示した、従来のパディング送信、すなわち、パディングビットおよびパディングＢＳＲの少なくとも一方を含むＭＡＣ  ＰＤＵを送信する、とするとよい。
【０３８５】
上り送信データが有る場合のパディング送信を、従来のパディング送信と異ならせる。
【０３８６】
上り送信データが有る場合のパディング送信では、ＭＡＣレイヤの処理を従来と異ならせるとよい。従来のパディング送信のＭＡＣ  ＰＤＵと異なるＭＡＣ  ＰＤＵの構成方法の具体例として、以下の（１）〜（３）の３つを開示する。
【０３８７】
（１）新たなＭＡＣ  ＣＥ（Control Element）を設ける。
【０３８８】
（２）パディングビットに特定の値を設定する。
【０３８９】
（３）ヘッダに特定の値を設定する。
【０３９０】
前述の（１）の方法として、上り送信データが有る場合のパディング送信であることを示すＭＡＣ  ＣＥを設けるとよい。
【０３９１】
例えば、送信の有無を示すＭＡＣ  ＣＥを設ける。従来のパディングビットおよびパディングＢＳＲの少なくとも一方に加えて、送信の有無を示すＭＡＣ  ＣＥを含めるとよい。送信が有ることを示すＭＡＣ  ＣＥであってもよい。
【０３９２】
あるいは、パディング送信の種類を示すＭＡＣ  ＣＥを設けてもよい。上り送信データが無い場合のパディング送信か、上り送信データが有る場合のパディング送信かを示すＭＡＣ  ＣＥとするとよい。
【０３９３】
あるいは、インプリシットリリースの有無を示すＭＡＣ  ＣＥを設けてもよい。このＭＡＣ  ＣＥが含まれたパディング送信が、インプリシットリリースを行わせるか、インプリシットリリースを行わせないかを示す。
【０３９４】
このようにすることによって、従来のパディング送信と異ならせることができる。
【０３９５】
前述の（２）の方法として、パディングビットに、上り送信データが有る場合のパディングビットであることを示す特定の値を設定するとよい。従来、パディングビットか否かはヘッダで判断するので、パディングビットは何であってもよかった。ここでは、新たに、上り送信データが有る場合のパディングであることを示す特定の値を設定する。ｅＮＢは、パディングビットを復調することによって、上り送信データが有る場合のパディング送信か否かを認識することができる。
【０３９６】
前述の（３）の方法として、ヘッダに、上り送信データの有無を示す値を設けるとよい。例えば、パディングビットのヘッダに、特定の値として、上り送信データの有無を示す値を付加する。これによって、送信データが有ることを示すヘッダの場合、上り送信データが有る場合のパディング送信であることを認識することができる。
【０３９７】
あるいは、パディングＢＳＲのヘッダに、該特定の値を付加してもよい。これによって、同様の効果を得ることができる。
【０３９８】
あるいは、上り送信データが有る場合のパディング送信であることを示すＭＡＣ  ＣＥのヘッダに、該特定の値を付加してもよい。これによって、ＭＡＣ  ＣＥとヘッダの両方で上り送信データが有るか否かを判断することが可能となる。したがって、誤動作を低減することが可能となる。
【０３９９】
このように、上り送信データが有る場合のパディング送信として、ＭＡＣレイヤの処理を従来と異ならせることによって、従来のパディング送信と異ならせることが可能となる。
【０４００】
他の方法としては、上り送信データが有る場合のパディング送信として、ＰＨＹレイヤの処理を従来と異ならせてもよい。
【０４０１】
例えば、上り送信データが有る場合のパディング送信を行うＰＵＳＣＨに用いるリファレンスシグナルを、従来の上り送信データが無い場合のパディング送信を行うＰＵＳＣＨに用いるリファレンスシグナルと異ならせる。
【０４０２】
あるいは、上り送信データが有る場合のパディング送信を行うＰＵＳＣＨがマッピングされる周波数軸上のリソースおよび時間軸上のリソースの少なくとも一方を、従来の上り送信データが無い場合のパディング送信を行うＰＵＳＣＨがマッピングされる周波数軸上のリソースおよび時間軸上のリソースの少なくとも一方と異ならせてもよい。
【０４０３】
周波数軸上のリソースおよび時間軸上のリソースの少なくとも一方は、ＳＰＳリソースとして割当てられた周波数軸上のリソースおよび時間軸上のリソースの少なくとも一方内で、異ならせてもよい。すなわち、上り送信データが有る場合のパディング送信を行うＰＵＳＣＨがマッピングされる該リソースと、上り送信データが無い場合のパディング送信を行うＰＵＳＣＨがマッピングされる該リソースとが、どちらも、ＳＰＳリソースとして割当てられたリソース内に存在することとなる。これによって、設定されたＳＰＳリソース外のリソースを用いなくて済むので、必要となるリソースの増大を抑制することができる。
【０４０４】
ＳＰＳリソース内で異ならせる方法としては、時間軸上のリソースで異ならせてもよい。例えば、スロット毎で異ならせる。シンボル毎でもよい。あるいは、周波数軸上のリソースで異ならせてもよい。例えば、サブキャリアで異ならせる。リソースブロック毎でもよい。
【０４０５】
ＳＰＳリソースとは別に無線リソース（周波数軸上のリソース−時間軸上のリソース）を設けてもよい。例えば、送信データが無い場合は、ＳＰＳリソースでパディング送信とする。送信データが有る場合は、別に設定された無線リソースでパディング送信とする。これによって、従来のパディング送信に関しては、メカニズムを変える必要がないので、制御が容易になる。別に設定された無線リソースは、複数のＵＥで使用してもよい。具体的には、多重するとよい。例えば、時間多重、周波数多重、およびコード多重などを行うとよい。あるいは、衝突ベースの共用でもよい。ｅＮＢが、ＵＥが送信したＰＵＳＣＨのＲＳを使用してＵＥ毎に分解するとよい。
【０４０６】
他の方法としては、上り送信データの有無で、Ｌ１／Ｌ２制御信号での送信を行うか、パディング送信を行うかを切替えてもよい。例えば、上り送信データが有る場合には、パディング送信の代わりにＬ１／Ｌ２制御信号を用いた送信を行い、上り送信データが無い場合には、従来のパディング送信を行う。ｅＮＢは、Ｌ１／Ｌ２制御信号で受信したか、従来のパディング送信で受信したかによって、上り送信データの有無を認識することが可能となる。上り送信データが有る場合のＬ１／Ｌ２制御信号には、実施の形態２の変形例１で開示した方法を用いてもよい。
【０４０７】
このようにすることによって、２ｎｄ−ｅＮＢが、ＵＥの送信データの有無を認識することが可能となる。２ｎｄ−ｅＮＢに設定されたＳＰＳのタイミングで上り送信データが無い場合は、インプリシットリリースを実行することが可能となる。２ｎｄ−ｅＮＢにＳＰＳリソースで上り送信データが有る場合は、インプリシットリリースを実行しないようにすることができる。
【０４０８】
したがって、実施の形態３で開示したように、２ｎｄ−ｅＮＢに設定されたＳＰＳのタイミングで上り送信データが有る場合を考慮してインプリシットリリースを実行しないようにする場合に生じる、長期にわたるＳＰＳリソースのリザーブが不要となる。これによって、ＰＵＳＣＨリソースの使用効率の向上が可能となる。
【０４０９】
本実施の形態では、ＤＣが設定されており、２ｎｄ−ｅＮＢに設定されたＳＰＳのタイミングで上り送信データが有るか無いかによって、パディング送信を異ならせる方法を開示した。これに限らず、一つのｅＮＢに、異なるパディング送信を送るような場合に、本実施の形態で開示した方法を適用してもよい。
【０４１０】
例えば、ＵＥは、上り送信データの発生量の時間変化を測定し、その測定結果を用いて、上り送信タイミングにおいて上り送信データが発生する確率を導出する。言い換えると、ＵＥは、上り送信データの発生量の時間変化の測定結果を用いて、上り送信タイミングにおいて上り送信データが発生する確率を予測する。上り送信タイミングにおいて上り送信データが発生する確率を導出するために、統計的処理を行ってもよい。
【０４１１】
上り送信タイミングにおいて上り送信データが発生する確率に応じて、パディング送信を異ならせるようにしてもよい。上り送信データの発生量の時間変化の測定は、ベアラ毎に行ってもよい。あるいは、コンテンツ毎、または、アプリケーション毎に行ってもよい。
【０４１２】
ＵＥは、上り送信タイミングにおいて上り送信データが発生する確率が、予め定める閾値以上か否かを判断する。閾値は、予めシステムとして決められていてもよいし、ｅＮＢが設定してｅＮＢから通知されてもよい。上り送信データが発生する確率が、予め定める閾値以上か否かによって、パディング送信を異ならせる。
【０４１３】
ＵＥは、設定された上りＳＰＳタイミングにおいて、実際に上り送信データが発生しなかった場合、パディング送信を行うことになる。このとき、上り送信データが発生する確率が閾値以上の場合、パディング（Ｂ）送信を行う。上り送信データが発生する確率が閾値以上でない場合、すなわち上り送信データが発生する確率が閾値未満である場合、パディング（Ａ）送信を行う。
【０４１４】
ｅＮＢは、ＵＥから、リリース前空送信回数として設定される回数、連続してパディング（Ｂ）を受信したとしても、ＳＰＳリソースをリリースしない。また、ＵＥは、ｅＮＢに、リリース前空送信回数として設定される回数連続してパディング（Ｂ）を送信したとしても、設定されたＳＰＳリソースをクリアしない。このようにすることによって、上り送信データが発生する確率が高い場合は、ＳＰＳリソースをリリースしないようにすることができる。
【０４１５】
例えば、本来は上り送信データが発生するが、何らかの遅延によって偶然、その上り送信タイミングで上り送信データが発生しなかったような場合に、ＳＰＳリソースをリリースしないようにすることができる。したがって、まだ上り送信データの発生が続くような場合に、ＳＰＳリソースをリリースしないようにすることができ、次のＳＰＳタイミングでＳＰＳリソースを用いて上りデータを送信することが可能となる。
【０４１６】
ｅＮＢは、ＵＥから、リリース前空送信回数として設定される回数連続してパディング（Ａ）を受信した場合、ＳＰＳリソースをリリースする。また、ＵＥは、ｅＮＢに、リリース前空送信回数として設定される回数連続してパディング（Ａ）を送信した場合、設定されたＳＰＳリソースをクリアする。このようにすることによって、上り送信データが発生する確率が低い場合は、ＳＰＳリソースをリリースすることができる。
【０４１７】
以上のようにすることによって、長期にわたるＳＰＳリソースのリザーブが不要となる。これによって、ＰＵＳＣＨリソースの使用効率の向上が可能となる。
【０４１８】
また、以上に開示した方法では、パディング送信を２種類としたが、これに限らず、複数の異なるパディング送信を設けてパディング送信を行うようにしてもよい。ｅＮＢは、パディング送信の種類によって動作を変えることが可能となる。
【０４１９】
例えば、ＵＥは、下り受信品質に応じて、パディング送信を異ならせる。下り受信品質の閾値を２つ設けて、３つの受信品質状態に分割し、３つの受信品質状態に応じて、各々異なるパディング送信を行うようにしてもよい。このようにすることによって、ｅＮＢは、ＵＥの下り受信品質がどの程度かを認識することが可能となる。
【０４２０】
また、ｅＮＢは、ＵＥにパディング送信を行わせるために、ＵＥからの上りスケジューリング要求が無い場合でも、ＵＬリソースをスケジューリングし、ＵＥに上りグラントを通知してもよい。ＵＥは、上り送信データが無いので、上りグラントで割り当てられた上りリソースでパディング送信を行うことになる。このパディング送信を前述の受信品質状態に応じて異なるパディング送信としてもよい。このようにすることによって、ｅＮＢは、適時に、動的に、ＵＥの下り受信品質を認識することができる。以上のようにすることによって、ｅＮＢは、ＵＥに対して、多様で柔軟な制御を行うことが可能になる。
【０４２１】
実施の形態６．
予め定めるベアラに対してＵＬスプリットベアラが設定された場合、該ベアラのデータの発生状況に応じて、２ｎｄ−ｅＮＢにおいて上りＳＰＳが設定される。
【０４２２】
２ｎｄ−ｅＮＢ側で設定された上りＳＰＳのタイミングにおいて、上り送信データが発生した場合、２ｎｄ−ｅＮＢに対してＳＰＳリソースで上り送信が行われるだけでなく、ベアラの設定条件によっては、該ＳＰＳのタイミングにおいて１ｓｔ−ｅＮＢに対しても上り送信が行われることになる。
【０４２３】
該ＳＰＳのタイミングにおいて、１ｓｔ−ｅＮＢに対してＳＰＳの設定が行われていないと、１ｓｔ−ｅＮＢに対してＳＲ信号の送信から開始しなければならなくなる。
【０４２４】
上り送信において１ｓｔ−ｅＮＢも使えるにも関わらず、１ｓｔ−ｅＮＢに対する遅延が生じ、送信遅延時間の増大を引き起こす。本実施の形態では、このような課題を解決する方法を開示する。
【０４２５】
１ｓｔ−ｅＮＢに対して、２ｎｄ−ｅＮＢに対して行ったＳＰＳの設定と同じＳＰＳの設定を行う。ＵＬスプリットベアラが設定された場合に、１ｓｔ−ｅＮＢに対して、該ＳＰＳの設定を行うとしてもよい。
【０４２６】
ＳＰＳの設定方法を開示する。１ｓｔ−ｅＮＢに対するＳＰＳに、２ｎｄ−ｅＮＢに対するＳＰＳの設定と同じ設定を行う。各ｅＮＢに対して複数のＳＰＳの設定を可能とするとよい。
【０４２７】
同じ設定とするパラメータは、全部のパラメータでなくてもよい。同じ設定とするパラメータとしては、ＳＰＳの間隔がある。異なる設定とするパラメータとしては、ＳＰＳ用のＣ−ＲＮＴＩがある。ＵＬのリリース前空送信回数は、同じとしてもよいし、異なる設定としてもよい。
【０４２８】
１ｓｔ−ｅＮＢにＳＰＳが設定されている場合に、２ｎｄ−ｅＮＢにＳＰＳが設定された場合、１ｓｔ−ｅＮＢは、既に設定されているＳＰＳの設定に加えて２ｎｄ−ｅＮＢに対するＳＰＳの設定と同じ設定を行うとよい。１ｓｔ−ｅＮＢで既に設定されているＳＰＳの設定と、２ｎｄ−ｅＮＢに対するＳＰＳの設定とが同じ場合、例えば、ＳＰＳのタイミングが同じ場合も、重複して設定するとよい。
【０４２９】
あるいは、１ｓｔ−ｅＮＢで既に設定されているＳＰＳの設定と、２ｎｄ−ｅＮＢに対するＳＰＳの設定とが同じ場合、例えば、ＳＰＳのタイミングが同じ場合、重複して設定せずに、１ｓｔ−ｅＮＢで既に設定されているＳＰＳの設定と、２ｎｄ−ｅＮＢに対するＳＰＳの設定とを合わせたＳＰＳの設定を行うとよい。
【０４３０】
このようにすることによって、１ｓｔ−ｅＮＢで既にＳＰＳが設定されている場合に、既存のＳＰＳの設定を中断することなく、１ｓｔ−ｅＮＢに対して、２ｎｄ−ｅＮＢに対するＳＰＳの設定と同じ設定を行うことが可能となる。
【０４３１】
ＳＰＳの設定をＵＥに通知して設定する方法を開示する。２ｎｄ−ｅＮＢは、２ｎｄ−ｅＮＢに対するＳＰＳの設定をＵＥに通知する。さらに、２ｎｄ−ｅＮＢは、１ｓｔ−ｅＮＢに、２ｎｄ−ｅＮＢに対するＳＰＳの設定を通知する。この通知には、Ｘ２シグナリングを用いるとよい。あるいは、ＭＭＥを介して、Ｓ１シグナリングを用いて行ってもよい。これによって、１ｓｔ−ｅＮＢは、２ｎｄ−ｅＮＢのＳＰＳの設定を認識することが可能となる。１ｓｔ−ｅＮＢは、２ｎｄ−ｅＮＢのＳＰＳの設定の同じ設定とするパラメータを自ｅＮＢのＳＰＳの設定に適用する。同じ設定とするパラメータとしては、ＳＰＳの間隔がある。ＵＬのリリース前空送信回数は同じとしてもよいし、異なる設定としてもよい。ＳＰＳ用のＣ−ＲＮＴＩは、自ｅＮＢが独立に設定する。１ｓｔ−ｅＮＢは、これらのＳＰＳの設定をＵＥに通知する。
【０４３２】
このようにすることによって、１ｓｔ−ｅＮＢは、２ｎｄ−ｅＮＢと同じＳＰＳの設定をＵＥに設定することが可能となる。
【０４３３】
他のＳＰＳの設定方法を開示する。１ｓｔ−ｅＮＢに対するＳＰＳに、２ｎｄ−ｅＮＢに対するＳＰＳの設定と同じ設定を行う。各ｅＮＢに対して複数のＳＰＳの設定を可能とするとよい。
【０４３４】
同じ設定とするパラメータは、全部のパラメータとする。ＳＰＳの間隔、ＳＰＳ用のＣ−ＲＮＴＩ、およびＵＬのリリース前空送信回数を同じ設定とする。
【０４３５】
該ＳＰＳの設定をＵＥに通知して設定する方法を開示する。２ｎｄ−ｅＮＢは、２ｎｄ−ｅＮＢに対するＳＰＳの設定をＵＥに通知する。さらに、２ｎｄ−ｅＮＢは、１ｓｔ−ｅＮＢに、２ｎｄ−ｅＮＢに対するＳＰＳの設定を通知する。この通知には、Ｘ２シグナリングを用いるとよい。あるいは、ＭＭＥを介して、Ｓ１シグナリングを用いて行ってもよい。これによって、１ｓｔ−ｅＮＢは、２ｎｄ−ｅＮＢのＳＰＳの設定を認識することが可能となる。ＵＥは、２ｎｄ−ｅＮＢに対するＳＰＳの設定を、１ｓｔ−ｅＮＢに対するＳＰＳの設定に適用する。
【０４３６】
このようにすることによって、１ｓｔ−ｅＮＢは、２ｎｄ−ｅＮＢと同じＳＰＳの設定をＵＥに設定することが可能となる。
【０４３７】
また、このようにすることによって、１ｓｔ−ｅＮＢからＵＥに、ＳＰＳの設定を通知する必要が無くなる。したがって、エアインタフェース上のシグナリング量を削減することが可能となる。
【０４３８】
２ｎｄ−ｅＮＢと１ｓｔ−ｅＮＢとで同じＳＰＳ  Ｃ-ＲＮＴＩとする方法を開示する。２ｎｄ−ｅＮＢと１ｓｔ−ｅＮＢとの間で予め協調して同じ値を設定する。例えば、２ｎｄ−ｅＮＢがＳＰＳを設定する場合、予め、１ｓｔ−ｅＮＢに対して使用するＳＰＳ  Ｃ-ＲＮＴＩを通知する。
【０４３９】
１ｓｔ−ｅＮＢは、通知されたＳＰＳ  Ｃ−ＲＮＴＩを使用可能な場合、２ｎｄ−ｅＮＢにＡｃｋを通知する。これによって、１ｓｔ−ｅＮＢと２ｎｄ−ｅＮＢとは、同じＳＰＳ  Ｃ−ＲＮＴＩを使用することが可能となる。
【０４４０】
１ｓｔ−ｅＮＢは、通知されたＳＰＳ  Ｃ−ＲＮＴＩを使用不可能な場合、２ｎｄ−ｅＮＢにＮａｃｋを通知する。この場合、２ｎｄ−ｅＮＢは、再度他のＳＰＳ  Ｃ−ＲＮＴＩ値を選択し、１ｓｔ−ｅＮＢに通知する。１ｓｔ−ｅＮＢからＡｃｋを受信するまで繰り返す。このような方法を行うことによって、２ｎｄ−ｅＮＢと１ｓｔ−ｅＮＢとで同じＳＰＳ  Ｃ-ＲＮＴＩを用いることが可能となる。
【０４４１】
２ｎｄ−ｅＮＢと１ｓｔ−ｅＮＢとの間の該情報の通知には、Ｘ２シグナリングを用いるとよい。あるいは、ＭＭＥを介して、Ｓ１シグナリングを用いて行ってもよい。
【０４４２】
ＳＰＳアクティベートのタイミングが、ＳＰＳの開始タイミングを決定する。したがって、両ｅＮＢでＳＰＳアクティベートタイミングを合わせる方法が必要となる。
【０４４３】
２ｎｄ−ｅＮＢは、ＳＰＳアクティベートをＵＥに通知することを決定した場合、ＳＰＳアクティベートをＵＥに通知するタイミングを、１ｓｔ−ｅＮＢに通知する。あるいは、ＳＰＳアクティベートをＵＥに通知したタイミングを、１ｓｔ−ｅＮＢに通知する。
【０４４４】
タイミング情報としては、無線フレーム番号およびサブフレーム番号の少なくとも一方とするとよい。
【０４４５】
１ｓｔ−ｅＮＢは、受信したタイミング情報を用いて、２ｎｄ−ｅＮＢのＳＰＳの設定がＵＥに対してアクティベートされるタイミングを導出し、該タイミングに合わせるように、ＳＰＳアクティベートをＵＥに通知する。
【０４４６】
２ｎｄ−ｅＮＢがＵＥにＳＰＳアクティベートを通知するタイミングに間に合わない場合、以降のＳＰＳの間隔後のタイミングに合わせてＵＥに通知すればよい。可能な限り早く通知すればよい。
【０４４７】
このようにすることによって、両ｅＮＢでＳＰＳアクティベートタイミングを合わせることができ、両ｅＮＢに対するＳＰＳのタイミングを一致させることが可能となる。
【０４４８】
２ｎｄ−ｅＮＢと１ｓｔ−ｅＮＢとの間の該情報の通知には、Ｘ２シグナリングを用いるとよい。あるいは、ＭＭＥを介して、Ｓ１シグナリングを用いて行ってもよい。
【０４４９】
図２１は、１ｓｔ-ｅＮＢに対して、２ｎｄ-ｅＮＢに対して行ったＳＰＳの設定と同じＳＰＳの設定を行う方法について説明する図である。１ｓｔ−ｅＮＢをＭｅＮＢとし、２ｎｄ−ｅＮＢをＳｅＮＢとする。
【０４５０】
図２１では、ＤＲＡＴの閾値を参照符号「１９０１」で示す。
【０４５１】
ＳｅＮＢは、ＳＰＳの設定を決定する。ステップＳＴ１９０２において、ＳｅＮＢは、ＵＥに、ＲＲＣ個別シグナリングで、ＳＰＳの間隔、リリース前空送信回数、およびＳＰＳ  Ｃ-ＲＮＴＩを通知する。
【０４５２】
また、ステップＳＴ１９０３において、ＳｅＮＢは、ＭｅＮＢに、設定したＳＰＳ構成を通知する。設定したＳＰＳ構成は、Ｘ２シグナリングで通知するとよい。通知するＳＰＳ構成としては、ＳＰＳの間隔とするとよい。また、リリース前空送信回数も通知してもよい。
【０４５３】
ＭｅＮＢは、受信したＳｅＮＢ構成と同じ値を、ＭｅＮＢに対するＳＰＳ構成として設定する。ＳＰＳ  Ｃ−ＲＮＴＩは、ＳｅＮＢと同じ値を用いずに、ＭｅＮＢが選択する。
【０４５４】
ステップＳＴ１９０４において、ＭｅＮＢは、ＵＥに、ＲＲＣ個別シグナリングで、ＭｅＮＢに対するＳＰＳ構成およびＳＰＳ  Ｃ-ＲＮＴＩを通知する。
【０４５５】
ＵＥは、ＳｅＮＢおよびＭｅＮＢから通知されたＳＰＳ  Ｃ−ＲＮＴＩを用いて、ＰＤＣＣＨを検出する。
【０４５６】
ステップＳＴ１９０５において、ＳｅＮＢは、ＭｅＮＢに、ＳＰＳアクティベートのタイミングを通知する。ＳＰＳアクティベートのタイミングを受信したＭｅＮＢは、ＳｅＮＢがＳＰＳをアクティベートするタイミングを認識することが可能となる。
【０４５７】
ステップＳＴ１９０６およびステップＳＴ１９０７において、ＳｅＮＢおよびＭｅＮＢは、ＳｅＮＢが決定したアクティベートのタイミングで、ぞれぞれ、ＵＥにＳＰＳアクティベートを送信する。これによって、ＳｅＮＢ、ＭｅＮＢともに、ＵＥに対して、同じＳＰＳアクティベートのタイミングとすることが可能となる。
【０４５８】
ステップＳＴ１９０５におけるＳｅＮＢからＭｅＮＢへのＳＰＳアクティベートのタイミングの通知と、ステップＳＴ１９０６におけるＳｅＮＢからＵＥへのＳＰＳアクティベートのタイミングの通知との順序は逆になってもよい。
【０４５９】
ＳｅＮＢは、ＳＰＳアクティベートをＵＥに通知したタイミングを、ＭｅＮＢに通知する。これによって、ＳｅＮＢで実際にＳＰＳアクティベートを行ったタイミングをＭｅＮＢに通知することが可能となる。実際のＳＰＳアクティベートタイミングを通知することによって、ＳｅＮＢとＭｅＮＢとでＳＰＳアクティベートタイミングがずれてしまうような誤動作の発生を低減することが可能となる。
【０４６０】
ＭｅＮＢからのＳＰＳリソースのスケジューリングと、ＳｅＮＢからのＳＰＳリソースのスケジューリングとは異なっていてもよい。ＭｅＮＢ、ＳｅＮＢは、それぞれ、個別にスケジューリングしてもよい。
【０４６１】
ＵＥは、ＳＰＳアクティベートを受信することによって、ＳｅＮＢとＭｅＮＢとに対してＳＰＳがアクティベートされたことを認識する。
【０４６２】
ステップＳＴ１９０８およびステップＳＴ１９０９において、ＵＥは、設定されたＳＰＳのタイミングで、ＳｅＮＢおよびＭｅＮＢに、上りデータの送信を行う。
【０４６３】
ステップＳＴ１９１０において、ＵＥは、設定されたＳＰＳのタイミングで、ＵＥの上り送信データのデータ量がＤＲＡＴの閾値よりも小さい場合、ＳｅＮＢに対してパディング送信を行う。ＭｅＮＢに対しては上りデータの送信を行う。
【０４６４】
ＳｅＮＢに対して、パディング送信が、リリース前空送信回数として設定される回数連続して行われた場合、ステップＳＴ１９１１において、ｅＮＢは、ＳｅＮＢに対して設定されたＳＰＳリソースをリリースする。ＵＥもＳｅＮＢに対して設定されたＳＰＳリソースをクリアする。
【０４６５】
ＭｅＮＢに対しては、上りデータの送信が行われているので、ステップＳＴ１９１１では、ＭｅＮＢに対して設定されたＳＰＳリソースをリリースしない。上り送信データがある場合は、上りデータの送信を行う。
【０４６６】
ＳＰＳリソースのリリースについて開示する。インプリシットリリースが生じたｅＮＢは、他のｅＮＢにその旨を通知してもよい。例えば、２ｎｄ−ｅＮＢで、設定されたＳＰＳに対してインプリシットリリースが生じた場合、２ｎｄ−ｅＮＢは、インプリシットリリースが生じたことを１ｓｔ−ｅＮＢに通知する。あるいは、インプリシットリリースによってＳＰＳリソースをリリースあるいはＳＰＳの設定を無効にしたことを通知してもよい。
【０４６７】
２ｎｄ−ｅＮＢのＳＰＳリソースのリリースを受信した１ｓｔ−ｅＮＢは、１ｓｔ−ｅＮＢで設定していた２ｎｄ−ｅＮＢと同じＳＰＳの設定を無効にしてもよい。また、適宜、１ｓｔ−ｅＮＢは、ＵＥに、１ｓｔ−ｅＮＢで設定していた２ｎｄ−ｅＮＢと同じＳＰＳの設定を無効にすることを通知してもよい。ＵＥは、該通知を受信することによって、１ｓｔ−ｅＮＢで設定していた２ｎｄ−ｅＮＢと同じＳＰＳの設定を無効にすることが可能となる。
【０４６８】
このようにすることによって、１ｓｔ−ｅＮＢは、２ｎｄ−ｅＮＢと同じＳＰＳの設定を無効にすることが可能となる。
【０４６９】
また、実施の形態４の変形例２で開示した上りＳＰＳの設定を無効にすることを示す情報をＵＥに通知したｅＮＢは、他のｅＮＢにその旨を通知してもよい。あるいは、上りＳＰＳの設定を無効にすることを示す情報をＵＥに通知するｅＮＢは、予め、他のｅＮＢにその旨を通知してもよい。
【０４７０】
例えば、２ｎｄ−ｅＮＢは、上りＳＰＳの設定を無効にすることを示す情報をＵＥに通知した場合、１ｓｔ−ｅＮＢに、上りＳＰＳの設定を無効にすることを示す情報をＵＥに通知したことを通知する。
【０４７１】
あるいは、２ｎｄ−ｅＮＢは、上りＳＰＳの設定を無効にすることを示す情報をＵＥに通知する場合、１ｓｔ−ｅＮＢに、上りＳＰＳの設定を無効にすることを示す情報をＵＥに通知することを通知する。この場合、上りＳＰＳの設定を無効にするタイミング、あるいは、上りＳＰＳの設定を無効にすることを示す情報をＵＥに通知するタイミングを、１ｓｔ−ｅＮＢに通知してもよい。
【０４７２】
２ｎｄ−ｅＮＢから、前述した上りＳＰＳの設定を無効にすることを示す情報を受信した１ｓｔ−ｅＮＢは、上りＳＰＳの設定を無効にすることを示す情報を用いて、１ｓｔ−ｅＮＢで設定していた２ｎｄ−ｅＮＢと同じＳＰＳの設定を無効にしてもよい。あるいは、１ｓｔ−ｅＮＢで設定していた２ｎｄ−ｅＮＢと同じＳＰＳの設定を無効にしないと判断してもよい。あるいは、１ｓｔ−ｅＮＢで設定していた２ｎｄ−ｅＮＢと同じＳＰＳの設定を修正設定してもよい。例えば、先に１ｓｔ−ｅＮＢに対して設定されていたＳＰＳの設定に戻してもよい。１ｓｔ−ｅＮＢは、負荷状況などを考慮して、柔軟に、自ｅＮＢに設定しているＳＰＳの設定を変更することが可能となる。
【０４７３】
また、適宜、１ｓｔ−ｅＮＢは、ＵＥに、１ｓｔ−ｅＮＢで設定していた２ｎｄ−ｅＮＢと同じＳＰＳの設定を無効にすることを通知してもよい。ＵＥは、該通知を受信することによって、１ｓｔ−ｅＮＢで設定していた２ｎｄ−ｅＮＢと同じＳＰＳの設定を無効にすることが可能となる。
【０４７４】
１ｓｔ−ｅＮＢは、２ｎｄ−ｅＮＢが上りＳＰＳの設定を無効にすることを示す情報をＵＥに通知するタイミングに間に合わない場合、次のＳＰＳの間隔後のタイミングでＵＥに通知してもよい。あるいは、次のＳＰＳの間隔後のタイミングを待たずにＵＥに通知してもよい。あるいは、即座に通知してもよい。
【０４７５】
このようにすることによって、１ｓｔ−ｅＮＢは、２ｎｄ−ｅＮＢと同じＳＰＳの設定を無効にすることが可能となる。
【０４７６】
２ｎｄ−ｅＮＢに対して設定されたＳＰＳのタイミングにおいて、２ｎｄ−ｅＮＢだけでなく、１ｓｔ−ｅＮＢに対しても上りデータの送信が行わる場合があることを述べた。
【０４７７】
本実施の形態で開示した方法を用いることによって、２ｎｄ−ｅＮＢに対して設定されたＳＰＳのタイミングにおいて、１ｓｔ−ｅＮＢに対してＳＰＳの設定が行わることになる。したがって、ＵＥは、２ｎｄ−ｅＮＢだけでなく、１ｓｔ−ｅＮＢに対しても、ＳＰＳのタイミングにおいて、上りスケジューリング要求を送信することなく、上りデータを送信することが可能となる。これによって、１ｓｔ−ｅＮＢに対する送信遅延時間の削減を図ることができる。
【０４７８】
実施の形態７．
ＵＬスプリットベアラにおいて、ＵＥは、上り送信データのデータ量がＤＲＡＴの閾値以下の場合、２ｎｄ−ｅＮＢに上りデータを送信しない。
【０４７９】
２ｎｄ-ｅＮＢに対して上りデータの送信が無いにも関わらず、パディング送信を行うことは、ＵＥの消費電力の無駄となる。
【０４８０】
特に、パディング送信が予め定める回数連続して発生しても、インプリシットリリースを行わない場合、パディング送信の回数によってインプリシットリリースを判断するわけではないので、パディング送信を行うことは無駄となる。
【０４８１】
このような問題を解決するために、インプリシットリリースが行われない場合、パディング送信をしないとするとよい。
【０４８２】
ＵＥは、設定されたＳＰＳのタイミングで２ｎｄ−ｅＮＢに対して上りデータの送信が無い場合、かつ、インプリシットリリースが行われない場合、パディング送信をしない。
【０４８３】
図２２は、インプリシットリリースが行われない場合にパディング送信をしないようにする方法を説明する図である。１ｓｔ−ｅＮＢをＭｅＮＢとし、２ｎｄ−ｅＮＢをＳｅＮＢとする。ＭｅＮＢ、ＳｅＮＢともにＳＰＳが設定された場合を示している。図２２は、図１５と類似しているので、主として異なる部分について説明する。
【０４８４】
ステップＳＴ１００８において、ＳｅＮＢは、ＵＥに、ＰＤＣＣＨを用いて、上りＳＰＳの上りグラントでアクティベートを通知する。該アクティベートに、上りＳＰＳの設定を無効にしないことを示す情報を含める。これによって、ＵＥは、インプリシットリリースを行わず、上りＳＰＳの設定を無効にしないようにすることを認識することができる。
【０４８５】
ＳｅＮＢからＳＰＳのアクティベートを受信したＵＥは、設定されたリソースでＳＰＳを実行するとともに、インプリシットリリースを行わず、上りＳＰＳの設定を無効にしない。たとえ、ＵＥがＳｅＮＢに対して予め定める回数上り送信データが発生しなかったとしても、ｅＮＢ、ＵＥともにインプリシットリリースを行わず、上りＳＰＳの設定を無効にしないように設定する。
【０４８６】
ステップＳＴ１３０１において、ＳｅＮＢに対して設定されたＳＰＳのタイミングで、ＵＥでＤＲＡＴの閾値よりも小さいデータ量の上りデータが発生した場合を考える。
【０４８７】
この場合、ステップＳＴ１３０１において、ＵＥは、ＭｅＮＢに上りデータを送信する。ＳｅＮＢに対しては上り送信データが発生しない。
【０４８８】
インプリシットリリースが行われない場合に、上り送信データが発生しない場合は、パディング送信をしないので、ステップＳＴ２００１において、ＵＥは、ＳｅＮＢに対して、パディング送信を行わない。
【０４８９】
ステップＳＴ２００１からステップＳＴ２００２において、ＳｅＮＢに対して設定されたＳＰＳのタイミングで、ＵＥでＤＲＡＴの閾値よりも小さいデータ量の上りデータが発生する場合、同様に、ステップＳＴ１３０１からステップＳＴ１３０２において、ＵＥは、ＭｅＮＢに上りデータの送信を行うが、ＳｅＮＢに対してはパディング送信を行わない。
【０４９０】
ＳｅＮＢに対して、リリース前空送信回数として設定される回数連続して上り送信データが発生しない場合、ＵＥは、そのＳＰＳリソースでパディング送信は行わない。このような場合、ＵＥは、ステップＳＴ１００８で受信した、インプリシットリリースを行わない。ＵＥは、上りＳＰＳの設定を無効にしない設定に従い、ステップＳＴ１２０４において、ＳＰＳリソースをクリアしない。ｅＮＢもＳＰＳリソースをリリースしない。ステップＳＴ１２０４において、インプリシットリリースが行われず、ＳＰＳリソースがリリースされない。
【０４９１】
ステップＳＴ１２０４において、ＳｅＮＢに対して設定されたＳＰＳのタイミングで、ＵＥでＤＲＡＴの閾値以上のデータ量の上りデータが発生した場合、ステップＳＴ１４０１において、ＵＥは、ＳｅＮＢに、設定されているＳＰＳリソースで、上りデータの送信を行うことが可能となる。
【０４９２】
このようにすることによって、インプリシットリリースが行われない場合、ＳｅＮＢに対して上り送信データが発生しないときに、パディング送信を行わないようにすることが可能となる。ＵＥは、パディング送信を行わないので、ＵＥの消費電力を削減することが可能となる。また、ＳｅＮＢに対して上り送信データが発生しないときに、パディング送信を行わないようにすることによって、上りリンクにおける干渉を低減することが可能となる。
【０４９３】
インプリシットリリースが行われる場合は、パディング送信が行われるようにしてもよい。インプリシットリリースを行う方法は、実施の形態４、実施の形態４の変形例１、および実施の形態４の変形例２において開示した方法を適用するとよい。ｅＮＢは、ＵＥに、インプリシットリリースの開始の通知とともに、パディング送信を開始することを示す情報を通知するとよい。
【０４９４】
このようにすることによって、インプリシットリリースが行われない場合、２ｎｄ−ｅＮＢに対して上り送信データが発生しないとき、パディング送信を行わないようにすることが可能となる。また、インプリシットリリースが行われる場合、２ｎｄ−ｅＮＢに対して上り送信データが発生しないとき、パディング送信を行うようにすることが可能となる。
【０４９５】
これによって、インプリシットリリースを正常に動作させることが可能になるとともに、ＵＥの消費電力を削減することが可能となる。
【０４９６】
インプリシットリリースが行われない場合、２ｎｄ−ｅＮＢに対して上り送信データが発生しないとき、パディング送信をしないことを設定する方法の具体例として、以下の（１），（２）の２つを開示する。
【０４９７】
（１）予め規格などで静的に決めておく。
【０４９８】
（２）パディング送信をしないことを示す情報を設けて、ｅＮＢからＵＥに通知する。
【０４９９】
前述の（１）の方法では、インプリシットリリースが行われない場合、２ｎｄ−ｅＮＢに対して上り送信データが発生しないとき、パディング送信をしないことを静的に決めておく。これを予め規格などで決めておくことによって、ｅＮＢとＵＥとで認識することが可能となるので、整合のとれた動作が可能となり、誤動作を低減させることができる。
【０５００】
前述の（２）の方法では、パディング送信をしないことを示す情報をｅＮＢからＵＥに通知することによって、２ｎｄ−ｅＮＢに対して上り送信データが発生しないとき、パディング送信をしないことを、動的に設定することが可能となる。ｅＮＢは、２ｎｄ−ｅＮＢでインプリシットリリースが行われない場合に、ＵＥに該情報を通知してもよい。ＵＥは、パディング送信をしないことを示す情報を受信すると、２ｎｄ−ｅＮＢに対して上りデータが発生しない場合に、パディング送信を行わない。
【０５０１】
前述の（２）のパディング送信をしないことを示す情報は、ｅＮＢからＵＥに通知するとよい。ｅＮＢとしては、１ｓｔ−ｅＮＢであってもよいし、２ｎｄ−ｅＮＢであってもよい。例えば、２ｎｄ−ｅＮＢからＵＥに通知するときに、２ｎｄ−ｅＮＢから直接ＵＥに通知してもよいし、２ｎｄ−ｅＮＢから１ｓｔ−ｅＮＢを介してＵＥに通知してもよい。ｅＮＢ間の情報の通知には、Ｘ２シグナリングを用いてもよい。あるいは、ＭＭＥを介してＳ１シグナリングを用いてもよい。
【０５０２】
パディング送信をしないことを示す情報をｅＮＢからＵＥに通知するためのシグナリング方法の具体例として、以下の（１）〜（３）の３つを開示する。
【０５０３】
（１）ＲＲＣシグナリング。例えば、ＳＰＳ構成の設定のためのシグナリングに含めて通知してもよい。
【０５０４】
（２）ＭＡＣシグナリング。例えば、パディング送信をしないことを示す情報を含むＭＡＣ  ＣＥを設けて、ＭＡＣシグナリングによって通知してもよい。
【０５０５】
（３）Ｌ１／Ｌ２シグナリング。例えば、ＰＤＣＣＨあるいはＥＰＤＣＣＨ。例えば、ＳＰＳアクティベートに含めて通知してもよい。
【０５０６】
パディング送信をしないことを示す情報を設けて、ｅＮＢからＵＥに通知することを開示したが、パディング送信を行うことを示す情報を設けてもよい。パディング送信を行うことを示す情報は、ｅＮＢからＵＥに通知してもよい。これによって、インプリシットリリースが行われない場合に、２ｎｄ−ｅＮＢに対して上り送信データが発生しない場合、パディング送信の有無を動的に設定することが可能となり、２ｎｄ−ｅＮＢの通信状況および負荷状況に応じて柔軟な運用が可能となる。
【０５０７】
実施の形態８．
実施の形態７では、設定されたＳＰＳのタイミングで上り送信データが無い場合、パディング送信をしない方法を開示した。
【０５０８】
パディング送信をしないとした場合、ｅＮＢは、実際上りデータが送信されたにも関わらず受信できなかったのか、パディング送信が無かったために受信できなかったのかを識別することができなくなる。本実施の形態では、このような問題を解決する方法を開示する。
【０５０９】
パディング送信をしないことが設定された場合でも、ＨＡＲＱを動作させる。ｅＮＢは、パディング送信をしないことが設定された場合、ＨＡＲＱを動作させる。ＵＥは、上り送信データがある場合、ＨＡＲＱを行い、上り送信データが無い場合、パディング送信も再送も行わない、とする。
【０５１０】
従来、設定されたＳＰＳのタイミングで上り送信データが無い場合に行われるパディング送信は、ＨＡＲＱの対象となる。ｅＮＢは、パディング送信を受信することによって、上り送信データが送られたのか否かを判断することができる。したがって、ＵＥは、設定されたＳＰＳのタイミングで上り送信データが無い場合も、パディング送信を行い、ｅＮＢから送達受信不成功（受信不成功）信号であるＮａｃｋを受信した場合は、パディング送信の再送を行うことになる。
【０５１１】
本実施の形態で開示した方法では、ｅＮＢはＨＡＲＱを動作させるが、ＵＥは、設定されたＳＰＳのタイミングで上り送信データが無い場合、パディング送信を行わず、たとえｅＮＢから受信不成功信号であるＮａｃｋを受信したとしても、パディング送信の再送を行わないようにするという点で、従来の方法と異なる。
【０５１２】
ＵＥは、パディング送信をしない場合に、ｅＮＢからＮａｃｋを受信したとしても、パディング送信の再送を行わない。したがって、ｅＮＢは、ＵＥからの再送が無いので、受信不成功となり、再度Ｎａｃｋを送信する。ＵＥは、ｅＮＢから再度Ｎａｃｋを受信することとなる。このＮａｃｋに対しても、ＵＥは、パディング送信の再送を行わない。ＵＥは、パディング送信もパディング送信の再送も行わないので、このような動作が繰り返されることになる。したがって、ｅＮＢは、ＵＥにＮａｃｋを送信し続けることになる。このような問題を解決する方法を開示する。
【０５１３】
ｅＮＢは、最大再送回数を設定するとよい。上りＳＰＳリソースで初送が行われた場合のＨＡＲＱについては、最大再送回数を設定するとよい。
【０５１４】
ｅＮＢは、受信不成功が続いたとき、最大再送回数だけＮａｃｋを送信しても受信不成功の場合は、ＨＡＲQを停止する。
【０５１５】
最大再送回数は、予め規格などで静的に決められてもよい。あるいはｅＮＢが決定してもよい。これによって、通信状況および負荷状況に応じて動的に変更することが可能となる。あるいはＯＡＭ（operation administration and maintenance）が決定してもよい。これによって、複数のｅＮＢの状況を考慮して決定することができる。あるいはオペレータが決定してもよい。システム設計パラメータの一つとして決定してもよい。
【０５１６】
本実施の形態で開示した最大再送回数は、従来ＨＡＲQに設定されている最大再送回数と異なる設定としてもよい。例えば、本実施の形態で開示した最大再送回数を、従来ＨＡＲQに設定されている最大再送回数よりも小さくするとよい。本実施の形態で開示した最大再送回数を小さくすることによって、上り送信データが無く、パディング送信が無い場合に、ｅＮＢからＵＥに送信するＮａｃｋの数を減らすことが可能となる。これによって、Ｎａｃｋ用の無線リソースの無駄を低減することが可能となる。
【０５１７】
図２３は、パディング送信をしない場合のＨＡＲＱの方法について説明する図である。１ｓｔ−ｅＮＢをＭｅＮＢとし、２ｎｄ−ｅＮＢをＳｅＮＢとする。図２３は、ＳｅＮＢにＳＰＳが設定された場合を示している。インプリシットリリースが行われない場合に、上り送信データが発生しない場合は、パディング送信をしないようにする場合について示している。ステップＳＴ２１０８において、ＳｅＮＢは、ＵＥに、ＰＤＣＣＨを用いて、上りＳＰＳの上りグラントでアクティベートを通知する。該アクティベートに、上りＳＰＳの設定を無効にしないことを示す情報を含める。これによって、ＵＥは、インプリシットリリースが行われず、上り送信データが発生しない場合は、パディング送信をしないことを認識することができる。
【０５１８】
ステップＳＴ２１０１において、ＳｅＮＢに対して設定されたＳＰＳのタイミングで、ＵＥでＤＲＡＴの閾値以上のデータ量の上りデータが発生した場合を考える。この場合、ステップＳＴ２１０１において、ＵＥは、ＳｅＮＢに対して設定されたＳＰＳリソースで、ＳｅＮＢに上りデータを送信する。ｅＮＢは、ＵＥからの上りデータを受信し、受信成功であったとする。この場合、ステップＳＴ２１０２において、ＳｅＮＢは、受信成功信号であるＡｃｋをＵＥに送信する。ＵＥは、Ａｃｋを受信した場合、上りデータがＳｅＮＢに受信されたと判断し、再送を行わない。
【０５１９】
次に、ＳＴ２１０３において、ＵＥは、ＳｅＮＢに、設定されたＳＰＳのタイミングで、上りデータを送信する。ＳｅＮＢは、ＵＥからの上りデータを受信し、受信不成功であったとする。この場合、ステップＳＴ２１０４において、ＳｅＮＢは、ＮａｃｋをＵＥに送信する。
【０５２０】
ＵＥは、Ｎａｃｋを受信した場合、上りデータがＳｅＮＢに受信されなかったと判断し、ステップＳＴ２１０５において、ＳｅＮＢに上りデータの再送を行う。このように、ＵＥは、上りデータをＳｅＮＢに送信し、ＳｅＮＢからＮａｃｋを受信した場合は、上りデータの再送を行う。
【０５２１】
ステップＳＴ２１０５において、ＳｅＮＢは、ＵＥからの上りデータの再送を受信して、受信成功であったとする。この場合、ステップＳＴ２１０９において、ＳｅＮＢは、ＡｃｋをＵＥに送信する。
【０５２２】
ＵＥは、Ａｃｋを受信した場合、上り再送データがｅＮＢに受信されたと判断し、再送を行わない。
【０５２３】
次に、ステップＳＴ２１０６において、ＳｅＮＢに対して設定されたＳＰＳのタイミングで、ＵＥでＤＲＡＴの閾値より小さいデータ量の上りデータが発生した場合を考える。この場合、ステップＳＴ２１１０において、ＵＥは、ＭｅＮＢに上りデータを送信するが、ＳｅＮＢに対して設定されたＳＰＳリソースで上りデータを送信しない。ステップＳＴ２１０８において、上り送信データが発生しない場合は、パディング送信をしないようにすることを設定されているので、ＵＥは、パディング送信も行わない。
【０５２４】
ステップＳＴ２１０６において、ＳｅＮＢは、ＵＥからのパディング送信が行われないので、受信不成功となる。この場合、ステップＳＴ２１１１において、ＳｅＮＢは、ＮａｃｋをＵＥに送信する。
【０５２５】
ＵＥは、Ｎａｃｋを受信してもよいし、Ｎａｃｋを受信しなくてもよい。ＵＥは、Ｎａｃｋを受信したとしても、再送を行わない。また、ＵＥは、パディング送信も行わない。
【０５２６】
ステップＳＴ２１０７において、ＳｅＮＢは、ＵＥから何も送信されないので、受信不成功となる。この場合、ステップＳＴ２１１２において、ＳｅＮＢは、再度ＮａｃｋをＵＥに送信する。
【０５２７】
ＵＥは、同様に、Ｎａｃｋを受信してもよいし、Ｎａｃｋを受信しなくてもよい。ＵＥは、Ｎａｃｋを受信したとしても、再送を行わない。また、ＵＥは、パディング送信も行わない。
【０５２８】
ｅＮＢは、Ｎａｃｋの送信回数が、最大送信回数に達した場合、ＨＡＲＱを停止する。仮に最大再送回数が設定されていない場合は、Ｎａｃｋの送信が繰り返されることになるが、本実施の形態では最大再送回数が設定されているので、ＨＡＲＱを停止することが可能となる。
【０５２９】
本実施の形態で開示した方法を用いることによって、ＵＥから上りデータの送信が行われた場合に、ＨＡＲＱが動作することになり、上りデータの受信性能が向上する。
【０５３０】
また、ＵＥは、上り送信データが無い場合は、たとえｅＮＢからＮａｃｋが送信されたとしても、再送することは無く、パディング送信もすることが無い。ＵＥは、上りデータ送信を行ったときのみ、ｅＮＢからのＮａｃｋに従って、再送を行えばよい。したがって、ＵＥの送信は、上りデータの送信が行わる場合に限定されるので、消費電力の増大を低減することが可能となる。
【０５３１】
実施の形態８  変形例１．
本変形例では、実施の形態８で示した課題を解決する他の方法を開示する。２ｎｄ−ｅＮＢは、２ｎｄ−ｅＮＢ向けにデータが発生したか否かを判断する。２ｎｄ−ｅＮＢは、該結果を用いてＨＡＲＱを動作させるか否かを判断する。
【０５３２】
２ｎｄ−ｅＮＢ向けにデータが発生したか否かを判断する方法を開示する。２ｎｄ−ｅＮＢは、予め自ｅＮＢのＳＰＳの設定を１ｓｔ−ｅＮＢに通知する。ＳＰＳの設定としては、ＳＰＳのタイミングとするとよい。あるいは、ＳＰＳの間隔と、ＳＰＳアクティベートとをＵＥに通知したタイミングであってもよい。
【０５３３】
これによって、１ｓｔ−ｅＮＢは、２ｎｄ−ｅＮＢで設定されたＳＰＳのタイミングを認識することが可能となる。
【０５３４】
１ｓｔ−ｅＮＢは、２ｎｄ−ｅＮＢのＳＰＳのタイミングで、ＵＥから発生した上り送信データのデータ量がＤＲＡＴの閾値よりも小さいか否かを判断する。１ｓｔ−ｅＮＢは、該判断結果を、２ｎｄ−ｅＮＢに通知する。２ｎｄ−ｅＮＢは、１ｓｔ−ｅＮＢから受信した判断結果に基づいて、２ｎｄ−ｅＮＢ自身向けにデータが発生したか否かを判断する。
【０５３５】
２ｎｄ−ｅＮＢは、１ｓｔ−ｅＮＢから通知された判断結果が、ＤＲＡＴの閾値よりも小さい場合、２ｎｄ−ｅＮＢ自身向けにデータが発生していないと判断する。
【０５３６】
２ｎｄ−ｅＮＢは、１ｓｔ−ｅＮＢから通知された判断結果が、ＤＲＡＴの閾値以上の場合、２ｎｄ−ｅＮＢ自身向けにデータが発生していると判断する。
【０５３７】
２ｎｄ−ｅＮＢが、ＨＡＲＱを動作させるか否かを判断する方法を開示する。２ｎｄ−ｅＮＢは、２ｎｄ−ｅＮＢ自身向けにデータが発生したと判断した場合は、ＨＡＲＱを動作させる。
【０５３８】
２ｎｄ−ｅＮＢは、２ｎｄ−ｅＮＢ自身向けにデータが発生していないと判断した場合は、ＨＡＲＱを停止させる。
【０５３９】
このような方法では、１ｓｔ−ｅＮＢから２ｎｄ−ｅＮＢに情報を通知する必要がある。この場合、Ｘ２インタフェースあるいはＳ１インタフェースなどのバックホールで通信を行うので、時間的に２ｎｄ−ｅＮＢで行うＨＡＲＱに即座に対応できない場合が生じる。
【０５４０】
しかし、たとえ、即座にＨＡＲＱに対応できないとしても、バックホール通信などによる遅延の後には対応可能となる。したがって、延々とＨＡＲＱが続くことを防ぐことができる。これによって、２ｎｄ−ｅＮＢのリソースの使用効率を向上させることが可能となる。
【０５４１】
１ｓｔ−ｅＮＢに送信されたデータが、ＤＲＡＴの閾値よりも小さいにも関わらず、２ｎｄ−ｅＮＢにもデータが送信される場合がある。例えば、ＤＲＡＴの閾値を超えた場合の１ｓｔ−ｅＮＢと２ｎｄ−ｅＮＢとのスケジューリング比率が１対２（１：２）と設定された場合などである。この場合、１ｓｔ−ｅＮＢへの送信データのデータ量は、１／３となる。このような場合、ＤＲＡＴの閾値よりも小さくなる可能性がある。
【０５４２】
このような場合、２ｎｄ−ｅＮＢ側でＨＡＲＱが行われなくなってしまう。２ｎｄ−ｅＭＢにはデータ送信が行われるにも関わらず、ＨＡＲＱが行われなくなるので、問題となる。このような問題を解決する方法を開示する。
【０５４３】
１ｓｔ−ｅＮＢは、１ｓｔ−ｅＮＢと２ｎｄ−ｅＮＢとのスケジューリング比率を取得する。例えば、２ｎｄ−ｅＮＢが該スケジューリング比率を決定する場合、予め、２ｎｄ−ｅＮＢから１ｓｔ−ｅＮＢに該スケジューリング比率を通知しておくとよい。１ｓｔ−ｅＮＢが該スケジューリング比率を決定する場合は、通知する必要はない。
【０５４４】
１ｓｔ−ｅＮＢは、スケジューリング比率を考慮して、ＤＲＡＴの閾値よりも小さいか否かを判断する。
【０５４５】
このようにすることによって、ＤＲＡＴの閾値を超えた場合の１ｓｔ−ｅＮＢと２ｎｄ−ｅＮＢとのスケジューリング比率によって、１ｓｔ−ｅＮＢに送信されたデータが、ＤＲＡＴの閾値よりも小さいにも関わらず、２ｎｄ−ｅＮＢにもデータが送信される場合に、ＨＡＲＱが動作しなくなることを防ぐことができる。
【０５４６】
したがって、２ｎｄ−ｅＮＢに対して、ＵＥからの上り送信データが有る場合、該上り送信データの受信性能を向上させることができる。
【０５４７】
また、ＨＡＲＱを停止することもできるので、２ｎｄ−ｅＮＢのリソースの使用効率を向上させることが可能となる。
【０５４８】
実施の形態８  変形例２．
実施の形態８で示した課題を解決する他の方法を開示する。２ｎｄ−ｅＮＢは、２ｎｄ−ｅＮＢ向けに設定されたＳＰＳリソースの上り電力を測定する。２ｎｄ−ｅＮＢは、上り通信品質を測定してもよい。
【０５４９】
２ｎｄ−ｅＮＢは、上り電力として、受信信号強度（ＲＳＳＩ）、または、ＩＯＴ（Interference over Thermal noise）、ＲＳＲＰ、信号対干渉雑音電力比（Signal to Interference plus Noise power Ratio；略称：ＳＩＮＲ）などを測定するとよい。あるいは、２ｎｄ−ｅＮＢは、設定されたＳＰＳリソースに用いるＰＵＳＣＨのリファレンス信号の受信電力を測定してもよい。
【０５５０】
２ｎｄ−ｅＮＢは、上り通信品質として、ＲＳＲＱを測定するとよい。あるいは、２ｎｄ−ｅＮＢは、ＰＵＳＣＨのリファレンス信号の受信品質を測定してもよい。
【０５５１】
２ｎｄ−ｅＮＢは、自身に設定されたＳＰＳリソースの上り電力あるいは上り通信品質が予め定める閾値よりも高い場合は、２ｎｄ−ｅＮＢに上りデータが送信されたと判断する。
【０５５２】
２ｎｄ−ｅＮＢは、自身に設定されたＳＰＳリソースの上り電力あるいは上り通信品質が予め定める閾値よりも低い場合は、２ｎｄ−ｅＮＢに上りデータが送信されなかったと判断する。
【０５５３】
２ｎｄ−ｅＮＢが、ＨＡＲＱを動作させるか否かを判断する方法を開示する。２ｎｄ−ｅＮＢは、２ｎｄ−ｅＮＢ自身向けにデータが送信されたと判断した場合は、ＨＡＲＱを動作させる。２ｎｄ−ｅＮＢは、２ｎｄ−ｅＮＢ自身向けにデータが送信されていないと判断した場合は、ＨＡＲＱを停止させる。
【０５５４】
測定を必要とするので、時間的に２ｎｄ−ｅＮＢで行うＨＡＲＱに即座に対応できない場合がある。しかし、たとえ、即座にＨＡＲＱに対応できないとしても、測定などによる遅延の後には対応可能となる。したがって、延々とＨＡＲＱが続くことを防ぐことができる。これによって、２ｎｄ−ｅＮＢのリソースの使用効率を向上させることが可能となる。
【０５５５】
また、ｅＮＢ間のシグナリングが不要となり、シグナリング量の増大を抑制することが可能となる。
【０５５６】
実施の形態９．
ＵＥは、上り送信データのデータ量がＤＲＡＴの閾値以下の場合、２ｎｄ−ｅＮＢに上りデータを送信しない。２ｎｄ−ｅＮＢに上りデータの送信が無いにも関わらず、パディング送信を行うことは、ＵＥの消費電力の無駄となる。
【０５５７】
しかし、インプリシットリリースが動作している場合、パディング送信が行われないと、インプリシットリリースが行われず、設定されたＳＰＳリソースのリリースが行われなくなる。ＳＰＳリソースがリリースされないと、該リソースを他のＵＥに使用させることができず、ＰＵＳＣＨリソースの使用効率が低減する。本実施の形態では、このような課題を解決する方法を開示する。
【０５５８】
上り送信データが無い場合のパディング送信の頻度を変える。具体的には、パディング送信を間引く。
【０５５９】
以上に開示したパディング送信の方法では、上り送信データのデータ量がＤＲＡＴの閾値以下の場合、常に２ｎｄ−ｅＮＢにパディング送信を行う。これに対して、本実施の形態で開示する方法では、上り送信データのデータ量がＤＲＡＴの閾値以下の場合に、２ｎｄ−ｅＮＢに送信するパディング送信を間引く。
【０５６０】
例えば、パディング送信を２回に１回間引く場合について示す。ＵＥは、１回目のパディング送信の実行タイミングでは、パディング送信を行わない。ＵＥは、２回目のパディング送信の実行タイミングで、パディング送信を行う。
【０５６１】
このように何回に１回パディング送信を行うか、すなわちパディング送信を行う頻度を、「パディング送信頻度」という場合がある。前述の例では、パディング送信頻度は、「２」である。
【０５６２】
パディング送信頻度は、予め規格などで静的に決められてもよいし、準静的あるいは動的に変更されてもよい。パディング送信頻度は、ｅＮＢによって設定され、ｅＮＢからＵＥへ通知されてもよい。ｅＮＢからＵＥへ通知される場合、ＳＰＳの設定のメッセージに含めてもよいし、ＳＰＳアクティベートに含めてもよい。
【０５６３】
図２４は、パディング送信を間引いた場合のインプリシットリリース方法を説明する図である。１ｓｔ−ｅＮＢをＭｅＮＢとし、２ｎｄ−ｅＮＢをＳｅＮＢとする。ＳｅＮＢにＳＰＳが設定された場合を示している。パディング送信頻度が「２」の場合について示している。インプリシットリリースのためのリリース前空送信回数を「３」とする。既にＳｅＮＢに対するＳＰＳの設定は行われているものとする。
【０５６４】
ステップＳＴ２２０９において、ＳｅＮＢは、ＵＥに、ＰＤＣＣＨを用いて、上りＳＰＳの上りグラントでアクティベートを通知する。該アクティベートに、パディング送信頻度の情報を含める。これによって、ＵＥは、パディング送信を間引く回数を認識することができる。
【０５６５】
ステップＳＴ２２０１において、ＳｅＮＢに対して設定されたＳＰＳのタイミングで、ＵＥでＤＲＡＴの閾値以上のデータ量の上りデータが発生した場合を考える。この場合、ステップＳＴ２２０１において、ＵＥは、ＳｅＮＢに対して設定されたＳＰＳリソースで、ＳｅＮＢに上りデータを送信する。
【０５６６】
ステップＳＴ２２０２において、ＳｅＮＢに対して設定されたＳＰＳのタイミングで、ＤＲＡＴの閾値よりも小さいデータ量の上りデータが発生した場合、ＵＥは、ＳｅＮＢに対するパディング送信タイミングが１回目であると判断し、パディング送信を行わない。
【０５６７】
ステップＳＴ２２０３において、ＳｅＮＢに対して設定されたＳＰＳのタイミングで、ＤＲＡＴの閾値よりも小さいデータ量の上りデータが発生した場合、ＵＥは、ＳｅＮＢに対するパディング送信タイミングが２回目であると判断する。ＵＥは、パディング送信頻度が「２」であることから、パディング送信を行う。
【０５６８】
ＵＥは、ＳｅＮＢにパディング送信を行った場合、パディング送信タイミングのカウントをリセットする。
【０５６９】
ＵＥは、パディング送信タイミングのカウントをリセットした後、ステップＳＴ２２０４において、ＳｅＮＢに対して設定されたＳＰＳのタイミングで、ＤＲＡＴの閾値よりも小さいデータ量の上りデータが発生した場合、ＳｅＮＢに対するパディング送信タイミングが１回目であると判断し、パディング送信を行わない。
【０５７０】
ステップＳＴ２２０５において、ＳｅＮＢに対して設定されたＳＰＳのタイミングで、ＤＲＡＴの閾値よりも小さいデータ量の上りデータが発生した場合、ＵＥは、ＳｅＮＢに対するパディング送信タイミングが２回目であると判断する。ＵＥは、パディング送信頻度が「２」であることから、パディング送信を行う。
【０５７１】
ＵＥは、ＳｅＮＢにパディング送信を行った場合、パディング送信タイミングのカウントをリセットする。
【０５７２】
同様に、ステップＳＴ２２０６において、ＵＥは、ＳｅＮＢにパディング送信を行わない。ステップＳＴ２２０７において、ＵＥは、ＳｅＮＢにパディング送信を行う。そして、ＵＥは、パディング送信タイミングのカウントをリセットする。
【０５７３】
ステップＳＴ２２０３において、ＳｅＮＢは、ＵＥからの１回目のパディング送信を受信する。また、ステップＳＴ２２０５において、ＳｅＮＢは、ＵＥからの２回目のパディング送信を受信し、ステップＳＴ２２０７において、ＳｅＮＢは、ＵＥからの３回目のパディング送信を受信する。
【０５７４】
ステップＳＴ２２０３からステップＳＴ２２０７において、ＳｅＮＢは、ＵＥからのパディング送信を受信している間に上りデータを受信せず、パディング送信をリリース前空送信回数、ここでは３回連続で受信したので、インプリシットリリースを行う。そして、ステップＳＴ２２０８において、ＳｅＮＢは、設定されたＳＰＳリソースをリリースする。ＳｅＮＢに、パディング送信をリリース前空送信回数、ここでは３回連続で送信した場合、ステップＳＴ２２０８において、ＵＥは、ＳＰＳの設定をクリアする。
【０５７５】
このようにすることによって、ＳｅＮＢに対して設定されたＳＰＳのタイミングで、上り送信データが無い場合のパディング送信を減らすことが可能となる。パディング送信を減らすことによって、ＵＥの消費電力の低減が可能となる。
【０５７６】
また、パディング送信は実行されるので、インプリシットリリースを動作させることは可能となる。したがって、ＰＵＳＣＨリソースの使用効率の低減を抑制することが可能となる。
【０５７７】
図２４に示す例では、ＵＥは、パディング送信を行った場合、パディング送信タイミングのカウントをリセットするようにした。他の方法として、ＵＥは、パディング送信を行った場合と上りデータの送信を行った場合とに、パディング送信タイミングのカウントをリセットするようにしてもよい。上りデータの送信を行った場合も、パディング送信タイミングのカウントをリセットすることになるので、さらにパディング送信回数を低減することが可能となる。
【０５７８】
パディング送信タイミングのカウントをリセットする方法は、予め規格などで静的に決められていてもよいし、ｅＮＢからＵＥに通知してもよい。該通知は、ＳＰＳの設定のメッセージに含めてもよいし、ＳＰＳアクティベートに含めてもよい。パディング送信頻度とともに通知してもよい。
【０５７９】
図２５は、パディング送信を間引いた場合のインプリシットリリース方法の他の例を示す図である。１ｓｔ−ｅＮＢをＭｅＮＢとし、２ｎｄ−ｅＮＢをＳｅＮＢとする。ＳｅＮＢにＳＰＳが設定された場合を示している。
【０５８０】
図２５は、図２４と類似しているので、主として異なる部分について説明する。
【０５８１】
図２５では、パディング送信頻度が「４」の場合について示している。
【０５８２】
インプリシットリリースのためのリリース前空送信回数ではなく、インプリシットリリースのための予め定めるパディング送信タイミング回数を設ける。インプリシットリリースのための予め定めるパディング送信タイミング回数として、「implicitReleaseAfter_T」というパラメータを用いる。以下の説明では、インプリシットリリースのための予め定めるパディング送信タイミング回数を、「リリース前空送信タイミング回数」という場合がある。図２５では、リリース前空送信タイミング回数を「８」とする。ＵＥは、パディング送信を行った場合と上りデータの送信を行った場合とに、パディング送信タイミングのカウントをリセットするようにするとよい。
【０５８３】
リリース前空送信タイミング回数は、予め規格などで静的に決められてもよいし、ｅＮＢからＵＥへ通知されてもよい。ｅＮＢからＵＥへ通知される場合、ＳＰＳの設定のメッセージに含めてもよいし、ＳＰＳアクティベートに含めてもよい。
【０５８４】
既にＳｅＮＢに対するＳＰＳの設定は行われているものとする。ステップＳＴ２３１０において、ＳｅＮＢは、ＵＥに、ＰＤＣＣＨを用いて、上りＳＰＳの上りグラントでアクティベートを通知する。該アクティベートに、パディング送信頻度の情報を含める。また、リリース前空送信タイミング回数の情報を含める。これによって、ＵＥは、パディング送信を間引く回数と、インプリシットリリースのための予め定めるパディング送信タイミング回数とを認識することができる。
【０５８５】
ステップＳＴ２３１１において、ＳｅＮＢに対して設定されたＳＰＳのタイミングで、ＵＥでＤＲＡＴの閾値以上のデータ量の上りデータが発生した場合を考える。この場合、ステップＳＴ２３１１において、ＵＥは、ＳｅＮＢに対して設定されたＳＰＳリソースで、ＳｅＮＢに上りデータを送信する。
【０５８６】
ＵＥは、上りデータの送信を行った場合、パディング送信タイミングのカウントをリセットする。
【０５８７】
ステップＳＴ２３０１において、ＳｅＮＢに対して設定されたＳＰＳのタイミングで、ＤＲＡＴの閾値よりも小さいデータ量の上りデータが発生した場合、ＵＥは、パディング送信タイミングが１回目であると判断し、パディング送信を行わない。
【０５８８】
ステップＳＴ２３０２において、ＳｅＮＢに対して設定されたＳＰＳのタイミングで、ＤＲＡＴの閾値よりも小さいデータ量の上りデータが発生した場合、ＵＥは、パディング送信タイミングが２回目であると判断し、パディング送信を行わない。
【０５８９】
ステップＳＴ２３０３において、ＳｅＮＢに対して設定されたＳＰＳのタイミングで、ＤＲＡＴの閾値よりも小さいデータ量の上りデータが発生した場合、ＵＥは、パディング送信タイミングが３回目であると判断し、パディング送信を行わない。
【０５９０】
ステップＳＴ２３０４において、ＳｅＮＢに対して設定されたＳＰＳのタイミングで、ＤＲＡＴの閾値よりも小さいデータ量の上りデータが発生した場合、ＵＥは、パディング送信タイミングが４回目であると判断し、パディング送信頻度が「４」であることから、パディング送信を行う。
【０５９１】
ＵＥは、パディング送信を行った場合、パディング送信タイミングのカウントをリセットする。
【０５９２】
ＵＥは、パディング送信タイミングのカウントをリセットした後、ステップＳＴ２３０５において、ＳｅＮＢに対して設定されたＳＰＳのタイミングで、ＤＲＡＴの閾値よりも小さいデータ量の上りデータが発生した場合、パディング送信タイミングが１回目であると判断し、パディング送信を行わない。
【０５９３】
同様に、ステップＳＴ２３０６およびステップＳＴ２３０７において、ＵＥは、パディング送信を行わない。ステップＳＴ２３０８において、ＵＥは、パディング送信を行う。そして、ＵＥは、パディング送信タイミングのカウントをリセットする。
【０５９４】
ステップＳＴ２３０４において、ＳｅＮＢは、ＵＥからの１回目のパディング送信を受信する。ＳｅＮＢは、ＵＥからのパディング送信を１回受信したので、パディング送信頻度が「４」であることを考慮して、パディング送信タイミングが４回以上となったと判断する。リリース前空送信タイミング回数は８以上になっていないので、ＳｅＮＢは、ＳＰＳリソースを維持し、該ＳＰＳリソースでＵＥからの受信を行う。
【０５９５】
ステップＳＴ２３０８において、ＳｅＮＢは、ＵＥからの２回目のパディング送信を受信する。ＳｅＮＢは、ＵＥからのパディング送信を２回連続で受信したので、リリース前空送信タイミング回数が８以上になったと判断する。
【０５９６】
リリース前空送信タイミング回数が８以上になったと判断したＳｅＮＢは、インプリシットリリースを行い、ステップＳＴ２３０９において、設定されたＳＰＳリソースをリリースする。
【０５９７】
ＵＥは、ＳｅＮＢに対する、パディング送信タイミングがリリース前空送信タイミング回数連続した場合、ＳＰＳの設定をクリアする。あるいは、パディング送信を連続２回行ったので、パディング頻度が「４」であることを考慮して、パディング送信タイミングがリリース前空送信タイミング回数以上連続したと判断し、インプリシットリリースを行う、設定されたＳＰＳリソースをクリアしてもよい。
【０５９８】
パディング送信をしない場合のＨＡＲＱに関しては、実施の形態８から実施の形態８の変形例２で開示した方法を適用してもよい。
【０５９９】
本実施の形態で開示した方法を用いることによって、ＳｅＮＢに対して設定されたＳＰＳのタイミングで、上りデータの送信が無い場合のパディング送信を減らすことが可能となる。パディング送信を減らすことによって、ＵＥの消費電力の低減が可能となる。
【０６００】
また、パディング送信は実行されるので、インプリシットリリースを動作させることは可能となる。したがって、ＰＵＳＣＨリソースの使用効率の低減を抑制することが可能となる。
【０６０１】
また、パディング送信頻度を設定可能とすることによって、２ｎｄ−ｅＮＢに対してＳＰＳが設定されたＵＥ毎あるいはベアラ毎に、該通信の所望の通信品質、許容遅延量、あるいはＵＥの所望の連続動作時間などの要求に柔軟に応じることが可能となる。
【０６０２】
実施の形態１０．
実施の形態１から実施の形態９では、ＵＬスプリットベアラの設定時、２ｎｄ−ｅＮＢにＳＰＳを設定した場合に生じる課題を示し、その解決策を開示した。そもそも、そのような課題が生じる頻度を少なくすることが要求される。本実施の形態では、そのような課題が生じる頻度を少なくする方法を開示する。
【０６０３】
複数の通信あるいはベアラでデータの発生周期が異なる場合、短周期で発生するデータが存在する通信あるいはベアラに対するＳＰＳを１ｓｔ−ｅＮＢに設定する。
【０６０４】
１ｓｔ−ｅＮＢのＳＰＳの周期が２ｎｄ−ｅＮＢのＳＰＳ周期以下（１ｓｔ−ｅＮＢのＳＰＳの周期≦２ｎｄ−ｅＮＢのＳＰＳ周期）と設定するとよい。
【０６０５】
ＤＲＡＴの閾値は、短周期で発生するデータ量の最大値あるいはそれ以上とするとよい。あるいは、ＤＲＡＴの閾値は、長周期で発生するデータ量の最小値以下としてもよい。
【０６０６】
このようにすることによって、ＵＬスプリットベアラの設定時、２ｎｄ−ｅＮＢにＳＰＳを設定した場合に、２ｎｄ−ｅＮＢで発生するＳＰＳのタイミング回数を少なくすることが可能となる。他方、１ｓｔ−ｅＮＢは、常に上りデータを送信することが可能であるので、通常のＳＰＳ処理が可能である。したがって、実施の形態１から実施の形態９で示したような課題が生じる頻度を少なくすることができる。
【０６０７】
ｅＮＢおよびＵＥの不安定な動作および誤動作の発生の低減、無線リソースの使用効率の向上、ならびにＵＥの低消費電力化を図ることが可能となる。
【０６０８】
複数の異なる通信容量のデータあるいはベアラが存在した場合、大容量の方が短周期で発生する場合、大容量通信に適するｅＮＢを１ｓｔ−ｅＮＢとしてもよい。１ｓｔ−ｅＮＢは、常に上りデータを送信することが可能であるので、大容量通信に適するｅＮＢを１ｓｔ−ｅＮＢにすることによって、大容量通信に適するＳＰＳ処理が可能となる。
【０６０９】
実施の形態１０  変形例１．
実施の形態１０で述べた課題を解決するための他の方法を開示する。一つのＵＥに対して、一つのｅＮＢが複数のＳＰＳを設定することを可能とするとよい。例えば、一つのＵＥに対して、一つのｅＮＢが、ベアラ毎にＳＰＳの設定を行う。ベアラの中には、ある程度、ベアラ毎のデータの発生周期およびデータ量を把握できるものがある。ベアラ毎にＳＰＳの設定を行うことによって、ベアラ毎のデータの発生周期およびデータ量に適したＳＰＳの設定を行うことが可能となる。
【０６１０】
また、ＤＲＡＴの閾値は、ベアラ毎に設定される。したがって、ベアラ毎にＳＰＳの設定を行うことによって、ベアラ毎のデータの発生周期およびデータ量に適したＳＰＳの設定、ならびにＤＲＡＴの閾値の設定を行うことが可能となる。これによって、実施の形態１から実施の形態９で示したような課題が生じる頻度を少なくすることができる。また、ベアラ毎の所望の通信品質、許容遅延量などの要求に柔軟に応じることが可能となる。
【０６１１】
ＳＰＳの設定は、ベアラ毎ではなく、一つ以上のベアラを含むベアラグループ毎としてもよい。例えば、同程度のデータの発生周期およびデータ量を有するベアラを同一グループとすることによって、ｅＮＢが一つのＵＥに対して設定するＳＰＳを少なくすることが可能となり、制御の簡略化を行うことが可能となる。
【０６１２】
実施の形態１０  変形例２．
実施の形態１０で述べた課題を解決するための他の方法を開示する。ｅＮＢは、ＵＥからの上り送信データのデータ量の時間変化を測定し、その測定結果を用いて、上り送信データが発生する確率の時間変化を導出する。言い換えると、ｅＮＢは、上り送信データのデータ量の時間変化の測定結果を用いて、上り送信データが発生する確率の時間変化を予測する。
【０６１３】
上り送信データが発生する確率を導出するために、統計的処理を行ってもよい。導出した上り送信データが発生する確率の時間変化から、どの上り送信タイミングにおいて上り送信データが発生する確率が高いかを導出する。
【０６１４】
ｅＮＢは、導出した上り送信データが発生する確率の時間変化に応じて、ＳＰＳの設定、ＳＰＳリソースのスケジューリング、ならびにＳＰＳのアクティベーションおよびデアクティベーションを行う。このようにすることによって、ｅＮＢは、ＵＥからの上り送信データのデータ量の時間変化に適したＳＰＳの設定が可能となる。
【０６１５】
上り送信データが発生する確率の時間変化を導出することを開示したが、データの発生量の時間変化についても導出してもよい。これによって、ＳＰＳリソースとして、どの程度無線リソースを割り当てたらよいかを導出することが可能となる。したがって、ＳＰＳリソースのスケジューリングを精度良く行うことが可能となる。
【０６１６】
ｅＮＢがＵＥからの上り送信データのデータ量の時間変化を測定し、その測定結果を用いて、上り送信データが発生する確率の時間変化を導出する方法を開示したが、ＵＥが上り送信データの発生量の時間変化を測定し、その測定結果を用いて、上り送信データが発生する確率の時間変化を導出してもよい。上り送信データが発生する確率を導出するために、統計的処理を行ってもよい。ＵＥは、導出した上り送信データが発生する確率の時間変化から、どの上り送信タイミングにおいて上り送信データが発生する確率が高いかを導出する。
【０６１７】
ＵＥは、導出した上り送信データが発生する確率の時間変化、または、どの上り送信タイミングにおいて上り送信データが発生する確率が高いかに関する情報を、ｅＮＢに通知する。この通知には、ＲＲＣシグナリングを用いるとよい。ＲＲＣシグナリングを用いることによって、大きい情報量を通知することが可能となる。
【０６１８】
ＭＡＣシグナリング、またはＬ１／Ｌ２制御信号を用いて通知してもよい。ＭＡＣシグナリング、またはＬ１／Ｌ２制御信号を用いた場合、通知できる情報量は小さくなるが、通知に要する時間を短縮することが可能となる。したがって、導出した値を低遅延で反映できることになる。
【０６１９】
ｅＮＢは、ＵＥから通知された、導出した上り送信データが発生する確率の時間変化、または、どの上り送信タイミングにおいて上り送信データが発生する確率が高いかに関する情報を用いて、ＳＰＳの設定、ＳＰＳリソースのスケジューリング、ならびにＳＰＳのアクティベーションおよびデアクティベーションを行う。
【０６２０】
このようにすることによって、ＵＥにおいて発生する上り送信データの時間変化をＵＥが直接測定できるので、電波伝搬環境によらずに、上り送信データが発生する確率の時間変化を導出することが可能となる。
【０６２１】
ＵＥが、導出した上り送信データが発生する確率の時間変化に応じて、ＳＰＳの設定、ＳＰＳリソースのスケジューリングおよびＳＰＳタイミングを導出してもよい。ＵＥは、導出したＳＰＳの設定、ＳＰＳリソースのスケジューリングおよびＳＰＳタイミングに関する情報を、ｅＮＢに通知する。このようにすることによって、ＵＥからｅＮＢに通知する情報量を低減することが可能となる。
【０６２２】
上り送信データのデータ量あるいは上り送信データの発生量の時間変化の測定、および上り送信データが発生する確率の時間変化の導出は、ＵＥ毎、またはベアラ毎に行ってもよい。あるいは、コンテンツ毎、または、アプリケーション毎に行ってもよい。これによって、ＵＥ毎、ベアラ毎、コンテンツ毎、アプリケーション毎に適したＳＰＳの設定を行うことが可能になる。
【０６２３】
上り送信データが発生する確率の時間変化を導出することを開示したが、上り送信データの発生量の時間変化について導出してもよい。または、上りスループットの時間変化について導出してもよい。これらの値を用いることによって、ＳＰＳリソースとして、どの程度無線リソースを割り当てたらよいかを導出することが可能となる。したがって、ＳＰＳリソースのスケジューリングを精度良く行うことが可能となる。
【０６２４】
前述の方法を、２ｎｄ−ｅＮＢのＳＰＳの設定に適用することによって、２ｎｄ−ｅＮＢにおいてＳＰＳリソースが割り当てられているにも関わらず、ＵＥで上り送信データが発生しないという状況を低減することが可能となる。また、１ｓｔ−ｅＮＢのＳＰＳの設定に適用してもよい。１ｓｔ−ｅＮＢにおいても、適切なＳＰＳの設定が可能となる。
【０６２５】
前述の方法では、上り送信データが発生する確率の時間変化に応じて、ＳＰＳの設定、ＳＰＳリソースのスケジューリングおよびＳＰＳタイミングを導出することを開示した。他の方法として、ＤＲＡＴの閾値の設定に適用してもよい。上り送信データが発生する確率の時間変化に応じて、ＤＲＡＴの閾値を設定する。
【０６２６】
例えば、ｅＮＢは、上り送信データが発生する確率の時間変化を導出した結果を、ＤＣを行っている他のｅＮＢに通知してもよい。また、他のｅＮＢは、自ｅＮＢへの上り送信データが発生する確率の時間変化を導出してもよい。他のｅＮＢは、これらの情報を用いて、ＤＲＡＴの閾値の設定を行うとよい。他のｅＮＢは、各ｅＮＢへの上り送信データが発生する確率の時間変化が判るので、ＤＲＡＴの閾値をどのように設定したら良いかを柔軟に判断することが可能となる。
【０６２７】
実施の形態１０の変形例１および変形例２で開示した方法は、１ｓｔ−ｅＮＢに適用してもよい。また、適宜、ＤＣが設定された場合に限らず適用してもよい。これによって、実施の形態１０の変形例１および変形例２と同様の効果を得ることができる。
【０６２８】
実施の形態１１．
３ＧＰＰで、一つのセルと接続状態のＵＥが上り送信を開始する場合の遅延の削減方法として、プレスケジューリングが検討されている。プレスケジューリングの方法として、ＳＰＳを用いる方法、ダイナミックスケジューリングを用いる方法がある（非特許文献１０参照）。しかし、これらの方法は、ＵＥが一つのセルと接続されている場合の方法であり、デュアルコネクティビティ（ＤＣ）が設定されている場合のプレスケジューリングの方法については、何ら議論されていない。
【０６２９】
前述のように、３ＧＰＰでは、ＵＥが２つのｅＮＢと接続して通信を行うＤＣが導入されている。ＤＣは、通信容量の増大を図る上で重要な技術である。本実施の形態では、ＵＥにＤＣが設定されている場合のプレスケジューリングの設定方法を開示する。
【０６３０】
プレスケジューリングをサポートするｅＮＢをＭｅＮＢのみとする。プレスケジューリングをサポートするｅＮＢは、予め規格などで静的に決めておくとよい。
【０６３１】
プレスケジューリングをサポートするｅＮＢを決めておかないと、例えばＳｅＮＢが独自にＵＥにプレスケジューリングを設定するが、ＵＥは、ＳｅＮＢに対してはプレスケジューリングを対応していない状態が生じる可能性がある。このような場合、誤動作が発生し、ＤＣを実行できなくなってしまう可能性が生じる。したがって、プレスケジューリングをサポートするｅＮＢは、予め静的に決めておくことによって、ＵＥおよびｅＮＢ間でＤＣにおけるプレスケジューリングの設定方法が明確になり、誤動作が生じることを低減することができる。
【０６３２】
ＤＣでは、両ｅＮＢからデータの送信が可能である。したがって、ＭｅＮＢのみプレスケジューリングをサポートした場合、ベアラとしての上り送信の遅延の低減量は少ない。
【０６３３】
したがって、ＤＣでは、ＳｅＮＢでプレスケジューリングをサポートするとよい。プレスケジューリングをサポートするｅＮＢを、ＤＣでは、ＭｅＮＢおよびＳｅＮＢにするとよい。ＭｅＮＢおよびＳｅＮＢに対して、同時にプレスケジューリングをサポートするとしてもよい。ＭｅＮＢおよびＳｅＮＢに対するプレスケジューリングの設定は同じとするとよい。
【０６３４】
スプリットベアラにおける２ｎｄ−ｅＮＢのＳＰＳの設定においては、前述の実施の形態で開示した方法を適用してもよい。
【０６３５】
このようにすることによって、ＳｅＮＢに対してもプレスケジューリングの設定が可能となる。したがって、ＳｅＮＢに対しても上りデータの送信を開始する時間を短縮することが可能となるので、ベアラとしての上り送信の遅延の低減量を増大させることができる。
【０６３６】
ＭｅＮＢでのプレスケジューリングの設定と、ＳｅＮＢでのプレスケジューリングの設定とを異ならせてもよい。ＭｅＮＢおよびＳｅＮＢの各ｅＮＢに対して、プレスケジューリングを別々に、つまり独立に設定可能としてもよい。
【０６３７】
ＤＣでは、ベアラ毎にスプリット構成を設定できるので、ｅＮＢ毎に送信するデータは異なる。例えば、ベアラ＃１は、ＭｅＮＢとＳｅＮＢとを用いたスプリットベアラを設定し、ベアラ＃２は、ＭｅＮＢを用いたスプリットベアラではないノンスプリットのベアラを設定することも可能である。したがって、ＤＣで設定するｅＮＢ毎に送信するデータは異なってくるので、ＤＣで設定するｅＮＢ毎に要求される遅延量も異なる。
【０６３８】
以上のように、ｅＮＢ毎に独立のプレスケジューリングを設定可能とすることによって、ベアラの設定を考慮したプレスケジューリングの設定が可能となる。これによって、ＤＣが設定されたｅＮＢ毎に要求される遅延量を満たすことが可能となる。
【０６３９】
ベアラ毎に各ｅＮＢのプレスケジューリングを独立に設定可能としてもよい。例えば、前述の例では、ベアラ＃１のＭｅＮＢとＳｅＮＢとに対するプレスケジューリングの設定と、ベアラ＃２のＭｅＮＢに対するプレスケジューリングの設定とを独立に設定可能としてもよい。このように、ベアラ毎に各ｅＮＢのプレスケジューリングを独立に設定可能とすることによって、ベアラによって異なる要求遅延量を満たすことが可能となる。
【０６４０】
プレスケジューリングを設定する主体、およびプレスケジューリングの設定をＵＥに通知する方法について開示する。
【０６４１】
ＭｅＮＢがプレスケジューリングの設定を行う。ＭｅＮＢがＭｅＮＢおよびＳｅＮＢのプレスケジューリングの設定を行う。ＭｅＮＢは、ＳｅＮＢのプレスケジューリングの設定をＳｅＮＢに通知する。該設定には設定解除を含んでもよい。ＳｅＮＢは、ＭｅＮＢから通知されたプレスケジューリングの設定に対して、可否（許可／不許可）を判断してもよい。ＳｅＮＢは、ＭｅＮＢから通知されたプレスケジューリングの設定を許可する場合、ＭｅＮＢに、許可を示す情報を通知するとよい。ＳｅＮＢは、ＭｅＮＢから通知されたプレスケジューリングの設定を不許可にする場合、ＭｅＮＢに、不許可を示す情報を通知するとよい。
【０６４２】
ＭｅＮＢは、ＳｅＮＢから不許可の通知を受信した場合、プレスケジューリングの設定を変更して、再度ＳｅＮＢに通知してもよい。ＳｅＮＢから許可の通知を受信するまで再設定を繰り返すとよい。
【０６４３】
ＭｅＮＢとＳｅＮＢとの間で行われるプレスケジューリングの設定の通知には、Ｘ２インタフェースを用いてもよい。ＳｅＮＢの追加、解除または修正のメッセージに含めて通知してもよい。ＳｅＮＢとＭｅＮＢとの間で行われる許可／不許可を示す情報の通知には、Ｘ２インタフェースを用いてもよい。
【０６４４】
ＭｅＮＢは、ＭｅＮＢおよびＳｅＮＢの少なくとも一方に対するプレスケジューリングの設定を、ＵＥに通知する。プレスケジューリングの設定の通知には、Ｕｕインタフェースを用いてもよい。プレスケジューリングの設定は、ＤＣを設定するためのメッセージに含めて通知してもよい。
【０６４５】
他の方法として、ＳｅＮＢが、ＳｅＮＢのプレスケジューリングの設定を行ってもよい。ＳｅＮＢは、ＵＥに、プレスケジューリングの設定を通知する。
【０６４６】
あるいは、ＳｅＮＢは、ＭｅＮＢに、ＳｅＮＢのプレスケジューリングの設定を通知してもよい。プレスケジューリングの設定は、Ｘ２インタフェースを用いて通知してもよい。ＳｅＮＢから、ＳｅＮＢのプレスケジューリングの設定を受信したＭｅＮＢは、該設定をＵＥに通知するとよい。
【０６４７】
プレスケジューリングの設定は、ベアラの設定に依存するところが大きい。したがって、ベアラに設定された情報を用いてＤＣを設定するＭｅＮＢが、プレスケジューリングの設定を行うことがより好ましい。
【０６４８】
本実施の形態で開示する方法を用いることによって、ＵＥに２つのｅＮＢと接続して通信を行うＤＣが設定されている場合にも、プレスケジューリングを行うことが可能となる。
【０６４９】
これによって、通信容量の増大を図るとともに、上り送信の遅延の低減を図ることが可能となり、より短時間に大容量の通信を行うことが可能となる。
【０６５０】
本実施の形態では、ＵＥにＤＣが設定されている場合のプレスケジューリングの設定方法を開示した。ＵＥにＤＣが設定されている場合ではなく、ＵＥに対してＤＣを設定する場合に、ＳｅＮＢに対してプレスケジューリングを設定するようにしてもよい。ｅＮＢは、ＳｅＮＢを追加するときに、ＳｅＮＢに対するプレスケジューリングを設定してもよい。このプレスケジューリングの設定に、本実施の形態で開示した方法を適宜適用するとよい。
【０６５１】
このようにすることによって、ＳｅＮＢの追加処理において、ＵＥがＳｅＮＢに対して従来行っていた、スケジューリング要求処理を省略することが可能となる。これによって、スケジューリング要求にかかる時間を削減することが可能となるので、ＤＣを設定する時間を短縮することが可能となる。また、通信における遅延を低減し、より短時間に大容量の通信を行うことが可能となる。
【０６５２】
本実施の形態で開示した方法は、ＳｅＮＢの追加を行う場合に限らず、ＳｅＮＢの修正を行う場合にも適用できる。修正後のＳｅＮＢに対して、本実施の形態で開示したプレスケジューリング方法を適宜適用するとよい。これによって、本実施の形態と同様の効果を得ることができる。
【０６５３】
以上の実施の形態およびその変形例では、デュアルコネクティビティ（ＤＣ）でスプリットベアラがサポートされた場合について開示した。ＤＣに限らず、複数のｅＮＢを用いて通信を行うマルチコネクティビティの場合にも適用することができる。マルチコネクティビティでスプリットベアラが行われた場合に、予め決められた規則に従って、マルチコネクティビティを構成するｅＮＢのうちの一つまたは複数のｅＮＢに上りデータが送信されないような場合に適用するとよい。これによって、以上の実施の形態およびその変形例と同様の効果を得ることができる。
【０６５４】
以上の実施の形態およびその変形例では、ＵＬスプリットベアラが設定されＤＲＡＴが用いられた場合において、ＳＰＳが設定された場合について開示したが、ＳＰＳが設定された場合ではなく、ダイナミックスケジューリングが行われた場合に適用してもよい。ＤＲＡＴが用いられた場合においてＳＰＳが設定された場合のＤＲＡＴの閾値の設定方法、およびパディング送信に関する方法を、ＤＲＡＴが用いられた場合においてダイナミックスケジューリングが行われた場合に適用してもよい。
【０６５５】
例えば、ＤＲＡＴの閾値が設定された場合に置いて、２ｎｄ−ｅＮＢがＵＥにダイナミックスケジューリングで上りグラントが通知されたときに、その上りグラントのリソースで、ＵＥで上り送信データが発生しなかった場合に、ＳＰＳが設定された場合と同様の問題が生じる。また、ＤＲＡＴの閾値が設定された場合において、２ｎｄ−ｅＮＢにおいてプレスケジューリングによるダイナミックスケジューリングが行われたときに、プレスケジューリングされたリソースで、ＵＥで上り送信データが発生しなかった場合などにも同様の問題が生じる。
【０６５６】
このような問題を解決するために、実施の形態１、実施の形態２、実施の形態２の変形例１、実施の形態５、実施の形態７、実施の形態８、実施の形態８の変形例１、実施の形態８の変形例２で開示した方法を適宜適用するとよい。ＤＲＡＴが用いられた場合においてダイナミックスケジューリングが行われた場合にも、同様の効果を得ることができる。
【０６５７】
実施の形態１２．
ｅＮＢとＵＥとが通信を行うときに、ｅＮＢが複数のアンテナを用いて、通信対象の端末であるＵＥの方向にのみビームを形成するビームフォーミングを利用して信号を送る技術がある。ビームフォーミングを用いてｅＮＢのサービスエリアをカバーする方法として、方向が固定されたビームを複数並べる方法がある。この場合、ｅＮＢは、ＵＥの移動に合わせて固定ビームを切り替え、適切なビームを使用する。
【０６５８】
図２６は、多素子アンテナを用いたビームフォーミングを説明する図である。ｅＮＢは、図４に示すアンテナ４０８を、多素子アンテナ２４０１によって構成する。
【０６５９】
ｅＮＢは、多素子アンテナ２４０１の一部または全部の複数のアンテナを用いて、予め定める方向のみにビームを形成し、通信対象となるＵＥ２４０２との間で通信を行う。図２６に示すように、ビームフォーミングを用いて形成する各ビームのカバレッジ２４０３，２４０４，２４０５は、狭カバレッジとなる。ｅＮＢは、異なる方向に固定された狭カバレッジを有する複数のビームを形成することによって、サービスエリアをカバーする。
【０６６０】
ＵＥ２４０２が第１のビームのカバレッジ２４０３に存在する場合、ｅＮＢは、ＵＥ２４０２と、第１のビームを用いて通信を行う。ＵＥ２４０２が、第２のビームのカバレッジ２４０４に移動した場合、ｅＮＢは、第１のビームから第２のビームに切り替えて、ＵＥ２４０２と通信を行う。以下、切替元のビームを「ソースビーム」といい、切替先のビームを「ターゲットビーム」という場合がある。
【０６６１】
ビームフォーミングを用いる場合、ｅＮＢによって構成されるサービスエリアは、複数のビームによって構成される狭カバレッジに分割される。したがって、ＵＥのビーム間の移動において高速なビーム切替処理が要求される。
【０６６２】
ｅＮＢは、セル毎にビームフォーミングを用いて複数のビームを形成してもよい。このような場合、一つのセル内でＵＥのビーム間移動においてビーム切替処理が生じる。
【０６６３】
ビーム切替処理において、ＵＥは、ターゲットビームと同期をとり、ｅＮＢは、ＵＥに対してターゲットビームの無線リソースのスケジューリングを行わなければならない。したがって、ＵＥのビーム間の移動においてビーム切替処理の高速化を可能とし、高速で安定な通信システムを提供することが求められる。
【０６６４】
ビーム切替処理の高速化を図るためには、このような同期処理および無線リソーススのケジューリング処理に要する時間の短縮が有効となる。
【０６６５】
本実施の形態では、ターゲットビームとの同期処理およびターゲットビームにおける無線リソースのスケジューリング処理の時間の短縮方法を開示する。
【０６６６】
ターゲットセルとの同期処理に、従来のセルとの同期方法を適用してもよい。ＵＥは、ターゲットビームで送信される同期信号、リファレンスシグナルおよびディスカバリーシグナルの少なくともいずれか１つを受信して、ターゲットビームと同期を行う。例えば、同期信号として、従来のセルで用いられているＰ−ＳＳおよびＳ−ＳＳなどの同期信号が用いられる場合、該同期信号を用いて同期を行うようにしてもよい。この場合、同期を行うために、少なくとも６サブフレームの期間が必要となる。
【０６６７】
従来のセルで用いられている同期信号は、セル毎のＰＣＩに１対１に対応するシンクロナイゼーションコードが割り当てられている。しかし、セル毎のＰＣＩでは、ＵＥは、どのビームと同期を行ったのかを認識することができない。このような問題を解決するために、ビーム毎の識別子を設け、各ビームの同期信号に、ビーム毎の識別子に１対１に対応するコードを割当てるとよい。
【０６６８】
このようにすることによって、ＵＥは、どのビームに対して同期を行ったかを認識することが可能となる。ビーム毎の識別子は、セル毎の識別子に重畳されて割当てられてもよい。ＵＥは、どのセルかを認識することが可能となり、さらには、どのビームかを認識することが可能となる。
【０６６９】
リファレンスシグナルおよびディスカバリーシグナルにも同様に、ビーム毎の識別子に１対１に対応するコードを割当ててもよい。ＵＥは、リファレンスシグナルまたはディスカバリーシグナルを受信して、ビーム毎の識別子を得ることによって、受信したビームがどのビームかを認識することが可能となる。
【０６７０】
しかし、従来のセルとの同期処理を適用した場合、前述のように、例えば同期信号を用いた場合、ＵＥが同期信号を受信するまでに少なくとも６サブフレームの期間が必要となる。ＵＥにおける同期処理に要する時間を考慮すると、従来のセルとの同期処理に要する時間は、さらに増大する。これらの同期処理に要する時間の短縮方法を開示する。
【０６７１】
ｅＮＢは、同一セル内のビーム間の同期をとる。ｅＮＢ内のビーム間の同期をとるとしてもよい。さらに具体的には、ビーム間で、サブフレームタイミングの同期、スロットタイミングの同期を行う。また、ＳＦＮ（System Frame Number）、無線フレームナンバ、およびスロットナンバも同期をとるとよい。
【０６７２】
このようにすることによって、ＵＥに対してビーム切替処理が行われたとしても、ターゲットビームに対して同期を行う必要が無くなる。したがって、同期処理に必要とした時間を削減することが可能となる。
【０６７３】
ターゲットビームにおける無線リソースのスケジューリングの処理時間の短縮方法を開示する。下りリンクの無線リソースのスケジューリング情報は、下り制御情報（Downlink Control Information：ＤＣＩ）に含まれる。下り制御情報は、Ｌ１／Ｌ２制御信号によって、ＵＥに通知される。ＬＴＥでは、ＰＤＣＣＨあるいはＥＰＤＣＣＨにマッピングされる。Ｌ１／Ｌ２制御信号のＣＲＣに、セル毎にＵＥ個別に割当てられた識別子（Ｃ−ＲＮＴＩ）がマスクされる。ＵＥは、自身のＣ−ＲＮＴＩを検出することによって、自身宛てのＬ１／Ｌ２制御信号を受信して下り制御情報を取得することができ、下りリンクの無線リソースのスケジューリング情報を取得することが可能となる。
【０６７４】
セル内のビームにおいて、Ｌ１／Ｌ２制御信号のＣＲＣにマスクするＵＥ個別の識別子に、同じ識別子を用いるとよい。セル毎にＵＥ個別に割当てられた識別子を用いるとよい。このようにすることによって、ＵＥは、セル内でビーム切替処理が行われたとしても、ソースビームで使用していたＣ−ＲＮＴＩを、ターゲットビームでも用いることが可能となる。
【０６７５】
したがって、ターゲットビームと同期を行った後、即座にＬ１／Ｌ２制御信号を受信することによって、スケジューリング情報を受信することが可能となる。
【０６７６】
セルを跨ぐビーム切替処理においては、予めｅＮＢはＵＥに、Ｃ−ＲＮＴＩを通知しておくとよい。ｅＮＢは、ソースビームを用いてＵＥにＣ−ＲＮＴＩを通知しておくとよい。このようにすることによって、セル間のビーム切替処理においても、ターゲットセルと同期した後、即座にＬ１／Ｌ２制御信号を受信し、スケジューリング情報を受信することが可能となる。
【０６７７】
他の方法として、ビーム毎にＵＥ個別に割当てる識別子（Ｂ−ＲＮＴＩとする）を設けてもよい。Ｌ１／Ｌ２制御信号のＣＲＣに、ビーム毎にＵＥ個別に割当てられた識別子をマスクするとよい。ビーム切替処理において、予めｅＮＢはＵＥに、Ｂ−ＲＮＴＩを通知しておくとよい。ｅＮＢは、ソースビームを用いてＵＥにＢ−ＲＮＴＩを通知しておくとよい。このようにすることによって、ビーム切替処理において、ターゲットセルと同期した後、即座にＬ１／Ｌ２制御信号を受信し、スケジューリング情報を受信することが可能となる。
【０６７８】
ビーム毎にＵＥ個別にＢ−ＲＮＴＩを割り当てることによって、セル内のビームの切替とセル間のビームの切替とで制御を異ならせる必要が無くなる。したがって、ｅＮＢおよびＵＥにおける制御を容易にすることが可能となる。また、どちらの制御を行うかを判断する必要がなくなるので、判断に要する時間を削減することが可能となる。
【０６７９】
上りリンクの無線リソースのスケジューリング情報も、同様に、下り制御情報（Downlink Control Information：ＤＣＩ）に含まれる。したがって、以上に開示した方法を適用することができる。
【０６８０】
上りリンクでは、ＵＥがｅＮＢに対して無線リソースの要求を行う必要がある。従来のセルでは、無線リソースの要求は、スケジューリングリクエスト（Scheduling Request：ＳＲ）あるいはＰＲＡＣＨで行われる。ビーム切替処理において、ＵＥがターゲットビームに対して無線リソースの要求を行うことになる。
【０６８１】
しかし、ＳＲおよびＰＲＡＣＨは、任意のタイミングで行ってよいわけでなく、ｅＮＢによって設定された予め定めるタイミングで行わなくてはならない。したがって、ＵＥは、ｅＮＢによって設定された予め定めるタイミングまで待たなくてはならず、遅延が生じることになる。狭カバレッジのビーム切替処理の場合、この遅延は、通信の失敗につながる可能性が高い。
【０６８２】
このような問題を解決する方法を開示する。予めｅＮＢは、ＵＥに対して、ターゲットビームでの上りリンクの無線リソースのスケジューリングを行う。予めｅＮＢは、ＵＥに対して、ソースビームを用いて、ターゲットビームでの上りリンクの無線リソースのスケジューリングを行うとよい。
【０６８３】
例えば、ターゲットビームの上りリンクの無線リソースのスケジューリング方法として、ＳＰＳを用いるとよい。ｅＮＢは、ＵＥに、ソースビームを用いて、ターゲットビームでの上りＳＰＳの設定を通知するとよい。上りＳＰＳの設定の通知は、ＵＥがターゲットビームと同期を行う前に行うとよい。ターゲットビームでの上りＳＰＳの設定を受信したＵＥは、ターゲットビームと同期した後、ターゲットビームで、通知された上りＳＰＳの設定を用いて、上り送信を行う。
【０６８４】
ＳＰＳの設定として、ＳＰＳリソースの時間間隔だけでなく、オフセット、スケジューリング情報を含めてもよい。オフセットとしては、無線フレームナンバ、サブフレームナンバが明示されてもよい。
【０６８５】
ターゲットビームでのＳＰＳの設定およびＳＰＳのアクティベーション方法について開示する。ＳＰＳリソースの時間間隔の設定は、ソースビームで行うとよい。ＳＰＳリソースの時間間隔の設定をソースビームで行うことによって、ビームの切替時にターゲットビームからの設定を不要とし、切替処理にかかる時間を短縮することが可能となる。
【０６８６】
ＳＰＳリソースのスケジューリング情報の設定は、ソースビームで行ってもよい。ＳＰＳリソースのスケジューリング情報の設定をソースビームで行うことによって、ビームの切替時にターゲットビームからの設定を不要とし、切替処理にかかる時間を短縮することが可能となる。
【０６８７】
あるいは、ＳＰＳリソースのスケジューリング情報の設定は、ターゲットビームで行ってもよい。これによって、ターゲットビームでの負荷状況に応じたリソース割当てなどのスケジューリング情報の設定が可能となる。
【０６８８】
ＳＰＳのアクティベーションおよびデアクティベーションは、ソースビームで行ってもよい。ＳＰＳのアクティベーションおよびデアクティベーションをソースビームで行うことによって、ビームの切替時にターゲットビームからの設定を不要とし、切替処理にかかる時間を短縮することが可能となる。
【０６８９】
あるいは、ＳＰＳリソースのアクティベーションおよびデアクティベーションは、ターゲットビームで行ってもよい。これによって、ターゲットビームでの負荷状況に応じたアクティベーションおよびデアクティベーションが可能となる。また、予めソースビームで行う場合よりも、リソースの使用効率の向上を図ることができる。これは、予めソースビームで行う場合、対象とするＵＥに対して、予めソースビームでアクティベーションおよびデアクティベーションを行ってから、ターゲットビームに切替えて実際にＳＰＳを行うまでの期間、ＳＰＳリソースを該ＵＥに対して割当て続けなければならず、無線リソースの無駄が生じるためである。
【０６９０】
前述の、ＳＰＳの設定、ならびにＳＰＳのアクティベーションおよびデアクティベーションを、ソースビームまたはターゲットビームで行う方法を、適宜組み合わせて用いてもよい。これによって、ターゲットビームでの負荷状況および遅延許容量などに応じて設定することが可能となる。
【０６９１】
このようにすることによって、ＵＥは、ｅＮＢに対して、ビームの切替後のターゲットビームで上りリンクの無線リソース要求を行う必要が無くなるので、遅延を削減することが可能となる。したがって、ビーム切替処理の時間を短縮することが可能となる。
【０６９２】
ここでは、ターゲットビームの上りリンクの無線リソースのスケジューリング方法として、上りＳＰＳを用いることを開示したが、ターゲットビームの下りリンクの無線リソースのスケジューリング方法として、下りＳＰＳを用いてもよい。ｅＮＢは、ＵＥに、ソースビームを用いて、ターゲットビームでの下りＳＰＳの設定を通知してもよい。このようにすることによって、ＵＥは、ターゲットビームに切替えた後、該下りＳＰＳの設定に従って、設定されたＳＰＳリソースを受信することが可能となる。
【０６９３】
ターゲットビームの上りリンクの無線リソースのスケジューリング方法の他の方法として、ダイナミックスケジューリングを用いてもよい。ｅＮＢは、ＵＥからのスケジューリング要求を受信しなくても、ＵＥに、ターゲットビームを用いて任意のサブフレームで無線リソースのスケジューリング情報を送信する。ＵＥは、ターゲットビームと同期を行った後、毎サブフレームでＬ１／Ｌ２制御信号を受信することによって、ｅＮＢが任意のサブフレームを送信した無線リソースのスケジューリング情報を受信することが可能となる。これによって、ＵＥは、受信した上り無線リソースのスケジューリング情報を用いて、上り送信を行うことが可能となる。
【０６９４】
このようにすることによって、ＵＥは、ｅＮＢに対して、上りリンクの無線リソース要求を行う必要が無くなるので、遅延を削減することが可能となる。したがって、ビーム切替処理の時間を短縮することが可能となる。
【０６９５】
図２７は、実施の形態１２におけるビーム切替処理の時間短縮方法に関するシーケンスの一例を示す図である。図２７では、ソースビーム（Ｓ−Ｂｍ）からターゲットビーム（Ｔ−Ｂｍ）へ切替える場合について示している。
【０６９６】
ステップＳＴ２５０１において、ｅＮＢは、ＵＥとソースビームを用いて通信を行っている。予めｅＮＢは、ソースビームとターゲットビームとの間で同期を行っておく。ソースビームとターゲットビームとの間で、サブフレームタイミングの同期、およびスロットタイミングの同期を行う。また、ＳＦＮ（System Frame Number）、無線フレームナンバ、およびスロットナンバも同期をとる。このようにすることによって、ステップＳＴ２５０２において、ＵＥは、ソースビームと同期がとれている場合、ターゲットビームとの同期もとれていることになる。ステップＳＴ２５０２において、ＵＥは、ターゲットビームとの同期もとれていることを示す。
【０６９７】
ステップＳＴ２５０３において、ｅＮＢは、ＵＥに、ソースビームを用いて、ターゲットビームでの上りスケジューリング情報を通知する。ここでは、ターゲットビームでの上りスケジューリング情報は、ターゲットビームでの上りＳＰＳの設定情報とする。ＳＰＳの設定情報としては、ＳＰＳリソースの時間間隔だけでなく、オフセットおよびスケジューリング情報を含める。
【０６９８】
ターゲットビームでの上りスケジューリング情報とともに、ターゲットビームに関する情報を通知してもよい。ターゲットビームに関する情報としては、例えば、ターゲットビームの識別子などがある。また、ビーム毎にＵＥ個別に割当てる識別子を用いる場合は、該識別子を通知してもよい。ターゲットビームでの上りスケジューリング情報およびターゲットビームに関する情報の通知は、ＲＲＣシグナリングを用いるとよい。
【０６９９】
ステップＳＴ２５０４において、ｅＮＢは、ＵＥに、ソースビームを用いて、ビーム切替指示を通知する。ビーム切替指示情報を設けて、該情報を通知するとしてもよい。ビーム切替指示情報は、ビームの切替のトリガとなる情報である。言い換えると、ＵＥにターゲットビームのＬ１／Ｌ２制御信号を受信させるトリガとなる情報である。ビーム切替指示情報の通知には、ＲＲＣシグナリングを用いるとよい。
【０７００】
ビーム切替指示情報を受信したＵＥは、既にステップＳＴ２５０２においてターゲットビームと同期済みであるので、ステップＳＴ２５０５において、ターゲットビームの下り制御情報を受信する。ＵＥは、毎サブフレームＰＤＣＣＨあるいはＥＰＤＣＣＨを受信する。ＵＥは、ターゲットビームの下り制御情報を受信することによって、下りスケジューリング情報を得ることができ、該スケジューリング情報に従って、下りデータを受信することが可能となる。
【０７０１】
上り送信データが有る場合、ステップＳＴ２５０６において、ＵＥは、ｅＮＢに、ターゲットビーム用に設定されたＳＰＳリソースを用いて、上りデータを送信する。
【０７０２】
このようにすることによって、ステップＳＴ２５０７において、ＵＥとｅＮＢとの間で、ターゲットビームを用いて通信が可能となる。
【０７０３】
本実施の形態で開示した方法を用いることによって、ビームフォーミングによって狭カバレッジになったビーム間をＵＥが移動してビームを切替える場合に、同期処理および無線リソースのスケジューリング処理に時間がかかることによる通信品質の劣化および通信の断絶を低減することが可能となる。
【０７０４】
ビームを形成する複数のアンテナ素子からなるアンテナの位置が、ビーム毎に同じ場合は、該アンテナからＵＥへのパスの距離は、ほぼ同じとなる。したがって、上り送信タイミングをソースビームとターゲットビームとで変える必要は無い。しかし、ビーム毎にアンテナの位置が異なるような場合、ターゲットビームにおいて、ＵＥは上りリンクの同期を行う必要がある場合がある。
【０７０５】
上りリンクの同期を行う方法を開示する。ｅＮＢは、ＵＥに対して、ターゲットビームにおいてランダムアクセス（Random Access：ＲＡ）処理を実行する指示を行う。ターゲットビームにおいてＲＡ処理を実行する指示は、ターゲットビーにおけるＬ１／Ｌ２制御信号を用いて行うとよい。あるいは、ターゲットビームにおけるＰＤＣＣＨまたはＥＰＤＣＣＨを用いて行うとよい。
【０７０６】
ＵＥは、ターゲットビームにおいてＲＡ処理を実行する指示を受信した場合、ターゲットビームにおいてＲＡ処理を行うとよい。ターゲットビームにおいてＲＡ処理を行うことによって、ｅＮＢは、ＵＥの上り送信タイミングの調整を行うことが可能となる。具体的には、ＲＡ処理において、上り送信タイミングをＵＥに通知する。タイミングアドバンス（Timing Advanced）とも称される。
【０７０７】
このようにすることによって、ターゲットビームにおいて、ＵＥは上りリンクの同期を行うことが可能となる。
【０７０８】
ｅＮＢが、上りリンクの同期を行うか否かを判断する方法を開示する。ｅＮＢは、アンテナの位置に関する情報を取得する。例えば、各アンテナは、全地球測位システム（Global Positioning System；略称：ＧＰＳ）などを用いて自アンテナの位置に関する情報を取得し、ｅＮＢに自アンテナの位置に関する情報を通知する。あるいは、オペレータがアンテナの位置に関する情報をｅＮＢに設定する。あるいは、オペレータがアンテナの位置に関する情報をＯＡＭに設定し、ＯＡＭがｅＮＢに通知してもよい。
【０７０９】
ｅＮＢは、取得したアンテナの位置に関する情報を用いて、ターゲットビームを用いた通信の対象となるＵＥに対して上りリンクの同期が必要か否かを判断する。
【０７１０】
ｅＮＢは、上りリンクの同期が必要と判断した場合、該ＵＥに対して、ターゲットビームにおいてＲＡ処理を実行する指示を行うとよい。
【０７１１】
このようにすることによって、ｅＮＢは、必要に応じて、上りリンクの同期を行うか否かを判断することが可能となる。上りリンクの同期が不要な場合は、ＲＡ処理を行わずに済ませることが可能となる。また、たとえ上りリンクの同期が必要な場合であったとしても、ｅＮＢから指示されて行うＲＡ処理を用いるので、衝突の無いＲＡ処理となり、制御を簡易にすることができる。
【０７１２】
図２７に示す例では、ターゲットビームでの上りスケジューリング情報と、ターゲットビームへの切替指示を別々のシグナリングで通知した。他の例として、ターゲットビームでの上りスケジューリング情報と、ターゲットビームへの切替指示とを同じシグナリングで通知してもよい。これによって、同様の効果を得ることが可能となる。
【０７１３】
実施の形態１３．
実施の形態１２では、ｅＮＢは、ＵＥに、ビームの切替を行わせるためのビーム切替指示を通知することを開示した。例えば、図２７のステップＳＴ２５０４の処理を示した。
【０７１４】
実施の形態１２では、ビーム切替指示情報の通知に、ＲＲＣシグナリングを用いることを開示した。しかし、ＲＲＣシグナリングを用いた場合、複数のトランスポートブロックに分割されるので、複数の送信時間間隔（Transmission Time Interval：ＴＴＩ）で送信されることになる。また、トランスポートブロック毎に再送が適用される。したがって、ＲＲＣシグナリングの送受信にかかる時間は大きくなってしまう。本実施の形態では、ビーム切替処理において、ビーム切替指示の通知にかかる時間の短縮方法を開示する。
【０７１５】
ビーム切替指示をＭＡＣシグナリングあるいはＬ１／Ｌ２シグナリングで行う。Ｌ１／Ｌ２シグナリングとして、個別制御チャネルを用いる。例えば、ＰＤＣＣＨあるいはＥＰＤＣＣＨなどである。ＭＡＣシグナリングおよびＬ１／Ｌ２シグナリングともに１ＴＴＩで行われるので、ＲＲＣシグナリングよりもビーム切替指示にかかる時間を短縮することが可能となる。
【０７１６】
ＭＡＣシグナリングの場合、ＨＡＲＱが適用される。したがって、Ｌ１／Ｌ２シグナリングを用いる場合に比べて、受信誤り率が低くなるという効果を得ることができる。
【０７１７】
Ｌ１／Ｌ２シグナリングの場合、ＨＡＲＱは適用されない。したがって、ＭＡＣシグナリングを用いる場合に比べて、低遅延でビーム切替指示を通知することが可能となる。
【０７１８】
ＭＡＣシグナリングおよびＬ１／Ｌ２シグナリングのどちらを用いるかは、規格などで静的に決められてもよい。あるいは、両方の方法をサポートしておき、準静的あるいは動的に使い分けてもよい。例えば、電波伝搬環境に応じて、ＭＡＣシグナリングあるいはＬ１／Ｌ２シグナリングの方法を使い分けてもよい。電波伝搬環境が良好な場合には、Ｌ１／Ｌ２シグナリングを用い、電波伝搬環境が良好でないような場合には、ＭＡＣシグナリングを用いるとしてもよい。
【０７１９】
ビームの切替を判断する主体について開示する。ｅＮＢ内のＭＡＣプロトコルがビームの切替を判断するとよい。ＲＲＣではなく、ＭＡＣが判断することによって、どのビームを使用するかの判断を、スケジューリングとともに、あるいは、スケジューリングに含ませることが可能となる。各ビームを同一の時間−周波数軸上に構成される無線リソースとして扱うとよい。複数のビームを複数の無線リソースとして扱い、該複数の無線リソースを用いたスケジューリングを行うようにしてもよい。
【０７２０】
また、ビームの切替を判断する主体をＭＡＣとすることは、ビーム切替指示をＭＡＣ以下のシグナリングで通知するのに適している。ビームの切替を判断する主体をＭＡＣとすることによって、ビームの切替判断からビーム切替指示の送信までの処理時間を短縮することが可能となる。
【０７２１】
ビーム切替指示の他に、ＵＥにビームの切替を実行させる場合に用いる情報の具体例として、以下の（１）〜（３）の３つを開示する。以下、ＵＥにビームの切替を実行させる場合に用いる情報を「ビーム切替用関連情報」という場合がある。
【０７２２】
（１）どのビームに切替えるかの情報。例えば、ターゲットビームの識別子。
【０７２３】
（２）ソースビームの各プロトコルのリセットおよびターゲットビームの各プロトコルの設定の情報。
【０７２４】
（３）ターゲットビームで通信を可能にするための情報。
【０７２５】
前述の具体例（１）について、さらに具体的に説明する。ネットワークの予め定める範囲毎に割当てられてもよい。例えば、ＭＭＥ毎に割当てられてもよい。あるいは、ｅＮＢ毎に割当てられてもよい。あるいは、ビームの識別子は、セル毎に割当てられてもよい。あるいは、予めビームの識別子を予め定める数だけ用意してその中から割当てるようにしてもよい。
【０７２６】
ネットワークの狭い範囲で割り当てることによって、ビームの識別子に必要となる情報量、例えばビット数を、より少なくすることが可能となる。例えばビームの識別子をセル毎に割当てることによって、ビーム切替関連情報の情報量、例えばビット数を低減することが可能となる。
【０７２７】
前述の具体例（２）について、さらに具体的に説明する。同一セル内のビーム間では、同一のＰＤＣＰが用いられる。したがって、ビームの切替でＰＤＣＰのリセットおよび再設定の少なくとも一方を行うか否かの情報は不要である。予め規格などでリセットも再設定もしないと決めておいてもよい。ＵＥは、同一セル内のビーム切替処理では、ソースビームのＰＤＣＰの設定を保持するとよい。
【０７２８】
同一セル内のビーム間では、同一のＲＬＣが用いられる。したがって、ビームの切替でＲＬＣのリセットおよび再設定の少なくとも一方を行うか否かの情報は不要である。予め規格などでリセットも再設定もしないと決めておいてもよい。ＵＥは、同一セル内のビーム切替処理では、ソースビームのＲＬＣの設定を保持するとよい。
【０７２９】
同一セル内のビームは、ＭＡＣの一部の設定のみが異なる。したがって、ビームの切替でＭＡＣのリセットおよび再設定の少なくとも一方を行うか否かの情報は不要である。すなわち、リセットは不要であり、異なる設定のみを再設定するとよい。予め規格などで異なる設定のみを再設定すると決めておいてもよい。ＵＥは、同一セル内のビーム切替処理では、ソースビームと同一のＭＡＣの設定のみを保持するとよい。
【０７３０】
同一セル内のビームは、ＰＨＹの一部あるいは全部の設定が異なる。ＰＨＹのリセットおよび再設定の少なくとも一方を行うか否かの情報が必要となる。
【０７３１】
前述の具体例（３）におけるターゲットビームで通信を可能にするための情報の具体例として、以下の（３−１）〜（３−３）の３つを開示する。
【０７３２】
（３−１）ターゲットビームでのＵＥ識別子。例えば、Ｃ−ＲＮＴＩ、あるいはＢ−ＲＮＴＩ。
【０７３３】
（３−２）ターゲットビームのＭＡＣおよびＰＨＹに関する情報。例えば、共通の無線リソース設定、ＭＡＣの主設定、個別のＰＨＹの設定などがある。共通の無線リソース設定のパラメータとしては、「radioResourceConfigCommon」が用いられる。ＭＡＣの主設定のパラメータとしては、「mac-MainConfig」が用いられる。個別のＰＨＹの設定のパラメータとしては、「physicalConfigDedicated」が用いられる。
【０７３４】
（３−３）ターゲットビームにおけるＳＣｅｌｌに関する情報。
【０７３５】
前述の（３−１）〜（３−３）の情報は、ソースビームの設定から変更の無いものは省略してもよい。ソースビームの設定から変更のあるもののみを通知するとしてもよい。これによって、情報量を削減することができる。
【０７３６】
ビーム切替指示の他に、ＵＥにビームの切替を実行させる場合に用いる情報を、ｅＮＢからＵＥに通知しておくことによって、ビーム切替指示情報を受信したＵＥは、ターゲットビームを用いた通信を行うことが可能となる。
【０７３７】
ｅＮＢは、ＵＥに、ビームの切替を実行させるために、ビーム切替用関連情報を通知する。ビーム切替用関連情報の通知方法について開示する。
【０７３８】
ｅＮＢは、ソースビームを用いて、ビーム切替用関連情報をＵＥに通知する。ビーム切替用関連情報は、ビーム切替指示を通知する前に通知する。ビーム切替用関連情報は、ＲＲＣシグナリングで通知するとよい。ビーム切替用関連情報の通知用に新たなメッセージを新設してもよい。
【０７３９】
ビーム測定用の構成情報（以下「ビーム測定用構成情報」という場合がある）を通知するメッセージを設けてもよい。ビーム測定用構成情報としては、ＣＳＩ測定用の構成情報としてもよい。
【０７４０】
ＵＥは、ｅＮＢから通知されたビーム測定用構成情報を用いてビームを測定する。ＵＥは、ビーム測定用構成情報に含まれるビームを測定する。ＵＥは、ビームの測定結果をｅＮＢに報告する。報告のための設定もｅＮＢからＵＥに通知してもよい。ビーム測定用構成情報とともに、あるいは、ビーム測定用構成情報に含めて通知してもよい。ｅＮＢは、ＵＥからのビームの測定結果の報告を受信し、該ＵＥに対して使用するビームを決定する。
【０７４１】
ＵＥによるビームの測定結果のｅＮＢへの報告方法について開示する。ビームの測定として、ビーム毎に送信されるリファレンスシグナルあるいはディスカバリーシグナルの受信電力を測定する。あるいは受信品質であってもよい。あるいは、干渉電力およびノイズ電力を含んだ量を測定してもよい。例えば、信号対雑音比（Signal to Noise Ratio；略称：ＳＮＲ）、信号対干渉雑音電力比（Signal to Interference plus Noise power Ratio；略称：ＳＩＮＲ）などである。
【０７４２】
従来のセルの測定結果の報告は、ＲＲＣシグナリングで行われる。ＲＲＣシグナリングで行ってもよいが、ＲＲＣシグナリングの場合、前述したように、ＲＲＣシグナリングの送受信にかかる時間は大きくなってしまう。
【０７４３】
他の方法として、ＭＡＣあるいはＬ１／Ｌ２シグナリングで通知してもよい。ＭＡＣ  ＣＥを用いて通知してもよい。あるいは、ＰＵＣＣＨにマッピングして通知してもよい。あるいは、ＰＵＳＣＨにマッピングして通知してもよい。あるいはＣＱＩ報告、あるいはＣＳＩ報告を利用してもよい。
【０７４４】
このようにすることによって、ＵＥによるビームの測定結果のｅＮＢへの報告を早期に行うことが可能となる。これによって、ビームの測定からビーム切替処理までの期間を短縮することが可能となるので、ｅＮＢがより適切なターゲットビームを選択することが可能となる。
【０７４５】
図２８は、実施の形態１３におけるビーム切替処理の時間短縮方法に関するシーケンスの一例を示す図である。図２８では、ソースビーム（Ｓ−Ｂｍ）からターゲットビーム（Ｔ−Ｂｍ）へ切替える場合について示している。ソースビームとターゲットビームとの間で同期をとった場合について示している。ターゲットビームでの無線リソースのスケジューリング情報を予めソースビームを用いて通知する場合について示している。図２８に示すシーケンスは、図２７に示すシーケンスと類似しているので、同一のステップについては同一のステップ番号を付して、共通する説明を省略する。ここでは、主として異なる部分について説明する。
【０７４６】
ステップＳＴＳＴ２６０１において、ｅＮＢは、ＵＥに、ソースビームを用いて、ビーム測定用構成情報を通知する。ビーム測定用構成情報の通知には、ＲＲＣシグナリングを用いる。
【０７４７】
ｅＮＢからビーム測定用構成情報を取得したＵＥは、ステップＳＴ２６０２において、ビーム測定用構成情報に含まれる測定用のビームについて、ビーム毎に送信されるリファレンスシグナルを測定する。
【０７４８】
ステップＳＴ２６０３において、ＵＥは、ステップＳＴ２６０２で得た測定結果を、ｅＮＢに、ソースビームを用いて通知する。測定結果の通知には、Ｌ１／Ｌ２シグナリングを用いるとよい。例えば、上り制御チャネルであるＰＵＣＣＨを用いて報告する。これによって、シグナリングの高速化を図ることができる。
【０７４９】
ステップＳＴ２６０３において、ＵＥは、ステップＳＴ２６０２で得た測定結果を全て報告しなくてもよい。予め定めるクライテリアに従って、報告がトリガされたビームの測定結果のみを報告してもよい。ｅＮＢは、これらの設定を、ステップＳＴ２６０１において、ビーム測定用構成情報とともにＵＥに通知する。
【０７５０】
ステップＳＴ２６０３でビームの測定結果の報告を受信したｅＮＢは、ステップＳＴ２６０４において、ＵＥに対してビームの切替を行うか否かを決定する。例えば、ソースビームの受信品質が予め定める閾値以下に劣化し、ソースビームよりも受信品質が良いビームが存在した場合、ｅＮＢは、受信品質が良いビームに切替えることを決定する。
【０７５１】
ステップＳＴ２６０４においてＵＥに対してビームの切替を決定したｅＮＢは、ステップＳＴ２６０５において、ソースビームを用いて、ターゲットビームのビーム切替用関連情報をＵＥに通知する。ビーム切替用関連情報の通知には、ＲＲＣシグナリングを用いるとよい。
【０７５２】
ステップＳＴ２５０３において、ｅＮＢが、ソースビームを用いて、ターゲットビームでの上り無線リソースのスケジューリング情報をＵＥに通知している場合、該通知と同じシグナリングで通知してもよい。
【０７５３】
ステップＳＴ２６０６において、ｅＮＢは、ソースビームを用いて、ターゲットビームへのビーム切替指示情報をＵＥに通知する。ビーム切替指示情報の通知には、ＭＡＣシグナリングを用いる。これによって、シグナリングの高速化を図ることができる。
【０７５４】
ステップＳＴ２６０５において、ターゲットビームのビーム切替用関連情報を受信し、ステップＳＴ２６０６において、ビーム切替指示情報を受信したＵＥは、ターゲットビームのＬ１／Ｌ２制御信号を受信する。
【０７５５】
ステップＳＴ２６０６において、ＵＥにターゲットビームへのビーム切替指示情報を送信したｅＮＢは、ターゲットビームを用いて、ＵＥに対してスケジューリングを行う。
【０７５６】
図２８に示すシーケンスでは、ビーム切替用関連情報と、ビーム測定用構成情報を通知するメッセージとを別々に通知した。他の方法として、ビーム切替用関連情報を、ビーム測定用構成情報を通知するメッセージに含めて通知してもよい。ビーム測定用構成情報に含まれるビームのビーム切替用関連情報を含めるとよい。この場合、ｅＮＢがターゲットビームを決定する前にＵＥに通知することになる。したがって、ビーム切替用関連情報に含まれるターゲットビームは、まだ決まっていない。そこで、ターゲットビームではなく、ビーム測定用のビームについての情報を含めるとよい。ビーム測定用のビームは、一つであっても複数であってもよい。ソースビームを含めてもよい。
【０７５７】
また、例えば、１回目のビーム測定用構成情報でターゲットビームが決まらなかった場合、ｅＮＢは、再度他のビーム測定用構成情報をＵＥに通知するとよい。該ビーム測定用構成情報を通知するメッセージに、ビーム切替用関連情報を含めて通知するとよい。
【０７５８】
ｅＮＢからＵＥへのビーム切替用関連情報の通知にＲＲＣシグナリングを用いることを開示したが、他の方法として、ＭＡＣシグナリングを用いてもよい。ＭＡＣ  ＣＥで通知してもよい。新たなＭＡＣ  ＣＥを設けてビームの切替を実行させるために必要な情報を含ませてもよい。ビーム切替指示情報とともに通知してもよい。
【０７５９】
ＲＲＣシグナリングで通知する情報とＭＡＣシグナリングで通知する情報とを分けてもよい。例えば、情報量の多い情報をＲＲＣシグナリングで通知し、情報量の少ない情報をＭＡＣシグナリングで通知するようにする。前述の具体例（３）のターゲットビームで通信を可能にさせるための設定情報をＲＲＣシグナリングで通知し、前述の具体例（１）のターゲットビームの識別子をＭＡＣシグナリングで通知してもよい。情報量の少ない情報をＭＡＣシグナリングで通知することによって、ビーム切替指示情報も合わせて１トランスポートブロックでの送信が可能となる。
【０７６０】
ビーム切替指示情報をＭＡＣシグナリングで通知するようにした場合、ＭＡＣシグナリングは１ＴＴＩで行われることになる。前述のように、ＲＲＣシグナリングは、複数のトランスポートブロックに分割されて送信されるので、複数のＴＴＩにわたって行われることになる。さらに再送を考慮したとしても、ＭＡＣシグナリングを用いることによって、ＲＲＣシグナリングを用いる場合に比べて、ビーム切替指示情報の通知にかかる時間を短縮することが可能となる。
【０７６１】
したがって、本実施の形態で開示した方法を用いることによって、ビームフォーミングによって狭カバレッジになったビーム間をＵＥが移動してビームを切替える場合に、シグナリングに時間がかかることによる通信品質の劣化および通信の断絶を低減することが可能となる。
【０７６２】
また、ビームの測定結果の報告にＬ１／Ｌ２シグナリングを用いることによって、ビームの測定からビームの切替までの時間を短縮することができる。これによって、より最適なビームに対してビームの切替を行うことが可能となり、通信品質の劣化ならびに切替えの失敗による通信の遅延および通信の断絶を低減することが可能となる。
【０７６３】
実施の形態１３  変形例１．
実施の形態１３では、ビーム切替指示情報の通知にかかる時間の短縮方法を開示した。本変形例では、他の方法を開示する。
【０７６４】
ｅＮＢは、通信対象のＵＥに対してターゲットビームの候補となる一つまたは複数のビームを決定する。ターゲットビームの候補にソースビームを入れてもよい。以下、ターゲットビームの候補となるビームを「ターゲット候補ビーム」という場合がある。
【０７６５】
ｅＮＢは、ターゲット候補ビームのうちの一部または全部のビームのアクティベーション、デアクティベーションを決定する。
【０７６６】
ｅＮＢは、ターゲット候補ビームのうちの一部または全部のビームのアクティベーション、デアクティベーションの指示をＵＥに通知する。該通知は、ソースビームを用いて行われる。該通知には、ＭＡＣシグナリングあるいはＬ１／Ｌ２シグナリングを用いるとよい。
【０７６７】
ＵＥは、アクティベーションの指示を受けたビームに対して同期を行い、下り制御情報（ＤＣＩ）を受信する。Ｌ１／Ｌ２制御信号を受信するとしてもよい。例えば、ＰＤＣＣＨあるいはＥＰＤＣＣＨを受信する。ＵＥは、ＰＤＣＣＨあるいはＥＰＤＣＣＨを受信し、Ｃ−ＲＮＴＩあるいはＢ−ＲＮＴＩで自ＵＥ宛てのＤＣＩを検出する。
【０７６８】
アクティベーションの指示を受けたビームが複数の場合、ＵＥは、複数のビームの下り制御情報を受信することとなる。
【０７６９】
ｅＮＢは、ＵＥに対して使用するビームをアクティベーションしたビームの中から決定し、ソースビームから決定したビームに切替える。ｅＮＢは、切替えたビームを用いてＵＥと通信を行う。このとき、ｅＮＢは、ＵＥにビーム切替指示情報を通知する必要は無い。ＵＥは、アクティベーションの指示を受けたビームの下り制御情報を受信しているので、どのビームで通信が開始されても、該通信のためのスケジューリング情報を取得することが可能だからである。
【０７７０】
このようにすることによって、ビーム切替指示情報の通知を不要とすることができる。ｅＮＢは、ＵＥに対するビームの切替を決定した後、即座に、切替えたビームを用いてＵＥと通信を行うことが可能となる。したがって、ビーム切替処理にかかる時間を短縮することが可能となる。
【０７７１】
ｅＮＢは、ターゲット候補ビームを決定した後、ＵＥにターゲット候補ビームのビーム切替用関連情報を通知しておくとよい。ビーム切替用関連情報の通知は、実施の形態１２で開示した方法を適用することができる。
【０７７２】
ターゲット候補ビームの決定は、適宜行われる。ターゲット候補ビームの決定は、周期的に行われてもよいし、ＵＥのビームの測定結果の報告に応じて行われてもよい。ターゲット候補ビームが変更された場合、再度、ＵＥにターゲット候補ビームのビーム切替用関連情報を通知しておくとよい。変更、削除または追加するビームのビーム切替用関連情報のみを通知してもよい。削除するビームに関しては、ビーム識別子だけを通知するとしてもよい。
【０７７３】
アクティベーションあるいはアクティベーションするビームの決定は、適宜行われる。アクティベーションあるいはアクティベーションするビームの決定は、周期的に行われてもよいし、ＵＥのビームの測定結果の報告に応じて行われてもよい。アクティベーションあるいはデアクティベーションするビームが変更された場合、再度、ＵＥにビームのアクティベーションあるいはデアクティベーションの指示を通知するとよい。変更するビームのみを通知してもよい。
【０７７４】
ＵＥに対して使用するビームの決定は、適宜行われる。ＵＥに対して使用するビームの決定は、周期的に行われてもよいし、ＵＥのビームの測定結果の報告に応じて行われてもよい。これによって、ＵＥに対して使用するビームが変更されても、ビーム切替指示情報の通知を行わなくて済む。
【０７７５】
図２９および図３０は、実施の形態１３の変形例１におけるビーム切替処理の時間短縮方法に関するシーケンスの一例を示す図である。図２９と図３０とは、境界線ＢＬ１の位置で、つながっている。図２９および図３０では、ソースビーム（Ｓ−Ｂｍ）から第１のターゲットビーム（Ｔ−Ｂｍ１）へ切替える場合について示している。また、第１のターゲットビーム（Ｔ−Ｂｍ１）から第２のターゲットビーム（Ｔ−Ｂｍ２）へ切替える場合についても示している。また、ソースビームとターゲットビームとの間で同期をとっていない場合について示している。また、ターゲットビームでの無線リソースのスケジューリング情報を予めソースビームを用いて行っていない場合について示している。図２９および図３０にシーケンスは、図２８に示すシーケンスと類似しているので、同一のステップについては同一のステップ番号を付して、共通する説明を省略する。ここでは、主として異なる部分について説明する。
【０７７６】
ステップＳＴ２６０３においてビームの測定結果の報告を受信したｅＮＢは、ＵＥからのビームの測定結果の報告を用いて、ステップＳＴ２８０１において、ＵＥに対してターゲットビームの候補となるビームを決定する。例えば、ＵＥのビームの受信品質の測定結果が予め定める閾値以上となるもので上位２つのビームを選択し、ソースビームと合わせた３つのビームをターゲット候補ビームとして決定する。ｅＮＢは、ターゲット候補ビームの決定において、ビームの測定結果の報告のみでなく、他の情報を考慮してもよい。
【０７７７】
ステップＳＴ２８０１においてＵＥに対してターゲット候補ビームを決定したｅＮＢは、ステップＳＴ２８０２において、ソースビームを用いて、ＵＥにターゲット候補ビームのビーム切替用関連情報を通知する。ターゲット候補ビームのビーム切替用関連情報は、例えばＲＲＣシグナリングを用いて通知する。
【０７７８】
ステップＳＴ２８２０において、ｅＮＢは、ターゲット候補ビームの中から、ＵＥに対してアクティベーションおよびデアクティベーションの少なくとも一方を行うビームを決定する。この決定には、直近に受信したＵＥからのビームの測定結果の報告を用いてもよい。
【０７７９】
ステップＳＴ２８０３において、ｅＮＢは、ＵＥに、アクティベーションおよびデアクティベーションの少なくとも一方を行うビームを通知する。アクティベーションおよびデアクティベーションの少なくとも一方を行うビームは、例えばＭＡＣシグナリングを用いて通知する。ここでは、アクティベーションするビームを、ソースビーム（Ｓ−Ｂｍ）、第１のターゲットビーム（Ｔ−Ｂｍ１）、および第２のターゲットビーム（Ｔ−Ｂｍ２）とする。
【０７８０】
ステップＳＴ２８０３においてアクティベーションおよびデアクティベーションの少なくとも一方を行うビームを受信したＵＥは、ステップＳＴ２８０４、ステップＳＴ２８０５、およびステップＳＴ２８０６において、アクティベーションするビームと同期を行う。
【０７８１】
さらにＵＥは、ステップＳＴ２８０７、ステップＳＴ２８０８、およびステップＳＴ２８０９において、アクティベーションするビームにおける下り制御情報を受信する。例えば、ソースビーム、第１のターゲットビーム、および第２のターゲットビームのＥＰＤＣＣＨを受信する。これらの受信には、ステップＳＴ２８０２で取得したターゲット候補ビームのビーム切替用関連情報を用いるとよい。
【０７８２】
ステップＳＴ２８１０において、ｅＮＢは、ビームの切替を決定する。具体的には、ソースビームから第１のターゲットビームへの切替を決定する。この決定には、直近に受信したＵＥからのビームの測定結果の報告を用いてもよい。
【０７８３】
ＳＴ２８１０において、第１のターゲットビームへのビームの切替を決定したｅＮＢは、ステップＳＴ２８１１において、第１のターゲットビームを用いて、ＵＥに対するスケジューリング情報をＵＥに送信する。スケジューリング情報としては、ＤＣＩなどがある。ＤＣＩには、下りスケジューリング情報および上りスケジューリング情報の少なくとも一方が含まれる。また、下りスケジューリング情報と同一のサブフレームで、下りデータを送信してもよい。
【０７８４】
ステップＳＴ２８０８において第１のターゲットビームの下り制御情報を受信しているＵＥは、ステップＳＴ２８１１において、第１のターゲットビームを用いて送信されるスケジューリング情報を取得する。
【０７８５】
ステップＳＴ２８１１において第１のターゲットビームのスケジューリング情報を取得したＵＥは、スケジューリング情報に下りスケジューリング情報が含まれている場合、下りスケジューリング情報に従って、下りデータを受信する。
【０７８６】
ステップＳＴ２８１１において第１のターゲットビームのスケジューリング情報を取得したＵＥは、スケジューリング情報に上りスケジューリング情報が含まれている場合、ステップＳＴ２８１２において、上りスケジューリング情報に従って、ｅＮＢに上りデータを送信する。あるいは、スケジューリングリクエストを送信してもよい。あるいは、バッファ状態報告（ＢＳＲ）を送信してもよい。
【０７８７】
このようにして、ＵＥとｅＮＢとは、ステップＳＴ２８１３において、第１のターゲットビームを用いて通信可能となる。
【０７８８】
図２９および図３０では、さらにターゲットビームを切替える方法について開示する。ステップＳＴ２８１３においてＵＥとの通信が第１のターゲットビームを用いて行われている。したがって、ＵＥに対して、第１のターゲットビームがソースビームとなるが、ここでは、引き続き第１のターゲットビームと称することにする。
【０７８９】
ステップＳＴ２８１４において、ＵＥは、ビームの測定を行う。このビームの測定には、ステップＳＴ２６０１で通知されたビーム測定用構成情報に含まれるビームの測定設定を用いる。図示はしていないが、第１のターゲットビームを用いて、新たにビームの測定設定が通知された場合は、該ビームの測定設定を用いて測定を行うとよい。
【０７９０】
ステップＳＴ２８１４において、ビームの測定を行ったＵＥは、ステップＳＴ２８１５において、ビームの測定結果をｅＮＢに報告する。該報告には、第１のターゲットビームを用いて行う。該報告には、Ｌ１／Ｌ２シグナリングを用いるとよい。これによって、シグナリングの高速化を図ることができる。
【０７９１】
ＳＴ２８１５においてビームの測定結果の報告を受信したｅＮＢは、ステップＳＴ２８１６において、ビームの切替を決定する。ビームの切替は、ステップＳＴ２８０３においてＵＥに通知した、アクティベーションするビームの中から行う。
【０７９２】
ステップＳＴ２８１６において第２のターゲットビームへのビームの切替を決定したｅＮＢは、ステップＳＴ２８１７において、第２のターゲットビームを用いて、ＵＥに対するスケジューリング情報をＵＥに送信する。スケジューリング情報としては、ＤＣＩなどがある。ＤＣＩには、下りスケジューリング情報および上りスケジューリング情報の少なくとも一方が含まれる。また、下りスケジューリング情報と同一のサブフレームで、下りデータを送信してもよい。
【０７９３】
ステップＳＴ２８０９において第２のターゲットビームの下り制御情報を受信しているＵＥは、ステップＳＴ２８１７において、第２のターゲットビームを用いて送信されるスケジューリング情報を取得する。
【０７９４】
ＳＴ２８１７において第２のターゲットビームのスケジューリング情報を取得したＵＥは、スケジューリング情報に下りスケジューリング情報が含まれている場合、下りスケジューリング情報に従って、下りデータを受信する。
【０７９５】
ステップＳＴ２８１７において第２のターゲットビームのスケジューリング情報を取得したＵＥは、スケジューリング情報に上りスケジューリング情報が含まれている場合、ステップＳＴ２８１８において、上りスケジューリング情報に従って、ｅＮＢに上りデータを送信する。あるいは、スケジューリングリクエストを送信してもよい。あるいは、バッファステータスレポート（ＢＳＲ）を送信してもよい。
【０７９６】
このようにして、ＵＥとｅＮＢとは、ステップＳＴ２８１９において、第２のターゲットビームを用いて通信可能となる。
【０７９７】
このようにすることによって、ＵＥにビーム切替指示情報を通知せずに、ビームを切替えることが可能となる。
【０７９８】
したがって、ｅＮＢにおけるビームの切替決定から、ＵＥが決定されたビームに切替えて通信可能とするまでの時間を短縮することが可能となる。
【０７９９】
これによって、ビームの切替が頻繁に発生するような状況においても、より最適なビームへの切替を短時間で行うことが可能となり、通信品質の劣化ならびに切替え失敗による通信の遅延および通信の断絶を低減することが可能となる。
【０８００】
また、ターゲットビームの候補となるビームをＵＥに通知することによって、ＵＥは同期をとり制御情報を受信するビームの数を限定することができる。したがって、以上に開示した方法は、ＵＥの処理の負荷を軽減することができ、低消費電力化、小型軽量化、および低価格化を図ることが可能となる。
【０８０１】
以上に開示した例では、アクティベーションまたはデアクティベーションするビームを、ターゲット候補ビームのうちの一部または全部のビームとした。
【０８０２】
他の方法として、アクティベーションするビームをターゲット候補ビームと同じにしてもよい。この場合、ｅＮＢにおけるアクティベーションするビームの決定処理は不要となる。
【０８０３】
また、この場合、ターゲット候補ビームの切替用関連情報の通知を、ターゲット候補ビームのアクティベーションの通知としてもよい。
【０８０４】
ＵＥは、ターゲット候補ビームの切替用関連情報で通知されたビームを、アクティベートされたビームとして、該ビームと同期を行い、下り制御情報を受信する。
【０８０５】
例えば図２９および図３０におけるステップＳＴ２８２０およびステップＳＴ２８０３の処理が省略される。
【０８０６】
このようにすることによって、ｅＮＢからＵＥへのシグナリング量を削減することが可能となる。またｅＮＢとＵＥとにおける制御を簡易にすることができる。
【０８０７】
ＵＥが最大受信可能なビームの数を設定するとよい。ＵＥのケーパビリティ（UE capability）に応じて、最大受信可能なビームの数を決定してもよい。あるいは、ＵＥのケーパビリティのパラメータとして、最大受信可能なビームの数を設けてもよい。
【０８０８】
ＵＥが最大受信可能なビームの数を、予めＵＥからｅＮＢに通知しておくとよい。ＵＥのケーパビリティの通知を用いてもよい。
【０８０９】
このようにすることによって、ｅＮＢは、ターゲット候補ビーム、あるいは、アクティベーションするビームの数を、ＵＥが最大受信可能なビームの数以下に設定することが可能となる。
【０８１０】
あるビームの下り制御情報に、他のビームのスケジューリング情報を含めてもよい。例えば、ソースビームの下り制御情報に、ターゲットビームのスケジューリング情報を含めてもよい。
【０８１１】
例えば図２９および図３０では、ｅＮＢは、ステップＳＴ２８１１において、ソースビームを用いて、第１のターゲットビームの下りスケジューリング情報あるいは上りスケジューリング情報を通知する。ＵＥは、ステップＳＴ２８１１において、ソースビームを用いて、第１のターゲットビームの下りスケジューリング情報あるいは上りスケジューリング情報を受信する。第１のターゲットビームのスケジューリング情報であることを認識したＵＥは、下りスケジューリング情報の場合は、該下りスケジューリング情報に従って、第１のターゲットビームの無線リソースを受信する。あるいは、第１のターゲットビームのスケジューリング情報であることを認識したＵＥは、上りスケジューリング情報の場合は、該上りスケジューリング情報に従って、第１のターゲットビームの無線リソースで送信する。
【０８１２】
このようにすることによって、ＵＥが複数のビームを使用可能な場合、複数のビームの柔軟な使用が可能となる。
【０８１３】
例えば、制御情報を送信するビームとデータ通信を行うビームとを異ならせることが可能となる。制御情報は、複数のビームのうちの一方のビームで送信を行い、データ通信は、複数のビームのうちの他方のビームで行うといった運用が可能となる。ｅＮＢは、各ビームのカバレッジ、負荷、および電波伝搬状況などを考慮して、各ビームを用いることが可能となる。例えば、制御情報は、広いカバレッジのビームで送信し、データ通信は、狭いカバレッジのビームで送信するとよい。このようにすることによって、各ビームの特性に適したビームの運用が可能となる。
【０８１４】
実施の形態１３  変形例２．
ソースビームでまだ通信が成功していないときに、ＵＥのビーム間の移動においてビーム切替処理が生じる場合、送達未成功のデータをどのように扱うかが問題となる。
【０８１５】
本変形例では、ビーム切替処理時の送達未成功のデータの取り扱い方法について開示する。ソースビームを用いて送達未成功となったデータを、ターゲットビームを用いて送信する。上りリンクおよび下りリンクともに行うとよい。
【０８１６】
さらに詳細に開示する。ＰＤＣＰにおいてソースビームを用いて送達未成功となったデータは破棄し、再度ターゲットセルにおいて送信を行う。このようにすることによって、ビームの切替時のデータの損失を抑制することが可能となる。
【０８１７】
ビームフォーミング技術によって形成される狭カバレッジのビーム間をＵＥが移動する場合、ビームの切替が頻繁に生じる場合がある。このような場合、以上に開示した方法を用いると、ＰＤＣＰデータの再送が何度も繰り返されることになる。同じＰＤＣＰデータの再送が何度も繰り返される場合も生じる。したがって、データの通信に遅延が生じてしまい、要求されるＱｏＳを満たさなくなってしまうなどの問題が生じる。このような問題を解決する方法を開示する。
【０８１８】
ビームの切替えにおいては、ソースビームでＨＡＲＱ処理中のデータからターゲットビームで再送する。ＵＥは、ビームの移動指示を受信したとき、ソースビームでＨＡＲＱ処理中のデータからターゲットビームで再送を行う。ｅＮＢは、ＵＥにビームの移動指示を送信したとき、ソースビームでＨＡＲＱ処理中のデータからターゲットビームで再送を行う。
【０８１９】
ソースビームでＨＡＲＱ処理中のデータからターゲットビームで再送する方法の具体例として、以下の（１），（２）の２つを開示する。
【０８２０】
（１）ＨＡＲＱ処理中のデータの初送からターゲットビームで行う。
【０８２１】
（２）ＨＡＲＱをソースビームとターゲットビームとを用いて行う。
【０８２２】
前述の具体例（１）のＨＡＲＱ処理中のデータの初送からターゲットビームで行う方法についての具体例を開示する。図３１は、実施の形態１３の変形例２におけるＨＡＲＱ処理中のデータの初送からターゲットビームで行う方法に関するシーケンスの一例を示す図である。ターゲットビームで上りデータの送信を行うときに、ＵＥがスケジューリングリクエスト（ＳＲ）から行う方法を示す。
【０８２３】
ステップＳＴ２９０１において、ＵＥは、ソースビームでｅＮＢから下りデータを受信している。
【０８２４】
ステップＳＴ２９０２において、ＵＥは、ソースビームでｅＮＢに上りデータを送信している。
【０８２５】
ステップＳＴ２９０３において、ｅＮＢは、ＵＥに対してビームの切替を決定する。
【０８２６】
ステップＳＴ２９０４において、ｅＮＢは、ソースビームにおいてＨＡＲＱ処理中の下りデータに関する情報である未達下りデータ情報を、ターゲットビームに与える。ソースビームとターゲットビームとが同一のｅＮＢの場合は、同一のｅＮＢ内で行われる。この場合、ＨＡＲＱ処理中の下りデータに関する情報を、ソースビームからターゲットビームに適用するとしてもよい。
【０８２７】
ソースビームにおいてＨＡＲＱ処理中の下りデータに関する情報は、ターゲットビームにおいて送信すべきデータを特定可能とする情報であればよい。
【０８２８】
ステップＳＴ２９０５において、ｅＮＢは、ＵＥに、ソースビームを用いてビーム切替指示情報を通知する。
【０８２９】
ビーム切替指示情報を受信したＵＥは、ステップＳＴ２９０６において、ターゲットビームと同期を行う。
【０８３０】
ステップＳＴ２９０７において、ｅＮＢは、ＵＥに、ソースビームにおいてＨＡＲＱ処理中であった下りデータについて、初送からターゲットビームを用いて送信するために、下りスケジューリングを行う。このとき、ｅＮＢは、ステップＳＴ２９０４で受信した、ソースビームにおいてＨＡＲＱ処理中の下りデータに関する情報を用いるとよい。該通知は、ターゲットビームを用いるとよい。
【０８３１】
ステップＳＴ２９０７において、データの初送用のターゲットビームにおけるスケジューリング情報をＵＥに通知したｅＮＢは、該スケジューリング情報に従って、ＵＥに、ターゲットビームを用いて、ソースビームにおいてＨＡＲＱ処理中の下りデータを送信する。
【０８３２】
ステップＳＴ２９０７において下りスケジューリング情報を受信したＵＥは、該スケジューリング情報に従って、ステップＳＴ２９０８において、ターゲットビームで、ソースビームにおいてＨＡＲＱ処理中の下りデータを受信する。
【０８３３】
このようにすることによって、ソースビームにおいてＨＡＲＱ処理中の下りデータを、ターゲットビームを用いて通信することが可能となる。
【０８３４】
次に、上りデータについて示す。ステップＳＴ２９０５においてビーム切替指示情報を受信したＵＥは、ステップＳＴ２９０９において、ｅＮＢに、ターゲットビームを用いて、スケジューリングリクエスト（ＳＲ）を送信する。該ＳＲは、ソースビームにおいてＨＡＲＱ処理中の上りデータを送信するために送信する。
【０８３５】
ＳＴ２９０９においてＳＲを受信したｅＮＢは、上りスケジューリングを決定し、ステップＳＴ２９１０において、ＵＥに、ターゲットビームを用いて上りスケジューリング情報を通知する。
【０８３６】
ＳＴ２９１０において上りスケジューリング情報を受信したＵＥは、ステップＳＴ２９１１において、該スケジューリング情報に従って、ｅＮＢにＵＬデータを送信する。ソースビームにおいてＨＡＲＱ処理中の上りデータの初送から送信する。
【０８３７】
このようにすることによって、ソースビームにおいてＨＡＲＱ処理中のデータを、ターゲットビームを用いて通信することが可能となる。したがって、ターゲットビームにおいてＰＤＣＰデータの再送から行う必要がなくなる。これによって、ビームの切替が頻繁に生じる場合でも、ＰＤＣＰデータの再送が何度も繰り返されるような状態が発生することを低減させることができる。
【０８３８】
他の方法を開示する。図３２は、実施の形態１３の変形例２におけるＨＡＲＱ処理中のデータの初送からターゲットビームで行う方法に関するシーケンスの他の例を示す図である。図３２では、ターゲットビームで上りデータ送信を行うときに、ＵＥがＳＲ送信を不要とする方法のシーケンスを示している。図３２に示すシーケンスは、図３１に示すシーケンスと類似しているので、同一のステップについては同一のステップ番号を付して、共通する説明を省略する。ここでは、主として異なる部分について説明する。下りデータに関しては、図３１と同様であるので説明を省略し、上りデータに関して説明する。
【０８３９】
ステップＳＴ２９０３において、ＵＥに対してビームの切替を決定したｅＮＢは、ステップＳＴ３００１において、ソースビームにおいてＨＡＲＱ処理中の上りデータに関する情報を、ターゲットビームに与える。ソースビームとターゲットビームとが同一のｅＮＢの場合は、同一のｅＮＢ内で行われる。この場合、ＨＡＲＱ処理中の上りデータに関する情報を、ソースビームからターゲットビームに適用するとしてもよい。
【０８４０】
ソースビームにおいてＨＡＲＱ処理中の上りデータに関する情報は、ターゲットビームにおいて送信すべきデータを特定可能とする情報であればよい。
【０８４１】
ステップＳＴ２９０５においてＵＥにビーム切替指示情報を送信したｅＮＢは、ステップＳＴＳＴ３００２において、ＵＥに、ソースビームにおいてＨＡＲＱ処理中であった上りデータについて、初送からターゲットビームを用いてＵＥに送信させるために、上りスケジューリングを行う。このとき、ｅＮＢは、ステップＳＴ３００１において受信した、ソースビームにおいてＨＡＲＱ処理中の上りデータに関する情報を用いるとよい。該通知は、ターゲットビームを用いるとよい。
【０８４２】
ステップＳＴ３００２において、上りデータの初送用のターゲットビームにおけるスケジューリング情報を受信したＵＥは、該スケジューリング情報に従って、ｅＮＢに、ターゲットビームを用いて、ソースビームにおいてＨＡＲＱ処理中の上りデータの初送から送信する。
【０８４３】
このようにすることによって、ターゲットビームにおいてＵＥからのＳＲの送信を行わなくても、ソースビームにおいてＨＡＲＱ処理中の上りデータを、ターゲットビームを用いて通信することが可能となる。
【０８４４】
ＵＥは、ＳＲの送信を不要とするので、ＵＥの低消費電力化を図ることができる。また、ビームの切替からＵＥの上りデータの送信までにかかる時間を短縮することが可能となる。
【０８４５】
前述の具体例（２）のＨＡＲＱをソースビームとターゲットビームとを用いて行う方法についての具体例を開示する。図３３は、実施の形態１３の変形例２におけるＨＡＲＱ処理中のデータの再送からターゲットビームで行う方法に関するシーケンスの一例を示す図である。図３３では、ターゲットビームで上りデータの送信を行うときに、ＵＥがＳＲの送信を行わずに済む方法のシーケンスを示している。図３３に示すシーケンスは、図３２に示すシーケンスと類似しているので、同一のステップについては同一のステップ番号を付して、共通する説明を省略する。ここでは、主として異なる部分について説明する。
【０８４６】
下りデータについて開示する。ステップＳＴ２９０１において、ｅＮＢからの下りデータの受信に失敗したＵＥは、ＨＡＲＱ処理によって、ステップＳＴ３１０１において、ｅＮＢに、ソースビームを用いて、送達失敗（送達未成功）情報であるＮａｃｋを送信する。
【０８４７】
ステップＳＴ２９０３において、ｅＮＢは、ＵＥに対してビームの切替を決定する。
【０８４８】
ステップＳＴ３１０３において、ｅＮＢは、ソースビームにおいてＨＡＲＱ処理中の下りデータに関する情報である未達下りデータ情報を、ターゲットビームに与える。ソースビームとターゲットビームとが同一ｅＮＢの場合は、同一のｅＮＢ内で行われる。この場合、ＨＡＲＱ処理中の下りデータに関する情報を、ソースビームからターゲットビームに適用するとしてもよい。
【０８４９】
ソースビームにおいてＨＡＲＱ処理中の下りデータに関する情報は、ターゲットビームにおいて送信すべきデータを特定可能とする情報であればよい。ここでは、ＵＥからＮａｃｋを受信しているので、再送のためのデータを特定可能とする情報とするとよい。
【０８５０】
ステップＳＴ２９０５において、ｅＮＢは、ＵＥに、ソースビームを用いてビーム切替指示情報を通知する。
【０８５１】
ビーム切替指示情報を受信したＵＥは、ステップＳＴ２９０６において、ターゲットビームと同期を行う。
【０８５２】
ステップＳＴ３１０５において、ｅＮＢは、ＵＥに、ソースビームにおいてＨＡＲＱ処理中であった下りデータについて、再送からターゲットビームを用いて送信するための下りスケジューリングを行う。このとき、ｅＮＢは、ステップＳＴ３１０３において受信した、ソースビームにおいてＨＡＲＱ処理中の下りデータに関する情報を用いるとよい。該通知は、ターゲットビームを用いるとよい。
【０８５３】
ステップＳＴ３１０５において、データの初送用のターゲットビームにおける再送のためのスケジューリング情報をＵＥに通知したｅＮＢは、該スケジューリング情報に従って、ＵＥに、ターゲットビームを用いて、ソースビームにおいてＨＡＲＱ処理中の下りデータの再送データを送信する。
【０８５４】
ステップＳＴ３１０５において下りスケジューリング情報を受信したＵＥは、該スケジューリング情報に従って、ステップＳＴ３１０６において、ターゲットビームで、ソースビームにおいてＨＡＲＱ処理中の下りデータの再送データを受信する。
【０８５５】
このようにすることによって、ソースビームにおいてＨＡＲＱ処理中の下りデータを、ターゲットビームを用いて通信することが可能となる。
【０８５６】
図３３では、ｅＮＢが、下りデータの１回目の再送データを、ターゲットビームで送信する場合について開示したが、１回目に限定されない。何回目であっても同様にすればよい。ソースビームでＮａｃｋが続くような場合、ビームの切替が実行された時点の再送データをターゲットビームで送信する。
【０８５７】
上りデータについて開示する。ステップＳＴ２９０２においてＵＥからの上りデータの受信に失敗したｅＮＢは、ＨＡＲＱ処理によって、ステップＳＴ３１０２において、ＵＥに、送達失敗（送達未成功）情報であるＮａｃｋを送信する。このときに、再送データ用の上りスケジューリング情報を通知する。
【０８５８】
ステップＳＴ２９０３において、ｅＮＢは、ＵＥに対してビームの切替を決定する。
【０８５９】
ステップＳＴ２９０３において、ＵＥに対してビームの切替を決定したｅＮＢは、ステップＳＴ３１０４において、ソースビームにおいてＨＡＲＱ処理中の上りデータに関する情報である未達上りデータ情報を、ターゲットビームに与える。ソースビームとターゲットビームとが同一のｅＮＢの場合は、同一のｅＮＢ内で行われる。この場合、ＨＡＲＱ処理中の上りデータに関する情報を、ソースビームからターゲットビームに適用するとしてもよい。
【０８６０】
ソースビームにおいてＨＡＲＱ処理中の上りデータに関する情報は、ターゲットビームにおいて送信すべきデータを特定可能とする情報であればよい。ここでは、ＵＥに対してＮａｃｋを送信しているので、上り再送データのためのスケジューリング情報を特定可能とする情報を含めるとよい。
【０８６１】
ステップＳＴ２９０５においてｅＮＢからビーム切替指示情報を受信したＵＥは、ステップＳＴ３１０２においてソースビームを用いて受信した上りデータ再送用のスケジューリング情報に従って、ステップＳＴ３１０７において、ターゲットビームを用いて、ｅＮＢに上りデータの再送を行う。
【０８６２】
ステップＳＴ３１０２においてｅＮＢがソースビームを用いてＵＥに通知する再送データ用の上りスケジューリング情報を、ターゲットビームを用いた場合の再送データ用の上りスケジューリング情報としてもよい。
【０８６３】
図３３に示すシーケンスでは、ステップＳＴ３１０２においてｅＮＢがＵＥに、ソースビームを用いてＮａｃｋを送信するとともに、再送データ用の上りスケジューリング情報を通知している。他の方法として、再送データ用の上りスケジューリング情報を、ターゲットビームを用いて通知してもよい。
【０８６４】
ステップＳＴ２９０５においてＵＥにビーム切替指示情報を送信したｅＮＢは、再送データを、ターゲットビームを用いて送信させるために、再送データ用の上りスケジューリング情報を、ターゲットビームを用いてＵＥに送信する。
【０８６５】
このとき、ｅＮＢは、ステップＳＴ３１０４において受信した、ソースビームにおいてＨＡＲＱ処理中の上りデータに関する情報を用いるとよい。
【０８６６】
上り再送データ用の上りスケジューリング情報を受信したＵＥは、ステップＳＴ３１０７において、該スケジューリング情報に従って、ｅＮＢに、ターゲットビームを用いて、ソースビームにおいてＨＡＲＱ処理中の上りデータの再送から送信する。
【０８６７】
このようにすることによって、ソースビームの受信品質が劣化したような場合に、ターゲットビームを用いて、再送から通信することが可能となる。
【０８６８】
したがって、初送からターゲットビームを用いて通信する方法に比べて、さらに早期に通信品質を良好にすることが可能となる。
【０８６９】
他の方法を開示する。図３４は、実施の形態１３の変形例２におけるＨＡＲＱ処理中のデータの送達成功（Ａｃｋ）／送達失敗（Ｎａｃｋ）からターゲットビームで行う方法に関するシーケンスの一例を示す図である。図３４では、ターゲットビームで上りデータの送信を行うときに、ＵＥがＳＲの送信を行わずに済む方法のシーケンスを示している。図３４に示すシーケンスは、図３３に示すシーケンスと類似しているので、同一のステップについては同一のステップ番号を付して、共通する説明を省略する。ここでは、主として異なる部分について説明する。
【０８７０】
下りデータについて開示する。ステップＳＴ２９０１において、ｅＮＢは、ＵＥに下りデータを送信する。ＵＥは、この下りデータの受信に失敗したとする。
【０８７１】
ステップＳＴ２９０３において、ｅＮＢがＵＥに対してビームの切替を決定する。ステップＳＴ３２０１において、ｅＮＢは、ソースビームにおいてＨＡＲＱ処理中の下りデータに関する情報である未達下りデータ情報を、ターゲットビームに与える。ソースビームとターゲットビームとが同一のｅＮＢの場合は、同一のｅＮＢ内で行われる。この場合、ＨＡＲＱ処理中の下りデータに関する情報を、ソースビームからターゲットビームに適用するとしてもよい。
【０８７２】
ソースビームにおいてＨＡＲＱ処理中の下りデータに関する情報は、ターゲットビームにおいて送信すべきデータを特定可能とする情報であればよい。この後にＵＥからＮａｃｋを受信した場合に、再送のためのデータを特定可能とする情報とするとよい。
【０８７３】
ステップＳＴ２９０１においてｅＮＢからの下りデータの受信に失敗したＵＥは、ＨＡＲＱ処理によって、予め定めるタイミングでｅＮＢにＡｃｋ／Ｎａｃｋを送信する必要があるが、ここでは、Ａｃｋ／Ｎａｃｋの送信の前に、ステップＳＴ２９０５において、ｅＮＢからビーム切替指示情報を受信したとする。
【０８７４】
ステップＳＴ２９０５においてビーム切替指示情報を受信したＵＥは、ステップＳＴ２９０６において、ターゲットビームと同期を行う。
【０８７５】
ステップＳＴ３２０３において、ＵＥは、ｅＮＢに、ターゲットビームを用いてＮａｃｋを送信する。ステップＳＴ２９０１において下りデータの受信に成功した場合はＡｃｋを送信する。ここでは、受信失敗、すなわち送達失敗であるので、Ｎａｃｋを送信する。Ａｃｋ／Ｎａｃｋの送信タイミングは、ソースビームでの下りデータの受信タイミングによって決定される、予め定めるタイミングとするとよい。
【０８７６】
ｅＮＢは、ステップＳＴ３２０１において受信したソースビームにおいてＨＡＲＱ処理中の下りデータに関する情報を用いて、Ａｃｋ／Ｎａｃｋが送信されるタイミングを導出する。ステップＳＴ３２０３において、ｅＮＢは、導出したタイミングで、ＵＥからのＮａｃｋを受信する。
【０８７７】
ステップＳＴ３２０３においてＵＥからＮａｃｋを受信したｅＮＢは、ステップＳＴ３２０４において、ＵＥに、ターゲットビームを用いて、ソースビームにおいてＨＡＲＱ処理中であった下りデータについて、再送からターゲットビームを用いて送信するための下りスケジューリングを行う。このとき、ｅＮＢは、ステップＳＴ３２０１において受信した、ソースビームにおいてＨＡＲＱ処理中の下りデータに関する情報を用いるとよい。
【０８７８】
ステップＳＴ３２０４において、ターゲットビームにおける再送のためのスケジューリング情報をＵＥに通知したｅＮＢは、該スケジューリング情報に従って、ＵＥに、ターゲットビームを用いて、ソースビームにおいてＨＡＲＱ処理中の下りデータの再送データを送信する。
【０８７９】
ステップＳＴ３２０４において下りスケジューリング情報を受信したＵＥは、該スケジューリング情報に従って、ステップＳＴ３２０５において、ターゲットビームで、ソースビームにおいてＨＡＲＱ処理中の下りデータの再送データを受信する。
【０８８０】
このようにすることによって、ソースビームにおいてＨＡＲＱ処理中の下りデータを、ターゲットビームを用いて通信することが可能となる。
【０８８１】
上りデータについて開示する。ステップＳＴ２９０２において、ｅＮＢは、ＵＥからの上りデータの受信に失敗する。
【０８８２】
ステップＳＴ２９０３において、ｅＮＢは、ＵＥに対してビームの切替を決定する。
【０８８３】
ステップＳＴ２９０３において、ＵＥに対してビームの切替を決定したｅＮＢは、ステップＳＴ３２０２において、ソースビームにおいてＨＡＲＱ処理中の上りデータに関する情報である未達上りデータ情報を、ターゲットビームに与える。ソースビームとターゲットビームとが同一のｅＮＢの場合は、同一のｅＮＢ内で行われる。この場合、ＨＡＲＱ処理中の上りデータに関する情報を、ソースビームからターゲットビームに適用するとしてもよい。
【０８８４】
ソースビームにおいてＨＡＲＱ処理中の上りデータに関する情報は、ターゲットビームにおいて送信すべきデータを特定可能とする情報であればよい。この後にＵＥにＮａｃｋを送信する場合に、再送のためのデータを特定可能とする情報とするとよい。
【０８８５】
ステップＳＴ２９０２おいてＵＥからの上りデータの受信に失敗したｅＮＢは、ＨＡＲＱ処理によって、任意のタイミングでＵＥにＡｃｋ／Ｎａｃｋを送信する必要があるが、ここでは、Ａｃｋ／Ｎａｃｋの送信の前に、ステップＳＴ２９０５において、ｅＮＢがＵＥにビーム切替指示情報を送信したとする。
【０８８６】
ステップＳＴ２９０５においてビーム切替指示情報を受信したＵＥは、ステップＳＴ２９０６において、ターゲットビームと同期を行う。
【０８８７】
ステップＳＴ３２０６において、ｅＮＢは、ＵＥに、ターゲットビームを用いてＮａｃｋを送信する。ステップＳＴ２９０２において上りデータの受信に成功した場合はＡｃｋを送信する。ここでは、受信失敗、すなわち送達失敗であるので、Ｎａｃｋを送信する。Ａｃｋ／Ｎａｃｋの送信タイミングは、任意のタイミングとするとよい。
【０８８８】
ステップＳＴ３２０６において、ｅＮＢは、ＵＥに、Ｎａｃｋとともに、ターゲットビームを用いて、ソースビームにおいてＨＡＲＱ処理中であった上りデータについて、再送からターゲットビームを用いてＵＥに送信させるための上りスケジューリング情報を送信する。このとき、ｅＮＢは、ステップＳＴ３２０２において受信した、ソースビームにおいてＨＡＲＱ処理中の上りデータに関する情報を用いるとよい。
【０８８９】
Ｎａｃｋとともに上りスケジューリング情報を送信することを開示したが、上りスケジューリング情報だけでもよい。上りスケジューリング情報によって、Ｎａｃｋとしてもよい。該スケジューリング情報に再送であることを示す情報を含めておくとよい。
【０８９０】
ステップＳＴ２９０５において、ｅＮＢからビーム切替指示情報を受信したＵＥは、ステップＳＴ３２０６においてターゲットビームを用いて受信した上りデータ再送用のスケジューリング情報に従って、ステップＳＴ３２０７において、ターゲットビームを用いて、ｅＮＢに上りデータの再送を行う。
【０８９１】
このようにすることによって、ソースビームの受信品質が劣化したような場合に、ターゲットビームを用いて、Ａｃｋ／Ｎａｃｋの送信から通信することが可能となる。
【０８９２】
したがって、初送からターゲットビームを用いて通信する方法に比べて、さらに早期に通信品質を良好にすることが可能となる。
【０８９３】
本変形例で開示した方法を用いることによって、ソースビームを用いて送達未成功のデータを、ターゲットビームを用いて送信することが可能となる。
【０８９４】
以上に開示した方法を適宜組み合わせることによって、初送、再送、あるいはＡｃｋ／Ｎａｃｋの送信から、ターゲットビームを用いて行うことが可能となる。
【０８９５】
ビームの切替の決定タイミングに応じて、これらの方法を適宜組み合わせて用いることによって、ビームの切替を、電波環境などに応じて最適なタイミングで行うことが可能となる。
【０８９６】
したがって、ビームの切替が頻繁に発生するような状況においても、より最適なビームへの切替を適切なタイミングで行うことが可能となり、通信品質の劣化ならびに切替え失敗による通信の遅延および通信の断絶を低減することが可能となる。
【０８９７】
実施の形態１２から実施の形態１３の変形例２では、ビームの切替について開示した。ビームの切替として、同一セル内のビーム間でのビームの切替、異なるセルのビーム間でのビームの切替、あるいは異なるｅＮＢのビーム間でのビームの切替にも、前述の実施の形態で開示した方法を適宜組み合わせて適用するとよい。これによって、ビームの切替処理による通信品質の劣化ならびに切替え失敗による通信の遅延および通信の断絶を低減することが可能となる。
【０８９８】
前述の各実施の形態およびその変形例は、本発明の例示に過ぎず、本発明の範囲内において、各実施の形態およびその変形例を自由に組合せることができる。また各実施の形態およびその変形例の任意の構成要素を適宜変更または省略することができる。
【０８９９】
本発明は詳細に説明されたが、上記した説明は、すべての局面において、例示であって、本発明がそれに限定されるものではない。例示されていない無数の変形例が、本発明の範囲から外れることなく想定され得るものと解される。
【符号の説明】
【０９００】
９０１，９０３  ＭｅＮＢ、９０２，９０４  ＳｅＮＢ、９０５，９０６，２４０２  ＵＥ、９０７，９０９，９１２，９１４  ＭＡＣ、９０８，９１０，９１３，９１５  ＲＬＣ、９１１，９１６  ＰＤＣＰ、２４０１  多素子アンテナ、２４０３，２４０４，２４０５  カバレッジ。
【図１】
2017135159.tif 000003
【図２】
2017135159.tif 000004
【図３】
2017135159.tif 000005
【図４】
2017135159.tif 000006
【図５】
2017135159.tif 000007
【図６】
2017135159.tif 000008
【図７】
2017135159.tif 000009
【図８】
2017135159.tif 000010
【図９】
2017135159.tif 000011
【図１０】
2017135159.tif 000012
【図１１】
2017135159.tif 000013
【図１２】
2017135159.tif 000014
【図１３】
2017135159.tif 000015
【図１４】
2017135159.tif 000016
【図１５】
2017135159.tif 000017
【図１６】
2017135159.tif 000018
【図１７】
2017135159.tif 000019
【図１８】
2017135159.tif 000020
【図１９】
2017135159.tif 000021
【図２０】
2017135159.tif 000022
【図２１】
2017135159.tif 000023
【図２２】
2017135159.tif 000024
【図２３】
2017135159.tif 000025
【図２４】
2017135159.tif 000026
【図２５】
2017135159.tif 000027
【図２６】
2017135159.tif 000028
【図２７】
2017135159.tif 000029
【図２８】
2017135159.tif 000030
【図２９】
2017135159.tif 000031
【図３０】
2017135159.tif 000032
【図３１】
2017135159.tif 000033
【図３２】
2017135159.tif 000034
【図３３】
2017135159.tif 000035
【図３４】
2017135159.tif 000036
【国際調査報告】
2017135159.tif 000037
2017135159.tif 000038
2017135159.tif 000039