JP2022528081A - 通信方法および通信装置 - Google Patents

Abstract

本出願は、通信技術の分野に関連する通信方法および通信装置を提供する。本方法は、端末デバイスにより、スケジューリング要求（SR）をトリガするステップと、SRを搬送するPUCCHと第1のデータパケットを搬送するPUSCHが第1のアップリンクリソースの時間領域において重複する場合、第1のアップリンクリソース上でのPUSCHの処理状態を取得するステップと、第1のアップリンクリソース上でのPUSCHの処理状態に基づいて、重複する時間領域リソース上でPUCCHまたはPUSCHを送信するステップと、を含む。上記の方法によると、SRを搬送するPUCCHとPUSCHが第1のアップリンクリソースの時間領域において重複する場合、端末デバイスは、第1のアップリンクリソース上でのPUSCHの処理状態を考慮し、第1のアップリンクリソース上でのPUSCHの処理状態に基づいて、重複する時間領域リソース上でPUCCHまたはPUSCHを送信することを決定することができる。これは、重複する時間領域リソース上でアップリンク情報を送信する効率を保証する。

Description

関連出願の相互参照
本出願は、2019年3月29日に中国特許庁に出願された「COMMUNICATIONS METHOD AND APPARATUS」と題する中国特許出願第201910253510.2号の優先権を主張し、その全体が参照により本明細書に組み込まれる。

本出願は、通信技術の分野に関し、詳細には、通信方法および通信装置に関する。

第5世代（5th generation、5G）通信システムでは、物理アップリンク制御チャネル（physical uplink control channel、PUCCH）または物理アップリンク共有チャネル（physical uplink shared channel、PUSCH）は、送信時間単位（例えば、スロット（slot））で任意のシンボルからデータを送信することができる。送信時間長も固定されていない。例えば、送信時間長は、1～14シンボルであってもよい。

現在の5G通信システムでは、PUCCHおよびPUSCHは、同じキャリア上で同時にデータを送信することができない。しかしながら、実際のシナリオでは、PUCCHによって占有されるリソースは、PUSCHによって占有されるリソースと競合することがある。例えば、5G通信システムは、超信頼性および低レイテンシ通信（ultra reliability and low latency communication、URLLC）サービスタイプならびに拡張モバイルブロードバンド（enhanced mobile broadband、eMBB）サービスタイプなど、複数のサービスタイプをサポートすることができる。したがって、端末デバイスは、複数のサービスタイプに対する通信要求を同時に有することがあり、例えば、端末デバイスは、URLLCサービスタイプおよびeMBBサービスタイプの通信要求を同時に有する。端末デバイスに送信予定のURLLCデータがあり、スケジューリング要求（scheduling request、SR）をトリガした後、SRを搬送するPUCCHとeMBBデータを搬送するPUSCHがアップリンクリソースの時間領域において重複する可能性がある。したがって、PUCCH上のアップリンクリソースとPUSCH上のアップリンクリソースとの間の競合にどのように対処するかがさらに研究される必要がある。

これに鑑みて、本出願は、SRを搬送するPUCCHとデータを搬送するPUSCHがアップリンクリソースの時間領域において重複する場合に、データを送信するための通信方法および装置を提供する。

第1の態様によると、本出願の実施形態は、通信方法を提供し、本方法は、端末デバイスにより、スケジューリング要求SRをトリガするステップと、SRを搬送する物理アップリンク制御チャネルPUCCHと第1のデータパケットを搬送する物理アップリンク共有チャネルPUSCHが第1のアップリンクリソースの時間領域において重複すると判断した場合、第1のアップリンクリソース上でのPUSCHの処理状態を取得するステップと、第1のアップリンクリソース上でのPUSCHの処理状態に基づいて、重複する時間領域リソース上でPUCCHまたはPUSCHを送信するステップと、を含む。

前述の方法によると、SRを搬送するPUCCHとPUSCHが第1のアップリンクリソースの時間領域において重複する場合、端末デバイスは、第1のアップリンクリソース上でのPUSCHの処理状態を考慮し、第1のアップリンクリソース上でのPUSCHの処理状態に基づいて、重複する時間領域リソース上でPUCCHまたはPUSCHを送信することを決定することができ、それにより、重複する時間領域リソース上で送信されるアップリンク情報が決定され、通信システムの効率が改善される。

可能な一設計において、第1のアップリンクリソース上でのPUSCHの処理状態に基づいて、端末デバイスにより、重複する時間領域リソース上でPUCCHを送信するステップは、第1のアップリンクリソース上でのPUSCHの処理状態が処理完了である場合に、SRをトリガするための論理チャネルの第1の優先度が第1のデータパケットの論理チャネルの第2の優先度以上であると判断した場合、端末デバイスにより、重複する時間領域リソース上でPUCCHを送信するステップを含む。

このように、第1の優先度が第2の優先度よりも高いため、端末デバイスは、重複する時間領域リソース上でPUCCHを送信し、それにより、ネットワークデバイスは、PUCCHを使用して、SRをトリガする送信予定データをタイムリーにスケジューリングして、送信予定データのレイテンシを効果的に低減することができる。

可能な一設計において、第1の優先度が第2の優先度以上であると判断した場合に、端末デバイスにより、重複する時間領域リソース上でPUCCHを送信するステップは、MAC層において、第1の優先度が第2の優先度以上であると判断した場合に、端末デバイスにより、第1の指示情報を端末デバイスの物理層に送信するステップと、物理層における第1の指示情報に基づいて、端末デバイスにより、重複する時間領域リソース上でPUCCHを送信するステップと、MAC層において、端末デバイスにより、第1の優先度および第2の優先度を物理層に通知するステップと、物理層において第1の優先度が第2の優先度以上であると判断した場合に、端末デバイスにより、重複する時間領域リソース上でPUCCHを送信するステップと、を含む。第2の優先度は、端末デバイスが第1のデータパケットを組み立てるときに端末デバイスによって取得されてもよい。

第2の態様によると、本出願の実施形態は、通信方法を提供する。本方法は、端末デバイスにより、スケジューリング要求SRをトリガするステップと、SRを搬送するPUCCHと第1のデータパケットを搬送するPUSCHが第1のアップリンクリソースの時間領域において重複すると判断した場合、PUSCHによって占有されるリソースおよびSRをトリガするための論理チャネルのリソース要求に基づいて、重複する時間領域リソース上でPUCCHまたはPUSCHを送信するステップと、を含む。

前述の方法によると、SRを搬送するPUCCHとPUSCHが第1のアップリンクリソースの時間領域において重複する場合、端末デバイスは、PUSCHリソースおよびSRをトリガするための論理チャネルのリソース要求を考慮し、PUSCHリソースおよびSRをトリガするための論理チャネルのリソース要求に基づいて、重複する時間領域リソース上でPUCCHまたはPUSCHを送信することを決定することができる。これは、重複する時間領域リソース上でアップリンク情報を送信する効率を保証する。PUSCHリソースおよびSRをトリガするための論理チャネルのリソース要求は、ネットワークデバイスによって設定される情報であり、シナリオによって影響されないため、前述の方法は、比較的適用可能性が高く、複数の可能なシナリオ、例えば、新たなデータ送信シナリオまたはデータ再送シナリオに適用可能である場合がある。

可能な一設計において、端末デバイスにより、PUSCHによって占有されるリソースおよびSRをトリガするための論理チャネルのリソース要求に基づいて、重複する時間領域リソース上でPUSCHを送信するステップは、PUSCHによって占有されるリソースがSRをトリガするための論理チャネルのリソース要求を満たすと判断した場合に、端末デバイスにより、重複する時間領域リソース上でPUSCHを送信するステップを含む。

前述の方法によると、PUSCHリソースが、SRをトリガするための論理チャネルのリソース要求を満たすということは、SRをトリガするデータがPUSCHリソース上で送信され得るということを示す。この場合、PUSCHが送信されてもよく、PUSCH上で送信されるデータのレイテンシを低減することができる。

可能な一設計において、PUSCHによって占有されるリソースがSRをトリガするための論理チャネルのリソース要求を満たすと判断した場合に、端末デバイスにより、重複する時間領域リソース上でPUSCHを送信するステップは、SRをトリガするための論理チャネルの第1の優先度が第1のデータパケットの論理チャネルの第2の優先度以下であると判断した場合、端末デバイスにより、重複する時間領域リソース上でPUSCHを送信するステップを含む。

可能な一設計において、本方法は、第1の優先度が第2の優先度よりも高い場合、端末デバイスにより、重複する時間領域リソース上でPUCCHを送信するステップをさらに含む。

前述の方法を使用して、PUSCHリソースがSRをトリガするための論理チャネルのリソース要求を満たすと判断した後、端末デバイスは、優先度比較結果に基づいて、重複する時間領域リソース上でPUCCHまたはPUSCHを送信することをさらに決定し、それにより、PUSCHリソースがSRをトリガするための論理チャネルのリソース要求を満たしているが、第1の優先度が第2の優先度よりも高い場合は、端末デバイスは、依然としてPUCCHを送信する。これは、PUSCHリソースおよびSRをトリガするための論理チャネルのリソース要求のみに基づいて判断することが十分には正確でないという問題を効果的に回避し、SRをトリガする送信予定データのレイテンシを低減する。

可能な一設計において、端末デバイスにより、PUSCHによって占有されるリソースおよびSRをトリガするための論理チャネルのリソース要求に基づいて、重複する時間領域リソース上でPUCCHを送信するステップは、PUSCHによって占有されるリソースがSRをトリガするための論理チャネルのリソース要求を満たさないと判断した場合、端末デバイスにより、重複する時間領域リソース上でPUCCHを送信するステップを含む。

前述の方法によると、PUSCHリソースが、SRをトリガするための論理チャネルのリソース要求を満たさないため、端末デバイスは、重複する時間領域リソース上でPUCCHを送信し、それにより、ネットワークデバイスは、PUCCHを使用して、SRをトリガする送信予定データをタイムリーにスケジューリングして、送信予定データのレイテンシを効果的に低減することができる。

第1の態様および第2の態様の可能な設計に基づいて、端末デバイスが第1のアップリンクリソース上でPUCCHを送信する場合、本方法は、端末デバイスにより、第2のアップリンクリソース上で第1のデータパケットを送信するステップであって、第2のアップリンクリソースおよび第1のアップリンクリソースは、同じHARQプロセスに対応する、ステップをさらに含む。

前述の方法によると、第1のデータパケット損失または第1のデータパケットの比較的大きなサービス性能損失を回避するために、第1のデータパケットが再度送信され得る。

可能な一設計において、第1のデータパケットは、第2のアップリンクリソースに対応するHARQプロセスのバッファに記憶される。

第1の態様および第2の態様の可能な設計に基づいて、端末デバイスが第1のアップリンクリソース上でPUCCHを送信する場合、本方法は、端末デバイスにより、第2のアップリンクリソース上で第2のデータパケットを送信するステップであって、第2のデータパケットは、第1のデータパケットの情報の一部または全部を含む、ステップをさらに含む。

このようにして、第1のデータパケットの情報の一部または全部が、データ再組立てを介して第2のデータパケットに再組み立てされ、それにより、ネットワークデバイスは、第1のデータパケットの情報の一部または全部を取得することができ、データ損失を効果的に回避する。

第1の態様および第2の態様の可能な設計に基づいて、端末デバイスが第1のアップリンクリソース上でPUCCHを送信する場合、本方法は、端末デバイスにより、第3の指示情報をネットワークデバイスに送信するステップであって、第3の指示情報は、第1のデータパケットが送信されていないか、または完全には送信されていないことを示すために用いられる、ステップをさらに含む。このようにして、第3の指示情報がネットワークデバイスに送信されるため、ネットワークデバイスは、第1のデータパケットが送信されていないか、または完全には送信されていないことを知ることができ、再送を容易にし、データ損失を回避する。

第3の態様によると、本出願の実施形態は、通信方法を提供する。本方法は、
端末デバイスにより、第1のアップリンクリソース上で送信される第1のデータパケットを組み立てるステップと、第1のデータパケットが送信されていないか、または完全には送信されていないと判断した場合、第2のアップリンクリソース上で第1のデータパケットを送信するステップであって、第2のアップリンクリソースおよび第1のアップリンクリソースは、同じHARQプロセスに対応する、ステップと、
を含む。

可能な一設計において、第1のデータパケットは、第2のアップリンクリソースに対応するHARQプロセスのバッファに記憶される。

第4の態様によると、本出願の実施形態は、SRトリガリング方法を提供する。本方法は、
端末デバイスにより、複数のBSRをトリガするステップであって、複数のBSRが複数のSRにそれぞれ対応する、ステップと、複数のSRを搬送する複数のPUCCHが第3のアップリンクリソースの時間領域において重複すると判断した場合、複数のBSRをトリガするための論理チャネルの優先度に基づいてターゲットBSRを決定するステップであって、ターゲットBSRをトリガするための論理チャネルの優先度が複数のBSRにおける別のBSRをトリガするための論理チャネルの優先度以上である、ステップと、端末デバイスにより、ターゲットBSRに対応するSRをトリガするステップと、
を含む。

前述の方法によると、複数のBSRをトリガするための論理チャネルの優先度が比較されて、トリガされるSRを決定し、対応する送信予定データのレイテンシを効果的に低減する。

第5の態様によると、本出願の実施形態は、通信方法を提供する。本方法は、
端末デバイスにより、第1のアップリンクリソース上で送信される第1のデータパケットを組み立て、第1のデータパケットが送信されていないか、または完全には送信されていないと判断した場合、第2のアップリンクリソース上で第2のデータパケットを送信するステップであって、第2のデータパケットは、第1のデータパケットの情報の一部または全部を含む、ステップ
を含む。

第6の態様によると、本出願の一実施形態は装置を提供する。本装置は、端末デバイスであってよく、または端末デバイス内に配置されたチップであってよい。本装置は、第1の態様から第5の態様の様々な可能な設計を実施する機能を有する。機能は、ハードウェアによって実施されてもよく、または対応するソフトウェアを実行することでハードウェアによって実施されてもよい。ハードウェアまたはソフトウェアは、前述の機能に対応する1つまたは複数のユニットまたはモジュールを含む。

第7の態様によると、本出願の実施形態は、プロセッサおよびメモリを含む装置を提供する。本プロセッサは、メモリに記憶された命令を実行するように構成され、命令が実行されると、装置は、第1の態様から第5の態様のいずれかの可能な設計において方法を実行可能となる。

第8の態様によると、本出願の実施形態は、命令を含むコンピュータ可読記憶媒体をさらに提供する。命令が実行されると、前述の態様または前述の態様の可能な設計のいずれかにおいて方法が実施される。

第9の態様によると、本出願の実施形態は、コンピュータプログラムまたは命令を含むコンピュータプログラム製品をさらに提供する。コンピュータプログラムまたは命令が実行されると、前述の態様または前述の態様の可能な設計のいずれかにおいて方法が実施される。

本出願の実施形態が適用可能である可能なシステムアーキテクチャの概略図である。 繰り返しメカニズムの可能な概略図である。 繰り返しメカニズムの可能な概略図である。 繰り返しメカニズムの可能な概略図である。 本出願の実施形態1による通信方法に対応する概略フローチャートである。 本出願の実施形態による、PUCCHとPUSCHが第1のアップリンクリソースの時間領域において重複する例である。 本出願の実施形態による、PUCCHおよびPUSCHが第1のアップリンクリソースの時間領域において重複する別の例である。 本出願の実施形態2による通信方法に対応する概略フローチャートである。 第2のアップリンクリソース上で第1のデータパケットを送信する概略図である。 本出願の一実施形態による装置の可能な例示的なブロック図である。 本出願の一実施形態による装置の概略構造図である。 本出願の一実施形態による端末デバイスの概略構造図である。

本出願の実施形態の目的、技術的解決策、および利点をより明確にするために、以下では、添付の図面を参照して本出願の実施形態をさらに詳細に説明する。

当業者がより良く理解するのを助けるために、最初に、本出願の実施形態のいくつかの用語が説明される。

（1）端末デバイスは、無線トランシーバ機能を有するデバイスであり、陸上に配備されてもよく、その配備は、屋内もしくは屋外、ハンドヘルド、ウェアラブル、または車載配備を含み、水上に（例えば、船舶に）配備されてもよく、空中に（例えば、航空機、気球、および衛星に）配備されてもよい。端末デバイスは、携帯電話機（mobile phone）、タブレット（Pad）、無線トランシーバ機能を有するコンピュータ、仮想現実（virtual reality、VR）端末デバイス、拡張現実（augmented reality、AR）端末デバイス、産業用制御（industrial control）の無線端末、自動運転（self driving）の無線端末、遠隔医療（remote medical）の無線端末、スマートグリッド（smart grid）の無線端末、輸送安全性（transportation safety）の無線端末、スマートシティ（smart city）の無線端末、スマートホーム（smart home）の無線端末などであってもよい。本出願の実施形態では、適用シナリオは限定されない。端末デバイスは、ユーザ機器（user equipment、UE）、移動局、遠隔局などと呼ばれることもある。本出願の実施形態では、端末デバイスは、独立して販売される端末全体であってよく、または端末の機能を実装するチップであってよい。端末デバイスによって使用される特定の技術、デバイス形態、および名称は、本出願の実施形態において限定されない。

（2）ネットワークデバイスは、端末デバイスがこの移動通信システムに無線方式でアクセスするために使用されるアクセスデバイスであり、基地局、進化型NodeB（evolved NodeB、eNodeB）、送受信点（transmission reception point、TRP）、5G移動通信システムにおける次世代NodeB（next generation NodeB、gNB）、将来の移動通信システムにおける基地局、またはワイヤレスフィデリティ（wireless-fidelity、Wi-Fi）システムにおけるアクセスノードであってよく、あるいは基地局のいくつかの機能を完全なものにするモジュールもしくはユニットであってよく、例えば、中央ユニット（central unit、CU）であってよく、または分散型ユニット（distributed unit、DU）であってよい。本出願の実施形態では、ネットワークデバイスは、独立して販売されるアクセスデバイスであってよく、またはアクセスデバイスの機能を実装するチップであってよい。ネットワークデバイスによって使用される特定の技術および特定のデバイス形態は、本出願の実施形態において限定されない。

（3）「システム」という用語と「ネットワーク」という用語は、本出願の実施形態では区別なく用いられる場合がある。「少なくとも1つ」は、1つまたは複数を意味し、「複数」は、2つ以上を意味する。「および／または」という用語は、関連付けられる対象を記述するための関連付け関係を記述し、3つの関係が存在し得ることを表す。例えば、Aおよび／またはBは、以下の場合を、すなわち、Aのみが存在する場合、AおよびBの両方が存在する場合、およびBのみが存在する場合を表してもよく、その場合、AおよびBは、単数または複数であり得る。記号「／」は一般に、関連付けられた対象間の「または」関係を示す。「以下の項目（ピース（piece））のうちの少なくとも1つ」または同様の表現は、単数の項目（ピース）または複数の項目（ピース）の任意の組み合わせを含めて、これらの項目の任意の組み合わせを意味する。例えば、a、b、またはcのうちの少なくとも1つの項目（ピース）は、a、b、c、a-b、a-c、b-c、またはa-b-cを表すことができ、ここでa、b、およびcは、単数または複数であってもよい。

加えて、特に明記しない限り、本出願の実施形態における「第1」および「第2」などの序数は、複数の対象物を区別するために使用されるが、複数の対象物の順序、時系列、優先度、または重要性を限定することは意図されていない。例えば、第1の指示情報および第2の指示情報は、異なる指示情報を単に区別するためのものであり、これらの2つのタイプの指示情報の内容、優先度、送信シーケンス、重要性などが異なることを示すものではない。

図1は、本出願の実施形態が適用可能である可能なシステムアーキテクチャの概略図である。図1に示されるシステムアーキテクチャは、ネットワークデバイスおよび端末デバイスを含む。システムアーキテクチャにおけるネットワークデバイスの数量および端末デバイスの数量は、本出願の実施形態において限定されないことを理解されたい。ネットワークデバイスおよび端末デバイスに加えて、本出願の実施形態が適用可能なシステムアーキテクチャは、コアネットワークデバイス、無線中継デバイス、または無線バックホールデバイスなどの別のデバイスをさらに含むことができる。これについても本出願のこの実施形態では限定されない。加えて、本出願の実施形態におけるネットワークデバイスは、すべての機能を1つの独立した物理デバイスに統合することができ、または複数の独立した物理デバイス上に機能を分散させることができる。このことも本出願の実施形態では限定されない。加えて、本出願の本実施形態における端末デバイスは、無線方式でネットワークデバイスに接続されてもよい。

上記で示されたシステムアーキテクチャは、様々な無線アクセス技術（radio access technology、RAT）の通信システム、例えば、ロングタームエボリューション（long term evolution、LTE）通信システム、5G通信システム、および別の可能な通信システムに適用可能であってもよい。

本出願の実施形態に記載されるシステムアーキテクチャおよびサービスシナリオは、本出願の実施形態における技術的解決策をより明確に説明するためのものであり、本出願の実施形態で提供される技術的解決策に対する限定を構成するものではない。通信システムアーキテクチャが進化し、新しいサービスシナリオが出現するにつれて、本出願の実施形態で提供される技術的解決策は、同様の技術的問題にも適用可能であることを、当業者は知るであろう。

5G通信システムが例として使用される。アップリンク送信のために使用されるアップリンクチャネルは、PUSCHおよびPUCCHを含むことができる。PUSCHは、データおよび／またはアップリンク制御情報（uplink control information、UCI）を搬送することができ、PUCCHは、UCIを搬送することができる。PUCCH上で搬送されるUCIは、SRを含むことができる。SRは、端末デバイスによってネットワークデバイスに送信されるスケジューリング要求情報であると理解されてもよく、端末デバイスに送信予定のアップリンクデータがあることを示す。

以下では、本出願の本実施形態における一部の実施態様またはメカニズムを説明する。これらの説明は、本出願の本実施形態をより容易に理解させることが意図されているが、本出願において特許請求される保護範囲を限定するものと考えられるべきではないことに留意されたい。

（1）SRのトリガ
5G通信システムのデータは、MAC層において論理チャネル（logical channel、LCH）を使用して搬送されてもよく、異なるサービスタイプのデータは、異なる論理チャネルを使用して搬送されてもよい。1つまたは複数の論理チャネルは、1つの論理チャネルグループ（logical channel group、LCG）に関連付けられてもよい。各論理チャネルは、1つのスケジューリング優先度に関連付けられてもよい。優先度は、ネットワークデバイスによって設定されてもよい。例えば、URLLCサービスデータを搬送する論理チャネルには比較的高い優先度が設定されてもよく、eMBBサービスデータを搬送する論理チャネルには比較的低い優先度が設定されてもよい。言い換えれば、URLLCサービスデータは、比較的高い優先度を有し、eMBBサービスデータは、比較的低い優先度を有する。したがって、端末デバイスが利用可能なアップリンクリソースを有する場合、リソース割当ては、高い優先度を有するデータに対して優先的に考慮されてもよい。端末デバイスに送信予定の新たなデータがあるが、いずれの論理チャネルも送信予定データがない場合、またはより高い優先度を有する論理チャネルに送信予定データがある場合、端末デバイスは、バッファ状態報告（buffer status report、BSR）をトリガして、ネットワークデバイスによるスケジューリングのために、少なくとも1つの論理チャネル上に送信予定データの総量を反映させることができる。

しかしながら、ネットワークデバイスは、制御シグナリングを配信してリソースを示す前に、端末デバイスに送信予定データがあることを知らない場合がある。したがって、端末デバイスがBSRをトリガし、データを送信するための利用可能なアップリンクリソースがない場合、端末デバイスは、まず、事前設定されたまたは共通のアップリンクリソースを使用して、ネットワークデバイスにアップリンクリソースを割り当てるように要求することができる。例えば、端末デバイスは、SRをトリガすることによってアップリンクリソースを要求することができ、または端末デバイスは、ランダムアクセスチャネル（random access channel、RACH）を使用してアップリンクリソースを要求することができる。SRは、端末デバイスのためにネットワークデバイスによって事前設定された、アップリンクリソースを要求するために使用されるPUCCH上で搬送されてよく、ランダムアクセスは、物理ランダムアクセスチャネル（physical random access channel、PRACH）上で実行されてよい。一例では、PUCCHによって占有されるリソース（またはPUCCHリソースとも呼ばれこともある）は、周期的リソースであってもよく、ネットワークデバイスは、PUCCHリソース情報を設定することができ、例えば、PUCCHリソース情報は、開始時間情報および周期を含むことができる。それに応じて、設定されたPUCCHリソース情報を取得した後に、端末デバイスは、周期的なSR送信機会（SR transmission occasion）を判断することができ、それにより、SRをトリガするとき、端末デバイスは、SR送信機会にSRを送信することができる。

（2）SRの送信
端末デバイスにおける送信予定データは、複数の異なるサービスタイプに属する可能性があると考えられる。ネットワークデバイスが端末デバイスにおける送信予定データのサービスタイプについて学習するのを助け、適切なリソースをスケジューリングするために、SR設定と論理チャネルとの間の関連付け関係が5G通信システムに導入されている。具体的には、ネットワークデバイスは、端末デバイスのための1つまたは複数のSR設定を設定することができる。各SR設定は、利用可能なPUCCHリソースを含む。これらのPUCCHリソースは、異なるセル、または異なる周波数領域の位置にある同じセルの異なる帯域幅部分（bandwidth part、BWP）に分配されてもよい。データを搬送するために使用される端末デバイスの論理チャネルについて、各論理チャネルは、1つのSR設定に関連付けられてもよい。言い換えれば、異なる論理チャネルが異なるSR設定に関連付けられてもよい。例えば、端末デバイスに対して、2つの論理チャネル、LCH＃1およびLCH＃2が設定される。LCH＃1は、eMBBサービスデータを搬送するために使用され、SR設定＃1（PUCCHリソース＃1）に対応する。LCH＃2は、URLLCサービスを搬送するために使用され、SR設定＃2（PUCCHリソース＃2）に対応する。

このように、異なるサービスタイプのデータが送信されようとする場合、端末デバイスは、データを搬送するために使用される論理チャネルに対応するSR設定に基づいてSRを送信することができ、それにより、ネットワークデバイスは、端末デバイスの現在の送信予定データのサービスタイプを認識する。例えば、URLLCサービスデータが送信されようとする場合、端末デバイスは、PUCCHリソース＃2を使用してSRを送信することができる。このようにして、PUCCHリソース＃2によって搬送されるSRを検出した後、ネットワークデバイスは、端末デバイスの送信予定データがURLLCサービスデータであることを学習することができ、それにより、URLLCサービスデータに適用可能なアップリンクリソースがスケジューリングされ得て、例えば、より短いPUSCH持続時間またはより信頼性の高いアップリンクリソースがスケジューリングされ得て、URLLCサービスデータの送信要求（具体的には、低レイテンシおよび高信頼性）を満たすことができる。

（3）動的スケジューリングおよび事前設定されるスケジューリング
ネットワークデバイスがSRまたはランダムアクセスに基づいてアップリンクリソースをスケジューリングする方式は、動的スケジューリングであると理解されてもよい。動的スケジューリングとは、ネットワークデバイスが、物理層シグナリング（例えば、ダウンリンク制御情報（downlink control information、DCI））を使用してリソース、例えば、アップリンクグラント（uplink grant）を示すことを意味する。DCIは、PUSCHによって占有されるリソース（またはPUSCHリソースと呼ばれることもある）に関する情報を搬送することができ、例えば、時間領域におけるリソース位置および周波数領域におけるリソース位置が含まれる。それに応じて、端末デバイスは、アップリンクグラントを受信した後、リソースサイズに基づいてトランスポートブロックサイズ（transport block size、TBS）を計算し、TBSに基づいてデータを組み立て、対応するリソース上でデータをさらに送信することができる。

しかしながら、URLLCサービスデータは、随時到着する可能性がある。SRまたはランダムアクセスを使用してリソースが要求される場合、遅すぎる可能性がある。したがって、ネットワークデバイスは、事前設定されたスケジューリング方式で高密度の周期的リソースをさらに事前設定することができる。端末デバイスのURLLCサービスデータが送信されようとするとき、アップリンクリソースがURLLCサービスデータを送信するために直ちに利用可能であり、それにより、レイテンシが低減され得る。事前設定されたスケジューリングは、設定されたグラント送信（configured grant transmission）と呼ばれることもある。設定されたグラント送信は、2つのタイプに分類されることがある。タイプ1（Type1）は、ネットワークデバイスが周期および開始オフセットを設定し、RRCを使用して特定のリソース位置を示すことを意味し、言い換えれば、RRCは、アップリンクグラントを搬送することができる。端末デバイスがRRCシグナリングのリリースコマンドを受信しない限り、リソースは、周期的に出現すると考えられてもよい。タイプ2（Type2）は、ネットワークデバイスが無線リソース制御（radio resource control、RRC）シグナリングを使用して周期および開始オフセットを設定し、次いで、DCIを使用して特定のリソース位置をアクティブにして、示すことを意味する。端末デバイスが非アクティブ化コマンドを受信しない限り、DCIによって示されるリソースは、周期的に出現すると考えられてもよい。設定されたグラント送信を使用する利点は、ネットワークデバイスが毎回制御シグナリングを配信してリソースを割り当てる必要がないため、制御シグナリングのオーバヘッドが低減され得て、UEによってSRおよびBSRを送信する際のレイテンシが低減され得ることにある。事前設定されたスケジューリング方式を使用することは、URLLCサービスデータに対してSR設定が設定される必要がないことを意味するものではないことに留意されたい。非周期的URLLCサービスデータを搬送する論理チャネルにも対応するSR設定が設定されてもよい。

（4）論理チャネル優先順位付け（logical channel prioritization、LCP）マッピング制約
端末デバイスの観点からは、端末デバイスがデータ送信に使用可能なアップリンクリソース（スケジューリングのために動的にスケジューリングされ得る、または事前設定され得るリソースであってもよい）を受信した後、不適切なデータがアップリンクリソース上に配置されている場合（言い換えれば、不適切なリソース上にデータが配置されている場合）、データ要求が満たされないか、または通信システムの効率が低減されることがある。したがって、適切なデータを適切なリソースに配置するために、論理チャネルを選択するステップが導入される。具体的には、ネットワークデバイスは、端末デバイスのために、論理チャネルからの、アップリンクリソースのパラメータに対するLCPマッピング制約を事前設定することができる。論理チャネルからの、アップリンクリソースのパラメータに対するLCPマッピング制約は、論理チャネルのリソースに対する要求、または論理チャネルに対応するリソースのパラメータであると理解されてもよい。例えば、リソースに対する論理チャネルの要求は、リソースの時間領域長に対する要求（例えば、リソースの最大時間領域長）を含んでもよく、または論理チャネルに対応するリソースのパラメータがリソースの時間領域長を含むことであると説明されてもよい。このように、端末デバイスは、アップリンクリソースを受信した後、アップリンクリソースのパラメータに基づいて、アップリンクリソースの論理チャネルにマッピングされ得るデータパケットを選択することができ、不適切なデータを配置することを回避することができる。アップリンクリソースが論理チャネルのリソース要求を満たすことができる場合、その論理チャネルは、アップリンクリソースにマッピングされ得る論理チャネルであり、またはアップリンクリソースにマッピングされ得る論理チャネルは、対応するリソースのパラメータがアップリンクリソースのパラメータと一致する論理チャネルである。例えば、リソースの最大時間領域長に対するLCH＃1（URLLCサービスデータを搬送する）の要求は、0.5ms（または、LCH＃1に対応するリソースの最大時間領域長が0.5ms）であり、リソースの最大時間領域長に対するLCH＃2（eMBBサービスデータを搬送する）の要求は、1ms（または、LCH＃2に対応するリソースの最大時間領域長が1ms）である。アップリンクリソースの時間領域長が1msである場合、アップリンクリソースは、eMBBサービスデータをスケジューリングするためのリソースであると考えられてもよく、LCH＃2は、LCPマッピング制約関係を満たす論理チャネルであり、それにより、端末デバイスは、パケット組立てのためにLCH＃2のデータを選択することができる。

リソースの時間領域長に対する前述の要件に加えて、リソースに対する論理チャネルの要件は、別の可能な要件、例えば、許容されるサブキャリア間隔、設定されるグラント周期、許容される変調および符号化方式テーブル、または信頼性要件、および許容される設定されたグラント設定をさらに含むことができることに留意されたい。これは、本出願のこの実施形態では限定されない。

（5）再送メカニズム
データ伝送の信頼性を保証するために、再送メカニズムが5G通信システムに導入されている。媒体アクセス制御（medium access control、MAC）層によって管理される再送は、ハイブリッド自動再送要求（hybrid automatic repeat request、HARQ）と呼ばれる。簡単に言えば、受信端がデータの受信に成功しなかった場合、受信端は否定応答（negative acknowledgment、NACK）を送信端にフィードバックする。それに応じて、送信端は、NACKを受信した後、送信に失敗したデータを再送することができる。このメカニズムでは、送信端には、同時に送信されるまたは再送予定のいくつかのデータがあるため、再送する必要があるデータを正確に識別するために、HARQプロセスおよびHARQ IDが導入される。具体的には、各HARQプロセスは、1つのHARQ IDおよび1つのバッファ（Buffer）に対応することができ、媒体アクセス制御プロトコルデータユニット（medium access control protocol data unit、MAC PDU）またはトランスポートブロック（transport block、TB）を記憶するために使用される。例えば、1つのセルは、最大16個のHARQプロセスを有する。言い換えれば、最大16個のデータパケットが同時に送信されてもよく、または送信のために準備されていてもよい。アップリンクデータをスケジューリングするとき、ネットワークデバイスは、明示的または暗示的なやり方でこのデータに対応するHARQ IDを示す。ネットワークデバイスがこのデータの再送を求めるとき、ネットワークデバイスは、同様にHARQ IDを示す。このように、端末デバイスは、HARQ IDに基づいて、どのデータが再送される必要があるかを知ることができる。具体的には、端末デバイスは、HARQ IDに基づいて、物理層に対応するバッファから、記憶されたトランスポートブロック（transport block、TB）、すなわち、MAC PDUを取得することができ、次いで、HARQ情報（例えば、冗長バージョン）に基づいて再送を行うことができ、パケット組立てを行う必要はない。

動的スケジューリングの場合、データが属するHARQ IDは、DCIによって直接指示されてもよい。事前設定されたスケジューリングの場合、各リソースのHARQ IDは、リソースの時間領域の位置および／または周波数領域の位置に基づいて計算されてもよい。動的スケジューリングの再送は、動的なスケジューリングであってもよく、事前設定されたスケジューリングの再送も動的なスケジューリングであってもよい。言い換えれば、事前設定されたスケジューリングは、通常、データの初回の送信のみに使用され、再送には使用されない。

事前設定されたスケジューリングの場合、設定されたタイマ（configured grant timer）が導入されてもよい。端末デバイスは、事前設定されたスケジューリングリソース上でデータを送信した後、タイマを開始する。タイマの動作中に、端末デバイスは、データが送信される事前設定されたスケジューリングリソースと同じ、HARQプロセスに属する事前設定されたスケジューリングリソースを使用してデータを送信することができない。前述の説明に基づいて、事前設定されたスケジューリングは通常、データの初回の送信のみに使用されるため、前のデータが送信に成功しなかった場合、またはネットワークデバイスからのフィードバックをまだ待っていて、同じHARQプロセスに属する新たな事前設定されたスケジューリングリソースが到着した場合、端末デバイスは、新たな送信を実行し、新たなデータパケットは、古いデータパケットを上書きする。その結果、ネットワークデバイスは、前のデータを再送する機会がない可能性がある。言い換えれば、タイマは、ネットワークデバイスに処理期間およびフィードバック期間を与えるように構成されている。タイマが満了した後、端末デバイスは、ネットワークデバイスが再送をスケジュールしないと判断することができ、HARQ IDに対応するリソースをさらに使用することができる。各HARQプロセスは、1つのタイマを維持することができ、言い換えれば、1つのタイマのみが、タイマに対応するHARQプロセスの事前設定されたスケジューリングリソースに対して使用されてもよく、別のHARQプロセスの事前設定されたスケジューリングリソースには使用され得ない。

（6）繰り返し（repetition）メカニズム
リソースについて、繰り返しメカニズムが端末デバイスに設定されている場合、端末デバイスは、自動的に、連続するK個の時点に同じサイズおよび同じ位置のリソースが存在するとデフォルトでみなし、端末デバイスは、これらのリソース上でデータをK回繰り返し送信する。言い換えれば、端末デバイスは、データを自動的に再送する。ここで、Kもネットワークデバイスによって設定される。図2（a）、図2（b）、および図2（c）はそれぞれ、繰り返しメカニズムの可能な概略図である。

前述の説明に基づいて、以下では、具体的な実施形態を参照して本出願の実施形態を詳細に説明する。

5G通信システムでは、アップリンクのシングルキャリア機能を維持するために、端末デバイスは通常、PUCCH上でのUCI（SRを含む）の送信と、PUSCH上でのデータ情報の送信を同時に行うことができない。しかしながら、端末がPUCCH上でネットワークデバイスにUCIを送信する場合、PUCCHの送信期間とPUSCHの送信期間が競合する可能性がある。言い換えれば、UCIの送信期間が、PUSCH上でのデータ情報の送信期間と重複する。例えば、本出願の実施形態におけるPUCCHの送信期間とPUSCHの送信期間との間の競合は、主に、同一キャリア上で送信されるPUCCHとPUSCHとの間で送信期間の競合が起きるシナリオに対してである。

PUCCHの送信期間とPUSCHの送信期間が競合する場合、可能な解決策は以下の通りである。SRを搬送するPUCCHとPUSCHがアップリンクリソースの時間領域において重複する場合、端末デバイスは、常にPUSCHを送信するが、SRを送信しない。その理由は、端末デバイスが、MAC層において、PUSCH上で送信されるデータパケット（すなわち、MAC PDU）を組み立てる前に、端末デバイスが、送信される必要があるSRがあると判断した場合、端末デバイスは、MAC層において、SRをトリガするBSRをデータパケットに組み立てることができるためである。言い換えれば、PUSCHによって送信されるデータパケットは、BSRを含むことができる。BSRは、現時点での端末デバイスにおける各論理チャネルグループの送信予定データの量を反映するために使用され、ネットワークデバイスは、それに続いて、BSRに基づいて効果的なスケジューリングを実行することができる。

しかしながら、一例において、SRを搬送するPUCCHと時間領域において重複するPUSCHが再送リソースである場合、PUSCH上で送信されるデータパケットは、現時点の端末デバイスの送信予定データの量を反映することができない。したがって、SRは、PUSCHが送信された後の次の利用可能なSR送信機会に送信される。SRをトリガするデータがURLLCサービスデータであるが、PUSCH上で送信されるデータパケットのデータがeMBBサービスデータである場合、URLLCサービスデータのレイテンシは、低減され得ない。

さらに別の例では、eMBBサービスデータのMAC PDUが組み立てられた後に、URLLCサービスデータによってトリガされたSRが発生した場合、PUSCHによって送信されるMAC PDUは、送信されるURLLCサービスデータがあることを反映することができない。言い換えれば、MAC PDUに含まれるBSRは、URLLCサービスデータの最新の状態を反映することができない。したがって、SRは、PUSCHが送信された後の次の利用可能なSR送信機会に送信される。その結果、URLLCサービスデータのレイテンシが低減され得ない。

さらに別の例では、eMBBサービスデータのMAC PDUが組み立てられる前にURLLCサービスデータによってトリガされたSRが発生した場合、PUSCHによって送信されるMAC PDUは、BSRを含むことができ、URLLCサービスデータの状態を反映することができる。この場合、PUSCHは、URLLCサービスデータにネットワークデバイスによるスケジューリングを待つように指示することができる。しかしながら、eMBBサービスデータをスケジューリングするためのPUSCHリソースの信頼性は、URLLCサービスデータのリソース要求を満たしていない可能性があり、PUSCHは、スロット（slot）（具体的には、ms粒度）に基づいてeMBBサービスデータをスケジューリングする可能性が非常に高い。その結果、URLLCサービスデータのレイテンシが低減され得ない。

これに基づいて、本出願の実施形態は、SRを搬送するPUCCHとPUSCHがアップリンクリソースの時間領域において重複する場合のデータ送信を解決するための通信方法を提供する。実施形態1および実施形態2を参照されたい。

実施形態1
図3は、本出願の実施形態1による通信方法に対応する概略フローチャートである。図3に示されるように、本方法は以下のステップを含む。

ステップ301：端末デバイスがSRをトリガする。

例えば、端末デバイスに、送信予定の新たなデータがあるが、どの論理チャネルにも送信予定データがないか、優先度のより高い論理チャネルに送信予定データがある場合、端末デバイスは、BSRをトリガすることができ、BSRに対応するSRをさらにトリガすることができる。詳細については、SRのトリガに関する前述の関連説明を参照されたい。

ステップ302：SRを搬送するPUCCHと第1のデータパケットを搬送するPUSCHが第1のアップリンクリソースの時間領域において重複し、重複が部分的な重複および完全な重複を含むと判断した場合、端末デバイスは、第1のアップリンクリソース上でのPUSCHの処理状態を取得する。PUSCHリソースは、動的にスケジュールされたリソース、または事前設定されたスケジュールされたリソースであってもよい。これは特に限定されない。PUSCH上で搬送される第1のデータパケットは、第1のアップリンクリソース上で送信予定のデータパケットであると理解されてもよい。

本出願の本実施形態では、PUCCHとPUSCHが第1のアップリンクリソースの時間領域において重複する複数のケースが存在する可能性がある。例えば、図4aを参照すると、PUSCHリソースは、スロットnに位置され、時間領域長は、6シンボルである。スロットnの開始シンボルがシンボル1の場合、PUSCHリソースは、シンボル1～シンボル6を占有すると考えられてもよい。PUCCHリソースもスロットnに位置され、時間領域長は、2シンボルであり、PUCCHリソースは、シンボル5およびシンボル6を占有する。この場合、PUCCHとPUSCHは、シンボル5およびシンボル6で重複する。別の例として、図4bを参照すると、PUSCHリソースは、スロットnに位置され、時間領域長は、6シンボルであり、PUSCHリソースは、シンボル1からシンボル6を占有する。PUCCHリソースもスロットnに位置され、時間領域長は、2シンボルであり、PUCCHリソースは、シンボル1およびシンボル2を占有する。この場合、PUCCHとPUSCHは、シンボル1およびシンボル2で重複する。

一例では、第1のアップリンクリソースは、時間領域において、PUCCHとPUSCHが重複する時間領域リソースを含むことができる。言い換えれば、時間領域の観点から、重複する時間領域リソースは、PUSCHに対応するアップリンクグラントが示すリソースの一部であると理解されてもよい。例えば、図4aを参照すると、PUSCHに対応するアップリンクグラントによって示されるリソースは、時間領域においてシンボル1からシンボル6を含み、重複する時間領域リソースは、シンボル5およびシンボル6を含むことができる。別の例では、図4bを参照すると、PUSCHに対応するアップリンクグラントによって指示されるリソースは、時間領域においてシンボル1からシンボル6を含み、重複する時間領域リソースは、シンボル1およびシンボル2を含むことができる。

本出願の本実施形態において重複する時間領域リソース上でPUCCHを送信することは、シンボル5およびシンボル6上でPUCCHを送信すること（図4a）、またはシンボル1およびシンボル2上でPUCCHを送信すること（図4b）であると理解されてもよいことに留意されたい。本出願の本実施形態において、第1のアップリンクリソースは、PUSCHに対応するアップリンクグラントによって指示されるリソースであると理解されてもよい。例えば、第1のアップリンクリソース上でのPUSCHの処理状態は、PUSCHに対応するアップリンクグラントによって指示されるリソースの処理状態であると理解されてもよい。別の例では、第1のアップリンクリソース上で送信される第1のデータパケットは、PUSCHに対応するアップリンクグラントによって指示されるリソース上で送信されるデータパケットであると理解されてもよい。

本出願の本実施形態では、第1のアップリンクリソース上でのPUSCHの処理状態は、処理完了および処理未完了を含むことができる。例えば、第1のアップリンクリソース上でのPUSCHの処理状態が処理完了であることは、以下のケースのうちの少なくとも1つを意味することができる。（1）第1のアップリンクリソース上で送信される第1のデータパケット（すなわち、MAC PDU）の組立てが完了していること、言い換えれば、第1のパケットが多重化および組立てエンティティ（multiplexing and assembly entity）を使用して取得されていること、またはLCPプロセスが完了されているかもしくは実行中であることである。LCPプロセスは、LCPマッピング制約に基づいて論理チャネルを選択するプロセス、または論理チャネルが選択された後に、選択された論理チャネルの送信予定データを組み立てるプロセスとして理解されてもよい。（2）PUSCHに対応するアップリンクグラントおよび／または第1のデータパケットがHARQエンティティに配信されていること、（3）PUSCHに対応するアップリンクグラントおよび／または第1のデータパケットがHARQプロセスに配信したこと、（4）第1のデータパケットが物理層に配信されていること、（5）PUSCHに対応するアップリンクグラントがアップリンク再送または繰り返しを示すために使用されていること、（6）第1のデータパケットが再送されたデータパケットであること、および（7）第1のデータパケットが送信中であることである。

例えば、第1のアップリンクリソース上でのPUSCHの処理状態が処理未完了であることは、以下のケースのうちの少なくとも1つを意味することができる。（1）第1のアップリンクリソース上で送信される第1のデータパケットの組立てが完了していないこと、言い換えれば、第1のデータパケットが多重化および組立てエンティティを使用して取得されていないこと、（2）アップリンクグラントおよび／またはPUSCHに対応する第1のデータパケットがHARQエンティティに配信されていないこと、（3）アップリンクグラントおよび／またはPUSCHに対応する第1のデータパケットが、HARQプロセスに配信されていないこと、（4）第1のデータパケットが物理層に配信されていないこと、（5）第1のアップリンクリソース上で送信される第1のデータパケットが取得されていないこと、言い換えれば、第1のデータパケットがスキップ（skip）されていることである。例えば、端末には、送信予定データがなく、アップリンクグラントを動的に無視することが許可されていること、および（6）第1のデータパケットの送信が開始されないか、または完全には送信されないことがある。

第1のアップリンクリソース上でのPUSCHの処理状態が処理完了または処理未完了であるケースについて、前述の列挙されたケースは、単に一部の例にすぎないことに留意されたい。具体的な実施態様では、別の可能なケースがさらに含まれてもよい。これは、本出願のこの実施形態では限定されない。

ステップ303：端末デバイスは、第1のアップリンクリソース上でのPUSCHの処理状態に基づいて、重複する時間領域リソース上でPUCCHまたはPUSCHを送信する。

ここで、第1のアップリンクリソース上でのPUSCHの処理状態が処理完了および処理未完了を含むことがあるため、以下では、2つの処理状態における実施態様を別々に詳細に説明する。

（1）第1のアップリンクリソース上でのPUSCHの処理状態が処理完了である。

この場合、端末デバイスは、SRをトリガするための論理チャネルの第1の優先度（Priority-SR）を、第1のデータパケットの論理チャネルの第2の優先度（Priority-PUSCH）と比較することによって、PUCCHまたはPUSCHを送信することができる。

例えば、端末デバイスは、層間指示方式でPUCCHまたはPUSCHを送信することができる。複数の層間指示方式が存在してもよい。可能な実施態様において、端末デバイスは、MAC層において第1の優先度を第2の優先度と比較し、比較結果に基づいて、PUCCHまたはPUSCHを送信することを決定し、指示情報1を物理層に送信して、端末デバイスが指示情報1に基づいて物理層においてPUCCHまたはPUSCHを送信するようにしてもよい。さらに別の可能な実施態様では、端末デバイスは、MAC層において第1の優先度および第2の優先度を物理層に通知し、次いで、物理層において第1の優先度と第2の優先度を比較し、比較結果に基づいて、PUCCHまたはPUSCHを送信することを決定してもよい。端末デバイスがMAC層において第1の優先度および第2の優先度を物理層に通知する複数の実施態様があってもよい。例えば、MAC層は、指示情報2を物理層に送信することができ、指示情報2は、第1の優先度および第2の優先度を示すために使用される。具体的な実施態様では、端末デバイスは、前述の可能な実施態様のうちのいずれか1つを選択することができる。これは特に限定されない。

本出願の本実施形態では、SRをトリガするための論理チャネルは、SRに対応するBSRをトリガするための論理チャネルであると理解されてもよい。例えば、端末デバイスに、送信予定のURLLCサービスデータがある場合、BSRおよびBSRに対応するSRがトリガされる。この場合、SRに対応するBSRをトリガする論理チャネルは、URLLCサービスデータを搬送する論理チャネルである。

本出願の本実施形態では、第2の優先度は、第1のデータパケットの論理チャネルの最高優先度であると理解されてもよい。第1のデータパケットの論理チャネルは、第1のデータパケットのデータを搬送する論理チャネルであると理解されてもよい。例えば、第1のデータパケットは、URLLCサービスデータ1およびURLLCサービスデータ2を含む。この場合、第1のデータパケットの論理チャネルは、URLLCサービスデータ1を搬送する論理チャネルと、URLLCサービスデータ2を搬送する論理チャネルとを含むことができる。具体的には、第1のデータパケットの論理チャネルが1つしかない場合、第2の優先度は、この論理チャネルの優先度であってもよい。第1のデータパケットが複数の論理チャネルを有する場合、第2の優先度は、複数の論理チャネルのうちの最高優先度であると理解されてもよい。例えば、第1のデータパケットの論理チャネルがLCH＃1（URLLCサービスデータ1を搬送する）およびLCH＃2（URLLCサービスデータ2を搬送する）を含み、LCH＃1の優先度がLCH＃2の優先度よりも高い場合、第2の優先度は、LCH＃1の優先度であってもよい。

第2の優先度は、端末デバイスが第1のデータパケットを組み立てるときに取得されてよく、例えば、端末デバイスがLCPプロセスを実行するときに取得されてよい。例えば、第1のデータパケットを組み立てるときに、端末デバイスは、PUSCHリソースおよび論理チャネルのリソース要求に基づいて、PUSCHリソースにマッピングされ得る論理チャネルがLCH＃1およびLCH＃2であると判断し、次いで、LCH＃1の優先度およびLCH＃2の優先度に基づいて第2の優先度を決定することができる。さらに、端末デバイスは、第2の優先度を記録することができる。例えば、端末デバイスは、第1のアップリンクリソースに対応するHARQプロセスのHARQ情報の一部として第2の優先度を使用することができ、MACエンティティは、第2の優先度をHARQエンティティに送信し、HARQエンティティは、第2の優先度をHARQプロセスにさらに送信することができる。このように、第1のデータパケットが再送されたデータパケットである場合（言い換えれば、再送シナリオにおいて）、端末デバイスは、HARQプロセスに基づいて、記録された第2の優先度を取得することができる。言い換えれば、本出願の本実施形態では、第1のデータパケットを組み立てることによって第2の優先度を取得した後に、端末デバイスは、第2の優先度を記録することができ、それにより、後続の再送シナリオにおいて第2の優先度が取得され得る。端末デバイスは、複数の具体的な実施態様において、第2の優先度を記録することができる。これは、本出願のこの実施形態では限定されない。

一例では、第1の優先度が第2の優先度よりも高いと判断した場合、端末デバイスは、第1のアップリンクリソース上でPUCCHを送信することができる。具体的には、MAC層において、第1の優先度が第2の優先度よりも高いと判断した場合、端末デバイスは、第1の指示情報を端末デバイスの物理層に送信する。このようにして、端末デバイスは、第1の指示情報に基づいて物理層においてPUCCHを送信することができる。あるいは、端末デバイスは、MAC層において第1の優先度および第2の優先度を端末デバイスの物理層に通知する。このようにして、端末デバイスは、物理層において第1の優先度が第2の優先度よりも高いと判断した場合、PUCCHを送信する。

例えば、端末デバイスが第1のアップリンクリソース上でPUCCHを送信することは、端末デバイスが第1のアップリンクリソース上でPUCCHのみを送信し、PUSCHを送信しないこととして理解されてもよく、または端末デバイスが第1のアップリンクリソース上でPUCCHを優先的に送信し、第1のアップリンクリソースに利用可能なリソースがまだ残っている場合、端末デバイスは、第1のデータパケットの何らかの情報をさらに送信することができる。例えば、端末デバイスは、パンクチャリング（puncturing）またはPUSCHプリエンプション（pre-empt）を介してPUCCHを送信することができる。

例えば、PUSCHが第1のアップリンクリソース上で送信されていない場合、端末デバイスは、物理層において、PUSCHに対応するTBを破棄し、PUCCHを送信することを選択してもよい。この場合、端末デバイスは、第1のアップリンクリソース上でPUCCHのみを送信し、PUSCHを送信しない。PUSCHが第1のアップリンクリソース上で送信された場合、端末デバイスは、パンクチャリング、PUSCHプリエンプションなどを介してPUCCHを送信することができる。SRが完全に送信された後、PUSCHの送信が再開されてもよく、またはPUSCHの送信が再開されなくてもよい。

本例では、第1の優先度が第2の優先度よりも高いため、端末デバイスは、第1のアップリンクリソース上でPUCCHを送信し、それにより、ネットワークデバイスは、PUCCHを使用して、SRをトリガする送信予定データを時間的にスケジューリングすることができ、送信予定データのレイテンシを効果的に低減することができる。

別の例では、第1の優先度が第2の優先度に等しいと判断した場合、端末デバイスは、重複する時間領域リソース上でPUCCHを送信してもよく、または重複する時間領域リソース上でPUSCHを送信してもよく、あるいは端末デバイスは、端末デバイスの処理能力に基づいて、PUCCHまたはPUSCHを送信することを選択する。

別の例では、第1の優先度が第2の優先度よりも低いと判断した場合、端末デバイスは、（重複する時間領域リソースを含む）第1のアップリンクリソース上でPUSCHを送信することができる。本明細書では、第1のアップリンクリソース上でPUSCHを送信することは、端末デバイスがPUSCHのみを送信し、第1のアップリンクリソース上でPUCCHを送信しないこととして理解されてもよい。本例では、第1の優先度が第2の優先度よりも低いため、端末デバイスは、第1のアップリンクリソース上でPUSCHを送信し、それにより、PUSCH上で送信されるデータのレイテンシが低減され得る。

（2）第1のアップリンクリソース上でのPUSCHの処理状態が処理未完了である。

この場合、端末デバイスは、第1の優先度と第2の優先度を比較することによって、PUCCHまたはPUSCHを送信することを決定してもよい。

一例では、端末デバイスが、第1の優先度が第2の優先度よりも高いと判断した場合、端末デバイスは、重複する時間領域リソース上でPUCCHを送信することができる。第2の優先度は、端末デバイスが第1のデータパケットを組み立てるときに端末デバイスによって取得されてもよい。

さらに別の例では、第1の優先度が第2の優先度に等しいと判断した場合、端末デバイスは、重複する時間領域リソース上でPUCCHを送信してもよく、または第1のアップリンクリソース上でPUSCHを送信してもよく、あるいは端末デバイスは、端末デバイスの処理能力に基づいて、PUCCHまたはPUSCHを送信することを選択する。

例えば、端末デバイスがPUCCHを送信すると決定した場合、端末デバイスのMAC層は、PUSCHに対応するアップリンクグラントを破棄することを選択することができる。この場合、端末デバイスは、重複する時間領域リソース上でPUCCHのみを送信し、PUSCHを送信しない。

さらに別の例では、第1の優先度が第2の優先度よりも低いと判断した場合、端末デバイスは、（重複する時間領域リソースを含む）第1のアップリンクリソース上でPUSCHを送信することができる。

前述の方法によると、SRを搬送するPUCCHとPUSCHが第1のアップリンクリソースの時間領域において重複する場合、端末デバイスは、第1のアップリンクリソース上でのPUSCHの処理状態を考慮し、第1のアップリンクリソース上でのPUSCHの処理状態に基づいて、重複する時間領域リソース上でPUCCHまたはPUSCHを送信することができ、それにより、データ送信の合理性が保証され得て（例えば、SRをトリガする送信予定データのレイテンシまたはPUSCH上で送信されるデータのレイテンシが低減され得る）、端末デバイスが常にPUSCHを送信するためにデータのレイテンシが低減され得ないという問題が回避され得る。

実施形態2
図5は、本出願の実施形態2による通信方法に対応する概略フローチャートである。図5に示されるように、本方法は以下のステップを含む。

ステップ501：端末デバイスがSRをトリガする。

ステップ502：SRを搬送するPUCCHとPUSCHが第1のアップリンクリソースの時間領域において重複すると判断した場合、端末デバイスは、PUSCHリソースおよびSRをトリガするための論理チャネルのリソース要求に基づいて、重複する時間領域リソース上でPUCCHまたはPUSCHを送信する。PUSCHリソースは、動的にスケジュールされたリソースまたは事前設定されたスケジュールされたリソースであってもよい。これは特に限定されない。

前述の方法によると、SRを搬送するPUCCHとPUSCHが第1のアップリンクリソースの時間領域において重複する場合、端末デバイスは、PUSCHリソースおよびSRをトリガするための論理チャネルのリソース要求を考慮し、PUSCHリソースおよびSRをトリガするための論理チャネルのリソース要求に基づいて、重複する時間領域リソース上でPUCCHまたはPUSCHを送信することを決定することができる。これは、重複する時間領域リソース上でアップリンク情報を送信する効率を保証する。PUSCHリソースおよびSRをトリガするための論理チャネルのリソース要求は、ネットワークデバイスによって設定される情報であり、シナリオによって影響されないため、前述の方法は、比較的適用可能性が高く、複数の可能なシナリオ、例えば、新たなデータ送信シナリオまたはデータ再送シナリオに適用可能である場合がある。

具体的には、一例において、PUSCHリソースがSRをトリガするための論理チャネルのリソース要求を満たさないと判断した場合、端末デバイスは、重複する時間領域リソース上でPUCCHを送信することができる。本例では、PUSCHリソースがSRをトリガするための論理チャネルのリソース要求を満たさないということは、SRをトリガするデータがPUSCHリソース上で送信され得ないことを示す。例えば、SRをトリガするデータは、URLLCサービスデータであり、PUSCHリソースは、eMBBサービスデータをスケジューリングするためのリソースである。したがって、PUSCHリソースは、SRをトリガするための論理チャネルのリソース要求（または、言い換えれば、SRをトリガするための論理チャネルのLCPマッピング制約）を満たさない。例えば、PUSCHリソースの時間領域長が、SRをトリガするための論理チャネルのリソースの時間領域長の要求よりも大きいと判断した場合、言い換えれば、PUSCHリソースの時間領域長が、SRをトリガするための論理チャネルのリソースの最大時間領域長の要求よりも大きいと判断した場合、端末デバイスは、PUSCHリソースがSRをトリガするための論理チャネルのリソース要求を満たすことができないと判断する。

本例では、PUSCHリソースが、SRをトリガするための論理チャネルのリソース要求を満たしていないため、端末デバイスは、第1のアップリンクリソース上でPUCCHを送信し、それにより、ネットワークデバイスは、PUCCHを使用して、SRをトリガする送信予定データをタイムリーにスケジューリングして、送信予定データのレイテンシを効果的に低減することができる。

別の例では、PUSCHリソースがSRをトリガするための論理チャネルのリソース要求を満たすと判断した場合、端末デバイスはPUSCHを送信する。本例では、PUSCHリソースがSRをトリガするための論理チャネルのリソース要求を満たすということは、SRをトリガするデータがPUSCHリソース上で送信されてもよいことを示す。この場合、PUSCHが送信されてもよい。

以下のことに留意されたい。（1）実施形態1と実施形態2との違いは、実施形態1では、PUCCHまたはPUSCHの送信が処理状態に基づいて決定され、実施形態2では、PUCCHまたはPUSCHの送信がPUSCHリソースおよびSRをトリガするための論理チャネルのリソース要求に基づいて決定される点にある。この違いに加えて、他のコンテンツが相互に参照されてもよい。

（2）実施形態1と実施形態2は別々に実施されてもよく、組み合わされて実施されてもよい。実施形態1と実施形態2が組み合わされて実施されるということは、以下のように理解されてもよい。PUSCHリソースが、SRをトリガするための論理チャネルのリソース要求を満たすかどうかがまず判断され、次いで、SRをトリガするための論理チャネルの第1の優先度と、第1のアップリンクリソース上で送信される第1のデータパケットの論理チャネルの第2の優先度とが、処理状態に基づいて比較され、次いで、比較結果に基づいてPUCCHまたはPUSCHが送信される。

一例では、実施形態1と実施形態2が組み合わされて実施されるということは、以下のことを示すことができる。PUSCHによって占有されるリソースがSRをトリガするための論理チャネルのリソース要求を満たすと判断した場合、端末デバイスは、処理状態に基づいて第1の優先度を第2の優先度とさらに比較し、第1の優先度が第2の優先度よりも高い場合は、重複する時間領域リソース上でPUCCHを送信し、または第1の優先度が第2の優先度より低い場合は、PUSCHを送信し、または第1の優先度が第2の優先度と等しい場合は、重複する時間領域リソース上でPUCCHまたはPUSCHを送信してもよい。端末デバイスが処理状態に基づいて第1の優先度と第2の優先度を比較する具体的な実施態様については、実施形態1の説明を参照されたい。このように、PUSCHリソースがSRをトリガするための論理チャネルのリソース要求を満たすと判断した後、端末デバイスは、優先度の比較結果に基づいて、PUCCHまたはPUSCHを送信することをさらに決定し、それにより、PUSCHリソースがSRをトリガするための論理チャネルのリソース要求を満たしているが、第1の優先度が第2の優先度より高い場合、端末デバイスは、依然としてPUCCHを送信する。これは、PUSCHリソースおよびSRをトリガするための論理チャネルのリソース要求のみに基づいて判断することが十分には正確でないという問題を効果的に回避し、SRをトリガする送信予定データのレイテンシを低減する。例えば、PUSCHリソースは、URLLCサービスデータ1をスケジューリングするためのリソースであり、PUSCHリソースの時間領域長は、0.2msである。SRをトリガする送信予定データは、URLLCサービスデータ2であり、SRをトリガするための論理チャネルのリソースの時間領域長に対する要求は、0.5msである。この場合、PUSCHリソースは、SRをトリガするための論理チャネルのリソース要求を満たす。URLLCサービスデータ2を搬送する論理チャネルの優先度（すなわち、第1の優先度）がURLLCサービスデータ1を搬送する論理チャネルの優先度（すなわち、第2の優先度）よりも高い場合、PUCCHは依然として送信されることができる。このようにして、URLLCサービスデータ2のレイテンシが低減される。

実施形態3
実施形態3では、PUSCHにおける第1のデータパケット（すなわち、PUSCHに対応するアップリンクグラントによって指示されたリソース上で送信予定のデータパケット）が効果的に送信されることができないシナリオに対して、第1のデータパケットを再度送信する機会を提供して、第1のデータパケットの損失または第1のデータパケットの比較的大きなサービス性能の損失を回避するためのいくつかの解決策が主に提供される。PUSCH上で第1のデータパケットが効果的に送信されることができないということは、PUSCH上で第1のデータパケットが送信されていないか、または完全には送信されていないことを含むことができる。

本出願の本実施形態では、PUSCHにおける第1のデータパケットが効果的に送信されることができない複数のシナリオが存在することがある。例えば、SRを搬送するPUCCHとPUSCHが第1のアップリンクリソースの時間領域において重複する場合、端末デバイスが第1のアップリンクリソース上でPUCCHを送信する場合、PUSCH上の第1のデータパケットが効果的に送信されない可能性がある。例えば、PUSCHが、スケジューリングされた新たな送信リソースである場合に、端末デバイスがPUSCH上で第1のデータパケットを組み立て、端末デバイスがPUCCHを送信することを選択して、PUSCHを送信しない場合、ネットワークデバイスは、端末デバイスに送信予定データがなく、PUSCHリソースをスキップすることを選択したために、あるいは時間領域において重複するSRを送信する際にPUSCHの第1のデータパケットが破棄（drop）されまたはプリエンプトされたために、PUSCHが送信されなかったかを判断することができない。したがって、ネットワークデバイスは、再送のためにPUSCH上で第1のデータパケットをタイムリーにスケジュールすることができない。PUSCHに対応するHARQプロセスがネットワークデバイスによって占有され、新たな送信スケジューリングが行われる場合、それは、第1のデータパケットが新たに組み立てられたデータパケットに置き換えられることを意味する。この場合、端末デバイスが、HARQプロセスにおいてPUSCH上で送信されるデータがなく、PUSCHリソースをスキップすることを選択する場合、端末デバイスは、HARQプロセスのバッファを能動的にクリアする。言い換えれば、第1のデータパケットがクリアされる。その結果、第1のデータパケットは、もはやHARQ送信機会を得ることができない。第1のデータパケットのデータが無線リンク制御（radio link control、RLC）層において非確認応答モード（unacknowledged mode、UM）で送信される場合、言い換えれば、RLC層のARQメカニズムがない場合、第1のデータパケットのデータは失われる。第1のデータパケットのデータがRLC層で第1のデータパケットにおいてAMモードで送信される場合、言い換えれば、RLC層のARQメカニズムが存在する場合、RLC ARQに依存することは、過度に長いレイテンシも引き起こす。第1のデータパケットのデータが比較的優先度が低いURLLCサービスである場合、レイテンシは低減され得ない。

別の例では、ネットワークデバイスは、端末デバイスに測定間隔を設定することができる。それに応じて、端末デバイスは、測定間隔内の異なる周波数領域リソースのチャネル品質を測定することができ、チャネル品質（例えば、チャネル品質インジケータ（channel quality indication、CQI）であってもよい）をネットワークデバイスに報告することができる。このようにして、ネットワークデバイスは、チャネル品質の良好な周波数領域リソース上にデータをスケジューリングして、周波数領域スケジューリングゲインを取得することができる。端末デバイスは、測定間隔中にPUSCHを送信することはできないため、PUSCHの送信機会は、測定間隔によって打ち切られる（knocked off）。その結果、PUSCH上の第1のデータパケットは効果的に送信され得ない。

別の例としては、端末デバイスは、同時に別の端末デバイスと通信する。端末デバイスと別の端末デバイスとの間の通信のための第2のアップリンクグラントの優先度が、端末デバイスとネットワークデバイスとの間の通信のための第1のアップリンクグラントの優先度よりも高い場合、端末デバイスは、第2のアップリンクグラントを選択し、第1のアップリンクグラントに対応するPUSCH上で第1のデータパケットのデータを送信しない。

（1）本出願の実施形態3において提供される可能な解決策は、以下の通りである。端末デバイスは、第1のアップリンクリソース上で送信される第1のデータパケットを組み立て、第1のデータパケットが送信されていないか、または完全には送信されていないと判断した場合、第2のアップリンクリソース上で第1のデータパケットを送信する。第2のアップリンクリソースおよび第1のアップリンクリソースは、同じHARQプロセスに対応することができ、言い換えれば、第2のアップリンクリソースおよび第1のアップリンクリソースは、同じHARQプロセス識別子を有する。このようにして、第1のデータパケットは、第2のアップリンクリソース上で送信され、それにより、ネットワークデバイスは、第1のデータパケットを受信することができ、第1のデータパケットのデータの損失を効果的に回避する。第2のアップリンクリソース上で送信される第1のデータパケットは、第1のアップリンクリソース上で組み立てられた完全なMAC PDUであってもよいことに留意されたい。言い換えれば、第1のデータパケットの何らかの情報が第1のアップリンクリソース上で送信される場合であっても、第2のアップリンクリソース上で送信される第1のデータパケットも完全なMAC PDUであってもよい。

一例では、第2のアップリンクリソースは、第1のアップリンクリソースの後の次のアップリンクリソースであってもよい。図6に示されるように、第1のアップリンクリソースおよび第2のアップリンクリソースは両方とも、事前設定されたスケジューリングリソースである。第1のアップリンクリソースは、HARQ ID＃1のアップリンクリソースである。第1のデータパケットは、第1のデータパケットが組み立てされたときに取得されるが、第1のデータパケットは、破棄またはプリエンプトされる。アップリンクリソースは、周期的リソース（スロットごとに1回繰り返される）であるため、次のHARQ ID＃1のアップリンクリソース（すなわち、第2のアップリンクリソース）が利用可能である場合、第2のアップリンクリソースを使用して第1のデータパケットが送信されることができる。

例えば、第1のデータパケットが第2のアップリンクリソースに対応するHARQプロセスのバッファ内に記憶され、それにより第1のデータパケットが第2のアップリンクリソース上で送信され得る。代替として、第2のアップリンクリソース上で送信される既存のデータがなく、言い換えれば、第2のアップリンクリソースは、多重化およびパケット組立てエンティティを使用して新たなMAC PDUを取得せず、それにより、第1のデータパケットが第2のアップリンクリソース上で送信され得る。

（2）本出願の実施形態3において提供される別の可能な解決策は、以下の通りである。端末デバイスは、第1のアップリンクリソース上で送信される第1のデータパケットを組み立て、第1のデータパケットが送信されていないか、または完全には送信されていないと判断した場合、第2のアップリンクリソース上で第2のデータパケットを送信し、第2のデータパケットは、第1のデータパケットの情報の一部または全部を含む。第2のアップリンクリソースおよび第1のアップリンクリソースは、同じHARQプロセスに対応することができる。一例では、第2のアップリンクリソースは、第1のアップリンクリソースの後の次のアップリンクリソースであってもよい。第2のデータパケットは、端末デバイスが第2のアップリンクリソース上でパケット組立てを行うときに、第1のアップリンクデータパケットの情報の一部または全部を含むことができ、言い換えれば、端末デバイスは、第2のアップリンクリソース上でデータ再組立て（MAC PDU rebuilding）を行うことができる。

一例では、MACエンティティは、多重化およびパケット組立てエンティティに第2のデータパケットを組み立てるように通知することができる。第1のデータパケットは、少なくとも1つのMACサブ（sub）PDUと、MAC制御要素（control element、CE）とを含むことができる。第2のデータパケットが第1のデータパケットの情報の一部または全部を含むということは、第2のデータパケットが第1のデータパケットの少なくとも1つのMACサブPDUを含むか、または第2のデータパケットが第1のデータパケットのMAC CEを含むか、または第2のデータパケットが第1のデータパケットの少なくとも1つのMACサブPDUおよびMAC CEを含むということであると理解されてもよい。これは、本出願のこの実施形態では限定されない。

例えば、第1のデータパケットが少なくとも1つのMAC CE、例えば、BSR MAC CEまたはパワーヘッドルーム報告（power headroom report、PHR）MAC CEを含む場合、少なくとも1つのMAC CEに対応するMACプロセスは、第1のデータパケットが組み立てられた後、キャンセル（cancel）されず、言い換えれば、端末デバイスは、MAC層において、少なくとも1つのMAC CEに対応するMACプロセスを再トリガすることができ、それにより、第2のデータパケットは、少なくとも1つのMAC CEに対応するMACプロセスにおいて生成されるMAC CE、例えば、BSR MAC CEまたはPHR MAC CEを含むことができる。

（3）本出願の実施形態3において提供される別の可能な解決策は、以下の通りである。第1のデータパケットのデータがRLC層においてAMモードで送信される場合、第1のデータパケットのMACサブPDUは、RLC層ARQの再送をトリガするようにRLC層に通知することができる。

（4）本出願の実施形態3において提供される別の可能な解決策は、以下の通りである。端末デバイスは、第1のアップリンクリソース上で送信される第1のデータパケットを組み立て、第1のデータパケットが送信されていないか、または完全に送信されたと判断した場合、第3の指示情報をネットワークデバイスに送信することができ、第3の指示情報は、第1のデータパケットが送信されていないか、または完全には送信されていないことを示すために使用される。それに応じて、第3の指示情報を受信した後、ネットワークデバイスは、第1のデータパケットのデータの損失を回避するために、第3の指示情報に基づいて第1のデータパケットの再送をスケジューリングすることができる。

一例では、SRを搬送するPUCCHとPUSCHが第1のアップリンクリソースの時間領域において重複するシナリオの場合、ネットワークデバイスは、2つのタイプのSR設定を事前設定することができる。第1のタイプのSR設定は、利用可能なPUCCHリソースを含み、第2のタイプのSR設定は、利用可能なPUCCHリソースと、第3の指示情報を搬送するリソースとを含む。第1のアップリンクリソース上でPUCCHを送信すると決定した場合、端末デバイスは、第2のタイプのSR設定を使用してPUCCHおよび第3の指示情報を送信することができる。

さらに別の例では、第3の指示情報は、SRを搬送するPUCCH上で搬送される追加情報であってもよい。追加の情報は、追加のビットであってもよい。例えば、ビットが1に設定される場合、第1のデータパケットが送信されていないか、または完全には送信されていないことを示す。

実施形態3に記載される様々な可能な解決策は、個別に実施されてもよく、または実施形態1もしくは実施形態2と組み合わされて実施されてもよいことに留意されたい。例えば、実施形態1または実施形態2において、端末デバイスが第1のアップリンクリソース上でPUCCHを送信する場合、第1のデータパケットが送信されていないか、または完全には送信されていない場合、前述の解決策が用いられて、第1のデータパケットが再度送信される機会を提供し、第1のデータパケットの損失または第1のデータパケットの比較的大きなサービス性能の損失を回避することができる。

実施形態4
本出願の本実施形態では、複数の論理チャネルが同時に送信予定データを有する場合、端末デバイスは、複数のBSRをトリガすることができる。例えば、URLLCサービスデータおよびeMBBサービスデータが送信される場合、端末デバイスは、URLLCサービスデータに対応するBSR1、およびeMBBサービスデータに対応するBSR2をトリガすることができる。この場合、BSR1に対応するSR1を搬送するPUCCHとBSR2に対応するSR2を搬送するPUCCHは、アップリンクリソースの時間領域において重複する。端末デバイスがBSR2に対応するSR2をトリガするが、BSR1に対応するSR1をトリガしない場合、ネットワークデバイスは、SR2に基づいて、URLLCサービスデータに適さないリソースをスケジューリングする可能性がある。その結果、URLLCサービスデータのレイテンシが低減され得ない。

これに基づいて、本出願の実施形態4において提供される解決策は以下の通りである。端末デバイスは、複数のBSRをトリガし、複数のBSRは、それぞれ複数のSRに対応する。複数のSRを搬送する複数のPUCCHが第3のアップリンクリソースの時間領域において重複すると判断した場合、端末デバイスは、複数のBSRをトリガするための論理チャネルの優先度に基づいてターゲットBSRを決定し、ターゲットBSRに対応するSRをトリガすることができる。ターゲットBSRをトリガするための論理チャネルの優先度は、複数のBSRにおける別のBSRをトリガするための論理チャネルの優先度よりも高い。例えば、端末デバイスは、URLLCサービスデータに対応するBSR1、およびeMBBサービスデータに対応するBSR2をトリガする。BSR1をトリガする論理チャネルの優先度がBSR2をトリガする論理チャネルの優先度よりも高いため、端末デバイスは、BSR1に対応するSR1をトリガして、URLLCサービスデータのレイテンシを低減することができる。

一例では、複数のBSRをトリガするための論理チャネルが同じ優先度を有する場合、端末デバイスは、別の要因に基づいてトリガされるべきSRを選択してもよい。例えば、端末デバイスは、複数のBSRに対応する複数のSRの送信機会の到着時刻に基づいて、トリガされるべきSRを選択してもよい。例えば、端末デバイスは、URLLCサービスデータに対応するBSR1、およびeMBBサービスデータに対応するBSR2をトリガする。BSR1に対応するSR1の送信機会が最初に来た場合、端末デバイスは、SR1をトリガしてもよい。

実施形態4に記載される解決策は、単独で実施されてもよく、または実施形態1もしくは実施形態2と組み合わされて実施されてもよいことに留意されたい。例えば、実施形態1または実施形態2において、端末デバイスが複数のBSRをトリガする場合、トリガされるSRは、前述の解決策に基づいて決定されてよい。

上記は、ネットワークデバイスと端末デバイスとの間の相互作用の観点から、本出願の実施形態において提供される解決策を主に説明している。前述の機能を実施するために、ネットワークデバイスまたは端末デバイスは、各機能を実行するための対応するハードウェア構造および／またはソフトウェアモジュールを含むことができると理解されてもよい。当業者は、本明細書に開示されている実施形態で説明された例と組み合わせて、ユニット、アルゴリズム、およびステップが、ハードウェアまたはハードウェアとコンピュータソフトウェアとの組み合わせによって実施され得ることを容易に気づくはずである。機能がハードウェアによって実行されるか、またはコンピュータソフトウェアによって駆動されるハードウェアによって実行されるかは、技術的解決策の特定の用途および設計制約に依存する。当業者であれば、様々な方法を使用して記載の機能を特定の用途ごとに実施し得るが、その実施態様は本出願の範囲を超えるとみなされるべきではない。

統合ユニット（モジュール）が使用される場合、図7は、本出願の実施形態による装置の可能な例示的なブロック図である。装置700は、ソフトウェアの形態で存在してもよい。装置700は、処理ユニット702および通信ユニット703を含むことができる。処理ユニット702は、装置700の動作を制御および管理するように構成されている。通信ユニット703は、別のネットワークエンティティと通信する装置700をサポートするように構成されている。任意選択で、通信ユニット703は、トランシーバユニットとも呼ばれ、受信ユニットおよび／または送信ユニットを含むことができ、これらは、それぞれ受信動作および送信動作を実行するように構成されている。装置700は、装置700のプログラムコードおよび／またはデータを記憶するように構成された記憶ユニット701をさらに含むことができる。

処理ユニット702は、プロセッサまたはコントローラであってもよく、本出願の実施形態において開示された内容を参照して説明された様々な例示的な論理ブロック、モジュール、および回路を実装または実行することができる。通信ユニット703は、通信インタフェース、トランシーバ、トランシーバ回路などであってもよい。通信インタフェースは一般用語である。特定の実施態様では、通信インタフェースは複数のインタフェースを含むことができる。記憶ユニット701はメモリであってもよい。

装置700は、前述の実施形態のうちのいずれかの実施形態おける端末デバイスであってよく、または端末デバイス内に配置されたチップであってよい。処理ユニット702は、前述の方法例において端末デバイスの動作を実行する際に、装置700をサポートすることができる。あるいは、処理ユニット702は、方法例における端末の内部動作を主に実行し、通信ユニット703は、装置700とネットワークデバイスとの間の通信をサポートすることができる。例えば、処理ユニット702は、図3のステップ301および302を実行するように構成されている。通信ユニット703は、図3のPUCCHまたはPUSCHを送信するように構成されている。

具体的には、一実施形態において、処理ユニット702は、SRをトリガし、SRを搬送するPUCCHと第1のデータパケットを搬送するPUSCHが第1のアップリンクリソースの時間領域において重複すると判断した場合、第1のアップリンクリソース上でのPUSCHの処理状態を取得し、第1のアップリンクリソース上でのPUSCHの処理状態に基づいて、通信ユニットを使用して第1のアップリンクリソース上でPUCCHまたはPUSCHを送信するように構成されている。

可能な一設計において、処理ユニットは、第1のアップリンクリソース上でのPUSCHの処理状態が処理完了である場合、SRをトリガするための論理チャネルの第1の優先度が第1のアップリンクリソース上で送信される第1のデータパケットの論理チャネルの第2の優先度以上であると判断した場合、通信ユニットを使用して第1のアップリンクリソース上でPUCCHを送信するように特に構成されている。

可能な一設計において、処理ユニットは、MAC層において、第1の優先度が第2の優先度以上であると判断した場合、物理層に第1の指示情報を送信し、物理層において、第1の指示情報に基づいて、通信ユニットを使用して第1のアップリンクリソース上でPUCCHを送信するように、またはMAC層において、第1の優先度および第2の優先度を物理層に通知し、物理層において、第1の優先度が第2の優先度以上であると判断した場合、通信ユニットを使用して第1のアップリンクリソース上でPUCCHを送信するように具体的に構成されている。第2の優先度は、通信装置が第1のデータパケットを組み立てるときに通信装置によって取得されてもよい。

具体的には、一実施形態において、処理ユニットは、スケジューリング要求SRをトリガし、SRを搬送するPUCCHと第1のデータパケットを搬送するPUSCHが第1のアップリンクリソースの時間領域において重複すると判断した場合、PUSCHによって占有されるリソースおよびSRをトリガするための論理チャネルのリソース要求に基づいて、通信ユニットを使用して、重複する時間領域リソース上でPUCCHまたはPUSCHを送信するように構成されている。

可能な一設計において、処理ユニットは、PUSCHによって占有されるリソースがSRをトリガするための論理チャネルのリソース要求を満たすと判断した場合、通信ユニットを使用して、重複する時間領域リソース上でPUSCHを送信するように特に構成されている。

可能な一設計において、端末デバイスが、PUSCHによって占有されるリソースがSRをトリガするための論理チャネルのリソース要求を満たすと判断した場合に、SRをトリガするための論理チャネルの第1の優先度が第1のデータパケットの論理チャネルの第2の優先度以下であると判断した場合、処理ユニットは、通信ユニットを使用して、重複する時間領域リソース上でPUSCHを送信するようにさらに構成されている。

可能な一設計において、処理ユニットは、第1の優先度が第2の優先度よりも高い場合、通信ユニットを使用して重複する時間領域リソース上でPUCCHを送信するように特に構成されている。

可能な一設計において、処理ユニットは、PUSCHによって占有されるリソースがSRをトリガするための論理チャネルのリソース要求を満たさないと判断した場合、通信ユニットを使用して、重複する時間領域リソース上でPUCCHを送信するように特に構成されている。

可能な一設計において、通信ユニットは、第2のアップリンクリソース上で第1のデータパケットを送信するようにさらに構成されている。第2のアップリンクリソースおよび第1のアップリンクリソースは、同じHARQプロセスに対応する。

可能な一設計において、第1のデータパケットは、第2のアップリンクリソースに対応するHARQプロセスのバッファに記憶される。

可能な一設計において、通信ユニットは、第2のアップリンクリソース上で第2のデータパケットを送信するようにさらに構成されている。第2のデータパケットは、第1のデータパケットの情報の一部または全部を含む。

可能な一設計において、通信ユニットは、第3の指示情報をネットワークデバイスに送信するようにさらに構成されている。第3の指示情報は、第1のデータパケットが送信されていないか、または完全には送信されていないことを示すために使用される。

具体的には、さらに別の例では、処理ユニットは、第1のアップリンクリソース上で送信される第1のデータパケットを組み立て、第1のデータパケットが送信されていないか、または完全には送信されていないと判断した場合、通信ユニットを使用して、第2のアップリンクリソース上で第1のデータパケットを送信するように構成されている。第2のアップリンクリソースおよび第1のアップリンクリソースは、同じHARQプロセスに対応する。

可能な一設計において、第1のデータパケットは、第2のアップリンクリソースに対応するHARQプロセスのバッファに記憶される。

本出願の本実施形態において、ユニット（モジュール）分割は一例であり、単に論理的な機能分割であることに留意されたい。実際の実装形態では、別の分割方法が使用されてよい。本出願の実施形態における機能モジュールは、1つの処理モジュールに統合されてよく、またはモジュールのそれぞれが物理的に単独で存在してよく、または2つ以上のモジュールが1つのモジュールに統合される。統合モジュールは、ハードウェアの形態で実現されてもよく、ソフトウェア機能モジュールの形態で実現されてもよい。

統合モジュールがソフトウェア機能モジュールの形態で実装され、独立した製品として販売または使用される場合、統合ユニットは、コンピュータ可読記憶媒体に記憶されてもよい。このような理解に基づいて、本出願の技術的解決策は、基本的に、または従来技術に寄与する部分が、または技術的解決策のすべてもしくは一部が、ソフトウェア製品の形態で実施され得る。ソフトウェア製品は、記憶媒体の中に記憶され、コンピュータデバイス（パーソナルコンピュータ、サーバ、もしくはネットワークデバイス）またはプロセッサ（processor）に、本出願の実施形態に説明する方法のステップのすべてまたは一部を実行するように命令するためにいくつかの命令を含む。前述の記憶媒体は、メモリなどの、プログラムコードを記憶することができる任意の媒体であってよい。

図8は、装置の概略構成図である。装置800は、プロセッサ810と、メモリ820と、トランシーバ830とを含む。一例では、装置800は、図7に示される装置700の機能を実装することができる。具体的には、トランシーバは、図7に示される通信ユニット703の機能を実装することができ、プロセッサは、処理ユニット702の機能を実装することができ、メモリは、記憶ユニット701の機能を実装することができる。さらに別の例では、装置800は、前述の方法の実施形態における端末デバイスであってよい。装置800は、端末デバイスに対応し、前述の方法の実施形態で説明された方法を実装するように構成されてもよい。詳細については、前述の方法の実施形態における説明を参照されたい。

図9は、本出願の一実施形態による端末デバイス900の概略構造図である。説明を容易にするために、図9は、端末デバイスの主要構成要素のみを示す。図9に示されるように、端末デバイス900は、プロセッサと、メモリと、制御回路と、アンテナと、入出力装置とを含む。端末デバイス900は、図1に示されるシステムアーキテクチャに適用され、前述の方法の実施形態における端末デバイスの機能を実行することができる。

プロセッサは、通信プロトコルおよび通信データを処理し、端末デバイス全体を制御し、ソフトウェアプログラムを実行するように構成され、ソフトウェアプログラムの処理データは、例えば、前述の方法の実施形態で説明された動作を実行する際に端末デバイスを制御するように主に構成されている。メモリは、ソフトウェアプログラムおよびデータを格納するように主に構成される。制御回路は、ベースバンド信号と無線周波数信号との間の変換を実行し、無線周波数信号を処理するように主に構成されている。制御回路とアンテナの組み合わせは、トランシーバと呼ばれることがあり、電磁波形態の無線周波数信号を送受信するように主に構成されている。タッチスクリーン、ディスプレイスクリーン、またはキーボードなどの入力／出力装置は、ユーザによって入力されたデータを受信し、データをユーザに出力するように主に構成されている。

端末デバイスの電源が投入にされた後、プロセッサは、記憶ユニット内のソフトウェアプログラムを読み取り、ソフトウェアプログラムの命令を解釈および実行し、ソフトウェアプログラムのデータを処理することができる。データが無線で送信される必要がある場合、プロセッサは、送信予定データに対してベースバンド処理を実行した後、ベースバンド信号を無線周波数回路に出力する。ベースバンド信号に対して無線周波数処理を実行した後、無線周波数回路は、アンテナを介して無線周波数信号を電磁波の形態で送信する。端末デバイスにデータが送信されると、無線周波数回路は、アンテナを介して無線周波数信号を受信し、無線周波数信号をベースバンド信号に変換して、プロセッサにベースバンド信号を出力する。プロセッサは、ベースバンド信号をデータに変換し、データを処理する。

当業者であれば、図9は、説明を容易にするために、1つのメモリおよび1つのプロセッサのみを示していることを理解されよう。実際の端末デバイスは、複数のプロセッサと複数のメモリを有することがある。メモリは、記憶媒体や記憶デバイスなどと呼ばれることもある。これについては本出願の実施形態では限定されない。

任意の実施態様では、プロセッサは、ベースバンドプロセッサと中央処理ユニットとを含んでもよい。ベースバンドプロセッサは、通信プロトコルおよび通信データを処理するように主に構成されている。中央処理ユニットは、端末デバイス全体を制御し、ソフトウェアプログラムを実行し、ソフトウェアプログラムのデータを処理するように主に構成される。ベースバンドプロセッサおよび中央処理ユニットの機能は、図9のプロセッサに統合される。当業者であれば、ベースバンドプロセッサおよび中央処理ユニットがそれぞれ独立したプロセッサであってよく、バスなどを使用して相互接続されることを理解されよう。当業者であれば、端末デバイスが異なるネットワーク規格に適応するために複数のベースバンドプロセッサを含んでもよく、端末デバイスが端末デバイスの処理能力を向上させるために複数の中央処理ユニットを含んでもよく、端末デバイスの構成要素が様々なバスを使用して接続されてもよいことを理解されよう。ベースバンドプロセッサはまた、ベースバンド処理回路またはベースバンド処理チップとして表現されてもよい。中央処理ユニットはまた、中央処理回路または中央処理チップとして表現されてもよい。通信プロトコルおよび通信データを処理する機能は、プロセッサに内蔵されてもよく、またはソフトウェアプログラムの形態で記憶ユニットに格納されてもよい。プロセッサは、ベースバンド処理機能を実施するためにソフトウェアプログラムを実行する。

図9に示される端末デバイス900は、図3に示される方法の実施形態における端末デバイスに関連するプロセスを実施することができる。端末デバイス900内のモジュールの動作および／または機能は、前述の方法の実施形態における対応する手順を実施するように意図されている。詳細については、前述の方法の実施形態における説明を参照されたい。繰り返しを避けるため、ここでは詳細な説明は適切に省略されている。

実施プロセスでは、実施形態における方法のステップは、プロセッサ内のハードウェア集積論理回路を使用して、またはソフトウェアの形態の命令を使用して実行されてもよい。本出願の実施形態を参照して開示された方法のステップは、ハードウェアプロセッサによって直接実行されてもよく、またはプロセッサ内のハードウェアとソフトウェアモジュールの組み合わせを使用して実行されてもよい。

本出願の実施形態におけるプロセッサは、集積回路チップであってよく、信号処理能力を有することに留意されたい。実施プロセスでは、前述の方法の実施形態におけるステップは、プロセッサ内のハードウェア集積論理回路を使用して、またはソフトウェアの形態の命令を使用して実施され得る。プロセッサは、汎用中央処理ユニット（central processing unit、CPU）、汎用プロセッサ、デジタル信号処理（digital signal processing、DSP）、特定用途向け集積回路（application specific integrated circuits、ASIC）、フィールドプログラマブルゲートアレイ（field programmable gate array、FPGA）、別のプログラマブル論理デバイス、トランジスタ論理デバイス、ハードウェア構成要素、またはそれらの任意の組み合わせであってよく、あるいは、コンピューティング機能を実施するプロセッサの組み合わせ、例えば、1つもしくは複数のマイクロプロセッサの組み合わせ、またはDSPとマイクロプロセッサの組み合わせであってよい。汎用プロセッサは、マイクロプロセッサであってもよく、またはプロセッサは任意の従来のプロセッサなどであってもよい。

本出願の実施形態におけるメモリまたは記憶ユニットは、揮発性メモリまたは不揮発性メモリであってよく、あるいは揮発性メモリおよび不揮発性メモリを含んでよいことが理解され得る。不揮発性メモリは読み出し専用メモリ（read-only memory、ROM）、プログラマブル読み出し専用メモリ（programmable ROM、PROM）、消去可能プログラマブル読み出し専用メモリ（erasable PROM、EPROM）、電気的消去可能プログラマブル読み出し専用メモリ（electrically EPROM、EEPROM）やフラッシュメモリであってもよい。揮発性メモリは外部キャッシュとして用いられるランダムアクセスメモリ（random access memory、RAM）であってよい。限定的な説明ではなく例として、多くの形態のRAM、例えば、スタティック・ランダムアクセスメモリ（static RAM、SRAM）、ダイナミック・ランダムアクセスメモリ（dynamic RAM、DRAM）、シンクロナス・ダイナミック・ランダムアクセスメモリ（synchronous DRAM、SDRAM）、ダブルデータレート・シンクロナス・ダイナミック・ランダムアクセスメモリ（double data rate SDRAM、DDR SDRAM）、強化型シンクロナス・ダイナミック・ランダムアクセスメモリ（enhanced SDRAM、ESDRAM）、シンクロナス・リンク・ダイナミック・ランダムアクセスメモリ（synchlink DRAM、SLDRAM）、およびダイレクトランバス・ダイナミック・ランダムアクセスメモリ（direct rambus RAM、DR RAM）が使用されてもよい。本明細書に記載されるシステムおよび方法のメモリは、これらおよび別の適切なタイプの任意のメモリを含むが、これらに限定されないことに留意されたい。

前述の実施形態のすべてまたは一部は、ソフトウェア、ハードウェア、ファームウェア、またはそれらの任意の組み合わせを使用して実施され得る。実施形態を実施するためにソフトウェアが使用される場合、実施形態は、完全に、または部分的に、コンピュータプログラム製品の形態で実施され得る。コンピュータプログラム製品は、1つまたは複数のコンピュータプログラムまたは命令を含む。コンピュータプログラムまたは命令がコンピュータにロードされ実行されると、本出願の実施形態による手順または機能がすべてまたは部分的に生成される。コンピュータは、汎用コンピュータ、専用コンピュータ、コンピュータネットワーク、または他のプログラマブル装置であり得る。コンピュータプログラムまたは命令は、コンピュータ可読記憶媒体に格納されてよく、またはコンピュータ可読記憶媒体を使用して送信され得る。コンピュータ可読記憶媒体は、コンピュータによってアクセス可能な任意の使用可能な媒体、または1つもしくは複数の使用可能な媒体を統合するサーバなどのデータ記憶デバイスであってもよい。使用可能媒体は、磁気媒体、例えば、フロッピー（登録商標）ディスク、ハードディスク、もしくは磁気テープであってよく、または光学媒体、例えば、DVDであってよく、または半導体媒体、例えば、ソリッドステートドライブ（solid state disk、SSD）であってよい。

本発明の実施形態で説明されている様々な例示的な論理ユニットおよび回路は、汎用プロセッサ、デジタル信号プロセッサ、特定用途向け集積回路（ASIC）、フィールドプログラマブルゲートアレイ（FPGA）もしくは別のプログラマブル論理装置、ディスクリートゲートもしくはトランジスタ論理、ディスクリートハードウェアコンポーネント、またはこれらの任意の組み合わせの設計を使用して、説明されている機能を実施または操作し得る。汎用プロセッサは、マイクロプロセッサであり得る。任意選択で、汎用プロセッサはまた、任意の従来のプロセッサ、コントローラ、マイクロコントローラ、または状態機械であってもよい。プロセッサはまた、デジタル信号プロセッサおよびマイクロプロセッサ、複数のマイクロプロセッサ、デジタル信号プロセッサコアを有する1つもしくは複数のマイクロプロセッサ、または任意の他の同様の構成など、コンピューティング装置の組み合わせによって実装されてもよい。

本出願の実施形態に記載される方法またはアルゴリズムのステップは、ハードウェア、プロセッサによって実行されるソフトウェアユニット、またはそれらの組み合わせに直接組み込まれ得る。ソフトウェアユニットは、RAMメモリ、フラッシュメモリ、ROMメモリ、EPROMメモリ、EEPROMメモリ、レジスタ、ハードディスク、リムーバブル磁気ディスク、CD-ROM、または当技術分野における任意の他の形態の記憶媒体に格納することができる。例示的に、記憶媒体は、プロセッサが記憶媒体から情報を読み取り、記憶媒体に情報を書き込むことができるように、プロセッサに接続することができる。あるいは、記憶媒体はプロセッサにさらに統合されていてもよい。プロセッサおよび記憶媒体は、ASICに配置されてもよく、ASICは、端末デバイスに配置されてもよい。あるいは、プロセッサと記憶媒体とは、端末デバイスの異なる構成要素に配置されていてもよい。

これらのコンピュータプログラム命令はまた、コンピュータまたは別のプログラマブルデータ処理デバイス上にロードされ得て、これにより一連の動作およびステップがコンピュータまたは別のプログラマブルデバイス上で実行されて、コンピュータ実施処理を生成する。したがって、コンピュータまたは別のプログラマブルデバイス上で実行される命令は、フローチャートの1つもしくは複数のプロセスおよび／またはブロック図の1つもしくは複数のブロックにおける特定の機能を実施するためのステップを提供する。

本出願の実施形態は、具体的な特徴を参照して説明されているが、本出願の実施形態の趣旨および範囲から逸脱することなく、それらに様々な修正および組み合わせが行われ得ることは明らかである。それに応じて、明細書および添付の図面は、添付の特許請求の範囲によって定義される本出願の実施形態の例示的な説明にすぎず、本出願の実施形態の範囲を包含する修正、変形、組み合わせまたは均等物のいずれかまたはすべてとみなされる。

1 URLLCサービスデータ
2 URLLCサービスデータ
700 装置
701 記憶ユニット
702 処理ユニット
703 通信ユニット
800 装置
810 プロセッサ
820 メモリ
830 トランシーバ
900 端末デバイス

Claims (40)

1. 通信方法であって、
   端末デバイスにより、スケジューリング要求SRをトリガするステップと、
   前記SRを搬送する物理アップリンク制御チャネルPUCCHと第1のデータパケットを搬送する物理アップリンク共有チャネルPUSCHが第1のアップリンクリソースの時間領域において重複すると判断した場合、前記端末デバイスにより、前記第1のアップリンクリソース上での前記PUSCHの処理状態を取得するステップと、
   前記端末デバイスにより、前記第1のアップリンクリソース上での前記PUSCHの前記処理状態に基づいて、重複する時間領域リソース上で前記PUCCHまたは前記PUSCHを送信するステップと、
   を含む方法。
2. 前記端末デバイスにより、前記第1のアップリンクリソース上での前記PUSCHの前記処理状態に基づいて、重複する時間領域リソース上で前記PUCCHを送信する前記ステップが、
   前記第1のアップリンクリソース上での前記PUSCHの前記処理状態が処理完了である場合に、前記SRをトリガするための論理チャネルの第1の優先度が前記第1のデータパケットの論理チャネルの第2の優先度以上であると判断した場合、前記端末デバイスにより、前記重複する時間領域リソース上で前記PUCCHを送信するステップであって、前記第2の優先度が前記第1のデータパケットの前記論理チャネルの最高優先度である、ステップ
   を含む、請求項1に記載の方法。
3. 前記第1のデータパケットがメディアアクセス制御プロトコルデータユニットMAC PDUであり、
   前記第1のアップリンクリソース上での前記PUSCHの前記処理状態が処理完了であることは、
   前記第1のアップリンクリソース上での前記PUSCHの前記処理状態が、前記MAC PDUが組み立て済みであること
   を含む、請求項2に記載の方法。
4. 第1の優先度が第2の優先度以上であると判断した場合、前記端末デバイスにより、前記重複する時間領域リソース上で前記PUCCHを送信する前記ステップが、
   MAC層において、前記第1の優先度が前記第2の優先度以上であると判断した場合、前記端末デバイスにより、第1の指示情報を前記端末デバイスの物理層に送信するステップと、
   前記端末デバイスにより、前記物理層において、前記第1の指示情報に基づいて前記重複する時間領域リソース上で前記PUCCHを送信するステップと、
   を含むか、または
   前記端末デバイスにより、MAC層において、前記第1の優先度および前記第2の優先度を前記物理層に通知し、前記物理層において、前記第1の優先度が前記第2の優先度以上であると判断した場合、前記端末デバイスにより、前記重複する時間領域リソース上で前記PUCCHを送信するステップ
   を含む、請求項2または3に記載の方法。
5. 前記第2の優先度は、前記端末デバイスが前記第1のデータパケットを組み立てるときに前記端末デバイスによって取得される、請求項2から4のいずれか一項に記載の方法。
6. 通信方法であって、
   端末デバイスにより、SRをトリガするステップと、
   前記SRを搬送するPUCCHと第1のデータパケットを搬送するPUSCHが第1のアップリンクリソースの時間領域において重複すると判断した場合、前記端末デバイスにより、前記PUSCHによって占有されるリソースおよび前記SRをトリガするための論理チャネルのリソース要求に基づいて、重複する時間領域リソース上で前記PUCCHまたは前記PUSCHを送信するステップと、
   を含む方法。
7. 前記端末デバイスにより、前記PUSCHによって占有されるリソースおよび前記SRをトリガするための論理チャネルのリソース要求に基づいて、重複する時間領域リソース上で前記PUSCHを送信する前記ステップが、
   前記PUSCHによって占有される前記リソースが前記SRをトリガするための前記論理チャネルの前記リソース要求を満たすと判断した場合、前記端末デバイスにより、前記重複する時間領域リソース上で前記PUSCHを送信するステップ
   を含む、請求項6に記載の方法。
8. 前記PUSCHによって占有される前記リソースが前記SRをトリガするための前記論理チャネルの前記リソース要求を満たすと判断した場合、前記端末デバイスにより、前記重複する時間領域リソース上で前記PUSCHを送信する前記ステップが、
   前記SRをトリガするための前記論理チャネルの第1の優先度が前記第1のデータパケットの論理チャネルの第2の優先度以下であると判断した場合、前記端末デバイスにより、前記重複する時間領域リソース上で前記PUSCHを送信するステップであって、前記第2の優先度が前記第1のデータパケットの前記論理チャネルの最高優先度である、ステップ
   を含む、請求項7に記載の方法。
9. 前記第1の優先度が前記第2の優先度よりも高い場合、前記端末デバイスにより、前記重複する時間領域リソース上で前記PUCCHを送信するステップ
   をさらに含む、請求項8に記載の方法。
10. 前記端末デバイスにより、前記PUSCHによって占有されるリソースおよび前記SRをトリガするための論理チャネルのリソース要求に基づいて、重複する時間領域リソース上で前記PUCCHを送信する前記ステップが、
    前記PUSCHによって占有される前記リソースが前記SRをトリガするための前記論理チャネルの前記リソース要求を満たさないと判断した場合、前記端末デバイスにより、前記重複する時間領域リソース上で前記PUCCHを送信するステップ
    を含む、請求項6に記載の方法。
11. 前記端末デバイスにより、第2のアップリンクリソース上で前記第1のデータパケットを送信するステップであって、前記第2のアップリンクリソースおよび前記第1のアップリンクリソースが同じHARQプロセスに対応する、ステップ
    をさらに含む、請求項2から5、請求項9または請求項10のいずれか一項に記載の方法。
12. 前記第1のデータパケットが、前記第2のアップリンクリソースに対応する前記HARQプロセスのバッファに格納されている、請求項11に記載の方法。
13. 前記端末デバイスにより、第2のアップリンクリソース上で第2のデータパケットを送信するステップであって、前記第2のデータパケットが前記第1のデータパケットの情報の一部または全部を含む、ステップ
    をさらに含む、請求項2から5、請求項9または請求項10のいずれか一項に記載の方法。
14. 前記第1のアップリンクリソースおよび前記第2のアップリンクリソースの両方が、事前設定されたグラントリソースである、請求項11から13のいずれか一項に記載の方法。
15. 前記端末デバイスにより、第3の指示情報をネットワークデバイスに送信するステップであって、前記第3の指示情報が、前記第1のデータパケットが送信されていないか、または完全には送信されていないことを示すために使用される、ステップ
    をさらに含む、請求項2から5、請求項9または請求項10のいずれか一項に記載の方法。
16. 通信方法であって、
    端末デバイスにより、第1のアップリンクリソース上で送信される第1のデータパケットを組み立てるステップと
    前記第1のデータパケットが送信されていないか、または完全には送信されていないと判断した場合、前記端末デバイスにより、第2のアップリンクリソース上で前記第1のデータパケットを送信するステップであって、前記第2のアップリンクリソースおよび前記第1のアップリンクリソースが同じHARQプロセスに対応する、ステップと、
    を含む方法。
17. 前記端末デバイスにより、前記第1のデータパケットが送信されていないか、または完全には送信されていないと判断する前記ステップが、
    SRを搬送するPUCCHと前記第1のデータパケットを搬送するPUSCHが前記第1のアップリンクリソースの時間領域において重複する場合、前記端末デバイスにより、前記第1のアップリンクリソース上で前記PUCCHを送信するステップ
    を含む、請求項16に記載の方法。
18. 前記第1のアップリンクリソースおよび前記第2のアップリンクリソースの両方が、事前設定されたグラントリソースである、請求項16または17に記載の方法。
19. 前記第1のデータパケットが、前記第2のアップリンクリソースに対応する前記HARQプロセスのバッファに格納されている、請求項16から18のいずれか一項に記載の方法。
20. 通信装置であって、
    処理ユニットおよび通信ユニットを備え、
    前記処理ユニットが、
    スケジューリング要求SRをトリガし、
    前記SRを搬送するPUCCHと第1のデータパケットを搬送するPUSCHが第1のアップリンクリソースの時間領域において重複すると判断した場合、前記第1のアップリンクリソース上での前記PUSCHの処理状態を取得し、
    前記第1のアップリンクリソース上での前記PUSCHの前記処理状態に基づいて、前記通信ユニットを使用して、重複する時間領域リソース上で前記PUCCHまたは前記PUSCHを送信する
    ように構成されている、装置。
21. 前記処理ユニットが、
    前記第1のアップリンクリソース上での前記PUSCHの前記処理状態が処理完了である場合に、前記SRをトリガするための論理チャネルの第1の優先度が前記第1のデータパケットの論理チャネルの第2の優先度以上であると判断した場合、前記通信ユニットを使用して、前記重複する時間領域リソース上で前記PUCCHを送信し、前記第2の優先度が前記第1のデータパケットの前記論理チャネルの最高優先度である、
    ようにさらに構成されている、請求項20に記載の装置。
22. 前記第1のデータパケットがMAC PDUであり、
    前記第1のアップリンクリソース上での前記PUSCHの前記処理状態が処理完了であることは、
    前記第1のアップリンクリソース上での前記PUSCHの前記処理状態が、前記MAC PDUが組み立て済みであること
    を含む、請求項21に記載の装置。
23. 前記処理ユニットが、
    MAC層において、前記第1の優先度が前記第2の優先度以上であると判断した場合、第1の指示情報を物理層に送信し、前記通信ユニットを使用して、前記物理層において、前記第1の指示情報に基づいて前記重複する時間領域リソース上で前記PUCCHを送信するか、または
    MAC層において、前記第1の優先度および前記第2の優先度を前記物理層に通知し、前記物理層において、前記第1の優先度が前記第2の優先度以上であると判断した場合、前記通信ユニットを使用して、前記重複する時間領域リソース上で前記PUCCHを送信する
    ようにさらに構成されている、請求項21または22に記載の装置。
24. 前記第2の優先度は、前記装置が前記第1のデータパケットを組み立てるときに前記装置によって取得される、請求項21から23のいずれか一項に記載の装置。
25. 通信装置であって、
    処理ユニットおよび通信ユニットを備え、
    前記処理ユニットが、
    スケジューリング要求SRをトリガし、
    前記SRを搬送するPUCCHと第1のデータパケットを搬送するPUSCHが第1のアップリンクリソースの時間領域において重複すると判断した場合、前記PUSCHによって占有されるリソースおよび前記SRをトリガするための論理チャネルのリソース要求に基づいて、前記通信ユニットを使用して、重複する時間領域リソース上で前記PUCCHまたは前記PUSCHを送信する
    ように構成されている、装置。
26. 前記処理ユニットが、
    前記PUSCHによって占有される前記リソースが前記SRをトリガするための前記論理チャネルの前記リソース要求を満たすと判断した場合、前記通信ユニットを使用して、前記重複する時間領域リソース上で前記PUSCHを送信する
    ようにさらに構成されている、請求項25に記載の装置。
27. 前記PUSCHによって占有される前記リソースが前記SRをトリガするための前記論理チャネルの前記リソース要求を満たすと端末デバイスが判断した場合に、前記処理ユニットが、
    前記SRをトリガするための前記論理チャネルの第1の優先度が前記第1のデータパケットの論理チャネルの第2の優先度以下であると判断した場合、前記通信ユニットを使用して、前記重複する時間領域リソース上で前記PUSCHを送信し、前記第2の優先度が前記第1のデータパケットの前記論理チャネルの最高優先度である、
    ようにさらに構成されている、請求項26に記載の装置。
28. 前記処理ユニットが、
    前記第1の優先度が前記第2の優先度よりも高い場合、前記通信ユニットを使用して、前記重複する時間領域リソース上で前記PUCCHを送信する
    ようにさらに構成されている、請求項27に記載の装置。
29. 前記処理ユニットが、
    前記PUSCHによって占有される前記リソースが前記SRをトリガするための前記論理チャネルの前記リソース要求を満たさないと判断した場合、前記通信ユニットを使用して、前記重複する時間領域リソース上で前記PUCCHを送信する
    ようにさらに構成されている、請求項25に記載の装置。
30. 前記通信ユニットが、
    第2のアップリンクリソース上で前記第1のデータパケットを送信し、前記第2のアップリンクリソースおよび前記第1のアップリンクリソースが同じHARQプロセスに対応する、
    ようにさらに構成されている、請求項21から24、請求項28または請求項29のいずれか一項に記載の装置。
31. 前記第1のデータパケットが、前記第2のアップリンクリソースに対応する前記HARQプロセスのバッファに格納されている、請求項30に記載の装置。
32. 前記通信ユニットが、
    第2のアップリンクリソース上で第2のデータパケットを送信し、前記第2のデータパケットが前記第1のデータパケットの情報の一部または全部を含む、
    ようにさらに構成されている、請求項21から24、請求項28または請求項29のいずれか一項に記載の装置。
33. 前記第1のアップリンクリソースおよび前記第2のアップリンクリソースの両方が、事前設定されたグラントリソースである、請求項30から32のいずれか一項に記載の装置。
34. 前記通信ユニットが、
    第3の指示情報をネットワークデバイスに送信し、前記第3の指示情報が、前記第1のデータパケットが送信されていないか、または完全には送信されていないことを示すために使用される、
    ようにさらに構成されている、請求項21から24、請求項28または請求項29のいずれか一項に記載の装置。
35. 通信装置であって、
    処理ユニットおよび通信ユニットを備え、
    前記処理ユニットが、
    第1のアップリンクリソース上で送信される第1のデータパケットを組み立て、
    前記第1のデータパケットが送信されていないか、または完全には送信されていないと判断した場合、前記通信ユニットを使用して、第2のアップリンクリソース上で前記第1のデータパケットを送信し、前記第2のアップリンクリソースおよび前記第1のアップリンクリソースが同じHARQプロセスに対応する、
    ように構成されている、装置。
36. 前記処理ユニットが、前記第1のデータパケットが送信されていないか、または完全には送信されていないと判断することが、
    SRを搬送するPUCCHと前記第1のデータパケットを搬送するPUSCHが前記第1のアップリンクリソースの時間領域において重複する場合、前記処理ユニットが、前記通信ユニットを使用して、前記第1のアップリンクリソース上で前記PUCCHを送信すること
    を含む、請求項35に記載の装置。
37. 前記第1のアップリンクリソースおよび前記第2のアップリンクリソースの両方が、事前設定されたグラントリソースである、請求項35または36に記載の装置。
38. 前記第1のデータパケットが、前記第2のアップリンクリソースに対応する前記HARQプロセスのバッファに格納されている、請求項35から37のいずれか一項に記載の装置。
39. 通信装置であって、プロセッサおよびメモリを備え、前記プロセッサが前記メモリに格納された命令を実行するように構成され、前記命令が実行されると、前記装置が請求項1から19のいずれか一項に記載の方法を実行可能となる、装置。
40. 命令を含み、前記命令が実行されると、請求項1から19のいずれか一項に記載の方法が実施される、コンピュータ可読記憶媒体。

Images