IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ ノキア テクノロジーズ オサケユイチアの特許一覧

特許7538889無線ネットワークのマルチイベント条件付きハンドオーバ実行に関するログ情報
<>
  • 特許-無線ネットワークのマルチイベント条件付きハンドオーバ実行に関するログ情報 図1
  • 特許-無線ネットワークのマルチイベント条件付きハンドオーバ実行に関するログ情報 図2
  • 特許-無線ネットワークのマルチイベント条件付きハンドオーバ実行に関するログ情報 図3
  • 特許-無線ネットワークのマルチイベント条件付きハンドオーバ実行に関するログ情報 図4
  • 特許-無線ネットワークのマルチイベント条件付きハンドオーバ実行に関するログ情報 図5
  • 特許-無線ネットワークのマルチイベント条件付きハンドオーバ実行に関するログ情報 図6
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-08-14
(45)【発行日】2024-08-22
(54)【発明の名称】無線ネットワークのマルチイベント条件付きハンドオーバ実行に関するログ情報
(51)【国際特許分類】
   H04W 36/24 20090101AFI20240815BHJP
   H04W 24/02 20090101ALI20240815BHJP
   H04W 24/08 20090101ALI20240815BHJP
   H04W 36/08 20090101ALI20240815BHJP
   H04W 88/02 20090101ALI20240815BHJP
   H04B 17/24 20150101ALI20240815BHJP
   H04B 17/309 20150101ALI20240815BHJP
【FI】
H04W36/24
H04W24/02
H04W24/08
H04W36/08
H04W88/02 150
H04B17/24
H04B17/309
【請求項の数】 37
(21)【出願番号】P 2022571124
(86)(22)【出願日】2021-05-21
(65)【公表番号】
(43)【公表日】2023-07-04
(86)【国際出願番号】 US2021033596
(87)【国際公開番号】W WO2021237053
(87)【国際公開日】2021-11-25
【審査請求日】2023-01-20
(31)【優先権主張番号】63/028,483
(32)【優先日】2020-05-21
(33)【優先権主張国・地域又は機関】US
(73)【特許権者】
【識別番号】515076873
【氏名又は名称】ノキア テクノロジーズ オサケユイチア
(74)【代理人】
【識別番号】100094112
【弁理士】
【氏名又は名称】岡部 讓
(74)【代理人】
【識別番号】100106183
【弁理士】
【氏名又は名称】吉澤 弘司
(74)【代理人】
【識別番号】100114915
【弁理士】
【氏名又は名称】三村 治彦
(74)【代理人】
【識別番号】100125139
【弁理士】
【氏名又は名称】岡部 洋
(74)【代理人】
【識別番号】100209808
【弁理士】
【氏名又は名称】三宅 高志
(72)【発明者】
【氏名】バラン,イリナ
(72)【発明者】
【氏名】アワダ,アーマド
(72)【発明者】
【氏名】ヴァルトハウザー,リヒャルト
(72)【発明者】
【氏名】デカロー,ギヨーム
(72)【発明者】
【氏名】ヴィーリング,インゴ
【審査官】本橋 史帆
(56)【参考文献】
【文献】米国特許出願公開第2020/0045602(US,A1)
【文献】特表2017-513255(JP,A)
【文献】Futurewei,On CHO execution triggering with two joint events[online],3GPP TSG RAN WG2 #109_e R2-2000444,Internet<URL:https://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_109_e/Docs/R2-2000444.zip>,2020年02月14日
【文献】Intel Corporation,(TP for NR_Mob_enh-Core BL CR for TS 38.300): Clean-up for Stage-2 CHO[online],3GPP TSG RAN WG3 #107_e R3-201111,Internet<URL:https://www.3gpp.org/ftp/tsg_ran/WG3_Iu/TSGR3_107_e/Docs/R3-201111.zip>,2020年02月15日
(58)【調査した分野】(Int.Cl.,DB名)
H04B 7/24- 7/26
H04W 4/00-99/00
H04B 17/24
H04B 17/309
3GPP TSG RAN WG1-4
SA WG1-4
CT WG1、4
(57)【特許請求の範囲】
【請求項1】
無線ネットワーク内のユーザデバイスによって、マルチイベント条件付きハンドオーバ実行に関連する情報をログ記録するステップであって、前記マルチイベント条件付きハンドオーバ実行は、前記ユーザデバイスによるマルチイベントの共同評価に基づいているステップと、
前記ユーザデバイスによって、前記情報の少なくとも一部を含むレポートを送信するステップと、
を含み、
前記マルチイベント条件付きハンドオーバ実行は複数のイベントに基づいており、
前記ログ記録するステップは、前記複数のイベントのうちの1つ以上のイベントについて、イベント関連条件の発生、イベント関連条件の発生回数、またはイベント関連条件の発生の時間またはタイミングを少なくともログ記録するステップを含む方法。
【請求項2】
前記マルチイベント条件付きハンドオーバ実行が、2つのイベントの共同評価に基づいているデュアルイベント条件付きハンドオーバ実行を含む、請求項1に記載の方法。
【請求項3】
前記送信するステップは、前記ユーザデバイスでハンドオーバ障害または無線リンク障害が発生した後、前記ユーザデバイスはセルへの接続を再確立した後に、前記ユーザデバイスによって、前記情報の少なくとも一部を含むレポートを送信するステップを含む、請求項1または2に記載の方法。
【請求項4】
前記送信するステップは、無線リンク障害またはハンドオーバ障害に応答する前記ユーザデバイスによって、前記情報の少なくとも一部を含むレポートを送信するステップ、または、
ネットワークノードからの要求に応答する前記ユーザデバイスによって、前記情報の少なくとも一部を含むレポートを送信するステップ、
を含む、請求項3に記載の方法。
【請求項5】
イベント関連条件が
開始されていない、開始された、開始後に停止された、または、満了したの内のいずれかのステータスを含む、イベントの時間トリガ(Time-To-Trigger)タイマのステータス、
前記イベントの開始条件を実現するイベント、
前記イベントの終了条件を実現するイベント、
前記ユーザデバイスのハンドオーバ障害の発生、または
前記マルチイベント条件付きハンドオーバ実行についての実行条件を実現したか否か、
のうちの少なくとも1つを含む、請求項に記載の方法。
【請求項6】
前記マルチイベント条件付きハンドオーバ実行は複数のイベントに基づいており、
前記ログ記録するステップが、
前記複数のイベントのうちの1つ以上についてイベント関連条件が発生したかどうかを示す情報をログ記録するステップ、
複数のイベントのうちの1つ以上についてイベント関連条件が発生した回数を示す情報をログ記録するステップ、
複数のイベントのうちの少なくとも2つのイベントのイベント関連条件の時間関係またはそれらの間の時間差をログ記録するステップ、
複数のイベントのうちの1つ以上についてイベント関連条件が発生した時間を示す情報をログ記録するステップ、
どのイベントについてイベント関連条件が最初に発生したかを示す情報をログ記録するステップ、または、
複数のイベントが前記マルチイベント条件付きハンドオーバ実行の実行条件を実現しないことにより、前記ユーザデバイスに対するハンドオーバの障害の回数をログ記録するステップ、
のうちの少なくとも1つを含む、請求項1~のいずれか1項に記載の方法。
【請求項7】
前記マルチイベント条件付きハンドオーバ実行は複数のイベントに基づいており、
前記ログ記録するステップが、
前記複数のイベントのうちの1つ以上についてイベント関連条件が発生したかどうかを示す情報をログ記録するステップを含む、請求項1~のいずれか1項に記載の方法。
【請求項8】
前記複数のイベントのうちの1つ以上についてイベント関連条件が発生したかどうかを示す情報をログ記録するステップが、
もしあれば、いずれのイベントが前記イベントの開始条件を満たし、時間トリガタイマを開始したかを示す情報をログ記録するステップ、
もしあれば、いずれのイベントが前記イベントの開始条件を満たし、時間トリガタイマを開始し、前記イベントについての時間トリガタイマが満了したかを示す情報をログ記録するステップ、
前記ユーザデバイスによるマルチイベントの共同評価に基づく前記マルチイベント条件付きハンドオーバ実行の実行条件が実現しているか否かを示す情報をログ記録するステップ、
既に満了した時間トリガタイマを有する第1イベントが、第2イベントの時間トリガタイマが満了したときに前記第1イベントの終了条件を満たすか否かを示す情報をログ記録するステップ、または、
もしあれば、いずれのイベントが前記イベントに対する開始条件を実現し、時間トリガタイマを開始し、前記イベントに対する時間トリガタイマは、満了する前に停止されたかを示す情報をログ記録するステップ、
のうちの少なくとも1つを含む、請求項に記載の方法。
【請求項9】
前記マルチイベント条件付きハンドオーバ実行は複数のイベントに基づいており、
前記ログ記録するステップは、前記複数のイベントのうちの1つ以上についてイベント関連条件が発生した回数を示すログ情報をログ記録するステップを含む、請求項1~のいずれか1項に記載の方法。
【請求項10】
前記ログ記録するステップは、
各イベントが、もしあれば、そのイベントの時間トリガタイマが何回開始したか、および、前記イベントの前記時間トリガタイマが満了する前に停止したことを示す情報をログ記録するステップを少なくとも含む前記複数のイベントのうちの1つ以上について、イベント関連条件が発生した回数を示す情報をログ記録するステップを含む、請求項に記載の方法。
【請求項11】
前記マルチイベント条件付きハンドオーバ実行は少なくとも第1イベントおよび第2イベントを含む複数のイベントに基づいており、
前記ログ記録するステップは、前記第2イベントに対する第2イベント関連条件に関する前記第1イベントに対する第1イベント関連条件の関係を示す情報をログ記録するステップを含む、請求項1~のいずれか1項に記載の方法。
【請求項12】
関係を示す前記情報は、
前記第1イベントの第1イベント関連条件と前記第2イベントの第2イベント関連条件との順序、
前記第1イベントに対する第1イベント関連条件の発生と前記第2イベントの第2イベント関連条件の発生との間の時間、または、
前記第1イベントについての第1イベント関連条件の発生の時間および前記第2イベントについての第2イベント関連条件の発生の時間、
のうちの少なくとも1つを含む、請求項11に記載の方法。
【請求項13】
前記関係を示す情報をログ記録するステップは、
第1イベントまたは第2イベントが最初に開始条件を実現したかどうかをログ記録するステップ、
時間トリガタイマのうちの1つが停止または満了したときの前記第1イベントおよび前記第2イベントの時間トリガタイマの値をログ記録するステップ、または、
前記第1イベントおよび前記第2イベントの時間トリガタイマが並行して動作していた時間または期間をログ記録するステップ、
のうちの少なくとも1つを含む、請求項11または12に記載の方法。
【請求項14】
前記マルチイベント条件付きハンドオーバ実行は複数のイベントに基づいており、
前記ログ記録するステップは、前記複数のイベントのうちの1つまたは複数についてイベント関連条件が発生した時間を示す情報をログ記録するステップを含む、請求項1~のいずれか1項に記載の方法。
【請求項15】
前記ログ記録するステップは、
イベントの時間トリガタイマが開始した時刻を示す情報をログ記録するステップ、
イベントの時間トリガタイマが満了した時刻を示す情報をログ記録するステップ、
イベントの時間トリガタイマが停止した時刻を示す情報をログ記録するステップ、または、
第1イベントの時間トリガタイマと第2イベントの時間トリガタイマが並行して動作していた時刻を示す情報をログ記録するステップ、
のうちの少なくとも1つを含む前記複数のイベントのうちの1つまたは複数についてイベント関連条件が発生した時間を示す情報をログ記録するステップを含む、請求項14に記載の方法。
【請求項16】
前記マルチイベント条件付きハンドオーバ実行は複数のイベントに基づいており、
前記ログ記録するステップは、いずれのイベントに関連する条件が最初に発生したかを示す情報をログ記録するステップを含む、請求項1~のいずれか1項に記載の方法。
【請求項17】
いずれのイベントに関連する条件が最初に発生したかを示す情報を前記ログ記録するステップは、
もしあれば、いずれのイベントが前記イベントの開始条件を実現し、最初に時間トリガタイマを開始したかを示す情報をログ記録するステップ、
もしあれば、いずれのイベントが最初に時間トリガタイマを満了したかを示す情報をログ記録するステップ、または、
いずれのイベントがイベントの開始条件を満たし、時間トリガタイマを開始し、次いで時間トリガタイマを最初に停止したかを示す情報をログ記録するステップ、
のうちの少なくとも1つを含む、請求項16に記載の方法。
【請求項18】
前記マルチイベント条件付きハンドオーバ実行は少なくとも第1イベントおよび第2イベントを含む複数のイベントに基づいており、
前記ログ記録するステップは、前記マルチイベント条件付きハンドオーバ実行の実行条件を実現していない前記複数のイベントによる前記ユーザデバイスの条件付きハンドオーバの障害数をカウントする障害カウンタをログ記録するステップを含む、請求項1~17のいずれか1項に記載の方法。
【請求項19】
前記第1イベントおよび前記第2イベントの両方が非デュアル閾値測定イベントである場合に、前記障害カウンタをログ記録するステップが、
前記第1イベントに対する時間トリガタイマが満了しなかった場合の条件付きハンドオーバ障害の数、または、
前記第2イベントに対する時間トリガタイマが満了しなかった場合の条件付きハンドオーバ障害の数、
の情報のうちの1つ以上をログ記録するステップを含む、請求項18に記載の方法。
【請求項20】
前記第1イベントおよび前記第2イベントの両方がデュアル閾値測定イベントである場合に、障害カウンタを前記ログ記録するステップが、
ソースセル測定値が第1の閾値以下ではないため、前記第1イベントに対する時間トリガタイマが満了しないときの条件付きハンドオーバ障害の数、
ターゲットセル測定値が第2の閾値よりも大きくないため、前記第2イベントに対する時間トリガタイマが満了しないときの条件付きハンドオーバ障害の数、
ソースセル測定値が第1の閾値以下ではないため、前記第2イベントに対する時間トリガタイマが満了しないときの条件付きハンドオーバ障害の数、または、
ターゲットセル測定値が第2の閾値よりも大きくないため、前記第1イベントに対する時間トリガタイマが満了しないときの条件付きハンドオーバ障害の数、
の情報のうちの1つ以上をログ記録するステップを含む、請求項18に記載の方法。
【請求項21】
前記障害カウンタをログ記録するステップは、
前記第1イベントの時間トリガタイマが満了し前記第2イベントの時間トリガタイマが満了したが、第2イベントの時間トリガタイマが満了したときに第1イベントの終了条件が実現されたことに基づく条件付きハンドオーバの障害の数をログ記録するステップを含む、請求項18に記載の方法。
【請求項22】
前記マルチイベント条件付きハンドオーバ実行は少なくとも第1イベントおよび第2イベントを含む複数のイベントに基づいており、
前記ログ記録するステップは、
第1イベントの構成および/または第2イベントの構成をログ記録するステップ、
もしあれば、いずれのイベントがイベントの開始条件を実現し、時間トリガタイマを開始したかを示す情報をログ記録するステップ、
もしあれば、いずれのイベントがイベントの開始条件を実現し、時間トリガタイマを開始し、イベントの時間トリガタイマが満了したかを示す情報をログ記録するステップ、
前記マルチイベント条件付きハンドオーバ実行の実行条件が実現したか否かを示す情報をログ記録するステップ、
既に満了した時間トリガタイマを有する第1のイベントが、前記第2イベントの時間トリガタイマが満了したときに前記第1のイベントの終了条件を実現するか否かを示す情報をログ記録するステップ、
もしあれば、いずれのイベントが自身の時間トリガタイマを開始し、前記イベントについての前記時間トリガタイマが満了する前に停止されたかを示す情報をログ記録するステップ、
もしあれば、各イベントが自身の時間トリガタイマを開始し、前記イベントについての時間トリガタイマが満了する前に停止された回数を示す情報をログ記録するステップ、
第1イベントまたは第2イベントが最初に開始条件を実現するかどうかの情報をログ記録するステップ、
時間トリガタイマのうちの1つが停止または満了したときに、前記第1イベントおよび前記第2イベントの時間トリガタイマの値をログ記録するステップ、
前記第1イベントおよび前記第2イベントの時間トリガタイマが並行して動作していた時間または期間をログ記録するステップ、
イベントの時間トリガタイマが開始された時刻を示す情報をログ記録するステップ、
イベントに対する時間トリガタイマが満了した時間を示す情報をログ記録するステップ、
イベントの時間トリガタイマが停止した時刻を示す情報をログ記録するステップ、
第1イベントに対する時間トリガタイマが、第2イベントに対する時間トリガタイマと並行して動作していた時間を示す情報をログ記録するステップ、
もしあれば、いずれのイベントがイベントの開始条件を実現し、最初に時間トリガタイマを開始したかを示す情報をログ記録するステップ、
もしあれば、いずれのイベントが時間トリガタイマを最初に満了したかを示す情報をログ記録するステップ、
もしあれば、どのイベントが前記イベントの開始条件を実現し、時間トリガタイマを開始し、次いで時間トリガタイマを最初に停止したかを示す情報をログ記録するステップ、または、
複数イベントが前記マルチイベント条件付きハンドオーバ実行の実行条件を実現しないことによる前記ユーザデバイスの条件付きハンドオーバの障害の回数をカウントする障害カウンタをログ記録するステップ、
のうちの少なくとも1つを含む、請求項1~21のいずれか1項に記載の方法。
【請求項23】
少なくとも第1のイベントの構成および第2イベントの構成を含むマルチイベントのそれぞれの構成と、条件付きハンドオーバ実行を行うかどうかを判定するために前記ユーザデバイスによるマルチイベントの共同評価を構成する共同評価構成を含む、条件付きハンドオーバの一部として、前記ユーザデバイスによって、ネットワークノードから、ハンドオーバコマンドを受信することをさらに含む、請求項1~22のいずれか1項に記載の方法。
【請求項24】
ソースネットワークノードからターゲットネットワークノードへの前記ユーザデバイスの条件付きハンドオーバ実行を行うかどうかを判定するために、ユーザデバイスによって複数のイベントを共同で評価するステップをさらに含む、請求項1~23のいずれか1項に記載の方法。
【請求項25】
請求項1~24のいずれか1項に記載の方法を実行する手段を含む装置。
【請求項26】
少なくとも1つのプロセッサによって実行されたときに、コンピューティングシステムに請求項1~24のいずれか1項に記載の方法を実行させるように構成された命令が格納された非一時的なコンピュータ可読記憶媒体。
【請求項27】
少なくとも1つのプロセッサと、
コンピュータプログラムコードを含む少なくとも1つのメモリとを含む装置であって、
前記少なくとも1つのメモリおよび前記コンピュータプログラムコードは、前記少なくとも1つのプロセッサとともに、前記装置に、請求項1~24のいずれか1項に記載の方法を少なくとも行わせるように構成された装置。
【請求項28】
少なくとも1つのプロセッサと、
コンピュータプログラムコードを含む少なくとも1つのメモリとを含む装置であって、
前記少なくとも1つのメモリおよび前記コンピュータプログラムコードは、前記少なくとも1つのプロセッサとともに、
無線ネットワーク内のユーザデバイスが、マルチイベント条件付きハンドオーバ実行に関連する情報をログ記録するステップあって、前記マルチイベント条件付きハンドオーバ実行は、前記ユーザデバイスによるマルチイベントの共同評価に基づいているログ記録するステップと、
前記ユーザデバイスが、前記情報の少なくとも一部を含むレポートを送信するステップと、
を前記装置に実行させ
前記マルチイベント条件付きハンドオーバ実行は複数のイベントに基づいており、
前記ログ記録するステップは、前記複数のイベントのうちの1つ以上のイベントについて、イベント関連条件の発生、イベント関連条件の発生回数、またはイベント関連条件の発生の時間またはタイミングを少なくともログ記録するステップを含む、装置。
【請求項29】
ユーザデバイスによる条件付きハンドオーバ実行のために共同で評価されるマルチイベントの構成を含む共同イベント構成情報を持つハンドオーバコマンドを、ネットワークノードによって前記ユーザデバイスに送信するステップと、
前記ユーザデバイスによるマルチイベント条件付きハンドオーバ実行の障害に関する前記ユーザデバイスによって記録された情報を含むレポートを前記ネットワークノードによって受信するステップであって、前記マルチイベント条件付きハンドオーバ実行が複数のイベントに基づいているステップと、
前記レポートに基づいて前記ネットワークノードによって、マルチイベント条件付きハンドオーバ実行のための一つ以上のイベントの構成に関連付けられた一つ以上のパラメータを変更するステップとを含み、
前記マルチイベント条件付きハンドオーバ実行は複数のイベントに基づいており、
前記ユーザデバイスによってログ記録される情報には、前記複数のイベントのうち1つ以上のイベント関連条件の発生、イベント関連条件の発生回数、イベント関連条件の発生時刻や発生タイミングの内の少なくとも1つを含む、方法。
【請求項30】
前記共同イベント構成情報は、条件付きハンドオーバ実行を行うかどうかを判定するために、前記ユーザデバイスによるマルチイベントの共同評価を構成する共同評価構成を含む、請求項29に記載の方法。
【請求項31】
前記マルチイベント条件付きハンドオーバ実行が、2つのイベントに基づくデュアルイベント条件付きハンドオーバ実行を含む、請求項29または30に記載の方法。
【請求項32】
イベント関連条件は、
開始されていない、開始された、開始後に停止された、または、満了したのいずれかのステータスを含むイベントの時間トリガタイマのステータス、
前記イベントの開始条件を実現するイベント、
前記イベントの終了条件を実現するイベント、
前記ユーザデバイスのハンドオーバ障害の発生、または
前記マルチイベント条件付きハンドオーバ実行の実行条件が実現されているか否か、
のうちの少なくとも1つを含む、請求項29に記載の方法。
【請求項33】
前記マルチイベント条件付きハンドオーバ実行は複数のイベントに基づいており、
前記ユーザデバイスによってログ記録される前記情報は、
前記複数のイベントのうちの1つ以上についてイベント関連条件が発生したかどうかを示す情報、
複数のイベントのうちの1つ以上についてイベント関連条件が発生した回数を示す情報、
複数のイベントのうちの少なくとも2つのイベントのイベント関連条件の時間関係またはそれらの間の時間差、
複数のイベントのうちの1つ以上についてイベント関連条件が発生した時間を示す情報、
どのイベントについてイベント関連条件が最初に発生したかを示す情報、または、
前記複数のイベントが前記マルチイベント条件付きハンドオーバ実行の実行条件を実現しないことにより、前記ユーザデバイスに対するハンドオーバの障害の回数、
のうちの少なくとも1つを含む、請求項2932のいずれか1項に記載の方法。
【請求項34】
前記マルチイベント条件付きハンドオーバ実行は少なくとも第1イベントおよび第2イベントを含む複数のイベントに基づいており、
前記ユーザデバイスによってログ記録される前記情報は、
第1イベントの構成および/または第2イベントの構成、
もしあれば、いずれのイベントがイベントの開始条件を実現し、時間トリガタイマを開始したかを示す情報、
もしあれば、いずれのイベントがイベントの開始条件を実現し、時間トリガタイマを開始し、イベントの時間トリガタイマが満了したかを示す情報、
前記マルチイベント条件付きハンドオーバ実行の実行条件が実現したか否かを示す情報、
既に満了した時間トリガタイマを有する第1のイベントが、前記第2のイベントの時間トリガタイマが満了したときに前記第1のイベントの終了条件を実現するか否かを示す情報、
もしあれば、いずれのイベントが自身の時間トリガタイマを開始し、前記イベントについての前記時間トリガタイマが満了する前に停止されたかを示す情報、
もしあれば、各イベントが自身の時間トリガタイマを開始し、前記イベントについての時間トリガタイマが満了する前に停止された回数を示す情報、
第1イベントまたは第2イベントが最初に開始条件を実現するかどうかの情報、
時間トリガタイマのうちの1つが停止または満了したときの、前記第1イベントおよび前記第2イベントの時間トリガタイマの値、
前記第1イベントおよび前記第2イベントの時間トリガタイマが並行して動作していた時間または期間、
イベントの時間トリガタイマが開始された時刻を示す情報、
イベントに対する時間トリガタイマが満了した時間を示す情報、
イベントの時間トリガタイマが停止した時刻を示す情報、
第1イベントに対する時間トリガタイマが、第2イベントに対する時間トリガタイマと並行して動作していた時間を示す情報、
もしあれば、いずれのイベントがイベントの開始条件を実現し、最初に時間トリガタイマを開始したかを示す情報、
もしあれば、いずれのイベントが時間トリガタイマを最初に満了したかを示す情報、
もしあれば、いずれのイベントが前記イベントの開始条件を実現し、時間トリガタイマを開始し、次いで時間トリガタイマを最初に停止したかを示す情報、または、
複数イベントが前記マルチイベント条件付きハンドオーバ実行の実行条件を実現しないことによる前記ユーザデバイスの条件付きハンドオーバの障害の回数をカウントする障害カウンタ、
のうちの少なくとも1つを含む、請求項2933のいずれか1項に記載の方法。
【請求項35】
請求項2934のいずれか1項に記載の方法を実行する手段を含む装置。
【請求項36】
少なくとも1つのプロセッサによって実行されたときに、コンピューティングシステムに請求項2934のいずれか1項に記載の方法を実行させるように構成された命令が格納された非一時的なコンピュータ可読記憶媒体。
【請求項37】
少なくとも1つのプロセッサと、
コンピュータプログラムコードを含む少なくとも1つのメモリとを含む装置であって、
前記少なくとも1つのメモリおよび前記コンピュータプログラムコードは、前記少なくとも1つのプロセッサとともに、前記装置に、請求項2934のいずれか1項に記載の方法を少なくとも実行させるように構成された装置。
【発明の詳細な説明】
【技術分野】
【0001】
本明細書は無線通信に関する。
【背景技術】
【0002】
通信システムは、固定通信機器や移動通信機器など、2つ以上のノードや機器間の通信を可能にする設備である場合がある。
信号は有線または無線のキャリアで伝送できる。
【0003】
セルラー通信システムの例として、3rd Generation Partnership Project(3GPP)によって標準化されているアーキテクチャがある。
この分野の最近の開発は、ユニバーサルモバイルテレコミュニケーションズシステム(UMTS)無線アクセス技術のロングタームエボリューション(LTE)と呼ばれることが多い。E-UTRA(進化型UMTS地上無線アクセス)は、モバイルネットワークのための3GPPのロングタームエボリューション(LTE)アップグレード経路のエアインターフェースである。LTEでは、拡張型ノードAP(eNB)と呼ばれる基地局またはアクセスポイント(AP)は、カバレッジエリアまたはセル内の無線アクセスを提供する。LTEでは、モバイル機器、すなわち移動局をユーザ機器(UE)と呼ぶ。LTEには多くの改良や開発が含まれている。LTEの態様も改善され続けている。
【発明の概要】
【発明が解決しようとする課題】
【0004】
5G New Radio(NR)の開発は、3Gおよび4G無線ネットワークの以前の進化と同様に、5Gの要件を満たすための継続的なモバイルブロードバンド進化プロセスの一部である。5Gは、モバイルブロードバンドに加えて、新たに出現したユースケースも対象としている。5Gの目標は、新しいレベルのデータレート、遅延、信頼性、およびセキュリティを含む、ワイヤレスパフォーマンスの大幅な改善を提供することである。5G NRは、大規模なモノのインターネット(IoT)を効率的に接続するために拡張される可能性もあり、新しいタイプのミッションクリティカルなサービスを提供する可能性もある。たとえば、超信頼性と低遅延の通信(URLLC)デバイスは、高い信頼性と非常に低い遅延を必要とする場合がある。
【課題を解決するための手段】
【0005】
一例の実施形態によれば、方法は、無線ネットワーク内のユーザデバイスによって、マルチイベント条件付きハンドオーバ実行に関連する情報をログ記録するステップであって、前記マルチイベント条件付きハンドオーバ実行は、前記ユーザデバイスによるマルチイベントの共同評価に基づいているステップと、前記ユーザデバイスによって、情報の少なくとも一部を含むレポートを送信するステップとを含む。
【0006】
別の実施例によれば、方法は、ユーザデバイスによる条件付きハンドオーバ実行のために共同で評価されるマルチのイベントの構成を含む共同イベント構成情報を持つハンドオーバコマンドを、ネットワークノードによってユーザデバイスに送信するステップと、ユーザデバイスによるマルチイベント条件付きハンドオーバ実行の障害に関するユーザデバイスによって記録された情報を含むレポートをネットワークノードによって受信するステップとを含み、マルチイベント条件付きハンドオーバ実行は複数のイベントに基づく受信するステップ、および、レポートに基づいてネットワークノードによって、マルチイベント条件付きハンドオーバ実行のための一つ以上のイベントの構成に関連付けられた一つ以上のパラメータを変更するステップとを含む。
【0007】
他の例示的な実施形態は、例示的な方法のそれぞれについて提供または説明され、例示的な方法のいずれかを実行するための手段、少なくとも1つのプロセッサによって実行されると、コンピューティングシステムに例示的な方法のいずれかを実行させるように構成された命令を記憶したコンピュータ可読記憶媒体、および、装置は、少なくとも1つのプロセッサと、コンピュータプログラムコードを含む少なくとも1つのメモリとを含み、少なくとも1つのメモリおよびコンピュータプログラムコードは、少なくとも1つのプロセッサを用いて、装置に少なくとも例示的な方法のいずれかを実行させるように構成される。
【0008】
1つ以上の実施例の詳細は、添付の図面および以下の説明に記載されている。
他の特徴は、説明および図面、および請求の範囲から明らかになるだろう。
【図面の簡単な説明】
【0009】
図1】一実施例による無線ネットワークのブロック図である。
図2】一実施例によるユーザデバイス(UE)の動作を示すフローチャートである。
図3】一実施例によるネットワークノード(例:BSやgNB)の動作を示すフローチャートである。
図4】一実施例によるマルチイベント条件付きハンドオーバ(CHO)を示す図である。
図5】一実施例によるデュアルイベント条件付きハンドオーバ(CHO)の実行を示す図である。
図6】一実施例による無線ステーションまたは無線ノード(例:AP、BS、gNB、RANノード、中継ノード、UEまたはユーザデバイス、またはその他のノード)のブロック図である。
【発明を実施するための形態】
【0010】
図1は、一実施例による無線ネットワーク130のブロック図である。図1の無線ネットワーク130では、ユーザデバイス131、132、133および135は、移動局(MS)またはユーザ機器(UE)とも呼ばれ、基地局(BS)134と接続(および通信)することができ、基地局(BS)は、アクセスポイント(AP)、拡張型ノードB(eNB)、BS、次世代ノードB(gNB)、次世代拡張型ノードB(ng-eNB)、またはネットワークノードとも呼ばれる。ユーザデバイスとユーザ機器(UE)という用語は、同じ意味で使用されることがある。BSは、RANノードを含むこともあれば、RAN(無線アクセスネットワーク)ノードと呼ばれることもあり、BSの一部またはRANノードの一部(例えば、分割BSの場合の集中型ユニット(CU)や分散型ユニット(DU)など)を含むこともある。BSの機能の少なくとも一部(例:アクセスポイント(AP)、基地局(BS)または(e)ノードB(eNB)、BS、RANノード)は、リモートラジオヘッドなどのトランシーバに動作可能に結合される任意のノード、サーバまたはホストによっても実行される場合がある。BS(またはAP)134は、セル136内で、ユーザデバイス(またはUE)131、132、133および135を含む無線カバレッジを提供する。4つのユーザデバイス(またはUE)のみがBS134に接続または接続されているように表示されるが、任意の数のユーザデバイスを提供できる。BS134は、S1インターフェイスまたはNGインターフェイス151を介してコアネットワーク150にも接続される。これは無線ネットワークの単純な一例にすぎず、他のものを使用することもできる。
【0011】
基地局(例:BS134)は、無線ネットワーク内の無線アクセスネットワーク(RAN)ノードの一例である。BS(またはRANノード)は、アクセスポイント(AP)、gNB、eNB、またはその一部(分割されたBSまたは分割されたgNBの場合の集中型ユニット(CU)および/または分散型ユニット(DU)など)、またはその他のネットワークノードである場合もあれば、これらを含む場合もある(または代わりにこれらで呼ばれる場合もある)。
【0012】
例示的な例によると、BSノード(例:BS、eNB、gNB、CU/DU、・・・)または無線アクセスネットワーク(RAN)は、移動体通信システムの一部である場合がある。RAN(無線アクセスネットワーク)は、例えば、1つ以上のUEがネットワークまたはコアネットワークにアクセスできるようにするために、無線アクセス技術を実装する1つ以上のBSまたはRANノードを含む場合がある。したがって、例えば、RAN(RANノード(BSやgNBなど))は、1つ以上のユーザデバイスまたはUEとコアネットワークの間に存在する場合がある。一例の実施形態によれば、各RANノード(例:BS、eNB、gNB、CU/DU、・・・)またはBSは、例えば、UEがRANノードを介してネットワークに無線アクセスできるようにするために、1つ以上のUEまたはユーザデバイスに対して1つ以上の無線通信サービスを提供する場合がある。各RANノードまたはBSは、例えば、UEまたはユーザデバイスがRANノードへの無線接続を確立できるようにしたり、1つ以上のUEに対してデータを送信および/または受信したりするような無線通信サービスを実行または提供する場合がある。例えば、UEへの接続を確立した後、RANノード(例:BS、eNB、gNB、CU/DU、・・・)は、ネットワークまたはコアネットワークから受信したデータをUEに転送したり、UEから受信したデータをネットワークまたはコアネットワークに転送したりする場合がある。RANノード(例:BS、eNB、gNB、CU/DU、・・・)は、制御情報(例えば、システム情報など)をUEにブロードキャストする、UEに配信するデータがある場合にUEをページングする、UEのセル間ハンドオーバを支援する、UEからのアップリンクデータ送信およびUEへのダウンリンクデータ送信のためのリソースのスケジューリング、1つ以上のUEを構成するための制御情報の送信など、その他の多種多様な無線機能またはサービスを実行する場合がある。これらは、RANノードまたはBSが実行する可能性のある1つ以上の機能のいくつかの例である。基地局は、IAB(Integrated Access and Backhaul)ノードのDU(Distributed Unit)の一部である場合もある(別名中継ノード)。DUは、IABノードのアクセスリンク接続を容易にする。
【0013】
ユーザデバイス(ユーザ端末、ユーザ機器(UE)、モバイル端末、携帯無線機器など)は、これに限定されないが、移動局(MS)、移動電話、携帯電話、スマートフォン、携帯情報端末(PDA)、ハンドセット、無線モデム(警報または測定デバイスなど)を使用するデバイス、ラップトップおよび/またはタッチスクリーンコンピュータ、タブレット、ファブレット、ゲームコンソール、ノートブック、車両、センサ、およびマルチメディアデバイス、および、例として、または任意の他の無線デバイスを含む、加入者識別モジュール(SIM)の有無にかかわらず動作する無線移動通信デバイスを含むポータブルコンピューティングデバイスを指す場合がある。ユーザデバイスは、ネットワークに画像またはビデオクリップをロードするカメラまたはビデオカメラを例とする、ほぼ排他的なアップリンク専用デバイスであり得る(または含むこともある)。ユーザデバイスは、IAB(Integrated Access and Backhaul)ノードのMT(Mobile Termination)部分である場合もある(別名中継ノード)。MTは、IABノードのバックホール接続を容易にする。
【0014】
LTEでは(例示的な例として)、コアネットワーク150は進化したパケットコア(EPC)と呼ばれることがあり、これには、BS間のユーザデバイスのモビリティ/ハンドオーバを処理または支援する可能性のあるモビリティ管理エンティティ(MME)、BSとパケットデータネットワークまたはインターネットの間でデータおよび制御信号を転送する可能性のある1つ以上のゲートウェイ、およびその他の制御機能またはブロックが含まれる場合がある。5G(NewRadio(NR)と呼ばれる場合がある)などの他の種類の無線ネットワークにも、コアネットワークが含まれる場合がある。
【0015】
さらに、説明例として、ここに記載されているさまざまな例の実施形態または技術は、さまざまな種類のユーザデバイスまたはデータサービスの種類に適用される場合もあれば、異なるデータサービスの種類である可能性のあるマルチのアプリケーションが実行されている可能性のあるユーザデバイスに適用される場合もある。New Radio(5G)の開発では、マシンタイプ通信(MTC)、拡張型マシンタイプ通信(eMTC)、モノのインターネット(IoT)、および/またはナローバンドIoTユーザデバイス、拡張型モバイルブロードバンド(eMBB)、および超信頼性と低遅延の通信(URLLC)など、多数の異なるアプリケーションまたは多数の異なるデータサービスタイプがサポートされる場合がある。これらの新しい5G(NR)関連アプリケーションの多くは、以前の無線ネットワークよりも一般的に高いパフォーマンスを必要とする場合がある。
【0016】
IoTは、インターネットまたはネットワーク接続を持つ可能性のあるオブジェクトのグループを指す場合があり、そのため、これらのオブジェクトは他のネットワークデバイスと情報を送受信できる。たとえば、多くのセンサータイプのアプリケーションやデバイスは、物理的な状態や状態を監視し、イベントが発生したときなどにサーバや他のネットワークデバイスにレポートを送信する場合がある。マシンタイプ通信(MTCまたはMachine to Machine communications)は、たとえば、人間の介入の有無にかかわらず、インテリジェントマシン間で完全に自動のデータ生成、交換、処理、および作動を特徴とする場合がある。拡張型モバイルブロードバンド(eMBB)は、現在LTEで利用可能なものよりもはるかに高いデータレートをサポートする場合がある。
【0017】
超高信頼かつ低遅延の通信(URLLC)は、新しいデータサービスの種類、または新しい使用シナリオであり、New Radio(5G)システムでサポートされる場合がある。これにより、産業オートメーション、自動運転、車両安全、e-ヘルスサービスなど、新しいアプリケーションやサービスが可能になる。3GPPは、ブロックエラー率(BLER)10-5と最大1ms U-Plane(ユーザ/データプレーン)遅延に対応する信頼性のある接続性を提供することを目的としている。したがって、たとえば、URLLCのユーザデバイス/UEは、他の種類のユーザデバイス/UEよりも大幅に低いブロックエラー率と、低い遅延(同時に高い信頼性を必要とするかどうかは問わない)を必要とする場合がある。したがって、たとえば、URLLC UE(またはUE上のURLLCアプリケーション)は、eMBB UE(またはUE上で実行されるeMBBアプリケーション)と比較して、はるかに短い遅延を必要とする場合がある。
【0018】
さまざまな例の実施形態は、LTE、LTE-A、5G(New Radio(NR))、cmWave、および/またはmmWaveバンドネットワーク、IoT、MTC、eMTC、eMBB、URLLCなど、またはその他の任意の無線ネットワークまたは無線技術など、さまざまな無線技術または無線ネットワークに適用できる。これらの例のネットワーク、技術またはデータサービスの種類は、説明例としてのみ提供される。
【0019】
ユーザ機器(UE)のハンドオーバは、接続されたコールまたはUEのデータセッションが、セッションを切断せずに1つのセル(または基地局)から別のセル(または基地局)に転送されるプロセスを指す場合がある。5G/New Radio(NR)などの一部の無線技術では、より高い周波数で動作すると、より高い周波数での回折損失が障害物によって引き起こされる急速な信号の劣化につながる可能性があるため、さらなる移動性の課題が生じる可能性がある。したがって、UEの移動性を確保するために、信頼性が高く効率的なハンドオーバを提供することが望ましい。
【0020】
例の実施形態によると、条件付きハンドオーバ(CHO)を使用して移動性の堅牢性を高めることができる。CHOの例では、CHOハンドオーバの準備とCHOハンドオーバの実行を分離することができる。例えば、CHOの手順の例では、サービングセルによって、ターゲットセルへのUEのハンドオーバが事前に準備され、その後、UEとターゲットセル間の無線リンクが十分であるとき、またはCHOの実行条件を満たしたときに、ソースセルからターゲットセルへのUEのハンドオーバが実行されることがある。したがって、CHOは、サービングBS/gNB(現在UEにサービスを提供しているソースセルに関連付けられているか、提供している)が可能なマルチのターゲットセルを準備することを可能にし、その後、UEに対してターゲットセルの1つへのハンドオーバが実行されることがある。CHOの利点は、UEと送信元セル間の無線リンクが良好な状態のまま、送信元セル(または送信元/サービングBS/ネットワークノード)から事前にハンドオーバ(HO)コマンドがUEに送信され、その後、CHO実行条件が実現された場合に、UEがCHOを実行できることである。前述のように、想定されるハンドオーバのために送信元セルによってターゲットセルが準備された後、送信元セル(サービングBS/ネットワークノード)は、ターゲットセル構成(例えば、UEのターゲットセル内のランダムアクセス/RACHリソースの表示を含む)、およびCHO実行の実行に使用されるイベント構成(イベントの1つ以上のパラメータを含む)を提供するハンドオーバ(HO)コマンドをUEに送信することができる。UEは、CHO実行条件が実現された場合にCHO実行を行うことができる。CHO実行条件は、通常、1つ以上のイベントに基づいている。たとえば、単一のイベントを使用して、イベントの開始条件が少なくとも時間トリガ(Time-To-Trigger)の時間実現された場合、UEはターゲットセルに対してCHO実行を実行(トリガー)することができる。
【0021】
UEは、ソースセルまたはソース/サービングネットワークノード(gNB/BS)から、ターゲットセルの条件付きハンドオーバ(CHO)実行条件の構成を受信することができ、これには、CHO実行条件を定義するか、またはUEがCHO実行条件を判定するために使用する可能性のある1つ以上のパラメータが含まれる場合がある。たとえば、CHO実行条件の構成には、イベントの開始条件または終了条件を定義する可能性のあるイベントの1つ以上のパラメータを含むイベント構成が含まれる場合がある。単一のイベントCHOでは、イベントの開始条件が時間トリガ(Time-to-Trigger(TTT))と呼ばれる最小時間期間に対して実現された場合に、CHO実行条件が実現されたり満たされたりすることがある)。たとえば、UEは、ソースセル、および1つ以上の隣接(または潜在的なターゲット)セルから受信した信号の信号測定を随時実行することがある。UEによる測定には、基準信号受信電力(RSRP)、基準信号受信品質(RSRQ)、またはその他の信号測定が含まれる場合がある。たとえば、A3イベントの場合、CHO実行条件は、ターゲットセルの測定値が、指定された閾値またはオフセットよりも優れている(例えば、より大きい)必要があることを示す場合がある。たとえば、CHO実行条件は、ソースBS(ソースノード)からUEに送信される可能性のある再構成メッセージ(例:Radio Resource Control(RRC)再設定メッセージ、またはhandoverコマンド)内のソースノード(ソースBS/gNB)によって構成される場合がある。
【0022】
例示的な例として、A3イベントの例は、CHO実行条件のための例示的なイベントとして構成され得る。たとえば、UEのCHO実行は、イベントA3についての((式1)で示される)開始条件が特定の時間トリガ(TTT)に対して実現された場合にトリガされる可能性がある。ここで、TTTは、イベントの開始条件が実現するか満たされてソースセルからターゲットセルへのUEのCHO実行をトリガするまたは引き起こす最小時間期間を指す場合がある。
【数1】
【0023】
ここで、Mnはハンドオーバの隣接するターゲットセルの測定値、Mpはサービングセルの測定値、Ocnはセル個別オフセット(CIO)である。パラメータOfn、Ofp、Ocp、Off、およびHysは、ネットワークによって構成される可能性のあるその他のオフセットである(また、条件付きハンドオーバ実行条件の構成で示される場合がある)。((式1)においてOcnとして示される)CIOは、そのような隣接セル測定を(たとえば、正のCIOを介する)UEハンドオーバにとってより魅力的にするために、または(たとえば、負のCIOを介する)UEハンドオーバにとってあまり魅力的ではなくするために、隣接セル測定に特に適用され得る(およびこのターゲット/隣接セルに固有であり得る)オフセットであり得る。
【0024】
A3イベントの終了条件は、以下の(式2)によって定義されてもよい。
【数2】
【0025】
A3イベントは、イベントA3の開始条件が単一の閾値を採用しているので、単一の閾値イベント、または非デュアル閾値イベントの例である。したがって、A3イベントの場合、開始条件は、ターゲット(または近隣)セルの測定値が、少なくともソースセルの測定値よりも優れた閾値になる必要がある。
【0026】
別の例のイベントであるイベントA5は、A5イベントが2つの閾値を採用して、イベントの開始条件(または終了条件)が実現されているかどうかを判定するので、デュアル閾値イベントの例である。A5イベント(式は示されていない)の場合、開始条件では、ソースセルの測定値が第1の閾値よりも悪く(例えば、低い)、ターゲットセルが第2の閾値よりも良好(例えば、より強い、またはより大きい)である必要がある。A3イベントとA5イベントはイベントの一例であり、他のイベントがCHOの実行に使用されてもよい。
【0027】
また、UE CHOの実行の信頼性やパフォーマンスを向上させるために、CHOの実行はマルチイベント(例:デュアルイベントCHO実行)に基づく場合がある。また、マルチイベントは、基準信号受信電力(RSRP)や基準信号受信品質(RSRQ)など、異なる信号パラメータの測定に基づく場合がある。したがって、複数イベント条件付きハンドオーバは、異なるイベント(例:A3イベント+A5イベント)を使用する場合もあれば、例えば、RSRPに基づくA3イベント+RSRQに基づくA3イベント、RSRPに基づくA3イベント+RSRQに基づくA5イベント、または、RSRPに基づくRSRQ+R5イベントに基づくA3イベントなど、同じイベントまたは異なるイベントに基づいて異なる信号パラメータを測定する場合もある。
【0028】
UEは、たとえば、ソースセルまたはサービングネットワークノードから、例えば、(例えば、UEのためのランダムアクセス/RACHリソースを示す)ターゲットセル構成、CHO実行条件、および(たとえば、イベントのイベント構成が、イベント(たとえば、A3またはA5イベント)、測定される信号パラメータ(たとえば、RSRPまたはRSRQ)、1つまたは複数のオフセット、イベントの入力条件に対するヒステリシス、および/またはイベントに対するTTT値のうちの1つまたは複数を含むかまたは識別することができる場合の)複数のイベントの内のイベントのためのイベント構成、のうちの1つまたは複数を含み得るハンドオーバコマンドとともに、複数イベントCHO構成を受信することができる。したがって、各イベントには、イベントの1つ以上のパラメータ、たとえば、イベントタイプの1つ以上(例:A3イベント、A5イベント)、測定される信号パラメータ(例:RSRPまたはRSRQ)、開始条件についてのオフセット、TTT値などを指定できる、独自のイベント構成を含めることができる。
【0029】
複数イベントCHO実行条件は、事前にUEが知っている場合もあれば、複数イベントCHO構成の一部としてUEにシグナリングされる場合もあり、複数イベントの各イベントのステータスや条件、または複数イベントCHO実行に対するCHO実行条件が実現される(すなわち、CHO実行をトリガする)ために発生する必要があるイベント間の関係を示す場合もある。たとえば、デュアルイベント(第1のイベントおよび第2のイベント)に基づくデュアルイベントCHO実行の場合、UEは、第1のイベントおよび第2のイベントの両方を共同で評価して(ここで、UEは、両方のイベントの態様を評価し、例えば、場合によっては、両方のイベントの態様を同時に評価する)、マルチイベントCHO実行は、第2のイベントに対する時間トリガ(TTT)タイマが満了したときに、既に満了した時間トリガ(TTT)タイマを有する第1のイベントが第1のイベントに対する終了条件を実現しない場合にUEによって実行されるという、複数イベントCHO実行条件が満たされたかどうかを判定することができる。これは複数イベントCHO実行条件の例であるが、他のものを用いてもよい。
【0030】
場合によっては、CHOが障害することがあり得、たとえば、UEの無線リンク障害(RLF)またはハンドオーバ(HO)障害をもたらし得る。HO障害は、UEがターゲットセルへのランダムアクセスの実行に失敗したときに発生し得る。無線リソース制御(RRC)接続モード(たとえば、RRC_CONNECTEDモード)では、UEは、典型的には、無線リンク監視(RLM)と呼ばれるサービングセル無線リンクを監視し得、RLM測定を実行する。RLM測定は、無線リンクを維持するのに充分な(例えば充分な)ダウンリンク(DL)無線リンク品質が良好であるかどうかを判定するために、および/または無線リンクの品質が定義された閾値(例えば、無線リンクがもはやデータ送信に充分な品質を提供できないことが予想されるとき)を下回るときを上位層に示すために、サービングセル無線リンク品質を評価することを支援する。RLMは、特定の状況下で無線リンク障害を検出または宣言するために、UEまたはユーザデバイスが、UEとサービングgNBまたはサービングセルとの間の無線リンクを監視するプロセスを含み得る。
【0031】
単一イベントCHOの場合、UEはRLFまたはHO障害の直前に情報を収集および/または格納し、ネットワークに報告する場合がある。しかしながら、この収集された情報は単一イベントCHO実行用であり、範囲は非常に限られている。例えば、RLFやHOの障害の原因となった可能性のあるイベントをUEが判定できるようにする、CHOの実行性能を向上させるためにパラメータをどのように調整できるかをUEが判定できるようにするなど、複数イベントのCHO実行に関連するより詳細な情報を提供する必要がある。
【0032】
図2は、一実施例によるユーザデバイス(UE)の動作を示すフローチャートである。動作210は、無線ネットワーク内のユーザデバイス(UE)による、複数イベント条件付きハンドオーバ実行に関する情報のログ記録を含み、複数イベント条件付きハンドオーバ実行は、ユーザデバイスによる複数イベントの共同評価に基づいている。ログ記録には、ログまたはレコードの作成または保持が含まれる場合がある。ログ記録には、たとえば、条件付きハンドオーバの実行に関して、ユーザデバイスまたはUEのイベントまたはイベント関連条件に関連する情報を記録(または保存)できるログまたはレコードの作成が含まれる場合がある。たとえば、複数イベントの条件付きハンドオーバの実行に関連するログ情報には、たとえば、さまざまなイベント関連条件のログ記録または保存が含まれる場合がある。イベント関連条件には、たとえば、イベントの時間トリガタイマのステータス(開始されていない、開始された、開始後に停止された、または、満了した)、イベントの開始条件を実現するイベント、イベントの終了条件を実現するイベント、ユーザデバイスのハンドオーバ障害の発生、またはマルチイベント条件付きハンドオーバ実行の実行条件が実現されているか否か、のいずれかのステータスを含む)が1つ以上含まれる場合がある。例えば、イベント関連条件の発生のログ記録、イベント関連条件の発生時刻、イベント関連条件の発生回数、異なるイベント(例えば、特定のイベント関連条件が最初に発生したイベントはどれか)のイベント関連条件の発生の関係(例えば、順序やタイミング)など、複数イベントCHO実行のイベントに関連する情報が記録される。
【0033】
複数イベント条件ハンドオーバ実行は、ユーザデバイスによる複数イベントの共同評価に基づく場合があり、例えば、複数イベントCHO実行条件が実現されたかどうかを判定するために、様々な時点(例えば、両方のイベントの状態関連イベントを同時にまたは同時に評価することが含まれる場合がある)での両方のイベントの(例えば、1つ以上の条件関連イベントなど)に関連する情報を評価するUE/ユーザデバイスを含む場合がある。複数イベントCHO実行条件が満たされたか実現された場合、UEはターゲットセルに対してCHO実行を実行する場合がある(または典型的には実行する)。
【0034】
また、図2に関して、操作220は、ユーザデバイスまたはUEによって、情報の少なくとも一部を含むレポートを送信することを含む。したがって、レポートには、UEによって記録された情報の少なくとも一部が含まれる場合がある。レポート(例えば、これにはログに記録された情報が含まれることがある)は、RLFまたはHOの障害の検出後(BS、gNB)、またはネットワークノードからの要求に応答して、UEによってネットワークノードまたはネットワークに送信される場合がある。たとえば、複数イベントCHO実行に関連する情報のログを記録してから、より詳細なログを送信することで、ネットワーク、送信元ネットワークノード(例:ソースBS/gNB)、またはその他のネットワークノードまたはネットワークが、CHO実行条件の構成に関連付けられた1つ以上のパラメータを変更したり、複数イベントCHO実行の1つ以上のイベントの1つ以上のパラメータを変更したりできるようになり、たとえば、CHO実行の信頼性とパフォーマンスを向上させることができる。例では、複数イベント条件付きハンドオーバ実行には、2つのイベントの共同評価に基づくデュアルイベント(2イベント)条件付きハンドオーバ実行が含まれる場合がある。
【0035】
図2に関して、送信には、ユーザデバイスに対してハンドオーバ障害または無線リンク障害が発生した後に、ユーザデバイスがセルへの接続を再確立した後に、情報の少なくとも一部を含むレポートをユーザデバイスによって送信することが含まれる場合がある。
【0036】
図2の方法に関して、送信には、無線リンク障害またはハンドオーバ障害に対応して、情報の少なくとも一部を含むレポートをユーザデバイスによって送信することが含まれる場合がある。または、ネットワークノードからの要求に対応して、情報の少なくとも一部を含むレポートをユーザデバイスによって送信することが含まれる場合がある。
【0037】
図2の方法に関して、マルチイベント条件付きハンドオーバ実行は、複数のイベントに基づいてもよく、ここで、ログには、少なくとも、複数のイベントの1つ以上のイベントについて、イベント関連条件の発生のログ、イベント関連条件の発生回数、またはイベント関連条件の発生の時間またはタイミングを含めることができる。
【0038】
図2の方法に関して、イベント関連条件は、イベントのための時間トリガの状態であって、開始されていない、開始された、開始後に停止された、または満了されたのいずれかの状態を含む状態、イベントの開始条件を満たすイベント、イベントの終了条件を満たすイベント、ユーザ装置に対するハンドオーバ障害の発生、または、マルチイベント条件付きハンドオーバ実行の実行条件が実現されているか否か、のうちの少なくとも1つを含み得る。
【0039】
図2の方法に関して、ログ記録することは、複数のイベントのうちの1つ以上についてイベント関連条件が発生したかどうかを示すログ情報、複数のイベントのうちの1つ以上についてイベント関連条件が発生した回数を示すログ情報、複数のイベントのうちの少なくとも2つのイベントのイベント関連条件の時間関係またはそれらの間の時間差を記録するステップと、複数のイベントのうちの1つ以上についてイベント関連条件が発生した時間を示すログ情報、いずれのイベントについてイベント関連条件が最初に発生したかを示すログ情報、または、複数のイベントがマルチイベント条件付きハンドオーバ実行の実行条件を満たさないことに起因して、ユーザデバイスに対するハンドオーバの障害の回数を記録するログ情報、のうちの少なくとも1つを含み得る。
【0040】
また、ログ記録することは、たとえば、もしあれば、いずれのイベントがイベントの開始条件を満たし、時間トリガタイマを開始したかを示すログ情報、もしあれば、いずれのイベントがイベントの開始条件を満たし、時間トリガタイマを開始し、時間トリガタイマが満了したかを示すログ情報、ユーザデバイスによるマルチイベントの共同評価に基づくマルチイベント条件付きハンドオーバ実行の実行条件の実現の有無を示すログ情報、既に満了した時間トリガタイマを有する第1イベントが、第2イベントの時間トリガタイマが満了したときに第1イベントの終了条件を満たすか否かを示すログ情報、または、もしあれば、いずれのイベントがイベントに対する開始条件を満たしたかを示し、タイム・トゥ・トリガ・タイマを開始し、イベントに対するタイム・トゥ・トリガ・タイマは、満了する前に停止されたかを示すログ情報のうちの1つまたは複数を含む、複数のイベントのうちの1つまたは複数についてイベント関連条件が発生したかどうかを示すログ情報を含むことができる。
【0041】
図2の方法に関して、ログには、複数のイベントのうちの1つ以上に対してイベント関連の状態が発生した回数を示すログ情報が含まれる場合があり、例えば、もしあれば、各イベントが発生した場合に、その時間トリガタイマが何回開始したかを示すログ情報や、イベントの時間トリガタイマが満了する前に停止したことを示すログ情報が含まれる場合がある。
【0042】
図2の方法に関して、ログは、第2イベントに対する第2イベント関連条件に関する第1イベントに対する第1イベント関連条件の関係を示す情報のログを少なくとも含み得、これは、第1イベントの第1イベント関連条件と第2イベントの第2イベント関連条件との順序、第1イベントに対する第1イベント関連条件の発生と第2イベントの第2イベント関連条件の発生との間の時間、または、第1イベントについての第1イベント関連条件の発生の時間および第2イベントについての第2イベント関連条件の発生の時間、のうちの少なくとも1つを含み得る。
【0043】
図2の方法に関して、関係を示す情報のログは、第1イベントまたは第2イベントが最初に開始条件を実現したかどうかのログ、時間トリガタイマの内の1つが停止したまたは満了したときの第1イベントおよび第2イベントの時間トリガタイマの値を記録するログ、または、第1イベントおよび第2イベントの時間トリガタイマが並行して動作していた時間または期間を記録するログのうちの少なくとも1つを含み得る。
【0044】
図2の方法に関して、ログは、例えば、イベントの時間トリガタイマが起動された時刻を示すログ情報、イベントに対する時間トリガタイマが満了した時刻を示すログ情報、イベントの時間トリガタイマが停止した時刻を示すロギング情報、または、第1イベントの時間トリガタイマと第2イベントの時間トリガタイマが並行して動作していた時刻を示すログ情報のうちの少なくとも1つを含む、複数のイベントのうちの1つまたは複数についてイベント関連条件が発生した時間を示すログ情報を含み得る。
【0045】
図2の方法に関して、ログには、どのイベントに関連する条件が最初に発生したかを示すログ情報を含めることができ、例えば、もしあれば、いずれのイベントがイベントの開始条件を満たし、最初に時間トリガタイマを開始したかを示すログ情報、もしあれば、いずれのイベントが最初に時間トリガタイマを満了したかを示すログ情報、または、いずれのイベントがイベントの開始条件を満たし、時間トリガタイマを開始し、次いで時間トリガタイマを最初に停止したかを示すロギング情報、のうちの少なくとも1つを含み得る。
【0046】
図2の方法に関して、ログに記録される情報には、さまざまなカウンタによってカウントまたは追跡される可能性のある多数の障害(例:HO障害やRLF)が含まれる場合がある。したがって、たとえば、マルチイベント条件付きハンドオーバ実行の実行条件を実現していない複数のイベントによるユーザデバイスの条件付きハンドオーバの障害数をカウントする障害カウンタのログがログに記録される場合がある。これは、第1イベントと第2イベントの両方が非デュアル閾値測定イベントである場合の、第1イベントに対する時間トリガタイマが満了しなかった場合の条件付きハンドオーバ障害の数、または、第2イベントに対する時間トリガタイマが満了しなかった場合の条件付きハンドオーバ障害の数、の情報の1つ以上を記録するログを含み得る。
【0047】
障害カウンタをログ記録することは、第1イベントと第2イベントの両方がデュアル閾値測定イベントである場合の、ソースセル測定値が第1の閾値以下ではなかったため、第1イベントに対する時間トリガタイマが満了しなかったときの条件付きハンドオーバ障害の数、ターゲットセル測定値が第2の閾値よりも大きくなかったため、第2イベントに対する時間トリガタイマが満了しなかったときの条件付きハンドオーバ障害の数、ソースセル測定値が第1の閾値以下ではなかったため、第2イベントに対する時間トリガタイマが満了しなかったときの条件付きハンドオーバ障害の数、または、ターゲットセル測定値が第2の閾値よりも大きくなかったため、第1イベントに対する時間トリガタイマが満了しなかったときの条件付きハンドオーバ障害の数、の情報のうちの1つまたは複数をログ記録することを含み得る。
【0048】
または、障害カウンタのログには、第1イベントの時間トリガタイマが満了し、第2イベントの時間トリガタイマが満了したが、第2イベントの時間トリガタイマが満了したときに第1イベントの終了条件が実現されたことに基づく条件付きハンドオーバの障害数のログが含まれる場合がある。
【0049】
図2に関して、ログは、例えば、第1イベントの構成及び/又は第2イベントの構成を記録すること、もしあれば、いずれのイベントがイベントの開始条件を実現し、時間トリガタイマを開始したかを示すログ情報、もしあれば、いずれのイベントがイベントの開始条件を実現し、時間トリガタイマを開始し、イベントの時間トリガタイマが満了したかを示すログ情報、マルチイベント条件付きハンドオーバ実行の実行条件の実現の有無を示すログ情報、既に満了した時間トリガタイマを有する第1のイベントが、第2のイベントの時間トリガタイマが満了したときに第1のイベントの離脱条件を実現するか否かを示すログ情報、もしあれば、いずれのイベントが時間トリガタイマを開始し、イベントについての時間トリガタイマが満了する前に停止されたかを示すログ情報、もしあれば、いずれのイベントが時間トリガタイマを開始したかを示し、イベントについての時間トリガタイマが満了する前に停止されたことを示すログ情報、第1イベントまたは第2イベントが最初に開始条件を実現するかどうかを記録することと、時間トリガタイマのうちの1つが停止または満了したときに、第1イベントおよび第2イベントの時間トリガタイマの値を記録すること、第1イベント及び第2イベントの時間トリガタイマが並行して動作していた時間又は期間を記録すること、イベントの時間トリガタイマが起動された時刻を示すログ情報、イベントに対する時間トリガタイマが満了した時間を示すログ情報、イベントの時間トリガタイマが停止した時刻を示すログ情報、第1イベントに対する時間トリガタイマが、第2イベントに対する時間トリガタイマと並行して動作していた時間を示すログ情報、もしあれば、いずれのイベントがイベントの開始条件を満たし、最初に時間トリガタイマを開始したかを示すログ情報、もしあれば、いずれのイベントが時間トリガタイマを最初に満了したかを示すログ情報、もしあれば、いずれのイベントがイベントの開始条件を実現し、時間トリガタイマを開始し、次いで時間トリガタイマを最初に停止したかを示す情報を記録すること、または、複数イベントがマルチイベント条件付きハンドオーバ実行の実行条件を実現しないことによるユーザデバイスの条件付きハンドオーバの障害の回数をカウントする障害カウンタを記録すること、のうちの1つまたは複数を含み得る。
【0050】
図2の方法に関して、この方法は、少なくとも第1のイベントの構成と第2イベントの構成を含むマルチイベントのそれぞれの構成と、条件付きハンドオーバ実行を行うかどうかを判定するためにユーザデバイスによるマルチイベントの共同評価を構成する共同評価構成を含む、条件付きハンドオーバの一部として、ユーザデバイスが前記ネットワークノードから、ハンドオーバコマンドを受信することをさらに含むことができる。
【0051】
図2の方法に関して、この方法は、さらに、ソースネットワークノードからターゲットネットワークノードへのユーザデバイスの条件付きハンドオーバ実行を実行するかどうかを判定するために、ユーザデバイスによって複数のイベントを共同で評価することを含むことができる。
【0052】
図3は、一例の実施形態によるネットワークノード(例:BS、gNBまたはその他のネットワークノード)の動作を示すフローチャートである。動作310は、ユーザデバイスによる条件付きハンドオーバ実行のために共同で評価されるマルチイベントの構成を含む共同イベント構成情報を持つハンドオーバコマンドを、ネットワークノードによってユーザデバイスに送信することを含む。動作320は、ユーザデバイスによるマルチイベント条件付きハンドオーバ実行の障害に関するユーザデバイスによって記録された情報を含むレポートをネットワークノードによって受信することを含み、マルチイベント条件付きハンドオーバ実行は複数のイベントに基づいている。また、動作330は、レポートに基づいてネットワークノードによって、マルチイベント条件付きハンドオーバ実行のための一つ以上のイベントの構成に関連付けられた一つ以上のパラメータを変更することを含む。
【0053】
図3の方法について、共同イベント構成情報は、条件付きハンドオーバ実行を行うかどうかを判定するために、ユーザデバイスによるマルチイベントの共同評価を構成する共同評価構成を含む。共同イベント構成情報には、CHO実行条件、マルチイベントのそれぞれの構成などを記述する情報が含まれる場合がある。
【0054】
図3の方法について、ユーザデバイスが記録する情報には、複数のイベントのうち1つ以上のイベント関連条件の発生、イベント関連条件の発生回数、イベント関連条件の発生時刻や発生タイミングなどが含まれる場合がある。前述のように、イベント関連の条件は、例えば、イベントのための時間トリガタイマの状態であって、開始されていない、開始された、開始後に停止された、または満了したのいずれかの状態を含む状態、イベントの開始条件を実現するイベント、イベントの終了条件を満たすイベント、ユーザデバイスに対するハンドオーバ障害の発生、または、マルチイベント条件付きハンドオーバ実行の実行条件が実現されているか否か、のうちの少なくとも1つを含んでもよい。
【0055】
図3の方法に関して、ユーザデバイスによって記録された情報は、複数のイベントのうちの1つ以上についてイベント関連条件が発生したかどうかを示す情報、複数のイベントのうちの1つ以上についてイベント関連条件が発生した回数を示す情報、複数のイベントのうちの少なくとも2つのイベントのイベント関連条件の間の時間関係又は時間差、複数のイベントのうちの1つ以上についてイベント関連条件が発生した時間を示す情報、どのイベントについてイベント関連条件が最初に発生したかを示す情報、または、複数のイベントが複数イベント条件付きハンドオーバ実行の実行条件を実現しないことによるユーザデバイスのハンドオーバの障害の回数、のうちの少なくとも1つを含み得る。
【0056】
図4は、一実施例によるマルチイベント条件付き引き継ぎ(CHO)を示す図である。図4に示すように、UE132、ソースセルに対応付けられたサービングノード210(例:BSへのサービス提供)、ターゲットセルに対応付けられたターゲットノード214を示す。また、例えば、サービングゲートウェイ/ユーザプレーン機能(S-GW/UPF)、モビリティ管理エンティティ/アクセスおよびモビリティ管理機能(MME/AMF)機能を含むコアネットワークエンティティも示す。操作1~16を図4に示す。たとえば、処理1~6をCHO準備に関連付け、処理7~16をCHO実行に関連付けることができる。処理1では、測定レポート(複数可)がサービングノード210に送信され、たとえば、ソースセルと1つ以上のターゲットセルのRSRP(またはその他の信号測定)を示し、サービングノード210がUEのハンドオーバの可能性がある1つ以上のターゲットセルを判定できるようにする。
【0057】
図4の処理2では、サービングノード210は、たとえば、1つ以上の(可能な)ターゲットセルへのUEの条件付きハンドオーバを実行するようにCHO決定を行うことができる。処理3では、CHO要求がターゲットセルに関連付けられているターゲットノード214に送信される。表示されていないCHO要求は、他のターゲットノードに送信される場合がある。処理4で、ターゲットノード214は、要求されたUE132のハンドオーバを受け入れる決定を行うためにアドミッション制御を実行する。処理5で、ターゲットノード214はCHO要求確認応答を送信し、UE132の要求されたCHOをターゲットセルに受け入れまたは確認し、ターゲットセルのターゲットセル構成を提供する。
【0058】
図4の処理6で、UEはハンドオーバ(HO)コマンドによる再構成メッセージ(例:RRCの再構成)を受信する。RRCメッセージには、例えば、マルチイベントCHO構成も含まれ、これには、ターゲットセル構成(例えば、ランダムアクセスプリアンブル伝送/RACHのターゲットリソースを含む)、マルチイベントCHO実行条件の表示(例えば、マルチイベントに対して、どのような特定の条件またはイベント関連の条件が存在するか、または発生したかを示して、CHOの実行をターゲットセルにトリガすることができる。)、およびマルチイベントのイベント構成のうちの1つ以上が含まれる場合がある。たとえば、イベント構成には、イベントの開始条件の1つ以上のパラメータ(例:threshold、hyst、CIO、Offまたはoffset、またはイベントの開始条件のその他のパラメータ、TTT値)が含まれる場合がある。マルチイベントCHO実行条件の表示には、たとえば、複数の可能なCHO実行条件の中から、特定のマルチイベントCHO実行条件を示すフィールドまたはパラメータが含まれる場合がある。たとえば、2つのイベント(第1のイベントと第2のイベント)に基づくデュアルイベントCHO実行の場合、第2イベントの時間トリガ(TTT)タイマが満了になったときに、すでに満了になっている時間トリガ(TTT)タイマを持つ第1イベントが第1イベントの終了条件を実現しなかった場合、マルチイベントCHO実行がUEによって実行されるという例が挙げられる。これはマルチイベントCHO実行条件の一例であり、他のものを使用できる。場合によっては、マルチイベントCHO実行条件が事前に構成されているか、またはUEによって事前に知られていることがある。
【0059】
図4の処理7では、マルチイベントCHO実行に関連する情報のログ記録を実行し、マルチイベントの共同評価(例えば、マルチイベントの評価や、マルチイベントの様々な事象関連の状態を、様々な時点で同時に評価すること)を実行して、CHO実行条件が実現されたかどうかを判定する場合がある。
【0060】
図4の処理8では、UEはマルチイベントCHO実行条件が実現されたと判定する(例えば、マルチイベントの共同評価に基づいて、CHO実行をターゲットセル/ターゲットノードにトリガし、UE132をソースノードから切り離して、ソースノードとの送受信を停止する。
【0061】
CHO実行中に障害(例:RLFやHOの障害)が発生した場合、UEは(例えば、セルに再接続した後)、マルチイベントCHO実行に関連するログに記録された情報のすべてまたは一部を含むレポートをネットワークノードに送信することができる。または、マルチイベントCHO実行に関連するログに記録された情報のすべてまたは一部を含むレポートを、要求に応じてネットワークノードに送信することができる。マルチイベントCHO実行に関連するログに記録された情報(例:障害)を含むレポートは、ネットワークおよび/またはソースノードがモビリティ堅牢性最適化(MRO:Mobility Robustness Optimization)を実行できるように、たとえば、ソースノードまたはネットワークが障害の原因となったイベントを判定し、その後、マルチイベントCHO実行の信頼性および/または動作を向上させるために調整する必要がある(例:障害の原因となった可能性のあるイベントのTTTまたはオフセットの調整)マルチイベントCHO実行に関連する1つ以上のパラメータまたは機能を判定するために、ソースノードに転送される場合がある。
【0062】
図4の残りの処理9~16は、障害がないことを前提としたCHO実行の一部である(例えば、RLFやHOの障害がないと仮定する)。
【0063】
図4の9で、サービングノード210/ソースセルは、UE132とのデータの送受信を停止し、UEのDLデータをターゲットノード214に転送し始める。ソースノード210がターゲットノード214に転送するDLデータには、ソースノード210がUE132に送信したが、UEが確認応答していないDL(ダウンリンク)データ、およびソースノード210が受信したが、まだUE132に送信されていない(コアネットワークからの)新規受信DLデータが含まれる場合がある。
【0064】
図4の処理10、11では、10でのシーケンス番号ステータス転送、処理11でのデータ転送を含むデータ転送が行われる。一例の実施例では、送信元セルは、UEとの送受信を停止した直後にデータ転送を開始する。さらに、送信元セルは、DLおよびULの次の欠落PDCP COUNT値、すなわち、ターゲットセルがDLで送信またはULで受信すべき次の欠落パケットを定義する、ハンドオーバ「SNステータス転送」メッセージのターゲットセルに送信する。
【0065】
その後、UEは、ターゲットノード/ターゲットセルとの同期を実行し(例えば、ターゲットノード/ターゲットセルからPSSとSSSを受信する)、その後、ターゲットノード/ターゲットセルとランダムアクセスを実行して、処理12でRACH(ランダムアクセス)プリアンブルを送信し、処理13でランダムアクセス(RACH)応答を受信するなど、ターゲットノード/ターゲットセルとの接続を確立できる。UEがターゲットノード/ターゲットセルへの接続を確立すると、処理14で、UE132はRRC再構成完了メッセージ/指示をターゲットノード/ターゲットセルに送信し、処理15のターゲットノードは、ハンドオーバ成功の指示をサービングノード/ソースセルに応答し、コアネットワークとソースノードおよびターゲットノード間でUEトラフィックのパススイッチが処理16で実行される。
【0066】
図5は、一実施例によるデュアルイベント条件付きハンドオーバ(CHO)の実行を示す図である。図5に示すように、A3イベントを含むマルチ(またはデュアル)イベントCHOの実行と、A5イベントの2つのイベントが用意されている。T1の時点で、CHO(またはハンドオーバ)コマンドは、例えば、CHO実行条件を含むマルチイベントCHO構成、および/または各イベントのイベント構成を含むUEによって受信される。したがって、T1の時点で、この例では、イベントA3およびA5のイベント構成がUEによって受信される。T2の時点で、UEはイベントA3が初めて開始条件を実現したと判定する(つまり、イベントA3のTTTタイマを開始する)。T3の時点で、イベントA5が初めてイベントの開始条件を実現したため、A5イベントのTTTタイマを開始する。T4の時点で、イベントA3がトリガされる(A3のTTTタイマが期限切れになる)。T5の時点で、イベントA5がトリガされる(イベントA5のTTTタイマが期限切れになる)。510で示される時刻T5(およびその他のさまざまな可能性のある時刻)に、UEは、マルチイベントCHO実行条件が実現されているかどうかを判定するために、イベントA3とA5の両方を共同で評価することができる。したがって、T5でA3イベント終了条件がT5で真でない場合、CHO実行が行われる。マルチイベントCHO実行に関連する情報のログの一部として記録される可能性のある情報要素(IE)の例。図5に示された時間とイベントは、記録される可能性のあるIEの例のいくつかを説明するのに役立つかもしれない。
【0067】
イベント1(A3イベント)とイベント2(A5イベント)の両方が、CHO実行条件のイベントとしてUEに構成され、(マルチイベントに基づく)CHO実行条件が実現されたかどうかを判定するなど、1つ以上の時点で同時に評価され、それによってCHO実行がトリガされるとする。2つのイベントの考えられるタイムラインとその評価を図5に示す。どのイベントが最初にトリガされるか、トリガされるイベント間の時間、1つ以上のポイントでの2つのイベントの共同評価(例えば同時に)がCHO実行をトリガするかどうかなどがわからないため、記述されたタイムラインには多くの組み合わせ(またはさまざまなイベントに対してさまざまなシナリオやさまざまなイベント関連条件のさまざまな発生)がある可能性があることに注意されたい。図5に示すデュアルイベントのタイムラインは、例として1つの考えられるタイムラインにすぎず、成功したCHOまたは成功したCHO実行のベストケースシナリオについてさえ説明している。ただし、一般に、T1とT5の間の任意のポイントなど、任意のポイントにRLFが存在する場合がある。
【0068】
T1とT5の間で何らかの問題(例:RLFやHO障害などの障害)が発生した場合、UEは通常、(試行された)マルチイベントCHO実行に関連する情報をログに記録し続け(例えば、マルチイベントの各イベントのイベント関連条件をログに記録する)、UEはネットワークまたはサービングノードにレポート(例えば、ログに記録された情報の全部または一部を含む)を送信する場合がある。RLFがあった場合、UEは一時的に切断された後、(ランダムアクセスを行うことで)セルに接続または再接続する。
【0069】
図5には示されていないが、UEに対してはすでにCHOの準備が行われており、A3とA5(例)の2つのイベントが構成されており、1つのイベントが最初にトリガされ(A3イベントが開始条件を満たす)、TTTが開始される。第1イベント(A3)が実行中に、第2イベント(A5)が開始条件を実現する。第1イベント(A3)TTTは有効期限が切れ、第2イベント(A5)TTTは実行を継続する。この例では、2つのイベントの(または例)共同評価ポイントはT5にあり、たとえば、両方のイベントの有効期限が切れた後(この成功したCHO実行例による)。T5の時点で、この例では第2イベントの有効期限が切れた時点で、A3終了条件がtrueでない場合はCHOが実行される。
【0070】
現在、RLFおよびMRO(モビリティ堅牢性最適化)KPI(Key Performance Indicators)でのUEログは、マルチイベント(例:デュアルイベント)を使用してCHOを実行した場合に、ネットワーク/MROがRLFの根本原因(またはその他の障害)を特定するのを支援しない。そのため、現在、ネットワークは、特にマルチイベントCHOを実行した場合に、パフォーマンスを向上させるモビリティパラメータの調整について、正確または正確な決定を行うことができない。
【0071】
前述のように、各イベントには、Offset、Hyst(ヒステリシス値)、TTTなど、多数の設定可能な(または可変の)モビリティ関連パラメータが存在する可能性がある。測定イベントのモビリティ関連パラメータが誤って構成されている場合、UEがCHOを適切に実行できず、代わりにRLFが発生する可能性がある。したがって、マルチイベントCHO実行のためのマルチイベントのモビリティパラメータは、適切に構成されているか、最適化されている場合でも、効率的かつ正しくCHOを実行するために望ましいものだ。ネットワーク内の接続障害(無線リンク障害およびハンドオーバ障害)の数を減らすことを目的としたモビリティ堅牢性最適化(MRO)は、情報またはレポートに基づいてモビリティパラメータを調整することで、この問題に対応できる。イベントパラメータの調整は、UEがログに記録し、UEがネットワーク(またはネットワークノード)に報告する可能性のある情報(例えば、マルチイベントのCHO実行に関連するログ情報)、例えば、RLFレポート、ログに記録された測定レポート、またはその他のレポートに基づいて行うことができる。RLFレポートの情報は、MDT機能によって評価されるログに記録された測定レポートに追加することもできる。
【0072】
マルチイベントCHO実行に関連する情報など、さまざまな情報がUEによってログに記録されることがあり、それらはUEによって報告され、後にネットワーク(例:送信元ネットワークノード)によって1つ以上のパラメータを調整してCHO実行のパフォーマンスや信頼性を向上させるために使用されることがある。以下は、マルチイベントCHO実行の1つ以上のイベントに対してUEによってログ/収集される可能性があるいくつかの情報要素(IE)の例のリストである。この情報またはIEは、マルチイベントに対して、UEによってネットワークまたはネットワークノードに報告される可能性がある。例えば、RLFまたはHOの障害などの障害が発生した場合、例えば、ネットワークまたはネットワークノードが根本原因分析を実行して障害の根本原因(例:RLFやHOの障害)を判定するのを支援したり、将来的にCHO実行を改善するのを支援したりするために使用される。ネットワークノードなどのネットワークによって実行される根本原因分析は、ログに記録された情報/IEに基づいて、例えば、マルチイベントのうち、いずれのイベントが障害の原因であるかを判定するために実行される可能性があり、CHO実行のパフォーマンスおよび/または信頼性を向上させるために、どのような可能性のあるパラメータ調整が必要であるか、または実行される可能性があるかを特定するために実行される可能性がある。次に、ログに記録される可能性のあるいくつかのIEの例(例えば、RLFやHOの障害を減らすように設計されたパラメータ調整)と、CHO実行のパフォーマンスおよび/または信頼性を向上させるために実行される可能性のあるいくつかの根本原因分析および可能性のあるパラメータ調整について説明する。
【0073】
IE(情報要素)1:イベント1(A3)およびイベント2(この例ではA5)の構成を識別する(発行セルは構成を長時間保持しない可能性があり、ネットワークからの信号値はUE側でスケーリングされる可能性がある)。イベント構成は、例えば、イベントタイプ(例:A3またはA5)、測定される信号パラメータ、および関連するヒステリシス、オフセット、TTT(UE速度に基づいてUEによってスケーリングされる可能性がある)、またはその他のイベント関連パラメータの1つ以上を示すことができる。
【0074】
IE2:TTT期間の開始条件を実現した、つまり、TTTを開始し、(存在する場合)TTTが満了したイベントはどれか-イベント1、イベント2、両方、またはなし。両方のイベントに関する情報を提供する。CHOのデュアルイベント設定の場合。
【0075】
IE3:イベントのTTTが満了したときのタイムスタンプ(または時刻)、例えば図5のT4/T5。
【0076】
IE4:第1のイベント(TTTがすでに満了している)が終了条件を満たしていないか、第2のイベントのTTTが満了したときに満たしていないかの表示-T5での評価結果。
【0077】
IE5:Event1および/またはEvent2が開始条件を実現し、TTTが開始された。
【0078】
IE6:イベントのTTTが開始されたときのタイムスタンプ(または時刻)-図5のT2およびT3。
【0079】
IE7:開始条件TTTを実現する第1のイベントの開始から、開始条件TTTを実現する第2のイベントの開始までの時間差-図5の(T3-T2)。
【0080】
IE8:2つのイベントTTTが並行して実行されていた時間-図5の(T4-T3)。
【0081】
IE9:開始条件を実現し、最初にTTTを開始したイベント-イベント1またはイベント2、両方同時。図5の例では、T2で第1のイベント(A3)が開始条件を満たし、最初にTTTを開始した。
【0082】
IE10:イベント1/イベント2 TTTを開始したが、期限切れになる前に停止した。
【0083】
IE11:失効前に停止した場合のイベント1/イベント2のTTTの値。
【0084】
IE12:失効前にイベント1/イベント2のTTTが開始され、停止された時間の数。
【0085】
次に、この情報をモビリティ堅牢性最適化(MRO)の目的(例えば、情報要素の組み合わせに基づくことができる)にさらに使用する方法の例をいくつか説明する。CHO最適化とは、CHOの信頼性とパフォーマンスを向上させるなど、安定性を維持しながらCHOがトリガされる回数を増やすことである。図5は、成功したCHOの実行を示すタイムラインを示しており、T5でUEがCHOの実行をトリガする(2つのイベントのT5での共同評価に基づく)ことに注意されたい。ただし、図5には示されていないが、問題や障害はいつでも発生する可能性がある。たとえば、RLF HO障害のような障害は、そのタイムラインのどこでも発生する可能性がある。したがって、T5より前のどこかで障害が発生した場合、他のさまざまなイベント関連の状態(図5には示されていない)が発生し、さまざまなIEを使用してログに記録される可能性がある。したがって、たとえば、障害やその他の状態によってTTTタイマが期限切れになる前に停止した場合、第2のイベントがトリガされないかTTTタイマを開始しない場合、イベントがまったく重複しない場合など、図5に示されていないその他のさまざまなイベント関連の状態が発生したり、記録されたりする可能性がある。
【0086】
IE8:T4-T3が0(2つのイベントのTTTが重複していない)であり、前述のIE4=FALSEの値(開始条件を満たす第1のイベントで、TTTが期限切れになったものは、第2のイベントのTTTが期限切れになったときに終了条件を実現している)。したがって、2つのイベントの全体的な評価に時間がかかりすぎたため、イベント2がより早く開始条件を実現する(およびTTTを開始する)ように、第2のイベントのTTTまたはその開始条件を制御するオフセットを緩和できた(または緩和する必要がある)ことを意味し、第2のイベントのTTTが期限切れになったときに、第1のイベントが終了条件を実現しない可能性が高くなる。
【0087】
IE10はTrue(TTTが期限切れになる前に停止)であり、IE11<<TTTの値は、イベントの設定が控えめすぎることを意味する場合がある。
これは図5には示されていないが、発生する可能性がある。
【0088】
IE2の値:別の例(図5には示されていない)では、イベント1のTTTだけが期限切れになっている。これは、CHOが実行される機会がなかったことを意味する。
イベント2の設定を変更する必要がある。
【0089】
IE2の値:別の例(図5には示されていない)では、いずれのイベントもTTTの有効期限が切れていなかった(TTTはいずれのイベントでも有効期限が切れなかった)。これは、両方のイベント設定を変更する必要があることを示している。
【0090】
IE6(TTTがイベントに対して開始されたときのタイムスタンプ)の値は、時刻T1にCHO実行がUEに提供されてからかなり後に発生する。これは、両方のイベントの設定を緩和できることを示す。
【0091】
また、障害をカウントしたり、マルチイベントのCHO実行に関連するログ情報に格納したりすることもできる。そこで、上記の二重イベントCHO実行条件を実現していないことによる障害(遅すぎるハンドオーバ)を、デュアルイベントCHO実行用の新しいサブカウンタにカウントすることを提案する。
【0092】
ここで説明する3つのケースは、デュアルイベントCHO実行の2つのイベントとして、非デュアル閾値測定イベント(例:A3イベント)、デュアル閾値測定イベント(例:A5イベント)、またはそれぞれの1つを使用するかどうかによって異なる。
【0093】
1)次のサブカウンタは、イベント1および/またはイベント2がデュアル閾値測定イベントではない場合に使用できる。
【0094】
イベント1はトリガされない(イベント1のTTTは満了していない)。
【0095】
CHO.OutFail.TooLateEvent1NotTriggered障害カウンタがインクリメントされる。
【0096】
イベント2はトリガされない(イベント2のTTTは満了しなかった)。
【0097】
CHO.OutFail.TooLateEvent2NotTriggered障害カウンタがインクリメントされる。
【0098】
2)イベント1および/または2がデュアル閾値測定イベント(例:A5)である場合、特定のタイプの障害が発生したときにインクリメントされる次のサブカウンタを持つことができる。
【0099】
イベント1はトリガされない。
【0100】
Source measurementがThreshold1(Th1)を下回っていないため、イベント1はトリガされない。
【0101】
CHO.OutFail.TooLateEvent 1 OwnNotCrossed障害カウンタがインクリメントされる。
【0102】
Target測定が閾値2(Th2)を超えることがないため、イベント1がトリガされることはない。
【0103】
CHO.OutFail.TooLateEvent 1 NeighbourNotCrossed障害カウンタがインクリメントされる。
【0104】
イベント2はトリガされない。
【0105】
Source測定がTh1の下にないため、イベント2はトリガされない。
【0106】
CHO.OutFail.TooLateEvent2OwnNotCrossed障害カウンタがインクリメントされる。
【0107】
Target測定がTh2を超えていないため、イベント2がトリガされることはない。
【0108】
CHO.OutFail.TooLateEvent2NeighbourNotCrossed障害カウンタがインクリメントされる。
【0109】
3)A3イベントとA5イベントの両方:イベント1とイベント2がトリガされるが、最初にトリガされたイベントの終了条件は、第2のイベントのTTTが期限切れになったときに実現された。CHO.OutFail.TooLateEvent 12 CombinatonNotTriggered障害カウンタがインクリメントされる。
【0110】
いくつかの例について説明する。
【0111】
[例1]
無線ネットワーク内のユーザデバイスによって、マルチイベント条件付きハンドオーバ実行に関連する情報をログ記録するステップであって、前記マルチイベント条件付きハンドオーバ実行は、前記ユーザデバイスによるマルチイベントの共同評価に基づいているステップと、前記ユーザデバイスによって、情報の少なくとも一部を含むレポートを送信するステップとを含む方法。
【0112】
[例2]
前記マルチイベント条件付きハンドオーバ実行が、2つのイベントの共同評価に基づいているデュアルイベント条件付きハンドオーバ実行を含む、例1の方法。
【0113】
[例3]
前記送信するステップは、前記ユーザデバイスでハンドオーバ障害または無線リンク障害が発生した後、ユーザデバイスはセルへの接続を再確立した後に、前記ユーザデバイスによって、前記情報の少なくとも一部を含むレポートを送信するステップを含む、例1-2のいずれかの方法。
【0114】
[例4]
前記送信するステップは、無線リンク障害またはハンドオーバ障害に応答する前記ユーザデバイスによって、前記情報の少なくとも一部を含むレポートを送信するステップ、または、ネットワークノードからの要求に応答する前記ユーザデバイスによって、前記情報の少なくとも一部を含むレポートを送信するステップ
を含む、請求項3に記載の方法。
【0115】
[例5]
前記マルチイベント条件付きハンドオーバ実行は複数のイベントに基づいており、前記ログ記録するステップは、複数のイベントのうちの1つ以上のイベントについて、イベント関連条件の発生、イベント関連条件の発生回数、またはイベント関連条件の発生の時間またはタイミングを少なくともログ記録するステップを含む、例1-4のいずれかの方法。
【0116】
[例6]
イベント関連条件が、開始されていない、開始された、開始後に停止された、または、満了した内のいずれかのステータスを含む、イベントの時間トリガタイマのステータス、前記イベントの開始条件を実現するイベント、前記イベントの開始条件を実現するイベント、前記ユーザデバイスのハンドオーバ障害の発生、または、前記マルチイベント条件付きハンドオーバ実行についての実行条件を実現したか否か、のうちの少なくとも1つを含む、例5の方法。
【0117】
[例7]
前記マルチイベント条件付きハンドオーバ実行は複数のイベントに基づいており、前記ログ記録するステップが、複数のイベントのうちの1つ以上についてイベント関連条件が発生したかどうかを示す情報をログ記録するステップ、複数のイベントのうちの1つ以上についてイベント関連条件が発生した回数を示す情報をログ記録するステップ、複数のイベントのうちの少なくとも2つのイベントのイベント関連条件の時間関係またはそれらの間の時間差をログ記録するステップと、複数のイベントのうちの1つ以上についてイベント関連条件が発生した時間を示す情報をログ記録するステップ、どのイベントについてイベント関連条件が最初に発生したかを示す情報をログ記録するステップ、または、複数のイベントがマルチイベント条件付きハンドオーバ実行の実行条件を実現しないことに起因して、ユーザデバイスに対するハンドオーバの障害の回数をログ記録するステップ、のうちの少なくとも1つを含む、例1-6のいずれかの方法。
【0118】
[例8]
前記マルチイベント条件付きハンドオーバ実行は複数のイベントに基づいており、前記ログ記録するステップが、前記複数のイベントのうちの1つ以上についてイベント関連条件が発生したかどうかを示す情報をログ記録するステップを含む、上記例のうちのいずれかの方法。
【0119】
[例9]
前記複数のイベントのうちの1つ以上についてイベント関連条件が発生したかどうかを示す情報をログ記録するステップが、もしあれば、いずれのイベントが前記イベントの開始条件を満たし、時間トリガタイマを開始したかを示す情報をログ記録するステップ、もしあれば、いずれのイベントが前記イベントの開始条件を満たし、時間トリガタイマを開始し、前記イベントについての時間トリガタイマが満了したかを示す情報をログ記録するステップ、前記ユーザデバイスによるマルチイベントの共同評価に基づく前記マルチイベント条件付きハンドオーバ実行の実行条件が実現しているか否かを示す情報をログ記録するステップ、既に満了した時間トリガタイマを有する第1イベントが、第2イベントの時間トリガタイマが満了したときに前記第1イベントの終了条件を満たすか否かを示す情報をログ記録するステップ、または、もしあれば、いずれのイベントが前記イベントに対する開始条件を実現し、時間トリガタイマを開始し、前記イベントに対する時間トリガタイマは、満了する前に停止されたかを示す情報をログ記録するステップのうちの少なくとも1つを含む、例8の方法。
【0120】
[例10]
前記マルチイベント条件付きハンドオーバ実行は複数のイベントに基づいており、前記ログ記録するステップは、前記複数のイベントのうちの1つ以上についてイベント関連条件が発生した回数を示すログ情報をログ記録するステップを含む、例1~9のうちのいずれかの方法。
【0121】
[例11]
前記ログ記録するステップは、各イベントが、もしあれば、前記時間トリガタイマが何回開始したか、および、前記イベントの前記時間トリガタイマが満了する前に停止したことを示す情報をログ記録するステップを少なくとも含む前記複数のイベントのうちの1つ以上についてイベント関連条件が発生した回数を示すログ情報をログ記録するステップを含む、例10の方法。
【0122】
[例12]
前記マルチイベント条件付きハンドオーバ実行は少なくとも第1イベントおよび第2イベントを含む複数のイベントに基づいており、前記ログ記録するステップは、前記第2イベントに対する第2イベント関連条件に関する前記第1イベントに対する第1イベント関連条件の関係を示す情報をログ記録するステップを含む、例1-7のいずれかの方法。
【0123】
[例13]
関係を示す前記情報は、第1イベントの第1イベント関連条件と第2イベントの第2イベント関連条件との順序、第1イベントに対する第1イベント関連条件の発生と第2イベントの第2イベント関連条件の発生との間の時間、または、前記第1イベントについての第1イベント関連条件の発生の時間および第2イベントについての第2イベント関連条件の発生の時間、のうちの少なくとも1つを含む、例12の方法。
【0124】
[例14]
関係を示す情報を前記ログ記録するステップは、第1イベントまたは第2イベントが最初に開始条件を実現したかどうかをログ記録するステップ、時間トリガタイマのうちの1つが停止または満了したときの前記第1イベントおよび前記第2イベントの時間トリガタイマの値をログ記録するステップ、または、前記第1イベントおよび前記第2イベントの時間トリガタイマが並行して動作していた時間または期間をログ記録するステップ、の内の少なくとも1つを含む、例12-13のいずれかの方法。
【0125】
[例15]
前記マルチイベント条件付きハンドオーバ実行は複数のイベントに基づき、前記ログ記録するステップは、前記複数のイベントのうちの1つまたは複数についてイベント関連条件が発生した時間を示す情報をログ記録するステップを含む、例1-7のいずれかの方法。
【0126】
[例16]
前記ログ記録するステップは、イベントの時間トリガタイマが開始した時刻を示す情報をログ記録するステップ、イベントの時間トリガタイマが満了した時刻を示す情報をログ記録するステップ、イベントの時間トリガタイマが停止した時刻を示す情報をログ記録するステップ、または、第1イベントの時間トリガタイマと第2イベントの時間トリガタイマが並行して動作していた時刻を示す情報をログ記録するステップのうちの少なくとも1つを含む前記複数のイベントのうちの1つまたは複数についてイベント関連条件が発生した時間を示す情報をログ記録するステップを含む、例15の方法。
【0127】
[例17]
前記マルチイベント条件付きハンドオーバ実行は複数のイベントに基づき、前記ログ記録するステップは、どのイベントに関連する条件が最初に発生したかを示す情報をログ記録するステップを含む、例1-7のいずれかの方法。
【0128】
[例18]
いずれのイベントに関連する条件が最初に発生したかを示す情報を前記ログ記録するステップは、もしあれば、いずれのイベントが前記イベントの開始条件を実現し、最初に時間トリガタイマを開始したかを示す情報をログ記録するステップ、もしあれば、いずれのイベントが最初に時間トリガタイマを満了したかを示す情報をログ記録するステップ、または、どのイベントがイベントの開始条件を満たし、時間トリガタイマを開始し、次いで時間トリガタイマを最初に停止したかを示す情報をログ記録するステップ、のうちの少なくとも1つを含む、例17の方法。
【0129】
[例19]
前記マルチイベント条件付きハンドオーバ実行は少なくとも第1イベントおよび第2イベントを含む複数のイベントに基づいており、前記ログ記録するステップは、前記マルチイベント条件付きハンドオーバ実行の実行条件を実現していない前記複数のイベントによる前記ユーザデバイスの条件付きハンドオーバの障害数をカウントする障害カウンタをログ記録するステップを含む、例1-18のいずれかの方法。
【0130】
[例20]
前記第1イベントおよび前記第2イベントの両方が非デュアル閾値測定イベントである場合に、障害カウンタを前記ログ記録するステップが、前記第1イベントに対する時間トリガタイマが満了しなかった場合の条件付きハンドオーバ障害の数、または、前記第2イベントに対する時間トリガタイマが満了しなかった場合の条件付きハンドオーバ障害の数、の情報のうちの1つ以上をログ記録するステップを含む、例19の方法。
【0131】
[例21]
前記第1イベントおよび前記第2イベントの両方がデュアル閾値測定イベントである場合に、障害カウンタを前記ログ記録するステップが、ソースセル測定値が第1の閾値以下ではないため、前記第1イベントに対する時間トリガタイマが満了しないときの条件付きハンドオーバ障害の数、ターゲットセル測定値が第2の閾値よりも大きくないため、前記第2イベントに対する時間トリガタイマが満了しないときの条件付きハンドオーバ障害の数、ソースセル測定値が第1の閾値以下ではないため、前記第2イベントに対する時間トリガタイマが満了しないときの条件付きハンドオーバ障害の数、または、ターゲットセル測定値が第2の閾値よりも大きくないため、前記第1イベントに対する時間トリガタイマが満了しないときの条件付きハンドオーバ障害の数、の情報のうちの1つ以上をログ記録するステップを含む、例19の方法。
【0132】
[例22]
前記障害カウンタをログ記録するステップは、
前記第1イベントの時間トリガタイマが満了し前記第2イベントの時間トリガタイマが満了したが、第2イベントの時間トリガタイマが満了したときに第1イベントの終了条件が実現されたことに基づく条件付きハンドオーバの障害の数をログ記録するステップを含む、例19の方法。
【0133】
[例23]
前記マルチイベント条件付きハンドオーバ実行は少なくとも第1イベントおよび第2イベントを含む複数のイベントに基づいており、前記ログ記録するステップは、第1イベントの構成および/または第2イベントの構成をログ記録するステップ、もしあれば、いずれのイベントがイベントの開始条件を実現し、時間トリガタイマを開始したかを示す情報をログ記録するステップ、もしあれば、いずれのイベントがイベントの開始条件を実現し、時間トリガタイマを開始し、イベントの時間トリガタイマが満了したかを示す情報をログ記録するステップ、前記マルチイベント条件付きハンドオーバ実行の実行条件が実現したか否かを示す情報をログ記録するステップ、既に満了した時間トリガタイマを有する第1のイベントが、前記第2のイベントの時間トリガタイマが満了したときに前記第1のイベントの終了条件を実現するか否かを示す情報をログ記録するステップ、もしあれば、いずれのイベントが自身の時間トリガタイマを開始し、前記イベントについての前記時間トリガタイマが満了する前に停止されたかを示す情報をログ記録するステップ、もしあれば、各イベントが自身の時間トリガタイマを開始し、前記イベントについての時間トリガタイマが満了する前に停止された回数を示す情報をログ記録するステップ、第1イベントまたは第2イベントが最初に開始条件を実現するかどうかの情報をログ記録するステップ、時間トリガタイマのうちの1つが停止または満了したときに、前記第1イベントおよび前記第2イベントの時間トリガタイマの値をログ記録するステップ、前記第1イベントおよび前記第2イベントの時間トリガタイマが並行して動作していた時間または期間をログ記録するステップ、イベントの時間トリガタイマが起動された時刻を示す情報をログ記録するステップ、イベントに対する時間トリガタイマが満了した時間を示す情報をログ記録するステップ、イベントの時間トリガタイマが停止した時刻を示す情報をログ記録するステップ、第1イベントに対する時間トリガタイマが、第2イベントに対する時間トリガタイマと並行して動作していた時間を示す情報をログ記録するステップ、もしあれば、いずれのイベントがイベントの開始条件を実現し、最初に時間トリガタイマを開始したかを示す情報をログ記録するステップ、もしあれば、いずれのイベントが時間トリガタイマを最初に満了したかを示す情報をログ記録するステップ、もしあれば、どのイベントが前記イベントの開始条件を実現し、時間トリガタイマを開始し、次いで時間トリガタイマを最初に停止したかを示す情報をログ記録するステップ、または、複数イベントが前記マルチイベント条件付きハンドオーバ実行の実行条件を実現しないことによる前記ユーザデバイスの条件付きハンドオーバの障害の回数をカウントする障害カウンタをログ記録するステップ、のうちの少なくとも1つを含む、例1-22のいずれかの方法。
【0134】
[例24]
少なくとも第1のイベントの構成および第2イベントの構成を含むマルチイベントのそれぞれの構成と、条件付きハンドオーバ実行を行うかどうかを判定するために前記ユーザデバイスによるマルチイベントの共同評価を構成する共同評価構成を含む、条件付きハンドオーバの一部として、前記ユーザデバイスによってネットワークノードから、ハンドオーバコマンドを受信することをさらに含む、例1から例23のいずれかの方法。
【0135】
[例25]
ソースネットワークノードからターゲットネットワークノードへの前記ユーザデバイスの条件付きハンドオーバ実行を行うかどうかを判定するために、ユーザデバイスによって複数のイベントを共同で評価するステップをさらに含む、例1-24のいずれかの方法。
【0136】
[例26]
例1から例25のいずれかの方法を実行する手段を含む装置。
【0137】
[例27]
少なくとも1つのプロセッサによって実行されたときに、コンピューティングシステムに例1から25のいずれか1項に記載の方法を実行させるように構成された命令が格納された非一時的なコンピュータ可読記憶媒体。
【0138】
[例28]
少なくとも1つのプロセッサと、コンピュータプログラムコードを含む少なくとも1つのメモリとを含む装置であって、前記少なくとも1つのメモリおよび前記コンピュータプログラムコードは、前記少なくとも1つのプロセッサとともに、前記装置に、例1-25の方法を少なくとも行わせるように構成された装置。
【0139】
[例29]
少なくとも1つのプロセッサと、コンピュータプログラムコードを含む少なくとも1つのメモリとを含む装置であって、前記少なくとも1つのメモリおよび前記コンピュータプログラムコードは、前記少なくとも1つのプロセッサとともに、無線ネットワーク内のユーザデバイスが、マルチイベント条件付きハンドオーバ実行に関連する情報をログ記録するステップであって、前記マルチイベント条件付きハンドオーバ実行は、前記ユーザデバイスによるマルチイベントの共同評価に基づいているログ記録するステップと、前記ユーザデバイスが、情報の少なくとも一部を含むレポートを送信するステップとを、前記装置に実行させる、装置。
【0140】
[例30]
ユーザデバイスによる条件付きハンドオーバ実行のために共同で評価されるマルチイベントの構成を含む共同イベント構成情報を持つハンドオーバコマンドを、ネットワークノードによって前記ユーザデバイスに送信するステップと、前記ユーザデバイスによるマルチイベント条件付きハンドオーバ実行の障害に関する前記ユーザデバイスによって記録された情報を含むレポートを前記ネットワークノードによって受信するステップであって、前記マルチイベント条件付きハンドオーバ実行が複数のイベントに基づいているステップと、前記レポートに基づいて前記ネットワークノードによって、マルチイベント条件付きハンドオーバ実行のための一つ以上のイベントの構成に関連付けられた一つ以上のパラメータを変更するステップとを含む、方法。
【0141】
[例31]
前記共同イベント構成情報は、条件付きハンドオーバ実行を行うかどうかを判定するために、前記ユーザデバイスによるマルチイベントの共同評価を構成する共同評価構成を含む、例30の方法。
【0142】
[例32]
前記マルチイベント条件付きハンドオーバ実行が、2つのイベントに基づくデュアルイベント条件付きハンドオーバ実行を含む、例30または31の方法。
【0143】
[例33]
前記マルチイベント条件付きハンドオーバ実行は複数のイベントに基づいており、前記ユーザデバイスによってログ記録される情報には、前記複数のイベントのうち1つ以上のイベント関連条件の発生、イベント関連条件の発生回数、イベント関連条件の発生時刻や発生タイミングの内の少なくとも1つを含む、例30-32のいずれかの方法。
【0144】
[例34]
イベント関連条件は、開始されていない、開始された、開始後に停止された、または、満了したいずれかのステータスを含むイベントの時間トリガタイマのステータス、前記イベントの開始条件を実現するイベント、前記イベントの終了条件を実現するイベント、前記ユーザデバイスのハンドオーバ障害の発生、または前記マルチイベント条件付きハンドオーバ実行の実行条件が実現されているか否か、のうちの少なくとも1つを含む、例33の方法。
【0145】
[例35]
前記マルチイベント条件付きハンドオーバ実行は複数のイベントに基づいており、前記ユーザデバイスによってログ記録される前記情報は、前記複数のイベントのうちの1つ以上についてイベント関連条件が発生したかどうかを示す情報、複数のイベントのうちの1つ以上についてイベント関連条件が発生した回数を示す情報、複数のイベントのうちの少なくとも2つのイベントのイベント関連条件の時間関係またはそれらの間の時間差、複数のイベントのうちの1つ以上についてイベント関連条件が発生した時間を示す情報、どのイベントについてイベント関連条件が最初に発生したかを示す情報、または、前記複数のイベントが前記マルチイベント条件付きハンドオーバ実行の実行条件を実現しないことにより、前記ユーザデバイスに対するハンドオーバの障害の回数、のうちの少なくとも1つを含む、例30-34のいずれかの方法。
【0146】
[例36]
前記マルチイベント条件付きハンドオーバ実行は少なくとも第1イベントおよび第2イベントを含む複数のイベントに基づいており、前記ユーザデバイスによってログ記録される前記情報は、第1イベントの構成および/または第2イベントの構成、もしあれば、いずれのイベントがイベントの開始条件を実現し、時間トリガタイマを開始したかを示す情報、もしあれば、いずれのイベントがイベントの開始条件を実現し、時間トリガタイマを開始し、イベントの時間トリガタイマが満了したかを示す情報、前記マルチイベント条件付きハンドオーバ実行の実行条件が実現したか否かを示す情報、既に満了した時間トリガタイマを有する第1のイベントが、前記第2のイベントの時間トリガタイマが満了したときに前記第1のイベントの終了条件を実現するか否かを示す情報、もしあれば、いずれのイベントが自身の時間トリガタイマを開始し、前記イベントについての前記時間トリガタイマが満了する前に停止されたかを示す情報、もしあれば、各イベントが自身の時間トリガタイマを開始し、前記イベントについての時間トリガタイマが満了する前に停止された回数を示す情報、第1イベントまたは第2イベントが最初に開始条件を実現するかどうかの情報、時間トリガタイマのうちの1つが停止または満了したときの、前記第1イベントおよび前記第2イベントの時間トリガタイマの値、前記第1イベントおよび前記第2イベントの時間トリガタイマが並行して動作していた時間または期間、イベントの時間トリガタイマが開始された時刻を示す情報、イベントに対する時間トリガタイマが満了した時間を示す情報、イベントの時間トリガタイマが停止した時刻を示す情報、第1イベントに対する時間トリガタイマが、第2イベントに対する時間トリガタイマと並行して動作していた時間を示す情報、もしあれば、いずれのイベントがイベントの開始条件を実現し、最初に時間トリガタイマを開始したかを示す情報、もしあれば、いずれのイベントが時間トリガタイマを最初に満了したかを示す情報、もしあれば、いずれのイベントが前記イベントの開始条件を実現し、時間トリガタイマを開始し、次いで時間トリガタイマを最初に停止したかを示す情報、または、複数イベントが前記マルチイベント条件付きハンドオーバ実行の実行条件を実現しないことによる前記ユーザデバイスの条件付きハンドオーバの障害の回数をカウントする障害カウンタ、のうちの少なくとも1つを含む、例30-35のいずれかの方法。
【0147】
[例37]
例30-36のいずれかの方法を実行する手段を含む装置。
【0148】
[例38]
少なくとも1つのプロセッサによって実行されたときに、コンピューティングシステムに例30-36のいずれかの方法を実行させるように構成された命令が格納された非一時的なコンピュータ可読記憶媒体。
【0149】
[例39]
少なくとも1つのプロセッサと、コンピュータプログラムコードを含む少なくとも1つのメモリとを含む装置であって、前記少なくとも1つのメモリおよび前記コンピュータプログラムコードは、前記少なくとも1つのプロセッサとともに、前記装置に、少なくとも例30-36のいずれかの方法を装置に実行させるように構成された装置。
【0150】
図6は、一実施例による無線ステーションまたはノード(例:AP、BS、gNB、eNB、中継ノードまたはその他のネットワークノード、ユーザデバイス/UE、またはその他のノード)1100のブロック図である。無線ステーション1100は、例えば、一つ以上の(例えば、図6に示すように2つの)RF(無線周波数)または無線トランシーバ1102A、1102Bを含み、各無線トランシーバは、信号を送信するための送信機と信号を受信するための受信機を含む。無線ステーションはまた、命令またはソフトウェアを実行し、信号の送受信を制御するプロセッサまたは制御ユニット/エンティティ(コントローラ)1104と、データおよび/または命令を格納するメモリ1106を含む。
【0151】
プロセッサ1104は、決定または判定を行い、送信のためのフレーム、パケットまたはメッセージを生成し、受信したフレームまたはメッセージをさらに処理するためにデコードし、およびここに記載されているその他のタスクまたは機能を実行することもできる。たとえば、ベースバンドプロセッサであるプロセッサ1104は、無線トランシーバ1102(1102Aまたは1102B)を介して送信するためのメッセージ、パケット、フレームまたはその他の信号を生成することができる。プロセッサ1104は、無線ネットワークを介した信号またはメッセージの送信を制御することができ、無線ネットワークを介した信号またはメッセージの受信などを制御することができる(たとえば、無線トランシーバ1102によってダウンコンバートされた後など)。プロセッサ1104は、プログラム可能であり、メモリまたは他のコンピュータメディアに保存されているソフトウェアまたは他の命令を実行して、上記のさまざまなタスクや機能を実行することができる場合がある。プロセッサ1104は、たとえば、ハードウェア、プログラム可能なロジック、ソフトウェアまたはファームウェアを実行するプログラム可能なプロセッサ、および/またはこれらの任意の組み合わせである場合がある(または含む場合がある)。
他の用語を使用すると、プロセッサ1104とトランシーバ1102を一緒にして、たとえば無線送受信システムと見なすことができる。
【0152】
さらに、図6を参照すると、コントローラ(またはプロセッサ)1108は、ソフトウェアと命令を実行し、ステーション1100の全体的な制御を提供することができ、入力/出力デバイス(例:ディスプレイ、キーパッド)の制御など、図6に示されていない他のシステムの制御を提供することができ、および/または、たとえば、電子メールプログラム、オーディオ/ビデオアプリケーション、ワードプロセッサ、Voice over IPアプリケーション、またはその他のアプリケーションやソフトウェアなど、無線ステーション1100で提供される可能性のある1つ以上のアプリケーションのソフトウェアを実行することができる。
【0153】
さらに、記憶された命令を含む記憶媒体が提供されることがあり、コントローラまたはプロセッサによって実行されると、プロセッサ1104、またはその他のコントローラまたはプロセッサが、上記の機能またはタスクの1つ以上を実行することになる場合がある。
【0154】
別の例の実施形態によると、RFまたは無線トランシーバ1102A/1102Bは、信号またはデータを受信したり、信号またはデータを送信または送信したりすることができる。プロセッサ1104(およびトランシーバ1102A/1102B)は、RFまたは無線トランシーバ1102Aまたは1102Bを制御して、信号またはデータを受信、送信、ブロードキャスト、または送信することができる。
【0155】
ただし、例示の実施形態は、例として示されているシステムに限定されるものではなく、当業者はこのソリューションを他の通信システムに適用することができる。適切な通信システムの別の例は、5Gシステムである。5Gのネットワークアーキテクチャは、LTE-Advancedのものとかなり似ていると想定されている。5Gは、マルチインプット-マルチアウトプット(MIMO)アンテナを使用する可能性が高く、LTEよりもはるかに多くの基地局またはノード(いわゆるスモールセルの概念)を使用する。これには、小規模な局と協力して動作するマクロサイトや、おそらくカバレッジと拡張型データレートのためにさまざまな無線技術を採用することも含まれる。
【0156】
将来のネットワークでは、ネットワークノード機能を「ビルディングブロック」またはサービスを提供するために運用上接続またはリンクされる可能性のあるエンティティに仮想化することを提案するネットワークアーキテクチャの概念であるネットワーク機能仮想化(NFV)がおそらく利用されることを認識する必要がある。仮想化ネットワーク機能(VNF)は、カスタマイズされたハードウェアの代わりに、標準または一般的なタイプのサーバを使用してコンピュータプログラムコードを実行する1つ以上の仮想マシンで構成される場合がある。クラウドコンピューティングやデータストレージを利用することもできる。無線通信では、これはノード操作が、少なくとも部分的に、リモートの無線ヘッドに操作的に結合されたサーバ、ホスト、またはノードで実行されることを意味する場合がある。また、ノード操作が複数のサーバ、ノード、またはホストに分散される可能性もある。また、コアネットワーク運用と基地局運用との間の労働力の配分がLTEと異なる場合や、存在しない場合があることも理解しておく必要がある。
【0157】
ここに記載されている様々な技術の実施例は、デジタル電子回路、またはコンピュータハードウェア、ファームウェア、ソフトウェア、またはそれらの組み合わせで実装することができる。実施例は、コンピュータプログラム製品として、すなわち、データ処理装置、例えばプログラマブルプロセッサ、コンピュータ、または複数のコンピュータによって実行またはその動作を制御するために、情報キャリア、例えば機械可読記憶装置または伝播された信号に有形的に具現化されたコンピュータプログラムとして実装することができる。また、実施例は、コンピュータ可読媒体またはコンピュータ可読記憶媒体で提供されることもあり、これは非遷移媒体であってもよい。様々な技術の実施例は、遷移信号または媒体を介して提供される実施例、および/またはインターネットまたは他のネットワーク(有線ネットワークおよび/または無線ネットワーク)を介してダウンロード可能なプログラムおよび/またはソフトウェアの実施例を含むこともできる。さらに、実施例は、マシンタイプ通信(MTC)を介して提供される場合もあれば、モノのインターネット(IOT)を介して提供される場合もある。
【0158】
コンピュータプログラムは、ソースコード形式、オブジェクトコード形式、または何らかの中間形式であってもよく、プログラムを運ぶことができる任意の実体または装置である、何らかのキャリア、配布媒体、またはコンピュータ可読媒体に格納される場合もある。このようなキャリアには、例えば、記録媒体、コンピュータメモリ、読み取り専用メモリ、光電気および/または電気キャリア信号、電気通信信号、およびソフトウェア配布パッケージが含まれる。必要な処理能力に応じて、コンピュータプログラムは単一の電子デジタルコンピュータで実行される場合もあれば、複数のコンピュータに分散される場合もある。
【0159】
さらに、ここに記載されている様々な技術の例示的な実施形態は、サイバーフィジカルシステム(CPS)(物理的実体を制御する共同計算要素のシステム)を使用することができる。CPSは、異なる場所にある物理的オブジェクトに埋め込まれた大量の相互接続されたICTデバイス(センサ、アクチュエータ、プロセッサマイクロコントローラ、...)の具体化と活用を可能にするかもしれない。問題の物理システムが固有の移動性を持つモバイルサイバーフィジカルシステムは、サイバーフィジカルシステムのサブカテゴリである。モバイル物理システムの例としては、人間や動物によって輸送されるモバイルロボティクスや電子機器などがある。スマートフォンの人気の高まりにより、モバイルのサイバーフィジカルシステムの分野への関心が高まっている。したがって、ここで説明する技術のさまざまな実施形態は、これらの技術の1つ以上を介して提供される可能性がある。
【0160】
上記のコンピュータプログラムのようなコンピュータプログラムは、コンパイル言語またはインタプリタ言語を含む任意の形式のプログラミング言語で記述することができ、スタンドアロンプログラムとして、またはコンピューティング環境での使用に適したモジュール、コンポーネント、サブルーチン、またはその他のユニットまたはその一部としてなど、任意の形式で展開することができる。コンピュータプログラムは、1つのコンピュータまたは1つのサイトの複数のコンピュータで実行されるように展開することも、複数のサイトに分散して通信ネットワークで相互接続されるように展開することもできる。
【0161】
方法ステップは、入力データを操作して出力を生成することによって機能を実行するために、コンピュータプログラムまたはコンピュータプログラムの部分を実行する1つ以上のプログラム可能なプロセッサによって実行される場合がある。方法ステップは、FPGA(フィールドプログラマブルゲートアレイ)またはASIC(特定用途向け集積回路)などの特殊な目的の論理回路によって実行される場合もあり、装置はとして実装される場合もある。
【0162】
コンピュータプログラムの実行に適したプロセッサには、例として、汎用と特殊目的の両方のマイクロプロセッサ、および任意の種類のデジタルコンピュータ、チップまたはチップセットの任意の1つ以上のプロセッサが含まれる。一般に、プロセッサは、読み取り専用メモリまたはランダムアクセスメモリ、またはその両方から命令とデータを受け取る。コンピュータの要素には、命令を実行するための少なくとも1つのプロセッサと、命令とデータを格納するための1つ以上のメモリデバイスを含めることができる。一般的に、コンピュータは、データを格納するための1つ以上の大容量記憶装置(例えば、磁気ディスク、光磁気ディスク、光ディスク)を含むか、またはそれらの両方からデータを受信したりデータを転送したりするために動作的に結合されることもある。コンピュータプログラム命令およびデータを具現化するのに適した情報キャリアは、例として、例えば、EPROM、EEPROM、およびフラッシュメモリデバイスを含む、すべての形態の不揮発性メモリを含む半導体メモリデバイス、内蔵ハードディスクまたはリムーバブルディスクなどの磁気ディスク、光磁気ディスク、およびCD-ROMおよびDVD-ROMディスクを含む。プロセッサとメモリは、特殊な目的の論理回路によって補完されたり、組み込まれたりすることがある。
【0163】
ユーザとの対話を提供するために、ユーザに情報を表示するための、例えばブラウン管(CRT)や液晶ディスプレイ(LCD)モニターなどの表示装置と、ユーザがコンピュータに入力を提供できるキーボードやポインティングデバイス(例えばマウスやトラックボール)などのユーザーインターフェイスを備えたコンピュータ上に実施することができる。他の種類のデバイスを使用して、同様にユーザとの対話を提供することができる。たとえば、ユーザに提供されるフィードバックは、視覚フィードバック、聴覚フィードバック、触覚フィードバックなど、任意の形式の感覚フィードバックである可能性がある。また、ユーザからの入力は、音響、音声、触覚入力など、任意の形式で受け取ることができる。
【0164】
例の実施形態は、例えばデータサーバとしてのバックエンドコンポーネントを含む、またはアプリケーションサーバのようなミドルウェアコンポーネントを含む、またはフロントエンドコンポーネントを含む、例えば、グラフィカルユーザーインターフェイスまたはユーザが実施形態と対話できるWebブラウザを持つクライアントコンピュータ、またはそのようなバックエンド、ミドルウェア、またはフロントエンドコンポーネントの任意の組み合わせで実装することができる。コンポーネントは、例えば通信ネットワークのような任意の形式またはデジタルデータ通信の媒体によって相互接続することができる。
通信ネットワークの例としては、ローカルエリアネットワーク(LAN)やワイドエリアネットワーク(WAN)、例えばインターネットなどがある。
【0165】
ここに記載されているように、記載されている実施形態の特定の特徴が説明されているが、多くの変更、置換、変更および同等のものが当業者に生じることになるため、添付のクレームは、様々な実施形態の真の精神の範囲内にあるようなすべての変更および変更をカバーすることを意図していると理解される。
図1
図2
図3
図4
図5
図6