JP2022031847A - 無線通信システムにおけるビーム管理のための方法及び装置 - Google Patents

Abstract

【課題】ビーム管理を特定の期間中継続する必要性をなくして効率を改善する無線通信システムにおけるビーム管理のための方法及び装置を提供する。【解決手段】ビーム管理を行うため、ＵＥは、設定を受信する。その設定は、ＵＥが特定期間中にビーム管理を実行するかどうかを示す。ＵＥは少なくともその設定に基づいて特定期間中にビーム管理を実行するかどうかを決定することで、特定期間中の管理の必要性をなくし、効率を改善する。【選択図】図２６

Description

本願は、２０１６年１２月１３日に出願された米国仮特許出願第６２／４３３，４４４号の利益を主張するものであり、そのすべての開示は全体として参照により本明細書に援用される。

本開示は、概して、無線通信ネットワークに関し、より詳細には、無線通信システムにおけるビーム管理のための方法及び装置に関する。

移動体通信デバイスとの大量データの通信に対する要求が急速に高まる中、従来の移動体音声通信ネットワークは、インターネットプロトコル（ＩＰ）データパケットをやり取りするネットワークへと発展している。このようなＩＰデータパケット通信は、移動体通信デバイスのユーザに、ボイスオーバＩＰ、マルチメディア、マルチキャスト、及びオンデマンド通信サービスを提供可能である。

例示的なネットワーク構造は、発展型ユニバーサル地上無線アクセスネットワーク（Ｅ－ＵＴＲＡＮ）である。Ｅ－ＵＴＲＡＮシステムは、上記のボイスオーバＩＰ及びマルチメディアサービスを実現するために、高いデータスループットを提供可能である。現在、次世代（例えば、５Ｇ）の新しい無線技術が３ＧＰＰ標準化機構によって論じられている。このため、現行の３ＧＰＰ標準内容に対する変更が現在提出され、３ＧＰＰ標準の発展及び確定に向けて検討されている。

ＵＥ（ユーザ機器）の観点からの方法及び装置が開示される。一実施形態では、その方法は、設定を受信するステップを含む。その設定は、ＵＥが特定期間中にビーム管理を実行するかどうかを示す。その方法は、少なくともその設定に基づいて特定期間中にビーム管理を実行するかどうかを決定するステップも含む。

例示的な一実施形態による無線通信システムの図である。 例示的な一実施形態による送信機システム（アクセスネットワークとしても知られている）及び受信機システム（ユーザ機器又はＵＥとしても知られている）のブロック図である。 例示的な一実施形態による通信デバイスの機能ブロック図である。 例示的な一実施形態による図３のプログラムコードの機能ブロック図である。 ３ＧＰＰ Ｒ２－１６２７０９の図１の再現である。 例示的な一実施形態による競合ベースのランダムアクセス手順の４つのステップを示す。 例示的な一実施形態による非競合ベースのランダムアクセス手順の３つのステップを示す。 ＴＳ ５Ｇ．２１３ ｖ１．９の表５．２－１の再現である。 ＴＳ ５Ｇ．２１３ ｖ１．９の表５．２－２の再現である。 ＴＳ ５Ｇ．２１３ ｖ１．９の表５．２－３の再現である。 ＴＳ ５Ｇ．２１３ ｖ１．９の表８．３．３．１－１の再現である。 ＴＳ ５Ｇ．２１３ ｖ１．９の表８．４．３．１－１の再現である。 ＴＳ ５Ｇ．２１３ ｖ１．９の表８．４．３．２－１の再現である。 例示的な一実施形態による図である。 例示的な一実施形態による図である。 ３ＧＰＰ Ｒ２－１６３８７９の図１の一部の再現である。 ３ＧＰＰ Ｒ２－１６３８７９の図１の一部の再現である。 ３ＧＰＰ Ｒ２－１６２２１０の図３の再現である。 ３ＧＰＰ Ｒ２－１６３４７１の図１の再現である。 例示的な一実施形態による図である。 ３ＧＰＰ Ｒ２－１６２２５１の図３の再現である。 ３ＧＰＰ Ｒ２－１６２２５１の図４の再現である。 例示的な一実施形態によるフローチャートである。 例示的な一実施形態によるフローチャートである。 例示的な一実施形態によるフローチャートである。 例示的な一実施形態によるフローチャートである。 例示的な一実施形態によるフローチャートである。 例示的な一実施形態によるフローチャートである。 例示的な一実施形態によるフローチャートである。 例示的な一実施形態によるフローチャートである。 例示的な一実施形態によるフローチャートである。

以下に記載される例示的な無線通信システム及び機器は、無線通信システムを採用し、ブロードキャストサービスをサポートする。無線通信システムは、音声、データ等の様々なタイプの通信を提供するため、広く展開されている。これらのシステムは、符号分割多元接続（ＣＤＭＡ）、時間分割多元接続（ＴＤＭＡ）、直交周波数分割多元接続（ＯＦＤＭＡ）、３ＧＰＰ ＬＴＥ（ロングタームエボリューション）無線アクセス、３ＧＰＰ ＬＴＥ－Ａ若しくはＬＴＥ－アドバンスト（ロングタームエボリューションアドバンスト）、３ＧＰＰ２ ＵＭＢ（Ultra Mobile Broadband：超モバイル広帯域）、ＷｉＭａｘ、又はその他何らかの変調技術に基づいてよい。

特に、以下に説明する例示的な無線通信システム及びデバイスは、本明細書において３ＧＰＰと称される「第３世代パートナーシッププロジェクト」という名称のコンソーシアムにより提供された標準等、１つ以上の標準をサポートするように設計されてよい。標準には、R2-162366, “Beam Forming Impacts”, Nokia and Alcatel-Lucent、R2-163716, “Discussion on terminology of beamforming based high frequency NR”, Samsung、R2-162709, “Beam support in NR”, Intel、R2-162762, “Active Mode Mobility in NR: SINR drops in higher frequencies”, Ericsson、R3-160947, TR 38.801 V0.1.0, “Study on New Radio Access Technology; Radio Access Architecture and Interfaces”、R2-164306, “Summary of email discussion [93bis#23][NR] Deployment scenarios”, NTT DOCOMO、3GPP RAN2#94 meeting minute、R2-163879, “RAN2 Impacts in HF-NR”, MediaTeK、R2-162210, “Beam level management <-> Cell level mobility”, Samsung、 R2-163471, “Cell concept in NR”, CATT、R2-164270, “General considerations on LTE-NR tight interworking”, Huawei、R2-162251, “RAN2 aspects of high frequency New RAT”, Samsung、R1-165364, “Support for Beam Based Common Control Plane”, Nokia and Alcatel-Lucent Shanghai Bell、TS 36.321 V13.2.0, “Medium Access Control (MAC) protocol specification”、TS 36.300 v13.4.0, “E-UTRA and E-UTRAN、 Overall description; Stage 2”、TS 36.213 v13.2.0, “E-UTRA; Physical layer procedures”、及びR2-168856, “Text Proposal to TR 38.804 on UE states and state transitions for NR”, NTT DoCoMoが含まれる。

さらに、以下で説明する例示的な無線通信システム及びデバイスは、様々な文書で論じられている無線技術用であってよい。文書には、TS 5G.211 v2.6, “KT 5G Physical channels and modulation (Release 1)”、TS 5G.212 v2.3, “KT 5G Physical Layer Multiplexing and channel coding (Release 1)”、TS 5G.213 v1.9, “KT 5G Physical layer procedures (Release 1)”、及びTS 5G.321 v1.2, “KT 5G MAC protocol specification (Release 1)”が含まれる。

上掲の標準及び文書は、全体として参照により本明細書に明示的に援用される。

図１は、本発明の一実施形態に係る多重アクセス無線通信システムを示している。アクセスネットワーク１００（ＡＮ）は、複数のアンテナグループを含み、あるグループは１０４及び１０６、別のグループは１０８及び１１０、また別のグループは１１２及び１１４を含む。図１においては、各アンテナグループに対して、アンテナが２つしか示されていないが、より多くの又はより少ないアンテナが各アンテナグループに利用されてよい。アクセス端末１１６（ＡＴ）は、アンテナ１１２及び１１４と通信しており、アンテナ１１２及び１１４は、順方向リンク１２０を介して情報をアクセス端末１１６に送信すると共に、逆方向リンク１１８を介して情報をアクセス端末１１６から受信している。アクセス端末（ＡＴ）１２２は、アンテナ１０６及び１０８と通信しており、アンテナ１０６及び１０８は、順方向リンク１２６を介して情報をアクセス端末（ＡＴ）１２２に送信すると共に、逆方向リンク１２４を介して情報をアクセス端末（ＡＴ）１２２から受信している。ＦＤＤシステムにおいては、通信リンク１１８、１２０、１２４、及び１２６は通信に異なる周波数を使用してよい。例えば、順方向リンク１２０では、逆方向リンク１１８によって使用される周波数とは異なる周波数を使用してよい。

アンテナの各グループ及び／又はアンテナが通信するように設計されたエリアは、アクセスネットワークのセクターと称することが多い。本実施形態において、アンテナグループはそれぞれ、アクセスネットワーク１００によってカバーされるエリアのセクターにおいて、アクセス端末と通信するように設計されている。

順方向リンク１２０及び１２６を介した通信において、アクセスネットワーク１００の送信アンテナは、異なるアクセス端末１１６及び１２２に対する順方向リンクの信号対雑音比を改善するために、ビームフォーミングを利用してよい。また、カバレッジにランダムに分散したアクセス端末への送信にビームフォーミングを使用するアクセスネットワークは、１つのアンテナからすべてのそのアクセス端末に送信を行うアクセスネットワークよりも、隣接セルのアクセス端末への干渉が少ない。

アクセスネットワーク（ＡＮ）は、端末と通信するのに使用される固定局又は基地局でよく、アクセスポイント、ノードＢ、基地局、拡張型基地局、進化型ノードＢ（ｅＮＢ）、又はその他何らかの専門用語で呼ばれることもある。アクセス端末（ＡＴ）は、ユーザ機器（ＵＥ）、無線通信デバイス、端末、アクセス端末、又はその他何らかの専門用語で呼ばれることもある。

図２は、ＭＩＭＯシステム２００における送信機システム２１０（アクセスネットワークとしても知られている）及び受信機システム２５０（アクセス端末（ＡＴ）又はユーザ機器（ＵＥ）としても知られている）の実施形態の簡易ブロック図である。送信機システム２１０では、多くのデータストリームのトラフィックデータがデータ源２１２から送信（ＴＸ）データプロセッサ２１４に提供される。

一実施形態において、各データストリームは、それぞれの送信アンテナを介して送信される。ＴＸデータプロセッサ２１４は、データストリームに対して選択された特定の符号化方式に基づいて、各データストリームについてのトラフィックデータをフォーマット、符号化、及びインターリーブして、符号化データを提供する。

各データストリームについての符号化データを、ＯＦＤＭ技術を使用してパイロットデータと多重化してよい。パイロットデータは、代表的には、既知の様態で処理される既知のデータパターンであり、受信機システムでチャネル応答を推定するのに使用されてよい。そして、各データストリームについての多重化パイロット及び符号化データは、データストリームに対して選択された特定の変調方式（例えば、ＢＰＳＫ、ＱＰＳＫ、Ｍ－ＰＳＫ、又はＭ－ＱＡＭ）に基づいて変調（すなわち、シンボルマッピング）されて、変調シンボルを提供する。各データストリームについてのデータレート、符号化、及び変調は、プロセッサ２３０により実行される命令によって決定されてよい。

そして、すべてのデータストリームについての変調シンボルはＴＸ ＭＩＭＯプロセッサ２２０に与えられ、これが（例えば、ＯＦＤＭの場合に）変調シンボルをさらに処理してよい。そして、ＴＸ ＭＩＭＯプロセッサ２２０は、Ｎ_Ｔ個の変調シンボルストリームをＮ_Ｔ個の送信機（ＴＭＴＲ）２２２ａ～２２２ｔに提供する。特定の実施形態において、ＴＸ ＭＩＭＯプロセッサ２２０は、ビームフォーミング加重をデータストリームのシンボル及びシンボルが送信されているアンテナに適用する。

各送信機２２２は、各シンボルストリームを受信及び処理して１つ以上のアナログ信号を提供し、さらに、アナログ信号を調節（例えば、増幅、フィルタリング、及びアップコンバート）して、ＭＩＭＯチャネルを介した送信に適した変調信号を提供する。そして、送信機２２２ａ～２２２ｔからのＮ_Ｔ個の変調信号がそれぞれ、Ｎ_Ｔ個のアンテナ２２４ａ～２２４ｔから送信される。

受信機システム２５０においては、送信された変調信号はＮ_Ｒ個のアンテナ２５２ａ～２５２ｒによって受信され、各アンテナ２５２からの受信信号は、各受信機（ＲＣＶＲ）２５４ａ～２５４ｒに提供される。各受信機２５４は、それぞれの受信信号を調節（例えば、フィルタリング、増幅、及びダウンコンバート）して、調節された信号をデジタル化してサンプルを与え、さらに、これらのサンプルを処理して対応する「受信」シンボルストリームを提供する。

そして、ＲＸデータプロセッサ２６０は、特定の受信機処理技術に基づいて、Ｎ_Ｒ個の受信機２５４からのＮ_Ｒ個の受信シンボルストリームを受信及び処理して、Ｎ_Ｔ個の「検出」シンボルストリームを提供する。そして、ＲＸデータプロセッサ２６０は、各検出シンボルストリームを復調、デインターリーブ、及び復号して、データストリームについてのトラフィックデータを復元する。ＲＸデータプロセッサ２６０による処理は、送信機システム２１０でのＴＸ ＭＩＭＯプロセッサ２２０及びＴＸデータプロセッサ２１４により実行される処理と相補的である。

プロセッサ２７０は、どのプリコーディングマトリクス（後述）使用するかを定期的に決定する。プロセッサ２７０は、マトリクス指標部及びランク値部を含む逆方向リンクメッセージを構築する。

逆方向リンクメッセージは、通信リンク及び／又は受信データストリームに関する様々なタイプの情報を含んでよい。そして、逆方向リンクメッセージは、データ源２３６からの多くのデータストリームについてのトラフィックデータも受信するＴＸデータプロセッサ２３８により処理され、変調器２８０により変調され、送信機２５４ａ～２５４ｒにより調節され、送信機システム２１０に送り戻される。

送信機システム２１０では、受信機システム２５０からの変調信号がアンテナ２２４により受信され、受信機２２２により調節され、復調器２４０により復調され、ＲＸデータプロセッサ２４２により処理されて、受信機システム２５０により送信された逆方向リンクメッセージを抽出する。そして、プロセッサ２３０は、ビームフォーミング加重を決定するのにどのプリコーディングマトリクスを使用するかを決定し、そして、抽出されたメッセージを処理する。

図３を参照すると、この図は、本発明の一実施形態による通信デバイスの代替的な簡易機能ブロック図を示している。図３に示されるように、無線通信システムにおける通信デバイスは、図１のＵＥ（若しくはＡＴ）１１６及び１２２又は図１の基地局（若しくはＡＮ）１００を実現するのに利用可能であり、無線通信システムは、ＬＴＥシステムであることが好ましい。通信デバイスは、入力デバイス３０２、出力デバイス３０４、制御回路３０６、中央演算処理装置（ＣＰＵ）３０８、メモリ３１０、プログラムコード３１２、及びトランシーバ３１４を含んでよい。制御回路３０６は、ＣＰＵ３０８を介してメモリ３１０内のプログラムコード３１２を実行することにより、通信デバイスの動作を制御する。通信デバイス３００は、キーボード、キーパッド等の入力デバイス３０２を介してユーザにより入力された信号を受信することができ、モニタ、スピーカ等の出力デバイス３０４を介して画像及び音声を出力することができる。トランシーバ３１４は、無線信号を受信及び送信するのに使用され、受信信号を制御回路３０６に伝達すると共に、制御回路３０６により生成された信号を無線で出力する。無線通信システムにおける通信デバイス３００は、図１のＡＮ１００を実現するのにも利用可能である。

図４は、本発明の一実施形態による図３に示すプログラムコード３１２の簡易ブロック図である。本実施形態において、プログラムコード３１２は、アプリケーションレイヤ４００、レイヤ３部４０２、及びレイヤ２部４０４を含み、レイヤ１部４０６に結合されている。レイヤ３部４０２は一般的に、無線リソース制御を実行する。レイヤ２部４０４は一般的に、リンク制御を実行する。レイヤ１部４０６は一般的に、物理的接続を実行する。

次世代（すなわち、５Ｇ）アクセス技術に関する３ＧＰＰ標準化活動は、２０１５年３月から開始されている。一般的に、次世代アクセス技術は、緊急の市場ニーズとＩＴＵ－Ｒ ＩＭＴ－２０２０によって規定されたより長期的な要求事項の両方を満たすために次の３つの使用シナリオファミリをサポートすることを目指している。
－ ｅＭＢＢ（enhanced Mobile Broadband：高度モバイルブロードバンド）
－ ｍＭＴＣ（massive Machine Type Communications：大量機械型通信）
－ ＵＲＬＬＣ（Ultra-Reliable and Low Latency Communications：超信頼・低遅延通信）。

一般に、新しい無線アクセス技術に関する５Ｇ研究項目の目的は、少なくとも１００ＧＨｚまでの範囲にわたる任意のスペクトル帯域を使用することを可能にし得る新しい無線システムに必要な技術コンポーネントを識別し、開発することである。１００ＧＨｚまでのキャリア周波数をサポートすることにより、無線伝搬の領域において多くの課題が生じる。キャリア周波数が増加すると、パスロスも増加する。

３ＧＰＰ Ｒ２－１６２３６６に基づくと、より低い周波数帯域（例えば、現在のＬＴＥ帯域＜６ＧＨｚ）では、必要なセルカバレッジは、下りリンク共通チャネルを送信するためのワイドセクタビームを形成することによって提供することができる。しかし、より高い周波数（＞６ＧＨｚ）でワイドセクタビームを利用すると、同じアンテナ利得ではセルカバレッジが小さくなる。したがって、より高い周波数帯域で必要なセルカバレッジを提供するためには、増加したパスロスを補償するためにより高いアンテナ利得が必要である。ワイドセクタビームにわたってアンテナ利得を増加させるためには、より大きいアンテナアレイ（数十から数百までの範囲にわたるアンテナ素子の数を有する）が高利得ビームを形成するのに使用される。

結果として、高利得ビームは、ワイドセクタビームに比べて狭いため、必要なセル領域をカバーするために、下りリンク共通チャネルを送信するための複数のビームが必要である。アクセスポイントが形成することができる同時高利得ビームの数は、利用されるトランシーバアーキテクチャのコスト及び複雑さによって制限され得る。実際には、より高い周波数では、同時高利得ビームの数は、セル領域をカバーするのに必要なビームの総数よりもはるかに少ない。言い換えると、アクセスポイントは、任意の時点でビームのサブセットを使用してセル領域の一部のみをカバーすることが可能である。

３ＧＰＰ Ｒ２－１６３７１６で論じられたように、ビームフォーミングは、指向性信号の送信／受信のためのアンテナアレイで使用される信号処理技術である。ビームフォーミングを用いると、特定の角度の信号が強め合う干渉を経験し、他のものが弱め合う干渉を経験するように、アンテナのフェーズドアレイの素子を組み合わせることによって、ビームが形成され得る。複数のアンテナアレイを使用して異なるビームが同時に利用され得る。

３ＧＰＰ Ｒ２－１６２７０９で論じられ、図５（これは、３ＧＰＰ Ｒ２－１６２７０９の図１の再現である）に示すように、ｅＮＢ（進化型ノードＢ）は、複数のＴＲＰ（集中型又は分散型）を有することができる。各ＴＲＰ（送信／受信ポイント）は、複数のビームを形成することができる。ビームの数及び時間／周波数領域における同時ビームの数は、ＴＲＰでのアンテナアレイ素子の数及びＲＦ（無線周波数）に依存する。

ＮＲ（New Radio：新しい無線）について可能性のあるモビリティタイプは、以下のように列挙することができる：
・ ＴＲＰ内モビリティ
・ ＴＲＰ間モビリティ
・ ＮＲ ｅＮＢ間モビリティ

Ｒ２－１６２７６２で論じられたように、ビームフォーミングに純粋に依存し、より高い周波数で動作するシステムの信頼性は、挑戦的なものとなるかもしれない。これは、カバレッジが時間及び空間の変動に対してより敏感となるかもしれないためである。結果として、狭リンクのＳＩＮＲ（Signal to Interference Plus Noise Ratio：信号対干渉雑音比）は、ＬＴＥの場合よりもはるかに急速に低下する可能性がある。

アクセスノードで数百の素子の数を有するアンテナアレイを使用すると、ノード当たり数十又は数百の候補ビームを有するかなり規則的なグリッドビームカバレッジパターンを作成することができる。そのようなアレイからの個々のビームのカバレッジエリアは、幅数十メートルのオーダにまで小さくなる可能性がある。結果として、現在のサービングビーム領域外のチャネル品質劣化は、ＬＴＥによって提供されるようなワイドエリアカバレッジの場合よりも急速である。

３ＧＰＰ ＴＳ ３６．３００で論じられたように、ＬＴＥでは、Ｐｃｅｌｌ（プライマリセル）に関連する以下のイベントに対してランダムアクセス手順が実行される：
－ ＲＲＣ＿ＩＤＬＥからの初期アクセス
－ ＲＲＣ接続再確立手順
－ ハンドオーバ
－ ランダムアクセス手順を必要とするＲＲＣ＿ＣＯＮＮＥＣＴＥＤ中のＤＬデータ到着：
－ 例えば、ＵＬ同期ステータスが「非同期」であるとき
－ ランダムアクセス手順を必要とするＲＲＣ＿ＣＯＮＮＥＣＴＥＤ中のＵＬデータ到着：
－ 例えば、ＵＬ同期ステータスが「非同期」であるか、又は利用可能なＳＲ用のＰＵＣＣＨリソースがないとき
－ ランダムアクセス手順を必要とするＲＲＣ＿ＣＯＮＮＥＣＴＥＤ中の測位目的の場合
－ 例えば、ＵＥ測位のためにタイミングアドバンスが必要であるとき
ランダムアクセス手順は、対応するｓＴＡＧ（セカンダリＴＡＧ）についてのタイムアライメントを確立するために、ＳＣｅｌｌ（セカンダリセル）上でも実行される。さらに、ランダムアクセス手順は、２つの異なる形式をとる：
－ 競合ベース（最初の５つのイベントに適用可能）。
－ 非競合ベース（ハンドオーバ、ＤＬデータ到着、測位、ｓＴＡＧのためのタイミングアドバンスアライメントの取得のみに適用可能）

通常のＤＬ／ＵＬ（下りリンク／上りリンク）送信は、ランダムアクセス手順の後に行うことができる。

ＬＴＥでは、競合ベース及び競合フリー（非競合ベース）の２つのタイプのＲＡ手順が定義されている。（図６に示すように）競合ベースのランダムアクセス手順の４つのステップは次のようである：
１） 上りリンク（Ｍｓｇ１）におけるＲＡＣＨ上のランダムアクセスプリアンブル：
－ ２つの可能なグループが定義され、１つはオプションである。両方のグループが構成されている場合は、メッセージ３のサイズ及びパスロスが使用されて、プリアンブルがどのグループから選択されるかを決定する。プリアンブルが属するグループは、メッセージ３のサイズ及びＵＥでの無線状態の指示を提供する。プリアンブルグループ情報は、必要なしきい値とともに、システム情報上にブロードキャストされる。
２） ＤＬ－ＳＣＨ（Ｍｓｇ２）でＭＡＣによって生成されるランダムアクセス応答：
－ メッセージ１と半同期（サイズが１つ以上のＴＴＩであるフレキシブルなウィンドウ内）
－ ＨＡＲＱなし
－ ＰＤＣＣＨ上でＲＡ－ＲＮＴＩにあてられる
－ 少なくともＲＡプリアンブル識別子、ｐＴＡＧについてのタイミングアライメント情報、初期ＵＬグラント、一時的Ｃ－ＲＮＴＩの割り当て（競合解決時に永続化されてもされなくてもよい）を搬送
－ １つのＤＬ－ＳＣＨメッセージにおいて可変数のＵＥを対象
３） ＵＬ－ＳＣＨ（Ｍｓｇ３）で最初にスケジューリングされたＵＬ送信：
－ ＨＡＲＱを使用
－ トランスポートブロックのサイズは、ステップ２で搬送されたＵＬグラントに依存
－ 初期アクセスの場合：
－ ＲＲＣレイヤによって生成され、ＣＣＣＨを介して送信されるＲＲＣ接続要求を搬送
－ 少なくともＮＡＳ ＵＥ識別子を搬送するが、ＮＡＳメッセージは搬送なし
－ ＲＬＣ ＴＭ：セグメント化なし
－ ＲＲＣ接続再確立手順の場合：
－ ＲＲＣレイヤによって生成され、ＣＣＣＨを介して送信されるＲＲＣ接続再確立要求を搬送
－ ＲＬＣ ＴＭ：セグメント化なし
－ いかなるＮＡＳメッセージを含まず
－ ハンドオーバ後、ターゲットセル内：
－ ＲＲＣレイヤによって生成され、ＤＣＣＨを介して送信される暗号化された完全性保護ＲＲＣハンドオーバ確認を搬送
－ （ハンドオーバーコマンドによって割り当てられた）ＵＥのＣ－ＲＮＴＩを搬送
－ 可能であるとき、上りリンクバッファステータス報告を含む
－ 他のイベントの場合：
－ 少なくともＵＥのＣ－ＲＮＴＩを搬送
４）ＤＬ（Ｍｓｇ４）で競合解決：
－ 早期の競合解決が使用されるものとする。すなわち、ｅＮＢはＮＡＳ応答を待つことなく競合解決を行う
－ メッセージ３と非同期
－ ＨＡＲＱをサポート
－ 以下にあてられる：
－ 初期アクセス及び無線リンク障害後のＰＤＣＣＨ上の一時的Ｃ－ＲＮＴＩ
－ ＲＲＣ＿ＣＯＮＮＥＣＴＥＤでのＵＥについてのＰＤＣＣＨ上のＣ－ＲＮＴＩ
－ ＨＡＲＱフィードバックは、メッセージ３で提供されるように、自身のＵＥアイデンティティを検出するＵＥによってのみ送信され、競合解決メッセージにエコーされる
－ 初期アクセス及びＲＲＣ接続再確立手順では、セグメント化は使用されない（ＲＬＣ－ＴＭ）
ＲＡ成功を検出し、Ｃ－ＲＮＴＩを有しないＵＥは、一時的Ｃ－ＲＮＴＩをＣ－ＲＮＴＩに促進する。ＲＡ成功を検出し、既にＣ－ＲＮＴＩを有しているＵＥは、そのＣ－ＲＮＴＩを使用して再開し、一時的Ｃ－ＲＮＴＩをドロップする。

（図７に示すように）非競合ベースのランダムアクセス手順の３つのステップは次のようである：
０） ＤＬ（Ｍｓｇ０）における専用シグナリングを介したランダムアクセスプリアンブル割り当て：
－ ｅＮＢは、非競合ランダムアクセスプリアンブル（ランダムアクセスプリアンブルは、ブロードキャストシグナリングにおいて送信されたセット内にはない）をＵＥに割り当て
－ 次を介したシグナリング：
－ ターゲットｅＮＢによって生成され、ハンドオーバのためのソースｅＮＢを介して送信されるＨＯコマンド
－ ＤＬデータの到着又は測位の場合のＰＤＣＣＨ
－ ｓＴＡＧについての初期ＵＬタイムアライメントのためのＰＤＣＣＨ
１） 上りリンク（Ｍｓｇ１）におけるＲＡＣＨ上のランダムアクセスプリアンブル：
－ ＵＥは、割り当てられた非競合ランダムアクセスプリアンブルを送信
２） ＤＬ－ＳＣＨ（Ｍｓｇ２）のランダムアクセス応答：
－ メッセージ１と半同期（サイズが２つ以上のＴＴＩであるフレキシブルなウィンドウ内）
－ ＨＡＲＱなし
－ ＰＤＣＣＨ上でＲＡ－ＲＮＴＩにあてられる
－ 少なくとも次を搬送：
－ ハンドオーバためのタイミングアライメント情報及び初期ＵＬグラント。

－ ＤＬデータ到着のためのタイミングアライメント情報
－ ＲＡプリアンブル識別子
－ １つのＤＬ－ＳＣＨメッセージにおいて１つ以上のＵＥを対象

ＬＴＥにおけるＤＲＸは、３ＧＰＰ ＴＳ ３６．３２１において次のように説明される。
５．７ 間欠受信（ＤＲＸ）
ＭＡＣエンティティは、ＭＡＣエンティティのＣ－ＲＮＴＩ、ＴＰＣ－ＰＵＣＣＨ－ＲＮＴＩ、ＴＰＣ－ＰＵＳＣＨ－ＲＮＴＩ、セミパーシステントスケジューリングＣ－ＲＮＴＩ（設定される場合）ｅＩＭＴＡ－ＲＮＴＩ（設定される場合）及びＳＬ－ＲＮＴＩ（設定される場合）のためのＵＥのＰＤＣＣＨ監視アクティビティを制御するＤＲＸ機能でＲＲＣによって設定されてよい。ＲＲＣ＿ＣＯＮＮＥＣＴＥＤにある場合、ＤＲＸが設定されるとき、ＭＡＣエンティティはこの項で指定されるＤＲＸ動作を使用してＰＤＣＣＨを間欠的に監視することが許可される。そうでなければ、ＭＡＣエンティティはＰＤＣＣＨを連続的に監視する。ＤＲＸ動作を使用する場合、ＭＡＣエンティティはまた、本仕様書の他の項に見られる要件に従ってＰＤＣＣＨを監視するものとする。ＲＲＣは、onDurationTimer（オン持続時間タイマ）、drx-InactivityTimer（ＤＲＸ非アクティブタイマ）、drx-RetransmissionTimer（ＤＲＸ再送タイマ）（ブロードキャストプロセスを除くＤＬ ＨＡＲＱプロセスごとに１つ）、drx-ULRetransmissionTimer（ＤＲＸ ＵＬ再送タイマ）（非同期ＵＬ ＨＡＲＱプロセスごとに１つ）、longDRX-Cycle（ロングＤＲＸサイクル）、drxStartOffsetの値、及びオプションで、drxShortCycleTimerとshortDRX-Cycle（ショートＤＲＸサイクル）のタイマを設定することによってＤＲＸ動作を制御する。また、（ブロードキャストプロセスを除く）ＤＬ ＨＡＲＱプロセスごとのＨＡＲＱ ＲＴＴタイマ及び非同期ＵＬ ＨＡＲＱプロセス当たりのＵＬ ＨＡＲＱ ＲＴＴタイマが定義される（第７．７項参照）。
ＤＲＸサイクルが設定される場合、アクティブ時間は以下の時間を含む：
－ onDurationTimer、drx-InactivityTimer、drx-RetransmissionTimer、drx-ULRetransmissionTimer、又はmac-ContentionResolutionTimer（第５．１．５項に記載）が動作している；
－ スケジューリング要求がＰＵＣＣＨで送信され、保留している（第５．４．４項に記載）
－ 保留しているＨＡＲＱ再送信に対する上りリンクグラントが発生する可能性があり、同期ＨＡＲＱプロセスに対する対応するＨＡＲＱバッファにデータが存在；あるいは
－ ＭＡＣエンティティによって選択されていないプリアンブルに対するランダムアクセス応答を首尾よく受信した後で、ＭＡＣエンティティのＣ－ＲＮＴＩ宛ての新しい送信を示すＰＤＣＣＨが受信されていない（第５．１．４項に記載）。
ＤＲＸが設定される場合、ＭＡＣエンティティは各サブフレームに対して次のことを行うものとする：
－ このサブフレームでＨＡＲＱ ＲＴＴタイマが期限切れになるとき：
－ 対応するＨＡＲＱプロセスのデータが首尾よく復号されなかったとき：
－ 対応するＨＡＲＱプロセスに対するdrx-RetransmissionTimerを開始する；
－ ＮＢ－ＩｏＴであるとき、drx-InactivityTimerを開始、又は再開する。
－ このサブフレームでＵＬ ＨＡＲＱ ＲＴＴタイマが期限切れになるとき：
－ 対応するＨＡＲＱプロセスに対するdrx-ULRetransmissionTimerを開始する。
－ ＮＢ－ＩｏＴであるとき、drx-InactivityTimerを開始、又は再開する。
－ ＤＲＸコマンドＭＡＣ制御要素又はロングＤＲＸコマンドＭＡＣ制御要素が受信されるとき：
－ onDurationTimerを停止する；
－ drx-InactivityTimerを停止する。
－ このサブフレームでdrx-InactivityTimerが期限切れになる、あるいはＤＲＸコマンドＭＡＣ制御要素が受信されるとき：
－ Short DRX cycleが設定されるとき：
－ drxShortCycleTimerを開始、又は再開する；
－ Short DRX cycleを使用する。
－ それ以外：
－ Long DRX cycleを使用する。
－ このサブフレームでdrxShortCycleTimerが期限切れになるとき：
－ Long DRX cycleを使用する。
－ ロングＤＲＸコマンドＭＡＣ制御要素が受信される場合：
－ drxShortCycleTimerを停止する；
Long DRX cycleを使用する。
－ Short DRX Cycleが使用され、[(SFN*10)+サブフレーム番号]modulo(shortDRX-Cycle)=（drxStartOffset）modulo（shortDRX-Cycle）のとき、又は
－ Long DRX Cycleが使用され、[(SFN*10)+サブフレーム番号]modulo(longDRX-Cycle)=drxStartOffsetのとき：
－ onDurationTimerを開始する。
－ アクティブ時間中、ＰＤＣＣＨサブフレームに対して、サブフレームが半二重ＦＤＤ ＵＥ動作のための上りリンク送信に必要ではないとき、サブフレームが半二重ガードサブフレーム［７］ではないとき、サブフレームが設定された測定ギャップの一部ではないとき、サブフレームが受信のための設定されたサイドリンクディスカバリギャップの一部ではないとき、及びＮＢ－ＩｏＴに対して、サブフレームが上りリンク送信又はＰＤＣＣＨ以外で下りリンク受信に必要ではないとき；
－ アクティブ時間中、ＰＤＣＣＨサブフレーム以外のサブフレームに対して、かつ集約セル内で同時に受信及び送信が可能なＵＥに対して、サブフレームがschedulingCellId[8]で設定されていない少なくとも１つのサービングセルに対する有効なｅＩＭＴＡ Ｌ１シグナリングによって示される下りリンクサブフレームであるとき、サブフレームが設定された測定ギャップの一部ではないとき、及びサブフレームが受信のための設定されたサイドリンクディスカバリギャップの一部ではないとき、又は
－ アクティブ時間中、ＰＤＣＣＨサブフレーム以外のサブフレームに対して、かつ集約セル内で同時に受信及び送信することができないＵＥに対して、サブフレームがＳｐＣｅｌｌに対する有効なｅＩＭＴＡ Ｌ１シグナリングによって示される下りリンクサブフレームであるとき、サブフレームが設定された測定ギャップの一部ではないとき、及びサブフレームが受信のための設定されたサイドリンクディスカバリギャップの一部ではない場合：
－ ＰＤＣＣＨを監視する。
－ ＰＤＣＣＨがＤＬ送信を示すとき、又はこのサブフレームに対してＤＬ割り当てが設定されているとき：
－ ＵＥがＮＢ－ＩｏＴ ＵＥ、ＢＬ ＵＥ、又は拡張カバレッジのＵＥのとき
－ 対応するＰＤＳＣＨ受信の最後の繰り返しを含むサブフレーム内の対応するＨＡＲＱプロセスのためのＨＡＲＱ ＲＴＴタイマを開始する；
－ それ以外：
－ 対応するＨＡＲＱプロセスのためのＨＡＲＱ ＲＴＴタイマを開始する；
－ 対応するＨＡＲＱプロセスのためのdrx-RetransmissionTimerを停止する。
－ ＰＤＣＣＨが非同期ＨＡＲＱプロセスのためのＵＬ送信を示すとき：
－ 対応するＰＵＳＣＨ送信の最後の繰り返しを含むサブフレーム内の対応するＨＡＲＱプロセスのためのＵＬ ＨＡＲＱ ＲＴＴタイマを開始する；
－ 対応するＨＡＲＱプロセスのためのdrx-ULRetransmissionTimerを停止する。
－ ＰＤＣＣＨが新しい送信（ＤＬ、ＵＬ、又はＳＬ）を示すとき：
－ ＮＢ－ＩｏＴを除き、drx-InactivityTimerを開始又は再開する。
－ ＰＤＣＣＨがＮＢ－ＩｏＴ ＵＥのための送信（ＤＬ、ＵＬ）を示す場合：
－ drx-InactivityTimer、drx-ULRetransmissionTimer、及びonDurationTimerを停止する。
－ 現在のサブフレームｎにおいて、この項で指定されるすべてのＤＲＸアクティブ時間条件を評価する場合、サブフレームｎ－５を含み、それまでに受信されたグラント／割り当て／ＤＲＸコマンドＭＡＣ制御要素／ロングＤＲＸコマンドＭＡＣ制御要素、及び送信されたスケジューリング要求を考慮してＭＡＣエンティティがアクティブ時間にないとき、タイプ０トリガのＳＲＳ［２］は報告されないものとする。
－ ＣＱＩマスキング（cqi-Mask）が上位レイヤによって設定されるとき：
－ 現在のサブフレームｎにおいて、この項で指定されるすべてのＤＲＸアクティブ時間条件を評価する場合、サブフレームｎ－５を含み、それまでに受信されたグラント／割り当て／ＤＲＸコマンドＭＡＣ制御要素／ロングＤＲＸコマンドＭＡＣ制御要素を考慮してonDurationTimerが実行中とならないとき、ＰＵＣＣＨでのＣＱＩ／ＰＭＩ／ＲＩ／ＰＴＩ／ＣＲＩは報告されないものとする。
－ それ以外：
－ 現在のサブフレームｎにおいて、この項で指定されるすべてのＤＲＸアクティブ時間条件を評価する場合、サブフレームｎ－５を含み、それまでに受信されたグラント／割り当て／ＤＲＸコマンドＭＡＣ制御要素／ロングＤＲＸコマンドＭＡＣ制御要素及び送信されたスケジューリング要求を考慮してＭＡＣエンティティがアクティブ時間にないとき、ＰＵＣＣＨでのＣＱＩ／ＰＭＩ／ＲＩ／ＰＴＩ／ＣＲＩは報告されないものとする。
ＭＡＣエンティティがＰＤＣＣＨを監視しているかどうかにかかわらず、ＭＡＣエンティティはＨＡＲＱフィードバックを送信及び受信し、そのようなことが期待される場合タイプ１トリガＳＲＳ［２］を送信する。
注：同じアクティブ時間が、アクティブにされているすべてのサービングセルに適用される。
注：下りリンク空間多重化の場合、ＨＡＲＱ ＲＴＴタイマの実行中にＴＢが受信され、同じＴＢの以前の送信が現在のサブフレームの少なくともＮサブフレーム前に受信された場合（ＮはＨＡＲＱ ＲＴＴタイマに対応する）、ＭＡＣエンティティはそれを処理し、ＨＡＲＱ ＲＴＴタイマを再開すべきである。
注：ＢＬ ＵＥと拡張カバレッジのＵＥは、設定されたＭＰＤＣＣＨサーチスペースの最後のサブフレームまで待機してから、次に指定されたアクションを実行する。

ＫＴ ５Ｇ ＰＨＹ仕様でのビームフォーミング手順は、ＴＳ ５Ｇ．２１３において次のように説明される。
（外２－１）

（外２－２）

“BRRS resource allocation field for xPDCCH with DL or UL DCI”と題する、ＴＳ ５Ｇ．２１３ ｖ１．９の表５．２－１は、図８として再現されている。
“BRRS process indication field for xPDCCH with DL or UL DCI”と題する、ＴＳ ５Ｇ．２１３ ｖ１．９の表５．２－２は、図９として再現されている。
（外３）

“BR process configuration”と題する、ＴＳ ５Ｇ．２１３ ｖ１．９の表５．２－３は、図１０として再現されている。
（外４－１）

（外４－２）

“7-bit BRSRP Table”と題する、ＴＳ ５Ｇ．２１３ ｖ１．９の表８．３．３．１－１は、図１１として再現されている。
（外５）

“7-bit BRRS-RP Table”と題する、ＴＳ ５Ｇ．２１３ ｖ１．９の表８．４．３．１－１は、図１２として再現されている。
（外６）

“BRRS-RI mapping”と題する、ＴＳ ５Ｇ．２１３ ｖ１．９の表８．４．３．２－１は、図１３として再現されている。

ＫＴ ５Ｇ ＭＡＣ仕様でのビーム管理及びＤＲＸは、ＴＳ ５Ｇ．３２１において次のように説明される。
５．５ ビーム管理
５．５．１ ビームフィードバック手順
ビームフィードバック手順は、ビーム測定結果をサービングセルに報告するために使用される。
２つのビームフィードバック手順が定義され、１つは、以下のビーム参照信号（ＢＲＳ）の測定に基づく、以下のビーム状態情報報告であり、１つは、ビームリファインメント参照信号（ＢＲＲＳ）の測定に基づく、以下のビームリファインメント情報報告である。

５．５．１．１．１ ビーム状態情報報告
ｘＰＤＣＣＨ命令によって開始されるＢＲＳベースのビーム状態情報（ＢＳＩ）報告は、対応するＤＣＩ［１］によってスケジューリングされるように、ｘＰＵＣＣＨ／ｘＰＵＳＣＨでのＵＣＩを通じて送信される；イベントトリガＢＳＩ報告は、通常のＳＲ又は競合ベースのＲＡＣＨ手順を使用して、第６．１．３．１１項で定義されるＢＳＩフィードバックＭＡＣ制御要素を通じて送信され、ＢＳＩはビームインデックス（ＢＩ）及びビーム参照信号受信電力（ＢＲＳＲＰ）からなる。ＢＳＩ報告は、サービングセルによって送信されるＢＲＳに基づく。
５．５．１．１．１ ｘＰＤＣＣＨ命令により開始されるＢＳＩ報告
ｘＰＤＣＣＨ命令によって開始されるＢＳＩ報告は、５Ｇの物理レイヤから得られる最新の測定結果に基づく。
－ サービングセルによってｘＰＵＣＣＨを介してＵＣＩを通じてＢＳＩ報告を要求するｘＰＤＣＣＨ命令がこのＴＴＩにおいて受信される場合：
－ サービングビームが最良のビームではなく、最良のビームのＢＲＳＲＰがサービングビームのＢＲＳＲＰよりも高い場合：
－ ［１］で定義されているように、ｘＰＵＣＣＨを介してスケジューリングされたＵＣＩリソースで最良のビームをシグナリングするように５Ｇ物理レイヤに指示する；
－ それ以外：
－ ［１］で定義されているように、ｘＰＵＣＣＨを介してスケジュールされたＵＣＩリソースでサービングビームをシグナリングするように５Ｇ物理レイヤに指示する；
－ サービングセルによってｘＰＵＳＣＨを介してＵＣＩを通じてＢＳＩ報告を要求するｘＰＤＣＣＨ命令がこのＴＴＩにおいて受信される場合：
－ 要求された報告に対するＢＳＩの数が１に等しい場合：
－ サービングビームが最良のビームではなく、最良のビームのＢＲＳＲＰがサービングビームのＢＲＳＲＰよりも高い場合：
－ ［１］で定義されているように、ｘＰＵＳＣＨを介してスケジューリングされたＵＣＩリソースで最良のビームをシグナリングするように５Ｇ物理レイヤに指示する；
－ それ以外：
－ ［１］で定義されているように、ｘＰＵＳＣＨを介してスケジューリングされたＵＣＩリソースでサービングビームをシグナリングするように５Ｇ物理レイヤに指示する；
－ それ以外、要求されたＢＳＩ報告の数が１より大きい場合、及び：
－ サービングビームが最良のビームではなく、最良のビームのＢＲＳＲＰがサービングビームのＢＲＳＲＰよりも高い場合：
－ ｘＰＵＳＣＨを介してスケジュールされたＵＣＩリソースでの最初のＢＳＩ及び次のＮ－１番目に高いＢＲＳＲＰビーム値として最良のビームを用いてＮ個のＢＳＩ報告をシグナリングするように５Ｇ物理レイヤに指示する；
－ それ以外：
－ ｘＰＵＳＣＨを介してスケジュールされたＵＣＩリソースでの最初のＢＳＩ及び次のＮ－１番目に高いＢＲＳＲＰビーム値としてサービングビームを用いてＮ個のＢＳＩ報告をシグナリングするように５Ｇ物理レイヤに指示する；

５．５．１．１．２ ５Ｇ－ＭＡＣによって開始されるＢＳＩ報告
５Ｇ－ＭＡＣによって開始されるＢＳＩ報告は、イベントトリガに基づく。
－ 最良のビームのＢＲＳＲＰが、beamTriggeringRSRPoffset ｄＢ＋サービングビームのＢＲＳＲＰより大きい場合、及び：
－ ＵＥが上りリンク同期される（すなわち、timeAlignmentTimerが期限切れになっていない）場合
－ ＵＥは、通常のＳＲ手順を通じてグラントされたＵＬリソースでＢＳＩフィードバックＭＡＣ制御要素を送信する。
－ それ以外：
－ ＵＥは、競合ベースのランダムアクセス手順を通じてグラントされたＭｓｇ３のためのＵＬリソースでＢＳＩフィードバックＭＡＣ制御要素を送信する。
５．５．１．２ ビームリファインメント情報報告
ビームリファインメント情報（ＢＲＩ）報告は、ｘＰＤＣＣＨ命令によって開始され、対応するＤＣＩ［１］によってスケジューリングされるｘＰＵＣＣＨ／ｘＰＵＳＣＨでのＵＣＩを通じて報告される。ＢＲＩは、サービングセルによって送信されるＢＲＲＳに基づいたリファインビームインデックス（ＲＢＩ）及びＢＲＳＲＰからなる。
－ サービングセルによってｘＰＵＣＣＨを介してＵＣＩを通じてＢＲＩ報告を要求するｘＰＤＣＣＨ命令が受信される場合：
－ ［１］で定義されているように、ｘＰＵＣＣＨを介してスケジュールされたＵＣＩリソースに関するＢＲＩ報告をシグナリングするように５Ｇ物理レイヤに指示する。
－ それ以外、サービングセルによってｘＰＵＳＣＨを介してＵＣＩを通してＢＲＩ報告を要求するｘＰＤＣＣＨ命令が受信される場合：
－ ［１］で定義されているように、ｘＰＵＳＣＨを介してスケジューリングされたＵＣＩリソースに関するＢＲＩ報告をシグナリングするように５Ｇ物理レイヤに指示する。
注：イベントトリガＢＲＩのフィードバックはサポートされない。
注：ｘＰＤＣＣＨ命令によって要求されるＢＳＩ／ＢＲＩフィードバックは、５Ｇ－ＭＡＣレイヤの報告手順には影響しない。

５．５．２ ビーム変更手順
ビーム変更手順は、ＵＥのためのサービングビームを変更するために、サービングセルによって使用される。サービングセルは、ｘＰＤＣＣＨ命令、ＢＲＳビーム変更指示ＭＡＣ制御要素、またはＢＲＲＳビーム変更指示ＭＡＣ制御要素によって手順を開始する。
各ＴＴＩに対して、５Ｇ－ＭＡＣエンティティは、以下のことを行うものとする：
－ beam_changeがこのＴＴＩに対してｘＰＤＣＣＨ命令で示されている場合：
－ 以前に送信された報告が５．５．１．２に従ったＢＲＩ報告であった場合：
－ ［１］で定義される時間kbeamswitch-delay-dciの後に報告された最も高いＢＲＳＲＰ値を有するＲＢＩに対応するビームに、サービングビームを変更するように５Ｇの物理レイヤに指示する；
－ それ以外で、以前に送信された報告が５．５．１．１に従ったＢＳＩ報告であった場合：
－ ［１］で定義される時間kbeamswitch-delay-dciの後に報告された最も高いＢＲＳＲＰ値を有するＢＩに対応するビームに、サービングビームを変更するように５Ｇの物理レイヤに指示する。
－ ６．１．３．９において定義されるようなＢＲＳビーム変更指示ＭＡＣ制御要素がこのＴＴＩにおいて受信されている場合：
－ ［１］で定義される時間kbeamswitch-delay-macの後に明示的にシグナリングされるＢＩに対応するビームに、サービングビームを変更するように５Ｇの物理レイヤに指示する。
－ ６．１．３．１０において定義されるようなＢＲＲＳビーム変更指示ＭＡＣ制御要素がこのＴＴＩにおいて受信されている場合：
－ ［１］で定義される時間kbeamswitch-delay-macの後に明示的にシグナリングされるＲＢＩに対応するビームに、サービングビームを変更するように５Ｇの物理レイヤに指示する。

５．５．３ ビーム調整要求手順
設定される場合、ビーム調整要求（ＢＡＲ）は、ＢＲＲＳ（ビームリファインメント参照信号）を送信するようにサービングセルに要求するために使用される。ＵＥは、スケジューリングされたサブフレームにおいてＢＲＲＳを測定し、サービングセルのものを決定する。
５Ｇ－ＲＲＣは、２つの連続するＢＡＲの間隔を制限するタイマprohibitBAR-Timerを設定することによりＢＡＲを制御する。
注： ＵＥは、任意のＵＥ実装特有の条件に基づいてＢＡＲをトリガすることができる。
ＢＡＲは、prohibitBAR-Timerが動作しておらず、任意のＵＥ実装特有の条件が満たされる場合にトリガされるものとする。
ＢＡＲがトリガされたとＢＡＲ手順が決定する場合：
－ ５Ｇ－ＭＡＣエンティティがこのＴＴＩに対して新しい送信のために割り当てられたＵＬリソースを有する場合
－ ６．１．３．８で定義されるようなＢＡＲ ＭＡＣ制御要素を生成及び送信するように多重化及びアセンブリ手順に指示する
－ prohibitBAR-Timerを開始または再開する
－ それ以外で、ＢＲＲＳ要求のための専用のＳＲがＵＥに設定される場合
－ ＲＡＣＨサブフレームの５Ｇ ＳＲ領域においてＢＲＲＳ要求のための専用ＳＲにシグナリングするように５Ｇの物理レイヤに指示する
－ prohibitBAR-Timerを開始または再開する
－ それ以外
－ スケジューリング要求がトリガされるものとする。

５．６ 間欠受信（ＤＲＸ）
５Ｇ－ＭＡＣエンティティは、５Ｇ－ＭＡＣエンティティのＣ－ＲＮＴＩに対するＵＥのｘＰＤＣＣＨ監視アクティビティを制御するＤＲＸ機能で５Ｇ－ＲＲＣによって設定され得る。５Ｇ－ＲＲＣ＿ＣＯＮＮＥＣＴＥＤの場合、ＤＲＸが設定されるとき、５Ｇ－ＭＡＣエンティティは、この項で指定したＤＲＸ動作を使用して、ｘＰＤＣＣＨを間欠的に監視することが許可される。そうでなければ、５Ｇ－ＭＡＣエンティティは、ｘＰＤＣＣＨを連続的に監視する。ＤＲＸ動作を使用する場合、５ＧＭＡＣエンティティはまた、本仕様書の他の項に見られる要件に従ってｘＰＤＣＣＨを監視するものとする。５ＧＲＲＣは、onDurationTimer、drx-InactivityTimer、drx-RetransmissionTimer（ブロードキャストプロセスを除くＤＬ ＨＡＲＱプロセスごとに１つ）、longDRX-Cycle、drxStartOffsetの値、およびオプションで、drxShortCycleTimerとshortDRX-Cycleのタイマを設定することによってＤＲＸの動作を制御する。また、（ブロードキャストプロセスを除く）ＤＬ ＨＡＲＱプロセス当たりのＨＡＲＱ ＲＴＴタイマが定義される。
ＤＲＸサイクルが設定される場合、アクティブ時間には以下の時間を含む：
－ onDurationTimer、drx-InactivityTimer、drx-RetransmissionTimerまたはmac-ContentionResolutionTimerが動作している；
－ スケジューリング要求がｘＰＵＣＣＨで送信され、（第５．４．４項に記載）保留している；
－ 保留しているＨＡＲＱ再送に対する上りリンクグラントが発生する可能性があり、対応するＨＡＲＱバッファにデータが存在；
－ ビーム変更指示ＭＡＣ－ＣＥは、継続時間（on-duration）の開始前に受信され、onDurationTimerが開始されるまで；
－ ＵＣＩ（上りリンク制御情報）が送信され、保留している；
－ ランダムアクセスプリアンブルがｘＰＲＡＣＨで送信され、保留している；
－ ＳＲプリアンブルがｘＰＲＡＣＨで送信され、保留している；あるいは
－ ５Ｇ－ＭＡＣエンティティのＣ－ＲＮＴＩに宛てた新しい送信を示すｘＰＤＣＣＨは、５Ｇ－ＭＡＣエンティティによって選択されていないプリアンブルに対するランダムアクセス応答を首尾よく受信した後で、受信されていない（第５．１．４項に記載）。
ＤＲＸが設定される場合、５Ｇ－ＭＡＣエンティティは、各サブフレームに対して以下のことを行うものとする：
－ ＨＡＲＱ ＲＴＴタイマがこのサブフレームにおいて期限切れとなり、対応するＨＡＲＱプロセスのデータが首尾よくデコードされなかった場合：
－ 対応するＨＡＲＱプロセスに対してdrx-RetransmissionTimerを開始する。
－ ＤＲＸコマンドＭＡＣ制御要素またはロングＤＲＸコマンドＭＡＣ制御要素が受信される場合：
－ onDurationTimerを停止する；
－ drx-InactivityTimerを停止する。
－ このサブフレームにおいてdrx-InactivityTimerが期限切れになる、あるいはＤＲＸコマンドＭＡＣ制御要素が受信される場合：
－ Short DRX cycleが設定されるとき：
－ drxShortCycleTimerを開始または再開する；
－ Short DRX Cycleを使用する。
－ それ以外：
－ Long DRX cycleを使用する。
－ このサブフレームにおいてdrxShortCycleTimerが期限切れになる場合：
－ Long DRX cycleを使用する。
－ ロングＤＲＸコマンドのＭＡＣ制御要素が受信される場合：
－ drxShortCycleTimerを停止する；
Long DRX cycleを使用する。
－ Short DRX Cycleが使用され、[(SFN*50)+サブフレーム番号]modulo(shortDRX-Cycle)=(drxStartOffset)modulo(shortDRX-Cycle)の場合；又は
－ Long DRX Cycleが使用され、[(SFN*50)+サブフレーム番号]modulo(longDRX-Cycle)=drxStartOffsetの場合：
－ onDurationTimerを開始する。
－ アクティブ時間中、サブフレームに対して：
－ ｘＰＤＣＣＨを監視する；
－ ｘＰＤＣＣＨがＤＬ送信を示す場合：
－ 対応するＨＡＲＱプロセスのためのＨＡＲＱ ＲＴＴタイマを開始する；
－ 対応するＨＡＲＱプロセスのためのdrx-RetransmissionTimerを停止する。
－ ｘＰＤＣＣＨがスケジューリングされたデータ送信（ＤＬまたはＵＬ）を示さないとき：
－ drx-InactivityTimerは開始されないものとする
－ スケジューリングされたデータ送信を示さないｘＰＤＣＣＨの例としては、以下のとおりである；
－ ｘＰＵＣＣＨまたはｘＰＵＳＣＨでのＵＣＩ送信をトリガするＵＬ ＤＣＩ、又は
－ ＤＬ／ＵＬデータ送信をスケジューリングするのに使用されない任意のＤＣＩフォーマット。
－ それ以外、ｘＰＤＣＣＨが新しい送信（ＤＬまたはＵＬ）を示す場合：
－ drx-ActivityTimerを開始又は再開する。
－ ＵＥは、オン持続時間（on-duration）の前にウェイクアップし、第５．５項で指定されるような通信に適したビームを見つけるためのビーム管理を行うことができる；
－ 現在サブフレームｎにおいて、この項で指定されるすべてのＤＲＸアクティブ時間条件を評価する場合、［サブフレームｎ－５］を含み、それまでに受信されたグラント／割り当て／ＤＲＸコマンドＭＡＣ制御要素／ロングＤＲＸコマンドＭＡＣ制御要素、及び送信されたスケジューリング要求を考慮してＭＡＣエンティティがアクティブ時間にないとき、ｘＰＵＣＣＨでのＣＱＩ／ＰＭＩ／ＲＩは報告されないものとする。
５Ｇ－ＭＡＣエンティティがｘＰＤＣＣＨを監視しているかどうかにかかわらず、５Ｇ－ＭＡＣエンティティはＨＡＲＱフィードバック（ＡＣＫ／ＮＡＣＫ情報）を受信及び送信し、期待される場合はＳＲＳを送信する。
注：同じアクティブ時間が、アクティブにされたすべてのサービングセルに適用される。
注：下りリンク空間多重化の場合、ＨＡＲＱ ＲＴＴタイマ実行中にＴＢが受信され、同じＴＢの以前の送信が現在のサブフレームの少なくともＮサブフレーム前に受信された（ＮはＨＡＲＱ ＲＴＴタイマに対応する）場合、５Ｇ－ＭＡＣエンティティはそれを処理し、ＨＡＲＱ ＲＴＴタイマを再起動すべきである。
各サービングセルに対して、ＨＡＲＱ ＲＴＴタイマは、ｌ＝ｎ＋４＋ｋ＋ｍ＋３のサブフレームに設定される。ｋ∈｛０，１，．．．，７｝およびｍ∈｛０，１，２，３｝は、［５Ｇ．２１３］の第８．５項に示されているように、下りリンク送信と関連するＨＡＲＱフィードバックの送信の間の間隔について、サブフレームｎにおけるＤＬ ＤＣＩ内である。

追加的な詳細は、TS 5G.211, “KT 5G Physical channels and modulation (Release 1)”、TS 5G.212,“KT 5G Physical Layer Multiplexing and channel coding (Release 1)”、TS 5G.213, “KT 5G Physical layer procedures (Release 1)”、及びTS 5G.321, “KT 5G MAC protocol specification (Release 1)”に見つけることができる。

３ＧＰＰ Ｒ３－１６０９４７及びＴＲ３８．８０１で論じられているように、ＮＲ無線ネットワークアーキテクチャによるサポートのために図１４及び図１５に示すシナリオを検討することができる。３ＧＰＰ Ｒ２－１６４３０６で論じられているように、スタンドアロンＮＲのためにセルレイアウトの次のシナリオを研究すべきものと捉えている。
・ マクロセルのみの展開
・ 異種展開（Heterogeneous deployment）
・ 小規模セルのみの展開

３ＧＰＰ ＲＡＮ２＃９４会議議事録で論じられたように、１つのＮＲ ｅＮＢは、１つ以上のＴＲＰに対応する。次のように、ネットワーク制御モビリティには、次のように可能性としてある２つのレベルがある。
・ ＲＲＣは「セル」レベルで駆動
・ ゼロ／最小ＲＲＣ関与（例えば、ＭＡＣ／ＰＨＹで）

３ＧＰＰ Ｒ２－１６２２１０で論じられたように、次の２レベルモビリティ処理の原理は、おそらく５Ｇにおいて維持される可能性がある。
Ａ） セルレベルのモビリティ
ａ． ＩＤＬＥでのセル選択／再選択、ＣＯＮＮでのハンドオーバ
ｂ． ＣＯＮＮ状態でＲＲＣによって処理
Ｂ） ビームレベル管理
ａ． Ｌ１は、ＵＥ及び最適なビーム方向に使用するＴＲＰの適切な選択を処理

一般に、５Ｇシステムは、ＵＥのモビリティを処理するため、通常のハンドオーバベースのＵＥのモビリティに加えて、「ビームベースのモビリティ」により依拠することが期待される。ＭＩＭＯ、フロントホール（fronthauling）、Ｃ－ＲＡＮ及びＮＦＶのような技術により、１つの「５Ｇノード」によって制御されるカバレッジエリアが拡大し、ビームレベルでの管理の可能性を高め、セルレベルでのモビリティの必要性を低くする。１つの５Ｇノードのカバレッジエリア内のすべてのモビリティは、理論的にはビームレベルでの管理に基づいて処理することができるが、別の５Ｇノードのカバレッジエリアへのモビリティに使用するためだけにハンドオーバを残す。

図１６～図１９は、５Ｇ ＮＲにおけるセルの例を示す。図１６は、３ＧＰＰ Ｒ２－１６３８７９の図１の一部の再現であり、単一のＴＲＰセルを有する例示的な展開を示す。図１７は、３ＧＰＰ Ｒ２－１６３８７９の図１の一部の再現であり、複数のＴＲＰセルを有する例示的な展開を示す。図１８は、３ＧＰＰ Ｒ２－１６２２１０の図３の再現であり、複数のＴＲＰを有する５Ｇノードを含む例示的な５Ｇセルを示す。図１９は、３ＧＰＰ Ｒ２－１６３４７１の図１の再現であり、ＬＴＥセルとＮＲセルとの比較を示す。

ＲＲＭ測定に基づくハンドオーバとは別に、５Ｇ ＵＥは、ビーム品質変動又はＵＥのセル内モビリティの影響を受ける５Ｇ接続を維持するためにサービングビームを適応させることができる。そうするために、５ＧノードＢ及びＵＥは、サービングビームを適切に追跡及び変更することができる（以下、ビーム追跡と呼ぶ）。

以下、次の専門用語の１つ以上を使用してよい。
・ ＢＳ：１つ以上のセルに関連付けられた１つ以上のＴＲＰを制御するのに使用される、ＮＲにおけるネットワーク中央ユニット又はネットワークノードである。ＢＳとＴＲＰとの間の通信はフロントホールを介する。ＢＳは、中央ユニット（ＣＵ）、ｅＮＢ、ｇＮＢ、又はノードＢと呼ぶことができる。
・ ＴＲＰ：送信及び受信ポイントはネットワークカバレッジを提供し、ＵＥと直接通信する。ＴＲＰは、分散ユニット（ＤＵ）と呼ぶことができる。
・ セル：セルは、１つ以上の関連付けられたＴＲＰで構成される。すなわち、セルのカバレッジは、関連付けられたすべてのＴＲＰのカバレッジで構成される。１つのセルは１つのＢＳによって制御される。セルは、ＴＲＰグループ（ＴＲＰＧ）と呼ぶことができる。
・ビーム掃引：送信及び／又は受信のためのすべての可能な方向をカバーするために、多くのビームが必要である。これらのすべてのビームを同時に発生させることは不可能であるため、ビーム掃引とは、１つの時間間隔において、これらのビームのサブセットを発生させ、他の時間間隔において、発生するビームを変更する、すなわち、時間領域でビームを変更することを意味する。このため、すべての可能な方向をいくつかの時間間隔の後にカバーすることができる。
・ビーム掃引数：送信及び/又は受信のために一度すべての可能な方向にビームを掃引するのに必要な数の時間間隔。言い換えれば、ビーム掃引を適用するシグナリングは、１つの期間内で「ビーム掃引数」の回数で送信される。例えば、シグナリングは、期間の異なる時間において（少なくとも部分的に）異なるビームで送信される。
・サービングビーム：ＵＥのためのサービングビームとは、例えば、送信及び／又は受信のために、ＵＥと通信するのに現在使用されているネットワーク、例えばＴＲＰによって生成されるビームである。
・候補ビーム：ＵＥのための候補ビームとは、サービングビームの候補である。サービングビームは、候補ビームであってもなくてもよい。
・適格ビーム：適格ビームとは、ビームについての信号を測定することに基づいて、しきい値よりも良好な無線品質を有するビームである。

以下、ネットワーク側について次の仮定が適用される。
・ ビームフォーミングを使用するＮＲはスタンドアロンとすることができる。すなわち、ＵＥはＮＲに直接的にキャンプオン又は接続することができる。
■ ビームフォーミングを使用するＮＲとビームフォーミングを使用しないＮＲは、例えば、異なるセルにおいて共存することができる。
・ ＴＲＰは、可能かつ有益である場合、データ及び制御シグナリングの送信及び受信の両方にビームフォーミングを適用することができる。
■ ＴＲＰによって同時に発生させるビームの数はＴＲＰの能力に依存し、例えば、異なるＴＲＰによって同時に発生させるビームの最大数は異なるものとしてよい。
■ ビーム掃引は、例えば、すべての方向に提供される制御シグナリングに必要である。
■ （ハイブリッドビームフォーミングの場合）ＴＲＰはすべてのビーム組合せをサポートしなくてもよく、例えば、いくつかのビームは、同時に発生させなくてよい。図２０は、ビーム発生についての組合せ制限についての例を示す。
・ 同じセル内のＴＲＰの下りリンク（downlink）タイミングは同期している。
・ ネットワーク側のＲＲＣレイヤはＢＳ内にある。
・ ＴＲＰは、異なるＵＥ能力又はＵＥリリースにより、ＵＥビームフォーミングありのＵＥと、ＵＥビームフォーミングなしのＵＥの両方をサポートすることができる。

以下、ＵＥ側について次の仮定が適用される。
・ ＵＥは、可能かつ有益である場合、受信及び／又は送信のためにビームフォーミングを実行してよい。
■ ＵＥによって同時に発生させるビームの数は、ＵＥの能力に依存し、例えば、複数のビームを生成することが可能である。
■ ＵＥによって発生させるビームは、ｅＮＢによって発生させるビームよりも広い。
■ 送信及び／又は受信のためのビーム掃引は、一般的には、ユーザデータには必要ではないが、他のシグナリング、例えば測定を実行するのに必要であることがある。
■ （ハイブリッドビームフォーミングの場合）ＵＥがすべてのビーム組合せをサポートしなくてもよく、例えば、いくつかのビームは、同時に発生させなくてよい。図２０は、ビーム発生についての組合せ制限についての例を示す。
・ すべてのＵＥが、ＵＥの能力又はＵＥビームフォーミングがＮＲの最初の（２、３の）リリースではサポートされていないことにより、ＵＥビームフォーミングをサポートしているわけではない。
・ １つのＵＥが、複数のＵＥビームを同時に発生させ、同じセルの１つ以上のＴＲＰからの複数のサービスビームによってサービスを受けることが可能である。
■ 同じ又は異なる（ＤＬ又はＵＬ）データは、ダイバーシティ又はスループット利得のために異なるビームを介して、同じ無線リソース上で送信することができる。
・ 少なくとも２つのＵＥ（ＲＲＣ）状態が存在：接続状態（又はアクティブ状態と呼ぶ）及び非接続状態（又はアイドル状態と呼ぶ）である。非アクティブ状態は、追加的な状態、あるいは接続状態又は非接続状態に属するものとしてよい。

３ＧＰＰ Ｒ２－１６２２５１で論じられたように、ｅＮＢ及びＵＥ側の両方でビームフォーミングを使用するためには、実際には、ｅＮＢにおけるビームフォーミングによるアンテナ利得は約１５～３０ｄＢｉと考えられ、ＵＥのアンテナ利得は約３～２０ｄＢｉと考えられる。３ＧＰＰ Ｒ２－１６２２５１の図３の再現である図２１は、ビームフォーミングによる利得補償を示す。

ＳＩＮＲの観点から、鋭いビームフォーミングは、隣接する干渉源、すなわち、下りリンクの場合の隣接ｅＮＢ、又は隣接ｅＮＢに接続された他のｅＮＢからの干渉電力を低減する。ＴＸビームフォーミングの場合、現在のビームがＲＸに対して同じ方向を向いている他のＴＸからの干渉のみが「有効」干渉となる。「有効」干渉とは、干渉電力が実効ノイズ電力よりも高いことを意味する。ＲＸビームフォーミングの場合、ビーム方向がＵＥの現在のＲＸビーム方向と同じである他のＴＸからの干渉のみが有効干渉となる。３ＧＰＰ Ｒ２－１６２２５１の図４の再現である図２２は、ビームフォーミングにより弱められた干渉を示す。

ＵＥが接続状態にあるとき、ＵＥは同じサービングセルの異なるビーム又はＴＲＰ間を移動することができる。さらに、ＵＥビームフォーミングが使用される場合、ＵＥビームは、例えばＵＥの回転により、時間とともに変化してもよい。

セル変更のない接続状態でのモビリティの例示的なケースは次のステップを有する。
・ 変化検出のためのシグナリング
ＵＥビーム、サービングＴＲＰのサービングビーム、及びサービングＴＲＰの変化は、ＵＥ及び／又はネットワークノードによって検出されてよい。変化を検出するために、ＴＲＰ又はＵＥによって周期的に送信されるシグナリングを使用することができる。ＴＲＰは、シグナリングの受信又は送信のために周期的にビーム掃引を実行する。ＵＥビームフォーミングが使用される場合、ＵＥは、シグナリングの受信又は送信のために周期的にビーム掃引を実行する。
・ ＵＥビームの変更
変化がＵＥによって検出された場合、ＵＥ自ら、次の受信（及び例えばＴＤＤの場合の送信）のために適切なＵＥビームを選択することができる。代替的には、ＵＥはネットワークにフィードバックを提供する必要があり、ネットワークノードはネットワークノードからＵＥにＵＥビームの変更の指示を提供することができる。
変化がネットワークによって検出された場合、ネットワークノードからＵＥへＵＥビームの変更の指示が必要とされてよい。ＵＥは、次の送信（及び、例えばＴＤＤの場合の受信）のためにネットワークノードによって指示されたＵＥビームを使用する。
・ サービングビーム及び／又はサービングＴＲＰの変更
ＵＥが変化検出のためのシグナリングを受信した後、ＵＥはネットワークノードにフィードバックを提供する必要があり、ネットワークはＵＥのために（ＤＬ）サービングビーム及び／又はサービングＴＲＰを変更するかどうかを決定することができる。一方、ＴＲＰが変化検出のためのシグナリングを受信した後、ネットワークノードはＵＥのためにサービングビーム及び／又はサービングＴＲＰを変更するかどうかを決定することができる。

図２３及び図２４は、セル変更のない接続状態でのモビリティについての例示的なフローチャートを示す。

ＮＲでは、既にＬＴＥに存在するＲＲＣ接続状態及びＲＲＣアイドル状態に加えて、新しい状態（例えば、非アクティブ状態）が考えられている。新しい状態は、ＲＲＣ接続状態のサブ状態、ＲＲＣアイドル状態のサブ状態、又は接続状態にもアイドル状態にも属さない独立した状態であってよい。新しい状態は、非アクティブ状態、接続非アクティブ状態、ＲＡＮ制御状態と呼んでよい。新しい状態の特性は、３ＧＰＰ Ｒ２－１６８８５６に以下のように説明されている。
（外８）

追加的に、新しい状態についての次の原理も３ＧＰＰ Ｒ２－１６８８５６で規定されている。
（外９）

ＵＥは、送信及び／又は受信に使用可能な少なくとも１つの（ネットワークノード）ビーム、例えばサービングビームを維持するためにビーム管理を実行することができる。ビーム管理は、３ＧＰＰ ＴＳ ５Ｇ．３２１で論じられた次の手順を含んでよいが、これに限定されない：
・ビームフィードバック手順
・ビーム変更手順
・ビーム調整要求手順

追加的に、ＵＥは、ＵＥのバッテリ消費を低減することができるように、ＤＲＸを実行して、ＤＬ制御チャネル（例えば、ＰＤＣＣＨ）監視を制御することができる。ＤＲＸアクティブ時間は、３ＧＰＰ ＴＳ ３６．３２１、ＴＳ ３６．３００、及びＴＳ ５Ｇ．３２１, “KT 5G MAC protocol specification (Release 1)”で規定されている。ＤＲＸが設定される場合、ＤＲＸアクティブ時間以外の時間は、ＤＲＸ非アクティブ時間と呼んでよい。ＫＴ ５Ｇ ＭＡＣ仕様ＴＳ ５Ｇ．３２１, “KT 5G MAC protocol specification (Release 1)”に基づき、ＤＲＸ非アクティブ時間中にビーム管理を継続してよい。ビーム管理は、ＵＥ電力を消費する連続的なＢＲＳ（ビーム参照信号）測定を必要とする。さらに、ＴＳ ５Ｇ．３２１, “KT 5G MAC protocol specification (Release 1)”によれば、ＵＥは、上りリンクが同期していない（すなわち、タイムアライメントタイマが動作していない）ときに、ＢＳＩ報告のためのランダムアクセス手順を開始する必要がある。したがって、静止している（stationary）ＵＥ、トラフィックが進行していないＵＥ、又はアクティブなサービスのないＵＥについて、ＤＲＸ非アクティブ時間中にビーム管理を継続することは、必ずしも有益ではない。

一般に、この問題を解決するために、ＵＥ（例えば、接続状態にある）は、ＤＲＸ非アクティブ時間中にビーム管理を停止することができる。例えば、ＵＥは、ＤＲＸ非アクティブ時間中にＢＲＳ測定及びＢＳＩ報告を実行しない。しかし、ＤＲＸ非アクティブ時間中の継続的なビーム管理は、データ転送の必要があるときにどのビームを使用するかをＵＥが知っているため、次のデータ転送の待ち時間が短縮されるという利点を有する。これは、敏感な待ち時間要件を有するサービスに役立つ可能性がある。妥協点として、ＤＲＸ非アクティブ時間中にビーム管理を続行するかどうかは、ネットワークノードによって設定又は制御することができる。ネットワークノード（例えばｇＮＢ）は、ＵＥの現在のアクティブなサービスのＱｏＳに基づいてそれを設定又は制御することができる。代替的には、ビーム管理を実行するかどうかは、少なくともＵＬ同期状態に基づく。例えば、ＵＥは、ＵＬが同期しなくなるときに、ビーム管理の実行を停止する（stop）ことができる。

同様の問題は、非アクティブ状態にあるＵＥに対しても発生することがある。上述の同じ理由に基づいて、非アクティブ状態中にビーム管理を続けることは必ずしも有益ではないことがある。この問題を解決するために、上記の方法は、ＵＥが非アクティブ状態にある場合に適用することができる。例えば、ＵＥは、非アクティブ状態（にあるＤＲＸ非アクティブ時間）中はビーム管理を停止することができる。代替的には、非アクティブ状態（にあるＤＲＸ非アクティブ時間）中にビーム管理を続行するかどうかは、ネットワークノードによって設定又は制御することができる。

上述のように、ビーム管理は、ＵＥのサービングビームを維持するのに使用することができる。ビーム管理に関して、ＵＥのサービングビームが決定された後、ＵＥは、現在のサービングビームが有効であるかどうかを決定するためにサービングビームについての測定を実行すべきである。測定結果はネットワークノードに報告されてよい。そして、ネットワークノードは、測定結果に基づいてサービングビームを変更することができる。場合によっては（例えば、ＤＲＸ非アクティブ時間中、非アクティブ状態中等）、ビーム管理は継続していないことがある。ビーム管理が実行されていない間、ＵＥは、現在のサービングビームが依然として有効かどうかについて全くわからない。現在のサービングビームが有効であるかどうかをＵＥが決定するための方法が以下で検討される。

この問題を解決するために、タイマを使用して、現在のサービングビームが有効であるかどうかを決定することができる。タイマは、サービングビーム有効性タイマと呼んでよい。ＵＥは、サービングビームのためのタイマを維持してよい。タイマの長さは、ネットワークノードによって設定してよい。長さはゼロ又は無限大としてよい。タイマの処理は、以下のアクションを含んでよいが、これに限定されない：
・ タイマは、サービングビームの決定又は更新に応答して開始又は再開することができる。サービングビームは、ネットワークノードからの情報に基づいて決定されてもよいし、ＵＥによって決定され、ネットワークノードに通知されてもよい。
・ 現在のサービングビームについてのビーム追跡及び／又はビーム測定の実行（、及び（現在のサービングビームが依然としてサービングビームでいることの基準を満たしている（例えば、品質がしきい値よりも良好、又はそれが最良のビームである））に応答して、タイマを再開することができる。ビーム追跡及び／又はビーム測定は、周期的に実行されてもよいし、ネットワークノードによってトリガされてもよい（例えば、ｘＰＤＣＣＨ命令）。
・ 現在のサービングビームの測定結果のネットワークノードへの報告（、及び現在のサービスビームが依然としてサービングビームでいることの基準を満たしている（例えば、品質がしきい値よりも良好、又はそれが最良のビームである））に応答して、タイマを再開することができる。報告は、定期的に実行されてもよいし、ネットワークノードによってトリガされてもよい。報告は、ＴＳ ５Ｇ．２１３, “KT 5G Physical layer procedures (Release 1)”及び５Ｇ．３２１, “KT 5G MAC protocol specification (Release 1)”で論じられたように、ＢＲＩ報告又はＢＳＩ報告としてよい。
・ タイマは、現在のサービングビームを介したＤＬ受信又はＵＬ送信に応答して再開することができる。
・ 例えば、現在のサービングビームがもはやサービングビームであることができない場合、サービングビームであるという基準が満たされていない場合、又はＵＥが非アクティブ状態に入った場合に、タイマを停止することができる。
・ タイマが終了又は停止するとき、ＵＥはサービングビームを無効と見なすことができる。
・ タイマが満了又は停止するとき、ＵＥはビーム管理を実行しなくてよい。

タイマが動作しているとき、ＵＥは現在のサービングビームを有効と見なすことができる。ＵＥは、データ転送の必要があるときに、データ送信及び／又は受信にそのサービングビームを使用することができる。タイマが動作していないとき、ＵＥは、関連付けられたサービングビームを無効と見なすことができ、（データ転送が必要なときに）データ送信及び／又は受信の前に少なくとも新しいサービングビームを見つける必要があることがある。

一般に、ＵＥは、ＵＥのサービングビームを介してＤＬ制御チャネル（例えば、ＰＤＣＣＨ、ｘＰＤＣＣＨ）上のＤＬ制御シグナリングを監視することができる。ＴＳ ５Ｇ．２１３, “KT 5G Physical layer procedures (Release 1)”によれば、ＵＥは、ｘＰＤＣＣＨ、ｘＰＤＳＣＨ、ＣＳＩ－ＲＳ、ｘＰＵＣＣＨ、ｘＰＵＳＣＨ、及びｘＳＲＳが、ＵＥのサービングビームを介して送信及び受信されると仮定することができる。ＵＥのサービングビームを無効と見なす場合、又はＵＥが有効なサービングビームを有さない場合、ＵＥがＤＬ制御チャネル（例えば、ｘＰＤＣＣＨ）をどのビームで監視しているかは不明である。

ＵＥがいかなる有効なサービングビームを有していない場合、ＵＥは、ＵＥの最良のビームを介してＤＬ制御チャネルを監視することができる。ＵＥは、ＢＲＳを測定することによって最良のビームを見つけてよい。最良のビームは、最も高いＲＳＲＰ（Reference Signal Receiving Power：参照信号受信電力）を有するビームであってよい。ネットワークノードは、有効なサービングビームが存在しない場合、ＵＥがそれを受信できることを確認するため、ＤＬ制御チャネルを送信するためのビーム掃引をする必要があることがある。

ＵＥは、ネットワークノードの異なるビームに対応する複数のタイミングでＤＬ制御チャネルを監視することができる。複数のタイミングは、ネットワークノードのすべてのビームをカバーすることができる。

ＵＥは、ＤＬ制御チャネルを監視して、新しいサービングビームを指示するためのシグナリング又はサービングビームとなるべき適切なビームを見つけるための手順（例えば、ＢＳＩ報告又はＢＲＩ報告）を開始するためのシグナリングを受信してよい。

ＵＥが送信に利用可能な上りリンクデータを有するとき、ＵＥは、例えば、３ＧＰＰ ＴＳ ３６．３２１で論じられたようなスケジューリング要求を介して、データを送信するためにいくつかの上りリンクリソースを要求する必要がある可能性があるＵＥのサービングセルがビームフォーミングを使用している場合、ＵＥは、データ送信及び／又は受信に使用することができる少なくとも１つのサービングビームを維持することができる。現在のサービングビームが有効であるとき（例えば、ＤＲＸアクティブ時間中又はサービングビーム有効性タイマが動作しているとき）、ＵＥはサービングビームを介して通常のスケジューリング要求手順を開始することができる。しかし、場合によっては、ＵＥが上りリンクデータ転送の必要性を有するときに、ＵＥがいかなる有効なサービングビームを有していないことがある。例えば、ＤＲＸ非アクティブ時間中にビーム管理が継続していない場合、又はサービングビーム有効性タイマが実行されていないときに、上りリンクデータは、ＤＲＸ非アクティブ時間中の送信に利用可能である。ビーム管理（例えば、ビームフィードバック）は、ＤＲＸ非アクティブ時間内の期間中に停止することができる。上述したように、ＵＥはサービングビームを無効とみなし、有効なサービングビームを使用することができないので、通常のスケジューリング要求手順を使用することができない。ＵＥが有効なサービングビームを有さないときの上りリンクデータ到着の処理は、以下で検討される。

この問題を解決するために、ＵＥが送信に利用可能な上りリンクデータを有するが、いかなる有効なサービングビームを有さない（例えば、ビーム管理が停止している期間に上りリンクデータが送信に利用可能である）とき、ＵＥはＵＬリソースを取得する要求を送信するために、少なくとも特定のビームを見つけることができる。ＵＥは、ＵＬ同期してよい。ＵＥは、ＢＲＳを測定することによって特定のビームを見つけてよい。特定のビームは、ＵＥによって測定されたビームのうちの最良のビームであってよい。最良のビームとは、最も高いＲＳＲＰを有するビームとしてよい。ビームは、同じセル、例えばＵＥのサービングセルに属してよい。要求は、特定のビームを介して送信してよい。要求は、スケジューリング要求としてよい。要求は、ＴＳ ５Ｇ．２１３, “KT 5G Physical layer procedures (Release 1)”及び５Ｇ．３２１, “KT 5G MAC protocol specification (Release 1)”で論じられたように、スケジューリング要求プリアンブル、ＢＳＩ報告、又はＢＲＩ報告としてよい。要求を送信した後、ＵＥは、特定のビームを介して要求の応答を監視することができる。ネットワークノードは、特定のビームを介して応答を送信してよい。応答は、ランダムアクセス応答としてよい。応答は、ビーム更新コマンドであってもよく、又はネットワークノードがＵＥのための新しいサービングビームを決定できるように、ＢＳＩ又はＢＲＩを報告するようにＵＥに通知してもよい。応答は、上りリンクグラントを含んでよい。

ＵＥは、ネットワークノードの異なるビームに対応する複数のタイミングで要求を送信するだけで、ネットワークノードが要求を受信できることを確認することができる。複数のタイミングは、ネットワークノードのすべてのビームをカバーする。ＵＥは、特定のビームを介して要求の応答を監視することができる。ネットワークノードは、特定のビームを介して応答を送信することができる。

ＵＥは、新しいサービングビーム決定をトリガする、要求を送信するための特定のビームを見つける代わりに、ＵＥは、ＴＳ ５Ｇ．２１３, “KT 5G Physical layer procedures (Release 1)”に規定されているランダムアクセス手順を開始することができ、その間にサービングビームを決定することができる。

ネットワークノードがＵＥに送信される下りリンクデータを有するとき、ネットワークノードは、ＵＥのサービングビームを介してＵＥにダウンリンク割り当てを送信することができる。ＵＥは、ダウンリンク割り当てに基づいてＤＬデータ受信を実行することができる。ダウンリンク割り当ては、ＵＥがＵＬ同期しているとき、ＤＲＸアクティブ時間中にＵＥに送信することができる。

ＵＥのサービングセルがビームフォーミングを使用している場合、ＵＥは、データ送信及び／又は受信に使用することができる少なくとも１つのサービングビームを維持することができる。場合によっては、ＵＥは、ネットワークノードがＵＥに送信されるべき下りリンクデータを有するときに、有効なサービングビームを有していないことがある。例えば、ＵＥがＵＬ同期を有さないとき、ＵＥがＤＲＸ非アクティブ時間にあるとき、又はＵＥが非アクティブ状態にあるとき、ビーム管理は継続されないことがある。そのような場合、ダウンリンク割り当ては、ＵＥのサービングビームを介してＵＥに送信することができない。ＵＥが有効なサービングビームを有さないとき、又はサービングビーム有効性タイマが動作していないときの下りリンクデータ到着の処理は以下で検討される。

この問題を解決するために、ＵＥが有効なサービングビームを有さず、ＵＥのＵＬが同期しておらず、ネットワークノードがＵＥに送信されるべき下りリンクデータを有する場合、ネットワークノードはＵＥにＵＬ送信のための要求を（例えば、ビーム掃引を使用して）送信する。この要求は、ＴＳ ５Ｇ．２１３, “KT 5G Physical layer procedures (Release 1)”で論じられているように、スケジューリング要求プリアンブルのための要求、ランダムアクセス手順を開始するための要求、ＢＳＩ報告のための要求、ＢＲＩ報告のための要求とすることができる。ＵＥは、特定のビームを介してその要求を監視することができる。特定のビームは、ＢＲＳを測定することによって決定してよい。特定のビームは、ＵＥによって測定されたビームうちの最良のビームとしてもよい。最良のビームは、最も高いＲＳＲＰを有するビームとしてよい。ビームは、同じセル（例えば、ＵＥのサービングセル）に属してよい。

ＵＥは、次のタイミングの少なくとも１つにおいて、特定のビームを決定、及び／又は特定のビームを介して要求を監視してよい：ＤＲＸアクティブ時間中又はこれに入りそうなとき（例えば、オン持続時間（on-duration））、ＵＥが物理下りリンク制御チャネル（例えば、ＰＤＣＣＨ）上の物理レイヤシグナリング（例えば、ダウンリンク割り当て）を監視する必要があるとき、又はＵＥが、ビームフィードバックが行われない期間（例えば、ＤＲＸ非アクティブ時間）を出るときである。ＰＤＣＣＨは、ＵＥのＣ－ＲＮＴＩ又はＰ－ＲＮＴＩ（すなわち、ページング受信のためのＲＮＴＩ）にあてられてよい（addressed）。Ｐ－ＲＮＴＩにあてられたＰＤＣＣＨの受信後、ＵＥはさらに、ＰＤＣＣＨに関連付けられたＰＤＳＣＨ上のページングメッセージを受信する。ここで、ページングメッセージは、下りリンクデータ到着を示す情報を含む。

要求を監視するための特定のビームを見つける代わりに、ＵＥは、ネットワークノードの異なるビームに対応する複数のタイミングで要求を受信するために監視して、ＵＥが要求を受信できることを確認してよい。複数のタイミングは、ネットワークノードのすべてのビームをカバーすることができる。

この要求に応答して、ＵＥは、要求が受信されるビームに対応するタイミングで、ＴＳ５Ｇ．２１３, “KT 5G Physical layer procedures (Release 1)”及び５Ｇ．３２１, “KT 5G MAC protocol specification (Release 1)”で論じられているように、スケジューリング要求プリアンブル、ＢＳＩ報告、又はＢＲＩ報告を送信してよい。ネットワークノードは、ビーム掃引を使用して応答を受信してよい。

３ＧＰＰ ＴＳ ３６．２１３によれば、ＵＥが現在のサービングビームがミスアライメントされていることを検出し、ビーム回復のためのＢＳＩを有する場合、ＵＥはビーム回復処理を実行することができる。ＵＬ同期化されたＵＥのためのビーム回復手順（例えば、時間アライメントタイマが動作している、又はＵＥが有効なＴＡ（タイミングアドバンス）を有する）は、次のステップを有してよい：
・ ＵＥは、ネットワークノード（例えば、ｇＮＢ）に通知するために、スケジューリング要求プリアンブルを送信する。
・ ネットワークノードは、ＢＳＩ報告手順を開始するためのＤＬ制御シグナリング（例えば、ｘＰＤＣＣＨ命令）を送信する。
・ ＵＥは、サービングビームを選択するためにネットワークノードに対してＢＳＩを報告する。

追加的に、ＴＳ５Ｇ．２１３, “KT 5G Physical layer procedures (Release 1)”によれば、ＵＥは、ｘＰＤＣＣＨ、ｘＰＤＳＣＨ、ＣＳＩ－ＲＳ、ｘＰＵＣＣＨ、ｘＰＵＳＣＨ、及びｘＳＲＳが、ＵＥのサービングビームを介して送信及び／又は受信されると仮定する。しかし、ビーム回復の場合、現在のサービングビームがミスアライメントされているので、サービングビームを介したＵＬ及び／又はＤＬ送信は正常に行われないことがある。この問題を解決するために、次の点を検討することができる。

ＵＥは、ネットワークノードがスケジューリング要求プリアンブルを受信できることを確認するために、ネットワークノードの異なるビームに対応する複数のタイミングでスケジューリング要求プリアンブルを送信する必要がある可能性がある。複数のタイミングは、ネットワークノードのすべてのビームをカバーすることができる。ネットワークノードは、スケジューリング要求プリアンブルが受信されるビームを介してＤＬ制御シグナリング（例えば、ｘＰＤＣＣＨ命令）を送信してよい。ＵＥは、ＤＬ制御シグナリングが受信されるビームを介してＢＳＩを報告してよい。

図２５は、ネットワークノードの観点からの例示的な一実施形態によるフローチャート２５００である。ステップ２５０５において、ネットワークノードは、ＵＥに設定（configuration）を送信する。ここで、設定は、ＵＥが特定期間中にビーム管理を実行するかどうかを示す。

図３及び図４に戻って参照すると、ネットワークノードの例示的な一実施形態では、デバイス３００は、メモリ３１０に記憶されたプログラムコード３１２を含む。ＣＰＵ３０８は、プログラムコード３１２を実行して、ネットワークノードが設定をＵＥに送信することを可能にする。ここで、設定は、ＵＥが特定期間中にビーム管理を実行するかどうかを示す。さらに、ＣＰＵ３０８は、プログラムコード３１２を実行して、上述のアクション及びステップ又は本明細書で説明した他のすべてを実行することができる。

図２６は、ＵＥの観点からの例示的な一実施形態によるフローチャート２６００である。ステップ２６０５において、ＵＥは、設定を受信する。ここで、設定は、ＵＥが特定期間中にビーム管理を実行するかどうかを示す。ステップ２６１０において、ＵＥは、その設定に基づいて、特定期間中にビーム管理を実行するかどうかを決定する。

図３及び図４に戻って参照すると、ＵＥの例示的な一実施形態では、デバイス３００は、メモリ３１０に記憶されたプログラムコード３１２を含む。ＣＰＵ３０８は、プログラムコード３１２を実行して、（ｉ）設定を受信することであって、その設定はＵＥが特定期間中にビーム管理を実行するかどうかを示す、受信することと、（ｉｉ）その設定に基づいて、特定期間中にビーム管理を実行するかどうかを決定すること、とを行う。さらに、ＣＰＵ３０８は、プログラムコード３１２を実行して、上述のアクション及びステップ又は本明細書で説明した他のすべてを実行することができる。

図２５及び図２６に示し、上述した実施形態との関連では、特定期間は、ＤＲＸ非アクティブ時間とすることができる。代替的には、特定期間は、ＵＥが非アクティブ状態にある持続期間とすることができる。

一実施形態では、ＵＥが特定期間中にビーム管理を実行することを設定が指示する場合に、ＵＥは、特定期間中にビーム管理を実行することができる。代替的には、ＵＥが特定期間中にビーム管理を実行しないことを設定が指示する場合、ＵＥは、特定期間中にビーム管理を実行しない。

一実施形態では、ＵＥが設定を受信しない場合、ＵＥは、その期間中にビーム管理を実行する。代替的には、ＵＥが設定を受信しない場合、ＵＥは、その期間中にビーム管理を実行しない。

図２７は、ＵＥの観点からの例示的な一実施形態によるフローチャート２７００である。ステップ２７０５において、ＵＥは、少なくともサービングビームを維持する。ステップ２７１０において、ＵＥは、サービングビームに関連付けられたタイマが満了又は停止したとき、サービングビームを無効と見なす。

一実施形態では、タイマは、ＵＥのサービングビームに関連付けられることができる。サービングビームは、タイマが満了したとき、無効と見なすことができる。タイマは、サービングビームが決定又は更新されたとき、ビーム追跡又はビーム管理がなされたとき、現在のサービングビームについてのビーム測定が行われたとき、及び／又は測定結果が報告されたときに、開始又は再開することができる。

測定結果は、現在のサービングビームの無線状態を指示することができる。代替的には、測定結果は、TS 5G.213, “KT 5G Physical layer procedures (Release 1)” and 5G.321, “KT 5G MAC protocol specification (Release 1)”において論じられたＢＲＩ報告及び／又はＢＳＩ報告とすることができる。

現在のサービングビームがサービングビームであるという基準（例えば、無線品質が十分でない）を満たさないことをＵＥが検出すると、タイマを停止することができる。ビーム管理を停止するとき、タイマを停止することができる。

タイマの長さは、ネットワークノードによって設定することができる。代替的には、タイマの長さをゼロにすることができる。

図３及び図４に戻って参照すると、ＵＥの例示的な一実施形態において、デバイス３００は、メモリ３１０に記憶されたプログラムコード３１２を含む。ＣＰＵ３０８は、プログラムコード３１２を実行して、（ｉ）少なくともサービングビームを維持することと、（ｉｉ）サービングビームに関連付けられたタイマが満了又は停止したとき、サービングビームを無効と見なすことと、を行う。さらに、ＣＰＵ３０８は、プログラムコード３１２を実行して、上述のアクション及びステップ又は本明細書で説明した他のすべてを実行することができる。

図２８は、ＵＥの観点からの例示的な一実施形態によるフローチャート２８００である。ステップ２８０５において、ＵＥは、上りリンクデータが送信に利用可能であるとき、有効なサービングビームが存在するかどうかを決定する。ステップ２８１０において、ＵＥは、ＵＥが有効なサービングビームを有さない場合に、特定のビームを選択し、その特定のビームを介して要求を送信する。

図３及び図４に戻って参照すると、ＵＥの例示的な一実施形態では、デバイス３００は、メモリ３１０に記憶されたプログラムコード３１２を含む。ＣＰＵ３０８は、プログラムコード３１２を実行して、（ｉ）上りリンクデータが送信に利用可能であるとき、有効なサービングビームが存在するかどうかを決定することと、（ｉｉ）ＵＥが有効なサービングビームを有さない場合に、特定のビームを選択し、その特定のビームを介して要求を送信することと、を行う。さらに、ＣＰＵ３０８は、プログラムコード３１２を実行して、上述のアクション及びステップ又は本明細書で説明した他のすべてを実行することができる。

図２９は、ＵＥの観点からの例示的な一実施形態によるフローチャート２９００である。ステップ２９０５において、ＵＥは、サービングセル内で少なくとも１つのサービングビームを維持する。ステップ２９１０において、ＵＥは、上りリンクデータが送信に利用可能であるとき、その少なくとも１つのサービングビームが有効であるかどうかを決定する。ステップ２９１５において、ＵＥは、その少なくとも１つのサービングビームが有効でない場合に、サービングセルの特定のビームを選択し、その特定のビームを介して上りリンクリソースの要求を送信する。

図３及び図４に戻って参照すると、ＵＥの例示的な一実施形態では、デバイス３００は、メモリ３１０に記憶されたプログラムコード３１２を含む。ＣＰＵ３０８は、プログラムコード３１２を実行して、（ｉ）サービングセル内で少なくとも１つのサービングビームを維持することと、（ｉｉ）上りリンクデータが送信に利用可能であるとき、その少なくとも１つのサービングビームが有効であるかどうかを決定することと、（ｉｉｉ）その少なくとも１つのサービングビームが有効でない場合に、サービングセルの特定のビームを選択し、その特定のビームを介して上りリンクリソースの要求を送信することと、を行う。さらに、ＣＰＵ３０８は、プログラムコード３１２を実行して、上述のアクション及びステップ又は本明細書で説明した他のすべてを実行することができる。

図２８及び図２９に示し、上述した実施形態との関連で、ＵＥは、ＢＲＳ測定に基づいて特定のビームを選択することができる。特定のビームは、ＵＥによって測定された最良のビームとすることができる。最良のビームは、最も高いＲＳＲＰを有するビームとすることができる。

要求は、上りリンクリソースを要求するのに使用され得る。この要求は、スケジューリング要求、ランダムアクセスプリアンブル、ＢＳＩ報告、又はＢＲＩ報告とすることができる。ＵＥは、少なくとも１つのサービングビームが有効である場合に、その少なくとも１つのサービングビームを介して要求を送信することができる。

図３０は、ＵＥの観点からの例示的な一実施形態によるフローチャート３０００である。ステップ３００５において、ＵＥは、ＵＥが下りリンク制御チャネルを監視する必要があるときに、有効なサービングビームが存在するかどうかを決定する。ステップ３０１０において、ＵＥは、ＵＥが有効なサービスビームを有さない場合に、特定のビームを選択し、その特定のビームを介して下りリンク制御チャネルを監視する。

図３及び図４を参照すると、ＵＥの例示的な一実施形態では、デバイス３００は、メモリ３１０に記憶されたプログラムコード３１２を含む。ＣＰＵ３０８は、プログラムコード３１２を実行して、（ｉ）ＵＥが下りリンク制御チャネルを監視する必要があるときに、有効なサービングビームが存在するかどうかを決定することと、（ｉｉ）ＵＥが有効なサービングビームを有さない場合に、特定のビームを選択し、その特定のビームを介して下りリンク制御チャネルを監視することと、を行う。さらに、ＣＰＵ３０８は、プログラムコード３１２を実行して、上述のアクション及びステップ又は本明細書で説明した他のすべてを実行することができる。

図３１は、ＵＥの観点からの例示的な一実施形態によるフローチャート３１００である。ステップ３１０５において、ＵＥは、サービングセル内で少なくとも１つのサービングビームを維持する。ステップ３１１０において、ＵＥは、ＵＥが下りリンク制御チャネルを監視する必要があるときに、その少なくとも１つのサービングビームが有効であるかどうかを決定する。ステップ３１１５において、ＵＥは、その少なくとも１つのサービングビームが有効でない場合に、サービングセルの特定のビームを選択し、その特定のビームを介してランダムアクセスプリアンブルを送信するための要求を受信するために下りリンク制御チャネルを監視する。

図３及び図４を再び参照すると、ＵＥの例示的な一実施形態では、デバイス３００は、メモリ３１０に記憶されたプログラムコード３１２を含む。ＣＰＵ３０８は、プログラムコード３１２を実行して、（ｉ）サービングセル内で少なくとも１つのサービングビームを維持することと、（ｉｉ）ＵＥが下りリンク制御チャネルを監視する必要があるときに、その少なくとも１つのサービングビームが有効であるかどうかを決定することと、（ｉｉｉ）その少なくとも１つのサービングビームが有効でない場合に、サービングセルの特定のビームを選択し、その特定のビームを介してランダムアクセスプリアンブルを送信するための要求を受信するために下りリンク制御チャネルを監視することと、を行う。さらに、ＣＰＵ３０８は、プログラムコード３１２を実行して、上述のアクション及びステップ又は本明細書で説明した他のすべてを実行することができる。

図２８及び図２９に示し、上述した実施形態との関連で、ＵＥは、ＢＲＳ測定に基づいて特定のビームを選択することができる。特定のビームは、ＵＥによって測定された最良のビームとすることができる。最良のビームは、最も高いＲＳＲＰを有するビームとすることができる。

ＵＥの上りリンクは同期していなくてよい。ＵＥが下りリンク制御チャネルを介して要求を受信した場合、ＵＥは応答を送信することができる。

応答は、ランダムアクセスプリアンブル、スケジューリング要求プリアンブル、ＢＳＩ報告、又はＢＲＩ報告とすることができる。

下りリンク制御チャネルは、物理下りリンク制御チャネル（例えば、ＰＤＣＣＨ）とすることができる。ＵＥは、ＤＲＸアクティブ時間（例えば、オン持続時間）中、下りリンク制御チャネルを監視することができる。

図２５～図３１に示し、上述した実施形態との関連では、ビーム管理は、サービングセル及び隣接セルのビームを測定することを含むことができる。ビーム管理は、現在のサービングビームが十分に良好であるかどうか、及び／又はサービングビームを変更する必要があるかどうかを追跡することを含むことができる。ビーム管理は、ビームフィードバック手順、ビーム変更手順、及び／又はビーム調整要求手順を含むことができる。ネットワークノードは、データ送信及び／又は受信のためにビームフォーミングを利用することができる。

一実施形態では、ＵＥは接続モードとすることができる。上りリンクタイミングは、ＵＥのために同期することができる。ＵＥのタイミングアライメントタイマ（timing alignment timer）が動作していることができる。

一実施形態では、ＵＥは、少なくとも１つのサービングビームについて測定を実行して、その少なくとも１つのサービングビームが有効であるかどうかを決定することができる。少なくとも１つのサービングビームは、ＤＲＸ非アクティブ時間中はビームフィードバック手順が継続されない場合、ＤＲＸ（間欠受信）非アクティブ時間中に無効とすることができる。少なくとも１つのサービングビームは、ＵＥの上りリンクが同期していないときにビームフィードバック手順が継続されない場合、無効とすることができる。一実施形態では、少なくとも１つのサービングビームが有効であるかどうかを決定するのにタイマが使用され得る。

一実施形態では、ＵＥは、その要求に応答してランダムアクセスプリアンブルを送信することができる。

本発明に基づいて、ビーム管理を特定の期間中継続する必要がないため、効率を改善することができる。追加的には、ビーム管理を継続しないことの副作用、例えば、ビームが無効になることは、適切に処理することができる。

以上、本開示の種々の態様を説明した。当然のことながら、本明細書の教示内容を多種多様な形態で具現化してよく、本明細書に開示されている如何なる特定の構造、機能、又は両者も代表的なものに過ぎない。本明細書の教示内容に基づいて、当業者には当然のことながら、本明細書に開示される態様は、他の如何なる態様からも独立に実装されてよく、これら態様のうちの２つ以上が種々組み合わされてよい。例えば、本明細書に記載された態様のうちの任意の数の態様を用いて、装置が実装されてよく、方法が実現されてよい。追加的に、本明細書に記載された態様のうちの１つ以上の追加又は代替で、他の構造、機能、又は構造と機能を用いて、このような装置が実装されるようになっていてもよいし、このような方法が実現されるようになっていてもよい。上記概念の一部の一例として、いくつかの態様においては、パルス繰り返し周波数に基づいて、同時チャネルが確立されてよい。いくつかの態様においては、パルス位置又はオフセットに基づいて、同時チャネルが確立されてよい。いくつかの態様においては、時間ホッピングシーケンスに基づいて、同時チャネルが確立されてよい。いくつかの態様において、パルス繰り返し周波数、パルス位置又はオフセット、及び時間ホッピングシーケンスに基づいて、同時チャネルが確立されてよい。

当業者であれば、多様な異なるテクノロジ及び技術のいずれかを使用して、情報及び信号を表わしてよいを理解するであろう。例えば、上記説明全体で言及されることがあるデータ、命令、コマンド、情報、信号、ビット、シンボル、及びチップは、電圧、電流、電磁波、磁場若しくは粒子、光場若しくは粒子、又はこれらの任意の組合せによって表わしてよい。

さらに、当業者には当然のことながら、本明細書に開示された態様に関連して説明した種々の例示的な論理ブロック、モジュール、プロセッサ、手段、回路、及びアルゴリズムステップは、電子的ハードウェア（例えば、ソースコーディング又はその他何らかの技術を用いて設計することがあるデジタル実装、アナログ実装、又はこれら２つの組合せ）、命令を含む種々の形態のプログラム若しくは設計コード（本明細書においては便宜上、「ソフトウェア」又は「ソフトウェアモジュール」と称されることがある）、又は両者の組合せとして実装されてよい。このハードウェア及びソフトウェアの互換性を明確に示すため、種々の例示的な構成要素、ブロック、モジュール、回路、及びステップを、概略的にそれぞれの機能の観点から上述した。そのような機能がハードウェアとして実装されるか、ソフトウェアとして実装されるかは、特定用途及びシステム全体に課される設計上の制約によって決まる。当業者であれば、特定各用途に対して、説明した機能を様々なやり方で実装してもよいが、そのような実装の決定は、本開示の範囲からの逸脱の原因として解釈されるべきではない。

追加的に、本明細書に開示される態様に関連して説明した種々の例示的な論理ブロック、モジュール、及び回路は、集積回路（「ＩＣ」）、アクセス端末、又はアクセスポイント内で実装される、あるいはこれらによって実行されてよい。ＩＣとしては、汎用プロセッサ、デジタルシグナルプロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、その他プログラマブル論理デバイス、ディスクリートゲート若しくはトランジスタロジック、ディスクリートハードウェアコンポーネント、電気部品、光学部品、機械部品、又は本明細書で説明した機能を実行するように設計されたこれらの任意の組合せを含み、ＩＣ内、ＩＣ外、又はその両方に存在するコード又は命令を実行してよい。汎用プロセッサは、マイクロプロセッサとしてよいが、代替として、プロセッサは、従来の任意のプロセッサ、コントローラ、マイクロコントローラ、又は状態機械としてよい。また、プロセッサは、ＤＳＰとマイクロプロセッサとの組合せ、複数のマイクロプロセッサ、ＤＳＰコアと協働する１つ以上のマイクロプロセッサ、又はその他任意のこのような構成である、コンピュータデバイスの組合せとして実装されてよい。

任意の開示プロセスにおけるステップの如何なる特定の順序又は階層は、実例的な手法の一例であることが了解される。設計の選好に基づいて、プロセスにおけるステップの特定の順序又は階層を、本開示の範囲内に留まりつつ、再構成してよいことが了解される。添付の方法の請求項は、種々のステップの要素を実例的な順序で示しており、提示の特定順序又は階層に限定されることを意図していない。

本明細書に開示される態様に関連して記載された方法又はアルゴリズムのステップを、ハードウェアにおいて直接具現化してよく、プロセッサにより実行されるソフトウェアモジュールにおいて具現化してよく、これら２つの組合せにおいて具現化してよい。（例えば、実行可能な命令及び関連するデータを含む）ソフトウェアモジュール及び他のデータは、ＲＡＭメモリ、フラッシュメモリ、ＲＯＭメモリ、ＥＰＲＯＭメモリ、ＥＥＰＲＯＭメモリ、レジスタ、ハードディスク、リムバーブルディスク、ＣＤ－ＲＯＭ等のデータメモリ、又は当技術分野において知られているその他任意の形態のコンピュータ可読記憶媒体に存在してよい。実例的な記憶媒体がコンピュータ／プロセッサ（本明細書においては便宜上、「プロセッサ」と称されることがある）等の機械に結合されてよい、このようなプロセッサは、記憶媒体からの情報（例えば、コード）の読み出し及び記憶媒体への情報の書き込みが可能である。実例的な記憶媒体は、プロセッサと一体化されてよい。プロセッサ及び記憶媒体は、ＡＳＩＣに存在してよい。ＡＳＩＣは、ユーザ機器に存在していてもよい。代替として、プロセッサ及び記憶媒体は、ディスクリートコンポーネントとしてユーザ機器に存在してよい。さらに、いくつかの態様においては、任意の適当なコンピュータプログラム製品が、本開示の態様のうちの１つ以上に関連するコードを含むコンピュータ可読媒体を含んでもよい。いくつかの態様において、コンピュータプログラム製品は、パッケージング材料を含んでよい。

以上、種々の態様に関連して本発明を説明したが、本発明は、さらに改良可能であることが了解される。本願は、概して本発明の原理に従うと共に、本発明が関係する技術分野における既知で慣習的な実施となるような本開示からの逸脱を含む本発明の任意の変形、使用、又は適応を網羅することを意図している。

Claims (18)

1. 間欠受信（ＤＲＸ）で設定されるＵＥ（ユーザ機器）の方法であって、
   上りリンクデータが送信に利用可能であるときに、ＤＲＸアクティブ時間及びＤＲＸ非アクティブ時間中に、少なくとも１つのサービングビームが有効であるかどうかを決定するための該少なくとも１つのサービングビームについての測定を実行することと、
   前記ＤＲＸアクティブ時間中に前記測定の結果をサービングセルに報告するためのビームフィードバック手順を実行することと、前記ＤＲＸ非アクティブ時間中に該ビームフィードバック手順を実行しないことと、 前記少なくとも１つのサービングビームがＤＲＸ非アクティブ時間中に有効でない場合、前記サービングセルの特定ビームを選択し、前記特定ビームを介して上りリンクリソースのための要求を送信することと、を含む方法。
2. 前記ＵＥは、ビーム参照信号を測定することによって前記特定ビームを選択する、請求項１に記載の方法。
3. 前記特定ビームが、最も高い参照信号受信電力（ＲＳＲＰ）を有するビームである、請求項２に記載の方法。
4. 前記ＤＲＸ非アクティブ時間が、前記ＤＲＸアクティブ時間以外の時間である、請求項１に記載の方法。
5. 前記ＵＥが、前記ＤＲＸアクティブ時間中にＰＤＣＣＨを監視する、請求項１に記載の方法。
6. 前記ＵＥが、前記サービングビームを介してＰＤＣＣＨ上の下りリンク制御シグナリングを監視する、請求項１に記載の方法。
7. 前記ＤＲＸアクティブ時間は、
   オン持続時間タイマ、ＤＲＸ非アクティブタイマ、ＤＲＸ再送タイマ、もしくは媒体アクセス制御（ＭＡＣ）競合解決タイマが動作している時間、
   スケジューリング要求がＰＵＣＣＨ（物理上りリンク制御チャネル）で送信され、保留している時間、または
   ＭＡＣエンティティのＣ－ＲＮＴＩ（Cell Radio Network Temporary Identifier）に宛てた新しい送信を示す物理下りリンク制御チャネル（ＰＤＣＣＨ）が、該ＭＡＣエンティティによって選択されていないプリアンブルに対するランダムアクセス応答を首尾よく受信した後に受信されていない時間、を含む、請求項１に記載の方法。
8. 前記ＵＥは、前記少なくとも１つのサービングビームが有効である場合に、前記少なくとも１つのサービングビームを介して前記要求を送信する、請求項１に記載の方法。
9. 前記少なくとも１つのサービングビームが有効であるかどうかを決定するためにタイマが使用される、請求項１に記載の方法。
10. 間欠受信（ＤＲＸ）で設定されるＵＥ（ユーザ機器）であって、
    制御回路と、
    前記制御回路に設けられたプロセッサと、
    前記制御回路に設けられ、前記プロセッサと動作可能に結合したメモリと、を含み、
    前記プロセッサは、前記メモリに記憶されたプログラムコードを実行して、
    上りリンクデータが送信に利用可能であるときに、ＤＲＸアクティブ時間及びＤＲＸ非アクティブ時間中に、少なくとも１つのサービングビームが有効であるかどうかを決定するための該少なくとも１つのサービングビームについての測定を実行することと、
    前記ＤＲＸアクティブ時間中に前記測定の結果をサービングセルに報告するためのビームフィードバック手順を実行することと、前記ＤＲＸ非アクティブ時間中に該ビームフィードバック手順を実行しないことと、
    前記少なくとも１つのサービングビームがＤＲＸ非アクティブ時間中に有効でない場合、前記サービングセルの特定ビームを選択し、前記特定ビームを介して上りリンクリソースのための要求を送信することと、行うように構成されている、ＵＥ。
11. 前記ＵＥは、ビーム参照信号を測定することによって前記特定ビームを選択する、請求項１０に記載のＵＥ。
12. 前記特定ビームが、最も高い参照信号受信電力（ＲＳＲＰ）を有するビームである、請求項１１に記載のＵＥ。
13. 前記ＤＲＸ非アクティブ時間が、前記ＤＲＸアクティブ時間以外の時間である、請求項１０に記載のＵＥ。
14. 前記ＵＥが、前記ＤＲＸアクティブ時間中にＰＤＣＣＨを監視する、請求項１０に記載のＵＥ。
15. 前記ＵＥが、前記サービングビームを介してＰＤＣＣＨ上の下りリンク制御シグナリングを監視する、請求項１０に記載のＵＥ。
16. 前記ＤＲＸアクティブ時間は、
    オン持続時間タイマ、ＤＲＸ非アクティブタイマ、ＤＲＸ再送タイマ、もしくは媒体アクセス制御（ＭＡＣ）競合解決タイマが動作している時間、
    スケジューリング要求がＰＵＣＣＨ（物理上りリンク制御チャネル）で送信され、保留している時間、または
    ＭＡＣエンティティのＣ－ＲＮＴＩ（Cell Radio Network Temporary Identifier）に宛てた新しい送信を示す物理下りリンク制御チャネル（ＰＤＣＣＨ）が、該ＭＡＣエンティティによって選択されていないプリアンブルに対するランダムアクセス応答を首尾よく受信した後に受信されていない時間、を含む、請求項１０に記載のＵＥ。
17. 前記ＵＥは、前記少なくとも１つのサービングビームが有効である場合に、前記少なくとも１つのサービングビームを介して前記要求を送信する、請求項１０に記載のＵＥ。
18. 前記少なくとも１つのサービングビームが有効であるかどうかを決定するためにタイマが使用される、請求項１０に記載のＵＥ。

Images