(57)【要約】【解決手段】  ビーム回復リクエストをトリガ、キャンセルおよび伝送するための方法を含むビーム障害回復およびスケジューリングリクエストの機構、方法および機能を提供する。スケジューリングリクエストは、グラントフリー上りリンク共有チャネル（ＵＬ−ＳＣＨ）での伝送、およびスケジュールリクエストを保留状態にするための新しい基準に適応するように設計されてよい。
2020524439.tif 000002
【特許請求の範囲】
【請求項１】
プロセッサと、メモリと、通信回路と、を備える装置であって、
当該通信回路を介して通信ネットワークと接続しており、
当該装置の前記プロセッサによって実行されると、論理チャネル（Logical  Channel：ＬＣＨｊ）の優先順位付けビットレート（Prioritized  Bit  Rate：ＰＢＲ）と、前記ＬＣＨｊの連続する各データ伝送機会（Data  Transmission  Opportunities：ＤＴＴＩ）間の時間間隔との積によって、前記ＬＣＨｊの優先順位付けされたバケットのサイズ（Ｂｊ）をインクリメントすることによって、新しい伝送に対する論理チャネル優先順位付けを前記装置に実施させる、前記装置の前記メモリに記憶されたコンピュータ実行可能命令をさらに含み、
上りリンクグラントが、前記ＬＣＨｊを作動するために利用可能である、
装置。
【請求項２】
前記命令はさらに、前記ＬＣＨｊが最初に確立されるときに、前記装置にＢｊを０にセットさせる、請求項１に記載の装置。
【請求項３】
前記命令はさらに、Ｂｊが前記ＬＣＨｊのバケットサイズを超える場合、前記ＬＣＨｊの前記バケットサイズに等しいＢｊを、前記装置にセットさせ、前記ＬＣＨｊの前記バケットサイズは、前記ＬＣＨｊのＰＢＲと、前記ＬＣＨｊのバケットサイズ長（Bucket  Size  Duration：ＢＳＤ）との積と等しい、請求項２に記載の装置。
【請求項４】
前記ＬＣＨｊの前記ＤＴＴＩは、前記上りリンクグラントによって許可される、連続するデータ伝送機会間の間隔と等しい、請求項３に記載の装置。
【請求項５】
前記ＬＣＨｊの前記ＤＴＴＩは、前記上りリンクグラント下で、実際に使用される連続するデータ伝送機会間の間隔と等しい、請求項３に記載の装置。
【請求項６】
前記命令はさらに、前記装置に、許容されるレイテンシパラメータのセットの中の前記上りリンクグラントに基づいて、前記ＬＣＨｊは前記上りリンクグラントによって作動されてもよいと判断させる、請求項３に記載の装置。
【請求項７】
前記許容されるレイテンシパラメータのセットは、最大レイテンシ時間および最小レイテンシ時間を含む、請求項６に記載の装置。
【請求項８】
前記最大レイテンシ時間および前記最小レイテンシ時間は、関連するレイテンシ係数によってスケーリングされる、請求項７に記載の装置。
【請求項９】
前記関連するレイテンシ係数は、再伝送数に関連付けられる、請求項８に記載の装置。
【請求項１０】
前記許容されるレイテンシパラメータのセットは、残りのハイブリッド自動要求（Hybrid  Automatic  Request：ＨＡＲＱ）動作点をさらに含む、請求項７に記載の装置。
【請求項１１】
前記命令はさらに、前記装置に、残りのブロック誤り率（Block  Error  Rate：ＢＬＥＲ）、および目標ＢＬＥＲの再伝送数に応じて前記残りの（ＨＡＲＱ）操作点を計算させる、請求項１０に記載の装置。
【請求項１２】
前記命令はさらに、（ａ）バッファ状態報告（Buffer  Status  Reporting：ＢＳＲ）が、トリガされたが、キャンセルはされていない、および、（ｂ）前記許容されるレイテンシの中に、前記ＢＳＲを伝送するのに利用可能な、上りリンクグラントがないときに、前記装置に、スケジューリングリクエスト（Scheduling  Request：ＳＲ）を伝送させる、請求項１に記載の装置。
【請求項１３】
前記命令はさらに、（ａ）バッファ状態報告（ＢＳＲ）がトリガされたが、キャンセルはされていない、（ｂ）スケジューリングリクエスト（ＳＲ）リソースがない、（ｃ）前記許容されるレイテンシの中に、前記ＢＳＲを伝送するのに利用可能な、上りリンクグラントがないときに、前記装置にランダムアクセスプロシージャを実施させる、請求項１に記載の装置。
【請求項１４】
前記命令はさらに、（ａ）バッファ状態報告（ＢＳＲ）がトリガされたが、キャンセルはされていない、（ｂ）割り当てられる上りリンクグラントなしで、ＳＲ伝送が許容される最大値に達する、（ｃ）前記許容されるレイテンシの中に、前記ＢＳＲを伝送するのに利用可能な、上りリンクグラントがないときに、前記装置にランダムアクセスプロシージャを実施させる、請求項１に記載の装置。
【請求項１５】
前記命令はさらに、（ａ）ＳＲリソースが、前記ＳＲの伝送のために利用可能になるか、または（ｂ）ランダムアクセス応答（Random  Access  Response：ＲＡＲ）メッセージが前記装置によって受信される前に、前記ＢＳＲ伝送のための上りリンクリソースが利用可能になる場合、前記装置に、前記ランダムアクセスプロシージャをキャンセルさせる、請求項１３または１４に記載の装置。
【請求項１６】
プロセッサと、メモリと、通信回路と、を備える装置であって、
当該通信回路を介して通信ネットワークと接続しており、
当該装置の前記プロセッサによって実行されると、前記装置に、次の上りリンクグラントに基づいて、スケジューリングリクエストまたはランダムアクセスチャネルプロシージャの伝送を遅らせる前記装置の前記メモリに記憶されたコンピュータ実行可能命令をさらに含み、
前記上りリンクグラントは、バッファ状態報告（Buffer  Status  Reporting：ＢＳＲ）のために利用可能である、
装置。
【請求項１７】
前記装置は、前記ランダムアクセスチャネルプロシージャを遅らせ、前記ランダムアクセスチャネルプロシージャは、物理ランダムアクセスチャネル（Physical  Random  Access  Channel：ＰＲＡＣＨ）である、請求項１７に記載の装置。
【請求項１８】
前記命令はさらに、前記装置に、前記次の上りリンクグラントの論理チャネル制約に基づいて、前記スケジューリングリクエストの伝送、または前記ランダムアクセスチャネルプロシージャを遅らせるかどうかを決定させる、請求項１７に記載の装置。
【請求項１９】
前記命令はさらに、前記装置に、スケジューリングリクエスト制約タイマを管理させる、請求項１７に記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
（関連出願の相互参照）
本出願は、２０１７年６月１５日に出願の米国仮出願番号第６２／５２０，２２６号、２０１７年１１月２日に出願の米国仮出願番号第６２／５８０，８１２号および２０１８年１月１０日に出願の米国仮出願番号第６２／６１５，７１６号の利益を請求し、その開示全体が本明細書へ参照により組み込まれる。
【背景技術】
【０００２】
モノのインターネット（Internet-of-Things：ＩｏＴ）またはモノのウェブ（Web  of  Things：ＷｏＴ）システムとも呼ばれるマシンツーマシン（Machine-To-Machine：Ｍ２Ｍ）システムは、しばしば、種々のネットワークプロトコルがその中で多様なデバイス、アプリケーションおよびサービスをサポートするために使用される複数の相互接続した異種ネットワークを組み込む。これらのプロトコルは様々な機能および機構を有し、それぞれが１つの状況または互いに対して最適化される。デバイス、アプリケーション、サービスおよび状況の多様性がゆえに、画一的なソリューションがない。
【０００３】
本開示は、ユーザ端末（User  Equipment：ＵＥ）、発展型Ｎｏｄｅ−Ｂ（Evolved  Node-B：ｅＮＢ）、新無線（New  Radio：ＮＲ）ノード、遠隔無線ヘッド（Remote  Radio  Head：ＲＲＨ）および送受信ポイント（Transmission  and  Reception  Point：ＴＲＰ）などのノードに関し、かつ、端末および無線アクセスネットワーク（Radio  Access  Network：ＲＡＮ）システムのデータリンクおよび物理レイヤ、ならびに、第３世代パートナーシッププロジェクト（3rd  Generation  Partnership  Project：３ＧＰＰ）および他のＭ２Ｍ、ＩｏＴ、ＷｏＴおよび類似のアーキテクチャにおける類似のノードおよびレイヤに関する。このようなノード、レイヤおよびアーキテクチャについては、例えば、3GPP  TR  38.913  Study  on  Scenarios  and  Requirements  for  Next  Generation  Access  Technologies,  (Release  14),  V0.2.0、Chairman’s  Note  of  3GPP  TSG  RAN  WG1#88b、3GPP  TS  36.321  E-UTRA  Medium  Access  Control  (MAC)  protocol  specification,V15.0.0、3GPP  TS  38.321  NR  Medium  Access  Control  (MAC)  protocol  specification,  V15.0.0、および3GPP  TS  38.331  NR  Radio  Resource  Control  (RRC)  protocol  specification,  V15.0.0に記載されている。
【発明の概要】
【０００４】
ビーム回復が、ビーム回復リクエスト（Beam  Recovery  Requests：ＢＲＲ）をトリガし、伝送し、キャンセルするプロシージャおよび技術を介して容易になる可能性がある。
【０００５】
スケジューリングリクエストが、グラントフリー上りリンク共有データチャネル（Uplink  Shared  Data  Channel：ＵＬ−ＳＣＨ）で伝送され、かつ保留状態にされてよい。
【０００６】
ビーム回復リクエストは、スケジューリングリクエストと多重化されてよく、かつ、スケジューリングリクエストと相互作用してよい。
【０００７】
スケジューリングリクエスト（Scheduling  Request：ＳＲ）障害報告および物理上りリンク制御チャネル（Physical  Uplink  Control  Channel：ＰＵＣＣＨ）解放のリクエストには、ＳＲ障害タイプの使用を伴ってよく、その際、ユーザ端末（ＵＥ）のＵＥ動作は、ＳＲ障害タイプに基づく。ＳＲ障害およびＰＵＣＣＨ解放のリクエストのｇＮＢへのＵＥシグナリングは、無線リソース制御（Radio  Resource  Control：ＲＲＣ）ベースまたは媒体アクセス制御（Medium  Access  Control：ＭＡＣ）ベースのプロシージャを使用してもよい。
【０００８】
論理チャネルの優先順位付けされるビットレートの要件を満たすことを確実にするために、例えば、Ｂｊなどの変数が、論理チャネル優先順位付け（Logical  Channel  Prioritization：ＬＣＰ）プロシージャで使用されてよい。例えば、上りリンク（Uplink：ＵＬ）伝送が行われるが、論理チャネルｊのデータが供給されない各伝送機会間の経過時間が、Ｂｊの更新される値の計算に使用されてよい。あるいは、ＵＬ伝送が行われ、かつ論理チャネルｊのＵＬデータが実際に供給される各伝送機会間の経過時間が、Ｂｊの更新される値の計算に使用されてよい。
【０００９】
論理チャネル選択は、ブロック誤り率（Block  Error  Rate：ＢＬＥＲ）に関する残りのハイブリッド自動再送要求（Hybrid  Automatic  Repeat  Request：ＨＡＲＱ）動作点対、所与の目標ＢＬＥＲの再伝送の数によって、スケーリングされた最小および最大論理チャネルレイテンシに基づいてもよい。
【００１０】
バッファ状態報告（Buffer  Status  Reporting：ＢＳＲ）がトリガされているが、ＢＳＲの伝送のために利用可能なＵＬ−ＳＣＨグラントがなく、まだ利用可能でないＵＥに割り当てられたグラント（例えば、後で使用可能なグラント）があるときに、タイマが、スケジューリングリクエストのトリガリングを遅らせるために使用されてよい。
【００１１】
ＳＲを伝送するのに利用可能なＰＵＣＣＨリソースがないか、ＳＲ伝送が、スケジューリングリクエスト伝送の最大値に達したときに、タイマが、ＲＡＣＨプロシージャの開始を遅らせるのに使用されてよい。
【００１２】
グラントが重複するコンテキストで、ＢＳＲが決定されることがあり、この際、どのグラントをＢＳＲのために使用するかを決定するための規則が適用される。例えば、各グラントの各ＵＬデータ伝送時間が重複し、同時に終了するか、別々に終了する場合、または、各グラントが重複していない場合、規則は、各状況に応じるものであってよい。
【００１３】
タイマが、ＢＳＲを遅らせるために使用されてよい。ＢＳＲタイマは、ＭＡＣによって開始されてよい。
【００１４】
ビーム回復リクエストをトリガ、キャンセルおよび伝送するための方法を含むビーム障害回復およびスケジューリングリクエストの機構、方法および機能を提供する。スケジューリングリクエストは、グラントフリー上りリンク共有チャネル（ＵＬ−ＳＣＨ）での伝送、およびスケジュールリクエストを保留状態にするための新しい基準に適応するように設計されてよい。
【図面の簡単な説明】
【００１５】
【図１】ＭＡＣ多重化向けのロングタームエボリューション（Long  Term  Evolution：ＬＴＥ）論理チャネル優先順位付け（ＬＣＰ）の一例を示す図である。
【図２】利用可能なＵＬグラント、および、即座にトリガされるＳＲを伴わずに、トリガされるＢＳＲの一例を示す図である。
【図３】利用可能なＵＬグラント、および、即座にトリガされるＳＲを伴わずに、トリガされるＢＳＲの一代替例を示す図である。
【図４】第１バッファ状態決定の一例を示す図である。
【図５】第２バッファ状態決定の一例を示す図である。
【図６】第３バッファ状態決定の一例を示す図である。
【図７】第４バッファ状態決定の一例を示す図である。
【図８】第５バッファ状態決定の一例を示す図である。
【図９】ビーム障害回復の方法の一例を示すフローチャートである。
【図１０】ビーム障害回復の方法の一例を示すフローチャートである。
【図１１】スケジューリングリクエストの方法の一例を示す図である。
【図１２】通信システムの一例を示す図である。
【図１３】例えば、無線伝送／受信ユニット（Wireless  Transmit/Receive  Unit：ＷＴＲＵ）などのような無線通信用に構成される装置またはデバイスの一例のブロック図である。
【図１４】無線アクセスネットワーク（ＲＡＮ）およびコアネットワークの第１の例のシステム図である。
【図１５】無線アクセスネットワーク（ＲＡＮ）およびコアネットワークの第２の例のシステム図である。
【図１６】無線アクセスネットワーク（ＲＡＮ）およびコアネットワークの第３の例のシステム図である。
【図１７】ＲＡＮ、コアネットワーク、公衆交換電話網（Public  Switched  Telephone  Network：ＰＳＴＮ）、インターネットまたは他のネットワーク内のある種のノードまたは機能性エンティティなどの通信ネットワークの１つまたは複数の装置がその中に具現化される可能性がある、例示的コンピューティングシステムのブロック図である。
【発明を実施するための形態】
【００１６】
本明細書で使用される頭字語のリストについて、付録の表１を参照する。
【００１７】
3GPP  TR  38.913  Study  on  Scenarios  and  Requirements  for  Next  Generation  Access  Technologies;  (Release  14),  V0.2.0  3では、新無線（ＮＲ）技術のシナリオおよび要件を規定している。高度化モバイルブロードバンド（Enhanced  Mobile  Broadband：ｅＭＢＢ）、超高信頼・低遅延通信（Ultra-Reliable  and  Low  Latency  Communications：ＵＲＬＬＣ）および大規模マシンタイプ通信（Massive  Machine  Type  Communication：ｍＭＴＣ）デバイスに対する主要性能指標（Key  Performance  Indicators：ＫＰＩ）は、付録の表２にまとめる。
【００１８】
ＬＴＥ／ＬＴＥ−アドバンスト（LTE-Advanced：ＬＴＥ−Ａ）では、スケジューリングリクエスト（ＳＲ）は、新しい伝送用のＵＬ−ＳＣＨリソースをリクエストするために使用される。
【００１９】
規則的なＢＳＲがトリガされ、ＵＥが少なくとも規則的なＢＳＲの伝送用の上りリンクリソースを有していない場合に、ＵＥのＭＡＣが、スケジューリングリクエストをトリガする。規則的なＢＳＲは、データが上りリンクでの伝送用に利用可能になる場合にトリガされる。
【００２０】
発展型Ｎｏｄｅ−Ｂ（Evolved  Node-B：ｅＮｏｄｅＢ）は、ＵＥがＰＵＣＣＨでＳＲを伝送するために、ＲＲＣシグナリングを介してＳＲ構成を用いてＵＥを構成する必要がある。ＳＲ構成構造は所与の付録のコード例１（表４）のようなものである。
【００２１】
ｓｒ−ＰＵＣＣＨ−ＲｅｓｏｕｒｃｅＩｎｄｅｘは、周波数ドメインリソースを有するＵＥを指し、一方、ｓｒ−ＣｏｎｆｉｇＩｎｄｅｘは、ＳＲを搬送するＰＵＣＣＨの時間領域リソースを決定する。ｅＮｏｄｅＢは、パラメータｄｓｒ−ＴｒａｎｓＭａｘを使用して、各ＵＥからのＰＵＣＣＨでのＳＲ伝送の最大数を制御する。
【００２２】
ＵＥが有効なＰＵＣＣＨリソースを有していない（ＳＲが構成または解放されていない）場合、ＵＥはランダムアクセスプロシージャを開始する。
【００２３】
一旦ＳＲがトリガされると、ＵＥはＳＲ周期、およびｓｒ−ＣｏｎｆｉｇＩｎｄｅｘ  ＩＥに基づく（現在のポストの終端で示される）オフセットを計算する。ＰＵＣＣＨで最初のＳＲを伝送した後、ＵＥが上りリンクリソースをｅＮｏｄｅＢから受信しない場合は、ＵＥは、周期に基づいて、ＰＵＣＣＨでＳＲを再送信する。このプロセスは、ＵＥがｅＮｏｄｅＢから上りリンクリソースを受信しない場合、ＵＥがＰＵＣＣＨで、ｄｓｒ−ＴｒａｎｓＭａｘの回数までに、ＳＲを伝送するまで続けられる。最大回数（ｄｓｒ−ＴｒａｎｓＭａｘ）までにＳＲを伝送した後、ＵＥは、ＳＲリソース（周波数リソースおよび時間リソース）を解放し、ランダムアクセスプロシージャを開始して、ペンディング中の（トリガされた）ＳＲのすべてをキャンセルする。
【００２４】
５、１０、２０、４０および８０ｍｓのＳＲ周期が、リリース８で最初に提案されている。リリース９では、レイテンシが削減された１および２ｍｓの短いＳＲ周期が、導入されている。
【００２５】
短いＳＲ周期が構成されるか、ＶｏＩＰトラフィックを実行するときに、ＳＲが不要に再伝送される可能性がある。不要なＳＲ伝送を防ぐために、リリース９では、ＳＲ禁止タイマ（ｓｒ−ＰｒｏｈｉｂｉｔＴｉｍｅｒ−ｒ９）が採用され、ＰＵＣＣＨでの負荷が軽減された。
【００２６】
ｓｒ−ＰｒｏｈｉｂｉｔＴｉｍｅｒ−ｒ９  ＩＥは、ｍａｃ−ＭａｉｎＣｏｎｆｉｇ下にあり、それは０から７までの値をとることがある。ＳＲ禁止タイマ値は、ＳＲ周期の回数までの値である。値０は、ＰＵＣＣＨでのＳＲ伝送向けのタイマが設定されないことを意味する。値１は、１つのＳＲ周期に相当し、値２は２＊ＳＲ周期に相当し、その他の場合も同様である。ＵＥは、ＳＲ伝送後、このタイマを開始する。このタイマが実行されるときに、ＵＥは、ＰＵＣＣＨでＳＲを伝送することになると想定されていない。ＵＥは、ＳＲの単独伝送のために、ＰＵＣＣＨフォーマット１を使用する。上りリンクでＳＲとＨＡＲＱフィードバックとが、同じサブフレームで同時に起こる場合に、ＵＥはＰＵＣＣＨフォーマット１ａ／１ｂを使用して、ＳＲ周期リソースでＨＡＲＱフィードバックを伝送してもよい。受信されるＰＵＣＣＨがＳＲリソースにあるので、ｅＮｏｄｅＢは、ＨＡＲＱフィードバックとＳＲとが同じサブフレームに存在することを容易に理解することができる。
【００２７】
ＵＥがＰＵＳＣＨとＰＵＣＣＨとの同時伝送のために構成されていないか、またはＵＥがＰＵＳＣＨとＰＵＣＣＨとの同時伝送のために構成され、かつＰＵＳＣＨを伝送しない場合で、同じサブフレーム内のＣＳＩとＳＲとの間で衝突が生じる場合、ＣＳＩはドロップされる。
【００２８】
ＵＥが最大回数（ｄｓｒ−ＴｒａｎｓＭａｘ）までにＳＲを伝送したとき、ｔｉｍｅＡｌｉｇｎｍｅｎｔＴｉｍｅｒが終了した後、ＭＡＣリセットプロシージャの間に、およびハンドオーバの間など、いくつかの状況で、ＵＥは、ＳＲリソースを解放してもよい。ハンドオーバ中、ＭＡＣリセットが実施される。
【００２９】
ハンドオーバ中に、ＵＥが発信元ｅＮｏｄｅＢの既存のＳＲリソースを解放するので、発信元ｅＮｏｄｅＢは、ターゲットｅＮｏｄｅＢで使用されることになる新しいＳＲ構成をＵＥに提供する必要がある。
【００３０】
ＳＲ構成テーブルを下記（3GPP  TS  36.213のTable  10.1.5-1）に提示する。ＳＲ伝送インスタンスは、次式（１）を満たしている上りリンクサブフレームである。付属の表３−ＳＲ構成を参照されたい。
【数１】
2020524439.tif 000003
【００３１】
（５Ｇ  ＮＲにおけるビーム回復の説明）
５Ｇ  ＮＲの現在の３ＧＰＰ標準化の取り組みにおいて、ＮＲでのビーム回復のいくつかの態様が、承認され、かつChairman’s  Note  of  3GPP  TSG  RAN  WG1#88bにて言及されている。ＵＥビーム障害回復メカニズムは、ビーム障害検出、新たな候補ビーム特定、ビーム障害回復リクエスト伝送、ビーム障害回復リクエストに対するｇＮＢ応答のＵＥによるモニタリングを含む。ビーム障害検出に関して、ビーム障害トリガ条件が満たされているかどうかを判断するために、ＵＥは、ビーム障害検出ＲＳをモニタする。ビーム障害検出ＲＳは、ビームマネジメントのための周期的ＣＳＩ−ＲＳを少なくとも含む。ビームマネジメントでＳＳブロックも同様に使用される場合、サービングセル内のＳＳブロックが考慮されてよい。ＦＦＳが、ビーム障害を宣言する場合のトリガ条件を含んでもよい。
【００３２】
他の取り決めは、新たな候補ビーム特定、ビーム障害回復リクエスト伝送、およびビーム障害回復リクエストに対するｇＮＢ応答を受信するための制御チャネルサーチスペースのＵＥによるモニタリングを含む。
【００３３】
新たな候補ビーム特定は、新たな候補ビームを見つけるために、ビーム特定ＲＳのＵＥによるモニタリングを含んでもよい。ビーム特定ＲＳは、ＮＷによって構成される場合は、ビームマネジメントのための周期的ＣＳＩ−ＲＳを含み、ビームマネジメントでＳＳブロックも同様に使用される場合、サービングセル内で周期的ＣＳＩ−ＲＳおよびＳＳブロックを含んでもよい。
【００３４】
ビーム障害回復リクエストによって運ばれる情報は、ＵＥの識別、および新たなｇＮＢ  ＴＸビーム情報に関する明示または暗黙の情報、ＵＥの識別、および新たな候補ビームの有無に関する明示または暗黙の情報、ＵＥビーム障害を示す情報、ならびに、例えば新たなビーム品質などの追加の情報を含んでもよい。
【００３５】
ビーム障害回復リクエスト伝送は、物理ランダムアクセスチャネル（Physical  Random  Access  Channel：ＰＲＡＣＨ）、ＰＵＣＣＨ、ＰＲＡＣＨと類似（例えば、ＰＲＡＣＨとは異なるプリアンブルシーケンス向けのパラメータを用いる）の選択肢など、複数の選択肢の中でのダウンセレクションを伴ってもよい。
【００３６】
ビーム障害回復リクエストリソースまたは信号が、スケジューリングリクエストのために追加的に使用されてよい。
【００３７】
ＵＥは、ビーム障害回復リクエストに対するｇＮＢ応答を受信するために、制御チャネルサーチスペースをモニタしてよい。例えば、制御チャネルサーチスペースは、サービングＢＰＬ（Beam  Pair  Link）に関連付けられた現在の制御チャネルサーチスペースと同じか、または異なるものであってもよい。ｇＮＢがビーム障害回復リクエスト伝送を受信しない場合は、ＵＥは別の対応をしてもよい。
【００３８】
また、重要なことは、ＮＷが、ビーム障害回復リクエストを受信するときに、どのように少なくとも１つのメカニズムをサポートするかである。例えば、ＮＷは、ビーム報告にＵＬのグラントを割り当て、ビーム測定のためにＤＬ  ＲＳを伝送し、ＵＥにビームインジケーションまたはビーム確認をシグナリングすることがある、など。ＵＥは、どのメカニズムを適用するかについてのＮＷの決定を支援してもよい。
【００３９】
さらに重要なことは、「新規候補ビームなし」の状況、例えば、問題があるかどうか、もしあるなら、ＲＬＦプロシージャが問題に十分に対処できるかどうかである。
【００４０】
新たな伝送が実施されるときに、論理チャネル優先順位付け（ＬＣＰ）プロシージャが、上りリンク伝送に適用されてよい。無線リソース制御（ＲＲＣ）シグナリングは、優先度の値が大きいほど優先度のレベルが低い優先度、優先順位付けされたビットレート（Prioritized  Bit  Rate：ＰＢＲ）をセットするｐｒｉｏｒｉｔｉｓｅｄＢｉｔＲａｔｅ、バケットサイズ長（Bucket  Size  Duration：ＢＳＤ）をセットするｂｕｃｋｅｔＳｉｚｅＤｕｒａｔｉｏｎ、を各論理チャネルについてシグナリングすることによって、上りリンクデータのスケジューリングを制御してもよい。ＮＢ−ＩｏＴに関しては、ｐｒｉｏｒｉｔｉｓｅｄＢｉｔＲａｔｅ、ｂｕｃｋｅｔＳｉｚｅＤｕｒａｔｉｏｎおよび論理チャネル優先順位付けプロシージャの対応するステップ（すなわち、以下のステップ１およびステップ２）は、適用できない場合がある。
【００４１】
ＭＡＣエンティティは、論理チャネルｊごとに変数Ｂｊを管理してもよい。Ｂｊは、関連する論理チャネルが確立されるときに０に初期化され、伝送時間間隔（Transmission  Time  Interval：ＴＴＩ）ごとに、ＰＢＲ×ＴＴＩ時間長の積によってインクリメントされてよいが、ここで、ＰＢＲは論理チャネルｊの優先順位付けされたビットレートである。論理チャネルが作動されるのを待ち行列で待っている間に、一定期間に論理チャネルごとにデータクレジットが蓄積されてよく、この場合、その論理チャネルが、論理チャネル優先度順序に従って作動される順番になったときに、その論理チャネルから供給されるデータ量は、論理チャネルの優先順位付けされたビットレート要件を満たしてよい。Ｂｊの値は、バケットサイズを超えることはできず、Ｂｊの値が論理チャネルｊのバケットサイズよりも大きい場合は、Ｂｊはバケットサイズに設定される。論理チャネルのバケットサイズは、ＰＢＲ×ＢＳＤに等しくてよく、ここで、ＰＢＲおよびＢＳＤは上位層によって構成される。
【００４２】
ＭＡＣエンティティは、新たな伝送を実施するときに、以下のような、論理チャネル優先順位付けプロシージャに従って、論理チャネルにリソースを割り当てることができる。
【００４３】
ステップ１、Ｂｊ＞０を用いる論理チャネルのすべてに、優先度の高い順にリソースを割り当てることができる。論理チャネルのＰＢＲが「無限大」に設定されている場合、ＭＡＣエンティティは、その論理チャネルで伝送可能なデータのすべてにリソースを割り当てた後に、より低い優先度の論理チャネルのＰＢＲを満たしてもよい。
【００４４】
ステップ２では、ＭＡＣエンティティは、ステップ１で論理チャネルｊに供給されたＭＡＣ  ＳＤＵの合計サイズだけＢｊをデクレメントしてもよく、Ｂｊの値は、負になることもある。
【００４５】
ステップ３、リソースが残っている場合、その論理チャネルのデータまたはＵＬグラントのどちらかが先に使い果たされるまで、すべての論理チャネルは、厳密に優先度の高い順で（Ｂｊの値に関係なく）作動されてよい。等しい優先度で構成されている論理チャネル同士は、等しく作動されてよい。
【００４６】
論理チャネル優先順位付けプロシージャの間、ＭＡＣエンティティは、Ｃ−ＲＮＴＩまたはＵＬ−ＣＣＣＨのデータ用のＭＡＣ制御要素、パディングに含まれるＢＳＲを除くＢＳＲ用のＭＡＣ制御要素、ＰＨＲ、拡張ＰＨＲ、またはデュアルコネクティビティＰＨＲ用のＭＡＣ制御要素、パディングに含まれるサイドリンクＢＳＲを除くサイドリンクＢＳＲ用のＭＡＣ制御要素、ＵＬ−ＣＣＣＨのデータを除く任意の論理チャネルのデータ、パディングに含まれるＢＳＲ用のＭＡＣ制御要素、パディングに含まれるサイドリンクＢＳＲ用のＭＡＣ制御要素などの相対的な優先度を高い順で考慮に入れてもよい。
【００４７】
ＭＡＣエンティティが１つのＴＴＩで複数のＭＡＣ  ＰＤＵを伝送することをリクエストされる場合、上述したステップ１から３および関連する規則は、独立して各グラントに、またはグラントの容量の合計に適用されてよい。また、グラントが処理される順序は、ＵＥの実装形態に委ねられる。ＭＡＣエンティティが１つのＴＴＩで複数のＭＡＣ  ＰＤＵを伝送するようにリクエストされる場合、どのＭＡＣ  ＰＤＵにＭＡＣ制御要素が含まれるかを決定することはＵＥの実装形態次第である。ＵＥが１つのＴＴＩで２つのＭＡＣエンティティにＭＡＣ  ＰＤＵを生成するようにリクエストされる場合、どの順番で、グラントが処理されるかはＵＥの実装形態次第である。
【００４８】
ＭＡＣエンティティは、上記に従って、ＭＡＣ  ＰＤＵにＭＡＣ制御要素およびＭＡＣ  ＳＤＵを多重化してよい。
【００４９】
ＭＡＣ多重化向けのＬＴＥ論理チャネル優先順位付けオペレーションの一例が、チャネル１、チャネル２、およびチャネル３の優先度の高い順で図１に示されている。図１を参照すると、チャネル１はそのＰＢＲまで、チャネル２はそのＰＢＲまで、次いで、チャネル３は、（この例では、利用可能なデータの量は、そのチャネルに構成されたＰＢＲによって許容されるものよりも少ないため）利用可能な限りの多くのデータを伴って作動される。次いで、ＭＡＣ  ＰＤＵ内の残りのスペースは、ＭＡＣ  ＰＤＵのスペース、またはチャネル１からのデータがなくなるまで、優先度の高いチャネル１からデータで埋められる。チャネル１が作動された後に、依然としてスペースがある場合、チャネル２は同じように作動される。
【００５０】
ビーム回復リクエスト（ＢＲＲ）は、ＮＲではＬ１信号として設計され、スケジュールベースではなくイベント駆動型であるので、ＢＲＲは、時間領域での伝送リソースおよび潜在的な衝突に関するＳＲおよびＨＡＲＱ  肯定応答（ＡＣＫ）／否定応答（ＮＡＣＫ）などの他のスケジュールされていない上りリンクＬ１信号と必然的に相互作用する。したがって、適切な設計ソリューションがこれらの問題を解決するために必要である。
【００５１】
ＬＴＥでは、スケジューリングリクエストシグナリングおよびプロシージャは、単一のユースケースＭＢＢ、無指向性伝送、および伝送のための２つの利用可能なチャネル（すなわち、ＰＵＣＣＨおよびＰＲＡＣＨ）に基づいて設計される。ＮＲでは、３のユースケース（ｅＭＢＢ、ＵＲＬＬＣ、ｍＭＴＣ）がサポートされ、ビームフォーミングが、制御およびデータチャネル伝送の両方のために使用され、グラントレス上りリンク伝送が同様に導入される。したがって、ＳＲに対する適切な設計ソリューションが、新しいユースケースをサポートし、かつ、ビームフォーミングおよびグラントレスＵＬ伝送を利用するのに必要とされる。
【００５２】
（２．５  論理チャネル優先順位付け）
新たな伝送が実施されるときに、論理チャネル優先順位付けプロシージャが、上りリンク伝送に適用される。
【００５３】
ＲＲＣは、優先度の値が大きいほど優先度のレベルが低い優先度、優先順位付けされたビットレート（ＰＢＲ）をセットするｐｒｉｏｒｉｔｉｓｅｄＢｉｔＲａｔｅ、バケットサイズ長（ＢＳＤ）をセットするｂｕｃｋｅｔＳｉｚｅＤｕｒａｔｉｏｎを各論理チャネルについてシグナリングすることによって、上りリンクデータのスケジューリングを制御する。ＮＢ−ＩｏＴに関しては、ｐｒｉｏｒｉｔｉｓｅｄＢｉｔＲａｔｅ、ｂｕｃｋｅｔＳｉｚｅＤｕｒａｔｉｏｎおよび論理チャネル優先順位付けプロシージャの対応するステップ（すなわち、以下のステップ１およびステップ２）は、適用できない。
【００５４】
ＭＡＣエンティティは、論理チャネルｊごとに変数Ｂｊを管理してもよい。Ｂｊは、関連する論理チャネルが確立されるときに０に初期化され、ＴＴＩごとに、ＰＢＲ×ＴＴＩ時間長の積によってインクリメントされてよいが、ここで、ＰＢＲは論理チャネルｊの優先順位付けされたビットレートである。ここでの着想は、論理チャネルが作動されるのを待ち行列で待っている間に、一定期間に論理チャネルごとにデータクレジットを蓄積することであり、この場合、その論理チャネルが、論理チャネル優先度順序に従って作動される順番になったときに、その論理チャネルから供給されるデータ量は、論理チャネルの優先順位付けされたビットレート要件を満たす。Ｂｊの値は、バケットサイズを超えることはできず、Ｂｊの値が論理チャネルｊのバケットサイズよりも大きい場合は、Ｂｊの値はバケットサイズに設定されることがある、という点に留意すべきである。論理チャネルのバケットサイズは、ＰＢＲ×ＢＳＤに等しく、ここで、ＰＢＲおよびＢＳＤは上位層によって構成される。
【００５５】
新たな伝送が実施されるときに、ＭＡＣエンティティは以下の論理チャネル優先順位付けプロシージャを実施して、論理チャネルにリソースを割り当ててもよい。ステップ１、Ｂｊ＞０を用いる論理チャネルすべてに、優先度の高い順でリソースを割り当てる。論理チャネルのＰＢＲが「無限大」に設定されている場合、ＭＡＣエンティティは、その論理チャネルで伝送可能なデータのすべてにリソースを割り当てた後に、より低い優先度の論理チャネルのＰＢＲを満たしてもよい。
【００５６】
ステップ２では、ＭＡＣエンティティは、ステップ１で論理チャネルｊで供給されたＭＡＣ  ＳＤＵの合計サイズだけＢｊをデクレメントしてもよく、Ｂｊの値は、負になることもある。
【００５７】
ステップ３では、リソースが残っている場合、その論理チャネルのデータまたはＵＬグラントのどちらかが先に使い果たされるまで、すべての論理チャネルは厳密に優先度の高い順で（Ｂｊの値に関係なく）作動されてよい。等しい優先度で構成されている論理チャネル同士は、等しく作動される必要がある。
【００５８】
論理チャネル優先順位付けプロシージャに関しては、ＭＡＣエンティティは、Ｃ−ＲＮＴＩまたはＵＬ−ＣＣＣＨのデータ用のＭＡＣ制御要素、パディングに含まれるＢＳＲを除くＢＳＲ用のＭＡＣ制御要素、ＰＨＲ、拡張ＰＨＲ、またはデュアルコネクティビティＰＨＲ用のＭＡＣ制御要素、パディングに含まれるサイドリンクＢＳＲを除くサイドリンクＢＳＲ用のＭＡＣ制御要素、ＵＬ−ＣＣＣＨのデータを除く任意の論理チャネルのデータ、パディングに含まれるＢＳＲ用のＭＡＣ制御要素、パディングに含まれるサイドリンクＢＳＲ用のＭＡＣ制御要素などの相対的な優先度を高い順で考慮に入れてもよい。
【００５９】
ＭＡＣエンティティが１つのＴＴＩで複数のＭＡＣ  ＰＤＵを伝送することをリクエストされる場合、ステップ１から３および関連する規則は、各グラントに独立して、またはグラントの容量の合計に適用されてよい。また、グラントが処理される順序は、ＵＥの実装形態に委ねられる。ＭＡＣエンティティが１つのＴＴＩで複数のＭＡＣ  ＰＤＵを伝送するようにリクエストされる場合、どのＭＡＣ  ＰＤＵにＭＡＣ制御要素が含まれるかを決定することはＵＥの実装形態次第である。ＵＥが１つのＴＴＩで２つのＭＡＣエンティティにＭＡＣ  ＰＤＵを生成するようにリクエストされる場合、どの順番で、グラントが処理されるかはＵＥの実装形態次第である。
【００６０】
ＭＡＣエンティティは、上記に従って、ＭＡＣ  ＰＤＵにＭＡＣ制御要素およびＭＡＣ  ＳＤＵを多重化してよい。
【００６１】
ＭＡＣ多重化向けのＬＴＥ論理チャネル優先順位付けオペレーションの一例が、チャネル１、チャネル２、およびチャネル３の優先度の高い順で、図１に示されている。
【００６２】
まずチャネル１はそのＰＢＲまで、チャネル２はそのＰＢＲまで、次いで、チャネル３は、（この例では、利用可能なデータの量は、このチャネルに構成されたＰＢＲによって許容されるものよりも少ないので）利用可能な限り多くのデータを伴って作動される。その後、ＭＡＣ  ＰＤＵ内の残りのスペースは、ＭＡＣ  ＰＤＵのスペースまたはチャネル１からのデータがそれ以上なくなるまで、優先度の高いチャネル１からデータで埋められる。チャネル１が作動された後に、依然としてスペースがある場合、チャネル２は同じように作動される。
【００６３】
（３  課題の例  課題１）
第１の課題は、ビーム回復リクエスト（ＢＲＲ）が、ＮＲにおけるＬ１信号として実装されるがゆえに、スケジュールベースではなくイベント駆動型である場合に、ＢＲＲは、時間領域での伝送リソースおよび潜在的な衝突の両方に関するＳＲおよびＨＡＲＱ  ＡＣＫ／ＮＡＣＫなどの、他のスケジュールされていない上りリンクＬ１信号と必然的に相互作用することである。
【００６４】
（課題２）
第２の課題は、ＬＴＥでは、スケジューリングリクエストシグナリングおよびプロシージャは、単一のユースケースＭＢＢ、無指向性伝送、および伝送のための２つの利用可能なチャネル（すなわち、ＰＵＣＣＨおよびＰＲＡＣＨ）に基づいて設計されていることである。ＮＲでは、３のユースケース（ＥＭＢＢ、ＵＲＬＬＣ、ｍＭＴＣ）がサポートされ、かつビームフォーミングが、制御およびデータチャネル伝送の両方のために使用され、グラントレス上りリンク伝送が同様に導入される。
【００６５】
ＮＲでは、ＵＥが複数のニューメロロジーをサポートするので、各伝送機会間の固定時間長の時間間隔として、伝送時間間隔（ＴＴＩ）のコンセプトが、置き換えられるかまたは再定義される可能性がある。これらニューメロロジーのそれぞれは、異なるサブキャリア間隔、したがって、異なるシンボル長、スロット長、およびミニスロット長によって特徴付けられる可能性がある。ＮＲにおいて対処される必要がある重要な問題は、ＬＴＥと類似のＴＴＩコンセプトがないために、時間の経過とともに変数Ｂｊをどう管理するかである。
【００６６】
別のＬＣＰ関連の問題は、論理チャネルの許容されるレイテンシ要件を満たさないＵＬリソースグラントを使用することによる論理チャネル制約の問題である。ＵＬリソースグラントが論理チャネルの許容されるレイテンシ要件を満たすときのみに、論理チャネルがＵＬリソースグラントを使用できるようにする必要性がある。
【００６７】
スケジューリングリクエスト（ＳＲ）に関しては、ＲＡＮ２でいくつかの取り決めが行われた。
【００６８】
セルごとに、常にＬＣＨごとに多くても１つの使用可能なＰＵＣＣＨリソースがあるという制約を伴う異なる各帯域幅パート（Bandwidth  Part：ＢＷＰ）および各セルにわたる、ＰＵＣＣＨリソースのセットの集合で、ＳＲ構成が構成される。これは、ＢＷＰごとのＬＣＨごとに、１つのＬＴＥと類似のＳＲ  ＰＵＣＣＨリソースのセットが構成され、一度に１つのＢＷＰのみがアクティブになる場合に相当する。
【００６９】
各ＬＣＨは、どのＳＲ構成にもマップされないか、１つのＳＲ構成にマップされる。
【００７０】
各ＳＲ構成は、それ自体固有のＳＲカウンタおよび禁止タイマを有する。このカウンタおよびタイマは、ＳＲ構成（すなわち、問題となっているＳＲ構成にマップされているＬＣＨのグループでのＳＲプロシージャ）を制御する。ＳＲ伝送カウンタがＳＲ構成に対して最大値に達すると、ＳＲ障害が宣言されて、ＵＥはＲＡＣＨをトリガして、すべてのＰＵＣＣＨリソースを解放する。ＳＲカウンタおよびタイマは、異なる全構成に実装される。
【００７１】
ＢＷＰ切り替え、およびセルのアクティブ化／非アクティブ化は、カウンタおよびタイマの動作を妨げない。
【００７２】
上記の取り決めに従って、ＳＲ伝送カウンタがＳＲ構成に対して最大値に達すると、ＳＲ障害が宣言されて、ＵＥはＲＡＣＨをトリガして、すべてのＰＵＣＣＨリソースを解放する。潜在的にＳＲペンディングを伴う他のＰＵＣＣＨリソースがある場合であっても、ＵＥは、この動作をとってもよい。このような場合、元のリソースでのＳＲ障害をネットワークに通知する必要がある。さらに、すべてのＰＵＣＣＨリソースの解放およびＲＡＣＨプロシージャの開始の動作は、高コストの操作である。したがって、この対策を最終手段の選択肢として使用することは重要であり、そのため、いつ他のＳＲリソースが使用可能になるかの基準を含む追加の方法が考慮される場合がある。
【００７３】
（課題３）
第３の課題は、ＮＲでは、ＵＥが複数のニューメロロジー（ニューメロロジーのそれぞれは、異なるサブキャリア間隔、したがって、異なるシンボル長、スロット長、およびミニスロット長によって特徴付けられている）をサポートするので、各伝送機会間の固定時間長の時間間隔として、伝送時間間隔（ＴＴＩ）のコンセプトが、置き換えられるかまたは再定義されることになることである。
【００７４】
ＮＲにおいて対処される必要がある重要な問題は、ＬＴＥと類似のＴＴＩコンセプトがないために、時間の経過とともに変数Ｂｊをどう管理するかである。
【００７５】
論理チャネル優先順位付け（ＬＣＰ）関連問題は、論理チャネルの許容されるレイテンシ要件または同等の規定を満たさないＵＬリソースグラントを使用することによる論理チャネル制約の問題であり、どのように、ＵＬリソースグラントが論理チャネルの許容されるレイテンシ要件を満たすときのみに、論理チャネルがＵＬリソースグラントを使用できるようにするかである。
【００７６】
（課題４）
第４の課題は、セルごとに、常にＬＣＨごとに多くても１つの使用可能なＰＵＣＣＨリソースがある異なる各ＢＷＰおよび各セルにわたる、ＰＵＣＣＨリソースのセットの集合で、ＳＲ構成が構成される場合があることである。これは、ＢＷＰごとのＬＣＨごとに、１つのＬＴＥと類似のＳＲ  ＰＵＣＣＨリソースのセットが構成され、一度に１つのＢＷＰのみがアクティブになる場合に相当する。各ＬＣＨは、どのＳＲ構成にもマップされないか、１つのＳＲ構成にマップされることがある。
【００７７】
各ＳＲ構成は、それ自体固有のＳＲカウンタおよび禁止タイマを有している場合がある。このカウンタおよびタイマは、ＳＲ構成（すなわち、問題となっているＳＲ構成にマップされているＬＣＨのグループでのＳＲプロシージャ）を制御する。ＳＲ伝送カウンタがＳＲ構成に対して最大値に達すると、ＳＲ障害が宣言されて、ＵＥはＲＡＣＨをトリガして、すべてのＰＵＣＣＨリソースを解放する。ＳＲカウンタおよびタイマは、異なる全構成において独立している。
【００７８】
ＢＷＰ切替、およびセルのアクティブ化／非アクティブ化は、カウンタおよびタイマの動作を妨げてはならないことを、ＲＡＮ２で取り決められた。
【００７９】
ＲＡＮ２ごとに、ＳＲ伝送カウンタがＳＲ構成に対して最大値に達すると、ＳＲ障害が宣言されて、ＵＥはＲＡＣＨをトリガして、すべてのＰＵＣＣＨリソースを解放する。潜在的にＳＲペンディングを伴う他のＰＵＣＣＨリソースがある場合であっても、ＵＥは、この動作をとってもよい。このような場合、元のリソースでのＳＲ障害をネットワークに通知する必要がある。さらに、すべてのＰＵＣＣＨリソースの解放およびＲＡＣＨプロシージャの開始の動作は、高コストの操作である。
【００８０】
（課題５）
第５の課題は、ＬＴＥにおいて、3GPP  TS  36.321  E-UTRA  Medium  Access  Control  (MAC)  protocol  specification,  V15.0.0で、スケジューリングリクエスト（ＳＲ）のトリガについて、少なくとも１つのＢＳＲがトリガされたが、キャンセルはされていないと、バッファ状態報告プロシージャで判断し、かつＭＡＣエンティティが、現在のＴＴＩでの新しい伝送に割り当てられるＵＬリソースを有している場合、多重化および組み立てプロシージャを命令して、ＢＳＲ  ＭＡＣ制御要素を生成し、すべての生成されたＢＳＲが短縮ＢＳＲである場合を除き、ｐｅｒｉｏｄｉｃＢＳＲ−Ｔｉｍｅｒを開始または再開し、かつｒｅｔｘＢＳＲ−Ｔｉｍｅｒを開始または再開することが明記されている。少なくとも１つのＢＳＲがトリガされていない、またはキャンセルされたとバッファ状態報告プロシージャで判断する場合、次いで、規則的なＢＳＲがトリガされたが、ｌｏｇｉｃａｌＣｈａｎｎｅｌＳＲ−ＰｒｏｈｉｂｉｔＴｉｍｅｒが動作していない場合、上りリンクグラントが構成されていないか、または論理チャネルＳＲマスキング（ｌｏｇｉｃａｌＣｈａｎｎｅｌＳＲ−Ｍａｓｋ）が上位層によって設定されている論理チャネルでの伝送のために、データが利用可能になることに起因して規則的なＢＳＲがトリガされなかった場合、スケジューリングリクエストはトリガされる場合がある。
【００８１】
ＳＲのトリガに関するＮＲのテキストは、少なくとも１つのＢＳＲがトリガされたが、キャンセルはされておらず、かつＵＬ−ＳＣＨリソースが、新しい次の伝送のために利用可能であると、バッファ状態報告プロシージャで判断する場合、ＭＡＣエンティティは、多重化および組み立てプロシージャを命令して、ＢＳＲ  ＭＡＣ  ＣＥを生成し、すべての生成されたＢＳＲが長いまたは短い短縮ＢＳＲである場合を除き、ｐｅｒｉｏｄｉｃＢＳＲ−Ｔｉｍｅｒを開始または再開し、かつｒｅｔｘＢＳＲ−Ｔｉｍｅｒを開始または再開する場合があることを明記している、3GPP  TS  38.321  NR  Medium  Access  Control  (MAC)  protocol  specification,  V15.0.0で、記載されている。少なくとも１つのＢＳＲがトリガされていないか、またはキャンセルされたとバッファ状態報告プロシージャで判断し、かつ規則的なＢＳＲがトリガされたが、ｌｏｇｉｃａｌＣｈａｎｎｅｌＳＲ−ＤｅｌａｙＴｉｍｅｒが動作していない場合、上りリンクグラントが構成されたグラントではなく、かつ論理チャネルＳＲマスキング（ｌｏｇｉｃａｌＣｈａｎｎｅｌＳＲ−Ｍａｓｋ）が上位層によって設定されている論理チャネルで規則的なＢＳＲがトリガされなかった場合、ＭＡＣエンティティは、スケジューリングリクエストをトリガしてもよい。
【００８２】
ｌｏｇｉｃａｌＣｈａｎｎｅｌＳＲ−ＤｅｌａｙＴｉｍｅｒは、ｌｏｇｉｃａｌＣｈａｎｎｅｌＳＲ−Ｄｅｌａｙによって可能になった論理チャネルでのＳＲの伝送を遅らせるために使用される。ＴＲＵＥまたはｌｏｇｉｃａｌＣｈａｎｎｅｌＳＲ−Ｄｅｌａｙでサポートされた値は、論理チャネルに対してｌｏｇｉｃａｌＣｈａｎｎｅｌＳＲ−ＤｅｌａｙＴｉｍｅｒが有効にされた／サポートされたことを示す。ｌｏｇｉｃａｌＣｈａｎｎｅｌＳＲ−ＤｅｌａｙＴｉｍｅｒが設定される場合、ＮＲでは、フィールド（すなわち、ＴＲＵＥ値を示す）を（任意選択で）構成するだけである。本明細書で定義されるｌｏｇｉｃａｌＣｈａｎｎｅｌＳＲ−Ｄｅｌａｙは、3GPP  TS  38.331  NR  Radio  Resource  Control  (RRC)  protocol  specification,  V15.0.0で定義されている、ｌｏｇｉｃａｌＣｈａｎｎｅｌＳＲ−ＤｅｌａｙＴｉｍｅｒＡｐｐｌｉｅｄと同じであるという点に留意すべきである。
【００８３】
概略において、現在のＳＲトリガ仕様は、下記のように要約することができる。ＬＴＥのケースでは、少なくとも１つのＢＳＲがトリガされたが、キャンセルはされていないＴＴＩで、利用可能なＵＬグラントがない場合、ＳＲをトリガすることがあり、ＮＲのケースでは、少なくとも１つのＢＳＲがトリガされたが、キャンセルはされておらず、新しい次の伝送のために利用可能なＵＬ−ＳＣＨリソースがない場合に、ＳＲをトリガすることがある。しかし、ＳＲのトリガが適切でない可能性のある状況も存在する。一例としては、図２に示したものである。
【００８４】
図２に示すように、ＢＳＲはトリガされたが、キャンセルされてなく、その一方で、受信されたグラントが存在するが、グラントリソースはまだ利用可能ではない。現在の仕様に従って、このような場合にＳＲは伝送される。例えば、図２に示すようなレイテンシ要件次第で、図２に示す例のようなＳＲを即座にトリガすることは、リソースおよびＵＥ処理の無駄である。図２の例では、論理チャネルＬＣＨ２のデータは、ニューメロロジー１のリソースグラントを使用して伝送されないであろうと想定することができる。しかし、論理チャネルＬＣＨ２のデータも、ニューメロロジー１のリソースグラントを使用する可能性があると想定する場合、ＬＣＨ２のデータを伝送するため、およびＵＬリソースグラント１を使用してＬＣＨ２のデータが伝送される場合であっても、ＢＳＲも依然として伝送される必要があるので、ＢＳＲを伝送するためにも、ＵＬリソースグラント１は、使用される可能性があり、これは、このリソースグラントが論理チャネルＬＣＨ１バッファおよびＬＣＨ２バッファの両方で利用可能なすべてのデータを伝送するのに十分でない可能性があるか、または新しいデータの到着が新しいＢＳＲをトリガした可能性もあるためである。また、図３に示すようなケースの場合、既にトリガされたＢＳＲがキャンセルはされていないが、ＢＳＲを伝送するＵＬリソースグラントがないときに、ＳＲを即座にトリガすることは、リソースおよびＵＥ処理の無駄になる。さらに、ＳＲを送信するＰＵＣＣＨリソースが不足しているか、またはＳＲ伝送が、再伝送の許容最大数に達することにより、ランダムアクセスが開始される場合、グラントがＵＥにとって利用可能になる。例えば、既にＵＥに割り当てられているグラントがＵＬ伝送のために利用可能になる場合、ＲＡＣＨプロシージャのトリガまたはキャンセルのための基準が規定される必要がある。
【００８５】
ＳＲに関連する別の未解決の問題は、複数のペンディングＳＲがある場合の例である。この場合、対処すべき問題は、ＳＲ構成およびＰＵＣＣＨリソースが、ＳＲの伝送のために使用される必要があることである。
【００８６】
（課題６）
第６の課題は、ＮＲでは、複数のグラントが重複する状況があることである。図４から８にいくつかの例を示す。これらの例では、ＭＡＣ  ＰＤＵが伝送される位置での、各グラントに対するバッファ状態計算のメカニズムは、適切に設計される必要がある。
【００８７】
（ビーム回復へのアプローチ）
（ＵＬビームのみが失敗した場合のビーム障害回復プロシージャ）
ＵＬビームは失敗したが、ＤＬビームがまだ機能している場合、ＵＬ  ＲＳ（例えば、ＳＲＳおよび／またはＤＭ−ＲＳ）を処理することによって、ｇＮＢはＵＬサービングビームおよび候補ビームのビーム品質をモニタしてもよい。サービングビームのビーム品質が予め規定される閾値を下回るか、またはＫｄＢが他のビームのビーム品質よりも悪い場合に、ｇＮＢは、下記のようにＵＬビーム障害回復プロシージャを開始してもよい。
【００８８】
ｇＮＢがＵＬ候補ビーム品質を認識している場合、ｇＮＢは、ＵＥに下りリンクでＵＬビーム切り替えコマンドを送信してもよい。上りリンクビーム切り替えコマンドは、ビームＩＤ、または（全方向ビームＩＤに比べて短く、かつＵＥとｇＮＢとのペアに認識されている）ビームタグＩＤを表すＭビットの形式でシグナリングされてもよい。ＵＬビーム切り替えコマンドは、新しいＤＣＩフォーマットで、他の既存のＮＲ−物理下りリンク制御チャネル（Physical  Downlink  Control  Channel：ＰＤＣＣＨ）フォーマット（例えば、ＵＬまたはＤＬグラント）で、再利用ＮＲ−ＰＤＣＣＨフォーマットで、または（ＮＲ−物理下りリンク共有データチャネル（Physical  Downlink  Shared  Data  Channel：ＰＤＳＣＨ）内の）ＭＡＣ  ＣＥで搬送されてもよい。ＵＬビーム切り替えコマンドが、後続の多くのサブフレームでのＵＬ伝送に影響する可能性があるので、高い信頼性を伴って設計される必要がある。ＮＲ−ＰＤＳＣＨのＭＡＣ  ＣＥでのＵＬビーム切り替えコマンドのシグナリングは、ＵＥからのＡＣＫ／ＮＡＣＫフィードバックの利点がある。ＵＬビーム切り替えコマンドが、再利用ＤＣＩフォーマットを使用して（すなわち、有効な上りリンクスケジューリンググラントなしのＤＣＩフォーマット０を使用して）、シグナリングされる場合、検出の信頼性を向上するために、例えば、ＨＡＲＱ処理ＩＤ、ＭＣＳレベル、ＴＰＣコマンド、冗長性、ＤＭＲＳサイクリックシフトなどのいくつかのフィールドが、「０」または「１」に設定されてよい（「バーチャルＣＲＣ」として作動する）。ＵＬビーム切り替えコマンドが、新しいＤＣＩフォーマットを使用してシグナリングされる場合、ＵＬビーム切り替えコマンドの信頼性を向上するために、強いＰｏｌａｒ符号化が適用されるか、または時間領域および／または周波数領域拡散コード／シーケンスが適用される必要がある。
【００８９】
ｇＮＢがＵＬ候補ビーム品質を認識していない場合、ｇＮＢは、ＵＥに下りリンクで非周期的（または周期的）ＵＬビームトレーニングコマンドを送ることによって、ＵＬビームトレーニングプロシージャを開始してもよい。上りリンクビームトレーニングコマンドは、（ＳＲＳサイクリックシフト、ポートに関する）ＳＲＳリソースの形式およびＳＲＳを伝送する上りリンクビームのサブセットでシグナリングされてもよい。ＵＬビームトレーニングコマンドは、新しいＤＣＩフォーマットで、他の既存のＮＲ−ＰＤＣＣＨフォーマット（例えば、ＵＬまたはＤＬグラント）で、再利用ＮＲ−ＰＤＣＣＨフォーマットで、または（ＮＲ−ＰＤＳＣＨ内の）ＭＡＣ  ＣＥで搬送されてもよい。ＵＬビームトレーニングコマンドを受信するとすぐに、ＵＥは、ｇＮＢからの有効なＵＬビーム切り替えコマンドの受信に成功するまで、いずれのペンディングＳＲＳの伝送も中断してよい。ＵＥはまた、先にスケジュールされるか、構成された他の上りリンク伝送（半永続的スケジュール済みＰＵＳＣＨ、ＣＳＩフィードバック、クロススケジュール済みＮＲ−ＰＵＳＣＨ、ＳＲＳ伝送など）を中断することを必要としてもよい。
【００９０】
（ＤＬビーム障害の場合のビーム回復リクエストプロシージャ）
ＤＬビーム障害の場合、ＵＥは、現在のサービングＤＬビームを使用するＤＬ信号を受信できない。ＵＬビームが失敗するときのみに使用されるｇＮＢ始動のビーム障害回復スキームは、この場合は使用されないかもしれない。むしろ、ＤＬビームが失敗すると、ＵＥは、まず、ＵＬでｇＮＢにビーム回復リクエストなどのビーム障害回復信号を送り、次いで、ＤＬビームのみが失敗した場合は、ＤＬビームを再構築するか、または、ｇＮＢとＵＥとの間でＵＬおよびＤＬビームの両方が失敗した場合は、ＵＬおよびＤＬビームを再構築する必要がある。
【００９１】
ＵＬおよびＤＬビームメンテナンスプロシージャが、周期的または非周期的ビームトレーニングを使用し、周期的または非周期的ＵＬおよびＤＬビーム報告を生成することが有利である。使用される特定のビームメンテナンススキームに応じて、ＴＴＩで、ＵＥおよび／またはｇＮＢに、候補ビーム情報が認識されても、認識されなくても（または無効にされても）よい。
【００９２】
（ビーム障害回復プロシージャの基本的な原理）
本発明者らは、概して、ビーム障害回復プロシージャにおける以下の５つの原理に注目することが有利であることに注目する。
【００９３】
第１に、各ＢＰＬのマルチコネクティビティまたはＣｏＭＰのケースでは、個別のビーム障害回復プロシージャを作動させることがより良好な場合がある。
【００９４】
第２に、ＵＬビームが失敗しない（しかし、ＤＬビームは失敗する）場合は、ＵＥは、ＢＲＲのために構成されたＰＵＣＣＨでＢＲＲを伝送することができる。ＢＲＲのために構成されたＰＵＣＣＨはないが、専用ＰＲＡＣＨリソースがＢＲＲのために構成される場合、ＵＥは構成された専用ＰＲＡＣＨでＢＲＲを伝送する。そうでない場合は、ＢＲＲのために構成された（特定のＵＥ向けに確保されていない）ＰＲＡＣＨリソースプールでＢＲＲを伝送する。
【００９５】
第３に、ＵＬビームが失敗する場合、ＵＥは、ＢＲＲのために構成されたＰＵＣＣＨでＢＲＲを伝送できない場合がある。専用ＰＲＡＣＨリソースがＢＲＲのために構成される場合、ＵＥは構成された専用ＰＲＡＣＨでＢＲＲを伝送し、そうでない場合は、ＢＲＲのために構成された（特定のＵＥ向けに確保されていない）ＰＲＡＣＨリソースプールでＢＲＲを伝送する。
【００９６】
第４に、ＵＬビームが失敗し、ＵＥがＰＲＡＣＨでＢＲＲを伝送する必要がある場合、ＵＥはＰＲＡＣＨでビームスイーピングを実施することができる。ＵＬ候補ビームが、ビームメンテナンスプロシージャおよびシグナリングを介してＵＥに認識される場合、ＵＥは、まずこれらの候補ビームをスイープしてもよく、かつ、ビームスイーピングの順番は、候補ビームのビーム品質の高い順でアレンジされてよい。あるいは、失敗したビームと空間的ＱＣＬ関係を有する候補ビームが、ビーム品質の順番の適用の前に、最初にスイープされてもよい。
【００９７】
第５に、ＵＬビームが失敗し、ＵＥがＰＲＡＣＨでＢＲＲを伝送する必要がある場合、ＵＥはＰＲＡＣＨでビームスイーピングを実施することができる。ＵＬ候補ビームが、ビームメンテナンスプロシージャおよびシグナリングを介してＵＥに認識されない場合、ＵＥは、全ビームまたはビームのサブセットをスイープする必要があり、ビームスイーピングの順番は、失敗したビームと空間的ＱＣＬ関係を有するビームが最初にスイープされ、次に他のビームがスイープされる順番でアレンジされてもよい。
【００９８】
（ビーム障害回復早期終了基準）
ＵＥは、Ｌ３測定、または長期測定を利用して、ビーム障害回復が実施されるべきかどうか、または、上位層へ同期していないことをすぐに宣言すべきかどうかを判断する。
【００９９】
例えば、このようなＬ３測定は、（複数のビームにわたって測定される）セルまたはＴＲｘＰのＬ３  ＲＳＲＰ測定であってもよい。現在のサービングセル／ＴＲｘＰのＬ３セル品質測定が、予め定められた閾値を下回るか、他のセル／ＴＲｘＰのＬ３セル品質測定値よりも悪いＫＢＦ  ｄＢである場合、ＵＥは、現在のサービングセルが、他の良好な候補ビームを有していないと判断して、その結果、ビーム障害回復をスキップすることを選択してもよい。
【０１００】
あるいは、例えば、このようなＬ３測定は、現在のサービングビームのＬ３  ＲＳＲＰ測定であってもよい。他のビームのＬ３  ＲＳＲＰ測定が、サービングビームのＬ３  ＲＳＲＰ測定より悪いか、または、サービングビームよりも良好ではあるが、許容可能なチャネル品質に対応する予め定められた閾値より低い場合、ＵＥは、現在のサービングセルが、他の良好な候補ビームを有していないと判断して、ビーム障害回復をスキップすることを選択してもよい。
【０１０１】
（ビーム障害回復プロシージャ）
ビーム障害回復は、様々な方法で実現することができる。例えば、ビーム回復リクエスト（ＢＲＲ）は、ＴｘとＲｘとのビームリンクペア間のビーム障害回復を開始するために使用されてよい。ビーム障害回復基準が、特定のビームペアリンク（ＢＰＬ）ｉに対して満たされると、ＢＲＲが、そのＢＰＬのためにトリガされてよい。
【０１０２】
ＢＲＲがトリガされるときに、ＢＲＲはキャンセルされるまでペンディングとして見なされてもよい。ＢＰＬｉ向けのすべてのペンディングＢＲＲはキャンセルされてよく、有効なビームリカバリー応答の受信が成功する場合、ｂｒｒ−ＲｅｓｐｏｎｓｅＷｉｎｄｏｗＴｉｍｅｒは停止されてよい。
【０１０３】
任意で、ＵＥは、（上述の）ビーム障害回復早期終了基準を評価してもよい。早期ビーム回復基準が満たされる（利用可能なより良いビームがない）場合、ＵＥは次のビーム回復プロシージャをスキップし、上位層に同期外れを宣言する。そうでない場合は、ＵＥは下記のステップへ進んでもよい。
【０１０４】
ＢＲＲがＢＰＬｉのためにトリガされ、かつペンディングされている他のＢＲＲがない場合、ＭＡＣエンティティは、ＢＬＰｉ用のＢＲＲ＿ＣＯＵＮＴＥＲを０にセットしてもよい。
【０１０５】
少なくとも１つのＢＲＲがＢＰＬｉのためにペンディングされている場合、ＭＡＣエンティティは、ＴＴＩごとに処理を実施してもよい。ＵＥが、それ自体のＵＬビーム品質が依然として通信のために許容可能であると認識しており、かつ、ＭＡＣエンティティが、現在のＴＴＩの間に構成されるＢＲＲのための少なくとも１つの有効なＮＲ−ＰＵＣＣＨリソース、または現在のＴＴＩの間にスケジュールされるＮＲ−ＰＵＳＣＨを有するか、あるいは、現在のＴＴＩの間に構成されるＢＲＲのための少なくとも１つの有効な専用ＮＲ−ＰＲＡＣＨリソースを有し、かつ、現在のＴＴＩが、伝送のための測定ギャップまたはサイドリンク発見ギャップの一部ではない場合、また、ｂｒｒ−ＲｅｓｐｏｎｓｅＷｉｎｄｏｗＴｉｍｅｒが動作していない場合、処理は、ＢＬＰｉ用のＢＲＲ＿ＣＯＵＮＴＥＲに依存してもよい。
【０１０６】
ＢＬＰｉ用のＢＲＲ＿ＣＯＵＮＴＥＲが、ｄｂｒｒ−ＴｒａｎｓＭａｘより小さい場合、ＵＥは、ＢＬＰｉ用のＢＲＲ＿ＣＯＵＮＴＥＲを１だけインクリメントし、物理層に命令して、ＢＲＲのための１つの有効なＰＵＣＣＨリソースでＢＲＲをシグナリングするか、またはＢＲＲのために構成された１つの有効な専用ＰＲＡＣリソースでＢＲＲを伝送するか、あるいは、スケジュール済みＮＲ−ＰＵＳＣＨでＢＲＲをピギーバックし、かつ、ｂｒｒ−ＲｅｓｐｏｎｓｅＷｉｎｄｏｗＴｉｍｅｒを開始してもよい。
【０１０７】
ＢＬＰｉ用のＢＲＲ＿ＣＯＵＮＴＥＲが、ｄｂｒｒ−ＴｒａｎｓＭａｘより大きい場合、ＵＥはＲＲＣに通知して、すべてのサービングセルのＢＰＬｉのＢＲＲのために構成されたＰＵＣＣＨまたは専用ＰＲＡＣＨリソースを解放し、ＲＲＣに通知して、すべてのサービングセルのＢＰＬｉのＳＲＳを解放し、いずれの構成された下りリンク割り当ておよび上りリンクグラントもクリアし、ＳｐＣｅｌｌでのランダムアクセスプロシージャを開始して、すべてのペンディングＢＲＲをキャンセルし、かつ、ビーム障害回復が失敗したことを上位層に通知し、同期外れを宣言してもよい。
【０１０８】
ＭＡＣエンティティが、いずれのＴＴＩ内に構成されるＢＲＲのための有効なＮＲ−ＰＵＣＣＨリソースも、いずれのＴＴＩ内に構成されるＢＲＲのための有効な専用ＮＲ−ＰＲＡＣＨリソースも、いずれのＴＴＩ内にスケジュールされたＮＲ−ＰＵＳＣＨも有していないが、現在のＴＴＩの間に少なくとも１つのグラントフリーＮＲ−ＰＵＳＣＨ伝送機会を有している場合、次いで、現在のＴＴＩが、伝送のための測定ギャップまたはサイドリンク発見ギャップの一部でない場合、また、ｂｒｒ−ＲｅｓｐｏｎｓｅＷｉｎｄｏｗＴｉｍｅｒが動作していない場合、処理はＢＲＲ＿ＣＯＵＮＴＥＲに従って進行してもよい。
【０１０９】
ＢＬＰｉ用のＢＲＲ＿ＣＯＵＮＴＥＲが、ｓｂｒｒ−ＴｒａｎｓＭａｘより小さい場合、ＵＥはＢＬＰｉ用のＢＲＲ＿ＣＯＵＮＴＥＲを１だけインクリメントし、物理層に命令して、（ＵＥによって伝送されるユーザデータが１つもない場合）利用可能なグラントフリーＮＲ−ＰＵＳＣＨでＢＲＲをシグナリングするか、または、（ＵＥによってこのグラントフリーＮＲ−ＰＵＳＣＨで伝送されるユーザデータがない場合）グラントフリーＮＲ−ＰＵＳＣＨでＢＲＲをピギーバックし、かつ、ｂｒｒ−ＲｅｓｐｏｎｓｅＷｉｎｄｏｗＴｉｍｅｒを開始してもよい。
【０１１０】
ＢＬＰｉ用のＢＲＲ＿ＣＯＵＮＴＥＲが、ｓｂｒｒ−ＴｒａｎｓＭａｘより大きい場合、ＵＥは、ＲＲＣに通知して、すべてのサービングセルのＢＰＬｉのＳＲＳを解放し、いずれの構成された下りリンク割り当ておよび上りリンクグラントもクリアし、ＳｐＣｅｌｌでのランダムアクセスプロシージャを開始して、すべてのペンディングＢＲＲをキャンセルし、かつ、ビーム障害回復が失敗したことを上位層に通知し、同期外れを宣言してもよい。
【０１１１】
ＭＡＣエンティティが、いずれのＴＴＩ内に構成されるＢＰＬｉのＢＲＲのための有効なＮＲ−ＰＵＣＣＨリソースまたは有効な専用ＮＲ−ＰＲＡＣＨリソースも、いずれのＴＴＩ内にスケジュールされたＮＲ−ＰＵＳＣＨも、いずれのＴＴＩ内のグラントフリーＮＲ−ＰＵＳＣＨ伝送機会も有していない場合、かつ、「ランダムアクセスをスキップすること」が構成されていない場合、ＳｐＣｅｌｌでのＢＰＬｉのＢＲＲのために構成される（専用ではない）ＰＲＡＣＨリソースを使用するランダムアクセスプロシージャを開始して、ＢＰＬｉのすべてのペンディングＢＲＲをキャンセルする。
【０１１２】
ＵＥが、それ自体のＵＬビーム品質がもはや許容可能ではないと認識する（例えば、ＵＬビームがＤＬビームと逆であるか、または、ｇＮＢ  ＤＬシグナリングまたはＵＥ自己検出を介して認識する）場合、ＵＥは、ＢＲＲ伝送のために構成されたＰＵＣＣＨリソースでＢＲＲを伝送しなくてもよい。ＵＥがどのように進行するかは、専用ＮＲ−ＰＲＡＣＨリソースを有しているかどうかによって決められてよい。
【０１１３】
ＭＡＣエンティティが、現在のＴＴＩの間に構成されるＢＲＲのための少なくとも１つの有効な専用ＮＲ−ＰＲＡＣリソースを有している場合、かつ、現在のＴＴＩが、伝送のための測定ギャップまたはサイドリンク発見ギャップの一部ではない場合、また、ｂｒｒ−ＲｅｓｐｏｎｓｅＷｉｎｄｏｗＴｉｍｅｒが動作していない場合、処理は、ＢＬＰｉ用のＢＲＲ＿ＣＯＵＮＴＥＲに依存してもよい。
【０１１４】
ＢＬＰｉ用のＢＲＲ＿ＣＯＵＮＴＥＲが、ｄｂｒｒ−ＴｒａｎｓＭａｘより小さい場合、ＵＥはＢＬＰｉ用のＢＲＲ＿ＣＯＵＮＴＥＲを１だけインクリメントし、物理層に命令して、ＵＬビームスイーピングを用いて、ＢＲＲのために構成された１つの専用ＰＲＡＣＨリソースでＢＲＲをシグナリングし、かつ、ｂｒｒ−ＲｅｓｐｏｎｓｅＷｉｎｄｏｗＴｉｍｅｒを開始してもよい。
【０１１５】
ＢＬＰｉ用のＢＲＲ＿ＣＯＵＮＴＥＲが、ｄｂｒｒ−ＴｒａｎｓＭａｘより大きい場合、ＵＥは、ＲＲＣに通知して、すべてのサービングセルのＢＰＬｉのＢＲＲのために構成されたＮＲ−ＰＵＣＣＨおよび専用ＰＲＡＣＨリソースを解放し、ＲＲＣに通知して、すべてのサービングセルのＢＰＬｉのＳＲＳを解放し、いずれの構成された下りリンク割り当ておよび上りリンクグラントもクリアし、ＳｐＣｅｌｌでのランダムアクセスプロシージャを開始して、すべてのペンディングＢＲＲをキャンセルし、かつ、ビーム障害回復が失敗したことを上位層に通知し、同期外れを宣言してもよい。
【０１１６】
ＭＡＣエンティティが、いずれのＴＴＩ内に構成されるＢＰＬｉのＢＲＲのための有効な専用ＮＲ−ＰＲＡＣＨリソースも有していない場合、かつ、「ランダムアクセスをスキップすること」が構成されていない場合、ＳｐＣｅｌｌでのＢＰＬｉのＢＲＲのために構成される（専用ではない）ＰＲＡＣＨリソースを使用するランダムアクセスプロシージャを、ＵＬビームスイーピングを用いて開始して、ＢＰＬｉのすべてのペンディングＢＲＲをキャンセルする。
【０１１７】
ＵＬ候補ビームが、ビームメンテナンスプロシージャおよびシグナリングを介してＵＥに認識される場合、ＵＥは、まずこれらの候補ビームをスイープしてもよく、かつ、ビームスイーピングの順番は、候補ビームのビーム品質の高い順でアレンジされてよい。
【０１１８】
複数のＢＰＬのためにペンディングされているＢＲＲがある場合、ＵＥは、設定に従って１つずつ構成されたＰＵＣＣＨリソースで伝送するか、単一のＰＵＣＣＨで１つのＢＲＲを伝送してよい。
【０１１９】
ＢＲＲの伝送電力が調整される必要がある。標準のＰＵＣＣＨ／ＰＲＡＣＨ  Ｔｘ電力＋マージン（障害のあるビームリンクの場合）。
【０１２０】
タイムウィンドウ内で、適切な応答が受信されない場合、ＢＲＲのプロシージャは、ＢＲＲの再伝送を考慮に入れる必要がある。
【０１２１】
ＢＲＲ＿ＣＯＵＮＴＥＲは、ＢＲＲバンドルごとにインクリメントされる。ｂｒｒ−ＲｅｓｐｏｎｓｅＷｉｎｄｏｗＴｉｍｅｒが、ＢＲＲ伝送処理の最初のＴＴＩで開始され、その値は、ＢＲＲ応答ウィンドウサイズと等しい。
【０１２２】
図９および図１０にビーム障害回復プロシージャの一例のフローチャートを図示する。
【０１２３】
図９を参照すると、ステップ１００で、ＵＥはビーム障害回復基準が満たされるかどうかを確認する。満たされる場合、ステップ１０１で、ＢＲＲがトリガされる。ＢＲＲはキャンセルされるまでペンディングを維持する。次いで、ステップ１０２で、ＵＥはビーム障害回復早期終了基準を評価する。
【０１２４】
ステップ１０３で、ＵＥはビーム障害回復早期終了基準が満たされているかどうかを確認する。満たされる場合、ステップ１０６で、ビーム障害回復プロシージャはスキップされる。次いで、ステップ１０７で、ＲＲＣは通知されて、すべてのサービングセルのＢＰＬｉのＳＲＳを解放し、いずれの構成された下りリンク割り当ておよび上りリンクグラントもクリアし、ＳｐＣｅｌｌでのランダムアクセスプロシージャを開始して、すべてのペンディングＢＲＲをキャンセルし、ビーム障害回復が失敗したことを上位層に通知し、同期外れを宣言して、方法を終了する。
【０１２５】
ステップ１０３で、早期終了基準が満たされない場合、ステップ１０４で、ＢＲＲがＢＰＬｉのためにトリガされ、かつペンディングされている他のＢＲＲがない場合、ＭＡＣエンティティは、ＢＬＰｉ用のＢＲＲ＿ＣＯＵＮＴＥＲを０にセットしてもよい。次いで、ステップ１０５で、１つのＢＲＲが、ＢＰＬｉのためにペンディングされている限り、ＭＡＣエンティティはＴＴＩごとに下記のことを行ってもよい。
【０１２６】
次に図１０を参照して、ステップ１０５の後に、ステップ１０８で、ＵＥは、ＵＥのＵＬビーム品質が依然として通信のために許容可能であるかどうかを確認する。許容可能でない場合、ステップ１０９で、ＵＥは、現在のＴＴＩ内に、専用ＰＲＡＣＨがＢＲＲのために構成されているかどうか確認する。構成されている場合、ステップ１１０で、ＵＥは、ＢＬＰＩ用のＢＲＲ＿ＣＯＵＮＴＥＲが、ｄｂｒｒ−ＴｒａｎｓＭａｘより小さいかどうかを確認する。ｄｂｒｒ−ＴｒａｎｓＭａｘより大きい場合、ステップ１１４で、ＲＲＣは通知されて、すべてのサービングセルのＢＰＬｉのＢＲＲのために構成されたＰＵＣＣＨまたは専用ＰＲＡＣＨを解放する。次いで、ステップ１１５で、ＲＲＣは通知されて、すべてのサービングセルのＢＰＬｉのＳＲＳを解放し、いずれの構成された下りリンク割り当ておよび上りリンクグラントもクリアし、ＳｐＣｅｌｌでのランダムアクセスプロシージャを開始して、すべてのペンディングＢＲＲをキャンセルし、ビーム障害回復が失敗したことを上位層に通知し、同期外れを宣言して、方法を終了する。
【０１２７】
ステップ１１０で、ＢＬＰＩ用のＢＲＲ＿ＣＯＵＮＴＥＲが、ｄｂｒｒ−ＴｒａｎｓＭａｘより小さい場合、ステップ１１１で、ＢＲＲ＿ＣＯＵＮＴＥＲは、ＢＬＰｉのために１だけインクリメントされる。次いで、ステップ１１２で、ＵＥは、物理層に命令して、ＵＬビームスイーピングを用いて、ＢＲＲのために構成された１つの有効な専用ＰＲＡＣＨリソースでＢＲＲを伝送するが、その順番は、候補ビームのビーム品質の高い順で決定されてよい。次いで、ステップ１１３で、ＵＥは、ｂｒｒ−ＲｅｓｐｏｎｓｅＷｉｎｄｏｗＴｉｍｅｒを開始する。次に、方法は、次のＴＴＩのために、ステップ１３０に進行し、その後で、ステップ１１６で、ＵＥは、有効なビーム回復応答が受信されるかどうかを確認する。受信される場合、ステップ１１７で、ＵＥは、ＢＰＬｉ向けのすべてのペンディングＢＲＲをキャンセルし、方法を終了する。
【０１２８】
ステップ１１６で、有効なビーム回復応答が受信されない場合、方法はステップ１０８に戻る。
【０１２９】
ステップ１０９で、現在のＴＴＩ内に、専用ＰＲＡＣＨがＢＲＲのために構成されていない場合、ステップ１１８で、ＵＥは、ＳｐＣｅｌｌでのＢＰＬｉのＢＲＲのために構成される（専用ではない）ＰＲＡＣＨリソースを使用するランダムアクセスプロシージャを開始して、ＢＰＬｉのすべてのペンディングＢＲＲをキャンセルし、その後、方法を終了する。
【０１３０】
ステップ１０８で、ＵＥのＵＬビーム品質が依然として通信のために許容可能である場合、ステップ１１９で、ＵＥは、構成されたＰＵＣＣＨ／専用ＰＲＡＣＨ伝送、またはグラントフリーＰＵＳＣＨ伝送基準の条件が満たされるかどうかを確認する。構成されたＰＵＣＣＨ／専用ＰＲＡＣＨ伝送の条件が満たされる場合、ステップ１２０で、ＵＥは、ＢＬＰＩ用のＢＲＲ＿ＣＯＵＮＴＥＲが、ｄｂｒｒ−ＴｒａｎｓＭａｘより小さいかどうかを確認する。小さい場合、ステップ１２１で、ＢＬＰｉ用のＢＲＲ＿ＣＯＵＮＴＥＲが１だけインクリメントされる。次いで、ステップ１２２で、ＵＥは物理層に命令して、ＢＲＲのための１つの有効なＰＵＣＣＨリソースでＢＲＲをシグナリングするか、またはＢＲＲのために構成された１つの有効な専用ＰＲＡＣＨリソースでＢＲＲを伝送するか、もしくは、スケジュール済みＮＲ−ＰＵＳＣＨでＢＲＲをピギーバックする。次に、ステップ１２３で、ｂｒｒ−ＲｅｓｐｏｎｓｅＷｉｎｄｏｗＴｉｍｅｒが開始され、方法は、次のＴＴＩのために、ステップ１３０へ進む。
【０１３１】
ステップ１２０で、ＢＬＰＩ用のＢＲＲ＿ＣＯＵＮＴＥＲがｄｂｒｒ−ＴｒａｎｓＭａｘより大きい場合、ステップ１２４で、ＵＥは、ＲＲＣに通知して、すべてのサービングセルのＢＰＬｉのＢＲＲのために構成されたＰＵＣＣＨまたは専用ＰＲＡＣＨを解放する。次いで、ステップ１２５で、ＵＥはＲＲＣに通知して、すべてのサービングセルのＢＰＬｉのＳＲＳを解放し、いずれの構成された下りリンク割り当ておよび上りリンクグラントもクリアし、ＳｐＣｅｌｌでのランダムアクセスプロシージャを開始して、すべてのペンディングＢＲＲをキャンセルし、ビーム障害回復が失敗したことを上位層に通知し、同期外れを宣言して、方法を終了する。
【０１３２】
ステップ１１９で、グラントフリーＰＵＳＣＨ伝送の条件が満たされる場合、ステップ１２６で、ＵＥは、ＢＬＰｉ用のＢＲＲ＿ＣＯＵＮＴＥＲがｓｂｒｒ−ＴｒａｎｓＭａｘより小さいかどうかを確認する。小さい場合、ステップ１２７で、ＢＬＰｉ用のＢＲＲ＿ＣＯＵＮＴＥＲが１だけインクリメントされる。次いで、ステップ１２８で、ＵＥは、物理層に命令して、（ＵＥによって伝送されるユーザデータが１つもない場合）利用可能なグラントフリーＮＲ−ＰＵＳＣＨでＢＲＲをシグナリングするか、または、（ＵＥによってこのグラントフリーＮＲ−ＰＵＳＣＨで伝送されるユーザデータがある場合）グラントフリーＮＲ−ＰＵＳＣＨでＢＲＲをピギーバックする。次に、ステップ１２９で、ＵＥは、ｂｒｒ−ＲｅｓｐｏｎｓｅＷｉｎｄｏｗＴｉｍｅｒを開始し、方法は、次のＴＴＩのために、ステップ１３０へ進む。
【０１３３】
ステップ１２６で、ＢＬＰｉ用のＢＲＲ＿ＣＯＵＮＴＥＲがｓｂｒｒ−ＴｒａｎｓＭａｘより大きい場合、方法はステップ１２５へ進行する。
【０１３４】
ステップ１１９で、構成されたＰＵＣＣＨ／専用ＰＲＡＣＨ伝送、またはグラントフリーＰＵＳＣＨ伝送基準の条件のどちらも満たされない場合、方法はステップ１１８に進む。
【０１３５】
（ＳＲ設計）
課題２に対処するために、概して、例えば、以下の３つの原理に従って、ＮＲでのＳＲに対処することが有利である。
【０１３６】
第１に、ＳＲのために構成されるＰＵＣＣＨリソースがない場合、ＵＥは、グラントフリーＰＵＳＣＨを最初に考慮してもよい（このグラントフリーＰＵＳＣＨは、クロスサブフレームスケジューリングが使用される場合、現在のＴＴＩ内か、または次のいくつかのＴＴＩ内にあることがある）。利用可能なグラントフリーＰＵＳＣＨがない場合、ＳＲはＲＡＣＨを使用してよい。
【０１３７】
第２に、ＳＲ向けに構成されたＰＵＣＣＨリソースを待つことが、ＳＲおよびデータの大幅な遅延の原因になる可能性がある場合、ＵＥは、最初にグラントフリーＰＵＳＣＨを使用することを選択してもよい。（データ＋ＢＳＲの）グラントフリーＰＵＳＣＨでの伝送は、グラントフリーＰＵＳＣＨ伝送に対するＡＣＫ／ＮＡＣＫが受信されるまで、現在のＳＲを（キャンセルすることなく）保留にしてもよい。
【０１３８】
第３に、ＵＥのＳＲプロシージャは、ＰＵＣＣＨベースのＳＲおよびグラントフリーＵＬ−ＳＣＨ伝送のために、ｄｓｒ−ＴｒａｎｓＭａｘおよびｇｓｒ−ＴｒａｎｓＭａｘの２つのカウンタを別々に使用してもよい。
【０１３９】
（ＳＲプロシージャの詳細）
スケジューリングリクエスト（ＳＲ）は、新しい伝送向けのＵＬ−ＳＣＨリソースをリクエストするために使用されてよい。ＳＲがトリガされるときに、ＳＲはキャンセルされるまでペンディングとして見なされてもよい。ＭＡＣ  ＰＤＵが組み立てられて、このＰＤＵが、ＢＳＲをトリガした最後のイベントまでの（および、それを含んでいる）バッファ状態を含むＢＳＲを含むときに、または、ＭＡＣ  ＰＤＵが組み立てられて、このＰＤＵが、サイドリンクＢＳＲをトリガした最後のイベントまでの（および、それを含んでいる）バッファ状態を含むサイドリンクＢＳＲを含むときに、すべてのペンディングＳＲが、サイドリンクＢＳＲによってトリガされる場合、もしくは上位層が、自律的なリソース選択を構成するときか、またはＵＬグラントが伝送のために利用可能なすべてのペンディングデータを適応する可能性があるときに、すべてのペンディングＳＲが、サイドリンクＢＳＲによってトリガされる場合、すべてのペンディングＳＲはキャンセルされて、ｓｒ−ＰｒｏｈｉｂｉｔＴｉｍｅｒは停止されてよい。
【０１４０】
ＳＲがトリガされ、かつペンディングされている他のＳＲがない場合、ＭＡＣエンティティはＳＲ＿ＣＯＵＮＴＥＲを０にセットしてもよい。
【０１４１】
１つのＳＲがペンディングされていて、ＭＡＣエンティティがＴＴＩごとにする可能性があり、現在のＴＴＩでの伝送のために利用可能なＵＬ−ＳＣＨリソースがない限り、処理は、有効なＰＵＣＣＨリソースがＳＲのために構成されるかどうかに従って進行してよい。
【０１４２】
ＭＡＣエンティティが、いずれのＴＴＩ内に構成されるＳＲのための有効なＰＵＣＣＨリソースも、いずれのＴＴＩ内の有効なグラントフリーＵＬ−ＳＣＨリソースも有しておらず、ＭＣＧ  ＭＡＣエンティティのｒａｃｈ−ＳｋｉｐまたはＳＣＧ  ＭＡＣエンティティのｒａｃｈ−ＳｋｉｐＳＣＧが構成されていない場合、ＭＡＣエンティティは、ＳｐＣｅｌｌでのランダムアクセスプロシージャを開始して、すべてのペンディングＳＲをキャンセルしてもよい。
【０１４３】
ＭＡＣエンティティが、現在のＴＴＩの間に構成されるＳＲのための少なくとも１つの有効なＰＵＣＣＨリソースを有している場合、かつ、現在のＴＴＩが、伝送のための測定ギャップまたはサイドリンク発見ギャップの一部ではない場合、また、ｓｒ−ＰｒｏｈｉｂｉｔＴｉｍｅｒが動作していない場合、処理は、ＳＲ＿ＣＯＵＮＴＥＲに依存してもよい。
【０１４４】
ＳＲ＿ＣＯＵＮＴＥＲが、ｄｓｒ−ＴｒａｎｓＭａｘより小さい場合、ＭＡＣエンティティは、ＳＲ＿ＣＯＵＮＴＥＲを１だけインクリメントし、物理層に命令して、ＳＲのための１つの有効なＰＵＣＣＨリソースでＳＲをシグナリングし、かつｓｒ−ＰｒｏｈｉｂｉｔＴｉｍｅｒを開始してよい。
【０１４５】
ＳＲ＿ＣＯＵＮＴＥＲが、ｄｓｒ−ＴｒａｎｓＭａｘより大きい場合、ＭＡＣエンティティは、ＲＲＣに通知して、すべてのサービングセルのＰＵＣＣＨを解放し、ＲＲＣに通知して、すべてのサービングセルのＳＲＳを解放し、いずれの構成された下りリンク割り当ておよび上りリンクグラントもクリアし、ＳｐＣｅｌｌでのランダムアクセスプロシージャを開始して、すべてのペンディングＳＲをキャンセルしてもよい。
【０１４６】
ＭＡＣエンティティが１つのＴＴＩ内でＳＲのための複数の有効なＰＵＣＣＨリソースを有するときに、ＳＲ向けにどの有効なＰＵＣＣＨリソースでＳＲをシグナリングするかの選択は、ＵＥの実装形態に任される。
【０１４７】
ＳＲ＿ＣＯＵＮＴＥＲが、ＳＲバンドルごとにインクリメントされる。ｓｒ−ＰｒｏｈｉｂｉｔＴｉｍｅｒがＳＲバンドルの最初のＴＴＩで開始される。
【０１４８】
図１１は、ＳＲプロシージャの一例を示す。ステップ２００で、ＳＲがトリガされる。ＳＲはキャンセルされるまでペンディングを維持する。
【０１４９】
ステップ２０１で、ＳＲがトリガされ、かつペンディングされている他のＳＲがない場合、ＭＡＣエンティティはＳＲ＿ＣＯＵＮＴＥＲを０にセットし、ＧＦ＿ＳＲ＿ＣＯＵＮＴＥＲを０にセットしてもよい。
【０１５０】
ステップ２０２から始まって、１つのＳＲがペンディングされている限り、ＭＡＣエンティティはＴＴＩごとに残りのステップを実施する。
【０１５１】
ステップ２０３で、ＭＡＣエンティティは、グラントベースのＵＬ−ＳＣＨリソースが、現在のＴＴＩでの伝送向けに利用可能であるかどうかをチェックする。利用可能である場合、ステップ２０４で、ＭＡＣ  ＰＤＵが組み立てられ、グラントベースのＵＬ−ＳＣＨで伝送される。ＰＤＵは、ＢＳＲをトリガした最後のイベントまでの（および、それを含んでいる）バッファ状態を含むＢＳＲを含む。次いで、ステップ２０５で、すべてのペンディングＳＲはキャンセルされて、ｓｒ−ＰｒｏｈｉｂｉｔＴｉｍｅｒが停止されてよく、方法は終了する。
【０１５２】
ステップ２０３で、グラントベースのＵＬ−ＳＣＨリソースが、現在のＴＴＩでの伝送のために利用可能でない場合、ステップ２０６で、ＭＡＣエンティティは、どのＳＲまたはデータおよびＢＳＲ伝送基準が満たされるかを確認する。
【０１５３】
いずれのＴＴＩ内に構成されるＳＲのための有効なＰＵＣＣＨリソースも有していないが、現在のＴＴＩ内に少なくとも１つの有効なグラントフリーＵＬ−ＳＣＨリソースを有している場合、あるいは、ＭＡＣエンティティが、大幅なレイテンシの原因となる可能性のある、その後のＴＴＩ内に構成されるＳＲのための少なくとも１つの有効なＰＵＣＣＨリソースを有しており、ユーザデータがレイテンシセンシティブ（例えば、ＵＲＬＬＣデータ）であり、かつ現在のＴＴＩ内に少なくとも１つの有効なグラントフリーＵＬ−ＳＣＨリソースを有している場合、ならびに、現在のＴＴＩが、伝送のための測定ギャップまたはサイドリンク発見ギャップの一部ではない場合、またＳＲが保留されていない場合、方法はステップ２０７に進行する。次いで、ステップ２０８で、ＭＡＣエンティティは、ＧＦ＿ＳＲ＿ＣＯＵＮＴＥＲが、ｓｓｒ−ＴｒａｎｓＭａｘより小さいかどうか確認する。小さい場合、ステップ２０９で、ＭＡＣエンティティは、ＧＦ＿ＳＲ＿ＣＯＵＮＴＥＲを１だけインクリメントし、物理層に命令して、１つの有効なグラントフリーＵＬ−ＳＣＨリソースで、ユーザデータおよびＢＳＲを伝送する。次のステップ２１０で、ｇＮＢからＡＣＫ／ＮＡＣＫが受信されるまで、ＳＲは保留される（キャンセルはされない）。ＡＣＫが受信される場合、ＳＲはキャンセルされてよい。ＮＡＣＫが受信される場合、ＳＲはペンディング状態に戻り、方法は、ステップ１３０で、次のＴＴＩに進む。
【０１５４】
ステップ２０８で、ＧＦ＿ＳＲ＿ＣＯＵＮＴＥＲが、ｓｓｒ−ＴｒａｎｓＭａｘより大きい場合、ステップ２１１で、ＭＡＣエンティティは、ＳｐＣｅｌｌでのランダムアクセスプロシージャを開始して、すべてのペンディングＳＲをキャンセルし、方法を終了する。
【０１５５】
ステップ２１２で、ＭＡＣエンティティが、いずれのＴＴＩ内に構成されるＳＲのための有効なＰＵＣＣＨリソースも、いずれのＴＴＩ内に構成される有効なグラントフリーＵＬ−ＳＣＨリソースも有していない場合、および「ＲＡＣＨをスキップすること」が構成されていない場合、方法は、ステップ２１１に進行する。
【０１５６】
ステップ２１３で、ＭＡＣエンティティが、現在のＴＴＩの間に構成されるＳＲのための少なくとも１つの有効なＰＵＣＣＨリソースを有している場合、および現在のＴＴＩが、伝送のための測定ギャップまたはサイドリンク発見ギャップの一部ではない場合、またｓｒ−ＰｒｏｈｉｂｉｔＴｉｍｅｒが動作していない場合、方法はステップ２１４に進行する。
【０１５７】
ステップ２１４で、ＭＡＣエンティティは、ＳＲ＿ＣＯＵＮＴＥＲが、ｄｓｒ−ＴｒａｎｓＭａｘより小さいかどうか確認する。小さい場合、ステップ２１５で、ＭＡＣエンティティは、ＳＲ＿ＣＯＵＮＴＥＲを１だけインクリメントし、物理層に命令して、ＳＲのための１つの有効なＰＵＣＣＨリソースで、ＳＲをシグナリングする。次に、ステップ２１６で、ｓｒ−ＰｒｏｈｉｂｉｔＴｉｍｅｒを開始する。
【０１５８】
ステップ２１７で、ＭＡＣエンティティは、ステップ２０３に戻って進行することによって、次のＴＴＩを処理する。
【０１５９】
ステップ２１４で、ＳＲ＿ＣＯＵＮＴＥＲが、ｄｓｒ−ＴｒａｎｓＭａｘより大きい場合、次いで、ステップ２１８で、ＭＡＣエンティティは、ＲＲＣに通知して、すべてのサービングセルのＰＵＣＣＨを解放し、すべてのサービングセルのＳＲＳを解放し、かついずれの構成された下りリンク割り当ておよび上りリンクグラントもクリアする。次いで、ステップ２１９で、ＭＡＣエンティティは、ＳｐＣｅｌｌでのランダムアクセスプロシージャを開始して、すべてのペンディングＳＲをキャンセルする。
【０１６０】
ＢＲＲとＳＲとの相互作用の課題２に対処するために、ビーム障害回復とスケジューリングリクエストプロシージャとの相互作用を対処することが有利である。本明細書では、ＢＲＲおよびＳＲのためのＮＲ−ＰＵＣＣＨリソースおよび専用ＰＲＡＣＨリソース割り当てに直接影響を与える場合がある、ビーム障害回復およびスケジューリングリクエストプロシージャに関する２つの設計原理を適用する。
【０１６１】
設計原理１、トリガされたビーム障害回復プロシージャは、任意のペンディングＳＲを中断してもよい。ビーム障害回復が新しいＢＰＬを用いて正常に終了すると、中断されたＳＲ処理は、再開されるかリセットされてよい。これにより、ＢＲＲは、ＳＲと一緒に同時に伝送されない。
【０１６２】
設計原理２、トリガされたビーム障害回復プロシージャは、任意のペンディングＳＲを中断しなくてもよい。これにより、ＢＲＲは、ＳＲと同時に一緒に伝送されてよい。
【０１６３】
（設計原理１のリソース割り当ておよびプロシージャ）
設計原理１のＢＲＲおよびＳＲのために構成されるＵＬチャネルリソースは、以下の方法の１つを採用してもよい。
【０１６４】
方法１は、ＵＥごとに、ＢＲＲおよびＳＲのために共通して構成された１つのＵＬチャネルリソースを構成できるようなものである。このＵＬチャネルで搬送されることになる最大情報量は、ＳＲビットとＢＲＲビットとの大きい方によって決定される。ＮＲでは、ＢＲＲはＳＲより大きいビットを使用する場合がある。
【０１６５】
方法２は、ＵＥごとに、ＢＲＲおよびＳＲのために別々に構成された２つのＵＬチャネルリソースを構成できるようなものである。各ＵＬチャネルで搬送されることになる最大情報量は、ＳＲビットとＢＲＲビットとで、別々に決定される。
【０１６６】
（ＢＲＲとＳＲとの多重化プロシージャ）
ＵＥのビーム障害回復基準が満たされるイベントの際に、ＢＲＲはトリガされて、もしあれば、ペンディングＳＲをＵＥは中断してよい。具体的には、ＳＲプロシージャのすべてのタイマおよびカウンタが中断されてよい。また、有効なビーム回復応答コマンドがＵＥによって受信されるまで、ＳＲは伝送されず、選択的に上りリンクユーザデータ＋ＢＳＲも伝送されなくてもよく、新しいＢＰＬがＵＬ、ＤＬまたは両方に確立される。次いで、ＵＥはＳＲプロシージャならびに関連するタイマおよびカウンタを再開するか、またはＳＲプロシージャならびに関連するタイマおよびカウンタをリセットしてよい。リソース割り当て方法１に関して、ＢＲＲおよびＳＲは、共通して構成された各ＵＬチャネルリソースで、伝送されてよい（ただし、同時ではない）。リソース割り当て方法２に関して、ＢＲＲおよびＳＲは、別々に構成された各ＵＬチャネルリソースで、伝送されてよい（ただし、同時ではない）。
【０１６７】
（設計原理２のリソース割り当ておよびプロシージャ）
設計原理２のＢＲＲおよびＳＲのために構成されるＵＬチャネルリソースは、以下の方法の１つを採用してもよい。
【０１６８】
方法１は、ＵＥごとに、ＢＲＲおよびＳＲのために共通して構成された１つのＵＬチャネルリソースを構成できるようなものである。このＵＬチャネルで搬送されることになる最大情報量は、ＳＲおよびＢＲＲのために使用されるビットの合計によって決定される。
【０１６９】
方法２は、ＵＥごとに、ＢＲＲおよびＳＲのために別々に構成された２つのＵＬチャネルリソースを構成できるようなものである。両方のＵＬチャネルで搬送されることになる最大情報量は、ＢＲＲによって使用されるビット数によって決定される。
【０１７０】
（ＢＲＲとＳＲとの多重化プロシージャ）
ＵＥのビーム障害回復基準が満たされるイベントの際に、ＢＲＲはトリガされて、もしあれば、ペンディングＳＲをＵＥは中断しなくてもよい。その代わりに、ＵＥは、可能であれば、ＢＲＲおよびＳＲを多重化してよい。リソース割り当て方法１に関して、共通して構成された各ＵＬチャネルリソースは、ＢＲＲのみか、ＳＲＲのみか、またはＢＲＲおよびＳＲの両方を、同時に搬送してよい。異なるコンテンツがフォーマットインジケータによってシグナリングされるか、ｇＮＢで暗黙的に検出されてよい。リソース割り当て方法２に関して、ＢＲＲまたはＳＲのどちらかのみが、送信される必要がある場合、ＢＲＲまたはＳＲのどちらかのために構成されるＵＬチャネルリソースでそれは伝送されてよい。ＢＲＲおよびＳＲの両方が伝送される必要がある場合、ＢＲＲビットのみが、ＳＲのために構成されるＵＬチャネルリソースで送信されてよい。このような伝送は、ＢＲＲおよびＳＲが伝送されることを示してもよい。
【０１７１】
（ＳＲに対するさらなる拡張）
スケジューリングリクエストは、いくつかの理由により失敗する可能性がある。例えば、スケジューリングリクエストは、ＤＬ同期またはＵＬ同期の喪失によって失敗する可能性がある。例えば、現在のＬＴＥ仕様の通りに、ＵＥがもはや同期していないときに、ＳＲのためのＰＵＣＣＨリソースは失われる。同様に、スケジューリングリクエストは、ＳＲのために構成されるＰＵＣＣＨリソースでの干渉によって、またはＵＥによる誤ったＰＵＣＣＨ伝送電力計算をもたらす、誤ったパス損失推定によって失敗する可能性がある。
【０１７２】
上記の理由のいずれかは、特定のセルまたはセルのグループに依存するものである場合があるが、必ずしも特定のＰＵＣＣＨリソースに依存するものではない。例えば、ＵＥは、構成されたタイミングアドバンスグループ（Timing  Advance  Groups：ＴＡＧ）によって、指図されるようなセルグループごとの同期を管理する。同期の喪失に関連するＰＵＣＣＨの問題によってもたらされるＳＲ障害は、同じＴＡＧに関連する同じセルグループで構成されるすべてのＳＲ  ＰＵＣＣＨリソースに共通である可能性がある。同様に、例えば、ＰＵＣＣＨリソース上の干渉または誤ったパス損失推定が原因のＳＲ障害は、おそらくセル固有またはセルグループ固有の可能性がある。
【０１７３】
追加として、ＮＲでは、セルのキャリア帯域幅は、複数の帯域幅パート（ＢＷＰ）を用いて構成される場合がある。ＳＲ障害はまた、ＢＷＰ固有のものである可能性もある。
【０１７４】
ＳＲ障害タイプを規定して、ＳＲ伝送カウンタがＳＲ構成に対して最大値に達すると、特定のＳＲ障害タイプを宣言することは、有利である。ＳＲ障害タイプとしては、例えば、以下のものを挙げてもよい。
【０１７５】
ＳＲ構成に関連するＳＲ障害、失敗したＳＲのリソースが構成されているＢＷＰに関連するＳＲ障害、および失敗したＳＲのリソースが構成されているセルに関連するＳＲ障害。
【０１７６】
障害タイプは、規格においてハードコードされてもよい。あるいは、障害タイプに対するＳＲ障害をどのようにＵＥが解釈するかは、ネットワークによって構成されてよい。
【０１７７】
（ＳＲ障害の際のＵＥ動作）
ＳＲ構成に関連付けられたＳＲ伝送カウンタ（SR  Transmission  Counter：ＳＲ＿ＣＯＵＮＴＥＲ）が、最大ＳＲ伝送（ｄｒｓ−ＴｒａｎｓＭａｘ）に達すると、ＵＥはいくつかの動作をとってもよい。例えば、ＭＡＣは、ＲＲＣに通知して、失敗したＳＲのＳＲ構成のためのＰＵＣＣＨを解放してもよい。ＭＡＣは、ＲＲＣに通知して、失敗したＳＲのリソースが構成されているサービングセルのＰＵＣＣＨを解放してもよい。ＭＡＣは、ＲＲＣに通知して、失敗したＳＲのリソースが構成されているサービングセルのタイミングアドバンスグループ（ＴＡＧ）内のすべてのサービングセルのＰＵＣＣＨを解放してもよい。ＭＡＣは、ＲＲＣに通知して、失敗したＳＲのリソースが構成されているＢＷＰのＰＵＣＣＨを解放してもよい。
【０１７８】
ＵＥは、特定のＳＲ障害タイプ、またはＵＥが構成されている障害タイプの粒度に応じて、上記の動作のいずれかを実施してもよい。例えば、ＵＥの構成は、特定のＳＲ障害タイプ、またはＵＥが構成されるＳＲ障害タイプに応じて、それに従って以下の動作をとってよい。ＵＥがＳＲ障害タイプ「ＳＲ構成固有のＳＲ障害」を用いて構成されている場合、ＭＡＣは、ＲＲＣに通知して、失敗したＳＲのＳＲ構成のためのＰＵＣＣＨを解放してもよい。
【０１７９】
ＵＥがＳＲ障害タイプ「失敗したＳＲのリソースが構成されているセル固有のＳＲ障害」を用いて構成されている場合、ＭＡＣは、ＲＲＣに通知して、失敗したＳＲのリソースが構成されているサービングセルのＰＵＣＣＨを解放してもよい。
【０１８０】
ＵＥがＳＲ障害タイプ「失敗したＳＲのリソースが構成されているセル固有のＳＲ障害」を用いて構成されている場合、ＭＡＣは、ＲＲＣに通知して、失敗したＳＲのリソースが構成されているサービングセルのタイミングアドバンスグループ（ＴＡＧ）内のすべてのサービングセルのＰＵＣＣＨを解放してもよい。例えば、ＵＥがＵＬ同期の喪失を検出する場合も、ＵＥはこの動作をとってよい。
【０１８１】
ＵＥがＳＲ障害タイプ「ＭＡＣがＲＲＣに通知して、失敗したＳＲのリソースが構成されているＢＷＰのＰＵＣＣＨを解放してもよい」を用いて構成されている場合、ＭＡＣは、ＲＲＣに通知して、失敗したＳＲのリソースが構成されているＢＷＰのＰＵＣＣＨを解放する。
【０１８２】
（ＵＥによるｇＮＢへのＳＲ障害とＰＵＣＣＨ解放のシグナリング）
ＵＥは、以下の方法のうち１つを使用して、ＳＲ障害およびＰＵＣＣＨ解放をｇＮＢへシグナリングしてよい。
【０１８３】
（ＲＲＣプロシージャ）
ＵＥがネットワークに、ＳＲ障害を報告して、ＰＵＣＣＨ解放をリクエストするように、新しいＲＲＣメッセージが定義されてよい。このようなメッセージは、ＰＵＣＣＨＦａｉｌｕｒｅＲｅｐｏｒｔ、ＰＵＣＣＨＳｔａｔｕｓＲｅｐｏｒｔ、ＰＵＣＣＨＲｅｅｓｔａｂｌｉｓｈｍｅｎｔ、ＰＵＣＣＨＦａｉｌｕｒｅＩｎｆｏｒｍａｔｉｏｎなどと呼ばれてもよい。メッセージは、ＲＲＣトランザクション識別子およびＳＲ構成インデックス（SR  Configuration  Index：ｓｒ−ＣｏｎｆｉｇＩｎｄｅｘ）を含んでもよい。追加として、失敗したＳＲに使用されたリソースのインデックス（ｓｒ−ＰＵＣＣＨ−ＲｅｓｏｕｒｃｅＩｎｄｅｘ）が、メッセージに含まれてもよい。ＵＥは、ＲＬＣ  ＡＭモードで、シグナリング無線ベアラＳＲＢ１上でメッセージを送信してよい。
【０１８４】
あるいは、ＳＲ障害情報およびＰＵＣＣＨ解放リクエストが、既存のＵＥからのｇＮＢへのＲＲＣメッセージを使用して、ｇＮＢにシグナリングされてよい。このようなメッセージは、新しいメッセージコード、およびＳＲ構成インデックス（ｓｒ−ＣｏｎｆｉｇＩｎｄｅｘ）などの情報要素を含んでもよく、かつ、失敗したＳＲに使用されたリソースのインデックス（ｓｒ−ＰＵＣＣＨ−ＲｅｓｏｕｒｃｅＩｎｄｅｘ）が、メッセージに含まれてもよい。
【０１８５】
（ＭＡＣプロシージャ）
ＲＡＣＨプロシージャを使用して、ｇＮＢに、ＳＲ障害を報告し、ＰＵＣＣＨ解放をリクエストしてもよい。ＵＥは、失敗したＳＲをトリガする論理チャネルに対応するＢＳＲをＲＡＣＨメッセージ３（Message  3：Ｍｓｇ３）に含んでもよい。ｇＮＢは、論理チャネル、したがって、失敗したＳＲの構成、および解放されるべきＰＵＣＣＨを、受信したＢＳＲから暗に導き出す。
【０１８６】
別の実施形態では、ＲＡＣＨ  Ｍｓｇ３は、失敗したＳＲリソースの識別子、例えば、ＳＲ構成インデックス（ｓｒ−ＣｏｎｆｉｇＩｎｄｅｘ）および／または失敗したＳＲのために使用されたリソースのインデックス（ｓｒ−ＰＵＣＣＨ−ＲｅｓｏｕｒｃｅＩｎｄｅｘ）を明確に搬送してもよい。ＵＥはこの情報を使用して、ｇＮＢに失敗したＳＲおよび解放されるべきＰＵＣＣＨを知らせる。
【０１８７】
別の実施形態では、ＵＥはＲＡＣＨリソースとＰＵＣＣＨリソース（例えば、ＳＲ  ＰＵＣＣＨリソース）との関連付けを用いて構成されてよい。ＵＥは、失敗したＳＲのＰＵＣＣＨリソースに関連付けられたＲＡＣＨリソースで、ＲＡＣＨメッセージ１（Message  1：Ｍｓｇ１）を伝送する。ｇＮＢは、ＲＡＣＨ  Ｍｓｇ１がその上で受信されるＲＡＣＨリソースに基づいて、失敗したＰＵＣＣＨリソース、すなわち、失敗したＳＲ、および解放されるべきＰＵＣＣＨを識別する。
【０１８８】
ＵＥは、失敗したＳＲのリソースが構成されているサービングセルでのＲＡＣＨプロシージャを開始することができる。しかし、既存のＬＴＥシステムでは、セカンダリセル（Secondary  Cell：ＳＣｅｌｌ）でのランダムアクセスプロシージャが、ｅＮＢからのＰＤＣＣＨ命令によってのみ開始されることがある。ＰＵＣＣＨリソースは、任意のセカンダリサービングセルで構成される可能性があるので、ＮＲシステムでは、特定の理由で、または一定の基準が満たされるときに、ＵＥが、ＳＣｅｌｌ、すなわち、プライマリセカンダリセルではないセカンダリセルでのＲＡＣＨプロシージャを開始できることは、有利である。例えば、ＳＲ障害が発生するときに、ＵＥは、ＳＣｅｌｌでのＲＡＣＨプロシージャを開始して、ＳＲ障害およびＰＵＣＣＨ解放のリクエストをシグナリングしてよい。ｇＮＢは、ＵＥが（ＰＤＣＣＨ命令なしに）開始したＳＣｅｌｌでのＲＡＣＨプロシージャの受信を、そのＳＣｅｌｌでの、ＳＲ障害インジケーション、およびＰＵＣＣＨの解放のリクエストとして解釈する。
【０１８９】
例えば、一実施形態では、ＵＥによるｇＮＢへのＳＲ障害のシグナリングおよび／またはＰＵＣＣＨリソースの解放のために確保されているＲＡＣＨリソースを用いて、ＵＥは、構成されてよい。ｇＮＢは、まず、ＳＲ障害のシグナリングのために確保されているＲＡＣＨリソースでのＲＡＣＨプロシージャＭｓｇ１の受信によって、ＳＲ障害について知らされる。ｇＮＢがＲＡＣＨプロシージャＭｓｇ５を受信することによる、コンテンションレゾリューション時、ｇＮＢは、（ＰＤＣＣＨ命令なしに）ＳＣｅｌｌでのＲＡＣＨプロシージャを開始するＵＥを識別する。さらに別の実施形態では、ＳＲ障害のシグナリングのために確保されているＲＡＣＨリソースが、ＵＥ専用のＲＡＣＨリソースの場合、ｇＮＢは、ＲＡＣＨプロシージャＭｓｇ１の受信に応じて、（ＰＤＣＣＨ命令なしに）ＳＣｅｌｌでのＲＡＣＨプロシージャを開始するＵＥを識別する。
【０１９０】
（ＬＣＰに対する拡張）
（ＰＢＲハンドリングおよび変数Ｂｊのメンテナンスに対するさらなる拡張）
固定時間長の基本ＮＲ時間単位（NR  time  UNIT：ＮＲ−ＵＮＩＴ）が、ＭＡＣオペレーションをサポートする際に検討される可能性がある。この基本時間単位は、ＭＡＣエンティティレベルにおける最小の時間分解能である場合があり、ＭＡＣオペレーションを作動させる、システムタイマ割り込み間の時間間隔と見なされることがある。すべてのＮＲ−ＵＮＩＴで、ＭＡＣエンティティは、例えば、ＤＬグラント受信、ＵＬグラント受信、ＤＬデータ受信、論理チャネル優先順位付けを含むＵＬデータ伝送、ＨＡＲＱフィードバックのシグナリング、スケジューリングリクエストのシグナリングなどの実行されるべきペンディングタスクがあるかどうかを確認する。ＮＲでは、ＵＬグラントが利用可能である連続するデータ伝送機会の間の時間間隔は、可変である可能性がある。ここでは、ＤＴＴＩを使用して、連続するデータ伝送機会の間の時間間隔を表す。その場合、ＤＴＴＩは、ＮＲ＿ＵＮＩＴに換算して、例えば、次式（２）で表されることがある（式中、パラメータｄは可変の整数である）。
【数２】
2020524439.tif 000004
【０１９１】
新しい伝送が実施されるたびに、論理チャネル優先順位付けプロシージャが使用されてよい。
【０１９２】
ＭＡＣエンティティごとに、（１）優先度の値が大きいほど優先度のレベルが低い優先度、（２）優先順位付けされたビットレート（ＰＢＲ）をセットするｐｒｉｏｒｉｔｉｓｅｄＢｉｔＲａｔｅ、および、（３）バケットサイズ長（ＢＳＤ）をセットするｂｕｃｋｅｔＳｉｚｅＤｕｒａｔｉｏｎ、を各論理チャネルについてシグナリングすることによって、ＲＲＣは上りリンクデータのスケジューリングを制御する。
【０１９３】
ＭＡＣエンティティは、以下に記載される実施形態のうちの１つに従って、各許可された論理チャネルｊの変数Ｂｊを管理してもよい。
【０１９４】
（変数Ｂｊを管理する実装形態１）
Ｂｊは、関連する論理チャネルが確立されるときに０に初期化され、論理チャネルｊでのデータ伝送機会ごとに、ＰＢＲ×ＤＴＴＩ（ｊ）の積によってインクリメントされ、ここで、ＰＢＲは、論理チャネルｊの優先順位付けされたビットレートであり、ＤＴＴＩ（ｊ）は、論理チャネルＬＣＨ＿ｊでの最後のデータ伝送と、論理チャネルＬＣＨ＿ｊの現在のデータ伝送機会との間の時間間隔である。論理チャネルｊの伝送機会は、論理チャネルｊを作動させることができるグラントを用いるＵＬデータ伝送の瞬間として定義される。しかし、Ｂｊの値は、バケットサイズを超えることはできず、Ｂｊの値が論理チャネルｊのバケットサイズよりも大きい場合は、Ｂｊの値はバケットサイズに設定されることがある。論理チャネルのバケットサイズは、ＰＢＲ×ＢＳＤに等しい。いつＢｊが更新されるかはＵＥの実装形態による。
【０１９５】
（変数Ｂｊを管理する実装形態２）
Ｂｊは、関連する論理チャネルが確立されるときに０に初期化され、論理チャネルｊでのデータ伝送機会ごとに、ＰＢＲ×ＤＴＴＩ（ｊ）の積によってインクリメントされ、ここで、ＰＢＲは論理チャネルｊの優先順位付けされたビットレートであり、ＤＴＴＩ（ｊ）は、論理チャネルＬＣＨ＿ｊでの最後のデータ伝送と、論理チャネルＬＣＨ＿ｊの現在のデータ伝送機会との間の時間間隔である。論理チャネルｊのデータ伝送機会は、論理チャネルｊのデータがそのグラントを用いて実際に伝送される場合のグラントを伴うＵＬデータ伝送の瞬間として定義される。しかし、Ｂｊの値は、バケットサイズを超えることはできず、Ｂｊの値が論理チャネルｊのバケットサイズよりも大きい場合は、Ｂｊの値はバケットサイズに設定されてよい。論理チャネルのバケットサイズは、ＰＢＲ×ＢＳＤに等しい。いつＢｊが更新されるかはＵＥの実装形態による。
【０１９６】
（論理チャネル選択に対するさらなる拡張）
ＬＣＰプロシージャがサポートされる際に、論理チャネルは、グラントがその中にある必要がある許容されるレイテンシとともに構成されてよい。許容されるレイテンシは、残りのＨＡＲＱ動作点と組み合わせられるＴｍｉｎ／Ｔｍａｘによって画定された時間間隔によって定義されてよい。論理チャネルと関連付けられているサービスの目標平均ブロック誤り率（ＢＬＥＲ）を達成するために、残りのＨＡＲＱ動作点は、予想される再伝送の数の全体にわたる許容可能なＢＬＥＲの組み合わせによって表されてよい。新しい伝送が実施されるときにＬＣＰプロシージャが実施されるので、残りのＢＬＥＲは目標ＢＬＥＲと同じでもよい。すべての新しい伝送において、論理チャネルにマップされているサービスの目標ＢＬＥＲを達成するために、ＵＥは予想される再伝送の数を推定する。目標ＢＬＥＲは、最も厳密な目標ＢＬＥＲ、すなわち、論理チャネルにマップされているサービス全体にわたる最小の目標ＢＬＥＲ値であってよい。ＵＥは、推定された再伝送の数を考慮に入れた換算係数によって、許容される下限時間レイテンシＴｍｉｎと、許容される上限時間レイテンシＴｍａｘをスケーリングする。異なる再伝送数が、異なる換算係数に関連付けられる場合、複数の換算係数が定義されてよい。さらに、異なる換算係数が、パラメータＴｍｉｎおよびパラメータＴｍａｘに対して定められてもよい。ＵＥは換算係数を用いて構成されてよい。あるいは、換算係数および再伝送数のマッピングは、仕様においてハードコードされてもよい。さらにもう１つの選択肢として、換算係数の選択および再伝送数のマッピングは、実装形態に任せられてもよい。
【０１９７】
ＭＡＣは、ＬＣＰプロシージャの間、パラメータＴｍｉｎおよびパラメータＴｍａｘに適切な換算係数を乗じることによって、ＴｍｉｎおよびＴｍａｘのスケーリング操作を実施する。
【０１９８】
レイテンシ要件の観点から、論理チャネルのスケーリングされた許容されるレイテンシＴｍｉｎからＴｍａｘの範囲内にグラントの処理タイミングがある場合、ＵＥ  ＭＡＣは、グラントによって論理チャネルが作動されてもよいと判断する。
【０１９９】
（課題５に対するソリューション−ＳＲトリガおよびキャンセル規則に対するさらなる拡張）
図２および図３に例示されているような、ＢＳＲがトリガされているが、キャンセルはされておらず、ＢＳＲの伝送のために利用可能なＵＬ−ＳＣＨリソースがない場合のシナリオにおける、ＳＲトリガリングに対する拡張に対処するソリューションについて、以下で説明する。
【０２００】
ＵＥに割り当てられるＵＬリソースグラントｒは、ＵＬグラント割り当て時間、およびＵＬ割り当てからＵＬデータ伝送までの時間長、すなわち、グラントの総有効時間によって特徴付けられてよい。あるいは、ＵＬ割り当てからＵＬデータ伝送までの時間長、すなわち、グラントの総有効時間は、２つの時間間隔（すなわち、時間間隔１と時間間隔２）に分けられてもよく、時間間隔１は、ＵＬ割り当てからＵＬデータ伝送開始時間までの時間経過に相当し、時間間隔２は、ＵＬリソースグラントの時間長である。ｋ２は、ＵＬ割り当てからＵＬデータ伝送までの時間長、すなわち、グラントの総有効時間、Ｋ２は、ＵＬ割り当てからＵＬデータ伝送開始時間までの時間経過の時間長または長さ、Ｌは、ＵＬ−ＳＣＨグラントの時間長、または長さを表し、この際、ｋ２＝Ｋ２＋Ｌである。Ｈは、グラントの残りの有効時間を表す。グラントｒに関しては、ｋ２（ｒ）は、グラントの総有効時間を表し、Ｋ２（ｒ）は、ＵＬ割り当てからＵＬデータ伝送開始時間までの時間経過を表し、Ｌ（ｒ）は、グラントの時間長を表し、Ｈ（ｒ）はグラントｒの残りの有効時間であることを表す。グラントｒの残りの有効時間である、Ｈ（ｒ）は、グラントｒの有効時間を追跡することで、ＭＡＣによって容易に管理されてよい。Ａ（ｒ）は、グラントｒの有効時間を表す。Ａ（ｒ）は、ＵＥがグラントｒ割り当てを受信する瞬間に、０に初期化されて、ＵＬ伝送機会ごとに、連続するＵＬ伝送機会の間の経過時間ずつ、適切にインクリメントされてよい。その場合、Ｈ（ｒ）は、Ｈ（ｒ）＝ｋ２（ｒ）−Ａ（ｒ）で表されてもよい。あるいは、Ｈ（ｒ）である、グラントの残りの有効時間は、下記のように管理されてよい。Ｈ（ｒ）は、ＵＥがグラントｒ割り当てを受信する瞬間に、ｋ２（ｒ）の値に初期化されて、ＵＬ伝送機会ごとに、連続するＵＬ伝送機会の間の経過時間ずつ、適切にデクリメントされる。パラメータｋ２（ｒ）、Ｋ２（ｒ）、Ｌ（ｒ）、Ｈ（ｒ）およびＡ（ｒ）の単位は、ＯＦＤＭシンボル、ＮＲタイムスロット、ミニスロット、ＮＲ時間スロットとＯＦＤＭシンボルとの組み合わせで示されてよい。例えば、スロットの中間で伝送が開始する場合、パラメータＫ２（ｒ）は、タイムスロットの整数の番号と、そのタイムスロット内のＵＬ−ＳＣＨリソースｒの開始シンボルを指すＯＦＤＭシンボルの整数の番号として表現されるタイムスロットの一部とで、表現することができる。
【０２０１】
図２の例で示されるように、ＢＳＲが、トリガされて、キャンセルされておらず、ＢＳＲの伝送のためのＵＬーＳＣＨリソースグラントがない場合、特に現在の仕様に従って即座にトリガされるＳＲの伝送を遅らせるために使用されるＳＲ制約タイマ、ｌｏｇｉｃａｌＣｈａｎｎｅｌＳＲ−ＲｅｓｔｒｉｃｔｉｏｎＴｉｍｅｒを導入することが有利である。タイマｌｏｇｉｃａｌＣｈａｎｎｅｌＳＲ−ＲｅｓｔｒｉｃｔｉｏｎＴｉｍｅｒは、論理チャネルごとに構成される。ＲＲＣは、ＭＡＣエンティティにタイマを構成する。タイマの値の単位は、ＯＦＤＭシンボル、スロット、または、例えば、ミリ秒またはマイクロ秒などの絶対時間値であってもよい。ｌｏｇｉｃａｌＣｈａｎｎｅｌＳＲ−ＲｅｓｔｒｉｃｔｉｏｎＴｉｍｅｒＤｕｒａｔｉｏｎは、タイマｌｏｇｉｃａｌＣｈａｎｎｅｌＳＲ−ＲｅｓｔｒｉｃｔｉｏｎＴｉｍｅｒの構成される値（すなわち、時間長）を表す。
【０２０２】
ＭＡＣエンティティは、（１）ＢＳＲがトリガされたが、キャンセルはされていない、（２）ＵＬ伝送機会時間間隔の間に、またはＢＳＲがトリガされる瞬間に、ＢＳＲを伝送するのに利用可能なＵＬ−ＳＣＨグラントがない、（３）Ｈ（ｒ）より大きいか、または等しい条件ｌｏｇｉｃａｌＣｈａｎｎｅｌＳＲ−ＲｅｓｔｒｉｃｔｉｏｎＴｉｍｅｒＤｕｒａｔｉｏｎを満たす、ＵＥに割り当てられたＵＬ−ＳＣＨグラントｒがある場合、タイマを開始する。
【０２０３】
ＭＡＣエンティティは、ＢＳＲが伝送されるときに、タイマｌｏｇｉｃａｌＣｈａｎｎｅｌＳＲ−ＲｅｓｔｒｉｃｔｉｏｎＴｉｍｅｒをキャンセルする。別の代替実施形態では、（図２または図３に図示されているように）ＢＳＲをトリガする論理チャネルＬＣＨ２のデータが伝送される場合、ＭＡＣエンティティは、タイマｌｏｇｉｃａｌＣｈａｎｎｅｌＳＲ−ＲｅｓｔｒｉｃｔｉｏｎＴｉｍｅｒをキャンセルする。
【０２０４】
タイマｌｏｇｉｃａｌＣｈａｎｎｅｌＳＲ−ＲｅｓｔｒｉｃｔｉｏｎＴｉｍｅｒが満了すると、ＭＡＣは、このタイマの設定により遅らされたＳＲをトリガする。ＭＡＣは、ＳＲがトリガされているＢＳＲをトリガするデータを有する論理チャネルにマップされているＳＲ構成を使用してもよい。
【０２０５】
割り当てられたグラントはあるが、使用はできない場合に、ＳＲのトリガを遅らせることをサポートする際に、下記で記載するような、バッファ状態報告（ＢＳＲ）プロシージャを調整することは有利である。
【０２０６】
ＲＲＣは、例えば、ＢＳＲを制御するために、下記パラメータを構成してよい。ｐｅｒｉｏｄｉｃＢＳＲ−Ｔｉｍｅｒ、ｒｅｔｘＢＳＲ−Ｔｉｍｅｒ、ｌｏｇｉｃａｌＣｈａｎｎｅｌＳＲ−Ｄｅｌａｙ、ｌｏｇｉｃａｌＣｈａｎｎｅｌＳＲ−ＤｅｌａｙＴｉｍｅｒ、ｌｏｇｉｃａｌＣｈａｎｎｅｌＧｒｏｕｐ、および、
【０２０７】
ｌｏｇｉｃａｌＣｈａｎｎｅｌＳＲ−ＲｅｓｔｒｉｃｔｉｏｎＴｉｍｅｒ。
【０２０８】
各論理チャネルは、ｌｏｇｉｃａｌＣｈａｎｎｅｌＧｒｏｕｐを使用して、ＬＣＧに割り当てられてよい。ＬＣＧの最大数は８である。
【０２０９】
ＭＡＣエンティティは、TS  38.322および38.323のデータボリューム計算プロシージャに従って、論理チャネルの利用可能なＵＬデータの量を決定する。
【０２１０】
ＭＡＣエンティティが、あるＬＣＧに属する論理チャネルに新しい利用可能なＵＬデータを有し、かつ、その新しいＵＬデータが、いずれかのＬＣＧに属する利用可能なＵＬデータを含んでいる論理チャネルの優先度よりも、高い優先度の論理チャネルに属するか、または、あるＬＣＧに属している論理チャネルのいずれも、利用可能なＵＬデータを含まない場合、ＢＳＲはトリガされてよく、この場合、ＢＳＲは「規則的なＢＳＲ」と下記で称される。
【０２１１】
ＵＬリソースが割り当てられ、かつパディングビットの数が、バッファ状態報告ＭＡＣ  ＣＥにそのサブヘッダを追加したサイズ以上の場合、ＢＳＲはトリガされてよく、この場合、ＢＳＲは「パディングＢＳＲ」と下記で称される。
【０２１２】
ｒｅｔｘＢＳＲ−Ｔｉｍｅｒが満了し、かつＬＣＧに属する論理チャネルの少なくとも１つが、ＵＬデータを含む場合、ＢＳＲはトリガされてよく、この場合、ＢＳＲは「規則的なＢＳＲ」と下記で称される。
【０２１３】
ｐｅｒｉｏｄｉｃＢＳＲ−Ｔｉｍｅｒが満了する場合、ＢＳＲはトリガされ、この場合、ＢＳＲは「周期的なＢＳＲ」と下記で称される。
【０２１４】
規則的なＢＳＲに関しては、上位層によってｌｏｇｉｃａｌＣｈａｎｎｅｌＳＲ−Ｄｅｌａｙが構成されている論理チャネルでＢＳＲがトリガされる場合、ＭＡＣエンティティは、ｌｏｇｉｃａｌＣｈａｎｎｅｌＳＲ−ＤｅｌａｙＴｉｍｅｒを開始または再開してもよい。そうでない場合は、ＭＡＣエンティティは、ｌｏｇｉｃａｌＣｈａｎｎｅｌＳＲ−ＤｅｌａｙＴｉｍｅｒが動作している場合、それを停止してもよい。
【０２１５】
規則的および周期的なＢＳＲに関しては、ＢＳＲが伝送されるときに、複数のＬＣＧが、伝送のために利用可能なデータを有している場合、ＭＡＣエンティティは、伝送のために利用可能なデータを有するすべてのＬＣＧ向けの長いＢＳＲを報告してもよい。そうでない場合、ＭＡＣエンティティは、短いＢＳＲを報告してもよい。
【０２１６】
パディングＢＳＲに関しては、パディングビットの数が、短いＢＳＲにそのサブヘッダを追加したサイズ以上だが、長いＢＳＲにそのサブヘッダを追加したサイズよりも小さい場合、および、ＢＳＲが伝送されるときに複数のＬＣＧが伝送のために利用可能なデータを有している場合、次いで、パディングビットの数が、短いＢＳＲにそのサブヘッダを追加したサイズに等しい場合、ＭＡＣエンティティは、伝送のために利用可能なデータを有する優先度が最も高い論理チャネルで、ＬＣＧの短い短縮ＢＳＲを報告してもよい。
【０２１７】
パディングＢＳＲに関しては、ＢＳＲが伝送されるときに、複数のＬＣＧが、伝送のために利用可能なデータを有しているが、パディングビットの数が、短いＢＳＲにそのサブヘッダを追加したサイズと等しくない場合、ＭＡＣエンティティは、伝送のために利用可能なデータを伴う優先度が最も高い論理チャネルを用いて、ＬＣＧの短い短縮ＢＳＲを報告してもよい。
【０２１８】
パディングＢＳＲに関しては、パディングビットの数が、短いＢＳＲにそのサブヘッダを追加したサイズ以上でないが、長いＢＳＲにそのサブヘッダを追加したサイズよりも小さい場合、ＭＡＣエンティティは、優先度の高い順に従って、かつ、優先度が等しい場合は、ＬＣＧＩＤの小さい順で、伝送のために利用可能なデータを有する論理チャネルで、ＬＣＧの長い短縮ＢＳＲを報告してもよい。
【０２１９】
パディングＢＳＲに関しては、パディングビットの数が、短いＢＳＲにそのサブヘッダを追加したサイズ以上でないが、長いＢＳＲにそのサブヘッダを追加したサイズよりも小さい場合、ＭＡＣエンティティは、短いＢＳＲを報告してもよい。
【０２２０】
パディングＢＳＲに関しては、パディングビットの数が、短いＢＳＲにそのサブヘッダを追加したサイズ以上でないが、長いＢＳＲにそのサブヘッダを追加したサイズよりも小さい場合、および、パディングビットの数が、長いＢＳＲにそのサブヘッダを追加したサイズ以上の場合、ＭＡＣエンティティは、伝送のために利用可能なデータを有するすべてのＬＣＧのために、長いＢＳＲを報告してもよい。
【０２２１】
少なくとも１つのＢＳＲがトリガされたが、キャンセルはされていないと、バッファ状態報告プロシージャで判断する場合、次いで、ＵＬ−ＳＣＨリソースが新しい即座の伝送のために利用可能な場合、ＭＡＣエンティティは、（１）多重化および組み立てプロシージャを命令して、ＢＳＲ  ＭＡＣ  ＣＥを生成し、（２）すべての生成されたＢＳＲが、長いまたは短い短縮ＢＳＲである場合を除き、ｐｅｒｉｏｄｉｃＢＳＲ−Ｔｉｍｅｒを開始または再開し、（３）ｒｅｔｘＢＳＲ−Ｔｉｍｅｒを開始または再開し、（４）動作している場合は、ｌｏｇｉｃａｌＣｈａｎｎｅｌＳＲ−ＲｅｓｔｒｉｃｔｉｏｎＴｉｍｅｒを停止してよい。
【０２２２】
少なくとも１つのＢＳＲがトリガされたが、キャンセルはされていないと、バッファ状態報告プロシージャで判断する場合、次いで、規則的なＢＳＲがトリガされて、ｌｏｇｉｃａｌＣｈａｎｎｅｌＳＲ−ＤｅｌａｙＴｉｍｅｒが動作していない場合、ＭＡＣエンティティは、状態に基づいていくつかの動作をとってもよい。上りリンクグラントが構成されたグラントではないか、または論理チャネルＳＲマスキング（ｌｏｇｉｃａｌＣｈａｎｎｅｌＳＲ−Ｍａｓｋ）が上位層によって設定されている論理チャネルで、規則的なＢＳＲがトリガされなかった場合、次いで、ｌｏｇｉｃａｌＣｈａｎｎｅｌＳＲ−ＲｅｓｔｒｉｃｔｉｏｎＴｉｍｅｒの構成される値が、ＵＥに既に割り当てられたグラントの残りの有効時間以上の場合、ＭＡＣエンティティは、タイマｌｏｇｉｃａｌＣｈａｎｎｅｌＳＲ−ＲｅｓｔｒｉｃｔｉｏｎＴｉｍｅｒを開始または再開してよい。そうでない場合、ＭＡＣエンティティは、スケジューリングリクエストをトリガして、ｌｏｇｉｃａｌＣｈａｎｎｅｌＳＲ−ＲｅｓｔｒｉｃｔｉｏｎＴｉｍｅｒが動作している場合は、それを停止してもよい。
【０２２３】
ｌｏｇｉｃａｌＣｈａｎｎｅｌＳＲ−ＲｅｓｔｒｉｃｔｉｏｎＴｉｍｅｒが満了する場合、ＭＡＣエンティティはスケジューリングリクエストをトリガしてよい。
【０２２４】
たとえ複数のイベントが時間までにＢＳＲをトリガしていても、ＭＡＣ  ＰＤＵは、多くても１つのＢＳＲ  ＭＡＣ  ＣＥを含んでもよい。規則的なＢＳＲおよび周期的なＢＳＲは、パディングＢＳＲよりも優先されてよい。
【０２２５】
任意のＵＬ−ＳＣＨ上の新しいデータの伝送のためのグラントの受信をするとすぐ、ＭＡＣエンティティは、ｒｅｔｘＢＳＲ−Ｔｉｍｅｒを再開してもよい。
【０２２６】
ＵＬグラントが、伝送のために利用可能なすべてのペンディングデータを適用する可能性があるが、追加的にＢＳＲ  ＭＡＣ制御要素にそのサブヘッダを追加したものを適応するのに十分でない場合、すべてのトリガされたＢＳＲがキャンセルされてよい。ＢＳＲが伝送のためのＭＡＣ  ＰＤＵ内に含まれる場合、すべてのトリガされたＢＳＲがキャンセルされてよい。
【０２２７】
ＭＡＣエンティティは、１つのＭＡＣ  ＰＤＵ内の多くても１つのＢＳＲを伝送してもよい。ＭＡＣ  ＰＤＵが、規則的なまたは周期的なＢＳＲを含む場合、パディングＢＳＲは含まれなくてもよい。
【０２２８】
ＭＡＣ  ＰＤＵが組み立てられるときに、すべてのペンディングＳＲがキャンセルされ、ｓｒ−ＰｒｏｈｉｂｉｔＴｉｍｅｒ、ｌｏｇｉｃａｌＣｈａｎｎｅｌＳＲ−ＲｅｓｔｒｉｃｔｉｏｎＴｉｍｅｒが、それぞれ停止されることは、スケジューリングリクエストプロシージャにとって有利である。ＰＤＵは、ＢＳＲをトリガした最後のイベントまで（および、それを含んでいる）のバッファ状態か、またはＵＬグラントが、伝送のために利用可能なすべてのペンディングデータを適用する可能性があるときのバッファ状態を含むＢＳＲを含んでよい。
【０２２９】
重要な別の問題は、複数のＳＲがペンディングされて、ＳＲがまだ送信されていないときに、ペンディングＳＲの利用可能なＳＲ構成の中から、どのＳＲ構成が、使用されるべきかである。
【０２３０】
１つのアプローチは、ＳＲ構成を優先順位付けすることである。ここで、ＭＡＣエンティティは、最も多くの伝送機会を有するＳＲ構成、最も早いすなわち最初の伝送機会を有するＳＲ構成、最も優先度が高い論理チャネルに対応するＳＲ構成、および、例えば、カバレッジが問題となる場合の、長いＰＵＣＣＨフォーマットを有するＳＲ構成、のうちの１つまたは複数を選択するために、ＳＲの構成に基づいて優先度順序を決定してもよい。
【０２３１】
例えば、レイテンシが決定因子である場合の短いＰＵＣＣＨフォーマットを有するＳＲ構成。
【０２３２】
あるいは、ＳＲ構成が優先順位付けされていない場合、各ＳＲは、そのＳＲのためのリソース構成を使用して伝送されてよい。一旦、ＳＲの１つが成功して、ＢＳＲが伝送されると、すべての残りのペンディングＳＲはキャンセルされる。
【０２３３】
重要な別の問題は、ＳＲを送信するＰＵＣＣＨリソースが不足しているか、または、ＳＲ伝送が許容される伝送の最大値に達することにより、ランダムアクセスが開始される場合、グラントがＵＥにとって利用可能になり、例えば、図２または図３に示すように、ＵＥに既に割り当てられたグラントは、ＵＬ伝送のために利用可能になり、ＲＡＣＨプロシージャのトリガおよびキャンセルに対する基準が規定される必要があることである。
【０２３４】
同様に、ＳＲ伝送の遅延に対して、ＲＡＣＨプロシージャを遅らせることは有利である。
【０２３５】
ＳＲを伝送するのに利用可能なＰＵＣＣＨリソースがないか、ＳＲ伝送が、3GPP  TS  38.321  NR  Medium  Access  Control  (MAC)  protocol  specification,  V15.0.0での、パラメータｓｒ−ＴｒａｎｓＭａｘによって、現在、規定されているスケジューリングリクエスト伝送の最大数に達したときに、特に現在の仕様に従って、即座にトリガされるＲＡＣＨプロシージャの開始を遅らせるのに使用される、ＲＡＣＨプロシージャ開始制約タイマｌｏｇｉｃａｌＣｈａｎｎｅｌＲＡＣＨ−ＲｅｓｔｒｉｃｔｉｏｎＴｉｍｅｒを使用することは、有利である。タイマｌｏｇｉｃａｌＣｈａｎｎｅｌＲＡＣＨ−ＲｅｓｔｒｉｃｔｉｏｎＴｉｍｅｒは、論理チャネルごとに構成される。ＲＲＣは、ＭＡＣエンティティにタイマを構成する。タイマの値の単位は、ＯＦＤＭシンボル、スロット、または、例えば、ミリ秒またはマイクロ秒などの絶対時間値であってもよい。ｌｏｇｉｃａｌＣｈａｎｎｅｌＲＡＣＨ−ＲｅｓｔｒｉｃｔｉｏｎＴｉｍｅｒＤｕｒａｔｉｏｎは、タイマｌｏｇｉｃａｌＣｈａｎｎｅｌＲＡＣＨ−ＲｅｓｔｒｉｃｔｉｏｎＴｉｍｅｒの構成される値（すなわち、時間長）を表す。
【０２３６】
トリガされ、ペンディングされ、ＳＲ伝送のために利用可能なＰＵＣＣＨリソースがないか、または、3GPP  TS  38.321  NR  Medium  Access  Control  (MAC)  protocol  specification,  V15.0.0でのパラメータｓｒ−ＴｒａｎｓＭａｘによって、現在、規定されているＳＲ繰り返しの最大数にＳＲ伝送の数が達する場合、ＭＡＣはタイマを開始する。
【０２３７】
Ｈ（ｒ）以上の条件ｌｏｇｉｃａｌＣｈａｎｎｅｌＲＡＣＨ−ＲｅｓｔｒｉｃｔｉｏｎＴｉｍｅｒＤｕｒａｔｉｏｎを満たす、ＵＥに割り当てられたＵＬ−ＳＣＨグラントｒがある場合、ＭＡＣはまた、タイマを開始する。
【０２３８】
ＵＬ−ＳＣＨリソースグラントｒを使用して、ＢＳＲが伝送される場合、ＭＡＣエンティティは、タイマｌｏｇｉｃａｌＣｈａｎｎｅｌＲＡＣＨ−ＲｅｓｔｒｉｃｔｉｏｎＴｉｍｅｒをキャンセルする。別の代替的実施形態では、ＵＬ−ＳＣＨグラントｒを使用して、（図２または図３に図示されているように）ＢＳＲをトリガする論理チャネルＬＣＨ２のデータが伝送される場合、ＭＡＣエンティティは、タイマｌｏｇｉｃａｌＣｈａｎｎｅｌＲＡＣＨ−ＲｅｓｔｒｉｃｔｉｏｎＴｉｍｅｒをキャンセルする。
【０２３９】
タイマｌｏｇｉｃａｌＣｈａｎｎｅｌＲＡＣＨ−ＲｅｓｔｒｉｃｔｉｏｎＴｉｍｅｒが満了すると、ＭＡＣは、このタイマの設定により遅らされたＲＡＣＨプロシージャをトリガする。
【０２４０】
ＲＡＣＨプロシージャのキャンセルに関しては、ランダムアクセス応答（Random  Access  Response：ＲＡＲ）メッセージがＵＥによって受信される前に、ＰＵＣＣＨリソースがＳＲの伝送のために利用可能になるか、ＢＳＲ伝送のためのＵＬ−ＳＣＨリソースが利用可能になる場合、ＳＲによってトリガされるＲＡＣＨプロシージャをキャンセルすることは有利である。
【０２４１】
（課題６に対するソリューション−バッファ状態計算に対するさらなる拡張）
２つ以上の重複するＵＬ−ＳＣＨリソースグラントが存在する場合のバッファ状態計算に対処するソリューションについて、以下で説明する。
【０２４２】
図４から８に示す、リソースグラント計算の例は、以下のバッファ状態決定に関連する重要な属性のうち１つまたは複数のものによって特徴付けられてよい。
【０２４３】
ケース１では、（例えば、図５または図６の、ＬＣＨ２のＵＬ伝送が、タイムスロット１０にある場合）各グラントの各ＵＬデータ伝送時間が、重複し、同時に終了する。
【０２４４】
ケース２では、（例えば、図４、図６、または図７の、ＬＣＨ２のＵＬ伝送が、タイムスロット９にある場合）各グラントの各ＵＬデータ伝送時間が、重複し、別々に終了する。
【０２４５】
ケース３では、（例えば、図８の）グラントのＵＬデータ伝送時間は、重複しないが、グラントがＵＥに割り当てられた時間から開始して、グラントがＵＥによる伝送に使用される時間までの時間間隔が、グラント間で重複する。
【０２４６】
（ケース１）
ケース１では、各グラントの各ＵＬデータ伝送時間が、重複し、同時に終了する。ＢＳＲに使用されるバッファ状態およびグラントを決定するために、以下の規則が提案される。
【０２４７】
グラントのＵＬデータ伝送時間が同時に終了するので、すべての利用可能なＵＬ−ＳＣＨグラントが、使い果たされた後に、ＭＡＣエンティティが、ＭＡＣ伝送バッファ内の残りのすべてのデータを考慮に入れてバッファ状態を決定することは、有利である。ＢＳＲの送信に使用されるグラントに関しては、無線エアインターフェースリソースの使用を最大化するために、ＭＡＣエンティティが複数のグラントに対してＢＳＲを分散することを決定することが提案される。あるいは、ＢＳＲは、単一のグラントを用いて伝送されてよい。あるいは、別の方法としては、ＭＡＣエンティティは、利用可能なＵＬグラント全体にわたってＢＳＲを分割してもよい。すなわち、例えば、２つのグラントが重複する場合、ＢＳＲは、２つのＢＳＲに分割されてよく、ここで、２つのＢＳＲのうち１つは、２つのグラントのうち１つを介して伝送され、もう１つのＢＳＲは、その他のグラントを介して伝送される。「複数のＢＳＲ、例えば、２つのＢＳＲにＢＳＲを分割する」という用語または表現は、本明細書では、ＭＡＣエンティティが、バッファ状態を計算または決定し、決定したバッファ状態を使用して複数のＢＳＲを作成し、作成されたすべてのＢＳＲにわたるバッファサイズの総合計が、複数のＢＳＲに分割されるバッファ状態のサイズと等しいことを表すために使用されることを理解されたい。
【０２４８】
各ＢＳＲに含まれるＬＣＧは、ＵＬグラントの優先順位に依存してもよい。例えば、２つのＵＬグラントが利用可能で、グラント１が、グラント２よりも優先度の高い場合を考慮する場合、グラント１を使用して伝送されるＢＳＲは、グラント１の優先度以上の優先度のＬＣＧについてのバッファ状態情報を含んでもよく、グラント２を使用して伝送されるＢＳＲは、残りのＬＣＧ（すなわち、グラント１の優先度よりも低い優先度のＬＣＧ）についてのバッファ状態情報を含んでもよい。
【０２４９】
Ｎ個のグラントが利用可能であるより一般的なケースの場合、この方法を拡張することができる。例証の目的のために、最も高い優先度グラントとなるＵＬグラント１と、最も低い優先度グラントとなるＵＬグラントＮを用いて、優先度の順に番号付けされた複数のグラントを想定する。ＵＬグラント１を使用して伝送されるＢＳＲは、Ｐｒｉｏｒｉｔｙ（ＬＣＧｉ）≧Ｐｒｉｏｒｉｔｙ（ｇｒａｎｔ１）のＬＣＧのバッファ状態情報を含み、ＵＬグラントｎ（ここで、１＜ｎ＜Ｎ）を使用して伝送されるＢＳＲは、Ｐｒｉｏｒｉｔｙ（ｇｒａｎｔｎ−１）＞Ｐｒｉｏｒｉｔｙ（ＬＣＧｉ）≧Ｐｒｉｏｒｉｔｙ（ｇｒａｎｔｎ）のＬＣＧのバッファ状態情報を含み、グラントＮを使用して伝送されるＢＳＲは、Ｐｒｉｏｒｉｔｙ（ＬＣＧｉ）＜Ｐｒｉｏｒｉｔｙ（ｇｒａｎｔＮ−１）のＬＣＧのバッファ状態情報を含む。
【０２５０】
このコンテキストでのＬＣＧｉの優先度は、ＬＣＧｉにおける、伝送のために利用可能なデータを有する、最も高い優先度の論理チャネルの優先度として定義されてよい。
【０２５１】
グラントの優先度は、グラントに関連付けられたニューメロロジーのサブキャリア間隔（SubCarrier  Spacing：ＳＣＳ）を基準にして、定義されてもよい。例えば、グラントは、それらのＳＣＳの値に従って、優先順位付けられてよく、ここで、ＳＣＳの値が高いほど、グラントの優先度は高くなる。
【０２５２】
グラントへのＢＳＲの割り当ては、以下の規則に従って行われる。ＬＣＧｉの優先度が、ＬＣＧｊの優先度以上の場合、ＬＣＧｉのバッファ情報は、ＬＣＧｊのバッファ情報を搬送するグラント以上の優先度のグラントで伝送される必要がある。
【０２５３】
（ケース２）
ケース２では、各グラントの各ＵＬデータ伝送時間が、重複し、別々に終了する。
【０２５４】
一実施形態では、このケースでは、最後に終了するＵＬ伝送時間を有するグラントが、使い果たされた後に、ＭＡＣエンティティが、バッファ状態を、ＭＡＣ伝送バッファの利用可能なすべてのデータとして決定することが提案される。このケースでは、ＭＡＣエンティティは、１つのＢＳＲのみを伝送し、そのＢＳＲは、伝送時間が最後に終了するＵＬ−ＳＣＨグラントを用いて伝送される。重複しているすべてのグラントにわたるＵＬ伝送の時間長が、ＵＬ伝送が最初に始まるリソースグラントを用いるＵＬ伝送の開始から、ＵＬ伝送が最後に終了するリソースグラントを用いるＵＬ伝送の最後までの経過時間であることが、この提案の合理的なものである。したがって、従来のＬＴＥシステムのものと類似するが、異なるメカニズムは、例えば、最後に終了するＵＬ伝送時間を有するグラントが使い果たされた後に、ＭＡＣエンティティに、バッファ状態を、ＭＡＣ伝送バッファの利用可能なすべてのデータとして決定させて、伝送時間が最後に終了するＵＬ−ＳＣＨグラントを用いてＢＳＲを伝送させるものである。
【０２５５】
別の代替的実施形態は、各グラントの各ＵＬ伝送時間の終了後に、ＭＡＣエンティティに、バッファ状態を、ＭＡＣ伝送バッファの利用可能なすべてのデータとして決定させ、そのグラントを使用して対応するバッファ状態報告を伝送させることである。これは、ＢＳＲの一部として報告されるいくつかのデータまたはすべてのデータの伝送に続いて使用される可能性のあるペンディングリソースグラントがＵＥ内にあるために、不要なバッファ状態報告または必要とされるよりも多いバッファ状態報告のために、エアインターフェース無線リソースが不要に使用され、バッファ状態が過剰に報告されることを意味するので、多少非効率である可能性がある。しかし、これは、バッファ状態の決定および報告のために実行可能なアプローチである。ｇＮＢが、ＵＥでのすべてのペンディングＵＬリソースグラント（すなわち、ＵＥに割り当てられ、さらに、ＵＥによるＵＬデータ伝送に使用されることになっている、ＵＬリソースグラント）を認識しているので、このアプローチは、結果として、ｇＮＢのＵＥへのＵＬリソースグラントの過剰な割り当てに必ずしもならないこともあるという点に留意するべきである。このスキームでは、ｇＮＢがＢＳＲをＵＥから受信すると、ｇＮＢは報告を介してバッファ状態を認識し、過剰に報告されるバッファ状態の一部に対するＵＬグラントの割り当てを回避することができる。この実施形態では、複数のＢＳＲを伝送することができる。
【０２５６】
別の代替的実施形態は、伝送時間が後で終了する、残りのグラントを用いて伝送される可能性のあるデータの推定なしに、各グラントの各ＵＬ伝送時間の終了後に、ＭＡＣエンティティに、バッファ状態を、ＭＡＣ伝送バッファの利用可能なすべてのデータとして決定させ、そのグラントを使用して対応するバッファ状態報告を伝送させることである。この実施形態では、複数のＢＳＲを伝送することができる。
【０２５７】
別の代替的実施形態では、最初に終了するＵＬ伝送時間を有するグラントが使い果たされた後に、ＭＡＣエンティティが、バッファ状態を、ＭＡＣ伝送バッファの利用可能なすべてのデータとして決定することが提案される。このケースでは、ＭＡＣエンティティは、１つのＢＳＲのみを伝送し、そのＢＳＲは、伝送時間が最初に終了するＵＬ−ＳＣＨグラントを用いて伝送される。あるいは、バッファ状態の推定に関して、ＭＡＣエンティティは、残りのグラントを用いて伝送される可能性のあるデータの推定なしに、最初に終了するＵＬ伝送時間を有するグラントが使い果たされた後に、バッファ状態をＭＡＣ伝送バッファの利用可能なすべてのデータとして決定する。
【０２５８】
（ケース３）
ケース３では、グラントのＵＬデータ伝送時間は、重複しないが、グラントがＵＥに割り当てられた時間から開始して、グラントがＵＥによる伝送に使用される時間までの時間間隔が、グラント間で重複する。
【０２５９】
一実施形態では、最初に終了するＵＬ伝送時間を有するグラントが使い果たされた後に、ＭＡＣエンティティが、バッファ状態を、ＭＡＣ伝送バッファの利用可能なすべてのデータとして決定することは、有利である。ＭＡＣエンティティは、１つのＢＳＲのみを伝送し、そのＢＳＲは、ＵＬ伝送時間が最初に終了するグラントを用いて伝送される。
【０２６０】
代替的な一実施形態では、最初に終了するＵＬ伝送時間を有するグラントが使い果たされた後に、最初に終了するＵＬ伝送時間を有するグラントが使い果たされた後に、伝送時間が開始する残りの重複していないグラントを用いて伝送される可能性のあるデータの推定なしに、バッファ状態を、ＭＡＣ伝送バッファの利用可能なすべてのデータとして決定することは、有利である。ＭＡＣエンティティは、１つのＢＳＲのみを伝送し、そのＢＳＲは、ＵＬ伝送時間が最初に終了するグラントを使用して伝送される。
【０２６１】
代替的な一実施形態では、最後に終了するＵＬ伝送時間を有するグラントが使い果たされた後に、ＭＡＣエンティティが、バッファ状態を、ＭＡＣ伝送バッファの利用可能なすべてのデータとして決定することは、有利である。ＭＡＣエンティティは、１つのＢＳＲのみを伝送し、そのＢＳＲは、ＵＬ伝送時間が最後に終了するグラントを用いて伝送される。
【０２６２】
さらに別の代替的な実施形態では、最初に終了するＵＬ伝送時間を有するグラントが使い果たされた後に、バッファ状態を、ＭＡＣ伝送バッファの利用可能なすべてのデータとして決定することは、有利である。ＭＡＣエンティティは、１つのＢＳＲのみを伝送し、そのＢＳＲは、ＵＬ伝送時間が最初に終了するグラントを使用して伝送される。
【０２６３】
別の代替的実施形態では、トリガされたがキャンセルはされていないＢＳＲの伝送を、次のグラントで遅延し、伝送できる（すなわち、ＭＡＣエンティティがＢＳＲ伝送機会をスキップできる）ことは、有利である。特に、即座にトリガされるＳＲの伝送を、遅らせるために使用される、ＢＳＲ制約タイマ、ｌｏｇｉｃａｌＣｈａｎｎｅｌＢＳＲ−ＲｅｓｔｒｉｃｔｉｏｎＴｉｍｅｒを導入することは、有利である。タイマｌｏｇｉｃａｌＣｈａｎｎｅｌＢＳＲ−ＲｅｓｔｒｉｃｔｉｏｎＴｉｍｅｒは、ＭＡＣエンティティごとに構成される。ＲＲＣは、ＭＡＣエンティティにタイマを構成する。タイマの値の単位は、ＯＦＤＭシンボル、スロット、ミニスロット、または、例えば、ミリ秒またはマイクロ秒などの絶対時間値であってもよい。ｌｏｇｉｃａｌＣｈａｎｎｅｌＢＳＲ−ＲｅｓｔｒｉｃｔｉｏｎＴｉｍｅｒＤｕｒａｔｉｏｎは、タイマｌｏｇｉｃａｌＣｈａｎｎｅｌＢＳＲ−ＲｅｓｔｒｉｃｔｉｏｎＴｉｍｅｒの構成される値（すなわち、時間長）を表す。
【０２６４】
（１）ＢＳＲがトリガされたがキャンセルはされていないか、または（２）Ｈ（ｒ）以上の条件ｌｏｇｉｃａｌＣｈａｎｎｅｌＢＳＲ−ＲｅｓｔｒｉｃｔｉｏｎＴｉｍｅｒＤｕｒａｔｉｏｎを満たす、ＵＥに割り当てられたＵＬ−ＳＣＨグラントｒがある場合、ＭＡＣは、ＢＳＲ伝送を遅らせて、タイマｌｏｇｉｃａｌＣｈａｎｎｅｌＢＳＲ−ＲｅｓｔｒｉｃｔｉｏｎＴｉｍｅｒを開始する。
【０２６５】
ＭＡＣエンティティは、ＢＳＲが伝送されるときに、タイマｌｏｇｉｃａｌＣｈａｎｎｅｌＢＳＲ−ＲｅｓｔｒｉｃｔｉｏｎＴｉｍｅｒをキャンセルする。別の代替的実施形態では、ＢＳＲをトリガするデータが伝送される場合、ＭＡＣエンティティはタイマｌｏｇｉｃａｌＣｈａｎｎｅｌＢＳＲ−ＲｅｓｔｒｉｃｔｉｏｎＴｉｍｅｒをキャンセルする。
【０２６６】
タイマｌｏｇｉｃａｌＣｈａｎｎｅｌＢＳＲ−ＲｅｓｔｒｉｃｔｉｏｎＴｉｍｅｒが満了すると、ＭＡＣはＢＳＲをトリガする。
【０２６７】
この代替的実施形態はまた、上述した例、重複するグラントのケース２にも適用することができるという点に留意すべきである。
【０２６８】
ＳＲに対する別の拡張について、本明細書に記載される。ＳＲが失敗する可能性のあるいくつかの原因としては、ＤＬ同期またはＵＬ同期の喪失（例えば、ＬＴＥ仕様の通りに、ＵＥがもはや同期していないときに、ＳＲのためのＰＵＣＣＨリソースが失われる）、ＳＲのために構成されるＰＵＣＣＨリソースでの干渉、およびＵＥによる誤ったＰＵＣＣＨ伝送電力計算をもたらす、誤ったパス損失推定が挙げられるが、これらに限定されない。上記の理由のいずれかは、特定のセルまたはセルのグループに依存している場合があるが、必ずしも特定のＰＵＣＣＨリソースに依存しているとは限らない。例えば、ＵＥは、構成されたタイミングアドバンスグループ（ＴＡＧ）によって、規定されるようなセルグループごとの同期を管理してもよい。同期の喪失に関連するＰＵＣＣＨの問題によってもたらされるＳＲ障害は、同じＴＡＧに関連する同じセルグループで構成されるすべてのＳＲ  ＰＵＣＣＨリソースに共通である可能性がある。同様に、例えば、ＰＵＣＣＨリソース上の干渉または誤ったパス損失推定が原因のＳＲ障害は、セル固有またはセルグループ固有の可能性がある。
【０２６９】
追加として、ＮＲでは、セルのキャリア帯域幅は、複数の帯域幅パート（ＢＷＰ）を用いて構成される場合がある。ＳＲ障害はまた、ＢＷＰ固有のものである可能性もある。
【０２７０】
したがって、ＳＲ障害タイプを規定して、ＳＲ伝送カウンタがＳＲ構成に対して最大値に達すると、特定のＳＲ障害タイプを宣言することが提案される。ＳＲ構成固有のＳＲ障害、失敗したＳＲのリソースが構成されているＢＷＰ固有のＳＲ障害、および失敗したＳＲのリソースが構成されているセル固有のＳＲ障害などのＳＲ障害タイプが、考慮されてよい。障害タイプは、規格においてハードコードされてもよい。代替的実施形態では、障害タイプに対するＳＲ障害をどのようにＵＥが解釈するかは、ネットワークによって構成される。
【０２７１】
ＳＲ障害時のＵＥ動作について、本明細書に記載される。ＳＲ構成に関連付けられたＳＲ伝送カウンタ（ＳＲ＿ＣＯＵＮＴＥＲ）が、最大ＳＲ伝送（ｄｒｓ−ＴｒａｎｓＭａｘ）に達すると、ＭＡＣがＲＲＣに通知して失敗したＳＲのＳＲ構成のためのＰＵＣＣＨを解放する、ＭＡＣがＲＲＣに通知して失敗したＳＲのリソースが構成されているサービングセルのＰＵＣＣＨを解放する、ＭＡＣがＲＲＣに通知して失敗したＳＲのリソースが構成されているサービングセルのタイミングアドバンスグループ（ＴＡＧ）内のすべてのサービングセルのＰＵＣＣＨを解放する、および、ＭＡＣがＲＲＣに通知して失敗したＳＲのリソースが構成されているＢＷＰのＰＵＣＣＨを解放する、のうち１つの動作を、ＵＥはとってもよい。ＵＥは、特定のＳＲ障害タイプ、またはＵＥがそれを用いて構成されている障害タイプの粒度に応じて、上記の動作のいずれかを実施してもよい。例えば、ＵＥは、特定のＳＲ障害タイプに応じて以下の動作をとるか、またはＵＥが以下のことを用いて構成されているＳＲ障害タイプに応じて以下の動作をとってもよい。ＵＥがＳＲ障害タイプ「ＳＲ構成固有のＳＲ障害」を用いて構成されている場合、ＭＡＣは、ＲＲＣに通知して、失敗したＳＲのＳＲ構成のためのＰＵＣＣＨを解放してもよい。ＵＥがＳＲ障害タイプ「失敗したＳＲのリソースが構成されているセル固有のＳＲ障害」を用いて構成されている場合、ＭＡＣは、ＲＲＣに通知して、失敗したＳＲのリソースが構成されているサービングセルのＰＵＣＣＨを解放してもよい。ＵＥがＳＲ障害タイプ「失敗したＳＲのリソースが構成されているセル固有のＳＲ障害」を用いて構成されている場合、ＭＡＣは、ＲＲＣに通知して、失敗したＳＲのリソースが構成されているサービングセルのタイミングアドバンスグループ（ＴＡＧ）内のすべてのサービングセルのＰＵＣＣＨを解放する（例えば、ＵＥがＵＬ同期の喪失を検出する場合も、ＵＥはこの動作をとってよい）。また、ＵＥがＳＲ障害タイプ「ＭＡＣがＲＲＣに通知して、失敗したＳＲのリソースが構成されているＢＷＰのＰＵＣＣＨを解放する」を用いて構成されている場合、ＭＡＣは、ＲＲＣに通知して、失敗したＳＲのリソースが構成されているＢＷＰのＰＵＣＣＨを解放してもよい。
【０２７２】
ＵＥによるｇＮＢへのＳＲ障害とＰＵＣＣＨ解放のシグナリングについて、本明細書に記載される。ＵＥは、以下の方法のうち１つを使用して、ＳＲ障害およびＰＵＣＣＨ解放をｇＮＢへシグナリングしてよい。
【０２７３】
ＲＲＣプロシージャについて、本明細書に記載される。ＵＥがネットワークに、ＳＲ障害を報告して、ＰＵＣＣＨ解放をリクエストするように、新しいＲＲＣメッセージが定義されてよい。このようなメッセージは、ＰＵＣＣＨＦａｉｌｕｒｅＲｅｐｏｒｔ、ＰＵＣＣＨＳｔａｔｕｓＲｅｐｏｒｔ、ＰＵＣＣＨＲｅｅｓｔａｂｌｉｓｈｍｅｎｔ、ＰＵＣＣＨＦａｉｌｕｒｅＩｎｆｏｒｍａｔｉｏｎなどと呼ばれてもよい。メッセージは、ＲＲＣトランザクション識別子およびＳＲ構成インデックス（ｓｒ−ＣｏｎｆｉｇＩｎｄｅｘ）を含んでもよい。追加として、失敗したＳＲに使用されたリソースのインデックス（ｓｒ−ＰＵＣＣＨ−ＲｅｓｏｕｒｃｅＩｎｄｅｘ）が、メッセージに含まれてもよい。ＵＥは、ＲＬＣ  ＡＭモードで、シグナリング無線ベアラＳＲＢ１上でメッセージを送信してよい。あるいは、ＳＲ障害情報およびＰＵＣＣＨ解放リクエストが、既存のＵＥからｇＮＢへのＲＲＣメッセージを使用して、ｇＮＢにシグナリングされてよい。このようなメッセージは、新しいメッセージコード、ならびに、ＳＲ構成インデックス（ｓｒ−ＣｏｎｆｉｇＩｎｄｅｘ）、およびメッセージに含まれてもよい失敗したＳＲに使用されたリソースのインデックス（ｓｒ−ＰＵＣＣＨ−ＲｅｓｏｕｒｃｅＩｎｄｅｘ）などの情報要素を含んでもよい。
【０２７４】
ＭＡＣプロシージャについて、本明細書に記載される。ＲＡＣＨプロシージャを使用して、ｇＮＢに、ＳＲ障害を報告し、ＰＵＣＣＨ解放をリクエストしてもよい。ＵＥは、ＲＡＣＨメッセージ３（Ｍｓｇ３）に、失敗したＳＲをトリガする論理チャネルに対応するＢＳＲを含んでもよい。ｇＮＢは、論理チャネル、したがって、失敗したＳＲの構成、および解放されるべきＰＵＣＣＨを、受信したＢＳＲから暗に導き出してもよい。
【０２７５】
別の実施形態では、ＲＡＣＨ  Ｍｓｇ３は、失敗したＳＲリソースの識別子、例えば、ＳＲ構成インデックス（ｓｒ−ＣｏｎｆｉｇＩｎｄｅｘ）および／または失敗したＳＲのために使用されたリソースのインデックス（ｓｒ−ＰＵＣＣＨ−ＲｅｓｏｕｒｃｅＩｎｄｅｘ）を明確に搬送してもよい。ＵＥはこの情報を使用して、ｇＮＢに失敗したＳＲおよび解放されるべきＰＵＣＣＨを知らせる。
【０２７６】
別の実施形態では、ＵＥはＲＡＣＨリソースとＰＵＣＣＨリソース（例えば、ＳＲ  ＰＵＣＣＨリソース）との関連付けを用いて構成されてよい。ＵＥは、失敗したＳＲのＰＵＣＣＨリソースに関連付けられたＲＡＣＨリソースで、ＲＡＣＨメッセージ１（Ｍｓｇ１）を伝送してもよい。ｇＮＢは、ＲＡＣＨ  Ｍｓｇ１がその上で受信されるＲＡＣＨリソースに基づいて、失敗したＰＵＣＣＨリソース、すなわち、失敗したＳＲ、および解放されるべきＰＵＣＣＨを識別する。
【０２７７】
ＵＥは、失敗したＳＲのリソースが構成されているサービングセルでのＲＡＣＨプロシージャを開始することができる。しかし、ＬＴＥシステムでは、セカンダリセル（ＳＣｅｌｌ）でのランダムアクセスプロシージャが、ｅＮＢからのＰＤＣＣＨ命令によってのみ開始することができる。ＰＵＣＣＨリソースは、任意のセカンダリサービングセルで構成されてもよいので、ＮＲシステムでは、特定の理由で、または一定の基準が満たされるときに、ＵＥが、ＳＣｅｌｌでのＲＡＣＨプロシージャを開始できることは、有利である。例えば、ＳＲ障害が発生するときに、ＵＥは、ＳＣｅｌｌでのＲＡＣＨプロシージャを開始して、ＳＲ障害およびＰＵＣＣＨ解放のリクエストをシグナリングしてよい。ｇＮＢは、ＵＥが（ＰＤＣＣＨ命令なしに）開始したＳＣｅｌｌでのＲＡＣＨプロシージャの受信を、そのＳＣｅｌｌでの、ＳＲ障害のインジケーション、およびＰＵＣＣＨの解放のリクエストとして解釈してもよい。
【０２７８】
例えば、一実施形態では、ＵＥによるｇＮＢへのＳＲ障害および／またはＰＵＣＣＨリソースの解放のシグナリングのために確保されているＲＡＣＨリソースを用いて、ＵＥは、構成されてよい。ｇＮＢは、まず、ＳＲ障害のシグナリングのために確保されているＲＡＣＨリソースでのＲＡＣＨプロシージャＭｓｇ１の受信によって、ＳＲ障害について知らされてよい。ｇＮＢがＲＡＣＨプロシージャＭｓｇ５を受信することによる、コンテンションレゾリューション時、ｇＮＢは、（ＰＤＣＣＨ命令なしに）ＳＣｅｌｌでのＲＡＣＨプロシージャを開始するＵＥを識別する。さらに別の実施例では、ＳＲ障害のシグナリングのために確保されているＲＡＣＨリソースが、ＵＥ専用のＲＡＣＨリソースの場合、ｇＮＢは、ＲＡＣＨプロシージャＭｓｇ１の受信に応じて、（ＰＤＣＣＨ命令なしに）ＳＣｅｌｌでのＲＡＣＨプロシージャを開始するＵＥを識別する。
【０２７９】
ＰＢＲハンドリングおよび変数Ｂｊのメンテナンスに対するさらなる拡張を含む可能性がある、ＬＣＰに対する拡張について、本明細書に記載される。固定時間長の基本ＮＲ時間単位（ＮＲ−ＵＮＩＴ）が、ＭＡＣオペレーションをサポートする際に検討される可能性がある。基本時間単位は、ＭＡＣエンティティレベルにおける最小の時間分解能である場合があり、ＭＡＣオペレーションを作動させる、システムタイマ割り込み間の時間間隔と見なされることがある。すべてのＮＲ−ＵＮＩＴで、ＭＡＣエンティティは、例えば、ＤＬグラント受信、ＵＬグラント受信、ＤＬデータ受信、論理チャネル優先順位付けを含むＵＬデータ伝送、ＨＡＲＱフィードバックのシグナリング、スケジューリングリクエストのシグナリングなどの実行されるべきペンディングタスクがあるかどうかを確認してもよい。ＮＲでは、ＵＬグラントが利用可能である連続するデータ伝送機会の間の時間間隔は、可変である可能性がある。ＤＴＴＩを使用して、連続するデータ伝送機会の間の時間間隔を表す場合がある。ＤＴＴＩは、ＮＲ＿ＵＮＩＴに換算して、例えば、次式（３）で、表されることがある（式中、パラメータｄは可変の整数である）。
【数３】
2020524439.tif 000005
【０２８０】
新しい伝送が実施されるたびに、論理チャネル優先順位付けプロシージャが適用されてよい。
【０２８１】
ＲＲＣは、優先度の値が大きいほど優先度のレベルが低い優先度、優先順位付けされたビットレート（ＰＢＲ）をセットするｐｒｉｏｒｉｔｉｓｅｄＢｉｔＲａｔｅ、バケットサイズ長（ＢＳＤ）をセットするｂｕｃｋｅｔＳｉｚｅＤｕｒａｔｉｏｎを、ＭＡＣエンティティごとに、各論理チャネルについてシグナリングすることによって、上りリンクデータのスケジューリングを制御してもよい。
【０２８２】
ＭＡＣエンティティは、本明細書に記載される実施形態のうちの１つに従って、各許可された論理チャネルｊの変数Ｂｊを管理してもよい。
【０２８３】
変数Ｂｊを管理するための一実施形態では、変数Ｂｊは、関連する論理チャネルが確立されるときに０に初期化され、論理チャネルｊでのデータ伝送機会ごとに、ＰＢＲ×ＤＴＴＩ（ｊ）の積によってインクリメントされ、ここで、ＰＢＲは論理チャネルｊの優先順位付けされたビットレートであり、ＤＴＴＩ（ｊ）は、論理チャネルＬＣＨ＿ｊでの最後のデータ伝送と、論理チャネルＬＣＨ＿ｊの現在のデータ伝送機会との間の時間間隔である。論理チャネルｊの伝送機会は、論理チャネルｊを作動することができるグラントを用いるＵＬデータ伝送の瞬間として定義されてよい。しかし、Ｂｊの値は、バケットサイズを超えることはできず、Ｂｊの値が論理チャネルｊのバケットサイズよりも大きい場合は、Ｂｊの値はバケットサイズに設定されてよい。論理チャネルのバケットサイズは、ＰＢＲ×ＢＳＤに等しくてもよい。いつＢｊが更新されるかはＵＥの実装形態による。
【０２８４】
変数Ｂｊを管理するための別の実施形態では、変数Ｂｊは、関連する論理チャネルが確立されるときに０に初期化され、論理チャネルｊでのデータ伝送機会ごとに、ＰＢＲ×ＤＴＴＩ（ｊ）の積によってインクリメントされ、ここで、ＰＢＲは論理チャネルｊの優先順位付けされたビットレートであり、ＤＴＴＩ（ｊ）は、論理チャネルＬＣＨ＿ｊでの最後のデータ伝送と、論理チャネルＬＣＨ＿ｊの現在のデータ伝送機会との間の時間間隔である。論理チャネルｊのデータ伝送機会は、論理チャネルｊのデータがそのグラントを用いて実際に伝送される場合のグラントを伴うＵＬデータ伝送の瞬間として定義される。しかし、Ｂｊの値は、バケットサイズを超えることはできず、Ｂｊの値が論理チャネルｊのバケットサイズよりも大きい場合は、Ｂｊの値はバケットサイズに設定されてよい。論理チャネルのバケットサイズは、ＰＢＲ×ＢＳＤに等しい。いつＢｊが更新されるかはＵＥの実装形態による。
【０２８５】
論理チャネル選択に対するさらなる拡張について、本明細書に記載される。ＬＣＰプロシージャがサポートされる際に、論理チャネルは、グラントがその中にある必要がある許容されるレイテンシとともに構成されてよい。許容されるレイテンシは、残りのＨＡＲＱ動作点と組み合わせられるＴｍｉｎ／Ｔｍａｘによって画定された時間間隔によって定義されてよい。論理チャネルと関連付けられているサービスの目標平均ブロック誤り率（ＢＬＥＲ）を達成するために、残りのＨＡＲＱ動作点は、予想される再伝送の残りの数の全体にわたる許容可能なＢＬＥＲの組み合わせによって表されてよい。新しい伝送が実施されるときにＬＣＰプロシージャが実施されるので、残りのＢＬＥＲは目標ＢＬＥＲと同じでもよい。すべての新しい伝送において、論理チャネルにマップされているサービスの目標ＢＬＥＲを達成するために、ＵＥは予想される再伝送の数を推定してもよい。目標ＢＬＥＲは、最も厳密な目標ＢＬＥＲ（すなわち、論理チャネルにマップされているサービス全体にわたる最小の目標ＢＬＥＲ値）であってよい。ＵＥは、推定された再伝送の数を考慮に入れた換算係数によって、許容される下限時間レイテンシＴｍｉｎと、許容される上限時間レイテンシＴｍａｘをスケーリングしてもよい。異なる再伝送数が、異なる換算係数に関連付けられる場合、複数の換算係数が定義されてよい。さらに、異なる換算係数が、パラメータＴｍｉｎおよびパラメータＴｍａｘに対して定められてもよい。ＵＥは換算係数を用いて構成されてよい。あるいは、換算係数および再伝送数のマッピングは、仕様においてハードコードされてもよい。さらにもう１つの選択肢として、換算係数の選択および再伝送数のマッピングは、実装形態に任せられてもよい。
【０２８６】
ＭＡＣは、ＬＣＰプロシージャの間、パラメータＴｍｉｎおよびパラメータＴｍａｘに適切な換算係数を乗じることによって、ＴｍｉｎおよびＴｍａｘのスケーリング操作を実施してもよい。
【０２８７】
レイテンシ要件の観点から、論理チャネルの許容されるスケーリングされたレイテンシＴｍｉｎおよびＴｍａｘの範囲内にグラントの処理タイミングがある場合、ＵＥ  ＭＡＣは、グラントによって論理チャネルが作動されてもよいと判断してもよい。
【０２８８】
別の実施形態では、グラントは、時間間隔Ｔｍｉｎ（グラント）およびＴｍａｘ（グラント）によって画定された処理レイテンシに関連付けられてよい。すべての新しい伝送で、許可された論理チャネルにマップされているサービスの目標ＢＬＥＲを達成するために、ＵＥは予想される再伝送の数を推定してもよい。目標ＢＬＥＲは、最も厳密な目標ＢＬＥＲ、すなわち、論理チャネルにマップされているサービス全体にわたる最小の目標ＢＬＥＲ値であってよい。ＵＥは、推定された再伝送の数を考慮に入れた換算係数によって、グラントの下限処理レイテンシＴｍｉｎ（グラント）と、グラントの上限処理レイテンシＴｍａｘ（グラント）をスケーリングしてもよい。異なる再伝送数が、異なる換算係数に関連付けられる場合、複数の換算係数が定義されてよい。さらに、異なる換算係数が、パラメータＴｍｉｎ（グラント）とパラメータＴｍａｘ（グラント）に対して定められてもよい。ＵＥは換算係数を用いて構成されてよい。あるいは、換算係数および再伝送数のマッピングは、仕様においてハードコードされてもよい。さらに別の変形例では、換算係数の選択および再伝送数のマッピングは、実装形態に任せられてもよい。
【０２８９】
ＭＡＣは、ＬＣＰプロシージャの間、パラメータＴｍｉｎ（グラント）およびパラメータＴｍａｘ（グラント）に適切な換算係数を乗じることによって、Ｔｍｉｎ（グラント）およびＴｍａｘ（グラント）のスケーリング操作を実施してもよい。
【０２９０】
レイテンシ要件の観点から、論理チャネルの許容されるレイテンシが、グラント処理レイテンシＴｍｉｎ（グラント）からＴｍａｘ（グラント）までの間にある場合、ＵＥ  ＭＡＣは、グラントによって論理チャネルが作動されてもよいと判断してもよい。
【０２９１】
第３世代パートナーシッププロジェクト（３ＧＰＰ）は、無線アクセス、コアトランスポートネットワーク、およびサービス能力（符復号化、セキュリティ、およびサービスの品質に作用するものを含む）を含む、セルラー電気通信ネットワーク技術のための技術的規格を開発している。最近の無線アクセス技術（Radio  Access  Technology：ＲＡＴ）規格は、広帯域ＣＤＭＡ（Wideband  CDMA：ＷＣＤＭＡ（登録商標））（一般に、３Ｇと称される）、ＬＴＥ（一般に、４Ｇと称される）、およびＬＴＥ−アドバンスト規格を含む。３ＧＰＰは、「５Ｇ」とも称される、新無線（ＮＲ）と呼ばれる、次世代セルラー技術の標準化への取り組みを開始している。３ＧＰＰ  ＮＲ規格開発は、次世代無線アクセス技術（新しいＲＡＴ）の定義を含むことが予期され、これは、６ＧＨｚを下回る新規のフレキシブルな無線アクセスの提供と、６ＧＨｚを上回る新規のウルトラモバイルブロードバンド無線アクセスの提供とを含むことが予期されている。フレキシブルな無線アクセスは、６ＧＨｚを下回る新しいスペクトルにおける新しい非後方互換性無線アクセスで構成されることが予期され、同じスペクトル内でともに多重化され、多様な要件を伴う３ＧＰＰ  ＮＲユースケースの広範なセットに対処する場合がある、異なる動作モードを含むことが予期される。ウルトラモバイルブロードバンドは、ウルトラモバイルブロードバンドアクセス、例えば、屋内用途およびホットスポット向けの機会を提供する、センチ波およびミリ波スペクトルを含むことが予期されている。特に、ウルトラモバイルブロードバンドは、センチ波およびミリ波特有設計最適化を伴って、共通設計フレームワークが６ＧＨｚを下回るフレキシブル無線アクセスと共有することが予期されている。
【０２９２】
３ＧＰＰは、データレート、レイテンシ、およびモビリティのための様々なユーザ体験要件をもたらす、ＮＲでサポートすることが予期される種々のユースケースを特定している。ユースケースは、以下の一般的カテゴリ、すなわち、高度化モバイルブロードバンド（例えば、高密度エリアにおけるブロードバンドアクセス、屋内超高ブロードバンドアクセス、群集の中のブロードバンドアクセス、あらゆる場所における５０＋Ｍｂｐｓ、超低コストブロードバンドアクセス、車両内のモバイルブロードバンド）、重要通信、大規模マシンタイプ通信、ネットワークオペレーション（例えば、ネットワークスライシング、ルーティング、移行およびインターワーキング、エネルギー節約）、および拡張ビークルツーエブリシング（Enhanced  Vehicle-To-Everything：ｅＶ２Ｘ）間の通信を含む。これらのカテゴリにおける具体的サービスおよびアプリケーションは、例えば、いくつか例を挙げると、監視およびセンサネットワーク、デバイス遠隔制御、双方向遠隔制御、パーソナルクラウドコンピューティング、ビデオストリーミング、無線クラウドベースのオフィス、緊急対応者コネクティビティ、自動車ｅコール、災害警告、リアルタイムゲーム、多人数ビデオコール、自律運転、拡張現実、触知インターネット、および仮想現実を含む。これらのユースケースのすべておよび他のものが、本明細書で検討される。
【０２９３】
図１２は、本明細書で説明および請求される方法および装置がその中で具現化される可能性のある例示的通信システム１００の一実施形態を示す。示すように、例示的通信システム１００は、無線伝送／受信ユニット（ＷＴＲＵ）１０２ａ、１０２ｂ、１０２ｃ、および／または１０２ｄ（概して、または集合的に、ＷＴＲＵ１０２と呼ばれることもある）と、無線アクセスネットワーク（ＲＡＮ）１０３／１０４／１０５／１０３ｂ／１０４ｂ／１０５ｂと、コアネットワーク１０６／１０７／１０９と、公衆交換電話ネットワーク（ＰＳＴＮ）１０８と、インターネット１１０と、他のネットワーク１１２とを含む場合があるが、開示される実施形態は、任意の数のＷＴＲＵ、基地局、ネットワーク、および／またはネットワーク要素を検討することを理解されよう。ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄ、１０２ｅはそれぞれ、無線環境で動作および／または通信するように構成される任意のタイプの装置またはデバイスであってよい。各ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄ、１０２ｅは、ハンドヘルド無線通信装置として図６６〜６８に描写されるが、５Ｇ無線通信のために検討される様々なユースケースに伴って、各ＷＴＲＵは、一例にすぎないが、ユーザ端末（ＵＥ）、移動局、固定またはモバイルサブスクライバユニット、ポケットベル、セルラー電話、携帯情報端末（Personal  Digital  Assistant：ＰＤＡ）、スマートフォン、ラップトップ、タブレット、ネットブック、ノートブックコンピュータ、パーソナルコンピュータ、無線センサ、大衆消費電子製品、スマートウォッチまたはスマート衣類などのウェアラブルデバイス、医療またはｅ健康デバイス、ロボット、産業機器、ドローン、例えば、車、トラック、電車、または飛行機の乗り物などを含む、無線信号を伝送および／または受信するように構成される任意のタイプの装置またはデバイスを備えている、またはそれらで具現化されてよいことを理解されよう。
【０２９４】
通信システム１００はまた、基地局１１４ａと、基地局１１４ｂとを含んでもよい。基地局１１４ａは、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのうちの少なくとも１つと無線でインターフェースをとり、コアネットワーク１０６／１０７／１０９、インターネット１１０、および／またはその他のネットワーク１１２などの１つまたは複数の通信ネットワークへのアクセスを促進するように構成される任意のタイプのデバイスであってもよい。基地局１１４ｂは、遠隔無線ヘッド（ＲＲＨ）１１８ａ、１１８ｂおよび／または送受信ポイント（ＴＲＰ）１１９ａ、１１９ｂのうちの少なくとも１つと有線および／または無線でインターフェースをとり、コアネットワーク１０６／１０７／１０９、インターネット１１０、および／またはその他のネットワーク１１２などの１つまたは複数の通信ネットワークへのアクセスを促進するように構成される任意のタイプのデバイスであってもよい。ＲＲＨ１１８ａ、１１８ｂは、ＷＴＲＵ１０２ｃのうちの少なくとも１つと無線でインターフェースをとり、コアネットワーク１０６／１０７／１０９、インターネット１１０、および／またはその他のネットワーク１１２などの１つまたは複数の通信ネットワークへのアクセスを促進するように構成される任意のタイプのデバイスであってもよい。ＴＲＰ１１９ａ、１１９ｂは、ＷＴＲＵ１０２ｄのうちの少なくとも１つと無線でインターフェースをとり、コアネットワーク１０６／１０７／１０９、インターネット１１０、および／またはその他のネットワーク１１２などの１つまたは複数の通信ネットワークへのアクセスを促進するように構成される任意のタイプのデバイスであってもよい。一例として、基地局１１４ａ、１１４ｂは、送受信機基地局（Base  Transceiver  Station：ＢＴＳ）、Ｎｏｄｅ−Ｂ、ｅＮｏｄｅＢ、ホームＮｏｄｅＢ、ホームｅＮｏｄｅＢ、サイトコントローラ、アクセスポイント（Access  Point：ＡＰ）、無線ルータなどであってもよい。基地局１１４ａ、１１４ｂはそれぞれ単一の要素として描写されているが、基地局１１４ａ、１１４ｂは、任意の数の相互接続される基地局および／またはネットワーク要素を含む場合があることを理解されよう。
【０２９５】
基地局１１４ａは、ＲＡＮ１０３／１０４／１０５の一部であってもよく、それらＲＡＮはまた、基地局コントローラ（Base  Station  Controller：ＢＳＣ）、無線ネットワークコントローラ（Radio  Network  Controller：ＲＮＣ）、中継ノードなどの他の基地局および／またはネットワーク要素（図示せず）も含んでもよい。基地局１１４ｂは、ＲＡＮ１０３ｂ／１０４ｂ／１０５ｂの一部であってもよく、それらＲＡＮはまた、基地局コントローラ（ＢＳＣ）、無線ネットワークコントローラ（ＲＮＣ）、中継ノードなどの他の基地局および／またはネットワーク要素（図示せず）も含んでもよい。基地局１１４ａは、特定の地理的領域内で無線信号を伝送および／または受信するように構成されてよく、その地理的領域はセル（図示せず）と呼ばれることもある。基地局１１４ｂは、特定の地理的領域内で有線および／または無線信号を伝送および／または受信するように構成されてよく、その地理的領域はセル（図示せず）と呼ばれることもある。セルは、セルセクタにさらに分割されてよい。例えば、基地局１１４ａに関連付けられたセルは、３つのセクタに分割されてもよい。したがって、一実施形態では、基地局１１４ａは、例えば、セルのセクタごとに１つの、３つの送受信機を含む場合がある。一実施形態では、基地局１１４ａは、多入力多出力（Multiple-Input  Multiple  Output：ＭＩＭＯ）技術を採用する場合があり、したがって、セルのセクタごとに複数の送受信機を利用することがある。
【０２９６】
基地局１１４ａは、任意の好適な無線通信リンク（例えば、無線周波数（Radio  Frequency：ＲＦ）、マイクロ波、赤外線（Infrared：ＩＲ）、紫外線（Ultraviolet：ＵＶ）、可視光、センチ波、ミリ波など）であることがあるエアインターフェース１１５／１１６／１１７を通してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのうちの１つまたは複数と通信してもよい。エアインターフェース１１５／１１６／１１７は、任意の好適な無線アクセス技術（ＲＡＴ）を使用して確立されてよい。
【０２９７】
基地局１１４ｂは、任意の好適な有線（例えば、ケーブル、光ファイバーなど）または無線通信リンク（例えば、無線周波数（ＲＦ）、マイクロ波、赤外線（ＩＲ）、紫外線（ＵＶ）、可視光、センチ波、ミリ波など）であることがある、有線またはエアインターフェース１１５ｂ／１１６ｂ／１１７ｂを通してＲＲＨ１１８ａ、１１８ｂおよび／またはＴＲＰ１１９ａ、１１９ｂのうち１つまたは複数と通信してもよい。エアインターフェース１１５ｂ／１１６ｂ／１１７ｂは、任意の好適な無線アクセス技術（ＲＡＴ）を使用して確立されてよい。
【０２９８】
ＲＲＨ１１８ａ、１１８ｂおよび／またはＴＲＰ１１９ａ、１１９ｂは、任意の好適な無線通信リンク（例えば、無線周波数（ＲＦ）、マイクロ波、赤外線（ＩＲ）、紫外線（ＵＶ）、可視光、センチ波、ミリ波など）であることがある、エアインターフェース１１５ｃ／１１６ｃ／１１７ｃを通してＷＴＲＵ１０２ｃ、１０２ｄのうちの１つまたは複数と通信してもよい。エアインターフェース１１５ｃ／１１６ｃ／１１７ｃは、任意の好適な無線アクセス技術（ＲＡＴ）を使用して確立されてよい。
【０２９９】
より詳細には、上記のように、通信システム１００は、複数のアクセスシステムであってもよく、かつＣＤＭＡ、ＴＤＭＡ、ＦＤＭＡ、ＯＦＤＭＡ、ＳＣ−ＦＤＭＡなどの１つまたは複数のチャネルアクセススキームを採用してもよい。例えば、ＲＡＮ１０３／１０４／１０５内の基地局１１４ａとＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとは、または、ＲＡＮ１０３ｂ／１０４ｂ／１０５ｂ内のＲＲＨ１１８ａ、１１８ｂおよびＴＲＰ１１９ａ、１１９ｂとＷＴＲＵ１０２ｃ、１０２ｄとは、ユニバーサルモバイル電気通信システム（Universal  Mobile  Telecommunications  System：ＵＭＴＳ）、地上無線アクセス（Universal  Terrestrial  Radio  Access：ＵＴＲＡ）などの無線技術を実装してよく、それにより、広帯域ＣＤＭＡ（ＷＣＤＭＡ）を使用して、エアインターフェース１１５／１１６／１１７または１１５ｃ／１１６ｃ／１１７ｃをそれぞれ確立することができる。ＷＣＤＭＡは、高速パケットアクセス（High-Speed  Packet  Access：ＨＳＰＡ）および／または発展型ＨＳＰＡ（Evolved  HSPA：ＨＳＰＡ＋）などの通信プロトコルを含んでもよい。ＨＳＰＡは、高速下りリンクパケットアクセス（High-Speed  Downlink  Packet  Access：ＨＳＤＰＡ）および／または高速上りリンクパケットアクセス（High-Speed  Uplink  Packet  Access：ＨＳＵＰＡ）を含んでもよい。
【０３００】
一実施形態では、基地局１１４ａとＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとは、またはＲＡＮ１０３ｂ／１０４ｂ／１０５ｂ内のＲＲＨ１１８ａ、１１８ｂおよびＴＲＰ１１９ａ、１１９ｂとＷＴＲＵ１０２ｃ、１０２ｄとは、発展型ＵＭＴＳ地上無線アクセス（Evolved  UMTS  Terrestrial  Radio  Access：Ｅ−ＵＴＲＡ）などの無線技術を実装してもよく、それにより、ロングタームエボリューション（Long  Term  Evolution：ＬＴＥ）および／またはＬＴＥ−アドバンスト（ＬＴＥ−Ａ）を使用して、それぞれ、エアインターフェース１１５／１１６／１１７または１１５ｃ／１１６ｃ／１１７ｃを確立してもよい。将来、エアインターフェース１１５／１１６／１１７は、３ＧＰＰ  ＮＲ技術を実装する可能性がある。
【０３０１】
一実施形態では、ＲＡＮ１０３／１０４／１０５内の基地局１１４ａとＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとは、またはＲＡＮ１０３ｂ／１０４ｂ／１０５ｂ内のＲＲＨ１１８ａ、１１８ｂおよびＴＲＰ１１９ａ、１１９ｂとＷＴＲＵ１０２ｃ、１０２ｄとは、ＩＥＥＥ８０２．１６（例えば、ワールドワイド・インターオペラビリティ・フォー・マイクロウェーブ・アクセス（Worldwide  Interoperability  For  Microwave  Access：ＷｉＭＡＸ））、ＣＤＭＡ２０００、ＣＤＭＡ２０００  １Ｘ、ＣＤＭＡ２０００  ＥＶ−ＤＯ、暫定規格２０００（Interim  Standard  2000：ＩＳ−２０００）、暫定規格９５（ＩＳ−９５）、暫定規格８５６（ＩＳ−８５６）、モバイル通信用グローバルシステム（Global  System  for  Mobile  communications：ＧＳＭ（登録商標））、ＧＳＭ進化型高速データレート（Enhanced  Data  Rates  For  GSM  Evolution：ＥＤＧＥ）、ＧＳＭ  ＥＤＧＥ（ＧＥＲＡＮ）などの無線技術を実装してもよい。
【０３０２】
図１２における基地局１１４ｃは、無線ルータ、ホームＮｏｄｅＢ、ホームｅＮｏｄｅＢ、またはアクセスポイントであってもよく、例えば、会社、自宅、車両、キャンパスなどの場所などの局所エリア内の無線コネクティビティを促進するための任意の好適なＲＡＴを利用してもよい。一実施形態では、基地局１１４ｃとＷＴＲＵ１０２ｅとは、ＩＥＥＥ８０２．１１などの無線技術を実装して、無線ローカルエリアネットワーク（Wireless  Local  Area  Network：ＷＬＡＮ）を確立してもよい。一実施形態では、基地局１１４ｃとＷＴＲＵ１０２ｄとは、ＩＥＥＥ８０２．１５などの無線技術を実装して、無線パーソナルエリアネットワーク（Wireless  Personal  Area  Network：ＷＰＡＮ）を確立してもよい。さらに別の実施形態では、基地局１１４ｃとＷＴＲＵ１０２ｅとは、セルラーベースのＲＡＴ（例えば、ＷＣＤＭＡ、ＣＤＭＡ２０００、ＧＳＭ、ＬＴＥ、ＬＴＥ−Ａなど）を利用して、ピコセルまたはフェムトセルを確立してもよい。図１２に示すように、基地局１１４ｂは、インターネット１１０への直接接続を有してもよい。したがって、基地局１１４ｃは、コアネットワーク１０６／１０７／１０９を介してインターネット１１０にアクセスする必要がない場合がある。
【０３０３】
ＲＡＮ１０３／１０４／１０５および／またはＲＡＮ１０３ｂ／１０４ｂ／１０５ｂは、コアネットワーク１０６／１０７／１０９と通信してもよく、そのコアネットワークは、音声、データ、アプリケーション、および／またはボイスオーバーインターネットプロトコル（Voice  Over  Internet  Protocol：ＶｏＩＰ）サービスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのうちの１つまたは複数に提供するように構成される任意のタイプのネットワークであってもよい。例えば、コアネットワーク１０６／１０７／１０９は、コール制御、請求サービス、モバイル位置ベースのサービス、プリペイドコール、インターネットコネクティビティ、ビデオ配信などを提供し、および／またはユーザ認証などの高レベルセキュリティ機能を実施してもよい。
【０３０４】
図１２では図示されないが、ＲＡＮ１０３／１０４／１０５および／またはＲＡＮ１０３ｂ／１０４ｂ／１０５ｂおよび／またはコアネットワーク１０６／１０７／１０９は、ＲＡＮ１０３／１０４／１０５および／またはＲＡＮ１０３ｂ／１０４ｂ／１０５ｂと同じＲＡＴまたは異なるＲＡＴを採用する他のＲＡＮと直接または間接通信してもよいことを理解されよう。例えば、Ｅ−ＵＴＲＡ無線技術を利用することがあるＲＡＮ１０３／１０４／１０５および／またはＲＡＮ１０３ｂ／１０４ｂ／１０５ｂに接続されることに加え、コアネットワーク１０６／１０７／１０９はまた、ＧＳＭ無線技術を採用する別のＲＡＮ（図示せず）と通信してもよい。
【０３０５】
コアネットワーク１０６／１０７／１０９はまた、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄ、１０２ｅがＰＳＴＮ１０８、インターネット１１０、および／または他のネットワーク１１２にアクセスするためのゲートウェイとして機能してもよい。ＰＳＴＮ１０８は、基本電話サービス（Plain  Old  Telephone  Service：ＰＯＴＳ）を提供する回線交換電話ネットワークを含んでもよい。インターネット１１０は、伝送制御プロトコル（Transmission  Control  Protocol：ＴＣＰ）、ユーザデータグラムプロトコル（User  Datagram  Protocol：ＵＤＰ）、およびＴＣＰ／ＩＰインターネットプロトコルスイートにおけるインターネットプロトコル（Internet  Protocol：ＩＰ）などの共通通信プロトコルを使用する、相互接続されたコンピュータネットワークおよびデバイスのグローバルシステムを含んでもよい。ネットワーク１１２は、他のサービスプロバイダによって所有および／または運営される、有線または無線通信ネットワークを含んでもよい。例えば、ネットワーク１１２は、ＲＡＮ１０３／１０４／１０５および／またはＲＡＮ１０３ｂ／１０４ｂ／１０５ｂと同じＲＡＴまたは異なるＲＡＴを採用することがある１つまたは複数のＲＡＮに接続される別のコアネットワークを含んでもよい。
【０３０６】
通信システム１００内のＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄの一部または全部は、マルチモード能力を含んでもよい。例えば、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄ、および１０２ｅは、異なる無線リンクを通して異なる無線ネットワークと通信するための複数の送受信機を含んでもよい。例えば、図１２に示されるＷＴＲＵ１０２ｅは、セルラーベースの無線技術を採用することがある基地局１１４ａと、およびＩＥＥＥ８０２無線技術を採用することがある基地局１１４ｃと通信するように構成されてよい。
【０３０７】
図１３は、例えば、ＷＴＲＵ１０２などの本明細書に図示されている実施形態に従って無線通信のために構成される例示的装置またはデバイスのブロック図である。図１３に示すように、例示的ＷＴＲＵ１０２は、プロセッサ１１８と、送受信機１２０と、伝送／受信要素１２２と、スピーカ／マイクロホン１２４と、キーパッド１２６と、ディスプレイ／タッチパッド／インジケータ１２８と、非取り外し可能メモリ１３０と、取り外し可能メモリ１３２と、電源１３４と、全地球測位システム（Global  Positioning  System：ＧＰＳ）チップセット１３６と、他の周辺機器１３８とを含んでもよい。ＷＴＲＵ１０２は、実施形態と一致したままで、上述の要素の任意の副次的組み合わせを含む場合があることを理解されたい。また、実施形態は、限定ではないが、とりわけ、送受信機基地局（ＢＴＳ）、Ｎｏｄｅ−Ｂ、サイトコントローラ、アクセスポイント（ＡＰ）、ホームＮｏｄｅ−Ｂ、発展型ホームＮｏｄｅ−Ｂ（evolved  Node-B：ｅＮｏｄｅＢ）、ホーム発展型Ｎｏｄｅ−Ｂ（Home  Evolved  Node-B：ＨｅＮＢ）、ホーム発展型Ｎｏｄｅ−Ｂゲートウェイ、およびプロキシノードなどの基地局１１４ａおよび１１４ｂ、および／または基地局１１４ａおよび１１４ｂを意味する場合があるノードは、図１３に描写され、本明細書に説明される要素の一部または全部を含んでもよいことを想定する。
【０３０８】
プロセッサ１１８は、汎用プロセッサ、特殊目的プロセッサ、従来のプロセッサ、デジタル信号プロセッサ（Digital  Signal  Processor：ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアに関連付けられた１つまたは複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（Application  Specific  Integrated  Circuits：ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（Field  Programmable  Gate  Array  ：ＦＰＧＡ）回路、任意の他のタイプの集積回路（Integrated  Circuit：ＩＣ）、状態マシンなどであってよい。プロセッサ１１８は、信号コーディング、データ処理、電力制御、入力／出力処理、および／またはＷＴＲＵ１０２が無線環境内で動作することを可能にする任意の他の機能性を果たしてもよい。プロセッサ１１８は、伝送／受信要素１２２に結合されることがある、送受信機１２０に結合されてもよい。図１３は、別個のコンポーネントとしてプロセッサ１１８と送受信機１２０とを示しているが、プロセッサ１１８と送受信機１２０とが、電子パッケージまたはチップ内に一緒に統合されてもよいことを理解されよう。
【０３０９】
伝送／受信要素１２２は、エアインターフェース１１５／１１６／１１７を通して基地局（例えば、基地局１１４ａ）へ信号を伝送する、またはそこから信号を受信するように構成されてよい。例えば、一実施形態では、伝送／受信要素１２２は、ＲＦ信号を伝送および／または受信するように構成されるアンテナであってもよい。図１２では図示されないが、ＲＡＮ１０３／１０４／１０５および／またはコアネットワーク１０６／１０７／１０９は、ＲＡＮ１０３／１０４／１０５と同じＲＡＴまたは異なるＲＡＴを採用する、他のＲＡＮと直接または間接通信してもよいことを理解されよう。例えば、Ｅ−ＵＴＲＡ無線技術を利用することがあるＲＡＮ１０３／１０４／１０５に接続されることに加え、コアネットワーク１０６／１０７／１０９はまた、ＧＳＭ無線技術を採用する別のＲＡＮ（図示せず）と通信してもよい。
【０３１０】
コアネットワーク１０６／１０７／１０９はまた、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄが、ＰＳＴＮ１０８、インターネット１１０、および／または他のネットワーク１１２にアクセスするためのゲートウェイとして機能してもよい。ＰＳＴＮ１０８は、基本電話サービス（ＰＯＴＳ）を提供する回線交換電話ネットワークを含んでもよい。インターネット１１０は、伝送制御プロトコル（ＴＣＰ）、ユーザデータグラムプロトコル（ＵＤＰ）、およびＴＣＰ／ＩＰインターネットプロトコルスイートにおけるインターネットプロトコル（ＩＰ）などの共通通信プロトコルを使用する、相互接続されたコンピュータネットワークおよびデバイスのグローバルシステムを含んでもよい。ネットワーク１１２は、他のサービスプロバイダによって所有および／または運営される、有線または無線通信ネットワークを含んでもよい。例えば、ネットワーク１１２は、ＲＡＮ１０３／１０４／１０５と同じＲＡＴまたは異なるＲＡＴを採用することがある１つまたは複数のＲＡＮに接続される別のコアネットワークを含んでもよい。
【０３１１】
通信システム１００内のＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄの一部または全部は、マルチモード能力を含んでもよい。例えば、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、および１０２ｄは、異なる無線リンクを通して異なる無線ネットワークと通信するための複数の送受信機を含んでもよい。例えば、図１２に示されるＷＴＲＵ１０２ｃは、セルラーベースの無線技術を採用することがある基地局１１４ａと、およびＩＥＥＥ８０２無線技術を採用する可能性のある基地局１１４ｂと通信するように構成されてよい。
【０３１２】
図１３は、例えば、ＷＴＲＵ１０２などの本明細書に図示されている実施形態に従って無線通信のために構成される例示的装置またはデバイスのブロック図である。図１３に示すように、例示的ＷＴＲＵ１０２は、プロセッサ１１８と、送受信機１２０と、伝送／受信要素１２２と、スピーカ／マイクロホン１２４と、キーパッド１２６と、ディスプレイ／タッチパッド／インジケータ１２８と、非取り外し可能メモリ１３０と、取り外し可能メモリ１３２と、電源１３４と、全地球測位システム（ＧＰＳ）チップセット１３６と、他の周辺機器１３８とを含んでもよい。ＷＴＲＵ１０２は、実施形態と一致したままで、上述の要素の任意の副次的組み合わせを含んでもよいことを理解されたい。また、実施形態は、限定ではないが、とりわけ、送受信機基地局（ＢＴＳ）、Ｎｏｄｅ−Ｂ、サイトコントローラ、アクセスポイント（ＡＰ）、ホームＮｏｄｅ−Ｂ、発展型ホームＮｏｄｅ−Ｂ（ｅＮｏｄｅＢ）、ホーム発展型Ｎｏｄｅ−Ｂ（ＨｅＮＢ）、ホーム発展型Ｎｏｄｅ−Ｂゲートウェイ、およびプロキシノードなどの基地局１１４ａおよび１１４ｂ、および／または基地局１１４ａおよび１１４ｂを意味する場合があるノードは、図１３に描写され、本明細書に説明される要素の一部または全部を含んでもよいことを想定する。
【０３１３】
プロセッサ１１８は、汎用プロセッサ、特殊目的プロセッサ、従来のプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアに関連付けられた１つまたは複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、任意の他のタイプの集積回路（ＩＣ）、状態マシンなどであってよい。プロセッサ１１８は、信号コーディング、データ処理、電力制御、入力／出力処理、および／またはＷＴＲＵ１０２が無線環境内で動作することを可能にする任意の他の機能性を果たしてもよい。プロセッサ１１８は、伝送／受信要素１２２に結合されることがある、送受信機１２０に結合されてもよい。図１３は、別個のコンポーネントとしてプロセッサ１１８と送受信機１２０とを示しているが、プロセッサ１１８と送受信機１２０とが、電子パッケージまたはチップ内に一緒に統合されてもよいことを理解されよう。
【０３１４】
伝送／受信要素１２２は、エアインターフェース１１５／１１６／１１７を通して基地局（例えば、基地局１１４ａ）へ信号を伝送する、またはそこから信号を受信するように構成されてよい。例えば、一実施形態では、伝送／受信要素１１２は、ＲＦ信号を伝送および／または受信するように構成されるアンテナであってもよい。一実施形態では、伝送／受信要素１２２は、例えば、ＩＲ、ＵＶ、もしくは可視光信号を伝送および／または受信するように構成されるエミッタ／検出器であってもよい。さらなる一実施形態では、伝送／受信要素１２２は、ＲＦおよび光信号の両方を伝送ならびに受信するように構成されてよい。伝送／受信要素１２２は、無線信号の任意の組み合わせを伝送および／または受信するように構成されてよいことを理解されよう。
【０３１５】
加えて、伝送／受信要素１２２は、単一の要素として図１３で描写されているが、ＷＴＲＵ１０２は、任意の数の伝送／受信要素１２２を含んでもよい。より具体的には、ＷＴＲＵ１０２は、ＭＩＭＯ技術を採用してもよい。したがって、一実施形態では、ＷＴＲＵ１０２は、エアインターフェース１１５／１１６／１１７を通して無線信号を伝送および受信するための２つ以上の伝送／受信要素１２２（例えば、複数のアンテナ）を含んでもよい。
【０３１６】
送受信機１２０は、伝送／受信要素１２２によって伝送されることになる信号を変調し、伝送／受信要素１２２によって受信される信号を復調するように構成されてよい。上記のように、ＷＴＲＵ１０２は、マルチモード能力を有してもよい。したがって、送受信機１２０は、ＷＴＲＵ１０２が、例えば、ＵＴＲＡおよびＩＥＥＥ８０２．１１などの複数のＲＡＴを介して通信することを可能にするための複数の送受信機を含んでもよい。
【０３１７】
ＷＴＲＵ１０２のプロセッサ１１８は、スピーカ／マイクロホン１２４、キーパッド１２６、および／またはディスプレイ／タッチパッド／インジケータ１２８（例えば、液晶ディスプレイ（Liquid  Crystal  Display：ＬＣＤ）ディスプレイユニットまたは有機発光ダイオード（Organic  Light-Emitting  Diode：ＯＬＥＤ）ディスプレイユニット）に結合され、そこからユーザ入力データを受信してもよい。プロセッサ１１８はまた、ユーザデータをスピーカ／マイクロホン１２４、キーパッド１２６、および／またはディスプレイ／タッチパッド／インジケータ１２８に出力してもよい。加えて、プロセッサ１１８は、非取り外し可能メモリ１３０および／または取り外し可能メモリ１３２などの任意のタイプの好適なメモリから情報にアクセスし、そこにデータを記憶してもよい。非取り外し可能メモリ１３０としては、ランダムアクセスメモリ（Random-Access  Memory：ＲＡＭ）、読み取り専用メモリ（Read-Only  Memory  ：ＲＯＭ）、ハードディスク、または任意の他のタイプのメモリ記憶デバイスを挙げてもよい。取り外し可能メモリ１３２としては、加入者識別モジュール（Subscriber  Identity  Module：ＳＩＭ）カード、メモリスティック、セキュアデジタル（Secure  Digital：ＳＤ）メモリカードなどを挙げてもよい。一実施形態では、プロセッサ１１８は、サーバまたはホームコンピュータ（図示せず）上などのＷＴＲＵ１０２上に物理的に位置しないメモリから情報にアクセスし、そこにデータを記憶してもよい。
【０３１８】
プロセッサ１１８は、電源１３４から電力を得てもよく、ＷＴＲＵ１０２内のその他のコンポーネントへの電力を分配および／または制御するように構成されてよい。電源１３４は、ＷＴＲＵ１０２に給電するための任意の好適なデバイスであってよい。例えば、電源１３４は、１つまたは複数の乾電池、太陽電池、燃料電池などを含んでもよい。
【０３１９】
プロセッサ１１８はまた、ＷＴＲＵ１０２の現在位置に関する位置情報（例えば、経度および緯度）を提供するように構成されることがあるＧＰＳチップセット１３６に結合されてもよい。ＧＰＳチップセット１３６からの情報に加え、またはその代わりに、ＷＴＲＵ１０２は、エアインターフェース１１５／１１６／１１７を通して基地局（例えば、基地局１１４ａ、１１４ｂ）から位置情報を受信し、および／または２つ以上の近傍基地局から受信されている信号のタイミングに基づいて、その場所を決定してもよい。ＷＴＲＵ１０２は、実施形態と一致したままで任意の好適な位置特定方法によって位置情報を取得してもよいことを理解されるであろう。
【０３２０】
プロセッサ１１８はさらに、追加の機構、機能性、および／または有線もしくは無線コネクティビティを提供する、１つまたは複数のソフトウェアならびに／もしくはハードウェアモジュールを含むことがある他の周辺機器１３８に連結されてよい。例えば、周辺機器１３８は、加速度計、バイオメトリック（例えば、指紋）センサなどの種々のセンサ、ｅ−コンパス、衛星送受信機、デジタルカメラ（写真またはビデオ用）、ユニバーサルシリアルバス（Universal  Serial  Bus：ＵＳＢ）ポートまたは他の相互接続インターフェース、振動デバイス、テレビ送受信機、ハンズフリーヘッドセット、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール、周波数変調（Frequency  Modulated：ＦＭ）無線ユニット、デジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザなどを含んでもよい。
【０３２１】
ＷＴＲＵ１０２は、センサ、大衆消費電子製品、スマートウォッチまたはスマート衣類などのウェアラブルデバイス、医療またはｅ健康デバイス、ロボット、産業機器、ドローン、車、トラック、電車、または飛行機などの乗り物などの他の装置もしくはデバイスで具現化されてよい。ＷＴＲＵ１０２は、周辺機器１３８のうちの１つを備えることがある相互接続インターフェースなどの１つまたは複数の相互接続インターフェースを介して、このような装置もしくはデバイスの他のコンポーネント、モジュール、またはシステムに接続してもよい。
【０３２２】
図１４は、一実施形態による、ＲＡＮ１０３およびコアネットワーク１０６の系統図である。上記のように、ＲＡＮ１０３はＵＴＲＡ無線技術を採用して、エアインターフェース１１５を通してＷＴＲＵ１０２ａ、１０２ｂ、および１０２ｃと通信してよい。ＲＡＮ１０３はまた、コアネットワーク１０６と通信してもよい。図１４に示すように、ＲＡＮ１０３は、エアインターフェース１１５を通してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するための１つまたは複数の送受信機をそれぞれ含むことがある、Ｎｏｄｅ−Ｂ１４０ａ、１４０ｂ、１４０ｃを含んでもよい。Ｎｏｄｅ−Ｂ１４０ａ、１４０ｂ、１４０ｃはそれぞれ、ＲＡＮ１０３内の特定のセル（図示せず）に関連付けられてよい。ＲＡＮ１０３はまた、ＲＮＣ１４２ａ、１４２ｂを含んでもよい。ＲＡＮ１０３は、実施形態と一致したままで、任意の数のＮｏｄｅ−ＢおよびＲＮＣを含んでもよいことを理解されよう。
【０３２３】
図１４に示すように、Ｎｏｄｅ−Ｂ１４０ａ、１４０ｂは、ＲＮＣ１４２ａと通信してもよい。加えて、Ｎｏｄｅ−Ｂ１４０ｃは、ＲＮＣ１４２ｂと通信してもよい。Ｎｏｄｅ−Ｂ１４０ａ、１４０ｂ、１４０ｃは、Ｉｕｂインターフェースを介して、それぞれのＲＮＣ１４２ａ、１４２ｂと通信してもよい。ＲＮＣ１４２ａ、１４２ｂは、Ｉｕｒインターフェースを介して、相互に通信してもよい。ＲＮＣ１４２ａ、１４２ｂのそれぞれは、接続されるそれぞれのＮｏｄｅ−Ｂ１４０ａ、１４０ｂ、１４０ｃを制御するように構成されてよい。加えて、ＲＮＣ１４２ａ、１４２ｂのそれぞれは、アウターループ電力制御、負荷制御、受付制御、パケットスケジューリング、ハンドオーバ制御、マクロダイバーシチ、セキュリティ機能、データ暗号化などの他の機能性を果たすまたはサポートするように構成されてよい。
【０３２４】
図１４に示されるコアネットワーク１０６は、メディアゲートウェイ（Media  Gateway：ＭＧＷ）１４４、移動通信交換局（Mobile  Switching  Center  ：ＭＳＣ）１４６、サービングＧＰＲＳサポートノード（Serving  GPRS  Support  Node：ＳＧＳＮ）１４８、および／またはゲートウェイＧＰＲＳサポートノード（Gateway  GPRS  Support  Node：ＧＧＳＮ）１５０を含んでもよい。上述の要素のそれぞれが、コアネットワーク１０６の一部として描写されるが、これらの要素のうちの任意の１つは、コアネットワークオペレータ以外のエンティティによって所有および／または運営されることがあることを理解されよう。
【０３２５】
ＲＡＮ１０３内のＲＮＣ１４２ａは、ＩｕＣＳインターフェースを介して、コアネットワーク１０６内のＭＳＣ１４６に接続されてよい。ＭＳＣ１４６は、ＭＧＷ１４４に接続されてよい。ＭＳＣ１４６およびＭＧＷ１４４は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに、ＰＳＴＮ１０８などの回線交換ネットワークへのアクセスを提供し、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと従来の地上通信デバイスとの間の通信を促進してもよい。
【０３２６】
ＲＡＮ１０３内のＲＮＣ１４２ａはまた、ＩｕＰＳインターフェースを介して、コアネットワーク１０６内のＳＧＳＮ１４８に接続されてよい。ＳＧＳＮ１４８は、ＧＧＳＮ１５０に接続されてよい。ＳＧＳＮ１４８およびＧＧＳＮ１５０は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに、インターネット１１０などのパケット交換ネットワークへのアクセスを提供し、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとＩＰ対応デバイスとの間の通信を促進してもよい。
【０３２７】
上記のように、コアネットワーク１０６はまた、他のサービスプロバイダによって所有および／または運営される他の有線または無線ネットワークを含むことがあるネットワーク１１２に接続されてよい。
【０３２８】
図１５は、一実施形態による、ＲＡＮ１０４およびコアネットワーク１０７の系統図である。上記のように、ＲＡＮ１０４は、Ｅ−ＵＴＲＡ無線技術を採用し、エアインターフェース１１６を通してＷＴＲＵ１０２ａ、１０２ｂ、および１０２ｃと通信してよい。ＲＡＮ１０４はまた、コアネットワーク１０７と通信してもよい。
【０３２９】
ＲＡＮ１０４は、ｅＮｏｄｅＢ１６０ａ、１６０ｂ、１６０ｃを含むことがあるが、ＲＡＮ１０４は、実施形態と一致したままで、任意の数のｅＮｏｄｅＢを含んでもよいことを理解されるであろう。ｅＮｏｄｅＢ１６０ａ、１６０ｂ、１６０ｃはそれぞれ、エアインターフェース１１６を通してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するための１つまたは複数の送受信機を含んでよい。一実施形態では、ｅＮｏｄｅ−Ｂ１６０ａ、１６０ｂ、１６０ｃは、ＭＩＭＯ技術を実装してもよい。したがって、ｅＮｏｄｅ−Ｂ１６０ａは、例えば、複数のアンテナを使用して、ＷＴＲＵ１０２ａに無線信号を伝送し、かつＷＴＲＵ１０２ａから無線信号を受信してもよい。
【０３３０】
ｅＮｏｄｅ−Ｂ１６０ａ、１６０ｂ、および１６０ｃのそれぞれは、特定のセル（図示せず）に関連付けられてよく、無線リソース管理決定、ハンドオーバ決定、上りリンクおよび／または下りリンクにおけるユーザのスケジューリングなどをハンドリングするように構成されてよい。図１５に示すように、ｅＮｏｄｅ−Ｂ１６０ａ、１６０ｂ、１６０ｃは、Ｘ２インターフェースを通して相互に通信してよい。
【０３３１】
図１５に示されるコアネットワーク１０７は、モビリティ管理ゲートウェイ（Mobility  Management  Gateway：ＭＭＥ）１６２と、サービングゲートウェイ１６４と、パケットデータネットワーク（Packet  Data  Network：ＰＤＮ）ゲートウェイ１６６とを含んでもよい。上述の要素のそれぞれが、コアネットワーク１０７の一部として描写されるが、これらの要素のうちの任意の１つは、コアネットワークオペレータ以外のエンティティによって所有および／または運営されてもよいことを理解されよう。
【０３３２】
ＭＭＥ１６２は、Ｓ１インターフェースを介して、ＲＡＮ１０４内のｅＮｏｄｅ−Ｂ１６０ａ、１６０ｂ、および１６０ｃのそれぞれに接続されてよく、制御ノードとして機能してよい。例えば、ＭＭＥ１６２は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのユーザを認証すること、ベアラアクティブ化／非アクティブ化、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃの初期アタッチの間の特定のサービングゲートウェイの選択などの役割を果たしてもよい。ＭＭＥ１６２はまた、ＲＡＮ１０４とＧＳＭまたはＷＣＤＭＡなどの他の無線技術を採用する他のＲＡＮ（図示せず）との間の切り替えのための制御プレーン機能を提供してもよい。
【０３３３】
サービングゲートウェイ１６４は、Ｓ１インターフェースを介して、ＲＡＮ１０４内のｅＮｏｄｅ−Ｂ１６０ａ、１６０ｂ、および１６０ｃのそれぞれに接続されてよい。サービングゲートウェイ１６４は、概して、ユーザデータパケットをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃへ／ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃからルーティングおよび転送してよい。サービングゲートウェイ１６４はまた、ｅＮｏｄｅＢ間ハンドオーバの間のユーザプレーンのアンカ、下りリンクデータがＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのために利用可能であるときのページングのトリガ、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのコンテキストの管理および記憶などの他の機能を実施してよい。
【０３３４】
サービングゲートウェイ１６４はまた、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに、インターネット１１０などのパケット交換ネットワークへのアクセスを提供し、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとＩＰ対応デバイスとの間の通信を促進することがあるＰＤＮゲートウェイ１６６に接続されてよい。
【０３３５】
コアネットワーク１０７は、他のネットワークとの通信を促進してもよい。例えば、コアネットワーク１０７は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに、ＰＳＴＮ１０８などの回線交換ネットワークへのアクセスを提供し、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと従来の地上通信デバイスとの間の通信を促進してもよい。例えば、コアネットワーク１０７は、コアネットワーク１０７とＰＳＴＮ１０８との間のインターフェースとして機能する、ＩＰゲートウェイ（例えば、ＩＰマルチメディアサブシステム（IP  Multimedia  Subsystem：ＩＭＳ）サーバ）を含むか、またはそれと通信してよい。加えて、コアネットワーク１０７は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに、他のサービスプロバイダによって所有および／または運営される他の有線または無線ネットワークを含むことがあるネットワーク１１２へのアクセスを提供してもよい。
【０３３６】
図１６は、一実施形態による、ＲＡＮ１０５およびコアネットワーク１０９の系統図である。ＲＡＮ１０５は、ＩＥＥＥ８０２．１６無線技術を採用し、エアインターフェース１１７を通してＷＴＲＵ１０２ａ、１０２ｂ、および１０２ｃと通信する、アクセスサービスネットワーク（Access  Service  Network：ＡＳＮ）であってよい。以下でさらに論じるように、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、ＲＡＮ１０５の異なる機能エンティティとコアネットワーク１０９との間の通信リンクは、参照点として定義されてよい。
【０３３７】
図１６に示すように、ＲＡＮ１０５は、基地局１８０ａ、１８０ｂ、１８０ｃと、ＡＳＮゲートウェイ１８２とを含んでもよいが、実施形態と一致したままで、任意の数の基地局およびＡＳＮゲートウェイを含んでもよいことを理解されるであろう。基地局１８０ａ、１８０ｂ、１８０ｃはそれぞれ、ＲＡＮ１０５内の特定のセルに関連付けられてよく、エアインターフェース１１７を通してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するための１つまたは複数の送受信機を含んでもよい。一実施形態では、基地局１８０ａ、１８０ｂ、１８０ｃは、ＭＩＭＯ技術を実装してもよい。したがって、基地局１８０ａは、例えば、複数のアンテナを使用して、ＷＴＲＵ１０２ａに無線信号を伝送し、ＷＴＲＵ１０２ａから無線信号を受信してもよい。基地局１８０ａ、１８０ｂ、１８０ｃはまた、ハンドオフトリガ、トンネル確立、無線リソース管理、トラフィック分類、サービスの品質（ＱｏＳ）ポリシ強制などのモビリティ管理機能を提供してもよい。ＡＳＮゲートウェイ１８２は、トラフィック集約点として機能してよく、ページング、加入者プロファイルのキャッシュ、コアネットワーク１０９へのルーティングなどの役割を果たしてもよい。
【０３３８】
ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとＲＡＮ１０５との間のエアインターフェース１１７は、ＩＥＥＥ８０２．１６仕様を実装する、Ｒ１参照点として定義されてよい。加えて、ＷＴＲＵ１０２ａ、１０２ｂ、および１０２ｃのそれぞれは、論理インターフェース（図示せず）をコアネットワーク１０９と確立してよい。ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとコアネットワーク１０９との間の論理インターフェースは、認証、認可、ＩＰホスト構成管理、および／またはモビリティ管理のために使用されることがあるＲ２参照点として定義されてよい。
【０３３９】
基地局１８０ａ、１８０ｂ、および１８０ｃのそれぞれ間の通信リンクは、基地局間のＷＴＲＵハンドオーバおよびデータの転送を促進するためのプロトコルを含む、Ｒ８参照点として定義されてよい。基地局１８０ａ、１８０ｂ、１８０ｃとＡＳＮゲートウェイ１８２との間の通信リンクは、Ｒ６参照点として定義されてよい。Ｒ６参照点は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのそれぞれに関連付けられたモビリティイベントに基づいてモビリティ管理を促進するためのプロトコルを含んでもよい。
【０３４０】
図１６に示すように、ＲＡＮ１０５は、コアネットワーク１０９に接続されてよい。ＲＡＮ１０５とコアネットワーク１０９との間の通信リンクは、例えば、データ転送およびモビリティ管理能力を促進するためのプロトコルを含む、Ｒ３参照点として定義されてよい。コアネットワーク１０９は、モバイルＩＰホームエージェント（Mobile  IP  Home  Agent：ＭＩＰ−ＨＡ）１８４と、認証、認可、課金（Authentication,  Authorization,  Accounting：ＡＡＡ）サーバ１８６と、ゲートウェイ１８８とを含んでもよい。上述の要素のそれぞれが、コアネットワーク１０９の一部として描写されるが、これらの要素のうちの任意の１つは、コアネットワークオペレータ以外のエンティティによって所有および／または運営されてもよいことを理解されよう。
【０３４１】
ＭＩＰ−ＨＡは、ＩＰアドレス管理の役割を果たしてもよく、ＷＴＲＵ１０２ａ、１０２ｂ、および１０２ｃが、異なるＡＳＮおよび／または異なるコアネットワーク間でローミングすることを可能にしてもよい。ＭＩＰ−ＨＡ１８４は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに、インターネット１１０などのパケット交換ネットワークへのアクセスを提供し、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとＩＰ対応デバイスとの間の通信を促進してもよい。ＡＡＡサーバ１８６は、ユーザ認証およびユーザサービスをサポートする役割を果たしてもよい。ゲートウェイ１８８は、他のネットワークとのインターワーキングを促進してもよい。例えば、ゲートウェイ１８８は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに、ＰＳＴＮ１０８などの回線交換ネットワークへのアクセスを提供し、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと従来の地上通信デバイスとの間の通信を促進してもよい。加えて、ゲートウェイ１８８は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに、他のサービスプロバイダによって所有および／または運営される他の有線または無線ネットワークを含むことがあるネットワーク１１２へのアクセスを提供してもよい。
【０３４２】
図１６では図示されないが、ＲＡＮ１０５は、他のＡＳＮに接続されてよく、コアネットワーク１０９は、他のコアネットワークに接続されてもよいことを理解されよう。ＲＡＮ１０５と他のＡＳＮとの間の通信リンクは、ＲＡＮ１０５とその他のＡＳＮとの間のＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのモビリティを協調するためのプロトコルを含むことがある、Ｒ４参照点として定義されてよい。コアネットワーク１０９とその他のコアネットワークとの間の通信リンクは、ホームコアネットワークと在圏コアネットワークとの間のインターワーキングを促進するためのプロトコルを含むことがある、Ｒ５参照点として定義されてよい。
【０３４３】
本明細書に記載され、図４から８に図示されている、コアネットワークエンティティは、ある既存の３ＧＰＰ仕様におけるそれらのエンティティに与えられる名称によって識別されるが、将来において、それらのエンティティおよび機能性は、他の名称によって識別される可能性があり、ある種のエンティティまたは機能は、将来的３ＧＰＰ  ＮＲ仕様を含む、３ＧＰＰによって公開される将来的な仕様において組み合わせられる場合があることを理解されたい。したがって、図４から８に説明および図示されている特定のネットワークエンティティおよび機能性は、一例としてのみ提供され、本明細書で開示および請求される主題は、現在規定されているか、または将来的に規定されるかどうかにかかわらず、任意の類似通信システムにおいて具現化または実装される場合があることを理解されたい。
【０３４４】
図１７は、ＲＡＮ１０３／１０４／１０５、コアネットワーク１０６／１０７／１０９、ＰＳＴＮ１０８、インターネット１１０、または他のネットワーク１１２内のある種のノードまたは機能エンティティなど、図４から８に図示されている通信ネットワークの１つまたは複数の装置がその中で具現化されることがある例示的コンピューティングシステム９０のブロック図である。コンピューティングシステム９０は、コンピュータまたはサーバを備えてもよく、ソフトウェアの形態（このようなソフトウェアが記憶されるまたはアクセスされる場所もしくは手段がいかなるものであっても）であってもよいコンピュータ可読命令によって主に制御されてよい。このようなコンピュータ可読命令は、コンピューティングシステム９０を稼働させるように、プロセッサ９１内で実行されてよい。プロセッサ９１は、汎用プロセッサ、特殊目的プロセッサ、従来のプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアに関連付けられた１つまたは複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、任意の他のタイプの集積回路（ＩＣ）、状態マシンなどであってよい。プロセッサ９１は、信号コーディング、データ処理、電力制御、入力／出力処理、および／またはコンピューティングシステム９０が通信ネットワーク内で動作することを可能にする、任意の他の機能性を果たしてもよい。コプロセッサ８１は、主要プロセッサ９１とは明確に異なる、任意選択のプロセッサであり、追加の機能を果たすか、またはプロセッサ９１を支援することがある。プロセッサ９１および／またはコプロセッサ８１は、本明細書に開示される方法および装置に関連するデータを受信、生成、ならびに処理してよい。
【０３４５】
プロセッサ９１は、動作時に、命令をフェッチ、復号、および実行し、コンピューティングシステムの主要データ転送パスであるシステムバス８０を介して、情報を他のリソースへ転送し、かつ他のリソースから転送する。このようなシステムバスは、コンピューティングシステム９０内のコンポーネント同士を接続し、データ交換のための媒体を定義する。システムバス８０は、典型的には、データを送信するためのデータラインと、アドレスを送信するためのアドレスラインと、インタラプトを送信するため、およびシステムバスを動作させるための制御ラインとを含む。このようなシステムバス８０の一例は、周辺コンポーネント相互接続（Peripheral  Component  Interconnect：ＰＣＩ）バスである。
【０３４６】
システムバス８０に連結されるメモリは、ランダムアクセスメモリ（ＲＡＭ）８２および読み取り専用メモリ（ＲＯＭ）９３を含む。このようなメモリは、情報が記憶され、かつ読み出されるようにする回路を含む。ＲＯＭ９３は、概して、容易に修正することができない記憶されたデータを含む。ＲＡＭ８２内に記憶されたデータは、プロセッサ９１または他のハードウェアデバイスによって読み取られる、もしくは変更されてよい。ＲＡＭ８２および／またはＲＯＭ９３へのアクセスは、メモリコントローラ９２によって制御されてよい。メモリコントローラ９２は、命令が実行されると、仮想アドレスを物理的アドレスに変換する、アドレス変換機能を提供してよい。メモリコントローラ９２はまた、システム内のプロセスを隔離し、ユーザプロセスからシステムプロセスを隔離するメモリ保護機能を提供してよい。したがって、第１のモードで起動するプログラムは、それ自体のプロセス仮想アドレス空間によってマップされているメモリのみにアクセスすることができ、プロセス間のメモリ共有が設定されていない限り、別のプロセスの仮想アドレス空間内のメモリにアクセスすることができない。
【０３４７】
加えて、コンピューティングシステム９０は、プロセッサ９１からプリンタ９４、キーボード８４、マウス９５、およびディスクドライブ８５などの周辺機器に命令を通信する役割を果たす、周辺機器コントローラ８３を含んでもよい。
【０３４８】
ディスプレイコントローラ９６によって制御されるディスプレイ８６は、コンピューティングシステム９０によって生成される視覚出力を表示するために使用される。このような視覚出力は、テキスト、グラフィックス、動画グラフィックス、およびビデオを含んでよい。視覚出力は、グラフィカルユーザインターフェース（Graphical  User  Interface：ＧＵＩ）の形態で提供されてよい。ディスプレイ８６は、ＣＲＴベースのビデオディスプレイ、ＬＣＤベースのフラットパネルディスプレイ、ガスプラズマベースのフラットパネルディスプレイ、またはタッチパネルを用いて実装されてよい。ディスプレイコントローラ９６は、ディスプレイ８６に送信されるビデオ信号を生成するために必要とされる電子コンポーネントを含む。
【０３４９】
さらに、コンピューティングシステム９０は、コンピューティングシステム９０をＲＡＮ１０３／１０４／１０５、コアネットワーク１０６／１０７／１０９、ＰＳＴＮ１０８、インターネット１１０、または図４から８の他のネットワーク１１２などの外部通信ネットワークに接続するために使用されることがある、例えば、ネットワークアダプタ９７などの通信回路を含み、コンピューティングシステム９０がそれらのネットワークの他のノードまたは機能エンティティと通信することを可能にしてもよい。通信回路は、単独で、またはプロセッサ９１と組み合わせて、本明細書に説明されるある種の装置、ノード、または機能エンティティの伝送および受信ステップを実施するために使用されてよい。
【０３５０】
本明細書に説明される装置、システム、方法、およびプロセスのうちのいずれかまたはすべては、コンピュータ可読記憶媒体上に記憶されたコンピュータ実行可能命令（例えば、プログラムコード）の形態で具現化されてよく、その命令は、プロセッサ１１８または９１などのプロセッサによって実行されると、プロセッサに、本明細書にて説明されるシステム、方法、およびプロセスを実施および／または実装させることを理解されたい。具体的には、本明細書に説明されるステップ、動作、または機能のうちのいずれも、このようなコンピュータ実行可能命令の形態で実装され、無線および／または有線ネットワーク通信向けに構成されている装置またはコンピューティングシステムのプロセッサ上で実行されてよい。コンピュータ可読記憶媒体は、情報を記憶するための任意の非一時的（すなわち、有形または物理的）方法もしくは技術に実装される揮発性および不揮発性媒体、取り外し可能および非取り外し可能媒体を含むが、このようなコンピュータ可読記憶媒体には信号は含まれない。コンピュータ可読記憶媒体としては、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（Digital  Versatile  Disks：ＤＶＤ）または他の光学ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶デバイスまたは他の磁気記憶デバイス、もしくは所望の情報を記憶するために使用されてよく、かつコンピュータシステムによってアクセスされることがある任意の他の有形もしくは物理的媒体が挙げられるが、それらに限定されない。
【０３５１】
（付録）
【表１】
2020524439.tif 000006
【表２−１】
2020524439.tif 000007
【表２−２】
2020524439.tif 000008
【表２−３】
2020524439.tif 000009
【表３】
2020524439.tif 000010
【表４】
2020524439.tif 000011
【図１】
2020524439.tif 000012
【図２】
2020524439.tif 000013
【図３】
2020524439.tif 000014
【図４】
2020524439.tif 000015
【図５】
2020524439.tif 000016
【図６】
2020524439.tif 000017
【図７】
2020524439.tif 000018
【図８】
2020524439.tif 000019
【図９】
2020524439.tif 000020
【図１０】
2020524439.tif 000021
【図１１】
2020524439.tif 000022
【図１２】
2020524439.tif 000023
【図１３】
2020524439.tif 000024
【図１４】
2020524439.tif 000025
【図１５】
2020524439.tif 000026
【図１６】
2020524439.tif 000027
【図１７】
2020524439.tif 000028
【国際調査報告】
2020524439.tif 000029
2020524439.tif 000030
2020524439.tif 000031
2020524439.tif 000032