(57)【特許請求の範囲】
【請求項１】
回路を有するユーザ装置(UE)であって、前記回路は、
ピアUEのグループに対する送信の許可を求めるリクエストをサービングエボルブドノードB(eNodeB)に送信する処理と、
前記リクエストに応答して、グループ識別子を特定するリソース割当指定を受ける処理であって、前記グループ識別子は、当該UEを含むグループと前記ピアUEのグループとを特定する、処理と、
前記サービングeNodeBにより指定されたリソースを利用して、前記ピアUEのグループに対してマルチキャスト送信を行う処理と
を実行し、前記リクエストは当該UEの論理チャネルグループ識別子(LCGID)を含み、送信はもはや許可されない旨の通知を受信したことに基づいて、前記LCGIDの利用を終了する、ユーザ装置。
【請求項２】
前記回路は、バッファステータスレポート(BSR)により前記リクエストを送信するように形成され、
前記グループ識別子は、ロングタームエボリューション(LTE)に関する第3世代パートナーシッププロジェクト(3GPP)標準規格ファミリに属する規格に従うマルチキャストメディアアクセスコントロールレイヤ無線ネットワークテンポラリ識別子(MC-RNTI)である、請求項1に記載のユーザ装置。
【請求項３】
前記リソースがアップリンクリソースであり、
前記リソースは、物理アップリンク共有チャネル(PUSCH)の物理リソースブロック(PRB)を含む、請求項1に記載のユーザ装置。
【請求項４】
前記リソースは、デバイス間通信のために特別に設定された周波数キャリアによる物理リソースブロック(PRB)を含む、請求項1に記載のユーザ装置。
【請求項５】
前記リソース割当指定は、物理ダウンリンク制御チャネル(PDCCH)又はエンハンストPDCCH(ePDCCH)により受信される、請求項1に記載のユーザ装置。
【請求項６】
前記リソース割当指定は、デバイス間通信のシステム情報ブロック(D2D  SIB)のブロードキャストにより受信される、請求項1に記載のユーザ装置。
【請求項７】
処理回路を更に有する請求項1に記載のユーザ装置であって、前記処理回路は、
前記ピアUEのグループを設定するためのシグナリングを開始する処理と、
或るピアUEが前記ピアUEのグループに対して追加又は削除されることを要求する処理であって、前記ピアUEのグループは、前記ピアUEのグループ及び当該UEが同じeNodeBのカバレッジの範囲内にあるほど近くにある、処理と
を実行する、請求項1に記載のユーザ装置。
【請求項８】
前記回路は、
当該UEの論理チャネルグループ識別子(LCGID)を利用して、アップリンクリソースにおける送信の許可を要求する処理と、
送信の許可を受信した場合に、ピアUEによるマルチキャスト送信に応じて、アップリンクリソースを利用して少なくとも1つのマルチキャスト送信フレームを送信する処理と
を更に実行するように形成されている請求項1に記載のユーザ装置。
【請求項９】
前記サービングeNodeBにより指定されるリソースは、セミパーシステントスケジューリングにより割り当てられるリソースである、請求項8に記載のユーザ装置。
【請求項１０】
グループのデバイス間通信を制御するためのエボルブドノードB(eNodeB)であって、
当該eNodeBによりサービングされるピアUEのグループに対してマルチキャストメッセージを送信する許可を求めるリクエストを、当該eNodeBによりサービングされるユーザ装置(UE)から受信する、ように形成される通信インタフェースと、
(i)前記リクエストに基づいて前記UEにアップリンクリソースを指定する処理であって、前記アップリンクリソースのリソース付与は、前記ピアUEのグループに対するグループ識別子と要求を行っている前記UEのメンバ識別子とを特定している、処理と、(ii)前記ピアUEのグループに対するマルチキャストメッセージを送信する許可を求めるために前記ピアUEのグループに属するピアUEから、論理チャネルグループ識別子(LCGID)を含むリクエストを受信する処理と、(iii)送信はもはや許可されないことを前記ピアUEに通知し、前記マルチキャストメッセージの送信に関する前記LCGIDの利用を終了する処理とを行うように形成される1つ以上のプロセッサと
を有するエボルブドノードB。
【請求項１１】
前記1つ以上のプロセッサは、前記ピアUEのグループに属するUEが、当該eNodeBによりサービングされる地理的領域から去りつつあることを判断するように更に形成され、
前記通信インタフェースは、前記ピアUEのグループの前記グループ識別子を含む協調情報を、当該eNodeBによりサービングされる地理的領域を去りつつあるUEをサービングすることになる第2のeNodeBに送信するように更に形成されている、請求項10に記載のエボルブドノードB。
【請求項１２】
マルチキャストのデバイス間通信を行うためにユーザ装置(UE)が実行する方法であって、
ピアUEのグループに対する送信の許可を要求するために、前記UEの論理チャネルグループ識別子(LCGID)を含むバッファステータスレポート(BSR)を、エボルブドノードB(eNodeB)に送信するステップと、
前記BSRの送信に応答してリソース割当指定を受けるステップであって、前記リソース割当指定は、前記ピアUEのグループのグループ識別子と前記UEのメンバ識別子とを特定している、ステップと、
前記リソース割当指定により割り当てられたアップリンクデバイス間通信のリソースにより、前記グループ識別子により特定されるピアUEのグループに対してマルチキャスト送信を行うステップと
を有し、送信はもはや許可されない旨の通知を受信したことに基づいて、前記LCGIDの利用を終了する、方法。
【請求項１３】
前記ピアUEのグループを設定するためのシグナリングを開始するステップと、
前記開始するステップに応じて、前記ピアUEのグループの前記グループ識別子を受信するステップと
を更に有する請求項12に記載の方法。
【請求項１４】
前記ピアUEのグループに対して或るピアUEが追加又は削除されることを要求するステップを更に有する請求項13に記載の方法。
【請求項１５】
前記グループ識別子は、ロングタームエボリューション(LTE)に関する第3世代パートナーシッププロジェクト(3GPP)標準規格ファミリに属する規格に従うマルチキャストメディアアクセスコントロールレイヤ無線ネットワークテンポラリ識別子(MC-RNTI)である、請求項12に記載の方法。
【請求項１６】
前記リソースは、アップリンク周波数キャリアによる物理アップリンク共有チャネル(PUSCH)の物理リソースブロック(PRB)、又は、デバイス間通信のために特別に設定された周波数キャリアによる物理リソースブロックを含む、請求項15に記載の方法。
【請求項１７】
前記リソース割当指定は、
物理ダウンリンク制御チャネル(PDCCH)又はエンハンストPDCCH(ePDCCH)、或いは
デバイス間通信のシステム情報のブロードキャスト(D2D  SIB)
により受信される、請求項12に記載の方法。
【請求項１８】
前記リソース割当指定が物理レイヤパラメータを更に特定し、前記物理レイヤパラメータは、送信電力と変調及び符号化の方式とのうちの少なくとも1つを含む、請求項17に記載の方法。
【請求項１９】
前記リソース割当指定により割り当てられるリソースは、セミパーシステントスケジューリングにより割り当てられるリソースである、請求項12に記載の方法。
【請求項２０】
グループのデバイス間通信を制御するためにエボルブドノードB(eNodeB)が実行する方法であって、
ピアUEのグループに対してマルチキャストメッセージを送信する許可を求めるリクエストをユーザ装置(UE)から受信するステップであって、前記ピアUEのグループは、前記eNodeBによりサービングされる地理的領域内に存在し、前記リクエストは前記ピアUEの論理チャネルグループ識別子(LCGID)を含む、ステップと、
前記リクエストに基づいて、要求を行っている前記UEにアップリンクリソースを指定するステップであって、前記アップリンクリソースのリソース付与は、前記ピアUEのグループに対するグループ識別子と要求を行っている前記UEのメンバ識別子とを特定している、ステップと
を有し、送信はもはや許可されないことを前記ピアUEに通知し、前記マルチキャストメッセージの送信に関する前記LCGIDの利用を終了する、方法。
【請求項２１】
前記ピアUEのグループに属するUEが、前記eNodeBによりサービングされる地理的領域から去りつつあることを判断するステップと、
前記ピアUEのグループの前記グループ識別子を含む協調情報を、前記eNodeBによりサービングされる地理的領域を去りつつあるUEをサービングすることになる第2のeNodeBに送信するステップと
を更に有する請求項20に記載の方法。
【請求項２２】
請求項１２〜２１のうちの何れか１項に記載の方法をコンピュータに実行させるコンピュータプログラム。
【請求項２３】
請求項２２に記載のコンピュータプログラムを記憶する記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
実施形態は無線通信に関連する。一実施形態はマルチキャストのデバイス間通信を支援することに関連する。一実施形態はマルチキャストのデバイス間通信の制御に関連する。
【背景技術】
【０００２】
現在の第3世代パートナーシッププロジェクト(3GPP)ロングタームエボリューション(LTE)標準仕様(規格)は、デバイス間(device-to-device：D2D)通信の条件を規定している。そのような通信は2つのデバイスの間でなされるが、現在のシステムはD2Dマルチキャスト通信を提供するように対応していなくてもよい。更に、そのような通信が、あるデバイスからピアデバイスのグループへのマルチキャストD2D処理に拡張される場合、そのような通信の協調(又は制御又は管理又は調整又は連係)(coordination)は、エボルブドノードB(eNodeB、eNB)のような複数のネットワーク側要素からの入力を必要とするかもしれない。一方、ピアユーザ装置(UE)の幾つかのグループが1つのノードBの通信範囲内に属する場合があり、そのようなシステム(群)の制御は簡易である。
【０００３】
＜関連出願＞
本願は、2012年12月17日付けで出願された米国出願第13/716,919号による優先的利益を享受し、この米国出願は2012年7月2日付けで出願された米国仮特許出願第61/667,325号による優先的利益を享受し、これらの出願は何れも本願のリファレンスに組み入れられる。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】米国特許出願公開第2012-0129540号明細書
【特許文献２】国際公開第2011-088609号パンフレット
【特許文献３】国際公開第2011-051745号パンフレット
【発明の概要】
【発明が解決しようとする課題】
【０００５】
従って、デバイス間マルチキャスト通信を実行可能にする又は最適化するための方法及び装置等を提供することが一般に望まれる。更に、デバイスのグループがeNodeBにより管理される地理的領域に属している場合の連係法を提供することも一般に望まれている。
【課題を解決するための手段】
【０００６】
一実施形態によるユーザ装置は、
回路を有するユーザ装置(UE)であって、前記回路は、
ピアUEのグループに対する送信の許可を求めるリクエストをサービングエボルブドノードB(eNodeB)に送信する処理と、
前記リクエストに応答して、グループ識別子を特定するリソース割当指定を受ける処理であって、前記グループ識別子は、当該UEを含むグループと前記ピアUEのグループとを特定する、処理と、
前記サービングeNodeBにより指定されたリソースを利用して、前記ピアUEのグループに対してマルチキャスト送信を行う処理と
を実行する、ユーザ装置である。
【図面の簡単な説明】
【０００７】
【図１】一実施形態による無線通信ネットワークの一部を例示する図。
【図２】一群のUEとeNodeBとの間の一実施形態による処理フローを示す図。
【図３】一実施形態における管理データベースの一例を示す図。
【図４】一実施形態によるユーザ装置(UE)のブロック図。
【図５】一実施形態によるeNodeBのブロック図。
【図６】一実施形態によるマルチキャストのデバイス間通信のための手順を示すフローチャート。
【図７】一実施形態によるグループのデバイス間通信を制御するための処理手順を示すフローチャート。
【発明を実施するための形態】
【０００８】
本説明及び図面は、開示内容を当業者が実施できる程度に十分に記載されている。実施形態は、構造の変更、論理の変更、電気的な変更、手順の変更その他の変更を取り込んでもよい。実施形態に対する様々な変形は当業者にとって自明であり、本願で説明される一般的な原理は、本願の開示範囲から逸脱することなく、他の実施形態や用途に適用されてよい。更に、以下の説明において、様々な具体的な詳細な事項が説明を目的として述べられている。しかしながら、それらの具体的な詳細な事項によらずに実施形態が実現されてもよいことを、当業者は認めるであろう。また、発明者等にとって従来の構造及び処理は、不要な詳細事項により実施形態の説明を曖昧にしないように、ブロック図形式で示される。本願の開示内容は記載されている実施形態に限定されるようには意図されておらず、本願で開示される原理及び特徴に合致する最も広い範囲に従って解釈されるべきである。
【０００９】
図1は実施形態が使用されてもよい無線通信ネットワーク100の一部を示す。一実施形態において、無線通信ネットワーク100は、第3世代パートナーシッププロジェクト(3GPP)ロングタームエボリューション(LTE)標準仕様を利用するエボルブドユニバーサル地上無線アクセスネットワーク(EUTRAN)を含む。一実施形態において、無線通信ネットワーク100はエボルブドノードB(eNodeB、eNB)を含む。1つのeNodeBしか描かれていないが、無線通信システム100は1つより多いeNodeB110を含んでよいことが理解されるであろう。
【００１０】
eNodeB110は所定の地理的領域、すなわちセル(サービングセル)120を管理する。UE130-1〜130-nがセル120の範囲内に属している場合、その1つ以上のユーザ装置(UE)130-1〜130-nはeNodeBに関連している。1つ以上のUE130-1〜130-nは、以後、「ピアUE」と言及される場合がある。ピアUE130-1〜130-nは、アップリンク/ダウンリンクペア140-1〜140-nを介してeNodeB110と通信する。
【００１１】
ピアUE130-1〜130-nのうちの1つ以上のUEは、他のピアUE130-1〜130-nに対してマルチキャスト通信を実行してもよい。ピアUE130-1〜130-nは、典型的には、人間のユーザにより制御、使用又は操作されるタイプのUEであってよい。例えば、ピアUE130-1〜130-nは、スマートフォン、タブレットコンピュータ又はラップトップコンピュータであってもよい。ピアUE130-1〜130-nはアップリンクA及びBを介して互いに通信してもよい。図1では、UE130-1がUE130-2及びUE130-nに送信している様子を示しているが、任意のピアUE130-1〜130-nが、他の任意のピアUE130-1〜130-nに或いはセル120内の他のUE(図示せず)に送信を行ってよいことが、理解されるであろう。ピアUE130-1〜130-nは他のセルに属する他のUE(図示せず)と更に通信してもよい。
【００１２】
何らかのピアトゥピア(P2P)通信が受動的になされてもよく、すなわち、ピアUE130-1〜130-nのうちの何れかが、マルチキャスト送信の大部分又は全部を実行する一方、他のピアUE130-1〜130-nがそのマルチキャストを受動的に受信(listen)してもよい。例えば、ピアUE130-1〜130-nは、他のピアUE130-1〜130-nによる広告を受動的に受信してもよい。
【００１３】
一方、ピアUE130-1〜130-nは、より緻密なリソースの割り振りを要するインタラクティブマルチキャスト送信又は双方向マルチキャスト送信(interactive  multicast  transmission)を実行してもよい。特に、インタラクティブマルチキャスト送信はアップリンクリソースの割り振りにより実現又は実行されてもよい。
【００１４】
現在の方式は、連係したマルチキャストのデバイス間(coordinated  multicast  D2D)送信を実現又は最適化する機能を備えていない。現在の第3世代パートナーシッププロジェクト(3GPP)ロングタームエボリューション(LTE)標準仕様は、インタラクティブマルチキャストD2D通信を実現又は最適化するようには拡張できないシングルD2D通信を提供しているに過ぎない。Wi-Fiダイレクト(商標)(「Wi-FiP2P」のように言及されてもよい)はD2Dマルチキャスト送信に関する連係及びその他の機能を提供するかもしれない。しかしながら、Wi-Fiダイレクト方式は、ピアUE130-1〜130-nが互いにWi-Fi通信範囲内に属したままであることを必要とする。マルチメディアブロードキャストマルチキャストサービス(MBMS)は、ピアUE130-1〜130-nの間でのインタラクティブマルチキャストの機能を提供することなく、専ら、UEによる受動的な受信を許容しているに過ぎない。
【００１５】
一実施形態は、ピアUE130-1〜130-nの間における直接的な通信(ダイレクト通信)の機能を提供する。一実施形態は、ピアUE130-1〜130-nの間における直接的なアップリンクマルチキャスト送信のためのeNodeB機能をもたらす。
【００１６】
一実施形態では、ピアUE130-1〜130-nは互いに近接していてもよく、ピアUE130-1〜130-nは少なくともマルチキャスト送信の期間内で小さな移動度しか示さない。一実施形態において、eNodeB110は、ピアUE130-1〜130-nが互いに通信できるようにするレイヤ2モデレータ(仲介装置)として機能してもよい。一実施形態はインタラクティブマルチキャストD2D通信を実行、実現又は最適化するが、一実施形態は受動的な一方向のマルチキャストD2Dを許容してもよい。一実施形態は、マルチキャストマシンタイプ通信(multicast  machine-type  communication)を実行、実現又は最適化してもよい。例えば、一実施形態は、人間による介在なしに通常的に動作するタイプのUE同士の間でマルチキャスト通信を行うために使用されてもよい。
【００１７】
図2は、eNodeBにより制御される一群のモバイル装置UE1、UE2、UE3の間におけるマルチキャストD2D通信の動作フローの一例を示す。UE1、UE2、UE3のようなUEは、ピアUE130-1〜130-n(図1)に適している。図示の例において、UE1は、UE2及びUE3である他のUEのグループに対するグループオーナー又はスポンサの役割を果たす。3つのUEが例示的に示されているが、任意の台数のUEがグループに所属してよいことが理解されるであろう。
【００１８】
メッセージ1により、グループオーナーとして機能するUE1は、ローカルグループコンフィギュレーションを要求する。UE1はそのグループのグループIDを提供し、UE1はグループメンバUE2及びUE3のユーザ識別子を提供してもよい。グループの設定、招集及びメンバーシップは、例えば「ネットミーティング」、グループチャットアプリケーション、スカイプ(Skype)等のようなアプリケーションレイヤシグナリングを介してピアアプリケーション間で直接的に決定及び設定されてもよいし、或いは、不図示のネットワークサーバを介して決定及び設定されてもよい。代替的に、eNodeBに対するアクセスストラタム(AS)メッセージによりリクエスト又は要求がなされてもよい。
【００１９】
これに応答して、メッセージ2により、eNodeBは、対応するリンク140-1〜140-nにおけるグループ通信のグループ識別子を提供してもよい。グループ識別子は、3GPP標準規格ファミリに属する規格に従うマルチキャストメディアアクセスコントロールレイヤ無線ネットワークテンポラリ識別子(MC-RNTI)であってもよい。eNodeBは、UE1、UE2、UE3のようなUEに対するメンバ識別子を更に提供してもよい。eNodeBは、マルチキャストD2D送信を実行する送信権限(送信権)を有するグループメンバに論理チャネルグループ識別子(LCGID)を更に提供する。これらのパラメータ及び他の準静的な無線パラメータ(例えば、電力制限等)は、無線リソース制御(RRC)シグナリングにより設定されてもよい。追加的又は代替的に、グループ管理装置(図示せず)がグループの管理機能を提供してもよい。グループ管理装置はeNodeBから分離していてもよい。
【００２０】
eNodeB又はグループ管理装置は、グループ識別子及びユーザの論理チャネルを対応付けて管理するためのテーブルを、例えばメモリの中で維持してもよい。図3は少なくとも1つの実施形態におけるテーブルの具体例を示す。図示の例において、eNodeBは2つの論理チャネルID(グループID1及びグループID2)とともに2つのグループを管理する。これらのグループは、アプリケーションレベルのIPアドレスMC-IP1、MC-IP2及びグループ識別子MC-RNTI1、MC-RNTI2を有する。グループのメンバにはMemIDが割り当てられ(指定され)、上述したようにリソースの割当の際にeNodeBが(MemIDを)ブロードキャストする。
【００２１】
一実施形態において、MemID1の指定を受けたメンバは、2つのグループのメンバである。MemID1の指定を受けたメンバがアップリンクでマルチキャストデータを送信する場合に、そのマルチキャストデータが関連しているグループ(が何れであるか)は、そのメンバから送信されたグループパラメータに基づいて判断される。
【００２２】
図2を再び参照すると、グループを設定する場合に、UE1は、先ずメッセージ3によりトークンを要求することで、UE2及びUE3に対するマルチキャストD2D通信の準備を開始する。トークンは、マルチキャスト送信を実行するための許可(許可されていること)を表し、UE1はそのトークンのリクエスト(要求)をeNodeBに送信してもよい。トークンのリクエストは、バッファステータスレポート(BSR)の一部として送信されてもよい。UE1がアップリンクでeNodeBにデータを既に送信している場合には、UE1は何時でもトークンリクエストをBSRに含めてよい。第2の代替例として、UE1は物理アップリンク制御チャネル(PUCCH)でステータスレポートを送信し、UE1はアップリンクリソースの割り当てを受けてもよい。第2の代替例の場合、UE1は、アップリンクリソースの割り当てを受けた場合に、トークンリクエストをBSRで送信してよい。第3の代替例として、ランダムアクセスに利用可能なプリアンブル、又は、eNodeBがRRCコンフィギュレーションによりグループのために特別に設定したプリアンブルとともに、UE1はランダムアクセスチャネル(RACH)で送信のスケジューリングを要求してもよい。RACHレスポンスを受信すると、UE1は、RACHスケジューリング送信によりトークンリクエストを送信してよい。
【００２３】
トークンリクエストは、UE1の論理チャネルグループ識別子(LCGID)を含んでもよい。これにより、eNodeBはマルチキャストD2D送信を要求しているUE1を特定し、eNodeBはそのようなD2D通信に使用されるアップリンクチャネルリソースを付与する。eNodeBは、例えば、物理ダウンリンク制御チャネル(PDCCH)、エンハンストPDCCH(ePDCCH)又はD2Dシステム情報ブロック(SIB)により、グループに属する全てのUE1、UE2、UE3に対して、ブロードキャストリソース指定メッセージを送信してもよい。そのブロードキャストメッセージの中に、eNodeBは、グループMC-RNTIと送信するUE1のメンバ識別子(MemID)とを含めている。PDCCHが使用される場合、グループに属するUEsは、MC-RNTIを利用してダウンリンク制御インジケータ(DCI)のマスクを解除する。従って、MC-RNTIを利用することにより、グループに属する何れのUEsもMC-RNTIを利用して有効なDCIを検出することができ、UEsは、以後、割り当てられたアップリンクリソースチャネルでマルチキャストコンテンツを受信することができる。ブロードキャストメッセージはD2Dマルチキャスト通信に関する他のパラメータを含んでいてもよく、他のパラメータは例えば変調符号化方式(MCS)、送信モード、最大電力レベル等である。そして、UEは、eNodeBが設定するような最大電力設定によるオープンループ電力制御を適用してもよい。
【００２４】
UE1は、その後に、割り当てられたD2DチャネルリソースでマルチキャストD2D送信を実行してよい。そして、何れかのUEs(UE2又はUE3)が、割り当てられたアップリンクチャネルリソースで通信内容を受信する場合に、UEs(UE2及びUE3)はMC-RNTIに基づいてその通信がグループ通信であることを判断してもよい。UEs(UE2及びUE3)は、eNodeBからのD2Dリソース割当に含まれているMemIDに基づいて、通信がUE1から送信されていることも確認できる。
【００２５】
同様に、メッセージ4により、UE2はマルチキャストD2D通信を実行する許可のトークンを要求してもよい。eNodeBは、同様に、アップリンクチャネルリソースを指定し、MC-RNTIとUE2のMemIDとを含むメッセージをブロードキャストする。そして、UE2は、アップリンクチャネルリソースでマルチキャストD2D送信を実行してよい。
【００２６】
eNodeBは、リソースに関するセミパーシステントスケジューリングを適用してもよい。例えば、eNodeBは、UEがトークンリクエストを作成する毎にリソースをスケジューリングしなくてよい(リソースの割り当て処理を実行しなくてよい)。そうではなく、それぞれの送信の際にトークンリクエストを必要とせずにUEが複数の時間に送信してよいように、(最初のトークンリクエストに対して)eNodeBは複数のリソースを割り当ててもよい。
【００２７】
図4は実施の形態によるUE400の基本構成を示す。UE400は、ピアUE130-1〜130-n(図1)又はUE1、UE2、UE3(図2)等に適している。UE400は一実施形態によるマルチキャストD2D通信方法をサポートしている(利用可能である)。UE400は、基地局(BS)、eNodeB110又は他のタイプの無線ローカルエリアネットワーク(WLAN)アクセスポイント等と通信するように形成された1つ以上のアンテナ410を含む。UE400は、プロセッサ420、命令425、メモリ430を更に有する。UE400は通信インタフェース440を更に有する。一実施形態において、メモリ430は、ランダムアクセスメモリ(RAM)、ダイナミックRAM(DRAM)、スタティックRAM(SRAM)、同期(DRAM)、ダブルデータレート(DDR)SDRAM(DDR-SDRAM)、又はデータの高速バッファリングを実行することが可能な任意の装置等を含んでよいが、これらに限定されない。
【００２８】
実施形態は、図2を参照しながら上述したように、UE400が、ピアUE130-1〜130-nに対してマルチキャストD2D送信を実行すること、及び、マルチキャストD2D送信に応答することを可能にする。少なくとも1つの実施形態において、通信インタフェース440は、例えば、複数入力/複数出力(MIMO)方式に従って動作する無線物理レイヤである。図2を参照しながら上述したように、UE400がグループオーナーである場合、UE400は、ピアUE130-1〜130-nのグループの設定(コンフィギュレーション)を要求する。通信インタフェース440は、ピアUE130-1〜130-n(図1)のグループに対する送信の許可を求めるリクエストをサービングeNodeBに送信する。通信インタフェース440は、バッファステータスレポート(BSR)の中でリクエストを送信してもよい。リクエストは、UE400の論理チャネルグループ識別子(LCGID)を含んでもよい。リクエストは、アップリンクにおけるトークンリクエストの形式であってもよい。リクエストに関する更なる詳細事項については図2を参照しながら説明されている。
【００２９】
通信インタフェース440は、リクエストに応答して、リソース割当指定を受ける。図2を参照しながら上述したように、通信インタフェース440は、物理ダウンリンク制御チャネル(PDCCH)又はエンハンストPDCCH(ePDCCH)を通じてリソース割当指定を受けてもよい。通信インタフェース440は、D2Dシステム情報ブロック(D2D  SIB)のブロードキャストを通じて、リソース割当指定を受けてもよい。リソースは、例えば、物理アップリンク共有チャネル(PUSCH)の1つ以上のリソースブロック(PRB)を含んでもよい。リソースは、D2D通信用に特別に設定された周波数キャリア上にあってもよい。
【００３０】
通信インタフェース440は、ピアUE130-1〜130-nのグループのうちのピアUEからのマルチキャストに応答してもよい。応答は、UE400の論理グループチャネル識別子を利用して、アップリンクリソースで送信を行う許可を要求することを含んでもよい。通信インタフェース440は、バッファステータスレポート(BSR)の中でリクエストを送信してもよい。リクエストは、UE400の論理チャネルグループ識別子(LCGID)を含んでもよい。リクエストはアップリンクにおけるトークンリクエストの形式であってもよい。
【００３１】
送信する許可を受信すると、通信インタフェース440は、サービングeNodeB110により指定されたリソースを利用して、ピアUE130-1〜130-nのグループに対して少なくとも1つのマルチキャスト送信フレームを送信してもよい。
【００３２】
上述したように、リソース割当指定は、グループ識別子を指定してもよい。グループ識別子は、UE400を含むグループとピアUE130-1〜130-nのグループ(図1)とを含むグループを特定してもよい。リソースはアップリンクリソースであってもよい。グループ識別子は、3GPP標準規格ファミリに属する規格に従うマルチキャストメディアアクセス制御例や無線ネットワークテンポラリ識別子(MC-RNTI)であってもよい。
【００３３】
プロセッサ420は、アンテナ410を介してネットワークから受信した信号をUE400が処理できるようにする論理手段又はコードを含んでもよい。プロセッサ420は、マルチキャストD2D送信信号をUE400が送信すること、マルチキャストD2D送信信号をUE400が受信すること、又は、マルチキャストD2D送信信号にUE400が応答することを可能にするコード又はその他の命令425を含んでもよい。命令425は、ピアUE130-1〜130-nのグループ(図1)を設定するためのシグナリングをUE400が開始すること、及び、ピアUE130-1〜130-nのグループに対して或るピアUE130-1〜130-nが追加又は削除されることをUE400が要求すること等を可能にしてもよい。命令425は、送信する権限(送信権)が取り消される旨の通知をUE400が受信すること、及び、その通知に基づいてUE400がLCGIDの使用を止めることを可能にしてもよい。命令425は追加的又は代替的にメモリ430の中に存在してもよい。従って、プロセッサ420及びメモリ430は、コンピュータにより読み取られることが可能な媒体を含んでもよい。
【００３４】
図5は実施の形態によるeNodeB500の詳細を示すブロック図である。eNodeB500はeNodeB110(図1)又はeNodeB(図2)等に適している。eNodeB500はグループD2D通信を制御する。eNodeB500は、プロセッサ510、メモリ520、トランシーバ530及び命令535を含む。eNodeB500は他の要素(図示せず)も含む。
【００３５】
プロセッサ510は、1つ以上の中央処理ユニット(CPU)、グラフィック処理ユニット(GPU)、又は双方を有する。プロセッサ510は、eNodeB500のための処理及び制御機能を提供する。メモリ520は、eNodeB500に関するデータ及び命令535を保存するように形成された1つ以上の一時的及び静的なメモリユニットを有する。メモリ520は、更に、図3に示されるテーブルのようなテーブルを保存するように形成されてもよい。
【００３６】
トランシーバ530は、複数入力複数出力(MIMO)通信を行うためのMIMOアンテナを含む1つ以上のトランシーバを有する。トランシーバ530は、特に、UE130-1〜130-n(図1)に関するアップリンク送信信号を受信しかつダウンリンク送信信号を送信する。
【００３７】
命令535は、コンピュータ装置(又はマシン)に上記の任意の方法を実行させるように、コンピュータ装置(又はマシン)で実行される1つ以上の一群の命令又はソフトウェアを有する。命令535(コンピュータ又はマシンにより実行可能な命令と言及されてもよい)は、eNodeB500による実行の際にプロセッサ510及び/又はメモリ520の中に、完全に又は少なくとも部分的に存在していてもよい。プロセッサ510及びメモリ520はマシン読み取り可能媒体を有していてもよい。
【００３８】
トランシーバ530は、eNodeB500により管理されるUEからのリクエストを受信する。例えば、トランシーバ530は、ピアUE130-1〜130-n(図1)のうちの1つ以上から、或いはUE1、UE2又はUE3(図2)から、リクエストを受信してもよい。リクエストは、ピアUEのグループに対してマルチキャストメッセージを送信する許可を求めるものである。ピアUEのグループはeNodeB500により管理されていてもよい。
【００３９】
プロセッサ510は、リクエストに基づいて、要求を行っているUEにアップリンクリソースを割り振ってもよい。アップリンクリソースのリソース付与は、ピアUEのグループのグループ識別子と、要求を行っているUEのメンバー識別子とを指定してもよい。
【００４０】
プロセッサ510は、ピアUE130-1〜130-nのうちの1つ以上が、eNodeB110(図1)により管理されているセル又は地理的領域を立ち去った又は立ち去りつつあること(或いは、去りつつあるか否か)を確認してもよい。プロセッサ510は、第2のeNodeB又は次のeNodeB(図示せず)に連係情報(coordination  information)を送信してもよい。連係情報は、ピアUE130-1〜130-nのグループに対するグループ識別子を含んでもよい。次のeNodeBは、1つ以上のピアUE130-1〜130-nが立ち入った地理的領域を管理している。
【００４１】
プロセッサ510は、マルチキャストメッセージを送信する許可を求めるリクエストを処理する。リクエストは、ピアUE130-1〜130-nのグループに属する1つ以上のピアUE130-1〜130-nから受信されてもよい。
【００４２】
図6は、マルチキャストD2D通信を行うために、例えばピアUE130-1〜130-nのようなUEが実行する動作を示す。図示の例では、UE130-1がこれらの処理を実行する。しかしながらピアUE130-1〜130-nのうちの1つ以上の任意のUEがこれらの処理を実行してもよいことが理解されるであろう。
【００４３】
処理610において、UE130-1は、ピアUE130-1〜130-nのグループに対する送信の許可を要求するために、バッファステータスレポート(BSR)を(eNodeB)110に送信する。BSRはUE130-1の論理チャネルグループ識別子(LCGID)を含む。
【００４４】
処理620において、UE130-1は、BSRの送信に応答してリソース割当指定を受ける。リソース割当指定は、ピアUE130-1〜130-nのグループのグループ識別子を特定していてもよい。グループ識別子は、3GPP標準規格ファミリに属する規格に従うマルチキャストメディアアクセスコントロールレイヤ無線ネットワークテンポラリ識別子(MC-RNTI)であってもよい。UE130-1は、D2Dシステム情報ブロードキャストによりリソース割当指定を受けてもよい。リソース割当指定は、UEのメンバ識別子を特定していてもよい。リソース割当指定は、図2を参照しながら上述したような物理レイヤパラメータを更に特定してもよい。物理レイヤパラメータは、送信電力を含んでもよい。そのような物理レイヤパラメータは、データ変調及びチャネル符号化の方式(伝送フォーマット)を含んでもよい。
【００４５】
処理630において、リソース割当指定により割り当てられたアップリンクD2D通信リソースにより、ピアUE130-1〜130-nのグループに対してマルチキャスト送信を行ってもよい。UE130-1は、送信がもはや許可されない旨の通知を受信した場合に、そのLCGIDの利用を終了する。
【００４６】
UE130-1は、ピアUE130-1〜130-nのグループを設定するためのシグナリングを開始してもよい。例えば、UE130-1は本願において詳細に説明されるグループスポンサとして機能してもよい。その「開始」に応じて、UE130-1は、ピアUE130-1〜130-nのグループに対するグループ識別子(MC-RNTI)を受信してもよい。UE130-1は、グループスポンサとして機能する場合、ピアUE130-1〜130-nが、ピアUE130-1〜130-nのグループに追加されること或いはピアUE130-1〜130-nのグループから排除されること、を要求してもよい。
【００４７】
図7は、グループD2D通信を制御するために、例えばeNodeB110であるeNodeBにより実行される処理を示す。処理710において、eNodeB110は、ピアUEのグループに対してマルチキャストメッセージを送信する許可を求めるリクエストをUEから受信する。例えば、eNodeB110は、UE130-2及び130-nに対してマルチキャストメッセージを送信するための許可を求めるリクエストを、UE130-1から受信する。ピアUEのグループは、eNodeB110により管理される地理的領域内に存在していてもよい。
【００４８】
処理720において、eNodeB110は、リクエストに基づいて、UE130-1に対してアップリンクリソースを指定する。アップリンクリソースのリソース付与は、ピアUEのグループに対するグループ識別子と要求を行っているUEのメンバ識別子(目下の例では、UE130-1)とを特定してもよい。
【００４９】
eNodeB110は、ピアUEのグループに属する或るUEがeNodeB110により管理される地理的領域を去りつつあること(又は去りつつあるか否か)を確認してもよい。そして、eNodeB110は、第2のeNodeBに連係情報を送信してもよい。連係情報は、ピアUEのグループのグループ識別子を含んでもよい。第2のeNodeB(図示せず)は、eNodeB110により管理される地理的領域を去りつつあるUEを管理することになる。
【００５０】
上記の実施形態は、上記の技術を実現する命令(又はコンピュータプログラム)を実行するプロセッサを含む様々なハードウェア形態で実施されてもよい。そのような命令は適切な記憶媒体に含まれ、メモリその他のプロセッサが使用可能な媒体に転送される。
【００５１】
簡明化のため、上記の説明は、個別的な複数の機能ユニット又はプロセッサを参照しながら実施形態を説明していることが認められるであろう。しかしながら、実施形態の本質から逸脱することなく、様々な機能ユニット群、プロセッサ群又はドメイン群の間で適切な如何なる機能分散形態が使用されてもよいことは、明らかであろう。例えば、個々のプロセッサ群又はコントローラ群により実行されるように説明された機能は、同じプロセッサ又はコントローラにより実行されてもよい。すなわち、参照される特定の機能ユニットは、説明される機能を発揮する適切な手段を指すように示されているに過ぎず、厳密な論理的又は物理的な構造又は組織を限定しているわけではない。
【００５２】
以上、本発明に関する特定事項が実施形態に関連して説明されてきたが、説明された具体的な形態に限定されることは意図されていない。説明された実施形態の様々な特徴は開示内容に従って適切に組み合わせられてよいことを、当業者は認めるであろう。更に、開示内容の範囲から逸脱することなく、様々な修正及び変形が当業者によってなされてよいことが、理解されるであろう。
【００５３】
要約は、技術的開示内容の本質及び要旨を読者が容易に把握できるように、37C.F.R.セクション1.72(b)に従って作成されている。要約は請求項の範囲又は意味を限定又は解釈するためには使用されないという理解の下で提出されている。特許請求の範囲は明細書又は図面により十分にサポートされており、個々の請求項は個々の形態として成立し得る。
【図１】
0005925960.tif 000002
【図２】
0005925960.tif 000003
【図３】
0005925960.tif 000004
【図４】
0005925960.tif 000005
【図５】
0005925960.tif 000006
【図６】
0005925960.tif 000007
【図７】
0005925960.tif 000008