特許 6386066 Ｄ２Ｄ発見のためのペイロードサイズの区別のための装置、システム、及び方法

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

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

(11)【特許番号】6386066

(24)【登録日】2018年8月17日

(45)【発行日】2018年9月5日

(54)【発明の名称】Ｄ２Ｄ発見のためのペイロードサイズの区別のための装置、システム、及び方法

(51)【国際特許分類】

   H04W 28/06 20090101AFI20180827BHJP

   H04W 8/00 20090101ALI20180827BHJP

   H04W 92/18 20090101ALI20180827BHJP

【ＦＩ】

   H04W28/06

   H04W8/00 110

   H04W92/18

【請求項の数】12

【全頁数】19

(21)【出願番号】特願2016-553584(P2016-553584)

(86)(22)【出願日】2015年3月13日

(65)【公表番号】特表2017-506475(P2017-506475A)

(43)【公表日】2017年3月2日

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

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

(87)【国際公開日】20151001

【審査請求日】2016年8月22日

(31)【優先権主張番号】61/969,781

(32)【優先日】2014年3月24日

(33)【優先権主張国】US

(31)【優先権主張番号】14/570,457

(32)【優先日】2014年12月15日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】514045555

【氏名又は名称】インテル アイピー コーポレイション

(74)【代理人】

【識別番号】100107766

【弁理士】

【氏名又は名称】伊東 忠重

(74)【代理人】

【識別番号】100070150

【弁理士】

【氏名又は名称】伊東 忠彦

(74)【代理人】

【識別番号】100091214

【弁理士】

【氏名又は名称】大貫 進介

(72)【発明者】

【氏名】シオーン，ガーン

(72)【発明者】

【氏名】チャッテルジー，デブディープ

【審査官】 松本 光平

(56)【参考文献】

【文献】 米国特許出願公開第２０１４／００１０１７９（ＵＳ，Ａ１）

【文献】 Ericsson，D2D discovery resource allocation，3GPP TSG-RAN WG2 #85bis R2-141258，3GPP，２０１４年 ３月２２日，第１−４頁，ＵＲＬ，://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_85bis/Docs/R2-141258.zip

【文献】 Intel Corporation，Link-level Analysis of LTE-based D2D Discovery Design，3GPP TSG RAN WG1 Meeting #74 R1-132943，3GPP，２０１３年 ８月１０日，第１−２頁，ＵＲＬ，http://www.3gpp.org/ftp/tsg_ran/WG1_RL1/TSGR1_74/Docs/R1-132943.zip

【文献】 SA2，LS reply on discovery message size，3GPP TSG-SA2 Meeting #101 S2-140568，3GPP，２０１４年 １月２４日，第１−２頁，ＵＲＬ，http://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_101_Taipei/Docs/S2-140568.zip

【文献】 Research In Motion, UK Limited，PDCCH Enhancement in Carrier Aggregation，R1-113962，２０１１年１１月 ８日，第１−３頁，ＵＲＬ，http://www.3gpp.org/ftp/tsg_ran/WG1_RL1/TSGR1_67/Docs/R1-113962.zip

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

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

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

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

ＳＡ ＷＧ１−４

ＣＴ ＷＧ１、４

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

【請求項1】

ユーザ機器（ＵＥ）であって、回路を有し、前記回路は、
第２のＵＥと装置対装置（Ｄ２Ｄ）直接発見リンクを確立するために、ｅＮｏｄｅＢへＤ２Ｄ発見要求を送信し、前記Ｄ２Ｄ発見要求は、Ｄ２Ｄサービスタイプに関連付けられ、
前記Ｄ２Ｄ直接発見リンクに関連するリソース割り当て情報を前記ｅＮｏｄｅＢから受信し、前記の情報は、共通又は専用無線リソース制御（ＲＲＣ）シグナリングを介して受信され、
前記リソース割り当て情報により前記ＵＥに割り当てられたリソースを用い、前記第２のＵＥへ前記Ｄ２Ｄ直接発見リンクを介して、Ｄ２Ｄ発見メッセージを送信し、前記前記Ｄ２Ｄ発見メッセージは、データペイロードを有する少なくとも１つのデータフレームを含み、前記データペイロードのサイズは前記Ｄ２Ｄサービスタイプに基づき決定され、
物理レイヤ（ＰＨＹ）を更に有し、前記ＰＨＹは、
前記のデータペイロードサイズを示すために、前記Ｄ２Ｄ発見メッセージの少なくとも１つのデータフレームに関連するデータを構成し、
前記データペイロードのための前記Ｄ２Ｄサービスタイプに関連する巡回冗長検査（ＣＲＣ）コードを選択し、又は、データペイロードマスクのための前記Ｄ２Ｄサービスタイプに関連する前記ＣＲＣコードは、前記Ｄ２Ｄサービスタイプに関連するデータマスク値によりマスクされるＣＲＣを有する、
ＵＥ。

【請求項2】

前記Ｄ２Ｄサービスタイプは、公衆安全（ＰＳ）サービス又は非ＰＳサービスのうちの少なくとも１つを有する、請求項１に記載のＵＥ。

【請求項3】

前記ＰＳサービスのためのデータペイロードサイズは、非ＰＳサービスのデータペイロードサイズより大きなサイズを有する、請求項２に記載のＵＥ。

【請求項4】

前記ＰＨＹは、前記Ｄ２Ｄサービスタイプと共に使用するために前記ｅＮｏｄｅＢにより排他的に割り当てられるリソースブロックを要求する、請求項１に記載のＵＥ。

【請求項5】

前記回路は、ＰＵＳＣＨ（physical uplink shared channel）を介して前記ｅＮｏｄｅＢへ前記Ｄ２Ｄ発見要求を送信するよう更に構成される、請求項１に記載のＵＥ。

【請求項6】

前記回路は、前記Ｄ２Ｄ発見要求及び前記Ｄ２Ｄ発見メッセージを送信するために、１又は複数のアンテナを更に有する、請求項１に記載のＵＥ。

【請求項7】

ユーザ機器（ＵＥ）と装置対装置（Ｄ２Ｄ）直接発見リンクを確立するために、ｅＮｏｄｅＢへＤ２Ｄ発見要求を送信するステップであって、前記Ｄ２Ｄ発見要求は、公衆安全（ＰＳ）サービス又は非ＰＳサービスのうちの少なくとも１つを有するＤ２Ｄサービスタイプに関連付けられる、ステップと、
前記Ｄ２Ｄ直接発見リンクに関連するリソース割り当て情報を前記ｅＮｏｄｅＢから受信するステップであって、前記リソース割り当て情報は、ＵＥ固有又はＵＥ共通情報を有する、ステップと、
Ｄ２Ｄ発見メッセージを生成するステップであって、前記Ｄ２Ｄ発見メッセージは、データペイロードを有する少なくとも１つのデータフレームを含み、前記データペイロードのサイズは前記Ｄ２Ｄサービスタイプに基づき決定され、前記生成するステップは、
前記データペイロードサイズを示すよう構成される前記Ｄ２Ｄ発見メッセージの前記少なくとも１つのデータフレームに関連するデータを構成するステップと、
前記データペイロードについて、前記Ｄ２Ｄサービスタイプに関連する巡回冗長検査（ＣＲＣ）コードを選択するステップ、又は、前記Ｄ２Ｄサービスタイプに関連するデータマスク値により、前記データペイロードの前記ＣＲＣコードをマスクするステップ、
を有する、ステップと、
前記リソース割り当て情報により前記ＵＥに割り当てられたリソースを用いて前記Ｄ２Ｄ直接発見リンクを介し前記ＵＥへ前記Ｄ２Ｄ発見メッセージを送信するステップと、
を有する方法。

【請求項8】

コンピュータプログラムであって、コンピューティングシステムに動作を実行させ、前記動作は、
ユーザ機器（ＵＥ）と装置対装置（Ｄ２Ｄ）直接発見リンクを確立するために、ｅＮｏｄｅＢへＤ２Ｄ発見要求を送信するステップであって、前記Ｄ２Ｄ発見要求は、公衆安全（ＰＳ）サービス又は非ＰＳサービスのうちの少なくとも１つを有するＤ２Ｄサービスタイプに関連付けられる、ステップと、
前記Ｄ２Ｄ直接発見リンクに関連するリソース割り当て情報を前記ｅＮｏｄｅＢから受信するステップであって、前記リソース割り当て情報は、ＵＥ固有又はＵＥ共通情報を有する、ステップと、
Ｄ２Ｄ発見メッセージを生成するステップであって、前記Ｄ２Ｄ発見メッセージは、データペイロードを有する少なくとも１つのデータフレームを含み、前記データペイロードのサイズは前記Ｄ２Ｄサービスタイプに基づき決定され、
前記のデータペイロードサイズを示すよう構成される前記Ｄ２Ｄ発見メッセージの前記少なくとも１つのデータフレームに関連するデータを構成するステップと、
前記データペイロードについて、前記Ｄ２Ｄサービスタイプに関連する巡回冗長検査（ＣＲＣ）コードを選択するステップ、又は、前記Ｄ２Ｄサービスタイプに関連するデータマスク値により、前記データペイロードの前記ＣＲＣコードをマスクするステップ、
を有する、ステップと、
前記リソース割り当て情報により前記ＵＥに割り当てられたリソースを用いて前記Ｄ２Ｄ直接発見リンクを介し前記ＵＥへ前記Ｄ２Ｄ発見メッセージを送信するステップと、
を有する、コンピュータプログラム。

【請求項9】

前記動作は、
ＵＥ固有発見リソース割り当て手順の間に前記Ｄ２Ｄサービスタイプと共に使用するために、前記ｅＮｏｄｅＢにより排他的に割り当てられる発見リソースを要求するステップ、を更に有する、請求項８に記載のコンピュータプログラム。

【請求項10】

前記データペイロードサイズを示すために前記Ｄ２Ｄ発見メッセージの前記少なくとも１つのデータフレームに関連するデータを構成するステップは、第２のＤ２Ｄサービスタイプに関連するデータペイロードサイズのビット数に合致するよう前記データペイロードに１又は複数のゼロを付加するステップを有する、請求項８に記載のコンピュータプログラム。

【請求項11】

前記Ｄ２Ｄ発見要求は、ＰＵＳＣＨ（physical uplink shared channel）を介して前記ｅＮｏｄｅＢへ送信される、請求項８に記載のコンピュータプログラム。

【請求項12】

請求項８乃至１１のいずれか一項に記載のコンピュータプログラムを記録したコンピュータ可読記憶媒体。

【発明の詳細な説明】

【技術分野】

【0001】

［優先権の主張］
本願は、米国仮特許出願番号第６１／９６９，７８１号、２０１４年３月２４日出願の優先権の利益を主張する米国特許出願番号第１４，５７０，４５７号、２０１４年１２月１５日出願の優先権の利益を主張する。これら米国出願の各々は、ここで参照されることによりその全体が本願明細書に組み込まれる。

【0002】

［技術分野］
実施形態は、無線通信に関連する。幾つかの実施形態は、３ＧＰＰ ＬＴＥネットワークのようなセルラネットワークにおける、Ｄ２Ｄ（device−to−device、装置対装置）発見を含むＤ２Ｄ発見サービス及び発見サービスに関する。

【背景技術】

【0003】

無線モバイル装置又はユーザ機器（ＵＥ）は、３ＧＰＰ ＬＴＥ（Long Term Evolution）Ａｄｖａｎｃｅｄ Ｒｅｌｅａｓｅ１２（２０１４年３月）（「LTE−A Standard」）、ＩＥＥＥ８０２．１６標準、ＩＥＥＥ標準８０２．１６−２００９、２００９年３月２９日発行（「WiMAX」）、並びに３Ｇ、４Ｇ、５Ｇ及びそれ以降として設計される任意の他の無線プロトコルのような無線アクセス技術を用いて、互いに通信しても良い。幾つかのＵＥは、例えば、装置対装置（「Ｄ２Ｄ」）通信を用いて、他のＵＥと直接通信するよう構成され得る。Ｄ２Ｄ通信は、例えば、ＵＥが、互いの直接無線範囲にいがなら、互いに通信を開始するとき、使用されても良い。公衆安全（ＰＳ）サービス、非ＰＳサービス、等のような、Ｄ２Ｄ通信セッションのための異なるサービスタイプは、異なるデータ特性（例えば、データタイプ及びデータ構造）を利用し得る。

【図面の簡単な説明】

【0004】

【図1】幾つかの実施形態に従う、ネットワークの様々なコンポーネントを有する無線ネットワークのアーキテクチャを示す。

【図2】幾つかの実施形態に従う、ＬＴＥ（Long Term Evolution）ネットワークのコンポーネントのアーキテクチャを示す。

【図3】幾つかの実施形態に従う、ユーザ機器（ＵＥ）及びｅＮｏｄｅＢ（enhanced NodeB）のブロック図を示す。

【図4A】開示の実施形態に従う、装置対装置（Ｄ２Ｄ）サービスのために割り当てられるリソースブロック（ＲＢ）の図である。

【図4B】開示の実施形態に従う、装置対装置（Ｄ２Ｄ）サービスのために割り当てられるリソースブロック（ＲＢ）の図である。

【図5】開示の実施形態による、Ｄ２ＤサービスのためにＲＢを割り当てるフロー図を示す。

【図6A】開示の実施形態に従う、Ｄ２Ｄ送信のためのデータフレームの図である。

【図6B】開示の実施形態に従う、Ｄ２Ｄ送信のためのデータフレームの図である。

【図7】開示の態様に従う、機械可読媒体から命令をリードし、本願明細書で議論される方法のうちの任意の１又は複数を実行できる、幾つかの例示的な実施形態に従う機械のコンポーネントを示すブロック図である。

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

【0005】

以下の説明及び図面は、当業者が実施するのに十分に特定の実施形態を説明する。他の実施形態は、構造的、論理的、電子的、処理及び他の変化を組み込むことができる。幾つかの実施形態の部分及び特徴は、他の実施形態の部分及び特徴に含まれ又はそれらを置き換えることができる。請求の範囲に記載された実施形態は、該請求の範囲の全ての可能な等価物を含む。

【0006】

幾つかの実施形態では、本願明細書に記載されるモバイル装置又は他の装置は、パーソナルデジタルアシスタント（ＰＤＡ）、無線通信能力を備えるラップトップ若しくはポータブルコンピュータ、ウェブタブレット、無線電話機、スマートフォン、無線ヘッドセット、ページャ、インスタントメッセージング装置、デジタルカメラ、アクセスポイント、テレビジョン、医療機器（例えば、心拍モニタ、血圧モニタ、等）、又は無線で情報を受信し及び／又は送信できる他の装置のようなポータブル無線通信装置の部分であり得る。幾つかの実施形態では、モバイル装置又は他の装置は、３ＧＰＰ標準に従って動作するよう構成されるユーザ機器（ＵＥ）又はｅＮｏｄｅＢ（Evolved Node−B）であり得る。幾つかの実施形態では、モバイル装置又は他の装置は、ＩＥＥＥ８０２．１１又は他のＩＥＥＥ及び３ＧＰＰ標準を含む他のプロトコル又は標準に従い動作するよう構成され得る。幾つかの実施形態では、モバイル装置又は他の装置は、キーボード、ディスプレイ、不揮発性メモリポート、複数のアンテナ、グラフィックプロセッサ、アプリケーションプロセッサ、スピーカ、及び他のモバイル装置要素のうちの１又は複数を有し得る。ディスプレイは、タッチスクリーンを含むＬＣＤであり得る。

【0007】

図１は、幾つかの実施形態に従う、ネットワークの様々なコンポーネントを有する無線ネットワークのアーキテクチャを示す。システム１００は、ユーザ機器（ＵＥ）１０２及びＵＥ１０４を有するよう示される。ＵＥ１０２及び１０４は、スマートフォン（つまり、１又は複数のセルラネットワークに接続可能なハンドヘルド・タッチスクリーン・モバイルコンピューティング装置）として示されるが、パーソナルデジタルアシスタント（ＰＤＡ）、ページャ、ラップトップコンピュータ、デスクトップコンピュータ、等も含み得る。

【0008】

ＵＥ１０２及び１０４は、それぞれ接続１２０及び１２２を介して無線アクセスネットワーク（radio access network：ＲＡＮ）１０６にアクセスするよう構成される。接続１２０及び１２２の各々は、物理通信インタフェース又はレイヤを有する。本実施形態では、接続１２０及び１２２は、通信結合を有効にする無線インタフェースとして示され、ＧＳＭ（Global System for Mobile Communications）プロトコル、ＣＤＭＡ（code−division multiple access）ネットワークプロトコル、ＰＴＴ（Push−to−Talk）プロトコル、ＰＯＣ（PTT over Cellular）プロトコル、ＵＭＴＳ（Universal Mobile Telecommunications System）プロトコル、３ＧＰＰ ＬＴＥ（Long Term Evolution）プロトコル、等のようなセルラ通信プロトコルと整合し得る。

【0009】

ＲＡＮ１０６は、接続１２０及び１２２を有効にする１又は複数のアクセスポイントを含み得る。これらのアクセスポイント（以下に更に詳述する）は、アクセスノード、基地局（ＢＳ）、ＮｏｄｅＢ、ｅＮｏｄｅＢ（enhanced NodeB）、等として参照され、地上局（つまり、地上波アクセスポイント）又は衛星アクセスポイントを有し得る。ＲＡＮ１０６は、コアネットワーク１１０に通信可能に結合されるよう示される。コアネットワーク１１０は、ＵＥ１０２と１０４との間の回線交換呼をブリッジすることに加えて、インターネット１１２とのパケット交換データの交換を有効にするために使用され得る。幾つかの実施形態では、ＲＡＮ１０６は、Ｅ−ＵＴＲＡＮ（ＵＭＴＳ（Evolved Universal Mobile Telecommunications System） Terrestrial RAN）を有し、コアネットワーク１１０は、ＥＰＣ（Evolved Packet Core）ネットワークを有し得る。

【0010】

ＵＥ１０４は、接続１２４を介してアクセスポイント（ＡＰ）１０８にアクセスするよう構成されるよう示される。接続１２４は、ＩＥＥＥ８０２．１１に従う接続のようなローカル無線接続を有し得る。ここで、ＡＰ１０８は、ＷｉＦｉ（wireless fidelity）（登録商標）ルータを有し得る。本例では、ＡＰ１０８は、コアネットワーク１１０に接続することなく、インターネット１１２に接続されるよう示される。

【0011】

インターネット１１２は、アプリケーションサーバ１１６に通信可能に結合されるよう示される。アプリケーションサーバ１１６は、複数の構造的に分離したサーバとして実装され、又は単一のサーバに含まれ得る。アプリケーションサーバ１１６は、インターネット１１２及びコアネットワーク１１０の両方に接続されるとして示される。他の実施形態では、コアネットワーク１１０は、インターネット１１２を介してアプリケーションサーバ１１６に接続する。アプリケーションサーバ１１６は、コアネットワーク１１０及び／又はインターネット１１２を介してアプリケーションサーバ１１６に接続できるＵＥのために、１又は複数の通信サービス（例えば、ＶｏＩＰ（Voice−over−Internet Protocol）セッション、ＰＴＴ（Push−to−Talk）セッション、グループ通信セッション、ソーシャルネットワーキングサービス、等）をサポートするよう構成され得る。

【0012】

コアネットワーク１１０は、ＩＭＳ（ＩＰ（Internet Protocol） Multimedia Subsystem）１１４に通信可能に結合されるよう更に示される。ＩＭＳ１１４は、伝統的な電話、ファックス、電子メール、インターネットアクセス、ＶｏＩＰ（Voice over IP）、ＩＭ（instant messaging）、ビデオ会議セッション、及びＶｏＤ（video on demand）、等のようなパケット通信のためのＩＰの使用を可能にできる通信キャリアの統合ネットワークを有する。

【0013】

図２は、幾つかの実施形態に従う、ＬＴＥネットワークのコンポーネントのアーキテクチャを示す。本実施形態では、ＲＡＮ１０６は、Ｅ−ＵＴＲＡＮを有し、ＵＥ１０２及び１０４と通信するためにｅＮｏｄｅＢ２０２及び２０４（基地局として動作できる）を含むよう示される。ｅＮｏｄｅＢ２０２及び２０４は、マクロｅＮｏｄｅＢ、低電力（ＬＰ）ｅＮｏｄｅＢ、等のうちの任意のものであり得る。

【0014】

セルラネットワークで、低電力セルは、屋外信号が良好に到達しない屋内領域へカバレッジを拡張するために、又は鉄道の駅のような非常に濃密な電話使用を有する領域にネットワーク容量を追加するために、使用できる。ここで使用されるとき、用語「低電力（ＬＰ）ｅＮｏｄｅＢ」は、フェムトセル、ピコセル、又はマイクロセルのような狭いセル（つまり、マクロセルよりも狭い）を実装する任意の適切な比較的低い電力のｅＮｏｄｅＢを表す。フェムトセルｅＮｏｄｅＢは、標準的に、モバイルネットワークオペレータにより、その敷地又は企業顧客に、設けられる。フェムトセルは、標準的に、家庭用ゲートウェイ又は小さな大きさであり、通常、ユーザのブロードバンド回線に接続する。一旦接続されると、フェムトセルは、モバイルオペレータのモバイルネットワークに接続し、家庭用フェムトセルのために、標準的に３０〜５０メートルの範囲の追加カバレッジを提供する。したがって、ＬＰ ｅＮｏｄｅＢは、ＰＧＷ（ＰＤＮ（Packet Data Network） Gateway）を通じて結合されるので、フェムトセルｅＮｏｄｅＢであり得る。同様に、ピコセルは、建物内（例えば、オフィス、ショッピングモール、鉄道の駅、等）又はより最近では航空機内のような標準的に小さな領域をカバーする無線通信システムである。ピコセルｅＮｏｄｅＢは、通常、自身の基地局制御（ＢＳＣ）機能を通じてマクロｅＮｏｄｅＢのように、Ｘ２リンクを通じて別のｅＮｏｄｅＢに接続できる。したがって、ＬＰ ｅＮｏｄｅＢは、Ｘ２インタフェースを介してマクロｅＮｏｄｅＢに結合されるので、ピコセルｅＮｏｄｅＢを実装され得る。ピコセルｅＮｏｄｅＢ又は他のＬＰ ｅＮｏｄｅＢは、マクロｅＮｏｄｅＢの一部又は全部の機能を組み込むことができる。幾つかの例では、これは、アクセスポイント基地局又はエンタープライズフェムトセルとして参照され得る。

【0015】

ｅＮｏｄｅＢ２０２及び２０４は、無線インタフェースプロトコルを終端でき、ＵＥ１０２及び１０４の最初の連絡先であり得る。幾つかの実施形態では、ｅＮｏｄｅＢ２０２及び２０４のうちの任意のものは、無線ベアラ管理、動的無線リソース管理、及びアップリンク通信２１０及びダウンリンク通信２１２のためのデータパケットスケジューリング、並びにモビリティ管理のような無線ネットワーク制御（ＲＮＣ）機能を含むがこれに限定されないＲＡＮ１０６の種々の論理機能を満たすことができる。ＥＰＳ／ＬＴＥネットワークの中のｅＮｏｄｅＢは、ＥＰＣネットワーク（図示しない）と通信するために別個の制御部（つまり、ＲＮＣ）を利用しない。他の実施形態では、他の仕様プロトコルを用いて、ＲＡＮは、ＢＳとコアネットワークとの間の通信を可能にするためにＲＮＣを含み得る。

【0016】

実施形態に従って、ＵＥ１０２及び１０４は、ＯＦＤＭ（Orthogonal Frequency−Division Multiplexing）通信信号をｅＮｏｄｅＢ２０２及び２０４のうちの任意のものと、ダウンリンク通信２１２ではＯＦＤＭＡ（Orthogonal Frequency−Division Multiple Access）に従うマルチキャリア通信チャネルを介して、及びアップリンク通信２１０ではＳＣ−ＦＤＭＡ（Single Carrier Frequency Division Multiple Access）通信技術を介して、通信するよう構成され得る。ＯＦＤＭ信号は、複数の直交サブキャリアを有し得る。

【0017】

幾つかの実施形態に従い、ＵＥ１０２及び１０４は、ｅＮｏｄｅＢ２０２及び２０４のうちの任意のものからの１又は複数の信号の受信に基づき、同期基準時間を決定するよう構成され得る。ＵＥは、ＯＦＤＭＡ、ＳＣ−ＦＤＭＡ、又は他の複数のアクセス方式を用いて、他のＵＥとの装置対装置（Ｄ２Ｄ）通信をサポートするよう更に構成され得る。

【0018】

幾つかの実施形態では、ダウンリンクリソースグリッドは、ｅＮｏｄｅＢ２０２及び２０４のうちの任意のものからＵＥ１０２及び１０４へのダウンリンク通信２１２での送信のために使用され得る。一方、ＵＥ１０２及び１０４からｅＮｏｄｅＢ２０２及び２０４のうちの任意のものへのアップリンク通信２１０のための送信は、同様の技術を利用できる。グリッドは、リソースグリッド又は時間周波数リソースグリッドと呼ばれる、各々のスロットの中のダウンリンクの物理リソースである時間周波数グリッドであり得る。このような時間周波数プレーン表現は、ＯＦＤＭシステムの慣習であり、無線リソース割り当てのために直感的に理解できる。リソースグリッドの各列及び各行は、１つのＯＦＤＭシンボル及び１つのＯＦＤＭサブキャリアにそれぞれ対応する。時間ドメインのリソースグリッドの期間は、無線フレームの中の１つのスロットに対応する。リソースグリッドの中の最小時間周波数ユニットは、リソースエレメントとして示される。各々のリソースグリッドは、多数のリソースブロックを有し、特定の物理チャネルのリソースエレメントへのマッピングを表す。各リソースブロックは、リソースエレメントの集合を有する。周波数ドメインでは、これは、現在割り当て可能なリソースの最小量を表す。このようなリソースブロックを用いて伝達される幾つかの異なる物理ダウンリンクチャネルが存在する。

【0019】

ＰＤＳＣＨ（physical downlink shared channel）は、ＵＥ１０２及び１０４へのユーザデータ及び上位レイヤシグナリングを伝達する。ＰＤＣＣＨ（physical downlink control channel）は、特に、ＰＤＳＣＨチャネルに関連するトランスポートフォーマット及びリソース割り当てに関する情報を伝達する。これは、ＵＥ１０２及び１０４に、アップリンク共有チャネルに関連する、トランスポートフォーマット、リソース割り当て、及びＨ−ＡＲＱ情報についても知らせる。標準的に、ダウンリンクスケジューリング（セルの中のＵＥ１０２に制御及び共有チャネルリソースブロックを割り当てる）は、ＵＥ１０２及び１０４からｅＮｏｄｅＢ２０２及び２０４のうちの任意のものにフィードバックされるチャネル品質情報に基づき実行される。次に、ダウンリンクリソース割り当て情報は、ＵＥのために使用される（つまりそれに割り当てられた）制御チャネル（つまり、ＰＤＣＣＨ）で、該ＵＥへ送信される。

【0020】

ＰＤＣＣＨは、制御情報を伝達するために、制御チャネルエレメント（control channel element：ＣＣＥ）を使用する。リソースエレメントにマッピングされる前に、ＰＤＣＣＨ複素数値シンボルは、先ず、４連符（quadruplets）に編成される。これは、次に、レートマッチングのためにサブブロックインターリーバを用いて順序を変えられる。各々のＰＤＣＣＨは、これらＣＣＥのうちの１又は複数を用いて送信される。ここで、各々のＣＣＥは、リソースエレメントグループ（resource element group：ＰｖＥＧ）として知られる４個の物理リソースエレメントの９個のセットに対応する。４個のＱＰＳＫ（quadrature phase shift keying）シンボルは、各々のＲＥＧにマッピングされる。ＰＤＣＣＨは、ＤＣＩのサイズ及びチャネル状態に依存して、１又は複数のＣＣＥを用いて送信され得る。異なる数のＣＣＥを有する、ＬＴＥにおいて定められた４個以上の異なるＰＤＣＣＨフォーマットが存在し得る（例えば、アグリゲーションレベル、Ｌ＝１、２、４又は８）。

【0021】

Ｄ２Ｄ通信リンク２１４は、ＵＥ１０２及び１０４に、ＲＡＮ１０６を用いて互いに直接通信させる。装置発見信号リソース割り当て及び上位レイヤシグナリング手順は、Ｄ２Ｄ通信を効率的な方法で可能にするために、最初に、ｅＮｏｄｅＢ２０２及び２０４のうちの任意のものから、ＵＥ１０２及び１０４へ通信され得る。Ｄ２Ｄサービスは、代替で、本願明細書において、近接性に基づくサービス（proximity−based service：ＰｒｏＳｅ）として参照され得る。これらの特徴は、公衆安全（ＰＳ）及び非ＰＳ（例えば、商用）サービスのために展開されている。Ｄ２Ｄ通信は、（少なくとも一部の）セルラインフラを使用しないでモバイルコンピューティング装置に互いに通信可能にするので、ＰＳサービスでは、Ｄ２Ｄ通信は、Ｅ−ＵＴＲＡＮカバレッジが利用可能ではない緊急状況で使用され得る。非ＰＳサービスは、ネットワークオフローディングを可能にする。例えば、所与の近傍にいるユーザが、ビデオ共有のような有意な帯域幅を消費するサービスを利用しているとき、Ｄ２Ｄサービスは、Ｅ−ＵＴＲＡＮリソースのユーザを排除する。Ｄ２Ｄ通信は、近接性に基づく装置発見、装置間通信、又は両者の通信の組合せ（つまり、近接性に基づく装置発見に続くその後のＤ２Ｄ通信）を備えることができる。

【0022】

以下に記載する例は、ＬＴＥ信号により接続を確立するＵＥ１０２及び１０４を対象とする。幾つかの実施形態では、ＵＥ１０２及び１０４は、他の通信フォーマット（例えば、Ｂｌｕｅｔｏｏｔｈ（登録商標）、近距離通信（near field communication：ＮＦＣ）、等）により接続を確立することが可能である。

【0023】

Ｄ２Ｄの可能なＵＥ１０２及び１０４は、近隣のＤ２Ｄの可能な装置を検出するための発見を実行でき、装置発見動作を実行するためにｅＮｏｄｅＢ２０２及び２０４のうちの任意のものからリソースを割り当てられる。以下に更に詳述するように、これらの割り当てられたリソースは、発見信号を送信するためのリソース（例えば、リソースブロック（resource block：ＲＢ）又は物理リソースブロック（physical resource block：ＰＲＢ））を有する発見領域又は発見ゾーンを有し得る。

【0024】

図３は、幾つかの実施形態に従う、ＵＥ３００及びｅＮｏｄｅＢ３５０のブロック図を示す。留意すべきことに、幾つかの実施形態では、ｅＮｏｄｅＢ３５０は、静止した非モバイル装置であり得る。ＵＥ３００は、１又は複数のアンテナ３０１を用いてｅＮｏｄｅＢ３５０、他のｅＮｏｄｅＢ、又は他の装置へ信号を送信し及びそれから受信する物理レイヤ回路３０２を有し得る。一方、ｅＮｏｄｅＢ３５０は、１又は複数のアンテナ３５１を用いてＵＥ３００、他のｅＮｏｄｅＢ、他のＵＥ、又は他の装置へ信号を送信し及びそれから受信する物理レイヤ回路３５２を有し得る。ＵＥ３００は、無線媒体へのアクセスを制御する媒体アクセス制御レイヤ（medium access control layer：ＭＡＣ）回路３０４も有し得る。一方、ｅＮｏｄｅＢ３５０は、無線媒体へのアクセスを制御するＭＡＣ回路３５４も有し得る。ＵＥ３００は、本願明細書に記載の動作を実行するよう構成される処理回路３０６及びメモリ３０８も有し得る。ｅＮｏｄｅＢ３５０は、本願明細書に記載の動作を実行するよう構成される処理回路３５６及びメモリ３５８も有し得る。

【0025】

アンテナ３０１、３５１は、例えばダイポールアンテナ、モノポールアンテナ、パッチアンテナ、ループアンテナ、マイクロストリップアンテナ、又はＲＦ信号の送信に適する他の種類のアンテナを含む１又は複数の指向性又は全方向性アンテナを有し得る。幾つかの多入力多出力（multiple−input multiple−output：ＭＩＭＯ）環境では、アンテナ３０１、３５１は、空間ダイバシティ及び結果として生じ得る異なるチャネル特性から利益を享受つるために効果的に隔離され得る。

【0026】

ＵＥ３００及びｅＮｏｄｅＢ３５０はそれぞれ幾つかの別個の機能要素を有するとして示されるが、機能要素のうちの１又は複数は、結合され、デジタル信号プロセッサ（digital signal processor：ＤＳＰ）を含む処理要素のようなソフトウェアにより設定される要素及び／又はハードウェア要素の組合せにより実装され得る。例えば、幾つかの要素は、１又は複数のマイクロプロセッサ、ＤＳＰ、ＦＰＧＡ（field−programmable gate array）、ＡＳＩＣ（application specific integrated circuit）、ＲＦＩＣ（radio−frequency integrated circuit）、及び少なくとも本願明細書に記載の機能を実行する種々のハードウェア及び回路の組合せを有し得る。幾つかの実施形態では、機能要素は、１又は複数の処理要素で動作する１又は複数のプロセスを表し得る。

【0027】

実施形態は、ハードウェア、ファームウェア、及びソフトウェアのうちの１つ又はそれらの組合せで実施され得る。実施形態は、本願明細書に記載の動作を実行するために少なくとも１つのプロセッサにより読み出され実行され得る、コンピュータ可読記憶装置に格納された命令として実施され得る。コンピュータ可読記憶装置は、機械（例えばコンピュータ）により読み出し可能な形式で情報を格納する任意の非一時的メカニズムを含み得る。例えば、コンピュータ読み取り可能な記憶装置は、読み出し専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、磁気ディスク記憶媒体、光学記憶媒体、フラッシュメモリ装置及びその他の記憶装置及び媒体を包含し得る。幾つかの実施形態は、１又は複数のプロセッサを含むことができ、コンピュータ可読記憶装置に格納される命令により構成されることができる。

【0028】

図４Ａは、開示の実施形態による、Ｄ２Ｄサービスのために割り当てられるＲＢを示す。本実施形態では、グラフ４００は、マッピングプロットを示し、ｘ軸は周波数ドメインにおけるフレーム（例えば、ＯＦＤＭシンボル）であり、ｙ軸はサブキャリアである。グラフ４００では、領域４０２は、ＬＴＥ動作ゾーンを有し、１つの領域はＤ２Ｄ装置のための１つの発見ゾーン４０４を有する。上述のように、ｅＮｏｄｅＢは、発見情報を送信するために、ＵＥのためのＤ２Ｄ発見ゾーン／領域の形式で、発見リソースを周期的に割り当てることができる。発見情報は、ペイロード情報を有する発見パケット、又は発見プリアンブルにより先行される発見パケットを有しても良い。発見パケット送信のために使用される物理リソースブロックの数は、ペイロードサイズ及び全体の発見性能目標に依存して、１又は複数のＲＢを有し得る。発見リソースプール又は発見ゾーン４０４は、多数のサブフレーム（サブフレームインデックス４２２から始まる大きさ４２０として示す）毎に割り当てられる多数の割り当てられたＲＢ（リソースブロックインデックス４１２から始まる大きさ４１０として示す）を有する。

【0029】

幾つかの実施形態では、ＵＥは、予め存在するアップリンクチャネルリソースを用いてＤ２Ｄ直接発見を実行しても良く、物理発見チャネルは、復調参照信号（demodulation reference signal：ＤＭＲＳ）を含む現在定められているＰＵＳＣＨ（physical uplink shared channel）に基づき設計され得る。ＰＳ及び非ＰＳ Ｄ２Ｄ発見サービスのためのメッセージサイズは、異なり得る。ＤＭＲＳシーケンスは、特定のメッセージサイズを示すために１又は複数の情報ビットを伝達するために使用され得る。

【0030】

図４Ｂは、開示の実施形態による、Ｄ２Ｄサービスのために割り当てられるＲＢを示す。本実施形態では、グラフ４５０は、ＰＳ及び非ＰＳ発見信号の送信のための発見ゾーン４０４のパーティショニングを示す。言い換えると、ＰＳ及び非ＰＳ発見信号のための別個の時間−周波数リソースは、ｅＮｏｄｅＢにより構成され得る。したがって、Ｄ２Ｄ ＵＥは、対応するリソースプールで、ＰＳ及び非ＰＳ発見信号を送信し及び受信できる。発見ゾーン４０４は、サブフレームによりパーティショニングされても良い。したがって、線４５２の左までのサブフレームは、ＰＳ Ｄ２Ｄサービスのために割り当てられても良く、線４５２の右までのサブフレームは、非ＰＳ Ｄ２Ｄサービスのために割り当てられても良い。発見ゾーン４０４は、物理リソースブロック（ＰＲＢ）に跨りパーティショニングされても良い。したがって、４５４の上にあるＰＲＢは、ＰＳ Ｄ２Ｄサービスのために割り当てられても良く、４５４の下にあるサブフレームは、非ＰＳ Ｄ２Ｄサービスのために割り当てられても良い。勿論、他の実施形態では、任意の他のパーティショニング方式が用いられても良い。

【0031】

幾つかの実施形態では、ＰＳ及び非ＰＳ発見リソースプールのための２つのリソースプールの構成は、受信のためだけにシグナリングされても良い。送信のために、リソースは、タイプ２Ａ発見リソース割り当て（つまり、各々の固有発見メッセージ送信機会）又はタイプ２Ｂ発見リソース割り当て（つまり、半永久的割り当て）のようなＵＥ固有の方法で構成され得る。幾つかの実施形態では、リソースは、ＵＥ固有及び非ＵＥ固有の方法の組合せ、例えばタイプ２Ａ／タイプ２Ｂ及びタイプ１発見リソース割り当てを用いて、構成され得る（ここで、タイプ１発見リソース割り当ては、非ＵＥ固有の方法で周期的に生じる発見リソースセットを割り当てるｅＮｏｄｅＢを表す）。

【0032】

図５は、開示の実施形態による、Ｄ２ＤサービスのためにＲＢを割り当てるフロー図を示す。ここに示されるような論理フロー図は、種々の処理動作の例示的なシーケンスを提供する。特定のシーケンス又は順序に示されるが、特に指定されない限り、動作の順序は変更できる。したがって、記載の及び図示の実装は、単なる例として理解されるべきであり、図示の処理は、異なる順序で実行でき、幾つかの動作は平行に実行できる。さらに、種々の実施形態において、１又は複数の動作は省略できる。したがって、必ずしも全ての動作が全ての実装において実行されない。他の処理フローも可能である。

【0033】

処理５００は、ＵＥにより実行される、１又は複数の他のＵＥによるＤ２Ｄ発見メッセージの送信のためのＤ２Ｄ発見リソース要求をｅＮｏｄｅＢへ送信する動作を有する（例えば、タイプ２又はＵＥ固有発見リソース割り当て手順）（ブロック５０２）。上述のように、Ｄ２Ｄ発見要求は、Ｄ２Ｄサービスタイプ、例えばＰＳサービス又は非ＰＳサービスに関連する。この動作は、ＵＥ自立リソース選択手順（例えば、タイプ１発見）と関係がなくても良い。

【0034】

次に、ＵＥは、ｅＮｏｄｅＢからＤ２Ｄ直接発見リンクに関連するリソース割り当て情報を受信する動作を実行する（ブロック５０４）。リソース割り当て手順に依存して、タイプ１発見では、この情報は、ＵＥ固有であり、共通ＲＲＣシグナリングを用いて、例えばシステム情報ブロック（System Information Block：ＳＩＢ）シグナリングにより送信できる。一方で、タイプ２Ａ又は２Ｂ発見では、この情報は、ＵＥ固有であり、共通ＲＲＣ（例えば、ＳＩＢ）及び専用ＲＲＣシグナリングの組合せにより示され得る。幾つかの実施形態では、上述のように、ｅＮｏｄｅＢは、Ｄ２Ｄサービスタイプに固有のＲＢを割り当てる（例えば、図４Ｂに示すように、ＰＳサービスのために特別に割り当てられるＲＢ、及び非ＰＳサービスのために特別に割り当てられるＲＢ）。他の実施形態では、Ｄ２Ｄ発見メッセージ送信に関連するデータは、１又は複数の他のＵＥにＤ２Ｄサービスタイプを示すために、送信側ＵＥの回路により構成される。

【0035】

本実施形態では、ＵＥは、Ｄ２Ｄ直接発見リンクを介して、１又は複数の他のＵＥへＤ２Ｄ発見メッセージを送信する動作を実行する。ここで、該メッセージは、データペイロードを有する少なくとも１つのデータフレームを有する（ブロック５０６）。データペイロードのサイズは、Ｄ２Ｄサービスタイプに基づき決定される。例えば、ＰＳサービスのためのデータペイロードサイズは、非ＰＳサービスのためのデータペイロードサイズより大きなサイズを有し得る。

【0036】

ＵＥは、データペイロードサイズを含み得るＤ２Ｄサービスタイプを示すために、Ｄ２Ｄデータ送信の少なくとも１つのデータフレームに関連するデータ送信を構成する動作を実行する（ブロック５０８）。幾つかの実施形態では、例えば、ＵＥのＭＡＣは、データペイロードサイズを示すためにＤ２Ｄデータ送信の少なくとも１つのデータフレームに関連するデータを構成するべきであり、さらに、少なくとも１つのデータフレームのＭＡＣヘッダの中の１又は複数のビットをアサートすべきである。他の実施形態では、例えば、ＵＥのＰＨＹは、データペイロードサイズを示すためにＤ２Ｄデータ送信の少なくとも１つのデータフレームに関連するデータを構成するべきであり、さらに、データペイロードのためのＤ２Ｄサービスタイプに関連する周期的冗長検査（cyclic redundancy check：ＣＲＣ）コードを選択すべきである。更に以下に詳述されるこれらの実施形態のうちの幾つかでは、データペイロードのためのＤ２Ｄサービスタイプに関連するＣＲＣコードは、Ｄ２Ｄサービスタイプに関連するデータマスク値によりマスクされるＣＲＣを有する。幾つかの他の実施形態では、例えばタイプ１発見では、ＵＥは発見リソースプールの中からリソースを自立的に選択し、ＵＥのＭＡＣ及びＰＨＹは、データ送信手順を構成する。したがって、ＵＥは、発見リソースプールの中から発見リソース（つまり、ＲＢ）で、又は特定の発見サービスタイプについてｅＮＢにより構成される発見ゾーンで、送信できる。

【0037】

１種類のみの発見信号送信（例えば、ＰＳ又は非ＰＳ）が生じる実施形態では、対応する発見リソースプールだけが、構成され得る。代替で、ネットワークの中でＰＳサービス及び非ＰＳサービスの両方が展開される場合、発見リソースプール又は発見ゾーンがＰＳサービス又は非ＰＳサービスに割り当てられるか否かを示すパラメータは、ｅＮＢによりシグナリングされる発見リソースプール構成の部分として構成され得る。これに関し、ＰｒｏＳｅの可能な装置は、このパラメータに従ってペイロードサイズを区別できる。

【0038】

送信及び受信のための又は受信のためのリソースプールの上述の構成は、ネットワークカバレッジの中にいるＤ２Ｄ ＵＥに対して、ｅＮｏｄｅＢによりシグナリングされる信号情報ブロック（ＳＩＢ）によりシグナリングされ得る。一部のネットワークカバレッジのシナリオでは、構成に関するこのような情報は、ネットワークカバレッジの中にいる１又は複数のＵＥにより、ネットワークカバレッジの外側にいるＵＥへ転送され得る。ネットワークカバレッジ外のシナリオでは、この構成は、中央Ｄ２Ｄ装置により予め定められ又はブロードキャストされ、或いは、他の従属／ゲートウェイ同期ソースにより更に転送される構成と共に、独立同期ソースに関連付けられ及びそれによりシグナリングされ得る。

【0039】

図６Ａは、開示の実施形態による、Ｄ２Ｄ発見メッセージ送信のためのデータフレームを示す。本実施形態では、データフレーム６００は、非ＰＳ発見サービスのために使用され、データフレーム６１０は、ＰＳ発見サービスのために使用される。データフレーム６００は、ペイロード６０２及び巡回冗長検査（ＣＲＣ）コード６０４を有する。データフレーム６１０は、ペイロード６１２及びＣＲＣコード６１４を有する。本図に示すように、ＰＳ発見サービスは、非ＰＳサービスと比べて大きな発見メッセージペイロードを使用すると想定される。しかしながら、本発明の実施形態は、反対の場合（つまり、非ＰＳ発見のための発見メッセージペイロードサイズがＰＳ発見よりも大きい）を扱うために直接的に適用できる。

【0040】

本実施形態では、データフレーム６００は、異なる種類の発見サービスの「全体の」ペイロードサイズが同じであることを保証するために、ゼロパディング６０６を更に有する。これに関し、ＰｒｏＳｅの可能なＵＥは、情報ビットを１度復号化するだけで良い。データペイロード６０２及び６１２のサイズを区別するために、実施形態は、異なるペイロードサイズを示す目的で異なるＣＲＣコードを利用できる（つまり、ＣＲＣコード１ ６０４は非ＰＳサービスに関連付けられ、ＣＲＣコード２ ６１４はＰＳサービスに関連付けられる）。ＰｒｏＳｅの可能な装置は、復号化処理（例えば、ターボ復号化）を１回だけ実行でき、続いて、ペイロードサイズ又は発見サービスを区別するために、複数のＣＲＣ復号化の試みを実行できる。

【0041】

ゼロパディングを利用しない他の実施形態では、ＰｒｏＳｅの可能なＵＥは、異なるペイロード及びＣＲＣコードを有する異なる種類の発見サービスのためのブラインド復号化を実行できる。ＣＲＣビットの復号化に成功すると、ＰｒｏＳｅの可能なＵＥは、対応するペイロードサイズ又は発見サービスの種類を決定できる。しかしながら、「全体の」ペイロードサイズの差は、復号化処理の複雑性を増大し得る。言い換えると、実施形態は、復号化の複雑性を低減するためにゼロパディング６０６を利用できる。

【0042】

図６Ｂは、本開示の実施形態による、異なるＤ２Ｄサービスデータペイロードのための異なるＣＲＣコードを生成する手順を示す。ＣＲＣ６５０の生成の後、非ＰＳサービスのために使用されるサービスＩＤ６５２を用いて、生成されたＣＲＣビットに対してＸＯＲ演算が用いられる。マスクされたＣＲＣビットは、次に、ＣＲＣコード１ ６０４としてデータフレーム６００の末尾に付加される。同様の演算はデータフレーム６１０に対して実行される。ＣＲＣ６６０の生成の後、ＰＳサービスのために使用されるサービスＩＤ６６２を用いて、生成されたＣＲＣビットに対してＸＯＲ演算が用いられる。マスクされたＣＲＣビットは、次に、ＣＲＣコード２ ５１４としてデータフレーム６１０の末尾に付加される。

【0043】

本開示の別の実施形態では、異なるペイロードサイズ又は発見サービスは、異なるスクランブリングコードに基づき区別できる。特に、スクランブリング同一性は、発見サービス同一性の関数であり得る。幾つかの実施形態では、発見サービスの同一性は、同一性情報の生成をスクランブリングするために、他のパラメータ及び／又は他のパラメータの組合せ、例えば共通スクランブリングＩＤ、発見リソースインデックス、等と共に組み込まれ得る。

【0044】

図７は、開示の態様に従う、機械可読媒体から命令をリードし、本願明細書で議論される方法のうちの任意の１又は複数を実行できる、幾つかの例示的な実施形態に従う機械のコンポーネントを示すブロック図である。特に、図７は、例示的なコンピュータシステム７００を示す。コンピュータシステム７００の中では、本願明細書で議論する方法のうちの１又は複数を機械に実行させるソフトウェア７２４が実行され得る。代替の実施形態では、機械は、スマートデバイスとして動作し、又は他の機械に接続（ネットワーク接続）され得る。ネットワーク接続された配備では、機械は、サーバ−クライアントネットワーク環境におけるサーバ又はクライアント機械の能力範囲内で、又はピアツーピア（又は分散型）ネットワーク環境におけるピアマシンとして動作できる。コンピュータシステム７００は、上述のＵＥ又はｅＮｏｄｅＢのうちの任意のものとして機能でき、パーソナルコンピュータ（PC）、タブレットPC、セットトップボックス（STB）、パーソナルデジタルアシスタント（PDA）、携帯電話機、ウェブ機器、ネットワークルータ、スイッチ若しくはブリッジ、又は該機械により行われるべき動作を指定する命令を（シーケンシャルに又はその他の場合）実行可能な機械であり得る。さらに、単一の機械のみを図示するが、用語「機械」は、個々に又は共同して、本願明細書で議論した１又は複数の方法を実行するために命令セット（又は複数のセット）を実行する機械の集合を含むと考えられるべきである。

【0045】

例示的なコンピュータシステム７００は、バス７０８を介して互いに通信する、プロセッサ７０２（例えば、CPU（central processing unit）、GPU（graphics processing unit）、又はそれらの両者）、主記憶７０４、及び静的記憶７０６を有する。コンピュータシステム７００は、ビデオディスプレイユニット７１０（例えば、液晶ディスプレイ（ＬＣＤ）又は陰極線管（ＣＲＴ））を更に有し得る。コンピュータシステム７００は、英数字入力装置７１２（例えば、キーボード）、ＵＩナビゲーション（又はカーソル制御）装置７１４（例えば、マウス）、記憶装置７１６、信号生成装置７１８（例えば、スピーカ）、及びネットワークインタフェース装置７２０も有する。

【0046】

記憶装置７１６は、非一時的機械可読媒体７２２を有する。非一時的機械可読媒体７２２には、本願明細書に記載の方法又は機能のうちの１又は複数を実施する又はそれにより利用されるデータ構造及びソフトウェア７２４の１又は複数のセットが格納される。ソフトウェア７２４は、コンピュータシステム７００による実行中に、主記憶７０４及び／又はプロセッサ７０２内に完全に又は少なくとも部分的に存在し得る。ここで、主記憶７０４及びプロセッサ７０２も、非一時的機械可読媒体７２２を構成する。ソフトウェア７２４は、完全に又は少なくとも部分的に、静的記憶７０６内に存在しても良い。

【0047】

非一時的機械可読媒体７２２は例示的な実施形態で単一媒体であるとして図示されたが、用語「機械可読媒体」は、１又は複数のソフトウェア７２４又はデータ構造を格納する単一の媒体又は複数の媒体（例えば、中央又は分散型データベース、及び／又は関連キャッシュ及びサーバ）を含み得る。用語「機械可読媒体」は、機械による実行のために命令を格納し、符号化し又は運ぶことができ、及び機械に本実施形態の方法のうちの１又は複数を実行させ、又は該命令により利用される若しくはそれに関連するデータ構造を格納し、符号化し又は運ぶことができる有形媒体を含むと考えられるべきである。したがって、用語「機械可読媒体」は、固体メモリ、光学及び磁気媒体を含むと考えられるが、これらに限定されない。機械可読媒体７２２の特定の例は、例として半導体メモリ装置（例えば、EPROM（Electrically Programmable Read−Only Memory）、EEPROM（Electrically Erasable Programmable Read−Only Memory））、フラッシュメモリ装置、内部ハードディスク及び取り外し可能ディスクのような磁気ディスク、光磁気ディスク、及びCD−ROM（compact disc−read−only memory）、DVD−ROM（digital versatile disc（又はdigital video disc） read−only memory）ディスクを含む。

【0048】

ソフトウェア７２４は、さらに、伝送媒体を用いて通信ネットワーク７２６を介して送信又は受信され得る。ソフトウェア７２４は、ネットワークインタフェース装置７２０及び多数の良く知られている転送プロトコルのうちの任意のもの（例えば、ＨＴＴＰ（hypertext transfer protocol））を用いて送信され得る。通信ネットワークの例は、LAN（local area network）、WAN（wide area network）、インターネット、携帯電話ネットワーク、POTS（Plain Old Telephone）ネットワーク、及び無線データネットワーク（例えば、Wi−Fi（登録商標）及びWiMAXネットワーク）を含む。用語「伝送媒体」は、機械による実行のために命令を格納し、符号化し又は運ぶことができる無形媒体を含み、デジタル又はアナログ通信信号又はこのようなソフトウェア７２４の通信を実現する他の無形媒体を含む。

【0049】

図及び前述の説明は、本開示の例を与えた。多数の異種機能アイテムとして示されたが、当業者は、このような要素のうちの１又は複数が単一の機能要素に結合され得ることを理解する。代替で、特定の要素は、複数の機能要素に分離できる。ある実施形態からの要素は、別の実施形態に追加できる。例えば、本願明細書に記載の処理の順序は、変更でき、本願明細書に記載の方法に限定されない。さらに、任意のフロー図の動作は、示された順序で実施される必要はなく、必ずしも全ての動作が実行される必要もない。また、他の動作に依存しない動作は、他の動作と平行に実行できる。しかしながら、本開示の範囲は、これらの特定の例により限定されない。本願明細書の中で明示的に与えられるか否かに拘わらず、構造、大きさ、及び材料の使用における相違のような多数の変形が可能である。本開示の範囲は、少なくとも、添付の請求の範囲により与えられるのと同じように広い。

【0050】

読者が技術的開示の特性及び主旨を解明できるように、要約を要求する３７Ｃ．Ｆ．Ｒ Section１．７２（ｂ）に従い、要約が提供される。要旨は請求項の範囲又は意味を解釈又は限定するために用いられるべきでないことが理解される。ここで、添付の請求項は、各請求項が別個の実施形態として存在するとして、詳細な説明に組み込まれる。

【0051】

幾つかの実施形態は、ユーザ機器（ＵＥ）であって、回路を有し、前記回路は、第２のＵＥと装置対装置（Ｄ２Ｄ）直接発見リンクを確立するために、ｅＮｏｄｅＢへＤ２Ｄ発見要求を送信し、前記Ｄ２Ｄ発見要求は、Ｄ２Ｄサービスタイプに関連付けられ、前記ｅＮｏｄｅＢから少なくとも前記第２のＵＥへ発見メッセージを送信するために、前記Ｄ２Ｄ直接発見リンクに関連するリソース割り当て情報を受信し、前記の情報は、共通又は専用無線リソース制御（ＲＲＣ）シグナリングを介して受信され、前記第２のＵＥへ前記Ｄ２Ｄ直接発見リンクを介して、データペイロード、前記Ｄ２Ｄサービスタイプに基づき決定される前記データペイロードのサイズを有する少なくとも１つのデータフレームを含むＤ２Ｄデータ送信を送信し、前記データペイロードサイズを示すために、前記Ｄ２Ｄデータ送信の前記少なくとも１つのデータフレームに関連するデータを構成する、よう構成される、ＵＥを記載する。

【0052】

幾つかの実施形態では、前記Ｄ２Ｄサービスタイプは、公衆安全（ＰＳ）サービス又は非ＰＳサービスのうちの少なくとも１つを有する。幾つかの実施形態では、ＰＳサービスのためのデータペイロードサイズは、非ＰＳサービスのためのデータペイロードサイズより大きなサイズを有する。

【0053】

幾つかの実施形態では、前記回路は、媒体アクセス制御（ＭＡＣ）レイヤを更に有し、前記ＭＡＣは、前記データペイロードサイズを示すために前記Ｄ２Ｄ発見メッセージ送信の前記少なくとも１つのデータフレームに関連するデータを構成し、さらに、前記少なくとも１つのデータフレームのＭＡＣヘッダの中の１又は複数のビットをアサートする。幾つかの実施形態では、前記回路は、物理レイヤ（ＰＨＹ）を更に有し、前記ＰＨＹは、前記データペイロードサイズを示すために前記Ｄ２Ｄ発見メッセージ送信の前記少なくとも１つのデータフレームに関連する前記データを構成し、さらに、前記データペイロードのための前記Ｄ２Ｄサービスタイプに関連する巡回冗長検査（ＣＲＣ）を選択する。幾つかの実施形態では、データペイロードマスクのための前記Ｄ２Ｄサービスタイプに関連する前記ＣＲＣコードは、前記Ｄ２Ｄサービスタイプに関連するデータマスク値によりマスクされるＣＲＣを有する。

【0054】

幾つかの実施形態では、前記回路は、物理レイヤ（ＰＨＹ）を更に有し、前記ＰＨＹは、前記データペイロードサイズを示すために前記Ｄ２Ｄ発見メッセージ送信の前記少なくとも１つのデータフレームに関連する前記データを構成し、さらに、前記Ｄ２Ｄサービスタイプと共に使用するために排他的に、前記ｅＮｏｄｅＢにより割り当てられるリソースブロックを要求する。

【0055】

幾つかの実施形態では、前記回路は、媒体アクセス制御レイヤ（ＭＡＣ）を更に有し、前記ＭＡＣは、前記データペイロードサイズを示すために前記Ｄ２Ｄデータ送信の前記少なくとも１つのデータフレームに関連するデータを構成し、さらに、Ｄ２Ｄサービスタイプに関連するデータペイロードのビット数に一致するよう１又は複数のゼロを前記データペイロードに付加する。

【0056】

幾つかの実施形態では、前記回路は、ＰＵＳＣＨ（physical uplink shared channel）を介して前記ｅＮｏｄｅＢへ前記Ｄ２Ｄ発見要求を送信するよう更に構成される。幾つかの実施形態では、前記回路は、前記Ｄ２Ｄ発見要求及び前記Ｄ２Ｄデータ送信を送信するために、１又は複数のアンテナを更に有する。

【0057】

幾つかの実施形態は、回路を有するｅＮｏｄｅＢであって、前記回路は、複数の装置対装置（Ｄ２Ｄ）発見サービスタイプに対して物理リソースブロック（ＰＲＢ）のセットを割り当て、前記ＰＲＢのセットは、第１のＤ２Ｄ発見サービスタイプのためのＰＲＢ及びサブフレームの第１のサブセットと、第２のＤ２Ｄ発見サービスタイプのためのＰＲＢ及びサブフレームの第２のサブセットと、を有し、前記第１のサブセット及び前記第２のサブセットは、重なり合わないサブセットを有し、共通無線リソース制御（ＲＲＣ）又は専用ＲＲＣシグナリングのうちの少なくとも１つを介する送信のために１又は複数のユーザ機器（ＵＥ）への送信のためのＰＲＢ割り当て情報を有する送信情報を構成する、よう構成される。

【0058】

幾つかの実施形態では、前記第１のＤ２Ｄ発見サービスタイプは、公衆安全（ＰＳ）サービスを有し、前記第２のＤ２Ｄ発見サービスタイプは、非ＰＳサービスを有する。幾つかの実施形態では、前記回路は、前記複数のＤ２Ｄ発見サービスタイプのうちの各々に１又は複数の復調参照信号（ＤＭＲＳ）を割り当てるよう更に構成される。

【0059】

幾つかの実施形態は、ユーザ機器（ＵＥ）と装置対装置（Ｄ２Ｄ）直接発見リンクを確立するために、ｅＮｏｄｅＢへＤ２Ｄ発見要求を送信するステップであって、前記Ｄ２Ｄ発見要求は、公衆安全（ＰＳ）サービス又は非ＰＳサービスのうちの少なくとも１つを有するＤ２Ｄ発見サービスタイプに関連付けられる、ステップと、前記ｅＮｏｄｅＢから前記Ｄ２Ｄ通信リンクに関連するリソース割り当て情報を受信するステップであって、前記リソース割り当て情報は、ＵＥ固有又はＵＥ共通情報を有する、ステップと、前記Ｄ２Ｄ通信リンクを介する前記ＵＥへの送信のために、Ｄ２Ｄ発見メッセージを生成するステップであって、前記Ｄ２Ｄ発見メッセージは、データペイロード、前記Ｄ２Ｄサービスタイプに基づき決定される前記データペイロードのサイズを有する少なくとも１つのデータフレームと、前記データペイロードサイズを示すよう構成される前記Ｄ２Ｄ発見メッセージの前記少なくとも１つのデータフレームに関連するデータと、を有する、ステップと、を有する方法を記載する。

【0060】

幾つかの実施形態では、前記データペイロードのサイズを示すために前記Ｄ２Ｄ発見メッセージ送信の前記少なくとも１つのデータフレームに関連するデータを構成するステップは、前記データフレームのＭＡＣヘッダの中の１又は複数のビットをアサートするステップを有する。幾つかの実施形態では、前記データペイロードのサイズを示すために前記Ｄ２Ｄ発見メッセージ送信の前記少なくとも１つのデータフレームに関連するデータを構成するステップは、前記データペイロードについて、前記Ｄ２Ｄ発見サービスタイプに関連する巡回冗長検査（ＣＲＣ）コードを選択するステップを有する。幾つかの実施形態では、前記データペイロードのサイズを示すために前記Ｄ２Ｄ発見メッセージ送信の前記少なくとも１つのデータフレームに関連するデータを構成するステップは前記Ｄ２Ｄ発見サービスタイプに関連するデータマスク値により、前記データペイロードの巡回冗長検査（ＣＲＣ）コードをマスクするステップを有する。

【0061】

幾つかの実施形態は、非一時的コンピュータ可読記録媒体であって、そのコンテンツは、コンピューティングシステムにより実行されると、前記コンピューティングシステムに動作を実行させ、前記動作は、ユーザ機器（ＵＥ）と装置対装置（Ｄ２Ｄ）直接発見リンクを確立するために、ｅＮｏｄｅＢへＤ２Ｄ発見要求を送信するステップであって、前記Ｄ２Ｄ発見要求は、公衆安全（ＰＳ）サービス又は非ＰＳサービスのうちの少なくとも１つを有するＤ２Ｄ発見サービスタイプに関連付けられる、ステップと、前記ｅＮｏｄｅＢから前記Ｄ２Ｄ通信リンクに関連するリソース割り当て情報を受信するステップであって、前記リソース割り当て情報は、ＵＥ固有又はＵＥ共通情報を有する、ステップと、前記Ｄ２Ｄ通信リンクを介して前記ＵＥへＤ２Ｄ発見メッセージ送信を送信するステップであって、前記Ｄ２Ｄ発見メッセージ送信は、データペイロードと前記Ｄ２Ｄサービスタイプに基づき決定される前記データペイロードのサイズとを有する少なくとも１つのデータフレームを有する、ステップと、前記データペイロードサイズを示すために、前記Ｄ２Ｄ発見メッセージ送信の前記少なくとも１つのデータフレームに関連するデータを構成するステップと、を有する非一時的コンピュータ可読記憶媒体を記載する。

【0062】

幾つかの実施形態では、前記動作は、ＵＥ固有発見リソース割り当て手順の間に前記Ｄ２Ｄ発見サービスタイプと共に使用するために、前記ｅＮｏｄｅＢにより排他的に割り当てられる発見リソースを要求するステップ、を更に有する。幾つかの実施形態では、前記データペイロードのサイズを示すために前記Ｄ２Ｄ発見メッセージ送信の前記少なくとも１つのデータフレームに関連するデータを構成するステップは、第２のＤ２Ｄサービスタイプに関連するデータペイロードのサイズのビット数に合致するよう前記データペイロードに１又は複数のゼロを付加するステップを有する。幾つかの実施形態では、前記Ｄ２Ｄ発見要求は、ＰＵＳＣＨ（physical uplink shared channel）を介して前記ｅＮｏｄｅＢへ送信される。幾つかの実施形態では、前記データペイロードのサイズを示すために前記Ｄ２Ｄ発見メッセージ送信の前記少なくとも１つのデータフレームに関連するデータを構成するステップは、前記データフレームのＭＡＣヘッダの中の１又は複数のビットをアサートするステップを有する。幾つかの実施形態では、前記データペイロードのサイズを示すために前記Ｄ２Ｄ発見メッセージ送信の前記少なくとも１つのデータフレームに関連するデータを構成するステップは、前記データペイロードについて、前記Ｄ２Ｄ発見サービスタイプに関連する巡回冗長検査（ＣＲＣ）コードを選択するステップ、又は前記Ｄ２Ｄサービスタイプに関連するデータマスク値により、前記データペイロードのＣＲＣコードをマスクするステップ、のうちの少なくとも１つを有する。

【図1】

【図2】

【図3】

【図4A】

【図4B】

【図5】

【図6A】

【図6B】

【図7】