JP7446476B2

JP7446476B2 - ランダムアクセス方法、装置、およびシステム

Info

Publication number: JP7446476B2
Application number: JP2022560382A
Authority: JP
Inventors: ▲海▼▲龍▼ 侯; 超君李; 永▲強▼ ▲費▼; 磊 ▲陳▼; 娟 ▲鄭▼
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2020-04-03
Filing date: 2021-04-01
Publication date: 2024-03-08
Anticipated expiration: 2041-04-01
Also published as: US20230034674A1; WO2021197404A1; KR20220162763A; EP4132195A4; CN116321507B; CN116321507A; EP4132195A1; CN113498213A; JP2023520545A

Description

本出願は、その全体が参照により本明細書に組み込まれる、2020年4月3日に中国国家知識産権局に出願された「RANDOM ACCESS METHOD, APPARATUS, AND SYSTEM」と題する中国特許出願第202010260718.X号の優先権を主張する。

本出願は通信技術の分野に関し、詳細には、ランダムアクセス方法、装置、およびシステムに関する。

端末は通常、ネットワークデバイスとのアップリンク時間同期を完了し、ネットワークデバイスへの無線リソース制御接続を確立するために、ネットワークデバイスとのランダムアクセス手順を実施する必要があり、その結果として、端末およびネットワークデバイスは、無線リソース制御接続に基づいてサービスデータを交換する。

モノのインターネットアプリケーション技術の発展に伴って、端末の帯域幅タイプは多様化する傾向がある。たとえば、いくつかの端末の帯域幅能力は5MHzである場合があり、いくつかの端末の帯域幅能力は10MHzである場合があり、いくつかの端末の帯域幅能力は20MHzである場合があり、いくつかの端末の帯域幅能力は100MHzである場合がある。したがって、同じネットワークデバイスの場合、ネットワークデバイスは、複数の帯域幅タイプの端末に接続される必要がある場合がある。

現在、ネットワークデバイスは通常、20MHzの初期ダウンリンク帯域幅においてランダムアクセスチャネル(random access channel、RACH)リソース構成情報を端末に送り、その結果として、端末は、受信されたRACHリソース構成情報に基づいて、ネットワークデバイスとのランダムアクセス手順のための対応するRACHリソースを選択する。この場合、様々な帯域幅タイプの端末はすべて、完全に同じRACHリソース構成情報を使用する必要がある。結果として、いくつかの端末は、端末の帯域幅能力の制限のせいで、ネットワークデバイスに効率的に接続するのに失敗する場合がある。

本出願の実施形態は、様々な帯域幅タイプの端末がより効率的にネットワークデバイスに接続するのを助けるために、ランダムアクセス方法、装置、およびシステムを提供する。

第1の態様によれば、ランダムアクセス方法が提供される。本方法は、ネットワークデバイスによって実施されてもよく、またはネットワークデバイスにおいて展開されたモジュール、チップ、もしくはシステムオンチップによって実施されてもよい。本方法は、M個のランダムアクセスチャネルRACHリソースセットを決定するステップであって、M個のRACHリソースセットがN個の端末タイプに対応し、N個の端末タイプが端末の帯域幅タイプおよび/またはランダムアクセスタイプに基づいて決定され、MおよびNが正の整数である、ステップと、RACH構成情報を少なくとも1つの端末に送るステップであって、RACH構成情報がM個のRACHリソースセットを示し、M個のRACHリソースセットがランダムアクセス要求をネットワークデバイスに送るために少なくとも1つの端末によって使用され、少なくとも1つの端末のうちのいずれか1つの帯域幅タイプがN個の端末タイプを決定するための帯域幅タイプに属する、ステップとを含む。

結論として、ネットワークデバイスによってサポートされるN個の端末タイプは、少なくとも1つの帯域幅タイプおよび/または少なくとも1つのランダムアクセスタイプに基づいてフレキシブルに構成されてもよく、M個のRACHリソースセットはN個の端末タイプのために構成され、MおよびNは正の整数である。異なる帯域幅タイプの端末は、ランダムアクセス手順を開始するために、同じRACHリソースセットまたは異なるRACHリソースセットに基づいてランダムアクセス要求をネットワークデバイスに別々に送ってもよい。このことは、様々な帯域幅タイプの端末がより効率的にネットワークデバイスに接続するのを助ける。

可能な実装形態では、M個のRACHリソースセットのうちの1つについて、ネットワークデバイスは、RACHリソースセットに対応する少なくとも1つの端末タイプを決定し、少なくとも1つの端末タイプに基づいて、ランダムアクセス手順を実施する少なくとも1つの端末デバイスを決定し、次いで、構成情報を少なくとも1つの端末デバイスに送ってもよい。ネットワークデバイスは、ランダムアクセス手順におけるリソース構成がよりフレキシブルになり、リソース利用が改善されるように、端末の帯域幅タイプおよびランダムアクセスタイプに基づいてRACHリソースを割り振る。

可能な実装形態では、N個の端末タイプのうちのいずれか1つは、少なくとも1つの帯域幅タイプのうちの1つおよび/または少なくとも1つのランダムアクセスタイプのうちの1つに基づいて決定され、少なくとも1つの端末のうちのいずれか1つの帯域幅タイプは、少なくとも1つの帯域幅タイプのうちの1つである。

可能な実装形態では、RACH構成情報は第1のRACH構成をさらに示し、第1のRACH構成は、M個のRACHリソースセットがN個の端末タイプに対応し、MがNよりも小さく、Mが1に等しいというものである。

可能な実装形態では、RACH構成情報は第2のRACH構成をさらに示し、第2のRACH構成は、M個のRACHリソースセットがN個の端末タイプに対応し、MがNに等しく、Mが1よりも大きいというものである。

可能な実装形態では、RACH構成情報は第3のRACH構成をさらに示し、第3のRACH構成は、M個のRACHリソースセットがN個の端末タイプに対応し、MがNよりも小さく、Mが1よりも大きいというものである。

可能な実装形態では、RACH構成情報は第4のRACH構成をさらに示し、第4のRACH構成は、M個のRACHリソースセットがN個の端末タイプに対応し、MがNに等しく、Mが1に等しいというものである。

可能な実装形態では、RACH構成情報はX個のRACH構成のうちの1つをさらに示し、Xは正の整数であり、X個のRACH構成は以下のRACH構成、すなわち、
第1のRACH構成であって、第1のRACH構成が、M個のRACHリソースセットがN個の端末タイプに対応し、MがNよりも小さく、Mが1に等しいというものである、第1のRACH構成、
第2のRACH構成であって、第2のRACH構成が、M個のRACHリソースセットがN個の端末タイプに対応し、MがNに等しく、Mが1よりも大きいというものである、第2のRACH構成、
第3のRACH構成であって、RACH構成情報が第3のRACH構成を示し、第3のRACH構成が、M個のRACHリソースセットがN個の端末タイプに対応し、MがNよりも小さく、Mが1よりも大きいというものである、第3のRACH構成、または
第4のRACH構成であって、第4のRACH構成が、M個のRACHリソースセットがN個の端末タイプに対応し、MがNに等しく、Mが1に等しいというものである、第4のRACH構成
のうちの少なくとも2つを含む。

可能な実装形態では、RACH構成情報は、N個の端末タイプが少なくとも1つのアップリンク初期帯域幅パート(uplink initial bandwidth part、UL initial BWP)に対応することをさらに示す。

可能な実装形態では、RACH構成情報を少なくとも1つの端末に送るステップは、少なくとも1つのダウンリンク初期帯域幅パート(downlink initial bandwidth part、DL initial BWP)においてRACH構成情報を少なくとも1つの端末に送るステップを含む。

可能な実装形態では、RACH構成情報を少なくとも1つの端末に送るステップは、シグナリングを少なくとも1つの端末に送るステップを含み、シグナリングはRACH構成情報を含み、シグナリングは、以下のタイプのシグナリング、すなわち、媒体アクセス制御制御要素(media access control-control element、MACCE)シグナリング、ダウンリンク制御情報(downlink control information、DCI)シグナリング、無線リソース制御(radio resource control、RRC)シグナリング、およびシステム情報ブロックタイプ1(system information block-type1、SIB1)シグナリングのうちの少なくとも1つを含む。

可能な実装形態では、本方法は、少なくとも1つの端末の中の現在の端末からランダムアクセス要求を受信するステップと、ランダムアクセス要求に対応するターゲットRACHリソースセットを決定するステップと、ターゲットRACHリソースセットに対応する物理アップリンク共有チャネル(physical uplink shared channel、PUSCH)リソースセットに基づいてランダムアクセス要求に応答するステップとをさらに含む。

可能な実装形態では、ランダムアクセス要求は現在の端末の帯域幅タイプを含み、ランダムアクセス要求はmessage1またはmessageAを介して送られる。

可能な実装形態では、現在の端末の帯域幅タイプはmessage1のPRACH上で搬送されるか、または現在の端末の帯域幅タイプはmessageAのPRACHもしくはPUSCH上で搬送される。

可能な実装形態では、少なくとも1つの帯域幅タイプは、以下の帯域幅タイプ、すなわち、NR_legacy、NR_REDCAP type1、およびNR_REDCAP type2のうちの少なくとも1つを含み、
少なくとも1つのランダムアクセスタイプは、以下のランダムアクセスタイプ、すなわち、4-step RACH、4-step RACH&EDT、2-step RACH、および2-step RACH&EDTのうちの少なくとも1つを含み、
N個の端末タイプは、以下の端末タイプ、すなわち、
NR_legacyおよび4-step RACHに基づいて決定された端末タイプ、
NR_legacyおよび4-step RACH&EDTに基づいて決定された端末タイプ、
NR_legacyおよび2-step RACHに基づいて決定された端末タイプ、
NR_legacyおよび2-step RACH&EDTに基づいて決定された端末タイプ、
NR_REDCAP type1および4-step RACHに基づいて決定された端末タイプ、
NR_REDCAP type1および4-step RACH&EDTに基づいて決定された端末タイプ、
NR_REDCAP type1および2-step RACHに基づいて決定された端末タイプ、
NR_REDCAP type1および2-step RACH&EDTに基づいて決定された端末タイプ、
NR_REDCAP type2および4-step RACHに基づいて決定された端末タイプ、
NR_REDCAP type2および4-step RACH&EDTに基づいて決定された端末タイプ、
NR_REDCAP type2および2-step RACHに基づいて決定された端末タイプ、または
NR_REDCAP type2および2-step RACH&EDTに基づいて決定された端末タイプ
のうちの少なくとも1つを含む。

第2の態様によれば、ランダムアクセス方法が提供される。有益な効果については、第1の態様における説明を参照されたい。本方法は、端末によって実施されてもよく、または端末において展開されたモジュール、チップ、もしくはシステムオンチップによって実施されてもよい。本方法は、ネットワークデバイスからRACH構成情報を受信するステップであって、RACH構成情報がM個のRACHリソースセットを示し、M個のRACHリソースセットがN個の端末タイプに対応し、N個の端末タイプが端末の帯域幅タイプおよび/またはランダムアクセスタイプに基づいて決定され、MおよびNが正の整数である、ステップと、構成情報に基づいて、ランダムアクセス要求をネットワークデバイスに送るために現在の端末によって使用されるターゲットRACHリソースセットを決定するステップであって、現在の端末の帯域幅タイプがN個の端末タイプを決定するための帯域幅タイプに属する、ステップとを含む。

可能な実装形態では、RACH構成情報はX個のRACH構成のうちの1つをさらに示し、Xは正の整数であり、X個のRACH構成は以下のRACH構成、すなわち、
第1のRACH構成であって、第1のRACH構成が、M個のRACHリソースセットがN個の端末タイプに対応し、MがNよりも小さく、Mが1に等しいというものである、第1のRACH構成、
第2のRACH構成であって、第2のRACH構成が、M個のRACHリソースセットがN個の端末タイプに対応し、MがNに等しく、Mが1よりも大きいというものである、第2のRACH構成、
第3のRACH構成であって、第3のRACH構成が、M個のRACHリソースセットがN個の端末タイプに対応し、MがNよりも小さく、Mが1よりも大きいというものである、第3のRACH構成、または
第4のRACH構成であって、第4のRACH構成が、M個のRACHリソースセットがN個の端末タイプに対応し、MがNに等しく、Mが1に等しいというものである、第4のRACH構成
のうちの少なくとも2つを含む。

可能な実装形態では、ネットワークデバイスからRACH構成情報を受信するステップは、ネットワークデバイスからシグナリングを受信するステップを含み、シグナリングは構成情報を含み、シグナリングは、以下のタイプのシグナリング、すなわち、MACCEシグナリング、DCIシグナリング、SIB1シグナリング、およびRRCシグナリングのうちの少なくとも1つを含む。

可能な実装形態では、RACH構成情報に基づいて、ランダムアクセス要求をネットワークデバイスに送るために現在の端末によって使用されるターゲットRACHリソースセットを決定するステップは、RACH構成情報および現在の端末のターゲット端末タイプに基づいて、ランダムアクセス要求をネットワークデバイスに送るために現在の端末によって使用されるターゲットRACHリソースセットを決定するステップであって、現在の端末のターゲット端末タイプが、現在の端末によってサポートされるランダムアクセスタイプおよび現在の端末の帯域幅タイプに基づいて決定される、ステップを含む。

可能な実装形態では、RACH構成情報は、N個の端末タイプが少なくとも1つのUL initial BWPに対応することをさらに示し、本方法は、構成情報に基づいて、ターゲット端末タイプに対応するターゲットUL initial BWPを決定するステップと、ターゲットRACHリソースセットに基づいてターゲットUL initial BWP上でランダムアクセス要求をネットワークデバイスに送るステップとをさらに含む。

第3の態様によれば、通信装置が提供される。有益な効果については、第1の態様における説明を参照されたい。通信装置は、ネットワークデバイスであってもよく、またはネットワークデバイスにおいて展開されたモジュール、チップ、もしくはシステムオンチップであってもよい。通信装置は、M個のRACHリソースセットを決定することであって、M個のRACHリソースセットがN個の端末タイプに対応し、N個の端末タイプが端末の帯域幅タイプおよび/またはランダムアクセスタイプに基づいて決定され、MおよびNが正の整数である、決定することを行うように構成された処理ユニットと、RACH構成情報を少なくとも1つの端末に送ることであって、RACH構成情報がM個のRACHリソースセットを示し、M個のRACHリソースセットがランダムアクセス要求をネットワークデバイスに送るために少なくとも1つの端末によって使用され、少なくとも1つの端末のうちのいずれか1つの帯域幅タイプがN個の端末タイプを決定するための帯域幅タイプに属する、送ることを行うように構成されたトランシーバユニットとを含む。

可能な実装形態では、処理ユニットは、M個のRACHリソースセットのうちの1つについて、RACHリソースセットに対応する少なくとも1つの端末タイプを決定し、少なくとも1つの端末タイプに基づいて、ランダムアクセス手順を実施する少なくとも1つの端末デバイスを決定するように構成される。トランシーバユニットは、構成情報を少なくとも1つの端末デバイスに送るように構成される。ネットワークデバイスは、ランダムアクセス手順におけるリソース構成がよりフレキシブルになり、リソース利用が改善されるように、端末の帯域幅タイプおよびランダムアクセスタイプに基づいてRACHリソースを割り振る。

可能な実装形態では、RACH構成情報は、N個の端末タイプが少なくとも1つのUL initial BWPに対応することをさらに示す。

可能な実装形態では、トランシーバユニットは特に、少なくとも1つのDL initial BWPにおいてRACH構成情報を少なくとも1つの端末に送るように構成される。

可能な実装形態では、トランシーバユニットは特に、シグナリングを少なくとも1つの端末に送るように構成され、シグナリングはRACH構成情報を含み、シグナリングは、以下のタイプのシグナリング、すなわち、MACCEシグナリング、DCIシグナリング、RRCシグナリング、およびSIB1シグナリングのうちの少なくとも1つを含む。

可能な実装形態では、トランシーバユニットは、少なくとも1つの端末の中の現在の端末からランダムアクセス要求を受信するようにさらに構成され、処理ユニットは、ランダムアクセス要求に対応するターゲットRACHリソースセットを決定し、ターゲットRACHリソースセットに対応するPUSCHリソースセットに基づいてランダムアクセス要求に応答するようにさらに構成される。

第4の態様によれば、通信装置が提供される。有益な効果については、第1の態様における説明を参照されたい。通信装置は、端末であってもよく、または端末において展開されたモジュール、チップ、もしくはシステムオンチップであってもよい。通信装置は、ネットワークデバイスからRACH構成情報を受信することであって、RACH構成情報がM個のRACHリソースセットを示し、M個のRACHリソースセットがN個の端末タイプに対応し、N個の端末タイプが端末の帯域幅タイプおよび/またはランダムアクセスタイプに基づいて決定され、MおよびNが正の整数である、受信することを行うように構成されたトランシーバユニットと、構成情報に基づいて、ランダムアクセス要求をネットワークデバイスに送るために現在の端末によって使用されるターゲットRACHリソースセットを決定することであって、現在の端末の帯域幅タイプがN個の端末タイプを決定するための帯域幅タイプに属する、決定することを行うように構成された処理ユニットとを含む。

可能な実装形態では、トランシーバユニットは特に、ネットワークデバイスからシグナリングを受信するように構成され、シグナリングは構成情報を含み、シグナリングは、以下のタイプのシグナリング、すなわち、MACCEシグナリング、DCIシグナリング、SIB1シグナリング、およびRRCシグナリングのうちの少なくとも1つを含む。

可能な実装形態では、処理ユニットは特に、RACH構成情報および現在の端末のターゲット端末タイプに基づいて、ランダムアクセス要求をネットワークデバイスに送るために現在の端末によって使用されるターゲットRACHリソースセットを決定するように構成され、現在の端末のターゲット端末タイプは、現在の端末によってサポートされるランダムアクセスタイプおよび現在の端末の帯域幅タイプに基づいて決定される。

可能な実装形態では、RACH構成情報は、N個の端末タイプが少なくとも1つのUL initial BWPに対応することをさらに示し、処理ユニットは、構成情報に基づいて、ターゲット端末タイプに対応するターゲットUL initial BWPを決定するようにさらに構成され、トランシーバユニットは、ターゲットRACHリソースセットに基づいてターゲットUL initial BWP上でランダムアクセス要求をネットワークデバイスに送るようにさらに構成される。

第5の態様によれば、通信装置が提供され、通信装置はメモリおよびプロセッサを含む。メモリは命令/コードを記憶する。メモリに記憶された命令/コードを実行するとき、プロセッサは第1の態様のいずれかの実装形態による方法を実装する。

第6の態様によれば、通信装置が提供され、通信装置はメモリおよびプロセッサを含む。メモリは命令/コードを記憶する。メモリに記憶された命令/コードを実行するとき、プロセッサは第2の態様のいずれかの実装形態による方法を実装する。

第7の態様によれば、チップが提供され、チップはプロセッサを含み、プロセッサはメモリからコンピュータプログラムを呼び出し、コンピュータプログラムを実行するように構成され、その結果として、チップがインストールされた通信装置は、第1の態様のいずれかの実装形態による方法または第2の態様のいずれかの実装形態による方法を実装する。

第8の態様によれば、コンピュータ可読記憶媒体が提供され、コンピュータ可読記憶媒体は命令/コードを記憶するように構成される。命令/コードが電子デバイスのプロセッサによって実行されるとき、電子デバイスは第1の態様のいずれかの実装形態による方法または第2の態様のいずれかの実装形態による方法を実装することを可能にされる。

第9の態様によれば、命令/コードを含むコンピュータプログラム製品が提供される。コンピュータプログラム製品が電子デバイス上で動作するとき、電子デバイスは第1の態様のいずれかの実装形態による方法または第2の態様のいずれかの実装形態による方法を実装する。

第10の態様によれば、通信システムが提供され、通信システムは、第3の態様のいずれかの実装形態による通信装置および第4の態様のいずれかの実装形態による通信装置を含むか、または第5の態様による通信装置および第6の態様による通信装置を含む。

本出願の一実施形態によるワイヤレス通信システムのシステムアーキテクチャ図の一例である。端末およびネットワークデバイスがランダムアクセスタイプが4-step RACHであるランダムアクセス手順を実施することを示す概略図である。本出願の一実施形態によるランダムアクセス方法の概略フローチャートである。本出願の一実施形態による別のランダムアクセス方法の概略フローチャートである。ネットワークデバイスが異なるDL initial BWPにおいてシグナリングを少なくとも2つの帯域幅タイプの端末に送ることを示す概略図である。本出願の一実施形態による通信装置の構造の概略図である。本出願の一実施形態による別の通信装置の構造の概略図である。本出願の一実施形態による別の通信装置の構造の概略図である。本出願の一実施形態による別の通信装置の構造の概略図である。

以下では、本出願の実施形態における添付の図面を参照しながら、本出願の実施形態における技術的解決策について説明する。

本出願の実施形態では、端末は、ワイヤレス通信機能を有する電子デバイスである。端末は、地上で展開され、たとえば、指定された屋内空間内でもしくは地上で走る車両上で展開されてもよく、水上で展開され、たとえば、船内で展開されてもよく、または空中で展開され、たとえば、飛行機、気球、もしくは衛星上で展開されてもよい。端末はユーザ機器(user equipment、UE)であってもよく、UEはハンドヘルドデバイス、車載デバイス、ウェアラブルデバイス、またはワイヤレス通信機能を有するコンピューティングデバイスであってもよい。たとえば、UEはモバイルフォン(mobile phone)、タブレットコンピュータ、またはワイヤレストランシーバ機能を有するコンピュータであってもよい。代替として、端末は仮想現実(virtual reality、VR)端末デバイス、拡張現実(augmented reality、AR)端末デバイス、産業制御におけるワイヤレス端末、自動運転におけるワイヤレス端末、遠隔医療におけるワイヤレス端末、スマートグリッドにおけるワイヤレス端末、スマートシティ(smart city)におけるワイヤレス端末、スマートホーム(smart home)におけるワイヤレス端末などであってもよい。

本出願の実施形態では、端末の機能を実装するように構成された通信装置は、端末であってもよく、または端末の機能を実装する際に端末をサポートするように構成された別の装置、たとえば、端末において展開されたチップであってもよい。いくつかの実施形態では、チップはプロセッサを含み、プロセッサはメモリからコンピュータプログラムを呼び出し、コンピュータプログラムを実行するように構成され、その結果として、チップがインストールされた端末は、本出願のいずれかの実施形態による端末によって実施される方法を実装する。

本出願の実施形態で提供される端末は、メモリおよびプロセッサを含んでもよい。メモリは、実行可能コード/命令を記憶するように構成される。実行可能コード/命令を実行するとき、プロセッサは、本出願のいずれかの実施形態による端末によって実施されるランダムアクセス方法を実装する。

本出願の一実施形態は、実行可能コード/命令を記憶するように構成されたコンピュータ可読記憶媒体をさらに提供する。実行可能コード/命令が電子デバイスのプロセッサによって実行されるとき、電子デバイスは、本出願のいずれかの実施形態による端末によって実施されるランダムアクセス方法を実装することを可能にされる。

本出願の一実施形態は、実行可能コード/命令を含むコンピュータプログラム製品をさらに提供する。コンピュータプログラム製品が電子デバイス上で動作するとき、電子デバイスは、本出願のいずれかの実施形態による端末によって実施されるランダムアクセス方法を実装する。

本出願の実施形態では、ネットワークデバイスは基地局(base station、BS)を含む。基地局は、無線アクセスネットワークにおいて展開されるとともに、端末とのワイヤレス通信を実施することができるデバイスである。基地局は、複数の形態、たとえば、マクロ基地局、マイクロ基地局、中継局、およびアクセスポイントであってもよい。たとえば、基地局は、5Gネットワークにおける基地局またはロングタームエボリューション(long term evolution、LTE)ネットワークにおける基地局であってもよい。5Gネットワークにおける基地局は、送信受信ポイント(transmission reception point、TRP)またはgNBと呼ばれることもある。

本出願の実施形態では、ネットワークデバイスの機能を実装するように構成された装置は、ネットワークデバイスであってもよく、またはネットワークデバイスの機能を実装する際にネットワークデバイスをサポートするように構成された別の装置、たとえば、ネットワークデバイスにおいて展開されたチップであってもよい。いくつかの実施形態では、チップはプロセッサを含み、プロセッサはメモリからコンピュータプログラムを呼び出し、コンピュータプログラムを実行するように構成され、その結果として、チップがインストールされたネットワークデバイスは、本出願のいずれかの実施形態によるネットワークデバイスによって実施される方法を実装する。

本出願の実施形態で提供されるネットワークデバイスは、メモリおよびプロセッサを含んでもよい。メモリは、実行可能コード/命令を記憶するように構成される。実行可能コード/命令を実行するとき、プロセッサは、本出願のいずれかの実施形態によるネットワークデバイスによって実施されるランダムアクセス方法を実装する。

本出願の一実施形態は、実行可能コード/命令を記憶するように構成されたコンピュータ可読記憶媒体をさらに提供する。実行可能コード/命令が電子デバイスのプロセッサによって実行されるとき、電子デバイスは、本出願のいずれかの実施形態によるネットワークデバイスによって実施されるランダムアクセス方法を実装することを可能にされる。

本出願の一実施形態は、実行可能コード/命令を含むコンピュータプログラム製品をさらに提供する。コンピュータプログラム製品が電子デバイス上で動作するとき、電子デバイスは、本出願のいずれかの実施形態によるネットワークデバイスによって実施されるランダムアクセス方法を実装する。

本出願の実施形態で提供される技術的解決策は、マシンツーマシン(machine to machine、M2M)通信システムおよびセルラー通信システムなどの複数のタイプのワイヤレス通信システムに適用され得る。ワイヤレス通信システムは、5Gネットワークにおける新無線(new radio、NR)システムのシステムアーキテクチャと同じまたは同様であるシステムアーキテクチャを使用してもよい。

図1は、ワイヤレス通信システムのシステムアーキテクチャ図の一例である。図1に示されているように、ワイヤレス通信システム100は、ネットワークデバイス101および少なくとも1つの端末103を含んでもよい。各端末103は、ネットワークデバイスとのアップリンク時間同期を完了し、ネットワークデバイス101へのRRC接続を確立するために、ネットワークデバイス101とのランダムアクセス手順を別々に実施してもよい。端末103がネットワークデバイス101へのRRC接続を確立した後、サービスデータが端末103とネットワークデバイス101との間で送信され得る。

端末103がネットワークデバイス101に対するランダムアクセス手順を開始する前に、端末103はさらに、ネットワークデバイス101からのダウンリンク同期信号に基づいてネットワークデバイス101とのダウンリンク時間同期および周波数同期を完了してもよいことが理解され得る。ダウンリンク同期信号は、1次同期信号(primary synchronization signal、PSS)および2次同期信号(secondary synchronization signal、SSS)を含む。

たとえば、ワイヤレス通信システム100はNRシステムアーキテクチャを使用する。端末103およびネットワークデバイス101は、ランダムアクセスタイプが「4-step RACH」であるランダムアクセス手順を実施してもよく、またはランダムアクセスタイプが「2-step RACH」であるランダムアクセス手順を実施してもよい。NR R15規格はランダムアクセスタイプが「4-step RACH」であるランダムアクセス手順を定義し、NR R16規格はランダムアクセスタイプが「2-step RACH」であるランダムアクセス手順を定義する。

図2を参照すると、端末103およびネットワークデバイス101がランダムアクセスタイプが「4-step RACH」であるランダムアクセス手順を実施することは、一例を使用することによって以下でさらに説明される。

最初に、端末103は、物理ランダムアクセスチャネル(physical random access channel、PRACH)上でpreambleをネットワークデバイスに送る。すなわち、端末103は、preambleを含む情報1(message1)をネットワークデバイス101に送る。この前に、端末103はさらに、ネットワークデバイス101からのシステムブロードキャスト情報を読み取ることによって、ネットワークデバイス101によって端末103に送られた構成情報を取得してもよい。構成情報は、1つまたは複数のRACHリソースを示してもよい。1つのRACHリソースは主に、PRACHチャネルのために使用される時間領域リソース、周波数領域リソース、直交コードシーケンスリソースなどを含む。

RACHリソースは物理ランダムアクセスチャネル(physical random access channel、PARCH)リソースと呼ばれることもあることに留意されたい。

次いで、message1を送った後、端末103はランダムアクセス応答ウィンドウをスタートし、対応するウィンドウにおいて、ネットワークデバイス103によって送られたランダムアクセス応答(random access response、RAR)をリッスンする。すなわち、端末103は、RARを含む情報2(message2)をネットワークデバイス101から受信する。

次いで、端末103がネットワークデバイス101によって端末103に送られたRARを成功裡に検出する場合、端末103のランダムアクセスが成功し、端末103はさらに、RARの指示に基づいて情報3(message3)をネットワークデバイス101に送ってもよい。message3は主に、RRC接続要求をネットワークデバイス101に送るためのものであり、message3は、UE識別子(identifier、ID)を含んでもよい。

端末103がネットワークデバイス101によって端末103に送られたRARを検出しない場合、端末103のランダムアクセスが失敗し、端末103は、ランダムアクセス時間の対応する最大量に達するまで、ネットワークデバイス101によって示されたバックオフパラメータに基づいてランダムアクセス手順を再開始してもよいことに留意されたい。

さらに、message3をネットワークデバイス101に送った後、端末103は、message3についてのネットワークデバイス101のフィードバック(Feedback)をリッスンする。ネットワークデバイスは、情報4(message4)を端末103に送る。message4は、端末103のための競合解消識別子およびエアインターフェースパラメータ構成を含んでもよい。

端末103がネットワークデバイス101によって端末103に送られたmessage4を成功裡にリッスンする場合、端末103のランダムアクセスが成功し、端末103は、情報5(message5)をネットワークデバイス101に送ってもよいことに留意されたい。message5は主に、RRC確立完了コマンドまたは他の情報をネットワークデバイス101に送るためのものである。端末が、リスニングを介して、ネットワークデバイス101によって端末103に送られたmessage4を取得しない場合、端末103のランダムアクセスが失敗し、端末103は、ランダムアクセス時間の対応する最大量に達するまで、ネットワークデバイス101によって示されたバックオフパラメータに基づいてランダムアクセス手順を再開始してもよい。

ランダムアクセスタイプがNR R16規格において定義される「2-step RACH」であるランダムアクセス手順の場合、ランダムアクセスタイプが「4-step RACH」であるランダムアクセス手順に含まれる4つのステップは、実際には2つのステップに組み合わされる。より詳細には、ランダムアクセスタイプが「2-step RACH」であるランダムアクセス手順では、端末103はmessage1およびmessage3をネットワークデバイスに同時に送ることができ、同時に送られるmessage1およびmessage3は情報A(message A)とも呼ばれる。対応して、端末103は、messageAを受信した後に、ネットワークデバイス101からmessageAについてのフィードバックを受信する、すなわち、情報B(message B)を端末103に送ることができる。

帯域幅パート(bandwidth part、BWP)がNRシステムに導入される。BWPは、データ送信を実施するために端末によって使用される周波数領域リソースを示す。ネットワークデバイスは、シグナリングを使用して端末のためのアップリンクBWPおよびダウンリンクBWPを構成し、端末は、基地局によって構成されたBWP範囲内でのみデータ送信を実施することができる。ダウンリンク初期アクセス段階およびアップリンク初期アクセス段階では、端末が動作するアップリンクBWPおよびダウンリンクBWPは、それぞれ、UL initial BWPおよびDL initial BWPと呼ばれる。ランダムアクセスタイプが「4-step RACH」であるランダムアクセス手順の場合、message2およびmessage4はDL initial BWP上で送信され、message1およびmessage3はUL initial BWP上で送信される。ランダムアクセスタイプが「2-step RACH」であるランダムアクセス手順の場合、messageAはUL initial BWP上で送信され、messageBはDL initial BWP上で送信される。

端末は、代替として、別の様式でネットワークデバイスとのランダムアクセス手順を実施してもよく、すなわち、端末とネットワークデバイスとの間で実施されるランダムアクセス手順のランダムアクセスタイプは、「4-step RACH」および「2-step RACH」とは異なる別のランダムアクセスタイプをさらに含んでもよいことが理解され得る。

たとえば、端末およびネットワークデバイスは、別のランダムアクセスタイプのランダムアクセス手順を実施してもよい。別のランダムアクセスタイプのランダムアクセス手順は、ランダムアクセスタイプが「4-step RACH」であるランダムアクセス手順と同様である。説明しやすいように、別のランダムアクセスタイプは、本出願の実施形態では「4-step RACH&EDT (Early Data Transmission)」と呼ばれる。ランダムアクセスタイプが「4-step RACH&EDT」であるランダムアクセス手順とランダムアクセスタイプが「4-step RACH」であるランダムアクセス手順との間の差は主に、端末によってネットワークデバイスに送られたmessage3が端末によってネットワークデバイスに送られたサービスデータを含むという点にある。

たとえば、端末およびネットワークデバイスは、別のランダムアクセスタイプのランダムアクセス手順を実施してもよい。別のランダムアクセスタイプのランダムアクセス手順は、ランダムアクセスタイプが「2-step RACH」であるランダムアクセス手順と同様である。説明しやすいように、別のランダムアクセスタイプは、本出願の実施形態では「2-step RACH&EDT」と呼ばれる。ランダムアクセスタイプが「2-step RACH&EDT」であるランダムアクセス手順とランダムアクセスタイプが「2-step RACH」であるランダムアクセス手順との間の差は主に、端末によってネットワークデバイスに送られたmessageAが端末によってネットワークデバイスに送られたサービスデータを含むという点にある。

本出願の実施形態では、2つのタイプのランダムアクセス手順、すなわち、「4-step RACH&EDT」および「2-step RACH&EDT」は主に、RRC非アクティブ(RRC inactive)状態である端末に適用される。このようにして、RRC非アクティブ状態である端末は、RRC接続(RRC connected)状態に入るためにランダムアクセス手順を完了する前に、サービスデータを送信することができる。このことは、ネットワークデバイスのエアインターフェースリソースを節約し、端末の電力消費を低減し、データ送信遅延を低減することができる。2つのタイプのランダムアクセス手順「4-step RACH&EDT」および「2-step RACH&EDT」は、RRCアイドル(RRC idle)状態である端末にも適用され得ることが理解され得る。

結論として、ネットワークデバイスとのランダムアクセス手順を実施するために端末によってサポートされるランダムアクセスタイプは、端末の能力である。異なる端末は、異なるランダムアクセスタイプをサポートしてもよい。同じ端末は、上記のランダムアクセスタイプのうちの1つまたは複数をサポートしてもよい。Y1個のランダムアクセスタイプは、端末によってサポートされるランダムアクセスタイプに基づいて決定されてもよく、Y1は正の整数である。ネットワークデバイスの構成が、ネットワークデバイスによって実施されるY1個のランダムアクセスタイプのランダムアクセス手順をサポートする場合、端末によって実施されるネットワークデバイスとのランダムアクセス手順のランダムアクセスタイプは、Y1個のランダムアクセスタイプのうちの1つまたは複数であってもよい。

本出願の実施形態では、異なる端末は異なる帯域幅能力を有してもよく、Y2個の帯域幅タイプは端末の帯域幅能力に基づいて決定されてもよく、Y2は正の整数である。端末の帯域幅能力は、データ送信が端末とネットワークデバイスとの間で実施されるとき、端末によってネットワークデバイスに送られたデータを搬送するために/ネットワークデバイスからのデータを搬送するためにキャリアによって使用され得る最大帯域幅である。たとえば、端末が100MHzの最大帯域幅を有する周波数リソースを使用するキャリア上でデータをネットワークデバイスに送ることができる場合、端末のアップリンク帯域幅能力は100MHzであり、端末が100MHzの最大帯域幅を有する周波数リソースを使用するキャリア上でネットワークデバイスからのデータを受信することができる場合、端末のダウンリンク帯域幅能力は100MHzである。別の例では、端末が20MHzの最大帯域幅を有する周波数リソースを使用するキャリア上でデータをネットワークデバイスに送ることができる場合、端末のアップリンク帯域幅能力は20MHzであり、端末が20MHzの最大帯域幅を有する周波数リソースを使用するキャリア上でネットワークデバイスからのデータを受信することができる場合、端末のダウンリンク帯域幅能力は20MHzである。一般に、端末のアップリンク帯域幅能力およびダウンリンク帯域幅能力は同じである。したがって、端末のアップリンク帯域幅能力またはダウンリンク帯域幅能力は、端末の帯域幅能力として使用されてもよい。

たとえば、単一の端末の帯域幅能力は、5MHz、10MHz、20MHz、または100MHzであってもよい。5MHzまたは10MHzの帯域幅能力を有する端末の帯域幅タイプは通常、「NR_REDCAP type1」として表されることがあり、すなわち、5MHzまたは10MHzの帯域幅能力を有する端末は通常、NR_REDCAP type1端末と呼ばれることがある。いくつかの他の実施形態では、5MHzの帯域幅能力を有する端末および10MHzの帯域幅能力を有する端末は、2つの異なるタイプの端末として定義されることもある。20MHzの帯域幅能力を有する端末の帯域幅タイプは通常、NR_REDCAP type2として表されることがあり、すなわち、20MHzの帯域幅能力を有する端末は通常、NR_REDCAP type2端末と呼ばれることがある。100MHzの帯域幅能力を有する端末の帯域幅タイプは通常、NR_legacyとして表されることがあり、すなわち、100MHzの帯域幅能力を有する端末は通常、NR_legacy端末と呼ばれることがある。言い換えれば、3つの帯域幅タイプ、NR_REDCAP type1、NR_REDCAP type2、およびNR_legacyが決定されてもよい。

本出願の実施形態では、端末の端末タイプは、端末の帯域幅タイプおよび端末によってサポートされるランダムアクセスタイプに関係し、N個の端末タイプは、端末の帯域幅タイプおよび/またはランダムアクセスタイプに基づいて決定されてもよく、Nは正の整数である。より詳細には、N個の端末タイプは、Y2個の帯域幅タイプおよび/またはY1個のランダムアクセスタイプに基づいて決定されてもよい。同じ端末の場合、端末は1つまたは複数のランダムアクセスタイプをサポートし得るので、同じ端末は上記のN個の端末タイプのうちの1つまたは複数に対応し得ることに留意されたい。たとえば、端末タイプT9は、帯域幅タイプ「NR_legacy」およびランダムアクセスタイプ4-step RACHに基づいて決定されてもよく、端末タイプT10は、帯域幅タイプ「NR_legacy」およびランダムアクセスタイプ2-step RACHに基づいて決定されてもよい。端末タイプT9に対応する帯域幅タイプは端末タイプT10に対応する帯域幅タイプと同じであるが、端末タイプT9に対応するランダムアクセスタイプは端末タイプT10に対応するランダムアクセスタイプとは異なる。

可能な実装形態では、N個の端末タイプのうちのいずれか1つは、Y2個の帯域幅タイプのうちの1つに基づいて決定されてもよい。すなわち、Y2個の帯域幅タイプは総量Nの端末タイプと1対1の対応になっており、Y2個の帯域幅タイプはN個の端末タイプと1対1の対応になっているので、帯域幅タイプの総量Y2は同じである。

たとえば、以下のTable 1(表1)を参照されたい。3つの端末タイプ「P1」、「P2」、および「P3」は、3つの帯域幅タイプ「NR_REDCAP type1」、「NR_REDCAP type2」、および「NR_legacy」に基づいて決定されてもよい。

Table 1(表1)では、帯域幅タイプ「NR_legacy」に基づいて決定された端末タイプは「P1」であり、帯域幅タイプ「NR_REDCAP type1」に基づいて決定された端末タイプは「P2」であり、帯域幅タイプ「NR_REDCAP type2」に基づいて決定された端末タイプは「P3」である。

可能な実装形態では、N個の端末タイプのうちのいずれか1つは、Y2個の帯域幅タイプのうちの1つおよびY1個のランダムアクセスタイプのうちの1つに基づいて決定されてもよい。具体的に言えば、端末タイプの総量Nは、帯域幅タイプの総量Y2とランダムアクセスタイプの総量Y1の積である。

たとえば、以下のTable 2(表2)を参照されたい。合計12個の端末タイプT1～T12は、3つの帯域幅タイプ「NR_REDCAP type1」、「NR_REDCAP type2」、および「NR_legacy」ならびに4つのランダムアクセスタイプ「4-step RACH」、「4-step RACH&EDT」、「2-step RACH」、および「2-step RACH&EDT」に基づいて決定され得る。

Table 2(表2)では、「NR_REDCAP type1」および「4-step RACH」に基づいて決定された端末タイプは「T1」であり、「NR_REDCAP type1」および「2-step RACH」に基づいて決定された端末タイプは「T2」であり、「NR_REDCAP type1」および「4-step RACH&EDT」に基づいて決定された端末タイプは「T3」であり、「NR_REDCAP type1」および「2-step RACH&EDT」に基づいて決定された端末タイプは「T4」であり、「NR_REDCAP type2」および「4-step RACH」に基づいて決定された端末タイプは「T5」であり、「NR_REDCAP type2」および「2-step RACH」に基づいて決定された端末タイプは「T6」であり、「NR_REDCAP type2」および「4-step RACH&EDT」に基づいて決定された端末タイプは「T7」であり、「NR_REDCAP type2」および「2-step RACH&EDT」に基づいて決定された端末タイプは「T8」であり、「NR_legacy」および「4-step RACH」に基づいて決定された端末タイプは「T9」であり、「NR_legacy」および「2-step RACH」に基づいて決定された端末タイプは「T10」であり、「NR_legacy」および「4-step RACH&EDT」に基づいて決定された端末タイプは「T11」であり、「NR_legacy」および「2-step RACH&EDT」に基づいて決定された端末タイプは「T12」である。

端末タイプは帯域幅タイプとランダムアクセスタイプの組合せを使用することによって表され得ることが理解され得る。たとえば、Table 2(表2)における端末タイプ「T12」は、「T12」を決定するためのものである、帯域幅タイプ「NR_legacy」およびランダムアクセスタイプ「2-step RACH&EDT」を含み得る。

以下では、一例を使用することによって、ネットワークデバイスと端末との間の通信の具体的なプロセスについて説明する。

本出願の実施形態で提供される技術的解決策によれば、ネットワークデバイスによってサポートされるN個の端末タイプは、少なくとも1つの帯域幅タイプおよび/または少なくとも1つのランダムアクセスタイプに基づいてフレキシブルに構成されてもよく、M個のRACHリソースセットはN個の端末タイプのために構成され、MおよびNは正の整数である。異なる帯域幅タイプの端末は、ランダムアクセス手順を開始するために、同じRACHリソースセットまたは異なるRACHリソースセットに基づいてランダムアクセス要求をネットワークデバイスに送ってもよい。このことは、様々な帯域幅タイプの端末がより効率的にネットワークデバイスに接続するのを助ける。

図3は、本出願の一実施形態によるランダムアクセス方法の概略フローチャートである。構成命令は、対応する通信装置によってネットワークデバイスに送られてもよく、かつ/または、対応する構成命令は、少なくとも以下のステップ301およびステップ303を実施するようにネットワークデバイスをトリガするために、入力デバイスによってネットワークデバイスに入力されてもよい。

ステップ301において、ネットワークデバイスは、M個のRACHリソースセットを決定する。

M個のRACHリソースセットはN個の端末タイプに対応し、MとNの両方は正の整数である。

M個のRACHリソースセットのうちのいずれか1つは、RACHの時間領域リソース、周波数領域リソース、または直交コードシーケンスリソースのうちの1つのリソースまたはそれらの組合せを含んでもよい。任意の2つの異なるRACHリソースセットに含まれるRACHリソースは、周波数領域リソース、時間領域リソース、および直交コードシーケンスリソースのうちの1つまたは複数において異なる。

N個の端末タイプは、端末の帯域幅タイプおよびランダムアクセスタイプに基づいて決定される。より詳細には、N個の端末タイプのうちのいずれか1つは、Y2個の帯域幅タイプのうちの1つに基づいて決定されてもよく、またはY2個の帯域幅タイプのうちの1つおよびY1個のランダムアクセスタイプのうちの1つに基づいて決定されてもよく、Y1およびY2は正の整数である。

ステップ303において、ネットワークデバイスは、RACH構成情報を少なくとも1つの端末に送る。

RACH構成情報はM個のRACHリソースセットを示し、M個のRACHリソースセットはランダムアクセス要求をネットワークデバイスに送るために少なくとも1つの端末によって使用され、少なくとも1つの端末のうちのいずれか1つの帯域幅タイプはN個の端末タイプを決定するための帯域幅タイプに属する。より詳細には、少なくとも1つの端末のうちのいずれか1つの帯域幅タイプは、Y2個の帯域幅タイプのうちの1つである。

可能な実装形態では、M個のRACHリソースセットのうちの1つについて、ネットワークデバイスは、RACHリソースセットに対応する少なくとも1つの端末タイプを決定し、少なくとも1つの端末タイプに基づいて、ランダムアクセス手順を実施する少なくとも1つの端末を決定し、次いで、構成情報を少なくとも1つの端末に送ってもよい。ネットワークデバイスは、ランダムアクセス手順におけるリソース構成がよりフレキシブルになり、リソース利用が改善されるように、端末の帯域幅タイプおよびランダムアクセスタイプに基づいてRACHリソースを割り振る。

図4は、本出願の一実施形態による別のランダムアクセス方法の概略フローチャートである。

ステップ401において、ネットワークデバイスは、M個のRACHリソースセットを決定する。

M個のRACHリソースセットはN個の端末タイプに対応し、MとNの両方は正の整数である。より詳細には、M個のRACHリソースセットのうちの1つは、N個の端末タイプのうちの1つまたは複数に対応する。

本明細書では、ネットワークデバイスは、M個のRACHリソースセットとN個の端末タイプとの間の対応をフレキシブルに構成してもよい。

以下では主に、本出願のこの実施形態におけるランダムアクセス方法について、ネットワークデバイスが3つの帯域幅タイプ、すなわち、「NR_REDCAP type1」、「NR_REDCAP type2」、および「NR_legacy」の端末に接続される場合があり、ネットワークデバイスが4つのランダムアクセスタイプ、すなわち、「4-step RACH」、「4-step RACH&EDT」、「2-step RACH」、および「2-step RACH&EDT」のランダムアクセス手順をサポートする一例を使用することによって、説明する。

可能な実装形態では、MはNに等しく、Mは1よりも大きい。言い換えれば、M個のRACHリソースセットはN個の端末タイプと1対1の対応になっており、ネットワークデバイスは、少なくとも異なる端末タイプに対して異なるRACHリソースセットを構成してもよい。この場合、異なる帯域幅タイプの端末は、異なるRACHリソースセットを使用してランダムアクセス手順を開始してもよく、同じ帯域幅タイプの端末は、ネットワークデバイスとの異なるランダムアクセスタイプのランダムアクセス手順を実施するために異なるRACHリソースを使用してもよい。任意の2つの端末の場合、任意の2つの端末は、2つの端末の帯域幅タイプにかかわらず、互いに影響を及ぼすことなしに、ネットワークデバイスとの同じランダムアクセスタイプまたは異なるランダムアクセスタイプのランダムアクセス手順を別々に実施してもよい。このことは、複数の帯域幅タイプの端末がより効率的にネットワークデバイスに接続するのを助ける。

たとえば、ネットワークデバイスは、以下のTable 3(表3)に記載されている12個のRACHリソースセットを決定してもよく、12個のRACHリソースセットは12個の端末タイプに対応する。

Table 3(表3)に記載されているように、端末タイプ「T1」に対応するRACHリソースセットは「RACH-R1」であり、端末タイプ「T2」に対応するRACHリソースセットは「RACH-R2」であり、端末タイプ「T3」に対応するRACHリソースセットは「RACH-R3」であり、端末タイプ「T4」に対応するRACHリソースセットは「RACH-R4」であり、端末タイプ「T5」に対応するRACHリソースセットは「RACH-R5」であり、端末タイプ「T6」に対応するRACHリソースセットは「RACH-R6」であり、端末タイプ「T7」に対応するRACHリソースセットは「RACH-R7」であり、端末タイプ「T8」に対応するRACHリソースセットは「RACH-R8」であり、端末タイプ「T9」に対応するRACHリソースセットは「RACH-R9」であり、端末タイプ「T10」に対応するRACHリソースセットは「RACH-R10」であり、端末タイプ「T11」に対応するRACHリソースセットは「RACH-R11」であり、端末タイプ「T12」に対応するRACHリソースセットは「RACH-R12」である。

可能な実装形態では、MはNよりも小さく、Mは1よりも大きい。この場合、異なる帯域幅タイプの端末は、ネットワークデバイスとの同じランダムアクセスタイプ/異なるランダムアクセスタイプのランダムアクセス手順を実施するために同じRACHリソースセットを使用してもよく、異なる帯域幅タイプの端末は、ネットワークデバイスとの同じランダムアクセスタイプ/異なるランダムアクセスタイプのランダムアクセス手順を実施するために異なるRACHリソースセットを使用してもよく、または、1つの帯域幅タイプの端末は、ネットワークデバイスとの異なるランダムアクセスタイプのランダムアクセス手順を実施するために同じRACHリソースセットを使用してもよい。このことは、RACHリソース利用を改善することができる。

たとえば、ネットワークデバイスは、以下のTable 4(表4)に記載されている7個のRACHリソースセットを決定してもよく、7個のRACHリソースセットは12個の端末タイプに対応する。

Table 4(表4)に記載されているように、RACHリソースセット「RACH-R1」に対応する端末タイプは「T1」および「T5」を含み、RACHリソースセット「RACH-R2」に対応する端末タイプは「T2」および「T6」を含み、RACHリソースセット「RACH-R3」に対応する端末タイプは「T3」および「T7」を含み、RACHリソースセット「RACH-R4」に対応する端末タイプは「T4」、「T8」、および「T12」を含み、RACHリソースセット「RACH-R5」に対応する端末タイプは「T9」であり、RACHリソースセット「RACH-R6」に対応する端末タイプは「T10」であり、RACHリソースセット「RACH-R7」に対応する端末タイプは「T11」である。

Table 4(表4)に記載されているように、帯域幅タイプがNR_REDCAP type1およびNR_REDCAP type2である端末について、ネットワークデバイスは、同じランダムアクセスタイプに対して同じRACHリソースセットのグループを構成してもよく、その結果として、帯域幅タイプがNR_REDCAP type1およびNR_REDCAP type2である端末がネットワークデバイスとの同じランダムアクセスタイプのランダムアクセス手順を別々に実施するとき、同じRACHリソースセットに含まれるRACHリソースが使用される。

たとえば、ネットワークデバイスは、以下のTable 5(表5)に記載されている8個のRACHリソースセットを決定してもよく、8個のRACHリソースセットは12個の端末タイプに対応する。

Table 5(表5)に記載されているように、RACHリソースセット「RACH-R1」に対応する端末タイプは「T1」であり、RACHリソースセット「RACH-R2」に対応する端末タイプは「T2」であり、RACHリソースセット「RACH-R3」に対応する端末タイプは「T3」であり、RACHリソースセット「RACH-R4」に対応する端末タイプは「T8」および「T12」を含み、RACHリソースセット「RACH-R5」に対応する端末タイプは「T5」および「T9」を含み、RACHリソースセット「RACH-R6」に対応する端末タイプは「T6」および「T10」を含み、RACHリソースセット「RACH-R7」に対応する端末タイプは「T7」および「T11」を含み、RACHリソースセット「RACH-R8」に対応する端末タイプは「T4」である。

Table 5(表5)に記載されているように、帯域幅タイプがNR_REDCAP type2およびNR_legacyである端末について、ネットワークデバイスは、同じランダムアクセスタイプに対して同じRACHリソースセットのグループを構成してもよく、その結果として、帯域幅タイプがNR_REDCAP type2およびNR_legacyである端末がネットワークデバイスとの同じランダムアクセスタイプのランダムアクセス手順を別々に実施するとき、同じRACHリソースセット内のRACHリソースが使用される。

2つのランダムアクセスタイプ「2-step RACH」および「2-step RACH&EDT」について、PUSCH上でmessageAにおいて搬送されるデータのボリュームは異なることが理解され得る。対応して、異なるPUSCHリソースセットは通常、2つのランダムアクセスタイプ「2-step RACH」および「2-step RACH&EDT」のランダムアクセス手順において使用される。

可能な実装形態では、同じ帯域幅タイプの端末について、ネットワークデバイスは、2つのランダムアクセスタイプ「2-step RACH」および「2-step RACH&EDT」に対して2つの異なるRACHリソースセットを構成してもよく、異なるRACHリソースセットは、異なるPUSCHリソースセットに関連付けられる。この場合、端末がmessageAをネットワークデバイスに送るとき、ネットワークデバイスは最初に、messageAのために使用されるRACHリソースが属するターゲットRACHリソースセットを決定し、次いで、ターゲットRACHリソースセットに関連付けられたPUSCHリソースセットを迅速に決定してもよい。

たとえば、ネットワークデバイスは、以下のTable 6(表6)に記載されている6個のRACHリソースセットを決定してもよく、6個のRACHリソースセットは12個の端末タイプに対応する。

Table 6(表6)に記載されているように、帯域幅タイプがNR_REDCAP type1、NR_REDCAP type2、およびNR_legacyであるすべての端末は、RACH-R2に含まれるRACHリソースを使用して、ネットワークデバイスとのランダムアクセスタイプ「2-step RACH」のランダムアクセス手順を実施してもよい。帯域幅タイプがNR_REDCAP type1、NR_REDCAP type2、およびNR_legacyであるすべての端末は、RACH-R4に含まれるRACHリソースを使用して、ネットワークデバイスとのランダムアクセスタイプ「2-step RACH」のランダムアクセス手順を実施してもよい。

可能な実装形態では、同じ帯域幅タイプの端末について、ネットワークデバイスは、2つのランダムアクセスタイプ「2-step RACH」および「2-step RACH&EDT」に対して同じRACHリソースセットを構成してもよく、RACHリソースセットは2つの異なるPUSCHリソースセットに関連付けられる。この場合、端末からmessageAを受信するとき、messageAのために使用されるRACHリソースが属するターゲットRACHリソースセットを決定した後、ネットワークデバイスは、ターゲットRACHリソースセットに対応する2つのPUSCHリソースセットに対してブラインド検出を実施してもよい。このことは、RACHリソースオーバーヘッドを低減し、RACHリソースについてのネットワーク統計値収集の複雑さを低減するのを助ける。

たとえば、ネットワークデバイスは、以下のTable 7(表7)に記載されている5個のRACHリソースセットを決定してもよく、5個のRACHリソースセットは12個の端末タイプに対応する。

Table 7(表7)に記載されているように、帯域幅タイプがNR_REDCAP type1、NR_REDCAP type2、およびNR_legacyであるすべての端末は、RACH-R2に含まれるRACHリソースを使用して、ネットワークデバイスとのランダムアクセスタイプ「2-step RACH」および「2-step RACH&EDT」のランダムアクセス手順を実施してもよい。

可能な実装形態では、Mは1に等しく、MはNよりも小さい。言い換えれば、ネットワークデバイスは、N個の端末タイプに対して完全に同じRACHリソースセットを構成してもよい。この場合、ネットワークデバイスのシグナリングオーバーヘッドを低減することができ、ネットワークデバイスによって実施されるRACHリソースについてのネットワーク統計値収集の複雑さを低減することができる。

たとえば、ネットワークデバイスは、以下のTable 8(表8)に記載されている1個のRACHリソースセットを決定してもよく、このRACHリソースセットは12個の端末タイプに対応する。

Table 8(表8)に記載されているように、端末タイプT1～T12はすべて、RACHリソースセット「RACH-R1」に対応し、NR_REDCAP type1、NR_REDCAP type2、およびNR_legacyの端末はすべて、ネットワークデバイスとのランダムアクセスタイプ「2-step RACH」、「2-step RACH&EDT」、4-step RACH、および4-step RACH&EDTのランダムアクセス手順を実施するために、RACH-R1に含まれるRACHリソースを使用してもよい。

可能な実装形態では、MはNに等しく、Mは1に等しい。言い換えれば、ネットワークデバイスは、ネットワークデバイスとの1つのみのランダムアクセスタイプのランダムアクセス手順を実施するために、1つのみの帯域幅タイプの端末をサポートする。

次いで、ステップ402において、ネットワークデバイスは、少なくとも1つのDL initial BWPおよび少なくとも1つのUL initial BWPを決定する。

1つのDL initial BWPはN個の端末タイプのうちの1つまたは複数に対応し、1つのUL initial BWPはN個の端末タイプのうちの1つまたは複数に対応する。1つのRACHリソースセットは1つまたは複数の端末タイプに対応するので、1つのDL initial BWPは1つまたは複数のRACHリソースセットに対応する。

本明細書では、DL initial BWPの量および各DL initial BWPの帯域幅がフレキシブルに構成されてもよく、UL initial BWPの量および各UL initial BWPの帯域幅がフレキシブルに構成されてもよい。加えて、少なくとも1つのDL initial BWPとN個の端末タイプとの間の対応および少なくとも1つのUL initial BWPとN個の端末タイプとの間の対応がフレキシブルに構成されてもよい。

可能な実装形態では、N個の端末タイプを決定するためのY2個の帯域幅タイプに基づいて、UL initial BWPの量、各UL initial BWPの帯域幅が決定されてもよく、DL initial BWPの量、および各DL initial BWPの帯域幅が決定されてもよい。

たとえば、2つのDL initial BWP、すなわち、第1のDL initial BWPおよび第2のDL initial BWPが構成されてもよい。第1のDL initial BWPの帯域幅は、3つの帯域幅タイプ、すなわち、NR_REDCAP type1、NR_REDCAP type2、およびNR_legacyの端末に対応する最小帯域幅能力5MHzであってもよい。第2のDL initial BWPの帯域幅は、5MHz以外の帯域幅、たとえば、20MHzであってもよい。

たとえば、3つのUL initial BWP、すなわち、第1のUL initial BWP、第2のUL initial BWP、および第3のUL initial BWPが構成されてもよい。第1のUL initial BWPの帯域幅は5MHzであってもよく、第2のUL initial BWPの帯域幅は20MHzであってもよく、第3のUL initial BWPの帯域幅は100MHzであってもよい。

たとえば、ネットワークデバイスは、Table 9(表9)に記載されている2つのDL initial BWPをさらに決定してもよく、2つのDL initial BWPは12個の端末タイプに対応する。

Table 9(表9)に記載されているように、4個の端末タイプ「T1」、「T2」、「T3」、および「T4」はすべて、帯域幅が5MHzである第1のDL initial BWPに対応し、8個の端末タイプ「T5」、「T6」、「T7」、「T8」、「T9」、「T10」、「T11」、および「T12」はすべて、帯域幅が20MHzである第2のDL initial BWPに対応する。

たとえば、ネットワークデバイスは、Table 10(表10)に記載されている3つのUL initial BWPをさらに決定してもよく、3つのUL initial BWPは12個の端末タイプに対応する。

Table 10(表10)に記載されているように、4個の端末タイプ「T1」、「T2」、「T3」、および「T4」はすべて、帯域幅が5MHzである第1のUL initial BWPに対応し、4個の端末タイプ「T5」、「T6」、「T7」、および「T8」はすべて、帯域幅が20MHzである第2のUL initial BWPに対応し、4個の端末タイプ「T9」、「T10」、「T11」、および「T12」はすべて、帯域幅が100MHzである第3のUL initial BWPに対応する。

DL initial BWPおよびUL initial BWPの量ならびに各DL initial BWPおよび各UL initial BWPの帯域幅は、代替として、別の形態で構成されてもよく、少なくとも1つのDL initial BWPとN個の端末タイプとの間の対応および少なくとも1つのUL initial BWPとN個の端末タイプとの間の対応は、代替として、別の形態で構成されてもよいことが理解され得る。

たとえば、1つのみのDL initial BWPおよび2つのUL initial BWPが構成されてもよい。可能な実装形態では、DL initial BWPの帯域幅は5MHzであり、DL initial BWPはN個の端末タイプに対応する。加えて、一方のUL initial BWPの帯域幅は5MHzであり、他方のUL initial BWPの帯域幅は20MHzである。対応して、12個の端末タイプT1～T12はすべて、帯域幅が5MHzであるDL initial BWPに対応し、4個の端末タイプ「T1」、「T2」、「T3」、および「T4」はすべて、帯域幅が5MHzであるUL initial BWPに対応し、8個の端末タイプ「T5」、「T6」、「T7」、「T8」、「T9」、「T10」、「T11」、および「T12」はすべて、帯域幅が20MHzであるUL initial BWPに対応する。

たとえば、2つのみの帯域幅タイプ、すなわち、NR_legacyおよびNR_REDCAP type2がある。対応して、8個の端末タイプ、すなわち、「T1」、「T2」、「T3」、「T4」、「T9」、「T10」、「T11」、および「T12」がある。可能な実装形態では、同様に、ネットワークデバイスは1つのみのDL initial BWPを構成し、2つのUL initial BWPを構成する。DL initial BWPの最大帯域幅は、20MHzであるように構成される。加えて、2つのUL initial BWPの中の第1のUL initial BWPの最大帯域幅は20MHzであるように構成されることが可能であり、2つのUL initial BWPの中の第2のUL initial BWPの最大帯域幅は20MHzよりも大きくなるように構成されることが可能である。対応して、「T1」、「T2」、「T3」、「T4」、「T9」、「T10」、「T11」、および「T12」はすべて、DL initial BWPに対応し、「T9」、「T10」、「T11」、および「T12」などの4個の端末タイプはすべて、第1のUL initial BWPに対応し、「T1」、「T2」、「T3」、および「T4」などの4個の端末タイプはすべて、第2のUL initial BWPに対応する。

たとえば、ネットワークデバイスは、代替として、1つのみのDL initial BWPおよび1つのUL initial BWPを構成してもよく、DL initial BWPとUL initial BWPの両方の帯域幅は5MHzである。DL initial BWPとUL initial BWPの両方は、N個の端末タイプに対応する。

次いで、ステップ403において、シグナリングは、少なくとも1つのDL initial BWPにおいて少なくとも1つの端末に送られる。

シグナリングは、限定はしないが、MACCEシグナリング、DCIシグナリング、SIB1シグナリング、およびRRCシグナリングのうちのいずれか1つまたは複数を含む。

可能な実装形態では、ネットワークデバイスは最初に、ネットワークデバイスによって決定されたDL initial BWPごとに、DL initial BWPに対応する様々な現在の端末タイプを決定し、次いで、各々が様々な現在の端末タイプに対応する現在のRACHリソースセットを決定し、次いで、DL initial BWPにおいてシグナリングを送ってもよく、シグナリングは構成情報を含み、構成情報は各現在のRACHリソースセットを含み、各現在の端末タイプは各現在のRACHリソースセットに対応し、UL initial BWPは各現在の端末タイプに対応する。

ネットワークデバイスによって決定されたM個のRACHリソースセット、少なくとも1つのUL initial BWP、および少なくとも1つのDL initial BWPがTable 4(表4)、Table 9(表9)、およびTable 10(表10)に記載されている構成を満足する一例を依然として使用して、以下では、図5を参照しながら、ネットワークデバイスが構成情報を少なくとも1つの端末に送るプロセスについてさらに説明する。図5に示されているように、ネットワークデバイスは、帯域幅が5MHzであるDL initial BWPにおいて、シグナリング1を帯域幅タイプがNR_REDCAP type1である少なくとも1つの端末にブロードキャストし、帯域幅が20MHzであるDL initial BWPにおいて、シグナリング2を帯域幅タイプがNR_REDCAP type2および/またはNR_legacyである少なくとも1つの端末にブロードキャストしてもよい。

シグナリング1における構成情報は、以下、すなわち、現在のRACHリソースセットRACH-R1、RACH-R1に対応する現在の端末タイプT1、およびT1に対応する第1のUL initial BWPと、現在のRACHリソースセットRACH-R2、RACH-R2に対応する現在の端末タイプT2、およびT2に対応する第1のUL initial BWPと、現在のRACHリソースセットRACH-R3、RACH-R3に対応する現在の端末タイプT3、およびT3に対応する第1のUL initial BWPと、現在のRACHリソースセットRACH-R4、RACH-R4に対応する現在の端末タイプT4、およびT4に対応する第1のUL initial BWPとを示してもよい。

たとえば、シグナリング1は、以下のTable 11(表11)に記載されている構成情報を含んでもよい。

シグナリング2における構成情報は、以下、すなわち、現在のRACHリソースセットRACH-R1、RACH-R1に対応する現在の端末タイプT5、およびT5に対応する第2のUL initial BWPと、現在のRACHリソースセットRACH-R2、RACH-R2に対応する現在の端末タイプT6、およびT6に対応する第2のUL initial BWPと、現在のRACHリソースセットRACH-R3、RACH-R3に対応する現在の端末タイプT7、およびT7に対応する第2のUL initial BWPと、現在のRACHリソースセットRACH-R4、RACH-R4に対応する現在の端末タイプT8およびT12、T8に対応する第2のUL initial BWP、ならびにT12に対応する第3のUL initial BWPと、現在のRACHリソースセットRACH-R5、RACH-R5に対応する現在の端末タイプT9、およびT9に対応する第3のUL initial BWPと、現在のRACHリソースセットRACH-R6、RACH-R6に対応する現在の端末タイプT10、およびT10に対応する第3のUL initial BWPと、現在のRACHリソースセットRACH-R6、RACH-R6に対応する現在の端末タイプT11、およびT11に対応する第3のUL initial BWPとを示してもよい。

たとえば、シグナリング2は、以下のTable 12(表12)に記載されている構成情報を含んでもよい。

対応して、帯域幅タイプがNR_REDCAP type1である端末は、帯域幅が5MHzである第1のDL initial BWPにおいてネットワークデバイスからシグナリング1を受信してもよく、帯域幅タイプがNR_REDCAP type2またはNR_legacyである端末は、帯域幅が20MHzである第2のDL initial BWPにおいてネットワークデバイスからシグナリング2を受信してもよい。

ネットワークデバイスは、1個のシグナリングにおいてM個のRACHリソースセットのうちのいくつかを構成してもよく、または複数個のシグナリングにおいてRACHリソースセットのうちのいくつかを構成してもよいことが理解され得る。言い換えれば、1つのRACHリソースセットについて、ネットワークデバイスは、1つまたは複数のDL initial BWPにおいて、RACHリソースセットを含む構成情報を1つまたは複数の帯域幅タイプの端末に送ってもよい。

たとえば、RACH-R1に対応する端末タイプはT1およびT5を含み、T1に対応するDL initial BWPは第1のDL initial BWPであり、T5に対応するDL initial BWPは第2のDL initial BWPである。ネットワークデバイスは、シグナリング1およびシグナリング2に含まれる構成情報においてRACH-R1を構成してもよい。次いで、ネットワークデバイスは、帯域幅が5MHzである第1のDL initial BWPにおいて、シグナリング1を帯域幅タイプがNR_REDCAP type1である端末にブロードキャストし、帯域幅が20MHzである第2のDL initial BWPにおいて、シグナリング2を帯域幅がNR_REDCAP type2およびNR_legacyである端末にブロードキャストしてもよい。このようにして、RACH-R1を含む構成情報は、第1のDL initial BWPおよび第2のDL initial BWPにおいて、帯域幅タイプがNR_REDCAP type1およびNR_REDCAP type2である端末に送られる。

いくつかの実施形態では、ネットワークデバイスによって決定されたM個のRACHリソースセット、M個のRACHリソースセットとN個の端末タイプとの間の対応、およびN個の端末タイプと少なくとも1つのUL initial BWPとの間の対応は、同じシグナリングにおいて構成されてもよい。対応して、ネットワークデバイスは、同じDL initial BWPまたは異なるDL initial BWPにおいてシグナリングをY2個の帯域幅タイプの端末に送ってもよい。

ステップ404において、端末は、端末によって受信されたシグナリングに含まれるRACH構成情報および端末のターゲット端末タイプに基づいて、ランダムアクセス要求をネットワークデバイスに送るために端末によって使用されるターゲットRACHリソースセットを決定する。

ステップ404を実施する端末は、ネットワークデバイスからシグナリングを受信しており、ネットワークデバイスに接続するためにネットワークデバイスとのランダムアクセス手順を実施する必要がある端末であることが理解され得る。上記で説明されたように、端末の帯域幅タイプは、NR_REDCAP type1、NR_REDCAP type2、またはNR_legacyであってもよく、端末は、ネットワークデバイスとの「4-step RACH」、「2-step RACH」、「4-step RACH&EDT」、および「2-step RACH&EDT」などの複数のタイプのランダムアクセス手順を実施してもよい。

たとえば、端末は、端末のターゲット端末タイプに基づいて、端末によって受信されたシグナリングに含まれる構成情報から、ターゲット端末タイプに対応するRACHリソースセットを決定してもよい。決定されたRACHリソースセットは、ランダムアクセス要求をネットワークデバイスに送るために端末によって使用されるターゲットRACHリソースセットである。

いくつかの実施形態では、端末は、ユーザ構成を通じてまたは別の様式で、端末とネットワークデバイスとの間のランダムアクセス手順を実施するためのランダムアクセスタイプを選択し、次いで、選択されたランダムアクセスタイプおよび端末の帯域幅タイプに基づいて、端末のターゲット端末タイプを決定してもよい。

いくつかの実施形態では、端末によって受信された構成情報は、端末およびネットワークデバイスによって実施されるランダムアクセス手順のランダムアクセスタイプを示してもよい。端末は、構成情報の指示、端末の帯域幅タイプ、およびサポートされるランダムアクセスタイプに基づいて、ランダムアクセス要求を送るためのターゲットRACHリソースセットを決定してもよい。たとえば、端末の帯域幅タイプはNR_REDCAP type1であり、端末はネットワークデバイスからシグナリング1を受信してもよい。選択されたランダムアクセスタイプが「4-step RACH」であるか、またはシグナリング1に含まれる構成情報が、NR_REDCAP type1端末によって実施されるランダムアクセス手順のランダムアクセスタイプが「4-step RACH」であることを示す場合、端末は、端末の帯域幅タイプ「NR_REDCAP type1」およびランダムアクセスタイプ「4-step RACH」に基づいて、対応するRACHリソースセットが「RACH-R1」であると決定し、すなわち、ランダムアクセス要求をネットワークデバイスに送るために端末によって使用されるターゲットRACHリソースセットが「RACH-R1」であると決定してもよい。

ネットワークデバイスは、端末のターゲット端末タイプに対してRACHリソースセットを構成しないことがあることに留意されたい。言い換えれば、端末は、ネットワークデバイスからのシグナリングに含まれる構成情報から、ターゲット端末タイプに対応するRACHリソースセットを決定するのに失敗することがある。この場合、端末は、構成情報から、別の端末タイプのためにネットワークデバイスによって構成されたRACHリソースセットを決定し、RACHリソースセットから、ランダムアクセス要求をネットワークデバイスに送るために端末によって使用されるターゲットRACHリソースを決定してもよい。

たとえば、1つのランダムアクセスタイプ「4-step RACH」ならびに2つの帯域幅タイプ「NR_legacy」および「NR_REDCAP type2」によって決定された2つの端末タイプ「T9」および「T5」について、端末が、ネットワークデバイスからのシグナリングに含まれる構成情報から、「T5」に対応するRACHリソースセットを決定するのに失敗したが、構成情報が「T9」に対応するRACHリソースセットを含む場合、端末は、「T9」に対応するRACHリソースセットを、ランダムアクセス要求をネットワークデバイスに送るために端末によって使用されるターゲットRACHリソースとして決定してもよい。

ステップ405において、端末は、端末によって受信されたシグナリングに含まれる構成情報から、ターゲット端末タイプに対応するターゲットUL initial BWPを決定する。

たとえば、端末の帯域幅タイプはNR_REDCAP type1であり、ネットワークデバイスからのシグナリング1が受信されてもよい。端末は、シグナリング1に含まれる構成情報から、ターゲット端末タイプ「T1」に対応するUL initial BWPが「第1のUL initial BWP」であると決定してもよい。

ステップ406において、端末は、ターゲットRACHリソースセットから、ランダムアクセス要求をネットワークデバイスに送るために端末によって使用されるターゲットRACHリソースを決定する。

ステップ407において、端末は、ターゲットRACHリソースに基づいて、ターゲット端末タイプに対応するターゲットUL initial BWPにおいてランダムアクセス要求をネットワークデバイスに送る。

ランダムアクセス要求はmessage1またはmessageAを介して送られる。

ランダムアクセス要求は、端末によってサポートされるランダムアクセスタイプに依存することが理解され得る。たとえば、端末によってサポートされるランダムアクセスタイプが「4-step RACH」または「4-step RACH&EDT」である場合、ランダムアクセス要求はmessage1を介して送られ、端末によってサポートされるランダムアクセスタイプが「2-step RACH」である場合、ランダムアクセス要求はサービスデータが送られないmessageAを介して送られ、端末によってサポートされるランダムアクセスタイプが「2-step RACH&EDT」である場合、ランダムアクセス要求はサービスデータが送られるmessageAを介して送られる。

message1およびmessageAは、対応するUL initial BWPにおいて送信されることに留意されたい。DL initial BWPの最大帯域幅は既存の通信プロトコルにおいて20MHzに制限されており、UL initial BWPの最大帯域幅は20MHzよりも大きくてもよい。しかしながら、端末の帯域幅能力は20MHzよりも大きくてもよく、または20MHzよりも小さくてもよく、ネットワークデバイスは、message3/messageAのための少なくとも2つのPUSCHリソースセットを構成してもよい。

ネットワークデバイスが後続のプロセスにおいてmessage1/messageAに応答するとき、message2、message3、message4、およびmessageBをスケジュールするための送信帯域幅が端末の帯域幅能力よりも小さいことを確実にするために、可能な実装形態では、端末によってネットワークデバイスに送られたランダムアクセス要求は、端末の帯域幅タイプ/端末タイプ/帯域幅能力を含んでもよい。いくつかの実施形態では、端末によってネットワークデバイスに送られたランダムアクセス要求は、端末によってサポートされるランダムアクセスタイプをさらに含んでもよい。

ランダムアクセス要求がmessageAを介して送られるとき、端末の帯域幅タイプ/端末タイプ/帯域幅能力は、PUSCH上で搬送されるデータとしてネットワークデバイスに報告されてもよい。

特定の例では、初期アクセスシナリオにおいて、端末がmessageAをネットワークデバイスに送るとき、端末はPUSCH上でRRCシグナリング(たとえば、RRCSetupRequestシグナリング)をネットワークデバイスに送ってもよい。RRCシグナリングは新たに追加された情報要素(information element、IE)を含み、IEは端末の帯域幅タイプ/端末タイプ/帯域幅能力を含む。別の特定の例では、EDTシナリオにおいて、端末がmessageAをネットワークデバイスに送るとき、端末はPUSCH上でMACCEシグナリングをネットワークデバイスに送ってもよく、MACCEシグナリングは端末の帯域幅タイプ/端末タイプ/帯域幅能力を含む。

ステップ408において、ネットワークデバイスは、端末からのランダムアクセス要求に対応するmessage1またはmessageAを検出する。

上記で説明されたように、単一のネットワークデバイスは、「4-step RACH」/「4-step RACH&EDT」のランダムアクセス手順をサポートし、「2-step RACH」/「2-step RACH&EDT」のランダムアクセス手順をサポートしてもよい。

2つのランダムアクセスタイプ「4-step RACH」および「4-step RACH&EDT」の場合、端末は、message1を介してランダムアクセス要求を送り、ネットワークデバイスは、message1を送るためのRACHリソースを検出してmessage1を取得し、message1を送るためのPRACH上で報告された端末の帯域幅タイプ/帯域幅能力/端末タイプを取得し、message1の検出を完了してもよい。

2つのランダムアクセスタイプ「2-step RACH」および「2-step RACH&EDT」の場合、端末は、messageAを介してランダムアクセス要求を送り、ネットワークデバイスは、messageAの検出を完了するために、messageAのPRACHおよびmessageAのPUSCHを検出する必要がある。

上記で説明されたように、2つのランダムアクセスタイプ「2-step RACH」および「2-step RACH&EDT」について、messageAにおいて搬送されるデータのボリュームは異なる。2つのランダムアクセスタイプ「2-step RACH」および「2-step RACH&EDT」に対して2つの異なるRACHリソースセットが構成され、異なるRACHリソースセットが異なるPUSCHリソースセットに関連付けられる場合、ネットワークデバイスが端末からmessageAを受信するとき、ネットワークデバイスは最初に、messageAを送るためのターゲットRACHリソースが属するターゲットRACHリソースセットを決定し、次いで、messageAに対応するターゲットRACHリソースセットに関連付けられたPUSCHリソースセットを迅速に決定してもよい。ネットワークデバイスが2つのランダムアクセスタイプ「2-step RACH」および「2-step RACH&EDT」に対して同じRACHリソースセットを構成する場合、RACHリソースセットは2つの異なるPUSCHリソースセットに関連付けられる。端末からmessageAを受信するとき、ネットワークデバイスは、message1を送るためのRACHリソースが属するターゲットRACHリソースセットを決定した後、ターゲットRACHリソースセットに対応する2つのPUSCHリソースセットに対してブラインド検出を実施してもよい。

現在受信されたランダムアクセス要求に対応するランダムアクセスタイプが「4-step RACH」/「4-step RACH&EDT」であるかまたは「2-step RACH」/「2-step RACH&EDT」であるかを示すために、可能な実装形態では、ネットワークデバイスは、「4-step RACH」/「4-step RACH&EDT」および「2-step RACH」/「2-step RACH&EDT」に対して異なるRACHリソースセットを構成してもよい。このようにして、ネットワークデバイスは、ネットワークデバイスによって検出されたPRACHに基づいて、ネットワークデバイスによって受信されたランダムアクセス要求に対応するランダムアクセスタイプを決定し、後続の対応するランダムアクセス手順を実装する。このことは、ネットワークデバイスによってPUSCHを検出する複雑さを低減するのを助ける。

可能な実装形態では、代替として、ネットワークデバイスは、「4-step RACH」/「4-step RACH&EDT」および「2-step RACH」/「2-step RACH&EDT」に対して同じPRACHリソースを構成してもよい。このことは、PRACHリソースオーバーヘッドを低減するのを助ける。

可能な実装形態では、端末はさらに、端末がネットワークデバイスとのランダムプロセスを完了し、RRC接続状態に入った後に、端末の帯域幅能力/帯域幅タイプ/端末タイプを再報告してもよい。

ステップ409において、ネットワークデバイスは、ネットワークデバイスによって検出されたmessage1またはmessageAに基づいて、端末デバイスからのランダムアクセス要求に応答する。

本明細書では、端末デバイスからmessage1またはmessageAへの応答が行われる。

可能な実装形態では、ネットワークデバイスは、ターゲットRACHリソースセットに対応するPUSCHリソースセットに基づいて、messageAの中のPUSCH上で搬送された端末の帯域幅タイプ/帯域幅能力/端末タイプを取得してもよく、または、messageAのPRACHに基づいて、端末によって報告された帯域幅タイプ/帯域幅能力/端末タイプを取得し、端末からのランダムアクセス要求に応答するために端末の帯域幅タイプ/帯域幅能力/端末タイプに基づいてmessageBをスケジュールしてもよい。

可能な実装形態では、ネットワークデバイスは、message1を送るためのPRACH上で報告された端末の帯域幅タイプ/帯域幅能力/端末タイプを取得し、端末からのランダムアクセス要求に応答するために端末の帯域幅タイプ/帯域幅能力/端末タイプに基づいてmessage2およびmessage3をスケジュールしてもよい。

同じランダムアクセス機会(RACH occasion、RO)上のランダムアクセス応答(random access response、RAR)の場合、ネットワークデバイスは、ランダムアクセス無線ネットワーク一時識別子(random access-radio network temporary identifier、RA-RNTI)によってスクランブルされた巡回冗長検査(cyclic redundancy check、CRC)を伴うダウンリンク制御情報(downlink control information、DCI)を使用してPDSCHをスケジュールしてもよく、PDSCHは、ROの全部または一部のランダムアクセス要求に対するRARを搬送する。ROはRACH preambleを送り、受信するための時間周波数リソースを指すことを理解されたい。ネットワークデバイスは、同じRO上で複数の相互に直交するpreamblesを構成してもよく、複数の端末デバイスは、同じpreambleまたは異なるpreamblesを使用して同じRO上でランダムアクセスを実施してもよい。ROリソース上での検出を通じて、端末デバイスによって送られたpreamblesを取得した場合、ネットワークデバイスは、RAR、すなわち、message2またはmessageBを端末デバイスに送る。1つのROは1つのみのRA-RNTIに関連付けられ、異なるROは異なるRA-RNTIに関連付けられる。

可能な実装形態では、ネットワークデバイスは、異なる端末タイプの端末に対して同じRACH時間領域リソースおよび同じRACH周波数領域リソースを構成するが、異なる周波数領域リソース、すなわち、preambles、すなわち、同じRO上の異なるpreambleを構成し、端末タイプは、ランダムアクセスタイプおよび/または端末帯域幅タイプを含む。ネットワークデバイスは、異なるタイプの端末のRAR上でグループ送信を実施してもよく、すなわち、複数の異なるPDSCH上で異なるタイプの端末のRARを送信してもよい。異なるPDSCHは、異なるRA-RNTIによってスクランブルされたCRCを伴うDCIを使用してスケジュールされてもよい。RA-RNTIは、RACHの時間リソース、周波数リソース、キャリアリソース、および端末タイプ識別子を使用して計算されてもよい。考えられるRA-RNTI計算様式は、RA-RNTI=1+s_id+14×t_id+14×80×f_id+14×80×8×ul_carrier_id+UE_type_idである。s_idは、ROの第1の直交周波数分割多重(orthogonal frequency division multiplexing、OFDM)シンボルのインデックスであり、t_idは、無線データフレーム内のROの第1のスロットのインデックスであり、f_idは、周波数領域内のROのインデックスであり、ul_carrier_idは、preambleを送るためのアップリンクキャリアのインデックスであり、UE_type_idは、preambleを送る端末の端末タイプ識別子である。本発明の解決策では、PRACHまたはpreambleを送るプロセスは、異なるアップリンクキャリア、たとえば、NRアップリンクキャリアおよびNR補助アップリンク(Supplementary Uplink、SUL)キャリア上で実施されてもよいことに留意されたい。異なるアップリンクキャリア上でpreambleを送る端末の場合、端末に対応するRARのRA-RNTIは、異なるアップリンクキャリアインデックス識別子を使用して計算される。

上記の方法実施形態と同じ概念に基づいて、図6に示されているように、本出願の一実施形態は通信装置600をさらに提供する。通信装置600は、ネットワークデバイスであってもよく、またはネットワークデバイスにおいて展開されたモジュール、チップ、もしくはシステムオンチップであってもよい。通信装置600は、M個のRACHリソースセットを決定することであって、M個のRACHリソースセットがN個の端末タイプに対応し、N個の端末タイプが端末の帯域幅タイプおよび/またはランダムアクセスタイプに基づいて決定され、MおよびNが正の整数である、決定することを行うように構成された処理ユニット601と、RACH構成情報を少なくとも1つの端末に送ることであって、RACH構成情報がM個のRACHリソースセットを示し、M個のRACHリソースセットがランダムアクセス要求をネットワークデバイスに送るために少なくとも1つの端末によって使用され、少なくとも1つの端末のうちのいずれか1つの帯域幅タイプがN個の端末タイプを決定するための帯域幅タイプに属する、送ることを行うように構成されたトランシーバユニット602とを含む。

可能な実装形態では、処理ユニット601は、M個のRACHリソースセットのうちの1つについて、RACHリソースセットに対応する少なくとも1つの端末タイプを決定し、少なくとも1つの端末タイプに基づいて、ランダムアクセス手順を実施する少なくとも1つの端末デバイスを決定するように構成される。トランシーバユニット602は、構成情報を少なくとも1つの端末デバイスに送るように構成される。ネットワークデバイスは、ランダムアクセス手順におけるリソース構成がよりフレキシブルになり、リソース利用が改善されるように、端末の帯域幅タイプおよびランダムアクセスタイプに基づいてRACHリソースを割り振る。

可能な実装形態では、トランシーバユニット602は特に、少なくとも1つのDL initial BWPにおいてRACH構成情報を少なくとも1つの端末に送るように構成される。

可能な実装形態では、トランシーバユニット602は特に、シグナリングを少なくとも1つの端末に送るように構成され、シグナリングはRACH構成情報を含み、シグナリングは、以下のタイプのシグナリング、すなわち、MACCEシグナリング、DCIシグナリング、RRCシグナリング、およびSIB1シグナリングのうちの少なくとも1つを含む。

可能な実装形態では、トランシーバユニット602は、少なくとも1つの端末の中の現在の端末からランダムアクセス要求を受信するようにさらに構成され、処理ユニット601は、ランダムアクセス要求に対応するターゲットRACHリソースセットを決定し、ターゲットRACHリソースセットに対応するPUSCHリソースセットに基づいてランダムアクセス要求に応答するようにさらに構成される。

上記の方法実施形態と同じ概念に基づいて、図7に示されているように、本出願の一実施形態は通信装置700をさらに提供する。通信装置700は、端末であってもよく、または端末において展開されたモジュール、チップ、もしくはシステムオンチップであってもよい。通信装置700は、ネットワークデバイスからRACH構成情報を受信することであって、RACH構成情報がM個のRACHリソースセットを示し、M個のRACHリソースセットがN個の端末タイプに対応し、N個の端末タイプが端末の帯域幅タイプおよび/またはランダムアクセスタイプに基づいて決定され、MおよびNが正の整数である、受信することを行うように構成されたトランシーバユニット701と、構成情報に基づいて、ランダムアクセス要求をネットワークデバイスに送るために現在の端末によって使用されるターゲットRACHリソースセットを決定することであって、現在の端末の帯域幅タイプがN個の端末タイプを決定するための帯域幅タイプに属する、決定することを行うように構成された処理ユニット702とを含む。

可能な実装形態では、トランシーバユニット701は特に、ネットワークデバイスからシグナリングを受信するように構成され、シグナリングは構成情報を含み、シグナリングは、以下のタイプのシグナリング、すなわち、MACCEシグナリング、DCIシグナリング、SIB1シグナリング、およびRRCシグナリングのうちの少なくとも1つを含む。

可能な実装形態では、処理ユニット702は特に、RACH構成情報および現在の端末のターゲット端末タイプに基づいて、ランダムアクセス要求をネットワークデバイスに送るために現在の端末によって使用されるターゲットRACHリソースセットを決定するように構成され、現在の端末のターゲット端末タイプは、現在の端末によってサポートされるランダムアクセスタイプおよび現在の端末の帯域幅タイプに基づいて決定される。

可能な実装形態では、RACH構成情報は、N個の端末タイプが少なくとも1つのUL initial BWPに対応することをさらに示し、処理ユニット702は、構成情報に基づいて、ターゲット端末タイプに対応するターゲットUL initial BWPを決定するようにさらに構成され、トランシーバユニット701は、ターゲットRACHリソースセットに基づいてターゲットUL initial BWP上でランダムアクセス要求をネットワークデバイスに送るようにさらに構成される。

通信装置600がネットワークデバイスであり、通信装置700が端末であるとき、トランシーバユニット602およびトランシーバユニット701は無線周波数回路であってもよいことに留意されたい。通信装置600がメモリを含み、メモリがコンピュータ命令を記憶するように構成されるとき、処理ユニット601はメモリに通信可能に接続され、処理ユニット601はメモリに記憶されたコンピュータ命令を実行し、その結果として、通信装置600は本出願のいずれかの実施形態によるネットワークデバイスによって実施される方法を実施する。通信装置700がメモリを含み、メモリがコンピュータ命令を記憶するように構成されるとき、処理ユニット702はメモリに通信可能に接続され、処理ユニット702はメモリに記憶されたコンピュータ命令を実行し、その結果として、通信装置700は、本出願のいずれかの実施形態による端末によって実施される方法を実施する。処理ユニット601および処理ユニット702は各々、汎用中央処理ユニット(CPU)、マイクロプロセッサ、または特定用途向け集積回路(application specific Integrated circuit、ASIC)であってもよい。

通信装置600がネットワークデバイスにおいて展開されるチップであり、通信装置700が端末において展開されるチップであるとき、トランシーバユニット602およびトランシーバユニット701は各々、入力/出力インターフェース、ピン、回路などであってもよいことに留意されたい。通信装置600がメモリを含み、メモリがコンピュータ命令を記憶するように構成されるとき、処理ユニット601はメモリに通信可能に接続され、処理ユニット601はメモリに記憶されたコンピュータ命令を実行し、その結果として、ネットワークデバイス内のチップは本出願のいずれかの実施形態によるネットワークデバイスによって実施される方法を実施する。通信装置700がメモリを含み、メモリがコンピュータ命令を記憶するように構成されるとき、処理ユニット702はメモリに通信可能に接続され、処理ユニット702はメモリに記憶されたコンピュータ命令を実行し、その結果として、端末内のチップは本出願のいずれかの実施形態による端末によって実施される方法を実施する。随意に、メモリは、チップ内の記憶ユニット、たとえば、レジスタまたはキャッシュである。メモリは、代替として、ネットワークデバイス/端末内のチップの外に位置する、読取り専用メモリ(read-only memory、ROM)、静的な情報および命令を記憶することができる別のタイプの静的な記憶デバイス、またはランダムアクセスメモリ(random access memory、RAM)などの記憶ユニットであってもよい。

対応して、本出願の一実施形態は、本出願のいずれかの実施形態で提供される通信装置600および本出願のいずれかの実施形態で提供される通信装置700を含む通信システムをさらに提供する。

好都合で簡単な説明のために、通信装置600、通信装置700、通信装置600が展開されるネットワークデバイス、または通信装置700が展開される端末の具体的なワーキングプロセスについては、上記の方法実施形態における対応するプロセスを参照することが当業者によって明確に理解され得る。詳細は再び本明細書で説明されない。

上記の方法実施形態と同じ概念に基づいて、図8に示されているように、本出願の一実施形態は通信装置800をさらに提供する。通信装置800は、図3または図4に示されている方法においてネットワークデバイスによって実施されるステップを実施することができることを理解されたい。繰返しを避けるために、詳細は再び本明細書で説明されない。通信装置800は、
プログラムを記憶するように構成されたメモリ801と、
別のデバイスと通信するように構成された通信インターフェース802と、
メモリ801内のプログラムを実行するように構成されたプロセッサ803とを含み、プログラムが実行されるとき、プロセッサ803は、M個のRACHリソースセットを決定することであって、M個のRACHリソースセットがN個の端末タイプに対応し、N個の端末タイプが端末の帯域幅タイプおよび/またはランダムアクセスタイプに基づいて決定され、MおよびNが正の整数である、決定することと、通信インターフェース802を通じて、RACH構成情報を少なくとも1つの端末に送ることであって、RACH構成情報がM個のRACHリソースセットを示し、M個のRACHリソースセットがランダムアクセス要求をネットワークデバイスに送るために少なくとも1つの端末によって使用され、少なくとも1つの端末のうちのいずれか1つの帯域幅タイプがN個の端末タイプを決定するための帯域幅タイプに属する、送ることとを行うように構成される。

図8に示されている通信装置800は、チップまたは回路、たとえば、ネットワークデバイスに配設され得るチップまたは回路であってもよいことを理解されたい。通信インターフェース802は、代替としてトランシーバであってもよい。トランシーバは、受信機および送信機を含む。さらに、通信装置800は、バスシステムをさらに含んでもよい。

プロセッサ803、メモリ801、受信機、および送信機は、バスシステムを通じて接続される。プロセッサ803は、メモリ801に記憶された命令を実行し、信号を受信するように受信機を制御するとともに信号を送るように送信機を制御し、本出願のいずれかの実施形態で提供されるランダムアクセス方法においてネットワークデバイスによって実施されるステップを完了するように構成される。受信機および送信機は、同じ物理エンティティまたは異なる物理エンティティであってもよい。受信機および送信機が同じ物理エンティティであるとき、受信機および送信機はトランシーバと総称されることがある。メモリ801はプロセッサ803に統合されてもよく、またはプロセッサ803とは別に配設されてもよい。

一実装形態では、受信機および送信機の機能は、トランシーバ回路または専用トランシーバチップを通じて実装されると見なされることがある。プロセッサ803は、専用処理チップ、処理回路、プロセッサ、または汎用チップを使用して実装されると見なされることがある。

上記の方法実施形態と同じ概念に基づいて、図9に示されているように、本出願の一実施形態は通信装置900をさらに提供する。通信装置900は、図3または図4に示されている方法において端末によって実施されるステップを実施することができることを理解されたい。繰返しを避けるために、詳細は再び本明細書で説明されない。通信装置900は、プログラムを記憶するように構成されたメモリ901と、
別のデバイスと通信するように構成された通信インターフェース902と、
メモリ901内のプログラムを実行するように構成されたプロセッサ903とを含み、プログラムが実行されるとき、プロセッサ903は、通信インターフェース902を通じて、ネットワークデバイスからRACH構成情報を受信することであって、RACH構成情報がM個のRACHリソースセットを示し、M個のRACHリソースセットがN個の端末タイプに対応し、N個の端末タイプが端末の帯域幅タイプおよび/またはランダムアクセスタイプに基づいて決定され、MおよびNが正の整数である、受信することと、構成情報に基づいて、ランダムアクセス要求をネットワークデバイスに送るために現在の端末によって使用されるターゲットRACHリソースセットを決定することであって、現在の端末の帯域幅タイプがN個の端末タイプを決定するための帯域幅タイプに属する、決定することとを行うように構成される。

図9に示されている通信装置900は、チップまたは回路、たとえば、端末に配設され得るチップまたは回路であってもよいことを理解されたい。通信インターフェース902は、代替としてトランシーバであってもよい。トランシーバは、受信機および送信機を含む。さらに、通信装置900は、バスシステムをさらに含んでもよい。

プロセッサ903、メモリ901、受信機、および送信機は、バスシステムを通じて接続される。プロセッサ903は、メモリ901に記憶された命令を実行し、信号を受信するように受信機を制御するとともに信号を送るように送信機を制御し、本出願のいずれかの実施形態で提供されるランダムアクセス方法において端末によって実施されるステップを完了するように構成される。受信機および送信機は、同じ物理エンティティまたは異なる物理エンティティであってもよい。受信機および送信機が同じ物理エンティティであるとき、受信機および送信機はトランシーバと総称されることがある。メモリ901はプロセッサ903に統合されてもよく、またはプロセッサ903とは別に配設されてもよい。

一実装形態では、受信機および送信機の機能は、トランシーバ回路または専用トランシーバチップを通じて実装されると見なされることがある。プロセッサ903は、専用処理チップ、処理回路、プロセッサ、または汎用チップを使用して実装されると見なされることがある。

当業者は、本明細書で開示される実施形態で説明される例と組み合わせて、ユニットおよびアルゴリズムステップが電子ハードウェアまたはコンピュータソフトウェアと電子ハードウェアの組合せによって実装されてもよいことに気づいていることがある。機能がハードウェアによって実施されるかまたはソフトウェアによって実施されるかは、特定の適用例および技術的解決策の設計制約条件に依存する。当業者は説明される機能を特定の適用例ごとに実装するために異なる方法を使用することができるが、その実装が本出願の実施形態の範囲を超えると解釈されるべきではない。

本出願で提供される異なる実施形態は組み合わされてもよい。本出願で提供される実施形態では、開示されるシステム、装置、および方法は他の様式で実装されてもよいことを理解されたい。たとえば、説明される装置実施形態は一例である。たとえば、ユニットへの分割は論理機能の分割にすぎず、実際の実装では他の分割であってもよい。たとえば、複数のユニットもしくは構成要素が別のシステムに組み合わされるかもしくは統合されることがあり、またはいくつかの特徴が無視されるかまたは実施されないことがある。加えて、表示されるまたは説明される相互結合もしくは直接結合または通信接続は、いくつかのインターフェースを通じて実装されてもよい。装置またはユニットの間の間接結合または通信接続は、電子形態、機械形態、または他の形態で実装されてもよい。

別個の部分として説明されるユニットは、物理的に分離していてもよいかまたは物理的に分離していなくてもよく、ユニットとして表示される部分は、物理ユニットであってもよいかまたは物理ユニットでなくてもよく、1つの位置に位置してもよく、または複数のネットワークユニット上で分散されてもよい。ユニットの一部または全部は、実施形態の目的を達成するための実際のニーズに基づいて選択されてもよい。

加えて、本出願の実施形態における機能ユニットが1つの処理ユニットに統合されてもよく、またはユニットの各々が物理的に単独で存在してもよく、または2つ以上のユニットが1つのユニットに統合されてもよい。集積ユニットはハードウェアの形態で実装されてもよく、またはソフトウェア機能ユニットの形態で実装されてもよい。

集積ユニットがソフトウェア機能ユニットの形態で実装され、独立した製品として販売または使用されるとき、集積ユニットはコンピュータ可読記憶媒体に記憶されてもよい。そのような理解に基づいて、本出願の技術的解決策は基本的に、あるいは、従来技術に寄与する部分、または技術的解決策の全部もしくは一部は、ソフトウェア製品の形態で実装されてもよい。コンピュータソフトウェア製品は、記憶媒体に記憶され、コンピュータデバイス(パーソナルコンピュータ、サーバ、またはネットワークデバイスであってもよい)に本出願の実施形態で説明される方法のステップの全部または一部を実施するように命令するためのいくつかの命令を含む。上記の記憶媒体は、リムーバブルハードディスク、読取り専用メモリ、ランダムアクセスメモリ、磁気ディスク、または光ディスクなどの、プログラムコードを記憶することができる任意の媒体を含む。

上記の説明は、本出願の実施形態の特定の実装形態にすぎず、本出願の実施形態の保護範囲を限定することは意図されていない。本出願の実施形態で開示される技術的範囲内で当業者によって容易に見つけ出されるいかなる変形または置換も、本出願の実施形態の保護範囲内に入るものとする。本出願の実施形態では、別段に明記されていない限りまたは論理矛盾がない限り、異なる実施形態の間の用語および/または説明は一貫性があり、相互に参照されることがあり、異なる実施形態における技術的特徴は、新しい実施形態を作成するために、その内部の論理関係に基づいて組み合わされることがある。

本出願では、「および/または」は関連する対象物の間の関連付け関係について説明し、3つの関係が存在し得ることを示す。たとえば、Aおよび/またはBは、以下の3つのケース、すなわち、Aのみが存在する、AとBの両方が存在する、Bのみが存在する、を示すことができ、AおよびBは単数または複数でもよい。本出願の本文の説明では、記号「/」は一般に、関連する対象物の間の「または」関係を示す。本出願における式では、記号「/」は関連する対象物の間の「除算」関係を示す。

本出願の実施形態における様々な数は、説明しやすいように区別のために使用されるものであり、本出願の実施形態の範囲を限定するために使用されるものではないことが理解され得る。上記のプロセスのシーケンス番号は実行シーケンスを意味するものではなく、プロセスの実行シーケンスは機能およびプロセスの内部論理に基づいて決定されるべきである。

最後に、上記の実施形態は、本出願を限定することではなく、本出願の技術的解決策について説明することが意図されているにすぎないことに留意されたい。本出願は上記の実施形態に関して詳細に説明されるが、当業者は、本出願の実施形態の技術的解決策の趣旨および範囲から逸脱することなく、当業者が依然として上記の実施形態で提供される技術的解決策に変更を加えるかまたはそのいくつかの技術的特徴に対して等価な置換を行うことができることを理解すべきである。

100 ワイヤレス通信システム
101 ネットワークデバイス
103 端末
600 通信装置
601 処理ユニット
602 トランシーバユニット
700 通信装置
701 トランシーバユニット
702 処理ユニット
800 通信装置
801 メモリ
802 通信インターフェース
803 プロセッサ
900 通信装置
901 メモリ
902 通信インターフェース
903 プロセッサ

Claims

M個のランダムアクセスチャネル、RACH、リソースセットを決定するステップであって、前記M個のRACHリソースセットがN個の端末タイプに対応し、前記N個の端末タイプが端末の帯域幅タイプおよび/またはランダムアクセスタイプに基づいて決定され、MおよびNが正の整数である、ステップと、
RACH構成情報を少なくとも1つの端末に送るステップであって、前記RACH構成情報が前記M個のRACHリソースセットを示し、前記M個のRACHリソースセットがランダムアクセス要求をネットワークデバイスに送るために前記少なくとも1つの端末によって使用され、前記少なくとも1つの端末のうちのいずれか1つの帯域幅タイプが前記N個の端末タイプを決定するための前記帯域幅タイプに属する、ステップと
を含むランダムアクセス方法であって、
前記RACH構成情報が第1のRACH構成、第2のRACH構成および第3のRACH構成のうちの1つをさらに示し、前記第1のRACH構成が、前記M個のRACHリソースセットが前記N個の端末タイプに対応し、MがNよりも小さく、Mが1に等しいというものであり、
前記第2のRACH構成が、前記M個のRACHリソースセットが前記N個の端末タイプに対応し、MがNに等しく、Mが1よりも大きいというものであり、
前記第3のRACH構成が、前記M個のRACHリソースセットが前記N個の端末タイプに対応し、MがNよりも小さく、Mが1よりも大きいというものである、
ランダムアクセス方法。
前記少なくとも1つの端末の帯域幅タイプがNR_legacyまたはNR_REDCAP type2であり、NR_legacyの帯域幅が100MHzであり、NR_REDCAP type2の帯域幅が20MHzであり、
前記M個のRACHリソースセットの各々が、RACHの時間領域リソース、周波数領域リソース、および直交コードシーケンスリソースの組合せを含み、前記M個のRACHリソースセットの中のいずれか2つの異なるRACHリソースセットが、周波数領域リソース、時間領域リソース、および直交コードシーケンスリソースのうちの1つまたは複数において異なる、
請求項1に記載の方法。
前記RACH構成情報が、シグナリングにおいて搬送され、前記シグナリングが、前記N個の端末タイプが少なくとも1つのアップリンク初期帯域幅パート、UL initial BWPに対応することを示す構成情報をさらに含む、
請求項1または2に記載の方法。
帯域幅タイプNR_REDCAP type2の端末および帯域幅タイプNR_legacyの端末が同じUL initial BWPに対応する、
請求項1から3のいずれか一項に記載の方法。
前記同じUL initial BWPが、NR_legacyおよび4-step RACHに基づいて決定された端末タイプの端末ならびにNR_REDCAP type2および4-step RACHに基づいて決定された端末タイプの端末からのランダムアクセス要求を第1のRACHリソースセット上で受信するためのものであるか、または
前記同じUL initial BWPが、NR_REDCAP type2および4-step RACHに基づいて決定された端末タイプの端末からのランダムアクセス要求を第5のRACHリソースセット上で、NR_legacyおよび4-step RACHに基づいて決定された端末タイプの端末からのランダムアクセス要求を第9のRACHリソースセット上で受信するためのものである、
請求項4に記載の方法。
帯域幅タイプNR_REDCAP type2の端末が第2のUL initial BWPに対応し、帯域幅タイプNR_legacyの端末が第3のUL initial BWPに対応し、
前記第2のUL initial BWPが、NR_legacyおよび4-step RACHに基づいて決定された端末タイプの端末からのランダムアクセス要求を第1のRACHリソースセット上で受信するためのものであり、前記第3のUL initial BWPが、NR_REDCAP type2および4-step RACHに基づいて決定された端末タイプの端末からのランダムアクセス要求を前記第1のRACHリソースセット上で受信するためのものであるか、または
前記第2のUL initial BWPが、NR_legacyおよび4-step RACHに基づいて決定された端末タイプの端末からのランダムアクセス要求を第5のRACHリソースセット上で受信するためのものであり、前記第3のUL initial BWPが、NR_REDCAP type2および4-step RACHに基づいて決定された端末タイプの端末からのランダムアクセス要求を第9のRACHリソースセット上で受信するためのものである、
請求項1から3のいずれか一項に記載の方法。
ネットワークデバイスからランダムアクセスチャネルRACH構成情報を受信するステップであって、前記RACH構成情報がM個のRACHリソースセットを示し、前記M個のRACHリソースセットがN個の端末タイプに対応し、前記N個の端末タイプが端末の帯域幅タイプおよび/またはランダムアクセスタイプに基づいて決定され、MおよびNが正の整数である、ステップと、
前記RACH構成情報に基づいて、ランダムアクセス要求を前記ネットワークデバイスに送るために端末によって使用されるターゲットRACHリソースセットを決定するステップであって、前記端末の帯域幅タイプが前記N個の端末タイプを決定するための前記帯域幅タイプに属する、ステップと
を含むランダムアクセス方法であって、
前記RACH構成情報が第1のRACH構成、第2のRACH構成および第3のRACH構成のうちの1つをさらに示し、前記第1のRACH構成が、前記M個のRACHリソースセットが前記N個の端末タイプに対応し、MがNよりも小さく、Mが1に等しいというものであり、
前記第2のRACH構成が、前記M個のRACHリソースセットが前記N個の端末タイプに対応し、MがNに等しく、Mが1よりも大きいというものであり、
前記第3のRACH構成が、前記M個のRACHリソースセットが前記N個の端末タイプに対応し、MがNよりも小さく、Mが1よりも大きいというものである、
ランダムアクセス方法。
前記端末の帯域幅タイプがNR_legacyまたはNR_REDCAP type2であり、NR_legacyの帯域幅が100MHzであり、NR_REDCAP type2の帯域幅が20MHzであり、
前記M個のRACHリソースセットの各々が、RACHの時間領域リソース、周波数領域リソース、および直交コードシーケンスリソースの組合せを含み、前記M個のRACHリソースセットの中のいずれか2つの異なるRACHリソースセットが、周波数領域リソース、時間領域リソース、および直交コードシーケンスリソースのうちの1つまたは複数において異なる、
請求項7に記載の方法。
前記RACH構成情報が、シグナリングにおいて搬送され、前記シグナリングが、前記N個の端末タイプが少なくとも1つのアップリンク初期帯域幅パート、UL initial BWPに対応することを示す構成情報をさらに含む、
請求項7または8に記載の方法。
帯域幅タイプNR_REDCAP type2の端末および帯域幅タイプNR_legacyの端末が同じUL initial BWPに対応する、
請求項7から9のいずれか一項に記載の方法。
前記同じUL initial BWPが、NR_legacyおよび4-step RACHに基づいて決定された端末タイプの端末ならびにNR_REDCAP type2および4-step RACHに基づいて決定された端末タイプの端末からのランダムアクセス要求を第1のRACHリソースセット上で受信するためのものであるか、または
前記同じUL initial BWPが、NR_REDCAP type2および4-step RACHに基づいて決定された端末タイプの端末からのランダムアクセス要求を第5のRACHリソースセット上で、NR_legacyおよび4-step RACHに基づいて決定された端末タイプの端末からのランダムアクセス要求を第9のRACHリソースセット上で受信するためのものである、
請求項10に記載の方法。
帯域幅タイプNR_REDCAP type2の端末が第2のUL initial BWPに対応し、帯域幅タイプNR_legacyの端末が第3のUL initial BWPに対応し、
前記第2のUL initial BWPが、NR_legacyおよび4-step RACHに基づいて決定された端末タイプの端末からのランダムアクセス要求を第1のRACHリソースセット上で受信するためのものであり、前記第3のUL initial BWPが、NR_REDCAP type2および4-step RACHに基づいて決定された端末タイプの端末からのランダムアクセス要求を前記第1のRACHリソースセット上で受信するためのものであるか、または
前記第2のUL initial BWPが、NR_legacyおよび4-step RACHに基づいて決定された端末タイプの端末からのランダムアクセス要求を第5のRACHリソースセット上で受信するためのものであり、前記第3のUL initial BWPが、NR_REDCAP type2および4-step RACHに基づいて決定された端末タイプの端末からのランダムアクセス要求を第9のRACHリソースセット上で受信するためのものである、
請求項7または8に記載の方法。
通信装置であって、
M個のランダムアクセスチャネルRACHリソースセットを決定するように構成された処理ユニットであって、前記M個のRACHリソースセットがN個の端末タイプに対応し、前記N個の端末タイプが端末の帯域幅タイプおよび/またはランダムアクセスタイプに基づいて決定され、MおよびNが正の整数である、処理ユニットと、
RACH構成情報を少なくとも1つの端末に送るように構成されたトランシーバユニットであって、前記RACH構成情報が前記M個のRACHリソースセットを示し、前記M個のRACHリソースセットがランダムアクセス要求をネットワークデバイスに送るために前記少なくとも1つの端末によって使用され、前記少なくとも1つの端末のうちのいずれか1つの帯域幅タイプが前記N個の端末タイプを決定するための前記帯域幅タイプに属する、トランシーバユニットと
を備える通信装置であって、
前記RACH構成情報が第1のRACH構成、第2のRACH構成および第3のRACH構成のうちの1つをさらに示し、前記第1のRACH構成が、前記M個のRACHリソースセットが前記N個の端末タイプに対応し、MがNよりも小さく、Mが1に等しいというものであり、
前記第2のRACH構成が、前記M個のRACHリソースセットが前記N個の端末タイプに対応し、MがNに等しく、Mが1よりも大きいというものであり、
前記第3のRACH構成が、前記M個のRACHリソースセットが前記N個の端末タイプに対応し、MがNよりも小さく、Mが1よりも大きいというものである、
通信装置。
前記少なくとも1つの端末の帯域幅タイプがNR_legacyまたはNR_REDCAP type2であり、NR_legacyの帯域幅が100MHzであり、NR_REDCAP type2の帯域幅が20MHzであり、
前記M個のRACHリソースセットの各々が、RACHの時間領域リソース、周波数領域リソース、および直交コードシーケンスリソースの組合せを含み、前記M個のRACHリソースセットの中のいずれか2つの異なるRACHリソースセットが、周波数領域リソース、時間領域リソース、および直交コードシーケンスリソースのうちの1つまたは複数において異なる、
請求項13に記載の通信装置。
前記RACH構成情報が、シグナリングにおいて搬送され、前記シグナリングが、前記N個の端末タイプが少なくとも1つのアップリンク初期帯域幅パート(UL initial BWP)に対応することを示す構成情報をさらに含む、
請求項13または14に記載の通信装置。
帯域幅タイプNR_REDCAP type2の端末および帯域幅タイプNR_legacyの端末が同じUL initial BWPに対応する、
請求項13から15のいずれか一項に記載の通信装置。
前記同じUL initial BWPが、NR_legacyおよび4-step RACHに基づいて決定された端末タイプの端末ならびにNR_REDCAP type2および4-step RACHに基づいて決定された端末タイプの端末からのランダムアクセス要求を第1のRACHリソースセット上で受信するためのものであるか、または
前記同じUL initial BWPが、NR_REDCAP type2および4-step RACHに基づいて決定された端末タイプの端末からのランダムアクセス要求を第5のRACHリソースセット上で、NR_legacyおよび4-step RACHに基づいて決定された端末タイプの端末からのランダムアクセス要求を第9のRACHリソースセット上で受信するためのものである、
請求項16に記載の通信装置。
帯域幅タイプNR_REDCAP type2の端末が第2のUL initial BWPに対応し、帯域幅タイプNR_legacyの端末が第3のUL initial BWPに対応し、
前記第2のUL initial BWPが、NR_legacyおよび4-step RACHに基づいて決定された端末タイプの端末からのランダムアクセス要求を第1のRACHリソースセット上で受信するためのものであり、前記第3のUL initial BWPが、NR_REDCAP type2および4-step RACHに基づいて決定された端末タイプの端末からのランダムアクセス要求を前記第1のRACHリソースセット上で受信するためのものであるか、または
前記第2のUL initial BWPが、NR_legacyおよび4-step RACHに基づいて決定された端末タイプの端末からのランダムアクセス要求を第5のRACHリソースセット上で受信するためのものであり、前記第3のUL initial BWPが、NR_REDCAP type2および4-step RACHに基づいて決定された端末タイプの端末からのランダムアクセス要求を第9のRACHリソースセット上で受信するためのものである、
請求項13から15のいずれか一項に記載の通信装置。
通信装置であって、
ネットワークデバイスからランダムアクセスチャネルRACH構成情報を受信するように構成されたトランシーバユニットであって、前記RACH構成情報がM個のRACHリソースセットを示し、前記M個のRACHリソースセットがN個の端末タイプに対応し、前記N個の端末タイプが端末の帯域幅タイプおよび/またはランダムアクセスタイプに基づいて決定され、MおよびNが正の整数である、トランシーバユニットと、
前記RACH構成情報に基づいて、ランダムアクセス要求を前記ネットワークデバイスに送るために前記通信装置によって使用されるターゲットRACHリソースセットを決定するように構成された処理ユニットであって、前記通信装置の帯域幅タイプが前記N個の端末タイプを決定するための前記帯域幅タイプに属する、処理ユニットと
を備える通信装置であって、
前記RACH構成情報が第1のRACH構成、第2のRACH構成および第3のRACH構成のうちの1つをさらに示し、前記第1のRACH構成が、前記M個のRACHリソースセットが前記N個の端末タイプに対応し、MがNよりも小さく、Mが1に等しいというものであり、
前記第2のRACH構成が、前記M個のRACHリソースセットが前記N個の端末タイプに対応し、MがNに等しく、Mが1よりも大きいというものであり、
前記第3のRACH構成が、前記M個のRACHリソースセットが前記N個の端末タイプに対応し、MがNよりも小さく、Mが1よりも大きいというものである、
通信装置。
前記端末の帯域幅タイプがNR_legacyまたはNR_REDCAP type2であり、NR_legacyの帯域幅が100MHzであり、NR_REDCAP type2の帯域幅が20MHzであり、
前記M個のRACHリソースセットの各々が、RACHの時間領域リソース、周波数領域リソース、および直交コードシーケンスリソースの組合せを含み、前記M個のRACHリソースセットの中のいずれか2つの異なるRACHリソースセットが、周波数領域リソース、時間領域リソース、および直交コードシーケンスリソースのうちの1つまたは複数において異なる、
請求項19に記載の通信装置。
前記RACH構成情報が、シグナリングにおいて搬送され、前記シグナリングが、前記N個の端末タイプが少なくとも1つのアップリンク初期帯域幅パート(UL initial BWP)に対応することを示す構成情報をさらに含む、
請求項19または20に記載の通信装置。
帯域幅タイプNR_REDCAP type2の端末および帯域幅タイプNR_legacyの端末が同じUL initial BWPに対応する、
請求項19から21のいずれか一項に記載の通信装置。
前記同じUL initial BWPが、NR_legacyおよび4-step RACHに基づいて決定された端末タイプの端末ならびにNR_REDCAP type2および4-step RACHに基づいて決定された端末タイプの端末からのランダムアクセス要求を第1のRACHリソースセット上で受信するためのものであるか、または
前記同じUL initial BWPが、NR_REDCAP type2および4-step RACHに基づいて決定された端末タイプの端末からのランダムアクセス要求を第5のRACHリソースセット上で、NR_legacyおよび4-step RACHに基づいて決定された端末タイプの端末からのランダムアクセス要求を第9のRACHリソースセット上で受信するためのものである、
請求項22に記載の通信装置。
帯域幅タイプNR_REDCAP type2の端末が第2のUL initial BWPに対応し、帯域幅タイプNR_legacyの端末が第3のUL initial BWPに対応し、
前記第2のUL initial BWPが、NR_legacyおよび4-step RACHに基づいて決定された端末タイプの端末からのランダムアクセス要求を第1のRACHリソースセット上で受信するためのものであり、前記第3のUL initial BWPが、NR_REDCAP type2および4-step RACHに基づいて決定された端末タイプの端末からのランダムアクセス要求を前記第1のRACHリソースセット上で受信するためのものであるか、または
前記第2のUL initial BWPが、NR_legacyおよび4-step RACHに基づいて決定された端末タイプの端末からのランダムアクセス要求を第5のRACHリソースセット上で受信するためのものであり、前記第3のUL initial BWPが、NR_REDCAP type2および4-step RACHに基づいて決定された端末タイプの端末からのランダムアクセス要求を第9のRACHリソースセット上で受信するためのものである、
請求項19から21のいずれか一項に記載の通信装置。
請求項1から6のいずれか一項に記載の方法を実装するように構成された通信装置。
請求項7から12のいずれか一項に記載の方法を実装するように構成された通信装置。
メモリおよびプロセッサを備える通信装置であって、前記メモリが命令/コードを記憶し、前記メモリに記憶された前記命令/コードを実行するとき、前記プロセッサが請求項1から6のいずれか一項に記載の方法を実装する、通信装置。
メモリおよびプロセッサを備える通信装置であって、前記メモリが命令/コードを記憶し、前記メモリに記憶された前記命令/コードを実行するとき、前記プロセッサが請求項7から12のいずれか一項に記載の方法を実装する、通信装置。
命令/コードを記憶するように構成されたコンピュータ可読記憶媒体であって、前記命令/コードが電子デバイスのプロセッサによって実行されるとき、前記電子デバイスが請求項1から6のいずれか一項に記載の方法を実装することを可能にされる、コンピュータ可読記憶媒体。
命令/コードを記憶するように構成されたコンピュータ可読記憶媒体であって、前記命令/コードが電子デバイスのプロセッサによって実行されるとき、前記電子デバイスが請求項7から12のいずれか一項に記載の方法を実装することを可能にされる、コンピュータ可読記憶媒体。
請求項27に記載の通信装置および請求項28に記載の通信装置を備える通信システム。