特許 7462053 不連続受信ＤＲＸパラメーター構成方法及び装置

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

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-03-27

(45)【発行日】2024-04-04

(54)【発明の名称】不連続受信ＤＲＸパラメーター構成方法及び装置

(51)【国際特許分類】

   H04W 52/02 20090101AFI20240328BHJP

   H04W 92/18 20090101ALI20240328BHJP

   H04W 72/40 20230101ALI20240328BHJP

   H04W 72/25 20230101ALI20240328BHJP

【ＦＩ】

H04W52/02 111

H04W92/18

H04W72/40

H04W72/25

【請求項の数】 16

(21)【出願番号】P 2022542051

(86)(22)【出願日】2021-01-07

(65)【公表番号】

(43)【公表日】2023-03-13

(86)【国際出願番号】 CN2021070649

(87)【国際公開番号】W WO2021139719

(87)【国際公開日】2021-07-15

【審査請求日】2022-10-04

(31)【優先権主張番号】202010019617.3

(32)【優先日】2020-01-08

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

(73)【特許権者】

【識別番号】503433420

【氏名又は名称】華為技術有限公司

【氏名又は名称原語表記】ＨＵＡＷＥＩ ＴＥＣＨＮＯＬＯＧＩＥＳ ＣＯ．，ＬＴＤ．

【住所又は居所原語表記】Ｈｕａｗｅｉ Ａｄｍｉｎｉｓｔｒａｔｉｏｎ Ｂｕｉｌｄｉｎｇ， Ｂａｎｔｉａｎ， Ｌｏｎｇｇａｎｇ Ｄｉｓｔｒｉｃｔ， Ｓｈｅｎｚｈｅｎ， Ｇｕａｎｇｄｏｎｇ ５１８１２９， Ｐ．Ｒ． Ｃｈｉｎａ

(74)【代理人】

【識別番号】100107766

【弁理士】

【氏名又は名称】伊東 忠重

(74)【代理人】

【識別番号】100070150

【弁理士】

【氏名又は名称】伊東 忠彦

(74)【代理人】

【識別番号】100135079

【弁理士】

【氏名又は名称】宮崎 修

(72)【発明者】

【氏名】ジャーン，ムオンチェン

(72)【発明者】

【氏名】シュイ，ハイボー

(72)【発明者】

【氏名】ワーン，ジエン

【審査官】吉倉 大智

(56)【参考文献】

【文献】国際公開第２０１８／０６４４７７（ＷＯ，Ａ１）

【文献】特表２０１９－５２５６０７（ＪＰ，Ａ）

【文献】Huawei, Hisilicon，Some considerations about DRX on PC5，3GPP TSG RAN WG2 #98 R2-1704718，2017年05月05日

【文献】LG Electronics Inc.，Remaining MAC issues and response to RAN1 LS，3GPP TSG RAN WG2 #108 R2-1916123，2019年11月08日

【文献】vivo，Physical layer structure for NR sidelink，3GPP TSG RAN WG1 #99 R1-1912020，2019年11月09日

【文献】Ericsson，Miscellaneous non-controversial corrections Set IV，3GPP TSG RAN WG2 #108 R2-1916627，2019年12月05日

【文献】Huawei, HiSilicon，Correction to 38.321 on the power saving for pending SR of delay-tolarate service，3GPP TSG RAN WG2 #102 R2-1808477，2018年05月11日

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｈ０４Ｂ ７／２４－ ７／２６

Ｈ０４Ｗ ４／００－９９／００

(57)【特許請求の範囲】

【請求項1】

不連続受信(DRX)パラメーター構成方法であって、当該方法は、
第1の通信装置によって、第1のサイドリンクDRXパラメーターを取得するステップであって、前記第1のサイドリンクDRXパラメーターは、前記第1の通信装置が前記第1のサイドリンクDRXパラメーターに基づいてサイドリンクにおいて、前記第1の通信装置に接続された少なくとも1つの第2の通信装置にデータを送信するのに使用される、ステップと、
前記第1の通信装置によって、前記少なくとも1つの第2の通信装置に前記第1のサイドリンクDRXパラメーターを送信するステップと、
サイドリンクリソース情報を前記第1の通信装置によって受信するステップと、
前記第1の通信装置によって、前記第1のサイドリンクDRXパラメーター、前記サイドリンクリソース情報、及び論理チャネル優先度に基づいて、サイドリンクの活動時間の中にある第3の通信装置を決定するステップであって、前記第3の通信装置は前記少なくとも1つの第2の通信装置のうちの一つである、ステップと、
前記第1の通信装置によって、前記サイドリンクリソース情報に基づいて、前記第3の通信装置との間で通信を実行するステップと、を含む、
方法。

【請求項2】

前記第1の通信装置によって、前記第1のサイドリンクDRXパラメーター、前記サイドリンクリソース情報、及び前記論理チャネル優先度に基づいて、前記第3の通信装置を決定する前記ステップは、
前記第1の通信装置によって、前記第1のサイドリンクDRXパラメーター及び前記サイドリンクリソース情報に基づいて、前記少なくとも1つの第2の通信装置のうちでサイドリンクリソース情報に対応する時間内のサイドリンクの前記活動時間の中にある少なくとも1つの通信装置を決定するステップであって、前記少なくとも1つの通信装置は、前記第3の通信装置を含む、ステップ、を含む、請求項1に記載の方法。

【請求項3】

前記第3の通信装置は、前記サイドリンクリソース情報に対応する時間内の前記活動時間の中にある前記少なくとも1つの第2の通信装置のうちで優先度が最も高い論理チャネルを有する、請求項1又は2に記載の方法。

【請求項4】

前記第1の通信装置によって、前記第3の通信装置との間で通信を実行する前記ステップは、
前記第1の通信装置によって、前記第3の通信装置にSCIを送信するステップであって、前記SCIは、前記サイドリンクリソース情報を含み、前記サイドリンクリソース情報は、前記第1の通信装置が送信するデータを、前記第3の通信装置が、前記サイドリンクリソース情報が示すサイドリンクリソースで受信するのに使用される、ステップ、を含む、請求項1乃至3のうちのいずれか1項に記載の方法。

【請求項5】

第1の通信装置によって、第1のサイドリンクDRXパラメーターを取得する前記ステップは、
前記第1の通信装置によって、補助情報および前記少なくとも1つの第2の通信装置の識別子を第1のネットワークデバイスに送信するステップであって、前記補助情報は前記第1のサイドリンクDRXパラメーターを決定するために使用される、ステップと、
前記第1のネットワークデバイスからの前記第1のサイドリンクDRXパラメーターを前記第1の通信装置によって受信するステップであって、前記第1の通信装置は、前記第1のネットワークデバイスのカバレッジ領域の中に存在する、ステップとを含む、
請求項1乃至4のうちのいずれか1項に記載の方法。

【請求項6】

前記第1のネットワークデバイスからの前記第1のサイドリンクDRXパラメーターを前記第1の通信装置によって受信する前記ステップは、
前記第1のネットワークデバイスからの第1の構成メッセージを前記第1の通信装置によって受信するステップであって、前記第1の構成メッセージは、前記第1のサイドリンクDRXパラメーター及び前記少なくとも1つの第2の通信装置の識別子を含む、ステップを含む、請求項5に記載の方法。

【請求項7】

前記第1の通信装置によって、前記少なくとも1つの第2の通信装置に前記第1のサイドリンクDRXパラメーターを送信する前記ステップは、
前記第1の通信装置によって、前記少なくとも1つの第2の通信装置に第2の構成メッセージを送信するステップであって、前記第2の構成メッセージは、前記第1のサイドリンクDRXパラメーターを含む、ステップを含む、請求項1乃至6のうちのいずれか1項に記載の方法。

【請求項8】

第1の通信装置によって、第1のサイドリンクDRXパラメーターを取得する前記ステップは、
前記第1の通信装置によって、サイドリンクにおける前記第1の通信装置のデータ伝送要件に基づいて、前記少なくとも1つの第2の通信装置の前記第1のサイドリンクDRXパラメーターを決定することを含む、
請求項１ないし７のうちいずれか一項に記載の方法。

【請求項9】

前記サイドリンクDRXパラメーターおよび前記少なくとも1つの第2の通信装置の識別子を第1のネットワークデバイスに送信するステップをさらに含む、請求項8に記載の方法。

【請求項10】

前記データ伝送要件が前記サイドリンクでの前記第1の通信装置のサービスのためのサービス品質（QoS）である、請求項8又は9に記載の方法。

【請求項11】

前記第1のサイドリンクDRXパラメーターは、
DRX-onDurationTimer、DRX-SlotOffset、DRX-InactivityTimer、DRX-RetransmissionTimer、DRX-ShortCycle、DRX-ShortCycleTimer、DRX-HARQ-RTT-Timer、のうちの少なくとも1つを含む、請求項1乃至10のうちのいずれか1項に記載の方法。

【請求項12】

サイドリンクの前記活動時間は、
前記第1のサイドリンクDRXパラメーターが含んでいるサイドリンクDRX-onDurationTimer又はサイドリンクDRX-InactivityTimerが実行されている、又は、
前記第1のサイドリンクDRXパラメーターが含んでいるサイドリンクDRX-RetransmissionTimerが実行されている、又は、
前記第1のサイドリンクDRXパラメーターが含んでいるra-ContentionResolutionTimerが実行されている、又は、
前記第2の通信装置が、物理アップリンク制御チャネル(PUCCH)においてSRを送信しており、前記SRが、現時点で、保留中の状態となっている、
期間を含む、請求項1乃至11のうちのいずれか1項に記載の方法。

【請求項13】

前記第1の通信装置は、端末デバイス又は通信チップであり、前記第2の通信装置は、端末デバイス又は通信チップである、請求項1乃至12のうちのいずれか1項に記載の方法。

【請求項14】

デバイストゥデバイス(D2D)通信シナリオに適用されるとともに、プロセッサを含む通信装置であって、前記プロセッサは、メモリに結合され、
前記メモリは、コンピュータプログラム又は命令を格納するように構成され、
前記プロセッサは、前記メモリの中に格納されている前記命令又は前記コンピュータプログラムを実行するように構成され、それによって、当該装置は、請求項1乃至13のうちのいずれか1項に記載の方法を実行する、
通信装置。

【請求項15】

請求項14に記載の通信装置及び第1のネットワークデバイスを含む通信システムであって、
前記第1のネットワークデバイスは、
前記第1の通信装置に前記第1のサイドリンクDRXパラメーターを送信し、
前記第1の通信装置にサイドリンクリソース情報を送信するように構成されている、
通信システム。

【請求項16】

プログラム又は命令を含むコンピュータ読み取り可能な記憶媒体であって、前記プログラム又は命令がプロセッサによって実行されるときに、請求項1乃至13のうちのいずれか1項に記載の方法を実行する、コンピュータ読み取り可能な記憶媒体。

【発明の詳細な説明】

【技術分野】

【0001】

[関連出願への相互参照]
この出願は、2020年1月8日付で中国国家知的財産管理局に出願された"不連続受信DRXパラメーター構成方法及び装置"と題する中国特許出願番号第202010019617.3号に基づく優先権を主張し、その内容は、その全体が参照により本明細書に組み込まれる。

【0002】

この出願の複数の実施形態は、通信分野に関し、特に、不連続受信DRXパラメーター構成方法及び装置に関する。

【背景技術】

【0003】

第5世代モバイルネットワーク(5th generation mobile network, 5G)新たな無線(new radio, NR)においては、端末デバイスの不必要な電力消費を減少させるために、Uuインターフェイスに不連続受信(discontinuous reception, DRX)メカニズムを適用して、無線リソース制御(radio resource control, RRC)接続モードになっている端末デバイスがエネルギーを節約するのを支援する。Uuインターフェイスは、端末デバイスと(例えば、基地局等の)ネットワークデバイスとの間のインターフェイスである。DRXの基本的な原理は、パケットベースのデータフローが、通常は、バースト性となっているということである。具体的にいうと、端末デバイスは、ある時間的な期間の中でスケジューリングされる、言い換えると、受信されるべきデータは存在するが、一方で、端末デバイスは、以降の比較的長い時間的な期間の中ではスケジューリングされない。端末デバイスがスケジューリングされないときに、端末デバイスが物理ダウンリンク制御チャネル(physical downlink control channel, PDCCH)をリッスンしないようにすることによって、端末デバイスの消費電力を減少させてもよく、それによって、端末デバイスのバッテリーの耐用年数を長くすることを可能とする。

【0004】

UuインターフェイスにDRXメカニズムを適用するのとは異なり、DRXメカニズムは、現在の5Gデバイストゥデバイス(device to device, D2D)通信シナリオには適用されない。送信端がサイドリンク(sidelink)を通じて受信端との間で通信するときに、その送信端は、構成されているリソースを使用することによって、受信端に情報を伝送し、一方、受信端は、サイドリンクにおいて、受信されるべき情報を継続的にリッスンする。結果として、受信側は、電力を過度に消費する。したがって、現時点では、D2Dシナリオにおいて受信端の電力消費を減少させる方法が緊急に必要とされている。

【発明の概要】

【0005】

この出願の複数の実施形態は、不連続受信DRXパラメーター構成方法及び装置を提供して、D2Dシナリオにおいては、受信端が情報を継続的にリッスンするため、その受信端の電力消費が大きくなるという問題を解決する。

【0006】

上記の目的を達成するために、この出願の複数の実施形態において、以下の技術的解決方法を使用する。

【0007】

第1の態様によれば、不連続受信DRXパラメーター構成方法が提供される。当該方法は、デバイストゥデバイスD2D通信シナリオに適用され、当該方法は、第1の通信装置が、第1のDRXパラメーターを取得するステップであって、前記第1のDRXパラメーターは、前記第1の通信装置が前記第1のDRXパラメーターに基づいてサイドリンクにおいて第2の通信装置にデータを送信するのに使用される、ステップと、前記第1の通信装置が、前記第2の通信装置に前記第1のDRXパラメーターを送信するステップと、を含む。

【0008】

したがって、この出願のこの実施形態においては、サイドリンクにおいて、データ受信端として機能する第2の通信装置は、第1のDRXに基づいて、第2の通信装置の活動時間及び休眠期間を決定し、そして、活動時間の中でのみデータを受信してもよい。このように、データ受信端として機能する第2の通信装置は、サイドリンクにおいて受信される情報を継続的にリッスンする必要がなく、データ受信端が電力消費を減少させるとともに、電力を節約するのを支援する。

【0009】

ある1つの可能な設計において、第1の通信装置が、第1のDRXパラメーターを取得することは、前記第1の通信装置が、第1のネットワークデバイスからの前記第1のDRXパラメーターを受信するステップを含む。前記第1の通信装置は、前記第1のネットワークデバイスのカバレッジ領域の中に存在する。すなわち、第1のDRXパラメーターは、データ送信端においてネットワークデバイスによって構成されてもよい。例えば、第1のDRXパラメーターは、第1の通信装置に対応する第1の基地局によって構成される。第1の基地局は、現時点で利用可能なリソースに基づいて、第1のDRXパラメーターを決定してもよく、それによって、第1のDRXパラメーターは、第1の基地局のリソース割り当てを満たすことが可能であり、第1の通信装置は、第1の基地局が割り当てるリソースによって、第2の通信装置にデータを送信する。

【0010】

ある1つの可能な設計において、前記第1の通信装置が、第1のネットワークデバイスからの前記第1のDRXパラメーターを受信することの前に、第1の通信装置が、第1のDRXパラメーターを取得することは、前記第1の通信装置が、前記第1のネットワークデバイスに、補助情報及び前記第2の通信装置の識別子を送信することをさらに含む。前記補助情報は、前記第1のネットワークデバイスが前記補助情報を参照して前記第1のDRXパラメーターを決定するのに使用される。データ送信端として機能する第1の通信装置は、データの送信時の条件を知っている。したがって、この出願においては、第1の通信装置は、第1のネットワークデバイスに補助情報を送信してもよく、第1のネットワークデバイスは、その補助情報に基づいて、第2の通信装置に対応するDRXパラメーターを決定し、それによって、第2の通信装置は、構成されているDRXパラメーターに基づいて、第2の通信装置が活動時間の中にある継続期間及び第2の通信装置が休眠期間(非活動時間の継続期間)の中にある継続期間及び活動時間を決定し、そして、第2の通信装置が活動時間の中にあるその継続期間の中でデータを受信してもよい。このように、第2の通信装置及び第1の通信装置が、同じネットワークデバイスのカバレッジ領域の中には存在しない場合に、D2Dシナリオにおいては、第1の通信装置及び第1のネットワークデバイスの双方は、第2の通信装置のDRXパラメーターを格納してもよく、第1のネットワークデバイスは、そのDRXパラメーターに基づいて、データをスケジューリングしてもよく、そして、第1の通信装置は、そのDRXパラメーターに基づいて、第2の通信装置にデータを送信してもよい。加えて、データ受信端として機能する第2の通信装置は、常時、データリスニング状態となっている必要はなく、それによって、第2の通信装置の消費電力を減少させることが可能であり、第2の通信装置の電力を節約する。

【0011】

ある1つの可能な設計において、前記補助情報は、前記サイドリンクにおける前記第1の通信装置のデータ伝送要件を含み、前記補助情報は、前記サイドリンクにおける前記第1の通信装置のデータ伝送要件に基づいて前記第1の通信装置が決定する第2のDRXパラメーターを含むか、又は、前記補助情報は、前記サイドリンクにおける前記第1の通信装置のデータ伝送要件及び前記データ伝送要件に基づいて前記第1の通信装置が決定する第2のDRXパラメーターを含む。データ伝送要件は、第1の通信装置が要求するQoSであってもよい。

【0012】

例えば、第1の通信装置がサイドリンクにおいて第2の通信装置との間で通信する必要があるサービスについて、QoS要件が比較的高く、低遅延データ伝送を実行する必要がある場合に、第1のネットワークデバイスは、第1のDRXパラメーターに対応するDRXサイクルの中で、休眠期間の継続期間が比較的短く、且つ、活動時間の継続期間が比較的長いということを決定してもよい。このように、第1の通信装置が、データを送信する必要があるときに、第2の通信装置は、時間内に起動し、第1の通信装置が送信するデータを活動時間の中で受信してもよい。このことは、低遅延要件を満たす。補助情報が、第2のDRXパラメーターを含み、且つ、その第2のDRXパラメーターが、DRXサイクルの中で、休眠期間の継続期間が比較的短く、活動時間の継続期間が比較的長いということを満たす場合に、第1のネットワークデバイスは、第1のDRXパラメーターとしてその第2のDRXパラメーターを使用してもよく、それ以外の場合には、第1のネットワークデバイスは、QoSに基づいて、第1のDRXパラメーターを再決定してもよく、それによって、その第1のDRXパラメーターは、低遅延要件を満たす。

【0013】

ある1つの可能な設計において、第1の通信装置が、第1のDRXパラメーターを取得することは、前記第1の通信装置が、デバイストゥデバイスD2D通信サイドリンクにおける前記第1の通信装置のデータ伝送要件に基づいて、前記第2の通信装置のために構成される前記第1のDRXパラメーターを決定するステップを含む。すなわち、データ送信端として機能する第1の通信装置は、データ受信端として機能する第2の通信装置の第1のDRXパラメーターを構成する。このように、第1の通信装置が第2の通信装置にデータを送信するときに、第1のDRXパラメーターは、第1の通信装置のデータ伝送要件を満たすことが可能である。

【0014】

ある1つの可能な設計において、当該方法は、前記第1の通信装置が、第1のネットワークデバイスに前記第1のDRXパラメーター及び前記第2の通信装置の識別子を送信するステップをさらに含む。第1のDRXパラメーターを決定した後に、第1の通信装置は、また、第1のネットワークデバイスに、決定されている第1のDRXパラメーターを送信してもよく、それによって、第1のネットワークデバイスが、第1の通信装置が伝送するべきデータが存在するということを決定するときに、第1のネットワークデバイスは、第1のDRXパラメーターを参照して第1の通信装置にリソースを割り当ててもよい。

【0015】

ある1つの可能な設計において、当該方法は、前記第1の通信装置が、前記第1のDRXパラメーターを格納し、そして、前記第1のDRXパラメーターと前記第2の通信装置の識別子との間の対応関係を確立するステップをさらに含む。第1の通信装置は、データ受信端として機能する複数の第2の通信装置へのサイドリンク接続を確立することが可能であるため、第1の通信装置は、第1のDRXパラメーターと第2の通信装置の識別子との間の対応関係を確立することが可能であり、それによって、第1の通信装置は、その対応関係に基づいて、データ通信を実行する第2の受信端の第1のDRXパラメーターを決定してもよい。識別子は、レイヤ2IDであってもよい。

【0016】

ある1つの可能な設計において、当該方法は、前記第1の通信装置が、前記第2の通信装置が送信する第1の通知メッセージを受信するステップであって、前記第1の通知メッセージは、前記第1のDRXパラメーターの構成を完了しているということを示す、ステップと、前記第1の通信装置が、前記第1のネットワークデバイスに第2の通知メッセージを送信するステップであって、前記第2の通知メッセージは、前記第1のDRXパラメーターの前記構成を完了しているということを示す、ステップと、をさらに含む。第1のネットワークデバイスが、第2の通知メッセージを受信するときに、第1の通信装置が、送信すべきデータを有している場合には、その第1の通信装置は、リソースを求めて第1のネットワークデバイスに申し込みを行って、申し込まれたリソースによって第2の通信装置にそのデータを送信してもよい。

【0017】

ある1つの可能な設計において、当該方法は、前記第1の通信装置が、第1のネットワークデバイスからのダウンリンク制御情報DCIを受信するステップであって、前記DCIは、前記第1の通信装置が送信するスケジューリング要求に基づいて前記第1のネットワークデバイスが決定する第3の通信装置の識別子、及び、前記第3の通信装置の第1のDRXパラメーターに基づいて決定されて、前記第1の通信装置と前記第3の通信装置とに割り当てられるリソースに関する情報を含む、ステップと、前記第1の通信装置が、前記第3の通信装置にサイドリンク制御情報SCIを送信するステップであって、前記SCIは、前記リソースに関する前記情報を含み、前記リソースに関する前記情報は、前記第1の通信装置が送信するデータを、前記第3の通信装置が、前記リソースに関する前記情報が示す前記リソースによって受信するのに使用される、ステップと、をさらに含む。第3の通信装置は、活動時間の中にあるデータ受信端のうちで、第1のネットワークデバイスが第1のDRXパラメーターに基づいて決定するデータ受信端である。したがって、第1の通信装置が、第1のネットワークデバイスが割り当てるリソースによってデータを送信するときに、第3の通信装置は、活動時間の中にあり、第3の通信装置は、第1のネットワークデバイスが割り当てるリソースによってデータを受信してもよい。加えて、第3の通信装置は、常時、受信すべきデータが存在するか否かをモニタリングする状態にある必要はなく、第3の通信装置の電力を節約する。

【0018】

ある1つの可能な設計において、当該方法は、前記第1の通信装置が、第1のネットワークデバイスからのDCIを受信するステップであって、前記DCIは、前記第1の通信装置に割り当てられて、前記サイドリンクにおいて利用可能とされるリソースに関する情報を含む、ステップと、前記第1の通信装置が、該第1の通信装置に接続される複数の通信装置の第1のDRXパラメーター及び前記リソースに関する情報に基づいて、前記第1の通信装置に接続される前記複数の通信装置のうちで活動時間の中にある少なくとも1つの通信装置を決定するステップと、前記第1の通信装置が、前記少なくとも1つの通信装置のうちで、論理チャネル優先度が最も高い第3の通信装置を決定するステップと、前記第1の通信装置が、前記第3の通信装置にSCIを送信するステップであって、前記SCIは、前記リソースに関する前記情報を含み、前記リソースに関する前記情報は、前記第1の通信装置が送信するデータを、前記第3の通信装置が、前記リソースに関する前記情報が示す前記リソースによって受信するのに使用される、ステップと、をさらに含む。このように、第1の通信装置が、第1のネットワークデバイスが割り当てるリソースに関する情報を受信するときに、第1の通信装置は、第1のDRXパラメーター及びリソースに関する情報に基づいて、活動時間の中にある通信装置のうちで論理チャネル優先度が最も高い第3の通信装置を決定してもよく、それによって、第1の通信装置が、リソースに関する情報が示すリソースによってデータを送信するときに、第3の通信装置は、活動時間の中にあり、且つ、第3の通信装置は、そのリソースによってデータを受信することが可能である。このことは、優先度が最も高い論理チャネルにおけるデータを時間内に受信するとともに、第3の通信装置が、常時、受信すべきデータが存在するか否かをモニタリングする状態にある必要はないということを保証することが可能であり、第3の通信装置の電力を節約する。

【0019】

ある1つの可能な設計において、当該方法は、前記第1の通信装置が、接続が確立されているサイドリンクのすべてから論理チャネル優先度が最も高い第1のサイドリンクを決定し、そして、前記第1のサイドリンクによって前記第1の通信装置に接続されている第3の通信装置の第1のDRXパラメーターを決定するステップと、前記第1の通信装置が、前記第3の通信装置の前記第1のDRXパラメーターに基づいて、リソースプールから、前記第3の通信装置が活動時間の中にあるリソースに関する情報を決定するステップと、前記第1の通信装置が、前記第3の通信装置にSCIを送信するステップであって、前記SCIは、前記リソースに関する前記情報を含み、前記リソースに関する前記情報は、前記第1の通信装置が送信するデータを、前記第3の通信装置が、前記リソースに関する前記情報が示す前記リソースによって受信するのに使用される、ステップと、をさらに含む。このように、第1の通信装置が、優先度が最も高い論理チャネルに対応する第1のサイドリンクを決定するときに、第1の通信装置は、その第1のサイドリンクにおいてデータ受信端として機能する第3の通信装置に対応する第1のDRXパラメーターに基づいて、リソースプールから、第3の通信装置が活動時間の中にあるリソースを決定してもよい。すなわち、第1の通信装置は、第1のDRXパラメーターに基づいて、第3の通信装置の活動時間及び休眠期間を決定して、第3の通信装置が活動時間の中にあるリソースによって、その第3の通信装置にデータを送信してもよい。第3の通信装置は、そのリソースによって、第1の通信装置が送信するデータを受信してもよく、第3の通信装置は、常時、受信すべきデータが存在するか否かをモニタリングする状態にある必要はなく、第3の通信装置の電力を節約する。

【0020】

ある1つの可能な設計において、前記第1の通信装置は、端末デバイス又は通信チップであり、前記第2の通信装置は、端末デバイス又は通信チップである。

【0021】

第2の態様によれば、不連続受信DRXパラメーター構成方法が提供される。当該方法は、デバイストゥデバイスD2D通信シナリオに適用され、当該方法は、第1のネットワークデバイスが、第1のDRXパラメーターを決定するステップであって、前記第1のDRXパラメーターは、第1の通信装置が、前記第1のDRXパラメーターに基づいて、サイドリンクにおいて第2の通信装置にデータを送信するのに使用される、ステップと、前記第1のネットワークデバイスが、前記第1の通信装置に前記第1のDRXパラメーターを送信するステップと、を含む。このように、第1のネットワークデバイス及び第1の通信装置の双方は、第2の通信装置の第1のDRXパラメーターを格納する。第2の通信装置及び第1の通信装置が、同じネットワークデバイスのカバレッジ領域の中には存在しない場合に、D2Dシナリオにおいては、第1のネットワークデバイスは、その第1のDRXパラメーターに基づいて、データをスケジューリングしてもよく、そして、第1の通信装置は、そのDRXパラメーターに基づいて、第2の通信装置にデータを送信してもよい。加えて、データ受信端として機能する第2の通信装置は、常時、データリスニング状態となっている必要はなく、それによって、第2の通信装置の消費電力を減少させることが可能であり、第2の通信装置の電力を節約する。

【0022】

ある1つの可能な設計において、第1のネットワークデバイスが、第1のDRXパラメーターを決定することの前に、当該方法は、前記第1のネットワークデバイスが、前記第1の通信装置が送信する補助情報及び前記第2の通信装置の識別子を受信するステップをさらに含む。前記補助情報は、前記第1のネットワークデバイスが前記補助情報を参照して前記第1のDRXパラメーターを決定するのに使用され、第1の通信装置は、前記第1のネットワークデバイスのカバレッジ領域の中に存在する。したがって、第1のネットワークデバイスが第1のDRXパラメーターを決定するときに、第1のネットワークデバイスは、第1の通信装置が送信する補助情報を参照して、第1のDRXパラメーターを決定してもよく、それによって、決定される第1のDRXパラメーターは、第1の通信装置のデータ伝送要件を満たすことが可能である。

【0023】

ある1つの可能な設計において、前記補助情報は、前記サイドリンクにおける前記第1の通信装置のデータ伝送要件を含み、前記補助情報は、前記サイドリンクにおける前記第1の通信装置のデータ伝送要件に基づいて前記第1の通信装置が決定する第2のDRXパラメーターを含むか、又は、前記補助情報は、前記サイドリンクにおける前記第1の通信装置のデータ伝送要件及び前記データ伝送要件に基づいて前記第1の通信装置が決定する第2のDRXパラメーターを含む。前記データ伝送要件は、前記サイドリンクにおいて前記第1の通信装置のサービスが要求するサービス品質QoSであってもよい。例えば、第1の通信装置がサイドリンクにおいて第2の通信装置との間で通信する必要があるサービスについて、QoS要件が比較的高く、低遅延データ伝送を実行する必要がある場合に、第1のネットワークデバイスは、第1のDRXパラメーターに対応するDRXサイクルの中で、休眠期間の継続期間が比較的短く、且つ、活動時間の継続期間が比較的長いということを決定してもよい。このように、第1の通信装置が、データを送信する必要があるときに、第2の通信装置は、時間内に起動し、第1の通信装置が送信するデータを活動時間の中で受信してもよい。このことは、低遅延要件を満たす。補助情報が、第2のDRXパラメーターを含み、且つ、その第2のDRXパラメーターが、DRXサイクルの中で、休眠期間の継続期間が比較的短く、活動時間の継続期間が比較的長いということを満たす場合に、第1のネットワークデバイスは、第1のDRXパラメーターとしてその第2のDRXパラメーターを使用してもよく、それ以外の場合には、第1のネットワークデバイスは、QoSに基づいて、第1のDRXパラメーターを再決定してもよく、それによって、その第1のDRXパラメーターは、低遅延要件を満たす。

【0024】

ある1つの可能な設計において、第1のネットワークデバイスが、第1のDRXパラメーターを決定することの前に、当該方法は、前記第1のネットワークデバイスが、第2のネットワークデバイスに要求メッセージを送信するステップをさらに含む。前記要求メッセージは、第3のDRXパラメーターを取得することを要求するのに使用され、前記第3のDRXパラメーターは、前記第2のネットワークデバイスが前記第2の通信装置のために構成するUuインターフェイスのDRXパラメーターであり、前記第2の通信装置は、前記第2のネットワークデバイスのカバレッジ領域の中に存在する。第1のネットワークデバイスが、第1のDRXパラメーターを決定することは、前記第1のネットワークデバイスが、前記第3のDRXパラメーターを参照して前記第1のDRXパラメーターを決定するステップを含む。第1の通信装置及び第2の通信装置が、同じネットワークデバイスのカバレッジ領域の中には存在しない場合、すなわち、第1の通信装置が第1のネットワークデバイスのカバレッジ領域の中にあり、且つ、第2の通信装置が第2のネットワークデバイスのカバレッジ領域の中に存在する場合に、第1のネットワークデバイスは、第2のネットワークデバイスに、第2のネットワークデバイスが第2の通信装置のために構成するUuインターフェイスの第3のDRXパラメーターを要求してもよい。第1のネットワークは、第3のDRXパラメーターを参照して、第2の通信装置のためのPC5インターフェイスの第1のDRXパラメーターを構成し、それによって、2つのインターフェイスにおいて、第2の通信装置が活動時間の中にある継続期間及び第2の通信装置が休眠期間の中にある継続期間は、可能な限り同じであってもよい。このように、伝送されるデータが存在するときに、第2の通信装置は、第3のDRXパラメーターに基づいて電力を節約する。加えて、第1の通信装置及び第2の通信装置が、複数の異なるネットワークデバイスのカバレッジ領域の中に存在するときに、第2の通信装置のPC5インターフェイスの第3のDRXパラメーターは、第2の通信装置のUuインターフェイスの第1のDRXパラメーターと整合しているため、さらに、第2の通信装置の電力を節約することが可能である。

【0025】

ある1つの可能な設計において、当該方法は、前記第1のネットワークデバイスが、前記第1の通信装置にダウンリンク制御情報DCIを送信するステップをさらに含む。前記DCIは、活動時間の中にある第3の通信装置の識別子及び前記第1の通信装置に割り当てられるとともに前記サイドリンクにおいて利用可能であるリソースに関する情報を含み、活動時間の中にある前記第3の通信装置の前記識別子は、前記第1のネットワークデバイスが前記第1のDRXパラメーターに基づいて決定する。第3の通信装置は、活動時間の中にある通信装置のうちで、第1のDRXパラメーターに基づいて第1のネットワークデバイスが決定するデータ受信端である。したがって、第1の通信装置が、第1のネットワークデバイスが割り当てるリソースによってデータを送信するときに、第3の通信装置は、活動時間の中にあり、第3の通信装置は、第1のネットワークデバイスが割り当てるリソースによってデータを受信してもよい。加えて、第3の通信装置は、常時、受信すべきデータが存在するか否かをモニタリングする状態にある必要はなく、第3の通信装置の電力を節約する。

【0026】

ある1つの可能な設計において、前記第1の通信装置は、端末デバイス又は通信チップであり、前記第2の通信装置は、端末デバイス又は通信チップである。

【0027】

第3の態様によれば、不連続受信DRXパラメーター構成方法が提供される。当該方法は、第2の通信装が、第1の通信装置からの第1のDRXパラメーターを受信するステップであって、前記第1のDRXパラメーターは、前記第1の通信装置が送信するデータを、前記第2の通信装置が、前記第1のDRXパラメーターに基づいてサイドリンクにおいて受信するのに使用される、ステップと、前記第2の通信装置が、前記第1のDRXパラメーターに基づいて、前記第1の通信装置との間でデータ通信を実行するステップと、を含む。このように、D2Dシナリオにおいて、第2の通信装置は、サイドリンクにおいてデータを継続的にリッスンする必要はなく、第1のDRXパラメーターに基づいて活動時間の中でデータを受信して、第2の通信装置の電力を節約することが可能である。

【0028】

ある1つの可能な設計において、当該方法は、前記第2の通信装置が、前記第1の通信装置からのサイドリンク制御情報SCIを受信するステップをさらに含む。前記SCIは、リソースに関する情報を含み、前記リソースに関する前記情報は、前記第1の通信装置が送信するデータを、前記第2の通信装置が、前記リソースに関する前記情報が示す前記リソースによって受信するのに使用される。このように、第2の通信装置は、第1の通信装置が送信するデータを、SCIの中のリソースに関する情報が示すリソースによって受信してもよい。具体的にいうと、第1の通信装置が、そのリソースによって第2の通信装置にデータを送信するときに、第2の通信装置は、活動時間の中のリソースによって、第1の通信装置が送信するデータを受信して、第3の通信装置の電力を節約してもよい。

【0029】

ある1つの可能な設計において、前記第1の通信装置は、端末デバイス又は通信チップであり、前記第2の通信装置は、端末デバイス又は通信チップである。

【0030】

第4の態様によれば、通信装置が提供され、その通信装置は、デバイストゥデバイスD2D通信シナリオに適用され、第1のDRXパラメーターを取得するように構成される処理ユニットであって、第1のDRXパラメーターは、第1の通信装置が、第1のDRXパラメーターに基づいてサイドリンクにおいて第2の通信装置にデータを送信するのに使用される、処理ユニットと、第2の通信装置に第1のDRXパラメーターを送信するように構成される送信ユニットと、を含む。

【0031】

第5の態様によれば、ネットワークデバイスが提供され、そのネットワークデバイスは、デバイストゥデバイスD2D通信シナリオに適用され、第1のDRXパラメーターを決定するように構成される処理ユニットであって、第1のDRXパラメーターは、第1の通信装置が、第1のDRXパラメーターに基づいてサイドリンクにおいて第2の通信装置にデータを送信するのに使用される、処理ユニットと、第1の通信装置に第1のDRXパラメーターを送信するように構成される送信ユニットと、を含む。

【0032】

第6の態様によれば、通信装置が提供され、その通信装置は、デバイストゥデバイスD2D通信シナリオに適用され、第1の通信装置からの第1のDRXパラメーターを受信するように構成される受信ユニットを含む。第1のDRXパラメーターは、第2の通信装置が、第1のDRXパラメーターに基づいて、サイドリンクにおいて、第1の通信装置が送信するデータを受信するのに使用される。受信ユニットは、さらに、第1のDRXパラメーターに基づいて、第1の通信装置との間でデータ通信を実行するように構成される。

【0033】

第7の態様によれば、通信システムが提供され、その通信システムは、デバイストゥデバイスD2D通信シナリオに適用され、第4の態様にしたがった通信装置、第5の態様にしたがったネットワークデバイス、及び第6の態様にしたがった通信装置を含む。

【0034】

第8の態様によれば、通信装置が提供され、その通信装置は、デバイストゥデバイスD2D通信シナリオに適用され、メモリに結合されるプロセッサ、及び、コンピュータプログラム又は命令を格納するように構成されるメモリを含む。プロセッサは、メモリの中に格納されているコンピュータプログラム又は命令を実行するように構成され、それによって、その装置が、第1の態様及び第1の態様の複数の可能な設計のうちのいずれか1つにしたがった方法を実行することを可能とする。

【0035】

第9の態様によれば、通信装置が提供され、その通信装置は、デバイストゥデバイスD2D通信シナリオに適用され、メモリに結合されるプロセッサ、及び、コンピュータプログラム又は命令を格納するように構成されるメモリを含む。プロセッサは、メモリの中に格納されているコンピュータプログラム又は命令を実行するように構成され、それによって、その装置が、第2の態様及び第2の態様の複数の可能な設計のうちのいずれか1つにしたがった方法を実行することを可能とする。

【0036】

第10の態様によれば、通信装置が提供され、その通信装置は、デバイストゥデバイスD2D通信シナリオに適用され、メモリに結合されるプロセッサ、及び、コンピュータプログラム又は命令を格納するように構成されるメモリを含む。プロセッサは、メモリの中に格納されているコンピュータプログラム又は命令を実行するように構成され、それによって、その装置が、第3の態様及び第3の態様の複数の可能な設計のうちのいずれか1つにしたがった方法を実行することを可能とする。

【0037】

第11の態様によれば、通信システムが提供され、その通信システムは、第8の態様にしたがった通信装置、第9の態様にしたがったネットワークデバイス、及び第10の態様にしたがった通信装置を含む。

【0038】

第12の態様によれば、コンピュータ読み取り可能な記憶媒体が提供され、そのコンピュータ読み取り可能な記憶媒体は、プログラム又は命令を含む。プログラム又は命令がプロセッサによって実行されるときに、第1の態様及び第1の態様の複数の可能な設計のうちのいずれか1つにしたがった方法を実行する。

【0039】

第13の態様によれば、コンピュータ読み取り可能な記憶媒体が提供され、そのコンピュータ読み取り可能な記憶媒体は、プログラム又は命令を含む。プログラム又は命令がプロセッサによって実行されるときに、第2の態様及び第2の態様の複数の可能な設計のうちのいずれか1つにしたがった方法を実行する。

【0040】

第14の態様によれば、コンピュータ読み取り可能な記憶媒体が提供され、そのコンピュータ読み取り可能な記憶媒体は、プログラム又は命令を含む。プログラム又は命令がプロセッサによって実行されるときに、第3の態様及び第3の態様の複数の可能な設計のうちのいずれか1つにしたがった方法を実行する。

【0041】

第15の態様によれば、コンピュータプログラム製品が提供される。そのコンピュータプログラム製品がコンピュータによって実行されるときに、電子デバイスが、第1の態様及び第1の態様の複数の可能な設計のうちのいずれか1つにしたがった方法を実行することを可能とする。

【0042】

第16の態様によれば、コンピュータプログラム製品が提供される。そのコンピュータプログラム製品がコンピュータによって実行されるときに、電子デバイスが、第2の態様及び第2の態様の複数の可能な設計のうちのいずれか1つにしたがった方法を実行することを可能とする。

【0043】

第17の態様によれば、コンピュータプログラム製品が提供される。そのコンピュータプログラム製品がコンピュータによって実行されるときに、電子デバイスが、第3の態様及び第3の態様の複数の可能な設計のうちのいずれか1つにしたがった方法を実行することを可能とする。

【図面の簡単な説明】

【0044】

【図1】この出願のある1つの実施形態にしたがったDRXサイクルの概略的な図である。

【図2】この出願のある1つの実施形態にしたがったネットワークフレームワークの構成の概略的な図である。

【図3】この出願のある1つの実施形態にしたがったDRXパラメーター構成方法の概略的なフローチャートである。

【図4A】この出願のある1つの実施形態にしたがったDRXパラメーター構成方法の概略的なフローチャートである。

【図4B】この出願のある1つの実施形態にしたがったDRXパラメーター構成方法の概略的なフローチャートである。

【図5】この出願のある1つの実施形態にしたがったDRXパラメーター構成方法の概略的なフローチャートである。

【図6】この出願のある1つの実施形態にしたがったデータ伝送のための伝送リソース割当方法の概略的なフローチャートである。

【図7】この出願のある1つの実施形態にしたがったデータ伝送のための伝送リソース割当方法の概略的なフローチャートである。

【図8】この出願のある1つの実施形態にしたがったデータ伝送のための伝送リソース割当方法の概略的なフローチャートである。

【図9】この出願のある1つの実施形態にしたがった端末デバイスの構成の概略的な図である。

【図10】この出願のある1つの実施形態にしたがった端末デバイスの構成の概略的な図である。

【図11】この出願のある1つの実施形態にしたがった端末デバイスの構成の概略的な図である。

【図12】この出願のある1つの実施形態にしたがったネットワークデバイスの構成の概略的な図である。

【図13】この出願のある1つの実施形態にしたがったネットワークデバイスの構成の概略的な図である。

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

【0045】

理解を容易にするために、参考のために、この出願の複数の実施形態に関連する複数の概念のうちのいくつかの複数の例示的な説明を提供する。詳細は、以下のように説明される。

【0046】

D2Dとは、デバイストゥデバイスをいい、そのデバイストゥデバイスは、2つのピアトゥピアのユーザノードが互いの間で直接的に通信する通信方式であり、また、直接端末通信と称される。D2Dは、新たな技術であり、その技術は、システムの制御の下で、複数の端末デバイスが、セルリソースを共有することによって、互いの間で直接的に通信することを可能として、無線通信システムの中でのスペクトラムリソースの欠如の問題をある程度まで解決する。そのD2D技術は、モバイルセルラネットワークに適用されて、リソース利用及びネットワーク容量を改善することが可能である。各々のD2D通信リンクが占有するリソースは、ある1つのセルラ通信リンクが占有するリソースと等しい。

【0047】

サービス品質(quality of service, QoS)は、ネットワークセキュリティメカニズムであり、ネットワーク遅延及びネットワーク輻輳等の問題を解決するのに使用される技術である。従来の意味では、サービス品質は、伝送帯域幅、伝送遅延、及びデータパケット損失率等を含んでもよい。サービス品質の改善は、伝送帯域幅を保証し、伝送遅延を減少させ、データパケット損失率及び遅延ジッタを減少させること等である。広義の意味では、サービス品質は、ネットワークアプリケーションのすべての側面を含んでいる。ネットワークアプリケーションに有益である手段のすべては、サービス品質を改善することである。この意味では、ファイアウォール、ポリシーベースのルーティング、及び高速転送は、また、ネットワークサービス品質を改善するための手段である。

【0048】

サイドリンクは、サイドリンク、直接的な通信リンク、二次的なリンク、又は、エッジリンク等と称されてもよく、デバイストゥデバイスの直接的な通信をサポートするのに導入されるリンクである。サイドリンクは、D2Dシナリオ及び車両対あらゆる対象物(vehicle-to-everything, V2X)等に適用されてもよい。5G NRにおいては、サイドリンクは、主として、物理サイドリンク制御チャネル(physical sidelink control channel, PSCCH)、物理サイドリンク共有チャネル(physical sidelink shared channel, PSSCH)、物理サイドリンクブロードキャストチャネル(physical sidelink broadcast channel, PSBCH)、及び、物理サイドリンクフィードバックチャネル(physical sidelink feedback channel, PSFCH)等を含む。

【0049】

現時点では、サイドリンク通信は、動作モード1及び動作モード2の2つのリソース割り当てモードを有する。それらの2つの動作モードは、以下のようになる。

【0050】

動作モード1: 端末デバイスは、無線リソース制御(radio resource control, RRC)接続モードでデータを伝送する。伝送リソースは、例えば、基地局等のネットワークデバイスによって制御される。基地局は、サイドリンクの制御情報及びデータを伝送するのに使用される伝送リソースをスケジューリングする。端末デバイスは、基地局にサイドリンクスケジューリング要求(scheduling request, SR)及びサイドリンクバッファ状態報告(buffer status report, BSR)を送信する。サイドリンクBSRに基づいて、基地局は、端末デバイスのサイドリンク通信のためのデータの量を決定し、そして、伝送のためのリソースを推定してもよい。基地局は、構成されているサイドリンク無線ネットワーク一時識別子(sidelink-radio network temporary identifier, SL-RNTI)を使用して、サイドリンク通信のために使用される伝送リソースをスケジューリングしてもよい。

【0051】

動作モード2: 端末デバイスは、リソースプールからリソースを選択し、そして、伝送フォーマットを選択して、サイドリンクの制御情報及びデータ情報を送信する。リソースプールの選択を実行すると、選択されたリソースは、サイドリンク制御期間の全体にわたって有効になる。サイドリンク制御期間が終了した後に、UEは、再度、リソースプールの選択を実行してもよい。

【0052】

DRXの動作原理は、以下のようになる。図1に示されているように、DRXの基本的なメカニズムは、RRC接続モードになっているUEのためのDRXサイクル(cycle)を構成することである。DRXサイクルは、"継続期間にある"(on duration)及び"DRXのための機会"(opportunity for DRX)を含む。"on duration"の継続期間の中で、端末デバイスは、PDCCHをリッスンし、そして、PDCCHを受信してもよい。"opportunity for DRX"の継続期間の中で、UEは、PDCCHを受信しないことにより、電力消費を減少させる。言い換えると、on durationの継続期間の中では、端末デバイスは、活動時間の中にあり、opportunity for DRXの継続期間の中では、端末デバイスは、休眠状態になっている。

【0053】

on durationの値は、DRXサイクルの開始位置からPDCCHをリッスンする継続期間、すなわちパラメーターdrx-onDurationTimerに対応する継続期間を指定する。ほとんどの場合に、端末デバイスがPDCCH時(occasion)においてスケジューリングされ、そして、データを受信し又は送信した後に、端末デバイスは、後続のサブフレームにおいて継続的にスケジューリングされる可能性が高い。次のDRXサイクルにおいて、そのデータを受信し又は送信する必要がある場合に、追加の遅延を生じさせる。この遅延を減少させるために、スケジューリングされた後に、端末デバイスは、連続的に活動時間の中にあってもよい、すなわち、構成されている活動時間の中で継続してPDCCHをリッスンしてもよい。実装メカニズムは、以下のようになる。すなわち、端末デバイスが新たなデータを最初に伝送するようにスケジューリングされるたびごとに、タイマdrx-InactivityTimerを開始する(又は、再び開始する)。そのタイマの計時継続期間の中で、端末デバイスは、そのタイマが終了するまで、継続して活動時間の中にある。drx-InactivityTimerは、端末デバイスが、最初に伝送されるアップリンク(uplink, UL)又はダウンリンク(downlink, DL)ユーザデータを示すPDCCHの復号化に成功した後に、その端末デバイスが継続して活動時間の中にある継続期間を指定する。言い換えると、その端末デバイスが最初にデータを伝送するようにスケジューリングされているときに、一度、そのタイマを開始し又は再び開始する。

【0054】

ハイブリッド自動再送要求(hybrid automatic repeat request, HARQ)によるデータの再送信の場合には、前回の送信と再送信との間には一定のタイミング関係が存在しないため、アップリンクHARQ及びダウンリンクHARQのための時間ウィンドウを個別に定義し、HARQラウンドトリップ時間(round-trip time, RTT)タイマは、前回のアップリンク伝送又はダウンリンク伝送からの時間ウィンドウの後にのみ、端末デバイスが、アップリンク再送信又はダウンリンク再送信のリッスンを開始することを可能とする。各々のアップリンクHARQプロセス及び各々のダウンリンクHARQプロセスは、1つのHARQ RTTタイマに個別に対応する。drx-HARQ-RTT-TimerULが終了した後に、アップリンク伝送については、端末デバイスは、対応するHARQプロセスのためにDRXアップリンク再送信タイマ(drx-RetransmissionTimerUL)を開始する。ダウンリンク伝送については、drx-HARQ-RTT-TimerDLが終了した後に、対応するHARQプロセスにおけるデータの受信に成功していない場合に、端末デバイスは、HARQプロセスのためのDRXダウンリンク再送信タイマ(drx-RetransmissionTimerDL)を開始する。drx-RetransmissionTimerUL又はdrx-RetransmissionTimerDLが実行されるときに、端末デバイスは、HARQ再送信をスケジューリングするのに使用されるPDCCHをリッスンする。

【0055】

UEがDRXサイクルによって構成されているときに、端末デバイスが活動時間(active time)の中にある継続期間は、
(1) drx-onDurationTimer、drx-InactivityTimer、drx-RetransmissionTimerUL、drx-RetransmissionTimerDL、又は競合解決タイマra-ContentionResolutionTimerが実行されている継続期間等;
(2) 端末デバイスが、物理アップリンク制御チャネル(physical uplink control channel, PUCCH)においてSRを送信しており、SRが現時点で保留状態となっている継続期間; 及び
(3) 端末デバイスが、端末デバイスが選択していない競合ベースのランダムアクセスシーケンス(preamble)に応答するのに使用されるランダムアクセス応答(random access response, RAR)の受信に成功しているが、(セル無線ネットワーク一時識別子(Cell-Radio Network Temporary Identifier, C-RNTI)を使用することによって)最初の送信を示すPDCCHを受信していない継続期間;
を含む。

【0056】

この出願の複数の実施形態における複数の技術的解決方法は、ロングタームエボリューション(long term evolution, LTE)システム、マイクロ波アクセスのための世界的相互運用性(worldwide interoperability for microwave access, WiMAX)通信システム、新たな無線アクセス技術(new radio access technology, NR)システム等の第5世代(5th Generation, 5G)システム、複数のシステムを一体化するネットワーク、モノのインターネットシステム、車両のインターネットシステム、及び6Gシステム等の将来的な通信システム等のさまざまな通信システムに適用されてもよい。具体的には、この出願は、これらの通信システムのD2D通信シナリオに適用されてもよい。言い換えると、複数のデバイスは、サイドリンクを確立することによって、互いの間で直接的に通信することが可能である。

【0057】

加えて、この出願の複数の実施形態において、"例えば"の語は、例、図示、又は説明を与えることを表すのに使用される。この出願の中で"例"として説明されているいずれかの実施形態又は設計上の解決方法は、他の実施形態又は他の設計上の解決方法よりもより好ましく又はより大きな利点を有すると説明されるべきではない。具体的には、"例"の語は、特定の方式によって概念を提示するのに使用される。

【0058】

この出願の複数の実施形態において、"の(of)"、"対応する(corresponding, relevant)"、及び"対応する(対応する)"は、ときに、交換可能に使用されてもよい。差異が強調されないときには、それらの語が表現する意味は一貫しているということに留意するべきである。

【0059】

この出願の複数の実施形態において説明されているネットワークアーキテクチャ及びサービスシナリオは、この出願の複数の実施形態における技術的解決方法をより明確に説明することを意図しており、この出願の複数の実施形態によって提供される複数の技術的解決方法に対する限定を構成しない。当業者は、ネットワークアーキテクチャの進歩及び新たなサービスシナリオの出現に伴って、この出願の複数の実施形態によって提供されるそれらの複数の技術的解決方法が、また、同様の技術的課題に適用可能であるということを認識することが可能である。

【0060】

この出願の複数の実施形態において、ある1つの例として、無線通信ネットワークのNRネットワークシナリオを使用して、複数のシナリオのうちのいくつかを説明する。この出願の複数の実施形態における複数の解決方法は、さらに、他の無線通信ネットワークに適用されてもよく、対応する名称は、また、他の無線通信ネットワークの中の対応する機能の名称によって置き換えられてもよいということに留意するべきである。

【0061】

この出願の複数の実施形態におけるD2D通信シナリオにおいて、図2に示されているように、この出願におけるネットワークフレームワークは、少なくとも1つのネットワークデバイス及び少なくとも2つの通信装置を含んでもよい。

【0062】

この出願の複数の実施形態におけるネットワークデバイスは、無線トランシーバー機能を有するデバイスであってもよく、又は、そのデバイスの中に配置されてもよいチップであってもよく、無線アクセスネットワークの中に配置されて、端末デバイスのための無線通信サービスを提供してもよい。そのデバイスは、これらには限定されないが、進化型NodeB(evolved NodeB, eNB)、無線ネットワークコントローラ(radio network controller, RNC)、NodeB(NodeB, NB)、基地局コントローラ(base station controller, BSC)、基地トランシーバー局(base transceiver station, BTS)、(例えば、home evolved NodeB又はhome NodeB, HNB等の)ホームNodeB、ベースバンドユニット(baseband unit, BBU)、無線忠実度(wireless fidelity, Wi-Fi)システムの中のアクセスポイント(access point, AP)、無線中継ノード、無線バックホールノード、及び、送信点(transmission and reception point, TRP又はtransmission point, TP)等を含む。代替的に、ネットワークデバイスは、NRシステム等の5GシステムにおけるgNB又は送信点(TRP又はTP)であってもよく、5Gシステムにおける基地局の(複数のアンテナパネルを含む)アンテナパネル又はアンテナパネルのグループであってもよく、或いは、gNB又は送信点を構成するベースバンドユニット(BBU)又は分散ユニット(distributed unit, DU)等のネットワークノードであってもよい。代替的に、ネットワークデバイスは、車載型デバイス、ウェアラブルデバイス、又は、将来的な進化型PLMNネットワークにおけるネットワークデバイス等である。

【0063】

この出願の複数の実施形態における通信装置は、端末デバイス又は通信チップであってもよい。例えば、端末デバイスは、ユーザ機器(User Equipment, UE)、アクセス端末、加入者ユニット、加入者局、移動局、モバイルコンソール、リモート局、リモート端末、モバイルデバイス、ユーザ端末、端末、無線通信デバイス、ユーザエージェント、又はユーザ装置であってもよい。この出願の複数の実施形態における端末デバイスは、携帯電話(mobile phone)、タブレットコンピュータ(Pad)、無線トランシーバー機能を有するコンピュータ、仮想現実感(virtual reality, VR)端末デバイス、拡張現実感(augmented reality, AR)端末デバイス、産業用制御(industrial control)における無線端末、自動運転(self driving)における無線端末、遠隔医療(telemedicine)における無線端末、スマートグリッド(smart grid)における無線端末、輸送安全性(transportation safety)における無線端末、スマートシティ(smart city)における無線端末、スマートホーム(smart home)における無線端末、5Gネットワークの中の端末デバイス、又は、将来的な進化型公衆陸上モバイルネットワーク(public land mobile network, PLMN)の中の端末デバイス等であってもよい。適用シナリオは、この出願の複数の実施形態においては限定されない。この出願において、端末デバイスが実装する方法及びステップは、また、端末デバイスにおいて使用されてもよい(例えば、チップ又は回路等の)構成要素によって実装されてもよい。この出願において、上記の端末デバイス及び上記の端末デバイスの中に配置されてもよい構成要素は、集合的に、端末デバイスと称される。

【0064】

データ送信端におけるUE及びデータ受信端におけるUEは、同じ基地局のカバレッジ領域の中に存在してもよく又は複数の異なる基地局のカバレッジ領域の中に存在してもよいということに留意するべきである。

【0065】

この出願の適用シナリオ及びネットワークアーキテクチャについては、例えば、D2Dは、複数のローカル通信サービス、短距離通信、又は同じ部屋の中の通信に適用されてもよい。例えば、巡回コンサートのビデオサービスの場合に、視聴者は、無線D2Dを使用することによって、(例えば、携帯電話等の)端末デバイス側で、コンサートが提供する資料をダウンロードしてもよい。D2Dリソースのための(例えば、基地局等の)システムセルに適用することによって、コンサート主催者は、複数の端末デバイスにビデオ情報を直ちに伝送することが可能である。システムセル基地局を使用することによるビデオサービスの提供と比較して、D2D方式によるビデオサービスの提供は、セル基地局の負荷を減少させることが可能である。システムは、D2D通信を実行しながら、音声サービス及びインターネットデータサービスを提供することが可能である。現時点において、ビデオデータを受信する端末デバイスは、サイドリンクにおいて受信されるビデオデータを継続的にリッスンする。結果として、受信端における端末デバイスは、過度に電力を消費する。

【0066】

他の例では、端末デバイスは、携帯電話及びVRヘッドマウントディスプレイ等であってもよい。携帯電話とVRヘッドマウントディスプレイとの間にサイドリンク接続を確立した後に、携帯電話は、データ送信端末として機能してもよく、VRヘッドマウントディスプレイは、データ受信端として機能してもよい。携帯電話は、サイドリンクを介してVRヘッドマウント型ディスプレイにビデオデータを送信してもよく、VRヘッド型ディスプレイは、サイドリンクにおいて、受信するビデオデータを継続的にリッスンしてもよい。結果として、VRヘッドマウントディスプレイは、電力を過度に消費する。

【0067】

言い換えると、複数のデバイスの間の送信端及び受信端がサイドリンクを確立した後に、現時点で、受信端は、サイドリンクにおいて、受信するデータを継続的にリッスンする。結果として、受信側は、電力を過度に消費する。現時点で、基地局は、UEのために、Uuインターフェイスのために使用されるDRXパラメーターを構成してもよい。具体的には、基地局は、UEに構成情報を送信してもよく、構成情報は、基地局とUEとの間のUuインターフェイスデータ伝送のために使用されるDRXパラメーターを含む。しかしながら、D2Dシナリオにおいては、送信端ユーザ(transmit UE, Tx UE)及び受信端ユーザ(receive UE, Rx UE)は、データ伝送のために直接的に接続され、Rx UEは、Tx UEが位置している基地局のカバレッジ領域の中に存在しない場合がある。Rx UEに接続されている基地局及びTx UEに接続されている基地局が、同じ基地局ではない場合に、そのTx UEに接続されている基地局は、Rx UEのDRXパラメーターを知らない。D2Dシナリオにおいては、このことは、Tx UEがデータを送信するが、一方で、Rx UEがこの時点で活動時間の中にはない場合を生じさせる場合があり、その結果、データ送信の失敗につながる。したがって、この出願は、Tx UEがRx UEにデータを送信するときに、どのようにしてDRXパラメーターを構成するかを説明する。この問題のために、この出願は、DRXパラメーター構成方法を提供する。その方法の基本的な原理は、送信端が、受信端のためのDRXパラメーターを構成し、それによって、送信端がデータを伝送するときに、受信端は、そのDRXパラメーターに基づいて、受信端が活動時間の中にある継続期間を決定することが可能であり、受信端は、常時、活動時間の中にあって、データをリッスンする必要はない、ということであってもよい。このことは、受信端の電力消費を減少させることを可能とする。

【0068】

以下の記載は、この出願の複数の実施形態における複数の添付の図面を参照して、この出願の複数の実施形態における複数の技術的解決方法を説明する。この出願の複数の実施形態の説明の中で、"/"は、別途定める場合を除き、"又は"を意味する。例えば、A/Bは、A又はBを表してもよい。この明細書においては、"及び/又は"は、関連する対象を説明するための関連性関係を説明しているにすぎず、3つの関係が存在する場合があるということを表す。例えば、A及び/又はBは、Aのみが存在する場合、A及びBの双方が存在する場合、及び、Bのみが存在する場合の3つの場合を表してもよい。加えて、この出願の複数の実施形態の説明において、"複数の"は、2つ又はそれ以上を意味する。

【0069】

"第1の"及び"第2の"という語は、説明する目的を意図しているにすぎず、相対的重要度を示すか又は暗示し、或いは、表示されている技術的特徴の数を黙示的に示すものとして理解されるべきではない。したがって、"第1の"又は"第2の"によって限定される特徴は、1つ又は複数の特徴を明示的に又は暗示的に含んでもよい。それらの複数の実施形態の説明の中で、別途定める場合を除き、"複数の"は、2つ又はそれ以上を意味する。

【0070】

この出願の原理に基づいて、この出願のある1つの実施形態は、DRXパラメーター構成方法を提供する。図3に示されているように、その方法は、以下のステップを含む。

【0071】

301: 第1の通信装置は、第2の通信装置へのサイドリンク接続を確立する。

【0072】

この出願のこの実施形態において、データ送信端として機能する第1の通信装置が第1のUEであり、データ受信端として機能する第2の通信装置が第2のUEであり、第1のUEが位置しているセルの中の第1のネットワークデバイスが第1の基地局であり、第2のUEが位置しているセルの中の第2のネットワークデバイスが第2の基地局であるある1つの例を使用することによって説明を行う。

【0073】

例えば、第1のUEがデータ通信要件を有しているときに、その第1のUEは、第1の基地局にサイドリンク通信要求を送信し、第1の基地局は、その要求に基づいて、第1のUEのためにリソース割り当てモードを構成する。例えば、第1のUEの能力に基づいて、第1のUEがリソース割り当てをサポートしていないということを決定するときに、第1の基地局は、リソース割り当てモードが動作モード1であるということを決定するか、又は、第1のUEの能力に基づいて、第1のUEがリソース割り当てをサポートしているということを決定するときに、第1の基地局は、リソース割り当てモードが動作モード2であるということを決定する。第1の基地局は、第1のUEに、第2のUEへの接続を確立するのに使用されるサイドリンクリソースを割り当て、そして、その次に、第1のUEは、そのリソースを使用することによって、第2のUEに、PC5-S接続を確立することを要求するためのメッセージを送信して、第1のUEと第2のUEとの間のサイドリンク接続を完了する。

【0074】

例えば、第1のUEがデータ通信要件を有していることは、携帯電話がVRヘッドマウント型ディスプレイにビデオデータを送信することであってもよく、又は、第1のUEがデータ通信要件を有していることは、複数のユーザが、それぞれ、自身の携帯電話においてゲームをプレイするときに、ある1つのユーザの携帯電話が、複数の他のユーザの携帯電話にゲームデータを送信して、同じゲーム進行を維持することであってもよい。

【0075】

PC5-S接続は、D2Dシナリオにおける複数のUEの間の接続のためのインターフェイスである。

【0076】

302: 第1の通信装置は、第1のネットワークデバイスに補助情報及び第2の通信装置の識別子を送信する。補助情報は、第1のネットワークデバイスが、補助情報を参照して、第1のDRXパラメーターを決定するのに使用される。

【0077】

複数の実装のうちのいくつかにおいて、補助情報は、サイドリンクにおける第1の通信装置のデータ伝送要件を含む。

【0078】

代替的に、補助情報は、サイドリンクにおける第1の通信装置のデータ伝送要件に基づいて第1の通信装置が決定する第2のDRXパラメーターを含む。

【0079】

代替的に、補助情報は、サイドリンクにおける第1の通信装置のデータ伝送要件及びそのデータ伝送要件に基づいて第1の通信装置が決定する第2のDRXパラメーターを含む。

【0080】

データ伝送要件は、第1の通信装置が第2の通信装置にデータを送信する際に満たす必要がある条件であり、その条件は、遅延要件、データ伝送レート、及びパケット損失率等を含む。

【0081】

複数の実装のうちのいくつかにおいて、データ伝送要件は、サイドリンクにおいて第1の通信装置のサービスが要求するサービス品質(quality of service, QoS)であってもよい。

【0082】

第2のDRXパラメーターは、サイドリンクにおいて第1の通信装置が要求するQoSに基づいて第1の通信装置が決定すると理解されてもよい。

【0083】

例えば、第1のUEそれ自体が第2のUEにデータを送信する必要があるということをその第1のUEが知っているときに、第1のUEが第2のUEのために構成する第2のDRXパラメーターは、第1のUEがデータを送信する必要があるときに、第2のUEが活動時間の中にある、ということを満たす必要がある。加えて、第1のUEがサイドリンクにおいて第2のUEとの間で通信する必要があるサービスのQoS要件が、比較的高い場合に、第1のUEは、そのサービスの遅延要件が比較的高く、低遅延データ伝送を実行する必要があるということを考慮してもよい。したがって、第1のUEがこの比較的高いQoS要件に基づいて決定することが可能である第2のDRXパラメーターの特徴は、休眠期間の継続期間が比較的短くてもよく、且つ、活動時間の継続期間が比較的長くてもよい、という特徴であってもよい。このように、第1のUEが第2のUEとの間でサービス通信を実行するときに、第2のUEは、第1のUEが送信するデータを時間内に受信することが可能である。

【0084】

例えば、第1のUEがサイドリンクにおいて第2のUEとの間で通信する必要があるサービスが、例えば、遅延が4[ms]又は5[ms]に達する必要があるといったように、そのQoS要件が比較的高く、且つ、低遅延データ伝送を実行する必要がある場合に、第1のUEは、第2のDRXパラメーターに対応するDRXサイクルにおいて、休眠期間の継続期間の値、すなわち、DRXのための機会が、比較的小さく、且つ、活動時間の継続期間の値、すなわち、drx-onDurationTimerが比較的大きいということを決定してもよい。例えば、ある1つのDRXサイクルの継続期間は、10[ms]であり、DRXのための機会の値は、4[ms]であり、drx-onDurationTimerの値は、6[ms]である。このように、第1のUEがデータを送信する必要があるときに、第2のUEは、時間内に起動して、第1のUEが送信するデータを活動時間の中で受信し、その結果、低遅延要件を満たすことが可能である。

【0085】

代替的に、第1のUEがサイドリンクにおいて第2のUEとの間で通信する必要があるサービスが、例えば、データパケット損失率が5%よりも小さい必要があるといったように、そのQoS要件が比較的高い場合に、第1のUEは、第2のDRXパラメーターに対応するDRXサイクルにおいて、休眠期間の継続期間の値、すなわち、DRXのための機会が比較的小さく、且つ、活動時間の継続期間の値、すなわち、drx-onDurationTimerが比較的大きいということを決定してもよい。同様に、例えば、ある1つのDRXサイクルの継続期間は、10[ms]であり、DRXのための機会の値は、4[ms]であり、drx-onDurationTimerの値は、6[ms]である。ある1つのDRXサイクルにおいて、第2のUEが活動時間の中にある継続期間が、第2のUEが休眠期間の中にある継続期間よりもより長く、且つ、データが第2のUEに送信されるときに遅延が存在する場合があるということが想定される場合に、第2のUEが活動時間の中でデータを受信する確率を増加させ、それによって、データパケット損失率を減少させることが可能ある。

【0086】

DRXのための機会及びdrx-onDurationTimerは、具体的には、ステップ303において説明されている。複数の実装のうちのいくつかにおいて、第2の通信装置の識別子は、layer 2 IDであってもよい、すなわち、layer 2 IDは、第2の通信装置を識別するための一意の識別子として使用される。具体的には、layer 2 IDは、ネットワーク通信アーキテクチャにおける第2の通信装置の層2のIDであり、層2は、メディアアクセス制御(media access control, MAC)層、無線リンク制御プロトコル(radio link control, RLC)層、パケットデータ収束プロトコル(packet data convergence protocol, PDCP)層、及びサービスデータ適応プロトコル(service data adaptation protocol, SDAP)層を含む。各々の端末デバイスは、固有のlayer 2 IDを有する、すなわち、第1のネットワークデバイスは、layer 2 IDを使用することによって、第2の通信装置を識別することが可能である。

【0087】

複数の実装のうちのいくつかにおいて、第2の通信装置の識別子は、代替的に、グローバル一意識別子(Globally Unique Identifier, GUID)であってもよい。

【0088】

複数の実装のうちのいくつかにおいて、第1の通信装置は、第1のネットワークデバイスにRRCメッセージを送信してもよく、そのRRCメッセージは、補助情報及び第2の通信装置の識別子を含む。

【0089】

303: 第1のネットワークデバイスは、補助情報を参照して、第1のDRXパラメーターを決定する。

【0090】

第1のネットワークデバイスが、第1の通信装置が送信する補助情報及び第2の通信装置の識別子を受信した後に、第1のネットワークデバイスは、補助情報を参照して、第2の通信装置のための第1のDRXパラメーターを構成してもよい。

【0091】

複数の実装のうちのいくつかにおいて、第1のネットワークデバイスが補助情報を受信し、且つ、その補助情報に含まれるデータ伝送要件がQoSである場合に、第1のネットワークデバイスは、QoSに基づいて、第2の通信装置のための第1のDRXパラメーターを決定してもよい。決定する方式については、ステップ302において第1のUEが第2のDRXパラメーターを決定する実装を参照するべきである。

【0092】

第1のネットワークデバイスが受信する補助情報が、第1の通信装置が決定する第2のDRXパラメーターである場合に、第1のネットワークデバイスは、現時点で利用可能なリソースに基づいて、第1のDRXパラメーターとして第2のDRXパラメーターを使用するべきであるか否かを決定してもよい。例えば、比較的大きな数の現時点で利用可能なリソースが存在する場合、すなわち、第1のネットワークデバイスの負荷が比較的小さく、且つ、第1の通信装置に比較的大きな数のリソースを割り当ててもよい場合に、第2の通信装置が活動時間の中にある継続期間は比較的短くてもよい。比較的小さな数の現時点で利用可能なリソースが存在する場合、すなわち、第1のネットワークデバイスの負荷が比較的大きく、且つ、第1の通信装置に割り当ててもよいリソースの数が比較的小さい場合に、第2の通信装置については、例えば、第2の通信装置が活動時間の中にある時間が長くなり、それによって、第2の通信装置がデータを受信する確率が増加する可能性がある、といったように、第2の通信装置のDRXパラメーターの構成要件は、より高くなる。したがって、第2のDRXパラメーターが、第2の通信装置が活動時間の中にある継続期間が、現時点で利用可能なリソースと適合しているということ示す場合に、第1のネットワークデバイスは、第1のDRXパラメーターとして第2のDRXパラメーターを使用してもよい。それ以外の場合、すなわち、第2のDRXパラメーターが、第2の通信装置が活動時間の中にある継続期間が現時点で利用可能なリソースに適合していないということを示す場合には、第1のネットワークデバイスは、修正されている第2のDRXパラメーターが第1のネットワークデバイスの現在のリソーススケジューリングに適合するように、第2のDRXパラメーターを適応的に修正してもよい。

【0093】

例えば、第1の基地局の現在の負荷が比較的小さいとき、すなわち、例えば、第1の基地局が第2のUEのための第1のDRXパラメーターを構成するときに、1つのDRXサイクルが10[ms]であるといったように、第1のUEのための比較的大きな数の利用可能な時間周波数リソースが存在するときに、その利用可能な時間周波数リソースに対応する継続期間が、1つのDRXサイクルの継続期間よりも長い場合には、第2のUEが活動時間の中にある継続期間は、例えば、4[ms]であるといったように、比較的短くてもよく、第2のUEが休眠期間の中にある継続期間は、例えば、6[ms]であるといったように、比較的長くてもよい。このことの理由は、この場合には、第1の基地局のリソースのすべてをこのDRXサイクルの中で使用してもよく、第2のUEが活動時間の中にある継続期間において、第1のUEは、データを伝送するのに選択可能なリソースを有するからということであり、第2のUEが休眠期間の中にある間に、第1のUEがデータを送信するような状況を生じさせることはない。一方で、第2のUEが活動時間の中にある継続期間が比較的長い場合には、第1のUEが第2のUEに継続的にデータを送信しない可能性が極めて高くなる。したがって、第2のUEは、比較的長い時間の間、活動時間の中にある必要はない。したがって、第1の基地局が、現時点で、第1のUEに割り当てることが可能である比較的大きな数のリソースを有しているときに、第2のUEがDRXサイクルにおいて活動時間の中にある継続期間は、比較的短くてもよい。

【0094】

したがって、第2のDRXパラメーターが、第2の通信装置が活動時間の中にある継続期間が、現時点で利用可能なリソースに適合するということを示すことは、第1の基地局が比較的大きな数の現時点で利用可能なリソースを有し、例えば、活動時間の継続期間が4[ms]であり、休眠期間の継続期間が6[ms]であるといったように、第2のDRXパラメーターのうちで、第2のUEが活動時間の中にある継続期間が比較的短く、第2のUEが休眠期間の中にある継続期間が比較的長いということであると理解されてもよい。第2のDRXパラメーターが、第2の通信装置が活動時間の中にある継続期間が、現時点で利用可能なリソースと適合していないということを示すことは、第1の基地局が比較的大きな数の現時点で利用可能なリソースを有し、例えば、活動時間の継続期間が6[ms]であり、休眠期間の継続期間が4[ms]であるといったように、第2のDRXパラメーターのうちで、第2のUEが活動時間の中にある継続期間が比較的長く、第2のUEが休眠期間の中にある継続期間が比較的短いということであると理解されてもよい。この場合には、第1の基地局は、第2のDRXパラメーターのうちで、活動時間の継続期間及び休眠期間の継続期間を修正してもよい。例えば、修正の後、活動時間の継続期間は、4[ms]となり、休眠期間の継続期間は、6[ms]となる。

【0095】

第1の基地局の現時点での負荷が比較的大きいとき、すなわち、例えば、基地局が第2のUEのために第1のDRXパラメーターを構成するときに、1つのDRXサイクルが10[ms]であるといったように、第1のUEのための比較的小さな数の利用可能な時間周波数リソースが存在するときに、それらの利用可能な時間周波数リソースに対応する継続期間が1つのDRXサイクルの継続期間より短い場合には、第2のUEが活動時間の中にある継続期間は、例えば、6[ms]であるといったように、比較的長くてもよく、第2のUEが休眠期間の中にある継続期間は、例えば、4[ms]であるといったように、比較的短くてもよい。このことの理由は、比較的小さな数の現時点で利用可能なリソースが存在するときに、1つのDRXサイクルにおいて、第2のUEがデータを受信するのに使用することが可能である継続期間は、比較的短くなるからということである。第1のUEがデータを送信し、一方で、第2のUEがデータを受信しないという状況を回避するためには、第2のUEが活動時間の中にある継続期間をより長くする必要があり、それによって、第2のUEは、比較的小さな数のリソースによってデータを受信することが可能である。したがって、第1の基地局が、現時点で、第1のUEに割り当てることが可能である比較的少ない数のリソースを有するときに、第2のUEがそのDRXサイクルの中で活動時間の中にある時間を比較的長くすることが可能である。

【0096】

したがって、第2のDRXパラメーターが、第2の通信装置が活動時間の中にある継続期間が、現時点で利用可能なリソースと適合しているということを示すことは、第1の基地局が比較的小さな数の現時点で利用可能なリソースを有し、第2のDRXパラメーターの中で、例えば、活動時間の継続期間が6[ms]であり、休眠期間の継続期間が4[ms]であるといったように、第2のUEが活動時間の中にある継続期間が比較的長く、第2のUEが休眠期間の中にある継続期間が比較的短いことであると理解されてもよい。第2のDRXパラメーターは、第2の通信装置が活動時間の中にある継続期間が、現時点で利用可能なリソースと適合していないということを示すことは、第1の基地局が比較的小さな数の現時点で利用可能なリソースを有し、第2のDRXパラメーターの中で、例えば、活動時間の継続期間が4[ms]であり、休眠期間の継続期間が6[ms]であるといったように、第2のUEが活動時間の中にある継続期間が比較的短く、第2のUEが休眠期間の中にある継続期間が比較的長いことであると理解されてもよい。この場合には、第1の基地局は、第2のDRXパラメーターの中で、活動時間の継続期間及び休眠期間の継続期間を修正してもよい。例えば、修正の後、活動時間の継続期間は、6[ms]となり、休眠期間の継続期間は、4[ms]となる。

【0097】

第1のネットワークデバイスが受信する補助情報が、QoS及び第2のDRXパラメーターを含む場合に、第1のネットワークデバイスは、QoSに基づいて第2のDRXパラメーターを修正して、第1のDRXパラメーターを取得してもよい。具体的には、QoSに基づいて第2のDRXパラメーターを修正することによって得られる第1のDRXパラメーターの特徴は、第1のUEがステップ302において第2のDRXパラメーターを決定する実装と同様であってもよい。

【0098】

例えば、第1のUEがサイドリンクにおいて第2のUEとの間で通信する必要があるサービスが、比較的高いQoS要件を有する場合に、第1の基地局は、そのサービスが比較的高い遅延要件を有し、低遅延データ送信を実行する必要があるということを考慮してもよい。したがって、第2のDRXパラメーターの特徴は、休眠期間の継続期間が比較的長くてもよく、活動時間が比較的短くてもよい、ということである。例えば、1つのDRXサイクルの継続期間は、10[ms]であり、DRXのための機会の値は、6[ms]であり、drx-onDurationTimerの値は、4[ms]である。このことに基づいて、第1の基地局は、第2のDRXパラメーターを修正して、第1のDRXパラメーターを取得してもよい。得られる第1のDRXパラメーターの特徴は、休眠期間の継続期間が比較的短くてもよく、活動時間の継続期間が比較的長くてもよい、ということであってもよい。例えば、第1のDRXパラメーターの中で、DRXのための機会の値は、4[ms]であり、drx-onDurationTimerの値は、6[ms]でである。このように、第1のUEが第2のUEとの間でサービス通信を実行するときに、第2のUEは、第1のUEが送信するデータを時間内に受信することが可能である。具体的な理由については、ステップ302の説明を参照するべきである。

【0099】

複数の実装のうちのいくつかにおいて、例えば、第1の通信装置(第1のUE)は、Tx UEであり、第2の通信装置(第2のUE)は、Rx UEである。第1のDRXパラメーターに含まれる具体的なパラメーター及び関数は、以下のパラメーターであってもよい。

【0100】

drx-onDurationTimerは、DRXサイクルの中の活動時間の継続期間を示す。

【0101】

DRXのための機会は、DRXサイクルの中の休眠期間を示す。

【0102】

drx-SlotOffsetは、drx-onDurationTimerを開始する前の遅延を示す。

【0103】

drx-InactivityTimerは、Rx UEが最初の送信のために新たなデータをスケジューリングするPSCCHの復号化に成功した後に、Rx UEが継続して活動時間の中にある継続期間を示す、すなわち、このパラメーターは、最初に送信されたデータに対して有効である。UEが、オンになっている継続期間の間にPSCCHスケジューリング情報を受信するときに、そのUEは、drx-InactivityTimerを開始する。UEがdrx-InactivityTimerの実行の際に他のPSCCHスケジューリング情報を受信するときに、UEは、継続的してdrx-InactivityTimerを再起動する。

【0104】

drx-RetransmissionTimerTtoRは、Rx UEが、Tx UEが送信する再送データを受信する前に、Rx UEが待機する必要がある継続期間を示す。このパラメーターの開始条件は、drx-HARQ-RTT-TimerTtoRが終了し、受信に成功していないデータが存在するということである。

【0105】

drx-RetransmissionTimerRtoTは、Tx UEが、Rx UEが送信する確認応答(Acknowledgment, ACK)メッセージ/(Negative-Acknowledgment, NACK)メッセージフィードバックデータを受信する前に、Tx UEが待機する必要がある継続期間を示す。このパラメーターの開始条件は、drx-HARQ-RTT-TimerRtoTが終了し、受信に成功していないデータが存在するということである。drx-LongCycleStartOffsetは、Long DRX Cycle及びdrx-StartOffsetの双方を示し、Long DRX Cycleは、長いDRXサイクルを示し、drx-StartOffsetは、長いDRXサイクルの開始サブフレーム及び短いDRXサイクルの開始サブフレームを指定する。

【0106】

drx-ShortCycleは、Short DRX Cycle、すなわち、短いDRXサイクルを示す。

【0107】

drx-ShortCycleTimerは、Rx UEがしたがうShort DRX cycleの継続期間を示す。

【0108】

drx-HARQ-RTT-TimerTtoRは、Rx UEのMACエンティティが、Tx UEからのHARQ再送信のために割り当てられるサイドリンクリソースを受信すると予想される前の継続期間を示す。具体的にいうと、前の送信からこのパラメーターの時間ウィンドウの継続期間の後に、Rx UEは、(再送信されるデータに対する制限に相当して、Tx UEが不定期に再送信されるデータを継続的に送信することを防止するための)再送信されるデータに対するリッスンを開始する。drx-HARQ-RTT-Timerが終了した後に、Tx UEは、再送信を開始してもよい。この場合には、drx-RetransmissionTimerTtoRを開始し、Rx UEは、drx-RetransmissionTimerTtoRの実行の際にデータを受信する。

【0109】

drx-HARQ-RTT-TimerRtoTは、Tx UEのMACエンティティが、Rx UEが送信するフィードバックデータを受信すると予想される前の継続期間を示す。具体的にいうと、前のACK/NACKフィードバック送信からこのパラメーターの時間ウィンドウの継続期間の後に、Rx UEは、(ACK/NACKフィードバックに対する制限に相当して、Rx UEがフィードバックデータを継続的に送信することを防止するための)ACK/NACKフィードバックデータの送信を開始する。drx-HARQ-RTT-TimerRtoTが終了した後に、Rx UEは、フィードバックを開始してもよい。この場合には、drx-RetransmissionTimerRtoTを開始し、Rx UEは、drx-RetransmissionTimerRtoTの実行の際に、フィードバックデータを送信する。

【0110】

第1のDRXパラメーターの中に含まれるパラメーターのある1つの例では、QoSに基づいて決定されてもよい第1のDRXパラメーターは、第1のDRXパラメーターの中に含まれるパラメーターのうちの少なくとも1つを含んでもよい。

【0111】

304: 第1のネットワークデバイスは、第1の通信装置に第2の通信装置の識別子及び第1のDRXパラメーターを送信する。

【0112】

複数の実装のうちのいくつかにおいて、第1のネットワークデバイスは、第1の通信装置に第1の構成メッセージを送信してもよい。第1の構成メッセージは、第2の通信装置の識別子及び第1のDRXパラメーターを含む。

【0113】

複数の実装のうちのいくつかにおいて、第1の構成メッセージは、RRCメッセージであってもよい。

【0114】

305: 第1の通信装置は、第1のDRXパラメーターを格納し、そして、第1のDRXパラメーターと第2の通信装置の識別子との間の対応関係を確立する。

【0115】

例えば、第1のUEは、データを受信する複数のUEとの間で通信してもよい。したがって、第2のUEの第1のDRXパラメーターを受信するときに、第1のUEは、第1のDRXパラメーターと第2のUEの識別子との間の対応関係を確立してもよく、それによって、第1のUEと第2のUEとの間でデータ通信を実行するときに、第2のUEの第1のDRXパラメーターは、その対応関係に基づいて決定されてもよい。

【0116】

306: 第1の通信装置は、第2の通信装置に第1のDRXパラメーターを送信する。

【0117】

複数の実装のうちのいくつかにおいて、第1の通信装置は、第2の通信装置に第2の構成メッセージを送信してもよく、第2の構成メッセージは、第1のDRXパラメーターを含んでもよい。

【0118】

複数の実装のうちのいくつかにおいて、第2の構成メッセージは、RRCメッセージであってもよい。

【0119】

例えば、第1のUEは、第1のUEと第2のUEの間に確立されているサイドリンクにおいて、第2のUEにRRCメッセージを送信してもよい。

【0120】

307: 第2の通信装置は、第1の通信装置に第1の通知メッセージを送信する。第1の通知メッセージは、第1のDRXパラメーターの構成が完了しているということを示す。

【0121】

複数の実装のうちのいくつかにおいて、第1の通知メッセージは、RRCメッセージであってもよい。

【0122】

308: 第1の通信装置は、第1のネットワークデバイスに第2の通知メッセージを送信する。第2の通知メッセージは、第1のDRXパラメーターの構成が完了しているということを示す。

【0123】

複数の実装のうちのいくつかにおいて、第2の通知メッセージは、RRCメッセージであってもよい。

【0124】

309: 第1のネットワークデバイスは、第1のDRXパラメーターに基づいて、データスケジューリングを実行する。

【0125】

例えば、動作モード1において、第1の基地局は、第1のDRXパラメーターに基づいて、データスケジューリングを実行してもよい。具体的には、第1の基地局は、複数の第2のUEに対応する第1のDRXパラメーターを格納してもよい。第1のUEが1つの第2のUEにデータを送信するときに、第1のUEは、第1の基地局にスケジューリング要求を送信してもよく、第1の基地局は、そのスケジューリング要求に基づいて、第1のUEとの間で通信する第2のUEを決定してもよい。具体的にどのようにして第2のUEを決定するかは、後のステップ602において説明される。このように、第1の基地局は、第2のUEに対応するとともに、第1の基地局が格納する第1のDRXパラメーターに基づいて、第1のUEのためにリソースを構成してもよく、それによって、第1のUEは、その構成されているリソースによって第2のUEにデータを送信する。

【0126】

代替的に、ステップ309は、第1の通信装置が、第1のDRXパラメーターに基づいて、データスケジューリングを実行するステップによって置き換えられてもよい。

【0127】

すなわち、動作モード2において、第1の通信装置は、第1のDRXパラメーターに基づいて、データスケジューリングを実行する。言い換えると、第1の通信装置は、リソースプールからリソースを選択し、第2の通信装置にサイドリンクの制御情報及びデータ情報を送信する。

【0128】

したがって、この出願のこの実施形態において、第1の通信装置は、第1のネットワークデバイスに補助情報を送信してもよい。第1のネットワークデバイスは、その補助情報に基づいて、第2の通信装置に対応するDRXパラメーターを決定し、第1の通信装置にそのDRXパラメーターを送信する。第1の通信装置は、そのDRXパラメーターを格納し、第2の通信装置にそのDRXパラメーターを送信してもよく、それによって、受信するべきデータが存在するということを決定するときに、第2の通信装置は、その構成されているDRXパラメーターに基づいて、第2の通信装置が活動時間の中にある継続期間及び第2の通信装置が休眠期間(非活動時間)の中にある継続期間を決定してもよい。このように、第2の通信装置及び第1の通信装置が、同じネットワークデバイスのカバレッジ領域の中には存在しない場合には、D2Dシナリオにおいては、第1のネットワークデバイス及び第1の通信装置が第2の通信装置のために構成するDRXパラメーターは、一致し、第1の通信装置は、そのDRXパラメーターに基づいて、第2の通信装置にデータを送信してもよい。加えて、データ受信端として機能する第2の通信装置は、常時、データリスニング状態となっている必要はなく、それによって、第2の通信装置の電力消費を減少させることが可能であり、第2の通信装置の電力を節約する。

【0129】

この出願のある1つの実施形態は、さらに、DRXパラメーター構成方法を提供する。図4A及び図4Bに示されているように、その方法は、以下のステップを含む。

【0130】

401: 第1の通信装置は、第2の通信装置へのサイドリンク接続を確立する。

【0131】

このステップの実装については、ステップ301を参照するべきである。

【0132】

402: 第1のネットワークデバイスが、第1の通信装置が第2の通信装置へのサイドリンク接続を確立しているということを決定するときに、第1のネットワークデバイスは、第2のネットワークデバイスに要求メッセージを送信する。要求メッセージは、第3のDRXパラメーターを取得することを要求するのに使用され、第3のDRXパラメーターは、第2のネットワークデバイスが第2の通信装置のために構成するUuインターフェイスのDRXパラメーターである。

【0133】

Uuインターフェイスは、ネットワークデバイスと通信装置との間の5Gの通信のためのインターフェイスである。

【0134】

複数の実装のうちのいくつかにおいて、第1の通信装置は、第1のネットワークデバイスのカバレッジ領域の中に存在し、第2の通信装置は、第2のネットワークデバイスのカバレッジ領域の中に存在する。例えば、Uuインターフェイスは、基地局とUEとの間の通信のためのインターフェイスであると理解されてもよい。UEが基地局との間のRRC接続を確立するときに、基地局は、複数の異なるUEのために、基地局とそれらの複数のUEとの間の通信のためのUuインターフェイスのDRXパラメーターを構成してもよい。この実施形態において、第2の基地局が第2のUEのために構成するDRXパラメーターは、第3のDRXパラメーターとして示される。

【0135】

403: 第2のネットワークデバイスは、第1のネットワークデバイスに応答メッセージを送信する。その応答メッセージは、第2のネットワークデバイスが第2の通信装置のために構成するUuインターフェイスのDRXパラメーターを含む。

【0136】

第2の通信装置が、また、第1のネットワークデバイスのカバレッジ領域の中に存在する場合には、第1のネットワークデバイスは、第2の通信装置のUuインターフェイスの第3のDRXパラメーターを知っており、ステップ402及びステップ403は実行されないということに留意するべきである。第1のネットワークデバイスは、第1のネットワークデバイスと第2の通信装置との間のUuインターフェイスの第3のDRXパラメーターを参照して、第1のDRXパラメーターを決定してもよい。具体的な実装は、ステップ404における第1のDRXパラメーターを決定する実装と同様であってもよい。

【0137】

404: 第1のネットワークデバイスは、第3のDRXパラメーターを参照して、第1のDRXパラメーターを決定する。第1のDRXパラメーターは、第1の通信装置が第1のDRXパラメーターに基づいてサイドリンクにおいて第2の通信装置にデータを送信するのに使用される。

【0138】

複数の実装のうちのいくつかにおいて、第1のネットワークデバイスが、第3のDRXパラメーターを参照して第1のDRXパラメーターを決定することは、第1のネットワークデバイスが、第1の通信装置と第2の通信装置との間の(例えば、PC5インターフェイスを使用することによる通信等の)D2D通信のために使用される第1のDRXパラメーターを決定するときに、第1のネットワークデバイスが、第3のDRXパラメーターを参照して、第1のDRXパラメーターを取得する、ことであると理解されてもよい。第3のDRXパラメーターは、第2のネットワークデバイスと第2の通信装置との間のUuインターフェイスのDRXパラメーターである。また、第1のネットワークデバイスが第1のDRXパラメーターを構成するときに、第1のDRXパラメーターは、Uuインターフェイスにおける第2の通信装置の第3のDRXパラメーターと整合されてもよいということを理解することが可能である。

【0139】

複数の実装のうちのいくつかにおいて、パラメーターの整合は、第1のDRXパラメーター及び第3のDRXパラメーターが、すべて又は部分的に整合されることであってもよい。

【0140】

複数の実装のうちのいくつかにおいて、パラメーターの整合は、第1のDRXパラメーターのうちで、第2の通信装置が活動時間の中にあるということを示すパラメーターが、第3のDRXパラメーターのうちで、第2の通信装置が活動時間の中にあるということを示すパラメーターと同じであるか又は部分的に同じパラメーターであると理解されてもよい。

【0141】

活動時間におけるパラメーターは、
実行されているdrx-onDurationTimer、drx-InactivityTimer、drx-RetransmissionTimerTtoR、drx-RetransmissionTimerRtoT、又はra-ContentionResolutionTimer等、を含んでもよい。

【0142】

複数の実装のうちのいくつかにおいて、図1を参照するべきである。DRXサイクルは、活動時間及び休眠期間を含む。第1のDRXパラメーターが、第3のDRXパラメーターを参照して構成されるときに、第2の通信装置がPC5インターフェイスによって活動時間の中にある継続期間は、第2の通信装置がUuインターフェイスによって活動時間の中にある継続期間と同じであってもよく又は部分的に同じであってもよく、第2の通信装置がPC5インターフェイスによって休眠期間の中にある継続期間は、第2の通信装置がUuインターフェイスによって休眠期間の中にある継続期間と同じであってもよく又は部分的に同じであってもよい。

【0143】

複数の実装のうちのいくつかにおいて、第2の通信装置の状態は、さらに、各々のパラメーターの継続期間によってさらに影響され、各々のパラメーターは、活動時間における上記のパラメーターであってもよい。したがって、パラメーターの整合は、PC5インターフェイスにおける第2の通信装置の第1のDRXパラメーターのうちの複数のパラメーターの継続期間が、Uuインターフェイスにおける第2の通信装置の第3のDRXパラメーターのうちの複数のパラメーターの継続期間と一致することをさらに含んでもよい。

【0144】

405: 第1のネットワークデバイスは、第1の通信装置に第1の構成メッセージを送信する。第1の構成メッセージは、第2の通信装置の識別子及び第1のDRXパラメーターを含む。

【0145】

複数の実装のうちのいくつかにおいて、第1の構成メッセージは、RRCメッセージであってもよい。

【0146】

406: 第1の通信装置は、第1のDRXパラメーターを格納し、第1のDRXパラメーターと第2の通信装置の識別子との間の対応関係を確立する。

【0147】

ステップ406乃至410の実装については、ステップ305乃至309を参照するべきである。

【0148】

407: 第1の通信装置は、第2の通信装置に第1のDRXパラメーターを送信する。

【0149】

408: 第2の通信装置は、第1の通信装置に第1の通知メッセージを送信する。第1の通知メッセージは、第1のDRXパラメーターの構成が完了しているということを示す。

【0150】

409: 第1の通信装置は、第1のネットワークデバイスに第2の通知メッセージを送信する。その第2の通知メッセージは、第1のDRXパラメーターの構成が完了しているということを示す。

【0151】

410: 第1のネットワークデバイスは、第1のDRXパラメーターに基づいて、データスケジューリングを実行する。

【0152】

したがって、この出願のこの実施形態において、第1の通信装置及び第2の通信装置が、同じネットワークデバイスのカバレッジ領域の中には存在しない場合、すなわち、第1の通信装置が第1のネットワークデバイスのカバレッジ領域の中に存在し、且つ、第2の通信装置が第2のネットワークデバイスのカバレッジ領域の中に存在する場合に、第1のネットワークデバイスは、第2のネットワークデバイスに、第2のネットワークデバイスが第2の通信装置のために構成するUuインターフェイスの第3のDRXパラメーターを要求してもよく、第1のネットワークデバイスは、第3のDRXパラメーターを参照して、第2の通信装置のためにPC5インターフェイスの第1のDRXパラメーターを構成する。代替的に、第1の通信装置及び第2の通信装置が、同じネットワークデバイスのカバレッジ領域の中に存在する場合、すなわち、第1の通信装置及び第2の通信装置の双方が、第1のネットワークデバイスのカバレッジ領域の中に存在する場合には、第1のネットワークデバイスは、第1のネットワークデバイスが第2の通信装置のために構成するUuインターフェイスの第3のDRXパラメーターを参照して、第2の通信装置のためにPC5インターフェイスの第1のDRXパラメーターを構成してもよい。このように、2つのインターフェイスにおいて、第2の通信装置が活動時間の中にある継続期間及び第2の通信装置が休眠期間の中にある継続期間は、可能な限り一貫している。このように、送信するべきデータが存在するときに、第2の通信装置は、第3のDRXパラメーターに基づいて電力を節約する。加えて、第2の通信装置のPC5インターフェイスの第3のDRXパラメーターは、第2の通信装置のUuインターフェイスの第1のDRXパラメーターと整合されているため、さらに、第2の通信装置の電力を節約することが可能である。

【0153】

この出願のある1つの実施形態は、さらに、DRXパラメーター構成方法を提供する。図5に示されているように、その方法は、以下のステップを含む。

【0154】

501: 第1の通信装置は、第2の通信装置へのサイドリンク接続を確立する。

【0155】

502: 第1の通信装置は、D2Dサイドリンクにおける第1の通信装置のデータ伝送要件に基づいて、第2の通信装置のために構成される第1のDRXパラメーターを決定する。

【0156】

複数の実装のうちのいくつかにおいて、データ伝送要件は、サイドリンクにおいて第1の通信装置のサービスが要求するQoSであってもよい。言い換えると、第1のDRXパラメーターは、サイドリンクにおいて第1の通信装置が要求するQoSに基づいて、第1の通信装置が決定すると理解されてもよい。

【0157】

ステップ502の具体的な実装については、ステップ302における第1のUEによる第2のDRXパラメーターの決定の実装を参照するべきである。

【0158】

503: 第1の通信装置は、第1のネットワークデバイスに第2の通信装置の識別子及び第1のDRXパラメーターを送信する。

【0159】

複数の実施形態のうちのいくつかにおいて、サイドリンクのリソース割り当てモードが動作モード1であるときに、第1のネットワークデバイスは、第1のDRXパラメーターに基づいて、第1の通信装置のためのリソースをスケジューリングしてもよく、それによって、第1の通信装置は、割り当てられるリソースによって第2の通信装置との間で通信する。

【0160】

504: 第1の通信装置は、第2の通信装置に第1のDRXパラメーターを送信する。

【0161】

第1の通信装置は、さらに、第1のDRXパラメーターと第2の通信装置の識別子との間の対応関係を確立してもよい。

【0162】

ステップ504乃至ステップ507の実装については、ステップ306乃至ステップ309を参照するべきである。

【0163】

505: 第2の通信装置は、第1の通信装置に第1の通知メッセージを送信する。第1の通知メッセージは、第1のDRXパラメーターの構成が完了しているということを示す。

【0164】

506: 第1の通信装置は、第1のネットワークデバイスに第2の通知メッセージを送信する。第2の通知メッセージは、第1のDRXパラメーターの構成が完了しているということを示す。

【0165】

507: 第1のネットワークデバイスは、第1のDRXパラメーターに基づいて、データスケジューリングを実行する。

【0166】

したがって、この出願のこの実施形態において、第1の通信装置は、サービスのデータ伝送要件に基づいて、第2の通信装置のために構成される第1のDRXパラメーターを決定してもよく、それによって、第2の通信装置は、第1のDRXパラメーターに基づいて、電力を節約することが可能である。

【0167】

この出願の図3、図4A、図4B、及び図5に対応する複数の実施形態のすべては、サイドリンク通信の2つのリソース割り当てモード、すなわち、動作モード1及び動作モード2に適用可能であるということに留意するべきである。

【0168】

以下の実施形態においては、第1のDRXパラメーターが第2の通信装置のために構成された後に、第1の通信装置がデータ伝送要件を有する場合に、第1の通信装置と第2の通信装置との間でのデータ伝送のための伝送リソースをどのようにして割り当てるかを説明する。

【0169】

動作モード1の場合、すなわち、伝送リソースが基地局等のネットワークデバイスによって割り当てられるときは、図6を参照するべきである。ステップ309、ステップ410、又はステップ507の具体的な実装は、以下のステップを含んでもよい。

【0170】

601: 第1の通信装置が、サイドリンクにおいて送信されるべきデータが存在するということを決定するときに、第1の通信装置は、第1のネットワークデバイスにSRを送信する。そのSRは、サイドリンクにおける第1の通信装置の通信要件を示すのに使用される。

【0171】

例えば、第1のUEは、データを受信することが可能である複数の第2のUEとの間で同時にD2D通信を実行してもよい。したがって、第1のUEがサイドリンクにおいてデータを送信する必要があるときに、第1のUEは、第1の基地局にSRを送信する。SRは、この場合に第1のUEがデータを送信する必要があるということを第1の基地局に示すのに使用され、第1の基地局に、サイドリンクにおいて第1のUEによってD2D通信を実行するためのリソースを要求するのに使用される。第1のUEが複数の第2のUEへのサイドリンクを確立するときに、第1のUEは、各々の第2のUEのために第1の基地局に1つのSRを送信してもよい、すなわち、第1のUEは、第1の基地局に複数のSRを送信してもよい。

【0172】

例えば、第1のUEがサイドリンクにおいてデータを送信する必要があることは、携帯電話がVRヘッドマウントディスプレイにビデオデータを送信するが、携帯電話がビデオデータを送信するためのリソースを取得していないことであってもよい。

【0173】

602: 第1のネットワークデバイスは、第1の通信装置にダウンリンク制御情報(downlink control information, DCI)を送信する。そのDCIは、第1のネットワークデバイスがSRに基づいて決定する第3の通信装置の識別子、及び、サイドリンクにおいて利用可能であり、第1の通信装置に割り当てられ、そして、第3の通信装置に対応する第1のDRXパラメーターに基づいて決定されるリソースに関する情報を含む。

【0174】

複数の実装のうちのいくつかにおいて、第1の通信装置は、複数の第2の通信装置へのサイドリンクを同時に確立してもよいので、第1のネットワークデバイスは、第1の通信装置が送信する複数のSRに基づいて、各々のSRに対応する第2の通信装置を決定してもよい。言い換えると、第1の通信装置は、受信したSRに基づいて、第1の通信装置に接続される複数の第2の通信装置のうちで第3の通信装置を決定し、そして、その第3の通信装置に対応する第1のDRXパラメーターに基づいて、第1の通信装置及び第3の通信装置に割り当てられるリソースに関する情報を決定してもよい。このように、第3の通信装置が活動時間の中にあるときに、第1の通信装置は、そのリソースに関する情報が示す時間領域リソースによってデータを送信することが可能であり、第3の通信装置は、そのリソースに関する情報が示すリソースによってデータを受信する。

【0175】

例えば、基地局は、カバレッジ領域の中の各々のUEに、SRを送信するのに使用することが可能であるリソースを割り当てる。したがって、第1のUEが第1の基地局にSRを送信し、且つ、第1の基地局が現時点のリソースによってSRを受信するときに、第1の基地局は、SRに対応する第1のUEを決定してもよく、第1のUEが報告するSRは、サイドリンクにおいて論理チャネルにバインドされる。したがって、第1の基地局は、第1のUEに接続される複数のサイドリンクにおいて受信したSRに基づいて、そのSRに対応するサイドリンクを決定してもよく、その決定されるサイドリンクのデータ受信端は、第3のUEとなる。言い換えると、第1の基地局は、受信したSRに基づいて、そのSRが、第1のUEに接続される複数の第2のUEのうちの第3のUEに対応するということを決定してもよい。SRは、1ビット情報であってもよい。

【0176】

第1のDRXパラメーターが図3乃至図5に示されている実施形態によって構成されているときに、第3の通信装置は、第2の通信装置のうちの1つであってもよい。

【0177】

第3の通信装置に対応する第1のDRXパラメーターに基づいて、サイドリンクにおいて利用可能であるとともに、第1の通信装置に割り当てられているリソースに関する情報を決定するときに、第1のネットワークデバイスは、第1のDRXパラメーターの中の活動時間のパラメーターに対応する(継続期間及び継続期間の開始時間点を含む)継続期間に基づいて、リソースプールのうちで、活動時間のパラメーターに対応する継続期間と同じ時間周波数リソースを決定してもよい。活動時間の継続期間は、割り当てられている時間領域リソースの継続期間よりもより長くてもよい。

【0178】

第1のネットワークデバイスが、第1の通信装置のために、サイドリンクにおける通信のためのリソースを構成するときに、そのリソースが通信のために使用される第2の通信装置を第1の通信装置に通知しない場合には、第1の通信装置は、データ伝送優先度が最も高い第2の通信装置を選択してもよいが、一方で、その第2の通信装置は、休眠期間の中にある場合がある。この場合には、第1の通信装置が送信するデータは、選択されている第2の通信装置のよっては受信されない。

【0179】

複数の実装のうちのいくつかにおいて、第1のネットワークデバイスは、PDCCHにおいて第1の通信装置にDCIを送信してもよい。

【0180】

複数の実装のうちのいくつかにおいて、リソースに関する情報は、第3の通信装置に利用可能であるPSSCHの位置情報を含んでもよい。

【0181】

603: 第1の通信装置は、第3の通信装置にサイドリンク制御情報(sidelink control information, SCI)を送信する。SCIは、リソースに関する情報を含み、リソースに関する情報は、第3の通信装置が、リソースに関する情報が示すリソースによって、第1の通信装置が送信するデータを受信するのに使用される。

【0182】

第1の通信装置が、第1のネットワークデバイスから、第3の通信装置の識別子及び割り当てられるリソースに関する情報を受信するときに、第1の通信装置は、第3の通信装置の識別子に基づいて、第3の通信装置に、リソースに関する情報を送信してもよく、それによって、第3の通信装置は、リソースに関する情報が示すリソースに基づいて、第1の通信装置が送信するデータを受信してもよい。

【0183】

複数の実装のうちのいくつかにおいて、第1の通信装置は、PSCCHにおいてSCIを送信してもよく、SCIの中に含まれるリソースに関する情報は、第3の通信装置がデータを受信する必要があるPSSCHの位置である。

【0184】

604: 第1の通信装置は、リソースに関する情報が示すリソースによって第3の通信装置との間でデータ通信を実行する。

【0185】

具体的にいうと、第1の通信装置は、リソースによって第3の通信装置にデータを送信し、第3の通信装置は、第1の通信装置が送信するデータをそのリソースによって受信する。

【0186】

複数の実装のうちのいくつかにおいて、第3の通信装置からPSCCHを受信することは、また、第3の通信装置から、新たなデータの最初の送信を示すスケジューリング情報を受信するときに、第3の通信装置が、第3の通信装置に対応する第1のDRXパラメーターに基づいて、drx-InactivityTimerを開始してもよいことであると理解されてもよい。

【0187】

複数の実装のうちのいくつかにおいて、第1の通信装置及び第3の通信装置の具体的なデータスケジューリングプロセスは、以下の場合をさらに含んでもよい。例えば、第1の通信装置は、Tx UEであり、第3の通信装置は、Rx UEである。

【0188】

Tx UEが送信するプロトコルデータユニット(protocol data unit, MAC PDU)を受信するときに、Rx UEは、対応するHARQプロセスに対してdrx-HARQ-RTT-TimerTtoRを開始し(この期間の中ではデータ再送信を実行することは不可能である)、対応するHARQプロセスのdrx-RetransmissionTimerTtoRを停止し(Rx UEが再送信されるデータの受信のために待機する必要がある継続期間)、そして、休眠期間に入る。

【0189】

Rx UEがTx UEにACK/NACKを送信するときに(Rx UEが、Tx UEが送信するデータを受信するときに、Rx UEは、Tx UEにACKを送信するか、又は、Rx UEが、Tx UEが送信するデータを受信しないときに、Rx UEは、Tx UEにNACKを送信する)、drx-HARQ-RTT-TimerRtoTを開始し(この期間においては、ACK/NAKCフィードバックを実行することは不可能である)、drx-RetransmissionTimerRtoTを停止し(Rx UEがACK/NAKCフィードバックの送信のために待機する必要がある継続期間)、そして、Rx UEは、休眠期間に入る。

【0190】

drx-HARQ-RTT-TimerTtoRが終了するときに、対応するHARQプロセスのデータの受信に成功していない場合には、対応するHARQプロセスに対してdrx-RetransmissionTimerTtoRを開始し、Rx UEは、活動時間に入る。

【0191】

drx-HARQ-RTT-TimerRtoTが終了するときに、Rx UEが送信するACK/NAKCフィードバックの受信に成功していない場合には、drx-RetransmissionTimerRtoTを開始し、Rx UEは、活動時間に入る。

【0192】

Rx UEがDRX Command MAC CE(control element, 制御要素)又はLong DRX Command MAC CEを受信するときに、drx-onDurationTimer及びdrx-InactivityTimerを停止する。

【0193】

Drx-InactivityTimerが終了するとき、又は、Rx UEがDRX Command MAC CEを受信するときに、Short DRX Cycleが現時点で構成されている場合には、drx-ShortCycleTimerが開始されるか又は再び開始され、そして、Short DRX Cycleを使用し、それ以外の場合には、Long DRX Cycleを使用する。

【0194】

drx-ShortCycleTimerが終了するときに、Long DRX Cycleを使用する。

【0195】

Rx UEがLong DRX Command MAC CEを受信するときに、drx-ShortCycleTimerを停止し、Long DRX Cycleを使用する。

【0196】

Short DRX Cycleを使用し、且つ、[(SFN×10)＋subframe number] modulo (drx-ShortCycle)＝(drx-StartOffset) modulo (drx-ShortCycle)であるとき、又は、Long DRX Cycleを使用し、且つ、[(SFN×10)＋subframe number] modulo (drx-LongCycle)＝drx-StartOffset(SFNは、system frame numberであり、システムフレーム番号を示す)であるときに、サブフレームの始端におけるdrx-SlotOffsetの後に、drx-onDurationTimerを開始する。

【0197】

MACエンティティが活動時間の中にあるときに、Rx UEは、PSCCHをリッスンする必要がある。

【0198】

Rx UEが新たなデータ伝送を示すPSCCHを受信するときに、drx-InactivityTimerを開始する。

【0199】

Rx UEが、データ再送信を示すPSCCHを受信するときに、drx-HARQ-RTT-TimerTtoRを開始し、drx-RetransmissionTimerTtoRを停止する。

【0200】

Rx UEがACK/NACKフィードバックの送信を示すPSCCHを受信するときに、drx-HARQ-RTT-TimerTtoRを開始し、drx-RetransmissionTimerTtoRを停止する。

【0201】

したがって、図6に対応する方法のステップの説明に基づいて、第3の通信装置は、第1のネットワークデバイスが第1のDRXパラメーターに基づいて決定するとともに活動時間の中にあるデータ受信端となる。したがって、第1の通信装置が、第1のネットワークデバイスが割り当てるリソースによってデータを送信するときに、第3の通信装置は、活動時間の中にあり、第3の通信装置は、第1のネットワークデバイスが割り当てるリソースによってデータを受信してもよい。したがって、第3の通信装置は、常時、受信されるべきデータが存在するか否かをモニタリングする状態となっている必要はなく、第3の通信装置の電力を節約する。

【0202】

動作モード1の場合、すなわち、基地局等のネットワークデバイスによって伝送リソースを割り当てる場合には、図7を参照するべきである。ステップ309、ステップ410、又はステップ507の具体的な実装は、以下のステップを含んでもよい。

【0203】

701: 第1の通信装置が、サイドリンクにおいて送信されるべきデータが存在するということを決定するときに、第1の通信装置は、第1のネットワークデバイスにSRを送信する。そのSRは、サイドリンクにおける第1の通信装置の通信要件を示すのに使用される。

【0204】

ステップ701の実装については、ステップ601を参照するべきである。

【0205】

702: 第1のネットワークデバイスは、第1の通信装置にDCIを送信する。そのDCIは、第1の通信装置に割り当てられて、サイドリンクにおいて利用可能とされるリソースに関する情報を含む。

【0206】

703: 第1の通信装置は、第1の通信装置に接続される複数の通信装置の第1のDRXパラメーター及びリソースに関する情報に基づいて、第1の通信装置に接続される複数の通信装置のうちで活動時間の中にある少なくとも1つの通信装置を決定する。

【0207】

第1の通信装置は、複数の第2の通信装置に対応する第1のDRXパラメーターを格納し、第1の通信装置は、また、PDCCHの中のリソースに関する特定の情報の中のPSSCHの位置を知っているため、第1の通信装置は、第1の通信装置が割り当てる(PSSCHの位置情報等の)リソースに関する情報及び第1の通信装置に接続される複数の通信装置の第1のDRXパラメーターに基づいて、現時点で活動時間の中にある少なくとも1つの通信装置を決定してもよい。

【0208】

704: 第1の通信装置は、少なくとも1つの通信装置のうちで、論理チャネル優先度が最も高い第3の通信装置を決定する。

【0209】

複数の実装のうちのいくつかにおいて、第1の通信装置へのサイドリンクを確立している複数の通信装置が存在してもよく、各々のサイドリンクは、複数の論理チャネルに対応してもよい。複数の異なる論理チャネルによって送信されるサービスデータは、異なってもよい。サービス優先度が高くなるにしたがい、対応する論理チャネルの優先度が高くなることを示す。このように、サービス優先度に基づいて、優先度が最も高い論理チャネルを決定して、その論理チャネルに対応するサイドリンクにおいて第1の通信装置との間で通信する第3の通信装置を決定してもよい。

【0210】

複数の実装のうちのいくつかにおいて、第1の通信装置は、さらに、第3の通信装置として、少なくとも1つの通信装置のうちで、論理チャネル優先度が2番目の通信装置又は3番目の通信装置を決定してもよい。

【0211】

705: 第1の通信装置は、第3の通信装置にSCIを送信する。そのSCIは、リソースに関する情報を含み、リソースに関する情報は、第1の通信装置が送信するデータを、第3の通信装置が、リソースに関する情報が示すリソースによって受信するのに使用される。

【0212】

ステップ705の実装については、ステップ603を参照するべきである。

【0213】

706: 第1の通信装置は、リソースに関する情報が示すリソースによって、第3の通信装置との間でデータ通信を実行する。

【0214】

ステップ706の実装については、ステップ604を参照するべきである。

【0215】

したがって、図7に対応する方法のステップの説明に基づいて、第1の通信装置が、第1のネットワークデバイスが割り当てるリソースに関する情報を受信するときに、第1の通信装置は、第1のDRXパラメーター及びリソースに関する情報に基づいて、活動時間の中にあるとともに論理チャネル優先度が最も高い第3の通信装置を決定してもよく、それによって、第1の通信装置は、リソースに関する情報が示すリソースによってデータを送信するときに、第3の通信装置は、活動時間の中にあり、第3の通信装置は、そのリソースによってデータを受信することが可能である。このことは、優先度が最も高い論理チャネルにおけるデータを時間内に受信するということを保証することを可能とし、第3の通信装置は、常時、受信されるべきデータが存在するか否かをモニタリングする状態となっている必要はなく、第3の通信装置の電力を節約する。

【0216】

動作モード2の場合、すなわち、端末デバイスによってリソースプールから伝送リソースを選択するときには、図8を参照するべきである。ステップ309、ステップ410、又はステップ507の具体的な実装は、代替的に、以下のステップを含んでもよい。

【0217】

801: 第1の通信装置は、接続が確立されているサイドリンクのすべてから論理チャネル優先度が最も高い第1のサイドリンクを決定し、そして、第1のサイドリンクによって第1の通信装置に接続されている第3の通信装置の第1のDRXパラメーターを決定する。

【0218】

複数の実装のうちのいくつかにおいて、第1の通信装置へのサイドリンクを確立している複数の通信装置が存在してもよく、各々のサイドリンクにおいて複数の論理チャネルが存在してもよい。複数の異なる論理チャネルによって送信されるサービスデータは、異なっていてもよい。サービス優先度が高くなるにしたがい、対応する論理チャネルの優先度が高くなることを示す。このように、サービス優先度に基づいて、優先度が最も高い論理チャネルを決定して、優先度が最も高い論理チャネルが位置しているサイドリンクを決定してもよい。そのサイドリンクは、第1のサイドリンクとなり、第1のサイドリンクに対応するデータ受信端は、第3の通信装置となる。その次に、第1の通信装置は、データ受信端として機能する通信装置の識別子と第1のDRXパラメーターとの間の格納されている対応関係に基づいて、第3の通信装置の第1のDRXパラメーターを決定してもよい。

【0219】

802: 第1の通信装置は、第3の通信装置の第1のDRXパラメーターに基づいて、リソースプールから、第3の通信装置が活動時間の中にあるリソースに関する情報を決定する。

【0220】

例えば、第3のUEの第1のDRXパラメーターは、(パラメーターの継続期間及び開始時間点を含む)活動時間のパラメーター及び休眠状態のパラメーターを含む。例えば、活動時間のパラメーターは、drx-onDurationTimer、drx-InactivityTimer、drx-RetransmissionTimerTtoR、又は、drx-RetransmissionTimerRtoTを含む。第1のUEは、リソースプールから、活動時間のパラメーターに対応する継続期間に基づいて、活動時間のパラメーターの継続期間における時間領域リソースに対応する時間周波数リソースを決定してもよく、時間周波数リソースは、第3のUEが活動時間の中にあるリソースに関する情報として役立つ。

【0221】

803: 第1の通信装置は、第3の通信装置にSCIを送信する。そのSCIは、リソースに関する情報を含み、リソースに関する情報は、第1の通信装置が送信するデータを、第3の通信装置が、リソースに関する情報が示すリソースによって受信するのに使用される。

【0222】

ステップ803の実装については、ステップ603を参照するべきである。

【0223】

804: 第1の通信装置は、リソースに関する情報が示すリソースによって、第3の通信装置との間でデータ通信を実行する。

【0224】

ステップ804の実装については、ステップ604を参照するべきである。

【0225】

したがって、図8に対応する方法のステップの説明に基づいて、第1の通信装置が、優先度が最も高い論理チャネルに対応する第1のサイドリンクを決定するときに、第1の通信装置は、第1のサイドリンクにおいてデータ受信端として機能する第3の通信装置に対応する第1のDRXに基づいて、リソースプールから、第3の通信装置が活動時間の中にあるリソースを決定してもよい。すなわち、第1の通信装置は、第1のDRXパラメーターに基づいて、第3の通信装置の活動時間及び休眠期間を決定して、第3の通信装置が活動時間の中にあるリソースによって、第3の通信装置にデータを送信してもよい。第3の通信装置は、そのリソースによって、第1の通信装置が送信するデータを受信することが可能であり、第3の通信装置は、常時、受信されるべきデータが存在するか否かをモニタリングする状態となっている必要はなく、第3の通信装置の電力を節約する。

【0226】

図3、図4A、図4B、図5、図6、図7、及び図8を参照すると、上記の記載は、この出願の複数の実施形態にしたがった通信方法を詳細に説明している。図9乃至図13を参照すると、以下の記載は、例えば、端末デバイス、端末デバイスの中で使用される(例えば、プロセッサ、回路、又はチップ等の)装置、ネットワークデバイス、又はネットワークデバイスの中で使用される(例えば、プロセッサ、回路、又はチップ等の)装置等のこの出願の複数の実施形態にしたがった通信装置を詳細に説明する。

【0227】

図9は、この出願のある1つの実施形態にしたがった端末デバイスの構成の概略的な図である。端末デバイスは、図2に示されているシステムに適用可能であり、上記の複数の方法の実施形態における端末デバイスの機能を実行する。説明を容易にするために、図9は、端末デバイスの主要な構成要素のみを示す。図9に示されているように、端末デバイス90は、プロセッサ902、メモリ903、(制御回路及びアンテナ)901、及び入力/出力装置を含む。プロセッサ902は、例えば、端末デバイスが、上記の複数の方法の実施形態の中で説明されている動作を実行するのを支援するように構成される、といったように、主として、通信プロトコル及び通信データを処理し、端末デバイス全体を制御し、ソフトウェアプログラムを実行し、そして、ソフトウェアプログラムのデータを処理するように構成される。メモリ903は、主として、ソフトウェアプログラム及びデータを格納するように構成される。制御回路は、主として、ベースバンド信号と無線周波数信号との間で変換を実行し、無線周波数信号を処理するように構成される。制御回路及びアンテナの組み合わせは、また、トランシーバーと称されてもよく、主として、電磁波の形態で無線周波数信号を送信し/受信するように構成されてもよい。例えば、タッチスクリーン、ディスプレイ、又はキーボード等の入力/出力装置は、主として、ユーザが入力するデータを受信し、ユーザにデータを出力するように構成される。

【0228】

端末デバイスの電源がオンになった後に、プロセッサ902は、メモリの中のソフトウェアプログラムを読み込み、ソフトウェアプログラムの命令を解釈して実行し、そして、ソフトウェアプログラムのデータを処理してもよい。無線方式によってデータを送信する必要があるときに、プロセッサが、送信されるデータに対してベースバンド処理を実行した後に、プロセッサは、無線周波数回路にベースバンド信号を出力する。そのベースバンド信号に対して無線周波数処理を実行した後に、無線周波数回路は、電磁波の形態で、アンテナを介して無線周波数信号を送信する。データが端末デバイスに送信されるときに、無線周波数回路は、アンテナを介して無線周波数信号を受信し、その無線周波数信号をベースバンド信号へと変換し、プロセッサにそのベースバンド信号を出力する。プロセッサは、そのベースバンド信号をデータへと変換し、そして、そのデータを処理する。

【0229】

当業者は、図9が、説明を容易にするために、1つのみのメモリ及び1つのみのプロセッサを示しているということを理解することが可能である。実際の端末デバイスは、複数のプロセッサ及び複数のメモリを含んでいてもよい。メモリは、また、記憶媒体又は記憶デバイス等と称されてもよい。メモリは、プロセッサと同じチップに位置している記憶素子であってもよい、すなわち、オンチップ記憶素子又は独立記憶素子であってもよい。このことは、この出願のこの実施形態においては限定されない。

【0230】

ある1つの選択的な実装において、端末デバイスは、ベースバンドプロセッサ及び中央処理ユニットを含んでもよい。ベースバンドプロセッサは、主として、通信プロトコル及び通信データを処理するように構成される。中央処理ユニットは、主として、端末デバイス全体を制御し、ソフトウェアプログラムを実行し、ソフトウェアプログラムのデータを処理する、ように構成される。図9におけるプロセッサは、ベースバンドプロセッサ及び中央処理ユニットの機能を一体化してもよい。当業者は、ベースバンドプロセッサ及び中央処理ユニットが、代替的に、互いに独立したプロセッサとなっていてもよく、バス等の技術を使用することによって相互接続されるということを理解することが可能である。当業者は、端末デバイスが、複数のベースバンドプロセッサを含むことにより、複数の異なるネットワーク規格に適合してもよく、端末デバイスが、複数の中央処理ユニットを含むことにより、その端末デバイスの処理能力を高めてもよく、さまざまなバスを使用することによって、端末デバイスの複数の構成要素を接続してもよいということを理解することが可能である。ベースバンドプロセッサは、代替的に、ベースバンド処理回路又はベースバンド処理チップとして表現されてもよい。中央処理ユニットは、代替的に、中央処理回路又は中央処理チップとして表現されてもよい。通信プロトコル及び通信データを処理する機能は、プロセッサの中に内蔵されていてもよく、又は、ソフトウェアプログラムの形態でメモリの中に格納されていてもよい。プロセッサは、ソフトウェアプログラムを実行して、ベースバンド処理機能を実装する。

【0231】

この出願のこの実施形態において、受信機能及び送信機能を有するアンテナ及び制御回路は、例えば、端末デバイスが受信機能及び送信機能を実行するのを支援するように構成されてもよい、といったように、端末デバイス100のトランシーバーユニット1001として考えられてもよい。処理機能を有するプロセッサ902は、端末デバイス100の処理ユニット1002と考えられる。メモリ903は、記憶ユニット1003と考えられる。図10に示されているように、端末デバイス100は、トランシーバーユニット1001及び処理ユニット1002を含む。トランシーバーユニットは、また、トランシーバー、トランシーバー機械、又はトランシーバー装置等と称されてもよい。選択的に、トランシーバーユニット1001の中で受信機能を実装するように構成されるデバイスは、受信ユニットと考えられてもよい。トランシーバーユニット1001の中で送信機能を実装するように構成されるデバイスは、送信ユニットと考えられてもよい。言い換えると、トランシーバーユニット1001は、受信ユニット及び送信ユニットを含む。受信ユニットは、また、受信機械、入力ポート、又は受信回路等と称されてもよい。送信ユニットは、送信機械、送信機、又は送信回路等と称されてもよい。

【0232】

処理ユニット1002は、メモリの中に格納されている命令を実行して、信号を受信し及び/又は信号を伝送するようにトランシーバーユニット1001を制御し、そして、上記の複数の方法の実施形態における端末デバイスの機能を実装する、ように構成されてもよい。処理ユニット1002は、インターフェイスをさらに含み、そのインターフェイスは、信号入力/出力機能を実装するように構成される。ある1つの実装において、トランシーバーユニット1001の機能は、トランシーバー回路又はトランシーバー専用チップを使用することによって実現されるということが考えられてもよい。

【0233】

図11は、この出願のある1つの実施形態にしたがった端末デバイスの他の構成の概略的な図である。図11に示されているように、端末デバイス110は、プロセッサ1101及びトランシーバー1102を含む。選択的に、端末デバイス110は、メモリ1103をさらに含む。プロセッサ1101、トランシーバー1102、及びメモリ1103は、内部接続経路を介して互いの間で通信して、制御信号及び/又はデータ信号を転送してもよい。メモリ1103は、コンピュータプログラムを格納するように構成される。プロセッサ1101は、メモリ1103からコンピュータプログラムを呼び出し、そして、そのコンピュータプログラムを実行して、信号を受信し/送信するようにトランシーバー1102を制御するように構成される。端末デバイス110は、アンテナ1104をさらに含んでもよく、そのアンテナ1104は、無線信号を使用することによって、トランシーバー1102が出力するアップリンクデータ又はアップリンク制御信号を送信するように構成される。

【0234】

プロセッサ1101及びメモリ1103を一体化して、1つの処理装置としてもよい。プロセッサ1101は、メモリ1103の中に格納されているプログラムコードを実行して、上記機能を実装するように構成される。具体的な実装の際に、メモリ1103は、また、プロセッサ1101に一体化されてもよく、又は、プロセッサ1101から独立していてもよい。

【0235】

具体的には、端末デバイス110は、この出願の複数の実施形態にしたがった方法のそれらの複数の実施形態に対応してもよい。加えて、端末デバイス110の中のユニット及び上記の他の操作及び/又は機能は、複数の方法の実施形態において対応する手順を実装するのに使用される。

【0236】

プロセッサ1101は、上記の複数の方法の実施形態の中で説明されている第1の通信装置及び第2の通信装置(異なる通信においては、端末デバイスは、第1の通信装置であってもよく又は第2の通信装置であってもよい)のうちの1つ又は複数が実装する動作を実行するように構成されてもよく、トランシーバー1102は、上記の複数の方法の実施形態の中で説明されている端末デバイスA、端末デバイスB、及び端末デバイスCのうちの1つ又は複数の送信動作又は受信動作を実行するように構成されてもよい。詳細については、上記の複数の方法の実施形態の中の説明を参照するべきである。本明細書においては、詳細は説明されない。

【0237】

選択的に、端末デバイス110は、その端末デバイスの中のさまざまなデバイス又は回路に電力を供給するように構成される電源1105をさらに含んでもよい。

【0238】

加えて、端末デバイスのそれらの複数の機能を改善するために、端末デバイス110は、入力ユニット1106、表示ユニット1107、オーディオ回路1108、カメラ1109、及びセンサ1110等のうちの1つ又は複数をさらに含んでもよく、オーディオ回路は、スピーカ1112及びマイクロホン1113等をさらに含んでもよい。

【0239】

図12は、この出願のある1つの実施形態にしたがったネットワークデバイスの構成の概略的な図であり、例えば、基地局の構成の概略的な図であってもよい。図12に示されているように、基地局は、図2に示されているシステムの中で使用されて、上記の複数の方法の実施形態におけるネットワークデバイスの機能を実行してもよい。基地局120は、1つ又は複数の分散ユニット(distributed units, DUs)121及び1つ又は複数の集中型ユニット(centralized units, CUs)122を含んでもよい。CU122は、NGコア(next generation core, NC)との間で通信してもよい。DU121は、少なくとも1つの無線周波数ユニット1212、少なくとも1つのプロセッサ1213、及び少なくとも1つのメモリ1214を含んでもよい。DU121は、少なくとも1つのアンテナ1211をさらに含んでもよい。DU121は、主として、無線周波数信号を受信し及び送信し、無線周波数信号とベースバンド信号との間の変換を実行し、そして、部分的なベースバンド処理を実行する、ように構成される。CU122は、少なくとも1つのプロセッサ1222及び少なくとも1つのメモリ1221を含んでもよい。CU122及びDU121は、インターフェイスを介して互いの間で通信してもよい。制御プレーン(Control plane)インターフェイスは、例えば、F1-C等のFs-Cであってもよく、ユーザプレーン(User Plane)インターフェイスは、例えば、F1-U等のFs-Uであってもよい。

【0240】

CU122は、主として、ベースバンド処理を実行し及び基地局を制御等するように構成される。DU121及びCU122は、物理的に一緒に配置されてもよく、又は、物理的に個別に配置されてもよく、具体的にいうと、基地局は、分散型基地局である。CU122は、基地局の制御センターであり、また、処理ユニットと称されてもよく、主として、ベースバンド処理機能を完了するように構成される。例えば、CU122は、上記の複数の方法の実施形態におけるネットワークデバイスに関連する操作手順を実行するように基地局を制御するように構成されてもよい。

【0241】

具体的には、無線ネットワークのプロトコル層に基づいて、CU及びDUのベースバンド処理を分割してもよい。例えば、PDCP層及びPDCP層の上位の層の機能は、CUにおいて設定され、RLC層及びMAC層等のPDCP層の下位のプロトコル層の機能は、DUにおいて設定される。他の例では、CUは、RRC層及びPDCP層の機能を実装し、DUは、RLC層、MAC層、及び物理(physical, PHY)層の機能を実装する。

【0242】

加えて、(図示されておらず)選択的に、基地局120は、1つ又は複数のアンテナ、1つ又は複数の無線周波数ユニット、1つ又は複数のDU、及び1つ又は複数のCUを含んでもよい。DUは、少なくとも1つのプロセッサ及び少なくとも1つのメモリを含んでもよく、少なくとも1つのアンテナ及び少なくとも1つの無線周波数ユニットを一体化して、1つのアンテナ装置としてもよく、CUは、少なくとも1つのプロセッサ及び少なくとも1つのメモリを含んでもよい。

【0243】

ある1つの例において、CU122は、1つ又は複数の回路基板を含んでもよく、複数の回路基板は、単一のアクセス規格の(例えば、5Gネットワーク等の)無線アクセスネットワークを共同でサポートしてもよく、又は、複数の異なるアクセス規格の(例えば、LTEネットワーク、5Gネットワーク、又は他のネットワーク等の)無線アクセスネットワークを個別にサポートしてもよい。メモリ1221及びプロセッサ1222は、1つ又は複数の回路基板にサービスを提供してもよい。すなわち、メモリ及びプロセッサは、各々の回路基板に個々に配置されてもよい。代替的に、複数の回路基板は、同じメモリ及び同じプロセッサを共有してもよい。加えて、さらに、各々の回路基板に必要な回路を配置してもよい。DU121は、1つ又は複数の回路基板を含んでもよく、複数の回路基板は、単一のアクセス規格の(例えば、5Gネットワーク等の)無線アクセスネットワークを共同でサポートしてもよく、又は、複数の異なるアクセス規格の(例えば、LTEネットワーク、5Gネットワーク、又は他のネットワーク等の)無線アクセスネットワークを個別にサポートしてもよい。メモリ1214及びプロセッサ1213は、1つ又は複数の回路基板にサービスを提供してもよい。すなわち、メモリ及びプロセッサは、各々の回路基板に個別に配置されてもよい。代替的に、複数の回路基板は、同じメモリ及び同じプロセッサを共有してもよい。加えて、さらに、各々の回路基板に必要な回路を配置してもよい。

【0244】

図13は、通信装置13の構成の概略的な図である。通信装置13は、上記の複数の方法の実施形態において説明されている方法を実装するように構成されてもよい。上記の複数の方法の実施形態の中の説明を参照するべきである。通信装置13は、チップ、(例えば、基地局等の)ネットワークデバイス、又は端末デバイスであってもよい。

【0245】

通信装置13は、1つ又は複数のプロセッサ1301を含む。そのプロセッサ1301は、汎用プロセッサ又は専用プロセッサ等であってもよい。例えば、プロセッサ1301は、ベースバンドプロセッサ又は中央処理ユニットであってもよい。ベースバンドプロセッサは、通信プロトコル及び通信データを処理するように構成されてもよい。中央処理ユニットは、(例えば、基地局、端末、又はチップ等の)装置を制御し、ソフトウェアプログラムを実行し、そして、ソフトウェアプログラムのデータを処理する、ように構成されてもよい。装置は、トランシーバーユニットを含んでもよく、そのトランシーバーユニットは、信号を入力し(受信し)及び出力する(送信する)ように構成される。例えば、装置は、チップであってもよく、トランシーバーユニットは、チップの入力及び/又は出力回路又は通信インターフェイスであってもよい。チップは、端末デバイス又は(例えば、基地局等の)ネットワークデバイスのために使用されてもよい。他の例として、装置は、端末デバイス又は(例えば、基地局等の)ネットワークデバイスであってもよく、トランシーバーユニットは、トランシーバー又は高周波チップ等であってもよい。

【0246】

通信装置13は、1つ又は複数のプロセッサ1301を含み、1つ又は複数のプロセッサ1301は、図3乃至図8に示されている複数の実施形態において、ネットワークデバイス又は端末デバイスが実行する方法を実装してもよい。

【0247】

ある1つの可能な設計において、通信装置13は、ソースネットワークデバイスからスケジューリング情報を受信するように構成される手段(means)、及び、スケジューリング情報に基づいてサイドリンクデータを送信するように構成される手段(means)を含む。例えば、トランシーバー、入力/出力回路、又はチップのインターフェイスを使用することによって、スケジューリング情報を受信してもよく、サイドリンクデータを送信してもよい。スケジューリング情報については、上記の複数の方法の実施形態の中の関連する説明を参照するべきである。

【0248】

ある1つの可能な設計において、通信装置13は、端末デバイスのスケジューリング情報を決定するように構成される手段(means)及び端末デバイスにスケジューリング情報を送信するように構成される手段(means)を含む。詳細については、上記の複数の方法の実施形態の中の関連する説明を参照するべきである。例えば、トランシーバー、入力/出力回路、又はチップのインターフェイスを使用することによって、スケジューリング情報を送信してもよく、1つ又は複数のプロセッサを使用することによって、端末デバイスのスケジューリング情報を決定してもよい。

【0249】

ある1つの可能な設計において、通信装置13は、第1の端末デバイスからのスケジューリング情報を受信するように構成される手段(means)及びスケジューリング情報に基づいてサイドリンクデータを受信するように構成される手段(means)を含む。詳細については、上記の複数の方法の実施形態の中の関連する説明を参照するべきである。例えば、トランシーバー、入力/出力回路、又はチップのインターフェイスを使用することによって、スケジューリング情報及びサイドリンクデータを受信してもよい。

【0250】

選択的に、図3乃至図8のうちの1つ又は複数に示されている実施形態における方法の実装に加えて、プロセッサ1301は、さらに、他の機能を実装してもよい。

【0251】

ある1つの選択的な設計において、プロセッサ1301は、また、命令1303を含んでもよい。命令は、プロセッサによって実行されてもよく、それによって、通信装置13は、上記の複数の方法の実施形態の中で説明されている方法を実行する。

【0252】

さらに別の可能な設計において、通信装置13は、回路を含んでもよく、その回路は、上記の複数の方法の実施形態におけるネットワークデバイス又は端末デバイスの機能を実装することが可能である。

【0253】

さらに別の可能な設計において、通信装置13は、命令1304が格納される1つ又は複数のメモリ1302を含んでもよく、その命令は、プロセッサによって実行されてもよく、それによって、通信装置13は、上記の複数の方法の実施形態の中で説明されている方法を実行する。選択的に、メモリは、さらに、データを格納してもよい。選択的に、プロセッサは、また、命令及び/又はデータを格納してもよい。例えば、1つ又は複数のメモリ1302は、上記の複数の実施形態の中で説明されている移動有効領域を格納してもよく、或いは、上記の複数の実施形態において、関連するパラメーター又はテーブル等を格納してもよい。プロセッサ及びメモリは、個別に配置されてもよく又はともに一体化されていてもよい。

【0254】

さらに別の可能な設計において、通信装置13は、トランシーバーユニット1305及びアンテナ1306をさらに含んでもよく、又は、通信インターフェイスを含んでもよい。トランシーバーユニット1305は、トランシーバー機械、トランシーバー回路、又はトランシーバー等と称されてもよく、アンテナ1306を使用することによって装置のトランシーバー機能を実装するように構成される。(図示されていない)通信インターフェイスは、コアネットワークデバイスとネットワークデバイスとの間の通信のために又は複数のネットワークデバイスの間の通信のために使用されてもよい。選択的に、通信インターフェイスは、例えば、光ファイバ通信インターフェイス等の有線通信インターフェイスであってもよい。

【0255】

プロセッサ1301は、(例えば、端末又は基地局等の)装置を制御するための処理ユニットと称されてもよい。

【0256】

加えて、この出願のこの実施形態の中で説明されているトランシーバーユニット1305が実行する送信又は受信は、処理ユニット(プロセッサ1301)の制御を受けているため、送信動作又は受信動作は、この出願のこの実施形態においては、処理ユニット(プロセッサ1301)が実行すると説明されてもよい。このことは、当業者による解決方法の理解に影響を及ぼすものではない。

【0257】

上記の複数の装置の実施形態における端末デバイス及びネットワークデバイスは、複数の方法の実施形態における端末デバイス又はネットワークデバイスと厳密に対応していてもよく、対応するモジュール又はユニットは、対応するステップを実行する。例えば、装置がチップの形態で実装されるときに、受信ユニットは、チップのインターフェイス回路であってよく、そのチップのインターフェイス回路は、他のチップ又は装置からの信号を受信するように構成される。送信のために構成される上記のユニットは、装置のインターフェイス回路であり、他の装置に信号を送信するように構成される。例えば、装置がチップの方式によって実装されるときに、送信ユニットは、チップのインターフェイス回路であり、そのチップのインターフェイス回路は、他のチップ又は装置に信号を送信するように構成される。

【0258】

この出願の複数の実施形態におけるプロセッサは、CPUであってもよく、或いは、さらに、他の汎用プロセッサ、ディジタル信号プロセッサ(digital signal processor, DSP)、特定用途向け集積回路(application-specific integrated circuit, ASIC)、フィールドプログラマブルゲートアレイ(field programmable gate array, FPGA)、又は、他のプログラム可能な論理デバイス、個別のゲート又はトランジスタ論理デバイス、又は、個別のハードウェア構成要素等であってもよいということを理解するべきである。

【0259】

さらに、この出願の複数の実施形態におけるメモリは、揮発性メモリであってもよく又は不揮発性メモリであってもよく、又は、揮発性メモリ及び不揮発性メモリの双方を含んでいてもよいということを理解するべきである。不揮発性メモリは、読み取り専用メモリ(read-only memory, ROM)、プログラム可能な読み取り専用メモリ(programmable ROM, PROM)、消去可能な且つプログラム可能な読み取り専用メモリ(erasable PROM, EPROM)、電気的に消去可能な且つプログラム可能な読み取り専用メモリ(electrically EPROM, EEPROM)、又はフラッシュメモリであってもよい。揮発性メモリは、ランダムアクセスメモリ(random access memory, RAM)であってもよく、外部キャッシュとして使用される。例として、これらには限定されないが、例えば、静的なランダムアクセスメモリ(static RAM, SRAM)、動的なランダムアクセスメモリ(DRAM)、同期的な且つ動的なランダムアクセスメモリ(synchronous DRAM, SDRAM)、ダブルデータレート同期的な且つ動的なランダムアクセスメモリ(double data rate SDRAM, DDR SDRAM)、強化型の同期的な且つ動的なランダムアクセスメモリ(enhanced SDRAM, ESDRAM)、サイドリンクの動的なランダムアクセスメモリ(synchlink DRAM, SLDRAM)、ダイレクトランバスランダムアクセスメモリ(direct rambus RAM, DR RAM)等の多くの形態のRAMを使用してもよい。

【0260】

上記の複数の装置の実施形態における端末デバイス及びネットワークデバイスは、複数の方法の実施形態における端末デバイス又はネットワークデバイスと厳密に対応していてもよく、対応するモジュール又はユニットは、対応するステップを実行する。例えば、装置がチップの形態で実装されるときに、受信ユニットは、チップのインターフェイス回路であってよく、そのチップのインターフェイス回路は、他のチップ又は装置からの信号を受信するように構成される。送信のために構成される上記のユニットは、装置のインターフェイス回路であり、他の装置に信号を送信するように構成される。例えば、装置がチップの方式によって実装されるときに、送信ユニットは、チップのインターフェイス回路であり、そのチップのインターフェイス回路は、他のチップ又は装置に信号を送信するように構成される。

【0261】

この出願のある1つの実施形態は、さらに、通信システムを提供する。通信システムは、ネットワークデバイス、第1の端末デバイス、及び第2の端末デバイスを含む。第1の端末デバイスは、第1の通信装置に相当し、第2の端末デバイスは、第2の通信装置に相当する。

【0262】

この出願のある1つの実施形態は、さらに、コンピュータプログラムコードを格納するように構成されるコンピュータ読み取り可能な媒体を提供する。コンピュータプログラムは、上記の複数の方法のうちの通信方法においてネットワークデバイス、第1の通信装置、又は第2の通信装置が実行する方法を実行するのに使用される命令を含む。読み取り可能な記憶装置は、ROM又はRAMであってもよい。このことは、この出願のこの実施形態においては限定されない。

【0263】

この出願は、さらに、コンピュータプログラム製品を提供する。コンピュータプログラム製品は、命令を含む。それらの命令を実行するときに、端末デバイスA、端末デバイスB、及びネットワークデバイスが、それぞれ、上記方法における第1の通信装置、第2の通信装置、及びネットワークデバイスに対応する操作を実行することを可能とする。

【0264】

この出願のある1つの実施形態は、さらに、システムチップを提供する。システムチップは、処理ユニット及び通信ユニットを含む。処理ユニットは、例えば、プロセッサであってもよく、通信ユニットは、例えば、入力/出力インターフェイス、ピン、又は回路等であってもよい。処理ユニットは、コンピュータ命令を実行してもよく、それによって、そのチップが適用される通信装置は、この出願の複数の実施形態にしたがった上記の複数の方法における第1の通信装置、第2の通信装置、及びネットワークデバイスの操作を実行する。

【0265】

選択的に、この出願の上記の複数の実施形態が提供するいずれかの通信装置は、システムチップを含んでもよい。

【0266】

選択的に、コンピュータ命令は、記憶ユニットの中に格納される。

【0267】

選択的に、記憶ユニットは、例えば、レジスタ又はキャッシュ等のチップの中の記憶ユニットである。代替的に、記憶ユニットは、例えば、ROM、静的な情報及び命令を格納することが可能である他のタイプの静的な記憶デバイス、又はRAM等の通信装置の中でそのチップの外側に位置している記憶ユニットであってもよい。上記で言及されてるいずれかのプロセッサは、CPU、マイクロプロセッサ、ASIC、或いは、上記のフィードバック情報伝送方法のためのプログラムの実行を制御するように構成される1つ又は複数の集積回路であってもよい。処理ユニット及び記憶ユニットは、分離されていてもよく、複数の異なる物理デバイスに個別に配置されていてもよく、有線方式又は無線方式によって接続されて、処理ユニット及び記憶ユニットのそれぞれの機能を実装し、それにより、そのシステムチップが、上記の複数の実施形態におけるさまざまな機能を実装するのを支援してもよい。代替的に、処理ユニット及びメモリは、同じデバイスに結合されてもよい。この出願の複数の実施形態において、プロセッサは、CPUであってもよく、或いは、他の汎用プロセッサ、DSP、ASIC、FPGA、又は他のプログラム可能な論理デバイス、個別のゲート又はトランジスタ論理デバイス、又は個別のハードウェア構成要素等であってもよいということを理解するべきである。汎用プロセッサは、マイクロプロセッサであってもよく、又は、プロセッサは、いずれかの従来のプロセッサ等であってもよい。

【0268】

当業者は、説明を便利且つ簡潔にするために、上記のシステム、装置、及びユニットの詳細な動作プロセスについては、上記の複数の方法の実施形態における対応するプロセスを参照するべきであるということを明確に理解することが可能である。本明細書において、詳細は繰り返しては説明されない。

【0269】

複数の実装に関する上記の説明は、説明を便利且つ簡潔にすることを目的として、図示するために、ある1つの例として、上記の複数の機能モジュールの分割を行っているということを当業者が理解することを可能とする。実際の適用の際に、要件にしたがって、複数の異なるモジュールに上記の機能を割り当て、そして、それらの機能を実装してもよい、すなわち、複数の異なる機能モジュールへとある装置の内部構成を分割して、上記で説明されているそれらの機能のすべて又は一部を実装する。

【0270】

この出願によって提供される複数の実施形態のうちのいくつかにおいて、開示されている装置及び方法は、他の方式によって実装されてもよいということを理解するべきである。例えば、説明されている装置の実施形態は、例であるにすぎない。例えば、モジュール又はユニットの分割は、論理的な機能の分割であるにすぎず、実際の実装の際には他の分割であってもよい。例えば、複数のユニット又は構成要素を組み合わせてもよく、或いは、それらを一体化して、他の装置としてもよく、或いは、いくつかの特徴を無視してもよく又は実行しなくてもよい。加えて、示され又は説明されている相互の結合、直接的な結合、又は通信接続は、いくつかのインターフェイスを使用することによって実装されてもよい。電子的な形態によって、機械的な形態によって、又は他の形態によって、複数の装置又はユニットの間の間接的な結合又は通信接続を実装してもよい。

【0271】

個別の構成要素として説明されているユニットは、物理的に分離されていてもよく又は物理的に分離されていなくてもよく、ユニットとして示されている構成要素は、1つ又は複数の物理的ユニットであってもよく、すなわち、1つの場所に位置していてもよく、或いは、複数の異なる場所に分散されていてもよい。実際の要件に基づいて、それらの複数のユニットの一部又はすべてを選択して、それらの複数の実施形態の解決方法の目的を達成してもよい。

【0272】

加えて、この出願の実施形態における複数の機能ユニットを一体化して、1つの処理ユニットとしてもよく、或いは、それらの複数のユニットの各々は、物理的に単独で存在していてもよく、或いは、2つ又はそれ以上のユニットを一体化して、1つのユニットとしてもよい。一体化されているユニットは、ハードウェアの形態で実装されてもよく、又は、ソフトウェア機能ユニットの形態で実装されてもよい。

【0273】

一体化されているユニットが、ソフトウェア機能ユニットの形態で実装され、且つ、独立した製品として販売され又は使用されるときに、その一体化されているユニットは、読み取り可能な記憶媒体の中に格納されてもよい。そのような理解に基づいて、この出願の複数の実施形態における複数の技術的解決方法は、本質的に、或いは、従来の技術に寄与する部分、或いは、それらの複数の技術的解決方法のうちのすべて又は一部は、ソフトウェア製品の形態で実装されてもよい。ソフトウェア製品は、記憶媒体の中に格納され、そして、いくつかの命令を含み、それらのいくつかの命令は、この出願の複数の実施形態の中で説明されている方法の複数のステップのすべて又は一部を実行するように、(シングルチップマイクロコンピュータ又はチップ等であってもよい)デバイス又はプロセッサ(processor)に指示する。上記の記憶媒体は、プログラムコードを格納することが可能であるUSBフラッシュドライブ、取り外し可能なハードディスク、ROM、RAM、磁気ディスク、又は光ディスク等の任意の媒体を含む。

【0274】

上記の説明は、この出願の具体的な実装であるにすぎず、この出願の保護の範囲を限定することを意図してはいない。この出願によって開示されている技術的範囲において、当業者が容易に考え出すことが可能であるいずれかの変更又は置換は、この出願の保護の範囲に属するものとする。したがって、この出願の保護の範囲は、請求項に記載された発明の保護の範囲にしたがうものとする。

【図1】

【図2】

【図3】

【図4A】

【図4B】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】