JP2020129802A - 装置間（ｄ２ｄ）通信における改良されたリソース割当て - Google Patents

Abstract

【課題】直接リンク接続を通じて直接通信送信を実行するための無線リソースを送信側端末に割り当てる方法を提供する。【解決手段】基地局は、システム情報ブロードキャストを送信し、システム情報ブロードキャストは、直接通信送信を実行するための無線リソースを示す、一時的な送信用無線リソースプールに関する情報と、一時的な無線リソースプールが送信側端末によって使用可能である時間長を制限する、リソースプールに関する設定情報と、を含む。【選択図】図１８

Description

本開示は、受信側端末との直接リンク接続を通じて直接通信送信を実行するための無線リソースを送信側端末に割り当てる方法に関する。さらに、本開示は、本明細書に記載されている方法に関与する送信側端末および基地局を提供する。

［ＬＴＥ（Long Term Evolution）］
ＷＣＤＭＡ（登録商標）無線アクセス技術をベースとする第３世代移動通信システム（３Ｇ）は、世界中で広範な規模で配備されつつある。この技術を機能強化または発展・進化させるうえでの最初のステップとして、高速ダウンリンクパケットアクセス（ＨＳＤＰＡ：High-Speed Downlink Packet Access）と、エンハンストアップリンク（高速アップリンクパケットアクセス（ＨＳＵＰＡ：High-Speed Uplink Packet Access）とも称する）とが導入され、これにより、極めて競争力の高い無線アクセス技術が提供されている。

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

ＬＴＥ（Long Term Evolution）に関する作業項目（ＷＩ：working item）の仕様は、Ｅ−ＵＴＲＡ（Evolved UMTS Terrestrial Radio Access）およびＥ−ＵＴＲＡＮ（Evolved UMTS Terrestrial Radio Access Network）と称され、最終的にリリース８（ＬＴＥリリース８）として公開される。ＬＴＥシステムは、パケットベースの効率的な無線アクセスおよび無線アクセスネットワークであり、ＩＰベースの全機能を低遅延かつ低コストで提供する。ＬＴＥでは、与えられたスペクトルを用いてフレキシブルなシステム配備を達成するために、スケーラブルな複数の送信帯域幅（例えば、１.４ＭＨｚ、３.０ＭＨｚ、５.０ＭＨｚ、１０.０ＭＨｚ、１５.０ＭＨｚ、および２０.０ＭＨｚ）が指定されている。ダウンリンクには、ＯＦＤＭ（Orthogonal Frequency Division Multiplexing：直交周波数分割多重）をベースとする無線アクセスが採用されている。なぜなら、かかる無線アクセスは、低いシンボルレートのため本質的にマルチパス干渉（ＭＰＩ：Multipath interference）を受けにくく、また、サイクリックプレフィックス（ＣＰ：Cyclic Prefix）を使用しており、さらに、さまざまな送信帯域幅の構成に対応可能だからである。アップリンクには、ＳＣ−ＦＤＭＡ（Single-Carrier Frequency Division Multiple Access：シングルキャリア周波数分割多元接続）をベースとする無線アクセスが採用されている。なぜなら、ユーザ機器（ＵＥ）の送信出力が限られていることを考えれば、ピークデータレートを向上させるよりも広いカバレッジエリアを提供することが優先されるからである。ＬＴＥリリース８／９では、数多くの主要なパケット無線アクセス技術（例えば、ＭＩＭＯ（Multiple-Input Multiple-Output）チャネル伝送技術）が採用され、高効率の制御シグナリング構造が達成されている。

［ＬＴＥのアーキテクチャ］
図１は、ＬＴＥの全体的なアーキテクチャを示し、図２は、Ｅ−ＵＴＲＡＮのアーキテクチャをより詳細に示している。Ｅ−ＵＴＲＡＮはｅＮｏｄｅＢから構成され、ｅＮｏｄｅＢは、ユーザ機器（ＵＥ：User Equipment）に向かう、Ｅ−ＵＴＲＡのユーザプレーン（ＰＤＣＰ／ＲＬＣ／ＭＡＣ／ＰＨＹ）プロトコルおよび制御プレーン（ＲＲＣ）プロトコルを終端させる。ｅＮｏｄｅＢ（ｅＮＢ）は、物理（ＰＨＹ）レイヤ、媒体アクセス制御（ＭＡＣ：Medium Access Control）レイヤ、無線リンク制御（ＲＬＣ：Radio Link Control）レイヤ、およびパケットデータ制御プロトコル（ＰＤＣＰ：Packet Data Control Protocol）レイヤ（これらのレイヤはユーザプレーンのヘッダ圧縮および暗号化の機能を含む）をホストする。ｅＮＢは、制御プレーンに対応する無線リソース制御（ＲＲＣ：Radio Resource Control）機能も提供する。ｅＮＢは、無線リソース管理、アドミッション制御、スケジューリング、交渉によるアップリンクサービス品質（ＱｏＳ：Quality of Service）の実施、セル情報のブロードキャスト、ユーザプレーンデータおよび制御プレーンデータの暗号化／復号化、ダウンリンク／アップリンクのユーザプレーンパケットヘッダの圧縮／復元など、多くの機能を実行する。複数のｅＮｏｄｅＢは、Ｘ２インタフェースによって互いに接続されている。

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

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

［ＬＴＥにおけるコンポーネントキャリア構造］
３ＧＰＰ ＬＴＥシステムのダウンリンクコンポーネントキャリアは、いわゆるサブフレームにおける時間−周波数領域でさらに分割される。３ＧＰＰ ＬＴＥで、各サブフレームは、図３に示すように２つのダウンリンクスロットに分割され、そこにおいて、第１のダウンリンクスロットは、第１のＯＦＤＭシンボル内の制御チャネル領域（ＰＤＣＣＨ領域）を備える。各サブフレームは、時間領域内の所与の数のＯＦＤＭシンボルで構成され（３ＧＰＰ ＬＴＥ（リリース８）では１２個または１４個のＯＦＤＭシンボル）、各ＯＦＤＭシンボルはコンポーネントキャリアの帯域幅全体に広がる。したがって、ＯＦＤＭシンボルは、各々、図４にも示すように、Ｎ^ＤＬ _ＲＢ×Ｎ^ＲＢ _ｓｃ個のそれぞれのサブキャリアで送信されるいくつかの変調シンボルで構成される。

例えば３ＧＰＰ ＬＴＥにおいて使用されるようなＯＦＤＭを使用する、マルチキャリア通信システムを想定すると、スケジューラによって割り当てることができるリソースの最小単位は、１つの「リソースブロック」である。物理リソースブロック（ＰＲＢ：Physical Resource Block）は、図４に例示されているように、時間領域におけるＮ^ＤＬ _ｓｙｍｂ個の連続するＯＦＤＭシンボル（例：７個のＯＦＤＭシンボル）と、周波数領域におけるＮ^ＲＢ _ｓｃ本の連続するサブキャリア（例：コンポーネントキャリアの１２本のサブキャリア）として定義される。したがって、３ＧＰＰ ＬＴＥ（リリース８）では、物理リソースブロックは、時間領域における１つのスロットおよび周波数領域における１８０ｋＨｚに対応する、Ｎ^ＤＬ _ｓｙｍｂ×Ｎ^ＲＢ _ｓｃ個のリソースエレメントで構成される（ダウンリンクリソースグリッドについてさらに詳しくは、例えば、３ＧＰＰのウェブサイトで入手可能であり、参照により本明細書に組み込まれている、非特許文献１の６.２節を参照）。

１個のサブフレームは２つのスロットからなり、したがって、いわゆる「通常の」サイクリックプレフィックス（normal CP）が使用されているときにはサブフレームに１４個のＯＦＤＭシンボルが存在し、いわゆる「拡張」サイクリックプレフィックス（extended CP）が使用されているときにはサブフレームに１２個のＯＦＤＭシンボルが存在する。専門用語として、以下では、サブフレーム全体にわたる、同一のＮ^ＲＢ _ｓｃ本の連続するサブキャリアに等しい時間−周波数リソースを、「リソースブロックペア」、または同じ意味で「ＲＢペア」または「ＰＲＢ（物理リソースブロック）ペア」と称する。

用語「コンポーネントキャリア（Component Carrier）」は、周波数領域におけるいくつかのリソースブロックの組合せを意味する。ＬＴＥの将来のリリースでは、「コンポーネントキャリア」という用語はもはや使用されず、その代わりに、その専門用語はダウンリンクおよびオプションでアップリンクリソースの組合せを示す「セル」に変更される。ダウンリンクリソースのキャリア周波数とアップリンクリソースのキャリア周波数との間のリンク付けは、ダウンリンクリソースで送信されるシステム情報において指示される。

コンポーネントキャリアの構造の同様の想定は、以降のリリースにも適用される。

［より広い帯域幅をサポートするためのＬＴＥ−Ａにおけるキャリアアグリゲーション］
世界無線通信会議２００７（ＷＲＣ−０７）において、ＩＭＴ−Ａｄｖａｎｃｅｄの周波数スペクトルが決定された。ＩＭＴ−Ａｄｖａｎｃｅｄのための全体的な周波数スペクトルは決定されたが、実際に利用可能な周波数帯域幅は、地域や国によって異なる。しかしながら、利用可能な周波数スペクトルのアウトラインの決定に続いて、３ＧＰＰにおいて無線インタフェースの標準化が開始された。３ＧＰＰでは、３ＧＰＰ ＴＳＧ ＲＡＮ ＃３９会合において、「Further Advancements for E-UTRA (LTE-Advanced)」に関する検討項目（Study Item）の記述が承認された。この検討項目は、Ｅ−ＵＴＲＡを進化・発展させるうえで（例えば、ＩＭＴ−Ａｄｖａｎｃｅｄの要求条件を満たすために）考慮すべき技術要素をカバーしている。

ＬＴＥアドバンストシステムがサポートすることができる帯域幅は１００ＭＨｚであり、一方、ＬＴＥシステムは２０ＭＨｚのみをサポートすることができる。今日、無線スペクトルの欠如がワイヤレスネットワークの開発のボトルネックになり、結果として、ＬＴＥアドバンストシステムのために十分広いスペクトル帯域を見つけることは困難である。したがって、より広い無線スペクトル帯域を獲得するための方法を見つけることは急務であり、ここにおいて、可能性のある答えは、キャリアアグリゲーション機能である。

キャリアアグリゲーションでは、最大で１００ＭＨｚの広い送信帯域幅をサポートする目的で、２つ以上のコンポーネントキャリア（ＣＣ）がアグリゲートされる。ＬＴＥ−Ａｄｖａｎｃｅｄシステムでは、ＬＴＥシステムにおけるいくつかのセルが、より広い１つのチャネルにアグリゲートされ、このチャネルは、たとえＬＴＥにおけるこれらのセルが異なる周波数帯域である場合でも１００ＭＨｚに対して十分に広い。

アグリゲートされるコンポーネントキャリアの数がアップリンクとダウンリンクとで少なくとも同じであるとき、すべてのコンポーネントキャリアをＬＴＥリリース８／９互換として設定することができる。ユーザ機器によってアグリゲートされるすべてのコンポーネントキャリアが必ずしもＬＴＥリリース８／９互換でなくてよい。リリース８／９のユーザ機器がコンポーネントキャリアにキャンプオンすることを回避するため、既存のメカニズム（例：バーリング（barring））を使用することができる。

ユーザ機器は、自身の能力に応じて１つまたは複数のコンポーネントキャリア（複数のサービングセルに対応する）を同時に受信または送信することができる。キャリアアグリゲーションのための受信能力もしくは送信能力またはその両方を備えた、ＬＴＥ−Ａリリース１０のユーザ機器は、複数のサービングセル上で同時に受信する、もしくは送信する、またはその両方を行うことができ、これに対して、ＬＴＥリリース８／９のユーザ機器は、コンポーネントキャリアの構造がリリース８／９の仕様に従う場合、１つのみのサービングセル上で受信および送信を行うことができる。

キャリアアグリゲーションは、連続するコンポーネントキャリアおよび不連続なコンポーネントキャリアの両方においてサポートされ、この場合、コンポーネントキャリアそれぞれは、３ＧＰＰ ＬＴＥ（リリース８／９）の計算方式を使用するとき周波数領域における最大１１０個のリソースブロックに制限される。

同じｅＮｏｄｅＢ（基地局）から送信される、場合によってはアップリンクおよびダウンリンクにおいて異なる帯域幅の異なる数のコンポーネントキャリアをアグリゲートするように、３ＧＰＰ ＬＴＥ−Ａ（リリース１０）互換のユーザ機器を構成することが可能である。設定することのできるダウンリンクコンポーネントキャリアの数は、ユーザ機器のダウンリンクのアグリゲーション能力に依存する。逆に、設定することのできるアップリンクコンポーネントキャリアの数は、ユーザ機器のアップリンクのアグリゲーション能力に依存する。ダウンリンクコンポーネントキャリアよりもアップリンクコンポーネントキャリアが多くなるように移動端末を構成することはできない。

一般的なＴＤＤ配備では、コンポーネントキャリアの数および各コンポーネントキャリアの帯域幅は、アップリンクとダウンリンクとで同じである。同じｅＮｏｄｅＢから送信されるコンポーネントキャリアは、必ずしも同じカバレッジを提供する必要はない。

連続的にアグリゲートされるコンポーネントキャリアの中心周波数の間隔は、３００ｋＨｚの倍数である。これは、３ＧＰＰ ＬＴＥ（リリース８／９）の１００ｋＨｚの周波数ラスターとの互換性を保つと同時に、１５ｋＨｚ間隔のサブキャリアの直交性を維持するためである。アグリゲーションのシナリオによっては、連続するコンポーネントキャリアの間に少数の使用されないサブキャリアを挿入することによって、ｎ×３００ｋＨｚの間隔あけを容易にすることができる。

複数のキャリアをアグリゲートする影響は、ＭＡＣレイヤに及ぶのみである。ＭＡＣレイヤには、アップリンクおよびダウンリンクの両方において、アグリゲートされるコンポーネントキャリアごとに１つのＨＡＲＱエンティティが要求される。コンポーネントキャリアあたりのトランスポートブロックは最大１個である（アップリンクにおけるＳＵ−ＭＩＭＯを使用しない場合）。トランスポートブロックおよびそのＨＡＲＱ再送信（発生時）は、同じコンポーネントキャリアにマッピングする必要がある。

図５および図６は、それぞれ、ダウンリンクおよびアップリンクにおける、キャリアアグリゲーションが設定されたＬ２レイヤ構造を示している。

キャリアアグリゲーションが設定されているとき、移動端末はネットワークとの１つのＲＲＣ接続を有するのみである。ＲＲＣ接続の確立／再確立時には、ＬＴＥリリース８／９と同様に、１つのセルが、セキュリティ入力（１つのＥＣＧＩ、１つのＰＣＩ、および１つのＡＲＦＣＮ）と、非アクセス層（ＮＡＳ）モビリティ情報（例：ＴＡＩ）とを提供する。ＲＲＣ接続の確立／再確立の後、そのセルに対応するコンポーネントキャリアをダウンリンクプライマリセル（ＰＣｅｌｌ）と称する。接続状態では、ユーザ機器あたりつねに１つのダウンリンクＰＣｅｌｌ（ＤＬ ＰＣｅｌｌ）および１つのアップリンクＰＣｅｌｌ（ＵＬ ＰＣｅｌｌ）が設定される。設定されているコンポーネントキャリアのセットの中のプライマリセル以外のセルを、セカンダリセル（ＳＣｅｌｌ）と称し、ＳＣｅｌｌのキャリアは、ダウンリンクセカンダリコンポーネントキャリア（ＤＬ ＳＣＣ）およびアップリンクセカンダリコンポーネントキャリア（ＵＬ ＳＣＣ）である。

コンポーネントキャリアの設定および再設定、ならびに追加および削除は、ＲＲＣによって実行することができる。アクティブ化および非アクティブ化は、ＭＡＣ制御要素を介して行われる。ＬＴＥ内ハンドオーバー時、ＲＲＣによって、ターゲットセルで使用するためのＳＣｅｌｌを追加、削除、または再設定することもできる。新しいＳＣｅｌｌを追加するときには、（ＬＴＥリリース８／９におけるハンドオーバー時と同様に）専用のＲＲＣシグナリングを使用して、ＳＣｅｌｌのシステム情報（この情報は送信／受信に必要である）を送る。

キャリアアグリゲーションを使用するようにユーザ機器が構成されているとき、アップリンクコンポーネントキャリアとダウンリンクコンポーネントキャリアの一対が常にアクティブである。この対のうちのダウンリンクコンポーネントキャリアは、「ダウンリンクアンカーキャリア」と称されることもある。同じことはアップリンクについてもあてはまる。

キャリアアグリゲーションが設定されているとき、同時に複数のコンポーネントキャリアについてユーザ機器をスケジューリングすることができるが、一度に行うことのできるランダムアクセス手順は最大で１つである。クロスキャリアスケジューリング（cross-carrier scheduling）では、コンポーネントキャリアのＰＤＣＣＨによって別のコンポーネントキャリアのリソースをスケジューリングすることができる。この目的のため、それぞれのＤＣＩフォーマットにコンポーネントキャリア識別フィールド（「ＣＩＦ」と称する）が導入されている。

クロスキャリアスケジューリングが行われていないときには、アップリンクコンポーネントキャリアとダウンリンクコンポーネントキャリアとをリンクすることによって、グラントが適用されるアップリンクコンポーネントキャリアを識別することができる。アップリンクコンポーネントキャリアへのダウンリンクコンポーネントキャリアのリンクは、必ずしも１対１である必要はない。言い換えれば、同じアップリンクコンポーネントキャリアに複数のダウンリンクコンポーネントキャリアをリンクすることができる。一方で、１つのダウンリンクコンポーネントキャリアは、１つのアップリンクコンポーネントキャリアのみにリンクすることができる。

［ＬＴＥにおけるＲＲＣ状態］
ＬＴＥは、２つのみの主状態、すなわち「ＲＲＣ＿ＩＤＬＥ」および「ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ」に基づく。

ＲＲＣ＿ＩＤＬＥ状態では、無線は有効ではないが、ネットワークによってＩＤが割り当てられて追跡されている。より具体的には、ＲＲＣ＿ＩＤＬＥモードの移動端末は、セルの選択および再選択を実行する（言い換えれば、キャンプオンするセルを決定する）。セルの（再）選択プロセスでは、適用可能な無線アクセス技術（ＲＡＴ：Radio Access Technology）それぞれの適用可能な各周波数の優先順位、無線リンクの品質、およびセルのステータス（すなわちセルが禁止または予約されているか）が考慮される。ＲＲＣ＿ＩＤＬＥモードの移動端末は、ページングチャネルを監視して着呼を検出し、さらにシステム情報を取得する。システム情報は、主として、セルの（再）選択プロセスと移動端末がネットワークにアクセスする方法とをネットワーク（Ｅ−ＵＴＲＡＮ）が制御するためのパラメータからなる。ＲＲＣは、ＲＲＣ＿ＩＤＬＥ状態にある移動端末に適用される制御シグナリング（すなわちページングおよびシステム情報）を指定する。ＲＲＣ＿ＩＤＬＥ状態にある移動端末の挙動については、非特許文献２の４節「General description of Idle mode」（参照によって本明細書に組み込まれている）にさらに詳細に規定されている。

ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態では、移動端末は、ｅＮｏｄｅＢとのアクティブな無線動作を有する。Ｅ−ＵＴＲＡＮでは、共有データチャネルを介して（ユニキャスト）データを伝送することができるように、移動端末に無線リソースが割り当てられる。この動作をサポートするため、移動端末は、時間および周波数の共有送信リソースの動的な割当てを示すために使用される対応する制御チャネルを監視する。移動端末は、Ｅ−ＵＴＲＡＮが移動端末にとって最適なセルを選択できるように、自身のバッファ状態およびダウンリンクチャネル品質の報告と、隣接セルの測定情報とを、ネットワークに提供する。これらの測定報告には、別の周波数や無線アクセス技術（ＲＡＴ）を使用するセルが含まれる。さらに、ユーザ機器は、送信チャネルを使用するために要求される情報から主として構成されるシステム情報を受信する。ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態のユーザ機器は、自身のバッテリの寿命を延ばすため、不連続受信（ＤＲＸ）サイクルを使用するように構成することができる。ＲＲＣとは、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態のユーザ機器の挙動をＥ−ＵＴＲＡＮが制御するためのプロトコルである。

ＲＲＣプロトコルにおける移動端末のさまざまな機能（接続モードを含む）については、非特許文献３の４節「Functions」（参照によって本明細書に組み込まれている）に記載されている。

［ＬＴＥにおけるアップリンクアクセス方式］
アップリンク送信では、カバレッジを最大にするため、ユーザ端末による電力効率の高い送信が必要である。Ｅ−ＵＴＲＡのアップリンク送信方式としては、シングルキャリア伝送と、動的な帯域幅割当てのＦＤＭＡとを組み合わせた方式が選択されている。シングルキャリア伝送が選択された主たる理由は、マルチキャリア信号（ＯＦＤＭＡ）と比較して、ピーク対平均電力比（ＰＡＰＲ：Peak to Average Power Ratio）が低く、これに対応して電力増幅器の効率が改善され、カバレッジの向上が見込まれるためである（与えられる端末ピーク電力に対してデータレートが高い）。各時間間隔において、ＮｏｄｅＢは、ユーザデータを送信するための固有の時間／周波数リソースをユーザに割り当て、これによってセル内の直交性が確保される。アップリンクにおける直交多元接続によって、セル内干渉が排除されることでスペクトル効率が高まる。マルチパス伝搬に起因する干渉については、送信信号にサイクリックプレフィックスを挿入することにより基地局（ＮｏｄｅＢ）において対処する。

データを送信するために使用される基本的な物理リソースは、１つの時間間隔（例えば０.５ｍｓのサブフレーム）にわたるサイズＢＷ_{ｇｒａｎｔ}の周波数リソースから構成される（符号化された情報ビットはこのリソースにマッピングされる）。なお、サブフレーム（送信時間間隔（ＴＴＩ：Transmission Time Interval）とも称する）は、ユーザデータを送信するための最小の時間間隔である。しかしながら、サブフレームを連結することにより、１ＴＴＩよりも長い時間にわたる周波数リソースＢＷ_{ｇｒａｎｔ}をユーザに割り当てることも可能である。

［ＬＴＥにおけるアップリンクのスケジューリング方式］
アップリンクの方式として、スケジューリング制御式の（すなわちｅＮＢによって制御される）アクセスと、コンテンション（競合）ベースのアクセスの両方を使用することができる。

スケジューリング制御式アクセスの場合、アップリンクデータを送信するための特定の時間長の特定の周波数リソース（すなわち時間／周波数リソース）が、ユーザ機器に割り当てられる。しかしながら、コンテンションベースのアクセス用に、いくらかの時間／周波数リソースを割り当てることができる。コンテンションベースの時間／周波数リソースの範囲内では、ユーザ機器は、最初にスケジューリングされることなく送信することができる。ユーザ機器がコンテンションベースのアクセスを行う１つのシナリオは、例えばランダムアクセスであり、すなわち、ユーザ機器があるセルへの最初のアクセスを行うとき、またはアップリンクリソースを要求するために最初のアクセスを行うときである。

スケジューリング制御式アクセスの場合、ＮｏｄｅＢのスケジューラが、アップリンクデータ送信のための固有の周波数／時間リソースをユーザに割り当てる。より具体的には、スケジューラは以下を決定する。
・ 送信を許可する（１つまたは複数の）ユーザ機器
・ 物理チャネルリソース（周波数）
・ 移動端末が送信に使用するべきトランスポートフォーマット（ＭＣＳ（Modulation and Coding Scheme））

割当て情報は、Ｌ１／Ｌ２制御チャネルで送られるスケジューリンググラントを介してユーザ機器にシグナリングされる。以下では、説明を簡潔にするため、このチャネルをアップリンクグラントチャネルと称する。スケジューリンググラントメッセージには、情報として、周波数帯域のうちユーザ機器による使用を許可する部分と、グラントの有効期間と、これから行うアップリンク送信にユーザ機器が使用しなければならないトランスポートフォーマットとが、少なくとも含まれる。最も短い有効期間は１サブフレームである。グラントメッセージには、選択される方式に応じて追加の情報も含めることができる。アップリンク共有チャネル（ＵＬ−ＳＣＨ）で送信する権利を許可するグラントとしては、「各ユーザ機器に対する」グラントのみが使用される（すなわち、「各ユーザ機器における各無線ベアラに対する」グラントは存在しない）。したがってユーザ機器は、割り当てられたリソースを何らかの規則に従って無線ベアラの間で配分する必要がある。トランスポートフォーマットは、ＨＳＵＰＡの場合とは異なり、ユーザ機器側では選択しない。ｅＮＢが、何らかの情報（例えば、報告されたスケジューリング情報およびＱｏＳ情報）に基づいてトランスポートフォーマットを決定し、ユーザ機器は、選択されたトランスポートフォーマットに従わなければならない。ＨＳＵＰＡでは、ＮｏｄｅＢが最大限のアップリンクリソースを割り当てて、ＵＥは、それに応じてデータ送信用の実際のトランスポートフォーマットを選択する。

無線リソースのスケジューリングは、サービス品質を決めるうえで、共有チャネルアクセスネットワークにおいて最も重要な機能であるため、効率的なサービス品質（ＱｏＳ）管理を可能にする目的で、ＬＴＥにおけるアップリンクスケジューリング方式が満たしているべき要件がいくつかある。
・ 優先順位の低いサービスのリソース不足を避けるべきである。
・ 個々の無線ベアラ／サービスにおいてサービス品質（ＱｏＳ）が明確に区別されるべきである。
・ どの無線ベアラ／サービスのデータが送信されるのかをｅＮＢのスケジューラが識別できるように、アップリンク報告において、きめ細かいバッファ報告（例えば、無線ベアラごとの報告、または無線ベアラグループごとの報告）を可能にするべきである。
・ 異なるユーザのサービスの間でサービス品質（ＱｏＳ）を明確に区別できるようにするべきである。
・ 無線ベアラごとに最小限のビットレートを提供できるようにするべきである。

上に挙げた条件から理解できるように、ＬＴＥのスケジューリング方式の１つの重要な側面は、事業者が、自身の総セル容量を、異なるＱｏＳクラスの個々の無線ベアラの間で分配することを制御できるメカニズムを提供することである。無線ベアラのＱｏＳクラスは、前述したようにサービングゲートウェイからｅＮＢにシグナリングされる対応するＳＡＥベアラのＱｏＳプロファイルによって識別される。事業者は、自身の総セル容量のうちの特定の量を、特定のＱｏＳクラスの無線ベアラに関連付けられる総トラフィックに割り当てることができる。クラスに基づくこの方法を採用する主たる目的は、パケットの処理を、パケットが属するＱｏＳクラスに応じて区別できるようにすることである。

［（ブロードキャスト）システム情報の構造］
３ＧＰＰの専門用語においては、（ブロードキャスト）システム情報は、ＢＣＣＨ情報とも称され、すなわち、ＵＥが接続されている（アクティブ状態）またはアタッチされている（アイドル状態）無線セルのブロードキャスト制御チャネル（論理チャネルである）で伝えられる情報を意味する。

システム情報には、一般的には、マスター情報ブロック（ＭＩＢ：Master Information Block）と、いくつかのシステム情報ブロック（ＳＩＢ：System Information Block）とが含まれる。マスター情報ブロック（ＭＩＢ）には、各システム情報ブロックに関する制御情報が含まれる。各システム情報ブロック（ＳＩＢ）に関連付けられる制御情報は、次の構造を有することができる。すなわち、ＳＩＢに関連付けられるそれぞれの制御情報は、ＳＩＢが送信されるトランスポートチャネル上での、共通のタイミング基準に対するＳＩＢの位置を示すことができる（例えば、ＯＦＤＭ無線アクセスの場合の時間−周波数平面における位置、すなわち各ＳＩＢの送信用に割り当てられている特定のリソースブロック）。さらには、ＳＩＢの繰り返し周期を示すことができる。この繰り返し周期は、各ＳＩＢが送信される周期を示す。さらに、制御情報は、ＳＩＢ情報のタイマベースの更新メカニズムのタイマ値、あるいは、ＳＩＢ情報のタグベースの更新の場合の値タグを含むこともできる。

次の表は、非特許文献４の８．１．１節（参照によって本明細書に組み込まれている）に定義されている、ＵＭＴＳレガシーシステムにおけるシステム情報ブロック（ＳＩＢ）の分類およびタイプの概要を示している。システム情報はＬＴＥシステムにおいても定義され、詳細については、非特許文献５の６．３．１節（参照によって本明細書に組み込まれている）に記載されている。

後の節でさらに詳しく説明するように、装置間（Ｄ２Ｄ：Device to Device）通信技術は、ＬＴＥリリース１２において実施される予定である。現在３ＧＰＰによる標準化作業では、特に、ＰｒｏＳｅ直接通信および直接発見に関連するいくつかの情報が含まれるようにシステム情報ブロックタイプ１８（ＳＩＢタイプ１８：SystemInformationBlock Type 18）の定義が進められている。ＳＩＢ１８の以下の定義は、非特許文献３を対象としてＰｒｏＳｅに関してこれまでに合意された現在検討されている変更要求ｒ２−１４３５６５からの抜粋である。ただしこれは最終的に決定されたものではなく、単なる例として理解されたい。

上のシステム情報から明らかであるように、commIdleTxPoolフィールド（commSA-TxResourcePoolCommonサブフィールドを含む）は共通リソースを示し、ＳＩＢ１８を受信しかつ依然としてアイドル状態にあるＵＥは、この共通リソースから（競合（コンテンション）ベース方式で）リソースを使用することができる。言い換えれば、ネットワーク事業者は、すべてのＵＥのための無線リソースを共通に定義することができ、ただしこれらの無線リソースは、ＵＥが依然としてアイドル状態にあるときにのみ使用可能である。後から説明するように、commIdleTxPoolによって定義されるこれらの無線リソースは、モード２のリソース（ＵＥによって自律的に使用される）として分類される。

［バッファ状態報告］
バッファ状態報告手順は、ＵＥのアップリンクバッファの中の送信できる状態にあるデータの量に関する情報を、サービングｅＮＢに提供するために使用される。ＲＲＣレイヤは、２つのタイマｐｅｒｉｏｄｉｃＢＳＲ−ＴｉｍｅｒおよびｒｅｔｘＢＳＲ−Ｔｉｍｅｒを設定し、さらにオプションとして、論理チャネルを論理チャネルグループ（ＬＣＧ）に割り当てるｌｏｇｉｃａｌＣｈａｎｎｅｌＧｒｏｕｐを各論理チャネルについてシグナリングすることによって、バッファ状態報告（ＢＳＲ）を制御する。バッファ状態報告に関するさらなる詳細は、非特許文献６の５．４．５節（参照によって本明細書に組み込まれている）に記載されている。

［ＬＴＥの装置間（Ｄ２Ｄ）近傍サービス（ＰｒｏＳｅ）］
近傍性に基づくアプリケーションおよびサービスは、ソーシャル技術の新しいトレンドである。識別される分野としては、事業者およびユーザにとって関心のある商用サービスおよび公共安全に関連するサービスが挙げられる。ＬＴＥに近傍サービス（ＰｒｏＳｅ）機能を導入することにより、３ＧＰＰ業界は、この成長の見込まれる市場にサービスを提供することができると同時に、連係してＬＴＥを使用するいくつかの公共安全コミュニティの緊急なニーズに応えることができる。

装置間（Ｄ２Ｄ）通信は、ＬＴＥリリース１２における技術要素である。装置間（Ｄ２Ｄ）通信技術によって、セルラーネットワークに対するアンダーレイ（下層）としてのＤ２Ｄにおいてスペクトル効率を高めることができる。例えば、セルラーネットワークがＬＴＥである場合、データを伝えるすべての物理チャネルは、Ｄ２ＤシグナリングにおいてＳＣ−ＦＤＭＡを使用する。

［ＬＴＥにおけるＤ２Ｄ通信］
ＬＴＥにおけるＤ２Ｄ通信は、発見および通信という２つの分野に焦点をあてている。

Ｄ２Ｄ通信では、ＵＥは、基地局（ＢＳ）を経由せずに、セルラーリソースを使用して直接的なリンクを通じて互いにデータ信号を送信する。Ｄ２Ｄのユーザは、直接通信するが、基地局の制御下のままである（少なくともｅＮＢのカバレッジ内であるとき）。したがってＤ２Ｄでは、セルラーリソースを再利用することによってシステムの性能を改善することができる。

Ｄ２Ｄは、アップリンクＬＴＥスペクトル（ＦＤＤの場合）において動作する、またはカバレッジを提供しているセルのアップリンクサブフレーム（ＴＤＤの場合、ただしカバレッジ外のときを除く）において動作するものと想定する。さらに、Ｄ２Ｄ送信／受信では、与えられたキャリアにおける全二重を使用しない。個々のユーザ機器の観点からは、与えられたキャリアにおいて、Ｄ２Ｄ信号受信とＬＴＥアップリンク送信とによる全二重を使用しない（すなわちＤ２Ｄ信号受信およびＬＴＥアップリンク送信を同時に行うことはできない）。

Ｄ２Ｄ通信では、特定の１基のＵＥ１が送信の役割であるとき（送信側ユーザ機器または送信側端末）、ＵＥ１がデータを送信し、別のＵＥ２（受信側ユーザ機器）がそれを受信する。ＵＥ１およびＵＥ２は、送信の役割と受信の役割を交換することができる。ＵＥ１からの送信は、ＵＥ２に類似する１基または複数基のＵＥによって受信することができる。

ユーザプレーンのプロトコルに関して、Ｄ２Ｄ通信に関連する合意内容を以下に示す（非特許文献７の９．２．２節（参照によって本明細書に組み込まれている）も参照）。
− ＰＤＣＰ：
・ １：Ｍ Ｄ２Ｄブロードキャスト通信データ（すなわちＩＰパケット）は、通常のユーザプレーンデータとして扱うべきである。
・ １：Ｍ Ｄ２Ｄブロードキャスト通信データには、ＰＤＣＰにおけるヘッダ圧縮／圧縮解除を適用することができる。
・ 公共安全に関連するＤ２Ｄブロードキャスト動作では、ＰＤＣＰにおけるヘッダ圧縮にＵモードを使用する。
− ＲＬＣ：
・ １：Ｍ Ｄ２Ｄブロードキャスト通信にはＲＬＣ ＵＭを使用する。
・ セグメント化および再構築はＲＬＣ ＵＭによってＬ２においてサポートされる。
・ 受信側ユーザ機器は、送信側のピアユーザ機器あたり少なくとも１つのＲＬＣ ＵＭエンティティを維持する必要がある。
・ 最初のＲＬＣ ＵＭデータユニットを受信する前に受信機のＲＬＣ ＵＭエンティティを設定する必要はない。
・ 現時点では、ユーザプレーンデータを送信するＤ２Ｄ通信においてＲＬＣ ＡＭまたはＲＬＣ ＴＭの必要性は認識されていない。
− ＭＡＣ：
・ １：Ｍ Ｄ２Ｄブロードキャスト通信ではＨＡＲＱフィードバックを想定しない。
・ 受信側ユーザ機器は、受信機のＲＬＣ ＵＭエンティティを識別する目的で送信元ＩＤを認識する必要がある。
・ ＭＡＣヘッダには、ＭＡＣレイヤにおけるパケットフィルタリングを可能にするＬ２送信先ＩＤが含まれる。
・ Ｌ２送信先ＩＤは、ブロードキャストアドレス、グループキャストアドレス、またはユニキャストアドレスとすることができる。
・ Ｌ２グループキャスト／ユニキャスト： ＭＡＣヘッダにおいて伝えられるＬ２送信先ＩＤによって、受信されたＲＬＣ ＵＭ ＰＤＵを、たとえそれを受信機のＲＬＣエンティティに渡す前であっても破棄することが可能となる。
・ Ｌ２ブロードキャスト： 受信側ユーザ機器は、すべての送信機からの受信されたすべてのＲＬＣ ＰＤＵを処理し、再構築してＩＰパケットを上位レイヤに渡す。
・ ＭＡＣサブヘッダには、（複数の論理チャネルを区別するための）論理チャネルＩＤ（ＬＣＩＤ）が含まれる。
・ Ｄ２Ｄでは、少なくとも多重化／逆多重化、優先順位の処理、およびパディングが有用である。

［無線リソースの割当て］
送信側ＵＥの観点からは、近傍サービスに対応するＵＥ（ＰｒｏＳｅ対応ＵＥ）は、リソース割当ての次の２つのモードで動作することができる。

モード１は、ｅＮＢがリソース割当てをスケジューリングする方式を意味し、この場合、ＵＥは、ｅＮＢ（またはリリース１０の中継ノード）からの送信リソースを要求し、それを受けてｅＮＢ（またはリリース１０の中継ノード）は、ユーザ機器が「直接」データおよび「直接」制御情報（例：スケジューリング割当て（ＳＡ：Scheduling Assignment））を送信するために使用する正確なリソースをスケジューリングする。ＵＥは、データを送信するためにはＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態にある必要がある。具体的には、ＵＥは、スケジューリング要求（専用スケジューリング要求（Ｄ−ＳＲ）またはランダムアクセス）をｅＮＢに送り、次いでバッファ状態報告（ＢＳＲ：Buffer State Report）を通常の方法で送る（次節「Ｄ２Ｄ通信における送信手順」も参照）。ｅＮＢは、バッファ状態報告（ＢＳＲ）に基づいて、ユーザ機器がＰｒｏＳｅ直接通信によって送信するデータを有するものと判断し、送信に必要なリソースを推定することができる。

これに対して、モード２は、ＵＥが自律的にリソースを選択する方式を意味し、この場合、ＵＥは、「直接」データおよび「直接」制御情報を送信するためのリソース（時間および周波数）を、自身でリソースプールから選択する。１つのリソースプールが、例えば（前の節で説明した）ＳＩＢ１８の内容によって（すなわちcommIdleTxPoolフィールドによって）定義され、この特定のリソースプールがセル内でブロードキャストされ、そのセル内の依然としてＲＲＣ＿ＩＤＬＥ状態にあるすべてのＵＥに共通して利用可能である。これに代えて、またはこれに加えて、ｅＮＢが別のリソースプールを定義して特定のＵＥを対象として（すなわちcommTxResourcePoolフィールドを使用することによって）シグナリングすることができる。まだ最終的に決定されていないが、非特許文献３を対象として変更要求ｒ２−１４３５６５に従って、対応するＰｒｏＳｅ情報エレメントについて現在標準化が進められている。したがって、以下の定義は単なる例として理解されたい。

このＰｒｏＳｅＣｏｍｍＣｏｎｆｉｇ情報エレメントは、Ｄ２Ｄ通信を実行しようとするＵＥによる対応する要求に応えてｅＮＢによって送信されるネットワーク応答の一部とすることができる。例えば図１６に示したように、ＵＥは、Ｄ２Ｄ通信を実行することを望む場合、Ｄ２Ｄ通信関心通知（D2D Communication Interest Indication）をｅＮＢに送信することができる。この場合、（例えばＲＲＣＣｏｍｍｕｎｉｃａｔｉｏｎＲｅｃｏｎｆｉｇｕｒａｔｉｏｎの一部としての）Ｄ２Ｄ通信応答に、上述したＰｒｏｓｅＣｏｍｍＣｏｎｆｉｇ情報エレメントを含めることができる。

さらには、ｅＮＢのセルのカバレッジ外であるＵＥが、スケジューリング割当て（ＳＡ）またはデータのＤ２Ｄ通信用に利用することのできる事前に設定される無線リソースも、モード２のリソースとして分類することができる。

ＵＥがどちらのリソース割当てモードを使用するかは、上述したようにｅＮＢによって設定可能である。さらに、ＵＥがＤ２Ｄデータ通信用にどちらのリソース割当てモードを使用するかは、ＲＲＣ状態（すなわちＲＲＣ＿ＩＤＬＥまたはＲＲＣ＿ＣＯＮＮＥＣＴＥＤ）と、ＵＥのカバレッジ状態（すなわちカバレッジ内またはカバレッジ外）によっても決まるようにすることができる。ＵＥがサービングセルを有する（すなわちＵＥがＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態にある、またはＲＲＣ＿ＩＤＬＥ状態において特定のセルにキャンプオンしている）場合、そのＵＥはカバレッジ内であるとみなされる。

３ＧＰＰにおける現在までの合意によると（Ｒ２−１４３６７２における非特許文献８への変更要求（リソース割当てに関する節）を参照）、リソース割当てモードに関する次の規則がＵＥに適用される。
・ ＵＥがカバレッジ外である場合、そのＵＥはモード２のみを使用することができる。
・ ＵＥがカバレッジ内である場合、ＵＥがモード１を使用できるようにｅＮＢによって設定されているならば、そのＵＥはモード１を使用することができる。
・ ＵＥがカバレッジ内である場合、ＵＥがモード２を使用できるようにｅＮＢによって設定されているならば、そのＵＥはモード２を使用することができる。
・ 例外条件が存在しないときには、モードを変更するようにｅＮＢによってＵＥが設定される場合にのみ、ＵＥはモード１からモード２に、またはモード２からモード１に変更することができる。ＵＥがカバレッジ内である場合、例外的なケースの１つが発生しない限り、ＵＥはｅＮＢの設定によって示されるモードのみを使用する。
・ 例えばＴ３１１またはＴ３０１が実行中である間、ＵＥは、自身を例外条件下にあるものとみなす。
・ 例外的なケースが発生したとき、ＵＥは、たとえモード１を使用するように設定されていても一時的にモード２を使用することが許可される。

ユーザ機器は、Ｅ−ＵＴＲＡセルのカバレッジ領域内にある間は、そのセルによって割り当てられるリソースにおいてのみアップリンクキャリアでのＰｒｏＳｅ直接通信送信を実行する（たとえそのキャリアのリソースが例えばＵＩＣＣ（汎用ＩＣカード：Universal Integrated Circuit Card）において事前に設定されている場合でも）。

ＲＲＣ＿ＩＤＬＥ状態にあるＵＥに対しては、ｅＮＢは次のオプションの一方を選択することができる。
・ ｅＮＢは、モード２の送信リソースプールをＳＩＢ（システム情報ブロック）の中で提供する。ＰｒｏＳｅ直接通信が許可されているＵＥは、ＲＲＣ＿ＩＤＬＥ状態においてＰｒｏＳｅ直接通信用にこれらのリソースを使用する。
・ ｅＮＢは、自身がＤ２ＤをサポートしているがＰｒｏＳｅ直接通信用のリソースを提供しないことをＳＩＢの中で示す。ＵＥは、ＰｒｏＳｅ直接通信送信を実行するためにはＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態に入る必要がある。
ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態にあるＵＥに関しては、次のようにすることができる。
・ ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態にありＰｒｏＳｅ直接通信送信を実行することが許可されているＵＥは、ＰｒｏＳｅ直接通信送信を実行する必要があるとき、ＰｒｏＳｅ直接通信送信の実行を希望することをｅＮＢに示す。
・ ｅＮＢは、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態にあるＵＥがＰｒｏＳｅ直接通信送信を許可されているかを、ＭＭＥから受信されるＵＥコンテキストを使用して確認する。
・ ｅＮＢは、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態にあるＵＥに対して、そのＵＥがＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態である間は制約なしで使用することのできるモード２リソース割当て方式の送信リソースプールを、専用シグナリングによって設定することができる。これに代えて、ｅＮＢは、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態にあるＵＥに対して、例外的なケースにおいてのみそのＵＥが使用することのできるモード２のリソース割当て方式の送信リソースプールを、専用シグナリングによって設定することができ、例外的なケースでない場合、ＵＥはモード１に従う。

リソース割当てに関するＵＥの上記の挙動は、図７および図８に状態図として単純化して示してある。図７は、ＵＥがＲＲＣ＿ＩＤＬＥ状態にある場合を示しており、カバレッジ内とカバレッジ外とを区別している。カバレッジ外でありＲＲＣ＿ＩＤＬＥ状態にあるＵＥは、モード２のリソース割当てを使用することができることに留意されたい。現在のところ、ＲＲＣ＿ＩＤＬＥ状態にあるＵＥに対しては例外的なケースは定義されていない。これに対して図８は、ＵＥがＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態にある場合を示しており、カバレッジ内と例外的なケースとを区別している。図から明らかであるように、接続状態かつ例外的なケースにあるＵＥは、モード２のリソース割当てを使用することができる。

図９は、オーバーレイ（ＬＴＥ）およびアンダーレイ（Ｄ２Ｄ）システムにおける送信／受信リソースの使用を示している。

ＵＥがモード１の送信を適用するかモード２の送信を適用するかは、基本的にはｅＮｏｄｅＢが制御する。ＵＥは、Ｄ２Ｄ通信を送信（または受信）することのできるリソースを認識すると、現在の最新の技術においては、対応するリソースを、対応する送信／受信にのみ使用する。例えば図９において、Ｄ２Ｄサブフレームは、Ｄ２Ｄ信号を受信または送信する目的にのみ使用される。Ｄ２Ｄ装置としてのＵＥは、半二重モードで動作するため、任意の時点においてＤ２Ｄ信号の受信または送信のいずれかを行うことができる。同様に、図９に示したそれ以外のサブフレームは、ＬＴＥ（オーバーレイ）の送信および／または受信に使用することができる。

［Ｄ２Ｄ通信における送信手順］
Ｄ２Ｄデータの送信手順は、リソース割当てモードに応じて異なる。上述したように、モード１の場合には、スケジューリング割当て（ＳＡ）およびＤ２Ｄデータを伝えるためのリソースを、ＵＥからの対応する要求の後にｅＮＢが明示的にスケジューリングする。具体的には、Ｄ２Ｄ通信は基本的に許可されるがモード２のリソース（すなわちリソースプール）が提供されないことを、ｅＮＢがＵＥに通知することができる。この通知は、例えば、図１６に示したようにＵＥによるＤ２Ｄ通信関心通知と、対応する応答であるＤ２Ｄ通信応答を交換することによって、行うことができ、この場合、前述した対応する例示的なＰｒｏｓｅＣｏｍｍＣｏｎｆｉｇの情報エレメントにcommTxREsourcePoolが含まれず、すなわち、送信を含む直接通信の開始を望むＵＥは、個々の送信ごとにリソース割当てをＥ−ＵＴＲＡＮに要求しなければならない。したがってこのような場合、ＵＥは、個々の送信それぞれのリソースを要求しなければならず、以下に、このモード１のリソース割当ての場合の要求／割当て手順の一連のステップを例示的に示す。
− ステップ１ ＵＥがＳＲ（スケジューリング要求）をＰＵＣＣＨを介してｅＮＢに送る。
− ステップ２ ｅＮＢが、（ＵＥがバッファ状態報告（ＢＳＲ）を送るための）アップリンクリソースを、Ｃ−ＲＮＴＩによってスクランブルされたＰＤＣＣＨを介して許可する。
− ステップ３ ＵＥが、バッファの状態を示すＤ２Ｄ ＢＳＲをＰＵＳＣＨを介して送る。
− ステップ４ ｅＮＢが、（ＵＥがデータを送るための）Ｄ２Ｄリソースを、Ｄ２Ｄ−ＲＮＴＩによってスクランブルされたＰＤＣＣＨを介して割り当てる。
− ステップ５ Ｄ２Ｄ送信側ＵＥが、ステップ４で受信したグラントに従って、スケジューリング割当て（ＳＡ）／Ｄ２Ｄデータを送信する。

スケジューリング割当て（ＳＡ）は、制御情報（例えば対応するＤ２Ｄデータを送信するための時間−周波数リソースを指すポインタ）を含むコンパクトな（低ペイロードの）メッセージである。スケジューリング割当て（ＳＡ）の内容は、基本的には上のステップ４において受信されるグラントに従う。Ｄ２Ｄグラントおよびスケジューリング割当て（ＳＡ）の内容の詳細は、現時点では決定されていないが、スケジューリング割当て（ＳＡ）の内容に関する具体的な想定として、以下の合意がなされている。
・ 周波数リソースは、リリース８のアップリンクタイプ０のリソース割当てによって示される（システム帯域幅に応じて５〜１３ビット）
・ １ビットの周波数ホッピングインジケータ（リリース８による）
・ モード２において設定されるリソースプールの範囲外の物理リソースブロック（ＰＲＢ）がホッピングによって使用されないように、インデクシングの何らかの再解釈が定義される予定である。
・ シングルクラスタのリソース割当てのみが有効である
・ すなわち周波数領域においてリソースプールにギャップが存在する場合、リソース割当てはギャップをまたがない。
・ スケジューリング割当て（ＳＡ）においてはＲＶインデックスは使用されない。データのＲＶパターンは、｛０，２，３，１｝である。

これに対して、モード２のリソース割当ての場合、上のステップ１〜ステップ４は基本的に不要であり、ＵＥは、スケジューリング割当て（ＳＡ）およびＤ２Ｄデータを送信するためのリソースを、ｅＮＢによって設定および提供される（１つまたは複数の）送信リソースプールから自律的に選択する。

図１０は、２基のＵＥ（ＵＥ−ＡおよびＵＥ−Ｂ）の場合のスケジューリング割当て（ＳＡ）およびＤ２Ｄデータの送信を例示的に示している。スケジューリング割当て（ＳＡ）を送るためのリソースは周期的であり、Ｄ２Ｄデータの送信に使用されるリソースは、対応するスケジューリング割当て（ＳＡ）によって示される。

［スケジューリング割当て（ＳＡ）およびＤ２Ｄデータのためのリソースプール］
ＵＥがカバレッジ外であるときのスケジューリング割当て（ＳＡ）およびＤ２Ｄデータのためのリソースプールは、以下のように設定することができる。
− スケジューリング割当て（ＳＡ）の受信に使用されるリソースプールは、事前に設定される。
− スケジューリング割当て（ＳＡ）の送信に使用されるリソースプールは、事前に設定される。
− Ｄ２Ｄデータの受信に使用されるリソースプールは、事前に設定される。
− Ｄ２Ｄデータの送信に使用されるリソースプールは、事前に設定される。

ＵＥがカバレッジ内であるときのスケジューリング割当て（ＳＡ）のためのリソースプールは、以下のように設定することができる。
− スケジューリング割当て（ＳＡ）の受信に使用されるリソースプールは、ｅＮＢによって、ＲＲＣを介して専用シグナリングまたはブロードキャストシグナリングにおいて設定される。
− スケジューリング割当て（ＳＡ）の送信に使用されるリソースプールは、モード２のリソース割当てが使用される場合、ｅＮＢによってＲＲＣを介して設定される。
− スケジューリング割当て（ＳＡ）の送信に使用されるリソースプールは、モード１のリソース割当てが使用される場合、ＵＥに知らされない。
− モード１のリソース割当てが使用される場合、スケジューリング割当て（ＳＡ）の送信に使用するための特定のリソースをｅＮＢがスケジューリングする。ｅＮＢによって割り当てられる特定のリソースは、ＵＥに提供されるスケジューリング割当て（ＳＡ）受信用のリソースプールの範囲内である。

［Ｄ２ＤにおけるＵＥのカバレッジ状態］
すでに前述したように（例えば図７および図８を参照）、Ｄ２Ｄ通信におけるリソース割当て方法は、ＲＲＣ状態（すなわちＲＲＣ＿ＩＤＬＥおよびＲＲＣ＿ＣＯＮＮＥＣＴＥＤ）以外に、ＵＥのカバレッジ状態（すなわちカバレッジ内およびカバレッジ外）にも依存する。ＵＥがサービングセルを有する（すなわちＵＥがＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態にある、またはＲＲＣ＿ＩＤＬＥ状態において特定のセルにキャンプオンしている）場合、そのＵＥはカバレッジ内であるとみなされる。

ここまでに説明した２つのカバレッジ状態（すなわちカバレッジ内（ＩＣ）およびカバレッジ外（ＯＯＣ：Out of Coverage））は、Ｄ２Ｄの場合のサブ状態にさらに区別される。図１１は、Ｄ２Ｄ ＵＥに関連付けることのできる４つの異なる状態を示しており、これらの状態は以下のように要約することができる。
− 状態１： ＵＥ１は、アップリンクカバレッジおよびダウンリンクカバレッジを有する。この状態においては、各Ｄ２Ｄ通信セッションをネットワークが制御する。さらにネットワークは、ＵＥ１がリソース割当てモード１を使用するべきかリソース割当てモード２を使用するべきかを設定する。
− 状態２： ＵＥ２は、ダウンリンクカバレッジを有するがアップリンクカバレッジを有さない（すなわちダウンリンクカバレッジのみを有する）。ネットワークが（競合ベースの）リソースプールをブロードキャストする。この状態においては、送信側ＵＥは、スケジューリング割当て（ＳＡ）およびデータに使用するリソースを、ネットワークによって設定されるリソースプールから選択する。この状態においては、Ｄ２Ｄ通信用にモード２によるリソース割当てのみが可能である。
− 状態３： ＵＥ３は、アップリンクカバレッジおよびダウンリンクカバレッジを有さないため、厳密に言えばすでにカバレッジ外（ＯＯＣ）とみなされる。しかしながらＵＥ３は、それ自体がセルのカバレッジ内にある何基かのＵＥ（例：ＵＥ１）のカバレッジ内であり、すなわちこれらのＵＥをＣＰ中継ＵＥと称することもでき、図１１における状態３のＵＥの領域は、ＣＰ ＵＥ中継カバレッジ領域と称することができる。この状態３におけるＵＥは、カバレッジ外（ＯＯＣ）状態３ ＵＥとも称される。この状態においては、ＵＥは、セルに固有ないくつかの情報を受信し、この情報は、ｅＮＢによって送られて（ＳＩＢ）、セルのカバレッジ内のＣＰ ＵＥ中継ＵＥによってＰＤ２ＤＳＣＨを介して状態３カバレッジ外（ＯＯＣ）ＵＥに転送される。ネットワークによって制御される（競合ベースの）リソースプールがＰＤ２ＤＳＣＨによってシグナリングされる。
− 状態４： ＵＥ４はカバレッジ外であり、セルのカバレッジ内にある別のＵＥからＰＤ２ＤＳＣＨを受信しない。この状態（状態４カバレッジ外（ＯＯＣ）とも称する）においては、送信側ＵＥは、データ送信に使用するリソースを、事前に設定されるリソースのプールから選択する。

状態３カバレッジ外（ＯＯＣ）と状態４カバレッジ外（ＯＯＣ）とを区別する理由は、主として、カバレッジ外の装置からのＤ２Ｄ送信と、レガシーＥ−ＵＴＲＡ送信との間に発生しうる強い干渉を回避するためである。一般的にＤ２Ｄ対応ＵＥは、カバレッジ外であるときに使用するための、Ｄ２Ｄ ＳＡおよびデータの送信用の事前に設定されるリソースプールを有する。これらのカバレッジ外のＵＥが、これらの事前に設定されるリソースプールを使用してセルの境界付近で送信すると、そのＤ２Ｄ送信と、カバレッジ内のレガシー送信との間の干渉が、セル内の通信に悪影響を及ぼすことがある。カバレッジ内のＤ２Ｄ対応ＵＥが、セル境界付近のこれらのカバレッジ外の装置にＤ２Ｄリソースプールの設定を転送するならば、カバレッジ外のＵＥは、自身の送信を、ｅＮｏｄｅＢによって指定されるこれらのリソースに制限することができ、したがってカバレッジ内のレガシー送信との干渉を最小にすることができる。したがってＲＡＮ１は、カバレッジ内のＵＥが、リソースプール情報およびＤ２Ｄに関連する他の設定を、カバレッジ領域のすぐ外側の装置（状態３のＵＥ）に転送するメカニズムを導入した。

カバレッジ内Ｄ２Ｄリソースプールに関するこの情報をネットワーク内で近傍に位置するＵＥに伝える目的には、物理Ｄ２Ｄ同期チャネル（ＰＤ２ＤＳＣＨ）が使用され、したがってネットワークの近傍の範囲内のリソースプールが調整される。ＰＤ２ＤＳＣＨの詳細な内容については、まだ最終合意されていない。

［Ｄ２Ｄ発見］
ＰｒｏＳｅ（近傍サービス）直接発見（ProSe Direct Discovery）は、ＰｒｏＳｅ対応ユーザ機器が、近傍の別の（１基または複数基の）ＰｒｏＳｅ対応ユーザ機器を、ＰＣ５インタフェースを介してＥ−ＵＴＲＡ直接無線信号を使用して発見するために使用される手順と定義されている。図１２は、装置間の直接発見のためのＰＣ５インタフェースを概略的に示している。

上位レイヤは、発見情報のアナウンスおよび監視の許可を処理する。この目的のため、ユーザ機器は、事前に定義された信号（発見信号（discovery signal）と称する）を交換しなければならない。ユーザ機器は、必要なときに通信リンクを確立する目的で、発見信号を周期的にチェックすることによって、近傍のユーザ機器のリストを維持する。発見信号は、たとえ信号対雑音比（ＳＮＲ：Signal to Noise Ratio）が低い環境においても高い信頼性で検出される必要がある。発見信号を周期的に送信することができるように、発見信号用のリソースを割り当てる必要がある。

ＰｒｏＳｅ直接発見には２つのタイプがあり、すなわちオープン型（open）と制限型（restricted）である。オープン型は、発見されるユーザ機器からの明示的な許可が必要ない場合であり、制限型の発見は、発見されるユーザ機器からの明示的な許可があるときにのみ行われる。

ＰｒｏＳｅ直接発見は、発見する側のユーザ機器におけるスタンドアロンのサービスイネーブラ（service enabler）とすることができ、このサービスイネーブラは、特定のアプリケーションにおいて、発見する側のユーザ機器が発見される側のユーザ機器からの情報を使用することを可能にする。ＰｒｏＳｅ直接発見において送信される情報は、一例として、「近くでタクシーを見つけて」、「コーヒーショップを見つけて」、「最寄りの警察署を見つけて」などとすることができる。発見する側のユーザ機器は、ＰｒｏＳｅ直接発見を通じて、必要な情報を取得することができる。さらに、得られる情報に応じて、ＰｒｏＳｅ直接発見を使用して遠隔通信システムにおける以降の動作（例えばＰｒｏＳｅ直接通信を開始するなど）を行うことができる。

［ＰｒｏＳｅ直接発見のモデル］
ＰｒｏＳｅ直接発見は、いくつかの発見モデルに基づく。以下に概要を示す。ＰｒｏＳｅ直接発見のモデルは、非特許文献９の５．３節（参照によって本明細書に組み込まれている）にさらに詳細に定義されている。

モデルＡ（「私はここです」）
モデルＡは、「私はここです」とも表される。なぜなら、アナウンスする側のユーザ機器が自身に関する情報（自身のＰｒｏＳｅアプリケーションの識別情報やＰｒｏＳｅ ＵＥの識別情報など）を発見メッセージの中でブロードキャストし、これにより自身の身元を明らかにし、自身が利用可能であることを通信システムの他の装置に伝えるためである。

モデルＡによると、ＰｒｏＳｅ直接発見に関与しているＰｒｏＳｅ対応ユーザ機器の２つの役割が定義されている。ＰｒｏＳｅ対応ユーザ機器は、アナウンスする側のユーザ機器と監視する側のユーザ機器の機能を有することができる。アナウンスする側のユーザ機器は、発見の許可を有する近傍のユーザ機器が使用することのできる特定の情報をアナウンスする。監視する側のユーザ機器は、アナウンスする側のユーザ機器の近傍において、関心のある特定の情報を監視する。

このモデルＡでは、アナウンスする側のユーザ機器が、事前に定義される発見間隔で発見メッセージをブロードキャストし、これらのメッセージに関心のある監視する側のユーザ機器が、メッセージを読み取って処理する。

モデルＢ（「そこにいるのは誰ですか？」／「あなたはそこにいますか？」）
このモデルは、ＰｒｏＳｅ直接発見に関与するＰｒｏＳｅ対応ＵＥの次の２つの役割を定義する。
− 発見する側のＵＥ： このＵＥは、自身が発見したい対象に関する特定の情報を含む要求を送信する。
− 発見される側のＵＥ： 要求メッセージを受信したＵＥは、発見する側のＵＥの要求に関連する何らかの情報で応答することができる。

モデルＢは、「そこにいるのは誰ですか？／あなたはそこにいますか？」と同等である。なぜなら、発見する側のユーザ機器が、応答を受け取りたい対象の別のユーザ機器に関する情報を送信するためである。送信される情報は、例えば、グループに対応するＰｒｏＳｅアプリケーションＩＤに関する情報とすることができる。グループのメンバーは、この送信された情報に応答することができる。

このモデルＢによると、ＰｒｏＳｅ直接発見に関与しているＰｒｏＳｅ対応ユーザ機器の２つの役割が定義されており、すなわち発見する側のユーザ機器と発見される側のユーザ機器である。発見する側のユーザ機器は、自身が発見したい対象に関する特定の情報を含む要求を送信する。一方で、この要求メッセージを受信した発見される側のユーザ機器は、発見する側のユーザ機器の要求に関連する何らかの情報によって応答することができる。

発見情報の内容は、アクセス層（ＡＳ）に透過的であり、アクセス層（ＡＳ）は発見情報の内容を認識していない。したがってアクセス層では、ＰｒｏＳｅ直接発見のさまざまなモデルが区別されず、またＰｒｏＳｅ直接発見のタイプも区別されない。ＰｒｏＳｅプロトコルは、アナウンスする有効な発見情報のみをアクセス層（ＡＳ）に渡す。

ユーザ機器は、ｅＮＢの設定によるＲＲＣ＿ＩＤＬＥ状態およびＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態の両方において、発見情報のアナウンスおよび監視に関与することができる。ユーザ機器は、半二重の制約を受ける発見情報をアナウンスおよび監視する。

［発見のタイプ］
図１３は、Ｄ２Ｄ通信において発見用リソースを受信するときのＩＤＬＥモードおよびＣＯＮＮＥＣＴＥＤモードを、リソース割当て手順に関して示した図である。

Ｄ２Ｄ通信は、ネットワークによって制御する（この場合には直接送信（Ｄ２Ｄ）と従来のセルラーリンクとの間の切り替えを通信事業者が管理する）、または、通信事業者の制御なしで直接リンクを装置によって管理することができる。Ｄ２Ｄでは、インフラストラクチャモードとアドホック通信を組み合わせることができる。

一般的には、装置の発見は周期的に必要である。さらにＤ２Ｄ装置は、発見メッセージのシグナリングプロトコルを利用して装置の発見を実行する。例えば、Ｄ２Ｄ対応ユーザ機器が、自身の発見メッセージを送信することができ、別のＤ２Ｄ対応ユーザ機器がこの発見メッセージを受信し、この情報を使用して通信リンクを確立することができる。ハイブリッドネットワークの利点として、Ｄ２Ｄ装置がネットワークインフラストラクチャの通信範囲内でもある場合、ｅＮＢなどのネットワークエンティティが発見メッセージの送信や設定を追加的に支援することができる。発見メッセージの送信や設定をｅＮＢによって調整／制御することは、Ｄ２Ｄのメッセージングと、そのｅＮＢによって制御されているセルラートラフィックとの干渉が発生しないようにするうえでも重要である。さらには、たとえ装置のいくつかがネットワークカバレッジの範囲外である場合でも、カバレッジ内の装置がアドホック発見プロトコルを支援することができる。

説明においてさらに使用される専門用語を定義する目的で、少なくとも以下の２つのタイプの発見手順が定義されている。
− タイプ１： 発見情報をアナウンスするためのリソースが特定のユーザ機器を対象とせずに割り当てられ、さらに以下を特徴とするリソース割当て手順。
○ 発見情報のアナウンスに使用されるリソースプールの設定をｅＮＢがユーザ機器に提供する。設定はＳＩＢにおいてシグナリングすることができる。
○ ユーザ機器は、示されたリソースプールから（１つまたは複数の）無線リソースを自律的に選択し、発見情報をアナウンスする。
○ ユーザ機器は、各発見期間中、ランダムに選択される発見用リソースで発見情報をアナウンスすることができる。
− タイプ２： 発見情報をアナウンスするためのリソースが特定のユーザ機器を対象として割り当てられ、さらに以下を特徴とするリソース割当て手順。
○ ＲＲＣ＿ＣＯＮＮＥＣＴＥＤモードにあるユーザ機器は、発見情報をアナウンスするためのｅＮＢからのリソースをＲＲＣを介して要求することができる。ｅＮＢはＲＲＣを介してリソースを割り当てる。
○ リソースは、監視するユーザ機器に設定されるリソースプール内に割り当てられる。

タイプ２の手順によると、リソースは例えば発見信号の送信用にセミパーシステントに割り当てられる。

ユーザ機器がＲＲＣ＿ＩＤＬＥモードにある場合、ｅＮＢは以下のオプションの１つを選択することができる。
− ｅＮＢは、発見情報をアナウンスするためのタイプ１のリソースプールをＳＩＢにおいて提供することができる。ＰｒｏＳｅ直接発見を許可されているユーザ機器は、ＲＲＣ＿ＩＤＬＥモードにおいてこれらのリソースを使用して発見情報をアナウンスする。
− ｅＮＢは、自身がＤ２Ｄをサポートしているが、発見情報をアナウンスするためのリソースを提供しないことを、ＳＩＢにおいて示すことができる。ユーザ機器は、発見情報をアナウンスするためのＤ２Ｄリソースを要求するためには、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤモードに入る必要がある。

ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態にあるユーザ機器については、ＰｒｏＳｅ直接発見のアナウンスを実行することが許可されているユーザ機器は、Ｄ２Ｄ発見のアナウンスの実行を望むことをｅＮＢに知らせる。するとｅＮＢは、そのユーザ機器がＰｒｏＳｅ直接発見のアナウンスを許可されているかを、ＭＭＥから受信したＵＥコンテキストを使用して確認する。ｅＮＢは、発見情報のアナウンス用にタイプ１のリソースプールまたはタイプ２の専用リソースを使用するように、専用のＲＲＣシグナリングを介してユーザ機器を設定することができる（またはリソースなし）。ｅＮＢによって割り当てられたリソースは、ａ）ｅＮＢがそのリソースをＲＲＣシグナリングによって設定解除する（de-configure）まで、またはｂ）ユーザ機器がＩＤＬＥモードに入るまで、有効である。

ＲＲＣ＿ＩＤＬＥモードおよびＲＲＣ＿ＣＯＮＮＥＣＴＥＤモードにある受信側ユーザ機器は、許可されるタイプ１およびタイプ２の発見用リソースプールの両方を監視する。ｅＮＢは、発見情報を監視するために使用されるリソースプールの設定をＳＩＢにおいて提供する。ＳＩＢは、隣接セルにおいてアナウンスするために使用される発見用リソースも含むことができる。

［無線プロトコルのアーキテクチャ］
図１４は、ＰｒｏＳｅ直接発見のための無線プロトコルスタック（ＡＳ：Access Stratum）を概略的に示している。

ＡＳレイヤは、上位レイヤ（ＰｒｏＳｅプロトコル）とのインタフェースとして機能する。したがって、ＭＡＣレイヤは上位レイヤ（ＰｒｏＳｅプロトコル）から発見情報を受け取る。この場合、発見情報を送信するのにＩＰレイヤは使用されない。さらに、ＡＳレイヤはスケジューリング機能を有し、ＭＡＣレイヤはこのスケジューリング機能に従って、上位レイヤから受け取った発見情報をアナウンスするために使用するべき無線リソースを決定する。これに加えてＡＳレイヤは、発見ＰＤＵを生成する機能を有し、ＭＡＣレイヤはこの機能に従って、発見情報を伝えるＭＡＣ ＰＤＵを構築し、そのＭＡＣ ＰＤＵを、決定した無線リソースにおいて送信できるように物理レイヤに渡す。ＭＡＣヘッダは追加されない。

ユーザ機器において、ＲＲＣプロトコルは、発見用リソースプールをＭＡＣレイヤに知らせる。さらにＲＲＣは、送信用に割り当てられたタイプ２のリソースをＭＡＣレイヤに知らせる。ＭＡＣヘッダの必要はない。発見に関するＭＡＣヘッダには、Ｌ２においてフィルタリングを実行するときに基づくフィールドが含まれない。ＭＡＣレベルにおいて発見メッセージをフィルタリングしても、上位レイヤにおいてＰｒｏＳｅ ＵＥ ＩＤやＰｒｏＳｅアプリケーションＩＤに基づいてフィルタリングを実行することと比較して、処理量や電力が節約されるとは考えられない。受信側ＭＡＣレイヤは、受け取った発見メッセージすべてを上位レイヤに渡す。このときＭＡＣレイヤは、正しく受信されたメッセージのみを上位レイヤに渡す。

以下では、発見メッセージが正しく受信されたかをＬ１（ＰＨＹ）がＭＡＣレイヤに示すものと想定する。さらに、上位レイヤは必ず有効な発見情報のみをＡＳレイヤに渡すものと想定する。

［Ｄ２Ｄの同期］
同期の主たる役割は、受信機が時間および周波数の基準を取得できるようにすることである。このような基準は、少なくとも次の２つの目的に利用することができる。１）Ｄ２Ｄチャネルを検出するときに受信窓および周波数補正を合わせる、２）Ｄ２Ｄチャネルを送信するときに送信機のタイミングおよびパラメータを合わせる。３ＧＰＰでは、現在のところ同期を目的として以下のチャネルが定義されている。
− Ｄ２ＤＳＳ Ｄ２Ｄ同期信号
− ＰＤ２ＤＳＣＨ 物理Ｄ２Ｄ同期チャネル
− ＰＤ２ＤＳＳ プライマリＤ２Ｄ同期信号
− ＳＤ２ＤＳＳ セカンダリＤ２Ｄ同期信号

さらに３ＧＰＰでは、同期に関する以下の専門用語が合意されており、これらの専門用語は本出願の残りの部分において例示的に使用する。
− Ｄ２Ｄ同期源： 少なくともＤ２Ｄ同期信号を送信するノード。Ｄ２Ｄ同期源は、基本的にはｅＮＢまたはＤ２Ｄ ＵＥとすることができる。
− Ｄ２Ｄ同期信号： ＵＥがそこからタイミングおよび周波数の同期を取得することのできる信号。

Ｄ２Ｄの同期は、ＬＴＥのセルサーチに類似する手順として理解することができる。部分的カバレッジ内シナリオおよびカバレッジ外シナリオにおいてネットワーク制御および効率的な同期の両方を可能にする目的で、現在３ＧＰＰにおいて、受信機および送信機の以下の同期手順が検討されている。

［受信機の同期］
ＰｒｏＳｅ対応ＵＥは、ＬＴＥセル（ＬＴＥのモビリティ手順に従う）と、同期源（ＳＳ：Synchronization Source）ＵＥによって送信されるＤ２ＤＳＳ／ＰＤ２ＤＳＣＨとを、定期的に探索する。

適切なセルが見つかると、ＵＥはそのセルにキャンプオンし、セル同期（ＬＴＥのレガシー手順による）に従う。

ＳＳ（同期源）ＵＥによって送信される適切なＤ２ＤＳＳ／ＰＤ２ＤＳＣＨが見つかると、ＵＥは、入ってくるすべてのＤ２ＤＳＳ／ＰＤ２ＤＳＣＨ（ＵＥの能力による）に自身の受信機を同期させ、入ってくる接続（スケジューリング割当て）がないかそれらを監視する。なお、ｅＮｏｄｅＢであるＤ２Ｄ同期源によって送信されるＤ２ＤＳＳは、リリース８のＰＳＳ／ＳＳＳ（プライマリ同期信号／セカンダリ同期信号）であることに留意されたい。ｅＮｏｄｅＢであるＤ２Ｄ同期源は、ＵＥであるＤ２Ｄ同期源よりも高い優先順位を有する。

［送信機の同期］
ＰｒｏＳｅ対応ＵＥは、ＬＴＥセル（ＬＴＥのモビリティ手順に従う）と、ＳＳ（同期源）ＵＥによって送信されるＤ２ＤＳＳ／ＰＤ２ＤＳＣＨとを、定期的に探索する。

適切なセルが見つかると、ＵＥはそのセルにキャンプオンし、Ｄ２Ｄ信号を送信できるようにセル同期に従う。このような場合、ネットワークは、セル同期に従ってＤ２ＤＳＳ／ＰＤ２ＤＳＣＨを送信するようにＵＥを設定することができる。

適切なセルが見つからない場合、ＵＥは、入ってくるＤ２ＤＳＳ／ＰＤ２ＤＳＣＨのいずれかをさらに中継できる（すなわち最大ホップカウントに達していない）かを確認し、（ａ）さらに中継できる入ってくるＤ２ＤＳＳ／ＰＤ２ＤＳＣＨが見つかった場合、ＵＥは自身の送信機の同期をその信号に合わせ、それに応じてＤ２ＤＳＳ／ＰＤ２ＤＳＣＨを送信する、または、（ｂ）さらに中継できる入ってくるＤ２ＤＳＳ／ＰＤ２ＤＳＣＨが見つからない場合、ＵＥは独立した同期源として動作し、任意の内部同期基準に従ってＤ２ＤＳＳ／ＰＤ２ＤＳＣＨを送信する。

Ｄ２Ｄにおける同期手順のさらなる詳細は、非特許文献９の７節（参照によって本明細書に組み込まれている）に記載されている。

［セルの選択およびＲＲＣ接続の確立］
図１５は、セルを選択してＲＲＣ接続を確立するための、ＵＥとｅＮＢの間の従来技術のメッセージ交換を、簡略的かつ例示的に示している。ステップ２におけるセルの選択は、例えば非特許文献１１の例えば５．２．３節（参照によって本明細書に組み込まれている）に基づく。ＷＡＮ（ワイドエリアネットワーク、例：ＬＴＥ）セルにキャンプオンしていないＵＥは、カバレッジ外（ＯＯＣ）とみなされる。セルへのキャンプオンは、非特許文献１１の５．２．３節に定義されているセル選択基準／プロセスに基づくことができる。したがってステップ２を完了する前は、一般にＵＥはカバレッジ外（ＯＯＣ）とみなされる。セルの選択に成功し、ＵＥが（適切なセルまたは許容されるセルに）キャンプオンすると、そのＵＥはＲＲＣアイドル状態にある。ＵＥは、ステップ７まで（すなわちネットワークからＲＲＣＣｏｎｎｅｃｔｉｏｎＳｅｔｕｐメッセージを受信するまで）ＲＲＣアイドル状態のままであり、そのあとＲＲＣ接続状態に変わる。

3GPP TS 36.211, "Evolved Universal Terrestrial Radio Access (E-UTRA); Physical Channels and Modulation (Release 8)" TS 36.304 3GPP TS36.331 3GPP TS 25.331, "Radio Resource Control (RRC)", version 12.2.0 TS 36.331 v12.2.0 3GPP TS 36.321 3GPP TS 36.843 vers. 12.0.0 TS 36.300 3GPP TS 23.303 V12.1.0 TS 36.843 V12.0.1 3GPP TS 36.304 v12.1.0

本発明を制限することのない例示的な一実施形態は、直接リンク接続を通じて直接通信送信を実行するための無線リソースを送信側端末に割り当てる方法であって、上述した問題を緩和する改良された方法、を提供する。独立請求項は、本発明を制限することのない例示的な一実施形態を提供する。有利な実施形態は、従属請求項の主題である。

第１の態様によると、最新の技術においてすでに定義されているアイドル状態送信用無線リソースプール（idle transmission radio resource pool）に追加される形での、直接通信送信を実行するための追加の（一時的な）送信用無線リソースプールを、ネットワーク事業者によって定義する。最新の技術のアイドル状態送信用無線リソースプールは、アイドル状態にある端末に制限されるが、第１の態様による追加の送信用無線リソースプールは、端末のアイドル状態または接続状態とは無関係であるが、この一時的な送信用無線リソースプールが送信側端末によって使用可能である時間長が制限されるように設定される。したがって、基地局は、この一時的な送信用無線リソースプールに関する情報および対応する設定情報を含むシステム情報を、自身のセル内でブロードキャストする。第１の態様による一時的な送信用無線リソースプールは、最新の技術のアイドル状態送信用無線リソースプールと同様に、システム情報ブロードキャストを受信した送信側端末が、直接リンク接続を通じて受信側端末への直接通信送信を実行するために使用可能な無線リソースを示す。

この第１の態様のさまざまな実装形態は、この追加のリソースプールの使用時間を設定情報によって制限する方法に関して異なり、または、端末が一時的な送信用無線リソースプールのこのようなリソースを使用するときには、端末は基地局との無線接続を確立しなければならない（少なくとも確立を試みなければならない）というさらなる必要条件を含む。

この追加のリソースプールを使用することによって、セル内の端末が基地局との無線接続を確立している間に中断が発生しないようにすることが可能である。

したがって、一般的な一態様においては、本明細書に開示されている技術は、通信システムにおいて直接リンク接続を通じて受信側端末への直接通信送信を実行するための無線リソースを、送信側端末に割り当てる方法、を提供する。本方法は、送信側端末によって実行される次のステップ、すなわち、基地局からシステム情報ブロードキャストを受信するステップであって、システム情報ブロードキャストが、システム情報ブロードキャストを受信する送信側端末によって、直接リンク接続を通じて受信側端末への直接通信送信を実行するために使用可能な無線リソースを示す、一時的な送信用無線リソースプールに関する情報と、一時的な送信用無線リソースプールが送信側端末によって使用可能である時間長を制限する、一時的な送信用無線リソースプールに関する設定情報に関する情報と、を含む、ステップ、を含む。本方法に関与する対応する端末および基地局も提供する。

第２の態様によると、事前に設定される送信用無線リソースプール（preconfigured transmission radio resource pool）を、基地局のセルのカバレッジ内である端末に利用可能であるようにする。このような事前に設定される送信用無線リソースプールは、カバレッジ外の状況での使用については最新の技術においてすでに公知であるが、第２の態様では、このリソースプールの使用を、端末がカバレッジ内である状況にも拡張する。この文脈において「事前に設定される」は、たとえ無線アクセスから何らのシステム情報を受信しなくても、例えば携帯電話のＵＳＩＭカード内の情報によって、あるいはコアネットワークからの上位レイヤシグナリングから、事前に設定される送信用無線リソースプールが端末に既知であることと理解されたい。

第１の態様と同様に、第２の態様のさまざまな実装形態は、端末がセルのカバレッジ内であるときに、このような事前に設定される送信用無線リソースプールがその端末に対して使用可能である時間長を制限するためのオプションを含み、この制限をさまざまな方法で行うことができる。第２の態様の別の実装形態では、事前に設定される送信用無線リソースプールのこのようなリソースを端末が使用するとき、必要条件として、その端末は基地局との無線接続を確立しなければならない（少なくとも確立を試みなければならない）。

したがって、一般的な一態様においては、本明細書に開示されている技術は、通信システムにおいて直接リンク接続を通じて受信側端末への直接通信送信を実行する送信側端末、を提供する。この送信側端末には、直接リンク接続を通じて受信側端末への直接通信送信を実行するために送信側端末によって使用可能な無線リソースを示す、事前に設定される送信用無線リソースプール、が事前設定されており、事前に設定される送信用無線リソースプールは、送信側端末が基地局のセルのカバレッジ内であるときに使用可能である。

開示する実施形態のさらなる恩恵および利点は、本明細書および図面から明らかになるであろう。これらの恩恵および利点は、本明細書および図面に開示したさまざまな実施形態および特徴によって個別に提供することができ、これらの恩恵および利点の１つまたは複数を得るためにすべてを備える必要はない。

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

以下では、例示的な実施形態について、添付の図面を参照しながらさらに詳しく説明する。

３ＧＰＰ ＬＴＥシステムの例示的なアーキテクチャを示している。 ３ＧＰＰ ＬＴＥのＥ−ＵＴＲＡＮアーキテクチャ全体の例示的な概要を示している。 ３ＧＰＰ ＬＴＥ（リリース８／９）のために定義されているダウンリンクコンポーネントキャリアの例示的なサブフレーム境界を示している。 ３ＧＰＰ ＬＴＥ（リリース８／９）に定義されているダウンリンクスロットの例示的なダウンリンクリソースグリッドを示している。 ダウンリンクのキャリアアグリゲーションが有効になっている状態における３ＧＰＰ ＬＴＥ−Ａ（リリース１０）のＬ２レイヤ構造を示している。 アップリンクのキャリアアグリゲーションが有効になっている状態における３ＧＰＰ ＬＴＥ−Ａ（リリース１０）のＬ２構造を示している。 ＲＲＣ＿ＩＤＬＥ状態、セルのカバレッジ内、およびセルのカバレッジ外にあるときに端末に利用可能なリソース割当てモードと、それらリソース割当てモード間の遷移の概要を示している。 ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態、セルのカバレッジ内、およびセルのカバレッジ外にあるときに端末に利用可能なリソース割当てモードと、それらリソース割当てモード間の遷移の概要を示している。 オーバーレイ（ＬＴＥ）およびアンダーレイ（Ｄ２Ｄ）システムにおける送信／受信リソースの使用を示している。 ２基のＵＥの場合のスケジューリング割当て（ＳＡ）およびＤ２Ｄデータの送信を示している。 Ｄ２Ｄ ＵＥに関連付けることのできる４つの異なる状態に関連するカバレッジを示している。 装置間の直接発見のためのＰＣ５インタフェースを概略的に示している。 Ｄ２Ｄ通信において発見用リソースを受信するときのアイドルモードおよび接続モードを示した線図を示している。 ＰｒｏＳｅ直接発見のための無線プロトコルスタックを概略的に示している。 セルを選択してＲＲＣ接続を確立するための、ＵＥとｅＮｏｄｅＢとの間の従来技術による例示的なメッセージ交換を示している。 Ｄ２Ｄ通信関心通知メッセージおよび対応するＤ２Ｄ通信応答の交換を示している。 セルの周縁部におけるＵＥの例示的な動きを示している。 図１５の拡張であり、セルを選択してＲＲＣ接続を確立するための従来技術におけるメッセージ交換を例示的に示しており、ＵＥ−Ａが、Ｄ２Ｄ通信への関心を示し、Ｄ２Ｄ通信の送信用の専用無線リソースを要求する。さらに、さまざまな異なる期間を示している。 ＲＲＣ接続確立手順が失敗する場合のメッセージ交換を示している。 ＵＥがＤ２Ｄ通信の送信を行うことのできない期間を示している。 モード１のリソースの場合にＵＥがＴ−ＲＰＴパターンをサブフレームに適用する方法を示している。 モード２のリソースの場合にＵＥがＴ−ＲＰＴパターンをサブフレームに適用する方法を示している。

以下の実施形態は、例えば、背景技術のセクションにおいて説明した３ＧＰＰ ＬＴＥ−Ａ（リリース１０／１１／１２）などの移動通信システムにおいて有利に利用することができるが、これらの実施形態は、この特定の例示的な通信ネットワークにおける使用に限定されないことに留意されたい。

移動局またはモバイルノードまたはユーザ端末は、通信ネットワーク内の物理的なエンティティである。１つのノードが、いくつかの機能エンティティを有することができる。機能エンティティとは、所定の一連の機能を実施する、もしくは、ノードまたはネットワークの別の機能エンティティに所定の一連の機能を提供する、またはその両方であるソフトウェアモジュールまたはハードウェアモジュールを意味する。ノードは、自身を通信機器または通信媒体にアタッチする１つまたは複数のインタフェースを有することができ、ノードはこれらのインタフェースを通じて通信することができる。同様に、ネットワークエンティティは、機能エンティティを通信機器または通信媒体にアタッチする論理インタフェースを有することができ、ネットワークエンティティは論理インタフェースを通じて別の機能エンティティやコレスポンデントノードと通信することができる。

特許請求の範囲および本出願において使用されている「送信側端末」は、送信機の役割のユーザ端末を意味する。逆に、「受信側端末」は、受信機の役割のユーザ端末を意味する。形容詞である「送信側」および「受信側」は、一時的な動作／役割を明確にすることを意図しているにすぎない。

特許請求の範囲および本出願において使用されている「直接通信送信」は、一例として、ＬＴＥリリース１２において現在検討されている装置間（Ｄ２Ｄ）通信を意味する。これに対応して、用語「直接リンク接続」は、一例として、２基のＤ２Ｄユーザ端末を直接接続するＰＣ５インタフェースを通じての接続チャネルまたは通信チャネルであって、ネットワークの関与なしにデータの直接的な交換を可能にする接続チャネルまたは通信チャネル、を意味する。言い換えれば通信チャネルは、通信システムにおいて、データを直接交換するのに十分に近い２基のユーザ機器の間に、ｅＮｏｄｅＢ（基地局）をバイパスして確立される。

特許請求の範囲および本出願において使用されている用語「無線接続確立手順」は、ランダムアクセス手順を含む手順、または含まない手順として理解することができる。したがって、無線接続確立手順を開始することは、ランダムアクセス手順のプリアンブルを送信することと等価であるものとして、または、ＲＲＣ接続要求メッセージを送信することと等価であるものとして、理解することができる。したがって、３ＧＰＰ ＬＴＥの文脈においては、無線接続確立手順は、ＲＲＣ接続確立手順が後に続くランダムアクセス手順とすることができる。

特許請求の範囲および本出願において使用されている用語「専用無線リソース」は、基地局（ｅＮｏｄｅＢ）によって特定の端末に明示的に割り当てられる無線リソースとして理解されたい。専用無線リソースは、それ自体は、背景技術のセクションにおいて説明したように、モード１のリソースまたはモード２のリソースのいずれかとすることができる。この用語は、セル内の端末によって共通に使用することのできる「共通無線リソース」と対照される語として理解されたい。例えば、システム情報（例えばＳＩＢ１８）によって定義される送信用無線リソースプールがセル内でブロードキャストされ、したがってこの無線リソースは、このシステム情報を受信する端末によって使用することができる。

「無線接続確立手順を開始する」という表現および類似する表現は、基地局との無線接続の確立を試みることが端末に要求されることと理解されるものとし、ただし無線接続確立手順は失敗してもよいことに留意されたい。言い換えれば、無線接続の確立を試みることが端末に要求されるが、端末は、対応する無線接続確立手順を開始することのみに成功し、その無線接続確立手順をそのまま続けて無線接続を正常に確立することに成功しなくてもよい。したがって、この表現において、無線接続確立手順を開始するというこの必要条件は、その結果、すなわち、無線接続の確立に成功する（例えばＲＲＣ接続設定メッセージを受信する）、または失敗する（例えばＲＲＣ接続拒否メッセージを受信する）かには無関係であることを理解されたい。

特許請求の範囲および本出願において使用されている「送信用無線リソースプールが使用可能である」という表現（および類似する表現）は、端末が（例えばスケジューリング割当て（ＳＡ）または直接通信データの）直接通信送信を実行することを望む場合に、端末が送信用無線リソースプールから（必須ではないが）リソースを選択して使用することができるという意味として、広義に理解されたい。これに対応して、送信用無線リソースプールが使用されるという表現（および類似する表現）は、端末が直接通信送信を実行することを実際に意図しており、送信用無線リソースプールから適切なリソースを選択し、選択されたそのリソースにおいてその直接通信送信を実行するという意味として、広義に理解されたい。

特許請求の範囲および本出願において使用されている「カバレッジ内」という表現は、端末がセルを正常に選択していれば、端末がアイドル状態にあるか接続状態にあるかには無関係に、その端末はカバレッジ内であるとみなされるという意味として、広義に理解されたい。セルの選択の基準は、非特許文献２に定義されている。すべてのカバレッジ内ＵＥは、（アイドル状態または接続状態において）ブロードキャストメッセージを使用して、または接続状態において専用（すなわちＵＥとネットワークとの間の１対１の）メッセージを使用して、ネットワークからシグナリングを受信することができる。例えば、ＵＥがサービングセルを有する（すなわちＵＥがＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態にある、またはＲＲＣ＿ＩＤＬＥ状態においてセルにキャンプオンしている）場合、そのＵＥはカバレッジ内であるとみなされる。したがって、「カバレッジ外」という表現は、この逆の意味として理解されたい。

特許請求の範囲および本出願において使用されている用語「事前に設定されている」は、たとえ無線アクセスから何らの情報も受信しなくても、リソースプールの対応するリソースが端末に既知である、すなわち、事前に設定されている無線リソースプールは、セルおよびセル内のシステム情報ブロードキャストとは無関係に利用可能であるという意味として、広義に理解されたい。

特許請求の範囲および本出願において使用されている用語「無線リソース」は、物理無線リソース（時間−周波数リソースなど）を意味するものと広義に理解されたい。

背景技術のセクションにおいて説明したように、ＵＥは、その状態およびｅＮＢによる設定に応じて、別のＵＥとのＤ２Ｄ直接通信用に異なるリソースを使用することができる。本発明者は、直接通信の現在考えられている実装形態（すなわち３ＧＰＰ Ｄ２Ｄ通信）に関して多くの問題点および欠点を認識した。以下のさまざまなシナリオおよび問題が存在し、これらについて図１８に関連して説明する。図１８（図１５の拡張である）は、図１５に加えて、ＵＥがＤ２Ｄ通信への関心を示し、このＵＥがＤ２Ｄ通信の送信用の専用無線リソースを要求するステップと、さまざまな異なる期間０，１，２，Ａ，Ｂ，Ｃ，Ｄを示している。図１８には示していないが、背景技術のセクションにおいて説明したように、ＵＥは、セルのカバレッジ外であるとき、スケジューリング割当て（ＳＡ）およびＤ２Ｄデータの受信／送信用に、事前に設定されるモード２のリソースを有することができる。

ｅＮＢは、自身のネットワーク内において、ＵＥがＲＲＣアイドル状態にあるときにモード２のリソース割当てができないことを決定することができる。説明を目的として、このようなタイプのネットワークをタイプＡのネットワークと称する。特に、タイプＡのネットワークにおいては、ＵＥは、Ｄ２Ｄが許可されることをＳＩＢ１８の中で認識するが、Ｄ２Ｄ用にブロードキャストされる共通のモード２のリソース（例：モード２によるリソースプール）が存在しないため、ＵＥは最初にＲＲＣ接続を確立しなければならない（図１５を参照）。次いでＵＥは、（例えばＤ２Ｄ通信関心通知および対応するＤ２Ｄ通信応答を使用して（図１６を参照））Ｄ２Ｄに関して適切に設定された後、（ｅＮＢによるＵＥに対する設定（Ｄ２Ｄ通信応答メッセージに対応する）によっては）送信用にモード２のリソースにアクセスすることができる。Ｄ２Ｄ通信用に（例えば専用のモード２のリソースプールとして）使用可能なリソースが、Ｄ２Ｄ通信応答によって提供されない場合、背景技術のセクションで前述したように（節「Ｄ２Ｄ通信における送信手順」内のステップ１〜５を参照）、ＵＥはＤ２Ｄに関連するリソースを、専用シグナリング（スケジューリング要求、バッファ状態報告）を使用して明示的に要求する必要があり、これによりさらなる時間がかかる（期間Ｃを参照）。

さらには、図１８に示した期間Ｄは、対応するＤ２Ｄグラントを受信した後に最初のＤ２Ｄを送るときの遅延である。この遅延は無視できるとも考えられるが、無視できないことがあり、なぜなら本発明者による計算によると、各スケジューリング割当て（ＳＡ）およびデータ用のリソースプールのビットマップの周期、それらのオフセット（例えばＳＦＮ（システムフレーム番号）０からのオフセット）、割り当てられるＴ−ＲＰＴ（送信の時間リソースパターン（time resource pattern of Transmission））などのリソース設定によっては、期間Ｄだけで約３００〜４００ｍｓにもなりうる。

結果としてＵＥは、図１８に示した期間２が終わるまでにＤ２Ｄ通信を実行することができず、さらには、ｅＮＢからのＤ２Ｄ通信応答によってＤ２Ｄが許可されても、この通信応答によってＵＥに専用のモード２のリソースが提供されない場合（この場合にはＵＥは特定のＤ２Ｄ送信用のリソースのグラントを明示的に要求する必要がある）、期間Ｃおよび期間ＤにわたってもＤ２Ｄ通信を実行することができない。

タイプＡのネットワークでは、ネットワーク事業者はリソースの使用を完全に制御することができる。なぜならネットワーク事業者は、Ｄ２Ｄを実行しているＵＥの数を認識し、したがってＤ２Ｄ用途とＬＴＥ用途との間でリソースを分配できるためである。しかしながら、このようなタイプＡのネットワーク内のＵＥは、アイドル状態においてはいかなるＤ２Ｄ通信も実行することができない。さらには、ＲＲＣ接続状態になった後も、ＵＥはＤ２Ｄ通信関心通知メッセージを送信し、少なくとも明示的なネットワーク応答を待機してＤ２Ｄ通信リソースを受信しなければならず、通信データを実際に送信できるまでには、さらなる時間（期間Ｃおよび／または期間Ｄ）待たなければならない。この遅延は、合計すると容易に２秒以上になりうる。リリース１２においては、Ｄ２Ｄ通信は主として公共安全性の用途を対象としているため、特にＶｏＩＰ／音声／会話のサービスクラスの場合、たとえ２秒の遅延／中断も許容されない。このことは、特に、カバレッジ外状況とカバレッジ内状況との間を行き来することのあるセル周縁部のＵＥにあてはまる。図１７は、セルの周縁部において移動するＵＥを示している。

この問題は、ＲＲＣアイドル状態において使用される共通のモード２のＤ２Ｄ通信リソースがｅＮＢによるネットワーク配備によって提供される別のタイプのネットワークにおいて限定的に緩和される。このようなネットワークは、説明を目的としてタイプＢのネットワークと称することができる。このようなタイプＢのネットワークにおいては、ＵＥは、ＳＩＢ１８（対応するモード２のアイドル状態リソース（idle resource）の設定（例：ｃｏｍｍＩｄｌｅＴｘＰｏｏｌ）を含む）を取得した後に（したがってタイプＡのネットワークにおけるよりも早く）、このようなモード２のアイドル状態リソースを使用してＤ２Ｄ通信を開始する。したがってこれらのＵＥは、期間Ｂ，Ｃ，Ｄにおいて再び中断が発生する少し前にＤ２Ｄデータ通信を実行することができる。したがってＵＥは、期間０においてＤ２Ｄ通信を実行することはできないが、期間Ａの間にＤ２Ｄ通信を実行することができる。

しかしながら、タイプＢのネットワークにおいても、ＵＥは、特定のタイミングにおいて、Ｄ２Ｄ通信を実行することが抑制され、これにより望ましくない遅延および／または中断が発生する。ＵＥは、ＲＲＣアイドル状態にある限りはモード２のアイドル状態リソースを継続して使用することができる。ＳＩＢ１８を介しての最新の技術のモード２のアイドル状態リソースは、ＲＲＣアイドル状態においてのみ使用することができる。しかしながら、（何らかの理由で、例えばＷＡＮの理由で（例：インターネットにアクセスするために））ＵＥがＲＲＣ接続を確立し、したがってＲＲＣ接続状態に変わると（図１５のステップ７を参照）、そのＵＥは、Ｄ２Ｄ通信を続行または開始する目的に（すなわち図１５のステップ７の時点で）、ＳＩＢ１８によって定義されるモード２のリソースプールのこれらのリソースをもはや使用することができない。このような場合、以前に開始したＤ２Ｄ通信を再開する、または新しいＤ２Ｄ通信を開始するためには、ＵＥは少なくともＤ２Ｄ通信関心通知メッセージを送信し、明示的なネットワーク応答を待機して、モード２のＤ２Ｄ通信リソースを受け取らなければならない（またはＤ２Ｄ通信の送信手順のステップ１〜５に関連して上述したように、特定のＤ２Ｄ送信用のリソースのグラントを明示的に要求する必要があるときにはさらに長い時間待機しなければならない）。このことは通信の遅延および／または中断につながる。ＵＥは、期間Ｂ，Ｃ（，およびＤ）においてＤ２Ｄ通信を実行することができない。

図２０は、図１８において説明したさまざまな期間をブロックとして示しており、タイプＡのネットワークとタイプＢのネットワークについて、ＵＥがＤ２Ｄ通信の送信を行うことのできない期間の差を図解している。

図１９は、図１８に似ているが、ＲＲＣ接続の確立に失敗する場合を示している。図から明らかであるように、ＲＲＣ接続の確立を開始した後、確立に失敗する（例えば、ＲＲＣ接続がｅＮＢによって拒否されるため、または、セルの再選択など別の理由で、あるいはＴ３００が切れることも起こり得る）。いずれの場合にも、ＵＥはＲＲＣアイドル状態のままである。タイプＡのネットワークにおいては、このような状況は特に不利である。なぜならＵＥは、アイドル状態にある間はＤ２Ｄ通信をまったく実行することができないためである。これに対してタイプＢのネットワークの場合、モード２のアイドル状態リソースの設定を含むＳＩＢ１８を取得した後に（すなわち期間Ａの間に、およびそれ以降において）、Ｄ２Ｄ通信が可能である。

タイプＢのネットワークの場合の１つの適切な（かつ容易に実施される）解決策は、少なくとも、直接通信送信に使用可能である専用リソースがｅＮｏｄｅＢによって端末に割り当てられるまでは（図１８の期間Ｂ＋Ｃ（＋Ｄ）を参照）、モード２のアイドル状態リソース（ｃｏｍｍＩｄｌｅＴｘＰｏｏｌ）が、ＲＲＣ接続状態にある端末によっても使用可能であるようにすることである。

本発明者は、上述した問題を緩和するため、以下の第１の例示的な実施形態および第２の例示的な実施形態を着想した。

以下では、いくつかの例示的な実施形態について詳しく説明する。これらの実施形態のいくつかは、３ＧＰＰ標準規格によって与えられる幅広い仕様（背景技術のセクションでその一部を説明した）の中で実施されるように意図されており、特に重要な特徴について、以下にさまざまな実施形態に関連して説明する。なお、これらの実施形態は、例えば背景技術のセクションで説明した３ＧＰＰ ＬＴＥ−Ａ（リリース１０／１１／１２）通信システムなどの移動通信システムにおいて有利に使用することができるが、これらの実施形態は、この特定の例示的な通信ネットワークにおける使用に限定されないことに留意されたい。

以下の説明は、本開示の範囲を制限するものではなく、本開示を深く理解するための実施形態の単なる例であるものと理解されたい。当業者には、請求項に記載されている本開示の一般的な原理を、さまざまなシナリオに、本明細書に明示的に説明されていない方法で、適用できることが認識されるであろう。したがって、さまざまな実施形態を説明する目的で想定される以下のシナリオは、本発明をそのようなシナリオに制限するものではない。

［第１の実施形態］
以下では、第１の一連の実施形態について説明する。第１の実施形態の原理の説明を簡略化するため、いくつかの想定を行うが、これらの想定は、特許請求の範囲によって広く定義されている本出願の範囲を限定するものとして解釈されるべきではないことに留意されたい。

第１の態様によると、直接通信送信を実行するための追加の送信用無線リソースプールを、ネットワーク事業者によって定義し、この追加のリソースプールは、従来技術からすでに公知であるアイドル状態送信用無線リソースプールとはいくつかの点で異なる。背景技術のセクションで説明したように、ネットワーク事業者がこのようにすることを決定するならば、送信用無線リソースプールに関する情報を基地局によってそのセル内でブロードキャストすることができる。したがって、このシステム情報ブロードキャストを受信した端末は、別の端末との直接通信の実行を望む場合、この送信用無線リソースプールからのリソースを自律的に使用することができる。従来技術の送信用無線リソースプール（便宜上、アイドル状態送信用無線リソースプールと称する）は、アイドル状態にある間に端末によって使用可能であるが、端末の状態が接続状態に変わると、上述した問題のいくつかが発生する。

これに対して、この第１の態様に従って導入される追加の送信用無線リソースプール（便宜上、一時的な送信用無線リソースプールと称する）は、一時的にのみ（すなわち限られた時間長に渡り）使用されるが、端末がアイドル状態にあるか接続状態にあるかには無関係である。ネットワーク事業者は、この一時的な送信用無線リソースプールが使用可能である時間長を、システム情報ブロードキャストの中の対応する追加の指示情報（設定情報）によって制御することができる。この一時的な送信用無線リソースプールの使用可能性を制限することは、いくつかの異なる方法で実施することができ、そのうちのいくつかを後から例示的に説明するが、いずれの方法においても、この一時的リソースを使用できる時間が制限され、基地局（すなわちネットワーク事業者）によって制御することができる。

ネットワーク事業者は、システム情報ブロードキャストを介してアイドル状態送信用無線リソースプールを端末に共通に利用可能にすることに躊躇して、自社の無線リソースに対する完全な制御（または少なくともできる限り多くの制御）が維持されるように、特定の端末に特定の専用リソースプールを割り当てる、あるいは各端末に特定の専用物理リソースのみを割り当てることを選ぶことができる。したがって、ネットワーク事業者は、端末が自身のセル内で従来技術のアイドル状態送信用無線リソースプールを自律的に使用することを望まないことがある。その理由としては、例えば、（端末がアイドル状態にある限り）端末はこのアイドル状態送信用無線リソースプールからのリソースをほぼ無制限に使用することができる、あるいは自律的に使用する場合、何基のＵＥがこれらのアイドルモードＤ２Ｄリソースを実際に使用しているかをネットワークが認識せず、なぜならネットワークはこのようなＵＥの数に関して知ることができないためである（アイドルモードのＵＥはセルレベルでは認識されず、セルレベルより十分に大きいトラッキングエリアのレベルでのみ認識される）。このためネットワークは、このアイドルモードＤ２Ｄリソースが少なすぎる（すなわちＤ２Ｄリソースの使用において多くの衝突が発生する）のか、多すぎる（すなわち本来ならばＬＴＥのリソースが不必要に消費される）のかを判断することができない。これに対して、追加の一時的な送信用無線リソースプールの場合には、ネットワーク事業者は、（程度の差はあるが）設定可能な時間長に渡り使用可能である物理リソースを正確に定義することができる。当然ながらこの方法の直接的な恩恵として、端末は、一時的な送信用無線リソースプールに関する情報を含む対応するシステム情報ブロードキャストを受信して処理した時点で、直ちに直接通信送信用のリソースにアクセスすることができる。その一方で、ネットワーク事業者は、このようなリソースが端末のセル内で端末に共通に利用可能になる時間を柔軟に制御することができる。ＲＲＣ接続を確立しているＵＥの数は、セル内のアイドルモードにあるＵＥの総数よりも非常に少ないため、追加の一時的な送信用無線リソースプールは、ＳＩＢ１８においてブロードキャストされる従来技術の（モード２の）アイドル状態送信用無線リソースプールと比較して、サイズの面で十分に効率的／少量とすることができる。追加の一時的な送信用無線リソースプールは、このようなアイドル状態送信用無線リソースプールを実際に提供しないセル内に存在する端末にとって、特に有利である。しかしながら、追加の一時的な送信用無線リソースプールは、アイドル状態送信用無線リソースプールを実際にブロードキャストする他方のタイプのセル内の端末にとっても有利である。なぜなら、その場合、端末がすでに接続状態にあるが直接通信送信に使用するための専用リソースが基地局によってまだ割り当てられていないとき、または端末がＤ２Ｄ通信のデータをまだ実際に送信していないときにも、直接通信送信用のリソースが利用可能であるためである。

要約すると、従来技術のアイドル状態送信用無線リソースプールの代わりに、またはこれに加えて、第１の態様の一時的な送信用無線リソースプールを、セルのシステム情報ブロードキャストの中で提供することによって、端末の直接通信の遅延または中断が減少する、またはほぼ排除され、それと同時に、ネットワーク事業者には、このようなリソースに対するできる限り多くの制御が与えられる。具体的な実装によって異なるが、タイプＡのネットワークのセル（すなわちシステム情報にアイドル状態送信用無線リソースプールが含まれない）においては、端末は、上述した一時的な送信用無線リソースプールを受け取った後、すなわち図１８に示した期間Ａ、期間Ｂ、期間Ｃ、および期間Ｄの間、このリソースプールからリソースを使用することができる。タイプＢのネットワークのセルにおいては、端末は、期間Ｂ＋Ｃ＋Ｄの間、一時的な送信用無線リソースプールからリソースを使用することができる。

第１の態様のさらなる実装形態は、セル内の送信側端末によって一時的な送信用無線リソースプールが使用可能である時間長を、設定情報によって制限する方法に関する。例えば、システム情報ブロードキャストが、一時的な送信用無線リソースプールの適切な時間長（例：１０ｍｓ、１００ｍｓ、２０００ｍｓ）を直接示すことができる。この場合、具体的な実装によって異なるが、端末は、この示された時間長を、例えばシステム情報ブロードキャストを受信した後にその特定の時間に渡り一時的な送信用無線リソースプールが使用可能であるものと解釈する。あるいは、端末がシステム情報ブロードキャストを受信したときにタイマを起動する代わりに、送信側端末が（例えば直接通信送信において別の端末にスケジューリング割当てを送信することによって）一時的な送信用無線リソースプールの使用を開始したときに、タイマを起動することができる。いずれの場合にも、この方法の具体的な恩恵として、このような設定は無線接続の確立手順およびその結果とは無関係であり、したがって基地局によって予測可能である。

時間長を直接示す代わりに、またはそれに加えて、端末がこのリソースをそれ以上使用することを停止させる特定の条件／イベントを指定することよって、一時的な送信用無線リソースプールが使用可能である時間を「間接的に」制限することができる。例えば、一時的な送信用無線リソースプールに関連する指示として、これらのリソースの使用を望む端末は、その端末がアイドル状態を維持してこのようなリソースを無制限に使用することを回避するため、基地局との無線接続の確立をさらに試みなければならないという指示を、システム情報ブロードキャストに含めることができる。この場合、端末には、接続が確立されて基地局によって専用無線リソースが端末に割り当てられるまでの間のみ（図１８の期間Ａ＋Ｂ＋Ｃを参照）、その一時的な送信用無線リソースプールからリソースを使用することが許可され、専用無線リソースが割り当てられた後の直接通信送信には、代わりにその専用無線リソースが使用される。または、接続を確立することができない、あるいは接続が拒否される場合、その確立の失敗について端末に通知されるまでの間のみ（図１９の期間Ａを参照）、一時的な送信用無線リソースプールからリソースを使用することが端末に許可される。または、その時点において基地局が、端末との接続は確立するが、端末が直接通信送信を実行することを許可しないことがある（図１８の期間Ａ＋Ｂを参照）。さらには、基地局によって端末に割り当てられた専用無線リソースを端末が実際に使用するまでにかかる時間が長くなりうることを考慮して、さらなる代替方式では、端末が（基地局との無線接続を確立し、直接通信送信用の専用無線リソースを基地局から受信した後）、基地局によって端末に割り当てられたこれらの専用無線リソースを使用してスケジューリング割当て（ＳＡ）またはデータの直接通信送信を実際に実行する時点まで（図１８の期間Ａ＋Ｂ＋Ｃ＋Ｄを参照）、一時的な送信用無線リソースプールが使用可能である時間を延長することができる。

接続を確立させる実際の指示は、例えば、具体的な時間長であって、その時間内に端末が接続の確立を（少なくとも）開始する（例えばシステム情報ブロードキャストを受信した直後、または一時的な送信用無線リソースプールの使用を開始した直後に開始する）必要のある時間長を示すことができる。さらに別のオプションとして、直接通信送信用に一時的な送信用無線リソースプールから無線リソースを使用することが許可される前に、端末が接続の確立を開始するように要求する。この目的においては、端末は、一例としてランダムアクセス手順のプリアンブルを送信することによって、基地局との接続の確立を開始するものと理解することができる。

これに加えて、第１の態様においては、従来技術のアイドル状態送信用無線リソースプールの場合と同様に、一時的な送信用無線リソースプールにおいて、スケジューリング割当て（ＳＡ）を直接リンクを通じて別の端末に直接通信送信するために利用可能なリソースと、「直接」データを直接リンクを通じて別の端末に直接通信送信するために利用可能なリソースとを、区別することができる。したがってセルは、スケジューリング割当て（ＳＡ）の送信用とデータの送信用に、異なるリソースを提供することができる。

ここまで、第１の態様のいくつかの異なる実装形態を説明してきた。以下では、この第１の態様およびその実装形態の背後の原理を、ＬＴＥシステム（背景技術のセクションで説明したＬＴＥシステムなど）に例示的に適用する。

特に、３ＧＰＰによる現在の標準化では、ＰｒｏＳｅ直接通信および直接発見に関連するいくつかの情報を、ＳＩＢ１８を使用して含めることが考慮されている。したがって、上述した一時的な送信用無線リソースプールに関する情報およびその設定情報を、このＳＩＢタイプ１８の一部とすることができる。当然ながら、この第１の態様の目的には、任意の別のタイプのシステム情報ブロックを使用してこの情報を伝えることができることに留意されたい。さらに、具体的な例においては、一時的な送信用無線リソースプールおよびその設定情報を伝えるための、システム情報ブロック内の選択されたフィールドは、「commTxPoolTemp」と称する。この場合にも、この態様の目的には、このフィールドに対して任意の別の名前を選ぶことができる、あるいは一時的な送信用無線リソースプールに関する情報を、対応する設定情報の別のフィールドに挿入できることに留意されたい。特定の変数commSA-TxResourcePoolCommonTempおよびcommData-TxResourcePoolCommonTempに選択される名前およびフォーマットにも、同じことがあてはまる。

したがって、システム情報ブロックタイプ１８の情報エレメントの以下の定義は、単なる例として理解されたい。

第１の態様において、従来技術と比較してこの例示的なシステム情報ブロックタイプ１８の情報エレメントに導入された重要な変更箇所は、容易に認識できるように太字とし下線を引いてある。表から明らかであるように、この特定の例においては、設定情報は変数「allowedTime」として実施されており、この変数は、上述したように例示的な時間の値として１００ｍｓ、２００ｍｓなどをとり、したがって時間長を直接制限する。当然ながら、これらの具体的な時間値と、設定可能である時間値の数は、単なる例として理解されたい。任意の別の時間値と、設定可能な時間値の数を適宜選択することができる。端末は、変数「allowedTime」によって示される値を読み取ることによって、そのシステム情報ブロードキャストを受信した後に（または直接通信を実行するために端末が一時的な送信用無線リソースプールからのリソースの使用を開始した後に）一時的な送信用無線リソースプールが使用可能である時間長を求めることができる。ＵＥは、対応するタイマを設定および起動して、監視することができる。

さらなる代替として、ＳＩＢ１８の定義の別の例を以下に示す。上の例示的な定義の場合と同様に、変数に付けられている名前と、変数に与えられた具体的な値は、単なる例として理解されたい。

第１の態様において、従来技術と比較してこの例示的なシステム情報ブロックタイプ１８の情報エレメントに導入された重要な変更箇所は、容易に認識できるように太字とし下線を引いてある。上の表から明らかであるように、一時的な送信用無線リソースプール（すなわちcommTxPoolTemp）の使用を、後から説明するように異なる終了条件に基づいて間接的に制限するため、設定変数timeToInitiateRRCConnEstが含まれている。この設定変数timeToInitiateRRCConnEstを使用することによって、ＵＥには、上に示したように例示的な時間である１ｍｓまたは５ｍｓなどの時間内にｅＮＢとのＲＲＣ接続の確立を試みるように指示される。ＵＥのさまざまな挙動に応じて、例えば、ＲＲＣ接続が確立されてｅＮＢが専用無線リソースを端末に割り当てるまで、または、ＲＲＣ接続の確立に失敗したことをＵＥが認識するまで、または、セル内では直接通信の実行が許可されないことをｅＮＢがＵＥに通知するまで、または、ｅＮＢによってＵＥに割り当てられた専用リソースを使用してスケジューリング割当て（ＳＡ）またはデータの直接通信を実際に実行するまで、ＵＥに、一時的な送信用無線リソースプールのリソースの使用を許可することができる。

さらに、この新規のフィールドcommTxPoolTempは、ＳＩＢ１８におけるオプションであり、したがってこのフィールドをセル内でブロードキャストするか否かの決定はネットワーク事業者に委ねられることに留意されたい。commIdleTxPoolフィールド（最新の技術においてすでに定義されている）もオプションであるため、結果としてネットワーク事業者は、必要に応じてcommIdleTxPoolフィールドおよびcommTxPoolTempフィールドの一方または両方を（ｅＮＢを介して）設定する、またはいずれも設定しないことができる。

当然ながら、上に示したＳＩＢ１８の複数の定義を組み合わせることも可能であり、これにより、commTxPoolTempフィールドに変数「allowedTime」および「timeToInitiateRRCConnEst」が含まれるように設定することができる。

［第２の実施形態］
本発明の第２の態様も、従来技術に内在する上述した問題を解決するが、異なる方法で解決する。第１の態様において行ったようにシステム情報ブロードキャストの中に追加の送信用無線リソースプールを定義する代わりに、この第２の態様は、事前に設定される送信用無線リソースプールを、（従来技術において現在定義されているように）端末がセルのカバレッジ外であるときのみならず、端末がセルのカバレッジ内であるときにも、直接通信送信用に使用するという発想に基づく。この文脈において「事前に設定される」は、基地局からのシステム情報ブロードキャストによって設定される、「設定される」リソースとは区別される。言い換えれば、事前に設定されるリソースは、例えば、たとえ無線アクセスから何らの情報を受信しなくても端末（および基地局）に既知であり、すなわちセルおよびセル内のシステム情報ブロードキャストとは無関係である。事前に設定される無線リソースは、それ自体は最新の技術に属し、セルのカバレッジ外である（すなわちセルの基地局から何らのシステム情報ブロードキャストも受信していない）ＵＥによってすでに使用されている。

例えば、事前に設定される送信用無線リソースプールは、ネットワーク事業者によって定義し、最も一般的な携帯電話に挿入して使用することのできる共通のｓｉｍ／ＵＳＩＭカードにハードコーディングすることができる。これに代えて、そのような事前に設定される送信用無線リソースプールに関する適切な情報を、上位レイヤシグナリングを使用して（例えばコアネットワークからインターネットプロトコルまたは非アクセス層プロトコルを介して）端末に提供することができる。

端末は、セルのカバレッジ内であるときにも、事前に設定される送信用無線リソースプールから無線リソースを使用することによって、直接通信送信を実行することができる。このことは、自身がシステム情報ブロードキャストを受信するか、システム情報ブロードキャストにリソースプールに関する情報が含まれているか、無線接続が確立されているか否か、端末が現在どの状態（アイドル状態または接続状態）にあるか、には無関係である。したがって端末は、直接通信送信に関して抑制される、遅延される、または中断されることがない。したがって第１の実施形態とは異なり、第２の態様によると、端末は、期間Ａ，Ｂ，Ｃ，Ｄに加えて期間０においても直接通信送信を実行することができる。

１つのオプションは、カバレッジ外の端末を対象として最新の技術においてすでに定義されている、事前に設定される送信用無線リソースプールを、基地局のセルのカバレッジ内である端末にも適用されるように再設定することである。

その一方で、代替のオプションは、カバレッジ外の端末を対象として最新の技術においてすでに定義されている、事前に設定される送信用無線リソースプールに加えて、新規の事前に設定されるカバレッジ内送信用無線リソースプール（in-coverage preconfigured transmission radio resource pool）を設定することであり、この事前に設定されるカバレッジ内送信用無線リソースプールは、カバレッジ内である端末に適用されるが、依然として基地局のセルのカバレッジ外である端末が使用することはできない。この場合、最新の技術のカバレッジ外を対象とする事前に設定される送信用無線リソースプールと、第２の態様による、事前に設定されるカバレッジ内送信用無線リソースプールの両方を、ｓｉｍ／ＵＳＩＭカードに記憶する、またはこれに代えて、上述したように上位レイヤシグナリングによって定義することができる。

第２の態様のさらなる発展形態においては、ネットワーク事業者は、この事前に設定される送信用無線リソースプールが、（たとえ特定の端末に対してこのリソースプールが事前に設定されている場合でも）自社のセル内で実際に使用可能であるかに関して一部の制御を行う。例えばネットワーク事業者は、自社のセル内では、これらの事前に設定される送信用無線リソースプールのリソースが端末に利用可能ではないことを決定することができる。これを目的として、セルのカバレッジ内である端末に、事前に設定される送信用無線リソースプールの使用が許可されるか否かを、システム情報ブロードキャストが適切に示す。

これを示すための１つの可能かつ単純な方法は、システム情報の中の１ビットのフラグであり、一方のビット値は、セルのカバレッジ内の端末に対して、事前に設定される送信用無線リソースプールの使用が許可されることを示し、他方のビット値は、許可されないことを示す。

これに代えて、システム情報は、事前に設定される送信用無線リソースプールの設定情報をオプションとして含むことができ、この設定情報が存在しないときには、端末は、事前に設定される送信用無線リソースプールが使用されないことを認識する。これに対して、事前に設定される送信用無線リソースプールに関する設定情報がシステム情報の中に存在する。したがってセルにアタッチされている端末によって受信されるときには、その端末は、直接通信送信用に、事前に設定される送信用無線リソースプールを引き続き使用できるが、このリソースプールの使用に関してその設定情報がさらに適用されることを認識する。

設定情報は、さまざまな形をとることができる。例えば、第２の態様の改良形態によると、セルのカバレッジ内である間の、この事前に設定される送信用無線リソースプールの使用を時間的にも制限することが有利である。第１の態様に関連して説明したように、特定の無線リソースプールが端末に使用可能である時間長を制限する方法として、いくつかの可能な方法がある。したがって、事前に設定される送信用無線リソースプールの設定情報は、一時的な送信用無線リソースプールの場合に上述した設定情報に類似する、または同じとすることができる。

詳細には、システム情報ブロードキャストは、事前に設定される送信用無線リソースプールの適切な時間長を例えば直接示す（例：１０ｍｓ，１００ｍｓ，２０００ｍｓ）ことができる。この場合、具体的な実装によって異なるが、端末は、この示された時間長を、事前に設定される送信用無線リソースプールが、例えばシステム情報ブロードキャストを受信した後にその特定の時間にわたり使用可能であるものと解釈する。あるいは、端末がシステム情報ブロードキャストを受信したときにタイマを起動する代わりに、送信側端末が（例えば直接通信送信においてスケジューリング割当て（ＳＡ）を別の端末に送信することによって）事前に設定される送信用無線リソースプールの使用を開始したときに、タイマを起動することができる。

時間長を直接示す代わりに、またはこれに加えて、端末がこのリソースをそれ以上使用することを停止させる特定の条件／イベントを指定することよって、事前に設定される送信用無線リソースプールが使用可能である時間を「間接的に」制限することができる。例えば、事前に設定される送信用無線リソースプールに関連付けられる指示として、これらのリソースの使用を望む端末は、その端末がアイドル状態を維持してこのようなリソースを無制限に使用することを回避するため、基地局との無線接続の確立をさらに試みなければならないという指示を、システム情報ブロードキャストに含めることができる。この場合、端末には、接続が確立されて基地局が専用無線リソースを端末に割り当てるまでの間のみ（図１８の期間０＋Ａ＋Ｂ＋Ｃを参照）、その事前に設定される送信用無線リソースプールからリソースを使用することが許可され、専用無線リソースが割り当てられた後の直接通信送信には、代わりにその専用無線リソースが使用される。または、接続を確立することができない、あるいは接続が拒否される場合、その確立の失敗について端末に通知されるまでの間のみ（図１９の期間０＋Ａを参照）、一時的な送信用無線リソースプールからリソースを使用することが端末に許可される。または、その時点において基地局が、端末との接続は確立するが、端末が直接通信送信を実行することを許可しないことがある（図１８の期間０＋Ａ＋Ｂを参照）。さらには、基地局によって端末に割り当てられた専用無線リソースを端末が実際に使用するまでにかかる時間が長くなりうることを考慮して、さらなる代替方式では、端末が（基地局との無線接続を確立し、直接通信送信用の専用無線リソースを基地局から受信した後）、基地局によって端末に割り当てられたこれらの専用無線リソースを使用してスケジューリング割当て（ＳＡ）またはデータの直接通信送信を実際に実行する時点まで（図１８の期間０＋Ａ＋Ｂ＋Ｃ＋Ｄを参照）、事前に設定される送信用無線リソースプールが使用可能である時間を延長することができる。

接続を確立させる実際の指示は、例えば、具体的な時間長であって、その時間内に端末が接続の確立を（少なくとも）開始する（例えばシステム情報ブロードキャストを受信した直後、または事前に設定される送信用無線リソースプールの使用を開始した直後に開始する）必要のある時間長を示すことができる。さらに別のオプションとして、直接通信送信用に、事前に設定される送信用無線リソースプールからの無線リソースを使用することが許可される前に、端末が接続の確立を開始するように要求する。この目的においては、端末は、一例としてランダムアクセス手順のプリアンブルを送信することによって、基地局との接続の確立を開始するものと理解することができる。

事前に設定される送信用無線リソースプールは、実際の物理無線リソース（すなわち時間および周波数）を定義することができ、オプションとして、物理無線リソースに関連付けられる特定の送信フォーマットまたは送信電力も定義することができる。さらに、端末がカバレッジ内であり、事前に設定される送信用無線リソースプールを直接通信送信用に使用するとき、それらの送信の電力を基地局によって（通常の方法で）制御することができる。

ここまで、第２の態様のいくつかの異なる実装形態について説明してきた。以下では、第２の態様およびその実装形態の背後の原理を、ＬＴＥシステム（背景技術のセクションで説明したＬＴＥシステムなど）に例示的に適用する。

第２の態様に関連して上述したいくつかの実装形態によると、カバレッジ内であるときに事前に設定される送信用無線リソースプールの使用を許可する／許可しないため、および／または、このリソースの使用を設定するため、基地局からのシステム情報ブロードキャストを修正する。

第１の態様において説明したように、３ＧＰＰによる現在の標準化では、ＰｒｏＳｅ直接通信および直接発見に関連するいくつかの情報を、ＳＩＢ１８を使用して含めることが考慮されており、ＳＩＢ１８は、上述したフラグや設定情報を伝えることができる。当然ながら、この第２の態様の目的において、任意の別のタイプのシステム情報ブロックを使用してこれらの情報を伝えることができることに留意されたい。以下では、極めて具体的な例を示す。設定および設定変数には具体的な名前が付けられており（すなわち、usePreconfigResInCoverage、allowedTime、timeToInitiateRRCConnEst）、これらの変数は具体的に設定されている（すなわち、ｍｓ１００、ｍｓ２００、ｍｓ３００など、ｍｓ０１、ｍｓ０５など）。この場合も、この第２の態様の目的において、フィールドに対して任意の別の名前を選ぶことができ、変数の実際の値は、異なる値とすることができることに留意されたい。

第２の態様において、従来技術と比較してこの例示的なシステム情報ブロックタイプ１８の情報エレメントに導入された重要な変更箇所は、容易に認識できるように太字とし下線を引いてある。

上の表から明らかであるように、設定情報のフィールド「usePreconfigResInCoverage」はオプションであり、したがってシステム情報ブロードキャストの中にこのフィールドが存在しているときには、ＵＥは、カバレッジ内であるときに、対応する事前に設定される送信用無線リソースプール（モード２のリソース）が利用可能であることを認識することができる。逆に、このフィールドが存在しないときには、ＵＥは、対応する事前に設定される送信用無線リソースプールがそのセル内で利用可能ではないことを認識する。

設定変数「allowedTime」および「timeToInitiateRRCConnEst」は、それ自体は第１の態様においてすでに説明したものであり、この第２の態様においても同様に定義される。上の例から明らかであるように、これらの設定変数は同時に定義することもでき（ｅＮＢがそのように決定した場合）、これにより、事前に設定されるカバレッジ内送信用無線リソースプールが使用可能である時間長を直接的および／または間接的に制限することができる。したがって、この特定の例においては、設定情報の一部は変数「allowedTime」として実施されており、例示的な時間の値は、上に示したように１００ｍｓ、２００ｍｓなどであり、したがって時間長を直接制限する。端末は、変数「allowedTime」によって示される値を読み取ることによって、システム情報ブロードキャストを受信した後（または端末が直接通信を実行するために一時的な送信用無線リソースプールからのリソースの使用を開始した後）、事前に設定される送信用無線リソースプールが使用可能である時間長を求めることができる。ＵＥは、対応するタイマを設定、起動、および監視することができる。

同様に、一時的な送信用無線リソースプール（すなわちcommTxPoolTemp）の使用を、後から説明するように異なる終了条件に基づいて間接的に制限するため、設定変数「timeToInitiateRRCConnEst」を含めることができる。この設定変数timeToInitiateRRCConnEstを使用することによって、上に示したように例示的な時間である１ｍｓまたは５ｍｓなどの間にｅＮＢとのＲＲＣ接続の確立を試みるようにＵＥに指示される。ＵＥのさまざまな挙動に応じて、例えば、ＲＲＣ接続が確立されてｅＮＢが専用無線リソースを端末に割り当てるまで、または、ＲＲＣ接続の確立に失敗したことをＵＥが認識するまで、または、セル内での直接通信の実行が許可されないことをｅＮＢがＵＥに通知するまで、または、ｅＮＢによってＵＥに割り当てられた専用リソースを使用してスケジューリング割当て（ＳＡ）またはデータの直接通信を実際に実行するまで、ＵＥに、事前に設定される送信用無線リソースプールのリソースの使用を許可することができる。

さらには、この第２の実施形態は、第１の実施形態とは異なる単独の解決策として説明したが、一般的には、この第２の実施形態を第１の実施形態と組み合わせることができる。

［第３の実施形態］
本発明者は、Ｄ２Ｄ通信および現在の発展形態に関連してさらなる問題点を認識した。より詳細には、さまざまなシナリオにおいてＵＥがさまざまな期間に渡りＤ２Ｄ通信の実行を抑制されることに関する上述した問題とは別に、もう１つの問題は、状態３カバレッジ外（ＯＯＣ）ＵＥと状態４カバレッジ外（ＯＯＣ）ＵＥに関連する。具体的には、特定のＵＥが、自身が状態３（ＣＰ ＵＥ中継）にあるのか状態４にあるのかを認識する方法がまだ明確ではない。このことはさらなる問題につながり、ＵＥは、Ｄ２Ｄ通信を実行するために使用するべきリソースおよび送信電力が明らかではない。

図１１と、背景技術のセクションの対応する説明箇所には、ＵＥがとりうる４つの一般的な状態について説明してある。これらの状態は、次のように要約される。
状態１： セルのカバレッジ内（ＩＣ）（セルの中央に極めて近い）
状態２： セルのカバレッジ内（ＩＣ）（セルの周縁部）
状態３： セルのカバレッジ外（セルのすぐ外側）。このようなＵＥは、衝突するリソースにおいて高い送信電力で送信する「ならば」、何らかのＷＡＮ干渉を発生させうる。
状態４： セルの「真の」カバレッジ外。たとえ衝突するリソースにおいて高い送信電力で送信しても、いかなる種類のＷＡＮ干渉も発生させることはない。

明らかに、状態３および状態４のいずれにおいてもＵＥはセルのカバレッジ外であるが、ＵＥが状態３と状態４を区別する方法は不明確である。なぜなら、ＵＥは、自身がセルのカバレッジ内ではない（すなわちいかなるＷＡＮセルにもキャンプオンしていない）ことを認識するのみであるためである。

以下の解決策が可能である。

ＵＥは、ＰＤ２ＤＳＣＨを受信した場合、自身が状態３であるとみなし、特定の事前に定義された（または設定可能な）時間に渡りＰＤ２ＤＳＣＨを受信しない場合、ＵＥは自身を状態４であるとみなす。ＰＤ２ＤＳＣＨは、背景技術のセクションで説明したように、ｅＮＢによって何基かのカバレッジ内（ＩＣ）ＵＥを介してＯＯＣ（カバレッジ外）ＵＥに送られる物理レイヤ情報である（カバレッジ内（ＩＣ）ＵＥはＰＤ２ＤＳＣＨを転送する）。ＰＤ２ＤＳＣＨは、Ｄ２Ｄ通信用のいくらかのリソースをシグナリングする。ＯＯＣ（カバレッジ外）ＵＥによって受信された場合、Ｄ２Ｄ通信用にＰＤ２ＤＳＣＨにおいて受信されたリソースは、ＯＯＣ（カバレッジ外）ＵＥに利用可能である事前に設定されるモード２のリソースよりも優先される。これは有利であり、なぜならこのような方策をとらない場合、これらのＵＥは自身を状態４にあるとみなし、矛盾するリソースにおいて高い送信電力で送信することがあり、事前に設定されるモード２のリソースを使用することによって何らかのＷＡＮ干渉が発生しうる。

状態３のＵＥは、ＰＤ２ＤＳＣＨまたはＤ２ＤＳＳ（Ｄ２Ｄ同期信号）の受信が、事前に定義された期間に渡り停止したとき、自身を再び状態４のＵＥとみなす。

このようにＵＥが状態３と状態４を区別する方法を指定することによって、ＷＡＮ通信との何らの問題（干渉）も引き起こされないように、Ｄ２Ｄ通信を実行するのにＵＥが使用するべきリソースおよび送信電力を効率的に選択／計算することができる。

なお、上に説明した第３の実施形態は、前述した第１の実施形態および／または第２の実施形態と組み合わせることができることに留意されたい。

［第４の実施形態］
Ｄ２Ｄ通信に関して認識される別の問題として、現在の標準化では、どのＵＥがＰＤ２ＤＳＣＨをカバレッジ外（ＯＯＣ）ＵＥに転送する役割を担うかが不明確である。

以下の代替解決策が可能である。以下の解決策を組み合わせることも可能である。

一般的には、十分にセルのカバレッジ内であり（例えばサービングセルのＲＳＲＰおよびＲＳＲＱの測定値が良好）、ただしセルの中央付近ではないＵＥは、ＰＤ２ＤＳＣＨを転送するうえでの良好な候補であり得る。具体的には、特定の無線受信値が事前に定義されたしきい値の間である（例：ＲＳＲＰ（基準信号受信電力）／ＲＳＲＱ（基準信号受信品質）の測定値が特定のしきい値「ｘ」としきい値「ｙ」との間である）ＵＥである。このような場合、しきい値ｘおよびしきい値ｙがＰＤ２ＤＳＣＨの内容と一緒にブロードキャストされる。

ＰＤ２ＤＳＣＨを転送する別の可能な候補は、Ｄ２ＤＳＳを送信／転送するＵＥである。ＰＤ２ＤＳＣＨの内容はブロードキャストされる。

別の可能な解決策は、ＰＤ２ＤＳＣＨを転送するように、ネットワークが特定のＵＥに専用シグナリングにおいて明示的に要求することである。ＰＤ２ＤＳＣＨの内容は、ブロードキャストされる、または専用シグナリングによってＵＥにシグナリングされる。

上の解決策の１つの可能な組合せは、Ｄ２ＤＳＳをすでに転送しており、かつ十分にセルのカバレッジ内である（すなわちＲＳＲＰまたはＲＳＲＱが対応するしきい値の間である）ＵＥである。

なお、第４の実施形態は、第１の実施形態、第２の実施形態、および第３の実施形態のうちのいずれかと一緒に、またはこれらの任意の組合せと一緒に、使用できることに留意されたい。

［第５の実施形態］
Ｄ２Ｄ通信に関して認識されるさらに別の問題は、Ｄ２Ｄ通信における受信／送信動作に関連する。背景技術のセクションで説明したように、Ｄ２Ｄ通信の送信動作は、リソース割当てモードに応じてわずかに異なる。モード１のＤ２Ｄ通信の場合、ｅＮＢがＤ２Ｄグラント（すなわちＤ２Ｄ−ＲＮＴＩによってスクランブルされた（Ｅ）ＰＤＣＣＨ）を、Ｄ２Ｄ送信側ＵＥに発行し、このＤ２Ｄグラントは、スケジューリング割当て（ＳＡ）の送信用のリソースのみならず、データ（ＰｒｏＳｅ／Ｄ２Ｄデータ）用のリソースも割り当てる。より詳細には、このＤ２Ｄグラントは、少なくとも、スケジューリング割当て（ＳＡ）リソースのインデックス（ＳＡリソースインデックス）（スケジューリング割当て（ＳＡ）を送信するのにＤ２Ｄ送信側ＵＥによって使用される、ＳＡリソースプール内の時間／周波数リソースを指す）と、Ｔ−ＲＰＴインデックスフィールドおよびデータＲＢ割当てフィールド（基本的にはＤ２Ｄデータ送信用の時間／周波数リソースを示す）とを含む。Ｔ−ＲＰＴインデックスフィールドは、すべての利用可能なＴ−ＲＰＴパターンをリストしたテーブル（このテーブルは例えば１２８個のエントリを含む）内の１つのエントリを参照する。送信の時間リソースパターン（Ｔ−ＲＰＴパターン）は、Ｄ２Ｄデータリソースプール内のＤ２Ｄデータ送信の時間リソースパターンを定義する。

Ｄ２Ｄ送信側ＵＥは、ｅＮＢからＤ２Ｄグラントを受信すると、スケジューリング割当て（ＳＡ）メッセージの送信または再送信に使用するべきサブフレームおよび周波数リソースをＳＡリソースプール内で求める目的で、ＳＡリソースインデックスを使用する。さらに、Ｄ２Ｄ送信側ＵＥは、Ｄ２ＤデータＰＤＵの送信に使用するべきサブフレーム（および場合によっては、Ｄ２Ｄグラント内で伝えられた何らかの別の情報に基づく周波数リソース）を求める目的で、少なくとも、Ｄ２Ｄグラントの中で受信したＴ−ＲＰＴインデックス情報を使用する。Ｄ２ＤデータＰＤＵの送信用のサブフレームを導くための関数は、モード１のＤ２Ｄ送信とモード２のＤ２Ｄ送信とで異なる。モード２のＤ２Ｄ送信の場合、Ｄ２Ｄ送信側ＵＥは、リソースプールのビットマップの中で１として表されるサブフレームに、Ｔ−ＲＰＴパターンを適用する。基本的にＤ２Ｄ送信側ＵＥは、モード２のＤ２Ｄデータ送信用リソースプールに従ってモード２送信に使用可能なＤ２Ｄサブフレームとして定義されているサブフレームに、Ｔ−ＲＰＴパターンを適用する。一例を図２２に示してある。

送信リソースプールのビットマップの中の１は、いわゆるＤ２Ｄサブフレーム（すなわちモード２のＤ２Ｄ送信用に予約されたサブフレーム）を表す。これらのＤ２ＤサブフレームにＴ−ＲＰＴパターンが適用される。図２２において理解できるように、対応するＴ−ＲＰＴエントリが１であるＤ２Ｄサブフレーム（リソースプールのビットマップのエントリとＴ−ＲＰＴビットマップのエントリの両方が１であるサブフレーム）が、Ｄ２ＤデータＰＤＵの送信に使用される。背景技術においてすでに説明したように、モード２のリソース割当ての場合、Ｄ２Ｄ送信側ＵＥは、Ｔ−ＲＰＴパターンを自律的に選択してそれをスケジューリング割当て（ＳＡ）の中でシグナリングする。したがってＤ２Ｄ受信側ＵＥは、（スケジューリング割当て（ＳＡ）を正常に復号した後、）受信されたＴ−ＲＰＴパターンに基づいて、Ｄ２Ｄデータ送信の時間／周波数リソースを求めることができる。モード２のＤ２Ｄ送信の場合、Ｄ２Ｄグラントは存在しない。

モード１のＤ２Ｄ送信の場合、すでに上述したように、ｅＮＢが、Ｄ２Ｄ送信に使用されるＴ−ＲＰＴパターンを割り当てて、それをＤ２ＤグラントによってＤ２Ｄ送信側ＵＥにシグナリングする。

モード１の場合にはＤ２Ｄ送信用のリソースプールが存在しないことを考慮して、Ｔ−ＲＰＴのパラメータが物理アップリンクサブフレームに直接適用される。なぜなら、すべてのアップリンクサブフレームをＤ２Ｄサブフレームとすることができるためである。例示的な一実施形態によると、Ｄ２Ｄ送信側ＵＥは、Ｄ２Ｄグラントの中のＴ−ＲＰＴパターンインデックスによって示されるＴ−ＲＰＴパターンを、リソースプールのビットマップ内のすべてのサブフレーム（すなわちビットマップのエントリが１であるサブフレームおよび０であるサブフレーム）に適用する。モード１のＤ２Ｄデータ送信の場合の例を、図２１に示してある。

図から理解できるように、この場合も、モード２のＤ２Ｄ送信を説明した例示的なシナリオにおいて使用されたものと同じＴ−ＲＰＴパターンを例として使用する。しかしながらモード１の場合、Ｔ−ＲＰＴパターンはリソースプール内のすべての（アップリンク）サブフレームに適用される。モード１の場合、データ送信用のリソースプールが定義／設定されないため、Ｄ２Ｄ送信側ＵＥは、Ｔ−ＲＰＴパターンを、モード２のデータ送信用リソースプールあるいはデータ受信用リソースプールのいずれかに適用することができる。重要なことは、モード１の場合にＴ−ＲＰＴパターンを適用するときの何らかの基準サブフレーム、すなわち開始サブフレームが必要であることである。これに代えて、Ｄ２Ｄデータの最初の送信とスケジューリング割当て（ＳＡ）との間の何らかのタイミング関係を事前に定義することができる。例えば、モード１でのＤ２Ｄデータの最初の送信機会（すなわちこれはＴ−ＲＰＴパターンの開始サブフレームである）は、スケジューリング割当て（ＳＡ）メッセージの前回の送信からｘ ｍｓ後に発生する。

Ｄ２Ｄ送信側ＵＥによってモード１のＤ２Ｄデータ送信が使用されるかモード２のＤ２Ｄデータ送信が使用されるかに応じて、Ｔ−ＲＰＴパターンの使用方法が異なる。したがってＤ２Ｄ受信側ＵＥは、モード１のＤ２Ｄデータ送信とモード２のＤ２Ｄデータ送信とを区別できる必要がある。より詳細には、Ｄ２Ｄ受信側ＵＥは、ＳＡリソースプール内でスケジューリング割当て（ＳＡ）を受信するとき、Ｔ−ＲＰＴパターンを正しく解釈することができるように（すなわち対応するＤ２Ｄデータ送信の正しい時間／周波数リソースを求める目的で）、そのスケジューリング割当て（ＳＡ）がモード１のＤ２Ｄデータ送信によって送信されたのかモード２のＤ２Ｄデータ送信によって送信されたのかを認識できる必要がある。別の例示的な実施形態によると、スケジューリング割当て（ＳＡ）メッセージには、Ｄ２Ｄ通信に使用されたリソース割当てモードの明示的なインジケータが含まれる。すなわち、スケジューリング割当て（ＳＡ）メッセージの中の新規のフィールドが、Ｄ２Ｄデータ送信にモード１が使用されたかモード２が使用されたかを示す。

代替の解決策として、送信／リソース割当てモードは、スケジューリング割当て（ＳＡ）メッセージの中でシグナリングされるＴ−ＲＰＴパターンによって暗黙的に示される。事前に設定されるかまたはテーブル形式で与えられる利用可能なＴ−ＲＰＴパターンが２つのセットに分割され、Ｔ−ＲＰＴパターンの一方のセットがモード１の送信に使用され、Ｔ−ＲＰＴパターンの２番目のセットがモード２に使用される。例えば、１２８個の異なるＴ−ＲＰＴパターンを想定すると、パターン０〜６３をモード１のＤ２Ｄ送信に使用することができ、インデックス６４〜１２７のＴ−ＲＰＴパターンはモード２用に予約される。Ｄ２Ｄ受信側ＵＥは、スケジューリング割当て（ＳＡ）の中の受信されたＴ−ＲＰＴインデックスに基づいて、送信側ＵＥがリソース割当てモード１を使用しているのかモード２を使用しているかを認識することができる。

さらに別の例示的な実施形態によるさらなる代替の解決策として、リソース割当て／送信モードを、スケジューリング割当て（ＳＡ）に含まれているＴＡフィールドの値から導くことができる。モード１の送信とモード２の送信では、異なる送信タイミングを使用するため、受信側ＵＥは、モード１の送信とモード２の送信とを、ＴＡフィールドの値に基づいて区別することができる。例えば、モード２の送信の場合のＴＡ値はつねに０であるのに対して、モード１ではＴＡ値はＵＥのＮＴＡ値に設定される（すなわちＵＥは、モード１のＤ２Ｄ送信においてはレガシーアップリンク送信タイミングを使用する）。

さらなる代替策として、リソース割当て／送信モードを、スケジューリング割当て（ＳＡ）メッセージの送信に使用される周波数リソースによって暗黙的に示すことができる。例えば、モード２の送信側ＵＥによって送信されるスケジューリング割当て（ＳＡ）メッセージと、モード１の送信側ＵＥによって送信されるスケジューリング割当て（ＳＡ）は、使用される周波数リソースが異なる。より詳細には、モード２の場合のＳＡ送信リソースプールは、スケジューリング割当て（ＳＡ）の送信用にｅＮＢによって割り当てられるリソース（モード１）とは異なる。

本発明のさらなる例示的な実施形態によるさらに別の代替の解決策は、モード１の送信とモード２の送信とを区別する必要がないように、Ｔ−ＲＰＴパターンのビットマップの長さを定義することである。より詳細には、Ｔ−ＲＰＴパターンのビットマップの長さは、Ｔ−ＲＰＴパターンが適用されるリソースプールのビットマップの長さと同じであるべきである。上に説明した図２１および図２２に示した例をとると、Ｔ−ＲＰＴパターンの長さは３０ビットであるべきである。

モード１およびモード２の両方のＴ−ＲＰＴパターンは同じ開始サブフレーム（例えばリソースプールの開始サブフレーム）に適用されるため、Ｄ２Ｄ受信側ＵＥは、モード２の送信とモード１の送信とを区別する必要がない。

なお、第５の実施形態は、第１の実施形態、第２の実施形態、第３の実施形態、および第４の実施形態のうちのいずれかと一緒に、またはこれらの任意の組合せと一緒に、使用できることに留意されたい。

［ハードウェアおよびソフトウェアによる本開示の実施］
別の例示的な実施形態は、上述したさまざまな実施形態を、ハードウェアおよびソフトウェアを使用して実施することに関する。これに関連して、ユーザ機器（移動端末）およびｅＮｏｄｅＢ（基地局）を提供する。ユーザ端末および基地局は、本明細書に記載されている方法を実行するようにされている。

本発明のさまざまな実施形態は、コンピューティングデバイス（プロセッサ）を使用して実施または実行され得るものとさらに認識される。コンピューティングデバイスまたはプロセッサは、例えば、汎用プロセッサ、デジタル信号プロセッサ（ＤＳＰ：Digital Signal Processor）、特定用途向け集積回路（ＡＳＩＣ：Application Specific Integrated Circuit）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ：Field Programmable Gate Arrary）、または、その他プログラマブルロジックデバイスなどである。本発明のさまざまな実施形態は、これらのデバイスの組合せによっても実行または具体化され得る。

さらに、本発明のさまざまな実施形態は、ソフトウェアモジュールによっても実施され得る。これらのソフトウェアモジュールは、プロセッサによって実行され、または、ハードウェアにおいて直接実行される。また、ソフトウェアモジュールとハードウェア実装の組合せも可能である。ソフトウェアモジュールは、任意の種類のコンピュータ可読記憶媒体、例えば、ＲＡＭ又はＥＰＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、レジスタ、ハードディスク、ＣＤ−ＲＯＭ、ＤＶＤなどに格納され得る。

さらには、複数の異なる実施形態の個々の特徴は、個別に、または任意の組合せにおいて、別の実施形態の主題とすることができることに留意されたい。

具体的な実施形態において示した本開示には、さまざまな変更もしくは修正またはその両方を行うことができることが、当業者には理解されるであろう。したがって、本開示の実施形態は、あらゆる点において例示的であり、本発明を制限するものではないものとみなされたい。

Claims (5)

1. 通信システムにおいて直接リンク接続を通じて受信側端末への直接通信送信を実行するための無線リソースを、送信側端末に割り当てる基地局の処理を制御する集積回路であって、前記処理は、
   システム情報ブロードキャストを送信し、
   前記システム情報ブロードキャストが、
   − 前記システム情報ブロードキャストを受信する送信側端末によって、直接リンク接続を通じて受信側端末への直接通信送信を実行するために使用可能な無線リソースを示す、アイドル状態送信用無線リソースプールまたは一時的な送信用無線リソースプールと、
   − 前記送信側端末が、前記一時的な送信用無線リソースプールを使用する前に前記基地局との無線接続確立手順を開始することが要求されること、
   を含む、前記一時的な送信用無線リソースプールに関する設定情報と、
   に関する情報、を含み、
   前記アイドル状態送信用無線リソースプールは、前記送信側端末がアイドル状態にあるときのみ使用可能であり、
   前記システム情報ブロードキャストが前記アイドル状態送信用無線リソースプールに関する設定情報を含み、かつ、前記送信側端末がアイドル状態である場合に、前記アイドル状態送信用無線リソースプールを無線リソースとして前記送信側端末により選択され、
   前記システム情報ブロードキャストが前記アイドル状態送信用無線リソースプールに関する設定情報を含まず、かつ、前記一時的な無線リソースプールに関する設定情報を含む場合に、前記一時的な送信用無線リソースプールが前記送信側端末により無線リソースとして選択され、
   前記一時的な送信用無線リソースプールが無線リソースとして選択された場合に、前記送信側端末と前記基地局との無線接続確立手順が開始された後、前記受信側端末へのスケジューリング割当てまたはデータのいずれかの直接通信送信が、前記送信側端末により、前記選択された無線リソースを使用して実行される、
   集積回路。
2. 前記送信側端末が、ランダムアクセス手順のプリアンブルを送信することによって、前記基地局との前記無線接続確立手順を開始する、
   請求項１に記載の集積回路。
3. 前記一時的な送信用無線リソースプールが、アイドル状態にある送信側端末および接続状態にある送信側端末によって使用可能である、
   請求項１又は２に記載の集積回路。
4. 前記一時的な送信用無線リソースプールが、次のいずれかまでのみ、すなわち、
   ・ 直接通信送信を実行するために使用可能である専用無線リソースが、前記基地局によって前記送信側端末に割り当てられる、
   ・ 前記送信側端末が、前記基地局によって前記送信側端末に割り当てられた専用無線リソースを使用して直接通信送信を最初に実行する、
   ・ 前記送信側端末によって開始された無線接続確立手順が失敗する、
   までのみ、前記送信側端末によって使用可能であり、
   前記専用無線リソースが、前記基地局によって前記送信側端末に割り当てられる、割り当てられた送信用無線リソースプール、から選択可能な無線リソースである、または、前記専用無線リソースが、直接通信送信用に前記送信側端末からのリソース要求に応えて前記基地局によって前記送信側端末に割り当てられる無線リソースである、
   請求項１から請求項３のいずれかに記載の集積回路。
5. 前記一時的な送信用無線リソースプールが、直接リンク接続を通じて受信側端末へのスケジューリング割当ての直接通信送信を実行するために使用可能である無線リソースの第１のセット、を示し、前記スケジューリング割当てが、その後に前記直接リンク接続を通じて前記受信側端末へのデータの直接通信送信を実行するために前記送信側端末によって使用される無線リソース、を示す、または
   前記一時的な送信用無線リソースプールが、直接リンク接続を通じて受信側端末へのデータの直接通信送信を実行するために使用可能である無線リソースの第２のセット、を示す、
   請求項１から請求項４のいずれかに記載の集積回路。