特許6594460 | 知財ポータル「IP Force」

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

▶ パナソニック　インテレクチュアル　プロパティ　コーポレーション　オブ　アメリカの特許一覧

特許6594460近接サービスのための改善されたリレーＵＥディスカバリ

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

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

< >

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

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

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

(11)【特許番号】6594460

(24)【登録日】2019年10月4日

(45)【発行日】2019年10月23日

(54)【発明の名称】近接サービスのための改善されたリレーＵＥディスカバリ

(51)【国際特許分類】

H04W 88/04 20090101AFI20191010BHJP

H04W 92/18 20090101ALI20191010BHJP

H04W 76/14 20180101ALI20191010BHJP

H04W 48/16 20090101ALI20191010BHJP

【ＦＩ】

H04W88/04

H04W92/18

H04W76/14

H04W48/16 135

【請求項の数】14

【全頁数】52

(21)【出願番号】特願2017-567432(P2017-567432)

(86)(22)【出願日】2015年7月24日

(65)【公表番号】特表2018-524913(P2018-524913A)

(43)【公表日】2018年8月30日

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

(87)【国際公開番号】WO2017015788

(87)【国際公開日】20170202

【審査請求日】2018年4月18日

(73)【特許権者】

【識別番号】514136668

【氏名又は名称】パナソニックインテレクチュアルプロパティコーポレーションオブアメリカ

【氏名又は名称原語表記】ＰａｎａｓｏｎｉｃＩｎｔｅｌｌｅｃｔｕａｌＰｒｏｐｅｒｔｙＣｏｒｐｏｒａｔｉｏｎｏｆＡｍｅｒｉｃａ

(74)【代理人】

【識別番号】110002952

【氏名又は名称】特許業務法人鷲田国際特許事務所

(72)【発明者】

【氏名】バスマリックプラティーク

(72)【発明者】

【氏名】ロアーヨアヒム

(72)【発明者】

【氏名】堀貴子

(72)【発明者】

【氏名】ワンリレイ

【審査官】横田有光

(56)【参考文献】

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

【文献】特表２０１４−５０５４２１（ＪＰ，Ａ）

【文献】 CATT，Considerations about ProSe UE-UE Relays[online]，3GPP TSG-SA WG2#104 S2-142853，２０１４年７月１１日，[検索日2019.02.01], インターネット<URL:http://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_104_Dublin/Docs/S2-142853.zip>, 3節

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

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

Ｈ０４Ｗ４／００−９９／００

３ＧＰＰＴＳＧＲＡＮＷＧ１−４

ＳＡＷＧ１−４

ＣＴＷＧ１、４

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

【請求項1】

移動体通信ネットワーク内でリレーディスカバリに関与させるためのリレーユーザ機器であって、
遠隔ユーザ機器とのダイレクトサイドリンク接続を介したダイレクト通信と、前記遠隔ユーザ機器と前記移動体通信ネットワーク内の無線基地局との間の通信の中継と、前記遠隔ユーザ機器との間および／または前記無線基地局との間における過負荷状況が存在するリンク方向の判定と、前記過負荷状況が存在する場合におけるさらなる遠隔ユーザ機器の中継の防止と、を行うプロセッサと、
前記判定された前記過負荷状況が存在するリンク方向を示す情報を含むリレーディスカバリメッセージを送信する送信機と、
を備える、
リレーユーザ機器。

【請求項2】

前記過負荷状況は、前記リレーユーザ機器のプロセッサ、前記リレーユーザ機器のメモリ、前記リレーユーザ機器のポート、前記リレーユーザ機器の論理チャネルＩＤのうちの少なくとも１つに関する、
請求項１に記載のリレーユーザ機器。

【請求項3】

前記プロセッサは、前記過負荷状況が存在しなくなるであろう時点を推定し、
前記リレーディスカバリメッセージは、前記推定された前記過負荷状況が存在しなくなるであろう時点を判定するための情報をさらに含む、
請求項１または２に記載のリレーユーザ機器。

【請求項4】

前記遠隔ユーザ機器からリレー要請メッセージを受信する受信機を備え、
前記送信機は、
前記受信機が前記リレー要請メッセージを受信した場合に前記リレーディスカバリメッセージを送信する、
または、定期的に前記リレーディスカバリメッセージを送信する、
請求項１〜３のいずれか一項に記載のリレーユーザ機器。

【請求項5】

移動体通信ネットワーク内でリレーユーザ機器を発見するための遠隔ユーザ機器であって、
前記リレーユーザ機器では、前記遠隔ユーザ機器とのダイレクトサイドリンク接続を介したダイレクト通信と、前記遠隔ユーザ機器と前記移動体通信ネットワーク内の無線基地局との間の通信の中継と、前記遠隔ユーザ機器との間および／または前記無線基地局との間における過負荷状況が存在するリンク方向の判定と、前記過負荷状況が存在する場合におけるさらなる遠隔ユーザ機器の中継の防止と、前記判定された前記過負荷状況が存在するリンク方向を示す情報を含むリレーディスカバリメッセージの送信と、が行われ、
前記リレーディスカバリメッセージを受信する受信機と、
前記リレーディスカバリメッセージに前記過負荷状況が存在するリンク方向を示す情報が含まれる場合、前記リレーディスカバリメッセージの送信元の前記リレーユーザ機器を中継に選択しない、プロセッサと、
を備える、
遠隔ユーザ機器。

【請求項6】

移動体通信ネットワーク内でリレーユーザ機器をディスカバリするための方法であって、
前記リレーユーザ機器は、
遠隔ユーザ機器とのダイレクトサイドリンク接続を介したダイレクト通信を行うステップと、
前記遠隔ユーザ機器と前記移動体通信ネットワーク内の無線基地局との間の通信を中継するステップと、
前記遠隔ユーザ機器との間および／または前記無線基地局との間における過負荷状況が存在するリンク方向を判定するステップと、
前記過負荷状況が存在する場合におけるさらなる遠隔ユーザ機器の中継を防止するステップと、
前記判定された前記過負荷状況が存在するリンク方向を示す情報を含むリレーディスカバリメッセージを送信するステップと、
を含む、
方法。

【請求項7】

前記過負荷状況は、前記リレーユーザ機器のプロセッサ、前記リレーユーザ機器のメモリ、前記リレーユーザ機器のポート、前記リレーユーザ機器の論理チャネルＩＤのうちの少なくとも１つに関する、
請求項６に記載の方法。

【請求項8】

前記リレーユーザ機器は、前記過負荷状況が存在しなくなるであろう時点を推定するステップを含み、
前記リレーディスカバリメッセージは、前記推定された前記過負荷状況が存在しなくなるであろう時点を判定するための情報をさらに含む、
請求項６または７に記載の方法。

【請求項9】

前記リレーユーザ機器は、
前記リレーディスカバリメッセージを送信するステップを、
前記遠隔ユーザ機器からリレー要請メッセージを受信した場合に実行する、
または、定期的に実行する、
請求項６〜８のいずれか一項に記載の方法。

【請求項10】

前記リレーユーザ機器は、
前記過負荷状況が存在する場合におけるさらなる遠隔ユーザ機器の中継を防止するステップにおいて、ルータ広告メッセージを送信しない、
請求項６〜９のいずれか一項に記載の方法。

【請求項11】

前記遠隔ユーザ機器は、
前記過負荷状況が存在するリンク方向を示す情報を含む前記リレーディスカバリメッセージを受信した場合、前記リレーユーザ機器を介して中継される前記ダイレクト通信の優先度を判定し、
前記判定された優先度が所定の閾値以下である場合、前記ダイレクト通信を停止して異なるリレーユーザ機器を選択するステップを実行し、
前記判定された優先度が前記所定の閾値より高い場合、当該ダイレクト通信の停止および異なるリレーユーザ機器の選択のステップを実行しない、
請求項６〜１０のいずれか一項に記載の方法。

【請求項12】

前記リレーユーザ機器は、
前記遠隔ユーザ機器との間に前記ダイレクトサイドリンク接続を確立し、前記遠隔ユーザ機器に対するリレーとしての役割を果たして通信を中継する、
請求項６〜１１のいずれか一項に記載の方法。

【請求項13】

前記リレーディスカバリメッセージは、前記遠隔ユーザ機器が、前記リレーユーザ機器、および、前記リレーユーザ機器が提供するサービス、を発見するために使用される以下の情報、
・タイプ：前記リレーディスカバリメッセージのタイプ
・アナウンサ情報および被発見者情報：前記リレーユーザ機器に関する情報
・ディスカバリタイプ：ディスカバリのタイプ
・ＰｒｏＳｅリレーＵＥＩＤ：前記リレーユーザ機器の識別子
のうちの少なくとも１つを含む、
請求項６〜１２のいずれか一項に記載の方法。

【請求項14】

前記遠隔ユーザ機器は、
前記無線基地局のカバレッジ内に位置する、
または、前記無線基地局のカバレッジ外、かつ、前記無線基地局のカバレッジ内の前記リレーユーザ機器のカバレッジ内に位置する、
請求項６〜１３のいずれか一項に記載の方法。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、移動体通信ネットワーク内でのリレーユーザ機器のディスカバリのための方法に関する。本開示はまた、本明細書において記載されている方法に関与させるためのリレーユーザ機器および対応する遠隔ユーザ機器を提供することでもある。

【背景技術】

【0002】

＜ＬＴＥ（ロングタームエボリューション）＞
ＷＣＤＭＡ（登録商標）無線アクセス技術に基づく３Ｇ（第３世代移動通信システム）は、世界中で広範な規模で配備されつつある。この技術を機能強化または発展させる上での最初のステップとして、ＨＳＤＰＡ（高速ダウンリンクパケットアクセス）と、ＨＳＵＰＡ（高速アップリンクパケットアクセス）とも称するエンハンストアップリンクとが導入され、これにより、極めて競争力の高い無線アクセス技術が提供されている。

【0003】

ユーザからのますます増大する需要に対応し、新しい無線アクセス技術に対する競争力を確保する目的で、３ＧＰＰは、ＬＴＥ（ロングタームエボリューション）と称される新しい移動通信システムを導入した。ＬＴＥは、今後１０年間にわたり、データおよびメディアの高速伝送ならびに大容量の音声サポートに対するキャリアの必要を満たすように設計されている。高いビットレートを提供することができることは、ＬＴＥにとって重要な尺度である。

【0004】

ＬＴＥ（ロングタームエボリューション）に関する作業項目（ＷＩ）の仕様は、Ｅ−ＵＴＲＡ（ＥｖｏｌｖｅｄＵＭＴＳＴｅｒｒｅｓｔｒｉａｌＲａｄｉｏＡｃｃｅｓｓ（ＵＴＲＡ）：進化型ＵＭＴＳ地上無線アクセス）およびＥ−ＵＴＲＡＮ（ＥｖｏｌｖｅｄＵＭＴＳＴｅｒｒｅｓｔｒｉａｌＲａｄｉｏＡｃｃｅｓｓＮｅｔｗｏｒｋ（ＵＴＲＡＮ）：進化型ＵＭＴＳ地上無線アクセスネットワーク）と称され、最終的にリリース８（ＬＴＥリリース８）として公開される。ＬＴＥシステムは、パケットベースの効率的な無線アクセスおよび無線アクセスネットワークであり、ＩＰベースの全機能を低遅延かつ低コストで提供する。ＬＴＥでは、与えられたスペクトルを用いてフレキシブルなシステム配備を達成するために、１．４ＭＨｚ、３．０ＭＨｚ、５．０ＭＨｚ、１０．０ＭＨｚ、１５．０ＭＨｚ、および２０．０ＭＨｚのような、スケーラブルな複数の送信帯域幅が指定されている。ダウンリンクには、ＯＦＤＭ（直交周波数分割多重化）をベースとする無線アクセスが採用されている。なぜなら、かかる無線アクセスは、低いシンボルレートのため本質的にＭＰＩ（マルチパス干渉）を受けにくく、また、ＣＰ（サイクリックプレフィックス）を使用しており、さらに、様々な送信帯域幅の設定に対応可能だからである。アップリンクには、ＳＣ−ＦＤＭＡ（シングルキャリア周波数分割多元接続）をベースとする無線アクセスが採用されている。なぜなら、ＵＥ（ユーザ機器）の送信出力が限られていることを考えれば、ピークデータレートを向上させるよりも広いカバレッジエリアを提供することが優先されるからである。ＬＴＥリリース８／９では、ＭＩＭＯ（多入力多出力）チャネル伝送技術を含む数多くの主要なパケット無線アクセス技術が採用され、高効率の制御シグナリング構造が達成されている。

【0005】

＜ＬＴＥのアーキテクチャ＞
図１は、ＬＴＥの全体的なアーキテクチャを示している。Ｅ−ＵＴＲＡＮは、ｅＮｏｄｅＢから構成され、ｅＮｏｄｅＢは、ＵＥ向けの、Ｅ−ＵＴＲＡのユーザプレーン（ＰＤＣＰ／ＲＬＣ／ＭＡＣ／ＰＨＹ）および制御プレーン（ＲＲＣ）のプロトコルを終端処理する。ｅＮＢ（ｅＮｏｄｅＢ）は、ＰＨＹ（物理）層、ＭＡＣ（メディアアクセス制御）層、ＲＬＣ（無線リンク制御）層、およびＰＤＣＰ（パケットデータ制御プロトコル）層をホストし、これらのレイヤはユーザプレーンのヘッダ圧縮および暗号化の機能を含む。ｅＮＢは、制御プレーンに対応するＲＲＣ（無線リソース制御）機能も提供する。ｅＮＢは、無線リソース管理、アドミッション制御、スケジューリング、交渉によるアップリンクＱｏＳ（サービス品質）の執行、セル情報のブロードキャスト、ユーザプレーンデータおよび制御プレーンデータの暗号化／解読、ダウンリンク／アップリンクのユーザプレーンパケットヘッダの圧縮／復元を含む、多くの機能を実行する。複数のｅＮｏｄｅＢは、Ｘ２インターフェースによって互いに接続されている。

【0006】

複数のｅＮｏｄｅＢはまた、Ｓ１インターフェースによってＥＰＣ（進化型パケットコア）、より具体的には、Ｓ１−ＭＭＥによってＭＭＥ（移動管理エンティティ）、Ｓ１−ＵによってＳＧＷ（サービングゲートウェイ）に接続されている。Ｓ１インターフェースは、ＭＭＥ／サービングゲートウェイとｅＮｏｄｅＢとの間の多対多関係をサポートする。ＳＧＷは、ユーザデータパケットをルーティングして転送する一方、ｅＮｏｄｅＢ間のハンドオーバ時におけるユーザプレーンのモビリティアンカとしても機能し、さらに、ＬＴＥと別の３ＧＰＰ技術との間のモビリティのためのアンカ（Ｓ４インターフェースを終端させ、２Ｇ／３ＧシステムとＰＤＮＧＷとの間でトラフィックを中継する）として機能する。ＳＧＷは、アイドル状態のユーザ機器に対しては、ダウンリンクデータ経路を終端させ、そのユーザ機器へのダウンリンクデータが到着したときにページングをトリガする。ＳＧＷは、ユーザ機器のコンテキスト、たとえば、ＩＰベアラサービスのパラメータ、またはネットワーク内部ルーティング情報を管理および記憶する。さらに、ＳＧＷは、合法傍受の場合にユーザトラフィックの複製を実行する。

【0007】

ＭＭＥは、ＬＴＥアクセスネットワークの主要な制御ノードである。ＭＭＥは、アイドルモードのユーザ機器の追跡および再送信を含むページング手順の役割を担う。ＭＭＥは、ベアラの有効化／無効化プロセスに関与し、さらには、最初のアタッチ時と、ＣＮ（基幹ネットワーク）ノードの再配置を伴うＬＴＥ内ハンドオーバ時とに、ユーザ機器のＳＧＷを選択する役割も担う。ＭＭＥは、（ＨＳＳと対話することによって）ユーザを認証する役割を担う。ＮＡＳ（非アクセス層）シグナリングはＭＭＥにおいて終端され、ＭＭＥは、一時的なＩＤを生成してユーザ機器に割り当てる役割も担う。ＭＭＥは、サービスプロバイダのＰＬＭＮ（公衆陸上移動体ネットワーク）にキャンプオンするためのユーザ機器の認証をチェックし、ユーザ機器のローミング制約を執行する。ＭＭＥは、ＮＡＳシグナリングの暗号化／整合性保護においてネットワーク内の終端点であり、セキュリティキー管理を取り扱う。シグナリングの合法傍受も、ＭＭＥによってサポートされる。さらに、ＭＭＥは、ＬＴＥのアクセスネットワークと２Ｇ／３Ｇのアクセスネットワークとの間のモビリティのための制御プレーン機能を提供し、ＳＧＳＮからのＳ３インターフェースをＭＭＥにおいて終端させる。さらに、ＭＭＥは、ローミングするユーザ機器のためのホームＨＳＳに向かうＳ６ａインターフェースを終端させる。

【0008】

＜ＬＴＥにおけるコンポーネントキャリアの構造＞
３ＧＰＰＬＴＥシステムのダウンリンクコンポーネントキャリアは、時間−周波数領域において、いわゆるサブフレームに分割されている。３ＧＰＰＬＴＥでは、図２に示したように、各サブフレームが２つのダウンリンクスロットに分割されており、第１のダウンリンクスロットは、最初のいくつかのＯＦＤＭシンボルにおける制御チャネル領域（ＰＤＣＣＨ領域）を含んでいる。各サブフレームは、時間領域における所与の数のＯＦＤＭシンボルからなり（３ＧＰＰＬＴＥ（リリース８）では１２個または１４個のＯＦＤＭシンボル）、ＯＦＤＭシンボルそれぞれが、コンポーネントキャリアの帯域幅全体を範囲としている。したがって、ＯＦＤＭシンボルは各々、それぞれのサブキャリア上で送信される複数の変調シンボルからなる。ＬＴＥにおいて、各スロット内で送信される信号は、Ｎ^ＤＬ_ＲＢＮ^ＲＢ_ＳＣ個のサブキャリアおよびＮ^ＤＬ_ｓｙｍｂ個のＯＦＤＭシンボルのリソースグリッドによって記述される。Ｎ^ＤＬ_ＲＢは、帯域幅内のリソースブロックの数である。量Ｎ^ＤＬ_ＲＢは、セル内で設定されているダウンリンク送信帯域幅に依存し、以下を満たすべきである。

【数1】

式中、Ｎ^{ｍｉｎ，ＤＬ}_ＲＢ＝６およびＮ^{ｍａｘ，ＤＬ}_ＲＢ＝１１０はそれぞれ、現行バージョンの仕様によってサポートされる最小ダウンリンク帯域幅および最大ダウンリンク帯域幅である。Ｎ^ＲＢ_ＳＣは、１つのリソースブロック内のサブキャリアの数である。通常のサイクリックプレフィックスサブフレーム構造について、Ｎ^ＲＢ_ＳＣ＝１２およびＮ^ＤＬ_ｓｙｍｂ＝７である。

【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】

本明細書においてさらに使用される用語の定義を目的として、少なくとも以下の２つのタイプのディスカバリ手順が定義される。
・ＵＥ自主的リソース選択（後にタイプ１と称される）：ディスカバリ情報を告知するためのリソースが、非ＵＥ特異的に配分されるリソース配分手順。これは、さらに以下のことを特徴とする：
○ｅＮＢがＵＥに、ディスカバリ情報の告知に使用されるリソースプール設定を提供する。設定は、たとえば、ＳＩＢにおいてシグナリングすることができる。
○ＵＥは、示されているリソースプールから無線リソースを自主的に選択し、ディスカバリ情報を告知する。
○ＵＥは、各ディスカバリ期間中に、ランダムに選択されたディスカバリリソース上でディスカバリ情報を告知することができる。
・スケジューリングされたリソース配分（後にタイプ２と称される）：ディスカバリ情報を告知するためのリソースが、ＵＥごとに特異的に配分されるリソース配分手順。これは、さらに以下のことを特徴とする：
○ＲＲＣ＿ＣＯＮＮＥＣＴＥＤであるＵＥが、ＲＲＣを介してｅＮＢからディスカバリ情報の告知のためのリソースを要求することができる。ｅＮＢは、ＲＲＣを介してリソースを割り当てる。
○リソースは、ＵＥにおいてモニタリングのために設定されているリソースプール内で配分される。

【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】

【非特許文献1】3GPP TS 36.211, "Evolved Universal Terrestrial Radio Access (E-UTRA); Physical Channels and Modulation (Release 8), current version 12.6.9

【非特許文献2】3GPP TR 36.843, version 12.0.1

【非特許文献3】3GPP TR 23.713 current version v1.4.0

【非特許文献4】3GPP 36.300, current version 13.3.0

【非特許文献5】3GPP, technical standard 36.212, version 12.4.0

【非特許文献6】3GPP TS 23.303, current version 13.0.0

【非特許文献7】TS 23.401

【非特許文献8】TS 23.003

【非特許文献9】TS 23.221

【非特許文献10】3GPP, TS 36.331, VC50

【非特許文献11】TS 22.179 current version 13.2.0

【発明の概要】

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

【0108】

非限定的で例示的な実施形態は、遠隔ユーザ機器によってリレーユーザ機器を発見するために使用されるディスカバリメカニズムのための改善された方法を提供する。独立請求項は、非限定的で例示的な実施形態を提供する。有利な実施形態は、従属請求項の対象である。

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

【0109】

本明細書において記載されているいくつかの態様によれば、遠隔ユーザ機器によってリレーユーザ機器を発見するために実行されるディスカバリメカニズムが改善される。これらの態様を説明するための基礎において、以下の仮定が行われる。特に、リレーユーザ機器は、他の遠隔ユーザ機器とのダイレクト通信を実行することが可能であり、ならびに、他の遠隔ユーザ機器に対するリレーとして動作することが可能であると仮定される。背景技術の節の具体的で例示的な３ＧＰＰ実施形態において説明したように、ダイレクトディスカバリは一般的に、遠隔ユーザ機器によって、利用可能なリレーユーザ機器を見つけるために使用され、そのリレーユーザ機器のうちの１つが、その後セルの無線基地局に接続するためのリレーとして選択および使用されることができる。遠隔ユーザ機器と選択されたリレーユーザ機器との間に１対１接続が確立され、それを介してダイレクト通信を実行することができる。

【0110】

第１の態様によれば、リレーユーザ機器と遠隔ユーザ機器との間で使用されるディスカバリメカニズムは、リレーユーザ機器が過負荷であり、したがって、追加の遠隔ユーザ機器に対するリレーとして動作することを多少妨げられる状況に対して特に機能強化される。言い換えれば、たとえば、リレーユーザ機器がすでに１つまたは複数の遠隔ユーザ機器に対するリレーとしての役割を果たしているため、リレーユーザ機器が限界にあり、追加の（すなわち、さらなる）遠隔ユーザ機器に対するリレーとしての役割を果たすことが可能でないように、リレーユーザ機器において過負荷状況が存在する場合がある。これには、リレーユーザ機器のハードウェア（プロセッサ、メモリ、ポート、送信能力などのような）に関する、または使用可能な論理チャネルＩＤの数、利用可能なバッファサイズ（Ｌ２、Ｌ３などでの）、残りの物理層データ送信能力のような、他の問題に関する過負荷状況のような、様々な理由があり得る。たとえば、さらなる遠隔ユーザ機器に対するリレーとしての役割を果たすための追加の接続を設定するために利用可能であるさらなる論理チャネルＩＤが存在しない。

【0111】

遠隔ユーザ機器がリレーのこの過負荷状況に関して知らない場合、遠隔ユーザ機器はこの過負荷のリレーユーザ機器を選択する可能性があり、したがって、最終的にこの特定の過負荷のリレーユーザ機器をリレーとして使用することが可能でないであろう。その場合、この第１のリレーユーザ機器の選択が失敗した後に、別のリレーユーザ機器を選択する必要があり、したがって、リレー選択工程の遅れを招く。さらに、リレーにおける処理負荷が、過負荷状況のためその後、機能しなくなると想定される遠隔ユーザ機器によって開始される、対応する接続要求によって増大される。

【0112】

第１の態様によれば、リレーユーザ機器は、リレーユーザ機器において過負荷状況が存在するか否かを判定するように機能強化される。

【0113】

過負荷状況は、すでに上記でリストした様々な理由（たとえば、プロセッサ、メモリ、論理チャネルＩＤ、メモリ／バッファサイズ、Ｌ１送信能力）のうちの１つまたは複数のために存在することができ、リレーユーザ機器は、たとえば、これらを１つずつ、または同時にチェックすることができる。いずれにせよ、リレーユーザ機器は、それがさらなる遠隔ユーザ機器に対するリレーとしての役割を果たすことが可能であるか否かを、または、その部品のいずれかが過負荷であるか否かを、したがって、さらなる遠隔ユーザ機器に対するリレーとしての役割を果たすことが不可能である（または、少なくとも不適切である）か否かを判定するように、それ自身をモニタリングすることになる。

【0114】

この文脈における過負荷状況は、リレーユーザ機器がさらなる遠隔ユーザ機器に対するリレーとしての役割を果たすのを阻害される、すなわち、さらなる遠隔ユーザ機器に対するリレーとしての役割を果たすことを受諾するのを阻害される、一時的な状況として理解されるべきである。また、その状況は、交互に急速に変化することができるという点でも一時的である。この文脈における過負荷状況は付加的に、リレーユーザ機器自身における中継処理によって引き起こされるとして理解されることができる。たとえば、リレーユーザ機器がすでに１つまたは複数の遠隔ユーザ機器に対するリレーとしての役割を果たしており、したがって「過負荷」であり、たとえば、さらなる遠隔ユーザ機器の通信データを中継するためのさらなる接続に割り当てられるために利用可能であるポートまたは論理チャネルＩＤがこれ以上存在しない。

【0115】

このように、過負荷状況は、たとえば、一般的に、上記で説明したような過負荷状況の場合のように、低であることと高であることとの間で急速に変化するものではない低バッテリから区別すべきである。このことは、たとえば、原則として時間とともにまったく変化しない、または、めったにないが、誰かオペレータによって、たとえば、ＵＳＩＭを無線で再設定することによって管理される、リレーユーザ機器の能力と対照的でもある。

【0116】

この過負荷判定は、リレーによって、たとえば、一定の間隔で、または所定の時間に実行されることができる。たとえば、過負荷判定は、少なくとも、リレーディスカバリメッセージが送信／ブロードキャストされるべきであるたびに（適時）実行され得る。いずれにせよ、リレーユーザ機器は、以下において説明されているように過負荷状況をモニタリングし、それに従って応答する。

【0117】

特に、リレーユーザ機器によって送信／ブロードキャストされるリレーディスカバリメッセージは、前に判定したように、リレーユーザ機器が過負荷状況にあるか否かに関する情報を提供する過負荷インジケーションを含むように拡張される。過負荷インジケーション値は、リレーユーザ機器における過負荷状況に従って設定され、たとえば、一方の値が、過負荷状況が存在しないことを示し、他方の値が反対に、過負荷状況が存在することを示す。これに応じて、リレーディスカバリメッセージは、リレーユーザ機器の過負荷状態を示しており、したがって、遠隔ユーザ機器によってリレー（再）選択手順中に使用することができる。

【0118】

特に、遠隔ユーザ機器は、リレーディスカバリメッセージ内の上述した過負荷インジケーションを使用することによって、現在過負荷状態にあり、さらなる遠隔ユーザ機器に対するリレーとしての役割を果たしたいと望むことができない／望まないことをすでに示しているリレーユーザ機器を、好ましくは選択（および接続）すべきでない。それゆえ、遠隔ユーザ機器が過負荷のリレーユーザ機器を選択せず、したがって、それに接続することを避けるため、リレー（再）選択工程の遅れは生じず、リレーユーザ機器において追加の処理負荷も招かない。

【0119】

上記で説明したような第１の態様は、背景技術の節の詳細な実施形態において一般的に説明したように、モデルＡおよびモデルＢによるディスカバリ手順に等しく適用可能である。特に、リレーディスカバリメッセージは、第１の態様に従って過負荷インジケーションによって拡張されているが、遠隔ユーザ機器からリレー要請メッセージを受信した後に送信されるメッセージであることもでき（すなわち、モデルＢ）、または、リレーによって定期的に送信されるメッセージである（すなわち、モデルＡ）。それゆえ、第１の態様は、両方のディスカバリモデルに有利に適用可能である。

【0120】

第１の態様の変形形態において、リレーディスカバリメッセージは、過負荷インジケーションに加えて、過負荷状況に関する追加の情報によってさらに拡張することができる。たとえば、過負荷状況が持続すると推定される残り時間に関する情報を、リレーディスカバリメッセージに含むことができる。または、過負荷状況を限定する特定のアップリンクおよび／またはダウンリンク方向に関する情報を、リレーディスカバリメッセージに含むことができ、たとえば、遠隔ユーザ機器から／へのリレーユーザ機器への／からのリンクを混雑させることができ（すなわち、ＰＣ５インターフェース上のアップリンク／ダウンリンク）、かつ／または、リレーユーザ機器から／への無線基地局への／からのリンクを混雑させることができる（すなわち、Ｕｕインターフェース上のアップリンク／ダウンリンク）。

【0121】

第２の態様によれば、上述した第１の態様とは異なるが、リレーユーザ機器のためのダイレクトディスカバリ手順も改善される。この第２の態様を論じるために、基本的に、第１の態様についてと同じ仮定を行うことができる。たとえば、リレーユーザ機器は、他のユーザ機器とのダイレクト通信を実行することが可能であり、ならびに、他の遠隔ユーザ機器に対するリレーとして動作することが可能であるべきである。第１の態様についてと同じように、第２の態様もまた、リレーユーザ機器が過負荷状況にあるか否かを判定することを含む。繰返しを回避するために、過負荷状況の判定が伴うこと（たとえば、いつどのようになど）について、上記の論述を参照する。

【0122】

リレーディスカバリメッセージを過負荷インジケーションによって拡張する代わりに、第２の態様は、リレーユーザ機器がすでにリレーとしてサービスしている遠隔ユーザ機器が引き続きリレーディスカバリメッセージを受信することができる一方、他のまだサービスされていない遠隔ユーザ機器が、ひいては現在は自身がサービスしていない遠隔ユーザ機器にとっては実際的に認識できない過負荷のリレーを発見しないように、リレーが過負荷であると判定されているか否かに応じて、リレーディスカバリメッセージを異なるリソース上で送信することを予期する。

【0123】

より詳細には、上述したように、異なる無線リソースセットが、リレーによってリレーディスカバリメッセージを送信するために使用されるべきである。すべての遠隔ユーザ機器（たとえば、サービスされている、およびサービスされていない）がこのリレーユーザ機器からリレーディスカバリメッセージを受信するための無線リソースをモニタリングすることができるように、第１の無線リソースセットを設定することができ、たとえば、無線基地局のカバレッジ内またはカバレッジ外の任意の遠隔ユーザ機器がリレーディスカバリメッセージをモニタリングする第１の無線リソースセットを知っているように、適切な無線リソースを予め設定することができる（たとえば、ＵＥのＵＳＩＭにおいて）。

【0124】

それと対照的に、過負荷であるときにリレーによってリレーディスカバリメッセージを送信するために使用されるべきである、第２の無線リソースセットは、すでにこのリレーユーザ機器によってサービスされている遠隔ユーザ機器によってのみモニタリングされるべきである。それゆえ、第２の無線リソースセットではなく第１の無線リソースセットをリッスンしている、過負荷のリレーユーザ機器の発見を試行している（モデルＡまたはモデルＢいずれかによる）任意の新たな遠隔ユーザ機器は、したがって、過負荷状況にあるリレーユーザ機器から送信されているリレーディスカバリメッセージを受信しない。他方、過負荷でないリレーユーザ機器は、リレーディスカバリメッセージを送信するために一般的な第１の無線リソースセットを使用することになり、したがって、適切なリレーの発見を試行している任意の新たな遠隔ユーザ機器にとって認識できる。

【0125】

リレーの過負荷状態に応じてリレーディスカバリメッセージを送信するための２つの無線リソースセット間で区別することによって、すでにサービスされている遠隔ユーザ機器にとって認識できるままである一方、適切なリレーユーザ機器の発見を現在試行している任意の新たな遠隔ユーザ機器に対しては一時的に認識できなくなることが可能である。

【0126】

さらに、サービスされている遠隔ユーザ機器が、リレーにおいて過負荷状況が存在するときでも、すなわちリレーユーザ機器と遠隔ユーザ機器の時間および周波数を同期させるためにリレーディスカバリメッセージを使用する場合に、引き続きリレーディスカバリメッセージを受信することが可能であることは特に有利である。

【0127】

第２の態様の１つの例示的な変形形態によれば、第２の無線リソースセットは、予め設定するのではなく、リレーユーザ機器によって決定することができ、その後、サービスされている遠隔ユーザ機器に通知される。それによって、リレーユーザ機器によって現在サービスされている遠隔ユーザ機器のみが、リレーが過負荷状態にあるときにリレーディスカバリメッセージを求めてモニタリングすべき第２のリソースセットに関して知っていることが保証される。

【0128】

第２の態様のさらなる例示的な変形形態によれば、リレーによってすでにサービスされている遠隔ユーザ機器は、リレーの過負荷状態に応じて、第１のリソースセットであろうと第２のリソースセットであろうと、一方のリソースセットのみをモニタリングする。上記目的のために、サービスされている遠隔ユーザ機器は、リレーディスカバリメッセージを受信するために「正しい」無線リソースセットがモニタリングされるように、過負荷状態の変化に関して通知されなければならない。有利には、サービスされている遠隔ユーザ機器は、両方の無線リソースセットではなく、過負荷状態に応じてリレーユーザ機器によってリレーディスカバリメッセージを送信するために実際に使用されている適切なリソースセットをモニタリングする必要があるのみである。

【0129】

また、第２の態様も、背景技術の節の詳細な実施形態において一般的に説明したように、モデルＡおよびモデルＢによるディスカバリ手順に等しく適用可能である。特に、リレーディスカバリメッセージは、遠隔ユーザ機器からリレー要請メッセージを受信した後に（第１または第２の無線リソースセット上で）送信されるメッセージであることもできる（すなわち、モデルＢ）。または、リレーディスカバリメッセージは、リレーによって定期的に送信されるメッセージである（すなわち、モデルＡ）。それゆえ、第２の態様は、両方のディスカバリモデルに有利に適用可能である。

【0130】

第３の態様によれば、第１および第２の態様について、リレーユーザ機器のためのダイレクトディスカバリ手順が改善される。基本的に、第１および第２の態様についてと同じ仮定を行うことができる。たとえば、リレーユーザ機器は、他の遠隔ユーザ機器とのダイレクト通信を実行することが可能であり、ならびに、遠隔ユーザ機器に対するリレーとして動作することが可能であるべきである。さらに、第３の態様については、リレーユーザ機器は、リレーディスカバリメッセージを定期的に、すなわち、それぞれのリレーディスカバリメッセージ間に時間間隔をおいて送信することを含むモデルＡによるダイレクトディスカバリを実行していると仮定される。第１および第２の態様についてと同じように、第３の態様もまた、リレーユーザ機器が過負荷状況にあるか否かを判定することを含む。繰返しを回避するために、過負荷状況の判定が伴うこと（たとえば、いつどのようになど）について、上記の論述を参照する。

【0131】

第３の態様は、任意の新たな遠隔ユーザ機器が過負荷のリレーユーザ機器を発見および選択するのを妨げ／遅らせられるように、リレーが過負荷であると判定されているか否かに応じて、リレーディスカバリメッセージを異なる定期性によって送信することを予期する。特に、第３の態様によれば、リレーユーザ機器は、過負荷状況にあるときに、リレーディスカバリメッセージ送信の定期性を拡大する、すなわち、その後のリレーディスカバリメッセージの送信間の時間間隔を拡大すべきである。言い換えれば、リレーユーザ機器におけるダイレクトディスカバリメカニズムは、リレーユーザ機器が過負荷でないときと比較して過負荷状況にあるときに、リレーディスカバリメッセージをより低頻度で送信するように適合されている。第３の態様の１つの例示的な実施態様において、定期性は、リレーディスカバリメッセージが、過負荷状態にあるときにリレーユーザ機器によって実際にはそれ以上送信されないように拡大することができる。

【0132】

これに応じて、１つの一般的な第１の態様において、本明細書において開示されている技法は、移動体通信ネットワーク内での１つまたは複数のリレーユーザ機器のディスカバリのための方法を特色とする。リレーユーザ機器は、それぞれ１つまたは複数の遠隔ユーザ機器とのダイレクトサイドリンク接続を介してダイレクト通信を実行することが可能である。リレーユーザ機器は、移動体通信ネットワーク内の無線基地局に接続されており、１つまたは複数の遠隔ユーザ機器と無線基地局との間の通信を中継するように、それぞれ１つまたは複数の遠隔ユーザ機器に対するリレーとしての役割を果たすことがさらに可能である。リレーユーザ機器は、リレーユーザ機器において過負荷状況であって、リレーユーザ機器がさらなる遠隔ユーザ機器に対するリレーとしての役割を果たすことを妨げる過負荷状況が存在するか否かを判定する。リレーユーザ機器は、リレーユーザ機器において過負荷状況が存在するか否かに関する判定の結果に関する情報を提供する過負荷インジケーションを少なくとも含んでいる、リレーディスカバリメッセージを送信する。

【0133】

これに応じて、１つの一般的な第１の態様において、本明細書において開示されている技法は、移動体通信ネットワーク内でリレーディスカバリに関与させるためのリレーユーザ機器を特色とする。リレーユーザ機器は、それぞれ１つまたは複数の遠隔ユーザ機器とのダイレクトサイドリンク接続を介してダイレクト通信を実行することが可能である。リレーユーザ機器は、移動体通信ネットワーク内の無線基地局に接続されており、１つまたは複数の遠隔ユーザ機器と無線基地局との間の通信を中継するように、それぞれ１つまたは複数の遠隔ユーザ機器に対するリレーとしての役割を果たすことがさらに可能である。リレーユーザ機器のプロセッサが、リレーユーザ機器において過負荷状況であって、リレーユーザ機器がさらなる遠隔ユーザ機器に対するリレーとしての役割を果たすことを妨げる過負荷状況が存在するか否かを判定する。リレーユーザ機器の送信機が、リレーユーザ機器において過負荷状況が存在するか否かに関する判定の結果に関する情報を提供する過負荷インジケーションを少なくとも含んでいる、リレーディスカバリメッセージを送信する。

【0134】

【0135】

これに応じて、１つの一般的な第１の態様において、本明細書において開示されている技法は、移動体通信ネットワーク内での１つまたは複数のリレーユーザ機器のディスカバリのための別の方法を特色とする。リレーユーザ機器は、それぞれ１つまたは複数の遠隔ユーザ機器とのダイレクトサイドリンク接続を介してダイレクト通信を実行することが可能である。リレーユーザ機器は、移動体通信ネットワーク内の無線基地局に接続されており、１つまたは複数の遠隔ユーザ機器と無線基地局との間の通信を中継するように、それぞれ１つまたは複数の遠隔ユーザ機器に対するリレーとしての役割を果たすことがさらに可能である。リレーユーザ機器は、リレーユーザ機器において過負荷状況であって、リレーユーザ機器がさらなる遠隔ユーザ機器に対するリレーとしての役割を果たすことを妨げる過負荷状況が存在するか否かを判定する。リレーユーザ機器は、リレーディスカバリメッセージを送信する。リレーユーザ機器において過負荷状況が存在しないと判定される場合、リレーディスカバリメッセージは、１つまたは複数の遠隔ユーザ機器によってモニタリングされている第１の無線リソースセット上で送信される。他方、リレーユーザ機器において過負荷状況が存在すると判定される場合、リレーディスカバリメッセージは、そのリレーユーザ機器をリレーとして使用していない遠隔ユーザ機器ではなくそのリレーユーザ機器をリレーとしてすでに使用している遠隔ユーザ機器によってモニタリングされている第２の無線リソースセット上で送信される。

【0136】

これに応じて、１つの一般的な第１の態様において、本明細書において開示されている技法は、移動体通信ネットワーク内でリレーディスカバリに関与させるためのリレーユーザ機器を特色とする。リレーユーザ機器は、それぞれ１つまたは複数の遠隔ユーザ機器とのダイレクトサイドリンク接続を介してダイレクト通信を実行することが可能である。リレーユーザ機器は、移動体通信ネットワーク内の無線基地局に接続されており、１つまたは複数の遠隔ユーザ機器と無線基地局との間の通信を中継するように、それぞれ１つまたは複数の遠隔ユーザ機器に対するリレーとしての役割を果たすことがさらに可能である。リレーユーザ機器のプロセッサが、リレーユーザ機器において過負荷状況であって、リレーユーザ機器がさらなる遠隔ユーザ機器に対するリレーとしての役割を果たすことを妨げる過負荷状況が存在するか否かを判定する。リレーユーザ機器の送信機が、リレーディスカバリメッセージを送信する。リレーユーザ機器において過負荷状況が存在しないと判定される場合、リレーディスカバリメッセージは、１つまたは複数の遠隔ユーザ機器によってモニタリングされている第１の無線リソースセット上で送信される。リレーユーザ機器において過負荷状況が存在すると判定される場合、リレーディスカバリメッセージは、そのリレーユーザ機器をリレーとして使用していない遠隔ユーザ機器ではなくそのリレーユーザ機器をリレーとしてすでに使用している遠隔ユーザ機器によってモニタリングされている第２の無線リソースセット上で送信される。

【0137】

これに応じて、１つの一般的な第１の態様において、本明細書において開示されている技法は、移動体通信ネットワーク内で１つまたは複数のリレーユーザ機器を発見するための遠隔ユーザ機器を特色とする。リレーユーザ機器は、それぞれ１つまたは複数の遠隔ユーザ機器とのダイレクトサイドリンク接続を介してダイレクト通信を実行することが可能である。リレーユーザ機器は、移動体通信ネットワーク内の無線基地局に接続されており、１つまたは複数の遠隔ユーザ機器と無線基地局との間の通信を中継するように、それぞれ１つまたは複数の遠隔ユーザ機器に対するリレーとしての役割を果たすことがさらに可能である。遠隔ユーザ機器の受信機が、第１の無線リソースセットをモニタリングし、第１の無線リソースセットは、リレーユーザ機器において、リレーユーザ機器がさらなる遠隔ユーザ機器に対するリレーとしての役割を果たすことを妨げる過負荷状況が存在しないとリレーユーザ機器が判定する場合に、リレーユーザ機器によってリレーディスカバリメッセージを送信するために使用される。遠隔ユーザ機器の受信機は、第２の無線リソースセットをモニタリングし、第２の無線リソースセットは、リレーユーザ機器において過負荷状況が存在するとリレーユーザ機器が判定する場合に、リレーユーザ機器によってリレーディスカバリメッセージを送信するために使用される。第２の無線リソースセットは、遠隔ユーザ機器がリレーユーザ機器をリレーとして使用していない場合ではなく、遠隔ユーザ機器がリレーユーザ機器をリレーとしてすでに使用している場合に、遠隔ユーザ機器によってモニタリングされる。受信機は、リレーユーザ機器からリレーディスカバリメッセージをさらに受信する。

【0138】

これに応じて、１つの一般的な第１の態様において、本明細書において開示されている技法は、移動体通信ネットワーク内での１つまたは複数のリレーユーザ機器の別のディスカバリのための方法を特色とする。リレーユーザ機器は、それぞれ１つまたは複数の遠隔ユーザ機器とのダイレクトサイドリンク接続を介してダイレクト通信を実行することが可能である。リレーユーザ機器は、移動体通信ネットワーク内の無線基地局に接続されており、１つまたは複数の遠隔ユーザ機器と無線基地局との間の通信を中継するように、それぞれ１つまたは複数の遠隔ユーザ機器に対するリレーとしての役割を果たすことがさらに可能である。リレーユーザ機器は、リレーディスカバリメッセージを間に時間間隔をおいて定期的に送信するように構成される。リレーユーザ機器は、リレーユーザ機器において過負荷状況であって、リレーユーザ機器がさらなる遠隔ユーザ機器に対するリレーとしての役割を果たすことを妨げる過負荷状況が存在するか否かを判定する。リレーユーザ機器において過負荷状況が存在しないと判定される場合、リレーユーザ機器は、リレーディスカバリメッセージを定期的に送信するための時間間隔を第１の値に設定する。リレーユーザ機器において過負荷状況が存在すると判定される場合、リレーユーザ機器は、リレーディスカバリメッセージを定期的に送信するための時間間隔を第２の値に設定し、第２の値は第１の値より高い。

【0139】

これに応じて、１つの一般的な第１の態様において、本明細書において開示されている技法は、移動体通信ネットワーク内でリレーディスカバリに関与させるためのリレーユーザ機器を特色とする。リレーユーザ機器は、それぞれ１つまたは複数の遠隔ユーザ機器とのダイレクトサイドリンク接続を介してダイレクト通信を実行することが可能である。リレーユーザ機器は、移動体通信ネットワーク内の無線基地局に接続されており、１つまたは複数の遠隔ユーザ機器と無線基地局との間の通信を中継するように、それぞれ１つまたは複数の遠隔ユーザ機器に対するリレーとしての役割を果たすことがさらに可能である。リレーユーザ機器は、リレーディスカバリメッセージを間に時間間隔をおいて定期的に送信するように構成される。リレーユーザ機器のプロセッサが、リレーユーザ機器において過負荷状況であって、リレーユーザ機器がさらなる遠隔ユーザ機器に対するリレーとしての役割を果たすことを妨げる過負荷状況が存在するか否かを判定する。プロセッサは、リレーユーザ機器において過負荷状況が存在しないと判定される場合、リレーディスカバリメッセージを定期的に送信するための時間間隔を第１の値に設定する。プロセッサは、リレーユーザ機器において過負荷状況が存在すると判定される場合、リレーディスカバリメッセージを定期的に送信するための時間間隔を第２の値に設定し、第２の値は第１の値より高い。

【0140】

開示されている実施形態の追加の恩恵および利点が、本明細書および図面から明らかとなろう。恩恵および／または利点は、本明細書および図面の開示の様々な実施形態および特徴によって個々にもたらすことができ、その１つまたは複数を得るためにすべてが与えられる必要はない。

【0141】

これらの一般的な態様および特定の態様は、システム、方法、およびコンピュータプログラム、ならびに、システム、方法、およびコンピュータプログラムの任意の組合せを使用して実装することができる。

【0142】

以下において、添付の図表および図面を参照しながら、例示的な実施形態を詳細に説明する。

【図面の簡単な説明】

【0143】

【図1】３ＧＰＰＬＴＥシステムの例示的なアーキテクチャを示す図

【図2】３ＧＰＰＬＴＥ（リリース８／９）について定義されているものとしての、サブフレームのダウンリンクスロットの例示的なダウンリンクリソースグリッドを示す図

【図3】ＰｒｏＳｅ通信のためのＰＣ５を介したレイヤ２リンクを確立する方法を概略的に示す図

【図4】オーバーレイ（ＬＴＥ）およびアンダーレイ（Ｄ２Ｄ）システムに対する送信／受信リソースの使用を示す図

【図5】２つのＵＥに関するスケジューリング割り当ておよびＤ２Ｄデータの送信を示す図

【図6】非ローミングシナリオについてのＰｒｏＳｅの例示的なアーキテクチャモデルを示す図

【図7】Ｄ２ＤＵＥが関連付けられ得る４つの異なる状態に関するセルカバレッジを示す図

【図8】デバイス間ダイレクトディスカバリのためのＰＣ５インターフェースを概略的に示す図

【図9】ＰｒｏＳｅダイレクトディスカバリのための無線プロトコルスタックを概略的に示す図

【図10】ＰｒｏＳｅＵＥ−ネットワークリレーシナリオを示す図

【図11】ＰｒｏＳｅＵＥ−ネットワークリレーのユーザプレーンプロトコルアーキテクチャを示す図

【図12】モデルＡによるＵＥ−ネットワークリレーディスカバリのための手順を例示的に示すシグナリング図

【図13】モデルＢによるＵＥ−ネットワークリレーディスカバリのための手順を例示的に示すシグナリング図

【図14】リレーディスカバリおよび１対１通信確立のためのＰｒｏＳｅＵＥ−ネットワークリレーを介したダイレクト通信を示す図

【図15】第１の実施形態の例示的な実施態様によるモデルＡによるＵＥ−ネットワークリレーディスカバリのための手順を例示的に示すシグナリング図

【図16】第１の実施形態の例示的な実施態様によるモデルＢによるＵＥ−ネットワークリレーディスカバリのための手順を例示的に示すシグナリング図

【図17】第１の実施形態の例示的な実施態様によるリレーＵＥ挙動を示すフロー図

【図18】第１の実施形態の例示的な実施態様による遠隔ＵＥ挙動を示すフロー図

【図19】第２の実施形態の例示的な実施態様によるリレーＵＥ挙動を示すフロー図

【図20】第２の実施形態の例示的な実施態様による遠隔ＵＥ挙動を示すフロー図

【図21】第３の実施形態の例示的な実施態様によるリレーＵＥ挙動を示すフロー図

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

【0144】

移動局もしくは移動ノードまたはユーザ端末もしくはユーザ機器は、通信ネットワーク内の物理エンティティである。１つのノードが、いくつかの機能エンティティを有し得る。機能エンティティとは、所定の機能セットを実施し、かつ／または、これをノードまたはネットワークの他の機能エンティティに提供するソフトウェアまたはハードウェアモジュールを指す。ノードは、ノードを、それを介してノードが通信することができる通信設備または媒体にアタッチする１つまたは複数のインターフェースを有することができる。同様に、ネットワークエンティティは、それを介して他の機能エンティティまたは対応するノードと通信することができる通信設備または媒体に機能エンティティをアタッチする論理インターフェースを有することができる。

【0145】

特許請求の範囲と本出願とを合わせた中で使用されるものとしての「リレーユーザ機器」は、別のユーザ機器（「遠隔ユーザ機器」と称される）に対するリレーとしての役割を果たすことが可能であるユーザ機器を指すものとして広範に理解されるべきである。これはまた、直接的に２つのユーザ機器の間でのダイレクト通信送信をサポートする機能をも含む（下記Ｄ２ＤまたはＰｒｏＳｅ参照）。一実施態様によれば、リレーユーザ機器は、３ＧＰＰＬＴＥ−Ａについて定義されているものとしての、および、背景技術の節において記載されているものとしてのリレー機能をサポートすべきである。上記に関連して、用語「遠隔ユーザ機器」は、リレーユーザ機器のピアとしての、すなわち、リレーがダイレクト通信をともに確立することを期待するものとしてのユーザ機器の役割を示すのみであるべきである。

【0146】

特許請求の範囲と本出願とを合わせた中で使用されるものとしての用語「無線リソース」は、時間−周波数リソースのような、物理無線リソースを指すものとして広範に理解されるべきである。

【0147】

特許請求の範囲と本出願とを合わせた中で使用されるものとしての用語「ダイレクト通信送信」は、２つのユーザ機器間での直接的な、すなわち、無線基地局（たとえば、ｅＮＢ）を介しない送信として広範に理解されるべきである。これに応じて、ダイレクト通信送信は、２つのユーザ機器間で直接的に確立される接続に使用される用語である「ダイレクトサイドリンク接続」を介して実行される。たとえば、３ＧＰＰにおいて、Ｄ２Ｄ（デバイス間）通信、またはＰｒｏＳｅ通信、またはサイドリンク通信の用語が使用される。特許請求の範囲と本出願とを合わせた中で使用されるものとしての用語「ダイレクトサイドリンク接続」は、３ＧＰＰのコンテキストにおいては、背景技術の節において記載されているＰＣ５インターフェースとして広範に理解されるべきであり、またそのように理解することができる。

【0148】

特許請求の範囲と本出願とを合わせた中で使用されるものとしての用語「過負荷状況」は、リレーがさらなる遠隔ユーザ機器に対する、すなわち、すでにサービスされている任意の（少しでも存在すれば）遠隔ユーザ機器に加えて任意の新たな遠隔ユーザ機器に対するリレーとしての役割を果たすことを妨げるか、または、深刻に阻害する、リレーユーザ機器に対して存在している特定の状況として広範に理解されるべきである。「リレーが、リレーとしての役割を果たすことを妨げるか、または、深刻に阻害する」ことの機能定義は、リレーユーザ機器が、さらなる単一の遠隔ユーザ機器に対するリレーとしての役割を果たすことが不可能であるというように狭く解釈されるべきではない。むしろ、過負荷状況は、たとえば、リレーユーザ機器の効率的な動作が保証されると理解される特定の制限を規定することによって、リレーユーザ機器にとって柔軟に定義され得る。過負荷は、プロセッサ、メモリ、ポート、論理チャネルＩＤ、アップリンク／ダウンリンクにおいて利用可能な帯域幅などのような、リレーユーザ機器のハードウェアまたはソフトウェア構成要素のいずれかを参照し得る。過負荷は、急速に変化する場合があるため、一時的なものであることを特徴とする。付加的にまたは代替的に、過負荷は、他のリレーユーザ機器にサービスすることによってリレーユーザ機器においてすでに実行されている中継処理によって引き起こされるものとして理解されることができる。用語「過負荷インジケーション」は、対応して理解されるべきである。

【0149】

ＵＥによってリレーユーザ機器を発見するために実行されるべき、現在標準化されているダイレクトディスカバリ手順は初期段階にあり、ＵＥによって他のＵＥを発見するために実行されるべきダイレクトディスカバリと同様であるが、多くの態様において依然として異なっている。本発明者らが特定した１つの欠点は、現在、特定のリレーＵＥが、たとえば、過負荷であり、したがって、新たなさらなる遠隔ＵＥに対するリレーとしての役割を果たすことができない場合に、遠隔ＵＥがそのリレーＵＥを選択することを妨げると予期されるメカニズムがないことである。たとえば、メモリプロセッサ、ポート、論理チャネルＩＤ、ＰＣ５／ｕｕインターフェースにおけるアップリンク／ダウンリンク方向において利用可能な帯域幅などのような、リレーユーザ機器の様々なソフトウェアまたはハードウェア構成要素のうちの１つまたは複数が過負荷（すなわち、その限界またはそのごく近く）であり得る。

【0150】

例示的なシナリオとしては、リレーＵＥが１つまたは複数の遠隔ＵＥにすでにサービスしており、結果として、その能力がすでに過負荷／制限され、この場合、リレーＵＥは追加の遠隔ＵＥに関心がないか、または、それに対するリレーとしての役割を果たすことさえできないということであろう。

【0151】

しかしながら、今のところ、これらのシナリオを考慮に入れるメカニズムが提供されていないため、遠隔ＵＥは、リレーの過負荷状況に関して知らないことになり、同リレーを発見した後に、接続を設定することを期待して過負荷のリレーを選択する可能性がある。結論的に、過負荷リレーは、遠隔ＵＥによるリレー選択を拒絶することができ、または、リレー選択を受諾する（したがって、リレーと遠隔ＵＥとの間でダイレクト接続が確立されることを可能にする）ときでも、過負荷リレーは、その構成要素のうちの１つまたはいくつかにおける過負荷のため、要求に応じて遠隔ＵＥにサービスすることが可能でない場合がある。このことは、遠隔ＵＥが、新たな（願わくは過負荷でない）リレーを選択するためにリレー再選択を最終的に実行しなければならないという結果になる場合があり、これには遅れを伴う。さらに、過負荷リレーに関する遠隔ＵＥの接続要求／試行は、次いでリレーにおける負荷をさらに増加させる。

【0152】

以下の例示的な実施形態は本発明者らによって、上記で説明した問題を軽減するために着想されている。

【0153】

様々な実施形態の特定の実施態様は、３ＧＰＰ規格によって与えられ、背景技術の節において部分的に説明されているような広範な仕様において実装されるべきであり、特定の重要な特徴が、様々な実施形態に付随して以下に説明されているように追加される。実施形態は、たとえば、上記背景技術の節に説明されている３ＧＰＰＬＴＥ−Ａ（リリース１０／１１／１２／１３）の通信システムのような移動体通信システムにおいて有利に使用することができるが、実施形態は、この特定の例示的な通信ネットワークにおける使用に限定されないことに留意されたい。

【0154】

これらの説明は本開示の範囲を限定するものとして理解されるべきではなく、本発明の開示をより良好に理解するための実施形態のほんの一例として理解されるべきである。特許請求の範囲において説明されているような本開示の全般的な原理を、異なるシナリオにおいて、本明細書において明示的に記載されていない様式で適用することができることを、当業者は認識するはずである。これに応じて、様々な実施形態の説明を目的として仮定されている以下のシナリオは、本発明およびその実施形態をそのように限定すべきではない。

【0155】

例示を目的として、ただし、以下の実施形態の範囲を制限すべきではないいくつかの仮定が行われる。１つには、ＰｒｏＳｅ通信、すなわち、ｅＮｏｄｅＢを介して迂回することのないＵＥ間の直接的なダイレクトＤ２Ｄ送信を実行することを可能にされるユーザ機器（ＰｒｏＳｅ使用可能ＵＥ）が想定される。さらに、このシナリオにおけるこれら（ＰｒｏＳｅ使用可能ＵＥ）のうちの少なくとも１つは、３ＧＰＰ規格のリリース１３における特定の実施態様について背景技術の節において説明されているようなリレー機能をサポートすべきである。言い換えれば、このリレーＵＥは、他の（ＰｒｏＳｅ使用可能）ＵＥ（遠隔ＵＥ）に対するリレーとしての役割を果たすことが可能であるべきであり、それによって、これらの遠隔ＵＥが、リレーを介してｅＮＢに接続することが可能にされる。

【0156】

さらに、上述したように、以下の実施形態は、３ＧＰＰＬＴＥ−Ａ（リリース１２／１３）環境内で実施することができる。様々な実施形態は主に、他の機能（すなわち、様々な実施形態によって変更されない機能）が、背景技術の節において説明されているものと正確に同じままであり得るように、または、様々な実施形態に一切影響を与えないように変更され得るように、リレーＵＥと遠隔ＵＥとの間で実行されるダイレクトディスカバリ手順への改善を提供する。たとえば、リレーＵＥとのダイレクト（リレー）通信の確立は、同じままであり得る。

【0157】

（第１の実施形態）
以下において、上記の問題を解決するための第１の実施形態を、詳細に説明する。第１の実施形態の実施態様が、図１５〜１８に関連して説明される。

【0158】

第１の実施形態によれば、過負荷インジケーションがディスカバリ手順に導入されており、リレーＵＥは、対応するリレーＵＥが過負荷であるか否かを示す（および、受信側遠隔ＵＥはそれを学習する）ことが可能になる。リレーＵＥが、過負荷インジケーションを使用することによって、リレーＵＥが過負荷であることを示す場合、遠隔ＵＥは、対応する過負荷のリレーではなく、ディスカバリ工程中に発見される別の利用可能な（過負荷でない）リレーを選択すべきである。このように、ディスカバリメカニズムを過負荷インジケーションによって拡張することによって、リレー選択を遅らせることを回避し、かつ過負荷のリレーにおける負荷をさらに増加させることを回避するように、リレーＵＥの過負荷状態をダイレクトディスカバリ中に考慮に入れることができる。

【0159】

リレーＵＥは、ハードウェアであろうとソフトウェアであろうと、いくつかの理由で過負荷であり得る。特に、リレーＵＥは、その（ハードウェア）構成要素のうちの１つまたはいくつかがすでにそれらのそれぞれの限界で動作しているために、過負荷状況にあり得る。たとえば、リレーＵＥのプロセッサ、メモリ、ポート、レイヤ２、レイヤ３で利用可能なバッファサイズが過負荷であり得る。リレーＵＥがさらなる遠隔ＵＥを中継することをサポートするには、使用可能な論理チャネルＩＤまたは必要な物理層データ送信能力が不足している、というような他の理由もあり得る。上述した理由のいずれも、リレーＵＥがさらなる遠隔ユーザ機器に対するリレーとしての役割を果たすことを妨げ得る、または少なくとも、追加の遠隔ＵＥに対するリレーとしての役割を果たすリレーＵＥの能力を深刻に制限する。

【0160】

リレーとしての役割を果たすことに対するこの妨害は、一時的な性質のものであり得、したがって、たとえばプロセッサ負荷の場合のように、交互に急速に変化することができる。また、リレーＵＥの論理チャネルＩＤは、自身の通信ＰＤＮ接続を終了するときに、または以前の遠隔ＵＥに対するリレーとしての役割を果たすことを停止するときに、突然解放されることになる。さらに、過負荷状況は、１つまたは複数の遠隔ＵＥにすでにサービスしているために、リレーＵＥにおいて引き起こされる場合もある。

【0161】

それゆえ、過負荷状況は、たとえば、それ自体は過負荷として理解すべきでない、リレーＵＥの低バッテリ状態から区別すべきである。たとえば、低バッテリは、通常は徐々に生じて問題になるのみである一方、過負荷状況の１つの特性は、それが交互に急速に変化する場合があることである。また、低バッテリの場合、リレー装置は、ｅＮＢに対してＰＰＩ（電力選好指標；非特許文献１０の”ｐｏｗｅｒＰｒｅｆＩｎｄｉｃａｔｉｏｎＣｏｎｆｉｇ”）インジケーションを使用して、バッテリを多少節約するのを援助し得るが、しかしながら、これは過負荷状況については可能でない（たとえば、ｅＮＢは、それ自体では「この」リレーによってサービスされているいくつかの遠隔ベアラを選択的に切断／解放することができないため）。

【0162】

したがって、リレーＵＥは、その構成要素のうちの１つまたはいくつかにおける過負荷を識別し、したがって、それが過負荷状況にあるか否かを判定するために、それ自身のシステムをモニタリングすべきである。これは、定期的に、または、特定の瞬間に、たとえば、リレーディスカバリメッセージを送信して遠隔ＵＥがリレーＵＥを発見することを可能にするときに（もしくは少し前に）行うことができる。リレーＵＥの過負荷状態をモニタリングすることによって、リレーＵＥは、したがって、その過負荷の現状に従ってダイレクトディスカバリ中に過負荷インジケーションの対応する値をいつでも設定することができる。

【0163】

すでに上記で示したように、本発明の第１の実施形態は、リレーＵＥによって送信されるリレーディスカバリメッセージを適切な過負荷インジケータによって拡張することによって、ダイレクトディスカバリメカニズムを改善するものとする。特に、リレーＵＥは、モデルＡまたはモデルＢに従ってディスカバリメッセージを送信しており、そのメッセージは、第１の実施形態に従って、リレーＵＥの現在の過負荷状態を反映する値を有する過負荷インジケーションを含むように拡張されている。換言すれば、リレーＵＥによって送信／ブロードキャストされる通常のリレーダイレクトディスカバリメッセージを再使用し、過負荷インジケーションによって拡張して、第１の実施形態による改善を可能にする。

【0164】

これに応じて機能強化されているディスカバリメッセージを図１５および１６において示すが、図１５は、モデルＡによるダイレクトディスカバリによる拡張リレーディスカバリ告知メッセージを開示し（図１２も参照）、図１６は、モデルＢによるダイレクトディスカバリによる拡張リレーディスカバリ応答メッセージを示す（図１３も参照）。これらの図面の両方から明らかなように、メッセージは過負荷インジケーションを含む。

【0165】

その最も単純な形態において、過負荷インジケーションは、２つの異なる状態（すなわち、過負荷である、および過負荷でない）間で区別しさえすればよく、単純な１つのビットフラグによって実装することができ、２つの値の各々がそれぞれ状態の一方を示す。無論、過負荷インジケーションは異なる実装でもよく、いくつかの他の例が下記にさらに提示される。

【0166】

図１７は、一般的な第１の実施形態によるリレーＵＥ処理を示す例示的な工程フロー図である。他方、図１８は、一般的な第１の実施形態による遠隔ＵＥ処理を示す例示的な工程フロー図である。

【0167】

リレーＵＥによって送信される（モデルＡまたはモデルＢのいずれかによる）対応するリレーディスカバリメッセージは遠隔ＵＥによって受信されるが、遠隔ＵＥは、新たな情報要素（過負荷インジケーション）を処理することが可能であり、したがって、発見したばかりのリレーＵＥが過負荷であるか否か、および、同リレーＵＥが自身のリレーとしての役割を果たすために選択されるべきであるか否かを、過負荷インジケーションから判定することができる。好ましくは無論、リレーＵＥが過負荷であるというインジケーションを受信した遠隔ＵＥは、上記過負荷のリレーＵＥを、そのディスカバリ後に選択しないでおくべきであり、むしろ異なるリレーＵＥを、自身のリレーとしての役割を果たすように選択すべきである。

【0168】

結論的に、第１の実施形態は、リレーＵＥの過負荷状態を考慮に入れ、したがって、過負荷のリレーに関する冗長な接続設定を回避し、このようにして、遠隔ＵＥのリレー（再）選択を促進させ、ならびに、過負荷のリレーＵＥにおける過剰な過負荷を軽減する、単純で効果的なメカニズムを提供する。

【0169】

第１の実施形態の有利な実施態様において、過負荷インジケーションは、リレーＵＥにおける過負荷状況に関するより詳細な情報を提供するために、さらに機能強化される。言い換えれば、リレーディスカバリメッセージは、対応するリレーＵＥが過負荷であるか否かに関する上述したインジケーションのみを提供するのではなく、さらなる利点を提供する過負荷状態に関する追加の情報を含むべきである。

【0170】

第１の実施態様によれば、リレーディスカバリメッセージは、過負荷状態の時間情報であって、（存在すれば）リレーＵＥにおいて過負荷状態がどれだけの時間持続すると予期されているかを示す時間情報を含むことができる。特に、リレーＵＥにおける過負荷状態の種類に応じて、リレーＵＥは、過負荷がどれくらい持続することになるかを確実に推定することが可能である。たとえば、過負荷がリレーユーザ機器における残りの論理チャネルＩＤの不足のためであり、かつ、特定のＰＤＮ接続の終了（および、したがって、論理チャネルＩＤの解放）がすぐに予期されることになる場合には、リレーＵＥは、過負荷状況が特定の時間内に存在しなくなることをすでに予期することができる。上記の場合、リレーディスカバリメッセージは、遠隔ＵＥがいつリレーＵＥの過負荷状況が終了すると予期することができるかに関する情報を付加的に提供することができる。この時間情報は、前述した過負荷インジケータと別個に、または、あわせてリレーディスカバリメッセージに符号化することができる。たとえば、過負荷インジケーションは、依然として単純な１つのビットフラグとして実装することができる一方、時間情報は、たとえば、ｘビットフィールド（多少粒度が細かい時間インジケーションを可能にする）によって実装することができる。他方、０の時間は、過負荷状態が存在しないというインジケーションとして遠隔ＵＥによって理解されることができる一方、０より大きい（異なる）任意の時間インジケーションは、リレーＵＥが過負荷であることを示すものとして理解されるという点で、過負荷は、時間情報に非明示的に含め得る。そのような時間インジケーションをリレーディスカバリメッセージに含めることが必ずしも賢明であるわけでもないように、そのような時間インジケーションが特定の過負荷理由で可能でない場合があることに留意されたい。これに応じて、そのような時間通信は、論理チャネルＩＤが存在しないような、特定の過負荷状態についてのみリレーディスカバリメッセージに含め得るが、他の過負荷状態については含めない。

【0171】

第２の実施態様によれば、リレーディスカバリメッセージは、過負荷状態の方向情報を含むことができ、この方向情報は、（存在すれば）過負荷を限定する特定の方向を示す。代替的に無論、方向情報は、過負荷の方向ではなく、むしろ反対に過負荷でない方向を示すこともできる。特に、たとえば、プロセッサまたはメモリ過負荷が両方の中継方向（ＰＣ５および／またはＵｕインターフェースにおけるアップリンク／ダウンリンク）に影響する可能性が高いのに対して、他の過負荷状態は、特定の中継方向の一方、すなわちＰＣ５インターフェースを介するアップリンクもしくはダウンリンク（遠隔ＵＥとリレーＵＥとの間；図６、１０もしくは１１参照）またはＵｕインターフェースを介するアップリンク／ダウンリンク（リレーＵＥとｅＮｏｄｅＢとの間；図６、１０もしくは１１参照）のみに限定され得る。この文脈において、一般的に、３つの異なるタイプのＵＥが存在することに留意されたい（非特許文献１１参照）：受信／送信ともに可能、送信のみ可能、受信のみ可能。したがって、たとえば、すでに１つまたはいくつかの受信／送信専用の遠隔ＵＥに対するリレーとしての役割を果たしているとき、リレーＵＥは、さらなる受信／送信専用の遠隔ＵＥをサポートすることは可能でない場合があるが、他方、その他の方向における中継、すなわち送信／受信専用の遠隔ＵＥをサポートすることは十分可能であり得る。より一般的には、特定のインターフェース（ＰＣ５またはＵｕ）を介するリレーＵＥの残りの送信／受信能力が制限され、したがって、１つの特定の方向にのみ過負荷状態を引き起こす場合がある。これに応じて、残りの送信／受信能力に応じて、リレーＵＥは、送信専用のＵＥまたは受信専用のＵＥにサービスすることが可能であり得るのみであり、その逆は可能ではない。

【0172】

リレーディスカバリメッセージに過負荷状態に対する方向情報を含めることによって、遠隔ＵＥに過負荷状況が関係する特定の方向に関して通知することが可能である。上述したように、方向インジケーションは、アップリンクとダウンリンクとの間で区別すること（たとえば、１ビットフィールドを介して）ほど単純であり得、この場合、たとえば、リレーディスカバリメッセージに方向情報が存在しないことは、過負荷状況がダウンリンク方向およびアップリンク方向の両方に関することを意味するものとなる。代替的に、方向情報は、アップリンクもしくはダウンリンクのみに、または、アップリンクおよびダウンリンクの両方に関する過負荷間で区別し得る。さらに、方向情報は、アップリンク／ダウンリンクがＰＣ５インターフェースおよび／またはＵｕインターフェースに関するか否かを区別することさえできる。このように、本明細書において使用されるものとしての用語「アップリンク」および「ダウンリンク」は、Ｕｕインターフェースのみを指すものとして理解されるべきではなく、むしろＰＣ５インターフェースにも適用可能である。方向情報は、時間情報と同様に、過負荷インジケーションと別個に、または、あわせて示すことができる。２ビットを使用することによる複合インジケーションを考えると、４つの可能なビット組合せのうちの１つは、リレーＵＥが過負荷でないというインジケーションと関連付けることができ、一方、４つの可能なビット組合せのうちの残りの３つは、それぞれ、アップリンク方向のみの過負荷、ダウンリンク方向のみの過負荷、ならびにアップリンク方向およびダウンリンク方向の両方の過負荷を示すことができる。または、さらなる拡張において、４つの可能なビット組合せのうちの残りの３つは、それぞれ、候補遠隔ＵＥが特定のリレーＵＥにアクセスするために持続性チェック（０と１との間のランダムな１０進数を引き出し、これが以下の値、たとえば、０．２５未満である場合のみ、リレーにアクセスする）を実行すべきである過負荷百分率、たとえば、２５％、５０％、７５％を示すことができる。

【0173】

このように、異なるタイプのＵＥについてと同様に、過負荷のリレーＵＥは、「受信専用」モード（たとえば、遠隔ＵＥにデータを送信するのではなく、遠隔ＵＥからデータを受信して、さらにそれをｅＮＢに中継することのみを可能にする）または「送信専用モード」（たとえば、遠隔ＵＥからデータを受信するのではなく、ｅＮＢから受信されるデータを遠隔ＵＥに送信することのみを可能にする）であることができる。

【0174】

したがって、この方向情報を受信する遠隔ＵＥは、ディスカバリ後にこの追加情報を使用して、適切なリレーを選択することができる。たとえば、遠隔ＵＥが、まったく過負荷でないリレーＵＥを好ましく選択し得るのに対して、遠隔ＵＥが選択することができる唯一の発見されたリレーが過負荷のリレーＵＥである状況があり得る。その後、過負荷が遠隔ＵＥの関心がない方向（たとえば、受信専用のＵＥにとってのアップリンク方向）のみに関する場合、このリレーＵＥは、その過負荷状態にもかかわらず、この遠隔ＵＥによって選択することができる。

【0175】

上記に関連して、過負荷の方向情報（たとえば、受信専用もしくは送信専用）、または、過負荷でなく、したがって、依然としてリレーＵＥによって受け入れられている「空き」方向は、遠隔ユーザ機器のユーザに（たとえば、スクリーンユーザインターフェース上に）表示することもできる。ユーザは、このように、この一方向に制限されているリレーを選択することが依然として望ましいか否かを選択することを可能にされ得る。逆に、過負荷状態が終了すれば、ユーザ機器は、同様にこの終了を遠隔ユーザ機器のユーザに示して、過負荷方向がＵＬおよびＤＬであったかどうか、ユーザがそれぞれ話すまたは聞く（ＰＣ４インターフェース上で）ことを可能にすることができる。

【0176】

第１の実施形態のまたさらなる実施態様によれば、過負荷状態のレベルを示すことができる。たとえば、過負荷状態は、５０％、または、７０％もしくは９０％であるとして識別することができ、すなわち、過負荷は、所定数の異なる重大度レベル間で区別される。たとえば、４つの（たとえば、２０、５０、７０および９０）または８つの異なるレベル（たとえば、１０、３０、４０、５０、６０、７０、８０、１００）を、それぞれ２または３ビットによって区別することができる。この追加のレベル情報を受信する遠隔ＵＥは、それを使用してアドミッション制御を適用することができる。たとえば、遠隔ＵＥがリレーを介する接続の確立を試行しているダイレクト通信の優先度に応じて、遠隔ＵＥは、過負荷のリレーＵＥを選択することさえあり得る。実施態様例として、アドミッション制御は、過負荷のリレーＵＥを選択するか否かを判定するために、異なる過負荷のレベルとその後比較することができる異なる優先度レベルを導入することによって達成し得る。詳細には、特定の過負荷のレベルを、ディスカバリ後に依然としてリレーＵＥを選択することが可能であるために遠隔ＵＥが有すべき最低レベルの優先度を示す特定の所定の優先度閾値と関連付けることができる。これに応じて、リレーＵＥを介するＰＤＮ接続を確立したいと望む遠隔ＵＥが、指示されているレベルの関連する優先度閾値より大きい優先度を有する場合、その遠隔ＵＥは、リレーＵＥを選択して、それとの接続を確立することができる。

【0177】

第１の実施形態の上述した実施態様（すなわち、上述した追加の種々の情報要素）のいずれも、組み合わせて使用することもできる。たとえば、過負荷に利用可能な方向情報は、レベル情報と組み合わせることができ、したがって、たとえば、アップリンク方向が９０％の過負荷である一方、ダウンリンク方向はほんの２０％過負荷であることを示すことが可能である。または、推定される時間情報は、それぞれ異なる過負荷方向について示すことができる。

【0178】

さらなる有利な実施態様は、リレーＵＥによってすでにサービスされている遠隔ＵＥにおける過負荷インジケーションの受信に関し、以下において説明する。リレーＵＥは、すでに１つまたはいくつかの遠隔ＵＥに対するリレーとしての役割を果たしていると仮定される。リレーとしてのリレーＵＥによってすでにサービスされている遠隔ＵＥも、ダイレクトディスカバリメカニズムに従ってリレーＵＥによって送信されるリレーディスカバリメッセージ（過負荷インジケーションを備えた）を受信するとさらに仮定される。たとえば、ダイレクトディスカバリメッセージは、リレーＵＥと遠隔ＵＥの時間および周波数を同期させるように使用することができ、その場合、遠隔ＵＥは、それらのタイミングおよび周波数をサービスしているリレーＵＥと同期させておくように、リレーディスカバリメッセージを連続的に受信することが可能であるべきである。過負荷インジケーションをリレーディスカバリメッセージで受信することと代替的に、リレーＵＥにすでに接続されており、かつサービスされている遠隔ＵＥは、過負荷インジケーションを異なって、たとえば、リレーＵＥからのダイレクトメッセージで受信することができる。いずれにせよ、リレーＵＥが過負荷であるというインジケーションを受信すると、サービスされている遠隔ＵＥは、過負荷のリレーＵＥとのダイレクト接続を解除することができ、任意で異なるリレーを付加的に選択することができる（必要ならば適切なダイレクトディスカバリ後に）。

【0179】

さらなる有利な実施態様において、リレーＵＥを介する低優先度通信を行っている遠隔ＵＥのみが、リレーを解放するように過負荷のリレーＵＥとのダイレクト接続を解除すべきである。逆に、リレーＵＥを介する高優先度通信のためにすでに接続されている遠隔ＵＥは、過負荷インジケーションを介してリレーＵＥが過負荷状況にあることを学習しているにもかかわらず、継続することができる。

【0180】

たとえば、「パケット単位優先度」が、各遠隔ＵＥおよびリレーＵＥを介するその通信ごとに定義される。アクセス層は、プロトコルデータユニットと関連付けられているＰｒｏＳｅパケット単位優先度を使用して、ＵＥ内送信（すなわち、同じＵＥ内での送信を待っている、異なる優先度と関連付けられているプロトコルデータユニット）に優先順位をつける。アプリケーションによって選択されるＰｒｏＳｅパケット単位優先度を尊重しつつ、媒体をスケジューリングされているまたはスケジューリングされていない送信モードでアクセスするという方法は、アクセス層の範囲内である。ＰｒｏＳｅパケット単位優先度の、たとえば８つのレベルをサポートするには、広範囲のアプリケーションをサポートすることが必要とされる。

【0181】

リレーＵＥが過負荷であることを学習すると、パケット単位優先度は、その後、リレーＵＥを介する接続を継続するか否か、または、接続を解除して、任意で継続するリレーとしての異なるリレーＵＥを選択するか否かを判定するために、サービスされている遠隔ＵＥによって、所定の優先度閾値と比較することができる。たとえば、所定の閾値優先度より高いパケット単位優先度を備えた遠隔ＵＥのみが、引き続き過負荷のリレーＵＥを使用することになる一方、より低いパケット単位優先度を備えた他の遠隔ＵＥは、中継を中断することになる（そして、代わりに異なるリレーを選択することができる）。

【0182】

過負荷インジケーションを使用して、遠隔ＵＥによる過負荷のリレーＵＥへの不要な接続試行を回避しているにもかかわらず、いくつかの遠隔ＵＥは、依然として過負荷のリレーを選択し、接続の確立を試行する場合がある。過負荷のリレーＵＥの１つの可能な応答は、遠隔ＵＥによる接続試行を受諾しないことである。特に、リレーＵＥが遠隔ＵＥからダイレクト通信要求を受信した場合（図３参照）、リレーＵＥは、通常のセキュリティアソシエーションの認証工程および確立から開始するのではなく、むしろ、たとえば、適切な拒絶応答メッセージによって応答することによって、接続試行を拒絶することができる。これには、遠隔ＵＥに対するアドレス設定（ルータ広告を送信することなど）を可能にするリレーＵＥのさらなるステップ（図１４参照）が実行されないことが等しく伴う。

【0183】

（第２の実施形態）
以下において、上記の問題を解決するための第２の実施形態を、詳細に説明する。第２の実施形態の主な概念は、第１の実施形態のそれと異なる。しかしながら、第２の実施形態の基礎原理を説明していくシナリオについて、同様の仮定を行うことができる。特に、以下において説明するように、改善されたリレーダイレクトディスカバリメカニズムを実装すべきであるＰｒｏＳｅ使用可能およびＰｒｏＳｅリレー使用可能ＵＥが想定される。

【0184】

上述した第１の実施形態についてと同じように、リレーＵＥは、その過負荷状態をモニタリングすべきである。単なる繰返しを回避するために、リレーＵＥが過負荷であるか否かを判定するステップを扱っている第１の実施形態の対応する一節を参照するが、これには、たとえば、リレーＵＥにおける過負荷状態の定義、いつ過負荷判定を実行するかなどが含まれる。

【0185】

第２の実施形態の改善されたダイレクトディスカバリメカニズムは、必ずしも、リレーディスカバリメッセージが過負荷インジケータを含むように拡張されている第１の実施形態に関してのように、背景技術の節において導入されている実際のリレーディスカバリメッセージを変更するわけではない。むしろ、リレーＵＥが過負荷であるときに、リレーディスカバリメッセージが、過負荷のリレーＵＥによってすでにサービスされている遠隔ＵＥによって受信されるのみであることを達成するように、リレーＵＥが過負荷であるか否かに応じて、リレーディスカバリメッセージを送信するための異なる送信リソースが使用される。それによって、サービスされている遠隔ＵＥは、引き続きリレーディスカバリメッセージを受信することが可能である一方、他の遠隔ＵＥ（すなわち、過負荷のリレーＵＥによって現在サービスされていない）は、過負荷のリレーＵＥによって送信されるリレーディスカバリメッセージを受信することが可能でなく、したがって、過負荷のリレーＵＥを発見することが可能でない。

【0186】

背景技術の節においてすでに説明されているように、現在標準化されているディスカバリメカニズム（中継のためではなく、ＵＥ間ダイレクト接続のため）は、ディスカバリリソース（リソースプール内からの）がｅＮｏｄｅＢによってスケジューリングされる（タイプ２）か、または、対応するリソースプール（ｅＮｏｄｅＢのセル内でＳＩＢを介してブロードキャストすることができる）からリレーＵＥによって自主的に選択される（タイプ１）かのいずれかを可能にする。

【0187】

非特許文献１０からＡＳＮ．１構造に注目することによって、一例を挙げることができる。

【0188】

＜ＳＬ−ＤｉｓｃＣｏｎｆｉｇ＞
ＩＥＳＬ−ＤｉｓｃＣｏｎｆｉｇは、サイドリンクダイレクトディスカバリのための専用の設定情報を指定する。

【0189】

＜ＳＬ−ＤｉｓｃＣｏｎｆｉｇ情報要素＞

【0190】

【表1】

【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】

具体的な実施形態において示した本開示には、多数の様々な変更および／または修正を行うことができることが、当業者には理解されるであろう。したがって、本発明の実施形態は、あらゆる点において例示的であり、本発明を制限するものではないものと考えられる。

【図1】