JP2022501946A - Ｎｒ−ｕ ｌｂｔ ｍａｃ手順 - Google Patents

Ｎｒ−ｕ ｌｂｔ ｍａｃ手順 Download PDF

Info

Publication number
JP2022501946A
JP2022501946A JP2021517410A JP2021517410A JP2022501946A JP 2022501946 A JP2022501946 A JP 2022501946A JP 2021517410 A JP2021517410 A JP 2021517410A JP 2021517410 A JP2021517410 A JP 2021517410A JP 2022501946 A JP2022501946 A JP 2022501946A
Authority
JP
Japan
Prior art keywords
lbt
procedure
mac
failure
uplink
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2021517410A
Other languages
English (en)
Other versions
JPWO2020069114A5 (ja
JP7455820B2 (ja
Inventor
テリー，ステファン，イー．
アジャクプレ，パスカル，エム．
マリー，ジョセフ，エム．
リ，チン
アイヤー，ラクシュミ，アール．
ジャン，グオドン
Original Assignee
コンヴィーダ ワイヤレス， エルエルシー
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by コンヴィーダ ワイヤレス， エルエルシー filed Critical コンヴィーダ ワイヤレス， エルエルシー
Publication of JP2022501946A publication Critical patent/JP2022501946A/ja
Publication of JPWO2020069114A5 publication Critical patent/JPWO2020069114A5/ja
Application granted granted Critical
Publication of JP7455820B2 publication Critical patent/JP7455820B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W74/00—Wireless channel access
    • H04W74/08—Non-scheduled access, e.g. ALOHA
    • H04W74/0808—Non-scheduled access, e.g. ALOHA using carrier sensing, e.g. carrier sense multiple access [CSMA]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W52/00—Power management, e.g. TPC [Transmission Power Control], power saving or power classes
    • H04W52/02—Power saving arrangements
    • H04W52/0209—Power saving arrangements in terminal devices
    • H04W52/0225—Power saving arrangements in terminal devices using monitoring of external events, e.g. the presence of a signal
    • H04W52/0235—Power saving arrangements in terminal devices using monitoring of external events, e.g. the presence of a signal where the received signal is a power saving command
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W16/00—Network planning, e.g. coverage or traffic planning tools; Network deployment, e.g. resource partitioning or cells structures
    • H04W16/14—Spectrum sharing arrangements between different networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/06—Selective distribution of broadcast services, e.g. multimedia broadcast multicast service [MBMS]; Services to user groups; One-way selective calling services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/20—Control channels or signalling for resource management
    • H04W72/21—Control channels or signalling for resource management in the uplink direction of a wireless link, i.e. towards the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/20—Control channels or signalling for resource management
    • H04W72/23—Control channels or signalling for resource management in the downlink direction of a wireless link, i.e. towards a terminal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W74/00—Wireless channel access
    • H04W74/002—Transmission of channel access control information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W74/00—Wireless channel access
    • H04W74/08—Non-scheduled access, e.g. ALOHA
    • H04W74/0833—Random access procedures, e.g. with 4-step access
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/20—Manipulation of established connections
    • H04W76/28—Discontinuous transmission [DTX]; Discontinuous reception [DRX]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

ＮＲ−Ｕにおいて、ＬＢＴ失敗が発生した場合、既存のＭＡＣ手順が不適切なアクションを実行し、意図しない結果を招くことがある。アンライセンス周波数帯で動作する場合、ＭＡＣ手順の適切な動作および性能を維持するのに役立つ、既存のＭＡＣ手順に関連付けられた方法、装置、およびシステム。

Description

（関連出願の相互参照）
本出願は、２０１８年９月２６日に出願された「ＮＲ−Ｕ ＬＢＴ ＭＡＣ Ｐｒｏｃｅｄｕｒｅｓ」と題する米国仮特許出願第６２／７３６，８１６号および２０１８年１０月３１日に出願された「ＮＲ−Ｕ ＬＢＴ ＭＡＣ Ｐｒｏｃｅｄｕｒｅｓ」と題する米国仮特許出願第６２／７５３，５７９号の利益を主張するものであり、両出願の内容は参照により本明細書に援用される。
ＬＴＥライセンスアシストアクセス３ＧＰＰリリース１６ ＮＲは、以前のリリースで利用可能であったライセンスアシスト接続を使用しないアンライセンス動作をサポートする。以前のリリースでは、常にライセンス接続が存在したため、アンライセンス接続で高レベルのＱｏＳを確保する必要がなかった。
アンライセンスで動作するには、既存のトラフィックに干渉せず、チャネルへのアクセスを得るために、リッスンビフォートーク（Listen Before Talk：ＬＢＴ）の手順が必要である。
アンライセンス周波数帯で動作する少なくとも１つのＳＣｅｌｌを有するキャリアアグリゲーションは、ライセンスアシストアクセス（Licensed-Assisted Access：ＬＡＡ）と呼ばれる。したがって、ＬＡＡでは、ＵＥのために設定されたサービングセルのセットは、フレーム構成タイプ３に従ってアンライセンス周波数帯で動作する少なくとも１つのＳＣｅｌｌを常に含み、これはＬＡＡ ＳＣｅｌｌとも呼ばれる。特に指定がない限り、ＬＡＡ ＳＣｅｌｌは規則的なＳＣｅｌｌとして機能する。
ＬＡＡ ｅＮＢおよびＵＥは、ＬＡＡ ＳＣｅｌｌで送信を実行する前にリッスンビフォートーク（ＬＢＴ）を適用する。ＬＢＴが適用されると、送信機はチャネルをリッスン／感知して、チャネルがフリーまたはビジーかを判定する。チャネルがフリーであると判定された場合、送信機は、送信を行ってもよく、さもなければ、送信を行わない。ＬＡＡ ｅＮＢがＬＡＡチャネルアクセスの目的で他のテクノロジーのチャネルアクセス信号を使用する場合、３ＧＰＰ ＴＳ ３６．３２１（Ｅ−ＵＴＲＡ）、メディアアクセス制御（Medium Access Control：ＭＡＣ）プロトコル仕様、Ｖ１５．２．０［１］のＬＡＡ最大エネルギ検出閾値要件を引き続き満たすものとする。さらなるコンテキストは、３ＧＰＰ ＴＳ ３６．３２１、（Ｅ−ＵＴＲＡ）、メディアアクセス制御（ＭＡＣ）プロトコル仕様、Ｖ１５．２．０に含まれ得る。
アンライセンス周波数帯で動作する場合など、ＭＡＣ手順の適切な動作および性能を維持され得る、既存のＭＡＣ手順に関連付けられた方法、装置、およびシステムが本明細書に開示される。ＮＲ−ＵにおいてＬＢＴ失敗が発生した場合、既存のＭＡＣ手順が不適切なアクションを実行し、意図しない結果を招くことがある。
この発明の概要は、以下の発明を実施するための形態でさらに記載される簡略化された形式で概念の選択を紹介するために提供される。この発明の概要は、請求項に記載された主題の主要な特徴または本質的な特徴を特定することを意図したものではなく、また、請求項に記載された主題の範囲を制限するために使用することを意図したものでもない。さらに、請求項に記載された主題は、本開示のいずれかの部分に記載された何らかのまたは全ての不利益を解決する制限に制約されない。
より詳細な理解は、添付図面に関連した例を介して与えられた以下の説明から得られ得る。
図１は、ＮＲ−Ｕ ＬＢＴ ＭＡＣ手順のための例示的なシステムを示す。 図２は、ＮＲ−Ｕ ＬＢＴ ＭＡＣ手順に関連付けられた例示的な方法を示す。 図３は、ＮＲ−Ｕ ＬＢＴ ＭＡＣ手順に関連付けられた例示的な方法を示す。 図４は、ＮＲ−Ｕ ＬＢＴ ＭＡＣ手順に関連付けられた例示的な方法を示す。 図５は、ＮＲ−Ｕ ＬＢＴ ＭＡＣ手順に関連付けられた例示的な方法を示す。 図６は、ＮＲ−Ｕ ＬＢＴ ＭＡＣ手順に関連付けられた例示的な方法を示す。 図７は、ＮＲ−Ｕ ＬＢＴ ＭＡＣ手順に関連付けられた例示的な方法を示す。 図８は、ＮＲ−Ｕ ＬＢＴ ＭＡＣ手順に関連付けられた例示的な方法を示す。 図９は、ＮＲ−Ｕ ＬＢＴ ＭＡＣ手順に関連付けられた例示的な方法を示す。 図１０は、ＮＲ−Ｕ ＬＢＴ ＭＡＣ手順に関連付けられた例示的な方法を示す。 図１１は、ＮＲ−Ｕ ＬＢＴ ＭＡＣ手順の方法、システム、およびデバイスに基づいて生成され得る例示的なディスプレイ（例えば、グラフィカルユーザインタフェース）を示す。 図１２Ａは、例示的な通信システムを示す。 図１２Ｂは、ＲＡＮおよびコアネットワークを含む例示的なシステムを示す。 図１２Ｃは、ＲＡＮおよびコアネットワークを含む例示的なシステムを示す。 図１２Ｄは、ＲＡＮおよびコアネットワークを含む例示的なシステムを示す。 図１２Ｅは、別の例示的な通信システムを示す。 図１２Ｆは、ＷＴＲＵなどの例示的な装置またはデバイスのブロック図である。 図１２Ｇは、例示的なコンピューティングシステムのブロック図である。
例えば、アンライセンス周波数帯で動作する場合に、ＭＡＣ手順の適切な動作および性能を維持するのに役立つ、ＭＡＣ手順に関連付けられた方法、装置、およびシステムが本明細書に開示される。ＮＲ−ＵにおいてＬＢＴ失敗が発生した場合、既存のＭＡＣ手順が不適切なアクションを実行し、意図しない結果を招くことがある。
本明細書で取り上げられるＭＡＣ手順に関連する特定の問題には、とりわけ、帯域幅部分（Bandwidth Part：ＢＷＰ）動作手順、ランダムアクセス手順、パワーヘッドルーム報告（Power Headroom Reporting：ＰＨＲ）手順、Ｓｃｅｌｌアクティブ化または非アクティブ化手順、間欠受信手順、スケジューリング要求（Scheduling Request：ＳＲ）手順、バッファステータス報告手順、論理チャネル優先順位付け手順、またはＵＥおよびノードＢ（Node B：ＮＢ）ＭＡＣ手順の協調に関連付けられた問題が含まれ得る。
帯域幅部分動作手順の問題で、ＬＢＴ失敗が発生した場合、帯域幅部分非アクティブタイマが満了し、スケジュールすべきＵＬまたはＤＬデータがある場合でも、初期またはデフォルトＢＷＰに切り替わることがある。
ランダムアクセス手順の問題で、ＬＢＴ失敗が発生した場合、１）ランダムアクセス応答に対する十分な数（例えば、閾値数）の送信機会を許容にすることなく、ランダムアクセス応答ウィンドウが満了することがあり、２）プリアンブル送信を成功させるために必要な十分な数のプリアンブル送信を許容にすることなく、プリアンブル送信カウンタが最大送信数に達することがあり、３）ＭＳＧ３送信に応答する十分な数のＰＤＣＣＨ送信機会を許容にすることなく、競合解決タイマが満了することがあり、または、４）プリアンブル送信がない場合でもパワーランピングが増加し、その結果、不正確な電力設定になることがある。
パワーヘッドルーム報告（ＰＨＲ）手順問題で、ＬＢＴ失敗が発生した場合、１）ＮＢは、ＰＨＲがいつ計算され、その時点で何が送信されたかを判定することができないことがあり、その結果、不正確なパワーヘッドルームの判定が生じ、２）ＰＨＲ周期タイマ、再設定、ＳＣｅｌｌアクティブ化、ＰＳＣｅｌｌ追加、または、禁止タイマ満了によるＰＨＲのトリガが、不適切に早期発生することがあり、３）ＰＨＲ計算は、実際の送信を想定した場合に、パワーヘッドルームが不正確に計算されることがあり、または４）ＰＨＲ送信がなかった場合でも、ＰＨＲ禁止タイマが設定されることがある。
ＳＣｅｌｌアクティブ化／非アクティブ化手順問題で、ＬＢＴ失敗が発生した場合、ＳＣｅｌｌ上でスケジュールすべきＵＬまたはＤＬデータがある場合に、ＳＣｅｌｌを非アクティブ化して、ＳＣｅｌｌ非アクティブ化タイマが満了することがある。
間欠受信手順の問題で、ＬＢＴ失敗が発生した場合、ススケジュールすべきＵＬまたはＤＬデータがある場合に、ＰＤＣＣＨ受信を停止して、オンデュレーションタイマまたは非アクティブタイマが満了することがある。
スケジューリング要求手順の問題で、ＬＢＴ失敗が発生した場合、１）失敗したＳＲ送信はランダムアクセス手順を開始せず、２）ＳＲ送信がなかった場合でも、ＳＲ禁止タイマが設定されることがあり、３）ＳＲ送信を成功させるために必要な十分な数のＳＲ送信を許容することなく、ＳＲ送信カウンタが最大送信数に達することがあり、または、４）ＳＲ送信がない場合でも、ＳＲ保留がクリアされることがある。
バッファステータス報告手順問題で、ＬＢＴ失敗が発生した場合、ＵＬ−ＳＣＨリソースが利用可能な場合、ＢＳＲは送信されないことがあり、ＳＲはトリガされない。
論理チャネルの優先順位付け手順の問題で、ＬＢＴ失敗が発生した場合、ＭＡＣ ＰＤＵは、後続のグラントで送信できないことがあり、その結果、ユーザデータおよび制御シグナリングが損失する。
ＵＥおよびＮＢのＭＡＣ手順の協調問題で、ＬＢＴ失敗が発生した場合、ＵＥは、適切なアクションのためにＮＢに認識される必要があるＭＡＣ手順を達成するアクションを実行することがある。さらに、ＮＢは、ＵＥの挙動とは無関係なアクションを実行し得る。
前述の例の問題を考慮して、不適切なアクションを実行せず、意図しない結果が回避されるように、ＬＢＴ失敗を考慮し得る既存のＭＡＣ手順の修正または新しいＭＡＣ手順の作成が存在し得る。問題をどのように対処し得るかの概要を以下に示す。
図１は、ＮＲ−Ｕ ＬＢＴ ＭＡＣ手順のための例示的なシステムを示す。ステップ１１１において、ＵＥ１０１は、基地局１０２からＵＥ１０１へのチャネルアクセスに関する情報を取得する。情報は、基地局１０２からシグナリングされるダウンリンク情報であり得る。ステップ１１２において、ＵＥ１０１は、基地局１０２へのアップリンクチャネルアクセス（例えば、アップリンク情報）に関する情報を検出し得る。アップリンク情報は、リッスンビフォートーク（ＬＢＴ）動作または他の動作（例えば、３ＧＰＰ ＴＳ ３６．２１３ Ｖ１４．８．０セクション１５内の動作）を行うことによって検出され得る。ステップ１１３において、ステップ１１１またはステップ１１２の情報（例えば、アップリンク／ダウンリンク情報）に基づいて、ＭＡＣ手順の動作を達成し得る。ＭＡＣ手順は、本明細書に開示されているように、特に（例えば、ＰＨＲ、ＢＳＲ、ＢＦＤ）、ＬＢＴＲ１２１（例えば、図１０）、ＤＲＸ１２２（例えば、図６）、ＢＷＰ動作１２３（例えば、図２）、またはランダムアクセス１２４（例えば、図３）、スケジューリング要求１２５（例えば、図７）を含み得る。本明細書では、アップリンクまたはダウンリンクチャネルアクセス情報を上記のステップで使用し得ることが意図されている。
図２〜図１０は、ＮＲ−Ｕ ＬＢＴ ＭＡＣ手順に関連付けられた例示的な方法を示し、本明細書でより詳細に記載される。
図２は、帯域幅部分（ＢＷＰ）動作手順のための例示的な方法を示す。例えば、ステップ１３１では、１つ以上のＬＢＴ失敗（例えば、アップリンク／ダウンリンクＬＢＴ失敗の閾値数）が検出される。ステップ１３２において、ステップ１３１で検出された失敗に基づいて、ＢＷＰ非アクティブタイマを延長し得る。スケジュールすべきＵＬまたはＤＬデータが存在し得るので、初期またはデフォルトＢＷＰへの切り替えが回避され得るように、非アクティブタイマを延長し得る。ステップ１３３において、ステップ１３１で検出された失敗に基づいて、代替帯域幅部分に切り替える。
図３は、ランダムアクセス手順のための例示的な方法を示す。例えば、ステップ１４１において、１つ以上のＬＢＴ失敗（例えば、アップリンク／ダウンリンクＬＢＴ失敗の閾値数）が検出される。ステップ１４１で検出された失敗に基づいて、ＵＥ１０１はステップ１４２、１４３、１４４または１４５を実行し得る。ステップ１４２において、ランダムアクセス応答ウィンドウを延長し得る。ステップ１４２は、ランダムアクセス応答のための十分な数の送信機会を許容し得る。ステップ１４３において、プリアンブル送信カウンタはインクリメントされないことがある。ステップ１４３は、プリアンブル送信を成功させるために十分な数のプリアンブル送信を許容し得る。ステップ１４４において、競合解決タイマは延長され得、これは、ＭＳＧ３送信に応答して十分な数のＰＤＣＣＨ送信機会を許容し得る。ステップ１４５において、パワーランピングを増加させないようにし得、これは、適切な電力設定を維持するのに役立ち得る。ステップ１４６において、ＲＡ問題が上位層に示され、ＲＡ手順が不成功であると見なし得る。ステップ１４７において、代替帯域幅部分への切り替えがあり得る。本明細書では、ステップ１４２からステップ１４７のうちの１つ以上が、ステップ１４１に基づいて生じ得ることが意図されている。
図４は、パワーヘッドルーム報告手順のための例示的な方法を示す。例えば、ステップ１５１において、１つ以上のＬＢＴ失敗（例えば、アップリンク／ダウンリンクＬＢＴ失敗の閾値数）が検出される。ステップ１５１で検出された失敗に基づいて、ＵＥ１０１はステップ１５２、１５３、１５４、１５５、１５６、１５７または１５８を実行し得る。ステップ１５２において、ＵＥ１０１は、ＰＨＲが計算されたときを基地局１０２（例えば、ノードＢ）に示し得る。ステップ１５３において、ＵＥ１０１は、ＰＨＲ計算時に送信されたものを基地局１０２に示し得る。ステップ１５４において、ＵＥ１０１は、ＬＢＴ失敗が発生したときを基地局１０２に示し得る。ステップ１５５において、ＵＥ１０１は、ＰＨＲ送信に遅延があったことを基地局１０２に示し得る。ステップ１５６において、ＰＨＲ周期タイマ、再設定、ＳＣｅｌｌアクティブ化、ＰＳＣｅｌｌ追加、または禁止タイマ満了によるＰＨＲトリガリングが遅延し得る。ステップ１５７において、ＰＨＲ計算は、損失または遅延した送信を考慮に入れてもよい。ステップ１５８において、ＰＨＲ禁止タイマが設定されないか、または遅延し得る。
図５は、ＳＣｅｌｌアクティブ化／非アクティブ化手順のための例示的な方法を示す。例えば、ステップ１６１において、１つ以上のＬＢＴ失敗（例えば、アップリンク／ダウンリンクＬＢＴ失敗の閾値数）が検出される。ステップ１６１に基づいて、ステップ１６２において、ＳＣｅｌｌ非アクティブ化タイマは延長され得、これは、ＳＣｅｌｌ上での追加のＵＬまたはＤＬデータスケジューリング機会を許容し得る。
図６は、間欠受信手順のための例示的な方法を示す。例えば、ステップ１７１において、１つ以上のＬＢＴ失敗（例えば、アップリンク／ダウンリンクＬＢＴ失敗の閾値数）が検出される。ステップ１７１に基づいて、オンデュレーションまたは非アクティブタイマは延長され得、これは追加のＵＬまたはＤＬデータスケジューリング機会を許容し得る。ステップ１７３において、ＤＲＸショートサイクルタイマが適用され得る。ステップ１７４において、オンデュレーションまたは非アクティブタイマは、ＭＣＯＴ、ＣＷＳまたはＣＣＡと整合され得る。ステップ１７５において、ＤＲＸ設定が調整され得る。本明細書では、ステップ１７２からステップ１７５のうちの１つ以上が、ステップ１７１に基づいて生じ得ることが意図されている。
図７は、スケジューリング要求手順のための例示的な方法を示す。例えば、ステップ１８１において、１つ以上のＬＢＴ失敗（例えば、アップリンク／ダウンリンクＬＢＴ失敗の閾値数）が検出される。ステップ１８１で検出された失敗に基づいて、ＵＥ１０１はステップ１８２、１８３、１８４または１８５を実行し得る。ステップ１８２において、ランダムアクセス応答ウィンドウが開始され得る。ステップ１８３において、ＳＲ禁止タイマが設定されないか、または禁止タイマの設定が遅延し得る。ステップ１８４において、ＳＲ送信カウンタは、ＳＲ送信を成功させるために必要な十分な数のＳＲ送信を許容するために、インクリメントされないことがある。ステップ１８５において、ＳＲ保留がクリアされないか、またはＳＲ保留のクリアが遅延し得る。ステップ１８６において、代替帯域幅部分への切り替えがあり得る。本明細書では、ステップ１８２からステップ１８６のうちの１つ以上が、ステップ１８１に基づいて生じ得ることが意図されている。
図８は、バッファステータス報告手順のための例示的な方法を示す。例えば、ステップ１９１において、１つ以上のＬＢＴ失敗（例えば、アップリンク／ダウンリンクＬＢＴ失敗の閾値数）が検出される。ステップ１９２に基づいて、ＵＬ−ＳＣＨリソースが利用可能であっても、ＳＲがトリガされ得る。
図９は、論理チャネル優先順位付け手順のための例示的な方法を示す。例えば、ステップ２０１では、１つ以上のＬＢＴ失敗（例えば、アップリンク／ダウンリンクＬＢＴ失敗の閾値数）が検出される。ステップ２０１で検出された失敗に基づいて、ＵＥ１０１はステップ２０２または２０３を実行し得る。ステップ２０２において、ＭＡＣ ＰＤＵは構築されないことがある。ステップ２０３において、ＭＡＣ ＰＤＵは、再フォーマットされ得、これは、後続のグラントで送信可能にし得る。
図１０は、ＵＥ１０１がＬＢＴの失敗または成功情報を基地局１０２に報告するための例示的な方法を示し、これは、ＵＥ１０１と基地局ＭＡＣ手順との協調を改善することを可能にし得る。例えば、ステップ２１１において、１つ以上のＬＢＴ失敗（例えば、アップリンク／ダウンリンクＬＢＴ失敗の閾値数）が検出される。ステップ２１１に基づいて、ＵＥ１０１は、ＬＢＴ失敗を報告するか、またはどの手順がどのように影響を受けるかを報告し得る。ステップ２１３において、報告は、設定された期間内のＬＢＴ成功／失敗統計を含む。ステップ２１４において、報告は、タイミング情報、ＣＣＡ、ＭＣＯＴ、またはＣＷＳを含む。ステップ２１５において、送信禁止タイマは、報告の頻度を最小にするように設定される。本明細書では、ステップ２１２からステップ２１５のうちの１つ以上が、ステップ１８１に基づいて生じ得ることが意図されている。
図２〜図１０は、ＮＲ−Ｕ ＬＢＴ ＭＡＣ手順に関連付けられた例示的な方法を示す。複数のＮＲ−Ｕ ＬＢＴ ＭＡＣ手順を、以下でより詳細に記載する。
（ＭＡＣへのＮＲ−Ｕ ＬＢＴ動作の影響）
開示された主題は、全体的なＭＡＣ動作および多数の特定のＭＡＣ手順に適用され得る。これらのＭＡＣ手順は、帯域幅部分（ＢＷＰ）動作、ランダムアクセス（Random Access：ＲＡ）、パワーヘッドルーム報告（ＰＨＲ）、ＳＣｅｌｌアクティブ化および非アクティブ化、論理チャネル優先順位付け（Logical Channel Prioritization：ＬＣＰ）、間欠受信（Discontinuous Reception：ＤＲＸ）、スケジューリング要求（ＳＲ）、バッファステータス報告（Buffer Status Report：ＢＳＲ）、ならびに場合により新しいＬＢＴ ＭＡＣ手順などを含み得る。
ＬＢＴ失敗により、これらのＭＡＣ手順に不要で意図しない影響をもたらす可能性がある。ＬＢＴ失敗または成功の認識があれば、これらのＭＡＣ手順は、ＬＢＴを必要としないライセンス周波数帯における動作と同様に、および同様の性能で、動作することができる。第１のＭＡＣ手順（例えば、ランダムアクセス）で開示され得るステップ（例えば、アクション）は、第２のＭＡＣ手順（例えば、ＢＷＰオペレーション）に適用可能であり得ることが意図されている。したがって、ステップは一般に、特定のＭＡＣ手順に限定されない。
（ＵＬおよびＤＬの両方のＬＢＴ失敗に関する一般的な考慮事項）
ＭＡＣ手順への影響に関しては、ＵＬまたはＤＬにおいてＬＢＴ失敗が考慮されることがある。ＭＡＣ手順および手順内の特定のアクションによって、ＵＬおよびＤＬのＬＢＴ失敗の両方が考慮されることがあり、または、ＵＬのみもしくはＤＬのみのＬＢＴ失敗が考慮されることがある。さらに、ＬＢＴ表示がＭＡＣにどのように提供されるか、およびどの情報が提供されるかは、ＵＬおよびＤＬによって異なることがある。
ＵＬ ＬＢＴ動作の場合、ＰＨＹ層はＭＡＣに、ＬＢＴ成功または失敗を示し得る。ＵＬ ＬＢＴ成功もしくは失敗の表示は、ＵＬ送信に関連付けられてもよく、またはＵＬ ＬＢＴ手順は、ＵＬ送信とは独立して実行されてもよい。各ＵＬ ＬＢＴ成功または失敗の表示は、１つ以上のＭＡＣ手順と関連付けられ得る。
ＤＬ ＬＢＴ動作の場合、ＮＢはＵＥにＤＬ ＬＢＴ成功または失敗をシグナリングし得る。ＤＬ ＬＢＴの成功もしくは失敗の表示は、ＤＬ送信に関連付けられてもよく、またはＤＬ ＬＢＴ手順は、ＤＬ送信とは独立して実行されてもよい。各ＤＬ ＬＢＴ成功または失敗の表示は、１つ以上のＭＡＣ手順と関連付けられ得る。
ＭＡＣ手順、および手順内の特定のアクションによっては、関連する送信がない場合でもＬＢＴを実行するために必要な場合がある。現在のＭＡＣ手順では、チャネルへの常時アクセスが存在し、送信の停止またはブロッキングがないことを前提としているため、これが必要な場合がある。例えば、ＵＥがＭＡＣ手順においてダウンリンク割り当てまたはアップリンクグラントを検出しない場合、ダウンリンクまたはアップリンクにおいて送信のためにスケジュールすべきデータが存在しないという仮定があり得る。しかし、ＬＢＴ失敗によってブロックされているかまたは遅延している、送信のためにスケジュールすべきデータが存在することがある。この場合、ＭＡＣ手順は、意図しない結果または望ましくない結果をもたらし得るアクションを実行し得る。
本開示において、全体的なＭＡＣ動作または特定のＭＡＣ手順についてＬＢＴ失敗または成功が言及される場合、アップリンクＬＢＴまたはダウンリンクＬＢＴの両方が考慮され得る。ＭＡＣ手順および手順内の特定のアクションによって、ＵＬおよびＤＬのＬＢＴ失敗の両方が考慮されるか、または、ＵＬのみもしくはＤＬのみのＬＢＴ失敗が考慮される。
ＬＢＴ失敗および成功の両方を、ＭＡＣにシグナリングする、または示す必要はないことに留意すべきである。ＬＢＴ失敗の表示がない場合は成功と解釈され得、成功の表示がない場合は失敗と解釈され得る。ＰＨＹ層からのＵＬ ＬＢＴの表示はＬＢＴ失敗のみを示し得、ＮＢからのＤＬ ＬＢＴ表示はＬＢＴ成功のみを示し得る。
ＬＢＴ成功または失敗の表示は、既知の状況で周期的に提供されることもあり、またはＭＡＣ手順によって実行される特定のアクションによってトリガされる場合もある。ＤＬ ＬＢＴの成功または失敗は、ＮＢによって周期的にシグナリングされ得、ＵＬ ＬＢＴの成功または失敗は、特定のＭＡＣ手順の動作に応じてＰＨＹ層によって示され得る。周期的な表示は、ＭＡＣ手順により駆動されるオンデマンド表示により増大されることがあり、およびその逆もあることに留意されたい。
ＬＢＴの成功または失敗の表示は、特定のＬＢＴ手順の動作に関するものであることもあり、または表示は、既知の期間にわたる２つ以上のＬＢＴ手順の動作に関する情報を提供することもある。期間は、最後の報告以降の期間であり得る。ＵＬ ＬＢＴ表示は、特定のＬＢＴ手順の動作に起因することがあり、ＤＬ ＬＢＴ表示は、一定期間の複数（例えば、閾値数）のＬＢＴ動作に関する情報を提供し得る。
ＬＢＴの成功または失敗の表示は、ＬＢＴが実行されるキャリアおよびＢＷＰ（単数または複数）に関する情報を提供し得る。アップリンクまたはダウンリンクＬＢＴの成功または失敗の表示に加えて、さらなるＬＢＴ手順情報がＭＡＣ手順に提供されてもよい。ＭＡＣ手順では、ダウンリンクおよびアップリンクの送信機会が考慮される。これらのＭＡＣ手順を適切に動作させるためには、アップリンクおよびダウンリンクで送信を実行できる期間または実行できない期間を認識する必要がある場合がある。これを達成するために、ＬＢＴの成功もしくは失敗の表示に加えて、またはこれに含まれる、クリアチャネル評価（Clear Channel Assessment：ＣＣＡ）の期間、選択された最大チャネル占有時間（Maximum Channel Occupancy Time：ＭＣＯＴ）、選択されたコンテンションウィンドウサイズ（Contention Window Size：ＣＷＳ）、および他のタイミング情報がＭＡＣに提供され、ダウンリンクおよびアップリンク送信機会の適切な判定が可能になることが本明細書で開示される。ＭＣＯＴ、ＣＷＳ、または他のタイミングは、選択されたタイミングを表すチャネルアクセス優先度クラス（Channel Access Priority Class：ＣＡＰＣ）または別のインデックスによって特定され得る。
（ダウンリンクＬＢＴ成功／失敗の表示）
ＤＲＸサイクルを実行するために、ＵＥのＤＲＸオンデュレーションの間、ＤＬ ＬＢＴ成功の表示がＮＢからＵＥにシグナリングされ得ることが議論されてきた。これは、ＤＲＸ非アクティブタイマが実行されている期間、および場合によりＤＲＸアクティブ時間を構成する全ての期間を含むように延長されるべきである。例えば、ＵＥがＤＲＸオンデュレーション内にない間にランダムアクセスまたはスケジューリング要求手順が開始された場合、ＬＢＴが必要とされないときと同様の適切な動作および性能のために、ＬＢＴ失敗の認識が必要な場合がある。
さらに、この問題に対処するより包括的な方法として、ＵＥに既知の定期的な方法で連続的に送信されるＤＬ ＬＢＴ成功の表示を考慮して、ＤＲＸアクティブタイムの外で実行されるＭＡＣ手順がＤＬ ＬＢＴ成功および失敗の認識の恩恵を受けることができるようにする。
ＤＬ ＬＢＴ成功の表示は、新しい明示的信号であってもよく、または暗黙的に検出されてもよい。例えば、ＤＬ ＬＢＴ成功は、ＳＳＢまたはＤＲＳの受信によって暗黙的に検出され得、新しい明示的信号は、新しいＤＣＩフォーマット（例えば、個々のＵＥもしくはＵＥのグループにアドレス指定されるか、または全てのＵＥにブロードキャストされる）であり得る。
ＤＲＸオンデュレーションは一般的に異なるＵＥに対して時間がずれているため、ＤＬ ＬＢＴ成功の表示を周期的に連続的にシグナリングしても、必ずしも複雑さが増したり、またはリソースの使用が増えたりするわけではない。周期性に応じて、シグナリングオーバーヘッドは低減され得る。
また、シグナリングＤＬ ＬＢＴ表示は、ＵＥ固有のものか、またはＤＲＸオンデュレーションを共有するＵＥのグループに固有のものであってもよいことに留意すべきである。セル固有のＤＬ ＬＢＴ表示により、リソースのより効率的な使用、ならびに、より一貫したＭＡＣ手順の動作およびパフォーマンスをもたらすことができる。
また、ＬＢＴ成功の表示は、単一の表示ではなくてもよいと見なされる。また、シグナリングされた情報は、最後のＬＢＴ成功の表示以降の期間の情報も提供し得る。また、シグナリングされた情報は、ＮＢが、例えば、特定のチャネルまたはＢＷＰへの、ＤＬチャネルのアクセスをどれくらい有するかについての情報を提供し得る。この場合、ＭＡＣ手順は、ＤＬ ＬＢＴ成功または失敗の時間経過と共に連続的な認識を有し得、これにより、ＤＬ ＬＢＴ失敗によるＭＡＣ手順への影響がより正確になり得る。
ダウンリンク成功の表示はまた、ＭＡＣ手順が送信機会を正確に判定することができるようにするために、送信を行うことができるとき、および行うことができないときを特定するタイミング情報を提供し得る。これを達成するために、ＬＢＴの成功の表示に、クリアチャネル評価（ＣＣＡ）の期間、選択された最大チャネル占有時間（ＭＣＯＴ）、選択されたコンテンションウィンドウサイズ（ＣＷＳ）、もしくはダウンリンク送信機会の適切な判定を可能にするためにＭＡＣに提供される他のタイミング情報を追加されるか、または含められ得る。ＭＣＯＴ、ＣＷＳ、または他のタイミング情報は、選択されたタイミングを表すチャネルアクセス優先度クラス（ＣＡＰＣ）または別のインデックスによって特定され得る。
（アップリンクＬＢＴ成功／失敗の表示）
ＮＢがＬＢＴ失敗または成功ステータスをＵＥに示すことに加えて、ＵＥは、ＵＬ ＬＢＴ失敗または成功情報をＮＢに提供し得る。
本明細書に開示されているように、ＵＥ ＭＡＣ手順への複数の潜在的な影響が存在し得る。特定のＭＡＣ手順にＬＢＴ失敗または成功がどのように影響したかをＮＢが認識することが必要な場合がある、複数の事例が存在し得る。例えば、ＤＲＸアクティブタイムまたはＤＲＸサイクルが影響を受けた場合、ＮＢはＵＥが適切にスケジュールされるように認識しなければならない。
ＬＢＴ手順は、ＵＬ ＬＢＴ失敗をＮＢに示す以上のことを行ってもよい。大量のＵＬ ＬＢＴ失敗が発生した後、他のアクションが実行されることがある。本明細書で示すように、既存のＭＡＣ手順の動作は、ＬＢＴ失敗によって影響を受けることがある。新しいＬＢＴ手順は、ＬＢＴ失敗を解決するための新しいアクションを実行する可能性を有する。例えば、チャネルアクセス優先度は、ＬＢＴが成功する可能性を高めるように調整され得る。
ＬＢＴ失敗の総数がカウントされることがあり、これは、指定されたまたは設定された期間内であり得る。あるいは、ＬＢＴ失敗カウンタ（Failure Counters：ＦＣ）は、連続ＬＢＴ失敗をカウントし、ＬＢＴ成功時にＬＢＴ ＦＣをゼロにリセットしてもよい。ＬＢＴ失敗がカウントされ得る期間は、時間のスライディングウィンドウであってもよい。ＬＢＴ失敗カウンタが指定されたまたは設定された閾値を超過する場合、ＬＢＴ状態は失敗したと見なされ得る。指定もしくは設定された数のＬＢＴ失敗を超過していない場合、または指定もしくは設定された数のＬＢＴ成功の表示が受信される場合、ＬＢＴ状態は成功したと見なされ得る。ＭＡＣ手順は、ＭＡＣ手順に関連付けられた個々のＬＢＴ失敗をカウントするのではなく、ＬＢＴ状態をチェックし得る。ＭＡＣ手順では、ＬＢＴ状態に従ってカウンタとタイマを調整し得る。例えば、ＭＡＣ手順はカウンタおよびタイマを延長し得、またはＬＢＴ状態に応じてタイマおよびカウンタが最大閾値に達したと見なし得る。ＬＢＴ状態は、より高い層に示されることもある。例えば、ＲＲＣ手順に影響を与える。
ＵＬ ＬＢＴの成功または失敗の情報を提供するために、新しいＭＡＣ ＬＢＴ報告（LBT Report：ＬＢＴＲ）手順が定義され得る。ＬＢＴＲ ＭＡＣ ＣＥは、以前のＵＬ ＬＢＴ結果に関する履歴情報を提供し得る。これは、報告が生成されたときに対して、特定の期間にわたることがある。例えば、最後のＬＢＴＲ ＭＡＣ ＣＥが送信されてからの期間であり得る。ＭＡＣ ＣＥは、どのＭＡＣ手順（単数または複数）が影響を受けたか、またはいつＬＢＴ失敗が発生したかに関する情報を提供する場合があり、それによって、ＮＢは、どの手順（単数または複数）が影響を受けたかを相関させようと試み得る。ＬＢＴＲ ＭＡＣ ＣＥはまた、例えば、ＢＷＰ ＬＢＴが失敗する、およびＢＷＰ ＬＢＴが成功した場合のＬＢＴ結果に、ＢＷＰ情報を含んでもよい。ＲＲＣは、ＵＥ内に、ＬＢＴＲ報告期間を設定してもよい。
あるいは、ＵＬ物理制御シグナリングが、ＵＬ ＬＢＴ失敗または成功の表示を提供してもよい。これは、スケジュールされた、または新しいＵＬシグナリングの場合、ＰＵＣＣＨで伝送されるか、またはＰＵＳＣＨにピギーバックされ得る。周期的なＵＬシグナリングの受信の欠如は、ＵＥ ＬＢＴ失敗と解釈されることがある。これは、ＰＵＣＣＨまたは新しいＵＬシグナリングであり得る。新しいＵＬシグナリングは、ＮＢ受信が既知の物理的リソースおよび既知の時間に発生するように設定されなければならないことがある。
アップリンクＬＢＴ成功および失敗の表示はまた、ＭＡＣ手順が送信機会を正確に判定することができるようにするために、送信を行うことができるとき、および行うことができないときを特定するタイミング情報を提供し得る。これを達成するために、ＬＢＴ成功もしくは失敗の表示に加えて、またはこれに含まれる、クリアチャネル評価（ＣＣＡ）の期間、選択された最大チャネル占有時間（ＭＣＯＴ）、選択されたコンテンションウィンドウサイズ（ＣＷＳ）、または他のタイミング情報がＭＡＣに提供され、アップリンク送信機会の適切な判定が可能になることが提案されている。ＭＣＯＴ、ＣＷＳ、または他のタイミングは、選択されたタイミングを表すチャネルアクセス優先度クラス（ＣＡＰＣ）または別のインデックスによって特定され得る。
（ＭＡＣタイマおよびカウンタへのＬＢＴの影響）
ＬＢＴ失敗により、送信機会が損失する場合がある。また送信機会の損失により、送信の成功を達成するためのより長い時間にもつながる。ＭＡＣ手順は、手順の失敗を宣言する前に、送信機会の量および完了するまでの時間を考慮する。ＬＢＴが必要な場合にＭＡＣ手順を適切に実行するためには、送信機会の数、および場合によっては手順が正常に完了するまでの期間は、ＬＢＴ失敗を考慮する必要がある。
既存のＭＡＣ手順では、ＭＡＣ ＰＤＵがＰＨＹ層に与えられるとき、またはＰＨＹアップリンク制御情報（例えば、ＳＲ）を送信するためにＰＨＹに命令が与えられるとき、ＰＤＵもしくはＰＨＹアップリンク制御情報が送信されると仮定する。特定のＭＡＣ手順に関連付けられたＭＡＣ ＣＥが構築され、ＭＡＣ ＰＤＵに多重化されるとき、このＭＡＣ ＣＥが送信されると仮定され得る。特定のＭＡＣ手順に関連付けられたＭＡＣ ＣＥまたはＰＨＹアップリンク制御情報が送信され得る周波数を制限するために、ＭＡＣ ＣＥが構築され、ＭＡＣ ＰＤＵがＰＨＹ層に与えられるとき、またはＰＨＹアップリンク制御情報を送信するためにＰＨＹに命令が与えられるとき、禁止タイマが設定され得る。ＭＡＣ ＣＥまたはＰＨＹのアップリンク制御情報が送信され得る頻度を適切に制御し、必要なときに送信されることを確実するために、これらの禁止タイマの設定はまた、ＬＢＴの失敗を考慮してもよい。
処理ＭＡＣ手順のシーケンスもまた、考慮され得る。既存の手順は、ＰＨＹ層によってＬＢＴが実行される前に、ＭＡＣ手順が実行されるときに、カウンタおよびタイマをインクリメントし得る。既存のＭＡＣ手順への影響に関しては、複数の方法を考慮し得るが、これは、以下に関連してもよい。１）ＭＡＣがＰＨＹ層カウンタからＬＢＴ失敗の表示を受信し、送信失敗を考慮してタイマが調整される場合、２）ＬＢＴが成功してタイマおよびカウンタが動作する場合、または、３）最初のＭＡＣ手順が実行されてから、または最初に設定されてから、カウンタ（単数または複数）もしくはタイマ（単数または複数）がそれらの最大閾値に達するまでの期間に、ＬＢＴ失敗が記録される。
ＭＡＣがＰＨＹ層カウンタからＬＢＴ失敗の表示を受信すると、送信失敗を考慮するようにカウンタおよびタイマが調整される。ＭＡＣ手順が実行されたときにインクリメントされたカウンタは、手順が実行される前に設定されたものから変更されないようにデクリメントされ得る。これは、タイマの場合は、多少複雑になり得る。最適には、手順の最大時間は、ＬＢＴの失敗の期間を考慮すべきではない。ＬＢＴ失敗が発生したときのＭＡＣタイマの作用については、異なるＭＡＣ手順にタイマがどのように使用されるかによって、次のような複数の選択肢がある。ａ）ＬＢＴ失敗に関連付けられたＭＡＣ手順が実行されたときから、ＭＡＣ手順を実行する次の機会までの期間をタイマから減算するか、もしくは最大時間閾値に加算する（タイマが満了するとき）、ｂ）ＬＢＴ失敗表示の受信時にタイマを停止し、ＭＡＣ手順を実行する次の機会に再起動する、ｃ）ＬＢＴ失敗表示を受けてタイマを再起動する、または、ｄ）ＬＢＴ失敗に関連付けられたＭＡＣ手順のタイマを設定したとき（起動または再起動）から、ＭＡＣ手順のタイマを設定する次の機会までの期間を、タイマから減算するか、もしくは最大時間閾値に加算する（タイマが満了するとき）。
このアプローチに関する１つの懸念は、ＭＡＣ手順が実行された時間と、ＭＡＣ手順関連付けられたＬＢＴ失敗表示カウンタ（単数または複数）またはタイマ（単数または複数）の受信との間が最大値に達したときに、何が起こるかである。この問題に対処する１つの方法は、タイマまたはカウンタがその最大値に達したときに、ＭＡＣが前の送信に対するＬＢＴ表示を待っているか否かをチェックし、ＬＢＴ表示が成功したと判定された後にタイマまたはカウンタの満了に関連付けられたアクションのみを呼び出すことである。
ＬＢＴが成功すると、タイマおよびカウンタが作用する。この方法では、ＭＡＣ手順が実行されるとき、カウンタ（単数または複数）およびタイマ（単数または複数）は作用されない。ＬＢＴの成功表示時にカウンタがインクリメントされ、タイマがチェックまたは調整される。このアプローチの問題の１つは、ＬＢＴの成功表示時にタイマまたはカウンタがそれらの最大閾値に達した場合であり、これは、ＭＡＣ手順が異なるように実行されたことを意味する。この状況に対処するには、いくつかの選択肢がある。ＭＡＣ手順を実行するときに、タイマおよびカウンタは、手順実行時にタイマおよびカウンタが手順に従って調整されていた場合、それらの最大閾値に達していたか否かをチェックされ得、この場合、ＭＡＣ手順は、カウンタまたはタイマがそれらの最大閾値に達していたかのようにアクションを実行し得る。
ＬＢＴ失敗は、最初のＭＡＣ手順が実行されたとき、または最初に設定されたときから、ポイントカウンタ（単数または複数）またはタイマ（単数または複数）がそれらの最大閾値に達するまでの期間に記録され得る。タイマまたはカウンタが最大閾値に達すると、ＬＢＴ失敗の記録がチェックされ、ＬＢＴ失敗が発生した場合、手順はＬＢＴ失敗を考慮してタイマおよびカウンタを調整する。これを達成するには、以下の（ａ）または（ｂ）のような複数の選択肢があり得る。（ａ）最大閾値に達したときに実行されるアクションがこの時点で実行されないように、ＬＢＴ失敗の数またはＬＢＴ失敗の期間に応じて、タイマおよびカウンタの最大閾値が調整される、または、（ｂ）最大閾値に達したときに実行されるアクションがこの時点で実行されないように、失敗の数およびＬＢＴ失敗の期間に応じて、タイマおよびカウンタが再起動される。
タイマおよびカウンタに影響を及ぼすＬＢＴ失敗により、受け入れられない遅延（例えば、閾値に達する）が発生するか、またはＭＡＣ手順が際限なく停止することがある。ＭＡＣ手順カウンタおよびタイマが決して最大閾値に達しないことがある。したがって、開示されたＭＡＣ手順の変更は、連続的なまたは相当量のＬＢＴ失敗の可能性を考慮に入れ得る。この場合、ＭＡＣ手順は、各ＭＡＣ手順が適切に実行されるように、時間の最大延長またはカウンタの最大延長を考慮してもよい。例えば、ＭＡＣ手順カウンタ（MAC Procedure Counter：ＭＡＣ ＰＣ）およびＭＡＣ手順タイマ（MAC Procedure Timer：ＭＡＣ ＰＴ）の延長を制限することは、次の方法で対処し得る。１）ＭＡＣ手順ＬＢＴ失敗カウンタ（LBT Failure Counter：ＬＢＴ ＦＣ）、ＭＡＣ ＰＣおよびＭＡＣ ＰＴ延長カウンタ（Extension Counter：ＥＣ）、またはＭＡＣ ＰＣおよびＭＡＣ ＰＴ延長最大閾値（Extended Maximum Threshold：ＥＭＴ）。
ＭＡＣ手順ＬＢＴ失敗カウンタ（ＬＢＴ ＦＣ）、ＬＢＴ ＦＣは、ＬＢＴ失敗の総数をカウントし得、これは、指定されたまたは設定された期間内であり得る。あるいは、ＬＢＴ ＦＣは連続ＬＢＴ失敗をカウントしてもよく、ＬＢＴが成功するとＬＢＴ ＦＣはゼロにリセットされる。ＬＢＴ ＦＣ期間は、ＭＡＣ手順が完了するまでに許容される時間、または時間のスライディングウィンドウであり得る。特定のＭＡＣ手順では、２つ以上のＬＢＴ ＦＣを使用してもよい。ＭＡＣ手順が独立したアクションを並列に実行する場合、各手順はＬＢＴ ＦＣを有してもよい。ＬＢＴ ＦＣには、最大値が指定されているか、または設定されている場合がある。ＬＢＴ ＦＣが最大カウントに達すると、ＭＡＣ手順のＬＢＴ失敗時に、ＭＡＣ ＰＣまたはＭＡＣ ＰＴは延長されなくなる。あるいは、ＬＢＴ ＦＣが最大カウントに達すると、ＭＡＣ手順はＭＡＣ ＰＣまたはＭＡＣ ＰＴが最大値に達したかのようにアクションを実行する。これにより、ＭＡＣ手順が失敗したと見なされ得る。
ＭＡＣ ＰＣおよびＭＡＣ ＰＴ延長カウンタ（ＥＣ）、ＬＢＴ失敗により、ＭＡＣ ＰＣまたはＭＡＣ ＰＴの最大閾値が延長される。延長の基準は、指定されたまたは設定された期間内の、指定されたまたは設定されたＬＢＴ失敗の数であり得る。例えば、ＭＡＣ ＰＴの最大閾値あってもよい。ＥＣは、ＭＡＣ ＰＣまたはＭＡＣ ＰＴ延長の総数をカウントすることがあり、これは、指定されたまたは設定された期間内であり得る。あるいは、ＥＣは、ＭＡＣ ＰＣまたはＭＡＣ ＰＴ延長を連続してカウントしてもよい。ＥＣ期間は、ＭＡＣ手順が完了するまでに許容される時間、または時間のスライディングウィンドウであり得る。特定のＭＡＣ手順では、２つ以上のＥＣを使用してもよい。ＭＡＣ手順が独立したアクションを並列に実行する場合、各手順はＥＣを有してもよい。ＥＣは、指定された、または設定された最大値を有し得る。ＥＣが最大カウントに達すると、ＭＡＣ手順のＬＢＴ失敗時に、ＭＡＣ ＰＣまたはＭＡＣ ＰＴは延長されなくなる。あるいは、ＥＣが最大カウントに達すると、ＭＡＣ手順はＭＡＣ ＰＣまたはＭＡＣ ＰＴが最大値に達したかのようにアクションを実行し得る。これにより、ＭＡＣ手順が失敗したと見なされ得る。
ＭＡＣ ＰＣおよびＭＡＣ ＰＴ延長最大閾値（ＥＭＴ）、ＬＢＴ失敗により、ＭＡＣ ＰＣまたはＭＡＣ ＰＴの最大閾値が延長され得る。ＭＡＣ ＰＣまたはＭＡＣ ＰＴの最大閾値は、各ＬＢＴ失敗時に、または指定されたもしくは設定された期間内の指定されたもしくは設定された数のＬＢＴ失敗時に、延長され得る。例えば、期間は、現在のＭＡＣ ＰＴの最大閾値あってもよい。ＭＡＣ ＰＣまたはＭＡＣ ＰＴの最大閾値は、指定されたまたは設定された連続数のＬＢＴ失敗時に延長され得る。ＭＡＣ ＰＣまたはＭＡＣ ＰＴが指定されたまたは設定されたＥＭＴに到達すると、ＭＡＣ ＰＣまたはＭＡＣ ＰＴの最大閾値は延長されなくなり得る。これにより、ＭＡＣ手順が失敗したと見なし得る。
ＭＡＣ手順はまた、手順が実行される頻度を制御するために使用されるタイマを有してもよい。これらのタイマは、禁止タイマとしてとして知られ得る。いくつかのＭＡＣ手順が実行されると、禁止タイマは、その手順が再び実行されることが許される最も早い時間を設定する。ＭＡＣ手順は現在のところ、手順が実行されるときにこれらのタイマを設定する。これに対処するために、複数の方法またはシステムが使用され得る。例えば、１）禁止タイマは、手順の実行時に設定されなくてもよく、ＬＢＴ成功または失敗によって設定されたりされなかったりし得る。ＭＡＣ手順に関連付けられた送信のＬＢＴ成功時のみ、禁止タイマを設定すべきである。ＬＢＴ手順が成功するまでに時間がかかることがある。この場合、禁止タイマの開始は、ＭＡＣ手順が実行されたときに対して遅延し得る。これは、ＭＡＣ手順が実行される頻度が適切に制限されることを確実にするために必要な場合がある。または、２）ＭＡＣ手順の実行時に設定され得る禁止タイマは、ＭＡＣ手順に関連付けられた送信に対するＬＢＴ失敗表示が受信された場合にクリアされる。ＬＢＴ手順によって送信が遅延する場合、禁止タイマは、ＭＡＣ手順が実行されてからＬＢＴ成功が判定されるまでの時間を考慮するように延長され得る。
（スケジューリングおよび送信機会の損失）
ＭＡＣ手順はまた、ダウンリンク割り当ておよびアップリンクグラントも考慮され得る。ＬＢＴ失敗によって、ダウンリンク割り当ておよびアップリンクグラントが損失することがある。ＮＢがＬＢＴ失敗を判定した場合、ＰＤＣＣＨスケジューリング機会は損失し得る。また、ＰＤＣＣＨスケジューリングを受信しているにも関わらず、ＵＥがＬＢＴ失敗と判定した場合、アップリンク送信機会は損失する。
設定されたモニタリング期間内にダウンリンク割り当てまたはアップリンクグラントを受信しないことがある場合、複数のＭＡＣ手順がアクションを実行する。ＬＢＴ失敗またはＬＢＴ成功は、ダウンリンク割り当ておよびアップリンクグラントを受信しないことのＭＡＣ手順基準に考慮され得る。アップリンクまたはダウンリンクＬＢＴの成功、失敗に加えて、さらなるＬＢＴ手順情報がＭＡＣ手順に提供されてもよい。ＬＢＴの成功もしくは失敗の表示に加えて、またはこれに含まれる、クリアチャネル評価（ＣＣＡ）の期間、選択された最大チャネル占有時間（ＭＣＯＴ）、選択されたコンテンションウィンドウサイズ（ＣＷＳ）、または他のタイミング情報がＭＡＣに提供され、ダウンリンクおよびアップリンク送信機会の適切な判定が可能になる。ＭＣＯＴ、ＣＷＳ、または他のタイミングは、選択されたタイミングを表すチャネルアクセス優先度クラス（ＣＡＰＣ）または別のインデックスによって特定され得る。
設定されたモニタリング期間中に、ダウンリンク割り当てもしくはアップリンクグラントを受信し得ない場合、ＬＢＴ失敗が検出される場合、またはＬＢＴ成功が検出されない場合は、複数のオプションが考慮され得る。
・モニタリング期間中にＬＢＴ成功が検出されなかった場合は、ＭＡＣ手順によるアクションは実行されないことがある。
・モニタリング期間内に、ＬＢＴ成功または連続ＬＢＴ成功検出の設定された最小閾値に到達しない場合、ＭＡＣ手順によるアクションは実行されないことがある。
・モニタリング期間中にＬＢＴ失敗が検出された場合、ＭＡＣ手順によるアクションは実行されないことがある。
・モニタリング期間内に、ＬＢＴ失敗または連続ＬＢＴ失敗の設定された最大閾値に達した場合は、ＭＡＣ手順によるアクションは実行されないことがある。
・アップリンクまたはダウンリンク送信機会の数もしくは期間は、ＣＣＡ、ＭＣＯＴ、ＣＷＳ、または他のタイミング情報からより正確に判定され得る。
ＭＡＣ手順によって実行されないアクションとは、設定されたモニタリング期間中にダウンリンク割り当てまたはアップリンクグラントが受信されない場合に、現在指定されているＭＡＣ手順によって行われていた可能性のあるアクションである。例えば、
・ＢＷＰ非アクティブタイマの実行中にＬＢＴ失敗が検出された場合、またはＬＢＴ成功が検出されなかった場合は、この期間中にダウンリンク割り当てまたはアップリンクグラントが受信されなかった場合でも、初期またはデフォルトＢＷＰへのＢＷＰ切り替えは実行されない。
・その間にＤＲＸアクティブタイムＬＢＴ失敗が検出された場合、またはＬＢＴ成功が検出されなかった場合は、この期間にダウンリンク割り当てまたはアップリンクグラントが受信されなかった場合でも、ＤＲＸ非アクティブがリセットされ得る。
ＬＢＴ失敗によりアップリンク送信ができない場合も、ＭＡＣ手順を考慮する必要があり得る。ＭＡＣ手順への影響は、ＬＢＴ失敗によってＰＤＣＣＨスケジューリング機会が損失した場合と同じである。ＭＡＣ手順は、アップリンクグラントが受信されない場合、または送信可能なデータに対してアップリンクグランドが受け入れられない場合（例えば、ＬＣＰ制限）に、ＬＢＴによるＵＬ送信失敗を、現在実行されているのと同じであると見なし得る。例えば、ＬＢＴ失敗後のバックオフ期間中に、ＭＡＣ手順は、アップリンクグラントが受信されない場合、または、送信可能なデータに対してアップリンクグラントが受け入れられない場合（例えば、ＬＣＰ制限）、現在のように振る舞い得る。
従来のＭＡＣ手順は、ＭＡＣ ＰＤＵがＰＨＹ層に提供されるとき、それが送信されると仮定し得る。ＬＢＴを実行する場合は、必ずしもそうとは限らない。したがって、ＭＡＣ ＰＤＵ送信を参照するＭＡＣ手順では、送信がＬＢＴ成功または失敗を考慮していることを明確にするべきである。これは、ＭＡＣ手順内のＬＢＴ成功を参照するか、またはＭＡＣ ＰＤＵ送信基準にＬＢＴ成功が含まれることを明確にすることによって達成され得る。
ＭＡＣ ＰＤＵの多重化およびアセンブリが再実行されたときに、トリガが再評価され、報告された値が再計算されるように、ＭＡＣ ＣＥは回復して保存されるか、またはこれらのＭＡＣ ＣＥをトリガしたイベントが復元され得る。
（特定のＭＡＣ手順へのＮＲ−Ｕ ＬＢＴの影響）
（特定のＭＡＣ手順へのＮＲ−Ｕ ＬＢＴの影響）
新しいＬＢＴ ＭＡＣ手順が導入され得る。この手順は、ＬＢＴの失敗または成功をＮＢに通知するために使用され得る。本明細書に記載されているように、ＵＥ ＭＡＣ手順への複数の可能性のある影響が存在し得る。多くの場合、ＮＢは適切な動作のためにこれらのＭＡＣ手順への影響を認識することが必要な場合がある。
ＬＢＴ失敗によって影響を受ける各ＵＥ ＭＡＣ手順は、それぞれのＭＡＣ手順に対するＵＥとＮＢ間の協調を維持するために、ＮＢへの効果をシグナリングする可能性がある。しかし、これには、多くのＭＡＣ手順にさらなる複雑さを導入する必要があり得る。
例示的な方法は、ＮＢがＬＢＴ情報を考慮し、ＬＢＴ動作によってこれらの手順の変更された振る舞いを実現することにより、他のＭＡＣ手順に対するその振る舞いを調整できるように、ＮＢにＬＢＴ状態（例えば、成功または失敗）を示す新しい個別のＭＡＣ手順を定義することである。
したがって、ＵＥ ＰＨＹ層のＬＢＴ成功または失敗表示がＭＡＣに提供される場合がある。ＰＨＹ層は、ＭＡＣ層とＰＨＹ層との間でシグナリングされるプリミティブの量を制限するために、何らかの前処理を行うことが可能である。新しいＬＢＴ ＭＡＣ手順では、これらのＬＢＴ表示を統合して、リッスンビフォートーク報告（ＬＢＴＲ）ＭＡＣ制御要素（Control Element：ＣＥ）を生成し得、これにより、一定期間のＬＢＴ失敗または成功に関する情報を提供し得る。ＵＥ ＰＨＹ層は、ＬＢＴ成功または失敗表示に加えて、ＬＢＴタイミング情報をＭＡＣ層に提供してもよい。例えば、ＬＢＴタイミング情報は、ＣＣＡ期間を含み、ＭＣＯＴまたはＣＷＳ期間を選択し得る。
ＬＢＴＲは、ＵＬおよびＤＬのＬＢＴ失敗を別々に提供し得る。ＵＬ ＬＢＴ失敗はＮＢにとって未知であることがあり、ＭＡＣ手順の協調を維持するためにシグナリングする必要がある。しかし、ＵＥが認識しているＤＬ ＬＢＴ失敗もＮＢにとって有用である可能性がある。なぜなら、ＵＥにシグナリングされるか、または別の方法でＵＥによって検出されるＤＬ ＬＢＴ失敗がＵＥによって実現されたとＮＢが想定できないことがあるからである。ＵＥがＮＢ ＤＬ ＬＢＴ失敗もしくは成功表示を逃したか、または受信に失敗した可能性がある。
ＬＢＴＲ手順は、ＬＢＴＲを送信する場合につながる手順を開始するために１つ以上のトリガを必要とすることがある。トリガには、以下の１つ以上の方法が含まれ得る。第１の方法では、閾値に達するＬＢＴ失敗が、トリガとなり得る。ＲＲＣが設定したＬＢＴ失敗閾値が存在し得る。この閾値は、既知の期間にわたるＬＢＴ失敗の閾値数、または連続ＬＢＴ失敗の閾値数であってもよい。報告の緊急度は、サポートされるトラフィックのタイプに依存することがあるため、これらのパラメータが設定可能である必要があり得る。第２の方法では、トリガは、他のＭＡＣ手順に対するある種の影響が、適切な動作のためにＮＢによって認識される必要があるその手順の動作変化をもたらすときであり得る。例えば、アクティブタイムまたはＤＲＸサイクルに影響するＤＲＸ動作の変更である。この場合、ＭＡＣ ＤＲＸ手順がＬＢＴＲをトリガする。第３の方法では、トリガは、ＲＲＣが設定した周期的なＬＢＴＲに基づき得る。第４の方法では、トリガは、ＬＢＴＲの頻度を制限するために導入されるＬＢＴＲ禁止タイマに基づき得る。
ＬＢＴＲ手順は、設定されたＬＢＴＲモニタリング期間にわたってＬＢＴ失敗または成功をカウントし得る。例えば、
・ＬＢＴＲモニタリング期間内、ＬＢＴ失敗カウントが、設定されたＬＢＴ失敗カウントより大きい場合、ＬＢＴＲがトリガされ得る。
・ＬＢＴＲモニタリング期間内、ＬＢＴ成功カウントが、設定されたＬＢＴ成功最小値未満の場合、ＬＢＴＲがトリガされ得る。
設定されたＬＢＴＲモニタリング期間にわたって、ＬＢＴＲ手順は、連続ＬＢＴ失敗または成功をカウントし得る。
・ＬＢＴＲモニタリング期間内、連続ＬＢＴ失敗カウントが、設定されたＬＢＴ失敗カウントより大きい場合、ＬＢＴＲがトリガされ得る。
・ＬＢＴＲモニタリング期間内、連続ＬＢＴ成功カウントが、設定された連続ＬＢＴ成功最小値未満の場合、ＬＢＴＲがトリガされ得る。
他のＭＡＣ手順がＬＢＴＲをトリガする場合、これは、ＬＢＴＲ保留表示を設定することによってであり得る。ＬＢＴＲ保留表示は、後でＭＡＣ ＰＤＵ多重化アセンブリ中にチェックされ、ＬＢＴＲ ＭＡＣ ＣＥが構築されることを確認する。
ＬＢＴＲには、以下の情報が含まれ得る。
・最後のＬＢＴＲ以降のＬＢＴ失敗または成功のカウント
・最後のＬＢＴＲ以降、ＬＢＴ失敗または連続ＬＢＴ失敗が、設定されたＬＢＴ失敗の最大閾値を超えた回数
・最後のＬＢＴＲ以降、ＬＢＴ成功カウントまたは連続ＬＢＴ成功カウントが、設定された連続ＬＢＴ成功最小値未満の回数
・ＵＬ ＬＢＴ失敗に加えて、ＵＥによって検出されたＤＬ ＬＢＴ失敗も報告されることがある
・ＬＢＴＲをトリガしたＭＡＣ手順
・ＬＢＴＲ ＰＤＵがいつ構築されるかに関連したタイムスタンプ。
・ＣＣＡ、ＭＣＯＴ、またはＣＷＳ情報
ＰＨＹ層またはＲＲＣ層によって同様の動作が提供されてもよく、ＰＨＹ層またはＲＲＣ層シグナリングを使用して同様の情報をＮＢに伝達してもよいことに留意すべきである。
ＲＲＣは、ＵＥ内に、ＬＢＴＲ ＭＡＣ ＣＥに指定された論理チャネルにマッピングされたチャネルアクセス優先度クラスの優先度を設定してもよい。あるいは、アクセス優先度クラスを最も優先度の高いチャネルアクセス優先度クラスとして指定してもよい。ＬＢＴＲ手順はまた、一般的なＬＢＴ状態判定手順を含んでもよく、または独立したＬＢＴ状態手順がＬＢＴＲおよび他のＭＡＣ手順によって利用されてもよい。この方法は、各ＭＡＣ手順に導入される複雑さを最小限にする。例えば、各ＭＡＣ手順がその手順に影響を及ぼすＬＢＴ失敗をカウントするのではなく、ＬＢＴ状態がチェックされるだけである。
ＬＢＴ失敗の総数がカウントされることがあり、これは、指定されたまたは設定された期間内であり得る。あるいは、ＬＢＴ ＦＣは連続ＬＢＴ失敗をカウントしてもよく、ＬＢＴが成功するとＬＢＴ ＦＣはゼロにリセットされる。ＬＢＴ失敗がカウントされ得る期間は、時間のスライディングウィンドウであってもよい。ＬＢＴ失敗カウンタが指定されたまたは設定された閾値を超過する場合、ＬＢＴ状態は失敗したと見なされる。指定もしくは設定された数のＬＢＴ失敗が受信されなかった場合、または指定もしくは設定された数のＬＢＴ成功の表示が受信される場合、ＬＢＴ状態は成功したと見なされる。ＭＡＣ手順は、ＭＡＣ手順に関連付けられた個々のＬＢＴ失敗をカウントするのではなく、ＬＢＴ状態をチェックすることがある。ＭＡＣ手順では、ＬＢＴ状態に従ってカウンタおよびタイマを調整し得る。例えば、ＭＡＣ手順はカウンタおよびタイマを延長し得、またはＬＢＴ状態に応じてタイマおよびカウンタが最大閾値に達したと見なし得る。ＬＢＴ状態は、より高い層に示されることもある。例えば、ＲＲＣ手順を行う。
（ＢＷＰ動作手順）
ＢＷＰ動作手順の以下の修正は、ＮＲ−ＵにおけるＬＢＴ動作の影響を考慮に入れてもよい。
ＬＢＴ失敗により、ＢＷＰ非アクティブタイマの期間中にダウンリンク割り当ておよびアップリンクグラントをブロックすることがある。この場合、ＢＷＰをデフォルトまたは初期ＢＷＰ（単数または複数）への切り替えを行うことは不適切であり得る。
ＢＷＰ非アクティブタイマが動作している間にＬＢＴ失敗と判定された場合、アクティブなＤＬ ＢＷＰに関連付けられたＢＷＰ非アクティブタイマは延長されるべきである。これは、ＬＢＴ失敗によってダウンリンク割り当ておよびアップリンクグラントが損失し得る場合に、デフォルトまたは初期ＢＷＰへのＢＷＰ切り替えが実行されないことを確実にするために、必要な場合がある。デフォルトまたは初期ＢＷＰへのＢＷＰ切り替えは、ＢＷＰ非アクティビティタイマの実行中に、実際には送信するデータがない場合にのみ実行されるべきである。本明細書における実施例は、ＭＡＣ仕様３ＧＰＰ ＴＳ ３８．３２１、（ＮＲ）、メディアアクセス制御（ＭＡＣ）プロトコル仕様、Ｖ１５．２．０を参照してもよい（また、本明細書では［２］として参照される）。例示的な修正の多くは、本明細書において下線が引かれている。例えば、ＭＡＣ仕様を以下のように修正してもよい。
ｂｗｐ−ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒが設定されている場合、ＭＡＣエンティティは、アクティブ化された各サービングセルに対して、以下であるものとする。
１＞ｄｅｆａｕｌｔＤｏｗｎｌｉｎｋＢＷＰが設定されていて、アクティブなＤＬ ＢＷＰがｄｅｆａｕｌｔＤｏｗｎｌｉｎｋＢＷＰによって示されたＢＷＰでない場合、または、
１＞ｄｅｆａｕｌｔＤｏｗｎｌｉｎｋＢＷＰが設定されておらず、アクティブなＤＬ ＢＷＰがｉｎｉｔｉａｌＤｏｗｎｌｉｎｋＢＷＰでない場合、
２＞ダウンリンクの割り当てもしくはアップリンクグラントを示すＣ−ＲＮＴＩもしくはＣＳ−ＲＮＴＩ宛てのＰＤＣＣＨが、アクティブなＢＷＰで受信された場合、または、
２＞ダウンリンクの割り当てもしくはアップリンクグラントを示すＣ−ＲＮＴＩもしくはＣＳ−ＲＮＴＩ宛てのＰＤＣＣＨが、アクティブなＢＷＰに対して受信された場合、または、
２＞ＭＡＣ ＰＤＵが、設定されたアップリンクグラントで送信された場合もしくは設定されたダウンリンク割り当てで受信された場合、または、
２＞アクティブなＢＷＰでＬＢＴ失敗が検出された場合、
３＞このサービングセルに関連付けられた現行のランダムアクセス手順がない場合、または、
３＞Ｃ−ＲＮＴＩ宛てのこのＰＤＣＣＨの受信時に、このサービングセルに関連付けられた現行のランダムアクセス手順が正常に完了した場合（例えば、［２］の５．１．４節および５．１．５節に関して規定されたとおり）、
４＞アクティブなＤＬ ＢＷＰに関連付けられたｂｗｐ−ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒを起動または再起動する。
この基準はまた、ＢＷＰ非アクティブが実行されている間のＬＢＴ成功検出に基づいていてもよい。例えば、
ｂｗｐ−ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒが設定されている場合、ＭＡＣエンティティは、アクティブ化された各サービングセルに対して、以下であるものとする。
１＞ｄｅｆａｕｌｔＤｏｗｎｌｉｎｋＢＷＰが設定されていて、アクティブなＤＬ ＢＷＰがｄｅｆａｕｌｔＤｏｗｎｌｉｎｋＢＷＰによって示されたＢＷＰでない場合、または、
１＞ｄｅｆａｕｌｔＤｏｗｎｌｉｎｋＢＷＰが設定されておらず、アクティブなＤＬ ＢＷＰがｉｎｉｔｉａｌＤｏｗｎｌｉｎｋＢＷＰでない場合、
２＞ダウンリンクの割り当てもしくはアップリンクグラントを示すＣ−ＲＮＴＩもしくはＣＳ−ＲＮＴＩ宛てのＰＤＣＣＨが、アクティブなＢＷＰで受信された場合、または、
２＞ダウンリンクの割り当てもしくはアップリンクグラントを示すＣ−ＲＮＴＩもしくはＣＳ−ＲＮＴＩ宛てのＰＤＣＣＨが、アクティブなＢＷＰに対して受信された場合、または、
２＞ＭＡＣ ＰＤＵが、設定されたアップリンクグラントで送信された場合もしくは設定されたダウンリンク割り当てで受信された場合、または、
２＞アクティブなＢＷＰでＬＢＴ成功が検出されなかった場合、
３＞このサービングセルに関連付けられた現行のランダムアクセス手順がない場合、または、
３＞Ｃ−ＲＮＴＩ宛てのこのＰＤＣＣＨの受信時に、このサービングセルに関連付けられた現行のランダムアクセス手順が正常に完了した場合（例えば、［２］の５．１．４節および５．１．５節に関して規定されたとおり）、
４＞アクティブなＤＬ ＢＷＰに関連付けられたｂｗｐ−ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒを起動または再起動する。
ＬＢＴ失敗は、単一のインスタンスではないことがある。ＢＷＰ非アクティブタイマが実行している間の、複数のＬＢＴ失敗または成功の検出であり得る。また、本明細書に示されるように、ＬＢＴ失敗または成功は、アップリンクＬＢＴまたはダウンリンクＬＢＴの両方を参照する。
一定期間のＬＢＴ失敗もしくはＬＢＴ成功をカウントする、または一定期間の連続ＬＢＴ失敗もしくは連続ＬＢＴ成功をカウントするように手順を定義してもよい。ＬＢＴ失敗もしくは連続ＬＢＴ失敗が、設定された最大ＬＢＴ失敗閾値を超えた場合、またはＬＢＴ成功もしくは連続ＬＢＴ成功が、設定された最小ＬＢＴ成功閾値未満であり得る場合にのみ、ＢＷＰ非アクティブタイマが再起動される。例えば、ＭＡＣ仕様を以下のように修正してもよい。
ｂｗｐ−ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒが設定されている場合、ＭＡＣエンティティは、アクティブ化された各サービングセルに対して、以下であるものとする。
１＞ｄｅｆａｕｌｔＤｏｗｎｌｉｎｋＢＷＰが設定されていて、アクティブなＤＬ ＢＷＰがｄｅｆａｕｌｔＤｏｗｎｌｉｎｋＢＷＰによって示されたＢＷＰでない場合、または、
１＞ｄｅｆａｕｌｔＤｏｗｎｌｉｎｋＢＷＰが設定されておらず、アクティブなＤＬ ＢＷＰがｉｎｉｔｉａｌＤｏｗｎｌｉｎｋＢＷＰでない場合、
２＞ダウンリンクの割り当てもしくはアップリンクグラントを示すＣ−ＲＮＴＩもしくはＣＳ−ＲＮＴＩ宛てのＰＤＣＣＨが、アクティブなＢＷＰで受信された場合、または、
２＞ダウンリンクの割り当てもしくはアップリンクグラントを示すＣ−ＲＮＴＩもしくはＣＳ−ＲＮＴＩ宛てのＰＤＣＣＨが、アクティブなＢＷＰに対して受信された場合、または、
２＞ＭＡＣ ＰＤＵが、設定されたアップリンクグラントで送信された場合もしくは設定されたダウンリンク割り当てで受信された場合、または、
２＞ＬＢＴ失敗カウントが、アクティブなＢＷＰでＬＢＴ失敗閾値を超えた場合、
３＞このサービングセルに関連付けられた現行のランダムアクセス手順がない場合、または、
３＞Ｃ−ＲＮＴＩ宛てのこのＰＤＣＣＨの受信時に、このサービングセルに関連付けられた現行のランダムアクセス手順が正常に完了した場合（例えば、［２］の５．１．４節および５．１．５節に関して規定されたとおり）、
４＞アクティブなＤＬ ＢＷＰに関連付けられたｂｗｐ−ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒを起動または再起動して、
４＞ＬＢＴ失敗カウントをリセットする。
上記の手順において、ＬＢＴ失敗が検出されたとは、ＢＷＰ非アクティブタイマが動作している期間、アクティブなＤＬ ＢＷＰ上でＢＷＰ切り替え用のＰＤＣＣＨを受信したとき、または、アクティブなＢＷＰ上もしくはＢＷＰ用のアップリンクグラントのＰＤＣＣＨを受信したとき、または設定されたグラントのためにＭＡＣ ＰＤＵを送信もしくは受信したときから、ＢＷＰ非アクティブタイマが満了する時点までの期間に適用されることに留意すべきである。
ＢＷＰ非アクティブタイマは、初期設定値とは異なる期間だけ延長され得る。ＢＷＰ非アクティブタイマが延長される期間は、別の設定値であってもよく、または検出されたＬＢＴの失敗もしくは判定された成功の量に応じた値であってもよい。
また、ＬＢＴ失敗により、設定されたＢＷＰ間の切り替えがトリガされることがある。ＬＢＴ失敗は、単一のインスタンスではないことがある。指定されたまたは設定された期間内の複数のＬＢＴ失敗または成功の検出であってもよい。また、本明細書に示されるように、ＬＢＴ失敗または成功は、アップリンクＬＢＴまたはダウンリンクＬＢＴを参照することがある。
一定期間のＬＢＴ失敗もしくはＬＢＴ成功をカウントする、または一定期間の連続ＬＢＴ失敗もしくは連続ＬＢＴ成功をカウントするように手順を定義してもよい。ＬＢＴ失敗もしくは連続ＬＢＴ失敗が設定された最大ＬＢＴ失敗閾値を超えた場合、またはＬＢＴ成功もしくは連続ＬＢＴ成功が設定された最小ＬＢＴ成功閾値未満である場合にのみ、アクティブなＢＷＰは、別の設定されたアクティブなＢＷＰに切り替えられる。
また、ＵＥが初期もしくはデフォルトＢＷＰに決して戻らないように、ＢＰＷ非アクティブタイマを大幅に延長すること、またはＬＢＴ失敗により非アクティブタイマを無期限に延長することを回避するために必要な場合がある。その場合、ＢＷＰ非アクティブタイマの再起動は、指定されたまたは設定された最大値に制限され得る。例えば、ＭＡＣ仕様を以下のように修正してもよい。
１＞アクティブなＢＷＰで、ＢＷＰ−Ｉｎａｃｔｉｖｉｔｙ−ＬＢＴ−Ｆａｉｌｕｒｅ−Ｃｏｕｎｔ＞ＢＷＰ−Ｉｎａｃｔｉｖｉｔｙ−ＬＢＴ Ｆａｉｌｕｒｅ Ｔｈｒｅｓｈｏｌｄである場合、および、
１＞ＬＢＴ−ＢＷＰ−ＩｎａｃｔｉｖｉｔｙＲｅｓｔａｒｔＣｏｕｎｔ＜＝ＬＢＴ−ＢＷＰ−Ｉｎａｃｔｉｖｉｔｙ−Ｒｅｓｔａｒｔ−Ｔｈｒｅｓｈｏｌｄである場合、
２＞ＢＷＰ−Ｉｎａｃｔｉｖｉｔｙ−ＬＢＴ−Ｆａｉｌｕｒｅ−Ｃｏｕｎｔを０に設定して、
２＞ＬＢＴ−ＢＷＰ−ＩｎａｃｔｉｖｉｔｙＲｅｓｔａｒｔＣｏｕｎｔを１だけインクリメントして、
２＞アクティブなＤＬ ＢＷＰに関連付けられたｂｗｐ−ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒを起動または再起動する。

１＞ＬＢＴ失敗が検出された場合、
２＞ＢＷＰ−Ｉｎａｃｔｉｖｉｔｙ−ＬＢＴ−Ｆａｉｌｕｒｅ−Ｃｏｕｎｔをインクリメントする。

ＬＢＴ ＢＷＰ非アクティブ再起動閾値を超えた場合、以下のアクションを実行してもよい。
１＞ＬＢＴ−ＢＷＰ−ＩｎａｃｔｉｖｉｔｙＲｅｓｔａｒｔＣｏｕｎｔ＞ＬＢＴ−ＢＷＰ−Ｉｎａｃｔｉｖｉｔｙ−Ｒｅｓｔａｒｔ−Ｔｈｒｅｓｈｏｌｄである場合、
２＞デフォルトまたは初期ＢＷＰへのＢＷＰ切り替えが実行されて、
２＞ＢＷＰを特定する表示が上位層に送信されて、
２＞ＳＣｅｌｌが非アクティブ化される。
（ランダムアクセス手順）
（ランダムアクセス応答受信）
ランダムアクセス応答受信手順の以下の修正は、ＮＲ−ＵにおけるＬＢＴの影響を考慮に入れてもよい。
ＲＡ応答ウィンドウが満了しても、プリアンブル送信以降にＬＢＴ失敗が検出された場合、ＲＡ応答ウィンドウを延長し得る。これは、ＮＢがプリアンブル送信を受信していても、ＬＢＴ失敗によりランダムアクセス応答が遅延している場合に必要になり得る。ＮＢが送信機会を逃したことをＵＥが検出するとき、ＲＡ応答ウィンドウを延長し得る。
例えば、ＭＡＣ仕様を以下のように修正してもよい。
１＞ＲＡＣＨ−ＣｏｎｆｉｇＣｏｍｍｏｎに設定されているｒａ−ＲｅｓｐｏｎｓｅＷｉｎｄｏｗが満了し、送信されたＰＲＥＡＭＢＬＥ＿ＩＮＤＥＸに一致するランダムアクセスプリアンブル識別子を含むランダムアクセス応答を受信していない場合、
１＞ＢｅａｍＦａｉｌｕｒｅＲｅｃｏｖｅｒｙＣｏｎｆｉｇに設定されたｒａ−ＲｅｓｐｏｎｓｅＷｉｎｄｏｗが満了した場合、およびＣ−ＲＮＴＩ宛てのＰＤＣＣＨを受信していない場合、
２＞ＬＢＴ失敗が検出された場合、
３＞ＭＡＣエンティティによってビーム障害回復要求のための競合なしランダムアクセスプリアンブルが送信された場合、
４＞ＢｅａｍＦａｉｌｕｒｅＲｅｃｏｖｅｒｙＣｏｎｆｉｇに設定したｒａ−ＲｅｓｐｏｎｓｅＷｉｎｄｏｗを再起動して、
４＞ｒａ−ＲｅｓｐｏｎｓｅＷｉｎｄｏｗが動作している間、Ｃ−ＲＮＴＩで特定されるビーム障害回復要求に対する応答をＳｐＣｅｌｌのＰＤＣＣＨで監視し、
３＞さもなければ、
４＞ＲＡＣＨ−ＣｏｎｆｉｇＣｏｍｍｏｎに設定されたｒａ−ＲｅｓｐｏｎｓｅＷｉｎｄｏｗを再起動して、
４＞ｒａ−ＲｅｓｐｏｎｓｅＷｉｎｄｏｗが実行されている間、ＲＡ−ＲＮＴＩによって特定されるランダムアクセス応答（単数または複数）に対するＳｐＣｅｌｌのＰＤＣＣＨを監視し、
２＞さもなければ（ＬＢＴ失敗は検出されず）、
３＞ランダムアクセス応答の受信が成功しなかったと見なす。
上記の手順において、ＬＢＴ失敗が検出されたとは、ＲＡ応答ウィンドウが動作している期間、プリアンブル送信から、プリアンブル送信後ＲＡ応答ウィンドウが最初に満了する時点までの期間、またはＬＢＴ検出によりＲＡ競合解決タイマが満了して最後に再起動してから、次のｒａ−ＲｅｓｐｏｎｓｅＷｉｎｄｏｗが満了するまでの期間に適用されることに留意すべきである。
あるいは、ＬＢＴ失敗またはＬＢＴ成功をカウントするように手順を定義してもよい。ＬＢＴ失敗が、設定された最大ＬＢＴ失敗閾値を超えた場合、またはＬＢＴ成功が、設定された最小ＬＢＴ成功閾値未満であり得る場合にのみ、ＲＡ応答ウィンドウが再起動される。
あるいは、ＲＡ応答ウィンドウは、ＢｅａｍＦａｉｌｕｒｅＲｅｃｏｖｅｒｙＣｏｎｆｉｇまたはＲＡＣＨ−ＣｏｎｆｉｇＣｏｍｍｏｎに設定された値とは異なる期間だけ延長され得る。ＲＡ応答ウィンドウが延長される期間は、別の設定値であってもよく、または検出されたＬＢＴ失敗もしくは判定された成功の量に応じた値であってもよい。また、ランダムアクセス応答受信が成功しなかったとＵＥが決して判定しないように、ＬＢＴの失敗によるランダムアクセス応答を大幅に延長すること、または無期限に延長することを回避する必要がある場合もある。その場合、ＲＡ応答ウィンドウの再起動は、指定されたまたは設定された最大値に制限され得る。例えば、ＭＡＣ仕様を以下のように修正してもよい。
１＞ＲＡ−ＲｅｓｐｏｎｓｅＷｉｎｄｏｗ−ＬＢＴ−Ｆａｉｌｕｒｅ−Ｃｏｕｎｔ＞ＲＡ−ＲｅｓｐｏｎｓｅＷｉｎｄｏｗ−ＬＢＴ−ＦａｉｌｕｒｅＴｈｒｅｓｈｏｌｄである場合、および、
１＞ＬＢＴ−ＲＡ−ＲｅｓｐｏｎｓｅＷｉｎｄｏｗＲｅｓｔａｒｔＣｏｕｎｔ＜＝ＬＢＴ−ＲＡ−ＲｅｓｐｏｎｓｅＷｉｎｄｏｗ−Ｒｅｓｔａｒｔ−Ｔｈｒｅｓｈｏｌｄである場合、
２＞ＲＡ−ＲｅｓｐｏｎｓｅＷｉｎｄｏｗ−ＬＢＴ−Ｆａｉｌｕｒｅ−Ｃｏｕｎｔを０に設定して、
２＞ＬＢＴ−ＲＡ−ＲｅｓｐｏｎｓｅＷｉｎｄｏｗＲｅｓｔａｒｔＣｏｕｎｔを１だけインクリメントして、
２＞ｒａ−ＲｅｓｐｏｎｓｅＷｉｎｄｏｗを起動または再起動する。

１＞ＬＢＴ失敗が検出された場合、
２＞ＲＡ−ＲｅｓｐｏｎｓｅＷｉｎｄｏｗ−ＬＢＴ−Ｆａｉｌｕｒｅ−Ｃｏｕｎｔをインクリメントする。

ＲＡ−ＲｅｓｐｏｎｓｅＷｉｎｄｏｗ−ＬＢＴ−ＦａｉｌｕｒｅＴｈｒｅｓｈｏｌｄを超えた場合、以下のアクションを実行してもよい。
１＞ＬＢＴ−ＲＡ−ＲｅｓｐｏｎｓｅＷｉｎｄｏｗＲｅｓｔａｒｔＣｏｕｎｔ＞ＬＢＴ−ＲＡ−ＲｅｓｐｏｎｓｅＷｉｎｄｏｗ−Ｒｅｓｔａｒｔ−Ｔｈｒｅｓｈｏｌｄである場合、
２＞ランダムアクセス応答の受信が成功しなかったと見なす。
以下に別の例を示す。ＬＢＴが失敗した場合、プリアンブル送信カウンタをインクリメントすべきではないと説明してきた。例えば、
１＞ＲＡＣＨ−ＣｏｎｆｉｇＣｏｍｍｏｎに設定されているｒａ−ＲｅｓｐｏｎｓｅＷｉｎｄｏｗが満了した場合、および送信されたに一致するランダムアクセスプリアンブル識別子を含むランダムアクセス応答を受信していない場合、
１＞ＢｅａｍＦａｉｌｕｒｅＲｅｃｏｖｅｒｙＣｏｎｆｉｇに設定されたｒａ−ＲｅｓｐｏｎｓｅＷｉｎｄｏｗが満了した場合、およびＣ−ＲＮＴＩ宛てのＰＤＣＣＨを受信していない場合、
２＞ランダムアクセス応答の受信が成功しなかったと見なし、
２＞ＬＢＴ失敗が検出されなかった場合、
３＞ＰＲＥＡＭＢＬＥ＿ＴＲＡＮＳＭＩＳＳＩＯＮ＿ＣＯＵＮＴＥＲを１だけインクリメントして、
３＞ＰＲＥＡＭＢＬＥ＿ＴＲＡＮＳＭＩＳＳＩＯＮ＿ＣＯＵＮＴＥＲ＝ｐｒｅａｍｂｌｅＴｒａｎｓＭａｘ＋１である場合、
４＞ＳｐＣｅｌｌでランダムアクセスプリアンブルが送信された場合、
５＞ランダムアクセスの問題を上位層に示し、
４＞ＳＩ要求に対してこのランダムアクセス手順がトリガされた場合、
５＞ランダムアクセス手順が不成功に終わったと見なし、
３＞さもなければ、ＳＣｅｌｌでランダムアクセスプリアンブルが送信された場合、
４＞ランダムアクセス手順が不成功に終わったと見なす。
プリアンブル送信カウンタは、ＬＢＴ失敗の検出時にデクリメントされてもよい。例えば、
１＞物理層に、選択されたＰＲＡＣＨ、対応するＲＡ−ＲＮＴＩ（利用可能な場合）、ＰＲＥＡＭＢＬＥ＿ＩＮＤＥＸ、および、ＰＲＥＡＭＢＬＥ＿ＲＥＣＥＩＶＥＤ＿ＴＡＲＧＥＴ＿ＰＯＷＥＲを使用して、ランダムアクセスプリアンブルを送信するように指示して、
１＞ＬＢＴ失敗が検出された場合、
２＞ＰＲＥＡＭＢＬＥ＿ＴＲＡＮＳＭＩＳＳＩＯＮ＿ＣＯＵＮＴＥＲを１だけデクリメントする。
上記の手順において、ＬＢＴ失敗がプリアンブル送信に適用され得ることに留意すべきである。ランダムアクセス応答受信が成功しなかったとＵＥが判定しないように、ＬＢＴ失敗によりプリアンブル送信カウンタを大幅にインクリメントしないこと、またはプリアンブル送信カウンタを無期限にインクリメントしないことを回避する試みがあるべきである。その場合、ＲＡ応答ウィンドウの再起動は、指定されたまたは設定された最大値に制限され得る。例えば、ＭＡＣ仕様を以下のように修正してもよい。
１＞ＲＡＣＨ−ＣｏｎｆｉｇＣｏｍｍｏｎに設定されているｒａ−ＲｅｓｐｏｎｓｅＷｉｎｄｏｗが満了した場合、および送信されたＰＲＥＡＭＢＬＥ＿ＩＮＤＥＸに一致するランダムアクセスプリアンブル識別子を含むランダムアクセス応答を受信していない場合、
１＞ＢｅａｍＦａｉｌｕｒｅＲｅｃｏｖｅｒｙＣｏｎｆｉｇに設定されたｒａ−ＲｅｓｐｏｎｓｅＷｉｎｄｏｗが満了した場合、およびＣ−ＲＮＴＩ宛てのＰＤＣＣＨを受信していない場合、
２＞ランダムアクセス応答の受信が成功しなかったと見なし、
２＞ＰｒｅａｍｂｌｅＴｒａｎｓｍｉｓｓｉｏｎＬＢＴ失敗が検出されなかった場合、または、
２＞ＲＡ−ＰｒｅａｍｂｌｅＴｒａｎｓｍｉｓｓｉｏｎ−ＬＢＴ−Ｆａｉｌｕｒｅ−Ｃｏｕｎｔ＞ＲＡ−ＰｒｅａｍｂｌｅＴｒａｎｓｍｉｓｓｉｏｎ−ＬＢＴ−ＦａｉｌｕｒｅＴｈｒｅｓｈｏｌｄである場合、
３＞ＰＲＥＡＭＢＬＥ＿ＴＲＡＮＳＭＩＳＳＩＯＮ＿ＣＯＵＮＴＥＲを１だけインクリメントして、
３＞ＰＲＥＡＭＢＬＥ＿ＴＲＡＮＳＭＩＳＳＩＯＮ＿ＣＯＵＮＴＥＲ＝ｐｒｅａｍｂｌｅＴｒａｎｓＭａｘ＋１である場合、
４＞ＳｐＣｅｌｌでランダムアクセスプリアンブルが送信された場合、
５＞上位層にランダムアクセスの問題を示し、
４＞ＳＩ要求に対してこのランダムアクセス手順がトリガされた場合、
５＞ランダムアクセス手順が不成功に終わったと見なし、
３＞さもなければ、ＳＣｅｌｌでランダムアクセスプリアンブルが送信された場合、
４＞ランダムアクセス手順が不成功に終わったと見なす。

１＞ＰｒｅａｍｂｌｅＴｒａｎｓｍｉｓｓｉｏｎ−ＬＢＴ−Ｆａｉｌｕｒｅが検出された場合、
２＞ＲＡ−ＰｒｅａｍｂｌｅＴｒａｎｓｍｉｓｓｉｏｎ−ＬＢＴ−Ｆａｉｌｕｒｅ−Ｃｏｕｎｔをインクリメントする。
ＲＡ−ＰｒｅａｍｂｌｅＴｒａｎｓｍｉｓｓｉｏｎ−ＬＢＴ−ＦａｉｌｕｒｅＴｈｒｅｓｈｏｌｄを超えた場合、以下のアクションを実行してもよい。１）上位層にランダムアクセスの問題を示す、または、２）ランダムアクセス手順が不成功に終わったと見なす。
あるいは、ＭＡＣ仕様を以下のように修正してもよい。
１＞ＰｒｅａｍｂｌｅＴｒａｎｓｍｉｓｓｉｏｎ−ＬＢＴ−Ｆａｉｌｕｒｅが検出された場合、
２＞ＲＡ−ＰｒｅａｍｂｌｅＴｒａｎｓｍｉｓｓｉｏｎ−ＬＢＴ−Ｆａｉｌｕｒｅ−Ｃｏｕｎｔをインクリメントして、
２＞ＲＡ−ＰｒｅａｍｂｌｅＴｒａｎｓｍｉｓｓｉｏｎ−ＬＢＴ−Ｆａｉｌｕｒｅ−Ｃｏｕｎｔ＞ＲＡ−ＰｒｅａｍｂｌｅＴｒａｎｓｍｉｓｓｉｏｎ−ＬＢＴ−ＦａｉｌｕｒｅＴｈｒｅｓｈｏｌｄである場合、
３＞ＳｐＣｅｌｌでランダムアクセスプリアンブルが送信された場合、
４＞上位層にランダムアクセスの問題を示し、
３＞ＳＩ要求に対してこのランダムアクセス手順がトリガされた場合、
４＞ランダムアクセス手順が不成功に終わったと見なし、
３＞さもなければ、ＳＣｅｌｌでランダムアクセスプリアンブルが送信された場合、
４＞ランダムアクセス手順が不成功に終わったと見なす。
（競合解決）
ランダムアクセス競合解決手順の以下の修正は、ＮＲ−ＵにおけるＬＢＴの影響を考慮に入れてもよい。
ＲＡ競合解決が満了しても、プリアンブル送信以降にＬＢＴ失敗が検出された場合、ＲＡ競合解決を延長し得る。これは、ＮＢがＭＳＧ３送信を受信していても、ＬＢＴ失敗によりＰＤＣＣＨ送信が遅延しているために必要になり得る。ＮＢがＬＢＴ失敗により送信機会を逃したことをＵＥが検出した場合、ＲＡ競合解決タイマを延長し得る。
例えば、ＭＡＣ仕様を以下のように修正してもよい。
１＞ｒａ−ＣｏｎｔｅｎｔｉｏｎＲｅｓｏｌｕｔｉｏｎＴｉｍｅｒが満了した場合、
２＞ＬＢＴ失敗が検出された場合、
３＞ｒａ−ＣｏｎｔｅｎｔｉｏｎＲｅｓｏｌｕｔｉｏｎＴｉｍｅｒを起動し、ＨＡＲＱ再送信ごとにｒａ−ＣｏｎｔｅｎｔｉｏｎＲｅｓｏｌｕｔｉｏｎＴｉｍｅｒを再起動して、
３＞測定ギャップの発生の可能性に関わらず、ｒａ−ＣｏｎｔｅｎｔｉｏｎＲｅｓｏｌｕｔｉｏｎＴｉｍｅｒが実行されている間、ＰＤＣＣＨを監視し、
２＞さもなければ、
３＞ＴＥＭＰＯＲＡＲＹ＿Ｃ−ＲＮＴＩを破棄して、
３＞競合解決が成功しなかったと見なす。
上記の手順において、ＬＢＴ失敗が検出されたとは、ＲＡ競合解決タイマが動作している期間、ＭＳＧ３送信から、ＭＳＧ３送信後ＲＡ競合解決タイマが最初に満了する時点までの期間、またはＬＢＴ検出によりＲＡ競合解決タイマが満了して最後に起動してから、次のＲＡ競合解決タイマが満了するまでの期間に適用されることに留意すべきである。
あるいは、ＬＢＴ失敗またはＬＢＴ成功をカウントするように手順を定義してもよい。ＬＢＴ失敗が、設定された最大ＬＢＴ失敗閾値を超えた場合、またはＬＢＴ成功が、設定された最小ＬＢＴ成功閾値未満であり得る場合にのみ、ＲＡ競合解決が再起動される。
あるいは、ＲＡ競合解決タイマは、設定されたＲＡ競合解決タイマとは異なる期間だけ延長されてもよい。ＲＡ競合解決タイマが延長される期間は、別の設定値であってもよく、または検出されたＬＢＴの失敗もしくは判定された成功の量に応じた値であってもよい。また、競合解決が成功しなかったとＵＥが決して判定しないように、ＲＡ競合解決タイマを大幅に延長すること、またはＬＢＴ失敗によりＲＡ競合解決タイマを無期限に延長することを回避する必要がある場合がある。その場合、ＲＡ競合解決タイマの再起動は、指定されたまたは設定された最大値に制限され得る。例えば、ＭＡＣ仕様を以下のように修正してもよい。
１＞ＲＡ−ＣｏｎｔｅｎｔｉｏｎＲｅｓｏｌｕｔｉｏｎ−ＬＢＴ−Ｆａｉｌｕｒｅ−Ｃｏｕｎｔ＞ＲＡ−ＣｏｎｔｅｎｔｉｏｎＲｅｓｏｌｕｔｉｏｎ−ＬＢＴ−ＦａｉｌｕｒｅＴｈｒｅｓｈｏｌｄである場合、および、
１＞ＬＢＴ−ＲＡ−ＣｏｎｔｅｎｔｉｏｎＲｅｓｏｌｕｔｉｏｎＴｉｍｅｒＲｅｓｔａｒｔＣｏｕｎｔ＜＝ＬＢＴ−ＲＡＣｏｎｔｅｎｔｉｏｎＲｅｓｏｌｕｔｉｏｎＲｅｓｔａｒｔ−Ｔｈｒｅｓｈｏｌｄである場合、
２＞ＲＡ−ＣｏｎｔｅｎｔｉｏｎＲｅｓｏｌｕｔｉｏｎ−ＬＢＴ−Ｆａｉｌｕｒｅ−Ｃｏｕｎｔを０に設定して、
２＞ＬＢＴ−ＲＡ−ＣｏｎｔｅｎｔｉｏｎＲｅｓｏｌｕｔｉｏｎＴｉｍｅｒＲｅｓｔａｒｔＣｏｕｎｔを１だけインクリメントして、
２＞ｒａ−ＣｏｎｔｅｎｔｉｏｎＲｅｓｏｌｕｔｉｏｎＴｉｍｅｒを起動し、ＨＡＲＱ再送信ごとにｒａ−ＣｏｎｔｅｎｔｉｏｎＲｅｓｏｌｕｔｉｏｎＴｉｍｅｒを再起動して、
２＞測定ギャップの発生の可能性に関わらず、ｒａ−ＣｏｎｔｅｎｔｉｏｎＲｅｓｏｌｕｔｉｏｎＴｉｍｅｒが実行されている間、ＰＤＣＣＨを監視する。

１＞ＬＢＴ失敗が検出された場合、
２＞ＲＡ−ＣｏｎｔｅｎｔｉｏｎＲｅｓｏｌｕｔｉｏｎ−ＬＢＴ−Ｆａｉｌｕｒｅ−Ｃｏｕｎｔをインクリメントする。

ＲＡ−ＣｏｎｔｅｎｔｉｏｎＲｅｓｏｌｕｔｉｏｎ−ＬＢＴＲｅｓｔａｒｔＴｈｒｅｓｈｏｌｄを超えた場合、以下のアクションを実行してもよい。
１＞ＬＢＴ−ＲＡ−ＣｏｎｔｅｎｔｉｏｎＲｅｓｏｌｕｔｉｏｎＴｉｍｅｒＲｅｓｔａｒｔＣｏｕｎｔ＞ＬＢＴ−ＲＡ−ＣｏｎｔｅｎｔｉｏｎＲｅｓｏｌｕｔｉｏｎＲｅｓｔａｒｔ−Ｔｈｒｅｓｈｏｌｄである場合、
２＞ランダムアクセス応答の受信が成功しなかったと見なす。
（ランダムアクセスプリアンブル送信）
ランダムアクセスプリアンブル送信手順の以下の修正は、ＮＲ−ＵにおけるＬＢＴの影響を考慮に入れる。
ＬＢＴが失敗した場合、プリアンブルパワーランピングカウンタをインクリメントすべきではないと説明してきた。例えば、
ＭＡＣエンティティは、各ランダムアクセスプリアンブルに対して、以下であるものとする。
１＞ＰＲＥＡＭＢＬＥ＿ＴＲＡＮＳＭＩＳＳＩＯＮ＿ＣＯＵＮＴＥＲが１よりも大きい場合、および、
１＞パワーランピングカウンタの一時停止の通知を下位層から受信していない場合、および、
１＞選択されたＳＳＢが変更されていない場合（すなわち、前回のランダムアクセスプリアンブル送信と同じ）、および、
１＞ＬＢＴ失敗が検出されなかった場合、
２＞ＰＲＥＡＭＢＬＥ＿ＰＯＷＥＲ＿ＲＡＭＰＩＮＧ＿ＣＯＵＮＴＥＲを１だけインクリメントする。
プリアンブルパワーランピングカウンタは、ＬＢＴ失敗の検出時にデクリメントされてもよい。例えば、
１＞物理層に、選択されたＰＲＡＣＨ、対応するＲＡ−ＲＮＴＩ（利用可能な場合）、ＰＲＥＡＭＢＬＥ＿ＩＮＤＥＸ、およびＰＲＥＡＭＢＬＥ＿ＲＥＣＥＩＶＥＤ＿ＴＡＲＧＥＴ＿ＰＯＷＥＲを使用して、ランダムアクセスプリアンブルを送信するように指示する。
２＞ＬＢＴ失敗が検出された場合、
２＞ＰＲＥＡＭＢＬＥ＿ＰＯＷＥＲ＿ＲＡＭＰＩＮＧ＿ＣＯＵＮＴＥＲを１だけデクリメントする。
上記の手順において、ＬＢＴ失敗がプリアンブル送信に適用され得ることに留意すべきである。
（パワーヘッドルーム報告）
ＰＨＲ手順の以下の修正は、ＮＲ−ＵにおけるＬＢＴの影響を考慮に入れる。
ＰＨＲ ＭＡＣ ＣＥの送信がＬＢＴ失敗によってブロックされ、時間をおいて再送信される場合、ＰＨＲが計算されたときＮＢに通知するため、またはＰＨＲが計算されたときの送信条件をＮＢに通知するために、追加のシグナリングが導入される。
ＮＢがＰＨＲを適切に処理するためには、ＰＨＲがどのような条件下で計算されたかをＮＢが認識するために必要な場合がある。
ＰＨＲは、定格ＵＥ最大送信電力と、アクティブ化されたサービングセルごとのＵＬ−ＳＣＨ送信またはＳＲＳ送信の推定電力との差について、および、定格ＵＥ最大電力と、ＳｐＣｅｌｌおよびＰＵＣＣＨ ＳＣｅｌｌ上のＵＬ−ＳＣＨおよびＰＵＣＣＨ送信の推定電力との差についての情報も用いて計算する。
既存のＰＨＲシグナリングは、ＵＬ−ＳＣＨ送信が実送信または仮想送信に基づいていたか否か、およびＰＨＲが計算されたときにＰＵＣＣＨが送信されたか否かを特定する。ＵＬ−ＳＣＨが実送信されたものである場合、ＰＨＲ計算時に何が送信されたかをＮＢが認識するために必要な場合がある。
アンライセンス周波数帯で動作しておらず、ＬＢＴが使用されていない場合、ＮＢはＰＨＲの計算がいつ行われたかを判定できる。ＮＢはスケジュールされたものと受信したものを認識しているため、この時点でＵＬ−ＳＣＨで何が送信されたかを認識することでＰＨＲを解釈することができる。しかし、ＬＢＴが失敗し、ＬＢＴが成功するまで送信が遅延する場合、ＮＢはＰＨＲの計算時にＵＬ−ＳＣＣＨで何が送信されたかを判定することができない。
以下に、この問題に対処するための複数の方法を示す。第１の方法では、ＰＨＲの計算がいつ行われたのかをＮＢが判定できるような追加の表示をＰＨＲに提供する。これは、最初のＬＢＴ失敗の時間に対するＬＢＴによる遅延であってもよく、または絶対時間基準であってもよい。第２の方法では、ＵＬ−ＳＣＣＨで何が送信されたかをＮＢに通知する追加情報をＰＨＲと共に提供する。これは、ＵＬ−ＳＣＣＨ上で何が送信されたかを近似したインデックス付きの値であってもよく、またはＰＨＲ計算時の送信の物理的な詳細であってもよい。第３の方法では、ＰＨＲのためにＬＢＴによって被った実効遅延をＮＢが判定し得るように、ＬＢＴの失敗または成功がＮＢに独立して示されてもよい。第４の方法では、ＰＨＲが計算されたときに使用されたグラント（例えば、アップリンクグラント）をＮＢに通知する追加情報をＰＨＲと共に提供する。
ＰＨＲがどのように計算されたかをＮＢが認識することができる追加情報をＮＢが受信することが好ましいが、絶対に必要というわけではない。あるいは、実際のＰＨＲが不正確な情報を提供している場合、ＮＢは少なくとも認識し得る。これは、ＵＥがＮＢにＬＢＴ失敗および成功示すことで、ＰＨＲを遅延させたＬＢＴ失敗があったことをＮＢが判定できるようにすることにより、実現され得る。
以下に別の例を示す。ＰＨＲのトリガ条件は、ＬＢＴ失敗を考慮すべきである。利用可能なＵＬリソース、ＰＨＲ周期タイマ満了、ＰＨＲ再設定、ＳＣｅｌｌアクティブ化、；およびＰＳＣｅｌｌ追加のトリガ基準は、ＬＢＴが成功した場合にのみ考慮されるべきである。ＬＢＴ基準の追加は、既存の各トリガに対して相互に排他的であり、したがって、既存の基準のサブセットにのみ影響を与え得る。
例えば（全てのトリガを考慮する場合）、ＭＡＣ仕様は以下のように修正されてもよい。
以下のイベントのいずれかが発生した場合、パワーヘッドルームレポート（ＰＨＲ）がトリガされるものとする。
・ｐｈｒ−ＰｒｏｈｉｂｉｔＴｉｍｅｒが満了するか、または満了して、ＭＡＣエンティティに新しい送信のためのＵＬリソースがあり、この送信がＬＢＴ失敗によってブロックされていないときに、このＭＡＣエンティティにおけるＰＨＲの最後の送信以降、パスロスの参照先として使用されるＭＡＣエンティティの少なくとも１つのアクティブ化されたサービングセルに対して、パスロスがｐｈｒ−Ｔｘ−ＰｏｗｅｒＦａｃｔｏｒＣｈａｎｇｅ ｄＢを超えて変化した、
注釈１ 上記で評価された１つのセルのパスロス変動は、現在のパスロス参照で現時点で測定されたパスロスと、その時点で使用されていたパスロス参照でＰＨＲの最後の送信時に測定されたパスロスとの間のものであり、その間にパスロス参照が変更されたか否かは関係がない。
・ｐｈｒ−ＰｅｒｉｏｄｉｃＴｉｍｅｒが満了し、その後ＬＢＴが成功する、
・上位層によるパワーヘッドルーム報告機能の設定または再設定時に、ＬＢＴがその後成功し、その機能性を無効化するために使用されていない、
・設定されたアップリンクを有するＭＡＣエンティティのＳＣｅｌｌをアクティブ化し、ＬＢＴがその後成功する、
・ＰＳＣｅｌｌの追加（すなわち、ＰＳＣｅｌｌが新たに追加または変更された場合）、およびＬＢＴがその後成功する、
・ｐｈｒ−ＰｒｏｈｉｂｉｔＴｉｍｅｒが満了するか、または満了し、ＭＡＣエンティティが新しい送信のためのＵＬリソースを有し、この送信がＬＢＴ失敗によってブロックされておらず、設定されたアップリンクを有するいずれかのＭＡＣエンティティのアクティブ化されたサービングセルのいずれかについて以下のことが当てはまる、
・このセルに送信のためのＵＬリソースが割り当てられているか、またはＰＵＣＣＨ送信があり、このセルに対する電力管理（ＴＳ３８．１０１［１０］に規定されているようにＰ−ＭＰＲｃによって許可されている）による必要な電力バックオフが、ＰＨＲの最後の送信以降、ＭＡＣエンティティが、このセルに送信のためのＵＬリソースが割り当てられていたか、またはＰＵＣＣＨ送信があったときに、ｐｈｒ−Ｔｘ−ＰｏｗｅｒＦａｃｔｏｒＣｈａｎｇｅ ｄＢを超えて変化した。
これらの変更は、ＬＢＴが成功し、ＵＥがチャネルにアクセスしたときにＰＨＲが計算または送信されるようにするために必要な場合がある。
以下に別の例を示す。ＰＨＲの計算および送信は、ＬＢＴが成功した場合にのみ考慮されるべきである。
定格ＵＥ最大送信電力と、アクティブ化されたサービングセルごとのＵＬ−ＳＣＨ送信またはＳＲＳ送信の推定電力との差について、および、定格ＵＥ最大電力と、ＳｐＣｅｌｌおよびＰＵＣＣＨ ＳＣｅｌｌ上のＵＬ−ＳＣＨおよびＰＵＣＣＨ送信の推定電力との差についての情報を用いた計算も、ＬＢＴ成功時にのみ考慮されるべきである。
ＵＬリソースがＰＨＲ ＭＡＣ ＣＥに適応できるか否かをチェックする場合、ＬＢＴ成功を判定することも必要であり得る。利用可能なＵＬリソースを有することは、ＰＨＲ ＭＡＣ ＣＥの送信がＬＢＴによりブロックされることには関係がない。
例えば、ＭＡＣ仕様を以下のように修正してもよい。
ＭＡＣエンティティが新しい送信のために割り当てられたＵＬリソースを有し、ＬＢＴ成功と判定された場合、ＭＡＣエンティティは、
１＞最後のＭＡＣリセット以降、新しい送信のために割り当てられた最初のＵＬリソースである場合、
２＞ｐｈｒ−ＰｅｒｉｏｄｉｃＴｉｍｅｒを起動して、
１＞パワーヘッドルーム報告手順により、少なくとも１つのＰＨＲがトリガされ、キャンセルされていないと判定された場合、および、
１＞割り当てられたＵＬリソースが、論理チャネルの優先順位付けの結果、ＭＡＣエンティティが送信するように構成されているＰＨＲのためのＭＡＣ ＣＥと、そのサブヘッダに適応できる場合、および、
１＞ＬＢＴ成功と判定され、
２＞ｍｕｌｔｉｐｌｅＰＨＲが設定されている場合、
３＞任意のＭＡＣエンティティに関連付けられた、設定されたアップリンクを有する各アクティブ化されたサービングセルに対して、
４＞対応するアップリンクキャリアに対するタイプ１またはタイプ３のパワーヘッドルームの値を取得して、
４＞このＭＡＣエンティティが、このサービングセルでの送信のために割り当てられたＵＬリソースを有し、ＬＢＴ成功と判定された場合、または、
４＞他方のＭＡＣエンティティ（設定されている場合）が、送信のために割り当てられたＵＬリソースを有し、このサービングセルでＬＢＴ成功と判定され、上位層によりｐｈｒ−ＭｏｄｅＯｔｈｅｒＣＧが実数に設定されている場合、
５＞物理層から対応するＰＣＭＡＸ，ｆ，ｃフィールドの値を取得し、
３＞ｐｈｒ−Ｔｙｐｅ２ＳｐＣｅｌｌが設定されている場合、
４＞このＭＡＣエンティティのＳｐＣｅｌｌに対するタイプ２パワーヘッドルームの値を取得して、
４＞物理層から対応するＰＣＭＡＸ，ｆ，ｃフィールドの値を取得し、
３＞ｐｈｒ−Ｔｙｐｅ２ＯｔｈｅｒＣｅｌｌが設定されている場合、
４＞その他のＣＧが設定されている場合、
５＞他方のＭＡＣエンティティのＳｐＣｅｌｌに対するタイプ２パワーヘッドルームの値を取得して、
５＞ｐｈｒ−ＭｏｄｅＯｔｈｅｒＣＧが上位層によって実数に設定されている場合、
６＞物理層から他方のＭＡＣエンティティのＳｐＣｅｌｌに対する対応するＰＣＭＡＸ，ｆ，ｃフィールドの値を取得し、
４＞さもなければ、ＰＵＣＣＨ ＳＣｅｌｌが設定され、アクティブ化されている場合、
５＞ＰＵＣＣＨ ＳＣｅｌｌに対するタイプ２パワーヘッドルームの値を取得して
５＞物理層から対応するＰＣＭＡＸ，ｆ，ｃフィールドの値を取得し、
３＞ＬＢＴ成功と判定された場合、物理層から報告された値に基づいて、［２］の６．１．３．９節で定義されているように、設定されたＳｅｒｖＣｅｌｌＩｎｄｅｘおよびＭＡＣエンティティのＰＵＣＣＨ（単数または複数）に従ってＰＨＲ ＭＡＣ ＣＥを生成および送信するように、多重化およびアセンブリ手順に指示し、
２＞さもなければ（すなわち、シングルエントリＰＨＲフォーマットが使用されて）、
３＞ＰＣｅｌｌの対応するアップリンクキャリアの物理層からタイプ１パワーヘッドルームの値を取得して、
３＞物理層から対応するＰＣＭＡＸ，ｆ，ｃフィールドの値を取得して。
３＞ＬＢＴ成功と判定された場合、物理層から報告された値に基づいて、［２］の６．１．３．８節で定義されているように、ＰＨＲ ＭＡＣ ＣＥ を生成および送信するように、多重化およびアセンブリ手順を指示し、
２＞ｐｈｒ−ＰｅｒｉｏｄｉｃＴｉｍｅｒを起動または再起動して、
２＞ｐｈｒ−ＰｒｏｈｉｂｉｔＴｉｍｅｒを起動または再起動して、
２＞全てのトリガされたＰＨＲ（単数または複数）をキャンセルする。
上記の例示的なＭＡＣ固有の変更は、ＬＢＴ成功の観点から記載されているが、例はＬＢＴ失敗なしの観点からも同様に表されてもよい。
この例では、変更は相互排他的であることに留意すべきである。開示された変更のサブセットのみが必要な場合がある。
以下に別の例を示す。さらに、ＭＡＣ ＰＨＲ ＣＥを含む送信のＬＢＴ失敗の検出時、ＰＨＲ禁止タイマを設定するべきではないか、または設定されていた場合はクリアするべきであることが開示されている。
物理層がＭＡＣ ＰＨＲ ＣＥを含むＭＡＣ ＰＤＵの送信を指示された場合、ＰＨＲ禁止タイマは、ＭＡＣ ＰＤＵ送信のＬＢＴ成功の判定時にのみ起動または再起動されるべきである。例えば、ＭＡＣ仕様を以下のように修正してもよい。
１＞ＬＢＴ成功と判定された場合、
２＞ｐｈｒ−ＰｅｒｉｏｄｉｃＴｉｍｅｒを起動または再起動して、
２＞ｐｈｒ−ＰｒｏｈｉｂｉｔＴｉｍｅｒを起動または再起動して、
２＞全てのトリガされたＰＨＲ（単数または複数）をキャンセルする。
上記の例示的なＭＡＣ固有の変更は、ＬＢＴ成功の観点から記載されているが、例はＬＢＴ失敗なしの観点からも表されてもよい。
あるいは、ＰＨＲ禁止タイマまたはＰＨＲ周期タイマは、既存の手順で行われるように起動されてもよいが、ＬＢＴ失敗と判定された場合には、ＰＨＲ禁止タイマがクリアされてもよく、またはＰＨＲ周期タイマがＬＢＴ失敗による最後のリセット前の残りの値に、もしくは、例えば設定された時間値などの異なる時間値にリセットしてもよい。
この修正は、後続のＰＨＲ送信が遅延し得ないようにＰＨＲ禁止タイマが設定されないようにするか、または、ＰＨＲの送信がＬＢＴ失敗によってブロックされたときに周期的なＰＨＲが遅延しないように、ＰＨＲ周期タイマがリセットされないようにすることを確実にするために、必要な場合がある。
（ＳＣｅｌｌのアクティブ化／非アクティブ化）
ＳＣｅｌｌのアクティブ化／非アクティブ化手順の以下の修正は、ＮＲ−ＵにおけるＬＢＴの影響を考慮に入れる。
ＳＣｅｌｌ非アクティブ化タイマの実行中にＬＢＴ失敗が検出された場合、ＳＣｅｌｌ非アクティブ化タイマが延長される。これは、意図しないＳＣｅｌｌ非アクティブ化を回避するために必要な場合がある。
ＬＢＴ失敗により、ＮＢがＤＬ送信の機会を逃した（ダウンリンクの割り当て（単数または複数）が損失され得る）か、またはＵＬ送信がブロックされ得る（ＭＡＣ ＰＤＵが送信されない）ことをＵＥが検出すると、ＳＣｅｌｌ非アクティブ化タイマが延長される。
これを達成する方法の、複数のオプションが存在し得る。
・ＬＢＴ失敗の検出時に、ＳＣｅｌｌ非アクティブ化タイマが延長または再起動される
・ＳＣｅｌｌ非アクティブ化タイマの満了時にＬＢＴ失敗が検出された場合、ＳＣｅｌｌ非アクティブ化タイマが延長または再起動される。
ＬＢＴ失敗とは、ＬＢＴ成功の欠如を意味する場合もあることに留意すべきである。例えば、ＵＥ ＰＨＹ層がＵＥ ＭＡＣにＬＢＴ失敗を示すことがあり、またはＮＢがＵＥ ＭＡＣにＬＢＴ成功を示すことがある。
例えば、ＭＡＣ仕様を以下のように修正してもよい。
１＞さもなければ、ＳＣｅｌｌを非アクティブ化する、ＳＣｅｌｌアクティブ化／非アクティブ化ＭＡＣ ＣＥを受信した場合、または、
１＞アクティブ化されたＳＣｅｌｌに関連付けられたｓＣｅｌｌＤｅａｃｔｉｖａｔｉｏｎＴｉｍｅｒが満了し、ＬＢＴ失敗が検出されなかった場合、
２＞ＴＳ ３８．２１３で定義されているタイミングに従って、ＳＣｅｌｌを非アクティブ化して、
２＞ＳＣｅｌｌに関連付けられたｓＣｅｌｌＤｅａｃｔｉｖａｔｉｏｎＴｉｍｅｒを停止して、
２＞ＳＣｅｌｌに関連付けられたｂｗｐ−ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒを停止して、
２＞ＳＣｅｌｌに関連付けられた、任意の設定されたダウンリンク割り当て、および任意の設定されたアップリンクグラントのタイプ２をそれぞれクリアして、
２＞ＳＣｅｌｌに関連付けられた、任意の設定されたアップリンクグラントのタイプ１を一時停止して、
２＞ＳＣｅｌｌに関連付けられた全てのＨＡＲＱバッファをフラッシュする。

１＞アクティブ化されたＳＣｅｌｌに関連付けられたｓＣｅｌｌＤｅａｃｔｉｖａｔｉｏｎＴｉｍｅｒが満了し、ＬＢＴ失敗が検出された場合、
２＞ＳＣｅｌｌに関連付けられたｓＣｅｌｌＤｅａｃｔｉｖａｔｉｏｎＴｉｍｅｒを再起動する。
上記の手順（単数または複数）において、ＬＢＴ失敗が検出されたとは、ＳＣｅｌｌ非アクティブ化タイマが動作している期間、ＳＣｅｌｌ非アクティブ化から、もしくは設定されたアップリンクグラントで最後のＭＡＣ ＰＤＵが送信されたときから、もしくは設定されたダウンリンク割り当てでＵＥが最後に受信したときから、ＳＣｅｌｌ非アクティブ化タイマが設定された後に最初に満了する時点までの期間、またはＬＢＴ検出によりＳＣｅｌｌ非アクティブ化タイマが満了して最後に起動してから、次のＳＣｅｌｌ非アクティブ化タイマが満了するまでの期間に適用されることに留意すべきである。
あるいは、ＳＣｅｌｌのＬＢＴ失敗検出時に、
１＞ＬＢＴ失敗が検出された場合、
２＞ＳＣｅｌｌに関連付けられたｓＣｅｌｌＤｅａｃｔｉｖａｔｉｏｎＴｉｍｅｒを再起動する。
あるいは、ＬＢＴ失敗もしくはＬＢＴ成功、または連続ＬＢＴ失敗もしくは連続ＬＢＴ成功をカウントするように手順を定義してもよい。ＬＢＴ失敗もしくは連続ＬＢＴ失敗が、設定された最大ＬＢＴ失敗閾値を超えた場合、またはＬＢＴ成功もしくは連続ＬＢＴ成功が、設定された最小ＬＢＴ成功閾値未満であり得る場合にのみ、ＳＣｅｌｌ非アクティブ化タイマが再起動される。例えば、ＭＡＣ仕様を以下のように修正してもよい。
１＞ＳｃｅｌｌＤｅａｃｔＬＢＴ−Ｆａｉｌｕｒｅ−Ｃｏｕｎｔ＞ＳｃｅｌｌＤｅａｃｔＬＢＴ−Ｆａｉｌｕｒｅ−Ｔｈｒｅｓｈｏｌｄである場合、
２＞ＳＣｅｌｌに関連付けられたｓＣｅｌｌＤｅａｃｔｉｖａｔｉｏｎＴｉｍｅｒを再起動して、
２＞ＳｃｅｌｌＤｅａｃｔＬＢＴ−Ｆａｉｌｕｒｅ−Ｃｏｕｎｔを０に設定する。

１＞ＬＢＴの失敗が発生した場合、
２＞ＳｃｅｌｌＤｅａｃｔＬＢＴ−Ｆａｉｌｕｒｅ−Ｃｏｕｎｔをインクリメントする。
あるいは、ＳＣｅｌｌ非アクティブ化タイマは、設定されたＳＣｅｌｌ非アクティブ化タイマとは異なる期間だけ延長され得る。ＳＣｅｌｌ非アクティブ化タイマが延長される期間は、別の設定値であってもよく、または検出されたＬＢＴの失敗もしくは判定された成功の量に応じた値であってもよい。また、ＵＥが決して非アクティブ化されないように、ＳＣｅｌｌ非アクティブ化タイマを大幅に延長すること、またはＬＢＴ失敗によりＳＣｅｌｌ非アクティブタイマを無期限に延長することを回避する必要がある場合もある。その場合、ＳＣｅｌｌ非アクティブ化タイマの再起動は、指定されたまたは設定された最大値に制限され得る。例えば、ＭＡＣ仕様を以下のように修正してもよい。
１＞ＳｃｅｌｌＤｅａｃｔ−ＬＢＴ−Ｆａｉｌｕｒｅ−Ｃｏｕｎｔ＞ＳｃｅｌｌＤｅａｃｔ−ＬＢＴ−ＦａｉｌｕｒｅＴｈｒｅｓｈｏｌｄである場合、および、
１＞ＬＢＴ−ＳｃｅｌｌＤｅａｃｔＴｉｍｅｒＲｅｓｔａｒｔＣｏｕｎｔ＜＝ＬＢＴ−ＳｃｅｌｌＤｅａｃｔ−Ｒｅｓｔａｒｔ−Ｔｈｒｅｓｈｏｌｄである場合、
２＞ＳｃｅｌｌＤｅａｃｔ−ＬＢＴ−Ｆａｉｌｕｒｅ−Ｃｏｕｎｔを０に設定して、
２＞ＬＢＴ−ＳｃｅｌｌＤｅａｃｔＴｉｍｅｒＲｅｓｔａｒｔＣｏｕｎｔを１だけインクリメントして、
２＞ＳＣｅｌｌに関連付けられたｓＣｅｌｌＤｅａｃｔｉｖａｔｉｏｎＴｉｍｅｒを再起動する。

１＞ＬＢＴ失敗が検出された場合、
２＞ＳｃｅｌｌＤｅａｃｔ−ＬＢＴ−Ｆａｉｌｕｒｅ−Ｃｏｕｎｔをインクリメントする。
ＳｃｅｌｌＤｅａｃｔ−ＬＢＴ−ＦａｉｌｕｒｅＴｈｒｅｓｈｏｌｄを超えた場合、以下のアクションを実行してもよい。
１＞ＬＢＴ−ＳｃｅｌｌＤｅａｃｔＴｉｍｅｒＲｅｓｔａｒｔＣｏｕｎｔ＜＝ＬＢＴ−ＳｃｅｌｌＤｅａｃｔ−Ｒｅｓｔａｒｔ−Ｔｈｒｅｓｈｏｌｄである場合、
２＞ＴＳ３８．２１３［６］で定義されているタイミングに従って、ＳＣｅｌｌを非アクティブ化して、
２＞ＳＣｅｌｌに関連付けられたｓＣｅｌｌＤｅａｃｔｉｖａｔｉｏｎＴｉｍｅｒを停止して、
２＞ＳＣｅｌｌに関連付けられたｂｗｐ−ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒを停止して、
２＞ＳＣｅｌｌに関連付けられた、任意の設定されたダウンリンク割り当て、および任意の設定されたアップリンクグラントのタイプ２をそれぞれクリアして、
２＞ＳＣｅｌｌに関連付けられた、任意の設定されたアップリンクグラントのタイプ１を一時停止して、
２＞ＳＣｅｌｌに関連付けられた全てのＨＡＲＱバッファをフラッシュする。
（間欠受信（ＤＲＸ））
ＤＲＸ手順の以下の修正は、ＮＲ−ＵにおけるＬＢＴの影響を考慮に入れる。
ショートサイクルタイマが満了するときに、ショートＤＲＸサイクルからロングＤＲＸサイクルに移行することがある。この移行はＬＢＴ成功が検出された場合、またはＬＢＴ失敗が検出されなかった場合にのみ実行されるべきである。例えば、
１＞ｄｒｘ−ＳｈｏｒｔＣｙｃｌｅＴｉｍｅｒが満了し、ＬＢＴ成功が検出された場合、
１＞ロングＤＲＸサイクルを使用し、
１＞さもなければ、
２＞ｄｒｘ−ＳｈｏｒｔＣｙｃｌｅＴｉｍｅｒを起動または再起動する。
本明細書では、最大ＬＢＴ失敗または最小ＬＢＴ成功の設定閾値が開示されている。そして、ＬＢＴ失敗またはＬＢＴ成功のカウントが閾値を超えた場合にのみ、ＵＥはＤＲＸショートサイクルを使用し続け得る。例えば、
１＞ｄｒｘ−ＳｈｏｒｔＣｙｃｌｅＴｉｍｅｒが満了し、ＬＢＴ成功カウンタが最小ＬＢＴ成功閾値を超えた場合、
２＞ロングＤＲＸサイクルを使用し、
２＞さもなければ、
２＞ｄｒｘ−ＳｈｏｒｔＣｙｃｌｅＴｉｍｅｒを起動または再起動する。
あるいは、ＬＢＴ失敗が検出された場合またはＬＢＴ成功が検出されなかった場合は、ＤＲＸアクティブタイムを延長する。これは、ＤＲＸ非アクティブタイマを起動または再起動することによって実現され得る。また、ＤＲＸ非アクティブタイマが満了時に、ＤＲＸショートサイクルタイマが起動または再起動されるため、これにより、ＤＲＸショートサイクルを継続して使用し得る。さらに、これにより、ＬＢＴ失敗により損失したスケジューリング機会のために必要となる場合がある、さらなるＰＤＣＣＨ ＵＬおよびＤＬのスケジューリング機会が可能となり得る。例えば、ＭＡＣ仕様を以下のように修正してもよい。
３＞ＰＤＣＣＨが新しい送信（ＤＬまたはＵＬ）を示す場合、
４＞ＰＤＣＣＨ受信終了後の最初のシンボルで、ｄｒｘ−ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒを起動または再起動して、
３＞ＬＢＴ失敗が検出された場合、
４＞ｄｒｘ−ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒを起動または再起動する。
好ましくは、ＤＲＸ非アクティブタイマの起動または再起動は、一定期間内にＬＢＴ失敗の検出またはＬＢＴ成功の非検出が複数回発生したことに依存する。期間は、オンデュレーションの期間または非アクティブタイマの期間、オンデュレーションおよび非アクティブタイマが実行されている時間の組み合わせであり得る。例えば、
１＞ＬＢＴ成功が検出されなかった場合に、ｄｒｘ−ｏｎＤｕｒａｔｉｏｎＴｉｍｅｒが満了するとき、
２＞ｄｒｘ−ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒを起動または再起動して、
１＞ＬＢＴ成功が検出されなかった場合に、ｄｒｘ−ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒが満了するとき、
２＞ｄｒｘ−ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒを起動または再起動する。
ＬＢＴ失敗は、単一のインスタンスではないことがある。複数のＬＢＴ失敗または成功の検出であってもよい。ＤＲＸ手順は、ＰＤＤＣＨのＵＥ受信に影響を及ぼす一連のＬＢＴ失敗の後にのみ開始されてもよい。
ＬＢＴ失敗もしくはＬＢＴ成功をカウントする、または連続ＬＢＴ失もしくは連続ＬＢＴ成功をカウントするように手順を定義してもよい。ＬＢＴ失敗もしくは連続ＬＢＴ失敗が、設定された最大ＬＢＴ失敗閾値を超えた場合、またはＬＢＴ成功もしくは連続ＬＢＴ成功が、設定された最小ＬＢＴ成功閾値未満であり得る場合にのみ、ＤＲＸ非アクティブタイマが再起動される。例えば、
１＞ＬＢＴ成功カウントがＬＢＴ最小成功閾値未満の場合に、オンデュレーションタイマが満了するとき、
２＞ｄｒｘ−ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒを起動または再起動する。
また、ＵＥがＤＲＸに決して入ることがないように、ＤＲＸ非アクティブタイマを大幅に延長すること、またはＬＢＴ失敗によりＤＲＸ非アクティブタイマを無期限に延長することを回避する必要がある場合もある。その場合、ＤＲＸ非アクティブタイマの再起動は、指定されたまたは設定された最大値に制限され得る。例えば、ＭＡＣ仕様を以下のように修正してもよい。
１＞ＤＲＸ−Ｉｎａｃｔｉｖｉｔｙ−ＬＢＴ−Ｆａｉｌｕｒｅ−Ｃｏｕｎｔ＞ＤＲＸ−Ｉｎａｃｔｉｖｉｔｙ−ＬＢＴ−ＦａｉｌｕｒｅＴｈｒｅｓｈｏｌｄである場合、および、
１＞ＤＲＸ−Ｉｎａｃｔｉｖｉｔｙ−ＴｉｍｅｒＲｅｓｔａｒｔＣｏｕｎｔ＜＝ＤＲＸ−Ｉｎａｃｔｉｖｉｔｙ−Ｒｅｓｔａｒｔ−Ｔｈｒｅｓｈｏｌｄである場合、
２＞ＤＲＸ−Ｉｎａｃｔｉｖｉｔｙ−ＬＢＴ−Ｆａｉｌｕｒｅ−Ｃｏｕｎｔを０に設定して、
２＞ＤＲＸ−Ｉｎａｃｔｉｖｉｔｙ−ＴｉｍｅｒＲｅｓｔａｒｔＣｏｕｎｔを１だけインクリメントして、
２＞ｄｒｘ−ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒを起動または再起動し、

１＞ＬＢＴ失敗が検出された場合、
２＞ＤＲＸ−Ｉｎａｃｔｉｖｉｔｙ−ＬＢＴ−Ｆａｉｌｕｒｅ−Ｃｏｕｎｔをインクリメントする。
ＤＲＸ−Ｉｎａｃｔｉｖｉｔｙ−ＬＢＴＲｅｓｔａｒｔＴｈｒｅｓｈｏｌｄを超えた場合、以下のアクションを実行してもよい。
１＞ＤＲＸ−Ｉｎａｃｔｉｖｉｔｙ−ＴｉｍｅｒＲｅｓｔａｒｔＣｏｕｎｔ＞ＤＲＸ−Ｉｎａｃｔｉｖｉｔｙ−Ｒｅｓｔａｒｔ−Ｔｈｒｅｓｈｏｌｄである場合
２＞ショートＤＲＸサイクルが設定されている場合、
３＞ｄｒｘ−ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒの満了後の最初のシンボル、またはＤＲＸコマンドＭＡＣ ＣＥの受信終了後の最初のシンボルで、ｄｒｘ−ＳｈｏｒｔＣｙｃｌｅＴｉｍｅｒを起動または再起動して、
３＞ショートＤＲＸサイクルを使用し、
２＞さもなければ、
３＞ロングＤＲＸサイクルを使用する。
ＬＢＴ失敗が発生したときに非アクティブタイムを起動または再起動することによってＤＲＸアクティブタイムを延長することは、設定可能なオプションであるか、または現在アクティブなサービスに依存しているべきである。例えば、ＵＲＬＬＣサービスがサポートされ得る場合、ＬＢＴ失敗が発生したときにスケジューリング機会を維持することがより重要になる。
あるいは、ＤＲＸアクティブタイムの延長時間は、設定されたＤＲＸインアクティビティタイマの期間と異なっていてもよい。別の設定値であってもよく、または、好ましくは現在のＤＲＸアクティブタイム期間中に検出されたＬＢＴ失敗の量に対する期間であってもよい。
別の例では、ＤＲＸ手順を動的に適応させることによって、ＬＢＴ動作によって生じるＤＲＸの非効率性に対処する方法があり得る。ＵＥが各ＤＲＸサイクルをウェイクアップするときに、ＤＲＸ設定をＬＢＴ動作に応じて動的に調整してもよい。例えば、ＤＲＸオンデュレーション、インアクティビティ、またはＤＲＸサイクルを周期的に調整してもよい。これは、各ＤＲＸサイクルであってもよい。
送信前にＮＢはクリアチャネル評価（ＣＣＡ）を判定し、チャネルアクセス優先度クラス（ＣＡＰＣ）を選択する。ＣＡＰＣには、最大チャネル占有時間（ＭＣＯＴ）およびコンテンションウィンドウサイズ（ＣＷＳ）が選択される。ＭＣＯＴ期間中は送信を行うことができる一方で、ＣＣＡおよびＣＷＳの期間中は送信を行うことができない。送信タイミングを動的に調整し得るため、ＵＥのＤＲＸ動作を動的に調整して、ＮＢによって判定された送信機会によりよく一致させ得る。
これを達成するために、各ＤＲＸサイクルにＮＢからシグナリングされるダウンリンクＬＢＴ成功表示に加えて、またはこれに含まれる、ＣＣＡ期間、選択されたＭＣＯＴもしくはＣＷＳ、または他のタイミング情報がＭＡＣに提供され得、ダウンリンクおよびアップリンクの送信機会をより正確に判定することが可能になる。ＭＣＯＴ、ＣＷＳ、または他のタイミングは、選択されたタイミングを表すチャネルアクセス優先度クラス（ＣＡＰＣ）または別のインデックスによって特定され得る。
ＬＢＴタイミング情報の受信に基づいて、ＵＥ ＤＲＸ手順は、ＭＣＯＴ期間と整合するようにアクティブタイムを動的に調整し、ＣＷＳおよび場合によりＣＣＡ期間にＤＲＸを適用する。
例えば、各ＤＲＸサイクルの開始時に、ＮＢによって選択されたＭＣＯＴにオンデュレーションを設定してもよい。同様に、非アクティブタイマは、選択されたＭＣＯＴと整合するように設定されてもよい。
あるいは、ＵＥは、ＣＷＳおよび場合によりＣＣＡ期間にＤＲＸに入ってもよい。例えば、アクティブタイムには、ＭＣＯＴ期間と重なる、またはＣＷＳおよび場合によりＣＣＡ期間と重ならないオンデュレーションおよび非アクティブタイム期間のみが含まれる。例えば、ＭＡＣ仕様を以下のように修正してもよい。
ＤＲＸサイクルが設定されている場合、アクティブタイムには、以下の時間が含まれる。
・ｄｒｘ−ｏｎＤｕｒａｔｉｏｎＴｉｍｅｒ、またはｄｒｘ−ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒ、またはｄｒｘ−ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒＤＬ、またはｄｒｘ−ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒＵＬ、またはｒａ−ＣｏｎｔｅｎｔｉｏｎＲｅｓｏｌｕｔｉｏｎＴｉｍｅｒ（５．１．５節に記載されているように）が実行されている間、および、
・ｄｒｘ−ＭＣＯＴ−Ｔｉｍｅｒが実行されている間。
またはその代わりに、
ＤＲＸサイクルが設定されている場合、アクティブタイムには、以下の時間が含まれる。
・ｄｒｘ−ｏｎＤｕｒａｔｉｏｎＴｉｍｅｒ、またはｄｒｘ−ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒ、またはｄｒｘ−ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒＤＬ、またはｄｒｘ−ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒＵＬ、またはｒａ−ＣｏｎｔｅｎｔｉｏｎＲｅｓｏｌｕｔｉｏｎＴｉｍｅｒ（５．１．５節に記載されているように）が実行されている間、および、
・ｄｒｘ−ＣＷＳ−Ｔｉｍｅｒが実行されていない間。
（スケジューリング要求）
ＳＲ手順の以下の修正は、ＮＲ−ＵにおけるＬＢＴの影響を考慮に入れる。
保留中のＳＲがあり、場合により一定時間にわたってＬＢＴ失敗が判定された場合、ランダムアクセス手順が開始され、保留中のＳＲがキャンセルされるべきである。これは、ＬＢＴ失敗によりＰＵＣＣＨリソースが使用不能になった場合に必要となることがある。この場合、ＲＡ手順が試行され、この手順が失敗した場合は、問題を解決するために無線リンク失敗が宣言される。例えば、ＭＡＣ仕様を以下のように修正してもよい。
少なくとも１つのＳＲが保留されている限り、ＭＡＣエンティティは、各保留中のＳＲに対して、以下であるものとする。
１＞ＭＡＣエンティティが、保留中のＳＲに対して妥当なＰＵＣＣＨリソースを設定していない場合、または、
１＞ＬＢＴ失敗が検出された場合、
２＞ＳｐＣｅｌｌでランダムアクセス手順（例えば、［２］の５．１節を参照）を開始し、保留中のＳＲをキャンセルする。
ＰＵＣＣＨリソースの妥当性はまた、ＬＢＴ成功またはＬＢＴ失敗に対して定義されてもよい。例えば、ＭＡＣ仕様を以下のように修正してもよい。
ＬＢＴ失敗が判定されていないＳＲ送信機会時にアクティブなＢＷＰ上のＰＵＣＣＨリソースのみが妥当と見なされる。
少なくとも１つのＳＲが保留されている限り、ＭＡＣエンティティは、各保留中のＳＲに対して、以下であるものとする。
１＞ＭＡＣエンティティが、保留中のＳＲに対して妥当なＰＵＣＣＨリソースを設定していない場合、
２＞ＳｐＣｅｌｌでランダムアクセス手順（例えば、［２］の５．１節を参照）を開始し、保留中のＳＲをキャンセルする。
上記の例は、「ＬＢＴ失敗なし」の検出の観点から表されることもあるが、「ＬＢＴ成功」の検出で表されることもある。ＬＢＴ失敗またはＬＢＴ成功は、単一のインスタンスではないことがある。複数のＬＢＴ失敗または成功の検出であってもよい。ＲＡ手順は、ＰＵＣＣＨのＳＲ送信に影響を及ぼす一連のＬＢＴ失敗後にのみ開始されてもよい。
ＬＢＴ失敗もしくはＬＢＴ成功をカウントする、または連続ＬＢＴ失敗もしくは連続ＬＢＴ成功をカウントするように手順を定義してもよい。ＬＢＴ失敗もしくは連続ＬＢＴ失敗が、設定された最大ＬＢＴ失敗閾値を超えた場合、またはＬＢＴ成功もしくは連続ＬＢＴ成功が、設定された最小ＬＢＴ成功閾値未満であり得る場合にのみ、ランダムアクセス手順が開始される。
以下に別の例を示す。物理層がＳＲを送信するように指示されると、ＳＲ送信に対するＬＢＴ成功の判定時にのみ、ＳＲ禁止タイマが起動され、ＳＲカウンタがインクリメントされ得る。例えば、ＭＡＣ仕様を以下のように修正してもよい。
２＞ＭＡＣエンティティが、設定されたＳＲのための妥当なＰＵＣＣＨリソース上でＳＲ送信機会を有する場合、および、
２＞ＳＲ送信機会時に、ｓｒ−ＰｒｏｈｉｂｉｔＴｉｍｅｒが実行されていない場合、および
２＞ＳＲ送信機会のＰＵＣＣＨリソースが、測定ギャップと重複していない場合、および、
２＞ＳＲ送信時のＰＵＣＣＨリソースが、ＵＬ−ＳＣＨリソースと重複していない場合、
３＞ＳＲ＿ＣＯＵＮＴＥＲ＜ｓｒ−ＴｒａｎｓＭａｘである場合、
４＞物理層に、ＳＲのための１つの妥当なＰＵＣＣＨリソース上でＳＲをシグナリングするように指示して、
ＬＢＴ成功と判定された場合、
５＞ｓｒ−ＰｒｏｈｉｂｉｔＴｉｍｅｒを起動して、
５＞ＳＲ＿ＣＯＵＮＴＥＲを１だけインクリメントする。
あるいは、既存の手順で行われるように、ＳＲ禁止タイマが起動され、ＳＲカウンタがインクリメントされてもよいが、ＬＢＴ失敗と判定された場合には、禁止タイマが停止されてもよく、ＳＲカウンタがデクリメントされてもよい。
この修正は、ＳＲカウンタがＳＲ Ｔｒａｎｓ Ｍａｘに到達しないことで、ＳＲ送信がＬＢＴ失敗によってブロックされたときに、物理リソースを解放してＲＡ手順を開始するように、後続のＳＲ送信を遅延させるＳＲ禁止タイマが設定されないことを確実にするために、必要な場合がある。
また、ＳＲ送信手順が成功しなかったとＵＥが決して判定しないように、ＬＢＴ失敗によりＳＲ送信カウンタを大幅にインクリメントしないこと、またはＳＲ送信カウンタを無期限にインクリメントしないことを回避する必要がある場合もある。ＳＲ送信カウントをインクリメントさせないことは、指定されたまたは設定された最大値に制限され得る。例えば、ＭＡＣ仕様を以下のように修正してもよい。
２＞ＳＲ ＬＢＴ失敗が検出されなかった場合、または、
２＞ＳＲ−Ｔｒａｎｓｍｉｓｓｉｏｎ−ＬＢＴ−Ｆａｉｌｕｒｅ−Ｃｏｕｎｔ＞ＳＲ−Ｔｒａｎｓｍｉｓｓｉｏｎ−ＬＢＴ−ＦａｉｌｕｒｅＴｈｒｅｓｈｏｌｄである場合、
３＞ＳＲ＿ＣＯＵＮＴＥＲを１だけインクリメントして、
３＞
２＞ＳＲＴｒａｎｓｍｉｓｓｉｏｎ−ＬＢＴ−Ｆａｉｌｕｒｅが検出された場合、
２＞ＳＲＴｒａｎｓｍｉｓｓｉｏｎ−ＬＢＴ−Ｆａｉｌｕｒｅ−Ｃｏｕｎｔをインクリメントする。
ＲＡ−ＰｒｅａｍｂｌｅＴｒａｎｓｍｉｓｓｉｏｎ−ＬＢＴ−ＦａｉｌｕｒｅＴｈｒｅｓｈｏｌｄを超えた場合、以下のアクションを実行してもよいし、ＭＡＣ仕様を以下のように修正してもよい。
２＞ＳＲ−Ｔｒａｎｓｍｉｓｓｉｏｎ−ＬＢＴ−Ｆａｉｌｕｒｅが検出された場合、
２＞ＳＲ−Ｔｒａｎｓｍｉｓｓｉｏｎ−ＬＢＴ−Ｆａｉｌｕｒｅ−Ｃｏｕｎｔをインクリメントして、
２＞ＳＲ−Ｔｒａｎｓｍｉｓｓｉｏｎ−ＬＢＴ−Ｆａｉｌｕｒｅ−Ｃｏｕｎｔ＞ＳＴｒａｎｓｍｉｓｓｉｏｎ−ＬＢＴ−ＦａｉｌｕｒｅＴｈｒｅｓｈｏｌｄである場合、
以下に別の例を示す。ＢＳＲ送信に対するＬＢＴ成功が判定された場合にのみ、保留中のＳＲ（単数または複数）がキャンセルされ得、ＳＲ禁止タイマが停止され得る。これは、ＬＢＴ失敗により現在のＳＲが送信されないときに、後続のＳＲ送信を遅延させる禁止タイマが設定されないことを確実にするために、必要な場合がある。
例えば、ＭＡＣ ＰＤＵ送信に対してＬＢＴ成功が判定され、このＰＤＵが、ＭＡＣ ＰＤＵアセンブリ前にＢＳＲ（［２］の５．４．５項を参照）をトリガした最後のイベントまでの（および含まれている）バッファ状態を有するＢＳＲ ＭＡＣ ＣＥを含む場合、ＭＡＣ ＰＤＵアセンブリ前にトリガされた保留中のＳＲは全てキャンセルされるものとし、それぞれのｓｒ−ＰｒｏｈｉｂｉｔＴｉｍｅｒは停止されるものとする。
上記の例は、ＬＢＴ成功検出の代わりに、ＬＢＴ失敗検出の観点から以下のように表されてもよい。ＭＡＣ ＰＤＵ送信に対してＬＢＴ失敗が判定されず、このＰＤＵが、ＭＡＣ ＰＤＵアセンブリ前にＢＳＲ（［２］の５．４．５項を参照）をトリガした最後のイベントまでの（および含まれている）バッファ状態を有するＢＳＲ ＭＡＣ ＣＥを含む場合、ＭＡＣ ＰＤＵアセンブリ前にトリガされた保留中のＳＲは全てキャンセルされるものとし、それぞれのｓｒ−ＰｒｏｈｉｂｉｔＴｉｍｅｒは停止されるものとする。
あるいは、ＢＳＲを含むＭＡＣ ＰＤＵがＰＨＹ層に提供されると、既存の手順で行われるように、保留中のＳＲ（単数または複数）がキャンセルされてもよく、禁止タイマが停止されてもよいが、ＬＢＴの失敗（または、ＬＢＴ成功なしと同様な意味合いで）が判定された場合には、保留中のＳＲ（単数または複数）が復元され、禁止タイマが再起動されてもよい。
（バッファステータス報告）
ＢＳＲ手順の以下の修正は、ＮＲ−ＵにおけるＬＢＴの影響を考慮に入れる。
規則的なＢＳＲがトリガされ、送信に利用可能なＵＬ−ＳＣＨリソースがあり得るが、ＬＢＴ失敗によって送信がブロックされている場合、ＳＲがトリガされ得る。ＬＢＴ失敗により利用可能なグラントが損失した場合、後続のグラントがＢＳＲの送信に利用可能になるようにするために新しいＳＲが必要になることがあるため、これが必要になる場合がある。例えば、ＭＡＣ仕様を以下のように修正してもよい。
２＞規則的なＢＳＲがトリガされ、ｌｏｇｉｃａｌＣｈａｎｎｅｌＳＲ−ＤｅｌａｙＴｉｍｅｒが実行されていない場合、
３＞新しい送信に利用可能なＵＬ−ＳＣＨリソースがない場合、または、
３＞ＭＡＣエンティティに設定されたアップリンクグラント（単数または複数）が設定されており、上位層によって論理チャネルＳＲマスキング（ｌｏｇｉｃａｌＣｈａｎｎｅｌＳＲ−Ｍａｓｋ）が設定されている論理チャネルに対して規則的なＢＳＲがトリガされなかった場合、または、
３＞新しい送信に利用可能なＵＬ−ＳＣＨリソースが、ＢＳＲ（単数または複数）をトリガした論理チャネル（単数または複数）に設定されたＬＣＰマッピング制限（［２］の５．４．３．１節を参照）を満たさない場合、または、
３＞送信に利用可能なＵＬ−ＳＣＨリソースがあり、この送信に対してＬＢＴ失敗が検出された場合、
４＞スケジューリング要求をトリガする。
上記の修正テキストは、ＬＢＴ失敗の観点から記載されているが、ＬＢＴ成功なしの観点からも表されてもよい。
ＬＢＴ失敗またはＬＢＴ成功は、単一のインスタンスではないことがある。複数のＬＢＴ失敗または成功の検出であってもよい。ＳＲは、ＭＡＣ ＢＳＲ ＣＥ送信に影響を及ぼす一連のＬＢＴ失敗後にのみトリガされてもよい。
また、ＬＢＴ失敗もしくはＬＢＴ成功をカウントする、または連続ＬＢＴ失敗もしくは連続ＬＢＴ成功をカウントするように手順を定義してもよい。ＬＢＴ失敗もしくは連続ＬＢＴ失敗が設定された最大ＬＢＴ失敗閾値を超えた場合、またはＬＢＴ成功もしくは連続ＬＢＴ成功が設定された最小ＬＢＴ成功閾値未満であり得る場合にのみ、ＳＲがトリガされる。
ＢＳＲ ＭＡＣ ＣＥの送信がＬＢＴ失敗によってブロックされ、時間をおいて再送信される場合、ＢＳＲがいつ計算されたかをＮＢに通知するため、またはＰＨＲが計算されたときの送信条件をＮＢに通知するために、追加のシグナリングが導入される。
ＮＢがＢＳＲを適切に処理するためには、ＢＳＲがいつ計算されたかをＮＢが認識することが必要な場合がある。
アンライセンス周波数帯で動作しておらず、ＬＢＴが使用されていない場合、ＮＢはＢＳＲの内容がいつ判定されたかを概ね取得し得る。ＮＢはスケジュールされたものおよび受信されたもの、ならびにＢＳＲの規則を認識しているため、ＢＳＲを適切に解釈し得る。しかし、ＬＢＴが失敗し、ＬＢＴが成功するまで送信が遅延すると、ＮＢは古くなったＢＳＲまたは不正確なＢＳＲを受信することがあり、場合により、ＵＥによって必要とされるよりも多いリソース割り当て、もしくはＵＥによって必要とされるよりも少ないリソース、または送信遅延およびＱｏＳ保証のペナルティにつながる。以下に、この問題に対処するための複数の方法を示す。第１の方法では、ＢＳＲの計算がいつ構築されたのかをＮＢが判定できるような追加の表示をＢＳＲに提供する。これは、最初のＬＢＴ失敗の時間に対するＬＢＴによる遅延であってもよく、または絶対時間基準であってもよい。第２の方法では、ＢＳＲのためのＬＢＴによって被った実効遅延をＮＢが判定し得るように、ＬＢＴの失敗または成功がＮＢに独立して示されてもよい。第３の方法では、ＰＨＲが計算されたときに使用されたグラント（例えば、アップリンクグラント）をＮＢに通知する追加情報をＰＨＲと共に提供する。
ＢＳＲがいつ構築されたかをＮＢが認識することができる追加情報を受信することが好ましいが、必要というわけではない。あるいは、ＢＳＲが不正確な情報を提供している場合、ＮＢは少なくとも認識しなければならない。これは、ＵＥがＮＢにＬＢＴ失敗および成功を示すことで、ＢＳＲを遅延させたＬＢＴ失敗があったことをＮＢが判定できるようにすることにより、実現され得る。
以下に別の例を示す。ＢＳＲのトリガ条件は、ＬＢＴ失敗を考慮すべきである。新しいデータが利用可能になり、現在指定されている規則的なＢＳＲトリガ基準、パディングＢＳＲトリガ条件、ＢＳＲ再送信タイマ満了、ＢＳＲ周期タイマ満了のトリガ基準を満たすには、ＬＢＴが成功した場合にのみ考慮するべきである。ＬＢＴ基準の追加は、既存の各トリガに対して相互に排他的であり、したがって、既存の基準のサブセットにのみ影響を与え得る。
例えば（全てのトリガを考慮する場合）、ＭＡＣ仕様は以下のように修正されてもよい。
以下のイベントのいずれかが発生した場合、ＢＳＲがトリガされるものとする。
・ＭＡＣエンティティが、ＬＣＧに属する論理チャネルで利用可能な新しいＵＬデータを有し、および、
・新しいＵＬデータが、いずれかのＬＣＧに属する利用可能なＵＬデータを含むどの論理チャネルの優先度よりも高い優先度を持つ論理チャネルに属し、ＬＢＴがその後成功する、または、
・ＬＣＧに属する論理チャネルのいずれにも利用可能なＵＬデータが含まれておらず、ＬＢＴがその後成功する。
この場合、ＢＳＲは、以下のように「規則的なＢＳＲ」と呼ばれる、
・ＵＬリソースが割り当てられ、パディングビット数がバッファステータス報告ＭＡＣ ＣＥとそのサブヘッダを加えたサイズ以上であり、ＬＢＴがその後成功した場合、ＢＳＲは以下のように「パディングＢＳＲ」と呼ばれる、
・ｒｅｔｘＢＳＲ−Ｔｉｍｅｒが満了し、ＬＣＧに属する論理チャネルのうち少なくとも１つにＵＬデータが含まれており、ＬＢＴがその後成功した場合、そのＢＳＲを以下のように「規則的なＢＳＲ」と呼ばれる、
・ｐｅｒｉｏｄｉｃＢＳＲ−Ｔｉｍｅｒが満了し、ＬＢＴがその後成功した場合、ＢＳＲは以下のように「周期的なＢＳＲ」と呼ばれる。
ＭＡＣエンティティは、以下であるものとする。
１＞バッファステータス報告手順により、少なくとも１つのＢＳＲがトリガされて、キャンセルされていないと判定された場合、
２＞ＵＬ−ＳＣＨのリソースが新しい送信に利用可能であり、ＬＢＴ成功と判定された場合、
３＞ＢＳＲ ＭＡＣ ＣＥ（単数または複数）を生成するように、多重化およびアセンブリ手順に指示して、
３＞生成されたＢＳＲが全てロングまたはショートのトランケートＳＲの場合を除き、ｐｅｒｉｏｄｉｃＢＳＲ−Ｔｉｍｅｒを起動または再起動して、
３＞ｒｅｔｘＢＳＲ−Ｔｉｍｅｒを起動または再起動する。
複数のイベントがＢＳＲをトリガした場合でも、ＭＡＣ ＰＤＵは最大で１つのＢＳＲ ＭＡＣ ＣＥを含むものとする。規則的なＢＳＲおよび周期的なＢＳＲは、パディングＢＳＲよりも優先されるものとする。
ＭＡＣエンティティは、任意のＵＬ−ＳＣＣＨで新しいデータの送信に対するグラントを受信すると、ｒｅｔｘＢＳＲ−Ｔｉｍｅｒを再起動するものとする。
ＵＬグラント（単数または複数）が送信可能な全ての保留データに適応でき、ＬＢＴ成功が判定されたが、追加的にＢＳＲ ＭＡＣ ＣＥとそのサブヘッダに適応するには十分ではないとき、トリガされた全てのＢＳＲはキャンセルされ得る。ＬＢＴ成功が判定され、ＢＳＲ ＭＡＣ ＣＥを含むＭＡＣ ＰＤＵが送信されたとき、ＭＡＣ ＰＤＵアセンブリ前にトリガされた全てのＢＳＲは、キャンセルされるものとする。
上記の修正テキストは、ＬＢＴ成功の観点から記載されているが、ＬＢＴ失敗なしの観点からも表されてもよい。
ＬＢＴ失敗またはＬＢＴ成功は、単一のインスタンスではないことがある。複数のＬＢＴ失敗または成功の検出であってもよい。ＳＲは、ＭＡＣ ＢＳＲ ＣＥ送信に影響を及ぼす一連のＬＢＴ失敗後にのみトリガされてもよい。
また、ＬＢＴ失敗もしくはＬＢＴ成功をカウントする、あるいは連続ＬＢＴ失敗もしくは連続ＬＢＴ成功をカウントするように手順を定義してもよい。ＬＢＴ失敗もしくは連続ＬＢＴ失敗が、設定された最大ＬＢＴ失敗閾値を超えた場合、またはＬＢＴ成功もしくは連続ＬＢＴ成功が、設定された最小ＬＢＴ成功閾値未満であり得る場合にのみ、ＳＲがトリガされる。
上記の例示的なＭＡＣ固有の変更は、ＬＢＴ成功の観点から記載されているが、例はＬＢＴ失敗なしの観点からも同様に表されてもよい。
あるいは、ＢＳＲ周期タイマおよびＢＳＲ再送信タイマは、既存の手順で行われるように起動または再起動してもよいが、ＬＢＴ失敗と判定された場合には、ＢＳＲ周期タイマおよびＢＳＲ再送信タイマをＬＢＴ失敗による最後のリセット前の残りの値に、または、例えば設定された時間値などの異なる時間値にリセットされる。
この修正は、ＢＳＲの送信がＬＢＴ失敗によってブロックされたときに、ＢＳＲの周期的な送信またはＢＳＲの再送信が遅延しないように、ＢＳＲ周期タイマまたはＢＳＲ再送信タイマがリセットされ得ないことを確実にするために、必要となる場合がある。
（論理チャネル優先順位付け（ＬＣＰ）手順
）
ＬＣＰ手順の以下の修正は、ＮＲ−ＵにおけるＬＢＴの影響を考慮に入れてもよい。
送信前にＬＢＴ失敗が検出された場合、ＭＡＣ ＰＤＵは生成されるべきではない。
例えば、ＭＡＣ仕様を以下のように修正してもよい。
ＭＡＣエンティティは、以下の条件を満たす場合、ＨＡＲＱエンティティのＭＡＣ ＰＤＵを生成しないものとする。
・ＭＡＣエンティティがｓｋｉｐＵｐｌｉｎｋＴｘＤｙｎａｍｉｃに設定されており、ＨＡＲＱエンティティに示されたグラントがＣ−ＲＮＴＩに宛てられたものであるか、またはＨＡＲＱエンティティに示されたグラントが設定されたアップリンクグラントである、および、
・ＴＳ３８．２１２に規定されているように、このＰＵＳＣＨ送信に対して要求された非周期的なＣＳＩがない、および、
・ＭＡＣ ＰＤＵは、０個のＭＡＣ ＳＤＵを含む、および、
・ＭＡＣ ＰＤＵには周期的なＢＳＲのみが含まれ、いずれのＬＣＧにも利用可能なデータがないか、またはＭＡＣ ＰＤＵにはパディングＢＳＲのみが含まれている、または、
・ＬＢＴ失敗が検出されなかった。
あるいは、ＬＢＴ成功が検出されたことを基準にしてもよい。
この修正は、このＭＡＣ ＰＤＵが後続のグラントに受け入れられないことがあり（例えば、ＵＬグラントのサイズのため）、また、生成されたＭＡＣ ＣＥ（単数または複数）がＭＡＣ ＰＤＵ送信時に誤った情報（例えば、ＰＨＲ、ＢＳＲ．．．）を提供し得るために、必要となる場合がある。
以下に別の例を示す。あるいは、ＭＡＣ ＰＤＵを生成して物理層に提供してもよいが、このＭＡＣ ＰＤＵのＬＢＴ失敗が検出されると、ＬＣＰ手順を再起動して新しいＭＡＣ ＰＤＵを生成する。
これを達成するために、このＭＡＣ ＰＤＵ内に組み込まれていたＭＡＣ ＳＤＵは、ＬＢＴ成功が判定されるまで保存されてもよい。これらのＭＡＣ ＳＤＵは、すでに構築されたＭＡＣ ＰＤＵからこれらのＭＡＣ ＳＤＵを再作成しなければならないのではなく、再処理し得る。
より単純な事例としては、グラントがより大きい場合、ＵＥがパディングを除去し、ＬＣＰに従って残りのスペースで追加データを多重化するか、またはＵＥがサブＰＤＵ（ＭＡＣ ＳＤＵおよびＣＥ）をバックアウトして、前回のグラントに対してデータが処理されなかったかのようにＬＣＰを再形成することである。
しかし、この場合でも、ＬＡＡで以前に判定されたＭＡＣ ＣＥをすでに構築しており、古いＰＨＲ ＣＥを許可している場合がある。その場合、ネットワークは、どのような送信に基づいて、ＰＨＲがどのように計算されたのかわからないことがある。
ＭＡＣ手順（ＢＳＲ、ＰＨＲ．．．）のタイマおよびカウンタは前回の（失敗した）送信によってすでに影響を受けているため、ＣＥの再構築は複雑である。
ＭＡＣ ＰＤＵの多重化およびアセンブリが再実行されたときに、トリガが再評価され、報告された値が再計算されるように、ＭＡＣ ＣＥは回復して保存され得るか、またはこれらのＭＡＣ ＣＥをトリガしたイベントが復元され得る。
さらに複雑な事例は、グラントがより小さいときにどうするかである。最初に、ＬＣＰに従って、前回のＰＤＵから何が送信され得るかを判定する。次に、送信されないことがあるＭＡＣ ＳＤＵを回復し、ＭＡＣ ＣＥの送信に関連付けられたＭＡＣ手順のタイマおよびカウンタをリセットして、ＭＡＣ ＣＥが構築される前の値にタイマおよびカウンタを設定し得る。
前回の送信以降に、新たに優先度の高いデータまたはその他のＭＡＣ ＣＥのトリガとなるイベントが受信された可能性がある。この可能性に対処するために、多重化アセンブリ手順は、失敗したＭＡＣ ＰＤＵ送信に関連付けられたＭＡＣ ＳＤＵを優先しないことがある。
ＭＡＣ ＣＥにも同様の問題が発生することがあり、これらは今では古くなり、ＭＡＣ手順をバックアウトすることが複雑である。
ＮＢはＭＡＣ ＣＥの送信が遅延したこと、または元々送信が予定されていたときを通知すべきである。
別の問題は、セグメンテーションがＲＬＣで実行され、ＭＡＣのＳＤＵが大きすぎる可能性があることである。ＭＡＣ要求ＲＬＣに前回のＲＬＣ ＰＤＵをバックアウトさせることは、非常に複雑である。これに対処する１つの方法は、このＭＡＣ ＳＤＵに対応するＲＬＣ ＰＤＵ、および新しいＭＡＣ ＰＤＵ送信に多重化されない場合がある他のＳＤＵに対して、ＲＬＣ否定応答を偽装することである。
（ビーム障害検出および回復）
ビーム障害および検出手順の以下の修正は、ＮＲ−ＵにおけるＬＢＴの影響を考慮に入れる。ビーム障害回復タイマが満了しても、ビーム障害回復のためのランダムアクセス手順の開始以降にＬＢＴ失敗が検出された場合、ビーム障害回復タイマを延長するべきである。これは、ビーム障害回復タイマの早期満了、および場合によりセル再選択またはＲＲＣ（再）確立を回避するために、必要な場合がある。
図２〜図１０など、本明細書に示されているステップを実行するエンティティは、論理エンティティによって実行されてもよいことが理解される。ステップは、図１２Ａ〜図１２Ｇに示されているようなデバイス、サーバ、またはコンピュータシステムのメモリに保存され、そのプロセッサ上で実行されてもよい。本明細書に開示されている例示的な方法の間で、ステップをスキップすること、ステップを組み合わせること、またはステップを追加することが意図されている。
表１は、例示的な略語または定義を提供する。
Figure 2022501946
Figure 2022501946
Figure 2022501946
図１１は、本明細書で説明したＮＲ−Ｕ ＬＢＴ ＭＡＣ手順の方法、システム、およびデバイスに基づいて生成され得る例示的なディスプレイ（例えば、グラフィカルユーザインタフェース）を示す。ディスプレイインタフェース９０１（例えば、タッチスクリーンディスプレイ）は、特に、ＰＨＲ関連パラメータおよび方法フローなど、ＮＲ−Ｕ ＬＢＴ ＭＡＣ手順に関連付けられたブロック９０２のテキストを提供してもよい。本明細書で説明したステップのいずれかの進捗（例えば、送信されたメッセージまたはステップの成功）をブロック９０２に表示してもよい。さらに、グラフィカル出力９０２が、ディスプレイインタフェース９０１に表示されてもよい。グラフィカル出力は、ＮＲ−Ｕ ＬＢＴ ＭＡＣ手順の方法、システム、およびデバイスを実装するデバイスのトポロジー、本明細書で議論される任意の方法またはシステムの進捗のグラフィカル出力などであってもよい。
第３世代パートナーシッププロジェクト（3rd Generation Partnership Project：３ＧＰＰ）は、無線アクセス、コアトランスポートネットワーク、ならびに、コーデック、セキュリティ、およびサービス品質に関する作業を含むサービス能力を含む、セルラー通信ネットワーク技術の技術標準を開発している。最近の（Radio Access Technology：ＲＡＴ）標準には、ＷＣＤＭＡ（登録商標）（一般に３Ｇと呼ばれる）、ＬＴＥ（一般に４Ｇと呼ばれる）、ＬＴＥ−Ａｄｖａｎｃｅｄ標準、および「５Ｇ」とも呼ばれる新しい無線技術（New Radio：ＮＲ）がある。３ＧＰＰ ＮＲ標準の開発は今後も継続されると予想されており、次世代無線アクセス技術（新ＲＡＴ）の定義が含まれる。これには、７ＧＨｚ未満の新しいフレキシブル無線アクセスの提供、および７ＧＨｚを超える新しいウルトラモバイルブロードバンド無線アクセスの提供が含まれると予想されている。フレキシブル無線アクセスは、６ＧＨｚ未満の新しい周波数帯での後方互換性のない新しい無線アクセスで構成され、同じ周波数帯で多重化され得る異なる動作モードを含むことで、要件が異なる幅広い３ＧＰＰ ＮＲユースケースに対処することが予想されている。ウルトラモバイルブロードバンドには、例えば、屋内用途およびホットスポットなどのウルトラモバイルブロードバンドアクセスの機会を提供するセンチ波およびミリ波の周波数帯が含まれることが予想されている。特にウルトラモバイルブロードバンドでは、センチ波およびミリ波専用の設計最適化により、７ＧＨｚ未満のフレキシブル無線アクセスと共通の設計フレームワークを共有することが予想されている。
３ＧＰＰでは、ＮＲがサポートすることが予想される様々なユースケースが特定されており、その結果、データレート、レイテンシ、およびモビリティに関する多種多様なユーザ体験の要件が生じている。ユースケースには、以下のような一般的なカテゴリ、拡張モバイルブロードバンド（Enhanced Mobile Broadband：ｅＭＢＢ）超高信頼性低遅延通信（Ultra-Reliable Low-Latency Communication：ＵＲＬＬＣ）、大規模マシンタイプ通信（Massive Machine Type Communications：ｍＭＴＣ）、ネットワーク運用（例えば、ネットワークスライシング、ルーティング、マイグレーションおよびインターワーキング、省エネ）、ならびに、高度化した車両対全て（Enhanced Vehicle-To-Everything：ｅＶ２Ｘ）通信であって、車両対車両通信（Vehicle-To-Vehicle Communication：Ｖ２Ｖ）、車両対インフラストラクチャ通信（Vehicle-To-Infrastructure Communication：Ｖ２Ｉ）、車両対ネットワーク通信（Vehicle-To-Network Communication：Ｖ２Ｎ）、車両対歩行者通信（Vehicle-To-Pedestrian Communication：Ｖ２Ｐ）、および他のエンティティとの車両通信のいずれかを含み得るものが含まれる。これらのカテゴリにおける特定のサービスおよび用途には、例えば、モニタリングおよびセンサネットワーク、デバイスの遠隔操作、双方向の遠隔操作、パーソナルクラウドコンピューティング、ビデオストリーミング、ワイヤレスクラウドベースのオフィス、ファーストレスポンダの接続性、自動車緊急通報システム、災害警報、リアルタイムゲーミング、複数人でのビデオ通話、自動運転、拡張現実、タッチインターネット、仮想現実、ホームオートメーション、ロボット、および空中ドローンが、ほんの一部の例として挙げられる。これらのユースケースの全ておよびその他のユースケースが、本明細書で意図されている。
図１２Ａは、本明細書で記載および請求された図１から図１０に示されたシステムおよび方法などの、ＮＲ−Ｕ ＬＢＴ ＭＡＣ手順の方法および装置が使用され得る例示的な通信システム１００を示す。通信システム１００は、無線送受信ユニット（Wireless Transmit/Receive Unit：ＷＴＲＵ）１０２ａ、１０２ｂ、１０２ｃ、１０２ｄ、１０２ｅ、１０２ｆ、または１０２ｇ（これらは、一般的または集合的に、ＷＴＲＵ１０２またはＷＴＲＵ１０２と呼ばれることがある）を含んでもよい。通信システム１００は、無線アクセスネットワーク（Radio Access Network：ＲＡＮ）１０３／１０４／１０５／１０３ｂ／１０４ｂ／１０５ｂ、コアネットワーク１０６／１０７／１０９、公衆交換電話網（Public Switched Telephone Network：ＰＳＴＮ）１０８、インターネット１１０、他のネットワーク１１２、およびネットワークサービス１１３を含んでもよい。ネットワークサービス１１３は、例えば、Ｖ２Ｘサーバ、Ｖ２Ｘ機能、ＰｒｏＳｅサーバ、ＰｒｏＳｅ機能、ＩｏＴサービス、ビデオストリーミング、またはエッジコンピューティングなどを含んでもよい。
本明細書に開示された概念は、任意の数のＷＴＲＵ、基地局、ネットワーク、またはネットワーク要素と共に使用されてもよいことが理解されるであろう。ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄ、１０２ｅ、１０２ｆ、または１０２ｇのそれぞれは、無線環境で動作または通信するように構成された任意のタイプの装置またはデバイスであってもよい。各ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄ、１０２ｅ、１０２ｆ、または１０２ｇは、図１２Ａ、図１２Ｂ、図１２Ｃ、図１２Ｄ、図１２Ｅ、または図１２Ｆに、ハンドヘルド無線通信装置として図示されている場合があるが、５Ｇ無線通信に意図されている多種多様なユースケースでは、各ＷＴＲＵは、ワイヤレス信号を送信もしくは受信するように構成された任意のタイプの装置もしくはデバイスを含んでもよく、または具体化されてもよいことが理解され、ほんの一例として、ユーザ機器（User Equipment：ＵＥ）、移動局、固定または移動加入者ユニット、ポケットベル、セルラー電話、パーソナルデジタルアシスタント（Personal Digital Assistant：ＰＤＡ）、スマートフォン、ラップトップ、タブレット、ネットブック、ノートブックコンピュータ、パーソナルコンピュータ、無線センサ、家電製品、スマートウォッチまたはスマートウェアなどのウェアラブルデバイス、医療または電子ヘルスデバイス、ロボット、産業機器、ドローン、自動車、バス、トラック、列車、または飛行機などの車両などが含まれる。
通信システム１００はまた、基地局１１４ａおよび基地局１１４ｂを含んでもよい。図１２Ａの例では、各基地局１１４ａおよび１１４ｂは、単一の要素として図示されている。実際には、基地局１１４ａおよび１１４ｂは、任意の数の相互接続された基地局またはネットワーク要素を含んでもよい。基地局１１４ａは、コアネットワーク１０６／１０７／１０９、インターネット１１０、ネットワークサービス１１３、または他のネットワーク１１２などの１つ以上の通信ネットワークへのアクセスを容易にするために、ＷＴＲＵ１０２ａ、１０２ｂ、および１０２ｃのうちの少なくとも１つと無線でインタフェースするように構成された任意のタイプのデバイスであってもよい。同様に、基地局１１４ｂは、コアネットワーク１０６／１０７／１０９、インターネット１１０、他のネットワーク１１２、またはネットワークサービス１１３などの１つ以上の通信ネットワークへのアクセスを容易にするために、遠隔無線ヘッド（Remote Radio Head：ＲＲＨ）１１８ａ、１１８ｂ、送受信ポイント（Transmission and Reception Point：ＴＲＰ）１１９ａ、１１９ｂ、または路側機（Roadside Unit：ＲＳＵ）１２０ａ、１２０ｂの少なくとも１つと有線または無線でインタフェースするように構成された任意のタイプのデバイスであってもよい。ＲＲＨ１１８ａ、１１８ｂは、コアネットワーク１０６／１０７／１０９、インターネット１１０、ネットワークサービス１１３、または他のネットワーク１１２などの１つ以上の通信ネットワークへのアクセスを容易にするために、ＷＴＲＵ１０２の少なくとも１つ、例えばＷＴＲＵ１０２ｃと無線でインタフェースするように構成された任意のタイプのデバイスであってもよい。
ＴＲＰ１１９ａ、１１９ｂは、コアネットワーク１０６／１０７／１０９、インターネット１１０、ネットワークサービス１１３、または他のネットワーク１１２などの１つ以上の通信ネットワークへのアクセスを容易にするために、ＷＴＲＵ１０２ｄの少なくとも１つと無線でインタフェースするように構成された任意のタイプのデバイスであってもよい。ＲＳＵ１２０ａおよび１２０ｂは、コアネットワーク１０６／１０７／１０９、インターネット１１０、他のネットワーク１１２、またはネットワークサービス１１３などの１つ以上の通信ネットワークへのアクセスを容易にするために、ＷＴＲＵ１０２ｅまたは１０２ｆの少なくとも１つと無線でインタフェースするように構成された任意のタイプのデバイスであってもよい。例として、基地局１１４ａ、１１４ｂは、無線基地局装置（Base Transceiver Station：ＢＴＳ）、ノードＢ、ｅノードＢ、ホームノードＢ、ホームｅノードＢ、次世代ノードＢ（Next Generation Node-B：ｇノードＢ）、衛星、サイトコントローラ、アクセスポイント（Access Point：ＡＰ）、無線ルータなどであってもよい。
基地局１１４ａは、ＲＡＮ１０３／１０４／１０５の一部であってもよく、これは、基地局コントローラ（Base Station Controller：ＢＳＣ）、無線ネットワークコントローラ（Radio Network Controller：ＲＮＣ）、中継ノードなどの他の基地局またはネットワーク要素（図示せず）も含んでいてもよい。同様に、基地局１１４ｂは、ＲＡＮ１０３ｂ／１０４ｂ／１０５ｂの一部であってもよく、これは、ＢＳＣ、ＲＮＣ、中継ノードなどの他の基地局またはネットワーク要素（図示せず）も含んでいてもよい。基地局１１４ａは、セル（図示せず）と呼ばれ得る特定の地理的領域内で、無線信号を送信または受信するように構成されてもよい。同様に、基地局１１４ｂは、本明細書に開示されているようなＮＲ−Ｕ ＬＢＴ ＭＡＣ手順の方法、システム、およびデバイスのための、セル（図示せず）と呼ばれ得る特定の地理的領域内で、有線または無線信号を送信または受信するように構成されてもよい。同様に、基地局１１４ｂは、セル（図示せず）と呼ばれ得る特定の地理的領域内で、有線信号または無線信号を送信または受信するように構成されてもよい。セルは、さらに、セルセクタに分割されてもよい。例えば、基地局１１４ａに関連付けられたセルは、３つのセクタに分割されてもよい。したがって、一実施例では、基地局１１４ａは、例えば、セルの各セクタに１つずつ、３つのトランシーバを含んでもよい。一実施例では、基地局１１４ａは、多入力多出力（Multiple-Input Multiple Output：ＭＩＭＯ）技術を採用してもよく、したがって、セルの各セクタにつきの複数のトランシーバを利用してもよい。
基地局１１４ａは、エアインタフェース１１５／１１６／１１７を介して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、または１０２ｇの１つ以上と通信してもよく、任意の適切な無線通信リンク（例えば、無線周波数（Radio Frequency：ＲＦ）、マイクロ波、赤外線（Infrared：ＩＲ）、紫外線（Ultraviolet：ＵＶ）、可視光、センチ波、ミリ波など）であってもよい。エアインタフェース１１５／１１６／１１７は、任意の適切な無線アクセス技術（ＲＡＴ）を使用して確立されてもよい。
基地局１１４ｂは、有線またはエアインタフェース１１５ｂ／１１６ｂ／１１７ｂを介して、ＲＲＨ１１８ａ、１１８ｂ、ＴＲＰ１１９ａ、１１９ｂ、またはＲＳＵ１２０ａ、１２０ｂのうちの１つ以上と通信してもよく、これは、任意の適切な有線（例えば、ケーブル、光ファイバなど）または無線通信リンク（例えば、無線周波数（ＲＦ）、マイクロ波、赤外線（ＩＲ）、紫外線（ＵＶ）、可視光、センチ波、ミリ波など）であってもよい。エアインタフェース１１５ｂ／１１６ｂ／１１７ｂは、任意の適切な無線アクセス技術（ＲＡＴ）を使用して確立されてもよい。
ＲＲＨ１１８ａ、１１８ｂ、ＴＲＰ１１９ａ、１１９ｂまたはＲＳＵ１２０ａ、１２０ｂは、エアインタフェース１１５ｃ／１１６ｃ／１１７ｃを介して、ＷＴＲＵ１０２ｃ、１０２ｄ、１０２ｅ、１０２ｆの１つ以上と通信してもよく、これは、任意の適切な無線通信リンク（例えば、無線周波数（ＲＦ）、マイクロ波、赤外線（ＩＲ）、紫外線（ＵＶ）、可視光、センチ波、ミリ波など）であってもよい。エアインタフェース１１５ｃ／１１６ｃ／１１７ｃは、任意の適切な無線アクセス技術（ＲＡＴ）を使用して確立されてもよい。
ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ，１０２ｄ、１０２ｅ、または１０２ｆは、サイドリンク通信などのエアインタフェース１１５ｄ／１１６ｄ／１１７ｄを介して互いに通信してもよく、これは、任意の適切な無線通信リンク（例えば、無線周波数（ＲＦ）、マイクロ波、赤外線（ＩＲ）、紫外線（ＵＶ）、可視光、センチ波、ミリ波など）であってもよい。エアインタフェース１１５ｄ／１１６ｄ／１１７ｄは、任意の適切な無線アクセス技術（ＲＡＴ）を使用して確立されてもよい。
通信システム１００は、多重アクセスシステムであってもよく、ＣＤＭＡ、ＴＤＭＡ、ＦＤＭＡ、ＯＦＤＭＡ、ＳＣ−ＦＤＭＡなどの１つ以上のチャネルアクセス方式を採用してもよい。例えば、ＲＡＮ１０３／１０４／１０５における基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、またはＲＡＮ１０３ｂ／１０４ｂ／１０５ｂにおけるＲＲＨ１１８ａ、１１８ｂ、ＴＲＰ１１９ａ、１１９ｂおよびＲＳＵ１２０ａ、１２０ｂならびにＷＴＲＵ１０２ｃ、１０２ｄ、１０２ｅ、１０２ｆは、ユニバーサル移動体通信システム（Universal Mobile Telecommunications System：ＵＭＴＳ）地上無線アクセス（UMTS Terrestrial Radio Access：ＵＴＲＡ）などの無線技術を実装してもよく、広帯域ＣＤＭＡ（Wideband CDMA：ＷＣＤＭＡ）を使用してエアインタフェース１１５／１１６／１１７または１１５ｃ／１１６ｃ／１１７ｃをそれぞれ確立してもよい。ＷＣＤＭＡは、高速パケットアクセス（High-Speed Packet Access：ＨＳＰＡ）または発展型高速パケットアクセス（Evolved HSPA：ＨＳＰＡ＋）などの通信プロトコルを含んでいてもよい。ＨＳＰＡは、高速ダウンリンクパケットアクセス（High-Speed Downlink Packet Access：ＨＳＤＰＡ）または高速アップリンクパケットアクセス（High-Speed Uplink Packet Access：ＨＳＵＰＡ）を含んでもよい。
一実施例では、基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、または、ＲＡＮ１０３ｂ／１０４ｂ／１０５ｂにおけるＲＲＨ１１８ａ、１１８ｂ、ＴＲＰ１１９ａ、１１９ｂ、もしくはＲＳＵ１２０ａ、１２０ｂおよびＷＴＲＵ１０２ｃ、１０２ｄは、発展型ＵＭＴＳ地上無線アクセス（Evolved UMTS Terrestrial Radio Access：Ｅ−ＵＴＲＡ）などの無線技術を実装していてもよく、ロングタームエボリューション（Long Term Evolution：ＬＴＥ）またはＬＴＥアドバンスト（LTE-Advanced：ＬＴＥ−Ａ）を使用してエアインタフェース１１５／１１６／１１７または１１５ｃ／１１６ｃ／１１７ｃをそれぞれ確立してもよい。将来的には、エアインタフェース１１５／１１６／１１７または１１５ｃ／１１６ｃ／１１７ｃは、３ＧＰＰ ＮＲ技術を実装してもよい。ＬＴＥおよびＬＴＥ−Ａ技術は、ＬＴＥ Ｄ２ＤおよびＶ２Ｘ技術ならびにインタフェース（サイドリンク通信など）を含んでもよい。同様に、３ＧＰＰ ＮＲ技術は、ＮＲ Ｖ２Ｘ技術およびインタフェース（サイドリンク通信など）を含む。
ＲＡＮ１０３／１０４／１０５における基地局１１４ａならびにＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、および１０２ｇ、またはＲＡＮ１０３ｂ／１０４ｂ／１０５ｂにおけるＲＲＨ１１８ａ、１１８ｂ、ＴＲＰ１１９ａ、１１９ｂ、もしくはＲＳＵ１２０ａ、１２０ｂおよびＷＴＲＵ１０２ｃ、１０２ｄ、１０２ｅ、１０２ｆは、ＩＥＥＥ８０２．１６（例えば、ＷｉＭＡＸ（Worldwide Interoperability for Microwave Access））、ＣＤＭＡ２０００、ＣＤＭＡ２０００ １Ｘ、ＣＤＭＡ２０００ ＥＶ−ＤＯ、暫定標準２０００（Interim Standard 2000：ＩＳ−２０００）、暫定標準９５（Interim Standard 95：ＩＳ−９５）、暫定標準８５６（Interim Standard 856：ＩＳ−８５６）、ＧＳＭ（Global System for Mobile communication）（登録商標）、ＥＤＧＥ（Enhanced Data rates for GSM Evolution）、ＧＥＲＡＮ（GSM EDGE）などの無線技術を実装していてもよい。
図１２Ａの基地局１１４ｃは、例えば、無線ルータ、ホームノードＢ、ホームｅノードＢ、またはアクセスポイントであってもよく、本明細書に開示されているように、ＮＲ−Ｕ ＬＢＴ ＭＡＣ手順の方法、システム、およびデバイスを実装するために、事業所、家、車両、列車、空中、衛星、製造所、キャンパスなどの局所的なエリアで無線接続性を容易にするための任意の適切なＲＡＴを利用してもよい。一実施例では、基地局１１４ｃおよびＷＴＲＵ１０２、例えば、ＷＴＲＵ１０２ｅは、無線ローカルエリアネットワーク（Wireless Local Area Network：ＷＬＡＮ）を確立するために、ＩＥＥＥ８０２．１１などの無線技術を実装してもよい。同様に、基地局１１４ｃおよびＷＴＲＵ１０２ｄは、無線パーソナルエリアネットワーク（Wireless Personal Area Network：ＷＰＡＮ）を確立するために、ＩＥＥＥ８０２．１５などの無線技術を実装してもよい。さらに別の実施例では、基地局１１４ｃおよびＷＴＲＵ１０２、例えば、ＷＴＲＵ１０２ｅは、ピコセルまたはフェムトセルを確立するために、セルラーベースのＲＡＴ（例えば、ＷＣＤＭＡ、ＣＤＭＡ２０００、ＧＳＭ、ＬＴＥ、ＬＴＥ−Ａ、ＮＲなど）を利用してもよい。図１２Ａに示すように、基地局１１４ｃは、インターネット１１０への直接接続を有していてもよい。したがって、基地局１１４ｃは、コアネットワーク１０６／１０７／１０９を介してインターネット１１０にアクセスする必要がなくてもよい。
ＲＡＮ１０３／１０４／１０５またはＲＡＮ１０３ｂ／１０４ｂ／１０５ｂは、コアネットワーク１０６／１０７／１０９と通信していてもよく、このネットワークは、音声、データ、メッセージング、認可および認証、アプリケーション、またはボイスオーバーインターネットプロトコル（Voice Over Internet Protocol：ＶｏＩＰ）サービスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄの１つ以上に提供するように構成された任意のタイプのネットワークであってもよい。例えば、コアネットワーク１０６／１０７／１０９は、呼制御、課金サービス、モバイル位置ベースサービス、プリペイドコーリング、インターネット接続性、パケットデータネットワーク接続性、イーサネット（登録商標）接続性、ビデオ配信などを提供してもよく、ユーザ認証などの高レベルのセキュリティ機能を実行してもよい。
図１２Ａには示されていないが、ＲＡＮ１０３／１０４／１０５もしくはＲＡＮ１０３ｂ／１０４ｂ／１０５ｂまたはコアネットワーク１０６／１０７／１０９は、ＲＡＮ１０３／１０４／１０５もしくはＲＡＮ１０３ｂ／１０４ｂ／１０５ｂと同じＲＡＴまたは異なるＲＡＴを採用する他のＲＡＮと、直接的にまたは間接的に通信してもよいことが理解されるであろう。例えば、Ｅ−ＵＴＲＡ無線技術を利用し得るＲＡＮ１０３／１０４／１０５またはＲＡＮ１０３ｂ／１０４ｂ／１０５ｂに接続されていることに加えて、コアネットワーク１０６／１０７／１０９はまた、ＧＳＭまたはＮＲ無線技術を採用している別のＲＡＮ（図示せず）と通信していてもよい。
コアネットワーク１０６／１０７／１０９はまた、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄ、１０２ｅがＰＳＴＮ１０８、インターネット１１０、または他のネットワーク１１２にアクセスするためのゲートウェイとして機能してもよい。ＰＳＴＮ１０８は、一般電話サービス（Plain Old Telephone Service：ＰＯＴＳ）を提供する回線交換電話網を含んでもよい。インターネット１１０は、ＴＣＰ／ＩＰインターネットプロトコルスイートにおける伝送制御プロトコル（Transmission Control Protocol：ＴＣＰ）、ユーザデータグラムプロトコル（User Datagram Protocol：ＵＤＰ）、インターネットプロトコル（Internet Protocol：ＩＰ）などの共通の通信プロトコルを使用する、相互接続されたコンピュータネットワークおよびデバイスのグローバルシステムを含んでもよい。ネットワーク１１２は、他のサービスプロバイダによって所有もしくは運営される有線または無線の通信ネットワークを含んでもよい。例えば、ネットワーク１１２は、任意のタイプのパケットデータネットワーク（例えば、ＩＥＥＥ８０２．３イーサネットネットワーク）または１つ以上のＲＡＮに接続された別のコアネットワークを含んでもよく、これは、ＲＡＮ１０３／１０４／１０５もしくはＲＡＮ１０３ｂ／１０４ｂ／１０５ｂと同じＲＡＴまたは異なるＲＡＴを採用してもよい。
通信システム１００におけるＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄ、１０２ｅ、および１０２ｆの一部または全ては、マルチモード能力を含んでもよく、例えば、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄ、１０２ｅ、および１０２ｆは、本明細書に開示されているように、ＮＲ−Ｕ ＬＢＴ ＭＡＣ手順の方法、システム、およびデバイスを実装するために、異なる無線リンクを介して異なる無線ネットワークと通信するための複数のトランシーバを含んでもよい。例えば、図１２Ａに示すＷＴＲＵ１０２ｇは、セルラーベースの無線技術を採用し得る基地局１１４ａ、および、ＩＥＥＥ８０２の無線技術を採用し得る基地局１１４ｃと通信するように構成されてもよい。
図１２Ａには示されていないが、ユーザ機器は、ゲートウェイに有線接続を行ってもよいことが理解されるであろう。ゲートウェイは、レジデンシャルゲートウェイ（Residential Gateway：ＲＧ）であってもよい。ＲＧは、コアネットワーク１０６／１０７／１０９への接続性を提供してもよい。本明細書に含まれるアイデアの多くは、ＷＴＲＵであるＵＥ、および有線接続を使用してネットワークに接続するＵＥにも同様に適用され得ることが理解されるであろう。例えば、無線インタフェース１１５、１１６、１１７および１１５ｃ／１１６ｃ／１１７ｃに適用されるアイデアは、有線接続にも同様に適用され得る。
図１２Ｂは、本明細書に開示されているように、ＮＲ−Ｕ ＬＢＴ ＭＡＣ手順の方法、システム、およびデバイスを実装し得る例示的なＲＡＮ１０３およびコアネットワーク１０６のシステム図である。上記のとおり、ＲＡＮ１０３は、エアインタフェース１１５を介してＷＴＲＵ１０２ａ、１０２ｂ、および１０２ｃと通信するために、ＵＴＲＡ無線技術を採用してもよい。ＲＡＮ１０３はまた、コアネットワーク１０６と通信していてもよい。図１２Ｂに示すように、ＲＡＮ１０３は、ノードＢ１４０ａ、１４０ｂ、および１４０ｃを含んでもよく、これらはそれぞれ、エアインタフェース１１５を介してＷＴＲＵ１０２ａ、１０２ｂ、および１０２ｃと通信するための１つ以上のトランシーバを含んでもよい。ノードＢ１４０ａ、１４０ｂ、および１４０ｃはそれぞれ、ＲＡＮ１０３内の特定のセル（図示せず）に関連付けられてもよい。ＲＡＮ１０３はまた、ＲＮＣ１４２ａ、１４２ｂを含んでもよい。ＲＡＮ１０３は、任意の数のノードＢおよび無線ネットワークコントローラ（Radio Network Controller：ＲＮＣ）を含んでもよいことが理解されるであろう。
図１２Ｂに示すように、ノードＢ１４０ａ、１４０ｂは、ＲＮＣ１４２ａと通信してもよい。さらに、ノードＢ１４０ｃは、ＲＮＣ１４２ｂと通信していてもよい。ノードＢ１４０ａ、１４０ｂ、および１４０ｃは、Ｉｕｂインタフェースを介して、それぞれのＲＮＣ１４２ａ、１４２ｂと通信してもよい。ＲＮＣ１４２ａ、および１４２ｂは、Ｉｕｒインタフェースを介して互いに通信してもよい。ＲＮＣ１４２ａ、および１４２ｂのそれぞれは、それが接続されているそれぞれのノードＢ１４０ａ、１４０ｂ、および１４０ｃを制御するように構成されてもよい。さらに、ＲＮＣ１４２ａおよび１４２ｂのそれぞれは、アウターループ電力制御、負荷制御、受付制御、パケットスケジューリング、ハンドオーバー制御、マクロダイバシティ、セキュリティ機能、データ暗号化などの、他の機能性を実行またはサポートするように構成されてもよい。
図１２Ｂに示すコアネットワーク１０６は、メディアゲートウェイ（Media Gateway：ＭＧＷ）１４４、モバイルスイッチングセンター（Mobile Switching Center：ＭＳＣ）１４６、サービングＧＰＲＳサポートノード（Serving GPRS Support Node：ＳＧＳＮ）１４８、またはゲートウェイＧＰＲＳサポートノード（Gateway GPRS Support Node：ＧＧＳＮ）１５０を含んでもよい。前述の各要素は、コアネットワーク１０６の一部として図示されているが、これらの要素のいずれか１つは、コアネットワークオペレータ以外のエンティティによって所有または運営されてもよいことが理解されるであろう。
ＲＡＮ１０３内のＲＮＣ１４２ａは、ＩｕＣＳインタフェースを介して、コアネットワーク１０６内のＭＳＣ１４６に接続されてもよい。ＭＳＣ１４６は、ＭＧＷ１４４に接続されてもよい。ＭＳＣ１４６およびＭＧＷ１４４は、ＷＴＲＵ１０２ａ、１０２ｂ、および１０２ｃに、ＰＳＴＮ１０８などの回線交換ネットワークへのアクセスを提供して、ＷＴＲＵ１０２ａ、１０２ｂ、および１０２ｃと、従来の陸上線通信デバイスとの間の通信を容易にしてもよい。
ＲＡＮ１０３内のＲＮＣ１４２ａはまた、ＩｕＰＳインタフェースを介して、コアネットワーク１０６内のＳＧＳＮ１４８に接続されてもよい。ＳＧＳＮ１４８は、ＧＧＳＮ１５０に接続されてもよい。ＳＧＳＮ１４８およびＧＧＳＮ１５０は、ＷＴＲＵ１０２ａ、１０２ｂ、および１０２ｃに、インターネット１１０などのパケット交換ネットワークへのアクセスを提供して、ＷＴＲＵ１０２ａ、１０２ｂ、および１０２ｃと、ＩＰ対応デバイスとの間の通信を容易にしてもよい。
コアネットワーク１０６はまた、他のサービスプロバイダによって所有または運営される他の有線または無線ネットワークを含み得る、他のネットワーク１１２に接続されてもよい。
図１２Ｃは、本明細書に開示されているように、ＮＲ−Ｕ ＬＢＴ ＭＡＣ手順の方法、システム、および装置を実装し得る、例示的なＲＡＮ１０４およびコアネットワーク１０７のシステム図である。上記のとおり、ＲＡＮ１０４は、エアインタフェース１１６を介してＷＴＲＵ１０２ａ、１０２ｂ、および１０２ｃと通信するために、Ｅ−ＵＴＲＡ無線技術を採用してもよい。ＲＡＮ１０４はまた、コアネットワーク１０７と通信してもよい。
ＲＡＮ１０４は、ｅノードＢ１６０ａ、１６０ｂ、および１６０ｃを含んでもよいが、ＲＡＮ１０４は任意の数のｅノードＢを含んでもよいことが理解されるであろう。ｅノードＢ１６０ａ、１６０ｂ、および１６０ｃはそれぞれ、エアインタフェース１１６を介して、ＷＴＲＵ１０２ａ、１０２ｂ、および１０２ｃと通信するための１つ以上のトランシーバを含んでもよい。例えば、ｅノードＢ１６０ａ、１６０ｂ、および１６０ｃは、ＭＩＭＯ技術を実装してもよい。したがって、ｅノードＢ１６０ａは、例えば、複数のアンテナを使用して、ＷＴＲＵ１０２ａに無線信号を送信し、かつＷＴＲＵ１０２ａから無線信号を受信してもよい。
ｅノードＢ１６０ａ、１６０ｂ、および１６０ｃのそれぞれは、特定のセル（図示せず）に関連付けられてもよく、無線リソース管理決定、ハンドオーバー決定、アップリンクまたはダウンリンクにおけるユーザのスケジューリングなどを処理するように構成されてもよい。図１２Ｃに示すように、ｅノードＢ１６０ａ、１６０ｂ、および１６０ｃは、Ｘ２インタフェースを介して互いに通信してもよい。
図１２Ｃに示すコアネットワーク１０７は、モビリティ管理ゲートウェイ（Mobility Management Gateway：ＭＭＥ）１６２、サービングゲートウェイ１６４、およびパケットデータネットワーク（Packet Data Network：ＰＤＮ）ゲートウェイ１６６を含んでもよい。前述の各要素は、コアネットワーク１０７の一部として図示されているが、これらの要素のいずれか１つは、コアネットワークオペレータ以外のエンティティによって所有または運営されてもよいことが理解されるであろう。
ＭＭＥ１６２は、Ｓ１インタフェースを介して、ＲＡＮ１０４内のｅノードＢ１６０ａ、１６０ｂ、および１６０ｃのそれぞれに接続されてもよく、制御ノードとして機能してもよい。例えば、ＭＭＥ１６２は、ＷＴＲＵ１０２ａ、１０２ｂ、および１０２ｃのユーザの認証、ベアラのアクティブ化／非アクティブ化、ＷＴＲＵ１０２ａ、１０２ｂ、および１０２ｃの初期接続中の特定のサービングゲートウェイの選択などの役割を担ってもよい。ＭＭＥ１６２はまた、ＲＡＮ１０４と、ＧＳＭまたはＷＣＤＭＡなどの他の無線技術を採用した他のＲＡＮ（図示せず）とを切り替えるための、制御プレーン機能を提供してもよい。
サービングゲートウェイ１６４は、Ｓ１インタフェースを介して、ＲＡＮ１０４内のｅノードＢ１６０ａ、１６０ｂ、および１６０ｃのそれぞれに接続されてもよい。サービングゲートウェイ１６４は、一般に、ＷＴＲＵ１０２ａ、１０２ｂ、および１０２ｃとの間でユーザデータパケットをルーティングおよび転送してもよい。サービングゲートウェイ１６４はまた、ｅノードＢハンドオーバー中にユーザプレーンをアンカリングすること、ＷＴＲＵ１０２ａ、１０２ｂ、および１０２ｃでダウンリンクデータが利用可能な場合にページングをトリガすること、ＷＴＲＵ１０２ａ、１０２ｂ、および１０２ｃのコンテキストを管理ならびに保存することなど、他の機能を実行してもよい。
サービングゲートウェイ１６４はまた、ＰＤＮゲートウェイ１６６に接続されてもよく、これは、ＷＴＲＵ１０２ａ、１０２ｂ、および１０２ｃに、インターネット１１０などのパケット交換ネットワークへのアクセスを提供して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとＩＰ対応デバイスとの間の通信を容易にしてもよい。
コアネットワーク１０７は、他のネットワークとの通信を容易にしてもよい。例えば、コアネットワーク１０７は、ＷＴＲＵ１０２ａ、１０２ｂ、および１０２ｃに、ＰＳＴＮ１０８などの回線交換ネットワークへのアクセスを提供して、ＷＴＲＵ１０２ａ、１０２ｂ、および１０２ｃと、従来の陸上線通信デバイスとの間の通信を容易にしてもよい。例えば、コアネットワーク１０７は、コアネットワーク１０７とＰＳＴＮ１０８との間のインタフェースとして機能するＩＰゲートウェイ（例えば、ＩＰマルチメディアサブシステム（IP Multimedia Subsystem：ＩＭＳ）サーバ）を含んでいてもよく、またはそれと通信してもよい。さらに、コアネットワーク１０７は、ＷＴＲＵ１０２ａ、１０２ｂ、および１０２ｃに、他のサービスプロバイダによって所有または運営される他の有線または無線ネットワークを含み得るネットワーク１１２へのアクセスを提供してもよい。
図１２Ｄは、本明細書に開示されているように、ＮＲ−Ｕ ＬＢＴ ＭＡＣ手順の方法、システム、およびデバイスを実装し得る例示的なＲＡＮ１０５およびコアネットワーク１０９のシステム図である。ＲＡＮ１０５は、エアインタフェース１１７を介してＷＴＲＵ１０２ａおよび１０２ｂと通信するために、ＮＲ無線技術を採用してもよい。ＲＡＮ１０５はまた、コアネットワーク１０９と通信してもよい。非３ＧＰＰインターワーキング機能（Non-3GPP Interworking Function：Ｎ３ＩＷＦ）１９９は、エアインタフェース１９８を介してＷＴＲＵ１０２ｃと通信するために、非３ＧＰＰ無線技術を採用してもよい。Ｎ３ＩＷＦ１９９はまた、コアネットワーク１０９と通信してもよい。
ＲＡＮ１０５は、ｇノードＢ１８０ａおよび１８０ｂを含んでもよい。ＲＡＮ１０５は、任意の数のｇノードＢを含んでもよいことが理解されるであろう。ｇノードＢ１８０ａおよび１８０ｂはそれぞれ、エアインタフェース１１７を介してＷＴＲＵ１０２ａ、および１０２ｂと通信するための１つ以上のトランシーバを含んでもよい。統合されたアクセスおよびバックホール接続が使用される場合、ＷＴＲＵとｇノードＢとの間で同じエアインタフェースが使用されてもよく、これは、１つまたは複数のｇＮＢを介したコアネットワーク１０９であってもよい。ｇノードＢ１８０ａおよび１８０ｂは、ＭＩＭＯ、ＭＵ−ＭＩＭＯ、またはデジタルビームフォーミング技術を実装してもよい。したがって、ｇノードＢ１８０ａは、例えば、複数のアンテナを使用して、ＷＴＲＵ１０２ａに無線信号を送信し、かつＷＴＲＵ１０２ａから無線信号を受信してもよい。ＲＡＮ１０５は、ｅノードＢなどの他のタイプの基地局を採用してもよいことが理解されるべきである。また、ＲＡＮ１０５は、１つ以上のタイプの基地局を採用してもよいことが理解されるであろう。例えば、ＲＡＮは、ｅノードＢおよびｇノードＢを採用してもよい。
Ｎ３ＩＷＦ１９９は、非３ＧＰＰアクセスポイント１８０ｃを含んでもよい。Ｎ３ＩＷＦ１９９は、任意の数の非３ＧＰＰアクセスポイントを含んでもよいことが理解されるであろう。非３ＧＰＰアクセスポイント１８０ｃは、エアインタフェース１９８を介してＷＴＲＵ１０２ｃと通信するための１つ以上のトランシーバを含んでもよい。非３ＧＰＰアクセスポイント１８０ｃは、８０２．１１を使用して、エアインタフェース１９８を介してＷＴＲＵ１０２ｃと通信してもよい。
ｇノードＢ１８０ａおよび１８０ｂのそれぞれは、特定のセル（図示せず）に関連付けられてもよく、無線リソース管理決定、ハンドオーバー決定、アップリンクまたはダウンリンクにおけるユーザのスケジューリングなどを処理するように構成されてもよい。図１２Ｄに示すように、ｇノードＢ１８０ａ、および１８０ｂは、例えば、Ｘｎインタフェースを介して互いに通信してもよい。
図１２Ｄに示すコアネットワーク１０９は、５Ｇコアネットワーク（5G Core Network：５ＧＣ）であってもよい。コアネットワーク１０９は、無線アクセスネットワークによって相互に接続されている顧客に、多数の通信サービスを提供してもよい。コアネットワーク１０９は、コアネットワークの機能性を実行する多数のエンティティで構成される。本明細書で使用する場合、「コアネットワークエンティティ」または「ネットワーク機能」という用語は、コアネットワークの１つ以上の機能性を実行する任意のエンティティを意味する。そのようなコアネットワークエンティティは、図１２Ｇに例示されたシステム９０のなどの、無線もしくはネットワーク通信用に構成された装置またはコンピュータシステムのメモリに保存され、そのプロセッサ上で実行されるコンピュータ実行可能命令（ソフトウェア）の形態で実装される論理エンティティであってもよいことが理解される。
図１２Ｄの例では、５Ｇコアネットワーク１０９は、アクセスおよびモビリティ管理機能（Access and Mobility Management Function：ＡＭＦ）１７２、セッション管理機能（Session Management Function：ＳＭＦ）１７４、ユーザプレーン機能（User Plane Function：ＵＰＦ）１７６ａおよび１７６ｂ、ユーザデータ管理機能（User Data Management Function：ＵＤＭ）１９７、認証サーバ機能（Authentication Server Function：ＡＵＳＦ）１９０、ネットワーク露出機能（Network Exposure Function：ＮＥＦ）１９６、ポリシー制御機能（Policy Control Function：ＰＣＦ）１８４、非３ＧＰＰインターワーキング機能（Ｎ３ＩＷＦ）１９９、ユーザデータリポジトリ（User Data Repository：ＵＤＲ）１７８を含んでもよい。前述の各要素は、５Ｇコアネットワーク１０９の一部として図示されているが、これらの要素のいずれか１つは、コアネットワークオペレータ以外のエンティティによって所有または運営されてもよいことが理解されるであろう。また、５Ｇコアネットワークは、これらの要素の全てで構成されていなくてもよく、追加の要素で構成されていてもよく、これらの各要素の複数のインスタンスで構成されていてもよいことも理解されるであろう。図１２Ｄは、ネットワーク機能が互いに直接接続していることを示しているが、直径ルーティングエージェントまたはメッセージバスなどのルーティングエージェントを介して通信してもよいことが理解されるべきである。
図１２Ｄの例では、ネットワーク機能間の接続性は、一連のインタフェースまたは基準点を介して達成されている。ネットワーク機能は、他のネットワーク機能またはサービスによって呼び出される（ｉｎｖｏｋｅｄ）または呼び出される（ｃａｌｌｅｄ）サービスのセットとしてモデル化、記述、または実装され得ることが理解されるであろう。ネットワーク機能サービスの呼び出しは、ネットワーク機能間の直接接続、メッセージバスでのメッセージ交換、ソフトウェア機能の呼び出しなどを介して実現されてもよい。
ＡＭＦ１７２は、Ｎ２インタフェースを介してＲＡＮ１０５に接続されてもよく、制御ノードとして機能してもよい。例えば、ＡＭＦ１７２は、登録管理、接続管理、到達可能性管理、アクセス認証、アクセス承認の役割を担ってもよい。ＡＭＦは、ユーザプレーンのトンネル構成情報を、Ｎ２インタフェースを介してＲＡＮ１０５に転送する役割を担ってもよい。ＡＭＦ１７２は、Ｎ１１インタフェースを介して、ＳＭＦからユーザプレーンのトンネル構成情報を受信してもよい。ＡＭＦ１７２は、一般的に、Ｎ１インタフェースを介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとの間でＮＡＳパケットをルーティングして転送してもよい。Ｎ１インタフェースは、図１２Ｄには示されていない。
ＳＭＦ１７４は、Ｎ１１インタフェースを介して、ＡＭＦ１７２に接続されてもよい。同様に、ＳＭＦは、Ｎ７インタフェースを介してＰＣＦ１８４に、ならびにＮ４インタフェースを介してＵＰＦ１７６ａおよび１７６ｂに接続されてもよい。ＳＭＦ１７４は、制御ノードとして機能してもよい。例えば、ＳＭＦ１７４は、セッション管理、ＷＴＲＵ１０２ａ、１０２ｂ、および１０２ｃに対するＩＰアドレスの割り当て、ＵＰＦ１７６ａおよびＵＰＦ１７６ｂにおけるトラフィックステアリングルールの管理および設定、ならびに、ＡＭＦ１７２に対するダウンリンクデータ通知の生成の役割を担ってもよい。
ＵＰＦ１７６ａおよびＵＰＦ１７６ｂは、ＷＴＲＵ１０２ａ、１０２ｂ、および１０２ｃに、インターネット１１０などのパケットデータネットワーク（ＰＤＮ）へのアクセスを提供して、ＷＴＲＵ１０２ａ、１０２ｂ、および１０２ｃと他のデバイスとの間の通信を容易にしてもよい。ＵＰＦ１７６ａおよびＵＰＦ１７６ｂはまた、ＷＴＲＵ１０２ａ、１０２ｂ、および１０２ｃに、他のタイプのパケットデータネットワークへのアクセスを提供してもよい。例えば、他のネットワーク１１２は、イーサネットネットワークまたはデータのパケットを交換する任意のタイプのネットワークであってもよい。ＵＰＦ１７６ａおよびＵＰＦ１７６ｂは、Ｎ４インタフェースを介してＳＭＦ１７４からトラフィックステアリングルールを受信してもよい。ＵＰＦ１７６ａおよびＵＰＦ１７６ｂは、Ｎ６インタフェースでパケットデータネットワークを接続することによって、またはＮ９インタフェースで相互におよび他のＵＰＦと接続することによって、パケットデータネットワークへのアクセスを提供してもよい。パケットデータネットワークへのアクセスを提供することに加えて、ＵＰＦ１７６は、パケットのルーティングおよび転送、ポリシールールの施行、ユーザプレーンのトラフィックに対するサービス品質の処理、ダウンリンクパケットのバッファリングなどの役割を担ってもよい。
ＡＭＦ１７２はまた、例えば、Ｎ２インタフェースを介してＮ３ＩＷＦ１９９に接続されていてもよい。Ｎ３ＩＷＦは、例えば、３ＧＰＰで定義されていない無線インタフェース技術を介して、ＷＴＲＵ１０２ｃと５Ｇコアネットワーク１７０との間の接続を容易にする。ＡＭＦは、ＲＡＮ１０５と相互作用するのと同じか、または類似の方法で、Ｎ３ＩＷＦ１９９と相互作用してもよい。
ＰＣＦ１８４は、Ｎ７インタフェースを介してＳＭＦ１７４に接続され、Ｎ１５インタフェースを介してＡＭＦ１７２に接続され、Ｎ５インタフェースを介してアプリケーション機能（Application Function：ＡＦ）１８８に接続されてもよい。Ｎ１５およびＮ５インタフェースは、図１２Ｄには示されていない。ＰＣＦ１８４は、ＡＭＦ１７２およびＳＭＦ１７４などの制御プレーンノードにポリシールールを提供して、制御プレーンノードがこれらのルールを施行できるようにしてもよい。ＰＣＦ１８４は、ＡＭＦがＮ１インタフェースを介してＷＴＲＵ１０２ａ、１０２ｂ、および１０２ｃにポリシーを配信できるように、ＷＴＲＵ１０２ａ、１０２ｂ、および１０２ｃに対してＡＭＦ１７２にポリシーを送信してもよい。その後、ポリシーは、ＷＴＲＵ１０２ａ、１０２ｂ、および１０２ｃで施行されるか、または適用されてもよい。
ＵＤＲ１７８は、認証のクレデンシャルおよび加入情報のリポジトリとして機能してもよい。ＵＤＲは、ネットワーク機能がリポジトリ内のデータに追加し、そこから読み取り、修正することができるように、ネットワーク機能に接続してもよい。例えば、ＵＤＲ１７８は、Ｎ３６インタフェースを介してＰＣＦ１８４に接続してもよい。同様に、ＵＤＲ１７８は、Ｎ３７インタフェースを介してＮＥＦ１９６に接続してもよく、ＵＤＲ１７８は、Ｎ３５インタフェースを介してＵＤＭ１９７に接続してもよい。
ＵＤＭ１９７は、ＵＤＲ１７８と他のネットワーク機能との間のインタフェースとして機能してもよい。ＵＤＭ１９７は、ネットワーク機能にＵＤＲ１７８へのアクセスを許可してもよい。例えば、ＵＤＭ１９７は、Ｎ８インタフェースを介してＡＭＦ１７２に接続してもよく、ＵＤＭ１９７は、Ｎ１０インタフェースを介してＳＭＦ１７４に接続してもよい。同様に、ＵＤＭ１９７は、Ｎ１３インタフェースを介してＡＵＳＦ１９０に接続してもよい。ＵＤＲ１７８とＵＤＭ１９７は、緊密に統合されていてもよい。
ＡＵＳＦ１９０は、認証関連の動作を実行し、Ｎ１３インタフェースを介してＵＤＭ１７８に接続し、Ｎ１２インタフェースを介してＡＭＦ１７２に接続する。
ＮＥＦ１９６は、５Ｇコアネットワーク１０９内における能力およびサービスを、アプリケーション機能（ＡＦ）１８８に公開する。公開は、Ｎ３３ ＡＰＩインタフェース上で行われてもよい。ＮＥＦは、Ｎ３３インタフェースを介してＡＦ１８８に接続してもよく、５Ｇコアネットワーク１０９の能力およびサービスを公開するために、他のネットワーク機能に接続してもよい。
アプリケーション機能１８８は、５Ｇコアネットワーク１０９のネットワーク機能と相互作用してもよい。アプリケーション機能１８８とネットワーク機能との間の相互作用は、直接的なインタフェースを介していてもよく、またはＮＥＦ１９６を介して生じてもよい。アプリケーション機能１８８は、５Ｇコアネットワーク１０９の一部と見なされてもよく、または５Ｇコアネットワーク１０９の外部にあって、モバイルネットワーク事業者とビジネス関係を有する企業によって展開されてもよい。
ネットワークスライシングは、モバイルネットワーク事業者が、事業者のエアインタフェースの背後にある１つ以上の「仮想」コアネットワークをサポートするために使用できるメカニズムである。これは、コアネットワークを１つ以上の仮想ネットワークに「スライスシング」して、異なるＲＡＮまたは単一のＲＡＮにわたって実行される異なるサービスタイプをサポートすることと関連する。ネットワークスライシングにより、事業者は、機能性、性能、およびアイソレーションなどの多様な要件が求められる様々な市場のシナリオに最適なソリューションを提供するようにカスタマイズされたネットワークを作成することができる。
３ＧＰＰは、ネットワークスライシングをサポートするように５Ｇコアネットワークを設計している。ネットワークスライシングは、ネットワーク事業者が、非常に多様でときには極端な要件が求められる５Ｇの多様な一連のユースケース（例えば、マッシブＩｏＴ、クリティカルコミュニケーション、Ｖ２Ｘ、および拡張モバイルブロードバンド）をサポートするために使用できる優れたツールである。ネットワークスライシング技術を使用しないと、各ユースケースに固有の一連の性能、スケーラビリティ、および可用性の要件がある場合、ネットワークアーキテクチャは、より広い範囲のユースケースを効率的にサポートするのに十分に柔軟かつスケーラブルではない可能性がある。さらに、新しいネットワークサービスの導入がより効率的に行われるべきである。
再び図１２Ｄを参照すると、ネットワークスライシングシナリオでは、ＷＴＲＵ１０２ａ、１０２ｂ、または１０２ｃは、Ｎ１インタフェースを介して、ＡＭＦ１７２に接続してもよい。ＡＭＦは、論理的に１つ以上のスライスの一部であってもよい。ＡＭＦは、ＷＴＲＵ１０２ａ、１０２ｂ、もしくは１０２ｃの接続または通信を、１つ以上のＵＰＦ１７６ａおよび１７６ｂ、ＳＭＦ１７４、ならびに他のネットワーク機能と調和してもよい。ＵＰＦ１７６ａおよび１７６ｂ、ＳＭＦ１７４、ならびに他のネットワーク機能のそれぞれは、同じスライス、または異なるスライスの一部であってもよい。それらが異なるスライスの一部であるとき、それらは、異なるコンピューティングリソース、セキュリティクレデンシャルなどを利用することができるという意味で、互いに分離されていてもよい。
コアネットワーク１０９は、他のネットワークとの通信を容易にしてもよい。例えば、コアネットワーク１０９は、５Ｇコアネットワーク１０９とＰＳＴＮ１０８との間のインタフェースとして機能するＩＰマルチメディアサブシステム（ＩＭＳ）サーバなどのＩＰゲートウェイを含んでいてもよく、またはそれと通信してもよい。例えば、コアネットワーク１０９は、ショートメッセージサービスを介して通信を機能させるショートメッセージサービス（Short Message Service：ＳＭＳ）サービスセンターを含んでもよく、またはそれと通信してもよい。例えば、５Ｇコアネットワーク１０９は、ＷＴＲＵ１０２ａ、１０２ｂ、および１０２ｃと、サーバまたはアプリケーション機能１８８との間の非ＩＰデータパケットの交換を容易にしてもよい。さらに、コアネットワーク１７０は、ＷＴＲＵ１０２ａ、１０２ｂ、および１０２ｃに、他のサービスプロバイダによって所有または運営される他の有線または無線ネットワークを含み得るネットワーク１１２へのアクセスを提供してもよい。
本明細書に記載され、図１２Ａ、図１２Ｃ、図１２Ｄ、または図１２Ｅに示されているコアネットワークエンティティは、特定の既存の３ＧＰＰ仕様でそれらのエンティティに与えられた名前によって識別されているが、将来、それらのエンティティおよび機能性が他の名前で識別される可能性があり、特定のエンティティまたは機能が、将来の３ＧＰＰ ＮＲ仕様を含む、３ＧＰＰによって発行される将来の仕様と組み合わされ得ることが理解される。したがって、図１２Ａ、図１２Ｂ、図１２Ｃ、図１２Ｄ、または図１２Ｅで説明および示されている特定のネットワークエンティティおよび機能性は、例示としてのみ提供されており、本明細書で開示および請求されている主題は、現在定義されているかまたは将来定義されるかに関わらず、任意の類似の通信システムで具体化または実装され得ることが理解される。
図１２Ｅは、本明細書に記載されているように、ＮＲ−Ｕ ＬＢＴ ＭＡＣ手順を実装するシステム、方法、装置が使用され得る例示的な通信システム１１１を示す。通信システム１１１は、無線送受信ユニット（ＷＴＲＵ）Ａ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆ、基地局ｇＮＢ１２１、Ｖ２Ｘサーバ１２４、ならびに路側機（Road Side Unit：ＲＳＵ）１２３ａ、および１２３ｂを含んでもよい。実際には、本明細書に提示される概念は、任意の数のＷＴＲＵ、基地局ｇＮＢ、Ｖ２Ｘネットワーク、または他のネットワーク要素に適用し得る。１つまたはいくつかまたは全てのＷＴＲＵ Ａ、Ｂ、Ｃ、Ｄ、Ｅ、およびＦは、アクセスネットワークカバレッジ１３１の範囲外であってもよい。ＷＴＲＵ Ａ、Ｂ、およびＣは、Ｖ２Ｘグループを形成しており、そのうちＷＴＲＵ Ａはグループリードであり、ＷＴＲＵ ＢおよびＣはグループメンバである。
ＷＴＲＵ Ａ、Ｂ、Ｃ、Ｄ、Ｅ、およびＦは、それらがアクセスネットワークカバレッジ１３１内にある場合、ｇＮＢ１２１を介してＵｕインタフェース１２９で相互に通信してもよい。図１２Ｅの例では、ＷＴＲＵ ＢおよびＦがアクセスネットワークカバレッジ１３１内に示されている。ＷＴＲＵ Ａ、Ｂ、Ｃ、Ｄ、Ｅ、およびＦは、それらがアクセスネットワークカバレッジ１３１のもとにあるか、またはアクセスネットワークカバレッジ１３１の外にあるかに関わらず、インタフェース１２５ａ、１２５ｂ、または１２８などのスライドリンクインタフェース（例えば、ＰＣ５またはＮＲ ＰＣ５）を介して、互いに直接通信してもよい。例えば、図１２Ｅの例では、アクセスネットワークカバレッジ１３１の外にあるＷＲＴＵ Ｄは、カバレッジ１３１の中にあるＷＴＲＵ Ｆと通信する。
ＷＴＲＵ Ａ、Ｂ、Ｃ、Ｄ、Ｅ、およびＦは、車両対ネットワーク通信（Ｖ２Ｎ）１３３またはサイドリンククインタフェース１２５ｂを介して、ＲＳＵ１２３ａまたは１２３ｂと通信してもよい。ＷＴＲＵ Ａ、Ｂ、Ｃ、Ｄ、Ｅ、およびＦは、車両対インフラストラクチャ通信（Ｖ２Ｉ）インタフェース１２７を介してＶ２Ｘサーバ１２４と通信してもよい。ＷＴＲＵ Ａ、Ｂ、Ｃ、Ｄ、Ｅ、およびＦは、車両対歩行者通信（Ｖ２Ｐ）インタフェース１２８を介して、別のＵＥに通信してもよい。
図１２Ｆは、図１２Ａ、図１２Ｂ、図１２Ｃ、図１２Ｄ、もしくは図１２ＥのＷＴＲＵ１０２、または図１（例えば、ＵＥ１０１）など、本明細書に記載されているように、ＮＲ−Ｕ ＬＢＴ ＭＡＣ手順を実装するシステム、方法、および装置に従って、無線通信および動作のために構成され得る、例示的な装置またはデバイスＷＴＲＵ１０２のブロック図である。図１２Ｆに示すように、例示的なＷＴＲＵ１０２は、プロセッサ１１８、トランシーバ１２０、送受信素子１２２、スピーカ／マイクロフォン１２４、キーパッド１２６、ディスプレイ／タッチパッド／インジケータ１２８、非リムーバブルメモリ１３０、リムーバブルメモリ１３２、電源１３４、全地球測位システム（Global Positioning System：ＧＰＳ）チップセット１３６、および他の周辺機器１３８を含んでもよい。ＷＴＲＵ１０２は、前述の要素の任意のサブコンビネーションを含み得ることが理解されるであろう。また、基地局１１４ａおよび１１４ｂ、または基地局１１４ａおよび１１４ｂが表し得るノード、例えば、しかしこれらに限定されない、基地局装置（ＢＴＳ）、ノードＢ、サイトコントローラ、アクセスポイント（ＡＰ）、ホームノードＢ、発展型ノードＢ（ｅノードＢ）、ホーム発展型ノードＢ（ＨｅＮＢ）、ホーム発展型ノードＢゲートウェイ、次世代ノードＢ（ｇノードＢ）、ならびにプロキシノードなどは、特に、図１２Ｆに図示された要素の一部または全てを含んでもよく、本明細書に記載されているＮＲ−Ｕ ＬＢＴ ＭＡＣ手順の開示されたシステムおよび方法を実行する例示的な実装であってもよい。
プロセッサ１１８は、汎用プロセッサ、専用プロセッサ、従来のプロセッサ、デジタル信号プロセッサ（Digital Signal Processor：ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアに関連した１つ以上のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（Application Specific Integrated Circuit：ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（Field Programmable Gate Array：ＦＰＧＡ）回路、その他のタイプの集積回路（Integrated Circuit：ＩＣ）、ステートマシンなどであってもよい。プロセッサ１１８は、信号符号化、データ処理、電力制御、入出力処理、または、ＷＴＲＵ１０２が無線環境で動作することを可能にする任意の他の機能性を実行してもよい。プロセッサ１１８は、トランシーバ１２０に結合されてもよく、トランシーバは、送受信素子１２２に結合されてもよい。図１２Ｆは、プロセッサ１１８およびトランシーバ１２０を別個のコンポーネントとして図示しているが、プロセッサ１１８およびトランシーバ１２０は、電子パッケージまたはチップ内に共に統合されてもよいことが理解されるであろう。
ＵＥの送受信素子１２２は、エアインタフェース１１５／１１６／１１７を介して基地局（例えば、図１２Ａの基地局１１４ａ）との間で、またはエアインタフェース１１５ｄ／１１６ｄ／１１７ｄを介して別のＵＥとの間で、信号を送信もしくは受信するように構成されてもよい。例えば、送受信素子１２２は、ＲＦ信号を送信または受信するように構成されたアンテナであってもよい。送受信素子１２２は、例えば、ＩＲ、ＵＶ、もしくは可視光信号を送信または受信するように構成されたエミッタ／検出器であってもよい。送受信素子１２２は、ＲＦ信号および光信号の両方を送受信するように構成されてもよい。送受信素子１２２は、無線もしくは有線信号の任意の組み合わせを送信または受信するように構成されていてもよいことが理解されよう。
さらに、図１２Ｆでは送受信素子１２２が単一の素子として図示さているが、ＷＴＲＵ１０２は、任意の数の送受信素子１２２を含んでもよい。より具体的には、ＷＴＲＵ１０２は、ＭＩＭＯ技術を採用してもよい。したがって、ＷＴＲＵ１０２は、エアインタフェース１１５／１１６／１１７を介して無線信号を送受信するための２つ以上の送受信素子１２２（例えば、複数のアンテナ）を含んでもよい。
トランシーバ１２０は、送受信素子１２２によって送信されるべき信号を変調し、送受信素子１２２によって受信される信号を復調するように構成されてもよい。上記のとおり、ＷＴＲＵ１０２は、マルチモード能力を有していてもよい。したがって、トランシーバ１２０は、ＷＴＲＵ１０２が複数のＲＡＴ、例えば、ＮＲとＩＥＥＥ８０２．１１もしくはＮＲとＥ−ＵＴＲＡを介して通信する、または、異なるＲＲＨ、ＴＲＰ、ＲＳＵ、もしくはノードに複数のビームを介して同じＲＡＴで通信することを可能にするための、複数のトランシーバを含んでもよい。
ＷＴＲＵ１０２のプロセッサ１１８は、スピーカ／マイクロフォン１２４、キーパッド１２６、またはディスプレイ／タッチパッド／インジケータ１２８（例えば、液晶ディスプレイ（Liquid Crystal Display：ＬＣＤ）ディスプレイユニット、または有機発光ダイオード（Organic Light-Emitting Diode：ＯＬＥＤ）ディスプレイユニットに結合されていてもよく、これらからユーザ入力データを受信してもよい。プロセッサ１１８はまた、スピーカ／マイクロフォン１２４、キーパッド１２６、または、ディスプレイ／タッチパッド／インジケータ１２８にユーザデータを出力してもよい。さらに、プロセッサ１１８は、非リムーバブルメモリ１３０またはリムーバブルメモリ１３２など、任意のタイプの適切なメモリから情報にアクセスし、メモリにデータを保存してもよい。非リムーバブルメモリ１３０は、ランダムアクセスメモリ（Random-Access Memory：ＲＡＭ）、リードオンリーメモリ（Read-Only MemoryＲＯＭ）、ハードディスク、または任意の他のタイプのメモリストレージデバイスを含んでもよい。リムーバブルメモリ１３２は、加入者識別モジュール（Subscriber Identity Module:ＳＩＭ）カード、メモリスティック、セキュアデジタル（Secure Digital：ＳＤ）メモリカードなどを含んでいてもよい。プロセッサ１１８は、クラウドもしくはエッジコンピューティングプラットフォームでホストされているサーバまたはホームコンピュータ（図示せず）上などで、ＷＴＲＵ１０２に物理的に配置されていないメモリから情報にアクセスし、データを保存してもよい。プロセッサ１１８は、本明細書に記載されているいくつかの実施例におけるＬＢＴ ＦＣのセットアップが成功したかまたは不成功なのかに応じて、ディスプレイもしくはインジケータ１２８上の照明パターン、画像、または色を制御するように構成されてもよく、または別の方法でＮＲ−Ｕ ＬＢＴ ＭＡＣ手順および関連するコンポーネントの状態を示すように構成されてもよい。ディスプレイもしくはインジケータ１２８上の制御照明パターン、画像、または色は、本明細書で示されている、もしくは記載されている図（例えば、図１〜図１０など）における方法フローまたはコンポーネントのいずれかの状態を反映していてもよい。本明細書には、ＮＲ−Ｕ ＬＢＴ ＭＡＣ手順のメッセージおよび手順が開示されている。メッセージおよび手順は、ユーザが、入力ソース（例えば、スピーカ／マイクロフォン１２４、キーパッド１２６、またはディスプレイ／タッチパッド／インジケータ１２８）を介してリソースを要求し、ディスプレイ１２８に表示され得る他のもののうち、ＮＲ−Ｕ ＬＢＴ ＭＡＣ手順関連情報を要求、設定、または照会するためのインタフェース／ＡＰＩを提供するように拡張されてもよい。
プロセッサ１１８は、電源１３４から電力を受け取り、ＷＴＲＵ１０２内の他のコンポーネントに電力を分配または制御するように構成されてもよい。電源１３４は、ＷＴＲＵ１０２に電力を供給するための任意の適切なデバイスであってもよい。例えば、電源１３４は、１つ以上の乾電池、太陽電池、燃料電池などを含んでもよい。
また、プロセッサ１１８は、ＧＰＳチップセット１３６に結合されてもよく、ＧＰＳチップセット１３６は、ＷＴＲＵ１０２の現在位置に関する位置情報（例えば、経度および緯度）を提供するように構成されてもよい。ＧＰＳチップセット１３６からの情報に加えて、またはそれの代わりに、ＷＴＲＵ１０２は、基地局（例えば、基地局１１４ａ、１１４ｂ）からエアインタフェース１１５／１１６／１１７を介して位置情報を受信してもよく、または２つ以上の近くの基地局から受信されている信号のタイミングに基づいてその位置を判定してもよい。ＷＴＲＵ１０２は、任意の適切な位置判定方法によって、位置情報を取得してもよいことが理解されるであろう。
プロセッサ１１８は、さらに、他の周辺機器１３８に結合されてもよく、これらの周辺機器１３８は、追加の特徴、機能性、または有線もしくは無線の接続性を提供する１つ以上のソフトウェアまたはハードウェアモジュールを含んでもよい。例えば、周辺機器１３８は、加速度計などの様々なセンサ、バイオメトリクス（例えば、指紋）センサ、電子コンパス、衛星トランシーバ、デジタルカメラ（写真またはビデオ用）、ユニバーサルシリアルバス（Universal Serial Bus：ＵＳＢ）ポートまたは他の相互接続インタフェース、振動デバイス、テレビトランシーバ、ハンズフリーヘッドセット、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール、周波数変調（Frequency Modulated：ＦＭ）無線ユニット、デジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザなどを含んでもよい。
ＷＴＲＵ１０２は、センサ、家電製品、スマートウォッチまたはスマートウェアなどのウェアラブルデバイス、医療または電子ヘルスデバイス、ロボット、産業機器、ドローン、自動車、トラック、電車、または飛行機などの車両など、他の装置またはデバイス内に含まれていてもよい。ＷＴＲＵ１０２は、周辺機器１３８の１つを構成し得る相互接続インタフェースなど、１つ以上の相互接続インタフェースを介して、そのような装置もしくはデバイスの他のコンポーネント、モジュール、またはシステムに接続してもよい。
図１２Ｇは、例示的なコンピューティングシステム９０のブロック図であり、これは、図１２Ａ、図１２Ｃ、図１２Ｄ、および図１２Ｅに示される通信ネットワークの１つ以上の装置、ならびに、図１から図１０に示され、本明細書において説明および請求されるシステムおよび方法などのＮＲ−Ｕ ＬＢＴ ＭＡＣ手順が、ＲＡＮ１０３／１０４／１０５、コアネットワーク１０６／１０７／１０９、ＰＳＴＮ１０８、インターネット１１０、その他のネットワーク１１２、もしくはネットワークサービス１１３における特定のノードまたは機能エンティティなどで具現化され得る。コンピューティングシステム９０は、コンピュータまたはサーバで構成され、主にコンピュータ可読命令によって制御されてもよく、コンピュータ可読命令は、ソフトウェアの形態であってもよく、またはそのようなソフトウェアがどこに保存されていても、もしくはどのような手段でアクセスされてもよい。このようなコンピュータ可読命令は、プロセッサ９１内で実行されて、コンピューティングシステム９０に動作をさせてもよい。プロセッサ９１は、汎用プロセッサ、専用プロセッサ、従来のプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアに関連した１つ以上のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、その他のタイプの集積回路（ＩＣ）、ステートマシンなどであってもよい。プロセッサ９１は、信号符号化、データ処理、電力制御、入出力処理、または、ＷＴＲＵ９０が電気通信ネットワークで動作することを可能にする任意の他の機能性を実行してもよい。コプロセッサ８１は、メインプロセッサ９１とは異なるオプションのプロセッサであり、追加の機能を実行、またはプロセッサ９１を支援し得る。プロセッサ９１またはコプロセッサ８１は、ＬＢＴ失敗の受信または反応など、ＮＲ−Ｕ ＬＢＴ ＭＡＣ手順のために本明細書に開示された方法および装置に関連するデータを受信、生成、ならびに処理してもよい。
動作時、プロセッサ９１は、命令をフェッチ、復号、および実行し、コンピューティングシステムの主なデータ転送パスであるシステムバス８０を介して、他のリソースとの間で情報を転送する。このようなシステムバスは、コンピューティングシステム９０内のコンポーネントを接続し、データ交換のための媒体を定義する。システムバス８０は、典型的には、データを送るためのデータライン、アドレスを送るためのアドレスライン、ならびに、割り込みを送るため、およびシステムバスを動作するための制御ラインを含む。このようなシステムバス８０の一例は、ペリフェラルコンポーネントインターコネクト（Peripheral Component Interconnect：ＰＣＩ）バスである。
システムバス８０に結合されたメモリは、ランダムアクセスメモリ（Random Access Memory：ＲＡＭ）８２および読み出し専用メモリ（Read Only Memory：ＲＯＭ）９３を含む。このようなメモリは、情報を保存して取り出すことができる回路を含む。ＲＯＭ９３は、一般に、容易に変更できない保存データを含む。ＲＡＭ８２に保存されたデータは、プロセッサ９１もしくは他のハードウェアデバイスによって読み取られ得るか、または変更され得る。ＲＡＭ８２またはＲＯＭ９３へのアクセスは、メモリコントローラ９２によって制御されてもよい。メモリコントローラ９２は、命令が実行される際に、仮想アドレスを物理アドレスに変換するアドレス変換機能を提供してもよい。メモリコントローラ９２はまた、システム内のプロセスを分離し、ユーザプロセスからシステムプロセスを分離するメモリ保護機能を提供してもよい。したがって、第１のモードで実行されるプログラムは、そのプロセスの仮想アドレス空間によってマッピングされたメモリのみにアクセスし得、プロセス間のメモリ共有が設定されていない限り、他のプロセスの仮想アドレス空間内のメモリにアクセスすることはできない。
さらに、コンピューティングシステム９０は、プロセッサ９１からの命令をプリンタ９４、キーボード８４、マウス９５、およびディスクドライブ８５などの周辺機器に通信するための役割を担う周辺機器コントローラ８３を含んでいてもよい。
ディスプレイコントローラ９６によって制御されるディスプレイ８６は、コンピューティングシステム９０によって生成された視覚的出力を表示するために使用される。このような視覚的出力は、テキスト、グラフィックス、アニメーショングラフィックス、およびビデオを含んでもよい。視覚的出力は、グラフィカルユーザインタフェース（Graphical User Interface：ＧＵＩ）の形態で提供されてもよい。ディスプレイ８６は、ＣＲＴベースのビデオディスプレイ、ＬＣＤベースのフラットパネルディスプレイ、ガスプラズマベースのフラットパネルディスプレイ、またはタッチパネルで実装されてもよい。ディスプレイコントローラ９６は、ディスプレイ８６に送信されるビデオ信号を生成するために必要な電子コンポーネントを含む。
さらに、コンピューティングシステム９０は、図１２Ａ、図１２Ｂ、図１２Ｃ、図１２Ｄ、もしくは図１２Ｅの、ＲＡＮ１０３／１０４／１０５、コアネットワーク１０６／１０７／１０９、ＰＳＴＮ１０８、インターネット１１０、ＷＴＲＵ１０２、またはその他のネットワーク１１２などの、外部通信ネットワークまたはデバイスに、コンピューティングシステム９０を接続するために使用され、コンピューティングシステム９０がそれらのネットワークの他のノードまたは機能エンティティと通信できるようにし得る、例えば無線または有線ネットワークアダプタ９７などの通信回路を含んでいてもよい。通信回路は、単独で、またはプロセッサ９１と組み合わせて、本明細書に記載されている特定の装置、ノード、または機能エンティティの送受信ステップを実行するために使用されてもよい。
本明細書に記載されている装置、システム、方法、およびプロセスのいずれかまたは全てが、コンピュータ可読記憶媒体に保存されたコンピュータ実行可能命令（例えば、プログラムコード）の形態で具現化されてもよく、この命令は、プロセッサ１１８または９１などのプロセッサによって実行されると、プロセッサに、本明細書に記載されたシステム、方法、およびプロセスを実行または実施させることが理解される。具体的には、本明細書に記載されているステップ、動作、または機能のいずれかは、無線または有線のネットワーク通信のために構成された装置またはコンピューティングシステムのプロセッサ上で実行される、そのようなコンピュータ実行可能命令の形態で実装されてもよい。コンピュータ可読記憶媒体は、情報を保存するための任意の非一時的（例えば、有形もしくは物理的）な方法または技術で実装された揮発性および不揮発性、取り外し可能および取り外し不可能な媒体を含むが、そのようなコンピュータ可読記憶媒体には信号は含まれない。コンピュータ可読記憶媒体には、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリもしくは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（Digital Versatile Disk：ＤＶＤ）もしくは他の光ディスクストレージ、磁気カセット、磁気テープ、磁気ディスクストレージもしくは他の磁気ストレージデバイス、または、所望の情報を保存するために使用され、コンピューティングシステムによってアクセスされ得る他の有形もしくは物理的媒体が含まれるが、これらに限定されない。
本開示の主題であるＮＲ−Ｕ ＬＢＴ ＭＡＣ手順の好ましい方法、システム、または装置を図に示すように説明する際、明確にするために特定の用語が採用されている。しかし、請求項に記載された主題は、そのように選択された特定の用語に限定されることを意図しておらず、各特定の要素は、同様の目的を達成するために同様の方法で動作する全ての技術的等価物を含むことを理解すべきである。
本明細書に記載されている様々な技術は、ハードウェア、ファームウェア、ソフトウェア、または必要に応じて、それらの組み合わせに関連して実装されてもよい。このようなハードウェア、ファームウェア、およびソフトウェアは、通信ネットワークの様々なノードに配置された装置に常駐してもよい。装置は、本明細書に記載されている方法を実現するために、単独で、または互いに組み合わせて動作してもよい。本本発明で使用する場合、「装置」、「ネットワーク装置」、「ノード」、「デバイス」、「ネットワークノード」などの用語が互換的に使用され得る。さらに、「または」という言葉の使用は、本明細書で別段の定めがない限り、一般的に包括的に使用される。
この書面による明細書では、最良のモードを含む本発明を開示するために例を使用しており、また、任意のデバイスまたはシステムを作成および使用し、任意の組み込まれた方法を実行することを含めて、当業者が本発明を実施できるようにする。特許を受けることができる範囲は、特許請求の範囲によって定義され、当業者が想到する他の実施例（例えば、本明細書に開示された例示的な方法の間でステップをスキップすること、ステップを組み合わせること、または、ステップを追加すること）を含み得る。このような他の実施例は、特許請求の範囲の文字通りの言語とは異なることのない構造要素を有する場合、または特許請求の範囲の文字通りの言語とは実質的に異なる同等の構造要素を含む場合、特許請求の範囲に含まれることが意図される。
この書面による明細書では、最良のモードを含む主題を開示するために例を使用しており、また、任意のデバイスまたはシステムを作成および使用し、任意の組み込まれた方法を実行することを含めて、当業者が主題を実施できるようにする。特許を受けることができる範囲は、特許請求の範囲によって定義され、例えば、当業者が想到する他の実施例（例えば、特に図２〜図１０など、本明細書に開示された例示的な方法の間でステップをスキップすること、ステップを組み合わせること、または、ステップを追加すること）を含み得る。このような他の実施例は、特許請求の範囲の文字通りの言語とは異なることのない構造要素を有する場合、または特許請求の範囲の文字通りの言語とは実質的に異なる同等の構造要素を含む場合、特許請求の範囲に含まれることが意図される。
本明細書に記載されている方法、システム、および装置などは、とりわけ、手段ＮＲ−Ｕ ＬＢＴ ＭＡＣ手順を提供してもよい。ＳＲ手順のＬＢＴ失敗により、１）代替ＢＷＰへの切り替え、２）ＲＡ手順の開始、または、３）ＳＲ保留状態の維持につながり得る。ＤＲＸ手順のＬＢＴ失敗により、１）オンデュレーションまたは非アクティブタイマの延長、２）オンデュレーションまたは非アクティブタイマの、ＭＣＯＴ、ＣＷＳ、またはＣＣＡへの整合、または、３）ショートサイクルの適用、のいずれかにつながり得る。ＲＡ手順のＬＢＴ失敗により、１）統計報告を生成することもしくは送信すること、または、２）禁止タイマを設定すること、につながり得る。ＢＷＰ手順のＬＢＴ失敗により、１）ＢＷＰ非アクティブタイマを延長すること、または、２）代替ＢＷＰへ切り替えること、につながり得る。このパラグラフおよび次のパラグラフ（または本明細書の関連したパラグラフ）の全ての組み合わせ（ステップの削除または追加を含む）が意図されている。
方法、システム、および装置は、とりわけ、本明細書に記載されているように、手段ＮＲ−Ｕ ＬＢＴ ＭＡＣ手順を提供してもよい。方法、システム、コンピュータ可読記憶媒体、または装置は、とりわけ、ランダムアクセス手順、ＳＣｅｌｌアクティブ化／非アクティブ化手順、間欠受信手順、スケジューリング要求手順、バッファステータス報告手順、論理チャネル優先順位付け手順、ＵＥとＮＢのＭＡＣ手順の調整、パワーヘッドルーム報告手順、または帯域幅部分動作手順に関して、ＬＢＴ失敗を判定する手段を有する。方法、システム、コンピュータ可読記憶媒体、または装置は、プリアンブル送信カウンタが１より大きく、パワーランピングカウンタの一時停止の通知が下位層から受信されておらず、選択されたＳＳＢが変更されず、ＬＢＴ失敗が検出されていないことを判定する手段、および、判定ステップに基づいて、プリアンブルパワーランピングカウンタを１だけインクリメントする命令を提供する手段を有する。方法、システム、コンピュータ可読記憶媒体、または装置は、ユーザ機器（ＵＥ）に関連付けられたＬＢＴ状態の表示を取得すること（例えば、リモートデバイスから受信すること、またはローカルセンサを使用して検出すること）、およびＬＢＴ報告ＭＡＣ制御要素（ＬＢＴＲ ＭＡＣ ＣＥ）を生成することを含み得る、リッスンビフォートーク（ＬＢＴ）およびメディアアクセス制御（ＭＡＣ）に関連付けられた動作のための手段を有し、ＬＢＴＲ ＭＡＣ ＣＥは、ＬＢＴ状態の表示を含み得る。方法、システム、コンピュータ可読記憶媒体、または装置は、ＬＢＴタイミング情報をＭＡＣ層に提供する手段を有する。ＬＢＴタイミング情報は、クリアチャネル評価の期間、最大チャネル占有時間、またはコンテンションウィンドウを含んでもよい。方法、システム、コンピュータ可読記憶媒体、または装置は、ユーザ機器（ＵＥ）に関連付けられたＬＢＴ失敗の第１の閾値またはＬＢＴ成功の第２の閾値を検出することと、第１の閾値または第２の閾値の検出に基づいて、ＤＲＸ設定を調整することとを含み得る、リッスンビフォートーク（ＬＢＴ）および間欠受信（ＤＲＸ）に関連付けられた動作のための手段を有する。ＤＲＸ設定は、オンデュレーションまたは非アクティブタイマを含んでもよい。本発明の方法、システム、コンピュータ可読記憶媒体、または装置は、基地局がＵＥに情報を提供する手段を有し、情報は、基地局またはＵＥに関連付けられたアクセスチャネルに関するダウンリンク情報を含み得る。ＵＥは、アップリンク情報に関する情報を自動的に検出してもよい。アップリンク情報またはダウンリンク情報に基づいて、ＵＥは異なるＭＡＣ手順を行ってもよい。一実施例では、ＵＥは、アップリンク情報およびダウンリンク情報を使用して、ＬＢＴ失敗を報告するか否か、またはどの手順が影響を受けるかを報告するか否かを判定してもよい。方法、システム、コンピュータ可読記憶媒体、または装置は、基地局によって検出されたダウンリンク情報を取得し、ダウンリンク情報は、基地局のチャネルアクセスに関連付けられ、ダウンリンクのリッスンビフォートーク失敗の表示を含み得、アップリンク情報を取得し、アップリンク情報は、装置によって検出され、アップリンク情報は、装置のチャネルアクセスに関連付けられ、アップリンクのリッスンビフォートーク失敗の表示を含み得、および、アップリンクのリッスンビフォートーク失敗の表示またはダウンリンクのリッスンビフォートーク失敗の表示に基づいて、メディアアクセス制御動作を実行する、手段を有する。アップリンクのリッスンビフォートーク失敗（もしくは成功）、またはダウンリンクのリッスンビフォートーク失敗（もしくは成功）は、スケジューリング要求手順、バッファステータス報告手順、論理チャネル優先順位付け手順、間欠受信手順、ＳＣｅｌｌアクティブ化もしくは非アクティブ化手順、パワーヘッドルーム報告手順、ランダムアクセス手順、リッスンビフォートーク報告手順、または帯域幅部分動作手順によって検出され得る。このパラグラフおよび次のパラグラフ（または本明細書の関連したパラグラフ）の全ての組み合わせ（ステップの削除または追加を含む）が意図されている。
方法、システム、コンピュータ可読記憶媒体、または装置は、ＭＡＣ手順を管理する手段を有する。方法、システム、コンピュータ可読記憶媒体、または装置は、ダウンリンク情報を取得する手段を有し、ダウンリンク情報は、基地局の（装置への）チャネルアクセスに関連付けられ、アップリンク情報（例えば、ユーザ機器）を取得する手段を有し、アップリンク情報は、装置による（例えば、基地局への）チャネルアクセスに関連付けられ、アップリンク情報またはダウンリンク情報に基づいて、メディアアクセス制御動作を実行する。ダウンリンク情報は、基地局によって検出されてもよい。アップリンク情報は、装置によって検出されてもよい。チャネルアクセス情報は、リッスンビフォートーク動作に関連する情報であってもよい。メディアアクセス制御動作の実行は、帯域幅部分の非アクティブタイマを延長することを含んでもよく、アップリンクまたはダウンリンク情報は、アップリンクまたはダウンリンクのリッスンビフォートーク失敗情報を含む。ＵＬまたはＤＬのＬＢＴ失敗情報時に、ＢＷＰを切り替えることがあってもよい（ＢＷＰ動作ＭＡＣ手順とは独立しており、切り替えは事前に設定された代替ＢＷＰへの切り替えであってもよい）。メディアアクセス制御動作の実行は、ランダムアクセス応答ウィンドウを延長することを含んでもよく、アップリンクまたはダウンリンク情報は、アップリンクまたはダウンリンクのリッスンビフォートーク失敗情報を含む。メディアアクセス制御動作の実行は、プリアンブル送信カウンタをインクリメントしないこと、または競合解決タイマを延長することを含んでもよく、アップリンクまたはダウンリンク情報は、アップリンクまたはダウンリンクのリッスンビフォートーク失敗情報を含む。メディアアクセス制御動作の実行は、パワーランピングを維持することまたは減少させることを含んでもよく、アップリンクまたはダウンリンク情報は、アップリンクまたはダウンリンクのリッスンビフォートーク失敗情報を含む。開示された主題は、ＬＢＴ失敗によるＲＡ手順の停止を回避し得る。さらに、プリアンブル送信ＬＢＴ失敗閾値を超えると、上位層にＲＡ問題が示され、ＲＡ手順が不成功であると見なされ得る。メディアアクセス制御動作の実行は、リッスンビフォートーク失敗または成功があるか否かを判定することに基づいて、物理アップリンク制御チャネルリソースが有効であると判定することを含んでもよく、これは、ＳＲ手順がＬＢＴ失敗閾値に到達してＰＵＣＣＨリソースを解放することに関連付けられてもよい。ＣＣＡ、ＭＣＯＴ、またはＣＷＳ情報は、ＬＢＴ成功情報と共に提供されてもよい。また、このＣＣＡ、ＭＣＯＴ、またはＣＷＳ情報を含むＬＢＴ成功は、成功の認識は失敗がなかったことを意味するため、ＬＢＴ失敗表示と同等であり得る。ＬＢＴが参照される場合、ＬＢＴ成功表示によって判定され得る。ＤＲＸにおいては、ＬＢＴ失敗時にショートサイクルの適用またはアクティブタイムの延長でカバーしてもよい。さらに、インアクティビティタイマを再起動するときに、ＬＢＴの失敗がアクティブタイムを延長する回数に制限がある場合がある。さらに、ＬＢＴ失敗時にＤＲＸの設定を調整する。これは、オンデュレーション、インアクティビティ、またはＤＲＸサイクルタイマに関連付けられ得る。ＬＢＴＲについては、ＬＢＴの失敗または成功時に、ＬＢＴの成功または失敗が既知の期間にわたって閾値を超えた場合に、基地局への報告がトリガされ、報告が送信された後、報告の頻度を制限するために禁止タイマが設定され、報告にはＣＣＡ、ＭＣＯＴ、またはＣＷＳなどのタイミング情報が含まれ得る。ＬＢＴが既知の閾値に達したことによるＳＲ失敗により、ＲＡ手順が開始される（例えば、ＬＢＴ失敗によりＳＲ送信カウンタがインクリメントされない回数を制限することにより達成される）、ＬＢＴ失敗時にＳＲ禁止タイマが設定されない、またはＬＢＴ失敗時にＳＲ保留が維持され得る。メディアアクセス制御動作の実行は、スケジューリング要求送信のリッスンビフォートーク失敗表示に基づいて、スケジューリング要求失敗を判定すること、またはランダムアクセス手順を開始することを含んでもよい。メディアアクセス制御動作の実行は、スケジューリング要求送信のリッスンビフォートーク失敗表示に基づいて、スケジューリング要求の失敗を判定すること、または帯域幅部分を切り替えることが含まれてもよい。メディアアクセス制御動作の実行は、装置のＭＡＣ手順タイマもしくはカウンタを拡張すること、ＭＡＣ手順がアップリンクもしくはダウンリンクチャネルアクセスによって達成されるときの動作に影響を与え、ライセンス動作と同様の性能を可能にすること、または装置がチャネルアクセス情報を基地局に報告することを含んでもよい。このパラグラフおよび次のパラグラフ（または本明細書の関連したパラグラフ）の全ての組み合わせ（ステップの削除または追加を含む）が意図されている。
方法、システム、コンピュータ可読記憶媒体、または装置は、ＭＡＣ手順を管理する手段を有する。方法、システム、コンピュータ可読記憶媒体、または装置は、基地局からダウンリンク情報を取得する手段を有し、ダウンリンク情報は、装置のチャネルアクセスに関連付けられ、アップリンク情報を取得し、アップリンク情報は、装置によって検出され、アップリンク情報またはダウンリンク情報に基づいて、メディアアクセス制御動作を実行する、手段を有する。メディアアクセス制御動作の実行は、帯域幅部分の非アクティブタイマを延長することを含んでもよく、アップリンクまたはダウンリンク情報は、アップリンクまたはダウンリンクのリッスンビフォートーク失敗情報を含んでもよい。メディアアクセス制御動作の実行は、ランダムアクセス応答ウィンドウを延長することを含んでもよく、アップリンクまたはダウンリンク情報は、アップリンクまたはダウンリンクのリッスンビフォートーク失敗情報を含んでもよい。メディアアクセス制御動作の実行は、プリアンブル送信カウンタをインクリメントすること、または競合解決タイマを延長することを含んでもよく、アップリンクまたはダウンリンク情報は、アップリンクまたはダウンリンクのリッスンビフォートーク失敗情報を含んでもよい。メディアアクセス制御動作の実行は、パワーランピングを維持すること、または減少させること(例えば、増加させないこと)を含んでもよく、アップリンクまたはダウンリンク情報は、アップリンクまたはダウンリンクのリッスンビフォートーク失敗情報を含んでもよい。メディアアクセス制御動作の実行は、リッスンビフォートーク失敗または失敗成功（例えば、閾値成功または失敗によってトリガされる）があるか否かを判定することに基づいて、物理アップリンク制御チャネル(ＰＵＣＣＨ)リソースが有効であると判定することを含んでもよい。メディアアクセス制御動作の実行は、間欠受信動作を調整することを含んでもよく、アップリンクまたはダウンリンク情報は、間欠受信サイクルで基地局からシグナリングされる、クリアチャネル評価期間、最大チャネル占有時間、またはダウンリンクリッスンビフォートーク成功指示を含んでもよい。メディアアクセス制御動作を実行することは、間欠受信動作において、最大チャネル占有時間期間と整合するようにアクティブタイムを調整すること、およびコンテンションウィンドウサイズ期間またはクリアチャネル評価期間中に間欠受信を適用すること含んでもよい。最大チャネル占有時間の期間との整合は、オンデュレーションタイマを調整すること、または非アクティブタイマを調整することを含んでもよい。メディアアクセス制御動作を実行することは、アップリンクまたはダウンリンク情報の影響を受けるメディアアクセス制御動作を報告することを含んでもよい。メディアアクセス制御動作の実行は、アップリンクまたはダウンリンク情報によって影響を受けるメディアアクセス制御動作を報告することを含んでもよく、アップリンクまたはダウンリンク情報は、アップリンクまたはダウンリンクのリッスンビフォートーク失敗情報を含んでもよい。メディアアクセス制御動作の実行は、メディアアクセス制御動作のうちの１つ以上が、アップリンクまたはダウンリンク情報によってどのように影響されるかを報告することを含んでもよい。メディアアクセス制御動作の実行は、メディアアクセス制御動作のうちの１つ以上が、アップリンクまたはダウンリンク情報によってどのように影響されるかを報告することを含んでもよく、アップリンクまたはダウンリンク情報は、アップリンクまたはダウンリンクのリッスンビフォートーク失敗情報を含んでもよい。一般に、ＬＢＴの失敗または成功などのアップリンクまたはダウンリンク情報は、とりわけ、本明細書に開示されているようなＭＡＣ動作をトリガし得る。装置は、ユーザ機器であってもよい。このパラグラフ（または本明細書の関連したパラグラフ）の全ての組み合わせ（ステップの削除または追加を含む）が意図されている。

Claims (15)

  1. 装置であって、
    プロセッサと、
    前記プロセッサに結合されたメモリと、を備え、前記メモリは、前記プロセッサによって実行されると、前記プロセッサに動作を実現させる実行可能な命令を保存し、前記動作は、
    ダウンリンク情報を取得することであって、前記ダウンリンク情報は、基地局によって検出され、前記ダウンリンク情報は、前記基地局のチャネルアクセスに関連付けられ、ダウンリンクのリッスンビフォートーク失敗の表示を含む、ことと、
    アップリンク情報を取得することであって、前記アップリンク情報は、前記装置によって検出され、前記アップリンク情報は、前記装置のチャネルアクセスに関連付けられ、アップリンクリッスンビフォートーク失敗の表示を含む、ことと、
    前記アップリンクのリッスンビフォートーク失敗の表示または前記ダウンリンクのリッスンビフォートーク失敗の表示に基づいて、メディアアクセス制御動作を実行することと、
    を含む、装置。
  2. 前記メディアアクセス制御動作の実行は、スケジューリング要求手順のために、代替帯域幅部分に切り替えることを含む、請求項１に記載の装置。
  3. 前記メディアアクセス制御動作の実行は、スケジューリング要求手順のために、ランダムアクセス手順を開始することを含む、請求項１に記載の装置。
  4. 前記メディアアクセス制御動作の実行は、スケジューリング要求手順のために、スケジューリング要求を保留状態に維持することを含む、請求項１に記載の装置。
  5. 前記メディアアクセス制御動作の実行は、間欠受信手順のために、オンデュレーションまたは非アクティブタイマを延長することを含む、請求項１に記載の装置。
  6. 前記メディアアクセス制御動作の実行は、間欠受信手順のために、オンデュレーションまたは非アクティブタイマを、クリアチャネル評価、最大チャネル占有時間、またはコンテンションウィンドウサイズに整合することを含む、請求項１に記載の装置。
  7. 前記メディアアクセス制御動作の実行は、間欠受信手順のために、ショートサイクルタイマを適用することを含む、請求項１に記載の装置。
  8. 前記メディアアクセス制御動作の実行は、ランダムアクセス手順のために、代替帯域幅部分に切り替えることを含む、請求項１に記載の装置。
  9. 前記メディアアクセス制御動作の実行は、ランダムアクセス手順のために、
    上位層にランダムアクセス問題表示を提供することと、
    前記ランダムアクセス手順が不成功であると表示することと、
    を含む、請求項１に記載の装置。
  10. 前記メディアアクセス制御動作の実行は、リッスンビフォートーク報告手順のために、リッスンビフォートーク失敗または成功の統計を含む報告を提供することを含む、請求項１に記載の装置。
  11. 前記メディアアクセス制御動作の実行は、リッスンビフォートーク報告手順のために、報告の頻度を設定するための禁止タイマを設定することを含む、請求項１に記載の装置。
  12. 前記メディアアクセス制御動作の実行は、帯域幅部分手順のために、帯域幅部分非アクティブタイマを延長すること、または代替帯域幅部分に切り替えることを含む、請求項１に記載の装置。
  13. ダウンリンク情報を取得することであって、前記ダウンリンク情報は、基地局によって検出され、前記ダウンリンク情報は、前記基地局のチャネルアクセスに関連付けられ、ダウンリンクのリッスンビフォートーク失敗の表示を含む、ことと、
    アップリンク情報を取得することであって、前記アップリンク情報は、装置によって検出され、前記アップリンク情報は、前記装置のチャネルアクセスに関連付けられ、アップリンクのリッスンビフォートークク失敗の表示を含む、ことと、
    前記アップリンクのリッスンビフォートーク失敗の表示または前記ダウンリンクのリッスンビフォートーク失敗の表示に基づいて、メディアアクセス制御動作を実行することと、
    を含む、方法。
  14. 前記アップリンクのリッスンビフォートーク失敗または前記ダウンリンクのリッスンビフォートーク失敗は、スケジューリング要求手順、バッファステータス報告手順、論理チャネル優先順位付け手順、間欠受信手順、ＳＣｅｌｌアクティブ化もしくは非アクティブ化手順、パワーヘッドルーム報告手順、ランダムアクセス手順、リッスンビフォートーク報告手順、または帯域幅部分動作手順によって検出される、請求項１３に記載の方法。
  15. コンピュータ可読記憶媒体上に保存されたコンピュータプログラムを有する前記コンピュータ可読記憶媒体であって、前記コンピュータプログラムは、データ処理ユニットにロード可能であり、前記コンピュータプログラムが前記データ処理ユニットによって実行されたときに、請求項１３から１４のいずれか一項に記載の方法ステップを前記データ処理ユニットに実行させるように適合されている、コンピュータ可読記憶媒体。
JP2021517410A 2018-09-26 2019-09-26 Ｎｒ－ｕ ｌｂｔ ｍａｃ手順 Active JP7455820B2 (ja)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201862736816P 2018-09-26 2018-09-26
US62/736,816 2018-09-26
US201862753579P 2018-10-31 2018-10-31
US62/753,579 2018-10-31
PCT/US2019/053135 WO2020069114A1 (en) 2018-09-26 2019-09-26 Nr-u lbt mac procedures

Publications (3)

Publication Number Publication Date
JP2022501946A true JP2022501946A (ja) 2022-01-06
JPWO2020069114A5 JPWO2020069114A5 (ja) 2022-09-20
JP7455820B2 JP7455820B2 (ja) 2024-03-26

Family

ID=68172284

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2021517410A Active JP7455820B2 (ja) 2018-09-26 2019-09-26 Ｎｒ－ｕ ｌｂｔ ｍａｃ手順

Country Status (6)

Country Link
US (1) US20220039016A1 (ja)
EP (1) EP3841823A1 (ja)
JP (1) JP7455820B2 (ja)
KR (1) KR20210064295A (ja)
CN (1) CN112753275A (ja)
WO (1) WO2020069114A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11817971B2 (en) 2015-11-04 2023-11-14 Futurewei Technologies, Inc. System and method for VNF termination management

Families Citing this family (37)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020033395A1 (en) * 2018-08-06 2020-02-13 Babaei Alireza Cell and bandwidth part operations in unlicensed bands
EP3857954B1 (en) * 2018-09-26 2023-06-21 Telefonaktiebolaget LM Ericsson (publ) Wireless channel switching
US11070328B2 (en) * 2018-09-27 2021-07-20 Ofinno, Llc Bandwidth parts operation in multiple active bandwidth parts
CA3060845A1 (en) * 2018-11-01 2020-05-01 Comcast Cable Communications, Llc Beam failure recovery in carrier aggregation
CN109565869B (zh) * 2018-11-14 2022-08-05 北京小米移动软件有限公司 调度请求发送方法和装置
SG11202105717VA (en) * 2018-12-28 2021-07-29 Zte Corp Methods, apparatus and systems for indicating transmission failures in a wireless communication
US20200221309A1 (en) * 2019-01-07 2020-07-09 Qualcomm Incorporated Handling of channel access problems
CN118055466A (zh) 2019-01-09 2024-05-17 汉尼拔Ip有限责任公司 用于lbt失败检测的方法和设备
WO2020152530A1 (en) * 2019-01-23 2020-07-30 Lenovo (Singpore) Pte. Ltd. Autonomous bandwidth part switching
US20220110153A1 (en) * 2019-02-13 2022-04-07 Nokia Technologies Oy Bandwidth part switching due to lbt failure
US10869336B2 (en) * 2019-02-15 2020-12-15 Qualcomm Incorporated Random access channel access and validity procedures
CN114145070A (zh) * 2019-05-01 2022-03-04 苹果公司 处理在未许可频谱上运行的新无线电（nr）系统的上行链路先听后说（lbt）故障的装置和方法
WO2020222696A2 (en) * 2019-05-02 2020-11-05 Telefonaktiebolaget Lm Ericsson (Publ) Wireless device, network node, and methods performed thereby, for handling a random access procedure
US11558899B2 (en) * 2019-08-15 2023-01-17 Industrial Technology Research Institute Method and user equipment of performing resource switching in unlicensed spectrum
US11627605B2 (en) * 2019-08-21 2023-04-11 Lenovo (Singapore) Pte. Ltd. Transmitting a TB after successful LBT procedure
CN112584479B (zh) * 2019-09-27 2022-08-02 维沃移动通信有限公司 功率余量报告处理方法、终端及网络设备
KR20220113356A (ko) * 2019-09-30 2022-08-12 콤캐스트 케이블 커뮤니케이션스 엘엘씨 통신 채널 장애 검출 및 복구
US10979128B1 (en) * 2019-12-07 2021-04-13 PanPsy Technologies, LLC Beam failure and consistent listen before talk failure recovery
US11368979B2 (en) * 2020-01-30 2022-06-21 Qualcomm Incorporated Synchronous channel access based on adaptive channel occupancy time management
EP3869890B1 (en) * 2020-02-21 2023-12-13 Nokia Technologies Oy Enhanced scheduling request handling procedure
EP4133889A1 (en) * 2020-04-09 2023-02-15 Telefonaktiebolaget LM ERICSSON (PUBL) Listen-before-talk failure in a wireless communication network
EP4140243A1 (en) * 2020-04-20 2023-03-01 Telefonaktiebolaget LM Ericsson (publ) Handling scell deactivation for unlicensed operation
WO2021215679A1 (en) * 2020-04-20 2021-10-28 Lg Electronics Inc. Method and apparatus for performing lbt procedures by ue in wireless communication system
JP7480867B2 (ja) * 2020-05-18 2024-05-10 日本電気株式会社 通信装置、及び方法
WO2022014860A1 (ko) * 2020-07-16 2022-01-20 엘지전자 주식회사 전력 절약 모드를 기반으로 통신을 수행하는 방법 및 장치
WO2022087202A2 (en) 2020-10-21 2022-04-28 Ofinno, Llc Reliable transmission of multicast and broadcast services
US11711814B2 (en) * 2020-11-06 2023-07-25 Qualcomm Incorporated Listen-before-talk reporting for sidelink channels
US20230397241A1 (en) * 2020-11-06 2023-12-07 Nokia Technologies Oy Delay information
US11490419B2 (en) * 2020-11-06 2022-11-01 Qualcomm Incorporated Contention window updates with integrated access and backhaul nodes for unlicensed operations
US11778655B2 (en) * 2020-11-16 2023-10-03 Qualcomm Incorporated Techniques for configuring multiple frequency domain opportunities for sidelink feedback
EP4124161B1 (en) * 2021-01-15 2024-05-08 ASUSTek Computer Inc. Method and apparatus for controlling unintended bandwidth part, bwp, swtiching in a wireless communication system
US20220417990A1 (en) * 2021-03-31 2022-12-29 Apple Inc. Improved Secondary Cell Activation Mechanism in the New Radio Unlicensed Spectrum
JP7460856B2 (ja) 2021-07-12 2024-04-02 京セラ株式会社 通信制御方法
US20230015997A1 (en) * 2021-07-19 2023-01-19 Qualcomm Incorporated Techniques for listen-before-talk failure reporting for multiple transmission time intervals
CN114938710A (zh) * 2022-03-28 2022-08-23 北京小米移动软件有限公司 侧行链路sidelink通信方法及装置
WO2023211214A1 (ko) * 2022-04-27 2023-11-02 엘지전자 주식회사 무선 통신 시스템에서 사이드링크 통신을 수행하는 방법 및 장치
WO2024019528A1 (ko) * 2022-07-19 2024-01-25 엘지전자 주식회사 Lbt와 관련된 무선 통신을 수행하는 방법 및 장치

Family Cites Families (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6388780B2 (ja) * 2014-03-19 2018-09-12 株式会社Ｎｔｔドコモ ユーザ端末、無線基地局及び無線通信方法
US10136452B2 (en) * 2015-02-24 2018-11-20 Qualcomm Incorporated Enhanced PRACH for standalone contention based communications including unlicensed spectrum
US10051617B2 (en) * 2015-03-17 2018-08-14 Motorola Mobility Llc Method and apparatus for scheduling user equipment uplink transmissions on an unlicensed carrier
US10159108B2 (en) * 2015-04-10 2018-12-18 Motorola Mobility Llc DRX handling in LTE license assisted access operation
US10251197B2 (en) * 2015-07-23 2019-04-02 Qualcomm Incorporated Transmitting uplink control channel information when a clear channel assessment of an unlicensed carrier fails
US10034305B2 (en) * 2015-11-12 2018-07-24 Qualcomm Incorporated LBT interface for logical DTX
CN108476532A (zh) * 2016-02-02 2018-08-31 英特尔Ip公司 随机接入过程期间的先听后说(lbt)失败
KR102443134B1 (ko) * 2016-03-29 2022-09-14 주식회사 아이티엘 비면허 대역 지원 상향링크 전송 방법 및 장치
WO2017196086A1 (en) * 2016-05-12 2017-11-16 Samsung Electronics Co., Ltd. Method and apparatus for assigning uplink resource for cellular network using unlicensed bands
CN107371273B (zh) * 2016-05-13 2023-05-30 中兴通讯股份有限公司 随机接入方法、装置及用户设备
EP4346116A3 (en) * 2016-06-15 2024-05-08 InterDigital Patent Holdings, Inc. Random access procedures in next generation networks
US20180124831A1 (en) * 2016-10-29 2018-05-03 Ofinno Technologies, Llc Dual connectivity scheduling request for wireless network and wireless device
US10681738B2 (en) * 2016-12-16 2020-06-09 Ofinno, Llc Random access in a wireless device and wireless network
US11317402B2 (en) * 2017-06-26 2022-04-26 Samsung Electronics Co., Ltd. Method for generating preamble, method for configuring preamble and equipment thereof, random access method, device, user equipment and base station
US10993283B2 (en) * 2018-04-06 2021-04-27 Apple Inc. Enhancements on random access for NR-unlicensed
EP3780838A4 (en) * 2018-04-25 2021-12-15 Beijing Xiaomi Mobile Software Co., Ltd. METHOD AND DEVICE FOR DISPLAYING THE OCCUPATION OF A SEMI-PERSISTENT PLANNING UNIT AND BASE STATION
US11013036B2 (en) * 2018-06-14 2021-05-18 Samsung Electronics Co., Ltd. Method and apparatus on enhancements of NR random access for unlicensed operations
US11956822B2 (en) * 2018-06-19 2024-04-09 Interdigital Patent Holdings, Inc. Radio link monitoring in shared spectrum
US11202320B2 (en) * 2018-09-05 2021-12-14 Samsung Electronics Co., Ltd. Method and apparatus of performing random access on unlicensed carrier

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11817971B2 (en) 2015-11-04 2023-11-14 Futurewei Technologies, Inc. System and method for VNF termination management

Also Published As

Publication number Publication date
US20220039016A1 (en) 2022-02-03
JP7455820B2 (ja) 2024-03-26
WO2020069114A1 (en) 2020-04-02
KR20210064295A (ko) 2021-06-02
EP3841823A1 (en) 2021-06-30
CN112753275A (zh) 2021-05-04

Similar Documents

Publication Publication Date Title
JP7455820B2 (ja) Ｎｒ－ｕ ｌｂｔ ｍａｃ手順
US11246147B2 (en) Scheduling requests, status reports, and logical channel prioritization
US20220295589A1 (en) Beam failure detection and recovery with multi-trp and multi-panel transmission
JP7299916B2 (ja) 新無線アンライセンスセルを用いるランダムアクセス
US20220399927A1 (en) Link recovery and sidelink beamforming
JP7431229B2 (ja) 障害のないセルでのビーム障害回復
US20220191962A1 (en) Rlm and rlf procedures for nr v2x
US20200145921A1 (en) Wake up signals operation
WO2017218847A1 (en) Grant-less operations
EP3991471B1 (en) Apparatus, system, method and computer-readable medium for performing beam failure recovery
US20220369225A1 (en) Ue power savings in multi-beam operation
EP4133825A1 (en) Sidelink enhancements - resource allocation simultaneous mode 1/mode 2
JP2023502936A (ja) マルチｓｉｍ ｕｅ接続モード動作のための方法
US20240172325A1 (en) Method and apparatuses for nr sidelink discontinuous reception
WO2023091959A1 (en) Method and apparatus for radio sidelink operation over shared spectrum
WO2023091963A1 (en) Methods and systems for nr sidelink resource allocation over shared spectrum
WO2024035937A1 (en) Coordinated handover for a group of wtrus using xr and media applications
WO2022212699A9 (en) Activation/de-activation mechanism for one scg and scells, and conditional pscell change/addition

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20210716

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20220909

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20220909

A711 Notification of change in applicant

Free format text: JAPANESE INTERMEDIATE CODE: A711

Effective date: 20221108

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20230814

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20230822

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20231122

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20240213

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20240313

R150 Certificate of patent or registration of utility model

Ref document number: 7455820

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150