(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】特表2015-537458(P2015-537458A)
(43)【公表日】2015年12月24日
(54)【発明の名称】RAT相互間のモビリティ設定を協調するための方法
(51)【国際特許分類】
H04W 36/14 20090101AFI20151201BHJP
H04W 92/24 20090101ALI20151201BHJP
H04W 36/38 20090101ALI20151201BHJP
【FI】
H04W36/14
H04W92/24
H04W36/38
【審査請求】有
【予備審査請求】未請求
【全頁数】40
(21)【出願番号】特願2015-540254(P2015-540254)
(86)(22)【出願日】2013年11月1日
(85)【翻訳文提出日】2015年6月29日
(86)【国際出願番号】IB2013059844
(87)【国際公開番号】WO2014068525
(87)【国際公開日】20140508
(31)【優先権主張番号】61/721,586
(32)【優先日】2012年11月2日
(33)【優先権主張国】US
(81)【指定国】
AP(BW,GH,GM,KE,LR,LS,MW,MZ,NA,RW,SD,SL,SZ,TZ,UG,ZM,ZW),EA(AM,AZ,BY,KG,KZ,RU,TJ,TM),EP(AL,AT,BE,BG,CH,CY,CZ,DE,DK,EE,ES,FI,FR,GB,GR,HR,HU,IE,IS,IT,LT,LU,LV,MC,MK,MT,NL,NO,PL,PT,RO,RS,SE,SI,SK,SM,TR),OA(BF,BJ,CF,CG,CI,CM,GA,GN,GQ,GW,KM,ML,MR,NE,SN,TD,TG),AE,AG,AL,AM,AO,AT,AU,AZ,BA,BB,BG,BH,BN,BR,BW,BY,BZ,CA,CH,CL,CN,CO,CR,CU,CZ,DE,DK,DM,DO,DZ,EC,EE,EG,ES,FI,GB,GD,GE,GH,GM,GT,HN,HR,HU,ID,IL,IN,IR,IS,JP,KE,KG,KN,KP,KR,KZ,LA,LC,LK,LR,LS,LT,LU,LY,MA,MD,ME,MG,MK,MN,MW,MX,MY,MZ,NA,NG,NI,NO,NZ,OM,PA,PE,PG,PH,PL,PT,QA,RO,RS,RU,RW,SA,SC,SD,SE,SG,SK,SL,SM,ST,SV,SY,TH,TJ,TM,TN,TR,TT,TZ,UA,UG,US
【公序良俗違反の表示】
(特許庁注:以下のものは登録商標)
1.GSM
(71)【出願人】
【識別番号】598036300
【氏名又は名称】テレフオンアクチーボラゲット エル エム エリクソン(パブル)
(74)【代理人】
【識別番号】100109726
【弁理士】
【氏名又は名称】園田 吉隆
(74)【代理人】
【識別番号】100161470
【弁理士】
【氏名又は名称】冨樫 義孝
(74)【代理人】
【識別番号】100194294
【弁理士】
【氏名又は名称】石岡 利康
(74)【代理人】
【識別番号】100194320
【弁理士】
【氏名又は名称】藤井 亮
(72)【発明者】
【氏名】ダ シルヴァ, イカロ エル.イェー.
(72)【発明者】
【氏名】セントンザ, アンジェロ
(72)【発明者】
【氏名】グンナルソン, フレデリック
【テーマコード(参考)】
5K067
【Fターム(参考)】
5K067DD36
5K067DD57
5K067EE10
5K067EE16
5K067HH22
5K067JJ39
(57)【要約】
ハンドオーバを協調するためのシステム、方法、および装置が提示されている。第1のRANセルと関連する第1のコントローラ(105)が、第1のRANセルから異なるRATを有する第2のRANセルへのハンドオーバを生じさせるべきかどうかを判断するときに用いられるための第1のハンドオーバパラメータ値を決定する(702)。第1のコントローラ(105)は、第2のRANセルと関連する第2のコントローラ(112)へ、第1のハンドオーバパラメータ値に関する情報を送信する(702)。第1のコントローラは、更に第2のコントローラへ、情報と関連するQoSパラメータまたはUE性能パラメータの値を通知する(704)。第1のコントローラは、第2のコントローラから、第2のコントローラが、送信された情報に基づいて第2のハンドオーバパラメータ値を調節したかどうかに関する指標を受信する(704)。ここで、第2のハンドオーバパラメータ値は、第2のRANセルから第1のRANセルへのハンドオーバを生じさせるべきかどうかを判断するときに用いるためのものである。
【選択図】図1
【特許請求の範囲】
【請求項1】
ハンドオーバを協調する方法(700)であって、
第1の無線アクセスネットワーク(RAN)セルと関連する第1のコントローラ(105)において、前記第1のRANセルから前記第1のRANセルとは異なる無線アクセス技術(RAT)を有する第2のRANセルへのハンドオーバを生じさせるべきかどうかを判断するときに用いるための第1のハンドオーバパラメータ値を決定する(702)ことと、
前記第1のコントローラ(105)から前記第2のRANセルと関連する第2のコントローラ(112)へ、前記第1のハンドオーバパラメータ値に関する情報を送信する(702)ことと、
前記第1のコントローラ(105)から前記第2のコントローラ(112)へ、前記情報と関連するサービス品質(QoS)パラメータまたはユーザ機器(UE)性能パラメータの値を通知する(704)ことであって、前記QoSパラメータは前記第1のRANセルまたは前記第2のRANセルによってサービスを受けているユーザ機器(UE)に提供されるか提供されると予想されるサービスのレベルを示し、前記UE性能パラメータはUE性能を示す、通知する(704)ことと、
前記第2のRANセルから前記第1のRANセルへのハンドオーバを生じさせるべきかどうかを判断するときに用いるための第2のハンドオーバパラメータ値を、前記第2のコントローラ(112)が前記送信された情報に基づいて調節したかどうかに関する指標を前記第2のコントローラ(112)から受信する(706)ことと
を含む方法(700)。
【請求項2】
前記第1のハンドオーバパラメータ値は第1のハンドオーバ閾値であり、前記第2のハンドオーバパラメータ値は第2のハンドオーバ閾値であって、第1の計算値が前記第1のハンドオーバ閾値を超えるときに、前記第1のRANセルから前記第2のRANセルへのハンドオーバが生じ、第2の計算値が前記第2のハンドオーバ閾値を超えるときに、前記第1のRANセルから前記第2のRANセルへのハンドオーバが生じる、請求項1に記載の方法。
【請求項3】
前記第1のハンドオーバ閾値に基づいて前記第1のコントローラ(105)によって前記第2のハンドオーバ閾値の調節値を決定する(802)ことを更に含み、
前記送信された情報(804)は、前記第2のハンドオーバ閾値の調節値を含み、
前記受信された指標(805)は、前記第2のコントローラ(112)が前記第2のハンドオーバ閾値の調節値を受け入れるかどうかに関する指標を含む、請求項2に記載の方法。
【請求項4】
前記第2のコントローラ(112)が前記第2のハンドオーバ閾値の調節値を受け入れないという指標の受信に応答して、前記第1のハンドオーバ閾値のために別の値を決定する(808)ことを更に含む、請求項3に記載の方法。
【請求項5】
前記送信された情報は、前記第1のハンドオーバ閾値を含み、前記受信された指標(905)は、前記第1のハンドオーバ閾値に基づき前記第2のコントローラ(112)が前記第2のハンドオーバ閾値への調節を行ったかどうかに関する指標を含む、請求項2に記載の方法。
【請求項6】
前記第1のハンドオーバ閾値に基づき前記第2のコントローラ(112)が前記第2のハンドオーバ閾値への調節を行っていないという指標の受信に応答して、前記第1のハンドオーバ閾値のために別の値を決定する(908)ことを更に含む、請求項5に記載の方法。
【請求項7】
前記送信するステップはRAN情報管理(RIM)メッセージを送信することを含み、前記RIMメッセージは、前記第1のハンドオーバパラメータ値に関する情報と、前記情報と関連する前記QoSパラメータもしくはUE性能パラメータのIDと、前記情報と関連する前記QoSパラメータもしくはUE性能パラメータの値とを含む、請求項1ないし6のいずれか一項に記載の方法。
【請求項8】
前記第2のコントローラは前記RIMメッセージが送信される複数のRANセルの複数のコントローラの中の1つであり、前記第2のRANセルを示すセルIDまたはセルグループIDを前記RIMメッセージの一部として送信することを更に含む、請求項1ないし7のいずれか一項に記載の方法。
【請求項9】
前記QoSパラメータは前記UEに対するデータの信号ベアラと関連しており、前記QoSパラメータは、前記信号ベアラのQoSクラスインジケータ(QCI)と、前記信号ベアラの割り当ておよび保持優先順位(ARP)と、前記信号ベアラが保証ビットレート(GBR)を有するかどうかに関する指標と、前記信号ベアラがリアルタイムデータを搬送しているかどうかに関する指標との中の少なくとも1つを含む、請求項1ないし8のいずれか一項に記載の方法。
【請求項10】
前記UE性能パラメータは、UEカテゴリと、UE無線リソース管理(RRM)コンフィギュレーションと、前記UEの加入タイプと、前記UEの速度との中の少なくとも1つを含む、請求項1ないし9のいずれか一項に記載の方法。
【請求項11】
前記第1のコントローラ(105)から前記第2のコントローラ(112)へ、ハンドオーバを決定するときに前記第2のコントローラ(112)が用いる1つもしくは複数のQoSパラメータ値または1つもしくは複数のUE性能パラメータ値に対する要求を送信する(1002)ことと、
前記1つもしくは複数のQoSパラメータ値または1つもしくは複数のUE性能パラメータ値を受信する(1004)ことと、
前記第1のコントローラ(105)において、前記1つもしくは複数のQoSパラメータ値または1つもしくは複数のUE性能パラメータ値に基づき、前記第2のハンドオーバパラメータ値の調節値を決定する(1006)ことと
を更に含んでおり、
前記送信された情報は、前記第2のパラメータ値への調節値を含み、
前記QoSパラメータ値またはUE性能パラメータ値の通知された値(1008)は前記1つまたは複数の受信された値の中の1つである、請求項1に記載の方法。
【請求項12】
前記第1のコントローラ(105)から前記第2のコントローラ(112)へ、ハンドオーバを決定するときに前記第1のコントローラ(105)が用いる1つもしくは複数のQoSパラメータ値または1つもしくは複数のUE性能パラメータ値を通知する(1102)ことと、
前記第2のコントローラ(112)から、ハンドオーバを決定するときに前記第2のコントローラ(112)が用いる1つもしくは複数のQoSパラメータ値または1つもしくは複数のUE性能パラメータ値に対する要求を受信する(1104)ことと、
を更に含む、請求項1に記載の方法。
【請求項13】
前記第1のコントローラ(105)において、ハンドオーバを決定するときに前記第1のコントローラ(105)が用いる前記1つもしくは複数のQoSパラメータ値または1つもしくは複数のUE性能パラメータ値を変更する(1106)ことと、
前記変更を前記第2のコントローラ(112)に通知する(1108)ことと、
を更に含む、請求項12に記載の方法。
【請求項14】
前記第1のコントローラ(105)において、ハンドオーバを決定するときに前記第1のコントローラ(105)がQoSパラメータまたはUE性能パラメータのどちらを用いるかを変更する(1106)ことと、
前記変更を前記第2のコントローラ(112)に通知する(1108)ことと、
を更に含む、請求項12に記載の方法。
【請求項15】
第1の無線アクセスネットワーク(RAN)セルと関連しており、第2のRANセルと関連する第2のコントローラとのハンドオーバを協調するための第1のコントローラ(105)であって、
前記第1のRANセルから前記第1のRANセルとは異なる無線アクセス技術(RAT)を有する前記第2のRANセルへのハンドオーバを生じさせるべきかどうかを決定するときに用いるための第1のハンドオーバパラメータ値を決定し(702)、
前記第1のコントローラ(105)から前記第2のコントローラ(112)へ、前記第1のハンドオーバパラメータ値に関する情報を送信し(702)、
前記第1のコントローラ(105)から前記第2のコントローラ(112)へ、前記情報と関連するサービス品質(QoS)パラメータまたはユーザ機器(UE)性能パラメータの値を通知し(704)、ここで、前記QoSパラメータは前記第1のRANセルまたは前記第2のRANセルによってサービスを受けているユーザ機器(UE)に提供されるか提供されると予想されるサービスのレベルを示し、前記UE性能パラメータはUE性能を示しており、
前記第2のRANセルから前記第1のRANセルへのハンドオーバを生じさせるべきかどうかを判断するときに用いるための第2のハンドオーバパラメータ値を、前記第2のコントローラが前記送信された情報に基づいて調節したかどうかに関する指標を前記第2のコントローラ(112)から受信する(706)ように構成されている1つまたは複数の処理ユニットを備えている、第1のコントローラ(105)。
【請求項16】
前記第1のハンドオーバパラメータ値は第1のハンドオーバ閾値であり、前記第2のハンドオーバパラメータ値は第2のハンドオーバ閾値であって、第1の計算値が前記第1のハンドオーバ閾値を超えるときに、前記第1のRANセルから前記第2のRANセルへのハンドオーバが生じ、第2の計算値が前記第2のハンドオーバ閾値を超えるときに、前記第1のRANセルから前記第2のRANセルへのハンドオーバが生じる、請求項15に記載のコントローラ(105)。
【請求項17】
前記1つまたは複数の処理ユニットは、更に、前記第1のハンドオーバ閾値に基づいて前記第2のハンドオーバ閾値の調節値を決定する(802)ように構成されており、
前記送信された情報(804)は、前記第2のハンドオーバ閾値の調節値を含み、
前記受信された指標(805)は、前記第2のコントローラが前記第2のハンドオーバ閾値の調節値を受け入れるかどうかに関する指標を含む、請求項16に記載のコントローラ(105)。
【請求項18】
前記1つまたは複数のプロセッサは、更に、
前記第2のコントローラが前記第2のハンドオーバ閾値の調節値を受け入れないという指標の受信に応答して、前記第1のハンドオーバ閾値のために別の値を決定する(808)ように構成されている、請求項17に記載のコントローラ(105)。
【請求項19】
前記送信された情報は、前記第1のハンドオーバ閾値を含み、前記受信された指標(905)は、前記第1のハンドオーバ閾値に基づき前記第2のコントローラが前記第2のハンドオーバ閾値への調節を行ったかどうかに関する指標を含む、請求項16に記載のコントローラ(105)。
【請求項20】
前記1つまたは複数の処理ユニットは、更に、前記第1のハンドオーバ閾値に基づき前記第2のコントローラが前記第2のハンドオーバ閾値への調節を行っていないという指標の受信に応答して、前記第1のハンドオーバ閾値のために別の値を決定する(908)ように構成されている、請求項19に記載のコントローラ(105)。
【請求項21】
前記1つまたは複数の処理ユニットは、前記第1のハンドオーバパラメータ値と、前記QoSパラメータまたはUE性能パラメータの値とに関する情報を、RAN情報管理(RIM)メッセージに含めて送信するように構成されている、請求項15ないし20のいずれか一項に記載のコントローラ(105)。
【請求項22】
前記第2のコントローラは前記RIMメッセージが送信される複数のRANセルの複数のコントローラの中の1つであり、前記1つまたは複数の処理ユニットは、更に、前記第2のRANセルを識別するセルIDまたはセルグループIDを前記RIMメッセージの一部として送信するように構成されている、請求項15ないし21のいずれか一項に記載のコントローラ(105)。
【請求項23】
前記QoSパラメータは前記UEに対するデータの信号ベアラと関連しており、前記QoSパラメータは、前記信号ベアラのQoSクラスインジケータ(QCI)と、前記信号ベアラの割り当ておよび保持優先順位(ARP)と、前記信号ベアラが保証ビットレート(GBR)を有するかどうかに関する指標と、前記信号ベアラがリアルタイムデータを搬送しているかどうかに関する指標との中の少なくとも1つを含む、請求項15ないし22のいずれか一項に記載のコントローラ(105)。
【請求項24】
前記UE性能パラメータは、UEカテゴリと、UE無線リソース管理(RRM)コンフィギュレーションと、前記UEの加入タイプと、前記UEの速度との中の少なくとも1つを含む、請求項15ないし23のいずれか一項に記載のコントローラ(105)。
【請求項25】
前記1つまたは複数の処理ユニットは、更に、
前記第1のコントローラ(105)から前記第2のコントローラ(112)へ、ハンドオーバを決定するときに前記第2のコントローラが用いる1つもしくは複数のQoSパラメータ値または1つもしくは複数のUE性能パラメータ値に対する要求を送信し(1002)、
前記1つもしくは複数のQoSパラメータ値または1つもしくは複数のUE性能パラメータ値を受信し(1004)、
前記第1のコントローラ(105)において、前記1つもしくは複数のQoSパラメータ値または1つもしくは複数のUE性能パラメータ値に基づき、前記第2のハンドオーバパラメータ値の調節値を決定する(1006)ように構成されており、
前記送信された情報は、前記第2のパラメータ値への調節値を含み、
前記QoSパラメータまたはUE性能パラメータの通知された値は前記1つまたは複数の受信された値の中の1つである、請求項15に記載のコントローラ(105)。
【請求項26】
前記1つまたは複数のプロセッサは、更に、
前記第1のコントローラ(105)から前記第2のコントローラ(112)へ、ハンドオーバを決定するときに前記第1のコントローラが用いる1つもしくは複数のQoSパラメータ値または1つもしくは複数のUE性能パラメータ値を通知し(1102)、
前記第1のコントローラ(105)から前記第2のコントローラ(112)に、ハンドオーバを決定するときに前記第2のコントローラ(112)が用いる1つもしくは複数のQoSパラメータ値または1つもしくは複数のUE性能パラメータ値に対する要求を受信する(1104)ように構成されている、請求項15に記載のコントローラ(105)。
【請求項27】
前記1つまたは複数のプロセッサは、更に、
前記第1のコントローラ(105)において、ハンドオーバを決定するときに前記第1のコントローラが用いる前記1つもしくは複数のQoSパラメータ値または1つもしくは複数のUE性能パラメータ値を変更し(1106)、
前記変更を前記第2のコントローラ(112)に通知する(1108)ように構成されている、請求項26に記載のコントローラ(105)。
【請求項28】
前記1つまたは複数の処理ユニットは、更に、
前記第1のコントローラ(105)において、ハンドオーバを決定するときに前記第1のコントローラ(105)がQoSパラメータまたはUE性能パラメータのどちらを用いるかを変更し(1106)、
前記変更を前記第2のコントローラ(112)に通知する(1108)ように構成されている、請求項26に記載のコントローラ(105)。
【発明の詳細な説明】
【技術分野】
【0001】
関連出願の相互参照
本出願は、2012年11月2日に出願され「Enhancements on Inter−RAT Mobility Setting Coordination」と題される米国特許仮出願第61/721,586号の優先権を主張する。
【0002】
RAT相互間でのモビリティ設定を協調するためのシステム、方法、装置、およびコンピュータプログラム製品
【背景技術】
【0003】
異なる無線アクセス技術(RAT)の間でのユーザ機器(UE)のモビリティは、あるRATを用いるセル(例えば、UTRAN)から別のRATを用いるセル(例えば、e−UTRAN)への、RAT相互間におけるハンドオーバによって達成され得る。ハンドオーバは、UEの現在のセルにおける参照信号またはターゲットセルにおける参照信号の品質が一定の条件を満たすイベントのようなモビリティイベントによって、トリガすることが可能である。
【0004】
e−UTRANの場合には、信号品質は、参照信号受信電力(RSRP)、参照信号受信品質(RSRQ)、およびいずれかの他の信号品質パラメータの中の1つまたは複数によって示され得る。UTRANの場合には、信号品質は、受信信号コード電力(RSCP)、受信信号強度インジケータ(RSSI)、EcNo(すなわち、RSCP/RSSI)およびいずれかの他の信号品質パラメータの中の1つまたは複数によって示され得る。
【0005】
e−UTRANセルからUTRANセルへのハンドオーバは、B2と称されるモビリティイベントが生じるときに、トリガされ得る。イベントB2は、信号品質が2つの条件B2−1およびB2−2を満たすときに生じる。すなわち、
条件B2−1は、Mp+Hys<Thresh1=B2_1であるときに、満たされる。
条件B2−2は、Mn+Ofn−Hys>Thresh2=B2_2であるときに、満たされる。
【0006】
M
pは、サービングセル(すなわち、e−UTRANセル)からの信号(例えば、参照信号)の測定値を指しており、RSRPの場合にはdBm単位で、RSRQの場合にはdB単位で表現され得る。M
nは、ターゲットセル(すなわち、UTRANセル)からの信号(例えば、参照信号)の測定値を指す。Hysは、ヒステリシスパラメータを指す。Ofnは、隣接セルの周波数の周波数固有オフセットである。
【0007】
これらの条件は、e−UTRANからUTRANへのハンドオーバは、e−UTRANセルにおける信号品質が閾値B2_1よりも悪くなり、かつ、UTRANセルにおける信号品質が閾値B2_2よりもよくなるとトリガされる、ということを示す。イベントB2は、TS 36.331において、より詳細に論じられている。e−UTRANからUTRANへのハンドオーバは、「B1」と名付けられたイベントによってもトリガされ得るのであるが、B1は、B1−bが満たされるときに、生じる。すなわち、
条件B1−bは、Mn+Ofn−Hys>Thresh=B1_bであるときに、満たされる。
【0008】
UTRANからe−UTRANへという他方の方向のハンドオーバは、「3A」と称されるモビリティイベントまたは「3C」と称されるモビリティイベントによって、トリガされ得る。イベント3Aは、2つの条件3A−1および3A−2が満たされるときに生じる。すなわち、
条件3A−1は、Q
Used+H3a/2<T
Used=3A_aであるときに、満たされる。
条件3A−2は、M
OtherRAT+CIO
OtherRAT−H3a/2>T
OtherRAT=3A_bであるときに、満たされる。
【0009】
これらのパラメータは、TS 25.331において、より詳細に論じられている。閾値3A_aは3A_1とも称され、閾値3A_bは3A_2とも称され得る。イベント3Cは、M
OtherRAT+CIO
OtherRAT≧T
OtherRAT+H
3c/2という単一の条件が満たされるときに、生じる。イベント3Aおよび3Cは、UTRANセルにおける信号品質が閾値3A_1よりも悪くなり、かつ、e−UTRANセルにおける信号品質が閾値3A_2よりもよくなる状況を一般的に表している。
【0010】
本開示では、閾値をトリガするものとしてイベントB1およびB2に言及しているが、より一般的には、これらのイベントは、ハンドオーバを生じさせるべきかどうかを決定するときに用いられるためのものである。すなわち、それぞれのイベントは、UEからそのUEのサービングセルの基地局への、信号測定の報告をトリガし得る。サービングセルのコントローラ(例えば、eNB、NB、またはRNC)は、サービングセルから別のセルへのハンドオーバを生じさせるべきかどうかを決定するために、この測定を用いることができる。
【発明の概要】
【0011】
異なる無線アクセス技術(RAT)の間でのハンドオーバのためなど、ハンドオーバの最適化を協調するための、システム、方法、および装置が提供される。ある実施形態では、第1の無線アクセスネットワーク(RAN)のコントローラ(「第1のコントローラ」)が、第1のRANセルから第1のRANセルとは異なる無線アクセス技術(RAT)を有する第2のRANセルへのハンドオーバを生じさせるべきかどうかを決定するときに用いるための第1のハンドオーバパラメータ値を決定する。
【0012】
第1のコントローラは、第2のRANセルのコントローラ(「第2のコントローラ」)に、第1のハンドオーバパラメータ値に関する情報を通知する。
【0013】
第1のコントローラは、更に、第2のコントローラへ、第1のハンドオーバパラメータ値に関する情報と関連するサービス品質(QoS)パラメータまたはユーザ機器(UE)性能パラメータの値を通知する。QoSパラメータとは、第1のRANセルまたは第2のRANセルによってサービスを受けているユーザ機器(UE)に提供されるか提供されると予想されるサービスのレベルを示す。UE性能パラメータとは、UE性能を示す。ある実施形態では、第1のハンドオーバパラメータ値に関する情報とQoSパラメータまたはUE性能パラメータの値とが、RAN情報管理(RIM)メッセージの一部として送られる。
【0014】
第1のコントローラは、通知された情報に基づいて第2のコントローラが第2のハンドオーバパラメータ値を調節したかどうかに関する指標を、第2のコントローラから受信する。第2のハンドオーバパラメータ値は、第2のRANセルから第1のRANセルへのハンドオーバを生じさせるべきかどうかを決定するときに用いるためのものである。
【0015】
ある実施形態では、第1のハンドオーバパラメータ値は、ハンドオーバ条件が満たされたかどうかを判断するために用いられる第1のハンドオーバ閾値であり、第2のハンドオーバパラメータ値は、ハンドオーバ条件が満たされたかどうかを判断するために用いられる第2のハンドオーバ閾値である。
【0016】
ある実施形態では、第1のコントローラは、第1のハンドオーバ閾値に基づき、第2のハンドオーバ閾値の調節値を決定する。この実施形態では、通知された情報は、第2のハンドオーバ閾値の調節値を含み、受信された指標は、第2のコントローラが第2のハンドオーバ閾値の調節値を受け入れるかどうかに関する指標を含む。
【0017】
ある実施形態では、通知された情報は、第1のハンドオーバ閾値を含み、受信された指標は、第1のハンドオーバ閾値に基づき第2のコントローラが第2のハンドオーバ閾値の調節を行ったかどうかに関する指標を含む。
【図面の簡単な説明】
【0018】
【図1】ハンドオーバを協調するためのシステムにおける複数のノードの図解である。
【図2A】ハンドオーバ閾値に関する信号ダイアグラムの図解である。
【図2B】ハンドオーバ閾値に関する信号ダイアグラムの図解である。
【図3A】ハンドオーバ閾値に関する信号ダイアグラムの図解である。
【図3B】ハンドオーバ閾値に関する信号ダイアグラムの図解である。
【図4】ハンドオーバ閾値に関する信号ダイアグラムの図解である。
【図5】UEデータを搬送するための様々な信号ベアラの図解である。
【図6A】ハンドオーバ閾値に関する信号ダイアグラムの図解である。
【図6B】ハンドオーバ閾値に関する信号ダイアグラムの図解である。
【図7】本開示の実施形態による流れ図の図解である。
【図8】本開示の実施形態による流れ図の図解である。
【図9】本開示の実施形態による流れ図の図解である。
【図10】本開示の実施形態による流れ図の図解である。
【図11】本開示の実施形態による流れ図の図解である。
【図12A】本開示の実施形態による信号ダイアグラムの図解である。
【図12B】本開示の実施形態による信号ダイアグラムの図解である。
【図13A】本開示の実施形態による信号ダイアグラムの図解である。
【図13B】本開示の実施形態による信号ダイアグラムの図解である。
【図14】本開示の実施形態による信号ダイアグラムの図解である。
【図15】本開示の実施形態による信号ダイアグラムの図解である。
【図16】本開示の実施形態による無線アクセスネットワーク(RAN)コントローラの図解である。
【図17】本開示の実施形態による無線アクセスネットワーク(RAN)コントローラの図解である。
【図18】本開示の実施形態によるUEの図解である。
【発明を実施するための形態】
【0019】
異なる無線アクセス技術(RAT)を有する無線アクセスネットワーク(RAN)の間における過剰な回数の双方向のハンドオーバを回避しながら、ハンドオーバを用いて無線リンク障害(RLF)を減少させることにより、モビリティのロバスト性を向上させることに関する。より詳しくは、異なるRATを有する2つ以上のRANの間で、モビリティ設定(例えば、ハンドオーバパラメータ)の調節を協調することを含む。より特定の例では、モビリティ負荷バランスシナリオにおける「ピンポン」回避を向上させることを扱う。
【0020】
図1は、基地局104によって提供されるセルと基地局106によって提供される別のセルとの間でのUE102のハンドオーバを協調するための例示的なシステム100を図解している。ある実施形態では、基地局104と基地局106とは、異なるRATを用いる。例えば、基地局104は、LTEのためにe−UTRANセルを提供するeNBであり、他方で、基地局106は、UMTSのためにUTRANセルを提供するNB、または、GSMのためにGERANセルを実装する基地局である。ハンドオーバは、基地局104のRANセルからの信号114(例えば、e−UTRAN参照信号)に関して、および/または、基地局106のRANセルからの信号116(例えば、UTRAN参照信号)に関して、UE102が行う測定に基づき得る。例えば、1つまたは複数の測定値が、一定の閾値を満たすなど、一定の条件を満たすときには、ハンドオーバイベントがトリガされ得る。ハンドオーバイベントは、UEに、そのサービングセル(serving cell)の基地局に測定を報告させる。その後、サービングセルのコントローラは、そのUEはサービング側のRANセルからターゲット側のRANセルにハンドオーバされるべきであると決めることができる。
【0021】
サービング側のRANセルからターゲット側のRANセルへのモビリティイベント(ハンドオーバイベント)をトリガする条件は、サービング側のRANセルによって設定され得る。例えば、コントローラ105は、基地局104によって提供されるRANセルから別のセルへのハンドオーバをトリガする条件を定義するハンドオーバパラメータ値(例えば、ハンドオーバ閾値)を設定し得る(すなわち、ハンドオーバパラメータは、そのようなハンドオーバが生じるべきかどうかを判断するのに用いられる)。より一般的にいえば、UEは、計算された値(例えば、M
p+Hys)を周期的に生成し得るのであって、計算された値がハンドオーバ閾値を超える(例えば、B2_1を下回る)場合には、UEは、信号測定値(例えば、M
p)をコントローラ105に報告する。そして、コントローラ105は、報告を用いて、別のセルへのUEのハンドオーバを生じさせるべきかどうかを判断する。ハンドオーバを生じさせるべきかどうかを判断するときには、コントローラ105は、例えば、ハンドオーバ閾値、モビリティ負荷バランス関数、またはそれらのいずれかの組合せとの関係で、信号測定値を考察し得る。
【0022】
同様に、コントローラ112は、ハンドオーバを生じさせるべきかどうかを判断するときに用いるためのハンドオーバパラメータ値(例えば、ハンドオーバ閾値)を設定し得る。なお、ハンドオーバパラメータ値とは、基地局106によって提供されるRANセルから別のセルへのハンドオーバをトリガする条件を定義する値などである。それぞれのコントローラは、閾値をUEに送信し得る。UEは、それらの閾値を用いてハンドオーバイベントを検出する。より一般的にいえば、UEは、計算された値(例えば、M
OtherRAT+CIO
OtherRAT−H
3a/2)を周期的に生成し得るのであって、計算された値がハンドオーバ閾値を超える(例えば、3A_2を上回る)場合には、UEは、信号測定値(例えば、M
OtherRAT)をコントローラ112に報告する。そして、コントローラ112は、報告を用いて、別のセルへのUEのハンドオーバを生じさせるべきかどうかを判断する。ハンドオーバを生じさせるべきかどうかを判断するときには、コントローラ112は、例えば、ハンドオーバ閾値、モビリティ負荷バランス関数、またはそれらのいずれかの組合せとの関係で、信号測定値を考察し得る。いくつかの場合において、基地局106がNBである場合には、コントローラ112は無線ネットワークコントローラ(RNC)である。ある実施形態では、基地局104のコントローラは、基地局104の一部(例えば、eNBの一部)であり得るし、および/または、ネットワークノード(例えば、MMEノード)であり得る。
【0023】
コントローラ105、112は、それらのコアネットワーク108、110を通じて情報を通信することにより、モビリティ設定の調節などのハンドオーバ情報を協調し得る。モビリティ設定は、1つまたは複数のハンドオーバ閾値など、ハンドオーバイベントが生じたかどうかを示すための1つまたは複数のパラメータ(すなわち、1つまたは複数のハンドオーバパラメータ)を含み得る。ある実施形態では、協調は、閾値B2_1または3A_2など、1つまたは複数のハンドオーバ閾値の通信を含む。そのような閾値の通信は、後でより詳細に論じられる。
【0024】
ハンドオーバ閾値は、ハンドオーバをトリガするためには、サービング側のRANセルにおける信号品質がどれだけ劣化しなければならないのか、および/または、ターゲット側のRANセルにおける信号品質がどれだけよくなければならないのか、を制御し得る。UEがセルの基地局から更に離れる方向に移動することによって生じるものなど、UEのサービングセルにおける信号品質の劣化は、UEがターゲットセルにハンドオーバされない場合には、結果的に無線リンク障害(RLF)に至り得る。
【0025】
ハンドオーバ閾値などのモビリティ設定を調節することで、RLFの発生を削減し得る。図2Aは、ハンドオーバ閾値B2_1が調節された場合を、図解している。閾値は、e−UTRANセルにおける信号品質を反映し、e−UTRANセルからUTRANセルへのハンドオーバをトリガするのに用いられる。そのようなハンドオーバイベントは閾値B2_2にも依存し、閾値B2_2はターゲットUTRANセルにおける信号品質と関連するのであるが、この実施形態では、UTRANがカバーする範囲は十分に広いために、一般的にはその信号品質はハンドオーバをサポートすると想定される。よって、このe−UTRANセルにおける信号品質と閾値B2_1とだけを扱う。他のさらにUTRANの信号品質を考慮することもあり得る。
【0026】
図2Aは、ユーザケース1と称される場合を図解している。この場合、UEがe−UTRANセルによってサービスを提供されている間に、または、e−UTRANセルからUTRANセルへのハンドオーバの間に、RLFが生じる。例えば、ハンドオーバが開始された直後にRLF条件が生じる場合には、障害はハンドオーバの間に生じ得る。この例では、ハンドオーバは、成功裏のうちに完了しないことがあり得る。
【0027】
ユーザケース1におけるRLFの発生を削減させるひとつの方法は、e−UTRANセルからUTRANセルへのハンドオーバをトリガするハンドオーバ閾値を緩和することである。例えば、図2Aは、閾値B2_1が低いときにRLFが生じがちであることを示している。ハンドオーバのための閾値を緩和することによって(より詳しくはB2_1を上昇させることによって)、RLFのおそれを低下させることができる。閾値を上昇させると、e−UTRANセルにおける信号品質がRLFの段階まで劣化する前に、UEがUTRANセルによりハンドオーバされやすくなる。
【0028】
RLFの発生を削減させるために、e−UTRANセルのコントローラがB2_1を上昇させ得るが、過剰な回数のハンドオーバを回避するために、B2_1を低下させてもよい。すなわち、B2_1のようなハンドオーバ閾値(または、いずれかの他のハンドオーバパラメータ)を緩和させることの副作用は、緩和された閾値が不必要なハンドオーバの蓋然性を上昇させ得るということである。例えば、図2Bは、図2Aの場合より優れた信号品質をUEが経験していることを示しており、この場合にはハンドオーバが不要である。UEは、図2Aの場合と比較して、より優れた信号品質を経験することができるが、その理由は、UEが異なる位置にあるから、異なる時間(例えば、別の日)において信号品質を経験しているから、または何らかの他の理由による。図2Bに示されているように、B2_1閾値が上昇すると、不必要なハンドオーバがトリガされる。
【0029】
よって、ハンドオーバ閾値は、RLFのおそれを低下させることと、不必要なハンドオーバのおそれを低下させることとの間のトレードオフを均衡させるように、調節され得る。RANコントローラにおけるRAT相互間のモビリティのロバスト性最適化(IRAT MRO)機能は、このトレードオフを考慮してハンドオーバ閾値を調節し得る。TS48.017、TS48.018、TS36.413、およびTS25.413で規定されているように、RLF報告は、遅すぎる時点で生じたハンドオーバについての、または、不必要なハンドオーバについての統計を収集するために、生成され得る。この統計は、ハンドオーバ閾値を調節するために、用いることができる。
【0030】
トレードオフは、また、UTRANからe−UTRANへのハンドオーバの場合について、図3Aおよび図3Bに図解されている。これらの図には、閾値3A_2の調節が示されており、この閾値3A_2は、ターゲットe−UTRANセルにおける信号品質を示す。ハンドオーバイベント3Aもまた、閾値3A_1に依存し、この閾値3A_1は、サービング側のUTRANセルにおける信号品質を示す。しかしながら、この実施形態では、UTRANがカバーする範囲は十分に広いために、ハンドオーバが生じるのは、UTRANの信号品質が劣るという理由ではなく、e−UTRANの方がUTRANよりも好ましい場合であってe−UTRANセルにおける信号品質がハンドオーバをサポートすることを理由とすることが想定されている。他の実施形態では、UTRANの信号品質も考慮することがあり得る。
【0031】
図3Aは、ユーザケース2と称される場合におけるRLFを図解している。この図は、ターゲットe−UTRANセルにおける信号品質はハンドオーバをサポートしないところまで劣化するということを示している。しかし、閾値3A_2の設定が低すぎるために、信号品質の若干の改善があると、サービング側のUTRANセルからe−UTRANセルへのハンドオーバがトリガされる。ハンドオーバの後では、e−UTRANセルにおける信号品質はその劣化が再び生じて、RLFに至る。ユーザケース2におけるRLFは、閾値3A_2を上昇させるなど、ハンドオーバ閾値(または、いずれかの他のハンドオーバパラメータ)をより厳格にすることによって、対抗することが可能である。図2Aに更に示されているように、閾値3A_2を上昇させることで、UEがUTRANに留まり、よって、RLFのおそれが低下することが保証される。
【0032】
しかし、ハンドオーバパラメータをより厳格にすると、UTRANからe−UTRANへのハンドオーバのための機会も失われる。図3Bに示されているように、e−UTRANセルにおける信号品質がハンドオーバをサポートするのに十分である場合には、3A_2という閾値を上昇させても、依然として、ハンドオーバが回避される。これによって、UEがUTRANに存在する時間が不必要に長くなり、LTEがカバーする範囲が縮小する。
【0033】
UTRANセルのコントローラは、IRAT MRO機能を実装してもよく、この場合には、RLFのおそれを低下させることとハンドオーバの機会喪失を回避することとトレードオフを均衡させるように、3A_2閾値を調節することができる。
【0034】
しかし、単一の閾値B2_1または3A_2(または、いずれかの他のハンドオーバ閾値)のみの調節をRANセルに適用するのは最適ではないかもしれない。その理由は、上で論じられたトレードオフは、UEが異なるか、1つのUE上で動作しているアプリケーションが異なると、異なる態様で均衡し得るからである。例えば、アプリケーションが異なると、RLFまたは過剰なハンドオーバの発生率が異なりうる。リアルタイムのサービス(例えば、ビデオチャットアプリケーション)を提供するUEアプリケーションは、リアルタイムではないサービス(例えば、ファイル転送アプリケーション)を提供するUEアプリケーションよりも、RLFに対して敏感であることが多い。よって、リアルタイムのUEアプリケーションは、RLFに対する寛容度がより低いが、過剰なハンドオーバまたはUTRANにおける長い滞在時間については、より寛容である。他方で、リアルタイムではないUEアプリケーションは、RLFについてはより寛容であり得るが、過剰なハンドオーバまたはUTRANにおける長い滞在時間については、寛容度が低い。後者の状況はスループットを低下させるから、というのがその理由である。
【0035】
ある実施形態では、リアルタイムのUEアプリケーションとリアルタイムではないUEアプリケーションとは、様々な基準に基づき、区別され得る。区別基準には、それぞれのアプリケーションに関連づけられるサービスの品質(QoS)またはUEの性能が含まれ得る。よって、ある実施形態では、異なるハンドオーバパラメータ値(例えば、異なるハンドオーバ閾値)が、特定の(QoS)パラメータの特定の値に、および/または、特定のUE性能パラメータの特定の値に、適用され得る。
【0036】
QoSパラメータは、UE上で動作しているアプリケーションのためのデータを搬送している信号ベアラと関連し得る。例えば、QoSパラメータは、QoSクラスインジケータ(QCI)を含み、UEのためのデータを搬送している特定の信号ベアラにどのようなQCI値が割り当てられるのかに基づいて、異なるハンドオーバ閾値が適用され得る。図4は、2つの異なるQCI値に基づくハンドオーバ閾値B2_1への2つの異なる調節を図解している。この例では、2つの異なる調節が、同じUEに対して適用され得る。例えば、UEで動作しているリアルタイムのアプリケーションは、QCIが4である信号ベアラを用いてデータを転送し、他方で、UEで動作しているリアルタイムではないアプリケーションは、QCIが2である信号ベアラを用いてデータを転送し得る。
【0037】
2というQCI値と関連するアプリケーションは、RLFに関して寛容度がより低いが、過剰なハンドオーバに関しては、より寛容であり得る。よって、ハンドオーバ閾値B2_1を上昇させて、RLFのおそれを低下し得る。このUEアプリケーションが、信号402Bによって表されているような信号品質の劣化を後で経験する場合には、B2_1の閾値を上昇させると、ハンドオーバがトリガされ、RLFを回避し得る。
【0038】
4というQCI値と関連するアプリケーションは、RLFに関してはより寛容であり得るが、過剰なハンドオーバに関しては寛容度がより低いことがあり得る。例えば、e−UTRANセルでRLFを経験するファイル転送アプリケーションは、e−UTRANセルとの無線接続を簡単に再確立して、ファイル転送を再開し得る。しかし、過剰なハンドオーバは、アプリケーションに対するファイル転送速度を低下させ得る。よって、図4に図解されているように、ハンドオーバ閾値B2_1は、QCIが4である信号ベアラを用いるアプリケーションに対しては、より低くして、ハンドオーバのおそれを低下させる。
【0039】
UE性能パラメータは、例えば、UEカテゴリ、UE無線リソース管理(RRM)コンフィギュレーション(例えば、DRXコンフィギュレーション)、UEの加入タイプ、UEの端末モデル、およびUEの速度(例えば、低速なのか、高速なのか)の中の1つまたは複数を含み得る。
【0040】
図5は、QCIなどのQoSパラメータが関連する様々な信号ベアラを図解している。UEは、異なるQoS要件をそれぞれが有するが同時に動作する複数のアプリケーション(例えば、VoIP、ブラウジング、ファイルダウンロード)を有することができる。これらの異なる要件をサポートするために、異なる信号ベアラが設定され、あるQoSパラメータ値とそれぞれが関連している。1つのEPSベアラ/E−RAB(無線アクセスベアラ)は、EPC/e−UTRANにおけるベアラレベルのQoS制御のための精度(granularity)のレベルを有する。すなわち、同じEPSベアラにマップされたサービスデータフロー(SDF)は、同じベアラレベルのパケット転送処理(例えば、スケジューリングポリシ、キュー管理ポリシ、レート形成ポリシ、RLCコンフィギュレーションなど)を受ける。
【0041】
EPSベアラ/E−RABと関連する保証ビットレート(GRB)値に関する専用ネットワークリソースが、ベアラ確立/修正の時点で、(例えば、eNBにおけるアドミッション制御機能によって)恒久的に割り当てられる場合には、EPSベアラ/E−RABは、GBRベアラと称される。そうでない場合には、EPSベアラ/E−RABは、非GBRベアラと称される。専用のベアラは、GBRまたは非GBRのいずれかのベアラであり、デフォルトのベアラは非GBRベアラでなければならない。
【0042】
図5に示されているように、EPSベアラのパケットは、UEとeNBとの間で、無線ベアラを介して、移送される。S1ベアラは、eNBとS−GWとの間で、EPSベアラのパケットを移送する。E−RABは、実際にはこれら2つのベアラ(つまり無線ベアラとS1ベアラ)の連結(concatenation)であり、これら2つのベアラは1対1の態様で、マップされる。S5/S8ベアラは、サービングゲートウェイ(S−GW)とパケットデータネットワークゲートウェイ(P−GW)との間で、EPSベアラのパケットを移送して、EPSベアラを完成させる。
【0043】
上述されたように、ベアラのためのQoSパラメータは、ベアラサービスのQCI、ARP、GBR、AMBR、およびいずれかの他の指標(例えば、ベアラがリアルタイムのサービスに対するのか、または、非リアルタイムのサービスに対するものであるのか)の中の1つまたは複数を含む。
・QoSクラス識別子(QCI):ベアラレベルのパケット転送処理(例えば、スケジューリングウェイト、アドミッション閾値、キュー管理閾値、リンク層プロトコルコンフィギュレーションなど)を制御し、eNodeBを所有するオペレータによって予めコンフィギュレーションされたノード固有パラメータにアクセスするための基準として用いられるスカラ値である。ある実施形態では、9つのQCI値が標準化されており、これらのクラスの詳細な要件は3GPP TS 23.203で入手可能である。
・割り当ておよび保持優先順位(ARP):ARPの主たる目的は、リソースが限定されている場合に、ベアラ確立/修正要求が受け入れ可能か拒絶されるべきかを決めることである。更に、ARPは、例外的にリソースが限定されている間に(例えば、ハンドオーバにおいて)、どの(1つまたは複数の)ベアラを排除すべきかを決めるために、eNodeBによって用いられることがある。
・保証ビットレート(GBR)(GBRベアラと関連する):GBRベアラによって提供されると予想可能なビットレートである。
・最大ビットレート(MBR)(GBRベアラと関連する):GBRベアラによって提供されと予想可能な最大ビットレートである。MBRは、GBRより大きくても等しくてもよい。
【0044】
ある実施形態では、UEによるそれぞれのAPNアクセスに対して、APN当たりの総合最大ビットレート(APN−AMBR)が関連づけられる。APN−AMBRは、すべての非GBRベアラに亘り、および、同じAPNのすべてのPDN接続に亘り、提供されると予想可能な総合ビットレートの限度を設定する。
【0045】
ある実施形態では、EMM−REGISTERED状態にあるそれぞれのUEには、UE当たりの総合最大ビットレート(UE−AMBR)として知られている、ベアラ総合レベルのQoSパラメータが関連している。UE−AMBRは、あるUEのすべての非GBRベアラに亘り提供されると予想可能な総合ビットレートを制限する。
【0046】
QoSパラメータとUE性能パラメータとに関し以上で論じられてきたが、の区別基準には、RLF、過剰なハンドオーバ、および/またはより好ましくないRANにおける長い滞在時間に対する敏感性のレベルを区別する、いずれかの他のパラメータが含まれ得る。
【0047】
以上で論じられたように、ハンドオーバ条件(例えば、ハンドオーバ閾値)の調節は、ソースRANセルとターゲットRANセルとの間での協調が可能である。この協調は、過剰な回数のハンドオーバが生じる「ピンポン」効果を回避するために、そして、カバーされる範囲(例えば、LTEでのカバーされる範囲)の縮小を回避するために、用いられ得るのであって、UEでは、ソースRANセルにおいて(例えば、UTRANセルにおいて)長い滞在時間を費やす。
【0048】
図6Aおよび図6Bは、「ピンポン」および縮小状況をそれぞれ図解している。両方の図面において、e−UTRANセルのコントローラは、e−UTRANセルからUTRANセルへのハンドオーバをトリガする閾値(例えば、B2_1)を調節する。しかし、e−UTRANセルのコントローラは、逆の方向のハンドオーバをトリガし得る閾値(例えば、3A_2)に関しては、UTRANセルのコントローラとの間で協調を行わない。結果的に、閾値B2_1と3A_2との間のギャップは、縮小される。このようにギャップが縮小されることにより、UTRANへのハンドオーバとe−UTRANへハンドオーバされ返すこととの間でUEが「ピンポン」するおそれが増加する。例えば、図6Aは、時間t
1において、信号品質がUTRANセルからe−UTRANセルへのハンドオーバをトリガする状態に近く、時間t
2においては、信号品質がe−UTRANセルからUTRANセルへのハンドオーバをトリガする状態に近い、ということを図解している。
【0049】
図6Bは、e−UTRANセルのコントローラがUTRANへのハンドオーバをトリガするのに用いられる閾値B2_1を低下させるが、UTRANセルのコントローラが、e−UTRANに戻るハンドオーバをトリガするための閾値3A_2を同じレベルで用い続けることを示す。この場合には、B2_1と3A_2との間のギャップが増加する。図面が示しているように、3A_2の高い値は、信号がUTRANセルに存在する時間を延長させ得る。
【0050】
次の表1は、他のRANセルにおける対応する調節を行うことなく、あるRANセルに対するハンドオーバ条件を調節(e−UTRANセルに対するB2_1閾値だけ、または、UTRANセルに対する3A_2だけの調節など)することの効果の概要を示している。
【0052】
よって、ある実施形態において、e−UTRANセルのコントローラ(「e−UTRANコントローラ」)は、閾値B2_1に対して調節を行うか、これから調節を行うであろう場合、UTRANセルのコントローラ(「UTRANコントローラ」)との間で協調を試みることができ、それにより、UTRANコントローラは、閾値3A_1に対して対応する調節を行うことが可能である。例えば、e−UTRANコントローラがB2_1を上昇させる場合には、協調により、UTRANコントローラに3A_1を上昇させて、2つの閾値の間のギャップを維持することにより、「ピンポン」または縮小効果を減少させてもよい。一方のRANセルに、B2_1閾値または3A_2閾値を他方のRANセルに送信させることによって、協調を達成してもよい。例えば、e−UTRANコントローラは、IRAT MRO機能を動作させることにより、RLF特性に基づいて閾値B2_1を調節してもよい。近隣UTRANコントローラとの間でこの調節を協調するために、UTRANコントローラは、3A_2閾値への対応する調節を計算して、調節された値である3A_2を近隣UTRANコントローラへの推奨として通知することができる。UTRANコントローラは、この調節された3A_2の値を採用して、B2_1と3A_2との間のギャップを所望の量の範囲内に維持してもよい。あるコントローラから別のコントローラへ単一の閾値を通信することに関する更なる詳細は、2013年4月16日に出願された「モビリティ設定のRAT相互間での協調(Inter−RAT Coordination of Mobility Settings)と題するPCT出願である第PCT/SE2013/050247号において入手可能である。
【0053】
ある実施形態では、協調は、IRATモビリティ負荷バランス(MLB)機能によってトリガされ得る。RANセルが最大収容能力に近づいている場合、RANセルは、UEがセルの外部へハンドオーバされることを可能にする条件を緩和することと、UEがセルの内部にハンドオーバされることを可能にする条件をより厳格にすることの少なくともいずれかによって、負荷の均衡を実行しようとしてもよい。ある実施形態では、第1のRANセルのコントローラ(第1のコントローラ)が、第1のハンドオーバパラメータ値(第1のRANセルから第2のRANセルへのハンドオーバを生じさせるべきかどうかを判断するのに用いられる)を計算する場合には、第1のコントローラは、関連するQoSパラメータ値またはUE性能パラメータ値と共に、第1のハンドオーバパラメータ値に関する情報を、第2のRANセルのコントローラ(第2のコントローラ)に通知してもよい。ある場合には、この情報は、第1のハンドオーバパラメータ値に基づく第2のハンドオーバパラメータ値(これは、第2のRANセルから第1のRANセルへのハンドオーバを生じさせるべきかどうかを判断するのに用いられる)への計算された調節値を含み得る。計算された調節値は、更に、IRAT MLB機能に基づいてもよい。ある場合には、情報は、第1のハンドオーバパラメータ値を含み得る。第2のコントローラは、第1のパラメータ値を受信し、第1のハンドオーバパラメータ値に基づいて、第2のハンドオーバパラメータ値への調節値を計算してもよい。計算された調節値は、更に、IRAT MLB機能に基づいてもよい。
【0054】
ある実施形態では、上で論じられた協調は、RAN情報管理(RAN information management、RIM)メッセージを通じて達成されてもよく、このRIMメッセージには、推奨されたハンドオーバ閾値のためのフィールドが含まれる。しかし、そのようなメッセージは、RANコントローラは複数のQoSパラメータまたはUE性能パラメータの異なる値に対して複数のハンドオーバ閾値を用い得る、ということを考慮しない。よって、ターゲットセルのコントローラは、ハンドオーバ閾値を受信する場合に、どのQoSパラメータ値またはUE性能パラメータ値をハンドオーバ閾値が適用するのかに関して、曖昧であり得る。従って、IRAT協調のためのメッセージのコンテンツは、どのQoSパラメータ値またはUE性能パラメータ値をハンドオーバ閾値(または、他のハンドオーバ条件)が適用するのかに関する情報が通知可能であるように、更新されることが必要である。
【0055】
図7は、ハンドオーバ閾値などのハンドオーバパラメータを、第2のRANセル(例えば、UTRANセル)と関連する第2のコントローラとの間で協調するために、第1のRANセル(例えば、e−UTRANセル)と関連する第1のコントローラによって実行されるプロセス700を図解する流れ図である。ある実施形態では、第1のコントローラ(例えば、eNB)が第1のRANセルを制御し、第2のコントローラ(例えば、RNC)が第2のRANセルを制御する。プロセス700によると、第1のコントローラは、ハンドオーバ閾値に関する情報を第2のコントローラへ送配(convey)するだけではなくて、その情報が適用可能な状況を第2のコントローラへ送配することも、可能になる。ある実施形態では、プロセス700はステップ701において開始し、このステップ701では、第1のコントローラが、第1のRANセルから第2のRANセルへのハンドオーバを生じさせるべきかどうかを決定するときに用いるための第1のハンドオーバパラメータ値を、決定する。ある実施形態では、第1のハンドオーバパラメータ値は、満たされると、UEに信号測定を第1のコントローラに報告させることになる条件を定義する。そして、第1のコントローラは、この報告を用いて、ハンドオーバを生じさせるかべきかどうかを決定する。ある実施形態では、第1のハンドオーバパラメータ値は、第1のRANセルから第2のRANセルへのハンドオーバをトリガする条件を定義する。ある例では、第1のRANセルがe−UTRANセルであり、第2のRANセルがUTRANセルである場合には、第1のハンドオーバパラメータ値は、閾値B2_1、ヒステリシス値、トリガ時間(time−to−trigger)(TTT)値、およびB2ハンドオーバイベントの条件が満たされるかどうかを判断するのに用いられるいずれかの他の値の中の少なくとも1つを含み得る。第1のハンドオーバパラメータ値の決定は、例えば、eNBによって実行されているIRAT MRO機能に基づいてもよい。ある実施形態では、eNBは、対応する調節を既に行ったことを第2のコントローラがステップ706において示さない限り、第1のパラメータ値の使用を開始しない。
【0056】
ステップ702では、第1のコントローラは、第1のハンドオーバパラメータ値に関する情報を、第2のコントローラに通知する。後で更に詳細に論じられるが、ハンドオーバ協調が分散されている(distributed)モードでは、通知された情報は、第1のハンドオーバパラメータ値を含む。第2のコントローラは、次に、第1のハンドオーバパラメータ値に基づき、それ自体のハンドオーバパラメータ値(第2のハンドオーバパラメータ値)を調節する。ハンドオーバ協調が第1のコントローラに集中化されているモードでは、第1のコントローラが、第2のハンドオーバパラメータ値への調節値を計算し、第2のハンドオーバパラメータ値への調節値は通知された情報に含まれる。ある例として、第1のRANセルがe−UTRANセルであり、第2のRANセルがUTRANセルである場合には、e−UTRANのeNBが、B2_1閾値を第1のハンドオーバパラメータ値として決定する。協調が分散されている場合には、ステップ702で通知されるハンドオーバ情報は、決定されたB2_1値を含むか、決定されたB2_1値によって構成される。協調が集中化されている場合には、ステップ702で通知されるハンドオーバ情報は、決定されたB2_1値に基づいて計算される3A_2を含むか、決定されたB2_1値に基づいて計算される3A_2によって構成される。
【0057】
ある実施形態では、通知されるハンドオーバ情報は、調節量(例えば、xdBで示されたハンドオーバ閾値の上昇または下降値)または絶対値(例えば、ydBで示された調節されて上昇した閾値または下降した閾値)を示してよい。
【0058】
ステップ704では、第1のコントローラは、第2のコントローラへ、QoSパラメータの値またはUE性能パラメータの値など、そのハンドオーバ情報と関連する1つまたは複数の区別基準の1つまたは複数の値を通知する。
【0059】
QoSパラメータは、第1のRANセルまたは第2のRANセルによってサービスを供給されているユーザ機器(UE)に提供されるか提供されると予想されるサービスのレベルに影響するパラメータを含み得る。ある実施形態では、QoSパラメータは、UEによって用いられている信号ベアラ(例えば、EPSベアラ)のQCIと、信号ベアラのARPと、信号ベアラがGBRベアラかどうかに関する指標と、信号ベアラがリアルタイムデータを搬送しているかどうかに関する指標との中の1つまたは複数を含む。UE性能パラメータは、UE性能を示し得る。UE性能パラメータは、例えば、UEのカテゴリと、UEのRRMコンフィギュレーション(例えば、DRXコンフィギュレーション)と、UEの加入タイプと、UEの速度(例えば、高速または低速)の中の1つまたは複数を含み得る。
【0060】
例えば、eNBは、NBに、閾値3A_2と、QCIおよびUEカテゴリのようなQoSパラメータおよびUE性能パラメータと、これらのパラメータに対する値(インスタンスとも称される)の組とを通信し得る。QCIについての値の組は、例えば、2および4を含み得る。他方で、UEカテゴリについての値の組は、例えば、カテゴリ1およびカテゴリ2を含み得る。これによると、調節された閾値3A_2が適用されるQoSパラメータ値の下記の4(2x2)通りの組合せ(すなわち、モード)が生じる。
モード1:QCI=2およびUEカテゴリ=1
モード2:QCI=2およびUEカテゴリ=2
モード3:QCI=4およびUEカテゴリ=1
モード4:QCI=4およびUEカテゴリ=2
【0061】
この実施形態では、第2のRANセルにおけるあるUEがカテゴリ3というUEカテゴリ値を有する場合には、第2のコントローラは、調節された3A_2の値をそのUEに中継するのを控えてよい。第2のRANセルにおける別のUEが、カテゴリ2というUEカテゴリを有し、調節された3A_2の値を受け取ることがあり得る。しかし、その別のUEは、2または4というQCI値を有するベアラを現時点で用いている場合にだけ、その調節された閾値を用い得る。
【0062】
ある実施形態では、2つの閾値パラメータが、区別基準の異なる組または区別基準の異なる値と関連する場合があり得る。例えば、3A_2の閾値がQCIおよびUEカテゴリ値と関連し、B2_1の閾値がUEカテゴリおよびUE加入タイプ値と関連するということがあり得る。
【0063】
ステップ706では、第1のコントローラが、第2のコントローラから、第2のコントローラが第1のハンドオーバパラメータ値に基づき第2のハンドオーバパラメータ値を調節したかどうかに関する指標を受け取る。なお、この場合に、第2のハンドオーバパラメータ値は、第2のRANセルから第1のRANセルへのハンドオーバを生じさせるべきかどうかを決定するときに用いられるためのものである。ある実施形態では、第2のハンドオーバパラメータ値は、満たされると、UEに信号測定を第2のコントローラに報告させることになる条件を定義する。そして、第2のコントローラは、この報告を用いて、ハンドオーバを生じさせるかべきかどうかを決定する。ある実施形態では、第2のハンドオーバパラメータ値は、第2のRANセルから第1のRANセルへのハンドオーバをトリガする条件を定義する。ある例では、eNBが、B2_1の値に基づく推奨された3A_2の値をRNCに通知した場合には、この指標は、RNCが調節された3A_2の値を受け入れるか拒絶することを示してもよい。eNBがB2_1の値をRNCに通知する場合には、この指標は、i)RNCが通知されたB2_1の値に基づいてその3A_2の値を調節したこと、または、ii)RNCがその3A_2の値を調節していないことを、示し得る。
【0064】
図8は、集中化されたハンドオーバの協調の例を図解している。より詳しくは、2つのRANセルの間のハンドオーバの協調を、第1のコントローラにおいて集中化してもよい。ステップ802は、協調が第1のコントローラに集中化されているシナリオの一部である。ステップ802では、第1のコントローラが、第1のハンドオーバパラメータ値(例えば、B2_1)に基づいて、第2のハンドオーバパラメータ値(例えば、3A_2)への調節値を決定する。
【0065】
ステップ804では、第1のコントローラが、第2のハンドオーバパラメータ値の調節値を、第2のコントローラに通知する。例えば、eNBは、3A_2への対応する調節値を計算した後で、その対応する調節値を、UTRANセルのRNCへの推奨として、調節量(例えば、20dBmの増加)として、または調節された値(例えば、調節された3A_2の値はydBm)として、通知する。
【0066】
ステップ805では、第1のコントローラが、ステップ804で通知される推奨された調節値とステップ704で通知されるパラメータ値とに応答して第2のコントローラによって通知されるメッセージを受信する。なお、このメッセージは、第2のコントローラが調節値を受け入れたかどうかを示す情報を含む。ステップ806では、第2のコントローラが第2のハンドオーバパラメータ値の調節値を受け入れたかどうかを、第1のコントローラが、このメッセージに含まれている情報に基づいて判定する。例えば、e−UTRANのコントローラが、3A_2閾値への対応する調節値を、UTRANセルのコントローラに通知する場合には、UTRANセルのコントローラは、調節値を承認することを選択することができるし、調節された3A_2閾値を拒絶することも選択し得る。ある実施形態では、UTRANセルのコントローラは、第1のコントローラに送るメッセージにおいて、拒絶の理由を示す情報を提供してもよい。この理由には、例えば、UTRANセルが、3A_2値と関連する特定のQoSパラメータもしくはUE性能パラメータ、またはQoSパラメータもしくはUE性能パラメータの特定の値をサポートしていないこと、3A_2値がサポートされる範囲の外に外れていること、または、いずれかの他の理由が含まれ得る。調節された3A_2値が、UTRANセルのコントローラによってサポートされる閾値の範囲から外れる場合には、そのUTRANセルのコントローラは、メッセージの中に、閾値のサポートされる範囲を示す情報を含めてもよい。
【0067】
ステップ808では、第2のコントローラが対応する調節値を受け入れないとの判断に応答して、第1のコントローラは、第1のハンドオーバパラメータのために、別の値(例えば、別のB2_1値)を決定し得る。例えば、eNBが、当初に、B2_1閾値への増加を決定し、3A_2値への対応する増加を決定し得るが、RNCは、3A_2値への対応する増加を拒絶し得る。それに応答して、eNBは、元のB2_1閾値を増加させないこと、または、それを僅かな量だけ増加させることを選択し得る。ある実施形態では、第2のコントローラが、サポートされている閾値の範囲(例えば、複数の3A_2値を示す)とともに応答した場合には、第1のコントローラは、その範囲に基づき、再計算を実行し得る。
【0068】
ステップ810では、第2のコントローラが対応する調節値を受け入れるという判断に応答して、第1のコントローラが、第1のRANセルから第2のRANセルへのハンドオーバイベントを示すための第1のハンドオーバパラメータ値(例えば、B2_1値)の使用を開始するか、使用し続け得る。
【0069】
ある実施形態では、ステップ702および704での通知は、RAN情報管理(RIM)メッセージの一部である。表2は、本明細書ではフォーマット1と称される、ハンドオーバ協調がe−UTRANセルのあるeNBに集中化されているシナリオにおいて用いられるRIM要求転送メッセージ(RIM Request Transfer message)の例示的なフォーマットを図解している。このフォーマットにより、e−UTRANが、3A_2閾値の推奨される対応する調節値をUTRANセルに通知することが可能になる。
【0071】
上の表が図解しているように、第1のコントローラは、ある実施形態では、第1のRANセルのセルIDと第2のRANセルのセルIDとの少なくとも一方を、更に通知し得る。ある実施形態では、セルIDは、推奨される3A_2値が向けられるセルのグループを示し得る。
【0072】
ある実施形態では、ステップ706において受信される指標は、RIM応答メッセージの一部として受信され得る。あるeNBにハンドオーバ協調が集中化されているシナリオでは、応答メッセージは、3A_2への推奨される対応する調節値が受け入れられたのか拒絶されたのかを示し得る。次の表3および表4は、RIM応答メッセージを図解している。
【0075】
図9は、第1のコントローラと第2のコントローラとの間で協調が分散されている例を図解している。ステップ902では、第1のコントローラは、第2のコントローラに、第1のハンドオーバパラメータ値(例えば、B2_1)を通知する。換言すると、この実施形態では、通知されるハンドオーバ情報は、ステップ701で決定された調節値を含むか、ステップ701で決定された調節値から構成される。分散型の協調シナリオでは、第1のコントローラ(例えば、eNB)は、他方の方向へのハンドオーバのために用いられる閾値(例えば、UTRANからe−UTRANへのハンドオーバのための3A_2値)への対応する調節値を計算する責任を有していない。代わりに、例えば、eNBは、B2_1閾値の調節値をUTRANのRNCに送信し、その3A_2値への対応する調節値の決定をUTRANに任せる。
【0076】
ステップ905では、第1のコントローラが、ステップ904で通知される調節値とステップ704で通知されるパラメータ値とに応答して、第2のコントローラによって送信されたメッセージを受信する。なお、このメッセージは、第2のコントローラが、第1のハンドオーバパラメータ値に基づいて第2のハンドオーバパラメータ値へ調節を行ったかどうかを示す情報を含む。
【0077】
ステップ906では、第1のコントローラが、このメッセージに含まれる情報に基づき、対応する調節を第2のコントローラが行ったかどうかを判断し得る。例えば、あるeNBがB2_1への増加を決定し、その増加をRNCに通知した場合には、そのeNBは、その応答として、RNCがその3A_2値への対応する増加を行ったかどうかを示すメッセージを受信し得る。
【0078】
ステップ908では、ステップ808におけるように、第2のコントローラは第2のハンドオーバパラメータ値(例えば、3A_2)への対応する調節を行っていないという判断に応答して、第1のコントローラが、第1のハンドオーバパラメータのために別の値(例えば、別のB2_1値)を決定し得る。
【0079】
ステップ910では、ステップ810におけるように、第2のコントローラは第2のハンドオーバパラメータ値(例えば、3A_2)への対応する調節を行ったという判断に応答して、第1のコントローラが、第1のRANセルから第2のRANセルへのハンドオーバをトリガするための第2のハンドオーバパラメータ値(例えば、B2_1)を使用し始めるか、その使用を継続し得る。
【0080】
ある実施形態では、ステップ902および704における通知は、RAN情報管理(RIM)メッセージの一部である。表5Aおよび表5Bは、ハンドオーバ協調がe−UTRANセルのeNBとUTRANセルのRNCとに分散されているシナリオで用いられるRIM要求転送メッセージの例示的なフォーマットをそれぞれ図解しており、これらは、本明細書ではフォーマット5Aおよび5Bと称される。フォーマット5Aにより、e−UTRANセルがそのB2_1値をUTRANセルに送信することが可能になり、フォーマット5Bにより、UTRANセルがその3A_2値をe−UTRANセルに送信することが可能になる。
【0083】
図10は、ある実施形態を図解している。この実施形態では、あるコントローラが別のコントローラに、どちらの区別基準(例えば、QoSパラメータおよび/もしくはUE性能パラメータ)が、または、より詳しくは、区別基準のどの例(例えば、QoSパラメータおよび/もしくはUE性能パラメータのどちらの値)がハンドオーバを判断するために他方のコントローラによってサポートされているのかを判断するように問い合わせ得る。より詳しくは、ステップ1002では、第1のコントローラが、第2のコントローラに、第2のRANセルにおけるハンドオーバを判断するために用いられる1つもしくは複数のQoSパラメータ値または1つもしくは複数のUE性能パラメータ値を求める要求を、送信する。例としては、e−UTRANのeNBは、UTRANセルのRNCから、どちらの区別基準(例えば、QCI、UEカテゴリ)がRNCによってサポートされているのかを示し、これらのパラメータのどの値(例えば、2および4というQCI値、カテゴリ1およびカテゴリ2というUEカテゴリ値)がサポートされているのかを更に示す情報を要求し得る。
【0084】
この情報は、ステップ1004において受信され、この受信された情報により第1のコントローラがハンドオーバ協調を調整することが可能になり、結果的に、第1のコントローラは、(例えば、QoSパラメータおよび/またはUE性能パラメータ値などの)区別基準値のサポートされる組に対応するハンドオーバパラメータ調節値だけを通知する。例えば、ステップ1006では、第1のコントローラは、受信されたQoSパラメータ値またはUE性能パラメータ値に基づいて、第2のハンドオーバパラメータ値の調節値を決定し得る。例としては、あるコントローラが、あるUTRANセルから、2および4というQCI値がハンドオーバの判断に用いられるという指標を受信する場合には、このコントローラは、QCI=2である状況に対する3A_2値の調節値を決定し得る。
【0085】
ステップ1008では、第1のコントローラは、1つもしくは複数の受信されたQoSパラメータ値またはUE性能パラメータ値の中の1つを通知し得る。この1つまたは複数のパラメータ値は第2のコントローラから受信されたので、第1のコントローラは、従って、それらのパラメータ値は第2のRANセルによってサポートされるということを、知り得る。
【0086】
図11は、コントローラが、相互に、それらの区別基準を分散型協調シナリオの一部として告知するプロセスを図解している。ステップ1102では、第1のコントローラは、第2のコントローラに、ハンドオーバを判断するために第1のRANで用いられる1つもしくは複数のQoSパラメータ値またはUE性能パラメータ値を、通知する。例としては、eNBは、QoSパラメータおよびUE性能パラメータの以下の値と関連し得る。すなわち、(QCI=2、UEカテゴリ=カテゴリ1)、(QCI=4、UEカテゴリ=カテゴリ1)、(QCI=2、UEカテゴリ=カテゴリ2)、(QCI=4、UEカテゴリ=カテゴリ2)である。この例では、eNBは、組合せを示す情報を、UTRANセルのRNCに送信し得る。
【0087】
ステップ1104では、第1のコントローラは、第2のコントローラから、ハンドオーバを判断するために第2のRANセルで用いられる1つもしくは複数のQoSパラメータ値またはUE性能パラメータ値を受信する。ステップ1102および1104により、2つのRANセルは、他方のRANによって用いられる区別基準および/または区別基準値を知ることが可能になる。そのようにして知ることにより、ハンドオーバパラメータ値の調節値の計算を最適化することができる。
【0088】
ステップ1106では、第1のコントローラは、ハンドオーバを判断するために第1のRANセルにおいて用いられる1つもしくは複数のQoSパラメータ値またはUE性能パラメータ値を変更し得る。
【0089】
例えば、ハンドオーバを判断するために、eNBが当初(QCI=2、UEカテゴリ=カテゴリ1)、(QCI=4、UEカテゴリ=カテゴリ1)、(QCI=2、UEカテゴリ=カテゴリ2)、(QCI=4、UEカテゴリ=カテゴリ2)を用いる場合、eNBは、QCIパラメータに対するサポートを排除し、カテゴリ1というUEカテゴリ値に対するサポートを排除することにより、(UEカテゴリ=カテゴリ2)という組合せだけがハンドオーバの判断のために用いられるようになる。
【0090】
ステップ1108では、第1のコントローラは、この変更を、第2のコントローラに通知し得る。
【0091】
図12A〜図12B、図13A〜図13B、ならびに図14は、e−UTRANセルのためのコントローラ(例えば、eNB)およびUTRANセルのためのコントローラ(例えば、RNC)との関連で、上述されたハンドオーバ協調を図解している。図12Aおよび図12Bは、協調が区別基準値(例えば、QoSパラメータ値およびUE性能パラメータ値)の送信を要しない実施形態を図解している。図13A〜図13Bおよび図14では、協調が区別基準値の送信を要し、それによってハンドオーバ情報が特定の状況に適合されることが可能になるような実施形態を図解している。よって、例えば、ハンドオーバ閾値を、異なるQoS要件のための異なる値に調節することが可能である。次に、信号測定を実行するUEが、そのアクティブなベアラのQoSパラメータ値に基づいて、複数のハンドオーバ閾値から選択することができる。
【0092】
図12Aでは、eNBが、B2_1および3A_2のための新たな値など、新たなハンドオーバ閾値を計算することができる。ある実施形態では、計算を、IRAT MRO機能から実行することができ、1つまたは複数のRLF障害統計から導くことができる。新たなハンドオーバ閾値3A_2が、e−UTRANセルからUTRANセルへ通知され得る。通知されたハンドオーバ閾値は、RAN情報管理(RIM)要求転送メッセージの中で通知され得る。図12Aの図解はeNBに集中化されている協調に対応するので、RIMメッセージは、上で示した報告フォーマット1を有する。
【0093】
新たな3A_2値を受け取ると、UTRANセルは、この新たな3A_2値を(図12Aに示されているように)受け入れてもよいし、この新たな3A_2値を(図12Bに示されているように)拒絶してもよい。eNBは、UTRANセルが新たな3A_2値を受け入れると知らされる場合、eNBは次に、e−UTRANセルのためのB2_1値を、(まだ変更されていないと仮定して)この新たな値に変更しうる。そうではなくて、UTRANが新たな3A_2値を拒絶する場合には、eNBは、B2_1という閾値を新たな値に変更せずに、その代わりに、別のB2_1を計算し得る。別のB2_1値の計算は、3A_2がその以前の値から変更することがまったく不可能であるか、または、特定の範囲の外には変更不可能である、という制約に基づくことがあり得る。ある実施形態では、この制約は、UTRANからのRIM応答メッセージにおいて、新たな3A_2値が拒絶された理由として、提供され得る。例えば、UTRANセルは、3A_2値が最大値もしくは最小値を超えている、または、3A_2値を変更することはまったく不可能であるということを示してもよい。新たな3A_2値がインクリメントまたはデクリメントとして通信された場合には、拒絶された理由は、インクリメントまたはデクリメントが最大量を超えていることを示してもよい。
【0094】
ある実施形態では、UTRANセルからのRIM応答メッセージを待機するとき、e−UTRANは、タイマを維持してもよい。タイマが終了し応答が受信されない場合には、e−UTRANは、RIM転送要求メッセージを、一定の回数、再送信してもよい。e−UTRANは、依然として応答を受信しない場合には、UTRANセルがRIM転送要求メッセージにおけるハンドオーバ閾値を拒絶したと想定してもよい。
【0095】
図12A〜図12Bのように、図13A〜図13Bは、eNBが新たな3A_2値をターゲットUTRANセルに通知する集中化されたハンドオーバ協調を示す信号ダイアグラムを提供している。ターゲットUTRANセルは、新たな3A_2値の受け入れまたは新たな3A_2の拒絶をもって応答し得る。図13A〜図13Bの新たな3A_2値と、対応する新たな3A_2値とを、1つまたは複数の特定のQoSパラメータ(または、いずれかの他の区別基準)の中の1つまたは複数の特定の値(特定のインスタンスとも称される)に、更に適用する。よって、eNBは、新たな3A_2の値を用いて、1つまたは複数の特定の区別基準の1つまたは複数の特定の値を通知し得る。
【0096】
ある実施形態では、新たな3A_2の値を受信すると、UTRANセルが、その1つまたは複数の特定の区別基準が適用される状況に対して3A_2の値を受け入れると決めることがあり得るし(図13A)、3A_2の値を拒絶することもあり得る(図13B)。UTRANは、新たな3A_2の値を拒絶するときには、RIM応答メッセージにおいて理由を提供することがあり得る。図11Bにおけるように、この理由は、高すぎるまたは低すぎる3A_2の値を含み得る。図13Bでは、この理由は、1つまたは複数の特定の区別基準の1つまたは複数の特定の値に対するサポートが欠けていることや、または、区別基準それ自体に対するサポートが欠けていることも、更に含んでよい。例えば、RANセルがARPパラメータをサポートしない、または、ARPパラメータの特定の値をサポートしないということを、RANセルが示してもよい。
【0097】
ある実施形態では、RIM応答メッセージを受け取ると、eNBは、3A_2は特定の範囲の外には変更不可能である、修正がまったく不可能である、および/または特定の区別基準の特定の値に対してだけ変更可能であるという制約に基づいて、新たなB2_1を計算してもよい。
【0098】
図14は、UTRANセルとe−UTRANセルとがそれらの区別基準値を共有し得る分散型協調方式の特定の実施形態を図解している。よって、e−UTRANセルのeNBは、ハンドオーバを判断するときには2および4というQCI値を用いることを示す報告を作成して、その報告をUTRANセルに送信し得る。この報告により、UTRANセルは、e−UTRANセルによって用いられるQCI値によりよく対応するように、その3A_2値への調節を行うことが可能になり得る。同様に、UTRANセルは、例えば、ハンドオーバを判断するときには2、3、4というQCI値とカテゴリ1および2というUEカテゴリ値とを用いることを示す報告を作成し得る。UTRANからのこの報告は、e−UTRANが将来の時点で3A_2値をUTRANセルに推奨する集中型協調方式において用いられ得る。e−UTRANセルは、UTRANセルによって用いられている区別基準値を知っているため、その区別基準によりよく対応する推奨を提供し得る。
【0099】
上述された方法は、2つの無線アクセスネットワーク(RAN)に限定されることはない。図15は、基地局104によって提供されるRANと、ブースタデバイス118によって提供されるピコセルとを含む例示的なシステム1500を図解している。ある実施形態では、RANは、マクロレベルのカバー範囲を提供し、ピコセルは、ブースタリンクとして性能の強化を提供するだけである。両方の接続がアクティブであるときには、アンカリンク(anchor link)を、制御シグナリングのために用いることが可能であり、ブースタリンクはデータのために用いられる。しかし、いくつかの例では、アンカリンクは、アンカリンクを経由してデータを送るために用いられることもあり得る。この場合には、システム情報が、マクロレベルのカバー対象範囲またはピコセルを経由して送られることがあり得る。
【0100】
無線エリアネットワークの例示的なコントローラ
【0101】
図16は、いくつかの実施形態によるコントローラ104のブロック図を図解している。図16に示されているように、コントローラ104は、1つもしくは複数のプロセッサ(例えば、マイクロプロセッサ)、および/もしくは、特定用途向け集積回路(ASIC)やフィールドプログラマブルゲートアレイ(FPGA)などの1つもしくは複数の回路を含み得るデータ処理システム1602、他の装置からのメッセージを受信し他の装置へメッセージを送信するためのトランシーバ1605、非一時的なデータ記憶装置(例えば、ハードドライブ、フラッシュメモリ、光ディスクおよびその他)などの1つもしくは複数のコンピュータ可読なデータ記憶媒体および/または、揮発性の記憶装置(例えば、ダイナミックランダムアクセスメモリ(DRAM))を含み得るデータ記憶システム1606を含み得る。データ処理システム1602がプロセッサ(例えば、マイクロプロセッサ)を含む実施形態では、コンピュータプログラム製品1633が提供され得る。このコンピュータプログラム製品は、コンピュータプログラムを実装し、データ記憶システム1606のコンピュータ可読媒体1642上に記憶されているコンピュータ可読なプログラムコード1643(例えば、命令)を含む。データ記憶システム1606の例としては、限定列挙ではないが、磁気媒体(例えば、ハードディスク)、光媒体(例えば、DVD)、メモリデバイス(例えば、ランダムアクセスメモリ)などがある。いくつかの実施形態では、コンピュータ可読なプログラムコード1643は、データ処理システム1602によって実行されると、コード1643が、データ処理システム1602に本明細書において説明されているステップを実行させるように、コンフィギュレーションされている。いくつかの実施形態では、コントローラ104は、コード1643を必要とすることなく上述されたステップを実行するように、コンフィギュレーションされ得る。例えば、データ処理システム1602は、1つまたは複数の特定用途向け集積回路(ASIC)などの、特定のハードウェアだけで構成されることもあり得る。従って、上述された本発明の特徴は、ハードウェアおよび/またはソフトウェアにおいて実装されることがあり得る。
【0102】
図17は、いくつかの実施形態によるコントローラ112のブロック図を図解している。図17に示されているように、コントローラ112は、1つもしくは複数のプロセッサ(例えば、マイクロプロセッサ)、および/もしくは、特定用途向け集積回路(ASIC)やフィールドプログラマブルゲートアレイ(FPGA)などの1つもしくは複数の回路を含み得るデータ処理システム1702、他の装置からのメッセージを受信し他の装置へメッセージを送信するための基地局インターフェース1705、非一時的なデータ記憶装置(例えば、ハードドライブ、フラッシュメモリ、光ディスクおよびその他)などの1つもしくは複数のコンピュータ可読なデータ記憶媒体および/または、揮発性の記憶装置(例えば、ダイナミックランダムアクセスメモリ(DRAM))を含み得るデータ記憶システム1706を含み得る。データ処理システム1702がプロセッサ(例えば、マイクロプロセッサ)を含む実施形態では、コンピュータプログラム製品1733が提供され得る。このコンピュータプログラム製品は、コンピュータプログラムを実装し、データ記憶システム1706のコンピュータ可読媒体1742上に記憶されているコンピュータ可読なプログラムコード1743(例えば、命令)を含む。データ記憶システム1706の例としては、限定列挙ではないが、磁気媒体(例えば、ハードディスク)、光媒体(例えば、DVD)、メモリデバイス(例えば、ランダムアクセスメモリ)などがある。いくつかの実施形態では、コンピュータ可読なプログラムコード1743は、データ処理システム1702によって実行されると、コード1743が、データ処理システム1702に本明細書において説明されているステップを実行させるように、コンフィギュレーションされている。いくつかの実施形態では、コントローラ112は、コード1743を必要とすることなく上述されたステップを実行するように、コンフィギュレーションされ得る。例えば、データ処理システム1702は、1つまたは複数の特定用途向け集積回路(ASIC)などの、特定のハードウェアだけで構成されることもあり得る。従って、上述された本発明の特徴は、ハードウェアおよび/またはソフトウェアにおいて実装されることがあり得る。
【0104】
図18は、実例UE102のブロック図を図解している。図18に示されているように、UE102は、1つもしくは複数のプロセッサ(P)1855(例えば、マイクロプロセッサ)、および/もしくは、特定用途向け集積回路(ASIC)やフィールドプログラマブルゲートアレイ(FPGA)などの1つまたは複数の回路を含み得るデータ処理システム(DPS)1802、アンテナ1822に接続されており、様々なアクセスポイントからのメッセージを受信し、様々なアクセスポイントにメッセージを送信するためのトランシーバ1805、非一時的メモリユニット(例えば、ハードドライブ、フラッシュメモリ、光ディスクなど)のような1つもしくは複数のコンピュータ可読なデータ記憶媒体および/または、揮発性記憶装置(例えば、ダイナミックランダムアクセスメモリ(DRAM))を含み得るデータ記憶システム1806を含む。
【0105】
データ処理システム1802がプロセッサ1855(例えば、マイクロプロセッサ)を含む実施形態では、コンピュータプログラム製品1833が提供され得るが、このコンピュータプログラム製品は、コンピュータ可読なプログラムコード1843(例えば、命令)を含む。そして、このコンピュータ可読なプログラムコード1843が、限定列挙ではないが、磁気媒体(例えば、ハードディスク)、光媒体(例えば、DVD)、メモリデバイス(例えば、ランダムアクセスメモリ)など、データ記憶システム1806のコンピュータ可読媒体1842上に記憶されているコンピュータプログラムを実装する。いくつかの実施形態では、コンピュータ可読なプログラムコード1843は、データ処理システム1802によって実行されると、本明細書において説明されているステップを、データ処理システム1802に実行させるようコンフィギュレーションされている。
【0106】
いくつかの実施形態では、UE102は、コード1843を必要とすることなく、上述されたステップを実行するようにコンフィギュレーションされる。例えば、データ処理システム1802は、1つまたは複数の特定用途向け集積回路(ASIC)など、特別なハードウェアだけで構成されることもあり得る。よって、上述された本発明の特徴は、ハードウェアおよび/またはソフトウェアにおいて、実装され得る。例えば、いくつかの実施形態では、上述されたUE102の機能コンポーネントは、プログラムコード1843を実行するデータ処理システム1802によって、どのようなコンピュータプログラムコード1843とも独立に動作するデータ処理システム1802によって、またはハードウェアおよび/もしくはソフトウェアの任意の適切な組合せによって、実装され得る。
【0107】
第2の実施形態では、UE102は、更に、1)データ処理システム1802に接続されており、データ処理システム1802が情報をUE130のユーザに表示することを可能にするディスプレイスクリーン1823と、2)データ処理システム1802に接続されており、データ処理システム1802が音声をUE130のユーザに出力することを可能にするスピーカ1824と、3)データ処理システム1802に接続されており、データ処理システム1802がユーザからの音声を受け取ることを可能にするマイクロホン1825と、を含む。
【0108】
以上では本開示の様々な態様および実施形態が説明されてきたが、それらの態様および限定ではなく、単なる例示として提供されてきたということが理解されるべきである。よって、本開示の拡がりおよび範囲は、上述された例示的な実施形態のいずれによっても限定されるべきでない。更に、本開示において説明されている要素を可能性のあるすべての多様性において組み合わせたとしても、本明細書に含まれないとの記載がない限り、または、文脈と明らかに矛盾しない限り、いずれの組合せも本開示に含まれる。
【0109】
更に、本発明のプロセスは、一連のステップとして本明細書で説明され図面において図解されているが、これは、単に例証の目的でそのようにしたのであった。従って、いくつかのステップが追加され得ること、いくつかのステップが削除され得ること、ステップの順序が並び換えられ得ること、およびいくつかのステップが並行的に実行され得ることが、考えられる。
【図1】
【図2A】
【図2B】
【図3A】
【図3B】
【図4】
【図5】
【図6A】
【図6B】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12A】
【図12B】
【図13A】
【図13B】
【図14】
【図15】
【図16】
【図17】
【図18】
【国際調査報告】