JP2023552433A - ＲｅｄＣａｐ ＵＥの識別のための方法及び装置 - Google Patents

Abstract

ユーザ機器（ＵＥ）は、基準に基づいて、ランダムアクセス（ＲＡ）手順中又は後に、それが機能削減（ＲｅｄＣａｐ）ＵＥであることをｇＮＢへ示すかを決定し、決定結果に従って、ＲＡ手順中又は後に、それがＲｅｄＣａｐ ＵＥであることを示しうる。ＲｅｄＣａｐ ＵＥは、減少させられた数量の受信ブランチを有するか、又は非ＲｅｄＣａｐ ＵＥよりも帯域幅を減少させる。ｇＮＢは、ＲＡ手順中に受信された第１のメッセージが、ＵＥがＲｅｄＣａｐ ＵＥであることを示すか決定しうる。第１のメッセージがＵＥをＲｅｄＣａｐ ＵＥとして示すときに、ｇＮＢは、カバレージ回復技法を使用してＲＡ手順中にＵＥへ第２のメッセージを送る。第１のメッセージがＵＥをＲｅｄＣａｐ ＵＥとして示さないときに、ｇＮＢは、ＲＡ手順が完了された後に、ＵＥがＲｅｄＣａｐ ＵＥであるか決定する。

Description

本特許出願は、２０２０年１２月７日に出願され、「Ｍｕｌｔｉｐａｔｈ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ ｏｆ ＲｅｄＣａｐ ＵＥｓ」と題された米国特許仮出願第６３／１２２，４１４号明細書、及び２０２１年９月３０日に出願され、「Ｍｕｌｔｉｐａｔｈ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ ｏｆ ＲｅｄＣａｐ ＵＥｓ」と題された米国特許仮出願第６３／２５０，７５１号明細書の優先権を主張するものであり、そっくりそのまま再現されるかのように参照により本明細書に組み込まれる。

本開示は、一般に、電気通信に関し、特定の実施形態では、機能削減（ＲｅｄＣａｐ）ユーザ機器（ＵＥ）の識別のための技法及び機構に関する。

第３世代パートナーシッププロジェクト（３ＧＰＰ）は、いくつかの重要な特徴を第５世代（５Ｇ）の新しい無線（ＮＲ）アクセス技術を用いて開発し、標準化している。ＲＡＮ＃８６（３ＧＰＰ ＲＰ－２０１６７７、２０２０年７月）において、Ｒｅｌ－１７は、機能削減（ＲｅｄＣａｐ）のＮＲデバイス（例えば、ユーザ機器（ＵＥ））のサポートを対象とする新しい研究項目（ＳＩ）を承認した。ＲｅｄＣａｐ ＵＥは、比較的ローエンドのサービスを供するＮＲエンティティであるが、典的なセルラーＵＥとは異なる要件を用い、例えば、ＲｅｄＣａｐ ＵＥは、極めて長いバッテリ寿命を有しうる。ＲｅｄＣａｐ ＵＥは、少なくとも３つの異なるシナリオ：産業用センサ、ビデオ監視、及びウェアラブルが思い描かれる。ＲｅｄＣａｐ ＵＥの通信を助ける機構を開発することが望ましい。

技術的な利点は、一般に、機能削減（ＲｅｄＣａｐ）ユーザ機器（ＵＥ）の識別のための技法及び機構を説明する本開示の実施形態によって達成される。

本開示の一態様によれば、方法は、ユーザ機器（ＵＥ）によって、基準に基づいて、ＵＥのランダムアクセス（ＲＡ）手順中に又はＲＡ手順後に、それが機能削減（ＲｅｄＣａｐ）ＵＥであることをｇＮＢへ示すかを決定するステップであって、ＲｅｄＣａｐ ＵＥは、非ＲｅｄＣａｐ ＵＥの受信ブランチの最小数よりも少ない受信ブランチの数量を有するか、又は非ＲｅｄＣａｐ ＵＥの最小帯域幅よりも少ない帯域幅を有する、ステップと、ＵＥによって、ｇＮＢへ、決定結果に従ってそれがＲｅｄＣａｐ ＵＥであることを示すステップとを含む方法が提供される。
任意選択で、前述の態様のいずれかでは、非ＲｅｄＣａｐ ＵＥは、レガシーＵＥである。
任意選択で、前述の態様のいずれかでは、ＲｅｄＣａｐ ＵＥは、１つ又は２つの受信ブランチを有する。

任意選択で、前述の態様のいずれかでは、非ＲｅｄＣａｐ ＵＥのための受信ブランチの最小数は、周波数範囲１（ＦＲ１）について４であり、周波数範囲２（ＦＲ２）について２である。

任意選択で、前述の態様のいずれかでは、示すステップは、ＵＥによって、ＲＡ手順中にＵＥをＲｅｄＣａｐ ＵＥとして示す第１のメッセージをＲＡ手順中に示すことを決定するときにｇＮＢへ送るステップを備え、第１のメッセージは、ＲＡ手順のメッセージ１（Ｍｓｇ１）、ＲＡ手順のメッセージ３（Ｍｓｇ３）、又はＲＡ手順のＲＡ手順のメッセージＡ（ＭｓｇＡ）を備える。

任意選択で、前述の態様のいずれかでは、方法は、ＵＥによって、ＲＡ手順前に、ｇＮＢによってブロードキャストされ、ＵＥによって受信される無線リソース制御（ＲＲＣ）構成に基づいて、ＲＡ手順前に、第１のメッセージを決定するステップをさらに含む。
任意選択で、前述の態様のいずれかでは、ＲＲＣ構成は、基準の情報を備える。

任意選択で、前述の態様のいずれかでは、ＲＡ手順前にｇＮＢによってブロードキャストされ、ＵＥによって受信される物理的ランダムアクセスチャネル（ＰＲＡＣＨ）構成に従って、第１のメッセージは、ＵＥによって送られ、ＰＲＡＣＨ構成は、ＲＡＣＨプリアンブル、ＲＡＣＨオケージョン、又はそれらの組合せを備え、これは、ＲｅｄＣａｐ ＵＥを示すことに関係付けられる。

任意選択で、前述の態様のいずれかでは、方法は、ＵＥによって、ＲＡ手順中にｇＮＢから、受信されたカバレージ回復技法に従ってメッセージ２（Ｍｓｇ２）又はメッセージ４（Ｍｓｇ４）を受信するステップをさらに含む。

任意選択で、前述の態様のいずれかでは、第１のメッセージは、Ｍｓｇ１であり、方法は、ＵＥによって、ｇＮＢへのＭｓｇ３の送信を繰り返すステップをさらに備える。
任意選択で、前述の態様のいずれかでは、Ｍｓｇ３の送信の反復の数がＲＡＣＨ構成に従う。

任意選択で、前述の態様のいずれかでは、Ｍｓｇ３の送信を繰り返すステップは、ＵＥの参照信号受信電力（ＲＳＲＰ）測定が閾値よりも少ないときに実行される。

任意選択で、前述の態様のいずれかでは、示すステップは、ＵＥによって、ＲＡ手順が完了された後にＵＥをＲｅｄＣａｐ ＵＥとして示すＵＥ機能の情報をＲＡ手順後に示すことを決定するときにｇＮＢへ送るステップを備える。

任意選択で、前述の態様のいずれかでは、基準は、ＵＥの受信ブランチの数、ＵＥによって測定される参照信号受信電力（ＲＳＲＰ）、ＵＥによって測定される参照信号受信品質（ＲＳＲＱ）、ＵＥによって測定される参照信号強度インジケータ（ＲＳＳＩ）、又はそれらの組合せに基づく。
任意選択で、前述の態様のいずれかでは、基準は、ＵＥの機能に基づく。

任意選択で、前述の態様のいずれかでは、決定するステップは、ＵＥが２つの受信ブランチを有するとき、ＵＥによって、ＲＡ手順後にＵＥをＲｅｄＣａｐ ＵＥとして示すことを決定するステップ、又はＵＥが１つの受信ブランチを有するとき、ＵＥによって、ＲＡ手順中にＵＥをＲｅｄＣａｐ ＵＥとして示すことを決定するステップを備える。

任意選択で、前述の態様のいずれかでは、決定するステップは、ＵＥが２つの受信ブランチを有し、周波数範囲１（ＦＲ１）又はＦＲ２内で動作可能であるとき、ＵＥによって、ＲＡ手順後にＵＥをＲｅｄＣａｐ ＵＥとして示すことを決定するステップ、ＵＥが１つの受信ブランチを有し、ＦＲ１又はＦＲ２内で動作可能であるとき、ＵＥによって、ＲＡ手順中にＵＥをＲｅｄＣａｐ ＵＥとして示すことを決定するステップ、又はＵＥが２つの受信ブランチを有し、ＦＲ１内で動作可能であるとき、ＵＥによって、ＲＡ手順中にＵＥをＲｅｄＣａｐ ＵＥとして示すことを決定するステップを備える。

任意選択で、前述の態様のいずれかでは、決定するステップは、ＵＥによって、ＲＳＲＰ測定をＲｅｄＣａｐ ＵＥのために構成された閾値と比較するステップ、ＲＳＲＰ測定が閾値よりも大きいとき、ＵＥによって、ＲＡ手順後にＵＥをＲｅｄＣａｐ ＵＥとして示すことを決定するステップ、又はＵＥのＲＳＲＰ測定が閾値以下であるとき、ＵＥによって、ＲＡ手順中にＵＥをＲｅｄＣａｐ ＵＥとして示すことを決定するステップを備える。

任意選択で、前述の態様のいずれかでは、決定するステップは、ＵＥによって、ＲＳＲＰ測定をＲｅｄＣａｐ ＵＥのために構成された閾値と比較するステップ、ＵＥが２つの受信ブランチを有し、ＲＳＲＰ測定が閾値よりも大きいとき、ＵＥによって、ＲＡ手順後にＵＥをＲｅｄＣａｐ ＵＥとして示すことを決定するステップ、ＵＥが２つの受信ブランチを有し、ＵＥのＲＳＲＰ測定が閾値以下であるとき、ＵＥによって、ＲＡ手順中にＵＥをＲｅｄＣａｐ ＵＥとして示すことを決定するステップ、又はＵＥが１つの受信ブランチを有するとき、ＵＥによって、ＲＡ手順中にＵＥをＲｅｄＣａｐ ＵＥとして示すことを決定するステップを備える。

任意選択で、前述の態様のいずれかでは、決定するステップは、ＵＥによって、ＲＳＲＰ測定をＲｅｄＣａｐ ＵＥのために構成された閾値と比較するステップ、ＵＥが１つの受信ブランチを有し、ＲＳＲＰ測定が閾値よりも大きいとき、ＵＥによって、ＲＡ手順後にＵＥをＲｅｄＣａｐ ＵＥとして示すことを決定するステップ、ＵＥが１つの受信ブランチを有し、ＲＳＲＰ測定が閾値以下であるとき、ＵＥによって、ＲＡ手順中にＵＥをＲｅｄＣａｐ ＵＥとして示すことを決定するステップ、又はＵＥが２つの受信ブランチを有するとき、ＵＥによって、ＲＡ手順後にＵＥをＲｅｄＣａｐ ＵＥとして示すことを決定するステップを備える。

本開示の別の態様によれば、ｇＮＢによって、ランダムアクセス（ＲＡ）手順中に、ユーザ機器（ＵＥ）から第１のメッセージを受信するステップと、ｇＮＢによって、第１のメッセージが、ＵＥが機能削減（ＲｅｄＣａｐ）ＵＥであることを示すかを決定するステップであって、ＲｅｄＣａｐ ＵＥは、非ＲｅｄＣａｐ ＵＥの受信ブランチの最小数よりも少ない受信ブランチの数量を有するか、又は非ＲｅｄＣａｐ ＵＥの最小帯域幅よりも少ない帯域幅を有する、ステップと、第１のメッセージがＵＥをＲｅｄＣａｐ ＵＥとして示すときに、ｇＮＢによって、カバレージ回復技法に従ってＲＡ手順中にＵＥへ第２のメッセージを送るステップと、第１のメッセージがＵＥをＲｅｄＣａｐ ＵＥとして示さないときに、ｇＮＢによって、ＲＡ手順が完了された後にＵＥがＲｅｄＣａｐ ＵＥであるか決定するステップとを含む方法が提供される。
任意選択で、前述の態様のいずれかでは、非ＲｅｄＣａｐ ＵＥは、レガシーＵＥである。
任意選択で、前述の態様のいずれかでは、ＲｅｄＣａｐ ＵＥは、１つ又は２つの受信ブランチを有する。

任意選択で、前述の態様のいずれかでは、非ＲｅｄＣａｐ ＵＥの受信ブランチの最小数は、周波数範囲１（ＦＲ１）について４であり、周波数範囲２（ＦＲ２）について２である。

任意選択で、前述の態様のいずれかでは、第１のメッセージは、ＲＡ手順のメッセージ１（Ｍｓｇ１）、ＲＡ手順のメッセージ３（Ｍｓｇ３）、又はＲＡ手順のメッセージＡ（ＭｓｇＡ）を備える。

任意選択で、前述の態様のいずれかでは、第１のメッセージは、ｇＮＢによってブロードキャストされる物理的ランダムアクセスチャネル（ＰＲＡＣＨ）構成に基づき、ＰＲＡＣＨ構成は、ＲＡＣＨプリアンブル、ＲＡＣＨオケージョン、又はそれらの組合せを備え、これは、ＲｅｄＣａｐ ＵＥを示すことに関係付けられる。
任意選択で、前述の態様のいずれかでは、第２のメッセージは、ＲＡ手順のメッセージ２（Ｍｓｇ２）、又はＲＡ手順のメッセージ４（Ｍｓｇ４）である。

任意選択で、前述の態様のいずれかでは、方法は、ｇＮＢによって、ＵＥから、ＲＡ手順が完了された後にＵＥをＲｅｄＣａｐ ＵＥとして示すＵＥ機能の情報を受信するステップをさらに備える。

任意選択で、前述の態様のいずれかでは、方法は、ｇＮＢによって、ＵＥへ基準の情報をブロードキャストするステップであって、基準に基づいて、ＲＡ手順中に又はＲＡ手順後に、ＵＥをＲｅｄＣａｐ ＵＥとしてｇＮＢへ示すかＵＥが決定することを可能にする、ステップをさらに備える。

任意選択で、前述の態様のいずれかでは、基準は、ＵＥの受信ブランチの数、ＵＥの参照信号受信電力（ＲＳＲＰ）測定、ＵＥの参照信号受信品質（ＲＳＲＱ）測定、ＵＥの参照信号強度インジケータ（ＲＳＳＩ）、又はそれらの組合せに基づく。
任意選択で、前述の態様のいずれかでは、基準は、ＵＥの機能に基づく。

任意選択で、前述の態様のいずれかでは、基準は、ＵＥが２つの受信ブランチを有するとき、ＲＡ手順後にＲｅｄＣａｐ ＵＥを示すステップ、又はＵＥが１つの受信ブランチを有するとき、ＲＡ手順中にＲｅｄＣａｐ ＵＥを示すステップを備える。

任意選択で、前述の態様のいずれかでは、基準は、ＵＥが２つの受信ブランチを有し、周波数範囲１（ＦＲ１）又はＦＲ２内で動作可能であるとき、ＲＡ手順後にＲｅｄＣａｐ ＵＥを示すステップ、ＵＥが１つの受信ブランチを有し、ＦＲ１又はＦＲ２内で動作可能であるとき、ＲＡ手順中にＲｅｄＣａｐ ＵＥを示すステップ、又はＵＥが２つの受信ブランチを有し、ＦＲ１内で動作可能であるとき、ＲＡ手順中にＲｅｄＣａｐ ＵＥを示すステップを備える。

任意選択で、前述の態様のいずれかでは、基準は、ＵＥによって測定されるＲＳＲＰが閾値よりも大きいとき、ＲＡ手順後にＲｅｄＣａｐ ＵＥを示すステップ、又はＵＥによって測定されるＲＳＲＰが閾値以下であるとき、ＲＡ手順中にＲｅｄＣａｐ ＵＥを示すステップを備える。

任意選択で、前述の態様のいずれかでは、基準は、ＵＥが２つの受信ブランチを有し、ＵＥによって測定されるＲＳＲＰが閾値よりも大きいとき、ＲＡ手順後にＲｅｄＣａｐ ＵＥを示すステップ、ＵＥが２つの受信ブランチを有し、ＵＥによって測定されるＲＳＲＰが閾値以下であるとき、ＲＡ手順中にＲｅｄＣａｐ ＵＥを示すステップ、又はＵＥが１つの受信ブランチを有するとき、ＲＡ手順中にＲｅｄＣａｐ ＵＥを示すステップを備える。

任意選択で、前述の態様のいずれかでは、基準は、ＵＥが１つの受信ブランチを有し、ＵＥによって測定されるＲＳＲＰが閾値よりも大きいとき、ＲＡ手順後にＲｅｄＣａｐ ＵＥを示すステップ、ＵＥが１つの受信ブランチを有し、ＵＥによって測定されるＲＳＲＰが、閾値以下であるとき、ＲＡ手順中にＲｅｄＣａｐ ＵＥを示すステップ、又はＵＥが２つの受信ブランチを有するとき、ＲＡ手順後にＲｅｄＣａｐ ＵＥを示すステップを備える。

任意選択で、前述の態様のいずれかでは、方法は、ｇＮＢによって、ｇＮＢがＲｅｄＣａｐ ＵＥをサポートすることを示す情報をブロードキャストするステップをさらに備える。

本開示の別の態様によれば、命令を備える非一時的なメモリストレージと、メモリストレージと通信する１つ又は複数のプロセッサとを含み、ここで、命令は、１つ又は複数のプロセッサによって実行されるときに、装置に、前述の態様のいずれかにおける方法を実行させる装置が提供される。

本開示の別の態様によれば、コンピュータ命令を記憶する非一時的なコンピュータ可読媒体であって、装置の１つ又は複数のプロセッサによって実行されるときに、装置に、前述の態様のいずれかにおける方法を実行させる、非一時的なコンピュータ可読媒体である。

本開示の別の態様によれば、ユーザ機器（ＵＥ）及びｇＮＢを含むシステムであって、ＵＥは、基準に基づいて、ＵＥのランダムアクセス（ＲＡ）手順中に又はＲＡ手順後に、ＵＥが機能削減（ＲｅｄＣａｐ）ＵＥであることをｇＮＢへ示すかを決定することであって、ＲｅｄＣａｐ ＵＥは、非ＲｅｄＣａｐ ＵＥの受信ブランチの最小数よりも少ない受信ブランチの数量を有するか、又は非ＲｅｄＣａｐ ＵＥの最小帯域幅よりも少ない帯域幅を有する、ことと、決定結果に従って、ｇＮＢへ、ＵＥがＲｅｄＣａｐ ＵＥであることを示すこととを実行するように構成され、ｇＮＢは、ランダムアクセス（ＲＡ）手順中にＵＥから第１のメッセージを受信することと、第１のメッセージが、ＵＥがＲｅｄＣａｐ ＵＥであることを示すかを決定することと、第１のメッセージがＵＥをＲｅｄＣａｐ ＵＥとして示すときに、カバレージ回復技法に従ってＲＡ手順中にＵＥへ第２のメッセージを送ることと、第１のメッセージがＵＥをＲｅｄＣａｐ ＵＥとして示さないときに、ＲＡ手順が完了された後に、ＵＥがＲｅｄＣａｐ ＵＥであるか決定することとを実行するように構成される、ユーザ機器（ＵＥ）及びｇＮＢを含むシステムが提供される。

本開示の態様は、ＲｅｄＣａｐ ＵＥが、ＲＡ手順中（早期識別）又はＲＡ手順後（通常識別）にそれがＲｅｄＣａｐであることを識別することを可能にし、ＲｅｄＣａｐ ＵＥ識別の混合を可能にする（例えば、いくつかのＲｅｄＣａｐ ＵＥは早期識別を実行しうるし、いくつかのＲｅｄＣａｐ ＵＥは、通常識別を実行しうる）。これは、ネットワークが、ネットワークと通信しているＲｅｄＣａｐ ＵＥのリンクバジェット損失を補償するための措置をとることを可能にし、通信信頼性及びユーザエクスペリエンスを改善する。

本開示及びその利点をより完全に理解するために、ここで、下記の添付図面と併せて以下の説明の参照がなされる。
一実施形態のワイヤレス通信ネットワークの図である。 ３ＧＰＰ ＴＳ３８．３００による４ステップのランダムアクセス手順を示す図である。 ３ＧＰＰ ＴＳ３８．３００による２ステップのランダムアクセス手順を示す図である。 例示的なカバレージエリア及びＵＥのアンテナ／ブランチの数を強調する、一実施形態の通信ネットワークを示す図である。 機能削減（ＲｅｄＣａｐ）のインジケーションのためのＵＥによる実施形態の動作の図である。 ＲｅｄＣａｐのインジケーションのための基準Ｃ１に基づく経路選択のための実施形態の動作の図である。 ＲｅｄＣａｐ ＵＥの検出のためのｇＮＢの実施形態の動作の図である。 ＲｅｄＣａｐのインジケーションのための基準Ｃ４に基づく経路選択のための実施形態の動作の図である。 は、一実施形態のＲｅｄＣａｐ ＵＥインジケーションの方法の図である。 別の実施形態のＲｅｄＣａｐ ＵＥを検出する方法の図である。 一実施形態の処理システムのブロック図である。 送受信機のブロック図である。 電子デバイスのブロック図である。

異なる図における対応する番号及び記号は、一般に、別段示されない限り、対応する部分を指す。図面は、実施形態の関連する態様を明確に示すように描かれており、必ずしも原寸に比例して描かれていない。

以下、本開示の実施形態の作製及び使用が、詳細に議論される。しかし、本明細書に開示される概念は、多種多様な特定の文脈において具現化されることができ、及び本明細書で議論される特定の実施形態は、例示にすぎず、特許請求の範囲を限定するように働かないことを理解されたい。さらに、添付の特許請求の範囲によって定められる本開示の趣旨及び範囲から逸脱することなく、様々な変更、置換、及び改変が本明細書で行われることができることを理解されたい。

機能削減（ＲｅｄＣａｐ）ユーザ機器（ＵＥ）は、複雑さを減少させる特徴／技法の使用により性能劣化に悩まされる。ＲｅｄＣａｐ ＵＥは、非ＲｅｄＣａｐ ＵＥの受信ブランチの最小数よりも少ない受信ブランチの数量を有するＵＥ、非ＲｅｄＣａｐ ＵＥの最小帯域幅よりも小さい帯域幅を有するＵＥ、及び／又は機能が低減された他のＵＥでありうる。劣化を補償するために、反復、より低い変調及びコーディング方式（ＭＣＳ）のテーブル、及び／又はトランスポートブロック（ＴＢ）のスケーリングなどのカバレージ回復技法が使用されうる。ＵＥがｇＮＢにアクセスする前、ｇＮＢはＲｅｄＣａｐ ＵＥの存在に気付かないので、これらのカバレージ回復技法を適用することは、ＵＥがＲｅｄＣａｐ ＵＥであることを識別する又は示すことに依存しうる。ｇＮＢが、ＵＥがＲｅｄＣａｐ ＵＥであるかを早期に知ることができる場合、ｇＮＢは、これらの技法のうちの１つ又は複数を使用して、そのＲｅｄＣａｐ ＵＥの性能を改善することができる。

本開示の実施形態は、ＲｅｄＣａｐ ＵＥが、（早期識別と呼ばれる）ランダムアクセス（ＲＡ）手順中に、又は（通常識別と呼ばれる）ＲＡ手順後にそれら自体を識別することを可能にする機構を提供する。従って、実施形態は、ＲｅｄＣａｐ ＵＥ識別の混合を可能にし、例えば、いくつかのＲｅｄＣａｐ ＵＥは、早期識別を実行しうるし、いくつかのＲｅｄＣａｐ ＵＥは、通常識別を実行しうる。これは、ＲｅｄＣａｐ ＵＥがそれ自体を識別するときを決定するための柔軟性を提供し、ネットワークがカバレージ回復技法を利用してＲｅｄＣａｐ ＵＥの通信性能を改善することを可能にする。

一実施形態によれば、ＵＥは、ＵＥのＲＡ手順中にそれがＲｅｄＣａｐ ＵＥであることをｇＮＢへ示すか、又はＲＡ手順後にＲｅｄＣａｐ ＵＥであることをｇＮＢに示すかを基準に基づいて決定し、次いで、決定結果に従ってそれがＲｅｄＣａｐ ＵＥであることをｇＮＢへ示してよい。例えば、ＵＥは、ＲＡ手順のメッセージ１、メッセージ３、若しくはメッセージＡにおいて、又はＲＡ手順後のメッセージ５において、それがＲｅｄＣａｐ ＵＥであることを示しうる。

別の実施形態によれば、ｇＮＢは、ＲＡ手順中にＵＥから第１のメッセージを受信し、ＵＥがＲｅｄＣａｐ ＵＥであることを第１のメッセージが示すかを決定しうる。第１のメッセージがＵＥをＲｅｄＣａｐ ＵＥとして示すとき、ｇＮＢは、カバレージ回復技法に従って、ＲＡ手順中に第２のメッセージをＵＥへ送りうる。第１のメッセージが、ＵＥをＲｅｄＣａｐ ＵＥとして示さないとき、ｇＮＢは、ＲＡ手順が完了された後に、ＵＥがＲｅｄＣａｐ ＵＥであるかを決定しうる。

図１は、データを通信するためのネットワーク１００を示す。ネットワーク１００は、カバレージエリア１０１を有する基地局１１０と、複数のモバイルデバイス１２０と、バックホールネットワーク１３０とを備える。図示されるように、基地局１１０は、モバイルデバイス１２０とのアップリンク（破線）接続、及び／又はダウンリンク（点線）接続を確立し、これは、モバイルデバイス１２０から基地局１１０へ、及びその逆でデータ及び制御情報を運ぶように働く。アップリンク接続／ダウンリンク接続上で運ばれるデータは、モバイルデバイス１２０間で通信されるデータ、及びバックホールネットワーク１３０を介してリモートエンド（図示せず）へ／から通信されるデータを含みうる。本明細書で使用されるとき、用語「基地局」は、拡張基地局（ｅＮＢ）、マクロセル、フェムトセル、Ｗｉ－Ｆｉアクセスポイント（ＡＰ）、又は他のワイヤレスに対応されたデバイスなど、ネットワークへのワイヤレスアクセスを提供するように構成された任意の構成要素（又は構成要素の集合）を指す。基地局は、１つ又は複数のワイヤレス通信プロトコル、例えば、ロングタームエボリューション（ＬＴＥ）、ＬＴＥアドバンスト（ＬＴＥ－Ａ）、高速パケットアクセス（ＨＳＰＡ）、Ｗｉ－Ｆｉ８０２．１１ａ／ｂ／ｇ／ｎ／ａｃなどに従ってワイヤレスアクセスを提供しうる。本明細書で使用されるとき、用語「モバイルデバイス」は、ユーザ機器（ＵＥ）、移動局（ＳＴＡ）、及び他のワイヤレスに対応されたデバイスなど、基地局とのワイヤレス接続を確立することができる任意の構成要素（又は構成要素の集合）を指す。いくつかの実施形態では、ネットワーク１００は、リレー、低電力ノード等など、様々な他のワイヤレスデバイスを備えうる。

図２は、３ＧＰＰ ＴＳ３８．３００の図９．６．２－１による４ステップのランダムアクセス手順を示す図である。Ｒｅｌ－１５からの競合ベースランダムアクセス（ＣＢＲＡ）手順全体は、図２に示されるように、４ステップ手順であり、ＰＲＡＣＨオケージョンにおけるランダムアクセスプリアンブル（メッセージ１（Ｍｓｇ１））を送信することと、物理ダウンリンク制御チャネル（ＰＤＣＣＨ）を通じてスケジュール設定された物理ダウンリンク共有チャネル（ＰＤＳＣＨ）においてランダムアクセス応答（ＲＡＲ）メッセージ（メッセージ２（Ｍｓｇ２））を受信することと、物理的なアップリンク制御チャネル（ＰＵＳＣＨ）においてメッセージ３（Ｍｓｇ３）を送信することと、競合解決のためにＰＤＣＣＨにおけるＤＣＩによってスケジュール設定されたＰＤＳＣＨにおいてメッセージ４（Ｍｓｇ４）を受信することとからなる。ＵＥがネットワークにアクセスすることを試みることができる前に、それは、ダウンリンクに（時間及び周波数において）同期し、物理的なブロードキャストチャネル（ＰＢＣＨ）及びＰＤＣＣＨ／ＰＤＳＣＨを介してマスタ情報ブロック（ＭＩＢ）及びシステム情報ブロック（ＳＩＢ）を受信する必要がありうる。ＳＩＢ（主にＳＩＢ１）を受信した後、ＵＥは、物理的ランダムアクセスチャネル（ＰＲＡＣＨ）構成及び送信パラメータの知識を有する。ランダムアクセス手順又はプロセスは、ＲＡＣＨ又はＲＡ手順／処理と呼ばれうる。

レイテンシを減少させるために、ランダムアクセス（ＲＡ）手順のための２ステップ手順がＲｅｌ－１６において標準化され、図３に示されている。ＴＳ３８．３００からの２ステップ手順の説明は、以下に転載される。

「２ステップＲＡタイプのＭＳＧＡは、ＰＲＡＣＨ上のプリアンブルと、ＰＵＳＣＨ上のペイロードとを含む。ＭＳＧＡ送信後、ＵＥは、構成されたウィンドウ内でネットワークからの応答を監視する。ＣＦＲＡについては、個別プリアンブル及びＰＵＳＣＨリソースは、ＭＳＧＡ送信のために構成され、ネットワーク応答を受信すると、ＵＥは、図９．２．６－１（ｄ）に示されるように、ランダムアクセス手順を終わらせる。ＣＢＲＡについては、ネットワーク応答の受信時に競合解決が成功である場合、ＵＥは、図９．２．６－１（ｂ）に示されるように、ランダムアクセス手順を終わらせ、一方、フォールバックインジケーションがＭＳＧＢにおいて受信された場合、ＵＥは、フォールバックインジケーションにおいてスケジュール設定されたＵＬ許可を使用してＭＳＧ３送信を実行し、図９．２．６－２に示すように、競合解決を監視する。ＭＳＧ３（再）送信後に競合解決が成功しなかった場合、ＵＥはＭＳＧＡ送信に戻る。」

即ち、２ステップＲＡ手順において、ＵＥは、メッセージＡ（ＭｓｇＡ）をｇＮＢへ送信し、そこで、ＭｓｇＡは、ＰＲＡＣＨ上のプリアンブルと、ＰＵＳＣＨ上のペイロードとを含む。ｇＮＢは、応答においてメッセージＢ（ＭｓｇＢ）を送る。本質的には、ＭｓｇＡは、Ｍｓｇ１及びＭｓｇ３を一緒に送ることと均等であると見られることができ、ＭｓｇＢは、Ｍｓｇ２及びＭｓｇ４と均等である。

ＲＡＮ＃８６（３ＧＰＰ ＲＰ－２０１６７７、２０２０年７月）において、機能削減（ＲｅｄＣａｐ）のＮＲデバイス（例えば、ユーザ機器（ＵＥ））のサポートを対象とした新しい研究項目（ＳＩ）が承認された。ＳＩは、以下の目標を含む。
「潜在的なＵＥの複雑さを減少させる特徴を識別し、研究する。
低減された数のＵＥ ＲＸ／ＴＸアンテナ
ＵＥ帯域幅の減少
留意：Ｒｅｌ－１５ＳＳＢ帯域幅は、再使用され、Ｌ１の変化は最小化されるべきである。
半二重－ＦＤＤ
緩和されたＵＥ処理時間
緩和されたＵＥ処理機能。」

ＲｅｄＣａｐ ＵＥは、比較的ローエンドのサービスを供するＮＲエンティティであるが、典的なセルラーＵＥ（非ＲｅｄＣａｐ ＵＥ）とは異なる要件／特徴を有する。例えば、ＲｅｄＣａｐ ＵＥは、非常に長いバッテリ寿命を有しうる。ＲｅｄＣａｐ ＵＥは、非ＲｅｄＣａｐ ＵＥの受信ブランチの最小数よりも少ない受信（Ｒｘ又はＲＸ）ブランチの数量を有する、非ＲｅｄＣａｐ ＵＥの最小帯域幅よりも小さい帯域幅を有する、及び／又は機能が低減された他のＵＥを指しうる。非ＲｅｄＣａｐ ＵＥは、Ｒｅｌ．１５及びＲｅｌ １６（３ＧＰＰ ＴＳ３８．３０６、（リリース１６）、バージョン１６－２、２０２０年１０月２日）で指定されたＵＥの最小要件を有するＵＥを指しうる。非ＲｅｄＣａｐ ＵＥは、レガシーＵＥ又は通常のＵＥとも呼ばれうる。一例として、非ＲｅｄＣａｐ ＵＥについての受信ブランチの最小数は、周波数範囲１（ＦＲ１）について４であり、周波数範囲２（ＦＲ２）について２である。ＲｅｄＣａｐ ＵＥは、１つ又は２つの受信ブランチを有しうる。別の例として、最低２つのＲｘブランチを装備するために非ＲｅｄＣａｐ ＵＥが必要とされるＦＲ１周波数分割複信（ＦＤＤ）又はＦＲ２帯域については、ＲｅｄＣａｐ ＵＥによってサポートされるＲｘブランチの最小数は１である。ワークアイテム記述（ＷＩＤ）は、ＲｅｄＣａｐ ＵＥのための２つのＲｘブランチのサポートも示す。別の例として、ＲｅｄＣａｐ ＵＥは、ＦＲ１について２０ＭＨｚ、ＦＲ２について１００ＭＨｚの最大帯域幅を有しうるが、非ＲｅｄＣａｐ ＵＥは、ＦＲ１及びＦＲ２についてそれぞれ１００ＭＨｚ及び４００ＭＨｚの最小帯域幅を有しうる。別の例として、ＲｅｄＣａｐ ＵＥは、最大数のＤＬ多入力多出力（ＭＩＭＯ）レイヤを有しうる（例えば、１つのＲｘブランチを有するＲｅｄＣａｐ ＵＥは、最大１つのＭＩＭＯレイヤを有しうるし、２つのＲｘブランチを有するＲｅｄＣａｐ ＵＥは、最大２つのＭＩＭＯレイヤを有しうる）。別の例として、ＲｅｄＣａｐ ＵＥは、減少させられた最大変調次数を有しうる（ＤＬにおける２５６ＱＡＭは、任意選択である）。ＲｅｄＣａｐ ＵＥは、半二重（ＨＤ）－ＦＤＤタイプＡをサポートしうる。

受信ブランチは、１つ又は複数の受信アンテナを有することができる。受信ブランチは、受信機チェーンに関連付けられる。典的には、ＦＲ１については、ブランチごとに１つの物理的なアンテナが存在する。この場合、ブランチの数は、アンテナの数に等しい。ＦＲ２については、典的には、各ブランチにおいて複数の物理的なアンテナ（ビームフォーミング）の信号の合成がある。この場合、ブランチごとに複数、例えば６４個のアンテナを有することが可能である。

ＳＩにおける減少させられた数のＵＥアンテナ／ブランチの特徴について、以下のものは、３ＧＰＰ ＴＲ３８．８７５、条項第７．２．４、Ｖ０．１．０、「Ｔｅｃｈｎｉｃａｌ Ｓｐｅｃｉｆｉｃａｔｉｏｎ Ｇｒｏｕｐ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ； Ｓｔｕｄｙ ｏｎ ｓｕｐｐｏｒｔ ｏｆ ｒｅｄｕｃｅｄ ｃａｐａｂｉｌｉｔｙ ＮＲ ｄｅｖｉｃｅｓ」（リリース１７）２０２０年１１月２５日において取り込まれた。

「一般に、減少させられた数のＲｘブランチを有するＲｅｄＣａｐ ＵＥは、レガシーＵＥと共存することができる。しかし、減少させられた数のＲｘブランチを有するＲｅｄＣａｐ ＵＥの存在は、いくつかのブロードキャストチャネルがレガシーＵＥとＲｅｄＣａｐ ＵＥの両方について使用される場合、レガシーＵＥについての性能に影響を及ぼしうる。これは、ＲｅｄＣａｐ ＵＥの早期インジケーションがない場合、レガシーＵＥとＲｅｄＣａｐ ＵＥの両方がネットワークによって同じに取り扱われることになり、これは、全てのＵＥの保存的治療をもたらしうる。」

ＳＩにおいて研究されたシナリオでは、２つのＲＸブランチを有するＲｅｄＣａｐ ＵＥに関してＭｓｇ２／Ｍｓｇ４についてダウンリンク（ＤＬ）上の補償は必要とされなかったのに対して、１つのＲＸブランチを有するＲｅｄＣａｐ ＵＥについては、以下に説明されるように、６ｄＢまでの補償が必要とされうることが観察された。従って、１つの１ＲＸブランチを有するＲｅｄＣａｐ ＵＥの早期識別／インジケーションを有することが有利であり、そのためＭｓｇ２／Ｍｓｇ４は、１ＲＸブランチの性能制限により適切な無線パラメータで送信されることができる。即ち、ＲｅｄＣａｐ ＵＥは、ネットワークへのアクセスの早期段階においてそれがＲｅｄＣａｐ ＵＥであることをネットワーク（例えば、ｇＮＢ）へ示しうるか又は識別しうる。しかし、そのような早期識別／インジケーションは、２つのＲＸブランチをもつＲｅｄＣａｐ ＵＥについては必要とされないことがある（又はまれにしか必要とされないことがある）ことに留意されたい。
初期アクセスのためのカバレージ拡張分析

複雑さを減少させる技法及び特徴の使用は、カバレージ劣化を引き起こしうるし、これは、例えば、（より小さい帯域幅を有することからの）周波数ダイバーシティの損失による、及び／又はより少ない受信ブランチ（ダイバーシティ及び／又は空間多重化の損失）によるものでありうる。

カバレージ回復評価のための複数のシナリオが、ＲｅｄＣａｐ ＵＥのランダムアクセス処理中に検討された。ＦＲ１シナリオとＦＲ２シナリオの両方が検討された。周波数範囲１（ＦＲ１）は、約６００ＭＨｚと７．２５ＧＨｚの間に広がり、ＦＲ２は、約２４．２５ＧＨｚから４７ＧＨｚの間に広がる。いくつかのチャネル及びメッセージについてのリンクバジェットが、４ＧＨｚにおけるＦＲ１市街（シナリオ１）、２．６ＧＨｚにおけるＦＲ１市街（シナリオ２）、及びＦＲ２屋内（シナリオ３）といった例示的なシナリオについて評価された。

一例として、全てのＦＲ１シナリオについて、小さいスケールのフォームファクタによるリンクバジェットの３ｄＢ損失は、（Ｍｓｇ３を含む）ＰＵＳＣＨについて補償される必要がありうると評価された。市街４ＧＨｚのシナリオ１については、受信ブランチの数が１であるとき、Ｍｓｇ２については５～６ｄＢの補償が必要とされ、Ｍｓｇ４について２～３ｄＢ補償が必要とされうることも評価された。ＲｅｄＣａｐ ＵＥが１つの受信アンテナを有するときの市街４ＧＨｚのシナリオ１のためのチャネル及びメッセージに必要とされる補償量の概要が、以下表１に示されている。チャネル及びメッセージのいくつかは、カバレージ回復を必要としうる。

以下のことが観察される。
－ ＵＥ送信電力が不正確でありうる（例えば、最小電力制御が使用される）ので、基地局におけるＰＵＳＣＨ／Ｍｓｇ３の検出成功のために、（小さいフォームファクタによる）３ｄＢの補償が必要とされうることが評価された。小さいフォームファクタの場合、２つの受信ブランチ間の距離は、半波長よりも近いものでありうる。その結果、受信ダイバーシティから３ｄＢのゲインを得ることは難しい。別のファクタは、ダウンリンク電力の評価が、小さいフォームファクタではあまり正確でないものでありうることであり、これは、Ｍｓｇ１及びＭｓｇ３のための送信電力に影響を及ぼす。ＰＵＳＣＨ／Ｍｓｇ３の検出成功のために、ＵＥは、反復のようなカバレージを補償する技法を用いて損失を補償しなければならないことがある。技法のいずれかを適用することは、ＵＥをＲｅｄＣａｐ ＵＥとして識別することに依存しうる。言い換えれば、ｇＮＢは、ＲＡＣＨ処理において、ＵＥがＲｅｄＣａｐ ＵＥであることを早期に知る必要がありうる。

－ ＲｅｄＣａｐ ＵＥが１つの受信ブランチを有する場合、Ｍｓｇ２ランダムアクセス応答（ＲＡＲ）の検出成功のために、５～６ｄＢのカバレージ損失が必要とされうることが評価された。従って、Ｍｓｇ１におけるＲｅｄＣａｐ ＵＥとしてのＵＥの早期識別／インジケーションが必要であり、これは、ダウンリンクにおいて識別されたＲｅｄＣａｐ ＵＥにカバレージ回復技法を適用するべきときを知ることにおいてｇＮＢを手助けする。これはまた、ＲｅｄＣａｐ ＵＥ及び通常の（レガシー）ＵＥ（何らカバレージ拡張を必要としなくてよいＵＥ）のためのリソースの最適化においてｇＮＢをやはり手助けしうる。

以下、表２は、ＲｅｄＣａｐ ＵＥが２つのＲｘブランチを有するときの市街４ＧＨｚのシナリオ１のためにカバレージ回復を必要とするチャネル及びメッセージを示す。受信ブランチの数が２であるとき、表２に示されるように、Ｍｓｇ２、Ｍｓｇ４及びＰＤＣＣＨについてカバレージ回復が必要とされないことは注目に値する。即ち、ＦＤＤ帯域とＴＤＤ帯域の両方を含むＦＲ１について、ならびに２つのＲｘブランチ及び減少させられたアンテナ効率を有するＲｅｄＣａｐ ＵＥについて、全てのダウンリンクチャネルの最大等方性損失（ＭＩＬ）が基準ＮＲ ＵＥについてのボトルネックチャネルのものよりも良く、ＲｅｄＣａｐ ＵＥのダウンリンクチャネルについてカバレージ回復は必要とされないことが示された。

以下、表３は、３ＧＰＰＴＲ３８．８７５Ｖ０．１．０（リリース１７）における市街シナリオのシミュレーション研究に基づいている４つのＲｘブランチを使用することから２つのＲｘブランチへの及び４つのＲｘブランチを使用することから１つのＲｘブランチへのＵＥの性能劣化を示す。ＣＳＳは、共通の探索空間を表し、ＵＳＳは、ＵＥ特有の探索空間を表す。

アップリンク同期の成功のために、及び初期アタッチメントのための許可を得るために、ＲＡＣＨ手順／処理に含まれるメッセージは、カバレージ制限されるべきではないが、これは、複雑さを減少させる特徴／技法によるＲｅｄＣａｐ ＵＥについての場合でありうる。そのような損失を補償するために、カバレージ回復技法が使用されうる。例えば、反復、低い変調及びコーディング方式（ＭＣＳ）のテーブル、及び／又はトランスポートブロック（ＴＢ）のスケーリングが、複雑さの減少による損失を補償するために使用されうる。カバレージ回復技法に関する議論は、本開示の範囲外である。ｇＮＢは、ＵＥがｇＮＢにアクセスする前にＲｅｄＣａｐ ＵＥのあらゆる存在に気付かないので、これらのカバレージ回復技法を適用することは、ＵＥがＲｅｄＣａｐ ＵＥであることを識別すること又は示すことに依存しうる。ｇＮＢが、ＲＡＣＨ処理においてＵＥがＲｅｄＣａｐ ＵＥであるかを早期に知ることができる場合、ｇＮＢは、これらの技法のうちの１つ又は複数を使用してそのＲｅｄＣａｐ ＵＥのための性能を改善することができる。

加えて、カバレージ制限が本明細書で議論されるが、考慮すべき他の態様があることに留意されたい。一例として、ＵＥはカバレージを有しうるが、メッセージを伝えるために大量のリソースを必要とする。この場合、対処される必要があるリソースの浪費がある。別の例として、Ｍｓｇ２からの５～６ｄＢペナルティ（損失）は、４の反復ファクタを常に使用することによって取り扱われうる。しかし、この場合、追加のオーバーヘッドは（反復により）かなり大きく、リソース効率の観点から、実際に補償を必要とするＵＥのみを補償することがずっとより良い。
ＲｅｄＣａｐ ＳＩで議論される早期識別の解決策
３ＧＰＰ ＴＲ３８．８７５、ｖ０．１．０では、ＲｅｄＣａｐ ＵＥ識別のための以下のオプションが議論された。
「ＲｅｄＣａｐ ＵＥの識別のための以下の方式の実現可能性、必要性、良い点、及び悪い点が研究されている。
－ オプション１：Ｍｓｇ１送信中
－ 例えば、別個の初期ＵＬ ＢＷＰ、別個のＰＲＡＣＨリソース、又はＰＲＡＣＨプリアンブル分割を介して
－ オプション２：Ｍｓｇ３送信中
－ オプション３：Ｍｓｇ４肯定応答後
－ 例えば、Ｍｓｇ５送信中又はＵＥ機能報告の一部の間」
２ステップＲＡ手順（２ステップＲＡＣＨ）のための第４のオプションも初期に検討されたが、ＳＩの過程中に優先順位が下げられた。

研究中、上記の３つのオプション全てが実行可能であることが決定された。例えば、Ｍｓｇ１における識別は、ＲｅｄＣａｐ ＵＥに関係付けられた時間又は周波数でＰＲＡＣＨプリアンブル又はオケージョンを提供することによって（構成情報を構成することによって、仕様における標準化によって、又はＳＩＢを介してなど）可能でありうる。識別は、同じ初期の帯域幅部分（ＢＷＰ）又は別個の初期のＢＷＰ内にありうる。同様に、Ｍｓｇ３における識別も可能でありうる。

ＲｅｄＣａｐ ＵＥが通常の（レガシー、非ＲｅｄＣａｐ）ＵＥよりも悪い性能を有する場合、ＲｅｄＣａｐ ＵＥの可能性ある存在により全てのＵＥ（ＲｅｄＣａｐ及び通常の両方）を保守的に扱わなければならないのとは対照的に、この早期識別は、ＲｅｄＣａｐ ＵＥ及び通常のＵＥが異なるように扱われることを可能にする。より悪い性能は、より少ない数の受信ブランチなどの複雑さ低減特徴に起因しうるか、又は小さいフォームファクタに対するアンテナ性能損失によりうる。
ＬＴＥ－Ｍデバイスのための初期アクセス

Ｒｅｌ－１３では、ネットワークは、ＭＩＢにおいてＳＩＢ１のためのＰＤＳＣＨのインジケーションを送信することによって、ロングタームエボリューションマシンタイプ通信（ＬＴＥ－Ｍ）デバイスのサポートを示す。マシンタイプ通信（ＭＴＣ）デバイスのための初期アクセスは、３ＧＰＰ ＴＳ３６．２１３及び３６．３３１において定められた。ＬＴＥ－ＭデバイスのためのＲＡＣＨ処理は、正規のＬＴＥ ＲＡＣＨ処理と多くの共通性を有し、プロトコル／交換されるメッセージは同一である。

ＭＴＣ ＵＥは、それがそのＵＥカテゴリを送るまで、それ自体をＭＴＣデバイスとして正式に識別しない。しかし、いくつかのＭＴＣ ＵＥは、カバレージ制限に悩まされる。従って、ＲＡＣＨプリアンブル（Ｍｓｇ１）及びＭＰＤＣＣＨ／ＰＤＳＣＨ（Ｍｓｇ２及びＭｓｇ４）は、何度も繰り返されうる。異なるカバレージレベル（カバレージ拡張（ＣＥ）レベルとも呼ばれる）は、参照信号受信電力（ＲＳＲＰ）に基づいて定められ、以下の表４に示されるように、ＴＳ３６．３３１、ｖ１６．２．１に特定されたＲＳＲＰ－ＴｈｒｅｓｈｏｌｄｓＰｒａｃｈＩｎｆｏＬｉｓｔの情報要素（ＩＥ）に定められる。

Ｒｅｌ－１２の既存のＰＲＡＣＨ－Ｃｏｎｆｉｇは、以下の表５に示されるように、ＴＳ ３６．３３１、ｖ１６．２．１に従ってＲＳＲＰ－ＴｈｒｅｓｈｏｌｄｓＰｒａｃｈＩｎｆｏＬｉｓｔを含むように強化された。

加えて、ＲＡＣＨ－ＣｏｎｆｉｇＣｏｍｍｏｎは、新しいＩＥ、ｒａｃｈ－ＣＥ－ＬｅｖｅｌＩｎｆｏＬｉｓｔを含み、これは、以下の表６（ｒａｃｈ－ＣＥ－ＬｅｖｅｌＩｎｆｏＬｉｓｔ－ｒ１３）に示されるように、ＴＳ３６．３３１、ｖ１６．２．１に従うｒａｃｈ－ＣＥ－ＬｅｖｅｌＩｎｆｏのリストである。

ｒａｃｈ－ＣＥ－ＬｅｖｅｌＩｎｆｏは、以下の表７に示すように、ＲＡＣＨに予期される所与のＣＥレベルにおけるＵＥごとの物理パラメータを含む。

全てのこれらＩＥは、ＴＳ ３６．３３１に示されるように、ＳＩＢにネストされる。

これに関し、通常のＵＥ（レガシー）に、（チャネル利得条件、ＲＳＲＰの観点で）最良に調整されたＬＴＥ－Ｍ ＵＥとＰＲＡＣＨ領域を共有させることが可能である。

ＬＴＥ－Ｍ ＵＥとしての所与のＣＥレベルにおけるＵＥの識別は、基地局におけるＭｓｇ１の受信において実行される。ＵＥは、ＲＳＲＰに従って適切なプリアンブルを選択する。基地局は、それがＭｓｇ１を受信するまで、カバレージ拡張の量が必要であることを知らない。ネットワークは、構成されたアップリンクリソースにおいて、それがＭｓｇ１を受信するまで、ＬＴＥ－Ｍデバイスの存在に気付かない。しかし、以下の態様に留意されたい。
・ 早期識別は、ＵＥがＲＳＲＰに基づいて決定する選択されたＲＡＣＨリソースに基づいて実行される。

・ 様々なＣＥレベルのＵＥがＭｓｇ１において識別されるが、ＭＴＣ ＵＥがＭｓｇ１において識別され、一方、他のものがＭｓｇ５において識別されるケースはなく、そのような処理は、基地局が限られた数のＰＲＢ（６）を占めるＭＴＣ ＵＥを監視しなければならないので、現在のＬＴＥフレームワークにおいて達成することは実際に不可能である。従って、Ｍｓｇ２が適切に受信されることができるように、ＭＴＣ ＵＥがＭｓｇ１において識別されることが必須である。

本開示の実施形態は、ＵＥが、Ｍｓｇ５（又は後のＵＥ機能交換）によって、又はＭｓｇ１等における早期識別によって、それ自体をＲｅｄＣａｐ ＵＥとして識別することを可能にする機構を提供する。即ち、同時に、ｇＮＢは、（全てのＲｅｄＣａｐ ＵＥが同時に－早期に又は早期にではなく－識別されることとは対照的に）いくつかのＲｅｄＣａｐ ＵＥが早期に識別され、一方、他のものが後の段階で識別されることを可能にする構成を提供しうる。いくつかのＲｅｄＣａｐ ＵＥは、ＲｅｄＣａｐ ＵＥとして識別される機能の交換まで、（現在の初期アクセス処理を使用して）通常のＵＥと同様の識別を有しうるが、他のＲｅｄＣａｐ ＵＥは、Ｍｓｇ１又はＭｓｇ３の段階で識別されうる。後者の場合、追加機能の交換は、ＲＡ手順後でＭｓｇ５の後に（又はＭｓｇ５において）行われうる。

ＬＴＥ－Ｍデバイスのための個別初期アクセス手順と比較して、ＲｅｄＣａｐ ＵＥ識別のための提案された解決策は、（いくつかは早期段階－Ｍｓｇ１又はＭｓｇ３で、他のものはＭｓｇ５で）識別の混合を可能にする。個別リソースを使用することは、本解決策から除外されないことに留意されたい。

いくつかの実施形態では、ＲｅｄＣａｐ ＵＥタイプが定義されてよく（タイプは、例えば、受信アンテナの数、サポートされる帯域幅、又はそれらの組合せに基づいて異なることがある）、この場合、異なるタイプのＲｅｄＣａｐ ＵＥが、別個の経路に沿って、即ち、ＲＡＣＨ手順の異なる段階において、識別が行われるときの観点で、取り扱われうる。この場合、ｇＮＢは、Ｍｓｇ５において全てのＵＥを識別しなければならないことを回避することが可能でありうるとともに、Ｍｓｇ１又はＭｓｇ３において全てのＵＥを識別しなければならないことを回避することも可能である。そのような解決策を用いて、ＲｅｄＣａｐ ＵＥタイプに基づく最適化が可能である。一実施形態では、ＲｅｄＣａｐ ＵＥタイプは、ＲｅｄＣａｐ ＵＥが有する受信アンテナ／ブランチの数、又はサポートされる帯域幅、或いはその両方に基づいて定められる。

本明細書で使用される場合、ＵＥがＲｅｄＣａｐ ＵＥであることを識別する又は指示することは、説明の便宜上、ＲｅｄＣａｐ ＵＥの識別若しくはインジケーション、又はＵＥの識別若しくはインジケーションと呼ばれうる。ランダムアクセス手順が完了する前の（又はランダムアクセス手順中の）、例えば、Ｍｓｇ１、Ｍｓｇ３、又はＭｓｇＡの段階での、ＲｅｄＣａｐ ＵＥの識別又はインジケーションは、早期識別若しくはインジケーション、又は早期段階での識別若しくはインジケーションと呼ばれうる。ランダムアクセス手順が完了した後の機能の交換中のＲｅｄＣａｐ ＵＥの識別又はインジケーションは、従来から実行されているもののように、説明の便宜上、後の（又は正規若しくは標準の）識別若しくはインジケーション、又は後の段階における識別若しくはインジケーションと呼ばれうる。以下の説明では、用語「経路」は、別段の定めがない限り、例えば、早期識別／インジケーション又は後の識別／インジケーションによって、ＵＥをＲｅｄＣａｐ ＵＥとして示す／識別する方法又はやり方を示すために使用される。「ＵＥを識別すること（又はＵＥを識別する、ＵＥの識別）」及び「ＵＥを示すこと（又はＵＥを示す、ＵＥのインジケーション）」という用語は、交換可能に使用される。以下において、「ｎ個のＲｘブランチを有するＲｅｄＣａｐ ＵＥ」は、説明の便宜上、単に、「ｎＲＸ ＲｅｄＣａｐ ＵＥ」、「ｎＲＸ ＵＥ」、又は「ｎＲＸを有するＵＥ」と呼ばれうるし、ｎは０よりも大きい整数である。
いくつかの実施形態では、ＵＥがＲｅｄＣａｐ ＵＥであることを示すために、２つの経路、即ち経路Ａ及び経路Ｂが定められる。

・ 経路Ａ：ＵＥは、Ｍｓｇ５（機能の交換）中にＲｅｄＣａｐ ＵＥとして識別される。ＵＥのＵＥ機能／特徴／特徴セットのうちの１つ又は複数は、ＲｅｄＣａｐ ＵＥとしてＵＥを識別するために使用されうる。これは、１つの個別ＵＥ機能（例えば、ＲｅｄＣａｐ ＵＥなどの特徴が定められる）の使用によって、又は既存及び／又は新しいＵＥ機能のセット（例えば、ＵＥ帯域幅、アンテナの数など）によってであることができる。そのような場合、ＵＥ特徴のうちのいくつかが、所与の組合せのセット（例えば、ＢＷ２０ＭＨｚ、１つのＲＸアンテナ）から選択されるとき、ｇＮＢは、ＵＥがＲｅｄＣａｐ ＵＥであることを知る。

・ 経路Ｂ：ＵＥは、Ｍｓｇ５よりも先にＲｅｄＣａｐとして識別される。これは、例えば、Ｍｓｇ１、ＭｓｇＡ、又はＭｓｇ３の送信中であることができる。ＵＥは、（例えば、Ｍｓｇ１を送信するためのプリアンブル／リソース選択を使用することによって）暗示的に、又は（例えば、Ｍｓｇ３における１ビットの設定によって）明示的に、それがＲｅｄＣａｐ ＵＥであることをネットワークに知らせうる。

経路Ａは、後の識別又はインジケーションに対応し、経路Ｂは、早期識別又はインジケーションに対応する。経路Ｂは、早期経路とも呼ばれうる。経路Ａは、正規経路、後経路、又は通常経路とも呼ばれうる。上記では、経路Ａが、Ｍｓｇ５に関係付けられており、経路Ｂが、Ｍｓｇ１、Ｍｓｇ３、又はＭｓｇＡに関係付けられていることに留意されたい。

図４は、例示的なカバレージエリア、及びＵＥのアンテナ／ブランチの数を強調した、一実施形態の通信ネットワーク４００を示す図である。図示されるように、ネットワーク４００は、ｇＮＢ４１０を含み、これは、１つのＲｘブランチを有するＵＥについてのカバレージエリア４１２と、２つのＲｘブランチを有するＵＥについてのカバレージエリア４１４とを有する。ＲｅｄＣａｐ ＵＥ４２２及び４２４はそれぞれ、１つのＲｘブランチを有する。ＲｅｄＣａｐ ＵＥ４２６及び４２８はそれぞれ、２つのＲｘブランチを有する。カバレージエリア４１２内のＵＥ４２２及び４２６、ならびにカバレージエリア４１４内のＵＥ４２８は、経路Ａを使用して、それらがＲｅｄＣａｐ ＵＥであることを示しうる。カバレージエリア４１４内のＵＥ４２４は、経路Ｂを使用して、それがＲｅｄＣａｐ ＵＥであることを示しうる。

いくつかの実施形態では、経路Ａ又は経路ＢがＲｅｄＣａｐ ＵＥの識別のために使用されるかを選択／決定するために基準が、ＵＥのために定義されうる。以下のものは、例示的な基準（Ｃ）Ｃ１及びＣ２を与える。
・ Ｃ１：経路Ａ又は経路Ｂの選択は、ＲｅｄＣａｐ ＵＥの受信アンテナの数に基づく：
ｏ ２ＲＸ（２つのＲｘアンテナ／ブランチ）を有するＵＥは、経路Ａを使用する
ｏ １ＲＸ（１つのＲｘアンテナ／ブランチ）を有するＵＥは、経路Ｂを使用する
・ Ｃ２：経路Ａ又は経路Ｂの選択は、ＲｅｄＣａｐ ＵＥの受信アンテナの数及び複信のモードに基づく：
ｏ ２ＲＸを有するＵＥは、ＦＲ１ ＦＤＤ及びＦＲ２において経路Ａを使用する
ｏ １ＲＸを有するＵＥは、ＦＲ１ ＦＤＤ及びＦＲ２において経路Ｂを使用する
ｏ ２ＲＸを有するＵＥは、ＦＲ１ ＴＤＤにおいて経路Ｂを使用する

基準Ｃ１によれば、ＵＥが２つの受信ブランチを有するとき、ＵＥは、ＲＡ手順の後にＲｅｄＣａｐ ＵＥとしてそれを示してよく、ＵＥが１つの受信ブランチを有するとき、ＲＡ手順中にＲｅｄＣａｐ ＵＥとしてそれを示してよい。

基準Ｃ２によれば、ＵＥが２つの受信ブランチを有し、ＦＲ１ ＦＤＤ帯域及びＦＲ２帯域において動作可能であるとき、それは、ＲＡ手順の後にそれがＲｅｄＣａｐ ＵＥであることを示しうる。ＵＥが１つの受信ブランチを有し、ＦＲ１ ＦＤＤ帯域及びＦＲ２帯域において動作可能であるとき、それは、ＲＡ手順中にそれがＲｅｄＣａｐ ＵＥであることを示しうる。ＵＥが２つの受信ブランチを有し、ＦＲ１ ＴＤＤ帯域において動作可能であるとき、それは、ＲＡ手順中にそれがＲｅｄＣａｐ ＵＥであることを示しうる。現在、ＦＲ２は、ＴＤＤとして定義されていることに留意されたい。上記の基準Ｃ１及びＣ２は、Ｒｘアンテナの数に基づいて定められる。ＲｅｄＣａｐ ＵＥは、１つ又は複数の周波数帯域上での動作をサポートしうる。しかし、ＷＩＤの目標によれば、ＲｅｄＣａｐ ＵＥは、２つ以上の周波数上で同時に動作することが許可されないことに留意されたい。この場合、基準Ｃ２も、何らかの修正とともに適用することができる。例えば、Ｃ２は、ＵＥがＦＲ１ ＦＤＤ又はＦＲ２において動作可能であるとき、２ＲＸを有するＵＥが経路Ａを使用し、ＵＥがＦＲ１ ＦＤＤ又はＦＲ２において動作可能であるとき、１ＲＸを有するＵＥが経路Ｂを使用することを指定するように変更されてよい。従って、経路選択のための実施形態基準の実装は、ＲｅｄＣａｐ ＵＥが１つ又は複数の周波数帯域で動作することを許可されるかに応じて変わりうる。当業者は、基準の様々な修正、代替、及び実施形態が、本開示の趣旨及び原理から逸脱することなく、それがＲｅｄＣａｐ ＵＥであることを識別するためにＵＥが経路を選択することに適用可能でありうることを認識するであろう。

いくつかの実施形態では、基準は、帯域幅又は帯域に基づいて定められうる。一例として、例えば、帯域幅が２０ＭＨｚよりも大きい１つの第１の帯域（又は複数の第１の帯域）については、ＲｅｄＣａｐ ＵＥは、早期インジケーションを使用することができ、例えば、帯域幅が２０ＭＨｚ以下である１つの第２の帯域（又は複数の第２の帯域）については、ＲｅｄＣａｐ ＵＥは、機能の交換（Ｍｓｇ５）中にＲｅｄＣａｐ ＵＥとしてそれ自体を示すことができる。

いくつかの実施形態では、基準はまた、（アンテナ結合前又はアンテナ結合後の）ＲＳＲＰ、参照信号受信品質（ＲＳＲＱ）、参照信号強度インジケータ（ＲＳＳＩ）などを含む無線チャネル状態を示すパラメータなどの１つ又は複数の他のパラメータに基づいて定められてもよい。一例として、可能な基準Ｃ３は、以下の通りでありうる。
・ Ｃ３：経路Ａ又は経路Ｂの選択は、アンテナ結合後のＲＳＲＰに基づく
ｏ ＲＳＲＰ＞閾値を有するＵＥは、経路Ａを使用する。
ｏ ＲＳＲＰ≦閾値を有するＵＥは、経路Ｂを使用する

一般に、評価された信号品質は、各ブランチについて個々に実行されてよく、最高の信号品質が使用されうる。信号品質の評価は、アンテナ／ブランチからの信号が結合される２つ以上のブランチに基づいてもよい。例えば、受信電力の評価は、各ブランチについての評価の（線形ドメイン内の）和に基づきうる。特定の例では、一のＲＳＲＰの評価は、－８０ｄＢｍであり、第２のＲＳＲＰの評価は、－８３ｄＢｍであり、結合された評価は、－７８．２ｄＢｍである。

基準Ｃ３によれば、ＵＥは、識別のために、ＲＳＲＰ測定をＲｅｄＣａｐ ＵＥのために構成された閾値と比較しうる。ＲＳＲＰ測定が閾値よりも大きいとき、ＵＥは、ＲＡ手順後にそれをＲｅｄＣａｐ ＵＥとして示す。ＵＥのＲＳＲＰ測定が閾値以下であるであるとき、ＵＥは、ＲＡ手順中にそれをＲｅｄＣａｐ ＵＥとして示す。

Ｃ３は、ＵＥについて単一の閾値を有する。いくつかの実施形態では、ＵＥは、異なる閾値間の差はどの経路を使用するかを決定するためにＵＥによって使用されるＲＳＲＰメトリック上に自然に現れないと仮定して、そのタイプ（上述されたようなＲｅｄＣａｐタイプ）又は機能に基づいて提供される単一の閾値を選択又は修正しうる。例えば、ＲＳＲＰ測定が３ｄＢであり、ＲＸアンテナの数が２倍である場合、複数の閾値の必要はないことがある。しかし、他の手段（例えば、１つのアンテナのみで測定されたＲＳＲＰ）を用いて、ファクタが閾値に追加されてよい。又は、任意選択で、小さいフォームファクタｄＢに基づく補正が、閾値に対して実行されてよい。

閾値は、カバレージエリアに関係付けられうる。例えば、図４の「１つのＲＸアンテナを有するＵＥについてのカバレージエリア４１２」は、第１の閾値に関係付けられてよく、図４の「２つのＲＸアンテナを有するＵＥについてのカバレージエリア４１４」は、第２の閾値に関係付けられてよい。カバレージエリア４１２及び４１４内のＵＥは、対応する閾値を使用して、ＲｅｄＣａｐ ＵＥインジケーションのための経路を決定しうる。Ｃ３については、ＲＳＲＰの手段は、例えば、ＳＳＢブロック、又はＰＤＣＣＨのための復調参照信号（ＤＭＲＳ）に対して実行される測定に基づいて定められうる。ＲＳＲＰの様々な測定が本開示の実施形態に適用されうることを当業者は認識するであろう。

図５は、ＵＥによる実施形態の動作を示す流れ図５００である。ＵＥは、経路選択基準を得てよい（ブロック５０２）。ＵＥは、経路選択基準、例えば、Ｃ１、Ｃ２、又はＣ３を知る必要がある。ＵＥが経路選択基準を得るいくつかの可能性がありうる。一実施形態では、標準仕様は、ＵＥによってどの経路を使用するかを規定しうる。例えば、Ｃ１については、ＵＥ挙動は、センテンス、例えば、「１つの受信アンテナを有するＲｅｄＣａｐ ＵＥは、Ｍｓｇ１中又はＭｓｇ３中にそれ自体を識別する」を用いて標準仕様においてハードコーディングされうる。これは、Ｃ１又はＣ２がＵＥによって使用されるべきであることを示しうる。一実施形態では、ＲｅｄＣａｐ ＵＥインジケーションのためにＵＥによってどの経路を使用するかは、ＵＥのために事前構成されうる。一例として、どの経路を使用すべきかは、ＳＩＢ又は他のシグナリングメッセージにおいて示されうる。例えば、Ｃ３については、ネットワーク／基地局は、ＳＩＢにおけるＲＳＲＰ閾値を示しうる。これは、Ｃ３がＵＥによって使用されるべきであることを示しうる。ネットワークは、基準のうちのどれがＲｅｄＣａｐ ＵＥを識別するために使用されるべきかを暗示的又は明示的にシグナリングしうる。

ＵＥは、経路構成を得てよい（ブロック５０４）。ＵＥは、ａ）複数の経路が存在するかどうか、及びｂ）経路Ｂのためにどんな構成があるかを知ることが必要である。ａ）について、１つの経路（例えば、経路Ａ）が構成される場合がありうる。例えば、ｇＮＢが互いに近接している密度の高い展開シナリオでは、たった１つのＲＸアンテナを有するＲｅｄＣａｐ ＵＥさえも、ＣＥ手段なしでｇＮＢと通信することが十分可能であることが予期される。従って、ＳＩＢ中のパラメータは、たった１つの経路が構成されるかを示しうる。このシグナリングは、ｂ）についての構成に基づいて明示的であってもよい。ｂ）について、ＵＥは、この例における早期識別のためのリソース構成を得る必要がある。例えば、識別がＭｓｇ１／ＭｓｇＡ又はＭｓｇ３中に実行される場合、ＲｅｄＣａｐ ＵＥは、どのパラメータ（時間リソース／ＰＲＢ／プリアンブル）が早期インジケーションのために使用されるべきかを知る必要がある。様々なＣＥレベルを有するＬＴＥ－Ｍデバイスのために使用されるものと同様のシグナリングが使用されうる。一般に、経路構成は、使用するべき利用可能な経路についての情報、早期インジケーションのためのＲＡＣＨ構成（時間周波数リソース、及び／又はプリアンブル）、及び／又は経路ＢがＭｓｇ１若しくはＭｓｇ３、又はＭｓｇＡ中に実行されるかを示す情報を含みうる。

ＵＥは、使用すべき経路を決定／選択してよい（ブロック５０６）。ＲｅｄＣａｐ ＵＥが全ての関連するＲＡＣＨ構成パラメータを得たとき、それはどの経路を使用すべきかを決定する必要がある。場合によっては、この動作は些細なものであり、何も実行される必要はない（例えば、Ｃ１に関しては、ＲｅｄＣａｐ ＵＥは、それが有するアンテナの数を知っており、それは対応する経路を直接選択しうる）。しかし、場合によっては、この決定は追加の動作を必要とする。例えば、Ｃ３については、ＲｅｄＣａｐ ＵＥは、ＲＳＲＰ測定を実行して経路を選択する必要がある。

ＵＥは、選択された経路に従ってそれ自体をＲｅｄＣａｐとして識別しうる（ブロック５０８）。経路が選択されると、ＲｅｄＣａｐ ＵＥは、選択された経路に従って進行する。例えば、経路Ａが選択された場合、ＵＥは、特別なことを何も行う必要がなくてよく、ＲＡＣＨ処理の後に、機能の交換中に（それがＲｅｄＣａｐ ＵＥであるかを示す）その機能を単に送ってよい。例えばＭｓｇ１中の識別を示しうる経路Ｂが選択される場合、ＲｅｄＣａｐ ＵＥは、早期識別（経路Ｂ）のためにｇＮＢによって示される／構成されるようなリソース（時間リソース／ＰＲＢ／プリアンブルインデックス）のセットを選択する必要がある。

図６は、基準Ｃ１に基づく経路選択のための実施形態の動作を示す図６００である。ＵＥ（ＲｅｄＣａｐ ＵＥ）は、ＳＩＢから経路構成を得てよい（ブロック６０２）。経路構成は、図５のブロック５０４で説明されるものと同様でありうる。次いで、ＵＥは、それが１つのＲｘアンテナを有するかどうかをチェックしうる（ブロック６０４）。ＵＥが２つ以上のＲｘアンテナを有するとき、ＵＥは、正規の識別、即ち経路Ａを実行しうる（ブロック６０６）。即ち、ＵＥは、ＲＡＣＨ手順後、例えば、ＵＥとネットワークとの間の機能の交換中に、それがＲｅｄＣａｐ ＵＥであることを識別しうる。ＵＥが１つのＲｘアンテナを有するとき、ＵＥは、早期識別、即ち、経路Ｂを実行しうる（ブロック６０８）。即ち、ＵＥは、ＲＡＣＨ手順中に、例えば、Ｍｓｇ１、Ｍｓｇ３、又はＭｓｇＡの送信中に、それがＲｅｄＣａｐ ＵＥであることを識別しうる。

図７は、ｇＮＢの実施形態の動作を示す図７００である。ｇＮＢは、それがＲｅｄＣａｐ ＵＥをサポートするかをチェックしてよい（ブロック７０２）。ｇＮＢがＲｅｄＣａｐ ＵＥをサポートしない場合、ｇＮＢは、ＲｅｄＣａｐ ＵＥを排除しうる（ブロック７０４）。この場合、ｇＮＢは、ＲｅｄＣａｐ ＵＥにサービスを提供しなくてよい。ｇＮＢがＲｅｄＣａｐ ＵＥをサポートする場合、それは、それがカバレージ回復をサポートするかをチェックしうる（ブロック７０６）。ｇＮＢがカバレージ回復をサポートしない場合、ｇＮＢは、経路Ａに従ってＲｅｄＣａｐ ＵＥを検出しうる（ブロック７０８）。即ち、ｇＮＢは、経路Ａに従って実行されるインジケーション／識別に基づいて、ＵＥがＲｅｄＣａｐ ＵＥであることを知りうる。ｇＮＢがカバレージ回復をサポートする場合、ｇＮＢは、カバレージ回復のためのパラメータをＵＥに提供しうる（ブロック７１０）。ｇＮＢは、早期検出を実行しうる（ブロック７１２）。即ち、ｇＮＢは、ＵＥのＲＡＣＨ手順中に、例えば、Ｍｓｇ１、Ｍｓｇ３、又はＭｓｇＡにおいて（経路Ｂに従って）、それがＲｅｄＣａｐ ＵＥであることをＵＥが示す／識別するかを検出しうる。ｇＮＢが（経路Ｂによる）早期検出中にＵＥからのインジケーション／識別を検出しない場合、ｇＮＢは、経路Ａに従ってＵＥを検出しうる（ブロック７１４）、即ち、ｇＮＢは、ＲＡＣＨ手順後にＲｅｄＣａｐ ＵＥを検出する。ｇＮＢが早期検出中にＵＥからのインジケーション／識別を検出した場合、ｇＮＢは、ＵＥと通信するためにカバレージ回復手段を適用してよい（ブロック７１６）。一例として、ＵＥがＭｓｇ１において示す場合、ｇＮＢは、ＲＡＣＨ手順中にＭｓｇ１を受信した後に、ＵＥへの全てのＤＬ送信についてカバレージ回復手段を適用しうる。ＵＥがＭｓｇ３において示す場合、ｇＮＢは、ＲＡＣＨ手順中にＭｓｇ３を受信した後に、ＵＥへの全てのＤＬ送信についてカバレージ回復手段を適用しうる。ＵＥがＭｓｇＡにおいて示す場合、カバレージ回復手段は、ＭｓｇＢをＵＥに送信するために適用されうる。ＵＥは、受信されたカバレージ回復技法を適用してこれらのＤＬ送信を受信しうる。アップリンクでは、ＵＥは、ＲＡ手順中にメッセージの送信を繰り返してよい。ＵＥとネットワークの両方がＭｓｇ３反復をサポートする場合、ＵＥは、反復のための構成に従ってＭｓｇ３の送信を繰り返してよい。Ｍｓｇ３はまた、ＨＡＲＱ手順に基づいて再送信されてもよく、これは、より大きい遅延を招きうる。

通常のＵＥが４つのＲＸブランチを使用するＦＲ１ ＴＤＤ帯域については、２ＲＸ ＲｅｄＣａｐ ＵＥ及び１ＲＸ ＲｅｄＣａｐ ＵＥは、（例えば、より少数のブランチにより）通常のＵＥとは異なる挙動を有し、従って、２ＲＸ ＵＥに通常経路を使用させることは、ＲｅｄＣａｐ ＵＥと非ＲｅｄＣａｐ ＵＥの両方に対して何らかの保守的な取り扱いを必要としうる。周波数帯域に基づいて、ＲｅｄＣａｐ ＵＥと非ＲｅｄＣａｐ ＵＥとの間に区別がありうる。この場合、ＲｅｄＣａｐ ＵＥの識別は、入力パラメータとしてのＲＸアンテナの数（１、２、又は４）ならびに帯域をとる基準を用いて、上述されたフレームワークにおいて行われることができる。インジケーションに基づいて、ネットワークは、ＲｅｄＣａｐ ＵＥとの通信を補償するための措置をとりうる。基準Ｃ１がＦＲ１ ＴＤＤのために使用された場合、２Ｒｘ ＵＥは、保守的な取り扱いが使用された場合、通常経路を使用しうる。これは、他の帯域には当てはまらないかもしれない

いくつかの実施形態では、ＦＲ１ ＴＤＤ帯域において動作可能なＲｅｄＣａｐ ＵＥが、通常経路又は早期経路に従ってそれ自体を識別するかは、ＳＩＢ構成によって構成され／示されうる。一例として、ＳＩＢ構成は、異なる経路に使用するための経路選択基準及びパラメータを含むようにブロードキャストされうる。別の例として、ｇＮＢは、どの経路を使用すべきか（例えば、常に経路Ｂを使用する）を示すために、ＳＩＢにフィールドを単に追加してよい。同様に、レガシーＵＥのために４ＲＸが必須であるＦＤＤ帯域において動作可能なＲｅｄＣａｐ ＵＥについては、ＳＩＢは、ＵＥが経路を決定するための経路構成及び経路選択基準を示すためにブロードキャストされうる。

いくつかの実施形態では、Ｃ３で説明されたように、瞬時のチャネル状態、例えば、アンテナ結合後のＲＳＲＰによって表されるチャネル状態は、どの経路を使用すべきかを決定するためにＵＥによって検討されうる。一実施形態では、ＲｅｄＣａｐ ＵＥは、チャネル状態が通常経路のために構成された閾値内にある場合、それを通常経路を使用したＲｅｄＣａｐ ＵＥとして識別しうる。このようにして、２ＲＸを有するＲｅｄＣａｐ ＵＥが特に悪い状態にある場合、それは、それが１ＲＸ ＵＥであるかのようにアクセスすることができ、特に良好な状態にある１ＲＸ ＵＥは、それが２ＲＸ ＵＥであるかのようにアクセスすることができる。

いくつかの実施形態では、ＲｅｄＣａｐ ＵＥが経路を選択するための基準は、１ＲＸ ＲｅｄＣａｐ ＵＥ又は２ＲＸ ＲｅｄＣａｐ ＵＥのうちの１つが経路を選択することができるように定められうる。以下は、そのような例示的な基準Ｃ４を提供する。
・ Ｃ４：経路Ａ又は経路Ｂの選択は、２つのＲＸアンテナを有するＵＥについてアンテナ結合後のＲＳＲＰに基づく：
ｏ ２つのＲＸアンテナ及びＲＳＲＰ＞閾値を有するＵＥは、経路Ａを使用する
ｏ ２つのＲＸアンテナ及びＲＳＲＰ≦閾値を有するＵＥは、経路Ｂを使用する
ｏ １つのＲＸアンテナを有するＵＥは、経路Ｂを使用する
又は：
・ Ｃ５：経路Ａ又は経路Ｂの選択は、１つのＲＸアンテナを有するＵＥについてのアンテナ結合後のＲＳＲＰに基づく
ｏ １つのＲＸアンテナ及びＲＳＲＰ＞閾値を有するＵＥは、経路Ａを使用する
ｏ １つのＲＸアンテナ及びＲＳＲＰ≦閾値を有するＵＥは、経路Ｂを使用する
ｏ ２つのＲＸアンテナを有するＵＥは、経路Ａを使用する

上記の基準（Ｃ４及びＣ５）では、経路を選択するための閾値の使用は、ＲｅｄＣａｐ ＵＥの特徴に基づく。一方のＲｅｄＣａｐ ＵＥの特徴は、２つのＲＸアンテナを有するＵＥであり、他方のＲｅｄＣａｐ ＵＥの特徴は、１つのＲＸアンテナを有するＵＥである。例えば、Ｃ４では、２ＲｘのＲｅｄＣａｐ ＵＥのみが、経路を選択するためにＲＳＲＰ閾値を使用することが許可され、一方、１Ｒｘを有するＵＥは、ＲＳＲＰを使用することは許可されない。１Ｒｘ ＵＥは、常に経路Ｂ、即ち早期識別を使用する。

Ｃ４についての根源は、あまりに多くのＵＥが、通常経路、及びＰＲＡＣＨプリアンブルなどの初期アクセスリソースを使用するのを防ぐために、１ＲＸ ＵＥが、それらが良好なチャネル状態であっても、通常経路を使用することを許可しないことが望ましいものでありうることである。Ｃ５についての根源も同様である。一例では、各ＲｅｄＣａｐ ＵＥの個々の無線状態を考慮する必要なく、経路Ａと経路Ｂとの間のＲＡＣＨリソースの準静的な分割が可能でありうる。

Ｃ５では、１Ｒｘを有するＲｅｄＣａｐ ＵＥのみが、経路を選択するためにＲＳＲＰ閾値を使用することが許可され、ここで、ＵＥは、早期に識別される、又はより後の段階で識別されうる。２Ｒｘ ＵＥは、常に経路Ａを使用する。

上記の全てのこれらの例示的な基準では、ｇＮＢは、異なる基準を満足し、異なる段階で識別されうるＲｅｄＣａｐ ＵＥを有しうる。例えば、いくつかのＲｅｄＣａｐ ＵＥは、早期段階で識別されてもよく（早期識別）、一方、いくつかの他のＲｅｄＣａｐ ＵＥは、後の段階で識別される。経路Ａ又は経路ＢのいずれかによるＲｅｄＣａｐ ＵＥの識別後、完全な機能の交換は、Ｍｓｇ５などの後の段階で起こりうる。

図８は、基準Ｃ４に基づく経路選択についての実施形態の動作を示す図８００である。ＵＥ（ＲｅｄＣａｐ ＵＥ）は、ＳＩＢから経路構成を得てよい（ブロック８０２）。経路構成は、図５のブロック５０４で説明されたものと同様でありうる。次いで、ＵＥは、それが２つのＲｘアンテナを有するか、及びＲＳＲＰ測定が閾値よりも大きいかをチェックしうる（ブロック８０４）。ＵＥが２つのＲｘアンテナを有し、ＲＳＲＰ測定が閾値よりも大きいとき、ＵＥは、正規の識別、即ち経路Ａを実行しうる（ブロック８０６）。ＵＥが２つのＲｘアンテナを有しない、又はＲＳＲＰ測定が閾値よりも大きくないとき、ＵＥは、早期識別、即ち経路Ｂを実行しうる（ブロック８０８）。この例は、図６に関して示された例と組み合わされうるし、そこでは、１ＲｘのＲｅｄＣａｐ ＵＥが、常に早期識別を使用する。

上記の実施形態では、２つの経路が説明される。しかし、３つ以上の経路が定められうることに留意されたい。例えば、Ｍｓｇ１、Ｍｓｇ３、及びＭｓｇ５による識別にそれぞれ対応する３つの経路が定義されうる。ＵＥは、例えば、ネットワーク構成又は基準に基づいて、それがＲｅｄＣａｐ ＵＥであることを識別するために経路のうちのどれを使用すべきかを決定しうる。この場合には、複数の（３つ以上の）経路が利用可能であるとき、経路の選択は、いくつかの異なる実施形態、検討事項、及び／又はファクタに基づきうる。例えば、選択は以下の通りでありうる。
・ 閾値ベース（例えば、ＲＳＲＰ）
・ ＵＥ実装ベース（例えば、ＵＥは、そのそれ自体のアンテナ不完全性の知識を有する）
・ トラフィックベース（例えば、ＵＥは、ＲＲＣ接続後に通常通信されるそのサブスクリプション又は他の情報の知識を有する）。

「ハイエンド」及び「ローエンド」のウェアラブルがある場合、経路を選択するための基準は、ウェアラブルのタイプに基づきうる。例えば、ハイエンドウェアラブルは経路Ａを使用してもよく、ローエンドウェアラブルは経路Ｂを使用してよい。

本開示の実施形態は、ＲｅｄＣａｐ ＵＥについて説明されるが、それらは、ローエンドスマートフォン、カバレージ拡張を必要とする「正規の」ＵＥ、産業用センサ等などの他のシナリオに適用可能である。

以下は、Ｍｓｇ５識別の実施形態を説明する（即ち、ＲｅｄＣａｐ ＵＥは、それを（機能の交換中の）Ｍｓｇ５におけるＲｅｄＣａｐ－経路Ａとして識別する）。Ｍｓｇ５識別は、以下の説明において、Ｍｓｇ５経路識別とも呼ばれうる。

ＲｅｄＣａｐ識別に可能な異なる経路が存在し、そのうちの１つは、ＲＡＣＨ処理後又はＵＥ機能の後の交換後の典的なＭｓｇ５であり、ここで、ＵＥは、それがＲｅｄＣａｐ ＵＥであるというインジケーション又は識別を含むことができるその特性をｇＮＢに知らせる。ＲｅｄＣａｐの特徴に加えて、この解決策は、実際には、いかなる標準的な変更も必要としない。一実施形態では、２つのＲｘアンテナを有するＲｅｄＣａｐ ＵＥは、Ｍｓｇ５経路識別を使用して識別されうる。別の実施形態では、１つのＲｘアンテナを有するが、とても強いチャネル利得条件（例えば、ＲＳＲＰ閾値よりも大きいＲＳＲＰ）を有するＲｅｄＣａｐ ＵＥも、Ｍｓｇ５経路識別を使用しうる。この識別経路は、本開示において後で説明されるように、Ｍｓｇ１又はＭｓｇ３を通じて他の識別経路と組み合わされてよい。

以下は、Ｍｓｇ１識別の実施形態を説明する（即ち、ＲｅｄＣａｐ ＵＥは、それを（ＲＡＣＨ処理中の）Ｍｓｇ１におけるＲｅｄＣａｐ－経路Ｂとして識別する）。上述されたように、ＲｅｄＣａｐ ＵＥを識別する１つの可能なやり方は、ＲｅｄＣａｐ ＵＥによるＭｓｇ１送信中など、早期の経路識別によるものである。この経路のための構成は、ＳＩＢにおいて提供されうる。例えば、Ｍｓｇ１における識別は、ＲｅｄＣａｐ ＵＥに関係付けられた時間又は周波数におけるＰＲＡＣＨプリアンブル又はオケージョンを（構成情報によって、標準仕様を指定することによって、又はＳＩＢにおいてなど）提供することによって可能でありうる。これらは、同じ初期ＢＷＰ内、又は別個の初期ＢＷＰ内にありうる。早期の経路識別は、通常識別のために使用される初期ＵＬ ＢＷＰと同じ又は別個の初期ＵＬ ＢＷＰにおいて実行されうる。初期ＢＷＰについての情報は、ＳＩＢにおいてブロードキャストされうる。異なる初期ＵＬ ＢＷＰに関係付けられた異なるＲＡＣＨ構成が存在しうる。

一例では、ＰＲＡＣＨ構成は、ＳＩＢ中でブロードキャストされうるし、ここで、ＰＲＡＣＨ構成は、経路Ｂを使用してＲｅｄＣａｐ ＵＥを識別するために使用される情報を含む。一例として、ＰＲＡＣＨ構成は、ＰＲＡＣＨプリアンブル、ＲＡＣＨオケージョン、又はそれらの組合せの情報を含みうるし、これは、ＲｅｄＣａｐ ＵＥを示す／識別することに関係付けられる。上述されたように、ＲｅｄＣａｐ ＵＥの早期識別のために、ＲＡＣＨ処理中の他のメッセージ、例えば、Ｍｓｇ３又はＭｓｇＡも使用されうる。Ｍｓｇ１、Ｍｓｇ３、又はＭｓｇＡのうちのどれが、早期識別のために使用されるべきかは、無線リソース制御（ＲＲＣ）構成によって構成されうる。ＲＲＣ構成は、ｇＮＢによってブロードキャストされうる。
ＳＩＢを受信すると、ＵＥは、以下のうちの１つ又は複数などのＰＲＡＣＨ構成及び送信パラメータの知識を有することになる。
・ ＰＲＡＣＨプリアンブルのフォーマット
・ 時間－周波数リソース
・ ルートシーケンスを決定するためのパラメータ
・ ＰＲＡＣＨプリアンブルのシーケンスセットにおける循環シフト、又は
・ 論理ルートシーケンステーブルへのインデックス、規制されていない関連セットタイプ、規制されたタイプＡ又はタイプＢ

通常のＮＲ ＵＥについては、ＴＳ３８．３３１、ｖ１６．２．０に従って、ＰＲＡＣＨプリアンブルについての時間ドメイン位置は、ＲＲＣパラメータｐｒａｃｈ－ＣｏｎｆｉｇｕｒａｔｉｏｎＩｎｄｅｘによって決定され、ＰＲＡＣＨプリアンブルについての周波数ドメインリソースは、ＲＲＣパラメータｍｓｇ１－ＦＤＭ及びｍｓｇ１－ＦｒｅｑｕｅｎｃｙＳｔａｒｔによって決定される。

一実施形態では、早期の経路識別を使用するＲｅｄＣａｐ ＵＥ（例えば、１Ｒｘを有するＲｅｄＣａｐ ＵＥ、又は２Ｒｘを有するがＲＳＲＰ＜閾値を有するＲｅｄＣａｐ ＵＥ）は、通常のＵＥとは別個の（ＲＡＣＨ構成とも呼ばれる）ＰＲＡＣＨ構成の情報要素、例えば、ＲＡＣＨ－ＣｏｎｆｉｇＧｅｎｅｒｉｃ－ＲｅｄＣａｐの情報要素を有してよく、ここで、ＲＡＣＨ構成の情報要素は、サフィックスによって示されるように、ＲｅｄＣａｐランダムアクセスパラメータを指定する。この情報要素において、周波数及び時間リソースは、パラメータｐｒａｃｈ－ＣｏｎｆｉｇｕｒａｔｉｏｎＩｎｄｅｘ－ｒｅｄｃａｐ、ｍｓｇ１－ＦＤＭ－ｒｅｄｃａｐ、及びｍｓｇ１－ＦｒｅｑｕｅｎｃｙＳｔａｒｔ－ｒｅｄｃａｐによって示されうる。他の構成のネーミングは、ｖ１７及び／又は省略形ｒｃ（ＲｅｄＣａｐ）を含みうるし、前述の例に限定されない。ＲｅｄＣａｐ ＵＥ ＰＲＡＣＨ（又はＲＡＣＨ）構成は、時間、周波数位置に限定されず、リソースの周期性、サブキャリアオフセット、サブキャリアの数、プリアンブル送信及び電力ランピングステップの最大数、開始スロット数、スロットの数なども含みうる。従って、ＲｅｄＣａｐ ＵＥは、早期識別のために通常のＵＥとは別個の構成を受信しうるし、又はＲｅｄＣａｐ ＵＥは、通常のＵＥが行うように、識別のために後のステップを使用しうる。

別の実施形態では、同じＲＡＣＨ－ＣｏｎｆｉｇＧｅｎｅｒｉｃの情報要素は、後の段階で（Ｍｓｇ５を通して）識別するＲｅｄＣａｐ ＵＥと早期段階で（例えば、Ｍｓｇ１を通して）識別するＲｅｄＣａｐ ＵＥとの両方についてのＰＲＡＣＨ構成を含みうる。別の実施形態では、ＰＲＡＣＨリソースは、異なる段階で識別されるべきである異なるタイプのＲｅｄＣａｐ ＵＥについて重複しないことがあり、その場合、ＲｅｄＣａｐ ＵＥのインジケーションを構成するために定められた異なるタイプのＵＥについての情報要素が存在しうる。

別の実施形態では、ｇＮＢは、（カバレージ補償を必要としなくよい）２Ｒｘを有するＲｅｄＣａｐ ＵＥがレガシーＰＲＡＣＨ構成を使用しうるし、一方、１Ｒｘを有するＲｅｄＣａｐ ＵＥが異なるＰＲＡＣＨ構成を使用しうることを示しうる。さらに別の実施形態では、早期段階で識別されるべきであるＲｅｄＣａｐ ＵＥについてのリソースは、通常のＵＥのために構成されたリソースからのオフセットの観点で指定されうる。オフセットは、時間－周波数リソースオフセットの観点でありうる。別個の構成は、時間－周波数リソース位置構成に限定されず、異なるプリアンブルなど、ＲＡＣＨ手順に関連付けられている全ての他の構成を含みうることに留意されたい。

構成ＩＥの例示的な実施形態は、以下、表８に提供される。この例では、別個の一般的なＰＲＡＣＨリソースが、早期識別を実行するＲｅｄＣａｐ ＵＥのために（イタリック体で）構成される。ＲｅｄＣａｐ ＵＥは、通常のＵＥについてのＰＲＡＣＨ構成を使用せず、別個のＰＲＡＣＨ構成を使用する。

別の実施形態では、閾値は、ＲｅｄＣａｐ ＵＥが基準に基づいて（Ｃ３、Ｃ４、Ｃ５などの）閾値を使用して早期識別経路を使用する場合に定められる。一実施形態では、閾値は、ｒｓｒｐ－ＴｈｒｅｓｈｏｌｄｓＰｒａｃｈＩｎｆｏＬｉｓｔ－ｒ１７ ＩＥを使用して定義されうる。異なるカバレージレベルは、ＲＳＲＰに基づいて定められ、情報要素において定められうる。ＲＡＣＨ－ＣｏｎｆｉｇＧｅｎｅｒｉｃ ＩＥは、ｒｓｒｐ－ＴｈｒｅｓｈｏｌｄｓＰｒａｃｈＩｎｆｏＬｉｓｔ－ｒ１７ ＩＥを含むように強化されうる。別の実施形態では、ＲＡＣＨ－ＣｏｎｆｉｇＣｏｍｍｏｎ ＩＥは、ｒｓｒｐ－ＴｈｒｅｓｈｏｌｄｓＰｒａｃｈＩｎｆｏＬｉｓｔ－ｒ１７ ＩＥを含むように強化されうる。

別の実施形態では、ネットワークはまた、Ｍｓｇ１において識別されるべきであるＲｅｄＣａｐ ＵＥによって具体的に使用されることになるプリアンブルのセットも構成しうる。これらのプリアンブルは、通常のＵＥのために構成されたプリアンブルとは異なる特性を有しうる。異なっていることができる特性は、シーケンスのタイプ、循環シフトなどのうちの１つ又は複数を含みうる。

プリアンブルの異なるグループが、定められてよい。一実施形態では、プリアンブルの２つのグループが定められ、一方のグループは、閾値を使用して又は閾値を使用せずに、早期に識別されるＵＥのために構成され、他方のグループは、後で識別されるＵＥのために構成される。

ＰＲＡＣＨ構成を介してＲｅｄＣａｐ ＵＥ ＰＲＡＣＨリソースを識別したとき、ＵＥは、それに応じて、（ＰＲＡＣＨオケージョンにおける）ｇＮＢへＰＲＡＣＨプリアンブル（ランダムアクセスプリアンブル）を送信しうる。ｇＮＢは、ランダムアクセスプリアンブルが送信されるＲＡＣＨオケージョン（ＲＯ）に関係付けられたＲＡ－ＲＮＴＩを計算してよく、ＲＡ－ＲＮＴＩを計算するために使用されるパラメータは、ｐｒａｃｈ－ＣｏｎｆｉｇｕｒａｔｉｏｎＩｎｄｅｘ－ｒｅｄｃａｐ、ｍｓｇ１－ＦＤＭ－ｒｅｄｃａｐ、及びｍｓｇ１－ＦｒｅｑｕｅｎｃｙＳｔａｒｔ－ｒｅｄｃａｐによって示されるように、プリアンブルが送信される時間及び周波数リソースを含みうる。ＲｅｄＣａｐ ＵＥは、（例えば、アップリンクカバレージ拡張のために）プリアンブルが何度も送信されることを必要としうるので、許容される反復の最大数を含む構成が、例えばＳＩＢにおいて、ＲｅｄＣａｐ ＵＥのために構成されうる。数は、カバレージ拡張レベルに関連付けられうる。

（図２の参照において）ＲＡＣＨ処理の第２のステップにおいて、ＰＲＡＣＨプリアンブルの送信に続いて、ＵＥは、ｇＮＢからのランダムアクセス応答を待つ。ランダムアクセス応答（ＲＡＲ）は、ＲＡ－ＲＮＴＩ値でスクランブルされたＤＣＩを通して送られうる。ＵＥは、ｒａ－ＲｅｓｐｏｎｓｅＷｉｎｄｏｗの期間内に、対応するＲＡ－ＲＮＴＩを有するＰＤＣＣＨ（即ち、ＤＣＩ）を検出しようと試みうる。別の実施形態では、１Ｒｘを有するＲｅｄＣａｐ ＵＥ（又は２Ｒｘを有し、悪いチャネル利得条件（例えば、閾値よりも小さいＲＳＲＰ）を有するＲｅｄＣａｐ）は、ＤＣＩを監視するために、通常のＵＥとは別個の期間ｒａ－ＲｅｓｐｏｎｓｅＷｉｎｄｏｗ－ｒｅｄｃａｐを用いて構成されうる。

経路選択のための基準は、上記で説明したように、ＳＩＢにおいて受信された構成を使用して構成されうるが、基準は、技術仕様中に取り入れられてもよい。例えば、仕様は、非ＲｅｄＣａｐ ＵＥのための最小２つのＲｘブランチをサポートするある帯域中で動作する２つのＲｘブランチのＲｅｄＣａｐ ＵＥが、経路Ａを使用してそれ自体を識別することができ、１Ｒｘ ＲｅｄＣａｐ ＵＥが、経路Ｂを使用してそれ自体を識別することができると述べることができる。また、２Ｒｘ ＲｅｄＣａｐ ＵＥによる経路Ａの使用は、いくつかのＲＡＮ４性能要件が満たされるかに基づいてさらに決定されうる。一例として、とても小さいフォームファクタ及びアンテナ相関による乏しい受信性能を有する２ＲＸ ＵＥは、経路Ｂを使用しうる。

ＵＥがＭｓｇ１を使用して早期識別を実行する場合、いくつかの実施形態では、例として、４ステップのランダムアクセス手順における他のステップについて、以下のことが検討されうる。

いくつかの例では、Ｍｓｇ ２（又はＭｓｇ２）を受信するために、ＵＥは、関係付けられたＰＤＣＣＨのためのダウンリンクカバレージ拡張技法（又はダウンリンク性能を補償する技法）を使用して、（Ｍｓｇ２に関係付けられた）関係付けられたＰＤＣＣＨを受信しうる。以下のことが検討されうる。
・ 早期識別のための個別ＰＤＣＣＨが存在する場合

ｏ ＵＥは、１つ又は複数のカバレージ拡張技法によってＭｓｇ２を運ぶＰＤＳＣＨを受信することができ、これは、ＰＤＣＣＨ内のＤＣＩを介してシグナリングされうる
－ ダウンリンクカバレージ拡張技法は、例えば、ＴＢスケーリング、反復、及び／又はより低いＭＣＳレベルを含みうる
－ カバレージ拡張が適用されるとき、ＲＡＣＨ（例えば、Ｍｓｇ３送信）のためのタイミングが変化しうることに留意されたい
・ 早期識別のための個別ＰＤＣＣＨが存在しない場合
ｏ ＵＥは、ＳＩＢ構成によって提供される１つ又は複数のダウンリンクカバレージ拡張技法を使用してＰＤＳＣＨを受信することができる
－ ダウンリンクカバレージ拡張が適用されるとき、ＲＡＣＨのためのタイミングが変化しうることに留意されたい。

いくつかの例では、早期識別がＭｓｇ１において実行されるときにＭｓｇ ３（又はＭｓｇ３）を送信するために、いくつかのオプションは、以下のものを含みうる。
・ ＲＡＲ ＵＬ許可への変更はない、即ち、Ｍｓｇ３の送信のためにＲＡＲにおいて受信されたＵＬ許可を使用する
・ （例えば、ＴＢスケーリング、異なるＭＣＳレベル、及び／又は反復を使用することによって）ＲＡＲ ＵＬ許可を修正する
・ ＳＩＢ構成を使用してＲＡＲ ＵＬ許可を強化する（例えば、ＳＩＢ構成に基づくＭｓｇ３反復などのアップリンクカバレージ拡張を実行する）。

いくつかの例では、早期識別がＭｓｇ１において実行されるときにＭｓｇ ４（又はＭｓｇ４）を受信するために、基地局（例えば、ｇＮＢ）は、Ｍｓｇ４をスケジュール設定するためにＭｓｇ２ ＰＤＣＣＨを送るための技法を再使用しうる。基地局は、ＵＥをより良く理解しているため（ＵＥは、それをＭｓｇ１におけるＲｅｄＣａｐ ＵＥとして識別する）、Ｍｓｇ４のためのＰＤＣＣＨの送信のために構成されたパラメータを使用することができる。この時点で、基地局はＲＡ－ＲＮＴＩではなく、そのＵＥ個別の一時的なＲＮＴＩを使用しうることに留意されたい。一時的なＲＮＴＩがその特定のＵＥに個別であるので、ここで、シグナリングは「ほとんど」個別であり、ＰＤＳＣＨスケジューリングは、そのＵＥのためにより合わせられうる。

以下は、Ｍｓｇ３識別の実施形態を説明する（即ち、ＲｅｄＣａｐ ＵＥは、それを（ＲＡＣＨ処理中の）Ｍｓｇ３におけるＲｅｄＣａｐ－経路Ｂとして識別する）。上述されたように、Ｍｓｇ３は、ＲｅｄＣａｐ ＵＥの早期識別のために使用されてもよい。ＲｅｄＣａｐ ＵＥが通常のＵＥよりも悪い性能を有する場合、ＲｅｄＣａｐ ＵＥが存在する可能性により、ＵＥの全て（ＲｅｄＣａｐと通常の両方）を保守的に扱わなければならないのとは対照的に、この早期識別は、ＲｅｄＣａｐ ＵＥと通常のＵＥとが異なるように扱われることを可能にする。

一実施形態では、早期識別経路を通り抜けているＲｅｄＣａｐ ＵＥを識別するためにＭｓｇ３内の１つ又は複数のビットが使用されうる。ＮＲ ＲＡＣＨ処理では、ＲＡＣＨ－ＣｏｎｆｉｇＣｏｍｍｏｎは、ＲＡＣＨ－ＣｏｎｆｉｇＣｏｍｍｏｎにおける変換プリコーダなどのＭｓｇ３に関連したパラメータを構成するために使用される。一実施形態では、ＵＥをＲｅｄＣａｐ ＵＥとして明示的に識別するために、Ｍｓｇ３における１ビットが使用されうる。別の実施形態では、Ｍｓｇ３サイズがある閾値を超える場合、変換プリコーダフィールドなどのＭｓｇ３の別のフィールドのビットが、ＵＥをＲｅｄＣａｐ ＵＥとして識別するために使用されうる。以下、表９は、ｍｓｇ３－ｔｒａｎｓｆｏｒｍＰｒｅｃｏｄｅｒ（ｍｓｇ３－ｔｒａｎｓｆｏｒｍＰｒｅｃｏｄｅｒ、イタリック体）を含む例示的なＲＡＣＨ－ＣｏｎｆｉｇＣｏｍｍｏｎ ＩＥを示す。

一実施形態では、その機能がＲＡＣＨ－ＣｏｎｆｉｇＣｏｍｍｏｎ機能と同様であるが、ＲｅｄＣａｐ ＵＥのために構成された異なる値を有する別個の情報要素が、ＲｅｄＣａｐを構成する目的のために使用されうるし、早期段階で識別されるべきＲｅｄＣａｐ ＵＥのための構成情報を提供する。

ｇＮＢは、Ｍｓｇ３を受信し、従って、Ｍｓｇ３及び使用された構成に基づいてＲｅｄＣａｐ ＵＥを識別することができる。Ｍｓｇ３は、カバレージ回復技法を使用してＵＥによって送られうる。Ｍｓｇ３がカバレージ回復技法を用いて送信されるということを知ったとき、ｇＮＢは、Ｍｓｇ３を正確に検出することができ、Ｍｓｇ４を数回繰り返すこと及び／又はより低いＭＣＳ値若しくはＴＢスケーリングを使用することなど、ダウンリンクカバレージ回復技法を用いてＲｅｄＣａｐ ＵＥのためのＭｓｇ４をさらに送信することができる。
以下は、カバレージ拡張（ＣＥ）を説明する。

Ｍｓｇ３反復は、非ＲｅｄＣａｐ ＵＥについての任意選択の特徴である。従来から、Ｍｓｇ３反復は、非ＲｅｄＣａｐ ＵＥによってＭｓｇ３を送信するためのアップリンクカバレージ拡張を提供するために使用されうる。Ｍｓｇ３は、ＲＡＣＨ処理中にＵＥによって繰り返し（複数回）送信されうる。Ｍｓｇ３反復は、以下において「ＣＥ特徴」と呼ばれうる。ｇＮＢは、Ｍｓｇ３反復を実行するために非ＲｅｄＣａｐ ＵＥが使用しうるＲＡＣＨオケージョン（ＲＯ）及び／又はプリアンブルを構成しうる。一例では、非ＲｅｄＣａｐは、測定されたＲＳＲＰが閾値よりも小さい場合、カバレージ拡張のためにＭｓｇ３反復を実行しうる。

早期インジケーションは、ＲｅｄＣａｐ ＵＥのための必須の特徴／機能としてｇＮＢによって構成されうる。この場合、ＲｅｄＣａｐ ＵＥが、ＲＡＣＨ処理中、例えば、Ｍｓｇ１、Ｍｓｇ３、又はＭｓｇＡにおいて、早期段階（経路Ｂ）でＲｅｄＣａｐ ＵＥとしてそれ自体を識別することが必須である。非ＲｅｄＣａｐ ＵＬ ＢＷＰのサイズが、ＲｅｄＣａｐ ＵＥのＵＬ ＢＷＰのサイズ以上であるとき、ＲｅｄＣａｐ ＵＥのために早期インジケーションが使用又は構成されうる。この場合に、早期インジケーションを使用する主な理由は、ＲｅｄＣａｐ及び非ＲｅｄＣａｐ ＵＥ（ここで非ＲｅｄＣａｐ ＵＥは、ＲＡプロセス中により幅広いＢＷＰを使用しうる）の両方に対して、ＲＡ処理中により効率的なリソース割当て（又は有効なサイズのＢＷＰ）を提供するためである。

Ｍｓｇ３反復はまた、必要に応じて可能な小さな修正を伴って（ＷＩＤごとに）ＲｅｄＣａｐ ＵＥに利用可能であってもよい。特徴（Ｍｓｇ３反復）は、全てのＲｅｄＣａｐ ＵＥに有用でありそうであっても、ＲｅｄＣａｐ ＵＥにとって任意選択でありうる。Ｍｓｇ３反復を適用するために、ＵＥは、Ｍｓｇ１を送信するのに適切なＲＡＣＨリソースを使用する必要がありうる。一例では、Ｍｓｇ１は、ＵＥがＲｅｄＣａｐ ＵＥであることを示すために使用されうる（早期インジケーション）。Ｍｓｇ１は、このＣＥ特徴が適用される（又はＭｓｇ３反復が実行される）ことを示すために使用されてもよい。別の例では、Ｍｓｇ１が反復されてよく、Ｍｓｇ３がＲｅｄＣａｐの早期インジケーションのために使用されてもよい。

ｇＮＢは、それが全てのＵＥタイプ（非ＲｅｄＣａｐ ＵＥ及びＲｅｄＣａｐ ＵＥ）についてこのＣＥ特徴（Ｍｓｇ３反復）をサポートすることを望む場合、プリアンブル／ＲＯを４つのグループ／領域：（ＲｅｄＣａｐ、非ＲｅｄＣａｐ）×（Ｍｓｇ３反復、非Ｍｓｇ３反復）に分割する必要がありうる（以下の表１０を参照）。

上記の表１０において、ＲＡＣＨｉは、ｉ番目のＲＡＣＨ構成を表し、各ＲＡＣＨ構成は、１つ又は複数のプリアンブル、１つ又は複数のＲＯ、又はそれらの組合せを含みうる。グループ／領域の数は、ＲＡＣＨ構成の数である。各ＲＡＣＨ構成は、Ｍｓｇ１の送信のための構成を提供する。表１０によれば、４つのＲＡＣＨ構成が構成されてよく、即ち、ＲＡＣＨ１～ＲＡＣＨ４は、ＵＥの４つの異なる特徴の組合せ、即ち、ＲｅｄＣａｐ ＵＥと非Ｍｓｇ３反復、ＲｅｄＣａｐ ＵＥとＭｓｇ３反復、非ＲｅｄＣａｐ ＵＥと非Ｍｓｇ３反復、及び非ＲｅｄＣａｐ ＵＥとＭｓｇ３反復にそれぞれ対応する。

しかし、リソースの分割の仕方は、ＵＥに行うように要求するには多過ぎるものでありうるし、従って、どのＲＡＣＨ構成が使用されることになるのかをＵＥが決定するために、ルールが定められる必要がありうる。別の問題は、プリアンブル及びＲＡＣＨリソースの数が制限されることである。

第１の実施形態では、早期インジケーションがＲｅｄＣａｐ ＵＥのために構成されないとき、ＲｅｄＣａｐ ＵＥと非ＲｅｄＣａｐ ＵＥの両方が、閾値とともにＣＥ特徴で定められるＲＯ／プリアンブルを使用しうる。即ち、閾値が満たされる（例えば、ＲＳＲＰ＜閾値）とき、ＲｅｄＣａｐ ＵＥと非ＲｅｄＣａｐ ＵＥの両方が、定められたＲＯ／プリアンブルを使用してＭｓｇ３カバレージ拡張を実行しうる。同じ閾値が、ＲｅｄＣａｐ ＵＥ及び非ＲｅｄＣａｐ ＵＥのために使用されてよく、又は別個の閾値が、ＲｅｄＣａｐ ＵＥのために使用されてよい（例えば、複雑さを減少させる特徴を説明するために必要とされる場合）。一例として、ＵＥ（ＲｅｄＣａｐ又は非ＲｅｄＣａｐのいずれか）は、ＲＳＲＰ測定が閾値よりも小さいときにＭｓｇ３反復を実行しうる。別の例として、閾値１は、非ＲｅｄＣａｐ ＵＥのために構成され、閾値２は、ＲｅｄＣａｐ ＵＥのために構成される。この場合、非ＲｅｄＣａｐ ＵＥは、ＲＳＲＰ測定が閾値１よりも小さいときにＭｓｇ３反復を実行してよく、ＲｅｄＣａｐ ＵＥは、ＲＳＲＰ測定が閾値２よりも小さいときにＭｓｇ３反復を実行してよい。以下の表１１は、第１の実施形態のＲＡＣＨ構成を示す。図示されるように、２つのカテゴリ、即ち、ＵＥと非Ｍｓｇ３反復、及びＵＥとＭｓｇ３反復に対応して２つのＲＡＣＨ構成、ＲＡＣＨ１、及びＲＡＣＨ２が必要とされる。ＵＥのＲＳＲＰ測定が閾値よりも大きいとき、ＵＥは、Ｍｓｇ３反復を実行することなくＲＡＣＨ１に従ってＭｓｇ１を送信する。ＵＥのＲＳＲＰ測定が閾値よりも小さいとき、ＵＥは、ＲＡＣＨ２に従ってＭｓｇ１を送信し、Ｍｓｇ３反復を実行する。

いくつかの実施形態では、ある特性を有するＲｅｄＣａｐ ＵＥ（例えば、非ＲｅｄＣａｐ ＵＥのために４つのＲｘブランチを必要とする帯域内に１つのＲｘブランチ（又は２つのＲｘブランチ）を有するＲｅｄＣａｐ ＵＥ）は、非反復領域（例えば、２つのＲＸを有するＲｅｄＣａｐ ＵＥ）（即ち、表１１中のＲＡＣＨ１）に割り当てられてよく、又は反復領域（例えば、１つのＲｘブランチを有するＲｅｄＣａｐ ＵＥ）（即ち、表１１中のＲＡＣＨ２）に割り当てられてよい。

ＵＥ特徴と閾値との組合せも使用されうる。例えば、２つのＲｘブランチ及び閾値よりも高いＲＳＲＰを有するＲｅｄＣａｐ ＵＥと非ＲｅｄＣａｐ ＵＥとは、通常のＲＯ（即ち、ＲＡＣＨ１）を使用しうるし、又は１つのＲｘブランチ及び閾値よりも低いＲＳＲＰを有するＲｅｄＣａｐ ＵＥは、ＣＥ ＲＯ（即ち、表１１中のＲＡＣＨ２）を使用しうる。（Ｍｓｇ３のための）反復領域（即ち、表１１中のＲＡＣＨ２）の使用は、ＵＥによるＣＥ特徴のサポートを必要とする。

このＣＥ特徴（Ｍｓｇ３反復）がＲｅｄＣａｐ ＵＥに必須である場合、それは、一意にそうしないことによって、早期インジケーションの形態に類似するように思われうることに留意されたい。例えば、Ｍｓｇ３反復がＲｅｄＣａｐ ＵＥに必須である場合、ネットワークは、ＲｅｄＣａｐ ＵＥがＭｓｇ３反復をサポートすることを知っており、ＲｅｄＣａｐ ＵＥは、（例えば、表１０及び１１に示されるように、条件が満たされる場合）Ｍｓｇ３反復を使用することができることを知っている。さらに、Ｍｓｇ３に使用される反復の数は、ＲｅｄＣａｐ ＵＥと非ＲｅｄＣａｐ ＵＥとを区別するためにネットワークによって使用されうる。ＣＥを示すＭｓｇ１リソースは、ＲｅｄＣａｐ又は非ＲｅｄＣａｐ ＵＥのいずれかによって要求されうる。反復の数がＲｅｄＣａｐ ＵＥに対して及び非ＲｅｄＣａｐ ＵＥにも対して一意である場合、基地局は、受信されたＭｓｇ３の反復の数をカウントして、メッセージがＲｅｄＣａｐ ＵＥからであるか、非ＲｅｄＣａｐ ＵＥからであるかを識別しうる。反復の数が一意でない場合、基地局は、反復の数を使用して、ＲｅｄＣａｐ ＵＥと非ＲｅｄＣａｐ ＵＥとを区別することができない。一例として、非ＲｅｄＣａｐ ＵＥは｛１，２｝反復を使用することができ、一方、ＲｅｄＣａｐ ＵＥは｛４｝反復を使用し、早期インジケーションの形態を提供することが可能である。表記｛ｘ｝は、Ｍｓｇ３の反復の許容された数である。非ＲｅｄＣａｐ ＵＥとＲｅｄＣａｐ ＵＥとの間の反復の数に共通の値がある場合、例えば、｛１，２｝が非ＲｅｄＣａｐ ＵＥに対して構成され、｛２，４｝がＲｅｄＣａｐ ＵＥに対して構成される場合、２つのＭｓｇ３反復が基地局において受信されるとき、ＵＥタイプを区別することが可能でないことがある。即ち、基地局は、２つのＭｓｇ３反復がＲｅｄＣａｐ ＵＥによって送られたのか、又は非ＲｅｄＣａｐ ＵＥによって送られたのかを知らないことがある。構成されたＲｅｄＣａｐ ＵＥについて別個のＵＬ ＢＷＰが存在しなくてもよい。例えば、ＵＥの両方のタイプ（ＲｅｄＣａｐ及び非ＲｅｄＣａｐ）は、ＲｅｄＣａｐ ＵＥのためのＵＬ ＢＷＰ、例えば、帯域幅、ロケーションの制約の下で、同じＵＬ ＢＷＰを共有する。

第２の実施形態では、早期インジケーションとＭｓｇ３反復の特徴との両方が、ＲｅｄＣａｐ ＵＥのために構成されてよく、非ＲｅｄＣａｐ ＵＥ及びＲｅｄＣａｐ ＵＥは、Ｍｓｇ３反復のために同じ領域（同じＲＡＣＨ構成）を使用する（従って、この例では、３つの領域（ＲＡＣＨ１～３）がある）。以下、表１２は、第２の実施形態のＲＡＣＨ構成を示す。Ｍｓｇ３反復が使用されるとき、非ＲｅｄＣａｐ ＵＥとＲｅｄＣａｐ ＵＥとの両方が、ＲＡＣＨ２に従ってＭｓｇ１を送信する。Ｍｓｇ３反復が使用されないとき、ＲｅｄＣａｐ ＵＥは、ＲＡＣＨ１に従ってＭｓｇ１を送信し、非ＲｅｄＣａｐ ＵＥは、ＲＡＣＨ３に従ってＭｓｇ３を送信する。

この例では、非ＲｅｄＣａｐ ＵＥは、それが早期インジケーションの一意性を弱めるが、ＲｅｄＣａｐ ＵＥ及び非ＲｅｄＣａｐ ＵＥが「同じＲＡＣＨ構成」（例えば、ＲＳＲＰが閾値よりも小さいので乏しいチャネル状態）を使用するので、ＲｅｄＣａｐ ＵＬ ＢＷＰと同じＵＬ ＢＷＰにおいてＭｓｇ３反復を送信しうる。非ＲｅｄＣａｐ ＵＥは、まだＭｓｇ３を効率的に送信しうる。上述された第１の実施形態と同様に、Ｍｓｇ３反復を実行するかを決定するために使用される閾値は、ＲｅｄＣａｐ ＵＥと非ＲｅｄＣａｐ ＵＥとについて異なるものであることができる。異なる特徴のＲｅｄＣａｐ ＵＥを区別するために反復の数を使用する（例えば、１つのＲｘブランチを有するＲｅｄＣａｐ ＵＥは、常に反復を使用する）ことは、その場合には、実施形態２が実施形態１に単純化するので、可能でない。この実施形態に関する１つの制限は、同じＲＡＣＨ構成（ＲＡＣＨ２）がＲｅｄＣａｐ及び非ＲｅｄＣａｐ ＵＥによって使用されるので、ＲｅｄＣａｐ及び非ＲｅｄＣａｐ ＵＥが、初期アクセス中に同じ初期ＵＬ ＢＷＰを共有することである。従って、反復を伴うＲｅｄＣａｐ ＵＥ及び非ＲｅｄＣａｐ ＵＥのために別個のＢＷＰが存在しないことがある。

第３の実施形態では、早期インジケーションとＭｓｇ３反復のＣＥ特徴との両方が、ＲｅｄＣａｐ ＵＥのために構成されてよく、非ＲｅｄＣａｐ及びＲｅｄＣａｐ ＵＥは、Ｍｓｇ３反復が実行されないときに同じ非反復領域（ＲＡＣＨ構成）を使用するが、反復のために異なる領域（異なるＲＡＣＨ構成）を使用する（従って、この例については合計３つの領域がある）。下記、表１２は、第３実施形態によるＲＡＣＨ構成を示す。Ｍｓｇ３反復が使用されないとき、非ＲｅｄＣａｐ ＵＥとＲｅｄＣａｐ ＵＥとの両方が、ＲＡＣＨ１に従ってＭｓｇ１を送信する。Ｍｓｇ３反復が使用されるとき、ＲｅｄＣａｐ ＵＥは、ＲＡＣＨ２に従ってＭｓｇ１を送信し、非ＲｅｄＣａｐ ＵＥは、ＲＡＣＨ４に従ってＭｓｇ１を送信する。

第３の実施形態は、あまり魅力的ではないことがあり、例えば、良好な状態にある（例えば、ＲＳＲＰが閾値よりも大きく、従ってＭｓｇ３反復が使用されない）非ＲｅｄＣａｐ ＵＥは、ＲｅｄＣａｐ ＢＷの規制（同じＲＡＣＨ１）に従わなければならない。また、ＲｅｄＣａｐ ＵＥがＭｓｇ３反復のこのＣＥ特徴をサポートしない場合、閾値に対してのその条件又はサポートされる特徴にかかわらず、それは「同じＲＡＣＨ構成」に従って非ＲｅｄＣａｐ ＵＥとして同様に扱われる。第１の実施形態で説明したものと同じ実施形態、例えば閾値が適用されてもよい。潜在的に、この解決策は、早期インジケーションがＲｅｄＣａｐ ＵＥによって実行されうるので、ＲｅｄＣａｐ ＵＥ及び非ＲｅｄＣａｐ ＵＥについて異なる数の反復（サポートされた１、２、４の反復、及び場合によっては８の反復）を可能にしうる。これは、ＲｅｄＣａｐ ＵＥがより少ないブランチを有するので合理的であり、ＲｅｄＣａｐ ＵＥに許容される反復の数は、非ＲｅｄＣａｐ ＵＥに構成される反復の数よりも大きくなりうる。これは、ＣＥのための別個のＢＷＰが、初期アクセス中のＭｓｇ３送信のためのＲｅｄＣａｐ及び非ＲｅｄＣａｐ ＵＥのために使用される場合、より魅力的であるとやはりみなされうる。

第４の実施形態では、ＲｅｄＣａｐ ＵＥのみが、ＣＥ特徴を使用することが許可されうる（従って、２つ又は３つの領域が存在しうる）。第４の実施形態は、（ＲｅｄＣａｐ ＵＥのために構成された）早期インジケーションがオンであり、ａ）ＣＥ特徴がＲｅｄＣａｐ ＵＥのために単にシグナリングされ、又はｂ）ＣＥのための閾値が、ＣＥ特徴が非ＲｅｄＣａｐ ＵＥのためにターンオフされ、非ＲｅｄＣａｐ ＵＥとは別個のＲｅｄＣａｐ ＵＥのためのＲｅｄＣａｐの閾値があるような値に設定される場合、３つの領域を有する第２の実施形態と同様でありうる。以下、表１４は、第４の実施形態によるＲＡＣＨ構成を示し、Ｍｓｇ３反復は、適切な閾値の値を用いて、非ＲｅｄＣａｐ ＵＥに対して一般にターンオフされる。Ｍｓｇ３反復が使用されないとき、ＲｅｄＣａｐ ＵＥは、ＲＡＣＨ１に従ってＭｓｇ１を送信し、非ＲｅｄＣａｐ ＵＥは、ＲＡＣＨ３に従ってＭｓｇ１を送信する。Ｍｓｇ３反復が使用されるとき、ＲｅｄＣａｐ ＵＥは、ＲＡＣＨ２に従ってＭｓｇ１を送信する。非ＲｅｄＣａｐ ＵＥは、Ｍｓｇ３反復が非ＲｅｄＣａｐ ＵＥによって実行されず、非ＲｅｄＣａｐ ＵＥがＲＡＣＨ３に従ってＭｓｇ１を送信するように、とても低い閾値で構成されうる。ＲｅｄＣａｐ ＵＥは、非ＲｅｄＣａｐ ＵＥのために構成された閾値とは異なる（Ｍｓｇ３反復を実行するための）閾値で構成される。３つの領域が構成されると、ＲｅｄＣａｐ ＵＥのために別個のＢＷＰを使用することに伴う問題はない（早期インジケーションがサポートされる）。非ＲｅｄＣａｐ ＵＥは、ＣＥを使用しない（又は、ネットワークが、非ＲｅｄＣａｐ ＵＥについてＣＥをサポートしないことを判断する）。

ＲｅｄＣａｐ ＵＥのために構成された早期インジケーションがない場合、２つの領域（ＲＡＣＨ構成）がある。この例は、ａ）ＣＥ特徴がＲｅｄＣａｐ ＵＥに対してシグナリングのみされる場合、又はｂ）ＣＥのための閾値が、ＣＥ特徴が非ＲｅｄＣａｐ ＵＥに対してターンオフされ、非ＲｅｄＣａｐ ＵＥとは別個のＲｅｄＣａｐの閾値が存在するような値に設定される場合、第１の実施形態と同様でありうる。この例は、以下、表１５に示される。Ｍｓｇ３反復が使用されないとき、ＲｅｄＣａｐ ＵＥ及びｎｏｎ－ＲｅｄＣａｐ ＵＥは、ＲＡＣＨ１に従ってＭｓｇ１を送信する。Ｍｓｇ３反復が使用されるとき、ＲｅｄＣａｐ ＵＥは、ＲＡＣＨ２に従ってＭｓｇ１を送信する。非ＲｅｄＣａｐ ＵＥは、とても低い閾値で構成されうるし、Ｍｓｇ３反復が非ＲｅｄＣａｐ ＵＥによって実行されず、結果として、非ＲｅｄＣａｐ ＵＥがＲＡＣＨ１に従ってＭｓｇ１を送信するようになっている。ＲｅｄＣａｐ ＵＥは、非ＲｅｄＣａｐ ＵＥのために構成された閾値とは異なる（Ｍｓｇ３反復を実行するための）閾値を用いて構成される。

図９は、ＲｅｄＣａｐ ＵＥインジケーションのための一実施形態の方法９００の流れ図である。方法９００は、ＵＥの動作を示しうる。ＵＥは、基準に基づいて、ＵＥのランダムアクセス（ＲＡ）手順中に、又はＲＡ手順の後に、それが機能削減（ＲｅｄＣａｐ）ＵＥであることをｇＮＢへ示すかを決定しうる（ブロック９０２）。ＲｅｄＣａｐ ＵＥは、非ＲｅｄＣａｐ ＵＥの受信ブランチの最小数よりも少ない受信ブランチの数量を有する、又は非ＲｅｄＣａｐ ＵＥの最小帯域幅よりも小さい帯域幅を有する。ＵＥは、決定結果に従って、それがＲｅｄＣａｐ ＵＥであることをｇＮＢへ示しうる（ブロック９０４）。非ＲｅｄＣａｐ ＵＥは、レガシーＵＥでありうる。

図１０は、ＲｅｄＣａｐ ＵＥ検出のための別の実施形態の方法１０００の流れ図である。方法１０００は、ｇＮＢの動作を示しうる。ｇＮＢは、ランダムアクセス（ＲＡ）手順中にＵＥから第１のメッセージを受信しうる（ブロック１００２）。ｇＮＢは、ＵＥが機能削減（ＲｅｄＣａｐ）ＵＥであることを第１のメッセージが示すかを決定しうる（ブロック１００４）。ＲｅｄＣａｐ ＵＥは、非ＲｅｄＣａｐ ＵＥの受信ブランチの最小数よりも少ない受信ブランチの数量を有する、又は非ＲｅｄＣａｐ ＵＥの最小帯域幅よりも小さい帯域幅を有する。ＵＥがＲｅｄＣａｐ ＵＥであることを第１のメッセージが示すとき、ｇＮＢは、カバレージ回復技法に従って、ＲＡ手順中にＵＥに第２のメッセージを送りうる（ブロック１００６）。ＵＥがＲｅｄＣａｐ ＵＥであることを第１のメッセージが示さないとき、ｇＮＢは、ＲＡ手順が完了した後に、ＵＥがＲｅｄＣａｐ ＵＥであるかを決定しうる（ブロック１００８）。

図１１は、ホストデバイスにインストールされうる、本明細書で説明される方法を実行するための一実施形態の処理システム１１００のブロック図を示す。図示されるように、処理システム１１００は、プロセッサ１１０４と、メモリ１１０６と、インターフェース１１１０～１１１４とを含み、これらは、図１１に示されるように配置されうる（又は配置されなくてよい）。プロセッサ１１０４は、計算及び／又は他の処理に関連付けられたタスクを実行するように適合された任意の構成要素又は構成要素の集合でありうるし、メモリ１１０６は、プロセッサ１１０４による実行のためにプログラミング及び／又は命令を記憶するように適合された任意の構成要素又は構成要素の集合でありうる。一実施形態では、メモリ１１０６は、非一時的なコンピュータ可読媒体を含む。インターフェース１１１０、１１１２、１１１４は、処理システム１１００が他のデバイス／構成要素、及び／又はユーザと通信することを可能にする任意の構成要素又は構成要素の集合でありうる。例えば、インターフェース１１１０、１１１２、１１１４のうちの１つ又は複数は、プロセッサ１１０４からホストデバイス及び／又はリモートデバイス上にインストールされたアプリケーションにデータ、制御、又は管理メッセージを通信するように適合されうる。別の例として、インターフェース１１１０、１１１２、１１１４のうちの１つ又は複数は、ユーザ又はユーザデバイス（例えば、パーソナルコンピュータ（ＰＣ）など）が処理システム１１００とインタラクト／通信することを可能にするように適合されうる。処理システム１１００は、長期記憶装置（例えば、不揮発性メモリ等）などの図１１に示されていない追加の構成要素を含みうる。

いくつかの実施形態では、処理システム１１００は、電気通信ネットワークにアクセスしている、又はさもなければ電気通信ネットワークの一部であるネットワークデバイスに含まれる。一例では、処理システム１１００は、基地局、中継局、スケジューラ、コントローラ、ゲートウェイ、ルータ、アプリケーションサーバ、又は電気通信ネットワーク内の任意の他のデバイスなどのワイヤレス又は有線の電気通信ネットワーク内のネットワーク側のデバイス内にある。他の実施形態では、処理システム１１００は、移動局、ユーザ機器（ＵＥ）、パーソナルコンピュータ（ＰＣ）、タブレット、ウェアラブル通信デバイス（例えば、スマートウォッチ等）、又は電気通信ネットワークにアクセスするように適合された任意の他のデバイスなどのワイヤレス又は有線の電気通信ネットワークにアクセスするユーザ側のデバイス内にある。

いくつかの実施形態では、インターフェース１１１０、１１１２、１１１４のうちの１つ又は複数は、処理システム１１００を、電気通信ネットワークを介してシグナリングを送信及び受信するように適合された送受信機に接続する。図１２は、電気通信ネットワークを介してシグナリングを送信及び受信するように適合された送受信機１２００のブロック図を示す。送受信機１２００は、ホストデバイスにインストールされうる。図示されるように、送受信機１２００は、ネットワーク側のインターフェース１２０２と、カプラ１２０４と、送信機１２０６と、受信機１２０８と、信号プロセッサ１２１０と、デバイス側のインターフェース１２１２とを備える。ネットワーク側のインターフェース１２０２は、ワイヤレス又は有線の電気通信ネットワークを介してシグナリングを送信又は受信するように適合された任意の構成要素又は構成要素の集合を含みうる。カプラ１２０４は、ネットワーク側のインターフェース１２０２を介した双方向通信を助けるように適合された任意の構成要素又は構成要素の集合を含みうる。送信機１２０６は、ベースバンド信号を、ネットワーク側のインターフェース１２０２を介した送信に適した変調されたキャリア信号に変換するように適合された任意の構成要素又は構成要素の集合（例えば、アップコンバータ、電力増幅器等）を含みうる。受信機１２０８は、ネットワーク側のインターフェース１２０２を介して受信されたキャリア信号をベースバンド信号に変換するように適合された任意の構成要素又は構成要素の集合（例えば、ダウンコンバータ、低雑音増幅器等）を含みうる。信号プロセッサ１２１０は、ベースバンド信号をデバイス側のインターフェース１２１２を介した通信に適したデータ信号に変換するように、又はその逆に変換するように適合された任意の構成要素又は構成要素の集合を含みうる。デバイス側のインターフェース１２１２は、信号プロセッサ１２１０とホストデバイス内の構成要素（例えば、処理システム１１００、ローカルエリアネットワーク（ＬＡＮ）ポート等）との間でデータ信号を通信するように適合された任意の構成要素又は構成要素の集合を含みうる。

送受信機１２００は、任意のタイプの通信媒体を介してシグナリングを送信及び受信しうる。いくつかの実施形態では、送受信機１２００は、ワイヤレス媒体を介してシグナリングを送信及び受信する。例えば、送受信機１２００は、セルラープロトコル（例えば、ロングタームエボリューション（ＬＴＥ）等）、ワイヤレスローカルエリアネットワーク（ＷＬＡＮ）プロトコル（例えば、Ｗｉ－Ｆｉ等）、又は任意の他のタイプのワイヤレスプロトコル（例えば、Ｂｌｕｅｔｏｏｔｈ、近距離無線通信（ＮＦＣ）等）などのワイヤレスの電気通信プロトコルに従って通信するように適合されたワイヤレス送受信機でありうる。そのような実施形態では、ネットワーク側のインターフェース１２０２は、１つ又は複数のアンテナ／放射要素を備える。例えば、ネットワーク側のインターフェース１２０２は、単一アンテナ、複数の別個のアンテナ、又は、多層通信、例えば、単一入力多出力（ＳＩＭＯ）、多入力単一出力（ＭＩＳＯ）、多入力多出力（ＭＩＭＯ）等のために構成されたマルチアンテナアレイを含みうる。他の実施形態では、送受信機１２００は、有線媒体、例えば、ツイストペアケーブル、同軸ケーブル、光ファイバ等を介してシグナリングを送信及び受信する。特定の処理システム及び／又は送受信機は、図示された構成要素の全て、又は構成要素のサブセットのみを利用してもよく、統合のレベルはデバイスごとに変わりうる。

図１３は、本明細書で開示されたデバイス及び方法を実装するために使用されうるコンピューティング及び通信環境１３００内に示される電子デバイス（ＥＤ）１３５２のブロック図である。ＥＤの例は、ＵＥ、タブレット、ＩｏＴデバイス、コンピュータ、又はワイヤレス通信機能を有する他のデバイスを含む。

いくつかの実施形態では、電子デバイスは、基地局（例えば、ＮｏｄｅＢ、ｅｖｏｌｖｅｄ ＮｏｄｅＢ（ｅＮｏｄｅＢ、又はｅＮＢ）、次世代ＮｏｄｅＢ（ｇＮｏｄｅＢ又はｇＮＢと呼ばれる場合もある）、ホーム加入者サーバ（ＨＳＳ）、パケットゲートウェイ（ＰＧＷ）若しくはサービングゲートウェイ（ＳＧＷ）などのゲートウェイ（ＧＷ）、又はコアネットワーク（ＣＮ）若しくはパブリックランドモビリティネットワーク（ＰＬＭＮ）内の様々な他のノード若しくは機能などの通信ネットワークインフラストラクチャの要素でありうる。他の実施形態では、電子デバイスは、モバイルフォン、スマートフォン、又はユーザ機器（ＵＥ）として分類されうる他のそのようなデバイスなど、無線インターフェースを介してネットワークインフラストラクチャに接続するデバイスでありうる。いくつかの実施形態では、ＥＤ１３５２は、（マシンツーマシン（ｍ２ｍ）デバイスとも呼ばれる）マシンタイプ通信（ＭＴＣ）デバイス、又はユーザに直接サービスを提供しないにもかかわらずＵＥとして分類されうる別のそのようなデバイスでありうる。いくつかの参考文献では、ＥＤは、モバイルデバイスとも呼ばれることがあり、用語は、デバイス自体がモビリティのために設計されているか、又はモビリティが可能であるかにかかわらず、モバイルネットワークに接続するデバイスを反映することが意図される。特定のデバイスは、示される構成要素の全て、又は構成要素のサブセットのみを利用してよく、統合のレベルは、デバイスごとに変わりうる。さらに、デバイスは、複数のプロセッサ、メモリ、送信機、受信機等など、構成要素の複数のインスタンスを含んでよい。ＥＤ１３５２は、典的には、中央処理装置（ＣＰＵ）などのプロセッサ１３５４を含み、グラフィックス処理装置（ＧＰＵ）又は他のそのようなプロセッサなどの特化されたプロセッサ、メモリ１３５６、ネットワークインターフェース１３５８、及びＥＤ１３５２の構成要素を接続するためのバス１３６０をさらに含みうる。ＥＤ１３５２は、任意選択で、（破線で示された）大容量記憶装置１３６２、ビデオアダプタ１３６４、及びＩ／Ｏインターフェース１３６８などの構成要素を含んでもよい。

メモリ１３５６は、スタティックランダムアクセスメモリ（ＳＲＡＭ）、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）、シンクロナスＤＲＡＭ（ＳＤＲＡＭ）、読取り専用メモリ（ＲＯＭ）、又はそれらの組合せなどのプロセッサ１３５４によって読取り可能な任意のタイプの非一時的なシステムメモリを備えうる。一実施形態では、メモリ１３５６は、ブートアップ時に使用するためのＲＯＭ、ならびにプログラムを実行している間に使用するためのプログラム及びデータを記憶するためのＤＲＡＭなど、２つ以上のタイプのメモリを含んでよい。バス１３６０は、メモリバス若しくはメモリコントローラ、周辺バス、又はビデオバスを含む、任意のタイプのいくつかのバスアーキテクチャのうちの１つ又は複数でありうる。

電子デバイス１３５２は、有線ネットワークインターフェース及びワイヤレスネットワークインターフェースのうちの少なくとも１つを含みうる１つ又は複数のネットワークインターフェース１３５８を含んでもよい。図１３に示されるように、ネットワークインターフェース１３５８は、ネットワーク１３７４に接続するための有線ネットワークインターフェースを含んでよく、無線リンクを介して他のデバイスに接続するために無線アクセスネットワークインターフェース１３７２を含んでもよい。ＥＤ１３５２がネットワークインフラストラクチャ要素であるとき、無線アクセスネットワークインターフェース１３７２は、無線エッジにあるもの（例えば、ｅＮＢ）以外のＰＬＭＮの要素として働くノード又は機能については省略されうる。ＥＤ１３５２がネットワークの無線エッジにおけるインフラストラクチャであるとき、有線ネットワークインターフェースとワイヤレスネットワークインターフェースとの両方が含まれうる。ＥＤ１３５２がユーザ機器などのワイヤレス接続されたデバイスであるとき、無線アクセスネットワークインターフェース１３７２が存在してもよく、それは、ＷｉＦｉネットワークインターフェースなどの他のワイヤレスインターフェースによって補足されてよい。ネットワークインターフェース１３５８は、ＥＤ１３５２が、ネットワーク１３７４に接続されたものなどのリモートエンティティと通信することを可能にする。

大容量記憶装置１３６２は、データ、プログラム、及び他の情報を記憶し、データ、プログラム、及び他の情報にバス１３６０を介してアクセス可能にさせるように構成された任意のタイプの非一時的な記憶デバイスを含みうる。大容量記憶装置１３６２は、例えば、ソリッドステートドライブ、ハードディスクドライブ、磁気ディスクドライブ、又は光ディスクドライブのうちの１つ又は複数を備えうる。いくつかの実施形態では、大容量記憶装置１３６２は、電子デバイス１３５２に対して遠隔にあってよく、インターフェース１３５８などのネットワークインターフェースを使用することによってアクセス可能でありうる。示された実施形態では、大容量記憶装置１３６２は、メモリ１３５６とは別個であり、そこにはそれが含まれ、一般に、より高いレイテンシに適合する記憶タスクを実行しうるが、一般に、より少ない揮発性を提供してもよいし、又は全く揮発性を提供しなくてもよい。いくつかの実施形態では、大容量記憶装置１３６２は、異種のメモリ１３５６と統合されてよい。

（破線で示された）任意選択のビデオアダプタ１３６４及びＩ／Ｏインターフェース１３６８は、電子デバイス１３５２を外部の入力デバイス及び出力デバイスに結合するためのインターフェースを提供する。入力デバイス及び出力デバイスの例は、ビデオアダプタ１３６４に結合されたディスプレイ１３６６、Ｉ／Ｏインターフェース１３６８に結合されたタッチスクリーンなどのＩ／Ｏデバイス１３７０を含む。他のデバイスがＥＤ１３５２に結合されてよく、追加の又はより少ないインターフェースが利用されてよい。例えば、ユニバーサルシリアルバス（ＵＳＢ）（図示せず）などのシリアルインターフェースを使用して、外部デバイスのためのインターフェースを提供してよい。当業者は、ＥＤ１３５２がデータセンタの一部である実施形態において、Ｉ／Ｏインターフェース１３６８及びビデオアダプタ１３６４が仮想化され、ネットワークインターフェース１３５８を介して提供されてよいことを理解するであろう。

いくつかの実施形態では、ＥＤ１３５２は、独立デバイスであってもよく、一方、他の実施形態では、電子デバイス１３５２は、データセンタ内に常駐してよい。データセンタは、当業界で理解されるように、集合的コンピューティング及び記憶リソースとして使用されることができる（典的にはサーバの形態の）コンピューティングリソースの集合である。データセンタ内では、複数のサーバが互いに接続されることができ、それにより、仮想化されたエンティティがインスタンス化されることができるコンピューティングリソースプールを提供する。データセンタは、互いに相互接続されて、接続性リソースによってそれぞれに接続されるプールコンピューティング及び記憶リソースからなるネットワークを形成することができる。接続性リソースは、イーサネット又は光通信リンクなどの物理接続の形態をとってよく、場合によっては、ワイヤレス通信チャネルも含みうる。２つの異なるデータセンタが複数の異なる通信チャネルによって接続される場合、リンクアグリゲーショングループ（ＬＡＧ）の形成を含むいくつかの技法のいずれかを使用して、リンクは一緒に組み合わされることができる。（ネットワーク内の他のリソースとともに）コンピューティングリソース、記憶リソース、及び接続性リソースのいずれか又は全てが、場合によってはリソーススライスの形態で、異なるサブネットワーク間で分割されることができることを理解されたい。いくつかの接続されたデータセンタ又は他のノードの集合にわたってのリソースがスライスされる場合、異なるネットワークスライスが生成されることができる。

本明細書で提供される実施形態の方法の１つ又は複数のステップは、対応するユニット又はモジュールによって実行されうることを理解されたい。例えば、信号は、送信ユニット又は送信モジュールによって送信されうる。信号は、受信ユニット又は受信モジュールによって受信されうる。信号は、処理ユニット又は処理モジュールによって処理されうる。他のステップは、決定ユニット／モジュール、ＲｅｄＣａｐ ＵＥを示す又は識別するユニット／モジュール、比較ユニット／モジュール、測定ユニット／モジュール、機能の交換ユニット／モジュール、ＲＡＣＨ構成ユニット／モジュール、ブロードキャストカバレージ回復、ＲＡＣＨ実行ユニット／モジュール、受信カバレージ回復ユニット／モジュール、及び／又はカバレージ回復ユニット／モジュールによって実行されうる。それぞれのユニット／モジュールは、ハードウェア、ソフトウェア、又はそれらの組合せであってよい。例えば、ユニット／モジュールのうちの１つ又は複数は、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、又は特定用途向け集積回路（ＡＳＩＣ）などの集積回路でありうる。
以下の参考文献は、本開示の主題に関連しており、全体として参照により本明細書に組み込まれる。

・ Ｅｒｉｃｓｓｏｎ，「Ｒｅｖｉｓｅｄ ＳＩＤ ｏｎ Ｓｔｕｄｙ ｏｎ Ｓｕｐｐｏｒｔ ｏｆ Ｒｅｄｕｃｅｄ Ｃａｐａｂｉｌｉｔｙ ＮＲ Ｄｅｖｉｃｅｓ」，ｄｏｃｕｍｅｎｔ ＲＰ－２０１６７７，３ＧＰＰ，Ｊｕｌ．２０２０；

・ ＴＲ３８．８７５，ｖ０．１．０「Ｓｔｕｄｙ ｏｎ Ｓｕｐｐｏｒｔ ｏｆ Ｒｅｄｕｃｅｄ Ｃａｐａｂｉｌｉｔｙ ＮＲ Ｄｅｖｉｃｅｓ」（Ｒｅｌｅａｓｅ １７），２０２０－１１－２５；
・ ＴＳ３６．３００，ｖ１６．３．０，「Ｅ－ＵＴＲＡ Ｅ－ＵＴＲＡＮ Ｏｖｅｒａｌｌ Ｄｅｓｃｒｉｐｔｉｏｎ Ｓｔａｇｅ－２」；

・ ＴＳ３８．３３１，ｖ１６．２．０，「Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ ＲＲＣ ｐｒｏｔｏｃｏｌ ｓｐｅｃｉｆｉｃａｔｉｏｎ」，（Ｒｅｌｅａｓｅ １６）；

・ ＴＳ３６．３３１，Ｖ１３．１１．０，「Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ ＲＲＣ ｐｒｏｔｏｃｏｌ ｓｐｅｃｉｆｉｃａｔｉｏｎ」，（Ｒｅｌｅａｓｅ １３），２０１８－０９－２７；

・ ＴＳ３８．３００，Ｖ１６．３．０，「ＮＲ ａｎｄ ＮＧ－ＲＡＮ Ｏｖｅｒａｌｌ ｄｅｓｃｒｉｐｔｉｏｎ；Ｓｔａｇｅ－２」，（Ｒｅｌｅａｓｅ １６），２０２０－１０－０２；

・ ＴＳ３６．２１３，Ｖ１３．１１．０，「Ｅｖｏｌｖｅｄ Ｕｎｉｖｅｒｓａｌ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ（Ｅ－ＵＴＲＡ）；Ｐｈｙｓｉｃａｌ ｌａｙｅｒ ｐｒｏｃｅｄｕｒｅｓ」，（Ｒｅｌｅａｓｅ １３），２０１８－１０－０１；

・ ＴＳ３８．３０６，Ｖ１６－２，「Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ（ＵＥ） ｒａｄｉｏ ａｃｃｅｓｓ ｃａｐａｂｉｌｉｔｉｅｓ」，（Ｒｅｌｅａｓｅ １６），２０２０－１０－０２

説明を詳細に記載してきたが、添付の特許請求の範囲によって定められる本開示の趣旨及び範囲から逸脱することなく、様々な変更、置換、及び改変を行われることができることを理解されたい。また、本開示の範囲は、本明細書に説明された特定の実施形態に限定されるものではなく、当業者は、現在存在する又は後で開発されるプロセス、機械、製造、物質の組成、手段、方法、又はステップが、本明細書に記載の対応する実施形態と実質的に同じ機能を実行しうる、又は実質的に同じ結果を達成しうることを本開示から容易に理解するであろう。従って、添付の特許請求の範囲は、そのようなプロセス、機械、製造、物質の組成、手段、方法、又はステップをその範囲内に含むことが意図される。

Claims (42)

1. ユーザ機器（ＵＥ）によって、基準に基づいて、前記ＵＥのランダムアクセス（ＲＡ）手順中に又は前記ＲＡ手順後に、それが機能削減（ＲｅｄＣａｐ）ＵＥであることをｇＮＢへ示すかを決定するステップであって、前記ＲｅｄＣａｐ ＵＥは、非ＲｅｄＣａｐ ＵＥの受信ブランチの最小数よりも少ない受信ブランチの数量を有するか、又は前記非ＲｅｄＣａｐ ＵＥの最小帯域幅よりも少ない帯域幅を有する、ステップと、
   前記ＵＥによって、前記ｇＮＢへ、決定結果に従ってそれが前記ＲｅｄＣａｐ ＵＥであることを示すステップと
   を含む、方法。
2. 前記非ＲｅｄＣａｐ ＵＥは、レガシーＵＥである、
   請求項１に記載の方法。
3. 前記ＲｅｄＣａｐ ＵＥは、１つ又は２つの受信ブランチを有する
   請求項１又は２に記載の方法。
4. 前記非ＲｅｄＣａｐ ＵＥのための前記受信ブランチの最小数は、周波数範囲１（ＦＲ１）について４であり、周波数範囲２（ＦＲ２）について２である
   請求項１～３のいずれか１項に記載の方法。
5. 前記示すステップは、
   前記ＵＥによって、前記ＲＡ手順中に前記ＵＥを前記ＲｅｄＣａｐ ＵＥとして示す第１のメッセージを前記ＲＡ手順中に示すことを決定するときに前記ｇＮＢへ送るステップを含み、前記第１のメッセージは、前記ＲＡ手順のメッセージ１（Ｍｓｇ１）、前記ＲＡ手順のメッセージ３（Ｍｓｇ３）、又は前記ＲＡ手順の前記ＲＡ手順のメッセージＡ（ＭｓｇＡ）を含む
   請求項１～４のいずれか１項に記載の方法。
6. 前記ＵＥによって、前記ＲＡ手順前に、前記ｇＮＢによってブロードキャストされ、前記ＵＥによって受信される無線リソース制御（ＲＲＣ）構成に基づいて、前記ＲＡ手順前に、前記第１のメッセージを決定するステップをさらに含む
   請求項５に記載の方法。
7. 前記ＲＲＣ構成は、前記基準の情報を含む
   請求項６に記載の方法。
8. 前記ＲＡ手順前に前記ｇＮＢによってブロードキャストされ、前記ＵＥによって受信される物理的ランダムアクセスチャネル（ＰＲＡＣＨ）構成に従って、前記第１のメッセージは、前記ＵＥによって送られ、前記ＰＲＡＣＨ構成は、ＲＡＣＨプリアンブル、ＲＡＣＨオケージョン、又はそれらの組合せを含み、これは、ＲｅｄＣａｐ ＵＥを示すことに関係付けられる、
   請求項５～７のいずれか１項に記載の方法。
9. 前記ＵＥによって、前記ＲＡ手順中に前記ｇＮＢから、受信されたカバレージ回復技法に従ってメッセージ２（Ｍｓｇ２）又はメッセージ４（Ｍｓｇ４）を受信するステップをさらに含む
   請求項５～８のいずれか１項に記載の方法。
10. 前記第１のメッセージは、前記Ｍｓｇ１であり、前記方法は、
    前記ＵＥによって、前記ｇＮＢへの前記Ｍｓｇ３の送信を繰り返すステップをさらに含む
    請求項５～９のいずれか１項に記載の方法。
11. 前記Ｍｓｇ３の前記送信の反復の数がＲＡＣＨ構成に従う
    請求項１０に記載の方法。
12. 前記Ｍｓｇ３の前記送信を繰り返すステップは、前記ＵＥの参照信号受信電力（ＲＳＲＰ）測定が閾値よりも少ないときに実行される
    請求項１０に記載の方法。
13. 前記示すステップは、
    前記ＵＥによって、前記ＲＡ手順が完了された後に前記ＵＥを前記ＲｅｄＣａｐ ＵＥとして示すＵＥ機能の情報を前記ＲＡ手順後に示すことを決定するときに前記ｇＮＢへ送るステップを含む
    請求項１～４のいずれか１項に記載の方法。
14. 前記基準は、前記ＵＥの受信ブランチの数、前記ＵＥによって測定される参照信号受信電力（ＲＳＲＰ）、前記ＵＥによって測定される参照信号受信品質（ＲＳＲＱ）、前記ＵＥによって測定される参照信号強度インジケータ（ＲＳＳＩ）、又はそれらの組合せに基づく、
    請求項１～１３のいずれか１項に記載の方法。
15. 前記基準は、前記ＵＥの機能に基づく
    請求項１～１４のいずれか１項に記載の方法。
16. 前記決定するステップは、
    前記ＵＥが２つの受信ブランチを有するとき、前記ＵＥによって、前記ＲＡ手順後に前記ＵＥを前記ＲｅｄＣａｐ ＵＥとして示すことを決定するステップ、又は
    前記ＵＥが１つの受信ブランチを有するとき、前記ＵＥによって、前記ＲＡ手順中に前記ＵＥを前記ＲｅｄＣａｐ ＵＥとして示すことを決定するステップ
    を含む
    請求項１～１５のいずれか１項に記載の方法。
17. 前記決定するステップは、
    前記ＵＥが２つの受信ブランチを有し、周波数範囲１（ＦＲ１）又はＦＲ２内で動作可能であるとき、前記ＵＥによって、前記ＲＡ手順後に前記ＵＥを前記ＲｅｄＣａｐ ＵＥとして示すことを決定するステップ、
    前記ＵＥが１つの受信ブランチを有し、ＦＲ１又はＦＲ２内で動作可能であるとき、前記ＵＥによって、前記ＲＡ手順中に前記ＵＥを前記ＲｅｄＣａｐ ＵＥとして示すことを決定するステップ、又は
    前記ＵＥが２つの受信ブランチを有し、ＦＲ１内で動作可能であるとき、前記ＵＥによって、前記ＲＡ手順中に前記ＵＥを前記ＲｅｄＣａｐ ＵＥとして示すことを決定するステップ
    を含む
    請求項１～１５のいずれか１項に記載の方法。
18. 前記決定するステップは、
    前記ＵＥによって、ＲＳＲＰ測定をＲｅｄＣａｐ ＵＥのために構成された閾値と比較するステップ、
    前記ＲＳＲＰ測定が前記閾値よりも大きいとき、前記ＵＥによって、前記ＲＡ手順後に前記ＵＥを前記ＲｅｄＣａｐ ＵＥとして示すことを決定するステップ、又は
    前記ＵＥの前記ＲＳＲＰ測定が前記閾値以下であるとき、前記ＵＥによって、前記ＲＡ手順中に前記ＵＥを前記ＲｅｄＣａｐ ＵＥとして示すことを決定するステップ
    を含む
    請求項１～１５のいずれか１項に記載の方法。
19. 前記決定するステップは、
    前記ＵＥによって、ＲＳＲＰ測定をＲｅｄＣａｐ ＵＥのために構成された閾値と比較するステップ、
    前記ＵＥが２つの受信ブランチを有し、前記ＲＳＲＰ測定が前記閾値よりも大きい とき、前記ＵＥによって、前記ＲＡ手順後に前記ＵＥを前記ＲｅｄＣａｐ ＵＥとして示すことを決定するステップ、
    前記ＵＥが２つの受信ブランチを有し、前記ＵＥの前記ＲＳＲＰ測定が前記閾値以下であるとき、前記ＵＥによって、前記ＲＡ手順中に前記ＵＥを前記ＲｅｄＣａｐ ＵＥとして示すことを決定するステップ、又は
    前記ＵＥが１つの受信ブランチを有するとき、前記ＵＥによって、前記ＲＡ手順中に前記ＵＥを前記ＲｅｄＣａｐ ＵＥとして示すことを決定するステップ
    を含む
    請求項１～１５のいずれか１項に記載の方法。
20. 前記決定するステップは、
    前記ＵＥによって、ＲＳＲＰ測定をＲｅｄＣａｐ ＵＥのために構成された閾値と比較するステップ、
    前記ＵＥが１つの受信ブランチを有し、前記ＲＳＲＰ測定が前記閾値よりも大きいとき、前記ＵＥによって、前記ＲＡ手順後に前記ＵＥを前記ＲｅｄＣａｐ ＵＥとして示すことを決定するステップ、
    前記ＵＥが１つの受信ブランチを有し、前記ＲＳＲＰ測定が前記閾値以下であるとき、前記ＵＥによって、前記ＲＡ手順中に前記ＵＥを前記ＲｅｄＣａｐ ＵＥとして示すことを決定するステップ、又は
    前記ＵＥが２つの受信ブランチを有するとき、前記ＵＥによって、前記ＲＡ手順後に前記ＵＥを前記ＲｅｄＣａｐ ＵＥとして示すことを決定するステップ
    を含む
    請求項１～１５のいずれか１項に記載の方法。
21. 方法であって、
    ｇＮＢによって、ランダムアクセス（ＲＡ）手順中に、ユーザ機器（ＵＥ）から第１のメッセージを受信するステップと、
    前記ｇＮＢによって、前記第１のメッセージが、前記ＵＥが機能削減（ＲｅｄＣａｐ）ＵＥであることを示すかを決定するステップであって、前記ＲｅｄＣａｐ ＵＥは、非ＲｅｄＣａｐ ＵＥの受信ブランチの最小数よりも少ない受信ブランチの数量を有するか、又は前記非ＲｅｄＣａｐ ＵＥの最小帯域幅よりも少ない帯域幅を有する、ステップと、
    前記第１のメッセージが前記ＵＥを前記ＲｅｄＣａｐ ＵＥとして示すときに、前記ｇＮＢによって、カバレージ回復技法に従って前記ＲＡ手順中に前記ＵＥへ第２のメッセージを送るステップと、
    前記第１のメッセージが前記ＵＥを前記ＲｅｄＣａｐ ＵＥとして示さないときに、前記ｇＮＢによって、前記ＲＡ手順が完了された後に前記ＵＥが前記ＲｅｄＣａｐ ＵＥであるか決定するステップと
    を含む、方法。
22. 前記非ＲｅｄＣａｐ ＵＥは、レガシーＵＥである
    請求項２１に記載の方法。
23. 前記ＲｅｄＣａｐ ＵＥは、１つ又は２つの受信ブランチを有する
    請求項２１又は２２に記載の方法。
24. 前記非ＲｅｄＣａｐ ＵＥの前記受信ブランチの最小数は、周波数範囲１（ＦＲ１）について４であり、周波数範囲２（ＦＲ２）について２である
    請求項２１～２３のいずれか１項に記載の方法。
25. 前記第１のメッセージは、前記ＲＡ手順のメッセージ１（Ｍｓｇ１）、前記ＲＡ手順のメッセージ３（Ｍｓｇ３）、又は前記ＲＡ手順のメッセージＡ（ＭｓｇＡ）を含む
    請求項２１～２４のいずれか１項に記載の方法。
26. 前記第１のメッセージは、前記ｇＮＢによってブロードキャストされる物理的ランダムアクセスチャネル（ＰＲＡＣＨ）構成に基づき、前記ＰＲＡＣＨ構成は、ＲＡＣＨプリアンブル、ＲＡＣＨオケージョン、又はそれらの組合せを含み、これは、ＲｅｄＣａｐ ＵＥを示すことに関係付けられる
    請求項２５に記載の方法。
27. 前記第２のメッセージは、前記ＲＡ手順のメッセージ２（Ｍｓｇ２）、又は前記ＲＡ手順のメッセージ４（Ｍｓｇ４）である
    請求項２１～２６のいずれか１項に記載の方法。
28. 前記ｇＮＢによって、前記ＵＥから、前記ＲＡ手順が完了された後に前記ＵＥを前記ＲｅｄＣａｐ ＵＥとして示すＵＥ機能の情報を受信するステップをさらに含む
    請求項２１～２５のいずれか１項に記載の方法。
29. 前記ｇＮＢによって、前記ＵＥへ基準の情報をブロードキャストするステップであって、前記基準に基づいて、前記ＲＡ手順中に又は前記ＲＡ手順後に、前記ＵＥを前記ＲｅｄＣａｐ ＵＥとして前記ｇＮＢへ示すか前記ＵＥが決定することを可能にする、ステップをさらに含む
    請求項２１～２８のいずれか１項に記載の方法。
30. 前記基準は、前記ＵＥの受信ブランチの数、前記ＵＥの参照信号受信電力（ＲＳＲＰ）測定、前記ＵＥの参照信号受信品質（ＲＳＲＱ）測定、前記ＵＥの参照信号強度インジケータ（ＲＳＳＩ）、又はそれらの組合せに基づく
    請求項２９に記載の方法。
31. 前記基準は、前記ＵＥの機能に基づく、
    請求項２９又は３０に記載の方法。
32. 前記基準は、
    前記ＵＥが２つの受信ブランチを有するとき、前記ＲＡ手順後に前記ＲｅｄＣａｐ ＵＥを示すステップ、又は
    前記ＵＥが１つの受信ブランチを有するとき、前記ＲＡ手順中に前記ＲｅｄＣａｐ ＵＥを示すステップ
    を含む
    請求項２９～３１のいずれか１項に記載の方法。
33. 前記基準は、
    前記ＵＥが２つの受信ブランチを有し、周波数範囲１（ＦＲ１）又はＦＲ２内で動作可能であるとき、前記ＲＡ手順後に前記ＲｅｄＣａｐ ＵＥを示すステップ、
    前記ＵＥが１つの受信ブランチを有し、ＦＲ１又はＦＲ２内で動作可能であるとき、前記ＲＡ手順中に前記ＲｅｄＣａｐ ＵＥを示すステップ、又は
    前記ＵＥが２つの受信ブランチを有し、ＦＲ１内で動作可能であるとき、前記ＲＡ手順中に前記ＲｅｄＣａｐ ＵＥを示すステップ
    を含む
    請求項２９～３１のいずれか１項に記載の方法。
34. 前記基準は、
    前記ＵＥによって測定されるＲＳＲＰが閾値よりも大きいとき、前記ＲＡ手順後に前記ＲｅｄＣａｐ ＵＥを示すステップ、又は
    前記ＵＥによって測定される前記ＲＳＲＰが前記閾値以下であるとき、前記ＲＡ手順中に前記ＲｅｄＣａｐ ＵＥを示すステップ
    を含む
    請求項２９～３１のいずれか１項に記載の方法。
35. 前記基準は、
    前記ＵＥが２つの受信ブランチを有し、前記ＵＥによって測定されるＲＳＲＰが閾値よりも大きいとき、前記ＲＡ手順後に前記ＲｅｄＣａｐ ＵＥを示すステップ、
    前記ＵＥが２つの受信ブランチを有し、前記ＵＥによって測定される前記ＲＳＲＰが前記閾値以下であるとき、前記ＲＡ手順中に前記ＲｅｄＣａｐ ＵＥを示すステップ、又は
    前記ＵＥが１つの受信ブランチを有するとき、前記ＲＡ手順中に前記ＲｅｄＣａｐ ＵＥを示すステップ
    を含む
    請求項２９～３１のいずれか１項に記載の方法。
36. 前記基準は、
    前記ＵＥが１つの受信ブランチを有し、前記ＵＥによって測定されるＲＳＲＰが閾値よりも大きいとき、前記ＲＡ手順後に前記ＲｅｄＣａｐ ＵＥを示すステップ、
    前記ＵＥが１つの受信ブランチを有し、前記ＵＥによって測定されるＲＳＲＰが、前記閾値以下であるとき、前記ＲＡ手順中に前記ＲｅｄＣａｐ ＵＥを示すステップ、又は
    前記ＵＥが２つの受信ブランチを有するとき、前記ＲＡ手順後に前記ＲｅｄＣａｐ ＵＥを示すステップ
    を含む
    請求項２９～３１のいずれか１項に記載の方法。
37. 前記ｇＮＢによって、前記ｇＮＢがＲｅｄＣａｐ ＵＥをサポートすることを示す情報をブロードキャストするステップをさらに含む
    請求項２１～３６のいずれか１項に記載の方法。
38. 命令を備える非一時的なメモリストレージと、
    前記メモリストレージと通信する１つ又は複数のプロセッサと
    を備える装置であって、前記命令は、前記１つ又は複数のプロセッサによって実行されるときに、前記装置に、
    基準に基づいて、前記装置のランダムアクセス（ＲＡ）手順中に又は前記ＲＡ手順後に、前記装置が機能削減（ＲｅｄＣａｐ）ＵＥであることをｇＮＢへ示すか決定することであって、前記ＲｅｄＣａｐ ＵＥは、非ＲｅｄＣａｐ ＵＥの受信ブランチの最小数よりも少ない受信ブランチの数量を有するか、又は前記非ＲｅｄＣａｐ ＵＥの最小帯域幅よりも少ない帯域幅を有する、ことと、
    決定結果に従って、前記装置が前記ＲｅｄＣａｐ ＵＥであることを前記ｇＮＢへ示すことと
    を実行させる、装置。
39. 命令を備える非一時的なメモリストレージと、
    前記メモリストレージと通信する１つ又は複数のプロセッサと、
    を備える装置であって、前記命令は、前記１つ又は複数のプロセッサによって実行されるときに、前記装置に、
    ランダムアクセス（ＲＡ）手順中にユーザ機器（ＵＥ）から第１のメッセージを受信することと、
    前記第１のメッセージが、前記ＵＥが機能削減（ＲｅｄＣａｐ）ＵＥであることを示すか決定することであって、前記ＲｅｄＣａｐ ＵＥは、非ＲｅｄＣａｐ ＵＥの受信ブランチの最小数よりも少ない受信ブランチの数量を有するか、又は前記非ＲｅｄＣａｐ ＵＥの最小帯域幅よりも少ない帯域幅を有する、ことと、
    前記第１のメッセージが前記ＵＥを前記ＲｅｄＣａｐ ＵＥとして示すときに、カバレージ回復技法に従って前記ＲＡ手順中に前記ＵＥへ第２のメッセージを送ることと、
    前記第１のメッセージが前記ＵＥを前記ＲｅｄＣａｐ ＵＥとして示さないときに、前記ＲＡ手順が完了された後に、前記ＵＥが前記ＲｅｄＣａｐ ＵＥであるか決定することと
    を実行させる、装置。
40. コンピュータ命令を記憶する非一時的なコンピュータ可読媒体であって、装置の１つ又は複数のプロセッサによって実行されるときに、前記装置に、
    基準に基づいて、前記装置のランダムアクセス（ＲＡ）手順中に又は前記ＲＡ手順後に、前記装置が機能削減（ＲｅｄＣａｐ）ＵＥであることをｇＮＢへ示すか決定することであって、前記ＲｅｄＣａｐ ＵＥは、非ＲｅｄＣａｐ ＵＥの受信ブランチの最小数よりも少ない受信ブランチの数量を有するか、又は前記非ＲｅｄＣａｐ ＵＥの最小帯域幅よりも少ない帯域幅を有する、ことと、
    決定結果に従って、前記装置が前記ＲｅｄＣａｐ ＵＥであることを前記ｇＮＢへ示すことと
    を実行させる、非一時的なコンピュータ可読媒体。
41. コンピュータ命令を記憶する非一時的なコンピュータ可読媒体であって、装置の１つ又は複数のプロセッサによって実行されるときに、前記装置に、
    ランダムアクセス（ＲＡ）手順中にユーザ機器（ＵＥ）から第１のメッセージを受信することと、
    前記第１のメッセージが、前記ＵＥが機能削減（ＲｅｄＣａｐ）ＵＥであることを示すか決定することであって、前記ＲｅｄＣａｐ ＵＥは、非ＲｅｄＣａｐ ＵＥの受信ブランチの最小数よりも少ない受信ブランチの数量を有するか、又は前記非ＲｅｄＣａｐ ＵＥの最小帯域幅よりも少ない帯域幅を有する、ことと、
    前記第１のメッセージが前記ＵＥを前記ＲｅｄＣａｐ ＵＥとして示すときに、カバレージ回復技法に従って前記ＲＡ手順中に前記ＵＥへ第２のメッセージを送ることと、
    前記第１のメッセージが前記ＵＥを前記ＲｅｄＣａｐ ＵＥとして示さないときに、前記ＲＡ手順が完了された後に、前記ＵＥが前記ＲｅｄＣａｐ ＵＥであるか決定することと
    を実行させる、非一時的なコンピュータ可読媒体。
42. ユーザ機器（ＵＥ）及びｇＮＢを備えるシステムであって、
    前記ＵＥは、
    基準に基づいて、前記ＵＥのランダムアクセス（ＲＡ）手順中に又は前記ＲＡ手順後に、前記ＵＥが機能削減（ＲｅｄＣａｐ）ＵＥであることを前記ｇＮＢへ示すかを決定することであって、前記ＲｅｄＣａｐ ＵＥは、非ＲｅｄＣａｐ ＵＥの受信ブランチの最小数よりも少ない受信ブランチの数量を有するか、又は前記非ＲｅｄＣａｐ ＵＥの最小帯域幅よりも少ない帯域幅を有する、ことと、
    決定結果に従って、前記ｇＮＢへ、前記ＵＥが前記ＲｅｄＣａｐ ＵＥであることを示すことと
    を実行するように構成され、
    前記ｇＮＢは、
    ランダムアクセス（ＲＡ）手順中に前記ＵＥから第１のメッセージを受信することと、
    前記第１のメッセージが、前記ＵＥが前記ＲｅｄＣａｐ ＵＥであることを示すかを決定することと、
    前記第１のメッセージが前記ＵＥを前記ＲｅｄＣａｐ ＵＥとして示すときに、カバレージ回復技法に従って前記ＲＡ手順中に前記ＵＥへ第２のメッセージを送ることと、
    前記第１のメッセージが前記ＵＥを前記ＲｅｄＣａｐ ＵＥとして示さないときに、前記ＲＡ手順が完了された後に、前記ＵＥが前記ＲｅｄＣａｐ ＵＥであるか決定することと
    を実行するように構成される、システム。

Images