[0001] 本出願は、2014年5月2日に出願された「RESOURCE ALLOCATION CONTROL FOR LONG TERM EVOLUTION DEVICE−TO−DEVICE DISCOVERY」と題する米国仮出願第61/987,839号、および2015年1月13日に出願された「RESOURCE ALLOCATION CONTROL FOR LONG TERM EVOLUTION DEVICE−TO−DEVICE DISCOVERY」と題する米国特許出願第14/596,146号の利益を主張するもので、それら全てが参照により本明細書に明確に組み込まれる。
[0024] 添付の図面に関して以下に記載する詳細な説明は、様々な構成の説明として意図されており、本明細書で説明する概念が実践され得る構成を表すことを意図しない。詳細な説明は、様々な概念の完全な理解を与えるための具体的な詳細を含む。しかしながら、これらの概念がこれらの具体的な詳細なしに実践され得ることが、当業者に明らかであろう。場合によっては、よく知られている構造および構成要素が、そのような概念を不明瞭にすることを避けるためにブロック図の形態で示される。
[0025] ここで、様々な装置および方法を参照しながら電気通信システムのいくつかの態様が提示される。これらの装置および方法は、以下の発明を実施するための形態において説明され、様々なブロック、モジュール、構成要素、回路、ステップ、プロセス、アルゴリズムなど(「要素」と総称される)によって添付の図面に示される。これらの要素は、電子ハードウェア、コンピュータソフトウェア、またはそれらの任意の組合せを使用して実施され得る。そのような要素がハードウェアとして実施されるのか、それともソフトウェアとして実施されるのかは、特定の適用例および全体的なシステムに課された設計制約に依存する。
[0026] 例として、要素、または要素の任意の部分、または要素の任意の組合せは、1つまたは複数のプロセッサを含む「処理システム」を用いて実施され得る。プロセッサの例は、マイクロプロセッサ、マイクロコントローラ、デジタルシグナルプロセッサ(DSP)、フィールドプログラマブルゲートアレイ(FPGA)、プログラマブル論理デバイス(PLD)、ステートマシン、ゲート論理、個別ハードウェア回路、および本開示全体にわたって説明する様々な機能を行うように構成される他の適切なハードウェアを含む。処理システムの中の1つまたは複数のプロセッサは、ソフトウェアを実行し得る。ソフトウェアは、ソフトウェア、ファームウェア、ミドルウェア、マイクロコード、ハードウェア記述言語と呼ばれるか、他の名称で呼ばれるかにかかわらず、命令、命令セット、コード、コードセグメント、プログラムコード、プログラム、サブプログラム、ソフトウェアモジュール、アプリケーション、ソフトウェアアプリケーション、ソフトウェアパッケージ、ルーチン、サブルーチン、オブジェクト、実行ファイル、実行スレッド、プロシージャ、関数などを意味すると広く解釈されたい。
[0027] 従って、1つまたは複数の例示的な実施形態では、説明される機能が、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せで実施され得る。ソフトウェアで実施される場合、機能は、コンピュータ可読媒体上に記憶され得るか、あるいはコンピュータ可読媒体上に1つまたは複数の命令またはコードとして符号化され得る。コンピュータ可読媒体は、コンピュータ記憶媒体を含む。記憶媒体は、コンピュータによってアクセスされ得る任意の利用可能な媒体であり得る。限定ではなく例として、そのようなコンピュータ可読媒体は、ランダムアクセスメモリ(RAM)、読取り専用メモリ(ROM)、電気的消去可能プログラマブルROM(EEPROM(登録商標))、コンパクトディスクROM(CD−ROM)もしくは他の光ディスクストレージ、磁気ディスクストレージもしくは他の磁気ストレージデバイス、または命令もしくはデータ構造の形態で所望のプログラムコードを搬送もしくは記憶するために使用され得、コンピュータによってアクセスされ得る、任意の他の媒体を備えることができる。上記の組合せも、コンピュータ可読媒体の範囲内に含まれるべきである。
[0028] 図1は、LTEネットワークアーキテクチャ100を示す図である。LTEネットワークアーキテクチャ100は、発展型パケットシステム(EPS)100と呼ばれることがある。EPS100は、1つまたは複数のユーザ機器(UE)102と、発展型UMTS地上波無線アクセスネットワーク(E−UTRAN:Evolved UMTS Terrestrial Radio Access Network)104と、発展型パケットコア(EPC:Evolved Packet Core)110と、事業者のインターネットプロトコル(IP)サービス122とを含み得る。EPSは他のアクセスネットワークと相互接続できるが、簡単のために、それらのエンティティ/インターフェースは図示していない。図示のように、EPSはパケット交換サービスを提供するが、当業者なら容易に諒解するように、本開示全体にわたって提示される様々な概念は、回線交換サービスを提供するネットワークに拡張され得る。
[0029] E−UTRANは、発展型ノードB(eNB)106と、他のeNB108とを含み、マルチキャスト協調エンティティ(MCE)128を含み得る。eNB106は、UE102に向かってユーザプレーンプロトコル終端と制御プレーンプロトコル終端とを提供する。eNB106は、バックホール(例えば、X2インターフェース)を介して他のeNB108に接続され得る。MCE128は、発展型マルチメディアブロードキャストマルチキャストサービス(MBMS:Multimedia Broadcast Multicast Service)(eMBMS)のために時間/周波数無線リソースを割り振り、eMBMS用の無線構成(例えば、変調/コーディング方式(MCS))を決定する。MCE128は、別個のエンティティ、またはeNB106の一部であり得る。eNB106は、基地局、ノードB、アクセスポイント、トランシーバ基地局、無線基地局、無線トランシーバ局、トランシーバ機能、基本サービスセット(BSS:basic service set)、拡張サービスセット(ESS:extended service set)、または何らかの他の適切な用語で呼ばれることもある。eNB106は、EPC110へのアクセスポイントをUE102に提供する。UE102の例は、セルラーフォン、スマートフォン、セッション開始プロトコル(SIP:session initiation protocol)フォン、ラップトップ、携帯情報端末(PDA)、衛星無線、全地球測位システム、マルチメディアデバイス、ビデオデバイス、デジタルオーディオプレーヤ(例えば、MP3プレーヤ)、カメラ、ゲーム機、タブレット、または任意の他の同様の機能デバイスを含む。UE102は、当業者によって、移動局、加入者局、モバイルユニット、加入者ユニット、ワイヤレスユニット、リモートユニット、モバイルデバイス、ワイヤレスデバイス、ワイヤレス通信デバイス、リモートデバイス、モバイル加入者局、アクセス端末、モバイル端末、ワイヤレス端末、リモート端末、ハンドセット、ユーザエージェント、モバイルクライアント、クライアント、または何らかの他の適切な用語で呼ばれることもある。
[0030] eNB106は、EPC110に接続される。EPC110は、モビリティ管理エンティティ(MME:Mobility Management Entity)112と、ホーム加入者サーバ(HSS)120と、他のMME114と、サービングゲートウェイ116と、マルチメディアブロードキャストマルチキャストサービス(MBMS)ゲートウェイ124と、ブロードキャストマルチキャストサービスセンター(BM−SC:Broadcast Multicast Service Center)126と、パケットデータネットワーク(PDN:Packet Data Network)ゲートウェイ118とを含み得る。MME112は、UE102とEPC110との間のシグナリングを処理する制御ノードである。概して、MME112は、ベアラおよび接続の管理を提供する。全てのユーザIPパケットは、サービングゲートウェイ116を通じて転送され、サービングゲートウェイ116自体は、PDNゲートウェイ118に接続される。PDNゲートウェイ118は、UEのIPアドレス割振り、ならびに他の機能を提供する。PDNゲートウェイ118およびBM−SC126は、IPサービス122に接続される。IPサービス122は、インターネット、イントラネット、IPマルチメディアサブシステム(IMS:IP Multimedia Subsystem)、PSストリーミングサービス(PSS:PS Streaming Service)、および/または他のIPサービスを含み得る。BM−SC126は、MBMSユーザサービスのプロビジョニングおよび配信のための機能を提供し得る。BM−SC126は、コンテンツプロバイダMBMS送信のためのエントリポイントとして働き得、PLMN内のMBMSベアラサービスを許可および開始するために使用され得、MBMS送信をスケジュールおよび配信するために使用され得る。MBMSゲートウェイ124は、特定のサービスをブロードキャストするマルチキャストブロードキャスト単一周波数ネットワーク(MBSFN:Multicast Broadcast Single Frequency Network)エリアに属するeNB(例えば、106、108)にMBMSトラフィックを配信するために使用され得、セッション管理(開始/停止)と、eMBMS関係の課金情報を収集することとを担当し得る。
[0031] 図2は、LTEネットワークアーキテクチャにおけるアクセスネットワーク200の一例を示す図である。この例では、アクセスネットワーク200が、いくつかのセルラー領域(セル)202に分割される。1つまたは複数のより低い電力クラスのeNB208が、セル202のうちの1つまたは複数と重なるセルラー領域210を有し得る。より低い電力クラスのeNB208は、フェムトセル(例えば、ホームeNB(HeNB:home eNB))、ピコセル、マイクロセル、またはリモートラジオヘッド(RRH:remote radio head)であり得る。マクロeNB204は各々、それぞれのセル202に割り当てられ、セル202の中の全てのUE206にEPC110へのアクセスポイントを提供するように構成される。アクセスネットワーク200のこの例では集中コントローラがないが、代替構成では集中コントローラが使用され得る。eNB204は、無線ベアラ制御、承認制御、モビリティ制御、スケジューリング、セキュリティ、およびサービングゲートウェイ116への接続性を含む、全ての無線関係機能を担当する。eNBは、1つまたは複数(例えば、3つ)のセル(セクタとも呼ばれる)をサポートし得る。「セル」という用語は、eNB、および/または特定のカバレージエリアをサービスするeNBサブシステムの、最小カバレージエリアを指すことができる。さらに、「eNB」、「基地局」、および「セル」という用語は、本明細書において同義で使用され得る。
[0032] アクセスネットワーク200によって採用される変調方式および多元接続方式は、展開されている特定の電気通信規格に応じて異なり得る。LTE適用例では、周波数分割複信(FDD)と時分割複信(TDD)の両方をサポートするために、OFDMがDL上で使用され、SC−FDMAがUL上で使用される。当業者なら以下の詳細な説明から容易に諒解するように、本明細書で提示される様々な概念は、LTE適用例に好適である。しかしながら、これらの概念は、他の変調技法および多元接続技法を採用する他の電気通信規格に容易に拡張され得る。例として、これらの概念は、エボリューションデータオプティマイズド(EV−DO:Evolution-Data Optimized)またはウルトラモバイルブロードバンド(UMB:Ultra Mobile Broadband)に拡張され得る。EV−DOおよびUMBは、CDMA2000規格ファミリーの一部として第3世代パートナーシッププロジェクト2(3GPP2)によって公表されたエアインターフェース規格であり、移動局にブロードバンドインターネットアクセスを提供するためにCDMAを採用する。これらの概念はまた、広帯域CDMA(W−CDMA(登録商標))と、TD−SCDMAなどのCDMAの他の変形形態とを採用するユニバーサル地上波無線アクセス(UTRA:Universal Terrestrial Radio Access)、TDMAを採用するモバイル通信用グローバルシステム(GSM(登録商標):Global System for Mobile Communications)、ならびに、OFDMAを採用する、発展型UTRA(E−UTRA:Evolved UTRA)、IEEE802.11(Wi−Fi(登録商標))、IEEE802.16(WiMAX(登録商標))、IEEE802.20、およびFlash−OFDMに拡張され得る。UTRA、E−UTRA、UMTS、LTE、およびGSMは、3GPP団体からの文書に記載されている。CDMA2000およびUMBは、3GPP2団体からの文書に記載されている。採用される実際のワイヤレス通信規格および多元接続技術は、特定の適用例およびシステムに課された全体的な設計制約に依存する。
[0033] eNB204は、MIMO技術をサポートする複数のアンテナを有し得る。MIMO技術の使用は、eNB204が、空間多重化と、ビームフォーミングと、送信ダイバーシティとをサポートするために、空間領域を活用することを可能にする。空間多重化は、データの異なるストリームを同じ周波数上で同時に送信するために使用され得る。データストリームは、データレートを上げるために単一のUE206に送信され得、または全体的なシステム容量を増大させるために複数のUE206に送信されされ得る。このことは、各データストリームを空間的にプリコーディングし(すなわち、振幅および位相のスケーリングを適用し)、次いで、空間的にプリコーディングされた各ストリームを、DL上で複数の送信アンテナを通じて送信することによって実現される。空間的にプリコーディングされたデータストリームは、異なる空間シグネチャとともにUE206に到達し、これにより、UE206の各々は、そのUE206に宛てられた1つまたは複数のデータストリームを復元することが可能になる。UL上では、各UE206が、空間的にプリコーディングされたデータストリームを送信し、これにより、eNB204は、空間的にプリコーディングされた各データストリームのソースを識別することが可能になる。
[0034] 空間多重化は、概して、チャネル状態が良好なときに使用される。チャネル状態があまり好ましくないとき、送信エネルギーを1つまたは複数の方向に集中させるためにビームフォーミングが使用され得る。このことは、複数のアンテナを通じた送信用にデータを空間的にプリコーディングすることによって実現され得る。セルのエッジにおいて良好なカバレージを実現するために、送信ダイバーシティと組み合わせてシングルストリームビームフォーミング送信が使用され得る。
[0035] 以下の発明を実施するための形態では、アクセスネットワークの様々な態様が、DL上でOFDMをサポートするMIMOシステムに関して説明される。OFDMは、OFDMシンボル内でいくつかのサブキャリアを介してデータを変調するスペクトル拡散技法である。サブキャリアは、正確な周波数で離間される。離間は、受信機がサブキャリアからデータを復元することを可能にする「直交性」をもたらす。時間領域では、OFDMシンボル間干渉をなくすために、各OFDMシンボルにガードインターバル(例えば、サイクリックプレフィックス)が追加され得る。ULは、高いピーク対平均電力比(PAPR)を補償するために、SC−FDMAをDFT拡散OFDM信号の形態で使用し得る。
[0036] 図3は、LTEにおけるDLフレーム構造の一例を示す図300である。フレーム(10ms)は、等しいサイズの10個のサブフレームに分割され得る。各サブフレームは、2つの連続するタイムスロットを含み得る。2つのタイムスロットを表すためにリソースグリッドが使用され得、各タイムスロットはリソースブロックを含む。リソースグリッドは、複数のリソース要素に分割される。LTEでは、ノーマルサイクリックプレフィックスの場合、リソースブロックが、合計84個のリソース要素に対して、周波数領域における12個の連続するサブキャリアと、時間領域における7個の連続するOFDMシンボルとを含む。拡張サイクリックプレフィックスの場合、リソースブロックは、合計72個のリソース要素に対して、周波数領域における12個の連続するサブキャリアと、時間領域における6個の連続するOFDMシンボルとを含む。R302、304として示されるリソース要素のいくつかは、DL基準信号(DL−RS:DL reference signal)を含む。DL−RSは、セル固有RS(CRS)(共通RSと呼ばれることもある)302と、UE固有RS(UE−RS)304とを含む。UE−RS304は、対応する物理DL共有チャネル(PDSCH)がマッピングされるリソースブロック上で送信される。各リソース要素によって搬送されるビット数は、変調方式に依存する。従って、UEが受信するリソースブロックが多いほど、また変調方式が高いほど、UEのためのデータレートは高くなる。
[0037] 図4は、LTEにおけるULフレーム構造の一例を示す図400である。UL用のために利用可能なリソースブロックは、データセクションおよび制御セクションに区分され得る。制御セクションは、システム帯域幅の2つのエッジにおいて形成され得、構成可能なサイズを有し得る。制御セクションの中のリソースブロックは、制御情報の送信用にUEに割り当てられ得る。データセクションは、制御セクションの中に含まれない全てのリソースブロックを含み得る。ULフレーム構造は、単一のUEがデータセクションの中の連続サブキャリアの全てを割り当てられることを可能にし得る、連続サブキャリアを含むデータセクションをもたらす。
[0038] UEは、制御情報をeNBへ送信するために、制御セクションの中のリソースブロック410a、410bを割り当てられ得る。UEはまた、データをeNBへ送信するために、データセクションの中のリソースブロック420a、420bを割り当てられ得る。UEは、制御セクションの中に割り当てられたリソースブロック上の物理UL制御チャネル(PUCCH)において制御情報を送信し得る。UEは、データセクションの中に割り当てられたリソースブロック上の物理UL共有チャネル(PUSCH)においてデータまたはデータと制御情報の両方を送信し得る。UL送信は、サブフレームの両方のスロットに広がり得、周波数にわたってホッピングし得る。
[0039] 初期システムアクセスを行い、物理ランダムアクセスチャネル(PRACH)430の中でのUL同期を実現するために、リソースブロックのセットが使用され得る。PRACH430は、ランダム系列を搬送し、いかなるULデータ/シグナリングも搬送できない。各ランダムアクセスプリアンブルは、6つの連続するリソースブロックに対応する帯域幅を占有する。開始周波数は、ネットワークによって指定される。すなわち、ランダムアクセスプリアンブルの送信は、ある時間リソースおよび周波数リソースに制限される。PRACHの場合、周波数ホッピングはない。PRACH試行は、単一のサブフレーム(1ms)において、または少数の連続サブフレームのシーケンスにおいて搬送され、UEは、フレーム(10ms)当たり単一のPRACH試行を行うことができる。
[0040] 図5は、LTEにおけるユーザプレーンおよび制御プレーンのための無線プロトコルアーキテクチャの一例を示す図500である。UEおよびeNBのための無線プロトコルアーキテクチャは、3つのレイヤ、すなわち、レイヤ1、レイヤ2、およびレイヤ3を用いて示される。レイヤ1(L1レイヤ)は最下位レイヤであり、様々な物理レイヤ信号処理機能を実施する。L1レイヤは、本明細書において物理レイヤ506と呼ばれる。レイヤ2(L2レイヤ)508は、物理レイヤ506の上にあり、物理レイヤ506を介したUEとeNBとの間のリンクを担当する。
[0041] ユーザプレーンでは、L2レイヤ508が、ネットワーク側でのeNBにおいて終端される、媒体アクセス制御(MAC)サブレイヤ510と、無線リンク制御(RLC:radio link control)サブレイヤ512と、パケットデータコンバージェンスプロトコル(PDCP)514サブレイヤとを含む。図示されていないが、UEは、ネットワーク側でのPDNゲートウェイ118において終端されるネットワークレイヤ(例えば、IPレイヤ)と、接続の他端(例えば、遠端UE、サーバなど)において終端されるアプリケーションレイヤとを含む、L2レイヤ508の上のいくつかの上位レイヤを有し得る。
[0042] PDCPサブレイヤ514は、異なる無線ベアラと論理チャネルとの間の多重化を提供する。PDCPサブレイヤ514はまた、無線送信オーバーヘッドを低減するための上位レイヤデータパケットに対するヘッダ圧縮と、データパケットを暗号化することによるセキュリティと、UEに対するeNB間のハンドオーバサポートとを提供する。RLCサブレイヤ512は、上位レイヤデータパケットのセグメント化および再アセンブリと、紛失データパケットの再送信と、ハイブリッド自動再送要求(HARQ)に起因して順が狂った受信を補正するためのデータパケットの並べ替えとを行う。MACサブレイヤ510は、論理チャネルとトランスポートチャネルとの間の多重化を提供する。MACサブレイヤ510はまた、1つのセルの中の様々な無線リソース(例えば、リソースブロック)をUEの間で割り振ることを担当する。MACサブレイヤ510はまた、HARQ演算を担当する。
[0043] 制御プレーンにおいて、UEおよびeNBのための無線プロトコルアーキテクチャは、制御プレーンのためのヘッダ圧縮機能がないことを除いて、物理レイヤ506およびL2レイヤ508に対して実質的に同じである。制御プレーンはまた、レイヤ3(L3レイヤ)の中に無線リソース制御(RRC)サブレイヤ516を含む。RRCサブレイヤ516は、無線リソース(例えば、無線ベアラ)を取得すること、およびeNBとUEとの間のRRCシグナリングを使用して下位レイヤを構成することを担当する。
[0044] 図6は、アクセスネットワークの中のUE650と通信しているeNB610のブロック図である。DLでは、コアネットワークからの上位レイヤパケットが、コントローラ/プロセッサ675に提供される。コントローラ/プロセッサ675は、L2レイヤの機能を実施する。DLでは、コントローラ/プロセッサ675が、ヘッダ圧縮と、暗号化と、パケットのセグメント化および並べ替えと、論理チャネルとトランスポートチャネルとの間の多重化と、様々な優先度メトリックに基づくUE650への無線リソース割振りとを提供する。コントローラ/プロセッサ675はまた、HARQ演算と、紛失パケットの再送信と、UE650へのシグナリングとを担当する。
[0045] 送信(TX)プロセッサ616は、L1レイヤ(すなわち、物理レイヤ)のための様々な信号処理機能を実施する。信号処理機能は、UE650における前方誤り訂正(FEC)を容易にするための、コーディングとインターリービングと、様々な変調方式(例えば、2位相シフトキーイング(BPSK)、4位相シフトキーイング(QPSK)、M位相シフトキーイング(M−PSK)、多値直交振幅変調(M−QAM))に基づく信号コンスタレーションへのマッピングとを含む。コーディングおよび変調されたシンボルは、次いで、並列ストリームに分割される。各ストリームは、次いで、時間領域OFDMシンボルストリームを搬送する物理チャネルを生成するために、OFDMサブキャリアにマッピングされ、時間領域および/または周波数領域において基準信号(例えば、パイロット)と多重化され、次いで、逆高速フーリエ変換(IFFT)を使用して互いに合成される。OFDMストリームは、複数の空間ストリームを生成するために空間的にプリコーディングされる。チャネル推定器674からのチャネル推定値は、コーディングおよび変調方式を決定するために、ならびに空間処理のために使用され得る。チャネル推定値は、UE650によって送信された基準信号および/またはチャネル状態フィードバックから導出され得る。各空間ストリームは、次いで、別個の送信機618TXを介して異なるアンテナ620に供給され得る。各送信機618TXは、送信のためにそれぞれの空間ストリームを用いてRFキャリアを変調し得る。
[0046] UE650において、各受信機654RXは、それのそれぞれのアンテナ652を通じて信号を受信する。各受信機654RXは、RFキャリア上に変調された情報を復元し、受信(RX)プロセッサ656に情報を提供する。RXプロセッサ656は、L1レイヤの様々な信号処理機能を実施する。RXプロセッサ656は、UE650に宛てられた任意の空間ストリームを復元するために、情報に対して空間処理を行い得る。複数の空間ストリームは、UE650に宛てられている場合、RXプロセッサ656によって単一のOFDMシンボルストリームに合成され得る。RXプロセッサ656は、次いで、高速フーリエ変換(FFT)を使用してOFDMシンボルストリームを時間領域から周波数領域に変換する。周波数領域信号は、OFDM信号のサブキャリアごとに別個のOFDMシンボルストリームを備える。各サブキャリア上のシンボル、および基準信号は、eNB610によって送信された、可能性が最も高い信号コンスタレーションポイントを決定することによって復元および復調される。これら軟判定(soft decisions)は、チャネル推定器658によって計算されるチャネル推定値に基づき得る。軟判定は、次いで、物理チャネル上でeNB610によって最初に送信されたデータと制御信号とを復元するために、復号およびデインターリーブされる。データおよび制御信号は、次いで、コントローラ/プロセッサ659に提供される。
[0047] コントローラ/プロセッサ659は、L2レイヤを実施する。コントローラ/プロセッサは、プログラムコードとデータとを記憶するメモリ660に関連付けられ得る。メモリ660は、コンピュータ可読媒体と呼ばれることがある。ULでは、コントローラ/プロセッサ659が、コアネットワークからの上位レイヤパケットを復元するために、トランスポートチャネルと論理チャネルとの間の多重分離と、パケットの再アセンブリと、暗号解読と、ヘッダ解凍と、制御信号処理とを提供する。上位レイヤパケットは、次いで、L2レイヤの上の全てのプロトコルレイヤを表す、データシンク662に提供される。様々な制御信号も、L3処理のためにデータシンク662に提供され得る。コントローラ/プロセッサ659はまた、HARQ演算をサポートするために、肯定応答(ACK)および/または否定応答(NACK)プロトコルを使用する誤り検出を担当する。
[0048] ULでは、データソース667が、コントローラ/プロセッサ659に上位レイヤパケットを提供するために使用される。データソース667は、L2レイヤの上の全てのプロトコルレイヤを表す。eNB610によるDL送信に関して説明された機能と同様に、コントローラ/プロセッサ659は、ヘッダ圧縮と、暗号化と、パケットのセグメント化および並べ替えと、eNB610による無線リソース割振りに基づく論理チャネルとトランスポートチャネルとの間の多重化とを提供することによって、ユーザプレーンおよび制御プレーンのためのL2レイヤを実施する。コントローラ/プロセッサ659はまた、HARQ演算と、紛失パケットの再送信と、eNB610へのシグナリングとを担当する。
[0049] eNB610によって送信された基準信号またはフィードバックからの、チャネル推定器658によって導出されるチャネル推定値は、適切なコーディングおよび変調方式を選択するために、また空間処理を容易にするために、TXプロセッサ668によって使用され得る。TXプロセッサ668によって生成された空間ストリームは、別個の送信機654TXを介して異なるアンテナ652に供給され得る。各送信機654TXは、送信のためにそれぞれの空間ストリームを用いてRFキャリアを変調し得る。
[0050] UL送信は、UE650における受信機機能に関して説明された方法と同様の方法で、eNB610において処理される。各受信機618RXは、それのそれぞれのアンテナ620を通じて信号を受信する。各受信機618RXは、RFキャリア上に変調された情報を復元し、情報をRXプロセッサ670に提供する。RXプロセッサ670は、L1レイヤを実施し得る。
[0051] コントローラ/プロセッサ675は、L2レイヤを実施する。コントローラ/プロセッサ675は、プログラムコードとデータとを記憶するメモリ676に関連付けられ得る。メモリ676は、コンピュータ可読媒体と呼ばれることがある。ULでは、コントローラ/プロセッサ675が、UE650からの上位レイヤパケットを復元するために、トランスポートチャネルと論理チャネルとの間の多重分離と、パケットの再アセンブリと、暗号解読と、ヘッダ解凍と、制御信号処理とを提供する。コントローラ/プロセッサ675からの上位レイヤパケットは、コアネットワークに提供され得る。コントローラ/プロセッサ675はまた、HARQ演算をサポートするために、ACKおよび/またはNACKプロトコルを使用する誤り検出を担当する。
[0052] 図7は、デバイス間通信システム700の図である。デバイス間通信システム700は、複数のワイヤレスデバイス704、706、708、710を含む。デバイス間通信システム700は、例えば、ワイヤレスワイドエリアネットワーク(WWAN)などのセルラー通信システムと重なることがある。ワイヤレスデバイス704、706、708、710の一部は、DL/UL WWANスペクトルを使用するデバイス間通信において互いに通信し得、一部は基地局702と通信し得、一部は両方を行い得る。例えば、図7に示すように、ワイヤレスデバイス708、710がデバイス間通信中であり、ワイヤレスデバイス704、706がデバイス間通信中である。ワイヤレスデバイス704、706はまた、基地局702と通信している。
[0053] 以下で説明する例示的な方法および装置は、例えば、FlashLinQ、WiMedia、Bluetooth(登録商標)、ZigBee(登録商標)、またはIEEE802.11規格に基づくWi−Fiに基づくワイヤレスデバイス間通信システムなどの、様々なワイヤレスデバイス間通信システムのいずれにも適用可能である。説明を簡略化するために、例示的な方法および装置は、LTEのコンテキスト内で説明される。しかしながら、例示的な方法および装置が、様々な他のワイヤレスデバイス間通信システムに、より一般的に適用可能であることを当業者なら理解されよう。
[0054] 例示的な実施形態は、概して、UEが別のUEと通信することを可能にする(例えば、UEがLTEバンドを介して何かを告知することを可能にし、その何かが他のUEによって受信される)ための方法と装置とを提供する。
[0055] 図8は、D2D発見通信、それらの機能、およびそれらの間の様々なインターフェースなどの、D2D通信に関係するUE802のスタックを構成する様々なレイヤを示すブロック図800である。UE802のスタックの様々なレイヤは、ProSe(近接度ベースサービス)プロトコル804と、非アクセス層(NAS)レイヤ806と、RRCレイヤ/サブレイヤ808と、MACレイヤ/サブレイヤ810とを含む。様々な他のレイヤ/サブレイヤが、例示的な実施形態のUE802のスタックの中に存在することがある。しかしながら、この詳細な説明は、ProSeプロトコル804、NASレイヤ806、RRCレイヤ808、およびMACレイヤ810、ならびにレイヤのうちの異なるものの間の様々な対話(interaction)チャネルに焦点を当てる。
[0056] ProSeプロトコル804の下は、UE802の状態遷移を(例えば、「アイドル状態」から「接続状態」へ)制御できるNASレイヤ806である。しかしながら、NASレイヤ806は、通常、D2D動作に気づいていない。さらに、NASレイヤ806は、他のアプリケーションによって共有されるとともに影響を及ぼされる。
[0057] NASレイヤ806の下は、D2D無線リソース割振りのための要件に関する情報を有するRRCレイヤ808であり、RRCレイヤ808はまた、UE802の現在の状態に関する情報を有するが、UE状態の遷移を制御することはできない。RRCレイヤ808は、UE802の無線リソースを制御でき、ネットワークの基地局/eNB812と通信できる。従って、無線リソース割振りは、RRCレイヤ808のみに対して利用可能であり、RRCレイヤ808のみによって制御される。さらに、無線リソース割振りは、NASレイヤ806に、またはProSeプロトコル804に、すぐには知られない場合がある。
[0058] 最後に、RRCレイヤ808の下は、UE802用の送信スケジューリングを担当するMACレイヤ810である。すなわち、MACレイヤ810が、事実上、UE802によって送信されるべきいくつかのメッセージがオーバージエアへ進むときを決定し、それはProSeプロトコル804と通信することによってスケジュールされ得る。また、RRCレイヤ808は、以下で説明するように、ネットワークによって提供されるシステム情報に従って、および他のイベントに従って、MACレイヤ810のMAC無線リソースを制御できる。
[0059] 実施形態は、利用可能なD2Dリソースに関する情報、および一般的なUEの接続状態(すなわち、接続済みまたはアイドル)に関する情報が、前記UEのスタックのうちの選ばれたレイヤだけに知られているという事実に対処する。さらに、ある状態から次の状態へ(例えば、アイドル状態から接続状態へ)前記UEを制御するための、または遷移させるための能力は、1つまたは複数のレイヤのみによって処理されることがある。
[0060] 例えば、一般的なUEの上位レイヤに対応する制御プロトコル(例えば、ProSeプロトコル)は、D2D送信に対応するタイミングおよび情報の制約に気づいているが、下位レイヤ(RRCレイヤなどの)に対応する情報への直接のアクセスを有しない。
[0061] 例示的な実施形態では、いくつかの状況の下で、ProSeプロトコル804が、NASレイヤ806と(例えば、インターフェース822を介して)、RRCレイヤ808と(例えば、インターフェース821を介して)、およびMACレイヤ810と(例えば、インターフェース823を介して)情報を交換し得、RRCレイヤ808は、NASレイヤ806と(例えば、インターフェース822’を介して)通信し得る。さらに、RRCレイヤ808は、基地局/eNB812と通信し得る。
[0062] LTEダイレクト(LTE−D)発見などの、D2D通信のためのUE802に対する無線リソース割振りは、eNB812が接続されているネットワークによって制御され得る。UE802が(一緒にD2D発見通信に関与しようとUE802が求める)別のUEと直接通信できる前に、UE802は、ネットワークからeNB812経由で許可を取得し得る。UE802がネットワークから許可を受信すると、UE802は、それの所期の通信に対応するコードを、オーバージエアで他のUEへ送り得る。ピア発見リソースと呼ばれることがあるD2Dリソースを使用することによって、UE802は、他のUEによって発見され得、その後、D2D通信リソースと呼ばれることがあるD2Dリソースを使用して、他のUEと直接通信できる。LTE−D発見は、1)システム情報(例えば、システム情報ブロック(SIB:System Information Block)に含まれる情報)がタイプ1(すなわち、共通の)リソースを示す場合、2)ネットワークがLTE−Dをサポートすることだけをシステム情報が示す場合、および3)D2Dのためのシステム情報が提供されない場合、という3つの主なユースケースを考慮する。ユースケースおよびUEの接続状態/アイドル状態に応じて、UEは、リソース(例えば、タイプ2(割り振られる)リソースおよび/またはタイプ1(共通の)リソース) 要求するRRCメッセージを送ることもあり、または送らないこともある。以下は、LTE−D発見についての3つの主なユースケース(1、2、および3)、およびそれらの下位区分(a,b,およびc)である。
[0063] 事例1a)D2D通信のためのシステム情報(例えば、SIB)がタイプ1リソースを示すとき(例えば、共通ピア発見リソースまたはD2D通信リソースなどのD2Dリソースのセットが、eNB812経由でリソースプールから利用可能であることをシステム情報が示すとき)、およびUE802がアイドル状態(例えば、RRCアイドル状態)にあるとき、UE802は、示されたタイプ1リソースをD2D発見通信のために使用でき、RRCメッセージは必要とされない。すなわち、UE802がアイドル状態にあるとき、UE802は、eNB812によりブロードキャストされた情報(例えば、リソース情報)を利用でき、eNB812との追加の通信なしに無線リソース管理を行うことが可能である。
[0064] 事例1b)D2D通信のためのSIBがタイプ1リソースを示し、UE802が接続状態(例えば、RRC接続状態)にあるとき、UE802は、UEがタイプ1リソースを使用するのか、それともタイプ2リソースを使用するのかにかかわらず、リソース割振りのためにRRCメッセージをeNB812へ送る。すなわち、UE802が接続状態にあるとき、UE802は、UE802がD2D発見通信を行うことを可能にするための、許可、ならびにリソース割振りに関する情報を、eNB812経由でネットワークに求める。
[0065] 事例1c)D2D通信のためのSIBがタイプ1リソースを示し、UE802がピア発見のために、またはD2D通信のためにタイプ1リソースを利用しながらアイドル状態から接続状態へ遷移するとき、UE802は、現在のタイプ1リソースを使用する送信を終えて、リソース割振りを求めるRRCメッセージを送り得、次いで、eNB812によって示される割り振られたリソースを用いて送信を再開し得る。
[0066] 事例2a)D2D通信のためのSIBが、ネットワークがLTE−Dをサポートすること(例えば、ネットワークがピア発見をサポートすること、または発見がサポートされること)だけを示すが、いかなるタイプ1リソース情報も示さず、UE802がアイドル状態にあるとき、UE802は、接続状態へ遷移し得、次いで、ネットワークにリソースを要求するためのRRCメッセージを送り得る。
[0067] 事例2b)D2D通信のためのSIBが、D2D通信およびD2D発見がサポートされることを示すが、いかなるリソース情報も示さず、UE802が接続状態にあるとき、UE802は、リソース割振りを求めるRRCメッセージを送る。
[0068] 事例2c)D2D通信のためのSIBが、D2D通信およびD2D発見がサポートされることを示すが、いかなるリソース情報も示さず、UE802がネットワークとのそれの接続を失っているか、またはUE802に許可されているリソースをeNB812が取り消すとき、もはやUE802はリソースを使用し続けることができない。
[0069] 事例3)D2DのためのSIBが提供されないとき(例えば、UE802が、レガシーeNBによってサービスされ、LTE−Dをサポートするネットワークに接続されていないとき)、UE802は、D2D送信を行わなず、MACレイヤ810へコードを送るのをやめ得る。すなわち、D2D発見またはD2D通信をサポートしないネットワークにeNB812が接続されているとき、UE802は、他のUEとのD2D通信に関与し得ない。
[0070] 上記の事例の各々(1a、1b、1c、2a、2b、2c、および3)は、図9〜図13のうちの1つに対応し、例示的な実施形態に関して以下でさらに詳細に説明される。
[0071] 例示的な実施形態は、UE802が、上記で略述した同じ方式または同じ事例において依然として動作しながら、LTE D2D通信またはLTE D2D発見のための無線リソース割振りの方法を行うための構成を提供する。すなわち、例示的な実施形態は、様々なシナリオの下で、LTE−Dネットワークに接続されているUEへのリソース割振りを管理するための方法および装置を提供する。
[0072] 例えば、適切なD2Dリソース管理をサポートする目的で、例示的な実施形態は、RRCレイヤ808がNASレイヤ806またはProSeプロトコル804などの上位レイヤからトリガを受信することを可能にし、トリガは、RRCレイヤ808に、「D2Dリソース要求」メッセージをeNB812へ送らせる。このシナリオは、事例1b、1c、2a、および2bを参照しながら説明する。
[0073] さらに、例示的な実施形態は、RRCレイヤ808がProSeプロトコル804にいくつかの状態変化イベントを示すことまたは通信することを可能にし、それによって、ProSeプロトコル804が、どんなアクションが行われる必要があるのかを決定することを可能にする。このシナリオは、事例2cおよび3を参照しながら説明する。
[0074] さらに、例示的な実施形態は、RRCメッセージを送ること(例えば、RRCレイヤ808によってD2Dリソース要求メッセージを送ること)が、常にUE802の状態遷移と同時に起こるとは限らないことを考慮に入れる。そのような事例では、NASレイヤ806を伴うことが、いかなる追加の利点ももたらさない場合があり、UE802の動作の効率を低減する場合がある。このシナリオは、事例1bおよび2bを参照しながら説明する。
[0075] 再び図8を参照すると、例示的な実施形態は、UE802におけるProSeプロトコル804とRRCレイヤ808との間にインターフェース、すなわち対話チャネル821を設けることによって、LTE D2D通信用のリソースの効率的なUE管理を提供する。対話チャネル821は、RRCレイヤ808がProSeプロトコル804に情報を提供することを可能にし、ProSeプロトコル804は、情報に基づいて(またNASレイヤ806の接続状態/アイドル状態に基づいて)UE802の関係する状態遷移を処理し得る。
[0076] 本実施形態で、RRCレイヤ808によってProSeプロトコル804に提供される情報は、1)eNB812のネットワークがLTE−D(D2D)をサポートするかどうか、および2)RRCレイヤ808がeNB812からリソースを取得することを可能にするために、RRCレイヤ808がUE802の他のレイヤによるいくつかのアクションを必要とするかどうか、に対応する。
[0077] 上記で説明した事例の各々に対して、情報は、RRCレイヤ808によってProSeプロトコル804へ、1つまたは複数のフラグを使用して通信され得、それによって、比較的少量の情報を通信しながらRRCレイヤ808がUE802のいくつかの状態を示すことを可能にする。本実施形態で、RRCレイヤ808は、2つのフラグを設定することによってProSeプロトコル804へ上記の情報を通信する。この発明を実施するための形態において、これらのフラグは、「トリガ必要」フラグおよび「発見サポート」フラグと呼ばれることがある。これらの2つのフラグは、RRCレイヤ808によって、SIBの、RRCレイヤの読取り値に従って設定される。
[0078] 図を参照して、フラグの3つの異なる構成を説明する。第1に、発見サポートフラグがセットされ(例えば、フラグに対応する値が1に等しい)、トリガ必要フラグがアンセット(unset)される(例えば、フラグに対応する値が0に等しい)(例えば、事例1a)。第2に、発見サポートフラグとトリガ必要フラグの両方がセットされる(例えば、事例1b、1c、2a、2b、および2c)。第3に、発見サポートフラグがアンセットされる(トリガ必要フラグはセットされ得、またはアンセットされされ得る)(例えば、事例3)。「発見サポートフラグ」という用語が本明細書全体にわたって、また図面において使用されるが、他の構成で、「発見サポートフラグ」は、D2D通信がネットワークによってサポートされることを示す「D2D通信サポートフラグ」であり得る。
[0079] フラグおよびUE802接続状態に基づいて、ProSeプロトコル804は、以下で説明するように、(例えば、NASレイヤ806をトリガすることによって)状態遷移を引き起こし得、(例えば、リソースを求める要求を送ることをRRCレイヤ808に命令するように)RRCレイヤ808をトリガし得、および/またはコマンドをMACレイヤ810へ送り得る。
[0080] 図9は、UEレイヤとeNBとの間の例示的なメッセージングを示す第1の図900である。図9を参照して、上述の事例1aを説明する。本事例では、eNB812のネットワークがLTEをサポートし、UE802がアイドル状態にある。さらに、タイプ1リソースが利用可能であることをSIBが示し、それによって、D2D通信(例えば、ピア発見)のための所望のリソースをそこから選択するために、無線リソースの共通プールがUE802にとって利用可能であることを示す。
[0081] 従って、RRCレイヤ808が発見サポートフラグをセットし(例えば、発見サポートフラグが1に設定される)、トリガ必要フラグがアンセットされる(例えば、トリガ必要フラグが0に設定される)。この情報は、例示的な実施形態によるProSeプロトコル804によって見られ得る。さらに、フラグは、ProSeプロトコル804によって使用される必要がない情報を通信することなく、RRCレイヤ808が有用な情報をProSeプロトコル804へ通信することを可能にする(利用可能なリソースがタイプ1リソースであるのか、それともタイプ2リソースであるのかを示す情報などの)。
[0082] さらに、SIBに含まれる情報に従って、D2DのためのMAC無線リソースがMACレイヤ810の中に、RRCレイヤ808によってタイプ1リソースに従って構成される。RRCレイヤ808がMAC無線リソースを構成すると、ProSeプロトコル804は、ProSeプロトコル804によって取得された1つまたは複数のProSeアプリケーションコード(ProSe Appコード)に従って送信機会(TxOP)時間を取得するために、インターフェース、すなわち対話チャネル823(図8参照)を介してMACレイヤ810と通信する。対話チャネル823は、ProSeプロトコル804が問合せをMACレイヤ810へ送ることを可能にし、その結果、ProSe Appコードに対応する所期のLTE−Dメッセージを送り出すべき時をProSeプロトコル804が知ることができ、UE802がそうした時を協調させることができる。
[0083] 本事例では、メッセージのUE802からの配送のためにUE802の状態遷移が必要とされないので、ProSeプロトコル804は、TxOPをMACレイヤ810から成功裡に直接取得可能で、UE802による送信を可能にできる。すなわち、たとえUE802がアイドル状態にあっても、MACレイヤ810の無線リソースが構成されるので、またリソースがタイプ1リソースとして示されるので、UE802の状態遷移が、D2D通信のために、またはD2D発見通信のために必要とされない。
[0084] ProSeプロトコル804がMACレイヤ810と連絡を取ると、MACレイヤ810が様々な所期のメッセージに様々な時間を割り当てる必要があるので、MACレイヤ810は、送信時間に関してProSeプロトコル804へどんな情報を送り返すべきか(例えば、どんなTxOP時間を送り返すべきか)を決定する。すなわち、ProSeプロトコル804は、ProSeプロトコル804がProSe Appコードを送信できる将来の時間を決定するために、MACレイヤ810と通信する。従って、MACレイヤ810は、選ばれたTxOP時間をProSeプロトコル804へ送り返し、その結果、ProSeプロトコル804がメッセージ(例えば、ProSe Appコードおよびメッセージインテグリティチェックサム(MIC))をTxOP時間に従って配送できる特定の時間を、MACレイヤ810が格下げできる。
[0085] 本事例では、ProSeプロトコル804が、対応する単一のProSe Appコードに対して単一のTxOP時間を取得するが、以下で説明するように、UE802が、対応する複数のそれぞれのTxOP時間を有する複数のProSe Appコードを考慮に入れることに留意されたい。
[0086] 有効なTxOP時間をMACレイヤ810から受信すると、以下でさらに説明するように、ProSeプロトコル804は、NASレイヤ806またはRRCレイヤ808をトリガするべきかどうかを決定する。この場合、どちらのトリガも必要とされないので、ProSeプロトコル804は、対応するTxOP時間に基づいて、ProSeアプリケーションコードごとにメッセージインテグリティチェックサム(MIC)(例えば、セキュリティインテグレーション検査結果)を計算する。その後、ProSeプロトコル804は、MACレイヤ810によって通信された、要求され取得されたTxOP時間に従ってProSe Appコードを送り、UE802が、ProSe Appコードに対応するD2D通信メッセージ(例えば、D2D発見通信メッセージ)を送る。
[0087] 引き続き図9を参照して、上述の事例1bを説明する。本事例では、eNB812のネットワークがやはりLTE−Dをサポートし、タイプ1リソースが利用可能であることをSIBが示すが、UE802は、接続状態へ遷移している。
[0088] 本事例では、RRCレイヤ808がアイドル状態(例えば、事例1aにおける)から接続状態へ遷移しているので、MAC無線リソースは、RRCレイヤ808によってMACレイヤ810から除去される。すなわち、RRCレイヤ808は、発見サポートフラグとトリガ必要フラグの両方をセットし(例えば、発見サポートフラグおよびトリガ必要フラグが両方とも1に設定され)、トリガ必要フラグが新たにセットされるので、RRCレイヤ808は、D2D無線リソースをMACレイヤ810から除去する。再び、フラグによって示される情報が、ProSeプロトコル804によって見られ得る。
[0089] 前の事例とは異なり、ProSeプロトコル804が、MACレイヤ810とのそれの通信を介してProSeプロトコル804によって前に取得された1つまたは複数のProSe Appコードに従って、TxOP時間を取得しようと試みるとき、TxOP時間を取得するための試行は失敗する。発見無線リソースがMACレイヤ810の中に構成されていないので、MACレイヤ810は、いくつかのアクションが行われる必要があることをProSeプロトコル804に示すために、「ヌルTxOP時間」を使用する。すなわち、MACレイヤ810は、送信時間が利用可能でないことを示すために、「ヌル」または何らかの他のインジケータをProSeプロトコル804へ送り、それによって、発見期間の中で無線リソースが利用可能でないことを示すことによって、何らかのアクションが行われる必要があることをProSeプロトコル804に示す。
[0090] 再び、ProSeプロトコル804は、NASレイヤ806またはRRCレイヤ808をトリガするべきかどうかを決定する。ここで、発見サポートフラグおよびトリガ必要フラグが両方とも1に設定されているので、またUE802が接続状態へ遷移しているので、UE802の状態遷移は必要とされない。従って、ProSeプロトコル804は、トリガをRRCレイヤ808へ送ることを決定する。
[0091] より詳細には、TxOP時間を取得することに失敗することの結果として、ProSeプロトコル804は、RRCレイヤ808によって設定された上述の2つのフラグを検査する。LTE−Dがサポートされるがアクションが必要とされることをRRCレイヤ808が示すとき(例えば、発見サポートフラグおよびトリガ必要フラグが両方とも1に設定されているとき)、ProSeプロトコル804は検査して、UE802が接続状態にあるのか、それともアイドル状態にあるのかを決定する。SIBが利用可能なリソース(例えば、タイプ1リソースまたはタイプ2リソース)として何を示すのかをProSeプロトコル804が知っている必要がないので、その情報は、ProSeプロトコル804へ(例えば、RRCレイヤ808のフラグから)通信される必要がない。すなわち、TxOP時間を取得するための失敗した試行に続いて、ProSeプロトコル804は、UE802の状態(例えば、接続状態またはアイドル状態)を決定するべきであることを知るために、トリガ必要フラグが1に設定されていることだけを知っていればよい。本事例では、UE802が接続状態にあるので(例えば、UE802のNASレイヤ806が接続状態にあるので)、状態遷移は必要とされず、ProSeプロトコル804は、リソースを求める要求(例えば、RRC D2Dリソース要求)をeNB812へ送るようにRRCレイヤ808に告げる。
[0092] トリガ(例えば、D2D要求のためのトリガ)をProSeプロトコル804から受信すると、RRCレイヤ808は、要求(例えば、RRC D2Dリソース要求)をeNB812へ送る。その後、eNB812は、応答(例えば、RRC D2Dリソース応答)をRRCレイヤ808へ送り返すことによって要求に応答して、RRCレイヤ808に応答する。従って、説明されるRRC D2Dメッセージ交換を使用することによって、eNB812は、ネットワークトラフィック(例えば、対象のUE802と、ネットワークに接続するために同じeNB812を使用する様々な他のUEとを伴うトラフィック)をより良くスケジュールできる。
[0093] 次いで、RRCレイヤ808は、eNB812から受信された応答に含まれる情報に従って、MACレイヤ810においてMAC D2D無線リソースを構成する。すなわち、RRCレイヤ808とeNB812との間のメッセージ交換の結果として取得された情報に従って、D2DのためのMAC D2D無線リソースが設定される。次いで、MACレイヤ810は、D2D送信のためのTxOP時間をProSeプロトコル804に提供できる。
[0094] 前に説明した事例1aと同様に、また図9に示すように、ProSeプロトコル804がTxOP時間を成功裡に取得すると、ProSeプロトコル804は、MICを計算し、その後、取得されたTxOP時間に従って、対象のProSe Appコードおよび計算されたMICに対応するコマンドをMACレイヤ810へ送る。その後、MACレイヤ810は、受信されたコマンドに従ってD2D送信を開始する。
[0095] 図10は、UEレイヤとeNBとの間の例示的なメッセージングを示す第2の図1000である。以下に図10を参照して、上述の事例1cを説明する。本事例では、UE802が、アイドル状態から接続状態へ遷移する。再び、eNB812のネットワークがLTE−Dをサポートし、タイプ1リソースが利用可能であることをSIBが示す。
[0096] 従って、RRCレイヤ808は、MACレイヤ810の中のD2D無線リソースをヌルに設定する。すなわち、MAC D2D無線リソースがRRCレイヤ808によってMACレイヤ810から除去され、その結果、RRCレイヤ808とeNB812との間の、前に説明したRRCメッセージ交換に含まれる情報に従って、RRCレイヤ808がMAC D2D無線リソースを後で設定できる。さらに、RRCレイヤ808は、ProSeプロトコル804によって見られ得る情報である発見サポートフラグとトリガ必要フラグの両方をセットする。
[0097] 本事例では、RRCレイヤ808がMACレイヤ810からMAC無線リソースを除去したことにProSeプロトコル804が気づいていないので、ProSeプロトコル804は、取得されたProSe Appコードに基づいてMICを計算し、ProSe Appコードおよび計算されたMICに従ってコマンドをMACレイヤ810へ送る。事例1aとは異なり、MACレイヤ810が、RRCレイヤ808によって前に除去されたそれのRRC無線リソースを有していて、再構成されていないので、ProSeプロトコル804によって送られるコマンドは、MACレイヤ810によって誤って受信される。
[0098] 従って、本事例で、MACレイヤ810は、MACレイヤ810にとって利用可能なD2D無線リソースがないことをProSeプロトコル804に通知するために、エラー通知をProSeプロトコル804へ送り返すか、または、代替として、ProSeプロトコル804は、TxOP時間をMACレイヤ810から取得するためのそれの試行に単に失敗する(例えば、設計の選択が、MACレイヤ810がエラー通知をProSeプロトコル804へ送るための能力を取り除く場合)。
[0099] エラー通知をMACレイヤ810から受信すると(または、TxOP時間を取得することに失敗すると)、トリガをRRCレイヤ808へ送るべきかどうかを(例えば、図9、事例1b)、またはアイドル状態から接続状態へのUE802の状態遷移を開始するべきかどうかを(例えば、図11に関して以下でさらに説明される事例2a)、ProSeプロトコル804が決定できるように、ProSeプロトコル804は、UE802が接続状態にあるのか、それともアイドル状態にあるのかを決定する。
[00100] 本事例で、ProSeプロトコル804は、UE802がアイドル状態にあることを、NASレイヤ806と通信することによって認識する。UEのNASレイヤ806がアイドル状態にあるので、ProSeプロトコル804は、「レガシーメッセージ」または「サービス要求」と呼ばれるものを使用して、UE802の状態遷移をトリガしようと試みる。レガシーメッセージ/サービス要求を使用することによって、ProSeプロトコル804はNASレイヤ806と通信し、NASレイヤ806は、UE802を接続状態へ遷移させ(ECM_CONNECTED)、状態遷移が起こったことをProSeプロトコル804に示す。
[00101] その後、また図9に示す事例1bと同様に、ProSeプロトコル804は、D2D要求のためのトリガをRRCレイヤ808へ送り、それによって、RRCレイヤ808にリソースをネットワークからeNB812を介して取り出すように命令する。トリガを受信すると、RRCレイヤ808は、要求メッセージ(例えば、RRC D2Dリソース要求メッセージ)をeNB812へ送り、eNB812は、応答メッセージ(例えば、RRC D2Dリソース応答メッセージ)をRRCレイヤ808へ送ることによって応答する。次いで、RRCレイヤ808は、eNB812から受信された応答に含まれる情報に従って、MACレイヤ810においてMAC D2D無線リソースを構成し、それによって、ProSeプロトコル804がTxOP時間をMACレイヤ810から成功裡に取得することを可能にする。ProSeプロトコル804がTxOP時間を成功裡に取得すると、ProSeプロトコル804は、MICを計算し、その後、取得されたTxOP時間に従って、対象のProSe AppコードおよびMICに対応するコマンドをMACレイヤ810へ送る。その後、MACレイヤ810は、受信されたコマンドに従って送信を開始する。
[00102] 図11は、UEレイヤとeNBとの間の例示的なメッセージングを示す第3の図1100である。図11を参照して、上述の事例2aを説明する。本事例では、UE802がアイドル状態である。例示的な実施形態に従って前に説明したシナリオとは異なり、タイプ1リソースが利用可能であることをSIBは示さず、代わりに、D2D通信がネットワークによってサポートされる(例えば、ネットワークがLTE−Dをサポートする)ことを示すにすぎない。
[00103] 従って、利用可能な特定のタイプのリソースに関する情報(例えば、タイプ1またはタイプ2であるかどうか)をSIBが提供しないので、MAC D2D無線リソースは、RRCレイヤ808によってMACレイヤ810から除去され、RRCレイヤ808は、ProSeプロトコル804によって見られる情報である発見サポートフラグ(例えば、D2D通信サポートフラグ)とトリガ必要フラグの両方をセットする。フラグのうちの両方がセットされるので、またUE802がアイドル状態にあるので、UE802は、接続状態になるように状態を遷移させる。
[00104] 再び、ProSeプロトコル804は、取得されたProSe Appコードに基づいてMICを計算し、ProSe Appコードおよび計算されたMICに従ってコマンドをMACレイヤ810へ送る。しかしながら、MACレイヤ810が、RRCレイヤ808によって前に除去されたそれのD2D無線リソースを有していたので、ProSeプロトコル804は、TxOP時間をMACレイヤ810から取得するためのそれの試行に失敗する。TxOP時間を取得することに失敗すると、ProSeプロトコル804はNASレイヤ806と通信し、NASレイヤ806は、UE802がアイドル状態にあることをProSeプロトコル804に示す。
[00105] UE802がアイドル状態にあるので、ProSeプロトコル804は、NASレイヤ806にサービス要求(SR)(例えば、呼出しを開始するタイプを有するサービス要求)をRRCレイヤ808へ(例えば、図8に示す対話チャネル822’を介して)送らせるために、トリガをNASレイヤ806へ送る。次いで、NASレイヤ806は、サービス要求をRRCレイヤ808へ送り、RRCレイヤ808は、MACレイヤ810と通信し、サービス要求に対応する手順に従ってeNB812を介してネットワークとも通信する。
[00106] その後、UE802が接続状態になり、UE802が接続されているという表示をNASレイヤ806が受信すると、NASレイヤ806は、UEが接続状態(ECM_CONNECTED)にあることをProSeプロトコル804へ(例えば、図8に示す対話チャネル822を介して)通信する。ProSeプロトコル804とNASレイヤ806との間の上記の対話が、UE802が接続状態にあった後にそれの接続を失っているとき(例えば、図11における事例2c)に起こり得ることに留意されたい。
[00107] その後、図9および図10に関して説明したシナリオ(例えば、事例1bおよび1c)と類似の方式で、ProSeプロトコル804は、D2D要求のためのトリガをRRCレイヤ808へ送り、RRCレイヤ808に要求をeNB812へ送らせ、eNB812は、その後、応答を送り返すことによって要求に応答する。次いで、RRCレイヤ808は、応答に含まれる情報に従って、MACレイヤ810においてMAC D2D無線リソースを構成し、ProSeプロトコル804は、TxOP時間をMACレイヤ810から成功裡に取得する。
[00108] 本事例では、ProSeプロトコル804がオーバージエアのProSeコードをいつ送ることができるのかをProSeプロトコル804が理解することを可能にするために、ProSeプロトコル804は、TxOP時間においてMACレイヤ810にポーリングする。ProSeプロトコル804がTxOP時間を成功裡に取得すると、ProSeプロトコル804は、MICを計算し、取得されたTxOP時間に従って、対象のProSe AppコードおよびMICに対応するコマンドをMACレイヤ810へ送る。その後、MACレイヤ810は、受信されたコマンドに従って送信を開始する。
[00109] 図12は、UEレイヤとeNBとの間の例示的なメッセージングを示す第4の図1200である。図12を参照して、上述の事例2bを説明する。図11に示すもの(例えば、事例2a)と同様に、タイプ1リソースが利用可能であることをSIBは示さず、代わりに、D2D通信がネットワークによってサポートされる(例えば、ネットワークがLTE−Dをサポートする)ことを示すにすぎない。しかしながら、事例2aに関して説明したシナリオとは異なり、UE802は接続状態にある。従って、所期のD2D通信のためにUE802の状態遷移は必要とされない。
[00110] 再び、MAC無線リソースは、RRCレイヤ808によってMACレイヤ810から除去され、RRCレイヤ808は、ProSeプロトコル804によって見られる情報である発見サポートフラグとトリガ必要フラグの両方をセットする。
[00111] 再び、ProSeプロトコル804は、取得されたProSe Appコードに基づいてMICを計算し、ProSe Appコードおよび計算されたMICに従ってコマンドをMACレイヤ810へ送り、TxOP時間をMACレイヤ810から取得するためのそれの試行に失敗する。TxOP時間を取得することに失敗すると、ProSeプロトコル804は、RRCレイヤ808によって設定されたフラグを検査する。トリガ必要フラグが1に設定されているので、ProSeプロトコル804は、UE802が接続状態にあるのか、それともアイドル状態にあるのかを決定する。ProSeプロトコル804は、本シナリオではUE802が接続状態にあることを示すNASレイヤ806と通信することによって、UE802の状態を決定する。
[00112] UE802が接続状態にあるので、事例2aに関して説明したシナリオとは異なり、ProSeプロトコル804は、UE802をアイドル状態から接続状態へ遷移させるためにトリガをNASレイヤ806へ送ることを必要としない。従って、図9、図10、および図11に関して説明したシナリオ(事例1b、1c、および2a)と同様に、ProSeプロトコル804は、D2Dリソース要求のためのトリガをRRCレイヤ808へ送り、RRCレイヤ808は、eNB812とのメッセージ交換(例えば、RRC D2Dリソース要求メッセージ交換)に関与する。次いで、RRCレイヤ808は、D2Dリソース要求メッセージ交換を介してeNB812から取得された情報に従って、MAC D2D無線リソースをMACレイヤ810において構成し、ProSeプロトコル804は、TxOP時間をMACレイヤ810から成功裡に取得する。次いで、ProSeプロトコル804は、取得されたTxOP時間に従って、対象のProSe Appコードおよび計算されたMICに対応するコマンドをMACレイヤ810へ送り、それによって、MACレイヤ810が受信されたコマンドに従って送信を開始することを可能にする。
[00113] 図13は、UEレイヤとeNBとの間の例示的なメッセージングを示す第5の図1300である。図11および図13を参照して、上述の事例2cを説明する。前に説明した実施形態とは異なり、D2DリソースがeNB812によって割り振られていることをシステム情報/SIBが示す。すなわち、UE802がそれのリソースを選ぶためのタイプ1リソースプールを有する代わりに、eNB812が接続されているネットワークによって決定されるように、タイプ2リソースがUE802に割り当てられ、または割り振られる。すなわち、タイプ2は、UE802がリソース(例えば、タイプ1)のプールからリソースを選択するのではなく、ネットワークが具体的にどのリソースを使用するべきかをUE802に告げ、専用のリソースをUE802に提供することを示す。さらに、UE802が接続状態にある。
[00114] 従って、本事例で、ProSeプロトコル804は、TxOP時間をMACレイヤ810から成功裡に取得し、ProSeプロトコル804は、取得されたTxOP時間に従って、対象のProSe Appコードおよび計算されたMICに対応するコマンドをMACレイヤ810へ送り、それによって、MACレイヤ810が受信されたコマンドに従って送信を開始することを可能にする。しかしながら、本シナリオでは、MACレイヤ810が所期のD2D通信を成功裡に完了する前に、eNB812が、図13に示すように、RRC D2Dリソース取消しメッセージをRRCレイヤ808へ送る(ただし、以下の説明は、図11に示すように、UE802がどういうわけか別のやり方で接続を失うときにも適用される)。
[00115] その後、RRCレイヤ808は、発見サポートフラグとトリガ必要フラグの両方がセットされていることをProSeプロトコル804に示し、RRCレイヤ808は、MACレイヤ810からMAC D2D無線リソースを除去する。従って、ProSeプロトコル804がProSe Appコードおよび計算されたMICに従ってコマンドをMACレイヤ810へ送るとき、ProSeプロトコル804は、TxOP時間をMACレイヤ810から取得するためのそれの試行に失敗する。その後、ProSeプロトコル804はNASレイヤ806と通信し、NASレイヤ806はUE802が依然として接続状態にあることを示し、従って、状態遷移は必要とされず、ProSeプロトコル804は、サービス要求SRのためのトリガをNASレイヤ806へ送ることを必要としない(事例2aに関して説明したシナリオの事例であったように)。
[00116] 再び、図9、図10、図11、および図12に関して説明したシナリオ(事例1b、1c、2a、および2b)と同様に、UE802が接続状態にあることをNASレイヤ806が示すので、ProSeプロトコル804は、D2D要求のためのトリガをRRCレイヤ808へ送り、RRCレイヤ808は、eNB812とのRRC D2Dリソースメッセージ交換に関与し、D2Dリソースメッセージ交換に従って、MACレイヤ810においてMAC D2D無線リソースを構成する。次いで、ProSeプロトコル804は、TxOP時間をMACレイヤ810から成功裡に取得し、取得されたTxOP時間に従って、対象のProSe Appコードおよび計算されたMICに対応するコマンドをMACレイヤ810へ送り、それによって、MACレイヤ810が受信されたコマンドに従って送信を開始することを可能にする。
[00117] 例示的な実施形態によって遭遇され得る他の事例によれば、RRCレイヤ808がそれのRRC D2Dリソース要求へのeNB812からの応答を受信する際に、またはRRCレイヤ808がMAC D2D無線リソースを構成する際に、エラーが起こったとき、ProSeプロトコル804は、タイムアウトが発生した後、D2D要求のためのトリガをRRCレイヤ808へ再び送る。すなわち、ProSeプロトコル804からRRCレイヤ808へ最初にトリガを送ることに続いて所定量の時間が過ぎた後、ProSeプロトコル804がMACレイヤ810からの通信を受信しないとき、ProSeプロトコル804は、上記で説明したプロセスの一部分を再び開始するために、D2D要求をRRCレイヤ808へ再び送る。
[00118] 最後に、代替事例(例えば、事例3、図示せず)で、RRCレイヤ808は、発見サポートフラグがセットされていないこと(例えば、サービング基地局/eNB812に接続されているネットワークがピア発見をサポートしないこと)をProSeプロトコル804に示すことがある。そのようなシナリオで、ProSeプロトコル804は、D2D動作を試みるべきでない。
[00119] ProSeプロトコル804が複数のProSe Appコードを配送しようと求める状況も、例示的な実施形態による潜在的な事例として考えられる。ProSeプロトコル804は、オーバージエアで告知されるべき複数のProSeアプリケーションコードを有し得る。ProSeプロトコル804が、送るべき複数のProSeアプリケーションコードを有するとき、ProSeプロトコル804は、複数のTxOP時間を、対話チャネル823を介してMACレイヤ810に要求し、そこから取得する。D2D送信のためのリソースが周波数領域と時間領域の両方において分配されるので、複数のTxOP機会のためのリソースが、異なる絶対時間値に対応することが可能である。例えば、ProSeプロトコル804が2つの送信機会を要求するとき、MACレイヤ810は、時間t秒と時間t+1秒とを戻し得る。これらの時間は、タイプ1リソースプールからの選択に基づき得、またはeNB812によって決定されるようなリソースの割振りに基づき得る。
[00120] 従って、本シナリオで、ProSeプロトコル804は、ProSeアプリケーションコードの各々に対して、異なる時間に基づいて個々のMICを計算する。例えば、ProSe Appコード1用の第1のMICが時間tを用いて計算され、ProSe Appコード2用の第2のMICが時間t+1を用いて計算される。
[00121] 従って、送信時間tおよびt+1が、異なるメッセージ用のそれらそれぞれのMICと整合することを確実にし、それによって、(UE802がメッセージをそこへ配送しようと求める)受信しているUEがメッセージを正しく検証できることを確実にするために、ProSeプロトコル804が送信のためにMACレイヤ810へProSe AppコードとMICとを送るとき、ProSeプロトコル804は、どのProSe Appコードがどの時間において送信されるべきかをMACレイヤ810に通知する。例示的な実施形態は、MACレイヤ810とProSeプロトコル804との間で送信機会を示すための2つの手法を提供する。すなわち、MACレイヤ810とProSeプロトコル804との間で送信機会TxOP時間を示すための、2つの可能な手法が以下に提供される。
[00122] 第1の手法では、インデックス付けするシステムが、異なるTxOP時間を区別するために、それぞれのTxOP時間に割り当てられる別個のインデックス番号を使用する。例えば、ProSeプロトコル804が複数のTxOPを要求するとき、MACレイヤ810は、これらのTxOP時間の各々を、インデックス番号を用いてインデックス付けする。
[00123] ProSeプロトコル804が、ProSe Appコードのうちの1つと、対応するMICとをMACレイヤ810に向かって下へ(例えば、下位レイヤを通じて)送るとき、ProSeプロトコル804は、特定のMICの計算のために使用される特定のTxOP時間に対応するインデックス番号を示し得る。本実施形態で、MACレイヤ810は、TxOP時間を順に提供し、ProSeプロトコル804は、様々なProSeプロトコルコードと、対応するMICとを、それぞれのMIC計算のために使用される時間と同じ順序に従って送り得る。MACレイヤ810がProSeプロトコル804に応答するとき、MACレイヤ810は、たとえ時間値のうちのいくつかが同一であり得ても、提供されたTxOP時間の各々に対して対応する時間値を含める。
[00124] 第2の代替手法で、ProSeプロトコル804は、ProSeプロトコル804がProSe Appコードを送信するとき、ProSe AppコードとMICとを、MIC計算のために使用されるTxOP時間と一緒に送る。従って、ProSeプロトコル804は、ProSe Appコードの各々に対して1つ、複数のTxOP機会を要求するためのTxOP要求を送り得る。次いで、ProSeプロトコル804は、MACレイヤ810に送られたTxOP要求の中で、送信されるべきProSe Appコードの数を示す。MACレイヤ810は、ProSeプロトコル804から受信された要求に従って、TxOP時間のリストに応答し得る。本実施形態のMACレイヤ810は、TxOP時間ごとに個々のインデックス番号に応答し得、TxOP時間の全てに対するインデックスを暗示する順に送り得、その場合、MACレイヤ810は、様々なインデックス番号とそれらの対応するTxOP時間との間のマッピングを覚えている。しかしながら、ProSeプロトコル804は、ProSe Appコード送信のためのコマンドを送るときのTxOP時間を含めてよく、それによって、MACレイヤ810がインデックス番号マッピングを覚えている必要をなくす。
[00125] さらに、代替動作で、ProSeプロトコル804は、送るべき複数のコードを有するとき、複数のTxOP時間が要求されていることを示す単一のTxOP要求を送る代わりに、複数の要求を使用し得る。そのような代替動作で、ProSeプロトコル804は、それがTxOPにとって新しいコードであるかどうか、またはProSeプロトコル804が既存の/前のProSeアプリケーションコード用の新しいTxOPを要求しているかどうかを、要求の中で示すことになる。例えば、ProSeプロトコル804は、インデックス番号を用いてProSe Appコードをインデックス付けでき、それを要求の中に含めることができる。このようにして、MACレイヤは要求が新しいProSe Appコードのためであるかどうかを知るが、MACレイヤは、インデックスとそれに割り振られた対応するTxOPリソースとのマッピングを覚えていてもよい。
[00126] RRCレイヤ808は、利用可能な無線リソースが変更されている状況に遭遇することがある。例えば、タイプ2リソース割振りの事例(例えば、図13、事例2c)で、eNB812は、eNB812の負荷に基づいて、またはD2D送信を要求しているUEの数に基づいて、UE802に割り振られたリソースを追加または削減することを決定し得る。利用可能な無線リソースが変更されているとき、RRCレイヤ808は、対応するアクションを行うようにProSeプロトコル804に通知し得る。
[00127] 例えば、RRCレイヤ808は、システムレベルインジケータ(例えば、「リソース更新済み」インジケータ)を有する(利用可能な無線リソースが変更されているという)表示をProSeプロトコル804に向かって送り得る。このことは、より多くのTxOP時間をMACレイヤ810に要求するように、またはリソース割振りのためのトリガをリソースの程度が必要とされているという別の表示と一緒にRRCレイヤ808へ送るように、ProSeプロトコル804をトリガする。RRCレイヤ808は、ネットワークによって割り振られた実際のリソースに応答できる。
[00128] 代替実施形態では、RRCレイヤ808が利用可能な無線リソースが変更されている状況に遭遇するとき、RRCレイヤ808は、更新されたリソースを用いてMACレイヤ810を構成するだけでよい。従って、ProSeプロトコル804が、MACレイヤ810と通信することによって次の機会においてTxOP時間を要求するとき、ProSeプロトコルはネットワークリソースの変更に気づく(例えば、ProSeプロトコルは、3つのTxOP値をMACレイヤ810に要求したが、2つだけを見る場合がある)。この場合、ProSeプロトコル804は、対応する動作(例えば、優先度のセットに従ってProSe Appコードのうちの1つもしくは複数の送信を中断すること、または3つのコードの送信を2つの可能なTxOP機会を用いて交互に行うこと)を決定することになる。
[00129] 記載された事例の上記の説明は、送信機UE802(例えば、LTE−Dにおいて告知しているUE)としてUE802に焦点を当てたが、上記の説明が、受信しているUE(例えば、他のUE、または監視しているUE)にも適用可能であり得ることに留意されたい。この場合、監視しているUEは接続状態にあり、さもなければ、SIBの中にリソースがないことをネットワークが示すとき、RRCレイヤ808がトリガ必要フラグをセット(例えば、値を1に設定する)し得る。ProSeプロトコル804は、ProSe Appコードを受信することを望むと決定するとき、RRC D2Dリソース要求メッセージをeNB812に向かって送るようにRRCレイヤ808をトリガする。eNB812が、対応する確認に応答するとき、RRCレイヤ808は、それに応じてD2Dリソースにおいて受信するようにMACレイヤ810を設定し得る。
[00130] 本事例で、RRC D2Dリソース要求は、もはやD2D送信リソースを求めるものでなく、代わりに、受信しているリソースにおいてUEがD2D動作を行うことになることをeNB812に示すために使用され、その結果、eNB812は、それらのリソースを介したいかなる通常のLTE通信をスケジュールすることも回避するべきであり、それによって、UEの他のアプリケーションへの悪影響を潜在的に回避する。従って、eNB812からRRCレイヤ808へ送り返されるD2Dリソース応答メッセージは、リソース情報を含まなくてよく、代わりに確認だけを含み得る。
[00131] 別の代替事例で、告知しているUEは監視しているUEであり得、ここにおいて同じ動作が適用される。そのような事例では、eNB812へ送られるRRC D2Dリソース要求メッセージは、メッセージが送信リソースに対応するのか、スケジューリング支援を受信することに対応するのか、それとも両方に対応するのかを示すことになる。eNB812から送り返されるRRC D2Dリソース応答メッセージは、メッセージが送信リソースに、または送信リソースとスケジューリング支援を受信することの両方に対応するとき、送信リソースを含むことになる。
[00132] 別の代替事例で、監視しているUEは、それが特定のパブリックランドモバイルネットワーク(PLMN)または特定の国コードに対してのみ受信するように望むことを、RRCレイヤ808に示し得る。その場合、RRCレイヤ808は、その要求を解釈し得、対応するRRC D2Dリソース要求の中でその希望を示し得る。RRC D2Dリソース応答において、eNB812は、監視するアクションを行うためのいくつかの方式で動作するように、UE802に命令し得る(例えば、いくつかの時間において周波数の再同調用のギャップを残すようにUE802に命令し得る)。
[00133] 図14は、ワイヤレス通信の方法のフローチャート1400である。方法は、UE(例えば、UE802)によって行われ得る。
[00134] ステップ1402において、ProSeプロトコル(例えば、ProSeプロトコル804)が、ProSeアプリケーションコードを取得する。ステップ1404において、RRCレイヤ(例えば、RRCレイヤ808)が、システム情報(例えば、SIB)を取得する。ステップ1406において、RRCレイヤは、ネットワーク(例えば、eNB812のネットワーク)がピア発見をサポートすることをシステム情報が示すかどうか(例えば、ネットワークがLTE−Dネットワークであるかどうか)を決定する。ネットワークがD2D通信をサポートしないことをシステム情報が示す場合、RRCレイヤは、ステップ1408において、それに対応する値が0になるように、フラグ(例えば、第2のフラグ、すなわち発見サポートフラグ)をアンセットする。従って、ProSeプロトコルはD2D通信を試みるべきでなく、プロセスは終了される。
[00135] ネットワークがピア発見をサポートするか、またはD2D通信をサポートすることをシステム情報が示す場合、RRCレイヤは、ステップ1410において、それに対応する値が1になるように、フラグ(例えば、発見サポートフラグ、またはD2D通信サポートフラグ)をセットする。ステップ1412において、RRCレイヤは、システム情報がタイプ1リソースを示すかどうかを決定し、ステップ1414において、RRCレイヤは、UEがアイドル状態にあるかどうかを決定する。ステップ1412および1414において、システム情報がタイプ1リソースを示さないこと、またはUEがアイドル状態にない(例えば、UEが接続状態にある)ことのいずれかをRRCレイヤが決定する場合、RRCレイヤは、ステップ1416において、別のフラグ(例えば、第1のフラグ、すなわちトリガ必要フラグ)をセットし、次いで、ステップ1418において、MACレイヤ(例えば、MACレイヤ810)のD2D無線リソースを除去する。
[00136] しかしながら、システム情報がタイプ1リソースを示すことと、UEがアイドル状態にあることとをRRCレイヤが決定する場合、RRCレイヤは、ステップ1420において、他のフラグをアンセットし(例えば、トリガ必要フラグを0に設定する)、ステップ1422において、MACレイヤのD2D無線リソースを構成する。
[00137] RRCレイヤが、ステップ1422においてMACレイヤのD2D無線リソースを構成すること、またはステップ1418においてMACレイヤのD2D無線リソースを除去することのいずれかの後、ProSeプロトコルは、ステップ1424において、MACレイヤからTxOP時間を取得しようと試みる。図14のフレームワーク内で複数のProSeアプリケーションコードが取得される場合があり、その場合、上記で説明したように、対応する複数のMICが計算され、複数のTxOP時間がMACレイヤから取得され得ることに留意されたい。
[00138] ProSeプロトコルの試行が成功した場合、ステップ1426において、ProSeプロトコルは、ステップ1402において取得されたProSeアプリケーションコード用のメッセージインテグリティチェックサム(MIC)を計算し、MICとProSeアプリケーションコードとをMACレイヤへ送る。
[00139] しかしながら、ステップ1424におけるMACレイヤからTxOP時間を取得するためのProSeプロトコルの試行が失敗した場合、ステップ1428において、ProSeプロトコルは、RRCレイヤによって設定されたフラグを検査する(例えば、トリガ必要フラグがセットされていることを確かめ、および/または発見サポートフラグがセットされていることを確かめる)。
[00140] ステップ1426においてMICとProSeアプリケーションコードとをMACレイヤへ送った後、ステップ1430においてエラー通知がProSeプロトコルによってMACレイヤから受信される場合、または1428においてトリガ必要フラグがセットされていることを確かめた後、ProSeプロトコルは、ステップ1432において、UEが接続状態にあるかどうかを決定するためにNASレイヤに確認する。
[00141] ステップ1432においてUEが接続状態にないと決定される場合、ステップ1434において、ProSeプロトコルは、接続状態へ切り替わるようにNASレイヤをトリガするためのサービス要求を送る。次いで、ステップ1436において、UEは接続状態へ遷移される。次いで、ステップ1438において、NASレイヤは、RRCが接続状態にあることをProSeプロトコルに示す。
[00142] ステップ1438の後、または代替として、ステップ1432においてUEが接続状態にあると決定される場合、ProSeプロトコルレイヤは、ステップ1440において、リソースを求める要求をサービング基地局(例えば、eNB812)へ送るようにRRCレイヤに命令する。ステップ1442において、RRCレイヤは、サービング基地局からのリソースの割振りを要求する。ステップ1444において、サービング基地局は、ピア発見リソースまたはD2D通信リソースなどのD2Dリソースを割り振る応答をRRCレイヤへ送る。その後、RRCレイヤはステップ1422に戻り、MACレイヤの無線リソースを構成する。
[00143] しかしながら、ステップ1430においてエラー通知がProSeプロトコルによってMACレイヤから受信されない場合、ステップ1446において無線リソースがeNBによって取り消されていない場合、およびステップ1448においてD2D通信が終了されていない場合、UEは、さらなる送信用の追加のProSeアプリケーションコードを取得するためにステップ1402に戻り得る。
[00144] 代替として、リソースが取り消されている場合、RRCレイヤは、トリガ必要フラグをセットするためにステップ1416に戻る。ステップ1448においてD2D通信が終了されている場合、プロセスは終了する。
[00145] 図15は、ワイヤレス通信の第1の方法を示す図1500である。方法は、UE802などのUEによって行われ得る。1502において、UEは、システム情報がD2D通信に対して受信されるかどうかを決定する。UEの第1のレイヤは、システム情報を受信し得、少なくとも1つのフラグを設定し得、第1のレイヤよりも上位の第2のレイヤは、少なくとも1つのフラグを検査し得、D2Dリソース(例えば、ピア発見リソース)を決定するように第1のレイヤに要求し得る。
[00146] 1504において、一構成では、システム情報がD2D通信に対して受信されていると決定されるとき、UEは、D2Dリソース(例えば、共通ピア発見リソース)のセットがシステム情報の中で示されるかどうかを決定し得る。1506において、UEは、UEの無線リソース制御(RRC)状態を決定し得る。
[00147] 1508において、一構成では、システム情報がD2D通信に対して受信されていると決定されるとき、および共通ピア発見リソースのセットなどのD2Dリソースのセットがシステム情報の中で示されるとき、UEは、D2Dリソースのセットを使用してD2Dピア発見通信などのD2D通信を行い得る。1510において、UEは、D2Dリソースのセットを通じたD2D通信を停止させ得る。1512において、UEは、RRCアイドル状態からRRC接続状態へ遷移し得る。
[00148] 1514において、一構成では、システム情報がD2D通信に対して受信されていると決定されるとき、および共通ピア発見リソースのセットなどのD2Dリソースのセットがシステム情報の中で示されないとき、UEは、割り振られたリソースのセットを使用してD2Dピア発見通信などのD2D通信を行い得る。1516において、UEは、割り振られたリソースのセットの使用の取消しを受信し得る。
[00149] 1518において、UEは、システム情報が受信されるとき、システム情報に基づいて少なくとも1つのフラグを設定する。少なくとも1つのフラグは、D2Dリソースのセットがシステム情報の中で示されるかどうかに基づいて、および決定されたRRC状態に基づいて設定され得る。D2Dリソースのセットがシステム情報の中で示されると決定されるとき、およびRRC状態がRRCアイドル状態であると決定されるとき、少なくとも1つのフラグを設定することは、D2Dリソースの割振りを求める要求が必要とされないことを第2のレイヤに対して示すために、少なくとも1つのフラグのうちの第1のフラグを設定することを含み得る。D2Dリソースのセットがシステム情報の中で示されると決定されるとき、およびRRC状態がRRC接続状態であると決定されるとき、少なくとも1つのフラグを設定することは、D2Dの割振りを求める要求が必要とされることを示すために、少なくとも1つのフラグのうちの第1のフラグを設定することを含み得る。D2Dリソースのセットがシステム情報の中で示されないと決定されるとき、およびRRC状態がRRCアイドル状態であると決定されるとき、少なくとも1つのフラグを設定することは、D2Dリソースの割振りを求める要求が必要とされることを第2のレイヤに対して示すために、少なくとも1つのフラグのうちの第1のフラグを設定することを含み得る。D2Dリソースのセットがシステム情報の中で示されないと決定されるとき、およびRRC状態がRRC接続状態であると決定されるとき、少なくとも1つのフラグを設定することは、D2Dリソースの割振りを求める要求が必要とされることを第2のレイヤに対して示すために、少なくとも1つのフラグのうちの第1のフラグを設定することを含み得る。RRCアイドル状態からRRC接続状態へ遷移すると、少なくとも1つのフラグが設定され得る。少なくとも1つのフラグを設定することは、D2Dリソースの割振りを求める要求が必要とされることを示すために、少なくとも1つのフラグのうちの第1のフラグを設定することを含み得る。システム情報がD2D通信に対して受信されていないと決定されるとき、および少なくとも1つのフラグを設定することが、D2D通信がサポートされないことを示す、少なくとも1つのフラグのうちのフラグを設定することを含むとき、D2Dリソースはヌルセットであると決定され得る。1520において、UEは、少なくとも1つのフラグに基づいてD2Dリソースを決定する。
[00150] 一構成で、第1のレイヤはRRCレイヤであり、第2のレイヤはProSeプロトコルレイヤである。事例1a、1b、2a、2bの場合、一構成では、システム情報がD2D通信に対して受信されていると決定され(1502)、UEは、共通ピア発見リソースのセットなどのD2Dリソースのセットがシステム情報の中で示されるかどうかを決定し(1504)、UEのRRC状態を決定する(1506)。そのような構成では、少なくとも1つのフラグが、D2Dリソースのセットがシステム情報の中で示されるかどうかに基づいて、および決定されたRRC状態に基づいて設定される(1518)。
[00151] 一構成では、事例1aの場合、D2Dリソース(例えば、共通ピア発見リソース)のセットがシステム情報の中で示されると決定され(1504)、RRC状態がRRCアイドル状態であると決定される(1506)。加えて、第1のレイヤは、D2Dリソースの割振りを求める要求が必要とされないことを第2のレイヤに対して示すために、少なくとも1つのフラグのうちの第1のフラグを設定することによって、少なくとも1つのフラグを設定する(1518)。一構成で、第1のレイヤは、D2D通信がサポートされることを示すために、少なくとも1つのフラグのうちの第2のフラグを設定することによって、少なくとも1つのフラグを設定する(1518)。一構成で、UEは、D2D通信がサポートされることと、D2Dリソースの割振りを求める要求が必要とされないこととを、少なくとも1つのフラグから決定する。そのような構成で、UEは、D2D通信に対するシステム情報の中で示されるD2Dリソースのセットを使用することを決定することによって、D2Dリソースを決定する(1520)。
[00152] 一構成で、事例1bの場合、D2Dリソース(例えば、共通ピア発見リソース)のセットがシステム情報の中で示されると決定され(1504)、RRC状態がRRC接続状態であると決定される(1506)。そのような構成で、第1のレイヤは、D2Dリソースの割振りを求める要求が必要とされることを示すために、少なくとも1つのフラグのうちの第1のフラグを設定することによって、少なくとも1つのフラグを設定する(1518)。一構成で、第1のレイヤは、D2D通信がサポートされることを示すために、少なくとも1つのフラグのうちの第2のフラグを設定することによって、少なくとも1つのフラグを設定する(1518)。一構成で、UEは、D2D通信がサポートされることと、D2Dリソースの割振りを求める要求が必要とされることとを、少なくとも1つのフラグから決定する。そのような構成で、UEは、第1のレイヤにサービング基地局からのD2Dリソースの割振りを要求するように第2のレイヤにおいて要求することによって、およびD2D2リソースの割振りをサービング基地局から受信することによって、D2Dリソースを決定する(1520)。そのような構成で、決定されたD2Dリソースは、受信された割振り済みD2D2リソースである。一構成で、UEは、D2D通信がサポートされることと、D2Dリソースの割振りを求める要求が必要とされることとを、少なくとも1つのフラグから決定する。そのような構成で、UEは、第1のレイヤにサービング基地局からのD2Dリソースのセットを用いたD2D通信を行うことを要求するように第2のレイヤにおいて要求することによって、およびD2DリソースのセットがD2D通信(例えば、ピア発見)のために予約されているという確認を基地局から受信することによって、D2Dリソースを決定する(1520)。
[00153] 一構成では、事例2aにおいて、D2Dリソース(例えば、共通ピア発見リソース)のセットがシステム情報の中で示されないと決定され(1504)、RRC状態がRRCアイドル状態であると決定される(1506)。そのような構成で、第1のレイヤは、D2Dリソースの割振りを求める要求が必要とされることを第2のレイヤに対して示すために、少なくとも1つのフラグのうちの第1のフラグを設定することによって、少なくとも1つのフラグを設定する(1518)。一構成で、第1のレイヤは、D2D通信がサポートされることを示すために、少なくとも1つのフラグのうちの第2のフラグを設定することによって、少なくとも1つのフラグを設定する(1518)。一構成で、UEは、D2D通信がサポートされることと、D2Dリソースの割振りを求める要求が必要とされることとを、少なくとも1つのフラグから決定する。そのような構成で、UEは、RRCアイドル状態からRRC接続状態へ遷移することによって、第1のレイヤにサービング基地局からのD2Dリソースの割振りを要求するように第2のレイヤにおいて要求することによって、およびD2Dリソースの割振りをサービング基地局から受信することによって、D2Dリソースを決定する(1520)。そのような構成で、決定されたD2Dリソースは、受信された割振り済みD2Dリソースである。一構成で、UEは、第1のレイヤにRRCアイドル状態からRRC接続状態へ遷移させるために、第1のレイヤよりも上位の第3のレイヤを第2のレイヤによって制御する。一構成で、第3のレイヤはNASレイヤである。
[00154] 一構成では、事例2bにおいて、D2Dリソース(例えば、共通ピア発見リソース)のセットがシステム情報の中で示されないと決定され(1504)、RRC状態がRRC接続状態であると決定される(1506)。そのような構成で、第1のレイヤは、D2Dリソースの割振りを求める要求が必要とされることを第2のレイヤに対して示すために、少なくとも1つのフラグのうちの第1のフラグを設定することによって、少なくとも1つのフラグを設定する(1518)。一構成で、第1のレイヤは、D2D通信がサポートされることを示すために、少なくとも1つのフラグのうちの第2のフラグを設定することによって、少なくとも1つのフラグを設定する(1518)。一構成で、UEは、D2D通信がサポートされることと、D2Dリソースの割振りを求める要求が必要とされることとを、少なくとも1つのフラグから決定する。そのような構成で、UEは、第1のレイヤにサービング基地局からのD2Dリソースの割振りを要求するように第2のレイヤにおいて要求することによって、およびD2Dリソースの割振りをサービング基地局から受信することによって、D2Dリソースを決定し、ここにおいて、決定されたD2Dリソースは、受信された割振り済みD2Dリソースである(1520)。一構成で、UEは、D2D通信がサポートされることと、D2Dリソースの割振りを求める要求が必要とされることとを、少なくとも1つのフラグから決定する。そのような構成で、UEは、第1のレイヤにサービング基地局からのD2Dリソースのセットを用いたD2D通信を行うことを要求するように第2のレイヤにおいて要求することによって、およびD2DリソースのセットがD2D通信(例えば、ピア発見)のために予約されているという確認を基地局から受信することによって、D2Dリソースを決定する(1520)。
[00155] 一構成では、事例1cにおいて、システム情報がD2D通信に対して受信されていると決定され(1502)、D2Dリソース(例えば、共通ピア発見リソース)のセットがシステム情報の中で示される(1504)。そのような構成で、UEは、D2Dリソースのセットを使用してD2D通信を行い(1508)、D2Dリソースのセットを通じたD2D通信を停止させ(1510)、RRCアイドル状態からRRC接続状態へ遷移する(1512)。加えて、そのような構成で、RRCアイドル状態からRRC接続状態へ遷移すると、少なくとも1つのフラグが設定され、D2Dリソースの割振りを求める要求が必要とされることを示すために、第1のレイヤは、少なくとも1つのフラグのうちの第1のフラグを設定することによって、少なくとも1つのフラグを設定する(1518)。一構成で、第1のレイヤは、D2D通信がサポートされることを示すために、少なくとも1つのフラグのうちの第2のフラグを設定することによって、少なくとも1つのフラグを設定する(1518)。一構成で、UEは、D2D通信がサポートされることと、D2Dリソースの割振りを求める要求が必要とされることとを、少なくとも1つのフラグから決定する。そのような構成で、UEは、D2Dリソースが利用可能でないことを第2のレイヤにおいて決定することによって、第1のレイヤにサービング基地局からのD2Dリソースの割振りを要求するように第2のレイヤにおいて要求することによって、およびD2Dリソースの割振りをサービング基地局から受信することによって、D2Dリソースを決定する(1520)。そのような構成で、決定されたD2Dリソースは、受信された割振り済みD2Dリソースである。
[00156] 一構成では、事例2cにおいて、システム情報がD2D通信に対して受信されていると決定され(1502)、D2Dリソースのセットがシステム情報の中で示されない(1504)。そのような構成で、UEは、割り振られたD2Dリソースのセット(例えば、割り振られたピア発見リソースのセット)を使用してD2D通信を行い(1514)、割り振られたD2Dリソースのセットの使用の取消しを受信する(1516)。そのような構成で、D2Dリソースの割振りを求める要求が必要とされることを示すために、第1のレイヤは、少なくとも1つのフラグのうちの第1のフラグを設定することによって、少なくとも1つのフラグを設定する(1518)。一構成で、第1のレイヤは、D2D通信がサポートされることを示すために、少なくとも1つのフラグのうちの第2のフラグを設定することによって、少なくとも1つのフラグを設定する(1518)。一構成で、UEは、D2D通信がサポートされることと、D2Dリソースの割振りを求める要求が必要とされることとを、少なくとも1つのフラグから決定する。そのような構成で、UEは、D2Dリソースが利用可能でないことを第2のレイヤにおいて決定することによって、第1のレイヤにサービング基地局からのD2Dリソースの割振りを要求するように第2のレイヤにおいて要求することによって、およびD2Dリソースの割振りをサービング基地局から受信することによって、D2Dリソースを決定し、ここにおいて、決定されたD2Dリソースは、受信された割振り済みD2Dリソースである(1520)。
[00157] 一構成では、事例3において、システム情報がD2D通信に対して受信されていないと決定され(1502)、第1のレイヤは、D2D通信がサポートされないことを示す、少なくとも1つのフラグのうちのフラグを設定することによって、少なくとも1つのフラグを設定し、ここにおいて、D2Dリソースはヌルセットであると決定される(1518)。一構成で、UEは、D2Dリソース(例えば、ピア発見リソース)の中で信号を送信する。
[00158] 図16は、例示的な装置1602の中の様々なモジュール/手段/構成要素間のデータフローを示す概念的なデータフロー図1600である。装置1602はUEであり得る。装置1602は、D2D通信に対するシステム情報を受信するように構成されている受信モジュール1610を含む。装置1602は、システム情報がD2D通信に対して受信されるかどうかを決定するように構成されているシステム情報決定モジュール1612をさらに含む。装置1602は、システム情報(例えば、基地局1640によって割り振られたピア発見リソースに対応する情報)が受信されるとき、システム情報に基づいて少なくとも1つのフラグを設定するように構成されているフラグ設定モジュール1614をさらに含む。装置1602は、少なくとも1つのフラグに基づいてD2Dリソースを決定するように構成されているD2Dリソース決定モジュール(例えば、ピア発見リソース決定モジュール)1616をさらに含む。一構成で、装置1602の第1のレイヤは、受信モジュール1610と、フラグ設定モジュール1614と、D2Dリソース決定モジュール1616とを備え、第1のレイヤよりも上位の装置1602の第2のレイヤは、少なくとも1つのフラグを検査し、D2Dリソースを決定するように第1のレイヤに要求するように構成されている。一構成で、装置1602は、装置1602のRRC状態を決定するように構成されているRRC状態決定および制御モジュール1618をさらに含み、システム情報決定モジュール1612は、D2Dリソースのセットがシステム情報の中で示されるかどうかを決定するように構成され、フラグ設定モジュール1614は、D2Dリソースのセットがシステム情報の中で示されるかどうかに基づいて、および決定されたRRC状態に基づいて、少なくとも1つのフラグを設定するように構成される。一構成で、D2Dリソースのセットがシステム情報の中で示されると決定されるとき、およびRRC状態がRRCアイドル状態であると決定されるとき、フラグ設定モジュール1614は、D2Dリソースの割振りを求める要求が必要とされないことを第2のレイヤに対して示すために、少なくとも1つのフラグのうちの第1のフラグを設定するように構成される。一構成で、D2Dリソースのセットがシステム情報の中で示されると決定されるとき、およびRRC状態がRRC接続状態であると決定されるとき、フラグ設定モジュール1614は、D2Dリソースの割振りを求める要求が必要とされることを示すために、少なくとも1つのフラグのうちの第1のフラグを設定するように構成される。一構成で、D2Dリソースのセットがシステム情報の中で示されないと決定されるとき、およびRRC状態がRRCアイドル状態であると決定されるとき、フラグ設定モジュール1614は、D2Dリソースの割振りを求める要求が必要とされることを第2のレイヤに対して示すために、少なくとも1つのフラグのうちの第1のフラグを設定するように構成される。一構成で、D2Dリソースのセットがシステム情報の中で示されないと決定されるとき、およびRRC状態がRRC接続状態であると決定されるとき、フラグ設定モジュール1614は、D2Dリソースの割振りを求める要求が必要とされることを第2のレイヤに対して示すために、少なくとも1つのフラグのうちの第1のフラグを設定するように構成される。一構成で、装置1602は送信モジュール1620をさらに含み、システム情報がD2D通信に対して受信されていると決定されるとき、およびD2Dリソースのセットがシステム情報の中で示されるとき、送信モジュール1620は、D2Dリソースのセットを使用して(例えば、別のUE1650と)D2D通信を行うように構成され、D2Dリソースのセットを通じたD2D通信を停止させるように構成され、RRC状態決定および制御モジュール1618は、装置1602をRRCアイドル状態からRRC接続状態へ遷移させるように構成され、フラグ設定モジュール1614は、装置1602がRRCアイドル状態からRRC接続状態へ遷移すると少なくとも1つのフラグを設定するように構成され、D2Dリソースの割振りを求める要求が必要とされることを示すために、少なくとも1つのフラグのうちの第1のフラグを設定するように構成される。一構成で、システム情報がD2D通信に対して受信されていると決定されるとき、およびD2Dリソースのセットがシステム情報の中で示されないとき、送信モジュール1620は、割り振られたD2Dリソースのセットを使用してD2Dピア発見通信などのD2D通信を行うように構成され、受信モジュール1610は、割り振られたD2Dリソースのセットの使用の取消しを受信するように構成され、フラグ設定モジュール1614は、D2Dリソースの割振りを求める要求が必要とされることを示すために、少なくとも1つのフラグのうちの第1のフラグを設定するように構成される。
[00159] 図17は、処理システム1713を採用する装置1602’のためのハードウェア実施の一例を示す図1700である。処理システム1713は、バス1724によって概略的に表されるバスアーキテクチャを用いて実施され得る。バス1724は、処理システム1713の特定の適用例および全体的な設計制約に応じて、任意の数の相互接続バスとブリッジとを含み得る。バス1724は、プロセッサ1704によって表される1つまたは複数のプロセッサおよび/またはハードウェアモジュールと、モジュール1610、1612、1614と、コンピュータ可読媒体/メモリ1706とを含む、様々な回路を互いにリンクする。バス1724はまた、タイミングソース、周辺装置、電圧調整器、および電力管理回路などの、様々な他の回路をリンクし得るが、これらの回路は当技術分野においてよく知られており、従って、これ以上説明しない。
[00160] 処理システム1713は、トランシーバ1710に結合され得る。トランシーバ1710は、1つまたは複数のアンテナ1720に結合される。トランシーバ1710は、送信媒体を介して様々な他の装置と通信するための手段を提供する。トランシーバ1710は、1つまたは複数のアンテナ1720から信号を受信し、受信された信号から情報を抽出し、抽出された情報を処理システム1713に提供する。加えて、トランシーバ1710は、処理システム1713から情報を受信し、受信された情報に基づいて、1つまたは複数のアンテナ1720に適用されるべき信号を生成する。処理システム1713は、コンピュータ可読媒体/メモリ1706に結合されたプロセッサ1704を含む。プロセッサ1704は、コンピュータ可読媒体/メモリ1706に記憶されたソフトウェアの実行を含む一般的な処理を担当する。ソフトウェアは、プロセッサ1704によって実行されたとき、処理システム1713に、特定の装置のための上記で説明した様々な機能を行わせる。コンピュータ可読媒体/メモリ1706はまた、ソフトウェアを実行するときにプロセッサ1704によって操作されるデータを記憶するために使用され得る。処理システムは、モジュール1610、1612、1614のうちの少なくとも1つをさらに含む。モジュールは、プロセッサ1704において稼働するソフトウェアモジュール、コンピュータ可読媒体/メモリ1706の中に常駐する/記憶されるソフトウェアモジュール、プロセッサ1704に結合された1つまたは複数のハードウェアモジュール、あるいはそれらの何らかの組合せであり得る。処理システム1713は、eNB610の構成要素であり得、メモリ676、ならびに/またはTXプロセッサ616、RXプロセッサ670、およびコントローラ/プロセッサ675のうちの少なくとも1つを含み得る。
[00161] 一構成では、ワイヤレス通信のための装置1602/1602’が、UEであり得る。UEは、システム情報がデバイス間(D2D)通信に対して受信されるかどうかを決定するための手段と、システム情報が受信されるとき、システム情報に基づいて少なくとも1つのフラグを設定するための手段と、少なくとも1つのフラグに基づいてD2Dリソースを決定するための手段とを含む。
[00162] UEは、D2Dリソースのセットがシステム情報の中で示されるかどうかを決定するための手段と、UEの無線リソース制御(RRC)状態を決定するための手段とをさらに含み得る。少なくとも1つのフラグは、D2Dリソースのセットがシステム情報の中で示されるかどうかに基づいて、および決定されたRRC状態に基づいて設定され得る。少なくとも1つのフラグを設定するための手段は、D2Dリソースのセットがシステム情報の中で示されると決定されるかどうか、およびRRC状態の決定に応じて、D2Dリソースの割振りを求める要求が必要とされることまたは必要とされないことのいずれかを第2のレイヤに対して示すために、少なくとも1つのフラグのうちの第1のフラグを設定するように構成され得る。
[00163] UEは、D2Dリソースのセットを使用してD2D通信を行うための手段と、D2Dリソースのセットを通じたD2D通信を停止させるための手段と、RRCアイドル状態からRRC接続状態へ遷移するための手段とをさらに含み得る。システム情報がD2D通信に対して受信されていると決定されるとき、およびD2Dリソースのセットがシステム情報の中で示されるとき、RRCアイドル状態からRRC接続状態へ遷移すると、少なくとも1つのフラグが設定され、少なくとも1つのフラグを設定するための手段は、D2Dリソースの割振りを求める要求が必要とされることを示すために、少なくとも1つのフラグのうちの第1のフラグを設定するように構成される。
[00164] UEは、割り振られたD2Dリソースのセットを使用してD2D通信を行うための手段と、割り振られたD2Dリソースのセットの使用の取消しを受信するための手段とをさらに含み得る。システム情報がD2D通信に対して受信されていると決定されるとき、およびD2Dリソースのセットがシステム情報の中で示されないとき、少なくとも1つのフラグを設定するための手段は、D2Dリソースの割振りを求める要求が必要とされることを示すために、少なくとも1つのフラグのうちの第1のフラグを設定するように構成される。
[00165] 上述の手段は、上述の手段によって記載される機能を行うように構成された、装置1602の上述のモジュールおよび/または装置1602’の処理システム1713のうちの、1つまたは複数であり得る。上記で説明したように、処理システム1713は、TXプロセッサ668と、RXプロセッサ656と、コントローラ/プロセッサ659とを含み得る。従って、一構成では、上述の手段が、上述の手段によって記載される機能を行うように構成された、TXプロセッサ668、RXプロセッサ656、およびコントローラ/プロセッサ659であり得る。
[00166] 開示したプロセス/フローチャートにおけるステップの特定の順序または階層は、例示的な手法の一例であることを理解されたい。設計の選好に基づいて、プロセス/フローチャートにおけるステップの特定の順序または階層が再構成され得ることを理解されたい。さらに、いくつかのステップは組み合わされ得、または省略され得る。添付の方法クレームは、様々なステップの要素を見本の順序において提示しており、提示された特定の順序または階層に限定されることを意味するものではない。
[00167] 以上の説明は、当業者が本明細書で説明する様々な態様を実践できるようにするために提供される。これらの態様に対する様々な修正は当業者には容易に明らかであり、本明細書で定義された一般原理は他の態様に適用され得る。従って、特許請求の範囲は、本明細書で示される態様に限定されるものではなく、クレーム文言に矛盾しない全範囲を与えられるべきであり、単数形の要素への言及は、そのように明記されていない限り、「唯一無二の」を意味するものではなく、「1つまたは複数の」を意味するものである。「例示的」という単語は、本明細書では「例、事例、または例示の働きをすること」を意味するために使用される。「例示的」として本明細書で説明するいかなる態様も、必ずしも他の態様よりも好適または有利であると解釈されるべきであるとは限らない。別段に明記されていない限り、「いくつかの(some)」という用語は1つまたは複数を表す。「A、B、またはCのうちの少なくとも1つの」、「A、B、およびCのうちの少なくとも1つ」、「A、B、C、またはそれらの任意の組合せ」などの組合せは、A、B、および/またはCの任意の組合せを含み、複数のA、複数のB、または複数のCを含み得る。具体的には、「A、B、またはCのうちの少なくとも1つ」、「A、B、およびCのうちの少なくとも1つ」、「A、B、C、またはそれらの任意の組合せ」などの組合せは、Aのみ、Bのみ、Cのみ、AおよびB、AおよびC、BおよびC、AおよびBおよびCであり得、任意のそのような組合せは、A、B、またはCのうちの1つまたは複数のメンバを含み得る。本開示全体にわたって説明される様々な態様の要素に対する全ての構造的および機能的均等物は、当業者には周知であり、または後に周知となり、参照により本明細書に明確に組み込まれ、特許請求の範囲によって包含されることを意図する。さらに、本明細書で開示するいかなることも、そのような開示が特許請求の範囲に明示的に記載されているかどうかにかかわらず、公に供するものではない。いかなるクレーム要素も、その要素が「ための手段」という句を使用して明確に記載されていない限り、ミーンズプラスファンクションとして解釈されるべきではない。
以下に本願発明の当初の特許請求の範囲に記載された発明を付記する。
[C1]
ユーザ機器(UE)のワイヤレス通信の方法であって、
システム情報がデバイス間(D2D)通信に対して受信されるかどうかを決定することと、
前記システム情報が受信されるとき、前記システム情報に基づいて少なくとも1つのフラグを設定することと、
前記少なくとも1つのフラグに基づいてD2Dリソースを決定することと
を備える方法。
[C2]
前記UEの第1のレイヤが、前記システム情報を受信し、前記少なくとも1つのフラグを設定し、前記第1のレイヤよりも上位の第2のレイヤが、前記少なくとも1つのフラグを検査し、前記D2Dリソースを決定するように前記第1のレイヤに要求する、C1に記載の方法。
[C3]
前記システム情報はD2D通信に対して受信されていると決定され、前記方法は、
共通D2Dリソースのセットが前記システム情報の中で示されるかどうかを決定することと、
前記UEの無線リソース制御(RRC)状態を決定することとをさらに備え、
ここにおいて、前記少なくとも1つのフラグは、前記共通D2Dリソースの前記セットが前記システム情報の中で示されるかどうかに基づいて、および前記決定されたRRC状態に基づいて設定される、
C2に記載の方法。
[C4]
共通D2Dリソースの前記セットは前記システム情報の中で示されると決定され、前記RRC状態はRRCアイドル状態であると決定され、
ここにおいて、前記少なくとも1つのフラグを前記設定することは、前記D2Dリソースの割振りを求める要求が必要とされないことを前記第2のレイヤに対して示すために、前記少なくとも1つのフラグのうちの第1のフラグを設定することを備える、
C3に記載の方法。
[C5]
共通D2Dリソースの前記セットは前記システム情報の中で示されると決定され、前記RRC状態はRRC接続状態であると決定され、
ここにおいて、前記少なくとも1つのフラグを前記設定することは、前記D2Dリソースの割振りを求める要求が必要とされることを示すために、前記少なくとも1つのフラグのうちの第1のフラグを設定することを備える、
C3に記載の方法。
[C6]
共通D2Dリソースの前記セットは前記システム情報の中で示されないと決定され、前記RRC状態はRRCアイドル状態であると決定され、
ここにおいて、前記少なくとも1つのフラグを前記設定することは、前記D2Dリソースの割振りを求める要求が必要とされることを前記第2のレイヤに対して示すために、前記少なくとも1つのフラグのうちの第1のフラグを設定することを備える、
C3に記載の方法。
[C7]
共通D2Dリソースの前記セットは前記システム情報の中で示されないと決定され、前記RRC状態はRRC接続状態であると決定され、
ここにおいて、前記少なくとも1つのフラグを前記設定することは、前記D2Dリソースの割振りを求める要求が必要とされることを前記第2のレイヤに対して示すために、前記少なくとも1つのフラグのうちの第1のフラグを設定することを備える、
C3に記載の方法。
[C8]
前記システム情報はD2D通信に対して受信されていると決定され、ここにおいて、共通D2Dリソースのセットが前記システム情報の中で示され、前記方法は、
共通D2Dリソースの前記セットを使用してD2D通信を行うことと、
共通D2Dリソースの前記セットを通じた前記D2D通信を停止させることと、
RRCアイドル状態からRRC接続状態へ遷移することとをさらに備え、
ここにおいて、前記RRCアイドル状態から前記RRC接続状態へ遷移すると、前記少なくとも1つのフラグが設定され、
ここにおいて、前記少なくとも1つのフラグを前記設定することは、前記D2Dリソースの前記割振りを求める要求が必要とされることを示すために、前記少なくとも1つのフラグのうちの第1のフラグを設定することを備える、
C2に記載の方法。
[C9]
前記システム情報はD2D通信に対して受信されていると決定され、ここにおいて、共通D2Dリソースのセットが前記システム情報の中で示されず、前記方法は、
割り振られたD2Dリソースのセットを使用してD2D通信を行うことと、
前記割り振られたD2Dリソースのセットの前記使用の取消しを受信することとをさらに備え、
ここにおいて、前記少なくとも1つのフラグを前記設定することは、前記D2Dリソースの前記割振りを求める要求が必要とされることを示すために、前記少なくとも1つのフラグのうちの第1のフラグを設定することを備える、
C2に記載の方法。
[C10]
前記システム情報はD2D通信に対して受信されていないと決定され、前記少なくとも1つのフラグを設定することは、D2D通信がサポートされないことを示す、前記少なくとも1つのフラグのうちのフラグを設定することを備え、ここにおいて、前記D2Dリソースは、ヌルセットであると決定される、C1に記載の方法。
[C11]
ワイヤレス通信のための装置であって、前記装置はUEであり、
システム情報がデバイス間(D2D)通信に対して受信されるかどうかを決定するための手段と、
前記システム情報が受信されるとき、前記システム情報に基づいて少なくとも1つのフラグを設定するための手段と、
前記少なくとも1つのフラグに基づいてD2Dリソースを決定するための手段と
を備える装置。
[C12]
前記UEの第1のレイヤが、前記システム情報を受信し、前記少なくとも1つのフラグを設定し、前記第1のレイヤよりも上位の第2のレイヤが、前記少なくとも1つのフラグを検査し、前記D2Dリソースを決定するように前記第1のレイヤに要求する、C11に記載の装置。
[C13]
前記システム情報はD2D通信に対して受信されていると決定され、前記装置は、
共通D2Dリソースのセットが前記システム情報の中で示されるかどうかを決定するための手段と、
前記UEの無線リソース制御(RRC)状態を決定するための手段とをさらに備え、
ここにおいて、前記少なくとも1つのフラグは、前記共通D2Dリソースの前記セットが前記システム情報の中で示されるかどうかに基づいて、および前記決定されたRRC状態に基づいて設定される、
C12に記載の装置。
[C14]
共通D2Dリソースの前記セットは前記システム情報の中で示されると決定され、前記RRC状態はRRCアイドル状態であると決定され、
ここにおいて、前記少なくとも1つのフラグを設定するための前記手段は、前記D2Dリソースの割振りを求める要求が必要とされないことを前記第2のレイヤに対して示すために、前記少なくとも1つのフラグのうちの第1のフラグを設定するように構成される、
C13に記載の装置。
[C15]
共通D2Dリソースの前記セットは前記システム情報の中で示されると決定され、前記RRC状態はRRC接続状態であると決定され、
ここにおいて、前記少なくとも1つのフラグを設定するための前記手段は、前記D2Dリソースの割振りを求める要求が必要とされることを示すために、前記少なくとも1つのフラグのうちの第1のフラグを設定するように構成される、
C13に記載の装置。
[C16]
共通D2Dリソースの前記セットは前記システム情報の中で示されないと決定され、前記RRC状態はRRCアイドル状態であると決定され、
ここにおいて、前記少なくとも1つのフラグを設定するための前記手段は、前記D2Dリソースの割振りを求める要求が必要とされることを前記第2のレイヤに対して示すために、前記少なくとも1つのフラグのうちの第1のフラグを設定するように構成される、
C13に記載の装置。
[C17]
共通D2Dリソースの前記セットは前記システム情報の中で示されないと決定され、前記RRC状態はRRC接続状態であると決定され、
ここにおいて、前記少なくとも1つのフラグを設定するための前記手段は、前記D2Dリソースの割振りを求める要求が必要とされることを前記第2のレイヤに対して示すために、前記少なくとも1つのフラグのうちの第1のフラグを設定するように構成される、
C13に記載の装置。
[C18]
前記システム情報はD2D通信に対して受信されていると決定され、ここにおいて、共通D2Dリソースのセットが前記システム情報の中で示され、前記装置が、
共通D2Dリソースの前記セットを使用してD2D通信を行うための手段と、
共通D2Dリソースの前記セットを通じた前記D2D通信を停止させるための手段と、
RRCアイドル状態からRRC接続状態へ遷移するための手段とをさらに備え、
ここにおいて、前記RRCアイドル状態から前記RRC接続状態へ遷移すると、前記少なくとも1つのフラグが設定され、
ここにおいて、前記少なくとも1つのフラグを設定するための前記手段は、前記D2Dリソースの前記割振りを求める要求が必要とされることを示すために、前記少なくとも1つのフラグのうちの第1のフラグを設定するように構成される、
C12に記載の装置。
[C19]
前記システム情報はD2D通信に対して受信されていると決定され、ここにおいて、共通D2Dリソースのセットが前記システム情報の中で示されず、前記装置は、
割り振られたD2Dリソースのセットを使用してD2D通信を行うための手段と、
前記割り振られたD2Dリソースのセットの前記使用の取消しを受信するための手段とをさらに備え、
ここにおいて、前記少なくとも1つのフラグを設定するための前記手段は、前記D2Dリソースの前記割振りを求める要求が必要とされることを示すために、前記少なくとも1つのフラグのうちの第1のフラグを設定するように構成される、
C12に記載の装置。
[C20]
前記システム情報はD2D通信に対して受信されていないと決定され、前記少なくとも1つのフラグを設定するための前記手段は、D2D通信がサポートされないことを示す、前記少なくとも1つのフラグのうちのフラグを設定するように構成され、ここにおいて、前記D2Dリソースは、ヌルセットであると決定される、C11に記載の装置。
[C21]
ワイヤレス通信のための装置であって、
メモリと、
前記メモリに結合された少なくとも1つのプロセッサとを備え、前記少なくとも1つのプロセッサは、
システム情報がデバイス間(D2D)通信に対して受信されるかどうかを決定し、
前記システム情報が受信されるとき、前記システム情報に基づいて少なくとも1つのフラグを設定し、
前記少なくとも1つのフラグに基づいてD2Dリソースを決定するように構成され、ここにおいて、前記UEの第1のレイヤが、前記システム情報を受信し、前記少なくとも1つのフラグを設定し、前記第1のレイヤよりも上位の第2のレイヤが、前記少なくとも1つのフラグを検査し、前記D2Dリソースを決定するように前記第1のレイヤに要求する、
装置。
[C22]
前記システム情報はD2D通信に対して受信されていると決定され、ここにおいて、前記少なくとも1つのプロセッサは、
共通D2Dリソースのセットが前記システム情報の中で示されるかどうかを決定し、
前記UEの無線リソース制御(RRC)状態を決定するようにさらに構成され、
ここにおいて、前記少なくとも1つのフラグは、前記共通D2Dリソースの前記セットが前記システム情報の中で示されるかどうかに基づいて、および前記決定されたRRC状態に基づいて設定される、
C21に記載の装置。
[C23]
共通D2Dリソースの前記セットは前記システム情報の中で示されると決定され、前記RRC状態はRRCアイドル状態であると決定され、
ここにおいて、前記少なくとも1つのプロセッサは、前記D2Dリソースの割振りを求める要求が必要とされないことを前記第2のレイヤに対して示すために、前記少なくとも1つのフラグのうちの第1のフラグを設定することによって、前記少なくとも1つのフラグを設定するように構成される、
C22に記載の装置。
[C24]
共通D2Dリソースの前記セットは前記システム情報の中で示されると決定され、前記RRC状態はRRC接続状態であると決定され、
ここにおいて、前記少なくとも1つのプロセッサは、前記D2Dリソースの割振りを求める要求が必要とされることを示すために、前記少なくとも1つのフラグのうちの第1のフラグを設定するようにさらに構成される、
C22に記載の装置。
[C25]
共通D2Dリソースの前記セットは前記システム情報の中で示されないと決定され、前記RRC状態はRRCアイドル状態であると決定され、
ここにおいて、前記少なくとも1つのプロセッサは、前記D2Dリソースの割振りを求める要求が必要とされることを前記第2のレイヤに対して示すために、前記少なくとも1つのフラグのうちの第1のフラグを設定するようにさらに構成される、
C22に記載の装置。
[C26]
共通D2Dリソースの前記セットは前記システム情報の中で示されないと決定され、前記RRC状態はRRC接続状態であると決定され、
ここにおいて、前記少なくとも1つのプロセッサは、前記D2Dリソースの割振りを求める要求が必要とされることを前記第2のレイヤに対して示すために、前記少なくとも1つのフラグのうちの第1のフラグを設定するように構成される、
C22に記載の装置。
[C27]
前記システム情報はD2D通信に対して受信されていると決定され、ここにおいて、共通D2Dリソースのセットが前記システム情報の中で示され、ここにおいて、前記少なくとも1つのプロセッサは、
共通D2Dリソースの前記セットを使用してD2D通信を行い、
共通D2Dリソースの前記セットを通じた前記D2D通信を停止させ、
RRCアイドル状態からRRC接続状態へ遷移するようにさらに構成され、
ここにおいて、前記RRCアイドル状態から前記RRC接続状態へ遷移すると、前記少なくとも1つのフラグが設定され、
ここにおいて、前記少なくとも1つのプロセッサは、前記D2Dリソースの前記割振りを求める要求が必要とされることを示すために、前記少なくとも1つのフラグのうちの第1のフラグを設定するように構成される、
C21に記載の装置。
[C28]
前記システム情報はD2D通信に対して受信されていると決定され、ここにおいて、共通D2Dリソースのセットが前記システム情報の中で示されず、ここにおいて、前記少なくとも1つのプロセッサは、
割り振られたD2Dリソースのセットを使用してD2D通信を行い、
前記割り振られたD2Dリソースのセットの前記使用の取消しを受信するようにさらに構成され、
ここにおいて、前記少なくとも1つのプロセッサは、前記D2Dリソースの前記割振りを求める要求が必要とされることを示すために、前記少なくとも1つのフラグのうちの第1のフラグを設定するように構成される、
C21に記載の装置。
[C29]
前記システム情報はD2D通信に対して受信されていないと決定され、ここにおいて、前記少なくとも1つのプロセッサは、D2D通信がサポートされないことを示す、前記少なくとも1つのフラグのうちのフラグを設定するように構成され、ここにおいて、前記D2Dリソースは、ヌルセットであると決定される、C21に記載の装置。
[C30]
少なくとも1つのプロセッサ上で実行されたとき、
システム情報がデバイス間(D2D)通信に対して受信されるかどうかを決定することと、
前記システム情報が受信されるとき、前記システム情報に基づいて少なくとも1つのフラグを設定することと、
前記少なくとも1つのフラグに基づいてD2Dリソースを決定することと
に前記少なくとも1つのプロセッサにさせるコードを備えるコンピュータ可読媒体。