JPWO2018117248A1 - 通信システム - Google Patents

通信システム Download PDF

Info

Publication number
JPWO2018117248A1
JPWO2018117248A1 JP2018558085A JP2018558085A JPWO2018117248A1 JP WO2018117248 A1 JPWO2018117248 A1 JP WO2018117248A1 JP 2018558085 A JP2018558085 A JP 2018558085A JP 2018558085 A JP2018558085 A JP 2018558085A JP WO2018117248 A1 JPWO2018117248 A1 JP WO2018117248A1
Authority
JP
Japan
Prior art keywords
pucch
cell
information
pucch resource
subframe
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2018558085A
Other languages
English (en)
Other versions
JP7320948B2 (ja
Inventor
満 望月
忠宏 下田
範行 福井
正明 草野
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Mitsubishi Electric Corp
Original Assignee
Mitsubishi Electric Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Mitsubishi Electric Corp filed Critical Mitsubishi Electric Corp
Publication of JPWO2018117248A1 publication Critical patent/JPWO2018117248A1/ja
Priority to JP2022163761A priority Critical patent/JP2023015051A/ja
Application granted granted Critical
Publication of JP7320948B2 publication Critical patent/JP7320948B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/04—Wireless resource allocation
    • H04W72/044—Wireless resource allocation based on the type of the allocated resource
    • H04W72/046—Wireless resource allocation based on the type of the allocated resource the resource being in the space domain, e.g. beams
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W16/00—Network planning, e.g. coverage or traffic planning tools; Network deployment, e.g. resource partitioning or cells structures
    • H04W16/24—Cell structures
    • H04W16/28—Cell structures using beam steering
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W52/00—Power management, e.g. TPC [Transmission Power Control], power saving or power classes
    • H04W52/02—Power saving arrangements
    • H04W52/0209—Power saving arrangements in terminal devices
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/20—Control channels or signalling for resource management
    • H04W72/23—Control channels or signalling for resource management in the downlink direction of a wireless link, i.e. towards a terminal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W84/00—Network topologies
    • H04W84/02—Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]
    • H04W84/04—Large scale networks; Deep hierarchical networks
    • H04W84/042—Public Land Mobile systems, e.g. cellular systems
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D30/00—Reducing energy consumption in communication networks
    • Y02D30/70—Reducing energy consumption in communication networks in wireless communication networks

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

通信端末装置の消費電力の増大、通信品質の劣化、および無線リソースの使用効率の減少を抑えることができる通信システムを提供する。基地局装置（ｇＮＢ）は、通信端末装置（ＵＥ）に、次の受信タイミングに関する情報を通知する。例えば、ＵＥは、サブフレーム（９０１）における下り制御信号（９０２）を受信する。ＵＥは、下り制御信号（９０２）から、サブフレーム（９０１）のユーザデータ（９０３）に関する情報および次の受信タイミングに関する情報（９０４）を取得する。ＵＥは、ｇＮＢとの間で、ユーザデータ（９０３）を送受信する。次の受信タイミングに関する情報（９０４）には、ＵＥの次の受信タイミングが、サブフレーム（９０５）であることが示されている。ＵＥは、サブフレーム（９０５）において、下り制御信号（９０６）を受信する。

Description

本発明は、移動端末装置などの通信端末装置と基地局装置との間で無線通信を行う通信システムに関する。
移動体通信システムの規格化団体である３ＧＰＰ（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；略称：ＤＣ）などがある。ＤＣについては、非特許文献１に記載されている。
デュアルコネクティビティ（ＤＣ）を行うｅＮＢのうち、一方を「マスターｅＮＢ（略称：ＭｅＮＢ）」といい、他方を「セカンダリｅＮＢ（略称：ＳｅＮＢ）」という場合がある。
モバイルネットワークのトラフィック量は、増加傾向にあり、通信速度も高速化が進んでいる。ＬＴＥおよびＬＴＥ−Ａが本格的に運用を開始されると、更に通信速度が高速化されることが見込まれる。
さらに、高度化する移動体通信に対して、２０２０年以降にサービスを開始することを目標とした第５世代（以下「５Ｇ」という場合がある）無線アクセスシステムが検討されている。例えば、欧州では、ＭＥＴＩＳという団体で５Ｇの要求事項がまとめられている（非特許文献５参照）。
５Ｇ無線アクセスシステムでは、ＬＴＥシステムに対して、システム容量は１０００倍、データの伝送速度は１００倍、データの処理遅延は１０分の１（１／１０）、通信端末の同時接続数は１００倍として、更なる低消費電力化、および装置の低コスト化を実現することが要件として挙げられている。
このような要求を満たすために、３ＧＰＰでは、リリース１４として、５Ｇの規格検討が進められている（非特許文献６〜１０参照）。５Ｇの無線区間の技術は、「New Radio（略称：ＮＲ） Access Technology」と称され、いくつかの新たな技術が検討されている（非特許文献１１〜１３参照）。例えば、自己完結型（self-contained）サブフレームを用いたＮＲ用フレーム構成、アナログビームフォーミングまたはハイブリッドビームフォーミングによるマルチビームフォーミング（ＭＢＦ）、ＭＢＦにおけるビームスイーピング、ならびにコーディングの際の最大コードブロックサイズなどが検討されている。
３ＧＰＰ ＴＳ ３６．３００ Ｖ１４．０．０ ３ＧＰＰ Ｓ１−０８３４６１ ３ＧＰＰ ＴＲ ３６．８１４ Ｖ９．０．０ ３ＧＰＰ ＴＲ ３６．９１２ Ｖ１３．０．０ "Scenarios, requirements and KPIs for 5G mobile and wireless system"、［online］、平成２５（２０１３）年４月３０日、ＩＣＴ−３１７６６９−ＭＥＴＩＳ／Ｄ１．１、［平成２８年１２月１３日検索］、インターネット<https://www.metis2020.com/documents/deliverables/> ３ＧＰＰ ＴＲ ２３．７９９ Ｖ１．１．０ ３ＧＰＰ ＴＲ ３８．８０１ Ｖ０．４．０ ３ＧＰＰ ＴＲ ３８．８０２ Ｖ０．３．０ ３ＧＰＰ ＴＲ ３８．８０４ Ｖ０．３．０ ３ＧＰＰ ＴＲ ３８．９１２ Ｖ０．０．２ ３ＧＰＰ Ｒ１−１６６１０４ ３ＧＰＰ Ｒ１−１６５３６４ ３ＧＰＰ Ｒ１−１６０９０６８
ＮＲでは、マルチビームフォーミングが検討されている。マルチビームフォーミングでは、セルで一時に形成できるビーム数が少ない場合、必要なカバレッジをカバーするために、１つまたは複数のビームを用いて、タイミングをずらして、ビームスイーピングが行われる。したがって、セルが構成する各ビームは、全てのタイミングで送受信できるわけではない。
ＬＴＥでは、通常、ダイナミックにスケジューリングが行われるので、ＵＥは、毎サブフレームで下り制御チャネルを受信する必要がある。しかし、マルチビームフォーミングにおいてビームスイーピングが行われるような場合、前述のように全てのタイミングでビームを送受信できるわけではないので、ＵＥが毎サブフレームで下り制御チャネルの受信を継続するのは無駄となる。したがって、無駄な消費電力が増大してしまう。また、ＵＥが、送受信できないビームのタイミングで上り制御チャネルを送信するのは無駄であり、消費電力が増大するとともに、上り通信が不可能となってしまう。
また、マルチビームフォーミングでは、一つのセルにおいて複数のビームが形成され、ビーム毎にカバレッジが構成される。したがって、ビームのカバレッジは、セルのカバレッジよりも狭範囲となる。ビームのカバレッジが適切に形成されていないと、ＵＥのビーム間の移動で通信の切断が生じやすくなったり、カバレッジホールが発生したりするという問題が生じる。
また、ＮＲにおいては、使用周波数の広帯域化によって、トランスポートブロックのサイズが大きくなり、コードブロック数が増加することが見込まれる。ＬＴＥのようなＡｃｋ／Ｎａｃｋフィードバック方法では、正常に受信されたコードブロックも含めてトランスポートブロック全体を再送するので、コードブロック数が増加すると、無線リソースの使用効率が大きく減少する。
したがって、ＮＲにおいては、正しくデコードできなかったコードブロックをＨＡＲＱによって再送することが検討されている。しかし、コードブロック数が多いので、複数のコードブロックが受信エラーとなった場合に、フィードバックに要するビット数が増大するという問題が生じる。これによって、ＵＥの消費電力の増大および無線リソースの使用効率の減少が引き起こされる。
本発明の目的は、通信端末装置の消費電力の増大、通信品質の劣化、および無線リソースの使用効率の減少を抑えることができる通信システムを提供することである。
本発明の通信システムは、基地局装置と、前記基地局装置と無線通信可能な少なくとも１つの通信端末装置とを備える通信システムであって、前記基地局装置は、前記通信端末装置に、次の受信タイミングに関する情報を通知し、前記通信端末装置は、前記基地局装置から通知された次の受信タイミングに関する情報に基づいて受信を行うことを特徴とする。
本発明の通信システムによれば、基地局装置と、基地局装置と無線通信可能な少なくとも１つの通信端末装置とを備えて、通信システムが構成される。基地局装置は、通信端末装置に、次の受信タイミングに関する情報を通知する。通知端末装置は、基地局装置から通知された次の受信タイミングに関する情報に基づいて受信を行う。これによって、通信端末装置は、通知された受信タイミングで、基地局装置から送信される情報を受信することができるので、受信に要する消費電力を節約することができる。また、再送が必要な場合には、迅速に再送を行うことができるので、基地局装置と通信端末装置との通信の遅延を抑制することができる。したがって、通信端末装置の消費電力の増大、通信品質の劣化、および無線リソースの使用効率の減少を抑えることができる。
本発明の目的、特徴、局面、および利点は、以下の詳細な説明と添付図面とによって、より明白となる。
ＬＴＥ方式の通信システムで使用される無線フレームの構成を示す説明図である。 ３ＧＰＰにおいて議論されているＬＴＥ方式の通信システム２００の全体的な構成を示すブロック図である。 本発明に係る通信端末である図２に示す移動端末２０２の構成を示すブロック図である。 本発明に係る基地局である図２に示す基地局２０３の構成を示すブロック図である。 本発明に係るＭＭＥの構成を示すブロック図である。 ＬＴＥ方式の通信システムにおいて通信端末（ＵＥ）が行うセルサーチから待ち受け動作までの概略を示すフローチャートである。 マクロｅＮＢとスモールｅＮＢとが混在する場合のセルの構成の概念を示す図である。 ビームスイーピングを説明するための図である。 ｇＮＢからＵＥへの、次のＰＤＣＣＨを受信する必要のあるタイミングの通知、および該ＵＥにおける上り／下りデータの送受信の一例を示す図である。 ｇＮＢからＵＥへの、予め定める期間におけるＰＤＣＣＨ受信タイミングの通知および該ＵＥにおける上り／下りデータの送受信の一例を示す図である。 上り通信において、Ａｃｋ／Ｎａｃｋの通知および再送を上り初送の次のサブフレームで行う場合の送受信チャネルを示す図である。 ビーム毎のＰＵＣＣＨリソースを、周期、オフセット、シンボル番号で設定する方法の一例を説明する図である。 ビームスイープ数のＰＵＣＣＨをｋサブフレーム内に設定する方法の一例を説明する図である。 ビームスイープ数のＰＵＣＣＨをｋサブフレーム内に設定する方法の他の例を説明する図である。 ビームスイープ数のＰＵＣＣＨをｋサブフレーム内に設定する方法の他の例を説明する図である。 ＰＵＣＣＨの設定およびＳＲの送受信のシーケンスの一例を示す図である。 ＵＥ毎のＰＵＣＣＨの設定およびＳＲの送受信のシーケンスの一例を示す図である。 ＵＥ毎にＰＵＣＣＨリソース設定の開始、修正、停止に関する情報を設定する方法の一例を説明する図である。 ＵＥ毎のＰＵＣＣＨの設定およびＳＲの送受信のシーケンスの一例を示す図である。 ＵＥのサービングビームのＤＬリソースと同一のサブフレームでＰＵＣＣＨリソースを設定する方法の一例を説明する図である。 ＤＬリソースと同一サブフレームでのＰＵＣＣＨリソースの設定およびＳＲの送受信のシーケンスの一例を示す図である。 ビーム間でＰＵＣＣＨ受信に優先順位を設けた場合のＳＲの送受信のシーケンスの一例を示す図である。 ビーム間でＰＵＣＣＨ受信に優先順位を設けた場合のＳＲの送受信のシーケンスの一例を示す図である。 ＳＲに対する上りグラントの送受信タイミング設定のシーケンスの一例を示す図である。 ＳＲの送信後にビーム間の移動が発生した場合のＳＲに対する上りグラントの送受信タイミング設定のシーケンスの一例を示す図である。 ＳＲの送信後にビーム間の移動が発生した場合のＳＲに対する上りグラントの送受信タイミング設定のシーケンスの一例を示す図である。 ＳＲの送信後にビーム間の移動が発生した場合のＳＲに対する上りグラントの送受信タイミング設定のシーケンスの他の例を示す図である。 ＳＲの送信後にビーム間の移動が発生した場合のＳＲに対する上りグラントの送受信タイミング設定のシーケンスの他の例を示す図である。 ＵＲＬＬＣの割り込みによるコードブロックの受信エラーを説明する図である。 複数のＣＢＧに属するコードブロックが存在する場合のコードブロックとＣＢＧとの対応関係を示す図である。 受信誤りを含む連続したコードブロックとコードブロック塊との関係を示す図である。 受信エラーを含むコードブロックのパターンを説明するための図である。 ＣＢＧ毎のパリティチェック３４０１〜３４０４の付与を説明するための図である。
実施の形態１．
図２は、３ＧＰＰにおいて議論されているＬＴＥ方式の通信システム２００の全体的な構成を示すブロック図である。図２について説明する。無線アクセスネットワークは、Ｅ−ＵＴＲＡＮ（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）」であってもよい。
図７は、マクロｅＮＢとスモールｅＮＢとが混在する場合のセルの構成の概念を示す図である。マクロｅＮＢによって構成されるマクロセルは、比較的広い範囲のカバレッジ７０１を有する。スモールｅＮＢによって構成されるスモールセルは、マクロｅＮＢ（マクロセル）のカバレッジ７０１に比べて範囲が小さいカバレッジ７０２を有する。
複数のｅＮＢが混在する場合、あるｅＮＢによって構成されるセルのカバレッジが、他のｅＮＢによって構成されるセルのカバレッジ内に含まれる場合がある。図７に示すセルの構成では、参照符号「７０４」または「７０５」で示されるように、スモールｅＮＢによって構成されるスモールセルのカバレッジ７０２が、マクロｅＮＢによって構成されるマクロセルのカバレッジ７０１内に含まれる場合がある。
また、参照符号「７０５」で示されるように、複数、例えば２つのスモールセルのカバレッジ７０２が、１つのマクロセルのカバレッジ７０１内に含まれる場合もある。移動端末（ＵＥ）７０３は、例えばスモールセルのカバレッジ７０２内に含まれ、スモールセルを介して通信を行う。
また図７に示すセルの構成では、参照符号「７０６」で示されるように、マクロｅＮＢによって構成されるマクロセルのカバレッジ７０１と、スモールｅＮＢによって構成されるスモールセルのカバレッジ７０２とが複雑に重複する場合が生じる。
また、参照符号「７０７」で示されるように、マクロｅＮＢによって構成されるマクロセルのカバレッジ７０１と、スモールｅＮＢによって構成されるスモールセルのカバレッジ７０２とが重複しない場合も生じる。
さらには、参照符号「７０８」で示されるように、多数のスモールｅＮＢによって構成される多数のスモールセルのカバレッジ７０２が、１つのマクロｅＮＢによって構成される１つのマクロセルのカバレッジ７０１内に構成される場合も生じる。
５Ｇでは、電波到達範囲すなわちカバレッジを広くするために、基地局（本明細書では、５Ｇの基地局をｇＮＢと称する）が複数のアンテナを用いて狭範囲なビームを形成するビームフォーミングを利用して通信を行うことが提案されている。例えば、ｇＮＢは、図４に示すアンテナ４０８を、多素子アンテナによって構成する。ｇＮＢは、多素子アンテナの一部または全部の複数のアンテナを用いて、予め定める方向にビームを形成する。狭範囲なビーム形成を行うことによって、電波到達範囲を広くすることが可能となる。ｇＮＢで一時に形成できるビーム数が少なく、セルとして必要となるカバレッジをカバーできない場合、１つまたは複数のビームを用いて、タイミングをずらしてビームスイーピングを行い、広範囲のカバレッジをカバーする方法が提案されている（非特許文献１２参照）。
図８は、ビームスイーピングを説明するための図である。ビームスイーピングを行うために、下りビームスイーピングブロック（DL sweeping block）８０１と、上りビームスイーピングブロック（UL sweeping block）８０３とが設けられる。下りビームスイーピングブロック８０１と、上りビームスイーピングブロック８０３との間が、下りデータおよび上りデータが送信されるＤＬ／ＵＬデータサブフレーム８０５となる。
各ブロック８０１，８０３は、参照符号「８１１」で示されるように、複数のリソース８０２，８０４，８０６を含んで構成される。各リソースは、参照符号「８１２」で示されるビームを用いて送信される。
下りビームスイーピングブロック８０１は、予め定める下りスイーピングブロック周期Ｔｓｂｐで、繰返し送信される。下りビームスイーピングブロック８０１では、最初の予め定める期間に、予め定める狭範囲のカバレッジに対してビームを形成して送信し、次の予め定める期間に、次の予め定める狭範囲のカバレッジに対してビームを形成して送信する。これを繰り返し行うことによって、セルとしての全カバレッジをカバーする。例えば、参照符号「８０２」で示されるリソースは、同期信号、ＰＢＣＨおよびビーム参照信号の送信に用いられる。
上りビームスイーピングブロック８０３では、最初の予め定める期間に、予め定める狭範囲のカバレッジに対してビームを形成して受信し、次の予め定める期間に、次の予め定める狭範囲のカバレッジに対してビームを形成して受信する。これを繰り返し行うことによって、セルとしての全カバレッジをカバーする。例えば、参照符号「８０４」で示されるリソースは、ＲＡＣＨの送信に用いられる。
セルの全カバレッジをカバーする間の一連のビームスイーピングを、ビームスイーピングブロックと称する。以下の説明では、ビームスイーピングブロックの各ビームの送受信期間を「ビームユニット」と称することもある。
ビームスイーピングブロックは、周期的に設けられる。下りビームスイーピングブロック８０１では、共通制御信号およびチャネルが各ビームで送信される。共通制御信号およびチャネルとして、例えば、初期アクセスに必要となる共通制御信号である、同期信号（ＳＳ）、ＰＢＣＨ、および参照信号（ＲＳ）などがある。上りビームスイーピングブロック８０３では、ＲＡＣＨリソースなどが、各ビームに割当てられる。
ＵＥ８１３は、下りビームスイーピングブロック８０１の全期間で受信を行う。このようにすることによって、ＵＥ８１３は、セルとしてのカバレッジのどこに位置していても、該位置に送信されたビームを受信することが可能となる。したがって、ＵＥ８１３は、例えば、初期アクセスに必要となる共通制御信号を受信することが可能となる。ＵＥ８１３は、上りビームスイーピングブロック８０３において送信を行う。このようにすることによって、ｇＮＢは、該ＵＥ８１３の上り送信を受信することが可能となる。ＵＥ８１３は、該ビームを用いて、ＤＬ／ＵＬデータサブフレーム８０５において上りデータ／下りデータをｇＮＢとの間で送受信する。
以上のようにして、ＵＥは、ビームスイーピングを用いて、自ＵＥが送受信可能なビームを見つけ、ｇＮＢとの通信に用いる。ｇＮＢが該ビームとは別のビームを用いているときは、該ＵＥは下り信号を受信する必要はない。
ところが、ｇＮＢが該ＵＥ向けのデータの送受信をどのタイミングで行うかを該ＵＥは知らない。したがって、該ＵＥは、ｇＮＢとの上り／下りのユーザデータの送受信を行うかどうかを判断するために、ｇＮＢから送信される下り制御信号を毎サブフレームで受信する必要がある。このように該ＵＥがｇＮＢからの下り制御信号を毎サブフレームで受信することによって、該ＵＥの消費電力ならびに、受信に使用される周波数および時間リソースが無駄となる。
３ＧＰＰ Ｒ１−１６０９１３５（以下「参考文献１」という）において、スケジューリング単位よりも長い周期で下り制御信号を受信することが提案されている。また、３ＧＰＰ Ｒ１−１６１０２４０（以下「参考文献２」という）において、ｇＮＢが下り制御信号を送信するタイミングを、ビーム毎に割り当てることが提案されている。
ところが、前述の方法では、該周期で下り制御信号がｇＮＢから送信されないときにおいても、ＵＥは周期的に下り制御信号の受信動作を行う必要があるので、該ＵＥの下り制御信号の受信動作による消費電力が無駄になるという問題が生じる。また、前述の方法では、ＨＡＲＱによる再送が発生した場合においても、前記再送を次の周期まで待つ必要があるので、ｇＮＢとＵＥとの間の通信において遅延が増加するという問題が生じる。また、前述の方法では、周期の設定方法について何ら考慮されていない。
本実施の形態では、以上のような問題を解決する方法を開示する。
ｇＮＢは、ＵＥに対して、次に該ＵＥがＰＤＣＣＨの受信動作を行う必要のあるタイミング（以下「ＰＤＣＣＨ受信タイミング」と称する）を通知する。ＰＤＣＣＨ受信タイミングは、ｇＮＢが該ＵＥに下り制御情報を送信する可能性のあるタイミングであってもよいし、該ＵＥに上り／下りデータの送受信をスケジューリングする可能性のあるタイミングであってもよいし、ｇＮＢが該ＵＥにビームを向けるタイミングであってもよい。ＰＤＣＣＨ受信タイミングにおいて、ｇＮＢは、該ＵＥに上り／下りデータの送受信のスケジューリング情報を通知してもよい。ｇＮＢは、該ＵＥと上り／下りデータの送受信を行ってもよい。ＰＤＣＣＨ受信タイミングにおいて、ＵＥは、ｇＮＢからのＰＤＣＣＨの受信動作を行う。ＵＥは、ｇＮＢからの自ＵＥ向け下り制御情報を受信してもよい。ＵＥは、ｇＮＢと上り／下りデータの送受信を行ってもよい。
ｇＮＢは、ＰＤＣＣＨ受信タイミングを、下り制御信号を用いて通知するとよい。前記下り制御信号は、Ｌ１／Ｌ２シグナリングを用いて通知するとよい。Ｌ１／Ｌ２シグナリングを用いることによって、ＰＤＣＣＨ受信タイミングを迅速に通知することが可能となる。
あるいは、ｇＮＢは、ＰＤＣＣＨ受信タイミングを、ＭＡＣ制御信号を用いて通知してもよい。ＭＡＣ制御信号を用いることによって、ＨＡＲＱによる再送制御が行われるので、高い信頼性でＰＤＣＣＨ受信タイミングを通知することができる。
ＵＥは、ＰＤＣＣＨ受信タイミングの通知を受信するまでは、ＰＤＣＣＨの受信動作を毎サブフレーム行うとよい。ｇＮＢは、ＰＤＣＣＨ受信タイミングを該ＵＥのＲＲＣ接続確立後に通知してもよいし、ＲＲＣ接続確立処理中に通知してもよいし、ランダムアクセス処理中に通知してもよい。前記ランダムアクセス処理中に通知する場合には、ランダムアクセス応答にＰＤＣＣＨ受信タイミングの情報を含めて通知してもよい。
ＰＤＣＣＨ受信タイミングとして、サブフレーム番号を示す情報を通知してもよい。前記サブフレーム番号を示す情報は、例えば、サブフレーム番号であってもよいし、あるいは、サブフレーム番号を予め定める除数で割った剰余であってもよい。前記予め定める除数は、規格で定めてもよいし、ｇＮＢからＵＥに報知してもよいし、ＲＲＣ個別シグナリングで個別に通知してもよい。
あるいは、ＰＤＣＣＨ受信タイミングとして、現在のサブフレームからの時間を通知してもよい。前記現在のサブフレームからの時間は、サブフレーム単位でもよいし、別の単位でもよい。
ｇＮＢは、ＰＤＣＣＨ受信タイミングとして、いくつかの選択肢を予め定め、ｇＮＢからＵＥに、選択した値の識別子を通知してもよい。前記選択肢は、規格で定めてもよいし、予めｇＮＢからＵＥに通知してもよい。前記選択肢は、ｇＮＢの傘下のＵＥに対して報知してもよいし、個別に通知してもよい。前述の個別の通知には、ＲＲＣ個別シグナリングを用いるとよい。このように前記選択肢を個別に通知することによって、ｇＮＢは、ＵＥに対して、ＰＤＣＣＨ受信タイミングを、前記選択肢から選択した値の識別子の形で通知することができるので、少ないビット数でＰＤＣＣＨ受信タイミングを通知することが可能になる。
ｇＮＢは、ＵＥに、ＰＤＣＣＨ受信タイミングを複数設定してもよい。このようにすることによって、あるＰＤＣＣＨ受信タイミングにおいてｇＮＢからＵＥへのＰＤＣＣＨの送信が不可能であった場合においても、ＵＥは、次のＰＤＣＣＨ受信タイミングにおいてＰＤＣＣＨの受信動作をすればよいので、次のＰＤＣＣＨ受信タイミングまでのＵＥの受信電力を節約することができる。
ｇＮＢからＵＥに対してＰＤＣＣＨ受信タイミングを複数設定するにあたり、１つの下り制御情報に複数のＰＤＣＣＨ受信タイミングの情報を含めてもよいし、複数の下り制御情報を多重して通知してもよい。
あるいは、それぞれが複数のＰＤＣＣＨ受信タイミングを含む下り制御情報を複数用いてもよい。１つの下り制御情報におけるＰＤＣＣＨ受信タイミングの数に上限を設けてもよい。前記上限は規格で定めてもよい。このようにすることによって、１つの下り制御情報のサイズを一定以下に抑えつつ、複数のＰＤＣＣＨ受信タイミングをｇＮＢからＵＥに通知することが可能となる。したがって、ＵＥにおける下り制御情報の受信処理が簡単になる。
複数のＰＤＣＣＨ受信タイミングの設定において、ｇＮＢおよびＵＥは、先にＵＥに通知したＰＤＣＣＨ受信タイミングと、後からＵＥに通知したＰＤＣＣＨ受信タイミングとの両方を有効にしてもよい。このようにすることによって、後からＵＥに通知するＰＤＣＣＨ受信タイミングの数を少なくすることができる。
あるいは、先にＵＥに通知したＰＤＣＣＨ受信タイミングを無効として、後からＵＥに通知したＰＤＣＣＨ受信タイミングを有効にしてもよい。このようにすることによって、ＵＥにおけるＰＤＣＣＨの受信動作の制御を簡単にすることができるとともに、ＵＥにおけるＰＤＣＣＨの受信動作による消費電力を少なくすることができる。
前述において、先にＵＥに通知したＰＤＣＣＨ受信タイミングを有効にするかどうかを、規格で定めてもよいし、予めｇＮＢからＵＥに通知してもよいし、後からＵＥに通知するＰＤＣＣＨ受信タイミングの通知に、先に通知したＰＤＣＣＨ受信タイミングを有効とするかどうかの情報を含めてもよい。例えば、前記情報を後からＵＥに通知するＰＤＣＣＨ受信タイミングの通知に含めることによって、ＰＤＣＣＨ受信タイミングの制御を柔軟に行うことが可能となる。
図９は、ｇＮＢからＵＥへの、次のＰＤＣＣＨを受信する必要のあるタイミングの通知、および該ＵＥにおける上り／下りデータの送受信の一例を示す図である。図９では、ｇＮＢからＵＥに送信する下り制御情報によって、該ＵＥの次の送受信タイミングが通知されている。図９において、参照符号９０２，９０６，９１０で示す部分は、該ＵＥがｇＮＢから受信する下り制御信号を表している。参照符号９０３，９０７，９１１で示す部分は、該ＵＥが送受信するユーザデータを表している。太い実線の矢印９０４，９０８，９１２は、次のＰＤＣＣＨ受信タイミングが示すサブフレームの情報を表している。下り制御情報９０２，９０６，９１０は、該サブフレームにおけるユーザデータ９０４，９０８，９１２の送受信のためのスケジューリング情報を含んでもよいし、含まなくてもよい。図９においては、下り制御信号９０２，９０６，９１０が該サブフレームにおけるユーザデータ９０４，９０８，９１２の送受信のためのスケジューリング情報を含む場合について示している。
図９において、ＵＥは、サブフレーム９０１における下り制御信号９０２を受信する。ＵＥは、前記下り制御信号９０２から、サブフレーム９０１のユーザデータ９０３の送受信のためのスケジューリング情報および次のＰＤＣＣＨ受信タイミングに関する情報９０４を取得する。ＵＥは、ｇＮＢとの間で、ユーザデータ９０３を送受信する。ユーザデータ９０３の送受信には、下り制御信号９０２に含まれるスケジューリング情報を用いる。
図９において、次のＰＤＣＣＨ受信タイミングに関する情報９０４には、ＵＥの次のＰＤＣＣＨ受信タイミングが、サブフレーム９０５であることが示されている。ＵＥは、サブフレーム９０５において、下り制御信号９０６を受信する。ＵＥは、受信した下り制御信号９０６から、サブフレーム９０５のユーザデータ９０７に関する情報および次のＰＤＣＣＨ受信タイミングに関する情報９０８を取得する。ＵＥは、ｇＮＢとの間で、ユーザデータ９０７を送受信する。ユーザデータ９０７の送受信には、下り制御信号９０６に含まれるスケジューリング情報を用いる。
図９において、次のＰＤＣＣＨ受信タイミングに関する情報９０８には、ＵＥの次のＰＤＣＣＨ受信タイミングが、サブフレーム９０９であることが示されている。以降の流れは、前述と同じであるので、説明を省略する。
ｇＮＢは、次のＰＤＣＣＨ受信タイミングを示す下り制御情報を含むＰＤＣＣＨに、他の下り制御情報を含めてもよい。前記他の下り制御情報は、例えば、上り／下りデータのスケジューリングに関する情報であってもよいし、ＣＱＩ送信要求であってもよいし、ＵＥへの電力制御指示であってもよい。
あるいは、ｇＮＢは、ＵＥが次にＰＤＣＣＨ受信タイミングを示す下り制御情報を含むＰＤＣＣＨに、他の下り制御情報を含めなくてもよい。このようにすることによって、例えば、ｇＮＢが前記タイミングにおいて送受信すべき上り／下りデータの送受信がなく、かつ、ｇＮＢからＵＥに送信すべき下り制御情報が他にない場合においても、ＵＥは、次のＰＤＣＣＨ受信タイミングをｇＮＢから受信することができる。したがって、ＵＥは、無駄なＰＤＣＣＨの受信動作を行わないでよくなる。
ｇＮＢは、同じビームで送受信をしている複数のＵＥに対して、次のＰＤＣＣＨ受信タイミングを通知してもよい。前記複数のＵＥは、該ビームを用いて送受信を行う全てのＵＥであってもよいし、全てのＵＥでなくともよい。前記タイミングの通知には、Ｌ１／Ｌ２シグナリングを用いるとよい。前記タイミングの通知は、複数のＵＥのそれぞれに対して行ってもよいし、該ビームを用いる全てのＵＥに対して一斉に行ってもよい。
前記タイミングを、該ビームを用いる全てのＵＥに対して一斉に通知するにあたり、前記ビームを表す識別子を用いてもよい。例えば、下り制御情報の符号化処理に前記識別子を用いてもよい。あるいは、前記下り制御情報の変調処理に前記識別子を用いてもよい。符号化処理と変調処理との両方に前記識別子を用いてもよい。
ｇＮＢは、複数のＵＥに対する下り制御信号を多重して送信してもよい。前記多重は、前記タイミングを複数のＵＥのそれぞれに対する通知に用いてもよい。前記多重は、周波数多重であってもよいし、時間多重であってもよいし、周波数多重と時間多重とを組合せてもよい。前記多重の方法は、規格で定めてもよいし、予めｇＮＢから配下のＵＥに報知してもよいし、各ＵＥに通知してもよい。
前記タイミングを複数のＵＥのそれぞれに対して通知するにあたり、ｇＮＢは、各ＵＥに同じタイミングを通知してもよいし、異なるタイミングを通知してもよい。複数のＵＥに同じ値を通知することによって、ｇＮＢは、前記複数のＵＥのスケジューリングを柔軟に行うことができる。例えば、前記タイミングにおいて、該ビーム内の予め定めるＵＥに対するユーザデータの送受信がない場合においても、該ビーム内の他のＵＥに対して、前記タイミングにおけるユーザデータの送受信を割り当てることができる。したがって、前記タイミングにおける周波数リソースを効率的に使用することができる。
ｇＮＢは、ＵＥと送受信する上り／下り信号に、他のＵＥに対する下り制御信号を多重してもよい。前記上り／下り信号は、該ＵＥに対する下り制御信号を含んでもよい。前記多重は、周波数多重であってもよいし、時間多重であってもよいし、周波数多重と時間多重とを組合せてもよい。前記多重の方法は、規格で定めてもよいし、予めｇＮＢから配下のＵＥに報知してもよいし、各ＵＥに通知してもよい。このようにすることによって、例えば、ｇＮＢは、該ＵＥとの上り／下りデータの送受信と、該ＵＥの次のＰＤＣＣＨ受信タイミングの通知に加え、他のＵＥの次のＰＤＣＣＨ受信タイミングを通知することができるので、周波数リソースおよび時間リソースを効率的に使用することができる。
ｇＮＢは、ＵＥの次のＰＤＣＣＨ受信タイミングにおいて、該ＵＥに対するＰＤＣＣＨを送信しなくてもよい。該ＵＥとの上り／下り送受信を行わなくてもよい。これによって、ｇＮＢは、ＵＥとの送受信データがない場合における消費電力を抑えることができる。
ＵＥの次のＰＤＣＣＨ受信タイミングをｇＮＢが判断するために必要な情報の具体例として、以下の（１）〜（１１）の１１個を開示する。
（１）チャネル状況。例えば、ＣＱＩ／ＣＳＩ。
（２）チャネル状況の変動。例えば、ＣＱＩ／ＣＳＩの変動。
（３）バッファ滞留量。
（４）バッファ滞留量の変動。
（５）目標サービス品質（target Quality of Service：target ＱｏＳ）。
（６）目標サービス品質と実際のサービス品質の差分。
（７）ビーム内にいるＵＥの情報。例えば、ビーム内にいるＵＥ数。
（８）マスターｅＮＢから自ｇＮＢに送信されるユーザデータのスループット。
（９）上位ネットワーク装置から自ｇＮＢに送信されるユーザデータのスループット。
（１０）自ｇＮＢからセカンダリｅＮＢに送信するユーザデータのスループット。
（１１）前記（１）〜（１０）の組合せ。
前記（１）において、例えば、ｇＮＢは、ＵＥから通知されるＣＱＩ／ＣＳＩが悪いときに、該ＵＥに対する前記タイミングまでの期間を長く設定し、ＣＱＩ／ＣＳＩが良いときに、前記タイミングまでの期間を短く設定することによって、ＣＱＩ／ＣＳＩが良いＵＥに対して頻繁に送受信タイミングを割り当ててもよい。これによって、システム全体としてのスループットを高めることができる。あるいは、例えば、ＣＱＩ／ＣＳＩが悪いときに前記タイミングまでの期間を短く設定してもよい。これによって、該ＵＥにおけるＨＡＲＱの初送から再送までの時間を短くできるので、ＨＡＲＱ再送による遅延を小さくすることができる。
前記（２）において、例えば、ＵＥから通知されるＣＱＩ／ＣＳＩの変動が大きいときに、ｇＮＢが該ＵＥに対する前記タイミングを短く設定することによって、ｇＮＢによるスケジューリングを通信チャネルの変動に迅速に追従させることができる。
前記（３）において、ｇＮＢは、下り通信用のバッファ滞留量を用いてもよいし、上り通信用のバッファ滞留量を用いてもよい。上り通信用のバッファ滞留量は、ＵＥからｇＮＢに通知するバッファ状態報告（Buffer Status Report：ＢＳＲ）を用いてもよいし、他の値を用いてもよい。
前記（３）において、例えば、ＵＥにおけるバッファ滞留量が大きいときに、ｇＮＢが該ＵＥに対する前記タイミングまでの期間を短く設定することによって、ｇＮＢと該ＵＥとの通信が頻繁に行われるので、該ＵＥにおけるバッファ溢れを防ぐことができる。
また、前記（３）におけるバッファ滞留量は、例えば、下り通信においては、他のＵＥ向けデータのバッファ滞留量との相対値でもよいし、上り通信においては、他のＵＥのバッファ滞留量との相対値でもよい。前述の相対値を用いることによって、バッファ滞留量が多いＵＥに対して、前記タイミングまでの期間を短く設定することができるので、バッファ滞留量が多いＵＥのバッファ溢れを防ぐことができる。
前記（４）において、例えば、ＵＥのバッファ滞留量が増加しているときに、該ＵＥに対する前記タイミングまでの期間を短く設定することによって、ｇＮＢによるスケジューリングのバッファ滞留量増加への追従を迅速に行うことができる。
前記（５）において、例えば、超高信頼性・低遅延（Ultra Reliability and Low Latency Communication：ＵＲＬＬＣ）のサービスを用いて通信するＵＥに対し、前記タイミングまでの期間を短く設定することによって、該ＵＥにおける遅延を小さくすることができる。
前記（６）において、例えば、モバイルブロードバンド（enhanced Mobile BroadBand：ｅＭＢＢ）のサービスを用いて通信するＵＥに対し、予め定める通信速度を確保できないときに、前記タイミングまでの期間を短く設定してもよい。これによって、該ＵＥにおける通信速度を上げて前記予め定める通信速度を確保することができる。
前記（７）において、例えば、あるビームに多くのＵＥが在圏している場合、前記ＵＥのそれぞれに対して前記タイミングまでの期間を短く設定することによって、各ＵＥのスループットを確保することができる。
前記（８）において、例えば、ＤＣにおいて該ｇＮＢがマスターｅＮＢから受信するユーザデータが増加しているときに、該ｇＮＢは配下のＵＥに対して前記タイミングまでの期間を短く設定することによって、該ｇＮＢは、前記ユーザデータを滞留させることなく、ＵＥに送信することができる。ここで、前記マスターｅＮＢは、ＬＴＥの基地局であるが、５Ｇの基地局に置き換えたもの、すなわち、ＤＣにおいてマスターとなる基地局、例えば、マスターｇＮＢであってもよい。
前記（９）において、例えば、該ｇＮＢが上位ネットワーク装置から受信するユーザデータが増加しているときに、前記タイミングまでの期間を短く設定することによって、前記ユーザデータを滞留させることなく、ＵＥに送信することができる。ここで、該ｇＮＢは、ＤＣの構成をとっていてもよい。前記ＤＣの構成において、該ｇＮＢは、マスターとなる基地局であってもよい。また、前記上位ネットワーク装置は、ＬＴＥにおける上位ネットワーク装置であってもよいし、５Ｇにおける上位ネットワーク装置であってもよい。
前記（１０）において、例えば、ＤＣにおいて該ｇＮＢがマスターとなる基地局である場合、該ｇＮＢからセカンダリｅＮＢに送信するユーザデータのスループットが減少しているときに、前記タイミングまでの期間を短く設定してもよい。これによって、該ｇＮＢからＵＥへのユーザデータ送信において、該ｇＮＢにおける滞留を抑制することができる。ここで、セカンダリｅＮＢは、５Ｇの基地局に置き換えたもの、すなわち、ＤＣにおいてセカンダリとなる基地局、例えば、セカンダリｇＮＢであってもよい。
前記（１１）において、例えば、前記（３）と前記（７）とを組合せ、あるビームを用いているＵＥのバッファ滞留量を合算し、また、合算したバッファ滞留量が多いビームを用いているＵＥに前記タイミングまでの期間を短く設定することによって、前記ビームを用いているＵＥとの通信におけるバッファ溢れを防ぐことができる。
また、例えば、前記（１１）において、前記（９）と前記（１０）とを組合せ、例えば、該ｇＮＢがマスター基地局となるＤＣ構成において、上位ネットワーク装置から自ｇＮＢに送信されるユーザデータのスループットから、該ｇＮＢからセカンダリｅＮＢに送信されるユーザデータのスループットを減じた値を用い、前記減じた値が増加しているときに、前記タイミングまでの期間を短く設定してもよい。このようにすることによって、該ｇＮＢに蓄積されるデータ量を用いて前記タイミングを設定できるようになるので、該ｇＮＢにおける滞留を抑制しつつ、ＵＥにユーザデータを送信することができる。
ｇＮＢからＵＥへの次のＰＤＣＣＨ受信タイミングの通知について、ｇＮＢは、予め定める期間におけるＰＤＣＣＨ受信タイミングを該ＵＥに通知してもよい。ＰＤＣＣＨ受信タイミングは複数であってもよい。ｇＮＢは、前記期間における送受信タイミングを決定するとよい。ＵＥは、前記タイミングでｇＮＢとの送受信を行う。このようにすることによって、ｇＮＢは、ＵＥに毎回ＰＤＣＣＨ受信タイミングを通知する必要がなくなり、また、ｇＮＢが、あるＰＤＣＣＨ受信タイミングで該ＵＥと通信ができない場合においても、ｇＮＢと該ＵＥとは、次のＰＤＣＣＨ受信タイミングにおいて通信を行うことが可能となる。
前述において、ｇＮＢは、ＵＥに、前記予め定める期間を通知するとよい。予め定める期間として、例えば、満了までの該ＵＥとのデータの送受信回数を用いてもよいし、満了までのサブフレーム数を用いてもよいし、満了時のサブフレーム番号を用いてもよい。
ｇＮＢは、ＵＥに、予め定める期間とＰＤＣＣＨ受信タイミングとを別々に通知してもよい。あるいは、予め定める期間とＰＤＣＣＨ受信タイミングとを同時に通知してもよい。予め定める期間とＰＤＣＣＨ受信タイミングとを同じ下り制御情報を用いて通知してもよいし、異なる下り制御情報を用いて通知してもよい。ＵＥは、前記通知を用いて、予め定める期間を更新してもよいし、ＰＤＣＣＨ受信タイミングを更新してもよい。
ｇＮＢは、予め定める期間として示す値を直接ＵＥに通知してもよいし、いくつかの選択肢を予め定め、ｇＮＢからＵＥに、選択した値の識別子を通知してもよい。前記選択肢は、規格で定めてもよいし、予めｇＮＢからＵＥに通知してもよい。前記選択肢の通知は、ｇＮＢの傘下のＵＥに対して報知してもよいし、個別に通知してもよい。前述の個別の通知は、ＲＲＣ個別シグナリングを用いるとよい。このようにすることによって、ｇＮＢは、ＵＥに対し、前記期間を、前記選択肢から選択した値の識別子の形で通知できるので、少ないビット数で前記期間を通知することが可能になる。
ｇＮＢは、ＵＥに、ＰＤＣＣＨ受信タイミングをビットマップの形式で通知してもよい。例えば、予め定める期間までのサブフレーム数を１０として、ＰＤＣＣＨ受信タイミングとして、１サブフレーム後、３サブフレーム後、６サブフレーム後、８サブフレーム後を指定する場合、前記タイミングに対応するビットを「１」とし、それ以外のビットを「０」とし、ＵＥに通知するビットマップとして、「１０１００１０１００」としてもよい。このようにすることによって、ＰＤＣＣＨ受信タイミングを少ないビット数で通知することが可能となる。前記において、「１」と「０」を逆としてもよい。
前記期間およびＰＤＣＣＨ受信タイミングは、ｇＮＢからＵＥに対して変更可能としてもよい。ｇＮＢは、前記期間およびＰＤＣＣＨ受信タイミングを、準静的に変更してもよいし、動的に変更してもよい。ｇＮＢは、ＵＥに対して、前記期間およびＰＤＣＣＨ受信タイミングを、該ＵＥに対するＰＤＣＣＨ受信タイミングのたびに通知してもよいし、前記期間内においてＰＤＣＣＨ受信タイミングの変更を行うときのみ通知してもよいし、前記期間を更新するときに通知してもよい。ｇＮＢは、ＵＥに対して、前記期間が満了する前に前記期間およびＰＤＣＣＨ受信タイミングを更新することが望ましい。このようにすることによって、ＵＥがＰＤＣＣＨの受信動作を毎サブフレーム行うことによる電力の浪費を防ぐことができる。あるいは、ｇＮＢは、ＵＥに対して、前記期間が満了した後すぐに前記期間およびＰＤＣＣＨ受信タイミングを通知してもよい。
ｇＮＢは、ＵＥに対して、前記期間およびＰＤＣＣＨ受信タイミングを準静的に通知してもよいし、動的に通知してもよい。前記準静的な通知として、例えば、ＲＲＣ個別シグナリングを用いてもよい。また、前記動的な通知として、例えば、ＭＡＣ制御信号を用いてもよいし、Ｌ１／Ｌ２シグナリングを用いてもよい。前記期間の通知と前記タイミングの通知とには、同じ方法を用いてもよいし、異なる方法を用いてもよい。また、前述の方法を組合せて用いてもよい。例えば、ｇＮＢがＵＥに対して、前記期間をＲＲＣ個別シグナリングを用いて通知し、また、ＰＤＣＣＨ受信タイミングをＬ１／Ｌ２シグナリングを用いて通知することによって、前記期間内における前記タイミングの動的な変更を、少ないシグナリング量で行うことができる。
ｇＮＢが前記期間およびＰＤＣＣＨ受信タイミングを判断するために必要な情報として、前述の送受信タイミングを判断するために必要な情報の具体例として開示した前記（１）〜（１１）を用いてもよい。
図１０は、ｇＮＢからＵＥへの、予め定める期間におけるＰＤＣＣＨ受信タイミングの通知および該ＵＥにおける上り／下りデータの送受信の一例を示す図である。図１０では、ｇＮＢからＵＥに送信する下り制御情報によって、前記期間および前記タイミングが通知されている。また、図１０において、参照符号１００１，１００７で示す部分は、ＵＥがｇＮＢから受信する下り制御信号のうち、該ＵＥ向けの予め定める期間およびＰＤＣＣＨ受信タイミングの通知があるものを表している。
参照符号１００３，１００５，１００９で示す部分は、該ＵＥがｇＮＢから受信する下り制御信号を表している。参照符号１００２，１００４，１００６，１００８，１０１０で示す部分は、該ＵＥがｇＮＢと送受信するユーザデータを表している。太い実線の矢印は、該ＵＥのＰＤＣＣＨ受信タイミングの情報を表している。また、予め定める期間Ｔ０を太い点線で表しており、下り制御信号における予め定める期間Ｔ０の情報を、太い一点鎖線で表している。細い実線の矢印は、該サブフレームにおけるユーザデータの送受信のためのスケジューリング情報を表している。下り制御信号１００１，１００３，１００５，１００７，１００９は、該サブフレームにおけるユーザデータ１００２，１００４，１００６，１００８，１０１０の送受信のためのスケジューリング情報を含んでもよいし、含まなくてもよい。図１０においては、下り制御信号１００１，１００３，１００５，１００７，１００９が、該サブフレームにおけるユーザデータ１００２，１００４，１００６，１００８，１０１０の送受信のためのスケジューリング情報を含む場合について示している。
図１０において、ＵＥは、下り制御信号１００１，１００３，１００５，１００７，１００９を受信する。このうち、下り制御信号１００１，１００７には、該サブフレームのユーザデータの送受信のためのスケジューリング情報に加え、予め定める期間に関する情報および予め定める期間内のＰＤＣＣＨ受信タイミングに関する情報が格納されている。ＵＥは、ＰＤＣＣＨ受信情報を取得し、取得した前記情報が格納されていた下り制御信号１００１，１００７よりも後の下り制御信号１００３，１００５，１００９の受信を行う。ＵＥは、下り制御信号１００１，１００３，１００５，１００７，１００９から取得したスケジューリング情報を用いてユーザデータ１００２，１００４，１００６，１００８，１０１０の送受信を行う。
図１０において、ｇＮＢは、下り制御信号１００３，１００５，１００９においても、ＰＤＣＣＨ受信タイミングをＵＥに通知してもよい。予め定める期間を併せて通知してもよい。このようにすることによって、前記ＵＥ向けのＰＤＣＣＨ受信タイミングの通知における冗長性が増すので、ＰＤＣＣＨ受信タイミングの通知の信頼性を向上させることができる。
図１０において、ｇＮＢは、下り制御信号１００３，１００５，１００９において、ＰＤＣＣＨ受信タイミングをＵＥに通知しなくてもよい。このようにすることによって、下り制御信号のビット数を節約することができる。
前述の、ｇＮＢからＵＥへのＰＤＣＣＨ受信タイミングの通知の他の例として、ｇＮＢは、前述とは逆に、ＵＥに、ｇＮＢからのＰＤＣＣＨの受信動作を行わなくてよいタイミング（以下「ＰＤＣＣＨ受信不要タイミング」と称する）を通知してもよい。ＰＤＣＣＨ受信不要タイミングは、予め定める期間と併せて通知してもよい。ＵＥは、ＰＤＣＣＨ受信不要タイミングに該当しないサブフレームにおいて、ｇＮＢからのＰＤＣＣＨの受信動作を行うこととしてもよい。
ＰＤＣＣＨ受信不要タイミングは、予め定める期間におけるＰＤＣＣＨ受信タイミングの通知と同様に、サブフレーム番号を用いて通知してもよいし、現在から数えたサブフレーム数として通知してもよいし、あるいはビットマップの形式として通知してもよい。
ｇＮＢは、ＰＤＣＣＨ受信不要タイミングとして、既に他のＵＥへのスケジューリングが決まっているサブフレームを指定してもよい。このようにすることによって、ｇＮＢは、ＰＤＣＣＨ受信不要タイミング以外におけるサブフレームの範囲中で、ＵＥに対して柔軟にスケジューリングを行うことができる。
ｇＮＢからＵＥへのＰＤＣＣＨ受信タイミングの通知の他の例として、ｇＮＢは、ＵＥに、ＰＤＣＣＨ受信周期を設定してもよい。ＰＤＣＣＨ受信周期は、サブフレーム単位で通知してもよいし、他の単位で通知してもよい。ＰＤＣＣＨ受信周期の設定方法を開示する点で、本実施の形態は参考文献１と異なる。
前述の、ＰＤＣＣＨ受信周期の設定において、ｇＮＢは、ＵＥに、ＰＤＣＣＨ受信周期の有効期間を併せて設定してもよい。有効期間の設定は、前述の予め定める期間と同様に行うとよい。
ｇＮＢは、ＵＥに対して、ＰＤＣＣＨ受信周期と併せてＰＤＣＣＨ受信タイミングのオフセットを通知するとよい。前記オフセットは、サブフレーム番号として通知してもよいし、前記サブフレーム番号の前記周期による剰余として通知してもよいし、該ＵＥにおける次のＰＤＣＣＨ受信タイミングまでの時間として通知してもよい。前記時間は、サブフレーム単位で通知してもよいし、他の単位で通知してもよい。
ｇＮＢは、ＵＥに対して、ＰＤＣＣＨ受信周期および前記オフセットと併せて、ＰＤＣＣＨ受信周期および前記オフセットが有効になるタイミングを通知するとよい。有効になるタイミングは、サブフレーム番号で通知してもよいし、通知時から有効になるまでの時間として通知してもよい。
ｇＮＢは、ＵＥに対して、ＰＤＣＣＨ受信周期、前記オフセットおよび前記有効になるタイミングをそれぞれ別々に通知してもよいし、複数のものを同時に通知してもよい。
ｇＮＢは、ＰＤＣＣＨ受信周期として示す値を直接ＵＥに通知してもよいし、いくつかの選択肢を予め定め、ｇＮＢからＵＥに、選択した値の識別子を通知してもよい。前記選択肢は、規格で定めてもよいし、予めｇＮＢからＵＥに通知してもよい。前記選択肢の通知は、ｇＮＢの傘下のＵＥに対して報知してもよいし、個別に通知してもよい。前述の個別の通知は、ＲＲＣ個別シグナリングを用いるとよい。このように前記選択肢を個別に通知することによって、ｇＮＢは、ＵＥに対して、ＰＤＣＣＨ受信周期を、前記選択肢から選択した値の識別子の形で通知できるので、少ないビット数でＰＤＣＣＨ受信周期を通知することが可能になる。前記オフセットおよび前記有効になるタイミングについても同様としてもよい。
ｇＮＢは、ＵＥに対して、ＰＤＣＣＨ受信周期、前記オフセットおよび前記有効になるタイミングを準静的に通知してもよいし、動的に通知してもよい。前記準静的な通知として、例えば、ＲＲＣ個別シグナリングを用いてもよい。また、前記動的な通知として、例えば、ＭＡＣ制御信号を用いてもよいし、Ｌ１／Ｌ２シグナリングを用いてもよい。ＰＤＣＣＨ受信周期、前記オフセットおよび前記有効になるタイミングの通知には、同じ方法を用いてもよいし、異なる方法を用いてもよい。また、前述の方法を組合せて用いてもよい。
ｇＮＢは、ＵＥに、予め定める周期におけるＰＤＣＣＨ受信タイミングを通知してもよい。前記通知において、例えばビットマップを用いてもよい。前記ビットマップにおいて、予め定める周期をビット数としてもよい。また、ＰＤＣＣＨ受信タイミングに「１」を対応付け、それ以外のサブフレームに「０」を対応付けてもよい。また、ビットの位置を、サブフレーム番号の予め定める周期による剰余に対応付けてもよい。例えば、予め定める周期を４サブフレームとし、ＵＥのＰＤＣＣＨ受信タイミングを、サブフレーム番号の予め定める周期による剰余が０、１、３とした場合、ｇＮＢはＵＥに前記ビットマップとして「１１０１」を通知してもよい。このようにすることによって、ｇＮＢからＵＥへのＰＤＣＣＨ受信タイミングの割り当てを柔軟に行うことができる。
ｇＮＢは、異なるＵＥに対して、異なる割合でＰＤＣＣＨ受信タイミングを配分してもよい。
例えば、ＵＥ＃１のＰＤＣＣＨ受信タイミングを、サブフレーム番号を３で割った余りが０あるいは１となるサブフレームとし、ＵＥ＃２のＰＤＣＣＨ受信タイミングを、サブフレーム番号を６で割った余りが４となるサブフレームとし、ＵＥ＃３のＰＤＣＣＨ受信タイミングを、サブフレーム番号を６で割った余りが５となるサブフレームとしたとき、ｇＮＢがＵＥ＃１、ＵＥ＃２、ＵＥ＃３のそれぞれに対して通知するビットマップを、それぞれ、「１１０」、「００００１０」、「０００００１」としてもよい。このようにすることによって、異なるＵＥへのＰＤＣＣＨ受信タイミングの割り当てを柔軟に行うことができる。
ｇＮＢが前記予め定める周期、前記オフセット、前記有効になるタイミングを判断するために必要な情報として、前述のＰＤＣＣＨ受信タイミングを判断するために必要な情報の具体例として開示した前記（１）〜（１１）を用いてもよい。
ＵＥは、ｇＮＢから送信されるＰＤＣＣＨの受信動作を毎サブフレーム行うとしてもよい。ＵＥがＰＤＣＣＨの受信動作を毎サブフレーム行う契機としては、例えば、ＵＥのＰＤＣＣＨ受信タイミングが過ぎた、あるいは存在しない場合でもよいし、前述の、予め定める期間が満了した場合でもよいし、ｇＮＢからの下り制御信号を正常に受信できなかった場合でもよいし、ｇＮＢからの下りユーザデータを正常に受信できなかった場合でもよい。このようにして、ＵＥがＰＤＣＣＨの受信動作を毎サブフレーム行うことによって、ＵＥは、ｇＮＢから自ＵＥ向けの下り制御信号を受信することができ、ｇＮＢとの通信を復旧あるいは継続させることができる。
ｇＮＢは、ＵＥ向けの下りユーザデータの再送を、初送データを送信した次のＰＤＣＣＨ受信タイミングを用いて行ってもよい。あるいは、次のＰＤＣＣＨ受信タイミングによらず、初送データを送信したタイミングの次のサブフレームで、ｇＮＢはＵＥに再送を行ってもよい。ＵＥは、前記再送を、初送の次のＰＤＣＣＨ受信タイミングで受信してもよいし、初送の次のサブフレームで受信してもよい。あるいは、ＵＥは、ＰＤＣＣＨ受信の毎サブフレーム実行を用いてｇＮＢから再送データを受信してもよい。ｇＮＢが再送を初送の次のサブフレームで行うことによって、ｇＮＢおよびＵＥ間の通信において、Ｎａｃｋによる遅延を少なくすることができる。また、例えば、ＵＥが次のＰＤＣＣＨ受信タイミングの通知に用いられるＲＲＣシグナリングあるいはＭＡＣ制御情報を正常に受信できなかった場合に、ＵＥは、次のサブフレームにおいて、ＰＤＣＣＨ受信タイミングを取得することができる。
ｇＮＢが再送に初送の次のサブフレームを用いるか否かを表す情報を、ｇＮＢは、ＵＥに予め通知するか、あるいは、規格で定めるとよい。ｇＮＢは、傘下のＵＥに対する報知によって前記通知を行ってもよいし、ＵＥにＲＲＣ個別シグナリングを送信することによって前記通知を行ってもよい。ＵＥは、前記通知を用いて、再送を初送の次のサブフレームで受信するかどうかを判断してもよい。
ｇＮＢは、ＵＥへの再送に初送の次のサブフレームを用いるか否かを、該ＵＥが在圏するビームの情報を用いて決めてもよい。前記ビームの情報は、例えば、該ビームに在圏するＵＥの数であってもよい。例えば、該ビームに在圏するＵＥが多い場合は、該ＵＥへの再送に初送の次のサブフレームを用いないとしてもよい。このようにすることによって、例えば、該ＵＥへの再送によって他のＵＥと送受信すべきデータが輻輳することを防ぐことができる。
他の例として、ＵＥが用いるサービスの情報を用いて決めてもよい。例えば、該ＵＥがＵＲＬＬＣのサービスを用いる場合に、該ＵＥへの再送に初送の次のサブフレームを用いるとしてもよい。このようにすることによって、例えば、ＵＲＬＬＣにおける低遅延といったように、該ＵＥが用いるサービスの要件を満たすことができる。
前述において、ＵＥへの再送を初送の次のサブフレームとする代わりに、指定のサブフレームだけ後のサブフレームとしてもよい。このようにすることによって、ｇＮＢから該ＵＥへの再送が発生する場合においても、他のＵＥへの通信を継続させることができる。
前記指定のサブフレームの値について、規格で決定してもよいし、ｇＮＢから傘下のＵＥに対して報知してもよいし、各ＵＥに対してＲＲＣシグナリングで通知してもよい。ｇＮＢは、前記サブフレームの値を、ＵＥが用いるビームの情報を用いて決めてもよいし、ＵＥが用いるサービスの情報を用いて決めてもよい。
ｇＮＢは、ＵＥにおける次のＰＤＣＣＨ受信タイミングにおいて、他のＵＥとの送受信を行ってもよい。前記他のＵＥとの送受信とは、例えば、前記他のＵＥの再送であってもよいし、優先度が高い通信であってもよい。前記優先度は、例えば、ＵＥが用いるサービスの種別を用いて、規格によって決めてもよいし、ｇＮＢが決定してもよい。
前述において、ｇＮＢは、ＰＤＣＣＨ受信タイミングにおいて、該ＵＥ、すなわち、ＰＤＣＣＨ受信タイミングにおいて前記他のＵＥに割り込まれたＵＥに、Ｌ１／Ｌ２シグナリングを送信しなくてもよい。該ＵＥは、ＰＤＣＣＨを毎サブフレームで連続して受信する動作に戻ってもよいし、ＰＤＣＣＨ受信タイミングの次のＰＤＣＣＨ受信タイミングでｇＮＢからのＰＤＣＣＨを受信する動作を行ってもよい。
前述において、ｇＮＢは、該ＵＥに、さらに次のＰＤＣＣＨ受信タイミングを通知してもよい。前記通知は、Ｌ１／Ｌ２シグナリングを用いて行ってもよい。該ＵＥ向けのＬ１／Ｌ２シグナリングと、前記他のＵＥ向けのＬ１／Ｌ２シグナリングとを多重して送信してもよい。前記多重は、例えば、異なるシンボルを用いた時間多重でもよいし、複数のビームを用いた空間多重でもよいし、両者を組合せて用いてもよい。前記時間多重において、該ＵＥ向けのＬ１／Ｌ２シグナリングが先でもよいし、前記他のＵＥ向けのＬ１／Ｌ２シグナリングが先でもよい。ｇＮＢがどちらのＬ１／Ｌ２シグナリングを先とするかについては、予め規格で定めるとよい。該ＵＥおよび前記他のＵＥは、前記規格に基づいて、それぞれ自ＵＥ向けのＬ１／Ｌ２シグナリングをｇＮＢから受信するとよい。
前述において、ｇＮＢは、該ＵＥに、ビームスイーピングブロックを用いて次のＰＤＣＣＨ受信タイミングを通知してもよい。ｇＮＢは、前記ビームスイーピングブロックを用いた通知において、該ＵＥを表す識別子と、前記タイミングとを併せて通知するとよい。ＵＥは、ビームスイーピングブロックの受信によって、次のＰＤＣＣＨ受信タイミングを取得してもよい。ＵＥは、前記ビームスイーピングブロックの受信を、ＰＤＣＣＨ受信タイミングにおいて他のＵＥに割り込まれたことを契機として行ってもよいし、常に行ってもよい。ＵＥは、ビームスイーピングブロックからのＰＤＣＣＨ受信タイミングの取得を契機として、毎サブフレームで連続してＰＤＣＣＨを受信することを止めてもよい。このようにすることによって、ＵＥは、ビームスイーピングブロック以降の毎サブフレームで連続してＰＤＣＣＨを受信する必要がなくなるので、ＵＥの消費電力を削減することができる。
ｇＮＢは、ビームスイーピングブロックによるＰＤＣＣＨ受信タイミングの通知を、該ＵＥとは別のＵＥに対して行ってもよい。前記別のＵＥへの通知は、前記別のＵＥにおける次のＰＤＣＣＨ受信タイミングよりも早いビームスイーピングブロックで行うことが望ましい。このようにすることによって、前記別のＵＥは、自ＵＥにおけるＰＤＣＣＨ受信タイミングよりも早いタイミングで、ｇＮＢとの送受信を行うことができる。
本実施の形態に示した、ＵＥにおける下り制御情報の指定タイミングにおける受信、周期的な受信、あるいは毎サブフレーム受信を、切り替え可能な構成としてもよい。ｇＮＢは、ＵＥに対して、下り制御チャネル受信方法の切り替えを指示する通知を送ってもよい。ＵＥは、前記通知を用いて、下り制御情報の受信方法を切り替えてもよい。前記通知は、前記受信方法を表す識別子を含むとよい。前記通知について、ｇＮＢからＵＥに対して、ＲＲＣ個別シグナリングを用いて準静的に通知してもよいし、ＭＡＣ制御信号を用いて動的に通知してもよいし、Ｌ１／Ｌ２シグナリングを用いて動的に通知してもよい。
本実施の形態において示す方法を、上りデータの通信に用いてもよい。その際に、ｇＮＢからＵＥに通知する内容は、下りデータの通信の場合と同じでよい。上りデータの通信においては、前記ＵＥへの上りグラントの通知を併せて行うとよい。
ｇＮＢは、ＵＥが初送データを受信した次のＰＤＣＣＨ受信タイミングを用いて、ＵＥにＡｃｋ／Ｎａｃｋを通知してもよい。ｇＮＢからＵＥへのＡｃｋ／Ｎａｃｋ通知とグラントの通知とを、同時に行ってもよいし、別々に行ってもよい。ＵＥは、前記Ａｃｋ／Ｎａｃｋ通知およびグラントを用いて、前記グラントを受信したサブフレームと同じサブフレームでｇＮＢに上りデータを送信してもよいし、別のサブフレームで送信してもよい。
ＵＥにおける次のＰＤＣＣＨ受信タイミングによらず、ＵＥが初送データを送信したサブフレームの次のサブフレームにおいて、ｇＮＢは、ＵＥにＡｃｋ／Ｎａｃｋを通知してもよい。ＵＥは、前記次のサブフレームにおいて、ｇＮＢからのＡｃｋ／Ｎａｃｋを受信してもよい。前述において、次のサブフレームの代わりに、予め定めるサブフレーム数だけ後のサブフレームでもよい。前記予め定めるサブフレーム数は、規格で定めてもよいし、ｇＮＢから傘下のＵＥに報知してもよいし、ｇＮＢからＵＥに、ＲＲＣ個別シグナリングで通知してもよい。
前述において、前記次のＰＤＣＣＨ受信タイミングによらず、ｇＮＢがＵＥにＡｃｋ／Ｎａｃｋを送信したサブフレームから予め定めるサブフレーム数だけ後のサブフレームで、ｇＮＢは、ＵＥにグラントを通知してもよい。前述において、予め定めるサブフレーム数は、０でもよいし、１でもよいし、２以上の値でもよい。予め定めるサブフレーム数が０の場合は、Ａｃｋ／Ｎａｃｋを送信したサブフレームと同じサブフレームでグラントが通知されるとしてもよい。前記予め定めるサブフレーム数は、規格で定めてもよいし、ｇＮＢから傘下のＵＥに報知してもよいし、ｇＮＢからＵＥにＲＲＣ個別シグナリングで通知してもよい。
前述において、前記次のＰＤＣＣＨ受信タイミングによらず、ｇＮＢがＵＥにグラントを送信したサブフレームから予め定めるサブフレーム数だけ後のサブフレームで、ＵＥは、ｇＮＢに再送データを送信してもよい。前述において、予め定めるサブフレーム数は、０でもよいし、１でもよいし、２以上の値でもよい。予め定めるサブフレーム数が０の場合は、ＵＥがグラントを受信したサブフレームと同じサブフレームで再送データがＵＥから送信される。前記予め定めるサブフレーム数は、規格で定めてもよいし、ｇＮＢから傘下のＵＥに報知してもよいし、ｇＮＢからＵＥにＲＲＣ個別シグナリングで通知してもよい。前記予め定めるサブフレーム数は、初送におけるグラントから初送データの間のサブフレーム数と同じであることが望ましい。
前述において、ｇＮＢは、Ａｃｋ／Ｎａｃｋ情報をＵＥへの上りグラントの中に含めてもよい。すなわち、ｇＮＢは、次の上り信号の受信に用いるグラントのＵＥへの通知において、前回の前記ＵＥからの上り信号の受信に対するＡｃｋ／Ｎａｃｋを含めてもよい。ＵＥは、前記Ａｃｋ／Ｎａｃｋを用いて、次のユーザデータの初送あるいは再送を行うとよい。
前述において、ｇＮＢは、ＡｃｋをＵＥに通知しなくてもよい。ＵＥは、予め定める時間の間、上りデータに関するＡｃｋ／Ｎａｃｋを受信しなかったことを用いて、該上りデータがｇＮＢに正しく受信されたとみなしてもよい。前記予め定める時間は、規格で定めてもよいし、ｇＮＢの傘下のＵＥに対してｇＮＢが報知してもよいし、各ＵＥに対してＲＲＣ個別シグナリングで通知してもよい。また、ｇＮＢは、前記予め定める時間を、ＵＥが使用するサービスを用いて決めてもよい。例えば、ＵＲＬＬＣを用いるＵＥには、ｅＭＢＢを用いるＵＥよりも短い時間を設定してもよい。
前述の、Ａｃｋ／Ｎａｃｋを上りグラントの中に含める方法と、ＡｃｋをＵＥに通知しない方法とを組合せて用いてもよい。このようにすることによって、ＵＥは、連続する上りユーザデータを送信し終えたときにおいても、ｇＮＢからのグラントを受信する必要がなく、最後の上りユーザデータがｇＮＢによって正常に受信されたことを知ることができる。また、ｇＮＢは、最後の上りユーザデータに対するＡｃｋを、ＵＥに通知しなくてもよいので、通信リソースの節約になる。
図１１は、上り通信において、Ａｃｋ／Ｎａｃｋの通知および再送を上り初送の次のサブフレームで行う場合の送受信チャネルを示す図である。図１１において、参照符号１１０１で示す部分は、ｇＮＢから該ＵＥに通知するグラントを含む下り制御情報を示している。また、参照符号１１０２，１１０４で示す部分は、該ＵＥからの上りユーザデータを示している。また、参照符号１１０３で示す部分は、ｇＮＢから該ＵＥに通知するＮａｃｋおよびグラントを含む下り制御情報を示している。また、参照符号１１０５で示す部分は、ｇＮＢから該ＵＥへのＡｃｋの通知を含む下り制御情報を示している。
図１１は、グラントに対する上りユーザデータが前記グラントと同じサブフレームで送信され、かつ、上りユーザデータに対するＡｃｋ／Ｎａｃｋが次のサブフレームで送信され、かつ、Ｎａｃｋと再送用のグラントが同じサブフレームで送信され、かつ、Ｎａｃｋと同じサブフレームで再送が行われる場合について示している。
図１１に示すサブフレーム＃２は、該ＵＥのＰＤＣＣＨ受信タイミングとして割り当てられている。前記サブフレーム＃２において、ｇＮＢは、該ＵＥに対してグラント１１０１を含む下り制御情報を通知する。該ＵＥは、前記グラントを含む下り制御情報１１０１と同じサブフレームであるサブフレーム＃２において、ｇＮＢに上りユーザデータ１１０２を送信する。
図１１において、ｇＮＢは、前記上りユーザデータ１１０２を正しく受信できなかった場合、サブフレーム＃３を該ＵＥに割り当て、該ＵＥに対して、Ｎａｃｋおよび再送用のグラントを含む下り制御情報１１０３を通知する。該ＵＥは、サブフレーム＃３において、Ｎａｃｋおよび再送用のグラントを含む下り制御情報１１０３を受信し、受信した下り制御情報からＡｃｋ／Ｎａｃｋを取得する。該ＵＥは、ｇＮＢからのＮａｃｋの通知を受けて、サブフレーム＃３において、上りユーザデータ１１０４を送信する。
図１１に示すサブフレーム＃４において、ｇＮＢは、Ａｃｋを含む下り制御情報１１０５を該ＵＥに通知する。該ＵＥは、サブフレーム＃４において、Ａｃｋを含む下り制御情報１１０５を受信し、受信した下り制御情報からＡｃｋ／Ｎａｃｋを取得する。
本実施の形態における上り通信において、ｇＮＢは、ＵＥにＡｃｋを通知するサブフレームを他のＵＥに割り当ててもよいし、該ＵＥに割り当ててもよい。
前述の、他のＵＥへの割り当てにおいては、ｇＮＢは、該ＵＥ向けのＡｃｋ／Ｎａｃｋと他のＵＥへの下り制御信号とを多重して送信してもよい。前記多重は、異なるシンボルを用いた時間多重としてもよいし、同じシンボル内での周波数多重としてもよい。あるいは、時間多重と周波数多重とを組合せてもよい。時間多重においては、該ＵＥ向けのＡｃｋ／Ｎａｃｋの通知が先でもよいし、前記他のＵＥ向けのＬ１／Ｌ２シグナリングが先でもよい。ｇＮＢがどちらの信号を先とするかについては、予め規格で定めるとよい。該ＵＥおよび前記他のＵＥは、前記規格に基づいて、それぞれ自ＵＥ向けの信号をｇＮＢから受信するとよい。
前述において、ｇＮＢは、ＰＤＣＣＨ受信タイミングにおいて、該ＵＥ、すなわち、ＰＤＣＣＨ受信タイミングにおいて前記他のＵＥに割り込まれたＵＥに対する動作として、下り送信と同じ動作を用いてもよい。すなわち、ｇＮＢは、該ＵＥに、Ｌ１／Ｌ２シグナリングを送信しなくてもよいし、さらに次のＰＤＣＣＨ受信タイミングを通知してもよいし、ビームスイーピングブロックを用いて次のＰＤＣＣＨ受信タイミングを通知してもよい。該ＵＥは、毎サブフレームで連続して受信を行ってもよいし、さらに次のＰＤＣＣＨ受信タイミングを受信してもよいし、ビームスイーピングブロックを受信してもよい。
本実施の形態において、ＵＥが、次のＰＤＣＣＨ受信タイミングまでの間に別のビーム、ＴＲＰ（Transmission Reception Point）、あるいはセルに帰属するにあたり、ＵＥは、無線リンク障害（Radio Link Failure：ＲＬＦ）を検出してもよい。あるいは、ＵＥは、ビームスイーピングブロックを受信してもよい。ＵＥは、前記ビームスイーピングブロックの受信において、受信したビームを用いてｇＮＢへのランダムアクセス処理を行ってもよい。
前述において、ｇＮＢは、移動元ビームと移動先ビームとで、同じＰＤＣＣＨ受信タイミングを用いてもよいし、異なるＰＤＣＣＨ受信タイミングを用いてもよい。
前述において、ｇＮＢは、移動元ＴＲＰと移動先ＴＲＰとで、同じＰＤＣＣＨ受信タイミングを用いてもよいし、異なるＰＤＣＣＨ受信タイミングを用いてもよい。移動先ＴＲＰは、移動元ＴＲＰに、移動元ＴＲＰで用いていたＰＤＣＣＨ受信タイミングの通知を要求してもよい。前記要求は、ｇＮＢ内のＴＲＰに対して一斉に行ってもよい。移動元ＴＲＰは、移動先ＴＲＰに、ＰＤＣＣＨ受信タイミングを通知してもよい。
前述において、ｇＮＢは、移動元セルと移動先セルとで、同じＰＤＣＣＨ受信タイミングを用いてもよいし、異なるＰＤＣＣＨ受信タイミングを用いてもよい。移動先セルは、移動元セルに、移動元セルで用いていたＰＤＣＣＨ受信タイミングの通知を要求してもよい。前記要求は、セル間インタフェースを用いて行ってもよい。移動元セルは、移動先セルに、ＰＤＣＣＨ受信タイミングを通知してもよい。
本実施の形態に示す方法によって、マルチビームのｇＮＢとの通信において、ＵＥが下り制御信号の受信に要する消費電力および無線リソースを節約することができる。また、Ｎａｃｋ後の再送を迅速に行うことによって、ｇＮＢとの通信の遅延を抑制することができる。
すなわち、本実施の形態によれば、基地局装置（ｇＮＢ）によって通信端末装置（ＵＥ）に、次のＰＤＣＣＨ受信タイミングに関する情報が通知される。通知端末装置は、基地局装置から通知された次のＰＤＣＣＨ受信タイミングに関する情報に基づいて受信を行う。これによって、通信端末装置は、通知されたＰＤＣＣＨ受信タイミングで、基地局装置から送信される情報を受信することができるので、受信に要する消費電力および無線リソースを節約することができる。また、再送が必要な場合には、迅速に再送を行うことができるので、基地局装置と通信端末装置との通信の遅延を抑制することができる。したがって、通信端末装置の消費電力の増大、通信品質の劣化、および無線リソースの使用効率の減少を抑えることができる。
特に本実施の形態では、基地局装置（ｇＮＢ）と通信端末装置（ＵＥ）とは、アンテナから放出されるビームの指向性を切替えて送受信を行う。この場合に、前述のように基地局装置によって通信端末装置に、次の受信タイミングに関する情報を通知することによって、通信端末装置は、自装置とは別の方向にビームが向けられているときには、受信を行わないようにすることができる。したがって、通信端末装置の消費電力の増大、通信品質の劣化、および無線リソースの使用効率の減少を抑えることができる。
本実施の形態において記載した方法を、シンボル単位でビームを切り替えることのできる通信システムに適用してもよい。また、同時に複数のビームを用いて通信できる通信システムに適用してもよい。また、前記を組合せた通信システムに適用してもよい。シンボル単位でビームを切り替えることによって、異なるビームに属するＵＥに対して、ＰＤＣＣＨ受信タイミングを同じサブフレーム内で通知することができるようになり、ｇＮＢのスケジューリングの柔軟性を向上させることができる。同時に複数のビームを用いて通信することによっても、同じ効果が得られる。
本実施の形態において記載した方法を、シングルビームのｇＮＢ、すなわち、ビームスイーピングを行わないｇＮＢに適用してもよい。本実施の形態のシングルビームのｇＮＢに適用することによって、他のｇＮＢへの干渉を低減することができる。
実施の形態２．
ＬＴＥでは、上り制御情報（Uplink Control Information：ＵＣＩ）がマッピングされる物理制御チャネルとしてＰＵＣＣＨがある。ＰＵＣＣＨのリソースは、ＵＥ毎に設定される。例えば、ＳＲ（Scheduling Request）用のＰＵＣＣＨのリソースおよびＳＲ周期などのＳＲ構成は、ＵＥ毎に設定される（３ＧＰＰ ＴＳ ３６．２１１ Ｖ１４．０．０（以下「参考文献３」という）、および３ＧＰＰ ＴＳ ３６．２１３ Ｖ１４．０．０（以下「参考文献４」という）参照）。これらの設定には、ＲＲＣシグナリングが用いられる（３ＧＰＰ ＴＳ ３６．３３１ Ｖ１４．０．０（以下「参考文献５」という）参照）。
ＮＲでは、ビームスイーピングを必要とするＭＢＦ（Multi Beam Forming）が検討されている。ビームスイーピングを必要とするＭＢＦでは、全カバレッジをカバーするために、ビーム切換が必要となる。一つのサブフレームは、一つのビームに対してのみの送受信に用いられることになるので、他のビームの送受信は不可能となる。したがって、一つのサブフレームに複数のＵＥのＰＵＣＣＨリソースを構成する従来のＬＴＥの設定方法では、該サブフレームでカバレッジを形成されないビームに存在するＵＥのＰＵＣＣＨは送受信できないという問題がある。
３ＧＰＰでは、このような問題を解決するために、ＭＢＦの運用において、ビーム毎に異なるシンボルのＰＵＣＣＨリソースを設けることが提案されている（３ＧＰＰ Ｒ１−１６０９７４０（以下「参考文献６」という）参照）。しかし、ＰＵＣＣＨリソースをシンボル毎に設定することは開示されているが、その設定方法については何ら開示されていない。例えば、どのシンボルをどのビームのＰＵＣＣＨ用に割当てるか、どのようにＵＥ毎に割当てるかなどについては全く開示されていない。
したがって、各ビームに存在するＵＥは、自ＵＥが通信を行っているビームにおけるＰＵＣＣＨの送信タイミングおよびリソースを認識できないことになる。ＵＥが通信を行っているビームにおいて、セルでのＰＵＣＣＨの受信タイミングおよびリソースと、ＵＥのＰＵＣＣＨの送信タイミングおよびリソースとを合わせることができない場合、ＰＵＣＣＨの送受信が不可能になるという問題が発生する。
本実施の形態では、このような問題を解決する方法を開示する。
ＰＵＣＣＨのためのリソースの割当方法について開示する。ビーム毎のＰＵＣＣＨのために、リソースを割当てる。ビーム毎のＰＵＣＣＨリソースとして、サブフレームおよびシンボルを割当てる。シンボルの割当ては、シンボル番号で行うとよい。サブフレーム内で設定されるシンボル番号で行うとよい。あるいは、サブフレームに割当てられるＰＵＣＣＨ用リソースの最大シンボル数を決めてもよい。シンボル番号は、最大シンボル数でリナンバリングしてもよい。これによって、シンボル番号を表す情報量、例えばビット数を削減することができる。
ＵＥが存在するビームのＰＵＣＣＨリソースから、ＵＥ毎のＰＵＣＣＨリソースを割当てる。すなわち、各ビームのＰＵＣＣＨリソース上で、ＵＥ毎のＰＵＣＣＨリソースを割当てて、多重する。
ＵＥが存在するビームのＰＵＣＣＨリソースから、ＵＥ毎のＵＣＩ毎のＰＵＣＣＨリソースを割当ててもよい。すなわち、各ビームのＰＵＣＣＨリソース上で、ＵＥ毎のＵＣＩ毎のＰＵＣＣＨリソースを割当てて多重してもよい。サブフレーム内で、ＰＵＣＣＨリソースのシンボルを送受信するビームと、該シンボルと異なるシンボルを送受信するビームとを異ならせてもよい。
ビーム毎のＰＵＣＣＨリソースの設定方法について開示する。ビーム毎のＰＵＣＣＨを割当てるサブフレームを周期およびオフセットで設定し、ＰＵＣＣＨを割当てるシンボルをシンボル番号で設定する。
図１２は、ビーム毎のＰＵＣＣＨリソースを、周期、オフセット、シンボル番号で設定する方法の一例を説明する図である。ここでは、ビームスイープ数が４個の場合について示す。予め定めるカバレッジをカバーするために必要となるビーム切換数をビームスイープ数とする。
ビーム番号０のＰＵＣＣＨリソースとして、周期を５サブフレームとし、オフセットを０サブフレームとし、サブフレーム内シンボル番号を１０としたリソース１２０１を設定する。これによって、ビーム番号０のＰＵＣＣＨは、基準サブフレーム番号、例えばサブフレーム番号０のサブフレームからオフセットが０のサブフレームで、周期が５サブフレームで、サブフレーム内シンボル番号が１０（シンボル＃１０）のリソース１２０１に割当てられる。基準サブフレーム番号は、予め設定されるとよい。基準サブフレーム番号は、例えば、規格などで予め決めておくとよい。
同様に、ビーム番号１のＰＵＣＣＨリソースとして、周期を１０サブフレームとし、オフセットを１サブフレームとし、サブフレーム内シンボル番号を１１としたリソース１２０２を設定する。これによって、ビーム番号１のＰＵＣＣＨは、基準サブフレーム番号のサブフレームからオフセット１のサブフレームで、周期が１０サブフレームで、サブフレーム内シンボル番号が１１（シンボル＃１１）のリソース１２０２に割当てられる。
同様に、ビーム番号２のＰＵＣＣＨリソースとして、周期を１サブフレームとし、オフセットを０サブフレームとし、サブフレーム内シンボル番号を１２としたリソース１２０３を設定する。これによって、ビーム番号２のＰＵＣＣＨは、基準サブフレーム番号のサブフレームからオフセット０のサブフレームで、周期が１サブフレームで、サブフレーム内シンボル番号が１２（シンボル＃１２）のリソース１２０３に割当てられる。
同様に、ビーム番号３のＰＵＣＣＨリソースとして、周期を２サブフレームとし、オフセットを０サブフレームとし、サブフレーム内シンボル番号を１３としたリソース１２０４を設定する。これによって、ビーム番号３のＰＵＣＣＨは、基準サブフレーム番号のサブフレームからオフセット０のサブフレームで、周期が２サブフレームで、サブフレーム内シンボル番号が１３（シンボル＃１３）のリソース１２０４に割当てられる。
このように、各ビームのＰＵＣＣＨリソースが周期的に割当てられる。サブフレーム番号が無線フレーム単位である場合、および無線フレーム番号がシステムフレーム単位である場合は、周期的な設定をサブフレーム番号だけでなく、無線フレーム番号およびシステムフレーム番号を用いてリナンバリングしてもよい。
ビーム毎のＰＵＣＣＨを割当てるシンボルは、サブフレーム内の最後尾から設定してもよい。ＤＬリソースを設けるような場合、ＰＵＣＣＨを割当てるシンボルの前のシンボルをＤＬに割当てることによって、ギャップ（Ｇａｐ）の数を最小にすることができる。
ビーム毎のＰＵＣＣＨを割当てるシンボル数を１つにしたが、複数であってもよい。複数にすることによって、セルのＰＵＣＣＨの受信電力を増大させることができ、ＰＵＣＣＨの受信品質を向上させることが可能となる。また、ビーム内で多重されるＰＵＣＣＨの数を増大させることが可能となる。
ビーム切換が１ビーム毎に行われる場合について示しているが、ビーム切換が複数のビーム毎に行われる場合であってもよい。同じタイミングで複数のビームで通信可能な場合、該複数のビーム間は空間多重が可能である。したがって、同じタイミングで通信可能な複数のビーム毎のＰＵＣＣＨには同じリソースを割当てるとよい。
ビーム毎のＰＵＣＣＨリソースの他の設定方法について開示する。ビームスイープ数のＰＵＣＣＨをｋサブフレーム内に設定する。ここで、ｋは自然数である。
図１３は、ビームスイープ数のＰＵＣＣＨをｋサブフレーム内に設定する方法の一例を説明する図である。ここでは、ビームスイープ数が４個の場合について示す。一例として、ｋ＝ビームスイープ数とする。各ビームのＰＵＣＣＨを、連続するサブフレームの最後のシンボル１３０２，１３０４，１３０６，１３０８に割当て、ビームスイープ数のサブフレーム数で繰り返し割当てる。ここでは、ＰＵＣＣＨリソースに割当てるシンボルは、１サブフレーム内１シンボルとしている。ＰＵＣＣＨリソースに割当てるシンボル番号は、固定としてもよい。
シンボル１３０１，１３０３，１３０５，１３０７には、任意のビームの任意の信号あるいは無送信区間が割当てられる。ＤＬでもよいしＵＬでもよい。例えば、シンボル１３０１にはビーム番号０の下り信号が、シンボル１３０３にはビーム番号１の下り信号が、シンボル１３０５にはビーム番号２の下り信号が、シンボル１３０７にはビーム番号３の下り信号が割当てられる。
ビーム番号０のビームからビーム番号３のビームがスイープされる。ビーム番号０のＰＵＣＣＨは、サブフレーム番号ｎ、シンボル番号１３（１３０２）に割当てられる。ビーム番号１のＰＵＣＣＨは、サブフレーム番号ｎ＋１、シンボル番号１３（１３０４）に割当てられる。ビーム番号２のＰＵＣＣＨは、サブフレーム番号ｎ＋２、シンボル番号１３（１３０６）に割当てられる。ビーム番号３のＰＵＣＣＨは、サブフレーム番号ｎ＋３、シンボル番号１３（１３０８）に割当てられる。ｎは０以上の整数である。
このように、各ビームのＰＵＣＣＨがサブフレーム毎に最後のシンボル１３０２，１３０４，１３０６，１３０８に割当てられ、ビームスイープ数のサブフレーム数で繰り返し割当てられる。サブフレーム番号が無線フレーム単位である場合、および無線フレーム番号がシステムフレーム単位である場合は、繰り返し割当てられるように、サブフレーム番号だけでなく、無線フレーム番号およびシステムフレーム番号を用いてリナンバリングされてもよい。
このようにすることによって、ビームスイープ数のサブフレームで全ビームのＰＵＣＣＨを割当てることができる。したがって、ビームスイープ数のサブフレームにおいて、少なくとも一度は、各ビームのＰＵＣＣＨの送受信を行うことが可能となる。
図１４は、ビームスイープ数のＰＵＣＣＨをｋサブフレーム内に設定する方法の他の例を説明する図である。ここでは、ビームスイープ数が４個の場合について示す。一例として、ｋ＝１とする。全ビームのＰＵＣＣＨを一つのサブフレームに割当て、１サブフレームで繰り返し割当てる（１４０２〜１４０５，１４０７〜１４１０，１４１２〜１４１５，１４１７〜１４２０）。言い換えると、毎サブフレーム繰り返し割当てる。各ビームのＰＵＣＣＨリソースに割当てられるシンボルは、１サブフレーム内１シンボルとしている。ＰＵＣＣＨリソースに割当てるシンボル番号は、固定としてもよい。ここでは、１サブフレーム内の最後からビームスイープ数のシンボルを割当てることとなる。
シンボル１４０１，１４０６，１４１１，１４１６には、任意のビームの任意の信号あるいは無送信区間が割当てられる。ＤＬでもよいしＵＬでもよい。例えば、シンボル１４０１にはビーム番号０の下り信号が、シンボル１４０６にはビーム番号１の下り信号が、シンボル１４１１にはビーム番号２の下り信号が、シンボル１４１６にはビーム番号３の下り信号が割当てられる。
ビーム番号０のビームからビーム番号３のビームがスイープされる。ビーム番号０のＰＵＣＣＨは、サブフレーム番号ｎ、シンボル番号１０（１４０２，１４０７，１４１２，１４１７）に割当てられる。ビーム番号１のＰＵＣＣＨは、サブフレーム番号ｎ、シンボル番号１１（１４０３，１４０８，１４１３，１４１８）に割当てられる。ビーム番号２のＰＵＣＣＨは、サブフレーム番号ｎ、シンボル番号１２（１４０４，１４０９，１４１４，１４１９）に割当てられる。ビーム番号３のＰＵＣＣＨは、サブフレーム番号ｎ、シンボル番号１３（１４０５，１４１０，１４１５，１４２０）に割当てられる。ｎは０以上の整数である。
このように、全ビームのＰＵＣＣＨリソースが同一サブフレームの異なるシンボルに割当てられる。このようにすることによって、毎サブフレーム、全ビームのＰＵＣＣＨリソースを構成することが可能となる。例えば、ＰＵＣＣＨで送信するＳＲについては、ＳＲ周期をサブフレーム単位に設定することが可能となる。具体的には、サブフレームを１ｍｓとすると、ＳＲ周期を１ｍｓに設定することができる。これによって、ＵＥに送信データが発生してからＳＲを送信するまでの時間を短縮することができるので、データの送信開始までの遅延時間を短縮することができる。
図１５は、ビームスイープ数のＰＵＣＣＨをｋサブフレーム内に設定する方法の他の例を説明する図である。ｋ個のサブフレーム毎に、ビームスイープ数分のＰＵＣＣＨリソースを、ｋ個のサブフレーム内のサブフレームとシンボルとに個別に割当てる。このｋ個のサブフレームの割当てパターンが繰り返される。ここでは、ビームスイープ数が４個の場合について示す。一例として、ｋ＝４とする。
シンボル１５０１，１５０３，１５０５，１５０７には、任意のビームの任意の信号あるいは無送信区間が割当てられる。ＤＬでもよいしＵＬでもよい。例えば、シンボル１５０１にはビーム番号０の下り信号が、シンボル１５０３にはビーム番号１の下り信号が、シンボル１５０５にはビーム番号２の下り信号が、シンボル１５０７にはビーム番号３の下り信号が割当てられる。
ビーム番号０のビームからビーム番号３のビームがスイープされる。ビーム番号０のＰＵＣＣＨは、サブフレーム番号ｎ、シンボル番号１３（１５０２）に割当てられる。ビーム番号１のＰＵＣＣＨは、サブフレーム番号ｎ＋１、シンボル番号１３（１５０４）に割当てられる。ビーム番号２のＰＵＣＣＨは、サブフレーム番号ｎ＋２、シンボル番号１２（１５０６）に割当てられる。ビーム番号３のＰＵＣＣＨは、サブフレーム番号ｎ＋２、シンボル番号１３（１５０７）に割当てられる。サブフレーム番号ｎ＋３には、ＰＵＣＣＨは割当てられない。ｎは０以上の整数である。
このようにすることによって、ｋ個のサブフレーム内に、全ビームのＰＵＣＣＨが割当てられる。ｋを増減させることによって、ＰＵＣＣＨリソースを割当てる頻度を変更することができる。したがって、セルの負荷およびＵＥが行うサービスの種類によって、柔軟にＰＵＣＣＨを割当てるリソース量を設定することができる。
前述の例では、繰り返されるｋサブフレーム内で、一つのビームのＰＵＣＣＨが割り当てられるシンボル数を１としたが、１に限らず複数であってもよい。また、その数はビーム毎に異なってもよい。このように繰り返されるｋサブフレーム内で一つのビームのＰＵＣＣＨが割り当てられるシンボル数を、ビーム毎に異なるようにすることによって、ＰＵＣＣＨのリソースの柔軟な設定が可能となる。
前述の例では、ｋサブフレームを連続して繰り返し割当てることを開示した。他の方法として、ｋサブフレームを連続ではなく、離散的に割当てるようにしてもよいし、周期的に割当てるようにしてもよい。例えば、ＰＵＣＣＨが割り当てられるｋサブフレームを、ｍサブフレーム間隔で周期的に繰り返してもよい。言い換えると、ＰＵＣＣＨが割り当てられるｋサブフレームを、ｍ＋１サブフレーム毎に周期的に繰り返してもよい。ｍは０以上の整数である。
このようにすることによって、ＰＵＣＣＨリソースを設定するサブフレーム間に、ＰＵＣＣＨリソースを設定しないサブフレームを設けることが可能となる。例えば、ＤＬのみのサブフレームを設定することも可能となる。これによって、ＰＵＣＣＨのリソースのさらに柔軟な設定が可能となる。また、ＤＬおよびＵＬの通信遅延量の柔軟な設定、ならびに通信量の柔軟な設定を行うことが可能となる。
セルは、ビーム内に存在するＵＥ数に応じて、ＰＵＣＣＨのリソースを増減させてもよい。例えば、ビーム内に存在するＵＥの要求遅延時間に応じて、時間軸上のＰＵＣＣＨリソースを増減させてもよい。
例えば、ビームスイープ数のＰＵＣＣＨをｋサブフレーム内に設定して繰り返し割当てる方法において、ｋおよびｍを大きく設定することによって、ＰＵＣＣＨリソースが割り当てられる頻度を少なくして、他のデータおよび制御情報に割当てられるリソース量を増大させる。逆に、ｋおよびｍを小さく設定することによって、ＰＵＣＣＨリソースが割り当てられる頻度を多くして、送信開始までの遅延時間を低減させる。
繰り返されるｊ個のサブフレーム内の各サブフレームで通信が行われるビームを決めておいてもよい。ここで、ｊは自然数である。このような場合のＰＵＣＣＨの設定方法として、前述に開示した方法を適用してもよい。上りリンクのサブフレームに適用するとよい。ｋ＝ｊと設定するとよい。通信が行われるビームに設定されたサブフレームの中で、そのビームに対するＰＵＣＣＨリソースを設定するのに、前述に開示した方法を適用するとよい。
ＰＵＣＣＨリソース割当ての判断方法について開示する。セルは、ビーム毎のＰＵＣＣＨリソースの設定を行う。判断指標例として、以下の（１）〜（７）の７つを開示する。
（１）各ビームの負荷。
例えば、各ビームの負荷が高負荷の場合は、高頻度でＰＵＣＣＨリソースを割当て、各ビームの負荷が低負荷の場合は、低頻度でＰＵＣＣＨリソースを割当てる。
（２）各ビームの存在するＵＥ数。
例えば、各ビームの存在するＵＥ数が多い場合は、高頻度でＰＵＣＣＨリソースを割当て、各ビームの存在するＵＥ数が少ない場合は、低頻度でＰＵＣＣＨリソースを割当てる。
（３）各ビームに存在するＵＥの使用サービス。
例えば、高頻度に上りデータが発生するサービスのＵＥが存在する場合は、高頻度でＰＵＣＣＨリソースを割当て、低頻度で上りデータが発生するサービスのＵＥが存在する場合は、低頻度でＰＵＣＣＨリソースを割当てる。ビームに存在するＵＥのうち、最も高頻度に上りデータが発生するサービスに合わせるとよい。
（４）各ビームの傘下のＵＥのサービスの要求ＱｏＳ。
例えば、高いＱｏＳが要求されるサービスのＵＥが存在する場合は、高頻度でＰＵＣＣＨリソースを割当て、低いＱｏＳが要求されるサービスのＵＥが存在する場合は、低頻度でＰＵＣＣＨリソースを割当てる。ビームに存在するＵＥのうち、最も高い要求ＱｏＳに合わせるとよい。
（５）各ビームに存在するＵＥの要求遅延時間。
例えば、高遅延時間が要求されるサービスのＵＥが存在する場合は、低頻度でＰＵＣＣＨリソースを割当て、低遅延時間が要求されるサービスのＵＥが存在する場合は、高頻度でＰＵＣＣＨリソースを割当てる。ビームに存在するＵＥのうち、要求遅延時間が最も低いものに合わせるとよい。
（６）各ビームに存在するＵＥの要求スループット。
例えば、高スループットが要求されるサービスのＵＥが存在する場合は、高頻度でＰＵＣＣＨリソースを割当て、低スループットが要求されるサービスのＵＥが存在する場合は、低頻度でＰＵＣＣＨリソースを割当てる。ビームに存在するＵＥのうち、要求スループットが最も高いものに合わせるとよい。
（７）前記（１）〜（６）の組合せ。
ＵＥに対するＰＵＣＣＨリソースの設定方法について開示する。
セルは、ＵＥに対して、ＰＵＣＣＨリソースに関する情報を通知する。ＰＵＣＣＨリソースに関する情報例として、以下の（１）〜（１３）の１３個を開示する。
（１）ビームＩＤ。
前記（１）のビームＩＤは、どのビームのＰＵＣＣＨの設定であるかを示す。
（２）周期。
前記（２）の周期は、ＰＵＣＣＨを割当てる周期を示す。無線フレーム単位、サブフレーム単位、シンボル単位などで設定するとよい。
（３）オフセット。
前記（３）のオフセットは、ＰＵＣＣＨを割当てるオフセットを示す。無線フレーム単位、サブフレーム単位、シンボル単位などで設定するとよい。
（４）シンボル番号。
前記（４）のシンボル番号は、ＰＵＣＣＨをどのシンボルに割当てるかを示す。
（５）サブフレーム番号。
前記（５）のサブフレーム番号は、ＰＵＣＣＨをどのサブフレームに割当てるかを示す。
（６）ｋ。
前記（６）のｋは、ビーム毎のＰＵＣＣＨのリソースを何サブフレーム毎に割当てるかを示す。
（７）ｍ。
前記（７）のｍは、ビーム毎のＰＵＣＣＨの割当てが何サブフレーム毎に繰り返されるかを示す。
（８）ＵＣＩ種類。
前記（８）のＵＣＩ種類は、どのＵＣＩのＰＵＣＣＨを割当てるかを示す。
（９）周波数リソース。
前記（９）の周波数リソースは、ＰＵＣＣＨをどの周波数リソースに割当てるかを示す。
（１０）サイクリックシフト（Cyclic Shift：ＣＳ）。
前記（１０）のＣＳは、ＰＵＣＣＨに用いるＺＣシーケンスのＣＳを示す。
（１１）シーケンス番号。
前記（１１）のシーケンス番号は、ＰＵＣＣＨに用いるシーケンスのシーケンス番号を示す。
（１２）直交符号。
前記（１２）の直交符号は、ＰＵＣＣＨに直交符号を用いる場合、該直交符号を示す。
（１３）前記（１）〜（１２）の組合せ。
ＰＵＣＣＨリソースに関する情報として、ＰＵＣＣＨ用ＲＳに関する情報を含めてもよい。ＰＵＣＣＨリソースに関する情報を、該ＵＥが通信可能なビームを介して通知する。以降、ＵＥが通信可能なビームを「サービングビーム」と称する。ＰＵＣＣＨリソースに関する情報は、常に固定でなくてもよい。セルは、準静的または動的に設定して、ＵＥに通知してもよい。
これらの情報の通知を行うことによって、ＵＥは、ＰＵＣＣＨリソースに関する情報を取得する。これによって、自ＵＥのＰＵＣＣＨリソースの設定を認識することが可能となる。
セルは、ＵＥに対して、ＰＵＣＣＨリソースに関する情報を、セルのカバレッジ全体をカバーするシングルビームを用いて通知してもよい。
ビーム毎のＰＵＣＣＨリソースに関する情報と、ＵＥ毎のＰＵＣＣＨリソースに関する情報とを設けてもよい。各々、ＰＵＣＣＨに関する情報を組合せて設けてもよい。セルは、ＵＥに対して、ビーム毎のＰＵＣＣＨリソースに関する情報と、ＵＥ毎のＰＵＣＣＨリソースに関する情報とを別々に通知してもよい。ＵＥは、これらの情報を取得することによって、自ＵＥのＰＵＣＣＨリソースの設定を認識することが可能となる。
例えば、ビーム毎のＰＵＣＣＨリソースの設定方法において、ビーム毎のＰＵＣＣＨを割当てるサブフレームを周期およびオフセットで設定し、ＰＵＣＣＨを割当てるシンボルをシンボル番号で設定する場合について示す。
例えば、ビーム毎のＰＵＣＣＨリソースに関する情報を、（１）ビームＩＤ、（２）周期、（３）オフセット、（４）シンボル番号、（１０）ＣＳ、（１１）ルートシーケンス番号とする。セルは、ＵＥに対して、ビーム毎のＰＵＣＣＨリソースに関する情報を通知する。セルが構成する全ビームのビーム毎のＰＵＣＣＨリソースに関する情報を通知してもよい。このようにすることによって、ＵＥは、ビーム毎に、どのサブフレームのどのシンボルにＰＵＣＣＨリソースが設定されるかを認識することが可能となる。また、ＰＵＣＣＨに用いるＣＳおよびルートシーケンスを認識することが可能となる。
例えば、ＵＥ毎のＰＵＣＣＨリソースに関する情報を、（２）周期、（３）オフセット、（８）ＵＣＩ種類、（９）周波数リソースとする。セルは、ＵＥに対して、ＵＥ毎のＰＵＣＣＨリソースに関する情報を通知する。このようにすることによって、ＵＥは、自ＵＥのＵＣＩ種類に応じて、どのサブフレームのどのシンボルのどの周波数リソースにＰＵＣＣＨリソースを設定するかを認識することが可能となる。
セルは、ＵＥに対して、該ＵＥが存在するビームのビーム毎に設定するＰＵＣＣＨリソースの中から、ＵＥ毎のＰＵＣＣＨリソースを設定する。セルは、ＵＥに対して、設定したＵＥ毎のＰＵＣＣＨリソースに関する情報を通知する。
ＰＵＣＣＨリソースに関する情報の一部または全部について、ビーム毎とＵＥ毎とで同じにしてもよい。このような場合、セルは、ＵＥに対して、同じ設定のＰＵＣＣＨリソースに関する情報の通知を１回で行ってもよい。ビーム毎のＰＵＣＣＨリソースに関する情報から同じ設定を省略してもよい。ＵＥ毎のＰＵＣＣＨリソースに関する情報としてのみ通知すればよい。
ビーム毎のＰＵＣＣＨリソースに関する情報の通知方法について開示する。
セルは、セル毎に、ビーム毎のＰＵＣＣＨリソースを設定する。セルは、セル毎に設定したビーム毎のＰＵＣＣＨリソースに関する情報を、セルの情報として、ＵＥに通知する。セルは、ビーム毎のＰＵＣＣＨリソースに関する情報を、セルの傘下のＵＥに対して通知する。ビーム毎のＰＵＣＣＨリソースに関する情報には、ＵＥが通信を行っているビームのビーム毎のＰＵＣＣＨリソースに関する情報が含まれる。
セルは、ＵＥに対して、セル内における全ビームのビーム毎のＰＵＣＣＨリソースに関する情報を通知してもよい。あるいは、セル内における全ビームではなく、複数のビームのビーム毎のＰＵＣＣＨリソースに関する情報を通知してもよい。例えば、ＵＥが通信を行っているビームのＰＵＣＣＨリソースに関する情報と、その周辺のカバレッジを有する複数のビームのＰＵＣＣＨリソースに関する情報とを通知してもよい。これによって、ＵＥのビーム移動時に、移動先のビーム毎のＰＵＣＣＨリソースに関する情報を通知しなくて済む。
あるいは、セルは、ＵＥに対して、ＵＥが通信を行っているビームのみのビーム毎のＰＵＣＣＨリソースに関する情報を通知してもよい。これによって、１回のシグナリングの情報量を少なくすることが可能となる。あるいは、セルは、セルが決定した一つまたは複数のビームのビーム毎のＰＵＣＣＨリソースに関する情報を通知してもよい。例えば、設定を変更したビームのビーム毎のＰＵＣＣＨリソースに関する情報を通知してもよい。これによって、設定変更のたびに全ビームのビーム毎のＰＵＣＣＨリソースに関する情報を通知しなくて済む。また、セルは、ビーム毎のＰＵＣＣＨリソースに関する情報のうち、設定を変更した情報のみを通知してもよい。これによって、さらに通知する情報量を低減することができる。
セルは、ＵＥに対して、前記ビーム毎のＰＵＣＣＨリソースに関する情報を、サービングビームを介して通知する。サービングビームを介して通知する場合、サービングビームのＰＵＣＣＨリソースに関する情報に関しては、ビームＩＤを省略してもよい。サービングビームと異なるビームのＰＵＣＣＨリソースに関する情報を通知する場合は、ビームＩＤを、前記ＰＵＣＣＨリソースに関する情報に含めるとよい。このようにすることによって、ＵＥは、通信を行っているビームを介して、ビーム毎のＰＵＣＣＨリソースに関する情報を得ることが可能となる。
他の方法として、セルは、前記ＰＵＣＣＨリソースに関する情報を、セルのカバレッジ全体をカバーするシングルビームを用いて通知してもよい。これによって、セルのカバレッジ全体に前記ＰＵＣＣＨリソースに関する情報を通知することができるので、シグナリング負荷を低減させることが可能となる。
セルは、前記ＰＵＣＣＨリソースに関する情報をシステム情報に含めて通知してもよい。セルは、前記ＰＵＣＣＨリソースに関する情報を報知してもよい。あるいは、セルは、前記ＰＵＣＣＨリソースに関する情報をＵＥ個別シグナリングで通知してもよい。ＵＥ個別シグナリングで通知することによって、セルが報知する情報量を増大させることがなくなる。したがって、報知に必要となる無線リソースの増大を抑制することができる。また、ＵＥ個別シグナリングで通知することによって、ビーム毎のリソースを用いて通知することが可能となる。これによって、前記ＰＵＣＣＨリソースに関する情報を、ビーム毎に柔軟に通知することが可能となる。
ＵＥ毎のＰＵＣＣＨリソースに関する情報の通知方法について開示する。
セルは、ＰＵＣＣＨリソースに関する情報を、ＵＥ個別の情報としてＵＥに通知する。セルは、ビーム毎のＰＵＣＣＨリソースに関する情報のうちの一部あるいは全部を通知してもよい。例えば、セルは、ＵＥ個別のＰＵＣＣＨリソースに関する情報のうちの一部の設定を変更した場合、ＵＥに対して、該一部の情報のみを通知してもよい。これによって、通知する情報量を低減することができる。
セルは、前記ＰＵＣＣＨリソースに関する情報を、サービングビームを介して通知する。サービングビームを介して通知する場合、ビームＩＤを省略してもよい。セルは、前記ＰＵＣＣＨリソースに関する情報をＵＥ個別シグナリングで通知するとよい。このようにすることによって、ＵＥは、通信を行っているビームを介して、ＵＥ毎のＰＵＣＣＨリソースに関する情報を得ることが可能となる。
他の方法として、セルは、前記ＰＵＣＣＨリソースに関する情報を、セルのカバレッジ全体をカバーするシングルビームを用いて通知してもよい。これによって、セルのカバレッジ全体に前記ＰＵＣＣＨリソースに関する情報を通知することができるので、シグナリング負荷を低減させることが可能となる。
また、セルは、ＵＥに対して、ＵＥ毎に、ＵＣＩ毎のＰＵＣＣＨリソースに関する情報を通知してもよい。前述の通知方法を適用するとよい。セルは、ＵＣＩ毎のＰＵＣＣＨリソースの設定が可能となり、ＵＥは、ＵＣＩ毎に設定されたＰＵＣＣＨリソースの設定を用いて、ＵＣＩ毎のＰＵＣＣＨを送信することが可能となる。
ビーム毎のＰＵＣＣＨリソースである一つのシンボルに複数のＵＥのＰＵＣＣＨを設定する方法として、複数のＵＥ間で周波数分割多重あるいは符号分割多重を行うように設定するとよい。
図１６は、ＰＵＣＣＨの設定およびＳＲの送受信のシーケンスの一例を示す図である。図１６では、セルが、ＵＥに対して、ビーム毎のＰＵＣＣＨリソースに関する情報と、ＵＥ毎のＰＵＣＣＨリソースに関する情報とを別々に通知する場合について示している。
ステップＳＴ２５０１において、セルは、セル内における全ビームのビーム毎のＰＵＣＣＨリソース構成を設定する。
ステップＳＴ２５０２において、セルは、ＵＥに対して、ＵＥが通信するビームのビーム毎のＰＵＣＣＨリソースに関する情報を含む、ビーム毎のＰＵＣＣＨリソースに関する情報を通知する。ＵＥと通信するビームを介して通知するとよい。該情報の通知には、ＲＲＣ個別シグナリングを用いる。
ステップＳＴ２５０２でビーム毎のＰＵＣＣＨリソースに関する情報を受信したＵＥは、ステップＳＴ２５０３において、ＵＥが通信するビームであるサービングビームに対応するＰＵＣＣＨリソース構成を記憶する。ここで、ＵＥは、通知されビーム全てについて、ビーム毎のＰＵＣＣＨリソースに関する情報を記憶してもよい。
ステップＳＴ２５０４において、セルは、ＵＥ毎のＰＵＣＣＨリソース構成を設定する。
ステップＳＴ２５０５において、セルは、ＵＥに対して、ＵＥ毎のＰＵＣＣＨリソースに関する情報を通知する。該情報の通知には、ＲＲＣ個別シグナリングを用いる。
ステップＳＴ２５０５でＵＥ毎のＰＵＣＣＨリソースを受信したＵＥは、ステップＳＴ２５０６において、ビーム毎のＰＵＣＣＨリソース上でＵＥ毎のＰＵＣＣＨリソース構成を設定する。具体的には、ＵＥは、ステップＳＴ２５０６において、ビーム毎のＰＵＣＣＨリソースに関する情報と、ＵＥ毎のＰＵＣＣＨリソースに関する情報とを用いて、自ＵＥのＰＵＣＣＨリソース構成を設定する。
ステップＳＴ２５０５でＵＥ毎のＰＵＣＣＨリソースに関する情報を通知したセルは、ステップＳＴ２５０７において、ＵＥに対して設定したＵＥ毎のＰＵＣＣＨリソース構成で受信を開始する。
ステップＳＴ２５０８において、ＵＥは、上りデータが発生したか否かを判断する。ステップＳＴ２５０８において上りデータが発生していないと判断された場合は、ステップＳＴ２５０８に戻り、上りデータが発生したか否かの判断を繰り返す。ステップＳＴ２５０８において上りデータが発生していると判断された場合は、ステップＳＴ２５０９に移行する。
ステップＳＴ２５０９において、ＵＥは、設定されたＵＥ毎のＳＲ用ＰＵＣＣＨリソースでＳＲを、サービングビームを介してセルに対して送信する。
ステップＳＴ２５０７でＵＥに対して設定したＵＥ毎のＰＵＣＣＨリソースで受信を開始したセルは、ステップＳＴ２５０９において、ＵＥから送信されたＳＲを受信する。
ステップＳＴ２５１０において、セルは、受信したＳＲに従って、ＵＥに対して上りスケジューリングを開始する。
ステップＳＴ２５１１において、セルは、ＵＥに対して上りグラント、具体的には上りグラントを含む上りスケジューリング情報を送信する。
ステップＳＴ２５１１で上りグラントを受信したＵＥは、ステップＳＴ２５１２において、該上りグラントを用いて、ＢＳＲ（Buffer Status Report）をセルに送信する。このときに、上りデータを送信してもよい。
ステップＳＴ２５１２でＢＳＲを受信したセルは、ＢＳＲに従って、ＵＥに対して上りスケジューリングを行う。
ステップＳＴ２５１３において、セルは、ＵＥに対して上りグラントを送信する。ステップＳＴ２５１３で上りグラントを受信したＵＥは、ステップＳＴ２５１４において、該上りグラントを用いて、上りデータをセルに送信する。ステップＳＴ２５１４において、セルは、ＵＥから送信された上りデータを受信する。
このようにして、ＵＥとセルとの間で上り通信が開始される。
ステップＳＴ２５１２において、ＵＥは、セルに対してＢＳＲを送信したが、ＢＳＲとともに上りデータを送信してもよい。あるいは、上りデータのみを送信してもよい。これによって、少量のデータの場合、該送信のみで上りデータ送信を完了させることができ、遅延時間の短縮を図ることができる。
ビーム毎のＰＵＣＣＨリソースに関する情報を、セルがＵＥに対して通知することを開示したが、静的に規格などで予め決めておいてもよい。あるいは、ビームＩＤをインプットパラメータとして用いて、サブフレーム番号およびシンボル番号などのビーム毎のＰＵＣＣＨリソースに関する情報をアウトプットする関数を用いてもよい。このようにすることによって、セルとＵＥとの間のシグナリング負荷を低減させることが可能となる。
本実施の形態で開示した方法を用いることによって、ＭＢＦにおけるビームスイーピング運用時のＰＵＣＣＨリソースの設定が可能となる。
セルがＵＥに対して、本実施の形態で開示した方法でＰＵＣＣＨリソースの設定を行うことによって、ＵＥが通信を行っているビームでのＰＵＣＣＨの送受信が可能となり、ＵＥからセルへの上り通信が可能となる。
サブフレーム内で、ＰＵＣＣＨリソースのシンボルを送受信するビームと、該シンボルと異なるシンボルを送受信するビームとを異ならせてもよいことを開示した。１サブフレーム内の他のシンボルを送受信するビームとは異なるビームのＰＵＣＣＨが構成されるような場合、たとえ、他のシンボルが下り通信に用いられたとしても、ギャップを設けなくてもよい。
下りリンクと上りリンクとでビームが異なるので、ＵＥは、下り信号の受信と上り信号の送信とを連続して行うことは無い。したがって、ＵＥで受信と送信とが重なることはなく、ギャップは不要となる。
セルは、ギャップ構成を設定してＵＥに通知してもよい。ギャップ設定についても、ＰＵＣＣＨリソースに関する情報に含めてもよい。セルは、他のＰＵＣＣＨリソースに関する情報とともに、ＵＥに対して通知してもよい。
セルがギャップ構成を設定して、ＵＥに対して通知できるようにしておくことによって、例えば、１サブフレーム内の下りリンクに用いられるシンボルと上りリンクに用いられるシンボルとで異なるビームが用いられるような場合に、下りリンクから上りリンクの間にギャップを設けないように設定することが可能となる。
このようにすることによって、従来必要であったギャップを、下り通信あるいは上り通信に使用することが可能となる。したがって、無線リソースの使用効率を向上させることが可能となる。
ビームをシンボル毎に切換える場合、送受信機においてビーム切換えに時間を要し、その期間は正常に送受信できない場合がある。したがって、ビーム切換え期間の設定が必要となる。ビーム切換え期間は、静的に規格などで決めておくとよい。セルとＵＥとで送受信できない期間を認識することが可能となる。ビーム切換期間をＣＰ長内と決めてもよい。１シンボルで送るデータに影響を及ぼさずにビーム切換を行うことができる。
実施の形態２ 変形例１．
本実施の形態では、実施の形態２で述べた問題を解決する他の方法を開示する。実施の形態２では、ＰＵＣＣＨリソースをビーム毎に予め決めておき、ビーム毎のＰＵＣＣＨリソースの中で、ＵＥ毎のＰＵＣＣＨリソースを設定することを開示した。しかし、ＵＥ毎に通信するサービスによって、必要となるＰＵＣＣＨの設定周期が異なるので、ビーム毎に設定したＰＵＣＣＨリソースの中で使用しないリソースも発生する。したがって、無線リソースの使用効率が低下してしまうという問題が生じる。
本変形例では、このような問題を解決する方法を開示する。
ＰＵＣＣＨリソースをＵＥ毎に設定する。ビーム毎のＰＵＣＣＨリソースを設定せず、ＵＥ毎にＰＵＣＣＨリソースを設定する。ＰＵＣＣＨリソースを動的に設定してもよい。ＵＥ毎に、動的にＰＵＣＣＨリソースを設定することによって、ＵＥの接続状態に応じて、適時にＰＵＣＣＨリソースを設定することが可能となる。また、実施の形態２で開示した方法におけるビーム毎に設定したＰＵＣＣＨリソースの中で使用しないリソースが発生することによるリソースの使用効率の低減を抑制できる。
ＵＥに対するＰＵＣＣＨリソースの設定方法について開示する。
セルは、ＵＥに対して、ＵＥ毎に設定するＰＵＣＣＨリソースに関する情報を通知して、ＰＵＣＣＨリソースを設定する。ＰＵＣＣＨリソースに関する情報例は、実施の形態２で開示したものを適用すればよい。本変形例における設定例を開示する。ＵＥ毎のＰＵＣＣＨを割当てるサブフレームを周期およびオフセットで設定し、ＰＵＣＣＨを割当てるシンボルをシンボル番号で設定する。
サブフレーム周期を１つまたは複数の予め定める値としてもよい。サブフレーム周期とオフセットとの組合せを示すインデックスを設け、インデックスで設定してもよい。シンボルの割当ては、シンボル番号で行うとよい。あるいは、シンボルの割当ては、サブフレーム内で設定されるシンボル番号で行うとよい。例えば、サブフレーム周期を１０、オフセットを４、シンボル番号を１３と設定する。この場合、５番目のサブフレームから１０サブフレーム毎のサブフレームのシンボル番号が１３のシンボルにＰＵＣＣＨを割当てる。
サブフレームに割当てられるＰＵＣＣＨ用リソースの最大シンボル数を決めて、シンボル番号を最大シンボル数でリナンバリングして設定してもよい。これによって、シンボル番号を表す情報量、例えばビット数を削減することができる。
また、セルは、ＵＥに対して、ＰＵＣＣＨの周波数リソース、ＣＳ、シーケンス番号を設定する。ＵＥは、これらの情報に従って、前述のＰＵＣＣＨを割当てるタイミングのシンボルでＰＵＣＣＨを構成する。
セルは、サービングビームが異なるＵＥに対して、ＵＥ毎にＰＵＣＣＨリソースを設定するときに、それらのＵＥに対するＰＵＣＣＨリソースの設定タイミングが同一にならないように設定する。ＰＵＣＣＨリソースにシンボルを割当てる場合、同一サブフレームの同一シンボルにならないように設定するとよい。
セルは、該情報を、サービングビームを介して通知する。サービングビームを介して通知する場合、ビームＩＤを省略してもよい。セルは、該情報をＵＥ個別シグナリングで通知するとよい。このようにすることによって、ＵＥは、通信を行っているビームを介して、ＵＥ毎のＰＵＣＣＨリソースに関する情報を得ることが可能となる。
ＵＥ個別シグナリングとして、ＲＲＣシグナリングを用いてもよい。ＵＥ毎のＰＵＣＣＨリソースに関する情報を、ＲＲＣメッセージに含めるとよい。あるいは、ＵＥ個別シグナリングとして、Ｌ１／Ｌ２制御シグナリングを用いてもよい。ＵＥ毎のＰＵＣＣＨリソースに関する情報を、下りＬ１／Ｌ２制御情報（下り制御情報であってもよい）に含めるとよい。ＵＥ個別シグナリングとしてＬ１／Ｌ２制御シグナリングを用いることによって、ＵＥは、比較的早期に設定を受信することが可能となるので、設定遅延時間の低減が可能となる。
あるいは、ＵＥ個別シグナリングとして、ＭＡＣシグナリングを用いてもよい。ＵＥ毎のＰＵＣＣＨリソースに関する情報を、ＭＡＣ制御情報に含めるとよい。ＵＥ個別シグナリングとして、ＭＡＣシグナリングを用いることによって、ＨＡＲＱが適用されるので、ＵＥは、低い受信誤り率で受信することが可能となるとともに、比較的早期に設定を受信することが可能となる。
図１７は、ＵＥ毎のＰＵＣＣＨの設定およびＳＲの送受信のシーケンスの一例を示す図である。図１７に示すシーケンスは、図１６に示すシーケンスと同一のステップを含んでいるので、同一のステップについては同一のステップ番号を付して、共通する説明を省略する。図１７では、セルが、ＵＥに対して、ＵＥ毎に設定するＰＵＣＣＨリソースに関する情報を通知する場合について示している。
ステップＳＴ２６０１において、セルは、ＵＥに対して、ＵＥ毎のＰＵＣＣＨリソース構成を設定する。セルは、ＵＥに対して、ＰＵＣＣＨを割当てるシンボル番号まで設定する。このとき、セルは、サービングビームが異なるＵＥに対して、ＰＵＣＣＨリソースタイミングが同一にならないように設定する。
ステップＳＴ２６０２において、セルは、ＵＥに対して、ＵＥ毎のＰＵＣＣＨリソースに関する情報を通知する。ＰＵＣＣＨリソースに関する情報に、ＰＵＣＣＨを割当てるシンボル番号（シンボル＃）を含ませる。ＵＥと通信するビームを介して通知するとよい。該情報の通知には、ＲＲＣ個別シグナリングを用いる。
ステップＳＴ２６０２でＵＥ毎のＰＵＣＣＨリソースに関する情報を受信したＵＥは、ステップＳＴ２６０３において、ＰＵＣＣＨリソース構成を設定する。
ステップＳＴ２６０２でＵＥに対してＰＵＣＣＨリソースに関する情報を通知したセルは、ステップＳＴ２６０４において、ＵＥに対して設定したＰＵＣＣＨリソース構成で受信を開始する。
ステップＳＴ２６０５において、ＵＥは、上りデータが発生したか否かを判断する。ステップＳＴ２６０５で上りデータが発生していない場合は、ステップＳＴ２６０５に戻り、上りデータが発生したか否かの判断を繰り返す。ステップＳＴ２６０５で上りデータが発生している場合は、ステップＳＴ２６０６に移行する。
ステップＳＴ２６０６において、ＵＥは、設定されたＳＲ用ＰＵＣＣＨリソースで、ＳＲを、サービングビームを介してセルに対して送信する。
ステップＳＴ２６０４でＵＥに対して設定したＰＵＣＣＨリソースで受信を開始したセルは、ステップＳＴ２６０６において、ＵＥから送信されたＳＲを受信する。
このようにしてＵＥからＳＲを受信したセルは、上り通信開始のための処理を行う。これによって、ＵＥとセルとの間で上り通信が開始される。
本変形例で開示した方法を用いることによって、ＭＢＦにおけるビームスイーピング運用時のＰＵＣＣＨリソースの設定が可能となる。セルがＵＥに対して、本実施の形態で開示した方法でＰＵＣＣＨリソースの設定を行うことによって、ＵＥが通信を行っているビームでのＰＵＣＣＨの送受信が可能となり、ＵＥからセルへの上り通信が可能となる。
また、ＵＥ毎に、動的にＰＵＣＣＨリソースを設定することによって、ＵＥの接続状態に応じて、ＰＵＣＣＨリソースを設定することが可能となる。また、実施の形態２で開示した方法におけるビーム毎に設定したＰＵＣＣＨリソースの中で使用しないリソースが発生することによるリソースの使用効率の低減を抑制することができる。
セルは、ＰＵＣＣＨリソースに関する情報を、サービングビームを介して通知することを開示したが、他の方法として、セルは、該情報を、セルのカバレッジ全体をカバーするシングルビームを用いて通知してもよい。これによって、セルのカバレッジ全体に前記ＰＵＣＣＨリソースに関する情報を通知できるので、シグナリング負荷を低減させることが可能となる。
また、セルはＵＥに対して、ＵＥ毎に、ＵＣＩ毎のＰＵＣＣＨリソースに関する情報を通知してもよい。前述の通知方法を適用するとよい。セルは、ＵＣＩ毎のＰＵＣＣＨリソースの設定が可能となり、ＵＥは、ＵＣＩ毎に設定されたＰＵＣＣＨリソースの設定を用いて、ＵＣＩ毎のＰＵＣＣＨを送信することが可能となる。
本変形例における他の設定例を開示する。ＵＥ毎にＰＵＣＣＨリソースの設定の開始、修正、停止に関する情報を設定する。セルは、ＵＥに対して、予めＵＥ毎のＰＵＣＣＨリソースに関する情報を通知する。セルは、ＵＥに対して、ＰＵＣＣＨリソース設定の開始、修正、停止に関する情報を通知することによって、該ＰＵＣＣＨリソースを設定する。ＵＥは、該設定の受信によって、実際にＰＵＣＣＨの送信、修正後送信、停止を実行する。
ＰＵＣＣＨリソース設定の開始、修正、停止に関する情報例として、以下の（１）〜（８）の８つを示す。
（１）開始を示す情報。
（２）停止を示す情報。
（３）修正を示す情報。
（４）設定期間を示す情報。
（５）停止期間を示す情報。
（６）オフセットを示す情報。
（７）シンボル番号。
（８）前記（１）〜（７）の組合せ。
前記（１）は、開始を示す情報であり、ＵＥは、該情報が設定された場合に、予め設定されたＰＵＣＣＨリソースでのＰＵＣＣＨ送信を可能とする。
前記（２）は、停止を示す情報であり、ＵＥは、該情報が設定された場合に、予め設定されたＰＵＣＣＨリソースでのＰＵＣＣＨ送信を停止する。
前記（３）は、修正を示す情報であり、ＵＥは、該情報が設定された場合に、ＰＵＣＣＨリソースを修正設定したリソースでＰＵＣＣＨ送信を可能とする。修正するＰＵＣＣＨリソース情報を併せて通知するとよい。
前記（４）は、設定期間を示す情報であり、ＵＥは、該情報が設定された場合に、設定開始から該設定期間、ＰＵＣＣＨリソースでのＰＵＣＣＨ送信を可能とする。該設定期間の満了で設定停止とするとよい。
前記（５）は、停止期間を示す情報であり、ＵＥは、該情報が設定された場合に、設定停止から該停止期間、ＰＵＣＣＨリソースでのＰＵＣＣＨ送信を停止する。該停止期間の満了で設定開始とするとよい。
前記（６）は、オフセットを示す情報であり、ＵＥは、該情報が設定された場合に、設定開始などのタイミングから該オフセット値だけオフセットして設定開始などを行う。
前記（７）は、ＰＵＣＣＨを割当てるシンボル番号であり、ＵＥは、該情報が設定された場合に、該シンボル番号にＰＵＣＣＨリソースを設定する。ＵＥに対して予め設定するＰＵＣＣＨリソースにシンボル番号が含まれている場合は、新たに設定されたシンボル番号に従う。
図１８は、ＵＥ毎にＰＵＣＣＨリソース設定の開始、修正、停止に関する情報を設定する方法の一例を説明する図である。ここでは、ビームスイープ数が４個の場合について示す。図１８において、横軸はサブフレームを示し、縦軸はサブフレーム内のシンボル番号を示している。図１８では、ＰＵＣＣＨが割当てられるシンボル数を１サブフレームに最大４つと設定した場合について示す。この場合、サブフレーム内のシンボル番号を０から３でリナンバリングする。
ここでは、シンボル番号１０がシンボル番号０に対応し、シンボル番号１１がシンボル番号１に対応し、シンボル番号１２がシンボル番号２に対応し、シンボル番号１３がシンボル番号３に対応する。１サブフレームのＰＵＣＣＨを割当てる最大シンボル数、サブフレーム内のシンボル番号とリナンバリング後のシンボル番号との対応関係を、予めセルからＵＥに対して通知しておくとよい。また、予め通知するＵＥ毎のＰＵＣＣＨリソースに関する情報に含めてもよい。ＵＥは、該情報を用いて、ＰＵＣＣＨを割当てるシンボル番号を認識することができる。
図１８において、矢符はセルからＵＥへ通知する情報を示している。セルは、予めＵＥ１、ＵＥ２、ＵＥ３、ＵＥ４に対して、ＵＥ毎のＰＵＣＣＨリソースに関する情報を通知しておく。セルは、ＵＥ２に対して、ＰＵＣＣＨリソースの設定開始を決定した場合、ＵＥ２に対して、ＰＵＣＣＨを割当てるシンボル番号とともに、ＰＵＣＣＨ設定開始を示す情報（Ｓｔｒ＿ＵＥ＃２（シンボル＃３））を通知する。ここでは、シンボル番号を３とする。これによって、ＵＥ２に対して、ＰＵＣＣＨリソースが設定される。
セルは、ＵＥ３に対して、ＰＵＣＣＨリソースの設定開始を決定した場合、ＵＥ３に対して、ＰＵＣＣＨを割当てるシンボル番号とともに、ＰＵＣＣＨ設定開始を示す情報（Ｓｔｒ＿ＵＥ＃３（シンボル＃２））を通知する。ここでは、シンボル番号を２とする。これによって、ＵＥ３に対して、ＰＵＣＣＨリソースが設定される。
セルは、ＵＥ１に対して、ＰＵＣＣＨリソースの設定開始を決定した場合、ＵＥ１に対して、ＰＵＣＣＨを割当てるシンボル番号とともに、ＰＵＣＣＨ設定開始を示す情報（Ｓｔｒ＿ＵＥ＃１（シンボル＃３））を通知する。ここでは、シンボル番号を３とする。これによって、ＵＥ１に対して、ＰＵＣＣＨリソースが設定される。
セルは、ＵＥ２に対して設定したＰＵＣＣＨリソースと、ＵＥ１に対して設定したＰＵＣＣＨリソースとが衝突すると判断した場合、ＰＵＣＣＨリソースの設定修正を決定し、ＵＥに通知する。ここでは、セルは、ＵＥ２に対して、修正後に割当てるシンボル番号とともに、ＰＵＣＣＨリソース設定修正を示す情報（Ｍｏｄ＿ＵＥ＃２（シンボル＃２））を通知する。ここでは、シンボル番号を２とする。これによって、ＵＥ２に対して、ＰＵＣＣＨリソース設定が修正される。
セルは、ＵＥ３に対して設定したＰＵＣＣＨリソースと、ＵＥ２に対して設定したＰＵＣＣＨリソースとが衝突すると判断した場合、ＰＵＣＣＨリソースの設定修正を決定し、ＵＥに通知する。ここでは、セルは、ＵＥ３に対して、修正後に割当てるシンボル番号とともに、ＰＵＣＣＨリソース設定修正を示す情報（Ｍｏｄ＿ＵＥ＃３（シンボル＃１））を通知する。ここでは、シンボル番号を１とする。これによって、ＵＥ３に対して、ＰＵＣＣＨリソース設定が修正される。
セルは、ＵＥ４に対してＰＵＣＣＨリソースの設定開始を決定した場合、ＵＥ４に対して、ＰＵＣＣＨを割当てるシンボル番号とともに、ＰＵＣＣＨ設定開始を示す情報（Ｓｔｒ＿ＵＥ＃４（シンボル＃２））を通知する。ここでは、シンボル番号を２とする。これによって、ＵＥ４に対して、ＰＵＣＣＨリソースが設定される。
セルは、ＵＥ２に対してＰＵＣＣＨリソースの設定停止を決定した場合、ＵＥ２に対して、ＰＵＣＣＨ設定停止を示す情報（Ｓｔｐ＿ＵＥ＃２）を通知する。これによって、ＵＥ２に対して設定されたＰＵＣＣＨリソースは解放される。
セルは、ＵＥ２に対して設定したＰＵＣＣＨリソースを解放したので、ＵＥ３に対して設定したＰＵＣＣＨリソースの衝突は生じないと判断し、ＰＵＣＣＨリソースの設定修正を決定し、ＵＥ３に通知する。ここでは、セルは、ＵＥ３に対して、修正後に割当てるシンボル番号とともに、ＰＵＣＣＨリソース設定修正を示す情報（Ｍｏｄ＿ＵＥ＃３（シンボル＃２））を通知する。ここでは、シンボル番号を２とする。これによって、ＵＥ３に対して、ＰＵＣＣＨリソース設定が修正される。
セルは、ＵＥ１に対してＰＵＣＣＨリソースの設定停止を決定した場合、ＵＥ１に対して、ＰＵＣＣＨ設定停止を示す情報（Ｓｔｐ＿ＵＥ＃１）を通知する。これによって、ＵＥ１に対して設定されたＰＵＣＣＨリソースは解放される。
セルは、ＵＥ１に対して設定したＰＵＣＣＨリソースを解放したので、ＵＥ４に対して設定したＰＵＣＣＨリソースの衝突は生じないと判断し、ＰＵＣＣＨリソースの設定修正を決定し、ＵＥ４に通知する。ここでは、セルは、ＵＥ４に対して、修正後に割当てるシンボル番号とともに、ＰＵＣＣＨリソース設定修正を示す情報（Ｍｏｄ＿ＵＥ＃４（シンボル＃３））を通知する。ここでは、シンボル番号を３とする。これによって、ＵＥ４に対して、ＰＵＣＣＨリソース設定が修正される。
セルは、ＵＥ１に対して設定したＰＵＣＣＨリソースを修正したので、ＵＥ４に対して設定したＰＵＣＣＨリソースの衝突は生じないと判断し、ＰＵＣＣＨリソースの設定修正を決定し、ＵＥ３に通知する。ここでは、セルは、ＵＥ３に対して、修正後に割当てるシンボル番号とともに、ＰＵＣＣＨリソース設定修正を示す情報（Ｍｏｄ＿ＵＥ＃３（シンボル＃３））を通知する。ここでは、シンボル番号を３とする。これによって、ＵＥ３に対して、ＰＵＣＣＨリソース設定が修正される。
このようにすることによって、セルは、異なるビームで通信を行うＵＥ毎に、異なるリソースを、該ＵＥのＰＵＣＣＨに割当てることが可能となる。したがって、ビームスイープが必要なセルにおいて、異なるビームで通信を行うＵＥ毎にビームを切り替えて、該ＵＥのＰＵＣＣＨを受信することが可能となる。
また、このようにすることによって、動的に、異なるビームで通信を行うＵＥ毎に、異なるリソースを、該ＵＥのＰＵＣＣＨに割当てることが可能となる。ＰＵＣＣＨリソースを設定不要のときは、ＰＵＣＣＨリソースの設定停止として、他のビームのＵＥに対して解放できる。実施の形態２で開示した方法のように、ビーム毎のＰＵＣＣＨリソースを予め設定しておく必要が無くなる。したがって、無線リソースの使用効率が低下することを抑制することが可能となる。
ＰＵＣＣＨリソース設定の開始、修正、停止に関する情報の通知方法について開示する。セルは、ＵＥに対して、ＰＵＣＣＨリソース設定の開始、修正、停止に関する情報を通知する。セルは、該情報を、サービングビームを介して通知する。サービングビームを介して通知する場合、ビームＩＤを省略してもよい。セルは、該情報をＵＥ個別シグナリングで通知するとよい。このようにすることによって、ＵＥは、通信を行っているビームを介して、ＵＥ毎のＰＵＣＣＨリソース設定の開始、修正、停止に関する情報を得ることが可能となる。
ＵＥ個別シグナリングとして、ＲＲＣシグナリングを用いてもよい。ＰＵＣＣＨリソース設定の開始、修正、停止に関する情報を、ＲＲＣメッセージに含めるとよい。あるいは、ＵＥ個別シグナリングとして、Ｌ１／Ｌ２制御シグナリングを用いてもよい。ＰＵＣＣＨリソース設定の開始、修正、停止に関する情報を、下りＬ１／Ｌ２制御情報に含めるとよい。ＵＥ個別シグナリングとしてＬ１／Ｌ２制御シグナリングを用いることによって、ＵＥは、比較的早期に設定を受信することが可能となるので、設定遅延時間の低減が可能となる。
あるいは、ＵＥ個別シグナリングとして、ＭＡＣシグナリングを用いてもよい。ＰＵＣＣＨリソース設定の開始、修正、停止に関する情報を、ＭＡＣ制御情報に含めるとよい。ＵＥ個別シグナリングとして、ＭＡＣシグナリングを用いることによって、ＨＡＲＱが適用されるので、ＵＥは、低い受信誤り率で受信することが可能となるとともに、比較的早期に設定を受信することが可能となる。
ＰＵＣＣＨリソースに関する情報と、ＰＵＣＣＨリソース設定の開始、修正、停止に関する情報との通知方法の一例を開示する。ＰＵＣＣＨリソースに関する情報をＲＲＣシグナリングで通知し、ＰＵＣＣＨリソースの設定開始、修正、停止に関する情報をＲＲＣシグナリングで通知する。ＲＲＣシグナリングを用いるので、多くの情報を通知できるとともに、低い受信誤り率で通知することが可能となる。
通知方法の他の例を開示する。
ＰＵＣＣＨリソースに関する情報をＲＲＣシグナリングで通知し、ＰＵＣＣＨリソースの設定開始、修正、停止に関する情報をＬ１／Ｌ２制御シグナリングで通知する。ＰＵＣＣＨリソースの設定開始、修正、停止に関する情報をＬ１／Ｌ２制御シグナリングで通知するので、ＵＥにおける該設定開始、修正、停止を早期に実行することが可能となる。動的に設定開始、修正、停止を早期に実行可能とすることによって、無線リソースの使用効率を向上させることが可能となる。
通知方法のさらに他の例を開示する。
ＰＵＣＣＨリソースに関する情報をＲＲＣシグナリングで通知し、ＰＵＣＣＨリソースの設定開始、修正、停止に関する情報をＭＡＣシグナリングで通知する。ＰＵＣＣＨリソースの設定開始、修正、停止に関する情報をＭＡＣシグナリングで通知するので、低誤り率で通知することが可能となる。また、ＵＥにおける該設定開始、修正、停止を比較的早期に実行することが可能となる。動的に設定開始、修正、停止を比較的早期に確実に実行可能とすることによって、無線リソースの使用効率を向上させることが可能となる。
セルは、ＰＵＣＣＨリソースに関する情報、およびＰＵＣＣＨリソース設定の開始、修正、停止に関する情報を、サービングビームを介して通知することを開示したが、他の方法として、セルは、前記ＰＵＣＣＨリソースに関する情報、およびＰＵＣＣＨリソース設定の開始、修正、停止に関する情報の少なくとも一方を、セルのカバレッジ全体をカバーするシングルビームを用いて通知してもよい。これによって、セルのカバレッジ全体に、前記ＰＵＣＣＨリソースに関する情報、およびＰＵＣＣＨリソース設定の開始、修正、停止に関する情報の少なくとも一方を通知することができるので、シグナリング負荷を低減させることが可能となる。
また、セルはＵＥに対して、ＵＥ毎に、ＵＣＩ毎のＰＵＣＣＨリソースに関する情報を通知してもよい。前述の通知方法を適用するとよい。セルは、ＵＣＩ毎のＰＵＣＣＨリソースの設定が可能となり、ＵＥは、ＵＣＩ毎に設定されたＰＵＣＣＨリソースの設定を用いて、ＵＣＩ毎のＰＵＣＣＨを送信することが可能となる。
ＰＵＣＣＨに割当てるシンボル番号に優先順位を設けてもよい。ＰＵＣＣＨリソースのためのシンボル番号の設定に優先順位を設けてもよい。１サブフレーム内の最後尾のシンボルの優先順位を最も高くして、それから順に、前方のシンボルに対する優先順位を低くする。例えば、１サブフレームが、シンボル番号０〜シンボル番号１３の１４シンボルで構成される場合、シンボル番号１３の優先順位が最も高く、それから順に、シンボル番号１２、シンボル番号１１、とシンボル番号が小さくなるに従って優先順位が低くなる。
優先順位の高いシンボルからＰＵＣＣＨに割当てる。例えば、最初のＰＵＣＣＨリソースの設定開始では、最も高いシンボルに割当てる。より高いシンボルへのＰＵＣＣＨリソースの設定が停止によって解放された場合、次の優先順位のシンボルに設定していたＰＵＣＣＨリソース設定を、解放された、より高いシンボルに修正するとよい。
このようにすることによって、優先順位に従って、柔軟に設定を修正することが可能となる。また、後尾のシンボルをＰＵＣＣＨリソースとして、優先して使用することによって、ＰＵＣＣＨリソースより前方のシンボルをまとめて他のＤＬ用およびＵＬ用の少なくとも一方に用いることが可能となる。また、ギャップ数も少なくすることが可能となる。
また、ＰＵＣＣＨリソースの設定周期の長さが短い順に、後尾のシンボルから割当ててもよい。例えば、最初のＰＵＣＣＨリソースの設定開始では、最も高いシンボルに割当てる。次のＰＵＣＣＨリソースの設定の周期が、最初のＰＵＣＣＨリソース設定の周期より短い場合は、最初のＰＵＣＣＨリソース設定を次の優先順位のシンボルに修正し、次のＰＵＣＣＨリソース設定を最も高い優先順位のシンボルに設定する。
このようにすることによって、さらに、ＰＵＣＣＨリソースより前方のシンボル数がまとまって発生する回数を大きくすることができる。
本変形例では、ＵＥ毎に、動的にＰＵＣＣＨリソースを設定することを開示したが、セルからＵＥへのＰＵＣＣＨリソースに関する情報、およびＰＵＣＣＨリソース設定開始、修正、停止に関する情報の通知タイミングが問題となる。
１サブフレーム内の他のシンボルを送受信するビームとは異なるビームのＰＵＣＣＨを構成してもよいことを開示した。この場合、予め定めるビームにおいて、ＰＵＣＣＨが設定されるサブフレームで常に下りリソースが存在するとは限らない。したがって、セルは、ＵＥに対して、ＵＥ毎のＰＵＣＣＨリソース設定サブフレームで、該情報を通知することはできない場合が生じる。
このような問題を解決する方法を開示する。
セルは、ＵＥに対して、ＵＥ毎のＰＵＣＣＨリソース設定サブフレーム以前のタイミングで通知する。セルは、ＵＥ毎のＰＵＣＣＨリソース設定サブフレーム以前のタイミングで、設定するＵＥが存在するビームでの送受信を行い、該送受信において、該情報のシグナリングを完了させるとよい。
ＵＥは、ＰＵＣＣＨリソース設定サブフレームは既に通知されているので、セルからＵＥ毎のＰＵＣＣＨリソース設定サブフレーム以前のタイミングで通知された場合、該通知以降のＰＵＣＣＨリソース設定サブフレームで該通知された情報を適用すればよい。
セルは、ＵＥに対して、ＵＥ毎のＰＵＣＣＨリソース設定サブフレーム以前のタイミングで通知する場合、設定を適用させるタイミングを併せて通知してもよい。オフセットとして通知してもよい。例えば、通知以降、何回目のＰＵＣＣＨリソース設定サブフレームから該設定を適用させるかを通知してもよい。このようにすることによって、時間的に柔軟に設定することが可能となる。
図１９は、ＵＥ毎のＰＵＣＣＨの設定およびＳＲの送受信のシーケンスの一例を示す図である。図１９に示すシーケンスは、図１６に示すシーケンスと同一のステップを含んでいるので、同一のステップについては同一のステップ番号を付して、共通する説明を省略する。図１９では、セルが、ＵＥに対して、ＵＥ毎のＰＵＣＣＨリソースに関する情報と、ＵＥ毎のＰＵＣＣＨリソース設定開始、修正、停止に関する情報とを別々に通知する場合について示している。
ステップＳＴ２８０１において、セルは、ＵＥに対して、ＵＥ毎のＰＵＣＣＨリソース構成を設定する。
ステップＳＴ２８０２において、セルは、ＵＥに対して、ＵＥ毎のＰＵＣＣＨリソースに関する情報を通知する。セルは、ＵＥと通信するビームを介して、ＵＥ毎のＰＵＣＣＨリソースに関する情報を通知するとよい。該情報の通知には、ＲＲＣ個別シグナリングを用いる。
ステップＳＴ２８０２でＵＥ毎のＰＵＣＣＨリソースに関する情報を受信したＵＥは、ステップＳＴ２８０３において、該ＰＵＣＣＨリソース構成を記憶する。
ステップＳＴ２８０４において、セルは、ＵＥに対して、ＰＵＣＣＨリソース設定開始を決定する。本実施の形態では、セルは、ＵＥに対してＰＵＣＣＨリソース設定開始を決定するとともに、ＵＥに対して割当てるシンボルを決定する。このとき、セルは、サービングビームが異なるＵＥに対して、ＰＵＣＣＨリソースタイミングが同一にならないように設定する。
ステップＳＴ２８０５において、セルは、ＵＥに対して、ＰＵＣＣＨリソース設定開始情報を通知する。また、ＰＵＣＣＨリソースとして割当てるシンボル番号情報を通知する。セルは、これらの情報を下りＬ１／Ｌ２制御情報に含めて、下りＬ１／Ｌ２制御シグナリングで、ＵＥに対して通知する。
ステップＳＴ２８０５でＰＵＣＣＨリソース設定開始情報を受信したＵＥは、ステップＳＴ２８１３において、ステップＳＴ２８０３で記憶したＵＥ毎のＰＵＣＣＨリソースに関する情報と、ステップＳＴ２８０５で受信したシンボル番号とを用いて、自ＵＥのＰＵＣＣＨリソース構成を設定する。
ステップＳＴ２８０５でＵＥに対してＰＵＣＣＨリソース設定開始情報とシンボル番号情報とを通知したセルは、ステップＳＴ２８０６において、ＵＥに対して設定したＰＵＣＣＨリソース構成で受信を開始する。
ＵＥは、上り信号の送信が発生した場合、このＰＵＣＣＨリソース設定でＳＲを送信することになる。しかし、図１９の例では、この状態ではＵＥに上りデータが発生しなかったとする。
ステップＳＴ２８０７において、セルは、ＵＥに対して、ＰＵＣＣＨリソース設定修正と修正後に割当てるシンボルとを決定する。このとき、セルは、サービングビームが異なるＵＥに対して、ＰＵＣＣＨリソースタイミングが同一にならないように設定する。また、前述のＰＵＣＣＨに割当てるシンボル番号の優先順位に従って設定してもよい。
ステップＳＴ２８０８において、セルは、ＵＥに対して、ＰＵＣＣＨリソース設定修正情報を通知する。また、ＰＵＣＣＨリソースとして修正後に割当てるシンボル番号情報を通知する。セルは、これらの情報を下りＬ１／Ｌ２制御情報に含めて、下りＬ１／Ｌ２制御シグナリングで、ＵＥに対して通知する。Ｌ１／Ｌ２制御シグナリングで通知することによって、可能な限り設定時間の削減を図ることができる。
ステップＳＴ２８０８でＰＵＣＣＨリソース設定修正情報とシンボル番号とを受信したＵＥは、ステップＳＴ２８０９において、自ＵＥのＰＵＣＣＨリソース設定を修正する。
ステップＳＴ２８０８でＵＥに対してＰＵＣＣＨリソース設定修正情報とシンボル番号情報とを通知したセルは、ステップＳＴ２８１０において、ＵＥに対して修正したＰＵＣＣＨリソース構成で受信を開始する。
ステップＳＴ２８１１において、ＵＥは、上りデータが発生したか否かを判断する。ステップＳＴ２８１１で上りデータが発生していない場合は、ステップＳＴ２８１１に戻り、上りデータが発生したか否かの判断を繰り返す。ステップＳＴ２８１１で上りデータが発生している場合は、ステップＳＴ２８１２に移行する。
ステップＳＴ２８１２において、ＵＥは、修正されたＳＲ用ＰＵＣＣＨリソース構成で、ＳＲを、サービングビームを介してセルに対して送信する。
ステップＳＴ２８１０でＵＥに対して修正したＰＵＣＣＨリソースで受信を開始したセルは、ステップＳＴ２８１２において、ＵＥから送信されたＳＲを受信する。
このようにしてＵＥからＳＲを受信したセルは、上り通信開始のための処理を行う。これによって、ＵＥとセルとの間で上り通信が開始される。
このような方法を用いることによって、先に示した例と同様の効果を得ることが可能となる。
また、予めＵＥに対してＰＵＣＣＨリソースを設定しておき、適宜ＰＵＣＣＨリソース設定開始、修正、停止を通知することによって、ＵＥの接続状態に応じて、より早期にＰＵＣＣＨリソースを設定することが可能となる。これによって、さらにリソースの使用効率の低減を抑制することができる。
実施の形態２ 変形例２．
実施の形態２の変形例１では、ＵＥに対してＵＥ毎のＰＵＣＣＨリソースの設定を行うことによって、無線リソースの使用効率を向上させることを開示した。しかし、周期的にＰＵＣＣＨリソースを設定すると、該タイミングでは、常にＰＵＣＣＨリソースが設定されたビームで通信を行わなくてはならない。他のビームで低遅延を要する通信があるような場合は、ＰＵＣＣＨリソースが設定されたビームで通信を行うことはできないという問題が生じる。
本変形例では、このような問題を解決する方法を開示する。
セルは、ＵＥに対して、ＵＥが通信するビームのＤＬリソースを構成するサブフレームと同一のサブフレームにＰＵＣＣＨリソースを設定する。ＵＥは、サービングビームの下り信号の送信が行われるサブフレームと同一のサブフレームでＰＵＣＣＨを送信する。ＮＲでは、同一のサブフレーム内でＤＬリソースとＵＬリソースとが構成される自己完結型サブフレーム（self-contained subframe）が提案されている。本変形例では、この自己完結型サブフレームを用いてもよい。
セルは、ＵＥに対して、ＵＥが通信するビームのＤＬリソースを構成するサブフレームと同一のサブフレームで、同じサブフレームでのＰＵＣＣＨ送信可否を通知する。セルは、ＵＥに対して、ＰＵＣＣＨ送信が必要なタイミングに応じて、サービングビームで下りＬ１／Ｌ２制御シグナリングによってＰＵＣＣＨ送信可否を通知する。ＰＵＣＣＨ送信可否情報を設けるとよい。セルは、ＰＵＣＣＨ送信可否情報を下り制御情報に含めて、下りＬ１／Ｌ２制御シグナリングでＵＥに対して通知するとよい。
ＵＥは、ＰＵＣＣＨ送信可否情報を受信し、ＰＵＣＣＨ送信が可の場合に、ＰＵＣＣＨ送信可否情報を受信したサブフレームでＰＵＣＣＨ送信を可能とする。ＵＥは、ＰＵＣＣＨ送信可否情報を受信し、ＰＵＣＣＨ送信が不可の場合に、ＰＵＣＣＨ送信可否情報を受信したサブフレームでＰＵＣＣＨ送信を不可能とする。ＵＥは、ＰＵＣＣＨ送信可否情報を受信し、ＰＵＣＣＨ送信可情報を受信できなかった場合に、該サブフレームでＰＵＣＣＨ送信を不可能としてもよい。
ＰＵＣＣＨ送信可情報のみ設けて、ＰＵＣＣＨ送信否情報は省略してもよい。ＵＥは、ＰＵＣＣＨ送信可情報を受信した場合にのみ、ＰＵＣＣＨ送信可情報を受信したサブフレームでＰＵＣＣＨ送信を可能とする。
ＵＥに対する設定方法について開示する。
セルは、ＵＥに対して、予め設定したＰＵＣＣＨリソース内で、ＰＵＣＣＨ送信可否情報を送信して、ＰＵＣＣＨ送信可否を指示する。予め設定するＰＵＣＣＨリソースには、ＰＵＣＣＨリソースを設定するタイミングを含ませるとよい。少なくともサブフレーム単位のタイミングを含ませるとよい。実施の形態２あるいは実施の形態２の変形例１で開示したＰＵＣＣＨリソースに関する情報を通知して設定してもよい。
ＵＥは、ＰＵＣＣＨ送信可の情報を受信した場合に、ＰＵＣＣＨを送信可能とする。逆に、ＰＵＣＣＨ送信否（不可）情報を受信した場合に、ＰＵＣＣＨを送信不可とする。
予めＰＵＣＣＨリソース設定を通知しておくことを開示したが、ＰＵＣＣＨリソース設定のうちの一部あるいは全部を、ＰＵＣＣＨ送信可否情報とともに通知してもよい。サブフレームより小さい時間単位のリソース設定をＰＵＣＣＨ送信可否情報とともに通知してもよい。例えば、ＰＵＣＣＨに割当てるシンボル番号情報をＰＵＣＣＨ送信可否情報とともに通知する。これによって、動的に柔軟にシンボルを割当てることが可能となる。
あるいは、ＰＵＣＣＨリソース設定の一部あるいは全部の通知によって、ＰＵＣＣＨ送信可を示すとしてもよい。これによって、ＰＵＣＣＨ送信可の情報を省略することが可能となる。ＰＵＣＣＨ送信可否情報とともに通知する情報を少数に限定してもよい。予め大部分のＰＵＣＣＨリソースを設定しておくことによって、ＰＵＣＣＨ送信可の情報を受信してからＰＵＣＣＨの送信までの処理時間を短時間にすることができる。ＵＥが、ＰＵＣＣＨ送信可の情報を受信したのと同一のサブフレームでＰＵＣＣＨの送信が可能となる。
セルは、ＵＥに対してＰＵＣＣＨリソースを設定したサブフレームで、ＵＥが通信するビームを送受信しなくてもよい。しかし、この場合、ＵＥは、サービングビームからの下りＬ１／Ｌ２制御シグナリングを受信できなくなるので、ＰＵＣＣＨ送信可否情報を受信できなくなる。したがって、ＵＥの動作が不明確となり、ＵＥは、ＰＵＣＣＨ送信を行ってしまうおそれがある。
このような場合に、前述に開示したように、ＵＥは、ＰＵＣＣＨ送信可否情報を受信してＰＵＣＣＨ送信可情報を受信できなかった場合に、該サブフレームでＰＵＣＣＨ送信を不可能としておくことによって、ＵＥが無駄なＰＵＣＣＨ送信を行うことを回避することが可能となる。これによって、ＵＥの低消費電力化、および上り干渉電力の削減を図ることができる。
ＵＥに対する他の設定方法について開示する。
セルは、ＵＥに対して、予め、タイミング以外のＰＵＣＣＨリソース設定を通知しておき、タイミング以外は、該ＰＵＣＣＨリソース設定に従う。予め設定するタイミング以外のＰＵＣＣＨリソースの設定には、実施の形態２あるいは実施の形態２の変形例１で開示したＰＵＣＣＨリソースに関する情報の通知を適用してもよい。
セルは、ＵＥに対して、任意のタイミングでＰＵＣＣＨ送信可否を指示する。セルは、ＵＥに対して、ＰＵＣＣＨ送信可否情報を通知する。ＰＵＣＣＨ送信可否情報とともに、サブフレームより小さい時間単位のリソース設定を通知してもよい。例えば、シンボル番号を通知する。ＵＥは、ＰＵＣＣＨ送信可の情報を受信した場合に、ＰＵＣＣＨを送信可とする。逆に、ＰＵＣＣＨ送信否の情報を受信した場合に、ＰＵＣＣＨを送信不可とする。
タイミング以外のＰＵＣＣＨリソース設定を予め通知しておくことを開示したが、タイミング以外のＰＵＣＣＨリソース設定のうちの一部あるいは全部を、ＰＵＣＣＨ送信可否情報とともに通知してもよい。例えば、ＰＵＣＣＨの周波数リソース情報を、ＰＵＣＣＨ送信可否情報とともに通知してもよい。これによって、動的に柔軟に周波数リソースを割当てることが可能となる。
シンボル番号の通知、またはＰＵＣＣＨリソース設定の一部もしくは全部の通知によって、ＰＵＣＣＨ送信可を示すとしてもよい。これによって、ＰＵＣＣＨ送信可の情報を省略することが可能となる。
ＰＵＣＣＨ送信可否情報とともに通知する情報を少数に限定してもよい。予め大部分のＰＵＣＣＨリソースを設定しておくことによって、ＰＵＣＣＨ送信可の情報を受信してからＰＵＣＣＨの送信までの処理時間を短時間にすることができる。これによって、ＵＥが、ＰＵＣＣＨ送信可の情報を受信したサブフレームと同一のサブフレームで、ＰＵＣＣＨ送信が可能となる。
このようにすることによって、ＵＥは、サービングビームで送信されるＬ１／Ｌ２制御シグナリングに含まれるＰＵＣＣＨ送信可否情報に応じて、ＰＵＣＣＨの送信可否を判断することが可能となる。セルは、ＵＥに対して設定したＰＵＣＣＨリソースでＰＵＣＣＨ送信を不可とすることによって、該ＰＵＣＣＨリソースを他に使用できる。例えば、下り通信用リソースに使用できる。セルは、該ＰＵＣＣＨリソースの他への使用をダイナミックに決定できる。
特に、ＳＲについては、ＰＵＣＣＨ送信に下り制御信号を関連させることによって、セルの判断で動的にＰＵＣＣＨリソースを設定することが可能となる。ビームスイープが必要なＭＢＦの場合に、セルは、動的に送受信するビームを変更することが可能となる。予め各ビームに設定されたＰＵＣＣＨリソースタイミングで送受信する必要がなくなる。時々刻々とした電波伝搬環境変動、セルの負荷変動、または要求される通信サービスなどに柔軟に対応することが可能となる。
ＵＥは、ＰＵＣＣＨ送信可の情報を受信した場合、ＰＵＣＣＨで送信するＵＣＩがある場合、ＰＵＣＣＨ送信を行う。ＰＵＣＣＨで送信するＵＣＩが無い場合、ＰＵＣＣＨ送信を行わない。例えば、ＵＥは、送信すべきＳＲがある場合、ＳＲ用ＰＵＣＣＨ送信を行う。ＵＥは、ＰＵＣＣＨ送信不可の情報を受信した場合、ＰＵＣＣＨで送信するＵＣＩの有無にかかわらず、ＰＵＣＣＨ送信を行わない。例えば、送信すべきＳＲがあったとしても、ＳＲ用ＰＵＣＣＨ送信を行わない。
ＵＥがＰＵＣＣ送信不可の場合に送信しなかったＵＣＩは、ＵＥが、次のＰＵＣＣＨ送信可情報を受信するまで待ってから送信する。これによって、確実にＵＣＩを送信することが可能となる。他の方法として、ＵＥは、送信しながったＵＣＩを破棄するとしてもよい。あるいは、ＵＥは、送信しなかったＵＣＩを、次の同じ種類のＵＣＩが発生した場合に破棄するとしてもよい。これによって、ＵＥに必要となるバッファを少なくすることが可能となる。
図２０は、ＵＥのサービングビームのＤＬリソースと同一のサブフレームでＰＵＣＣＨリソースを設定する方法の一例を説明する図である。ここでは、ビームスイープ数が４個の場合について示す。ＰＵＣＣＨリソースに割当てるシンボルは、１サブフレーム内１シンボルとしている。ここでは、シンボル番号が１３のシンボルに割当てる。ＰＵＣＣＨリソースに割当てるシンボル番号は、固定としてもよい。下りＬ１／Ｌ２制御シグナリングに割当てるシンボルは、１サブフレーム内１シンボルとしている。ここでは、シンボル番号が０のシンボルに割当てる。下りＬ１／Ｌ２制御シグナリングに割当てるシンボル番号は、固定としてもよい。
セルは、サブフレーム番号０でビーム番号２のビーム２００２の送受信を行う。セルは、ビーム番号２で通信を行うＵＥに対して、ＵＥ毎のＰＵＣＣＨリソース送信可否情報をＵＣＩに含めて、ビーム番号２の下りＬ１／Ｌ２制御シグナリング２００１で通知する。セルは、ＵＥに、ＰＵＣＣＨリソース送信可否情報とともに、シンボル番号情報をＵＣＩに含めて通知してもよい。
ビーム番号２のビーム２００２で送受信を行うＵＥは、サブフレーム番号０のＬ１／Ｌ２制御シグナリング２００１を受信して、ＰＵＣＣＨリソース送信可否情報とシンボル番号とを受信する。ＰＵＣＣＨリソース送信可を受信したＵＥは、予め設定されたＰＵＣＣＨリソースに関する情報とシンボル番号とから、ＰＵＣＣＨリソースを設定し、送信可能とする。送信するＵＣＩがあるＵＥは、該ＰＵＣＣＨリソースでＰＵＣＣＨを送信する。ここでは、ビーム＃２のＰＵＣＣＨ２００３を送信する。
ＰＵＣＣＨリソース送信不可を受信したＵＥは、ＰＵＣＣＨの送信を不可能とする。ＵＥは、たとえ送信するＵＣＩがあったとしても、ＰＵＣＣＨを送信しない。
セルは、次のサブフレーム番号１でビーム番号３のビーム２００２の送受信を行う。セルは、ビーム番号３で通信を行うＵＥに対して、ＵＥ毎のＰＵＣＣＨリソース送信可否情報をＵＣＩに含めて、ビーム番号３の下りＬ１／Ｌ２制御シグナリング２００４で通知する。セルは、ＵＥに、ＰＵＣＣＨリソース送信可否情報とともに、シンボル番号情報をＵＣＩに含めて通知してもよい。
ビーム番号３のビーム２００２で送受信を行うＵＥは、サブフレーム番号１のＬ１／Ｌ２制御シグナリング２００４を受信して、ＰＵＣＣＨリソース送信可否情報とシンボル番号とを受信する。ＰＵＣＣＨリソース送信可を受信したＵＥは、予め設定されたＰＵＣＣＨリソースに関する情報とシンボル番号とから、ＰＵＣＣＨリソースを設定し、送信可能とする。送信するＵＣＩがあるＵＥは、該ＰＵＣＣＨリソースでＰＵＣＣＨを送信する。ここでは、ビーム＃３のＰＵＣＣＨ２００５を送信する。
ＰＵＣＣＨリソース送信不可を受信したＵＥは、ＰＵＣＣＨの送信を不可能とする。ＵＥは、たとえ送信するＵＣＩがあったとしても、ＰＵＣＣＨを送信しない。
セルは、次のサブフレーム番号２でビーム番号１のビーム２００２の送受信を行う。セルは、ビーム番号１で通信を行うＵＥに対して、ＵＥ毎のＰＵＣＣＨリソース送信可否情報をＵＣＩに含めて、ビーム番号１の下りＬ１／Ｌ２制御シグナリング２００６で通知する。セルは、ＵＥに、ＰＵＣＣＨリソース送信可否情報とともに、シンボル番号情報をＵＣＩに含めて通知してもよい。
ビーム番号１のビーム２００２で送受信を行うＵＥは、サブフレーム番号２のＬ１／Ｌ２制御シグナリング２００６を受信して、ＰＵＣＣＨリソース送信可否情報とシンボル番号とを受信する。ＰＵＣＣＨリソース送信可を受信したＵＥは、予め設定されたＰＵＣＣＨリソースに関する情報とシンボル番号とから、ＰＵＣＣＨリソースを設定し、送信可能とする。送信するＵＣＩがあるＵＥは、該ＰＵＣＣＨリソースでＰＵＣＣＨを送信する。ここでは、ビーム＃１のＰＵＣＣＨ２００７を送信する。
ＰＵＣＣＨリソース送信不可を受信したＵＥは、ＰＵＣＣＨの送信を不可能とする。ＵＥは、たとえ送信するＵＣＩがあったとしても、ＰＵＣＣＨを送信しない。
セルは、次のサブフレーム番号３でビーム番号０のビーム２００２の送受信を行う。セルは、ビーム番号０で通信を行うＵＥに対して、ＵＥ毎のＰＵＣＣＨリソース送信可否情報をＵＣＩに含めて、ビーム番号０の下りＬ１／Ｌ２制御シグナリング２００８で通知する。セルは、ＵＥに、ＰＵＣＣＨリソース送信可否情報とともに、シンボル番号情報をＵＣＩに含めて通知してもよい。
ビーム番号０のビーム２００２で送受信を行うＵＥは、サブフレーム番号３のＬ１／Ｌ２制御シグナリング２００８を受信して、ＰＵＣＣＨリソース送信可否情報とシンボル番号とを受信する。ＰＵＣＣＨリソース送信可を受信したＵＥは、予め設定されたＰＵＣＣＨリソースに関する情報とシンボル番号とから、ＰＵＣＣＨリソースを設定し、送信可能とする。送信するＵＣＩがあるＵＥは、該ＰＵＣＣＨリソースでＰＵＣＣＨを送信する。ここでは、ビーム＃０のＰＵＣＣＨ２００９を送信する。
ＰＵＣＣＨリソース送信不可を受信したＵＥは、ＰＵＣＣＨの送信を不可能とする。ＵＥは、たとえ送信するＵＣＩがあったとしても、ＰＵＣＣＨを送信しない。
このようにすることによって、セルが送受信を行うビームのタイミングに合わせてＰＵＣＣＨの送受信が可能となる。ＵＥは、サービングビームで送信されるＬ１／Ｌ２制御シグナリングに含まれるＰＵＣＣＨ送信可否情報に応じて、ＰＵＣＣＨの送信可否を判断することが可能となる。ＰＵＣＣＨの送信に下り制御信号を関連させることによって、セルの判断で動的にＰＵＣＣＨリソースを設定することが可能となる。
図２１は、ＤＬリソースと同一サブフレームでのＰＵＣＣＨリソースの設定およびＳＲの送受信のシーケンスの一例を示す図である。図２１に示すシーケンスは、図１６に示すシーケンスと同一のステップを含んでいるので、同一のステップについては同一のステップ番号を付して、共通する説明を省略する。
ステップＳＴ３００１において、セルは、ＵＥに対して、タイミング以外のＰＵＣＣＨリソース構成を設定する。
ステップＳＴ３００２において、セルは、ＵＥに対して、タイミング以外のＰＵＣＣＨリソースに関する情報を通知する。前記ＰＵＣＣＨリソースに関する情報は、ＵＥと通信するビームを介して通知するとよい。前記ＰＵＣＣＨリソースに関する情報の通知には、ＲＲＣ個別シグナリングを用いる。
ステップＳＴ３００２でタイミング以外のＰＵＣＣＨリソースに関する情報を受信したＵＥは、ステップＳＴ３００３において、該ＰＵＣＣＨリソース構成を記憶する。
ステップＳＴ３００４において、ＵＥは、上りデータが発生したか否かを判断する。ステップＳＴ３００４において上りデータが発生していない場合は、ステップＳＴ３００４に戻り、上りデータが発生したか否かの判断を繰り返す。ステップＳＴ３００４において上りデータが発生している場合は、ステップＳＴ３００５に移行する。
ステップＳＴ３００５において、ＵＥは、ＳＲ送信を待機し、上りデータをバッファに記憶する。
ステップＳＴ３００６において、セルは、任意のサブフレームにおいて、ＵＥが通信を行うビームへの送受信を決定する。また、セルは、該サブフレームにおいて、ＵＥに対して、ＰＵＣＣＨの送信が可能であることを決定する。
ステップＳＴ３００７において、セルは、該サブフレームにおいて、ＵＥに対して、ＰＵＣＣＨ送信可の情報を通知する。ここでは、ＰＵＣＣＨ送信可の情報とともに、シンボル番号情報を通知する。セルは、これらの情報を下りＬ１／Ｌ２制御情報に含めて、下りＬ１／Ｌ２制御シグナリングで、ＵＥに対して通知する。
ステップＳＴ３００７でＰＵＣＣＨ送信可の情報を受信したＵＥは、ステップＳＴ３００８において、ステップＳＴ３００３で記憶したＵＥ毎のＰＵＣＣＨリソースに関する情報と、ステップＳＴ３００７で受信したシンボル番号とを用いて、受信したサブフレームと同一のサブフレームに、自ＵＥのＰＵＣＣＨリソース構成を設定する。
ステップＳＴ３００９において、ＵＥは、待機していたＳＲを、ステップＳＴ３００８で設定したＳＲ用ＰＵＣＣＨリソース構成で、サービングビームを介してセルに対して送信する。
ステップＳＴ３００７でＵＥに対してＰＵＣＣＨ送信可の情報とシンボル番号情報とを通知したセルは、ステップＳＴ３０１０において、同一のサブフレームでＵＥに対して設定したＰＵＣＣＨリソース構成で受信を開始する。
ステップＳＴ３０１０でＵＥに対して設定したＰＵＣＣＨリソース構成で受信を開始したセルは、ステップＳＴ３００９において、ＵＥから送信されたＳＲを受信する。
このようにしてＵＥからＳＲを受信したセルは、上り通信開始のための処理を行う。これによって、ＵＥとセルとの間で上り通信が開始される。
本変形例で開示した方法を用いることによって、ＭＢＦにおけるビームスイーピング運用時のＰＵＣＣＨリソースの設定が可能となる。セルがＵＥに対して、本実施の形態で開示した方法でＰＵＣＣＨリソースの設定を行うことによって、ＵＥが通信を行っているビームでのＰＵＣＣＨの送受信が可能となり、ＵＥからセルへの上り通信が可能となる。
また、セルが送受信を行うビームのタイミングに合わせてＰＵＣＣＨの送受信が可能となる。ＵＥは、サービングビームで送信されるＬ１／Ｌ２制御シグナリングに含まれるＰＵＣＣＨ送信可否情報に応じて、ＰＵＣＣＨの送信可否を判断することが可能となる。このようにすることによって、ＰＵＣＣＨを送受信するビームを、ＵＥに対して設定したＰＵＣＣＨリソースに合わせて制御することが不要となる。したがって、ＵＥへのＰＵＣＣＨリソース設定およびＰＵＣＣＨ送受信のための制御を容易にすることが可能となる。
前述に開示した方法では、セルは、ＵＥに対して、ＵＥが通信するビームのＤＬリソースを構成するサブフレームと同一サブフレームでのＰＵＣＣＨの送信可否を通知した。セルは、同一サブフレームでのＰＵＣＣＨの送信可否ではなく、ＰＵＣＣＨの送信可否を通知したサブフレームからオフセット後のサブフレームでのＰＵＣＣＨの送信可否を通知してもよい。
ＰＵＣＣＨの送信可否を通知したサブフレームからオフセット値を示すオフセット情報を設けてもよい。セルは、ＵＥに対して、ＰＵＣＣＨ送信可否情報とともに、該オフセット情報を通知する。ＵＥは、ＰＵＣＣＨ送信可の情報を受信したサブフレームからオフセット値だけ後のサブフレームでＰＵＣＣＨを送信する。ＵＥは、ＰＵＣＣＨ送信不可の情報を受信した場合、サブフレームからオフセット値だけ後のサブフレームでＰＵＣＣＨを送信しない。
セルは、ＵＥが通信しているビームの次の送受信タイミングを認識している場合に適用するとよい。あるいは、セルは、ＵＥが通信しているビームの次の送受信タイミングをスケジューリングしているような場合に適用するとよい。あるいは、セルは、ＵＥに対して、ＰＵＣＣＨ送信可の情報を通知するときに、ＵＥが通信しているビームの次の送受信タイミングを決定した場合に適用するとよい。
このようにすることによって、ＵＥは、ＰＵＣＣＨ送信可の情報を受信したサブフレームと同一のサブフレームでＰＵＣＣＨを設定し、ＰＵＣＣＣＨを送信しなくてもよい。したがって、ＵＥでの復調、デコーディング、コーディングおよび変調などのＰＵＣＣＨの送信に関する処理に時間を要する場合も、ＵＥからのＰＵＣＣＨを送信することが可能となる。
ＵＥは、セルに対して、予め、復調、デコーディング、コーディングおよび変調などに関する処理に要する時間あるいは能力を通知しておいてもよい。ＵＥケーパビリティ情報として通知してもよい。セルは、ＵＥから通知された復調、デコーディング、コーディングおよび変調などに関する処理に要する時間あるいは能力を用いて、オフセット値を決定してもよい。
例えば、ＵＥが、ＰＵＣＣＨ送信可否の受信からＰＵＣＣＨの送信までを同一のサブフレーム内で可能な場合、セルは、オフセットを０としてＵＥに通知する。オフセットが０の場合は、オフセット情報を省略してもよい。また、例えば、ＵＥが、ＰＵＣＣＨ送信可否の受信からＰＵＣＣＨの送信まで２サブフレームを要する場合は、セルは、オフセットを２としてＵＥに通知する。このとき、セルは、他のビームの通信状況を考慮してもよく、オフセットが２以降を設定してＵＥに通知してもよい。
前述に開示した方法では、一つのサブフレームを一つのビームに割当てた。一つのサブフレーム全部を一つのビームだけに割当てるのではなく、複数のビームに割当ててもよい。例えば、一つのサブフレームの下りＬ１／Ｌ２制御信号がマッピングされるシンボルとＰＵＣＣＨリソースが構成されるシンボルのみ同一のビームに割当てて、他のシンボルを他のビームに割当ててもよい。このようにすることによって、セルは、さらにビームの運用を柔軟に行うことが可能となり、セルとしての無線リソースの使用効率を向上させることができる。
例えば、一つのサブフレームに一つのビームの下りＬ１／Ｌ２制御信号だけでなく、複数のビームの下りＬ１／Ｌ２制御信号が割当てられてもよい。シンボル毎に割当てらえてもよい。また、一つのサブフレームに一つのビームのＰＵＣＣＨリソースだけでなく、複数のビームのＰＵＣＣＨリソースが割り当てられてもよい。シンボル毎に割当てられてもよい。セルは、一つのサブフレームで複数のビームにおいて、各ビームと通信するＵＥからのＰＵＣＣＨ送信を受信することが可能となる。
１サブフレーム内でＬ１／Ｌ２制御信号がマッピングされる可能性のあるシンボルを限定してもよい。最大値を設けてもよい。ＵＥは、該可能性のあるシンボルを受信して、サービングビーム向けのＬ１／Ｌ２制御信号があるかどうか判断するとよい。最大値は、セルからＵＥに対して、予め通知してもよい。セル毎の情報として報知してもよいし、ＵＥ個別シグナリングで通知してもよい。あるいは、静的に規格などで決めておいてもよい。ＵＥは、該最大値のシンボルだけを受信して、自ＵＥ宛の下りＬ１／Ｌ２制御情報を受信できなかった場合、該サブフレームを受信しなくてよい。
このような方法を用いることによって、各ビームでの通信機会が増大するので、ＵＥでのＳＲ送信待機時間を短縮することが可能となる。したがって、ＵＥからの上りデータの発生から上り通信の開始までの遅延時間の短縮を図ることができる。
１サブフレーム内の複数のシンボルに複数のビームのＬ１／Ｌ２制御信号が割当てられる場合、ＵＥは、先頭の１シンボルではなく、複数のシンボルを受信する。予めＬ１／Ｌ２制御信号が割当てられるシンボル数が固定されている場合は、ＵＥは、該シンボル数を受信して、サービングビームで送信されるＬ１／Ｌ２制御信号を受信することが可能となる。しかし、予めシンボル数を固定にすると、Ｌ１／Ｌ２制御信号が不要なビームが発生した場合、該シンボルは無駄になる。
このような問題を解決する方法を開示する。
セルは、毎サブフレーム、Ｌ１／Ｌ２制御信号に用いられるシンボル数の情報を通知するとよい。該情報をセル共通の情報とするとよい。該情報を下りＬ１／Ｌ２制御情報に含めて通知してもよい。ＵＥ個別のＬ１／Ｌ２制御情報とするとよい。あるいは、セル共通のＬ１／Ｌ２制御情報としてもよい。セル共通のＬ１／Ｌ２制御情報とすることによって、情報量を削減することができる。
前記Ｌ１／Ｌ２制御信号に用いられるシンボル数の情報をマッピングする物理チャネルを個別に設けて、毎サブフレームＵＥに対して通知してもよい。該物理チャネルをサブフレームの先頭のシンボルにマッピングしてもよい。
セルは、前記Ｌ１／Ｌ２制御信号に用いられるシンボル数の情報を毎サブフレーム通知することを開示したが、周期的に通知してもよい。周期的に１サブフレーム内の複数のシンボルに複数のビームのＬ１／Ｌ２制御信号が割当てるような場合に適用するとよい。セルは、該周期情報および始点となるオフセット情報を予めＵＥに通知しておくとよい。セル毎の情報として報知してもよいし、ＵＥ個別シグナリングで通知してもよい。あるいは、静的に規格などで決めておいてもよい。
このようにすることによって、ＭＢＦにおけるビームスイーピング運用時のＬ１／Ｌ２制御シグナリングを柔軟に設定することが可能となる。また、本変形例を用いることによって、ＭＢＦにおけるビームスイーピング運用時のＰＵＣＣＨリソースの設定が可能となる。
ＮＲでは、ＭＢＦにおいてセル内の全てのビームを同一のタイミングで構成できないような場合、セル共通の制御チャネルを送受信するために、全てのビームを連続してビームスイーピングを行うことが検討されている（非特許文献１２参照）。このように全てのビームを連続してビームスイーピングを行う部分を、ビームスイーピングブロックとも称する。
ＰＵＣＣＨリソースタイミングが、このようなビームスイーピングブロックのタイミングと重なる場合、ＰＵＣＣＨにシンボルを割当てられなくなる。このような場合、ＰＵＣＣＨリソースタイミングとして、ビームスイーピングブロックのタイミングを除くとよい。セルは、ビームスイーピングブロックタイミングと、ＵＥに対して設定したＰＵＣＣＨリソースタイミングとが重なる場合、ＰＵＣＣＨリソースを設定しないとしてもよい。ＰＵＣＣＨを送信不可能とする。
あるいは、ＵＥは、ビームスイーピングブロックタイミングと、ＰＵＣＣＨリソースタイミングとが重なる場合、ＰＵＣＣＨリソースを設定しない。ＰＵＣＣＨを送信不可能としてもよい。このことを、予め規格などで決めておいてもよい。セルがＵＥに対して、ビームスイーピングブロック周期などを通知することによって、ＵＥは、ビームスイーピングブロックタイミングを認識することができる。
このようにすることによって、ビームスイーピングブロックで無駄なＰＵＣＣＨの送信を防ぐことができる。したがって、ＵＥの低消費電力化を図ることができる。
ＰＵＣＣＨリソースタイミングが、このようなビームスイーピングブロックのタイミングと重なる場合の他の方法を開示する。
ビームスイーピングブロックを自己完結型サブフレームとする。下りビームスイーピングブロックの各ビームの送信において、上り送信を可能にする。該上り送信用シンボルをＰＵＣＣＨに割当てるとよい。
ビームスイーピングブロックにおいて、ＰＵＣＣＨ送信と重なるタイミングでのビームが、ＰＵＣＣＨの送信を必要とするビームではなく、他のビームとなる場合がある。このような場合は、該ビームスイーピングブロック内の、ＰＵＣＣＨの送信を必要とするビームの上り送信用シンボルを、ＰＵＣＣＨに割当てるようにしてもよい。このことを、予め規格などで決めておいてもよい。
このようにすることによって、たとえ、ＰＵＣＣＨリソースタイミングが、ビームスイーピングブロックタイミングと重なるとしても、該タイミングあるいはビームスイーピングブロックのタイミングでＰＵＣＣＨを送信することが可能となる。
ＰＵＣＣＨリソースタイミングが、上りのビームスイーピングブロックのタイミングと重なる場合は、上りビームスイーピングブロックの一部のシンボルをＰＵＣＣＨに割当てるとよい。
上りビームスイーピングブロックにおいて、ＰＵＣＣＨの送信と重なるタイミングでのビームが、ＰＵＣＣＨの送信を必要とするビームではなく、他のビームとなる場合がある。このような場合は、該上りビームスイーピングブロック内の、ＰＵＣＣＨの送信を必要とするビームの一部のシンボルを、ＰＵＣＣＨに割当てるようにしてもよい。このことを、予め規格などで決めておいてもよい。
このようにすることによって、たとえ、ＰＵＣＣＨリソースタイミングが、上りビームスイーピングブロックタイミングと重なるとしても、該タイミングあるいは上りビームスイーピングブロックのタイミングでＰＵＣＣＨを送信することが可能となる。
周波数分割複信（Frequency Division Duplex：ＦＤＤ）の場合、ＰＵＣＣＨリソースタイミングと、下りビームスイーピングブロックタイミングとが重なったときは、周波数が異なるので問題ないが、ＰＵＣＣＨリソースタイミングと、上りビームスイーピングブロックタイミングとが重なったときは、問題が生じる。このようなときも、前述の上りビームスイーピングブロックについて開示した方法を適用するとよい。これによって、同様の効果を得ることができる。
実施の形態３．
実施の形態２から実施の形態２の変形例２では、ビームスイーピングを必要とするＭＢＦでのＰＵＣＣＨの送受信方法として、各ビームのＰＵＣＣＨを異なるリソースに割当てる方法を開示した。本実施の形態では、ビームスイーピングを必要とするＭＢＦでのＰＵＣＣＨの送受信方法として、他の方法を開示する。
セルは、ビーム間でＰＵＣＣＨの受信の優先順位をつける。セルは、ビーム間でＰＵＣＣＨの受信の優先順位をつけ、優先順位に従って対象ビームでＰＵＣＣＨを受信する。
セルは、ＵＥ間で優先順位をつけてもよい。セルは、ＵＥの優先順位を用いて、ＵＥが通信を行うビーム間で優先順位をつけてもよい。例えば、同一ビームで通信を行うＵＥのうち、最も高い優先順位に応じて、ビーム間の優先順位をつける。
優先順位付けの指標例として、以下の（１）〜（９）の９つを開示する。
（１）通信のサービス種類。例えば、緊急性を要するサービスの優先順位を高く設定する。
（２）要求ＱｏＳ。例えば、高スループットを要するＱｏＳの優先順位を高く設定する。
（３）要求遅延時間。例えば、低遅延時間を要するＵＥの優先順位を高く設定する。
（４）ビーム毎の負荷。例えば、負荷の高いビームの優先順位を高く設定する。
（５）ＵＥ能力（ＵＥケーパビリティ）。例えば、ＵＥ能力の高いＵＥの優先順位を高く設定する。
（６）ＳＲ周期。例えば、ＳＲ周期の長いＵＥの優先順位を高く設定する。
（７）ビーム毎のＵＥ数。例えば、ＵＥ数の多いビームの優先順位を高く設定する。
（８）通信品質。例えば、通信品質の良いビームの優先順位を高く設定する。
（９）前記（１）〜（８）の組合せ。
セルは、予め前述のような指標に従って、ビームのＰＵＣＣＨの受信に優先順位をつけるとよい。セルは、予め前述の指標に従って、ビームの送信および受信の少なくとも一方に優先順位をつけてもよい。セルは、予め前述のような指標に従って、ＵＥのＰＵＣＣＨの受信に優先順位をつけ、ＵＥの優先順位に応じて、ビーム間の優先順位をつけてもよい。
セルは、設定した優先順位に従って、対象ビームでＰＵＣＣＨを受信する。例えば、通信品質の良いビームの優先順位を高く設定した場合、通信品質の良いビームをＰＵＣＣＨの受信対象ビームとする。例えば、高い優先順位のＵＥが存在するビームをＰＵＣＣＨの受信対象ビームとする。
あるビームのＵＥのＰＵＣＣＨの送信タイミングが、他のビームのＵＥのＰＵＣＣＨの送信タイミングと衝突した場合、セルは、設定した優先順位に従って、どのビームで送受信を優先して行うかを決定する。他のビームのＵＥのＰＵＣＣＨの送信タイミングと衝突した場合だけでなく、他のビームでの送受信のスケジューリングタイミングと衝突した場合としてもよい。
ＵＥの優先順位を用いて、ＵＥが通信を行うビーム間で優先順位をつける場合の例について開示する。該タイミングが衝突した場合、該タイミングで、セルは、優先順位の高いＵＥが通信を行うビームでＰＵＣＣＨの受信を行い、優先順位の低いＵＥが通信を行うビームでＰＵＣＣＨの受信を行わない。該タイミングで優先順位の高いＵＥは、セルに対して、ＰＵＣＣＨの送信を行う。該タイミングで優先順位の低いＵＥは、セルに対して、ＰＵＣＣＨを送信するが、セルは、該ＰＵＣＣＨを受信しない。
衝突タイミングで、優先順位の低いＵＥがＰＵＣＣＨを送信することになるが、該ＵＥが通信を行うビームとは異なるビームで通信を行うことになるので、セルにおいて受信信号が衝突することはなく、問題にはならない。
このように、たとえＰＵＣＣＨの送信タイミングが衝突しても、優先順位を設けて、優先順位に応じたビームでＰＵＣＣＨの送受信を行うことによって、ビームとは関係なく、ＰＵＣＣＨ用リソースの設定を実行することができる。したがって、ＵＥに対する処理の追加などによって、処理が複雑化することを回避することが可能となる。
前述に開示した方法では、優先順位の低いＵＥは、ＰＵＣＣＨがセルに受信されなくなるので、ＰＵＣＣＨの送信のために設定されたタイミングで毎回送信することになる。しかし、これは無駄な送信となり、ＵＥの消費電力が増大し、上り干渉電力が増大するという問題を引き起こす。
このような問題を解決する方法を開示する。
ＢＳＲを受信中のＵＥの優先順位を最下位にする。セルは、ＢＳＲを受信中のＵＥの優先順位を最下位に設定する。セルは、ＢＳＲに対する上りスケジューリング（上りグラント）の送信を終了すると、ＵＥの優先順位を元に戻す。このような方法を用いることによって、優先順位の低いＵＥが通信を行うビームでＰＵＣＣＨの送受信が可能となる。したがって、優先順位の低いＵＥが無駄なＰＵＣＣＨを繰り返し送信してしまうことを回避することが可能となる。
他の方法を開示する。セルは、優先順位の低いＵＥに対して、ＰＵＣＣＨリソースのあるサブフレームで該ＵＥが通信を行うビームを用いてＰＵＣＣＨ送信可否情報を通知する。ＰＵＣＣＨリソースのあるサブフレームに該ＵＥが通信を行うビームの下りＬ１／Ｌ２制御信号をマッピングし、該ビームの下りＬ１／Ｌ２制御情報にＰＵＣＣＨ送信可否を示す情報を含ませる。ＰＵＣＣＨ送信不可情報のみとしてもよい。
下りＬ１／Ｌ２制御信号用のリソースは、シンボル単位としてもよい。１シンボルとしてもよい。ＵＥは、ＰＵＣＣＨリソースのあるサブフレームで、自ＵＥが通信を行うビームの下りＬ１／Ｌ２制御信号を受信して、ＰＵＣＣＨ送信可否を判断する。ＵＥは、ＰＵＣＣＨの送信不可を受信した場合、ＰＵＣＣＨの送信を行わない。このＰＵＣＣＨ送信可否情報の送信に関しては、実施の形態２の変形例２で開示した方法を適用するとよい。
このようにすることによって、優先順位の低いＵＥが、衝突したタイミングでＰＵＣＣＨの送信を行わないようにすることができる。したがって、優先順位の低いＵＥが無駄なＰＵＣＣＨを繰り返し送信してしまうことを回避することが可能となる。
図２２および図２３は、ビーム間でＰＵＣＣＨ受信に優先順位を設けた場合のＳＲの送受信のシーケンスの一例を示す図である。図２２と図２３とは、境界線ＢＬ１の位置で、つながっている。図２２および図２３に示すシーケンスは、図１９に示すシーケンスと同一のステップを含んでいるので、同一のステップについては同一のステップ番号を付して、共通する説明を省略する。図２２および図２３では、優先順位が高いＵＥ（以下「ＵＥ１」と称する場合がある）と、優先順位が低いＵＥ（以下「ＵＥ２」と称する場合がある）とが存在しており、優先順位の高いＵＥが通信を行うビームと優先順位の低いＵＥが通信を行うビームとが異なる場合について示している。
ステップＳＴ２８０１において、セルは、ＵＥ１に対して、ＵＥ毎のＰＵＣＣＨリソース構成を設定する。また、ステップＳＴ２８０１において、セルは、ＵＥ２に対しても、ＵＥ毎のＰＵＣＣＨリソース構成を設定する。
ステップＳＴ３１０１において、セルは、ＵＥ１に対して、ＵＥ毎のＰＵＣＣＨリソースに関する情報を通知する。前記ＰＵＣＣＨリソースに関する情報は、ＵＥ１と通信するビームを介して通知するとよい。前記ＰＵＣＣＨリソースに関する情報の通知には、ＲＲＣ個別シグナリングを用いる。
ステップＳＴ３１０２において、セルは、ＵＥ２に対して、ＵＥ毎のＰＵＣＣＨリソースに関する情報を通知する。前記ＰＵＣＣＨリソースに関する情報は、ＵＥ２と通信するビームを介して通知するとよい。前記ＰＵＣＣＨリソースに関する情報の通知には、ＲＲＣ個別シグナリングを用いる。
ステップＳＴ３１０１でＵＥ毎のＰＵＣＣＨリソースに関する情報を受信したＵＥ１は、ステップＳＴ３１０３において、該ＰＵＣＣＨリソース構成を設定する。
ステップＳＴ３１０２でＵＥ毎のＰＵＣＣＨリソースに関する情報を受信したＵＥ２は、ステップＳＴ３１０４において、該ＰＵＣＣＨリソース構成を設定する。
ステップＳＴ３１０５において、ＵＥ１は、上りデータが発生したか否かを判断する。ステップＳＴ３１０５において上りデータが発生していない場合は、ステップＳＴ３１０５に戻り、上りデータが発生したか否かの判断を繰り返す。ステップＳＴ３１０５において上りデータが発生している場合は、ステップＳＴ３１０６に移行する。
ステップＳＴ３１０６において、ＵＥ１は、設定されたＳＲ用ＰＵＣＣＨリソース構成でＳＲを、サービングビームを介してセルに対して送信する。
ステップＳＴ３１０７において、セルは、ＵＥ１とＵＥ２とのＰＵＣＣＨリソースタイミングで衝突が発生していることを認識する。
ステップＳＴ３１０８において、セルは、前記ＰＵＣＣＨリソースタイミングで、優先順位の高いＵＥ、ここではＵＥ１と通信を行うビームでＰＵＣＣＨの受信を決定する。言い換えると、セルは、前記ＰＵＣＣＨリソースタイミングで、優先順位の低いＵＥ、ここではＵＥ２と通信を行うビームでＰＵＣＣＨの受信を行わないことを決定する。
ステップＳＴ３１０６において、セルは、ＵＥ１に対して設定したＰＵＣＣＨリソースでＵＥ１から送信されたＳＲを受信する。
このようにしてＵＥ１からＳＲを受信したセルは、ステップＳＴ２５１０Ａにおいて、ＳＲを送信したＵＥに対して、すなわちＵＥ１に対して、上りスケジューリングを開始する。
ステップＳＴ２５１１Ａにおいて、セルは、ＵＥ１に対して上りグラント、具体的には上りグラントを含む上りスケジューリング情報を送信する。
ステップＳＴ２５１１Ａで上りグラントを受信したＵＥ１は、ステップＳＴ２５１２Ａにおいて、該上りグラントを用いて、ＢＳＲ（Buffer Status Report）をセルに送信する。このときに、上りデータを送信してもよい。
ステップＳＴ２５１２ＡでＢＳＲを受信したセルは、ＢＳＲに従って、ＵＥ１に対して上りスケジューリングを行う。
ステップＳＴ２５１３Ａにおいて、セルは、ＵＥ１に対して上りグラントを送信する。ステップＳＴ２５１３Ａで上りグラントを受信したＵＥ１は、ステップＳＴ２５１４Ａにおいて、該上りグラントを用いて、上りデータをセルに送信する。ステップＳＴ２５１４Ａにおいて、セルは、ＵＥ１から送信された上りデータを受信する。
以上のようにして、セルは、ステップＳＴ２５１１ＡからステップＳＴ２５１４Ａにおいて、ＵＥ１に対して上り通信開始のための処理を行う。これによって、ＵＥ１とセルとの間で上り通信が開始される。
ステップＳＴ３１０９において、ＵＥ２は、上りデータが発生したか否かを判断する。ステップＳＴ３１０９において上りデータが発生していない場合は、ステップＳＴ３１０９に戻り、上りデータが発生したか否かの判断を繰り返す。ステップＳＴ３１０９において上りデータが発生している場合は、ステップＳＴ３１１０に移行する。
ステップＳＴ３１１０において、ＵＥ２は、設定されたＳＲ用ＰＵＣＣＨリソース構成でＳＲを、サービングビームを介してセルに対して送信する。
しかし、ステップＳＴ３１０８において、セルは、前記ＰＵＣＣＨリソースタイミングで、ＵＥ１と通信を行うビームでＰＵＣＣＨの受信を決定し、ステップＳＴ３１０８において、ＵＥ１に対して設定したＰＵＣＣＨリソースでＵＥ１から送信されたＳＲを受信する。
したがって、セルは、ステップＳＴ３１１０において、ＵＥ２と通信を行うビームでＵＥ２から送信されたＳＲを受信できない。
ステップＳＴ３１１１において、セルは、優先順位の高いＵＥであるＵＥ１のＢＳＲを受信中か否かを判断する。ステップＳＴ３１１１においてＢＳＲを受信中でない場合は、ステップＳＴ３１１１に戻り、再度ＢＳＲを受信中か否かの判断を行う。ステップＳＴ３１１１においてＢＳＲを受信中である場合は、ステップＳＴ３１１２に移行する。
ステップＳＴ３１１１においてＢＳＲを受信中である場合、セルは、ＵＥ１に対して上りデータを送信するためのリソースをスケジューリングする処理を行っているので、ＵＥ１がＳＲを送信する必要は無いと判断する。そして、ステップＳＴ３１１２において、セルは、ＵＥ１の優先順位を最下位に設定する。
ステップＳＴ３１１３において、セルは、ＵＥ１とＵＥ２とのＰＵＣＣＨリソースタイミングで衝突が再度発生していることを認識する。
ステップＳＴ３１１４において、セルは、前記ＰＵＣＣＨリソースタイミングで、優先順位の高いＵＥ、ここではＵＥ２と通信を行うビームでＰＵＣＣＨの受信を決定する。言い換えると、セルは、前記ＰＵＣＣＨリソースタイミングで、優先順位の低いＵＥ、ここではＵＥ１と通信を行うビームでＰＵＣＣＨの受信を行わないことを決定する。
ステップＳＴ３１１０においてＳＲを送信したにもかかわらず、上りグラントを受信できなかったＵＥ２は、再度ＰＵＣＣＨリソースタイミングで、ステップＳＴ３１１５において、設定されたＳＲ用ＰＵＣＣＨリソース構成でＳＲを、サービングビームを介してセルに対して送信する。
ステップＳＴ３１１５において、セルは、ＵＥ２に対して設定したＰＵＣＣＨリソースで、ＵＥ２から送信されたＳＲを受信する。
このようにしてＵＥ２からＳＲを受信したセルは、ステップＳＴ２５１０Ａにおいて、ＳＲを送信したＵＥに対して、すなわちＵＥ２に対して、上りスケジューリングを開始する。
ステップＳＴ２５１１Ｂにおいて、セルは、ＵＥ２に対して上りグラント、具体的には上りグラントを含む上りスケジューリング情報を送信する。
ステップＳＴ２５１１Ｂで上りグラントを受信したＵＥ２は、ステップＳＴ２５１２Ｂにおいて、該上りグラントを用いて、ＢＳＲをセルに送信する。このときに、上りデータを送信してもよい。
ステップＳＴ２５１２ＢでＢＳＲを受信したセルは、ＢＳＲに従って、ＵＥ２に対して上りスケジューリングを行う。
ステップＳＴ２５１３Ｂにおいて、セルは、ＵＥ２に対して上りグラントを送信する。ステップＳＴ２５１３Ｂで上りグラントを受信したＵＥ２は、ステップＳＴ２５１４Ｂにおいて、該上りグラントを用いて、上りデータをセルに送信する。ステップＳＴ２５１４Ｂにおいて、セルは、ＵＥ２から送信された上りデータを受信する。
以上のようにして、セルは、ステップＳＴ２５１１ＢからステップＳＴ２５１４Ｂにおいて、ＵＥ２に対して上り通信開始のための処理を行う。これによって、ＵＥ２とセルとの間で上り通信が開始される。
このようにすることによって、たとえ、通信しているビームが異なる複数のＵＥのＰＵＣＣＨリソースタイミングが衝突したとしても、セルは、それらのＵＥのＰＵＣＣＨを受信することが可能となる。
これによって、ビームとは関係なく、従来のＰＵＣＣＨの設定方法を適用できる。したがって、ＵＥに対する処理の追加などによって、処理が複雑化することを回避することが可能となる。また、上りグラントを送信したＵＥに対する優先順位を最下位に再設定することによって、低い優先順位のＵＥに対しても該ビームでＰＵＣＣＨを受信することが可能となる。したがって、低い優先順位のＵＥが無駄なＰＵＣＣＨの送信を繰り返すことによる消費電力の増大、および上り干渉電力の増大を回避することが可能となる。
実施の形態４．
実施の形態２から実施の形態３では、ＰＵＣＣＨを割当てるリソースの最小単位としてシンボルを割当てることを開示した。ビームスイープ数が多くなると、ＰＵＣＣＨリソースのために必要となるシンボル数が増大する。したがって、一つのサブフレーム内で多数のビームのＰＵＣＣＨリソースを構成しようとすると、データ用のリソースが少なくなり、通信速度を低下させてしまうという問題が発生する。あるいは、一つのサブフレーム内では、少数のビームのＰＵＣＣＨリソースを構成すると、複数のサブフレームにわたってＰＵＣＣＨリソースが必要となり、ビーム毎のＰＵＣＣＨリソースの発生間隔が増大する。したがって、遅延時間が大きくなってしまうという問題が発生する。
本実施の形態では、このような問題を解決するための方法を開示する。
１シンボル期間内に複数のシンボルを構成し、複数のビームのＰＵＣＣＨリソースを時間分割多重する。１シンボル期間内に構成する複数のシンボル数を２のｎ（ｎは自然数）乗倍とするとよい。このようにすることによって、ＰＵＣＣＨリソースを割当てるシンボル期間を短くすることができ、多数のビームのＰＵＣＣＨリソースを構成することが可能となる。短くしたシンボルのことを、以下の説明において、短縮シンボルと称する場合がある。
１シンボル期間内に複数のシンボルを構成する方法として、３ＧＰＰで提案されているサブキャリア間隔増大（Larger subcarrier spacing）方法（３ＧＰＰ Ｒ１−１６６５６６（以下「参考文献７」という）参照）を用いるとよい。参考文献７では、１シンボル期間内で４シンボルが構成され、ＵＥは、該４シンボルを用いて、各シンボルでビームを振って送信を行うことが開示されている。セルは、該４シンボルで一つのＵＥからの送信を受信することが開示されている。
本実施の形態では、各短縮シンボルをＵＥ毎のＰＵＣＣＨのリソースとして割当てる。セルは、１シンボル期間内で構成された複数の短縮シンボルを受信することによって、異なるビームで通信する複数のＵＥからのＰＵＣＣＨを受信することが可能となる。
１シンボル期間を短くするので、サブキャリア間隔は広がることになる。しかし、ビームスイープが必要なＭＢＦにおいては、同一タイミングで複数のビームで送受信できないので、時間分割多重が必要となる。逆に、あるタイミングでは、特定の方向のビームでしか送受信を行うことができないので、該タイミングでは全帯域の周波数リソースを使用することが可能となる。したがって、サブキャリア間隔が広がり、必要となる周波数リソースが増大したとしても、１シンボル間隔を短くして、複数のビームのＰＵＣＣＨに割当てることが有効となる。
前述の方法では、１シンボル期間内で２のｎ乗倍のシンボルが構成されることを開示したが、１シンボルのみでなくてもよく、複数のシンボルであってもよい。複数のシンボルが、１シンボル期間内で、各々、２のｎ乗倍のシンボルが構成されるようにしてもよい。ｎの値は、各シンボルで同じでもよいし、異なっていてもよい。
このようにすることによって、短縮シンボルに、さらに多くのビームのＰＵＣＣＨリソースを割当てることが可能となる。
ＰＵＣＣＨのためのリソースの設定方法について開示する。実施の形態２で開示したＰＵＣＣＨリソースに関する情報の他に、短縮シンボルに関する情報を設ける。
短縮シンボルに関する情報の具体例として、以下の（１）〜（６）の６つを開示する。
（１）短縮シンボルにするシンボル番号。
（２）１シンボル内に構成する短縮シンボル数。
（３）短縮シンボルのシンボル長。
（４）短縮シンボルのサブキャリア間隔。
（５）短縮シンボルでのシンボル番号。
（６）前記（１）〜（５）の組合せ。
セルは、ＵＥに対して、短縮シンボルに関する情報を通知する。また、セルは、ＵＥに対して、ＰＵＣＣＨリソースに関する情報を通知してもよい。セルは、ＵＥに対して、短縮シンボルに関する情報と、ＰＵＣＣＨリソースに関する情報とを組合せて通知してもよい。
セルは、ＵＥに対して、短縮シンボルに関する情報を、対応するＰＵＣＣＨリソースに関する情報とともに、あるいは、対応するＰＵＣＣＨリソースに関する情報に含めて通知してもよい。
また、短縮シンボルの他に、短縮シンボルではない通常のシンボルにＰＵＣＣＨリソースを設定してもよい。この場合、通常のシンボル用と、短縮シンボル用とで、ＰＵＣＣＨリソースに関する情報を別に設けてもよい。
ＰＵＣＣＨのためのリソースの割当方法については、実施の形態２から実施の形態３の方法を適宜適用するとよい。また、短縮シンボルに関する情報あるいは対応するＰＵＣＣリソースに関する情報の通知方法は、各実施の形態あるいは変形例で開示した方法を適用すればよい。
このようにすることによって、より多くのビームスイープ数が必要となるセルあるいはＴＲＰにおいても、一つのサブフレーム内でより多くのビームのＰＵＣＣＨリソースを構成することが可能となる。したがって、データ用のリソースの低減による通信速度の低下、およびビーム毎のＰＵＣＣＨリソースの発生間隔の増大による遅延時間の増大を抑制することが可能となる。
また、ＵＥは、短縮シンボルでＰＵＣＣＨを送信することになるので、ＰＵＣＣＨの送信時間を短縮することが可能となる。したがって、ＵＥの低消費電力化、および上り干渉電力の低減を図ることが可能となる。
セルは、通常のシンボルと短縮シンボルとを使い分けてもよい。例えば、セルは、ビームスイープ数によって、通常のシンボルとするか、短縮シンボルとするかを決定してもよい。ビームスイープ数が多い場合、短縮シンボルを構成するとよい。このようにすることによって、ビームスイープ数が少ない場合は、短縮シンボルを用いずに済む。したがって、セルおよびＵＥでの設定および処理を容易にすることができる。
他の例として、セルは、各ビームと通信するＵＥ数によって、通常のシンボルとするか、短縮シンボルとするかを決定してもよい。通信するＵＥ数が少ないビームは、短縮シンボルを構成して短縮シンボルを割当てる。通信するＵＥ数が多いビームは、通常のシンボルを割当てる。短縮シンボルにすると、サブキャリア間隔が増大する。これによって、１シンボルに多重できるＵＥ数が通常シンボルに比べて減少する。したがって、通信するＵＥ数が多いビームは、通常のシンボルを割当てることが有効である。
このように、通常のシンボルと短縮シンボルとを使い分けることによって、ビーム構成およびビーム毎の負荷などに応じて、無線リソースの使用効率を向上させることが可能となる。
実施の形態４ 変形例１．
実施の形態４では、ビームスイープ数の増大などによって、ＰＵＣＣＨリソースのために必要となるシンボル数が増大する問題に対する解決方法を開示した。
本変形例では、このような問題を解決するための他の方法を開示する。
１シンボル期間を予め定める数に分割する。以下の説明において、予め定める数に分割した期間を、分割期間と称する場合がある。予め定める数をｎとする。ＵＥは、１シンボル内のＰＵＣＣＨデータタイミングをｎ倍して、１シンボル内でＰＵＣＣＨデータをｎ回リピティションする。このようにして、ＵＥは、ＰＵＣＣＨを送信する。セルは、ビーム切換間隔を短くする。セルは、１シンボル期間を１／ｎにした分割期間でビームを切換えて受信する。
ＵＥは、ＵＥが通信するビームで、１シンボル期間だけＰＵＣＣＨを送信することになるが、セルは、分割期間だけ該ビームでＰＵＣＣＨを受信することになる。複数のビームでＵＥから送信されるＰＵＣＣＨを、各ビームで分割期間だけ受信することになる。このようにすることによって、セルは、１シンボル期間で、複数のビームで送信されるＰＵＣＣＨを分割期間で受信することが可能となる。
１シンボル内のＰＵＣＣＨデータタイミングをｎ倍して、１シンボル内でＰＵＣＣＨデータをｎ回リピティションする方法として、３ＧＰＰで提案されているＩＦＤＭＡ（Interleaved Frequency Domain Multiple Access）ベース方法（参考文献７参照）を用いるとよい。参考文献７では、１シンボル内でデータタイミングが４倍され、１シンボル内でデータが４回リピティションされることが開示されている。
参考文献７では、１シンボルで、一つのＵＥがデータをリピティションして各データでビームを切換えて送信する場合について開示している。セルは、１シンボル期間で同じビームで受信する。本変形例では、１シンボルで、一つのＵＥがデータをｎ回リピティションするが、ビームを切換えることは無い。セルが１シンボル期間を１／ｎにした分割期間でビームを切換えて受信する。セルは、ｎ回リピティションされているうちの一つのデータを受信する。
データタイミングをｎ倍に高速にするために、ｎ個おきに離散的にサブキャリアを使用する。見かけ上ｎ倍のサブキャリアを用いてデータを送るようにすることによって、データタイミングをｎ倍に高速にできる。１シンボル期間内でデータタイミングをｎ倍にしたので、同一データのｎ回のリピティションとなる。ＣＰ（Cyclic Prefix）は、１シンボルの先頭に付加されるとよい。あるいは、１シンボルの最後尾でもよい。あるいは、１シンボルの先頭と最後尾とに付加されてもよい。セルおよびＵＥが共通に認識していればよい。
ＵＥは、ＰＵＣＣＨリソースに設定されたシンボルで、１シンボル期間でｎ回繰返してＰＵＣＣＨ用のデータを送信する。異なるビームのＵＥは、各々、ＰＵＣＣＨリソースに設定されたシンボルで、１シンボル期間でｎ回繰返してＰＵＣＣＨ用のデータを送信する。このときに、異なるビームのＵＥから、同一シンボルでＰＵＣＣＨ用のデータが送信されてもよい。
セルは、１シンボル期間を１／ｎにした分割期間でビームを切換えて受信する。セルは、各ビームのＵＥから送信される、ｎ回リピティションされているうちの一つのＰＵＣＣＨ用データを受信する。このようにすることによって、１つのシンボルに、さらに多くのビームのＰＵＣＣＨリソースを割当てることが可能となる。また、ＤＦＴ（Discrete Fourier Transform）−ｓ（Spread）−ＯＦＤＭを用いることができる。したがって、ＵＥの上りＰＡＰＲ（Peak-to-Average Power Ratio）の低減、およびＵＥの低消費電力化を図ることができる。
ＰＵＣＣＨのためのリソースの設定方法について開示する。実施の形態２で開示したＰＵＣＣＨリソースに関する情報の他に、分割期間に関する情報を設ける。
分割期間に関する情報の具体例として、以下の（１）〜（７）の７つを開示する。
（１）１シンボル内の分割数。
（２）周波数範囲を何倍にするか。
（３）周波数リソース。
（４）データ繰り返し数。
（５）ＣＰ挿入方法。
（６）ＣＰ挿入位置。
（７）前記（１）〜（６）の組合せ。
セルは、ＵＥに対して、分割期間に関する情報を通知する。また、セルは、ＵＥに対して、ＰＵＣＣＨリソースに関する情報を通知してもよい。セルは、ＵＥに対して、分割期間に関する情報と、ＰＵＣＣＨリソースに関する情報とを組合せて通知してもよい。
セルは、ＵＥに対して、分割期間に関する情報を、対応するＰＵＣＣＨリソースに関する情報とともに、あるいは、対応するＰＵＣＣＨリソースに関する情報に含めて通知してもよい。
また、分割期間の他に、分割ではない通常のシンボルにＰＵＣＣＨリソースを設定してもよい。この場合、通常のシンボル用と、分割シンボル用とで、ＰＵＣＣＨリソースに関する情報を別に設けてもよい。
ＰＵＣＣＨのためのリソースの割当方法については、実施の形態２から実施の形態３の方法を適宜適用するとよい。また、分割期間に関する情報あるいは対応するＰＵＣＣリソースに関する情報の通知方法は、各実施の形態あるいは変形例で開示した方法を適用すればよい。
このようにすることによって、より多くのビームスイープ数が必要となるセルあるいはＴＲＰにおいても、一つのサブフレーム内でより多くのビームのＰＵＣＣＨリソースを構成することが可能となる。したがって、データ用のリソースの低減による通信速度の低下、およびビーム毎のＰＵＣＣＨリソースの発生間隔の増大による遅延時間の増大を抑制することが可能となる。
セルは、通常のシンボルと分割シンボルとを使い分けてもよい。実施の形態４で開示した方法を適用するとよい。これによって、ビーム構成およびビーム毎の負荷などに応じて、無線リソースの使用効率を向上させることが可能となる。
実施の形態５．
ＳＲを受信したセルは、ＳＲに対する応答信号として上りグラントを送信する。３ＧＰＰでは、ビームスイーピングを必要とするＭＢＦにおける、ＳＲに対する上りグラントの送信タイミングに関しては何ら議論されていない。ビームスイーピングを行う必要がある場合、各ビームのタイミングは限られる。したがって、セルとＵＥとで、ＳＲに対する上りグラントの送信タイミングの認識を合わせておく必要が生じる。
本実施の形態では、ＳＲに対する応答信号の送受信タイミングについて開示する。
ＵＥからＳＲを送信した後、ＳＲを受信したセルが、上りグラントをＵＥに対して送信するタイミングを非同期とする。セルは、ＳＲを送信したＵＥのサービングビームで、該ＳＲに対する上りグラントをＵＥに対して任意のタイミングで送信する。ＵＥは、ＳＲを送信した後、毎サブフレームＬ１／Ｌ２制御信号を受信する。
たとえ、セルがＳＲの受信から上りグラントの送信タイミングまで他のビームで送受信を行っているとしても、ＵＥは、毎サブフレームＬ１／Ｌ２制御信号を受信する。セルが他のビームで送受信を行っている場合、ＵＥは、Ｌ１／Ｌ２制御信号を受信できないので、上りグラントが無いと判断できる。このようにすることによって、任意のタイミングで送信される上りグラントをＵＥは受信することが可能となる。
セルは、ＳＲを受信したビームで該ＳＲに対する上りグラントを送信するタイミングを決定する。決定するために用いる指標例として、実施の形態２で開示したＰＵＣＣＨリソース割当ての判断指標例を適用するとよい。
このように、ＳＲに対する上りグラントの送信タイミングを非同期にすることによって、前述の判断指標のような状況に応じて、セルは、上りグラントの送信タイミングを決定できる。また、たとえ非同期であったとしても、ＵＥは、送信したＳＲに対する上りグラントを受信することが可能となり、上り通信を開始できる。
ＳＲに対する上りグラントの送受信タイミングの他の方法について開示する。
ＳＲに対する上りグラントを送信するタイミングを非同期にした場合、ＵＥは、ＳＲを送信した後、毎サブフレームＬ１／Ｌ２制御信号を受信しなければならない。しかし、ビームスイーピングを必要とするＭＢＦでは、他のビームで送受信を行っているタイミングがあるので、ＵＥが毎サブフレーム受信するのは無駄になるという問題が生じる。
このような問題を解決する方法を開示する。
ＳＲに対する上りグラントの送信タイミングをＮ＋Ｌとする。Ｎは、ＳＲ送信タイミングを示す。Ｌは、０以上の一つの値を示す。Ｎ，Ｌは、スケジュール単位で表すとよい。例えば、サブフレーム単位、スロット単位、あるいはミニスロット単位などである。
このようにすることによって、ＵＥが毎サブフレームＬ１／Ｌ２制御信号を受信しなくて済む。したがって、無駄な受信動作を行わなくて済むので、ＵＥの消費電力の低減を抑制することが可能となる。
他の方法について開示する。
前述に開示した方法では、Ｌを一つの値とした。Ｌを複数の値としてもよい。例えば、Ｌ１、Ｌ２、Ｌ３、・・・として、セルは、ＵＥに対してＳＲに対する複数のタイミングを設定する。Ｌの数の最大値を決めておいてもよい。
Ｌの値を設定する範囲（期間）を決めておいてもよい。例えば、Ｌの値を設定する範囲（期間）をＫとする。例えば、サブフレーム単位の場合、Ｋサブフレーム期間内でＬの値を設定する。Ｋサブフレーム過ぎた場合、さらにＫの期間の設定が繰り返し行われるとしてもよい。例えば、Ｋ＝６、Ｌ＝１，３と設定する。
Ｋの期間の起点として、Ｎを起点としてもよい。あるいはオフセット値を設けて、Ｎからオフセット後を起点として設定してもよい。
前述の例では、Ｎを起点とする場合、Ｎを起点に６サブフレーム毎に、Ｌ＝１，３の設定が繰り返される。
Ｎを起点に、Ｎ＋０〜Ｎ＋（Ｋ−１）サブフレームの期間において、最初のサブフレームからＬ＋１番目のサブフレームに設定される。
ここでは、Ｎ＋１、Ｎ＋３番目のサブフレームでＳＲに対する上りグラントの送信タイミングが設定される。Ｋ＝６を過ぎた場合、さらにＫの期間の設定が繰り返し行われるとしてもよい。
このように複数の値を設定することによって、セルがＳＲに対する上りグラントの送信タイミングを選択することが可能となる。セルは、設定した複数のタイミングの全てで上りグラントを送信する必要はない。他のビームの送受信を行ってもよい。セルは、ビーム毎の状況に応じて、ＳＲに対する上りグラントの送信タイミングを決定することが可能となる。
ＵＥは、設定された複数のタイミングでＬ１／Ｌ２制御信号を受信する。
このようにすることによって、非同期の場合に比べて、ＵＥの低消費電力化を図ることができるとともに、セルの状況にさらに適した送信タイミングとすることが可能となる。したがって、セルとしての無線リソースの使用効率を向上させることが可能となる。
他の方法について開示する。
Ｌの値の設定として、偶数と奇数とに分けて設定してもよい。Ｌを偶数（０を含めてもよい）とした場合、Ｎを起点に偶数番目のサブフレームでＳＲに対する上りグラントの送信タイミングが発生する。Ｌを奇数とした場合、Ｎを起点に奇数番目のサブフレームでＳＲに対する上りグラントの送信タイミングが発生する。
セルは、設定したＮ＋Ｌのタイミングから選択して、ＳＲに対する上りグラントを送信する。セルは、Ｎ＋Ｌのタイミング全てで上りグラントを送信する必要はない。他のビームの送受信を行ってもよい。セルは、ビーム毎の状況に応じて、ＳＲに対する上りグラントの送信タイミングを決定することが可能となる。
ＵＥは、偶数または奇数に設定されたＬに応じて、Ｎ＋ＬのタイミングでＬ１／Ｌ２制御信号を受信する。このようにすることによって、非同期の場合に比べて、ＵＥの消費電力を半分に低減することが可能になるとともに、セルの状況にさらに適した送信タイミングとすることが可能となる。したがって、セルとしての無線リソースの使用効率を向上させることが可能となる。
Ｌを偶数と奇数とで設定することを開示したが、同様に、Ａの剰余で設定してもよい。Ａを１以上の整数とする。Ｌを、０、１、２、・・・、あるいは（Ａ−１）で設定する。例えば、Ａ＝６のとき、Ｌを、０、１、２、３、４、あるいは５として設定する。
この場合、Ｎ＋（Ａ×（ｎ−１）＋Ｌ）で送信タイミングが発生することになる。
セルは、設定したタイミングから選択して、ＳＲに対する上りグラントを送信する。セルは、設定したタイミング全てで上りグラントを送信する必要はない。他のビームの送受信を行ってもよい。セルは、ビーム毎の状況に応じて、ＳＲに対する上りグラントの送信タイミングを決定することが可能となる。
ＵＥは、設定されたＬに応じて、設定されたタイミングでＬ１／Ｌ２制御信号を受信する。このようにすることによって、非同期の場合に比べて、ＵＥの消費電力を半分に低減することが可能になるとともに、セルの状況にさらに適した送信タイミングとすることが可能となる。したがって、セルとしての無線リソースの使用効率を向上させることが可能となる。
Ｎを起点にしたタイミングで設定することを開示したが、セルとして与えられているサブフレーム番号で設定してもよい。どのビームで送受信を行うかがサブフレーム番号で与えられるような場合に有効である。
他の方法について開示する。
ＳＲに対する上りグラントを送信しない期間をＬとして設定してもよい。セルは、Ｎ＋Ｌより後の任意のタイミングで、ＳＲに対する上りグラントを送信する。ＵＥは、Ｎ＋Ｌより後のタイミングで、Ｌ１／Ｌ２制御信号を受信する。
例えば、セルによる処理時間をｎとして、Ｌ＞ｎとして設定する。この場合、セルは、ＮからＮ＋Ｌまでのタイミングで、ＳＲに対する上りグラントの送信を行わない。セルは、Ｎ＋Ｌより後の任意のタイミングで、ＳＲに対する上りグラントの送信を行う。ＵＥは、ＮからＮ＋Ｌまでのタイミングで、Ｌ１／Ｌ２制御信号の受信を行わない。ＵＥは、Ｎ＋Ｌより後のタイミングで、Ｌ１／Ｌ２制御信号を受信する。
サブフレーム単位の場合、セルは、ＮからＮ＋Ｌまでのサブフレームで、ＳＲに対する上りグラントの送信を行わない。セルは、Ｎ＋Ｌより後の任意のサブフレームで、ＳＲに対する上りグラントの送信を行う。ＵＥは、ＮからＮ＋Ｌまでのサブフレームで、Ｌ１／Ｌ２制御信号の受信を行わない。ＵＥは、Ｎ＋Ｌより後の毎サブフレームで、Ｌ１／Ｌ２制御信号を受信する。
このようにすることによって、ＵＥは、ＳＲを送信した後、いくつかのサブフレームのＬ１／Ｌ２制御信号の受信を行わなくて済むようになる。
さらに、Ｎ＋Ｌより後の受信期間を設定してもよい。該受信期間をＷとする。セルは、Ｎ＋Ｌより後のＷの期間で、任意のタイミングでＳＲに対する上りグラントを送信する。ＵＥは、Ｎ＋Ｌより後のＷの期間で、タイミングでＬ１／Ｌ２制御信号を受信する。
このようにすることによって、ＵＥは、ＳＲを送信した後、いくつかのサブフレームのＬ１／Ｌ２制御信号の受信を行わなくて済むようになるとともに、さらに、Ｎ＋Ｌより後のＷの期間だけ、Ｌ１／Ｌ２制御信号を受信すればよくなる。したがって、さらにＵＥの低消費電力化を図ることができる。
このようにすることによって、ＵＥの低消費電力化を図りつつ、セルは、セルの状況に適した送信タイミングとすることが可能となる。したがって、セルとしての無線リソースの使用効率を向上させることが可能となる。
他の方法について開示する。
予めＵＥに対して下りスケジューリングが行われるタイミングが決められている場合は、それに従うこととする。ＳＲの送信以降の該下りスケジューリングが行われるタイミングで、Ｌ１／Ｌ２制御信号を受信する。予めＵＥに対して、下りスケジューリングが行われるタイミングを設定する方法は、実施の形態１で開示した方法を適用するとよい。
このようにすることによって、ＳＲに対する上りグラントだけでなく、通常のスケジューリングと統一した方法を用いることが可能となる。したがって、セルおよびＵＥでの処理を容易にすることができる。
前述に開示した方法において、セルがＵＥに対して設定する情報（以下「ＳＲ応答に関する情報」と称する場合がある）の設定方法および通知方法について開示する。
システムとして固定としてもよい。予め静的に規格などで決めておくとよい。
他の方法として、セル毎およびビーム毎の少なくとも一方に設定してもよい。セルからＵＥに対して通知する方法は、実施の形態２で開示したビーム毎のＰＵＣＣＨリソースに関する情報を通知する方法と同様にしてもよい。例えば、セル毎の情報として、システム情報に含めて報知してもよいし、あるいは、ＲＲＣメッセージに含めてＵＥ個別に通知してもよい。
他の方法として、ＵＥ毎に設定してもよい。セルからＵＥに対して通知する方法は、実施の形態２で開示したＵＥ毎のＰＵＣＣＨリソースに関する情報を通知する方法と同様にしてもよい。例えば、ＵＥ毎の情報として、ＲＲＣメッセージに含めてＵＥ個別に通知してもよい。
これらの設定方法および通知方法を組合せて行ってもよい。ＳＲ応答に関する情報毎にこれらの方法を使い分けてもよい。例えば、剰余を用いる場合、Ａはシステムとして固定とし、ＬはＵＥ毎に設定するなどである。あるいは、Ｋはセル毎に設定し、Ｌはビーム毎に設定するなどである。このようにすることによって、セルはＵＥに対して、ＳＲに対する上りグラントが発生するタイミングを通知することが可能となる。
他の方法について開示する。
セルおよびＵＥは、ＳＲを送信したＵＥのＵＥ識別子を用いて、ＳＲに対する上りグラントを送信するタイミングを導出する。例えば、ＳＲに対する上りグラントを送信するタイミングをＮ＋Ｌとする場合、ＳＲを送信したＵＥの識別子を用いてＬを導出する。例えば、該ＵＥの識別子が奇数である場合、Ｌは奇数とする。該ＵＥの識別子が偶数である場合、Ｌは偶数とする。
ＵＥの識別子ではなく、ビームの識別子を用いてもよい。セルおよびＵＥは、ＳＲを送信したＵＥが通信しているビームの識別子を用いて、ＳＲに対する上りグラントを送信するタイミングを導出する。例えば、ＳＲに対する上りグラントを送信するタイミングをＮ＋Ｌとする場合、ＳＲを送信したＵＥが通信を行っているビームの識別子を用いてＬを導出する。例えば、該ビームの識別子が奇数である場合、Ｌは奇数とする。該ビームの識別子が偶数である場合、Ｌは偶数とする。
このようにすることによって、セルがＵＥに対してＳＲ応答に関する情報を設定しなくてもよい。したがって、シグナリングの負荷の削減を図ることができる。
図２４は、ＳＲに対する上りグラントの送受信タイミング設定のシーケンスの一例を示す図である。図２４に示すシーケンスは、図１９に示すシーケンスと同一のステップを含んでいるので、同一のステップについては同一のステップ番号を付して、共通する説明を省略する。
ステップＳＴ２８０１において、セルは、ＵＥに対して、ＵＥ毎のＰＵＣＣＨリソース構成を設定する。
ステップＳＴ３２０１において、セルは、ＵＥに対して、ＵＥに対するＳＲ応答タイミングを設定する。
ステップＳＴ３２０２において、セルは、ＵＥに対して、ＰＵＣＣＨリソースに関する情報とともに、ＳＲ応答に関する情報を通知する。ＰＵＣＣＨリソースに関する情報およびＳＲ応答に関する情報は、ＵＥと通信するビームを介して通知するとよい。前記ＰＵＣＣＨリソースに関する情報およびＳＲ応答に関する情報の通知には、ＲＲＣ個別シグナリングを用いる。
セルは、ステップＳＴ３２０２の処理を行った後は、ステップＳＴ２８０４、ステップＳＴ２８０５およびステップＳＴ２８０６の処理を行う。
ステップＳＴ３２０２でＰＵＣＣＨリソースに関する情報およびＳＲ応答に関する情報を受信したＵＥは、ステップＳＴ２８０３の処理を行う。その後、ＵＥは、ステップＳＴ２８１３の処理を行う。
ステップＳＴ２８１１において、ＵＥは、上りデータが発生したか否かを判断し、上りデータが発生している場合は、ステップＳＴ２８１２に移行する。
ステップＳＴ２８１２Ａにおいて、ＵＥは、設定されたＳＲ用ＰＵＣＣＨリソース構成でＳＲを、サービングビームを介してセルに対して送信する。
ステップＳＴ２８１２ＡでＵＥからのＳＲを受信したセルは、ステップＳＴ３２０３において、ＵＥに対して設定したＳＲ応答タイミングで上りスケジューリングを行う。
ステップＳＴ２８１２でＳＲを送信したＵＥは、ステップＳＴ３２０４において、ＳＲ応答に関する情報を用いて、ＳＲ応答タイミングを導出し、ＳＲ応答タイミングで受信を行う。
ステップＳＴ２５１１において、セルは、ＵＥに対して設定したＳＲ応答タイミングで上りグラントを通知する。
ステップＳＴ２５１１において、ＵＥは、設定されたＳＲ応答タイミングで、セルから上りグラントを取得する。
このようにしてセルからＳＲに対する上りグラントを受信したＵＥは、ステップＳＴ２５１２からステップＳＴ２５１４において、セルとの間で上り通信開始のための処理を行う。これによって、ＵＥとセルとの間で上り通信が開始される。
本実施の形態で開示した方法を用いることによって、セルは、ＵＥに対して、ＳＲ応答に関する情報を通知することが可能となり、セルとＵＥとでＳＲに対する上りグラントの送信タイミングの認識を合わせることが可能となる。
実施の形態６．
ＳＲの送信が不達となった場合、セルは、ＵＥに対して、ＳＲに対する上りグラントを送信しない。あるいは、セルがＵＥに対して上りグラントを送信したとしても、電波伝搬環境が悪く、ＵＥが受信できない場合がある。これらの場合、ＵＥは、ＳＲの送信が不達のために上りグラントが送信されないのか、あるいはセルが他のビームで通信を行っているためにサービングビームで通信できず、ＳＲに対する上りグラントを送信していないのかの判断がつかない。
したがって、ＵＥは、ＳＲ応答タイミングでＳＲに対する上りグラントを受信するので、Ｌ１／Ｌ２制御信号を受信し続けることになる。３ＧＰＰでは、ビームスイーピングを必要とするＭＢＦにおける、ＳＲの送信不達については、何ら議論されていない。
本実施の形態では、このような問題を解決する方法を開示する。
ＳＲの送信から上りグラントを待つ期間を設定するタイマを設ける。以下の説明において、前記タイマを「ＳＲ応答待機タイマ」と称する場合がある。ＵＥは、ＳＲの送信でＳＲ応答待機タイマを起動し、ＳＲ応答待機タイマが満了する前に上りグラントを受信した場合、ＳＲ応答待機タイマをリセットする。ＵＥは、ＳＲ応答待機タイマの期間中に上りグラントを受信できず、ＳＲ応答待機タイマが満了した場合、ＳＲの再送を行う。
ＳＲ応答待機タイマの値は、予め規格などで決めておいてもよいし、セルが設定してＵＥに対して通知してもよい。実施の形態５で開示したＳＲ応答に関する情報の通知方法を適用してもよい。ＳＲ応答待機タイマとして、時間単位であってもよいし、スケジューリング単位であってもよい。スケジューリング単位の例としては、例えば、サブフレーム、スロット、ミニスロットなどがある。
このようにすることによって、ＵＥは、セルがＳＲを送信した場合に、ＳＲ応答待機タイマ期間内でＳＲに対する上りグラントを送信すると仮定することが可能となる。これによって、ＵＥは、ＳＲ応答待機タイマが満了した場合、ＳＲの送信が不達として、再度ＳＲを送信することが可能となる。したがって、ＵＥは、セルが他のビームで通信を行っているかどうかの判断がつかず、ＳＲ応答タイミングでＬ１／Ｌ２制御信号を受信し続けることが無くなる。
ＳＲ応答タイミングは、ビーム毎あるいはＵＥ毎に設定される場合がある。したがって、ＳＲ応答タイミングは、ビーム毎あるいはＵＥ毎に異なる場合がある。この場合、ＳＲ応答待機タイマの値をＳＲの送信からの期間として設定すると、ビーム毎あるいはＵＥ毎に異なった値を設定しなければならず、設定が複雑になるという問題が生じる。
このような問題を解決する方法を開示する。
ＳＲ応答待機タイマを、ＳＲに対する上りグラントの送信タイミングの発生回数で設定する。例えばＸ回と設定する。ＵＥは、ＳＲの送信でＳＲ応答待機タイマを起動し、ＳＲに対する上りグラントの送信タイミングの発生回数がＸ回以内に上りグラントを受信した場合、ＳＲ応答待機タイマをリセットする。ＵＥは、ＳＲに対する上りグラントの送信タイミングの発生回数がＸ回以内に上りグラントを受信しなかった場合、ＳＲの再送を行う。
実施の形態５で開示した、ＳＲに対する上りグランントの送信発生タイミングの設定において、Ｌの値を設定する範囲（Ｋ）を決めるような場合、ＳＲ応答待機タイマを、Ｋの繰返し回数で設定してもよい。例えばＸ回と設定する。ＵＥは、ＳＲ送信でＳＲ応答待機タイマを起動し、Ｋの繰返し回数がＸ回以内に上りグラントを受信した場合、ＳＲ応答待機タイマをリセットする。ＵＥは、Ｋの繰返し回数がＸ回以内に上りグラントを受信しなかった場合、ＳＲの再送を行う。
このようにすることによって、上りグラントの発生回数に応じて、ＳＲ応答待機タイマを設定することが可能となる。したがって、ビーム毎、ＵＥ毎に、上りグラントの発生回数に応じて、均等な機会で設定するときに、異なるタイマ値で設定しなくて済む。これによって、セルからＵＥに対するＳＲ応答待機タイマの設定および通知の処理を容易にすることが可能となる。
前述の方法の場合、ＵＥが、セルからＳＲに対する上りグラントを受信できなかった場合、ＳＲの再送を続けて行うことになる。例えば、ＵＥが通信を行うビームで上り同期がはずれた場合、セルは、ＵＥからのＳＲの送信を受信できなくなる。このような状態が続くと、ＵＥが何度ＳＲを再送したとしても、セルは、ＵＥからのＳＲの送信を受信することができず、ＳＲに対する上りグラントは送信されないことになる。したがって、ＵＥは、ＳＲの再送を繰り返すことになる。
このような問題を解決する方法を開示する。
ＳＲの再送に最大回数を設けるとよい。例えばＹ回と設定する。ＳＲの再送がＹ回を超えた場合、ＵＥはＳＲの再送を停止する。このようにすることによって、ＵＥの移動、および電波伝搬環境の悪化などによって、ＵＥがＳＲを再送し続けることを回避することができる。したがって、ＵＥの低消費電力化を図ることができる。
ＳＲの再送がＹ回を超えた場合、ＲＡ処理から開始するとしてもよい。ＲＡ処理によって上り同期が行われる。ＲＡ処理は、ビームスイーピングブロックを用いてもよい。このようにすることによって、ＵＥは、再度ＵＥが通信を行うビームで上り同期を得ることが可能となる。
ＳＲの再送がＹ回を超えた場合、ＵＥに対して設定されているＰＵＣＣＨリソース設定、ＳＲ応答設定、ＳＲ不達設定をリセットしてもよい。リセットすることによって、設定されていたリソースを他に開放できるので、無線リソースの使用効率を向上させることができる。
実施の形態７．
ＭＢＦでのビームカバレッジは、セルのカバレッジより狭域になる。また、ＭＢＦにおいてビームスイーピングが必要な場合、ＵＥがＳＲを送信してからＳＲに対する上りグラントを受信するまでの間に、セルは、他のビームでの通信を行う場合がある。この場合、ＳＲの送信からＳＲ応答信号の受信タイミングまでの期間は、ビームスイーピングが不要な場合に比べて長くなる。
したがって、ＵＥがＳＲを送信してからＳＲ応答信号を受信するまでに、ビームカバレッジを跨いだ移動が発生する場合がある。いわゆるビーム間の移動（モビリティ）が行われる場合がある。セルは、一つまたは複数のＴＲＰを構成し、ＴＲＰは、一つまたは複数のビームを構成する。ここでは、主として、ビーム間の移動について記載するが、ＴＲＰ間の移動にも適用可能である。
ＴＲＰが構成するビーム間の移動に適用するとよい。また、ＤＵ（Distributed Unit）が一つまたは複数のビームを構成する場合がある。このような場合のＤＵ間の移動にも適用可能である。ＤＵが構成するビーム間の移動に適用するとよい。
実施の形態５では、ＵＥがＳＲの送信を行ったビームにおいてＳＲ応答信号を受信するタイミングの設定方法について開示した。しかし、ＵＥがＳＲの送信を行った後に、ビーム間の移動が発生した場合は、ＳＲの送信を行ったビームからＵＥが移動しているので、実施の形態５の方法を単純に適用することはできない。そのような場合に、セルとＵＥとの間でＳＲ応答信号をどのように送受信するかが問題となる。
本実施の形態では、このような問題を解決する方法を開示する。
ＳＲの送信後、ＵＥにビーム間の移動が発生した場合、ＵＥがＳＲの送信を行ったビームでそのままＳＲに対する上りグラントを待っていても、該ビームでのＵＥの通信品質は悪化するので、上りグラントを受信できなくなる場合が発生する。ここでは、このような問題を解決する方法を開示する。
ＵＥは、ＳＲの送信後にビーム間の移動が発生した場合、送信したＳＲに対する上りグラントを、移動先のビームで受信する。セルは、ＵＥからのＳＲを受信した後、受信したＳＲに対する上りグラントを、ＵＥの移動先のビームでＵＥに対して送信する。このようにすることによって、ＵＥにとって通信品質の良いビームで、ＳＲ応答信号の送受信を行うことができる。したがって、ＵＥにおけるＳＲ応答信号の受信誤り率を低減させることが可能となる。
ＳＲに対する上りグラントの送信タイミングについて開示する。
移動元のビームで送信されたＳＲに対する上りグラントを移動先のビームで送信する場合、ビームが異なるので、移動先ビームでの上りグラントの送信タイミングの設定が問題となる。例えば、移動元ビーム（以下「ソースビーム（S-beam）」と称する場合がある）の設定をそのまま用いるのか、移動先ビーム（以下「ターゲットビーム（T-beam）」と称する場合がある）で新たに設定するのか、新たに設定する場合の設定方法はどうするのか、などの問題が生じる。
ここでは、このような問題を解決する方法を開示する。
ＳＲに対する上りグラントの送信タイミングが、システムで固定、あるいはセル毎にセル内の全ビームで同一に設定されている場合、ＵＥは、ビーム間の移動後も該設定に従うとよい。ＳＲの送信タイミングを起点にするとよい。また、ＳＲに対する上りグラントの送信タイミングが、セル内の複数のビームで同一に設定されてもよい。ＳＲに対する上りグラントの送信タイミングは、ＳＲの送信タイミングを起点にするとよい。
電波伝搬状況の急激な悪化に対抗するために、ＵＥが複数のビームの物理制御チャネルを受信することが提案されている。そのような複数のビームでビームグループを設けてもよい。ＵＥは、通信しているビームの電波伝搬状況の急激な悪化によるビームの移動先をビームグループとしてもよい。例えば、前述のビームグループで、ＳＲに対する上りグラントの送信タイミングを同一に設定してもよい。
このようにすることによって、ＵＥは、ビーム間移動後のターゲットビームでのＳＲ応答信号を受信することが可能となる。また、ＵＥは、ビーム間の移動後もＳＲ応答信号の受信タイミングを変更することが無くなるので、ビーム間移動の処理を簡易にすることが可能となる。
ＳＲ応答信号の送信タイミングが、ＳＲの送信タイミングを起点にすることを開示したが、他の方法として、ＵＥのビーム間の移動あるいはセルからＵＥへのビーム間移動指示のタイミングを起点に、ＳＲ応答信号のタイミングを決定してもよい。
このようにすることによって、ソースビームでのＳＲ送信タイミングをターゲットビームで不要とすることができる。また、ビーム間移動指示のタイミングを起点にするので、新たな情報を通知する必要もない。したがって、ＵＥおよびビーム間で要する処理を簡易にすることが可能となる。
ＳＲに対する上りグラントの送信タイミングが、ビーム毎に、あるいは、ビーム毎にＵＥ毎に設定されている場合の方法について開示する。ビーム毎に設定されている場合、セルは、ＵＥに対して、予め、セル内の全ビームあるいは複数のビームのＳＲに対する上りグラントの送信タイミングを設定する。ビーム毎にＵＥ毎に設定されている場合、セルは、ＵＥに対して、予め、ターゲットビームあるいは複数のビームのＵＥ毎のＳＲに対する上りグラントの送信タイミングを設定する。
複数のビームとしては、前述のビームグループとしてもよい。ターゲットビームとなる可能性のある複数のビームのグループとしてもよい。
ＵＥは、ビーム間の移動後に、ターゲットビームのＳＲに対する上りグラントの送信タイミングを用いて受信する。セルは、ＵＥがビーム間を移動した後、ターゲットビームのＳＲに対する上りグラントの送信タイミングを用いて送信する。
このようにすることによって、ＵＥは、ビーム間移動後のターゲットビームでのＳＲ応答信号を受信することが可能となる。
ＵＥのビーム間の移動において、セルからＵＥに対して移動指示が通知される場合は、ＵＥは、セルからビーム間の移動指示を受信した後、ターゲットビームのＳＲに対する上りグラントの送信タイミングを用いて受信するとしてもよい。また、セルは、ＵＥにビーム間の移動指示を送信した後、ターゲットビームのＳＲに対する上りグラントの送信タイミングを用いて送信するとしてもよい。
ここで、ＳＲに対する上りグラントの送信タイミングが、ＳＲの送信タイミングを起点にする場合、ソースビームでのＳＲの送信タイミングを起点とするとよい。このようにすることによって、セルおよびＵＥは、ＳＲに対する上りグラントの送信タイミングを特定することが可能となる。ＵＥは、該送信タイミングで受信することによって、セルが該送信タイミングで送信したＳＲ応答信号を受信することが可能となる。
ソースビームでのＳＲの送信タイミングからＳＲ応答信号の受信タイミングまでの期間よりも、ターゲットビームでのＳＲの送信タイミングからＳＲ応答信号の受信タイミングまでの期間が長い場合、ＵＥのビーム間の移動前に、ターゲットビームでのＳＲ応答信号の受信タイミングが終わっていることがある。このような場合、セルは、ターゲットビームのＳＲ応答信号の送信タイミングで上りグラントを送信してしまった場合、ＵＥは、ＳＲに対する上りグラントを受信できなくなる。
このような問題を解決する方法を開示する。
ＳＲに対する上りグラントの送信タイミングについて、ＵＥのビーム間の移動時は、ソースビームでのＳＲに対する上りグラントの送信タイミングに従う。ＳＲを送信したＵＥが、ＳＲに対する上りグラントを受信する前に移動指示を受信した場合、ＵＥは、ソースビームでのＳＲの送信タイミングを起点に、ソースビームで設定された上りグラントの送信タイミングで受信する。
セルは、ＳＲを送信したＵＥに対して、ＳＲに対する上りグラントを送信する前にビーム間の移動を指示した場合、該ＵＥに対するＳＲに対する上りグラントの送信タイミングを、ソースビームでのＳＲの送信タイミングを起点に、ソースビームで設定された上りグラントの送信タイミングで送信する。このようにすることによって、ＵＥがビーム間を移動した場合でも、ＳＲ応答信号のタイミングをソースビームでのＳＲに対する上りグラントの送信タイミングに設定できるので、ＵＥのビーム間の移動前に、ＳＲ応答信号の受信タイミングが終わってしまうようなことはなく、ＵＥは、ターゲットビームでＳＲ応答信号を受信することが可能となる。
他の方法を開示する。
ＳＲに対する上りグラントの送信タイミングについて、ＵＥのビーム間の移動時は、ＳＲの送信からＳＲに対する上りグラントの送信タイミングまでが長い方に従う。セルは、ＵＥに対して、予め、セル内の全ビームあるいは複数のビームのＳＲ応答信号の受信タイミングを設定する。複数のビームとしては、前述のビームグループとしてもよい。
ＳＲを送信したＵＥが、ＳＲに対する上りグラントを受信する前に移動指示を受信した場合、ＵＥは、ソースビームでのＳＲの送信からＳＲに対する上りグラントの受信タイミングまでの期間と、ターゲットビームでのＳＲの送信からＳＲに対する上りグラントの受信タイミングまでの期間とを比較して、長い方のＳＲに対する上りグラントの受信タイミングを選択して設定し、該タイミングで受信する。
セルは、ＳＲを送信したＵＥに、ＳＲに対する上りグラントを送信する前にビーム間の移動指示を送信した場合、ソースビームでのＳＲの送信からＳＲに対する上りグラントの送信タイミングまでの期間と、ターゲットビームでのＳＲの送信からＳＲに対する上りグラントの送信タイミングまでの期間とを比較して、長い方のＳＲに対する上りグラントの送信タイミングを選択して設定し、該タイミングで送信する。
このようにすることによって、ＵＥがビーム間を移動した場合でも、ＳＲ応答信号のタイミングを長い方のＳＲに対する上りグラントの送信タイミングに設定できるので、ＵＥのビーム間の移動前に、ＳＲ応答信号の受信タイミングが終わってしまうようなことはなく、ＵＥは、ターゲットビームでＳＲ応答信号を受信することが可能となる。
他の方法を開示する。
ＵＥは、ビーム間の移動、あるいはセルからのビーム間移動指示の受信で、ソースビームでのＳＲ応答信号のタイミングをリセットする。
ＵＥは、ビーム間の移動、あるいはセルからのビーム間移動指示の受信のサブフレームを起点（Ｎ）として、ターゲットビームのＳＲ応答信号のタイミングで受信する。セルは、ＵＥのビーム間移動、あるいはビーム間移動指示の送信のサブフレームを起点（Ｎ）として、ターゲットビームでのＳＲ応答信号のタイミングで送信する。
このようにすることによって、ＵＥがビーム間移動したことを起点にＳＲ応答信号のタイミングを設定できるので、ＵＥのビーム間の移動前に、ターゲットビームでのＳＲ応答信号の受信タイミングが終わるようなことはなく、ＵＥは、ターゲットビームでＳＲ応答信号を受信することが可能となる。
ＳＲに対する上りグラントの送信タイミングが、ビーム毎に、あるいは、ビーム毎にＵＥ毎に設定されている場合の他の方法について開示する。セルは、ＵＥへの移動指示とともに、ターゲットビームでのＳＲ応答信号のタイミングを設定する。セルは、ターゲットビームでのＳＲ応答信号のタイミングを設定し、ＵＥに、ビーム間移動指示を送信するとともに、該ＳＲ応答信号のタイミングを通知する。セルは、ＵＥへのビーム間移動指示の送信で、ソースビームでのＳＲ応答信号のタイミングをリセットし、ターゲットビームでのＳＲ応答信号のタイミングで送信する。
ＵＥは、セルからビーム間移動指示を受信するとともに、ターゲットビームでのＳＲ応答信号のタイミングを受信する。ＵＥは、セルからのビーム間移動指示の受信で、ソースビームでのＳＲ応答信号のタイミングをリセットし、ターゲットビームでのＳＲ応答信号のタイミングで受信する。
セルは、ＵＥがターゲットビームに移動した後、新たにＳＲ応答信号のタイミングを設定してもよい。
このようにすることによって、ソースビームでのＳＲ送信タイミングをターゲットビームで不要とすることができる。したがって、ビーム間で要する処理を簡易にすることが可能となる。
ＳＲに対する上りグラントの送信タイミングが、ビーム毎に、あるいは、ビーム毎にＵＥ毎に設定されている場合の他の方法について開示する。ＵＥに対するビーム間移動指示の送信以降、ターゲットビームでのＳＲ応答信号の送信タイミングをダイナミックにする。セルは、ＵＥに対して、ビーム間移動指示を送信するとともに、ターゲットビームでのＳＲ応答送信のタイミングをダイナミックにする。
ＵＥは、セルからのビーム間移動指示の受信で、ソースビームでのＳＲ応答信号の受信タイミングをリセットする。ＵＥは、セルからのビーム間移動指示を受信した後、ターゲットビームでＳＲ応答信号を連続受信する。例えば、ＳＲ応答信号の送信タイミングがサブフレーム単位の場合、ＵＥは、ターゲットビームでのＳＲ応答信号を毎サブフレーム受信する。セルは、ＵＥに対して、ＵＥがターゲットビームに移動した後、新たにＳＲ応答信号のタイミングを設定してもよい。
このようにすることによって、セルはＵＥに対して、ＵＥのビーム間移動指示を通知するとき、あるいは、ビーム間移動前に予め、ターゲットビームでのＳＲ応答信号の送信タイミングを通知しなくてもよくなる。したがって、シグナリングに必要な情報量を低減することが可能となる。
ＳＲに対する上りグラントの送信タイミングが、ビーム毎に、あるいは、ビーム毎にＵＥ毎に設定されている場合の他の方法について開示する。セルからのＵＥへの移動指示後も、ソースビームのＳＲ応答信号のタイミングが維持される。セルは、ＵＥに対して、ビーム間移動指示を送信した後も、ソースビームのＳＲ応答信号の送信タイミングで送信する。セルは、ＵＥに対して、ビーム間移動指示を送信した後、ソースビームでのＳＲ応答信号の送信タイミング設定を、ターゲットビームでのＳＲ応答信号の送信タイミング設定とする。
ＵＥは、セルからのビーム間移動指示を受信した後も、ソースビームでのＳＲ応答信号の受信タイミングで受信する。ＵＥは、セルからのビーム間移動指示を受信した後、ソースビームでのＳＲ応答信号の送信タイミング設定を、ターゲットビームでのＳＲ応答信号の送信タイミング設定とする。
セルは、ＵＥに対してビームの移動を決定してから、次のソースビームでのＳＲ応答信号の送信タイミングになる前までに、ソースビームでのＳＲ応答信号のタイミング設定を、ターゲットビームに通知する。これは、ソースビームとターゲットビームとが異なるノードによって構成されている場合に有効である。
あるいは、ソースビームがＵＥに対してビームの移動を通知してから、次のソースビームでのＳＲ応答信号の送信タイミングになる前までに、ソースビームを構成するノードがターゲットビームを構成するノードに対して、ソースビームでのＳＲ応答信号のタイミング設定を通知する。これは、ソースビームとターゲットビームとが異なるノードによって構成されており、各ノードがＳＲ応答信号のタイミングを設定する場合に有効である。
前述のノードとして、例えば、ＴＲＰ、ＤＵなどがある。セルは、ＵＥに対して、ＵＥがターゲットビームに移動した後、新たにＳＲ応答信号のタイミングを設定してもよい。
ＳＲに対する上りグラント送信タイミングが、セル内でＵＥ毎に設定されている場合の方法について開示する。ＵＥがビーム間を移動した後も、移動前に設定されたＵＥ毎のＳＲ応答信号のタイミング設定に従う。ＳＲの送信タイミングを起点にＳＲ応答信号のタイミングを決定するとよい。セルは、ＵＥに対して、ＵＥ毎にＳＲ応答信号の受信タイミングを設定する。
ＵＥは、ビーム間を移動した後、あるいはセルからビーム間移動指示を受信した後も、設定されたＵＥ毎のＳＲ応答信号の受信タイミングで受信する。ＵＥは、ビーム間の移動前、あるいはセルからビーム間移動指示を受信する前のＳＲの送信タイミングを起点（Ｎ）として、ＵＥ毎のＳＲ応答信号のタイミングで受信する。
このようにすることによって、ビーム間移動処理とＳＲ応答信号送信タイミング設定処理とを分離することが可能となる。したがって、実運用時の誤動作を低減させることが可能となる。
セルは、ＵＥがビーム間を移動した後、あるいはビーム間移動指示を送信した後も、ＵＥ毎に設定したＳＲ応答信号の送信タイミングで送信する。セルは、ＵＥのビーム間の移動前、あるいはビーム間移動指示を送信する前のＳＲの受信タイミングを起点（Ｎ）として、ＵＥ毎のＳＲ応答信号のタイミングで送信する。
このようにすることによって、ビーム間移動においてＵＥ毎に設定されたＳＲ応答信号タイミングを変更しなくて済む。したがって、ビーム間移動処理を簡易にすることが可能となる。
ＳＲの送信タイミングを起点にすることを開示したが、他の方法として、ＵＥのビーム間の移動あるいはセルからＵＥへのビーム間移動指示のタイミングを起点に、ＳＲ応答信号のタイミングを決定してもよい。ＵＥは、ビーム間の移動、あるいはセルからのビーム間移動指示の受信タイミングを起点（Ｎ）として、ＵＥ毎のＳＲ応答信号のタイミングで受信する。セルは、ＵＥのビーム間の移動、あるいはビーム間移動指示の送信タイミングを起点（Ｎ）として、ＵＥ毎のＳＲ応答信号のタイミングで送信する。
このようにすることによって、ソースビームでのＳＲ送信タイミングをターゲットビームで不要とすることができる。したがって、ビーム間で要する処理を簡易にすることが可能となる。
ＳＲに対する上りグラントの送信タイミングが、ＵＥ毎に設定されている場合の他の方法について開示する。ＳＲに対する上りグラントの送信タイミングが、ビーム毎に、あるいは、ビーム毎にＵＥ毎に設定されている場合の方法を適用してもよい。ＵＥ毎のＳＲに対する上りグラントの送信タイミングの設定が、ＵＥが通信するビームに使用するタイミングを考慮している場合に有効となる。
図２５および図２６は、ＳＲの送信後にビーム間の移動が発生した場合のＳＲに対する上りグラントの送受信タイミング設定のシーケンスの一例を示す図である。図２５と図２６とは、境界線ＢＬ２の位置で、つながっている。図２５および図２６に示すシーケンスは、図２４に示すシーケンスと同一のステップを含んでいるので、同一のステップについては同一のステップ番号を付して、共通する説明を省略する。
ステップＳＴ２８０１において、セルは、ＵＥに対して、ＵＥ毎のＰＵＣＣＨリソース構成を設定する。
ステップＳＴ３２０１において、セルは、ＵＥに対して、ＵＥに対するＳＲ応答タイミングを設定する。
ステップＳＴ３２０２において、セルは、ＵＥに対して、ＰＵＣＣＨリソースに関する情報とともに、ＳＲ応答に関する情報を通知する。ＰＵＣＣＨリソースに関する情報およびＳＲ応答に関する情報は、ＵＥと通信するビームを介して通知するとよい。前記ＰＵＣＣＨリソースに関する情報およびＳＲ応答に関する情報の通知には、ＲＲＣ個別シグナリングを用いる。ここで、ＵＥと通信するビームは、ソースビームである。
セルは、ステップＳＴ３２０２の処理を行った後は、ステップＳＴ２８０４、ステップＳＴ２８０５およびステップＳＴ２８０６の処理を行う。
ステップＳＴ３２０２でＰＵＣＣＨリソースに関する情報およびＳＲ応答に関する情報を受信したＵＥは、ステップＳＴ２８０３の処理を行う。その後、ＵＥは、ステップＳＴ２８１３の処理を行う。
ステップＳＴ２８１１において、ＵＥは、上りデータが発生したか否かを判断し、上りデータが発生している場合は、ステップＳＴ２８１２に移行する。
ステップＳＴ２８１２Ａにおいて、ＵＥは、設定されたＳＲ用ＰＵＣＣＨリソース構成でＳＲを、サービングビームを介してセルに対して送信する。ここで、サービングビームは、ソースビームである。
ステップＳＴ２８１２ＡでＳＲを送信したＵＥは、ステップＳＴ３２０２で通知されたＳＲ応答に関する情報から導出したＳＲ応答タイミングで受信を開始する。
ステップＳＴ２８１２Ａにおいて、セルは、ＵＥからのＳＲを受信する。ＵＥからのＳＲを受信したセルは、ステップＳＴ３２０１で設定したＳＲ応答タイミングで上りスケジューリングを行うための処理を行う。
この間に、ステップＳＴ３３０１において、セルは、下りＣＳＩ−ＲＳを、ソースビームを介してＵＥに対して送信する。
ステップＳＴ３３０１で下りＣＳＩ−ＲＳを受信したＵＥは、ステップＳＴ３３０２において、ＣＳＩ−ＲＳの測定結果を、ソースビームを介してセルに対して報告する。具体的には、ＵＥは、ＣＳＩ−ＲＳの測定結果をＣＳＩとしてセルに報告する。
ここで、セルは、複数のビームでＣＳＩ−ＲＳを送信してもよい。ＵＥは、複数のビームのＣＳＩ−ＲＳの測定結果をセルに通知してもよい。あるいは、ＵＥは、ＣＳＩ−ＲＳの測定結果から、サービングビームよりも受信品質の良いビームを導出し、該ビームの識別子を通知してもよい。これによって、情報量を削減することができる。
ステップＳＴ３３０２において、ＵＥからＣＳＩ報告を取得したセルは、ステップＳＴ３３０３において、ＵＥをターゲットビームに移動させることを決定する。
ステップＳＴ３３０４において、セルは、ＵＥに対して、ソースビームで設定したＳＲ応答タイミングでＳＲ応答を送信することが可能か否かを判断する。
ステップＳＴ３３０４において、セルがＳＲ応答タイミングでＳＲ応答を送信可能と判断した場合は、ステップＳＴ３３０５に移行する。
ステップＳＴ３３０５において、セルは、ＵＥに対して、ターゲットビームへの移動指示を通知する。ターゲットビームへの移動指示として、ターゲットビームのビーム識別子を含ませてもよい。移動指示の通知には、Ｌ１／Ｌ２制御シグナリングを用いてもよい。あるいは、ＭＡＣシグナリングを用いてもよい。ＭＡＣシグナリングを用いることによって、ＲＲＣシグナリングで通知するよりも、セルは、ＵＥに対して、より低遅延でビームの移動指示を通知することができる。該移動指示とともに、ＳＲ応答タイミングへの変更指示は通知しない。
ステップＳＴ３３０４において、セルがＳＲ応答タイミングでＳＲ応答を送信不可能と判断した場合は、ステップＳＴ３３０６に移行する。
ステップＳＴ３３０６において、セルは、ＵＥに対して、ターゲットビームでのＳＲ応答タイミングに設定を変更する。
ステップＳＴ３３０７において、セルは、ＵＥに対して、ターゲットビームへの移動指示と、設定変更したＳＲ応答タイミングへの変更指示を通知する。ＳＲ応答タイミングの設定変更指示として、ターゲットビームでのＳＲ応答に関する情報を含ませてもよい。
ステップＳＴ３３０８において、ＵＥは、セルから受信した移動指示とともに、ＳＲ応答タイミングの設定変更指示を受信したか否かを判断する。
ステップＳＴ３３０８において、ＵＥがＳＲ応答タイミングの設定変更指示を受信していない場合は、ステップＳＴ３３０９に移行する。
ステップＳＴ３３０９において、ＵＥは、ソースビームでのＳＲ応答タイミングで受信を継続する。
ステップＳＴ３３０８において、ＵＥがＳＲ応答タイミングの設定変更指示を受信した場合は、ステップＳＴ３３１０に移行する。
ステップＳＴ３３１０において、ＵＥは、受信したＳＲ応答に関する情報を用いてＳＲ応答タイミングを導出し、該ＳＲ応答タイミングに設定を変更して受信を行う。
ステップＳＴ３３１１において、セルは、ＵＥに対して設定したＳＲ応答タイミングで、ターゲットビームでの上りスケジューリングを行う。
ステップＳＴ３３１２において、セルは、ＵＥに対して設定したＳＲ応答タイミングで、ターゲットビームを介して上りグラントをＵＥに通知する。
ステップＳＴ３３１２において、ＵＥは、設定されたＳＲ応答タイミングで、セルからターゲットビームを介して上りグラントを取得する。
ステップＳＴ３３１３において、ＵＥは、取得した上りグラントを用いて、ＢＳＲ（Buffer Status Report）を、ターゲットビームを介してセルに送信する。
ステップＳＴ３３１３でＢＳＲを受信したセルは、ＢＳＲに従って、ＵＥに対して上りスケジューリングを行う。
ステップＳＴ３３１４において、セルは、ターゲットビームを介してＵＥに、上りグラントを通知する。
このようにしてセルからのＳＲに対する上りグラントを受信したＵＥは、ステップＳＴ３３１５において、上りデータをセルに送信する。これによって、ＵＥとセルとの間でターゲットビームを介して上り通信が開始される。
このようにすることによって、ＵＥがＳＲの送信後にビーム間移動が生じた場合に、たとえターゲットビームにおいてＳＲ応答タイミングが変更されたとしても、ＵＥがターゲットビームにおいてＳＲ応答信号を受信することが可能となる。
図２７および図２８は、ＳＲの送信後にビーム間の移動が発生した場合のＳＲに対する上りグラントの送受信タイミング設定のシーケンスの他の例を示す図である。図２７と図２８とは、境界線ＢＬ３の位置で、つながっている。図２７および図２８に示すシーケンスは、図２５に示すシーケンスと同一のステップを含んでいるので、同一のステップについては同一のステップ番号を付して、共通する説明を省略する。
ステップＳＴ２８０１において、セルは、ＵＥに対して、ＵＥ毎のＰＵＣＣＨリソース構成を設定する。
ステップＳＴ３２０１において、セルは、ＵＥに対して、ＵＥに対するＳＲ応答タイミングを設定する。
ステップＳＴ３２０２において、セルは、ＵＥに対して、ＰＵＣＣＨリソースに関する情報とともに、ＳＲ応答に関する情報を通知する。ＰＵＣＣＨリソースに関する情報およびＳＲ応答に関する情報は、ＵＥと通信するビームを介して通知するとよい。前記ＰＵＣＣＨリソースに関する情報およびＳＲ応答に関する情報の通知には、ＲＲＣ個別シグナリングを用いる。ここで、ＵＥと通信するビームは、ソースビームである。
セルは、ステップＳＴ３２０２の処理を行った後は、ステップＳＴ２８０４、ステップＳＴ２８０５およびステップＳＴ２８０６の処理を行う。
ステップＳＴ３２０２でＰＵＣＣＨリソースに関する情報およびＳＲ応答に関する情報を受信したＵＥは、ステップＳＴ２８０３の処理を行う。その後、ＵＥは、ステップＳＴ２８１３の処理を行う。
ステップＳＴ２８１１において、ＵＥは、上りデータが発生したか否かを判断し、上りデータが発生している場合は、ステップＳＴ２８１２Ａに移行する。
ステップＳＴ２８１２Ａにおいて、ＵＥは、設定されたＳＲ用ＰＵＣＣＨリソース構成でＳＲを、サービングビームを介してセルに対して送信する。ここで、サービングビームは、ソースビームである。
ステップＳＴ２８１２ＡでＳＲを送信したＵＥは、ステップＳＴ３２０２で通知されたＳＲ応答に関する情報から導出したＳＲ応答タイミングで受信を開始する。
ステップＳＴ２８１２Ａにおいて、セルは、ＵＥからのＳＲを受信する。ＵＥからのＳＲを受信したセルは、ステップＳＴ３２０１で設定したＳＲ応答タイミングで上りスケジューリングを行うための処理を行う。
この間に、ステップＳＴ３３０１において、セルは、下りＣＳＩ−ＲＳを、ソースビームを介してＵＥに対して送信する。
ステップＳＴ３３０１で下りＣＳＩ−ＲＳを受信したＵＥは、ステップＳＴ３３０２において、ＣＳＩ−ＲＳの測定結果を、ソースビームを介してセルに対して報告する。具体的には、ＵＥは、ＣＳＩ−ＲＳの測定結果をＣＳＩとしてセルに報告する。
ここで、セルは、複数のビームでＣＳＩ−ＲＳを送信してもよい。ＵＥは、複数のビームのＣＳＩ−ＲＳの測定結果をセルに通知してもよい。あるいは、ＵＥは、ＣＳＩ−ＲＳの測定結果から、サービングビームよりも受信品質の良いビームを導出し、該ビームの識別子を通知してもよい。これによって、情報量を削減することができる。
ステップＳＴ３３０２において、ＵＥからＣＳＩ報告を取得したセルは、ステップＳＴ３３０３において、ＵＥをターゲットビームに移動させることを決定する。
ステップＳＴ３３０５において、セルは、ＵＥに対して、ターゲットビームへの移動指示を通知する。
ステップＳＴ３３０５で移動指示を受信したＵＥは、ステップＳＴ３４０３において、ソースビームでのＳＲ応答タイミングをリセットして、毎サブフレームでの受信に設定する。
ステップＳＴ３３０５でＵＥに移動指示を送信したセルは、ステップＳＴ３４０１において、ＵＥに対して設定したソースビームでのＳＲ応答タイミングをリセットし、ＳＲ応答タイミングをダイナミックに設定する。
ステップＳＴ３４０２において、セルは、ＵＥに対して、任意のタイミングで上りスケジューリングを行う。
ステップＳＴ３３１２において、セルは、ＵＥに対して、上りグラントを送信する。上りグラントの送信は、ターゲットビームを介して行う。
ステップＳＴ３４０３において、移動指示の受信によって毎サブフレームでの受信に設定したＵＥは、以降、ターゲットビームにおいて毎サブフレーム受信する。
これによって、ＵＥは、ステップＳＴ３３１２においてセルから送信された上りグラントを受信することが可能となる。
このようにしてセルからＳＲに対する上りグラントを受信したＵＥは、ステップＳＴ３３１３からステップＳＴ３３１５によって、セルとの間でターゲットビームを介して上り通信開始のための処理を行う。これによって、ＵＥとセルとの間で上り通信が開始される。
このようにすることによって、ＵＥがＳＲの送信後にビーム間移動が生じた場合に、たとえターゲットビームにおいてＳＲ応答タイミングが変更されたとしても、ＵＥがターゲットビームにおいてＳＲ応答信号を受信することが可能となる。
セルは、任意のタイミングで、ターゲットビームで、ＵＥからのＳＲに対する上りスケジューリングを行い、上りグラントを送信することができる。また、ＵＥも任意のタイミングで上りグラントが送信されたとしても、該上りグラントを受信することが可能となる。セルは、各ビームの負荷状況および電波伝搬状況などに応じて、適宜適切なタイミングで、ＳＲに対する上りスケジューリングを行うことが可能となる。
ターゲットビームでＳＲの送信が不達になった場合についても問題となる。例えば、ソースビームの設定をそのまま用いるのか、ターゲットビームで新たに設定するのか、新たに設定する場合の設定方法はどうするのか、などの問題が生じる。
ＳＲの送信が不達になった場合についても、前述に開示した、ターゲットビームでのＳＲに対する上りグラントの送信タイミング設定および設定方法を適用するとよい。これによって、ＳＲの送信が不達の場合でも、ターゲットビームでセルおよびＵＥの協調動作が可能となる。
ターゲットビームでのＵＥからのＳＲの再送についてさらなる問題が生じる。例えば、ターゲットビームでＵＥが上り送信を行う場合、ソースビームの送受信ポイント（以下「Ｓ−ＴＲＰ」という場合がある）と、ターゲットビームの送受信ポイント（以下「Ｔ−ＴＲＰ」という場合がある）とが異なるような場合、ＵＥからＳ−ＴＲＰまでの電波伝搬時間と、ＵＥからＴ−ＴＲＰまでの電波伝搬時間とが異なる。
このような場合、ソースビームでのタイミングアドバンス（Timing Advance：ＴＡ）を用いて、ターゲットビームで上り送信を行っても、セルは、Ｔ−ＴＲＰで該上り送信を受信することができないという問題が生じる。
ターゲットビームでのＵＥからのＳＲの再送についても同様の問題が生じる。ＵＥがターゲットビームでＳＲの再送を何度繰り返しても、セルは、該ＳＲの再送を受信できず、ＵＥに対して上りグラントを送信できなくなる。これによって、ＵＥは、上り送信を開始できなくなってしまうという問題が生じる。
このような問題を解決する方法を開示する。
セルは、ＵＥに対して、移動指示とともに、ターゲットビームにおいて、ＵＥ個別のＲＡ処理の起動を指示する。ＵＥ個別のＲＡ処理は、ＲＡ用のプリアンブルにＵＥ個別の構成を用いる。したがって、衝突をすることなく、確実にＲＡ処理を行うことが可能となる。
ＵＥ個別のＲＡ用プリアンブル構成として、無線リソースおよびプリアンブルに用いる信号のシーケンスなどがある。セルは、ＵＥに対して、ターゲットビームでのＲＡ用プリアンブルに関する情報を通知する。セルは、ＵＥに対して、該情報を、ソースビームでの移動指示のシグナリングに含めて通知してもよい。該情報が通知されると、ＵＥ個別のＲＡ処理が起動されるようにしてもよい。
ＵＥは、移動指示とともに、前記ターゲットビームでのＲＡ用プリアンブルに関する情報を受信した場合、ターゲットビームにおいてＵＥ個別のＲＡ処理を行う。ＵＥは、このＲＡ処理によって、ターゲットビームでのタイミングアドバンスをセルから取得することが可能となる。ターゲットビームでのタイミングアドバンスを取得したＵＥは、該タイミングアドバンスを用いて上り送信を行う。
このようにすることによって、セルは、ターゲットビームにおけるＵＥからの上り送信を受信することが可能となる。ＳＲの再送においても同様に、該タイミングアドバンスを用いてＳＲの再送を行う。このようにすることによって、セルは、ターゲットビームにおけるＵＥからのＳＲの再送を受信することが可能となる。
セルは、ＵＥに対する、ソースビームでのタイミングアドバンスとターゲットビームでのタイミングアドバンスとが異なると判断した場合に、ＵＥに対して、ＵＥ個別のＲＡ処理を起動してもよい。例えば、Ｓ−ＴＲＰとＴ−ＴＲＰとの位置が異なるような場合に、ＵＥに対して、ＵＥ個別のＲＡ処理を起動する。Ｓ−ＴＲＰとＴ−ＴＲＰとの位置が同じ、あるいは、ソースビームとターゲットビームとが同一のＴＲＰによって構成されている場合、ＵＥに対して、ＵＥ個別のＲＡ処理を起動しない。
Ｓ−ＴＲＰとＴ−ＴＲＰとの位置が同じ、あるいは、ソースビームとターゲットビームとが同一のＴＲＰによって構成されている場合は、ＵＥからの電波伝搬時間は、ほぼ等しくなる。したがって、ターゲットビームでのタイミングアドバンスを設定し直す必要が無く、ソースビームでのタイミングアドバンスを引き続き使用するとよい。
このようにすることによって、ＵＥがビーム間の移動のときに、常にＲＡ処理を起動する必要が無くなる。したがって、ＵＥおよびセルにおける処理を容易にするとともに、低消費電力化を図ることができる。
他の方法を開示する。ビーム毎あるいはＴＲＰ毎のＴＡＧ（Timing Advance Group）を設定する。従来、ＴＡＧは、セル毎に設定されていた。ＮＲでは、セル内に一つまたは複数のＴＲＰが構成され、ＴＲＰが一つまたは複数のビームを構成することが検討されている。ビームを構成するＴＲＰの位置が異なるような場合、前述のように、タイミングアドバンスが異なってくる。ビーム毎あるいはＴＲＰ毎のＴＡＧを設定することによって、ビームを構成するＴＲＰの位置の違いによるＴＡＧを設定することが可能となる。
セルは、ターゲットビームがソースビームと同じＴＡＧ内か否かを判断して、ＵＥに対してＵＥ個別のＲＡ処理を起動してもよい。ターゲットビームがソースビームと同じＴＡＧ内である場合、セルは、ＵＥに対してＵＥ個別のＲＡ処理を起動しない。ターゲットビームがソースビームと異なるＴＡＧ内である場合、セルは、ＵＥに対してＵＥ個別のＲＡ処理を起動する。このようにすることによって、本実施の形態と同様の効果を得ることができる。
セルがＵＥに対してＲＡ処理を起動することを判断したが、ＵＥがＲＡ処理を起動することを判断してもよい。セルは、予め、ビーム毎あるいはＴＲＰ毎のＴＡＧ設定情報をＵＥに対して通知する。ＴＡＧ設定情報の通知方法として、ＲＲＣシグナリングを用いるとよい。あるいは、ＭＡＣシグナリングを用いてもよい。
セルからビーム間の移動指示を受信したＵＥは、該移動指示に含まれるターゲットビームの識別子から、前記ＴＡＧ設定情報を用いて、ターゲットビームがソースビームと同じＴＡＧ内か否かを判断する。ターゲットビームがソースビームと同じＴＡＧ内である場合、ＵＥは、ＵＥ個別のＲＡ処理を起動しない。ターゲットビームがソースビームと異なるＴＡＧ内である場合、ＵＥは、ＲＡ処理を起動する。ターゲットビームでのＲＡ用プリアンブルに関する情報は、移動指示とともにセルからＵＥに対して通知されるとよい。
ＵＥは、ＵＥ個別ではないＲＡ処理を行うとよい。セルは、ターゲットビームでのＲＡ用プリアンブルに関する情報を、移動指示とともにＵＥに対して通知しなくて済む。ＵＥは、ＲＡ処理に、セル毎あるいはビーム毎に設定されたＲＡ用プリアンブルに関する情報を用いるとよい。該情報は、予め規格などで決められていてもよいし、セルからＵＥに対して予め通知してもよい。ＲＡ用プリアンブルに関する情報の通知方法として、ＲＲＣシグナリングを用いるとよい。このようにすることによって、ＵＥがＲＡ処理を起動することが可能となる。
このような方法で、ターゲットビームでＲＡ処理を起動したＵＥは、ＲＡ処理で取得したタイミングアドバンスを用いて、ターゲットビームでＳＲの再送を行う。ターゲットビームでＲＡ処理を起動しないＵＥは、ソースビームでのタイミングアドバンスを引き続き使用して、ターゲットビームでＳＲの再送を行う。
このようにすることによって、ソースビームでのＳＲの送信が不達の場合でも、ターゲットビームでＳＲを再送することが可能となる。また、ターゲットビームでＳＲを再送する場合に、ＲＡ処理から行うことによって、ＴＡが異なることに起因してＳＲの送信の不達が続くような状況を早期に回避することができる。したがって、早期に上り送信を開始することが可能となる。
このような方法は、ソースビームでＳＲの送信および一回以上のＳＲの再送が不達であった場合でも、ターゲットビームでさらなるＳＲの再送を行うことが可能となる。
ビーム間の移動指示によって、ＳＲの再送最大回数をリセットしてもよい。ターゲットビームでの最初のＳＲの再送を、初回ＳＲの再送あるいはＳＲの初送として、再度、ＳＲの再送最大回数までＳＲの再送を可能としてもよい。このようにすることによって、ターゲットビームでのＳＲの再送機会を十分に与えることができる。したがって、ＳＲの送信不達を低減することができる。
また、ターゲットビームでＲＡ処理を起動したＵＥに対してのみ、ＳＲの再送最大回数をリセットしてもよい。ターゲットビームでの最初のＳＲの再送を、初回ＳＲの再送あるいはＳＲの初送として、再度、ＳＲの再送最大回数までＳＲの再送を可能としてもよい。このようにすることによって、ＴＡが変更されたＵＥに対してのみＳＲの再送機会を十分に与えることができる。したがって、ＳＲの送信不達を低減することができる。また、ＴＡが変更されないＵＥに対しては、無駄に最大回数になるまでの期間を長くせず、早期に再度ＲＡ処理から行うことが可能となる。
ＵＥがＲＡ処理を起動した場合、ＳＲ処理をリセットするとしてもよい。ＵＥは、ＲＡ処理を起動した後、ＳＲ処理を起動するとよい。ターゲットビームにおけるＰＵＣＣＨリソースの設定から起動するとよい。このとき、ソースビームと同じＰＵＣＣＨリソースに関する情報は省略してもよい。このようにすることによって、ＴＡの異なるターゲットビームでＳＲ処理を開始することが可能となる。
実施の形態８．
ＮＲでは、アナログビームフォーミングおよびハイブリッドビームフォーミングが検討されている。一つのセルにおいて複数のビームが形成され、ビーム毎にカバレッジが構成される。したがって、ビームのカバレッジは、セルのカバレッジよりも狭範囲となる。
ビームのカバレッジが適切に形成されていないと、ＵＥのビーム間の移動で通信の切断が生じやすくなるという問題が生じる。また、新たに障害物が形成されたような場合、地点によっては受信電力の低下が生じ、カバレッジホールが発生するという問題が生じる。
ＬＴＥでは、ＵＥによるカバレッジの評価機能として、ＭＤＴ（Minimization of Drive Test）がサポートされている（３ＧＰＰ ＴＳ ３７．３２０ Ｖ１３．１．０（以下「参考文献８」という）、３ＧＰＰ ＴＳ ３６．３３１ Ｖ１４．０．０（以下「参考文献５」という）、および非特許文献１参照）。
従来のＭＤＴは、セルがカバレッジをどのように形成しているかを評価するために、地理的ポイントでセルからどの程度の受信電力が得られるかを、ＵＥに測定、記録、報告させる機能である。セルは、ＵＥからの測定地点における一つまたは複数のセルからの受信電力の報告を取得することによって、セルのカバレッジの形成に利用する。これによって、例えばハンドオーバ失敗などによる通信の切断が生じる地帯を低減するようなカバレッジを形成することができる。
しかし、このように従来のＭＤＴは、セルのカバレッジの形成を目的にしているので、ＮＲで検討されているビーム毎のカバレッジの適切な形成には適用できないという問題がある。
本実施の形態では、このような問題を解決する方法を開示する。
ＭＤＴにビームの識別子を導入する。また、ＴＲＰの識別子がある場合、ＴＲＰの識別子を導入してもよい。ＴＲＰの識別子とビームの識別子とを組合せて導入してもよい。このような方法を、以下の説明では、ビーム毎のＭＤＴと称する場合がある。
ＭＤＴへのビーム識別子の導入の具体例を開示する。
ＵＥが測定結果を記録するログに、測定時点のビームの識別子を入れる。従来のＭＤＴにおけるセル毎の測定結果に、測定時点のビームの識別子を入れてもよい。ビーム毎に送信されるＲＳ（reference signal）（以下「ＢＲＳ」と称する場合がある）とビームの識別子とを関連付けておく。ビームの識別子として、例えばビーム番号などとしてもよい。
ＵＥは、ビーム毎に送信されるＢＲＳを受信してビームの識別子を得る。ＵＥは、セルの識別子と、測定地点に関する情報と、測定地点での受信電力の測定結果とをログに記録する。このログに、測定地点で受信を行っているビームの識別子を加える。
測定地点での受信電力として、ＢＲＳの受信電力を測定してもよい。
セルの識別子と、測定地点に関する情報と、測定地点での受信電力または受信品質の測定結果のログへの記録は、従来のＭＤＴで行われる。これに、測定地点で受信を行っているビームの識別子を加えることによって、測定地点で、どのビームから受信しているかが判ることになる。ＵＥは、記録するログに、測定地点で受信を行っているビームの識別子を加えて、セルに報告する。このようにすることによって、セルは、ＵＥが測定地点でどのビームから受信できているかを認識することができ、ビームのカバレッジがどのように形成されているかを判断することが可能となる。
また、従来のＭＤＴにビームの識別子を加えるだけでよいので、変更が容易である。
他の方法を開示する。
ＵＥは、ビーム毎に受信電力を測定し、測定結果をログに記録する。ＵＥは、該ログをセルに通知する。ＵＥは、測定したビームの識別子に対応付けて測定結果をログに記録する。ビームの識別子は、前述と同様に、ビーム個別のＢＲＳを受信することによって導出するとよい。ＵＥは、ビーム毎の識別子と、測定地点に関する情報と、測定地点でのビーム毎の受信電力（または受信品質であってもよい）の測定結果とをログに記録する。
測定するビームは、一つであってもよいし、複数であってもよい。また、測定するビームは、サービングビームに限らなくてもよい。測定するビームは、同じＴＲＰ内の他のビーム、同じセル内の他のビーム、他のＴＲＰ内のビーム、他のセル内のビームを含んでもよい。ＵＥが測定するビームは、セルが決定して、セルからＵＥに通知してもよい。あるいは、ＵＥが測定できるビームとしてもよい。
ＵＥがログに記録するビーム数に最大値を設けてもよい。セル毎の最大値を設けてもよい。あるいは、ＴＲＰ毎の最大値を設けてもよい。あるいは、周波数毎の最大値を設けてもよい。これによって、測定可能なビーム数が多大になった場合に、ログに記録するビームを限定できるので、ＵＥの記録容量が増大することを抑制することができる。これらの最大数は、予め規格で決められていてもよいし、あるいは、セルからＵＥに対して通知してもよい。前記最大数は、ＲＲＣ個別シグナリングを用いて通知するとよい。
ビーム毎の受信電力を測定する信号の具体例として、以下の（１）〜（５）の５つを開示する。
（１）同期信号（Synchronization Signal：ＳＳ）。
（２）ＢＲＳ。
（３）ＤＭＲＳ（Demodulation RS）。
（４）ＣＳＩ−ＲＳ（Channel Status Information - RS）。
（５）前記（１）〜（４）の組合せ。
前記（１）のＳＳは、ＵＥのＲＲＣ接続状態によらずに用いることができる。ＵＥは、ＲＲＣ＿Ｉｄｌｅ状態でも、ＲＲＣ＿Ｃｏｎｎｅｃｔｅｄ状態でもＳＳを測定できる。ＲＲＭ（Radio Resource Management）メジャメントとして行われてもよい。ＮＲでは、ＳＳはセル内の全ビーム共通の信号が各ビームで送信されることが検討されている。ＵＥは、ビーム毎のＳＳの測定結果と、ＳＳを測定したビームの識別子とを関連付けてログに記憶するとよい。
前記（２）のＢＲＳは、ＵＥのＲＲＣ接続状態によらずに用いることができる。ＵＥは、ＲＲＣ＿Ｉｄｌｅ状態でも、ＲＲＣ＿Ｃｏｎｎｅｃｔｅｄ状態でもＢＲＳを測定できる。ＲＲＭメジャメントとして行われてもよい。あるいは、ＲＬＣメジャメント、あるいは、ＰＨＹメジャメントとして行われてもよい。ＮＲでは、ビーム毎にＢＳＲが送信されることが検討されている。ＵＥは、ビーム毎のＢＳＲの測定結果と、ＢＳＲを測定したビームの識別子とを関連付けてログに記憶するとよい。
前記（３）のＤＭＲＳは、ＵＥがＲＲＣ接続状態で用いることができる。ＲＲＣ＿Ｃｏｎｎｅｃｔｅｄ状態でＤＭＲＳを測定できる。ＲＬＣメジャメントとして行われてもよい。あるいは、ＰＨＹメジャメントとして行われてもよい。ＮＲでは、ＵＥの下りデータあるいは下り制御信号とともに、復調用にＤＭＲＳが送信されることが検討されている。ＵＥは、ＤＭＲＳの測定結果と、ＤＭＲＳを測定したビームの識別子とを関連付けてログに記憶するとよい。
前記（４）のＣＳＩ−ＲＳは、ＵＥがＲＲＣ接続状態で用いることができる。ＲＲＣ＿Ｃｏｎｎｅｃｔｅｄ状態でＣＳＩ−ＲＳを測定できる。ＲＬＣメジャメントとして行われてもよい。あるいは、ＰＨＹメジャメントとして行われてもよい。ＮＲでは、ビームのチャネル状態評価用にビーム毎あるいはアンテナ毎のＣＳＩ−ＲＳが送信されることが検討されている。ＵＥは、ＣＳＩ−ＲＳの測定結果と、ＣＳＩ−ＲＳを測定したビームの識別子とを関連付けてログに記憶するとよい。
セルあるいはＴＲＰが複数のビームで構成する全カバレッジとほぼ同等のカバレッジをシングルビームで構成している場合がある。シングルビームについても、ＵＥは、シングルビームでの受信電力を測定し、測定結果をログに記録してもよい。この場合でも、前述の方法を適宜適用できる。ビーム毎の受信電力を測定する信号としては、前述の（１）から（４）に加えて、シングルビームとして送信されるＲＳの受信電力を測定してもよい。また、前述の（１）から（４）を組合せてもよい。
ＮＲでは、ＵＥにおいてもマルチビームを構成することが検討されているが、ＵＥの測定においては、シングルビームを構成するとしてもよい。ＵＥは、シングルビームで、セルが構成するビーム毎の受信電力を測定し結果をログに記録する。セルが構成するビーム毎の受信電力の測定結果から、ＵＥが構成するビームの影響を排除することが可能となる。
ＵＥがシングルビームを構成できない場合、マルチビームでの測定結果をシングルビームでの測定結果に、予め定める変換方法を用いて変換するとよい。マルチビームでの測定は、ＵＥがビームスイーピングを行って実行してもよい。予め定める変換方法は、静的に規格などで決めておいてもよい。これによって、変換方法の通知に要するシグナリングの増大を回避することができ、変換が容易になる。あるいは、準静的にもしくは動的にＵＥに通知してもよい。例えば、マルチビームのビーム数およびシングルビームとの対応関係が準静的あるいは動的に変更されるような場合に有効である。
準静的あるいは動的にＵＥに通知するような場合、複数の変換方法を予め決めておき、各方法を示すインジケーションを設け、セルは、該インジケーションをＵＥに通知するようにしてもよい。これによって、シグナリングする情報量を低減することができる。
従来のＭＤＴは、ＲＲＭメジャメントで行われていた。しかし、ＮＲにおいて、ビームのメジャメントは、ＲＲＭメジャメントではなく、ＲＬＣメジャメントあるいはＰＨＹメジャメントとすることが検討されている。ビームのメジャメントが、ＲＬＣメジャメントあるいはＰＨＹメジャメントで行われるような場合、ビーム毎の受信電力の測定には、ＲＬＣメジャメントあるいはＰＨＹメジャメントを用いるようにしてもよい。これによって、ビームのメジャメントにＲＲＭ処理を不要とすることができる。
ビーム毎の受信電力の測定およびログへの記録方法を開示する。
受信電力の測定結果に予め定める条件を設定するとよい。予め定める条件に合致した場合に、測定結果をログに記録する。予め定める条件に合致しない場合は、測定結果をログに記録しない。
例えば、受信電力の測定結果に閾値を設定する。例えば、閾値より大きい場合は、測定結果をログに記録し、閾値以下の場合は、測定結果をログに記録しないとするとよい。
セルは、予め設定した条件をＵＥに通知するとよい。例えば、ＭＤＴ設定を通知するメッセージに含めて通知してもよい。
他の方法として、周期的に受信電力を測定し、測定結果をログに記録してもよい。セルは、予め設定した周期をＵＥに通知するとよい。例えば、ＭＤＴ設定を通知するメッセージに含めて通知してもよい。該周期としては、ＭＤＴ用の測定周期としてもよい。
該周期をＤＲＸの動作期間（アクティブ期間）に合わせて設定してもよい。アクティブ期間にあわせることによって、ＤＲＸ中のインアクティブ期間中に受信電力の測定のために受信動作を行わなくて済む。したがって、ＵＥの低消費電力化を図ることが可能となる。
ＵＥからセルへログを通知する方法について開示する。
ＲＲＣ＿Ｉｄｌｅ状態のときは、セルからＵＥに対して、ＭＤＴ結果の報告要求を通知するとよい。該要求を受信したＵＥは、ログを通知する。これらの通知には、ＲＲＣシグナリングを用いるとよい。
ＭＤＴ結果の報告要求およびＭＤＴ結果報告に、ＬＴＥで既存のＵＥ情報プロシージャ（UE information procedure）を用いてもよい。ＭＤＴ結果の報告要求に、ＵＥ情報要求（UE Information Request）を用いて、ＭＤＴ結果報告にＵＥ情報応答（UE Information Response）を用いる。これによって、ＬＴＥにおいて本実施の形態で開示した方法が適用された場合に、別途シグナリングを設ける必要がなくなるので、有効である。
ＲＲＣ＿Ｃｏｎｎｅｃｔｅｄ状態のときは、メジャメント報告に含めて通知するとよい。セルは、ＵＥに対して、メジャメント報告を行うように設定する。ＭＤＴ結果のメジャメント報告を設定してもよい。メジャメント報告の設定を受信したＵＥは、該設定に従って、メジャメント報告にログを含めてセルに通知する。
あるいは、ＣＳＩ報告として通知してもよい。セルは、ＵＥに対して、ＣＳＩ報告を行うように設定する。ＭＤＴ結果のＣＳＩ報告を設定してもよい。ＣＳＩ報告の設定を受信したＵＥは、該設定に従って、ＣＳＩ報告にログを含めてセルに通知する。ＣＳＩ−ＲＳの測定結果をログしているような場合に有効である。
あるいは、新たなメッセージを設けて通知してもよい。セルは、ＵＥに対して、ログの報告を要求するメッセージでログの報告を設定する。ログの報告要求の設定を受信したＵＥは、該設定に従って、ログを報告するメッセージにログを含めてセルに通知する。これらの新たなメッセージの通知には、ＲＲＣシグナリングを用いるとよい。
このようにすることによって、セルは、ＵＥの測定地点で、どのビームからどの程度受信できているかを認識することができる。ビームのカバレッジが、どのように形成されているかを、より精度良く判断することが可能となる。これによって、例えばハンドオーバ失敗などによる通信の切断が生じる地帯を低減するようなカバレッジを形成することができる。
従来、ＬＴＥにおいては、ＣＮはｅＮＢに対してＭＤＴを要求可能であった。ＭＤＴを、ＮＲで検討されているビーム毎のカバレッジに対応させるために、ＣＮは、ｇＮＢに対して、ビーム毎のＭＤＴあるいはＴＲＰ毎のＭＤＴを要求してもよい。ＣＮがｇＮＢに対してビーム毎あるいはＴＲＰ毎のＭＤＴを要求するメッセージを通知する。５ＧでのＣＮとｇＮＢとの間で設定されるインタフェースを用いて通知するよい。
従来のＭＤＴ要求メッセージを用いてもよい。従来のＭＤＴ要求メッセージは、「Trace Start」であり、Ｓ１シグナリングが用いられるが、ｇＮＢに対して通知可能とするために、５ＧでのＣＮとｇＮＢとの間で設定されるインタフェースを用いて通知するとよい。
ＣＮは、「Trace Start」メッセージにＭＤＴ構成を含めてｅＮＢに通知する。「Trace Start」メッセージでＭＤＴの構成を受信したｅＮＢは、セルに対して、ＵＥにＭＤＴを実行させるように指示する。
「Trace Start」メッセージでＭＤＴ構成の中の情報として、ＭＤＴエリアの設定情報がある。ＭＤＴエリアの設定情報は、「CHOICE Area Scope of MDT」である。この中で、従来は、セルあるいはトラッキングエリアでの設定しかできない。
「CHOICE Area Scope of MDT」に、新たに、ビームの設定を加えるとよい。ＴＲＰの設定を加えてもよい。例えば、ビーム毎のＭＤＴを行うか否かを示す情報、あるいは、ＴＲＰ毎のＭＤＴを行うか否かを示す情報を設定可能とする。さらに、ＭＤＴで設定するビームの識別子あるいはＴＲＰの識別子を設定可能としてもよい。
このようにすることによって、ＣＮは、ｇＮＢに対して、ビーム毎のＭＤＴあるいはＴＲＰ毎のＭＤＴを実行させることができる。
また、ビーム毎の受信電力を測定する信号、ならびに予め定める条件および閾値などの設定を行ってもよい。「Trace Start」メッセージでＭＤＴ構成の中の情報として、測定信号などの設定情報がある。測定信号などの設定情報は、「CHOICE MDT Mode」である。これに新たに、前述の信号、予め定める条件および閾値の設定を加えるとよい。例えば、ビーム毎の受信電力を測定する信号として、どの信号にするかを示す情報、受信電力の測定結果をログに記録するための予め定める条件を示す情報、あるいは閾値を示す情報などを設定可能とする。
このようにすることによって、ＣＮは、ｇＮＢに対して、ビーム毎のＭＤＴあるいはＴＲＰ毎のＭＤＴにおいて、どのような信号を測定し、どのような条件でログを取得させるかを設定することが可能となる。
実施の形態９．
ＬＴＥのチャネルコーディングにおいて、チャネルコーディング前のデータブロック、すなわち、トランスポートブロックを、予め規格で定められた一定サイズ以下のコードブロックに分割し、コードブロック毎にコーディングを行っている。ＮＲにおいては、使用周波数の広帯域化によって、トランスポートブロックのサイズが大きくなり、結果として、コードブロック数が増加することが見込まれる。
ＬＴＥにおけるチャネルコーディングにおいて、コードブロック毎およびトランスポートブロック全体に対し、ＣＲＣビットが設けられる。ＬＴＥのＡｃｋ／Ｎａｃｋフィードバックにおいては、受信側は、受信したトランスポートブロック中、１つでもＣＲＣエラーとなるコードブロックが存在した場合、送信側に対してＮａｃｋを送信する。送信側は、前記トランスポートブロック全体を受信側に再送する。したがって、ＣＲＣ＝ＯＫとなったコードブロックも同時に再送されることによって、通信の無駄が生じる。
ＮＲにおいては、３ＧＰＰ Ｒ１−１６０９７４４（以下「参考文献９」という）において、受信側は正しくデコードできなかったコードブロックの番号をフィードバックし、送信側はフィードバックされたコードブロックのみをＨＡＲＱ再送することによって、ＨＡＲＱ再送を効率的に行うことが提唱されている。また、前記フィードバックのビット数について、ｇＮＢから制御シグナリングを用いて準静的に、あるいはトランスポートブロックサイズに応じて制御シグナリングを用いて動的に各ＵＥに設定することが提唱されている。
また、ＮＲにおいては、３ＧＰＰ Ｒ１−１６１２０７２（以下「参考文献１０」という）において、受信側から送信側へのフィードバックのビット数を節約するために、コードブロックを予め定める数ごとにバンドリングすなわちグループ分けし、受信側は正しくデコードできなかったコードブロックを含むバンドリングの番号をフィードバックすることが提唱されている。また、前記予め定める数は、ｇＮＢが決定することが提唱されている。
ところが、コードブロックのバンドリングの番号のフィードバックにおいて、バンドリングあたりのコードブロック数を決めるための詳細は開示されていない。
また、特定シンボルが受信エラーとなった場合において、フィードバック対象となるコードブロックあるいはコードブロックのバンドリングが複数になるので、フィードバック数が増大するという問題が生じる。特定シンボルが受信エラーとなる例として、ＵＲＬＬＣの割り込みが挙げられる。
図２９は、ＵＲＬＬＣの割り込みによるコードブロックの受信エラーを説明する図である。図２９において、１つのトランスポートブロックが、１サブフレームで送信されている。前記トランスポートブロックは、コードブロック（以下「ＣＢ」という場合がある）＃１〜＃１９に分割され、１サブフレームの中において先頭のシンボルから順にマッピングされている。
図２９に示すように、各シンボルにマッピングされるＣＢは、シンボルによって異なる。例えば、図２９に示すように、４番目のシンボルにＵＲＬＬＣの割り込みが入ったとすると、元のＣＢ＃９およびＣＢ＃１０は全部送信することができず、ＣＢ＃１１は一部しか送信することができない。このとき、ＣＢ＃９〜ＣＢ＃１１の計３つのＣＢが受信エラーとなる。一方、５番目のシンボルには、ＣＢ＃１１〜ＣＢ＃１４の計４つのＣＢがマッピングされているので、５番目のシンボルにＵＲＬＬＣの割り込みが入った場合、前記４つのＣＢが受信エラーとなる。従来の方法によると、１バンドリングあたりのＣＢ数は一定であるので、ＵＲＬＬＣによる割り込みによって生じるＣＢの受信エラーのフィードバックに、複数のバンドリングの番号をフィードバックする必要がある。したがって、フィードバックに要するビット数が多くなるという問題がある。
本実施の形態では、このような問題を解決する方法を開示する。
トランスポートブロック中のコードブロックのグループ分けを、１つのコードブロックグループ（以下、Code Block Group：ＣＢＧと称する場合がある）あたりの最大コードブロック数を決めて行ってもよい。ＣＢＧ数を、１つのＣＢＧあたりの最大コードブロック数を用いて決めるとよい。例えば、コードブロック数を、１つのＣＢＧあたりの最大コードブロック数で除算し、小数部を切り上げた値をＣＢＧ数としてもよい。
このようにすることによって、ＣＢＧの受信側から送信側へのフィードバックにおいて、正しく受信できた（受信結果がＯＫとなった）コードブロックを再び送信することによる無駄なコードブロック再送の数を一定以下に抑えることができる。
本実施の形態におけるＨＡＲＱフィードバックは、受信エラーとなったコードブロックをグループ分けして送信側にフィードバックする点で、ＲＬＣにおけるＡＲＱと異なる。
各ＣＢＧへのコードブロック数の割り振りについて、例えば、最大コードブロック数を持つＣＢＧと、余りのコードブロック数を持つＣＢＧとにグループ分けしてもよい。余りのコードブロック数を持つＣＢＧは、先頭のコードブロックを含むものであってもよいし、末尾のコードブロックを含むものであってもよい。余りのコードブロック数を持つＣＢＧを、先頭のコードブロックを含むものとすることによって、トランスポートブロックの先頭に配置されるＭＡＣヘッダを含むＣＢＧに割り当てるコードブロック数が少なくなり、前記ＣＢＧを少ない再送回数で受信可能とすることができる。これによって、受信側は、ＭＡＣヘッダを早期に取得することができる。
具体例として、コードブロック数を５０、１つのＣＢＧあたりの最大コードブロック数を８とすると、ＣＢＧ数は７となる。各ＣＢＧへのコードブロック数の割り当ては、６つのＣＢＧに８コードブロック、残り１つのＣＢＧに２コードブロックとなる。
前記割り振りの他の例として、各ＣＢＧにおけるコードブロック数が均等となるように行ってもよい。最大コードブロック数を持つＣＢＧを、先頭に配置してもよいし、末尾に配置してもよい。前述の具体例において、コードブロック数が均等となるように割り振りを行うと、１つのＣＢＧに８コードブロック、残り６つのＣＢＧに７コードブロックとなる。このようにすることによって、無駄なコードブロック再送の数のＣＢＧ間の偏りを抑えることができる。
コードブロックのグループ分けの他の方法として、ＣＢＧ数を決めて行ってもよい。１つのＣＢＧあたりの最大コードブロック数を、前記ＣＢＧ数を用いて決めるとよい。例えば、コードブロック数を、ＣＢＧ数で除算し、小数部を切り上げた値を１つのＣＢＧあたりの最大コードブロック数としてもよい。このようにすることによって、１つのＣＢＧのフィードバックに要するビット数を一定とすることが可能となる。
前述の、ＣＢＧ数を決めたコードブロックのグループ分けにおいて、前述の、１つのＣＢＧあたりの最大コードブロック数を決めたコードブロックのグループ分けと同様に、コードブロックの割り振りを行ってもよい。例えば、最大コードブロック数を持つＣＢＧと、余りのコードブロック数を持つＣＢＧとにグループ分けしてもよい。余りのコードブロック数を持つＣＢＧは、先頭のコードブロックを含むものであってもよいし、末尾のコードブロックを含むものであってもよい。余りのコードブロック数を持つＣＢＧを、先頭のコードブロックを含むものとすることによって、受信側は、ＭＡＣヘッダを早期に取得することができる。
具体例として、コードブロック数を５０、ＣＢＧ数を８とすると、１つのＣＢＧあたりの最大コードブロック数は７となる。各ＣＢＧへのコードブロック数の割り当ては、７つのＣＢＧに７コードブロック、残り１つのＣＢＧに１コードブロックとなる。
前記割り振りの他の例として、各ＣＢＧにおけるコードブロック数が均等となるように行ってもよい。前述の具体例において、コードブロック数が均等となるように割り振りを行うと、２つのＣＢＧに７コードブロック、残り６つのＣＢＧに６コードブロックとなる。このようにすることによって、無駄なコードブロック再送の数のＣＢＧ間の偏りを抑えることができる。
コードグループのグループ分けにおいて、ＣＢＧ数あるいは１つのＣＢＧあたりの最大コードブロック数のデフォルト値を設けてもよい。また、ＣＢＧの配置についても、デフォルトとなる設定を設けてもよい。例えば、ＣＢＧ数のデフォルト値として、１としてもよい。あるいは、１つのＣＢＧあたりの最大コードブロック数の例として、トランスポートブロック内のコードブロック数と同一としてもよい。あるいは、ＣＢＧの配置のデフォルト設定の例として、最大コードブロック数を持つＣＢＧを先頭に配置してもよいし、コードブロック数が一番少ないＣＢＧを先頭に配置してもよい。
ＣＢＧのグループ分けの方法について、規格で決定してもよい。例えば、固定値としてもよい。固定値の例として、例えば、ＣＢＧ数を１６と固定してもよい。規格で決める他の例として、ＵＥが送信あるいは受信可能な最大コードブロック数を用いて決めてもよい。ＵＥが送信あるいは受信可能な最大トランスポートブロックサイズを用いてもよいし、ＵＥカテゴリーを用いてもよい。
規格で決める他の例として、伝搬環境を用いてもよい。伝搬環境として、ＣＱＩ／ＣＳＩを用いてもよい。例えば、ＣＱＩ／ＣＳＩが良いときに、１つのＣＢＧあたりの最大コードブロック数を少なくしてもよい。このようにすることによって、受信エラーとなったＣＢＧのフィードバックについて、前記ＣＢＧのうち正しく受信できたコードブロックの再送によるオーバーヘッドを少なくすることができる。
規格で決める他の例として、受信誤り率を用いてもよい。例えば、受信誤り率が高いときに、１つのＣＢＧあたりの最大コードブロック数を多くすることによって、受信エラーとなったＣＢＧの送信側へのフィードバックを少ないビット数で行うことができる。
ＣＢＧのグループ分けの方法について、ｇＮＢが決定してもよい。ｇＮＢがＣＢＧのグループ分けを行うために必要な情報としては、規格で決定する場合と同様としてもよい。
あるいは、ｇＮＢがＵＥに対してＨＡＲＱフィードバックに用いることができるビット数を用いて決めてもよい。
ＨＡＲＱフィードバックのビット数を用いる例として、例えば、前記ビット数をＣＢＧ数と同一とし、各ＣＢＧについてＡｃｋ／Ｎａｃｋの情報をフィードバックしてもよい。例えば、前記ビット数を４とし、受信エラーが存在するＣＢＧに１を、受信エラーが存在しないＣＢＧに０を対応付けるとき、ＣＢＧ＃３に属するコードブロックに受信エラーが存在する場合、ｇＮＢからＵＥにフィードバックするビット列を「００１０」としてもよい。他の例として、前記ビット列が示す値に、受信エラーが存在するＣＢＧの組合せを対応付けしてもよい。例えば、受信エラーなしに値０を、ＣＢＧ＃１のみ、ＣＢＧ＃２のみ、ＣＢＧ＃３のみ、ＣＢＧ＃４のみが受信エラーとなる場合にそれぞれ値１、２、３、４を、ＣＢＧ＃１および＃２が受信エラーとなる場合に値５を、ＣＢＧ＃１および＃３が受信エラーとなる場合に値６を、また、ＣＢＧ＃１、＃２、＃３が受信エラーとなる場合に値１１、ＣＢＧ＃１、＃２、＃４が受信エラーとなる場合に値１２、ＣＢＧが４つとも受信エラーとなる場合に値１５を対応付けてもよい。
ＵＥは、ＨＡＲＱフィードバックのビット数および前記ビット列の値を用いて、受信不可能となったＣＢＧに属するコードブロックを求めるとよい。これによって、上り通信において、ＣＢＧのグループ分けに必要な情報をｇＮＢからＵＥに通知する必要がなくなるので、シグナリング量の削減が可能となる。さらに、受信エラーとなるコードブロックが含まれるＣＢＧの数が増えても、ＵＥにフィードバックするビット数を増やさずに一定とすることができる。
ＣＢＧのグループ分けの方法について、ＵＥがｇＮＢに対してＨＡＲＱフィードバックに用いることができるビット数を用いて決定してもよい。例えば、前述と同様に、ＵＥがＨＡＲＱフィードバックに用いることができるビット数を用いて決めてもよい。これによって、下り通信において、前述と同様の効果を得ることができる。
ＣＢＧのグループ分けの方法を、ｇＮＢからＵＥに通知するための手段の具体例として、以下の（１）〜（５）の５つを開示する。
（１）傘下のＵＥに対する報知。
（２）ＵＥ毎の制御シグナリング。例えば、ＲＲＣ個別シグナリング。
（３）ＭＡＣ制御情報。
（４）Ｌ１／Ｌ２シグナリング。
（５）前記（１）〜（４）の組合せ。
前記（１）を用いることによって、複数のＵＥに同時にＣＢＧのグループ分けの方法を通知することができるので、シグナリング量の削減が可能となる。
前記（２）を用いることによって、各ＵＥに対して準静的に通知を行うので、ＵＥ個別の状況に適した設定を少ないシグナリングで行うことができる。
前記（３）を用いることによって、例えば、伝搬環境の短期的変動に応じて、ＨＡＲＱ再送制御によって高い信頼性でＵＥに通知することができる。
前記（４）を用いることによって、ｇＮＢからＵＥに送信するユーザデータがないときにおいても、動的に通知を行うことが可能となる。
ＣＢＧのグループ分けの方法としてｇＮＢからＵＥに通知する内容として、１つのＣＢＧあたりの最大コードブロック数を用いてもよい。あるいは、ＣＢＧ数を用いてもよい。前述の、１つのＣＢＧあたりの最大コードブロック数あるいはＣＢＧ数と併せて、ＣＢＧへのコードブロックの割り振り方法を表す識別子を通知するとよい。前記識別子は、例えば、最大コードブロック数を持つＣＢＧと、余りのコードブロック数を持つＣＢＧとにグループ分けするのか、各ＣＢＧあたりのコードブロック数を均等に割り当てるのか、また、前記２つのそれぞれについて、最大コードブロック数を持つＣＢＧを先頭に配置するか、あるいは末尾に配置するか、を表すものであってもよい。
ＨＡＲＱフィードバックに用いるビット数について、Ａｃｋを１ビット、Ｎａｃｋを複数ビットとしてもよい。前記複数ビットを用いて、前記受信エラーとなったＣＢＧの情報を示してもよい。これによって、Ａｃｋ送信時に余ったビットを用いて他の情報を載せることが可能となる。
下り通信に対するＵＥからｇＮＢへのＨＡＲＱフィードバックの送信について、例えば、ＰＵＣＣＨを用いてもよい。ＰＵＣＣＨについて、例えば、周波数方向の物理リソースを用いてＨＡＲＱフィードバックを送信してもよい。あるいは、前記フィードバックの送信にＭＡＣ制御情報を用いてもよい。ＭＡＣ制御情報を用いることによって、多値変調が可能となるので、少ない物理リソースで送信が可能となる。
ＭＡＣ制御情報を用いるにあたり、ｇＮＢからＵＥに対して、前記フィードバックを送るためのグラントを通知してもよい。あるいは、前記フィードバックの送信について、新たに設けたチャネルを用いて送信してもよい。前記ＭＡＣ制御情報の送信について、上りユーザデータの送信と同じように、ＨＡＲＱフィードバックを行うとよい。
上り通信に対するＵＥからｇＮＢへのＨＡＲＱフィードバックの送信について、例えば、Ｌ１／Ｌ２シグナリングを用いてもよい。あるいは、ＥＰＤＣＣＨ（Enhanced Physical Downlink Control Channel）の構成を用いてもよいし、同じサブフレームのどこかに、ＮＧとなったＣＢＧの情報を載せてもよいし、ＭＡＣ制御情報を用いてもよい。ＭＡＣ制御情報を用いることによって、多値変調が可能となるので、より多いビットの情報をフィードバックできる。前記ＭＡＣ制御情報の送信について、下りユーザデータの送信と同じように、ＨＡＲＱフィードバックを行うとよい。あるいは、ｇＮＢからＵＥへのＨＡＲＱフィードバックの送信について、ＰＨＩＣＨを用いてもよい。
実施の形態１と同様、ｇＮＢは、上り通信に対するフィードバック情報をＵＥへの上りグラントの中に含めてもよい。あるいは、ｇＮＢは、ＡｃｋのフィードバックをＵＥに通知しなくてもよい。ＵＥは、予め定める時間において上りデータに関するＨＡＲＱフィードバックを受信しないことを用いて、該上りデータがｇＮＢに正しく受信されたとみなしてもよい。あるいは、フィードバック情報を上りグラントの中に含める方法と、ＡｃｋのフィードバックをＵＥに通知しない方法とを組合せて用いてもよい。これによって、ＵＥは、上りユーザデータを送信し終えたときにおいても、ｇＮＢからのグラントを受信する必要がなく、最後の上りユーザデータがｇＮＢにおいて正常に受信されたことを知ることができる。また、ｇＮＢは、最後の上りユーザデータに対するＨＡＲＱフィードバック情報をＵＥに通知しなくてもよいので、通信リソースの節約になる。
前述の、下り通信、上り通信それぞれに対するＨＡＲＱフィードバックについて、複数の方法を組合せて用いてもよい。例えば、下り通信に対するＨＡＲＱフィードバックについて、ＵＥはｇＮＢに対して、ＰＵＣＣＨを用いて受信エラーの有無を通知し、ＭＡＣ制御情報を用いて、受信エラーを含むコードブロックの属するＣＢＧ番号を通知してもよい。このようにすることによって、ＨＡＲＱフィードバックにおける信頼性を高めることができる。
本実施の形態におけるＨＡＲＱフィードバックの内容として、受信エラーとなったコードブロックを含むＣＢＧの情報を送信するとよい。前記情報としては、例えば、ＣＢＧ番号を含んでもよいし、ＣＢＧ数を含んでもよい。あるいは、例えば、ＣＢＧの受信可能／エラーを示すビットマップとして送信してもよい。前記ビットマップとしては、例えば、ＣＢＧ数を４とし、受信エラーが存在するＣＢＧに１を、受信エラーが存在しないＣＢＧに０を対応付けるとき、ＣＢＧ＃３に属するコードブロックに受信エラーが存在する場合、ｇＮＢからＵＥにフィードバックするビット列を「００１０」としてもよい。
本実施の形態におけるＣＢＧのグループ分けについて、複数のＣＢＧに属するコードブロックが存在してもよい。例えば、各シンボルにマッピングされるコードブロックを１つのＣＢＧにグループ分けしてもよい。これによって、例えば、優先度が高い通信、例えば、ＵＲＬＬＣのサービスが求められる通信によって、あるシンボルが割り込まれた場合、受信側は送信側に該シンボルに対応するＣＢＧの情報をフィードバックすることによって、送信側は該シンボルにマッピングされたコードブロックを再送することが可能となる。
前述において、複数のシンボルにマッピングされるコードブロックを１つのＣＢＧにグループ分けしてもよい。これによって、ＨＡＲＱフィードバックに要するビット数を小さく抑えることができる。
前述におけるグループ分けについて、各コードブロックと各ＣＢＧとの対応関係を、予め規格で定めてもよい。あるいは、ｇＮＢからＵＥに前記対応関係を通知してもよい。前記対応関係の情報としては、例えば、各ＣＢＧに属するコードブロックの先頭および末尾の番号を用いてもよい。前記通知は、ＲＲＣ個別シグナリングを用いて準静的に行ってもよい。
前述において、受信側は、送信側に、複数のＣＢＧに属するコードブロックの受信エラーを、前記複数のＣＢＧのうち他に受信エラーとなったコードブロックを含むＣＢＧとして通知するとよい。あるいは、受信側は、送信側に、前記複数のＣＢＧのうち先の番号のＣＢＧとして通知してもよいし、後ろの番号のＣＢＧとして通知してもよい。前述において、他に受信エラーとなったコードブロックを含むＣＢＧとして通知することによって、フィードバックするＣＢＧの数を減らすことができる。
あるいは、受信側は、受信エラーとなったコードブロックを含むシンボル番号を送信側に通知してもよい。このようにすることによって、各コードブロックと各ＣＢＧの対応関係を予めｇＮＢからＵＥに通知する必要がなくなり、シグナリング量を削減することができる。複数のシンボルを１つのグループにまとめて、前記グループを表す識別子を受信側から送信側にフィードバックしてもよい。
図３０は、複数のＣＢＧに属するコードブロックが存在する場合のコードブロックとＣＢＧとの対応関係を示す図である。図３０は、下り通信において、１つのシンボルにマッピングされるコードブロックを１つのＣＢＧにグループ分けした場合を示している。
図３０において、シンボル＃２、すなわちＣＢＧ＃２に属するコードブロック＃ｈ（ＣＢ＃ｈ）、コードブロック＃（ｈ＋１）（ＣＢ＃（ｈ＋１））およびコードブロック＃（ｋ−１）（ＣＢ＃（ｋ−１））が受信エラーとなっているので、ＵＥは、ｇＮＢに、ＣＢＧ＃２が受信エラーである旨のＨＡＲＱフィードバックを行う。ｇＮＢは、前記ＨＡＲＱフィードバックを用いて、コードブロック＃ｈ（ＣＢ＃ｈ）からコードブロック＃ｋ（ＣＢ＃ｋ）をＵＥに再送する。
本実施の形態において、ＣＢＧのグループ分けをする代わりに、受信エラーとなったコードブロックを含む、連続したコードブロック（以下「コードブロック塊」と称する場合がある）の情報を通知してもよい。前記コードブロック塊には、受信結果がＯＫであったコードブロックが含まれていてもよい。
前述において、受信側は、各コードブロックの受信結果から、前記コードブロック塊を求める。受信側は、前記コードブロック塊の情報をＨＡＲＱフィードバック情報に含めて送信側に通知する。送信側は、前記コードブロック塊に属するコードブロックを受信側に再送する。
前記コードブロック塊の情報として、先頭のコードブロックを示す情報を用いてもよいし、末尾となるコードブロックを示す情報を用いてもよい。あるいは、コードブロック数を示す情報を用いてもよい。あるいは、これらの２つ以上を組合せて用いてもよい。
前述において、先頭となるコードブロックを示す情報は、例えば、先頭となるコードブロック番号でもよいし、前記コードブロック番号を、予め決めた定数で除した値を用いてもよい。前記値は、小数以下を切り捨てたものであってもよい。前記定数は、規格で定めてもよいし、予めｇＮＢからＵＥにＲＲＣ個別シグナリングで通知してもよい。あるいは、前記定数を受信側が決定し、送信側に通知してもよい。受信側は、前記通知を動的に行ってもよい。例えば、ＭＡＣ制御情報を用いてもよいし、Ｌ１／Ｌ２シグナリングを用いてもよい。このようにすることによって、受信側は、受信エラーの発生状況に応じて、少ないビット数で送信側にＨＡＲＱフィードバックを送ることが可能となる。前記定数をｇＮＢからＵＥに動的に通知してもよい。
先頭となるコードブロック番号を定数で除した値を用いることによって、ＨＡＲＱフィードバックのビット数を小さくすることができる。前述における、末尾となるコードブロックを示す情報についても、前記先頭となるコードブロックを示す情報と同様に扱ってもよい。
前述において、コードブロック数を示す情報についても、前記先頭となるコードブロックを示す情報と同様に扱ってもよい。あるいは、コードブロック数を、予め定める整数のべき乗の値に丸め込み、前記べき乗の指数の値を用いてもよい。前記べき乗の値は、前記コードブロック数以上であることが望ましい。前記整数について、規格で定めてもよいし、予めｇＮＢからＵＥにＲＲＣ個別シグナリングで通知してもよい。あるいは、前記整数を受信側が決定し、送信側に通知してもよい。受信側は、前記通知を動的に行ってもよい。例えば、ＭＡＣ制御情報で通知してもよいし、Ｌ１／Ｌ２シグナリングで通知してもよい。このようにすることによって、受信側は、受信エラーの発生状況に応じて、少ないビット数で送信側にＨＡＲＱフィードバックを送ることが可能となる。前記整数をｇＮＢからＵＥに動的に通知してもよい。
図３１は、受信誤りを含む連続したコードブロックとコードブロック塊との関係を示す図である。図３１において、コードブロック＃２（ＣＢ＃２）、コードブロック＃４（ＣＢ＃４）〜コードブロック＃６（ＣＢ＃６）が受信エラーとなっている。
図３１において、受信側は、受信結果がＯＫであったコードブロック＃３（ＣＢ＃３）も受信エラーとみなすことによって、コードブロック＃２（ＣＢ＃２）〜コードブロック＃６（ＣＢ＃６）を受信エラーとして送信側に通知する。前記通知において、受信側はコードブロック＃２（ＣＢ＃２）およびコードブロック＃６（ＣＢ＃６）の識別子を送信側に通知してもよいし、あるいは、コードブロック＃２（ＣＢ＃２）の識別子および受信エラーの個数を示す情報を通知してもよい。図３１においては、受信側から送信側に通知される受信エラーの個数は５である。
送信側は、前記通知から、受信エラーとなったコードブロックの情報を取得する。送信側は、コードブロック＃２（ＣＢ＃２）〜コードブロック＃６（ＣＢ＃６）を受信側に再送する。
受信側が送信側にコードブロック塊の情報を通知することによって、受信エラーとなったコードブロックが連続、あるいは少し離れて発生している場合について、特に、受信エラーとなったコードブロックがＣＢＧの境界を跨いでいても、受信側から送信側に通知するＨＡＲＱフィードバックの情報を小さく抑えることができる。
本実施の形態におけるコードブロック塊の情報の通知において、コードブロックの代わりにＣＢＧを用いてもよい。例えば、受信側から送信側へのＨＡＲＱフィードバックにおいて、受信エラーを含む先頭のＣＢＧ番号とＣＢＧ数とを用いてもよい。このようにすることによって、受信側から送信側に通知するＨＡＲＱフィードバックの情報をさらに小さく抑えることができる。
本実施の形態において、受信側から送信側へのフィードバックに、予め定めるパターンを用いてもよい。予め定めるパターンは、例えば、トランスポートブロック中の全コードブロックのうち、先頭の４分の１および末尾の４分の１のコードブロックが受信エラーとなるものでもよい。また、予め定めるパターンは、先頭の４分の１から末尾の４分の１までのコードブロックが受信エラーとなるものでもよいし、あるいは、例えば、先頭の８分の１および末尾の８分の１が受信エラーとなるものでもよい。
また、予め定めるパターンは、対称形でなくてもよい。例えば、トランスポートブロック中の全コードブロックのうち、先頭の５個が受信エラーとなるものでもよいし、あるいは、先頭の３個ならびに先頭から５個目および７個目が受信エラーとなるものでもよい。
あるいは、予め定めるパターンは、物理チャネルの各シンボルについて、マッピングされたコードブロックが受信エラーとなる場合のシンボル番号に対応するものであってもよい。
予め定めるパターンの一覧について、規格で定めてもよいし、予めｇＮＢからＵＥに対して通知してもよい。また、前記予め定めるパターンの一覧は、Ａｃｋ、すなわち、受信エラーとなるコードブロックが存在しないパターンを含んでもよい。
予め定めるパターンの一覧には、受信エラーとなるコードブロックが存在しないパターンが含まれていてもよい。ｇＮＢおよびＵＥは、前記パターンを、全てのコードブロックを正しく受信したことの通知に用いてもよい。
受信側は、各コードブロックの受信結果を用いて、送信側にフィードバックするパターンを決定する。前記パターンは、予め定めるパターンの一覧のうち、受信エラーとなったコードブロックを全て含むものであることが望ましい。受信側は、前記パターンを示す識別子を送信側に通知する。送信側は、前記識別子にて示されたパターンにおいて受信エラーに該当するコードブロックを、受信側に再送する。
図３２は、受信エラーを含むコードブロックのパターンを説明するための図である。図３２では、受信データが受信エラー３３０２，３３０４，３３０５を含む場合を示す。図３２において、受信エラー３３０２，３３０４，３３０５を除く部分、例えば参照符号３３０１，３３０３，３３０６で示す部分は、受信エラーとならずに受信できた部分である。
図３２において、受信側は、受信データに示すように受信エラー３３０２，３３０４，３３０５を検出した場合、送信側にパターン＃４を示す識別子をフィードバックする。送信側は、パターン＃４に従い、コードブロック＃１（ＣＢ＃１）〜コードブロック＃５（ＣＢ＃５）を受信側に再送する。
受信側が送信側にコードブロック塊の情報を通知することによって、受信エラーとなったコードブロックがトランスポートブロック内に分散していても、受信側から送信側に通知するＨＡＲＱフィードバックの情報を小さく抑えることができる。
本実施の形態において、ｇＮＢは、ＨＡＲＱフィードバックのレベルを切り替えてもよい。ＨＡＲＱレベルとしては、例えば、コードブロック毎のフィードバックを含んでもよいし、ＣＢＧ毎のフィードバックを含んでもよいし、トランスポートブロック全体のフィードバックを含んでもよい。前述において、ＣＢＧ毎のフィードバックについても、複数のレベルを設けてもよい。例えば、ＣＢＧあたりのコードブロック数が少ないＣＢＧによるフィードバックのレベルと、ＣＢＧあたりのコードブロック数が多いＣＢＧによるフィードバックのレベルとを設けてもよい。各レベルにおけるコードブロック数について、あるレベルにおいて用いるＣＢＧに含まれるコードブロック数は、他のレベルにおいて用いるＣＢＧに含まれるコードブロック数の整数倍であってもよいし、整数倍でなくてもよい。また、あるレベルにおいて、複数のＣＢＧが同じコードブロックを含んでもよいし、含まなくてもよい。
ｇＮＢは、前記フィードバックのレベルをＵＥに通知する。前記通知内容としては、フィードバックのレベルの内容、例えば、ＣＢＧあたりのコードブロック数でもよいし、前記レベルの識別子でもよい。前記識別子を用いるにあたり、フィードバックのレベルの一覧を、規格で定めてもよいし、予めｇＮＢからＵＥに通知してもよい。前記通知としては例えばＲＲＣシグナリングを用いてもよい。
ｇＮＢがＨＡＲＱフィードバックのレベルの通知を行う方法として、以下の（１）〜（５）の５つを開示する。
（１）傘下のＵＥへの報知。
（２）ＵＥ毎の制御シグナリング。例えば、ＵＥ毎のＲＲＣ個別シグナリング。
（３）ＭＡＣ制御情報。
（４）Ｌ１／Ｌ２シグナリング。
（５）前記（１）〜（４）の組合せ。
前記（１）を用いることによって、複数のＵＥに対して一斉に通知を行うことができるので、シグナリングの削減が可能となる。
前記（２）を用いることによって、個別のＵＥに準静的な設定が可能となる。例えば、該ｇＮＢの配下に、ＵＲＬＬＣのサービスを用いるＵＥが接続されたときに、ｅＭＢＢのサービスを使用しているＵＥに対して、ＨＡＲＱフィードバックレベルをトランスポートブロック全体のフィードバックのレベルから、シンボル毎のフィードバックのレベルに切り替えることが可能となる。これによって、前記ＵＲＬＬＣのサービスを用いるＵＥが、前記ｅＭＢＢのサービスを使用しているＵＥが使用するシンボルに割り込んだ場合において、ＵＥはｇＮＢに対し前記シンボル番号のフィードバックが可能となり、ｅＭＢＢのサービスを使用するＵＥにとっての伝送効率が向上する。
前記（３）を用いることによって、伝搬環境などの動的な変化に対応したレベルの切り替えを、高い信頼性で行うことができる。また、ＭＡＣ制御情報を用いることによって、多値変調が可能であるので、前記通知に用いるビット数を少なく抑えることができる。
前記（４）を用いることによって、ユーザデータが存在しない場合においても、伝搬環境などの動的な変化に対応した迅速なレベルの切り替えが可能となる。
本実施の形態におけるＣＢＧのグループ分けについて、ＨＡＲＱフィードバックの複数のレベルに対して一連のＣＢＧ番号を割り当ててもよい。例えば、トランスポートブロック内のコードブロック全体に、予め定めた最大コードブロック数で構成されるＣＢＧ番号を割り当てた後、前記予め定めた最大コードブロック数より大きい最大コードブロック数で構成されるＣＢＧ番号を割り当ててもよい。
受信側は、受信エラーとなったコードブロックの分布に応じて、どのレベルに対して割り当てたＣＢＧ番号を用いるかを決めてもよい。受信側は、送信側に、前述において受信側が決めたＣＢＧ番号をフィードバックしてもよい。
例えば、コードブロック数が２０であるトランスポートブロックについて、ｇＮＢおよびＵＥは、最大コードブロック数が３であるＣＢＧを用いて、ＣＢＧ＃１をコードブロック＃１〜＃３、ＣＢＧ＃２をコードブロック＃４〜＃６、以下同様にして、ＣＢＧ＃６をコードブロック＃１５〜＃１８、ＣＢＧ＃７をコードブロック＃１９、＃２０に割り当て、最大コードブロック数が５であるＣＢＧを用いて、ＣＢＧ＃７をコードブロック＃１〜＃５、ＣＢＧ＃８をコードブロック＃６〜＃１０、以下同様にして、ＣＢＧ＃１０をコードブロック＃１６〜＃２０に割り当ててもよい。
前述の例において、受信側においてコードブロック＃３，＃４が受信エラーとなった場合において、受信側は、送信側に、ＣＢＧ＃７が受信エラーとなったことをフィードバックすればよい。
このようにすることによって、ｇＮＢからＵＥへのＨＡＲＱフィードバックのレベルの通知が不要となるので、ｇＮＢからＵＥへのシグナリング量を削減することが可能となる。
本実施の形態におけるＨＡＲＱフィードバックについて、受信側は、送信側に、受信結果がＯＫであったコードブロックの情報をフィードバックしてもよい。受信結果がＯＫであったコードブロックのみで構成されるＣＢＧの情報をフィードバックしてもよい。受信側は、前記フィードバックに、受信結果ＯＫおよび受信エラーのどちらのフィードバックであるかを示す識別子を含めてもよい。
受信側は、自身が受信結果ＯＫおよび受信エラーのどちらのフィードバックを行うかを、受信エラーとなったコードブロック数、あるいはＣＢＧ数の情報を用いて決めてもよいし、受信結果ＯＫまたは受信エラーのフィードバックに要するビット数を用いて決めてもよい。
このようにすることによって、受信側は、トランスポートの受信結果に応じて、少ないビット数で送信側にフィードバックを行うことが可能となる。
ｇＮＢがＨＡＲＱフィードバックのレベルの判断に用いる情報として、以下の（１）〜（５）の５つを開示する。
（１）伝搬環境。例えば、ＣＱＩ／ＣＳＩ。
（２）下り通信の負荷。例えば、ｇＮＢのバッファ蓄積量。
（３）上り通信の負荷。例えば、ＵＥのバッファ蓄積量。
（４）ＵＥについての情報。例えば、ＵＥカテゴリーやＵＥの使用サービス。
（５）前記（１）〜（４）の組合せ。
前記（１）において、例えば、ＣＱＩ／ＣＳＩが良いときに、１つのＣＢＧあたりの最大コードブロック数を多くするようにレベルを切り替えてもよい。このようにすることによって、Ａｃｋを通知するためのフィードバックのビット数を少なくすることができる。
前記（２）において、例えば、ｇＮＢのバッファ蓄積量が多いときに、１つのＣＢＧあたりの最大コードブロック数を少なくすることによって、下り通信において、受信エラーとなったＣＢＧのフィードバックについて、受信結果がＯＫであったコードブロックの再送のオーバーヘッドを少なくすることができる。これによって、下り通信における伝送効率を高めることができる。
前記（３）において、ＵＥからｇＮＢに通知するバッファ状態報告（Buffer Status Report：ＢＳＲ）を用いてもよいし、他の値を用いてもよい。
前記（３）において、例えば、ＵＥのバッファ蓄積量が多いときに、１つのＣＢＧあたりの最大コードブロック数を少なくすることによって、上り通信において、受信エラーとなったＣＢＧのフィードバックについて、受信結果がＯＫであったコードブロックの再送のオーバーヘッドを少なくすることができる。これによって、上り通信における伝送効率を高めることができる。
前記（４）において、例えば、ｅＭＢＢを用いるＵＥに対して、１つのＣＢＧあたりの最大コードブロック数を少なくすることによって、受信エラーとなったＣＢＧのフィードバックについて、受信結果がＯＫであったコードブロックの再送のオーバーヘッドを少なくすることができる。これによって、ｅＭＢＢを用いるＵＥの伝送効率を高めることができる。
本実施の形態において、受信側は、予め定めた閾値を用いて、すべてのコードブロックを受信エラーとみなしてもよい。受信側は、すべてのコードブロックが受信エラーである旨の通知を送信側に行ってもよい。送信側は、すべてのコードブロックを再送してもよい。前述において、送信側は、既に受信可能となっているコードブロックは再送から除外してもよい。前述において、既に受信可能となっているコードブロックは、受信側からのフィードバックによって得られたものであってもよい。
前述において、予め定めた閾値は、規格で決定してもよいし、ｇＮＢからＵＥに通知してもよい。
前記閾値は、受信エラーとなるコードブロック数を用いて決められてもよいし、受信エラーとなるコードブロックを含むＣＢＧ数を用いて決められてもよいし、受信側からのＨＡＲＱフィードバックに使用可能なビット数を用いて決められてもよい。例えば、前記ビット数が２のとき、受信エラーとなるコードブロックがトランスポートブロックの中央を跨いで存在していた場合に、受信側は、すべてのコードブロックを受信エラーとして送信側に通知してもよい。このようにすることによって、受信エラーを送信側にフィードバックするビット数を少なくすることができる。
本実施の形態において、ＣＢＧ、コードブロック塊、あるいはコードブロックのパターンの最大再送回数は、ＨＡＲＱ最大再送回数と同じとしてもよい。すなわち、本実施の形態における前記再送は、ＨＡＲＱ再送とみなしてもよい。これによって、ｇＮＢおよびＵＥの実装を簡易にすることができる。
本実施の形態において、受信側は、受信結果がＯＫであったコードブロックを破棄して受信し直してもよい。前述において、送信側は、受信側における受信結果がＯＫであったコードブロックの送信をやり直してもよい。前記送信のやり直しは、ＨＡＲＱ最大再送回数を超過したときに行ってもよい。
本実施の形態において、受信側は、上位レイヤ、例えばＲＬＣレイヤのデータユニット、例えばＲＬＣ ＰＤＵが完成した時点で、受信データを前記上位レイヤに送信してもよい。前記受信データは、トランスポートブロックのうち、一部のコードブロックが正しく受信できたデータでもよい。これによって、前記データの送受信にかかる遅延を抑制することができる。
前述において、受信側は、ＭＡＣヘッダのサイズおよび上位レイヤのデータユニットのサイズを予め送信側から取得していてもよい。あるいは、規格によって決められてもよい。
本実施の形態において、送信側は、ＣＢＧ毎にパリティチェックビットを付加してもよい。前記パリティチェックビットは、例えば、ＣＲＣでもよい。前記ＣＢＧ毎のパリティチェックビットとトランスポートブロック全体のパリティチェックビットとが共存していてもよい。
前述において、ｇＮＢは、ＣＢＧ毎のパリティチェックの使用の有無をＵＥに通知してもよい。前記通知は、ＲＲＣ個別シグナリングを用いて準静的に通知してもよいし、Ｌ１／Ｌ２シグナリングを用いて動的に通知してもよい。あるいは、規格で決定してもよい。
図３３は、ＣＢＧ毎のパリティチェック３４０１〜３４０４の付与を説明するための図である。図３３において、送信側は、ＣＢＧ＃１に含まれるコードブロック＃１〜コードブロック＃ｋに基づいてパリティビットを計算し、コードブロック＃１（ＣＢ＃１）にパリティチェック３４０１を付与する。ＣＢＧ＃２以降についても、同様にして、コードブロック＃ｋ＋１（ＣＢ＃（ｋ＋１））、…コードブロック＃２ｋ＋１（ＣＢ＃（２ｋ＋１））、…コードブロック＃（Ｎ−１）ｋ＋１（ＣＢ＃（（Ｎ−１）ｋ＋１））に、それぞれパリティチェック３４０２、３４０３、３４０４が付与される。
前述の方法を用いることによって、トランスポートブロック全体におけるパリティチェックの信頼性を高めることができる。
本実施の形態によって、受信側は、受信エラーとなったコードブロックの情報のフィードバックを少ないビット数で行うことができるので、通信を効率的に行うことができる。
前述の各実施の形態およびその変形例は、本発明の例示に過ぎず、本発明の範囲内において、各実施の形態およびその変形例を自由に組合せることができる。また各実施の形態およびその変形例の任意の構成要素を適宜変更または省略することができる。
例えば、前述の各実施の形態およびその変形例において、サブフレームは、第５世代基地局通信システムにおける通信の時間単位の一例である。スケジューリング単位であってもよい。前述の各実施の形態およびその変形例において、サブフレーム単位として記載している処理を、ＴＴＩ単位、スロット単位、サブスロット単位、ミニスロット単位として行ってもよい。
本発明は詳細に説明されたが、上記した説明は、すべての局面において、例示であって、本発明がそれに限定されるものではない。例示されていない無数の変形例が、本発明の範囲から外れることなく想定され得るものと解される。
７０１ マクロセルのカバレッジ、７０２ スモールセルのカバレッジ、７０３，８１３ 移動端末（ＵＥ）、８０１ 下りビームスイーピングブロック、８０２，８０４，８０６，８１１ リソース、８０３ 上りビームスイーピングブロック、８０５ ＤＬ／ＵＬデータサブフレーム、８１２ ビーム、９０１，９０５，９０９ サブフレーム、９０２，９０６，９１０ 下り制御信号、９０３，９０７，９１１ ユーザデータ、９０４，９０８，９１２ 次の受信タイミングに関する情報。

Claims (2)

  1. 基地局装置と、前記基地局装置と無線通信可能な少なくとも１つの通信端末装置とを備える通信システムであって、
    前記基地局装置は、前記通信端末装置に、次の受信タイミングに関する情報を通知し、
    前記通信端末装置は、前記基地局装置から通知された次の受信タイミングに関する情報に基づいて受信を行うことを特徴とする通信システム。
  2. 前記基地局装置と前記通信端末装置とは、アンテナから放出されるビームの指向性を切替えて送受信を行うことを特徴とする請求項１に記載の通信システム。
JP2018558085A 2016-12-22 2017-12-22 通信システム、基地局装置および通信端末装置 Active JP7320948B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2022163761A JP2023015051A (ja) 2016-12-22 2022-10-12 通信システム、基地局装置および通信端末装置

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP2016249443 2016-12-22
JP2016249443 2016-12-22
PCT/JP2017/046054 WO2018117248A1 (ja) 2016-12-22 2017-12-22 通信システム

Related Child Applications (1)

Application Number Title Priority Date Filing Date
JP2022163761A Division JP2023015051A (ja) 2016-12-22 2022-10-12 通信システム、基地局装置および通信端末装置

Publications (2)

Publication Number Publication Date
JPWO2018117248A1 true JPWO2018117248A1 (ja) 2019-10-31
JP7320948B2 JP7320948B2 (ja) 2023-08-04

Family

ID=62626757

Family Applications (2)

Application Number Title Priority Date Filing Date
JP2018558085A Active JP7320948B2 (ja) 2016-12-22 2017-12-22 通信システム、基地局装置および通信端末装置
JP2022163761A Pending JP2023015051A (ja) 2016-12-22 2022-10-12 通信システム、基地局装置および通信端末装置

Family Applications After (1)

Application Number Title Priority Date Filing Date
JP2022163761A Pending JP2023015051A (ja) 2016-12-22 2022-10-12 通信システム、基地局装置および通信端末装置

Country Status (5)

Country Link
US (3) US20200045725A1 (ja)
EP (2) EP4274346A3 (ja)
JP (2) JP7320948B2 (ja)
CN (1) CN110115090A (ja)
WO (1) WO2018117248A1 (ja)

Families Citing this family (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018126357A1 (en) * 2017-01-04 2018-07-12 Qualcomm Incorporated Techniques for indicating or using information about a subsequent physical downlink control channel transmission
US10721756B2 (en) 2017-02-13 2020-07-21 Qualcomm Incorporated Repetition-based uplink for low latency communications in a new radio wireless communication system
ES2968142T3 (es) 2017-03-08 2024-05-08 Lg Electronics Inc Método y aparato para transmitir y recibir señales de radio en un sistema de comunicación inalámbrica
ES2890526T3 (es) * 2017-06-06 2022-01-20 Guangdong Oppo Mobile Telecommunications Corp Ltd Método de transmisión de datos por mapeo y producto relacionado
US11277760B2 (en) * 2017-08-10 2022-03-15 Sony Corporation Communication apparatus, communication control method, and computer program for beam measurement
CN109861775B (zh) * 2017-11-30 2021-04-09 上海华为技术有限公司 一种传播路径搜索方法以及装置
US11088750B2 (en) * 2018-02-16 2021-08-10 Qualcomm Incorporated Feedback of beam switch time capability
CN110446232B (zh) * 2018-05-04 2021-10-29 中国移动通信有限公司研究院 测量上报配置方法、测量上报方法、小区切换方法及设备
US11095355B2 (en) * 2018-05-10 2021-08-17 Comcast Cable Communications, Llc Prioritization in beam failure recovery procedures
WO2020027572A1 (ko) * 2018-07-31 2020-02-06 엘지전자 주식회사 무선통신시스템에서 사이드 링크 단말이 동기 신호를 전송하는 방법 및 장치
EP3834459A4 (en) * 2018-08-21 2021-11-10 Guangdong Oppo Mobile Telecommunications Corp., Ltd. BEAM MEASUREMENT PROCESS, NETWORK DEVICE, AND USER EQUIPMENT
EP3911100A4 (en) * 2019-01-10 2022-01-19 Sony Group Corporation COMMUNICATION DEVICE, COMMUNICATION METHOD AND COMMUNICATION PROGRAM
CN114745748A (zh) * 2019-02-15 2022-07-12 华为技术有限公司 最小化路测技术配置方法和基站
CN111585730B (zh) * 2019-02-15 2021-10-15 华为技术有限公司 传输方法和通信装置
US10848965B1 (en) * 2019-07-12 2020-11-24 Qualcomm Incorporated Compromised-message exploit protection
US11503611B2 (en) * 2019-10-29 2022-11-15 Hon Lin Technology Co., Ltd. Method and apparatus for allocation of resources in a wireless communication system
US11627613B2 (en) 2019-12-13 2023-04-11 Apple Inc. Mechanism for low latency communication using historical beam information
US10917843B1 (en) * 2020-09-02 2021-02-09 Lockheed Martin Corporation Cell selection and reselection algorithm for LTE over satellite
EP4009564B1 (en) * 2020-12-03 2023-12-06 Hon Lin Technology Co., Ltd. Method for allocating wireless resources based on sensitivity to inter-cell interference and apparatus thereof
WO2023073939A1 (ja) * 2021-10-29 2023-05-04 株式会社Ｎｔｔドコモ 端末、無線通信方法及び基地局

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006030582A1 (ja) * 2004-09-17 2006-03-23 Nec Corporation 通信制御方法、移動通信システム、基地局及び回線制御局
JP2010525725A (ja) * 2007-05-02 2010-07-22 サムスン エレクトロニクス カンパニー リミテッド 無線通信システムにおける制御チャンネルの集合を限定して送受信する方法及び装置
JP2012531813A (ja) * 2009-06-23 2012-12-10 クアルコム，インコーポレイテッド 無線通信システム内のマルチキャスティング
US20160219557A1 (en) * 2015-01-22 2016-07-28 Hong He Devices and methods for epdcch monitoring in wireless communication systems

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2013017154A1 (en) * 2011-07-29 2013-02-07 Fujitsu Limited Control channel for wireless communication
WO2014171683A1 (en) * 2013-04-14 2014-10-23 Lg Electronics Inc. Method and apparatus for controlling monitoring timing in wireless communication system
US11252582B2 (en) * 2013-09-27 2022-02-15 Nokia Technologies Oy Method for determining start time of a physical downlink control channel
JP6255281B2 (ja) * 2014-02-27 2017-12-27 パナソニック株式会社 無線通信装置及び指向性制御方法
JP6628365B2 (ja) * 2014-04-28 2020-01-08 シャープ株式会社 端末装置、基地局装置および通信方法
US9474013B2 (en) * 2014-06-16 2016-10-18 Qualcomm Incorporated Method and apparatus for connection point discovery and association in a directional wireless network

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006030582A1 (ja) * 2004-09-17 2006-03-23 Nec Corporation 通信制御方法、移動通信システム、基地局及び回線制御局
JP2010525725A (ja) * 2007-05-02 2010-07-22 サムスン エレクトロニクス カンパニー リミテッド 無線通信システムにおける制御チャンネルの集合を限定して送受信する方法及び装置
JP2012531813A (ja) * 2009-06-23 2012-12-10 クアルコム，インコーポレイテッド 無線通信システム内のマルチキャスティング
US20160219557A1 (en) * 2015-01-22 2016-07-28 Hong He Devices and methods for epdcch monitoring in wireless communication systems

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
NOKIA, ALCATEL-LUCENT SHANGHAI BELL, VERIZON WIRELESS: "On the synchronization signal design principle in NR", 3GPP TSG-RAN WG1#86B R1-1610287[ONLINE], vol. [retrieved on 2018.03.05], JPN6018008767, 14 October 2016 (2016-10-14), pages 2 - 3, ISSN: 0004950823 *

Also Published As

Publication number Publication date
CN110115090A (zh) 2019-08-09
US20200045725A1 (en) 2020-02-06
JP2023015051A (ja) 2023-01-31
WO2018117248A1 (ja) 2018-06-28
EP4274346A2 (en) 2023-11-08
US20220159704A1 (en) 2022-05-19
US20240121793A1 (en) 2024-04-11
EP4274346A3 (en) 2024-01-17
JP7320948B2 (ja) 2023-08-04
EP3562243A4 (en) 2020-07-22
EP3562243A1 (en) 2019-10-30

Similar Documents

Publication Publication Date Title
JP7320948B2 (ja) 通信システム、基地局装置および通信端末装置
JP7405911B2 (ja) 無線通信システム、基地局
JP7399242B2 (ja) 通信システム、基地局、及び、ユーザ装置
US20230422139A1 (en) Communication system
JP7341135B2 (ja) ユーザ装置、基地局および通信システム
CN107926003B (zh) 通信系统
JP7420732B2 (ja) ユーザ装置および通信システム
WO2019194021A1 (ja) 通信システム、基地局および端末装置
JP2023145753A (ja) 通信システム、基地局および通信端末

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20201127

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20220111

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20220301

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20220719

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20221012

C60 Trial request (containing other claim documents, opposition documents)

Free format text: JAPANESE INTERMEDIATE CODE: C60

Effective date: 20221012

A911 Transfer to examiner for re-examination before appeal (zenchi)

Free format text: JAPANESE INTERMEDIATE CODE: A911

Effective date: 20221019

C21 Notice of transfer of a case for reconsideration by examiners before appeal proceedings

Free format text: JAPANESE INTERMEDIATE CODE: C21

Effective date: 20221025

A912 Re-examination (zenchi) completed and case transferred to appeal board

Free format text: JAPANESE INTERMEDIATE CODE: A912

Effective date: 20221228

C211 Notice of termination of reconsideration by examiners before appeal proceedings

Free format text: JAPANESE INTERMEDIATE CODE: C211

Effective date: 20230110

C22 Notice of designation (change) of administrative judge

Free format text: JAPANESE INTERMEDIATE CODE: C22

Effective date: 20230207

C22 Notice of designation (change) of administrative judge

Free format text: JAPANESE INTERMEDIATE CODE: C22

Effective date: 20230322

C13 Notice of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: C13

Effective date: 20230404

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20230525

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20230725

R150 Certificate of patent or registration of utility model

Ref document number: 7320948

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150