JP2016530748A - 低い呼セットアップレイテンシを要求する複数の同時グループｐｔｔ呼を効率的にサポートするための方法 - Google Patents

Abstract

本開示は、マルチキャストサービスを介したグループ通信に関する。ユーザ機器(UE)が、UEが関心を抱く通信グループを示す登録要求をサーバに送り、あらかじめ確立されたマルチキャストリソースが割り当てられた通信グループの組を示すメッセージを受信し、通信グループの組における各通信グループのグループ識別子にマッピングされた呼識別子を受信し、呼識別子のグループ識別子へのマッピングを記憶し、通信グループの組に関するグループ呼セッションを維持する。サーバは、登録要求を受信し、UEがあらかじめ確立されたグループ呼に関してプロビジョニングされていると判定し、通信グループのグループ識別子を取り出し、グループ識別子に呼識別子をマッピングし、通信グループの組およびマッピングされた呼識別子をUEに通知し、複数のグループ呼をあらかじめ確立されたマルチキャストリソース上に割り当てる。

Description

関連出願の相互参照
本特許出願は、本出願の譲受人に譲渡され、その全体が参照により本明細書に明確に組み込まれる、2013年5月29日に出願された「METHOD FOR EFFICIENTLY SUPPORTING MULTIPLE SIMULTANEOUS GROUP PTT CALLS REQUIRING LOW CALL SETUP LATENCY」と題する米国仮出願第61/828,266号の優先権を主張する。

本開示は、低い呼セットアップレイテンシを要求する複数の同時グループプッシュツートーク(PTT)呼を効率的にサポートすることに関する。

セルラー通信システムは、利用可能なシステムリソースを共有することによって複数のユーザのための双方向通信をサポートすることができる。セルラーシステムは、ブロードキャスト局からユーザへの単方向送信を主にサポートするかまたはそれのみをサポートすることができるブロードキャストシステムとは異なる。セルラーシステムは、様々な通信サービスを提供するために広く展開されており、符号分割多元接続(CDMA)システム、時分割多元接続(TDMA)システム、周波数分割多元接続(FDMA)システム、直交FDMA(OFDMA)システム、シングルキャリアFDMA(SC-FDMA)システムなどの多元接続システムであり得る。

セルラーシステムは、ブロードキャストサービス、マルチキャストサービス、およびユニキャストサービスをサポートし得る。ブロードキャストサービスは、すべてのユーザによって受信され得るサービス、たとえば、ニュース放送である。マルチキャストサービスは、あるユーザのグループによって受信され得るサービス、たとえば、サブスクリプションビデオサービスである。ユニキャストサービスは、特定のユーザを対象とするサービス、たとえば、ボイス呼である。グループ通信は、ユニキャスト、ブロードキャスト、マルチキャスト、または各々の組合せのいずれかを使用して実装され得る。グループがより大きくなると、概して、マルチキャストサービスを使用するほうがより効率的になる。しかしながら、レイテンシが低くグループ通信を確立する時間が短いことが必要とされるグループ通信サービスでは、従来のマルチキャストチャネルのセットアップ時間がシステム性能にとって有害になり得る。

本開示は、マルチキャストサービスを介したグループ通信に関する。マルチキャストサービスを介したグループ通信のための方法は、ユーザ機器(UE)からサーバに登録要求を送るステップであって、登録要求が、UEが関心を抱く1つまたは複数の通信グループを示し、場合によっては、グループ通信サービス用のサーバに登録するUEの意図を含む、ステップと、あらかじめ確立されたマルチキャストリソースが割り当てられた1つまたは複数の通信グループの組を示すメッセージをサーバから受信するステップと、サーバから1つまたは複数の呼識別子を受信するステップであって、1つまたは複数の呼識別子が、1つまたは複数の通信グループの組における各通信グループのグループ識別子にマッピングされる、ステップと、1つまたは複数の呼識別子の、1つまたは複数の通信グループの組における各通信グループのグループ識別子へのマッピングを記憶するステップと、1つまたは複数の通信グループの組に関する1つまたは複数のグループ呼セッションを維持するステップとを含み、サーバは、複数のグループ呼をあらかじめ確立されたマルチキャストリソースに割り当てる。

マルチキャストサービスを介したグループ通信のための方法は、UEから登録要求を受信するステップであって、登録要求が、UEが関心を抱く1つまたは複数の通信グループを示す、ステップと、UEがあらかじめ確立されたグループ呼に関してプロビジョニングされていると判定するステップと、1つまたは複数の通信グループのグループ識別子を取り出すステップと、1つまたは複数の通信グループの組における各通信グループのグループ識別子に1つまたは複数の呼識別子をマッピングするステップと、1つまたは複数の通信グループの組および1つまたは複数のマッピングされた呼識別子を示すメッセージをUEに送るステップと、複数のグループ呼を1つまたは複数のあらかじめ確立されたマルチキャストリソース上に割り当てるステップとを含み、UEは、1つまたは複数の通信グループの組の1つまたは複数のグループ呼セッションを維持する。

マルチキャストサービスを介したグループ通信のための装置は、ユーザ機器(UE)からサーバに登録要求を送るように構成された論理であって、登録要求が、UEが関心を抱く1つまたは複数の通信グループを示し、場合によっては、グループ通信サービス用のサーバに登録するUEの意図を含む、論理と、あらかじめ確立されたマルチキャストリソースが割り当てられた1つまたは複数の通信グループの組を示すメッセージをサーバから受信するように構成された論理と、サーバから1つまたは複数の呼識別子を受信するように構成された論理であって、1つまたは複数の呼識別子が、1つまたは複数の通信グループの組における各通信グループのグループ識別子にマッピングされる、論理と、1つまたは複数の呼識別子の、1つまたは複数の通信グループの組における各通信グループのグループ識別子へのマッピングを記憶するように構成された論理と、1つまたは複数の通信グループの組に関する1つまたは複数のグループ呼セッションを維持するように構成された論理とを含み、サーバは、複数のグループ呼をあらかじめ確立されたマルチキャストリソースに割り当てる。

マルチキャストサービスを介したグループ通信のための装置は、ユーザ機器(UE)から登録要求を受信するように構成された論理であって、登録要求が、UEが関心を抱く1つまたは複数の通信グループを示す、論理と、UEがあらかじめ確立されたグループ呼に関してプロビジョニングされていると判定するように構成された論理と、1つまたは複数の通信グループのグループ識別子を取り出すように構成された論理と、1つまたは複数の通信グループの組における各通信グループのグループ識別子に1つまたは複数の呼識別子をマッピングするように構成された論理と、1つまたは複数の通信グループの組および1つまたは複数のマッピングされた呼識別子を示すメッセージをUEに送るように構成された論理と、複数のグループ呼を1つまたは複数のあらかじめ確立されたマルチキャストリソース上に割り当てるように構成された論理とを含み、UEは、1つまたは複数の通信グループの組の1つまたは複数のグループ呼セッションを維持する。

マルチキャストサービスを介したグループ通信のための装置は、ユーザ機器(UE)からサーバに登録要求を送るための手段であって、登録要求が、UEが関心を抱く1つまたは複数の通信グループを示し、場合によっては、グループ通信サービス用のサーバに登録するUEの意図を含む、手段と、あらかじめ確立されたマルチキャストリソースが割り当てられた1つまたは複数の通信グループの組を示すメッセージをサーバから受信するための手段と、サーバから1つまたは複数の呼識別子を受信するための手段であって、1つまたは複数の呼識別子が、1つまたは複数の通信グループの組における各通信グループのグループ識別子にマッピングされる、手段と、1つまたは複数の呼識別子の、1つまたは複数の通信グループの組における各通信グループのグループ識別子へのマッピングを記憶するための手段と、1つまたは複数の通信グループの組に関する1つまたは複数のグループ呼セッションを維持するための手段とを含み、サーバは、複数のグループ呼をあらかじめ確立されたマルチキャストリソースに割り当てる。

マルチキャストサービスを介したグループ通信のための装置は、ユーザ機器(UE)から登録要求を受信するための手段であって、登録要求が、UEが関心を抱く1つまたは複数の通信グループを示す、手段と、UEがあらかじめ確立されたグループ呼に関してプロビジョニングされていると判定するための手段と、1つまたは複数の通信グループのグループ識別子を取り出すための手段と、1つまたは複数の通信グループの組における各通信グループのグループ識別子に1つまたは複数の呼識別子をマッピングするための手段と、1つまたは複数の通信グループの組および1つまたは複数のマッピングされた呼識別子を示すメッセージをUEに送るための手段と、複数のグループ呼を1つまたは複数のあらかじめ確立されたマルチキャストリソース上に割り当てるための手段とを含み、UEは、1つまたは複数の通信グループの組の1つまたは複数のグループ呼セッションを維持する。

マルチキャストサービスを介したグループ通信のための非一時的コンピュータ可読媒体は、ユーザ機器(UE)からサーバに登録要求を送るための少なくとも1つの命令であって、登録要求が、UEが関心を抱く1つまたは複数の通信グループを示し、場合によっては、グループ通信サービス用のサーバに登録するUEの意図を含む、命令と、あらかじめ確立されたマルチキャストリソースが割り当てられた1つまたは複数の通信グループの組を示すメッセージをサーバから受信するための少なくとも1つの命令と、サーバから1つまたは複数の呼識別子を受信するための少なくとも1つの命令であって、1つまたは複数の呼識別子が、1つまたは複数の通信グループの組における各通信グループのグループ識別子にマッピングされる、命令と、1つまたは複数の呼識別子の、1つまたは複数の通信グループの組における各通信グループのグループ識別子へのマッピングを記憶するための少なくとも1つの命令と、1つまたは複数の通信グループの組に関する1つまたは複数のグループ呼セッションを維持するための少なくとも1つの命令とを含み、サーバは、複数のグループ呼をあらかじめ確立されたマルチキャストリソースに割り当てる。

マルチキャストサービスを介したグループ通信のための非一時的コンピュータ可読媒体は、ユーザ機器(UE)から登録要求を受信するための少なくとも1つの命令であって、登録要求が、UEが関心を抱く1つまたは複数の通信グループを示す、命令と、UEがあらかじめ確立されたグループ呼に関してプロビジョニングされていると判定するための少なくとも1つの命令と、1つまたは複数の通信グループのグループ識別子を取り出すための少なくとも1つの命令と、1つまたは複数の通信グループの組における各通信グループのグループ識別子に1つまたは複数の呼識別子をマッピングするための少なくとも1つの命令と、1つまたは複数の通信グループの組および1つまたは複数のマッピングされた呼識別子を示すメッセージをUEに送るための少なくとも1つの命令と、複数のグループ呼を1つまたは複数のあらかじめ確立されたマルチキャストリソース上に割り当てるための少なくとも1つの命令とを含み、UEは、1つまたは複数の通信グループの組の1つまたは複数のグループ呼セッションを維持する。

添付の図面は、本開示の実施形態の説明を助けるために提示され、実施形態の限定ではなく、実施形態の例示のためのみに提供される。

本開示の一態様によるワイヤレス通信システムのハイレベルシステムアーキテクチャを示す図である。 本開示の一態様による、無線アクセスネットワーク(RAN)、および1x EV-DOネットワーク用のコアネットワークのパケット交換部分の例示的な構成を示す図である。 本開示の一態様による、RAN、および3G UMTS W-CDMAシステム内の汎用パケット無線サービス(GPRS)コアネットワークのパケット交換部分の例示的な構成を示す図である。 本開示の一態様による、RAN、および3G UMTS W-CDMAシステム内のGPRSコアネットワークのパケット交換部分の別の例示的な構成を示す図である。 本開示の一態様による、RAN、および進化型パケットシステム(EPS:Evolved Packet System)またはロングタームエボリューション(LTE)ネットワークに基づくコアネットワークのパケット交換部分の例示的な構成を示す図である。 本開示の一態様による、EPSまたはLTEネットワークに接続された拡張型高速パケットデータ(HRPD)RAN、およびまたHRPDコアネットワークのパケット交換部分の例示的な構成を示す図である。 例示的な送信構造を示す図である。 マルチセルモードにおける異なるサービスの例示的な送信を示す図である。 シングルセルモードにおける異なるサービスの例示的な送信を示す図である。 ブロードキャスト/マルチキャストサービスをサポートすることができる追加のワイヤレス通信システムを示す図である。 ブロードキャスト/マルチキャストサービスをサポートすることができる追加のワイヤレス通信システムを示す図である。 ブロードキャスト/マルチキャストサービスをサポートすることができるワイヤレス通信システムの一部分のブロック図である。 本開示の態様によるユーザ機器(UE)の例を示す図である。 情報を受信および/または送信するように構成された論理を含む通信デバイスを示す図である。 本開示の様々な態様による例示的なサーバを示す図である。 あらかじめ確立されたセッションシグナリングに基づいてセルラー(PoC)通信を介したPTTを確立するために従来技術において使用される例示的なフローを示す図である。 UEとアプリケーションサーバとの間の相互作用の例示的なフローを示す図である。 本開示の一態様による、複数のPTT呼をあらかじめ確立するための例示的なフローを示す図である。 本開示の一態様による、例示的な呼事前確立フローを示す図である。 本開示の一態様による、例示的な媒体交換フローを示す図である。 本開示の一態様による、マルチキャストサービスを介したグループ通信のための例示的なフローを示す図である。 本開示の一態様による、マルチキャストサービスを介したグループ通信のための例示的なフローを示す図である。

以下の説明および関連する図面において様々な態様が開示される。本開示の範囲から逸脱することなく、代替の態様が考案され得る。さらに、本開示の関連する詳細を不明瞭にしないように、本開示のよく知られている要素は詳細に説明されないか、または省略される。

「例示的」および/または「例」という言葉は、本明細書では「例、事例、または例示として機能すること」を意味するために使用される。本明細書で「例示的」および/または「例」として説明するいかなる態様も、必ずしも他の態様よりも好ましいか、または有利であると解釈されるべきではない。同様に、「本開示の態様」という用語は、本開示のすべての態様が、論じられた特徴、利点または動作モードを含むことを要求しない。

さらに、多くの態様について、たとえばコンピューティングデバイスの要素によって実行されるべき、動作のシーケンスに関して説明する。本明細書で説明する様々な動作は、特定の回路(たとえば、特定用途向け集積回路(ASIC))によって、1つもしくは複数のプロセッサによって実行されるプログラム命令によって、または両方の組合せによって実施され得ることを認識されよう。加えて、本明細書で説明するこれらの動作のシーケンスは、実行時に、関連するプロセッサに本明細書で説明する機能を実施させるコンピュータ命令の対応するセットを記憶した、任意の形式のコンピュータ可読記憶媒体内で完全に具現化されるものと見なされ得る。したがって、本開示の様々な態様は、そのすべてが特許請求される主題の範囲内に入ることが企図されているいくつかの異なる形で具現され得る。さらに、本明細書で説明される態様ごとに、任意のそのような態様の対応する形は、本明細書において、たとえば、説明する動作を実行する「ように構成された論理」として説明される場合がある。

本明細書ではユーザ機器(UE)と呼ばれるクライアントデバイスは、モバイルであってもまたは固定されていてもよく、かつ無線アクセスネットワーク(RAN)と通信してよい。本明細書で使用する「UE」という用語は、「アクセス端末」または「AT」、「ワイヤレスデバイス」、「加入者デバイス」、「加入者端末」、「加入者局」、「ユーザ端末」またはUT、「モバイル端末」、「移動局」、およびそれらの変化形と互換的に参照されてよい。一般に、UEは、RANを介してコアネットワークと通信してよく、コアネットワークを通じてUEはインターネットなどの外部ネットワークに接続されてよい。もちろん、UEには、有線アクセスネットワーク、(たとえば、IEEE802.11などに基づく)WiFiネットワークなど、コアネットワークおよび/またはインターネットに接続する他の機構も考えられる。UEは、限定はしないが、PCカード、コンパクトフラッシュ（登録商標）デバイス、外付けまたは内蔵のモデム、ワイヤレスまたは有線の電話などを含むいくつかのタイプのデバイスのうちの任意のものによって具体化されてよい。UEが信号をRANに送ることができる通信リンクは、アップリンクチャネル(たとえば、逆方向トラフィックチャネル、逆方向制御チャネル、アクセスチャネルなど)と呼ばれる。RANが信号をUEに送ることができる通信リンクは、ダウンリンクチャネルまたは順方向リンクチャネル(たとえば、ページングチャネル、制御チャネル、ブロードキャストチャネル、順方向トラフィックチャネルなど)と呼ばれる。本明細書で使用するトラフィックチャネル(TCH)という用語は、アップリンク/逆方向トラフィックチャネル、またはダウンリンク/順方向トラフィックチャネルのいずれかを指すことができる。

図1は、本開示の一態様によるワイヤレス通信システム100のハイレベルシステムアーキテクチャを示す。ワイヤレス通信システム100はUE1...Nを含む。UE1...Nは、セルラー電話、携帯情報端末(PDA)、ページャ、ラップトップコンピュータ、デスクトップコンピュータなどを含んでよい。たとえば、図1において、UE1...2は発呼側セルラー電話として示され、UE3...5はタッチスクリーンセルラー電話またはスマートフォンとして示され、UE NはデスクトップコンピュータまたはPCとして示されている。

図1を参照すると、UE1...Nは、図1にエアインターフェース104、106、108および/または直接有線接続として示されている物理通信インターフェースまたはレイヤを介してアクセスネットワーク(たとえば、RAN120、アクセスポイント125など)と通信するように構成される。エアインターフェース104および106は、所与のセルラー通信プロトコル(たとえば、符号分割多元接続(CDMA)、エボリューションデータオプティマイズド(EV-DO)、発展型高速パケットデータ(eHRPD:Evolved High Rate Packet Data)、グローバルシステムオブモバイルコミュニケーション(GSM（登録商標）)、GSM（登録商標）進化型高速データレート(EDGE)、ワイドバンドCDMA(W-CDMA)、ロングタームエボリューション(LTE)など)に準拠し得るが、エアインターフェース108は、ワイヤレスIPプロトコル(たとえば、IEEE802.11)に準拠し得る。RAN120は、エアインターフェース104および106などのエアインターフェースを介してUEにサービスする複数のアクセスポイントを含む。RAN120内のアクセスポイントは、アクセスノードまたはAN、アクセスポイントまたはAP、基地局またはBS、ノードB、eノードBなどと呼ばれてよい。これらのアクセスポイントは、地上アクセスポイント(もしくは地上局)、または衛星アクセスポイントであり得る。RAN120は、RAN120によってサービスされるUEとRAN120または異なるRANによってサービスされる他のUEとの間の回線交換(CS)呼を完全にブリッジングすることを含む様々な機能を実行することができ、かつインターネット175などの外部ネットワークとのパケット交換(PS)データの交換を仲介することもできるコアネットワーク140に接続するように構成される。インターネット175は、いくつかのルーティングエージェントおよび処理エージェント(便宜上図1には示されていない)を含む。図1において、UE Nはインターネット175に直接接続する(すなわち、WiFiまたは802.11ベースネットワークのイーサネット（登録商標）接続を介するなど、コアネットワーク140から分離される)ように示されている。それによって、インターネット175は、コアネットワーク140を介してUE NとUE1...Nとの間のパケット交換データ通信をブリッジングするように働いてよい。図1には、RAN120から分離されたアクセスポイント125も示されている。アクセスポイント125は、コアネットワーク140とは無関係に(たとえば、FiOS、ケーブルモデムなどの光通信システムを介して)インターネット175に接続されてよい。エアインターフェース108は、一例ではIEEE802.11などのローカルワイヤレス接続を介してUE4またはUE5にサービスしてよい。UE Nは、一例では(たとえば、有線接続性とワイヤレス接続性の両方を有するWiFiルータ用の)アクセスポイント125自体に相当してよいモデムまたはルータとの直接接続などのインターネット175との有線接続を含むデスクトップコンピュータとして示されている。

図1を参照すると、アプリケーションサーバ170は、インターネット175、コアネットワーク140、またはその両方に接続されるように示されている。アプリケーションサーバ170は、構造的に分離された複数のサーバとして実装されてよく、または代替として単一のサーバに対応し得る。以下により詳しく説明するように、アプリケーションサーバ170は、コアネットワーク140および/またはインターネット175を介してアプリケーションサーバ170に接続することのできるUEについて1つまたは複数の通信サービス(たとえば、ボイスオーバーインターネットプロトコル(VoIP:Voice-over-Internet Protocol)セッション、プッシュツートーク(PTT:Push-to-Talk)セッション、グループ通信セッション、ソーシャルネットワーキングサービスなど)をサポートするように構成される。

ワイヤレス通信システム100をさらに詳細に説明するのを助けるために、図2A〜図2Dに関して、RAN120およびコアネットワーク140のためのプロトコル特有の実装形態の例が以下に提供される。詳細には、RAN120およびコアネットワーク140の構成要素は、パケット交換(PS)通信をサポートすることに関連付けられる構成要素に対応し、これらのネットワーク内にレガシー回線交換(CS)構成要素も存在することができるが、図2A〜図2Dには、いかなるレガシー回線交換(CS)特有の構成要素も明示されていない。

図2Aは、本開示の一態様による、RAN120、およびCDMA2000 1xエボリューションデータオプティマイズド(EV-DO)ネットワークにおけるパケット交換通信用のコアネットワーク140の例示的な構成を示す。図2Aを参照すると、RAN120は、有線バックホールインターフェースを介して基地局コントローラ(BSC)215Aに結合される複数の基地局(BS)200A、205Aおよび210Aを含む。単一のBSCによって制御される一群のBSはまとめてサブネットと呼ばれる。当業者によって理解されるように、RAN120は、複数のBSCおよびサブネットを含むことができ、図2Aには便宜的に単一のBSCが示される。BSC215Aは、A9接続を介してコアネットワーク140内のパケット制御機能(PCF)220Aと通信する。PCF220Aは、パケットデータに関連するBSC215Aのための特定の処理機能を実行する。PCF220Aは、A11接続を介してコアネットワーク140内のパケットデータサービングノード(PDSN)225Aと通信する。PDSN225Aは、ホームエージェント(HA)および/またはフォーリンエージェント(FA)としての役割を果たす、ポイントツーポイント(PPP)セッションを管理することを含む様々な機能を有し、GSM（登録商標）およびUMTSネットワーク内のゲートウェイ汎用パケット無線サービス(GPRS)サポートノード(GGSN)に機能的に類似である(以下にさらに詳細に説明される)。PDSN225Aは、コアネットワーク140をインターネット175のような外部IPネットワークに接続する。

図2Bは、本開示の一態様による、RAN120、および3G UMTS W-CDMAシステム内のGPRSコアネットワークとして構成されたコアネットワーク140のパケット交換部分の例示的な構成を示す。図2Bを参照すると、RAN120は、有線バックホールインターフェースを介して無線ネットワークコントローラ(RNC)215Bに結合される複数のノードB200B、205Bおよび210Bを含む。1x EV-DOネットワークと同様に、単一のRNCによって制御される一群のノードBはまとめてサブネットと呼ばれる。RAN120が複数のRNCおよびサブネットを含むことができ、便宜的に、図2Bには単一のRNSが示されることは、当業者には理解されよう。RNC215Bは、コアネットワーク140内のサービングGRPSサポートノード(SGSN)220Bと、RAN120によってサービングされるUEとの間でシグナリングし、ベアラチャネル(すなわち、データチャネル)を確立し、解除する責任を担う。また、リンクレイヤ暗号化が可能な場合、RNC215Bは、エアインターフェースを介して送信するために、コンテンツをRAN120に転送する前に暗号化する。RNC215Bの機能は、当技術分野でよく知られており、簡潔にするためこれ以上は説明しない。

図2Bにおいて、コアネットワーク140は、先に言及されたSGSN220B(そして、潜在的にはいくつかの他のSGSN)と、GGSN225Bとを含む。一般的に、GPRSは、IPパケットをルーティングするためにGSM（登録商標）において用いられるプロトコルである。GPRSコアネットワーク(たとえば、GGSN225Bおよび1つまたは複数のSGSN220B)は、GPRSシステムの中心部分であり、W-CDMAベースの3Gネットワークのためのサポートも提供する。GPRSコアネットワークは、GSM（登録商標）およびW-CDMAネットワークにおけるIPパケットサービスのモビリティ管理、セッション管理、およびトランスポートを提供する、GSM（登録商標）コアネットワーク(すなわち、コアネットワーク140)の一体化された部分である。

GPRSトンネリングプロトコル(GTP)は、GPRSコアネットワークを特徴づけるIPプロトコルである。GTPは、GGSN225Bにおいて、1つの場所からインターネット175に接続し続けているかのようにしながら、GSM（登録商標）またはW-CDMAネットワークのエンドユーザ(たとえば、UE)が方々に移動できるようにするプロトコルである。これは、UEの現在のSGSN220Bから、それぞれのUEのセッションを処理しているGGSN225BにそれぞれのUEのデータを転送することによって達成される。

GTPの3つの形態、すなわち(i)GTP-U、(ii)GTP-C、および(iii)GTP'(GTP Prime)がGPRSコアネットワークによって使用される。GTP-Uは、各パケットデータプロトコル(PDP)コンテキスト用の分離されたトンネルにおけるユーザデータの転送に使用される。GTP-Cは、制御シグナリング(たとえば、EPSベアラの設定および削除、GSN到達可能性の検証、加入者があるSGSNから別のSGSNに移動した場合のような更新または変更)のために使用される。GTP'は、GSNから課金機能への課金データの転送のために使用される。

図2Bを参照すると、GGSN225Bは、GPRSバックボーンネットワーク(図示せず)とインターネット175との間のインターフェースとしての役割を果たす。GGSN225Bは、SGSN220Bから来るGPRSパケットから、関連するパケットデータプロトコル(PDP)形式(たとえば、IPまたはPPP)を有するパケットデータを抽出し、そのパケットを対応するパケットデータネットワーク上で送る。反対方向において、着信データパケットは、GGSNに接続されたUEによってSGSN220Bに向けられ、SGSN220Bは、RAN120によってサービングされるターゲットUEの無線アクセスベアラ(RAB)を管理および制御する。それによって、GGSN225Bは、ターゲットUEの現在のSGSNアドレスおよびその関連付けられるプロファイルを、(たとえば、EPSベアラ内の)ロケーションレジスタに記憶する。GGSN225Bは、IPアドレス割当てを担い、接続されたUEのデフォルトのルータである。また、GGSN225Bは、認証および課金機能を実行する。

一例では、SGSN220Bは、コアネットワーク140内の多くのSGSNのうちの1つの代表である。各SGSNは、関連する地理的サービスエリア内で、UEとの間でのデータパケットを送達する責任を担う。SGSN220Bのタスクは、パケットルーティングおよび転送、モビリティ管理(たとえば、アタッチ/デタッチおよび位置管理)、論理リンク管理、ならびに認証機能および課金機能を含む。SGSN220Bのロケーションレジスタは、位置情報(たとえば、現在のセル、現在のVLR)、および、SGSN220Bに登録されたすべてのGPRSユーザのユーザプロファイル(たとえば、パケットデータネットワークにおいて使用されるIMSI、PDPアドレス)を、たとえばユーザまたはUEごとに1つまたは複数のEPSベアラ内に記憶する。したがって、SGSN220Bは、(i)GGSN225BからのダウンリンクGTPパケットの逆トンネリング、(ii)GGSN225Bに向かうIPパケットのアップリンクトンネリング、(iii)UEがSGSNサービスエリアの間を移動するときのモビリティ管理の実行、(iv)モバイル加入者の支払い請求の責任を担う。当業者によって理解されるように、(i)〜(iv)の他に、GSM（登録商標）/EDGEネットワークのために構成されたSGSNは、W-CDMAネットワークのために構成されたSGSNと比較して、わずかに異なる機能を有する。

RAN120(またはユニバーサルモバイル通信システム(UMTS)アーキテクチャにおけるユニバーサル地上波無線アクセス(UTRAN)など)は、無線アクセスネットワークアプリケーションパート(RANAP)プロトコルを介して、SGSN220Bと通信する。RANAPは、Iuインターフェース(Iu-ps)を介して、フレームリレーまたはIPなどの伝送プロトコルを用いて動作する。SGSN220Bは、SGSN220Bおよび他のSGSN(図示せず)と内部のGGSN(図示せず)との間のIPベースのインターフェースであり、上記で規定されたGTPプロトコル(たとえば、GTP-U、GTP-C、GTP'など)を使用するGnインターフェースを介してGGSN225Bと通信する。図2Bの実施形態では、SGSN220BとGGSN225Bとの間のGnは、GTP-CとGTP-Uの両方を搬送する。図2Bには示されないが、Gnインターフェースは、ドメイン名システム(DNS)によっても使用される。GGSN225Bは、公衆データネットワーク(PDN)(図示せず)に接続され、さらには、IPプロトコルによるGiインターフェースを介して直接、またはワイヤレスアプリケーションプロトコル(WAP)ゲートウェイを通して、インターネット175に接続される。

図2Cは、本開示の一態様による、RAN120、および3G UMTS W-CDMAシステム内のGPRSコアネットワークとして構成されたコアネットワーク140のパケット交換部分の別の例示的な構成を示す。図2Bと同様に、コアネットワーク140は、SGSN220Bと、GGSN225Bとを含む。しかしながら、図2Cでは、ダイレクトトンネルは、SGSN220Bが、RAN120と、パケット交換(PS)ドメイン内のGGSN225Bとの間にダイレクトユーザプレーントンネル、GTP-Uを確立できるようにする、Iuモードにおけるオプションの機能である。図2CのSGSN220Bのようなダイレクトトンネル対応SGSNは、SGSN220Bがダイレクトユーザプレーン接続を使用できるか否かにかかわらず、GGSN単位およびRNC単位で構成され得る。図2CのSGSN220Bは、制御プレーンシグナリングを処理し、ダイレクトトンネルをいつ確立するべきか決定を行う。PDPコンテキストのために割り当てられたRABが解放される(すなわち、PDPコンテキストが保たれる)とき、ダウンリンクパケットを処理できるようにするために、GGSN225BとSGSN220Bとの間にGTP-Uトンネルが確立される。

図2Dは、本開示の一態様による、RAN120、および進化型パケットシステム(EPS)またはLTEネットワークに基づくコアネットワーク140のパケット交換部分の例示的な構成を示す。図2Dを参照すると、図2B〜図2Cに示すRAN120と異なり、EPS/LTEネットワーク内のRAN120は、図2B〜図2CのRNC215Bなしに、複数の発展型ノードB(EノードBまたはeNB)200D、205D、および210Dとともに構成される。これは、EPS/LTEネットワーク内のEノードBは、コアネットワーク140と通信するためにRAN120内に別個のコントローラ(すなわち、RNC215B)を必要としないからである。言い換えれば、図2B〜図2CのRNC215Bの機能のいくつかは、図2DのRAN120のそれぞれの各eノードBに内蔵される。

図2Dにおいて、コアネットワーク140は複数のモビリティ管理エンティティ(MME)215Dおよび220Dと、ホーム加入者サーバ(HSS)225Dと、サービングゲートウェイ(S-GW)230Dと、パケットデータネットワークゲートウェイ(P-GW)235Dと、ポリシーおよび課金規則機能(PCRF)240Dとを含む。これらの構成要素と、RAN120と、インターネット175との間のネットワークインターフェースが図2Dに示されており、表1(以下)において次のように規定される。

ここで、図2DのRAN120およびコアネットワーク140に示される構成要素のハイレベル記述について説明する。しかしながら、これらの構成要素は各々、様々な3GPP TS規格により当技術分野でよく知られており、本明細書に含まれる記述は、これらの構成要素によって実行されるすべての機能の網羅的な記述となることを意図しない。

図2Dを参照すると、MME215Dおよび220Dは、EPSベアラのための制御プレーンシグナリングを管理するように構成される。MME機能は、非アクセス層(NAS)シグナリング、NASシグナリングセキュリティ、技術間および技術内ハンドオーバのためのモビリティ管理、P-GWおよびS-GW選択、MME変更を伴うハンドオーバのためのMME選択を含む。

図2Dを参照すると、S-GW230Dは、RAN120に向かうインターフェースを終端するゲートウェイである。EPSベースシステムのためのコアネットワーク140に関連付けられるUEごとに、所与の時点において、単一のS-GWが存在する。GTPベースのS5/S8とプロキシモバイルIPv6(PMIP)ベースのS5/S8の両方に関して、S-GW230Dの機能には、モビリティアンカーポイント、パケットルーティングおよび転送、ならびに関連するEPSベアラのQoSクラス識別子(QCI)に基づくディフサーブコードポイント(DSCP)の設定が含まれる。

図2Dを参照すると、P-GW235Dは、パケットデータネットワーク(PDN)、たとえばインターネット175の方へのSGiインターフェースの終端にあるゲートウェイである。UEが複数のPDNにアクセスしている場合、そのUEのために2つ以上のP-GWが存在し得るが、S5/S8接続とGn/Gp接続との混合は、通常、そのUEに関して同時にサポートされない。P-GW機能は、GTPベースの両S5/S8に関して、(ディープパケット検査による)パケットフィルタリング、UEIPアドレス割当て、関連のEPSベアラのQCIに基づくDSCPの設定、オペレータ間の課金のためのアカウンティング、3GPP TS23.203に定義されたアップリンク(UL)およびダウンリンク(DL)ベアラバインディング、3GPP TS23.203に定義されたULベアラバインディング検証を含む。P-GW235Dは、E-UTRAN、GSM（登録商標）/EDGE無線アクセスネットワーク(GERAN)、またはUTRANのいずれかを使用して、GERAN/UTRAN専用UEとE-UTRAN対応UEの両方へのPDN接続を提供する。P-GW235Dは、E-UTRANを使用してS5/S8インターフェースのみを介してE-UTRAN対応UEへのPDN接続を提供する。

図2Dを参照するとわかるように、MCE212Dは、M2インターフェースを介してeノードB205Dに接続され、M3インターフェースを介してMME215Dに接続される。MME215Dは、SG-imbインターフェースを介してBM-SC236Dに接続されたMBMS-GW234Dに接続される。BM-MC236DはPCRF240Dに接続される。これらの構成要素については、図5Aおよび図5Bを参照して以下でより詳細に説明する。

図2Dを参照すると、PCRF240Dは、EPSベースコアネットワーク140のポリシーおよび課金制御要素である。非ローミングシナリオでは、UEのインターネットプロトコル接続性アクセスネットワーク(IP-CAN)セッションに関連付けられるHPLMN内に単一のPCRFが存在する。PCRF240Dは、RxインターフェースおよびGxインターフェースを終端する。ローミングシナリオでは、トラフィックのローカルブレイクアウトに伴って、UEのIP-CANセッションに関連付けられる2つのPCRFが存在する場合がある。ホームPCRF(H-PCRF)は、HPLMN内に存在するPCRFであり、ビジテッドPCRF(V-PCRF)は、訪問先VPLMN内に存在するPCRFである。PCRFは、3GPP TS23.203内にさらに詳細に説明されており、したがって、簡潔のためにさらに説明されない。図2Dでは、アプリケーションサーバ170(たとえば、3GPP用語ではAFと呼ぶことができる)は、インターネット175を介してコアネットワーク140に、または代替的にはRxインターフェースを介して直接PCRF240Dに接続されるように示される。一般的に、アプリケーションサーバ170(またはAF)は、コアネットワークとともにIPベアラリソース(たとえば、UMTS PSドメイン/GPRSドメインリソース/LTE PSデータサービス)を用いてアプリケーションを提供する要素である。アプリケーション機能の一例は、IPマルチメディアサブシステム(IMS)コアネットワークサブシステムのプロキシコールセッション制御機能(P-CSCF)である。AFはRX基準点を用いて、PCRF240Dにセッション情報を提供する。セルラーネットワークを介してIPデータサービスを提供する任意の他のアプリケーションサーバも、RX基準点を介してPCRF240Dに接続することができる。

図2Eは、本開示の一態様による、EPSまたはLTEネットワーク140Aに接続された拡張型高速パケットデータ(HRPD)RANとして構成されたRAN120、およびまたHRPDコアネットワーク140Bのパケット交換部分の一例を示す。コアネットワーク140Aは、図2Dに関して先に説明されたコアネットワークに類似のEPSまたはLTEコアネットワークである。

図2Eにおいて、eHRPD RANは複数のトランシーバ基地局(BTS)200E、205Eおよび210Eを含み、それらのトランシーバ基地局は、拡張BSC(eBSC)および拡張PCF(ePCF)215Eに接続される。eBSC/ePCF215Eは、S101インターフェースを介してEPSコアネットワーク140A内のMME215Dまたは220Dのうちの1つに接続し、EPSコアネットワーク140A内の他のエンティティとインターフェースするためのA10および/またはA11インターフェースを介してHRPDサービングゲートウェイ(HSGW)220Eに(たとえば、S103インターフェースを介してS-GW230Dに、S2aインターフェースを介してP-GW235Dに、Gxaインターフェースを介してPCRF240Dに、STaインターフェースを介して3GPP AAAサーバ(図2Dには明示的に示さず)に、など)接続し得る。HSGW220Eは、HRPDネットワークとEPS/LTEネットワークとの間のインターワーキングを提供するために3GPP2において規定される。理解されるように、eHRPD RANおよびHSGW220Eは、レガシーHRPDネットワークにおいて利用できない発展型パケットコア(EPC)/LTEネットワークへのインターフェース機能によって構成される。

再びeHRPD RANを参照すると、EPS/LTEネットワーク140Aとのインターフェースに加えて、eHRPD RANは、HRPDネットワーク140BなどのレガシーHRPDネットワークとインターフェースすることもできる。諒解されるように、HRPDネットワーク140Bは、図2AのEV-DOネットワークなどのレガシーHRPDネットワークの例示的な実装形態である。たとえば、eBSC/ePCF215Eは、A12インターフェースを介して認証、許可、およびアカウンティング(AAA)サーバ225Eと、A10またはA11インターフェースを介してPDSN/FA230Eとインターフェースすることができる。PDSN/FA230Eは、次に、HA235Aに接続し、それによって、インターネット175にアクセスし得る。図2Eでは、いくつかのインターフェース(たとえば、A13、A16、H1、H2など)が明示的に記載されていないが、完全に示されており、HRPDまたはeHRPDに精通している当業者には理解されよう。

図2B〜図2Eを参照すると、LTEコアネットワーク(たとえば、図2D)およびeHRPD RANおよびHSGW(たとえば、図2E)とのインターフェースを構成するHRPDコアネットワークは、場合によって、ネットワーク開始サービス品質(QoS)をサポートすることができる(たとえば、P-GW、GGSN、SGSNなどによる)。

図3は、ワイヤレス通信システム100においてダウンリンクのために使用され得る例示的な送信構造300を示す。送信タイムラインは、無線フレームの単位に区分され得る。各無線フレームは、所定の持続時間(たとえば、10ミリ秒(ms))を有し得、10個のサブフレームに区分され得る。各サブフレームは2つのスロットを含み得、各スロットは、固定数または構成可能な数のシンボル期間、たとえば、6つまたは7つのシンボル期間を含み得る。

システム帯域幅は、OFDMによって複数(K個)のサブキャリアに区分され得る。利用可能な時間周波数リソースはリソースブロックに分割され得る。各リソースブロックは、1つのスロット中にQ個のサブキャリアを含み得、ただし、Qは12または何らかの他の値に等しくなり得る。利用可能なリソースブロックは、データ、オーバーヘッド情報、パイロットなどを送るために使用され得る。

ワイヤレス通信システム100は、複数のUEのために発展型マルチメディアブロードキャスト/マルチキャストサービス(eMBMS)をサポートし、ならびに個々のUEのためにユニキャストサービスをサポートし得る。eMBMSのためのサービスは、eMBMSサービスまたはフローと呼ばれることがあり、ブロードキャストサービス/フローまたはマルチキャストサービス/フローであり得る。

LTEでは、データおよびオーバーヘッド情報は、無線リンク制御(RLC)レイヤにおいて論理チャネルとして処理される。論理チャネルは、媒体アクセス制御(MAC)層においてトランスポートチャネルにマッピングされる。トランスポートチャネルは、物理(PHY)レイヤにおいて物理チャネルにマッピングされる。Table 2(表2)に、LTEにおいて使用される、(「L」として示された)いくつかの論理チャネルと、(「T」として示された)トランスポートチャネルと、(「P」として示された)物理チャネルとを記載し、各チャネルについて短い説明を与える。

Table 2(表2)に示すように、異なるチャネル上で異なるタイプのオーバーヘッド情報が送られ得る。Table 3(表3)に、いくつかのタイプのオーバーヘッド情報を記載し、各タイプについて短い説明を与える。Table 3(表3)はまた、1つの設計に従って、各タイプのオーバーヘッド情報が送られ得るチャネルを与える。

異なるタイプのオーバーヘッド情報は、他の名前で呼ばれることもある。スケジューリングおよび制御情報は動的であり得るが、システムおよび構成情報は半静的であり得る。

システムは、マルチセルモードとシングルセルモードとを含み得る、eMBMSのための複数の動作モードをサポートし得る。マルチセルモードは以下の特性を有し得る。
・ブロードキャストサービスまたはマルチキャストサービスのためのコンテンツが、複数のセル上で同期的に送信され得る。
・ブロードキャストサービスおよびマルチキャストサービスのための無線リソースが、ノードBの上に論理的に配置され得るMBMS協調エンティティ(MCE:MBMS Coordinating Entity)によって割り振られる。
・ブロードキャストサービスおよびマルチキャストサービスのためのコンテンツがノードBにおいてMCH上にマッピングされる。
・ブロードキャストサービス、マルチキャストサービス、およびユニキャストサービスのためのデータの(たとえば、サブフレームレベルにおける)時分割多重化。

シングルセルモードは以下の特性を有し得る。
・各セルが、他のセルとの同期なしにブロードキャストサービスおよびマルチキャストサービスのためのコンテンツを送信する。
・ブロードキャストサービスおよびマルチキャストサービスのための無線リソースがノードBによって割り振られる。
・ブロードキャストサービスとマルチキャストサービスとのためのコンテンツがDL-SCH上にマッピングされる。
・ブロードキャストサービス、マルチキャストサービス、およびユニキャストサービスのためのデータが、DL-SCHの構造によって可能にされる任意の方法で多重化され得る。

概して、eMBMSサービスは、マルチセルモード、シングルセルモード、および/または他のモードでサポートされ得る。マルチセルモードは、受信性能を改善するために、複数のセルから受信された信号をUEが合成することを可能にし得る、eMBMSマルチキャスト/ブロードキャスト単一周波数ネットワーク(MBSFN)送信のために使用され得る。

図4Aは、マルチセルモードにおけるM個のセル1〜MによるeMBMSサービスとユニキャストサービスとの例示的な送信を示し、ただし、Mは任意の整数値であり得る。各セルについて、水平軸は時間を表し得、垂直軸は周波数を表し得る。以下の説明の大部分について仮定するeMBMSの1つの設計では、各セルの送信タイムラインは、サブフレームの時間単位に区分され得る。eMBMSの他の設計では、各セルの送信タイムラインは、他の持続時間の時間単位に区分され得る。概して、時間単位は、サブフレーム、スロット、シンボル期間、複数のシンボル期間、複数のスロット、複数のサブフレームなどに対応し得る。

図4Aに示す例では、M個のセルは、3つのeMBMSサービス1、2、および3を送信する。すべてのM個のセルは、サブフレーム1および3ではeMBMSサービス1を、サブフレーム4ではeMBMSサービス2を、ならびにサブフレーム7および8ではeMBMSサービス3を送信する。M個のセルは、3つのeMBMSサービスの各々について同じコンテンツを送信する。各セルは、サブフレーム2、5および6においてそれ自体のユニキャストサービスを送信し得る。M個のセルは、それらのユニキャストサービスについて異なるコンテンツを送信し得る。

図4Bは、シングルセルモードにおけるM個のセルによるeMBMSサービスおよびユニキャストサービスの例示的な送信を示す。各セルについて、水平軸は時間を表し得、垂直軸は周波数を表し得る。図4Bに示す例では、M個のセルは、3つのeMBMSサービス1、2、および3を送信する。セル1は、1つの時間周波数ブロック410においてeMBMSサービス1を送信し、時間周波数ブロック412および414においてeMBMSサービス2を送信し、1つの時間周波数ブロック416においてeMBMSサービス3を送信する。同様に、他のセルは、図4Bに示すようにサービス1、2および3を送信する。

概して、eMBMSサービスは任意の数の時間周波数ブロックで送られ得る。サブフレームの数は、送るべきデータの量、および場合によっては他の因子に依存し得る。M個のセルは、図4Bに示すように、時間および周波数において整合されないことがある時間周波数ブロックにおいて3つのeMBMSサービス1、2および3を送信し得る。さらに、M個のセルは、3つのeMBMSサービスについて同じまたは異なるコンテンツを送信し得る。各セルは、3つのeMBMSサービスのために使用されない残りの時間周波数リソースにおいてそれ自体のユニキャストサービスを送信し得る。M個のセルは、それらのユニキャストサービスについて異なるコンテンツを送信し得る。

図4Aおよび図4Bは、マルチセルモードおよびシングルセルモードにおいてeMBMSサービスを送信する例示的な設計を示している。eMBMSサービスはまた、マルチセルモードおよびシングルセルモードにおいて他の方法で、たとえば、時分割多重化(TDM)を使用して送信され得る。

上記に示したように、eMBMSサービスは、グループにマルチキャストデータを配信するために使用され得、グループ通信システム(たとえば、プッシュツートーク(PTT)呼)では有用であり得る。eMBMSにおける従来のアプリケーションは、別個のサービス告知/発見機構を有する。さらに、事前確立されたeMBMSフロー上の通信は、エアインターフェースにおいてさえ常時オンである。節電最適化は、呼/通信が進行中でないとき、UEをスリープにするように適用されなければならない。これは、典型的には、ユニキャストまたはマルチキャストユーザプレーンデータに関する帯域外のサービス告知を使用することによって実現される。代替的に、アプリケーションレイヤページングチャネルのような機構を使用することができる。アプリケーションレイヤページング機構は、アクティブのままでなければならないので、ページング機構がない場合にアイドル状態である可能性があるマルチキャストサブフレームの帯域幅を消費する。さらに、マルチキャストサブフレームは、アプリケーションレイヤページングを使用している間はアクティブであるので、サブフレーム内のリソースブロックの残りは、ユニキャストトラフィックに使用することができない。したがって、合計5Mhzの帯域幅は、たとえば、アプリケーションレイヤページングが他のいかなるデータもなしにスケジューリングされるとき、サブフレームのために消費される。

図5Aは、本明細書で互換的に使用される、発展型マルチメディアブロードキャスト/マルチキャストサービス(eMBMS)またはMBMSサービスを実装することができるワイヤレスネットワークの別の説明図である。MBMSサービスエリア500は、複数のMBSFNエリア(たとえば、MBSFNエリア1、501およびMBSFNエリア2、502)を含み得る。各MBSFNエリアは、コアネットワーク530に結合される1つまたは複数のeノードB510によってサポートされ得る。コアネットワーク530は、コンテンツプロバイダ570(アプリケーションサーバなどを含み得る)からのコンテンツを制御し、MBMSサービスエリア500に配信するのを容易にするために、様々な要素(たとえば、MME532、eMBMSゲートウェイ534、およびブロードキャストマルチキャストサービスセンタ(BM-SC)536)を含み得る。コアネットワーク530は、ネットワーク内のeノードBのリスト、他のダウンストリームE-MBMS-GW534およびモビリティ管理エンティティ(MME)/MCE532のリスト、ならびにマルチキャストIPアドレスのセッション識別子へのマッピングを必要とし得る。ネットワーク内のUE520には、セッション識別子およびUE520に送られるコンテンツのマルチキャストIPアドレスがプロビジョニングされ得る。通常、MMEはLTEアクセスネットワークにとって主要な制御ノードである。MMEは、アイドルモードUEの追跡および再送信を含むページングプロシージャを担う。MMEは、ベアラのアクティブ化/非アクティブ化プロセスに関与し、また、最初の接続時点およびコアネットワーク530ノード移転を伴うLTE内ハンドオーバの時点でUEのためにSGWを選択する役割を果たし、かつユーザを認証する役割も果たす。MME532は、サービスプロバイダのパブリックランドモバイルネットワーク(PLMN:Public Land Mobile Network)にキャンプオンするにあたりUEの認証をチェックすることもでき、UEのローミング制限を実施する。MME532は、非アクセス層(NAS)シグナリングの暗号化/完全性保護のためのネットワーク中の終端点であり、セキュリティ鍵管理を扱う。MMEはまた、MMEで終端するS3インターフェースによるLTEアクセスネットワークと2G/3Gアクセスネットワークとの間の移動の制御プレーン機能を提供する。

図5Bは、本明細書で開示する、マルチメディアブロードキャスト/マルチキャストサービス(MBMS)を実装することができるワイヤレスネットワークの別の説明図である。例示したネットワークでは、アプリケーションサーバ550(たとえば、PTTサーバ)は、コンテンツサーバとして働くことができる。アプリケーションサーバ550は、ネットワークコアにユニキャストパケット552内のメディアを通信することができ、コンテンツは、ユニキャスト構成で維持され、ユニキャストパケットとして所与のUE(たとえば、発信者/話者520)に送信され得るか、またはBM-SCを介してマルチキャストパケット554に変換され、次いでターゲットUE522に搬送され得る。たとえば、PTT呼はUE520によって、ユニキャストチャネル上でユニキャストパケット552を介してアプリケーションサーバ550と通信することによって開始され得る。呼発信者/呼話者については、アプリケーションシグナリングとメディアの両方が、アップリンクすなわち逆方向リンク上でユニキャストチャネルを介して通信されることに留意されたい。次いで、アプリケーションサーバ550は、呼告知/呼セットアップ要求を生成し、これらをターゲットUE522に通信することができる。この特定の例に示すように、通信は、マルチキャストフロー上でマルチキャストパケット554を介してターゲットUE522に通信され得る。さらに、この例では、アプリケーションシグナリングとメディアの両方が、ダウンリンクすなわち順方向リンク内でマルチキャストフローを介して通信され得ることが諒解されよう。従来のシステムとは異なり、アプリケーションシグナリングとメディアの両方をマルチキャストフロー内に有することにより、アプリケーションシグナリング用の別個のユニキャストチャネルを有する必要がなくなる。しかしながら、例示したシステムのマルチキャストフローを介したアプリケーションシグナリングを可能にするために、発展型パケットシステム(EPS)ベアラは、BM-SC536、EMBS GW534、eNB510、およびターゲットUE522間で確立される(かつ持続的にオンになる)。

本明細書で開示する様々な実施形態に従って、eMBMSに関連するダウンリンクチャネルのいくつかについてさらに論じるが、これらのチャネルは、
MCCH:マルチキャスト制御チャネル、
MTCH:マルチキャストトラフィックチャネル、
MCH:マルチキャストチャネル、および
PMCH:物理マルチキャストチャネルを含む。

eMBMSおよびユニキャストフローの多重化は、時間ドメインのみにおいて実現されることが諒解されよう。MCHは、物理層上の固有のサブフレームにおいてMBSFNを介して送信される。MCHは、ダウンリンクのみのチャネルである。単一のトランスポートブロックは、サブフレーム単位で使用される。異なるサービス(MTCH)は、図6に関して示されるように、このトランスポートブロックで多重化され得る。

低レイテンシを実現し、制御シグナリングを低減するために、各サービスエリアに関して、1つのeMBMSフロー(562、564)をアクティブ化することができる。データレートに応じて、単一のスロット上で複数のマルチキャストフローを多重化することができる。PTT UE(ターゲット)は、スケジューリングされたサブフレームを無視し、スケジューリングされたサブフレーム間で「スリープ」し、UEに関してユニキャストデータがスケジューリングされていないときに電力消費を低減することができる。MBSFNサブフレームは、同じMBSFNサービスエリアにおけるグループによって共有され得る。MACレイヤシグナリングは、ターゲットUEのアプリケーションレイヤ(たとえば、PTTアプリケーション)を「起動する」ために活用され得る。

実施形態は、各々がLTEブロードキャストフロー上の別個のeMBMSフローであり、定義された各ブロードキャスト領域502、501(たとえば、ネットワーク内のセクタのサブセット)に関する、それ自体のアプリケーションレベルブロードキャストストリーム、およびそれ自体のマルチキャストIPアドレスを有する、2つのブロードキャストストリームを使用することができる。別個の領域として示されているが、ブロードキャストエリア502、501は重複し得ることが諒解されよう。

LTEでは、マルチキャストに関する制御およびデータトラフィックは、それぞれ、MCCHおよびMTCHを介して配信される。UEに関する媒体アクセス制御プロトコルデータユニット(MAC PDU)は、MTCHのマッピングおよびサブフレーム内の特定のMTCHの位置を示す。MCHスケジューリング情報(MSI)MAC制御要素は、各MTCHの位置およびMCH上の未使用のサブフレームを示すためにMCHスケジューリング周期内にMCHに割り振られる第1のサブフレームに含まれる。MTCH論理チャネルによって搬送されるeMBMSユーザデータに関して、MCHスケジューリング情報(MSI)は、下位の層においてMTCHを復号することに関する情報(たとえば、MAC層情報)を周期的に与える。MSIスケジューリングを構成することができ、本実施形態によれば、MSIスケジューリングはMTCHサブフレーム間隔の前にスケジューリングされる。

図6は、様々な実施形態に関して本明細書で説明する、eノードBのうちの1つおよびUEのうちの1つであり得る、eノードB510およびUE520の設計のブロック図を示す。この設計では、ノードB510はT個のアンテナ634a〜634tを装備し、UE520はR個のアンテナ652a〜652rを装備するが、概して、Tは1以上であり、Rは1以上である。

ノードB510において、送信プロセッサ620は、データソース612から(たとえば、アプリケーションサーバ150から直接または間接的に)、ユニキャストサービスのためのデータと、ブロードキャストおよび/またはマルチキャストサービスのためのデータとを受信し得る。送信プロセッサ620は、各サービスのためのデータを処理してデータシンボルを取得し得る。送信プロセッサ620はまた、コントローラ/プロセッサ640および/またはスケジューラ644から、スケジューリング情報、構成情報、制御情報、システム情報および/または他のオーバーヘッド情報を受信し得る。送信プロセッサ620は、受信されたオーバーヘッド情報を処理し、オーバーヘッドシンボルを与え得る。送信(TX)多入力多出力(MIMO)プロセッサ630は、データおよびオーバーヘッドシンボルをパイロットシンボルと多重化し、多重化シンボルを処理(たとえば、プリコード)し、T個の変調器(MOD)632a〜632tにT個の出力シンボルストリームを与え得る。各変調器632は、それぞれの出力シンボルストリームを(たとえば、OFDM用に)処理して、出力サンプルストリームを取得し得る。各変調器632はさらに、ダウンリンク信号を取得するために、出力サンプルストリームを処理(たとえば、アナログへの変換、増幅、フィルタ処理、およびアップコンバート)をすることができる。変調器632aから632tからのT個のダウンリンク信号は、それぞれT個のアンテナ634aから634tを介して送信され得る。

UE520において、アンテナ652a〜652rは、ノードB510からダウンリンク信号を受信し、受信された信号をそれぞれ復調器(DEMOD)654a〜654rに与え得る。各復調器654は、それぞれの受信された信号を調整(たとえば、フィルタ処理、増幅、ダウンコンバート、およびデジタル化)して、受信されたサンプルを取得し得、受信されたサンプルを(たとえば、OFDM用に)さらに処理して、受信されたシンボルを取得し得る。MIMO検出器660は、すべてのR個の復調器654a〜654rから受信されたシンボルを受信および処理し、検出されたシンボルを与え得る。受信プロセッサ670は、検出されたシンボルを処理し、UE520および/または所望のサービスについての復号されたデータをデータシンク672に与え、復号されたオーバーヘッド情報をコントローラ/プロセッサ690に与え得る。概して、MIMO検出器660および受信プロセッサ670による処理は、ノードB510におけるTX MIMOプロセッサ630および送信プロセッサ620による処理と相補関係にある。

アップリンク上で、UE520において、データソース678からのデータと、コントローラ/プロセッサ690からのオーバーヘッド情報とは、送信プロセッサ680によって処理され、(適用可能な場合は)TX MIMOプロセッサ682によってさらに処理され、変調器654a〜654rによって調整され、アンテナ652a〜652rを介して送信され得る。ノードB510において、UE520からのアップリンク信号は、アンテナ634によって受信され、復調器632によって調整され、MIMO検出器636によって検出され、受信プロセッサ638によって処理されて、UE520によって送信されたデータおよびオーバーヘッド情報が取得され得る。

コントローラ/プロセッサ640および690は、それぞれノードB510およびUE520における動作を指示し得る。スケジューラ644は、ダウンリンクおよび/またはアップリンク送信についてUEをスケジューリングし、ブロードキャストサービスとマルチキャストサービスとの送信をスケジューリングし、スケジューリングされたUEおよびサービスへの無線リソースの割当てを行い得る。コントローラ/プロセッサ640および/またはスケジューラ644は、ブロードキャストサービスおよびマルチキャストサービスのためのスケジューリング情報および/または他のオーバーヘッド情報を生成し得る。

コントローラ/プロセッサ690は、本明細書で説明する技法のためのプロセスを実装し得る。メモリ642および692は、それぞれノードB510およびUE520のためのデータおよびプログラムコードを記憶し得る。したがって、eMBMS環境におけるグループ通信は、本明細書に開示された様々な実施形態に従って達成され得るが、依然として既存の規格に準拠したままである。

図7は、本開示の態様によるUEの例を示す。図7を参照すると、UE700Aは発呼側電話として示され、UE700Bはタッチスクリーンデバイス(たとえば、スマートフォン、タブレットコンピュータなど)として示されている。図7に示すように、UE700Aの外部ケーシングは、当技術分野で知られているように、数ある構成要素の中でも、アンテナ705A、ディスプレイ710A、少なくとも1つのボタン715A(たとえば、PTTボタン、電源ボタン、音量調節ボタンなど)、キーパッド720Aによって構成される。また、UE700Bの外部ケーシングは、当技術分野で知られているように、数ある構成要素の中でも、タッチスクリーンディスプレイ705B、周辺ボタン710B、715B、720B、および725B(たとえば、電力調節ボタン、音量または振動調節ボタン、飛行機モードトグルボタンなど)、少なくとも1つのフロントパネルボタン730B(たとえば、Homeボタンなど)によって構成され得る。UE700Bの一部として明示的に示されてはいないが、UE700Bは、限定はしないが、WiFiアンテナ、セルラーアンテナ、衛星位置システム(SPS)アンテナ(全地球測位システム(GPS)アンテナ)などを含む1本もしくは複数の外部アンテナおよび/またはUE700Bの外部ケーシングに内蔵された1本または複数の集積アンテナを含んでよい。

UE700AおよびUE700BなどのUEの内部構成要素は異なるハードウェア構成によって具体化され得るが、内部ハードウェア構成要素のための基本的なハイレベルUE構成は図7にプラットフォーム702として示されている。プラットフォーム702は、最終的にコアネットワーク140、インターネット175、ならびに/または他のリモートサーバおよびネットワーク(たとえば、アプリケーションサーバ170、ウェブURLなど)から得ることのできるRAN120から送信されたソフトウェアアプリケーション、データ、および/またはコマンドを受信し実行してよい。プラットフォーム702は、ローカルに記憶されたアプリケーションをRAN対話なしで独立して実行してもよい。プラットフォーム702は、特定用途向け集積回路(「ASIC」)708または他のプロセッサ、マイクロプロセッサ、論理回路、または他のデータ処理デバイスに動作可能に結合された送受信機706を含み得る。ASIC708または他のプロセッサは、ワイヤレスデバイスのメモリ712中の任意の常駐プログラムとインターフェースを構成するアプリケーションプログラミングインターフェース(「API」)710レイヤを実行する。メモリ712は、読取り専用メモリ(ROM)もしくはランダムアクセスメモリ(RAM)、電気的消去可能プログラマブルROM(EEPROM)、フラッシュカード、またはコンピュータプラットフォームに共通する任意のメモリから構成されてよい。プラットフォーム702は、メモリ712中でアクティブに使用されないアプリケーション、ならびに他のデータを記憶することができるローカルデータベース714も含むことができる。ローカルデータベース714は、一般的にフラッシュメモリセルであるが、磁気媒体、EEPROM、光学媒体、テープ、ソフトディスクまたはハードディスクなど、当技術分野で知られている任意の二次記憶デバイスとすることができる。

したがって、本開示の一態様は、本明細書で説明する機能を実行する能力を含むUE(たとえば、UE700A、UE700Bなど)を含むことができる。当業者によって理解されるように、様々な論理要素は、本明細書で開示する機能を達成するために、個別の要素、プロセッサ上で実行されるソフトウェアモジュール、またはソフトウェアとハードウェアとの任意の組合せで具現され得る。たとえば、ASIC708、メモリ712、API210、およびローカルデータベース714をすべて協調的に用いて、本明細書で開示する様々な機能をロード、記憶および実行することができ、したがって、これらの機能を実行するための論理は様々な要素に分散させることができる。代替的には、機能は1つの個別構成要素に組み込むことができる。したがって、図7のUE700AおよびUE700Bの特徴は単に例示であると見されるべきであり、本開示は図示される特徴または構成に限定されない。

UE700Aおよび/またはUE700BとRAN120との間のワイヤレス通信は、CDMA、W-CDMA、時分割多元接続(TDMA)、周波数分割多元接続(FDMA)、直交周波数分割多元(OFDM)、GSM（登録商標）、またはワイヤレス通信ネットワークもしくはデータ通信ネットワークで使用することができる他のプロトコルのような、様々な技術に基づくことができる。先に論じられ、当該技術分野において知られているように、音声送信および/またはデータは、様々なネットワークおよび構成を使用してRANからUEに送信することができる。したがって、本明細書で提供する例示は、本開示の態様を限定することを意図するものではなく、本開示の様々な態様の説明を助けるためのものにすぎない。

図8は、機能を実行するように構成される論理を含む通信デバイス800を示す。通信デバイス800は、限定はしないが、UE700Aもしくは700B、RAN120の任意の構成要素(たとえば、BS200A〜210A、BSC215A、ノードB200B〜210B、RNC215B、eノードB200D〜210Dなど)、コアネットワーク140の任意の構成要素(PCF220A、PDSN225A、SGSN220B、GGSN225B、MME215Dまたは220D、HSS225D、S-GW230D、P-GW235D、PCRF240D)、コアネットワーク140および/またはインターネット175に結合される任意の構成要素(たとえば、アプリケーションサーバ170)などを含む、先に言及された通信デバイスのいずれかに対応することができる。したがって、通信デバイス800は、図1のワイヤレス通信システム100を介して1つもしくは複数の他のエンティティと通信する(または通信を容易にする)ように構成された任意の電子デバイスに対応し得る。

図8を参照すると、通信デバイス800は、情報を受信および/または送信するように構成された論理805を含む。一例では、通信デバイス800がワイヤレス通信デバイス(たとえば、UE700Aまたは700B、BS200A〜210Aのうちの1つ、ノードB200B〜210Bのうちの1つ、eノードB200D〜210Dのうちの1つなど)に対応する場合、情報を受信および/または送信するように構成された論理805は、ワイヤレストランシーバおよび関連のハードウェア(たとえば、RFアンテナ、モデム、変調器および/または復調器など)などのワイヤレス通信インターフェース(たとえば、Bluetooth（登録商標）、WiFi、2G、CDMA、W-CDMA、3G、4G、LTEなど)を含み得る。別の例では、情報を受信および/または送信するように構成された論理805は、有線通信インターフェース(たとえば、インターネット175にアクセスする手段となり得るシリアル接続、USBまたはFirewire接続、Ethernet（登録商標）接続など)に対応することができる。したがって、通信デバイス800が、何らかのタイプのネットワークベースのサーバ(たとえば、PDSN、SGSN、GGSN、S-GW、P-GW、MME、HSS、PCRF、アプリケーションサーバ170など)に対応する場合、情報を受信および/または送信するように構成された論理805は、一例では、イーサネット（登録商標）プロトコルを介してネットワークベースのサーバを他の通信エンティティに接続するイーサネット（登録商標）カードに対応し得る。一例として、情報を受信および/または送信するように構成された論理805は、UEからサーバに登録要求を送るように構成された論理であって、登録要求が、UEが関心を抱く1つまたは複数の通信グループを示し、場合によっては、グループ通信サービス用のサーバに登録するUEの意図を含む論理と、あらかじめ確立されたマルチキャストリソースが割り当てられた1つまたは複数の通信グループの組を示すメッセージをサーバから受信するように構成された論理と、サーバから1つまたは複数の呼識別子を受信するように構成された論理であって、1つまたは複数の呼識別子が、1つまたは複数の通信グループの組における各通信グループのグループ識別子にマッピングされる論理とを含んでよい。別の例として、情報を受信および/または送信するように構成された論理805は、UEから登録要求を受信するように構成された論理であって、登録要求が、UEが関心を抱く1つまたは複数の通信グループを示す論理と、1つまたは複数の通信グループの組および1つまたは複数のマッピングされた呼識別子を示すメッセージをUEに送るように構成された論理と、複数のグループ呼を1つまたは複数のあらかじめ確立されたマルチキャストリソース上に割り当てるように構成された論理とを含んでよい。さらなる例では、情報を受信および/または送信するように構成された論理805は、通信デバイス800がそのローカル環境を監視する手段となり得る感知または測定ハードウェア(たとえば、加速度計、温度センサ、光センサ、ローカルRF信号を監視するためのアンテナなど)を含むことができる。情報を受信および/または送信するように構成された論理805は、実行されるときに、情報を受信および/または送信するように構成された論理805の関連ハードウェアがその受信機能および/または送信機能を実行できるようにするソフトウェアも含むことができる。しかしながら、情報を受信および/または送信するように構成された論理805は、ソフトウェア単体に対応するのではなく、情報を受信および/または送信するように構成された論理805は、その機能を達成するためのハードウェアに少なくとも部分的に依拠する。

図8を参照すると、通信デバイス800は、情報を処理するように構成された論理810をさらに含む。一例では、情報を処理するように構成された論理810は、少なくともプロセッサを含むことができる。情報を処理するように構成された論理810によって実行され得るタイプの処理の例示的な実装態様は、限定はしないが、決定を行うこと、接続を確立すること、異なる情報オプション間で選択を行うこと、データに関係する評価を行うこと、測定演算を実行するために通信デバイス800に結合されたセンサとやりとりすること、情報をあるフォーマットから別のフォーマットに(たとえば、.wmvから.aviへなど、異なるプロトコル間で)変換することなどを含む。たとえば、情報を処理するように構成された論理810は、1つまたは複数の呼識別子の、1つまたは複数の通信グループの組における各通信グループのグループ識別子へのマッピングを記憶するように構成された論理と、1つまたは複数の通信グループの組に関する1つまたは複数のグループ呼セッションを維持するように構成された論理とを含んでよい。別の例として、情報を処理するように構成された論理810は、UEがあらかじめ確立されたグループ呼に関してプロビジョニングされていると判定するように構成された論理と、1つまたは複数の通信グループのグループ識別子を取り出すように構成された論理と、1つまたは複数の呼識別子を、1つまたは複数の通信グループの組における各通信グループのグループ識別子にマッピングするように構成された論理と、複数のグループ呼を1つまたは複数のあらかじめ確立されたマルチキャストリソース上に割り当てるように構成された論理とを含んでよい。情報を処理するように構成された論理810中に含まれるプロセッサは、汎用プロセッサ、デジタル信号プロセッサ(DSP)、ASIC、フィールドプログラマブルゲートアレイ(FPGA)もしくは他のプログラマブル論理デバイス、個別ゲートもしくはトランジスタ論理、個別ハードウェア構成要素、または本明細書で説明する機能を実行するように設計されたそれらの任意の組合せに対応し得る。汎用プロセッサはマイクロプロセッサであってもよいが、代替ではプロセッサは、任意の従来のプロセッサ、コントローラ、マイクロコントローラまたは状態マシンであってもよい。また、プロセッサは、計算デバイスの組合せ、たとえばDSPと、マイクロプロセッサ、複数のマイクロプロセッサ、DSPコアと関連した1つまたは複数のマイクロプロセッサとの組合せ、あるいは任意の他のそのような構成として実施することも可能である。情報を処理するように構成された論理810は、実行されるとき、情報を処理するように構成された論理810の関連ハードウェアがその処理機能を実行できるようにするソフトウェアも含むことができる。しかしながら、情報を処理するように構成された論理810は、ソフトウェアだけに対応するのではなく、情報を処理するように構成された論理810は、その機能を達成するためにハードウェアに少なくとも部分的に依拠する。

図8を参照すると、通信デバイス800は、情報を記憶するように構成された論理815をさらに含む。一例では、情報を記憶するように構成された論理815は、少なくとも非一時的メモリおよび関連ハードウェア(たとえば、メモリコントローラなど)を含むことができる。たとえば、情報を記憶するように構成された論理815内に含まれる非一時的メモリは、RAM、フラッシュメモリ、ROM、消去可能プログラマブルROM(EPROM)、EEPROM、レジスタ、ハードディスク、リムーバブルディスク、CD-ROM、または当技術分野で知られている任意の他の形の記憶媒体に対応し得る。情報を記憶するように構成された論理815はまた、実行されるとき、情報を記憶するように構成された論理815の関連ハードウェアがその記憶機能を実行できるようにするソフトウェアを含み得る。しかしながら、情報を記憶するように構成された論理815は、ソフトウェアだけに対応するのではなく、情報を記憶するように構成された論理815は、その機能を達成するためにハードウェアに少なくとも部分的に依拠する。一例として、情報を処理するように構成された論理815は、1つまたは複数の呼識別子の、1つまたは複数の通信グループの組における各通信グループのグループ識別子へのマッピングを記憶するように構成された論理と、1つまたは複数の通信グループの組に関する1つまたは複数のグループ呼セッションを維持するように構成された論理とを含んでよい。

図8を参照すると、通信デバイス800は、場合によっては、情報を提示するように構成された論理820をさらに含む。一例では、情報を提示するように構成された論理820は、少なくとも出力デバイスおよび関連ハードウェアを含むことができる。たとえば、出力デバイスは、ビデオ出力デバイス(たとえば、ディスプレイスクリーン、USB、HDMI（登録商標）のようなビデオ情報を搬送することができるポートなど)、オーディオ出力デバイス(たとえば、スピーカ、マイクロフォンジャック、USB、HDMI（登録商標）のようなオーディオ情報を搬送することができるポートなど)、振動デバイス、および/または、情報がそれによって出力のためにフォーマットされ得る、または通信デバイス800のユーザもしくは操作者によって実際に出力され得る任意の他のデバイスを含むことができる。たとえば、通信デバイス800が図7に示されるようなUE700AまたはUE700Bに対応する場合、情報を提示するように構成された論理820は、UE700Aのディスプレイ710AまたはUE700Bのタッチスクリーンディスプレイ705Bを含むことができる。さらなる例では、情報を提示するように構成された論理820は、(たとえば、ネットワークスイッチまたはルータ、リモートサーバなど)ローカルユーザを有さないネットワーク通信デバイスのようないくつかの通信デバイスでは省略されることがある。情報を提示するように構成された論理820は、実行されるとき、情報を提示するように構成された論理820の関連ハードウェアがその提示機能を実行できるようにするソフトウェアも含むことができる。しかしながら、情報を提示するように構成された論理820は、ソフトウェア単体に対応するのではなく、情報を提示するように構成された論理820は、その機能を達成するためのハードウェアに少なくとも部分的に依拠する。

図8を参照すると、通信デバイス800は、場合によっては、ローカルユーザ入力を受信するように構成された論理825をさらに含む。一例では、ローカルユーザ入力を受信するように構成された論理825は、少なくともユーザ入力デバイスおよび関連ハードウェアを含み得る。たとえば、ユーザ入力デバイスは、ボタン、タッチスクリーンディスプレイ、キーボード、カメラ、オーディオ入力デバイス(たとえば、マイクロフォン、もしくはマイクロフォンジャックなど、オーディオ情報を搬送することができるポートなど)、および/または情報がそれによって通信デバイス800のユーザもしくはオペレータから受信され得る任意の他のデバイスを含み得る。たとえば、通信デバイス800が図7に示すようなUE700AまたはUE700Bに対応する場合、ローカルユーザ入力を受信するように構成された論理825は、キーパッド720A、ボタン715Aまたは710B〜725Bのうちのいずれか、タッチスクリーンディスプレイ705Bなどを含むことができる。さらなる例では、ローカルユーザ入力を受信するように構成された論理825は、(たとえば、ネットワークスイッチまたはルータ、リモートサーバなど)ローカルユーザを有さないネットワーク通信デバイスのようないくつかの通信デバイスでは省略されることがある。ローカルユーザ入力を受信するように構成された論理825は、実行されるとき、ローカルユーザ入力を受信するように構成された論理825の関連ハードウェアがその入力受信機能を実行できるようにするソフトウェアも含むことができる。しかしながら、ローカルユーザ入力を受信するように構成された論理825は、ソフトウェアだけに対応するのではなく、ローカルユーザ入力を受信するように構成された論理825は、その機能を達成するためにハードウェアに少なくとも部分的に依拠する。

図8を参照すると、805〜825の構成された論理は、図8では別個のまたは相異なるブロックとして示されているが、それぞれの構成された論理がその機能を実行するためのハードウェアおよび/またはソフトウェアは、部分的に重複できることは理解されよう。たとえば、805〜825の構成された論理の機能を容易にするために使用される任意のソフトウェアを、情報を記憶するように構成された論理815に関連する非一時的メモリに記憶することができ、それにより、805〜825の構成された論理は各々、その機能(すなわち、この場合、ソフトウェア実行)を、情報を記憶するように構成された論理815によって記憶されたソフトウェアの動作に部分的に基づいて実行する。同様に、構成された論理のうちの1つに直接関連付けられたハードウェアは、時々、他の構成された論理によって借用または使用され得る。たとえば、情報を処理するように構成された論理810のプロセッサは、データを、情報を受信および/または送信するように構成された論理805によって送信される前に、適切な形式にフォーマットすることができ、それにより、情報を受信および/または送信するように構成された論理805は、その機能(すなわち、この場合、データの送信)を、情報を処理するように構成された論理810に関連付けられたハードウェア(すなわち、プロセッサ)の動作に部分的に基づいて実行する。

概して、別段に明示的に記載されていない限り、本開示全体にわたって使用される「ように構成された論理」という句は、ハードウェアにより少なくとも部分的に実装される態様を呼び出すものとし、ハードウェアから独立したソフトウェアだけの実装形態に対応付けるものではない。様々なブロックにおける構成された論理または「ように構成された論理」は、特定の論理ゲートまたは論理要素に限定されるのではなく、概して、本明細書で説明する機能性を、(ハードウェアまたはハードウェアとソフトウェアの組合せのいずれかを介して)実行するための能力を指すことが諒解されよう。したがって、様々なブロックに示す構成された論理または「ように構成された論理」は、「論理」という言葉を共有するにもかかわらず、必ずしも論理ゲートまたは論理要素として実装されるわけではない。様々なブロックの論理間の他のやりとりまたは協働が、以下でより詳細に説明する態様の検討から、当業者には明らかになるであろう。

様々な実施形態は、図9に示すサーバ900などの、様々な市販のサーバデバイスのいずれにおいても実装され得る。一例では、サーバ900は、上記で説明したアプリケーションサーバ170の1つの例示的な構成に対応し得る。図9では、サーバ900は、揮発性メモリ902と、ディスクドライブ903などの大容量の不揮発性メモリとに結合されたプロセッサ901を含む。サーバ900は、プロセッサ901に結合された、フロッピー（登録商標）ディスクドライブ、コンパクトディスク(CD)ドライブまたはDVDディスクドライブ906を含むことも可能である。サーバ900は、他のブロードキャストシステムコンピュータおよびサーバに、またはインターネットに結合されたローカルエリアネットワークなどのネットワーク907とのデータ接続を確立するための、プロセッサ901に結合されたネットワークアクセスポート904を含むことも可能である。図8の文脈において、図9のサーバ900は、通信デバイス800の1つの例示的な実装形態を示すが、情報を送信および/または受信するように構成された論理805は、ネットワーク907と通信するためにサーバ900によって使用されるネットワークアクセスポイント904に対応し、情報を処理するように構成された論理810は、プロセッサ901に対応し、情報を記憶するように構成された論理815は、揮発性メモリ902、ディスク(disk)ドライブ903、および/またはディスク(disc)ドライブ906の任意の組合せに対応することを諒解されよう。情報を提示するように構成された随意の論理820およびローカルユーザ入力を受信するように構成された随意の論理825は、図9には明示的に示されず、そこに含まれる場合も、含まれない場合もある。したがって、図9は、図7の場合のような705Aまたは705BのようなUEの実装形態に加えて、通信デバイス800がサーバとして実現できることを実証するのを助ける。

しかしながら、レイテンシが低くグループ通信を確立する時間が短いことが必要とされるグループ通信サービスでは、従来のマルチキャストチャネルのセットアップ時間がシステム性能にとって有害になり得る。LTEでは、ブロードキャストマルチキャストフレームワーク、すなわちeMBMSは半静的ベアラセットアップをサポートする。eMBMSベアラは、帯域外ネットワーク手順によってセットアップされ、利用可能なeMBMSベアラをセットアップし検出するためのレイテンシは、低レイテンシグループ通信に適切ではない。このレイテンシ問題を解消するために、eMBMSシステムでは、呼が開始される前にマルチキャストベアラを確立する必要がある。これは、ターゲット地理的エリアが特定される必要があり、ネットワーク構成要素が接続される必要があることを意味する。さらに、eMBMSシステムと相互作用するアプリケーションサーバにおいてグループメンバーリストを事前プロビジョニングする必要がある。

従来の方式では、ユニキャストシステムにおいて呼があらかじめ確立され、UEは、呼のセッションを確立し、コアネットワークベアラを確立する。コアネットワークは、呼のリソースを予約し、同様に、UE上のマルチキャストクライアントは呼の計算リソースおよびボコーダリソースを予約する。同様に、アプリケーションサーバは呼の計算リソースを予約する。したがって、後で、PTTボタンが押されたときに、たとえば、システムはフロア調停を実行し、非常に短い時間で媒体を配信することができる。

このシステムは、あらかじめ確立された単一のグループ呼に対してうまく作用する。しかし、システムは、複数の呼をサポートする必要があるときにはうまくスケーリングしない。システムは、あらかじめ確立された各グループ呼のシグナリングを送達する必要があり、あらかじめ確立された各呼がUE、ネットワーク、およびアプリケーションサーバ上のリソースを消費するとすれば、リソースの利用は非効率的になる。ネットワークおよびアプリケーションサーバがうまくスケーリングされ得ると仮定する場合でも、UE上のリソースは依然としてかなり限定され、したがって、メモリと同様に、UE上の計算リソースも、現在の方式を使用してあらかじめ確立された複数の呼をサポートするために枯渇する。

図10は、あらかじめ確立された呼のセルラー(PoC)フローを介した例示的なオープンモバイルアライアンス(OMA)PTTを示す。ステップ1において、各PoCユーザ(図10の例におけるUE1020AおよびUE1020B)に電源が投入される。ステップ2において、UE1020AおよびUE1020Bの各々が接続手順を実行し、それぞれパケット交換(PS)ドメイン1030Aおよび1030Bに対して認証する。ステップ3において、UE1020AおよびUE1020Bの各々が、IMSに関連するシグナリングに適切なベアラを確立させ、必要ならば、IMSに関連するシグナリングのデフォルトのベアラと同じアクセスポイント名(APN)およびIPアドレスを有する追加的な汎用ベアラを確立させることを確実にする。

これらのステップが、各PoCユーザ、すなわち、UE1020AおよびUE1020Bに対して異なる時間に行われてよいことに留意されたい。EPSベアラを使用するかどうかは、UE、ネットワーク、および全体的なシステムが、動作するためにどのように構成されるかに依存する。PoCトークバースト制御および媒体に関するあらかじめ確立されたEPSのQoSが、加入および事業者方針によって許可されている場合には、ベストエフォートよりも高いQoSを有してよいことにも留意されたい。

ステップ4において、UE1020AおよびUE1020Bの各々が、それぞれIMSコア1040Aおよび1040BへのIMS登録を実行する。ステップ5において、UE1020AおよびUE1020Bの各々が、それぞれPoCアプリケーションサーバ170Aおよび170BへのPoC通信用あらかじめ確立されたセッションを確立する。INVITE要求5aはPoCサービス表示を含み、セッション記述プロトコル(SDP)媒体パラメータは、ステップ3において得られたIPアドレスを示す。ステップ5bにおいて、IMSコア1040A/1040Bは、このサービス表示があらかじめ確立されたセッションに関するフィルタリング基準に整合することを確認し、ステップ5cにおいて、セッション確立要求をPoCアプリケーションサーバ170A/170Bに転送する。従来、このセッションセットアップはユニキャストベアラ上で行われる。しかし、これはeMBMSベアラ上で行われてもよい。

UE1020A/1020BのIMSネットワークにおいてサービスベースのローカルポリシーが適用される場合、IMSコア1040A/1040Bはセッションの認証トークンを生成し、次いで、ステップ5eにおいて、あらかじめ確立されたセッションのセットアップ時に200OKに対する応答として認証トークンをUE1020A/1020Bに挿入し送達する。

複数の同時呼の監視をサポートするために、呼ごとにステップ5a〜5eが繰り返される。したがって、UEは、呼ごとに、各呼の状態を維持する必要がある。

ステップ6において、PoCユーザAは、UE1020A上のPTT表示/ボタンを押して、PoCユーザAがUE1020Bのユーザと通信することを望んでいることを示す。ステップ7およびステップ8において、UE1020Aは、媒体転送の確立を要求し、終端ユーザ、すなわちUE1020Bのアドレスを含むSIP REFERメッセージをたとえばIMSコア1040Aを介してPoCアプリケーションサーバ170Aに送る。

ステップ9〜11において、PoCアプリケーションサーバ170Aは、IMSコア1040AおよびIMSコア1040BによってPoCアプリケーションサーバ170BにINVITE要求を送る。ステップ12〜14において、PoCアプリケーションサーバ170Bは、IMSコア1040BおよびIMSコア1040Aを介してPoCアプリケーションサーバ170AにAuto-Answerを示す。ステップ15〜17において、PoCアプリケーションサーバ170Aは媒体確立要求メッセージに肯定応答し、同時にトークバースト確認をUE1020Aに送る。トークバースト制御メッセージは、ステップ3において確立されたEPSベアラ上のUE1020Aに転送される。

ステップ18および19において、PoCアプリケーションサーバ170Aは、UE1020Aからトークバーストが送られてくることをPoCアプリケーションサーバ170Bを介してUE1020Bに通知する。通常、UE1020Bは、トークバーストメッセージを転送できるようになるまでにページングされる必要がある。トークバーストメッセージを受信することがPSドメイン1030Bに対して透過的であることに留意されたい。

ステップ20および21において、UE1020Aは、媒体確立要求メッセージに対する肯定応答とトークバースト確認メッセージに対する肯定応答の両方を受信した後、PoCアプリケーションサーバ170Aに媒体データを送ってよい。ユニキャスト送信の場合、UE1020Aは、トラフィッククラスストリーミングおよび交渉される媒体パラメータに関して必要とされる帯域幅を有するEPSベアラのような、ステップ3のEPSベアラと同じIPアドレスおよびAPNを有する媒体およびトークバースト制御交換用の追加のEPSベアラを確立してよい。UEは、ステップ5において認証トークンを受信した場合、EPSベアラシグナリングに挿入する。ステップ18において確立されたEPSベアラが利用可能になるとすぐに、UE1020AはそのEPSベアラを使用してよい。

ステップ22〜24において、UE1020Aは引き続き媒体を送る。もしステップ22において確立されたEPSベアラが利用可能であるとき、UE1020AはそのEPSベアラを使用してよい。UE1020Aは、PoCアプリケーションサーバ170Aに媒体データを送り、PoCアプリケーションサーバ170Aは、PoCアプリケーションサーバ170Bを介してUE1020Bに媒体データを送る。

ステップ25において、UE1020Bは、トークバーストメッセージを受信した後、トラフィッククラスストリーミングおよび交渉される媒体パラメータに関して必要とされる帯域幅を有するEPSベアラのような、ステップ3のコンテキストと同じIPアドレスおよびAPNを有する媒体およびトークバースト制御交換用の追加のEPSベアラを確立してよい。UEは、ステップ5において認証トークンを受信した場合、EPSベアラシグナリングに挿入する。

eMBMSベアラ発見、アクティブ化、および遅延ベアラ通知プロセスは、eMBMSを低い呼セットアップレイテンシのアプリケーションに使用するのを妨げる。しかし、eMBMSによって実現されるネットワークリソース効率を考慮すると、eMBMSは、たとえば、LTEにおける大規模なグループ通信に最も適した機構である。インタラクティブグループ通信の低レイテンシ呼セットアップ要件を満たすには、あらかじめアクティブ化されたeMBMSベアラを使用すればよい。そのようなあらかじめアクティブ化されたサービスの場合、アプリケーションサーバは、グループ呼要求がクライアントから許容される前に低い呼セットアップレイテンシを必要とするグループ用のベアラを確立する。

ある解決策では、あらかじめ確立されたeMBMSベアラを高速グループ通信セットアップに使用することによってeMBMSをグループ通信用のダウンリンク上で活用する。ユニキャストベアラがアップリンク通信に使用され、場合によっては(たとえば、eMBMSはサポートされない)、ダウンリンク上でもユニキャストが使用される。この解決策では、eMBMSに関連する制御情報を交換するための、アプリケーションサーバ170などのアプリケーションサーバとBM-SC536などのBM-SCとの間のインターフェースとして、図2DにおけるPCRF240DなどのPCRFを使用する。

図11は、本開示の一態様による、UE1120とアプリケーションサーバ170との間の相互作用の例示的なフローを示す図である。1101〜1104において、アプリケーションサーバ170は、UE1120が属するグループの一時モバイルグループ識別子(TMGI)をPCRF1150を介してBM-SC1140に要求する。1105において、アプリケーションサーバ170は、TMGIのグループ識別子へのマッピングを作成する。

1106〜1110において、グループに関してあらかじめ確立されたeMBMSベアラがセットアップされる。対応するMBSFN領域は、BM-SC1140に対して実現されるこのグループ通信用にあらかじめ選択されたeNBsに基づく。1111において、UE1120上のグループ通信用のアプリケーションがグループ通信アプリケーションサービスなどのアプリケーションサービスに登録する。登録メッセージは、UE1120が関心を抱くグループ、たとえば、UE1120が属するすべてのグループのすべてのグループ識別子を含んでよい。1112において、グループのTMGIが利用可能な場合、このTMGIが成功した登録の一部としてUE1120に返される。UE1120は、TMGIのグループ識別子へのマッピングを維持する。

1113において、UE1120は、ネットワークを監視して、関心対象のグループのTMGIに対応するeMBMS送信の可用性を判定する。TMGIがアクティブである場合、UE1120は、eMBMS論理およびトランスポートチャネルを確立し、引き続きトラフィックをTMGIに関して監視する。UE1120は、これらのチャネル上のダウンリンクユーザプレーントラフィックをグループ通信アプリケーションに転送する。

UE1120は、ユニキャストアップリンクベアラを使用して特定のグループのグループ通信セットアップを開始する。UE1120はまた、グループセットアップシグナリングにおけるグループのTMGIに対応するeMBMS送信の可用性を示す。アプリケーションサーバ170は、あらかじめ確立されたeMBMSベアラをダウンリンクに使用するか否かを決定する。1114において、アプリケーションサーバ170はグループ通信トラフィックを送信する。eMBMSベアラがダウンリンクに使用される場合、発展型UTRAN(E-UTRAN)1130は、(たとえば、カウンティング情報に基づいて)ポイントツーポイントサービスまたはポイントツーマルチポイントサービスを使用することを決定することによってリソースの利用をさらに最適化してよい。

本開示の態様は、低い呼セットアップレイテンシを必要とする複数の同時グループ呼をあらかじめ確立して監視するのにUEおよびPTTアプリケーションレイヤを使用するのを可能にする。このシステムは、ユーザがアクティブグループのうちの1つを選択し、フロアが媒体の送達を要求するのを可能にする。

このシステムは、登録時にUEからの表示を使用して呼をあらかじめ確立する。登録時に、アプリケーションサーバは、そのデータベースからUEのグループメンバーシップを取り出し、UEのセッションをあらかじめ確立する。アプリケーションサーバは、UEが関心を抱く各グループにマッピングされた呼識別子のリストをUEに送る。UEは次いで、任意のインコールシグナリング用の呼識別子を使用する。

図12は、本開示の一態様による、複数のPTT呼をあらかじめ確立するための例示的なフローを示す図である。フローは、ベアラ事前確立段階から始まる。図12の例では、複数のUE1220が通信グループを形成する。通信グループは、たとえば、同じ通信アプリケーションを使用する友人または同僚のグループなど、あらかじめ決定されてもよく、またはたとえば、所与の地理的領域内のすべてのユーザなど、オンザフライで決定されてもよい。

1201において、EPC1240内のBM-SCおよびアプリケーションサーバ170はグループ通信用のTMGIを予約する。1202において、E-UTRAN1230、図2DにおけるBM-SC236DなどのEPC1240内のBM-SC、およびアプリケーションサーバ170は、通信を行って予約されたTMGI用のベアラを確立する。BM-SCは、eMBMSベアラを確立し、1203において、TMGIをE-UTRAN1230にブロードキャストする。E-UTRAN1230は次いで、TMGIをUE1220にブロードキャストする。TMGIは、UE1220が現在サポートされているグループ呼を知るのを可能にする。

図12に示すフローは、引き続きアプリケーション(グループ通信アプリケーションなど)セッション事前確立およびベアラ識別段階に移行する。1204において、UE1220は、E-UTRAN1230、ならびにそれぞれ図2DにおけるS-GW230DおよびP-GW235Dなどの、EPC1240におけるSGWおよびPGWを介してアプリケーションサーバ170に登録し、UE1220が関心を抱くグループのリストを提供する。1205において、アプリケーションサーバ170は、関心対象のグループに関連するグループ識別子をデータベース1180から取り出すむ。1206において、アプリケーションサーバ170は、後述のように、あらかじめ確立されたベアラ方式を使用できるUE1220の各グループの呼識別子にグループ識別子をマッピングする。

1207において、アプリケーションサーバ170は、EPC1240内のBM-SCにグループ用の特定数のベアラをあらかじめ確立するように指示する。アプリケーションサーバ170は、同じベアラ上で複数のグループを多重化することを決定してよい。したがって、そのようなベアラが存在する場合、アプリケーションサーバ170は新しいベアラに対してアクティブ化を開始しなくてよい。

1208において、アプリケーションサーバ170は、ユニキャストベアラ上で、あらかじめ確立されたグループのリストおよびグループ識別子の対応する呼識別子へのマッピングをUE1220に送る。EPC1240内のSGWおよびPGWがこの情報をE-UTRAN1230に転送し、E-UTRAN1230がこの情報をUE1220に転送する。1209において、UE1220は、あらかじめ確立されたグループに注目し、呼識別子をグループ識別子にマッピングする。

この呼はアクティブではないので、アプリケーションサーバ170は、呼にリソース(たとえば、メモリ)を割り振らず、多重化された他の呼と同様にアイドル状態の呼と見なす。

図12に示すフローでは、引き続き、あらかじめ確立されたベアラがグループ通信段階に使用される。1210において、UE1220のうちの1つのユーザが、たとえば、PTTボタンを押してフロアにグループ呼を要求することによってグループ呼を開始する。1211において、UEは、あらかじめ確立されたグループのうちの1つに関してユーザによって要求されたグループに対応する呼識別子を選択して、通話または媒体の送信を求める生成された要求(すなわち、図12の例ではPTTフロア要求)に含める。クライアントは、この現在アクティブな呼専用の別のプロセスを作成し、メモリリソースをこの呼専用にしてよい。

1212において、UEは、通話または媒体送信を求める要求をE-UTRAN1230ならびにEPC1240のSGWおよびPGWを介してアプリケーションサーバ170に送る。1213において、アプリケーションサーバ170は、あらかじめ確立されたグループの呼識別子を受信し、呼識別子を使用して対応するグループ識別子を探し、グループ識別子を使用してグループ内の他の参加者を特定し、他の参加者(すなわち、図12の例では残りのUE1220)に通知する。アプリケーションサーバ170は、アプリケーションレイヤメソッドに応じて、呼に使用される共通eMBMSベアラまたは目標UEの専用ベアラ上で、アプリケーションレイヤシグナリングを使用して他の参加者に通知する。アプリケーションサーバ170は、この現在アクティブな呼専用の別のプロセスを作成し、メモリリソースをこの呼専用にしてよい。

1214において、アプリケーションサーバ170は、EPC1240のSGWおよびPGWならびにE-UTRAN1230を介してユニキャストベアラ上で発呼側UEにフロア要求許可メッセージを送る。1215において、発呼側UEは、グループ用のトークスパートまたは媒体をE-UTRAN1230、SGW、およびPGWを介してアプリケーションサーバ170に送信する。1216において、アプリケーションサーバ170は、アプリケーションレイヤメソッドに応じて、呼の媒体転送に使用される共通eMBMSベアラまたは目標UEの専用ベアラまたはその両方の組合せ上で、EPC1240のBM-SCおよびE-UTRAN1230を介してUE1220のグループの他のメンバーにトークスパートまたは媒体を転送する。

グループ識別子は、次のようなグループの総称的静的特性の参照である。
グループ呼を再確立する必要性、
マルチキャストリソースの使用、
メンバーのリスト、
各メンバーの機能(すなわち、QoS、サポートされるデータタイプ、ユニキャスト、マルチキャスト機能など)、
参加者ごとのマルチキャストベアラまたはユニキャストベアラの使用、
グループおよびメンバーの認証資料、
グループに関してサポートされる媒体フォーマット(たとえば、ボコーダ、オーディオ、ビデオ、画像タイプ、半二重、全二重など)、および/または
サービスをサポートするのに必要なアプリケーションレイヤ固有の他のすべてのパラメータ(たとえば、送話者プリエンプションランク、地理的領域、管理領域、課金およびOAMフォーマット、タイマ、呼状態情報パラメータなど)。

上記の特性は呼の間変化しない。しかし、呼がアプリケーションサーバ170に入ると、いくつかの特性が利用可能になるかまたは呼の間に変化することがある。グループ識別子によって参照されるグループの静的特性および呼セットアップ時にのみ利用可能な動的特性の総称的な参照は、呼識別子によって行われる。

呼識別子は、グループ識別子とともに以下の特性を指す。
アプリケーションサーバとの通信のIPアドレスおよびポート、
呼に参加するメンバーの数、
クライアントとの通信用のポート、
送信元識別子(たとえば、RTPパケットの同期送信元(SSRC))、
呼のセッション鍵、および/または
呼の選択された媒体フォーマット(たとえば、ボコーダ、ビデオフォーマットなど)。

アプリケーションサーバ170は、メンバーリスト内でユーザが定義されるグループごとに、グループ識別子、対応する呼識別子、および対応するTMGIを提供する。グループ識別子の呼識別子およびTMGIへのこのマッピングは、呼を一意に特定する。したがって、クライアントは、本明細書では単一の応答における多重化された呼識別子のUEへの供給と呼ばれる、グループごとの上記のマッピングのリストを受信する。

本明細書において開示されるシステムは、単一の要求を使用してeMBMSシステム上のユーザに関するすべての必要な呼をあらかじめ確立し、かつ呼識別子を提供することによって、複数のセッション要求を不要にし、それによってシグナリングトラフィックを最適化する。さらに、本明細書において開示されるシステムは、セッションごとの別個のコンテンツの維持を不要にすることによって、UEおよびアプリケーションサーバに対するメモリ制約も低減させる。

図13は、本開示の一態様による、例示的な呼事前確立フローを示す図である。図13に示すフローは、アプリケーションサーバ170などのアプリケーションサーバによって実行され得る。1310において、アプリケーションサーバ170は、事前確立のためのグループのリストを随意に含んでよい登録要求をクライアントUEから受信する。1320において、アプリケーションサーバ170は、UEがあらかじめ確立されたセットアップを使用することを示していたか否かを判定する。代替的に、アプリケーションサーバ170は、登録の一部として、図11のデータベース1180などの、アプリケーションサーバ170内のグループデータベースからユーザ情報を取り出し、ユーザがあらかじめ確立されたグループ呼に関してプロビジョニングされているかどうかを判定してよい。アプリケーションサーバ170は、ユーザがあらかじめ確立されたグループ呼に関してプロビジョニングされていないかまたはあらかじめ確立された呼を示していなかったと判定した場合、1330において、通信を通常の呼として扱う。

しかし、1340において、クライアントUEがあらかじめ確立された呼セットアップの使用を示していている場合、アプリケーションサーバ170は、図11のデータベース1180などのデータベースからグループリストを取り出す。1350において、アプリケーションサーバ170は、あらかじめ確立された呼セットアップを必要とするすべてのグループ呼がアクティブ化されているか否かを判定する。グループ呼が「アクティブ化されている」場合、フローは1370に進む。グループ呼がアクティブ化されていない場合、1355において、アプリケーションサーバ170は、既存のeMBMSベアラ上でグループ呼を多重化できるか否かを判定する。多重化が望ましい場合、フローは1370の呼セットアップ手順に進む。ベアラがあらかじめ確立されておらず、既存のベアラ上での多重化が望ましくない場合、1360において、アプリケーションサーバ170は、呼をあらかじめ確立し、フロア制御に関する呼識別子を含む、呼のリソースを予約する。

1370において、あらかじめ確立された呼セットアップを必要とするグループ呼のすべてがアクティブ化されている場合、アプリケーションサーバ170は、呼セットアップ手順を進め、クライアントUEのIPアドレスまたはネットワーク識別子などのクライアントUEのベアラ情報を各グループの呼参加リストに追加する。したがって、各グループは、参加者および共通するeMBMSベアラ情報とは別の参加者のユニキャストベアラ情報のリストを作成する。アプリケーションサーバ170は次いで、インコール通信に使用すべき呼識別子を選択する。グループが非アクティブ状態であるので、アプリケーションサーバ170は、アイドル状態の呼を扱う単一のプロセスにこのグループの情報を追加し、呼にリソースが割り振られることはない。

1380において、アプリケーションサーバ170は、あらかじめ確立された各グループに関するクライアントUEに多重化された通知を送り、呼識別子を提供する。

1390において、クライアントUEは、アイドル状態の呼を扱うプロセスに情報を追加し、リソースが割り振られることはない。アプリケーションサーバ170は、フロア要求メッセージを待つ。クライアントUEは、フロア要求を行う際、グループの呼識別子を使用する。

図14は、本開示の一態様による、例示的な媒体交換フローを示す図である。アプリケーションサーバ170などのアプリケーションサーバおよびUEでは、アイドル状態である呼にメモリ、ボコーダ、マイクロフォンなどのリソースが予約されることはないことに留意されたい。1410において、UE520、UE700A、UE700B、またはUE1120などのUEが、ユーザが特定のグループに関するPTTボタンを押したことを検出する。たとえば、このことは、連絡先リストから得られたグループを示すかまたは最後に試みられた呼を再使用するユーザインターフェース(UI)あるいはボタンを押す前またはボタンを押す間にグループを選択する任意の他の手段に基づいてよい。1415において、UEは、関連するトークスパートまたは媒体が送られるグループがあらかじめ確立されているか否かを判定する。グループがあらかじめ確立されていない場合、1420において、UEは従来のオンデマンド手順を使用する。しかし、グループがあらかじめ確立されている場合、1425において、UEがPTTグループのグループ識別子を判定し、シグナリングメッセージにおいて関連する呼識別子を使用してフロアを要求する。1430において、UEは、通話要求メッセージを呼識別子とともにアプリケーションサーバ170などのアプリケーションサーバに送る。

1435において、アプリケーションサーバ170は、呼識別子に基づいてグループおよびその参加者を探す。グループがアクティブである場合、アプリケーションサーバ170は、呼の新しいプロセスを作成し、リソースを割り当てる。1440において、アプリケーションサーバ170は、フロア通知に関するインコールシグナリングを参加者に送り、呼シグナリング手順においてグループ識別子を使用して要求側UEにフロアを許可する。

1445において、TAGIに基づいてeMBMSベアラを監視する参加しているクライアントUEが、アプリケーションサーバ170から呼シグナリングメッセージを受信し、呼識別子に基づいてグループを特定する。参加しているクライアントUEはトークスパートまたは媒体を受信する準備をする。

1450において、トークスパートまたは媒体を送ることを要求しているクライアントUEは、シグナリングおよび媒体メッセージにおいて呼識別子を使用して媒体をアプリケーションサーバ170に転送する。1455において、アプリケーションサーバ170は、参加しているクライアントUEのベアラ識別子またはIPアドレスに基づいて参加しているクライアントUEに媒体を転送する。1460において、トークスパートまたは媒体送信が終了する。アプリケーションサーバ170はハングタイマを起動する。1465において、ハングタイマが満了すると、アプリケーションサーバ170はプロセス割当てを解放し、したがって、呼に割り当てられたメモリリソースを解放する。ネットワークおよびeMBMSリソースは依然として維持されている。

図15は、本開示の一態様による、MBMSまたはeMBMSを介したグループ通信のための例示的なフローを示す図である。図15に示すフローは、アプリケーションサーバ170などのサーバによって実行され得る。1502において、サーバは、図12の1204および/または図13の1310などにおいて、UEから登録要求を受信する。登録要求は、UEが関心を抱く1つまたは複数の通信グループを示してよい。1504において、サーバは、UEが図13の1320などにおいてあらかじめ確立されたグループ呼に関してプロビジョニングされていると判定する。1506において、サーバは、図12の1205および/または図13の1340などにおいて、1つまたは複数の通信グループのグループ識別子を取り出す。1508において、サーバは、図12の1206などにおいて、1つまたは複数の通信グループの組における各通信グループのグループ識別子に1つまたは複数の呼識別子をマッピングする。1510において、サーバは、図12の1208などにおいて、1つまたは複数の通信グループの組および1つまたは複数のマッピングされた呼識別子を示すメッセージをUEに送る。1512において、サーバは、図13の1355および1370などにおいて、1つまたは複数のあらかじめ確立されたマルチキャストリソースに複数のグループ呼を割り当てる。

図16は、本開示の一態様による、MBMSまたはeMBMSを介したグループ通信のための例示的なフローを示す図である。図16に示すフローは、UE520、UE700A、UE700B、またはUE1120のいずれかなどのUEによって実行され得る。1602において、UEは、図12の1204などにおいて、アプリケーションサーバ170などのサーバに登録要求を送る。登録要求は、UEが関心を抱く1つまたは複数の通信グループを示し、場合によっては、グループ通信サービス用のサーバを登録するUEの意図を示してよい。1604において、UEは、図12の1207などにおいて、あらかじめ確立されたマルチキャストリソースが割り当てられた1つまたは複数の通信グループの組を示すメッセージをサーバから受信する。1606において、UEは、図12の1208などにおいて、サーバから1つまたは複数の呼識別子を受信し、1つまたは複数の呼識別子は、1つまたは複数の通信グループの組における各通信グループのグループ識別子にマッピングされる。1608において、UEは、図12の1209などにおいて、1つまたは複数の通信グループの組における各通信グループのグループ識別子への1つまたは複数の呼識別子のマッピングを記憶する。1610において、UEは、図12の1209および図13の1390などにおいて、1つまたは複数の通信グループの組に関する1つまたは複数のグループ呼セッションを維持する。

上述の態様は、従来技術に勝るいくつかの利点をもたらす。たとえば、多重化技法を使用することによって、本明細書において開示するシステムは、様々なデバイス(たとえば、アプリケーションサーバおよびUE)上で最小限のネットワークリソースおよび計算リソースを使用する。さらに、同様の方式を1対1の呼に拡張してもよく、その場合、アプリケーションサーバ170は、ユーザの連絡先のあらゆる組合せの識別子を提供する。

本明細書において開示された実施形態に関連して説明された様々な例示的な論理ブロック、モジュール、回路、およびアルゴリズムステップは、電子ハードウェア、コンピュータソフトウェア、または両者の組合せとして実装され得ることを当業者は諒解されよう。ハードウェアおよびソフトウェアのこの互換性を明確に示すために、様々な例示的構成要素、ブロック、モジュール、回路、およびステップは、概して、それらの機能に関して前述された。そのような機能がハードウェアとして実装されるかソフトウェアとして実装されるかは、特定の適用例およびシステム全体に課される設計制約に応じて決まる。熟練した職人は、各特定の適用例について変化する方法で、記載された機能を実装することができるが、そのような実装の決定は、本開示の範囲からの逸脱をもたらすものとして解釈されるべきではない。

本明細書において開示された実施形態に関連して説明された方法、シーケンス、および/またはアルゴリズムは、ハードウェアで、プロセッサによって実行されるソフトウェアモジュールで、またはその2つの組合せで直接具現され得る。ソフトウェアモジュールは、RAMメモリ、フラッシュメモリ、ROMメモリ、EPROMメモリ、EEPROMメモリ、レジスタ、ハードディスク、リムーバブルディスク、CD-ROM、または当技術分野で知られている任意の他の形の記憶媒体中に存在し得る。例示的な記憶媒体は、プロセッサが記憶媒体から情報を読み取り、記憶媒体に情報を書き込むことができるように、プロセッサに結合する。代替で、記憶媒体は、プロセッサに不可欠でもよい。

したがって、本開示の実施形態は、eMBMSを介したグループ通信のための方法を具現化するコンピュータ可読媒体を含み得る。したがって、本開示は図示の例に限定されず、本明細書で説明した機能を実施するためのいかなる手段も、本発明の実施形態に含まれる。

上記の開示は本開示の例示的な実施形態を示すが、添付の特許請求の範囲によって規定される本開示の範囲から逸脱することなく、本明細書において様々な変更および修正が行われ得ることに留意されたい。本明細書に記載された本開示の実装形態による方法クレームの機能、ステップおよび/または動作は、特定の順序で実行される必要はない。さらに、本開示の要素は単数形で記載または特許請求されている場合があるが、単数形に限定することが明示的に述べられていない限り、複数形が考えられる。

100 ワイヤレス通信システム
104 エアインターフェース
108 エアインターフェース
120 RAN
125 アクセスポイント
140 コアネットワーク
170 アプリケーションサーバ
175 インターネット
300 例示的な送信構造
412 時間周波数ブロック
500 MBMSサービスエリア
502 ブロードキャストエリア
530 コアネットワーク
532 EME
536 BM-SC
550 アプリケーションサーバ
554 マルチキャストパケット
570 コンテンツプロバイダ
612 データソース
620 送信プロセッサ
636 MIMO検出器
640 コントローラ/プロセッサ
644 スケジューラ
660 MIMO検出器
670 受信プロセッサ
678 データソース
680 送信プロセッサ
682 TX MIMOプロセッサ
690 コントローラ/プロセッサ
702 プラットフォーム
706 トランシーバ
708 ASIC
712 メモリ
714 ローカルデータベース
800 通信デバイス
805 情報を受信および/または送信するように構成された論理
810 情報を処理するように構成された論理
815 情報を記憶するように構成された論理
820 情報を提示するように構成された論理
825 ローカルユーザ入力を受信するように構成された論理
900 サーバ
901 プロセッサ
902 揮発性メモリ
903 ディスクドライブ
904 ネットワークアクセスポイント
906 ディスクドライブ
907 ネットワーク
1140 BM-SC
1150 PCRF
1180 データベース
1220 UES
1230 E-UTRAN
1240 EPC

Claims (54)

1. マルチキャストサービスを介したグループ通信のための方法であって、
   登録要求をユーザ機器(UE)からサーバに送るステップであって、前記登録要求は、前記UEが関心を抱く1つまたは複数の通信グループを示し、場合によっては、グループ通信サービス用のサーバを登録する前記UEの意図を含む、ステップと、
   あらかじめ確立されたマルチキャストリソースが割り当てられた前記1つまたは複数の通信グループの組を示すメッセージを前記サーバから受信するステップと、
   前記サーバから1つまたは複数の呼識別子を受信するステップであって、前記1つまたは複数の呼識別子は、前記1つまたは複数の通信グループの前記組における各通信グループのグループ識別子にマッピングされる、ステップと、
   前記1つまたは複数の通信グループの前記組における各通信グループの前記グループ識別子への前記1つまたは複数の呼識別子のマッピングを記憶するステップと、
   前記1つまたは複数の通信グループの前記組に関する1つまたは複数のグループ呼セッションを維持するステップとを含み、
   前記サーバは、前記あらかじめ確立されたマルチキャストリソースに複数のグループ呼を割り当てる、方法。
2. 前記1つまたは複数のグループ呼セッションを維持するステップは、呼状態情報を維持するステップを含む、請求項1に記載の方法。
3. 前記1つまたは複数の通信グループの前記組に関する1つのグループ呼セッションを維持するステップをさらに含む、請求項1に記載の方法。
4. 前記UEが、あらかじめ確立されたグループ呼に関してプロビジョニングされていると判定するステップをさらに含む、請求項1に記載の方法。
5. 前記サーバに呼要求を送るステップであって、前記呼要求は、前記1つまたは複数の通信グループの前記組のうちの1つの通信グループに対応する呼識別子を含む、ステップをさらに含む、請求項1に記載の方法。
6. 通信グループのグループ呼を確立するための要求を受信するステップと、
   前記通信グループのグループ識別子を判定するステップと、
   前記グループ識別子に基づいて前記呼識別子を判定するステップとをさらに含む、請求項5に記載の方法。
7. 前記呼要求は、グループ呼を開始するための要求を含む、請求項5に記載の方法。
8. 前記グループ呼はプッシュツートーク呼を含む、請求項7に記載の方法。
9. 前記通信グループに関する情報をアイドル状態の呼を扱うプロセスに追加するステップをさらに含む、請求項5に記載の方法。
10. 前記マルチキャストリソースは、マルチメディアブロードキャスト/マルチキャストサービス(MBMS)ベアラを含む、請求項1に記載の方法。
11. 前記1つまたは複数の呼識別子は、共通の一時モバイルグループ識別子(TMGI)上にマッピングされる、請求項1に記載の方法。
12. マルチキャストサービスを介したグループ通信のための方法であって、
    ユーザ機器(UE)から登録要求を受信するステップであって、前記登録要求は、前記UEが関心を抱く1つまたは複数の通信グループを示す、ステップと、
    前記UEが、あらかじめ確立されたグループ呼に関してプロビジョニングされていると判定するステップと、
    前記1つまたは複数の通信グループのグループ識別子を取り出すステップと、
    前記1つまたは複数の通信グループの組における各通信グループの前記グループ識別子に1つまたは複数の呼識別子をマッピングするステップと、
    前記1つまたは複数の通信グループの前記組および前記1つまたは複数のマッピングされた呼識別子を示すメッセージを前記UEに送るステップと、
    前記1つまたは複数のあらかじめ確立されたマルチキャストリソース上に複数のグループ呼を割り当てるステップとを含み、
    前記UEは、前記1つまたは複数の通信グループの前記組に関する1つまたは複数のグループ呼セッションを維持する方法。
13. 前記1つまたは複数の通信グループの前記組用の1つまたは複数のマルチキャストリソースをあらかじめ確立するステップをさらに含む、請求項12に記載の方法。
14. 前記1つまたは複数のあらかじめ確立されたマルチキャストリソース上に複数のグループ呼を割り当てる前記ステップは、前記1つまたは複数のあらかじめ確立されたマルチキャストリソース上で前記複数のグループ呼を多重化するステップを含む、請求項12に記載の方法。
15. 前記1つまたは複数の通信グループの前記組および前記1つまたは複数のマッピングされた呼識別子を示す前記メッセージを前記UEに送るステップをさらに含む、請求項12に記載の方法。
16. 前記UEが前記1つまたは複数のグループ呼セッションを維持するステップは、前記UEが呼状態情報を維持するステップを含み、サーバが呼状態情報を維持する、請求項12に記載の方法。
17. 前記UEから呼要求を受信するステップであって、前記呼要求は、サーバによって提供される呼識別子を含むステップと、
    前記呼識別子に基づいて通信グループの参加者のリストを特定するステップと、
    参加者の前記リストに呼通知を送信するステップとをさらに含む、請求項12に記載の方法。
18. 前記UEからフロア要求を受信するステップであって、前記フロア要求は、呼識別子を含む、ステップをさらに含む、請求項17に記載の方法。
19. 前記呼要求は、グループ呼を開始するための要求を含む、請求項17に記載の方法。
20. 前記グループ呼はプッシュツートーク呼を含む、請求項19に記載の方法。
21. 前記呼要求に対応するグループ呼を前記1つまたは複数のあらかじめ確立されたマルチキャストリソース上で多重化できるか否かを判定するステップをさらに含む、請求項17に記載の方法。
22. 前記通信グループに関する情報を、あらかじめ確立されたすべてのアイドル状態のグループ呼を扱う多重化されたプロセスに追加するステップをさらに含む、請求項17に記載の方法。
23. ハングタイマの満了時に前記マルチキャストリソースを解放するステップと、
    多重化されたアイドル状態の呼処理に割当てプロセスを再割当てするステップをさらに含む、請求項12に記載の方法。
24. 前記マルチキャストリソースは、マルチメディアブロードキャスト/マルチキャストサービス(MBMS)ベアラを含む、請求項12に記載の方法。
25. 前記1つまたは複数の呼識別子は、共通の一時モバイルグループ識別子(TMGI)上にマッピングされる、請求項12に記載の方法。
26. マルチキャストサービスを介したグループ通信のための装置であって、
    登録要求をユーザ機器(UE)からサーバに送るように構成された論理であって、前記登録要求は、前記UEが関心を抱く1つまたは複数の通信グループを示し、場合によっては、グループ通信サービス用のサーバを登録する前記UEの意図を含む、論理と、
    あらかじめ確立されたマルチキャストリソースが割り当てられた前記1つまたは複数の通信グループの組を示すメッセージを前記サーバから受信するように構成された論理と、
    前記サーバから1つまたは複数の呼識別子を受信するように構成された論理であって、前記1つまたは複数の呼識別子は、前記1つまたは複数の通信グループの前記組における各通信グループのグループ識別子にマッピングされる、論理と、
    前記1つまたは複数の通信グループの前記組における各通信グループの前記グループ識別子への前記1つまたは複数の呼識別子のマッピングを記憶するように構成された論理と、
    前記1つまたは複数の通信グループの前記組に関する1つまたは複数のグループ呼セッションを維持するように構成された論理とを備え、
    前記サーバは、前記あらかじめ確立されたマルチキャストリソースに複数のグループ呼を割り当てる、装置。
27. 前記1つまたは複数のグループ呼セッションを維持するように構成された前記論理は、呼状態情報を維持するように構成された論理を備える、請求項26に記載の装置。
28. 前記1つまたは複数の通信グループの前記組に関する1つまたは複数のグループ呼セッションを維持するように構成された論理をさらに備える、請求項26に記載の装置。
29. 前記UEが、あらかじめ確立されたグループ呼に関してプロビジョニングされていると判定するように構成された論理をさらに備える、請求項26に記載の装置。
30. 前記サーバに呼要求を送るように構成された論理であって、前記呼要求は、前記1つまたは複数の通信グループの前記組のうちの1つの通信グループに対応する呼識別子を含む、論理をさらに備える、請求項26に記載の装置。
31. 通信グループのグループ呼を確立するための要求を受信するように構成された論理と、
    前記通信グループのグループ識別子を判定するように構成された論理と、
    前記グループ識別子に基づいて前記呼識別子を判定するように構成された論理とをさらに備える、請求項30に記載の装置。
32. 前記呼要求は、グループ呼を開始するための要求を含む、請求項30に記載の装置。
33. 前記グループ呼はプッシュツートーク呼を含む、請求項32に記載の装置。
34. 前記通信グループに関する情報をアイドル状態の呼を扱うプロセスに追加するように構成された論理をさらに備える、請求項30に記載の装置。
35. 前記マルチキャストリソースは、マルチメディアブロードキャスト/マルチキャストサービス(MBMS)ベアラを含む、請求項26に記載の装置。
36. 前記1つまたは複数の呼識別子は、共通の一時モバイルグループ識別子(TMGI)上にマッピングされる、請求項26に記載の装置。
37. マルチキャストサービスを介したグループ通信のための装置であって、
    ユーザ機器(UE)から登録要求を受信するように構成された論理であって、前記登録要求は、前記UEが関心を抱く1つまたは複数の通信グループを示す、論理と、
    前記UEが、あらかじめ確立されたグループ呼に関してプロビジョニングされていると判定するように構成された論理と、
    前記1つまたは複数の通信グループのグループ識別子を取り出すように構成された論理と、
    前記1つまたは複数の通信グループの組における各通信グループの前記グループ識別子に1つまたは複数の呼識別子をマッピングするように構成された論理と、
    前記1つまたは複数の通信グループの前記組および前記1つまたは複数のマッピングされた呼識別子を示すメッセージを前記UEに送るように構成された論理と、
    前記1つまたは複数のあらかじめ確立されたマルチキャストリソース上に複数のグループ呼を割り当てるように構成された論理とを備え、
    前記UEは、前記1つまたは複数の通信グループの前記組に関する1つまたは複数のグループ呼セッションを維持する装置。
38. 前記1つまたは複数の通信グループの前記組用の1つまたは複数のマルチキャストリソースをあらかじめ確立するように構成された論理をさらに備える、請求項37に記載の装置。
39. 前記1つまたは複数のあらかじめ確立されたマルチキャストリソース上に複数のグループ呼を割り当てるように構成された前記論理は、前記1つまたは複数のあらかじめ確立されたマルチキャストリソース上で前記複数のグループ呼を多重化するように構成された論理を備える、請求項37に記載の装置。
40. 前記1つまたは複数の通信グループの前記組および前記1つまたは複数のマッピングされた呼識別子を示す前記メッセージを1つまたは複数の目標UEに送るように構成された論理をさらに備える、請求項37に記載の装置。
41. 前記UEが前記1つまたは複数のグループ呼セッションを維持することは、前記UEが呼状態情報を維持することを含み、サーバが呼状態情報を維持する、請求項37に記載の装置。
42. 前記UEから呼要求を受信するように構成された論理であって、前記呼要求は、サーバによって提供される呼識別子を含む、論理と、
    前記呼識別子に基づいて通信グループの参加者のリストを特定するように構成された論理と、
    参加者の前記リストに呼通知を送信するように構成された論理とをさらに備える、請求項37に記載の装置。
43. 前記UEからフロア要求を受信するように構成された論理であって、前記フロア要求は呼識別子を含む、論理をさらに備える、請求項42に記載の装置。
44. 前記呼要求は、グループ呼を開始するための要求を含む、請求項42に記載の装置。
45. 前記グループ呼はプッシュツートーク呼を含む、請求項44に記載の装置。
46. 前記呼要求に対応するグループ呼を前記1つまたは複数のあらかじめ確立されたマルチキャストリソース上で多重化できるか否かを判定するように構成された論理をさらに含む、請求項42に記載の装置。
47. 前記通信グループに関する情報を、あらかじめ確立されたすべてのアイドル状態のグループ呼を扱う多重化されたプロセスに追加するように構成された論理をさらに備える、請求項42に記載の装置。
48. ハングタイマの満了時に前記マルチキャストリソースを解放するように構成された論理と、
    多重化されたアイドル状態の呼処理に割当てプロセスを再割当てするように構成された論理をさらに備える、請求項37に記載の装置。
49. 前記マルチキャストリソースは、マルチメディアブロードキャスト/マルチキャストサービス(MBMS)ベアラを含む、請求項37に記載の装置。
50. 前記1つまたは複数の呼識別子は、共通の一時モバイルグループ識別子(TMGI)上にマッピングされる、請求項37に記載の装置。
51. マルチキャストサービスを介したグループ通信のための装置であって、
    登録要求をユーザ機器(UE)からサーバに送るための手段であって、前記登録要求は、前記UEが関心を抱く1つまたは複数の通信グループを示し、場合によっては、グループ通信サービス用のサーバを登録する前記UEの意図を含む、手段と、
    あらかじめ確立されたマルチキャストリソースが割り当てられた前記1つまたは複数の通信グループの組を示すメッセージを前記サーバから受信するための手段と、
    前記サーバから1つまたは複数の呼識別子を受信するための手段であって、前記1つまたは複数の呼識別子は、前記1つまたは複数の通信グループの前記組における各通信グループのグループ識別子にマッピングされる、手段と、
    前記1つまたは複数の通信グループの前記組における各通信グループの前記グループ識別子への前記1つまたは複数の呼識別子のマッピングを記憶するための手段と、
    前記1つまたは複数の通信グループの前記組に関する1つまたは複数のグループ呼セッションを維持するための手段とを備え、
    前記サーバは、前記あらかじめ確立されたマルチキャストリソースに複数のグループ呼を割り当てる、装置。
52. マルチキャストサービスを介したグループ通信のための装置であって、
    ユーザ機器(UE)から登録要求を受信するための手段であって、前記登録要求は、前記UEが関心を抱く1つまたは複数の通信グループを示す手段と、
    前記UEが、あらかじめ確立されたグループ呼に関してプロビジョニングされていると判定するための手段と、
    前記1つまたは複数の通信グループのグループ識別子を取り出すための手段と、
    前記1つまたは複数の通信グループの組における各通信グループの前記グループ識別子に1つまたは複数の呼識別子をマッピングするための手段と、
    前記1つまたは複数の通信グループの前記組および前記1つまたは複数のマッピングされた呼識別子を示すメッセージを前記UEに送るための手段と、
    前記1つまたは複数のあらかじめ確立されたマルチキャストリソース上に複数のグループ呼を割り当てるための手段とを備え、
    前記UEは、前記1つまたは複数の通信グループの前記組に関する1つまたは複数のグループ呼セッションを維持する装置。
53. マルチキャストサービスを介したグループ通信のための非一時的コンピュータ可読媒体であって、
    登録要求をユーザ機器(UE)からサーバに送るための少なくとも1つの命令であって、前記登録要求は、前記UEが関心を抱く1つまたは複数の通信グループを示し、場合によっては、グループ通信サービス用のサーバを登録する前記UEの意図を含む、命令と、
    あらかじめ確立されたマルチキャストリソースが割り当てられた前記1つまたは複数の通信グループの組を示すメッセージを前記サーバから受信するための少なくとも1つの命令と、
    前記サーバから1つまたは複数の呼識別子を受信するための少なくとも1つの命令であって、前記1つまたは複数の呼識別子は、前記1つまたは複数の通信グループの前記組における各通信グループのグループ識別子にマッピングされる、命令と、
    前記1つまたは複数の通信グループの前記組における各通信グループの前記グループ識別子への前記1つまたは複数の呼識別子のマッピングを記憶するための少なくとも1つの命令と、
    前記1つまたは複数の通信グループの前記組に関する1つまたは複数のグループ呼セッションを維持するための少なくとも1つの命令とを含み、
    前記サーバは、前記あらかじめ確立されたマルチキャストリソースに複数のグループ呼を割り当てる、非一時的コンピュータ可読媒体。
54. マルチキャストサービスを介したグループ通信のための非一時的コンピュータ可読媒体であって、
    ユーザ機器(UE)から登録要求を受信するための少なくとも1つの命令であって、前記登録要求は、前記UEが関心を抱く1つまたは複数の通信グループを示す、命令と、
    前記UEが、あらかじめ確立されたグループ呼に関してプロビジョニングされていると判定するための少なくとも1つの命令と、
    前記1つまたは複数の通信グループのグループ識別子を取り出すための少なくとも1つの命令と、
    前記1つまたは複数の通信グループの組における各通信グループの前記グループ識別子に1つまたは複数の呼識別子をマッピングするための少なくとも1つの命令と、
    前記1つまたは複数の通信グループの前記組および前記1つまたは複数のマッピングされた呼識別子を示すメッセージを前記UEに送るための少なくとも1つの命令と、
    前記1つまたは複数のあらかじめ確立されたマルチキャストリソース上に複数のグループ呼を割り当てるための少なくとも1つの命令とを含み、
    前記UEは、前記1つまたは複数の通信グループの前記組に関する1つまたは複数のグループ呼セッションを維持する、非一時的コンピュータ可読媒体。

Images