JP2024508928A

JP2024508928A - 通信方法およびデバイス

Info

Publication number: JP2024508928A
Application number: JP2023553722A
Authority: JP
Inventors: 奕如 ▲クアン▼; ▲海▼博徐; ▲麗▼霞薛; 繁▲華▼ 孔
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2021-03-04
Filing date: 2022-02-24
Publication date: 2024-02-28
Also published as: CN115022865A; WO2022183970A1; EP4294078A1; US20230413129A1; BR112023017860A2

Abstract

本出願は、通信方法およびデバイスを提供する。本方法は、ネットワークデバイスの第1の中央ユニットが端末デバイスから第1の情報を受信するステップであって、第1の情報が端末デバイスのタイプを示す、ステップ、を含む。第1の中央ユニットは、ネットワークデバイスの第1の分散ユニットに第2の情報を送信し、第2の情報は端末デバイスのタイプを示す。

Description

関連出願の相互参照
本出願は、2021年3月4日に中国国家知識産権局に出願された「TERMINAL CAPABILITY INDICATION METHOD，TERMINAL，AND NETWORK DEVICE」という名称の中国特許出願第202110240470．5号の優先権を主張し、その全体が参照により本明細書に組み込まれる。本出願は、2021年3月31日に中国国家知識産権局に出願された「COMMUNICATION METHOD AND DEVICE」という名称の中国特許出願第202110352120．8号の優先権を主張し、その全体が参照により本明細書に組み込まれる。

本出願の実施形態は、無線通信技術の分野に関し、特に、通信方法およびデバイスに関する。

現在、LTE Rel－15および5G NRエボリューションでは、図1に示されるように、新しいネットワークアーキテクチャが提供されている。このネットワークアーキテクチャでは、基地局の機能は、中央ユニット（central unit、CU）と分散ユニット（distributed unit、DU）の2つのユニットに分割される。CUは、無線上位層プロトコルスタック機能、例えば、無線リソース制御（radio resource control、RRC）層およびパケットデータ収束プロトコル（packet data convergence protocol、PDCP）層を処理する。DUは、ベースバンド処理の物理層と、いくつかの層2プロトコルスタック機能、例えば、無線リンク制御（radio link control、RLC）層、メディアアクセス制御（media access control、MAC）層、および物理層（physical layer、PHY）とを処理する。CUとDUとの間のインターフェースはF1インターフェースである。

現在、CU－DUネットワークアーキテクチャでは、ネットワークデバイスは、低減された能力（Reduced Capability、REDCAP）の端末デバイスのためのより良好なスケジューリングおよびアクセス管理を実装することができない。

本出願の実施形態は、通信方法およびデバイスを提供し、その結果、ネットワークデバイスは、低減された能力の端末デバイスに対してより良好なスケジューリングおよびアクセス管理を実行することができる。

第1の態様によれば、本出願は通信方法を提供し、本方法は、ネットワークデバイスの第1の中央ユニットが端末デバイスから第1の情報を受信し、第1の情報が端末デバイスのタイプを示すことを含む。第1の中央ユニットは、ネットワークデバイスの第1の分散ユニットに第2の情報を送信し、第1の情報は端末デバイスのタイプを示す。

例えば、ネットワークデバイスの中央ユニットはCUであってもよく、ネットワークデバイスの分散ユニットはDUであってもよい。前述の方法によれば、端末デバイスがネットワークデバイスにアクセスした後に、ネットワークデバイスの第1の中央ユニットは、端末デバイスから受信した第1の情報に基づいてネットワークデバイスの第1の分散ユニットに第2の情報を送信することができ、その結果、ネットワークデバイスの第1の分散ユニットは、時間内に端末デバイスのタイプを取得することができる。例えば、端末デバイスのタイプは、低減された能力の端末デバイス（例えば、REDCAP端末デバイス、またはNB－IoT端末デバイス）であってもよい。あるいは、端末デバイスのタイプは、中程度に低減された能力の端末デバイスのタイプであってもよい。例えば、低減された能力の端末デバイスがREDCAP端末デバイスである場合、低減された能力の端末デバイスのタイプは、別の例として、REDCAP端末デバイス内の異なる能力を有する、さらなる細分化端末デバイスであってもよいし、REDCAP端末デバイス内の異なるアンテナのさらなる細分化端末デバイスであってもよい。

したがって、端末デバイスのアクセスプロセスにおいて、または端末デバイスがネットワークデバイスの第1の分散ユニットにハンドオーバされると、ネットワークデバイスの第1の分散ユニットは、ネットワークデバイスの第1の中央ユニットから取得された第2の情報内の端末デバイスのタイプに基づいて、対応するリソースおよび端末デバイスのアクセス優先順位を時間内にスケジュールして、低減された能力の端末デバイスのスケジューリング管理を実施することができる。

可能な実施態様では、端末デバイスのタイプは、以下、すなわち、低減された能力の端末デバイス、または低減された能力の端末デバイスのタイプのうちのいずれか1つを含む。

可能な実施態様では、第1の中央ユニットは、第1の分散ユニットを介して第1の情報を受信する。

前述の方法によれば、端末デバイスが第1の分散ユニットおよび第1の中央ユニットを介してネットワークにアクセスすると、端末デバイスは、第1の分散ユニットを介して第1の情報を透過的伝送方式で第1の中央ユニットに送信することができる。

可能な実施態様では、第1の中央ユニットは、第2の分散ユニットを介して第1の情報を受信し、第2の分散ユニットは、端末デバイスが第1の分散ユニットにハンドオーバされる前に端末デバイスによりアクセスされる分散ユニットである。

前述の方法によれば、第2の分散ユニットにアクセスするとき、端末デバイスは、第1の中央ユニットが時間内に端末デバイスのタイプを取得することができるように、第2の分散ユニットを介して第1の中央ユニットに第1の情報を送信することができる。端末デバイスが第1の分散ユニットにハンドオーバされると、第1の分散ユニットは、第1の中央ユニットにより送信された第2の情報に基づいて第2の情報を取得して、第1の分散ユニットがハンドオーバ後に時間内に端末デバイスのリソースを依然としてスケジュールできることを保証することができる。

可能な実施態様では、第1の中央ユニットは、第2の中央ユニットにより送信された第1の情報を受信し、第2の中央ユニットは、端末デバイスが第1の中央ユニットにハンドオーバされる前に端末デバイスによりアクセスされる中央ユニットである。

可能な実施態様では、第1の分散ユニットは、第2の情報に基づいて端末デバイスのリソースおよび／または端末デバイスのアクセス優先順位をスケジュールする。

可能な実施態様では、第1の中央ユニットは第2の情報を第3の分散ユニットに送信し、第3の分散ユニットは、端末デバイスが第1の分散ユニットからハンドオーバされる分散ユニットである。

前述の方法によれば、第1の中央ユニットは、端末デバイスが第3の分散ユニットにハンドオーバされたときに第2の情報を第3の分散ユニットに送信することができ、その結果、第3の分散ユニットは、ハンドオーバ時に端末デバイスのタイプをより早く取得することができ、端末デバイスが第3の分散ユニットにアクセスするプロセスにおいて、端末デバイスのために、低減された能力の端末デバイスに対応するリソーススケジューリングをより早く提供することができる。

可能な実施態様では、第1の中央ユニットは、第1の情報を第3の中央ユニットに送信し、第3の中央ユニットは、端末デバイスが第1の中央ユニットからハンドオーバされる中央ユニットであり、第1の情報は、第2の情報を第3の分散ユニットに送信するために第3の中央ユニットにより使用されるべきであり、第3の分散ユニットは、端末デバイスが第1の分散ユニットからハンドオーバされる分散ユニットである。

前述の方法によれば、第1の中央ユニットは、端末デバイスが第3の中央ユニットにハンドオーバされたときに第1の情報を第3の中央ユニットに送信することができ、その結果、第3の中央ユニットは、ハンドオーバ時に端末デバイスのタイプをより早く取得することができ、端末デバイスが第3の中央ユニットにアクセスした後に第2の情報を第3の分散ユニットに送信することができ、その結果、第3の分散ユニットは、端末デバイスのために低減された能力の端末デバイスに対応するリソーススケジューリングをより早く提供することができる。

可能な実施態様では、第2の情報は第1のメッセージで搬送され、第1のメッセージは第1のフィールドを含み、第1のフィールドは第2の情報を搬送する。

前述の方法によれば、第1のフィールドは、第2の情報が第1のメッセージを介して送信されるように、第2の情報のために第1のメッセージに新たに追加され得る。例えば、第1のメッセージは、第1の中央ユニットにより第1の分散ユニットに送信されたメッセージであってもよく、その結果、ネットワークデバイスの第1の分散ユニットは、第2の情報をより早く取得し、低減された能力の端末デバイスのリソースをより早くスケジュールすることができる。

第2の態様によれば、本出願は通信方法を提供し、本通信方法は、ネットワークデバイスの第1の分散ユニットが端末デバイスから第1の情報を受信し、第1の情報が端末デバイスのタイプを示すことを含む。第1の分散ユニットは、ネットワークデバイスの第1の中央ユニットに第2の情報を送信し、第2の情報は端末デバイスのタイプを示す。

例えば、ネットワークデバイスの中央ユニットはCUであってもよく、ネットワークデバイスの分散ユニットはDUであってもよい。前述の方法によれば、端末デバイスがネットワークデバイスにアクセスした後に、ネットワークデバイスの第1の分散ユニットは、端末デバイスから受信した第1の情報に基づいてネットワークデバイスの第1の中央ユニットに第2の情報を送信することができ、その結果、ネットワークデバイスの第1の中央ユニットは、時間内に端末デバイスのタイプを取得することができる。例えば、端末デバイスのタイプは、低減された能力の端末デバイス（例えば、REDCAP端末デバイス、またはNB－IoT端末デバイス）であってもよい。あるいは、端末デバイスのタイプは、中程度に低減された能力の端末デバイスのタイプであってもよい。例えば、低減された能力の端末デバイスがREDCAP端末デバイスである場合、低減された能力の端末デバイスのタイプは、別の例として、REDCAP端末デバイス内の異なる能力を有する、さらなる細分化端末デバイスであってもよいし、REDCAP端末デバイス内の異なるアンテナのさらなる細分化端末デバイスであってもよい。

したがって、端末デバイスのアクセスプロセスにおいて、または端末デバイスがネットワークデバイスの第1の中央ユニットもしくはネットワークデバイスの第1の分散ユニットにハンドオーバされるとき、ネットワークデバイスの第1の中央ユニットは、ネットワークリソースの利用を改善するために、ネットワークデバイスの第1の中央ユニットから取得された第2の情報内の端末デバイスのタイプに基づいて、低減された能力の端末デバイスのアクセスを適時に制御することができる。

可能な実施態様では、第1の中央ユニットは、第2の情報に基づいて端末デバイスのアクセスを制御する。

可能な実施態様では、第1の中央ユニットは第2の情報を第3の中央ユニットに送信し、第3の中央ユニットは、端末デバイスが第1の中央ユニットからハンドオーバされる中央ユニットである。

可能な実施態様では、第2の情報は、端末デバイスのアクセスを制御するために使用される。

可能な実施態様では、第2の情報は第2のメッセージで搬送され、第2のメッセージは第1のフィールドを含み、第1のフィールドは第2の情報を搬送する。

前述の方法によれば、第1のフィールドは、第2の情報が第2のメッセージを介して送信されるように、第2の情報のために第2のメッセージに新たに追加されてもよい。例えば、第2のメッセージは初期アップリンク無線リソース制御メッセージ転送メッセージであってもよく、その結果、ネットワークデバイスの第1の中央ユニットは、第2の情報をより早く取得し、低減された能力の端末デバイスのアクセスをより早く制御することができる。

可能な実施態様では、第1のメッセージは、ダウンリンク無線リソース制御メッセージ転送メッセージ、または端末デバイスコンテキスト要求メッセージのいずれか一方であり、第2のメッセージは、初期アップリンク無線リソース制御メッセージ転送メッセージである。

可能な実施態様では、第1の情報はメッセージ1またはメッセージ3により搬送される。

上記の方式では、第1の情報の後に、すなわちランダム・アクセス・プロセスにおけるメッセージ1またはメッセージ3の後に、ネットワークデバイスの第1の分散ユニットまたはネットワークデバイスの第1の中央ユニットは、対応する第1の中央ユニットまたは第1の分散ユニットに情報をより早く送信して、より早く低減された能力の端末デバイスをスケジューリングまたは管理することができる。

可能な実施態様では、第1の分散ユニットおよび第1の中央ユニットは第1のネットワークデバイス内の分離されたネットワーク要素であり、第1のネットワークデバイスが、端末デバイスがネットワークにアクセスするように構成されるか、第2の分散ユニットおよび第2の中央ユニットが、第2のネットワークデバイス内の分離されたネットワーク要素であり、第2のネットワークデバイスが、端末デバイスがネットワークにアクセスするように構成されるか、第3の分散ユニットおよび第3の中央ユニットが、第3のネットワークデバイス内の分離されたネットワーク要素であり、第3のネットワークデバイスが、端末デバイスがネットワークにアクセスするように構成されるか、第2の分散ユニットおよび第1の中央ユニットが、第4のネットワークデバイス内の分離されたネットワーク要素であり、第4のネットワークデバイスが、端末デバイスがネットワークにアクセスするように構成されるか、または第3の分散ユニットおよび第1の中央ユニットが、第5のネットワークデバイス内の分離されたネットワーク要素であり、第5のネットワークデバイスが、端末デバイスがネットワークにアクセスするように構成される。

第3の態様によれば、本出願は、ネットワークデバイスの第1の中央ユニットに使用される通信装置を提供する。第1の中央ユニットは、処理モジュール、送信モジュール、および受信モジュールを含んでもよい。

処理モジュールは、受信モジュールを介して端末デバイスから第1の情報を受信するように構成され、第1の情報は端末デバイスのタイプを示す。処理モジュールは、送信モジュールを介してネットワークデバイスの第1の分散ユニットに第2の情報を送信するように構成され、第1の情報は端末デバイスのタイプを示す。

可能な実施態様では、処理モジュールは、受信モジュールを介して第1の分散ユニットを介して端末デバイスから第1の情報を受信するように構成される。

可能な実施態様では、処理モジュールは、受信モジュールを介して第2の分散ユニットを介して端末デバイスから第1の情報を受信するように構成され、第2の分散ユニットは、端末デバイスが第1の分散ユニットにハンドオーバされる前に端末デバイスによりアクセスされる分散ユニットである。

可能な実施態様では、処理モジュールは、受信モジュールを介して、第2の中央ユニットにより送信された第1の情報を受信するように構成され、第2の中央ユニットは、端末デバイスが第1の中央ユニットにハンドオーバされる前に端末デバイスによりアクセスされる中央ユニットである。

可能な実施態様では、処理モジュールは、送信モジュールを介して第2の情報を第3の分散ユニットに送信するように構成され、第3の分散ユニットは、端末デバイスが第1の分散ユニットからハンドオーバされる分散ユニットである。

可能な実施態様では、処理モジュールは、送信モジュールを介して第1の情報を第3の中央ユニットに送信するように構成され、第3の中央ユニットは、端末デバイスが第1の中央ユニットからハンドオーバされる中央ユニットであり、第1の情報は、第2の情報を第3の分散ユニットに送信するために第3の中央ユニットにより使用されるべきであり、第3の分散ユニットは、端末デバイスが第1の分散ユニットからハンドオーバされる分散ユニットである。

第4の態様によれば、本出願は、ネットワークデバイスの第1の分散ユニットに使用される通信装置を提供する。第1の分散ユニットは、処理モジュールと、送信モジュールと、受信モジュールと、を含んでもよい。

処理モジュールは、受信モジュールを介して端末デバイスから第1の情報を受信するように構成され、第1の情報は端末デバイスのタイプを示す。処理モジュールは、送信モジュールを介してネットワークデバイスの第1の中央ユニットに第2の情報を送信するように構成され、第2の情報は端末デバイスのタイプを示す。

第3の態様または第4の態様を参照すると、第1のメッセージは、ダウンリンク無線リソース制御メッセージ転送メッセージ、または端末デバイスコンテキスト要求メッセージのいずれか一方であり、第2のメッセージは、初期アップリンク無線リソース制御メッセージ転送メッセージである。

第3の態様または第4の態様を参照すると、可能な実施態様では、第1の情報はメッセージ1またはメッセージ3により搬送される。

第3の態様または第4の態様を参照すると、可能な実施態様では、第1の分散ユニットおよび第1の中央ユニットは第1のネットワークデバイス内の分離されたネットワーク要素であり、第1のネットワークデバイスが、端末デバイスがネットワークにアクセスするように構成されるか、第2の分散ユニットおよび第2の中央ユニットが、第2のネットワークデバイス内の分離されたネットワーク要素であり、第2のネットワークデバイスが、端末デバイスがネットワークにアクセスするように構成されるか、第3の分散ユニットおよび第3の中央ユニットが、第3のネットワークデバイス内の分離されたネットワーク要素であり、第3のネットワークデバイスが、端末デバイスがネットワークにアクセスするように構成されるか、第2の分散ユニットおよび第1の中央ユニットが、第4のネットワークデバイス内の分離されたネットワーク要素であり、第4のネットワークデバイスが、端末デバイスがネットワークにアクセスするように構成されるか、または第3の分散ユニットおよび第1の中央ユニットが、第5のネットワークデバイス内の分離されたネットワーク要素であり、第5のネットワークデバイスが、端末デバイスがネットワークにアクセスするように構成される。

第5の態様によれば、本出願は、プロセッサおよびメモリを含む通信装置を提供する。メモリは、コンピュータ実行可能命令を記憶するように構成される。装置が動作すると、プロセッサは、メモリに記憶されたコンピュータ実行可能命令を実行し、装置は、第1の態様の実施方法における任意の方法を実行することを可能にされる。

第6の態様によれば、本出願は、プロセッサおよびメモリを含む通信装置を提供する。メモリは、コンピュータ実行可能命令を記憶するように構成される。装置が動作すると、プロセッサは、メモリに記憶されたコンピュータ実行可能命令を実行し、装置は、第2の態様の実施方法における任意の方法を実行することを可能にされる。

第7の態様によれば、本出願の一実施形態は、コンピュータ可読記憶媒体をさらに提供する。コンピュータ可読記憶媒体は命令を記憶する。命令がコンピュータ上で実行されると、コンピュータは、第1の態様から第2の態様の実施方法における任意の方法を実行することを可能にされる。

第8の態様によると、本出願の一実施形態は、コンピュータプログラム製品をさらに提供する。コンピュータ製品は、コンピュータプログラムを含む。コンピュータプログラムが実行されると、第1の態様から第2の態様の実施態様における任意の方法が実行される。

第9の態様によれば、本出願の一実施形態は、第1の態様から第2の態様の実施態様における任意の方法を実行するように構成されたプロセッサを含むチップシステムをさらに提供する。

第10の態様によれば、本出願の一実施形態は、第3の態様または第5の態様の第1の中央ユニットを含むか、または第4の態様または第6の態様の第1の分散ユニットを含む通信システムをさらに提供する。

本出願の一実施形態が適用可能であるネットワークアーキテクチャの概略図である。本出願の一実施形態が適用可能であるネットワークアーキテクチャの概略図である。本出願の一実施形態が適用可能であるネットワークアーキテクチャの概略図である。ランダムアクセス方法の概略フローチャートである。本出願の一実施形態による通信方法の概略フローチャートである。本出願の一実施形態による通信方法の概略フローチャートである。本出願の一実施形態による通信方法の概略フローチャートである。コンテキスト設定方法の概略フローチャートである。本出願の一実施形態が適用可能であるアプリケーションシナリオの概略図である。本出願の一実施形態による通信方法の概略フローチャートである。本出願の一実施形態が適用可能であるアプリケーションシナリオの概略図である。本出願の一実施形態による通信方法の概略フローチャートである。本出願の一実施形態による通信方法の概略フローチャートである。本出願の一実施形態による通信方法の概略フローチャートである。本出願の一実施形態による通信装置の概略図である。本出願の一実施形態による通信デバイスの概略図である。

以下は、当業者がより良く理解するのを助けるために、本出願の実施形態におけるいくつかの用語を説明する。

（1）低減された能力の端末デバイスとは、低いデータ処理能力、小さい信号送信および受信帯域幅、低いバッテリ容量、ならびに少数の送信および受信アンテナを含む、5G NRネットワークにおける端末デバイスのバッテリ寿命を改善するように設計された簡略化された機能を有する端末デバイスを指す。例えば、REDCAP端末デバイスは、より低いエアインターフェース能力をサポートする。例えば、REDCAP端末デバイスは、能力に関して、より小さい帯域幅、より少ないアンテナ数、より低い変調次数などをサポートする。具体的には、REDCAP端末デバイスは、サポートされている最大能力に基づいて異なるREDCAP端末デバイスタイプにさらに分類されてもよい。例えば、REDCAP端末デバイスは、高能力REDCAP端末デバイスタイプ（例えば、サポートされる受信アンテナの最大数は2であり、またはサポートされる最大帯域幅は40Mである）と、低能力REDCAP端末デバイスタイプ（例えば、サポートされる受信アンテナの最大数は1であり、またはサポートされる最大帯域幅は20Mである）と、に分類されることができる。本出願のこの実施形態では、低減された能力の端末デバイスは、代替的に、狭帯域モノのインターネット（narrow band internet of things、NB－IoT）端末デバイスまたはマシンタイプ通信（machine type communication、MTC）端末デバイスであってもよいし、代替的に、機能が簡略化された別のタイプの端末デバイスであってもよいことに留意されたい。REDCAPが低減された能力の端末デバイスとして使用されることは、本明細書では一例として使用されているにすぎない。低減された端末デバイスの名称は、本出願では限定されない。

（2）通信システムは、様々な無線アクセス技術（radio access technology、RAT）システム、例えば、ロングタームエボリューション（long term evolution、LTE）システムおよび様々なLTEエボリューションベースのシステムであってもよい。また、通信システムは、例えば、第5世代（5th generation、5G）システムや新無線（new radio、NR）など、将来の通信技術にさらに適用可能であってもよい。

図1は、本出願の一実施形態が適用可能な通信システムのネットワークアーキテクチャの概略図である。

図1に示されるように、通信システムは、端末デバイス101とネットワークデバイス102とを含む。端末デバイス101は、ランダム・アクセス・プロセスを介してネットワークデバイス102にアクセスする。

端末デバイス101は、無線ネットワークにアクセスして、無線ネットワークを介して外部ネットワーク（例えば、インターネット）のサービスを取得するか、または無線ネットワークを介して別のデバイスと通信する、例えば、別の端末デバイスと通信することができる。アクセスネットワークは、次世代無線アクセスネットワーク（next generation radio access network、NG－RAN）であってもよく、アクセスネットワークは、基地局（例えば、gNB）などのアクセスネットワークデバイスを含んでもよい。gNB同士は、インターフェース（例えば、Xnインターフェース）を介して接続される。RANデバイスは、無線ネットワークに端末デバイス101にアクセスするように構成され、gNBは、インターフェース（例えば、Ngインターフェース）を介して5GCに接続される。コアネットワークは、複数のコアネットワークデバイスを含んでもよい。コアネットワークデバイスは、端末デバイスを管理し、外部ネットワークと通信するためのゲートウェイを提供するように構成される。図1に示されるネットワークアーキテクチャが5G通信システムに適用可能である場合、コアネットワークは5Gコアネットワーク（5G core network、5GC）であってもよい。5GCは、1つまたは複数の機能またはデバイスを含む。例えば、コアネットワークデバイスは、アクセスおよび移動管理機能（access and mobility management function、AMF）エンティティ、セッション管理機能（session management function、SMF）エンティティまたはユーザプレーン機能（user plane function、UPF）エンティティ、セッション管理機能（session management function、SMF）などであってもよい。これらの機能またはデバイスは、ハードウェアデバイス内のネットワーク要素、専用ハードウェア上で実行されるソフトウェア機能、またはプラットフォーム（クラウドプラットフォームなど）上でインスタンス化された仮想化機能であってもよい。様々なコアネットワークデバイスの名前は、5G通信システムにおける名前であることが理解されよう。通信システムの進化に伴い、様々なコアネットワークデバイスの名称は、同じ機能を有する他の名称に置き換えられてもよい。図1に示されるネットワークアーキテクチャがLTE通信システムに適用可能である場合、コアネットワークデバイスは、移動管理エンティティ（mobility management entity、MME）、サービングゲートウェイ（serving gateway、S－GW）などであってもよい。

図1に示される通信システム内のデバイスの数は単なる例であることを理解されたい。これは、本出願のこの実施形態では限定されない。実際の応用では、通信システムは、より多くの端末デバイス101およびより多くのRAN機器をさらに含むことができ、別の機器をさらに含むことができる。

RANは、アクセスネットワークデバイスまたは基地局と呼ばれることもあり、RANノード（またはRANデバイス）と呼ばれることもある。現在、アクセスネットワークデバイスのいくつかの例は以下の通りであり、すなわち、gNB／NR－NB、送受信ポイント（transmission reception point、TRP）、進化型ノードB（evolved Node B、eNB）、次世代進化型ノードB（next generation eNodeB、ng－eNB）、無線ネットワークコントローラ（radio network controller、RNC）、ノードB（Node B、NB）、基地局コントローラ（BSC）、トランシーバ基地局（base transceiver station、BTS）、ホーム基地局（例えば、home evolved NodeB、またはhome Node B、HNB）、ベースバンドユニット（base band unit、BBU）、ワイヤレスフィデリティ（wireless fidelity、Wifi）アクセスポイント（access point、AP）、または可能な将来の通信システムにおけるアクセスネットワークデバイスである。あるいは、アクセスネットワークデバイスは、5GシステムのgNB、例えばNRシステム、送信ポイント（TRPまたはTP）、5Gシステムの基地局のアンテナパネルの1つまたはグループ（複数のアンテナパネルを含む）、またはgNBまたは送信ポイントを形成するネットワークノード、例えばベースバンドユニット（baseband unit、BBU）であってもよい。

端末デバイスは、端末デバイス、ユーザ機器（user equipment、UE）、移動局（mobile station、MS）、モバイル端末デバイス（mobile terminal、MT）などとも呼ばれ、ユーザに音声またはデータ接続性を提供するデバイスであり、モノのインターネットデバイスであってもよい。例えば、端末デバイスは、無線接続機能を有するハンドヘルドデバイスまたは車載デバイスを含んでもよい。現在、端末デバイスは、携帯電話（mobile phone）、タブレットコンピュータ、ノートブックコンピュータ、パームトップコンピュータ、モバイル・インターネット・デバイス（mobile internet device、MID）、ウェアラブルデバイス（スマートウオッチ、スマートバンド、歩数計など）、車載デバイス（自動車、自転車、電気自動車、飛行機、船舶、電車、高速鉄道など）、仮想現実（virtual reality、VR）デバイス、拡張現実（augmented reality、AR）デバイス、産業制御（industrial control）における無線端末デバイス、スマートホームデバイス（冷蔵庫、TV、エアーコンディショナ、メータなど）、インテリジェントロボット、ワークショップデバイス、自動運転（self driving）における無線端末デバイス、遠隔医療手術（remote medical surgery）における無線端末デバイス、スマートグリッド（smart grid）における無線端末デバイス、交通安全（transportation safety）における無線端末デバイス、スマートシティ（smart city）における無線端末デバイス、スマートホーム（smart home）における無線端末デバイス、飛行デバイス（例えば、インテリジェントロボット、熱気球、ドローン、飛行機）などであってもよい。本出願のこの実施形態では、解決策を説明するためにUEまたは端末デバイスが使用される。

図2aは、本出願の一実施形態が適用可能な5G通信システムにおけるネットワークアーキテクチャの概略図である。図2aに示されるように、ネットワークアーキテクチャは、CNデバイス（例えば、図2aに示される5GC）、RANデバイス、および端末デバイスを含む。

RANデバイスおよび端末デバイスは、互いに通信するために特定のプロトコル層構造に準拠する。例えば、制御プレーンプロトコル層構造は、無線リソース制御（radio resource control、RRC）層、パケットデータコンバージェンスプロトコル（packet data convergence protocol、PDCP）層、無線リンク制御（radio link control、RLC）層、メディアアクセス制御（media access control、MAC）層、および物理層などのプロトコル層の機能を含んでもよい。ユーザプレーンプロトコル層構造は、PDCP層、RLC層、MAC層、および物理層などのプロトコル層の機能を含んでもよい。可能な実施態様では、PDCP層よりも上にサービスデータアダプションプロトコル（service data adaptation protocol、SDAP）層がさらに含まれてもよい。RRC層の主な機能は、RRC層がRRCメッセージを解析できるように、UEのアクセス制御、保守、および解放、UEの構成などに関連するUEの上位層制御プレーンであることである。MAC層および物理層（physical layer、PHY）の主な機能は、UEのデータパッケージング、データスケジューリングなどに関連するUEの下位層スケジューリングであり、そのため、MAC層はMAC層の制御シグナリングを解析でき、PHY層はPHY層の制御シグナリングを解析できる。RANデバイスは、1つのノードを使用してRRC、PDCP、RLC、およびMACなどのプロトコル層の機能を実装してもよいし、複数のノードを使用してそのようなプロトコル層の機能を実装してもよい。

5G NRネットワークの新しいネットワークアーキテクチャでは、ネットワークデバイスは、中央ユニットと分散ユニットの2つの論理ネットワーク要素を含んでもよい。ネットワークデバイスのいくつかの機能は1つの中央ユニットに配置され、残りの機能は分散ユニットに配置される。複数の分散ユニットが1つの中央ユニットを共有することにより、コストを削減し、ネットワーク拡張を容易にすることができる。機能は、シナリオおよび要件に基づいて、一体的に展開されても別々に展開されてもよい。例えば、中央ユニットはCUであってもよく、分散ユニットはDUであってもよい。以下では、中央ユニットおよび分散ユニットを含むネットワークアーキテクチャがCU－DU分離アーキテクチャである例を説明する。ネットワークアーキテクチャの進化および新しいサービスシナリオの出現により、通信システム内の無線アクセスネットワークデバイスがCU－DU分離アーキテクチャまたはCU－DU分離アーキテクチャの機能と同等のアーキテクチャを有する場合、本出願の実施形態で提供される技術的解決策は、同様の技術的問題にも適用可能である。

本出願の本実施形態では、CUとDUとはインターフェース（例えば、F1インターフェース）を介して接続される。CUは、基地局がインターフェース（例えば、Ngインターフェース）を介してコアネットワークに接続されていることを表す。本出願の通信システムでは、図2aに示されるように、UEはアクセスネットワークデバイス（例えば、gNB）に接続されてもよい。具体的には、UEはgNB内のDUに接続されてもよい。CUは、5GCとDUとに別々に接続される。ダウンリンク通信リンクでは、CUは、5GCからデータを受信し、そのデータをDUに送信するように構成される。アップリンク通信リンクでは、CUは、DUからデータを受信し、データを5GCに送信するように構成される。さらに、CUは、DUのための集中制御機能を有する。異なる無線アクセス技術を用いるシステムでは、CU機能を有するデバイスは、異なる名前を有してもよい。説明を容易にするために、CU機能を有するデバイスは、アクセスネットワーク中央ユニットと総称される。

DUは、CUおよびユーザ機器（UE）に別々に接続される。ダウンリンク通信リンクでは、DUは、CUからデータを受信し、UEにデータを送信するように構成される。アップリンク通信リンクでは、DUは、UEからデータを受信し、そのデータをCUに送信するように構成される。異なる無線アクセス技術を使用するシステムでは、DU機能を有するデバイスは異なる名前を有する場合がある。説明を簡単にするために、DU機能を有するデバイスはアクセスネットワーク分散ユニットと総称される。

前述のネットワークアーキテクチャでは、CUにより生成されたシグナリングは、DUを介して端末デバイスに送信されてもよく、または端末デバイスにより生成されたシグナリングは、DUを介してCUに送信されてもよい。DUは、解析せずにプロトコル層により直接カプセル化された後にシグナリングを端末デバイスまたはCUに透過的に送信することができる。以下の実施形態がDUと端末デバイスとの間のそのようなシグナリング伝送に関与される場合、この場合、DUによるシグナリングの送受信はこのシナリオを含む。例えば、RRC層またはPDCP層のシグナリングは、最終的に物理層のシグナリングとして処理されて端末デバイスに送信されるか、または物理層の受信シグナリングから変換される。このアーキテクチャでは、RRC層またはPDCP層のシグナリングも、DUにより送信されるか、またはDUおよび無線周波数負荷により送信されると見なされ得る。

ネットワークデバイスのCUとネットワークデバイスのDUとの間のプロトコルスタックベースの割り当ては図2bに示されることができる。例えば、RRC層、SDAP層、およびPDCP層は、ネットワークデバイスのCUに配置される。RLC層、MAC層、および物理層は、ネットワークデバイスのDUに配置される。

本出願のこの実施形態では、ネットワークデバイスがNRシステムをサポートするデバイスである場合、CUおよびDUの機能割り当ては、プロトコルスタックに基づいて実行されてもよい。ネットワークデバイスのCUおよびネットワークデバイスのDUは、2つの機能エンティティとして使用される。1つの可能な方式では、機能割り当ては、コンテンツ処理のリアルタイムに基づいて実行される。図2bに示されるように、RRC層、SDAP層、およびPDCP層は、CUに配置される。RLC層、MAC層、PHY層などはDUに展開される。これに対応して、CUは、RRC、PDCP、およびSDAPの処理能力を有する。CU－DUアーキテクチャのネットワークデバイスの場合、ネットワークデバイスのCUは、端末デバイスのRRC状態を管理する役割を担う。DUは、RLC、MAC、およびPHYの処理能力を有する。

前述の機能割り当ては一例にすぎず、別の割り当て方式があってもよいことに留意されたい。例えば、CUはRRC、PDCP、RLC、およびSDAPの処理能力を含み、DUはMACおよびPHYの処理能力を有する。別の例では、CUは、RRC、PDCP、RLC、SDAP、およびMACの一部の処理能力（例えば、MACパケットヘッダが付加される）を含み、DUは、PHYおよびMACの一部の処理能力（スケジューリングなど）を有する。

そのようなプロトコル層での割り当ては単なる例である。割り当てはまた、他のプロトコル層で実行されてもよい。例えば、割り当てはRLC層で行われ、RLC層およびRLC層より上のプロトコル層の機能はCUに割り当てられ、RLC層より下のプロトコル層の機能はDUに割り当てられる。あるいは、割り当てはプロトコル層で行われる。例えば、RLC層の一部の機能およびRLC層の上位のプロトコル層の機能がCUに割り当てられ、RLC層の残りの機能およびRLC層の下位のプロトコル層の機能がDUに割り当てられる。加えて、割り当ては別の方式で実行されてもよい。例えば、割り当ては遅延に基づいて行われ、処理時間が遅延制約を満たす必要がある機能がDUに割り当てられ、処理時間が遅延制約を満たす必要がない機能がCUに割り当てられる。上記のようなプロトコル層での割り当ては単なる例である。割り当てはまた、例を使用して本明細書で詳細に説明されていない他のプロトコル層で実行されてもよい。

当然ながら、本出願のこの実施形態は、LTE通信システムにさらに適用可能であり得る。例えば、LTE通信システムは、RANデバイスおよびCNデバイスも含んでもよい。RANデバイス（eNB）は、ベースバンド装置および無線周波数装置を含む。ベースバンド装置は、1つのノードを使用して実装されてもよく、または複数のノードを使用して実装されてもよい。無線周波数装置は、ベースバンド装置から遠隔に独立して実装されてもよいし、ベースバンド装置に統合されてもよいし、部分が遠隔にあり、部分がベースバンド装置に統合される。無線周波数装置は、ベースバンド装置に対して遠隔配置されてもよく、例えば、遠隔無線ユニット（remote radio unit、RRU）は、BBUに対して遠隔配置される。さらに、無線周波数装置は、DUに配置されることなく遠隔に配置されてもよく、DUに統合されてもよく、または部品が遠隔であり、部品がDUに統合される。これは本明細書では限定されない。

図2aおよび図2bに示される通信システムに含まれるUEの数およびタイプは一例にすぎないことを理解されたい。これは、本出願のこの実施形態では限定されない。例えば、アクセスネットワークデバイス（gNBなど）と通信するより多くのUEが含まれてもよい。簡潔にするために、これは添付の図面では詳細に説明されない。また、図2aおよび図2bに示される通信システムでは、各DUに接続された1つの基地局および1つのUEが示されているが、通信システムは、各DUに接続された基地局およびUEを含むことに限定されなくてもよい。本明細書では詳細を繰り返さない。

本明細書の以下の実施形態では、第1のDUによりサポートされるネットワークがすべての論理CUによりサポートされるネットワークのユニオンセットであることが主な例として使用され、すなわち、第1のDUは、第1のDUに接続された各論理CUによりサポートされるネットワークをサポートする。説明を容易にするために、本明細書の以下の説明では、第1の論理CUは略して「第1のCU」と呼ばれ、以下の説明では、第2の論理CUは略して「第2のCU」と呼ばれる。

図1から図2bは、本出願の実施形態におけるいくつかの機能またはデバイスのみを示しており、通信システムアーキテクチャは、より多くのまたはより少ない機能またはデバイスをさらに含んでもよいことを理解されたい。例えば、図1の5GCデバイスは、統合データ管理（unified data management、UDM）、データネットワーク（data network、DN）などをさらに含んでもよい。図2aまたは図2bに示されるDUは、より多くの論理セルなどでさらに構成されてもよい。

本出願の実施形態が適用可能な通信システムアーキテクチャは、図1から図2bに示されるものに限定されない。本出願は、図1～図2bに示されるデバイスの機能を実施することができるすべての通信システムアーキテクチャに適用可能である。

「システム」および「ネットワーク」という用語は、本出願の実施形態において交換可能に使用され得る。「少なくとも1つ」は1つまたは複数を意味し、「複数の」は2つ以上を意味する。「および／または」という用語は、関連付けられる対象を記述するための関連付け関係を記述し、3つの関係が存在し得ることを表す。例えば、Aおよび／またはBは、以下の3つの場合、すなわち、Aのみが存在する、AおよびBの両方が存在する、およびBのみが存在する、を表す可能性があり、AおよびBは、単数であっても複数であってもよい。文字「／」は一般に、関連付けられる対象間の「または」関係を示す。「以下の項目（個）の少なくとも1つ」または同様の表現は、単数の項目（ピース）または複数の項目（ピース）の任意の組み合わせを含む、これらの項目の任意の組み合わせを指す。例えば、a、b、またはcの少なくとも1つは、a、b、c、aおよびb、aおよびc、bおよびc、またはa、b、およびcを表すことができる。

さらに、特に明記しない限り、本出願の実施形態で言及される「第1」および「第2」などの序数は、複数の対象を区別するために使用され、複数の対象の順序、時系列、優先順位、または重要度を限定することは意図されない。例えば、第1の優先順位基準および第2の優先順位基準は、異なる基準を区別するために使用されるにすぎず、2つの基準の内容、優先順位、または重要度が異なることを示すものではない。

さらに、本出願の実施形態、特許請求の範囲、および添付の図面における「含む」および「有する」という用語は排他的ではない。例えば、一連のステップまたはモジュールを含むプロセス、方法、システム、製品、またはデバイスは、列挙されているステップまたはモジュールに限定されず、列挙されていないステップまたはモジュールをさらに含んでもよい。

図1、図2a、または図2bに示されるネットワークアーキテクチャでは、端末デバイス101は、通常のサービス送信を実行して、ネットワークデバイス102への接続を設定し、対応する専用リソースを端末デバイス101に割り当てるようにネットワークデバイス102に要求する。端末デバイスは、ランダム・アクセス・プロセスを介してネットワークデバイスとのアップリンク同期を設定し、端末デバイスがネットワークデバイスとのアップリンク伝送を行うことができるように、一意の端末デバイス識別子、例えばセル無線ネットワーク一時識別子（cell radio network temporary identifier、C－RNTI）を取得することができる。

以下では、本出願の実施形態におけるランダム・アクセス・プロセスの関連する技術的特徴について説明する。

1．ランダム・アクセス・プロセスのトリガ
ランダム・アクセス・プロセスとは、端末デバイスがランダムアクセス信号を送信することによりネットワークにアクセスしようと試み始めてから、ネットワークデバイスへの基本的なシグナリング接続が設定されるまでのプロセスを指す。ランダムアクセス信号は、ランダム・アクセス・プロセスを開始するために使用され得る。例えば、ランダムアクセス信号は、ランダム・アクセス・プリアンブル（random access preamble）であってもよい。任意選択で、ランダムアクセス信号は代替的に復調基準信号（demodulation reference signal、DMRS）であってもよい。端末デバイスは、通信システムとのアップリンク時間同期を実施するために、ランダム・アクセス・プロセスを介してネットワークデバイスと情報を交換することができる。任意選択で、端末デバイスは、ランダム・アクセス・プロセスを介してリソース要求またはデータ送信をさらに実行してもよい。本出願のこの実施形態では、ランダム・アクセス・プロセスは、ランダムアクセス、ランダム・アクセス・チャネル・プロセス、またはランダムアクセス方式とも呼ばれ得る。これは、本出願では区別されず、以下の説明では互換的に使用され得る。

例えば、ランダム・アクセス・プロセスをトリガする複数のイベント（またはシナリオ）があってもよい。例えば、LTE通信システムでは、ランダム・アクセス・プロセスは、以下のシナリオでトリガされてもよい。

シナリオ1：端末デバイスの初期アクセスにおいて、端末デバイスは初期RRC接続を設定する。RRCアイドル（RRC＿IDLE）状態がRRC接続（RRC＿CONNECTED）状態に変更されると、端末デバイスはランダムアクセスを開始する。

シナリオ2：端末デバイスがRRC接続を再確立する（RRC connection re－establishment procedure）。無線接続が失敗した後に端末デバイスがRRC接続を再確立する必要がある場合、端末デバイスはランダムアクセスを開始する。

シナリオ3：端末デバイスがセルハンドオーバ（handover）を実行すると、端末デバイスはターゲットセルでランダムアクセスを開始する。

シナリオ4：ダウンリンクデータが到着する。端末デバイスが接続状態にあるとき、ネットワークデバイスは、ダウンリンクデータを端末デバイスに送信する必要があるが、端末デバイスがアップリンク同期から外れていることを発見する。すなわち、RRC＿CONNECTED状態において、ダウンリンクデータが到来すると（この場合、肯定応答（ACK）／否定応答（NACK）応答が必要である）、アップリンクは「同期外れ」状態となる。ネットワークデバイスは、ランダムアクセスを開始するように端末デバイスを制御する。ネットワークデバイス側はアップリンクタイマを維持する。アップリンクタイマが満了し、ネットワークデバイスが端末デバイスから応答信号を受信しない場合、ネットワークデバイスは、端末デバイスがアップリンク同期から外れていると見なす。

シナリオ5：アップリンクデータが到着する。端末デバイスが接続状態にあるとき、端末デバイスはネットワークデバイスにアップリンクデータを送信する必要があるが、端末デバイスがアップリンク同期から外れていることを発見する。すなわち、RRC＿CONNECTED状態では、アップリンクデータが到着すると（例えば、測定報告が報告される必要があり、またはユーザデータが送信される必要がある）、アップリンクは「同期外れ」状態にあるか、またはスケジューリング要求（scheduling request、SR）送信（この場合、アップリンク同期にある端末デバイスは、SRを置換するためにランダム・アクセス・チャネル（random access channel、RACH）を使用することを許可される）に利用可能な物理アップリンク制御チャネル（physical uplink control channel、PUCCH）リソースがない。この場合、端末デバイスはランダムアクセスを開始する。端末デバイス側はアップリンクタイマを維持する。アップリンクタイマが満了し、端末デバイスがネットワークデバイスにより最大時間アドバンス（time advanced、TA）値を調整するためのコマンドを受信しない場合、端末デバイスはアップリンクが同期から外れていると見なす。

別の例として、5G通信システムでは、ランダム・アクセス・プロセスは、以下のシナリオでさらにトリガされてもよい。

（1）アップリンク（uplink、UL）データは非アクティブ（Inactive）状態で到着し、この場合、アップリンクは「同期外れ」状態にある。（2）ダウンリンク（downlink、DL）データはInactive状態で到着し、この場合、アップリンクは「同期外れ」状態にある。（3）On－demandシステム情報（system information、SI）が要求される（5G通信システムでは、システム情報は、minimum SIおよびOn－demand SIの2つのタイプに分類され、minimum SIは、すべての端末デバイスにより受け入れられる必要があり、On－demand SIは、端末デバイスの要求に従って要求されてもよい）。（4）ビーム障害回復（beam failure recovery、BFR）。

上記は、ランダム・アクセス・プロセスをトリガするイベントである。LTEシステムまたはNRシステムに関係なく、端末デバイスはランダム・アクセス・プロセスを介してネットワークデバイスにアクセスする必要があることが知見され得る。ランダム・アクセス・プロセスには、競合ベース（contention based）ランダムアクセスと非競合ベース（non－contention based）ランダムアクセスの2つの異なる方式がある。例えば、端末デバイスにより送信されたプリアンブルが端末デバイスにより選択されるかどうかに応じて、ランダム・アクセス・プロセスは、競合ベースのランダム・アクセス・プロセスと非競合ベースのランダム・アクセス・プロセスとに分類され得る。競合ベースのランダム・アクセス・プロセスでは、プリアンブルは端末デバイスにより選択され得る。ランダム・アクセス・プロセスをトリガするイベントが、上述したハンドオーバおよびビーム障害の回復以外の他のイベントである場合、競合ベースのランダム・アクセス・プロセスが使用されてもよい。非競合ベースのランダム・アクセス・プロセスでは、プリアンブルは、ネットワークデバイスにより端末デバイスに割り当てられ得る。ランダム・アクセス・プロセスをトリガするイベントが上述したハンドオーバまたはビーム障害の回復のイベントである場合、非競合ベースのランダム・アクセス・プロセスが使用されてもよい。

以下では、図3を参照してランダム・アクセス・プロセスに含まれるいくつかのステップを説明するために、一例として競合ベースのランダム・アクセス・プロセスを使用する。図3は、本出願の一実施形態によるランダム・アクセス・プロセスの概略図である。図3に示されるように、本出願の本実施形態において提供される画像処理方法は、以下のステップを含む。

ステップ300：ネットワークデバイスがランダムアクセス構成情報を端末デバイスに送信すると、端末デバイスは、ネットワークデバイスからランダムアクセス構成情報を受信することができ、ランダムアクセス構成情報はランダム・アクセス・パラメータを構成するために使用される。このステップは、ランダムアクセス処理が行われる前の準備作業であってもよく、ランダムアクセス処理に含まれるステップではない。

例えば、ランダム・アクセス・パラメータは、ランダム・アクセス・プリアンブルを送信するために使用される物理ランダム・アクセス・チャネル（physical random access channel、PRACH）リソースセット、ランダム・アクセス・プリアンブル（preamble）セット、ランダム・アクセス・プリアンブルの最大送信回数、ランダム・アクセス・プリアンブルの初期送信電力、ランダムアクセス応答ウィンドウのサイズ、第3のメッセージのハイブリッド自動再送要求（hybrid automatic repeat request、HARQ）繰り返し回数の最大数、および競合解決タイマの持続時間のうちの1つまたは複数を含んでもよい。さらに、ランダム・アクセス・パラメータは、パワーランピングステップをさらに含むことができる。

PRACHリソースセットは、プリアンブルを送信するために端末デバイスにより使用され得る時間－周波数リソースを含んでもよく、フィールドrach－ConfigGenericにより示されてもよい。ランダム・アクセス・プリアンブルの最大送信回数は、フィールドtotalNumberOfRA－Preamblesにより示されてもよい。ランダム・アクセス・プリアンブルの初期送信電力は、フィールドreambleInitialReceivedTargetpowerにより示されてもよい。ランダムアクセス応答ウィンドウのサイズは、ランダムアクセス応答ウィンドウに含まれるサブフレームの数を示し、フィールドra－ResponsewindowSizeにより示されてもよい。ランダムアクセス応答ウィンドウは、端末デバイスがpreambleを送信するサブフレームの後の第3のサブフレームから始まり（preambleが時間領域において複数のサブフレームにまたがる場合、最後のサブフレームがカウントの開始として使用される）、ra－ResponseWindowSizeサブフレームにわたって持続する。第3のメッセージのHARQ繰り返し回数の最大数は、フィールドmaxHARQ－Msg3により示されてもよい。競合解決タイマの持続時間は、フィールドmac－ContentionResolutionTimerにより示されてもよい。

（1）上記「PRACHリソースセット、preambleセット、ランダム・アクセス・プリアンブルの最大送信回数、ランダム・アクセス・プリアンブルの初期送信電力、ランダムアクセス応答ウィンドウのサイズ、第3のメッセージのHARQ繰り返し回数の最大回数、および競合解決タイマの持続時間」毎に、対応するデフォルト値が設定されてもよいことに留意されたい。例えば、ネットワークデバイスにより送信されるランダムアクセス構成情報がRACHリソースセットで構成されるが、ランダム・アクセス・プリアンブルの最大送信回数（例えば、ランダムアクセス構成情報は、フィールドrach－ConfigGenericを含むが、フィールドtotalNumberOfRA－Preamblesを含まない）で構成されないとき、ランダム・アクセス・プリアンブルの最大送信回数の値はデフォルト値であってもよい。

（2）上記は、ランダム・アクセス・パラメータに含まれる内容の一例について説明している。別の可能な実施形態では、ランダム・アクセス・パラメータは、ランダム・アクセス・プロセスに関連する他のコンテンツ、例えば、時間指示情報をさらに含んでもよい。

ステップ301：端末デバイスはネットワークデバイスにpreambleを送信し、ネットワークデバイスは端末デバイスからpreambleを受信し、preambleはランダム・アクセス・プロセスにおける第1のメッセージまたはメッセージ1（MSG1）とも呼ばれる。

ステップ301で端末デバイスによりネットワークデバイスに送信されるpreambleは、端末デバイスによりネットワークデバイスに送信されるランダムアクセス要求であってもよい。preambleは、ランダムアクセスのためにステップ300で取得されたpreambleセットから端末デバイスにより選択されたpreambleであってもよい。任意選択で、ネットワークデバイスは、preambleに基づいてネットワークデバイスと端末デバイスとの間の伝送遅延を推定し、伝送遅延に基づいてアップリンクタイミングを較正してもよい。

ステップ302：端末デバイスにより送信されたpreambleを検出した後に、ネットワークデバイスは、ランダムアクセス応答（random access response、RAR）メッセージを端末デバイスに送信する。

これに対応して、端末デバイスは、ネットワークデバイスからRARメッセージを受信する。RARメッセージは、ランダム・アクセス・プロセスにおける第2のメッセージまたはメッセージ2（MSG2）とも称される。メッセージ2は、メディアアクセス制御MACサブヘッダ（subheader）とMAC RARとを含むMACプロトコルデータユニット（Protocol Data Unit、PDU）を含む。メッセージ2は、以下の情報、すなわち、検出されたpreambleの識別子またはインデックス、アップリンク時間同期情報、ならびにメッセージ3を送信するために端末デバイスに割り当てられたアップリンクリソースおよびBIのうちの1つまたは複数のタイプを含んでもよい。当然ながら、メッセージ2は他の情報をさらに含むことができる。preambleの識別子は、例えば、ランダム・アクセス・プリアンブル識別子（random access preamble identifier、RAPID）である。ネットワークデバイスが端末デバイスにより送信されたpreambleを受信しない場合、ネットワークデバイスにより送信されたメッセージ2は、端末デバイスに対応するpreambleの識別子を含まないことに留意されたい。

例えば、MAC RARは、タイミングアドバンス（timing advance、TA）のためのコマンド（command）を含むことができ、TAは、端末デバイスのアップリンク同期に必要な時間調整値を指定するために使用されるか、またはメッセージ3に割り振られたアップリンクリソースをさらに含んでもよいし、または端末デバイスに割り振られた一時的セル無線ネットワーク一時識別子（temporary cell radio network temporary identifier、TC－RNTI）をさらに含んでもよく、TC－RNTIは端末デバイスとネットワークデバイスとのその後の送信に用いられ、競合が解決された後で、TC－RNTIはセル無線ネットワーク一時識別子（cell radio network temporary identifier、C－RNTI）になり得る。

メッセージ1を送信した後に、端末デバイスは、RAR時間ウィンドウ（RA response window）でメッセージ2を受信する。ネットワークデバイスにより返されたメッセージ2がRAR時間ウィンドウで受信されない場合、ランダム・アクセス・プロセスは失敗したと見なされる。ランダムアクセスに失敗した端末デバイスの場合、ネットワークデバイスはバックオフ指示を端末デバイスに送信することができる。バックオフ指示は時間値を示すことができ、時間値はバックオフ時間範囲を決定するために使用される。ランダム・アクセス・プロセスが失敗すると、端末デバイスは、バックオフ時間範囲内のバックオフ時間を選択することができ、ステップ300でネットワークデバイスにより端末デバイスに対して構成されたランダムアクセスリソースは、選択されたバックオフ時間が終了するまで再び使用されることができない。

ステップ303：端末デバイスは、メッセージ2に基づいてネットワークデバイスにアップリンクデータを送信する。

これに対応して、ネットワークデバイスは、端末デバイスからアップリンクデータを受信する。アップリンクデータは、ランダム・アクセス・プロセスにおける第3のメッセージまたはメッセージ3（MSG3）とも呼ばれる。

メッセージ3は異なるシナリオ情報の識別子を含むことができ、識別子はステップ304で競合解決に使用される。メッセージ3は、端末デバイスの異なる状態および異なるアプリケーションシナリオに基づいて異なるコンテンツを有することができる。一例として、端末デバイスの識別子（例えば、UE－ID）が使用される。例えば、初期アクセスシナリオでは、メッセージ3はRRC設定要求（RRCSetupRequest）メッセージである。この場合、メッセージ3は、端末デバイスの一意の識別子または乱数を搬送する。端末デバイスがRRC接続を再確立するシナリオでは、メッセージ3はRRC再確立要求（RRCReestablishmentRequest）メッセージであり、対応するシナリオ情報の識別子はC－RNTIである。RRC接続再開シナリオの場合、メッセージ3はRRC再開要求（RRCResumeRequest）メッセージであり、対応するシナリオ情報の識別子はC－RNTIであってもよい。端末デバイスがRRC接続状態にある別のシナリオでは、メッセージ3で搬送される端末デバイスの一意の識別子はC－RNTIであってもよい。例えば、メッセージ2は、アップリンクリソースおよびTAコマンドを搬送することができる。このようにして、メッセージ2を受信した後に、端末デバイスは、TAコマンドにより示されるTA値を使用して、メッセージ2により示されるアップリンクリソース上でメッセージ3を送信する。

ステップ304：メッセージ3を検出すると、ネットワークデバイスは競合解決メッセージを端末デバイスに送信し、端末デバイスはネットワークデバイスから競合解決メッセージを受信する。

競合解決メッセージは、第4のメッセージまたはメッセージ4（MSG4）とも呼ばれる。メッセージ4は、メッセージ3の内容の一部、またはC－RNTIを含む物理ダウンリンク制御チャネル（physical downlink control channel、PDCCH）を含んでもよい、すなわち、メッセージ4は、PDCCHにより搬送されるC－RNTIを含む。

メッセージ4は、競合解決に使用される。競合解決メカニズムでは、ネットワークデバイスは、ネットワークに正常にアクセスした端末デバイスを指定するために、メッセージ4に一意の識別子を含み（メッセージ3は端末デバイスの一意の識別子を含む）、競合解決に失敗した別の端末デバイスは、ランダムアクセスを再び開始する。

例えば、ネットワークデバイスが端末デバイスにより送信されたアップリンクデータを受信した場合、メッセージ4は端末デバイスの識別子を搬送することができる。ネットワークデバイスが端末デバイスにより送信されたアップリンクデータを受信しない場合、ネットワークデバイスにより送信されたメッセージ4は端末デバイスの識別子を含まない。メッセージ4を受信すると、端末デバイスは、メッセージ4で搬送された端末デバイスの識別子が端末デバイス自体の識別子と一致するかどうかに応じて、端末デバイスがネットワークデバイスに正常にアクセスしたかどうか判定することができる。2つの識別子が一致する場合には、端末デバイスがネットワークデバイスに正常にアクセスしたと判定されるか、または、2つの識別子が一致しない場合には、端末デバイスがネットワークデバイスにアクセスできないと判定される。

任意選択で、メッセージ4の後に、端末デバイスによりネットワークデバイスに送信されたメッセージ5がさらに含まれてもよい。メッセージ5は、端末デバイスの能力情報を送信するために使用されてもよい。具体的な方式については、以下の図7を参照されたい。本明細書では詳細を繰り返さない。

上記は、競合ベースのランダム・アクセス・プロセスの実装プロセスを説明し、非競合ベースのランダム・アクセス・プロセスの実装のための参照を提供することに留意されたい。競合ベースのランダム・アクセス・プロセスとは異なり、非競合ベースのランダム・アクセス・プロセスの場合、ランダム・アクセス・パラメータは、上記のパラメータに加えて、powerRampingStepHighPriorityおよびscalingFactorBIをさらに含んでもよい。

一例として、5G通信システムが使用される。端末デバイスは、REDCAP端末デバイス、NB－IoT端末デバイス、またはMTC端末デバイスなどのいくつかの特別な端末デバイスであってもよい。リソースおよびアクセス方式は、低減された能力の端末デバイスの狭帯域幅および低電力消費の要件を満たすために、これらの低減された能力の端末デバイスに対応して割り当てられる必要がある。これに基づいて、そのようなデバイスがネットワークデバイスにアクセスするとき、ネットワークデバイスは、アクセスされた端末デバイスが低減された能力の端末デバイスであるかどうかを可能な限り早く知る必要があり、その結果、アクセスネットワークデバイスは、低減された能力の端末デバイスのための対応するリソースをより早くスケジュールするか、または低減された能力の端末デバイスに対してアクセス制御を実行することができる。

前述のアーキテクチャに基づいて、本出願の一実施形態は、本出願の実施形態で提供される前述のアーキテクチャが適用された後に端末デバイスのアクセス手順を実施するための通信方法を提供する。図4に示されているように、本方法は以下のステップを含んでもよい。

ステップ401：ネットワークデバイスの第1のユニットは端末デバイスから第1の情報を取得する。

いくつかの実施形態では、第1のユニットはネットワークデバイスのDUであってもよく、第2のユニットはネットワークデバイスのCUである。この場合、ネットワークデバイスは、端末デバイスにより送信された第1の情報に基づいて第1の情報を取得し得る。あるいは、第1のユニットはネットワークデバイスのCUであり、第2のユニットはネットワークデバイスのDUである。この場合、ネットワークデバイスは、ネットワークデバイスのDUを介して端末デバイスから第1の情報を受信することができる。いくつかの他の実施形態では、第1のユニットはネットワークデバイスのターゲットDUであってもよく、第2のユニットはネットワークデバイスのターゲットCUであってもよい。すなわち、端末は、移動などの理由に基づいて、ソースCUからターゲットCUにハンドオーバされ、ソースDUからターゲットDUにハンドオーバされる。この場合、第1のユニットはネットワークデバイスのターゲットDUであってもよい。したがって、ネットワークデバイスのCUは、ハンドオーバプロセスにおいて端末デバイスからネットワークデバイスのターゲットDUに第1の情報を送信することができ、その結果、ネットワークデバイスのターゲットDUは、端末デバイスから第1の情報を取得する。あるいは、CUは変更されず、端末デバイスはソースDUからターゲットDUにハンドオーバされる。この場合、第1のユニットはネットワークデバイスのターゲットDUであってもよく、第2のユニットはネットワークデバイスのターゲットCUであってもよい。したがって、ハンドオーバプロセスにおいて、ネットワークデバイスは、ネットワークデバイスのソースCUを介して端末デバイスからネットワークデバイスのターゲットCUに第1の情報をまず送信し、次いで、ネットワークデバイスのターゲットCUを介して端末デバイスからネットワークデバイスのターゲットDUに第1の情報を送信することができ、その結果、ネットワークデバイスのターゲットDUは、端末デバイスから第1の情報を取得する。

第1の情報は端末デバイスのタイプを示し、端末デバイスのタイプは、端末デバイスは低減された能力の端末デバイスであるか、または端末デバイスのタイプは低減された能力の端末デバイスのタイプであること、を含む。

具体的な指示方法については、以下の方式1～方式3を参照されたい。本明細書では詳細を繰り返さない。

ステップ402：ネットワークデバイスの第1のユニットはネットワークデバイスの第2のユニットへ第2の情報を送信する。

第2の情報は端末デバイスのタイプを示し、端末デバイスのタイプは、端末デバイスは低減された能力の端末デバイスであるか、または端末デバイスのタイプは低減された能力の端末デバイスのタイプであること、を含む。

いくつかの実施形態では、第2の情報は、端末デバイスが低減された能力の端末デバイスであることを示す。例えば、第2の情報は、端末デバイスの識別子に基づいて端末デバイスのタイプを識別することができる。例えば、第2の情報は端末デバイスの識別子であり、識別子＝0は端末デバイスにタイプが構成されていないことを示す。識別子＝1は、端末デバイスがREDCAP端末デバイスであることを示す。識別子＝2は、端末デバイスがNB－IoT端末デバイスであることを示す。識別子＝3から10は、将来の使用のために予約されている。識別子＝11は、端末デバイスがアクセスクラス11に対応する端末デバイスであることを示し、以下同様である。

別の例では、第2の情報は、端末デバイスが、そのサポートされる受信アンテナの最大数が2である低減された能力の端末デバイスであることをさらに示してもよいし、または端末デバイスが、そのサポートされる受信アンテナの最大数が1である低減された能力の端末デバイスであることを示してもよいし、または端末デバイスが、その最大サポート帯域幅が40Mである低減された能力の端末デバイスであることを示してもよいし、または端末デバイスが、その最大サポート帯域幅が20Mである低減された能力の端末デバイスであることなどを示してもよい。具体的には、第2の情報は、端末デバイスの識別子に基づいてさらに分類されてもよい。詳細については、前述の例を参照されたい。

いくつかの他の実施形態では、第2の情報は、低減された能力の端末デバイスのタイプを示すことができる。第2の情報が低減された能力の端末デバイスを示す方式と比較して、第2の情報が低減された能力の端末デバイスのタイプを示す場合、より多くのビットが対応して設定され得る。例えば、低減された能力の端末デバイスのタイプは、2つの受信アンテナを有する低減された能力の端末デバイスまたは1つの受信アンテナを有する低減された能力の端末デバイスなどのタイプであってもよい。この場合、低減された能力の端末デバイスのタイプは、第2の情報の2bitにより示されてもよい。例えば、第2の情報の00は高い能力の端末デバイスを示し、第2の情報の11は2つの受信アンテナを有する低減された能力の端末デバイスを示し、第2の情報の01は1つの受信アンテナを有する低減された能力の端末デバイスを示す。

前述の方法によれば、端末デバイスから第1の情報を取得した後に、ネットワークデバイスのCUまたはネットワークデバイスのDUは、端末デバイスが低減された能力の端末デバイスであるかどうかに関する情報を共有することができ、その結果、ネットワークデバイスのCUは、アクセスされた低減された能力の端末デバイスに対して時間内にアクセス制御を実行することができ、ネットワークデバイスのDUは、アクセスされた低減された能力の端末デバイスのリソースを時間内に適切にスケジュールするか、または低減された能力の端末デバイスのアクセス優先順位を適切に割り当てることができ、低減された能力の端末デバイスのより早く、かつよりタイムリーな管理を実施し、低減された能力の端末デバイスのネットワーク性能を最適化することができる。

以下では、本出願のこの実施形態における解決策を説明するために特定の例を使用する。

実施例1
前述のアーキテクチャに基づいて、本出願の一実施形態は、本出願の実施形態で提供される前述のアーキテクチャが適用された後に端末デバイスのアクセス手順を実施するための通信方法を提供する。図5に示されるように、方法は以下のステップを含んでもよい。

ステップ501：端末デバイスが第1の情報を第1のDUへ送信する。

いくつかの実施形態では、ネットワークデバイスにアクセスするとき、端末デバイスは、ランダム・アクセス・プロセスにおいてメッセージ1またはメッセージ3を介してネットワークデバイスのDUに第1の情報を送信することができる。これに対応して、ネットワークデバイスのDUは、ランダム・アクセス・プロセスにおけるメッセージ1またはメッセージ3を介して、端末デバイスにより送信された第1の情報を受信し、その結果、UEのタイプが識別され得る。

ネットワークデバイスのDUが、ランダム・アクセス・プロセスにおいてメッセージ1またはメッセージ3を介して、UEにより送信された第1の情報を受信する方式1および方式2が、例を用いて以下に説明される。

方式1：第1の情報は、メッセージ1で搬送されたリソース情報に基づいて決定される。

あるいは、第1の情報は、メッセージ1に対応するリソース情報に基づいて決定される。

例えば、特定のPRACH時間－周波数リソースまたは特定のpreamble符号語シーケンスが低減された能力の端末デバイスのために構成されることを考慮すると、端末デバイスが特定の時間－周波数リソースまたは特定の符号語シーケンスを選択した後に、端末デバイスは、メッセージ1を介して対応する時間－周波数リソースまたは符号語シーケンスを送信することができ、その結果、ネットワークデバイスのDUは、メッセージ1を介して送信された時間－周波数リソースまたは符号語シーケンスを第1の情報として使用することができ、ネットワークデバイスのDUは、端末デバイスの時間－周波数リソースまたは符号語シーケンスに基づいて端末デバイスが低減された能力の端末デバイスであると判定する。

別の例では、特定の初期帯域幅部分（bandwidth part、BWP）が低減された能力の端末デバイスのために構成されていることを考慮すると、端末デバイスが特定の初期BWPを選択した後に、端末デバイスは、特定の初期BWPに対応する時間－周波数リソースまたはコードワードシーケンスを介してメッセージ1を送信し、その結果、ネットワークデバイスのDUは、UEが低減された能力の端末デバイスであると判定するために、メッセージ1に対応する初期BWPを第1の情報として使用することができる。

方式1では、第1の情報は、PHY層に関する情報に基づいて決定される。したがって、PHY層を有するDUは、端末デバイスが低減された能力の端末デバイスであると判定するために、第1の情報を取得することができる。

方式1によれば、基地局は、後続のメッセージ2、メッセージ3、メッセージ4、および後続のメッセージをより適切にスケジュールすることができる。加えて、方式1によれば、基地局は、低減されていない能力の端末デバイスおよびREDCAP UEのアクセスのための優先処理を行うことができ、例えば、低減されていない能力の端末デバイスが優先的にアクセスされる。あるいは、基地局が、低減された能力のUEのために対応するリソースを優先的に構成する基地局である場合、REDCAP UEは、ネットワークにアクセスすることを優先的に許可される。したがって、低減された能力の端末デバイスにより開始されるランダム・アクセス・プロセスとハンドオーバイベント（またはBFRイベント）によりトリガされるランダム・アクセス・プロセスとは同じ優先順位を有してもよいし、異なる優先順位を有してもよいことがさらに設定されてもよい。

方式2：第1の情報は、ランダム・アクセス・プロセスにおいてメッセージ1またはメッセージ3の第2のフィールドを使用して搬送される。

第2のフィールドは、メッセージ1またはメッセージ3に導入され得る。例えば、第2のフィールドは、MAC制御要素（MAC control element、MAC CE）であってもよく、または第2のフィールドは、MACサブヘッダ内の新しい論理チャネル識別子（logical channel ID、LCID）フィールドであってもよい。第2のフィールドは、第1の情報を含んでもよい。

いくつかの実施形態では、端末デバイスは、第2のフィールドに第1の情報を含んでもよく、例えば、端末デバイスがREDCAP UEであることを示すためにREDCAPに関する情報およびREDCAPに関するタイプ情報が含まれる。別の例では、端末デバイスは、端末デバイスのタイプを示すために第2のフィールドに第1の情報を含んでもよく、例えば、端末デバイスはデフォルト端末デバイスであると指示され、または端末デバイスは緊急メッセージを送信するための端末デバイスであると示される。

方式2では、第1の情報は、MAC層に関する情報に基づいて決定される。したがって、MAC層を有するDUは、端末デバイスが低減された能力の端末デバイスであると判定するために情報を取得することができる。方式2によれば、基地局は、後続のメッセージ4および後続のメッセージをより適切にスケジュールすることができる。加えて、基地局は、共通UEおよびREDCAP UEのアクセスに対して優先処理を行うことができる。例えば、低減されていない能力の端末デバイスが優先的にアクセスされる。別の例では、基地局は、低減された能力の端末デバイスと低減されていない能力の端末デバイスとの間の競合問題をより適切にさらにスケジュールすることができる。

同様に、2ステップ非競合ベースのランダム・アクセス・プロセスでは、基地局は、ランダム・アクセス・プロセス内のメッセージAに基づいて（2ステップランダムアクセス処理におけるメッセージAは、4ステップランダムアクセス処理におけるメッセージ1とメッセージ3とを含む、すなわち、メッセージAはメッセージ1とメッセージ3とを結合したメッセージである）、端末デバイスが低減された能力の端末デバイスであると判定することができる。具体的な方法については、前述の方式1～方式2を参照されたい。本明細書では詳細を繰り返さない。

ステップ502：ネットワークデバイスの第1のDUはネットワークデバイスの第1のCUに第2のメッセージを送信する。

第2のメッセージは、第2の情報を含む。第2の情報は端末デバイスのタイプを示し、端末デバイスのタイプは、端末デバイスは低減された能力の端末デバイスであるか、または端末デバイスは低減された能力の端末デバイスのタイプであること、を含む。

具体的には、第2のメッセージは初期アップリンクRRCメッセージ転送（initial UL RRC message transfer）メッセージであってもよい。第2のメッセージは、新たに追加された第1のフィールドを含んでもよく、第1のフィールドは第2の情報を示す。

表1は、初期アップリンクRRCメッセージ転送に含まれ得るフィールドを示しており、これらは、例えばメッセージタイプフィールド（Message Type）、DU UE F1インターフェースアプリケーション識別子フィールド（gNB－DU UE F1AP ID）、NR構成済みグラント情報フィールド（NR（configured grant information、CGI））、ネットワークデバイスのDUを位置決めするために端末デバイスにより使用される端末デバイス識別子フィールドC－RNTI、アップリンクメッセージフィールド（UL－CCCH－Message IEまたはUL－CCCH 1－Message IE）を含むことができるRRCコンテナフィールド（RRC－Container）、DUからCU RRCコンテナフィールド（DU to CU RRC－Container）、SULアクセス指示フィールド（Access Indication）、トランザクション識別子フィールド（Transaction ID）、RAN UE識別子フィールド（RAN UE ID）、RRCセットメッセージ（RRCSetupComplete message）内のアップリンク制御情報要素（UL－DCCH－Message IE）を搬送するRRCコンテナセットフィールド（RRC－Container－RRCSetupComplete）、ならびに端末デバイスタイプフィールド（UE type）を含む。

例えば、表2に示されるように、第1のフィールドは、端末デバイスのタイプ（UE type）を示すことができ、第1のフィールドの第2の情報は、REDCAP、REDCAPのタイプ、または別のUEタイプのうちのいずれか1つを含んでもよい。

例えば、端末デバイスの識別子が使用されて端末デバイスのタイプを識別することができる。例えば、識別子＝0は、端末デバイスにタイプが構成されていないことを示す。識別子＝1は、端末デバイスがREDCAP端末デバイスであることを示す。識別子＝2は、端末デバイスがNB－IoT端末デバイスであることを示す。識別子＝3から10は、将来の使用のために予約されている。識別子＝11は、端末デバイスがアクセスクラス11に対応する端末デバイスであることを示し、以下同様である。

本出願のこの実施形態では、タイプ情報は、複数の方式で端末デバイスのタイプを示すことができる。一例では、タイプ情報は4ビットを含むことができ、UE typeは合計16個の値を有する。例えば、4ビットの値が0000である場合、それは、UE type＝0であることを示し、これは、端末デバイス、例えば、4つのアンテナを有する高能力端末デバイスのタイプに対応する。4ビットの値が0001であるとき、それは、UE type＝1であることを示し、これは、端末デバイスのタイプ、例えば、1つのアンテナを有する低減された能力の端末デバイスに対応する。4ビットの値が0010であるとき、それは、UE type＝2であることを示し、これは、端末デバイスのタイプ、例えば、2つのアンテナを有する低減された能力の端末デバイスなどに対応する。このようにして、第2のネットワークデバイスは、タイプ情報により示されるUE typeに基づいて端末デバイスのタイプを判定することができる。例えば、UE type＝1の場合、端末デバイスは第1のタイプの端末デバイスと判定され得る。さらに別の例では、タイプ情報は1ビットを含んでもよい。ビットの値が1である場合、それは端末デバイスが第1のタイプの端末デバイスであることを示す。ビットの値が0である場合、それは端末デバイスが第1のタイプの端末デバイスではないことを示す。さらに別の例では、本出願のこの実施形態における端末デバイスがREDCAP端末デバイスまたはNB－IoT端末デバイスであり得ることを考慮すると、タイプ情報は2ビットを含むことができ、1ビットの値は、端末デバイスがREDCAP端末デバイスであるかどうかを示すために使用され（例えば、値が1である場合には、それは端末デバイスがREDCAP端末デバイスであることを示し、または値が0である場合には、それは端末デバイスがREDCAP端末デバイスではないことを示す）、他方のビットは、端末デバイスがNB－IoT端末デバイスであるかどうかを示すために使用される（例えば、値が1である場合には、端末デバイスがNB－IoT端末デバイスであることを示し、または値が0である場合には、それは端末デバイスがNB－IoT端末デバイスではないことを示す）。あるいは、タイプ情報は2ビットを含むことができ、2ビットの値は、端末デバイスのタイプを示すために一緒に使用される。例えば、00は端末デバイスがREDCAP端末デバイスであることを示し、01は端末デバイスがNB－IoT端末デバイスであることを示し、10は端末デバイスがREDCAP端末デバイスでもNB－IoT端末デバイスでもないことを示し、11は将来の使用のために予約されている。

本出願の本実施形態では、第2のメッセージは、代替として、ランダム・アクセス・プロセスにおいて別のDUによりCUに送信されたメッセージであってもよいことに留意されたい。例えば、第2のメッセージは、新たに追加されたメッセージであり、第1のフィールドを搬送するために使用され、その結果、DUは、第2のメッセージをCUに送信して、端末デバイスが低減された能力の端末デバイスであるかどうかをCUに通知することができる。

ステップ503：第1のCUは、第2の情報に基づいて、ネットワークにアクセスするよう端末デバイスを制御し得る。

例えば、ネットワークデバイスのCUが、現在のネットワーク負荷が重いと判定した場合、ネットワークデバイスの第1のCUは、低減された能力の端末デバイスのアクセスを拒否することができる。あるいは、ネットワークデバイスの第1のCUが、現在のネットワークリソースが堅牢であると判定した場合、ネットワークデバイスの第1のCUは、低減された能力の端末デバイスのアクセスを許可し得る。ステップ503は任意選択のステップであることに留意されたい。

実施例2
前述のアーキテクチャに基づいて、本出願の一実施形態は、本出願の実施形態で提供される前述のアーキテクチャが適用された後に端末デバイスのアクセス手順を実施するための通信方法を提供する。図6に示されているように、本方法は以下のステップを含んでもよい。

ステップ601：端末デバイスは、ネットワークデバイスの第1のDUを介してネットワークデバイスの第1のCUに第1の情報を送信する。

第1の情報は端末デバイスのタイプを示し、端末デバイスのタイプは、端末デバイスがREDCAP端末デバイスであること、または端末デバイスのタイプが低減された能力の端末デバイスのタイプであること、を含む。

いくつかの実施形態では、ネットワークデバイスにアクセスするとき、端末デバイスは、ネットワークデバイスのDUを介したランダム・アクセス・プロセスにおいて、メッセージ3を介してネットワークデバイスのCUに第1の情報を送信することができる。具体的には、ネットワークデバイスのDUは、UEにより送信されたメッセージ3を最初に受信するが、メッセージ3内のRRCメッセージの内容を解析せず、メッセージ3内のRRCメッセージをネットワークデバイスのCUに送信する。これに対応して、ネットワークデバイスのCUは、ランダム・アクセス・プロセスにおけるメッセージ3を介して、端末デバイスにより送信された第1の情報を受信し、その結果、UEのタイプが識別され得る。

ネットワークデバイスのCUが、ランダム・アクセス・プロセスにおけるメッセージ3を介して、UEにより送信された第1の情報を受信する方式3が、例を用いて以下に説明される。

方式3：端末デバイスは、ランダム・アクセス・プロセスにおけるメッセージ3内のRRCメッセージに基づいて、低減された能力の端末デバイスとして判定される。

いくつかの実施形態では、端末デバイスは、メッセージ3で搬送されるRRCメッセージ（例えば、RRCSetupRequestメッセージ）内の予約フィールドを第1のフィールドとして使用することができる。言い換えると、メッセージ3で搬送されるRRCメッセージは第1のフィールドを含む。第1のフィールドは、第1の情報を含み、UEがREDCAP UEであるかどうかを示すために使用される。

いくつかの他の実施形態では、端末デバイスは、メッセージ3で搬送されるRRCメッセージのサイズを拡張することができる。例えば、RRCメッセージに新たに追加されたフィールドが第1のフィールドとして使用される。言い換えると、メッセージ3で搬送されるRRCメッセージは第1のフィールドを含む。第1のフィールドは、第1の情報を含み、UEがREDCAP UEであるかどうかを示すために使用される。

いくつかの他の実施形態では、端末デバイスは、メッセージ3のRRCメッセージとして新しい共通制御チャネルおよび新しいRRCメッセージを導入することができる。新しいRRCメッセージは第1のフィールドを含み、第1のフィールドは第1の情報を含み、UEがREDCAP UEであるかどうかを示すために使用される。

方式3によれば、基地局は、REDCAP UEのアクセスをより早く制御することができる。例えば、REDCAP UEは、ネットワークリソースが不足すると、ネットワークへのアクセスを拒否される。別の例では、ネットワークリソースが堅牢である場合、REDCAP UEはネットワークへのアクセスを許可される。

方式3で識別された情報がRRC層に関する情報であることを考慮すると、RRC層を有するCUのみが情報を取得して、端末デバイスが低減された能力の端末デバイスであると判定することができる。PHY層およびMAC層を有するDUは、REDCAP UEの識別情報を知らず、後続のメッセージを適切にスケジュールすることも、UEのアクセスのための優先処理を行うこともできない。

同様に、2ステップ非競合ベースのランダム・アクセス・プロセスでは、基地局は、ランダム・アクセス・プロセス内のメッセージAに基づいて（2ステップランダムアクセス処理におけるメッセージAは、4ステップランダムアクセス処理におけるメッセージ1とメッセージ3とを含む、すなわち、メッセージAはメッセージ1とメッセージ3とを結合したメッセージである）、端末デバイスが低減された能力の端末デバイスであると判定することができる。具体的な方法については、前述の方式3を参照されたい。本明細書では詳細を繰り返さない。

ステップ602：ネットワークデバイスの第1のCUは、ネットワークデバイスの第1のDUに第1のメッセージを送信する。

第1のメッセージは第2の情報を含む。第2の情報は、UEのタイプを示し、端末デバイスのタイプは、端末デバイスがREDCAP端末デバイスであることを含む。

いくつかの実施形態では、第1のメッセージは、ネットワークデバイスのCUによりネットワークデバイスのDUに送信されるダウンリンクRRCメッセージ転送（DL RRC message transfer）メッセージであってもよい。この場合、第1のメッセージは新たに追加された第1のフィールドを含むことができ、第1のフィールドは第2の情報を搬送する。

表3は、ダウンリンクRRCメッセージ転送メッセージに含まれ得るフィールドを示しており、これらは、例えばメッセージタイプフィールド（Message Type）、CU UE F1インターフェースアプリケーション識別子フィールド（gNB－CU UE F1AP ID）、DU UE F1インターフェースアプリケーション識別子フィールド（gNB－DU UE F1AP ID）、RRC containerがRRC接続設定に関する情報を含むときに使用される旧DU UE F1インターフェースアプリケーション識別子フィールド（old gNB－DU UE F1AP ID）、新しいDU UE F1インターフェースアプリケーション識別子フィールド（old gNB－DU UE F1AP ID）、SRB識別子フィールド（SRB ID）、重複実行フィールド（Execute Duplication）、ダウンリンクメッセージフィールド（DL－DCCH－Message IE）を含み得るRRCコンテナフィールド（RRC－Container）、RAT周波数優先順位情報フィールド（RAT－Frequency Priority Information）、RRC配信ステータス要求フィールド（RRC Delivery Status Request）、端末デバイスコンテキスト検索不能フィールド（UE Context not retrievable）、リダイレクトされたRRCメッセージフィールド（redirected RRC message）、ネットワーク共有のためのPLMN支援情報（PLMN Assistance Info for Network Sharing）のフィールド、第1のフィールド、例えば、端末デバイスタイプフィールド（UE type）を含む。

例えば、表3および表2を参照すると、第1のメッセージで搬送される第1のフィールドは、端末デバイスのタイプ（UE type）を示すために使用されてもよく、第1のフィールドの値の範囲は、REDCAP、REDCAPのタイプ、または別のUEタイプを含んでもよい。例えば、端末デバイスの識別子は、端末デバイスのタイプを識別するために使用されてもよく、識別子＝0は、端末デバイスにパラメータが構成されていないことを示す。識別子＝1は、端末デバイスがREDCAP端末デバイスであることを示す。識別子＝2は、端末デバイスがNB－IoT端末デバイスであることを示す。識別子＝3から10は、将来の使用のために予約されている。識別子＝11は、端末デバイスがアクセスクラス11に対応する端末デバイスであることを示し、以下同様である。確かに、前述の例における端末デバイスのタイプを設定する方式も参照され得る。例えば、対応して設定されたタイプの低減された能力の端末デバイスは、対応する識別子＝3の2つのアンテナを有する低減された能力の端末デバイスと、対応する識別子＝4の1つのアンテナを有する低減された能力の端末デバイスと、を含む。本明細書では詳細を繰り返さない。

いくつかの他の実施形態では、第1のメッセージは、代替として、端末デバイスコンテキスト設定要求（UE context setup request）メッセージであってもよい。この場合、第1のフィールドが端末デバイスコンテキスト設定要求メッセージに新たに追加されてもよく、その結果、第1のフィールドは第2の情報を搬送し、端末デバイスが低減された能力の端末デバイスであるかどうかを示すために使用される。

本出願のこの実施形態では、第1のメッセージは、代替として、ランダム・アクセス・プロセスにおいて別のCUによりDUに送信されたメッセージまたは第1のフィールドを搬送するために使用される新たに追加されたメッセージであってもよく、その結果、CUは、端末デバイスが低減された能力の端末デバイスであるかどうかをDUに通知するために、第1のメッセージをDUに送信することができることに留意されたい。

ステップ603：第1のDUは第2の情報に基づいて低減された能力の端末デバイスのための後続のランダムアクセスメッセージまたは別のメッセージをスケジュールし得る。

ステップ603は任意選択のステップであることに留意されたい。例えば、ネットワークデバイスの第1のDUは、低減された能力の端末デバイスの能力範囲内で後続のメッセージ4またはメッセージ5をスケジュールする。具体的には、第1のDUは、低減された能力の端末デバイスのために対応するリソースを構成することができる。具体的な構成済みリソースについては、図4のランダム・アクセス・プロセスの説明を参照されたい。本明細書では詳細を繰り返さない。

任意選択で、ネットワークデバイスの第1のCUは、第2の情報に基づいて、低減された能力の端末デバイスのための、低減された能力の端末デバイスのアクセス優先順位を決定してもよい。

例えば、ネットワークデバイスの第1のCUは、低減された能力の端末デバイスのアクセス優先順位を低い優先順位に設定し、低減されていない能力の端末デバイスのアクセス優先順位を低い優先順位に設定することができ、その結果、低減された能力の端末デバイスおよび低減されていない能力の端末デバイスが同時にネットワークにアクセスするとき、低減されていない能力の端末デバイスがネットワークにアクセスすることを優先する。

端末デバイスの前述のアクセス手順が完了された後に、端末デバイスは、端末デバイスの移動により引き起こされる現在のセルの信号品質の悪さ、または基地局が大量の端末デバイスに現在アクセスしている場合による輻輳のために、さらにハンドオーバされる必要があり得る。ネットワークデバイスのCUは、ハンドオーバプロセスにおいて、端末デバイスがランダム・アクセス・プロセスを再開始することなくRRC接続を設定できることを保証するために、端末デバイスの記憶されたコンテキストに基づいてハンドオーバ手順を開始することができ、それにより遅延を低減し、シグナリングオーバーヘッドを低減する。加えて、新しいRRC状態が考慮される：非アクティブ状態（inactive state）では、アイドル状態と同じ省電力効果を達成するために、端末デバイスとネットワークとの間のRRC接続が中断される。アイドル状態とは異なり、非アクティブ状態では、端末デバイスおよびアクセスネットワークデバイスは、端末デバイスのコンテキストを記憶する。端末デバイスが接続状態に入る必要があるとき、例えば、端末デバイスが送信すべきアップリンクデータを有するとき、またはネットワークデバイスが端末デバイスをページングして接続状態に入るとき、端末デバイスは、端末デバイスの記憶されたコンテキストに基づいて接続状態に入り、それにより遅延を低減し、シグナリングオーバーヘッドを低減する。以下では、端末デバイスのコンテキスト設定手順を説明するために例を使用する。詳細については、図7を参照されたい。

ステップ701：端末デバイスは、能力情報をネットワークデバイスのCUに送信する。

能力情報は、端末デバイスの能力を示す。

任意選択で、能力情報は、端末デバイスがinactive状態でデータを送信する能力を有することを示し、能力は、端末デバイスが非アクティブ状態で構成済みグラントまたはスケジューリンググラントでアップリンク情報を送信する能力を有することを示す。アップリンク情報は、アップリンクシグナリングおよびアップリンクデータを含むが、これらに限定されない。アップリンクシグナリングはアップリンクRRCシグナリングなどであってもよく、アップリンクデータはアップリンクサービスデータ、例えばビデオデータやオーディオデータであってもよい。

スケジューリンググラントは、端末デバイスにより送信されたリソース要求に基づいてネットワークデバイスにより端末デバイスに割り当てられたリソースを指すことに留意されたい。例えば、リソース要求は、ランダム・アクセス・プロセスにおけるプリアンブル（preamble）であってもよく、アップリンクスケジューリング要求などであってもよい。構成済みグラントは、ネットワークデバイスにより事前構成されたリソースを指し、端末デバイスはリソース要求を送信する必要がない。リソースは1回割り当てられ、複数回使用される。

端末デバイスは複数の能力を有し、能力情報は端末デバイスの別の能力をさらに示すことができることに留意されたい。これは、本出願のこの実施形態では限定されない。

ネットワークデバイスのCUは、コアネットワークデバイスから端末デバイスの能力情報をさらに取得し得ることに留意されたい。ネットワークデバイスのCUがコアネットワークデバイスから端末デバイスの能力情報を取得する場合、ネットワークデバイスのCUは、端末デバイスから端末デバイスの能力情報を取得する必要がない、すなわち、この場合、端末デバイスは、ネットワークデバイスのCUに能力情報を送信する必要がない。

ステップ702：ネットワークデバイスのCUは、ネットワークデバイスのDUにUEコンテキスト設定要求メッセージを送信する。

UEコンテキスト設定要求メッセージは、端末デバイスのコンテキスト（context）を設定するように要求するために使用されてもよい。

任意選択で、UEコンテキスト設定要求メッセージは能力情報を含んでもよい。

ステップ703：ネットワークデバイスのDUが端末デバイスのコンテキストを設定し、ネットワークデバイスのCUにUEコンテキスト設定応答メッセージを送信する。

本出願のこの実施形態では、コンテキストは、エアインターフェースコンテキストおよびF1コンテキストを含んでもよいことに留意されたい。

エアインターフェースコンテキストは、端末デバイスのRLC層構成、MAC層構成、物理層構成情報、I－RNTI、C－RNTIなどを指し得、「非アクティブ状態におけるデータ送信のための構成済み許可」、物理層フィードバック情報を送信するためのPDCCH構成情報、およびPDCCHをスクランブルするためのRNTIをさらに含んでもよい。F1コンテキストは、F1AP ID、F1データ伝送のためのトランスポート層アドレス情報などを参照することができる。端末デバイスのDRBデータは、ネットワークデバイスのCUとネットワークデバイスのDUとの間で送信され、F1データ送信とも呼ばれ得る。

本出願の本実施形態では、端末デバイスのためにネットワークデバイスのDUにより設定されるコンテキストは、以下のうちの1つまたは複数を含むことができる：

1．端末デバイスのために構成された物理ダウンリンク制御チャネル（physical downlink control channel、PDCCH）の構成情報。PDCCHの構成情報は、アップリンクデータのフィードバック情報を送信するため、またはPUSCH送信をスケジュールするため、および物理ダウンリンク共有制御チャネル（physical downlink control channel、PDSCH）送信をスケジュールするためなどに使用されてもよい。

PDCCHの構成情報は、PDCCHのリソース位置情報、周期、開始位置などを含むが、これらに限定されない。

本出願のこの実施形態では、PDCCHは、物理層シグナリング、例えば、肯定応答（Acknowledgement、ACK）または否定応答（Negative Acknowledgement、NACK）シグナリング、初期送信のためのアップリンクグラント、および再送信のためのアップリンクグラントのうちの少なくとも1つの送信をスケジュールすることができる。PDCCHはPDSCHの送信をさらにスケジュールすることができ、PDSCHで搬送される情報は、ダウンリンクRRCシグナリング、ダウンリンクデータ、およびタイミングアドバンスのためのコマンドのうちの1つまたは複数を含むが、これらに限定されない。端末デバイスは、PDCCHのスケジューリングに基づいてアップリンク送信およびダウンリンク送信を実行することができる。

2．PDCCHをスクランブルするための一時的な識別子。一時識別子は、PDCCHをスクランブルするための32ビットの無線ネットワーク一時識別子（radio network temporary identity、RNTI）である。例えば、一時的識別子は、端末デバイスのセル無線ネットワーク一時識別子（cell radio network temporary identity、C－RNTI）であってもよい。

3．無線ベアラのものであり、端末デバイスのために構成されたRLC層の構成情報。

4．端末デバイスのために構成されたMAC層の構成情報。

5．端末デバイスのために構成された非アクティブ無線ネットワーク一時識別子（inactive radio network temporary identity、I－RNTI）。

6．端末デバイスに対して構成された構成済みグラント。構成済みグラントは、端末デバイスに割り当てられたアップリンクリソースを示すために使用されてもよい。構成済みグラントは、物理アップリンク共有チャネル（physical uplink shared channel、PUSCH）、周波数領域リソース、周期、開始位置、およびデータ復調参照情報のうちの1つまたは複数を含んでもよいが、これらに限定されない。

任意選択で、構成済みグラントは、inactive状態の端末デバイスに対して構成されてもよく、inactive状態の端末デバイスは、構成済みグラントを使用してアップリンクRRCシグナリングおよびアップリンクデータのうちの1つまたは複数を送信してもよい。

任意選択で、構成済みグラントにより構成された時間－周波数リソースは、端末デバイスのための専用の時間－周波数リソース、すなわち、別の端末デバイスと共有されない時間－周波数リソースであってもよい。この場合、ネットワークデバイスのDUは、構成済みグラントと端末デバイスのコンテキストとの間のマッピング関係、および構成済みグラントと端末デバイスのデータ送信チャネルとの間のマッピング関係を確立することができる。

任意選択で、構成済みグラントにより構成された時間－周波数リソースは、端末デバイスにより別の端末デバイスと共有される時間－周波数リソースであってもよい。この場合、端末デバイスが非アクティブ状態に入ったと判定すると、ネットワークデバイスのCUは、inactive I－RNTIをネットワークデバイスのDUに送信することができる。ネットワークデバイスのDUは、構成済みグラントと端末デバイスのI－RNTIとの間のマッピング関係を確立することができる。I－RNTIは、無線ネットワークベースの通知領域（RAN－based notification area、RNA）における非アクティブ状態の端末デバイスの一意の識別子であってもよい。

上記は単なる例であり、端末デバイスのコンテキストは他の情報をさらに含んでもよいことに留意されたい。これは、本出願のこの実施形態では限定されない。本明細書の例を再度使用して詳細は説明されない。例えば、ネットワークデバイスのCUにより送信されるUEコンテキスト設定応答メッセージは、端末デバイスのコンテキストを含んでもよい。

図7に示される手順では、主要なステップのみが記載されている。端末デバイスのためのコンテキストを設定するプロセスには他のステップがあってもよい。本明細書では詳細を繰り返さない。端末デバイスのコンテキストは、図7に示される手順に従って設定される。

コンテキストを元々記憶しているアクセスネットワークデバイスのカバレッジ範囲を出た後に、端末デバイスは新しいアクセスネットワークデバイスへのRRC再開手順を開始する必要があることを考慮する。以下では、例を使用して具体的なシナリオを説明する。

シナリオ1
図8に示されるように、端末デバイスは、セル1から近傍セル2に移動する。この場合、CUは変更されないままであり得、端末デバイスは、ソース・ネットワーク・デバイスのDUからターゲット・ネットワーク・デバイスのDUにハンドオーバされる。この場合、ソース・ネットワーク・デバイス（例えば、第4のネットワークデバイス）は第1のCUおよび第2のDUを含み、ターゲット・ネットワーク・デバイス（例えば、第1のネットワークデバイス）は第1のCUおよび第1のDUを含む。

CU－DUアーキテクチャのネットワークデバイスの場合、ネットワークデバイスのCUは、端末デバイスのRRC状態を管理する役割を担う。ネットワークデバイスのCUは、端末デバイスのコンテキスト（端末デバイスの能力情報および別の端末デバイスの構成情報を含む）を格納する。ネットワークデバイスのCUが変更されないままであり、ネットワークデバイスのDUがハンドオーバされるシナリオでは、ネットワークデバイスのCUは、端末デバイスのコンテキストをターゲット・ネットワーク・デバイスのDUに送信することができ、ターゲット・ネットワーク・デバイスのDUは、受信した端末デバイスのコンテキストに基づいて端末デバイスのために端末デバイスのランダム・アクセス・プロセスを開始し、ターゲット・ネットワーク・デバイスにアクセスするDUにより使用されるプリアンブルおよびC－RNTIを割り当て、その結果、端末デバイスは、ターゲット・ネットワーク・デバイスのDUを介してネットワークデバイスのCUにアクセスすることができる。このようにして、端末デバイスのランダム・アクセス・プロセスが完了される。

ハンドオーバプロセスでは、ネットワークデバイスのCUは、端末デバイスが低減された能力の端末デバイスであるかどうかを示す第2の情報を含まなくてもよい。例えば、ハンドオーバが発生したとき、端末デバイスのコンテキストで搬送されたUE能力情報に基づいて、UEが低減された能力の端末デバイスであると判定されることはできない。この場合、ターゲット・ネットワーク・デバイスのDUは、低減された能力の端末デバイスに、低減された能力の端末デバイスと一致するプリアンブルまたはC－RNTIを割り当てることができない。この場合、ターゲット・ネットワーク・デバイスのDUは、後続のメッセージを適切にスケジュールすることができず、UEのアクセスのための優先順位処理を行うことができない。

前述の問題に基づいて、本出願の一実施形態は通信方法を提供する。図9に示されるように、通信方法は以下のステップを含む。

ステップ901：第1のCUは第1のDUへのハンドオーバの初期ハンドオーバ手順を開始する。

特定のハンドオーバ方式は、第1のCUが第1のDUへのハンドオーバのためのハンドオーバ要求を開始することであってもよい。

例えば、第1のDUはターゲットDUであり、第2のDUはソースDUである。ハンドオーバ要求は、端末デバイスをターゲットDUにハンドオーバするよう要求するために使用されてもよい。ハンドオーバ要求を受信した後に、ターゲットDUは、ハンドオーバ要求に基づいて端末デバイスのハンドオーバ手順をトリガする。

いくつかの実施形態では、端末デバイスの測定報告を受信した後に、第1のCUは、測定報告に基づいて、端末デバイスがハンドオーバされる必要があると判定することができる。具体的には、第1のCUが、受信した測定報告に基づいて、端末デバイスの現在の通信品質が低いと判定した場合、端末デバイスはハンドオーバされてもよい。この場合、ハンドオーバ要求は第1のエンティティに送信される。

さらに、端末デバイスの前述の測定報告手順は、第1のCUにより能動的にトリガされてもよく、または端末デバイスにより能動的に実行されてもよい。任意選択で、ハンドオーバ要求は、ハンドオーバ対象端末デバイスの識別子、ターゲットセルの識別子、およびターゲット周波数情報の各情報のうちの1つまたは複数を含む。

可能な実施態様では、第1のCUは、第2のDUにより送信されたセル輻輳状態報告をさらに受信することができる。レポートが、セルが現在輻輳状態にあることを示す場合、ネットワークデバイスのCUは、セル輻輳状態（例えば、優先順位の低いGBRを解放すること、エッジユーザを解放することなど）を緩和するための緩和ポリシーを対応して決定し、セル輻輳緩和要求を第1のエンティティに送信することができ、要求は決定された緩和ポリシーを含む。第1のエンティティは、緩和ポリシーに従って緩和処理を実行することができる。セル輻輳状態報告は、セル識別子およびベアラタイプ（例えば、GBRまたはnonGBR）、ARP、輻輳タイプ（例えば、GBR輻輳またはnon－GBR輻輳）、輻輳レベル（例えば、重度、軽度、輻輳していない）などの情報のうちの1つまたは複数を含む。

ステップ902：第1のCUは第1のDUへ第1のメッセージを送信する。

第1のメッセージは、第2の情報を含んでもよい。第2の情報は端末デバイスのタイプを示し、端末デバイスのタイプは、端末デバイスは低減された能力の端末デバイスであるか、または端末デバイスのタイプは低減された能力の端末デバイスのタイプであること、を含む。

いくつかの実施形態では、第1のメッセージは、第1のCUにより第1のDUに送信される端末デバイスコンテキスト要求（UE context setup request）メッセージであってもよい。第1のメッセージは、第1のフィールドを含んでもよい。第1のフィールドは、UEコンテキスト要求メッセージに新たに追加されるフィールドであってもよい。第1のフィールドは、UE情報を指示または識別するために使用されるか、またはUEタイプ情報を指示または識別するために使用される。別の例では、第1のフィールドは、UEコンテキスト要求メッセージ内のCUからDUへのRRC情報（CU to DU RRC information）フィールド内にあってもよい。

表4は、UEコンテキスト要求メッセージに含まれ得るフィールドを示しており、これらは、例えば、構成済みグラント確認情報フィールド（CG－ConfigInfo）、構成済み許可確認フィールド（CG－Config）、端末デバイス能力RATリストフィールド（UE－capabilityRAT－containerLis）、測定情報フィールド（MeasConfig）、ハンドオーバ準備情報フィールド（handover preparation information）、セルグループ情報フィールド（CellGroupConfig）、測定タイミング構成フィールド（measurement timing configuration）、ならびに第1のフィールド、例えば、端末デバイスタイプフィールド（UE type）を含む。

例えば、表4および表2を参照すると、第1のメッセージで搬送される第1のフィールドは、端末デバイスのタイプ（UE type）を示すために使用されてもよく、第1のフィールドの値の範囲は、REDCAP、REDCAPのタイプ、または別のUEタイプを含んでもよい。例えば、端末デバイスの識別子は、端末デバイスのタイプを識別するために使用されてもよく、識別子＝0は、端末デバイスにパラメータが構成されていないことを示す。識別子＝1は、端末デバイスがREDCAP端末デバイスであることを示す。識別子＝2は、端末デバイスがNB－IoT端末デバイスであることを示す。識別子＝3から10は、将来の使用のために予約されている。識別子＝11は、端末デバイスがアクセスクラス11に対応する端末デバイスであることを示し、以下同様である。

ステップ903：第1のDUは第2の情報に基づいて低減された能力の端末デバイスのための後続のランダムアクセスメッセージまたは別のメッセージをスケジュールし得る。

ステップ603は任意選択のステップであることに留意されたい。例えば、ネットワークデバイスのDUは、低減された能力の端末デバイスの能力範囲内の後続のランダム・アクセス・プロセスにおいてメッセージ（例えば、メッセージ4またはメッセージ5）をスケジュールする。具体的には、第1のDUは、低減された能力の端末デバイスのために対応するリソースを構成することができる。具体的な構成済みリソースについては、図4のランダム・アクセス・プロセスの説明を参照されたい。本明細書では詳細を繰り返さない。

任意選択で、第1のCUは、第2の情報に基づいて、低減された能力の端末デバイスのための低減された能力の端末デバイスのアクセス優先順位を決定してもよい。

例えば、第1のCUは、低減された能力の端末デバイスのアクセス優先順位を低い優先順位に設定し、低減されていない能力の端末デバイスのアクセス優先順位を低い優先順位に設定することができ、その結果、低減された能力の端末デバイスおよび低減されていない能力の端末デバイスが同時にネットワークにアクセスするとき、低減されていない能力の端末デバイスがネットワークにアクセスすることを優先する。

シナリオ2
図10に示されるように、端末デバイスは、セル1からセル3に移動する。この場合、端末デバイスは、ソース・ネットワーク・デバイスのCUからターゲット・ネットワーク・デバイスのCUにハンドオーバされ、端末デバイスは、ソース・ネットワーク・デバイスのDUからターゲット・ネットワーク・デバイスのDUにハンドオーバされる。この場合、ソース・ネットワーク・デバイス（例えば、第2のネットワークデバイス）は第2のCUおよび第2のDUを含み、ターゲット・ネットワーク・デバイス（例えば、第1のネットワークデバイス）は第1のCUおよび第1のDUを含む。

本出願の一実施形態は、通信方法を提供する。図11に示されるように、通信方法は以下のステップを含む。

ステップ1101：第2のCUは、第1のCUへのハンドオーバ手順を開始する。

例えば、ソース・ネットワーク・デバイスのCUは第2のCUであり、ターゲット・ネットワーク・デバイスのCUは第1のCUであり、ソース・ネットワーク・デバイスのDUは第2のDUであり、ターゲット・ネットワーク・デバイスのDUは第1のDUである。この場合、第2のCUは、端末デバイスのコンテキストを記憶する。ハンドオーバプロセスにおいて、第2のCUは、UEコンテキスト要求メッセージを介して、端末デバイスのコンテキスト（例えば、端末デバイスの能力情報を含んでもよい）をターゲット・ネットワーク・デバイスのCUに送信することができる。具体的なハンドオーバプロセスについては、ステップ901を参照されたい。本明細書では詳細を繰り返さない。

UEのコンテキスト要求メッセージは、第2の情報を含むことができ、第2の情報は、UEが低減された能力の端末デバイスであるかどうかに関する情報を示す。

ステップ1102：第1のCUは第1のDUへのハンドオーバ手順を開始する。

ターゲット・ネットワーク・デバイスのCUは、端末デバイスのコンテキスト（例えば、端末デバイスの能力情報を含んでもよい）をターゲット・ネットワーク・デバイスイスのDUに送信し、ターゲット・ネットワーク・デバイスのDUは、端末デバイスの受信したコンテキストに基づいて、ターゲット・ネットワーク・デバイスにアクセスするDUにより使用されるpreambleおよびC－RNTIを端末デバイスに割り当てる。このようにして、端末デバイスのランダム・アクセス・プロセスが完了される。具体的なハンドオーバプロセスについては、ステップ901を参照されたい。本明細書では詳細を繰り返さない。

ステップ1103：第1のCUは第1のDUへ第1のメッセージを送信する。

第1のメッセージは、第2の情報を含んでもよい。第2の情報は、端末デバイスのタイプを示す。端末デバイスのタイプは、端末デバイスが低減された能力の端末デバイスであること、または端末デバイスのタイプが低減された能力の端末デバイスのタイプであることを含む。

いくつかの実施形態では、第1のメッセージは、第1のCUにより第1のDUに送信されるUEコンテキスト要求（UE context setup request）メッセージであってもよい。第1のメッセージは、第1のフィールドを含んでもよい。第1のフィールドは、UEコンテキスト要求メッセージに新たに追加されるフィールドであってもよい。第1のフィールドは、UE情報を指示または識別するために使用されるか、またはUEタイプ情報を指示または識別するために使用される。別の例では、第1のフィールドは、UEコンテキスト要求メッセージ内のCUからDUへのRRC情報（CU to DU RRC information）フィールド内にあってもよい。

ステップ1104：第1のDUは第2の情報に基づいて低減された能力の端末デバイスのための後続のランダムアクセスメッセージまたは別のメッセージをスケジュールし得る。

ステップ603は任意選択のステップであることに留意されたい。例えば、第1のDUは、低減された能力の端末デバイスの能力範囲内の後続のランダム・アクセス・プロセスにおいてメッセージ（例えば、メッセージ4またはメッセージ5）をスケジュールする。具体的には、第1のDUは、低減された能力の端末デバイスのために対応するリソースを構成することができる。具体的な構成済みリソースについては、図4のランダム・アクセス・プロセスの説明を参照されたい。本明細書では詳細を繰り返さない。

前述のステップ1101から1104のすべてが実行される必要はないことに留意されたい。いくつかの実施形態では、ステップ1101から1104のいくつかが実行されてもよく、例えば、ステップ1101、ステップ1103、およびステップ1104が実行されるか、またはステップ1102、ステップ1103、およびステップ1104が実行される。これは本明細書では限定されない。

シナリオ3
端末デバイスのRRC状態が変化すると、ネットワークデバイスのCUは、関連するコンテキスト処理を実行するためにネットワークデバイスのDUに通知する必要がある。具体的には、端末デバイスがRRC接続状態からinactive状態に変化するプロセスにおいて、ネットワークデバイスのCUは、端末デバイスのコンテキストを解放するようにネットワークデバイスのDUに通知する。コンテキストは、すべての専用F1送信リソース、エアインターフェースの構成情報などを含む。ネットワークデバイスのDUが端末デバイスのコンテキストを解放する場合、inactive状態の端末デバイスがネットワークデバイスのDUにアップリンクデータを送信するとき、ネットワークデバイスのDUはネットワークデバイスのCUにデータを直ちに送信することができない。

端末デバイスがinactive状態で移動するとき、例えば、セル1からセル3に移動するとき、この場合、端末デバイスはRRC状態再開要求を再開する必要がある。ソース・ネットワーク・デバイスのDUからターゲット・ネットワーク・デバイスのDUへのハンドオーバを完了するプロセスにおいて、またはソース・ネットワーク・デバイスのCUからターゲット・ネットワーク・デバイスのCUへのハンドオーバおよびソース・ネットワーク・デバイスのDUからターゲット・ネットワーク・デバイスのDUへのハンドオーバのプロセスにおいて、UE能力情報に基づいてUEをREDCAP UEとして直接識別できない場合、ネットワークデバイスのDUは、preambleまたはC－RNTIを割り当てるときにUEがREDCAP UEであることを知らず、ネットワークデバイスのDUは、メッセージ1のpreambleまたはメッセージ3のC－RNTIに基づいて、UEがREDCAP UEであることを知ることができない。その結果、後続のメッセージは適切にスケジュールされることができず、またはUEのアクセスのために優先順位処理は行われることができない。以下では、ソース・ネットワーク・デバイス（例えば、第2のネットワークデバイス）が第2のCUおよび第2のDUを含み、ターゲット・ネットワーク・デバイス（例えば、第1のネットワークデバイス）が第1のCUおよび第1のDUを含む例について説明する。ソース・ネットワーク・デバイス（例えば、第3のネットワークデバイス）が第1のCUおよび第2のDUを含み、ターゲット・ネットワーク・デバイス（例えば、第1のネットワークデバイス）が第1のCUおよび第1のDUを含む方式については、この実施形態を参照されたい。

前述の問題に基づいて、本出願の一実施形態は通信方法を提供する。図12に示されるように、通信方法は以下のステップを含む。

ステップ1201：端末デバイスが第2のDUを介して第2のCUへのRRC接続再開手順を開始する。

例えば、第2のDUはソース・ネットワーク・デバイスのDUであってもよく、第2のCUはソース・ネットワーク・デバイスのCUであってもよい。第1のDUはターゲット・ネットワーク・デバイスのDUであってもよく、第1のCUはターゲット・ネットワーク・デバイスのCUであってもよい。この場合、端末デバイスは、ソース・ネットワーク・デバイスのDUを介してソース・ネットワーク・デバイスのCUへのRRC接続再開要求を開始する。RRC接続再開要求は、RRC接続状態の再開を要求するために用いられる。

ステップ1202：第2のCUは、第1のCUへのハンドオーバ手順を開始する。

この場合、ソース・ネットワーク・デバイスのCUは、端末デバイスのRRC接続再開要求および端末デバイスの記憶されたコンテキストに基づいて、端末デバイスがハンドオーバされる必要があると判定する。したがって、ソース・ネットワーク・デバイスのCUは、UEコンテキスト要求メッセージを介して、端末デバイスのコンテキスト（例えば、端末デバイスの能力情報を含んでもよい）をターゲット・ネットワーク・デバイスのCUに送信することができる。

ステップ1203：第1のCUは第1のDUへのハンドオーバ手順を開始する。

ターゲット・ネットワーク・デバイスのCUは、端末デバイスのコンテキスト（例えば、端末デバイスの能力情報を含んでもよい）をターゲット・ネットワーク・デバイスイスのDUに送信し、ターゲット・ネットワーク・デバイスのDUは、端末デバイスの受信したコンテキストに基づいて、ターゲット・ネットワーク・デバイスにアクセスするDUにより使用されるpreambleおよびC－RNTIを端末デバイスに割り当てる。このようにして、端末デバイスのランダム・アクセス・プロセスが完了される。

ステップ1204：第1のCUは第1のDUへ第1のメッセージを送信する。

ステップ1205：第1のDUは第2の情報に基づいて低減された能力の端末デバイスのための後続のランダムアクセスメッセージまたは別のメッセージをスケジュールし得る。

ステップ1205は任意選択のステップであることに留意されたい。例えば、DUは、低減された能力の端末デバイスの能力範囲内の後続のランダム・アクセス・プロセスにおいてメッセージ（例えば、メッセージ4またはメッセージ5）をスケジュールする。具体的には、DUは、低減された能力の端末デバイスのために対応するリソースを構成することができる。具体的な構成済みリソースについては、図4のランダム・アクセス・プロセスの説明を参照されたい。本明細書では詳細を繰り返さない。

任意選択で、CUは、第2の情報に基づいて、低減された能力の端末デバイスのための低減された能力の端末デバイスのアクセス優先順位を決定してもよい。例えば、CUは、低減されていない能力の端末デバイスのアクセス優先順位を低い優先順位に設定し、低減された能力の端末デバイスのアクセス優先順位を低い優先順位に設定することができ、その結果、低減された能力の端末デバイスと低減されていない能力の端末デバイスとが同時にネットワークにアクセスする場合、低減されていない能力の端末デバイスがネットワークにアクセスすることが優先される。

前述のステップ1201から1205のすべてが実行される必要はないことに留意されたい。いくつかの実施形態では、ステップ1201から1205のいくつかが実行されてもよく、例えば、ステップ1202、ステップ1204、およびステップ1205が実行されるか、またはステップ1203、ステップ1204、およびステップ1205が実行される。これは本明細書では限定されない。

前述の問題に基づいて、本出願の一実施形態は通信方法を提供する。端末デバイスは、第2の分散ユニットおよび第1の中央ユニット（例えば、第4のネットワークデバイス）を介してネットワークに最初にアクセスし、第1の分散ユニットおよび第1の中央ユニット（例えば、第1のネットワークデバイス）を介してネットワークに続いてアクセスし、次いで第3の分散ユニットおよび第1の中央ユニット（例えば、第5のネットワークデバイス）を介してネットワークにアクセスすることを示す。図13に示されるように、本方法は、以下のステップを含む。

ステップ1301a：端末デバイスが第2の分散ユニットに第1の情報を送信する。

ステップ1301aで、端末デバイスは、第2の分散ユニットおよび第1の中央ユニットを介してネットワークにアクセスし得る。この場合、端末デバイスが図5の第1の分散ユニットに第1の情報を送信する方式について参照されることができる。

ステップ1302a：第2の分散ユニットが第1の中央ユニットに第2のメッセージ1を送信する。

第2のメッセージ1については、端末デバイスが図5の第1の分散ユニットに第2のメッセージを送信する方式を参照されたい。

ステップ1301b：端末デバイスが第1の中央ユニットに第1の情報を送信する。

ステップ1301bで、端末デバイスは、第2の分散ユニットおよび第1の中央ユニットを介してネットワークにアクセスし得る。この場合、端末デバイスが図6の分散ユニットを介して中央ユニットに第1の情報を送信する方式について参照されることができる。

ステップ1301aおよびステップ1302aは可能な実施態様であり、ステップ1301bは可能な実施態様であることに留意されたい。

ステップ1303：第1の分散ユニットおよび第1の中央ユニットは端末デバイスの初期ハンドオーバ手順を開始する。

任意選択で、端末デバイスは、第1の分散ユニットにアクセスするために、第2の分散ユニットから第1の分散ユニットへの初期ハンドオーバを開始し得る。詳細については、図9のステップ901の第1の分散ユニットへのハンドオーバの実施態様を参照されたい。

ステップ1304：第1の中央ユニットは第1の分散ユニットへ第1のメッセージaを送信する。

ステップ1304で第1の中央ユニットが第1の分散ユニットへ第1のメッセージaを送信する方式については、ステップ902で第1の中央ユニットが第1の分散ユニットへ第1のメッセージを送信する方式を参照されたい。第1のメッセージaは、第1のメッセージと同じであってもよい。

ステップ1305：第1の分散ユニットは第2の情報に基づいて端末デバイスのリソースをスケジュールする。

ステップ1305は任意選択のステップであることに留意されたい。

ステップ1306：第3の分散ユニットおよび第1の中央ユニットは端末デバイスの初期ハンドオーバ手順を開始する。

任意選択で、端末デバイスは、第3の分散ユニットにアクセスするために、第1の分散ユニットから第3の分散ユニットへの初期ハンドオーバを開始し得る。詳細については、図9のステップ901の第1の分散ユニットへのハンドオーバの実施態様を参照されたい。

ステップ1307：第1の中央ユニットは第3の分散ユニットへ第1のメッセージbを送信する。

ステップ1304で第1の中央ユニットが第3の分散ユニットへ第1のメッセージbを送信する方式については、ステップ902で第1の中央ユニットが第1の分散ユニットへ第1のメッセージを送信する方式を参照されたい。第1のメッセージbは、第1のメッセージと同じであってもよい。

ステップ1308：第3の分散ユニットは第2の情報に基づいて端末デバイスのリソースをスケジュールする。

ステップ1308は任意選択のステップであることに留意されたい。

上記の方式は、第1の中央ユニットが変更されない例のみを使用して説明されている。ハンドオーバが第1の中央ユニットでも行われる方式は、図13および図12の実施態様を参照して説明されることができる。例えば、端末デバイスは、第2の分散ユニットを介して第2の中央ユニットにまずアクセスし、次いで端末デバイスは第1の中央ユニットおよび第1の分散ユニットにハンドオーバされる。続いて、端末デバイスは、第1の中央ユニットから第3の中央ユニットにさらにハンドオーバされ、第1の分散ユニットから第3の分散ユニットにハンドオーバされ得る、すなわち、端末デバイスは第3のネットワークデバイス（第3の中央ユニットおよび第3の分散ユニットを含む）にアクセスする。

もちろん、別の組み合わせ方式が代わりに使用されてもよい。ハンドオーバにおいて第1の情報および第2の情報を送信する具体的な方式については、前述の実施形態を参照されたい。本明細書では詳細を繰り返さない。

前述のステップ1301aから1308のすべてが実行される必要はないことに留意されたい。これは本明細書では限定されない。なお、図9～図13は一例である。実際のプロセスでは、別のステップがあってもよく、本明細書では詳細は再び説明されない。

本明細書で説明されている実施形態は、独立した解決策であってよく、または内部ロジックに基づいて組み合わされてもよい。これらの解決策はすべて本出願の保護範囲内にある。

本出願で提供される前述の実施形態では、本出願の実施形態で提供される方法は、デバイス間の相互作用の観点から別々に説明される。本出願の実施形態で提供される方法における機能を実施するために、ネットワークデバイスのCUまたはネットワークデバイスのDUは、ハードウェア構造および／またはソフトウェアモジュールを含み、ハードウェア構造、ソフトウェアモジュール、またはハードウェア構造とソフトウェアモジュールとの組み合わせの形態で前述の機能を実施することができる。前述の機能のうちのある機能が、ハードウェア構造、ソフトウェアモジュール、またはハードウェア構造とソフトウェアモジュールとの組み合わせにより実行されるかどうかは、技術的解決策の特定のアプリケーションおよび設計制約に依存する。

本出願の実施形態では、モジュール分割は一例であり、論理的な機能分割にすぎず、実際の実施態様では別の分割方式があってもよい。加えて、本出願の実施形態における機能的モジュールは1つのプロセッサに統合されてもよく、または物理的に単独で存在してもよく、または2つ以上のモジュールは1つのモジュールに統合されてよい。統合モジュールは、ハードウェアの形態で実施されてもよいし、またはソフトウェア機能モジュールの形態で実施されてもよい。

図14に示されるように、本出願は通信装置を提供する。

いくつかの実施形態では、通信装置1400は、ネットワークデバイスの第1の中央ユニットに使用されてもよい。この場合、第1の中央ユニットは処理モジュール1410を含んでもよく、任意選択で送信モジュール1420と受信モジュール1430とをさらに含んでもよい。

処理モジュール1410は、受信モジュール1430を介して端末デバイスから第1の情報を受信するように構成されており、第1の情報は端末デバイスのタイプを示す。処理モジュール1410は、送信モジュール1420を介してネットワークデバイスの第1の分散ユニットに第2の情報を送信するように構成されており、第1の情報は端末デバイスのタイプを示す。

可能な実施態様では、処理モジュール1410は、受信モジュール1430を介して第1の分散ユニットを介して端末デバイスから第1の情報を受信するように構成されている。

可能な実施態様では、処理モジュール1410は、受信モジュール1430を介して第2の分散ユニットを介して端末デバイスから第1の情報を受信するように構成され、第2の分散ユニットは、端末デバイスが第1の分散ユニットにハンドオーバされる前に端末デバイスによりアクセスされる分散ユニットである。

可能な実施態様では、処理モジュール1410は、受信モジュール1430を介して、第2の中央ユニットにより送信された第1の情報を受信するように構成され、第2の中央ユニットは、端末デバイスが第1の中央ユニットにハンドオーバされる前に端末デバイスによりアクセスされる中央ユニットである。

可能な実施態様では、処理モジュール1410は、送信モジュール1420を介して第2の情報を第3の分散ユニットに送信するように構成され、第3の分散ユニットは、端末デバイスが第1の分散ユニットからハンドオーバされる分散ユニットである。

可能な実施態様では、処理モジュール1410は、送信モジュール1420を介して第1の情報を第3の中央ユニットに送信するように構成され、第3の中央ユニットは、端末デバイスが第1の中央ユニットからハンドオーバされる中央ユニットであり、第1の情報は、第3の中央ユニットにより第2の情報を第3の分散ユニットに送信するために使用されるべきであり、第3の分散ユニットは、端末デバイスが第1の分散ユニットからハンドオーバされる分散ユニットである。

いくつかの実施形態では、通信装置1400は、ネットワークデバイスの第1の分散ユニットに使用されてもよい。この場合、第1の分散ユニットは処理モジュール1410を含んでもよく、任意選択で送信モジュール1420と受信モジュール1430とをさらに含んでもよい。

処理モジュール1410は、受信モジュールを介して端末デバイスから第1の情報を受信するように構成されており、第1の情報は端末デバイスのタイプを示す。処理モジュール1410は、送信モジュール1420を介してネットワークデバイスの第1の中央ユニットに第2の情報を送信するように構成されており、第2の情報は端末デバイスのタイプを示す。

任意選択で、前述の通信装置1400は、記憶ユニットをさらに含んでもよい。記憶ユニットは、データまたは命令（コードもしくはプログラムとも呼ばれる場合もある）を記憶するように構成される。前述のユニットは、対応する方法または機能を実施するために、記憶ユニットと対話するか、または記憶ユニットに接続され得る。例えば、処理モジュール1410は、通信装置が前述の実施形態の方法を実施するように、記憶ユニット内のデータまたは命令を読み取ることができる。

装置内のユニットの分割は、単に論理的な機能分割にすぎないことを理解されたい。実際の実施時には、ユニットの前部または一部が1つの物理的エンティティに一体化されていてもよいし、物理的に分離されていてもよい。加えて、装置における全部のユニットが、処理素子により呼び出されるソフトウェアの形態で実施されてもよいし、またはハードウェアの形態で実施されてもよい。あるいは、いくつかのユニットは、処理素子によるソフトウェア呼び出しの形態で実装されてもよく、いくつかのユニットは、ハードウェアの形態で実装されてもよい。例えば、各ユニットは、別々に配置された処理素子であってもよいし、実装のために装置のチップに統合されてもよい。加えて、各ユニットはプログラムの形態でメモリに代替的に記憶されてもよく、ユニットの機能は装置の処理素子により呼び出され実行される。加えて、これらのユニットの全部または一部が一体化されてもよいし、独立して実施されてもよい。あるいは、本明細書に記載の処理素子は、プロセッサであってもよく、信号処理能力を有する集積回路であってもよい。実装プロセスにおいて、前述の方法または前述のユニットのステップは、処理素子内のハードウェアの集積論理回路を使用して実装されてもよく、または処理素子によりソフトウェアを呼び出すことにより実装されてもよい。

一例では、前述の装置のいずれか1つにおけるユニットは、前述の方法を実装するように構成された1つもしくは複数の集積回路、例えば1つもしくは複数の特定用途向け集積回路（application specific integrated circuit、ASIC）、1つもしくは複数のマイクロプロセッサ（digital signal processor、DSP）、1つもしくは複数のフィールド・プログラマブル・ゲート・アレイ（field programmable gate array、FPGA）、またはこれら集積回路形態のうちの少なくとも2つの組み合わせであってもよい。別の例として、装置内のユニットが処理素子によりプログラムをスケジューリングする形態で実施され得る場合、処理素子は、中央処理装置（central processing unit、CPU）などの汎用プロセッサ、またはプログラムを呼び出すことができる別のプロセッサであってもよい。別の例として、そのようなユニットは一体化され、システム・オン・チップ（system－on－a－chip、SOC）の形態で実施されてもよい。

（例えば、受信ユニット）を受信するための前述のユニットは、装置のインターフェース回路であり、別の装置から信号を受信するように構成される。例えば、装置がチップ方式で実施される場合、受信ユニットは、別のチップまたは装置から信号を受信するためにチップにより使用されるインターフェース回路である。送信のための前述のユニット（例えば、送信部）は、装置のインターフェース回路であり、別の装置に信号を送信するように構成される。例えば、装置がチップ方式で実施される場合、送信ユニットは、別のチップまたは装置に信号を送信するためにチップにより使用されるインターフェース回路である。

図15は、本出願の一実施形態による通信デバイスの構造の概略図である。通信デバイスは、前述の実施形態におけるネットワークデバイスの第1の中央ユニットまたはネットワークデバイスの第1の分散ユニットの動作を実施するように構成される。図15に示されるように、通信デバイスがネットワークデバイスの第1の中央ユニットまたは第1の分散ユニットである例が一例として使用される。通信デバイスは、アンテナ1510と、無線周波数装置1520と、信号処理部1530とを含む。アンテナ1510は、無線周波数装置1520に接続されている。ダウンリンク方向では、無線周波数装置1520は、アンテナ1510を介して、ネットワークデバイスまたは別の端末デバイスにより送信された情報を受信し、ネットワークデバイスまたは別の端末デバイスにより送信された情報を処理のために信号処理部1530に送信する。アップリンク方向では、信号処理部1530は、端末デバイスからの情報を処理し、その情報を無線周波数装置1520に送信する。無線周波数装置1520は、端末デバイスからの情報を処理し、次いで、アンテナ1510を介してネットワークデバイスまたは別の端末デバイスに情報を送信する。

通信デバイスがネットワークデバイスである例が使用され、通信デバイスは、アンテナ1510、無線周波数装置1520、および信号処理部1530を含む。アンテナ1510は、無線周波数装置1520に接続されている。アップリンク方向では、無線周波数装置1520は、アンテナ1510を介して、第1の端末または別の端末デバイスにより送信された情報を受信し、第1の端末または別の端末デバイスにより送信された情報を処理のために信号処理部1530に送信する。ダウンリンク方向では、信号処理部1530は、ネットワークデバイスからの情報を処理し、その情報を無線周波数装置1520に送信する。無線周波数装置1520は、ネットワークデバイスからの情報を処理し、次いで、アンテナ1510を介して第1の端末または別の端末デバイスに情報を送信する。

信号処理部1530は、データの各通信プロトコル層を処理するように構成される。信号処理部1530は、通信デバイスのサブシステムであってもよく、通信デバイスは、別のサブシステム、例えば、通信デバイスのオペレーティングシステムおよびアプリケーション層上で処理を実施するように構成された中央処理サブシステムをさらに含んでもよい。別の例では、周辺サブシステムは、別のデバイスへの接続を実施するように構成される。信号処理部1530は、別個に配置されたチップであってもよい。任意選択で、前述の装置は信号処理部1530に配置されてもよい。

信号処理部1530は、1つまたは複数の処理素子1531を含んでいてもよく、例えば、メイン制御用CPUやその他の集積回路を含み、インターフェース回路1533を含んでいてもよい。また、信号処理部1530は、記憶素子1532をさらに含んでいてもよい。記憶素子1532は、データおよびプログラムを記憶するように構成される。通信装置が上記の方法で実行する方法を実行するためのプログラムは、記憶素子1532に格納されていてもよいし、格納されていなくてもよく、例えば、信号処理部1530の外部のメモリに格納されていてもよい。信号処理部1530は、使用時には、プログラムをキャッシュにロードして使用する。インターフェース回路1533は、装置と通信するように構成される。前述の装置は、信号処理部1530に配置されてもよい。信号処理部1530は、チップを用いて実現されてもよい。チップは、少なくとも1つの処理素子とインターフェース回路とを含む。処理素子は、前述の通信デバイスにより実行される任意の方法のステップを実行するように構成される。インターフェース回路は、他の装置と通信するように構成される。一実施態様では、前述の方法のステップを実施するためのユニットは、処理素子によりプログラムをスケジューリングする形態で実施されてもよい。例えば、装置は処理素子および記憶素子を含み、処理素子は、前述の方法の実施形態において通信デバイスにより実行される方法を実行するために、記憶素子に格納されたプログラムを呼び出す。記憶素子は、処理素子と同じチップ上に配置された記憶素子、すなわちオンチップ記憶素子であってもよい。

別の実施態様では、前述の方法で通信デバイスにより実行される方法を実行するために使用されるプログラムは、処理素子とは異なるチップ上に配置された記憶素子、すなわちオフチップ記憶素子であってもよい。この場合、処理素子は、前述の方法の実施形態において通信デバイス（ネットワークデバイスの第1の中央ユニットまたは第1の分散ユニット）により実行される方法を呼び出して実行するために、オフチップ記憶素子からプログラムを呼び出すか、またはオンチップ記憶素子にプログラムをロードする。

さらに別の実施態様では、前述の方法の各ステップを実施するために通信デバイスにより使用されるユニットは、1つまたは複数の処理素子として構成されてもよい。これらの処理素子は、信号処理部1530に配置される。本明細書での処理素子は、集積回路、例えば、1つもしくは複数のASIC、1つもしくは複数のDSP、1つもしくは複数のFPGA、またはこれらの集積回路の組み合わせであってもよい。これらの集積回路は集積されてチップを形成してもよい。

前述の方法のステップを実施するためのユニットは、システム・オン・チップ（system－on－a－chip、SOC）の形態で統合および実施されてもよく、SOCチップは前述の方法を実施するように構成される。少なくとも1つの処理素子および記憶素子はチップに統合されてもよく、処理素子は、通信デバイスにより実行される前述の方法を実施するために、記憶素子に格納されたプログラムを呼び出す。あるいは、少なくとも1つの集積回路がチップに集積されてもよく、前述の通信デバイスにより実行される方法を実施するように構成される。あるいは、前述の実施態様を参照すると、いくつかのユニットの機能は、処理素子によりプログラムを呼び出す形態で実装されてもよく、いくつかのユニットの機能は、集積回路の形態で実装される。

前述の装置は、少なくとも1つの処理素子およびインターフェース回路を含むことができ、少なくとも1つの処理素子は、前述の方法の実施形態で提供された通信デバイスにより実行される任意の方法を実行するように構成されることが知見され得る。処理素子は、記憶素子に記憶されたプログラムを呼び出す第1の方式で、通信デバイスにより実行されるステップの一部または全部を実行することができる。あるいは、処理素子は、命令と組み合わせて処理素子内のハードウェア内の集積論理回路を使用する第2の方式で、通信デバイスにより実行されるステップの一部または全部を実行してもよい。確かに、通信デバイスにより実行されるステップの一部またはすべては、第1の方法および第2の方式を参照して、代替的に実行されてもよい。

本明細書の処理素子は、上述したものと同じであり、汎用プロセッサ、例えばCPUであってもよいし、上述の方法を実施するように構成された1つまたは複数の集積回路、例えば1つもしくは複数のASIC、1つもしくは複数のマイクロプロセッサDSP、1つもしくは複数のFPGA、またはこれらの集積回路形態のうちの少なくとも2つの組み合わせであってもよい。記憶素子は、メモリであってもよいし、複数の記憶素子の総称であってもよい。

本出願の本実施形態におけるメモリが揮発性メモリもしくは不揮発性メモリであってもよく、または揮発性メモリおよび不揮発性メモリを含んでもよいことが理解されよう。不揮発性メモリは、読み取り専用メモリ（read－only memory、ROM）、プログラマブル読み取り専用メモリ（programmable ROM、PROM）、消去可能プログラマブル読み取り専用メモリ（erasable PROM、EPROM）、電気的消去可能プログラマブル読み取り専用メモリ（electrically EPROM、EEPROM）、またはフラッシュメモリであってもよい。揮発性メモリは、ランダムアクセスメモリ（random access memory、RAM）であってもよく、外部キャッシュとして使用される。例示的であるが限定されない説明により、多くの形態のRAM、例えば、スタティックランダムアクセスメモリ（static RAM、SRAM）、ダイナミックランダムアクセスメモリ（dynamic RAM、DRAM）、シンクロナス・ダイナミック・ランダム・アクセス・メモリ（synchronous DRAM、SDRAM）、ダブル・データ・レート・シンクロナス・ダイナミック・ランダム・アクセス・メモリ（double data rate SDRAM、DDR SDRAM）、拡張シンクロナス・ダイナミック・ランダム・アクセス・メモリ（enhanced SDRAM、ESDRAM）、シンクリンク・ダイナミック・ランダム・アクセス・メモリ（synchlink DRAM、SLDRAM）、およびダイレクト・ラムバス・ランダム・アクセス・メモリ（direct rambus RAM、DR RAM）が使用されてもよい。本明細書に記載されたシステムおよび方法のメモリは、これらおよび任意の他の適切なタイプのメモリを含むことが意図されているが、これらに限定されないことに留意されたい。

本出願の一実施形態は、コンピュータプログラムを記憶するコンピュータ可読記憶媒体をさらに提供する。コンピュータプログラムがコンピュータにより実行されると、ネットワークデバイスの第1の中央ユニットまたは第1の分散ユニットに適用される前述の方法実施形態のいずれか1つに対応する方法が実施される。

本出願の一実施形態は、コンピュータプログラム製品をさらに提供する。コンピュータプログラム製品がコンピュータにより実行されると、ネットワークデバイスの第1の中央ユニットまたは第1の分散ユニットに適用される任意の方法実施形態で説明された方法が実施される。

「第1」および「第2」などの用語、例えば「第1の指示情報および第2の指示情報」は、単に説明を区別するために使用されており、相対的な重要性を示すまたは暗示することも、順序を示すまたは暗示することも意図されていないことに留意されたい。「少なくとも1つ」は1つまたは複数を意味し、「複数の」は2つ以上を意味する。「および／または」という用語は、関連付けられる対象を記述するための関連付け関係を記述し、3つの関係が存在し得ることを表す。例えば、Aおよび／またはBは、以下の3つの場合、すなわち、Aのみが存在する、AおよびBの両方が存在する、およびBのみが存在する、を表す可能性があり、AおよびBは、単数であっても複数であってもよい。文字「／」は一般に、関連付けられる対象間の「または」関係を示す。「以下の項目（個）の少なくとも1つ」または同様の表現は、単数の項目（ピース）または複数の項目（ピース）の任意の組み合わせを含む、これらの項目の任意の組み合わせを指す。例えば、a、b、またはcのうちの少なくとも1つは、a、b、c、aおよびb、aおよびc、bおよびc、またはa、b、およびcを表すことができ、ここで、a、b、およびcは、単数または複数であってもよい。

前述の実施形態の全部または一部は、ソフトウェア、ハードウェア、ファームウェア、またはこれらの任意の組み合わせにより実施されてもよい。ソフトウェアが実施形態を実施するために使用されるとき、実施形態の全部または一部は、コンピュータプログラム製品の形態で実施されてもよい。コンピュータプログラム製品は、1つまたは複数のコンピュータプログラムを含む。コンピュータプログラムがコンピュータにロードされ実行されると、本出願の実施形態による手順または機能の全部または一部が生成される。コンピュータは、汎用コンピュータ、専用コンピュータ、コンピュータネットワーク、または他のプログラマブル装置であってもよい。コンピュータプログラムは、コンピュータ可読記憶媒体に記憶されてもよく、またはコンピュータ可読記憶媒体から別のコンピュータ可読記憶媒体に送信されてもよい。例えば、コンピュータプログラムは、有線（例えば、同軸ケーブル、光ファイバ、またはデジタル加入者回線（digital subscriber line、DSL））の方式または無線（例えば、赤外線、無線、もしくはマイクロ波）の方式で、あるウェブサイト、コンピュータ、サーバ、またはデータセンタから別のウェブサイト、コンピュータ、サーバ、またはデータセンタに送信され得る。コンピュータ可読記憶媒体は、コンピュータによりアクセス可能な任意の使用可能な媒体であっても、1つまたは複数の使用可能な媒体を組み込んだ、サーバやデータセンタなどのデータ記憶装置であってもよい。使用可能な媒体は、磁気媒体（例えば、フロッピーディスク、ハードディスク、または磁気テープ）、光学媒体（例えば、高密度デジタルビデオディスク（digital video disc、DVD））、半導体媒体（例えば、ソリッドステートディスク（solid state disk、SSD））などであってもよい。

本出願の一実施形態は、プロセッサとインターフェースとを含む処理装置をさらに提供する。プロセッサは、ネットワークデバイスの第1の中央ユニットまたは第1の分散ユニットに適用される前述の方法実施形態のいずれか1つに記載された方法を実行するように構成される。

処理装置はチップであってもよく、プロセッサはハードウェアにより実装されてもよく、またはソフトウェアにより実装されてもよいことを理解されたい。ハードウェアにより実装される場合、プロセッサは、論理回路、集積回路などであってもよい。ソフトウェアにより実装される場合、プロセッサは汎用プロセッサであってもよく、メモリに記憶されたソフトウェアコードを読み取ることにより実装される。メモリは、プロセッサに統合されてもよく、またはプロセッサの外部に配置されて独立して存在してもよい。

上記の説明は本出願の特定の実施態様にすぎず、本出願の実施形態の保護範囲を限定することは意図されていない。本出願の実施形態に開示した技術的範囲内で当業者が容易に理解することができる任意の変形または置換は、本出願の実施形態の保護範囲内に含まれるものとする。したがって、本出願の実施形態の保護範囲は請求項の保護範囲に従うものである。

101 端末デバイス
102 ネットワークデバイス
1400 通信装置
1410 処理モジュール
1420 送信モジュール
1430 受信モジュール
1510 アンテナ
1520 無線周波数装置
1530 信号処理部
1531 処理素子
1532 記憶素子
1533 インターフェース回路

第1の態様によれば、本出願は通信方法を提供し、本方法は、ネットワークデバイスの第1の中央ユニットが端末デバイスから第1の情報を受信し、第1の情報が端末デバイスのタイプを示すことを含む。第1の中央ユニットは、ネットワークデバイスの第1の分散ユニットに第2の情報を送信し、第2の情報は端末デバイスのタイプを示す。

例えば、ネットワークデバイスの中央ユニットはCUであってもよく、ネットワークデバイスの分散ユニットはDUであってもよい。前述の方法によれば、端末デバイスがネットワークデバイスにアクセスした後に、ネットワークデバイスの第1の中央ユニットは、端末デバイスから受信した第1の情報に基づいてネットワークデバイスの第1の分散ユニットに第2の情報を送信することができ、その結果、ネットワークデバイスの第1の分散ユニットは、時間内に端末デバイスのタイプを取得することができる。例えば、端末デバイスのタイプは、低減された能力の端末デバイス（例えば、REDCAP端末デバイス、またはNB－IoT端末デバイス）であってもよい。あるいは、端末デバイスのタイプは、低減された能力の端末デバイスのタイプであってもよい。例えば、低減された能力の端末デバイスがREDCAP端末デバイスである場合、低減された能力の端末デバイスのタイプは、別の例として、REDCAP端末デバイス内の異なる能力を有する、さらなる細分化端末デバイスであってもよいし、REDCAP端末デバイス内の異なるアンテナのさらなる細分化端末デバイスであってもよい。

処理モジュールは、受信モジュールを介して端末デバイスから第1の情報を受信するように構成され、第1の情報は端末デバイスのタイプを示す。処理モジュールは、送信モジュールを介してネットワークデバイスの第1の分散ユニットに第2の情報を送信するように構成され、第2の情報は端末デバイスのタイプを示す。

端末デバイスは、端末、ユーザ機器（user equipment、UE）、移動局（mobile station、MS）、モバイル端末デバイス（mobile terminal、MT）などとも呼ばれ、ユーザに音声またはデータ接続性を提供するデバイスであり、モノのインターネットデバイスであってもよい。例えば、端末デバイスは、無線接続機能を有するハンドヘルドデバイスまたは車載デバイスを含んでもよい。現在、端末デバイスは、携帯電話（mobile phone）、タブレットコンピュータ、ノートブックコンピュータ、パームトップコンピュータ、モバイル・インターネット・デバイス（mobile internet device、MID）、ウェアラブルデバイス（スマートウオッチ、スマートバンド、歩数計など）、車載デバイス（自動車、自転車、電気自動車、飛行機、船舶、電車、高速鉄道など）、仮想現実（virtual reality、VR）デバイス、拡張現実（augmented reality、AR）デバイス、産業制御（industrial control）における無線端末デバイス、スマートホームデバイス（冷蔵庫、TV、エアーコンディショナ、メータなど）、インテリジェントロボット、ワークショップデバイス、自動運転（self driving）における無線端末デバイス、遠隔医療手術（remote medical surgery）における無線端末デバイス、スマートグリッド（smart grid）における無線端末デバイス、交通安全（transportation safety）における無線端末デバイス、スマートシティ（smart city）における無線端末デバイス、スマートホーム（smart home）における無線端末デバイス、飛行デバイス（例えば、インテリジェントロボット、熱気球、ドローン、飛行機）などであってもよい。本出願のこの実施形態では、解決策を説明するためにUEまたは端末デバイスが使用される。

（1）上記「PRACHリソースセット、preambleセット、ランダム・アクセス・プリアンブルの最大送信回数、ランダム・アクセス・プリアンブルの初期送信電力、ランダムアクセス応答ウィンドウのサイズ、第3のメッセージのHARQ繰り返し回数の最大回数、および競合解決タイマの持続時間」毎に、対応するデフォルト値が設定されてもよいことに留意されたい。例えば、ネットワークデバイスにより送信されるランダムアクセス構成情報がPRACHリソースセットで構成されるが、ランダム・アクセス・プリアンブルの最大送信回数（例えば、ランダムアクセス構成情報は、フィールドrach－ConfigGenericを含むが、フィールドtotalNumberOfRA－Preamblesを含まない）で構成されないとき、ランダム・アクセス・プリアンブルの最大送信回数の値はデフォルト値であってもよい。

表1は、初期アップリンクRRCメッセージ転送メッセージに含まれ得るフィールドを示しており、これらは、例えばメッセージタイプフィールド（Message Type）、DU UE F1インターフェースアプリケーション識別子フィールド（gNB－DU UE F1AP ID）、NR構成済みグラント情報フィールド（NR（configured grant information、CGI））、ネットワークデバイスのDUを位置決めするために端末デバイスにより使用される端末デバイス識別子フィールドC－RNTI、アップリンクメッセージフィールド（UL－CCCH－Message IEまたはUL－CCCH 1－Message IE）を含むことができるRRCコンテナフィールド（RRC－Container）、DUからCU RRCコンテナフィールド（DU to CU RRC－Container）、SULアクセス指示フィールド（Access Indication）、トランザクション識別子フィールド（Transaction ID）、RAN UE識別子フィールド（RAN UE ID）、RRCセットメッセージ（RRCSetupComplete message）内のアップリンク制御情報要素（UL－DCCH－Message IE）を搬送するRRCコンテナセットフィールド（RRC－Container－RRCSetupComplete）、ならびに端末デバイスタイプフィールド（UE type）を含む。

表3は、ダウンリンクRRCメッセージ転送メッセージに含まれ得るフィールドを示しており、これらは、例えばメッセージタイプフィールド（Message Type）、CU UE F1インターフェースアプリケーション識別子フィールド（gNB－CU UE F1AP ID）、DU UE F1インターフェースアプリケーション識別子フィールド（gNB－DU UE F1AP ID）、RRC containerがRRC接続設定に関する情報を含むときに使用される旧DU UE F1インターフェースアプリケーション識別子フィールド（old gNB－DU UE F1AP ID）、新しいDU UE F1インターフェースアプリケーション識別子フィールド（new gNB－DU UE F1AP ID）、SRB識別子フィールド（SRB ID）、重複実行フィールド（Execute Duplication）、ダウンリンクメッセージフィールド（DL－DCCH－Message IE）を含み得るRRCコンテナフィールド（RRC－Container）、RAT周波数優先順位情報フィールド（RAT－Frequency Priority Information）、RRC配信ステータス要求フィールド（RRC Delivery Status Request）、端末デバイスコンテキスト検索不能フィールド（UE Context not retrievable）、リダイレクトされたRRCメッセージフィールド（redirected RRC message）、ネットワーク共有のためのPLMN支援情報（PLMN Assistance Info for Network Sharing）のフィールド、第1のフィールド、例えば、端末デバイスタイプフィールド（UE type）を含む。

例えば、ネットワークデバイスの第1のCUは、低減された能力の端末デバイスのアクセス優先順位を低い優先順位に設定し、低減されていない能力の端末デバイスのアクセス優先順位を高い優先順位に設定することができ、その結果、低減された能力の端末デバイスおよび低減されていない能力の端末デバイスが同時にネットワークにアクセスするとき、低減されていない能力の端末デバイスがネットワークにアクセスすることを優先する。

例えば、第1のCUは、低減された能力の端末デバイスのアクセス優先順位を低い優先順位に設定し、低減されていない能力の端末デバイスのアクセス優先順位を高い優先順位に設定することができ、その結果、低減された能力の端末デバイスおよび低減されていない能力の端末デバイスが同時にネットワークにアクセスするとき、低減されていない能力の端末デバイスがネットワークにアクセスすることを優先する。

任意選択で、CUは、第2の情報に基づいて、低減された能力の端末デバイスのための低減された能力の端末デバイスのアクセス優先順位を決定してもよい。例えば、CUは、低減された能力の端末デバイスのアクセス優先順位を低い優先順位に設定し、低減されていない能力の端末デバイスのアクセス優先順位を高い優先順位に設定することができ、その結果、低減された能力の端末デバイスと低減されていない能力の端末デバイスとが同時にネットワークにアクセスする場合、低減されていない能力の端末デバイスがネットワークにアクセスすることが優先される。

ステップ1302a：第2の分散ユニットが第1の中央ユニットに第2のメッセージを送信する。

第2のメッセージについては、端末デバイスが図5の第1の分散ユニットに第2のメッセージを送信する方式を参照されたい。

処理モジュール1410は、受信モジュール1430を介して端末デバイスから第1の情報を受信するように構成されており、第1の情報は端末デバイスのタイプを示す。処理モジュール1410は、送信モジュール1420を介してネットワークデバイスの第1の分散ユニットに第2の情報を送信するように構成されており、第2の情報は端末デバイスのタイプを示す。

Claims

通信方法であって、
ネットワークデバイスの第1の中央ユニットにより、端末デバイスから第1の情報を受信するステップであって、前記第1の情報が前記端末デバイスのタイプを示す、ステップと、
前記第1の中央ユニットにより、前記ネットワークデバイスの第1の分散ユニットに第2の情報を送信するステップであって、前記第1の情報が前記端末デバイスの前記タイプを示す、ステップと
を含む、通信方法。
前記端末デバイスの前記タイプが、低減された能力の端末デバイス、または低減された能力の端末デバイスのタイプのうちのいずれか1つを含む、請求項1に記載の方法。
第1の中央ユニットにより、端末デバイスから第1の情報を受信する前記ステップが、
前記第1の中央ユニットにより、前記第1の分散ユニットを介して前記端末デバイスから前記第1の情報を受信するステップ
を含む、請求項1または2に記載の方法。
第1の中央ユニットにより、端末デバイスから第1の情報を受信する前記ステップが、
前記第1の中央ユニットにより、第2の分散ユニットを介して前記端末デバイスから前記第1の情報を受信するステップであって、前記第2の分散ユニットが、前記端末デバイスが前記第1の分散ユニットにハンドオーバされる前に前記端末デバイスによりアクセスされる分散ユニットである、ステップ
を含む、請求項1または2に記載の方法。
第1の中央ユニットにより、端末デバイスから第1の情報を受信する前記ステップが、
前記第1の中央ユニットにより、第2の中央ユニットにより送信された前記第1の情報を受信するステップであって、前記第2の中央ユニットが、前記端末デバイスが前記第1の中央ユニットにハンドオーバされる前に前記端末デバイスによりアクセスされる中央ユニットである、ステップ
を含む、請求項1または2に記載の方法。
前記第1の分散ユニットが、前記第2の情報に基づいて前記端末デバイスのリソースおよび／または前記端末デバイスのアクセス優先順位をスケジュールする、請求項1から5のいずれか一項に記載の方法。
前記第1の中央ユニットにより、前記第2の情報を第3の分散ユニットに送信するステップであって、前記第3の分散ユニットが、前記端末デバイスが前記第1の分散ユニットからハンドオーバされる分散ユニットである、ステップ
をさらに含む、請求項1から6のいずれか一項に記載の方法。
前記第1の中央ユニットにより、前記第1の情報を第3の中央ユニットに送信するステップであって、前記第3の中央ユニットが、前記端末デバイスが前記第1の中央ユニットからハンドオーバされる中央ユニットであり、前記第1の情報が、前記第2の情報を第3の分散ユニットに送信するために前記第3の中央ユニットにより使用されるべきであり、前記第3の分散ユニットが、前記端末デバイスが前記第1の分散ユニットからハンドオーバされる分散ユニットである、ステップ
をさらに含む、請求項1から6のいずれか一項に記載の方法。
前記第2の情報が第1のメッセージで搬送され、前記第1のメッセージが第1のフィールドを含み、前記第1のフィールドが前記第2の情報を搬送する、請求項1から8のいずれか一項に記載の方法。
通信方法であって、
ネットワークデバイスの第1の分散ユニットにより、端末デバイスから第1の情報を受信するステップであって、前記第1の情報が前記端末デバイスのタイプを示す、ステップと、
前記第1の分散ユニットにより、前記ネットワークデバイスの第1の中央ユニットに第2の情報を送信するステップであって、前記第2の情報が前記端末デバイスの前記タイプを示す、ステップと
を含む、通信方法。
前記端末デバイスの前記タイプが、低減された能力の端末デバイス、または低減された能力の端末デバイスのタイプのうちのいずれか1つを含む、請求項10に記載の方法。
前記第1の中央ユニットが前記第2の情報に基づいて前記端末デバイスのアクセスを制御する、請求項10または11に記載の方法。
前記第1の中央ユニットにより、前記第2の情報を第3の分散ユニットに送信するステップであって、前記第3の分散ユニットが、前記端末デバイスが前記第1の分散ユニットからハンドオーバされる分散ユニットである、ステップ
をさらに含む、請求項10から12のいずれか一項に記載の方法。
前記第1の中央ユニットにより、前記第2の情報を第3の中央ユニットに送信するステップであって、前記第3の中央ユニットが、前記端末デバイスが前記第1の中央ユニットからハンドオーバされる中央ユニットである、ステップ
をさらに含む、請求項10から12のいずれか一項に記載の方法。
前記第2の情報が前記端末デバイスのアクセスを制御するために使用される、請求項13または14に記載の方法。
前記第2の情報が第2のメッセージで搬送され、前記第2のメッセージが第1のフィールドを含み、前記第1のフィールドが前記第2の情報を搬送する、請求項10から15のいずれか一項に記載の方法。
前記第1のメッセージが、ダウンリンク無線リソース制御メッセージ転送メッセージ、または端末デバイスコンテキスト要求メッセージのいずれか一方であり、
前記第2のメッセージが、初期アップリンク無線リソース制御メッセージ転送メッセージである、
請求項9または16に記載の方法。
前記第1の情報がメッセージ1またはメッセージ3により搬送される、請求項1から17のいずれか一項に記載の方法。
前記第1の分散ユニットおよび前記第1の中央ユニットが第1のネットワークデバイス内の分離されたネットワーク要素であり、前記第1のネットワークデバイスが、前記端末デバイスがネットワークにアクセスするように構成されるか、
第2の分散ユニットおよび第2の中央ユニットが、第2のネットワークデバイス内の分離されたネットワーク要素であり、前記第2のネットワークデバイスが、前記端末デバイスがネットワークにアクセスするように構成されるか、
第3の分散ユニットおよび第3の中央ユニットが、第3のネットワークデバイス内の分離されたネットワーク要素であり、前記第3のネットワークデバイスが、前記端末デバイスがネットワークにアクセスするように構成されるか、
前記第2の分散ユニットおよび前記第1の中央ユニットが、第4のネットワークデバイス内の分離されたネットワーク要素であり、前記第4のネットワークデバイスが、前記端末デバイスがネットワークにアクセスするように構成されるか、または
前記第3の分散ユニットおよび前記第1の中央ユニットが、第5のネットワークデバイス内の分離されたネットワーク要素であり、前記第5のネットワークデバイスが、前記端末デバイスがネットワークにアクセスするように構成される、
請求項1から18のいずれか一項に記載の方法。
プロセッサおよび通信インターフェースを含む通信装置であって、前記通信インターフェースが、前記装置が通信するように構成され、前記プロセッサがメモリに結合され、前記メモリがプログラムまたは命令を記憶するように構成され、前記プログラムまたは前記命令が前記プロセッサにより実行されると、前記装置が請求項1から9のいずれか一項に記載の方法を実行することを可能にされる、通信装置。
プロセッサおよび通信インターフェースを含む通信装置であって、前記通信インターフェースが、前記装置が通信するように構成され、前記プロセッサがメモリに結合され、前記メモリがプログラムまたは命令を記憶するように構成され、前記プログラムまたは前記命令が前記プロセッサにより実行されると、前記装置が請求項10から19のいずれか一項に記載の方法を実行することを可能にされる、通信装置。
ネットワークデバイスであって、前記ネットワークデバイスが請求項20に記載の通信装置および請求項21に記載の通信装置を含む、ネットワークデバイス。
コンピュータ可読記憶媒体であって、前記コンピュータ可読記憶媒体が命令を格納し、前記命令がコンピュータ上で実行されると、前記コンピュータが、請求項1から9のいずれか一項または請求項10から19のいずれか一項に記載の方法を実行することを可能にされる、コンピュータ可読記憶媒体。