特開 2024-95668 ＮＲ－Ｕ ＬＢＴ ＭＡＣ手順

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2024095668

(43)【公開日】2024-07-10

(54)【発明の名称】ＮＲ－Ｕ ＬＢＴ ＭＡＣ手順

(51)【国際特許分類】

   H04W 72/54 20230101AFI20240703BHJP

   H04W 74/08 20240101ALI20240703BHJP

   H04W 72/0453 20230101ALI20240703BHJP

   H04W 72/21 20230101ALI20240703BHJP

【ＦＩ】

H04W72/54 110

H04W74/08

H04W72/0453

H04W72/21

【審査請求】有

【請求項の数】16

【出願形態】ＯＬ

【外国語出願】

(21)【出願番号】P 2024039342

(22)【出願日】2024-03-13

(62)【分割の表示】P 2021517410の分割

【原出願日】2019-09-26

(31)【優先権主張番号】62/753,579

(32)【優先日】2018-10-31

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】62/736,816

(32)【優先日】2018-09-26

(33)【優先権主張国・地域又は機関】US

【公序良俗違反の表示】

（特許庁注：以下のものは登録商標）

１．３ＧＰＰ

(71)【出願人】

【識別番号】510030995

【氏名又は名称】インターデイジタル パテント ホールディングス インコーポレイテッド

(74)【代理人】

【識別番号】110002147

【氏名又は名称】弁理士法人酒井国際特許事務所

(72)【発明者】

【氏名】テリー，ステファン，イー．

(72)【発明者】

【氏名】アジャクプレ，パスカル，エム．

(72)【発明者】

【氏名】マリー，ジョセフ，エム．

(72)【発明者】

【氏名】リ，チン

(72)【発明者】

【氏名】アイヤー，ラクシュミ，アール．

(72)【発明者】

【氏名】ジャン，グオドン

【テーマコード（参考）】

5K067

【Ｆターム（参考）】

5K067EE02

5K067EE10

5K067HH22

(57)【要約】      （修正有）

【課題】アンライセンス周波数で動作し、既存のトラフィックに干渉せずチャネルへのアクセスを得るためにリッスンビフォートーク（ＬＢＴ）の手順を有し、ＭＡＣ手順の適切な動作及び性能を維持するのに役立つ、既存のＭＡＣ手順に関連付けられた方法、装置及びシステムを提供する。
【解決手段】帯域幅部分（ＢＷＰ）動作手順であって、１つ以上のＬＢＴ失敗を検出し、検出した失敗に基づいて、スケジュールすべきＵＬ又はＤＬデータが存在するとき、初期またはデフォルトＢＷＰへの切り替えが回避されるように、ＢＷＰ非アクティブタイマを延長し、検出した失敗に基づいて、代替帯域幅部分に切り替える。
【選択図】図２

【特許請求の範囲】

【請求項1】

装置であって、
プロセッサと、
前記プロセッサに結合されたメモリと、を備え、前記メモリは、前記プロセッサによっ
て実行されると、前記プロセッサに動作を実現させる実行可能な命令を保存し、前記動作
は、
ダウンリンク情報を取得することであって、前記ダウンリンク情報は、基地局によって
検出され、前記ダウンリンク情報は、前記基地局のチャネルアクセスに関連付けられ、ダ
ウンリンクのリッスンビフォートーク失敗の表示を含む、ことと、
アップリンク情報を取得することであって、前記アップリンク情報は、前記装置によっ
て検出され、前記アップリンク情報は、前記装置のチャネルアクセスに関連付けられ、ア
ップリンクリッスンビフォートーク失敗の表示を含む、ことと、
前記アップリンクのリッスンビフォートーク失敗の表示または前記ダウンリンクのリッ
スンビフォートーク失敗の表示に基づいて、メディアアクセス制御動作を実行することと
、
を含む、装置。

【請求項2】

前記メディアアクセス制御動作の実行は、スケジューリング要求手順のために、代替帯
域幅部分に切り替えることを含む、請求項１に記載の装置。

【請求項3】

前記メディアアクセス制御動作の実行は、スケジューリング要求手順のために、ランダ
ムアクセス手順を開始することを含む、請求項１に記載の装置。

【請求項4】

前記メディアアクセス制御動作の実行は、スケジューリング要求手順のために、スケジ
ューリング要求を保留状態に維持することを含む、請求項１に記載の装置。

【請求項5】

前記メディアアクセス制御動作の実行は、間欠受信手順のために、オンデュレーション
または非アクティブタイマを延長することを含む、請求項１に記載の装置。

【請求項6】

前記メディアアクセス制御動作の実行は、間欠受信手順のために、オンデュレーション
または非アクティブタイマを、クリアチャネル評価、最大チャネル占有時間、またはコン
テンションウィンドウサイズに整合することを含む、請求項１に記載の装置。

【請求項7】

前記メディアアクセス制御動作の実行は、間欠受信手順のために、ショートサイクルタ
イマを適用することを含む、請求項１に記載の装置。

【請求項8】

前記メディアアクセス制御動作の実行は、ランダムアクセス手順のために、代替帯域幅
部分に切り替えることを含む、請求項１に記載の装置。

【請求項9】

前記メディアアクセス制御動作の実行は、ランダムアクセス手順のために、
上位層にランダムアクセス問題表示を提供することと、
前記ランダムアクセス手順が不成功であると表示することと、
を含む、請求項１に記載の装置。

【請求項10】

前記メディアアクセス制御動作の実行は、リッスンビフォートーク報告手順のために、
リッスンビフォートーク失敗または成功の統計を含む報告を提供することを含む、請求項
１に記載の装置。

【請求項11】

前記メディアアクセス制御動作の実行は、リッスンビフォートーク報告手順のために、
報告の頻度を設定するための禁止タイマを設定することを含む、請求項１に記載の装置。

【請求項12】

前記メディアアクセス制御動作の実行は、帯域幅部分手順のために、帯域幅部分非アク
ティブタイマを延長すること、または代替帯域幅部分に切り替えることを含む、請求項１
に記載の装置。

【請求項13】

ダウンリンク情報を取得することであって、前記ダウンリンク情報は、基地局によって
検出され、前記ダウンリンク情報は、前記基地局のチャネルアクセスに関連付けられ、ダ
ウンリンクのリッスンビフォートーク失敗の表示を含む、ことと、
アップリンク情報を取得することであって、前記アップリンク情報は、装置によって検
出され、前記アップリンク情報は、前記装置のチャネルアクセスに関連付けられ、アップ
リンクのリッスンビフォートークク失敗の表示を含む、ことと、
前記アップリンクのリッスンビフォートーク失敗の表示または前記ダウンリンクのリッ
スンビフォートーク失敗の表示に基づいて、メディアアクセス制御動作を実行することと
、
を含む、方法。

【請求項14】

前記アップリンクのリッスンビフォートーク失敗または前記ダウンリンクのリッスンビ
フォートーク失敗は、スケジューリング要求手順、バッファステータス報告手順、論理チ
ャネル優先順位付け手順、間欠受信手順、ＳＣｅｌｌアクティブ化もしくは非アクティブ
化手順、パワーヘッドルーム報告手順、ランダムアクセス手順、リッスンビフォートーク
報告手順、または帯域幅部分動作手順によって検出される、請求項１３に記載の方法。

【請求項15】

コンピュータ可読記憶媒体上に保存されたコンピュータプログラムを有する前記コンピ
ュータ可読記憶媒体であって、前記コンピュータプログラムは、データ処理ユニットにロ
ード可能であり、前記コンピュータプログラムが前記データ処理ユニットによって実行さ
れたときに、請求項１３から１４のいずれか一項に記載の方法ステップを前記データ処理
ユニットに実行させるように適合されている、コンピュータ可読記憶媒体。

【発明の詳細な説明】

【技術分野】

【0001】

（関連出願の相互参照）
本出願は、２０１８年９月２６日に出願された「ＮＲ－Ｕ ＬＢＴ ＭＡＣ Ｐｒｏｃ
ｅｄｕｒｅｓ」と題する米国仮特許出願第６２／７３６，８１６号および２０１８年１０
月３１日に出願された「ＮＲ－Ｕ ＬＢＴ ＭＡＣ Ｐｒｏｃｅｄｕｒｅｓ」と題する米
国仮特許出願第６２／７５３，５７９号の利益を主張するものであり、両出願の内容は参
照により本明細書に援用される。

【背景技術】

【0002】

ＬＴＥライセンスアシストアクセス３ＧＰＰリリース１６ ＮＲは、以前のリリースで
利用可能であったライセンスアシスト接続を使用しないアンライセンス動作をサポートす
る。以前のリリースでは、常にライセンス接続が存在したため、アンライセンス接続で高
レベルのＱｏＳを確保する必要がなかった。

【0003】

アンライセンスで動作するには、既存のトラフィックに干渉せず、チャネルへのアクセ
スを得るために、リッスンビフォートーク（Listen Before Talk：ＬＢＴ）の手順が必
要である。

【0004】

アンライセンス周波数帯で動作する少なくとも１つのＳＣｅｌｌを有するキャリアアグ
リゲーションは、ライセンスアシストアクセス（Licensed-Assisted Access：ＬＡＡ）
と呼ばれる。したがって、ＬＡＡでは、ＵＥのために設定されたサービングセルのセット
は、フレーム構成タイプ３に従ってアンライセンス周波数帯で動作する少なくとも１つの
ＳＣｅｌｌを常に含み、これはＬＡＡ ＳＣｅｌｌとも呼ばれる。特に指定がない限り、
ＬＡＡ ＳＣｅｌｌは規則的なＳＣｅｌｌとして機能する。

【0005】

ＬＡＡ ｅＮＢおよびＵＥは、ＬＡＡ ＳＣｅｌｌで送信を実行する前にリッスンビフ
ォートーク（ＬＢＴ）を適用する。ＬＢＴが適用されると、送信機はチャネルをリッスン
／感知して、チャネルがフリーまたはビジーかを判定する。チャネルがフリーであると判
定された場合、送信機は、送信を行ってもよく、さもなければ、送信を行わない。ＬＡＡ
ｅＮＢがＬＡＡチャネルアクセスの目的で他のテクノロジーのチャネルアクセス信号を
使用する場合、３ＧＰＰ ＴＳ ３６．３２１（Ｅ－ＵＴＲＡ）、メディアアクセス制御
（Medium Access Control：ＭＡＣ）プロトコル仕様、Ｖ１５．２．０［１］のＬＡＡ
最大エネルギ検出閾値要件を引き続き満たすものとする。さらなるコンテキストは、３Ｇ
ＰＰ ＴＳ ３６．３２１、（Ｅ－ＵＴＲＡ）、メディアアクセス制御（ＭＡＣ）プロト
コル仕様、Ｖ１５．２．０に含まれ得る。

【発明の概要】

【0006】

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

【0007】

この発明の概要は、以下の発明を実施するための形態でさらに記載される簡略化された
形式で概念の選択を紹介するために提供される。この発明の概要は、請求項に記載された
主題の主要な特徴または本質的な特徴を特定することを意図したものではなく、また、請
求項に記載された主題の範囲を制限するために使用することを意図したものでもない。さ
らに、請求項に記載された主題は、本開示のいずれかの部分に記載された何らかのまたは
全ての不利益を解決する制限に制約されない。

【0008】

より詳細な理解は、添付図面に関連した例を介して与えられた以下の説明から得られ得
る。

【図面の簡単な説明】

【0009】

【図1】図１は、ＮＲ－Ｕ ＬＢＴ ＭＡＣ手順のための例示的なシステムを示す。

【図2】図２は、ＮＲ－Ｕ ＬＢＴ ＭＡＣ手順に関連付けられた例示的な方法を示す。

【図3】図３は、ＮＲ－Ｕ ＬＢＴ ＭＡＣ手順に関連付けられた例示的な方法を示す。

【図4】図４は、ＮＲ－Ｕ ＬＢＴ ＭＡＣ手順に関連付けられた例示的な方法を示す。

【図5】図５は、ＮＲ－Ｕ ＬＢＴ ＭＡＣ手順に関連付けられた例示的な方法を示す。

【図6】図６は、ＮＲ－Ｕ ＬＢＴ ＭＡＣ手順に関連付けられた例示的な方法を示す。

【図7】図７は、ＮＲ－Ｕ ＬＢＴ ＭＡＣ手順に関連付けられた例示的な方法を示す。

【図8】図８は、ＮＲ－Ｕ ＬＢＴ ＭＡＣ手順に関連付けられた例示的な方法を示す。

【図9】図９は、ＮＲ－Ｕ ＬＢＴ ＭＡＣ手順に関連付けられた例示的な方法を示す。

【図10】図１０は、ＮＲ－Ｕ ＬＢＴ ＭＡＣ手順に関連付けられた例示的な方法を示す。

【図11】図１１は、ＮＲ－Ｕ ＬＢＴ ＭＡＣ手順の方法、システム、およびデバイスに基づいて生成され得る例示的なディスプレイ（例えば、グラフィカルユーザインタフェース）を示す。

【図12A】図１２Ａは、例示的な通信システムを示す。

【図12B】図１２Ｂは、ＲＡＮおよびコアネットワークを含む例示的なシステムを示す。

【図12C】図１２Ｃは、ＲＡＮおよびコアネットワークを含む例示的なシステムを示す。

【図12D】図１２Ｄは、ＲＡＮおよびコアネットワークを含む例示的なシステムを示す。

【図12E】図１２Ｅは、別の例示的な通信システムを示す。

【図12F】図１２Ｆは、ＷＴＲＵなどの例示的な装置またはデバイスのブロック図である。

【図12G】図１２Ｇは、例示的なコンピューティングシステムのブロック図である。

【発明を実施するための形態】

【0010】

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

【0011】

本明細書で取り上げられるＭＡＣ手順に関連する特定の問題には、とりわけ、帯域幅部
分（Bandwidth Part：ＢＷＰ）動作手順、ランダムアクセス手順、パワーヘッドルーム
報告（Power Headroom Reporting：ＰＨＲ）手順、Ｓｃｅｌｌアクティブ化または非ア
クティブ化手順、間欠受信手順、スケジューリング要求（Scheduling Request：ＳＲ）
手順、バッファステータス報告手順、論理チャネル優先順位付け手順、またはＵＥおよび
ノードＢ（Node B：ＮＢ）ＭＡＣ手順の協調に関連付けられた問題が含まれ得る。

【0012】

帯域幅部分動作手順の問題で、ＬＢＴ失敗が発生した場合、帯域幅部分非アクティブタ
イマが満了し、スケジュールすべきＵＬまたはＤＬデータがある場合でも、初期またはデ
フォルトＢＷＰに切り替わることがある。

【0013】

ランダムアクセス手順の問題で、ＬＢＴ失敗が発生した場合、１）ランダムアクセス応
答に対する十分な数（例えば、閾値数）の送信機会を許容にすることなく、ランダムアク
セス応答ウィンドウが満了することがあり、２）プリアンブル送信を成功させるために必
要な十分な数のプリアンブル送信を許容にすることなく、プリアンブル送信カウンタが最
大送信数に達することがあり、３）ＭＳＧ３送信に応答する十分な数のＰＤＣＣＨ送信機
会を許容にすることなく、競合解決タイマが満了することがあり、または、４）プリアン
ブル送信がない場合でもパワーランピングが増加し、その結果、不正確な電力設定になる
ことがある。

【0014】

パワーヘッドルーム報告（ＰＨＲ）手順問題で、ＬＢＴ失敗が発生した場合、１）ＮＢ
は、ＰＨＲがいつ計算され、その時点で何が送信されたかを判定することができないこと
があり、その結果、不正確なパワーヘッドルームの判定が生じ、２）ＰＨＲ周期タイマ、
再設定、ＳＣｅｌｌアクティブ化、ＰＳＣｅｌｌ追加、または、禁止タイマ満了によるＰ
ＨＲのトリガが、不適切に早期発生することがあり、３）ＰＨＲ計算は、実際の送信を想
定した場合に、パワーヘッドルームが不正確に計算されることがあり、または４）ＰＨＲ
送信がなかった場合でも、ＰＨＲ禁止タイマが設定されることがある。

【0015】

ＳＣｅｌｌアクティブ化／非アクティブ化手順問題で、ＬＢＴ失敗が発生した場合、Ｓ
Ｃｅｌｌ上でスケジュールすべきＵＬまたはＤＬデータがある場合に、ＳＣｅｌｌを非ア
クティブ化して、ＳＣｅｌｌ非アクティブ化タイマが満了することがある。

【0016】

間欠受信手順の問題で、ＬＢＴ失敗が発生した場合、ススケジュールすべきＵＬまたは
ＤＬデータがある場合に、ＰＤＣＣＨ受信を停止して、オンデュレーションタイマまたは
非アクティブタイマが満了することがある。

【0017】

スケジューリング要求手順の問題で、ＬＢＴ失敗が発生した場合、１）失敗したＳＲ送
信はランダムアクセス手順を開始せず、２）ＳＲ送信がなかった場合でも、ＳＲ禁止タイ
マが設定されることがあり、３）ＳＲ送信を成功させるために必要な十分な数のＳＲ送信
を許容することなく、ＳＲ送信カウンタが最大送信数に達することがあり、または、４）
ＳＲ送信がない場合でも、ＳＲ保留がクリアされることがある。

【0018】

バッファステータス報告手順問題で、ＬＢＴ失敗が発生した場合、ＵＬ－ＳＣＨリソー
スが利用可能な場合、ＢＳＲは送信されないことがあり、ＳＲはトリガされない。

【0019】

論理チャネルの優先順位付け手順の問題で、ＬＢＴ失敗が発生した場合、ＭＡＣ ＰＤ
Ｕは、後続のグラントで送信できないことがあり、その結果、ユーザデータおよび制御シ
グナリングが損失する。

【0020】

ＵＥおよびＮＢのＭＡＣ手順の協調問題で、ＬＢＴ失敗が発生した場合、ＵＥは、適切
なアクションのためにＮＢに認識される必要があるＭＡＣ手順を達成するアクションを実
行することがある。さらに、ＮＢは、ＵＥの挙動とは無関係なアクションを実行し得る。

【0021】

前述の例の問題を考慮して、不適切なアクションを実行せず、意図しない結果が回避さ
れるように、ＬＢＴ失敗を考慮し得る既存のＭＡＣ手順の修正または新しいＭＡＣ手順の
作成が存在し得る。問題をどのように対処し得るかの概要を以下に示す。

【0022】

図１は、ＮＲ－Ｕ ＬＢＴ ＭＡＣ手順のための例示的なシステムを示す。ステップ１
１１において、ＵＥ１０１は、基地局１０２からＵＥ１０１へのチャネルアクセスに関す
る情報を取得する。情報は、基地局１０２からシグナリングされるダウンリンク情報であ
り得る。ステップ１１２において、ＵＥ１０１は、基地局１０２へのアップリンクチャネ
ルアクセス（例えば、アップリンク情報）に関する情報を検出し得る。アップリンク情報
は、リッスンビフォートーク（ＬＢＴ）動作または他の動作（例えば、３ＧＰＰ ＴＳ
３６．２１３ Ｖ１４．８．０セクション１５内の動作）を行うことによって検出され得
る。ステップ１１３において、ステップ１１１またはステップ１１２の情報（例えば、ア
ップリンク／ダウンリンク情報）に基づいて、ＭＡＣ手順の動作を達成し得る。ＭＡＣ手
順は、本明細書に開示されているように、特に（例えば、ＰＨＲ、ＢＳＲ、ＢＦＤ）、Ｌ
ＢＴＲ１２１（例えば、図１０）、ＤＲＸ１２２（例えば、図６）、ＢＷＰ動作１２３（
例えば、図２）、またはランダムアクセス１２４（例えば、図３）、スケジューリング要
求１２５（例えば、図７）を含み得る。本明細書では、アップリンクまたはダウンリンク
チャネルアクセス情報を上記のステップで使用し得ることが意図されている。

【0023】

図２～図１０は、ＮＲ－Ｕ ＬＢＴ ＭＡＣ手順に関連付けられた例示的な方法を示し
、本明細書でより詳細に記載される。

【0024】

図２は、帯域幅部分（ＢＷＰ）動作手順のための例示的な方法を示す。例えば、ステッ
プ１３１では、１つ以上のＬＢＴ失敗（例えば、アップリンク／ダウンリンクＬＢＴ失敗
の閾値数）が検出される。ステップ１３２において、ステップ１３１で検出された失敗に
基づいて、ＢＷＰ非アクティブタイマを延長し得る。スケジュールすべきＵＬまたはＤＬ
データが存在し得るので、初期またはデフォルトＢＷＰへの切り替えが回避され得るよう
に、非アクティブタイマを延長し得る。ステップ１３３において、ステップ１３１で検出
された失敗に基づいて、代替帯域幅部分に切り替える。

【0025】

図３は、ランダムアクセス手順のための例示的な方法を示す。例えば、ステップ１４１
において、１つ以上のＬＢＴ失敗（例えば、アップリンク／ダウンリンクＬＢＴ失敗の閾
値数）が検出される。ステップ１４１で検出された失敗に基づいて、ＵＥ１０１はステッ
プ１４２、１４３、１４４または１４５を実行し得る。ステップ１４２において、ランダ
ムアクセス応答ウィンドウを延長し得る。ステップ１４２は、ランダムアクセス応答のた
めの十分な数の送信機会を許容し得る。ステップ１４３において、プリアンブル送信カウ
ンタはインクリメントされないことがある。ステップ１４３は、プリアンブル送信を成功
させるために十分な数のプリアンブル送信を許容し得る。ステップ１４４において、競合
解決タイマは延長され得、これは、ＭＳＧ３送信に応答して十分な数のＰＤＣＣＨ送信機
会を許容し得る。ステップ１４５において、パワーランピングを増加させないようにし得
、これは、適切な電力設定を維持するのに役立ち得る。ステップ１４６において、ＲＡ問
題が上位層に示され、ＲＡ手順が不成功であると見なし得る。ステップ１４７において、
代替帯域幅部分への切り替えがあり得る。本明細書では、ステップ１４２からステップ１
４７のうちの１つ以上が、ステップ１４１に基づいて生じ得ることが意図されている。

【0026】

図４は、パワーヘッドルーム報告手順のための例示的な方法を示す。例えば、ステップ
１５１において、１つ以上のＬＢＴ失敗（例えば、アップリンク／ダウンリンクＬＢＴ失
敗の閾値数）が検出される。ステップ１５１で検出された失敗に基づいて、ＵＥ１０１は
ステップ１５２、１５３、１５４、１５５、１５６、１５７または１５８を実行し得る。
ステップ１５２において、ＵＥ１０１は、ＰＨＲが計算されたときを基地局１０２（例え
ば、ノードＢ）に示し得る。ステップ１５３において、ＵＥ１０１は、ＰＨＲ計算時に送
信されたものを基地局１０２に示し得る。ステップ１５４において、ＵＥ１０１は、ＬＢ
Ｔ失敗が発生したときを基地局１０２に示し得る。ステップ１５５において、ＵＥ１０１
は、ＰＨＲ送信に遅延があったことを基地局１０２に示し得る。ステップ１５６において
、ＰＨＲ周期タイマ、再設定、ＳＣｅｌｌアクティブ化、ＰＳＣｅｌｌ追加、または禁止
タイマ満了によるＰＨＲトリガリングが遅延し得る。ステップ１５７において、ＰＨＲ計
算は、損失または遅延した送信を考慮に入れてもよい。ステップ１５８において、ＰＨＲ
禁止タイマが設定されないか、または遅延し得る。

【0027】

図５は、ＳＣｅｌｌアクティブ化／非アクティブ化手順のための例示的な方法を示す。
例えば、ステップ１６１において、１つ以上のＬＢＴ失敗（例えば、アップリンク／ダウ
ンリンクＬＢＴ失敗の閾値数）が検出される。ステップ１６１に基づいて、ステップ１６
２において、ＳＣｅｌｌ非アクティブ化タイマは延長され得、これは、ＳＣｅｌｌ上での
追加のＵＬまたはＤＬデータスケジューリング機会を許容し得る。

【0028】

図６は、間欠受信手順のための例示的な方法を示す。例えば、ステップ１７１において
、１つ以上のＬＢＴ失敗（例えば、アップリンク／ダウンリンクＬＢＴ失敗の閾値数）が
検出される。ステップ１７１に基づいて、オンデュレーションまたは非アクティブタイマ
は延長され得、これは追加のＵＬまたはＤＬデータスケジューリング機会を許容し得る。
ステップ１７３において、ＤＲＸショートサイクルタイマが適用され得る。ステップ１７
４において、オンデュレーションまたは非アクティブタイマは、ＭＣＯＴ、ＣＷＳまたは
ＣＣＡと整合され得る。ステップ１７５において、ＤＲＸ設定が調整され得る。本明細書
では、ステップ１７２からステップ１７５のうちの１つ以上が、ステップ１７１に基づい
て生じ得ることが意図されている。

【0029】

図７は、スケジューリング要求手順のための例示的な方法を示す。例えば、ステップ１
８１において、１つ以上のＬＢＴ失敗（例えば、アップリンク／ダウンリンクＬＢＴ失敗
の閾値数）が検出される。ステップ１８１で検出された失敗に基づいて、ＵＥ１０１はス
テップ１８２、１８３、１８４または１８５を実行し得る。ステップ１８２において、ラ
ンダムアクセス応答ウィンドウが開始され得る。ステップ１８３において、ＳＲ禁止タイ
マが設定されないか、または禁止タイマの設定が遅延し得る。ステップ１８４において、
ＳＲ送信カウンタは、ＳＲ送信を成功させるために必要な十分な数のＳＲ送信を許容する
ために、インクリメントされないことがある。ステップ１８５において、ＳＲ保留がクリ
アされないか、またはＳＲ保留のクリアが遅延し得る。ステップ１８６において、代替帯
域幅部分への切り替えがあり得る。本明細書では、ステップ１８２からステップ１８６の
うちの１つ以上が、ステップ１８１に基づいて生じ得ることが意図されている。

【0030】

図８は、バッファステータス報告手順のための例示的な方法を示す。例えば、ステップ
１９１において、１つ以上のＬＢＴ失敗（例えば、アップリンク／ダウンリンクＬＢＴ失
敗の閾値数）が検出される。ステップ１９２に基づいて、ＵＬ－ＳＣＨリソースが利用可
能であっても、ＳＲがトリガされ得る。

【0031】

図９は、論理チャネル優先順位付け手順のための例示的な方法を示す。例えば、ステッ
プ２０１では、１つ以上のＬＢＴ失敗（例えば、アップリンク／ダウンリンクＬＢＴ失敗
の閾値数）が検出される。ステップ２０１で検出された失敗に基づいて、ＵＥ１０１はス
テップ２０２または２０３を実行し得る。ステップ２０２において、ＭＡＣ ＰＤＵは構
築されないことがある。ステップ２０３において、ＭＡＣ ＰＤＵは、再フォーマットさ
れ得、これは、後続のグラントで送信可能にし得る。

【0032】

図１０は、ＵＥ１０１がＬＢＴの失敗または成功情報を基地局１０２に報告するための
例示的な方法を示し、これは、ＵＥ１０１と基地局ＭＡＣ手順との協調を改善することを
可能にし得る。例えば、ステップ２１１において、１つ以上のＬＢＴ失敗（例えば、アッ
プリンク／ダウンリンクＬＢＴ失敗の閾値数）が検出される。ステップ２１１に基づいて
、ＵＥ１０１は、ＬＢＴ失敗を報告するか、またはどの手順がどのように影響を受けるか
を報告し得る。ステップ２１３において、報告は、設定された期間内のＬＢＴ成功／失敗
統計を含む。ステップ２１４において、報告は、タイミング情報、ＣＣＡ、ＭＣＯＴ、ま
たはＣＷＳを含む。ステップ２１５において、送信禁止タイマは、報告の頻度を最小にす
るように設定される。本明細書では、ステップ２１２からステップ２１５のうちの１つ以
上が、ステップ１８１に基づいて生じ得ることが意図されている。

【0033】

図２～図１０は、ＮＲ－Ｕ ＬＢＴ ＭＡＣ手順に関連付けられた例示的な方法を示す
。複数のＮＲ－Ｕ ＬＢＴ ＭＡＣ手順を、以下でより詳細に記載する。

【0034】

（ＭＡＣへのＮＲ－Ｕ ＬＢＴ動作の影響）
開示された主題は、全体的なＭＡＣ動作および多数の特定のＭＡＣ手順に適用され得る
。これらのＭＡＣ手順は、帯域幅部分（ＢＷＰ）動作、ランダムアクセス（Random Acce
ss：ＲＡ）、パワーヘッドルーム報告（ＰＨＲ）、ＳＣｅｌｌアクティブ化および非アク
ティブ化、論理チャネル優先順位付け（Logical Channel Prioritization：ＬＣＰ）、
間欠受信（Discontinuous Reception：ＤＲＸ）、スケジューリング要求（ＳＲ）、バッ
ファステータス報告（Buffer Status Report：ＢＳＲ）、ならびに場合により新しいＬ
ＢＴ ＭＡＣ手順などを含み得る。

【0035】

ＬＢＴ失敗により、これらのＭＡＣ手順に不要で意図しない影響をもたらす可能性があ
る。ＬＢＴ失敗または成功の認識があれば、これらのＭＡＣ手順は、ＬＢＴを必要としな
いライセンス周波数帯における動作と同様に、および同様の性能で、動作することができ
る。第１のＭＡＣ手順（例えば、ランダムアクセス）で開示され得るステップ（例えば、
アクション）は、第２のＭＡＣ手順（例えば、ＢＷＰオペレーション）に適用可能であり
得ることが意図されている。したがって、ステップは一般に、特定のＭＡＣ手順に限定さ
れない。

【0036】

（ＵＬおよびＤＬの両方のＬＢＴ失敗に関する一般的な考慮事項）
ＭＡＣ手順への影響に関しては、ＵＬまたはＤＬにおいてＬＢＴ失敗が考慮されること
がある。ＭＡＣ手順および手順内の特定のアクションによって、ＵＬおよびＤＬのＬＢＴ
失敗の両方が考慮されることがあり、または、ＵＬのみもしくはＤＬのみのＬＢＴ失敗が
考慮されることがある。さらに、ＬＢＴ表示がＭＡＣにどのように提供されるか、および
どの情報が提供されるかは、ＵＬおよびＤＬによって異なることがある。

【0037】

ＵＬ ＬＢＴ動作の場合、ＰＨＹ層はＭＡＣに、ＬＢＴ成功または失敗を示し得る。Ｕ
Ｌ ＬＢＴ成功もしくは失敗の表示は、ＵＬ送信に関連付けられてもよく、またはＵＬ
ＬＢＴ手順は、ＵＬ送信とは独立して実行されてもよい。各ＵＬ ＬＢＴ成功または失敗
の表示は、１つ以上のＭＡＣ手順と関連付けられ得る。

【0038】

ＤＬ ＬＢＴ動作の場合、ＮＢはＵＥにＤＬ ＬＢＴ成功または失敗をシグナリングし
得る。ＤＬ ＬＢＴの成功もしくは失敗の表示は、ＤＬ送信に関連付けられてもよく、ま
たはＤＬ ＬＢＴ手順は、ＤＬ送信とは独立して実行されてもよい。各ＤＬ ＬＢＴ成功
または失敗の表示は、１つ以上のＭＡＣ手順と関連付けられ得る。

【0039】

ＭＡＣ手順、および手順内の特定のアクションによっては、関連する送信がない場合で
もＬＢＴを実行するために必要な場合がある。現在のＭＡＣ手順では、チャネルへの常時
アクセスが存在し、送信の停止またはブロッキングがないことを前提としているため、こ
れが必要な場合がある。例えば、ＵＥがＭＡＣ手順においてダウンリンク割り当てまたは
アップリンクグラントを検出しない場合、ダウンリンクまたはアップリンクにおいて送信
のためにスケジュールすべきデータが存在しないという仮定があり得る。しかし、ＬＢＴ
失敗によってブロックされているかまたは遅延している、送信のためにスケジュールすべ
きデータが存在することがある。この場合、ＭＡＣ手順は、意図しない結果または望まし
くない結果をもたらし得るアクションを実行し得る。

【0040】

本開示において、全体的なＭＡＣ動作または特定のＭＡＣ手順についてＬＢＴ失敗また
は成功が言及される場合、アップリンクＬＢＴまたはダウンリンクＬＢＴの両方が考慮さ
れ得る。ＭＡＣ手順および手順内の特定のアクションによって、ＵＬおよびＤＬのＬＢＴ
失敗の両方が考慮されるか、または、ＵＬのみもしくはＤＬのみのＬＢＴ失敗が考慮され
る。

【0041】

ＬＢＴ失敗および成功の両方を、ＭＡＣにシグナリングする、または示す必要はないこ
とに留意すべきである。ＬＢＴ失敗の表示がない場合は成功と解釈され得、成功の表示が
ない場合は失敗と解釈され得る。ＰＨＹ層からのＵＬ ＬＢＴの表示はＬＢＴ失敗のみを
示し得、ＮＢからのＤＬ ＬＢＴ表示はＬＢＴ成功のみを示し得る。

【0042】

ＬＢＴ成功または失敗の表示は、既知の状況で周期的に提供されることもあり、または
ＭＡＣ手順によって実行される特定のアクションによってトリガされる場合もある。ＤＬ
ＬＢＴの成功または失敗は、ＮＢによって周期的にシグナリングされ得、ＵＬ ＬＢＴ
の成功または失敗は、特定のＭＡＣ手順の動作に応じてＰＨＹ層によって示され得る。周
期的な表示は、ＭＡＣ手順により駆動されるオンデマンド表示により増大されることがあ
り、およびその逆もあることに留意されたい。

【0043】

ＬＢＴの成功または失敗の表示は、特定のＬＢＴ手順の動作に関するものであることも
あり、または表示は、既知の期間にわたる２つ以上のＬＢＴ手順の動作に関する情報を提
供することもある。期間は、最後の報告以降の期間であり得る。ＵＬ ＬＢＴ表示は、特
定のＬＢＴ手順の動作に起因することがあり、ＤＬ ＬＢＴ表示は、一定期間の複数（例
えば、閾値数）のＬＢＴ動作に関する情報を提供し得る。

【0044】

ＬＢＴの成功または失敗の表示は、ＬＢＴが実行されるキャリアおよびＢＷＰ（単数ま
たは複数）に関する情報を提供し得る。アップリンクまたはダウンリンクＬＢＴの成功ま
たは失敗の表示に加えて、さらなるＬＢＴ手順情報がＭＡＣ手順に提供されてもよい。Ｍ
ＡＣ手順では、ダウンリンクおよびアップリンクの送信機会が考慮される。これらのＭＡ
Ｃ手順を適切に動作させるためには、アップリンクおよびダウンリンクで送信を実行でき
る期間または実行できない期間を認識する必要がある場合がある。これを達成するために
、ＬＢＴの成功もしくは失敗の表示に加えて、またはこれに含まれる、クリアチャネル評
価（Clear Channel Assessment：ＣＣＡ）の期間、選択された最大チャネル占有時間（
Maximum Channel Occupancy Time：ＭＣＯＴ）、選択されたコンテンションウィンド
ウサイズ（Contention Window Size：ＣＷＳ）、および他のタイミング情報がＭＡＣに
提供され、ダウンリンクおよびアップリンク送信機会の適切な判定が可能になることが本
明細書で開示される。ＭＣＯＴ、ＣＷＳ、または他のタイミングは、選択されたタイミン
グを表すチャネルアクセス優先度クラス（Channel Access Priority Class：ＣＡＰＣ
）または別のインデックスによって特定され得る。

【0045】

（ダウンリンクＬＢＴ成功／失敗の表示）
ＤＲＸサイクルを実行するために、ＵＥのＤＲＸオンデュレーションの間、ＤＬ ＬＢ
Ｔ成功の表示がＮＢからＵＥにシグナリングされ得ることが議論されてきた。これは、Ｄ
ＲＸ非アクティブタイマが実行されている期間、および場合によりＤＲＸアクティブ時間
を構成する全ての期間を含むように延長されるべきである。例えば、ＵＥがＤＲＸオンデ
ュレーション内にない間にランダムアクセスまたはスケジューリング要求手順が開始され
た場合、ＬＢＴが必要とされないときと同様の適切な動作および性能のために、ＬＢＴ失
敗の認識が必要な場合がある。

【0046】

さらに、この問題に対処するより包括的な方法として、ＵＥに既知の定期的な方法で連
続的に送信されるＤＬ ＬＢＴ成功の表示を考慮して、ＤＲＸアクティブタイムの外で実
行されるＭＡＣ手順がＤＬ ＬＢＴ成功および失敗の認識の恩恵を受けることができるよ
うにする。

【0047】

ＤＬ ＬＢＴ成功の表示は、新しい明示的信号であってもよく、または暗黙的に検出さ
れてもよい。例えば、ＤＬ ＬＢＴ成功は、ＳＳＢまたはＤＲＳの受信によって暗黙的に
検出され得、新しい明示的信号は、新しいＤＣＩフォーマット（例えば、個々のＵＥもし
くはＵＥのグループにアドレス指定されるか、または全てのＵＥにブロードキャストされ
る）であり得る。

【0048】

ＤＲＸオンデュレーションは一般的に異なるＵＥに対して時間がずれているため、ＤＬ
ＬＢＴ成功の表示を周期的に連続的にシグナリングしても、必ずしも複雑さが増したり
、またはリソースの使用が増えたりするわけではない。周期性に応じて、シグナリングオ
ーバーヘッドは低減され得る。

【0049】

また、シグナリングＤＬ ＬＢＴ表示は、ＵＥ固有のものか、またはＤＲＸオンデュレ
ーションを共有するＵＥのグループに固有のものであってもよいことに留意すべきである
。セル固有のＤＬ ＬＢＴ表示により、リソースのより効率的な使用、ならびに、より一
貫したＭＡＣ手順の動作およびパフォーマンスをもたらすことができる。

【0050】

また、ＬＢＴ成功の表示は、単一の表示ではなくてもよいと見なされる。また、シグナ
リングされた情報は、最後のＬＢＴ成功の表示以降の期間の情報も提供し得る。また、シ
グナリングされた情報は、ＮＢが、例えば、特定のチャネルまたはＢＷＰへの、ＤＬチャ
ネルのアクセスをどれくらい有するかについての情報を提供し得る。この場合、ＭＡＣ手
順は、ＤＬ ＬＢＴ成功または失敗の時間経過と共に連続的な認識を有し得、これにより
、ＤＬ ＬＢＴ失敗によるＭＡＣ手順への影響がより正確になり得る。

【0051】

ダウンリンク成功の表示はまた、ＭＡＣ手順が送信機会を正確に判定することができる
ようにするために、送信を行うことができるとき、および行うことができないときを特定
するタイミング情報を提供し得る。これを達成するために、ＬＢＴの成功の表示に、クリ
アチャネル評価（ＣＣＡ）の期間、選択された最大チャネル占有時間（ＭＣＯＴ）、選択
されたコンテンションウィンドウサイズ（ＣＷＳ）、もしくはダウンリンク送信機会の適
切な判定を可能にするためにＭＡＣに提供される他のタイミング情報を追加されるか、ま
たは含められ得る。ＭＣＯＴ、ＣＷＳ、または他のタイミング情報は、選択されたタイミ
ングを表すチャネルアクセス優先度クラス（ＣＡＰＣ）または別のインデックスによって
特定され得る。

【0052】

（アップリンクＬＢＴ成功／失敗の表示）
ＮＢがＬＢＴ失敗または成功ステータスをＵＥに示すことに加えて、ＵＥは、ＵＬ Ｌ
ＢＴ失敗または成功情報をＮＢに提供し得る。

【0053】

本明細書に開示されているように、ＵＥ ＭＡＣ手順への複数の潜在的な影響が存在し
得る。特定のＭＡＣ手順にＬＢＴ失敗または成功がどのように影響したかをＮＢが認識す
ることが必要な場合がある、複数の事例が存在し得る。例えば、ＤＲＸアクティブタイム
またはＤＲＸサイクルが影響を受けた場合、ＮＢはＵＥが適切にスケジュールされるよう
に認識しなければならない。

【0054】

ＬＢＴ手順は、ＵＬ ＬＢＴ失敗をＮＢに示す以上のことを行ってもよい。大量のＵＬ
ＬＢＴ失敗が発生した後、他のアクションが実行されることがある。本明細書で示すよ
うに、既存のＭＡＣ手順の動作は、ＬＢＴ失敗によって影響を受けることがある。新しい
ＬＢＴ手順は、ＬＢＴ失敗を解決するための新しいアクションを実行する可能性を有する
。例えば、チャネルアクセス優先度は、ＬＢＴが成功する可能性を高めるように調整され
得る。

【0055】

ＬＢＴ失敗の総数がカウントされることがあり、これは、指定されたまたは設定された
期間内であり得る。あるいは、ＬＢＴ失敗カウンタ（Failure Counters：ＦＣ）は、連
続ＬＢＴ失敗をカウントし、ＬＢＴ成功時にＬＢＴ ＦＣをゼロにリセットしてもよい。
ＬＢＴ失敗がカウントされ得る期間は、時間のスライディングウィンドウであってもよい
。ＬＢＴ失敗カウンタが指定されたまたは設定された閾値を超過する場合、ＬＢＴ状態は
失敗したと見なされ得る。指定もしくは設定された数のＬＢＴ失敗を超過していない場合
、または指定もしくは設定された数のＬＢＴ成功の表示が受信される場合、ＬＢＴ状態は
成功したと見なされ得る。ＭＡＣ手順は、ＭＡＣ手順に関連付けられた個々のＬＢＴ失敗
をカウントするのではなく、ＬＢＴ状態をチェックし得る。ＭＡＣ手順では、ＬＢＴ状態
に従ってカウンタとタイマを調整し得る。例えば、ＭＡＣ手順はカウンタおよびタイマを
延長し得、またはＬＢＴ状態に応じてタイマおよびカウンタが最大閾値に達したと見なし
得る。ＬＢＴ状態は、より高い層に示されることもある。例えば、ＲＲＣ手順に影響を与
える。

【0056】

ＵＬ ＬＢＴの成功または失敗の情報を提供するために、新しいＭＡＣ ＬＢＴ報告（
LBT Report：ＬＢＴＲ）手順が定義され得る。ＬＢＴＲ ＭＡＣ ＣＥは、以前のＵＬ
ＬＢＴ結果に関する履歴情報を提供し得る。これは、報告が生成されたときに対して、
特定の期間にわたることがある。例えば、最後のＬＢＴＲ ＭＡＣ ＣＥが送信されてか
らの期間であり得る。ＭＡＣ ＣＥは、どのＭＡＣ手順（単数または複数）が影響を受け
たか、またはいつＬＢＴ失敗が発生したかに関する情報を提供する場合があり、それによ
って、ＮＢは、どの手順（単数または複数）が影響を受けたかを相関させようと試み得る
。ＬＢＴＲ ＭＡＣ ＣＥはまた、例えば、ＢＷＰ ＬＢＴが失敗する、およびＢＷＰ
ＬＢＴが成功した場合のＬＢＴ結果に、ＢＷＰ情報を含んでもよい。ＲＲＣは、ＵＥ内に
、ＬＢＴＲ報告期間を設定してもよい。

【0057】

あるいは、ＵＬ物理制御シグナリングが、ＵＬ ＬＢＴ失敗または成功の表示を提供し
てもよい。これは、スケジュールされた、または新しいＵＬシグナリングの場合、ＰＵＣ
ＣＨで伝送されるか、またはＰＵＳＣＨにピギーバックされ得る。周期的なＵＬシグナリ
ングの受信の欠如は、ＵＥ ＬＢＴ失敗と解釈されることがある。これは、ＰＵＣＣＨま
たは新しいＵＬシグナリングであり得る。新しいＵＬシグナリングは、ＮＢ受信が既知の
物理的リソースおよび既知の時間に発生するように設定されなければならないことがある
。

【0058】

アップリンクＬＢＴ成功および失敗の表示はまた、ＭＡＣ手順が送信機会を正確に判定
することができるようにするために、送信を行うことができるとき、および行うことがで
きないときを特定するタイミング情報を提供し得る。これを達成するために、ＬＢＴ成功
もしくは失敗の表示に加えて、またはこれに含まれる、クリアチャネル評価（ＣＣＡ）の
期間、選択された最大チャネル占有時間（ＭＣＯＴ）、選択されたコンテンションウィン
ドウサイズ（ＣＷＳ）、または他のタイミング情報がＭＡＣに提供され、アップリンク送
信機会の適切な判定が可能になることが提案されている。ＭＣＯＴ、ＣＷＳ、または他の
タイミングは、選択されたタイミングを表すチャネルアクセス優先度クラス（ＣＡＰＣ）
または別のインデックスによって特定され得る。

【0059】

（ＭＡＣタイマおよびカウンタへのＬＢＴの影響）
ＬＢＴ失敗により、送信機会が損失する場合がある。また送信機会の損失により、送信
の成功を達成するためのより長い時間にもつながる。ＭＡＣ手順は、手順の失敗を宣言す
る前に、送信機会の量および完了するまでの時間を考慮する。ＬＢＴが必要な場合にＭＡ
Ｃ手順を適切に実行するためには、送信機会の数、および場合によっては手順が正常に完
了するまでの期間は、ＬＢＴ失敗を考慮する必要がある。

【0060】

既存のＭＡＣ手順では、ＭＡＣ ＰＤＵがＰＨＹ層に与えられるとき、またはＰＨＹア
ップリンク制御情報（例えば、ＳＲ）を送信するためにＰＨＹに命令が与えられるとき、
ＰＤＵもしくはＰＨＹアップリンク制御情報が送信されると仮定する。特定のＭＡＣ手順
に関連付けられたＭＡＣ ＣＥが構築され、ＭＡＣ ＰＤＵに多重化されるとき、このＭ
ＡＣ ＣＥが送信されると仮定され得る。特定のＭＡＣ手順に関連付けられたＭＡＣ Ｃ
ＥまたはＰＨＹアップリンク制御情報が送信され得る周波数を制限するために、ＭＡＣ
ＣＥが構築され、ＭＡＣ ＰＤＵがＰＨＹ層に与えられるとき、またはＰＨＹアップリン
ク制御情報を送信するためにＰＨＹに命令が与えられるとき、禁止タイマが設定され得る
。ＭＡＣ ＣＥまたはＰＨＹのアップリンク制御情報が送信され得る頻度を適切に制御し
、必要なときに送信されることを確実するために、これらの禁止タイマの設定はまた、Ｌ
ＢＴの失敗を考慮してもよい。

【0061】

処理ＭＡＣ手順のシーケンスもまた、考慮され得る。既存の手順は、ＰＨＹ層によって
ＬＢＴが実行される前に、ＭＡＣ手順が実行されるときに、カウンタおよびタイマをイン
クリメントし得る。既存のＭＡＣ手順への影響に関しては、複数の方法を考慮し得るが、
これは、以下に関連してもよい。１）ＭＡＣがＰＨＹ層カウンタからＬＢＴ失敗の表示を
受信し、送信失敗を考慮してタイマが調整される場合、２）ＬＢＴが成功してタイマおよ
びカウンタが動作する場合、または、３）最初のＭＡＣ手順が実行されてから、または最
初に設定されてから、カウンタ（単数または複数）もしくはタイマ（単数または複数）が
それらの最大閾値に達するまでの期間に、ＬＢＴ失敗が記録される。

【0062】

ＭＡＣがＰＨＹ層カウンタからＬＢＴ失敗の表示を受信すると、送信失敗を考慮するよ
うにカウンタおよびタイマが調整される。ＭＡＣ手順が実行されたときにインクリメント
されたカウンタは、手順が実行される前に設定されたものから変更されないようにデクリ
メントされ得る。これは、タイマの場合は、多少複雑になり得る。最適には、手順の最大
時間は、ＬＢＴの失敗の期間を考慮すべきではない。ＬＢＴ失敗が発生したときのＭＡＣ
タイマの作用については、異なるＭＡＣ手順にタイマがどのように使用されるかによって
、次のような複数の選択肢がある。ａ）ＬＢＴ失敗に関連付けられたＭＡＣ手順が実行さ
れたときから、ＭＡＣ手順を実行する次の機会までの期間をタイマから減算するか、もし
くは最大時間閾値に加算する（タイマが満了するとき）、ｂ）ＬＢＴ失敗表示の受信時に
タイマを停止し、ＭＡＣ手順を実行する次の機会に再起動する、ｃ）ＬＢＴ失敗表示を受
けてタイマを再起動する、または、ｄ）ＬＢＴ失敗に関連付けられたＭＡＣ手順のタイマ
を設定したとき（起動または再起動）から、ＭＡＣ手順のタイマを設定する次の機会まで
の期間を、タイマから減算するか、もしくは最大時間閾値に加算する（タイマが満了する
とき）。

【0063】

このアプローチに関する１つの懸念は、ＭＡＣ手順が実行された時間と、ＭＡＣ手順関
連付けられたＬＢＴ失敗表示カウンタ（単数または複数）またはタイマ（単数または複数
）の受信との間が最大値に達したときに、何が起こるかである。この問題に対処する１つ
の方法は、タイマまたはカウンタがその最大値に達したときに、ＭＡＣが前の送信に対す
るＬＢＴ表示を待っているか否かをチェックし、ＬＢＴ表示が成功したと判定された後に
タイマまたはカウンタの満了に関連付けられたアクションのみを呼び出すことである。

【0064】

ＬＢＴが成功すると、タイマおよびカウンタが作用する。この方法では、ＭＡＣ手順が
実行されるとき、カウンタ（単数または複数）およびタイマ（単数または複数）は作用さ
れない。ＬＢＴの成功表示時にカウンタがインクリメントされ、タイマがチェックまたは
調整される。このアプローチの問題の１つは、ＬＢＴの成功表示時にタイマまたはカウン
タがそれらの最大閾値に達した場合であり、これは、ＭＡＣ手順が異なるように実行され
たことを意味する。この状況に対処するには、いくつかの選択肢がある。ＭＡＣ手順を実
行するときに、タイマおよびカウンタは、手順実行時にタイマおよびカウンタが手順に従
って調整されていた場合、それらの最大閾値に達していたか否かをチェックされ得、この
場合、ＭＡＣ手順は、カウンタまたはタイマがそれらの最大閾値に達していたかのように
アクションを実行し得る。

【0065】

ＬＢＴ失敗は、最初のＭＡＣ手順が実行されたとき、または最初に設定されたときから
、ポイントカウンタ（単数または複数）またはタイマ（単数または複数）がそれらの最大
閾値に達するまでの期間に記録され得る。タイマまたはカウンタが最大閾値に達すると、
ＬＢＴ失敗の記録がチェックされ、ＬＢＴ失敗が発生した場合、手順はＬＢＴ失敗を考慮
してタイマおよびカウンタを調整する。これを達成するには、以下の（ａ）または（ｂ）
のような複数の選択肢があり得る。（ａ）最大閾値に達したときに実行されるアクション
がこの時点で実行されないように、ＬＢＴ失敗の数またはＬＢＴ失敗の期間に応じて、タ
イマおよびカウンタの最大閾値が調整される、または、（ｂ）最大閾値に達したときに実
行されるアクションがこの時点で実行されないように、失敗の数およびＬＢＴ失敗の期間
に応じて、タイマおよびカウンタが再起動される。

【0066】

タイマおよびカウンタに影響を及ぼすＬＢＴ失敗により、受け入れられない遅延（例え
ば、閾値に達する）が発生するか、またはＭＡＣ手順が際限なく停止することがある。Ｍ
ＡＣ手順カウンタおよびタイマが決して最大閾値に達しないことがある。したがって、開
示されたＭＡＣ手順の変更は、連続的なまたは相当量のＬＢＴ失敗の可能性を考慮に入れ
得る。この場合、ＭＡＣ手順は、各ＭＡＣ手順が適切に実行されるように、時間の最大延
長またはカウンタの最大延長を考慮してもよい。例えば、ＭＡＣ手順カウンタ（MAC Pro
cedure Counter：ＭＡＣ ＰＣ）およびＭＡＣ手順タイマ（MAC Procedure Timer：Ｍ
ＡＣ ＰＴ）の延長を制限することは、次の方法で対処し得る。１）ＭＡＣ手順ＬＢＴ失
敗カウンタ（LBT Failure Counter：ＬＢＴ ＦＣ）、ＭＡＣ ＰＣおよびＭＡＣ Ｐ
Ｔ延長カウンタ（Extension Counter：ＥＣ）、またはＭＡＣ ＰＣおよびＭＡＣ ＰＴ
延長最大閾値（Extended Maximum Threshold：ＥＭＴ）。

【0067】

ＭＡＣ手順ＬＢＴ失敗カウンタ（ＬＢＴ ＦＣ）、ＬＢＴ ＦＣは、ＬＢＴ失敗の総数
をカウントし得、これは、指定されたまたは設定された期間内であり得る。あるいは、Ｌ
ＢＴ ＦＣは連続ＬＢＴ失敗をカウントしてもよく、ＬＢＴが成功するとＬＢＴ ＦＣは
ゼロにリセットされる。ＬＢＴ ＦＣ期間は、ＭＡＣ手順が完了するまでに許容される時
間、または時間のスライディングウィンドウであり得る。特定のＭＡＣ手順では、２つ以
上のＬＢＴ ＦＣを使用してもよい。ＭＡＣ手順が独立したアクションを並列に実行する
場合、各手順はＬＢＴ ＦＣを有してもよい。ＬＢＴ ＦＣには、最大値が指定されてい
るか、または設定されている場合がある。ＬＢＴ ＦＣが最大カウントに達すると、ＭＡ
Ｃ手順のＬＢＴ失敗時に、ＭＡＣ ＰＣまたはＭＡＣ ＰＴは延長されなくなる。あるい
は、ＬＢＴ ＦＣが最大カウントに達すると、ＭＡＣ手順はＭＡＣ ＰＣまたはＭＡＣ
ＰＴが最大値に達したかのようにアクションを実行する。これにより、ＭＡＣ手順が失敗
したと見なされ得る。

【0068】

ＭＡＣ ＰＣおよびＭＡＣ ＰＴ延長カウンタ（ＥＣ）、ＬＢＴ失敗により、ＭＡＣ
ＰＣまたはＭＡＣ ＰＴの最大閾値が延長される。延長の基準は、指定されたまたは設定
された期間内の、指定されたまたは設定されたＬＢＴ失敗の数であり得る。例えば、ＭＡ
Ｃ ＰＴの最大閾値あってもよい。ＥＣは、ＭＡＣ ＰＣまたはＭＡＣ ＰＴ延長の総数
をカウントすることがあり、これは、指定されたまたは設定された期間内であり得る。あ
るいは、ＥＣは、ＭＡＣ ＰＣまたはＭＡＣ ＰＴ延長を連続してカウントしてもよい。
ＥＣ期間は、ＭＡＣ手順が完了するまでに許容される時間、または時間のスライディング
ウィンドウであり得る。特定のＭＡＣ手順では、２つ以上のＥＣを使用してもよい。ＭＡ
Ｃ手順が独立したアクションを並列に実行する場合、各手順はＥＣを有してもよい。ＥＣ
は、指定された、または設定された最大値を有し得る。ＥＣが最大カウントに達すると、
ＭＡＣ手順のＬＢＴ失敗時に、ＭＡＣ ＰＣまたはＭＡＣ ＰＴは延長されなくなる。あ
るいは、ＥＣが最大カウントに達すると、ＭＡＣ手順はＭＡＣ ＰＣまたはＭＡＣ ＰＴ
が最大値に達したかのようにアクションを実行し得る。これにより、ＭＡＣ手順が失敗し
たと見なされ得る。

【0069】

ＭＡＣ ＰＣおよびＭＡＣ ＰＴ延長最大閾値（ＥＭＴ）、ＬＢＴ失敗により、ＭＡＣ
ＰＣまたはＭＡＣ ＰＴの最大閾値が延長され得る。ＭＡＣ ＰＣまたはＭＡＣ ＰＴ
の最大閾値は、各ＬＢＴ失敗時に、または指定されたもしくは設定された期間内の指定さ
れたもしくは設定された数のＬＢＴ失敗時に、延長され得る。例えば、期間は、現在のＭ
ＡＣ ＰＴの最大閾値あってもよい。ＭＡＣ ＰＣまたはＭＡＣ ＰＴの最大閾値は、指
定されたまたは設定された連続数のＬＢＴ失敗時に延長され得る。ＭＡＣ ＰＣまたはＭ
ＡＣ ＰＴが指定されたまたは設定されたＥＭＴに到達すると、ＭＡＣ ＰＣまたはＭＡ
Ｃ ＰＴの最大閾値は延長されなくなり得る。これにより、ＭＡＣ手順が失敗したと見な
し得る。

【0070】

ＭＡＣ手順はまた、手順が実行される頻度を制御するために使用されるタイマを有して
もよい。これらのタイマは、禁止タイマとしてとして知られ得る。いくつかのＭＡＣ手順
が実行されると、禁止タイマは、その手順が再び実行されることが許される最も早い時間
を設定する。ＭＡＣ手順は現在のところ、手順が実行されるときにこれらのタイマを設定
する。これに対処するために、複数の方法またはシステムが使用され得る。例えば、１）
禁止タイマは、手順の実行時に設定されなくてもよく、ＬＢＴ成功または失敗によって設
定されたりされなかったりし得る。ＭＡＣ手順に関連付けられた送信のＬＢＴ成功時のみ
、禁止タイマを設定すべきである。ＬＢＴ手順が成功するまでに時間がかかることがある
。この場合、禁止タイマの開始は、ＭＡＣ手順が実行されたときに対して遅延し得る。こ
れは、ＭＡＣ手順が実行される頻度が適切に制限されることを確実にするために必要な場
合がある。または、２）ＭＡＣ手順の実行時に設定され得る禁止タイマは、ＭＡＣ手順に
関連付けられた送信に対するＬＢＴ失敗表示が受信された場合にクリアされる。ＬＢＴ手
順によって送信が遅延する場合、禁止タイマは、ＭＡＣ手順が実行されてからＬＢＴ成功
が判定されるまでの時間を考慮するように延長され得る。

【0071】

（スケジューリングおよび送信機会の損失）
ＭＡＣ手順はまた、ダウンリンク割り当ておよびアップリンクグラントも考慮され得る
。ＬＢＴ失敗によって、ダウンリンク割り当ておよびアップリンクグラントが損失するこ
とがある。ＮＢがＬＢＴ失敗を判定した場合、ＰＤＣＣＨスケジューリング機会は損失し
得る。また、ＰＤＣＣＨスケジューリングを受信しているにも関わらず、ＵＥがＬＢＴ失
敗と判定した場合、アップリンク送信機会は損失する。

【0072】

設定されたモニタリング期間内にダウンリンク割り当てまたはアップリンクグラントを
受信しないことがある場合、複数のＭＡＣ手順がアクションを実行する。ＬＢＴ失敗また
はＬＢＴ成功は、ダウンリンク割り当ておよびアップリンクグラントを受信しないことの
ＭＡＣ手順基準に考慮され得る。アップリンクまたはダウンリンクＬＢＴの成功、失敗に
加えて、さらなるＬＢＴ手順情報がＭＡＣ手順に提供されてもよい。ＬＢＴの成功もしく
は失敗の表示に加えて、またはこれに含まれる、クリアチャネル評価（ＣＣＡ）の期間、
選択された最大チャネル占有時間（ＭＣＯＴ）、選択されたコンテンションウィンドウサ
イズ（ＣＷＳ）、または他のタイミング情報がＭＡＣに提供され、ダウンリンクおよびア
ップリンク送信機会の適切な判定が可能になる。ＭＣＯＴ、ＣＷＳ、または他のタイミン
グは、選択されたタイミングを表すチャネルアクセス優先度クラス（ＣＡＰＣ）または別
のインデックスによって特定され得る。

【0073】

設定されたモニタリング期間中に、ダウンリンク割り当てもしくはアップリンクグラン
トを受信し得ない場合、ＬＢＴ失敗が検出される場合、またはＬＢＴ成功が検出されない
場合は、複数のオプションが考慮され得る。
・モニタリング期間中にＬＢＴ成功が検出されなかった場合は、ＭＡＣ手順によるアクシ
ョンは実行されないことがある。
・モニタリング期間内に、ＬＢＴ成功または連続ＬＢＴ成功検出の設定された最小閾値に
到達しない場合、ＭＡＣ手順によるアクションは実行されないことがある。
・モニタリング期間中にＬＢＴ失敗が検出された場合、ＭＡＣ手順によるアクションは実
行されないことがある。
・モニタリング期間内に、ＬＢＴ失敗または連続ＬＢＴ失敗の設定された最大閾値に達し
た場合は、ＭＡＣ手順によるアクションは実行されないことがある。
・アップリンクまたはダウンリンク送信機会の数もしくは期間は、ＣＣＡ、ＭＣＯＴ、Ｃ
ＷＳ、または他のタイミング情報からより正確に判定され得る。

【0074】

ＭＡＣ手順によって実行されないアクションとは、設定されたモニタリング期間中にダ
ウンリンク割り当てまたはアップリンクグラントが受信されない場合に、現在指定されて
いるＭＡＣ手順によって行われていた可能性のあるアクションである。例えば、
・ＢＷＰ非アクティブタイマの実行中にＬＢＴ失敗が検出された場合、またはＬＢＴ成功
が検出されなかった場合は、この期間中にダウンリンク割り当てまたはアップリンクグラ
ントが受信されなかった場合でも、初期またはデフォルトＢＷＰへのＢＷＰ切り替えは実
行されない。
・その間にＤＲＸアクティブタイムＬＢＴ失敗が検出された場合、またはＬＢＴ成功が検
出されなかった場合は、この期間にダウンリンク割り当てまたはアップリンクグラントが
受信されなかった場合でも、ＤＲＸ非アクティブがリセットされ得る。

【0075】

ＬＢＴ失敗によりアップリンク送信ができない場合も、ＭＡＣ手順を考慮する必要があ
り得る。ＭＡＣ手順への影響は、ＬＢＴ失敗によってＰＤＣＣＨスケジューリング機会が
損失した場合と同じである。ＭＡＣ手順は、アップリンクグラントが受信されない場合、
または送信可能なデータに対してアップリンクグランドが受け入れられない場合（例えば
、ＬＣＰ制限）に、ＬＢＴによるＵＬ送信失敗を、現在実行されているのと同じであると
見なし得る。例えば、ＬＢＴ失敗後のバックオフ期間中に、ＭＡＣ手順は、アップリンク
グラントが受信されない場合、または、送信可能なデータに対してアップリンクグラント
が受け入れられない場合（例えば、ＬＣＰ制限）、現在のように振る舞い得る。

【0076】

従来のＭＡＣ手順は、ＭＡＣ ＰＤＵがＰＨＹ層に提供されるとき、それが送信される
と仮定し得る。ＬＢＴを実行する場合は、必ずしもそうとは限らない。したがって、ＭＡ
Ｃ ＰＤＵ送信を参照するＭＡＣ手順では、送信がＬＢＴ成功または失敗を考慮している
ことを明確にするべきである。これは、ＭＡＣ手順内のＬＢＴ成功を参照するか、または
ＭＡＣ ＰＤＵ送信基準にＬＢＴ成功が含まれることを明確にすることによって達成され
得る。

【0077】

ＭＡＣ ＰＤＵの多重化およびアセンブリが再実行されたときに、トリガが再評価され
、報告された値が再計算されるように、ＭＡＣ ＣＥは回復して保存されるか、またはこ
れらのＭＡＣ ＣＥをトリガしたイベントが復元され得る。

【0078】

（特定のＭＡＣ手順へのＮＲ－Ｕ ＬＢＴの影響）
（特定のＭＡＣ手順へのＮＲ－Ｕ ＬＢＴの影響）
新しいＬＢＴ ＭＡＣ手順が導入され得る。この手順は、ＬＢＴの失敗または成功をＮ
Ｂに通知するために使用され得る。本明細書に記載されているように、ＵＥ ＭＡＣ手順
への複数の可能性のある影響が存在し得る。多くの場合、ＮＢは適切な動作のためにこれ
らのＭＡＣ手順への影響を認識することが必要な場合がある。

【0079】

ＬＢＴ失敗によって影響を受ける各ＵＥ ＭＡＣ手順は、それぞれのＭＡＣ手順に対す
るＵＥとＮＢ間の協調を維持するために、ＮＢへの効果をシグナリングする可能性がある
。しかし、これには、多くのＭＡＣ手順にさらなる複雑さを導入する必要があり得る。

【0080】

例示的な方法は、ＮＢがＬＢＴ情報を考慮し、ＬＢＴ動作によってこれらの手順の変更
された振る舞いを実現することにより、他のＭＡＣ手順に対するその振る舞いを調整でき
るように、ＮＢにＬＢＴ状態（例えば、成功または失敗）を示す新しい個別のＭＡＣ手順
を定義することである。

【0081】

したがって、ＵＥ ＰＨＹ層のＬＢＴ成功または失敗表示がＭＡＣに提供される場合が
ある。ＰＨＹ層は、ＭＡＣ層とＰＨＹ層との間でシグナリングされるプリミティブの量を
制限するために、何らかの前処理を行うことが可能である。新しいＬＢＴ ＭＡＣ手順で
は、これらのＬＢＴ表示を統合して、リッスンビフォートーク報告（ＬＢＴＲ）ＭＡＣ制
御要素（Control Element：ＣＥ）を生成し得、これにより、一定期間のＬＢＴ失敗また
は成功に関する情報を提供し得る。ＵＥ ＰＨＹ層は、ＬＢＴ成功または失敗表示に加え
て、ＬＢＴタイミング情報をＭＡＣ層に提供してもよい。例えば、ＬＢＴタイミング情報
は、ＣＣＡ期間を含み、ＭＣＯＴまたはＣＷＳ期間を選択し得る。

【0082】

ＬＢＴＲは、ＵＬおよびＤＬのＬＢＴ失敗を別々に提供し得る。ＵＬ ＬＢＴ失敗はＮ
Ｂにとって未知であることがあり、ＭＡＣ手順の協調を維持するためにシグナリングする
必要がある。しかし、ＵＥが認識しているＤＬ ＬＢＴ失敗もＮＢにとって有用である可
能性がある。なぜなら、ＵＥにシグナリングされるか、または別の方法でＵＥによって検
出されるＤＬ ＬＢＴ失敗がＵＥによって実現されたとＮＢが想定できないことがあるか
らである。ＵＥがＮＢ ＤＬ ＬＢＴ失敗もしくは成功表示を逃したか、または受信に失
敗した可能性がある。

【0083】

ＬＢＴＲ手順は、ＬＢＴＲを送信する場合につながる手順を開始するために１つ以上の
トリガを必要とすることがある。トリガには、以下の１つ以上の方法が含まれ得る。第１
の方法では、閾値に達するＬＢＴ失敗が、トリガとなり得る。ＲＲＣが設定したＬＢＴ失
敗閾値が存在し得る。この閾値は、既知の期間にわたるＬＢＴ失敗の閾値数、または連続
ＬＢＴ失敗の閾値数であってもよい。報告の緊急度は、サポートされるトラフィックのタ
イプに依存することがあるため、これらのパラメータが設定可能である必要があり得る。
第２の方法では、トリガは、他のＭＡＣ手順に対するある種の影響が、適切な動作のため
にＮＢによって認識される必要があるその手順の動作変化をもたらすときであり得る。例
えば、アクティブタイムまたはＤＲＸサイクルに影響するＤＲＸ動作の変更である。この
場合、ＭＡＣ ＤＲＸ手順がＬＢＴＲをトリガする。第３の方法では、トリガは、ＲＲＣ
が設定した周期的なＬＢＴＲに基づき得る。第４の方法では、トリガは、ＬＢＴＲの頻度
を制限するために導入されるＬＢＴＲ禁止タイマに基づき得る。

【0084】

ＬＢＴＲ手順は、設定されたＬＢＴＲモニタリング期間にわたってＬＢＴ失敗または成
功をカウントし得る。例えば、
・ＬＢＴＲモニタリング期間内、ＬＢＴ失敗カウントが、設定されたＬＢＴ失敗カウント
より大きい場合、ＬＢＴＲがトリガされ得る。
・ＬＢＴＲモニタリング期間内、ＬＢＴ成功カウントが、設定されたＬＢＴ成功最小値未
満の場合、ＬＢＴＲがトリガされ得る。

【0085】

設定されたＬＢＴＲモニタリング期間にわたって、ＬＢＴＲ手順は、連続ＬＢＴ失敗ま
たは成功をカウントし得る。
・ＬＢＴＲモニタリング期間内、連続ＬＢＴ失敗カウントが、設定されたＬＢＴ失敗カウ
ントより大きい場合、ＬＢＴＲがトリガされ得る。
・ＬＢＴＲモニタリング期間内、連続ＬＢＴ成功カウントが、設定された連続ＬＢＴ成功
最小値未満の場合、ＬＢＴＲがトリガされ得る。

【0086】

他のＭＡＣ手順がＬＢＴＲをトリガする場合、これは、ＬＢＴＲ保留表示を設定するこ
とによってであり得る。ＬＢＴＲ保留表示は、後でＭＡＣ ＰＤＵ多重化アセンブリ中に
チェックされ、ＬＢＴＲ ＭＡＣ ＣＥが構築されることを確認する。

【0087】

ＬＢＴＲには、以下の情報が含まれ得る。
・最後のＬＢＴＲ以降のＬＢＴ失敗または成功のカウント
・最後のＬＢＴＲ以降、ＬＢＴ失敗または連続ＬＢＴ失敗が、設定されたＬＢＴ失敗の最
大閾値を超えた回数
・最後のＬＢＴＲ以降、ＬＢＴ成功カウントまたは連続ＬＢＴ成功カウントが、設定され
た連続ＬＢＴ成功最小値未満の回数
・ＵＬ ＬＢＴ失敗に加えて、ＵＥによって検出されたＤＬ ＬＢＴ失敗も報告されるこ
とがある
・ＬＢＴＲをトリガしたＭＡＣ手順
・ＬＢＴＲ ＰＤＵがいつ構築されるかに関連したタイムスタンプ。
・ＣＣＡ、ＭＣＯＴ、またはＣＷＳ情報

【0088】

ＰＨＹ層またはＲＲＣ層によって同様の動作が提供されてもよく、ＰＨＹ層またはＲＲ
Ｃ層シグナリングを使用して同様の情報をＮＢに伝達してもよいことに留意すべきである
。

【0089】

ＲＲＣは、ＵＥ内に、ＬＢＴＲ ＭＡＣ ＣＥに指定された論理チャネルにマッピング
されたチャネルアクセス優先度クラスの優先度を設定してもよい。あるいは、アクセス優
先度クラスを最も優先度の高いチャネルアクセス優先度クラスとして指定してもよい。Ｌ
ＢＴＲ手順はまた、一般的なＬＢＴ状態判定手順を含んでもよく、または独立したＬＢＴ
状態手順がＬＢＴＲおよび他のＭＡＣ手順によって利用されてもよい。この方法は、各Ｍ
ＡＣ手順に導入される複雑さを最小限にする。例えば、各ＭＡＣ手順がその手順に影響を
及ぼすＬＢＴ失敗をカウントするのではなく、ＬＢＴ状態がチェックされるだけである。

【0090】

ＬＢＴ失敗の総数がカウントされることがあり、これは、指定されたまたは設定された
期間内であり得る。あるいは、ＬＢＴ ＦＣは連続ＬＢＴ失敗をカウントしてもよく、Ｌ
ＢＴが成功するとＬＢＴ ＦＣはゼロにリセットされる。ＬＢＴ失敗がカウントされ得る
期間は、時間のスライディングウィンドウであってもよい。ＬＢＴ失敗カウンタが指定さ
れたまたは設定された閾値を超過する場合、ＬＢＴ状態は失敗したと見なされる。指定も
しくは設定された数のＬＢＴ失敗が受信されなかった場合、または指定もしくは設定され
た数のＬＢＴ成功の表示が受信される場合、ＬＢＴ状態は成功したと見なされる。ＭＡＣ
手順は、ＭＡＣ手順に関連付けられた個々のＬＢＴ失敗をカウントするのではなく、ＬＢ
Ｔ状態をチェックすることがある。ＭＡＣ手順では、ＬＢＴ状態に従ってカウンタおよび
タイマを調整し得る。例えば、ＭＡＣ手順はカウンタおよびタイマを延長し得、またはＬ
ＢＴ状態に応じてタイマおよびカウンタが最大閾値に達したと見なし得る。ＬＢＴ状態は
、より高い層に示されることもある。例えば、ＲＲＣ手順を行う。

【0091】

（ＢＷＰ動作手順）
ＢＷＰ動作手順の以下の修正は、ＮＲ－ＵにおけるＬＢＴ動作の影響を考慮に入れても
よい。

【0092】

ＬＢＴ失敗により、ＢＷＰ非アクティブタイマの期間中にダウンリンク割り当ておよび
アップリンクグラントをブロックすることがある。この場合、ＢＷＰをデフォルトまたは
初期ＢＷＰ（単数または複数）への切り替えを行うことは不適切であり得る。

【0093】

ＢＷＰ非アクティブタイマが動作している間にＬＢＴ失敗と判定された場合、アクティ
ブなＤＬ ＢＷＰに関連付けられたＢＷＰ非アクティブタイマは延長されるべきである。
これは、ＬＢＴ失敗によってダウンリンク割り当ておよびアップリンクグラントが損失し
得る場合に、デフォルトまたは初期ＢＷＰへのＢＷＰ切り替えが実行されないことを確実
にするために、必要な場合がある。デフォルトまたは初期ＢＷＰへのＢＷＰ切り替えは、
ＢＷＰ非アクティビティタイマの実行中に、実際には送信するデータがない場合にのみ実
行されるべきである。本明細書における実施例は、ＭＡＣ仕様３ＧＰＰ ＴＳ ３８．３
２１、（ＮＲ）、メディアアクセス制御（ＭＡＣ）プロトコル仕様、Ｖ１５．２．０を参
照してもよい（また、本明細書では［２］として参照される）。例示的な修正の多くは、
本明細書において下線が引かれている。例えば、ＭＡＣ仕様を以下のように修正してもよ
い。
ｂｗｐ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒが設定されている場合、ＭＡＣエンティティは
、アクティブ化された各サービングセルに対して、以下であるものとする。
１＞ｄｅｆａｕｌｔＤｏｗｎｌｉｎｋＢＷＰが設定されていて、アクティブなＤＬ ＢＷ
ＰがｄｅｆａｕｌｔＤｏｗｎｌｉｎｋＢＷＰによって示されたＢＷＰでない場合、または
、
１＞ｄｅｆａｕｌｔＤｏｗｎｌｉｎｋＢＷＰが設定されておらず、アクティブなＤＬ Ｂ
ＷＰがｉｎｉｔｉａｌＤｏｗｎｌｉｎｋＢＷＰでない場合、
２＞ダウンリンクの割り当てもしくはアップリンクグラントを示すＣ－ＲＮＴＩもしくは
ＣＳ－ＲＮＴＩ宛てのＰＤＣＣＨが、アクティブなＢＷＰで受信された場合、または、
２＞ダウンリンクの割り当てもしくはアップリンクグラントを示すＣ－ＲＮＴＩもしくは
ＣＳ－ＲＮＴＩ宛てのＰＤＣＣＨが、アクティブなＢＷＰに対して受信された場合、また
は、
２＞ＭＡＣ ＰＤＵが、設定されたアップリンクグラントで送信された場合もしくは設定
されたダウンリンク割り当てで受信された場合、または、
２＞アクティブなＢＷＰでＬＢＴ失敗が検出された場合、
３＞このサービングセルに関連付けられた現行のランダムアクセス手順がない場合、また
は、
３＞Ｃ－ＲＮＴＩ宛てのこのＰＤＣＣＨの受信時に、このサービングセルに関連付けられ
た現行のランダムアクセス手順が正常に完了した場合（例えば、［２］の５．１．４節お
よび５．１．５節に関して規定されたとおり）、
４＞アクティブなＤＬ ＢＷＰに関連付けられたｂｗｐ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅ
ｒを起動または再起動する。

【0094】

この基準はまた、ＢＷＰ非アクティブが実行されている間のＬＢＴ成功検出に基づいて
いてもよい。例えば、
ｂｗｐ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒが設定されている場合、ＭＡＣエンティティは
、アクティブ化された各サービングセルに対して、以下であるものとする。
１＞ｄｅｆａｕｌｔＤｏｗｎｌｉｎｋＢＷＰが設定されていて、アクティブなＤＬ ＢＷ
ＰがｄｅｆａｕｌｔＤｏｗｎｌｉｎｋＢＷＰによって示されたＢＷＰでない場合、または
、
１＞ｄｅｆａｕｌｔＤｏｗｎｌｉｎｋＢＷＰが設定されておらず、アクティブなＤＬ Ｂ
ＷＰがｉｎｉｔｉａｌＤｏｗｎｌｉｎｋＢＷＰでない場合、
２＞ダウンリンクの割り当てもしくはアップリンクグラントを示すＣ－ＲＮＴＩもしくは
ＣＳ－ＲＮＴＩ宛てのＰＤＣＣＨが、アクティブなＢＷＰで受信された場合、または、
２＞ダウンリンクの割り当てもしくはアップリンクグラントを示すＣ－ＲＮＴＩもしくは
ＣＳ－ＲＮＴＩ宛てのＰＤＣＣＨが、アクティブなＢＷＰに対して受信された場合、また
は、
２＞ＭＡＣ ＰＤＵが、設定されたアップリンクグラントで送信された場合もしくは設定
されたダウンリンク割り当てで受信された場合、または、
２＞アクティブなＢＷＰでＬＢＴ成功が検出されなかった場合、
３＞このサービングセルに関連付けられた現行のランダムアクセス手順がない場合、また
は、
３＞Ｃ－ＲＮＴＩ宛てのこのＰＤＣＣＨの受信時に、このサービングセルに関連付けられ
た現行のランダムアクセス手順が正常に完了した場合（例えば、［２］の５．１．４節お
よび５．１．５節に関して規定されたとおり）、
４＞アクティブなＤＬ ＢＷＰに関連付けられたｂｗｐ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅ
ｒを起動または再起動する。

【0095】

ＬＢＴ失敗は、単一のインスタンスではないことがある。ＢＷＰ非アクティブタイマが
実行している間の、複数のＬＢＴ失敗または成功の検出であり得る。また、本明細書に示
されるように、ＬＢＴ失敗または成功は、アップリンクＬＢＴまたはダウンリンクＬＢＴ
の両方を参照する。

【0096】

一定期間のＬＢＴ失敗もしくはＬＢＴ成功をカウントする、または一定期間の連続ＬＢ
Ｔ失敗もしくは連続ＬＢＴ成功をカウントするように手順を定義してもよい。ＬＢＴ失敗
もしくは連続ＬＢＴ失敗が、設定された最大ＬＢＴ失敗閾値を超えた場合、またはＬＢＴ
成功もしくは連続ＬＢＴ成功が、設定された最小ＬＢＴ成功閾値未満であり得る場合にの
み、ＢＷＰ非アクティブタイマが再起動される。例えば、ＭＡＣ仕様を以下のように修正
してもよい。
ｂｗｐ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒが設定されている場合、ＭＡＣエンティティ
は、アクティブ化された各サービングセルに対して、以下であるものとする。
１＞ｄｅｆａｕｌｔＤｏｗｎｌｉｎｋＢＷＰが設定されていて、アクティブなＤＬ ＢＷ
ＰがｄｅｆａｕｌｔＤｏｗｎｌｉｎｋＢＷＰによって示されたＢＷＰでない場合、または
、
１＞ｄｅｆａｕｌｔＤｏｗｎｌｉｎｋＢＷＰが設定されておらず、アクティブなＤＬ Ｂ
ＷＰがｉｎｉｔｉａｌＤｏｗｎｌｉｎｋＢＷＰでない場合、
２＞ダウンリンクの割り当てもしくはアップリンクグラントを示すＣ－ＲＮＴＩもしくは
ＣＳ－ＲＮＴＩ宛てのＰＤＣＣＨが、アクティブなＢＷＰで受信された場合、または、
２＞ダウンリンクの割り当てもしくはアップリンクグラントを示すＣ－ＲＮＴＩもしくは
ＣＳ－ＲＮＴＩ宛てのＰＤＣＣＨが、アクティブなＢＷＰに対して受信された場合、また
は、
２＞ＭＡＣ ＰＤＵが、設定されたアップリンクグラントで送信された場合もしくは設定
されたダウンリンク割り当てで受信された場合、または、
２＞ＬＢＴ失敗カウントが、アクティブなＢＷＰでＬＢＴ失敗閾値を超えた場合、
３＞このサービングセルに関連付けられた現行のランダムアクセス手順がない場合、また
は、
３＞Ｃ－ＲＮＴＩ宛てのこのＰＤＣＣＨの受信時に、このサービングセルに関連付けられ
た現行のランダムアクセス手順が正常に完了した場合（例えば、［２］の５．１．４節お
よび５．１．５節に関して規定されたとおり）、
４＞アクティブなＤＬ ＢＷＰに関連付けられたｂｗｐ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅ
ｒを起動または再起動して、
４＞ＬＢＴ失敗カウントをリセットする。

【0097】

上記の手順において、ＬＢＴ失敗が検出されたとは、ＢＷＰ非アクティブタイマが動作
している期間、アクティブなＤＬ ＢＷＰ上でＢＷＰ切り替え用のＰＤＣＣＨを受信した
とき、または、アクティブなＢＷＰ上もしくはＢＷＰ用のアップリンクグラントのＰＤＣ
ＣＨを受信したとき、または設定されたグラントのためにＭＡＣ ＰＤＵを送信もしくは
受信したときから、ＢＷＰ非アクティブタイマが満了する時点までの期間に適用されるこ
とに留意すべきである。

【0098】

ＢＷＰ非アクティブタイマは、初期設定値とは異なる期間だけ延長され得る。ＢＷＰ非
アクティブタイマが延長される期間は、別の設定値であってもよく、または検出されたＬ
ＢＴの失敗もしくは判定された成功の量に応じた値であってもよい。

【0099】

また、ＬＢＴ失敗により、設定されたＢＷＰ間の切り替えがトリガされることがある。
ＬＢＴ失敗は、単一のインスタンスではないことがある。指定されたまたは設定された期
間内の複数のＬＢＴ失敗または成功の検出であってもよい。また、本明細書に示されるよ
うに、ＬＢＴ失敗または成功は、アップリンクＬＢＴまたはダウンリンクＬＢＴを参照す
ることがある。

【0100】

一定期間のＬＢＴ失敗もしくはＬＢＴ成功をカウントする、または一定期間の連続ＬＢ
Ｔ失敗もしくは連続ＬＢＴ成功をカウントするように手順を定義してもよい。ＬＢＴ失敗
もしくは連続ＬＢＴ失敗が設定された最大ＬＢＴ失敗閾値を超えた場合、またはＬＢＴ成
功もしくは連続ＬＢＴ成功が設定された最小ＬＢＴ成功閾値未満である場合にのみ、アク
ティブなＢＷＰは、別の設定されたアクティブなＢＷＰに切り替えられる。

【0101】

また、ＵＥが初期もしくはデフォルトＢＷＰに決して戻らないように、ＢＰＷ非アクテ
ィブタイマを大幅に延長すること、またはＬＢＴ失敗により非アクティブタイマを無期限
に延長することを回避するために必要な場合がある。その場合、ＢＷＰ非アクティブタイ
マの再起動は、指定されたまたは設定された最大値に制限され得る。例えば、ＭＡＣ仕様
を以下のように修正してもよい。
１＞アクティブなＢＷＰで、ＢＷＰ－Ｉｎａｃｔｉｖｉｔｙ－ＬＢＴ－Ｆａｉｌｕｒｅ－
Ｃｏｕｎｔ＞ＢＷＰ－Ｉｎａｃｔｉｖｉｔｙ－ＬＢＴ Ｆａｉｌｕｒｅ Ｔｈｒｅｓｈｏ
ｌｄである場合、および、
１＞ＬＢＴ－ＢＷＰ－ＩｎａｃｔｉｖｉｔｙＲｅｓｔａｒｔＣｏｕｎｔ＜＝ＬＢＴ－ＢＷ
Ｐ－Ｉｎａｃｔｉｖｉｔｙ－Ｒｅｓｔａｒｔ－Ｔｈｒｅｓｈｏｌｄである場合、
２＞ＢＷＰ－Ｉｎａｃｔｉｖｉｔｙ－ＬＢＴ－Ｆａｉｌｕｒｅ－Ｃｏｕｎｔを０に設定し
て、
２＞ＬＢＴ－ＢＷＰ－ＩｎａｃｔｉｖｉｔｙＲｅｓｔａｒｔＣｏｕｎｔを１だけインクリ
メントして、
２＞アクティブなＤＬ ＢＷＰに関連付けられたｂｗｐ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅ
ｒを起動または再起動する。

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

ＬＢＴ ＢＷＰ非アクティブ再起動閾値を超えた場合、以下のアクションを実行しても
よい。
１＞ＬＢＴ－ＢＷＰ－ＩｎａｃｔｉｖｉｔｙＲｅｓｔａｒｔＣｏｕｎｔ＞ＬＢＴ－ＢＷＰ
－Ｉｎａｃｔｉｖｉｔｙ－Ｒｅｓｔａｒｔ－Ｔｈｒｅｓｈｏｌｄである場合、
２＞デフォルトまたは初期ＢＷＰへのＢＷＰ切り替えが実行されて、
２＞ＢＷＰを特定する表示が上位層に送信されて、
２＞ＳＣｅｌｌが非アクティブ化される。

【0102】

（ランダムアクセス手順）
（ランダムアクセス応答受信）
ランダムアクセス応答受信手順の以下の修正は、ＮＲ－ＵにおけるＬＢＴの影響を考慮
に入れてもよい。

【0103】

ＲＡ応答ウィンドウが満了しても、プリアンブル送信以降にＬＢＴ失敗が検出された場
合、ＲＡ応答ウィンドウを延長し得る。これは、ＮＢがプリアンブル送信を受信していて
も、ＬＢＴ失敗によりランダムアクセス応答が遅延している場合に必要になり得る。ＮＢ
が送信機会を逃したことをＵＥが検出するとき、ＲＡ応答ウィンドウを延長し得る。

【0104】

例えば、ＭＡＣ仕様を以下のように修正してもよい。
１＞ＲＡＣＨ－ＣｏｎｆｉｇＣｏｍｍｏｎに設定されているｒａ－ＲｅｓｐｏｎｓｅＷｉ
ｎｄｏｗが満了し、送信されたＰＲＥＡＭＢＬＥ＿ＩＮＤＥＸに一致するランダムアクセ
スプリアンブル識別子を含むランダムアクセス応答を受信していない場合、
１＞ＢｅａｍＦａｉｌｕｒｅＲｅｃｏｖｅｒｙＣｏｎｆｉｇに設定されたｒａ－Ｒｅｓｐ
ｏｎｓｅＷｉｎｄｏｗが満了した場合、およびＣ－ＲＮＴＩ宛てのＰＤＣＣＨを受信して
いない場合、
２＞ＬＢＴ失敗が検出された場合、
３＞ＭＡＣエンティティによってビーム障害回復要求のための競合なしランダムアクセス
プリアンブルが送信された場合、
４＞ＢｅａｍＦａｉｌｕｒｅＲｅｃｏｖｅｒｙＣｏｎｆｉｇに設定したｒａ－Ｒｅｓｐｏ
ｎｓｅＷｉｎｄｏｗを再起動して、
４＞ｒａ－ＲｅｓｐｏｎｓｅＷｉｎｄｏｗが動作している間、Ｃ－ＲＮＴＩで特定される
ビーム障害回復要求に対する応答をＳｐＣｅｌｌのＰＤＣＣＨで監視し、
３＞さもなければ、
４＞ＲＡＣＨ－ＣｏｎｆｉｇＣｏｍｍｏｎに設定されたｒａ－ＲｅｓｐｏｎｓｅＷｉｎｄ
ｏｗを再起動して、
４＞ｒａ－ＲｅｓｐｏｎｓｅＷｉｎｄｏｗが実行されている間、ＲＡ－ＲＮＴＩによって
特定されるランダムアクセス応答（単数または複数）に対するＳｐＣｅｌｌのＰＤＣＣＨ
を監視し、
２＞さもなければ（ＬＢＴ失敗は検出されず）、
３＞ランダムアクセス応答の受信が成功しなかったと見なす。

【0105】

上記の手順において、ＬＢＴ失敗が検出されたとは、ＲＡ応答ウィンドウが動作してい
る期間、プリアンブル送信から、プリアンブル送信後ＲＡ応答ウィンドウが最初に満了す
る時点までの期間、またはＬＢＴ検出によりＲＡ競合解決タイマが満了して最後に再起動
してから、次のｒａ－ＲｅｓｐｏｎｓｅＷｉｎｄｏｗが満了するまでの期間に適用される
ことに留意すべきである。

【0106】

あるいは、ＬＢＴ失敗またはＬＢＴ成功をカウントするように手順を定義してもよい。
ＬＢＴ失敗が、設定された最大ＬＢＴ失敗閾値を超えた場合、またはＬＢＴ成功が、設定
された最小ＬＢＴ成功閾値未満であり得る場合にのみ、ＲＡ応答ウィンドウが再起動され
る。

【0107】

あるいは、ＲＡ応答ウィンドウは、ＢｅａｍＦａｉｌｕｒｅＲｅｃｏｖｅｒｙＣｏｎｆ
ｉｇまたはＲＡＣＨ－ＣｏｎｆｉｇＣｏｍｍｏｎに設定された値とは異なる期間だけ延長
され得る。ＲＡ応答ウィンドウが延長される期間は、別の設定値であってもよく、または
検出されたＬＢＴ失敗もしくは判定された成功の量に応じた値であってもよい。また、ラ
ンダムアクセス応答受信が成功しなかったとＵＥが決して判定しないように、ＬＢＴの失
敗によるランダムアクセス応答を大幅に延長すること、または無期限に延長することを回
避する必要がある場合もある。その場合、ＲＡ応答ウィンドウの再起動は、指定されたま
たは設定された最大値に制限され得る。例えば、ＭＡＣ仕様を以下のように修正してもよ
い。
１＞ＲＡ－ＲｅｓｐｏｎｓｅＷｉｎｄｏｗ－ＬＢＴ－Ｆａｉｌｕｒｅ－Ｃｏｕｎｔ＞ＲＡ
－ＲｅｓｐｏｎｓｅＷｉｎｄｏｗ－ＬＢＴ－ＦａｉｌｕｒｅＴｈｒｅｓｈｏｌｄである場
合、および、
１＞ＬＢＴ－ＲＡ－ＲｅｓｐｏｎｓｅＷｉｎｄｏｗＲｅｓｔａｒｔＣｏｕｎｔ＜＝ＬＢＴ
－ＲＡ－ＲｅｓｐｏｎｓｅＷｉｎｄｏｗ－Ｒｅｓｔａｒｔ－Ｔｈｒｅｓｈｏｌｄである場
合、
２＞ＲＡ－ＲｅｓｐｏｎｓｅＷｉｎｄｏｗ－ＬＢＴ－Ｆａｉｌｕｒｅ－Ｃｏｕｎｔを０に
設定して、
２＞ＬＢＴ－ＲＡ－ＲｅｓｐｏｎｓｅＷｉｎｄｏｗＲｅｓｔａｒｔＣｏｕｎｔを１だけイ
ンクリメントして、
２＞ｒａ－ＲｅｓｐｏｎｓｅＷｉｎｄｏｗを起動または再起動する。

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

ＲＡ－ＲｅｓｐｏｎｓｅＷｉｎｄｏｗ－ＬＢＴ－ＦａｉｌｕｒｅＴｈｒｅｓｈｏｌｄを
超えた場合、以下のアクションを実行してもよい。
１＞ＬＢＴ－ＲＡ－ＲｅｓｐｏｎｓｅＷｉｎｄｏｗＲｅｓｔａｒｔＣｏｕｎｔ＞ＬＢＴ－
ＲＡ－ＲｅｓｐｏｎｓｅＷｉｎｄｏｗ－Ｒｅｓｔａｒｔ－Ｔｈｒｅｓｈｏｌｄである場合
、
２＞ランダムアクセス応答の受信が成功しなかったと見なす。

【0108】

以下に別の例を示す。ＬＢＴが失敗した場合、プリアンブル送信カウンタをインクリメ
ントすべきではないと説明してきた。例えば、
１＞ＲＡＣＨ－ＣｏｎｆｉｇＣｏｍｍｏｎに設定されているｒａ－ＲｅｓｐｏｎｓｅＷｉ
ｎｄｏｗが満了した場合、および送信されたに一致するランダムアクセスプリアンブル識
別子を含むランダムアクセス応答を受信していない場合、
１＞ＢｅａｍＦａｉｌｕｒｅＲｅｃｏｖｅｒｙＣｏｎｆｉｇに設定されたｒａ－Ｒｅｓｐ
ｏｎｓｅＷｉｎｄｏｗが満了した場合、およびＣ－ＲＮＴＩ宛てのＰＤＣＣＨを受信して
いない場合、
２＞ランダムアクセス応答の受信が成功しなかったと見なし、
２＞ＬＢＴ失敗が検出されなかった場合、
３＞ＰＲＥＡＭＢＬＥ＿ＴＲＡＮＳＭＩＳＳＩＯＮ＿ＣＯＵＮＴＥＲを１だけインクリメ
ントして、
３＞ＰＲＥＡＭＢＬＥ＿ＴＲＡＮＳＭＩＳＳＩＯＮ＿ＣＯＵＮＴＥＲ＝ｐｒｅａｍｂｌｅ
ＴｒａｎｓＭａｘ＋１である場合、
４＞ＳｐＣｅｌｌでランダムアクセスプリアンブルが送信された場合、
５＞ランダムアクセスの問題を上位層に示し、
４＞ＳＩ要求に対してこのランダムアクセス手順がトリガされた場合、
５＞ランダムアクセス手順が不成功に終わったと見なし、
３＞さもなければ、ＳＣｅｌｌでランダムアクセスプリアンブルが送信された場合、
４＞ランダムアクセス手順が不成功に終わったと見なす。

【0109】

プリアンブル送信カウンタは、ＬＢＴ失敗の検出時にデクリメントされてもよい。例え
ば、
１＞物理層に、選択されたＰＲＡＣＨ、対応するＲＡ－ＲＮＴＩ（利用可能な場合）、Ｐ
ＲＥＡＭＢＬＥ＿ＩＮＤＥＸ、および、ＰＲＥＡＭＢＬＥ＿ＲＥＣＥＩＶＥＤ＿ＴＡＲＧ
ＥＴ＿ＰＯＷＥＲを使用して、ランダムアクセスプリアンブルを送信するように指示して
、
１＞ＬＢＴ失敗が検出された場合、
２＞ＰＲＥＡＭＢＬＥ＿ＴＲＡＮＳＭＩＳＳＩＯＮ＿ＣＯＵＮＴＥＲを１だけデクリメン
トする。

【0110】

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

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

【0111】

ＲＡ－ＰｒｅａｍｂｌｅＴｒａｎｓｍｉｓｓｉｏｎ－ＬＢＴ－ＦａｉｌｕｒｅＴｈｒｅ
ｓｈｏｌｄを超えた場合、以下のアクションを実行してもよい。１）上位層にランダムア
クセスの問題を示す、または、２）ランダムアクセス手順が不成功に終わったと見なす。

【0112】

あるいは、ＭＡＣ仕様を以下のように修正してもよい。
１＞ＰｒｅａｍｂｌｅＴｒａｎｓｍｉｓｓｉｏｎ－ＬＢＴ－Ｆａｉｌｕｒｅが検出された
場合、
２＞ＲＡ－ＰｒｅａｍｂｌｅＴｒａｎｓｍｉｓｓｉｏｎ－ＬＢＴ－Ｆａｉｌｕｒｅ－Ｃｏ
ｕｎｔをインクリメントして、
２＞ＲＡ－ＰｒｅａｍｂｌｅＴｒａｎｓｍｉｓｓｉｏｎ－ＬＢＴ－Ｆａｉｌｕｒｅ－Ｃｏ
ｕｎｔ＞ＲＡ－ＰｒｅａｍｂｌｅＴｒａｎｓｍｉｓｓｉｏｎ－ＬＢＴ－ＦａｉｌｕｒｅＴ
ｈｒｅｓｈｏｌｄである場合、
３＞ＳｐＣｅｌｌでランダムアクセスプリアンブルが送信された場合、
４＞上位層にランダムアクセスの問題を示し、
３＞ＳＩ要求に対してこのランダムアクセス手順がトリガされた場合、
４＞ランダムアクセス手順が不成功に終わったと見なし、
３＞さもなければ、ＳＣｅｌｌでランダムアクセスプリアンブルが送信された場合、
４＞ランダムアクセス手順が不成功に終わったと見なす。

【0113】

（競合解決）
ランダムアクセス競合解決手順の以下の修正は、ＮＲ－ＵにおけるＬＢＴの影響を考慮
に入れてもよい。

【0114】

ＲＡ競合解決が満了しても、プリアンブル送信以降にＬＢＴ失敗が検出された場合、Ｒ
Ａ競合解決を延長し得る。これは、ＮＢがＭＳＧ３送信を受信していても、ＬＢＴ失敗に
よりＰＤＣＣＨ送信が遅延しているために必要になり得る。ＮＢがＬＢＴ失敗により送信
機会を逃したことをＵＥが検出した場合、ＲＡ競合解決タイマを延長し得る。

【0115】

例えば、ＭＡＣ仕様を以下のように修正してもよい。
１＞ｒａ－ＣｏｎｔｅｎｔｉｏｎＲｅｓｏｌｕｔｉｏｎＴｉｍｅｒが満了した場合、
２＞ＬＢＴ失敗が検出された場合、
３＞ｒａ－ＣｏｎｔｅｎｔｉｏｎＲｅｓｏｌｕｔｉｏｎＴｉｍｅｒを起動し、ＨＡＲＱ再
送信ごとにｒａ－ＣｏｎｔｅｎｔｉｏｎＲｅｓｏｌｕｔｉｏｎＴｉｍｅｒを再起動して、
３＞測定ギャップの発生の可能性に関わらず、ｒａ－ＣｏｎｔｅｎｔｉｏｎＲｅｓｏｌｕ
ｔｉｏｎＴｉｍｅｒが実行されている間、ＰＤＣＣＨを監視し、
２＞さもなければ、
３＞ＴＥＭＰＯＲＡＲＹ＿Ｃ－ＲＮＴＩを破棄して、
３＞競合解決が成功しなかったと見なす。

【0116】

上記の手順において、ＬＢＴ失敗が検出されたとは、ＲＡ競合解決タイマが動作してい
る期間、ＭＳＧ３送信から、ＭＳＧ３送信後ＲＡ競合解決タイマが最初に満了する時点ま
での期間、またはＬＢＴ検出によりＲＡ競合解決タイマが満了して最後に起動してから、
次のＲＡ競合解決タイマが満了するまでの期間に適用されることに留意すべきである。

【0117】

あるいは、ＬＢＴ失敗またはＬＢＴ成功をカウントするように手順を定義してもよい。
ＬＢＴ失敗が、設定された最大ＬＢＴ失敗閾値を超えた場合、またはＬＢＴ成功が、設定
された最小ＬＢＴ成功閾値未満であり得る場合にのみ、ＲＡ競合解決が再起動される。

【0118】

あるいは、ＲＡ競合解決タイマは、設定されたＲＡ競合解決タイマとは異なる期間だけ
延長されてもよい。ＲＡ競合解決タイマが延長される期間は、別の設定値であってもよく
、または検出されたＬＢＴの失敗もしくは判定された成功の量に応じた値であってもよい
。また、競合解決が成功しなかったとＵＥが決して判定しないように、ＲＡ競合解決タイ
マを大幅に延長すること、またはＬＢＴ失敗によりＲＡ競合解決タイマを無期限に延長す
ることを回避する必要がある場合がある。その場合、ＲＡ競合解決タイマの再起動は、指
定されたまたは設定された最大値に制限され得る。例えば、ＭＡＣ仕様を以下のように修
正してもよい。
１＞ＲＡ－ＣｏｎｔｅｎｔｉｏｎＲｅｓｏｌｕｔｉｏｎ－ＬＢＴ－Ｆａｉｌｕｒｅ－Ｃｏ
ｕｎｔ＞ＲＡ－ＣｏｎｔｅｎｔｉｏｎＲｅｓｏｌｕｔｉｏｎ－ＬＢＴ－ＦａｉｌｕｒｅＴ
ｈｒｅｓｈｏｌｄである場合、および、
１＞ＬＢＴ－ＲＡ－ＣｏｎｔｅｎｔｉｏｎＲｅｓｏｌｕｔｉｏｎＴｉｍｅｒＲｅｓｔａｒ
ｔＣｏｕｎｔ＜＝ＬＢＴ－ＲＡＣｏｎｔｅｎｔｉｏｎＲｅｓｏｌｕｔｉｏｎＲｅｓｔａｒ
ｔ－Ｔｈｒｅｓｈｏｌｄである場合、
２＞ＲＡ－ＣｏｎｔｅｎｔｉｏｎＲｅｓｏｌｕｔｉｏｎ－ＬＢＴ－Ｆａｉｌｕｒｅ－Ｃｏ
ｕｎｔを０に設定して、
２＞ＬＢＴ－ＲＡ－ＣｏｎｔｅｎｔｉｏｎＲｅｓｏｌｕｔｉｏｎＴｉｍｅｒＲｅｓｔａｒ
ｔＣｏｕｎｔを１だけインクリメントして、
２＞ｒａ－ＣｏｎｔｅｎｔｉｏｎＲｅｓｏｌｕｔｉｏｎＴｉｍｅｒを起動し、ＨＡＲＱ再
送信ごとにｒａ－ＣｏｎｔｅｎｔｉｏｎＲｅｓｏｌｕｔｉｏｎＴｉｍｅｒを再起動して、
２＞測定ギャップの発生の可能性に関わらず、ｒａ－ＣｏｎｔｅｎｔｉｏｎＲｅｓｏｌｕ
ｔｉｏｎＴｉｍｅｒが実行されている間、ＰＤＣＣＨを監視する。

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

ＲＡ－ＣｏｎｔｅｎｔｉｏｎＲｅｓｏｌｕｔｉｏｎ－ＬＢＴＲｅｓｔａｒｔＴｈｒｅｓ
ｈｏｌｄを超えた場合、以下のアクションを実行してもよい。
１＞ＬＢＴ－ＲＡ－ＣｏｎｔｅｎｔｉｏｎＲｅｓｏｌｕｔｉｏｎＴｉｍｅｒＲｅｓｔａｒ
ｔＣｏｕｎｔ＞ＬＢＴ－ＲＡ－ＣｏｎｔｅｎｔｉｏｎＲｅｓｏｌｕｔｉｏｎＲｅｓｔａｒ
ｔ－Ｔｈｒｅｓｈｏｌｄである場合、
２＞ランダムアクセス応答の受信が成功しなかったと見なす。

【0119】

（ランダムアクセスプリアンブル送信）
ランダムアクセスプリアンブル送信手順の以下の修正は、ＮＲ－ＵにおけるＬＢＴの影
響を考慮に入れる。

【0120】

ＬＢＴが失敗した場合、プリアンブルパワーランピングカウンタをインクリメントすべ
きではないと説明してきた。例えば、
ＭＡＣエンティティは、各ランダムアクセスプリアンブルに対して、以下であるものと
する。
１＞ＰＲＥＡＭＢＬＥ＿ＴＲＡＮＳＭＩＳＳＩＯＮ＿ＣＯＵＮＴＥＲが１よりも大きい場
合、および、
１＞パワーランピングカウンタの一時停止の通知を下位層から受信していない場合、およ
び、
１＞選択されたＳＳＢが変更されていない場合（すなわち、前回のランダムアクセスプリ
アンブル送信と同じ）、および、
１＞ＬＢＴ失敗が検出されなかった場合、
２＞ＰＲＥＡＭＢＬＥ＿ＰＯＷＥＲ＿ＲＡＭＰＩＮＧ＿ＣＯＵＮＴＥＲを１だけインクリ
メントする。

【0121】

プリアンブルパワーランピングカウンタは、ＬＢＴ失敗の検出時にデクリメントされて
もよい。例えば、
１＞物理層に、選択されたＰＲＡＣＨ、対応するＲＡ－ＲＮＴＩ（利用可能な場合）、Ｐ
ＲＥＡＭＢＬＥ＿ＩＮＤＥＸ、およびＰＲＥＡＭＢＬＥ＿ＲＥＣＥＩＶＥＤ＿ＴＡＲＧＥ
Ｔ＿ＰＯＷＥＲを使用して、ランダムアクセスプリアンブルを送信するように指示する。
２＞ＬＢＴ失敗が検出された場合、
２＞ＰＲＥＡＭＢＬＥ＿ＰＯＷＥＲ＿ＲＡＭＰＩＮＧ＿ＣＯＵＮＴＥＲを１だけデクリメ
ントする。

【0122】

上記の手順において、ＬＢＴ失敗がプリアンブル送信に適用され得ることに留意すべき
である。

【0123】

（パワーヘッドルーム報告）
ＰＨＲ手順の以下の修正は、ＮＲ－ＵにおけるＬＢＴの影響を考慮に入れる。

【0124】

ＰＨＲ ＭＡＣ ＣＥの送信がＬＢＴ失敗によってブロックされ、時間をおいて再送信
される場合、ＰＨＲが計算されたときＮＢに通知するため、またはＰＨＲが計算されたと
きの送信条件をＮＢに通知するために、追加のシグナリングが導入される。

【0125】

ＮＢがＰＨＲを適切に処理するためには、ＰＨＲがどのような条件下で計算されたかを
ＮＢが認識するために必要な場合がある。

【0126】

ＰＨＲは、定格ＵＥ最大送信電力と、アクティブ化されたサービングセルごとのＵＬ－
ＳＣＨ送信またはＳＲＳ送信の推定電力との差について、および、定格ＵＥ最大電力と、
ＳｐＣｅｌｌおよびＰＵＣＣＨ ＳＣｅｌｌ上のＵＬ－ＳＣＨおよびＰＵＣＣＨ送信の推
定電力との差についての情報も用いて計算する。

【0127】

既存のＰＨＲシグナリングは、ＵＬ－ＳＣＨ送信が実送信または仮想送信に基づいてい
たか否か、およびＰＨＲが計算されたときにＰＵＣＣＨが送信されたか否かを特定する。
ＵＬ－ＳＣＨが実送信されたものである場合、ＰＨＲ計算時に何が送信されたかをＮＢが
認識するために必要な場合がある。

【0128】

アンライセンス周波数帯で動作しておらず、ＬＢＴが使用されていない場合、ＮＢはＰ
ＨＲの計算がいつ行われたかを判定できる。ＮＢはスケジュールされたものと受信したも
のを認識しているため、この時点でＵＬ－ＳＣＨで何が送信されたかを認識することでＰ
ＨＲを解釈することができる。しかし、ＬＢＴが失敗し、ＬＢＴが成功するまで送信が遅
延する場合、ＮＢはＰＨＲの計算時にＵＬ－ＳＣＣＨで何が送信されたかを判定すること
ができない。

【0129】

以下に、この問題に対処するための複数の方法を示す。第１の方法では、ＰＨＲの計算
がいつ行われたのかをＮＢが判定できるような追加の表示をＰＨＲに提供する。これは、
最初のＬＢＴ失敗の時間に対するＬＢＴによる遅延であってもよく、または絶対時間基準
であってもよい。第２の方法では、ＵＬ－ＳＣＣＨで何が送信されたかをＮＢに通知する
追加情報をＰＨＲと共に提供する。これは、ＵＬ－ＳＣＣＨ上で何が送信されたかを近似
したインデックス付きの値であってもよく、またはＰＨＲ計算時の送信の物理的な詳細で
あってもよい。第３の方法では、ＰＨＲのためにＬＢＴによって被った実効遅延をＮＢが
判定し得るように、ＬＢＴの失敗または成功がＮＢに独立して示されてもよい。第４の方
法では、ＰＨＲが計算されたときに使用されたグラント（例えば、アップリンクグラント
）をＮＢに通知する追加情報をＰＨＲと共に提供する。

【0130】

ＰＨＲがどのように計算されたかをＮＢが認識することができる追加情報をＮＢが受信
することが好ましいが、絶対に必要というわけではない。あるいは、実際のＰＨＲが不正
確な情報を提供している場合、ＮＢは少なくとも認識し得る。これは、ＵＥがＮＢにＬＢ
Ｔ失敗および成功示すことで、ＰＨＲを遅延させたＬＢＴ失敗があったことをＮＢが判定
できるようにすることにより、実現され得る。

【0131】

以下に別の例を示す。ＰＨＲのトリガ条件は、ＬＢＴ失敗を考慮すべきである。利用可
能なＵＬリソース、ＰＨＲ周期タイマ満了、ＰＨＲ再設定、ＳＣｅｌｌアクティブ化、；
およびＰＳＣｅｌｌ追加のトリガ基準は、ＬＢＴが成功した場合にのみ考慮されるべきで
ある。ＬＢＴ基準の追加は、既存の各トリガに対して相互に排他的であり、したがって、
既存の基準のサブセットにのみ影響を与え得る。

【0132】

例えば（全てのトリガを考慮する場合）、ＭＡＣ仕様は以下のように修正されてもよい
。
以下のイベントのいずれかが発生した場合、パワーヘッドルームレポート（ＰＨＲ）が
トリガされるものとする。
・ｐｈｒ－ＰｒｏｈｉｂｉｔＴｉｍｅｒが満了するか、または満了して、ＭＡＣエンティ
ティに新しい送信のためのＵＬリソースがあり、この送信がＬＢＴ失敗によってブロック
されていないときに、このＭＡＣエンティティにおけるＰＨＲの最後の送信以降、パスロ
スの参照先として使用されるＭＡＣエンティティの少なくとも１つのアクティブ化された
サービングセルに対して、パスロスがｐｈｒ－Ｔｘ－ＰｏｗｅｒＦａｃｔｏｒＣｈａｎｇ
ｅ ｄＢを超えて変化した、
注釈１ 上記で評価された１つのセルのパスロス変動は、現在のパスロス参照で現時点で
測定されたパスロスと、その時点で使用されていたパスロス参照でＰＨＲの最後の送信時
に測定されたパスロスとの間のものであり、その間にパスロス参照が変更されたか否かは
関係がない。
・ｐｈｒ－ＰｅｒｉｏｄｉｃＴｉｍｅｒが満了し、その後ＬＢＴが成功する、
・上位層によるパワーヘッドルーム報告機能の設定または再設定時に、ＬＢＴがその後成
功し、その機能性を無効化するために使用されていない、
・設定されたアップリンクを有するＭＡＣエンティティのＳＣｅｌｌをアクティブ化し、
ＬＢＴがその後成功する、
・ＰＳＣｅｌｌの追加（すなわち、ＰＳＣｅｌｌが新たに追加または変更された場合）、
およびＬＢＴがその後成功する、
・ｐｈｒ－ＰｒｏｈｉｂｉｔＴｉｍｅｒが満了するか、または満了し、ＭＡＣエンティテ
ィが新しい送信のためのＵＬリソースを有し、この送信がＬＢＴ失敗によってブロックさ
れておらず、設定されたアップリンクを有するいずれかのＭＡＣエンティティのアクティ
ブ化されたサービングセルのいずれかについて以下のことが当てはまる、
・このセルに送信のためのＵＬリソースが割り当てられているか、またはＰＵＣＣＨ送信
があり、このセルに対する電力管理（ＴＳ３８．１０１［１０］に規定されているように
Ｐ－ＭＰＲｃによって許可されている）による必要な電力バックオフが、ＰＨＲの最後の
送信以降、ＭＡＣエンティティが、このセルに送信のためのＵＬリソースが割り当てられ
ていたか、またはＰＵＣＣＨ送信があったときに、ｐｈｒ－Ｔｘ－ＰｏｗｅｒＦａｃｔｏ
ｒＣｈａｎｇｅ ｄＢを超えて変化した。

【0133】

これらの変更は、ＬＢＴが成功し、ＵＥがチャネルにアクセスしたときにＰＨＲが計算
または送信されるようにするために必要な場合がある。

【0134】

以下に別の例を示す。ＰＨＲの計算および送信は、ＬＢＴが成功した場合にのみ考慮さ
れるべきである。

【0135】

定格ＵＥ最大送信電力と、アクティブ化されたサービングセルごとのＵＬ－ＳＣＨ送信
またはＳＲＳ送信の推定電力との差について、および、定格ＵＥ最大電力と、ＳｐＣｅｌ
ｌおよびＰＵＣＣＨ ＳＣｅｌｌ上のＵＬ－ＳＣＨおよびＰＵＣＣＨ送信の推定電力との
差についての情報を用いた計算も、ＬＢＴ成功時にのみ考慮されるべきである。

【0136】

ＵＬリソースがＰＨＲ ＭＡＣ ＣＥに適応できるか否かをチェックする場合、ＬＢＴ
成功を判定することも必要であり得る。利用可能なＵＬリソースを有することは、ＰＨＲ
ＭＡＣ ＣＥの送信がＬＢＴによりブロックされることには関係がない。

【0137】

例えば、ＭＡＣ仕様を以下のように修正してもよい。
ＭＡＣエンティティが新しい送信のために割り当てられたＵＬリソースを有し、ＬＢＴ成
功と判定された場合、ＭＡＣエンティティは、
１＞最後のＭＡＣリセット以降、新しい送信のために割り当てられた最初のＵＬリソース
である場合、
２＞ｐｈｒ－ＰｅｒｉｏｄｉｃＴｉｍｅｒを起動して、
１＞パワーヘッドルーム報告手順により、少なくとも１つのＰＨＲがトリガされ、キャン
セルされていないと判定された場合、および、
１＞割り当てられたＵＬリソースが、論理チャネルの優先順位付けの結果、ＭＡＣエンテ
ィティが送信するように構成されているＰＨＲのためのＭＡＣ ＣＥと、そのサブヘッダ
に適応できる場合、および、
１＞ＬＢＴ成功と判定され、
２＞ｍｕｌｔｉｐｌｅＰＨＲが設定されている場合、
３＞任意のＭＡＣエンティティに関連付けられた、設定されたアップリンクを有する各ア
クティブ化されたサービングセルに対して、
４＞対応するアップリンクキャリアに対するタイプ１またはタイプ３のパワーヘッドルー
ムの値を取得して、
４＞このＭＡＣエンティティが、このサービングセルでの送信のために割り当てられたＵ
Ｌリソースを有し、ＬＢＴ成功と判定された場合、または、
４＞他方のＭＡＣエンティティ（設定されている場合）が、送信のために割り当てられた
ＵＬリソースを有し、このサービングセルでＬＢＴ成功と判定され、上位層によりｐｈｒ
－ＭｏｄｅＯｔｈｅｒＣＧが実数に設定されている場合、
５＞物理層から対応するＰ_{ＣＭＡＸ，ｆ，ｃ}フィールドの値を取得し、
３＞ｐｈｒ－Ｔｙｐｅ２ＳｐＣｅｌｌが設定されている場合、
４＞このＭＡＣエンティティのＳｐＣｅｌｌに対するタイプ２パワーヘッドルームの値を
取得して、
４＞物理層から対応するＰ_{ＣＭＡＸ，ｆ，ｃ}フィールドの値を取得し、
３＞ｐｈｒ－Ｔｙｐｅ２ＯｔｈｅｒＣｅｌｌが設定されている場合、
４＞その他のＣＧが設定されている場合、
５＞他方のＭＡＣエンティティのＳｐＣｅｌｌに対するタイプ２パワーヘッドルームの値
を取得して、
５＞ｐｈｒ－ＭｏｄｅＯｔｈｅｒＣＧが上位層によって実数に設定されている場合、
６＞物理層から他方のＭＡＣエンティティのＳｐＣｅｌｌに対する対応するＰ_{ＣＭＡＸ，
ｆ，ｃ}フィールドの値を取得し、
４＞さもなければ、ＰＵＣＣＨ ＳＣｅｌｌが設定され、アクティブ化されている場合、
５＞ＰＵＣＣＨ ＳＣｅｌｌに対するタイプ２パワーヘッドルームの値を取得して
５＞物理層から対応するＰ_{ＣＭＡＸ，ｆ，ｃ}フィールドの値を取得し、
３＞ＬＢＴ成功と判定された場合、物理層から報告された値に基づいて、［２］の６．１
．３．９節で定義されているように、設定されたＳｅｒｖＣｅｌｌＩｎｄｅｘおよびＭＡ
ＣエンティティのＰＵＣＣＨ（単数または複数）に従ってＰＨＲ ＭＡＣ ＣＥを生成お
よび送信するように、多重化およびアセンブリ手順に指示し、
２＞さもなければ（すなわち、シングルエントリＰＨＲフォーマットが使用されて）、
３＞ＰＣｅｌｌの対応するアップリンクキャリアの物理層からタイプ１パワーヘッドルー
ムの値を取得して、
３＞物理層から対応するＰ_{ＣＭＡＸ，ｆ，ｃ}フィールドの値を取得して。
３＞ＬＢＴ成功と判定された場合、物理層から報告された値に基づいて、［２］の６．１
．３．８節で定義されているように、ＰＨＲ ＭＡＣ ＣＥ を生成および送信するよう
に、多重化およびアセンブリ手順を指示し、
２＞ｐｈｒ－ＰｅｒｉｏｄｉｃＴｉｍｅｒを起動または再起動して、
２＞ｐｈｒ－ＰｒｏｈｉｂｉｔＴｉｍｅｒを起動または再起動して、
２＞全てのトリガされたＰＨＲ（単数または複数）をキャンセルする。

【0138】

上記の例示的なＭＡＣ固有の変更は、ＬＢＴ成功の観点から記載されているが、例はＬ
ＢＴ失敗なしの観点からも同様に表されてもよい。
この例では、変更は相互排他的であることに留意すべきである。開示された変更のサブセ
ットのみが必要な場合がある。

【0139】

以下に別の例を示す。さらに、ＭＡＣ ＰＨＲ ＣＥを含む送信のＬＢＴ失敗の検出時
、ＰＨＲ禁止タイマを設定するべきではないか、または設定されていた場合はクリアする
べきであることが開示されている。

【0140】

物理層がＭＡＣ ＰＨＲ ＣＥを含むＭＡＣ ＰＤＵの送信を指示された場合、ＰＨＲ
禁止タイマは、ＭＡＣ ＰＤＵ送信のＬＢＴ成功の判定時にのみ起動または再起動される
べきである。例えば、ＭＡＣ仕様を以下のように修正してもよい。
１＞ＬＢＴ成功と判定された場合、
２＞ｐｈｒ－ＰｅｒｉｏｄｉｃＴｉｍｅｒを起動または再起動して、
２＞ｐｈｒ－ＰｒｏｈｉｂｉｔＴｉｍｅｒを起動または再起動して、
２＞全てのトリガされたＰＨＲ（単数または複数）をキャンセルする。

【0141】

上記の例示的なＭＡＣ固有の変更は、ＬＢＴ成功の観点から記載されているが、例はＬ
ＢＴ失敗なしの観点からも表されてもよい。

【0142】

あるいは、ＰＨＲ禁止タイマまたはＰＨＲ周期タイマは、既存の手順で行われるように
起動されてもよいが、ＬＢＴ失敗と判定された場合には、ＰＨＲ禁止タイマがクリアされ
てもよく、またはＰＨＲ周期タイマがＬＢＴ失敗による最後のリセット前の残りの値に、
もしくは、例えば設定された時間値などの異なる時間値にリセットしてもよい。

【0143】

この修正は、後続のＰＨＲ送信が遅延し得ないようにＰＨＲ禁止タイマが設定されない
ようにするか、または、ＰＨＲの送信がＬＢＴ失敗によってブロックされたときに周期的
なＰＨＲが遅延しないように、ＰＨＲ周期タイマがリセットされないようにすることを確
実にするために、必要な場合がある。

【0144】

（ＳＣｅｌｌのアクティブ化／非アクティブ化）
ＳＣｅｌｌのアクティブ化／非アクティブ化手順の以下の修正は、ＮＲ－ＵにおけるＬ
ＢＴの影響を考慮に入れる。

【0145】

ＳＣｅｌｌ非アクティブ化タイマの実行中にＬＢＴ失敗が検出された場合、ＳＣｅｌｌ
非アクティブ化タイマが延長される。これは、意図しないＳＣｅｌｌ非アクティブ化を回
避するために必要な場合がある。

【0146】

ＬＢＴ失敗により、ＮＢがＤＬ送信の機会を逃した（ダウンリンクの割り当て（単数ま
たは複数）が損失され得る）か、またはＵＬ送信がブロックされ得る（ＭＡＣ ＰＤＵが
送信されない）ことをＵＥが検出すると、ＳＣｅｌｌ非アクティブ化タイマが延長される
。

【0147】

これを達成する方法の、複数のオプションが存在し得る。
・ＬＢＴ失敗の検出時に、ＳＣｅｌｌ非アクティブ化タイマが延長または再起動される
・ＳＣｅｌｌ非アクティブ化タイマの満了時にＬＢＴ失敗が検出された場合、ＳＣｅｌｌ
非アクティブ化タイマが延長または再起動される。

【0148】

ＬＢＴ失敗とは、ＬＢＴ成功の欠如を意味する場合もあることに留意すべきである。例
えば、ＵＥ ＰＨＹ層がＵＥ ＭＡＣにＬＢＴ失敗を示すことがあり、またはＮＢがＵＥ
ＭＡＣにＬＢＴ成功を示すことがある。

【0149】

例えば、ＭＡＣ仕様を以下のように修正してもよい。
１＞さもなければ、ＳＣｅｌｌを非アクティブ化する、ＳＣｅｌｌアクティブ化／非アク
ティブ化ＭＡＣ ＣＥを受信した場合、または、
１＞アクティブ化されたＳＣｅｌｌに関連付けられたｓＣｅｌｌＤｅａｃｔｉｖａｔｉｏ
ｎＴｉｍｅｒが満了し、ＬＢＴ失敗が検出されなかった場合、
２＞ＴＳ ３８．２１３で定義されているタイミングに従って、ＳＣｅｌｌを非アクティ
ブ化して、
２＞ＳＣｅｌｌに関連付けられたｓＣｅｌｌＤｅａｃｔｉｖａｔｉｏｎＴｉｍｅｒを停止
して、
２＞ＳＣｅｌｌに関連付けられたｂｗｐ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒを停止して、
２＞ＳＣｅｌｌに関連付けられた、任意の設定されたダウンリンク割り当て、および任意
の設定されたアップリンクグラントのタイプ２をそれぞれクリアして、
２＞ＳＣｅｌｌに関連付けられた、任意の設定されたアップリンクグラントのタイプ１を
一時停止して、
２＞ＳＣｅｌｌに関連付けられた全てのＨＡＲＱバッファをフラッシュする。

１＞アクティブ化されたＳＣｅｌｌに関連付けられたｓＣｅｌｌＤｅａｃｔｉｖａｔｉｏ
ｎＴｉｍｅｒが満了し、ＬＢＴ失敗が検出された場合、
２＞ＳＣｅｌｌに関連付けられたｓＣｅｌｌＤｅａｃｔｉｖａｔｉｏｎＴｉｍｅｒを再起
動する。

【0150】

上記の手順（単数または複数）において、ＬＢＴ失敗が検出されたとは、ＳＣｅｌｌ非
アクティブ化タイマが動作している期間、ＳＣｅｌｌ非アクティブ化から、もしくは設定
されたアップリンクグラントで最後のＭＡＣ ＰＤＵが送信されたときから、もしくは設
定されたダウンリンク割り当てでＵＥが最後に受信したときから、ＳＣｅｌｌ非アクティ
ブ化タイマが設定された後に最初に満了する時点までの期間、またはＬＢＴ検出によりＳ
Ｃｅｌｌ非アクティブ化タイマが満了して最後に起動してから、次のＳＣｅｌｌ非アクテ
ィブ化タイマが満了するまでの期間に適用されることに留意すべきである。

【0151】

あるいは、ＳＣｅｌｌのＬＢＴ失敗検出時に、
１＞ＬＢＴ失敗が検出された場合、
２＞ＳＣｅｌｌに関連付けられたｓＣｅｌｌＤｅａｃｔｉｖａｔｉｏｎＴｉｍｅｒを再起
動する。

【0152】

あるいは、ＬＢＴ失敗もしくはＬＢＴ成功、または連続ＬＢＴ失敗もしくは連続ＬＢＴ
成功をカウントするように手順を定義してもよい。ＬＢＴ失敗もしくは連続ＬＢＴ失敗が
、設定された最大ＬＢＴ失敗閾値を超えた場合、またはＬＢＴ成功もしくは連続ＬＢＴ成
功が、設定された最小ＬＢＴ成功閾値未満であり得る場合にのみ、ＳＣｅｌｌ非アクティ
ブ化タイマが再起動される。例えば、ＭＡＣ仕様を以下のように修正してもよい。
１＞ＳｃｅｌｌＤｅａｃｔＬＢＴ－Ｆａｉｌｕｒｅ－Ｃｏｕｎｔ＞ＳｃｅｌｌＤｅａｃｔ
ＬＢＴ－Ｆａｉｌｕｒｅ－Ｔｈｒｅｓｈｏｌｄである場合、
２＞ＳＣｅｌｌに関連付けられたｓＣｅｌｌＤｅａｃｔｉｖａｔｉｏｎＴｉｍｅｒを再起
動して、
２＞ＳｃｅｌｌＤｅａｃｔＬＢＴ－Ｆａｉｌｕｒｅ－Ｃｏｕｎｔを０に設定する。

１＞ＬＢＴの失敗が発生した場合、
２＞ＳｃｅｌｌＤｅａｃｔＬＢＴ－Ｆａｉｌｕｒｅ－Ｃｏｕｎｔをインクリメントする。

【0153】

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

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

【0154】

ＳｃｅｌｌＤｅａｃｔ－ＬＢＴ－ＦａｉｌｕｒｅＴｈｒｅｓｈｏｌｄを超えた場合、以
下のアクションを実行してもよい。
１＞ＬＢＴ－ＳｃｅｌｌＤｅａｃｔＴｉｍｅｒＲｅｓｔａｒｔＣｏｕｎｔ＜＝ＬＢＴ－Ｓ
ｃｅｌｌＤｅａｃｔ－Ｒｅｓｔａｒｔ－Ｔｈｒｅｓｈｏｌｄである場合、
２＞ＴＳ３８．２１３［６］で定義されているタイミングに従って、ＳＣｅｌｌを非アク
ティブ化して、
２＞ＳＣｅｌｌに関連付けられたｓＣｅｌｌＤｅａｃｔｉｖａｔｉｏｎＴｉｍｅｒを停止
して、
２＞ＳＣｅｌｌに関連付けられたｂｗｐ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒを停止して、
２＞ＳＣｅｌｌに関連付けられた、任意の設定されたダウンリンク割り当て、および任意
の設定されたアップリンクグラントのタイプ２をそれぞれクリアして、
２＞ＳＣｅｌｌに関連付けられた、任意の設定されたアップリンクグラントのタイプ１を
一時停止して、
２＞ＳＣｅｌｌに関連付けられた全てのＨＡＲＱバッファをフラッシュする。

【0155】

（間欠受信（ＤＲＸ））
ＤＲＸ手順の以下の修正は、ＮＲ－ＵにおけるＬＢＴの影響を考慮に入れる。

【0156】

ショートサイクルタイマが満了するときに、ショートＤＲＸサイクルからロングＤＲＸ
サイクルに移行することがある。この移行はＬＢＴ成功が検出された場合、またはＬＢＴ
失敗が検出されなかった場合にのみ実行されるべきである。例えば、
１＞ｄｒｘ－ＳｈｏｒｔＣｙｃｌｅＴｉｍｅｒが満了し、ＬＢＴ成功が検出された場合、
１＞ロングＤＲＸサイクルを使用し、
１＞さもなければ、
２＞ｄｒｘ－ＳｈｏｒｔＣｙｃｌｅＴｉｍｅｒを起動または再起動する。

【0157】

本明細書では、最大ＬＢＴ失敗または最小ＬＢＴ成功の設定閾値が開示されている。そ
して、ＬＢＴ失敗またはＬＢＴ成功のカウントが閾値を超えた場合にのみ、ＵＥはＤＲＸ
ショートサイクルを使用し続け得る。例えば、
１＞ｄｒｘ－ＳｈｏｒｔＣｙｃｌｅＴｉｍｅｒが満了し、ＬＢＴ成功カウンタが最小ＬＢ
Ｔ成功閾値を超えた場合、
２＞ロングＤＲＸサイクルを使用し、
２＞さもなければ、
２＞ｄｒｘ－ＳｈｏｒｔＣｙｃｌｅＴｉｍｅｒを起動または再起動する。

【0158】

あるいは、ＬＢＴ失敗が検出された場合またはＬＢＴ成功が検出されなかった場合は、
ＤＲＸアクティブタイムを延長する。これは、ＤＲＸ非アクティブタイマを起動または再
起動することによって実現され得る。また、ＤＲＸ非アクティブタイマが満了時に、ＤＲ
Ｘショートサイクルタイマが起動または再起動されるため、これにより、ＤＲＸショート
サイクルを継続して使用し得る。さらに、これにより、ＬＢＴ失敗により損失したスケジ
ューリング機会のために必要となる場合がある、さらなるＰＤＣＣＨ ＵＬおよびＤＬの
スケジューリング機会が可能となり得る。例えば、ＭＡＣ仕様を以下のように修正しても
よい。
３＞ＰＤＣＣＨが新しい送信（ＤＬまたはＵＬ）を示す場合、
４＞ＰＤＣＣＨ受信終了後の最初のシンボルで、ｄｒｘ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅ
ｒを起動または再起動して、
３＞ＬＢＴ失敗が検出された場合、
４＞ｄｒｘ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒを起動または再起動する。

【0159】

好ましくは、ＤＲＸ非アクティブタイマの起動または再起動は、一定期間内にＬＢＴ失
敗の検出またはＬＢＴ成功の非検出が複数回発生したことに依存する。期間は、オンデュ
レーションの期間または非アクティブタイマの期間、オンデュレーションおよび非アクテ
ィブタイマが実行されている時間の組み合わせであり得る。例えば、
１＞ＬＢＴ成功が検出されなかった場合に、ｄｒｘ－ｏｎＤｕｒａｔｉｏｎＴｉｍｅｒが
満了するとき、
２＞ｄｒｘ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒを起動または再起動して、
１＞ＬＢＴ成功が検出されなかった場合に、ｄｒｘ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒが
満了するとき、
２＞ｄｒｘ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒを起動または再起動する。

【0160】

ＬＢＴ失敗は、単一のインスタンスではないことがある。複数のＬＢＴ失敗または成功
の検出であってもよい。ＤＲＸ手順は、ＰＤＤＣＨのＵＥ受信に影響を及ぼす一連のＬＢ
Ｔ失敗の後にのみ開始されてもよい。

【0161】

ＬＢＴ失敗もしくはＬＢＴ成功をカウントする、または連続ＬＢＴ失もしくは連続ＬＢ
Ｔ成功をカウントするように手順を定義してもよい。ＬＢＴ失敗もしくは連続ＬＢＴ失敗
が、設定された最大ＬＢＴ失敗閾値を超えた場合、またはＬＢＴ成功もしくは連続ＬＢＴ
成功が、設定された最小ＬＢＴ成功閾値未満であり得る場合にのみ、ＤＲＸ非アクティブ
タイマが再起動される。例えば、
１＞ＬＢＴ成功カウントがＬＢＴ最小成功閾値未満の場合に、オンデュレーションタイマ
が満了するとき、
２＞ｄｒｘ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒを起動または再起動する。
また、ＵＥがＤＲＸに決して入ることがないように、ＤＲＸ非アクティブタイマを大幅
に延長すること、またはＬＢＴ失敗によりＤＲＸ非アクティブタイマを無期限に延長する
ことを回避する必要がある場合もある。その場合、ＤＲＸ非アクティブタイマの再起動は
、指定されたまたは設定された最大値に制限され得る。例えば、ＭＡＣ仕様を以下のよう
に修正してもよい。
１＞ＤＲＸ－Ｉｎａｃｔｉｖｉｔｙ－ＬＢＴ－Ｆａｉｌｕｒｅ－Ｃｏｕｎｔ＞ＤＲＸ－Ｉ
ｎａｃｔｉｖｉｔｙ－ＬＢＴ－ＦａｉｌｕｒｅＴｈｒｅｓｈｏｌｄである場合、および、
１＞ＤＲＸ－Ｉｎａｃｔｉｖｉｔｙ－ＴｉｍｅｒＲｅｓｔａｒｔＣｏｕｎｔ＜＝ＤＲＸ－
Ｉｎａｃｔｉｖｉｔｙ－Ｒｅｓｔａｒｔ－Ｔｈｒｅｓｈｏｌｄである場合、
２＞ＤＲＸ－Ｉｎａｃｔｉｖｉｔｙ－ＬＢＴ－Ｆａｉｌｕｒｅ－Ｃｏｕｎｔを０に設定し
て、
２＞ＤＲＸ－Ｉｎａｃｔｉｖｉｔｙ－ＴｉｍｅｒＲｅｓｔａｒｔＣｏｕｎｔを１だけイン
クリメントして、
２＞ｄｒｘ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒを起動または再起動し、

１＞ＬＢＴ失敗が検出された場合、
２＞ＤＲＸ－Ｉｎａｃｔｉｖｉｔｙ－ＬＢＴ－Ｆａｉｌｕｒｅ－Ｃｏｕｎｔをインクリメ
ントする。
ＤＲＸ－Ｉｎａｃｔｉｖｉｔｙ－ＬＢＴＲｅｓｔａｒｔＴｈｒｅｓｈｏｌｄを超えた場
合、以下のアクションを実行してもよい。
１＞ＤＲＸ－Ｉｎａｃｔｉｖｉｔｙ－ＴｉｍｅｒＲｅｓｔａｒｔＣｏｕｎｔ＞ＤＲＸ－Ｉ
ｎａｃｔｉｖｉｔｙ－Ｒｅｓｔａｒｔ－Ｔｈｒｅｓｈｏｌｄである場合
２＞ショートＤＲＸサイクルが設定されている場合、
３＞ｄｒｘ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒの満了後の最初のシンボル、またはＤＲＸ
コマンドＭＡＣ ＣＥの受信終了後の最初のシンボルで、ｄｒｘ－ＳｈｏｒｔＣｙｃｌｅ
Ｔｉｍｅｒを起動または再起動して、
３＞ショートＤＲＸサイクルを使用し、
２＞さもなければ、
３＞ロングＤＲＸサイクルを使用する。

【0162】

ＬＢＴ失敗が発生したときに非アクティブタイムを起動または再起動することによって
ＤＲＸアクティブタイムを延長することは、設定可能なオプションであるか、または現在
アクティブなサービスに依存しているべきである。例えば、ＵＲＬＬＣサービスがサポー
トされ得る場合、ＬＢＴ失敗が発生したときにスケジューリング機会を維持することがよ
り重要になる。

【0163】

あるいは、ＤＲＸアクティブタイムの延長時間は、設定されたＤＲＸインアクティビテ
ィタイマの期間と異なっていてもよい。別の設定値であってもよく、または、好ましくは
現在のＤＲＸアクティブタイム期間中に検出されたＬＢＴ失敗の量に対する期間であって
もよい。

【0164】

別の例では、ＤＲＸ手順を動的に適応させることによって、ＬＢＴ動作によって生じる
ＤＲＸの非効率性に対処する方法があり得る。ＵＥが各ＤＲＸサイクルをウェイクアップ
するときに、ＤＲＸ設定をＬＢＴ動作に応じて動的に調整してもよい。例えば、ＤＲＸオ
ンデュレーション、インアクティビティ、またはＤＲＸサイクルを周期的に調整してもよ
い。これは、各ＤＲＸサイクルであってもよい。

【0165】

送信前にＮＢはクリアチャネル評価（ＣＣＡ）を判定し、チャネルアクセス優先度クラ
ス（ＣＡＰＣ）を選択する。ＣＡＰＣには、最大チャネル占有時間（ＭＣＯＴ）およびコ
ンテンションウィンドウサイズ（ＣＷＳ）が選択される。ＭＣＯＴ期間中は送信を行うこ
とができる一方で、ＣＣＡおよびＣＷＳの期間中は送信を行うことができない。送信タイ
ミングを動的に調整し得るため、ＵＥのＤＲＸ動作を動的に調整して、ＮＢによって判定
された送信機会によりよく一致させ得る。

【0166】

これを達成するために、各ＤＲＸサイクルにＮＢからシグナリングされるダウンリンク
ＬＢＴ成功表示に加えて、またはこれに含まれる、ＣＣＡ期間、選択されたＭＣＯＴもし
くはＣＷＳ、または他のタイミング情報がＭＡＣに提供され得、ダウンリンクおよびアッ
プリンクの送信機会をより正確に判定することが可能になる。ＭＣＯＴ、ＣＷＳ、または
他のタイミングは、選択されたタイミングを表すチャネルアクセス優先度クラス（ＣＡＰ
Ｃ）または別のインデックスによって特定され得る。

【0167】

ＬＢＴタイミング情報の受信に基づいて、ＵＥ ＤＲＸ手順は、ＭＣＯＴ期間と整合す
るようにアクティブタイムを動的に調整し、ＣＷＳおよび場合によりＣＣＡ期間にＤＲＸ
を適用する。

【0168】

例えば、各ＤＲＸサイクルの開始時に、ＮＢによって選択されたＭＣＯＴにオンデュレ
ーションを設定してもよい。同様に、非アクティブタイマは、選択されたＭＣＯＴと整合
するように設定されてもよい。

【0169】

あるいは、ＵＥは、ＣＷＳおよび場合によりＣＣＡ期間にＤＲＸに入ってもよい。例え
ば、アクティブタイムには、ＭＣＯＴ期間と重なる、またはＣＷＳおよび場合によりＣＣ
Ａ期間と重ならないオンデュレーションおよび非アクティブタイム期間のみが含まれる。
例えば、ＭＡＣ仕様を以下のように修正してもよい。

【0170】

ＤＲＸサイクルが設定されている場合、アクティブタイムには、以下の時間が含まれる
。
・ｄｒｘ－ｏｎＤｕｒａｔｉｏｎＴｉｍｅｒ、またはｄｒｘ－ＩｎａｃｔｉｖｉｔｙＴｉ
ｍｅｒ、またはｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒＤＬ、またはｄｒｘ－
ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒＵＬ、またはｒａ－ＣｏｎｔｅｎｔｉｏｎＲｅ
ｓｏｌｕｔｉｏｎＴｉｍｅｒ（５．１．５節に記載されているように）が実行されている
間、および、
・ｄｒｘ－ＭＣＯＴ－Ｔｉｍｅｒが実行されている間。

【0171】

またはその代わりに、
ＤＲＸサイクルが設定されている場合、アクティブタイムには、以下の時間が含まれる
。
・ｄｒｘ－ｏｎＤｕｒａｔｉｏｎＴｉｍｅｒ、またはｄｒｘ－ＩｎａｃｔｉｖｉｔｙＴｉ
ｍｅｒ、またはｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒＤＬ、またはｄｒｘ－
ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒＵＬ、またはｒａ－ＣｏｎｔｅｎｔｉｏｎＲｅ
ｓｏｌｕｔｉｏｎＴｉｍｅｒ（５．１．５節に記載されているように）が実行されている
間、および、
・ｄｒｘ－ＣＷＳ－Ｔｉｍｅｒが実行されていない間。

【0172】

（スケジューリング要求）
ＳＲ手順の以下の修正は、ＮＲ－ＵにおけるＬＢＴの影響を考慮に入れる。

【0173】

保留中のＳＲがあり、場合により一定時間にわたってＬＢＴ失敗が判定された場合、ラ
ンダムアクセス手順が開始され、保留中のＳＲがキャンセルされるべきである。これは、
ＬＢＴ失敗によりＰＵＣＣＨリソースが使用不能になった場合に必要となることがある。
この場合、ＲＡ手順が試行され、この手順が失敗した場合は、問題を解決するために無線
リンク失敗が宣言される。例えば、ＭＡＣ仕様を以下のように修正してもよい。
少なくとも１つのＳＲが保留されている限り、ＭＡＣエンティティは、各保留中のＳＲに
対して、以下であるものとする。
１＞ＭＡＣエンティティが、保留中のＳＲに対して妥当なＰＵＣＣＨリソースを設定して
いない場合、または、
１＞ＬＢＴ失敗が検出された場合、
２＞ＳｐＣｅｌｌでランダムアクセス手順（例えば、［２］の５．１節を参照）を開始し
、保留中のＳＲをキャンセルする。

【0174】

ＰＵＣＣＨリソースの妥当性はまた、ＬＢＴ成功またはＬＢＴ失敗に対して定義されて
もよい。例えば、ＭＡＣ仕様を以下のように修正してもよい。

【0175】

ＬＢＴ失敗が判定されていないＳＲ送信機会時にアクティブなＢＷＰ上のＰＵＣＣＨリ
ソースのみが妥当と見なされる。

【0176】

少なくとも１つのＳＲが保留されている限り、ＭＡＣエンティティは、各保留中のＳＲ
に対して、以下であるものとする。
１＞ＭＡＣエンティティが、保留中のＳＲに対して妥当なＰＵＣＣＨリソースを設定して
いない場合、
２＞ＳｐＣｅｌｌでランダムアクセス手順（例えば、［２］の５．１節を参照）を開始し
、保留中のＳＲをキャンセルする。

【0177】

上記の例は、「ＬＢＴ失敗なし」の検出の観点から表されることもあるが、「ＬＢＴ成
功」の検出で表されることもある。ＬＢＴ失敗またはＬＢＴ成功は、単一のインスタンス
ではないことがある。複数のＬＢＴ失敗または成功の検出であってもよい。ＲＡ手順は、
ＰＵＣＣＨのＳＲ送信に影響を及ぼす一連のＬＢＴ失敗後にのみ開始されてもよい。

【0178】

ＬＢＴ失敗もしくはＬＢＴ成功をカウントする、または連続ＬＢＴ失敗もしくは連続Ｌ
ＢＴ成功をカウントするように手順を定義してもよい。ＬＢＴ失敗もしくは連続ＬＢＴ失
敗が、設定された最大ＬＢＴ失敗閾値を超えた場合、またはＬＢＴ成功もしくは連続ＬＢ
Ｔ成功が、設定された最小ＬＢＴ成功閾値未満であり得る場合にのみ、ランダムアクセス
手順が開始される。

【0179】

以下に別の例を示す。物理層がＳＲを送信するように指示されると、ＳＲ送信に対する
ＬＢＴ成功の判定時にのみ、ＳＲ禁止タイマが起動され、ＳＲカウンタがインクリメント
され得る。例えば、ＭＡＣ仕様を以下のように修正してもよい。
２＞ＭＡＣエンティティが、設定されたＳＲのための妥当なＰＵＣＣＨリソース上でＳＲ
送信機会を有する場合、および、
２＞ＳＲ送信機会時に、ｓｒ－ＰｒｏｈｉｂｉｔＴｉｍｅｒが実行されていない場合、お
よび
２＞ＳＲ送信機会のＰＵＣＣＨリソースが、測定ギャップと重複していない場合、および
、
２＞ＳＲ送信時のＰＵＣＣＨリソースが、ＵＬ－ＳＣＨリソースと重複していない場合、
３＞ＳＲ＿ＣＯＵＮＴＥＲ＜ｓｒ－ＴｒａｎｓＭａｘである場合、
４＞物理層に、ＳＲのための１つの妥当なＰＵＣＣＨリソース上でＳＲをシグナリングす
るように指示して、
ＬＢＴ成功と判定された場合、
５＞ｓｒ－ＰｒｏｈｉｂｉｔＴｉｍｅｒを起動して、
５＞ＳＲ＿ＣＯＵＮＴＥＲを１だけインクリメントする。

【0180】

あるいは、既存の手順で行われるように、ＳＲ禁止タイマが起動され、ＳＲカウンタが
インクリメントされてもよいが、ＬＢＴ失敗と判定された場合には、禁止タイマが停止さ
れてもよく、ＳＲカウンタがデクリメントされてもよい。

【0181】

この修正は、ＳＲカウンタがＳＲ Ｔｒａｎｓ Ｍａｘに到達しないことで、ＳＲ送信
がＬＢＴ失敗によってブロックされたときに、物理リソースを解放してＲＡ手順を開始す
るように、後続のＳＲ送信を遅延させるＳＲ禁止タイマが設定されないことを確実にする
ために、必要な場合がある。

【0182】

また、ＳＲ送信手順が成功しなかったとＵＥが決して判定しないように、ＬＢＴ失敗に
よりＳＲ送信カウンタを大幅にインクリメントしないこと、またはＳＲ送信カウンタを無
期限にインクリメントしないことを回避する必要がある場合もある。ＳＲ送信カウントを
インクリメントさせないことは、指定されたまたは設定された最大値に制限され得る。例
えば、ＭＡＣ仕様を以下のように修正してもよい。
２＞ＳＲ ＬＢＴ失敗が検出されなかった場合、または、
２＞ＳＲ－Ｔｒａｎｓｍｉｓｓｉｏｎ－ＬＢＴ－Ｆａｉｌｕｒｅ－Ｃｏｕｎｔ＞ＳＲ－Ｔ
ｒａｎｓｍｉｓｓｉｏｎ－ＬＢＴ－ＦａｉｌｕｒｅＴｈｒｅｓｈｏｌｄである場合、
３＞ＳＲ＿ＣＯＵＮＴＥＲを１だけインクリメントして、
３＞
２＞ＳＲＴｒａｎｓｍｉｓｓｉｏｎ－ＬＢＴ－Ｆａｉｌｕｒｅが検出された場合、
２＞ＳＲＴｒａｎｓｍｉｓｓｉｏｎ－ＬＢＴ－Ｆａｉｌｕｒｅ－Ｃｏｕｎｔをインクリメ
ントする。

【0183】

ＲＡ－ＰｒｅａｍｂｌｅＴｒａｎｓｍｉｓｓｉｏｎ－ＬＢＴ－ＦａｉｌｕｒｅＴｈｒｅ
ｓｈｏｌｄを超えた場合、以下のアクションを実行してもよいし、ＭＡＣ仕様を以下のよ
うに修正してもよい。
２＞ＳＲ－Ｔｒａｎｓｍｉｓｓｉｏｎ－ＬＢＴ－Ｆａｉｌｕｒｅが検出された場合、
２＞ＳＲ－Ｔｒａｎｓｍｉｓｓｉｏｎ－ＬＢＴ－Ｆａｉｌｕｒｅ－Ｃｏｕｎｔをインクリ
メントして、
２＞ＳＲ－Ｔｒａｎｓｍｉｓｓｉｏｎ－ＬＢＴ－Ｆａｉｌｕｒｅ－Ｃｏｕｎｔ＞ＳＴｒａ
ｎｓｍｉｓｓｉｏｎ－ＬＢＴ－ＦａｉｌｕｒｅＴｈｒｅｓｈｏｌｄである場合、

【0184】

以下に別の例を示す。ＢＳＲ送信に対するＬＢＴ成功が判定された場合にのみ、保留中
のＳＲ（単数または複数）がキャンセルされ得、ＳＲ禁止タイマが停止され得る。これは
、ＬＢＴ失敗により現在のＳＲが送信されないときに、後続のＳＲ送信を遅延させる禁止
タイマが設定されないことを確実にするために、必要な場合がある。

【0185】

例えば、ＭＡＣ ＰＤＵ送信に対してＬＢＴ成功が判定され、このＰＤＵが、ＭＡＣ
ＰＤＵアセンブリ前にＢＳＲ（［２］の５．４．５項を参照）をトリガした最後のイベン
トまでの（および含まれている）バッファ状態を有するＢＳＲ ＭＡＣ ＣＥを含む場合
、ＭＡＣ ＰＤＵアセンブリ前にトリガされた保留中のＳＲは全てキャンセルされるもの
とし、それぞれのｓｒ－ＰｒｏｈｉｂｉｔＴｉｍｅｒは停止されるものとする。

【0186】

上記の例は、ＬＢＴ成功検出の代わりに、ＬＢＴ失敗検出の観点から以下のように表さ
れてもよい。ＭＡＣ ＰＤＵ送信に対してＬＢＴ失敗が判定されず、このＰＤＵが、ＭＡ
Ｃ ＰＤＵアセンブリ前にＢＳＲ（［２］の５．４．５項を参照）をトリガした最後のイ
ベントまでの（および含まれている）バッファ状態を有するＢＳＲ ＭＡＣ ＣＥを含む
場合、ＭＡＣ ＰＤＵアセンブリ前にトリガされた保留中のＳＲは全てキャンセルされる
ものとし、それぞれのｓｒ－ＰｒｏｈｉｂｉｔＴｉｍｅｒは停止されるものとする。

【0187】

あるいは、ＢＳＲを含むＭＡＣ ＰＤＵがＰＨＹ層に提供されると、既存の手順で行わ
れるように、保留中のＳＲ（単数または複数）がキャンセルされてもよく、禁止タイマが
停止されてもよいが、ＬＢＴの失敗（または、ＬＢＴ成功なしと同様な意味合いで）が判
定された場合には、保留中のＳＲ（単数または複数）が復元され、禁止タイマが再起動さ
れてもよい。

【0188】

（バッファステータス報告）
ＢＳＲ手順の以下の修正は、ＮＲ－ＵにおけるＬＢＴの影響を考慮に入れる。

【0189】

規則的なＢＳＲがトリガされ、送信に利用可能なＵＬ－ＳＣＨリソースがあり得るが、
ＬＢＴ失敗によって送信がブロックされている場合、ＳＲがトリガされ得る。ＬＢＴ失敗
により利用可能なグラントが損失した場合、後続のグラントがＢＳＲの送信に利用可能に
なるようにするために新しいＳＲが必要になることがあるため、これが必要になる場合が
ある。例えば、ＭＡＣ仕様を以下のように修正してもよい。
２＞規則的なＢＳＲがトリガされ、ｌｏｇｉｃａｌＣｈａｎｎｅｌＳＲ－ＤｅｌａｙＴｉ
ｍｅｒが実行されていない場合、
３＞新しい送信に利用可能なＵＬ－ＳＣＨリソースがない場合、または、
３＞ＭＡＣエンティティに設定されたアップリンクグラント（単数または複数）が設定さ
れており、上位層によって論理チャネルＳＲマスキング（ｌｏｇｉｃａｌＣｈａｎｎｅｌ
ＳＲ－Ｍａｓｋ）が設定されている論理チャネルに対して規則的なＢＳＲがトリガされな
かった場合、または、
３＞新しい送信に利用可能なＵＬ－ＳＣＨリソースが、ＢＳＲ（単数または複数）をトリ
ガした論理チャネル（単数または複数）に設定されたＬＣＰマッピング制限（［２］の５
．４．３．１節を参照）を満たさない場合、または、
３＞送信に利用可能なＵＬ－ＳＣＨリソースがあり、この送信に対してＬＢＴ失敗が検出
された場合、
４＞スケジューリング要求をトリガする。

【0190】

上記の修正テキストは、ＬＢＴ失敗の観点から記載されているが、ＬＢＴ成功なしの観
点からも表されてもよい。

【0191】

ＬＢＴ失敗またはＬＢＴ成功は、単一のインスタンスではないことがある。複数のＬＢ
Ｔ失敗または成功の検出であってもよい。ＳＲは、ＭＡＣ ＢＳＲ ＣＥ送信に影響を及
ぼす一連のＬＢＴ失敗後にのみトリガされてもよい。

【0192】

また、ＬＢＴ失敗もしくはＬＢＴ成功をカウントする、または連続ＬＢＴ失敗もしくは
連続ＬＢＴ成功をカウントするように手順を定義してもよい。ＬＢＴ失敗もしくは連続Ｌ
ＢＴ失敗が設定された最大ＬＢＴ失敗閾値を超えた場合、またはＬＢＴ成功もしくは連続
ＬＢＴ成功が設定された最小ＬＢＴ成功閾値未満であり得る場合にのみ、ＳＲがトリガさ
れる。

【0193】

ＢＳＲ ＭＡＣ ＣＥの送信がＬＢＴ失敗によってブロックされ、時間をおいて再送信
される場合、ＢＳＲがいつ計算されたかをＮＢに通知するため、またはＰＨＲが計算され
たときの送信条件をＮＢに通知するために、追加のシグナリングが導入される。

【0194】

ＮＢがＢＳＲを適切に処理するためには、ＢＳＲがいつ計算されたかをＮＢが認識する
ことが必要な場合がある。

【0195】

アンライセンス周波数帯で動作しておらず、ＬＢＴが使用されていない場合、ＮＢはＢ
ＳＲの内容がいつ判定されたかを概ね取得し得る。ＮＢはスケジュールされたものおよび
受信されたもの、ならびにＢＳＲの規則を認識しているため、ＢＳＲを適切に解釈し得る
。しかし、ＬＢＴが失敗し、ＬＢＴが成功するまで送信が遅延すると、ＮＢは古くなった
ＢＳＲまたは不正確なＢＳＲを受信することがあり、場合により、ＵＥによって必要とさ
れるよりも多いリソース割り当て、もしくはＵＥによって必要とされるよりも少ないリソ
ース、または送信遅延およびＱｏＳ保証のペナルティにつながる。以下に、この問題に対
処するための複数の方法を示す。第１の方法では、ＢＳＲの計算がいつ構築されたのかを
ＮＢが判定できるような追加の表示をＢＳＲに提供する。これは、最初のＬＢＴ失敗の時
間に対するＬＢＴによる遅延であってもよく、または絶対時間基準であってもよい。第２
の方法では、ＢＳＲのためのＬＢＴによって被った実効遅延をＮＢが判定し得るように、
ＬＢＴの失敗または成功がＮＢに独立して示されてもよい。第３の方法では、ＰＨＲが計
算されたときに使用されたグラント（例えば、アップリンクグラント）をＮＢに通知する
追加情報をＰＨＲと共に提供する。

【0196】

ＢＳＲがいつ構築されたかをＮＢが認識することができる追加情報を受信することが好
ましいが、必要というわけではない。あるいは、ＢＳＲが不正確な情報を提供している場
合、ＮＢは少なくとも認識しなければならない。これは、ＵＥがＮＢにＬＢＴ失敗および
成功を示すことで、ＢＳＲを遅延させたＬＢＴ失敗があったことをＮＢが判定できるよう
にすることにより、実現され得る。

【0197】

以下に別の例を示す。ＢＳＲのトリガ条件は、ＬＢＴ失敗を考慮すべきである。新しい
データが利用可能になり、現在指定されている規則的なＢＳＲトリガ基準、パディングＢ
ＳＲトリガ条件、ＢＳＲ再送信タイマ満了、ＢＳＲ周期タイマ満了のトリガ基準を満たす
には、ＬＢＴが成功した場合にのみ考慮するべきである。ＬＢＴ基準の追加は、既存の各
トリガに対して相互に排他的であり、したがって、既存の基準のサブセットにのみ影響を
与え得る。

【0198】

例えば（全てのトリガを考慮する場合）、ＭＡＣ仕様は以下のように修正されてもよい
。
以下のイベントのいずれかが発生した場合、ＢＳＲがトリガされるものとする。
・ＭＡＣエンティティが、ＬＣＧに属する論理チャネルで利用可能な新しいＵＬデータを
有し、および、
・新しいＵＬデータが、いずれかのＬＣＧに属する利用可能なＵＬデータを含むどの論理
チャネルの優先度よりも高い優先度を持つ論理チャネルに属し、ＬＢＴがその後成功する
、または、
・ＬＣＧに属する論理チャネルのいずれにも利用可能なＵＬデータが含まれておらず、Ｌ
ＢＴがその後成功する。
この場合、ＢＳＲは、以下のように「規則的なＢＳＲ」と呼ばれる、
・ＵＬリソースが割り当てられ、パディングビット数がバッファステータス報告ＭＡＣ
ＣＥとそのサブヘッダを加えたサイズ以上であり、ＬＢＴがその後成功した場合、ＢＳＲ
は以下のように「パディングＢＳＲ」と呼ばれる、
・ｒｅｔｘＢＳＲ－Ｔｉｍｅｒが満了し、ＬＣＧに属する論理チャネルのうち少なくとも
１つにＵＬデータが含まれており、ＬＢＴがその後成功した場合、そのＢＳＲを以下のよ
うに「規則的なＢＳＲ」と呼ばれる、
・ｐｅｒｉｏｄｉｃＢＳＲ－Ｔｉｍｅｒが満了し、ＬＢＴがその後成功した場合、ＢＳＲ
は以下のように「周期的なＢＳＲ」と呼ばれる。
ＭＡＣエンティティは、以下であるものとする。
１＞バッファステータス報告手順により、少なくとも１つのＢＳＲがトリガされて、キャ
ンセルされていないと判定された場合、
２＞ＵＬ－ＳＣＨのリソースが新しい送信に利用可能であり、ＬＢＴ成功と判定された場
合、
３＞ＢＳＲ ＭＡＣ ＣＥ（単数または複数）を生成するように、多重化およびアセンブ
リ手順に指示して、
３＞生成されたＢＳＲが全てロングまたはショートのトランケートＳＲの場合を除き、ｐ
ｅｒｉｏｄｉｃＢＳＲ－Ｔｉｍｅｒを起動または再起動して、
３＞ｒｅｔｘＢＳＲ－Ｔｉｍｅｒを起動または再起動する。

【0199】

複数のイベントがＢＳＲをトリガした場合でも、ＭＡＣ ＰＤＵは最大で１つのＢＳＲ
ＭＡＣ ＣＥを含むものとする。規則的なＢＳＲおよび周期的なＢＳＲは、パディング
ＢＳＲよりも優先されるものとする。

【0200】

ＭＡＣエンティティは、任意のＵＬ－ＳＣＣＨで新しいデータの送信に対するグラント
を受信すると、ｒｅｔｘＢＳＲ－Ｔｉｍｅｒを再起動するものとする。

【0201】

ＵＬグラント（単数または複数）が送信可能な全ての保留データに適応でき、ＬＢＴ成
功が判定されたが、追加的にＢＳＲ ＭＡＣ ＣＥとそのサブヘッダに適応するには十分
ではないとき、トリガされた全てのＢＳＲはキャンセルされ得る。ＬＢＴ成功が判定され
、ＢＳＲ ＭＡＣ ＣＥを含むＭＡＣ ＰＤＵが送信されたとき、ＭＡＣ ＰＤＵアセン
ブリ前にトリガされた全てのＢＳＲは、キャンセルされるものとする。
上記の修正テキストは、ＬＢＴ成功の観点から記載されているが、ＬＢＴ失敗なしの観
点からも表されてもよい。

【0202】

ＬＢＴ失敗またはＬＢＴ成功は、単一のインスタンスではないことがある。複数のＬＢ
Ｔ失敗または成功の検出であってもよい。ＳＲは、ＭＡＣ ＢＳＲ ＣＥ送信に影響を及
ぼす一連のＬＢＴ失敗後にのみトリガされてもよい。

【0203】

また、ＬＢＴ失敗もしくはＬＢＴ成功をカウントする、あるいは連続ＬＢＴ失敗もしく
は連続ＬＢＴ成功をカウントするように手順を定義してもよい。ＬＢＴ失敗もしくは連続
ＬＢＴ失敗が、設定された最大ＬＢＴ失敗閾値を超えた場合、またはＬＢＴ成功もしくは
連続ＬＢＴ成功が、設定された最小ＬＢＴ成功閾値未満であり得る場合にのみ、ＳＲがト
リガされる。

【0204】

上記の例示的なＭＡＣ固有の変更は、ＬＢＴ成功の観点から記載されているが、例はＬ
ＢＴ失敗なしの観点からも同様に表されてもよい。

【0205】

あるいは、ＢＳＲ周期タイマおよびＢＳＲ再送信タイマは、既存の手順で行われるよう
に起動または再起動してもよいが、ＬＢＴ失敗と判定された場合には、ＢＳＲ周期タイマ
およびＢＳＲ再送信タイマをＬＢＴ失敗による最後のリセット前の残りの値に、または、
例えば設定された時間値などの異なる時間値にリセットされる。

【0206】

この修正は、ＢＳＲの送信がＬＢＴ失敗によってブロックされたときに、ＢＳＲの周期
的な送信またはＢＳＲの再送信が遅延しないように、ＢＳＲ周期タイマまたはＢＳＲ再送
信タイマがリセットされ得ないことを確実にするために、必要となる場合がある。

【0207】

（論理チャネル優先順位付け（ＬＣＰ）手順
）
ＬＣＰ手順の以下の修正は、ＮＲ－ＵにおけるＬＢＴの影響を考慮に入れてもよい。

【0208】

送信前にＬＢＴ失敗が検出された場合、ＭＡＣ ＰＤＵは生成されるべきではない。

【0209】

例えば、ＭＡＣ仕様を以下のように修正してもよい。

【0210】

ＭＡＣエンティティは、以下の条件を満たす場合、ＨＡＲＱエンティティのＭＡＣ Ｐ
ＤＵを生成しないものとする。
・ＭＡＣエンティティがｓｋｉｐＵｐｌｉｎｋＴｘＤｙｎａｍｉｃに設定されており、Ｈ
ＡＲＱエンティティに示されたグラントがＣ－ＲＮＴＩに宛てられたものであるか、また
はＨＡＲＱエンティティに示されたグラントが設定されたアップリンクグラントである、
および、
・ＴＳ３８．２１２に規定されているように、このＰＵＳＣＨ送信に対して要求された非
周期的なＣＳＩがない、および、
・ＭＡＣ ＰＤＵは、０個のＭＡＣ ＳＤＵを含む、および、
・ＭＡＣ ＰＤＵには周期的なＢＳＲのみが含まれ、いずれのＬＣＧにも利用可能なデー
タがないか、またはＭＡＣ ＰＤＵにはパディングＢＳＲのみが含まれている、または、
・ＬＢＴ失敗が検出されなかった。

【0211】

あるいは、ＬＢＴ成功が検出されたことを基準にしてもよい。

【0212】

この修正は、このＭＡＣ ＰＤＵが後続のグラントに受け入れられないことがあり（例
えば、ＵＬグラントのサイズのため）、また、生成されたＭＡＣ ＣＥ（単数または複数
）がＭＡＣ ＰＤＵ送信時に誤った情報（例えば、ＰＨＲ、ＢＳＲ．．．）を提供し得る
ために、必要となる場合がある。

【0213】

以下に別の例を示す。あるいは、ＭＡＣ ＰＤＵを生成して物理層に提供してもよいが
、このＭＡＣ ＰＤＵのＬＢＴ失敗が検出されると、ＬＣＰ手順を再起動して新しいＭＡ
Ｃ ＰＤＵを生成する。

【0214】

これを達成するために、このＭＡＣ ＰＤＵ内に組み込まれていたＭＡＣ ＳＤＵは、
ＬＢＴ成功が判定されるまで保存されてもよい。これらのＭＡＣ ＳＤＵは、すでに構築
されたＭＡＣ ＰＤＵからこれらのＭＡＣ ＳＤＵを再作成しなければならないのではな
く、再処理し得る。

【0215】

より単純な事例としては、グラントがより大きい場合、ＵＥがパディングを除去し、Ｌ
ＣＰに従って残りのスペースで追加データを多重化するか、またはＵＥがサブＰＤＵ（Ｍ
ＡＣ ＳＤＵおよびＣＥ）をバックアウトして、前回のグラントに対してデータが処理さ
れなかったかのようにＬＣＰを再形成することである。

【0216】

しかし、この場合でも、ＬＡＡで以前に判定されたＭＡＣ ＣＥをすでに構築しており
、古いＰＨＲ ＣＥを許可している場合がある。その場合、ネットワークは、どのような
送信に基づいて、ＰＨＲがどのように計算されたのかわからないことがある。

【0217】

ＭＡＣ手順（ＢＳＲ、ＰＨＲ．．．）のタイマおよびカウンタは前回の（失敗した）送
信によってすでに影響を受けているため、ＣＥの再構築は複雑である。

【0218】

ＭＡＣ ＰＤＵの多重化およびアセンブリが再実行されたときに、トリガが再評価され
、報告された値が再計算されるように、ＭＡＣ ＣＥは回復して保存され得るか、または
これらのＭＡＣ ＣＥをトリガしたイベントが復元され得る。

【0219】

さらに複雑な事例は、グラントがより小さいときにどうするかである。最初に、ＬＣＰ
に従って、前回のＰＤＵから何が送信され得るかを判定する。次に、送信されないことが
あるＭＡＣ ＳＤＵを回復し、ＭＡＣ ＣＥの送信に関連付けられたＭＡＣ手順のタイマ
およびカウンタをリセットして、ＭＡＣ ＣＥが構築される前の値にタイマおよびカウン
タを設定し得る。

【0220】

前回の送信以降に、新たに優先度の高いデータまたはその他のＭＡＣ ＣＥのトリガと
なるイベントが受信された可能性がある。この可能性に対処するために、多重化アセンブ
リ手順は、失敗したＭＡＣ ＰＤＵ送信に関連付けられたＭＡＣ ＳＤＵを優先しないこ
とがある。

【0221】

ＭＡＣ ＣＥにも同様の問題が発生することがあり、これらは今では古くなり、ＭＡＣ
手順をバックアウトすることが複雑である。

【0222】

ＮＢはＭＡＣ ＣＥの送信が遅延したこと、または元々送信が予定されていたときを通
知すべきである。

【0223】

別の問題は、セグメンテーションがＲＬＣで実行され、ＭＡＣのＳＤＵが大きすぎる可
能性があることである。ＭＡＣ要求ＲＬＣに前回のＲＬＣ ＰＤＵをバックアウトさせる
ことは、非常に複雑である。これに対処する１つの方法は、このＭＡＣ ＳＤＵに対応す
るＲＬＣ ＰＤＵ、および新しいＭＡＣ ＰＤＵ送信に多重化されない場合がある他のＳ
ＤＵに対して、ＲＬＣ否定応答を偽装することである。

【0224】

（ビーム障害検出および回復）
ビーム障害および検出手順の以下の修正は、ＮＲ－ＵにおけるＬＢＴの影響を考慮に入
れる。ビーム障害回復タイマが満了しても、ビーム障害回復のためのランダムアクセス手
順の開始以降にＬＢＴ失敗が検出された場合、ビーム障害回復タイマを延長するべきであ
る。これは、ビーム障害回復タイマの早期満了、および場合によりセル再選択またはＲＲ
Ｃ（再）確立を回避するために、必要な場合がある。

【0225】

図２～図１０など、本明細書に示されているステップを実行するエンティティは、論理
エンティティによって実行されてもよいことが理解される。ステップは、図１２Ａ～図１
２Ｇに示されているようなデバイス、サーバ、またはコンピュータシステムのメモリに保
存され、そのプロセッサ上で実行されてもよい。本明細書に開示されている例示的な方法
の間で、ステップをスキップすること、ステップを組み合わせること、またはステップを
追加することが意図されている。

【0226】

表１は、例示的な略語または定義を提供する。

【0227】

【表1-1】

【0228】

【表1-2】

【0229】

【表1-3】

【0230】

図１１は、本明細書で説明したＮＲ－Ｕ ＬＢＴ ＭＡＣ手順の方法、システム、およ
びデバイスに基づいて生成され得る例示的なディスプレイ（例えば、グラフィカルユーザ
インタフェース）を示す。ディスプレイインタフェース９０１（例えば、タッチスクリー
ンディスプレイ）は、特に、ＰＨＲ関連パラメータおよび方法フローなど、ＮＲ－Ｕ Ｌ
ＢＴ ＭＡＣ手順に関連付けられたブロック９０２のテキストを提供してもよい。本明細
書で説明したステップのいずれかの進捗（例えば、送信されたメッセージまたはステップ
の成功）をブロック９０２に表示してもよい。さらに、グラフィカル出力９０２が、ディ
スプレイインタフェース９０１に表示されてもよい。グラフィカル出力は、ＮＲ－Ｕ Ｌ
ＢＴ ＭＡＣ手順の方法、システム、およびデバイスを実装するデバイスのトポロジー、
本明細書で議論される任意の方法またはシステムの進捗のグラフィカル出力などであって
もよい。

【0231】

第３世代パートナーシッププロジェクト（3rd Generation Partnership Project：
３ＧＰＰ）は、無線アクセス、コアトランスポートネットワーク、ならびに、コーデック
、セキュリティ、およびサービス品質に関する作業を含むサービス能力を含む、セルラー
通信ネットワーク技術の技術標準を開発している。最近の（Radio Access Technology
：ＲＡＴ）標準には、ＷＣＤＭＡ（登録商標）（一般に３Ｇと呼ばれる）、ＬＴＥ（一般
に４Ｇと呼ばれる）、ＬＴＥ－Ａｄｖａｎｃｅｄ標準、および「５Ｇ」とも呼ばれる新し
い無線技術（New Radio：ＮＲ）がある。３ＧＰＰ ＮＲ標準の開発は今後も継続される
と予想されており、次世代無線アクセス技術（新ＲＡＴ）の定義が含まれる。これには、
７ＧＨｚ未満の新しいフレキシブル無線アクセスの提供、および７ＧＨｚを超える新しい
ウルトラモバイルブロードバンド無線アクセスの提供が含まれると予想されている。フレ
キシブル無線アクセスは、６ＧＨｚ未満の新しい周波数帯での後方互換性のない新しい無
線アクセスで構成され、同じ周波数帯で多重化され得る異なる動作モードを含むことで、
要件が異なる幅広い３ＧＰＰ ＮＲユースケースに対処することが予想されている。ウル
トラモバイルブロードバンドには、例えば、屋内用途およびホットスポットなどのウルト
ラモバイルブロードバンドアクセスの機会を提供するセンチ波およびミリ波の周波数帯が
含まれることが予想されている。特にウルトラモバイルブロードバンドでは、センチ波お
よびミリ波専用の設計最適化により、７ＧＨｚ未満のフレキシブル無線アクセスと共通の
設計フレームワークを共有することが予想されている。

【0232】

３ＧＰＰでは、ＮＲがサポートすることが予想される様々なユースケースが特定されて
おり、その結果、データレート、レイテンシ、およびモビリティに関する多種多様なユー
ザ体験の要件が生じている。ユースケースには、以下のような一般的なカテゴリ、拡張モ
バイルブロードバンド（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：Ｖ２Ｐ）、および他のエ
ンティティとの車両通信のいずれかを含み得るものが含まれる。これらのカテゴリにおけ
る特定のサービスおよび用途には、例えば、モニタリングおよびセンサネットワーク、デ
バイスの遠隔操作、双方向の遠隔操作、パーソナルクラウドコンピューティング、ビデオ
ストリーミング、ワイヤレスクラウドベースのオフィス、ファーストレスポンダの接続性
、自動車緊急通報システム、災害警報、リアルタイムゲーミング、複数人でのビデオ通話
、自動運転、拡張現実、タッチインターネット、仮想現実、ホームオートメーション、ロ
ボット、および空中ドローンが、ほんの一部の例として挙げられる。これらのユースケー
スの全ておよびその他のユースケースが、本明細書で意図されている。

【0233】

図１２Ａは、本明細書で記載および請求された図１から図１０に示されたシステムおよ
び方法などの、ＮＲ－Ｕ ＬＢＴ ＭＡＣ手順の方法および装置が使用され得る例示的な
通信システム１００を示す。通信システム１００は、無線送受信ユニット（Wireless Tr
ansmit/Receive Unit：ＷＴＲＵ）１０２ａ、１０２ｂ、１０２ｃ、１０２ｄ、１０２ｅ
、１０２ｆ、または１０２ｇ（これらは、一般的または集合的に、ＷＴＲＵ１０２または
ＷＴＲＵ１０２と呼ばれることがある）を含んでもよい。通信システム１００は、無線ア
クセスネットワーク（Radio Access Network：ＲＡＮ）１０３／１０４／１０５／１０
３ｂ／１０４ｂ／１０５ｂ、コアネットワーク１０６／１０７／１０９、公衆交換電話網
（Public Switched Telephone Network：ＰＳＴＮ）１０８、インターネット１１０、
他のネットワーク１１２、およびネットワークサービス１１３を含んでもよい。ネットワ
ークサービス１１３は、例えば、Ｖ２Ｘサーバ、Ｖ２Ｘ機能、ＰｒｏＳｅサーバ、Ｐｒｏ
Ｓｅ機能、ＩｏＴサービス、ビデオストリーミング、またはエッジコンピューティングな
どを含んでもよい。

【0234】

本明細書に開示された概念は、任意の数のＷＴＲＵ、基地局、ネットワーク、またはネ
ットワーク要素と共に使用されてもよいことが理解されるであろう。ＷＴＲＵ１０２ａ、
１０２ｂ、１０２ｃ、１０２ｄ、１０２ｅ、１０２ｆ、または１０２ｇのそれぞれは、無
線環境で動作または通信するように構成された任意のタイプの装置またはデバイスであっ
てもよい。各ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄ、１０２ｅ、１０２ｆ、
または１０２ｇは、図１２Ａ、図１２Ｂ、図１２Ｃ、図１２Ｄ、図１２Ｅ、または図１２
Ｆに、ハンドヘルド無線通信装置として図示されている場合があるが、５Ｇ無線通信に意
図されている多種多様なユースケースでは、各ＷＴＲＵは、ワイヤレス信号を送信もしく
は受信するように構成された任意のタイプの装置もしくはデバイスを含んでもよく、また
は具体化されてもよいことが理解され、ほんの一例として、ユーザ機器（User Equipmen
t：ＵＥ）、移動局、固定または移動加入者ユニット、ポケットベル、セルラー電話、パ
ーソナルデジタルアシスタント（Personal Digital Assistant：ＰＤＡ）、スマートフ
ォン、ラップトップ、タブレット、ネットブック、ノートブックコンピュータ、パーソナ
ルコンピュータ、無線センサ、家電製品、スマートウォッチまたはスマートウェアなどの
ウェアラブルデバイス、医療または電子ヘルスデバイス、ロボット、産業機器、ドローン
、自動車、バス、トラック、列車、または飛行機などの車両などが含まれる。

【0235】

通信システム１００はまた、基地局１１４ａおよび基地局１１４ｂを含んでもよい。図
１２Ａの例では、各基地局１１４ａおよび１１４ｂは、単一の要素として図示されている
。実際には、基地局１１４ａおよび１１４ｂは、任意の数の相互接続された基地局または
ネットワーク要素を含んでもよい。基地局１１４ａは、コアネットワーク１０６／１０７
／１０９、インターネット１１０、ネットワークサービス１１３、または他のネットワー
ク１１２などの１つ以上の通信ネットワークへのアクセスを容易にするために、ＷＴＲＵ
１０２ａ、１０２ｂ、および１０２ｃのうちの少なくとも１つと無線でインタフェースす
るように構成された任意のタイプのデバイスであってもよい。同様に、基地局１１４ｂは
、コアネットワーク１０６／１０７／１０９、インターネット１１０、他のネットワーク
１１２、またはネットワークサービス１１３などの１つ以上の通信ネットワークへのアク
セスを容易にするために、遠隔無線ヘッド（Remote Radio Head：ＲＲＨ）１１８ａ、
１１８ｂ、送受信ポイント（Transmission and Reception Point：ＴＲＰ）１１９ａ
、１１９ｂ、または路側機（Roadside Unit：ＲＳＵ）１２０ａ、１２０ｂの少なくとも
１つと有線または無線でインタフェースするように構成された任意のタイプのデバイスで
あってもよい。ＲＲＨ１１８ａ、１１８ｂは、コアネットワーク１０６／１０７／１０９
、インターネット１１０、ネットワークサービス１１３、または他のネットワーク１１２
などの１つ以上の通信ネットワークへのアクセスを容易にするために、ＷＴＲＵ１０２の
少なくとも１つ、例えばＷＴＲＵ１０２ｃと無線でインタフェースするように構成された
任意のタイプのデバイスであってもよい。

【0236】

ＴＲＰ１１９ａ、１１９ｂは、コアネットワーク１０６／１０７／１０９、インターネ
ット１１０、ネットワークサービス１１３、または他のネットワーク１１２などの１つ以
上の通信ネットワークへのアクセスを容易にするために、ＷＴＲＵ１０２ｄの少なくとも
１つと無線でインタフェースするように構成された任意のタイプのデバイスであってもよ
い。ＲＳＵ１２０ａおよび１２０ｂは、コアネットワーク１０６／１０７／１０９、イン
ターネット１１０、他のネットワーク１１２、またはネットワークサービス１１３などの
１つ以上の通信ネットワークへのアクセスを容易にするために、ＷＴＲＵ１０２ｅまたは
１０２ｆの少なくとも１つと無線でインタフェースするように構成された任意のタイプの
デバイスであってもよい。例として、基地局１１４ａ、１１４ｂは、無線基地局装置（Ba
se Transceiver Station：ＢＴＳ）、ノードＢ、ｅノードＢ、ホームノードＢ、ホーム
ｅノードＢ、次世代ノードＢ（Next Generation Node-B：ｇノードＢ）、衛星、サイト
コントローラ、アクセスポイント（Access Point：ＡＰ）、無線ルータなどであっても
よい。

【0237】

基地局１１４ａは、ＲＡＮ１０３／１０４／１０５の一部であってもよく、これは、基
地局コントローラ（Base Station Controller：ＢＳＣ）、無線ネットワークコントロ
ーラ（Radio Network Controller：ＲＮＣ）、中継ノードなどの他の基地局またはネッ
トワーク要素（図示せず）も含んでいてもよい。同様に、基地局１１４ｂは、ＲＡＮ１０
３ｂ／１０４ｂ／１０５ｂの一部であってもよく、これは、ＢＳＣ、ＲＮＣ、中継ノード
などの他の基地局またはネットワーク要素（図示せず）も含んでいてもよい。基地局１１
４ａは、セル（図示せず）と呼ばれ得る特定の地理的領域内で、無線信号を送信または受
信するように構成されてもよい。同様に、基地局１１４ｂは、本明細書に開示されている
ようなＮＲ－Ｕ ＬＢＴ ＭＡＣ手順の方法、システム、およびデバイスのための、セル
（図示せず）と呼ばれ得る特定の地理的領域内で、有線または無線信号を送信または受信
するように構成されてもよい。同様に、基地局１１４ｂは、セル（図示せず）と呼ばれ得
る特定の地理的領域内で、有線信号または無線信号を送信または受信するように構成され
てもよい。セルは、さらに、セルセクタに分割されてもよい。例えば、基地局１１４ａに
関連付けられたセルは、３つのセクタに分割されてもよい。したがって、一実施例では、
基地局１１４ａは、例えば、セルの各セクタに１つずつ、３つのトランシーバを含んでも
よい。一実施例では、基地局１１４ａは、多入力多出力（Multiple-Input Multiple Ou
tput：ＭＩＭＯ）技術を採用してもよく、したがって、セルの各セクタにつきの複数のト
ランシーバを利用してもよい。

【0238】

基地局１１４ａは、エアインタフェース１１５／１１６／１１７を介して、ＷＴＲＵ１
０２ａ、１０２ｂ、１０２ｃ、または１０２ｇの１つ以上と通信してもよく、任意の適切
な無線通信リンク（例えば、無線周波数（Radio Frequency：ＲＦ）、マイクロ波、赤外
線（Infrared：ＩＲ）、紫外線（Ultraviolet：ＵＶ）、可視光、センチ波、ミリ波など
）であってもよい。エアインタフェース１１５／１１６／１１７は、任意の適切な無線ア
クセス技術（ＲＡＴ）を使用して確立されてもよい。

【0239】

基地局１１４ｂは、有線またはエアインタフェース１１５ｂ／１１６ｂ／１１７ｂを介
して、ＲＲＨ１１８ａ、１１８ｂ、ＴＲＰ１１９ａ、１１９ｂ、またはＲＳＵ１２０ａ、
１２０ｂのうちの１つ以上と通信してもよく、これは、任意の適切な有線（例えば、ケー
ブル、光ファイバなど）または無線通信リンク（例えば、無線周波数（ＲＦ）、マイクロ
波、赤外線（ＩＲ）、紫外線（ＵＶ）、可視光、センチ波、ミリ波など）であってもよい
。エアインタフェース１１５ｂ／１１６ｂ／１１７ｂは、任意の適切な無線アクセス技術
（ＲＡＴ）を使用して確立されてもよい。

【0240】

ＲＲＨ１１８ａ、１１８ｂ、ＴＲＰ１１９ａ、１１９ｂまたはＲＳＵ１２０ａ、１２０
ｂは、エアインタフェース１１５ｃ／１１６ｃ／１１７ｃを介して、ＷＴＲＵ１０２ｃ、
１０２ｄ、１０２ｅ、１０２ｆの１つ以上と通信してもよく、これは、任意の適切な無線
通信リンク（例えば、無線周波数（ＲＦ）、マイクロ波、赤外線（ＩＲ）、紫外線（ＵＶ
）、可視光、センチ波、ミリ波など）であってもよい。エアインタフェース１１５ｃ／１
１６ｃ／１１７ｃは、任意の適切な無線アクセス技術（ＲＡＴ）を使用して確立されても
よい。

【0241】

ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ，１０２ｄ、１０２ｅ、または１０２ｆは、サ
イドリンク通信などのエアインタフェース１１５ｄ／１１６ｄ／１１７ｄを介して互いに
通信してもよく、これは、任意の適切な無線通信リンク（例えば、無線周波数（ＲＦ）、
マイクロ波、赤外線（ＩＲ）、紫外線（ＵＶ）、可視光、センチ波、ミリ波など）であっ
てもよい。エアインタフェース１１５ｄ／１１６ｄ／１１７ｄは、任意の適切な無線アク
セス技術（ＲＡＴ）を使用して確立されてもよい。

【0242】

通信システム１００は、多重アクセスシステムであってもよく、ＣＤＭＡ、ＴＤＭＡ、
ＦＤＭＡ、ＯＦＤＭＡ、ＳＣ－ＦＤＭＡなどの１つ以上のチャネルアクセス方式を採用し
てもよい。例えば、ＲＡＮ１０３／１０４／１０５における基地局１１４ａおよびＷＴＲ
Ｕ１０２ａ、１０２ｂ、１０２ｃ、またはＲＡＮ１０３ｂ／１０４ｂ／１０５ｂにおける
ＲＲＨ１１８ａ、１１８ｂ、ＴＲＰ１１９ａ、１１９ｂおよびＲＳＵ１２０ａ、１２０ｂ
ならびにＷＴＲＵ１０２ｃ、１０２ｄ、１０２ｅ、１０２ｆは、ユニバーサル移動体通信
システム（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：ＨＳＵＰＡ）を含んでもよい。

【0243】

一実施例では、基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、または
、ＲＡＮ１０３ｂ／１０４ｂ／１０５ｂにおけるＲＲＨ１１８ａ、１１８ｂ、ＴＲＰ１１
９ａ、１１９ｂ、もしくはＲＳＵ１２０ａ、１２０ｂおよびＷＴＲＵ１０２ｃ、１０２ｄ
は、発展型ＵＭＴＳ地上無線アクセス（Evolved UMTS Terrestrial Radio Access：
Ｅ－ＵＴＲＡ）などの無線技術を実装していてもよく、ロングタームエボリューション（
Long Term Evolution：ＬＴＥ）またはＬＴＥアドバンスト（LTE-Advanced：ＬＴＥ－
Ａ）を使用してエアインタフェース１１５／１１６／１１７または１１５ｃ／１１６ｃ／
１１７ｃをそれぞれ確立してもよい。将来的には、エアインタフェース１１５／１１６／
１１７または１１５ｃ／１１６ｃ／１１７ｃは、３ＧＰＰ ＮＲ技術を実装してもよい。
ＬＴＥおよびＬＴＥ－Ａ技術は、ＬＴＥ Ｄ２ＤおよびＶ２Ｘ技術ならびにインタフェー
ス（サイドリンク通信など）を含んでもよい。同様に、３ＧＰＰ ＮＲ技術は、ＮＲ Ｖ
２Ｘ技術およびインタフェース（サイドリンク通信など）を含む。

【0244】

ＲＡＮ１０３／１０４／１０５における基地局１１４ａならびにＷＴＲＵ１０２ａ、１
０２ｂ、１０２ｃ、および１０２ｇ、またはＲＡＮ１０３ｂ／１０４ｂ／１０５ｂにおけ
るＲＲＨ１１８ａ、１１８ｂ、ＴＲＰ１１９ａ、１１９ｂ、もしくはＲＳＵ１２０ａ、１
２０ｂおよびＷＴＲＵ１０２ｃ、１０２ｄ、１０２ｅ、１０２ｆは、ＩＥＥＥ８０２．１
６（例えば、ＷｉＭＡＸ（Worldwide Interoperability for Microwave Access））
、ＣＤＭＡ２０００、ＣＤＭＡ２０００ １Ｘ、ＣＤＭＡ２０００ ＥＶ－ＤＯ、暫定標
準２０００（Interim Standard 2000：ＩＳ－２０００）、暫定標準９５（Interim St
andard 95：ＩＳ－９５）、暫定標準８５６（Interim Standard 856：ＩＳ－８５６）
、ＧＳＭ（Global System for Mobile communication）（登録商標）、ＥＤＧＥ（En
hanced Data rates for GSM Evolution）、ＧＥＲＡＮ（GSM EDGE）などの無線技
術を実装していてもよい。

【0245】

図１２Ａの基地局１１４ｃは、例えば、無線ルータ、ホームノードＢ、ホームｅノード
Ｂ、またはアクセスポイントであってもよく、本明細書に開示されているように、ＮＲ－
Ｕ ＬＢＴ ＭＡＣ手順の方法、システム、およびデバイスを実装するために、事業所、
家、車両、列車、空中、衛星、製造所、キャンパスなどの局所的なエリアで無線接続性を
容易にするための任意の適切なＲＡＴを利用してもよい。一実施例では、基地局１１４ｃ
およびＷＴＲＵ１０２、例えば、ＷＴＲＵ１０２ｅは、無線ローカルエリアネットワーク
（Wireless Local Area Network：ＷＬＡＮ）を確立するために、ＩＥＥＥ８０２．１
１などの無線技術を実装してもよい。同様に、基地局１１４ｃおよびＷＴＲＵ１０２ｄは
、無線パーソナルエリアネットワーク（Wireless Personal Area Network：ＷＰＡＮ
）を確立するために、ＩＥＥＥ８０２．１５などの無線技術を実装してもよい。さらに別
の実施例では、基地局１１４ｃおよびＷＴＲＵ１０２、例えば、ＷＴＲＵ１０２ｅは、ピ
コセルまたはフェムトセルを確立するために、セルラーベースのＲＡＴ（例えば、ＷＣＤ
ＭＡ、ＣＤＭＡ２０００、ＧＳＭ、ＬＴＥ、ＬＴＥ－Ａ、ＮＲなど）を利用してもよい。
図１２Ａに示すように、基地局１１４ｃは、インターネット１１０への直接接続を有して
いてもよい。したがって、基地局１１４ｃは、コアネットワーク１０６／１０７／１０９
を介してインターネット１１０にアクセスする必要がなくてもよい。

【0246】

ＲＡＮ１０３／１０４／１０５またはＲＡＮ１０３ｂ／１０４ｂ／１０５ｂは、コアネ
ットワーク１０６／１０７／１０９と通信していてもよく、このネットワークは、音声、
データ、メッセージング、認可および認証、アプリケーション、またはボイスオーバーイ
ンターネットプロトコル（Voice Over Internet Protocol：ＶｏＩＰ）サービスをＷ
ＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄの１つ以上に提供するように構成された
任意のタイプのネットワークであってもよい。例えば、コアネットワーク１０６／１０７
／１０９は、呼制御、課金サービス、モバイル位置ベースサービス、プリペイドコーリン
グ、インターネット接続性、パケットデータネットワーク接続性、イーサネット（登録商
標）接続性、ビデオ配信などを提供してもよく、ユーザ認証などの高レベルのセキュリテ
ィ機能を実行してもよい。

【0247】

図１２Ａには示されていないが、ＲＡＮ１０３／１０４／１０５もしくはＲＡＮ１０３
ｂ／１０４ｂ／１０５ｂまたはコアネットワーク１０６／１０７／１０９は、ＲＡＮ１０
３／１０４／１０５もしくはＲＡＮ１０３ｂ／１０４ｂ／１０５ｂと同じＲＡＴまたは異
なるＲＡＴを採用する他のＲＡＮと、直接的にまたは間接的に通信してもよいことが理解
されるであろう。例えば、Ｅ－ＵＴＲＡ無線技術を利用し得るＲＡＮ１０３／１０４／１
０５またはＲＡＮ１０３ｂ／１０４ｂ／１０５ｂに接続されていることに加えて、コアネ
ットワーク１０６／１０７／１０９はまた、ＧＳＭまたはＮＲ無線技術を採用している別
のＲＡＮ（図示せず）と通信していてもよい。

【0248】

コアネットワーク１０６／１０７／１０９はまた、ＷＴＲＵ１０２ａ、１０２ｂ、１０
２ｃ、１０２ｄ、１０２ｅがＰＳＴＮ１０８、インターネット１１０、または他のネット
ワーク１１２にアクセスするためのゲートウェイとして機能してもよい。ＰＳＴＮ１０８
は、一般電話サービス（Plain Old Telephone Service：ＰＯＴＳ）を提供する回線交
換電話網を含んでもよい。インターネット１１０は、ＴＣＰ／ＩＰインターネットプロト
コルスイートにおける伝送制御プロトコル（Transmission Control Protocol：ＴＣＰ
）、ユーザデータグラムプロトコル（User Datagram Protocol：ＵＤＰ）、インターネ
ットプロトコル（Internet Protocol：ＩＰ）などの共通の通信プロトコルを使用する、
相互接続されたコンピュータネットワークおよびデバイスのグローバルシステムを含んで
もよい。ネットワーク１１２は、他のサービスプロバイダによって所有もしくは運営され
る有線または無線の通信ネットワークを含んでもよい。例えば、ネットワーク１１２は、
任意のタイプのパケットデータネットワーク（例えば、ＩＥＥＥ８０２．３イーサネット
ネットワーク）または１つ以上のＲＡＮに接続された別のコアネットワークを含んでもよ
く、これは、ＲＡＮ１０３／１０４／１０５もしくはＲＡＮ１０３ｂ／１０４ｂ／１０５
ｂと同じＲＡＴまたは異なるＲＡＴを採用してもよい。

【0249】

通信システム１００におけるＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄ、１０
２ｅ、および１０２ｆの一部または全ては、マルチモード能力を含んでもよく、例えば、
ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄ、１０２ｅ、および１０２ｆは、本明
細書に開示されているように、ＮＲ－Ｕ ＬＢＴ ＭＡＣ手順の方法、システム、および
デバイスを実装するために、異なる無線リンクを介して異なる無線ネットワークと通信す
るための複数のトランシーバを含んでもよい。例えば、図１２Ａに示すＷＴＲＵ１０２ｇ
は、セルラーベースの無線技術を採用し得る基地局１１４ａ、および、ＩＥＥＥ８０２の
無線技術を採用し得る基地局１１４ｃと通信するように構成されてもよい。

【0250】

図１２Ａには示されていないが、ユーザ機器は、ゲートウェイに有線接続を行ってもよ
いことが理解されるであろう。ゲートウェイは、レジデンシャルゲートウェイ（Resident
ial Gateway：ＲＧ）であってもよい。ＲＧは、コアネットワーク１０６／１０７／１０
９への接続性を提供してもよい。本明細書に含まれるアイデアの多くは、ＷＴＲＵである
ＵＥ、および有線接続を使用してネットワークに接続するＵＥにも同様に適用され得るこ
とが理解されるであろう。例えば、無線インタフェース１１５、１１６、１１７および１
１５ｃ／１１６ｃ／１１７ｃに適用されるアイデアは、有線接続にも同様に適用され得る
。

【0251】

図１２Ｂは、本明細書に開示されているように、ＮＲ－Ｕ ＬＢＴ ＭＡＣ手順の方法
、システム、およびデバイスを実装し得る例示的なＲＡＮ１０３およびコアネットワーク
１０６のシステム図である。上記のとおり、ＲＡＮ１０３は、エアインタフェース１１５
を介してＷＴＲＵ１０２ａ、１０２ｂ、および１０２ｃと通信するために、ＵＴＲＡ無線
技術を採用してもよい。ＲＡＮ１０３はまた、コアネットワーク１０６と通信していても
よい。図１２Ｂに示すように、ＲＡＮ１０３は、ノードＢ１４０ａ、１４０ｂ、および１
４０ｃを含んでもよく、これらはそれぞれ、エアインタフェース１１５を介してＷＴＲＵ
１０２ａ、１０２ｂ、および１０２ｃと通信するための１つ以上のトランシーバを含んで
もよい。ノードＢ１４０ａ、１４０ｂ、および１４０ｃはそれぞれ、ＲＡＮ１０３内の特
定のセル（図示せず）に関連付けられてもよい。ＲＡＮ１０３はまた、ＲＮＣ１４２ａ、
１４２ｂを含んでもよい。ＲＡＮ１０３は、任意の数のノードＢおよび無線ネットワーク
コントローラ（Radio Network Controller：ＲＮＣ）を含んでもよいことが理解される
であろう。

【0252】

図１２Ｂに示すように、ノードＢ１４０ａ、１４０ｂは、ＲＮＣ１４２ａと通信しても
よい。さらに、ノードＢ１４０ｃは、ＲＮＣ１４２ｂと通信していてもよい。ノードＢ１
４０ａ、１４０ｂ、および１４０ｃは、Ｉｕｂインタフェースを介して、それぞれのＲＮ
Ｃ１４２ａ、１４２ｂと通信してもよい。ＲＮＣ１４２ａ、および１４２ｂは、Ｉｕｒイ
ンタフェースを介して互いに通信してもよい。ＲＮＣ１４２ａ、および１４２ｂのそれぞ
れは、それが接続されているそれぞれのノードＢ１４０ａ、１４０ｂ、および１４０ｃを
制御するように構成されてもよい。さらに、ＲＮＣ１４２ａおよび１４２ｂのそれぞれは
、アウターループ電力制御、負荷制御、受付制御、パケットスケジューリング、ハンドオ
ーバー制御、マクロダイバシティ、セキュリティ機能、データ暗号化などの、他の機能性
を実行またはサポートするように構成されてもよい。

【0253】

図１２Ｂに示すコアネットワーク１０６は、メディアゲートウェイ（Media Gateway：
ＭＧＷ）１４４、モバイルスイッチングセンター（Mobile Switching Center：ＭＳＣ
）１４６、サービングＧＰＲＳサポートノード（Serving GPRS Support Node：ＳＧＳ
Ｎ）１４８、またはゲートウェイＧＰＲＳサポートノード（Gateway GPRS Support No
de：ＧＧＳＮ）１５０を含んでもよい。前述の各要素は、コアネットワーク１０６の一部
として図示されているが、これらの要素のいずれか１つは、コアネットワークオペレータ
以外のエンティティによって所有または運営されてもよいことが理解されるであろう。

【0254】

ＲＡＮ１０３内のＲＮＣ１４２ａは、ＩｕＣＳインタフェースを介して、コアネットワ
ーク１０６内のＭＳＣ１４６に接続されてもよい。ＭＳＣ１４６は、ＭＧＷ１４４に接続
されてもよい。ＭＳＣ１４６およびＭＧＷ１４４は、ＷＴＲＵ１０２ａ、１０２ｂ、およ
び１０２ｃに、ＰＳＴＮ１０８などの回線交換ネットワークへのアクセスを提供して、Ｗ
ＴＲＵ１０２ａ、１０２ｂ、および１０２ｃと、従来の陸上線通信デバイスとの間の通信
を容易にしてもよい。

【0255】

ＲＡＮ１０３内のＲＮＣ１４２ａはまた、ＩｕＰＳインタフェースを介して、コアネッ
トワーク１０６内のＳＧＳＮ１４８に接続されてもよい。ＳＧＳＮ１４８は、ＧＧＳＮ１
５０に接続されてもよい。ＳＧＳＮ１４８およびＧＧＳＮ１５０は、ＷＴＲＵ１０２ａ、
１０２ｂ、および１０２ｃに、インターネット１１０などのパケット交換ネットワークへ
のアクセスを提供して、ＷＴＲＵ１０２ａ、１０２ｂ、および１０２ｃと、ＩＰ対応デバ
イスとの間の通信を容易にしてもよい。

【0256】

コアネットワーク１０６はまた、他のサービスプロバイダによって所有または運営され
る他の有線または無線ネットワークを含み得る、他のネットワーク１１２に接続されても
よい。

【0257】

図１２Ｃは、本明細書に開示されているように、ＮＲ－Ｕ ＬＢＴ ＭＡＣ手順の方法
、システム、および装置を実装し得る、例示的なＲＡＮ１０４およびコアネットワーク１
０７のシステム図である。上記のとおり、ＲＡＮ１０４は、エアインタフェース１１６を
介してＷＴＲＵ１０２ａ、１０２ｂ、および１０２ｃと通信するために、Ｅ－ＵＴＲＡ無
線技術を採用してもよい。ＲＡＮ１０４はまた、コアネットワーク１０７と通信してもよ
い。

【0258】

ＲＡＮ１０４は、ｅノードＢ１６０ａ、１６０ｂ、および１６０ｃを含んでもよいが、
ＲＡＮ１０４は任意の数のｅノードＢを含んでもよいことが理解されるであろう。ｅノー
ドＢ１６０ａ、１６０ｂ、および１６０ｃはそれぞれ、エアインタフェース１１６を介し
て、ＷＴＲＵ１０２ａ、１０２ｂ、および１０２ｃと通信するための１つ以上のトランシ
ーバを含んでもよい。例えば、ｅノードＢ１６０ａ、１６０ｂ、および１６０ｃは、ＭＩ
ＭＯ技術を実装してもよい。したがって、ｅノードＢ１６０ａは、例えば、複数のアンテ
ナを使用して、ＷＴＲＵ１０２ａに無線信号を送信し、かつＷＴＲＵ１０２ａから無線信
号を受信してもよい。

【0259】

ｅノードＢ１６０ａ、１６０ｂ、および１６０ｃのそれぞれは、特定のセル（図示せず
）に関連付けられてもよく、無線リソース管理決定、ハンドオーバー決定、アップリンク
またはダウンリンクにおけるユーザのスケジューリングなどを処理するように構成されて
もよい。図１２Ｃに示すように、ｅノードＢ１６０ａ、１６０ｂ、および１６０ｃは、Ｘ
２インタフェースを介して互いに通信してもよい。

【0260】

図１２Ｃに示すコアネットワーク１０７は、モビリティ管理ゲートウェイ（Mobility
Management Gateway：ＭＭＥ）１６２、サービングゲートウェイ１６４、およびパケッ
トデータネットワーク（Packet Data Network：ＰＤＮ）ゲートウェイ１６６を含んで
もよい。前述の各要素は、コアネットワーク１０７の一部として図示されているが、これ
らの要素のいずれか１つは、コアネットワークオペレータ以外のエンティティによって所
有または運営されてもよいことが理解されるであろう。

【0261】

ＭＭＥ１６２は、Ｓ１インタフェースを介して、ＲＡＮ１０４内のｅノードＢ１６０ａ
、１６０ｂ、および１６０ｃのそれぞれに接続されてもよく、制御ノードとして機能して
もよい。例えば、ＭＭＥ１６２は、ＷＴＲＵ１０２ａ、１０２ｂ、および１０２ｃのユー
ザの認証、ベアラのアクティブ化／非アクティブ化、ＷＴＲＵ１０２ａ、１０２ｂ、およ
び１０２ｃの初期接続中の特定のサービングゲートウェイの選択などの役割を担ってもよ
い。ＭＭＥ１６２はまた、ＲＡＮ１０４と、ＧＳＭまたはＷＣＤＭＡなどの他の無線技術
を採用した他のＲＡＮ（図示せず）とを切り替えるための、制御プレーン機能を提供して
もよい。

【0262】

サービングゲートウェイ１６４は、Ｓ１インタフェースを介して、ＲＡＮ１０４内のｅ
ノードＢ１６０ａ、１６０ｂ、および１６０ｃのそれぞれに接続されてもよい。サービン
グゲートウェイ１６４は、一般に、ＷＴＲＵ１０２ａ、１０２ｂ、および１０２ｃとの間
でユーザデータパケットをルーティングおよび転送してもよい。サービングゲートウェイ
１６４はまた、ｅノードＢハンドオーバー中にユーザプレーンをアンカリングすること、
ＷＴＲＵ１０２ａ、１０２ｂ、および１０２ｃでダウンリンクデータが利用可能な場合に
ページングをトリガすること、ＷＴＲＵ１０２ａ、１０２ｂ、および１０２ｃのコンテキ
ストを管理ならびに保存することなど、他の機能を実行してもよい。

【0263】

サービングゲートウェイ１６４はまた、ＰＤＮゲートウェイ１６６に接続されてもよく
、これは、ＷＴＲＵ１０２ａ、１０２ｂ、および１０２ｃに、インターネット１１０など
のパケット交換ネットワークへのアクセスを提供して、ＷＴＲＵ１０２ａ、１０２ｂ、１
０２ｃとＩＰ対応デバイスとの間の通信を容易にしてもよい。

【0264】

コアネットワーク１０７は、他のネットワークとの通信を容易にしてもよい。例えば、
コアネットワーク１０７は、ＷＴＲＵ１０２ａ、１０２ｂ、および１０２ｃに、ＰＳＴＮ
１０８などの回線交換ネットワークへのアクセスを提供して、ＷＴＲＵ１０２ａ、１０２
ｂ、および１０２ｃと、従来の陸上線通信デバイスとの間の通信を容易にしてもよい。例
えば、コアネットワーク１０７は、コアネットワーク１０７とＰＳＴＮ１０８との間のイ
ンタフェースとして機能するＩＰゲートウェイ（例えば、ＩＰマルチメディアサブシステ
ム（IP Multimedia Subsystem：ＩＭＳ）サーバ）を含んでいてもよく、またはそれと
通信してもよい。さらに、コアネットワーク１０７は、ＷＴＲＵ１０２ａ、１０２ｂ、お
よび１０２ｃに、他のサービスプロバイダによって所有または運営される他の有線または
無線ネットワークを含み得るネットワーク１１２へのアクセスを提供してもよい。

【0265】

図１２Ｄは、本明細書に開示されているように、ＮＲ－Ｕ ＬＢＴ ＭＡＣ手順の方法
、システム、およびデバイスを実装し得る例示的なＲＡＮ１０５およびコアネットワーク
１０９のシステム図である。ＲＡＮ１０５は、エアインタフェース１１７を介してＷＴＲ
Ｕ１０２ａおよび１０２ｂと通信するために、ＮＲ無線技術を採用してもよい。ＲＡＮ１
０５はまた、コアネットワーク１０９と通信してもよい。非３ＧＰＰインターワーキング
機能（Non-3GPP Interworking Function：Ｎ３ＩＷＦ）１９９は、エアインタフェース
１９８を介してＷＴＲＵ１０２ｃと通信するために、非３ＧＰＰ無線技術を採用してもよ
い。Ｎ３ＩＷＦ１９９はまた、コアネットワーク１０９と通信してもよい。

【0266】

ＲＡＮ１０５は、ｇノードＢ１８０ａおよび１８０ｂを含んでもよい。ＲＡＮ１０５は
、任意の数のｇノードＢを含んでもよいことが理解されるであろう。ｇノードＢ１８０ａ
および１８０ｂはそれぞれ、エアインタフェース１１７を介してＷＴＲＵ１０２ａ、およ
び１０２ｂと通信するための１つ以上のトランシーバを含んでもよい。統合されたアクセ
スおよびバックホール接続が使用される場合、ＷＴＲＵとｇノードＢとの間で同じエアイ
ンタフェースが使用されてもよく、これは、１つまたは複数のｇＮＢを介したコアネット
ワーク１０９であってもよい。ｇノードＢ１８０ａおよび１８０ｂは、ＭＩＭＯ、ＭＵ－
ＭＩＭＯ、またはデジタルビームフォーミング技術を実装してもよい。したがって、ｇノ
ードＢ１８０ａは、例えば、複数のアンテナを使用して、ＷＴＲＵ１０２ａに無線信号を
送信し、かつＷＴＲＵ１０２ａから無線信号を受信してもよい。ＲＡＮ１０５は、ｅノー
ドＢなどの他のタイプの基地局を採用してもよいことが理解されるべきである。また、Ｒ
ＡＮ１０５は、１つ以上のタイプの基地局を採用してもよいことが理解されるであろう。
例えば、ＲＡＮは、ｅノードＢおよびｇノードＢを採用してもよい。

【0267】

Ｎ３ＩＷＦ１９９は、非３ＧＰＰアクセスポイント１８０ｃを含んでもよい。Ｎ３ＩＷ
Ｆ１９９は、任意の数の非３ＧＰＰアクセスポイントを含んでもよいことが理解されるで
あろう。非３ＧＰＰアクセスポイント１８０ｃは、エアインタフェース１９８を介してＷ
ＴＲＵ１０２ｃと通信するための１つ以上のトランシーバを含んでもよい。非３ＧＰＰア
クセスポイント１８０ｃは、８０２．１１を使用して、エアインタフェース１９８を介し
てＷＴＲＵ１０２ｃと通信してもよい。

【0268】

ｇノードＢ１８０ａおよび１８０ｂのそれぞれは、特定のセル（図示せず）に関連付け
られてもよく、無線リソース管理決定、ハンドオーバー決定、アップリンクまたはダウン
リンクにおけるユーザのスケジューリングなどを処理するように構成されてもよい。図１
２Ｄに示すように、ｇノードＢ１８０ａ、および１８０ｂは、例えば、Ｘｎインタフェー
スを介して互いに通信してもよい。

【0269】

図１２Ｄに示すコアネットワーク１０９は、５Ｇコアネットワーク（5G Core Networ
k：５ＧＣ）であってもよい。コアネットワーク１０９は、無線アクセスネットワークに
よって相互に接続されている顧客に、多数の通信サービスを提供してもよい。コアネット
ワーク１０９は、コアネットワークの機能性を実行する多数のエンティティで構成される
。本明細書で使用する場合、「コアネットワークエンティティ」または「ネットワーク機
能」という用語は、コアネットワークの１つ以上の機能性を実行する任意のエンティティ
を意味する。そのようなコアネットワークエンティティは、図１２Ｇに例示されたシステ
ム９０のなどの、無線もしくはネットワーク通信用に構成された装置またはコンピュータ
システムのメモリに保存され、そのプロセッサ上で実行されるコンピュータ実行可能命令
（ソフトウェア）の形態で実装される論理エンティティであってもよいことが理解される
。

【0270】

図１２Ｄの例では、５Ｇコアネットワーク１０９は、アクセスおよびモビリティ管理機
能（Access and Mobility Management Function：ＡＭＦ）１７２、セッション管理
機能（Session Management Function：ＳＭＦ）１７４、ユーザプレーン機能（User P
lane Function：ＵＰＦ）１７６ａおよび１７６ｂ、ユーザデータ管理機能（User Data
Management Function：ＵＤＭ）１９７、認証サーバ機能（Authentication Server
Function：ＡＵＳＦ）１９０、ネットワーク露出機能（Network Exposure Function：
ＮＥＦ）１９６、ポリシー制御機能（Policy Control Function：ＰＣＦ）１８４、非
３ＧＰＰインターワーキング機能（Ｎ３ＩＷＦ）１９９、ユーザデータリポジトリ（User
Data Repository：ＵＤＲ）１７８を含んでもよい。前述の各要素は、５Ｇコアネット
ワーク１０９の一部として図示されているが、これらの要素のいずれか１つは、コアネッ
トワークオペレータ以外のエンティティによって所有または運営されてもよいことが理解
されるであろう。また、５Ｇコアネットワークは、これらの要素の全てで構成されていな
くてもよく、追加の要素で構成されていてもよく、これらの各要素の複数のインスタンス
で構成されていてもよいことも理解されるであろう。図１２Ｄは、ネットワーク機能が互
いに直接接続していることを示しているが、直径ルーティングエージェントまたはメッセ
ージバスなどのルーティングエージェントを介して通信してもよいことが理解されるべき
である。

【0271】

図１２Ｄの例では、ネットワーク機能間の接続性は、一連のインタフェースまたは基準
点を介して達成されている。ネットワーク機能は、他のネットワーク機能またはサービス
によって呼び出される（ｉｎｖｏｋｅｄ）または呼び出される（ｃａｌｌｅｄ）サービス
のセットとしてモデル化、記述、または実装され得ることが理解されるであろう。ネット
ワーク機能サービスの呼び出しは、ネットワーク機能間の直接接続、メッセージバスでの
メッセージ交換、ソフトウェア機能の呼び出しなどを介して実現されてもよい。

【0272】

ＡＭＦ１７２は、Ｎ２インタフェースを介してＲＡＮ１０５に接続されてもよく、制御
ノードとして機能してもよい。例えば、ＡＭＦ１７２は、登録管理、接続管理、到達可能
性管理、アクセス認証、アクセス承認の役割を担ってもよい。ＡＭＦは、ユーザプレーン
のトンネル構成情報を、Ｎ２インタフェースを介してＲＡＮ１０５に転送する役割を担っ
てもよい。ＡＭＦ１７２は、Ｎ１１インタフェースを介して、ＳＭＦからユーザプレーン
のトンネル構成情報を受信してもよい。ＡＭＦ１７２は、一般的に、Ｎ１インタフェース
を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとの間でＮＡＳパケットをルーティング
して転送してもよい。Ｎ１インタフェースは、図１２Ｄには示されていない。

【0273】

ＳＭＦ１７４は、Ｎ１１インタフェースを介して、ＡＭＦ１７２に接続されてもよい。
同様に、ＳＭＦは、Ｎ７インタフェースを介してＰＣＦ１８４に、ならびにＮ４インタフ
ェースを介してＵＰＦ１７６ａおよび１７６ｂに接続されてもよい。ＳＭＦ１７４は、制
御ノードとして機能してもよい。例えば、ＳＭＦ１７４は、セッション管理、ＷＴＲＵ１
０２ａ、１０２ｂ、および１０２ｃに対するＩＰアドレスの割り当て、ＵＰＦ１７６ａお
よびＵＰＦ１７６ｂにおけるトラフィックステアリングルールの管理および設定、ならび
に、ＡＭＦ１７２に対するダウンリンクデータ通知の生成の役割を担ってもよい。

【0274】

ＵＰＦ１７６ａおよびＵＰＦ１７６ｂは、ＷＴＲＵ１０２ａ、１０２ｂ、および１０２
ｃに、インターネット１１０などのパケットデータネットワーク（ＰＤＮ）へのアクセス
を提供して、ＷＴＲＵ１０２ａ、１０２ｂ、および１０２ｃと他のデバイスとの間の通信
を容易にしてもよい。ＵＰＦ１７６ａおよびＵＰＦ１７６ｂはまた、ＷＴＲＵ１０２ａ、
１０２ｂ、および１０２ｃに、他のタイプのパケットデータネットワークへのアクセスを
提供してもよい。例えば、他のネットワーク１１２は、イーサネットネットワークまたは
データのパケットを交換する任意のタイプのネットワークであってもよい。ＵＰＦ１７６
ａおよびＵＰＦ１７６ｂは、Ｎ４インタフェースを介してＳＭＦ１７４からトラフィック
ステアリングルールを受信してもよい。ＵＰＦ１７６ａおよびＵＰＦ１７６ｂは、Ｎ６イ
ンタフェースでパケットデータネットワークを接続することによって、またはＮ９インタ
フェースで相互におよび他のＵＰＦと接続することによって、パケットデータネットワー
クへのアクセスを提供してもよい。パケットデータネットワークへのアクセスを提供する
ことに加えて、ＵＰＦ１７６は、パケットのルーティングおよび転送、ポリシールールの
施行、ユーザプレーンのトラフィックに対するサービス品質の処理、ダウンリンクパケッ
トのバッファリングなどの役割を担ってもよい。

【0275】

ＡＭＦ１７２はまた、例えば、Ｎ２インタフェースを介してＮ３ＩＷＦ１９９に接続さ
れていてもよい。Ｎ３ＩＷＦは、例えば、３ＧＰＰで定義されていない無線インタフェー
ス技術を介して、ＷＴＲＵ１０２ｃと５Ｇコアネットワーク１７０との間の接続を容易に
する。ＡＭＦは、ＲＡＮ１０５と相互作用するのと同じか、または類似の方法で、Ｎ３Ｉ
ＷＦ１９９と相互作用してもよい。

【0276】

ＰＣＦ１８４は、Ｎ７インタフェースを介してＳＭＦ１７４に接続され、Ｎ１５インタ
フェースを介してＡＭＦ１７２に接続され、Ｎ５インタフェースを介してアプリケーショ
ン機能（Application Function：ＡＦ）１８８に接続されてもよい。Ｎ１５およびＮ５
インタフェースは、図１２Ｄには示されていない。ＰＣＦ１８４は、ＡＭＦ１７２および
ＳＭＦ１７４などの制御プレーンノードにポリシールールを提供して、制御プレーンノー
ドがこれらのルールを施行できるようにしてもよい。ＰＣＦ１８４は、ＡＭＦがＮ１イン
タフェースを介してＷＴＲＵ１０２ａ、１０２ｂ、および１０２ｃにポリシーを配信でき
るように、ＷＴＲＵ１０２ａ、１０２ｂ、および１０２ｃに対してＡＭＦ１７２にポリシ
ーを送信してもよい。その後、ポリシーは、ＷＴＲＵ１０２ａ、１０２ｂ、および１０２
ｃで施行されるか、または適用されてもよい。

【0277】

ＵＤＲ１７８は、認証のクレデンシャルおよび加入情報のリポジトリとして機能しても
よい。ＵＤＲは、ネットワーク機能がリポジトリ内のデータに追加し、そこから読み取り
、修正することができるように、ネットワーク機能に接続してもよい。例えば、ＵＤＲ１
７８は、Ｎ３６インタフェースを介してＰＣＦ１８４に接続してもよい。同様に、ＵＤＲ
１７８は、Ｎ３７インタフェースを介してＮＥＦ１９６に接続してもよく、ＵＤＲ１７８
は、Ｎ３５インタフェースを介してＵＤＭ１９７に接続してもよい。

【0278】

ＵＤＭ１９７は、ＵＤＲ１７８と他のネットワーク機能との間のインタフェースとして
機能してもよい。ＵＤＭ１９７は、ネットワーク機能にＵＤＲ１７８へのアクセスを許可
してもよい。例えば、ＵＤＭ１９７は、Ｎ８インタフェースを介してＡＭＦ１７２に接続
してもよく、ＵＤＭ１９７は、Ｎ１０インタフェースを介してＳＭＦ１７４に接続しても
よい。同様に、ＵＤＭ１９７は、Ｎ１３インタフェースを介してＡＵＳＦ１９０に接続し
てもよい。ＵＤＲ１７８とＵＤＭ１９７は、緊密に統合されていてもよい。

【0279】

ＡＵＳＦ１９０は、認証関連の動作を実行し、Ｎ１３インタフェースを介してＵＤＭ１
７８に接続し、Ｎ１２インタフェースを介してＡＭＦ１７２に接続する。

【0280】

ＮＥＦ１９６は、５Ｇコアネットワーク１０９内における能力およびサービスを、アプ
リケーション機能（ＡＦ）１８８に公開する。公開は、Ｎ３３ ＡＰＩインタフェース上
で行われてもよい。ＮＥＦは、Ｎ３３インタフェースを介してＡＦ１８８に接続してもよ
く、５Ｇコアネットワーク１０９の能力およびサービスを公開するために、他のネットワ
ーク機能に接続してもよい。

【0281】

アプリケーション機能１８８は、５Ｇコアネットワーク１０９のネットワーク機能と相
互作用してもよい。アプリケーション機能１８８とネットワーク機能との間の相互作用は
、直接的なインタフェースを介していてもよく、またはＮＥＦ１９６を介して生じてもよ
い。アプリケーション機能１８８は、５Ｇコアネットワーク１０９の一部と見なされても
よく、または５Ｇコアネットワーク１０９の外部にあって、モバイルネットワーク事業者
とビジネス関係を有する企業によって展開されてもよい。

【0282】

ネットワークスライシングは、モバイルネットワーク事業者が、事業者のエアインタフ
ェースの背後にある１つ以上の「仮想」コアネットワークをサポートするために使用でき
るメカニズムである。これは、コアネットワークを１つ以上の仮想ネットワークに「スラ
イスシング」して、異なるＲＡＮまたは単一のＲＡＮにわたって実行される異なるサービ
スタイプをサポートすることと関連する。ネットワークスライシングにより、事業者は、
機能性、性能、およびアイソレーションなどの多様な要件が求められる様々な市場のシナ
リオに最適なソリューションを提供するようにカスタマイズされたネットワークを作成す
ることができる。

【0283】

３ＧＰＰは、ネットワークスライシングをサポートするように５Ｇコアネットワークを
設計している。ネットワークスライシングは、ネットワーク事業者が、非常に多様でとき
には極端な要件が求められる５Ｇの多様な一連のユースケース（例えば、マッシブＩｏＴ
、クリティカルコミュニケーション、Ｖ２Ｘ、および拡張モバイルブロードバンド）をサ
ポートするために使用できる優れたツールである。ネットワークスライシング技術を使用
しないと、各ユースケースに固有の一連の性能、スケーラビリティ、および可用性の要件
がある場合、ネットワークアーキテクチャは、より広い範囲のユースケースを効率的にサ
ポートするのに十分に柔軟かつスケーラブルではない可能性がある。さらに、新しいネッ
トワークサービスの導入がより効率的に行われるべきである。

【0284】

再び図１２Ｄを参照すると、ネットワークスライシングシナリオでは、ＷＴＲＵ１０２
ａ、１０２ｂ、または１０２ｃは、Ｎ１インタフェースを介して、ＡＭＦ１７２に接続し
てもよい。ＡＭＦは、論理的に１つ以上のスライスの一部であってもよい。ＡＭＦは、Ｗ
ＴＲＵ１０２ａ、１０２ｂ、もしくは１０２ｃの接続または通信を、１つ以上のＵＰＦ１
７６ａおよび１７６ｂ、ＳＭＦ１７４、ならびに他のネットワーク機能と調和してもよい
。ＵＰＦ１７６ａおよび１７６ｂ、ＳＭＦ１７４、ならびに他のネットワーク機能のそれ
ぞれは、同じスライス、または異なるスライスの一部であってもよい。それらが異なるス
ライスの一部であるとき、それらは、異なるコンピューティングリソース、セキュリティ
クレデンシャルなどを利用することができるという意味で、互いに分離されていてもよい
。

【0285】

コアネットワーク１０９は、他のネットワークとの通信を容易にしてもよい。例えば、
コアネットワーク１０９は、５Ｇコアネットワーク１０９とＰＳＴＮ１０８との間のイン
タフェースとして機能するＩＰマルチメディアサブシステム（ＩＭＳ）サーバなどのＩＰ
ゲートウェイを含んでいてもよく、またはそれと通信してもよい。例えば、コアネットワ
ーク１０９は、ショートメッセージサービスを介して通信を機能させるショートメッセー
ジサービス（Short Message Service：ＳＭＳ）サービスセンターを含んでもよく、ま
たはそれと通信してもよい。例えば、５Ｇコアネットワーク１０９は、ＷＴＲＵ１０２ａ
、１０２ｂ、および１０２ｃと、サーバまたはアプリケーション機能１８８との間の非Ｉ
Ｐデータパケットの交換を容易にしてもよい。さらに、コアネットワーク１７０は、ＷＴ
ＲＵ１０２ａ、１０２ｂ、および１０２ｃに、他のサービスプロバイダによって所有また
は運営される他の有線または無線ネットワークを含み得るネットワーク１１２へのアクセ
スを提供してもよい。

【0286】

本明細書に記載され、図１２Ａ、図１２Ｃ、図１２Ｄ、または図１２Ｅに示されている
コアネットワークエンティティは、特定の既存の３ＧＰＰ仕様でそれらのエンティティに
与えられた名前によって識別されているが、将来、それらのエンティティおよび機能性が
他の名前で識別される可能性があり、特定のエンティティまたは機能が、将来の３ＧＰＰ
ＮＲ仕様を含む、３ＧＰＰによって発行される将来の仕様と組み合わされ得ることが理
解される。したがって、図１２Ａ、図１２Ｂ、図１２Ｃ、図１２Ｄ、または図１２Ｅで説
明および示されている特定のネットワークエンティティおよび機能性は、例示としてのみ
提供されており、本明細書で開示および請求されている主題は、現在定義されているかま
たは将来定義されるかに関わらず、任意の類似の通信システムで具体化または実装され得
ることが理解される。

【0287】

図１２Ｅは、本明細書に記載されているように、ＮＲ－Ｕ ＬＢＴ ＭＡＣ手順を実装
するシステム、方法、装置が使用され得る例示的な通信システム１１１を示す。通信シス
テム１１１は、無線送受信ユニット（ＷＴＲＵ）Ａ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆ、基地局ｇＮＢ
１２１、Ｖ２Ｘサーバ１２４、ならびに路側機（Road Side Unit：ＲＳＵ）１２３ａ、
および１２３ｂを含んでもよい。実際には、本明細書に提示される概念は、任意の数のＷ
ＴＲＵ、基地局ｇＮＢ、Ｖ２Ｘネットワーク、または他のネットワーク要素に適用し得る
。１つまたはいくつかまたは全てのＷＴＲＵ Ａ、Ｂ、Ｃ、Ｄ、Ｅ、およびＦは、アクセ
スネットワークカバレッジ１３１の範囲外であってもよい。ＷＴＲＵ Ａ、Ｂ、およびＣ
は、Ｖ２Ｘグループを形成しており、そのうちＷＴＲＵ Ａはグループリードであり、Ｗ
ＴＲＵ ＢおよびＣはグループメンバである。

【0288】

ＷＴＲＵ Ａ、Ｂ、Ｃ、Ｄ、Ｅ、およびＦは、それらがアクセスネットワークカバレッ
ジ１３１内にある場合、ｇＮＢ１２１を介してＵｕインタフェース１２９で相互に通信し
てもよい。図１２Ｅの例では、ＷＴＲＵ ＢおよびＦがアクセスネットワークカバレッジ
１３１内に示されている。ＷＴＲＵ Ａ、Ｂ、Ｃ、Ｄ、Ｅ、およびＦは、それらがアクセ
スネットワークカバレッジ１３１のもとにあるか、またはアクセスネットワークカバレッ
ジ１３１の外にあるかに関わらず、インタフェース１２５ａ、１２５ｂ、または１２８な
どのスライドリンクインタフェース（例えば、ＰＣ５またはＮＲ ＰＣ５）を介して、互
いに直接通信してもよい。例えば、図１２Ｅの例では、アクセスネットワークカバレッジ
１３１の外にあるＷＲＴＵ Ｄは、カバレッジ１３１の中にあるＷＴＲＵ Ｆと通信する
。

【0289】

ＷＴＲＵ Ａ、Ｂ、Ｃ、Ｄ、Ｅ、およびＦは、車両対ネットワーク通信（Ｖ２Ｎ）１３
３またはサイドリンククインタフェース１２５ｂを介して、ＲＳＵ１２３ａまたは１２３
ｂと通信してもよい。ＷＴＲＵ Ａ、Ｂ、Ｃ、Ｄ、Ｅ、およびＦは、車両対インフラスト
ラクチャ通信（Ｖ２Ｉ）インタフェース１２７を介してＶ２Ｘサーバ１２４と通信しても
よい。ＷＴＲＵ Ａ、Ｂ、Ｃ、Ｄ、Ｅ、およびＦは、車両対歩行者通信（Ｖ２Ｐ）インタ
フェース１２８を介して、別のＵＥに通信してもよい。

【0290】

図１２Ｆは、図１２Ａ、図１２Ｂ、図１２Ｃ、図１２Ｄ、もしくは図１２ＥのＷＴＲＵ
１０２、または図１（例えば、ＵＥ１０１）など、本明細書に記載されているように、Ｎ
Ｒ－Ｕ ＬＢＴ ＭＡＣ手順を実装するシステム、方法、および装置に従って、無線通信
および動作のために構成され得る、例示的な装置またはデバイスＷＴＲＵ１０２のブロッ
ク図である。図１２Ｆに示すように、例示的なＷＴＲＵ１０２は、プロセッサ１１８、ト
ランシーバ１２０、送受信素子１２２、スピーカ／マイクロフォン１２４、キーパッド１
２６、ディスプレイ／タッチパッド／インジケータ１２８、非リムーバブルメモリ１３０
、リムーバブルメモリ１３２、電源１３４、全地球測位システム（Global Positioning
System：ＧＰＳ）チップセット１３６、および他の周辺機器１３８を含んでもよい。Ｗ
ＴＲＵ１０２は、前述の要素の任意のサブコンビネーションを含み得ることが理解される
であろう。また、基地局１１４ａおよび１１４ｂ、または基地局１１４ａおよび１１４ｂ
が表し得るノード、例えば、しかしこれらに限定されない、基地局装置（ＢＴＳ）、ノー
ドＢ、サイトコントローラ、アクセスポイント（ＡＰ）、ホームノードＢ、発展型ノード
Ｂ（ｅノードＢ）、ホーム発展型ノードＢ（ＨｅＮＢ）、ホーム発展型ノードＢゲートウ
ェイ、次世代ノードＢ（ｇノードＢ）、ならびにプロキシノードなどは、特に、図１２Ｆ
に図示された要素の一部または全てを含んでもよく、本明細書に記載されているＮＲ－Ｕ
ＬＢＴ ＭＡＣ手順の開示されたシステムおよび方法を実行する例示的な実装であって
もよい。

【0291】

プロセッサ１１８は、汎用プロセッサ、専用プロセッサ、従来のプロセッサ、デジタル
信号プロセッサ（Digital Signal Processor：ＤＳＰ）、複数のマイクロプロセッサ、
ＤＳＰコアに関連した１つ以上のマイクロプロセッサ、コントローラ、マイクロコントロ
ーラ、特定用途向け集積回路（Application Specific Integrated Circuit：ＡＳＩＣ
）、フィールドプログラマブルゲートアレイ（Field Programmable Gate Array：ＦＰ
ＧＡ）回路、その他のタイプの集積回路（Integrated Circuit：ＩＣ）、ステートマシ
ンなどであってもよい。プロセッサ１１８は、信号符号化、データ処理、電力制御、入出
力処理、または、ＷＴＲＵ１０２が無線環境で動作することを可能にする任意の他の機能
性を実行してもよい。プロセッサ１１８は、トランシーバ１２０に結合されてもよく、ト
ランシーバは、送受信素子１２２に結合されてもよい。図１２Ｆは、プロセッサ１１８お
よびトランシーバ１２０を別個のコンポーネントとして図示しているが、プロセッサ１１
８およびトランシーバ１２０は、電子パッケージまたはチップ内に共に統合されてもよい
ことが理解されるであろう。

【0292】

ＵＥの送受信素子１２２は、エアインタフェース１１５／１１６／１１７を介して基地
局（例えば、図１２Ａの基地局１１４ａ）との間で、またはエアインタフェース１１５ｄ
／１１６ｄ／１１７ｄを介して別のＵＥとの間で、信号を送信もしくは受信するように構
成されてもよい。例えば、送受信素子１２２は、ＲＦ信号を送信または受信するように構
成されたアンテナであってもよい。送受信素子１２２は、例えば、ＩＲ、ＵＶ、もしくは
可視光信号を送信または受信するように構成されたエミッタ／検出器であってもよい。送
受信素子１２２は、ＲＦ信号および光信号の両方を送受信するように構成されてもよい。
送受信素子１２２は、無線もしくは有線信号の任意の組み合わせを送信または受信するよ
うに構成されていてもよいことが理解されよう。

【0293】

さらに、図１２Ｆでは送受信素子１２２が単一の素子として図示さているが、ＷＴＲＵ
１０２は、任意の数の送受信素子１２２を含んでもよい。より具体的には、ＷＴＲＵ１０
２は、ＭＩＭＯ技術を採用してもよい。したがって、ＷＴＲＵ１０２は、エアインタフェ
ース１１５／１１６／１１７を介して無線信号を送受信するための２つ以上の送受信素子
１２２（例えば、複数のアンテナ）を含んでもよい。

【0294】

トランシーバ１２０は、送受信素子１２２によって送信されるべき信号を変調し、送受
信素子１２２によって受信される信号を復調するように構成されてもよい。上記のとおり
、ＷＴＲＵ１０２は、マルチモード能力を有していてもよい。したがって、トランシーバ
１２０は、ＷＴＲＵ１０２が複数のＲＡＴ、例えば、ＮＲとＩＥＥＥ８０２．１１もしく
はＮＲとＥ－ＵＴＲＡを介して通信する、または、異なるＲＲＨ、ＴＲＰ、ＲＳＵ、もし
くはノードに複数のビームを介して同じＲＡＴで通信することを可能にするための、複数
のトランシーバを含んでもよい。

【0295】

ＷＴＲＵ１０２のプロセッサ１１８は、スピーカ／マイクロフォン１２４、キーパッド
１２６、またはディスプレイ／タッチパッド／インジケータ１２８（例えば、液晶ディス
プレイ（Liquid Crystal Display：ＬＣＤ）ディスプレイユニット、または有機発光ダ
イオード（Organic Light-Emitting Diode：ＯＬＥＤ）ディスプレイユニットに結合さ
れていてもよく、これらからユーザ入力データを受信してもよい。プロセッサ１１８はま
た、スピーカ／マイクロフォン１２４、キーパッド１２６、または、ディスプレイ／タッ
チパッド／インジケータ１２８にユーザデータを出力してもよい。さらに、プロセッサ１
１８は、非リムーバブルメモリ１３０またはリムーバブルメモリ１３２など、任意のタイ
プの適切なメモリから情報にアクセスし、メモリにデータを保存してもよい。非リムーバ
ブルメモリ１３０は、ランダムアクセスメモリ（Random-Access Memory：ＲＡＭ）、リ
ードオンリーメモリ（Read-Only MemoryＲＯＭ）、ハードディスク、または任意の他の
タイプのメモリストレージデバイスを含んでもよい。リムーバブルメモリ１３２は、加入
者識別モジュール（Subscriber Identity Module:ＳＩＭ）カード、メモリスティック
、セキュアデジタル（Secure Digital：ＳＤ）メモリカードなどを含んでいてもよい。
プロセッサ１１８は、クラウドもしくはエッジコンピューティングプラットフォームでホ
ストされているサーバまたはホームコンピュータ（図示せず）上などで、ＷＴＲＵ１０２
に物理的に配置されていないメモリから情報にアクセスし、データを保存してもよい。プ
ロセッサ１１８は、本明細書に記載されているいくつかの実施例におけるＬＢＴ ＦＣの
セットアップが成功したかまたは不成功なのかに応じて、ディスプレイもしくはインジケ
ータ１２８上の照明パターン、画像、または色を制御するように構成されてもよく、また
は別の方法でＮＲ－Ｕ ＬＢＴ ＭＡＣ手順および関連するコンポーネントの状態を示す
ように構成されてもよい。ディスプレイもしくはインジケータ１２８上の制御照明パター
ン、画像、または色は、本明細書で示されている、もしくは記載されている図（例えば、
図１～図１０など）における方法フローまたはコンポーネントのいずれかの状態を反映し
ていてもよい。本明細書には、ＮＲ－Ｕ ＬＢＴ ＭＡＣ手順のメッセージおよび手順が
開示されている。メッセージおよび手順は、ユーザが、入力ソース（例えば、スピーカ／
マイクロフォン１２４、キーパッド１２６、またはディスプレイ／タッチパッド／インジ
ケータ１２８）を介してリソースを要求し、ディスプレイ１２８に表示され得る他のもの
のうち、ＮＲ－Ｕ ＬＢＴ ＭＡＣ手順関連情報を要求、設定、または照会するためのイ
ンタフェース／ＡＰＩを提供するように拡張されてもよい。

【0296】

プロセッサ１１８は、電源１３４から電力を受け取り、ＷＴＲＵ１０２内の他のコンポ
ーネントに電力を分配または制御するように構成されてもよい。電源１３４は、ＷＴＲＵ
１０２に電力を供給するための任意の適切なデバイスであってもよい。例えば、電源１３
４は、１つ以上の乾電池、太陽電池、燃料電池などを含んでもよい。

【0297】

また、プロセッサ１１８は、ＧＰＳチップセット１３６に結合されてもよく、ＧＰＳチ
ップセット１３６は、ＷＴＲＵ１０２の現在位置に関する位置情報（例えば、経度および
緯度）を提供するように構成されてもよい。ＧＰＳチップセット１３６からの情報に加え
て、またはそれの代わりに、ＷＴＲＵ１０２は、基地局（例えば、基地局１１４ａ、１１
４ｂ）からエアインタフェース１１５／１１６／１１７を介して位置情報を受信してもよ
く、または２つ以上の近くの基地局から受信されている信号のタイミングに基づいてその
位置を判定してもよい。ＷＴＲＵ１０２は、任意の適切な位置判定方法によって、位置情
報を取得してもよいことが理解されるであろう。

【0298】

プロセッサ１１８は、さらに、他の周辺機器１３８に結合されてもよく、これらの周辺
機器１３８は、追加の特徴、機能性、または有線もしくは無線の接続性を提供する１つ以
上のソフトウェアまたはハードウェアモジュールを含んでもよい。例えば、周辺機器１３
８は、加速度計などの様々なセンサ、バイオメトリクス（例えば、指紋）センサ、電子コ
ンパス、衛星トランシーバ、デジタルカメラ（写真またはビデオ用）、ユニバーサルシリ
アルバス（Universal Serial Bus：ＵＳＢ）ポートまたは他の相互接続インタフェース
、振動デバイス、テレビトランシーバ、ハンズフリーヘッドセット、Ｂｌｕｅｔｏｏｔｈ
（登録商標）モジュール、周波数変調（Frequency Modulated：ＦＭ）無線ユニット、デ
ジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネ
ットブラウザなどを含んでもよい。

【0299】

ＷＴＲＵ１０２は、センサ、家電製品、スマートウォッチまたはスマートウェアなどの
ウェアラブルデバイス、医療または電子ヘルスデバイス、ロボット、産業機器、ドローン
、自動車、トラック、電車、または飛行機などの車両など、他の装置またはデバイス内に
含まれていてもよい。ＷＴＲＵ１０２は、周辺機器１３８の１つを構成し得る相互接続イ
ンタフェースなど、１つ以上の相互接続インタフェースを介して、そのような装置もしく
はデバイスの他のコンポーネント、モジュール、またはシステムに接続してもよい。

【0300】

図１２Ｇは、例示的なコンピューティングシステム９０のブロック図であり、これは、
図１２Ａ、図１２Ｃ、図１２Ｄ、および図１２Ｅに示される通信ネットワークの１つ以上
の装置、ならびに、図１から図１０に示され、本明細書において説明および請求されるシ
ステムおよび方法などのＮＲ－Ｕ ＬＢＴ ＭＡＣ手順が、ＲＡＮ１０３／１０４／１０
５、コアネットワーク１０６／１０７／１０９、ＰＳＴＮ１０８、インターネット１１０
、その他のネットワーク１１２、もしくはネットワークサービス１１３における特定のノ
ードまたは機能エンティティなどで具現化され得る。コンピューティングシステム９０は
、コンピュータまたはサーバで構成され、主にコンピュータ可読命令によって制御されて
もよく、コンピュータ可読命令は、ソフトウェアの形態であってもよく、またはそのよう
なソフトウェアがどこに保存されていても、もしくはどのような手段でアクセスされても
よい。このようなコンピュータ可読命令は、プロセッサ９１内で実行されて、コンピュー
ティングシステム９０に動作をさせてもよい。プロセッサ９１は、汎用プロセッサ、専用
プロセッサ、従来のプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、複数のマイクロプ
ロセッサ、ＤＳＰコアに関連した１つ以上のマイクロプロセッサ、コントローラ、マイク
ロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲート
アレイ（ＦＰＧＡ）回路、その他のタイプの集積回路（ＩＣ）、ステートマシンなどであ
ってもよい。プロセッサ９１は、信号符号化、データ処理、電力制御、入出力処理、また
は、ＷＴＲＵ９０が電気通信ネットワークで動作することを可能にする任意の他の機能性
を実行してもよい。コプロセッサ８１は、メインプロセッサ９１とは異なるオプションの
プロセッサであり、追加の機能を実行、またはプロセッサ９１を支援し得る。プロセッサ
９１またはコプロセッサ８１は、ＬＢＴ失敗の受信または反応など、ＮＲ－Ｕ ＬＢＴ
ＭＡＣ手順のために本明細書に開示された方法および装置に関連するデータを受信、生成
、ならびに処理してもよい。

【0301】

動作時、プロセッサ９１は、命令をフェッチ、復号、および実行し、コンピューティン
グシステムの主なデータ転送パスであるシステムバス８０を介して、他のリソースとの間
で情報を転送する。このようなシステムバスは、コンピューティングシステム９０内のコ
ンポーネントを接続し、データ交換のための媒体を定義する。システムバス８０は、典型
的には、データを送るためのデータライン、アドレスを送るためのアドレスライン、なら
びに、割り込みを送るため、およびシステムバスを動作するための制御ラインを含む。こ
のようなシステムバス８０の一例は、ペリフェラルコンポーネントインターコネクト（Pe
ripheral Component Interconnect：ＰＣＩ）バスである。

【0302】

システムバス８０に結合されたメモリは、ランダムアクセスメモリ（Random Access
Memory：ＲＡＭ）８２および読み出し専用メモリ（Read Only Memory：ＲＯＭ）９３を
含む。このようなメモリは、情報を保存して取り出すことができる回路を含む。ＲＯＭ９
３は、一般に、容易に変更できない保存データを含む。ＲＡＭ８２に保存されたデータは
、プロセッサ９１もしくは他のハードウェアデバイスによって読み取られ得るか、または
変更され得る。ＲＡＭ８２またはＲＯＭ９３へのアクセスは、メモリコントローラ９２に
よって制御されてもよい。メモリコントローラ９２は、命令が実行される際に、仮想アド
レスを物理アドレスに変換するアドレス変換機能を提供してもよい。メモリコントローラ
９２はまた、システム内のプロセスを分離し、ユーザプロセスからシステムプロセスを分
離するメモリ保護機能を提供してもよい。したがって、第１のモードで実行されるプログ
ラムは、そのプロセスの仮想アドレス空間によってマッピングされたメモリのみにアクセ
スし得、プロセス間のメモリ共有が設定されていない限り、他のプロセスの仮想アドレス
空間内のメモリにアクセスすることはできない。

【0303】

さらに、コンピューティングシステム９０は、プロセッサ９１からの命令をプリンタ９
４、キーボード８４、マウス９５、およびディスクドライブ８５などの周辺機器に通信す
るための役割を担う周辺機器コントローラ８３を含んでいてもよい。

【0304】

ディスプレイコントローラ９６によって制御されるディスプレイ８６は、コンピューテ
ィングシステム９０によって生成された視覚的出力を表示するために使用される。このよ
うな視覚的出力は、テキスト、グラフィックス、アニメーショングラフィックス、および
ビデオを含んでもよい。視覚的出力は、グラフィカルユーザインタフェース（Graphical
User Interface：ＧＵＩ）の形態で提供されてもよい。ディスプレイ８６は、ＣＲＴ
ベースのビデオディスプレイ、ＬＣＤベースのフラットパネルディスプレイ、ガスプラズ
マベースのフラットパネルディスプレイ、またはタッチパネルで実装されてもよい。ディ
スプレイコントローラ９６は、ディスプレイ８６に送信されるビデオ信号を生成するため
に必要な電子コンポーネントを含む。

【0305】

さらに、コンピューティングシステム９０は、図１２Ａ、図１２Ｂ、図１２Ｃ、図１２
Ｄ、もしくは図１２Ｅの、ＲＡＮ１０３／１０４／１０５、コアネットワーク１０６／１
０７／１０９、ＰＳＴＮ１０８、インターネット１１０、ＷＴＲＵ１０２、またはその他
のネットワーク１１２などの、外部通信ネットワークまたはデバイスに、コンピューティ
ングシステム９０を接続するために使用され、コンピューティングシステム９０がそれら
のネットワークの他のノードまたは機能エンティティと通信できるようにし得る、例えば
無線または有線ネットワークアダプタ９７などの通信回路を含んでいてもよい。通信回路
は、単独で、またはプロセッサ９１と組み合わせて、本明細書に記載されている特定の装
置、ノード、または機能エンティティの送受信ステップを実行するために使用されてもよ
い。

【0306】

本明細書に記載されている装置、システム、方法、およびプロセスのいずれかまたは全
てが、コンピュータ可読記憶媒体に保存されたコンピュータ実行可能命令（例えば、プロ
グラムコード）の形態で具現化されてもよく、この命令は、プロセッサ１１８または９１
などのプロセッサによって実行されると、プロセッサに、本明細書に記載されたシステム
、方法、およびプロセスを実行または実施させることが理解される。具体的には、本明細
書に記載されているステップ、動作、または機能のいずれかは、無線または有線のネット
ワーク通信のために構成された装置またはコンピューティングシステムのプロセッサ上で
実行される、そのようなコンピュータ実行可能命令の形態で実装されてもよい。コンピュ
ータ可読記憶媒体は、情報を保存するための任意の非一時的（例えば、有形もしくは物理
的）な方法または技術で実装された揮発性および不揮発性、取り外し可能および取り外し
不可能な媒体を含むが、そのようなコンピュータ可読記憶媒体には信号は含まれない。コ
ンピュータ可読記憶媒体には、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリもしく
は他のメモリ技術、ＣＤ－ＲＯＭ、デジタル多用途ディスク（Digital Versatile Disk
：ＤＶＤ）もしくは他の光ディスクストレージ、磁気カセット、磁気テープ、磁気ディス
クストレージもしくは他の磁気ストレージデバイス、または、所望の情報を保存するため
に使用され、コンピューティングシステムによってアクセスされ得る他の有形もしくは物
理的媒体が含まれるが、これらに限定されない。

【0307】

本開示の主題であるＮＲ－Ｕ ＬＢＴ ＭＡＣ手順の好ましい方法、システム、または
装置を図に示すように説明する際、明確にするために特定の用語が採用されている。しか
し、請求項に記載された主題は、そのように選択された特定の用語に限定されることを意
図しておらず、各特定の要素は、同様の目的を達成するために同様の方法で動作する全て
の技術的等価物を含むことを理解すべきである。

【0308】

本明細書に記載されている様々な技術は、ハードウェア、ファームウェア、ソフトウェ
ア、または必要に応じて、それらの組み合わせに関連して実装されてもよい。このような
ハードウェア、ファームウェア、およびソフトウェアは、通信ネットワークの様々なノー
ドに配置された装置に常駐してもよい。装置は、本明細書に記載されている方法を実現す
るために、単独で、または互いに組み合わせて動作してもよい。本本発明で使用する場合
、「装置」、「ネットワーク装置」、「ノード」、「デバイス」、「ネットワークノード
」などの用語が互換的に使用され得る。さらに、「または」という言葉の使用は、本明細
書で別段の定めがない限り、一般的に包括的に使用される。

【0309】

この書面による明細書では、最良のモードを含む本発明を開示するために例を使用して
おり、また、任意のデバイスまたはシステムを作成および使用し、任意の組み込まれた方
法を実行することを含めて、当業者が本発明を実施できるようにする。特許を受けること
ができる範囲は、特許請求の範囲によって定義され、当業者が想到する他の実施例（例え
ば、本明細書に開示された例示的な方法の間でステップをスキップすること、ステップを
組み合わせること、または、ステップを追加すること）を含み得る。このような他の実施
例は、特許請求の範囲の文字通りの言語とは異なることのない構造要素を有する場合、ま
たは特許請求の範囲の文字通りの言語とは実質的に異なる同等の構造要素を含む場合、特
許請求の範囲に含まれることが意図される。

【0310】

この書面による明細書では、最良のモードを含む主題を開示するために例を使用してお
り、また、任意のデバイスまたはシステムを作成および使用し、任意の組み込まれた方法
を実行することを含めて、当業者が主題を実施できるようにする。特許を受けることがで
きる範囲は、特許請求の範囲によって定義され、例えば、当業者が想到する他の実施例（
例えば、特に図２～図１０など、本明細書に開示された例示的な方法の間でステップをス
キップすること、ステップを組み合わせること、または、ステップを追加すること）を含
み得る。このような他の実施例は、特許請求の範囲の文字通りの言語とは異なることのな
い構造要素を有する場合、または特許請求の範囲の文字通りの言語とは実質的に異なる同
等の構造要素を含む場合、特許請求の範囲に含まれることが意図される。

【0311】

本明細書に記載されている方法、システム、および装置などは、とりわけ、手段ＮＲ－
Ｕ ＬＢＴ ＭＡＣ手順を提供してもよい。ＳＲ手順のＬＢＴ失敗により、１）代替ＢＷ
Ｐへの切り替え、２）ＲＡ手順の開始、または、３）ＳＲ保留状態の維持につながり得る
。ＤＲＸ手順のＬＢＴ失敗により、１）オンデュレーションまたは非アクティブタイマの
延長、２）オンデュレーションまたは非アクティブタイマの、ＭＣＯＴ、ＣＷＳ、または
ＣＣＡへの整合、または、３）ショートサイクルの適用、のいずれかにつながり得る。Ｒ
Ａ手順のＬＢＴ失敗により、１）統計報告を生成することもしくは送信すること、または
、２）禁止タイマを設定すること、につながり得る。ＢＷＰ手順のＬＢＴ失敗により、１
）ＢＷＰ非アクティブタイマを延長すること、または、２）代替ＢＷＰへ切り替えること
、につながり得る。このパラグラフおよび次のパラグラフ（または本明細書の関連したパ
ラグラフ）の全ての組み合わせ（ステップの削除または追加を含む）が意図されている。

【0312】

方法、システム、および装置は、とりわけ、本明細書に記載されているように、手段Ｎ
Ｒ－Ｕ ＬＢＴ ＭＡＣ手順を提供してもよい。方法、システム、コンピュータ可読記憶
媒体、または装置は、とりわけ、ランダムアクセス手順、ＳＣｅｌｌアクティブ化／非ア
クティブ化手順、間欠受信手順、スケジューリング要求手順、バッファステータス報告手
順、論理チャネル優先順位付け手順、ＵＥとＮＢのＭＡＣ手順の調整、パワーヘッドルー
ム報告手順、または帯域幅部分動作手順に関して、ＬＢＴ失敗を判定する手段を有する。
方法、システム、コンピュータ可読記憶媒体、または装置は、プリアンブル送信カウンタ
が１より大きく、パワーランピングカウンタの一時停止の通知が下位層から受信されてお
らず、選択されたＳＳＢが変更されず、ＬＢＴ失敗が検出されていないことを判定する手
段、および、判定ステップに基づいて、プリアンブルパワーランピングカウンタを１だけ
インクリメントする命令を提供する手段を有する。方法、システム、コンピュータ可読記
憶媒体、または装置は、ユーザ機器（ＵＥ）に関連付けられたＬＢＴ状態の表示を取得す
ること（例えば、リモートデバイスから受信すること、またはローカルセンサを使用して
検出すること）、およびＬＢＴ報告ＭＡＣ制御要素（ＬＢＴＲ ＭＡＣ ＣＥ）を生成す
ることを含み得る、リッスンビフォートーク（ＬＢＴ）およびメディアアクセス制御（Ｍ
ＡＣ）に関連付けられた動作のための手段を有し、ＬＢＴＲ ＭＡＣ ＣＥは、ＬＢＴ状
態の表示を含み得る。方法、システム、コンピュータ可読記憶媒体、または装置は、ＬＢ
Ｔタイミング情報をＭＡＣ層に提供する手段を有する。ＬＢＴタイミング情報は、クリア
チャネル評価の期間、最大チャネル占有時間、またはコンテンションウィンドウを含んで
もよい。方法、システム、コンピュータ可読記憶媒体、または装置は、ユーザ機器（ＵＥ
）に関連付けられたＬＢＴ失敗の第１の閾値またはＬＢＴ成功の第２の閾値を検出するこ
とと、第１の閾値または第２の閾値の検出に基づいて、ＤＲＸ設定を調整することとを含
み得る、リッスンビフォートーク（ＬＢＴ）および間欠受信（ＤＲＸ）に関連付けられた
動作のための手段を有する。ＤＲＸ設定は、オンデュレーションまたは非アクティブタイ
マを含んでもよい。本発明の方法、システム、コンピュータ可読記憶媒体、または装置は
、基地局がＵＥに情報を提供する手段を有し、情報は、基地局またはＵＥに関連付けられ
たアクセスチャネルに関するダウンリンク情報を含み得る。ＵＥは、アップリンク情報に
関する情報を自動的に検出してもよい。アップリンク情報またはダウンリンク情報に基づ
いて、ＵＥは異なるＭＡＣ手順を行ってもよい。一実施例では、ＵＥは、アップリンク情
報およびダウンリンク情報を使用して、ＬＢＴ失敗を報告するか否か、またはどの手順が
影響を受けるかを報告するか否かを判定してもよい。方法、システム、コンピュータ可読
記憶媒体、または装置は、基地局によって検出されたダウンリンク情報を取得し、ダウン
リンク情報は、基地局のチャネルアクセスに関連付けられ、ダウンリンクのリッスンビフ
ォートーク失敗の表示を含み得、アップリンク情報を取得し、アップリンク情報は、装置
によって検出され、アップリンク情報は、装置のチャネルアクセスに関連付けられ、アッ
プリンクのリッスンビフォートーク失敗の表示を含み得、および、アップリンクのリッス
ンビフォートーク失敗の表示またはダウンリンクのリッスンビフォートーク失敗の表示に
基づいて、メディアアクセス制御動作を実行する、手段を有する。アップリンクのリッス
ンビフォートーク失敗（もしくは成功）、またはダウンリンクのリッスンビフォートーク
失敗（もしくは成功）は、スケジューリング要求手順、バッファステータス報告手順、論
理チャネル優先順位付け手順、間欠受信手順、ＳＣｅｌｌアクティブ化もしくは非アクテ
ィブ化手順、パワーヘッドルーム報告手順、ランダムアクセス手順、リッスンビフォート
ーク報告手順、または帯域幅部分動作手順によって検出され得る。このパラグラフおよび
次のパラグラフ（または本明細書の関連したパラグラフ）の全ての組み合わせ（ステップ
の削除または追加を含む）が意図されている。

【0313】

方法、システム、コンピュータ可読記憶媒体、または装置は、ＭＡＣ手順を管理する手
段を有する。方法、システム、コンピュータ可読記憶媒体、または装置は、ダウンリンク
情報を取得する手段を有し、ダウンリンク情報は、基地局の（装置への）チャネルアクセ
スに関連付けられ、アップリンク情報（例えば、ユーザ機器）を取得する手段を有し、ア
ップリンク情報は、装置による（例えば、基地局への）チャネルアクセスに関連付けられ
、アップリンク情報またはダウンリンク情報に基づいて、メディアアクセス制御動作を実
行する。ダウンリンク情報は、基地局によって検出されてもよい。アップリンク情報は、
装置によって検出されてもよい。チャネルアクセス情報は、リッスンビフォートーク動作
に関連する情報であってもよい。メディアアクセス制御動作の実行は、帯域幅部分の非ア
クティブタイマを延長することを含んでもよく、アップリンクまたはダウンリンク情報は
、アップリンクまたはダウンリンクのリッスンビフォートーク失敗情報を含む。ＵＬまた
はＤＬのＬＢＴ失敗情報時に、ＢＷＰを切り替えることがあってもよい（ＢＷＰ動作ＭＡ
Ｃ手順とは独立しており、切り替えは事前に設定された代替ＢＷＰへの切り替えであって
もよい）。メディアアクセス制御動作の実行は、ランダムアクセス応答ウィンドウを延長
することを含んでもよく、アップリンクまたはダウンリンク情報は、アップリンクまたは
ダウンリンクのリッスンビフォートーク失敗情報を含む。メディアアクセス制御動作の実
行は、プリアンブル送信カウンタをインクリメントしないこと、または競合解決タイマを
延長することを含んでもよく、アップリンクまたはダウンリンク情報は、アップリンクま
たはダウンリンクのリッスンビフォートーク失敗情報を含む。メディアアクセス制御動作
の実行は、パワーランピングを維持することまたは減少させることを含んでもよく、アッ
プリンクまたはダウンリンク情報は、アップリンクまたはダウンリンクのリッスンビフォ
ートーク失敗情報を含む。開示された主題は、ＬＢＴ失敗によるＲＡ手順の停止を回避し
得る。さらに、プリアンブル送信ＬＢＴ失敗閾値を超えると、上位層にＲＡ問題が示され
、ＲＡ手順が不成功であると見なされ得る。メディアアクセス制御動作の実行は、リッス
ンビフォートーク失敗または成功があるか否かを判定することに基づいて、物理アップリ
ンク制御チャネルリソースが有効であると判定することを含んでもよく、これは、ＳＲ手
順がＬＢＴ失敗閾値に到達してＰＵＣＣＨリソースを解放することに関連付けられてもよ
い。ＣＣＡ、ＭＣＯＴ、またはＣＷＳ情報は、ＬＢＴ成功情報と共に提供されてもよい。
また、このＣＣＡ、ＭＣＯＴ、またはＣＷＳ情報を含むＬＢＴ成功は、成功の認識は失敗
がなかったことを意味するため、ＬＢＴ失敗表示と同等であり得る。ＬＢＴが参照される
場合、ＬＢＴ成功表示によって判定され得る。ＤＲＸにおいては、ＬＢＴ失敗時にショー
トサイクルの適用またはアクティブタイムの延長でカバーしてもよい。さらに、インアク
ティビティタイマを再起動するときに、ＬＢＴの失敗がアクティブタイムを延長する回数
に制限がある場合がある。さらに、ＬＢＴ失敗時にＤＲＸの設定を調整する。これは、オ
ンデュレーション、インアクティビティ、またはＤＲＸサイクルタイマに関連付けられ得
る。ＬＢＴＲについては、ＬＢＴの失敗または成功時に、ＬＢＴの成功または失敗が既知
の期間にわたって閾値を超えた場合に、基地局への報告がトリガされ、報告が送信された
後、報告の頻度を制限するために禁止タイマが設定され、報告にはＣＣＡ、ＭＣＯＴ、ま
たはＣＷＳなどのタイミング情報が含まれ得る。ＬＢＴが既知の閾値に達したことによる
ＳＲ失敗により、ＲＡ手順が開始される（例えば、ＬＢＴ失敗によりＳＲ送信カウンタが
インクリメントされない回数を制限することにより達成される）、ＬＢＴ失敗時にＳＲ禁
止タイマが設定されない、またはＬＢＴ失敗時にＳＲ保留が維持され得る。メディアアク
セス制御動作の実行は、スケジューリング要求送信のリッスンビフォートーク失敗表示に
基づいて、スケジューリング要求失敗を判定すること、またはランダムアクセス手順を開
始することを含んでもよい。メディアアクセス制御動作の実行は、スケジューリング要求
送信のリッスンビフォートーク失敗表示に基づいて、スケジューリング要求の失敗を判定
すること、または帯域幅部分を切り替えることが含まれてもよい。メディアアクセス制御
動作の実行は、装置のＭＡＣ手順タイマもしくはカウンタを拡張すること、ＭＡＣ手順が
アップリンクもしくはダウンリンクチャネルアクセスによって達成されるときの動作に影
響を与え、ライセンス動作と同様の性能を可能にすること、または装置がチャネルアクセ
ス情報を基地局に報告することを含んでもよい。このパラグラフおよび次のパラグラフ（
または本明細書の関連したパラグラフ）の全ての組み合わせ（ステップの削除または追加
を含む）が意図されている。

【0314】

方法、システム、コンピュータ可読記憶媒体、または装置は、ＭＡＣ手順を管理する手
段を有する。方法、システム、コンピュータ可読記憶媒体、または装置は、基地局からダ
ウンリンク情報を取得する手段を有し、ダウンリンク情報は、装置のチャネルアクセスに
関連付けられ、アップリンク情報を取得し、アップリンク情報は、装置によって検出され
、アップリンク情報またはダウンリンク情報に基づいて、メディアアクセス制御動作を実
行する、手段を有する。メディアアクセス制御動作の実行は、帯域幅部分の非アクティブ
タイマを延長することを含んでもよく、アップリンクまたはダウンリンク情報は、アップ
リンクまたはダウンリンクのリッスンビフォートーク失敗情報を含んでもよい。メディア
アクセス制御動作の実行は、ランダムアクセス応答ウィンドウを延長することを含んでも
よく、アップリンクまたはダウンリンク情報は、アップリンクまたはダウンリンクのリッ
スンビフォートーク失敗情報を含んでもよい。メディアアクセス制御動作の実行は、プリ
アンブル送信カウンタをインクリメントすること、または競合解決タイマを延長すること
を含んでもよく、アップリンクまたはダウンリンク情報は、アップリンクまたはダウンリ
ンクのリッスンビフォートーク失敗情報を含んでもよい。メディアアクセス制御動作の実
行は、パワーランピングを維持すること、または減少させること(例えば、増加させない
こと)を含んでもよく、アップリンクまたはダウンリンク情報は、アップリンクまたはダ
ウンリンクのリッスンビフォートーク失敗情報を含んでもよい。メディアアクセス制御動
作の実行は、リッスンビフォートーク失敗または失敗成功（例えば、閾値成功または失敗
によってトリガされる）があるか否かを判定することに基づいて、物理アップリンク制御
チャネル(ＰＵＣＣＨ)リソースが有効であると判定することを含んでもよい。メディアア
クセス制御動作の実行は、間欠受信動作を調整することを含んでもよく、アップリンクま
たはダウンリンク情報は、間欠受信サイクルで基地局からシグナリングされる、クリアチ
ャネル評価期間、最大チャネル占有時間、またはダウンリンクリッスンビフォートーク成
功指示を含んでもよい。メディアアクセス制御動作を実行することは、間欠受信動作にお
いて、最大チャネル占有時間期間と整合するようにアクティブタイムを調整すること、お
よびコンテンションウィンドウサイズ期間またはクリアチャネル評価期間中に間欠受信を
適用すること含んでもよい。最大チャネル占有時間の期間との整合は、オンデュレーショ
ンタイマを調整すること、または非アクティブタイマを調整することを含んでもよい。メ
ディアアクセス制御動作を実行することは、アップリンクまたはダウンリンク情報の影響
を受けるメディアアクセス制御動作を報告することを含んでもよい。メディアアクセス制
御動作の実行は、アップリンクまたはダウンリンク情報によって影響を受けるメディアア
クセス制御動作を報告することを含んでもよく、アップリンクまたはダウンリンク情報は
、アップリンクまたはダウンリンクのリッスンビフォートーク失敗情報を含んでもよい。
メディアアクセス制御動作の実行は、メディアアクセス制御動作のうちの１つ以上が、ア
ップリンクまたはダウンリンク情報によってどのように影響されるかを報告することを含
んでもよい。メディアアクセス制御動作の実行は、メディアアクセス制御動作のうちの１
つ以上が、アップリンクまたはダウンリンク情報によってどのように影響されるかを報告
することを含んでもよく、アップリンクまたはダウンリンク情報は、アップリンクまたは
ダウンリンクのリッスンビフォートーク失敗情報を含んでもよい。一般に、ＬＢＴの失敗
または成功などのアップリンクまたはダウンリンク情報は、とりわけ、本明細書に開示さ
れているようなＭＡＣ動作をトリガし得る。装置は、ユーザ機器であってもよい。このパ
ラグラフ（または本明細書の関連したパラグラフ）の全ての組み合わせ（ステップの削除
または追加を含む）が意図されている。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12A】

【図12B】

【図12C】

【図12D】

【図12E】

【図12F】

【図12G】

【手続補正書】

【提出日】2024-04-11

【手続補正1】

【補正対象書類名】特許請求の範囲

【補正対象項目名】全文

【補正方法】変更

【補正の内容】

【特許請求の範囲】

【請求項1】

プロセッサとメモリとを備えた無線送受信ユニット（ＷＴＲＵ）であって、
前記プロセッサおよび前記メモリは、
１つ以上のリッスンビフォートーク（Listen Before Talk：ＬＢＴ）失敗が発生したと判定し、
前記１つ以上のＬＢＴ失敗が発生したとする判定に基づいて、ランダムアクセスプリアンブルの送信を試行し、
前記ランダムアクセスプリアンブルの送信にＬＢＴ失敗があったと判定し、
前記ランダムアクセスプリアンブルの送信にＬＢＴ失敗があったとする判定に基づいて、プリアンブル送信カウンタをインクリメントしないこと、およびプリアンブルパワーランピングカウンタをインクリメントしないことを判定し、
スライディングタイムウィンドウ内でＬＢＴ失敗カウンタが設定された失敗の表示数に達したと判定し、
前記スライディングタイムウィンドウ内でＬＢＴ失敗カウンタが設定された失敗の表示数に達したとする判定に基づいて、第１帯域幅部分（Bandwidth Part：ＢＷＰ）から第２ＢＷＰへ切り替え、
前記ＷＴＲＵによって検出されたＬＢＴ失敗情報を示すＬＢＴ報告メディアアクセス制御（Medium Access Control：ＭＡＣ）制御要素（Control Element：ＣＥ）を基地局に送信するよう構成されている、
ＷＴＲＵ。

【請求項2】

前記スライディングタイムウィンドウは、ＬＢＴ失敗の検出によって延長された期間に相当する、請求項１に記載のＷＴＲＵ。

【請求項3】

前記ＬＢＴ報告ＭＡＣ ＣＥは、利用可能なアップリンク共有チャネル（uplink shared channel：ＵＬ－ＳＣＨ）リソースを用いて前記基地局に送信される、請求項１に記載のＷＴＲＵ。

【請求項4】

前記プロセッサおよびメモリは、さらに、前記ＬＢＴ失敗カウンタをゼロにリセットするよう構成される、請求項１に記載のＷＴＲＵ。

【請求項5】

前記スライディングタイムウィンドウ内で発生した失敗の表示は、少なくとも１つのアップリンク失敗および少なくとも１つのダウンリンク失敗に関連している、請求項１に記載のＷＴＲＵ。

【請求項6】

前記プロセッサおよびメモリは、さらに、トリガされた一貫するＬＢＴ失敗をキャンセルするよう構成される、請求項１に記載のＷＴＲＵ。

【請求項7】

前記１つ以上のＬＢＴ失敗が発生したとする判定は、物理層の表示に基づいている、請求項１に記載のＷＴＲＵ。

【請求項8】

前記ランダムアクセスプリアンブルの送信に失敗があったとする判定は、物理層の表示に基づいている、請求項１に記載のＷＴＲＵ。

【請求項9】

無線送受信ユニット（ＷＴＲＵ）によって実行される方法であって、
１つ以上のリッスンビフォートーク（Listen Before Talk：ＬＢＴ）失敗が発生したと判定することと、
前記１つ以上のＬＢＴ失敗が発生したとする判定に基づいて、ランダムアクセスプリアンブルの送信を試行することと、
前記ランダムアクセスプリアンブルの送信にＬＢＴ失敗があったと判定することと、
前記ランダムアクセスプリアンブルの送信にＬＢＴ失敗があったとする判定に基づいて、プリアンブル送信カウンタをインクリメントしないこと、およびプリアンブルパワーランピングカウンタをインクリメントしないことを判定することと、
スライディングタイムウィンドウ内でＬＢＴ失敗カウンタが設定された失敗の表示数に達したと判定することと、
前記スライディングタイムウィンドウ内でＬＢＴ失敗カウンタが設定された失敗の表示数に達したとする判定に基づいて、第１帯域幅部分（Bandwidth Part：ＢＷＰ）から第２ＢＷＰへ切り替えることと、
前記ＷＴＲＵによって検出されたＬＢＴ失敗情報を示すＬＢＴ報告メディアアクセス制御（Medium Access Control：ＭＡＣ）制御要素（Control Element：ＣＥ）を基地局に送信することと、
を含む方法。

【請求項10】

前記スライディングタイムウィンドウは、ＬＢＴ失敗の検出によって延長された期間に相当する、請求項９に記載の方法。

【請求項11】

前記ＬＢＴ報告ＭＡＣ ＣＥは、利用可能なアップリンク共有チャネル（uplink shared channel：ＵＬ－ＳＣＨ）リソースを用いて前記基地局に送信される、請求項９に記載の方法。

【請求項12】

前記ＬＢＴ失敗カウンタをゼロにリセットすることをさらに含む、請求項９に記載の方法。

【請求項13】

前記スライディングタイムウィンドウ内で発生した失敗の表示は、少なくとも１つのアップリンク失敗および少なくとも１つのダウンリンク失敗に関連している、請求項９に記載の方法。

【請求項14】

トリガされた一貫するＬＢＴ失敗をキャンセルすることをさらに含む、請求項９に記載の方法。

【請求項15】

前記１つ以上のＬＢＴ失敗が発生したとする判定は、物理層の表示に基づいている、請求項９に記載の方法。

【請求項16】

前記ランダムアクセスプリアンブルの送信に失敗があったとする判定は、物理層の表示に基づいている、請求項９に記載の方法。

【外国語明細書】