【文献】
General Dynamics UK Ltd,Service continuity with the UE-to-network relay[online], 3GPP TSG-RAN WG2#89bis R2-151487,インターネット<URL:http://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_89bis/Docs/R2-151487.zip>,2015年 4月20日
【文献】
Huawei, Hisilicon,The ProSe UE-to-network relay with the network authorization[online], 3GPP TSG-SA WG2#99 S2-133281,インターネット<URL:http://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_99_Xiamen/Docs/S2-133281.zip>,2013年 9月23日
(58)【調査した分野】(Int.Cl.,DB名)
移動体通信ネットワーク内でリレーユーザ機器のリレー機能を有効化するための方法であって、前記リレーユーザ機器は、それぞれ1つまたは複数の遠隔ユーザ機器とのダイレクトサイドリンク接続を介してダイレクト通信を実行することが可能であり、前記リレーユーザ機器は、前記移動体通信ネットワーク内の無線基地局によって制御される無線セル内に位置し、前記ダイレクトサイドリンク接続を介して前記1つまたは複数の遠隔ユーザ機器と前記無線基地局との間の通信を中継するために、それぞれ前記1つまたは複数の遠隔ユーザ機器のためのリレーとしての役割を果たすことを可能にするためのリレー機能をサポートし、前記方法は、
前記無線基地局によって、さらなるリレーが前記無線セル内に必要であるか否かを判定するステップと、
さらなるリレーが前記無線セル内に必要であると判定される場合、前記無線基地局によって、持続性チェック値を選択し、前記無線基地局によって、前記無線セル内でブロードキャストメッセージを送信するステップであって、前記ブロードキャストメッセージは少なくとも、さらなるリレーが前記無線セル内に必要であることを示し、前記選択されている持続性チェック値を含む、選択し送信するステップと、
前記ブロードキャストメッセージを受信したとき、前記リレーユーザ機器が、前記無線セル内でそのリレー機能を有効化するためのリレー要件が前記リレーユーザ機器によって満たされると前記リレーユーザ機器が判定する場合、かつ、前記受信されている持続性チェック値に基づいて前記リレーユーザ機器によって実行される持続性チェックが成功する場合に、そのリレー機能を有効化するステップと
を含む、方法。
前記リレーユーザ機器によって実行される、前記無線基地局から前記リレーディスカバリ手順を実行するための無線リソースを要求するステップは、前記無線リソースを求める前記要求を、前記リレーユーザ機器によって、前記無線基地局からそのリレー機能を有効化するための前記許可を要求するために前記無線基地局に送信される前記リレー有効化要求メッセージ内に含めることを含み、
前記リレーユーザ機器によって実行される、無線リソースが前記リレーディスカバリ手順を実行するために割り当てられているか否か、および、いずれの無線リソースが割り当てられているかに関する前記情報を、前記基地局から受信するステップは、前記情報を、前記無線基地局によって、前記リレーユーザ機器がそのリレー機能を有効化するための前記許可を与えるかまたは拒絶するために送信される前記リレー有効化応答メッセージ内に含めることを含み、
好ましくは前記無線基地局は、前記リレーディスカバリ手順のために無線リソースを前記リレーユーザ機器に割り当てることによって、前記リレーユーザ機器がそのリレー機能を有効化するための前記許可を与え、前記無線基地局は、前記リレーディスカバリ手順のために無線リソースを前記リレーユーザ機器に割り当てないことによって、前記リレーユーザ機器がそのリレー機能を有効化するための前記許可を拒絶する、請求項3または4に記載の方法。
前記無線セル内で前記無線基地局によって送信される前記ブロードキャストメッセージは、前記リレーユーザ機器のリレーとしての存在を告知するためのリレーディスカバリ手順のために前記リレーユーザ機器によって使用されるべき無線リソースに関する情報をさらに含み、
好ましくは、さらなるリレーが必要であるというインジケーションが、前記リレーディスカバリ手順のための前記無線リソースに関する前記情報とは別個に前記ブロードキャストメッセージ内に含まれ、または、前記リレーユーザ機器が、前記ブロードキャストメッセージ内に前記リレーディスカバリ手順のための前記無線リソースに関する前記情報が存在することから、および/もしくは、前記ブロードキャストメッセージ内に前記持続性チェック値が存在することから、さらなるリレーが必要であると判定する、請求項1〜6のいずれか一項に記載の方法。
リレー機能を有効化するための、移動体通信ネットワーク内のリレーユーザ機器であって、前記リレーユーザ機器は、それぞれ1つまたは複数の遠隔ユーザ機器とのダイレクトサイドリンク接続を介してダイレクト通信を実行することが可能であり、前記リレーユーザ機器は、前記移動体通信ネットワーク内の無線基地局によって制御される無線セル内に位置し、前記ダイレクトサイドリンク接続を介して前記1つまたは複数の遠隔ユーザ機器と前記無線基地局との間の通信を中継するために、それぞれ前記1つまたは複数の遠隔ユーザ機器のためのリレーとしての役割を果たすことを可能にするためのリレー機能をサポートし、前記リレーユーザ機器は、
前記無線基地局から、前記無線セル内にさらなるリレーが必要であることを示し、前記無線基地局によって選択されている持続性チェック値を含むブロードキャストメッセージを受信するように構成されている受信機と、
前記ブロードキャストメッセージを受信したとき、前記無線セル内でそのリレー機能を有効化するためのリレー要件が前記リレーユーザ機器によって満たされると前記リレーユーザ機器が判定する場合、かつ、前記受信されている持続性チェック値に基づいて前記リレーユーザ機器によって実行される持続性チェックが成功する場合に、前記リレーユーザ機器の前記リレー機能を有効化するように構成されているプロセッサと
を備える、リレーユーザ機器。
前記プロセッサは、前記受信機が前記ブロードキャストメッセージを受信した後で、かつ、前記プロセッサが前記リレー機能を有効化する前に、前記リレーユーザ機器がリレーとしてのその存在を告知するためのリレーディスカバリ手順を実行するために無線リソースがすでに設定されているか否かを判定するようにさらに構成されており、
前記リレーユーザ機器が前記リレーディスカバリ手順を実行するために無線リソースがすでに設定されているのではないと前記プロセッサが判定する場合、
前記プロセッサは、前記無線基地局から、前記リレーディスカバリ手順を実行するための無線リソースを要求するようにさらに構成されており、
前記受信機は、無線リソースが前記リレーディスカバリ手順を実行するために割り当てられているか否か、および、いずれの無線リソースが割り当てられているかに関する情報を、前記基地局から受信するようにさらに構成されている、請求項10または11に記載のリレーユーザ機器。
前記受信機が前記ブロードキャストメッセージを受信した後で、かつ、前記プロセッサが前記リレー機能を有効化する前に、前記リレーユーザ機器の送信機が、前記無線基地局に、前記無線基地局から前記リレーユーザ機器の前記リレー機能を有効化するための許可を要求するリレー有効化要求メッセージを送信するようにさらに構成されており、
前記受信機が、前記無線基地局から、前記リレーユーザ機器が前記リレー機能を有効化する前記許可を与えるかまたは拒絶する、リレー有効化応答メッセージを受信するようにさらに構成されており、
前記リレー機能を有効化する前記許可を与える前記リレー有効化応答メッセージが受信される場合、前記プロセッサが、前記リレー機能を有効化するように構成されている、請求項10〜12のいずれか一項に記載のリレーユーザ機器。
前記プロセッサが、無線リソースを求める要求を、前記送信機によって、前記無線基地局からそのリレー機能を有効化するための前記許可を要求するために前記無線基地局に送信されるべき前記リレー有効化要求メッセージ内に含めることによって、前記無線基地局から前記リレーディスカバリ手順を実行するための前記無線リソースを要求するように構成されており、
前記受信機が、無線リソースが前記リレーディスカバリ手順を実行するために割り当てられているか否か、および、いずれの無線リソースが割り当てられているかに関する前記情報を、前記基地局から受信することによって、前記リレーユーザ機器がそのリレー機能を有効化するための前記許可を与えるか、または、拒絶するために、前記無線基地局によって送信される前記リレー有効化応答メッセージを受信するように構成されている、請求項12または13に記載のリレーユーザ機器。
移動体通信ネットワーク内でのリレーユーザ機器のリレー機能の有効化に関与するための無線基地局であって、前記リレーユーザ機器は、それぞれ1つまたは複数の遠隔ユーザ機器とのダイレクトサイドリンク接続を介してダイレクト通信を実行することが可能であり、前記リレーユーザ機器は、前記移動体通信ネットワーク内の無線基地局によって制御される無線セル内に位置し、前記ダイレクトサイドリンク接続を介して前記1つまたは複数の遠隔ユーザ機器と前記無線基地局との間の通信を中継するために、それぞれ前記1つまたは複数の遠隔ユーザ機器のためのリレーとしての役割を果たすことを可能にするためのリレー機能をサポートし、前記無線基地局は、
さらなるリレーが前記無線セル内に実際に必要であるか否かを判定するように構成されているプロセッサであって、
一定の値範囲内で持続性チェック値を選択するようにさらに構成されている、プロセッサと、
前記無線セル内の前記1つまたは複数の遠隔ユーザ機器に、前記リレー機能を有効化する前に満たされるべきリレー要件を送信するように構成されている送信機と
を備え、
前記送信機が、さらなるリレーが必要であると前記プロセッサが判定する場合に前記無線セル内でブロードキャストメッセージを送信するように構成され、前記ブロードキャストメッセージは少なくとも、前記無線セル内にさらなるリレーが必要であることを示し、前記選択されている持続性チェック値を含み、
前記ブロードキャストメッセージは、前記リレーユーザ機器が前記持続性チェック値に基づく持続性チェックの実行に成功した場合、かつ、前記リレーユーザ機器が前記リレー要件を満たす場合に、前記無線セル内の前記1つまたは複数のリレーユーザ機器に対して、前記リレー機能を有効化するように示す、無線基地局。
【背景技術】
【0002】
LTE(ロングタームエボリューション)
WCDMA(登録商標)無線アクセス技術に基づく3G(第3世代移動通信システム)は、世界中で広範な規模で配備されつつある。この技術を機能強化または発展させる上での最初のステップとして、HSDPA(高速ダウンリンクパケットアクセス)と、HSUPA(高速アップリンクパケットアクセス)とも称するエンハンストアップリンクとが導入され、これにより、極めて競争力の高い無線アクセス技術が提供されている。
【0003】
ユーザからのますます増大する需要に対応し、新しい無線アクセス技術に対する競争力を確保する目的で、3GPPは、LTE(ロングタームエボリューション)と称される新しい移動通信システムを導入した。LTEは、今後10年間にわたり、データおよびメディアの高速伝送ならびに大容量の音声サポートに対するキャリアの必要を満たすように設計されている。高いビットレートを提供することができることは、LTEにとって重要な尺度である。
【0004】
LTE(ロングタームエボリューション)に関する作業項目(WI)の仕様は、E−UTRA(Evolved UMTS Terrestrial Radio Access(UTRA):進化型UMTS地上無線アクセス)およびE−UTRAN(Evolved UMTS Terrestrial Radio Access Network(UTRAN):進化型UMTS地上無線アクセスネットワーク)と称され、最終的にリリース8(LTEリリース8)として公開される。LTEシステムは、パケットベースの効率的な無線アクセスおよび無線アクセスネットワークであり、IPベースの全機能を低遅延かつ低コストで提供する。LTEでは、与えられたスペクトルを用いてフレキシブルなシステム配備を達成するために、1.4MHz、3.0MHz、5.0MHz、10.0MHz、15.0MHz、および20.0MHzのような、スケーラブルな複数の送信帯域幅が指定されている。ダウンリンクには、OFDM(直交周波数分割多重化)をベースとする無線アクセスが採用されている。なぜなら、かかる無線アクセスは、低いシンボルレートのため本質的にMPI(マルチパス干渉)を受けにくく、また、CP(サイクリックプレフィックス)を使用しており、さらに、様々な送信帯域幅の設定に対応可能だからである。アップリンクには、SC−FDMA(シングルキャリア周波数分割多元接続)をベースとする無線アクセスが採用されている。なぜなら、UE(ユーザ機器)の送信出力が限られていることを考えれば、ピークデータレートを向上させるよりも広いカバレッジエリアを提供することが優先されるからである。LTEリリース8/9では、MIMO(多入力多出力)チャネル伝送技術を含む数多くの主要なパケット無線アクセス技術が採用され、高効率の制御シグナリング構造が達成されている。
【0005】
LTEのアーキテクチャ
図1は、LTEの全体的なアーキテクチャを示している。E−UTRANは、eNodeBから構成され、eNodeBは、UE向けの、E−UTRAのユーザプレーン(PDCP/RLC/MAC/PHY)および制御プレーン(RRC)のプロトコルを終端処理する。eNB(eNodeB)は、PHY(物理)層、MAC(メディアアクセス制御)層、RLC(無線リンク制御)層、およびPDCP(パケットデータ制御プロトコル)層をホストし、これらのレイヤはユーザプレーンのヘッダ圧縮および暗号化の機能を含む。eNBは、制御プレーンに対応するRRC(無線リソース制御)機能も提供する。eNBは、無線リソース管理、アドミッション制御、スケジューリング、交渉によるアップリンクQoS(サービス品質)の執行、セル情報のブロードキャスト、ユーザプレーンデータおよび制御プレーンデータの暗号化/解読、ダウンリンク/アップリンクのユーザプレーンパケットヘッダの圧縮/復元を含む、多くの機能を実行する。複数のeNodeBは、X2インターフェースによって互いに接続されている。
【0006】
eNodeBはまた、複数のeNodeBは、S1インターフェースによってEPC(進化型パケットコア)、より具体的には、S1−MMEによってMME(移動管理エンティティ)、S1−UによってSGW(サービングゲートウェイ)に接続されている。S1インターフェースは、MME/サービングゲートウェイとeNodeBとの間の多対多関係をサポートする。SGWは、ユーザデータパケットをルーティングして転送する一方、eNodeB間のハンドオーバ時におけるユーザプレーンのモビリティアンカとしても機能し、さらに、LTEと別の3GPP技術との間のモビリティのためのアンカ(S4インターフェースを終端させ、2G/3GシステムとPDN GWとの間でトラフィックを中継する)として機能する。SGWは、アイドル状態のユーザ機器に対しては、ダウンリンクデータ経路を終端させ、そのユーザ機器へのダウンリンクデータが到着したときにページングをトリガする。SGWは、ユーザ機器のコンテキスト、たとえば、IPベアラサービスのパラメータ、またはネットワーク内部ルーティング情報を管理および記憶する。さらに、SGWは、合法傍受の場合にユーザトラフィックの複製を実行する。
【0007】
MMEは、LTEアクセスネットワークの主要な制御ノードである。MMEは、アイドルモードのユーザ機器の追跡および再送信を含むページング手順の役割を担う。MMEは、ベアラの有効化/無効化プロセスに関与し、さらには、最初のアタッチ時と、CN(基幹ネットワーク)ノードの再配置を伴うLTE内ハンドオーバ時とに、ユーザ機器のSGWを選択する役割も担う。MMEは、(HSSと対話することによって)ユーザを認証する役割を担う。NAS(非アクセス層)シグナリングはMMEにおいて終端され、MMEは、一時的なIDを生成してユーザ機器に割り当てる役割も担う。MMEは、サービスプロバイダのPLMN(公衆陸上移動体ネットワーク)にキャンプオンするためのユーザ機器の認証をチェックし、ユーザ機器のローミング制約を執行する。MMEは、NASシグナリングの暗号化/整合性保護においてネットワーク内の終端点であり、セキュリティキー管理を取り扱う。シグナリングの合法傍受も、MMEによってサポートされる。さらに、MMEは、LTEのアクセスネットワークと2G/3Gのアクセスネットワークとの間のモビリティのための制御プレーン機能を提供し、SGSNからのS3インターフェースをMMEにおいて終端させる。さらに、MMEは、ローミングするユーザ機器のためのホームHSSに向かうS6aインターフェースを終端させる。
【0008】
LTEにおけるコンポーネントキャリアの構造
3GPP LTEシステムのダウンリンクコンポーネントキャリアは、時間−周波数領域において、いわゆるサブフレームに分割されている。3GPP LTEでは、
図2に示したように、各サブフレームが2つのダウンリンクスロットに分割されており、第1のダウンリンクスロットは、最初のいくつかのOFDMシンボルにおける制御チャネル領域(PDCCH領域)を含んでいる。各サブフレームは、時間領域における所与の数のOFDMシンボルからなり(3GPP LTE(リリース8)では12個または14個のOFDMシンボル)、OFDMシンボルそれぞれが、コンポーネントキャリアの帯域幅全体を範囲としている。したがって、OFDMシンボルは各々、それぞれのサブキャリア上で送信される複数の変調シンボルからなる。LTEにおいて、各スロット内で送信される信号は、したがって、OFDMシンボルそれぞれは、
図4にも示したように、N
DLRB×N
RBSC個のサブキャリアおよびN
DLsymb個のOFDMシンボルのリソースグリッドによって記述される。N
DLRBは、帯域幅内のリソースブロックの数である。量N
DLRBは、セル内で設定されているダウンリンク送信帯域幅に依存し、以下を満たすべきである。
【数1】
式中、N
min,DLRB=6およびN
max,DLRB=110はそれぞれ、現行バージョンの仕様によってサポートされる最小ダウンリンク帯域幅および最大ダウンリンク帯域幅である。N
RBSCは、1つのリソースブロック内のサブキャリアの数である。通常のサイクリックプレフィックスサブフレーム構造について、N
RBSC=12およびN
DLsymb=7である。
【0009】
たとえば、例として3GPP LTE(ロングタームエボリューション)において使用される、OFDMを採用するマルチキャリア通信システムを考えると、スケジューラによって割り当てることのできるリソースの最小単位は、1つの「リソースブロック」である。物理リソースブロック(PRB)は、
図2に例示的に示したように、時間領域における連続するOFDMシンボル(たとえば、7個のOFDMシンボル)と、周波数領域における連続するサブキャリアとして定義される(たとえば、コンポーネントキャリアの12のサブキャリア)。したがって、3GPP LTE(リリース8)においては、物理リソースブロックは、時間領域における1スロットと、周波数領域における180kHzに対応する複数のリソース要素からなる(ダウンリンクリソースグリッドに関するさらなる詳細については、たとえば、非特許文献1の6.2節を参照)(3GPPのウェブサイトにおいて入手可能であり、参照によって本明細書に組み込まれている)。
【0010】
1つのサブフレームは2つのスロットからなり、それによって、いわゆる「通常の」CP(サイクリックプレフィックス)が使用されているときにはサブフレームに14個のOFDMシンボルが存在し、いわゆる「拡張」CPが使用されているときにはサブフレームに12個のOFDMシンボルが存在する。専門用語として、以下では、サブフレーム全体にわたる、同じ連続するサブキャリアに等しい時間−周波数リソースを、「リソースブロックペア」、または同じ意味で「RBペア」もしくは「PRBペア」と称する。
【0011】
用語「コンポーネントキャリア」は、周波数領域におけるいくつかのリソースブロックの組合せを意味する。LTEの将来のリリースにおいて、「コンポーネントキャリア」という用語はもはや使用されない。代わりに、この用語は「セル」に変更される。「セル」は、ダウンリンクリソースおよび任意でアップリンクリソースの組合せを意味する。ダウンリンクリソースのキャリア周波数とアップリンクリソースのキャリア周波数との間のリンクは、ダウンリンクリソースで送信されるシステム情報に示される。
コンポーネントキャリアの構造の同様の想定は、以降のリリースにも適用される。
【0012】
より広い帯域幅をサポートするためのLTE−Aにおけるキャリアアグリゲーション
世界無線通信会議2007(WRC−07)において、IMT−Advancedの周波数スペクトルが決定された。IMT−Advancedのための全体的な周波数スペクトルは決定されたが、実際に利用可能な周波数帯域幅は、地域または国によって異なる。しかしながら、利用可能な周波数スペクトルのアウトラインの決定に続いて、3GPP(第3世代パートナーシッププロジェクト)において無線インターフェースの標準化が開始された。3GPP TSG RAN #39会合において、「Further Advancements for E−UTRA (LTE−Advanced)」に関する検討項目の記述が承認された。この検討項目は、E−UTRAを発展させる上で、たとえば、IMT−Advancedの要件を満たすために、考慮すべき技術要素をカバーしている。
【0013】
LTE−Advancedシステムがサポートできる帯域幅は100MHzであるが、LTEシステムは20MHzをサポートできるのみである。最近、無線スペクトルの不足によって無線ネットワークの発展が妨げられており、結果として、LTE−Advancedシステムのための十分に広いスペクトル帯域を確保することが困難である。したがって、より広い無線スペクトル帯域を得るための方法を見つけることが緊急課題であり、1つの可能な答えがキャリアアグリゲーション機能である。
【0014】
キャリアアグリゲーションでは、最大で100MHzの広い送信帯域幅をサポートする目的で、2つ以上のコンポーネントキャリアがアグリゲートされる。LTE−Advancedシステムでは、LTEシステムにおけるいくつかのセルが、より広い1つのチャネルにアグリゲートされ、このチャネルは、たとえLTEにおけるこれらのセルが異なる周波数帯域内にある場合でも100MHzに対して十分に広い。
【0015】
少なくとも、コンポーネントキャリアの帯域幅がLTEリリース8/9セルのサポートされている帯域幅を超えないとき、すべてのコンポーネントキャリアをLTEリリース8/9互換として設定することができる。ユーザ機器によってアグリゲートされるすべてのコンポーネントキャリアが必ずしもLTEリリース8/9互換でなくてよい。リリース8/9のユーザ機器がコンポーネントキャリアにキャンプオンすることを回避するため、既存のメカニズム(たとえば、バーリング(barring))を使用することができる。
【0016】
ユーザ機器は、その能力に応じて1つまたは複数のコンポーネントキャリア(複数のサービングセルに対応する)を同時に受信または送信することができる。キャリアアグリゲーションのための受信および/または送信能力を備えた、LTE−Aリリース10のユーザ機器は、複数のサービングセル上で同時に受信および/または送信することができ、これに対して、LTEリリース8/9のユーザ機器は、コンポーネントキャリアの構造がリリース8/9の仕様に従うことを条件として、1つのみのサービングセル上で受信および送信することができる。
【0017】
キャリアアグリゲーションは、連続するコンポーネントキャリアおよび不連続なコンポーネントキャリアの両方についてサポートされ、この場合、コンポーネントキャリアそれぞれは、(3GPP LTE(リリース8/9)の計算方式を使用するとき)周波数領域における最大110個のリソースブロックに制限される。
【0018】
同じeNodeB(基地局)から送信される、場合によってはアップリンクおよびダウンリンクにおいて異なる帯域幅の異なる数のコンポーネントキャリアをアグリゲートするように、3GPP LTE−A(リリース10)互換のユーザ機器を設定することが可能である。設定することのできるダウンリンクコンポーネントキャリアの数は、ユーザ機器のダウンリンクのアグリゲーション能力に依存する。逆に、設定することのできるアップリンクコンポーネントキャリアの数は、ユーザ機器のアップリンクのアグリゲーション能力に依存する。現在、ダウンリンクコンポーネントキャリアよりもアップリンクコンポーネントキャリアが多くなるように移動端末を設定することはできない。一般的なTDD配備では、コンポーネントキャリアの数および各コンポーネントキャリアの帯域幅は、アップリンクとダウンリンクとで同じである。同じeNodeBから送信されるコンポーネントキャリアは、必ずしも同じカバレッジを提供する必要はない。
【0019】
連続的にアグリゲートされるコンポーネントキャリアの中心周波数の間隔は、300kHzの倍数であるべきである。これは、3GPP LTE(リリース8/9)の100kHzの周波数ラスターとの互換性を保つと同時に、15kHz間隔のサブキャリアの直交性を維持するためである。アグリゲーションのシナリオによっては、連続するコンポーネントキャリアの間に少数の使用されないサブキャリアを挿入することによって、n×300kHzの間隔あけを容易にすることができる。
【0020】
複数のキャリアをアグリゲートする影響は、MAC層に及ぶのみである。MAC層には、アップリンクおよびダウンリンクの両方において、アグリゲートされるコンポーネントキャリアごとに1つのHARQエンティティが要求される。コンポーネントキャリアあたりのトランスポートブロックは最大1個である(アップリンクにおけるSU−MIMOを使用しない場合)。トランスポートブロックおよび必要時のそのHARQ再送信は、同じコンポーネントキャリアにマッピングする必要がある。
【0021】
キャリアアグリゲーションが設定されるとき、移動端末はネットワークとの1つのRRC接続のみを有する。RRC接続の確立/再確立時、1つのセルが、LTEリリース8/9と同様に、セキュリティ入力(1つのECGI、1つのPCI、および1つのARFCN)と、非アクセス層モビリティ情報(たとえば、TAI)とを提供する。RRC接続の確立/再確立の後、そのセルに対応するコンポーネントキャリアは、ダウンリンクPCell(プライマリセル)と称される。接続状態では、ユーザ機器あたり常に1つの、また1つだけのDL PCell(ダウンリンクPCell)および1つのUL PCell(アップリンクPCell)が設定される。設定されたコンポーネントキャリアのセットのうち、プライマリセル以外のセルはSCell(セカンダリセル)と称される。SCellのキャリアは、DL SCC(ダウンリンクセカンダリコンポーネントキャリア)およびUL SCC(アップリンクセカンダリコンポーネントキャリア)である。PCellを含む最大5つのサービングセルを、1つのUEに対して設定することができる。
【0022】
ダウンリンクPCellおよびアップリンクPCellの特徴は以下のとおりである。
1.SCellごとに、ダウンリンクリソースに加えてアップリンクリソースのUEによる使用を設定可能である(したがって、設定されるDL SCCの数はUL SCCの数よりも常に大きいかまたは等しく、アップリンクリソースのみを使用するようにSCellを設定することはできない)。
2.ダウンリンクPCellは、SCellとは異なり無効化することはできない。
3.ダウンリンクPCellにおいてRLF(レイリーフェージング)が発生すると再確立がトリガされるが、ダウンリンクSCellにRLFが発生しても再確立はトリガされない。
4.非アクセス層情報はダウンリンクPCellから取得される。
5.PCellは、ハンドオーバ手順(すなわちセキュリティキーの変更およびRACH手順)によってのみ変更することができる。
6.PCellは、PUCCHの送信に使用される。
7.アップリンクPCellは、レイヤ1アップリンク制御情報を送信するのに使用される。
8.ユーザ機器の観点から、各アップリンクリソースは1つのサービングセルに属するのみである。
【0023】
コンポーネントキャリアの設定および再設定ならびに追加および削除は、RRCによって行うことができる。有効化および無効化は、MAC制御要素を介して行われる。LTE内ハンドオーバ時、RRCによって、ターゲットセルで使用するためのSCellを追加、削除、または再設定することもできる。新しいSCellを追加するときには、SCellのシステム情報を送るために専用のRRCシグナリングが使用され、この情報は、送信/受信に必要である(LTEリリース8/9におけるハンドオーバ時と同様)。各SCellは、SCellが1つのUEに追加されるときにサービングセルインデックスによって設定され、PCellは、常にサービングセルインデックス0を有する。
【0024】
キャリアアグリゲーションを使用するようにユーザ機器が設定されているとき、アップリンクコンポーネントキャリアとダウンリンクコンポーネントキャリアの少なくとも一対が常にアクティブである。この対のうちのダウンリンクコンポーネントキャリアは、「ダウンリンクアンカーキャリア」と称されることもある。同じことはアップリンクについても当てはまる。
【0025】
キャリアアグリゲーションが設定されているとき、同時に複数のコンポーネントキャリアについてユーザ機器をスケジューリングすることができるが、一度に行うことのできるランダムアクセス手順は最大で1つであるべきである。クロスキャリアスケジューリング(Cross−carrier scheduling)では、コンポーネントキャリアのPDCCHによって別のコンポーネントキャリアのリソースをスケジューリングすることができる。この目的のため、それぞれのDCI(ダウンリンク制御情報)フォーマットにCIFと称される、コンポーネントキャリア識別フィールドが導入されている。
【0026】
クロスキャリアスケジューリングが行われていないときには、アップリンクコンポーネントキャリアとダウンリンクコンポーネントキャリアとの間の、RRCシグナリングによって確立されるリンクによって、グラントが適用されるアップリンクコンポーネントキャリアを識別することができる。アップリンクコンポーネントキャリアへのダウンリンクコンポーネントキャリアのリンクは、必ずしも1対1である必要はない。言い換えれば、同じアップリンクコンポーネントキャリアに複数のダウンリンクコンポーネントキャリアをリンクすることができる。同時に、1つのダウンリンクコンポーネントキャリアは、1つのアップリンクコンポーネントキャリアのみにリンクすることができる。
【0027】
LTE D2D(デバイス間)ProSe(近接サービス)
近接性ベースのアプリケーションおよびサービスは、新たに起こっている社会技術的傾向を表している。認められている分野は、オペレータおよびユーザにとって関心事である商業サービスおよび公衆安全に関するサービスを含む。LTEに近接サービス(ProSe)機能を導入すれば、3GPP産業が、この発展している市場に奉仕することが可能であり、同時に、ともにLTEに取り組んでいるいくつかの公衆安全団体の緊急の需要に奉仕することになる。
D2D(デバイス間)通信は、LTEリリース12によって導入されている技術要素であり、LTEリリース12は、セルラネットワークに対するアンダーレイとしてのD2Dがスペクトル効率を増大させることを可能にする。たとえば、セルラネットワークがLTEである場合、すべてのデータ搬送物理チャネルが、D2DシグナリングにSC−FDMAを使用する。D2D通信において、ユーザ機器は、無線基地局を通す代わりに、セルラリソースを使用したダイレクトリンクを介して互いにデータ信号を送信する。本開示全体を通じて、用語「D2D」、「ProSe」および「サイドリンク」は交換可能である。
【0028】
LTEにおけるD2D通信
LTEにおけるD2D通信は、ディスカバリおよび通信の2つの領域に焦点を当てている。
ProSe(近接性ベースのサービス)ダイレクトディスカバリは、ProSe使用可能UEによって、PC5インターフェースを介してE−UTRAダイレクト無線信号を使用してその付近にある他のProSe使用可能UEを発見するために使用される手順として定義され、後により詳細に説明される。
【0029】
D2D通信において、UEは、BS(基地局)を通す代わりに、セルラリソースを使用したダイレクトリンクを介して互いにデータ信号を送信する。D2Dユーザは、BS下で制御されたままである間に、すなわち、少なくともeNBのカバレッジ内にあるときに、直接的に通信する。それゆえ、D2Dは、セルラリソースを再使用することによってシステム性能を向上させることができる。
【0030】
D2Dは、アップリンクLTEスペクトル(FDDの場合)またはカバレッジを与えているセルのアップリンクサブフレーム(TDDの場合、カバレッジ外であるときを除く)において動作するが仮定される。さらに、D2D送信/受信は、所与のキャリア上で全二重通信を使用しない。個々のUEの観点から、所与のキャリア上で、D2D信号受信およびLTEアップリンク送信は全二重通信を使用しない、すなわち、D2D信号受信とLTE UL送信を同時に行うことは可能ではない。
【0031】
D2D通信において、1つの特定のUE1が送信の役割を有する(送信ユーザ機器または送信端末)とき、UE1がデータを送信し、別のUE2(受信ユーザ機器)がこれを受信する。UE1およびUE2は、それらの送信および受信の役割を交代することができる。UE1からの送信は、UE2のような1つまたは複数のUEによって受信することができる。ユーザプレーンプロトコルに関連して、D2D通信の観点からの合意の一部を以下に与える(参照によって本明細書に組み込まれている非特許文献2の9.2.2節も参照)。
【0032】
−PDCP:
−−1:M D2Dブロードキャスト通信データ(すなわち、IPパケット)は、通常ユーザプレーンデータとして取り扱われるべきである。
−−PDCPにおけるヘッダ圧縮/復元が、1:M D2Dブロードキャスト通信に適用可能である。
−−公衆安全のためのD2Dブロードキャスト動作について、PDCPにおけるヘッダ圧縮のためにU−Modeが使用される。
−RLC:
−−RLC UMが1:M D2Dブロードキャスト通信に使用される。
−−セグメント化および再組み立てが、RLC UMによってL2上でサポートされる。
−−受信UEは、送信ピアUEごとに少なくとも1つのRLC UMエンティティを維持する必要がある。
−−RLC UM受信機エンティティは、最初のRLC UMデータユニットを受信する前に設定される必要はない。
−−そのため、ユーザプレーンデータ送信のためのD2D通信について、RLC AMまたはRLC TMの必要性は認められていない。
−MAC:
−−1:M D2Dブロードキャスト通信についてHARQフィードバックは想定されない。
−−受信UEは、受信機RLC UMエンティティを識別するために発信元IDを知る必要がある。
−−MACヘッダは、MAC層におけるパケットのフィルタリング除外を可能にするL2宛先IDを含む。
−−L2宛先IDは、ブロードキャスト、グループキャストまたはユニキャストアドレスであり得る。
−−−L2グループキャスト/ユニキャスト:MACヘッダ内で搬送されるL2宛先IDは、受信されるRLC UM PDUを、それがRLC受信機エンティティに送達される前であっても、廃棄することを可能にする。
−−−L2ブロードキャスト:受信UEは、すべての送信機からのすべての受信されるRLC PDUを処理し、IPパケットを再組み立てして、上層に送達することを目標とする。
−−MACサブヘッダは、(複数の論理チャネルを区別するために)LCIDを含む。
−−少なくとも多重化/逆多重化、優先度処理およびパディングがD2Dにとって有用である。
【0033】
ProSeダイレクト通信レイヤ2リンク
簡潔には、ProSeダイレクト1対1通信は、2つのUEの間でPC5を介したセキュアなレイヤ2リンクを確立することによって実現される。各UEは、UEがレイヤ2リンク上で送信するすべてのフレームの発信元レイヤ2 IDフィールド内、および、UEがレイヤ2リンク上で受信するすべてのフレームの宛先レイヤ2 ID内に含まれているユニキャスト通信のためのレイヤ2 IDを有する。UEは、ユニキャスト通信のためのレイヤ2 IDが、少なくともローカルに固有であることを保証する必要がある。そのため、UEは、指定されていないメカニズムを使用して、隣接するUEとのレイヤ2 ID衝突の処理に備えるべきである(たとえば、衝突が検出されるときに、ユニキャスト通信のための新たなレイヤ2 IDを自己割り当てする)。1対1ProSeダイレクト通信のためのレイヤ2リンクは、2つのUEのレイヤ2 IDの組合せによって識別される。これは、UEが、同じレイヤ2 IDを使用して1対1ProSeダイレクト通信のための複数のレイヤ2リンクに携わることができることを意味する。
【0034】
1対1ProSeダイレクト通信は、参照によって本明細書に組み込まれている非特許文献3の7.1.2節に詳細に説明されているような、以下の手順から構成される。
−PC5を介したセキュアなレイヤ2リンクの確立。
−IPアドレス/プレフィックス割り当て。
−PC5を介したレイヤ2リンクの維持。
−PC5を介したレイヤ2リンクの解放。
【0035】
図3は、PC5インターフェースを介したセキュアなレイヤ2リンクを確立する方法を開示している。
1.UE−1が、相互認証をトリガするために、ダイレクト通信要求メッセージをUE−2に送信する。リンクイニシエータ(UE−1)は、ステップ1を実行するために、ピア(UE−2)のレイヤ2 IDを知る必要がある。一例として、リンクイニシエータは、最初にディスカバリ手順を実行すること、または、ピアを含むProSe1対多通信に参加することによって、ピアのレイヤ2 IDを学習することができる。
2.UE−2が、相互認証のための手順を開始する。認証手順が首尾よく完了すると、PC5を介したセキュアなレイヤ2リンクの確立が完了する。
【0036】
少なくとも以下の標準的なIETFメカニズムを、IPアドレス/プレフィックス割り当てに使用することができる。
−IPv4アドレスの割り当てのためのDHCPベースのIPアドレス設定。
−IPv6プレフィックス割り当てのための、RFC4862において指定されているIPv6ステートレスアドレス自動設定。
【0037】
2つのUEのうちの一方が、DHCPサーバまたはIPv6デフォルトルータとして動作する。ProSeUE−NWリレーの場合において(後のProSeリレーに関するチャプタも参照)、リレーは、PC5を介したセキュアなレイヤ2リンクにわたってそれに接続するすべての遠隔UEに対するDHCPサーバまたはIPv6デフォルトルータとして動作する。
【0038】
隔離された(非中継)1対1通信に携わるUEはまた、リンクローカルアドレスも使用することができる。
【0039】
PC5シグナリングプロトコルは、UEが黙示的なレイヤ2リンク解放を進めることができるように、UEがProSe通信範囲内にないときを検出するために使用されるキープアライブ機能をサポートすべきである。
【0040】
PC5を介したレイヤ2リンク解放は、他方のUEに送信される接続切断要求メッセージを使用し、他方のUEも、すべての関連するコンテキストデータを削除することによって実行することができる。接続切断要求メッセージを受信したとき、他方のUEは、接続切断応答メッセージによって応答し、レイヤ2リンクに関連するすべてのコンテキストデータを削除する。
【0041】
ProSeダイレクト通信関連識別情報
非特許文献4は、従属節8.3において、ProSeダイレクト通信に使用するための以下の識別情報を定義している。
−SL−RNTI:ProSeダイレクト通信スケジューリングに使用される固有の識別情報、
−発信元レイヤ2 ID:サイドリンクProSeダイレクト通信におけるデータの送信者を識別する。発信元レイヤ2 IDは、24ビット長であり、受信機におけるRLC UMエンティティおよびPDCPエンティティの識別のためのProSeレイヤ2宛先IDおよびLCIDとともに使用される。
−宛先レイヤ2 ID:サイドリンクProSeダイレクト通信におけるデータの目標を識別する。宛先レイヤ2 IDは、24ビット長であり、MAC層において2つのビット列に分割される。
−−1つのビット列は、宛先レイヤ2 IDのLSB部分(8ビット)であり、サイドリンク制御レイヤ1 IDとして物理層に転送される。これは、サイドリンク制御において意図されているデータの目標を識別し、物理層においてパケットをフィルタリングするために使用される。
−−第2のビット列は、宛先レイヤ2 IDのMSB部分(16ビット)であり、MACヘッダ内で搬送される。これは、MAC層においてパケットをフィルタリングするために使用される。
【0042】
グループ形成のために、また、UEにおいて発信元レイヤ2 ID、宛先レイヤ2 IDおよびサイドリンク制御L1 IDを設定するために、非アクセス層シグナリングが必要とされる。これらの識別情報は、より高位の層によって提供されるか、または、より高位の層によって提供される識別情報から導出される。グループキャストおよびブロードキャストの場合、より高位の層によって提供されるProSe UE IDは、発信元レイヤ2 IDとして直接的に使用され、より高位の層によって提供されるProSeレイヤ2グループIDは、MAC層における宛先レイヤ2 IDとして直接的に使用される。
【0043】
近接サービスのための無線リソース配分
送信UEの観点から、近接サービス使用可能UE(ProSe使用可能UE)は、2つのリソース配分モードにおいて動作することができる。
【0044】
モード1は、eNBによってスケジューリングされるリソース配分を指し、UEがeNB(またはリリース10リレーノード)から送信リソースを要求し、eNodeB(またはリリース10リレーノード)は、UEによってダイレクトデータおよびダイレクト制御情報(たとえば、スケジューリング割り当て)を送信するために使用されるリソースをスケジューリングする。UEは、データを送信するためにRRC_CONNECTEDである必要がある。特に、UEは、eNBにスケジューリング要求(D−SRまたはランダムアクセス)を送信し、その後、通常通りにバッファ状態報告(BSR)を送信する(以下のチャプタ「D2D通信のための送信手順」も参照)。BSRに基づいて、eNBは、UEがProSeダイレクト通信送信のためのデータを有すると判定することができ、送信のために必要とされるリソースを推定することができる。
【0045】
他方、モード2は、UEによる自主的なリソース選択を参照し、UE自体がリソースプールからダイレクトデータおよびダイレクト制御情報(すなわち、SA)を送信するためのリソース(時間および周波数)を選択する。1つのリソースプールが、たとえば、SIB18の内容によって、すなわち、フィールドcommTxPoolNormalCommonによって定義され、この特定のリソースプールは、セル内でブロードキャストされ、その後、依然としてRRC_Idle状態にあるセル内のすべてのUEにとって共通して利用可能である。実際的には、eNBは、上記プールの最大4つの異なるインスタンス、SAメッセージおよびダイレクトデータの送信のためのそれぞれ4つのリソースプールを定義することができる。しかしながら、UEは、たとえ複数のリソースプールで構成されたとしても、リスト内に定義されている最初のリソースプールを常に使用すべきである。
【0046】
代替として、別のリソースプールを、すなわち、例外的な場合においてUEによって使用することができるフィールドcommTxPoolExceptionalを使用することによって、eNBによって定義し、SIB18においてシグナリングすることができる。
【0047】
UEが使用することになるリソース配分モードは、eNBによって設定可能である。さらに、D2Dデータ通信のためにUEが使用することになるリソース配分モードはまた、RRC状態、すなわち、RRC_IDLEまたはRRC_CONNECTED、および、UEのカバレッジ状態、すなわち、カバレッジ内、カバレッジ外に依存し得る。UEは、サービングセルを有する(すなわち、UEがRRC_CONNECTEDであるか、または、RRC_IDLEにおいてセルにキャンプオンしている)場合、カバレッジ内と考えられる。
図4は、オーバーレイ(LTE)およびアンダーレイ(D2D)システムに対する送信/受信リソースの使用を示す。
【0048】
基本的に、eNodeBは、UEがモード1またはモード2のいずれにおける送信を適用し得るかを制御する。UEが、D2D通信を送信(または受信)することができるそのリソースが分かると、UEは、対応する送信/受信に対してはその対応するリソースのみを使用する。たとえば、
図4において、D2Dサブフレームは、D2D信号を受信または送信するためにのみ使用されることになる。D2DデバイスとしてのUEは半二重モードで動作することになるため、UEは、任意の時点においてD2D信号を受信するか、または、送信するかのいずれかであり得る。同様に、
図4に示す他のサブフレームは、LTE(オーバーレイ)送信および/または受信に使用することができる。
【0049】
D2D通信のための送信手順
D2Dデータ送信手順は、リソース配分モードに応じて異なる。モード1について上述したように、eNBは、UEからの対応する要求後に、スケジューリング割り当ておよびD2Dデータ通信のためにリソースを明示的にスケジューリングする。特に、UEは、eNBによって、D2D通信が一般的に許可されているが、モード2リソース(すなわち、リソースプール)は与えられないことを通知され得、これは、たとえば、UEによるD2D通信関心インジケーションおよび対応する応答、D2D通信応答を交換することによって行うことができ、上述した対応する例示的なProseCommConfig情報要素は、commTxPoolNormalCommonを含まないことになり、これは、送信を含むダイレクト通信を開始したいと望むUEが、E−UTRANに、各個々の送信にリソースを割り当てることを要求する必要があることを意味する。したがって、そのような場合において、UEは、各個々の送信のためにリソースを要求する必要があり、以下において、要求/許可手順の種々のステップが、このモード1リソース配分について例示的にリストされる。
【0050】
−ステップ1:UEが、PUCCHを介してeNBにSR(スケジューリング要求)を送信する。
−ステップ2:eNBが、PDCCHを介してULリソース(UEがBSRを送信するためのもの)を許可し、これはC−RNTIによってスクランブルをかけられる。
−ステップ3:UEが、PUSCHを介してバッファ状態を示すD2D BSRを送信する。
−ステップ4:eNBが、PDCCHを介してD2Dリソース(UEがデータを送信するためのもの)を許可し、これはD2D−RNTIによってスクランブルをかけられる。
−ステップ5:D2D Tx UEが、ステップ4において受信されている許可に従ってSA/D2Dデータを送信する。
【0051】
SCI(サイドリンク制御情報)とも称されるSA(スケジューリング割り当て)は、制御情報、たとえば、時間−周波数リソースに対するポインタ、変調およびコード化方式、ならびに、対応するD2Dデータ送信のためのグループ宛先IDを含むコンパクトな(低ペイロード)メッセージである。SCIは、1つの(ProSe)宛先IDのサイドリンクスケジューリング情報を伝送する。SA(SCI)の内容は基本的に、上記ステップ4において受信される許可に従う。D2D許可およびSA内容(すなわち、SCI内容)は、特にSCIフォーマット0を定義している、参照によって本明細書に組み込まれている非特許文献5の従属節5.4.3において定義されている。
【0052】
他方、モード2リソース配分について、上記ステップ1〜4は基本的に必要なく、UEは、eNBによって設定および提供される送信リソースプールから、SAおよびD2Dデータ送信のためのリソースを自主的に選択する。
【0053】
図5は、2つのUE、すなわち、UE−AおよびUE−Bのスケジューリング割り当ておよびD2Dデータの送信を例示的に示し、スケジューリング割り当てを送信するためのリソースは定期的であり、D2Dデータ送信に使用されるリソースは、対応するスケジューリング割り当てによって示される。
【0054】
ProSeネットワークアーキテクチャおよびProSeエンティティ
図6は、それぞれのUE AおよびB内の異なるProSeアプリケーション、ならびに、ネットワーク内のProSeアプリケーションサーバおよびProSe関数を含む、非ローミングの場合の高レベルの例示的なアーキテクチャを示す。
図6の例示的なアーキテクチャは、参照によって本明細書に組み込まれている非特許文献6の4.2章「Architectural Reference Model」から取得される。
【0055】
これらの機能エンティティは、参照によって本明細書に組み込まれている非特許文献6の従属節4.4「Functional Entities」に詳細に提示および説明されている。ProSe関数は、ProSeに必要とされるネットワーク関連動作のために使用される論理関数であり、ProSeの特徴の各々のための種々の役割を果たす。ProSe関数は、3GPPのEPCの一部分であり、近接サービスに関係する、承認、認証、データ取り扱いなどのような、すべての関連するネットワークサービスを提供する。ProSeダイレクトディスカバリおよび通信のために、UEは、PC3基準点を介して、特定のProSe UE識別情報、他の設定情報、および、ProSe関数からの承認を取得することができる。ネットワーク内で複数のProSe関数が配備され得るが、例示を容易にするために、単一のProSe関数が提示されている。ProSe関数は、ProSe特徴に応じて異なる役割を実行する3つの主な従属関数、すなわち、DPF(Direct Provision Function:ダイレクト付与関数)、ダイレクトディスカバリ名管理関数(Direct Discovery Name Management Function)、および、EPCレベルディスカバリ関数(EPC−level Discovery Function)からなる。DPFは、UEに、ProSeダイレクトディスカバリおよびProSeダイレクト通信を使用するために必要なパラメータを付与するために使用される。
【0056】
上記接続において使用されている用語「UE」は、ProSe機能をサポートするProSe使用可能UEを指す。
【0057】
ProSeアプリケーションサーバは、EPC ProSeユーザIDおよびProSe関数IDの記憶、ならびに、アプリケーション層ユーザIDおよびEPC ProSeユーザIDのマッピングをサポートする。ProSe AS(アプリケーションサーバ)は、3GPPの範囲外のエンティティである。UE内のProSeアプリケーションは、アプリケーション層基準点PC1を介してProSe ASと通信する。ProSe ASは、PC2基準点を介して3GPPネットワークに接続されている。
【0058】
D2Dに関するUEカバレッジ状態
すでに前述したように、D2D通信のためのリソース配分モードは、RRC状態、すなわち、RRC_IDLEおよびRRC_CONNECTEDとは別に、UEのカバレッジ状態、すなわち、カバレッジ内、カバレッジ外にも依存する。UEは、サービングセルを有する(すなわち、UEがRRC_CONNECTEDであるか、または、RRC_IDLEにおいてセルにキャンプオンしている)場合、カバレッジ内と考えられる。
これまで言及した2つのカバレッジ状態、すなわち、IC(カバレッジ内)およびOOC(カバレッジ外)は、さらに、D2Dのサブ状態へと区別される。
図7は、以下のように要約することができる、D2D UEが関連付けられ得る4つの異なる状態を示す。
【0059】
−状態1:UE1が、アップリンクおよびダウンリンクカバレッジを有する。この状態において、ネットワークは、各D2D通信セッションを制御する。さらに、ネットワークは、UE1がリソース配分モード1を使用すべきか、または、モード2を使用すべきかを設定する。
−状態2:UE2が、ダウンリンクカバレッジを有するが、アップリンクカバレッジを有しない、すなわち、DLカバレッジのみを有する。ネットワークは、(コンテンションベースの)リソースプールをブロードキャストする。この状態において、送信UEは、ネットワークによって設定されるリソースプールからSAおよびデータに使用されるリソースを選択し、そのような状態において、リソース配分は、D2D通信のモード2に従ってのみ可能である。
−状態3:UE3がアップリンクおよびダウンリンクカバレッジを有しないため、UE3は、厳密に言うと、すでにOOC(カバレッジ外)であると考えられる。しかしながら、UE3は、それ自体はセルのカバレッジ内にある何らかのUE(たとえば、UE1)のカバレッジ内にある。すなわち、それらの何らかのUEは、CPリレーUEまたは単純にリレーUEとしても参照され得る(ProSeリレーに関する後のチャプタも参照)。それゆえ、
図7における状態3のUEの領域は、CP UEリレーカバレッジエリアとして示すことができる。この状態3にあるUEはまた、OOC状態3 UEとしても参照される。この状態において、UEは、eNBによって送信され(SIB)、セルのカバレッジ内にあるCP UEリレーUEによってPD2DSCHを介してOOC状態3 UEへと転送されるいくつかのセル特有の情報を受信することができる。(コンテンションベースの)ネットワーク制御リソースプールが、PD2DSCHによってシグナリングされる。
−状態4:UE4はカバレッジ外にあり、セルのカバレッジ内にある他のUEからPD2DSCHを受信しない。状態4 OOCとしても参照されるこの状態において、送信UEは、予め設定されているリソースプールからデータ送信に使用されるリソースを選択する。
【0060】
状態3 OOCと状態4 OOCとの間で区別する理由は、主に、カバレッジ外デバイスからのD2D送信と、レガシーE−UTRA送信との間で発生する可能性がある強い干渉を回避するためである。一般的に、D2D有効UEは、カバレッジ外にある間に使用するための、D2D SAおよびデータの送信のためのリソースプールを有する。これらのカバレッジ外UEが、セル境界付近の予め設定されているこれらの予め設定されているリソースプールで送信する場合、D2D送信とカバレッジ内レガシー送信との間の干渉が、セル内の通信に悪影響を与える可能性がある。カバレッジ内のD2D使用可能UEがD2Dリソースプール設定をセル境界付近のそれらのカバレッジ外デバイスに転送した場合、カバレッジ外UEは、eNodeBによって指定されるリソースにそれらの送信を制限し、それゆえ、カバレッジ内のレガシー送信との干渉が最小限に抑えられる。このように、RAN1は、カバレッジ内UEがリソースプール情報および他のD2D関連設定をカバレッジエリアのほんの外側にあるそれらのデバイス(状態3 IE)に転送しているメカニズムを導入している。
【0061】
カバレッジ内D2Dリソースプールに関するこの情報をネットワーク内で近接するUEに搬送するためにPD2DSCH(物理D2D同期チャネル)が使用され、それによって、ネットワーク内で近接するリソースプールが連携される。
【0062】
D2Dディスカバリ
ProSeダイレクトディスカバリは、ProSe使用可能UEによって、PC5を介してE−UTRAダイレクト無線信号を使用してその付近にある他のProSe使用可能UEを発見するために使用される手順として定義される。
図8は、デバイス間ダイレクトディスカバリのためのPC5インターフェースを概略的に示す。
【0063】
上層は、ディスカバリ情報の告知およびモニタリングの承認を処理する。この目的のために、UEは、「ディスカバリ信号」と称される、所定の信号を交換する必要がある。ディスカバリ信号を定期的にチェックすることによって、UEは、必要なときに通信リンクを確立するために、近接するUEのリストを維持する。ディスカバリ信号は、たとえ低信号対雑音比(SNR)環境にあっても確実に検出されるべきである。ディスカバリ信号が定期的に送信されることを可能にするために、ディスカバリ信号のためのリソースが割り当てられるべきである。
【0064】
オープンおよび制限の、2つのタイプのProSeダイレクトディスカバリがある。オープンは、発見されているUEから必要とされている明示的な許可がない場合であり、一方、制限ディスカバリは、発見されているUEから明示的な許可がある場合にのみ行われる。
【0065】
ProSeダイレクトディスカバリは、たとえば、「find a taxi nearby(近くのタクシーを見つけて)」、「find me a coffee shop(コーヒーショップを見つけて)」のような、たとえば、発見されるUEからの情報を、この情報を使用することを許可されているUEにおいて特定の用途のために使用することができる、独立型サービスイネーブラであり得る。加えて、取得される情報に応じて、ProSeダイレクトディスカバリは、その後の動作のために、たとえば、その後のProSeダイレクト通信のために使用することができる。
【0066】
ProSeダイレクトディスカバリモデル
ProSeダイレクトディスカバリのための以下のモデルは、参照によって本明細書に組み込まれている非特許文献6の5.3節およびそのすべての従属節において定義されている。
【0067】
モデルA「I am here(私はここにいます)」
このモデルは、ProSeダイレクトディスカバリに参加するProSe使用可能UEの2つの役割を定義する。
告知UE:このUEは、発見する許可を得ている近接するUEによって使用され得る特定の情報を告知する。
モニタリングUE:告知UEの近傍の関心のある特定の情報をモニタリングするUE。
【0068】
このモデルにおいて、告知UEは、所定のディスカバリ間隔をおいてディスカバリメッセージをブロードキャストし、これらのメッセージに関心のあるモニタリングUEは、それらを読み出し、それらを処理する。告知UEは、それ自体に関する情報、たとえば、そのProSeアプリケーションコードをディスカバリメッセージ内でブロードキャストするため、このモデルは、「I am here」と称される場合がある。
【0069】
モデルB(「who is there?(そこにいるのは誰ですか?)」/「are you there?(あなたはそこにいますか?」)
このモデルは、ProSeダイレクトディスカバリに参加するProSe使用可能UEの2つの役割を定義する。
−発見者UE:このUEは、当該UEが発見しようと関心を持っている物に関する特定の情報を含む要求を送信する。
−被発見者UE:この要求メッセージを受信するUEは、発見者の要求に関連する何らかの情報によって応答することができる。
【0070】
発見者UEは、応答を受信する可能性がある他のUEの情報を送信し、たとえば、情報は、応答することができるグループおよびグループのメンバーに対するProSeアプリケーション識別情報に関するものであり得るため、これは、「who is there/are you there」と称され得る。
【0071】
ディスカバリ情報の内容は、AS(アクセス層)にとってトランスペアレントであり、ProSeダイレクトディスカバリモデルのASおよびProSeダイレクトディスカバリのタイプにおいて区別は行われない。ProSeプロトコルは、有効なディスカバリ情報のみを告知のためのASに送達することを保証する。
【0072】
UEは、eNB設定によってRRC_IDLEとRRC_CONNECTEDの両方の状態においてディスカバリ情報の告知およびモニタリングに参加することができる。UEは、半二重制約にしたがってそのディスカバリ情報を告知およびモニタリングする。
【0073】
ディスカバリのためのリソース配分
D2D通信は、ダイレクト送信(D2D)と従来のセルラリンクとの間の切り替えをオペレータが管理するネットワーク制御、または、オペレータが制御することなくダイレクトリンクをデバイスによって管理するかのいずれかであり得る。D2Dは、インフラストラクチャモードとアドホック通信とを組み合わせることを可能にする。
【0074】
一般的に、デバイスディスカバリは定期的に必要とされる。さらに、D2Dデバイスは、デバイスディスカバリを実行するためにディスカバリメッセージシグナリングプロトコルを利用する。たとえば、あるD2D使用可能UEがそのディスカバリメッセージを送信することができ、別のD2D使用可能UEが、このディスカバリメッセージを受信し、この情報を使用して、ダイレクト通信リンクを確立することができる。ハイブリッドネットワークの利点は、D2Dデバイスもネットワークインフラストラクチャの通信範囲内にある場合に、eNBのようなネットワークエンティティが付加的に、ディスカバリメッセージの送信または設定を支援することができることである。ディスカバリメッセージの送信または設定におけるeNBの協調/制御は、D2DメッセージがeNBによって制御されるセルラトラフィックとの干渉をもたらさないことを保証するためにも重要である。加えて、たとえデバイスのいくつかがネットワークカバレッジ範囲外にある場合であっても、カバレッジ内デバイスが、アドホックディスカバリプロトコルを支援することができる。
【0075】
本明細書においてさらに使用される用語の定義を目的として、少なくとも以下の2つのタイプのディスカバリ手順が定義される。
−UE自主的リソース選択(後にタイプ1と称される):ディスカバリ情報を告知するためのリソースが、非UE特異的に配分されるリソース配分手順。これは、さらに以下のことを特徴とする:
−−eNBがUEに、ディスカバリ情報の告知に使用されるリソースプール設定を提供する。設定は、たとえば、SIBにおいてシグナリングすることができる。
−−UEは、示されているリソースプールから無線リソースを自主的に選択し、ディスカバリ情報を告知する。
−−UEは、各ディスカバリ期間中に、ランダムに選択されたディスカバリリソース上でディスカバリ情報を告知することができる。
−スケジューリングされたリソース配分(後にタイプ2と称される):ディスカバリ情報を告知するためのリソースが、UEごとに特異的に配分されるリソース配分手順。これは、さらに以下のことを特徴とする:
−−RRC_CONNECTEDであるUEが、RRCを介してeNBからディスカバリ情報の告知のためのリソースを要求することができる。eNBは、RRCを介してリソースを割り当てる。
−−リソースは、UEにおいてモニタリングのために設定されているリソースプール内で配分される。
【0076】
RRC_IDLEであるUEについて、eNBは、以下の選択肢のうちの1つを選択することができる。
−eNBは、SIBにおけるディスカバリ情報告知のためにタイプ1リソースプールを提供することができる。ProSeダイレクトディスカバリのために承認されているUEは、これらのリソースを、RRC_IDLEにおいてディスカバリ情報の告知に使用する。
−eNBは、SIBにおいて、eNBがD2Dをサポートするが、ディスカバリ情報告知のためにはリソースを提供しないことを示し得る。UEは、ディスカバリ情報告知のためのD2Dリソースを要求するために、RRC接続状態に入る必要がある。
【0077】
RRC_CONNECTEDであるUEについて:
−ProSeダイレクトディスカバリ告知を実行することを承認されているUEは、eNBに、当該UEが、D2Dディスカバリ告知を実行したいと望むことを示す。
−eNBは、UEがMMEから受信されるUEコンテキストを使用して、UEがProSeダイレクトディスカバリ告知について承認されているか否かを検証する。
−eNBは、専用RRCシグナリングを介してディスカバリ情報告知のためにタイプ1リソースプールまたは専用タイプ2リソースを使用する(またはリソースを使用しない)ように設定することができる。
−eNBによって配分されるリソースは、a)eNBがRRCシグナリングによってリソースを設定解除するか、または、b)UEがIDLEに入るまで有効である。
RRC_IDLEおよびRRC_CONNECTEDである受信UEは、承認されると、タイプ1とタイプ2の両方のディスカバリリソースプールをモニタリングする。eNBは、SIBにおいてディスカバリ情報モニタリングに使用されるリソースプール設定を提供する。SIBはまた、隣接するセルにおいて告知に使用されるディスカバリリソースをも含み得る。
【0078】
ProSeダイレクトディスカバリのための無線プロトコルアーキテクチャ
図9は、ProSeダイレクトディスカバリのための無線プロトコルスタック(アクセス層)を概略的に示し、アクセス層プロトコルは、MACおよびPHYのみからなる。AS層は、以下の機能を実行する。
【0079】
−上層(ProSeプロトコル)とのインターフェース:MAC層は、上層(ProSeプロトコル)からディスカバリメッセージを受信する。IP層は、ディスカバリメッセージの送信には使用されない。
−スケジューリング:MAC層は、上層から受信されるディスカバリメッセージを告知するために使用されるべき無線リソースを決定する。
−ディスカバリPDU生成:MAC層は、ディスカバリメッセージを搬送するMAC PDUを構築し、MAC PDUを、決定された無線リソースにおいて送信するために物理層に送信する。MACヘッダは付加されない。
【0080】
UEにおいて、RRCプロトコルは、ディスカバリリソースプールをMACに通知する。RRCはまた、MACへの送信のための配分されたタイプ2Bリソースを通知する。MACヘッダは必要ない。ディスカバリのためのMACヘッダは、それに基づいてL2に対するフィルタリングが実行され得るフィールドを一切含まない。MACレベルにおけるディスカバリメッセージフィルタリングは、ProSe UEおよび/またはProseアプリケーションIDに基づいて上層においてフィルタリングを実施するのと比較して、処理または電力を節約するとは考えられない。MAC受信機は、すべての受信されるディスカバリメッセージを上層に転送する。MACは、正確に受信されたメッセージのみを上層に送達する。L1はMACに、ディスカバリメッセージが正確に受信されたか否かを示すと仮定される。上層は、有効なディスカバリ情報のみをアクセス層に送達することを保証すると仮定される。
【0081】
ProSe UE−ネットワークリレー
UEはまた、遠隔UEがPC5基準点を介してProSe UE−ネットワークリレーと通信するように、ProSe UE−ネットワークリレーとして動作するような機能および手順をサポートすることもできる。ProSe UE−ネットワークリレー動作は、3GPPリリース13内で指定されることになる。これまでのところ、3GPP RANワーキンググループにおいて初期合意のみが為されており、それらのいくらかは、たとえば、参照によって本明細書に組み込まれている非特許文献6および非特許文献7に見ることができる。それらの合意のいくつかを下記にリストする。しかしながら、この作業項目は、ごく最近に導入されたものであり、いまだ標準化の途上にあることが留意されるべきである。それゆえ、以下において仮定されている任意の合意は、なお変更または改訂される可能性があり、しかしながら、論述を目的として仮定されている以下の合意は、本開示を、標準化のごく早期段階にあるこの特定の3GPP実施態様に限定するものとして理解されるべきではない。
【0082】
−ProSe UE−ネットワークリレーディスカバリおよびProSeリレー(再)選択について、遠隔UEがカバレッジ内とカバレッジ外である両方のシナリオに対処することができる。
−リレーUEは常にカバレッジ内になる。無線レベルにあるeNBは、UEがリレーとして動作することができるか否かを制御し、一方、ネットワーク制御がリレーUEごとか、セルごと(ブロードキャスト設定)ごとか、もしくは両方か、または何らかの他の様態かは、依然として決定されていない。
−遠隔UEがリレーディスカバリ目的でカバレッジ内にあるとき、ディスカバリのためのモニタリングおよび送信リソースは、たとえば、リリース12メカニズム(アイドルモードについてはブロードキャスト、および、接続モードについては専用シグナリング)を使用してeNBによって提供することができる。遠隔UEは、モニタリングをいつ開始すべきかを決定することができる。
−遠隔UEがカバレッジ外であるとき、ディスカバリおよび通信(実際のデータ転送)のためのモニタリングおよび送信リソースは、UEが実際にいずれのリソースを使用すべきかが正確に分かるように、たとえば、予め設定することによって、すなわち、仕様/オペレータ設定(USIMなどにおいて)によって提供することができる。
【0083】
ProSe UE−ネットワークリレー(再)選択
−遠隔UEは、PC5無線リンク品質の無線レベル測定値を、ProSe UE−ネットワークリレー選択手順のために考慮に入れることができる。
−遠隔UEがカバレッジ外である場合について、無線レベル測定値は遠隔UEによって他のより高位の層の基準とともに、リレー選択を実行するために使用することができる。
−遠隔UEがカバレッジ外である場合について、再選択のための基準は、PC5測定値(RSRPまたは他のRAN1合意測定値)およびより高位の層の基準に基づく。リレー再選択は、遠隔UEによってトリガすることができる。
−遠隔UEがカバレッジ内である場合について、これらの測定値(PC5測定値)が使用されるか否か、および、どのように使用されるかは、依然として決定されていない(たとえば、測定値は、UEによって、カバレッジ外の場合と同様の選択を実行するために使用することができ、または、eNBに報告することができる)。
【0084】
ProSe UE−ネットワークリレーは、レイヤ3パケット転送を使用することができる。たとえば、UE−ネットワークリレー検出およびProSeダイレクトディスカバリのために、ProSe UE間の制御情報を、PC5基準点を介して交換することができる。
【0085】
ProSe使用可能UEはまた、PC3基準点を介して別のProSe使用可能UEおよびProSe関数の間のProSe制御情報の交換をもサポートすることになる。ProSe UE−ネットワークリレーの場合において、遠隔UEは、この制御情報を、PC5ユーザプレーンを介して、LTE−Uuインターフェースを介してProSe関数にむけて中継されるように送信する。
【0086】
ProSe UE−ネットワークリレーエンティティは、eNBのカバレッジエリア内にない、すなわち、E−UTRANに接続されていない遠隔UEに対する「ユニキャスト」サービスに対する接続をサポートする機能を提供する。
図10は、ProSe UE−ネットワークリレーシナリオを示す。ProSe UE−ネットワークリレーは、遠隔UEとネットワークとの間でユニキャストトラフィック(ULおよび/またはDL)を中継すべきである。ProSe UE−ネットワークリレーは、公衆安全通信に関連する任意のタイプのトラフィックを中継することができる一般的な機能を提供すべきである。
【0087】
遠隔UEとProSe UE−ネットワークリレーとの間の1対1ダイレクト通信は、以下の特性を有する。
−PC5基準点を介した通信がコネクションレスである。
−ProSeベアラは双方向性である。所与のProSeベアラ上で無線層に渡されるIPパケットは、関連するL2宛先アドレスを用いて物理層によって送信されることになる。同じProSeベアラ上で無線層から送られるIPパケットは、同じL2宛先にアドレス指定されて無線で受信されていることになる。
ProSe UE−ネットワーク中継は、以下の機能を含むことができる。
−遠隔UEが近接するProSe UE−ネットワークリレーを発見することを可能にするために、モデルAまたはモデルBに従ったProSeダイレクトディスカバリを使用することができる。
−遠隔UEが、遠隔UEによってIPアドレス配分のために使用されるべきProSe UE−ネットワークリレーのL2アドレス、および、ProSe UE−ネットワークリレーによってサポートされる特定のPDN接続に対応するユーザプレーントラフィックを発見することを可能にするために使用することができるProSeダイレクトディスカバリ。
−ダイレクトディスカバリをサポートするPC5基準点で「告知」または「被発見」UEとして動作する。
−UE−ProSe UE−ネットワークリレーポイントツーポイントリンクと対応するPDN接続との間でIPパケットを転送する遠隔UEに対するデフォルトルータとして動作する。
−ルータ要請およびルータ広告メッセージを、IETF RFC4861において定義されているように処理する。
−DHCPv4サーバおよびステートレスDHCPv6リレーエージェントとして動作する。
−IPv4が使用される場合、遠隔UEのローカルに割り当てられているIPv4アドレスを、それ自体に置き換えるNATとして動作する。
−宛先レイヤ2IDとして遠隔UEによって使用されているL2リンクIDを、ProSe UE−ネットワークリレーによってサポートされる対応するPDN接続にマッピングする。
ProSe UE−ネットワークリレーのユーザプレーンプロトコルアーキテクチャが、
図11に示されている。
【0088】
ProSe UE−ネットワークリレーディスカバリ
2つのProSe UE間の通常のリリース12ダイレクトディスカバリについて前述したようにモデルAとモデルBの両方のディスカバリがサポートされ、モデルAは単一のディスカバリプロトコルメッセージ(UE−ネットワークリレーディスカバリ告知)を使用し、モデルBは、2つのディスカバリプロトコルメッセージ(UE−ネットワークリレーディスカバリ要請およびUE−ネットワークリレーディスカバリ応答)を使用する。リレーディスカバリに関する詳細は、参照によって本明細書に組み込まれている非特許文献3の6節に見出すことができる。
【0089】
以下のパラメータは、UE−ネットワークリレーディスカバリ、グループメンバディスカバリ、および、UE−UEリレーディスカバリのすべてに共通である。
−メッセージタイプ:告知(モデルA)または要請/応答(モデルB)、リレーディスカバリ追加情報(モデルA)。
−ディスカバリタイプ:これがUE−ネットワークリレーディスカバリ、グループメンバディスカバリ、または、UE−UEリレーディスカバリであるかを示す。
【0090】
以下のパラメータが、UE−ネットワークリレーディスカバリ告知メッセージ(モデルA)において使用される。
−ProSeリレーUE ID:ダイレクト通信に使用され、ProSe UE−ネットワークリレーが確立したPDN接続と関連付けられるリンク層識別子。
−アナウンサ情報(Announcer info):告知しているユーザに関する情報を提供する。
−リレーサービスコード:ProSe UE−ネットワークリレーが公衆安全アプリケーションに提供する接続サービスを識別するパラメータ。リレーサービスコードは、ProSe UE−ネットワークリレーにおいて広告のために設定され、ProSe UE−ネットワークリレーにおいて、それらが接続を提供する特定のAPNにマッピングする。加えて、リレーサービスコードはまた、ProSe UE−ネットワークリレーがサービスを提供する承認されたユーザをも識別し、たとえば、遠隔UEとProSe UE−ネットワークリレーとの間の認証および承認に必要な関連するセキュリティポリシまたは情報を選択することができる(たとえば、警察関係者のみのための中継のリレーサービスコードは、消防士のみのための中継のリレーサービスコードとは、たとえそれらが、可能性として、たとえば、インターネットアクセスをサポートするために同じAPNへの接続を与えられる場合であっても、異なることになる)。
−無線層情報:遠隔UEが適切なUE−ネットワークリレーを選択するのを支援するための、無線層情報、たとえば、eNBとUE−ネットワークリレーとの間の無線状態に関する情報を含む。
【0091】
以下のパラメータが、UE−ネットワークリレーディスカバリ要請メッセージ(モデルB)において使用される。
−発見者情報:発見者ユーザに関する情報を提供する。
−リレーサービスコード:発見者UEが関心がある接続に関する情報。リレーサービスコードは、関連接続サービスにおいて関心を持たれているProSe遠隔UEにおいて設定される。
−ProSe UE ID:ダイレクト通信に使用される発見者のリンク層識別子(モデルB)
【0092】
以下のパラメータが、UE−ネットワークリレーディスカバリ応答メッセージ(モデルB)において使用される。
−ProSeリレーUE ID:ダイレクト通信に使用され、ProSe UE−ネットワークリレーが確立したPDN接続と関連付けられるリンク層識別子。
−被発見者情報:被発見者に関する情報を提供する。
−無線層情報:遠隔UEが適切なUE−ネットワークリレーを選択するのを支援するための、無線層情報、たとえば、eNBとUE−ネットワークリレーとの間の無線状態に関する情報を含む。
【0093】
ProSe UE−ネットワークリレーを介したProSeダイレクト通信
UE−ネットワークリレー機能は、非特許文献6においてすでに文書化されているProSe機能の発展に基づいて指定されることになる。
【0094】
ProSe UE−ネットワークリレー可能UEは、ネットワークにアタッチし(まだ接続されていない場合)、必要なリレートラフィックを有効化するPDN接続に接続し得るか、または、遠隔UE向けのリレートラフィックを提供するために追加のPDN接続に接続する必要があり得る。UE−ネットワークリレーをサポートするPDN接続は、遠隔ProSe UEリレートラフィックのためにのみ使用されるべきである。
図12は、ProSe UE−ネットワークリレーを介するダイレクト通信を示す。
【0095】
1.ProSe UE−ネットワークリレーが、初期E−UTRANアタッチ(まだアタッチされていない場合)を実行し、かつ/または、中継のためのPDN接続を確立する(この中継のための適切なPDN接続がまだ存在しない場合)。IPv6の場合において、ProSe UE−ネットワークリレーは、非特許文献11において定義されているように、ネットワークからプレフィックスデリゲート関数を介してIPv6プレフィックスを取得する。
2.遠隔UEは、モデルAまたはモデルBディスカバリを使用してProSe UE−ネットワークリレーのディスカバリを実行する。この手順の詳細は前述している。
3.遠隔UEは、受信されたリレー選択情報を使用してProSe UE−ネットワークリレーを選択し、その後、
図3を参照して前述したように、1対1通信のための接続を確立する。
4.IPv6がPC5上で使用されるとき、遠隔IEは、IPv6ステートレスアドレス自動設定を実行し、ここで、遠隔UEは、IETF RFC4862において指定されているようにルータ広告メッセージ(ステップ4b)を要請するために、宛先レイヤ2IDとしてリレーのレイヤ2IDを使用してルータ要請メッセージ(ステップ4a)をネットワークに送信すべきである。ルータ広告メッセージは、割り当てられているIPv6プレフィックスを含むべきである。遠隔UEは、ルータ広告メッセージを受信した後、IETF RFC4862に従って、IPv6ステートレスアドレス自動設定を介してIPv6アドレス全体を構築する。しかしながら、遠隔UEは、インターフェース識別子を生成するための基礎として、非特許文献12において定義されている識別子を一切使用すべきでない。プライバシーのために、遠隔UEは、ネットワークを巻き込むことなく、非特許文献13において定義されているように、IPv6アドレス全体を生成するために使用されるインターフェース識別子を変更することができる。遠隔UEは、パケットを送信している間に自動設定IPv6アドレスを使用すべきである。
5.IPv4がPC5上で使用されるとき、遠隔UEはDHCPv4を使用する。遠隔UEは、宛先レイヤ2IDとしてリレーのレイヤ2IDを使用してDHCPv4ディスカバリ(ステップ5a)メッセージを送信すべきである。DHCPv4サーバとして動作するProSe UE−ネットワークリレーは、割り当てられている遠隔UE IPv4アドレスとともにDHCPv4要請(ステップ5b)を送信する。遠隔UEが貸与要請を受信したとき、UEは、受信されたIPv4アドレスを含むDHCP REQUESTメッセージを送信する(ステップ5c)。DHCPv4サーバとして動作するProSe UE−ネットワークリレーは、貸与期間、および、クライアントが要求している場合がある任意の他の設定情報を含むDHCPACKメッセージを遠隔UEに送信する(ステップ5d)。DHCPACKメッセージを受信したとき、遠隔UEは、TCP/IP設定プロセスを完了する。
【0096】
上記で説明したように3GPPは、主要な作業項目として、リレーディスカバリおよびリレーダイレクト通信を含むProSeリレー機能を導入する。ProSeリレーのために現在定義されているメカニズムはかなり非効率的である。リレー可能ProSe UEが実際にどのように、および、いつ、リレーとして動作し始めるか、すなわち、無線セル内でリレーサービスを提供し始めるかなどの他のメカニズムはまったく合意されていない。
【発明を実施するための形態】
【0120】
移動局もしくは移動ノードまたはユーザ端末もしくはユーザ機器は、通信ネットワーク内の物理エンティティである。1つのノードが、いくつかの機能エンティティを有し得る。機能エンティティとは、所定の機能セットを実施し、かつ/または、これをノードまたはネットワークの他の機能エンティティに提供するソフトウェアまたはハードウェアモジュールを指す。ノードは、ノードを、それを介してノードが通信することができる通信設備または媒体にアタッチする1つまたは複数のインターフェースを有することができる。同様に、ネットワークエンティティは、それを介して他の機能エンティティまたは対応するノードと通信することができる通信設備または媒体に機能エンティティをアタッチする論理インターフェースを有することができる。
【0121】
特許請求の範囲と本出願とを合わせた中で使用されるものとしての「リレーユーザ機器」は、別のユーザ機器(「遠隔ユーザ機器」と称される)に対するリレーとしての役割を果たすことが可能であるユーザ機器を指すものとして広範に理解されるべきである。これはまた、直接的に2つのユーザ機器の間でのダイレクト通信送信をサポートする機能をも含む(下記D2DまたはProSe参照)。一実施態様によれば、リレーユーザ機器は、3GPP LTE−Aについて定義されているものとしての、および、背景技術の節において記載されているものとしてのリレー機能をサポートすべきである。上記に関連して、用語「遠隔ユーザ機器」は、リレーユーザ機器のピアとしての、すなわち、リレーがダイレクト通信をともに確立することを期待するものとしてのユーザ機器の役割を示すのみであるべきである。
【0122】
特許請求の範囲と本出願とを合わせた中で使用されるものとしての用語「無線リソース」は、時間−周波数リソースのような、物理無線リソースを指すものとして広範に理解されるべきである。
【0123】
特許請求の範囲と本出願とを合わせた中で使用されるものとしての用語「ダイレクト通信送信」は、2つのユーザ機器間での直接的な、すなわち、無線基地局(たとえば、eNB)を介しない送信として広範に理解されるべきである。これに応じて、ダイレクト通信送信は、2つのユーザ機器間で直接的に確立される接続に使用される用語である「ダイレクトサイドリンク接続」を介して実行される。たとえば、3GPPにおいて、D2D(デバイス間)通信、またはProSe通信、またはサイドリンク通信の用語が使用される。特許請求の範囲と本出願とを合わせた中で使用されるものとしての用語「ダイレクトサイドリンク接続」は、3GPPのコンテキストにおいては、背景技術の節において記載されているPC5インターフェースとして広範に理解されるべきであり、またそのように理解することができる。
【0124】
特許請求の範囲と本出願とを合わせた中で使用されるものとしての用語「リレー機能」は、ユーザ機器のリレーとして動作する機能として広範に理解されるべきである。例示的な一実施態様において、リレー機能は、背景技術の節において詳細に説明されているものとしての、3GPP作業項目において現在標準化されている機能である。
【0125】
特許請求の範囲と本出願とを合わせた中で使用されるものとしての用語「持続性チェック」は、持続性チェックが成功するか否かを判定するための所与の閾値に対する、ランダムに生成される値の比較に基づく単純な判定として広範に理解されるべきである。閾値を適切に選択することによって、いずれの割合の持続性チェックが成功するかを(概ね)制御することが可能である。
【0126】
3GPPは現在、ProSe可能ユーザ機器のリレー機能を導入している途上にある。いくつかの初期合意(そのうちのいくらかは背景技術の節においてすでに詳細に説明されている)がすでに達成されているが、ProSeリレー機能に関連するいくつかの重要な問題についてはまだ合意を達成することができていない。上記に関連する1つの重要な問題は、ProSeリレー可能UEが実際にどのように、および、いつ、リレーUEになり始める、すなわち、他のProSe遠隔UEに対するリレーとしての役割を果たすことを可能にするためにそのリレー機能を有効化するかという課題である。リレー機能を有効化されているリレーUEは、それに近接する遠隔UEに対するそのディスカバリを可能にするためにリレーディスカバリ手順を実行することになることが留意されるべきであり、これは、モデルA(定期的)またはモデルB(遠隔UEによる要請を受けたとき)に従ってリレーディスカバリメッセージを送信することを含む。
【0127】
リレーUEのためのリレー有効化を制御する1つの可能な方法は、特定の無線セル内でリレーとして動作するための特定の必要条件を、リレー可能UEが満たすか否かを判定することを含む。より詳細には、UEは一般的にリレーとして動作することが可能であるが、無線セルにおいて(たとえば、eNBによって)リレーとして動作することを可能にされる前に付加的に満たされるべきである特定の(リレー)要件が規定されると仮定される。たとえば、リレー可能UEが遠隔UEから入来する追加のトラフィックを中継するリレーとしての役割を果たすことが可能であることが保証されるように、リレーUEとeNodeBとの間のリンクの品質は十分に良好である、すなわち、最小閾値よりも高いものであるべきである。別の例において、高速で移動するリレーUEに接続されている遠隔UEは、リレーUEの送信範囲外にすぐに出て、したがって新たなリレーを選択する必要がある可能性がより高いため、可能性のあるリレーUEが移動している速度も、特定の最大値に限定されるべきである。別の可能なリレー要件は、リレーユーザ機器の充電レベルを指す場合があり、これは、ネットワークとの接続を確立するために特定のリレーUEを選択する遠隔UEのサービス連続性を保証するために、特定の最小閾値を下回るべきではない。
【0128】
しかしながら、無線セルにおいて付加的に規定されるリレー要件を使用することには、過度に多い(不要な)UEが無線セル内でそのリレー機能を有効化することになるという欠点があり得ることに留意すべきである。上述したように、リレー機能の有効化は、リレーディスカバリメッセージを(たとえば、モデルAにおいては定期的に)送信することを結果として含む、リレーディスカバリ手順の開始を含む。これによってリレーディスカバリリソースにおいてコンテンションおよび干渉が不必要に増大する場合があり、したがって、結果として、遠隔UEが、リレーに接続するのに成功するまでに、接続を受けるための2つ以上の可能性のあるリレーデバイスを連続して次々に試行することが必要になるため、リレー選択が遅延する場合がある。その場合にも、多くのリレーが同じリソースセットへのアクセスを試行していることになり得るため、PC5インターフェース上での通信リンク品質が影響を受けることになる。Uu品質が不良であるため(そもそもそのため、UEはリレーを探している)、このことは不良なPC5リンク品質と相まって、ユーザ体験を劣化させることになる。
【0129】
その上、リレー有効化を制御するための別の可能性は、上記に関連して専用シグナリングを使用することである。特に、リレー可能UEは、リレーとしての役割を果たすことに関心があるとき、対応する専用シグナリングメッセージをeNodeBに送信し、eNodeBはその後、要求しているリレーUEがリレーとして有効化されるべきであるか否かに関して決定することが可能になる。その後、リレー機能を有効化するための許可を与えるかまたは拒絶するために、対応する応答メッセージをリレーUEに返信することができる。eNodeBと専用シグナリングを交換することには、eNodeBが、リレー機能を有効化されているリレーUEの数を明示的に制御することができるという利点があるが、これはまた、いくつかの欠点も伴う。たとえば、専用シグナリングは、接続状態にある、すなわち、それを介して専用シグナリングメッセージが送信される、eNodeBとの有効な接続があるときにのみ、eNBに送信することができるため、アイドル状態にあるリレー可能UEにとっては、専用シグナリングを使用することは可能でない。それゆえ、アイドル状態UEは、たとえ後にそれらのリレー機能を有効化することを許可されない場合であっても接続状態に遷移する必要があることになり、それによってリソースおよび電池が無駄になる。さらに、この手法は、厳密に、リレー可能UEが、リレーとしての役割を果たすことを要求するためにeNodeBに専用シグナリングを送信すべきであるときに、可能性を残す。たとえば、eNodeBに専用シグナリングメッセージを送信することによって、特に、多くのリレー可能UEが無線セル内で利用可能であり、eNodeBにリレー機能を有効化するための許可を繰り返し求めることになる場合に、eNodeBにおける負荷が増大する場合があり、Uuリンクを不必要に混雑させる場合がある。加えて、許可を求めるために接続状態に遷移しているアイドル状態UEは、eNBによって、たとえば、接続解放メッセージを送信することによって、RRC接続が明示的に解放されるまで、接続状態のままである必要がある。さらに、遠隔UEに対するリレーとしての役割を果たすことを期待して接続状態のままであることによって、遠隔UEがリレーUEをリレーとしての役割を果たすものとして実際に選択するまでに、リレーUEが長時間待機することになり得る。アイドルモード自体にある間に、リレーUEがリレーとして動作する機会があることがより良好であることになる。
【0130】
リレー有効化のための別の可能な解決策は、上述した両方の手法を組み合わせること、すなわち、追加のリレー要件をチェックし、eNBからの許可を得るために専用シグナリングを使用することである。しかしながら、この組合せ手法においてもまた、過度に多くの(不要な)要求がeNBに送信されることになり得、それによって、Uuリンクが混雑し、eNBにおける処理負荷が増大する。さらに、この組合せ手法においてもまた、アイドル状態UEは、後に、さらなるリレーが実際には必要ない場合にそれらのリレー機能を有効化することをeNodeBによって拒絶されるときに、不要にRRC接続を確立する(すなわち、接続状態に遷移する)場合がある。その上、この組合せ手法は、専用シグナリング要求がいずれの時点においてeNodeBに送信されるべきかを指定せず、すなわち、リレー要件が満たされる限り繰り返される。
【0131】
以下の例示的な実施形態は本発明者らによって、上記で説明した問題のうちの1つまたは複数を軽減するために着想されている。
【0132】
様々な実施形態の特定の実施態様は、3GPP規格によって与えられ、背景技術の節において部分的に説明されているような広範な仕様において実装されるべきであり、特定の重要な特徴が、様々な実施形態に付随して以下に説明されているように追加される。実施形態は、たとえば、上記背景技術の節に説明されている3GPP LTE−A(リリース10/11/12/13)の通信システムのような移動体通信システムにおいて有利に使用することができるが、実施形態は、この特定の例示的な通信ネットワークにおける使用に限定されないことに留意されたい。
【0133】
これらの説明は本開示の範囲を限定するものとして理解されるべきではなく、本発明の開示をより良好に理解するための実施形態のほんの一例として理解されるべきである。特許請求の範囲において説明されているような本開示の全般的な原理を、異なるシナリオにおいて、本明細書において明示的に記載されていない様式で適用することができることを、当業者は認識するはずである。例示を目的として、ただし、以下の実施形態の範囲を制限すべきではないいくつかの仮定が行われる。
【0134】
さらに、上述したように、以下の実施形態は、3GPP LTE−A(リリース12/13)環境内で実施することができる。様々な実施形態は主に、他の機能(すなわち、様々な実施形態によって変更されない機能)が、背景技術の節において説明されているものと正確に同じままであり得るように、または、様々な実施形態に一切影響を与えないように変更され得るように、リレーUEによって実行されるリレー有効化手順のためのメカニズムを提供する。これは、たとえば、リレー機能が有効化された後に開始されるリレーディスカバリ手順、および、リレーが行われるダイレクトサイドリンク接続を確立するための正確な手順、および、遠隔ユーザ機器とリレーユーザ機器との間でデータが中継される方法の正確な手順について当てはまる。
ユーザ機器がProSe通信、すなわち、eNodeBを介して迂回することのないUE間の直接的なダイレクトD2D送信を実行することを可能にされる(ProSe使用可能UE)シナリオが仮定され得る。さらに、このシナリオにおけるこれらの(ProSe使用可能)UEのうちの少なくとも1つは、たとえば、3GPP規格のリリース13における特定の実施態様について背景技術の節において説明されているようなリレー機能をサポートすべきである。言い換えれば、このリレーUE(無線セル内に位置し、無線セルを制御する対応する無線基地局に接続されている)は、他の(ProSe使用可能)UE(遠隔UE)に対するリレーとしての役割を果たすことが可能であるべきであり、それによって、これらの遠隔UEが、リレーを介してeNBに接続することが可能にされる。
【0135】
第1の実施形態
以下において、上記の問題を解決するための第1の実施形態を、詳細に説明する。第1の実施形態の複数の異なる実施態様が、下記に詳細に説明される。第1の実施形態によれば、リレー可能UEにおけるリレー機能の有効化が改善される。
【0136】
第1の態様の一般的な実施態様は、リレー機能を有効化すべきか否かを判定するためにリレーUEにおいて実行されるべきリレー有効化手順に関するリレーUE挙動を示す
図13のフロー図に関連して説明される。
【0137】
eNodeBは、その無線セル内のリレー可能UEがそれぞれのリレー有効化手順をいつ開始すべきかを管理しており、したがって、その無線セル内の不要なリレー有効化を回避することができる。上記に関連して、eNodeBは、主に、無線セル内で1つまたは複数の追加のリレーが必要であるときに、リレー有効化手順をトリガすべきである。他方、無線セル内でそれ以上のリレーが必要ない場合、eNodeBは、その無線セル内でリレー有効化手順を開始するためにリレーUEをトリガしない。上記を目的として、eNodeBは、さらなるリレーが必要であると判定すると、好ましくは、すべてのカバレッジ内リレー可能UE(たとえば、それによって、リレー機能を有効化することでカバレッジエリアを大幅に拡大するために、eNodeBのカバレッジエリアの外縁にあるUEも)によって受信されるべき適切なブロードキャストメッセージを、その無線セル内で送信する。このブロードキャストメッセージは、リレー有効化手順を開始するためのトリガを含むか、または、受信リレーUEによってそのようなトリガとして解釈されるべきである。たとえば、ブロードキャストメッセージは、明示的なリレートリガ、たとえば、1ビットフラグを含むことができる。
【0138】
さらに、eNBは、適切な持続性チェック値(閾値)を選択し、たとえば、無線セル内で必要とされるリレーの数に応じて特定の値が選択される。それぞれのリレーUE内で実行される、リレー有効化手順において持続性チェックを使用することによって(後に詳細に説明する)、eNodeBは、最終的にリレー機能を有効化することになるリレーUEの数を制御することができる。この持続性チェック値もまた、eNodeBによって無線セル内でブロードキャストされるブロードキャストメッセージ内に含まれる。有利には、さらなるリレーが必要であるというブロードキャストメッセージ内に別個のインジケーション(すなわち、リレーUEにおけるリレー有効化手順の開始をトリガする別個のインジケーション)を与える代わりに、ブロードキャストメッセージ内に持続性チェック値が存在することがすでに黙示的に、さらなるリレーが必要であるというこのインジケーションとして考えられてもよい。
【0139】
これに応じて、無線セル内のこれらのリレー可能UEのうちの1つの観点からは(すなわち、
図13参照)、リレー有効化トリガ(リレー有効化手順の実行を開始するための)および持続性チェック値を有する、対応するブロードキャストメッセージが受信される。ブロードキャストメッセージが受信されることによって、リレーUEにおけるリレー有効化手順がトリガされ、これは、リレー機能が実際に有効化されるべきであるか否かを判定するための以下のテストを含む。
【0140】
第1のチェックはすでに前述したものであり、すなわち、ブロードキャストメッセージにおいて受信される持続性チェック値に基づいてリレーUEによって実行される持続性チェックである。持続性チェックは、リレーUEによって実行されるべきであり、これに成功したときにのみ、リレー機能の有効化が可能であるべきである。成功しない場合、リレーUEは、リレー有効化手順を終了し得、リレーUEにおけるリレー有効化手順を新たにトリガする別のブロードキャストメッセージをモニタリングし続けることができる。
【0141】
リレーUEによってリレー有効化手順中に実行されるべきもう1つのチェックが、リレーとして動作する無線セル内の必要条件として定義される追加のリレー要件が、リレーUEによって満たされるか否かである。ここでも、追加のリレー要件が満たされるときにのみ、リレー機能の有効化が可能であるべきである。リレー要件が満たされない場合、リレーUEは、リレー有効化手順を終了し得、リレーUEにおけるリレー有効化手順を新たにトリガする別のブロードキャストメッセージをモニタリングし続けることができる。
【0142】
図13から明らかであるように、リレーUEによって両方のチェックが首尾よく終了すると、リレーUEは、そのリレー機能を有効化し、したがって、セル内でその存在を告知するためのリレーディスカバリ手順から開始することができる。リレーディスカバリ手順は、リレーUEによって、たとえば、背景技術の節において説明されているようなモデルAまたはモデルBに従って実行することができる。これに応じて、リレーを介したeNodeBとの接続を維持または開始する必要がある遠隔UEによって、有効化されたリレーUEを発見し選択することができる。言及されているリレーディスカバリ手順、リレー選択手順および中継手順のような、リレー機能が有効化された後に実行されるべき後続の手順に関するさらなる詳細は、それ自体は本明細書では省かれており、代わりに、これらの手順の可能な例示的な実施態様として、背景技術の節が参照される。
【0143】
ちょうど説明した第1の実施形態によるリレー有効化は、eNodeBが、その後これに応じてブロードキャストメッセージを送信するために実際にリレーが必要であるときを明確に判定することを含む。これによって、実際に必要であるときにのみ、リレーUEにおけるリレー有効化手順をトリガすることが可能になる。それゆえ、それによって、第1の実施形態の改善されたリレー有効化によって、不要なリレーUEにおいてリレー有効化手順が開始されることが回避され、これによって、リレーUE側での処理が節約される。さらに、第1の実施形態のリレー有効化において持続性チェックを実施することによって、リレー機能を有効化することになるリレーUE(リレー有効化手順を開始する無線セル内のすべてのリレーUEの中の、すなわち、好ましくはまだそのリレー機能が有効化されていないもの)の数を限定するために、eNodeBのさらなるレベルの制御が提供される。これに応じて、(おおよそ)必要な数の追加のリレーのみが有効化されることになり、それによって、リレーディスカバリリソース(その後、リレーUEによってその有効化後に使用される)が、不要なリレーディスカバリメッセージによって混雑しない。第1の実施形態によるリレー有効化のこの特定の手法によって、eNodeBによる許可を求めるさらなる要求が含まれることも避けられ、それによって、さらなるメッセージがUuリンクを介して責任のあるeNodeBに送信されることが回避される。これに応じて、同時に、eNodeBが、(少なくとも)最終的にリレー機能を有効化することになるリレーUEの数を制御することを可能にしながら、eNodeBにおける負荷が増大されず、Uuリンクの混雑が回避される。
【0144】
以下において、第1の実施形態のさらなる異なる代替的な実施態様を説明する。
【0145】
図13による第1の実施形態の(および、残りの図面による残りの実施態様の一部分にもなる)実施態様について説明したように、リレーUEは、リレーUEが無線セルにおいて規定されている特定のリレー要件を満たすか否かを判定する。これらの特定のリレー要件は、たとえば、eNodeB、もしくは、MMEのような基幹ネットワーク内の別の責任のあるエンティティによって、または、ProSe関数自体によって規定されてもよい。この場合、特定のリレー要件に関する対応する情報は、eNodeBによって、たとえば、適切なSIB(システム情報ブロック)において無線セル内でブロードキャストされ得る。代替的に、要件は、UE内でハードコード化されるか、または、たとえば、USIMにおいてオペレータによって予め個設定されるか、または、NAS(非アクセス層)シグナリングを含むより高位のシグナリングによって設定されるか、または、リレーUEが以前に接続状態にあった場合は、eNBによってリレーUEに対する専用シグナリングメッセージ内で与えられてもよい。
【0146】
特定のリレー要件は、無線セルごとに異なる場合があり、現在の状況に応じて厳密さには程度の差があり得る。別個にまたは組み合わせて利用することができる、いくつかの可能なリレー要件が、以下に提示される。しかしながら、これらのパラメータは、リレー要件として必ず使用されなければならないものとして考えられるべきではなく、例として考えられるべきである。たとえば、リレーUEとeNodeBとの間の無線リンク(すなわち、Uuリンク)の品質は、リレーUEによる効率的な中継/転送を保証するために、特定の制限を下回るべきではない。他方、Uu品質が良好に過ぎるリレーUEは、セル端から、または、カバレッジホールから遠く離れる可能性があり得、それによって、無線セルにとって、そのようなリレーUEがリレーとして動作することに関して関心のあるようなものではなくなり得ることを考慮すると、Uuリンク品質は付加的に、所定の閾値を下回ったままである必要があり得る。予想されるリレーUEによって満たされるべき別の可能なリレー要件は、リレーUEのモビリティに関係し得る。たとえば、高速で移動しているリレーUEは、遠隔UEの及ぶ範囲外に出る可能性がより高く、したがって、これらの遠隔UEは別のリレーUEを選択することを余儀なくされる。これに応じて、無線セル内でリレーとして動作したいと望む任意のリレーUEによって満たされるべきリレー要件として、リレーUEのモビリティ/移動度の上限が規定され得る。さらなる可能なリレー要件は、好ましくは、リレーUEが十分に長い時間にわたってリレーとして機能することが可能であることを保証するために最小閾値を上回るべきである、リレーUEの充電レベルを参照する。たとえば、残りの電池が限られているリレーUEがリレーとして選択された場合、遠隔UEに向かって進むパケットがその電池電力を急速に枯渇させる可能性がある。これは、新たなリレーを選択する必要がある遠隔UEにとってだけでなく、より速く終了してしまうリレーUEの通常動作にとっても有害である。
【0147】
他のリレー要件は、たとえば、リレーUEが遠隔UEに対するリレーとしての役割を果たすことを妨げるか、または、深刻に阻害することになる、リレーUEにおける過負荷状況を参照する。「リレーが、リレーとしての役割を果たすことを妨げるか、または、深刻に阻害する」ことの機能定義は、リレーユーザ機器が、さらなる単一の遠隔ユーザ機器に対するリレーとしての役割を果たすことが不可能であるというように狭く解釈されるべきではない。むしろ、過負荷状況は、たとえば、リレーユーザ機器の効率的な動作が保証されると理解される特定の制限を規定することによって、リレーユーザ機器にとって柔軟に定義され得る。過負荷は、プロセッサ、メモリ、ポート、論理チャネルID、アップリンク/ダウンリンクにおいて利用可能な帯域幅などのような、リレーユーザ機器のハードウェアまたはソフトウェア構成要素のいずれかを参照し得る。過負荷は、急速に変化する場合があるため、一時的なものであることを特徴とする。
【0148】
これに応じて、これらのまたは他のリレー要件のうちの1つまたは複数からなるセットが、第1の実施形態の実施態様のリレー有効化手順中に、任意のリレーUEによってチェックされる必要があり得る。
【0149】
図13の特定の実施態様について、2つのチェックが基本的に並列に実行されると仮定されている。一方、
図14は、第1の実施形態の異なる実施態様を示しており、これら2つの判定が連続的に実施され、特定の順序は、本開示の機能とは無関係である。
図14の例示的な実施態様において、単純な持続性チェックが最初に実行され、この持続性チェックが成功する場合にのみ、リレーUEは引き続き、リレー要件が満たされるか否かをチェックする。それゆえ、すでに持続性チェックに失敗している場合、リレー要件が満たされるか否かをさらにチェックする必要はないため、リレー有効化手順は即座に停止することができ、これによって、リレーUEにおいて処理が節約される。
【0150】
同様に、図面には示されていないが、リレーUEは、最初にリレー要件が満たされるか否かをチェックしてもよく、リレー要件が満たされる場合にのみ、引き続き持続性チェックを実行してもよい。したがって、すでにリレー要件チェックに失敗している場合、さらに持続性チェックを実行する必要はないため、リレー有効化手順は終了することができ、これによって、リレーUEにおいて処理が節約される。
【0151】
その上、上述したように、リレーUEは、ブロードキャストメッセージ内でeNodeBによって与えられる持続性チェック値に基づいてリレー有効化手順中に持続性チェックを実行する。その後生成されるランダム値が、持続性チェックに合格または不合格であるように比較される閾値と考えることができる持続性チェック値は、eNodeBにおいて、たとえば、eNodeBが有効化されることを所望するリレーUEの数に基づいて決定される。一実施態様において、eNodeBは、独自のインターフェースを通じてもしくはMMEのような基幹ネットワーク要素を通じてeNBが受信することができるProSe関数からのフィードバックを含む多くの要因に基づいて、または純粋に、たとえば、平方キロメートルあたり一定数のリレーが必要とされることを記述する、ネットワークからのOAM(ネットワーク運用および管理)設定に基づいて、または純粋に、セル内で公衆安全サービスを実行しているUEの数(eNBによってサービスされているCQIクラスのベアラから明らかになる)および/もしくは公衆安全サービスを実行している一定数のUEあたり一般的に必要とされるリレーUEの数に関する何らかの統計的計算からのそれ自体の推定に基づいて、セル内で必要とされるリレーUEの数を決定することができ、あるいは、セル内で必要とされるリレーUEの数に関するeNodeB決定は、純粋に、UEの、リレーサービスに対するそれらの要件の報告に基づいてもよい。別の例は、UEの、リレーサービスに対するそれらの要件の報告が、カバレッジ内公衆安全UEが(Uuインターフェース上で)不良な無線品質を受けていること、および、eNodeBがカバレッジ外UEの可能な数を含めるためにこの数字を推定することに基づき得ることであり得る。
【0152】
持続性チェックは従来技術の3GPP規格においてすでに使用されているが、これは他の目的のためである。たとえば、非特許文献8は、たとえば、以前の送信が成功と判断されなかったときにUEがRACHチャネルにアクセスすることを可能にされる時点を制御するために使用される持続性値Piを規定している。アクセスを時間領域において分散させることによって、任意の所与の時点においてRNCにアクセスするUEの数がRNCによって、持続性値Piの値を調整することによって厳密に制御される。
【0153】
第1の実施形態の変形形態によれば、持続性チェックは同様に実行されてもよい。したがって、その中で持続性チェック値がeNodeBによって選択される値の範囲(たとえば、0と1との間)が規定される。これに応じて、リレーUEは、リレー有効化手順中に、この同じ値範囲内でランダム値を生成する。持続性チェックに合格するために、リレーUEのランダムに生成されている値は、eNodeBによって選択される持続性チェック値と比較される。1つの可能性は、ランダムに生成されている値が、eNodeBによって与えられる持続性チェック値以下である場合に、持続性チェックが成功すること、または、ランダムに生成されている値がeNodeBによって与えられる持続性チェック値よりも大きい場合は、その逆であることを定義することになる。たとえば、適切な持続性チェック値を選択することによって、eNodeBは、持続性チェックが成功するまたは成功しない割合を制御することができる。ランダムに生成されている値が持続性チェック値以下であるときに持続性チェックが成功すると仮定するとき、eNodeBは、持続性チェック閾値を低い値、たとえば、0.1に設定することによって、成功する持続性チェックを低い割合に制限することができ、これに応じて、持続性チェック閾値を0.5のような中程度の値に設定することによって、eNodeBは、約半分のみの持続性チェックが成功するように制御することが可能になる。これに応じて、持続性チェックは、リレーUEが専用シグナリングを介して直接的にeNodeBからの許可を求めるよう強制する必要なしに、eNodeBが、そのリレー機能を有効化することになる/有効化することができるリレーUEの数に対していくらか制御する余地を残す単純で効果的なメカニズムを提供する。
【0154】
それにもかかわらず、第1の実施形態の先行する実施形態は、eNodeBからの許可を求める専用の要求を行う必要がないが、第1の実施形態の代替的な実施形態は、そのような追加の制御レベルを含む。具体的には、
図15のフロー図が、
図14の前述した実施態様に基づいて、そのような例示的な実施態様を示している。持続性チェックおよびリレー要件チェックに加えて、
図15に示されている第1の実施形態のこの代替的な実施態様によるリレー有効化手順は、付加的に、リレーUEがそのリレー機能を有効化することを可能にされるか否かについて、リレーUEがeNodeBから許可を要求することを含む。この許可を求める追加の要求は、たとえば、
図15に示す実施態様について仮定されているように、リレー有効化手順の両方のチェックが首尾よく完了した後に、実行することができる。それゆえ、eNodeBにはその後、要求しているリレーユーザ機器の各々について1つずつ許可を特定的に拒絶または承認する機会があることになる。たとえば、これは、eNodeBがその無線セル内にあるリレー可能UEの数を知らず、しかしeNodeBが依然として、リレー機能が有効化されているUEの数を特定の制限未満のままにしたいと望むシナリオにおいて有利である。
【0155】
これに応じて、対応するメッセージ(たとえば、リレー有効化要求メッセージと称される)を無線基地局に送信した後、リレーUEは、無線基地局からの応答、すなわち、リレーUEがそのリレー機能を有効化することを可能にされるか否か、を含む対応する応答メッセージ(たとえば、リレー有効化応答メッセージと称される)を待ち、最終的に受信することになる。この応答メッセージの内容にしたがって、このようにリレーUEはそのリレー機能を有効化し、または有効化しない。一実施態様において、要求と応答メッセージの両方を、RRCメッセージ(たとえば、非特許文献9のSidelinkUEInformation、詳細については下記参照)、または、各々要求および応答メッセージについて指定のLCID(論理チャネルID)を有するMAC CE(制御要素)のいずれかとして設計することができる。
【0156】
このリレー有効化要求メッセージは、リレーUEのリレー機能を有効化するための許可を求める要求(および、無線リソースを求める要求、後述する第1の実施形態の実施態様を参照)を搬送することができるだけでなく、以下に説明するようなさらなる情報を含むこともできる。
【0157】
たとえば、メッセージは、許可を求める目的がリレーとして動作することであることを示し得る。
【0158】
さらに、リレーUEからeNodeBへと送信されるこのリレー有効化要求メッセージは、リレーUEによって遠隔ユーザ機器に提供することができる1つまたは複数のサービスに関する情報を含むことができる。たとえば、サービスは、公衆安全サービスまたは非公衆安全サービスであってもよい。いずれにせよ、提供されるサービスに関するそのような情報を与えることによって、eNodeBは、それぞれの1つまたは複数の提供されるサービスと関連付けられる優先度を決定することができ、したがって、リレーUEがそのリレー機能を有効化することを許可するかまたは許可しないかの決定に、そのような情報を根拠として用いることができる。一例として、可能性のあるリレーUEは、フラットなレイアウトにける音声特有の呼び出しに対して医療救急人員を供与する意図を示す場合があり、すでに5つのそのようなリレーを受け入れ、承認しているeNodeBは、セル内で(干渉を生じさせることなく)より多くのリレーを許容することができないこと、および、たとえば、近接サービスからのその知識に基づいて、5つのリレーですでに十分であることをすでに知っており、それによって、eNodeBはリレーになるための新たな要求を拒絶する。
【0159】
同様に、リレーUEは、リレーUEによって遠隔ユーザ機器に提供することができる1つまたは複数のサービスに関するグループ識別情報を含むことができる。このグループ識別情報は、1つまたは複数の提供されるサービスの各々が属するグループを識別することを可能にする。
【0160】
リリース12、13の3GPP規格環境における特定の実施態様によれば、SidelinkUEInformationメッセージ(参照によって本明細書に組み込まれている非特許文献9の6.2.2節においてすでに定義されている)は、上記に関連して再使用することができる。これに応じて、SidelinkUEInformationメッセージは、上記で説明したようないくつかの追加の情報を示すことを可能にするために、追加の情報要素を用いて拡張することができる。たとえば、
−許可を求める目的が、リレーとして動作することであり、
−当該リレーは、リソースを求める要求が、リレーディスカバリ手順のためのリソースを参照し、たとえば、商用ディスカバリ手順またはさらには2つのProSe UE間のリリース12 D2D(ダイレクト)通信のためではないものであり、したがって、対応する追加の情報要素は、リレーディスカバリ手順のためのリソースと、リリース12ダイレクトディスカバリ手順および/またはリリース12 D2D通信のためのリソースを同時に要求することを可能にする。
【0161】
SidelinkUEInformationメッセージの拡張定義の対応する例が、下記に与えられる。
【0162】
SidelinkUEInformationメッセージ
【表1】
【表2】
【0163】
第1の実施形態のさらなる実施態様によれば、リレー有効化手順はまた、リレーディスカバリ手順(リレー機能の有効化に続いて開始される)を実行するために無線リソースがすでに利用可能であるか否かをも考慮に入れる。上記に関連して、標準化においては、リレーディスカバリのために使用されるべき無線リソースがいつ、および、どのように定義されてリレーUEに提供されるかについて、まだ最終合意が為されていないことに留意されたい。1つの可能性のある実施態様は、リレーUEによって実行されるべきリレーディスカバリ手順と関連して使用されるべきである無線リソースを提供する、適切なリレーディスパバリリソースプールをブロードキャストすることである。結果として、その後、特定の無線リソースが、リレーUEによってそのような適切なリレーディスカバリリソースプールから自動的に選択され得るか、または、特定の無線リソース(このリレーディスカバリリソースプール内からの)が、(リレーUEによる要求を受けたとき)eNodeBによってスケジューリングされる必要がある。無線セル内のリレーUEは、そのようなプールから無線リソースを自動的に選択することを可能にされるように設定することができるか、または、最初にeNodeBから専用無線リソースを要求する必要があり得る。いずれにせよ、リレーUEは、無線リソースがすでに、リレーUEによって、そのリレー機能の有効化を受けて実行されるべきリレーディスカバリ手順のために使用されるために設定されており、利用可能であるか否かを判定する。その後、適切な無線リソースがリレーUEにとって実際に利用可能である場合、リレーUEは、リレー有効化手順を続ける(たとえば、リレー機能を有効化する)ことができる。他方、リレーUEにとってリレーディスカバリ手順のために適切な無線リソースが利用可能でない場合、リレーUEは、無線基地局からそのような無線リソースを要求することができ、無線基地局は、これに応じて、リレーディスカバリのための適切な無線リソースを受信し、これを割り当てることによって応答することになる。適切な無線リソースが割り当てられると、リレーUEは、リレー有効化手順を続ける(たとえば、リレー機能を有効化する)ことができる。
【0164】
上述したように、無線リソースを要求する方法の1つの可能な実施態様は、SidelinkUEInformationメッセージを使用することである。リレーUEは、このメッセージ内で、リレーディスカバリ手順のためのリソースが要求されていることをシグナリングすることができる。さらに、SidelinkUEInformationメッセージは、同じSidelinkUEInformationメッセージ内で、リレーUEが付加的に、商用ディスカバリおよび/またはリリース12 D2D通信のためのリソースを要求することができるように、リレーディスカバリ手順のためのリソースを要求するための情報要素によって拡張されるべきである。SidelinkUEInformationメッセージの可能な例示的な実施態様が、下記に与えられる。
【0165】
SidelinkUEInformationメッセージ
【表3】
【表4】
【0166】
無線リソースをチェックおよび要求する方法の1つの特定の例示的な実施態様が
図16に示されており、これは、リレーUEが、リレー機能を有効化する前に、最初にeNodeBからの許可を求めることを追加で必要とする、
図15に関連して論じられている先行する実施態様に基づく。しかしながら、代替的に、この特定の実施態様は、許可を求める追加の要求がリレーUEによって実行されることなく、すなわち、リレーUEが、無線リソースが必要とされるか否かを判定し、そうである場合、eNodeBから無線リソースの許可を要求および受信する、上述した追加のステップによって、
図13および
図14に関連して説明されているようなリレー有効化手順を拡張することによっても可能であることに留意されたい。
【0167】
図14に関連して説明されている例示的な実施態様の対応する拡張が、
図17のフロー図によって示されているが、わずかな改変が行われている。
図16に関連してすでに説明されているように、リレーUEは付加的に、無線リソースがすでにリレーディスカバリ手順に対して利用可能であるか否かを判定し、そのようなリソースが利用可能でない場合、リレーUEは、eNodeBにむけてそのような要求を継続する。その後、無線リソースが割り当てられるか否かに応じて、リレーUEは、リレー機能の有効化を継続する(無線リソースが実際に割り当てられる場合)か、または、リレー有効化手順を終了する(無線リソースが割り当てられない場合)。それゆえ、この有利な実施態様において、リソースを求める要求は、リレー機能が有効化されるか否かの許可を求めるために再使用することができる。特に、eNodeBは、無線リソース要求に応答して無線リソースを割り当てることまたは割り当てないことによって、リレー機能を有効化するための許可を特定のリレーUEに与えるかまたは拒絶する機会を有することになるため、リレーUEによって無線基地局に送信される無線リソースを求める要求は、許可を求める黙示的な要求と考えることができる。これに応じて、要求しているリレーUEがそのリレー機能を有効化すべきでないとeNodeBが決定するとき、eNodeBは単純に、(応答メッセージをリレーUEに返信しないこと、または、無線リソースが割り当てられないという対応する情報によって応答することのいずれかによって)リレーUEにリソースを割り当てないことができ、そのためこれは、リレーUEによって、eNodeBがリレー機能を有効化するための許可を与えていないと解釈される。他方、割り当てられる無線リソースに関する対応する情報を与えることによって、要求しているリレーUEがそのリレー機能を実際に有効化すべきであるとeNodeBが決定するとき、eNodeBは、リレーUEがリレー機能を有効化することを黙示的に許可する。
【0168】
図17による実施態様において、無線リソースを判定および要求するための追加のステップは、2つのチェック(リレー要求チェックおよび持続性チェック)の後に設けられる。これは、この流れによって、上記2つのチェックのうちの一方が失敗する場合に、さらなるメッセージがUuリンクを介して無線基地局に送信されることが回避されるためである。それにもかかわらず、理論的には、無線リソースを判定および要求するためのこれらのステップは、無線リソースが利用可能になった(それらが要求される前または後に利用可能にすることによって)後にのみ、持続性チェックおよび/またはリレー要件チェックが実行されるように、代替的に、持続性チェックおよび/またはリレー要件チェックの前に設けられてもよい。
【0169】
第1の実施形態のさらなる変形形態が、
図18に関連して説明され、これは、付加的に、リレーUEがRRCアイドル状態にあるか、または、RRC接続状態にあるかを考慮に入れる。この追加の改善を説明するために、リレー有効化手順が、前に説明したようにリレーディスカバリ手順のためにリソースが利用可能であるか否かをリレーUEが判定するステップをも含むことが例示的に仮定される。しかしながら、UEのアイドル/接続状態を考慮に入れるこの追加の改善も、独立して(すなわち、無線リソース判定を有する必要なしに)リレー有効化手順に含むことができることに留意されたい。一般的に、リレーUEはリレーディスカバリ手順を実行するときにRRC接続またはアイドル状態にあり得るが、リレーUEは中継のためにUuリンク上でデータを転送および受信する必要があるため、遠隔UEによってリレーとして動作することが選択されたとき、リレーUEは接続状態に遷移する必要があることになる。したがって、たとえば、リレーUEはRRCアイドル状態においてリレーディスカバリ手順を実行してもよいが、遠隔UEに対するリレーになることが選択されたとき、その後、RRC接続状態に遷移することになる。それにもかかわらず、eMBMSトラフィックを遠隔UEに中継する場合、中継はまた、RRCアイドルであるリレーUEによって行われてもよい。その上、(たとえば、リソースを要求するための、および/または、リレー機能を有効化するための許可を要求するための)無線基地局とのダイレクト専用シグナリングを伴う第1の実施形態の有利な実施態様については、リレーUEは、この専用シグナリングを実行することが可能であるように、RRC接続状態にあるべきである。それゆえ、第1の実施形態の有利な実施態様において、アイドル状態にあるリレーUEは、リレー有効化手順を継続/終了する前に、最初に接続状態に遷移することになる。上記目的のために、リレーUEは最初に、特定のRRC状態、すなわち、アイドル状態であるかまたは接続状態であるかを判定することができ、リレーUEがアイドル状態にある場合、リレーUEは、(
図18の特定の例においては、専用シグナリングによって無線基地局から無線リソースを要求するために)リレー有効化手順を継続する前に、接続状態に遷移するための対応する手順を実施する必要があることになる。
【0170】
アイドル状態から接続状態へと遷移するステップは、たとえば、RRC接続手順によって実行することができることに留意されたい。RRCアイドル状態からRRC接続状態へと遷移するためのそのような手順の特定の実施態様は、3GPPにおいてすでに標準化されており、これはたとえば、参照によって本明細書に組み込まれている非特許文献9によって5.3.3節において定義されているRRC接続確立手順である。要約すると、リレーUEによってランダムアクセスが実行された後、リレーUEは、RRC接続要求メッセージ(RRCConnectionRequestメッセージ)をeNodeBに送信し、eNodeBはその後、リレーUEとeNodeBとの間にRRC接続を確立するために、必要なパラメータを含むRRC接続応答メッセージ(RRCConnectionSetup)を送信することによって応答し、これは、C−RNTIと呼ばれるUE特有のRRCレベル識別情報に基づくUEコンテキストをさらに含む。UEはさらに、RRC接続が解放されるまでUEとeNodeBの両方において保持されるこのC−RNTIに基づいてUuリンク上で識別される。リレーUEが接続状態に遷移すると、リレーUEは通常、eNodeBによって接続が解放されるまで、または、UEがRRC接続の再確立が可能でない無線リンク失敗後にアイドルモードに遷移しなければならなくなるまで、接続状態に留まる(非特許文献9の5.3.7節)ことに留意されたい。
【0171】
それゆえ、特にリレー有効化手順を首尾よく完了するために専用シグナリングが必要とされる第1の実施形態の実施態様については、アイドル状態にあるリレーUEもまた、リレー有効化手順を首尾よく完了することを可能にされ得る。
【0172】
第1の実施形態のさらなる変形形態によれば、ネットワーク内のProSe関数は、
図19の例示的な図解に関連して以下で説明されるように、リレー有効化も制御することになる。具体的には、ProSe関数は、第1のトリガとして対応するリレー開始メッセージをリレーUEに送信し、それによって、リレーUEは、ブロードキャストメッセージがeNodeBによってそれを介して送信される、対応する無線リソースのモニタリングを開始する。具体的には、それぞれの無線セルにおけるリレー状況に対する何らかのネットワーク制御を維持するために、ProSe関数は(たとえば、付加的にProSeアプリケーションサーバと協議して)、たとえば、特定の地理的領域/セルにおいて何らかの特別な公衆安全シナリオが通知されるときに、(たとえ前に説明したようにさらなる制御がeNodeB次第であり得るとしても)特定の無線セルがリレーを提供すべきであると決定することができる。したがって、無線セル内のリレー可能UEに対応するリレー開始メッセージを送信することによって、ProSe関数は、(たとえば、参照によって本明細書に組み込まれている非特許文献9の5.2節において定義されているように)リレーUEにおいて実際にリレー有効化手順をトリガするためのメッセージをeNodeBからブロードキャストするために、リレーUEをトリガする。したがって、
図19から明らかであるように、リレーUEは、リレー開始メッセージをモニタリングし、最終的に受信することになり、この場合、リレーUEは、eNodeBからブロードキャストメッセージを受信するために無線リソースのモニタリングを開始する。
【0173】
代替的に、または付加的に、ProSe関数が、eNodeBを通じてリレー有効化を開始するために、同様のメッセージをeNodeBに送信してもよい。eNodeBはその後、ProSe関数から受信される対応するリレー開始メッセージから、さらなるリレーが必要であると直ちに結論し、したがって、前述したブロードキャストメッセージを無線セル内でリレーUEに送信する。代替的に、eNodeBは、ProSe関数からのそのようなリレー開始メッセージを受信したとき、その後、たとえば、eNodeBとの無線リンクが不良である無線セル内の遠隔UEの数、ならびに/または、無線セル内の公衆安全サービスを実行している遠隔UEの数に基づいて、実際にさらなるリレーが必要であるか否かを判定する。さらに説明すると、eNodeBは、独自のインターフェースを通じてもしくはMMEのような基幹ネットワーク要素を通じてeNBが受信することができるProSe関数からのフィードバックを含む可能性としての多くの要因に基づいて、または純粋に、たとえば、平方キロメートルあたり一定数のリレーが必要とされることを記述する、ネットワークからのOAM設定に基づいて、または純粋に、セル内でPSサービスを実行しているUEの数(eNBによってサービスされているCQIクラスのベアラから明らかになる)およびPSサービスを実行している一定数のUEあたり一般的に必要とされるリレーUEの数に関する何らかの統計的計算からのそれ自体の推定に基づいて、セル内で必要とされるリレーUEの数を決定することができ、あるいは、セル内で必要とされるリレーUEの数に関するeNodeB決定は、純粋に、UEの、リレーサービスに対するそれらの要件の報告に基づいてもよい。最後のもの、すなわち、UEの、リレーサービスに対するそれらの要件の報告は、カバレッジ内公衆安全UEが(Uuインターフェース上で)不良な無線品質を受けていること、および、eNodeBがカバレッジ外UEの可能な数を含めるためにこの数字を推定することに基づき得る。この判定は、eNodeBによって、リレー開始メッセージの受信後に定期的に実行され得る。
【0174】
ちょうど上記で説明したような、eNodeBによる、さらなるリレーが必要であるか否かに関するこの判定は、同様に、ProSe関数からのリレー開始メッセージ交換を含まない第1の実施形態の実施態様において、たとえば、
図13〜
図18に関連して説明した実施態様(およびそれらの対応する変形形態)において、実行されてもよい。その場合、eNodeBはまた、さらなるリレーが必要であるか否かを定期的に判定する。
【0175】
図19に関連して説明されているような第1の実施形態の実施態様のさらなる利点および拡張バージョンが、
図20に関連して説明される。
図20から明らかであるように、追加の、すなわち、リレー停止メッセージがProSe関数から受信されるか否かに関する決定が、リレー有効化手順に導入されている。リレー開始メッセージとは反対に、ProSe関数は(たとえば、加えて、ProSeアプリケーションサーバと協議して)、特定の無線セルがそれ以上いかなるリレーも提供すべきでないと決定することができ、したがって、これに応じて無線セル内でリレー停止メッセージを送信することができる。これに応じて、リレーUEがそのようなリレー停止メッセージを受信した場合、リレーUEは、eNodeBからのブロードキャストメッセージに対するモニタリングを停止する。
【0176】
第1の実施形態のさらなる有利な実施態様によれば、ブロードキャストメッセージは、リレーUEにおいてリレー有効化手順を実施するのに有用であるさらなる情報によって拡張される。前に説明したように、ブロードキャストメッセージは、持続性チェック値、および、リレーUEがリレー有効化手順を開始するためのトリガとしての機能を含むべきである。加えて、ブロードキャストメッセージは、無線セル内で満たされるべきであり、リレー有効化手順中にリレーユーザ機器によってチェックされるさらなるリレー要件を含むことができる。第1の実施形態の特定の実施態様において前述したように、eNodeBは、そのセルに対する特定のリレー要件を判定するためのエンティティであってもよく、したがって、これに応じて、その無線セル内で送信されるブロードキャストメッセージ内にリレー要件に関する情報を含めることが可能である。有利には、ブロードキャストメッセージ内にリレー要件に関するこの情報が存在することは、無線セル内でさらなるリレーが必要であることを黙示的に示していると考えることができ(すなわち、リレーユーザ機器においてリレー有効化手順を開始するためのトリガとして黙示的に考えることができ)、それによって、上記に関連して別個のインジケーションは必要ない。
【0177】
代替的に、または加えて、第1の実施形態のさらなる実施態様によれば、ブロードキャストメッセージは、リレーUEによって、そのリレー機能を有効化した後にリレーディスカバリ手順を実行するために使用することができる無線リソースに関する情報によって拡張されてもよい。たとえば、ブロードキャストメッセージ内でeNodeBによって与えられる無線リソースに関する情報は、そこからその後ユーザ機器が、たとえば、リレーディスカバリを実行するための無線リソースを自主的に選択することができる、前述したリレーディスカバリリソースプールと同じまたは同様であってもよい。他方、リレーディスカバリリソースプール情報がリレーUEにすでに(たとえば、システム情報を介して)与えられていると仮定すると、ブロードキャストメッセージ内でeNodeBによって与えられる無線リソースに関するこの情報は、リレーディスカバリリソースプール全体のうちの一部分のみを参照し得る。いずれにせよ、eNodeBによって送信されるブロードキャストメッセージ内ですでに対応する無線リソースを提供することによって、後に、たとえば、リレー有効化手順が、無線リソースがリレーディスカバリ手順にとってすでに利用可能であるか否かを判定するステップを含む第1の実施形態の実施態様のいくつかと関連して説明されているようなリレー有効化手順(たとえば、
図16および
図17参照)の間に無線リソースをさらに要求する必要がなくなる。有利には、ブロードキャストメッセージ内にそのような情報が存在することは、無線セル内でさらなるリレーが必要であることを黙示的に示していると考えることができ(すなわち、リレーユーザ機器においてリレー有効化手順を開始するためのトリガとして黙示的に考えることができ)、それによって、上記に関連して別個のインジケーションは必要ない。
【0178】
第1の実施形態のさらなる有利な実施態様は、リレーUEがリレーディスカバリメッセージを不要に送信し続け、それによって、その電池がさらに消耗し、対応するリレーディスカバリ無線リソースが混雑することがなくなるように、必要に応じてリレー機能を無効化する追加のメカニズムを提供する。これに応じて、この実施態様について、リレーUEがすでにそのリレー機能を有効化しており、他の遠隔UEに対するリレーとしての役割を果たしていてもよく、または果たしていなくてもよいことが仮定される。この実施態様によれば、eNodeBは、その無線セル内でもはやいかなるリレーも提供しないことを決定することができ、または、単純に、その無線セル内のリレーの数を低減することを決定することができる。いずれにせよ、この実施態様において、eNodeBがすべてのリレーUEまたは特定のリレーUEのみを無効化することを可能にするためのメカニズムが提供される。上記に関連して、eNodeBは、無線セル内でブロードキャストすることができるか、または、リレー機能が無効化されるべきである関連リレーUEに直接的に送信することができるかのいずれかである、対応するリレー無効化コマンドメッセージを使用することができる。より詳細には、eNodeBがその無線セル内ですべてのリレーを無効化したいと望む場合、eNodeBは、その無線セル内のすべてのリレーUEによって受信されるべき対応する無効化コマンドをブロードキャストすることを決定することができ、リレーUEの各々はこのコマンドに従い、リレー機能が有効化されているときは、リレー機能を無効化する。他方、eNodeBはまた、上記リレーUEのリレー機能を無効化するために、それぞれ1つのみのリレーとの専用シグナリングを使用してもよい。しかしながら、eNodeBは、専用シグナリングを使用することによって、アイドル状態にあるリレーUEに達することは可能でないことに留意されたい。この場合、eNodeBは代替的にまたは付加的に、特にアイドル状態にある、リレー機能が有効化されているリレーUEのみのリレー機能を無効化するためにブロードキャストシグナリングを使用してもよい。アイドル状態にあるリレーUEは、この特別なインジケーションを有するブロードキャストシグナリングを受信し、応答して、リレー機能(有効化されている場合)を無効化する。さらなる例として、ブロードキャストメッセージはさらに、前述したように、その有効化されているリレーセット全体の一部分のみを無効化するために、持続性チェックメカニズムを使用することができる。
【0179】
代替的に、リレー無効化はまた、たとえば、リレーUEが特定の期間にわたって任意のリレーUEがリレーとしての役割を果たすのを停止しているとき、または、ProSe関数がUEにリレーであることを停止するように通知する場合に、リレーUEによって開始されてもよい。この場合、リレーUEは、対応するリレー無効化要求メッセージをeNodeBに送信することができ、eNodeBはその後、実際にリレーUEがそのリレー機能を無効化すべきか否かを決定することができる。これに応じて、eNodeBは、対応する無効化コマンドを与えるかまたは与えない応答メッセージを、リレーUEに返信する。
【0180】
3GPP環境による特定の実施態様において、RRCConnectionReconfigurationメッセージを、リレー無効化コマンドとしての役割を果たすために再使用することができる。
【0181】
第2の実施形態
以下において、以下の問題に対処する第2の実施形態が提示される。特に、ProSeリレー機能に関する現在の標準化は、遠隔ユーザ機器がPC5インターフェースを介してデータの送信をいつ開始および停止するかを指定していない。言い換えれば、現在の3GPP標準化では、遠隔UEが、eNodeBとのダイレクトUuリンクを介する代わりに、リレー接続を介してデータの送信/受信をいつ開始すべきかに関して、具体的な合意に至っていない。遠隔UEがUuリンクにいつ戻って切り替わるべきかも不明確である。
【0182】
一般的に、遠隔UEは、PC5リンクではなくUuリンクを選好するはずであることに留意されたい。それゆえ、リレー動作は、Uuリンクが非常に微弱/維持不可能もしくは非効率であるときにのみ開始されるべきであり、かつ/または、遠隔UEが再び、eNodeBによってUuリンクを介して直接的にサービスされ得るようになったときには、停止されるべきである。これは、様々な測定報告、CSI報告などに基づく動的スケジュールが、Uuインターフェース上では可能であり、実行され、PC5リンクについてはそうでないためである。
【0183】
第2の実施形態を論じるために、遠隔UEは最終的に、1つまたは複数の可能な発見されている(たとえば、背景技術の節において説明されているようなリレーディスカバリを実行することによって発見されている)リレーUEの中から、リレーUEを選択すると仮定される。これに応じて、これはまた、それを介してその後通信を中継することができるリレーUEとの対応するダイレクト接続を確立することをも含む。特に、そのようなダイレクト接続は、背景技術の節において説明されているように、たとえば、リレーUEと遠隔UEとの間にレイヤ2リンクを確立することによって、確立することができる。
【0184】
ここで、実際の(PC5インターフェースへの)データ切り替えが、(リレーUEが遠隔UEによって選択され、リレーUEと遠隔UEとの間の対応するダイレクト接続が確立された後の)いずれの時点において行われるべきかを決定することが重要である。いくつかの選択肢がある。たとえば、遠隔UEは、そもそもPC5リンクを介したデータの送信/受信を開始すべきか否か、および、いつ開始すべきかを自主的に決定することができる。この自主的な決定は、Uuおよび/またはPC5リンク品質、各リンク上で必要とされる送信電力、ならびに、他の同様の考慮事項を含むいくつかの異なるオプションに基づくことができる。
【0185】
たとえば、遠隔UEは、遠隔UEと無線基地局との間の対応するUuリンク品質が特定の設定閾値を下回る場合に、PC5リンクを介してデータの送信を開始することができる。またさらなる代替形態として、遠隔UEは、リレーUEとのレイヤ2リンクの確立に成功した後、直ちにPC5リンクを介したデータの送信を開始するように設定することができる。
【0186】
いずれにせよ、遠隔UEは、eNodeBに、PC5に対する経路切り替えを通知することができ、それによって、eNodeBは、遠隔UEの通信がこの時点で、リレーUEを介して遠隔UEへと中継され続けるように、既存のデータベアラを解放および設定解除することが可能であり得る。
【0187】
代替的に、遠隔UEは、たとえば、未確認応答データパケット(たとえば、PDCP SDU)をリレーUEに送信することによって、前もってeNodeBに通知せずに、選択されるリレーUEとの通信リンクの使用を直接的に開始してもよい。これを受けて、リレーUEはその後、eNodeBに通知し、eNodeBは、ダウンリンク(PDCP)未確認応答データパケットを、選択されているリレーユーザ機器を介して遠隔UEに送信し始める。「いずれの」遠隔UEかの知識は、UEがPC5に移行する直前に使用されていたUuリンク上でUEに割り当てられていたC−RNTIを使用して、リレーを介してeNBに伝達することができる。
【0188】
一般的に、遠隔UE(およびリレーUE)によって実行される(UuからPC5への、および、PC5からUuへの)すべてのデータ切り替えは、アクセス層からアプリケーション層に通知されるべきである。これは、この場合のアプリケーション層、たとえば、近傍関数が、無線ネットワークレイアウト(たとえば、セルおよびトラッキングエリアID)をそれ自体のインフラストラクチャにマッピングする必要があり得るためである。
【0189】
UEの接続をPC5リンクから再びUuリンクへと首尾よく移行するためのさらなるソリューションが提供される。これに関連して、ここで、リレーUEが、遠隔UEに対するリレーとして動作しており、それによって、遠隔UEの通信がeNodeBと遠隔UEとの間でリレーUEを介して中継されると仮定される。1つのソリューションによれば、遠隔ユーザを再びUuリンクに移行するために、ハンドオーバのような手順が使用され得る。具体的には、遠隔UEは、通常の測定報告を、リレー接続を介してeNodeBに送信することができる。たとえば、以前、Uuリンクを介してeNodeBに接続されているときに受信されている古い測定設定を、PC5データ切り替え後に維持することができ、したがって、遠隔ユーザ機器がPC5リンク上にあるときであっても、Uuリンクの測定に使用することができる。対応するハンドオーバメッセージ(参照によって本明細書に組み込まれている非特許文献9のMobilityControlInfoを有するRRCConnectionReconfigurationメッセージなど)が、eNodeBによって、リレーUEを介して遠隔UEに送信され得る。この特定の場合において、再び切り替えられるべきUuリンクは、同じ古い(ソース)セルに属してもよく、または、任意の他の隣接セルに属してもよい。しかしながら、このソリューションには、UEおよびeNodeBがUuコンテキスト(設定を含む)を保持するという問題、および、より高い層のデータ(たとえば、アプリケーションデータ)を伝達するためにのみリンクが使用されることが想定されているために、PC5を介したRRCメッセージシグナリングが不利であり、これに関連して、Uuインターフェース上でRRC接続を維持することに関して同じ複雑度がサポートされる必要があり得るために、PC5上でのより低い層のシグナリング伝送が回避され得るという問題がある。
【0190】
他方、前述したように、遠隔UEは、Uuリンク品質が十分に良好になると、(PC5インターフェースリンクの代わりに)再びUuリンクの使用に切り替わることができる。上記の場合において、有利には、接続確立の原因として、遠隔UEがPC5インターフェースからUuインターフェースへの移行を所望していることを示す、RRC接続確立手順が遠隔UEによって実行され得る。3GPP規格環境における例示的な実施態様によれば、非特許文献9(5.3.3節、参照によって本明細書に組み込まれている)によるRRC接続確立手順を再使用することができる。
【0191】
Uuリンクがいつ再び良好になるかを遠隔UEによって適切に判定するために、遠隔UEは、たとえば、RSRPおよび/もしくはRSRQ、ならびに/または、経路損失情報等を含むもののような特定の無線リンク測定を実行することができる。再び切り替えるのに十分に良好であると判定されるためにUuリンクが満たさなければならない、対応する最小閾値が、それぞれの無線リンク測定の各々について規定され得る。たとえば、所定の閾値の各々が、eNodeBによって設定され得、遠隔UEがUuリンクを介してまだアクセス可能である間に(すなわち、PC5リンクへのデータ切り替えを実行する前に)、閾値に対応する情報が遠隔UEに与えられ得る。
【0192】
第2の実施形態の代替的な実施態様によれば、遠隔UEは、セル選択基準(非特許文献10において規定される)を使用してUuがいつ、上記Uuリンクへ戻るデータ切り替えを開始するのに十分に良好になるかを判定する。具体的には、参照によって本明細書に組み込まれている非特許文献10は、5.2節に記載されているセル選択手順のためにセルを評価するために使用されるセル選択基準を、5.2.3.2節において規定している。以下は、上記非特許文献10の5.2.3.2節の抜粋である。
【0193】
セル選択基準Sは、以下のときに満たされる。
Srxlev>0 かつ Squal>0
ここで、
Srxlev=Q
rxlevmeas−(Q
rxlevmin+Q
rxlevminoffset)−Pcompensation−Qoffset
temp
Squal=Q
qualmeas−(Q
qualmin+Q
qualminoffset)−Qoffset
temp
ここで、
【表5】
【0194】
シグナリングされる値Q
rxlevminoffsetおよびQ
qualminoffsetは通常通りVPLMN内にキャンプしている間に、より優先度の高いPLMNを求めて定期的に探索する結果として、セルがセル選択について評価されるときにのみ、適用される。このより優先度の高いPLMNを求める定期的探索の間、UEは、このより優先度の高いPLMNの異なるセルからの記憶されているパラメータ値を使用してセルのS基準をチェックすることができる。
【0195】
これに応じて、遠隔UEは、Uuリンクがいつこのリンクに再び切り替えるのに再び十分に良好になるかを判定するために、このセル選択基準を再使用することができる。
【0196】
さらなる改善によれば、新たなモニタリング挙動が、遠隔UEに提供される。具体的には、遠隔UEは、公衆安全アプリケーションのみを実行していると想定されるため、これらの公衆安全アプリケーションのためにリレーディスカバリに使用されるように特定的に規定される特定のディスカバリリソースプールをモニタリングすることのみを、選択的に必要とし得る。それゆえ、遠隔UEが他のディスカバリリソースプールをモニタリングする必要はなく、それによって、電池を節約することが可能である。
【0197】
さらなる実施形態
第1の態様によれば、移動体通信ネットワーク内でリレーユーザ機器のリレー機能を有効化するための方法が提供される。リレーユーザ機器は、それぞれ1つまたは複数の遠隔ユーザ機器とのダイレクトサイドリンク接続を介してダイレクト通信を実行することが可能である。リレーユーザ機器は、移動体通信ネットワーク内の無線基地局によって制御される無線セル内に位置し、ダイレクトサイドリンク接続を介して1つまたは複数の遠隔ユーザ機器と無線基地局との間の通信を中継するために、それぞれ1つまたは複数の遠隔ユーザ機器のためのリレーとしての役割を果たすことを可能にするためのリレー機能をサポートする。方法は、以下のステップを含む。無線基地局は、さらなるリレーが無線セル内に必要であるか否かを判定する。さらなるリレーが無線セル内に必要であると判定される場合、無線基地局は持続性チェック値を選択し、無線セル内でブロードキャストメッセージを送信する。ブロードキャストメッセージは少なくとも、さらなるリレーが無線セル内に必要であることを示し、選択されている持続性チェック値を含む。リレーユーザ機器は、ブロードキャストメッセージを受信し、その後、無線セル内でそのリレー機能を有効化するためのリレー要件がリレーユーザ機器によって満たされるとリレーユーザ機器が判定する場合、かつ、受信されている持続性チェック値に基づいてリレーユーザ機器によって実行される持続性チェックが成功する場合に、そのリレー機能を有効化する。
【0198】
第1の態様に加えて提供される第2の態様によれば、リレーユーザ機器によって持続性チェックを実施するステップは、リレーユーザ機器が、一定の値範囲内のランダム値を生成し、生成されているランダム値を、同じ値範囲内で無線基地局によって選択されている、受信されている持続性チェック値と比較して、持続性チェックが成功するか否かを判定することを含む。たとえば、生成されているランダム値が受信されている持続性チェック値以下である場合、持続性チェックは成功する。
【0199】
第1の態様または第2の態様に加えて提供される第3の態様によれば、方法は、ブロードキャストメッセージを受信した後で、リレー機能を有効化するステップの前に、さらなるステップを含むことができる。具体的には、リレーユーザ機器が、その存在をリレーとして告知するためのリレーディスカバリ手順を実行するために、無線リソースがすでに設定されているか否かを、リレーユーザ機器が判定する。リレーユーザ機器がリレーディスカバリ手順を実行するために無線リソースがすでに設定されているのではない場合、リレーユーザ機器は、無線基地局から、リレーディスカバリ手順を実行するための無線リソースを要求し、その後、無線リソースがリレーディスカバリ手順を実行するために割り当てられているか否か、および、いずれの無線リソースが割り当てられているかに関する情報を、基地局から受信する。
【0200】
第1の態様〜第3の態様のいずれかに加えて提供される第4の態様によれば、方法は、ブロードキャストメッセージを受信した後で、リレー機能を有効化するステップの前に、さらなるステップを含むことができる。具体的には、リレーユーザ機器が無線基地局に、無線基地局からリレーユーザ機器のリレー機能を有効化するための許可を要求するリレー有効化要求メッセージを送信する。リレーユーザ機器は、無線基地局から、リレーユーザ機器がリレー機能を有効化する許可を与えるかまたは拒絶する、リレー有効化応答メッセージを受信する。その後、リレー機能を有効化する許可を与えるリレー有効化応答メッセージが受信される場合、リレーユーザ機器によってそのリレー機能を有効化するステップが実行される。
【0201】
第3の態様〜第4の態様に加えて提供される第5の態様によれば、リレーユーザ機器によって実行される、無線基地局からリレーディスカバリ手順を実行するための無線リソースを要求するステップは、上記無線リソースを求める要求を、リレーユーザ機器によって、無線基地局からそのリレー機能を有効化するための許可を要求するために無線基地局に送信されるリレー有効化要求メッセージ内に含めることを含む。さらに、リレーユーザ機器によって実行される、無線リソースがリレーディスカバリ手順を実行するために割り当てられているか否か、および、いずれの無線リソースが割り当てられているかに関する情報を、基地局から受信するステップは、上記情報を、無線基地局によって、リレーユーザ機器がそのリレー機能を有効化するための許可を与えるかまたは拒絶するために送信されるリレー有効化応答メッセージ内に含めることを含む。たとえば、無線基地局は、リレーディスカバリ手順のために無線リソースをリレーユーザ機器に割り当てることによって、リレーユーザ機器がそのリレー機能を有効化するための許可を与え、無線基地局は、リレーディスカバリ手順のために無線リソースをリレーユーザ機器に割り当てないことによって、リレーユーザ機器がそのリレー機能を有効化するための許可を拒絶する。
【0202】
この第4の態様または第5の態様に加えて提供される第6の態様によれば、リレー有効化要求メッセージは、1)好ましくは無線基地局が1つまたは複数の提供されるサービスと関連付けられる優先度を決定することを可能にする、公衆安全サービスまたは非公衆安全サービスのような、リレーユーザ機器によって遠隔ユーザ機器に提供することができる1つもしくは複数のサービスに関する情報、2)リレーユーザ機器によって遠隔ユーザ機器に提供することができる1つもしくは複数のサービスのグループ識別情報であって、グループ識別情報は、1つもしくは複数の提供されるサービスの各々がいずれのグループに属するかに関する情報を与える、グループ識別情報、または、3)リレーユーザ機器が、無線セル内でディスカバリメッセージを送信することによってダイレクト通信ユーザ機器としてのその存在を告知するためのダイレクトディスカバリを実行するための無線リソースを求める要求をさらに含む。
【0203】
第1の態様〜第6の態様のいずれかに加えて提供される第7の態様によれば、方法は、ブロードキャストメッセージを受信した後で、リレー機能を有効化するステップの前に、以下のステップをさらに含む。リレーユーザ機器が、リレーユーザ機器がアイドル状態にあるか、または、接続状態にあるかを判定する。リレーユーザ機器がアイドル状態にある場合、リレーユーザ機器は、無線基地局からリレーディスカバリ手順を実行するためのリソースを要求することを可能にするために、および/または、無線基地局からリレーユーザ機器のリレー機能を有効化するための許可を要求するために、接続状態に遷移する。たとえば、リレーユーザ機器が接続状態に遷移するステップは、リレーユーザ機器によって、無線基地局との接続要求手順を実行することを含む。この接続要求手順は、リレーディスカバリ手順を実行するために無線リソースを要求する必要性、および/または、リレー機能を有効化するための許可を求める必要性を、確立要因として示すことができる。これに応じて、無線基地局は、確立要因に基づいて接続要求を拒絶するかまたは許可するかを判定する。確立要因は、無線基地局によって、接続要求手順の間に、接続要求手順のメッセージの無線リソース制御プロトコルヘッダから、または、接続要求手順のメッセージの媒体アクセス制御プロトコルヘッダから、または、接続要求手順の間にリレーユーザ機器によって送信されるランダムアクセスプリアンブルから判定することができる。
【0204】
第1の態様〜第7の態様のいずれかに加えて提供される第8の態様によれば、無線セル内で無線基地局によって送信されるブロードキャストメッセージは、無線セル内のリレーユーザ機器によって満たされるべきリレー要件に関する情報をさらに含む。たとえば、さらなるリレーが必要であるというインジケーションが、リレー要件に関する情報とは別個にブロードキャストメッセージ内に含まれ、または、リレーユーザ機器が、ブロードキャストメッセージ内にリレー要件に関する情報が存在することから、および/もしくは、ブロードキャストメッセージ内に持続性チェック値が存在することから、さらなるリレーが必要であると判定する。
【0205】
第1の態様〜第8の態様のいずれかに加えて提供される第9の態様によれば、無線セル内で無線基地局によって送信されるブロードキャストメッセージは、リレーユーザ機器のリレーとしての存在を告知するためのリレーディスカバリ手順のためにリレーユーザ機器によって使用されるべき無線リソースに関する情報をさらに含む。たとえば、さらなるリレーが必要であるというインジケーションが、リレーディスカバリ手順のための無線リソースに関する情報とは別個にブロードキャストメッセージ内に含まれ、または、リレーユーザ機器が、ブロードキャストメッセージ内にリレーディスカバリ手順のための無線リソースに関する情報が存在することから、および/もしくは、ブロードキャストメッセージ内に持続性チェック値が存在することから、さらなるリレーが必要であると判定する。
【0206】
第1の態様〜第9の態様のいずれかに加えて提供される第10の態様によれば、リレー要件は、1)リレーユーザ機器と無線基地局との間のリンクの無線リンク品質に対する最小および/または最大閾値であって、好ましくは、無線リンク品質は、基準信号受信電力RSRPおよび/または基準信号受信品質RSRQに基づいて決定される、最小および/または最大閾値、2)リレーユーザ機器の速度のような、リレーユーザ機器の移動レベルに対する最大閾値、ならびに、3)リレーユーザ機器の充電レベルに対する最小閾値のうちの少なくとも1つを含む。
【0207】
第1の態様〜第10の態様のいずれかに加えて提供される第11の態様によれば、リレー機能が有効化されると、リレーユーザ機器は、無線セル内でリレーディスカバリメッセージを送信することによって、無線セル内でリレーとしてのその存在を告知するためのリレーディスカバリ手順を実行する。リレーディスカバリメッセージの各々は、リレーユーザ機器のディスカバリを要求する、遠隔ユーザ機器からのリレー要請メッセージの受信後、または、定期的にのいずれかで送信される。たとえば、リレーユーザ機器は、第1の遠隔ユーザ機器が通信を中継するためのリレーとしての役割を果たすために選択され、リレーユーザ機器と第1の遠隔ユーザ機器との間に第1のダイレクトサイドリンク接続が、第1の遠隔ユーザ機器によって無線基地局と交換される通信が第1のダイレクトサイドリンク接続を介してリレーユーザ機器と第1の遠隔ユーザ機器との間で中継されるように、確立される。
【0208】
第1の態様〜第11の態様のいずれかに加えて提供される第12の態様によれば、リレーユーザ機器は、そのリレー機能を有効化されると仮定され、その場合、方法は、以下のステップをさらに含む。リレーユーザ機器が、無線基地局からリレー無効化コマンドを受信し、応答して、そのリレー機能を無効化する。代替的に、リレーユーザ機器が、無線基地局に、リレー無効化要求メッセージを送信し、その後、応答して、無線基地局から、リレーユーザ機器にそのリレー機能を無効化するか、または、しないよう指示するリレー無効化応答メッセージを受信する。これに応じて、リレーユーザ機器は、リレー無効化応答メッセージがリレー機能を無効化するよう指示する場合に、そのリレー機能を無効化する。
【0209】
第1の態様〜第12の態様のいずれかに加えて提供される第13の態様によれば、方法は、以下のステップを含む。リレーユーザ機器が、移動体通信ネットワーク内の近接サービス関数から、リレー開始メッセージを受信し、応答して、リレーユーザ機器による、無線基地局からブロードキャストメッセージの受信のためのモニタリングを開始する。たとえば、方法は、以下のステップをさらに含む。リレーユーザ機器が、近接サービス関数から、リレー停止メッセージを受信し、応答して、リレーユーザ機器による、無線基地局からのブロードキャストメッセージの受信のためのモニタリングを停止する。
【0210】
第1の態様〜第13の態様のいずれかに加えて提供される第14の態様によれば、無線基地局によって実施される、さらなるリレーが必要であるか否かを判定するステップは、移動体通信ネットワーク内の近接サービス関数からリレー開始メッセージが受信される場合に、さらなるリレーが必要であると判定する。代替的にまたは加えて、無線基地局によって実施される、さらなるリレーが必要であるか否かを判定するステップは、無線基地局との無線リンクが不良である無線セル内の遠隔ユーザ機器の数、ならびに/または、無線セル内の公衆安全サービスを実行している遠隔ユーザ機器の数に基づく。
【0211】
第15の態様によれば、リレー機能を有効化するための、移動体通信ネットワーク内のリレーユーザ機器が提供される。リレーユーザ機器は、それぞれ1つまたは複数の遠隔ユーザ機器とのダイレクトサイドリンク接続を介してダイレクト通信を実行することが可能である。リレーユーザ機器は、移動体通信ネットワーク内の無線基地局によって制御される無線セル内に位置し、ダイレクトサイドリンク接続を介して1つまたは複数の遠隔ユーザ機器と無線基地局との間の通信を中継するために、それぞれ1つまたは複数の遠隔ユーザ機器のためのリレーとしての役割を果たすことを可能にするためのリレー機能をサポートする。リレーユーザ機器の受信機が、無線基地局から、無線セル内にさらなるリレーが必要であることを示し、無線基地局によって選択されている持続性チェック値を含むブロードキャストメッセージを受信する。ブロードキャストメッセージを受信したとき、リレーユーザ機器のプロセッサが、無線セル内でそのリレー機能を有効化するためのリレー要件がリレーユーザ機器によって満たされるとリレーユーザ機器が判定する場合、かつ、受信されている持続性チェック値に基づいてリレーユーザ機器によって実行される持続性チェックが成功する場合に、リレーユーザ機器のリレー機能を有効化する。
【0212】
第15の態様に加えて提供される第16の態様によれば、プロセッサは、1)一定の値範囲内のランダム値を生成すること、2)生成されているランダム値を、同じ値範囲内で無線基地局によって選択されている、受信されている持続性チェック値と比較して、持続性チェックが成功するか否かを判定するように構成されている。たとえば、プロセッサは、生成されているランダム値が受信されている持続性チェック値以下である場合に、持続性チェックが成功すると判定する。
【0213】
第15の態様または第16の態様に加えて提供される第17の態様によれば、プロセッサは、受信機がブロードキャストメッセージを受信した後で、かつ、プロセッサがリレー機能を有効化する前に、リレーユーザ機器がリレーとしてのその存在を告知するためのリレーディスカバリ手順を実行するために無線リソースがすでに設定されているか否かを判定する。リレーユーザ機器がリレーディスカバリ手順を実行するために無線リソースがすでに設定されているのではないとプロセッサが判定する場合、プロセッサは、無線基地局から、リレーディスカバリ手順を実行するための無線リソースを要求し、受信機が、無線リソースがリレーディスカバリ手順を実行するために割り当てられているか否か、および、いずれの無線リソースが割り当てられているかに関する情報を、基地局から受信する。
【0214】
第15の態様〜第17の態様のいずれかに加えて提供される第18の態様によれば、受信機がブロードキャストメッセージを受信した後で、かつ、プロセッサがリレー機能を有効化する前に、リレーユーザ機器の送信機が、無線基地局に、無線基地局からリレーユーザ機器のリレー機能を有効化するための許可を要求するリレー有効化要求メッセージを送信する。受信機が、無線基地局から、リレーユーザ機器がリレー機能を有効化する許可を与えるかまたは拒絶する、リレー有効化応答メッセージを受信する。リレー機能を有効化する許可を与えるリレー有効化応答メッセージが受信される場合、プロセッサが、リレー機能を有効化する。
【0215】
第17の態様および第18の態様に加えて提供される第19の態様によれば、プロセッサが、無線リソースを求める要求を、送信機によって、無線基地局からそのリレー機能を有効化するための許可を要求するために無線基地局に送信されるべきリレー有効化要求メッセージ内に含めることによって、無線基地局からリレーディスカバリ手順を実行するための無線リソースを要求する。受信機が、無線リソースがリレーディスカバリ手順を実行するために割り当てられているか否か、および、いずれの無線リソースが割り当てられているかに関する情報を、無線基地局から受信することによって、リレーユーザ機器がそのリレー機能を有効化するための許可を与えるか、または、拒絶するために、無線基地局によって送信されるリレー有効化応答メッセージを受信する。
【0216】
第15の態様〜第19の態様のいずれかに加えて提供される第20の態様によれば、受信機がブロードキャストメッセージを受信し、プロセッサがリレー機能を有効化した後に、プロセッサは、リレーユーザ機器がアイドル状態にあるか、または、接続状態にあるかを判定する。リレーユーザ機器がアイドル状態にあるとプロセッサが判定する場合、プロセッサは、無線基地局からリレーディスカバリ手順を実行するためのリソースを要求することを可能にするために、および/または、無線基地局からリレーユーザ機器のリレー機能を有効化するための許可を要求するために、リレーユーザ機器を接続状態に遷移させる。
【0217】
第15の態様〜第20の態様のいずれかに加えて提供される第21の態様によれば、受信機が、無線セル内のリレーユーザ機器によって満たされるべきリレー要件に関する情報を含むブロードキャストメッセージを受信する。加えてまたは代替的に、受信機は、リレーユーザ機器によって、リレーユーザ機器のリレーとしての存在を告知するためのリレーディスカバリ手順のために使用されるべき無線リソースに関する情報を含むブロードキャストメッセージを受信する。
第15の態様〜第21の態様のいずれかに加えて提供される第22の態様によれば、プロセッサが、以下のリレー要件のうちの少なくとも1つが満たされるか否かを判定する。リレーユーザ機器と無線基地局との間のリンクの無線リンク品質に対する最小および/または最大閾値であって、好ましくは、無線リンク品質は、基準信号受信電力RSRPおよび/または基準信号受信品質RSRQに基づいて決定される、最小および/または最大閾値、リレーユーザ機器の速度のような、リレーユーザ機器の移動レベルに対する最大閾値、ならびに、リレーユーザ機器の充電レベルに対する最小閾値。
【0218】
第15の態様〜第22の態様のいずれかに加えて提供される第23の態様によれば、リレーユーザ機器がそのリレー機能を有効化しており、受信機が無線基地局から、リレー無効化コマンドを受信する。プロセッサが、リレー無効化コマンドに応答して、リレー機能を無効化する。たとえば、送信機が無線基地局に、リレーユーザ機器のリレー機能を無効化するよう、または、無効化しないよう無線基地局に要求するリレー無効化要求メッセージを送信する。
【0219】
第24の態様によれば、移動体通信ネットワーク内でのリレーユーザ機器のリレー機能の有効化に関与するための無線基地局を提供する。リレーユーザ機器は、それぞれ1つまたは複数の遠隔ユーザ機器とのダイレクトサイドリンク接続を介してダイレクト通信を実行することが可能である。リレーユーザ機器は、移動体通信ネットワーク内の無線基地局によって制御される無線セル内に位置し、ダイレクトサイドリンク接続を介して1つまたは複数の遠隔ユーザ機器と無線基地局との間の通信を中継するために、それぞれ1つまたは複数の遠隔ユーザ機器のためのリレーとしての役割を果たすことを可能にするためのリレー機能をサポートする。無線基地局のプロセッサが、さらなるリレーが無線セル内に必要であるか否かを判定する。プロセッサは、一定の値範囲内で持続性チェック値を選択する。送信機が、無線セル内の1つまたは複数の遠隔ユーザ機器に、リレー機能を有効化する前に満たされるべきリレー要件を送信する。送信機は、さらなるリレーが必要であるとプロセッサが判定する場合に、無線セル内でブロードキャストメッセージを送信する。ブロードキャストメッセージは少なくとも、さらなるリレーが無線セル内に必要であることを示し、選択されている持続性チェック値を含む。ブロードキャストメッセージは、リレーユーザ機器が持続性チェック値に基づく持続性チェックの実行に成功した場合、かつ、リレーユーザ機器がリレー要件を満たす場合に、無線セル内の1つまたは複数のリレーユーザ機器に対して、リレー機能を有効化するように示す。
【0220】
第24の態様に加えて提供される第25の態様によれば、受信機が移動体通信ネットワーク内の近接サービス関数からリレー開始メッセージを受信する場合に、プロセッサは、さらなるリレーが必要であると判定する。付加的にまたは代替的に、無線基地局との無線リンクが不良である無線セル内の遠隔ユーザ機器の数、ならびに/または、無線セル内の公衆安全サービスを実行している遠隔ユーザ機器の数に基づいて、プロセッサは、さらなるリレーが必要であると判定する。
【0221】
本開示のハードウェアおよびソフトウェア実装
他の例示的な実施形態は、ハードウェア、ソフトウェア、または、ハードウェアと協働するソフトウェアを使用した、上述した様々な実施形態の実装に関する。これに関連して、ユーザ端末(移動端末)およびeNodeB(基地局)が提供される。ユーザ端末および基地局は、本明細書において記載されている方法を実行するように適合されており、これは、受信機、送信機、プロセッサのような、方法に適切に関与する対応するエンティティを含む。
【0222】
様々な実施形態は、コンピューティングデバイス(プロセッサ)を使用して実施または実行され得るものとさらに認識される。コンピューティングデバイスまたはプロセッサは、たとえば、汎用プロセッサ、DSP(デジタル信号プロセッサ)、ASIC(特定用途向け集積回路)、FPGA(フィールドプログラマブルゲートアレイ)、または、その他プログラマブルロジックデバイスなどであってもよい。様々な実施形態は、これらのデバイスの組合せによっても実行または具体化することができる。特に、上述した各実施形態の記述において使用されている各機能ブロックは、LSIによって集積回路として実現することができる。それらは、チップとして個々に形成されてもよく、または、1つのチップが、それら機能ブロックの一部分またはすべてを含むように形成されてもよい。それらは、それらに結合されているデータ入力および出力を含むことができる。本明細書において、LSIは、集積度の差に応じて、IC、システムLSI、スーパーLSI、またはウルトラLSIとして参照されてもよい。しかしながら、集積回路を実装する技法は、LSIに限定されず、専用回路または汎用プロセッサを使用することによって実現されてもよい。加えて、LSIの製造後にプログラムすることができるFPGA(フィールドプログラマブルゲートアレイ)、または、LSIの内部に配置される回路セルの接続および設定を再構成することができる再構成可能プロセッサが使用されてもよい。
【0223】
さらに、様々な実施形態は、プロセッサによって、または、直接的にハードウェアにおいて実行されるソフトウェアモジュールによって実施することもできる。また、ソフトウェアモジュールとハードウェア実装の組合せも可能であり得る。ソフトウェアモジュールは、任意の種類のコンピュータ可読記憶媒体、たとえば、RAM、EPROM、EEPROM、フラッシュメモリ、レジスタ、ハードディスク、CD−ROM、DVDなどに記憶することができる。さらには、複数の異なる実施形態の個々の特徴は、個々に、または任意の組合せにおいて、別の実施形態の主題とすることができることにさらに留意されたい。
【0224】
具体的な実施形態において示した本開示には、多数の様々な変更および/または修正を行うことができることが、当業者には理解されるであろう。したがって、本発明の実施形態は、あらゆる点において例示的であり、本発明を制限するものではないものと考えられる。