特表2025-505264 | 知財ポータル「IP Force」

知財求人 - 知財ポータルサイト「IP Force」

▶ 北京小米移動軟件有限公司の特許一覧

特表2025-505264端末支援情報報告方法、取得方法及びその装置

書誌要約請求の範囲詳細な説明課題実施例実施するための形態図面の説明

目に優しい文字サイズ小中大 PDF Top

< >

1
2
3
4
5
6
7
8
9
10
11

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

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

(11)【公表番号】

(43)【公表日】2025-02-21

(54)【発明の名称】端末支援情報報告方法、取得方法及びその装置

(51)【国際特許分類】

H04W 72/25 20230101AFI20250214BHJP

H04W 92/18 20090101ALI20250214BHJP

H04W 76/14 20180101ALI20250214BHJP

H04W 28/06 20090101ALI20250214BHJP

【ＦＩ】

H04W72/25

H04W92/18

H04W76/14

H04W28/06 110

【審査請求】有

【予備審査請求】未請求

(21)【出願番号】P 2024547715

(86)(22)【出願日】2022-02-14

(85)【翻訳文提出日】2024-09-02

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

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

(87)【国際公開日】2023-08-17

(81)【指定国・地域】

(71)【出願人】

【識別番号】516180667

【氏名又は名称】北京小米移動軟件有限公司

【氏名又は名称原語表記】ＢｅｉｊｉｎｇＸｉａｏｍｉＭｏｂｉｌｅＳｏｆｔｗａｒｅＣｏ．，Ｌｔｄ．

【住所又は居所原語表記】Ｎｏ．０１８，Ｆｌｏｏｒ８，Ｂｕｉｌｄｉｎｇ６，Ｙａｒｄ３３，ＭｉｄｄｌｅＸｉｅｒｑｉＲｏａｄ，ＨａｉｄｉａｎＤｉｓｔｒｉｃｔ，Ｂｅｉｊｉｎｇ１０００８５，Ｃｈｉｎａ

(74)【代理人】

【識別番号】100079108

【弁理士】

【氏名又は名称】稲葉良幸

(74)【代理人】

【識別番号】100109346

【弁理士】

【氏名又は名称】大貫敏史

(74)【代理人】

【識別番号】100117189

【弁理士】

【氏名又は名称】江口昭彦

(74)【代理人】

【識別番号】100134120

【弁理士】

【氏名又は名称】内藤和彦

(74)【代理人】

【識別番号】100108213

【弁理士】

【氏名又は名称】阿部豊隆

(72)【発明者】

【氏名】ヤン，シン

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

5K067

【Ｆターム（参考）】

5K067AA13

5K067DD17

5K067EE02

5K067EE10

5K067EE22

5K067EE25

(57)【要約】

本願の実施例は端末支援情報報告方法、取得方法及びその装置を開示し、カーネットワーク、Ｖ２Ｘなどのシステムに適用可能であり、この方法は、第１の端末デバイスがネットワーク側デバイスにサイドリンク（ＳＬ）リソース要求情報リスト及び支援情報リストを送信するステップであって、リソース要求情報リストに第２の端末デバイスの複数のリソース要求が含まれ、第２の端末デバイスのリソース要求に第２の端末デバイスの宛先アドレスが含まれ、支援情報リストに第２の端末デバイスの支援情報が含まれ、支援情報はインデックス識別子により支援情報に対応する端末デバイス識別子を決定することを含み、支援情報に対応する端末デバイス識別子は、リソース要求情報リストにおけるインデックス識別子位置に位置するリソース要求内の宛先アドレスである（３０１）。本願の実施例の実施により、サイドリンク（ＳＬ）リソース要求情報リストにおける既存の宛先アドレスフィールドによって、支援情報が適用される第２の端末デバイスの指示を実現し、支援情報の報告のシグナリングオーバーヘッドを節約することができる。
【選択図】図３

【特許請求の範囲】

【請求項1】

第１の端末デバイスによって実行される支援情報報告方法であって、
ネットワーク側デバイスにサイドリンク（ＳＬ）リソース要求情報リスト及び支援情報リストを送信するステップであって、前記リソース要求情報リストに第２の端末デバイスのリソース要求が含まれ、前記第２の端末デバイスのリソース要求に前記第２の端末デバイスの宛先アドレスが含まれ、前記支援情報リストに支援情報が含まれ、前記支援情報はインデックス識別子により前記支援情報に対応する端末デバイス識別子を決定するステップを含み、
前記支援情報に対応する端末デバイス識別子は、リソース要求情報リストにおけるインデックス識別子位置に位置するリソース要求内の宛先アドレスである、
ことを特徴とする支援情報報告方法。

【請求項2】

前記インデックス識別子は前記支援情報に含まれている、
ことを特徴とする請求項１に記載の支援情報報告方法。

【請求項3】

第２の端末デバイスの宛先アドレスに対応するリソース要求の前記リソース要求情報リストにおけるインデックス位置に基づいて、前記インデックス識別子をセットするステップをさらに含む、
ことを特徴とする請求項２に記載の支援情報報告方法。

【請求項4】

前記インデックス識別子は支援情報の前記支援情報リストにおける位置によって決定される、
ことを特徴とする請求項１に記載の支援情報報告方法。

【請求項5】

第２の端末デバイスの宛先アドレスに対応するリソース要求の前記リソース要求情報リストにおけるインデックス位置に基づいて、支援情報を前記支援情報リストにおける同じインデックス位置にセットするステップであって、前記支援情報リストは、前記リソース要求情報リストと同じ長さであるステップをさらに含む、
ことを特徴とする請求項４に記載の支援情報報告方法。

【請求項6】

前記支援情報は第２の端末デバイスのページング識別子を含み、前記第２の端末デバイスはリモート端末デバイスである、
ことを特徴とする請求項１～５のいずれかに記載の支援情報報告方法。

【請求項7】

前記支援情報はサイドリンク不連続受信（ＳＬＤＲＸ）設定を含み、前記サイドリンク不連続受信（ＳＬＤＲＸ）設定は、前記第１の端末デバイスによって受信された、第２の端末デバイスから送信されたＳＬＤＲＸ設定であり、かつ前記第１の端末デバイスが前記ＳＬＤＲＸ設定を受容する、
ことを特徴とする請求項１～５のいずれかに記載の支援情報報告方法。

【請求項8】

前記支援情報は受信されたＳＬＤＲＸ支援情報を含み、前記ＳＬＤＲＸ支援情報は、前記第１の端末デバイスによって受信された、第２の端末デバイスから送信されたＳＬＤＲＸ支援情報である、
ことを特徴とする１～５のいずれかに記載の支援情報報告方法。

【請求項9】

ネットワーク側デバイスによって実行される支援情報取得方法であって、
第１の端末デバイスから送信されたサイドリンク（ＳＬ）リソース要求情報リスト及び支援情報リストを受信するステップであって、前記リソース要求情報リストに第２の端末デバイスのリソース要求が含まれ、前記第２の端末デバイスのリソース要求に前記第２の端末デバイスの宛先アドレスが含まれ、前記支援情報リストに支援情報が含まれ、前記支援情報はインデックス識別子により前記支援情報に対応する端末デバイス識別子を決定するステップを含み、
前記支援情報に対応する端末デバイス識別子は、リソース要求情報リストにおけるインデックス識別子位置に位置するリソース要求内の宛先アドレスである、
ことを特徴とする支援情報取得方法。

【請求項10】

前記支援情報には、前記リソース要求情報リストを検索するためのインデックス識別子が含まれている、
ことを特徴とする請求項９に記載の支援情報取得方法。

【請求項11】

前記インデックス識別子は支援情報の前記支援情報リストにおける位置によって決定される、
ことを特徴とする請求項９に記載の支援情報取得方法。

【請求項12】

受信された前記支援情報リストにおけるインデックス識別子に基づいて、前記リソース要求情報リストにおける前記インデックス識別子位置に位置するリソース要求内の宛先アドレスを決定するステップであって、前記インデックス識別子に対応する支援情報は、前記宛先アドレスに対応する第２の端末デバイスに適用されるステップをさらに含む、
ことを特徴とする請求項９～１１のいずれかに記載の支援情報取得方法。

【請求項13】

前記支援情報はページング識別子であり、
前記方法は、
前記宛先アドレスが前記ページング識別子であるページングメッセージを前記第１の端末デバイスに送信して報告するステップをさらに含む、
ことを特徴とする請求項９～１１のいずれかに記載の支援情報取得方法。

【請求項14】

前記支援情報はサイドリンク不連続受信（ＳＬＤＲＸ）設定であり、
前記方法は、
前記宛先アドレスに対応する第２の端末デバイスのアクティブ化時間内に、前記宛先アドレスに対応する第２の端末デバイスへのサイドリンク送信リソースをスケジューリングするステップをさらに含む、
ことを特徴とする請求項９～１１のいずれかに記載の支援情報取得方法。

【請求項15】

前記支援情報はＳＬＤＲＸ支援情報であり、ＳＬＤＲＸ支援情報はアドバイスされたＳＬＤＲＸ設定を含み、
前記方法は、
前記ＳＬＤＲＸ支援情報に基づいて、前記宛先アドレスに対応する第２の端末デバイスのＳＬＤＲＸ設定を決定するステップをさらに含む、
ことを特徴とする請求項９～１１のいずれかに記載の支援情報取得方法。

【請求項16】

通信装置であって、
ネットワーク側デバイスにサイドリンク（ＳＬ）リソース要求情報リスト及び支援情報リストを送信するための送受信モジュールであって、前記リソース要求情報リストに第２の端末デバイスのリソース要求が含まれ、前記第２の端末デバイスのリソース要求に前記第２の端末デバイスの宛先アドレスが含まれ、前記支援情報リストに支援情報が含まれ、前記支援情報はインデックス識別子により前記支援情報に対応する端末デバイス識別子を決定する送受信モジュールを含み、
前記支援情報に対応する端末デバイス識別子は、リソース要求情報リストにおけるインデックス識別子位置に位置するリソース要求内の宛先アドレスである、
ことを特徴とする通信装置。

【請求項17】

前記インデックス識別子は前記支援情報に含まれている、
ことを特徴とする請求項１６に記載の通信装置。

【請求項18】

第２の端末デバイスの宛先アドレスに対応するリソース要求の前記リソース要求情報リストにおけるインデックス位置に基づいて、前記インデックス識別子をセットするための処理モジュールをさらに含む、
ことを特徴とする請求項１７に記載の通信装置。

【請求項19】

前記インデックス識別子は支援情報の前記支援情報リストにおける位置によって決定される、
ことを特徴とする請求項１６に記載の通信装置。

【請求項20】

第２の端末デバイスの宛先アドレスに対応するリソース要求の前記リソース要求情報リストにおけるインデックス位置に基づいて、支援情報を前記支援情報リストにおける同じインデックス位置にセットするための処理モジュールであって、前記支援情報リストは、前記リソース要求情報リストと同じ長さである処理モジュールをさらに含む、
ことを特徴とす請求項１９に記載の通信装置。

【請求項21】

前記支援情報は第２の端末デバイスのページング識別子を含み、前記第２の端末デバイスはリモート端末デバイスである、
ことを特徴とする請求項１６～２０のいずれかに記載の通信装置。

【請求項22】

前記支援情報はサイドリンク不連続受信（ＳＬＤＲＸ）設定を含み、前記サイドリンク不連続受信（ＳＬＤＲＸ）設定は、前記第１の端末デバイスによって受信された、第２の端末デバイスから送信されたＳＬＤＲＸ設定であり、かつ前記第１の端末デバイスが前記ＳＬＤＲＸ設定を受容する、
ことを特徴とする請求項１６～２０のいずれかに記載の通信装置。

【請求項23】

前記支援情報は受信されたＳＬＤＲＸ支援情報を含み、前記ＳＬＤＲＸ支援情報は、前記第１の端末デバイスによって受信された、第２の端末デバイスから送信されたＳＬＤＲＸ支援情報である、
ことを特徴とする請求項１６～２０のいずれかに記載の通信装置。

【請求項24】

通信装置であって、
第１の端末デバイスから送信されたサイドリンク（ＳＬ）リソース要求情報リスト及び支援情報リストを受信するための送受信モジュールであって、前記リソース要求情報リストに第２の端末デバイスのリソース要求が含まれ、前記第２の端末デバイスのリソース要求に前記第２の端末デバイスの宛先アドレスが含まれ、前記支援情報リストに支援情報が含まれ、前記支援情報はインデックス識別子により前記支援情報に対応する端末デバイス識別子を決定する送受信モジュールを含み、
前記支援情報に対応する端末デバイス識別子は、リソース要求情報リストにおけるインデックス識別子位置に位置するリソース要求内の宛先アドレスである、
ことを特徴とする通信装置。

【請求項25】

前記支援情報には、前記リソース要求情報リストを検索するためのインデックス識別子が含まれている、
ことを特徴とする請求項２４に記載の通信装置。

【請求項26】

前記インデックス識別子は支援情報の前記支援情報リストにおける位置によって決定される、
ことを特徴とする請求項２４に記載の通信装置。

【請求項27】

受信された前記支援情報リストにおけるインデックス識別子に基づいて、前記リソース要求情報リストにおける前記インデックス識別子位置に位置するリソース要求内の宛先アドレスを決定するための処理モジュールであって、前記インデックス識別子に対応する支援情報は、前記宛先アドレスに対応する第２の端末デバイスに適用される処理モジュールをさらに含む、
ことを特徴とする請求項２６に記載の通信装置。

【請求項28】

前記支援情報はページング識別子であり、
前記送受信モジュールがさらに、前記宛先アドレスが前記ページング識別子であるページングメッセージを前記第１の端末デバイスに送信して報告する、
ことを特徴とする請求項２４～２６のいずれかに記載の通信装置。

【請求項29】

前記支援情報はサイドリンク不連続受信（ＳＬＤＲＸ）設定であり、
前記送受信モジュールがさらに、前記宛先アドレスに対応する第２の端末デバイスのアクティブ化時間内に、前記宛先アドレスに対応する第２の端末デバイスへのサイドリンク送信リソースをスケジューリングする、
ことを特徴とする請求項２４～２６のいずれかに記載の通信装置。

【請求項30】

前記支援情報はＳＬＤＲＸ支援情報であり、ＳＬＤＲＸ支援情報はアドバイスされたＳＬＤＲＸ設定を含み、
前記処理モジュールがさらに、前記ＳＬＤＲＸ支援情報に基づいて、前記宛先アドレスに対応する第２の端末デバイスのＳＬＤＲＸ設定を決定する、
ことを特徴とする請求項２４～２６のいずれかに記載の通信装置。

【請求項31】

通信装置であって、
プロセッサとメモリとを含み、
前記メモリにはコンピュータプログラムが記憶され、前記プロセッサは前記メモリに記憶されるコンピュータプログラムを実行することにより、前記装置に請求項１～８のいずれかに記載の方法を実行させる、
ことを特徴とする通信装置。

【請求項32】

通信装置であって、
プロセッサとメモリとを含み、
前記メモリにはコンピュータプログラムが記憶され、前記プロセッサは前記メモリに記憶されるコンピュータプログラムを実行することにより、前記装置に請求項９～１５のいずれかに記載の方法を実行させる、
ことを特徴とする通信装置。

【請求項33】

命令が記憶されているコンピュータ読み取り可能な記憶媒体であって、
前記命令が実行される場合、請求項１～８のいずれかに記載の方法が実現される、
ことを特徴とするコンピュータ読み取り可能な記憶媒体。

【請求項34】

命令が記憶されているコンピュータ読み取り可能な記憶媒体であって、
前記命令が実行される場合、請求項９～１５のいずれかに記載の方法が実現される、
ことを特徴とするコンピュータ読み取り可能な記憶媒体。

【発明の詳細な説明】

【技術分野】

【0001】

本願は通信技術の分野に関し、特に端末支援情報報告方法、取得方法及びその装置に関する。

【背景技術】

【0002】

端末デバイスと端末デバイスとの間の直接通信をサポートするために、サイドリンク（ｓｉｄｅｌｉｎｋ、ＳＬとも呼ばれる）通信方式が導入されており、端末デバイスと端末デバイスとの間のインターフェースはＰＣ－５（サイドリンク通信）インターフェースとなっている。送信端末デバイスと受信端末デバイスの対応関係により、ｓｉｄｅｌｉｎｋではユニキャスト、マルチキャスト及びブロードキャストという３つの伝送方式がサポートされている。接続状態にある第１の端末デバイスがサイドリンクで通信する場合、Ｓｉｄｅｌｉｎｋ送信リソース要求情報リストが含まれるＳｉｄｅｌｉｎｋＵＥＩｎｆｏｒｍａｔｉｏｎ（サイドリンク通信端末情報）メッセージをネットワーク側デバイス（例えば基地局）に送信する必要がある。

【0003】

関連技術では、第１の端末デバイスがネットワーク側デバイスにサイドリンク送信リソース要求情報リストを報告する場合、サイドリンク送信リソース要求情報リストにおける送信リソース要求内の宛先アドレスフィールドを用いて、ユニキャストで接続された第２の端末デバイスの識別子を指示するが、現在このサイドリンク送信リソース要求情報リストというシグナリングを拡張することができないため、このサイドリンク送信リソース要求情報リストに、ページング識別子、サイドリンク不連続受信（ＳＬＤＲＸ）支援情報及びＳＬＤＲＸ設定などの支援情報を指示するためのフィールドを追加することができない。第１の端末デバイスによって報告されるページング識別子、ＳＬＤＲＸ支援情報及びＳＬＤＲＸ設定などの支援情報に第２の端末デバイスの宛先アドレス（識別子とも呼ばれる）を追加すると、大量のシグナリングオーバーヘッドが増加する。そのため、ページング識別子、ＳＬＤＲＸ支援情報及びＳＬＤＲＸ設定などの支援情報をどのように指示して、シグナリングオーバーヘッドを低減する目的を達成するかは、早急に解決すべき問題となっている。

【発明の概要】

【発明が解決しようとする課題】

【0004】

本願の実施例は、端末支援情報報告方法、取得方法及びその装置を提供し、支援情報の報告のシグナリングオーバーヘッドを節約することができる。

【課題を解決するための手段】

【0005】

第１の態様によれば、本願の実施例は端末支援情報報告方法を提供し、前記方法は第１の端末デバイスによって実行され、前記方法は、
ネットワーク側デバイスにサイドリンク（ＳＬ）リソース要求情報リスト及び支援情報リストを送信するステップであって、ここで、前記リソース要求情報リストに第２の端末デバイスのリソース要求が含まれ、前記第２の端末デバイスのリソース要求に前記第２の端末デバイスの宛先アドレスが含まれ、前記支援情報リストに支援情報が含まれ、前記支援情報はインデックス識別子により前記支援情報に対応する端末デバイス識別子を決定するステップを含み、
ここで、前記支援情報に対応する端末デバイス識別子は、リソース要求情報リストにおけるインデックス識別子位置に位置するリソース要求内の宛先アドレスである。

【0006】

本技術案では、支援情報に対応するインデックス識別子によって該支援情報とリソース要求情報リストにおける第２の端末デバイスの宛先アドレスとのマッピング関係を構築することにより、ネットワーク側デバイスがこのマッピング関係に基づいて、第１の端末デバイスから送信された支援情報が適用される第２の端末を特定するようにし、これにより、リソース要求情報リストにおける既存の宛先アドレスフィールドによって、支援情報が適用される第２の端末デバイスの指示を実現し、支援情報の報告のシグナリングオーバーヘッドを節約することができる。

【0007】

一実現形態では、前記インデックス識別子は前記支援情報に含まれている（ｃａｒｒｙ）。

【0008】

可能な一実現形態では、前記方法は、第２の端末デバイスの宛先アドレスに対応するリソース要求の前記リソース要求情報リストにおけるインデックス位置に基づいて、前記インデックス識別子をセットするステップをさらに含む。

【0009】

一実現形態では、前記インデックス識別子は支援情報の前記支援情報リストにおける位置によって決定される。

【0010】

可能な一実現形態では、前記方法は、第２の端末デバイスの宛先アドレスに対応するリソース要求の前記リソース要求情報リストにおけるインデックス位置に基づいて、支援情報を前記支援情報リストにおける同じインデックス位置にセットするステップであって、ここで、前記支援情報リストは、前記リソース要求情報リストと同じ長さであるステップをさらに含む。

【0011】

一実現形態では、前記支援情報は第２の端末デバイスのページング識別子を含み、ここで、前記第２の端末デバイスはリモート端末デバイスである。

【0012】

一実現形態では、前記支援情報はサイドリンク不連続受信（ＳＬＤＲＸ）設定（ｃｏｎｆｉｇｕｒａｔｉｏｎ）を含み、ここで、前記サイドリンク不連続受信（ＳＬＤＲＸ）設定は、前記第１の端末デバイスによって受信された、第２の端末デバイスから送信されたＳＬＤＲＸ設定であり、かつ前記第１の端末デバイスが前記ＳＬＤＲＸ設定を受容（ａｃｃｅｐｔ）する。

【0013】

一実現形態では、前記支援情報は受信されたＳＬＤＲＸ支援情報を含み、ここで、前記ＳＬＤＲＸ支援情報は、前記第１の端末デバイスによって受信された、第２の端末デバイスから送信されたＳＬＤＲＸ支援情報である。

【0014】

第２の態様によれば、本願の実施例は端末支援情報取得方法を提供し、前記方法はネットワーク側デバイスによって実行され、前記方法は、
第１の端末デバイスから送信されたサイドリンク（ＳＬ）リソース要求情報リスト及び支援情報リストを受信する、ここで、前記リソース要求情報リストに第２の端末デバイスのリソース要求が含まれ、前記第２の端末デバイスのリソース要求に前記第２の端末デバイスの宛先アドレスが含まれ、前記支援情報リストに支援情報が含まれ、前記支援情報はインデックス識別子により前記支援情報に対応する端末デバイス識別子を決定するステップを含み、
ここで、前記支援情報に対応する端末デバイス識別子は、リソース要求情報リストにおけるインデックス識別子位置に位置するリソース要求内の宛先アドレスである。

【0015】

一実現形態では、前記支援情報には、前記リソース要求情報リストを検索するためのインデックス識別子が含まれている（ｃａｒｒｙ）。

【0016】

一実現形態では、前記インデックス識別子は支援情報の前記支援情報リストにおける位置によって決定される。

【0017】

一実現形態では、前記方法は、受信された前記支援情報リストにおけるインデックス識別子に基づいて、前記リソース要求情報リストにおける前記インデックス識別子位置に位置するリソース要求内の宛先アドレスを決定するステップであって、ここで、前記インデックス識別子に対応する支援情報は、前記宛先アドレスに対応する第２の端末デバイスに適用されるステップをさらに含む。

【0018】

一実現形態では、前記支援情報はページング識別子であり、前記方法は、前記宛先アドレスが前記ページング識別子であるページングメッセージを前記第１の端末デバイスに送信して報告するステップをさらに含む。

【0019】

一実現形態では、前記支援情報はサイドリンク不連続受信（ＳＬＤＲＸ）設定であり、前記方法は、
前記宛先アドレスに対応する第２の端末デバイスのアクティブ化時間内に、前記宛先アドレスに対応する第２の端末デバイスへのサイドリンク送信リソースをスケジューリングするステップをさらに含む。

【0020】

一実現形態では、前記支援情報はＳＬＤＲＸ支援情報であり、ＳＬＤＲＸ支援情報はアドバイスされたＳＬＤＲＸ設定を含み、前記方法は、
前記ＳＬＤＲＸ支援情報に基づいて、前記宛先アドレスに対応する第２の端末デバイスのＳＬＤＲＸ設定を決定するステップをさらに含む。

【0021】

第３の態様によれば、本願の実施例は通信装置を提供し、
ネットワーク側デバイスにサイドリンク（ＳＬ）リソース要求情報リスト及び支援情報リストを送信するための送受信モジュールであって、ここで、前記リソース要求情報リストに第２の端末デバイスのリソース要求が含まれ、前記第２の端末デバイスのリソース要求に前記第２の端末デバイスの宛先アドレスが含まれ、前記支援情報リストに支援情報が含まれ、前記支援情報はインデックス識別子により前記支援情報に対応する端末デバイス識別子を決定する送受信モジュールを含み、
ここで、前記支援情報に対応する端末デバイス識別子は、リソース要求情報リストにおけるインデックス識別子位置に位置するリソース要求内の宛先アドレスである。

【0022】

一実現形態では、前記インデックス識別子は前記支援情報に含まれている。

【0023】

一実現形態では、前記通信装置は、第２の端末デバイスの宛先アドレスに対応するリソース要求の前記リソース要求情報リストにおけるインデックス位置に基づいて、前記インデックス識別子をセットするための処理モジュールをさらに含む。

【0024】

一実現形態では、前記インデックス識別子は支援情報の前記支援情報リストにおける位置によって決定される。

【0025】

一実現形態では、前記通信装置は、
第２の端末デバイスの宛先アドレスに対応するリソース要求の前記リソース要求情報リストにおけるインデックス位置に基づいて、支援情報を前記支援情報リストにおける同じインデックス位置にセットするための処理モジュールをさらに含み、ここで、前記支援情報リストは、前記リソース要求情報リストと同じ長さである。

【0026】

【0027】

一実現形態では、前記支援情報はサイドリンク不連続受信（ＳＬＤＲＸ）設定を含み、ここで、前記サイドリンク不連続受信（ＳＬＤＲＸ）設定は、前記第１の端末デバイスによって受信された、第２の端末デバイスから送信されたＳＬＤＲＸ設定であり、かつ前記第１の端末デバイスが前記ＳＬＤＲＸ設定を受容する。

【0028】

【0029】

第４の態様によれば、本願の実施例は別の通信装置を提供し、
第１の端末デバイスから送信されたサイドリンク（ＳＬ）リソース要求情報リスト及び支援情報リストを受信するための送受信モジュールであって、ここで、前記リソース要求情報リストに第２の端末デバイスのリソース要求が含まれ、前記第２の端末デバイスのリソース要求に前記第２の端末デバイスの宛先アドレスが含まれ、前記支援情報リストに支援情報が含まれ、前記支援情報はインデックス識別子により前記支援情報に対応する端末デバイス識別子を決定する送受信モジュールを含み、
ここで、前記支援情報に対応する端末デバイス識別子は、リソース要求情報リストにおけるインデックス識別子位置に位置するリソース要求内の宛先アドレスである。

【0030】

一実現形態では、前記支援情報には、前記リソース要求情報リストを検索するためのインデックス識別子が含まれている。

【0031】

一実現形態では、前記インデックス識別子は支援情報の前記支援情報リストにおける位置によって決定される。

【0032】

可能な一実現形態では、前記通信装置は、
受信された前記支援情報リストにおけるインデックス識別子に基づいて、前記リソース要求情報リストにおける前記インデックス識別子位置に位置するリソース要求内の宛先アドレスを決定するための処理モジュールをさらに含み、ここで、前記インデックス識別子に対応する支援情報は、前記宛先アドレスに対応する第２の端末デバイスに適用される。

【0033】

一実現形態では、前記支援情報はページング識別子であり、前記送受信モジュールはさらに前記宛先アドレスが前記ページング識別子であるページングメッセージを前記第１の端末デバイスに送信して報告する。

【0034】

一実現形態では、前記支援情報はサイドリンク不連続受信（ＳＬＤＲＸ）設定であり、前記送受信モジュールはさらに、前記宛先アドレスに対応する第２の端末デバイスのアクティブ化時間内に、前記宛先アドレスに対応する第２の端末デバイスへのサイドリンク送信リソースをスケジューリングする。

【0035】

一実現形態では、前記支援情報はＳＬＤＲＸ支援情報であり、ＳＬＤＲＸ支援情報はアドバイスされたＳＬＤＲＸ設定を含み、前記処理モジュールはさらに、前記ＳＬＤＲＸ支援情報に基づいて、前記宛先アドレスに対応する第２の端末デバイスのＳＬＤＲＸ設定を決定する。

【0036】

第５の態様によれば、本願の実施例は別の端末支援情報報告方法を提供し、前記方法は第１の端末デバイスによって実行され、前記方法は、
ネットワーク側デバイスにサイドリンク（ＳＬ）リソース要求情報リスト及び支援情報リストを送信するステップであって、ここで、前記リソース要求情報リストに複数のリソース要求が含まれ、１つのリソース要求が１つのインデックス位置に対応し、前記支援情報リストに第２の端末デバイスの支援情報、及び前記支援情報に対応するインデックス識別子が含まれ、ここで、前記インデックス識別子は、前記リソース要求に対応するインデックス位置と対応しているステップを含む。

【0037】

【0038】

一実現形態では、前記インデックス識別子は対応する支援情報に含まれている（ｃａｒｒｙ）。

【0039】

可能な一実現形態では、前記方法は、前記リソース要求の前記リソース要求情報リストにおけるインデックス位置を決定するステップと、前記インデックス位置に基づいて、前記支援情報リストにおいて、前記支援情報に対応するインデックス識別子をセットするステップと、をさらに含む。

【0040】

可能な一実現形態では、前記支援情報リストは、前記リソース要求情報リストと同じ長さであり、前記リソース要求の前記リソース要求情報リストにおけるインデックス位置は、前記支援情報の前記支援情報リストにおけるインデックス位置と同じである。

【0041】

選択的な一実現形態では、前記方法は、前記支援情報を決定するステップをさらに含む。

【0042】

選択的な一実現形態では、前記支援情報は、
前記第２の端末デバイスから送信されたページング識別子と、前記第２の端末デバイスから送信されたサイドリンク不連続受信（ＳＬＤＲＸ）設定情報と、前記第２の端末デバイスから送信されたＳＬＤＲＸ支援情報とのうちの１つであり、ここで、ＳＬＤＲＸ支援情報はアドバイスされたＳＬＤＲＸ設定情報を含む。

【0043】

第６の態様によれば、本願の実施例は別の端末支援情報取得方法を提供し、前記方法はネットワーク側デバイスによって実行され、前記方法は、
第１の端末デバイスから送信されたサイドリンク（ＳＬ）リソース要求情報リスト及び支援情報リストを受信するステップであって、ここで、前記リソース要求情報リストに複数のリソース要求が含まれ、１つのリソース要求が１つのインデックス位置に対応し、前記支援情報リストに第２の端末デバイスの支援情報、及び前記支援情報に対応するインデックス識別子が含まれ、ここで、前記インデックス識別子は、前記リソース要求に対応するインデックス位置と対応しているステップと、
前記インデックス識別子に基づいて前記リソース要求を決定するステップと、
前記リソース要求内の宛先アドレスを取得するステップであって、ここで、前記宛先アドレスを有する端末デバイスは前記第２の端末デバイスであるステップと、を含む。

【0044】

【0045】

一実現形態では、前記インデックス識別子は対応する支援情報に含まれている。

【0046】

【0047】

可能な一実現形態では、前記支援情報はページング識別子であり、前記方法は、前記ページング識別子のページングメッセージを決定するステップと、前記ページングメッセージを前記第１の端末デバイスを介して前記第２の端末デバイスに送信するステップと、をさらに含む。

【0048】

選択的な一実現形態では、前記支援情報はサイドリンク不連続受信（ＳＬＤＲＸ）設定であり情報、前記方法は、前記第２の端末デバイスのアクティブ化時間内に、前記ＳＬＤＲＸ設定情報に基づいて、前記第２の端末デバイスへのサイドリンク送信リソースをスケジューリングするステップをさらに含む。

【0049】

選択的な一実現形態では、前記支援情報はＳＬＤＲＸ支援情報であり、ＳＬＤＲＸ支援情報はアドバイスされたＳＬＤＲＸ設定情報を含み、前記方法は、前記ＳＬＤＲＸ支援情報に基づいて、前記第２の端末デバイスのＳＬＤＲＸ設定情報を決定するステップをさらに含む。

【0050】

第７の態様によれば、本願の実施例はは、上記第１の態様に記載の方法における端末デバイスの一部または全部の機能を実現する通信装置を提供し、例えば、通信装置の機能は本願の一部または全部の実施例の機能を備えていてもよいし、本願のいずれかの実施例を単独で実施する機能を備えていてもよい。前記機能は、ハードウェアで実現されてもよいし、ハードウェアが対応するソフトウェアを実行することで実現されてもよい。前記ハードウェアまたはソフトウェアは、上記の機能に対応する１つまたは複数のユニットまたはモジュールを含む。

【0051】

一実現形態では、通信装置の構成には、送受信モジュールと、通信装置が上記の方法で対応する機能を実行することをサポートするように構成される処理モジュールとが含まれてもよい。前記送受信モジュールは、通信装置と他のデバイスとの間の通信をサポートするために使用される。前記通信装置は、送受信モジュールと処理モジュールとに結合し、通信装置に必要なコンピュータプログラムとデータを保存するための記憶モジュールをさらに含んでもよい。

【0052】

一例として、処理モジュールはプロセッサであってもよく、送受信モジュールはトランシーバまたは通信インターフェースであってもよく、記憶モジュールはメモリであってもよい。

【0053】

第８の態様によれば、本願の実施例はは、上記第２の態様に記載の方法におけるネットワークデバイスの一部または全部の機能を実現する通信装置を提供し、例えば、通信装置の機能は本願の一部または全部の実施例の機能を備えていてもよいし、本願のいずれかの実施例を単独で実施する機能を備えていてもよい。前記機能は、ハードウェアで実現されてもよいし、ハードウェアが対応するソフトウェアを実行することで実現されてもよい。前記ハードウェアまたはソフトウェアは、上記の機能に対応する１つまたは複数のユニットまたはモジュールを含む。

【0054】

【0055】

【0056】

第９の態様によれば、本願の実施例は通信装置を提供し、該通信装置はプロセッサを含み、当該プロセッサはメモリにおけるコンピュータプログラムを呼び出すと、上記第１の態様に記載の方法を実行する。

【0057】

第１０の態様によれば、本願の実施例は通信装置を提供し、該通信装置はプロセッサを含み、当該プロセッサはメモリにおけるコンピュータプログラムを呼び出すと、上記第２の態様に記載の方法を実行する。

【0058】

第１１の態様によれば、本願の実施例は通信装置を提供し、該通信装置はプロセッサを含み、当該プロセッサはメモリにおけるコンピュータプログラムを呼び出すと、上記第５の態様に記載の方法を実行する。

【0059】

第１２の態様によれば、本願の実施例は通信装置を提供し、該通信装置はプロセッサを含み、当該プロセッサはメモリにおけるコンピュータプログラムを呼び出すと、上記第６の態様に記載の方法を実行する。

【0060】

第１３の態様によれば、本願の実施例は通信装置を提供し、該通信装置はプロセッサとメモリとを含み、該メモリにはコンピュータプログラムが記憶され、前記プロセッサは該メモリに記憶されているコンピュータプログラムを実行することにより、該通信装置に上記第１の態様に記載の方法を実行させる。

【0061】

第１４の態様によれば、本願の実施例は通信装置を提供し、該通信装置はプロセッサとメモリとを含み、該メモリにはコンピュータプログラムが記憶され、前記プロセッサは該メモリに記憶されているコンピュータプログラムを実行することにより、該通信装置に上記第２の態様に記載の方法を実行させる。

【0062】

第１５の態様によれば、本願の実施例は通信装置を提供し、該通信装置はプロセッサとメモリとを含み、該メモリにはコンピュータプログラムが記憶され、前記プロセッサは該メモリに記憶されているコンピュータプログラムを実行することにより、該通信装置に上記第５の態様に記載の方法を実行させる。

【0063】

第１６の態様によれば、本願の実施例は通信装置を提供し、該通信装置はプロセッサとメモリとを含み、該メモリにはコンピュータプログラムが記憶され、前記プロセッサは該メモリに記憶されているコンピュータプログラムを実行することにより、該通信装置に上記第６の態様に記載の方法を実行させる。

【0064】

第１７の態様によれば、本願の実施例は通信装置を提供し、該装置はプロセッサとインターフェース回路とを含み、該インターフェース回路はコード命令を受信して該プロセッサに伝送し、該プロセッサは前記コード命令を実行することにより、該装置に上記第１の態様に記載の方法を実行させる。

【0065】

第１８の態様によれば、本願の実施例は通信装置を提供し、該装置はプロセッサとインターフェース回路とを含み、該インターフェース回路はコード命令を受信して該プロセッサに伝送し、該プロセッサは前記コード命令を実行することにより、該装置に上記第２の態様に記載の方法を実行させる。

【0066】

第１９の態様によれば、本願の実施例は通信装置を提供し、該装置はプロセッサとインターフェース回路とを含み、該インターフェース回路はコード命令を受信して該プロセッサに伝送し、該プロセッサは前記コード命令を実行することにより、該装置に上記第５の態様に記載の方法を実行させる。

【0067】

第２０の態様によれば、本願の実施例は通信装置を提供し、該装置はプロセッサとインターフェース回路とを含み、該インターフェース回路はコード命令を受信して該プロセッサに伝送し、該プロセッサは前記コード命令を実行することにより、該装置に上記第６の態様に記載の方法を実行させる。

【0068】

第２１の態様によれば、本願の実施例は通信システムを提供し、該システムは第３の態様に記載の通信装置及び第４の態様に記載の通信装置を含み、または、該システムは第７の態様に記載の通信装置及び第８の態様に記載の通信装置を含み、または、該システムは第９の態様に記載の通信装置及び第１０の態様に記載の通信装置を含み、または、該システムは第１１の態様に記載の通信装置及び第１２の態様に記載の通信装置を含み、または、第１３の態様に記載の通信装置及び第１４の態様に記載の通信装置を含み、または、該システムは第１５の態様に記載の通信装置及び第１６の態様に記載の通信装置を含み、または、該システムは第１７の態様に記載の通信装置及び第１８の態様に記載の通信装置を含み、または、該システムは第１９の態様に記載の通信装置及び第２０の態様に記載の通信装置を含む。

【0069】

第２２の態様によれば、本発明の実施例は、上記端末デバイスによって使用される命令を記憶するためのコンピュータ読み取り可能な記憶媒体を提供し、前記命令が実行される場合、前記端末デバイスに上記第１の態様に記載の方法を実行させる。

【0070】

第２３の態様によれば、本発明の実施例は、上記端末デバイスによって使用される命令を記憶するためのコンピュータ読み取り可能な記憶媒体を提供し、前記命令が実行される場合、前記端末デバイスに上記第２の態様に記載の方法を実行させる。

【0071】

第２４の態様によれば、本発明の実施例は、上記端末デバイスによって使用される命令を記憶するためのコンピュータ読み取り可能な記憶媒体を提供し、前記命令が実行される場合、前記端末デバイスに上記第５の態様に記載の方法を実行させる。

【0072】

第２５の態様によれば、本発明の実施例は、上記端末デバイスによって使用される命令を記憶するためのコンピュータ読み取り可能な記憶媒体を提供し、前記命令が実行される場合、前記端末デバイスに上記第６の態様に記載の方法を実行させる。

【0073】

第２６の態様によれば、本願は、コンピュータプログラムを含むコンピュータプログラム製品をさらに提供し、それがコンピュータで実行される場合、コンピュータに上記第１の態様に記載の方法を実行させる。

【0074】

第２７の態様によれば、本願は、コンピュータプログラムを含むコンピュータプログラム製品をさらに提供し、それがコンピュータで実行される場合、コンピュータに上記第２の態様に記載の方法を実行させる。

【0075】

第２８の態様によれば、本願は、コンピュータプログラムを含むコンピュータプログラム製品をさらに提供し、それがコンピュータで実行される場合、コンピュータに上記第５の態様に記載の方法を実行させる。

【0076】

第２９の態様によれば、本願は、コンピュータプログラムを含むコンピュータプログラム製品をさらに提供し、それがコンピュータで実行される場合、コンピュータに上記第６の態様に記載の方法を実行させる。

【0077】

第３０の態様によれば、本願は、コンピュータプログラムを提供し、それがコンピュータで実行される場合、コンピュータに上記第１の態様に記載の方法を実行させる。

【0078】

第３１の態様によれば、本願は、コンピュータプログラムを提供し、それがコンピュータで実行される場合、コンピュータに上記第２の態様に記載の方法を実行させる。

【0079】

第３２の態様によれば、本願は、コンピュータプログラムを提供し、それがコンピュータで実行される場合、コンピュータに上記第５の態様に記載の方法を実行させる。

【0080】

第３３の態様によれば、本願は、コンピュータプログラムを提供し、それがコンピュータで実行される場合、コンピュータに上記第６の態様に記載の方法を実行させる。

【図面の簡単な説明】

【0081】

本願の実施例又は背景技術における技術案をよりはっきりと説明するために、以下、本願の実施例又は背景技術において使用する必要がある図面を説明する。

【図1】本願の実施例によって提供されるサイドリンク通信端末情報の概略図である。

【図2】本願の実施例によって提供される通信システムのアーキテクチャの概略図である。

【図3】本願の実施例によって提供される端末支援情報報告方法の概略フローチャートである。

【図4】本願の実施例によって提供される別の端末支援情報報告方法の概略フローチャートである。

【図5】本願の実施例によって提供される更なる端末支援情報報告方法の概略フローチャートである。

【図6】本願の実施例によって提供される更なる端末支援情報報告方法の概略フローチャートである。

【図7】本願の実施例によって提供される別の端末支援情報報告方法の概略フローチャートである。

【図8】本願の実施例によって提供される端末支援情報取得方法の概略フローチャートである。

【図9】本願の実施例によって提供される別の端末支援情報取得方法の概略フローチャートである。

【図10】本願の実施例によって提供される通信装置の概略構成図である。

【図11】本願の実施例によって提供される別の通信装置の概略構成図である。

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

【0082】

以下、本願の実施例について詳細に説明し、実施例の例は図面に示されており、最初から最後まで同一または類似の符号は同一または類似の要素または同一または類似の機能を有する要素を示す。以下に添付の図面を参照して説明される実施例は例示的なものであり、本願を説明するためのものであり、本願の制限と理解されてはならない。ここで、本願の記述では、特に明記されていない限り、「／」はまたはの意味を表し、例えば、Ａ／ＢはＡまたはＢを表すことができ、本文の「及び／又は」は単に関連オブジェクトの関連関係を記述するものであり、３つの関係が存在できることを示している。例えば、Ａ及び／又はＢは、Ａが単独で存在し、ＡとＢが同時に存在し、Ｂが単独で存在するという３つの状況を示すことができる。

【0083】

本願の実施例で使用される用語は、特定の実施例を説明するための目的であり、本願の実施例を限定するものではない。文脈では他の意味がはっきりと示されていない限り、本願の実施例と添付の特許請求の範囲で使用される単数型の「一種」と「該」も複数型を含む。

【0084】

なお、本願の実施例では、第１、第２、第３などの用語で様々な情報を説明する可能性があるが、これらの情報はこれらの用語に限定すべきではないことを理解されたい。これらの用語は、同一のタイプの情報を互いに区別することだけに使用される。例えば、本願の実施例の範囲から逸脱しない限り、第１の情報は第２情報と呼ぶこともでき、同様に、第２情報は第１の情報と呼ぶこともできる。コンテクストによると、ここで使用される「の場合」という用語は、「……時」又は「……すると」又は「決定することに応答する」として解釈することができる。

【0085】

以下に本願の実施例を詳細に説明し、その実施例の例を図面に示す。ここで、最初から最後まで同一または類似の符号は同一または類似の要素を示す。以下に添付の図面を参照して説明する実施形態は例示的なものであり、本願を説明するためのものであり、本願を制限するものと理解することはできない。

【0086】

なお、端末デバイスと端末デバイスとの間の直接通信をサポートするために、サイドリンク（ｓｉｄｅｌｉｎｋ、ＳＬとも呼ばれる）通信方式が導入されており、端末デバイスと端末デバイスとの間のインターフェースはＰＣ－５（サイドリンク通信）インターフェースとなっている。送信端末デバイスと受信端末デバイスの対応関係により、ｓｉｄｅｌｉｎｋではユニキャスト、マルチキャスト及びブロードキャストという３つの伝送方式がサポートされている。

【0087】

接続状態にある第１の端末デバイスがサイドリンクで通信する場合、サイドリンク（ＳＬ）送信リソース要求情報リストが含まれるＳｉｄｅｌｉｎｋＵＥＩｎｆｏｒｍａｔｉｏｎ（サイドリンク通信端末情報）メッセージをネットワーク側デバイス（例えば基地局）に送信する必要がある。ここで、図１に示すように、このサイドリンク（ＳＬ）リソース要求情報リストにおける各エレメントは、第２の端末デバイスのサイドリンク（ＳＬ）リソース要求であり、このリソース要求には、この第２の端末デバイスの宛先アドレス、対応する伝送方式（ユニキャスト、マルチキャスト及びブロードキャストを含む）、サービス品質ＱｏＳ及びターゲット送信周波数が含まれる。

【0088】

なお、現在、一方の端末デバイスは基地局に直接接続せず、他方の端末デバイスの中継によって基地局との通信を実現することができ、ここで、基地局に接続されていない端末デバイスをリモート端末デバイス（ｒｅｍｏｔｅＵＥ）と呼び、中継機能を提供する端末デバイスを中継端末デバイス（ｒｅｌａｙＵＥ）と呼び、リモート端末デバイスと中継端末デバイスとの間はｓｉｄｅｌｉｎｋでユニキャスト通信する。

【0089】

ネットワーク側デバイスによって第２の端末デバイス（例えばリモート端末デバイス）に送信されたページングメッセージは、専用シグナリングによって第１の端末デバイス（例えば中継端末デバイス）に送信され、そして第１の端末デバイスによって第２の端末デバイスに転送されることを理解されたい。第１の端末デバイスは第２の端末デバイスのページング識別子をネットワーク側デバイスに報告する必要があり、ページング識別子はＮＧ－５Ｇ－Ｓ－ＴＭＳＩまたはＩ－ＲＮＴＩであってもよい。

【0090】

端末デバイスがサイドリンク通信を行う際のデバイス消費電力を節約するために、ｓｉｄｅｌｉｎｋ不連続受信（ＤｉｓｃｏｎｔｉｎｕｏｕｓＲｅｃｅｐｔｉｏｎ、ＤＲＸ）が導入されている。受信端末デバイスは、アクティブ化時間内のみに物理サイドリンク制御チャネル（ｐｈｙｓｉｃａｌｓｉｄｅｌｉｎｋｃｏｎｔｒｏｌｃｈａｎｎｅｌ、ＰＳＣＣＨ）をモニタし、これによって省エネの目的を達成する。

【0091】

ユニキャストのサイドリンク不連続受信（ＳＬＤＲＸ）設定情報は、送信端末デバイスによって受信端末デバイスに送信され、受信端末デバイスは、アドバイスされたＳＬＤＲＸ設定情報を含むＳＬＤＲＸ支援情報を送信端末デバイスに送信することができる。受信端末デバイスが接続状態にある場合、受信されたＳＬＤＲＸ設定情報を基地局に報告する。基地局は、ＳＬＤＲＸとＵｕ（セルラネット通信インターフェース）ＤＲＸができるだけ重なるようにＵｕＤＲＸを調整することにより、省電力化を図ることができる。送信端末デバイスが接続状態にある場合、受信されたＳＬＤＲＸ支援情報を基地局に報告する。基地局はこのＳＬＤＲＸ支援情報に基づいてＳＬＤＲＸ設定を决定する。

【0092】

関連技術では、図１に示すように、第１の端末デバイスがネットワーク側デバイスにサイドリンクリソース要求情報リストを報告する場合、サイドリンクリソース要求情報リストにおけるリソース要求内の宛先アドレスフィールドを用いて、ユニキャストで接続された第２の端末デバイスの識別子を指示するが、現在このサイドリンクリソース要求情報リストというシグナリングを拡張することができないため、このサイドリンクリソース要求情報リストに、ページング識別子、サイドリンク不連続受信（ＳＬＤＲＸ）支援情報及びＳＬＤＲＸ設定などの支援情報を指示するためのフィールドを追加することができない。第１の端末デバイスによって報告されるページング識別子、ＳＬＤＲＸ支援情報及びＳＬＤＲＸ設定などの支援情報に第２の端末デバイスの宛先アドレス（識別子とも呼ばれる）を追加すると、大量のシグナリングオーバーヘッドが増加する。そのため、ページング識別子、ＳＬＤＲＸ支援情報及びＳＬＤＲＸ設定などの支援情報をどのように指示して、シグナリングオーバーヘッドを低減する目的を達成するかは、早急に解決すべき問題となっている。

【0093】

上記の問題に基づいて、本願は端末支援情報報告方法、取得方法及びその装置を提案し、サイドリンク（ＳＬ）リソース要求情報リストにおける既存の宛先アドレスフィールドによって、支援情報が適用される第２の端末デバイスの指示を実現することができ、支援情報の報告のシグナリングオーバーヘッドを節約することができる。

【0094】

図２は本願の実施例によって提供される通信システムのアーキテクチャの概略図である。この通信システムは、１つのネットワークデバイスと２つの端末デバイスとを含むことができるが、これらに限定されず、図２に示されるデバイスの数と形態は、例示的なものだけであり、本願の実施例の限定を構成するものではなく、実際の応用では、２つ以上のネットワークデバイスと、２つ以上の端末デバイスとを含むことができる。図２に示される通信システムが１つのネットワークデバイス２０１と２つの端末デバイス２０２とを含むことを例とする。ここで、端末デバイス２０２はサイドリンクｓｉｄｅｌｉｎｋの端末デバイスである。

【0095】

なお、本願の実施例の技術案は、各種の通信システムに適用可能である。例えば、ロングタームエボリューション（ｌｏｎｇｔｅｒｍｅｖｏｌｕｔｉｏｎ、ＬＴＥ）システム、第５世代（５ｔｈｇｅｎｅｒａｔｉｏｎ、５Ｇ）移動通信システム、５Ｇ新しい無線（ｎｅｗｒａｄｉｏ、ＮＲ）システム、またはその他の未来の新型移動通信システムなどである。なお、本願の実施例におけるサイドリンクは、直接接続リンクまたは直通リンクとも呼ばれてもよい。

【0096】

本願の実施例におけるネットワークデバイス２０１は、信号を送信や受信するためのネットワーク側のエンティティである。例えば、ネットワークデバイス２０１は、進化型基地局（ｅｖｏｌｖｅｄＮｏｄｅＢ，ｅＮＢ）、送受信ポイント（ｔｒａｎｓｍｉｓｓｉｏｎｒｅｃｅｐｔｉｏｎｐｏｉｎｔ，ＴＲＰ）、ＮＲシステムにおける次世代基地局（ｎｅｘｔｇｅｎｅｒａｔｉｏｎＮｏｄｅＢ，ｇＮＢ）、他の未来移動通信システムにおける基地局またはワイヤレスフィデリティ（ｗｉｒｅｌｅｓｓｆｉｄｅｌｉｔｙ，ＷｉＦｉ）システムにおけるアクセスノードなどであってもよい。本願の実施例はネットワークデバイスによって採用される具体的な技術と具体的なデバイス形態を限定しない。本願の実施例によって提供されるネットワークデバイスは、集中ユニット（ｃｅｎｔｒａｌｕｎｉｔ、ＣＵ）と分散型ユニット（ｄｉｓｔｒｉｂｕｔｅｄｕｎｉｔ，ＤＵ）とから構成されてもよく、ここで、ＣＵは制御ユニット（ｃｏｎｔｒｏｌｕｎｉｔ）とも呼ばれ、ＣＵ?ＤＵの構造を採用して、ネットワークデバイス、例えば基地局のプロトコル層を分離し、一部のプロトコル層の機能をＣＵに集中制御させ、残りの一部又は全てのプロトコル層の機能をＤＵに分散させ、ＣＵによってＤＵを集中制御することができる。

【0097】

本願の実施例における端末デバイス２０２は、携帯電話などの信号を受信または送信するためのユーザ側のエンティティである。端末デバイスは、端末（ｔｅｒｍｉｎａｌ）、ユーザイクイップメント（ｕｓｅｒｅｑｕｉｐｍｅｎｔ、ＵＥ）、移動局（ｍｏｂｉｌｅｓｔａｔｉｏｎ、ＭＳ）、移動端末デバイス（ｍｏｂｉｌｅｔｅｒｍｉｎａｌ、ＭＴ）などとも呼ばれることができる。端末デバイスは、通信機能を備える自動車、スマートカー、携帯電話（ｍｏｂｉｌｅｐｈｏｎｅ）、ウェアラブルデバイス、タブレット（Ｐａｄ）、無線送受信機能付きパソコン、仮想現実（ｖｉｒｔｕａｌｒｅａｌｉｔｙ、ＶＲ）端末デバイス、拡張現実（ａｕｇｍｅｎｔｅｄｒｅａｌｉｔｙ、ＡＲ）端末デバイス、産業制御（ｉｎｄｕｓｔｒｉａｌｃｏｎｔｒｏｌ）の無線端末デバイス、自動運転（ｓｅｌｆ－ｄｒｉｖｉｎｇ）の無線端末デバイス、遠隔手術（ｒｅｍｏｔｅｍｅｄｉｃａｌｓｕｒｇｅｒｙ）の無線端末デバイス、スマートグリッド（ｓｍａｒｔｇｒｉｄ）の無線端末デバイス、輸送安全（ｔｒａｎｓｐｏｒｔａｔｉｏｎｓａｆｅｔｙ）の無線端末デバイス、スマートシティ（ｓｍａｒｔｃｉｔｙ）の無線端末デバイス、スマートホーム（ｓｍａｒｔｈｏｍｅ）の無線端末デバイスなどであってもよい。本願の実施例は端末デバイスによって採用される具体的な技術と具体的なデバイス形態を限定しない。

【0098】

サイドリンク通信には、４種類のサイドリンク伝送モードが存在する。サイドリンク伝送モード１とサイドリンク伝送モード２は端末デバイス間（ｄｅｖｉｃｅ－ｔｏ－ｄｅｖｉｃｅ、Ｄ２Ｄ）通信に使用される。サイドリンク伝送モード３とサイドリンク伝送モード４はＶ２Ｘ通信に使用される。サイドリンク伝送モード３を採用する場合、リソース割り当てはネットワークデバイス２０１によってスケジューリングされる。具体的に、ネットワークデバイス２０１は、リソース割り当て情報を端末デバイス２０２に送信し、そしてその端末デバイス２０２によって他の端末デバイスにリソースを割り当てて、割り当てられたリソースを介して該他の端末デバイスがネットワークデバイス２０１に情報を送信できるようにすることができる。Ｖ２Ｘ通信では、信号の良い、または信頼性の高い端末デバイスを端末デバイス２０２とすることができる。

【0099】

なお、本願の実施例で説明された通信システムは、本願の実施例の技術案をより明確に説明するためであり、本願の実施例によって提供される技術案に対する限定を構成するものではない、当業者であれば、システムアーキテクチャの進化と新たなサービスシーンの出現につれて、本願の実施例によって提供される技術案は同様な問題に対して、同様に適用されることが分かることができる。

【0100】

以下、図面と併せて、本願によって提供される端末支援情報報告方法、取得方法及びその装置を詳細に説明する。

【0101】

図３を参照すると、図３は本願の実施例によって提供される端末支援情報報告方法の概略フローチャートである。なお、本願の実施例の端末支援情報報告方法は第１の端末デバイスによって実行できる。図３に示すように、この端末支援情報報告方法は以下のステップを含むことができるが、これに限定されない。

【0102】

ステップ３０１において、ネットワーク側デバイスにサイドリンク（ＳＬ）リソース要求情報リスト及び支援情報リストを送信し、ここで、リソース要求情報リストに第２の端末デバイスのリソース要求が含まれ、第２の端末デバイスのリソース要求に第２の端末デバイスの宛先アドレスが含まれ、支援情報リストに支援情報が含まれ、支援情報はインデックス識別子により支援情報に対応する端末デバイス識別子を決定し、ここで、支援情報に対応する端末デバイス識別子は、リソース要求情報リストにおけるインデックス識別子位置に位置するリソース要求内の宛先アドレスである。

【0103】

本願のいくつかの実施例では、この報告された支援情報リストにおける支援情報は、ページング識別子であってもよく、または、サイドリンク不連続受信（ＳＬＤＲＸ）支援情報であってもよく、または、ＳＬＤＲＸ設定などであってもよい。

【0104】

一実現形態では、支援情報リストの長さは１であってもよい。すなわち、第１の端末デバイスはネットワーク側デバイスに支援情報リストを報告することができ、この支援情報リストには１つのまたは複数の支援情報が含まれることができ、ここで、この支援情報リストにおける各支援情報はインデックス識別子によりこの支援情報が適用されるＵＥ識別子を決定することができ、このＵＥ識別子は、リソース要求情報リストにおけるインデックス識別子位置に位置するリソース要求内の宛先アドレスであってもよい。

【0105】

なお、接続状態にある第１の端末デバイスがサイドリンクで通信する場合、サイドリンク（ＳＬ）送信リソース要求情報リストが含まれるＳｉｄｅｌｉｎｋＵＥＩｎｆｏｒｍａｔｉｏｎメッセージをネットワーク側デバイス（例えば基地局）に送信する必要がある。このリソース要求情報リストにおける各エレメントは、第２の端末デバイスのリソース要求であり、このリソース要求には、この第２の端末デバイスの宛先アドレス、対応する伝送方式（ユニキャスト、マルチキャスト及びブロードキャストを含む）、サービス品質ＱｏＳ及びターゲット送信周波数が含まれる。本願の実施例では、第１の端末デバイスがネットワーク側デバイスに支援情報を報告する場合、支援情報に対応するインデックス識別子によって該支援情報とリソース要求情報リストにおける第２の端末デバイスの宛先アドレスとのマッピング関係を構築することにより、ネットワーク側デバイスがこのマッピング関係に基づいて、第１の端末デバイスから送信された支援情報が適用される第２の端末を特定するようにし、これにより、リソース要求情報リストにおける既存の宛先アドレスフィールドによって、支援情報が適用される第２の端末デバイスの指示を実現する。

【0106】

なお、本願のいくつかの実施例では、このインデックス識別子のセット方式は様々な方法があり、例えば、対応する支援情報に含まれてもよく、または、リソース要求のリソース要求情報リストにおけるインデックス位置によって支援情報に対応するインデックス識別子をセットしてもよい。以下、例を挙げて、インデックス識別子の異なるセット方式で、インデックス識別子によって支援情報とリソース要求情報リストにおける第２の端末デバイスの宛先アドレスとのマッピング関係を構築することをそれぞれ説明する。

【0107】

可能な一実現形態の例として、第１の端末デバイスから報告されたリソース要求情報リスト（例えばＳＬ－ＴｘＲｅｓｏｕｒｃｅＲｅｑＬｉｓｔ－ｒ１６）には４つのエレメントがあると仮定すると、例えば以下の表１に示す。

【0108】

【表1】

【0109】

第１の端末デバイスが報告する必要がある支援情報がＳＬＤＲＸ設定情報であると仮定すると、報告されたＳＬＤＲＸ設定情報は、例えば、宛先アドレス（識別子とも呼ばれる）が０００００００１である第２の端末デバイスについて、そのＳＬＤＲＸ設定情報がＡであり、宛先アドレス（識別子とも呼ばれる）が００００００１１である第２の端末デバイスについて、そのＳＬＤＲＸ設定情報がＢであることであってもよい。インデックス識別子のセット方式が異なるため、第１の端末デバイスがネットワーク側デバイスに報告した支援情報リストの形式も異なる。

【0110】

一実現形態では、インデックス識別子は対応する支援情報に含まれている。このような場合、第１の端末デバイス第２の端末デバイスの宛先アドレスに対応する送信リソース要求のリソース要求情報リストにおけるインデックス位置に基づいて、インデックス識別子をセットすることができる。このような実現形態では、第１の端末デバイスがネットワーク側デバイスに報告した支援情報リストは例えば表２に示すようにすることができる。

【0111】

【表2】

【0112】

ここで、表１及び表２から、報告された支援情報リストにおけるＳＬＤＲＸ設定がＡであるＵＥのＳＬ－ＤｅｓｔｉｎａｔｉｏｎＩｄｅｎｔｉｔｙ－ｒ１６は、リソース要求情報リスト（例えばＳＬ－ＴｘＲｅｓｏｕｒｃｅＲｅｑＬｉｓｔ－ｒ１６）における２（インデックス識別子）番目のエントリのＳＬ－ＤｅｓｔｉｎａｔｉｏｎＩｄｅｎｔｉｔｙ－ｒ１６、すなわち０００００００１である。このように、報告された支援情報リストにおけるＳＬＤＲＸ設定がＢであるＵＥのＳＬ－ＤｅｓｔｉｎａｔｉｏｎＩｄｅｎｔｉｔｙ－ｒ１６は、リソース要求情報リスト（例えばＳＬ－ＴｘＲｅｓｏｕｒｃｅＲｅｑＬｉｓｔ－ｒ１６）における４（インデックス識別子）番目のエントリのＳＬ－ＤｅｓｔｉｎａｔｉｏｎＩｄｅｎｔｉｔｙ－ｒ１６、すなわち００００００１１である。

【0113】

別の実現形態では、本願の実施例におけるインデックス識別子は支援情報の支援情報リストにおける位置によって決定される。このような場合、第１の端末デバイスは、第２の端末デバイスの宛先アドレスに対応するリソース要求のリソース要求情報リストにおけるインデックス位置に基づいて、支援情報を支援情報リストにおける同じインデックス位置にセットする必要があり、ここで、支援情報リストは、リソース要求情報リストと同じ長さである。ある目的のＵＥに支援情報がない場合は、空にするが、そのエントリを保持する必要がある。このような実現形態では、第１の端末デバイスがネットワーク側デバイスに報告した支援情報リストは例えば以下の表３に示すようにすることができる。

【0114】

【表3】

【0115】

ここで、表３におけるＳＬＤＲＸ設定がＡである場合、まずＡのインデックス識別子がその支援情報リストにおけるインデックス位置である２番目であると決定し、そしてインデックス識別子によってＡのＵＥ識別子を取得し、すなわち、報告された支援情報リストにおけるＳＬＤＲＸ設定がＡであるＵＥのＳＬ－ＤｅｓｔｉｎａｔｉｏｎＩｄｅｎｔｉｔｙ－ｒ１６が、リソース要求情報リスト（例えばＳＬ－ＴｘＲｅｓｏｕｒｃｅＲｅｑＬｉｓｔ－ｒ１６）における２（インデックス識別子）番目のエントリのＳＬ－ＤｅｓｔｉｎａｔｉｏｎＩｄｅｎｔｉｔｙ－ｒ１６、すなわち０００００００１である。

【0116】

このように、表３におけるＳＬＤＲＸ設定がＢである場合、まずＢのインデックス識別子がその支援情報リストにおけるインデックス位置である４番目であると決定し、そしてインデックス識別子によってＢのＵＥ識別子を取得し、すなわち、報告された支援情報リストにおけるＳＬＤＲＸ設定がＢであるＵＥのＳＬ－ＤｅｓｔｉｎａｔｉｏｎＩｄｅｎｔｉｔｙ－ｒ１６が、リソース要求情報リスト（例えばＳＬ－ＴｘＲｅｓｏｕｒｃｅＲｅｑＬｉｓｔ－ｒ１６）における４（インデックス識別子）番目のエントリのＳＬ－ＤｅｓｔｉｎａｔｉｏｎＩｄｅｎｔｉｔｙ－ｒ１６、すなわち００００００１１である。

【0117】

本願のいくつかの実施例では、この報告された支援情報リストにおける支援情報は、ページング識別子であってもよく、または、サイドリンク不連続受信（ＳＬＤＲＸ）支援情報であってもよく、または、ＳＬＤＲＸ設定などであってもよい。一実現形態では、この支援情報は第２の端末デバイスのページング識別子を含んでもよく、ここで、この第２の端末デバイスはリモート端末デバイスである。

【0118】

すなわち、第１の端末デバイスが中継ＵＥである場合、報告された支援情報リストにおける支援情報は第２の端末デバイスのページング識別子を含んでもよい。例えば、第１の端末デバイスが中継ＵＥである場合、中継ＵＥはネットワーク側デバイスに第２の端末デバイス（例えばリモートＵＥ）のページング識別子を報告することにより、ネットワーク側デバイスがこの第２の端末デバイスに送信されたページングメッセージをこの中継ＵＥに送信して、中継ＵＥによってこのページングメッセージを第２の端末デバイスを転送するようにする必要がある。

【0119】

一実現形態では、支援情報はサイドリンク不連続受信（ＳＬＤＲＸ）設定を含んでもよく、ここで、このサイドリンク不連続受信（ＳＬＤＲＸ）設定は、第１の端末デバイスによって受信された、第２の端末デバイスから送信されたＳＬＤＲＸ設定であり、かつ第１の端末デバイスがこのＳＬＤＲＸ設定を受容する。

【0120】

すなわち、第１の端末デバイスが第２の端末デバイスから送信されたＳＬＤＲＸ設定を受信し、かつ第１の第１の端末デバイスがこのＳＬＤＲＸ設定を受容した場合、この第１の端末デバイスによって報告された支援情報リストにおける支援情報はこのＳＬＤＲＸ設定を含んでもよい。

【0121】

一実現形態では、支援情報は受信されたＳＬＤＲＸ支援情報を含んでもよく、ここで、このＳＬＤＲＸ支援情報は、第１の端末デバイスによって受信された、第２の端末デバイスから送信されたＳＬＤＲＸ支援情報である。

【0122】

すなわち、第１の端末デバイスが第２の端末デバイスから送信されたＳＬＤＲＸ支援情報を受信した場合、この第１の端末デバイスによって報告された支援情報リストにおける支援情報はこの受信されたＳＬＤＲＸ支援情報を含んでもよい。

【0123】

本願の実施例の実施により、端末支援情報を報告する場合にインデックス識別子によって端末支援情報が適用される端末デバイスＵＥの識別子を決定することができ、この端末デバイスＵＥの識別子は、リソース要求情報リストにおけるインデックス識別子位置に位置する送信リソース要求内の宛先アドレスである。これにより、本願の実施例は、インデックス識別子によって支援情報とリソース要求情報リストにおける相手側端末デバイスＵＥの宛先アドレスとのマッピング関係を構築することにより、端末支援情報を報告する場合の相手側端末デバイスに対する指示を実現し、端末支援情報の報告のシグナリングオーバーヘッドを節約することができる。

【0124】

図４を参照すると、図４は本願の実施例によって提供される端末支援情報報告方法の概略フローチャートである。なお、本願の実施例の端末支援情報報告方法は第１の端末デバイスによって実行できる。図４に示すように、この端末支援情報報告方法は以下のステップを含むことができるが、これに限定されない。

【0125】

ステップ４０１において、ネットワーク側デバイスにサイドリンク（ＳＬ）リソース要求情報リスト及び支援情報リストを送信し、ここで、リソース要求情報リストに複数のリソース要求が含まれ、１つのリソース要求が１つのインデックス位置に対応し、支援情報リストに第２の端末デバイスの支援情報、及び支援情報に対応するインデックス識別子が含まれ、ここで、インデックス識別子は、リソース要求に対応するインデックス位置と対応している。

【0126】

本願のいくつかの実施例では、この支援情報リストにおける支援情報は、ページング識別子であってもよく、または、サイドリンク不連続受信（ＳＬＤＲＸ）支援情報であってもよく、または、ＳＬＤＲＸ設定などであってもよい。

【0127】

一実現形態では、支援情報リストの長さは１であってもよい。すなわち、第１の端末デバイスは、ネットワーク側デバイスにサイドリンク（ＳＬ）リソース要求情報リストを送信することに加えて、ネットワーク側デバイスに支援情報リストを送信してもよく、この支援情報リストには、１つのまたは複数の第２の端末デバイスの支援情報、及びこの支援情報に対応するインデックス識別子が含まれてもよく、このインデックス識別子はリソース要求のリソース要求情報リストにおけるインデックス位置に対応している。リソース要求に第２の端末デバイスの宛先アドレスがあるため、ネットワーク側デバイスは、第１の端末デバイスから報告されたリソース要求情報リスト及び支援情報リストを受信した後、リソース要求情報リストにおける既存の宛先アドレスフィールドによって、支援情報リストにおける各支援情報が適用される第２の端末デバイスの指示を実現することができ、支援情報の報告のシグナリングオーバーヘッドを節約することができる。

【0128】

なお、接続状態にある第１の端末デバイスがサイドリンクで通信する場合、サイドリンク（ＳＬ）送信リソース要求情報リストが含まれるＳｉｄｅｌｉｎｋＵＥＩｎｆｏｒｍａｔｉｏｎ（サイドリンク通信端末情報）メッセージをネットワーク側デバイス（例えば基地局）に送信する必要がある。このリソース要求情報リストにおける各エレメントは、第２の端末デバイスのリソース要求であり、このリソース要求には、この第２の端末デバイスの宛先アドレス、対応する伝送方式（ユニキャスト、マルチキャスト及びブロードキャストを含む）、サービス品質ＱｏＳ及びターゲット送信周波数が含まれる。本願の実施例では、第１の端末デバイスがネットワーク側デバイスに支援情報を報告する場合、支援情報に対応するインデックス識別子によって該支援情報とリソース要求情報リストにおける第２の端末デバイスの宛先アドレスとのマッピング関係を構築することにより、ネットワーク側デバイスがこのマッピング関係に基づいて、第１の端末デバイスから送信された支援情報が適用される第２の端末を特定するようにし、これにより、リソース要求情報リストにおける既存の宛先アドレスフィールドによって、支援情報が適用される第２の端末デバイスの指示を実現する。

【0129】

【0130】

可能な一実現形態の例として、第１の端末デバイスから報告されたリソース要求情報リスト（例えばＳＬ－ＴｘＲｅｓｏｕｒｃｅＲｅｑＬｉｓｔ－ｒ１６）には４つのエレメントがあると仮定すると、例えば上記の表１に示す。第１の端末デバイスが報告する必要がある支援情報がＳＬＤＲＸ設定情報であると仮定すると、報告されたＳＬＤＲＸ設定情報は、例えば、宛先アドレス（識別子とも呼ばれる）が０００００００１である第２の端末デバイスについて、そのＳＬＤＲＸ設定情報がＡであり、宛先アドレス（識別子とも呼ばれる）が００００００１１である第２の端末デバイスについて、そのＳＬＤＲＸ設定情報がＢであることであってもよい。インデックス識別子のセット方式が異なるため、第１の端末デバイスがネットワーク側デバイスに支援情報リストを報告する形態も異なる。

【0131】

一実現形態では、インデックス識別子は対応する支援情報に含まれている。このような場合、第１の端末デバイスは、リソース要求のリソース要求情報リストにおけるインデックス位置を決定し、このインデックス位置に基づいて、支援情報リストにおいて、この支援情報に対応するインデックス識別子をセットすることができる。第１の端末デバイスは、このインデックス位置に基づいて、支援情報リストにおいて、この支援情報に対応するインデックス識別子をセットした後、セットされた支援情報リスト及びリソース要求情報リストをネットワーク側デバイスに送信することができる。

【0132】

例えば、第１の端末デバイスがネットワーク側デバイスに報告した支援情報リストの形式は例えば上記の表２に示すようにすることができる。ここで、表１及び表２から、報告された支援情報リストにおけるＳＬＤＲＸ設定情報Ａが適用される第２の端末デバイスの宛先アドレスは、リソース要求情報リスト（例えばＳＬ－ＴｘＲｅｓｏｕｒｃｅＲｅｑＬｉｓｔ－ｒ１６）におけるインデックス位置が２である宛先アドレス、すなわち０００００００１である。このように、報告された支援情報リストにおけるＳＬＤＲＸ設定Ｂが適用される第２の端末デバイスの宛先アドレスは、リソース要求情報リスト（例えばＳＬ－ＴｘＲｅｓｏｕｒｃｅＲｅｑＬｉｓｔ－ｒ１６）におけるインデックス位置が４である宛先アドレス、すなわち００００００１１である。ネットワーク側デバイスは、第１の端末デバイス送信のリソース要求情報リスト及び支援情報リストを受信した後、支援情報リストにおける支援情報に対応するインデックス識別子に基づいて、リソース要求情報リストにおけるインデックス位置に位置するリソース要求を決定し、インデックス位置に位置するリソース要求内の宛先アドレスを取得することができ、ここで、宛先アドレスを有する端末デバイスは支援情報が適用される第２の端末デバイスである。

【0133】

例えば、第１の端末デバイスから送信されたリソース要求情報リストが例えば上記の表１に示すものであり、送信された支援情報リストが例えば上記の表２に示すものであると仮定すると、ネットワーク側デバイスは、支援情報に対応するインデックス識別子「２」に基づいて、リソース要求情報リストにおけるインデックス位置が２であるリソース要求を決定することにより、この支援情報（すなわち上記の表２においてＳＬＤＲＸ設定情報がＡである）が適用される端末デバイスが宛先アドレス「０００００００１」を有する第２の端末デバイスであることを知ることができる。このように、ネットワーク側デバイスは、支援情報に対応するインデックス識別子「４」に基づいて、リソース要求情報リストにおけるインデックス位置が４であるリソース要求を決定することにより、この支援情報（すなわち上記の表２においてＳＬＤＲＸ設定情報がＢである）が適用される端末デバイスが宛先アドレス「００００００１１」を有する第２の端末デバイスであることを知ることができる。

【0134】

別の実現形態では、支援情報リストは、リソース要求情報リストと同じ長さであり、リソース要求のリソース要求情報リストにおけるインデックス位置は、支援情報の前記支援情報リストにおけるインデックス位置と同じである。ここで、支援情報に対応するインデックス識別子は支援情報の支援情報リストにおけるインデックス位置であってもよい。すなわち、第１の端末デバイスは、第２の端末デバイスのリソース要求のリソース要求情報リストにおけるインデックス位置に基づいて、この第２の端末デバイスの支援情報を支援情報リストにおける同じインデックス位置にセットする必要がある。ある第２の端末デバイスが支援情報を有さない場合、支援情報リストにおける対応する位置で空にする。

【0135】

例えば、第１の端末デバイスがネットワーク側デバイスに報告した支援情報リストの形式は例えば以下の表３に示すようにすることができる。

【0136】

【表4】

【0137】

すなわち、第１の端末デバイスセットの支援情報リストの長さは、リソース要求情報リストの長さと同じであり、長さはいずれも４であり、ＳＬＤＲＸ設定情報Ａが適用される端末デバイスが、宛先アドレスが０００００００１である第２の端末デバイスであり、ＳＬＤＲＸ設定情報Ｂが適用される端末デバイスが、宛先アドレスが００００００１１である第２の端末デバイスであると仮定する。第１の端末デバイスは、第２の端末デバイスのリソース要求のリソース要求情報リストにおけるインデックス位置（例えば２）に基づいて、支援情報リストにおけるインデックス位置が２の位置にＳＬＤＲＸ設定情報Ａをセットする必要がある。このように、第１の端末デバイスは、第２の端末デバイスのリソース要求のリソース要求情報リストにおけるインデックス位置（例えば４）に基づいて、支援情報リストにおけるインデックス位置が４の位置にＳＬＤＲＸ設定情報Ｂをセットする必要がある。リソース要求情報リストにおいて他の第２の端末デバイスが支援情報を有さない場合、支援情報リストにおける対応する位置で空にし、すなわちこの第１の端末デバイスセットの支援情報リストの形式は例えば上記の表３に示すようにすることができる。第１の端末デバイスは、リソース要求のリソース要求情報リストにおけるインデックス位置に基づいて、支援情報リストにおける同じインデックス位置に支援情報をセットした後、セットされた支援情報リスト及びリソース要求情報リストをネットワーク側デバイスに送信する。

【0138】

本例では、ネットワーク側デバイスは、第１の端末デバイスから送信されたリソース要求情報リスト及び支援情報リストを受信した後、支援情報リストにおける支援情報に対応するインデックス識別子に基づいて、リソース要求情報リストにおけるインデックス位置に位置するリソース要求を決定し、インデックス位置に位置するリソース要求内の宛先アドレスを取得することができ、ここで、宛先アドレスを有する端末デバイスは支援情報が適用される第２の端末デバイスである。例えば、第１の端末デバイスから送信されたリソース要求情報リストが例えば上記の表１に示すものであり、送信された支援情報リストが例えば上記の表３に示すものであると仮定すると、ネットワーク側デバイスは、支援情報に対応するインデックス識別子「２」（すなわち支援情報の支援情報リストにおける位置）に基づいて、リソース要求情報リストにおけるインデックス位置が２であるリソース要求を決定することにより、この支援情報（すなわち上記の表３においてＳＬＤＲＸ設定情報がＡである）が適用される端末デバイスが宛先アドレス「０００００００１」を有する第２の端末デバイスであることを知ることができる。このように、ネットワーク側デバイスは、支援情報に対応するインデックス識別子「４」に基づいて、リソース要求情報リストにおけるインデックス位置が４であるリソース要求を決定することにより、この支援情報（すなわち上記の表３においてＳＬＤＲＸ設定情報がＢである）が適用される端末デバイスが宛先アドレス「００００００１１」を有する第２の端末デバイスであることを知ることができる。

【0139】

本願の実施例の実施により、支援情報に対応するインデックス識別子によって該支援情報とリソース要求情報リストにおける第２の端末デバイスの宛先アドレスとのマッピング関係を構築することにより、ネットワーク側デバイスがこのマッピング関係に基づいて、第１の端末デバイスから送信された支援情報が適用される第２の端末を特定するようにし、これにより、リソース要求情報リストにおける既存の宛先アドレスフィールドによって、支援情報が適用される第２の端末デバイスの指示を実現し、支援情報の報告のシグナリングオーバーヘッドを節約することができる。

【0140】

なお、本願のいくつかの実施例では、この報告された支援情報リストにおける支援情報は、ページング識別子であってもよく、または、ＳＬＤＲＸ支援情報であってもよく、または、ＳＬＤＲＸ設定情報などであってもよい。なお、第１の端末デバイスがネットワーク側デバイスに報告した支援情報のコンテンツが異なる場合、第１の端末デバイスと第２の端末デバイスが果たす役割も異なる。例えば、第１の端末デバイスがネットワーク側デバイスに送信した支援情報がページング識別子である場合、この第１の端末デバイスは中継端末デバイスであり、第２の端末デバイスはリモート端末デバイスである。また例えば、第１の端末デバイスがネットワーク側デバイスに送信した支援情報がＳＬＤＲＸ支援情報である場合、この第１の端末デバイスは送信端末デバイスであり、第２の端末デバイスは受信端末デバイスである。また例えば、第１の端末デバイスがネットワーク側デバイスに送信した支援情報がＳＬＤＲＸ設定情報である場合、この第１の端末デバイスは受信端末デバイスであり、第２の端末デバイスは送信端末デバイスである。以下、実施例に基づいてそれぞれ詳細に説明する。

【0141】

図５を参照すると、図５は本願の実施例によって提供される別の端末支援情報報告方法の概略フローチャートである。なお、本願の実施例の端末支援情報報告方法は第１の端末デバイスによって実行できる。ここで、支援情報はページング識別子であり。図５に示すように、この端末支援情報報告方法は、以下のステップを含むことができるが、これらに限定されない。

【0142】

ステップ５０１において、第２の端末デバイスから送信されたページング識別子を受信する。

【0143】

選択的に、本願の実施例では、この第１の端末デバイスは中継端末デバイスであり、第２の端末デバイスはリモート端末デバイスである。第２の端末デバイスがネットワーク側デバイスにページング要求を送信する場合、第２の端末デバイスは自体のページング識別子を第１の端末デバイスに送信する。第１の端末デバイスは、第２の端末デバイスから送信されたページング識別子を受信して、このページング識別子をネットワーク側デバイスに送信することにより、ネットワーク側デバイスがこのページング識別子のページングメッセージを第１の端末デバイスを介して第２の端末デバイスに送信するようにすることができる。

【0144】

ステップ５０２において、ページング識別子を第２の端末デバイスの支援情報として決定する。

【0145】

選択的に、第１の端末デバイスは、第２の端末デバイスから送信されたページング識別子を受信すると、このページング識別子をこの第２の端末デバイスの支援情報として決定することができる。第１の端末デバイスがネットワーク側デバイスにリソース要求情報リストを報告して、ネットワーク側デバイスによるこのリストにおける第２の端末デバイスのサイドリンクリソースへの設定を実現する必要があるため、第１の端末デバイスは、リソース要求情報リストにおける第２の端末デバイスの宛先アドレスを用いて、このページング識別子が適用される端末デバイスが具体的にどの第２の端末デバイスであるかを指示することができる。

【0146】

一実現形態では、第１の端末デバイスは、ページング識別子を第２の端末デバイスの支援情報として決定した後、第２の端末デバイスのサイドリンクリソース要求のリソース要求情報リストにおけるインデックス位置を決定し、このインデックス位置に基づいて、支援情報リストにおいて、このページング識別子に対応するインデックス識別子をセットすることにより、このページング識別子及びそれに対応するインデックス識別子を支援情報リストにセットすることができる。

【0147】

例えば、第１の端末デバイスが報告する必要があるリソース要求情報リスト（例えばＳＬ－ＴｘＲｅｓｏｕｒｃｅＲｅｑＬｉｓｔ－ｒ１６）には４つのエレメントがあると仮定すると、例えば上記の表１に示す。第１の端末デバイスが受信した支援情報は、宛先アドレス「０００００００１」を有する第２の端末デバイスから送信されたページング識別子Ｃと、宛先アドレス「００００００１１」を有する第２の端末デバイスから送信されたページング識別子Ｄであると仮定する。第１の端末デバイスは、宛先アドレス「０００００００１」を有する第２の端末デバイスのリソース要求のリソース要求情報リストにおけるインデックス位置が２であると決定し、このインデックス位置に基づいて、支援情報リストにおいて、このページング識別子Ｃに対応するインデックス識別子をセットすることができ、すなわちこのインデックス識別子が２であり、このページング識別子Ｃ及びインデックス識別子の支援情報リストにおける形態は例えば以下の表４に示すようにすることができる。第１の端末デバイスは、宛先アドレス「００００００１１」を有する第２の端末デバイスのリソース要求のリソース要求情報リストにおけるインデックス位置が４であると決定し、このインデックス位置に基づいて、支援情報リストにおいて、このページング識別子Ｄに対応するインデックス識別子をセットすることができ、すなわちこのインデックス識別子が４であり、このページング識別子Ｄ及びインデックス識別子の支援情報リストにおける形態は例えば以下の表４に示すようにすることができる。第１の端末デバイスは、このページング識別子Ｃ及びそれに対応するインデックス識別子、ページング識別子Ｄ及びそれに対応するインデックス識別子を支援情報リストにセットし、この支援情報リストの形態は例えば表４に示すようにすることができる。

【0148】

【表5】

【0149】

別の実現形態では、第１の端末デバイスは、ページング識別子を第２の端末デバイスの支援情報として決定した後、リソース要求のリソース要求情報リストにおけるインデックス位置に基づいて、支援情報リストにおける同じインデックス位置に対応する支援情報をセットすることができ、ここで、支援情報に対応するインデックス識別子は支援情報の支援情報リストにおけるインデックス位置と対応しており、支援情報リストは、リソース要求情報リストと同じ長さである。

【0150】

例えば、第１の端末デバイスが報告する必要があるサイドリンク（ＳＬ）リソース要求情報リスト（例えばＳＬ－ＴｘＲｅｓｏｕｒｃｅＲｅｑＬｉｓｔ－ｒ１６）には４つのエレメントがあると仮定すると、例えば上記の表１に示す。第１の端末デバイスが受信した支援情報は、宛先アドレス「０００００００１」を有する第２の端末デバイスから送信されたページング識別子Ｃと、宛先アドレス「００００００１１」を有する第２の端末デバイスから送信されたページング識別子Ｄであると仮定する。第１の端末デバイスは、宛先アドレス「０００００００１」を有する第２の端末デバイスのリソース要求のリソース要求情報リストにおけるインデックス位置が２であると決定し、このインデックス位置に基づいて、支援情報リストにおける同じインデックス位置にこのページング識別子Ｃをセットすることができ、例えば以下の表５に示すように、支援情報リストにおけるインデックス位置が２である位置にこのページング識別子Ｃをセットする。第１の端末デバイスは、宛先アドレス「００００００１１」を有する第２の端末デバイスのリソース要求のリソース要求情報リストにおけるインデックス位置が４であると決定し、このインデックス位置に基づいて、支援情報リストにおける同じインデックス位置にこのページング識別子Ｄをセットすることができ、例えば以下の表５に示すように、支援情報リストにおけるインデックス位置が４である位置にこのページング識別子Ｄをセットする。

【0151】

【表6】

【0152】

ステップ５０３において、ネットワーク側デバイスにサイドリンク（ＳＬ）リソース要求情報リスト及び支援情報リストを送信する。

【0153】

ここで、本願の実施例では、リソース要求情報リストに複数のリソース要求が含まれ、１つのリソース要求が１つのインデックス位置に対応し、支援情報リストに第２の端末デバイスの支援情報、及び支援情報に対応するインデックス識別子が含まれ、ここで、インデックス識別子は、リソース要求に対応するインデックス位置と対応している。

【0154】

すなわち、第１の端末デバイスは、第２の端末デバイスから送信されたページング識別子を受信した後、ページング識別子を第２の端末デバイスの支援情報として決定し、支援情報に対応するインデックス識別子によって該支援情報とリソース要求情報リストにおける第２の端末デバイスの宛先アドレスとのマッピング関係を構築することにより、ネットワーク側デバイスがこのマッピング関係に基づいて、第１の端末デバイスから送信された支援情報が適用される第２の端末を特定するようにし、これにより、リソース要求情報リストにおける既存の宛先アドレスフィールドによって、支援情報が適用される第２の端末デバイスの指示を実現し、支援情報の報告のシグナリングオーバーヘッドを節約することができる。

【0155】

図６を参照すると、図６は本願の実施例によって提供される更なる端末支援情報報告方法の概略フローチャートである。なお、本願の実施例の端末支援情報報告方法は第１の端末デバイスによって実行できる。ここで、支援情報はＳＬＤＲＸ設定情報である。図６に示すように、この端末支援情報報告方法は、以下のステップを含むことができるが、これに限定されない。

【0156】

ステップ６０１において、第２の端末デバイスから送信されたＳＬＤＲＸ設定情報を受信する。

【0157】

【0158】

ステップ６０２において、ＳＬＤＲＸ設定情報を第２の端末デバイスの支援情報として決定する。

【0159】

選択的に、第１の端末デバイスは第２の端末デバイスから送信されたＳＬＤＲＸ設定情報を受信すると、このＳＬＤＲＸ設定情報をこの第２の端末デバイスの支援情報として決定することができる。第１の端末デバイスがネットワーク側デバイスにリソース要求情報リストを報告して、ネットワーク側デバイスによるこのリストにおける第２の端末デバイスのサイドリンクリソースへの設定を実現する必要があるため、第１の端末デバイスは、リソース要求情報リストにおける第２の端末デバイスの宛先アドレスを用いて、このＳＬＤＲＸ設定情報の端末デバイスを指示することができる。

【0160】

ここで、支援情報がＳＬＤＲＸ設定情報である場合の支援情報リストのセットの実現方式は、支援情報がページング識別子である場合の支援情報リストのセットの実現方式と類似している。一実現形態では、第１の端末デバイスは、ＳＬＤＲＸ設定情報を第２の端末デバイスの支援情報として決定した後、第２の端末デバイスのサイドリンクリソース要求のリソース要求情報リストにおけるインデックス位置を決定し、このインデックス位置に基づいて、支援情報リストにおいて、このＳＬＤＲＸ設定情報に対応するインデックス識別子をセットすることにより、このＳＬＤＲＸ設定情報及びそれに対応するインデックス識別子を支援情報リストにセットすることができる。

【0161】

別の実現形態では、第１の端末デバイスは、ＳＬＤＲＸ設定情報を第２の端末デバイスの支援情報として決定した後、リソース要求のリソース要求情報リストにおけるインデックス位置に基づいて、支援情報リストにおける同じインデックス位置に支援情報をセットすることができ、ここで、支援情報に対応するインデックス識別子は支援情報の支援情報リストにおけるインデックス位置であり、支援情報リストは、リソース要求情報リストと同じ長さである。

【0162】

ステップ６０３において、ネットワーク側デバイスにサイドリンク（ＳＬ）リソース要求情報リスト及び支援情報リストを送信する。

【0163】

【0164】

すなわち、第１の端末デバイスは、第２の端末デバイスから送信されたＳＬＤＲＸ設定情報を受信した後、接続状態にある場合にＳＬＤＲＸ設定情報を第２の端末デバイスの支援情報として決定し、支援情報に対応するインデックス識別子によって該支援情報とリソース要求情報リストにおける第２の端末デバイスの宛先アドレスとのマッピング関係を構築することにより、ネットワーク側デバイスがこのマッピング関係に基づいて、第１の端末デバイスから送信された支援情報が適用される第２の端末を特定するようにし、これにより、リソース要求情報リストにおける既存の宛先アドレスフィールドによって、支援情報が適用される第２の端末デバイスの指示を実現し、支援情報の報告のシグナリングオーバーヘッドを節約することができる。

【0165】

図７を参照すると、図７は本願の実施例によって提供される更なる端末支援情報報告方法の概略フローチャートである。なお、本願の実施例の端末支援情報報告方法は第１の端末デバイスによって実行できる。ここで、支援情報はＳＬＤＲＸ支援情報であり。図７に示すように、この端末支援情報報告方法は、以下のステップを含むことができるが、これに限定されない。

【0166】

ステップ７０１において、第２の端末デバイスから送信されたＳＬＤＲＸ支援情報を受信し、ＳＬＤＲＸ支援情報はアドバイスされたＳＬＤＲＸ設定情報を含む。

【0167】

選択的に、本願の実施例では、この第１の端末デバイスは送信端末デバイスであり、第２の端末デバイスは受信端末デバイスである。省電力化を図るために、ネットワーク側デバイス（例えば基地局）は、サイドリンク端末デバイスのＳＬＤＲＸ設定情報に基づいて、ＳＬＤＲＸとＵｕＤＲＸができるだけ重なるようにＵｕＤＲＸを調整することができる。ここで、このＳＬＤＲＸ設定情報は、受信端末デバイスから送信されたＳＬＤＲＸ支援情報においてアドバイスされたＳＬＤＲＸ設定情報であってもよい。

【0168】

【0169】

ステップ７０２において、ＳＬＤＲＸ支援情報を第２の端末デバイスの支援情報として決定する。

【0170】

選択的に、第１の端末デバイスは、第２の端末デバイスから送信されたＳＬＤＲＸ支援情報を受信すると、このＳＬＤＲＸ支援情報をこの第２の端末デバイスの支援情報として決定することができる。第１の端末デバイスがネットワーク側デバイスにリソース要求情報リストを報告して、ネットワーク側デバイスによるこのリストにおける第２の端末デバイスのサイドリンクリソースへの設定を実現する必要があるため、第１の端末デバイスは、リソース要求情報リストにおける第２の端末デバイスの宛先アドレスを用いて、このＳＬＤＲＸ支援情報の端末デバイスを指示することができる。

【0171】

ここで、支援情報がＳＬＤＲＸ支援情報である場合の支援情報リストのセットの実現方式は、支援情報がページング識別子である場合の支援情報リストのセットの実現方式と類似している。一実現形態では、第１の端末デバイスは、ＳＬＤＲＸ支援情報を第２の端末デバイスの支援情報とした後、第２の端末デバイスのサイドリンクリソース要求のリソース要求情報リストにおけるインデックス位置を決定し、このインデックス位置に基づいて、支援情報リストにおいて、このＳＬＤＲＸ支援情報に対応するインデックス識別子をセットすることにより、このＳＬＤＲＸ支援情報及びそれに対応するインデックス識別子を支援情報リストにセットすることができる。

【0172】

別の実現形態では、第１の端末デバイスは、ＳＬＤＲＸ支援情報を第２の端末デバイスの支援情報とした後、リソース要求のリソース要求情報リストにおけるインデックス位置に基づいて、支援情報リストにおける同じインデックス位置に対応する支援情報をセットすることができ、ここで、支援情報に対応するインデックス識別子は支援情報の支援情報リストにおけるインデックス位置と対応しており、支援情報リストは、リソース要求情報リストと同じ長さである。

【0173】

ステップ７０３において、ネットワーク側デバイスにサイドリンク（ＳＬ）リソース要求情報リスト及び支援情報リストを送信する。

【0174】

【0175】

すなわち、第１の端末デバイスは、第２の端末デバイスから送信されたＳＬＤＲＸ支援情報を受信した後、接続状態にある場合にＳＬＤＲＸ支援情報を第２の端末デバイスの支援情報として決定し、支援情報に対応するインデックス識別子によって該支援情報とリソース要求情報リストにおける第２の端末デバイスの宛先アドレスとのマッピング関係を構築することにより、ネットワーク側デバイスがこのマッピング関係に基づいて、第１の端末デバイスから送信された支援情報が適用される第２の端末を特定するようにし、これにより、リソース要求情報リストにおける既存の宛先アドレスフィールドによって、支援情報が適用される第２の端末デバイスの指示を実現し、支援情報の報告のシグナリングオーバーヘッドを節約することができる。

【0176】

なお、上記の実施例は第１の端末デバイス側で本願の実施例の端末支援情報報告方法の実現形態を説明する。本願の実施例は端末支援情報取得方法をさらに提案し、以下、ネットワーク側デバイス側でこの端末支援情報取得方法の実現形態を説明する。図８を参照すると、図８は本願の実施例によって提供される端末支援情報取得方法の概略フローチャートである。なお、本願の実施例の端末支援情報取得方法はネットワーク側デバイスによって実行できる。図８に示すように、この端末支援情報取得方法は、以下のステップを含むことができるが、これに限定されない。

【0177】

ステップ８０１において、第１の端末デバイスから送信されたサイドリンク（ＳＬ）リソース要求情報リスト及び支援情報リストを受信し、ここで、リソース要求情報リストに第２の端末デバイスのリソース要求が含まれ、第２の端末デバイスのリソース要求に第２の端末デバイスの宛先アドレスが含まれ、支援情報リストに支援情報が含まれ、支援情報はインデックス識別子により支援情報に対応する端末デバイス識別子を決定し、ここで、支援情報に対応する端末デバイス識別子は、リソース要求情報リストにおけるインデックス識別子位置に位置するリソース要求内の宛先アドレスである。

【0178】

【0179】

一実現形態では、支援情報リストの長さは１であってもよい。すなわち、第１の端末デバイスはネットワーク側デバイスに支援情報リストを報告することができる。ネットワーク側デバイスは第１の端末デバイスから送信された支援情報リストを受信することができ、この支援情報リストには１つのまたは複数の支援情報が含まれることができ、ここで、この支援情報リストには１つのまたは複数の支援情報が含まれることができ、ここで、この支援情報リストにおける各支援情報はインデックス識別子によりこの支援情報が適用されるＵＥ識別子を決定することができ、このＵＥ識別子は、リソース要求情報リストにおけるインデックス識別子位置に位置するリソース要求内の宛先アドレスであってもよい。

【0180】

【0181】

なお、本願のいくつかの実施例では、このインデックス識別子のセット方式は様々な方法があり、例えば各支援情報に含まれていてもよく、または、支援情報の支援情報リストにおける位置によって決定されてもよい。ここでインデックス識別子のセット方式については上記の各実施例の実現形態の説明を参照することができ、ここでは説明を省略する。

【0182】

本願のいくつかの実施例では、この報告された支援情報リストにおける支援情報は、ページング識別子であってもよく、または、サイドリンク不連続受信（ＳＬＤＲＸ）支援情報であってもよく、または、ＳＬＤＲＸ設定などであってもよい。一実現形態では、この報告された支援情報リストにおける支援情報がページング識別子である場合、ネットワーク側デバイスは、宛先アドレスがこのページング識別子であるページング情報を、この支援情報リストを報告した端末デバイスに送信することができる。

【0183】

すなわち、第１の端末デバイスが中継ＵＥである場合、報告された支援情報リストにおける支援情報は第２の端末デバイスのページング識別子を含んでもよい。例えば、第１の端末デバイスが中継ＵＥである場合、中継ＵＥはネットワーク側デバイスに第２の端末デバイス（例えばリモートＵＥ）のページング識別子を報告することにより、ネットワーク側デバイスが、このリモートＵＥに送信されたページングメッセージをこの中継ＵＥに送信して、中継ＵＥによってこのページングメッセージをリモートＵＥに転送するようにする必要がある。

【0184】

一実現形態では、この報告された支援情報リストにおける支援情報がサイドリンク不連続受信（ＳＬＤＲＸ）設定である場合、ネットワーク側デバイスは、宛先アドレスに対応する第２の端末デバイスのアクティブ化時間内に、この宛先アドレスに対応する第２の端末デバイスへのサイドリンク送信リソースをスケジューリングすることができる。

【0185】

例えば、上記の表２に示すように、ネットワーク側デバイスが支援情報「ＳＬＤＲＸ設定Ａ」を受信し、かつＳＬＤＲＸ設定Ａがリソース要求情報リスト（例えばＳＬ－ＴｘＲｅｓｏｕｒｃｅＲｅｑＬｉｓｔ－ｒ１６）における２（インデックス識別子）番目のエントリのＳＬ－ＤｅｓｔｉｎａｔｉｏｎＩｄｅｎｔｉｔｙ－ｒ１６、すなわち０００００００１である端末デバイスに適用されると決定したと仮定すると、ネットワーク側デバイスは、宛先アドレスが０００００００１である端末デバイスのアクティブ化時間内に、この宛先アドレスが０００００００１である端末デバイスへのサイドリンクｓｉｄｅｌｉｎｋ送信リソースをスケジューリングすることができる。

【0186】

一実現形態では、この報告された支援情報リストにおける支援情報がＳＬＤＲＸ支援情報である場合、ネットワーク側デバイスは、このＳＬＤＲＸ支援情報に基づいて、宛先アドレスに対応する第２の端末デバイスのＳＬＤＲＸ設定を決定することができる。

【0187】

一例として、このＳＬＤＲＸ支援情報はアドバイスされたＳＬＤＲＸ設定を含んでもよい。例えば、ネットワーク側デバイスが受信した第１の端末デバイスから報告された支援情報リストにおける支援情報がＳＬＤＲＸ支援情報であり、このＳＬＤＲＸ支援情報に含まれるアドバイスされたＳＬＤＲＸ設定がＡであり、この支援情報に対応するインデックス識別子が２であると仮定する。ネットワーク側デバイスがインデックス識別子に基づいて、リソース要求情報リストにおける２（インデックス識別子）番目の位置に位置するリソース要求内の宛先アドレスが「０００００００１」であると決定した場合、ネットワーク側デバイスは、このＳＬＤＲＸ支援情報が、宛先アドレスが「０００００００１」である端末デバイスに適用されると決定することができ、ネットワーク側デバイスは、このＳＬＤＲＸ支援情報に基づいて、宛先アドレスが「０００００００１」である端末デバイスのＳＬＤＲＸ設定がＡであると決定することができる。

【0188】

本願の実施例の実施により、端末支援情報を報告する場合にインデックス識別子によって端末支援情報が適用される端末デバイスＵＥの識別子を決定することができ、この端末デバイスＵＥの識別子は、リソース要求情報リストにおけるインデックス識別子位置に位置するリソース要求内の宛先アドレスである。これにより、本願の実施例は、インデックス識別子によって支援情報とリソース要求情報リストにおける相手側端末デバイスＵＥの宛先アドレスとのマッピング関係を構築することにより、端末支援情報を報告する場合の相手側端末デバイスに対する指示を実現し、端末支援情報の報告のシグナリングオーバーヘッドを節約することができる。

【0189】

図９を参照すると、図９は本願の実施例によって提供される端末支援情報取得方法の概略フローチャートである。なお、本願の実施例の端末支援情報取得方法はネットワーク側デバイスによって実行できる。図９に示すように、この端末支援情報取得方法は、以下のステップを含むことができるが、これに限定されない。

【0190】

ステップ９０１において、第１の端末デバイスから送信されたサイドリンク（ＳＬ）リソース要求情報リスト及び支援情報リストを受信し、ここで、リソース要求情報リストに複数のリソース要求が含まれ、１つのリソース要求が１つのインデックス位置に対応し、支援情報リストに第２の端末デバイスの支援情報、及び支援情報に対応するインデックス識別子が含まれ、ここで、インデックス識別子は、リソース要求に対応するインデックス位置と対応している。

【0191】

本願の実施例では、第１の端末デバイスがリソース要求情報リスト及び支援情報リストを送信する実現形態は、それぞれ本願の各実施例におけるいずれかの形態によって実現することができ、本願の実施例ではこれを限定せず、説明も省略する。

【0192】

ステップ９０２において、インデックス識別子に基づいてリソース要求を決定する。

【0193】

選択的に、ネットワーク側デバイスは、第１の端末デバイスから送信されたリソース要求情報リスト及び支援情報リストを受信した後、支援情報リストにおける支援情報に対応するインデックス識別子に基づいて、リソース要求情報リストにおけるインデックス位置に位置するリソース要求を決定することができる。

【0194】

ステップ９０３において、リソース要求内の宛先アドレスを取得し、ここで、宛先アドレスを有する端末デバイスは第２の端末デバイスである。

【0195】

選択的に、ネットワーク側デバイスは、リソース要求を決定した後、このリソース要求から宛先アドレスを取得することができ、この宛先アドレスを有する端末デバイスはこの支援情報が適用される第２の端末デバイスである。

【0196】

なお、インデックス識別子のセット方式が異なるため、支援情報リストの形式も異なる。例えば、上記の表２及び表４に示すように、インデックス識別子は、対応する支援情報に含まれてもよい。また例えば、上記の表１、表３及び表５に示すように、支援情報リストは、リソース要求情報リストと同じ長さであり、支援情報に対応するインデックス識別子が支援情報の支援情報リストにおけるインデックス位置であると理解でき、すなわち、ネットワーク側デバイスは、支援情報の支援情報リストにおける位置に基づいて、この支援情報に対応するインデックス識別子を決定することにより、インデックス識別子に基づいてリソース要求情報リストにおけるインデックス位置に位置するリソース要求を決定することもできる。

【0197】

一実現形態では、インデックス識別子は対応する支援情報に含まれている。例えば、第１の端末デバイスから報告されたリソース要求情報リスト（例えばＳＬ－ＴｘＲｅｓｏｕｒｃｅＲｅｑＬｉｓｔ－ｒ１６）には４つのエレメントがあると仮定すると、例えば上記の表１に示すとおりであり、報告された支援情報リストは例えば上記の表２に示される。ネットワーク側デバイスが第１の端末デバイスから報告されたリソース要求情報リスト及び支援情報リストを受信した後、ネットワーク側デバイスは、支援情報に対応するインデックス識別子「２」に基づいて、リソース要求情報リストにおけるインデックス位置が２であるリソース要求を決定し、このインデックス位置が２であるリソース要求内の宛先アドレス０００００００１を取得することにより、この支援情報（すなわち上記の表２においてＳＬＤＲＸ設定情報がＡである）が適用される端末デバイスが宛先アドレス「０００００００１」を有する第２の端末デバイスであることを知ることができる。このように、ネットワーク側デバイスは、支援情報に対応するインデックス識別子「４」に基づいて、リソース要求情報リストにおけるインデックス位置が４であるリソース要求を決定し、このインデックス位置が４であるリソース要求内の宛先アドレス００００００１１を取得することにより、この支援情報（すなわち上記の表２においてＳＬＤＲＸ設定情報がＢである）が適用される端末デバイスが宛先アドレス「００００００１１」を有する第２の端末デバイスであることを知ることができる。

【0198】

別の実現形態では、支援情報リストは、リソース要求情報リストと同じ長さであり、リソース要求のリソース要求情報リストにおけるインデックス位置は、支援情報の支援情報リストにおけるインデックス位置と同じである。ネットワーク側デバイスは、支援情報の支援情報リストにおけるインデックス位置に基づいて、支援情報に対応するインデックス識別子を決定することができる。

【0199】

例えば、第１の端末デバイスから報告されたリソース要求情報リスト（例えばＳＬ－ＴｘＲｅｓｏｕｒｃｅＲｅｑＬｉｓｔ－ｒ１６）には４つのエレメントがあると仮定すると、例えば上記の表１に示すとおりであり、報告された支援情報リストは例えば上記の表３に示される。ネットワーク側デバイスは、第１の端末デバイスから送信されたリソース要求情報リスト及び支援情報リストを受信した後、支援情報に対応するインデックス識別子「２」（すなわち支援情報の支援情報リストにおける位置）に基づいて、リソース要求情報リストにおけるインデックス位置が２であるリソース要求を決定し、このインデックス位置が２であるリソース要求内の宛先アドレス０００００００１を取得することにより、この支援情報（すなわち上記の表３においてＳＬＤＲＸ設定情報がＡである）が適用される端末デバイスが宛先アドレス「０００００００１」を有する第２の端末デバイスであることを知ることができる。このように、ネットワーク側デバイスは、支援情報に対応するインデックス識別子「４」に基づいて、リソース要求情報リストにおけるインデックス位置が４であるリソース要求を決定し、このインデックス位置が４であるリソース要求内の宛先アドレス００００００１１を取得することにより、この支援情報（すなわち上記の表３においてＳＬＤＲＸ設定情報がＢである）が適用される端末デバイスが宛先アドレス「００００００１１」を有する第２の端末デバイスであることを知ることができる。

【0200】

なお、本願のいくつかの実施例では、この報告された支援情報リストにおける支援情報は、ページング識別子であってもよく、または、ＳＬＤＲＸ支援情報であってもよく、または、ＳＬＤＲＸ設定情報などであってもよい。なお、第１の端末デバイスがネットワーク側デバイスに報告した支援情報のコンテンツが異なる場合、第１の端末デバイス和第２の端末デバイスが果たす役割も異なる。例えば、第１の端末デバイスがネットワーク側デバイスに送信した支援情報がページング識別子である場合、この第１の端末デバイスは中継端末デバイスであり、第２の端末デバイスはリモート端末デバイスである。また例えば、第１の端末デバイスがネットワーク側デバイスに送信した支援情報がＳＬＤＲＸ支援情報である場合、この第１の端末デバイスは送信端末デバイスであり、第２の端末デバイスは受信端末デバイスである。また例えば、第１の端末デバイスがネットワーク側デバイスに送信した支援情報がＳＬＤＲＸ設定情報である場合、この第１の端末デバイスは受信端末デバイスであり、第２の端末デバイスは送信端末デバイスである。以下、実施例に基づいてそれぞれ詳細に説明する。

【0201】

本願のいくつかの実施例では、支援情報がページング識別子である場合、ネットワーク側デバイスは、リソース要求内の宛先アドレスを取得した後、ページング識別子のページングメッセージを決定し、このページングメッセージを第１の端末デバイスを介して第２の端末デバイスに送信することができる。選択的に、本願の実施例では、この第１の端末デバイスは中継端末デバイスであり、第２の端末デバイスはリモート端末デバイスである。第２の端末デバイスがネットワーク側デバイスにページング要求を送信する場合、第２の端末デバイスは自体のページング識別子を第１の端末デバイスに送信する。第１の端末デバイスは、第２の端末デバイスから送信されたページング識別子を受信して、このページング識別子をネットワーク側デバイスに送信する。第１の端末デバイスは、ページング識別子を第２の端末デバイスの支援情報として決定し、このページング識別子を支援情報リストにセットしてネットワーク側デバイスに報告する。ネットワーク側デバイスは、この支援情報リストを受信した後、支援情報リストにおけるページング識別子に対応するインデックス識別子に基づいて、リソース要求情報リストにおけるインデックス位置に位置するリソース要求を決定し、インデックス位置に位置するリソース要求内の宛先アドレスを取得し、この宛先アドレスを有する端末デバイスはページング識別子が適用される第２の端末デバイスであり、これにより、ネットワーク側デバイスがこのページング識別子のページングメッセージを第１の端末デバイスに送信することができる。第１の端末デバイスがこのページングメッセージを第２の端末デバイスに転送する。

【0202】

本願のいくつかの実施例では、支援情報がサイドリンク不連続受信（ＳＬＤＲＸ）設定情報である場合、ネットワーク側デバイスは、第２の端末デバイスのアクティブ化時間内に、ＳＬＤＲＸ設定情報に基づいて、第２の端末デバイスへのサイドリンク送信リソースをスケジューリングする。

【0203】

選択的に、本願の実施例では、この第１の端末デバイスは受信端末デバイスであり、第２の端末デバイスは送信端末デバイスである。省電力化を図るために、ネットワーク側デバイス（例えば基地局）は、サイドリンク端末デバイスのＳＬＤＲＸ設定情報に基づいて、ＳＬＤＲＸとＵｕＤＲＸができるだけ重なるようにＵｕＤＲＸを調整することができる。このような場合、第１の端末デバイスは第２の端末デバイスから送信されたＳＬＤＲＸ設定情報を受信し、第２の端末デバイスはこのＳＬＤＲＸ設定情報を受容するか否かを決定する。第１の端末デバイスがこのＳＬＤＲＸ設定情報を受容すると決定した場合、第１の端末デバイスは、このＳＬＤＲＸ設定情報を第２の端末デバイスの支援情報として決定し、この支援情報を支援情報リストにセットしてネットワーク側デバイスに報告する必要がある。ネットワーク側デバイスは、この支援情報リストを受信した後、支援情報リストにおけるＳＬＤＲＸ設定情報に対応するインデックス識別子に基づいて、リソース要求情報リストにおけるインデックス位置に位置するリソース要求を決定し、インデックス位置に位置するリソース要求内の宛先アドレスを取得し、この宛先アドレスを有する端末デバイスはこのＳＬＤＲＸ設定情報が適用される第２の端末デバイスであり、これにより、ネットワーク側デバイスがこの第２の端末デバイスのアクティブ化時間内に、ＳＬＤＲＸ設定情報に基づいて、この第２の端末デバイスへのサイドリンク送信リソースをスケジューリングすることができる。

【0204】

本願のいくつかの実施例では、支援情報がＳＬＤＲＸ支援情報であり、ＳＬＤＲＸ支援情報がアドバイスされたＳＬＤＲＸ設定情報を含む場合、ネットワーク側デバイスはこのＳＬＤＲＸ支援情報に基づいて、第２の端末デバイスのＳＬＤＲＸ設定情報を決定する。

【0205】

選択的に、この第１の端末デバイスは送信端末デバイスであり、第２の端末デバイスは受信端末デバイスである。省電力化を図るために、ネットワーク側デバイス（例えば基地局）は、サイドリンク端末デバイスのＳＬＤＲＸ設定情報に基づいて、ＳＬＤＲＸとＵｕＤＲＸができるだけ重なるようにＵｕＤＲＸを調整することができ、ここで、このＳＬＤＲＸ設定情報は受信端末デバイスから送信されたＳＬＤＲＸ支援情報においてアドバイスされたＳＬＤＲＸ設定情報であってもよい。

【0206】

例えば、ユニキャストのＳＬＤＲＸは送信端末デバイス（例えば本願の実施例の第１の端末デバイス）によって受信端末デバイス（例えば本願の実施例の第２の端末デバイス）に送信されるため、受信端末デバイスはＳＬＤＲＸ支援情報を送信端末デバイスに送信することができ、このＳＬＤＲＸ支援情報はアドバイスされたＳＬＤＲＸ設定情報を含み、これにより、送信端末デバイスが接続状態にある場合、受信されたＳＬＤＲＸ支援情報をネットワーク側デバイス（例えば基地局）に報告して、ネットワーク側デバイス（例えば基地局）がこのＳＬＤＲＸ支援情報に基づいてＳＬＤＲＸ設定を决定するようにする。ネットワーク側デバイスは、支援情報リストを受信した後、支援情報リストにおけるＳＬＤＲＸ設定情報に対応するインデックス識別子に基づいて、リソース要求情報リストにおけるインデックス位置に位置するリソース要求を決定し、インデックス位置に位置するリソース要求内の宛先アドレスを取得し、この宛先アドレスを有する端末デバイスはこのＳＬＤＲＸ設定情報が適用される第２の端末デバイスであり、これにより、ネットワーク側デバイスがＳＬＤＲＸとＵｕＤＲＸができるだけ重なるようにＵｕＤＲＸを調整することにより、省電力化を図ることができる。

【0207】

【0208】

上記の本願によって提供される実施例では、それぞれ端末デバイス（例えば前述した方法実施例における第１の端末デバイス）、ネットワーク側デバイスの観点から本願の実施例によって提供される方法を説明した。上記の本願の実施例によって提供される方法における各機能を実現するために、端末デバイス（例えば前述した方法実施例における第１の端末デバイス）とネットワーク側デバイスは、ハードウェア構成、ソフトウェアモジュールを含むことができ、ハードウェア構成、ソフトウェアモジュール、またはハードウェア構成プラスソフトウェアモジュールの形態で上記各機能を実現することができる。上記の各機能のうちのある機能は、ハードウェア構成、ソフトウェアモジュール、またはハードウェア構成プラスソフトウェアモジュールの形態で実行することができる。

【0209】

図１０を参照すると、本願の実施例によって提供される通信装置１００の概略構成図である。図１０に示される通信装置１００は送受信モジュール１００１及び処理モジュール１００２を含むことができる。送受信モジュール１００１は送信モジュール及び／又は受信モジュールを含むことができ、送信モジュールは送信機能を実現するために使用され、受信モジュールは受信機能を実現するために使用され、送受信モジュール１００１は送信機能および／または受信機能を実現することができる。

【0210】

通信装置１００は端末デバイス（例えば前述した方法実施例における第１の端末デバイス）であってもよいし、端末デバイスにおける装置であってもよいし、端末デバイスにマッチングして使用可能な装置であってもよい。または、通信装置１００はネットワークデバイスであってもよいし、ネットワークデバイスにおける装置であってもよいし、ネットワークデバイスにマッチングして使用可能な装置であってもよいことが理解できる。

【0211】

通信装置１００が端末デバイス（例えば前述した方法実施例における第１の端末デバイス）である場合：本願の実施例では、送受信モジュール１００１はネットワーク側デバイスにサイドリンク（ＳＬ）リソース要求情報リスト及び支援情報リストを送信し、ここで、リソース要求情報リストに複数のリソース要求が含まれ、１つのリソース要求が１つのインデックス位置に対応し、支援情報リストに第２の端末デバイスの支援情報、及び支援情報に対応するインデックス識別子が含まれ、ここで、インデックス識別子は、リソース要求に対応するインデックス位置と対応している。

【0212】

一実現形態では、インデックス識別子は対応する支援情報に含まれている。

【0213】

可能な一実現形態では、処理モジュール１００２は前記リソース要求の前記リソース要求情報リストにおけるインデックス位置を決定し、前記インデックス位置に基づいて、前記支援情報リストにおいて、前記支援情報に対応するインデックス識別子をセットする。

【0214】

【0215】

可能な一実現形態では、処理モジュール１００２は前記支援情報を決定する。

【0216】

可能な一実現形態では、前記支援情報は、
前記第２の端末デバイスから送信されたページング識別子と、前記第２の端末デバイスから送信されたサイドリンク不連続受信（ＳＬＤＲＸ）設定情報と、前記第２の端末デバイスから送信されたＳＬＤＲＸ支援情報とのうちの１つであり、ここで、ＳＬＤＲＸ支援情報はアドバイスされたＳＬＤＲＸ設定情報を含む。

【0217】

通信装置１００がネットワークデバイスである場合：本願の実施例では、送受信モジュール１００１は第１の端末デバイスから送信されたサイドリンク（ＳＬ）リソース要求情報リスト及び支援情報リストを受信し、ここで、前記リソース要求情報リストに複数のリソース要求が含まれ、１つのリソース要求が１つのインデックス位置に対応し、前記支援情報リストに第２の端末デバイスの支援情報、及び前記支援情報に対応するインデックス識別子が含まれ、ここで、前記インデックス識別子は、前記リソース要求に対応するインデックス位置と対応しており、処理モジュール１００２は前記インデックス識別子に基づいて前記リソース要求を決定し、前記リソース要求内の宛先アドレスを取得し、ここで、前記宛先アドレスを有する端末デバイスは前記第２の端末デバイスである。

【0218】

一実現形態では、インデックス識別子は対応する支援情報に含まれている。

【0219】

一実現形態では、前記支援情報リストは、前記リソース要求情報リストと同じ長さであり、前記リソース要求の前記リソース要求情報リストにおけるインデックス位置は、前記支援情報の前記支援情報リストにおけるインデックス位置と同じである。

【0220】

一実現形態では、処理モジュール１００２はさらに、前記支援情報の前記支援情報リストにおけるインデックス位置に基づいて、前記支援情報に対応するインデックス識別子を決定する。

【0221】

可能な一実現形態では、支援情報がページング識別子である場合、処理モジュール１００２はさらに前記ページング識別子のページングメッセージを決定し、送受信モジュール１００１はさらに前記ページングメッセージを前記第１の端末デバイスを介して前記第２の端末デバイスに送信する。

【0222】

可能な一実現形態では、支援情報がサイドリンク不連続受信（ＳＬＤＲＸ）設定情報である場合、送受信モジュール１００１はさらに前記第２の端末デバイスのアクティブ化時間内に、前記ＳＬＤＲＸ設定情報に基づいて、前記第２の端末デバイスへのサイドリンク送信リソースをスケジューリングする。

【0223】

可能な一実現形態では、支援情報がＳＬＤＲＸ支援情報であり、ＳＬＤＲＸ支援情報がアドバイスされたＳＬＤＲＸ設定情報を含む場合、処理モジュール１００２はさらに前記ＳＬＤＲＸ支援情報に基づいて、前記第２の端末デバイスのＳＬＤＲＸ設定情報を決定する。

【0224】

上記の実施例における装置について、その各モジュールが動作を実行する具体的な方式は、この方法の実施例で詳しく説明されたため、ここでは説明を省略する。

【0225】

図１１を参照すると、図１１は本願の実施例によって提供される別の通信装置１１０の概略構成図である。通信装置１１０はネットワークデバイスであってもよいし、端末デバイス（例えば前述した方法実施例における第１の端末デバイス）であってもよいし、ネットワークデバイスが上記の方法を実現することをサポートするチップ、チップシステム、またはプロセッサなどであってもよいし、端末デバイス（例えば前述した方法実施例における第１の端末デバイス）が上記の方法を実現することをサポートするチップ、チップシステム、またはプロセッサなどであってもよい。この装置は上記の方法の実施例で説明される方法を実現することができ、具体的には上記の方法の実施例の説明を参照されたい。

【0226】

通信装置１１０は、１つまたは複数のプロセッサ１１０１を含むことができる。プロセッサ１１０１は、汎用プロセッサまたは固有プロセッサなどであってよい。例えば、ベースバンドプロセッサや中央処理ユニットであってもよい。ベースバンドプロセッサは、通信プロトコルと通信データとを処理するために使用されることができ、中央処理ユニットは、通信装置（例えば、基地局、ベースバンドチップ、端末デバイス、端末デバイスチップ、ＤＵまたはＣＵなど）を制御し、コンピュータプログラムを実行し、コンピュータプログラムのデータを処理するために使用されることができる。

【0227】

選択的に、通信装置１１０にはコンピュータプログラム１１０４が記憶可能である１つまたは複数のメモリ１１０２がさらに含まれることができる、通信装置１１０が上記方法の実施例で説明された方法を実行するように、プロセッサ１１０１は、前記コンピュータプログラム１１０４を実行する。選択的に、前記メモリ１１０２にはさらにデータが記憶されることができる。通信装置１１０とメモリ１１０２は、個別に設けられてもよく、統合されてもよい。

【0228】

選択的に、通信装置１１０は、トランシーバ１１０５、アンテナ１１０６をさらに含むことができる。トランシーバ１１０５は、送受信機能を実現するために、送受信ユニット、送受信機、または送受信回路などと呼ぶことができる。トランシーバ１１０５は、受信器と送信機とを含むことができ、受信機は受信機能を実現するための受信機または受信回路などと呼ばれることができ、送信機は、送信機能を実現するための送信機や送信回路などと呼ばれることがる。

【0229】

選択的に、通信装置１１０には、１つまたは複数のインターフェース回路１１０７をさらに含まれることができる。インターフェース回路１１０７は、コード命令を受信してプロセッサ１１０１に伝送するために使用される。プロセッサ１１０１は、前記コード命令を実行することにより、通信装置１１０に上記方法の実施例で説明された方法を実行させる。

【0230】

通信装置１１０が端末デバイス（例えば前述した方法実施例における第１の端末デバイス）である場合、トランシーバ１１０５は図３におけるステップ３０１を実行し、図４におけるステップ４０１を実行し、図５におけるステップ５０１及びステップ５０３を実行し、図６におけるステップ６０１及びステップ６０３を実行し、図７におけるステップ７０１及びステップ７０３を実行する。プロセッサ１１０１は図５におけるステップ５０２を実行し、図６におけるステップ６０２を実行し、図７におけるステップ７０２を実行する。

【0231】

通信装置１１０がネットワークデバイスである場合、トランシーバ１１０５は図８におけるステップ８０１を実行し、図９におけるステップ９０１を実行する。プロセッサ１１０１は図９におけるステップ９０２及びステップ９０３を実行する。

【0232】

一実施形態では、プロセッサ１１０１には、受信および送信機能を実現するためのトランシーバが含まれることができる。例えば、このトランシーバは、送受信回路であってもよいし、インターフェースであってもよいし、インターフェース回路であるもよい。受信と送信機能を実現するための送受信回路、インターフェースまたはインターフェース回路は、別々であってもよく、統合されていてもよい。上記送受信回路、インターフェースまたはインターフェース回路は、コード／データの読み書きのために使用されるか、または、上記送受信回路、インターフェースまたはインターフェース回路は、信号の伝送または伝達のために使用されることができる。

【0233】

一実現形態では、プロセッサ１１０１は、コンピュータプログラム１１０３がプロセッサ１１０１上で実行すると、上記方法の実施例で説明された方法を通信装置１１０に実行させることができるコンピュータプログラム１１０３を記憶することができる。コンピュータプログラム１１０３は、プロセッサ１１０１内に硬化する可能性があり、この場合、プロセッサ１１０１はハードウェアによって実現される可能性がある。

【0234】

一実施形態では、通信装置１１０は、上記方法の実施例における送信または受信または通信の機能を実現可能である回路を含むことができる。本願で説明されたプロセッサとトランシーバは、集積回路（ｉｎｔｅｇｒａｔｅｄｃｉｒｃｕｉｔ、ＩＣ）、アナログＩＣ、無線周波数集積回路ＲＦＩＣ、ハイブリッド信号ＩＣ、専用集積回路（ａｐｐｌｉｃａｔｉｏｎｓｐｅｃｉｆｉｃｉｎｔｅｇｒａｔｅｄｃｉｒｃｕｉｔ、ＡＳＩＣ）、プリント基板（ｐｒｉｎｔｅｄｃｉｒｃｕｉｔｂｏａｒｄ、ＰＣＢ）、電子デバイスなどに実現されることができる。このプロセッサとトランシーバは、相補型金属酸化物半導体（ｃｏｍｐｌｅｍｅｎｔａｒｙｍｅｔａｌｏｘｉｄｅｓｅｍｉｃｏｎｄｕｃｔｏｒ、ＣＭＯＳ）、Ｎ型金属酸化物半導体（ｎＭｅｔａｌ－ｏｘｉｄｅ－ｓｅｍｉｃｏｎｄｕｃｔｏｒ、ＮＭＯＳ）、Ｐ型金属酸化物半導体（ｐｏｓｉｔｉｖｅｃｈａｎｎｅｌｍｅｔａｌｏｘｉｄｅｓｅｍｉｃｏｎｄｕｃｔｏｒ、ＰＭＯＳ）、バイポーラ接合型トランジスタ（ｂｉｐｏｌａｒｊｕｎｃｔｉｏｎｔｒａｎｓｉｓｔｏｒ、ＢＪＴ）、バイポーラＣＭＯＳ（ＢｉＣＭＯＳ）、シリコンゲルマニウム（ＳｉＧｅ）、ガリウム砒素（ＧａＡｓ）などの様々なＩＣプロセス技術で製造することもできる。

【0235】

上記の実施例で説明された通信装置は、ネットワークデバイスまたは端末デバイス（例えば前述した方法実施例における第１の端末デバイス）であってもよいが、本願で説明された通信装置の範囲はこれに限定されず、通信装置の構造は図１１に限定されないものであってもよい。通信装置は独立したデバイスであってもよいし、大きなデバイスの一部であってもよい。例えば、前記通信装置は、以下の通りであってもよい：
（１）独立した集積回路ＩＣ、またはチップ、またはチップシステムまたはサブシステム、
（２）１つまたは複数のＩＣのセットを有し、選択的に、このＩＣセットはデータ、コンピュータプログラムを記憶するための記憶部品を含むことができる。
（３）モデム（Ｍｏｄｅｍ）などのＡＳＩＣ、
（４）他のデバイスに組み込まれることができるモジュール、
（５）受信機、端末デバイス、スマート端末デバイス、携帯電話、無線デバイス、ハンドヘルド、モバイルユニット、車載デバイス、ネットワークデバイス、クラウドデバイス、人工知能デバイスなど、
（６）その他など。

【0236】

当業者はまた、本願の実施例に記載されたさまざまな例示的な論理ブロック（ｉｌｌｕｓｔｒａｔｉｖｅｌｏｇｉｃａｌｂｌｏｃｋ）とステップ（ｓｔｅｐ）が、電子ハードウェア、コンピュータソフトウェア、または両方の組み合わせによって実現できることが理解することができる。このような機能をハードウェアで実現するかソフトウェアで実現するかは、特定のアプリケーションとシステム全体の設計要件によって決定される。当業者は、それぞれの特定のアプリケーションに対して、様々な方法で実現される前記の機能を使用することができるが、この実現は、本願の実施例の保護の範囲を超えていると理解されたくない。

【0237】

本願の実施例は、前記図１０の実施例における端末デバイスとする通信装置と、ネットワークデバイスとする通信装置、または前記図１１の実施例における端末デバイスとする通信装置と、ネットワークデバイスとする通信装置とを含む通信システムをさらに提供する。

【0238】

本願は、コンピュータによって実行される場合、上記のいずれかの方法の実施例の機能を実現する命令が記憶されるコンピュータ読み取り可能な記憶媒体をさらに提供する。

【0239】

本願は、コンピュータによって実行される場合、上記のいずれかの方法の実施例の機能を実現するコンピュータプログラム製品をさらに提供する。

【0240】

上記の実施例では、ソフトウェア、ハードウェア、ファームウェア、またはそれらの任意の組み合わせによって、すべてまたは部分的に実現することができる。ソフトウェアを使用して実現される場合に、コンピュータプログラム製品の形態で全体的にまたは部分的に実現されることができる。前記コンピュータプログラム製品は、１つまたは複数のコンピュータプログラムを含む。本願の前記の実施例に従ったプロセスまたは機能は、コンピュータで前記コンピュータプログラムをロードして実行するとき、全体的にまたは部分的に生成される。前記コンピュータは、汎用コンピュータ、固有コンピュータ、コンピュータネットワーク、または他のプログラマブル装置であってもよい。前記コンピュータプログラムは、コンピュータ読み取り可能な記憶媒体に記憶されるか、または１つのコンピュータ読み取り可能な記憶媒体から別のコンピュータ読み取り可能な記憶媒体に伝送されることができ、例えば、前記コンピュータプログラムは、有線（例えば、同軸ケーブル、光ファイバ、デジタル加入者線（ｄｉｇｉｔａｌｓｕｂｓｃｒｉｂｅｒｌｉｎｅ、ＤＳＬ）または無線（例えば、赤外線、無線、マイクロ波など）を介して、１つのウェブサイト、コンピュータ、サーバ、またはデータセンターから別のウェブサイト、コンピュータ、サーバ、またはデータセンターに伝送されることができる。前記コンピュータ読み取り可能な記憶媒体は、コンピュータがアクセス可能な任意の利用可能な媒体であってもよいし、１つまたは複数の利用可能な媒体によって統合されたサーバ、データセンターなどのデータ記憶デバイスを含んでいてもよい。前記利用可能な媒体は、磁気媒体（例えば、フロッピーディスク、ハードディスク、磁気テープ）、光媒体（例えば、高密度デジタルビデオディスク（ｄｉｇｉｔａｌｖｉｄｅｏｄｉｓｃ、ＤＶＤ））、または半導体媒体（例えば、ソリッドステートハードディスク（ｓｏｌｉｄｓｔａｔｅｄｉｓｋ、ＳＳＤ））などであってもよい。

【0241】

当業者であれば、本願に係る第１、第２等の各種の数字番号は、説明の便宜的な区分のみであり、本願の実施例の範囲を限定するものではなく、優先順位も表さないことが理解することができる。

【0242】

本願の少なくとも１つは、１つまたは複数として説明することもでき、複数は、２つ、３つ、４つまたはそれ以上であってもよく、本願は限定しない。本願の実施例では、１つの技術的特徴に対して、「第１」、「第２」、「第３」、「Ａ」、「Ｂ」、「Ｃ」、及び「Ｄ」等によって当該種類の技術的特徴における技術的特徴を区別し、当該「第１」、「第２」、「第３」、「Ａ」、「Ｂ」、「Ｃ」、及び「Ｄ」に記載の技術的特徴間には前後の順序や大小の順序がない。

【0243】

本願における各表に示される対応関係は、設定されていてもよいし、予め定義されていてもよい。各表の情報の値は単なる例であり、他の値として設定することができ、本願は限定しない。情報と各パラメータとの対応関係を設定するとき、各表に示される対応関係のすべてを設定すべきものではないとは限らない。例えば、本願の表では、ある行によって示される対応関係が設定されなくてもよい。別の例として、分割、マージなどの適切な変形調整は、上記の表に基づいて行うことができる。上記の各表にタイトルに示されるパラメータの名称は、通信装置が理解可能な他の名称を採用することもでき、そのパラメータの値のや表示方式は、通信装置が理解可能な他の値や表示方式を採用することもできる。上記各表は、実現時には、他のデータ構造を採用することもでき、例えば、配列、キュー、コンテナ、スタック、線形テーブル、ポインタ、リンクテーブル、ツリー、図、構造体、クラス、ヒープ、ハッシュリスト、またはハッシュテーブルなどを採用することができる。

【0244】

本願における予め定義は、定義、予め定義、記憶、予め記憶、予め交渉、予め設定、硬化、または予め焼成として理解することができる。

【0245】

当業者であれば、本明細書に開示された実施例で説明された各例のユニットとアルゴリズムステップと併せて、電子ハードウェア、またはコンピュータソフトウェアと電子ハードウェアの組み合わせで実現できることを認識することができる。ある機能はいかにハードウェアまたはソフトウェアの方式で実行するかどうかは、技術案の特定の応用と設計制約条件によって決定される。当業者は、各特定の応用に対して異なる方法を使用して説明された機能を実現することができるが、このような実現は、本願の範囲を超えていると考えすべきではない。

【0246】

当業者が明らかに分かるように、説明の便宜と簡潔のために、上記に記載のシステム、装置及びユニットの具体的な動作プロセスは、上記方法の実施例における対応プロセスを参照することができ、ここでは説明を省略する。

【0247】

以上で説明されたように、本願の具体的な実施形態のみであるが、本願の保護範囲はこれに限定されるものではなく、当業者であらば、本願が開示した技術範囲内では、変更または置換が本願の保護範囲内に含まれるべきることを容易に想到できる。したがって、本願の保護範囲は請求項の保護範囲を基准とするべきである。

【図1】