例えば、アンライセンス周波数帯で動作する場合に、MAC手順の適切な動作および性能を維持するのに役立つ、MAC手順に関連付けられた方法、装置、およびシステムが本明細書に開示される。NR-UにおいてLBT失敗が発生した場合、既存のMAC手順が不適切なアクションを実行し、意図しない結果を招くことがある。
本明細書で取り上げられるMAC手順に関連する特定の問題には、とりわけ、帯域幅部分(Bandwidth Part:BWP)動作手順、ランダムアクセス手順、パワーヘッドルーム報告(Power Headroom Reporting:PHR)手順、Scellアクティブ化または非アクティブ化手順、間欠受信手順、スケジューリング要求(Scheduling Request:SR)手順、バッファステータス報告手順、論理チャネル優先順位付け手順、またはUEおよびノードB(Node B:NB)MAC手順の協調に関連付けられた問題が含まれ得る。
帯域幅部分動作手順の問題で、LBT失敗が発生した場合、帯域幅部分非アクティブタイマが満了し、スケジュールすべきULまたはDLデータがある場合でも、初期またはデフォルトBWPに切り替わることがある。
ランダムアクセス手順の問題で、LBT失敗が発生した場合、1)ランダムアクセス応答に対する十分な数(例えば、閾値数)の送信機会を許容にすることなく、ランダムアクセス応答ウィンドウが満了することがあり、2)プリアンブル送信を成功させるために必要な十分な数のプリアンブル送信を許容にすることなく、プリアンブル送信カウンタが最大送信数に達することがあり、3)MSG3送信に応答する十分な数のPDCCH送信機会を許容にすることなく、競合解決タイマが満了することがあり、または、4)プリアンブル送信がない場合でもパワーランピングが増加し、その結果、不正確な電力設定になることがある。
パワーヘッドルーム報告(PHR)手順問題で、LBT失敗が発生した場合、1)NBは、PHRがいつ計算され、その時点で何が送信されたかを判定することができないことがあり、その結果、不正確なパワーヘッドルームの判定が生じ、2)PHR周期タイマ、再設定、SCellアクティブ化、PSCell追加、または、禁止タイマ満了によるPHRのトリガが、不適切に早期発生することがあり、3)PHR計算は、実際の送信を想定した場合に、パワーヘッドルームが不正確に計算されることがあり、または4)PHR送信がなかった場合でも、PHR禁止タイマが設定されることがある。
SCellアクティブ化/非アクティブ化手順問題で、LBT失敗が発生した場合、SCell上でスケジュールすべきULまたはDLデータがある場合に、SCellを非アクティブ化して、SCell非アクティブ化タイマが満了することがある。
間欠受信手順の問題で、LBT失敗が発生した場合、ススケジュールすべきULまたはDLデータがある場合に、PDCCH受信を停止して、オンデュレーションタイマまたは非アクティブタイマが満了することがある。
スケジューリング要求手順の問題で、LBT失敗が発生した場合、1)失敗したSR送信はランダムアクセス手順を開始せず、2)SR送信がなかった場合でも、SR禁止タイマが設定されることがあり、3)SR送信を成功させるために必要な十分な数のSR送信を許容することなく、SR送信カウンタが最大送信数に達することがあり、または、4)SR送信がない場合でも、SR保留がクリアされることがある。
バッファステータス報告手順問題で、LBT失敗が発生した場合、UL-SCHリソースが利用可能な場合、BSRは送信されないことがあり、SRはトリガされない。
論理チャネルの優先順位付け手順の問題で、LBT失敗が発生した場合、MAC PDUは、後続のグラントで送信できないことがあり、その結果、ユーザデータおよび制御シグナリングが損失する。
UEおよびNBのMAC手順の協調問題で、LBT失敗が発生した場合、UEは、適切なアクションのためにNBに認識される必要があるMAC手順を達成するアクションを実行することがある。さらに、NBは、UEの挙動とは無関係なアクションを実行し得る。
前述の例の問題を考慮して、不適切なアクションを実行せず、意図しない結果が回避されるように、LBT失敗を考慮し得る既存のMAC手順の修正または新しいMAC手順の作成が存在し得る。問題をどのように対処し得るかの概要を以下に示す。
図1は、NR-U LBT MAC手順のための例示的なシステムを示す。ステップ111において、UE101は、基地局102からUE101へのチャネルアクセスに関する情報を取得する。情報は、基地局102からシグナリングされるダウンリンク情報であり得る。ステップ112において、UE101は、基地局102へのアップリンクチャネルアクセス(例えば、アップリンク情報)に関する情報を検出し得る。アップリンク情報は、リッスンビフォートーク(LBT)動作または他の動作(例えば、3GPP TS 36.213 V14.8.0セクション15内の動作)を行うことによって検出され得る。ステップ113において、ステップ111またはステップ112の情報(例えば、アップリンク/ダウンリンク情報)に基づいて、MAC手順の動作を達成し得る。MAC手順は、本明細書に開示されているように、特に(例えば、PHR、BSR、BFD)、LBTR121(例えば、図10)、DRX122(例えば、図6)、BWP動作123(例えば、図2)、またはランダムアクセス124(例えば、図3)、スケジューリング要求125(例えば、図7)を含み得る。本明細書では、アップリンクまたはダウンリンクチャネルアクセス情報を上記のステップで使用し得ることが意図されている。
図2~図10は、NR-U LBT MAC手順に関連付けられた例示的な方法を示し、本明細書でより詳細に記載される。
図2は、帯域幅部分(BWP)動作手順のための例示的な方法を示す。例えば、ステップ131では、1つ以上のLBT失敗(例えば、アップリンク/ダウンリンクLBT失敗の閾値数)が検出される。ステップ132において、ステップ131で検出された失敗に基づいて、BWP非アクティブタイマを延長し得る。スケジュールすべきULまたはDLデータが存在し得るので、初期またはデフォルトBWPへの切り替えが回避され得るように、非アクティブタイマを延長し得る。ステップ133において、ステップ131で検出された失敗に基づいて、代替帯域幅部分に切り替える。
図3は、ランダムアクセス手順のための例示的な方法を示す。例えば、ステップ141において、1つ以上のLBT失敗(例えば、アップリンク/ダウンリンクLBT失敗の閾値数)が検出される。ステップ141で検出された失敗に基づいて、UE101はステップ142、143、144または145を実行し得る。ステップ142において、ランダムアクセス応答ウィンドウを延長し得る。ステップ142は、ランダムアクセス応答のための十分な数の送信機会を許容し得る。ステップ143において、プリアンブル送信カウンタはインクリメントされないことがある。ステップ143は、プリアンブル送信を成功させるために十分な数のプリアンブル送信を許容し得る。ステップ144において、競合解決タイマは延長され得、これは、MSG3送信に応答して十分な数のPDCCH送信機会を許容し得る。ステップ145において、パワーランピングを増加させないようにし得、これは、適切な電力設定を維持するのに役立ち得る。ステップ146において、RA問題が上位層に示され、RA手順が不成功であると見なし得る。ステップ147において、代替帯域幅部分への切り替えがあり得る。本明細書では、ステップ142からステップ147のうちの1つ以上が、ステップ141に基づいて生じ得ることが意図されている。
図4は、パワーヘッドルーム報告手順のための例示的な方法を示す。例えば、ステップ151において、1つ以上のLBT失敗(例えば、アップリンク/ダウンリンクLBT失敗の閾値数)が検出される。ステップ151で検出された失敗に基づいて、UE101はステップ152、153、154、155、156、157または158を実行し得る。ステップ152において、UE101は、PHRが計算されたときを基地局102(例えば、ノードB)に示し得る。ステップ153において、UE101は、PHR計算時に送信されたものを基地局102に示し得る。ステップ154において、UE101は、LBT失敗が発生したときを基地局102に示し得る。ステップ155において、UE101は、PHR送信に遅延があったことを基地局102に示し得る。ステップ156において、PHR周期タイマ、再設定、SCellアクティブ化、PSCell追加、または禁止タイマ満了によるPHRトリガリングが遅延し得る。ステップ157において、PHR計算は、損失または遅延した送信を考慮に入れてもよい。ステップ158において、PHR禁止タイマが設定されないか、または遅延し得る。
図5は、SCellアクティブ化/非アクティブ化手順のための例示的な方法を示す。例えば、ステップ161において、1つ以上のLBT失敗(例えば、アップリンク/ダウンリンクLBT失敗の閾値数)が検出される。ステップ161に基づいて、ステップ162において、SCell非アクティブ化タイマは延長され得、これは、SCell上での追加のULまたはDLデータスケジューリング機会を許容し得る。
図6は、間欠受信手順のための例示的な方法を示す。例えば、ステップ171において、1つ以上のLBT失敗(例えば、アップリンク/ダウンリンクLBT失敗の閾値数)が検出される。ステップ171に基づいて、オンデュレーションまたは非アクティブタイマは延長され得、これは追加のULまたはDLデータスケジューリング機会を許容し得る。ステップ173において、DRXショートサイクルタイマが適用され得る。ステップ174において、オンデュレーションまたは非アクティブタイマは、MCOT、CWSまたはCCAと整合され得る。ステップ175において、DRX設定が調整され得る。本明細書では、ステップ172からステップ175のうちの1つ以上が、ステップ171に基づいて生じ得ることが意図されている。
図7は、スケジューリング要求手順のための例示的な方法を示す。例えば、ステップ181において、1つ以上のLBT失敗(例えば、アップリンク/ダウンリンクLBT失敗の閾値数)が検出される。ステップ181で検出された失敗に基づいて、UE101はステップ182、183、184または185を実行し得る。ステップ182において、ランダムアクセス応答ウィンドウが開始され得る。ステップ183において、SR禁止タイマが設定されないか、または禁止タイマの設定が遅延し得る。ステップ184において、SR送信カウンタは、SR送信を成功させるために必要な十分な数のSR送信を許容するために、インクリメントされないことがある。ステップ185において、SR保留がクリアされないか、またはSR保留のクリアが遅延し得る。ステップ186において、代替帯域幅部分への切り替えがあり得る。本明細書では、ステップ182からステップ186のうちの1つ以上が、ステップ181に基づいて生じ得ることが意図されている。
図8は、バッファステータス報告手順のための例示的な方法を示す。例えば、ステップ191において、1つ以上のLBT失敗(例えば、アップリンク/ダウンリンクLBT失敗の閾値数)が検出される。ステップ192に基づいて、UL-SCHリソースが利用可能であっても、SRがトリガされ得る。
図9は、論理チャネル優先順位付け手順のための例示的な方法を示す。例えば、ステップ201では、1つ以上のLBT失敗(例えば、アップリンク/ダウンリンクLBT失敗の閾値数)が検出される。ステップ201で検出された失敗に基づいて、UE101はステップ202または203を実行し得る。ステップ202において、MAC PDUは構築されないことがある。ステップ203において、MAC PDUは、再フォーマットされ得、これは、後続のグラントで送信可能にし得る。
図10は、UE101がLBTの失敗または成功情報を基地局102に報告するための例示的な方法を示し、これは、UE101と基地局MAC手順との協調を改善することを可能にし得る。例えば、ステップ211において、1つ以上のLBT失敗(例えば、アップリンク/ダウンリンクLBT失敗の閾値数)が検出される。ステップ211に基づいて、UE101は、LBT失敗を報告するか、またはどの手順がどのように影響を受けるかを報告し得る。ステップ213において、報告は、設定された期間内のLBT成功/失敗統計を含む。ステップ214において、報告は、タイミング情報、CCA、MCOT、またはCWSを含む。ステップ215において、送信禁止タイマは、報告の頻度を最小にするように設定される。本明細書では、ステップ212からステップ215のうちの1つ以上が、ステップ181に基づいて生じ得ることが意図されている。
図2~図10は、NR-U LBT MAC手順に関連付けられた例示的な方法を示す。複数のNR-U LBT MAC手順を、以下でより詳細に記載する。
(MACへのNR-U LBT動作の影響)
開示された主題は、全体的なMAC動作および多数の特定のMAC手順に適用され得る。これらのMAC手順は、帯域幅部分(BWP)動作、ランダムアクセス(Random Access:RA)、パワーヘッドルーム報告(PHR)、SCellアクティブ化および非アクティブ化、論理チャネル優先順位付け(Logical Channel Prioritization:LCP)、間欠受信(Discontinuous Reception:DRX)、スケジューリング要求(SR)、バッファステータス報告(Buffer Status Report:BSR)、ならびに場合により新しいLBT MAC手順などを含み得る。
LBT失敗により、これらのMAC手順に不要で意図しない影響をもたらす可能性がある。LBT失敗または成功の認識があれば、これらのMAC手順は、LBTを必要としないライセンス周波数帯における動作と同様に、および同様の性能で、動作することができる。第1のMAC手順(例えば、ランダムアクセス)で開示され得るステップ(例えば、アクション)は、第2のMAC手順(例えば、BWPオペレーション)に適用可能であり得ることが意図されている。したがって、ステップは一般に、特定のMAC手順に限定されない。
(ULおよびDLの両方のLBT失敗に関する一般的な考慮事項)
MAC手順への影響に関しては、ULまたはDLにおいてLBT失敗が考慮されることがある。MAC手順および手順内の特定のアクションによって、ULおよびDLのLBT失敗の両方が考慮されることがあり、または、ULのみもしくはDLのみのLBT失敗が考慮されることがある。さらに、LBT表示がMACにどのように提供されるか、およびどの情報が提供されるかは、ULおよびDLによって異なることがある。
UL LBT動作の場合、PHY層はMACに、LBT成功または失敗を示し得る。UL LBT成功もしくは失敗の表示は、UL送信に関連付けられてもよく、またはUL LBT手順は、UL送信とは独立して実行されてもよい。各UL LBT成功または失敗の表示は、1つ以上のMAC手順と関連付けられ得る。
DL LBT動作の場合、NBはUEにDL LBT成功または失敗をシグナリングし得る。DL LBTの成功もしくは失敗の表示は、DL送信に関連付けられてもよく、またはDL LBT手順は、DL送信とは独立して実行されてもよい。各DL LBT成功または失敗の表示は、1つ以上のMAC手順と関連付けられ得る。
MAC手順、および手順内の特定のアクションによっては、関連する送信がない場合でもLBTを実行するために必要な場合がある。現在のMAC手順では、チャネルへの常時アクセスが存在し、送信の停止またはブロッキングがないことを前提としているため、これが必要な場合がある。例えば、UEがMAC手順においてダウンリンク割り当てまたはアップリンクグラントを検出しない場合、ダウンリンクまたはアップリンクにおいて送信のためにスケジュールすべきデータが存在しないという仮定があり得る。しかし、LBT失敗によってブロックされているかまたは遅延している、送信のためにスケジュールすべきデータが存在することがある。この場合、MAC手順は、意図しない結果または望ましくない結果をもたらし得るアクションを実行し得る。
本開示において、全体的なMAC動作または特定のMAC手順についてLBT失敗または成功が言及される場合、アップリンクLBTまたはダウンリンクLBTの両方が考慮され得る。MAC手順および手順内の特定のアクションによって、ULおよびDLのLBT失敗の両方が考慮されるか、または、ULのみもしくはDLのみのLBT失敗が考慮される。
LBT失敗および成功の両方を、MACにシグナリングする、または示す必要はないことに留意すべきである。LBT失敗の表示がない場合は成功と解釈され得、成功の表示がない場合は失敗と解釈され得る。PHY層からのUL LBTの表示はLBT失敗のみを示し得、NBからのDL LBT表示はLBT成功のみを示し得る。
LBT成功または失敗の表示は、既知の状況で周期的に提供されることもあり、またはMAC手順によって実行される特定のアクションによってトリガされる場合もある。DL LBTの成功または失敗は、NBによって周期的にシグナリングされ得、UL LBTの成功または失敗は、特定のMAC手順の動作に応じてPHY層によって示され得る。周期的な表示は、MAC手順により駆動されるオンデマンド表示により増大されることがあり、およびその逆もあることに留意されたい。
LBTの成功または失敗の表示は、特定のLBT手順の動作に関するものであることもあり、または表示は、既知の期間にわたる2つ以上のLBT手順の動作に関する情報を提供することもある。期間は、最後の報告以降の期間であり得る。UL LBT表示は、特定のLBT手順の動作に起因することがあり、DL LBT表示は、一定期間の複数(例えば、閾値数)のLBT動作に関する情報を提供し得る。
LBTの成功または失敗の表示は、LBTが実行されるキャリアおよびBWP(単数または複数)に関する情報を提供し得る。アップリンクまたはダウンリンクLBTの成功または失敗の表示に加えて、さらなるLBT手順情報がMAC手順に提供されてもよい。MAC手順では、ダウンリンクおよびアップリンクの送信機会が考慮される。これらのMAC手順を適切に動作させるためには、アップリンクおよびダウンリンクで送信を実行できる期間または実行できない期間を認識する必要がある場合がある。これを達成するために、LBTの成功もしくは失敗の表示に加えて、またはこれに含まれる、クリアチャネル評価(Clear Channel Assessment:CCA)の期間、選択された最大チャネル占有時間(Maximum Channel Occupancy Time:MCOT)、選択されたコンテンションウィンドウサイズ(Contention Window Size:CWS)、および他のタイミング情報がMACに提供され、ダウンリンクおよびアップリンク送信機会の適切な判定が可能になることが本明細書で開示される。MCOT、CWS、または他のタイミングは、選択されたタイミングを表すチャネルアクセス優先度クラス(Channel Access Priority Class:CAPC)または別のインデックスによって特定され得る。
(ダウンリンクLBT成功/失敗の表示)
DRXサイクルを実行するために、UEのDRXオンデュレーションの間、DL LBT成功の表示がNBからUEにシグナリングされ得ることが議論されてきた。これは、DRX非アクティブタイマが実行されている期間、および場合によりDRXアクティブ時間を構成する全ての期間を含むように延長されるべきである。例えば、UEがDRXオンデュレーション内にない間にランダムアクセスまたはスケジューリング要求手順が開始された場合、LBTが必要とされないときと同様の適切な動作および性能のために、LBT失敗の認識が必要な場合がある。
さらに、この問題に対処するより包括的な方法として、UEに既知の定期的な方法で連続的に送信されるDL LBT成功の表示を考慮して、DRXアクティブタイムの外で実行されるMAC手順がDL LBT成功および失敗の認識の恩恵を受けることができるようにする。
DL LBT成功の表示は、新しい明示的信号であってもよく、または暗黙的に検出されてもよい。例えば、DL LBT成功は、SSBまたはDRSの受信によって暗黙的に検出され得、新しい明示的信号は、新しいDCIフォーマット(例えば、個々のUEもしくはUEのグループにアドレス指定されるか、または全てのUEにブロードキャストされる)であり得る。
DRXオンデュレーションは一般的に異なるUEに対して時間がずれているため、DL LBT成功の表示を周期的に連続的にシグナリングしても、必ずしも複雑さが増したり、またはリソースの使用が増えたりするわけではない。周期性に応じて、シグナリングオーバーヘッドは低減され得る。
また、シグナリングDL LBT表示は、UE固有のものか、またはDRXオンデュレーションを共有するUEのグループに固有のものであってもよいことに留意すべきである。セル固有のDL LBT表示により、リソースのより効率的な使用、ならびに、より一貫したMAC手順の動作およびパフォーマンスをもたらすことができる。
また、LBT成功の表示は、単一の表示ではなくてもよいと見なされる。また、シグナリングされた情報は、最後のLBT成功の表示以降の期間の情報も提供し得る。また、シグナリングされた情報は、NBが、例えば、特定のチャネルまたはBWPへの、DLチャネルのアクセスをどれくらい有するかについての情報を提供し得る。この場合、MAC手順は、DL LBT成功または失敗の時間経過と共に連続的な認識を有し得、これにより、DL LBT失敗によるMAC手順への影響がより正確になり得る。
ダウンリンク成功の表示はまた、MAC手順が送信機会を正確に判定することができるようにするために、送信を行うことができるとき、および行うことができないときを特定するタイミング情報を提供し得る。これを達成するために、LBTの成功の表示に、クリアチャネル評価(CCA)の期間、選択された最大チャネル占有時間(MCOT)、選択されたコンテンションウィンドウサイズ(CWS)、もしくはダウンリンク送信機会の適切な判定を可能にするためにMACに提供される他のタイミング情報を追加されるか、または含められ得る。MCOT、CWS、または他のタイミング情報は、選択されたタイミングを表すチャネルアクセス優先度クラス(CAPC)または別のインデックスによって特定され得る。
(アップリンクLBT成功/失敗の表示)
NBがLBT失敗または成功ステータスをUEに示すことに加えて、UEは、UL LBT失敗または成功情報をNBに提供し得る。
本明細書に開示されているように、UE MAC手順への複数の潜在的な影響が存在し得る。特定のMAC手順にLBT失敗または成功がどのように影響したかをNBが認識することが必要な場合がある、複数の事例が存在し得る。例えば、DRXアクティブタイムまたはDRXサイクルが影響を受けた場合、NBはUEが適切にスケジュールされるように認識しなければならない。
LBT手順は、UL LBT失敗をNBに示す以上のことを行ってもよい。大量のUL LBT失敗が発生した後、他のアクションが実行されることがある。本明細書で示すように、既存のMAC手順の動作は、LBT失敗によって影響を受けることがある。新しいLBT手順は、LBT失敗を解決するための新しいアクションを実行する可能性を有する。例えば、チャネルアクセス優先度は、LBTが成功する可能性を高めるように調整され得る。
LBT失敗の総数がカウントされることがあり、これは、指定されたまたは設定された期間内であり得る。あるいは、LBT失敗カウンタ(Failure Counters:FC)は、連続LBT失敗をカウントし、LBT成功時にLBT FCをゼロにリセットしてもよい。LBT失敗がカウントされ得る期間は、時間のスライディングウィンドウであってもよい。LBT失敗カウンタが指定されたまたは設定された閾値を超過する場合、LBT状態は失敗したと見なされ得る。指定もしくは設定された数のLBT失敗を超過していない場合、または指定もしくは設定された数のLBT成功の表示が受信される場合、LBT状態は成功したと見なされ得る。MAC手順は、MAC手順に関連付けられた個々のLBT失敗をカウントするのではなく、LBT状態をチェックし得る。MAC手順では、LBT状態に従ってカウンタとタイマを調整し得る。例えば、MAC手順はカウンタおよびタイマを延長し得、またはLBT状態に応じてタイマおよびカウンタが最大閾値に達したと見なし得る。LBT状態は、より高い層に示されることもある。例えば、RRC手順に影響を与える。
UL LBTの成功または失敗の情報を提供するために、新しいMAC LBT報告(LBT Report:LBTR)手順が定義され得る。LBTR MAC CEは、以前のUL LBT結果に関する履歴情報を提供し得る。これは、報告が生成されたときに対して、特定の期間にわたることがある。例えば、最後のLBTR MAC CEが送信されてからの期間であり得る。MAC CEは、どのMAC手順(単数または複数)が影響を受けたか、またはいつLBT失敗が発生したかに関する情報を提供する場合があり、それによって、NBは、どの手順(単数または複数)が影響を受けたかを相関させようと試み得る。LBTR MAC CEはまた、例えば、BWP LBTが失敗する、およびBWP LBTが成功した場合のLBT結果に、BWP情報を含んでもよい。RRCは、UE内に、LBTR報告期間を設定してもよい。
あるいは、UL物理制御シグナリングが、UL LBT失敗または成功の表示を提供してもよい。これは、スケジュールされた、または新しいULシグナリングの場合、PUCCHで伝送されるか、またはPUSCHにピギーバックされ得る。周期的なULシグナリングの受信の欠如は、UE LBT失敗と解釈されることがある。これは、PUCCHまたは新しいULシグナリングであり得る。新しいULシグナリングは、NB受信が既知の物理的リソースおよび既知の時間に発生するように設定されなければならないことがある。
アップリンクLBT成功および失敗の表示はまた、MAC手順が送信機会を正確に判定することができるようにするために、送信を行うことができるとき、および行うことができないときを特定するタイミング情報を提供し得る。これを達成するために、LBT成功もしくは失敗の表示に加えて、またはこれに含まれる、クリアチャネル評価(CCA)の期間、選択された最大チャネル占有時間(MCOT)、選択されたコンテンションウィンドウサイズ(CWS)、または他のタイミング情報がMACに提供され、アップリンク送信機会の適切な判定が可能になることが提案されている。MCOT、CWS、または他のタイミングは、選択されたタイミングを表すチャネルアクセス優先度クラス(CAPC)または別のインデックスによって特定され得る。
(MACタイマおよびカウンタへのLBTの影響)
LBT失敗により、送信機会が損失する場合がある。また送信機会の損失により、送信の成功を達成するためのより長い時間にもつながる。MAC手順は、手順の失敗を宣言する前に、送信機会の量および完了するまでの時間を考慮する。LBTが必要な場合にMAC手順を適切に実行するためには、送信機会の数、および場合によっては手順が正常に完了するまでの期間は、LBT失敗を考慮する必要がある。
既存のMAC手順では、MAC PDUがPHY層に与えられるとき、またはPHYアップリンク制御情報(例えば、SR)を送信するためにPHYに命令が与えられるとき、PDUもしくはPHYアップリンク制御情報が送信されると仮定する。特定のMAC手順に関連付けられたMAC CEが構築され、MAC PDUに多重化されるとき、このMAC CEが送信されると仮定され得る。特定のMAC手順に関連付けられたMAC CEまたはPHYアップリンク制御情報が送信され得る周波数を制限するために、MAC CEが構築され、MAC PDUがPHY層に与えられるとき、またはPHYアップリンク制御情報を送信するためにPHYに命令が与えられるとき、禁止タイマが設定され得る。MAC CEまたはPHYのアップリンク制御情報が送信され得る頻度を適切に制御し、必要なときに送信されることを確実するために、これらの禁止タイマの設定はまた、LBTの失敗を考慮してもよい。
処理MAC手順のシーケンスもまた、考慮され得る。既存の手順は、PHY層によってLBTが実行される前に、MAC手順が実行されるときに、カウンタおよびタイマをインクリメントし得る。既存のMAC手順への影響に関しては、複数の方法を考慮し得るが、これは、以下に関連してもよい。1)MACがPHY層カウンタからLBT失敗の表示を受信し、送信失敗を考慮してタイマが調整される場合、2)LBTが成功してタイマおよびカウンタが動作する場合、または、3)最初のMAC手順が実行されてから、または最初に設定されてから、カウンタ(単数または複数)もしくはタイマ(単数または複数)がそれらの最大閾値に達するまでの期間に、LBT失敗が記録される。
MACがPHY層カウンタからLBT失敗の表示を受信すると、送信失敗を考慮するようにカウンタおよびタイマが調整される。MAC手順が実行されたときにインクリメントされたカウンタは、手順が実行される前に設定されたものから変更されないようにデクリメントされ得る。これは、タイマの場合は、多少複雑になり得る。最適には、手順の最大時間は、LBTの失敗の期間を考慮すべきではない。LBT失敗が発生したときのMACタイマの作用については、異なるMAC手順にタイマがどのように使用されるかによって、次のような複数の選択肢がある。a)LBT失敗に関連付けられたMAC手順が実行されたときから、MAC手順を実行する次の機会までの期間をタイマから減算するか、もしくは最大時間閾値に加算する(タイマが満了するとき)、b)LBT失敗表示の受信時にタイマを停止し、MAC手順を実行する次の機会に再起動する、c)LBT失敗表示を受けてタイマを再起動する、または、d)LBT失敗に関連付けられたMAC手順のタイマを設定したとき(起動または再起動)から、MAC手順のタイマを設定する次の機会までの期間を、タイマから減算するか、もしくは最大時間閾値に加算する(タイマが満了するとき)。
このアプローチに関する1つの懸念は、MAC手順が実行された時間と、MAC手順関連付けられたLBT失敗表示カウンタ(単数または複数)またはタイマ(単数または複数)の受信との間が最大値に達したときに、何が起こるかである。この問題に対処する1つの方法は、タイマまたはカウンタがその最大値に達したときに、MACが前の送信に対するLBT表示を待っているか否かをチェックし、LBT表示が成功したと判定された後にタイマまたはカウンタの満了に関連付けられたアクションのみを呼び出すことである。
LBTが成功すると、タイマおよびカウンタが作用する。この方法では、MAC手順が実行されるとき、カウンタ(単数または複数)およびタイマ(単数または複数)は作用されない。LBTの成功表示時にカウンタがインクリメントされ、タイマがチェックまたは調整される。このアプローチの問題の1つは、LBTの成功表示時にタイマまたはカウンタがそれらの最大閾値に達した場合であり、これは、MAC手順が異なるように実行されたことを意味する。この状況に対処するには、いくつかの選択肢がある。MAC手順を実行するときに、タイマおよびカウンタは、手順実行時にタイマおよびカウンタが手順に従って調整されていた場合、それらの最大閾値に達していたか否かをチェックされ得、この場合、MAC手順は、カウンタまたはタイマがそれらの最大閾値に達していたかのようにアクションを実行し得る。
LBT失敗は、最初のMAC手順が実行されたとき、または最初に設定されたときから、ポイントカウンタ(単数または複数)またはタイマ(単数または複数)がそれらの最大閾値に達するまでの期間に記録され得る。タイマまたはカウンタが最大閾値に達すると、LBT失敗の記録がチェックされ、LBT失敗が発生した場合、手順はLBT失敗を考慮してタイマおよびカウンタを調整する。これを達成するには、以下の(a)または(b)のような複数の選択肢があり得る。(a)最大閾値に達したときに実行されるアクションがこの時点で実行されないように、LBT失敗の数またはLBT失敗の期間に応じて、タイマおよびカウンタの最大閾値が調整される、または、(b)最大閾値に達したときに実行されるアクションがこの時点で実行されないように、失敗の数およびLBT失敗の期間に応じて、タイマおよびカウンタが再起動される。
タイマおよびカウンタに影響を及ぼすLBT失敗により、受け入れられない遅延(例えば、閾値に達する)が発生するか、またはMAC手順が際限なく停止することがある。MAC手順カウンタおよびタイマが決して最大閾値に達しないことがある。したがって、開示されたMAC手順の変更は、連続的なまたは相当量のLBT失敗の可能性を考慮に入れ得る。この場合、MAC手順は、各MAC手順が適切に実行されるように、時間の最大延長またはカウンタの最大延長を考慮してもよい。例えば、MAC手順カウンタ(MAC Procedure Counter:MAC PC)およびMAC手順タイマ(MAC Procedure Timer:MAC PT)の延長を制限することは、次の方法で対処し得る。1)MAC手順LBT失敗カウンタ(LBT Failure Counter:LBT FC)、MAC PCおよびMAC PT延長カウンタ(Extension Counter:EC)、またはMAC PCおよびMAC PT延長最大閾値(Extended Maximum Threshold:EMT)。
MAC手順LBT失敗カウンタ(LBT FC)、LBT FCは、LBT失敗の総数をカウントし得、これは、指定されたまたは設定された期間内であり得る。あるいは、LBT FCは連続LBT失敗をカウントしてもよく、LBTが成功するとLBT FCはゼロにリセットされる。LBT FC期間は、MAC手順が完了するまでに許容される時間、または時間のスライディングウィンドウであり得る。特定のMAC手順では、2つ以上のLBT FCを使用してもよい。MAC手順が独立したアクションを並列に実行する場合、各手順はLBT FCを有してもよい。LBT FCには、最大値が指定されているか、または設定されている場合がある。LBT FCが最大カウントに達すると、MAC手順のLBT失敗時に、MAC PCまたはMAC PTは延長されなくなる。あるいは、LBT FCが最大カウントに達すると、MAC手順はMAC PCまたはMAC PTが最大値に達したかのようにアクションを実行する。これにより、MAC手順が失敗したと見なされ得る。
MAC PCおよびMAC PT延長カウンタ(EC)、LBT失敗により、MAC PCまたはMAC PTの最大閾値が延長される。延長の基準は、指定されたまたは設定された期間内の、指定されたまたは設定されたLBT失敗の数であり得る。例えば、MAC PTの最大閾値あってもよい。ECは、MAC PCまたはMAC PT延長の総数をカウントすることがあり、これは、指定されたまたは設定された期間内であり得る。あるいは、ECは、MAC PCまたはMAC PT延長を連続してカウントしてもよい。EC期間は、MAC手順が完了するまでに許容される時間、または時間のスライディングウィンドウであり得る。特定のMAC手順では、2つ以上のECを使用してもよい。MAC手順が独立したアクションを並列に実行する場合、各手順はECを有してもよい。ECは、指定された、または設定された最大値を有し得る。ECが最大カウントに達すると、MAC手順のLBT失敗時に、MAC PCまたはMAC PTは延長されなくなる。あるいは、ECが最大カウントに達すると、MAC手順はMAC PCまたはMAC PTが最大値に達したかのようにアクションを実行し得る。これにより、MAC手順が失敗したと見なされ得る。
MAC PCおよびMAC PT延長最大閾値(EMT)、LBT失敗により、MAC PCまたはMAC PTの最大閾値が延長され得る。MAC PCまたはMAC PTの最大閾値は、各LBT失敗時に、または指定されたもしくは設定された期間内の指定されたもしくは設定された数のLBT失敗時に、延長され得る。例えば、期間は、現在のMAC PTの最大閾値あってもよい。MAC PCまたはMAC PTの最大閾値は、指定されたまたは設定された連続数のLBT失敗時に延長され得る。MAC PCまたはMAC PTが指定されたまたは設定されたEMTに到達すると、MAC PCまたはMAC PTの最大閾値は延長されなくなり得る。これにより、MAC手順が失敗したと見なし得る。
MAC手順はまた、手順が実行される頻度を制御するために使用されるタイマを有してもよい。これらのタイマは、禁止タイマとしてとして知られ得る。いくつかのMAC手順が実行されると、禁止タイマは、その手順が再び実行されることが許される最も早い時間を設定する。MAC手順は現在のところ、手順が実行されるときにこれらのタイマを設定する。これに対処するために、複数の方法またはシステムが使用され得る。例えば、1)禁止タイマは、手順の実行時に設定されなくてもよく、LBT成功または失敗によって設定されたりされなかったりし得る。MAC手順に関連付けられた送信のLBT成功時のみ、禁止タイマを設定すべきである。LBT手順が成功するまでに時間がかかることがある。この場合、禁止タイマの開始は、MAC手順が実行されたときに対して遅延し得る。これは、MAC手順が実行される頻度が適切に制限されることを確実にするために必要な場合がある。または、2)MAC手順の実行時に設定され得る禁止タイマは、MAC手順に関連付けられた送信に対するLBT失敗表示が受信された場合にクリアされる。LBT手順によって送信が遅延する場合、禁止タイマは、MAC手順が実行されてからLBT成功が判定されるまでの時間を考慮するように延長され得る。
(スケジューリングおよび送信機会の損失)
MAC手順はまた、ダウンリンク割り当ておよびアップリンクグラントも考慮され得る。LBT失敗によって、ダウンリンク割り当ておよびアップリンクグラントが損失することがある。NBがLBT失敗を判定した場合、PDCCHスケジューリング機会は損失し得る。また、PDCCHスケジューリングを受信しているにも関わらず、UEがLBT失敗と判定した場合、アップリンク送信機会は損失する。
設定されたモニタリング期間内にダウンリンク割り当てまたはアップリンクグラントを受信しないことがある場合、複数のMAC手順がアクションを実行する。LBT失敗またはLBT成功は、ダウンリンク割り当ておよびアップリンクグラントを受信しないことのMAC手順基準に考慮され得る。アップリンクまたはダウンリンクLBTの成功、失敗に加えて、さらなるLBT手順情報がMAC手順に提供されてもよい。LBTの成功もしくは失敗の表示に加えて、またはこれに含まれる、クリアチャネル評価(CCA)の期間、選択された最大チャネル占有時間(MCOT)、選択されたコンテンションウィンドウサイズ(CWS)、または他のタイミング情報がMACに提供され、ダウンリンクおよびアップリンク送信機会の適切な判定が可能になる。MCOT、CWS、または他のタイミングは、選択されたタイミングを表すチャネルアクセス優先度クラス(CAPC)または別のインデックスによって特定され得る。
設定されたモニタリング期間中に、ダウンリンク割り当てもしくはアップリンクグラントを受信し得ない場合、LBT失敗が検出される場合、またはLBT成功が検出されない場合は、複数のオプションが考慮され得る。
・モニタリング期間中にLBT成功が検出されなかった場合は、MAC手順によるアクションは実行されないことがある。
・モニタリング期間内に、LBT成功または連続LBT成功検出の設定された最小閾値に到達しない場合、MAC手順によるアクションは実行されないことがある。
・モニタリング期間中にLBT失敗が検出された場合、MAC手順によるアクションは実行されないことがある。
・モニタリング期間内に、LBT失敗または連続LBT失敗の設定された最大閾値に達した場合は、MAC手順によるアクションは実行されないことがある。
・アップリンクまたはダウンリンク送信機会の数もしくは期間は、CCA、MCOT、CWS、または他のタイミング情報からより正確に判定され得る。
MAC手順によって実行されないアクションとは、設定されたモニタリング期間中にダウンリンク割り当てまたはアップリンクグラントが受信されない場合に、現在指定されているMAC手順によって行われていた可能性のあるアクションである。例えば、
・BWP非アクティブタイマの実行中にLBT失敗が検出された場合、またはLBT成功が検出されなかった場合は、この期間中にダウンリンク割り当てまたはアップリンクグラントが受信されなかった場合でも、初期またはデフォルトBWPへのBWP切り替えは実行されない。
・その間にDRXアクティブタイムLBT失敗が検出された場合、またはLBT成功が検出されなかった場合は、この期間にダウンリンク割り当てまたはアップリンクグラントが受信されなかった場合でも、DRX非アクティブがリセットされ得る。
LBT失敗によりアップリンク送信ができない場合も、MAC手順を考慮する必要があり得る。MAC手順への影響は、LBT失敗によってPDCCHスケジューリング機会が損失した場合と同じである。MAC手順は、アップリンクグラントが受信されない場合、または送信可能なデータに対してアップリンクグランドが受け入れられない場合(例えば、LCP制限)に、LBTによるUL送信失敗を、現在実行されているのと同じであると見なし得る。例えば、LBT失敗後のバックオフ期間中に、MAC手順は、アップリンクグラントが受信されない場合、または、送信可能なデータに対してアップリンクグラントが受け入れられない場合(例えば、LCP制限)、現在のように振る舞い得る。
従来のMAC手順は、MAC PDUがPHY層に提供されるとき、それが送信されると仮定し得る。LBTを実行する場合は、必ずしもそうとは限らない。したがって、MAC PDU送信を参照するMAC手順では、送信がLBT成功または失敗を考慮していることを明確にするべきである。これは、MAC手順内のLBT成功を参照するか、またはMAC PDU送信基準にLBT成功が含まれることを明確にすることによって達成され得る。
MAC PDUの多重化およびアセンブリが再実行されたときに、トリガが再評価され、報告された値が再計算されるように、MAC CEは回復して保存されるか、またはこれらのMAC CEをトリガしたイベントが復元され得る。
(特定のMAC手順へのNR-U LBTの影響)
(特定のMAC手順へのNR-U LBTの影響)
新しいLBT MAC手順が導入され得る。この手順は、LBTの失敗または成功をNBに通知するために使用され得る。本明細書に記載されているように、UE MAC手順への複数の可能性のある影響が存在し得る。多くの場合、NBは適切な動作のためにこれらのMAC手順への影響を認識することが必要な場合がある。
LBT失敗によって影響を受ける各UE MAC手順は、それぞれのMAC手順に対するUEとNB間の協調を維持するために、NBへの効果をシグナリングする可能性がある。しかし、これには、多くのMAC手順にさらなる複雑さを導入する必要があり得る。
例示的な方法は、NBがLBT情報を考慮し、LBT動作によってこれらの手順の変更された振る舞いを実現することにより、他のMAC手順に対するその振る舞いを調整できるように、NBにLBT状態(例えば、成功または失敗)を示す新しい個別のMAC手順を定義することである。
したがって、UE PHY層のLBT成功または失敗表示がMACに提供される場合がある。PHY層は、MAC層とPHY層との間でシグナリングされるプリミティブの量を制限するために、何らかの前処理を行うことが可能である。新しいLBT MAC手順では、これらのLBT表示を統合して、リッスンビフォートーク報告(LBTR)MAC制御要素(Control Element:CE)を生成し得、これにより、一定期間のLBT失敗または成功に関する情報を提供し得る。UE PHY層は、LBT成功または失敗表示に加えて、LBTタイミング情報をMAC層に提供してもよい。例えば、LBTタイミング情報は、CCA期間を含み、MCOTまたはCWS期間を選択し得る。
LBTRは、ULおよびDLのLBT失敗を別々に提供し得る。UL LBT失敗はNBにとって未知であることがあり、MAC手順の協調を維持するためにシグナリングする必要がある。しかし、UEが認識しているDL LBT失敗もNBにとって有用である可能性がある。なぜなら、UEにシグナリングされるか、または別の方法でUEによって検出されるDL LBT失敗がUEによって実現されたとNBが想定できないことがあるからである。UEがNB DL LBT失敗もしくは成功表示を逃したか、または受信に失敗した可能性がある。
LBTR手順は、LBTRを送信する場合につながる手順を開始するために1つ以上のトリガを必要とすることがある。トリガには、以下の1つ以上の方法が含まれ得る。第1の方法では、閾値に達するLBT失敗が、トリガとなり得る。RRCが設定したLBT失敗閾値が存在し得る。この閾値は、既知の期間にわたるLBT失敗の閾値数、または連続LBT失敗の閾値数であってもよい。報告の緊急度は、サポートされるトラフィックのタイプに依存することがあるため、これらのパラメータが設定可能である必要があり得る。第2の方法では、トリガは、他のMAC手順に対するある種の影響が、適切な動作のためにNBによって認識される必要があるその手順の動作変化をもたらすときであり得る。例えば、アクティブタイムまたはDRXサイクルに影響するDRX動作の変更である。この場合、MAC DRX手順がLBTRをトリガする。第3の方法では、トリガは、RRCが設定した周期的なLBTRに基づき得る。第4の方法では、トリガは、LBTRの頻度を制限するために導入されるLBTR禁止タイマに基づき得る。
LBTR手順は、設定されたLBTRモニタリング期間にわたってLBT失敗または成功をカウントし得る。例えば、
・LBTRモニタリング期間内、LBT失敗カウントが、設定されたLBT失敗カウントより大きい場合、LBTRがトリガされ得る。
・LBTRモニタリング期間内、LBT成功カウントが、設定されたLBT成功最小値未満の場合、LBTRがトリガされ得る。
設定されたLBTRモニタリング期間にわたって、LBTR手順は、連続LBT失敗または成功をカウントし得る。
・LBTRモニタリング期間内、連続LBT失敗カウントが、設定されたLBT失敗カウントより大きい場合、LBTRがトリガされ得る。
・LBTRモニタリング期間内、連続LBT成功カウントが、設定された連続LBT成功最小値未満の場合、LBTRがトリガされ得る。
他のMAC手順がLBTRをトリガする場合、これは、LBTR保留表示を設定することによってであり得る。LBTR保留表示は、後でMAC PDU多重化アセンブリ中にチェックされ、LBTR MAC CEが構築されることを確認する。
LBTRには、以下の情報が含まれ得る。
・最後のLBTR以降のLBT失敗または成功のカウント
・最後のLBTR以降、LBT失敗または連続LBT失敗が、設定されたLBT失敗の最大閾値を超えた回数
・最後のLBTR以降、LBT成功カウントまたは連続LBT成功カウントが、設定された連続LBT成功最小値未満の回数
・UL LBT失敗に加えて、UEによって検出されたDL LBT失敗も報告されることがある
・LBTRをトリガしたMAC手順
・LBTR PDUがいつ構築されるかに関連したタイムスタンプ。
・CCA、MCOT、またはCWS情報
PHY層またはRRC層によって同様の動作が提供されてもよく、PHY層またはRRC層シグナリングを使用して同様の情報をNBに伝達してもよいことに留意すべきである。
RRCは、UE内に、LBTR MAC CEに指定された論理チャネルにマッピングされたチャネルアクセス優先度クラスの優先度を設定してもよい。あるいは、アクセス優先度クラスを最も優先度の高いチャネルアクセス優先度クラスとして指定してもよい。LBTR手順はまた、一般的なLBT状態判定手順を含んでもよく、または独立したLBT状態手順がLBTRおよび他のMAC手順によって利用されてもよい。この方法は、各MAC手順に導入される複雑さを最小限にする。例えば、各MAC手順がその手順に影響を及ぼすLBT失敗をカウントするのではなく、LBT状態がチェックされるだけである。
LBT失敗の総数がカウントされることがあり、これは、指定されたまたは設定された期間内であり得る。あるいは、LBT FCは連続LBT失敗をカウントしてもよく、LBTが成功するとLBT FCはゼロにリセットされる。LBT失敗がカウントされ得る期間は、時間のスライディングウィンドウであってもよい。LBT失敗カウンタが指定されたまたは設定された閾値を超過する場合、LBT状態は失敗したと見なされる。指定もしくは設定された数のLBT失敗が受信されなかった場合、または指定もしくは設定された数のLBT成功の表示が受信される場合、LBT状態は成功したと見なされる。MAC手順は、MAC手順に関連付けられた個々のLBT失敗をカウントするのではなく、LBT状態をチェックすることがある。MAC手順では、LBT状態に従ってカウンタおよびタイマを調整し得る。例えば、MAC手順はカウンタおよびタイマを延長し得、またはLBT状態に応じてタイマおよびカウンタが最大閾値に達したと見なし得る。LBT状態は、より高い層に示されることもある。例えば、RRC手順を行う。
(BWP動作手順)
BWP動作手順の以下の修正は、NR-UにおけるLBT動作の影響を考慮に入れてもよい。
LBT失敗により、BWP非アクティブタイマの期間中にダウンリンク割り当ておよびアップリンクグラントをブロックすることがある。この場合、BWPをデフォルトまたは初期BWP(単数または複数)への切り替えを行うことは不適切であり得る。
BWP非アクティブタイマが動作している間にLBT失敗と判定された場合、アクティブなDL BWPに関連付けられたBWP非アクティブタイマは延長されるべきである。これは、LBT失敗によってダウンリンク割り当ておよびアップリンクグラントが損失し得る場合に、デフォルトまたは初期BWPへのBWP切り替えが実行されないことを確実にするために、必要な場合がある。デフォルトまたは初期BWPへのBWP切り替えは、BWP非アクティビティタイマの実行中に、実際には送信するデータがない場合にのみ実行されるべきである。本明細書における実施例は、MAC仕様3GPP TS 38.321、(NR)、メディアアクセス制御(MAC)プロトコル仕様、V15.2.0を参照してもよい(また、本明細書では[2]として参照される)。例示的な修正の多くは、本明細書において下線が引かれている。例えば、MAC仕様を以下のように修正してもよい。
bwp-InactivityTimerが設定されている場合、MACエンティティは、アクティブ化された各サービングセルに対して、以下であるものとする。
1>defaultDownlinkBWPが設定されていて、アクティブなDL BWPがdefaultDownlinkBWPによって示されたBWPでない場合、または、
1>defaultDownlinkBWPが設定されておらず、アクティブなDL BWPがinitialDownlinkBWPでない場合、
2>ダウンリンクの割り当てもしくはアップリンクグラントを示すC-RNTIもしくはCS-RNTI宛てのPDCCHが、アクティブなBWPで受信された場合、または、
2>ダウンリンクの割り当てもしくはアップリンクグラントを示すC-RNTIもしくはCS-RNTI宛てのPDCCHが、アクティブなBWPに対して受信された場合、または、
2>MAC PDUが、設定されたアップリンクグラントで送信された場合もしくは設定されたダウンリンク割り当てで受信された場合、または、
2>アクティブなBWPでLBT失敗が検出された場合、
3>このサービングセルに関連付けられた現行のランダムアクセス手順がない場合、または、
3>C-RNTI宛てのこのPDCCHの受信時に、このサービングセルに関連付けられた現行のランダムアクセス手順が正常に完了した場合(例えば、[2]の5.1.4節および5.1.5節に関して規定されたとおり)、
4>アクティブなDL BWPに関連付けられたbwp-InactivityTimerを起動または再起動する。
この基準はまた、BWP非アクティブが実行されている間のLBT成功検出に基づいていてもよい。例えば、
bwp-InactivityTimerが設定されている場合、MACエンティティは、アクティブ化された各サービングセルに対して、以下であるものとする。
1>defaultDownlinkBWPが設定されていて、アクティブなDL BWPがdefaultDownlinkBWPによって示されたBWPでない場合、または、
1>defaultDownlinkBWPが設定されておらず、アクティブなDL BWPがinitialDownlinkBWPでない場合、
2>ダウンリンクの割り当てもしくはアップリンクグラントを示すC-RNTIもしくはCS-RNTI宛てのPDCCHが、アクティブなBWPで受信された場合、または、
2>ダウンリンクの割り当てもしくはアップリンクグラントを示すC-RNTIもしくはCS-RNTI宛てのPDCCHが、アクティブなBWPに対して受信された場合、または、
2>MAC PDUが、設定されたアップリンクグラントで送信された場合もしくは設定されたダウンリンク割り当てで受信された場合、または、
2>アクティブなBWPでLBT成功が検出されなかった場合、
3>このサービングセルに関連付けられた現行のランダムアクセス手順がない場合、または、
3>C-RNTI宛てのこのPDCCHの受信時に、このサービングセルに関連付けられた現行のランダムアクセス手順が正常に完了した場合(例えば、[2]の5.1.4節および5.1.5節に関して規定されたとおり)、
4>アクティブなDL BWPに関連付けられたbwp-InactivityTimerを起動または再起動する。
LBT失敗は、単一のインスタンスではないことがある。BWP非アクティブタイマが実行している間の、複数のLBT失敗または成功の検出であり得る。また、本明細書に示されるように、LBT失敗または成功は、アップリンクLBTまたはダウンリンクLBTの両方を参照する。
一定期間のLBT失敗もしくはLBT成功をカウントする、または一定期間の連続LBT失敗もしくは連続LBT成功をカウントするように手順を定義してもよい。LBT失敗もしくは連続LBT失敗が、設定された最大LBT失敗閾値を超えた場合、またはLBT成功もしくは連続LBT成功が、設定された最小LBT成功閾値未満であり得る場合にのみ、BWP非アクティブタイマが再起動される。例えば、MAC仕様を以下のように修正してもよい。
bwp-InactivityTimerが設定されている場合、MACエンティティは、アクティブ化された各サービングセルに対して、以下であるものとする。
1>defaultDownlinkBWPが設定されていて、アクティブなDL BWPがdefaultDownlinkBWPによって示されたBWPでない場合、または、
1>defaultDownlinkBWPが設定されておらず、アクティブなDL BWPがinitialDownlinkBWPでない場合、
2>ダウンリンクの割り当てもしくはアップリンクグラントを示すC-RNTIもしくはCS-RNTI宛てのPDCCHが、アクティブなBWPで受信された場合、または、
2>ダウンリンクの割り当てもしくはアップリンクグラントを示すC-RNTIもしくはCS-RNTI宛てのPDCCHが、アクティブなBWPに対して受信された場合、または、
2>MAC PDUが、設定されたアップリンクグラントで送信された場合もしくは設定されたダウンリンク割り当てで受信された場合、または、
2>LBT失敗カウントが、アクティブなBWPでLBT失敗閾値を超えた場合、
3>このサービングセルに関連付けられた現行のランダムアクセス手順がない場合、または、
3>C-RNTI宛てのこのPDCCHの受信時に、このサービングセルに関連付けられた現行のランダムアクセス手順が正常に完了した場合(例えば、[2]の5.1.4節および5.1.5節に関して規定されたとおり)、
4>アクティブなDL BWPに関連付けられたbwp-InactivityTimerを起動または再起動して、
4>LBT失敗カウントをリセットする。
上記の手順において、LBT失敗が検出されたとは、BWP非アクティブタイマが動作している期間、アクティブなDL BWP上でBWP切り替え用のPDCCHを受信したとき、または、アクティブなBWP上もしくはBWP用のアップリンクグラントのPDCCHを受信したとき、または設定されたグラントのためにMAC PDUを送信もしくは受信したときから、BWP非アクティブタイマが満了する時点までの期間に適用されることに留意すべきである。
BWP非アクティブタイマは、初期設定値とは異なる期間だけ延長され得る。BWP非アクティブタイマが延長される期間は、別の設定値であってもよく、または検出されたLBTの失敗もしくは判定された成功の量に応じた値であってもよい。
また、LBT失敗により、設定されたBWP間の切り替えがトリガされることがある。LBT失敗は、単一のインスタンスではないことがある。指定されたまたは設定された期間内の複数のLBT失敗または成功の検出であってもよい。また、本明細書に示されるように、LBT失敗または成功は、アップリンクLBTまたはダウンリンクLBTを参照することがある。
一定期間のLBT失敗もしくはLBT成功をカウントする、または一定期間の連続LBT失敗もしくは連続LBT成功をカウントするように手順を定義してもよい。LBT失敗もしくは連続LBT失敗が設定された最大LBT失敗閾値を超えた場合、またはLBT成功もしくは連続LBT成功が設定された最小LBT成功閾値未満である場合にのみ、アクティブなBWPは、別の設定されたアクティブなBWPに切り替えられる。
また、UEが初期もしくはデフォルトBWPに決して戻らないように、BPW非アクティブタイマを大幅に延長すること、またはLBT失敗により非アクティブタイマを無期限に延長することを回避するために必要な場合がある。その場合、BWP非アクティブタイマの再起動は、指定されたまたは設定された最大値に制限され得る。例えば、MAC仕様を以下のように修正してもよい。
1>アクティブなBWPで、BWP-Inactivity-LBT-Failure-Count>BWP-Inactivity-LBT Failure Thresholdである場合、および、
1>LBT-BWP-InactivityRestartCount<=LBT-BWP-Inactivity-Restart-Thresholdである場合、
2>BWP-Inactivity-LBT-Failure-Countを0に設定して、
2>LBT-BWP-InactivityRestartCountを1だけインクリメントして、
2>アクティブなDL BWPに関連付けられたbwp-InactivityTimerを起動または再起動する。
1>LBT失敗が検出された場合、
2>BWP-Inactivity-LBT-Failure-Countをインクリメントする。
LBT BWP非アクティブ再起動閾値を超えた場合、以下のアクションを実行してもよい。
1>LBT-BWP-InactivityRestartCount>LBT-BWP-Inactivity-Restart-Thresholdである場合、
2>デフォルトまたは初期BWPへのBWP切り替えが実行されて、
2>BWPを特定する表示が上位層に送信されて、
2>SCellが非アクティブ化される。
(ランダムアクセス手順)
(ランダムアクセス応答受信)
ランダムアクセス応答受信手順の以下の修正は、NR-UにおけるLBTの影響を考慮に入れてもよい。
RA応答ウィンドウが満了しても、プリアンブル送信以降にLBT失敗が検出された場合、RA応答ウィンドウを延長し得る。これは、NBがプリアンブル送信を受信していても、LBT失敗によりランダムアクセス応答が遅延している場合に必要になり得る。NBが送信機会を逃したことをUEが検出するとき、RA応答ウィンドウを延長し得る。
例えば、MAC仕様を以下のように修正してもよい。
1>RACH-ConfigCommonに設定されているra-ResponseWindowが満了し、送信されたPREAMBLE_INDEXに一致するランダムアクセスプリアンブル識別子を含むランダムアクセス応答を受信していない場合、
1>BeamFailureRecoveryConfigに設定されたra-ResponseWindowが満了した場合、およびC-RNTI宛てのPDCCHを受信していない場合、
2>LBT失敗が検出された場合、
3>MACエンティティによってビーム障害回復要求のための競合なしランダムアクセスプリアンブルが送信された場合、
4>BeamFailureRecoveryConfigに設定したra-ResponseWindowを再起動して、
4>ra-ResponseWindowが動作している間、C-RNTIで特定されるビーム障害回復要求に対する応答をSpCellのPDCCHで監視し、
3>さもなければ、
4>RACH-ConfigCommonに設定されたra-ResponseWindowを再起動して、
4>ra-ResponseWindowが実行されている間、RA-RNTIによって特定されるランダムアクセス応答(単数または複数)に対するSpCellのPDCCHを監視し、
2>さもなければ(LBT失敗は検出されず)、
3>ランダムアクセス応答の受信が成功しなかったと見なす。
上記の手順において、LBT失敗が検出されたとは、RA応答ウィンドウが動作している期間、プリアンブル送信から、プリアンブル送信後RA応答ウィンドウが最初に満了する時点までの期間、またはLBT検出によりRA競合解決タイマが満了して最後に再起動してから、次のra-ResponseWindowが満了するまでの期間に適用されることに留意すべきである。
あるいは、LBT失敗またはLBT成功をカウントするように手順を定義してもよい。LBT失敗が、設定された最大LBT失敗閾値を超えた場合、またはLBT成功が、設定された最小LBT成功閾値未満であり得る場合にのみ、RA応答ウィンドウが再起動される。
あるいは、RA応答ウィンドウは、BeamFailureRecoveryConfigまたはRACH-ConfigCommonに設定された値とは異なる期間だけ延長され得る。RA応答ウィンドウが延長される期間は、別の設定値であってもよく、または検出されたLBT失敗もしくは判定された成功の量に応じた値であってもよい。また、ランダムアクセス応答受信が成功しなかったとUEが決して判定しないように、LBTの失敗によるランダムアクセス応答を大幅に延長すること、または無期限に延長することを回避する必要がある場合もある。その場合、RA応答ウィンドウの再起動は、指定されたまたは設定された最大値に制限され得る。例えば、MAC仕様を以下のように修正してもよい。
1>RA-ResponseWindow-LBT-Failure-Count>RA-ResponseWindow-LBT-FailureThresholdである場合、および、
1>LBT-RA-ResponseWindowRestartCount<=LBT-RA-ResponseWindow-Restart-Thresholdである場合、
2>RA-ResponseWindow-LBT-Failure-Countを0に設定して、
2>LBT-RA-ResponseWindowRestartCountを1だけインクリメントして、
2>ra-ResponseWindowを起動または再起動する。
1>LBT失敗が検出された場合、
2>RA-ResponseWindow-LBT-Failure-Countをインクリメントする。
RA-ResponseWindow-LBT-FailureThresholdを超えた場合、以下のアクションを実行してもよい。
1>LBT-RA-ResponseWindowRestartCount>LBT-RA-ResponseWindow-Restart-Thresholdである場合、
2>ランダムアクセス応答の受信が成功しなかったと見なす。
以下に別の例を示す。LBTが失敗した場合、プリアンブル送信カウンタをインクリメントすべきではないと説明してきた。例えば、
1>RACH-ConfigCommonに設定されているra-ResponseWindowが満了した場合、および送信されたに一致するランダムアクセスプリアンブル識別子を含むランダムアクセス応答を受信していない場合、
1>BeamFailureRecoveryConfigに設定されたra-ResponseWindowが満了した場合、およびC-RNTI宛てのPDCCHを受信していない場合、
2>ランダムアクセス応答の受信が成功しなかったと見なし、
2>LBT失敗が検出されなかった場合、
3>PREAMBLE_TRANSMISSION_COUNTERを1だけインクリメントして、
3>PREAMBLE_TRANSMISSION_COUNTER=preambleTransMax+1である場合、
4>SpCellでランダムアクセスプリアンブルが送信された場合、
5>ランダムアクセスの問題を上位層に示し、
4>SI要求に対してこのランダムアクセス手順がトリガされた場合、
5>ランダムアクセス手順が不成功に終わったと見なし、
3>さもなければ、SCellでランダムアクセスプリアンブルが送信された場合、
4>ランダムアクセス手順が不成功に終わったと見なす。
プリアンブル送信カウンタは、LBT失敗の検出時にデクリメントされてもよい。例えば、
1>物理層に、選択されたPRACH、対応するRA-RNTI(利用可能な場合)、PREAMBLE_INDEX、および、PREAMBLE_RECEIVED_TARGET_POWERを使用して、ランダムアクセスプリアンブルを送信するように指示して、
1>LBT失敗が検出された場合、
2>PREAMBLE_TRANSMISSION_COUNTERを1だけデクリメントする。
上記の手順において、LBT失敗がプリアンブル送信に適用され得ることに留意すべきである。ランダムアクセス応答受信が成功しなかったとUEが判定しないように、LBT失敗によりプリアンブル送信カウンタを大幅にインクリメントしないこと、またはプリアンブル送信カウンタを無期限にインクリメントしないことを回避する試みがあるべきである。その場合、RA応答ウィンドウの再起動は、指定されたまたは設定された最大値に制限され得る。例えば、MAC仕様を以下のように修正してもよい。
1>RACH-ConfigCommonに設定されているra-ResponseWindowが満了した場合、および送信されたPREAMBLE_INDEXに一致するランダムアクセスプリアンブル識別子を含むランダムアクセス応答を受信していない場合、
1>BeamFailureRecoveryConfigに設定されたra-ResponseWindowが満了した場合、およびC-RNTI宛てのPDCCHを受信していない場合、
2>ランダムアクセス応答の受信が成功しなかったと見なし、
2>PreambleTransmissionLBT失敗が検出されなかった場合、または、
2>RA-PreambleTransmission-LBT-Failure-Count>RA-PreambleTransmission-LBT-FailureThresholdである場合、
3>PREAMBLE_TRANSMISSION_COUNTERを1だけインクリメントして、
3>PREAMBLE_TRANSMISSION_COUNTER=preambleTransMax+1である場合、
4>SpCellでランダムアクセスプリアンブルが送信された場合、
5>上位層にランダムアクセスの問題を示し、
4>SI要求に対してこのランダムアクセス手順がトリガされた場合、
5>ランダムアクセス手順が不成功に終わったと見なし、
3>さもなければ、SCellでランダムアクセスプリアンブルが送信された場合、
4>ランダムアクセス手順が不成功に終わったと見なす。
1>PreambleTransmission-LBT-Failureが検出された場合、
2>RA-PreambleTransmission-LBT-Failure-Countをインクリメントする。
RA-PreambleTransmission-LBT-FailureThresholdを超えた場合、以下のアクションを実行してもよい。1)上位層にランダムアクセスの問題を示す、または、2)ランダムアクセス手順が不成功に終わったと見なす。
あるいは、MAC仕様を以下のように修正してもよい。
1>PreambleTransmission-LBT-Failureが検出された場合、
2>RA-PreambleTransmission-LBT-Failure-Countをインクリメントして、
2>RA-PreambleTransmission-LBT-Failure-Count>RA-PreambleTransmission-LBT-FailureThresholdである場合、
3>SpCellでランダムアクセスプリアンブルが送信された場合、
4>上位層にランダムアクセスの問題を示し、
3>SI要求に対してこのランダムアクセス手順がトリガされた場合、
4>ランダムアクセス手順が不成功に終わったと見なし、
3>さもなければ、SCellでランダムアクセスプリアンブルが送信された場合、
4>ランダムアクセス手順が不成功に終わったと見なす。
(競合解決)
ランダムアクセス競合解決手順の以下の修正は、NR-UにおけるLBTの影響を考慮に入れてもよい。
RA競合解決が満了しても、プリアンブル送信以降にLBT失敗が検出された場合、RA競合解決を延長し得る。これは、NBがMSG3送信を受信していても、LBT失敗によりPDCCH送信が遅延しているために必要になり得る。NBがLBT失敗により送信機会を逃したことをUEが検出した場合、RA競合解決タイマを延長し得る。
例えば、MAC仕様を以下のように修正してもよい。
1>ra-ContentionResolutionTimerが満了した場合、
2>LBT失敗が検出された場合、
3>ra-ContentionResolutionTimerを起動し、HARQ再送信ごとにra-ContentionResolutionTimerを再起動して、
3>測定ギャップの発生の可能性に関わらず、ra-ContentionResolutionTimerが実行されている間、PDCCHを監視し、
2>さもなければ、
3>TEMPORARY_C-RNTIを破棄して、
3>競合解決が成功しなかったと見なす。
上記の手順において、LBT失敗が検出されたとは、RA競合解決タイマが動作している期間、MSG3送信から、MSG3送信後RA競合解決タイマが最初に満了する時点までの期間、またはLBT検出によりRA競合解決タイマが満了して最後に起動してから、次のRA競合解決タイマが満了するまでの期間に適用されることに留意すべきである。
あるいは、LBT失敗またはLBT成功をカウントするように手順を定義してもよい。LBT失敗が、設定された最大LBT失敗閾値を超えた場合、またはLBT成功が、設定された最小LBT成功閾値未満であり得る場合にのみ、RA競合解決が再起動される。
あるいは、RA競合解決タイマは、設定されたRA競合解決タイマとは異なる期間だけ延長されてもよい。RA競合解決タイマが延長される期間は、別の設定値であってもよく、または検出されたLBTの失敗もしくは判定された成功の量に応じた値であってもよい。また、競合解決が成功しなかったとUEが決して判定しないように、RA競合解決タイマを大幅に延長すること、またはLBT失敗によりRA競合解決タイマを無期限に延長することを回避する必要がある場合がある。その場合、RA競合解決タイマの再起動は、指定されたまたは設定された最大値に制限され得る。例えば、MAC仕様を以下のように修正してもよい。
1>RA-ContentionResolution-LBT-Failure-Count>RA-ContentionResolution-LBT-FailureThresholdである場合、および、
1>LBT-RA-ContentionResolutionTimerRestartCount<=LBT-RAContentionResolutionRestart-Thresholdである場合、
2>RA-ContentionResolution-LBT-Failure-Countを0に設定して、
2>LBT-RA-ContentionResolutionTimerRestartCountを1だけインクリメントして、
2>ra-ContentionResolutionTimerを起動し、HARQ再送信ごとにra-ContentionResolutionTimerを再起動して、
2>測定ギャップの発生の可能性に関わらず、ra-ContentionResolutionTimerが実行されている間、PDCCHを監視する。
1>LBT失敗が検出された場合、
2>RA-ContentionResolution-LBT-Failure-Countをインクリメントする。
RA-ContentionResolution-LBTRestartThresholdを超えた場合、以下のアクションを実行してもよい。
1>LBT-RA-ContentionResolutionTimerRestartCount>LBT-RA-ContentionResolutionRestart-Thresholdである場合、
2>ランダムアクセス応答の受信が成功しなかったと見なす。
(ランダムアクセスプリアンブル送信)
ランダムアクセスプリアンブル送信手順の以下の修正は、NR-UにおけるLBTの影響を考慮に入れる。
LBTが失敗した場合、プリアンブルパワーランピングカウンタをインクリメントすべきではないと説明してきた。例えば、
MACエンティティは、各ランダムアクセスプリアンブルに対して、以下であるものとする。
1>PREAMBLE_TRANSMISSION_COUNTERが1よりも大きい場合、および、
1>パワーランピングカウンタの一時停止の通知を下位層から受信していない場合、および、
1>選択されたSSBが変更されていない場合(すなわち、前回のランダムアクセスプリアンブル送信と同じ)、および、
1>LBT失敗が検出されなかった場合、
2>PREAMBLE_POWER_RAMPING_COUNTERを1だけインクリメントする。
プリアンブルパワーランピングカウンタは、LBT失敗の検出時にデクリメントされてもよい。例えば、
1>物理層に、選択されたPRACH、対応するRA-RNTI(利用可能な場合)、PREAMBLE_INDEX、およびPREAMBLE_RECEIVED_TARGET_POWERを使用して、ランダムアクセスプリアンブルを送信するように指示する。
2>LBT失敗が検出された場合、
2>PREAMBLE_POWER_RAMPING_COUNTERを1だけデクリメントする。
上記の手順において、LBT失敗がプリアンブル送信に適用され得ることに留意すべきである。
(パワーヘッドルーム報告)
PHR手順の以下の修正は、NR-UにおけるLBTの影響を考慮に入れる。
PHR MAC CEの送信がLBT失敗によってブロックされ、時間をおいて再送信される場合、PHRが計算されたときNBに通知するため、またはPHRが計算されたときの送信条件をNBに通知するために、追加のシグナリングが導入される。
NBがPHRを適切に処理するためには、PHRがどのような条件下で計算されたかをNBが認識するために必要な場合がある。
PHRは、定格UE最大送信電力と、アクティブ化されたサービングセルごとのUL-SCH送信またはSRS送信の推定電力との差について、および、定格UE最大電力と、SpCellおよびPUCCH SCell上のUL-SCHおよびPUCCH送信の推定電力との差についての情報も用いて計算する。
既存のPHRシグナリングは、UL-SCH送信が実送信または仮想送信に基づいていたか否か、およびPHRが計算されたときにPUCCHが送信されたか否かを特定する。UL-SCHが実送信されたものである場合、PHR計算時に何が送信されたかをNBが認識するために必要な場合がある。
アンライセンス周波数帯で動作しておらず、LBTが使用されていない場合、NBはPHRの計算がいつ行われたかを判定できる。NBはスケジュールされたものと受信したものを認識しているため、この時点でUL-SCHで何が送信されたかを認識することでPHRを解釈することができる。しかし、LBTが失敗し、LBTが成功するまで送信が遅延する場合、NBはPHRの計算時にUL-SCCHで何が送信されたかを判定することができない。
以下に、この問題に対処するための複数の方法を示す。第1の方法では、PHRの計算がいつ行われたのかをNBが判定できるような追加の表示をPHRに提供する。これは、最初のLBT失敗の時間に対するLBTによる遅延であってもよく、または絶対時間基準であってもよい。第2の方法では、UL-SCCHで何が送信されたかをNBに通知する追加情報をPHRと共に提供する。これは、UL-SCCH上で何が送信されたかを近似したインデックス付きの値であってもよく、またはPHR計算時の送信の物理的な詳細であってもよい。第3の方法では、PHRのためにLBTによって被った実効遅延をNBが判定し得るように、LBTの失敗または成功がNBに独立して示されてもよい。第4の方法では、PHRが計算されたときに使用されたグラント(例えば、アップリンクグラント)をNBに通知する追加情報をPHRと共に提供する。
PHRがどのように計算されたかをNBが認識することができる追加情報をNBが受信することが好ましいが、絶対に必要というわけではない。あるいは、実際のPHRが不正確な情報を提供している場合、NBは少なくとも認識し得る。これは、UEがNBにLBT失敗および成功示すことで、PHRを遅延させたLBT失敗があったことをNBが判定できるようにすることにより、実現され得る。
以下に別の例を示す。PHRのトリガ条件は、LBT失敗を考慮すべきである。利用可能なULリソース、PHR周期タイマ満了、PHR再設定、SCellアクティブ化、;およびPSCell追加のトリガ基準は、LBTが成功した場合にのみ考慮されるべきである。LBT基準の追加は、既存の各トリガに対して相互に排他的であり、したがって、既存の基準のサブセットにのみ影響を与え得る。
例えば(全てのトリガを考慮する場合)、MAC仕様は以下のように修正されてもよい。
以下のイベントのいずれかが発生した場合、パワーヘッドルームレポート(PHR)がトリガされるものとする。
・phr-ProhibitTimerが満了するか、または満了して、MACエンティティに新しい送信のためのULリソースがあり、この送信がLBT失敗によってブロックされていないときに、このMACエンティティにおけるPHRの最後の送信以降、パスロスの参照先として使用されるMACエンティティの少なくとも1つのアクティブ化されたサービングセルに対して、パスロスがphr-Tx-PowerFactorChange dBを超えて変化した、
注釈1 上記で評価された1つのセルのパスロス変動は、現在のパスロス参照で現時点で測定されたパスロスと、その時点で使用されていたパスロス参照でPHRの最後の送信時に測定されたパスロスとの間のものであり、その間にパスロス参照が変更されたか否かは関係がない。
・phr-PeriodicTimerが満了し、その後LBTが成功する、
・上位層によるパワーヘッドルーム報告機能の設定または再設定時に、LBTがその後成功し、その機能性を無効化するために使用されていない、
・設定されたアップリンクを有するMACエンティティのSCellをアクティブ化し、LBTがその後成功する、
・PSCellの追加(すなわち、PSCellが新たに追加または変更された場合)、およびLBTがその後成功する、
・phr-ProhibitTimerが満了するか、または満了し、MACエンティティが新しい送信のためのULリソースを有し、この送信がLBT失敗によってブロックされておらず、設定されたアップリンクを有するいずれかのMACエンティティのアクティブ化されたサービングセルのいずれかについて以下のことが当てはまる、
・このセルに送信のためのULリソースが割り当てられているか、またはPUCCH送信があり、このセルに対する電力管理(TS38.101[10]に規定されているようにP-MPRcによって許可されている)による必要な電力バックオフが、PHRの最後の送信以降、MACエンティティが、このセルに送信のためのULリソースが割り当てられていたか、またはPUCCH送信があったときに、phr-Tx-PowerFactorChange dBを超えて変化した。
これらの変更は、LBTが成功し、UEがチャネルにアクセスしたときにPHRが計算または送信されるようにするために必要な場合がある。
以下に別の例を示す。PHRの計算および送信は、LBTが成功した場合にのみ考慮されるべきである。
定格UE最大送信電力と、アクティブ化されたサービングセルごとのUL-SCH送信またはSRS送信の推定電力との差について、および、定格UE最大電力と、SpCellおよびPUCCH SCell上のUL-SCHおよびPUCCH送信の推定電力との差についての情報を用いた計算も、LBT成功時にのみ考慮されるべきである。
ULリソースがPHR MAC CEに適応できるか否かをチェックする場合、LBT成功を判定することも必要であり得る。利用可能なULリソースを有することは、PHR MAC CEの送信がLBTによりブロックされることには関係がない。
例えば、MAC仕様を以下のように修正してもよい。
MACエンティティが新しい送信のために割り当てられたULリソースを有し、LBT成功と判定された場合、MACエンティティは、
1>最後のMACリセット以降、新しい送信のために割り当てられた最初のULリソースである場合、
2>phr-PeriodicTimerを起動して、
1>パワーヘッドルーム報告手順により、少なくとも1つのPHRがトリガされ、キャンセルされていないと判定された場合、および、
1>割り当てられたULリソースが、論理チャネルの優先順位付けの結果、MACエンティティが送信するように構成されているPHRのためのMAC CEと、そのサブヘッダに適応できる場合、および、
1>LBT成功と判定され、
2>multiplePHRが設定されている場合、
3>任意のMACエンティティに関連付けられた、設定されたアップリンクを有する各アクティブ化されたサービングセルに対して、
4>対応するアップリンクキャリアに対するタイプ1またはタイプ3のパワーヘッドルームの値を取得して、
4>このMACエンティティが、このサービングセルでの送信のために割り当てられたULリソースを有し、LBT成功と判定された場合、または、
4>他方のMACエンティティ(設定されている場合)が、送信のために割り当てられたULリソースを有し、このサービングセルでLBT成功と判定され、上位層によりphr-ModeOtherCGが実数に設定されている場合、
5>物理層から対応するPCMAX,f,cフィールドの値を取得し、
3>phr-Type2SpCellが設定されている場合、
4>このMACエンティティのSpCellに対するタイプ2パワーヘッドルームの値を取得して、
4>物理層から対応するPCMAX,f,cフィールドの値を取得し、
3>phr-Type2OtherCellが設定されている場合、
4>その他のCGが設定されている場合、
5>他方のMACエンティティのSpCellに対するタイプ2パワーヘッドルームの値を取得して、
5>phr-ModeOtherCGが上位層によって実数に設定されている場合、
6>物理層から他方のMACエンティティのSpCellに対する対応するPCMAX,f,cフィールドの値を取得し、
4>さもなければ、PUCCH SCellが設定され、アクティブ化されている場合、
5>PUCCH SCellに対するタイプ2パワーヘッドルームの値を取得して
5>物理層から対応するPCMAX,f,cフィールドの値を取得し、
3>LBT成功と判定された場合、物理層から報告された値に基づいて、[2]の6.1.3.9節で定義されているように、設定されたServCellIndexおよびMACエンティティのPUCCH(単数または複数)に従ってPHR MAC CEを生成および送信するように、多重化およびアセンブリ手順に指示し、
2>さもなければ(すなわち、シングルエントリPHRフォーマットが使用されて)、
3>PCellの対応するアップリンクキャリアの物理層からタイプ1パワーヘッドルームの値を取得して、
3>物理層から対応するPCMAX,f,cフィールドの値を取得して。
3>LBT成功と判定された場合、物理層から報告された値に基づいて、[2]の6.1.3.8節で定義されているように、PHR MAC CE を生成および送信するように、多重化およびアセンブリ手順を指示し、
2>phr-PeriodicTimerを起動または再起動して、
2>phr-ProhibitTimerを起動または再起動して、
2>全てのトリガされたPHR(単数または複数)をキャンセルする。
上記の例示的なMAC固有の変更は、LBT成功の観点から記載されているが、例はLBT失敗なしの観点からも同様に表されてもよい。
この例では、変更は相互排他的であることに留意すべきである。開示された変更のサブセットのみが必要な場合がある。
以下に別の例を示す。さらに、MAC PHR CEを含む送信のLBT失敗の検出時、PHR禁止タイマを設定するべきではないか、または設定されていた場合はクリアするべきであることが開示されている。
物理層がMAC PHR CEを含むMAC PDUの送信を指示された場合、PHR禁止タイマは、MAC PDU送信のLBT成功の判定時にのみ起動または再起動されるべきである。例えば、MAC仕様を以下のように修正してもよい。
1>LBT成功と判定された場合、
2>phr-PeriodicTimerを起動または再起動して、
2>phr-ProhibitTimerを起動または再起動して、
2>全てのトリガされたPHR(単数または複数)をキャンセルする。
上記の例示的なMAC固有の変更は、LBT成功の観点から記載されているが、例はLBT失敗なしの観点からも表されてもよい。
あるいは、PHR禁止タイマまたはPHR周期タイマは、既存の手順で行われるように起動されてもよいが、LBT失敗と判定された場合には、PHR禁止タイマがクリアされてもよく、またはPHR周期タイマがLBT失敗による最後のリセット前の残りの値に、もしくは、例えば設定された時間値などの異なる時間値にリセットしてもよい。
この修正は、後続のPHR送信が遅延し得ないようにPHR禁止タイマが設定されないようにするか、または、PHRの送信がLBT失敗によってブロックされたときに周期的なPHRが遅延しないように、PHR周期タイマがリセットされないようにすることを確実にするために、必要な場合がある。
(SCellのアクティブ化/非アクティブ化)
SCellのアクティブ化/非アクティブ化手順の以下の修正は、NR-UにおけるLBTの影響を考慮に入れる。
SCell非アクティブ化タイマの実行中にLBT失敗が検出された場合、SCell非アクティブ化タイマが延長される。これは、意図しないSCell非アクティブ化を回避するために必要な場合がある。
LBT失敗により、NBがDL送信の機会を逃した(ダウンリンクの割り当て(単数または複数)が損失され得る)か、またはUL送信がブロックされ得る(MAC PDUが送信されない)ことをUEが検出すると、SCell非アクティブ化タイマが延長される。
これを達成する方法の、複数のオプションが存在し得る。
・LBT失敗の検出時に、SCell非アクティブ化タイマが延長または再起動される
・SCell非アクティブ化タイマの満了時にLBT失敗が検出された場合、SCell非アクティブ化タイマが延長または再起動される。
LBT失敗とは、LBT成功の欠如を意味する場合もあることに留意すべきである。例えば、UE PHY層がUE MACにLBT失敗を示すことがあり、またはNBがUE MACにLBT成功を示すことがある。
例えば、MAC仕様を以下のように修正してもよい。
1>さもなければ、SCellを非アクティブ化する、SCellアクティブ化/非アクティブ化MAC CEを受信した場合、または、
1>アクティブ化されたSCellに関連付けられたsCellDeactivationTimerが満了し、LBT失敗が検出されなかった場合、
2>TS 38.213で定義されているタイミングに従って、SCellを非アクティブ化して、
2>SCellに関連付けられたsCellDeactivationTimerを停止して、
2>SCellに関連付けられたbwp-InactivityTimerを停止して、
2>SCellに関連付けられた、任意の設定されたダウンリンク割り当て、および任意の設定されたアップリンクグラントのタイプ2をそれぞれクリアして、
2>SCellに関連付けられた、任意の設定されたアップリンクグラントのタイプ1を一時停止して、
2>SCellに関連付けられた全てのHARQバッファをフラッシュする。
1>アクティブ化されたSCellに関連付けられたsCellDeactivationTimerが満了し、LBT失敗が検出された場合、
2>SCellに関連付けられたsCellDeactivationTimerを再起動する。
上記の手順(単数または複数)において、LBT失敗が検出されたとは、SCell非アクティブ化タイマが動作している期間、SCell非アクティブ化から、もしくは設定されたアップリンクグラントで最後のMAC PDUが送信されたときから、もしくは設定されたダウンリンク割り当てでUEが最後に受信したときから、SCell非アクティブ化タイマが設定された後に最初に満了する時点までの期間、またはLBT検出によりSCell非アクティブ化タイマが満了して最後に起動してから、次のSCell非アクティブ化タイマが満了するまでの期間に適用されることに留意すべきである。
あるいは、SCellのLBT失敗検出時に、
1>LBT失敗が検出された場合、
2>SCellに関連付けられたsCellDeactivationTimerを再起動する。
あるいは、LBT失敗もしくはLBT成功、または連続LBT失敗もしくは連続LBT成功をカウントするように手順を定義してもよい。LBT失敗もしくは連続LBT失敗が、設定された最大LBT失敗閾値を超えた場合、またはLBT成功もしくは連続LBT成功が、設定された最小LBT成功閾値未満であり得る場合にのみ、SCell非アクティブ化タイマが再起動される。例えば、MAC仕様を以下のように修正してもよい。
1>ScellDeactLBT-Failure-Count>ScellDeactLBT-Failure-Thresholdである場合、
2>SCellに関連付けられたsCellDeactivationTimerを再起動して、
2>ScellDeactLBT-Failure-Countを0に設定する。
1>LBTの失敗が発生した場合、
2>ScellDeactLBT-Failure-Countをインクリメントする。
あるいは、SCell非アクティブ化タイマは、設定されたSCell非アクティブ化タイマとは異なる期間だけ延長され得る。SCell非アクティブ化タイマが延長される期間は、別の設定値であってもよく、または検出されたLBTの失敗もしくは判定された成功の量に応じた値であってもよい。また、UEが決して非アクティブ化されないように、SCell非アクティブ化タイマを大幅に延長すること、またはLBT失敗によりSCell非アクティブタイマを無期限に延長することを回避する必要がある場合もある。その場合、SCell非アクティブ化タイマの再起動は、指定されたまたは設定された最大値に制限され得る。例えば、MAC仕様を以下のように修正してもよい。
1>ScellDeact-LBT-Failure-Count>ScellDeact-LBT-FailureThresholdである場合、および、
1>LBT-ScellDeactTimerRestartCount<=LBT-ScellDeact-Restart-Thresholdである場合、
2>ScellDeact-LBT-Failure-Countを0に設定して、
2>LBT-ScellDeactTimerRestartCountを1だけインクリメントして、
2>SCellに関連付けられたsCellDeactivationTimerを再起動する。
1>LBT失敗が検出された場合、
2>ScellDeact-LBT-Failure-Countをインクリメントする。
ScellDeact-LBT-FailureThresholdを超えた場合、以下のアクションを実行してもよい。
1>LBT-ScellDeactTimerRestartCount<=LBT-ScellDeact-Restart-Thresholdである場合、
2>TS38.213[6]で定義されているタイミングに従って、SCellを非アクティブ化して、
2>SCellに関連付けられたsCellDeactivationTimerを停止して、
2>SCellに関連付けられたbwp-InactivityTimerを停止して、
2>SCellに関連付けられた、任意の設定されたダウンリンク割り当て、および任意の設定されたアップリンクグラントのタイプ2をそれぞれクリアして、
2>SCellに関連付けられた、任意の設定されたアップリンクグラントのタイプ1を一時停止して、
2>SCellに関連付けられた全てのHARQバッファをフラッシュする。
(間欠受信(DRX))
DRX手順の以下の修正は、NR-UにおけるLBTの影響を考慮に入れる。
ショートサイクルタイマが満了するときに、ショートDRXサイクルからロングDRXサイクルに移行することがある。この移行はLBT成功が検出された場合、またはLBT失敗が検出されなかった場合にのみ実行されるべきである。例えば、
1>drx-ShortCycleTimerが満了し、LBT成功が検出された場合、
1>ロングDRXサイクルを使用し、
1>さもなければ、
2>drx-ShortCycleTimerを起動または再起動する。
本明細書では、最大LBT失敗または最小LBT成功の設定閾値が開示されている。そして、LBT失敗またはLBT成功のカウントが閾値を超えた場合にのみ、UEはDRXショートサイクルを使用し続け得る。例えば、
1>drx-ShortCycleTimerが満了し、LBT成功カウンタが最小LBT成功閾値を超えた場合、
2>ロングDRXサイクルを使用し、
2>さもなければ、
2>drx-ShortCycleTimerを起動または再起動する。
あるいは、LBT失敗が検出された場合またはLBT成功が検出されなかった場合は、DRXアクティブタイムを延長する。これは、DRX非アクティブタイマを起動または再起動することによって実現され得る。また、DRX非アクティブタイマが満了時に、DRXショートサイクルタイマが起動または再起動されるため、これにより、DRXショートサイクルを継続して使用し得る。さらに、これにより、LBT失敗により損失したスケジューリング機会のために必要となる場合がある、さらなるPDCCH ULおよびDLのスケジューリング機会が可能となり得る。例えば、MAC仕様を以下のように修正してもよい。
3>PDCCHが新しい送信(DLまたはUL)を示す場合、
4>PDCCH受信終了後の最初のシンボルで、drx-InactivityTimerを起動または再起動して、
3>LBT失敗が検出された場合、
4>drx-InactivityTimerを起動または再起動する。
好ましくは、DRX非アクティブタイマの起動または再起動は、一定期間内にLBT失敗の検出またはLBT成功の非検出が複数回発生したことに依存する。期間は、オンデュレーションの期間または非アクティブタイマの期間、オンデュレーションおよび非アクティブタイマが実行されている時間の組み合わせであり得る。例えば、
1>LBT成功が検出されなかった場合に、drx-onDurationTimerが満了するとき、
2>drx-InactivityTimerを起動または再起動して、
1>LBT成功が検出されなかった場合に、drx-InactivityTimerが満了するとき、
2>drx-InactivityTimerを起動または再起動する。
LBT失敗は、単一のインスタンスではないことがある。複数のLBT失敗または成功の検出であってもよい。DRX手順は、PDDCHのUE受信に影響を及ぼす一連のLBT失敗の後にのみ開始されてもよい。
LBT失敗もしくはLBT成功をカウントする、または連続LBT失もしくは連続LBT成功をカウントするように手順を定義してもよい。LBT失敗もしくは連続LBT失敗が、設定された最大LBT失敗閾値を超えた場合、またはLBT成功もしくは連続LBT成功が、設定された最小LBT成功閾値未満であり得る場合にのみ、DRX非アクティブタイマが再起動される。例えば、
1>LBT成功カウントがLBT最小成功閾値未満の場合に、オンデュレーションタイマが満了するとき、
2>drx-InactivityTimerを起動または再起動する。
また、UEがDRXに決して入ることがないように、DRX非アクティブタイマを大幅に延長すること、またはLBT失敗によりDRX非アクティブタイマを無期限に延長することを回避する必要がある場合もある。その場合、DRX非アクティブタイマの再起動は、指定されたまたは設定された最大値に制限され得る。例えば、MAC仕様を以下のように修正してもよい。
1>DRX-Inactivity-LBT-Failure-Count>DRX-Inactivity-LBT-FailureThresholdである場合、および、
1>DRX-Inactivity-TimerRestartCount<=DRX-Inactivity-Restart-Thresholdである場合、
2>DRX-Inactivity-LBT-Failure-Countを0に設定して、
2>DRX-Inactivity-TimerRestartCountを1だけインクリメントして、
2>drx-InactivityTimerを起動または再起動し、
1>LBT失敗が検出された場合、
2>DRX-Inactivity-LBT-Failure-Countをインクリメントする。
DRX-Inactivity-LBTRestartThresholdを超えた場合、以下のアクションを実行してもよい。
1>DRX-Inactivity-TimerRestartCount>DRX-Inactivity-Restart-Thresholdである場合
2>ショートDRXサイクルが設定されている場合、
3>drx-InactivityTimerの満了後の最初のシンボル、またはDRXコマンドMAC CEの受信終了後の最初のシンボルで、drx-ShortCycleTimerを起動または再起動して、
3>ショートDRXサイクルを使用し、
2>さもなければ、
3>ロングDRXサイクルを使用する。
LBT失敗が発生したときに非アクティブタイムを起動または再起動することによってDRXアクティブタイムを延長することは、設定可能なオプションであるか、または現在アクティブなサービスに依存しているべきである。例えば、URLLCサービスがサポートされ得る場合、LBT失敗が発生したときにスケジューリング機会を維持することがより重要になる。
あるいは、DRXアクティブタイムの延長時間は、設定されたDRXインアクティビティタイマの期間と異なっていてもよい。別の設定値であってもよく、または、好ましくは現在のDRXアクティブタイム期間中に検出されたLBT失敗の量に対する期間であってもよい。
別の例では、DRX手順を動的に適応させることによって、LBT動作によって生じるDRXの非効率性に対処する方法があり得る。UEが各DRXサイクルをウェイクアップするときに、DRX設定をLBT動作に応じて動的に調整してもよい。例えば、DRXオンデュレーション、インアクティビティ、またはDRXサイクルを周期的に調整してもよい。これは、各DRXサイクルであってもよい。
送信前にNBはクリアチャネル評価(CCA)を判定し、チャネルアクセス優先度クラス(CAPC)を選択する。CAPCには、最大チャネル占有時間(MCOT)およびコンテンションウィンドウサイズ(CWS)が選択される。MCOT期間中は送信を行うことができる一方で、CCAおよびCWSの期間中は送信を行うことができない。送信タイミングを動的に調整し得るため、UEのDRX動作を動的に調整して、NBによって判定された送信機会によりよく一致させ得る。
これを達成するために、各DRXサイクルにNBからシグナリングされるダウンリンクLBT成功表示に加えて、またはこれに含まれる、CCA期間、選択されたMCOTもしくはCWS、または他のタイミング情報がMACに提供され得、ダウンリンクおよびアップリンクの送信機会をより正確に判定することが可能になる。MCOT、CWS、または他のタイミングは、選択されたタイミングを表すチャネルアクセス優先度クラス(CAPC)または別のインデックスによって特定され得る。
LBTタイミング情報の受信に基づいて、UE DRX手順は、MCOT期間と整合するようにアクティブタイムを動的に調整し、CWSおよび場合によりCCA期間にDRXを適用する。
例えば、各DRXサイクルの開始時に、NBによって選択されたMCOTにオンデュレーションを設定してもよい。同様に、非アクティブタイマは、選択されたMCOTと整合するように設定されてもよい。
あるいは、UEは、CWSおよび場合によりCCA期間にDRXに入ってもよい。例えば、アクティブタイムには、MCOT期間と重なる、またはCWSおよび場合によりCCA期間と重ならないオンデュレーションおよび非アクティブタイム期間のみが含まれる。例えば、MAC仕様を以下のように修正してもよい。
DRXサイクルが設定されている場合、アクティブタイムには、以下の時間が含まれる。
・drx-onDurationTimer、またはdrx-InactivityTimer、またはdrx-RetransmissionTimerDL、またはdrx-RetransmissionTimerUL、またはra-ContentionResolutionTimer(5.1.5節に記載されているように)が実行されている間、および、
・drx-MCOT-Timerが実行されている間。
またはその代わりに、
DRXサイクルが設定されている場合、アクティブタイムには、以下の時間が含まれる。
・drx-onDurationTimer、またはdrx-InactivityTimer、またはdrx-RetransmissionTimerDL、またはdrx-RetransmissionTimerUL、またはra-ContentionResolutionTimer(5.1.5節に記載されているように)が実行されている間、および、
・drx-CWS-Timerが実行されていない間。
(スケジューリング要求)
SR手順の以下の修正は、NR-UにおけるLBTの影響を考慮に入れる。
保留中のSRがあり、場合により一定時間にわたってLBT失敗が判定された場合、ランダムアクセス手順が開始され、保留中のSRがキャンセルされるべきである。これは、LBT失敗によりPUCCHリソースが使用不能になった場合に必要となることがある。この場合、RA手順が試行され、この手順が失敗した場合は、問題を解決するために無線リンク失敗が宣言される。例えば、MAC仕様を以下のように修正してもよい。
少なくとも1つのSRが保留されている限り、MACエンティティは、各保留中のSRに対して、以下であるものとする。
1>MACエンティティが、保留中のSRに対して妥当なPUCCHリソースを設定していない場合、または、
1>LBT失敗が検出された場合、
2>SpCellでランダムアクセス手順(例えば、[2]の5.1節を参照)を開始し、保留中のSRをキャンセルする。
PUCCHリソースの妥当性はまた、LBT成功またはLBT失敗に対して定義されてもよい。例えば、MAC仕様を以下のように修正してもよい。
LBT失敗が判定されていないSR送信機会時にアクティブなBWP上のPUCCHリソースのみが妥当と見なされる。
少なくとも1つのSRが保留されている限り、MACエンティティは、各保留中のSRに対して、以下であるものとする。
1>MACエンティティが、保留中のSRに対して妥当なPUCCHリソースを設定していない場合、
2>SpCellでランダムアクセス手順(例えば、[2]の5.1節を参照)を開始し、保留中のSRをキャンセルする。
上記の例は、「LBT失敗なし」の検出の観点から表されることもあるが、「LBT成功」の検出で表されることもある。LBT失敗またはLBT成功は、単一のインスタンスではないことがある。複数のLBT失敗または成功の検出であってもよい。RA手順は、PUCCHのSR送信に影響を及ぼす一連のLBT失敗後にのみ開始されてもよい。
LBT失敗もしくはLBT成功をカウントする、または連続LBT失敗もしくは連続LBT成功をカウントするように手順を定義してもよい。LBT失敗もしくは連続LBT失敗が、設定された最大LBT失敗閾値を超えた場合、またはLBT成功もしくは連続LBT成功が、設定された最小LBT成功閾値未満であり得る場合にのみ、ランダムアクセス手順が開始される。
以下に別の例を示す。物理層がSRを送信するように指示されると、SR送信に対するLBT成功の判定時にのみ、SR禁止タイマが起動され、SRカウンタがインクリメントされ得る。例えば、MAC仕様を以下のように修正してもよい。
2>MACエンティティが、設定されたSRのための妥当なPUCCHリソース上でSR送信機会を有する場合、および、
2>SR送信機会時に、sr-ProhibitTimerが実行されていない場合、および
2>SR送信機会のPUCCHリソースが、測定ギャップと重複していない場合、および、
2>SR送信時のPUCCHリソースが、UL-SCHリソースと重複していない場合、
3>SR_COUNTER<sr-TransMaxである場合、
4>物理層に、SRのための1つの妥当なPUCCHリソース上でSRをシグナリングするように指示して、
LBT成功と判定された場合、
5>sr-ProhibitTimerを起動して、
5>SR_COUNTERを1だけインクリメントする。
あるいは、既存の手順で行われるように、SR禁止タイマが起動され、SRカウンタがインクリメントされてもよいが、LBT失敗と判定された場合には、禁止タイマが停止されてもよく、SRカウンタがデクリメントされてもよい。
この修正は、SRカウンタがSR Trans Maxに到達しないことで、SR送信がLBT失敗によってブロックされたときに、物理リソースを解放してRA手順を開始するように、後続のSR送信を遅延させるSR禁止タイマが設定されないことを確実にするために、必要な場合がある。
また、SR送信手順が成功しなかったとUEが決して判定しないように、LBT失敗によりSR送信カウンタを大幅にインクリメントしないこと、またはSR送信カウンタを無期限にインクリメントしないことを回避する必要がある場合もある。SR送信カウントをインクリメントさせないことは、指定されたまたは設定された最大値に制限され得る。例えば、MAC仕様を以下のように修正してもよい。
2>SR LBT失敗が検出されなかった場合、または、
2>SR-Transmission-LBT-Failure-Count>SR-Transmission-LBT-FailureThresholdである場合、
3>SR_COUNTERを1だけインクリメントして、
3>
2>SRTransmission-LBT-Failureが検出された場合、
2>SRTransmission-LBT-Failure-Countをインクリメントする。
RA-PreambleTransmission-LBT-FailureThresholdを超えた場合、以下のアクションを実行してもよいし、MAC仕様を以下のように修正してもよい。
2>SR-Transmission-LBT-Failureが検出された場合、
2>SR-Transmission-LBT-Failure-Countをインクリメントして、
2>SR-Transmission-LBT-Failure-Count>STransmission-LBT-FailureThresholdである場合、
以下に別の例を示す。BSR送信に対するLBT成功が判定された場合にのみ、保留中のSR(単数または複数)がキャンセルされ得、SR禁止タイマが停止され得る。これは、LBT失敗により現在のSRが送信されないときに、後続のSR送信を遅延させる禁止タイマが設定されないことを確実にするために、必要な場合がある。
例えば、MAC PDU送信に対してLBT成功が判定され、このPDUが、MAC PDUアセンブリ前にBSR([2]の5.4.5項を参照)をトリガした最後のイベントまでの(および含まれている)バッファ状態を有するBSR MAC CEを含む場合、MAC PDUアセンブリ前にトリガされた保留中のSRは全てキャンセルされるものとし、それぞれのsr-ProhibitTimerは停止されるものとする。
上記の例は、LBT成功検出の代わりに、LBT失敗検出の観点から以下のように表されてもよい。MAC PDU送信に対してLBT失敗が判定されず、このPDUが、MAC PDUアセンブリ前にBSR([2]の5.4.5項を参照)をトリガした最後のイベントまでの(および含まれている)バッファ状態を有するBSR MAC CEを含む場合、MAC PDUアセンブリ前にトリガされた保留中のSRは全てキャンセルされるものとし、それぞれのsr-ProhibitTimerは停止されるものとする。
あるいは、BSRを含むMAC PDUがPHY層に提供されると、既存の手順で行われるように、保留中のSR(単数または複数)がキャンセルされてもよく、禁止タイマが停止されてもよいが、LBTの失敗(または、LBT成功なしと同様な意味合いで)が判定された場合には、保留中のSR(単数または複数)が復元され、禁止タイマが再起動されてもよい。
(バッファステータス報告)
BSR手順の以下の修正は、NR-UにおけるLBTの影響を考慮に入れる。
規則的なBSRがトリガされ、送信に利用可能なUL-SCHリソースがあり得るが、LBT失敗によって送信がブロックされている場合、SRがトリガされ得る。LBT失敗により利用可能なグラントが損失した場合、後続のグラントがBSRの送信に利用可能になるようにするために新しいSRが必要になることがあるため、これが必要になる場合がある。例えば、MAC仕様を以下のように修正してもよい。
2>規則的なBSRがトリガされ、logicalChannelSR-DelayTimerが実行されていない場合、
3>新しい送信に利用可能なUL-SCHリソースがない場合、または、
3>MACエンティティに設定されたアップリンクグラント(単数または複数)が設定されており、上位層によって論理チャネルSRマスキング(logicalChannelSR-Mask)が設定されている論理チャネルに対して規則的なBSRがトリガされなかった場合、または、
3>新しい送信に利用可能なUL-SCHリソースが、BSR(単数または複数)をトリガした論理チャネル(単数または複数)に設定されたLCPマッピング制限([2]の5.4.3.1節を参照)を満たさない場合、または、
3>送信に利用可能なUL-SCHリソースがあり、この送信に対してLBT失敗が検出された場合、
4>スケジューリング要求をトリガする。
上記の修正テキストは、LBT失敗の観点から記載されているが、LBT成功なしの観点からも表されてもよい。
LBT失敗またはLBT成功は、単一のインスタンスではないことがある。複数のLBT失敗または成功の検出であってもよい。SRは、MAC BSR CE送信に影響を及ぼす一連のLBT失敗後にのみトリガされてもよい。
また、LBT失敗もしくはLBT成功をカウントする、または連続LBT失敗もしくは連続LBT成功をカウントするように手順を定義してもよい。LBT失敗もしくは連続LBT失敗が設定された最大LBT失敗閾値を超えた場合、またはLBT成功もしくは連続LBT成功が設定された最小LBT成功閾値未満であり得る場合にのみ、SRがトリガされる。
BSR MAC CEの送信がLBT失敗によってブロックされ、時間をおいて再送信される場合、BSRがいつ計算されたかをNBに通知するため、またはPHRが計算されたときの送信条件をNBに通知するために、追加のシグナリングが導入される。
NBがBSRを適切に処理するためには、BSRがいつ計算されたかをNBが認識することが必要な場合がある。
アンライセンス周波数帯で動作しておらず、LBTが使用されていない場合、NBはBSRの内容がいつ判定されたかを概ね取得し得る。NBはスケジュールされたものおよび受信されたもの、ならびにBSRの規則を認識しているため、BSRを適切に解釈し得る。しかし、LBTが失敗し、LBTが成功するまで送信が遅延すると、NBは古くなったBSRまたは不正確なBSRを受信することがあり、場合により、UEによって必要とされるよりも多いリソース割り当て、もしくはUEによって必要とされるよりも少ないリソース、または送信遅延およびQoS保証のペナルティにつながる。以下に、この問題に対処するための複数の方法を示す。第1の方法では、BSRの計算がいつ構築されたのかをNBが判定できるような追加の表示をBSRに提供する。これは、最初のLBT失敗の時間に対するLBTによる遅延であってもよく、または絶対時間基準であってもよい。第2の方法では、BSRのためのLBTによって被った実効遅延をNBが判定し得るように、LBTの失敗または成功がNBに独立して示されてもよい。第3の方法では、PHRが計算されたときに使用されたグラント(例えば、アップリンクグラント)をNBに通知する追加情報をPHRと共に提供する。
BSRがいつ構築されたかをNBが認識することができる追加情報を受信することが好ましいが、必要というわけではない。あるいは、BSRが不正確な情報を提供している場合、NBは少なくとも認識しなければならない。これは、UEがNBにLBT失敗および成功を示すことで、BSRを遅延させたLBT失敗があったことをNBが判定できるようにすることにより、実現され得る。
以下に別の例を示す。BSRのトリガ条件は、LBT失敗を考慮すべきである。新しいデータが利用可能になり、現在指定されている規則的なBSRトリガ基準、パディングBSRトリガ条件、BSR再送信タイマ満了、BSR周期タイマ満了のトリガ基準を満たすには、LBTが成功した場合にのみ考慮するべきである。LBT基準の追加は、既存の各トリガに対して相互に排他的であり、したがって、既存の基準のサブセットにのみ影響を与え得る。
例えば(全てのトリガを考慮する場合)、MAC仕様は以下のように修正されてもよい。
以下のイベントのいずれかが発生した場合、BSRがトリガされるものとする。
・MACエンティティが、LCGに属する論理チャネルで利用可能な新しいULデータを有し、および、
・新しいULデータが、いずれかのLCGに属する利用可能なULデータを含むどの論理チャネルの優先度よりも高い優先度を持つ論理チャネルに属し、LBTがその後成功する、または、
・LCGに属する論理チャネルのいずれにも利用可能なULデータが含まれておらず、LBTがその後成功する。
この場合、BSRは、以下のように「規則的なBSR」と呼ばれる、
・ULリソースが割り当てられ、パディングビット数がバッファステータス報告MAC CEとそのサブヘッダを加えたサイズ以上であり、LBTがその後成功した場合、BSRは以下のように「パディングBSR」と呼ばれる、
・retxBSR-Timerが満了し、LCGに属する論理チャネルのうち少なくとも1つにULデータが含まれており、LBTがその後成功した場合、そのBSRを以下のように「規則的なBSR」と呼ばれる、
・periodicBSR-Timerが満了し、LBTがその後成功した場合、BSRは以下のように「周期的なBSR」と呼ばれる。
MACエンティティは、以下であるものとする。
1>バッファステータス報告手順により、少なくとも1つのBSRがトリガされて、キャンセルされていないと判定された場合、
2>UL-SCHのリソースが新しい送信に利用可能であり、LBT成功と判定された場合、
3>BSR MAC CE(単数または複数)を生成するように、多重化およびアセンブリ手順に指示して、
3>生成されたBSRが全てロングまたはショートのトランケートSRの場合を除き、periodicBSR-Timerを起動または再起動して、
3>retxBSR-Timerを起動または再起動する。
複数のイベントがBSRをトリガした場合でも、MAC PDUは最大で1つのBSR MAC CEを含むものとする。規則的なBSRおよび周期的なBSRは、パディングBSRよりも優先されるものとする。
MACエンティティは、任意のUL-SCCHで新しいデータの送信に対するグラントを受信すると、retxBSR-Timerを再起動するものとする。
ULグラント(単数または複数)が送信可能な全ての保留データに適応でき、LBT成功が判定されたが、追加的にBSR MAC CEとそのサブヘッダに適応するには十分ではないとき、トリガされた全てのBSRはキャンセルされ得る。LBT成功が判定され、BSR MAC CEを含むMAC PDUが送信されたとき、MAC PDUアセンブリ前にトリガされた全てのBSRは、キャンセルされるものとする。
上記の修正テキストは、LBT成功の観点から記載されているが、LBT失敗なしの観点からも表されてもよい。
LBT失敗またはLBT成功は、単一のインスタンスではないことがある。複数のLBT失敗または成功の検出であってもよい。SRは、MAC BSR CE送信に影響を及ぼす一連のLBT失敗後にのみトリガされてもよい。
また、LBT失敗もしくはLBT成功をカウントする、あるいは連続LBT失敗もしくは連続LBT成功をカウントするように手順を定義してもよい。LBT失敗もしくは連続LBT失敗が、設定された最大LBT失敗閾値を超えた場合、またはLBT成功もしくは連続LBT成功が、設定された最小LBT成功閾値未満であり得る場合にのみ、SRがトリガされる。
上記の例示的なMAC固有の変更は、LBT成功の観点から記載されているが、例はLBT失敗なしの観点からも同様に表されてもよい。
あるいは、BSR周期タイマおよびBSR再送信タイマは、既存の手順で行われるように起動または再起動してもよいが、LBT失敗と判定された場合には、BSR周期タイマおよびBSR再送信タイマをLBT失敗による最後のリセット前の残りの値に、または、例えば設定された時間値などの異なる時間値にリセットされる。
この修正は、BSRの送信がLBT失敗によってブロックされたときに、BSRの周期的な送信またはBSRの再送信が遅延しないように、BSR周期タイマまたはBSR再送信タイマがリセットされ得ないことを確実にするために、必要となる場合がある。
(論理チャネル優先順位付け(LCP)手順
)
LCP手順の以下の修正は、NR-UにおけるLBTの影響を考慮に入れてもよい。
送信前にLBT失敗が検出された場合、MAC PDUは生成されるべきではない。
例えば、MAC仕様を以下のように修正してもよい。
MACエンティティは、以下の条件を満たす場合、HARQエンティティのMAC PDUを生成しないものとする。
・MACエンティティがskipUplinkTxDynamicに設定されており、HARQエンティティに示されたグラントがC-RNTIに宛てられたものであるか、またはHARQエンティティに示されたグラントが設定されたアップリンクグラントである、および、
・TS38.212に規定されているように、このPUSCH送信に対して要求された非周期的なCSIがない、および、
・MAC PDUは、0個のMAC SDUを含む、および、
・MAC PDUには周期的なBSRのみが含まれ、いずれのLCGにも利用可能なデータがないか、またはMAC PDUにはパディングBSRのみが含まれている、または、
・LBT失敗が検出されなかった。
あるいは、LBT成功が検出されたことを基準にしてもよい。
この修正は、このMAC PDUが後続のグラントに受け入れられないことがあり(例えば、ULグラントのサイズのため)、また、生成されたMAC CE(単数または複数)がMAC PDU送信時に誤った情報(例えば、PHR、BSR...)を提供し得るために、必要となる場合がある。
以下に別の例を示す。あるいは、MAC PDUを生成して物理層に提供してもよいが、このMAC PDUのLBT失敗が検出されると、LCP手順を再起動して新しいMAC PDUを生成する。
これを達成するために、このMAC PDU内に組み込まれていたMAC SDUは、LBT成功が判定されるまで保存されてもよい。これらのMAC SDUは、すでに構築されたMAC PDUからこれらのMAC SDUを再作成しなければならないのではなく、再処理し得る。
より単純な事例としては、グラントがより大きい場合、UEがパディングを除去し、LCPに従って残りのスペースで追加データを多重化するか、またはUEがサブPDU(MAC SDUおよびCE)をバックアウトして、前回のグラントに対してデータが処理されなかったかのようにLCPを再形成することである。
しかし、この場合でも、LAAで以前に判定されたMAC CEをすでに構築しており、古いPHR CEを許可している場合がある。その場合、ネットワークは、どのような送信に基づいて、PHRがどのように計算されたのかわからないことがある。
MAC手順(BSR、PHR...)のタイマおよびカウンタは前回の(失敗した)送信によってすでに影響を受けているため、CEの再構築は複雑である。
MAC PDUの多重化およびアセンブリが再実行されたときに、トリガが再評価され、報告された値が再計算されるように、MAC CEは回復して保存され得るか、またはこれらのMAC CEをトリガしたイベントが復元され得る。
さらに複雑な事例は、グラントがより小さいときにどうするかである。最初に、LCPに従って、前回のPDUから何が送信され得るかを判定する。次に、送信されないことがあるMAC SDUを回復し、MAC CEの送信に関連付けられたMAC手順のタイマおよびカウンタをリセットして、MAC CEが構築される前の値にタイマおよびカウンタを設定し得る。
前回の送信以降に、新たに優先度の高いデータまたはその他のMAC CEのトリガとなるイベントが受信された可能性がある。この可能性に対処するために、多重化アセンブリ手順は、失敗したMAC PDU送信に関連付けられたMAC SDUを優先しないことがある。
MAC CEにも同様の問題が発生することがあり、これらは今では古くなり、MAC手順をバックアウトすることが複雑である。
NBはMAC CEの送信が遅延したこと、または元々送信が予定されていたときを通知すべきである。
別の問題は、セグメンテーションがRLCで実行され、MACのSDUが大きすぎる可能性があることである。MAC要求RLCに前回のRLC PDUをバックアウトさせることは、非常に複雑である。これに対処する1つの方法は、このMAC SDUに対応するRLC PDU、および新しいMAC PDU送信に多重化されない場合がある他のSDUに対して、RLC否定応答を偽装することである。
(ビーム障害検出および回復)
ビーム障害および検出手順の以下の修正は、NR-UにおけるLBTの影響を考慮に入れる。ビーム障害回復タイマが満了しても、ビーム障害回復のためのランダムアクセス手順の開始以降にLBT失敗が検出された場合、ビーム障害回復タイマを延長するべきである。これは、ビーム障害回復タイマの早期満了、および場合によりセル再選択またはRRC(再)確立を回避するために、必要な場合がある。
図2~図10など、本明細書に示されているステップを実行するエンティティは、論理エンティティによって実行されてもよいことが理解される。ステップは、図12A~図12Gに示されているようなデバイス、サーバ、またはコンピュータシステムのメモリに保存され、そのプロセッサ上で実行されてもよい。本明細書に開示されている例示的な方法の間で、ステップをスキップすること、ステップを組み合わせること、またはステップを追加することが意図されている。
表1は、例示的な略語または定義を提供する。
図11は、本明細書で説明したNR-U LBT MAC手順の方法、システム、およびデバイスに基づいて生成され得る例示的なディスプレイ(例えば、グラフィカルユーザインタフェース)を示す。ディスプレイインタフェース901(例えば、タッチスクリーンディスプレイ)は、特に、PHR関連パラメータおよび方法フローなど、NR-U LBT MAC手順に関連付けられたブロック902のテキストを提供してもよい。本明細書で説明したステップのいずれかの進捗(例えば、送信されたメッセージまたはステップの成功)をブロック902に表示してもよい。さらに、グラフィカル出力902が、ディスプレイインタフェース901に表示されてもよい。グラフィカル出力は、NR-U LBT MAC手順の方法、システム、およびデバイスを実装するデバイスのトポロジー、本明細書で議論される任意の方法またはシステムの進捗のグラフィカル出力などであってもよい。
第3世代パートナーシッププロジェクト(3rd Generation Partnership Project:3GPP)は、無線アクセス、コアトランスポートネットワーク、ならびに、コーデック、セキュリティ、およびサービス品質に関する作業を含むサービス能力を含む、セルラー通信ネットワーク技術の技術標準を開発している。最近の(Radio Access Technology:RAT)標準には、WCDMA(登録商標)(一般に3Gと呼ばれる)、LTE(一般に4Gと呼ばれる)、LTE-Advanced標準、および「5G」とも呼ばれる新しい無線技術(New Radio:NR)がある。3GPP NR標準の開発は今後も継続されると予想されており、次世代無線アクセス技術(新RAT)の定義が含まれる。これには、7GHz未満の新しいフレキシブル無線アクセスの提供、および7GHzを超える新しいウルトラモバイルブロードバンド無線アクセスの提供が含まれると予想されている。フレキシブル無線アクセスは、6GHz未満の新しい周波数帯での後方互換性のない新しい無線アクセスで構成され、同じ周波数帯で多重化され得る異なる動作モードを含むことで、要件が異なる幅広い3GPP NRユースケースに対処することが予想されている。ウルトラモバイルブロードバンドには、例えば、屋内用途およびホットスポットなどのウルトラモバイルブロードバンドアクセスの機会を提供するセンチ波およびミリ波の周波数帯が含まれることが予想されている。特にウルトラモバイルブロードバンドでは、センチ波およびミリ波専用の設計最適化により、7GHz未満のフレキシブル無線アクセスと共通の設計フレームワークを共有することが予想されている。
3GPPでは、NRがサポートすることが予想される様々なユースケースが特定されており、その結果、データレート、レイテンシ、およびモビリティに関する多種多様なユーザ体験の要件が生じている。ユースケースには、以下のような一般的なカテゴリ、拡張モバイルブロードバンド(Enhanced Mobile Broadband:eMBB)超高信頼性低遅延通信(Ultra-Reliable Low-Latency Communication:URLLC)、大規模マシンタイプ通信(Massive Machine Type Communications:mMTC)、ネットワーク運用(例えば、ネットワークスライシング、ルーティング、マイグレーションおよびインターワーキング、省エネ)、ならびに、高度化した車両対全て(Enhanced Vehicle-To-Everything:eV2X)通信であって、車両対車両通信(Vehicle-To-Vehicle Communication:V2V)、車両対インフラストラクチャ通信(Vehicle-To-Infrastructure Communication:V2I)、車両対ネットワーク通信(Vehicle-To-Network Communication:V2N)、車両対歩行者通信(Vehicle-To-Pedestrian Communication:V2P)、および他のエンティティとの車両通信のいずれかを含み得るものが含まれる。これらのカテゴリにおける特定のサービスおよび用途には、例えば、モニタリングおよびセンサネットワーク、デバイスの遠隔操作、双方向の遠隔操作、パーソナルクラウドコンピューティング、ビデオストリーミング、ワイヤレスクラウドベースのオフィス、ファーストレスポンダの接続性、自動車緊急通報システム、災害警報、リアルタイムゲーミング、複数人でのビデオ通話、自動運転、拡張現実、タッチインターネット、仮想現実、ホームオートメーション、ロボット、および空中ドローンが、ほんの一部の例として挙げられる。これらのユースケースの全ておよびその他のユースケースが、本明細書で意図されている。
図12Aは、本明細書で記載および請求された図1から図10に示されたシステムおよび方法などの、NR-U LBT MAC手順の方法および装置が使用され得る例示的な通信システム100を示す。通信システム100は、無線送受信ユニット(Wireless Transmit/Receive Unit:WTRU)102a、102b、102c、102d、102e、102f、または102g(これらは、一般的または集合的に、WTRU102またはWTRU102と呼ばれることがある)を含んでもよい。通信システム100は、無線アクセスネットワーク(Radio Access Network:RAN)103/104/105/103b/104b/105b、コアネットワーク106/107/109、公衆交換電話網(Public Switched Telephone Network:PSTN)108、インターネット110、他のネットワーク112、およびネットワークサービス113を含んでもよい。ネットワークサービス113は、例えば、V2Xサーバ、V2X機能、ProSeサーバ、ProSe機能、IoTサービス、ビデオストリーミング、またはエッジコンピューティングなどを含んでもよい。
本明細書に開示された概念は、任意の数のWTRU、基地局、ネットワーク、またはネットワーク要素と共に使用されてもよいことが理解されるであろう。WTRU102a、102b、102c、102d、102e、102f、または102gのそれぞれは、無線環境で動作または通信するように構成された任意のタイプの装置またはデバイスであってもよい。各WTRU102a、102b、102c、102d、102e、102f、または102gは、図12A、図12B、図12C、図12D、図12E、または図12Fに、ハンドヘルド無線通信装置として図示されている場合があるが、5G無線通信に意図されている多種多様なユースケースでは、各WTRUは、ワイヤレス信号を送信もしくは受信するように構成された任意のタイプの装置もしくはデバイスを含んでもよく、または具体化されてもよいことが理解され、ほんの一例として、ユーザ機器(User Equipment:UE)、移動局、固定または移動加入者ユニット、ポケットベル、セルラー電話、パーソナルデジタルアシスタント(Personal Digital Assistant:PDA)、スマートフォン、ラップトップ、タブレット、ネットブック、ノートブックコンピュータ、パーソナルコンピュータ、無線センサ、家電製品、スマートウォッチまたはスマートウェアなどのウェアラブルデバイス、医療または電子ヘルスデバイス、ロボット、産業機器、ドローン、自動車、バス、トラック、列車、または飛行機などの車両などが含まれる。
通信システム100はまた、基地局114aおよび基地局114bを含んでもよい。図12Aの例では、各基地局114aおよび114bは、単一の要素として図示されている。実際には、基地局114aおよび114bは、任意の数の相互接続された基地局またはネットワーク要素を含んでもよい。基地局114aは、コアネットワーク106/107/109、インターネット110、ネットワークサービス113、または他のネットワーク112などの1つ以上の通信ネットワークへのアクセスを容易にするために、WTRU102a、102b、および102cのうちの少なくとも1つと無線でインタフェースするように構成された任意のタイプのデバイスであってもよい。同様に、基地局114bは、コアネットワーク106/107/109、インターネット110、他のネットワーク112、またはネットワークサービス113などの1つ以上の通信ネットワークへのアクセスを容易にするために、遠隔無線ヘッド(Remote Radio Head:RRH)118a、118b、送受信ポイント(Transmission and Reception Point:TRP)119a、119b、または路側機(Roadside Unit:RSU)120a、120bの少なくとも1つと有線または無線でインタフェースするように構成された任意のタイプのデバイスであってもよい。RRH118a、118bは、コアネットワーク106/107/109、インターネット110、ネットワークサービス113、または他のネットワーク112などの1つ以上の通信ネットワークへのアクセスを容易にするために、WTRU102の少なくとも1つ、例えばWTRU102cと無線でインタフェースするように構成された任意のタイプのデバイスであってもよい。
TRP119a、119bは、コアネットワーク106/107/109、インターネット110、ネットワークサービス113、または他のネットワーク112などの1つ以上の通信ネットワークへのアクセスを容易にするために、WTRU102dの少なくとも1つと無線でインタフェースするように構成された任意のタイプのデバイスであってもよい。RSU120aおよび120bは、コアネットワーク106/107/109、インターネット110、他のネットワーク112、またはネットワークサービス113などの1つ以上の通信ネットワークへのアクセスを容易にするために、WTRU102eまたは102fの少なくとも1つと無線でインタフェースするように構成された任意のタイプのデバイスであってもよい。例として、基地局114a、114bは、無線基地局装置(Base Transceiver Station:BTS)、ノードB、eノードB、ホームノードB、ホームeノードB、次世代ノードB(Next Generation Node-B:gノードB)、衛星、サイトコントローラ、アクセスポイント(Access Point:AP)、無線ルータなどであってもよい。
基地局114aは、RAN103/104/105の一部であってもよく、これは、基地局コントローラ(Base Station Controller:BSC)、無線ネットワークコントローラ(Radio Network Controller:RNC)、中継ノードなどの他の基地局またはネットワーク要素(図示せず)も含んでいてもよい。同様に、基地局114bは、RAN103b/104b/105bの一部であってもよく、これは、BSC、RNC、中継ノードなどの他の基地局またはネットワーク要素(図示せず)も含んでいてもよい。基地局114aは、セル(図示せず)と呼ばれ得る特定の地理的領域内で、無線信号を送信または受信するように構成されてもよい。同様に、基地局114bは、本明細書に開示されているようなNR-U LBT MAC手順の方法、システム、およびデバイスのための、セル(図示せず)と呼ばれ得る特定の地理的領域内で、有線または無線信号を送信または受信するように構成されてもよい。同様に、基地局114bは、セル(図示せず)と呼ばれ得る特定の地理的領域内で、有線信号または無線信号を送信または受信するように構成されてもよい。セルは、さらに、セルセクタに分割されてもよい。例えば、基地局114aに関連付けられたセルは、3つのセクタに分割されてもよい。したがって、一実施例では、基地局114aは、例えば、セルの各セクタに1つずつ、3つのトランシーバを含んでもよい。一実施例では、基地局114aは、多入力多出力(Multiple-Input Multiple Output:MIMO)技術を採用してもよく、したがって、セルの各セクタにつきの複数のトランシーバを利用してもよい。
基地局114aは、エアインタフェース115/116/117を介して、WTRU102a、102b、102c、または102gの1つ以上と通信してもよく、任意の適切な無線通信リンク(例えば、無線周波数(Radio Frequency:RF)、マイクロ波、赤外線(Infrared:IR)、紫外線(Ultraviolet:UV)、可視光、センチ波、ミリ波など)であってもよい。エアインタフェース115/116/117は、任意の適切な無線アクセス技術(RAT)を使用して確立されてもよい。
基地局114bは、有線またはエアインタフェース115b/116b/117bを介して、RRH118a、118b、TRP119a、119b、またはRSU120a、120bのうちの1つ以上と通信してもよく、これは、任意の適切な有線(例えば、ケーブル、光ファイバなど)または無線通信リンク(例えば、無線周波数(RF)、マイクロ波、赤外線(IR)、紫外線(UV)、可視光、センチ波、ミリ波など)であってもよい。エアインタフェース115b/116b/117bは、任意の適切な無線アクセス技術(RAT)を使用して確立されてもよい。
RRH118a、118b、TRP119a、119bまたはRSU120a、120bは、エアインタフェース115c/116c/117cを介して、WTRU102c、102d、102e、102fの1つ以上と通信してもよく、これは、任意の適切な無線通信リンク(例えば、無線周波数(RF)、マイクロ波、赤外線(IR)、紫外線(UV)、可視光、センチ波、ミリ波など)であってもよい。エアインタフェース115c/116c/117cは、任意の適切な無線アクセス技術(RAT)を使用して確立されてもよい。
WTRU102a、102b、102c,102d、102e、または102fは、サイドリンク通信などのエアインタフェース115d/116d/117dを介して互いに通信してもよく、これは、任意の適切な無線通信リンク(例えば、無線周波数(RF)、マイクロ波、赤外線(IR)、紫外線(UV)、可視光、センチ波、ミリ波など)であってもよい。エアインタフェース115d/116d/117dは、任意の適切な無線アクセス技術(RAT)を使用して確立されてもよい。
通信システム100は、多重アクセスシステムであってもよく、CDMA、TDMA、FDMA、OFDMA、SC-FDMAなどの1つ以上のチャネルアクセス方式を採用してもよい。例えば、RAN103/104/105における基地局114aおよびWTRU102a、102b、102c、またはRAN103b/104b/105bにおけるRRH118a、118b、TRP119a、119bおよびRSU120a、120bならびにWTRU102c、102d、102e、102fは、ユニバーサル移動体通信システム(Universal Mobile Telecommunications System:UMTS)地上無線アクセス(UMTS Terrestrial Radio Access:UTRA)などの無線技術を実装してもよく、広帯域CDMA(Wideband CDMA:WCDMA)を使用してエアインタフェース115/116/117または115c/116c/117cをそれぞれ確立してもよい。WCDMAは、高速パケットアクセス(High-Speed Packet Access:HSPA)または発展型高速パケットアクセス(Evolved HSPA:HSPA+)などの通信プロトコルを含んでいてもよい。HSPAは、高速ダウンリンクパケットアクセス(High-Speed Downlink Packet Access:HSDPA)または高速アップリンクパケットアクセス(High-Speed Uplink Packet Access:HSUPA)を含んでもよい。
一実施例では、基地局114aおよびWTRU102a、102b、102c、または、RAN103b/104b/105bにおけるRRH118a、118b、TRP119a、119b、もしくはRSU120a、120bおよびWTRU102c、102dは、発展型UMTS地上無線アクセス(Evolved UMTS Terrestrial Radio Access:E-UTRA)などの無線技術を実装していてもよく、ロングタームエボリューション(Long Term Evolution:LTE)またはLTEアドバンスト(LTE-Advanced:LTE-A)を使用してエアインタフェース115/116/117または115c/116c/117cをそれぞれ確立してもよい。将来的には、エアインタフェース115/116/117または115c/116c/117cは、3GPP NR技術を実装してもよい。LTEおよびLTE-A技術は、LTE D2DおよびV2X技術ならびにインタフェース(サイドリンク通信など)を含んでもよい。同様に、3GPP NR技術は、NR V2X技術およびインタフェース(サイドリンク通信など)を含む。
RAN103/104/105における基地局114aならびにWTRU102a、102b、102c、および102g、またはRAN103b/104b/105bにおけるRRH118a、118b、TRP119a、119b、もしくはRSU120a、120bおよびWTRU102c、102d、102e、102fは、IEEE802.16(例えば、WiMAX(Worldwide Interoperability for Microwave Access))、CDMA2000、CDMA2000 1X、CDMA2000 EV-DO、暫定標準2000(Interim Standard 2000:IS-2000)、暫定標準95(Interim Standard 95:IS-95)、暫定標準856(Interim Standard 856:IS-856)、GSM(Global System for Mobile communication)(登録商標)、EDGE(Enhanced Data rates for GSM Evolution)、GERAN(GSM EDGE)などの無線技術を実装していてもよい。
図12Aの基地局114cは、例えば、無線ルータ、ホームノードB、ホームeノードB、またはアクセスポイントであってもよく、本明細書に開示されているように、NR-U LBT MAC手順の方法、システム、およびデバイスを実装するために、事業所、家、車両、列車、空中、衛星、製造所、キャンパスなどの局所的なエリアで無線接続性を容易にするための任意の適切なRATを利用してもよい。一実施例では、基地局114cおよびWTRU102、例えば、WTRU102eは、無線ローカルエリアネットワーク(Wireless Local Area Network:WLAN)を確立するために、IEEE802.11などの無線技術を実装してもよい。同様に、基地局114cおよびWTRU102dは、無線パーソナルエリアネットワーク(Wireless Personal Area Network:WPAN)を確立するために、IEEE802.15などの無線技術を実装してもよい。さらに別の実施例では、基地局114cおよびWTRU102、例えば、WTRU102eは、ピコセルまたはフェムトセルを確立するために、セルラーベースのRAT(例えば、WCDMA、CDMA2000、GSM、LTE、LTE-A、NRなど)を利用してもよい。図12Aに示すように、基地局114cは、インターネット110への直接接続を有していてもよい。したがって、基地局114cは、コアネットワーク106/107/109を介してインターネット110にアクセスする必要がなくてもよい。
RAN103/104/105またはRAN103b/104b/105bは、コアネットワーク106/107/109と通信していてもよく、このネットワークは、音声、データ、メッセージング、認可および認証、アプリケーション、またはボイスオーバーインターネットプロトコル(Voice Over Internet Protocol:VoIP)サービスをWTRU102a、102b、102c、102dの1つ以上に提供するように構成された任意のタイプのネットワークであってもよい。例えば、コアネットワーク106/107/109は、呼制御、課金サービス、モバイル位置ベースサービス、プリペイドコーリング、インターネット接続性、パケットデータネットワーク接続性、イーサネット(登録商標)接続性、ビデオ配信などを提供してもよく、ユーザ認証などの高レベルのセキュリティ機能を実行してもよい。
図12Aには示されていないが、RAN103/104/105もしくはRAN103b/104b/105bまたはコアネットワーク106/107/109は、RAN103/104/105もしくはRAN103b/104b/105bと同じRATまたは異なるRATを採用する他のRANと、直接的にまたは間接的に通信してもよいことが理解されるであろう。例えば、E-UTRA無線技術を利用し得るRAN103/104/105またはRAN103b/104b/105bに接続されていることに加えて、コアネットワーク106/107/109はまた、GSMまたはNR無線技術を採用している別のRAN(図示せず)と通信していてもよい。
コアネットワーク106/107/109はまた、WTRU102a、102b、102c、102d、102eがPSTN108、インターネット110、または他のネットワーク112にアクセスするためのゲートウェイとして機能してもよい。PSTN108は、一般電話サービス(Plain Old Telephone Service:POTS)を提供する回線交換電話網を含んでもよい。インターネット110は、TCP/IPインターネットプロトコルスイートにおける伝送制御プロトコル(Transmission Control Protocol:TCP)、ユーザデータグラムプロトコル(User Datagram Protocol:UDP)、インターネットプロトコル(Internet Protocol:IP)などの共通の通信プロトコルを使用する、相互接続されたコンピュータネットワークおよびデバイスのグローバルシステムを含んでもよい。ネットワーク112は、他のサービスプロバイダによって所有もしくは運営される有線または無線の通信ネットワークを含んでもよい。例えば、ネットワーク112は、任意のタイプのパケットデータネットワーク(例えば、IEEE802.3イーサネットネットワーク)または1つ以上のRANに接続された別のコアネットワークを含んでもよく、これは、RAN103/104/105もしくはRAN103b/104b/105bと同じRATまたは異なるRATを採用してもよい。
通信システム100におけるWTRU102a、102b、102c、102d、102e、および102fの一部または全ては、マルチモード能力を含んでもよく、例えば、WTRU102a、102b、102c、102d、102e、および102fは、本明細書に開示されているように、NR-U LBT MAC手順の方法、システム、およびデバイスを実装するために、異なる無線リンクを介して異なる無線ネットワークと通信するための複数のトランシーバを含んでもよい。例えば、図12Aに示すWTRU102gは、セルラーベースの無線技術を採用し得る基地局114a、および、IEEE802の無線技術を採用し得る基地局114cと通信するように構成されてもよい。
図12Aには示されていないが、ユーザ機器は、ゲートウェイに有線接続を行ってもよいことが理解されるであろう。ゲートウェイは、レジデンシャルゲートウェイ(Residential Gateway:RG)であってもよい。RGは、コアネットワーク106/107/109への接続性を提供してもよい。本明細書に含まれるアイデアの多くは、WTRUであるUE、および有線接続を使用してネットワークに接続するUEにも同様に適用され得ることが理解されるであろう。例えば、無線インタフェース115、116、117および115c/116c/117cに適用されるアイデアは、有線接続にも同様に適用され得る。
図12Bは、本明細書に開示されているように、NR-U LBT MAC手順の方法、システム、およびデバイスを実装し得る例示的なRAN103およびコアネットワーク106のシステム図である。上記のとおり、RAN103は、エアインタフェース115を介してWTRU102a、102b、および102cと通信するために、UTRA無線技術を採用してもよい。RAN103はまた、コアネットワーク106と通信していてもよい。図12Bに示すように、RAN103は、ノードB140a、140b、および140cを含んでもよく、これらはそれぞれ、エアインタフェース115を介してWTRU102a、102b、および102cと通信するための1つ以上のトランシーバを含んでもよい。ノードB140a、140b、および140cはそれぞれ、RAN103内の特定のセル(図示せず)に関連付けられてもよい。RAN103はまた、RNC142a、142bを含んでもよい。RAN103は、任意の数のノードBおよび無線ネットワークコントローラ(Radio Network Controller:RNC)を含んでもよいことが理解されるであろう。
図12Bに示すように、ノードB140a、140bは、RNC142aと通信してもよい。さらに、ノードB140cは、RNC142bと通信していてもよい。ノードB140a、140b、および140cは、Iubインタフェースを介して、それぞれのRNC142a、142bと通信してもよい。RNC142a、および142bは、Iurインタフェースを介して互いに通信してもよい。RNC142a、および142bのそれぞれは、それが接続されているそれぞれのノードB140a、140b、および140cを制御するように構成されてもよい。さらに、RNC142aおよび142bのそれぞれは、アウターループ電力制御、負荷制御、受付制御、パケットスケジューリング、ハンドオーバー制御、マクロダイバシティ、セキュリティ機能、データ暗号化などの、他の機能性を実行またはサポートするように構成されてもよい。
図12Bに示すコアネットワーク106は、メディアゲートウェイ(Media Gateway:MGW)144、モバイルスイッチングセンター(Mobile Switching Center:MSC)146、サービングGPRSサポートノード(Serving GPRS Support Node:SGSN)148、またはゲートウェイGPRSサポートノード(Gateway GPRS Support Node:GGSN)150を含んでもよい。前述の各要素は、コアネットワーク106の一部として図示されているが、これらの要素のいずれか1つは、コアネットワークオペレータ以外のエンティティによって所有または運営されてもよいことが理解されるであろう。
RAN103内のRNC142aは、IuCSインタフェースを介して、コアネットワーク106内のMSC146に接続されてもよい。MSC146は、MGW144に接続されてもよい。MSC146およびMGW144は、WTRU102a、102b、および102cに、PSTN108などの回線交換ネットワークへのアクセスを提供して、WTRU102a、102b、および102cと、従来の陸上線通信デバイスとの間の通信を容易にしてもよい。
RAN103内のRNC142aはまた、IuPSインタフェースを介して、コアネットワーク106内のSGSN148に接続されてもよい。SGSN148は、GGSN150に接続されてもよい。SGSN148およびGGSN150は、WTRU102a、102b、および102cに、インターネット110などのパケット交換ネットワークへのアクセスを提供して、WTRU102a、102b、および102cと、IP対応デバイスとの間の通信を容易にしてもよい。
コアネットワーク106はまた、他のサービスプロバイダによって所有または運営される他の有線または無線ネットワークを含み得る、他のネットワーク112に接続されてもよい。
図12Cは、本明細書に開示されているように、NR-U LBT MAC手順の方法、システム、および装置を実装し得る、例示的なRAN104およびコアネットワーク107のシステム図である。上記のとおり、RAN104は、エアインタフェース116を介してWTRU102a、102b、および102cと通信するために、E-UTRA無線技術を採用してもよい。RAN104はまた、コアネットワーク107と通信してもよい。
RAN104は、eノードB160a、160b、および160cを含んでもよいが、RAN104は任意の数のeノードBを含んでもよいことが理解されるであろう。eノードB160a、160b、および160cはそれぞれ、エアインタフェース116を介して、WTRU102a、102b、および102cと通信するための1つ以上のトランシーバを含んでもよい。例えば、eノードB160a、160b、および160cは、MIMO技術を実装してもよい。したがって、eノードB160aは、例えば、複数のアンテナを使用して、WTRU102aに無線信号を送信し、かつWTRU102aから無線信号を受信してもよい。
eノードB160a、160b、および160cのそれぞれは、特定のセル(図示せず)に関連付けられてもよく、無線リソース管理決定、ハンドオーバー決定、アップリンクまたはダウンリンクにおけるユーザのスケジューリングなどを処理するように構成されてもよい。図12Cに示すように、eノードB160a、160b、および160cは、X2インタフェースを介して互いに通信してもよい。
図12Cに示すコアネットワーク107は、モビリティ管理ゲートウェイ(Mobility Management Gateway:MME)162、サービングゲートウェイ164、およびパケットデータネットワーク(Packet Data Network:PDN)ゲートウェイ166を含んでもよい。前述の各要素は、コアネットワーク107の一部として図示されているが、これらの要素のいずれか1つは、コアネットワークオペレータ以外のエンティティによって所有または運営されてもよいことが理解されるであろう。
MME162は、S1インタフェースを介して、RAN104内のeノードB160a、160b、および160cのそれぞれに接続されてもよく、制御ノードとして機能してもよい。例えば、MME162は、WTRU102a、102b、および102cのユーザの認証、ベアラのアクティブ化/非アクティブ化、WTRU102a、102b、および102cの初期接続中の特定のサービングゲートウェイの選択などの役割を担ってもよい。MME162はまた、RAN104と、GSMまたはWCDMAなどの他の無線技術を採用した他のRAN(図示せず)とを切り替えるための、制御プレーン機能を提供してもよい。
サービングゲートウェイ164は、S1インタフェースを介して、RAN104内のeノードB160a、160b、および160cのそれぞれに接続されてもよい。サービングゲートウェイ164は、一般に、WTRU102a、102b、および102cとの間でユーザデータパケットをルーティングおよび転送してもよい。サービングゲートウェイ164はまた、eノードBハンドオーバー中にユーザプレーンをアンカリングすること、WTRU102a、102b、および102cでダウンリンクデータが利用可能な場合にページングをトリガすること、WTRU102a、102b、および102cのコンテキストを管理ならびに保存することなど、他の機能を実行してもよい。
サービングゲートウェイ164はまた、PDNゲートウェイ166に接続されてもよく、これは、WTRU102a、102b、および102cに、インターネット110などのパケット交換ネットワークへのアクセスを提供して、WTRU102a、102b、102cとIP対応デバイスとの間の通信を容易にしてもよい。
コアネットワーク107は、他のネットワークとの通信を容易にしてもよい。例えば、コアネットワーク107は、WTRU102a、102b、および102cに、PSTN108などの回線交換ネットワークへのアクセスを提供して、WTRU102a、102b、および102cと、従来の陸上線通信デバイスとの間の通信を容易にしてもよい。例えば、コアネットワーク107は、コアネットワーク107とPSTN108との間のインタフェースとして機能するIPゲートウェイ(例えば、IPマルチメディアサブシステム(IP Multimedia Subsystem:IMS)サーバ)を含んでいてもよく、またはそれと通信してもよい。さらに、コアネットワーク107は、WTRU102a、102b、および102cに、他のサービスプロバイダによって所有または運営される他の有線または無線ネットワークを含み得るネットワーク112へのアクセスを提供してもよい。
図12Dは、本明細書に開示されているように、NR-U LBT MAC手順の方法、システム、およびデバイスを実装し得る例示的なRAN105およびコアネットワーク109のシステム図である。RAN105は、エアインタフェース117を介してWTRU102aおよび102bと通信するために、NR無線技術を採用してもよい。RAN105はまた、コアネットワーク109と通信してもよい。非3GPPインターワーキング機能(Non-3GPP Interworking Function:N3IWF)199は、エアインタフェース198を介してWTRU102cと通信するために、非3GPP無線技術を採用してもよい。N3IWF199はまた、コアネットワーク109と通信してもよい。
RAN105は、gノードB180aおよび180bを含んでもよい。RAN105は、任意の数のgノードBを含んでもよいことが理解されるであろう。gノードB180aおよび180bはそれぞれ、エアインタフェース117を介してWTRU102a、および102bと通信するための1つ以上のトランシーバを含んでもよい。統合されたアクセスおよびバックホール接続が使用される場合、WTRUとgノードBとの間で同じエアインタフェースが使用されてもよく、これは、1つまたは複数のgNBを介したコアネットワーク109であってもよい。gノードB180aおよび180bは、MIMO、MU-MIMO、またはデジタルビームフォーミング技術を実装してもよい。したがって、gノードB180aは、例えば、複数のアンテナを使用して、WTRU102aに無線信号を送信し、かつWTRU102aから無線信号を受信してもよい。RAN105は、eノードBなどの他のタイプの基地局を採用してもよいことが理解されるべきである。また、RAN105は、1つ以上のタイプの基地局を採用してもよいことが理解されるであろう。例えば、RANは、eノードBおよびgノードBを採用してもよい。
N3IWF199は、非3GPPアクセスポイント180cを含んでもよい。N3IWF199は、任意の数の非3GPPアクセスポイントを含んでもよいことが理解されるであろう。非3GPPアクセスポイント180cは、エアインタフェース198を介してWTRU102cと通信するための1つ以上のトランシーバを含んでもよい。非3GPPアクセスポイント180cは、802.11を使用して、エアインタフェース198を介してWTRU102cと通信してもよい。
gノードB180aおよび180bのそれぞれは、特定のセル(図示せず)に関連付けられてもよく、無線リソース管理決定、ハンドオーバー決定、アップリンクまたはダウンリンクにおけるユーザのスケジューリングなどを処理するように構成されてもよい。図12Dに示すように、gノードB180a、および180bは、例えば、Xnインタフェースを介して互いに通信してもよい。
図12Dに示すコアネットワーク109は、5Gコアネットワーク(5G Core Network:5GC)であってもよい。コアネットワーク109は、無線アクセスネットワークによって相互に接続されている顧客に、多数の通信サービスを提供してもよい。コアネットワーク109は、コアネットワークの機能性を実行する多数のエンティティで構成される。本明細書で使用する場合、「コアネットワークエンティティ」または「ネットワーク機能」という用語は、コアネットワークの1つ以上の機能性を実行する任意のエンティティを意味する。そのようなコアネットワークエンティティは、図12Gに例示されたシステム90のなどの、無線もしくはネットワーク通信用に構成された装置またはコンピュータシステムのメモリに保存され、そのプロセッサ上で実行されるコンピュータ実行可能命令(ソフトウェア)の形態で実装される論理エンティティであってもよいことが理解される。
図12Dの例では、5Gコアネットワーク109は、アクセスおよびモビリティ管理機能(Access and Mobility Management Function:AMF)172、セッション管理機能(Session Management Function:SMF)174、ユーザプレーン機能(User Plane Function:UPF)176aおよび176b、ユーザデータ管理機能(User Data Management Function:UDM)197、認証サーバ機能(Authentication Server Function:AUSF)190、ネットワーク露出機能(Network Exposure Function:NEF)196、ポリシー制御機能(Policy Control Function:PCF)184、非3GPPインターワーキング機能(N3IWF)199、ユーザデータリポジトリ(User Data Repository:UDR)178を含んでもよい。前述の各要素は、5Gコアネットワーク109の一部として図示されているが、これらの要素のいずれか1つは、コアネットワークオペレータ以外のエンティティによって所有または運営されてもよいことが理解されるであろう。また、5Gコアネットワークは、これらの要素の全てで構成されていなくてもよく、追加の要素で構成されていてもよく、これらの各要素の複数のインスタンスで構成されていてもよいことも理解されるであろう。図12Dは、ネットワーク機能が互いに直接接続していることを示しているが、直径ルーティングエージェントまたはメッセージバスなどのルーティングエージェントを介して通信してもよいことが理解されるべきである。
図12Dの例では、ネットワーク機能間の接続性は、一連のインタフェースまたは基準点を介して達成されている。ネットワーク機能は、他のネットワーク機能またはサービスによって呼び出される(invoked)または呼び出される(called)サービスのセットとしてモデル化、記述、または実装され得ることが理解されるであろう。ネットワーク機能サービスの呼び出しは、ネットワーク機能間の直接接続、メッセージバスでのメッセージ交換、ソフトウェア機能の呼び出しなどを介して実現されてもよい。
AMF172は、N2インタフェースを介してRAN105に接続されてもよく、制御ノードとして機能してもよい。例えば、AMF172は、登録管理、接続管理、到達可能性管理、アクセス認証、アクセス承認の役割を担ってもよい。AMFは、ユーザプレーンのトンネル構成情報を、N2インタフェースを介してRAN105に転送する役割を担ってもよい。AMF172は、N11インタフェースを介して、SMFからユーザプレーンのトンネル構成情報を受信してもよい。AMF172は、一般的に、N1インタフェースを介してWTRU102a、102b、102cとの間でNASパケットをルーティングして転送してもよい。N1インタフェースは、図12Dには示されていない。
SMF174は、N11インタフェースを介して、AMF172に接続されてもよい。同様に、SMFは、N7インタフェースを介してPCF184に、ならびにN4インタフェースを介してUPF176aおよび176bに接続されてもよい。SMF174は、制御ノードとして機能してもよい。例えば、SMF174は、セッション管理、WTRU102a、102b、および102cに対するIPアドレスの割り当て、UPF176aおよびUPF176bにおけるトラフィックステアリングルールの管理および設定、ならびに、AMF172に対するダウンリンクデータ通知の生成の役割を担ってもよい。
UPF176aおよびUPF176bは、WTRU102a、102b、および102cに、インターネット110などのパケットデータネットワーク(PDN)へのアクセスを提供して、WTRU102a、102b、および102cと他のデバイスとの間の通信を容易にしてもよい。UPF176aおよびUPF176bはまた、WTRU102a、102b、および102cに、他のタイプのパケットデータネットワークへのアクセスを提供してもよい。例えば、他のネットワーク112は、イーサネットネットワークまたはデータのパケットを交換する任意のタイプのネットワークであってもよい。UPF176aおよびUPF176bは、N4インタフェースを介してSMF174からトラフィックステアリングルールを受信してもよい。UPF176aおよびUPF176bは、N6インタフェースでパケットデータネットワークを接続することによって、またはN9インタフェースで相互におよび他のUPFと接続することによって、パケットデータネットワークへのアクセスを提供してもよい。パケットデータネットワークへのアクセスを提供することに加えて、UPF176は、パケットのルーティングおよび転送、ポリシールールの施行、ユーザプレーンのトラフィックに対するサービス品質の処理、ダウンリンクパケットのバッファリングなどの役割を担ってもよい。
AMF172はまた、例えば、N2インタフェースを介してN3IWF199に接続されていてもよい。N3IWFは、例えば、3GPPで定義されていない無線インタフェース技術を介して、WTRU102cと5Gコアネットワーク170との間の接続を容易にする。AMFは、RAN105と相互作用するのと同じか、または類似の方法で、N3IWF199と相互作用してもよい。
PCF184は、N7インタフェースを介してSMF174に接続され、N15インタフェースを介してAMF172に接続され、N5インタフェースを介してアプリケーション機能(Application Function:AF)188に接続されてもよい。N15およびN5インタフェースは、図12Dには示されていない。PCF184は、AMF172およびSMF174などの制御プレーンノードにポリシールールを提供して、制御プレーンノードがこれらのルールを施行できるようにしてもよい。PCF184は、AMFがN1インタフェースを介してWTRU102a、102b、および102cにポリシーを配信できるように、WTRU102a、102b、および102cに対してAMF172にポリシーを送信してもよい。その後、ポリシーは、WTRU102a、102b、および102cで施行されるか、または適用されてもよい。
UDR178は、認証のクレデンシャルおよび加入情報のリポジトリとして機能してもよい。UDRは、ネットワーク機能がリポジトリ内のデータに追加し、そこから読み取り、修正することができるように、ネットワーク機能に接続してもよい。例えば、UDR178は、N36インタフェースを介してPCF184に接続してもよい。同様に、UDR178は、N37インタフェースを介してNEF196に接続してもよく、UDR178は、N35インタフェースを介してUDM197に接続してもよい。
UDM197は、UDR178と他のネットワーク機能との間のインタフェースとして機能してもよい。UDM197は、ネットワーク機能にUDR178へのアクセスを許可してもよい。例えば、UDM197は、N8インタフェースを介してAMF172に接続してもよく、UDM197は、N10インタフェースを介してSMF174に接続してもよい。同様に、UDM197は、N13インタフェースを介してAUSF190に接続してもよい。UDR178とUDM197は、緊密に統合されていてもよい。
AUSF190は、認証関連の動作を実行し、N13インタフェースを介してUDM178に接続し、N12インタフェースを介してAMF172に接続する。
NEF196は、5Gコアネットワーク109内における能力およびサービスを、アプリケーション機能(AF)188に公開する。公開は、N33 APIインタフェース上で行われてもよい。NEFは、N33インタフェースを介してAF188に接続してもよく、5Gコアネットワーク109の能力およびサービスを公開するために、他のネットワーク機能に接続してもよい。
アプリケーション機能188は、5Gコアネットワーク109のネットワーク機能と相互作用してもよい。アプリケーション機能188とネットワーク機能との間の相互作用は、直接的なインタフェースを介していてもよく、またはNEF196を介して生じてもよい。アプリケーション機能188は、5Gコアネットワーク109の一部と見なされてもよく、または5Gコアネットワーク109の外部にあって、モバイルネットワーク事業者とビジネス関係を有する企業によって展開されてもよい。
ネットワークスライシングは、モバイルネットワーク事業者が、事業者のエアインタフェースの背後にある1つ以上の「仮想」コアネットワークをサポートするために使用できるメカニズムである。これは、コアネットワークを1つ以上の仮想ネットワークに「スライスシング」して、異なるRANまたは単一のRANにわたって実行される異なるサービスタイプをサポートすることと関連する。ネットワークスライシングにより、事業者は、機能性、性能、およびアイソレーションなどの多様な要件が求められる様々な市場のシナリオに最適なソリューションを提供するようにカスタマイズされたネットワークを作成することができる。
3GPPは、ネットワークスライシングをサポートするように5Gコアネットワークを設計している。ネットワークスライシングは、ネットワーク事業者が、非常に多様でときには極端な要件が求められる5Gの多様な一連のユースケース(例えば、マッシブIoT、クリティカルコミュニケーション、V2X、および拡張モバイルブロードバンド)をサポートするために使用できる優れたツールである。ネットワークスライシング技術を使用しないと、各ユースケースに固有の一連の性能、スケーラビリティ、および可用性の要件がある場合、ネットワークアーキテクチャは、より広い範囲のユースケースを効率的にサポートするのに十分に柔軟かつスケーラブルではない可能性がある。さらに、新しいネットワークサービスの導入がより効率的に行われるべきである。
再び図12Dを参照すると、ネットワークスライシングシナリオでは、WTRU102a、102b、または102cは、N1インタフェースを介して、AMF172に接続してもよい。AMFは、論理的に1つ以上のスライスの一部であってもよい。AMFは、WTRU102a、102b、もしくは102cの接続または通信を、1つ以上のUPF176aおよび176b、SMF174、ならびに他のネットワーク機能と調和してもよい。UPF176aおよび176b、SMF174、ならびに他のネットワーク機能のそれぞれは、同じスライス、または異なるスライスの一部であってもよい。それらが異なるスライスの一部であるとき、それらは、異なるコンピューティングリソース、セキュリティクレデンシャルなどを利用することができるという意味で、互いに分離されていてもよい。
コアネットワーク109は、他のネットワークとの通信を容易にしてもよい。例えば、コアネットワーク109は、5Gコアネットワーク109とPSTN108との間のインタフェースとして機能するIPマルチメディアサブシステム(IMS)サーバなどのIPゲートウェイを含んでいてもよく、またはそれと通信してもよい。例えば、コアネットワーク109は、ショートメッセージサービスを介して通信を機能させるショートメッセージサービス(Short Message Service:SMS)サービスセンターを含んでもよく、またはそれと通信してもよい。例えば、5Gコアネットワーク109は、WTRU102a、102b、および102cと、サーバまたはアプリケーション機能188との間の非IPデータパケットの交換を容易にしてもよい。さらに、コアネットワーク170は、WTRU102a、102b、および102cに、他のサービスプロバイダによって所有または運営される他の有線または無線ネットワークを含み得るネットワーク112へのアクセスを提供してもよい。
本明細書に記載され、図12A、図12C、図12D、または図12Eに示されているコアネットワークエンティティは、特定の既存の3GPP仕様でそれらのエンティティに与えられた名前によって識別されているが、将来、それらのエンティティおよび機能性が他の名前で識別される可能性があり、特定のエンティティまたは機能が、将来の3GPP NR仕様を含む、3GPPによって発行される将来の仕様と組み合わされ得ることが理解される。したがって、図12A、図12B、図12C、図12D、または図12Eで説明および示されている特定のネットワークエンティティおよび機能性は、例示としてのみ提供されており、本明細書で開示および請求されている主題は、現在定義されているかまたは将来定義されるかに関わらず、任意の類似の通信システムで具体化または実装され得ることが理解される。
図12Eは、本明細書に記載されているように、NR-U LBT MAC手順を実装するシステム、方法、装置が使用され得る例示的な通信システム111を示す。通信システム111は、無線送受信ユニット(WTRU)A、B、C、D、E、F、基地局gNB121、V2Xサーバ124、ならびに路側機(Road Side Unit:RSU)123a、および123bを含んでもよい。実際には、本明細書に提示される概念は、任意の数のWTRU、基地局gNB、V2Xネットワーク、または他のネットワーク要素に適用し得る。1つまたはいくつかまたは全てのWTRU A、B、C、D、E、およびFは、アクセスネットワークカバレッジ131の範囲外であってもよい。WTRU A、B、およびCは、V2Xグループを形成しており、そのうちWTRU Aはグループリードであり、WTRU BおよびCはグループメンバである。
WTRU A、B、C、D、E、およびFは、それらがアクセスネットワークカバレッジ131内にある場合、gNB121を介してUuインタフェース129で相互に通信してもよい。図12Eの例では、WTRU BおよびFがアクセスネットワークカバレッジ131内に示されている。WTRU A、B、C、D、E、およびFは、それらがアクセスネットワークカバレッジ131のもとにあるか、またはアクセスネットワークカバレッジ131の外にあるかに関わらず、インタフェース125a、125b、または128などのスライドリンクインタフェース(例えば、PC5またはNR PC5)を介して、互いに直接通信してもよい。例えば、図12Eの例では、アクセスネットワークカバレッジ131の外にあるWRTU Dは、カバレッジ131の中にあるWTRU Fと通信する。
WTRU A、B、C、D、E、およびFは、車両対ネットワーク通信(V2N)133またはサイドリンククインタフェース125bを介して、RSU123aまたは123bと通信してもよい。WTRU A、B、C、D、E、およびFは、車両対インフラストラクチャ通信(V2I)インタフェース127を介してV2Xサーバ124と通信してもよい。WTRU A、B、C、D、E、およびFは、車両対歩行者通信(V2P)インタフェース128を介して、別のUEに通信してもよい。
図12Fは、図12A、図12B、図12C、図12D、もしくは図12EのWTRU102、または図1(例えば、UE101)など、本明細書に記載されているように、NR-U LBT MAC手順を実装するシステム、方法、および装置に従って、無線通信および動作のために構成され得る、例示的な装置またはデバイスWTRU102のブロック図である。図12Fに示すように、例示的なWTRU102は、プロセッサ118、トランシーバ120、送受信素子122、スピーカ/マイクロフォン124、キーパッド126、ディスプレイ/タッチパッド/インジケータ128、非リムーバブルメモリ130、リムーバブルメモリ132、電源134、全地球測位システム(Global Positioning System:GPS)チップセット136、および他の周辺機器138を含んでもよい。WTRU102は、前述の要素の任意のサブコンビネーションを含み得ることが理解されるであろう。また、基地局114aおよび114b、または基地局114aおよび114bが表し得るノード、例えば、しかしこれらに限定されない、基地局装置(BTS)、ノードB、サイトコントローラ、アクセスポイント(AP)、ホームノードB、発展型ノードB(eノードB)、ホーム発展型ノードB(HeNB)、ホーム発展型ノードBゲートウェイ、次世代ノードB(gノードB)、ならびにプロキシノードなどは、特に、図12Fに図示された要素の一部または全てを含んでもよく、本明細書に記載されているNR-U LBT MAC手順の開示されたシステムおよび方法を実行する例示的な実装であってもよい。
プロセッサ118は、汎用プロセッサ、専用プロセッサ、従来のプロセッサ、デジタル信号プロセッサ(Digital Signal Processor:DSP)、複数のマイクロプロセッサ、DSPコアに関連した1つ以上のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路(Application Specific Integrated Circuit:ASIC)、フィールドプログラマブルゲートアレイ(Field Programmable Gate Array:FPGA)回路、その他のタイプの集積回路(Integrated Circuit:IC)、ステートマシンなどであってもよい。プロセッサ118は、信号符号化、データ処理、電力制御、入出力処理、または、WTRU102が無線環境で動作することを可能にする任意の他の機能性を実行してもよい。プロセッサ118は、トランシーバ120に結合されてもよく、トランシーバは、送受信素子122に結合されてもよい。図12Fは、プロセッサ118およびトランシーバ120を別個のコンポーネントとして図示しているが、プロセッサ118およびトランシーバ120は、電子パッケージまたはチップ内に共に統合されてもよいことが理解されるであろう。
UEの送受信素子122は、エアインタフェース115/116/117を介して基地局(例えば、図12Aの基地局114a)との間で、またはエアインタフェース115d/116d/117dを介して別のUEとの間で、信号を送信もしくは受信するように構成されてもよい。例えば、送受信素子122は、RF信号を送信または受信するように構成されたアンテナであってもよい。送受信素子122は、例えば、IR、UV、もしくは可視光信号を送信または受信するように構成されたエミッタ/検出器であってもよい。送受信素子122は、RF信号および光信号の両方を送受信するように構成されてもよい。送受信素子122は、無線もしくは有線信号の任意の組み合わせを送信または受信するように構成されていてもよいことが理解されよう。
さらに、図12Fでは送受信素子122が単一の素子として図示さているが、WTRU102は、任意の数の送受信素子122を含んでもよい。より具体的には、WTRU102は、MIMO技術を採用してもよい。したがって、WTRU102は、エアインタフェース115/116/117を介して無線信号を送受信するための2つ以上の送受信素子122(例えば、複数のアンテナ)を含んでもよい。
トランシーバ120は、送受信素子122によって送信されるべき信号を変調し、送受信素子122によって受信される信号を復調するように構成されてもよい。上記のとおり、WTRU102は、マルチモード能力を有していてもよい。したがって、トランシーバ120は、WTRU102が複数のRAT、例えば、NRとIEEE802.11もしくはNRとE-UTRAを介して通信する、または、異なるRRH、TRP、RSU、もしくはノードに複数のビームを介して同じRATで通信することを可能にするための、複数のトランシーバを含んでもよい。
WTRU102のプロセッサ118は、スピーカ/マイクロフォン124、キーパッド126、またはディスプレイ/タッチパッド/インジケータ128(例えば、液晶ディスプレイ(Liquid Crystal Display:LCD)ディスプレイユニット、または有機発光ダイオード(Organic Light-Emitting Diode:OLED)ディスプレイユニットに結合されていてもよく、これらからユーザ入力データを受信してもよい。プロセッサ118はまた、スピーカ/マイクロフォン124、キーパッド126、または、ディスプレイ/タッチパッド/インジケータ128にユーザデータを出力してもよい。さらに、プロセッサ118は、非リムーバブルメモリ130またはリムーバブルメモリ132など、任意のタイプの適切なメモリから情報にアクセスし、メモリにデータを保存してもよい。非リムーバブルメモリ130は、ランダムアクセスメモリ(Random-Access Memory:RAM)、リードオンリーメモリ(Read-Only MemoryROM)、ハードディスク、または任意の他のタイプのメモリストレージデバイスを含んでもよい。リムーバブルメモリ132は、加入者識別モジュール(Subscriber Identity Module:SIM)カード、メモリスティック、セキュアデジタル(Secure Digital:SD)メモリカードなどを含んでいてもよい。プロセッサ118は、クラウドもしくはエッジコンピューティングプラットフォームでホストされているサーバまたはホームコンピュータ(図示せず)上などで、WTRU102に物理的に配置されていないメモリから情報にアクセスし、データを保存してもよい。プロセッサ118は、本明細書に記載されているいくつかの実施例におけるLBT FCのセットアップが成功したかまたは不成功なのかに応じて、ディスプレイもしくはインジケータ128上の照明パターン、画像、または色を制御するように構成されてもよく、または別の方法でNR-U LBT MAC手順および関連するコンポーネントの状態を示すように構成されてもよい。ディスプレイもしくはインジケータ128上の制御照明パターン、画像、または色は、本明細書で示されている、もしくは記載されている図(例えば、図1~図10など)における方法フローまたはコンポーネントのいずれかの状態を反映していてもよい。本明細書には、NR-U LBT MAC手順のメッセージおよび手順が開示されている。メッセージおよび手順は、ユーザが、入力ソース(例えば、スピーカ/マイクロフォン124、キーパッド126、またはディスプレイ/タッチパッド/インジケータ128)を介してリソースを要求し、ディスプレイ128に表示され得る他のもののうち、NR-U LBT MAC手順関連情報を要求、設定、または照会するためのインタフェース/APIを提供するように拡張されてもよい。
プロセッサ118は、電源134から電力を受け取り、WTRU102内の他のコンポーネントに電力を分配または制御するように構成されてもよい。電源134は、WTRU102に電力を供給するための任意の適切なデバイスであってもよい。例えば、電源134は、1つ以上の乾電池、太陽電池、燃料電池などを含んでもよい。
また、プロセッサ118は、GPSチップセット136に結合されてもよく、GPSチップセット136は、WTRU102の現在位置に関する位置情報(例えば、経度および緯度)を提供するように構成されてもよい。GPSチップセット136からの情報に加えて、またはそれの代わりに、WTRU102は、基地局(例えば、基地局114a、114b)からエアインタフェース115/116/117を介して位置情報を受信してもよく、または2つ以上の近くの基地局から受信されている信号のタイミングに基づいてその位置を判定してもよい。WTRU102は、任意の適切な位置判定方法によって、位置情報を取得してもよいことが理解されるであろう。
プロセッサ118は、さらに、他の周辺機器138に結合されてもよく、これらの周辺機器138は、追加の特徴、機能性、または有線もしくは無線の接続性を提供する1つ以上のソフトウェアまたはハードウェアモジュールを含んでもよい。例えば、周辺機器138は、加速度計などの様々なセンサ、バイオメトリクス(例えば、指紋)センサ、電子コンパス、衛星トランシーバ、デジタルカメラ(写真またはビデオ用)、ユニバーサルシリアルバス(Universal Serial Bus:USB)ポートまたは他の相互接続インタフェース、振動デバイス、テレビトランシーバ、ハンズフリーヘッドセット、Bluetooth(登録商標)モジュール、周波数変調(Frequency Modulated:FM)無線ユニット、デジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザなどを含んでもよい。
WTRU102は、センサ、家電製品、スマートウォッチまたはスマートウェアなどのウェアラブルデバイス、医療または電子ヘルスデバイス、ロボット、産業機器、ドローン、自動車、トラック、電車、または飛行機などの車両など、他の装置またはデバイス内に含まれていてもよい。WTRU102は、周辺機器138の1つを構成し得る相互接続インタフェースなど、1つ以上の相互接続インタフェースを介して、そのような装置もしくはデバイスの他のコンポーネント、モジュール、またはシステムに接続してもよい。
図12Gは、例示的なコンピューティングシステム90のブロック図であり、これは、図12A、図12C、図12D、および図12Eに示される通信ネットワークの1つ以上の装置、ならびに、図1から図10に示され、本明細書において説明および請求されるシステムおよび方法などのNR-U LBT MAC手順が、RAN103/104/105、コアネットワーク106/107/109、PSTN108、インターネット110、その他のネットワーク112、もしくはネットワークサービス113における特定のノードまたは機能エンティティなどで具現化され得る。コンピューティングシステム90は、コンピュータまたはサーバで構成され、主にコンピュータ可読命令によって制御されてもよく、コンピュータ可読命令は、ソフトウェアの形態であってもよく、またはそのようなソフトウェアがどこに保存されていても、もしくはどのような手段でアクセスされてもよい。このようなコンピュータ可読命令は、プロセッサ91内で実行されて、コンピューティングシステム90に動作をさせてもよい。プロセッサ91は、汎用プロセッサ、専用プロセッサ、従来のプロセッサ、デジタル信号プロセッサ(DSP)、複数のマイクロプロセッサ、DSPコアに関連した1つ以上のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)回路、その他のタイプの集積回路(IC)、ステートマシンなどであってもよい。プロセッサ91は、信号符号化、データ処理、電力制御、入出力処理、または、WTRU90が電気通信ネットワークで動作することを可能にする任意の他の機能性を実行してもよい。コプロセッサ81は、メインプロセッサ91とは異なるオプションのプロセッサであり、追加の機能を実行、またはプロセッサ91を支援し得る。プロセッサ91またはコプロセッサ81は、LBT失敗の受信または反応など、NR-U LBT MAC手順のために本明細書に開示された方法および装置に関連するデータを受信、生成、ならびに処理してもよい。
動作時、プロセッサ91は、命令をフェッチ、復号、および実行し、コンピューティングシステムの主なデータ転送パスであるシステムバス80を介して、他のリソースとの間で情報を転送する。このようなシステムバスは、コンピューティングシステム90内のコンポーネントを接続し、データ交換のための媒体を定義する。システムバス80は、典型的には、データを送るためのデータライン、アドレスを送るためのアドレスライン、ならびに、割り込みを送るため、およびシステムバスを動作するための制御ラインを含む。このようなシステムバス80の一例は、ペリフェラルコンポーネントインターコネクト(Peripheral Component Interconnect:PCI)バスである。
システムバス80に結合されたメモリは、ランダムアクセスメモリ(Random Access Memory:RAM)82および読み出し専用メモリ(Read Only Memory:ROM)93を含む。このようなメモリは、情報を保存して取り出すことができる回路を含む。ROM93は、一般に、容易に変更できない保存データを含む。RAM82に保存されたデータは、プロセッサ91もしくは他のハードウェアデバイスによって読み取られ得るか、または変更され得る。RAM82またはROM93へのアクセスは、メモリコントローラ92によって制御されてもよい。メモリコントローラ92は、命令が実行される際に、仮想アドレスを物理アドレスに変換するアドレス変換機能を提供してもよい。メモリコントローラ92はまた、システム内のプロセスを分離し、ユーザプロセスからシステムプロセスを分離するメモリ保護機能を提供してもよい。したがって、第1のモードで実行されるプログラムは、そのプロセスの仮想アドレス空間によってマッピングされたメモリのみにアクセスし得、プロセス間のメモリ共有が設定されていない限り、他のプロセスの仮想アドレス空間内のメモリにアクセスすることはできない。
さらに、コンピューティングシステム90は、プロセッサ91からの命令をプリンタ94、キーボード84、マウス95、およびディスクドライブ85などの周辺機器に通信するための役割を担う周辺機器コントローラ83を含んでいてもよい。
ディスプレイコントローラ96によって制御されるディスプレイ86は、コンピューティングシステム90によって生成された視覚的出力を表示するために使用される。このような視覚的出力は、テキスト、グラフィックス、アニメーショングラフィックス、およびビデオを含んでもよい。視覚的出力は、グラフィカルユーザインタフェース(Graphical User Interface:GUI)の形態で提供されてもよい。ディスプレイ86は、CRTベースのビデオディスプレイ、LCDベースのフラットパネルディスプレイ、ガスプラズマベースのフラットパネルディスプレイ、またはタッチパネルで実装されてもよい。ディスプレイコントローラ96は、ディスプレイ86に送信されるビデオ信号を生成するために必要な電子コンポーネントを含む。
さらに、コンピューティングシステム90は、図12A、図12B、図12C、図12D、もしくは図12Eの、RAN103/104/105、コアネットワーク106/107/109、PSTN108、インターネット110、WTRU102、またはその他のネットワーク112などの、外部通信ネットワークまたはデバイスに、コンピューティングシステム90を接続するために使用され、コンピューティングシステム90がそれらのネットワークの他のノードまたは機能エンティティと通信できるようにし得る、例えば無線または有線ネットワークアダプタ97などの通信回路を含んでいてもよい。通信回路は、単独で、またはプロセッサ91と組み合わせて、本明細書に記載されている特定の装置、ノード、または機能エンティティの送受信ステップを実行するために使用されてもよい。
本明細書に記載されている装置、システム、方法、およびプロセスのいずれかまたは全てが、コンピュータ可読記憶媒体に保存されたコンピュータ実行可能命令(例えば、プログラムコード)の形態で具現化されてもよく、この命令は、プロセッサ118または91などのプロセッサによって実行されると、プロセッサに、本明細書に記載されたシステム、方法、およびプロセスを実行または実施させることが理解される。具体的には、本明細書に記載されているステップ、動作、または機能のいずれかは、無線または有線のネットワーク通信のために構成された装置またはコンピューティングシステムのプロセッサ上で実行される、そのようなコンピュータ実行可能命令の形態で実装されてもよい。コンピュータ可読記憶媒体は、情報を保存するための任意の非一時的(例えば、有形もしくは物理的)な方法または技術で実装された揮発性および不揮発性、取り外し可能および取り外し不可能な媒体を含むが、そのようなコンピュータ可読記憶媒体には信号は含まれない。コンピュータ可読記憶媒体には、RAM、ROM、EEPROM、フラッシュメモリもしくは他のメモリ技術、CD-ROM、デジタル多用途ディスク(Digital Versatile Disk:DVD)もしくは他の光ディスクストレージ、磁気カセット、磁気テープ、磁気ディスクストレージもしくは他の磁気ストレージデバイス、または、所望の情報を保存するために使用され、コンピューティングシステムによってアクセスされ得る他の有形もしくは物理的媒体が含まれるが、これらに限定されない。
本開示の主題であるNR-U LBT MAC手順の好ましい方法、システム、または装置を図に示すように説明する際、明確にするために特定の用語が採用されている。しかし、請求項に記載された主題は、そのように選択された特定の用語に限定されることを意図しておらず、各特定の要素は、同様の目的を達成するために同様の方法で動作する全ての技術的等価物を含むことを理解すべきである。
本明細書に記載されている様々な技術は、ハードウェア、ファームウェア、ソフトウェア、または必要に応じて、それらの組み合わせに関連して実装されてもよい。このようなハードウェア、ファームウェア、およびソフトウェアは、通信ネットワークの様々なノードに配置された装置に常駐してもよい。装置は、本明細書に記載されている方法を実現するために、単独で、または互いに組み合わせて動作してもよい。本本発明で使用する場合、「装置」、「ネットワーク装置」、「ノード」、「デバイス」、「ネットワークノード」などの用語が互換的に使用され得る。さらに、「または」という言葉の使用は、本明細書で別段の定めがない限り、一般的に包括的に使用される。
この書面による明細書では、最良のモードを含む本発明を開示するために例を使用しており、また、任意のデバイスまたはシステムを作成および使用し、任意の組み込まれた方法を実行することを含めて、当業者が本発明を実施できるようにする。特許を受けることができる範囲は、特許請求の範囲によって定義され、当業者が想到する他の実施例(例えば、本明細書に開示された例示的な方法の間でステップをスキップすること、ステップを組み合わせること、または、ステップを追加すること)を含み得る。このような他の実施例は、特許請求の範囲の文字通りの言語とは異なることのない構造要素を有する場合、または特許請求の範囲の文字通りの言語とは実質的に異なる同等の構造要素を含む場合、特許請求の範囲に含まれることが意図される。
この書面による明細書では、最良のモードを含む主題を開示するために例を使用しており、また、任意のデバイスまたはシステムを作成および使用し、任意の組み込まれた方法を実行することを含めて、当業者が主題を実施できるようにする。特許を受けることができる範囲は、特許請求の範囲によって定義され、例えば、当業者が想到する他の実施例(例えば、特に図2~図10など、本明細書に開示された例示的な方法の間でステップをスキップすること、ステップを組み合わせること、または、ステップを追加すること)を含み得る。このような他の実施例は、特許請求の範囲の文字通りの言語とは異なることのない構造要素を有する場合、または特許請求の範囲の文字通りの言語とは実質的に異なる同等の構造要素を含む場合、特許請求の範囲に含まれることが意図される。
本明細書に記載されている方法、システム、および装置などは、とりわけ、手段NR-U LBT MAC手順を提供してもよい。SR手順のLBT失敗により、1)代替BWPへの切り替え、2)RA手順の開始、または、3)SR保留状態の維持につながり得る。DRX手順のLBT失敗により、1)オンデュレーションまたは非アクティブタイマの延長、2)オンデュレーションまたは非アクティブタイマの、MCOT、CWS、またはCCAへの整合、または、3)ショートサイクルの適用、のいずれかにつながり得る。RA手順のLBT失敗により、1)統計報告を生成することもしくは送信すること、または、2)禁止タイマを設定すること、につながり得る。BWP手順のLBT失敗により、1)BWP非アクティブタイマを延長すること、または、2)代替BWPへ切り替えること、につながり得る。このパラグラフおよび次のパラグラフ(または本明細書の関連したパラグラフ)の全ての組み合わせ(ステップの削除または追加を含む)が意図されている。
方法、システム、および装置は、とりわけ、本明細書に記載されているように、手段NR-U LBT MAC手順を提供してもよい。方法、システム、コンピュータ可読記憶媒体、または装置は、とりわけ、ランダムアクセス手順、SCellアクティブ化/非アクティブ化手順、間欠受信手順、スケジューリング要求手順、バッファステータス報告手順、論理チャネル優先順位付け手順、UEとNBのMAC手順の調整、パワーヘッドルーム報告手順、または帯域幅部分動作手順に関して、LBT失敗を判定する手段を有する。方法、システム、コンピュータ可読記憶媒体、または装置は、プリアンブル送信カウンタが1より大きく、パワーランピングカウンタの一時停止の通知が下位層から受信されておらず、選択されたSSBが変更されず、LBT失敗が検出されていないことを判定する手段、および、判定ステップに基づいて、プリアンブルパワーランピングカウンタを1だけインクリメントする命令を提供する手段を有する。方法、システム、コンピュータ可読記憶媒体、または装置は、ユーザ機器(UE)に関連付けられたLBT状態の表示を取得すること(例えば、リモートデバイスから受信すること、またはローカルセンサを使用して検出すること)、およびLBT報告MAC制御要素(LBTR MAC CE)を生成することを含み得る、リッスンビフォートーク(LBT)およびメディアアクセス制御(MAC)に関連付けられた動作のための手段を有し、LBTR MAC CEは、LBT状態の表示を含み得る。方法、システム、コンピュータ可読記憶媒体、または装置は、LBTタイミング情報をMAC層に提供する手段を有する。LBTタイミング情報は、クリアチャネル評価の期間、最大チャネル占有時間、またはコンテンションウィンドウを含んでもよい。方法、システム、コンピュータ可読記憶媒体、または装置は、ユーザ機器(UE)に関連付けられたLBT失敗の第1の閾値またはLBT成功の第2の閾値を検出することと、第1の閾値または第2の閾値の検出に基づいて、DRX設定を調整することとを含み得る、リッスンビフォートーク(LBT)および間欠受信(DRX)に関連付けられた動作のための手段を有する。DRX設定は、オンデュレーションまたは非アクティブタイマを含んでもよい。本発明の方法、システム、コンピュータ可読記憶媒体、または装置は、基地局がUEに情報を提供する手段を有し、情報は、基地局またはUEに関連付けられたアクセスチャネルに関するダウンリンク情報を含み得る。UEは、アップリンク情報に関する情報を自動的に検出してもよい。アップリンク情報またはダウンリンク情報に基づいて、UEは異なるMAC手順を行ってもよい。一実施例では、UEは、アップリンク情報およびダウンリンク情報を使用して、LBT失敗を報告するか否か、またはどの手順が影響を受けるかを報告するか否かを判定してもよい。方法、システム、コンピュータ可読記憶媒体、または装置は、基地局によって検出されたダウンリンク情報を取得し、ダウンリンク情報は、基地局のチャネルアクセスに関連付けられ、ダウンリンクのリッスンビフォートーク失敗の表示を含み得、アップリンク情報を取得し、アップリンク情報は、装置によって検出され、アップリンク情報は、装置のチャネルアクセスに関連付けられ、アップリンクのリッスンビフォートーク失敗の表示を含み得、および、アップリンクのリッスンビフォートーク失敗の表示またはダウンリンクのリッスンビフォートーク失敗の表示に基づいて、メディアアクセス制御動作を実行する、手段を有する。アップリンクのリッスンビフォートーク失敗(もしくは成功)、またはダウンリンクのリッスンビフォートーク失敗(もしくは成功)は、スケジューリング要求手順、バッファステータス報告手順、論理チャネル優先順位付け手順、間欠受信手順、SCellアクティブ化もしくは非アクティブ化手順、パワーヘッドルーム報告手順、ランダムアクセス手順、リッスンビフォートーク報告手順、または帯域幅部分動作手順によって検出され得る。このパラグラフおよび次のパラグラフ(または本明細書の関連したパラグラフ)の全ての組み合わせ(ステップの削除または追加を含む)が意図されている。
方法、システム、コンピュータ可読記憶媒体、または装置は、MAC手順を管理する手段を有する。方法、システム、コンピュータ可読記憶媒体、または装置は、ダウンリンク情報を取得する手段を有し、ダウンリンク情報は、基地局の(装置への)チャネルアクセスに関連付けられ、アップリンク情報(例えば、ユーザ機器)を取得する手段を有し、アップリンク情報は、装置による(例えば、基地局への)チャネルアクセスに関連付けられ、アップリンク情報またはダウンリンク情報に基づいて、メディアアクセス制御動作を実行する。ダウンリンク情報は、基地局によって検出されてもよい。アップリンク情報は、装置によって検出されてもよい。チャネルアクセス情報は、リッスンビフォートーク動作に関連する情報であってもよい。メディアアクセス制御動作の実行は、帯域幅部分の非アクティブタイマを延長することを含んでもよく、アップリンクまたはダウンリンク情報は、アップリンクまたはダウンリンクのリッスンビフォートーク失敗情報を含む。ULまたはDLのLBT失敗情報時に、BWPを切り替えることがあってもよい(BWP動作MAC手順とは独立しており、切り替えは事前に設定された代替BWPへの切り替えであってもよい)。メディアアクセス制御動作の実行は、ランダムアクセス応答ウィンドウを延長することを含んでもよく、アップリンクまたはダウンリンク情報は、アップリンクまたはダウンリンクのリッスンビフォートーク失敗情報を含む。メディアアクセス制御動作の実行は、プリアンブル送信カウンタをインクリメントしないこと、または競合解決タイマを延長することを含んでもよく、アップリンクまたはダウンリンク情報は、アップリンクまたはダウンリンクのリッスンビフォートーク失敗情報を含む。メディアアクセス制御動作の実行は、パワーランピングを維持することまたは減少させることを含んでもよく、アップリンクまたはダウンリンク情報は、アップリンクまたはダウンリンクのリッスンビフォートーク失敗情報を含む。開示された主題は、LBT失敗によるRA手順の停止を回避し得る。さらに、プリアンブル送信LBT失敗閾値を超えると、上位層にRA問題が示され、RA手順が不成功であると見なされ得る。メディアアクセス制御動作の実行は、リッスンビフォートーク失敗または成功があるか否かを判定することに基づいて、物理アップリンク制御チャネルリソースが有効であると判定することを含んでもよく、これは、SR手順がLBT失敗閾値に到達してPUCCHリソースを解放することに関連付けられてもよい。CCA、MCOT、またはCWS情報は、LBT成功情報と共に提供されてもよい。また、このCCA、MCOT、またはCWS情報を含むLBT成功は、成功の認識は失敗がなかったことを意味するため、LBT失敗表示と同等であり得る。LBTが参照される場合、LBT成功表示によって判定され得る。DRXにおいては、LBT失敗時にショートサイクルの適用またはアクティブタイムの延長でカバーしてもよい。さらに、インアクティビティタイマを再起動するときに、LBTの失敗がアクティブタイムを延長する回数に制限がある場合がある。さらに、LBT失敗時にDRXの設定を調整する。これは、オンデュレーション、インアクティビティ、またはDRXサイクルタイマに関連付けられ得る。LBTRについては、LBTの失敗または成功時に、LBTの成功または失敗が既知の期間にわたって閾値を超えた場合に、基地局への報告がトリガされ、報告が送信された後、報告の頻度を制限するために禁止タイマが設定され、報告にはCCA、MCOT、またはCWSなどのタイミング情報が含まれ得る。LBTが既知の閾値に達したことによるSR失敗により、RA手順が開始される(例えば、LBT失敗によりSR送信カウンタがインクリメントされない回数を制限することにより達成される)、LBT失敗時にSR禁止タイマが設定されない、またはLBT失敗時にSR保留が維持され得る。メディアアクセス制御動作の実行は、スケジューリング要求送信のリッスンビフォートーク失敗表示に基づいて、スケジューリング要求失敗を判定すること、またはランダムアクセス手順を開始することを含んでもよい。メディアアクセス制御動作の実行は、スケジューリング要求送信のリッスンビフォートーク失敗表示に基づいて、スケジューリング要求の失敗を判定すること、または帯域幅部分を切り替えることが含まれてもよい。メディアアクセス制御動作の実行は、装置のMAC手順タイマもしくはカウンタを拡張すること、MAC手順がアップリンクもしくはダウンリンクチャネルアクセスによって達成されるときの動作に影響を与え、ライセンス動作と同様の性能を可能にすること、または装置がチャネルアクセス情報を基地局に報告することを含んでもよい。このパラグラフおよび次のパラグラフ(または本明細書の関連したパラグラフ)の全ての組み合わせ(ステップの削除または追加を含む)が意図されている。
方法、システム、コンピュータ可読記憶媒体、または装置は、MAC手順を管理する手段を有する。方法、システム、コンピュータ可読記憶媒体、または装置は、基地局からダウンリンク情報を取得する手段を有し、ダウンリンク情報は、装置のチャネルアクセスに関連付けられ、アップリンク情報を取得し、アップリンク情報は、装置によって検出され、アップリンク情報またはダウンリンク情報に基づいて、メディアアクセス制御動作を実行する、手段を有する。メディアアクセス制御動作の実行は、帯域幅部分の非アクティブタイマを延長することを含んでもよく、アップリンクまたはダウンリンク情報は、アップリンクまたはダウンリンクのリッスンビフォートーク失敗情報を含んでもよい。メディアアクセス制御動作の実行は、ランダムアクセス応答ウィンドウを延長することを含んでもよく、アップリンクまたはダウンリンク情報は、アップリンクまたはダウンリンクのリッスンビフォートーク失敗情報を含んでもよい。メディアアクセス制御動作の実行は、プリアンブル送信カウンタをインクリメントすること、または競合解決タイマを延長することを含んでもよく、アップリンクまたはダウンリンク情報は、アップリンクまたはダウンリンクのリッスンビフォートーク失敗情報を含んでもよい。メディアアクセス制御動作の実行は、パワーランピングを維持すること、または減少させること(例えば、増加させないこと)を含んでもよく、アップリンクまたはダウンリンク情報は、アップリンクまたはダウンリンクのリッスンビフォートーク失敗情報を含んでもよい。メディアアクセス制御動作の実行は、リッスンビフォートーク失敗または失敗成功(例えば、閾値成功または失敗によってトリガされる)があるか否かを判定することに基づいて、物理アップリンク制御チャネル(PUCCH)リソースが有効であると判定することを含んでもよい。メディアアクセス制御動作の実行は、間欠受信動作を調整することを含んでもよく、アップリンクまたはダウンリンク情報は、間欠受信サイクルで基地局からシグナリングされる、クリアチャネル評価期間、最大チャネル占有時間、またはダウンリンクリッスンビフォートーク成功指示を含んでもよい。メディアアクセス制御動作を実行することは、間欠受信動作において、最大チャネル占有時間期間と整合するようにアクティブタイムを調整すること、およびコンテンションウィンドウサイズ期間またはクリアチャネル評価期間中に間欠受信を適用すること含んでもよい。最大チャネル占有時間の期間との整合は、オンデュレーションタイマを調整すること、または非アクティブタイマを調整することを含んでもよい。メディアアクセス制御動作を実行することは、アップリンクまたはダウンリンク情報の影響を受けるメディアアクセス制御動作を報告することを含んでもよい。メディアアクセス制御動作の実行は、アップリンクまたはダウンリンク情報によって影響を受けるメディアアクセス制御動作を報告することを含んでもよく、アップリンクまたはダウンリンク情報は、アップリンクまたはダウンリンクのリッスンビフォートーク失敗情報を含んでもよい。メディアアクセス制御動作の実行は、メディアアクセス制御動作のうちの1つ以上が、アップリンクまたはダウンリンク情報によってどのように影響されるかを報告することを含んでもよい。メディアアクセス制御動作の実行は、メディアアクセス制御動作のうちの1つ以上が、アップリンクまたはダウンリンク情報によってどのように影響されるかを報告することを含んでもよく、アップリンクまたはダウンリンク情報は、アップリンクまたはダウンリンクのリッスンビフォートーク失敗情報を含んでもよい。一般に、LBTの失敗または成功などのアップリンクまたはダウンリンク情報は、とりわけ、本明細書に開示されているようなMAC動作をトリガし得る。装置は、ユーザ機器であってもよい。このパラグラフ(または本明細書の関連したパラグラフ)の全ての組み合わせ(ステップの削除または追加を含む)が意図されている。