JP2018533235A - ＰｒｏＳｅリレーのための改善されたベアラマッピング - Google Patents

ＰｒｏＳｅリレーのための改善されたベアラマッピング Download PDF

Info

Publication number
JP2018533235A
JP2018533235A JP2018500752A JP2018500752A JP2018533235A JP 2018533235 A JP2018533235 A JP 2018533235A JP 2018500752 A JP2018500752 A JP 2018500752A JP 2018500752 A JP2018500752 A JP 2018500752A JP 2018533235 A JP2018533235 A JP 2018533235A
Authority
JP
Japan
Prior art keywords
user equipment
relay
priority
bearer
side link
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2018500752A
Other languages
English (en)
Other versions
JP6849651B2 (ja
Inventor
ヨアキム ローア
ヨアキム ローア
マリック プラティーク バス
マリック プラティーク バス
貴子 堀
貴子 堀
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Panasonic Intellectual Property Corp of America
Original Assignee
Panasonic Intellectual Property Corp of America
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Panasonic Intellectual Property Corp of America filed Critical Panasonic Intellectual Property Corp of America
Publication of JP2018533235A publication Critical patent/JP2018533235A/ja
Application granted granted Critical
Publication of JP6849651B2 publication Critical patent/JP6849651B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W40/00—Communication routing or communication path finding
    • H04W40/02—Communication route or path selection, e.g. power-based or shortest path routing
    • H04W40/22—Communication route or path selection, e.g. power-based or shortest path routing using selective relaying for reaching a BTS [Base Transceiver Station] or an access point
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04B—TRANSMISSION
    • H04B7/00—Radio transmission systems, i.e. using radiation field
    • H04B7/24—Radio transmission systems, i.e. using radiation field for communication between two or more posts
    • H04B7/26—Radio transmission systems, i.e. using radiation field for communication between two or more posts at least one of which is mobile
    • H04B7/2603—Arrangements for wireless physical layer control
    • H04B7/2606—Arrangements for base station coverage control, e.g. by using relays in tunnels
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/50—Allocation or scheduling criteria for wireless resources
    • H04W72/56—Allocation or scheduling criteria for wireless resources based on priority criteria
    • H04W72/566—Allocation or scheduling criteria for wireless resources based on priority criteria of the information or information source or recipient
    • H04W72/569—Allocation or scheduling criteria for wireless resources based on priority criteria of the information or information source or recipient of the traffic information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/20—Manipulation of established connections
    • H04W76/23—Manipulation of direct-mode connections
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/02—Terminal devices
    • H04W88/04—Terminal devices adapted for relaying to or from another terminal or user

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

本開示は、リモートＵＥと無線基地局との間でプロトコルデータユニットを中継するためのリレーＵＥに関する。制御パケットが、リレーＵＥによって第１のサイドリンクベアラを介してリモートＵＥから受信され、これは第１のサイドリンクベアラを介してリモートユーザ機器によって送信されるプロトコルデータユニットと関連づけられる優先度指標を含む。リレーＵＥは、優先度指標とリレーＵＥによってプロトコルデータパケットを中継するために使用される無線ベアラとの間の関連を記憶する。リレーＵＥは、第１の無線ベアラを介して基地局から受信されたプロトコルデータユニットがリモートＵＥに送信されるべきである優先度を、記憶した関連に基づいて決定し、そして決定した優先度に対応する第２のサイドリンクベアラを使用してリモートユーザ機器に受信したプロトコルデータユニットを中継する。

Description

本開示は、リレーユーザ機器とリモートユーザ機器との間でプロトコルデータユニットを中継するための方法に関する。本開示は、本明細書に記載される方法に関与するためのリレーユーザ機器およびリモートユーザ機器も提供している。
＜ロングタームエボリューション（ＬＴＥ：Long Term Evolution）＞
ＷＣＤＭＡ（登録商標）無線アクセス技術に基づく第３世代移動システム（３Ｇ）が世界中至る所で広範に展開されている。この技術を強化または進化させる際の第１段階は、ＨＳＤＰＡ（High-Speed Downlink Packet Access）およびＨＳＵＰＡ（High Speed Uplink Packet Access）とも称される拡張アップリンクを導入し、競争力の高い無線アクセス技術を提供する。
さらに増加するユーザ需要に備え、かつ新たな無線アクセス技術に対して競争力を備えるよう、３ＧＰＰは、ＬＴＥと呼ばれる新たな移動通信システムを導入した。ＬＴＥは、次の１０年間、高速データおよびメディア転送の他に大容量音声サポートの通信事業者要求を満たすように設計されている。高ビットレートを提供できる能力がＬＴＥにとっての主要な方策である。
Ｅｖｏｌｖｅｄ ＵＴＲＡ（UMTS Terrestrial Radio Access）およびＵＴＲＡＮ（UMTS Terrestrial Radio Access Network）と呼ばれるＬＴＥに関する作業項目（ＷＩ：work item）仕様がＲｅｌｅａｓｅ８（ＬＴＥ Ｒｅｌ．８）として完成されている。ＬＴＥシステムは、低遅延および低コストでフルＩＰベースの機能性を提供する効率的なパケットベースの無線アクセスおよび無線アクセスネットワークを表している。ＬＴＥでは、所与のスペクトルを用いて柔軟なシステム展開を達成するために、１．４、３．０、５．０、１０．０、１５．０および２０．０ＭＨｚなどのスケーラブルな複数の送信帯域幅が設定される。ダウンリンクでは、直交周波数分割多重（ＯＦＤＭ：Orthogonal Frequency Division Multiplexing）ベースの無線アクセスが、低シンボルレートによるマルチパス干渉（ＭＰＩ）に対するその固有の耐性、サイクリックプレフィックス（ＣＰ：Cyclic Prefix）の使用、および異なる送信帯域幅の配置に対するその親和性のために採用された。ユーザ機器（ＵＥ：User Equipment）の制限される送信電力を考慮すると、ピークデータレートの向上よりも広域カバレッジを備えることが優先されるため、アップリンクではシングルキャリア周波数分割多元接続（ＳＣ−ＦＤＭＡ：Single-Carrier Frequency Division Multiple Access）ベースの無線アクセスが採用された。ＬＴＥ Ｒｅｌ．８／９では、多くの主要なパケット無線アクセス技法が、ＭＩＭＯ（Multiple Input Multiple Output）チャネル送信技術を含めて利用され、高効率の制御シグナリング構造が達成される。
＜ＬＴＥアーキテクチャ＞
全体的なＬＴＥアーキテクチャを図１に示す。Ｅ−ＵＴＲＡＮはｅＮｏｄｅＢから構成され、ユーザ機器（ＵＥ）に向けたＥ−ＵＴＲＡユーザプレーン（ＰＤＣＰ／ＲＬＣ／ＭＡＣ／ＰＨＹ）プロトコルの終端および制御プレーン（ＲＲＣ）プロトコルの終端を提供する。ｅＮｏｄｅＢ（ｅＮＢ）は、物理（ＰＨＹ）、メディアアクセス制御（ＭＡＣ）、無線リンク制御（ＲＬＣ）および、ユーザプレーンヘッダ圧縮および暗号化の機能を含むパケットデータ制御プロトコル（ＰＤＣＰ）レイヤをホストする。ｅＮｏｄｅＢは、制御プレーンに対応する無線リソース制御（ＲＲＣ：Radio Resource Control）機能も提供する。ｅＮｏｄｅＢは、無線リソース管理、アドミッションコントロール、スケジューリング、ネゴシエートされたアップリンクサービス品質（ＱｏＳ：Quality of Service）の実施、セル情報ブロードキャスト、ユーザおよび制御プレーンデータの暗号化／解読、ならびにダウンリンク／アップリンクユーザプレーンパケットヘッダの圧縮／解凍を含む多くの機能を行う。ｅＮｏｄｅＢは、Ｘ２インタフェースを用いて相互接続される。
ｅＮｏｄｅＢはまた、Ｓ１インタフェースを用いてＥＰＣ（Evolved Packet Core）に、より詳細には、Ｓ１−ＭＭＥを用いてＭＭＥ（Mobility Management Entity）に接続され、Ｓ１−Ｕを用いてサービングゲートウェイ（ＳＧＷ：Serving Gateway）に接続される。Ｓ１インタフェースは、ＭＭＥ／サービングゲートウェイとｅＮｏｄｅＢとの間の多対多の関係をサポートする。ＳＧＷは、ユーザデータパケットをルーティングおよび転送する一方で、ｅＮｏｄｅＢ間でのハンドオーバ中にユーザプレーンのためのモビリティアンカとして、および、（Ｓ４インタフェースを終端し、２Ｇ／３ＧシステムとＰＤＮ ＧＷとの間のトラヒックを中継する）ＬＴＥと他の３ＧＰＰ技術との間のモビリティのためのアンカとして機能する。アイドル（Idle）状態のユーザ機器に対しては、ＳＧＷはダウンリンクデータを終端し、ユーザ機器に対してダウンリンクデータが到着するとページングをトリガする。ＳＧＷはユーザ機器コンテキスト、例えば、ＩＰベアラサービスのパラメータ、またはネットワーク内部ルーティング情報を管理および記憶する。ＳＧＷは、合法的傍受の場合にはユーザトラヒックの複製も行う。
ＭＭＥは、ＬＴＥアクセスネットワークにとって主要な制御ノードである。ＭＭＥは、再送を含むアイドルモードのユーザ機器のトラッキングおよびページングプロシージャに対する役割を担う。ＭＭＥはベアラアクティブ化／非アクティブ化プロセスに関与し、かつ初期アタッチ時およびコアネットワーク（ＣＮ：Core Network）ノード再配置を伴うＬＴＥ内ハンドオーバ時にユーザ機器に対するＳＧＷを選択する役割も担う。ＭＭＥは、（ＨＳＳと対話することによって）ユーザを認証する役割を担う。非アクセス層（ＮＡＳ：Non-Access Stratum）シグナリングはＭＭＥで終端し、ＭＭＥは一時的な識別子の生成およびユーザ機器への割当ての役割も担う。ＭＭＥは、サービスプロバイダのＰＬＭＮ（Public Land Mobile Network）にキャンプするためにユーザ機器の認証を確認し、ユーザ機器のローミング制限を実施する。ＭＭＥは、ＮＡＳシグナリングに対する暗号化／整合性保護のためのネットワークにおける終端点であり、セキュリティキー管理を扱う。シグナリングの合法的傍受もＭＭＥによってサポートされる。ＭＭＥは、Ｓ３インタフェースがＳＧＳＮからＭＭＥで終端して、ＬＴＥおよび２Ｇ／３Ｇアクセスネットワーク間のモビリティのための制御プレーン機能も提供する。ＭＭＥは、ローミングユーザ機器に対してホームＨＳＳに向けたＳ６ａインタフェースも終端する。
＜ＬＴＥにおけるコンポーネントキャリア構造＞
３ＧＰＰ ＬＴＥシステムのダウンリンクコンポーネントキャリアは、時間−周波数領域で、いわゆるサブフレームに分割される。３ＧＰＰ ＬＴＥでは、図２に図示するように、各サブフレームは２つのダウンリンクスロットに分割され、ここでは第１のダウンリンクスロットは第１のＯＦＤＭシンボル内に制御チャネル領域（ＰＤＣＣＨ領域）を備える。各サブフレームは時間領域で所与の数のＯＦＤＭシンボル（３ＧＰＰ ＬＴＥ（Ｒｅｌｅａｓｅ８）では１２または１４個のＯＦＤＭシンボル）から成り、ここでは各ＯＦＤＭシンボルはコンポーネントキャリアの帯域幅全体に渡る。ＯＦＤＭシンボルは、したがって各々、それぞれのサブキャリアで送信されるいくつかの変調シンボルから成る。ＬＴＥでは、各スロットでの送信信号は、ＮＤＬ ＲＢ×ＮＲＢ ＳＣ個のサブキャリアとＮＤＬ ｓｙｍｂ個のＯＦＤＭシンボルのリソースグリッドによって描写される。ＮＤＬ ＲＢは帯域幅内のリソースブロックの数である。量ＮＤＬ ＲＢはセルに構成されるダウンリンク送信帯域幅に依存し、
Ｎｍｉｎ，ＤＬ ＲＢ≦ＮＤＬ ＲＢ≦Ｎｍａｘ，ＤＬ ＲＢ
を満たすものとし、式中、Ｎｍｉｎ，ＤＬ ＲＢ＝６およびＮｍａｘ，ＤＬ ＲＢ＝１１０はそれぞれ、仕様の現行バージョンによってサポートされる最小および最大ダウンリンク帯域幅である。ＮＲＢ ＳＣは１つのリソースブロック内のサブキャリアの数である。通常サイクリックプレフィックスサブフレーム構造の場合、ＮＲＢ ＳＣ＝１２およびＮＤＬ ｓｙｍｂ＝７である。
例えば、３ＧＰＰ ＬＴＥに使用されるような、ＯＦＤＭを利用するマルチキャリア通信システムを前提とすると、スケジューラによって割り当てられることができるリソースの最小単位は１つの「リソースブロック」である。物理リソースブロック（ＰＲＢ：Physical Resource Block）は、時間領域では連続するＯＦＤＭシンボル（例えば７つのＯＦＤＭシンボル）、および、周波数領域では図２に例示するように連続するサブキャリア（例えばコンポーネントキャリアにとして１２個のサブキャリア）として定義される。３ＧＰＰ ＬＴＥ（Ｒｅｌｅａｓｅ８）では、物理リソースブロックはリソースエレメントから成り、時間領域では１つのスロットに、また周波数領域では１８０ｋＨｚに対応する（ダウンリンクリソースグリッドに関するさらなる詳細については、例えばｈｔｔｐ：／／ｗｗｗ．３ｇｐｐ．ｏｒｇで入手可能であり、かつ参照により本明細書に援用される非特許文献１の６．２節を参照のこと）。
１つのサブフレームは２つのスロットから成り、その結果、いわゆる「通常（normal）」ＣＰ（サイクリックプレフィックス）が使用されるときにはサブフレームに１４個のＯＦＤＭシンボルがあり、いわゆる「拡張（extended）」ＣＰが使用されるときにはサブフレームに１２個のＯＦＤＭシンボルがある。専門用語のために、以下では、サブフレーム全体に渡る同じ連続するサブキャリアに相当する時間−周波数リソースを、「リソースブロックペア」または同意義の「ＲＢペア」もしくは「ＰＲＢペア」と呼ぶ。
「コンポーネントキャリア」という用語は、周波数領域でのいくつかのリソースブロックの組合せを指す。ＬＴＥの将来のリリースでは、「コンポーネントキャリア」という用語はもはや使用されず、代わりに専門用語は、ダウンリンクおよび任意選択でアップリンクリソースの組合せを指す「セル」に変更される。ダウンリンクリソースのキャリア周波数とアップリンクリソースのキャリア周波数との間の関連づけ（リンキング）は、ダウンリンクリソースで送信されるシステム情報に示される。
コンポーネントキャリア構造に対する同様の前提が、後のリリースにも当てはまることになる。
＜より広帯域幅のサポートのためのＬＴＥ−Ａでのキャリアアグリゲーション＞
ＩＭＴ−Ａｄｖａｎｃｅｄのための周波数スペクトルがＷＲＣ−０７（World Radio communication Conference 2007）で決定された。ＩＭＴ−Ａｄｖａｎｃｅｄのための全周波数スペクトルが決定されたとは言え、実際に利用可能な周波数帯域幅は各地域または国によって異なる。しかしながら、利用可能な周波数スペクトル概要に関する決定に続いて、無線インタフェースの標準化が第３世代パートナーシッププロジェクト（３ＧＰＰ：3rd Generation Partnership Project）で始まった。３ＧＰＰ ＴＳＧ ＲＡＮ＃３９会合で、「Ｅ−ＵＴＲＡに対するさらなる向上（ＬＴＥ−Ａｄｖａｎｃｅｄ）」に関する検討項目明細が承認された。その検討項目は、Ｅ−ＵＴＲＡの進化が、例えばＩＭＴ−Ａｄｖａｎｃｅｄに関する要件を満たすために考慮すべき技術要素を包含する。
ＬＴＥ−Ａｄｖａｎｃｅｄシステムがサポートすることができる帯域幅が１００ＭＨｚである一方で、ＬＴＥシステムは２０ＭＨｚしかサポートすることができない。最近では、電波スペクトルの不足がワイヤレスネットワークの発展のボトルネックになっており、結果として、ＬＴＥ−Ａｄｖａｎｃｅｄシステムのために十分に広いスペクトル帯を見つけることは困難である。結果的に、より広い電波スペクトル帯を得る方途を見つけることが急務であり、ここで考え得る解答がキャリアアグリゲーション機能である。
キャリアアグリゲーションでは、１００ＭＨｚまでのより広い送信帯域幅をサポートするために、２つ以上のコンポーネントキャリアがアグリゲートされる。ＬＴＥシステムでのいくつかのセルがアグリゲートされて、たとえＬＴＥでのこれらのセルが異なる周波数帯にあるとしても、１００ＭＨｚに対して十分に広いＬＴＥ−Ａｄｖａｎｃｅｄシステムでの１つのより広いチャネルになる。
すべてのコンポーネントキャリアは、少なくともコンポーネントキャリアの帯域幅がＬＴＥ Ｒｅｌ．８／９セルのサポートされる帯域幅を超えない場合、ＬＴＥ Ｒｅｌ．８／９互換性があるように構成されることができる。ユーザ機器によってアグリゲートされるすべてのコンポーネントキャリアが必ずしもＲｅｌ．８／９互換性があるわけではなくてもよい。現存のメカニズム（例えば禁止（ｂａｒｒｉｎｇ））を使用して、Ｒｅｌ−８／９ユーザ機器がコンポーネントキャリアにキャンプすることを回避してもよい。
ユーザ機器は、その能力に応じて１つまたは複数のコンポーネントキャリア（複数のサービングセルに対応する）を同時に受信または送信してもよい。キャリアアグリゲーションのための受信および／または送信能力を持つＬＴＥ−Ａ Ｒｅｌ．１０ユーザ機器は、複数のサービングセルで同時に受信および／または送信することができる一方で、ＬＴＥ Ｒｅｌ．８／９ユーザ機器は、コンポーネントキャリアの構造がＲｅｌ．８／９仕様に従うとの条件で、単一のサービングセルのみで受信および送信することができる。
キャリアアグリゲーションは連続および非連続コンポーネントキャリア両方に対してサポートされるが、各コンポーネントキャリアは（３ＧＰＰ ＬＴＥ（Ｒｅｌｅａｓｅ８／９）のニューメロロジー（numerology）を用いて）周波数領域で最大で１１０個のリソースブロックに制限される。
３ＧＰＰ ＬＴＥ−Ａ（Ｒｅｌｅａｓｅ１０）互換のユーザ機器を、同じｅＮｏｄｅＢ（基地局）から発信し、かつ場合によりアップリンクおよびダウンリンクで異なる帯域幅の異なる数のコンポーネントキャリアをアグリゲートするように構成することが可能である。構成することができるダウンリンクコンポーネントキャリアの数はＵＥのダウンリンクアグリゲーション能力に依存する。反対に、構成することができるアップリンクコンポーネントキャリアの数はＵＥのアップリンクアグリゲーション能力に依存する。移動端末をダウンリンクコンポーネントキャリアよりアップリンクコンポーネントキャリアが多くなるように構成することは、現在、可能でなくてもよい。典型的なＴＤＤ展開では、アップリンクおよびダウンリンクでのコンポーネントキャリアの数および各コンポーネントキャリアの帯域幅は同じである。同じｅＮｏｄｅＢから発信するコンポーネントキャリアが同じカバレッジを提供する必要はない。
連続してアグリゲートされるコンポーネントキャリアの中心周波数間の間隔は３００ｋＨｚの倍数であるものとする。これは、３ＧＰＰ ＬＴＥ（Ｒｅｌｅａｓｅ８／９）の１００ｋＨｚ周波数ラスタ（raster）と互換性があり、かつ同時に１５ｋＨｚ間隔を持つサブキャリアの直交性を保持するためである。アグリゲーションシナリオに応じて、ｎ×３００ｋＨｚ間隔は、連続したコンポーネントキャリア間への少数の未使用サブキャリアの挿入によって容易にされることができる。
複数のキャリアのアグリゲーションの性質は、ＭＡＣレイヤまでしか明らかにされていない。アップリンクおよびダウンリンク両方に関して、各アグリゲートされるコンポーネントキャリアごとにＭＡＣで１つのＨＡＲＱエンティティが必要とされる。（アップリンクに対するＳＵ−ＭＩＭＯの不在下では）コンポーネントキャリア当たり多くとも１つのトランスポートブロックがある。トランスポートブロックおよびその潜在的なＨＡＲＱ再送信は同じコンポーネントキャリアにマッピングされる必要がある。
キャリアアグリゲーションが構成されるとき、移動端末は、ネットワークとは１つのＲＲＣ接続しか有しない。ＲＲＣ接続確立／再確立時に、１つのセルが、ＬＴＥ Ｒｅｌ．８／９と同様に、セキュリティ入力（１つのＥＣＧＩ、１つのＰＣＩおよび１つのＡＲＦＣＮ）ならびに非アクセス層モビリティ情報（例えばＴＡＩ）を提供する。ＲＲＣ接続確立／再確立後に、そのセルに対応するコンポーネントキャリアはダウンリンクプライマリセル（ＰＣｅｌｌ：Primary Cell）と称される。接続状態のユーザ機器当たり常に１つであり、１つだけのダウンリンクＰＣｅｌｌ（ＤＬ ＰＣｅｌｌ）および１つのアップリンクＰＣｅｌｌ（ＵＬ ＰＣｅｌｌ）が構成される。構成された一組のコンポーネントキャリア内で、他のセルはセカンダリセル（ＳＣｅｌｌ：Secondary Cell）と称され、ＳＣｅｌｌのキャリアはＤＬ ＳＣＣ（Downlink Secondary Component Carrier）およびＵＬ ＳＣＣ（Uplink Secondary Component Carrier）である。ＰＣｅｌｌを含めて最大５つのサービングセルが１つのＵＥに対して構成されることができる。
ダウンリンクおよびアップリンクＰＣｅｌｌの特性は：
１．各ＳＣｅｌｌごとに、ダウンリンクリソースに加えてＵＥによるアップリンクリソースの使用が構成可能である（構成されるＤＬ ＳＣＣの数は、したがって常にＵＬ ＳＣＣの数以上であり、そしてどのＳＣｅｌｌも、アップリンクリソースのみの使用のために構成することはできない）
２．ダウンリンクＰＣｅｌｌは、ＳＣｅｌｌとは異なり、非アクティブ化することはできない
３．ダウンリンクＳＣｅｌｌがレイリーフェージング（ＲＬＦ）を経験するときではなく、ダウンリンクＰＣｅｌｌがＲＬＦを経験するときに、再確立がトリガされる
４．非アクセス層情報がダウンリンクＰＣｅｌｌから取得される
５．ＰＣｅｌｌは、ハンドオーバ手順につれて（すなわちセキュリティキー変更およびＲＡＣＨ手順につれて）のみ変更することができる
６．ＰＣｅｌｌは、ＰＵＣＣＨの送信のために使用される
７．アップリンクＰＣｅｌｌは、レイヤ１アップリンク制御情報の送信のために使用される
８．ＵＥ観点から、各アップリンクリソースは、１つのサービングセルにのみ帰属する
コンポーネントキャリアの構成および再構成の他に、追加および削除はＲＲＣによって行われることができる。アクティブ化および非アクティブ化は、ＭＡＣ制御要素を介して行われる。ＬＴＥ内ハンドオーバ時に、ＲＲＣは、ターゲットセルでの使用のためにＳＣｅｌｌを追加、削除または再構成することもできる。新たなＳＣｅｌｌを追加するとき、ＳＣｅｌｌのシステム情報を送るために個別ＲＲＣシグナリングが使用されるが、情報は（Ｒｅｌ−８／９でのハンドオーバのためと同様に）送受信のために必要である。各ＳＣｅｌｌには、ＳＣｅｌｌが１つのＵＥに追加されるときにサービングセルインデックスが設定されるが、ＰＣｅｌｌは常にサービングセルインデックス０を有する。
ユーザ機器にキャリアアグリゲーションが構成されると、少なくとも一対のアップリンクおよびダウンリンクコンポーネントキャリアが常にアクティブである。その対のダウンリンクコンポーネントキャリアは「ＤＬアンカキャリア」とも称されることがある。同じことがアップリンクに関しても当てはまる。
キャリアアグリゲーションが構成されると、ユーザ機器は、複数のコンポーネントキャリアに同時にスケジュールされてもよいが、多くとも１つのランダムアクセス手順がいかなる時にも進行中であるものとする。クロスキャリアスケジューリングは、コンポーネントキャリアのＰＤＣＣＨが別のコンポーネントキャリア上のリソースをスケジュールするのを許容する。この目的で、コンポーネントキャリア識別フィールドがそれぞれのＤＣＩ（Downlink Control Information）フォーマットに導入され、ＣＩＦと呼ばれている。
アップリンクおよびダウンリンクコンポーネントキャリア間の、ＲＲＣシグナリングによって確立される関連づけは、クロスキャリアスケジューリングがないときに、グラントが適用されるアップリンクコンポーネントキャリアを特定することを許容する。アップリンクコンポーネントキャリアへのダウンリンクコンポーネントキャリアの関連づけは、必ずしも１対１である必要はない。言い換えると、２つ以上のダウンリンクコンポーネントキャリアが、同じアップリンクコンポーネントキャリアに関連することができる。同時に、ダウンリンクコンポーネントキャリアは、１つのアップリンクコンポーネントキャリアにしか関連することができない。
＜レイヤ２−ＭＡＣレイヤ／エンティティ、ＲＲＣレイヤ＞
ＬＴＥレイヤ２ユーザプレーン／制御プレーンプロトコルスタックは、４つのサブレイヤ（ＲＲＣ、ＰＤＣＰ、ＲＬＣおよびＭＡＣ）を備える。ＭＡＣ（Medium Access Control）レイヤはＬＴＥ無線プロトコルスタックのレイヤ２アーキテクチャにおける最下位サブレイヤであり、例えば非特許文献２によって規定される。下位の物理レイヤへの接続はトランスポートチャネルを通じてであり、上位のＲＬＣレイヤへの接続は論理チャネルを通じてである。ＭＡＣレイヤはしたがって、論理チャネルとトランスポートチャネルとの間の多重化および逆多重化を行い、送信側のＭＡＣレイヤは、論理チャネルを通じて受け取られるＭＡＣ ＳＤＵから、トランスポートブロックとして知られるＭＡＣ ＰＤＵを構築し、受信側のＭＡＣレイヤは、トランスポートチャネルを通じて受け取られるＭＡＣ ＰＤＵからＭＡＣ ＳＤＵを復元する。
ＭＡＣレイヤは、制御データ（例えばＲＲＣシグナリング）を通知する制御論理チャネルか、またはユーザプレーンデータを通知するトラヒック論理チャネルかである論理チャネルを通じてＲＬＣレイヤにデータ転送サービス（参照により本明細書に援用される非特許文献２の５．４および５．３項を参照のこと）を提供する。以下の制御論理チャネルが規定される：ブロードキャスト制御チャネル（ＢＣＣＨ：broadcast control channel）、ページング制御チャネル（ＰＣＣＨ：paging control channel）、共通制御チャネル（ＣＣＣＨ：common control channel）、マルチキャスト制御チャネル（ＭＣＣＨ：multicast control channel）および個別制御チャネル（ＤＣＣＨ：dedicated control channel）。トラヒック論理チャネルは個別トラヒックチャネル（ＤＴＣＨ：dedicated traffic channel）およびマルチキャストトラヒックチャネル（ＭＴＣＨ：multicast traffic channel）である。
論理チャネルは、例えば、バッファ状況報告の目的で、ＬＣＧ ＩＤ０〜３を持つ４つの異なる論理チャネルグループ（ＬＣＧ：Logical Channel Group）のうちの１つと関連づけられる。
他方で、ＭＡＣレイヤからのデータは、ダウンリンクまたはアップリンクと分類されるトランスポートチャネルを通じて物理レイヤと交換される。データは、それがどのように無線で送信されるかに応じてトランスポートチャネルに多重化される。以下のダウンリンクトランスポートチャネルが規定される：ブロードキャストチャネル（ＢＣＨ：Broadcast channel）、ダウンリンク共有チャネル（ＤＬ−ＳＣＨ：downlink shared channel）、ページングチャネル（ＰＣＨ：paging channel）およびマルチキャストチャネル（ＭＣＨ：multicast channel）。以下のアップリンクトランスポートチャネルが規定される：アップリンク共有チャネル（ＵＬ−ＳＣＨ：uplink shared channel）およびランダムアクセスチヤネル（ＲＡＣＨ）。論理チャネルおよびトランスポートチャネルおよびそれらの間のマッピングに関するさらなる情報は、参照により本明細書にその全体が援用される非特許文献２の４．５節「Channel Structure」に見られることができる。
無線リソース制御（ＲＲＣ）レイヤは、無線インタフェースでのＵＥとｅＮＢとの間の通信、およびいくつかのセルを渡って移動するＵＥのモビリティを制御する。ＲＲＣプロトコルはＮＡＳ情報の転送もサポートする。ＲＲＣ＿ＩＤＬＥのＵＥに対して、ＲＲＣは、着呼のネットワークからの通知をサポートする。ＲＲＣ接続制御は、ページング、測定構成および報告、無線リソース構成、初期セキュリティアクティブ化、ならびにシグナリング無線ベアラ（ＳＲＢ：Signalling Radio Bearer）の、およびユーザデータを通知する無線ベアラ（データ無線ベアラ（ＤＲＢ：Data Radio Bearer））の確立を含む、ＲＲＣ接続の確立、修正および解除に関連したすべての手順を包含する。
個別ＲＲＣメッセージはシグナリング無線ベアラを渡って輸送されて、論理チャネル−接続確立中に共通制御チャネル（ＣＣＣＨ）か、またはＲＲＣ＿ＣＯＮＮＥＣＴＥＤで個別制御チャネル（ＤＣＣＨ）かに、ＰＤＣＰおよびＲＬＣレイヤを介してマッピングされる。システム情報およびページングメッセージは論理チャネル、それぞれブロードキャスト制御チャネル（ＢＣＣＨ）およびページング制御チャネル（ＰＣＣＨ）に直接マッピングされる。
ＬＴＥ（Long Term Evolution）アーキテクチャを使用する移動ネットワークでは、ベアラは、ユーザ機器をインターネットなどのパケットデータネットワーク（ＰＤＮ：Packet Data Network）に接続するために使用される「トンネル」である。ＬＴＥネットワークでは、ＱｏＳがＵＥとＰＤＮゲートウェイとの間に実装され、一組のベアラに適用される。「ベアラ」は基本的に仮想概念であり、かつ一組のトラヒックに特別な処理を提供する一組のネットワーク構成であり、例えばＶｏＩＰパケットはウェブブラウザトラヒックと比較してネットワークによって優先される。本質的に、異なる特性（例えば遅延、配信時間、スループット、ＳＮＲ、誤り率ジッタなど）の各ストリームが異なるベアラにマッピングされる。したがって、ベアラはＱｏＳ制御の単位であり、一組のＱｏＳ要件を満たすために１つのベアラが使用される。ＬＴＥでは、ＱｏＳは、総称的に図３に図示するＥＰＳベアラと呼ばれる、無線ベアラ、Ｓ１ベアラおよびＳ５／Ｓ８ベアラに適用される。図３は、リレーＵＥとリレーＵＥによって応対されるリモートＵＥとの間のサイドリンク無線ベアラも例示する（ＰｒｏＳｅサイドリンクに関する情報については後節を参照のこと）。
ＬＴＥ移動ネットワークでは、ユーザ機器装置がアクティブ化される（これは、ユーザ機器がオンであり、かつ認証を行ったことを意味する）ときはいつでも、デフォルトＰ−ＧＷに対して１つのデフォルトベアラが確立される。１つのデフォルトＰ−ＧＷに対して少なくとも１つのデフォルトベアラがなければならないが、単一のユーザ機器装置に対して同じまたは他のＰ−ＧＷに対する１１個までの他のベアラがアクティブであることができる。ベアラは、ＧＰＲＳトンネリングプロトコル、ユーザプレーン（ＧＴＰ−Ｕ：GPRS tunneling protocol, user plane）でユーザデータをカプセル化する。ＧＴＰ−Ｕ情報は、次いでＵＤＰで、かつＩＰパケット内で送られる。あらゆるユーザ機器装置が、それが接続する各Ｐ−ＧＷに対して「常にオンである」デフォルトベアラを有する。例えば、ユーザ機器が１つのＰ−ＧＷを通してインターネットに、および別のＰ−ＧＷを通して企業イントラネットに接続する場合、２つのデフォルトベアラがアクティブであることになる。加えて、ユーザ機器は、サービス品質（ＱｏＳ）要件に基づいて、他のＰＤＮに対して他の個別ベアラを確立することができる。例えば、インターネットを通じてストリーミングビデオを見ることは、個別ベアラを通じて行われることができる。個別ベアラが帯域保証（保証ビットレート、もしくはＧＢＲ：guaranteed bit rate）を使用することができるか、またはユーザ機器が非ＧＢＲベアラを確立することができる。
ＬＴＥには２種類の無線ベアラがある：制御シグナリング、例えばＲＲＣシグナリング／ＮＡＳ情報を通知するシグナリング無線ベアラ（ＳＲＢ）（ＬＴＥには数種類のＳＲＢがある：ＳＲＢ０、ＳＲＢ１およびＳＲＢ２）、ならびにユーザプレーントラヒック／データを通知するデータ無線ベアラ（ＤＲＢ）。ＵＥは８つまでのＤＲＢをサポートする。
ＥＰＳベアラ自体は、以下の順に確立される、（非ローミング状況で）３つの部分から成る連結トンネルである。
− Ｓ５ベアラ−このトンネルはサービングゲートウェイ（Ｓ−ＧＷ）をＰ−ＧＷに接続する。（トンネルはＰ−ＧＷからＰＤＮサービスネットワークまで延長することができるが、これはここでは考慮されない。）
− Ｓ１ベアラ−このトンネルは進化型ＮｏｄｅＢ（ｅＮｏｄｅＢまたはｅＮＢ）無線セルをＳ−ＧＷと接続する。ハンドオーバがエンドツーエンド接続のために新たなＳ１ベアラを確立する。
− 無線ベアラ−このトンネルはユーザ機器をｅＮｏｄｅＢ（ｅＮＢ）に接続する。このベアラは、移動ユーザが１つのセルから別のセルに移動するときに無線ネットワークがハンドオーバを行うにあたり、ＭＭＥ（Mobile Management Entity）の指示の下でユーザに追従する。
以上列記されたすべての異なる種類のベアラに関して、１対１マッピングの関係がある。言い換えると、ＥＰＳベアラとＥ−ＲＡＢとの間、Ｅ−ＲＡＢと無線ベアラとの間、および無線ベアラとＳ１ベアラとの間に、固有の対応がある。
各ベアラは一組のＱｏＳパラメータを使用して、ビットレート、パケット遅延、パケットロス、ビット誤り率およびスケジューリングポリシーなどの、トランスポートチャネルのプロパティを記述する。４つのキーパラメータがここで概説される。
ＱｏＳクラスインジケータ（ＱＣＩ：QoS class indicator）：ＱＣＩは基本的にベアラの固有の期待される処理を規定し、たとえネットワークノードが異なるベンダによって開発されるとしても、同じＱＣＩのベアラの同様の取扱いを提供するものと意図される。受信されるＱＣＩ値に基づいて、各ネットワークノードが対応する関連ベアラの取扱い方を知ることになり、すなわちＱＣＩ値がベアラに関連づけられている。現行の規定されたＱＣＩ値の一覧が非特許文献３の６．１．７節に見られることができる。
割当ておよび保持優先度（ＡＲＰ：allocation and retention priority）：ＡＲＰは、ベアラが受け取る制御プレーントラヒックに対する転送処理を特定する。ＡＲＰは、ベアラ確立および修正の他に、接続設定および解除を可能にする。例えば、ＡＲＰは、リソース限界またはトラヒック輻輳中にどのベアラが解除されるべきかを決定するためにＥＰＳによって使用されることができる。
最大ビットレート（ＭＢＲ：maximum bit rate）：ＭＢＲは、リアルタイムサービスに対してのみ適用可能であり、ＧＢＲベアラに対して規定される。ＭＢＲは、ベアラ上のトラヒックが超えてはいけないビットレートである。
保証ビットレート（ＧＢＲ）：ＧＢＲは、ネットワークがそのベアラに対して（例えばアドミッションコントロール機能の使用を通じて）保証するビットレートを特定する。３ＧＰＰ Ｒｅｌｅａｓｅ８以降では、ＭＢＲはＧＢＲに等しく設定されなければならず、すなわち保証レートはシステムによって許容される最大レートでもある。
＜論理チャネル優先順位付け（ＬＣＰ：Logical Channel Prioritization）手順＞
アップリンクについて、ＵＥが、割り当てられた無線リソースを使用して送信されることになるＭＡＣ ＰＤＵを作成するプロセスは完全に標準化されるが、ＬＣＰ手順は、最適でかつ異なるＵＥ実装間で一貫した方途でＵＥが各構成された無線ベアラのＱｏＳを充足することを保証するように設計される。ＰＤＣＣＨでシグナリングされるアップリンク送信リソースグラントメッセージに基づいて、ＵＥは、新たなＭＡＣ ＰＤＵに含まれるべき各論理チャネルに対するデータ量を決定しなければならず、必要ならば、ＭＡＣ制御要素のためにスペースも割り当てなければならない。
複数の論理チャネルからのデータでＭＡＣ ＰＤＵを構築する際、最も単純かつ最も直観的な方法は絶対優先度ベースの方法であり、この方法ではＭＡＣ ＰＤＵスペースは論理チャネル優先度の降順に論理チャネルに割り当てられる。つまり、最高優先度の論理チャネルからのデータがＭＡＣ ＰＤＵで最初に扱われ、次の最高優先度の論理チャネルからのデータが後続し、ＭＡＣ ＰＤＵスペースが尽きるまで続く。絶対優先度ベースの方法はＵＥ実装の点で非常に単純であるとは言え、その方法は時には低優先度の論理チャネルからのデータの枯渇につながる。枯渇は、高優先度の論理チャネルからのデータがすべてのＭＡＣ ＰＤＵスペースを占めるために低優先度の論理チャネルからのデータが送信されることができないことを意味する。
ＬＴＥでは、重要性の順にデータを送信するが、しかしより低い優先度を持つデータの枯渇を回避もするために、優先ビットレート（ＰＢＲ：Prioritized Bit Rate）が各論理チャネルに対して規定される。ＰＢＲは、論理チャネルに対して保証される最小データレートである。たとえ論理チャネルが低優先度を有するとしても、ＰＢＲを保証するために、少なくとも小量のＭＡＣ ＰＤＵスペースが割り当てられる。したがって、ＰＢＲを使用することによって、枯渇の問題は回避されることができる。
ＰＢＲを持つＭＡＣ ＰＤＵを構築することは、２つのラウンドから成る。第１のラウンドでは、各論理チャネルは論理チャネル優先度の降順に扱われるが、ＭＡＣ ＰＤＵに含まれる各論理チャネルからのデータ量は、最初、論理チャネルの設定されたＰＢＲ値に対応する量に制限される。すべての論理チャネルがそれらのＰＢＲ値まで扱われた後、ＭＡＣ ＰＤＵに残された余地があれば、第２のラウンドが行われる。第２のラウンドでは、各論理チャネルは優先度の降順に再び扱われる。第１のラウンドと比較した第２のラウンドについての大きな違いは、より高い優先度のすべての論理チャネルがもはや送信するデータを有しない場合だけ、より低い優先度の各論理チャネルがＭＡＣ ＰＤＵスペースを割り当てられることができることである。
ＭＡＣ ＰＤＵは、各設定された論理チャネルからのＭＡＣ ＳＤＵだけでなくＭＡＣ ＣＥも含んでもよい。パディングＢＳＲを除いて、ＭＡＣ ＣＥは、それがＭＡＣレイヤの動作を制御するので、論理チャネルからのＭＡＣ ＳＤＵより高い優先度を有する。したがって、ＭＡＣ ＰＤＵが構成されるとき、ＭＡＣ ＣＥが存在すれば、それが含まれるべき最初のものであり、残りのスペースが論理チャネルからのＭＡＣ ＳＤＵのために使用される。次いで、追加のスペースが残され、それがＢＳＲを含むのに十分大きければ、パディングＢＳＲがトリガされてＭＡＣ ＰＤＵに含められる。
論理チャネル優先順位付けは、例えば参照によって本明細書に援用される非特許文献２の５．４．３．１項に標準化される。
論理チャネル優先順位付け（ＬＣＰ：Logical Channel Prioritization）手順は、新たな送信が行われるときに適用される。
ＲＲＣは、各論理チャネルに対するシグナリングによって、アップリンクデータのスケジューリングを制御する：
− 大きい優先度値ほど低い優先度レベルを示すpriority、
− 優先ビットレート（ＰＢＲ：Prioritized Bit Rate）を設定するprioritisedBitRate、
− バケットサイズ継続時間（ＢＳＤ：Bucket Size Duration）を設定するbucketSizeDuration。
ＵＥは、各論理チャネルｊのための変数Ｂｊを維持するものとする。Ｂｊは、関連した論理チャネルが確立されるときにゼロに初期化され、各ＴＴＩごとに積ＰＢＲ×ＴＴＩ継続時間だけインクリメントされるものとし、ここでＰＢＲは論理チャネルｊの優先ビットレートである。しかしながら、Ｂｊの値は決してバケットサイズを超えることができず、Ｂｊの値が論理チャネルｊのバケットサイズより大きければ、Ｂｊの値はバケットサイズに設定されるものとする。論理チャネルのバケットサイズはＰＢＲ×ＢＳＤに等しく、ここでＰＢＲおよびＢＳＤは上位のレイヤによって設定される。
ＵＥ（ＭＡＣエンティティ）は、新たな送信が行われるときに以下の論理チャネル優先順位付け手順を行うものとする：
− ＵＥ（ＭＡＣエンティティ）は、以下のステップで論理チャネルにリソースを割り当てるものとする：
−− ステップ１：Ｂｊ＞０のすべての論理チャネルが優先度降順にリソースを割り当てられる。無線ベアラのＰＢＲが「無限大」に設定されれば、ＵＥは、より低い優先度無線ベアラのＰＢＲを満たす前に、無線ベアラでの送信のために利用可能であるすべてのデータのためにリソースを割り当てるものとする。
−− ステップ２：ＵＥ（ＭＡＣエンティティ）は、ステップ１で論理チャネルｊに分配されるＭＡＣ ＳＤＵの総サイズだけＢｊをデクリメントするものとする。
注：Ｂｊの値は負でありえる。
−− ステップ３：任意のリソースが残れば、どちらが先にせよその論理チャネルのためのデータかまたはＵＬグラントかいずれかが尽きるまで、すべての論理チャネルが（Ｂｊの値に関係なく）厳密な優先度降順に扱われる。等しい優先度が設定される論理チャネルは等しく扱われるべきである。
− ＵＥ（ＭＡＣエンティティ）は、以上のスケジューリング手順の間、以下の規則にも従うものとする：
−− ＵＥ（ＭＡＣエンティティ）は、全体のＳＤＵ（または部分的に送信されるＳＤＵもしくは再送信されるＲＬＣ ＰＤＵ）が残りのリソースに収まれば、ＲＬＣ ＳＤＵ（または部分的に送信されるＳＤＵもしくは再送信されるＲＬＣ ＰＤＵ）をセグメント化するべきでない。
−− ＵＥ（ＭＡＣエンティティ）が論理チャネルからのＲＬＣ ＳＤＵをセグメント化する場合、ＵＥは、可能な限りグラントを満たすようにセグメントのサイズを最大化するものとする。
−− ＵＥ（ＭＡＣエンティティ）はデータの送信を最大化するべきである。
−− ＵＥ（ＭＡＣエンティティ）が、送信のために利用可能なデータを有しつつ、４バイト以上であるＵＬグラントサイズを与えられれば、ＵＥ（ＭＡＣエンティティ）は、パディングＢＳＲおよび／またはパディングのみを送信することはしないものとする（ＵＬグラントサイズが７バイト未満であり、かつＡＭＤ ＰＤＵセグメントが送信される必要がある場合を除く）。
ＵＥは、停止されている無線ベアラに対応する論理チャネルのためのデータを送信しないものとする（無線ベアラが停止されていると考えられるときの条件は、TS 36.211に規定される）。
論理チャネル優先順位付け手順に関して、ＵＥは以下の相対的優先度を降順に考慮するものとする：
− Ｃ−ＲＮＴＩに関するＭＡＣ制御要素またはＵＬ−ＣＣＣＨからのデータ；
− パディングのために含まれるＢＳＲを除くＢＳＲに関するＭＡＣ制御要素；
− ＰＨＲもしくは拡張ＰＨＲまたは二重接続ＰＨＲに関するＭＡＣ制御要素；
− ＵＬ−ＣＣＣＨからのデータを除く、任意の論理チャネルからのデータ；
− パディングのために含まれるＢＳＲに関するＭＡＣ制御要素。
ＵＥが１つのＴＴＩに複数のＭＡＣ ＰＤＵを送信するように要求されるとき、ステップ１〜３および関連する規則が各グラントに独立してか、またはグラントの容量の和にかいずれかで適用されてもよい。また、グラントが処理される順序は、ＵＥ実装次第である。ＵＥが１つのＴＴＩに複数のＭＡＣ ＰＤＵを送信するように要求されるとき、どのＭＡＣ ＰＤＵにＭＡＣ制御要素が含まれるか決定することはＵＥ実装次第である。
＜ＬＴＥデバイスツーデバイス（Ｄ２Ｄ：Device to Device）近接サービス（ＰｒｏＳｅ：Proximity Services）＞
近接ベースのアプリケーションおよびサービスが、新興の社会的技術的傾向を表している。特定される領域は、事業者およびユーザにとって関心があろう商用サービスおよび公衆安全（Public Safety）に関連したサービスを含む。ＬＴＥへの近接サービス（ＰｒｏＳｅ）能力の導入は、３ＧＰＰ業界がこの発展市場に応対するのを許容するであろうし、同時に、ＬＴＥに共同で関与するいくつかの公衆安全地域の急務を満たすであろう。
デバイスツーデバイス（Ｄ２Ｄ：Device to Device）通信は、セルラネットワークに対するアンダーレイとしてのＤ２Ｄがスペクトル効率を上昇させるのを許容するＬＴＥ−Ｒｅｌ．１２により導入される技術要素である。例えば、セルラネットワークがＬＴＥであれば、すべてのデータ通知用物理チャネルはＤ２ＤシグナリングのためにＳＣ−ＦＤＭＡを使用する。Ｄ２Ｄ通信では、ユーザ機器は、無線基地局を通しての代わりにセルラリソースを使用する直接リンクを通じて互いにデータ信号を送信する。本開示を通して、「Ｄ２Ｄ」、「ＰｒｏＳｅ」および「サイドリンク」という用語は交換可能である。
＜ＬＴＥでのＤ２Ｄ通信＞
ＬＴＥでのＤ２Ｄ通信は２つの領域：発見および通信に重点を置いている。
ＰｒｏＳｅ（近接ベースのサービス）直接発見（Direct Discovery）が、ＰｒｏＳｅ対応ＵＥによって、ＰＣ５インタフェースを介してＥ−ＵＴＲＡ直接無線信号を使用してその近接の他のＰｒｏＳｅ対応ＵＥを発見するために使用される手順として規定され、後により詳細に記載することになる。
Ｄ２Ｄ通信では、ＵＥは、基地局（ＢＳ：Base Station）を通しての代わりにセルラリソースを使用する直接リンクを通じて互いにデータ信号を送信する。Ｄ２Ｄユーザは、ＢＳ下で制御されたまま、すなわち少なくともｅＮＢのカバレッジにいるときに直接通信する。したがって、Ｄ２Ｄは、セルラリソースを再使用することによってシステム性能を向上させることができる。
Ｄ２Ｄは、（ＦＤＤの場合）アップリンクＬＴＥスペクトル、または、（カバレッジ外の場合を除き、ＴＤＤの場合）カバレッジを与えるセルのアップリンクサブフレームで動作することを前提とする。さらには、Ｄ２Ｄ送信／受信は所与のキャリアで全二重を使用しない。個々のＵＥの観点から、所与のキャリアで、Ｄ２Ｄ信号受信およびＬＴＥアップリンク送信は全二重を使用しない、すなわちＤ２Ｄ信号受信およびＬＴＥ ＵＬ送信の同時は不可能である。
Ｄ２Ｄ通信では、１つの特定のＵＥ１が送信の役割を有するとき（送信ユーザ機器または送信端末）、ＵＥ１はデータを送信し、別のＵＥ２（受信ユーザ機器）がそのデータを受信する。ＵＥ１およびＵＥ２はそれらの送信および受信役割を交換することができる。ＵＥ１からの送信は、ＵＥ２のような１つまたは複数のＵＥによって受信されることができる。
ユーザプレーンプロトコルに関して、Ｄ２Ｄ通信の観点からの取決めの一部を以下に挙げる（参照により本明細書に援用される非特許文献４の９．２．２節も参照のこと）。
−ＰＤＣＰ：
−− １：Ｍ Ｄ２Ｄブロードキャスト通信データ（すなわちＩＰパケット）は、通常のユーザプレーンデータとして取り扱われるべきである。
−− ＰＤＣＰでのヘッダ圧縮／伸長は、１：Ｍ Ｄ２Ｄブロードキャスト通信に適用可能である。
−−− Ｕモードは、公共安全（public safety）のためのＤ２Ｄブロードキャスト動作のためのＰＤＣＰでのヘッダ圧縮のために使用される。
− ＲＬＣ：
−− ＲＬＣ ＵＭは１：Ｍ Ｄ２Ｄブロードキャスト通信のために使用される。
−− セグメンテーションおよび再構築はＲＬＣ ＵＭによってＬ２でサポートされる。
−− 受信ＵＥは、送信ピアＵＥ当たり少なくとも１つのＲＬＣ ＵＭエンティティを維持する必要がある。
−− ＲＬＣ ＵＭ受信側エンティティは、最初のＲＬＣ ＵＭデータユニットの受信前に設定される必要はない。
−− ここまで、ユーザプレーンデータ送信のためのＤ２Ｄ通信のためのＲＬＣ ＡＭまたはＲＬＣ ＴＭの必要性は確認されていない。
−ＭＡＣ：
−− １：Ｍ Ｄ２Ｄブロードキャスト通信に対して、ＨＡＲＱフィードバックは前提とされない。
−− 受信ＵＥは、受信側ＲＬＣ ＵＭエンティティを識別するためにソースＩＤを知る必要がある。
−− ＭＡＣヘッダは、ＭＡＣレイヤでパケットをフィルタリングすることを許容するＬ２ターゲットＩＤを備える。
−− Ｌ２ターゲットＩＤはブロードキャスト、グループキャストまたはユニキャストアドレスでもよい。
−−− Ｌ２グループキャスト／ユニキャスト：ＭＡＣヘッダで通知されるＬ２ターゲットＩＤは、受信ＲＬＣ ＵＭ ＰＤＵをＲＬＣ受信側エンティティに送る前にさえそれを破棄することを許容するであろう。
−−− Ｌ２ブロードキャスト：受信ＵＥは、すべての送信機からのすべての受信ＲＬＣ ＰＤＵを処理し、ＩＰパケットを再構築して上位のレイヤに送ろうとするであろう。
−− ＭＡＣサブヘッダは、複数の論理チャネルを区別するＬＣＩＤを含む。
−− 少なくとも多重化／逆多重化、優先度処理およびパディングはＤ２Ｄに対して有用である。
＜ＰｒｏＳｅ直接通信レイヤ２リンク＞
要するに、２つのＵＥ間にＰＣ５上の安全なレイヤ２リンクを確立することによって、ＰｒｏＳｅ直接１対１通信が実現される。各ＵＥは、それがレイヤ２リンクで送信するあらゆるフレームのソースレイヤ２ＩＤフィールドに、およびそれがレイヤ２リンクで受信するあらゆるフレームの宛先レイヤ２ＩＤに含まれるユニキャスト通信のためのレイヤ２ＩＤを有する。ＵＥは、ユニキャスト通信のためのレイヤ２ＩＤが少なくともローカルで一意であることを保証する必要がある。そこで、ＵＥは、不特定のメカニズムを使用して隣接するＵＥとのレイヤ２ＩＤ競合を取り扱う（例えば、競合が検出されると、ユニキャスト通信のための新たなレイヤ２ＩＤを自己割り当てする）備えができているべきである。ＰｒｏＳｅ１対１直接通信のためのレイヤ２リンクは、２つのＵＥのレイヤ２ＩＤの組合せによって識別される。これは、ＵＥが、同じレイヤ２ＩＤを使用してＰｒｏＳｅ１対１直接通信のための複数のレイヤ２リンクに係わることができることを意味する。
ＰｒｏＳｅ１対１直接通信は、参照により本明細書に援用される非特許文献８の７．１．２節に詳細に説明される以下の手順で構成される。
− ＰＣ５上の安全なレイヤ２リンクの確立。
− ＩＰアドレス／プレフィックス割当て。
− ＰＣ５上のレイヤ２リンク維持。
− ＰＣ５上のレイヤ２リンク解除。
図４は、ＰＣ５インタフェース上の安全なレイヤ２リンクの確立のさせ方を開示する。
１. ＵＥ−１が、相互認証をトリガするためにＵＥ−２に直接通信要求（Direct Communication Request）メッセージを送信する。リンクイニシエータ（ＵＥ−１）は、ステップ１を実行するためにピア（ＵＥ−２）のレイヤ２ＩＤを知る必要がある。例として、リンクイニシエータは、最初に発見手順を実行することによって、またはピアを含むＰｒｏＳｅ一対多通信に関与したことによってピアのレイヤ２ＩＤを学習してもよい。
２. ＵＥ−２が、相互認証のための手順を開始する。認証手順の完了成功が、ＰＣ５上の安全なレイヤ２リンクの確立を完了する。
少なくとも以下の標準ＩＥＴＦメカニズムが、ＩＰアドレス／プレフィックス割当てのために使用されることができる：
− ＩＰｖ４アドレスの割当てのためのＤＨＣＰベースのＩＰアドレス設定。
− ＩＰｖ６プレフィックスの割当てのためのＲＦＣ４８６２に明記されるＩＰｖ６ステートレスアドレス（Stateless Address）自動設定。
２つのＵＥの一方は、ＤＨＣＰサーバまたはＩＰｖ６デフォルトルータとして機能する。ＰｒｏＳｅ ＵＥ−ＮＷリレーの場合には（ＰｒｏＳｅリレーに関する後章も参照のこと）、リレーは、ＰＣ５上の安全なレイヤ２リンクを通じてそれに接続するすべてのリモートＵＥに対してＤＨＣＰサーバまたはＩＰｖ６デフォルトルータとして機能する。
独立した（非リレー）１対１通信に係わるＵＥは、リンクローカルアドレスも使用してもよい。
ＰＣ５シグナリングプロトコル（Signalling Protocol）は、ＵＥがＰｒｏＳｅ通信距離でなくなる時を検出するために使用されるキープアライブ機能をサポートするものとし、その結果ＵＥは黙示のレイヤ２リンク解除を始めることができる。
ＰＣ５上のレイヤ２リンク解除は、他方のＵＥに送信される切断要求（Disconnect Request）メッセージを使用することによって行われることができ、これはすべての関連するコンテキストデータも削除する。切断要求メッセージの受信に応じて、他方のＵＥは、切断応答（Disconnect Response）メッセージで応答し、レイヤ２リンクと関連づけられるすべてのコンテキストデータを削除する。
＜ＰｒｏＳｅ直接通信関連識別情報＞
非特許文献５の現行バージョン１３．３．０が、ＰｒｏＳｅ直接通信のために使用する以下の識別情報を８．３項に規定する：
− ＳＬ−ＲＮＴＩ：ＰｒｏＳｅ直接通信スケジューリングのために使用される固有の識別；
− ソースレイヤ２ＩＤ：サイドリンクＰｒｏＳｅ直接通信でデータの送信側を識別する。ソースレイヤ２ＩＤは長さ２４ビットであり、受信側でのＲＬＣ ＵＭエンティティおよびＰＤＣＰエンティティの識別のためのＰｒｏＳｅレイヤ２宛先ＩＤおよびＬＣＩＤと共に使用される；
− 宛先レイヤ２ＩＤ：サイドリンクＰｒｏＳｅ直接通信でデータのターゲットを識別する。宛先レイヤ２ＩＤは長さ２４ビットであり、ＭＡＣレイヤで２つのビット列に分割される：
−− １つのビット列は宛先レイヤ２ＩＤのＬＳＢ部（８ビット）であり、サイドリンク制御レイヤ１ＩＤとして物理レイヤに転送される。これはサイドリンク制御の意図されたデータのターゲットを識別し、物理レイヤでパケットフィルタリングのために使用される。
−− 第２のビット列は宛先レイヤ２ＩＤのＭＳＢ部（１６ビット）であり、ＭＡＣヘッダ内で通知される。これはＭＡＣレイヤでパケットフィルタリングのために使用される。
アクセス層シグナリングは、グループ形成のために、ならびにＵＥでソースレイヤ２ＩＤ、宛先レイヤ２ＩＤおよびサイドリンク制御Ｌ１ＩＤを設定するために必要とされない。これらの識別情報は上位レイヤによって提供されるか、または上位レイヤによって提供される識別情報から導出されるかいずれかである。グループキャストおよびブロードキャストの場合には、上位レイヤによって提供されるＰｒｏＳｅ ＵＥ ＩＤはソースレイヤ２ＩＤとして直接使用され、上位レイヤによって提供されるＰｒｏＳｅレイヤ２グループＩＤはＭＡＣレイヤで宛先レイヤ２ＩＤとして直接使用される。
＜近接サービスのための無線リソース割当て＞
送信ＵＥの観点から、近接サービス対応ＵＥ（ＰｒｏＳｅ対応ＵＥ）は、リソース割当てのための２つのモードで動作することができる。
モード１はｅＮＢスケジュールリソース割当てを指し、ここでＵＥがｅＮＢ（またはリリース１０中継ノード）に送信リソースを要求し、ｅＮｏｄｅＢ（またはリリース１０中継ノード）は次いで直接データおよび直接制御情報を送信するためにＵＥによって使用されるリソースをスケジュールする（例えばスケジューリング割当て）。ＵＥは、データを送信するためにＲＲＣ＿ＣＯＮＮＥＣＴＥＤである必要がある。特に、ＵＥはｅＮＢにスケジューリング要求（Ｄ−ＳＲまたはランダムアクセス）を送信し、通例のようにバッファ状況報告（ＢＳＲ：Buffer Status Report）が後続する（以下の章「Ｄ２Ｄ通信のための送信手順」も参照のこと）。ＢＳＲに基づいて、ｅＮＢは、ＵＥがＰｒｏＳｅ直接通信送信のためのデータを有すると判定することができ、送信のために必要とされるリソースを推定することができる。
他方では、モード２はＵＥ自律リソース選択を指し、ここでＵＥが、直接データおよび直接制御情報を送信するためにリソースプールからリソース（時間および周波数）を単独で選択する（すなわちＳＡ）。１つのリソースプールが、例えばＳＩＢ１８の内容によって、すなわちフィールドｃｏｍｍＴｘＰｏｏｌＮｏｒｍａｌＣｏｍｍｏｎによって規定され、この特定のリソースプールはセルでブロードキャストされ、次いでなおＲＲＣ＿Ｉｄｌｅ状態のセルにおけるすべてのＵＥに共通に利用可能である。実際上、ｅＮＢは、上記プールの４つまでの異なるインスタンス、それぞれＳＡメッセージおよび直接データの送信のための４つのリソースプールを規定してもよい。しかしながら、たとえ複数のリソースプールを設定されたとしても、ＵＥは列記に規定される第１のリソースプールを常に使用するものとする。
代替策として、別のリソースプールがｅＮＢによって規定され、ＳＩＢ１８で、すなわちフィールドｃｏｍｍＴｘＰｏｏｌＥｘｃｅｐｔｉｏｎａｌを使用することによってシグナリングされることができ、そのリソースプールは例外的な場合にＵＥによって使用されることができる。
ＵＥがどのリソース割当てモードを使用する予定かは、ｅＮＢによって設定可能である。さらには、ＵＥがＤ２Ｄデータ通信のためにどのリソース割当てモードを使用する予定かは、また、ＲＲＣ状態、すなわちＲＲＣ＿ＩＤＬＥまたはＲＲＣ＿ＣＯＮＮＥＣＴＥＤ、およびＵＥのカバレッジ状態、すなわちカバレッジ内、カバレッジ外に依存してもよい。ＵＥは、それがサービングセルを有する（すなわちＵＥがＲＲＣ＿ＣＯＮＮＥＣＴＥＤであるかまたはＲＲＣ＿ＩＤＬＥのセルにキャンプしている）とすれば、カバレッジ内と考えられる。
図５は、オーバーレイ（ＬＴＥ）およびアンダーレイ（Ｄ２Ｄ）システムのための送信／受信リソースの使用を例示する。
基本的に、ｅＮｏｄｅＢは、ＵＥがモード１またはモード２送信を適用してもよいかどうかを制御する。一旦ＵＥが、それがＤ２Ｄ通信を送信（または受信）することができるそのリソースを知ると、ＵＥは対応する送信／受信のための対応するリソースのみを使用する。例えば、図５で、Ｄ２Ｄサブフレームは、Ｄ２Ｄ信号を受信または送信するためにのみ使用されることになる。Ｄ２ＤデバイスとしてのＵＥは半二重モードで動作するであろうから、ＵＥは任意の時点でＤ２Ｄ信号を受信かまたは送信かいずれかすることができる。同様に、図５に例示するその他のサブフレームは、ＬＴＥ（オーバーレイ）送信および／または受信のために使用することができる。
＜Ｄ２Ｄ通信のための送信手順＞
Ｄ２Ｄデータ送信手順は、リソース割当てモードに応じて異なる。モード１について上記したように、ｅＮＢは、ＵＥからの対応する要求後、スケジューリング割当ておよびＤ２Ｄデータ通信のためのリソースを明示的にスケジュールする。特に、ＵＥは、Ｄ２Ｄ通信が通常許容されるが、しかしモード２リソース（すなわちリソースプール）は提供されないことをｅＮＢによって通知されてもよく；これは、例えばＵＥによるＤ２Ｄ通信関心インジケーションおよび対応する応答（Ｄ２Ｄ通信応答）の交換で行われてもよく、ここで、上述した対応する例示的なＰｒｏｓｅＣｏｍｍＣｏｎｆｉｇ情報要素はｃｏｍｍＴｘＰｏｏｌＮｏｒｍａｌＣｏｍｍｏｎを含まないであろうから、送信を伴う直接通信を開始したいＵＥがＥ−ＵＴＲＡＮに各個々の送信のためのリソースを割り当てるように要求しなければならないことを意味する。したがって、そのような場合に、ＵＥは各個々の送信のためのリソースを要求しなければならず、以下に要求／グラント手順の異なるステップがこのモード１リソース割当てに関して例示的に列記される：
− ステップ１：ＵＥがＰＵＣＣＨを介してｅＮＢにＳＲ（スケジューリング要求）を送信する；
− ステップ２：ｅＮＢがＰＤＣＣＨを介して（ＵＥがＢＳＲを送信するための）ＵＬリソースを、Ｃ−ＲＮＴＩによってスクランブルして許可する；
− ステップ３：ＵＥがＰＵＳＣＨを介してバッファ状況を示すＤ２Ｄ ＢＳＲを送信する；
− ステップ４：ｅＮＢがＰＤＣＣＨを介して（ＵＥがデータを送信するための）Ｄ２Ｄリソースを、Ｄ２Ｄ−ＲＮＴＩによってスクランブルして許可する。
− ステップ５：Ｄ２Ｄ Ｔｘ ＵＥがステップ４で受信したグラントに従ってＳＡ／Ｄ２Ｄデータを送信する。
ＳＣＩ（Sidelink Control Information：サイドリンク制御情報）とも名付けられるスケジューリング割当て（ＳＡ：Scheduling Assignment）は、制御情報、例えば対応するＤ２Ｄデータ送信のための時間／周波数リソースへのポインタ、変調および符号体系ならびにグループ宛先ＩＤ（Group Destination ID）を含むコンパクトな（低ペイロード）メッセージである。ＳＣＩは、１つの（ＰｒｏＳｅ）宛先ＩＤに対するサイドリンクスケジューリング情報を搬送する。ＳＡ（ＳＣＩ）の内容は基本的に、上記ステップ４で受信したグラントに従う。Ｄ２ＤグラントおよびＳＡ内容（すなわちＳＣＩ内容）は、参照により本明細書に援用される非特許文献６の５．４．３項に規定され、特にＳＣＩ ｆｏｒｍａｔ０を規定する。
他方では、モード２リソース割当てに関して、上記ステップ１〜４は基本的に必要でなく、ＵＥは、ｅＮＢによって設定および提供される送信リソースプールからＳＡおよびＤ２Ｄデータ送信のためのリソースを自律的に選択する。
図６は、２つのＵＥ（ＵＥ−ＡおよびＵＥ−Ｂ）に対するスケジューリング割当ておよびＤ２Ｄデータの送信を例示的に示し、ここでスケジューリング割当てを送信するためのリソースは周期的であり、Ｄ２Ｄデータ送信のために使用されるリソースは対応するスケジューリング割当てによって示される。
＜ＰｒｏＳｅネットワークアーキテクチャおよびＰｒｏＳｅエンティティ＞
図７は、それぞれのＵＥ ＡおよびＢにおける異なるＰｒｏＳｅアプリケーションの他に、ネットワークにおけるＰｒｏＳｅアプリケーションサーバおよびＰｒｏＳｅ機能を含む、非ローミングケースについての高レベルの例示的なアーキテクチャを例示する。図７のアーキテクチャ例は、参照により本明細書に援用される非特許文献７のバージョン１３．０．０の４．２章「Architectural Reference Model」から取られている。
機能エンティティは、参照により本明細書に援用される、上記引用した非特許文献７の４．４項「Functional Entities」に詳細に提示および説明されている。ＰｒｏＳｅ機能は、ＰｒｏＳｅのために必要とされるネットワーク関連行動のために使用される論理機能であり、ＰｒｏＳｅの特徴の各々のための異なる役割を果たす。ＰｒｏＳｅ機能は３ＧＰＰのＥＰＣの一部であり、近接サービスに関連した、許可、認証、データ操作などのようなすべての関連するネットワークサービスを提供する。ＰｒｏＳｅ直接発見および通信に関して、ＵＥは、ＰＣ３基準点を通じてＰｒｏＳｅ機能から、特定のＰｒｏＳｅ ＵＥ識別情報、他の構成情報の他に許可を得てもよい。ネットワークには複数のＰｒｏＳｅ機能を展開することができるが、例解の容易さのために、単一のＰｒｏＳｅ機能を提示する。ＰｒｏＳｅ機能は、ＰｒｏＳｅ特徴に応じて異なる役割を行う３つの主な副機能：直接供給機能（ＤＰＦ：Direct Provision Function）、直接発見名管理機能およびＥＰＣレベル発見機能から成る。ＤＰＦは、ＰｒｏＳｅ直接発見およびＰｒｏＳｅ直接通信を使用するために、ＵＥに必要なパラメータを供給するために使用される。
上記関連で使用される用語「ＵＥ」は、以下などのＰｒｏＳｅ機能性をサポートするＰｒｏＳｅ対応ＵＥを指す。
ＰｒｏＳｅアプリケーションサーバは、ＥＰＣ ＰｒｏＳｅユーザＩＤおよびＰｒｏＳｅ機能ＩＤの記憶、ならびにアプリケーションレイヤユーザＩＤおよびＥＰＣ ＰｒｏＳｅユーザＩＤのマッピングをサポートする。ＰｒｏＳｅアプリケーションサーバ（ＡＳ：Application Server）は３ＧＰＰの範囲外のエンティティである。ＵＥにおけるＰｒｏＳｅアプリケーションは、アプリケーションレイヤ基準点ＰＣ１を介してＰｒｏＳｅ ＡＳと通信する。ＰｒｏＳｅ ＡＳはＰＣ２基準点を介して３ＧＰＰネットワークに接続される。
＜Ｄ２ＤのためのＵＥカバレッジ状態＞
既に前述したように、Ｄ２Ｄ通信のためのリソース割当て方法は、ＲＲＣ状態、すなわちＲＲＣ＿ＩＤＬＥおよびＲＲＣ＿ＣＯＮＮＥＣＴＥＤとは別に、ＵＥのカバレッジ状態、すなわちカバレッジ内、カバレッジ外にも依存する。ＵＥは、それがサービングセルを有する（すなわちＵＥがＲＲＣ＿ＣＯＮＮＥＣＴＥＤであるかまたはＲＲＣ＿ＩＤＬＥのセルにキャンプしている）とすれば、カバレッジ内と考えられる。
ここまで述べた２つのカバレッジ状態、すなわちカバレッジ内（ＩＣ：in-coverage）およびカバレッジ外（ＯＯＣ：out-of-coverage）は、Ｄ２Ｄに関して下位状態にさらに区別される。図８は、Ｄ２Ｄ ＵＥが関連づけられることができる４つの異なる状態を示し、それらは以下の通りに要約されることができる：
− 状態１：ＵＥ１はアップリンクおよびダウンリンクカバレッジを有する。この状態では、ネットワークは各Ｄ２Ｄ通信セッションを制御する。さらには、ネットワークは、ＵＥ１がリソース割当てモード１かまたはモード２かどちらを使用するべきかを設定する。
− 状態２：ＵＥ２はアップリンクを除いたダウンリンクカバレッジ、すなわちＤＬカバレッジのみを有する。ネットワークは（競合ベースの）リソースプールをブロードキャストする。この状態では、送信ＵＥは、ネットワークによって設定されるリソースプールからＳＡおよびデータのために使用されるリソースを選択するが、リソース割当ては、そのような状態のＤ２Ｄ通信のためのモード２に従って可能であるのみである。
− 状態３：ＵＥ３はアップリンクおよびダウンリンクカバレッジを有しないので、ＵＥ３は厳密に言えば、既にカバレッジ外（ＯＯＣ：out-of-coverage）として考えられる。しかしながら、ＵＥ３は、それら自体（例えばＵＥ１）セルのカバレッジ内であるいくつかのＵＥのカバレッジ内であり、すなわちそれらのＵＥはＣＰ中継ＵＥまたは単にリレーＵＥとも称されることができる（ＰｒｏＳｅリレーに関する後章も参照のこと）。したがって、図８における状態３ＵＥの領域は、ＣＰ ＵＥ中継カバレッジ範囲として示されることができる。この状態３のＵＥはＯＯＣ状態３ＵＥとも称される。この状態では、ＵＥは、ｅＮＢ（ＳＩＢ）によって送信してもよく、セルのカバレッジ内のＣＰ ＵＥ中継ＵＥによってＰＤ２ＤＳＣＨを介してＯＯＣ状態３ＵＥに転送される何らかのセル固有情報を受信してもよい。（競合ベースの）ネットワーク制御リソースプールがＰＤ２ＤＳＣＨによってシグナリングされる。
− 状態４：ＵＥ４はカバレッジ外であり、セルのカバレッジ内である他のＵＥからＰＤ２ＤＳＣＨを受信しない。状態４ＯＯＣとも称されるこの状態では、送信ＵＥは、リソースの予め設定されたプールからデータ送信のために使用されるリソースを選択する。
状態３ＯＯＣと状態４ＯＯＣとの間で区別する理由は、主にカバレッジ外デバイスからのＤ２Ｄ送信とレガシーＥ−ＵＴＲＡ送信との間の潜在的に強い干渉を回避するためである。概して、Ｄ２Ｄ可能ＵＥは、カバレッジ外の間に使用するためにＤ２Ｄ ＳＡおよびデータの送信のためのリソースプールを予め設定しているだろう。これらのカバレッジ外ＵＥがセル境界付近でこれらの予め設定されたリソースプールで送信する場合、Ｄ２Ｄ送信とカバレッジ内レガシー送信との間の干渉がセル内の通信に悪影響を及ぼすはずである。カバレッジ内のＤ２Ｄ対応ＵＥがセル境界付近でそれらのカバレッジ外デバイスにＤ２Ｄリソースプール設定を転送するとすれば、カバレッジ外ＵＥはｅＮｏｄｅ Ｂによって特定されるリソースにそれらカバレッジ外ＵＥの送信を限定し、したがってカバレッジ内のレガシー送信との干渉を最小化することができるだろう。したがって、ＲＡＮ１は、カバレッジ内ＵＥがカバレッジ範囲すぐ外のそれらのデバイス（状態３ＵＥ）にリソースプール情報および他のＤ２Ｄ関連設定を転送するメカニズムを導入した。
物理Ｄ２Ｄ同期チャネル（ＰＤ２ＤＳＣＨ：Physical D2D synchronization channel）を使用してネットワーク近接のＵＥにカバレッジ内Ｄ２Ｄリソースプールについてのこの情報を通知し、その結果ネットワーク近接内のリソースプールは同調される。
＜Ｄ２Ｄ発見−モデルおよびリソース割当て＞
ＰｒｏＳｅ直接発見は、ＰｒｏＳｅ対応ＵＥによって、ＰＣ５を介してＥ−ＵＴＲＡ直接無線信号を使用してその近接の他のＰｒｏＳｅ対応ＵＥを発見するために使用される手順として規定される。上位のレイヤが、発見情報のアナウンスおよびモニタリングのための許可を取り扱う。この目的のため、ＵＥは、「発見信号」と称される所定の信号を交換しなければならない。発見信号を周期的に確認することによって、ＵＥは、必要とされるときに通信リンクを確立するために近接ＵＥの一覧を維持する。発見信号は、低信号対雑音比（ＳＮＲ：Signal-to-Noise Ratio）環境でさえ、確実に検出されるべきである。発見信号が周期的に送信されるのを許容するために、発見信号のためのリソースが割り当てられるべきである。
二種類のＰｒｏＳｅ直接発見がある：無制限および制限付。無制限は、発見されているＵＥから明示的な許可が必要とされない場合である一方で、制限付発見は、発見されているＵＥからの明示的な許可を伴ってのみ生じる。
ＰｒｏＳｅ直接発見は、例えば発見されるＵＥからの情報を、この情報、例えば「近くでタクシーを見つけて」、「私にコーヒー店を見つけて」を使用するのを許可されるＵＥにおける一定のアプリケーションのために使用することがありえるスタンドアロンサービスを可能にすることであることができる。付加的に、得られた情報に応じて、ＰｒｏＳｅ直接発見は、例えばＰｒｏＳｅ直接通信を開始する後続の行動のために使用されることができる。
ＰｒｏＳｅ直接発見のための以下のモデルが、参照により本明細書に援用される非特許文献７の５．３節およびそのすべての項に規定される。
モデルＡ（「私はここにいます」）：
このモデルは、ＰｒｏＳｅ直接発見に関与しているＰｒｏＳｅ対応ＵＥのための２つの役割を規定する。
− アナウンスＵＥ（Announcing UE）：ＵＥは、発見する許可を有する近接のＵＥによって使用されることがありえる一定の情報をアナウンスする。
− モニタリングＵＥ（Monitoring UE）：アナウンスＵＥの近接の関心を引く一定の情報をモニタリングするＵＥ。
このモデルでは、アナウンスＵＥは所定の発見間隔で発見メッセージをブロードキャストし、これらのメッセージに関心があるモニタリングＵＥはそれらを読み、それらを処理する。このモデルは、アナウンスＵＥがそれ自体についての情報、例えばそのＰｒｏＳｅアプリケーションコードを発見メッセージでブロードキャストすることになるので、「私はここにいます」と称されてもよい。
モデルＢ（「誰がそこにいますか？」／「あなたはそこにいますか？」）：
このモデルは、ＰｒｏＳｅ直接発見に関与しているＰｒｏＳｅ対応ＵＥのための２つの役割を規定する。
− 発見者ＵＥ（Discoverer UE）：ＵＥは、それが何を発見することに関心があるかについての一定の情報を含む要求を送信する。
− 被発見者ＵＥ：要求メッセージを受信するＵＥは、発見者の要求に関連した何らかの情報で応答することができる。
それは、発見者ＵＥが応答を受信することを望む他のＵＥに対する情報を送信する、例えば、情報がグループに対応するＰｒｏＳｅアプリケーション識別情報についてであることができ、かつグループのメンバーが応答することができるので、「誰がそこにいますか／あなたはそこにいますか」と称されることができる。
発見情報の内容はアクセス層（ＡＳ：Access Stratum）にとって透過的であり、ＡＳではＰｒｏＳｅ直接発見モデルおよびＰｒｏＳｅ直接発見の種類に関して区別はなされない。ＰｒｏＳｅプロトコルは、それが、アナウンスの場合、有効な発見情報のみをＡＳに送出することを保証する。
ＵＥは、ｅＮＢ構成に従ってＲＲＣ＿ＩＤＬＥおよびＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態の両方で発見情報のアナウンスおよびモニタリングに関与することができる。ＵＥは、半二重制約を条件としてその発見情報をアナウンスおよびモニタリングする。
概して、デバイス発見は周期的に必要とされる。さらに、Ｄ２Ｄデバイスは、発見メッセージシグナリングプロトコルを利用してデバイス発見を行う。例えば、Ｄ２Ｄ対応ＵＥがその発見メッセージを送信することができ、別のＤ２Ｄ対応ＵＥがこの発見メッセージを受信し、その情報を使用して直接通信リンクを確立することができる。ハイブリッドネットワークの利点は、Ｄ２Ｄデバイスがネットワークインフラの通信距離にもあれば、ｅＮＢのようなネットワークエンティティが発見メッセージの送信または設定を付加的に支援することができるということである。発見メッセージの送信または設定でのｅＮＢによる協調／制御も、Ｄ２ＤメッセージングがｅＮＢによって制御されるセルラトラヒックとの干渉を引き起こさないことを保証するために重要である。付加的に、たとえデバイスのいくつかがネットワークカバレッジ範囲の外であるとしても、カバレッジ内デバイスがアドホック発見プロトコルを支援することができる。
少なくとも以下の二種類の発見手順が、記載にさらに使用される専門用語定義の目的で規定される。
− ＵＥ自律リソース選択（以降１型と呼ばれる）：発見情報をアナウンスするためのリソースが非ＵＥ特定ベースで割り当てられるリソース割当て手順であり、以下によってさらに特徴付けられる。
−− ｅＮＢは、発見情報のアナウンスのために使用されるリソースプール設定をＵＥに提供する。設定は例えばＳＩＢでシグナリングされてもよい。
−− ＵＥは、示されたリソースプールから無線リソースを自律的に選択し、発見情報をアナウンスする。
−− ＵＥは、各発見期間の間、ランダムに選択された発見リソースで発見情報をアナウンスすることができる。
−スケジュールリソース割当て（以降２型と呼ばれる）：発見情報をアナウンスするためのリソースがＵＥ特定ベースで割り当てられるリソース割当て手順であり、以下によってさらに特徴付けられる。
−− ＲＲＣ＿ＣＯＮＮＥＣＴＥＤのＵＥは、ＲＲＣを介してｅＮＢに発見情報のアナウンスのためのリソースを要求してもよい。ｅＮＢはＲＲＣを介してリソースを割り当てる。
−− リソースは、モニタリングのためにＵＥに設定されるリソースプール内で割り当てられる。
ＲＲＣ＿ＩＤＬＥのＵＥに対して、ｅＮＢは以下のオプションの１つを選択してもよい。
− ｅＮＢは、発見情報アナウンスのための１型リソースプールをＳＩＢで提供してもよい。ＰｒｏＳｅ直接発見に許可されているＵＥが、これらのリソースを、ＲＲＣ＿ＩＤＬＥで発見情報をアナウンスするために使用する。
− ｅＮＢは、それがＤ２Ｄをサポートするが、しかし発見情報アナウンスのためのリソースは提供しないことをＳＩＢで示してもよい。ＵＥは、発見情報アナウンスのためのＤ２Ｄリソースを要求するためにＲＲＣ Ｃｏｎｎｅｃｔｅｄに入る必要がある。
ＲＲＣ＿ＣＯＮＮＥＣＴＥＤのＵＥに対して：
− ＰｒｏＳｅ直接発見アナウンスを行う許可を与えられているＵＥが、それがＤ２Ｄ発見アナウンスを行いたいことをｅＮＢに示す。
− ｅＮＢは、ＭＭＥから受信されるＵＥコンテキストを使用して、ＵＥがＰｒｏＳｅ直接発見アナウンスに許可されているかどうかを確認する。
− ｅＮＢは、個別ＲＲＣシグナリングを介して、発見情報アナウンスのために１型リソースプールまたは個別２型リソースを使用するようにＵＥを構成してもよい（またはリソースなし）。
− ｅＮＢによって割り当てられるリソースは、ａ）ｅＮＢがＲＲＣシグナリングによってリソースを構成解除する、またはｂ）ＵＥがＩＤＬＥに入るまで有効である。
ＲＲＣ＿ＩＤＬＥおよびＲＲＣ＿ＣＯＮＮＥＣＴＥＤの受信ＵＥが、許可されるように、１型および２型発見リソースプール両方をモニタリングする。ｅＮＢは、発見情報モニタリングのために使用されるリソースプール設定をＳＩＢで提供する。ＳＩＢは、隣接セルでのアナウンスのために使用される発見リソースも含んでもよい。
＜Ｄ２Ｄ（サイドリンク）論理チャネルのためのＬＣＰ手順＞
Ｄ２ＤのためのＬＣＰ手順は、「通常の」ＬＴＥデータのための以上提示したＬＣＰ手順とは異なることになる。以下の情報は、非特許文献２の、ＰｒｏＳｅのためのＬＣＰを記載する５．１４．１．３．１項から取られており、それは参照によりその全体が本明細書に援用される。
すべてのＤ２Ｄ（サイドリンク）論理チャネル、例えばＳＴＣＨ（Sidelink Traffic CHannel：サイドリンクトラヒックチャネル）が、ＬＣＧＩＤが「１１」に設定される同じ論理チャネルグループ（ＬＣＧ）に割り当てられる（非特許文献２の５．１４．１．４項「Buffer Status Reporting」を参照のこと）。Ｒｅｌ−１２では、Ｄ２Ｄ（サイドリンク）論理チャネル／グループのための優先順位付けメカニズムはない。本質的に、すべてのサイドリンク論理チャネルはＵＥの観点から同じ優先度を有し、すなわちサイドリンク論理チャネルが扱われる順序はＵＥ実装次第である。
＜ＰｒｏＳｅ ＵＥ−ネットワークリレー（ＵＥ−ｔｏ−Ｎｅｔｗｒｏｋ Ｒｅｌａｙ）＞
ＵＥはまた、ＰｒｏＳｅ ＵＥ−ネットワークリレーとして作用して、その結果リモートＵＥがＰＣ５基準点を通じてＰｒｏＳｅ ＵＥ−ネットワークリレーと通信するように、機能性および手順をサポートしてもよい。ＰｒｏＳｅ ＵＥ−ネットワークリレー動作は、３ＧＰＰ Ｒｅｌｅａｓｅ１３内で明記されるであろう。ここまで、初期取決めのみが３ＧＰＰ ＲＡＮ作業グループでなされてきたが、そのいくつかが、例えば、参照により本明細書に援用される非特許文献７および非特許文献８から理解されることができる。それらの取決めのいくつかが以下列記されることになる。しかしながら、この作業項目がごく最近導入され、したがって依然標準化の最中であることに留意するべきである。結果的に、以下に前提とされるいかなる取決めも依然変更または破棄される可能性があり、考察目的で前提とされる以下の取決めは、しかしながら、標準化のこの非常に初期段階で本開示をこの特定の３ＧＰＰ実装に限定するとは理解されないものとする。
− ＰｒｏＳｅ ＵＥ−ネットワークリレー発見およびＰｒｏＳｅリレー（再）選択に関して、リモートＵＥがカバレッジ内およびカバレッジ外である両シナリオが対処されることができる。
− リレーＵＥは常にカバレッジ内であろう。ｅＮＢが無線レベルで、ＵＥがリレーとして作用することができるかどうかを制御することができる一方で、ネットワーク制御がリレーＵＥごと、セル（ブロードキャスト設定）ごと、もしくは両方、または何か他のことであるかどうかは依然未決定である。
− リモートＵＥがリレー発見目的でカバレッジ内であるとき、発見のためのモニタリングおよび送信リソースは、例えばＲｅｌ−１２メカニズム（アイドルモード用のブロードキャストおよび接続モード用の個別シグナリング）を使用してｅＮＢによって提供されることができる。リモートＵＥは、いつモニタリングを開始するべきかを決定することができる。
− リモートＵＥがカバレッジ外であるとき、発見および通信（実際のデータ転送）のためのモニタリングおよび送信リソースは、例えば、ＵＥがどのリソースを使用するべきかを正確に知るように、事前設定によって、すなわち仕様／オペレータ設定（ＵＳＩＭでなど）を通じて提供されることができる。
ＰｒｏＳｅ ＵＥ−ネットワークリレー（再）選択：
− リモートＵＥは、ＰｒｏＳｅ ＵＥ−ネットワークリレー選択手順に対して、ＰＣ５無線リンク品質の無線レベル測定値を考慮に入れることができる。
− リモートＵＥがカバレッジ外である場合に関して、無線レベル測定値は、他の上位レイヤ判定基準と共にリモートＵＥによって使用されてリレー選択を行うことができる。
− リモートＵＥがカバレッジ外である場合に関して、再選択のための判定基準は、ＰＣ５測定値（ＲＳＲＰまたは他のＲＡＮ１約定測定値）および上位レイヤ判定基準に基づく。リレー再選択はリモートＵＥによってトリガされることができる。
− リモートＵＥがカバレッジ内である場合に関して、これらの測定値（ＰＣ５測定値）が使用されるかどうか、およびどのように使用されるかはまだ決定されていない（例えば、測定値はＵＥによって使用されてカバレッジ外の場合と同様の選択を行うことができる、またはそれらはｅＮＢに報告されることができる）。
ＰｒｏＳｅ ＵＥ−ネットワークリレーはレイヤ３パケット転送を使用してもよい。ＰｒｏＳｅ ＵＥ間の制御情報が、例えばＵＥ−ネットワークリレー検出およびＰｒｏＳｅ直接発見のために、ＰＣ５基準点を通じて交換されることができる。
ＰｒｏＳｅ対応ＵＥがまた、ＰＣ３基準点を通じた別のＰｒｏＳｅ対応ＵＥとＰｒｏＳｅ機能との間のＰｒｏＳｅ制御情報の交換をサポートするであろう。ＰｒｏＳｅ ＵＥ−ネットワークリレーの場合には、リモートＵＥはＰＣ５ユーザプレーンを通じてこの制御情報を送信し、ＰｒｏＳｅ機能に向けてＬＴＥ−Ｕｕインタフェースを通じて中継されることになる。
ＰｒｏＳｅ ＵＥ−ネットワークリレーエンティティは、ｅＮＢのカバレッジ範囲内でない、すなわちＥ−ＵＴＲＡＮに接続されていないリモートＵＥに、「ユニキャスト」サービスへの接続性をサポートする機能性を提供する。図９は、ＰｒｏＳｅ ＵＥ−ネットワークリレーシナリオを示す。ＰｒｏＳｅ ＵＥ−ネットワークリレーは、リモートＵＥとネットワークとの間のユニキャストトラヒック（ＵＬおよび／またはＤＬ）を中継するものとする。ＰｒｏＳｅ ＵＥ−ネットワークリレーは、公衆安全通信に関連するいかなる種類のトラヒックも中継することができる一般的な機能を提供するものとする。
リモートＵＥとＰｒｏＳｅ ＵＥ−ネットワークリレーとの間の１対１直接通信は以下の特性を有する。
− ＰＣ５基準点を通じた通信はコネクションレスである。
− ＰｒｏＳｅベアラは双方向である。所与のＰｒｏＳｅベアラ上の無線レイヤに渡されるＩＰパケットは、関連するＬ２宛先アドレスを持つ物理レイヤによって送信されるであろう。同じＰｒｏＳｅベアラ上の無線レイヤから上方へ渡されるＩＰパケットは、同じＬ２宛先にアドレス指定される無線で受信されるであろう。
ＰｒｏＳｅ ＵＥ−ネットワークリレーは以下の機能を含んでもよい。
− モデルＡまたはモデルＢに従うＰｒｏＳｅ直接発見は、リモートＵＥが近接のＰｒｏＳｅ ＵＥ−ネットワークリレーを発見するのを許容するために使用されることができる。
− ＰｒｏＳｅ ＵＥ−ネットワークリレーのＬ２アドレスがＰｒｏＳｅ ＵＥ−ネットワークリレーによってサポートされる特定のＰＤＮ接続に対応するＩＰアドレス割当ておよびユーザプレーントラヒックのためにリモートＵＥによって使用されるのをリモートＵＥが発見するのを許容するために使用されることができるＰｒｏＳｅ直接発見。
− 直接発見をサポートするＰＣ５基準点上の「アナウンス」または「被発見者」ＵＥとして作用する。
−ＵＥ−ＰｒｏＳｅ ＵＥ−ネットワークリレーポイントツーポイントリンクと対応するＰＤＮ接続との間でＩＰパケットを転送する、リモートＵＥに対するデフォルトルータとして作用する。
− ＩＥＴＦ ＲＦＣ４８６１に規定されるルータ要請およびルータ広告メッセージを取り扱う。
− ＤＨＣＰｖ４サーバおよびステートレスＤＨＣＰｖ６リレーエージェントとして作用する。
− ＩＰｖ４が使用される場合ＮＡＴとして作用し、リモートＵＥのローカルに割り当てられたＩＰｖ４アドレスをそれ自体のものに置き換える。
− 宛先レイヤ２ＩＤとしてリモートＵＥによって使用されるＬ２リンクＩＤを、ＰｒｏＳｅ ＵＥ−ネットワークリレーによってサポートされる対応ＰＤＮ接続にマッピングする。
ＰｒｏＳｅ ＵＥ−ネットワークリレーのためのユーザプレーンプロトコルアーキテクチャが図１０に示される。
２つのＰｒｏＳｅ ＵＥ間の通例のＲｅｌ．−１２直接発見に関して上述したように、モデルＡおよびモデルＢ発見の両方がサポートされ、ここでモデルＡは単一の発見プロトコルメッセージ（ＵＥ−ネットワークリレー発見アナウンス）を使用し、モデルＢは２つの発見プロトコルメッセージ（ＵＥ−ネットワークリレー発見要請およびＵＥ−ネットワークリレー発見応答）を使用する。リレー発見に関する詳細は、参照により本明細書に援用される非特許文献８の６節に見られることができる。
ＰｒｏＳｅ ＵＥ対ネットワークリレー発見
２つのＰｒｏＳｅ ＵＥ間の通例のＲｅｌ．−１２直接発見に関して上論したように、モデルＡおよびモデルＢの両発見がサポートされ、ここでモデルＡは単一の発見プロトコルメッセージ（ＵＥ対ネットワークリレー発見アナウンス）を使用し、モデルＢは２つの発見プロトコルメッセージ（ＵＥ対ネットワークリレー発見要請およびＵＥ対ネットワークリレー発見応答）を使用する。リレー発見に関する詳細は、参照により本明細書に援用される非特許文献８の６節に見られることができる。
以下のパラメータは、ＵＥ対ネットワークリレー発見、グループメンバー発見およびＵＥ対ＵＥリレー発見のすべてに共通である。
− メッセージ型：アナウンス（モデルＡ）または要請／応答（モデルＢ）、リレー発見追加情報（モデルＡ）。
− 発見型：これがＵＥ対ネットワークリレー発見であるか、グループメンバー発見であるか、またはＵＥ対ＵＥリレー発見であるかを示す。
以下のパラメータは、ＵＥ対ネットワークリレー発見アナウンスメッセージ（モデルＡ）に使用される。
− ＰｒｏＳｅリレーＵＥ ＩＤ：直接通信のために使用され、かつＰｒｏＳｅ ＵＥ対ネットワークリレーが確立したＰＤＮ接続と関連づけられるリンクレイヤ識別子。
− アナウンサｉｎｆｏ：アナウンスユーザについての情報を提供する。
− リレーサービスコード：ＰｒｏＳｅ ＵＥ対ネットワークリレーが公共安全アプリケーションに提供する接続サービスを識別するパラメータ。リレーサービスコードは、それらが接続を提供する特定のＡＰＮに対するＰｒｏＳｅ ＵＥ対ネットワークリレーにおける広告およびマップのためにＰｒｏＳｅ ＵＥ対ネットワークリレーに設定される。付加的に、リレーサービスコードは、ＰｒｏＳｅ ＵＥ対ネットワークリレーがサービスを提供するであろう許可ユーザも識別し、例えばリモートＵＥとＰｒｏＳｅ ＵＥ対ネットワークリレーとの間の認証および許可のために必要な関連したセキュリティポリシーまたは情報を選択してもよい（例えば、警察メンバーのみに対するリレーのためのリレーサービスコードは、消防士のみに対するリレーのためのリレーサービスコードとは異なるものであり、たとえ可能性として両方とも、例えばインターネットアクセスをサポートするために同じＡＰＮに接続を提供したとしてもである）。
− 無線レイヤ情報：リモートＵＥが適当なＵＥ対ネットワークリレーを選択するのを支援するために、無線レイヤ情報、例えばｅＮＢとＵＥ対ネットワークリレーとの間の無線状態についての情報を含む。
以下のパラメータは、ＵＥ対ネットワークリレー発見要請メッセージ（モデルＢ）に使用される。
− 発見者ｉｎｆｏ：発見者ユーザについての情報を提供する。
− リレーサービスコード：発見者ＵＥが関心がある接続についての情報。リレーサービスコードは、関連した接続サービスに関心があるＰｒｏＳｅリモートＵＥに設定される。
− ＰｒｏＳｅ ＵＥ ＩＤ：直接通信（モデルＢ）のために使用される発見者のリンクレイヤ識別子。
以下のパラメータは、ＵＥ対ネットワークリレー発見応答メッセージ（モデルＢ）に使用される。
− ＰｒｏＳｅリレーＵＥ ＩＤ：直接通信のために使用され、かつＰｒｏＳｅ ＵＥ対ネットワークリレーが確立したＰＤＮ接続と関連づけられるリンクレイヤ識別子。
− 被発見者ｉｎｆｏ：被発見者についての情報を提供する。
− 無線レイヤ情報：リモートＵＥが適当なＵＥ対ネットワークリレーを選択するのを支援するために、無線レイヤ情報、例えばｅＮＢとＵＥ対ネットワークリレーとの間の無線状態についての情報を含む。
＜ＰｒｏＳｅ ＵＥ−ネットワークリレーを介するＰｒｏＳｅ方向通信＞
ＵＥ−ネットワークリレー機能は、上述した非特許文献７に既に文書化されたＰｒｏＳｅ機能性の進化に基づいて明記されることになる。
ＰｒｏＳｅ ＵＥ−ネットワークリレー可能ＵＥがネットワークにアタッチし（それが既に接続されていない場合）、必要なリレートラヒックを可能にするＰＤＮ接続に接続してもよく、またはそれは、リモートＵＥに向けてリレートラヒックを提供するために追加のＰＤＮ接続に接続する必要があってもよい。ＵＥ−ネットワークリレーをサポートするＰＤＮ接続は、リモートＰｒｏＳｅ ＵＥリレートラヒックのためにのみ使用されるものとする。
ＰｒｏＳｅ ＵＥ対ネットワークリレーは、リモートＵＥとネットワークとの間のいかなる種類のＩＰトラヒックも中継することができる一般的なＬ３転送機能を提供する。１対１ＰｒｏＳｅ直接通信は、リモートＵＥとＰｒｏＳｅ ＵＥ対ネットワークリレーとの間で使用される。リモートＵＥは、上位のレイヤによって許可され、ＵＥ対ネットワークリレー発見、選択および通信に関してＥＵＴＲＡＮのカバレッジ内またはカバレッジ外であることができる。ＰｒｏＳｅ ＵＥ対ネットワークリレーＵＥは常にＥＵＴＲＡＮのカバレッジ内である。
ｅＮＢは、ＵＥがＰｒｏＳｅ ＵＥ対ネットワークリレーとして機能することができるかどうかを制御する。
− ｅＮＢがＰｒｏＳｅ ＵＥ対ネットワークリレー動作に関連づけられる何らかの情報をブロードキャストすれば、ＰｒｏＳｅ ＵＥ対ネットワークリレー動作がセルでサポートされる。
− ｅＮＢは、ＰｒｏＳｅ ＵＥ対ネットワークリレー動作がサポートされることを示してもよく、ＰｒｏＳｅ ＵＥ対ネットワークリレー発見のための送信および受信リソースプールをブロードキャストシグナリングで提供してもよい。
− ｅＮＢは、ＰｒｏＳｅ ＵＥ対ネットワークリレーＵＥがブロードキャストされた閾値を使用してＵＥ対ネットワークリレー発見手順を自律的に開始／停止するために尊重する必要がある最低および／または最高Ｕｕリンク品質（ＲＳＲＰ／ＲＳＲＱ）閾値をブロードキャストしてもよい。ｅＮＢは、閾値のいずれも設定しなくても、その一方でも、または両閾値を設定してもよい。
− ｅＮＢが、ＰｒｏＳｅ ＵＥ対ネットワークリレー動作がサポートされるとブロードキャストするが、しかしＰｒｏＳｅ ＵＥ対ネットワークリレー発見のための送信リソースプールをブロードキャストしなければ、ＵＥは個別シグナリングによってＰｒｏＳｅ ＵＥ対ネットワークリレー発見リソースの要求を開始することができる。ｅＮＢは、個別シグナリングによって、ＵＥをＰｒｏＳｅ ＵＥ対ネットワークリレーになるように構成してもよい。
− ｅＮＢが、ＵＥが送信リレー発見リソースを要求する前に尊重する必要がある最低および／または最高Ｕｕリンク品質（ＲＳＲＰ／ＲＳＲＱ）閾値を任意選択でブロードキャストすることができるかどうか、ならびにモデルＡとモデルＢとの間の行動の区別が必要とされるかどうかがまだ明らかでないことに留意すべきである。
− ＰｒｏＳｅ ＵＥ対ネットワークリレーがブロードキャストシグナリングによって開始される場合、それは、ＲＲＣ＿ＩＤＬＥであるときにＰｒｏＳｅ ＵＥ対ネットワークリレー発見を行うことができる。ＰｒｏＳｅ ＵＥ対ネットワークリレーが個別シグナリングによって開始される場合、それは、自身がＲＲＣ＿ＣＯＮＮＥＣＴＥＤである間リレー発見を行うことができる。
プールが中継動作のためのみであるか、または他のＰＳ発見サービスのためでもあるか、ならびにプールがＰｒｏＳｅ ＵＥ対ネットワークリレーのみによって使用されることができるか、またはＰｒｏＳｅ ＵＥ対ネットワークリレーおよびリモートＵＥの両方によって使用されることができるかがまだ明らかでないことに留意すべきである。
ｅＮＢがリレー発見リソースをブロードキャストしている場合、それがＵＥを個別で制御することができるかどうか、および接続モードのＵＥがブロードキャストされたリレー発見リソースを使用することができるかどうかがまだ明らかでないことに留意すべきである。
ＵＥがカバレッジ内からカバレッジ外へ、およびカバレッジ外からカバレッジ内へ移動している場合に関して、サービス中断の潜在的な最小化が何であるかはまだ明らかでないことに留意すべきである。
１対１サイドリンク通信を行うＵＥ対ネットワークリレーはＲＲＣ＿ＣＯＮＮＥＣＴＥＤでなければならない。リモートＵＥからレイヤ２リンク確立要求（上位のレイヤメッセージ）を受信した後に、ＰｒｏＳｅ ＵＥ対ネットワークリレーは、それがＰｒｏＳｅ ＵＥ対ネットワークリレー１対１通信を行うつもりであることをｅＮＢに示す。ｅＮＢは、ＰｒｏＳｅ ＵＥ対ネットワークリレー１対１通信のためのリソースを提供してもよい。
リモートＵＥは、ＰＣ５インタフェースで無線測定を行い、それを上位レイヤ判定基準と共にＰｒｏＳｅ ＵＥ対ネットワークリレー選択および再選択のために使用する。ＰｒｏＳｅ ＵＥ対ネットワークリレーは、ＰＣ５リンク品質が（予め設定される、またはｅＮＢによって提供される）設定閾値を超えれば、無線判定基準の点で適切であると考えられる。リモートＵＥはまた、それがＰｒｏＳｅ ＵＥ対ネットワークリレーからレイヤ２リンク解除メッセージ（上位のレイヤメッセージ）を受信すると、ＰｒｏＳｅ ＵＥ対ネットワークリレー再選択をトリガしてもよい。ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態では、ＰｒｏＳｅ ＵＥ対ネットワークリレーを選択した後に、リモートＵＥは、それがＰｒｏＳｅ ＵＥ対ネットワークリレー１対１通信を使用するつもりであることをｅＮＢに通知する。ｅＮＢは、ＰｒｏＳｅ ＵＥ対ネットワークリレー１対１通信のためのリソースを提供してもよい。
Ｕｕリンク品質が選択／再選択目的で必要とされるかどうかはまだ決定されていない。さらに、新たなＰｒｏＳｅ ＵＥ対ネットワークリレーを選択する詳細な判定基準およびＰｒｏＳｅ ＵＥ対ネットワークリレーの順位付けも決定されていない。
リモートＵＥがカバレッジ内であるとき、
− ＰｒｏＳｅ ＵＥ対ネットワークリレー発見のための送信リソースは、ＲＲＣ＿ＩＤＬＥ状態に対してブロードキャストおよびＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態に対して個別シグナリングを使用してｅＮＢによって提供される。
− ＰｒｏＳｅ ＵＥ対ネットワークリレー発見のためのモニタリングリソースは、ブロードキャストシグナリングを使用してｅＮＢによって提供される。
リモートＵＥは、いつＰｒｏＳｅ ＵＥ対ネットワークリレー発見のためにモニタリングを開始するべきかを決定することができる。リモートＵＥは、ＰｒｏＳｅ ＵＥ対ネットワークリレー発見のためのリソースの設定に応じてＲＲＣ＿ＩＤＬＥである、またはＲＲＣ＿ＣＯＮＮＥＣＴＥＤである間、ＰｒｏＳｅ ＵＥ対ネットワークリレー発見要請メッセージを送信することができる。ｅＮＢは、閾値をリモートＵＥからのＰｒｏＳｅ ＵＥ対ネットワークリレー発見要請メッセージの送信を制御するように設定してもよい。閾値が設定されれば、リモートＵＥは、リモートＵＥでのＵｕリンク品質が設定された閾値を下回る場合だけＰｒｏＳｅ ＵＥ対ネットワークリレー発見要請メッセージを送信するのを許容される。
ＰｒｏＳｅのためのＱｏＳサポート
Ｒｅｌ−１３では、ＱｏＳは一般にＰｒｏＳｅ一対多通信のためにサポートされる。その理由で、例えば非特許文献７で、いわゆるＰｒｏＳｅパケット単位優先度（ＰＰＰＰ：ProSe Per-Packet Priority）が導入された。ＰｒｏＳｅパケット単位優先度は、プロトコルデータユニット、例えばＩＰパケットの送信のために適用されることになる優先度処理、すなわちＰＣ５インタフェース上の送信に対する優先度処理を規定される、そのプロトコルデータユニットと関連づけられるスカラー値である。言い換えると、ＰｒｏＳｅ ＰＰＰは、ＰｒｏＳｅ ＵＥ対ＵＥのため、およびＰｒｏＳｅリレーのためも含むＰｒｏＳｅ直接通信を使用するときにパケットの優先順位付けを許容するために使用されるメカニズムである。
ＰｒｏＳｅ上位レイヤ（すなわちＰＣ５アクセス層より上）がＰＣ５アクセス層に送信のためのプロトコルデータユニットを渡すとき、ＰｒｏＳｅ上位レイヤは、８つの可能な値の範囲からＰｒｏＳｅパケット単位優先度を提供する。
ＰｒｏＳｅパケット単位優先度は宛先レイヤ２ＩＤから独立し、１対１および一対多の両ＰｒｏＳｅ直接通信に当てはまる。ＰｒｏＳｅパケット単位優先度は、例えば（音声パケット伝送のようなサービスまたはフロア制御関連シグナリングのような制御シグナリングの遅延要件など）本明細書の範囲外である様々な判定基準に基づいてアプリケーションレイヤによって選択される。
ＰｒｏＳｅパケット単位優先度は、ＵＥが媒体にアクセスするモード、すなわちＰｒｏＳｅ通信のためのスケジュールかまたは自律かいずれのリソース割当てモードが使用されるかから独立している。ＰｒｏＳｅアクセス層は、上位のレイヤから受信されるプロトコルデータユニットと関連づけられるＰｒｏＳｅパケット単位優先度を使用して、他のＵＥ内送信（すなわち同じＵＥ内で送信を待っている、異なる優先度と関連づけられるプロトコルデータユニット）およびＵＥ間送信（すなわち異なるＵＥ内で送信を待っている、異なる優先度と関連づけられるプロトコルデータユニット）に関して送信に優先順位付けする。
優先度付き待ち行列（ＵＥ内およびＵＥ間の両方）は厳密な優先度順に扱われるのを予期され、すなわちＵＥまたはｅＮＢは、優先度Ｎ＋１と関連づけられるパケットを扱う前にＰｒｏＳｅパケット単位優先度Ｎと関連づけられるすべてのパケットを扱う（より低い番号がより高い優先度を意味する）。
ＰＣ５インタフェースそのものへの優先度処理は非特許文献２、すなわち論理チャネル優先順位付け（ＬＣＰ）手順に明記されることになる。たとえすべての詳細がまだ決定されているわけではないとしても、各サイドリンク論理チャネルに対して、例えばレガシーＬＴＥ ＵＬ動作の論理チャネル優先度と同様の関連する優先度がおそらくあることになる。論理チャネルの作成は、Ｒｅｌ−１２と同様、ＵＥ実装次第であろう。論理チャネルを作成するときにパケットのソース／宛先ＩＤを考慮することに加えて、ＵＥはパケットの優先度も考慮することになる。本質的に、同じＰＰＰＰ値（および何らかのソース／宛先ＩＤ）を有するプロトコルデータユニットは、ある関連する論理チャネル優先度を持つ１つのサイドリンク論理チャネルによって扱われることになる。ＰＰＰＰと論理チャネル優先度との間の詳細な関係／マッピングはまだ決定されておらず、標準化においてさらに論じられることになる。
論理チャネル優先順位付け手順の間、ＵＥがＳＬグラントを受信すると、ＵＥは、ＳＬデータを有するサイドリンク論理チャネルの中で最高のＰＰＰＰを持つサイドリンク論理チャネルを有するＰｒｏＳｅグループを選択し、次いで選択したＰｒｏＳｅ宛先グループに帰属するすべてのサイドリンク論理チャネルを優先度降順に扱う。
ＰｒｏＳｅ ＵＥ対ネットワークリレーのためのＱｏＳサポート
リモートＵＥがＰｒｏＳｅ ＵＥ対ネットワークリレーを介してＰＤＮと通信しているＰｒｏＳｅ ＵＥ対ネットワークリレーシナリオに関して、ＱｏＳに備えるためのさらなる具体的な態様がある。ＰＰＰがリモートＵＥとリレーＵＥとの間でのみ適用可能である一方、通例の優先順位付けメカニズム（ＱＣＩ、ＥＰＳベアラ）が残りの部分で使用されることができ、図１０は、ネットワークにおける異なる優先順位付けメカニズムを例示する。一定の優先度、すなわちＰＰＰＰでＰＣ５インタフェース上で扱われるデータパケットは、ｅＮＢとＰｒｏＳｅリレーＵＥとの間のＵｕインタフェースより優先される必要もある。これはアップリンクおよびダウンリンクの両送信に当てはまる。たとえすべての詳細が標準化のこの段階で明らかであるわけではないとしても、以下は現在共通の前提である。
− アップリンク：ＰｒｏＳｅ ＵＥ−ネットワークリレーＵＥは、アップリンクＴＦＴ（traffic flow template：トラヒックフローテンプレート）を使用して、ＰＣ５インタフェースを通じて適用されるＰｒｏＳｅパケット単位優先度（ＰＰＰＰ）と独立して、中継されるアップリンクパケットのためのアップリンクＥＰＳベアラを選択する。
− ダウンリンク：ＰｒｏＳｅ ＵＥ−ネットワークリレーＵＥは、ＥＰＳベアラＱｏＳパラメータを、ＰＣ５を通じたダウンリンク中継ユニキャストパケットに適用されることになるＰｒｏＳｅパケット単位優先度（ＰＰＰＰ）値にマッピングする。アップリンク送信のためのＰｒｏＳｅパケット単位優先度とＥＰＳベアラＩＤまたはＩＰ５タプルとの間のマッピングに基づいて、適切なマッピング規則がリレーＵＥにおいて決定されてもよい。
リレーは、ｅＮＢへのアップリンクで適当なＱｏＳを選択することができるためにサイドリンク上の着信パケットのＰＰＰを知る必要がある。これを達成するために、各ユーザプレーンＰＤＣＰ ＰＤＵは関連するＰＰＰＰ情報を、すなわちＰＤＣＰヘッダに含むものとする。リレーＵＥは、ＳＬＲＢ（Sidelink Radio Bearer：サイドリンク無線ベアラ）でリモートＵＥから受信されるＰＤＣＰパケットのＰＰＰＰとそれがＵＬ ＴＦＴに基づいてマッピングされることになるＵｕベアラとの間のマッピングを記憶しなければならない。
上述したように、ＵＥ対ネットワークリレーシナリオのためのＱｏＳをサポートするために、リレーＵＥは、Ｕｕインタフェースに渡って使用されるベアラのＱｏＳパラメータ（例えばＱＣＩ値）からＰＣ５インタフェースに渡って使用されるＰｒｏＳｅ ＰＰＰ値へダウンリンク方向にマッピングを行う。これは、基本的にリレーＵＥとＰＧＷとの間の適切な個別ベアラの確立を必要とする。図１１は、これを達成する１つの例証的な手順を描く。
１．リモートＵＥがリレーＵＥを発見し、それら間のＰｒｏＳｅ Ｄ２Ｄ接続がＰＣ５を通じて確立される。（リモートＵＥはステップの結果としてＩＰアドレス／プレフィックスを受信する。）
２．リレーＵＥがリレートラヒックのためのＰＤＮ接続を確立する。
注：ステップ１および２の順序は規定されていない。
３．シグナリングのための個別ベアラが作成される。これは、何らかのアプリケーションレベルシグナリング（例えばリモートＵＥからの登録要求）を受信した後にＧＣＳ−ＡＳ（ステップ３ａおよびステップ３ｂ）によってトリガされることがあり、またはシグナリングのための個別ベアラの作成をトリガするデフォルトＰＣＣ規則があることができる。
４．リモートＵＥが、アプリケーションレベルシグナリングを使用してアプリケーションレベルグループに加わる。シグナリングベアラはこのトラヒックのために使用されることができる。
５．ある時点で、ＧＣＳ−ＡＳが、メディアベアラが必要とされることをＰＣＲＦに示す。
注：ＭＣＰＴＴの場合には、ＰＣＲＦを制御するのがＭＣＰＴＴ−ＡＳであるかＩＭＳ（Ｐ−ＣＳＣＦ）であるかはＳＡ６に依存する。この決定は描かれる手順の原理を変化させない。
６．ＰＣＲＦがＩＰＣＡＮセッション変更を開始する。それはメディアベアラのための詳細（ＴＦＴ、ＱＣＩ、ＢＷ）を提供する。
７．メディアトラヒックのための個別ベアラが作成されるか、または同じＱＣＩを持つベアラが存在すれば、現存のものが変更される（ＢＷパラメータが変更される）。
８．メディアトラヒックが、メディアのために作成される個別ベアラを通じてルーティングされる。アップリンクパケットの場合、リモートＵＥは（アプリケーションレベルで）ＰＣ５を通じてＰｒｏＳｅ ＰＰＰを設定し、次いで、リレーＵＥはアップリンクＴＦＴに基づいて適切なＥＰＳベアラを使用する。ダウンリンクパケットの場合、ＰＧＷはダウンリンクＴＦＴに基づいて適切なＥＰＳベアラを選択し、次いで、リレーＵＥは、パケットのために使用されたＥＰＳベアラのＱＣＩ（および／または他のＱｏＳパラメータ）およびリモートＵＥからリレーＵＥへのアップリンク送信のためのＰＰＰＰとＥＰＳベアラとの間のマッピングｉｎｆｏに基づいて、ＰＣ５を通じてＰｒｏＳｅ ＰＰＰを設定する。
上述したように、第１のアプリケーションレベルシグナリングメッセージは、アプリケーションレベルシグナリングのための個別ベアラがまだ確立されていないため、デフォルトベアラを使用しなければならないことがある。図１２は、対応する例証的なメッセージ交換を開示する。
１．リモートＵＥがリレーＵＥを発見し、それら間のＰｒｏＳｅ Ｄ２Ｄ接続がＰＣ５を通じて確立される。（リモートＵＥはこのステップ内でＩＰアドレス／プレフィックスを受信する。）
２．リモートＵＥが、ＧＣＳ−ＡＳとアプリケーションレベルシグナリングを開始する（例えば登録を開始する）。
３．ＧＣＳ−ＡＳが、シグナリングのための個別ベアラが必要とされると決定する。ＧＣＳ−ＡＳは、ＨＰＬＭＮ＿ＲｅｍｏｔｅにあるＰＣＲＦ２にシグナリングベアラのためのベアラＩｎｆｏを送る。ＰＣＲＦ２は、それをＨＰＬＭＮ＿ＲｅｌａｙにあるＰＣＲＦ１に転送し、リレーＵＥのＩＰＣＡＮセッションを制御する。リモートＵＥのパブリックＩＰアドレスはユーザセッション識別子として使用される。
４．ＰＣＲＦ１は、リモートＵＥのパブリックＩＰアドレスに基づいてリレーＵＥのＩＰＣＡＮセッションを識別する。ＩＰＣＡＮセッション変更はベアラパラメータで行われる。ＱＣＩ、ＢＷおよびＴＦＴはベアラＩｎｆｏから来ている。
５．ＰＧＷが与えられたＱＣＩを持つ個別ベアラを有しなければ、ステップ４で受信したＢＷおよびＴＦＴを使用して与えられたＱＣＩに対してＰＧＷとリレーＵＥとの間に新たな個別ベアラが確立される。ＰＧＷが与えられたＱＣＩを持つ個別ベアラを有すれば、現存の個別ベアラが変更される：ＢＷが更新され、新たなＴＦＴが追加される。
以上説明したように、３ＧＰＰは、主要な作業項目として、リレー発見およびリレー直接通信を含むＰｒｏＳｅリレー機能性を導入する。ＰｒｏＳｅリレーのための現在規定されているメカニズムのいくつかはかなり非効率的である。
3GPP TS 36.211、「Evolved Universal Terrestrial Radio Access (E-UTRA); Physical Channels and Modulation」、version 12.6.9 3GPP TS 36.321、version 12.6.0 3GPP TS 23.203、version 13.4.0 3GPP TR 36.843、version 12.0.1 3GPP TS 36.300、version 13.3.0 3GPP TS 36.212、version 12.4.0 3GPP TS 23.303、version 13.0.0 3GPP TR 23.713、version 1.4.0
非限定的かつ例証的な実施形態が、プロトコルデータユニットを中継するための改善された方法を提供する。独立請求項は非限定的かつ例証的な実施形態を提供する。有利な実施形態は従属請求項に従う。
本明細書に記載するいくつかの態様によれば、リレー可能ユーザ機器のリレー機能性、特にリレーＵＥとリモートＵＥとの間のインタフェースを通じて送信されるプロトコルデータユニットの優先順位付けが改善される。
これらの態様を論ずるために、以下の前提が立てられる。特に、リレーユーザ機器が他のリモートユーザ機器と直接通信を（すなわち直接サイドリンクベアラを介して）行うことが可能であることを前提とする。リモートＵＥと（リレーＵＥが接続される）無線基地局との間の通信が、リモートユーザ機器と確立された直接サイドリンクベアラを介してプロトコルデータユニットを交換することを含むリレーＵＥによって中継される。
第１の態様は、以下に説明することになる、リレーＵＥで行われ、かつリモートＵＥによって支援されるリレー機能性の改善に関する。特に、リレーＵＥは、プロトコルデータユニットをダウンリンクおよびアップリンクの両方向に、すなわち無線基地局から受信されてリモートＵＥに中継されることになるプロトコルデータユニットの他にリモートＵＥから受信されて無線基地局に中継されることになるプロトコルデータユニットを中継しなければならない。さらには、リレー機能性は、プロトコルデータユニットが適切な優先度（例えば送信優先度としてＱｏＳ）で両方向に中継／送信されることを確認しなければならず、すなわちリレーＵＥは、適切な優先度を持つサイドリンクベアラを使用してリモートＵＥにプロトコルデータユニットを転送しなければならず、かつ同様に適切な優先度（例えばＱｏＳ）を持つ無線ベアラを使用して無線基地局にプロトコルデータユニットを転送しなければならない。結果的に、これは、リレーＵＥが、受信したプロトコルデータユニットの優先度に応じて、中継のためにどのサイドリンク／無線ベアラを使用するべきかを知ることを必要にする。アップリンクでは、すなわちリモートＵＥから受信されるプロトコルデータユニットを無線基地局に中継するとき、ベアラ選択は、例えば宛先アドレス、ソースアドレス、ポート番号およびプロトコルデータユニットに存在する他の情報など、転送されることになるプロトコルデータユニット（例えばそのヘッダ）に含まれる情報に基づいてリレーＵＥが適切な無線ベアラを選択するのを許容した特定のパケットフィルタリング規則（ＬＴＥ実装ではトラヒックフローテンプレートとしても知られる）を使用することによって行われる。言い換えると、アップリンクでのベアラ選択は、リモートＵＥとリレーＵＥとの間で実際に使用される優先度と独立して行われるが、但しパケットフィルタリング規則が、例えば高優先度プロトコルデータユニットが同じく高優先度（例えばＱｏＳ属性）を保証する無線基地局に無線ベアラを介して送信されることを保証するように、対応があるべきである。
他方で、ダウンリンクでは、すなわち無線基地局から受信されるプロトコルデータユニットをリモートＵＥに中継するとき、そのようなパケットフィルタリング規則は適用可能でない。代わりに、優先度を使用して、サイドリンクインタフェースに渡る適切なサイドリンクベアラを選択し、そしてサイドリンクインタフェースを通じて必要とされる送信優先度を持つデータパケットを送信するものとする。リレーＵＥのリレー機能性は、リモートＵＥによって送信されるプロトコルデータユニットと関連づけられる優先度の指標をリモートＵＥがリレーＵＥに提供するという点で支援される。優先度指標はリモートＵＥからリレーＵＥへ制御パケット内で送信される。リモートＵＥによってリレーＵＥにプロトコルデータユニットを送信するために使用されることになる異なるサイドリンクベアラ間で優先度が異なることを考慮して、リモートＵＥはサイドリンクベアラごとに対応する優先度を持つ制御パケットを送信する。換言すれば、以下では態様を１つのサイドリンクベアラのみを参照しつつ記載することになるとはいえ、ベアラ選択、またはリレーＵＥでのダウンリンクのサイドリンクインタフェースに対するプロトコルデータユニットの優先度の選択は、利用可能なサイドリンクベアラの各々に対して行われ、したがってこれらのパケットと関連づけられる優先度に関する対応する情報を提供するリモートＵＥによって支援される。
リレーＵＥは、プロトコルデータユニットのそれぞれのサイドリンクベアラの受信した優先度を、優先度指標が無線基地局に関係させる対応するプロトコルデータユニットを送信するためにリレーＵＥによって使用される対応する無線ベアラ（例えばベアラＩＤ）と関連づける。受信した優先度と使用されるアップリンク無線ベアラとの間の関連をこのように確立することによって、リレーＵＥは後に、無線ベアラを介して無線基地局から受信されるプロトコルデータユニットの優先度を、正しい優先度を持つ対応するサイドリンクベアラを使用してリモートＵＥにプロトコルデータユニットを転送／送信するように決定してもよい。
上記の点で、無線基地局にプロトコルデータユニットを転送する適切な無線ベアラの選択は、リモートＵＥから対応するプロトコルデータユニットを受信した上でリレーＵＥによって行われることに留意すべきである。プロトコルデータユニットのいずれかがリモートＵＥによってリレーＵＥに送信される前に制御パケットがリモートＵＥによって送信されることを前提として、リレーＵＥは、優先度と無線基地局にプロトコルデータユニットを中継するための選択した無線ベアラとの間の関連を作ることができるために、リレーＵＥが上記サイドリンクベアラを介して第１のプロトコルデータユニットを続いて受信するまで、受信した優先度を記憶しなければならない。
前述したように、リモートＵＥは、リモートＵＥによってリレーＵＥにプロトコルデータユニットを送信するために使用されるサイドリンクベアラの各々に対して優先度指標を持つ対応する制御パケットを送信する。制御パケットの送信は、サイドリンクベアラがリモートＵＥに作成される時になされることができ；例えば、制御パケットは、何らかのデータプロトコルデータユニットが上記新たに作成されたサイドリンクベアラを介して送信される前に、対応する優先度を持つリモートＵＥに送信される。優先度を持つ制御パケットを最初に送信することによって、リレーＵＥが、無線基地局から受信されるダウンリンクＰＤＵの適当な優先順位付けがリモートＵＥに転送されるのを許容するように可能な限り早く上述した関連を作成することができることが保証される。
さらには、リレーＵＥに記憶される優先度情報は、リモートＵＥとリレーＵＥとの間の適当な優先順位付けを保証するように更新されて保たれるべきである。上記理由で、リモートＵＥは、サイドリンクベアラの優先度が変更されるたびにリモートＵＥにさらなる制御パケットを送信するものとする。言い換えると、リモートＵＥの実装に応じて、新たなサイドリンクベアラを作成して新たな優先度に対応する代わりに、上記サイドリンクベアラのために新たな優先度を設定することによって、現存のサイドリンクベアラが変更されてもよい。この場合にも、リモートＵＥはリレーＵＥにさらなる制御パケットを送信してもよく、そのためリレーＵＥは、この新たな優先度とその変更されたサイドリンクベアラを介して受信されるプロトコルデータユニットを無線基地局に送信するためにリレーＵＥによって選択される対応する無線ベアラとの間のさらなる関連を確立（または古い関連を更新）することができる。
第１の態様の特定の実装では、制御パケットは、詳細には優先度指標を通知する目的で規定されるＰＤＣＰ（パケットデータ収束プロトコル）制御ＰＤＵである。対応して、ＰＤＣＰ制御ＰＤＵは、上論した優先度指標を通知する制御パケットとしてのＰＤＣＰ制御ＰＤＵの識別を許容するように新たなフォーマットおよび対応するフォーマットインジケータを有することができる。
その上、リレーＵＥは、適切なサイドリンクベアラを使用して、無線ベアラで無線基地局から受信されたプロトコルデータユニットをリモートＵＥに転送するために、記憶した関連を参照する。必要な優先度を持つ適切なサイドリンクベアラが既に存在しない場合、リレーＵＥは、決定された優先度を持つ対応するサイドリンクベアラを最初に確立しなければならなくてもよく、その後それを使用してリモートＵＥにプロトコルデータユニットを転送することができる。他方で、必要な優先度を持つ適切なサイドリンクベアラが既に存在すれば（例えば第１のプロトコルデータユニットがその無線ベアラで受信されたときにサイドリンクベアラが既に確立された）、リレーＵＥは、それを最初に作成する必要なく、単にそれを選択しなければならなくてもよい。
第１の態様のさらなる変形では、リモートＵＥは、制御パケットがリレーＵＥで成功裏に受信されることを確認するように制御パケット送信の様々な繰返し（例えば所定の回数）を行うだろう。
代替の解決策では、優先度指標は制御パケットではなく、むしろデータパケットで送信される。より詳細には、優先度指標のための対応するフィールドを含む新たなデータパケットフォーマット、例えばＰＤＣＰデータＰＤＵフォーマットが規定される。したがって、この新たなデータパケットフォーマットに係るデータパケットは、通例のデータおよび他の情報（例えばソース、シーケンス番号）を含むのみではなく、加えて優先度指標を含むことになる。さらには、優先度指標を持つこのデータパケット（例えばＰＤＣＰデータＰＤＵ）は、常にリモートＵＥによって送信されることになるのではなく、優先度指標を含む制御パケットと同様にして、新たな優先度関連がリレーＵＥに設定または更新されなければならないときにのみ送信されてもよい。例えば、新たなサイドリンクベアラがリモートＵＥによって設定されることを前提として、リモートＵＥは、第１のデータと、かつ対応する新たなサイドリンクベアラと関連づけられる対応する優先度を付加的に含むことができるように新たなデータパケットフォーマットを使用して、この新たなサイドリンクベアラを通じてこのデータを送信することになる。以上説明したように、リレーＵＥは次いで、受信した優先度とリレーＵＥによって無線基地局に対応するデータを転送するために使用される対応する無線ベアラ（ＩＤ）との間の適切な関連を作ることになる。その上、新たなデータパケットフォーマットは、データパケットに同じく含まれてもよい対応する新たなデータフォーマットインジケータによって識別および区別されてもよい。
第２の態様は、リレーＵＥによってリモートＵＥに提供されるリレー機能性を同様に扱い、特にリレーＵＥから無線基地局への初期アプリケーションレベルシグナリングメッセージの中継を改善する。第１の態様に対してと同様の前提が第２の態様に対して立てられることができる。さらには、アプリケーションレベルシグナリングがリモートＵＥによって（例えばリモートＵＥの上位レイヤによって）開始され、次いでリレーＵＥを介してネットワークに送信されることになるシナリオが前提とされる。背景で説明したように、アプリケーションレベルシグナリング交換におけるこの初期段階では、アプリケーションレベルシグナリングのための個別無線ベアラがリレーＵＥと無線基地局との間に上記の点でまだ設定されておらず、そのためリレーＵＥから無線基地局へ初期アプリケーションレベルシグナリングメッセージを転送するために、デフォルトベアラが使用される。第２の態様によれば、アプリケーションレベルシグナリングメッセージは、リモートＵＥおよびリレーＵＥの両方に知られている所定の優先度値と関連づけられ、所定の優先度は、例えばアプリケーションレベルシグナリングが無線基地局に送信されることになる優先度を上げることによって、対応するアプリケーションレベルシグナリングが優先して扱われるものとすることをリレーＵＥに示す。対応して、初期アプリケーションレベルシグナリングメッセージの他に対応する所定の優先度はリレーＵＥに送信される。例えば、特定の（高優先度）サイドリンクベアラが、リモートＵＥによってリレーＵＥに両方とも送信するために使用されてもよい。その受信に応じて、リレーＵＥは、次いで所定の優先度を識別し、したがって無線基地局にアプリケーションレベルシグナリングメッセージを上昇した優先度で、例えば最高優先度で扱って送信するようにデフォルト無線ベアラを使用し続けてもよい。
さらには、所定の優先度値を識別した上で、リレーＵＥは、所定の優先度を、リレーＵＥによって無線基地局にアプリケーションレベルシグナリングメッセージを転送するために使用される対応するデフォルト無線ベアラと関連して記憶しないことになる。したがって、対応するダウンリンクアプリケーションレベルシグナリングメッセージの誤った優先順位付けがリレーＵＥで行われることが回避される。代わりに、リレーＵＥは、リモートＵＥに転送されることになる対応するダウンリンクアプリケーションレベルシグナリングメッセージを受信すると、リモートＵＥへの中継のための高優先度サイドリンクベアラを優先して選択することになる。言い換えると、リレーＵＥでベアラマッピングを行う代わりに、リレーＵＥは、ダウンリンクアプリケーションレベルシグナリングメッセージを取り扱うために設定される適切な関連を有しないことになり、したがって何らかの適切なサイドリンクベアラを使用してリモートＵＥにメッセージを提供することになり、ここでは上記サイドリンクベアラは任意選択で高優先度であるために適当かつ安全な送信を保証する。
対応して、１つの一般的な第１の態様では、ここで開示する技法は、移動通信ネットワーク内でリモートユーザ機器と交換されるプロトコルデータユニットを中継するためのリレーユーザ機器を特徴とする。リレーユーザ機器は無線基地局に接続される。リレーユーザ機器は、リモートユーザ機器と無線基地局との間の通信を中継し、リモートユーザ機器とサイドリンクベアラを通じてプロトコルデータユニットを交換する。リレーＵＥの受信器が、第１のサイドリンクベアラを介してリモートユーザ機器から制御パケットを受信し、制御パケットは、第１のサイドリンクベアラを介してリモートユーザ機器によって送信されるプロトコルデータユニットと関連づけられる優先度の指標を含む。リレーＵＥのプロセッサが、制御パケットで受信された優先度指標とリモートユーザ機器から受信されるプロトコルデータパケットを無線基地局に中継するためにリレーユーザ機器によって使用される第１の無線ベアラとの間の関連を記憶する。プロセッサは、第１の無線ベアラを介して無線基地局から受信されたプロトコルデータユニットがリモートユーザ機器に送信されるべきである優先度を、記憶した関連に基づいて決定する。リレーＵＥの送信器が、決定した優先度に対応する第２のサイドリンクベアラを使用してリモートユーザ機器に受信したプロトコルデータユニットを中継する。
対応して、１つの一般的な第１の態様では、ここで開示する技法は、移動通信ネットワーク内でリモートユーザ機器と交換されるプロトコルデータユニットを中継するためのリレーユーザ機器を動作させるための方法を特徴とする。リレーユーザ機器は無線基地局に接続される。リレーユーザ機器は、リモートユーザ機器と無線基地局との間の通信を中継し、リモートユーザ機器とサイドリンクベアラを通じてプロトコルデータユニットを交換する。方法は以下のステップを含む。リレーＵＥが、第１のサイドリンクベアラを介してリモートユーザ機器から制御パケットを受信し、制御パケットは、第１のサイドリンクベアラを介してリモートユーザ機器によって送信されるプロトコルデータユニットと関連づけられる優先度の指標を含む。リレーＵＥが、制御パケットで受信した優先度指標とリモートユーザ機器から受信されるプロトコルデータパケットを無線基地局に中継するためにリレーユーザ機器によって使用される第１の無線ベアラとの間の関連を記憶する。リレーＵＥが、第１の無線ベアラを介して無線基地局から受信されたプロトコルデータユニットがリモートユーザ機器に送信されるべきである優先度を、記憶した関連に基づいて決定する。リレーＵＥが、決定した優先度に対応する第２のサイドリンクベアラを使用してリモートユーザ機器に受信したプロトコルデータユニットを中継する。
対応して、１つの一般的な第１の態様では、ここで開示する技法は、移動通信ネットワーク内で無線基地局に接続されるリレーユーザ機器にプロトコルデータユニットを送信するためのリモートユーザ機器を特徴とする。リレーユーザ機器は、リモートユーザ機器と無線基地局との間の通信を中継し、リレーユーザ機器とサイドリンクベアラを通じてプロトコルデータユニットを交換する。リモートＵＥの送信器が、第１のサイドリンクベアラを介してリレーユーザ機器に制御パケットを送信し、制御パケットは、第１のサイドリンクベアラを介してリモートユーザ機器によってリレーユーザ機器に送信されるプロトコルデータユニットと関連づけられる優先度の指標を含む。
対応して、１つの一般的な第１の態様では、ここで開示する技法は、移動通信ネットワーク内で無線基地局に接続されるリレーユーザ機器にプロトコルデータユニットを送信するためのリモートユーザ機器を動作させるための方法を特徴とする。リレーユーザ機器は、リモートユーザ機器と無線基地局との間の通信を中継し、リレーユーザ機器とサイドリンクベアラを通じてプロトコルデータユニットを交換する。方法は以下のステップを含む。リモートＵＥが、第１のサイドリンクベアラを介してリレーユーザ機器に制御パケットを送信し、制御パケットは、第１のサイドリンクベアラを介してリモートユーザ機器によってリレーユーザ機器に送信されるプロトコルデータユニットと関連づけられる優先度の指標を含む。
対応して、１つの一般的な第１の態様では、ここで開示する技法は、移動通信ネットワーク内でリモートユーザ機器と交換されるプロトコルデータユニットを中継するためのリレーユーザ機器を特徴とする。リレーユーザ機器は無線基地局に接続される。リレーユーザ機器は、リモートユーザ機器と無線基地局との間の通信を中継し、リモートユーザ機器とサイドリンクベアラを通じてプロトコルデータユニットを交換する。リレーＵＥの受信器が、第１の所定の優先度と関連づけられるアプリケーションレベルシグナリングメッセージを受信する。リレーＵＥのプロセッサが、第１の所定の優先度に基づいて、デフォルトベアラを使用して無線基地局にアプリケーションレベルシグナリングメッセージを送信すると、かつアプリケーションレベルシグナリングメッセージが無線基地局に送信されることになる優先度を上げると決定する。リレーＵＥの送信器が、デフォルトベアラを介して無線基地局にアプリケーションレベルシグナリングメッセージを上昇した優先度で送信する。
対応して、１つの一般的な第１の態様では、ここで開示する技法は、移動通信ネットワーク内でリモートユーザ機器と交換されるプロトコルデータユニットを中継するためのリレーユーザ機器を動作させるための方法を特徴とする。リレーユーザ機器は無線基地局に接続される。リレーユーザ機器は、リモートユーザ機器と無線基地局との間の通信を中継し、リモートユーザ機器とサイドリンクベアラを通じてプロトコルデータユニットを交換する。方法は以下のステップを含む。リレーＵＥが、所定の優先度と関連づけられるアプリケーションレベルシグナリングメッセージを受信する。リレーＵＥが、所定の優先度に基づいて、デフォルトベアラを使用して無線基地局にアプリケーションレベルシグナリングメッセージを送信すると、かつアプリケーションレベルシグナリングメッセージが無線基地局に送信されることになる優先度を上げると決定する。リレーＵＥが、デフォルトベアラを介して無線基地局にアプリケーションレベルシグナリングメッセージを上昇した優先度で送信する。
対応して、１つの一般的な第１の態様では、ここで開示する技法は、移動通信ネットワーク内で無線基地局に接続されるリレーユーザ機器にプロトコルデータユニットを送信するためのリモートＵＥを特徴とする。リレーユーザ機器は、リモートユーザ機器と無線基地局との間の通信を中継し、リモートユーザ機器とサイドリンクベアラを通じてプロトコルデータユニットを交換する。リモートＵＥのプロセッサが、リレーユーザ機器に送信されることになるアプリケーションレベルシグナリングメッセージと関連づけられることになる所定の優先度を決定する。リモートＵＥの送信器が、アプリケーションレベルシグナリングメッセージが無線基地局に送信されることになる優先度を上げるようにリレーユーザ機器に示すように、リレーユーザ機器にアプリケーションレベルシグナリングメッセージおよび関連する所定の優先度を送信する。
対応して、１つの一般的な第１の態様では、ここで開示する技法は、移動通信ネットワーク内で無線基地局に接続されるリレーユーザ機器にプロトコルデータユニットを送信するためのリモートユーザ機器を動作させるための方法を特徴とする。リレーユーザ機器は、リモートユーザ機器と無線基地局との間の通信を中継し、リモートユーザ機器とサイドリンクベアラを通じてプロトコルデータユニットを交換し、方法は以下のステップを含む。リモートＵＥが、リレーユーザ機器に送信されることになるアプリケーションレベルシグナリングメッセージと関連づけられることになる所定の優先度を決定する。リモートＵＥが、アプリケーションレベルシグナリングメッセージが無線基地局に送信されることになる優先度を上げるようにリレーユーザ機器に示すように、リレーユーザ機器にアプリケーションレベルシグナリングメッセージおよび関連する所定の優先度を送信する。
開示した実施形態の追加の利益および利点は本明細書および図から明らかだろう。利益および／または利点は、明細書および図面の開示の様々な実施形態および特徴によって個々に提供されてもよく、同利益および／または利点の１つまたは複数を得るためにすべて提供される必要があるわけではない。
これらの一般的なおよび特定の態様はシステム、方法およびコンピュータプログラム、ならびにシステム、方法およびコンピュータプログラムの任意の組合せを使用して実装されてもよい。
以下では、例示的な実施形態が添付の図および図面を参照しつつより詳細に記載される。
３ＧＰＰ ＬＴＥシステムの例示的なアーキテクチャを示す図である。 ３ＧＰＰ ＬＴＥ（Ｒｅｌｅａｓｅ８／９）に定義されるサブフレームのダウンリンクスロットの例示的なダウンリンクリソースグリッドを示す図である。 ＰＣ５インタフェースを通じたＰｒｏＳｅ通信を含む、ＬＴＥのためのベアラアーキテクチャの図である。 ＰｒｏＳｅ通信のためのＰＣ５上のレイヤ２リンクの確立のさせ方を概略的に示す図である。 オーバーレイ（ＬＴＥ）およびアンダーレイ（Ｄ２Ｄ）システムのための送信／受信リソースの使用を示す図である。 ２つのＵＥに対するスケジューリング割当ておよびＤ２Ｄデータの送信を示す図である。 非ローミングシナリオについてのＰｒｏＳｅのための例示的なアーキテクチャモデルを示す図である。 Ｄ２Ｄ ＵＥが関連づけられることができる４つの異なる状態に関するセルカバレッジを示す図である。 ＰｒｏＳｅ ＵＥ−ネットワークリレーシナリオを示す図である。 ＰｒｏＳｅ ＵＥ−ネットワークリレーのためのユーザプレーンプロトコルアーキテクチャを示す図である。 ＰｒｏＳｅセッション確立のためのシグナリング図である。 リモートＵＥとアクセスネットワークとの間のアプリケーションシグナリングの交換を例示するシグナリング図である。 第１の実施形態の１つの実装に係るリモートＵＥでの処理のシーケンス図である。 第１の実施形態の１つの実装に係るリレーＵＥでの処理のシーケンス図である。 第１の実施形態の１つの実装に係るＰＰＰ ｉｎｆｏを通知する例証的なＰＤＣＰ制御ＰＤＵフォーマットの図である。 第１の実施形態の１つの実装に係る様々な信号および処理ステップを例示するシグナリング図である。 ＰＤＣＰデータＰＤＵフォーマットの図である。 第１の実施形態の１つの実装に係るＰＰＰ ｉｎｆｏを通知する例証的なＰＤＣＰデータＰＤＵフォーマットの図である。 第２の実施形態の１つの実装に係るリモートＵＥでの処理のシーケンス図である。 第２の実施形態の１つの実装に係るリレーＵＥでの処理のシーケンス図である。 第２の実施形態の１つの実装に係る様々な信号および処理ステップを例示するシグナリング図である。
移動局または移動ノードまたはユーザ端末またはユーザ機器は、通信ネットワーク内の物理エンティティである。１つのノードがいくつかの機能エンティティを有してもよい。機能エンティティは、所定の機能の集合をノードの他の機能エンティティまたはネットワークに実装および／または提供するソフトウェアまたはハードウェアモジュールを指す。ノードは、ノードが通信するために介することができる通信機構または媒体にノードを取り付ける１つまたは複数のインタフェースを有してもよい。同様に、ネットワークエンティティは、機能エンティティが他の機能エンティティまたは対応ノードと通信するために介してもよい通信機構または媒体に機能エンティティを取り付ける論理インタフェースを有してもよい。
「リレーユーザ機器」は、本願の請求項でおよび本出願で使用する場合、（「リモートユーザ機器」と名付けられる）別のユーザ機器に対するリレーとして働くことが可能であるユーザ機器を指すとして広く理解しなければならない。これは、直接に２つのユーザ機器間の直接通信送信をサポートする能力も伴う（以下Ｄ２ＤまたはＰｒｏＳｅを参照のこと）。３ＧＰＰ専門用語では、リレーユーザ機器はＰｒｏＳｅ ＵＥ対ネットワークリレーとも称される。１つの実装によれば、リレーユーザ機器は、３ＧＰＰ ＬＴＥ−Ａに規定されるように、および背景に記載したようにリレー機能性をサポートするものとする。上記の関連で、用語「リモートユーザ機器」は単に、リレーユーザ機器のピアである、すなわち直接通信を確立するリレーを探しているとしてのユーザ機器の役割を示すだけのものとする。より詳細には、「リモートユーザ機器」は、ＰｒｏＳｅ ＵＥ対ネットワークリレーを介してＰＤＮと通信するＰｒｏＳｅ対応公共安全ＵＥである。
用語「無線リソース」は、本願の請求項でおよび本出願で使用する場合、時間−周波数リソースなどの物理無線リソースを指すとして広く理解しなければならない。
用語「直接通信送信」は、本願の請求項でおよび本出願で使用する場合、直接に２つのユーザ機器間の、すなわち無線基地局（例えばｅＮＢ）を介さない送信として広く理解しなければならない。対応して、直接通信送信は「直接サイドリンク接続」を通じて行われ、これは直接に２つのユーザ機器間に確立される接続のために使用される用語である。例えば、３ＧＰＰでは、Ｄ２Ｄ（デバイスツーデバイス）通信またはＰｒｏＳｅ通信またはサイドリンク通信の専門用語が使用される。用語「直接サイドリンク接続」は、本願の請求項でおよび本出願で使用する場合、背景に記載したＰＣ５インタフェースとして広く理解しなければならず、かつ３ＧＰＰコンテキストで理解することができる。
用語「リレー機能性」は、本願の請求項でおよび本出願で使用する場合、ＰｒｏＳｅ ＵＥ対ネットワークリレーとして作用するユーザ機器の能力として広く理解しなければならない。１つの例示的な実装では、リレー機能性は、背景で詳細に説明したように３ＧＰＰ作業項目で現在標準化されている機能性である。
用語「アプリケーションレベルシグナリング」は、一組の請求項でおよび本出願で使用する場合、アプリケーション関連制御シグナリング、例えば図７に図示するようにＰＣ１インタフェースを通じたＵＥでのＰｒｏＳｅアプリケーションとＰｒｏＳｅアプリケーションサーバとの間のシグナリングとして広く理解しなければならない。例えばＰｒｏＳｅ対応ＵＥがアプリケーションレベルグループに加わるときに、アプリケーションレベルシグナリングが使用される。
３ＧＰＰは、現在ＰｒｏＳｅ可能ユーザ機器のためのリレー機能性を導入する最中である。いくつかの初期取決めが既になされた（そのいくつかは背景で詳細に説明される）。リレーＵＥでの優先度メカニズムを支援するために、各ＰＤＣＰデータＰＤＵがＰｒｏＳｅパケット単位優先度（ＰＰＰＰ）情報で拡張されることが決定されたが、それは次いでリレーＵＥでＵｕ無線ベアラを適切なＰＣ５ベアラ（ＳＬＲＢ）にマッピングするために使用することができる。対応して、ＰＤＣＰデータＰＤＵヘッダは、ＰＤＣＰ ＳＤＵに関連づけられるＰＰＰＰ値を含んでもよい。ＰＰＰＰは８つの可能な値を有し、４ビットを介して区別可能である。ＰＤＣＰヘッダは、ＰＤＵフォーマットをバイトアラインさせて保つようにフルオクテットだけ拡大されることになる。これは、次いでシグナリングオーバーヘッドの有意な増加、事実上ＰＣ５インタフェースで送信される各ＰＤＣＰデータＰＤＵに対して１バイトのオーバーヘッドにつながる。
サイドリンク無線ベアラの優先度が基本的に半静的であり、したがって動的に変更されないことをさらに考慮すると、これは特に不利である。
以上説明した１つまたは複数の課題を軽減するために、以下の例示的な実施形態が発明者らによって考えられる。
様々な実施形態の特定の実装が、様々な実施形態に関連して以下で説明するように特定の主要な特徴を追加しつつ、３ＧＰＰ規格によって与えられ、かつ背景で部分的に説明したような広範な仕様で実装されるものである。実施形態は、例えば上記技術背景に記載したように、３ＧＰＰ ＬＴＥ−Ａ（Ｒｅｌｅａｓｅ１０／１１／１２／１３）通信システムなどの移動通信システムに有利に使用されることができるが、しかし実施形態はこの特定の例示的な通信ネットワークでのその使用に限定されないことに留意するべきである。
説明は、本開示の範囲を限定するとしてではなく、本開示をよりよく理解するための実施形態の単なる例として理解するべきである。当業者は、請求項に述べるような本開示の一般的な原理が異なるシナリオに、かつ本明細書に明記しない方途で適用されることができることを認識しているべきである。例示目的で、いくつかの前提が立てられるが、しかしながら、それらは以下の実施形態の範囲を限定するものではない。
さらには、上述したように、以下の実施形態は、３ＧＰＰ ＬＴＥ−Ａ（Ｒｅｌ．１２／１３）環境で実装されてもよい。様々な実施形態は、主にリレーＵＥにおける改善されたリレー機能性、すなわちＰｒｏＳｅ ＵＥ対ネットワークリレーケースのための改善されたＱｏＳサポートを提供し、そのため他の機能性（すなわち様々な実施形態によって変更されない機能性）は、背景で説明したのと厳密に同じままでもよいし、または様々な実施形態へのいかなる影響もなしで変更されてもよい。
ユーザ機器がＰｒｏＳｅ通信（ＰｒｏＳｅ対応ＵＥ）、すなわちｅＮｏｄｅＢを介する迂回のない直接にＵＥ間の直接Ｄ２Ｄ送信を行うことを可能にされるシナリオを前提としてもよい。さらには、シナリオにおけるこれらの（ＰｒｏＳｅ対応）ＵＥの少なくとも１つが、例えば３ＧＰＰ規格のリリース１３における具体的な実装に関して背景で説明したリレー機能性をサポートするものとし、かつ以下でリモートＵＥと称される少なくとも１つのＰｒｏＳｅ対応ＵＥに対するＰｒｏＳｅリレーとして働くものとする。データは、リモートＵＥとリレーＵＥとの間のサイドリンクベアラを介して対応して交換され、リレーＵＥによってアップリンクおよびダウンリンクの両方向に中継されることになる。
第１の実施形態
以下に、上述した課題を解決するための第１の実施形態を詳細に記載することにする。第１の実施形態の異なる実装を以下に詳細に説明することにする。第１の実施形態によれば、以下に説明することになるように、リレーＵＥによって行われるリレー機能性が改善される。
リレーＵＥにおけるリレー機能性は、異なる優先度を持つデータを適当に取り扱うことを必要とする。背景で説明したように、レガシー優先度メカニズムはＱｏＳ／ＱＣＩ属性に基づき、リレーＵＥとコアネットワークとの間に適用されるものとする。対応して、各無線／ＥＰＳベアラは特定のＱＣＩと関連づけられ、特定の一組のＱｏＳ要件を満たす。
他方で、ＰＣ５インタフェースを介する優先度処理は、ＰｒｏＳｅパケット単位優先度（ＰＰＰＰ）（または単にパケット単位優先度、ＰＰＰ）に基づくものとする。対応するサイドリンクベアラは、特定の優先度ＰＰＰＰ要件を満たすように確立される。背景で説明したように、現在ＰＰＰＰ当たり１つのサイドリンクベアラがあることを前提とする。より詳細には、サイドリンクベアラは、ソースＩＤ／宛先ＩＤ／ＰＰＰの組合せに対してＰＤＣＰ／ＲＬＣエンティティを確立し、そしてサイドリンクベアラの論理チャネルにＬＣＩＤ（論理チャネルＩＤ）を割り当てることによって設定される。例えば、ＰｒｏＳｅアプリケーションレイヤがリモートＵＥにおける下位レイヤ（例えばＰＤＣＰレイヤ）にデータパケットを提供するとき、それは、優先度に従って適切なサイドリンクベアラを選択／確立してリレーＵＥにデータパケットを送信するために使用されることになる対応するパケット単位優先度も提供する。
結果的に、ＰＣ５インタフェースを介する優先度処理は、無線およびコアネットワークの残りに渡る優先度処理と異なる。リレーＵＥは、データパケットが正しい優先度（ＰＰＰＰであろうと、またはＱＣＩ／ＱｏＳであろうと）で送信されることを確認する必要があり、したがってＱｏＳ／優先度要件を満たす適切なサイドリンク／無線ベアラを使用してデータを送信しなければならない。
リレーＵＥでの優先度処理がアップリンクおよびダウンリンクデータ間で有意に異なってもよいことにさらに留意すべきである。特に、リレーＵＥがリモートＵＥからデータを受信すると、リレーＵＥは、ｅＮｏｄｅＢにデータを転送するためにどの無線ベアラを使用するべきかを決定する必要がある。この決定は、例えばこの目的でリレーＵＥに記憶／設定されるトラヒックフローテンプレート（ＴＦＴ）に基づいてなされ；すなわち、トラヒックフローテンプレートは、データがｅＮＢに送信されるために介することになる（対応するＱＣＩ属性を持つ）無線ベアラをリレーＵＥが決定するために従うことができるパケットフィルタリング規則を提供する。例えば、データのＩＰ宛先アドレス、ＩＰソースアドレス、ポート番号および／または他の情報がトラヒックフローテンプレートと比較されて、適切な無線ベアラを決定することができる。１つの実装では、ＴＦＴはＰＣＲＦによって提供され、ＰＣＲＦは、例えばベアラがアクティブ化されるときに加入者プロファイルリポジトリ（ＳＰＲ：Subscriber Profile Repository）から受信される加入情報に基づいてベアラのためのＱｏＳパラメータを決定する。
このデータ情報をリレーＵＥでのアップリンクベアラマッピングのためのトラヒックフローテンプレートに対して検討することによって、リレーＵＥは、ＱｏＳ要件を満足させる無線ベアラが使用されることを確認する。
他方で、リレーＵＥがｅＮｏｄｅＢからデータを受信すると、リレーＵＥは、リモートＵＥにデータを転送するために使用するのに適するサイドリンクベアラを決定する必要がある。上述したように、ＰＣ５インタフェースへの優先度処理は、（リモートＵＥが、上位ＰｒｏＳｅアプリケーションレイヤによって提供されるＰＰＰＰに基づいてリレーＵＥへのサイドリンクベアラを選択／確立する必要があるときとは対照的に）しかしながらｅＮｏｄｅＢからのダウンリンクデータと共には送信されないパケット単位優先度に基づく。代わりに、リレーＵＥは、ＰＰＰＰとＵｕインタフェースでデータを送信するために使用される無線ベアラとの間の以前に確立および記憶した関連に基づいてベアラマッピングを行うことになる。この関連は特定のＰＰＰＰを無線ベアラ（例えばそのベアラＩＤ）と関連づけ、そのためリレーＵＥは、無線ベアラを介してダウンリンクデータを受信すると、データがｅＮｏｄｅＢから受信された上記無線ベアラと関連づけられる対応する優先度（ＰＰＰＰ）を決定してもよい。ＰＰＰＰを決定した上で、リレーＵＥは、リモートＵＥにダウンリンクデータを送信するための適切なサイドリンクベアラを使用してもよく、適切なサイドリンクベアラは、決定したＰＰＰＰの要件に対応する。上記の点で、適切なサイドリンクベアラがまだ利用可能でなければ、リレーＵＥが、決定したＰＰＰＰに対するそのようなサイドリンクベアラを最初に確立しなければならなくてもよいことに留意すべきである。
上記の点で、リモートＵＥによってリレーＵＥにデータを送信するために使用されるサイドリンクベアラがリレーＵＥによってリモートＵＥにデータを送信するために使用されるサイドリンクベアラと異なってもよいことも留意すべきである。言い換えると、送信されることになるそれぞれのデータが同じＰＰＰＰを有するにもかかわらず、異なるサイドリンクベアラがそれぞれの送信方向のためにリモートＵＥおよびリレーＵＥによって使用されてもよい。１つの理由は、一般にサイドリンクベアラが必ずしも双方向ではなく、単に単方向でもよいということである。
リレーＵＥにおいてダウンリンクベアラマッピング（または優先度処理）の目的で優先度（ＰＰＰＰ）と無線ベアラとの間の関連を確立するために、リモートＵＥは、それがリレーＵＥにサイドリンクベアラを介して送信するデータのＰＰＰＰについてリレーＵＥに通知することになる。リレーＵＥは次いで、それがｅＮｏｄｅＢに上記データを転送するために介する特定の無線ベアラを決定してもよく、そして決定した無線ベアラと対応するＰＰＰＰとの間のマッピングを確立してもよい。
上記のために、リモートＵＥは、対応する優先度ＰＰＰＰを含むＰＤＣＰ制御ＰＤＵパケットを生成し、リレーＵＥに送信する。この新たなＰＤＣＰ制御ＰＤＵは、詳細にはリレーＵＥにサイドリンク無線ベアラと関連づけられる優先度（ＰＰＰＰ）を通知するように規定される。１つの実装によれば、新たなＰＤＣＰ制御ＰＤＵは、具体的なＰＤＣＰ ＳＤＵ型によって識別されることになる。特に、以下の表から明らかなように、これまで２つの異なるＰＤＣＰ ＳＤＵ型のみが規定されている。
Figure 2018533235
明らかなように、３ビットＳＤＵ型フィールドが、ＩＰパケットとアドレス解決プロトコル（ＡＲＰ：Address Resolution Protocol）パケットとの間を区別することを許容する。ＩＰアドレスが設定されなければ、アドレス解決プロトコル（ＡＲＰ）は、例えばＩＰｖ４アドレスの動的設定のためのＤ２Ｄ通信に使用される。
第１の実施形態の例証的な実装によれば、以下の表から明らかなように、新たなＳＤＵ型が導入される（下線部参照のこと）。
Figure 2018533235
新たなＳＤＵ型は例証的に「ＰＰＰ ｉｎｆｏ」と命名され、対応してＰＰＰ ｉｎｆｏ、すなわちサイドリンク無線ベアラのパケットに関連づけられる優先度情報を通知するものと意図される。以上の表では、例証的に「ＰＰＰ ｉｎｆｏ」ＰＤＣＰ制御ＰＤＵを識別するためにビットパターン０１０が使用される。
この新たなＳＤＵ型に係るＰＤＣＰ制御ＰＤＵの例を図１５に例示する。そこから明らかなように、ＰＤＣＰ制御ＰＤＵは、例証的なビット「０１０」を通知してＰＤＵを型「ＰＰＰ ｉｎｆｏ」であると識別するものであるＳＤＵ型フィールドを含み、さらにＰＰＰ ｉｎｆｏ自体を含む。オクテットを満たす残りのビットは予約済であると考えてもよく、将来使用可能でもよい。３ビットを有するＰＰＰ ｉｎｆｏは単に例であり、したがって代替的に、より多いまたはより少ないビットがＰＰＰ ｉｎｆｏフィールドに与えられてもよい。ＰＤＣＰ制御ＰＤＵのこの例は、暗号化が適用されないことを前提とする。対応して、ＰＤＣＰレイヤは、そのようなＰＤＣＰ制御ＰＤＵを送るようにトリガされると、それ自体をＰＤＣＰシーケンス番号と関連づけることも、暗号化を行うこともなくＰＤＣＰ制御ＰＤＵを下位レイヤに提示する。
このＰＤＣＰ制御ＰＤＵは、特定の時点でのみ、例えばこのＰＰＰ情報が実際にリレーＵＥで必要とされるときにのみ、リモートＵＥによってリレーＵＥに送信されることになる。例えば、ＰＰＰ ｉｎｆｏを持つＰＤＣＰ制御ＰＤＵは、新たなＰＰＰを持つデータがリモートＵＥによってリレーＵＥに送信されるときにリモートＵＥからリレーＵＥに送信されるのみでもよい。これは、リモートＵＥがリレーＵＥにデータを送信するために利用可能である適切な（すなわち特定の優先度を適切に有する）サイドリンクベアラがない特定の優先度に従って上記データが送信されることになる場合でもよい。対応して、リモートＵＥは、これが新たな優先度であると（言い換えると対応する優先度を持つ新たなサイドリンクベアラが必要とされると）決定すると、（完全に新たなサイドリンクベアラを確立することによってか、または以前に確立したサイドリンクベアラを、この特定の優先度を有するように変更することによってかいずれかで）この特定の優先度を有するそのようなサイドリンクベアラを確立することになる。新たな優先度のためのこの新たなサイドリンクベアラを確立した上で、リモートＵＥは、この新たな／変更した優先度についてリレーＵＥに通知して、対応する関連をリレーＵＥに有するものとする。上記のために、リモートＵＥは、「ＰＰＰ ｉｎｆｏ」フィールドに新たな優先度値を含む新たなＰＤＣＰ制御ＰＤＵを生成し、それを新たな／変更したサイドリンクベアラを介してリレーＵＥに送信する。また、リモートＵＥは、上記新たな優先度を持つデータを送信するのに適する新たな／変更したサイドリンクベアラを介して、上記優先度を持つデータを送信する。リレーＵＥ側では、リレーＵＥは、新たなＰＤＣＰ制御ＰＤＵで受信されるＰＰＰと（新たな／変更されたサイドリンクベアラを介してリモートＵＥから受信される）データをｅＮＢに送信するためにリレーＵＥによって選択される無線ベアラとの間の関連を再び確立することになる。
結果的に、ＰＤＣＰ制御ＰＤＵが実際にリレーＵＥで必要とされる特定の時点でのみそれを送信することによって、オーバーヘッドを最小に保つことができる。
ＰＰＰ ｉｎｆｏはダウンリンクデータ優先順位付けを適当に処理する（すなわち正しいＰＰＰを持つ適切なサイドリンクベアラを選択する）ようにリレーＵＥで必要とされるので、ＰＤＣＰ制御ＰＤＵは、例えば新たなサイドリンクベアラを確立した直後に、および対応するデータの送信を始める前に、リモートＵＥによってできるだけ早く送信されてもよい。他方で、リレーＵＥが対応する関連を確立することができるためには、その時点でのみリレーＵＥが（上で説明したトラヒックフローテンプレートに基づいて）適切な無線ベアラを決定することになるため、データパケットもリモートＵＥによって送信されなければならない。したがって、ＰＰＰ ｉｎｆｏを持つＰＤＣＰ制御ＰＤＵは、データと同様の時点で、すなわち新たな優先度を持つ新たに確立したサイドリンクベアラを通じて最初のデータパケットを送信するすぐ前か後に送信されてもよい。
代替的に、最終的には後にデータを送信するために使用されるであろう無線ベアラを決定するために最初のデータパケットがリレーＵＥで必要でないように、ＰＤＣＰ制御ＰＤＵは、データからの（例えばそのヘッダからの）必要な情報を付加的に含んでもよく、したがってこの拡張ＰＤＣＰ制御ＰＤＵを受信した直後に関連を確立することを許容する。
第１の実施形態の代替の実装では、ＰＤＣＰ制御ＰＤＵは、それがリレーＵＥで成功裏に受信される可能性を上昇させるように、一度だけでなく所定の回数送信される。例えば、所定の回数はｅＮｏｄｅＢによって特定されてもよく、または例えばカバレッジ外動作に対して予め設定されてもよい。
図１３は、上論したように第１の実施形態の具体的な実装に係るリモートＵＥでの機能性の一部の処理を例示するシーケンス図である。図１３から明らかなように、制御パケット送信の繰返しは、このステップが任意選択であることを示すように一点鎖線で例示する。同様に、制御パケットを送信するステップとデータパケットの送信との間の破線矢印は、任意選択で、データパケットの送信が優先度ｉｎｆｏを通知する制御パケットの送信の後でもよいことを示すものとする。
図１４は、上論した第１の実施形態の具体的な実装に係るリレーＵＥでのリレー機能性の一部の処理を例示するシーケンス図である。リレーＵＥ処理の例示は、対応するスレッドが別々に保たれるように、アップリンクおよびダウンリンクデータパケットの並列処理を前提とする。しかしながら、ダウンリンクデータパケットの優先度を決定することができるように、リレーＵＥは、図１４の左側スレッドに従って行われる、既に記憶した対応する関連を有しなければならない。他方では、ＰＤＣＰ制御ＰＤＵ（図１４で制御パケット）のリレーＵＥ処理は、少なくとも一度リレーＵＥが、アップリンクデータパケットの中継のための無線ベアラを決定して、リレーが優先度ｉｎｆｏと対応する選択した（アップリンク）無線ベアラとの間の関連を確立および記憶するのを許容する必要があることを示すように、アップリンクデータ処理と連結される。
図１６は、上論した第１の実施形態の例証的な実装を例示するシグナリング図である。図１６から明らかなように、値６を持つＰＰＰ優先度がＰＤＣＰ制御ＰＤＵによってリレーＵＥに通知されることを前提とする。この特定の例は、制御パケットもデータもリモートＵＥによってＩＤ＝１を持つサイドリンク無線ベアラを介して送信されることを前提とする。データを受信した上で、リレーＵＥは、適切な無線ベアラを選択して、例えば上で説明したトラヒックフローテンプレートによって与えられる規則に基づいてｅＮｏｄｅＢにデータを送信することになる。この特定の場合には、ＩＤ＝１を持つ無線ベアラを使用する前提とする。対応して、リレーＵＥによって確立される関連は、優先度値６を無線ベアラＩＤ１と関連づけることになる。結果的に、後にＩＤ＝１を持つ無線ベアラを介して無線基地局からデータを受信すると、リレーＵＥは、記憶した関連を参照し、そして無線ベアラＩＤ１と関連づけられる優先度を識別することによって上記データの対応して正しい優先度を決定することができることになる。リレーＵＥは、したがってｅＮｏｄｅＢから受信されるデータが優先度値６（すなわちＰＰＰＰ＝６）に従ってリモートＵＥに送信されるものとすることを学習することになり、それに応じて優先度値６を持つ適切なサイドリンクベアラを選択することになる。リレーＵＥが、したがってＩＤ＝３を持つサイドリンク無線ベアラを介してリモートＵＥに上記データを送信することを前提とする。
第１の実施形態の以上の記載は、基本的にリモートＵＥによってリレーＵＥにデータを送信するために使用される単一のサイドリンクベアラに集中していた。しかしながら、第１の実施形態（ならびにその変形および実装のいずれか）の以上の原理は、リモートＵＥによってリレーＵＥにデータを送信するために確立される複数のサイドリンクベアラの各々に適用されることができる（所与のソース／宛先のためのサイドリンクベアラの各々は異なる優先度ＰＰＰに対応している）。対応して、異なるサイドリンクベアラが異なる優先度と関連づけられることになるので、リモートＵＥは、リレーＵＥにデータを送信するために使用するサイドリンクベアラ当たりリレーＵＥに少なくとも１つのＰＤＣＰ制御ＰＤＵを送信することができ、したがって上記異なるサイドリンクベアラを介して送信されるデータは、それをｅＮｏｄｅＢに送信するためにどの無線ベアラを使用するべきかを決定するときにリレーＵＥでも異なって処理されることになる。リレーＵＥは、対応して、ｅＮｏｄｅＢから受信され、リモートＵＥに転送されることになるすべての異なるデータを処理するように、いくつかの異なる関連を記憶してもよい。
第１の実施形態の代替の実装によれば、制御パケットを使用してリモートＵＥからリレーＵＥへＰＰＰ情報を通知する代わりに、上記の点でデータパケットを使用してもよい。対応して、リモートＵＥは、対応するＰＰＰ要件を満たす対応するサイドリンクベアラを介してリレーＵＥにデータと共にＰＰＰ情報を送信することになる。上記のために、１つの変形では、ＰＰＰ情報を通知するためのフィールドを付加的に含む新たなＰＤＣＰデータＰＤＵフォーマットが規定される。新たなＰＤＣＰ制御ＰＤＵフォーマットに関連して既に論じたように、「通常の」ＰＤＣＰデータＰＤＵに対して規定される通例のフィールドに加えてＰＰＰ情報を通知することも許容する新たなＳＤＵ型が規定されてもよい。
図１７は、ＰＤＣＰデータＰＤＵを通知するために現在規定されているＰＤＣＰデータＰＤＵフォーマットを開示する。そこから明らかなように、フォーマットは以下のフィールドから成る：
− ＰＤＵがＩＰデータを通知することを示すためのＳＤＵ型（上記表ビットパターン「０００」を参照のこと）、
− 暗号化のためのＰＧＫ（ProSe Group Key：ＰｒｏＳｅグループキー）インデックス、
− 暗号化のためのＰＴＫ（ProSe Traffic Key：ＰｒｏＳｅトラヒックキー）識別情報、
− ＰＤＣＰシーケンス番号
− ＩＰデータ
図１８は、優先度情報を通知することもできるように拡張された（フィールド「ＰＰＰ ｉｎｆｏ」を参照のこと）新たなＰＤＣＰデータＰＤＵフォーマットを開示する。バイトアラインさせるために、オクテット番号６の残りのビットは予約済でもあることになることに留意すべきである。この新たなＰＤＣＰデータＰＤＵフォーマットのＳＤＵ型は、以下の例証的な表のように規定されてもよい。
Figure 2018533235
第１の実施形態に関連して既に上論したように、（最初のデータと共に）この新たなＰＤＣＰデータＰＤＵ内で送信されるＰＰＰ情報は、ＰＰＰ値とこの新たなＰＤＣＰデータＰＤＵで同じく受信されるデータをｅＮｏｄｅＢに転送するために使用されると決定される無線ベアラとの間の対応する関連を生成するためにリレーＵＥによって使用されることができる。上論したのと同じように、リレーＵＥは次いで、確立した関連を使用して、ｅＮｏｄｅＢから受信されるダウンリンクデータに適当に優先順位付けし、リモートＵＥに中継するように、適切なダウンリンクベアラマッピングを行ってもよい。
第１の実施形態に関連して既に上論したように、ＰＰＰ ｉｎｆｏを付加的に通知する新たなＰＤＣＰデータＰＤＵは、常にではなく、ＰＰＰ ｉｎｆｏが実際にリレーＵＥで必要とされる特定の時点でのみ使用されてもよい。例えば、新たなＰＤＣＰデータＰＤＵフォーマットは、新たなサイドリンクベアラが確立されるときに、この新たなサイドリンクベアラと関連づけられる新たな優先度およびそれを介して送信されるデータをリレーＵＥに通知するように（例えば最初の（ごく少ない）ＩＰパケットと共に）初めに使用されるものとする。また、リモートＵＥからリレーＵＥへＰＰＰ ｉｎｆｏを付加的に送信することによって発生されるオーバーヘッドは、したがって最小に保たれることになる。
第２の実施形態
以下では、第１の実施形態の根底にあるものと異なる課題を扱う第２の実施形態を提示する。第２の実施形態はスタンドアロンで、または第１の実施形態と共に（すなわち組み合わせて）使用することができ、第２の実施形態の以下の記載から明らかになるであろう。
第１の実施形態に対して立てたのと同じ前提を第２の実施形態に対しても立てることができる。特に、ＰｒｏＳｅ対応リレーＵＥが、ＱｏＳ／ＱＣＩ属性および適切なトラヒックフローテンプレート（ＴＦＴ）に基づいてアップリンクデータに適当に優先順位付けし、かつＰｒｏＳｅパケット単位優先度（ＰＰＰＰ）および以前に確立した優先度対無線ベアラ関連に基づいてダウンリンクデータに優先順位付けすることができる前提とする。リレーＵＥは、データパケットを正しい優先度（ＰＰＰＰであろうと、または論理チャネル優先度であろうと）で送信するものとし、したがってデータを送信するために優先度要件を満たす適切なサイドリンク／無線ベアラを使用しなければならない。さらなる詳細については、第２の実施形態に適用可能であると等しく考えられるものとする第１の実施形態に対して与えられた前提が参照される。
第１の実施形態に関して詳細に説明したように、無線ベアラとＰＰＰ（ＰＣ５インタフェース上の優先度）、したがって（ダウンリンク）サイドリンクベアラとの間の適当なダウンリンクマッピングを許容するように優先度対無線ベアラ関連がリレーＵＥに確立される。対応して、リレーＵＥには、サイドリンクベアラ（上記サイドリンクベアラを介して送信されるデータも指す）に対する優先度情報（ＰＰＰＰ ｉｎｆｏ）が提供され、そのためリレーＵＥは次いで、受信した優先度値を、（優先度が指す上記サイドリンクベアラを介してリモートＵＥから受信される）上記データをｅＮＢに転送／送信するためにリレーＵＥによって使用される無線ベアラ（例えばＩＤ）と関連づけてもよい。第１の実施形態はこのＰＰＰ情報をリレーＵＥに提供する様々な方途を提案しており、したがって第１の実施形態は第２の実施形態と組み合わせて使用することができる。しかしながら、第２の実施形態は上記の点で制限されず、ＰＰＰ ｉｎｆｏをリレーＵＥに提供する何らかの他の（第１の実施形態と異なる）方途が想定されてもよく、したがって第２の実施形態はスタンドアロンである。
図１２に関連して論じたように、アプリケーションレベルシグナリングがリモートＵＥによって初期送信されるとき、リレーＵＥがそれをｅＮｏｄｅＢに送信するために介してもよいシグナリングのための個別無線ベアラは利用可能でなく；シグナリングのための個別ＥＰＳベアラはリレーＵＥとＳＧＷ／ＰＧＷとの間で利用可能でない。結果的に、リレーＵＥは、上記の点で（基本的に常に確立しており、利用可能である）デフォルト無線ベアラを使用し、（実際には高優先度である）アプリケーションレベルシグナリングが無線およびコアネットワークでより低い優先度で送信されるという不利点となる。言い換えると、アプリケーションレベルシグナリングに対する実際に必要とされるＱｏＳは、デフォルト無線／ＥＰＳベアラによってサポートされることはない。
別の課題は、リレーＵＥがどのように、対応する関連に基づいてダウンリンクデータのためにリレー機能性を行うかと関連する。前に説明したように、リレーＵＥでは、アプリケーションレベルシグナリングおよび（リレーＵＥによってｅＮＢにアプリケーションレベルシグナリングを送信するために使用される）デフォルト無線ベアラに与えられる優先度（ＰＰＰＰ）を関連づけるダウンリンクベアラマッピングのために、関連が確立されるものである。しかしながら、この関連は、アプリケーションレベルシグナリングの高優先度がより低い優先度と関連づけられるデフォルト無線ベアラに関連づけられるものであるので正しくない。むしろ、アプリケーションレベルシグナリングは、このアプリケーションレベルシグナリングに実際に対応する優先度、例えばＭＣＰＴＴの場合ＱＣＩ＝６９を持つ個別（無線／ＥＰＳ）ベアラにマッピングされるべきである。
第２の実施形態によれば、最初のアプリケーションレベルシグナリングメッセージに関連して、リモートＵＥによって所定の優先度（ＰＰＰＰ）値が使用され、所定の優先度は、以下に説明することになるように、リレーＵＥでの優先処理をトリガする。アプリケーションレベルシグナリングが、例えばＧＣＳ−ＡＳ（グループ通信システムアプリケーションサーバ）に登録を開始するために、リモートＵＥによって送信されることになることを前提とする。アプリケーションレベルシグナリングを開始している対応するＰｒｏＳｅアプリケーションレイヤは、リレーＵＥとｅＮｏｄｅＢとの間でアプリケーションレベルシグナリングを通知するために個別無線ベアラが利用可能であるか否かに応じて、アプリケーションレベルメッセージに所定の優先度（ＰＰＰＰ値）を割り当てる。特に、アプリケーションレベルシグナリングの初めに、リモートＵＥは、リレーＵＥで個別無線ベアラがまだ利用可能でないことを前提としてもよい。言い換えると、リモートＵＥ（特にＰｒｏＳｅアプリケーションレイヤ）は、それが反対の指示を受信していない限り、アプリケーションレベルシグナリングを通知するのにリレーＵＥで個別無線ベアラが利用可能でないことを前提とすることになる。
結果的に、特に最初のアプリケーションレベルシグナリングメッセージのために、リモートＵＥは、所定の優先度値（ＰＰＰＰ）を選択して、さらにそれをＰＣ５インタフェースを介してリレーＵＥに送信する方法を決定することになる。対応して、所定の優先度値も実際のアプリケーションレベルシグナリングメッセージもリレーＵＥに送信される。例えば、いかなる利用可能なサイドリンクベアラを使用して、リレーＵＥにアプリケーションレベルメッセージを送信してもよい。任意選択で、リモートＵＥは、リレーＵＥにアプリケーションレベルシグナリングを通知するための高優先度を持つサイドリンクベアラを選択／確立してもよい。
次いで、所定の優先度値もアプリケーションレベルシグナリングメッセージも受信するリレーＵＥは、メッセージが優先して扱われることになることを所定の優先度値から学習することになる。優先処理は、アプリケーションレベルシグナリングがｅＮｏｄｅＢにデフォルト無線ベアラを介して送信されるであろう優先度を上げることを伴う。例えば、アプリケーションレベルシグナリングメッセージに対して、論理チャネル優先度が（一時的に）上げられる。１つの例証的な実装によれば、アプリケーションレベルシグナリングメッセージの送信のために使用されるデフォルト無線ベアラは、アップリンク送信のためにリレーＵＥで行われるＬＣＰ手順の間、最高論理チャネル優先度で扱われることになる。より詳細には、デフォルトベアラに対して設定される論理チャネル優先度は一時的に、すなわちアプリケーションレベルシグナリングメッセージの送信のために変更される。
したがって、アプリケーションレベルシグナリングメッセージがＬＣＰ手順の間、優先して扱われるので、リレーＵＥはこれらのメッセージを、デフォルト無線ベアラを介してであるが上昇した優先度で送信することになる。
さらには、リレーＵＥが所定の優先度値を識別すると、それは、その通常動作と反対に、この（所定の）優先度値とデフォルト無線ベアラとの間の関連を作成しない。したがって、リモートＵＥにダウンリンクアプリケーションレベルシグナリングを転送するのに適切な優先度／サイドリンクベアラを識別するためにリレーＵＥで行われるダウンリンクベアラミラーリングは、少なくとも初めは、そのような関連に依存することができない。リレーＵＥが無線ベアラを介してｅＮｏｄｅＢからアプリケーションレベルシグナリングメッセージを受信すると、リレーＵＥは、対応する優先度対無線ベアラ関連がリレーＵＥで利用可能であるか否かを決定することになる。そのような関連が利用可能でない場合、リレーＵＥは、リモートＵＥにアプリケーションレベルシグナリングメッセージを送信するのに利用可能なサイドリンクベアラのいずれかを選択してもよい。任意選択で、リレーＵＥは高優先度サイドリンクベアラを使用するものとし、そのようなベアラが利用可能でなければ、それは、リモートＵＥにアプリケーションレベルシグナリングメッセージを送信する目的で１つ最初に確立するものとする。
図１２に関連して既に論じたように、アプリケーションレベルシグナリングの間、個別無線／ＥＰＳベアラが最終的に確立されることになり、これは次いで、デフォルト無線／ＥＰＳベアラを使用し続ける代わりに、残りのアプリケーションレベルシグナリングメッセージを搬送するために使用されるものとする。例えば、ＭＣＰＴＴ（ミッションクリティカルプッシュツートーク）を前提とすると、ＱＣＩパラメータはＱＣＩ＝６９でもよい。第２の実施形態の目的で、リモートＵＥがシグナリングのための個別（データ）無線ベアラの確立成功について何とか知ることになることを前提とする。例えば、上記個別（データ）無線ベアラを成功裏に確立した上で、リレーＵＥは、リモートＵＥに（例えばＰＣ５−Ｓプロトコルを介して）特定の指示を送信してもよい。代替的に、リモートＵＥにおけるアプリケーションレイヤは、個別無線ベアラが確立されたことを受信した応答メッセージに基づいて知ることになる。結果的に、リモートＵＥは、したがってリレーＵＥに利用可能な新たな個別無線ベアラについて知ることになり、したがって所定の優先度値を使用してリレーＵＥにアップリンクアプリケーションレベルシグナリングメッセージを送信するのをやめることになる。代わりに、リモートＵＥは、通例アプリケーションレベルシグナリングに対応する必要とされる優先度値を使用することになる。結果的に、上記必要とされる優先度をサポートする適切なサイドリンクベアラが、リレーＵＥに後続のアプリケーションレベルシグナリングメッセージを送信するようにリモートＵＥによって選択／確立されることになる。
前述のように、この新たな必要とされる優先度値も、アプリケーションレベルシグナリングメッセージとは別に、またはそれと共にリモートＵＥによってリレーＵＥに送信されることになる。
次いで、リレーＵＥは、例えばＴＦＴに基づいて通例の無線ベアラ選択を行って、新たに確立した個別無線ベアラを選択することになり、それを介してアプリケーションレベルシグナリングメッセージは次いでリレーＵＥからｅＮｏｄｅＢへ送信される。また、ダウンリンクでの適当なベアラマッピングをサポートするのを支援するために、アプリケーションレベルシグナリングと関連づけられる受信した優先度は、前に詳細に説明したように、記憶されて個別無線ベアラと関連づけられることになる。結果的に、無線ベアラを介してｅＮｏｄｅＢからダウンリンクでアプリケーションレベルシグナリングを受信すると、リレーＵＥは、特定の関連を識別することになり、したがって上記無線ベアラと関連づけられる正しい優先度（ＰＰＰＰ）を決定することになり、ＰＣ５インタフェースを介してアプリケーションレベルシグナリングを送信するために使用されるものとなる。ＰＣ５インタフェースに渡って決定した優先度をサポートする対応するサイドリンクベアラが、ｅＮｏｄｅＢから受信されたアプリケーションレベルシグナリングをリモートＵＥに通知するためにリレーＵＥによって選択および使用される。
図１９は、上論した第２の実施形態の特定の実装に係るリモートＵＥでの機能性の処理の一部を例示するシーケンス図である。図２０は、上論した第２の実施形態の特定の実装に係るリレーＵＥでのリレー機能性の処理の一部を例示するシーケンス図である。図２１は、第２の実施形態の特定の実装に係るメッセージの交換および処理ステップを例示するシグナリング図である。
所定の優先度は、優先度のために通例使用される有効値の範囲外であり、かつリモートＵＥおよびリレーＵＥの両方に知られている値を有する。例えば、現在８つの異なるＰＰＰ値が通常使用され、３ビットで区別可能である。所定の優先度値をさらに識別するために、８つのＰＰＰ値のすべてを使用し続けることができつつ、第２の実施形態に従って４ビットを使用してＰＰＰ値を規定してもよい。結果的に、値０〜７（例えば００００〜０１１１）が優先順位付け中に通常使用される値として考えられることができる一方、この有効な値の範囲外の値８〜１５（１０００〜１１１１）のいずれかが第２の実施形態に係る所定の優先度値として使用されることができる。
さらなる実施形態
第１の態様によれば、移動通信ネットワーク内でリモートユーザ機器と交換されるプロトコルデータユニットを中継するためのリレーユーザ機器が提供される。リレーユーザ機器は無線基地局に接続される。リレーユーザ機器は、リモートユーザ機器と無線基地局との間の通信を中継し、リモートユーザ機器とサイドリンクベアラを通じてプロトコルデータユニットを交換する。リレーＵＥの受信器が、第１のサイドリンクベアラを介してリモートユーザ機器から制御パケットを受信し、制御パケットは、第１のサイドリンクベアラを介してリモートユーザ機器によって送信されるプロトコルデータユニットと関連づけられる優先度の指標を備える。リレーＵＥのプロセッサが、制御パケットで受信された優先度指標とリモートユーザ機器から受信されるプロトコルデータパケットを無線基地局に中継するためにリレーユーザ機器によって使用される第１の無線ベアラとの間の関連を記憶する。プロセッサは、第１の無線ベアラを介して無線基地局から受信されたプロトコルデータユニットがリモートユーザ機器に送信されるべきである優先度を、記憶した関連に基づいて決定する。リレーＵＥの送信器が、決定した優先度に対応する第２のサイドリンクベアラを使用してリモートユーザ機器に受信したプロトコルデータユニットを中継する。
第１の態様に加えて提供される第２の態様によれば、制御パケットは、優先度の指標を通知するために意図されるパケットデータ収束プロトコル（ＰＤＣＰ）制御ＰＤＵである。ＰＤＣＰ制御ＰＤＵは、フォーマットインジケータをさらに備える。対応して、リレーＵＥのプロセッサは、受信したＰＤＣＰ制御ＰＤＵに備えられるフォーマットインジケータに基づいて、受信したＰＤＣＰ制御ＰＤＵが優先度の指標を通知するために意図されると決定する。
第１または第２の態様に加えて提供される第３の態様によれば、リレーＵＥのプロセッサは、リモートユーザ機器から受信されたプロトコルデータユニットに含まれる情報およびリレーユーザ機器に記憶される対応するパケットフィルタ規則に基づいて、無線基地局にプロトコルデータユニットを中継するために使用されることになる第１の無線ベアラを決定する。リレーＵＥの送信器は、決定した第１の無線ベアラを使用して無線基地局にプロトコルデータユニットを送信する。任意選択で、リレーＵＥのプロセッサは、第１のサイドリンクベアラを介してリモートユーザ機器から受信される複数のプロトコルデータユニットの最初の１つのための第１の無線ベアラを決定した後にのみ、制御パケットで受信された優先度指標と第１の無線ベアラとの間の関連を生成および記憶する。
第１〜第３の態様の１つに加えて提供される第４の態様によれば、リレーユーザ機器は、無線基地局からプロトコルデータユニットを受信した上で、
リモートユーザ機器に受信したプロトコルデータユニットを中継するように、
− 決定した優先度を持つサイドリンクベアラが利用可能でない場合、決定した優先度を持つ新たな第２のサイドリンクベアラを設定するか、または、
− 決定した優先度を持つサイドリンクベアラが利用可能である場合、決定した優先度に対応する第２のサイドリンクベアラを選択する。
第１〜第４の態様の１つに加えて提供される第５の態様によれば、リレーユーザ機器に記憶された関連は、制御パケットで受信された優先度指標を、リレーユーザ機器によって無線基地局に受信したプロトコルデータユニットを送信するために使用されているその無線ベアラの識別情報と関連づける。
第１〜第５の態様の１つに加えて提供される第６の態様によれば、リレーＵＥの受信器は、さらなるサイドリンクベアラを介してリモートユーザ機器からさらなる制御パケットを受信し、さらなる制御パケットは、さらなるサイドリンクベアラを介してリモートユーザ機器によって送信されるプロトコルデータユニットと関連づけられる優先度のさらなる指標を備える。リレーＵＥのプロセッサは、さらなる制御パケットで受信されたさらなる優先度指標とリモートユーザ機器から受信されるプロトコルデータパケットを無線基地局にさらなるサイドリンクベアラを介して中継するためにリレーユーザ機器によって使用される第２の無線ベアラとの間のさらなる関連を記憶する。リレーＵＥのプロセッサは、第２の無線ベアラを介して無線基地局から受信されたさらなるプロトコルデータユニットがリモートユーザ機器に送信されるべきである優先度を、記憶したさらなる関連に基づいて決定する。リレーＵＥの送信器は、決定したさらなる優先度に対応するさらなるサイドリンクベアラを使用してリモートユーザ機器に受信したプロトコルデータユニットを中継する。
第７の態様によれば、移動通信ネットワーク内でリモートユーザ機器と交換されるプロトコルデータユニットを中継するためのリレーユーザ機器を動作させるための方法が提供される。リレーユーザ機器は無線基地局に接続される。リレーユーザ機器は、リモートユーザ機器と無線基地局との間の通信を中継し、リモートユーザ機器とサイドリンクベアラを通じてプロトコルデータユニットを交換する。方法は以下のステップを含む。リレーＵＥは、第１のサイドリンクベアラを介してリモートユーザ機器から制御パケットを受信し、制御パケットは、第１のサイドリンクベアラを介してリモートユーザ機器によって送信されるプロトコルデータユニットと関連づけられる優先度の指標を備える。リレーＵＥは、制御パケットで受信された優先度指標とリモートユーザ機器から受信されるプロトコルデータパケットを無線基地局に中継するためにリレーユーザ機器によって使用される第１の無線ベアラとの間の関連を記憶する。リレーＵＥは、第１の無線ベアラを介して無線基地局から受信されたプロトコルデータユニットがリモートユーザ機器に送信されるべきである優先度を、記憶した関連に基づいて決定する。リレーＵＥは、決定した優先度に対応する第２のサイドリンクベアラを使用してリモートユーザ機器に受信したプロトコルデータユニットを中継する。
第８の態様によれば、移動通信ネットワーク内で無線基地局に接続されるリレーユーザ機器にプロトコルデータユニットを送信するためのリモートユーザ機器が提供され、ここではリレーユーザ機器は、リモートユーザ機器と無線基地局との間の通信を中継し、リレーユーザ機器とサイドリンクベアラを通じてプロトコルデータユニットを交換する。リモートＵＥは、第１のサイドリンクベアラを介してリレーユーザ機器に制御パケットを送信する送信器を備え、制御パケットは、第１のサイドリンクベアラを介してリモートユーザ機器によってリレーユーザ機器に送信されるプロトコルデータユニットと関連づけられる優先度の指標を含む。
第８の態様に加えて提供される第９の態様によれば、リモートＵＥの送信器は、第１のサイドリンクベアラを介してリレーユーザ機器に送信されることになるプロトコルデータユニットの優先度が変更すると、リレーユーザ機器に制御パケットを送信する。
第９の態様に加えて提供される第１０の態様によれば、リモートＵＥのプロセッサが、プロトコルデータユニットがリモートユーザ機器に送信されることになると決定し、プロトコルデータユニットは優先度と関連づけられる。リモートＵＥのプロセッサは、プロトコルデータユニットがリレーユーザ機器に送信されることになる優先度に対応するサイドリンクベアラがないと決定する。この決定の上で、プロセッサは、上記優先度に対応するリレーユーザ機器へのサイドリンクベアラを設定し、送信器は、設定したサイドリンクベアラを介してリモートユーザ機器にプロトコルデータユニットを送信する前に、設定したサイドリンクベアラを介してリモートユーザ機器に優先度を備える制御パケットを送信する。
第８〜第１０の態様の１つに加えて提供される第１１の態様によれば、送信器は、動作中、制御パケットを所定の回数送信する。
第１２の態様によれば、移動通信ネットワーク内で無線基地局に接続されるリレーユーザ機器にプロトコルデータユニットを送信するためのリモートユーザ機器を動作させるための方法が提供される。リレーユーザ機器は、リモートユーザ機器と無線基地局との間の通信を中継し、リレーユーザ機器とサイドリンクベアラを通じてプロトコルデータユニットを交換する。方法は以下のステップを含む。リモートＵＥは、第１のサイドリンクベアラを介してリレーユーザ機器に制御パケットを送信し、制御パケットは、第１のサイドリンクベアラを介してリモートユーザ機器によってリレーユーザ機器に送信されるプロトコルデータユニットと関連づけられる優先度の指標を含む。
第１３の態様によれば、移動通信ネットワーク内でリモートユーザ機器と交換されるプロトコルデータユニットを中継するためのリレーユーザ機器が提供される。リレーユーザ機器は無線基地局に接続される。リレーユーザ機器は、リモートユーザ機器と無線基地局との間の通信を中継し、リモートユーザ機器とサイドリンクベアラを通じてプロトコルデータユニットを交換する。リレーＵＥの受信器が、第１の所定の優先度と関連づけられるアプリケーションレベルシグナリングメッセージを受信する。リレーＵＥのプロセッサが、第１の所定の優先度に基づいて、デフォルトベアラを使用して無線基地局にアプリケーションレベルシグナリングメッセージを送信すると、かつアプリケーションレベルシグナリングメッセージが無線基地局に送信されることになる優先度を上げると決定する。リレーＵＥの送信器が、デフォルトベアラを介して無線基地局にアプリケーションレベルシグナリングメッセージを上昇した優先度で送信する。
第１３の態様に加えて提供される第１４の態様によれば、リレーＵＥのプロセッサは、第１の所定の優先度をデフォルトベアラと関連して記憶しない。リレーＵＥのプロセッサは、デフォルト無線ベアラを介して無線基地局から受信されるさらなるアプリケーションレベルシグナリングメッセージをリモートユーザ機器に送信するために使用されることになるサイドリンクベアラを決定し、好ましくはここでは、決定したサイドリンクベアラは高優先度を有する。対応して、リレーＵＥの送信器は、決定したサイドリンクベアラを使用してリモートユーザ機器にさらなるアプリケーションレベルシグナリングメッセージを送信する。
第１３または第１４の態様に加えて提供される第１５の態様によれば、個別シグナリング無線ベアラが、リレーユーザ機器と無線基地局との間に設定されて、さらなるアプリケーションレベルシグナリングメッセージを送信するために使用される。個別シグナリング無線ベアラを設定した上で、リレーユーザ機器は、所定の優先度と異なるさらなる優先度と関連づけられるさらなるサイドリンクベアラを使用してリモートユーザ機器にアプリケーションレベルシグナリングメッセージを送信する。
第１３〜第１５の態様の１つに加えて提供される第１６の態様によれば、リレーＵＥのプロセッサは、アプリケーションレベルシグナリングメッセージに関連して論理チャネル優先順位付け手順の間に使用される優先度を上げることによって、アプリケーションレベルシグナリングメッセージが無線基地局に送信される優先度を上げる。
第１７の態様によれば、移動通信ネットワーク内でリモートユーザ機器と交換されるプロトコルデータユニットを中継するためのリレーユーザ機器を動作させるための方法が提供される。リレーユーザ機器は無線基地局に接続される。リレーユーザ機器は、リモートユーザ機器と無線基地局との間の通信を中継し、リモートユーザ機器とサイドリンクベアラを通じてプロトコルデータユニットを交換する。方法は以下のステップを含む。リレーＵＥは、所定の優先度と関連づけられるアプリケーションレベルシグナリングメッセージを受信する。リレーＵＥは、デフォルトベアラを使用して無線基地局にアプリケーションレベルシグナリングメッセージを送信すると、かつアプリケーションレベルシグナリングメッセージが無線基地局に送信されることになる優先度を上げると、所定の優先度に基づいて決定する。リレーＵＥは、デフォルトベアラを介して無線基地局にアプリケーションレベルシグナリングメッセージを上昇した優先度で送信する。
第１８の態様によれば、移動通信ネットワーク内で無線基地局に接続されるリレーユーザ機器にプロトコルデータユニットを送信するためのリモートユーザ機器が提供される。リレーユーザ機器は、リモートユーザ機器と無線基地局との間の通信を中継し、リモートユーザ機器とサイドリンクベアラを通じてプロトコルデータユニットを交換する。リモートユーザ機器のプロセッサが、リレーユーザ機器に送信されることになるアプリケーションレベルシグナリングメッセージと関連づけられることになる所定の優先度を決定する。リモートＵＥの送信器が、アプリケーションレベルシグナリングメッセージが無線基地局に送信されることになる優先度を上げるようにリレーユーザ機器に示すように、リレーユーザ機器にアプリケーションレベルシグナリングメッセージおよび関連する所定の優先度を送信する。
第１８の態様に加えて提供される第１９の態様によれば、リモートユーザ機器は、高優先度を持つサイドリンクベアラを使用して、関連する所定の優先度を持つアプリケーションレベルシグナリングメッセージをリレーユーザ機器に送信する。
第１８または第１９の態様に加えて提供される第２０の態様によれば、所定の優先度は、リレーユーザ機器が第１の所定の優先度を、リレーユーザ機器によって無線基地局にアプリケーションレベルシグナリングメッセージを送信するために使用されることになるデフォルトベアラと関連して記憶しないものとすることを示すように、アプリケーションレベルシグナリングメッセージに対して設定される。
第２１の態様によれば、移動通信ネットワーク内で無線基地局に接続されるリレーユーザ機器にプロトコルデータユニットを送信するためのリモートユーザ機器を動作させるための方法が提供される。リレーユーザ機器は、リモートユーザ機器と無線基地局との間の通信を中継し、リモートユーザ機器とサイドリンクベアラを通じてプロトコルデータユニットを交換する。方法は以下のステップを含む。リモートＵＥは、リレーユーザ機器に送信されることになるアプリケーションレベルシグナリングメッセージと関連づけられることになる所定の優先度を決定する。リモートＵＥは、アプリケーションレベルシグナリングメッセージが無線基地局に送信されることになる優先度を上げるようにリレーユーザ機器に示すように、リレーユーザ機器にアプリケーションレベルシグナリングメッセージおよび関連する所定の優先度を送信する。
＜本開示のハードウェアおよびソフトウェア実装＞
他の例示的な実施形態は、ハードウェア、ソフトウェア、またはハードウェアと協働したソフトウェアを使用する上記した様々な実施形態の実装に関する。これに関連して、ユーザ端末（移動端末）およびｅＮｏｄｅＢ（基地局）が提供される。ユーザ端末および基地局は、受信器、送信器、プロセッサなど、本明細書に記載した方法に適切に関与する対応するエンティティを含め、同方法を行う。
様々な実施形態がコンピューティング装置（プロセッサ）を使用して実装されてもまたは行われてもよいとさらに認識される。コンピューティング装置またはプロセッサは、例えば汎用プロセッサ、デジタル信号プロセッサ（ＤＳＰ：Digital Signal Processor）、特定用途向け集積回路（ＡＳＩＣ：Application Specific Integrated Circuit）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ：Field Programmable Gate Array）または他のプログラマブル論理装置などでもよい。様々な実施形態はこれらの装置の組合せによって行われてもまたは具象化されてもよい。特に、上記した各実施形態の記載に使用される各機能ブロックは、集積回路としてのＬＳＩによって実現されることができる。それらはチップとして個々に形成されてもよいし、または１つのチップが、機能ブロックの一部または全部を含むように形成されてもよい。それらは、そこに結合されるデータ入出力を含んでもよい。ＬＳＩはここで、集積度の相違に応じて、ＩＣ、システムＬＳＩ、超ＬＳＩまたは極超ＬＳＩと称されてもよい。しかしながら、集積回路を実装する技術はＬＳＩに限定されず、専用回路または汎用プロセッサを使用することによって実現されてもよい。加えて、ＬＳＩの製造後にプログラムされることができるＦＰＧＡ（Field Programmable Gate Array）、またはＬＳＩ内部に設けられる回路セルの接続および設定が再構成されることができる再構成可能プロセッサが使用されてもよい。
さらに、様々な実施形態はソフトウェアモジュールを用いて実装されてもよく、ソフトウェアモジュールはプロセッサによってまたはハードウェアで直接実行される。また、ソフトウェアモジュールおよびハードウェア実装の組合せも可能だろう。ソフトウェアモジュールは任意の種類のコンピュータ可読記憶媒体、例えばＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、レジスタ、ハードディスク、ＣＤ−ＲＯＭ、ＤＶＤなどに記憶されてもよい。異なる実施形態の個々の特徴が個々にまたは任意の組合せで別の実施形態の主題であることにさらに留意するべきである。
当業者によって、多数の変形および／または修正が具体的な実施形態に示すように本開示になされてもよいことが認識されるであろう。本実施形態は、したがって、すべての点で例示的であり限定的でないと考えられるべきである。

Claims (15)

  1. 移動通信ネットワーク内でリモートユーザ機器と交換されるプロトコルデータユニットを中継するためのリレーユーザ機器であって、前記リレーユーザ機器が、無線基地局に接続され、前記リレーユーザ機器が、前記リモートユーザ機器と前記無線基地局との間の通信を中継し、かつ前記リモートユーザ機器とサイドリンクベアラを通じて前記プロトコルデータユニットを交換し、
    動作中、第１のサイドリンクベアラを介して前記リモートユーザ機器から制御パケットを受信し、前記制御パケットが、前記第１のサイドリンクベアラを介して前記リモートユーザ機器によって送信されるプロトコルデータユニットと関連づけられる優先度の指標を含む、受信器と、
    動作中、前記制御パケットで受信された前記優先度指標と前記リモートユーザ機器から受信される前記プロトコルデータパケットを前記無線基地局に中継するために前記リレーユーザ機器によって使用される第１の無線ベアラとの間の関連を記憶するプロセッサであって、
    動作中、前記第１の無線ベアラを介して前記無線基地局から受信されたプロトコルデータユニットが前記リモートユーザ機器に送信されるべきである前記優先度を、前記記憶した関連に基づいて決定するプロセッサと、
    動作中、前記決定した優先度に対応する第２のサイドリンクベアラを使用して前記リモートユーザ機器に前記受信したプロトコルデータユニットを中継する送信器とを備える、リレーユーザ機器。
  2. 前記制御パケットが、前記優先度の前記指標を通知するために意図されるパケットデータ収束プロトコル（ＰＤＣＰ）制御ＰＤＵであり、前記ＰＤＣＰ制御ＰＤＵが、フォーマットインジケータをさらに備え、
    前記プロセッサが、動作中、前記受信したＰＤＣＰ制御ＰＤＵに備えられる前記フォーマットインジケータに基づいて、前記受信したＰＤＣＰ制御ＰＤＵが前記優先度の前記指標を通知するために意図されると決定する、請求項１に記載のリレーユーザ機器。
  3. 前記プロセッサが、動作中、前記リモートユーザ機器から受信された前記プロトコルデータユニットに含まれる情報および前記リレーユーザ機器に記憶される対応するパケットフィルタ規則に基づいて、前記無線基地局に前記プロトコルデータユニットを中継するために使用されることになる前記第１の無線ベアラを決定し、
    前記送信器が、動作中、前記決定した第１の無線ベアラを使用して前記無線基地局に前記プロトコルデータユニットを送信し、かつ、
    好ましくは、前記プロセッサが、動作中、前記第１のサイドリンクベアラを介して前記リモートユーザ機器から受信される複数のプロトコルデータユニットの最初の１つのための前記第１の無線ベアラを決定した後にのみ、前記制御パケットで受信された前記優先度指標と前記第１の無線ベアラとの間の前記関連を生成および記憶する、請求項１または２に記載のリレーユーザ機器。
  4. 前記リレーユーザ機器が、前記無線基地局から前記プロトコルデータユニットを受信した上で、
    前記リモートユーザ機器に前記受信したプロトコルデータユニットを中継するように、
    前記決定した優先度を持つサイドリンクベアラが利用可能でない場合、前記決定した優先度を持つ新たな第２のサイドリンクベアラを設定するか、または、
    前記決定した優先度を持つサイドリンクベアラが利用可能である場合、前記決定した優先度に対応する前記第２のサイドリンクベアラを選択する、請求項１〜３のいずれか一項に記載のリレーユーザ機器。
  5. 移動通信ネットワーク内でリモートユーザ機器と交換されるプロトコルデータユニットを中継するためのリレーユーザ機器を動作させるための方法であって、前記リレーユーザ機器が、無線基地局に接続され、前記リレーユーザ機器が、前記リモートユーザ機器と前記無線基地局との間の通信を中継し、かつ前記リモートユーザ機器とサイドリンクベアラを通じて前記プロトコルデータユニットを交換し、前記リレーユーザ機器によって行われる、
    第１のサイドリンクベアラを介して前記リモートユーザ機器から制御パケットを受信し、前記制御パケットが、前記第１のサイドリンクベアラを介して前記リモートユーザ機器によって送信されるプロトコルデータユニットと関連づけられる優先度の指標を含む、ステップと、
    前記制御パケットで受信された前記優先度指標と前記リモートユーザ機器から受信される前記プロトコルデータパケットを前記無線基地局に中継するために前記リレーユーザ機器によって使用される第１の無線ベアラとの間の関連を記憶するステップと、
    前記第１の無線ベアラを介して前記無線基地局から受信されたプロトコルデータユニットが前記リモートユーザ機器に送信されるべきである前記優先度を、前記記憶した関連に基づいて決定するステップと、
    前記決定した優先度に対応する第２のサイドリンクベアラを使用して前記リモートユーザ機器に受信したプロトコルデータユニットを中継するステップとを含む、方法。
  6. 移動通信ネットワーク内で無線基地局に接続されるリレーユーザ機器にプロトコルデータユニットを送信するためのリモートユーザ機器であって、前記リレーユーザ機器が、前記リモートユーザ機器と前記無線基地局との間の通信を中継し、かつ前記リレーユーザ機器とサイドリンクベアラを通じてプロトコルデータユニットを交換し、
    動作中、第１のサイドリンクベアラを介して前記リレーユーザ機器に制御パケットを送信し、前記制御パケットが、前記第１のサイドリンクベアラを介して前記リモートユーザ機器によって前記リレーユーザ機器に送信されるプロトコルデータユニットと関連づけられる優先度の指標を含む、送信器を備える、リモートユーザ機器。
  7. 前記送信器が、動作中、前記第１のサイドリンクベアラを介して前記リレーユーザ機器に送信されることになるプロトコルデータユニットの前記優先度が変更すると、前記リレーユーザ機器に制御パケットを送信する、請求項６に記載のリモートユーザ機器。
  8. 動作中、プロトコルデータユニットが前記リモートユーザ機器に送信されることになると決定し、前記プロトコルデータユニットが、優先度と関連づけられる、プロセッサをさらに備え、
    前記プロセッサが、動作中、前記プロトコルデータユニットが前記リレーユーザ機器に送信されることになる優先度に対応するサイドリンクベアラがないと決定し、前記決定の上で、前記プロセッサが、前記優先度に対応する前記リレーユーザ機器へのサイドリンクベアラを設定し、前記送信器が、前記設定したサイドリンクベアラを介して前記リモートユーザ機器に前記プロトコルデータユニットを送信する前に、前記設定したサイドリンクベアラを介して前記リモートユーザ機器に前記優先度を含む前記制御パケットを送信する、請求項７に記載のリモートユーザ機器。
  9. 移動通信ネットワーク内で無線基地局に接続されるリレーユーザ機器にプロトコルデータユニットを送信するためのリモートユーザ機器を動作させるための方法であって、前記リレーユーザ機器が、前記リモートユーザ機器と前記無線基地局との間の通信を中継し、かつ前記リレーユーザ機器とサイドリンクベアラを通じてプロトコルデータユニットを交換し、前記リモートユーザ機器によって行われる、
    第１のサイドリンクベアラを介して前記リレーユーザ機器に制御パケットを送信し、前記制御パケットが、前記第１のサイドリンクベアラを介して前記リモートユーザ機器によって前記リレーユーザ機器に送信されるプロトコルデータユニットと関連づけられる優先度の指標を含む、ステップを含む、方法。
  10. 移動通信ネットワーク内でリモートユーザ機器と交換されるプロトコルデータユニットを中継するためのリレーユーザ機器であって、前記リレーユーザ機器が、無線基地局に接続され、前記リレーユーザ機器が、前記リモートユーザ機器と前記無線基地局との間の通信を中継し、かつ前記リモートユーザ機器とサイドリンクベアラを通じて前記プロトコルデータユニットを交換し、
    動作中、所定の優先度と関連づけられるアプリケーションレベルシグナリングメッセージを受信する受信器と、
    動作中、前記所定の優先度に基づいて、デフォルトベアラを使用して前記無線基地局に前記アプリケーションレベルシグナリングメッセージを送信すると、かつ前記アプリケーションレベルシグナリングメッセージが前記無線基地局に送信されることになる優先度を上げると決定するプロセッサと、
    動作中、前記デフォルトベアラを介して前記無線基地局に前記アプリケーションレベルシグナリングメッセージを前記上昇した優先度で送信する送信器とを備える、リレーユーザ機器。
  11. 前記プロセッサが、動作中、前記所定の優先度を前記デフォルトベアラと関連して記憶せず、
    前記プロセッサが、動作中、前記デフォルト無線ベアラを介して前記無線基地局から受信されるさらなるアプリケーションレベルシグナリングメッセージを前記リモートユーザ機器に送信するために使用されることになるサイドリンクベアラを決定し、好ましくは前記決定したサイドリンクベアラが、高優先度を有し、かつ、
    前記送信器が、動作中、前記決定したサイドリンクベアラを使用して前記リモートユーザ機器に前記さらなるアプリケーションレベルシグナリングメッセージを送信する、請求項１０に記載のリレーユーザ機器。
  12. 個別無線ベアラが、前記リレーユーザ機器と前記無線基地局との間に設定されて、さらなるアプリケーションレベルシグナリングメッセージを送信するために使用され、
    前記個別シグナリング無線ベアラを設定した上で、前記リレーユーザ機器が、前記所定の優先度と異なるさらなる優先度と関連づけられるさらなるサイドリンクベアラを使用して前記リモートユーザ機器にアプリケーションレベルシグナリングメッセージを送信する、請求項１０または１１に記載のリレーユーザ機器。
  13. 移動通信ネットワーク内でリモートユーザ機器と交換されるプロトコルデータユニットを中継するためのリレーユーザ機器を動作させるための方法であって、前記リレーユーザ機器が、無線基地局に接続され、前記リレーユーザ機器が、前記リモートユーザ機器と前記無線基地局との間の通信を中継し、かつ前記リモートユーザ機器とサイドリンクベアラを通じて前記プロトコルデータユニットを交換し、前記リレーユーザ機器によって行われる、
    所定の優先度と関連づけられるアプリケーションレベルシグナリングメッセージを受信するステップと、
    デフォルトベアラを使用して前記無線基地局に前記アプリケーションレベルシグナリングメッセージを送信すると、かつ前記アプリケーションレベルシグナリングメッセージが前記無線基地局に送信されることになる優先度を上げると、前記所定の優先度に基づいて決定するステップと、
    前記デフォルトベアラを介して前記無線基地局に前記アプリケーションレベルシグナリングメッセージを前記上昇した優先度で送信するステップとを含む、方法。
  14. 移動通信ネットワーク内で無線基地局に接続されるリレーユーザ機器にプロトコルデータユニットを送信するためのリモートユーザ機器であって、前記リレーユーザ機器が、前記リモートユーザ機器と前記無線基地局との間の通信を中継し、かつ前記リモートユーザ機器とサイドリンクベアラを通じてプロトコルデータユニットを交換し、
    動作中、前記リレーユーザ機器に送信されることになるアプリケーションレベルシグナリングメッセージと関連づけられることになる所定の優先度を決定するプロセッサと、
    動作中、前記アプリケーションレベルシグナリングメッセージが前記無線基地局に送信されることになる優先度を上げるように前記リレーユーザ機器に示すように、前記リレーユーザ機器に前記アプリケーションレベルシグナリングメッセージおよび前記関連する所定の優先度を送信する送信器とを備える、リモートユーザ機器。
  15. 移動通信ネットワーク内で無線基地局に接続されるリレーユーザ機器にプロトコルデータユニットを送信するためのリモートユーザ機器を動作させるための方法であって、前記リレーユーザ機器が、前記リモートユーザ機器と前記無線基地局との間の通信を中継し、かつ前記リモートユーザ機器とサイドリンクベアラを通じてプロトコルデータユニットを交換し、前記リモートユーザ機器によって行われる、
    前記リレーユーザ機器に送信されることになるアプリケーションレベルシグナリングメッセージと関連づけられることになる所定の優先度を決定するステップと、
    前記アプリケーションレベルシグナリングメッセージが前記無線基地局に送信されることになる優先度を上げるように前記リレーユーザ機器に示すように、前記リレーユーザ機器に前記アプリケーションレベルシグナリングメッセージおよび前記関連する所定の優先度を送信するステップとを含む、方法。
JP2018500752A 2015-09-25 2016-08-08 ＰｒｏＳｅリレーのための改善されたベアラマッピング Active JP6849651B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
EP15186950.0 2015-09-25
EP15186950.0A EP3148285B1 (en) 2015-09-25 2015-09-25 Improved radio bearer mapping for proximity services ue to network relay with associated priority signalling
PCT/JP2016/003635 WO2017051494A1 (en) 2015-09-25 2016-08-08 Improved bearer mapping for prose relay

Publications (2)

Publication Number Publication Date
JP2018533235A true JP2018533235A (ja) 2018-11-08
JP6849651B2 JP6849651B2 (ja) 2021-03-24

Family

ID=54251991

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2018500752A Active JP6849651B2 (ja) 2015-09-25 2016-08-08 ＰｒｏＳｅリレーのための改善されたベアラマッピング

Country Status (4)

Country Link
US (1) US10805858B2 (ja)
EP (1) EP3148285B1 (ja)
JP (1) JP6849651B2 (ja)
WO (1) WO2017051494A1 (ja)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2020184752A (ja) * 2019-05-02 2020-11-12 華碩電腦股▲ふん▼有限公司 無線通信システムにおけるユニキャスト伝送のサイドリンク無線ベアラ（ｓｌｒｂ）設定を要求するための方法および装置
KR20210065850A (ko) * 2019-11-26 2021-06-04 아서스테크 컴퓨터 인코포레이션 무선 통신 시스템에서 사이드링크 시그널링 라디오 베어러(srb) 설정을 위한 방법 및 장치
JP2022527772A (ja) * 2019-03-28 2022-06-06 華為技術有限公司 無線ベアラ構成方法、装置及びシステム
JP2022549614A (ja) * 2019-09-20 2022-11-28 大唐移▲動▼通信▲設▼▲備▼有限公司 直接通信インターフェースベアラ構成変更方法及び端末
JP2023523071A (ja) * 2020-04-28 2023-06-01 維沃移動通信有限公司 遠端端末の接続管理方法、端末及びネットワーク側機器

Families Citing this family (79)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2016159728A1 (ko) * 2015-04-01 2016-10-06 삼성전자 주식회사 D2d 통신 시스템에서 우선 순위를 처리하는 방법 및 장치
WO2016172887A1 (zh) * 2015-04-29 2016-11-03 华为技术有限公司 一种数据传输方法、设备及系统
EP3145269A1 (en) * 2015-09-16 2017-03-22 Alcatel Lucent Method, devices and system for a hybrid bearer service
EP3353939B1 (en) * 2015-09-25 2022-08-17 Telefonaktiebolaget LM Ericsson (PUBL) Per-packet resource pool selection in lte v2x system
EP3148285B1 (en) * 2015-09-25 2019-04-17 Panasonic Intellectual Property Corporation of America Improved radio bearer mapping for proximity services ue to network relay with associated priority signalling
WO2017069430A1 (ko) * 2015-10-22 2017-04-27 엘지전자 주식회사 무선 통신 시스템에서 단말 간의 직접 통신 방법 및 이를 위한 장치
EP3376788B1 (en) * 2015-12-31 2019-09-18 Huawei Technologies Co., Ltd. Method for user equipment to access network, core network entity, base station, and first ue
US10271370B2 (en) * 2016-02-12 2019-04-23 Ofinno Technologies, Llc Mission critical communications
WO2017146710A1 (en) * 2016-02-25 2017-08-31 Nokia Solutions And Networks Oy Techniques for providing proximity services (prose) priority-related information to a base station in a wireless network
JP6714707B2 (ja) * 2016-03-30 2020-06-24 オッポ広東移動通信有限公司Ｇｕａｎｇｄｏｎｇ Ｏｐｐｏ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｃｏｒｐ．， Ｌｔｄ． 中継伝送方法
CN108370592B (zh) * 2016-03-30 2021-01-29 华为技术有限公司 承载切换方法及基站设备、网络节点
WO2017206186A1 (zh) 2016-06-03 2017-12-07 广东欧珀移动通信有限公司 中继传输的方法和装置
WO2018053692A1 (zh) * 2016-09-20 2018-03-29 北京小米移动软件有限公司 数据传输方法、装置及系统
ES2854985T3 (es) * 2016-09-29 2021-09-23 Nokia Technologies Oy Conmutación del portador radioeléctrico en el acceso radioeléctrico
WO2018062857A1 (ko) * 2016-09-30 2018-04-05 엘지전자 주식회사 무선 통신 시스템에서 우선 순위를 기반으로 단말 자체적으로 자원을 재선택하는 방법 및 장치
CN106717102B (zh) * 2016-11-09 2020-07-03 北京小米移动软件有限公司 控制协议数据单元pdu发送方法及装置
US10420128B2 (en) * 2016-11-11 2019-09-17 Qualcomm Incorporated Uplink data transfer for wireless communications with mixed transmission time intervals
US11665730B2 (en) * 2017-01-09 2023-05-30 Interdigital Patent Holdings, Inc. Relay for wireless communication system
US10484517B2 (en) * 2017-02-10 2019-11-19 Qualcomm Incorporated Quality of service support for layer 2 based device-to-device relay
US10999843B2 (en) * 2017-02-10 2021-05-04 Lg Electronics Inc. Method and apparatus for calculating channel occupancy ratio in wireless communication system
US11696219B2 (en) 2017-04-28 2023-07-04 Guangdong Oppo Mobile Telecommunications Corp., Ltd. Data transmission method, terminal apparatus, and network apparatus
EP3493633B1 (en) * 2017-05-05 2020-12-30 Guangdong Oppo Mobile Telecommunications Corp., Ltd. Method for allocating logical channel resources and terminal device
GB2562220A (en) 2017-05-05 2018-11-14 Tcl Communication Ltd Methods and devices associated with direct communications in a radio access network
CN108834107B (zh) * 2017-05-05 2020-12-18 上海诺基亚贝尔股份有限公司 用于旁链路发现的方法和设备
US10912114B2 (en) * 2017-05-05 2021-02-02 Qualcomm Incorporated Relaying in a device-to-device communication system
WO2018219436A1 (en) * 2017-05-30 2018-12-06 Huawei Technologies Co., Ltd. Devices and methods for communication in a wireless communication network
CN109005527B (zh) * 2017-06-06 2022-07-12 华为技术有限公司 一种数据传输方法和终端
WO2018228597A1 (zh) * 2017-06-16 2018-12-20 华为技术有限公司 通信方法、终端及基站
WO2019033416A1 (zh) * 2017-08-18 2019-02-21 Oppo广东移动通信有限公司 无线通信的方法、终端设备和网络设备
RU2020111322A (ru) * 2017-09-29 2021-09-20 Сони Корпорейшн Устройство связи и способ связи
TWI711327B (zh) 2018-04-03 2020-11-21 美商Ｉｄａｃ控股公司 合作車間有效資源使用方法
US11006312B2 (en) * 2018-04-06 2021-05-11 Apple Inc. PDCP packet-based DDDS frame transmission
US11589257B2 (en) * 2018-04-10 2023-02-21 Lg Electronics Inc. Method for performing a logical channel prioritization (LCP) procedure by a relay UE in wireless communication system and a device therefor
US20190364424A1 (en) * 2018-05-28 2019-11-28 Qualcomm Incorporated Roll-over of identifiers and keys for unicast vehicle to vehicle communication links
CN110831075A (zh) * 2018-08-10 2020-02-21 中兴通讯股份有限公司 数据传输方法及装置，业务切换方法及装置
CN113556786A (zh) * 2018-08-10 2021-10-26 瑞典爱立信有限公司 用于控制副链路QoS的方法和装置
US11115890B2 (en) * 2018-08-16 2021-09-07 Lg Electronics Inc. Method and apparatus for triggering transmission carrier reselection procedure due to high congestion level in wireless communication system
US11070954B2 (en) * 2018-09-21 2021-07-20 Qualcomm Incorporated Distributed QoS control for multicast
CN110958704B (zh) * 2018-09-26 2022-02-22 维沃移动通信有限公司 一种资源调度方法和装置
CN112956275A (zh) * 2018-09-27 2021-06-11 弗劳恩霍夫应用研究促进协会 新无线电侧链帧结构
CN110972103B (zh) * 2018-09-28 2021-06-15 华为技术有限公司 一种通信方法及装置
US20200128469A1 (en) * 2018-10-19 2020-04-23 Huawei Technologies Co., Ltd. Method and system for network routing
US11224007B2 (en) * 2018-11-19 2022-01-11 Huawei Technologies Co., Ltd. System and method for supporting sidelink radio bearers
US11457355B2 (en) * 2019-01-04 2022-09-27 Asustek Computer Inc. Method and apparatus for supporting vehicle-to-everything (V2X) services on single one-to-one sidelink communication link in a wireless communication system
US11553542B2 (en) * 2019-01-11 2023-01-10 Qualcomm Incorporated Device-to-device signaling
KR20200094343A (ko) 2019-01-30 2020-08-07 삼성전자주식회사 무선 통신 시스템에서 직접 통신 베어러의 서비스 품질을 관리 및 설정하는 장치 및 방법
CN113475158A (zh) * 2019-02-13 2021-10-01 康维达无线有限责任公司 用于5g中面向连接的车辆对x(vtx)通信的装置、系统、方法和计算机可读介质
US11277880B2 (en) * 2019-02-14 2022-03-15 Lg Electronics Inc. Sidelink connection suspension or release based on different target qualities of different services
CN112153708A (zh) * 2019-06-29 2020-12-29 华为技术有限公司 一种通信方法及相关设备
KR20210003632A (ko) * 2019-07-02 2021-01-12 삼성전자주식회사 무선 통신 시스템에서 사이드링크 데이터 베어러 설정 방법 및 장치
US11026246B2 (en) * 2019-07-23 2021-06-01 Qualcomm Incorporated Techniques for prioritizing transmission of types of wireless communications
US11395294B2 (en) * 2019-08-16 2022-07-19 Mediatek Inc. Method and apparatus for resource selection of multiple transmission occasions in new radio sidelink communications
CN114945159A (zh) * 2019-10-30 2022-08-26 大唐移动通信设备有限公司 直接通信的处理方法、装置、中继终端及远端终端
JP7394991B2 (ja) * 2019-11-07 2023-12-08 中興通訊股▲ふん▼有限公司 無線通信ネットワークにおけるサイドリンク通信のためのシステムおよび方法
WO2021097808A1 (en) * 2019-11-22 2021-05-27 Mediatek Singapore Pte. Ltd. Methods and apparatus of adaptation handling for sidelink relay
JP7317236B2 (ja) * 2019-12-13 2023-07-28 北京小米移動軟件有限公司 データ処理方法、データ処理装置、通信機器及び記憶媒体
US11528769B2 (en) * 2019-12-20 2022-12-13 Qualcomm Incorporated Unicast link radio link failure detection and management
US20230023254A1 (en) * 2019-12-23 2023-01-26 Nokia Technologies Oy Method, apparatus, and computer program product for alternative quality of service profile notification handling
WO2021134163A1 (en) * 2019-12-30 2021-07-08 Mediatek Singapore Pte. Ltd. Methods and apparatus of early packet filtering for sidelink ue discovery
WO2021138868A1 (en) * 2020-01-09 2021-07-15 Mediatek Singapore Pte. Ltd. Methods and apparatus of sidelink configuration and traffic forwarding for layer-2 ue-to-ue relay
US11700654B2 (en) * 2020-01-31 2023-07-11 Qualcomm Incorporated User equipment to network relay
WO2021167314A1 (en) * 2020-02-17 2021-08-26 Samsung Electronics Co., Ltd. Method and apparatus for handling security policies in v2x communication system
US20230053351A1 (en) * 2020-02-29 2023-02-23 Qualcomm Incorporated Techniques for selecting and reselecting sidelink relay
CN116709424A (zh) * 2020-04-03 2023-09-05 华为技术有限公司 一种临近服务的数据传输方法、设备及系统
CN113660680B (zh) * 2020-05-12 2023-11-07 维沃移动通信有限公司 副链路中继架构中的配置方法和设备
CN113747537A (zh) * 2020-05-28 2021-12-03 维沃移动通信有限公司 优先级确定方法和设备
CN113825204A (zh) * 2020-06-18 2021-12-21 华硕电脑股份有限公司 无线通信系统中执行pc5单播链路建立过程的方法和设备
CN113825109A (zh) * 2020-06-18 2021-12-21 华硕电脑股份有限公司 无线通信系统中中继传送直接通信请求消息的方法和设备
US20220039145A1 (en) * 2020-07-28 2022-02-03 Qualcomm Incorporated User equipment (ue) assisted uplink (ul) transmission
CN115769662A (zh) * 2020-08-05 2023-03-07 Oppo广东移动通信有限公司 无线通信方法和终端设备
WO2022040828A1 (en) * 2020-08-23 2022-03-03 Qualcomm Incorporated Layer 2 relay initial configuration
CN116114300A (zh) * 2020-09-17 2023-05-12 华为技术有限公司 一种通信方法及装置
CN114666848A (zh) * 2020-12-24 2022-06-24 夏普株式会社 QoS分割和携带方法、对象侧QoS确定方法及UE
EP4255090A4 (en) * 2021-01-28 2023-12-20 Guangdong Oppo Mobile Telecommunications Corp., Ltd. DATA TRANSMISSION METHOD, TERMINAL DEVICES AND NETWORK DEVICE
WO2022217540A1 (zh) * 2021-04-15 2022-10-20 Oppo广东移动通信有限公司 无线通信方法、设备及存储介质
BR112023024745A2 (pt) * 2021-06-07 2024-02-15 Qualcomm Inc Arquitetura de conectividade dupla e procedimentos de configuração
CN115550911A (zh) * 2021-06-30 2022-12-30 华为技术有限公司 中继通信方法、装置及系统
CN115885572A (zh) * 2021-07-28 2023-03-31 北京小米移动软件有限公司 一种通信方法、装置、用户设备、基站、核心网设备及存储介质
CN114501345A (zh) * 2022-04-15 2022-05-13 希诺麦田技术（深圳）有限公司 组呼全双工实现方法、装置及系统

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008069616A2 (en) * 2006-12-07 2008-06-12 Lg Electronics Inc. Methods of transferring data in a wireless communication system
US20090010258A1 (en) * 2007-07-03 2009-01-08 Motorola, Inc. Packet prioritization in ad hoc networks
JP4704482B2 (ja) * 2009-06-08 2011-06-15 株式会社エヌ・ティ・ティ・ドコモ 移動通信システム、リレーノード、無線基地局及びゲートウェイ装置
US9144007B2 (en) * 2009-10-16 2015-09-22 Architecture Technology, Inc. Wireless infrastructure access network and method for communication on such network
GB2484915B (en) * 2010-10-22 2013-10-23 Toshiba Res Europ Ltd Forwarding and routing in sensor networks
EP3148285B1 (en) * 2015-09-25 2019-04-17 Panasonic Intellectual Property Corporation of America Improved radio bearer mapping for proximity services ue to network relay with associated priority signalling

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
3GPP TS36.323 V12.4.0, JPN6020023924, 8 July 2015 (2015-07-08), pages 25, ISSN: 0004299808 *
ERICSSON: "Impact of PPP on user plane", 3GPP TSG-RAN WG2 #91 R2-153480, JPN6020023922, 14 August 2015 (2015-08-14), pages 1 - 5, ISSN: 0004299806 *
HUAWEI, HISILICON: "D2D PDCP Header Format and Procedures", 3GPP TSG RAN WG2 MEETING #87BIS R2-144606, JPN6020023923, 27 September 2014 (2014-09-27), pages 1 - 3, ISSN: 0004299807 *

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2022527772A (ja) * 2019-03-28 2022-06-06 華為技術有限公司 無線ベアラ構成方法、装置及びシステム
JP7270766B2 (ja) 2019-03-28 2023-05-10 華為技術有限公司 無線ベアラ構成方法、装置及びシステム
JP2020184752A (ja) * 2019-05-02 2020-11-12 華碩電腦股▲ふん▼有限公司 無線通信システムにおけるユニキャスト伝送のサイドリンク無線ベアラ（ｓｌｒｂ）設定を要求するための方法および装置
JP2022549614A (ja) * 2019-09-20 2022-11-28 大唐移▲動▼通信▲設▼▲備▼有限公司 直接通信インターフェースベアラ構成変更方法及び端末
KR20210065850A (ko) * 2019-11-26 2021-06-04 아서스테크 컴퓨터 인코포레이션 무선 통신 시스템에서 사이드링크 시그널링 라디오 베어러(srb) 설정을 위한 방법 및 장치
KR102364868B1 (ko) 2019-11-26 2022-02-18 아서스테크 컴퓨터 인코포레이션 무선 통신 시스템에서 사이드링크 시그널링 라디오 베어러(srb) 설정을 위한 방법 및 장치
JP2023523071A (ja) * 2020-04-28 2023-06-01 維沃移動通信有限公司 遠端端末の接続管理方法、端末及びネットワーク側機器

Also Published As

Publication number Publication date
EP3148285B1 (en) 2019-04-17
US10805858B2 (en) 2020-10-13
EP3148285A1 (en) 2017-03-29
WO2017051494A1 (en) 2017-03-30
JP6849651B2 (ja) 2021-03-24
US20180255499A1 (en) 2018-09-06

Similar Documents

Publication Publication Date Title
JP6849651B2 (ja) ＰｒｏＳｅリレーのための改善されたベアラマッピング
JP6652577B2 (ja) リモートｕｅに応対するｐｒｏｓｅリレーのための改善されたスケジューリングメカニズム
JP7402902B2 (ja) 改善されたＰｒｏＳｅリレーＵＥ有効化
US10701549B2 (en) Procedures for grouping wearable devices with LTE master UEs
JP6669853B2 (ja) Ｄ２ｄ通信システムにおいてバッファ状態報告を行う方法及びその装置
JP6594460B2 (ja) 近接サービスのための改善されたリレーｕｅディスカバリ
US20190053251A1 (en) Priority-optimized sidelink data transfer in the case of autonomous resource allocation in lte prose communication

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20190306

RD02 Notification of acceptance of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7422

Effective date: 20190717

RD04 Notification of resignation of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7424

Effective date: 20191114

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20200707

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20200914

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20210302

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20210304

R150 Certificate of patent or registration of utility model

Ref document number: 6849651

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150