(57)【要約】第３世代パートナーシッププロジェクト（３ＧＰＰ）通信ネットワーク上で実行される通信方法は、通信グループのグループメンバとグループアプリケーションサーバとの間でアタッチメントをもたらすステップと、グループメンバとグループアプリケーションサーバとの間のデタッチメントを検出するステップと、３ＧＰＰ通信ネットワークによってアタッチメントを再確立するステップと、を含む。モビリティ管理エンティティ（ＭＭＥ）がアタッチメントをもたらすことができる。グループ通信サービスイネーブラアプリケーションサーバ（ＧＣＳＥ  ＡＳ）またはマルチポイントサービス（ＭｕＳｅ）機能がデタッチメントを検出することができる。アタッチメントがＭｕＳｅ機能に従って再確立されてもよい。グループ通信ベアラは、グループ通信ベアラにリソースを割り当てるための第１の優先度レベル、および非グループ通信ベアラにリソースを割り当てるための第２の優先度レベルを有してもよい。第２の優先度レベルは第１の優先度レベルとは異なってもよい。異なる品質制御インデックス（ＱＣＩ）が、グループ通信ベアラおよび非グループ通信ベアラに提供されてもよい。
2016536918.tif 000002
【特許請求の範囲】
【請求項１】
第３世代パートナーシッププロジェクト（３ＧＰＰ）通信ネットワーク上で実行される通信方法であって、
通信グループのグループメンバとグループアプリケーションサーバとの間でアタッチメントをもたらすステップと、
前記グループメンバと前記グループアプリケーションサーバとの間のデタッチメントを検出するステップと、
前記３ＧＰＰ通信ネットワークによって、前記グループメンバと前記グループアプリケーションサーバとの間で前記アタッチメントを再確立するステップと
を備えたことを特徴とする通信方法。
【請求項２】
モビリティ管理エンティティ（ＭＭＥ）が、前記グループメンバと前記グループアプリケーションサーバとの間で前記アタッチメントをもたらすステップをさらに備えたことを特徴とする請求項１に記載の通信方法。
【請求項３】
グループ通信サービスイネーブラアプリケーションサーバ（ＧＣＳＥ  ＡＳ）が、前記グループメンバと前記グループアプリケーションサーバとの間の前記デタッチメントを検出するステップをさらに備えたことを特徴とする請求項１に記載の通信方法。
【請求項４】
ＭＭＥが、前記グループメンバと前記グループアプリケーションサーバとの間の前記デタッチメントを検出するステップをさらに備えたことを特徴とする請求項１に記載の通信方法。
【請求項５】
マルチポイントサービス（ＭｕＳｅ）機能が、前記グループメンバと前記グループアプリケーションサーバとの間の前記デタッチメントを検出するステップをさらに備えたことを特徴とする請求項１に記載の通信方法。
【請求項６】
前記ＭｕＳｅ機能に従って、前記グループメンバと前記グループアプリケーションサーバとの間で前記アタッチメントを再確立するステップをさらに備えたことを特徴とする請求項５に記載の通信方法。
【請求項７】
前記グループメンバが、通知を受信し、および前記通知に応答して、前記グループメンバと前記グループアプリケーションサーバとの間で前記アタッチメントを再確立するステップをさらに備えたことを特徴とする請求項１に記載の通信方法。
【請求項８】
前記３ＧＰＰ通信ネットワークが、前記グループメンバの位置を決定し、および前記決定された位置に従って、前記グループメンバと前記グループアプリケーションサーバとの間で前記アタッチメントを再確立するステップをさらに備えたことを特徴とする請求項１に記載の通信方法。
【請求項９】
前記３ＧＰＰ通信ネットワークが、前記決定された位置を前記グループアプリケーションサーバに送信するステップと、
前記グループアプリケーションサーバが、前記送信された位置に従って、前記グループメンバと前記グループアプリケーションサーバとの間で前記アタッチメントを再確立するステップと
をさらに備えたことを特徴とする請求項８に記載の通信方法。
【請求項１０】
グループサービスエリア内に複数のグループメンバを含めることは、前記複数のグループメンバのうちの少なくとも２つのグループメンバが、異なるグループアプリケーションサーバにアタッチすることを備えることを特徴とする請求項１に記載の通信方法。
【請求項１１】
前記３ＧＰＰ通信ネットワークと前記グループアプリケーションサーバとの間でインターワーキング機能（ＩＷＦ）エンティティを設けるステップをさらに備えたことを特徴とする請求項１に記載の通信方法。
【請求項１２】
前記ＩＷＦエンティティが、前記グループアプリケーションサーバを位置付けるステップと、
前記位置付けに従って、前記３ＧＰＰ通信ネットワークからの通信を前記グループアプリケーションサーバに転送するステップと
をさらに備えたことを特徴とする請求項１１に記載の通信方法。
【請求項１３】
セルが３ＧＰＰ識別子を有することは、前記３ＧＰＰ識別子に従って、前記グループメンバと前記グループアプリケーションサーバとの間で前記アタッチメントを再確立することを備えることを特徴とする請求項１に記載の通信方法。
【請求項１４】
グループ通信ベアラにリソースを割り当てるための第１の優先度レベルを有する前記グループ通信ベアラを設けるステップと、
非グループ通信ベアラにリソースを割り当てるための第２の優先度レベルを有する前記非グループ通信ベアラを設けるステップと
をさらに備え、
前記第２の優先度レベルは、前記第１の優先度レベルとは異なる
ことを特徴とする請求項１に記載の通信方法。
【請求項１５】
前記第１の優先度レベルは、前記第２の優先度レベルよりも高いことを特徴とする請求項１４に記載の通信方法。
【請求項１６】
前記第１および第２の優先度レベルに従って、前記グループ通信ベアラおよび前記非グループ通信ベアラに異なる品質制御インデックス（ＱＣＩ）を提供するステップをさらに備えたことを特徴とする請求項１４に記載の通信方法。
【請求項１７】
ダウンリンクトラフィックにおいて、前記グループ通信ベアラおよび前記非グループ通信ベアラに異なるＱＣＩを提供するステップをさらに備えたことを特徴とする請求項１６に記載の通信方法。
【請求項１８】
ユニキャストトラフィックにおいて、前記グループ通信ベアラおよび前記非グループ通信ベアラに異なるＱＣＩを提供するステップをさらに備えたことを特徴とする請求項１６に記載の通信方法。
【請求項１９】
前記第１および第２の優先度レベルに従って、前記グループ通信ベアラおよび前記非グループ通信ベアラに異なるプリエンプション脆弱性をもたらすステップをさらに備えたことを特徴とする請求項１４に記載の通信方法。
【請求項２０】
前記第１および第２の優先度レベルに従って、前記グループ通信ベアラおよび前記非グループ通信ベアラに異なるプリエンプション能力をもたらすステップをさらに備えたことを特徴とする請求項１４に記載の通信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本出願は、無線通信に関する。
【背景技術】
【０００２】
３ＧＰＰ  Ｒｅｌｅａｓｅ  １２では、ＳＡおよびＲＡＮ標準化グループが、Ｌｏｎｇ−Ｔｅｒｍ  Ｅｖｏｌｕｔｉｏｎ用グループ通信サービスイネーブラ（ＧＣＳＥ＿ＬＴＥ）検討事項に取り組んでいる。例えば、非特許文献１を参照する。ＧＣＳＥ＿ＬＴＥは、アプリケーションレイヤ機能がＥｖｏｌｖｅｄ  Ｕｎｉｖｅｒｓａｌ  Ｔｅｒｒｅｓｔｒｉａｌ  Ｒａｄｉｏ  Ｎｅｔｗｏｒｋ（Ｅ−ＵＴＲＡＮ）上でグループ通信をもたらすことを可能にするための第３世代パートナーシッププロジェクト（３ＧＰＰ）の機能である場合がある。そのうえ、グループ通信サービスは、制御された方式で複数のユーザに同一のコンテンツを配信するための機構を提供してもよい。一例として、グループ通信の概念は、公安組織によって使用される伝統的な陸上移動無線（ＬＭＲ）システムの動作において拡張して使用されてもよい。ＬＭＲにおけるグループ通信サービスの主な用途は、プッシュツートーク（ＰＴＴ）機能を提供することである場合がある。したがって、ＬＴＥ無線技術を使用して、３ＧＰＰアーキテクチャに基づくグループ通信サービスは、同等の性能を有するＰＴＴ音声通信を有効にすることができる。
【０００３】
ユーザおよびユーザが動作する環境が発展中（in evolve）であるとき、グループ通信サービスによって、柔軟な動作のモードが可能になることがある。例えば、ＬＴＥによって、ブロードバンド通信が可能になることがある。したがって、グループ通信サービスは、音声、ビデオ、またはより一般的には、データ通信をサポートすることができる。また、ＬＴＥによって、ユーザが、いくつかのグループと同時に並行して、例えば、１つのグループに対して音声を、およびいくつかの他のグループに対してビデオまたはデータの異なるストリームを通信することが可能となることがある。グループ通信サービスのユーザは、グループに編成されてもよく、ユーザは、複数のグループのメンバであってもよい。
【０００４】
非特許文献２は、イネーブラを開発するための要件、すなわち、グループ通信サービスを設計するために使用することができるモジュール式機能およびオープンインタフェース（例えば、リソース効率の良い配信機構）を記載している。ハイレベル要件のうちのいくつかは、３ＧＰＰによって提供されるＧＣＳＥを使用する機能、グループメンバをベースに有効にされることになる機能、ユーザ機器（ＵＥ）にＧＣＳＥのネットワークサポートを示す機構を提供する機能、およびユーザにＧＣＳＥのネットワークサポートを示す機能を含んでもよい。他のハイレベル要件は、対話型通信（例えば、音声、ビデオ）、ストリーミング（例えば、ビデオ）、データ（例えば、メッセージ）、またはそれらの組み合わせなどのさまざまな媒体をサポートするＧＣＳＥを含んでもよい。非特許文献２に記載されたシステムは、ＧＣＳＥグループを一意に識別し、ＧＣＳＥグループ内のグループメンバを一意に識別する機能を有することがある。それは、すべての受信機グループメンバにグループ通信を送信するための機構を提供することができる。ＧＣＳＥグループの受信機グループメンバは、グループ通信を介してＧＣＳＥグループから通信を受信することが可能であってもよい。非特許文献２のシステムは、グループメンバに、送信機グループメンバになることを許可することが可能である場合がある。送信機グループメンバは、受信機グループメンバを有し、または有しないで、ＧＣＳＥグループのメンバであるＧＣＳＥグループに送信することが可能である場合がある。ＵＥ上のＧＣＳＥクライアントとネットワークとの間のインタフェースは、オープンインタフェースである場合があり、ネットワークは、グループ通信のための第三者インタフェースを提供する場合がある。このことは、インタフェースが課金および認証／許可などの特徴をサポートすることを暗に示す場合がある。システムはまた、３ＧＰＰネットワークを介して接続されていないグループメンバがグループ通信においてそのメンバであってもよいＧＣＳＥグループのために通信する機構を提供することができる。
【０００５】
ＧＣＳＥ＿ＬＴＥシステムにおけるグループ管理のための要件のうちのいくつかは、以下のものであってもよい。システムは、ＧＣＳＥグループの動的な作成、修正、および削除のための機構を提供することができる。ＧＣＳＥグループと関連付けられた情報は、ＧＣＳＥグループを識別し、どのようにグループを変更および使用することができるかを判定する属性を指定するために、システムによって使用される場合がある。情報は、例えば、どのグループメンバが管理機能に対して許可されてもよいかを示し、ＧＣＳＥグループが近接サービス（ＰｒｏＳｅ：Proximity Service）を介して中継可能かどうかを判定するために使用される場合がある。システムはまた、ＧＣＳＥグループの作成または削除の通知をそのグループメンバに提供することができる。許可される場合、ユーザは、それがグループメンバであってもよいすべてのＧＣＳＥグループのリストを要求および受信することが可能である場合が或る。許可される場合、ユーザは、ＧＣＳＥグループと関連付けられた情報を修正し、ＧＣＳＥグループのグループメンバを追加もしくは削除し、および／またはＧＣＳＥグループを作成／削除してもよいように、機構が設けられてもよい。許可される場合、ユーザはまた、特定のＧＣＳＥグループのグループメンバのリストを要求および受信することが可能である場合がある。許可される場合、ユーザは、特定のグループメンバまたは任意のグループメンバがいつ特定のＧＣＳＥグループに追加さまたは削除されてもよいかという通知を要求することができる。
【０００６】
そのうえ、システムは、ＧＣＳＥ関連情報でＵＥをリモートで構成するための機構を提供することができる。送信機グループメンバは、他のＧＣＳＥグループメンバの識別情報の知識なしで、ＧＣＳＥグループのためのグループ通信を送信することができる。グループメンバは、確立されたグループ通信に参加または離れることを要求することができる。システムは、適用可能なパラメータ、例えばサービス品質（ＱｏＳ）または優先度でマルチポイントサービス（ＭｕＳｅ）をセットアップ、解放、および修正する機構を提供することができる。システムはまた、グループの加入者情報によって指定されたポリシに基づいてグループ通信をセットアップまたは修正する要求において受信されたパラメータを確認することができ、例えば、それは、ＱｏＳまたは優先度をチェックすることができる。システムは、要求エンティティに、進行中のグループ通信のステータスのいずれかの更新を通知するための手段を提供することができる。グループメンバは、ＧＣＳＥグループがグループ通信に使用されるとき、グループ通信を受信することに対する関心を表すことが可能である場合がある。システムは、グループ通信を受け付け、拒否、または無視することを可能にするために、グループ通信を受信する、受信機グループメンバための機構を提供することができる。システムはまた、グループ通信を受け付けるよう要求されるグループ通信を受信する、受信機グループメンバのための機構を提供することができる。
【０００７】
ＧＣＳＥのためのハイレベルアーキテクチャ
【０００８】
ここで図２を参照すると、ＧＣＳＥグループ通信アーキテクチャ２００のハイレベル図が示されている。ＧＣＳＥグループ通信アーキテクチャ２００などのアーキテクチャについては、例えば、非特許文献１で議論されることがある。
【０００９】
グループ通信アーキテクチャ２００は、アプリケーションレイヤと、３ＧＰＰ  Ｅｖｏｌｖｅｄ  Ｐａｃｋｅｔ  Ｓｙｓｔｅｍ（ＥＰＳ）レイヤとを含むことがある。アプリケーションレイヤは、ＧＣＳＥアプリケーションサーバ（ＧＣＳＥ  ＡＳ）２１４を含むことがある。３ＧＰＰ  ＥＰＳレイヤは、ＭｕＳｅ機能２１０を含むことがある。ＭｕＳｅ機能２１０は、ＭｕＳｅ機能を提供する３ＧＰＰ  ＥＰＳエンティティ（例えば、非特許文献３で議論されることがある）とインタフェースすることができる。３ＧＰＰ  ＥＰＳレイヤはまた、ＭＭＥ２０６と、ＰＧＷ２０８と、ＣＧＳＥアプリケーションサーバ２１４と、ｅＮＢと、ＳＧＷと、ＵＥ２０４とを含むことができる。
【００１０】
グループ通信アーキテクチャ２００内の基準ポイントＧＣ１、ＧＣ２、ＧＣ３、ＧＣ４、およびＧＣ５は、以下のように説明されることがある。ＧＣ１は、ＵＥ２０４内で実行されているＧＣＳＥアプリケーションとＧＣＳＥ  ＡＳ２１４内で実行されているＧＣＳＥアプリケーションとの間の基準ポイントとすることができる。それは、ＧＣＳＥ＿ＬＴＥに対するマルチポイント機能を有効にするアプリケーションレベルシグナリング要件を説明するために使用されることがある。ＧＣ１はまた、セッション確立、フロア制御使用などを有効にすることができる。ＧＣ２は、ＧＣＳＥ  ＡＳ２１４とマルチポイントサービス（ＭｕＳｅ）機能２１０との間の基準ポイントとすることができる。それは、ＧＣＳＥ  ＡＳ２１４とＭｕＳｅ機能２１０との間の相互作用を説明するために使用されることがあり、ＭｕＳｅ機能２１０は３ＧＰＰ  ＥＰＳレイヤによってもたらされることがある。ＧＣ３は、Ｅ−ＵＴＲＡＮ（ｅＮＢ）とＭｕＳｅ機能２１０との間の基準ポイントとすることができる。それも、３ＧＰＰ  ＥＰＳレイヤによってもたらされることがあるマルチポイント機能を達成するために、Ｅ−ＵＴＲＡＮとＭｕＳｅ機能２１０との間の相互作用を説明するために使用されることがある。ＧＣ４は、モビリティ管理エンティティ（ＭＭＥ）２０６とＭｕＳｅ機能２１０との間の基準ポイントとすることができる。それは、３ＧＰＰ  ＥＰＳレイヤによってもたらされることがあるマルチポイント機能を達成するために、ＭＭＥ２０６とＭｕＳｅ機能２１０との間の相互作用を説明するために使用されることがある。ＧＣ５は、パケットゲートウェイ（ＰＧＷ）２０８とＭｕＳｅ機能２１０との間の基準ポイントとすることができる。それは、ＭｕＳｅ機能２１０によってＤＬユニキャストサービスをもたらすために使用されることがある。
【００１１】
３ＧＰＰ  ＬＴＥ  Ｒｅｌｅａｓｅ  ８および／または９（ＬＴＥ  Ｒｅｌ−８／９）は、２×２構成に対し、ダウンリンク（ＤＬ）において最高１００Ｍｂｐｓ、アップリンク（ＵＬ）において５０Ｍｂｐｓをサポートすることができる。ＬＴＥ  ＤＬ送信方式は、直交周波数分割多元接続（ＯＦＤＭＡ）エアインタフェースに基づくことがある。
【００１２】
ＬＴＥ  Ｒｅｌ−８／９および／またはＲｅｌｅａｓｅ  １０（総称して「ＬＴＥ  Ｒｅｌ−８／９／１０」）システムは、スケーラブルな送信帯域幅をサポートする（例えば、柔軟な展開などのために）。そのようなスケーラブルな送信帯域幅は、例えば、１．４、２．５、５、１０、１５、および２０メガヘルツ（ＭＨｚ）の帯域幅を含むことができる。
【００１３】
ＬＴＥ  Ｒｅｌ−８／９では（およびＬＴＥ  Ｒｅｌ−１０に適用可能なとき）、各無線フレームは、１０ミリ秒（ｍｓ）の持続時間を有し、１０サブフレームから構成されることがある、サブフレームの各々は１ｍｓである場合がある。各サブフレームは、各々０．５ｍｓの２つのタイムスロットから構成されることがある。タイムスロットごとに７つまたは６つの直交周波数多重（ＯＦＤＭ）シンボルが存在することがある。タイムスロットごとの７つのシンボルは、通常の巡回プレフィックス長とともに使用されることがあり、タイムスロットごとの６つのシンボルは、拡張された巡回プレフィックス長とともに使用されることがある。ＬＴＥ  Ｒｅｌ−８／９システムのサブキャリア間隔は、１５ｋＨｚである場合がある。７．５ｋＨｚを使用する減少されたサブキャリア間隔モードも可能である場合がある。
【００１４】
リソース要素（ＲＥ）は、１つのＯＦＤＭシンボルインターバルの間の１つのサブキャリアに対応することがある。０．５ｍｓタイムスロットの間の１２個の連続したサブキャリアは、１つのリソースブロック（ＲＢ）を構成することがある。したがって、タイムスロットごとの７つのシンボルでは、各ＲＢは、８４のＲＥから構成されることがある。ＤＬキャリアは、ほぼ１ＭＨｚから２０ＭＨｚの全体的なスケーラブルな送信帯域幅に対応する６つのＲＢから最高１１０のＲＢにわたることができる。各送信帯域幅、例えば、１．４、３、５、１０、または２０ＭＨｚは、いくつかのＲＢに対応することがある。
【００１５】
動的スケジューリングのための基本時間領域単位は、１サブフレームである場合があり、サブフレームは、２つの連続したタイムスロットから構成されることがある。これは、ＲＢペアと称されることがある。いくつかのＯＦＤＭシンボルのあるサブキャリアは、時間周波数グリッド内のパイロット信号を搬送するために割り当てられることがある。送信帯域幅の境界にあるいくつかのサブキャリアは、スペクトルマスク要件に適合するために送信されないことがある。
【００１６】
ＬＴＥ  Ｒｅｌ−８／９、およびＲｅｌ−１０では、ＵＬにおいてアクティブな単一のハイブリッド自動再送要求（ＨＡＲＱ）プロセスと、ＤＬにおいてアクティブな単一のＨＡＲＱプロセスが存在することがある。これは、ネットワークがサブフレームに対してＵＬキャリアおよびＤＬキャリアの１つのペア（周波数分割複信（ＦＤＤ））、またはＵＬおよびＤＬのための１つのタイムシェアリングされたキャリア（ＴＤＤ）のみをＵＥに割り当てることができる、シングルキャリア構成において発生することがある。
【００１７】
ＬＴＥキャリアアグリゲーション（ＣＡ）
【００１８】
ＣＡでのＬＴＥ−Ａｄｖａｎｃｅｄ（ＬＴＥ  ＣＡ  Ｒｅｌ−１０）は、解決策の中でも帯域幅拡張を使用するシングルキャリアＬＴＥデータレートを改善するための発展版である。ＣＡで、ＵＥは、複数のサービングセルの物理アップリンク共有チャネル（ＰＵＳＣＨ）および物理ダウンリンク共有チャネル（ＰＤＳＣＨ）（それぞれ）上で同時に送信および受信することができる。例えば、プライマリサービングセル（ＰＣｅｌｌ）に加えて最高４つのセカンダリサービングセル（ＳＣｅｌｌ）が使用されることがあり、したがって、最高１００ＭＨｚの柔軟な帯域幅割り当てをサポートする。ＨＡＲＱ確認応答および／もしくは否定応答（ＡＣＫ／ＮＡＣＫ）フィードバックを含むことがあるアップリンク制御情報（ＵＣＩ）、ならびに／またはチャネル状態情報（ＣＳＩ）は、ＰＣｅｌｌの物理ＵＬ制御チャネル（ＰＵＣＣＨ）リソース上、またはＵＬ送信のために構成されたサービングセルが利用可能なＰＵＳＣＨリソース上のいずれかで送信されることがある。
【００１９】
ＰＤＳＣＨおよびＰＵＳＣＨのスケジューリングのための制御情報は、１つまたは複数の物理ダウンリンク制御チャネル（ＰＤＣＣＨ）上で送信されることがある。ＵＬキャリアおよびＤＬキャリアのペアに対して１つのＰＤＣＣＨを使用するＬＴＥ  Ｒｅｌ−８／９スケジューリングに加えて、クロスキャリアスケジューリングもＰＤＣＣＨによってサポートされることがある。これによって、ネットワークが、ＰＤＳＣＨ割り当ておよび／または１もしくは複数の他のサービングセルにおける送信のためのＰＵＳＣＨ許可をもたらすことが可能となる場合がある。
【００２０】
ＣＡで動作するＦＤＤ  ＬＴＥ  Ｒｅｌ−１０  ＵＥに対し、各サービングセルに対して１つのＨＡＲＱエンティティが存在することがある。各ＨＡＲＱエンティティは、最高８つのＨＡＲＱプロセス、例えば、１つのラウンドトリップタイム（ＲＴＴ）に対してサブフレームごとに１つを有することができる。さらに、ＣＡで動作するＦＤＤ  ＬＴＥ  Ｒｅｌ−１０  ＵＥに対し、サブフレーム内のＵＬに対しておよびＤＬに対してアクティブな複数のＨＡＲＱプロセスが存在することがあるが、構成されたサービングセルごとに１つのＵＬ  ＨＡＲＱプロセスおよび１つのＤＬ  ＨＡＲＱプロセスのみが存在することがある。
【先行技術文献】
【非特許文献】
【００２１】
【非特許文献１】３ＧＰＰ  ＴＲ２３．７６８
【非特許文献２】３ＧＰＰ  ＴＲ  ２２．４８６
【非特許文献３】ＴＳ  ２３．４０１
【非特許文献４】ＴＳ  ２２．２４６  ＭＢＭＳ；  ａｒｃｈｉｔｅｃｔｕｒｅ  ａｎｄ  ｆｕｎｃｔｉｏｎａｌ  ｄｅｓｃｒｉｐｔｉｏｎ
【非特許文献５】３ＧＰＰ  ＴＳ  ３３．２４６
【非特許文献６】３ＧＰＰ  ＴＳ  ２２．４６８
【非特許文献７】３ＧＰＰ  ＴＳ  ３６．４４０
【発明の概要】
【００２２】
第３世代パートナーシッププロジェクト（３ＧＰＰ）通信ネットワーク上で実装される通信方法は、通信グループのグループメンバとグループアプリケーションサーバとの間でアタッチメントをもたらすことと、グループメンバとグループアプリケーションサーバとの間のデタッチメントを検出することと、３ＧＰＰ通信ネットワークによってグループメンバとグループアプリケーションサーバとの間のアタッチメントを再確立することと、を含む。モビリティ管理エンティティ（ＭＭＥ）は、グループメンバとグループアプリケーションサーバとの間でアタッチメントをもたらしてもよい。グループ通信サービスイネーブラアプリケーションサーバ（ＧＣＳＥ  ＡＳ）は、グループメンバとグループアプリケーションサーバとの間でデタッチメントを検出してもよい。ＭＭＥは、グループメンバとグループアプリケーションサーバとの間のデタッチメントを検出してもよい。マルチポイントサービス（ＭｕＳｅ）機能は、グループメンバとグループアプリケーションサーバとの間のデタッチメントを検出してもよい。グループメンバとグループアプリケーションサーバとの間のアタッチメントは、ＭｕＳｅ機能に従って再確立されてもよい。グループメンバは、通知を受信し、この通知に応答してグループメンバとグループアプリケーションサーバとの間のアタッチメントを再確立してもよい。
【００２３】
３ＧＰＰ通信ネットワークは、グループメンバの位置を判定し、判定された位置に従ってグループメンバとグループアプリケーションサーバとの間のアタッチメントを再確立してもよい。３ＧＰＰ通信ネットワークは、判定された位置をグループアプリケーションサーバに送信してもよく、グループアプリケーションサーバは、送信された位置に従ってグループメンバとグループアプリケーションサーバとの間のアタッチメントを再確立してもよい。複数のグループメンバがグループサービスエリア内で位置付け（located）されてもよく、複数のグループメンバのうちの少なくとも２人のグループメンバが異なるグループアプリケーションサーバにアタッチしてもよい。
【００２４】
インターワーキング機能（ＩＷＦ）エンティティが、３ＧＰＰネットワークとグループアプリケーションサーバとの間で設けられてもよい。ＩＷＦエンティティは、グループアプリケーションサーバを位置付けてもよく、位置付けに従って３ＧＰＰ通信ネットワークからグループアプリケーションサーバに通信を転送してもよい。セルは、３ＧＰＰ識別子を有してもよく、グループメンバとグループアプリケーションサーバとの間のアタッチメントは、この３ＧＰＰ識別子により再確立されてもよい。
【００２５】
グループ通信ベアラは、グループ通信ベアラにリソースを割り当てるための第１の優先度レベルを有してもよい。非グループ通信ベアラは、非グループ通信ベアラにリソースを割り当てるための第２の優先度レベルを有してもよい。第２の優先度レベルは、第１の優先度レベルと異なってもよい。第１の優先度レベルは、第２の優先度レベルよりも高くてもよい。第１の優先度レベルおよび第２の優先度レベルに従って、異なる品質制御インデックス（ＱＣＩ）がグループ通信ベアラおよび非グループ通信ベアラに提供されてもよい。異なるＱＣＩが、ダウンリンクトラフィックにおいてグループ通信ベアラおよび非グループ通信ベアラに提供されてもよい。異なるＱＣＩが、ユニキャストトラフィックにおいてグループ通信ベアラおよび非グループ通信ベアラに提供されてもよい。第１の優先度レベルおよび第２の優先度レベルに従って、異なるプリエンプション脆弱性（pre-emption vulnerability）がグループ通信ベアラおよび非グループ通信ベアラにもたらされてもよい。第１の優先度レベルおよび第２の優先度レベルに従って、異なるプリエンプション機能がグループ通信ベアラおよび非グループ通信ベアラにもたらされてもよい。
【００２６】
通信方法は、通信グループのグループメンバとグループ通信システムとの間のアタッチメントをもたらすことと、グループメンバとグループ通信システムとの間のデタッチメントを検出することと、３ＧＰＰシステムに従ってグループメンバとグループ通信システムとの間のアタッチメントを再確立することと、を含む。方法はまた、グループ利用可能性のインジケーションをグループ通信システムによってグループメンバに提供してもよく、３ＧＰＰシステムは、グループメンバの位置を判定し、その判定された位置に従ってアタッチメントを再確立する。３ＧＰＰシステムによって判定された位置をグループ通信システムに送信すること、およびこの送信された位置に従ってグループ通信システムがアタッチメントを再確立することも、備えられてもよい。ブロードキャスト領域は、判定された位置に従って最適化されてもよく、ＥＰＳノードは、判定された位置に従ってアクティブ化されてもよい。加入されたグループサービスエリア内にグループメンバがいるかどうかの判定は、判定された位置に従ってなされてもよい。グループメンバは、グループサービスエリア内で位置決めされてもよい。グループサービスエリア内で複数のグループメンバが位置付けされてもよく、複数のグループメンバのうちの少なくとも２人のグループメンバが、異なるグループ通信システムにアタッチされてもよい。
【００２７】
ＧＣＳＥサービスエリアは、識別子に関連付けられてもよく、この識別子はグローバル一意識別子（ＧＵＩＤ）であってもよい。そのような識別子は、ＧＣＳＥサービスエリア内のセルによってブロードキャストされてもよい。ＧＣＳＥサービスエリア識別子はまた、専用無線リソース制御（ＲＲＣ）メッセージ内で、非アクセスストレイタム（ＮＡＳ）メッセージ内で、ＧＣＳＥ  ＡＳ固有メッセージ内で、または限定するものではないが、Ａｃｃｅｓｓ  Ｎｅｔｗｏｒｋ  Ｄｉｓｃｏｖｅｒｙ  ａｎｄ  Ｓｅｌｅｃｔｉｏｎ  Ｆｕｎｃｔｉｏｎ（ＡＮＤＳＦ）、Ｏｐｅｎ  Ｍｏｂｉｌｅ  Ａｌｌｉａｎｃｅ（ＯＭＡ）復調（ＤＭ）、ＳＭＳなどの他の任意の上位レイヤ方法を使用して、ＵＥ間で、またはＵＥとネットワークエンティティとの間で交換されてもよい。
【００２８】
ＵＥ内のアプリケーションレイヤが、レイヤ２グループＩＤもしくはアプリケーションレイヤグループＩＤのマッピングを実行する能力を有さない場合、またはマッピング情報を有さない場合、それは、グループアプリケーションサーバＭＭＥまたはＰｒｏＳｅに連絡（contact）してもよい。さらに、それは、レイヤ２グループＩＤを送信してもよい。グループアプリケーションサーバ、ＭＭＥ、またはＰｒｏＳｅサーバは、グループＩＤの変換で応答してもよい。
【００２９】
３ＧＰＰネットワークとグループ通信サーバとの間のインターワーキング機能（ＩＷＦ）エンティティと称される論理ノードが設けられてもよい。グループアプリケーションサーバは、グループメンバに到達することが不可能である場合がある。この場合、グループアプリケーションサーバは、インビテーション（invitation）または通知をユーザに転送する際に３ＧＰＰネットワークを関与させてよい。ユーザは、次いで、グループに登録／参加することを開始してもよい。
【００３０】
ＵＥ位置報告は、マルチメディアブロードキャスト／マルチキャストサービス（ＭＢＭＳ）ブロードキャスト領域を最適化し、ダウンストリームＥＰＳ制御ノードをアクティブ化／非アクティブ化し、および／または加入されたＧＣＳＥサービスエリア内にユーザがいるかどうか判定するために、ネットワークによって使用されてもよい。ＮＡＳプロシージャは、グループ管理を扱うために設けられてもよい。ＮＡＳメッセージは、ＰｒｏＳｅ要求と称されてもよく、ＰｒｏＳｅ要求は、アイドルモードまたは接続モードから開始されてもよく、すなわち、メッセージは、第１のＵＥ  ＮＡＳメッセージとして送信されてもよい。
【００３１】
グループを作成する要求が送信される場合、ＭＭＥは、新しく形成されたグループを含むようにＵＥのコンテキストを更新してもよい。さらに、ＭＭＥは、ＵＥがグループ所有者であるというインジケーションを維持してもよい（これが許可され、または当てはまる場合）。ＧＣＳＥグループ内のユーザの品質制御インデックス（ＱＣＩ）、優先度レベル、プリエンプション能力、およびプリエンプション脆弱性は、ＵＬユニキャストトラフィックベアラごとに割り当てられてもよい。
【図面の簡単な説明】
【００３２】
より詳細な理解は、本明細書に添付される図面とともに例として与えられる以下の詳細な説明からなされてもよい。そのような図面中の図は、詳細な説明のように、例示的である。したがって、図および詳細な説明は、限定するものとして考えられるべきではなく、他の同等に有効な例が可能である。そのうえ、図中の同一の参照番号は同一の要素を示す。
【図１Ａ】１つまたは複数の開示される実施形態が実装することができる例示的な通信システムの図である。
【図１Ｂ】図１Ａに示される通信システム内で使用することができる例示的な無線送信／受信ユニット（ＷＴＲＵ）のシステム図である。
【図１Ｃ】図１Ａに示される通信システム内で使用することができる例示的な無線アクセスネットワークおよび例示的なコアネットワークのシステム図である。
【図１Ｄ】図１Ａに示される通信システム内で使用することができる別の例示的な無線アクセスネットワークおよび例示的なコアネットワークのシステム図である。
【図１Ｅ】図１Ａに示される通信システム内で使用することができる別の例示的な無線アクセスネットワークおよび例示的なコアネットワークのシステム図である。
【図２】例示的なＧＣＳＥ＿ＬＴＥアーキテクチャのシステム図である。
【図３】例示的なグループメンバ登録プロシージャの図である。
【図４】新たなサービスエリアに入るための例示的な通知プロシージャの図である。
【図５】グループ管理のためのＩＷＦエンティティを有するアーキテクチャのシステム図である。
【図６】３ＧＰＰ識別子を用いた例示的なグループ登録プロシージャの図である。
【図７】グループ情報を登録するための例示的なトラッキングエリア更新（ＴＡＵ）プロシージャの図である。
【図８】ユーザステータスを更新するためのＩＷＦエンティティによるグループサーバとの例示的なＭＭＥ通信の図である。
【図９】ＩＷＦエンティティおよび３ＧＰＰネットワークを介してＵＥに送信される例示的なグループインビテーションの図である。
【発明を実施するための形態】
【００３３】
以下の詳細な説明では、本明細書で開示される実施形態および／または例の完全な理解を提供するために多数の具体的な詳細が示される。しかしながら、そのような実施形態および例は、本明細書に記載された具体的な詳細のうちのいくつかまたはすべてなしに実装されてもよいことが理解されよう。他の例では、よく公知の方法、プロシージャ、構成要素、および回路は、以下の説明を曖昧にしないように、詳細に説明されていない。さらに、本明細書に具体的に説明されていない実施形態および例は、開示された本明細書に開示された実施形態および他の例の代わりに、またはこれと組み合わせて、実装されてもよい。
【００３４】
例示的なアーキテクチャ
【００３５】
本明細書で参照されるとき、「ユーザ機器」という用語およびその略語「ＵＥ」は、（ｉ）以下で説明されるものなどのＷＴＲＵ、（ｉｉ）以下で説明されるものなどの、ＷＴＲＵのいくつかの実施形態のいずれか、（ｉｉｉ）以下で説明されるものなどのとりわけＷＴＲＵのいくつかもしくはすべての構造および機能に満たないで構成された無線対応デバイスおよび／もしくは有線対応（例えば、テザリング可能な）デバイス、（ｉｉｉ）以下で説明されるものなどの、ＷＴＲＵのすべての構造および機能に満たない（less than all structures and functionality）ように構成された、無線対応デバイスおよび／もしくは有線対応デバイス、または（ｉｖ）これらのようなものを意味してもよい。本明細書に記載されるいかなるＵＥも表すことができる例示的なＷＴＲＵの詳細は、図１Ａ〜図１Ｃに関して以下に提供される。
【００３６】
本明細書で参照されるとき、「発展型ＮｏｄｅＢ」という用語ならびにその略語「ｅＮＢ」および「ｅＮｏｄｅ−Ｂ」は、（ｉ）以下で説明されるものなどの基地局、（ｉｉ）以下で説明されるものなどの、基地局のいくつかの実施形態のいずれか、（ｉｉｉ）以下で説明されるものなどの、とりわけ基地局またはｅＮＢのいくつかもしくはすべての構造および機能を有するように構成されたデバイス、（ｉｉｉ）以下で説明されるものなどの、基地局もしくはｅＮＢのすべての構造および機能に満たないように構成されたデバイス、または（ｉｖ）これらのようなものを意味してもよい。本明細書に記載されるいかなるｅＮＢも表してもよい例示的なｅＮＢの詳細は、図１Ａ〜図１Ｃに関して以下に提供される。
【００３７】
本明細書で参照されるとき、「モビリティ管理エンティティ」という用語およびその略語「ＭＭＥ」は、（ｉ）以下で説明されるものなどのＭＭＥ、（ｉｉ）３ＧＰＰ  ＬＴＥ  ｒｅｌｅａｓｅによるＭＭＥ、（ｉｉｉ）以下の説明により修正された、拡張および／もしくは強化された、３ＧＰＰ  ＬＴＥ  ｒｅｌｅａｓｅによるＭＭＥ、（ｉｉｉ）とりわけ前述のＭＭＥのいずれかのいくつかもしくはすべての構造および機能を有するように構成されたデバイス、（ｉｖ）上記の（ｉ）および（ｉｉ）のＭＭＥのいずれかのすべての構造および機能に満たないように構成されたデバイス、または（ｉｖ）これらのようなものを意味してもよい。本明細書に記載されるいかなるＭＭＥも表してもよい例示的なＭＭＥの詳細は、図１Ａ〜図１Ｃに関して以下に提供される。
【００３８】
図１Ａは、１つまたは複数の開示される実施形態が実施されてもよい例示的な通信システム１１００の図である。通信システム１００は、音声、データ、ビデオ、メッセージ、ブロードキャストなどのコンテンツを複数の無線ユーザに提供する多元接続システムであってもよい。通信システム１００は、複数の無線ユーザが、無線帯域幅を含むシステムリソースの共有によって、そのようなコンテンツにアクセスすることを可能にしてもよい。例えば、通信システム１００は、符号分割多元接続（ＣＤＭＡ）、時分割多元接続（ＴＤＭＡ）、周波数分割多元接続（ＦＤＭＡ）、ＯＦＤＭＡ、シングルキャリアＦＤＭＡ（ＳＣ−ＦＤＭＡ）などの１つまたは複数のチャネルアクセススキームを使用してもよい。
【００３９】
図１Ａに示されるように、通信システム１００は、無線送信／受信ユニット（ＷＴＲＵ）１０２ａ、１０２ｂ、１０２ｃ、１０２ｄと、無線アクセスネットワーク（ＲＡＮ）１０４と、コアネットワーク１０６と、公衆交換電話網（ＰＳＴＮ）１０８と、インターネット１１０と、他のネットワーク１１２とを含んでもよいが、開示される実施形態は、任意の数のＷＴＲＵ、基地局、ネットワーク、および／またはネットワーク要素を意図することが理解されるであろう。ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄの各々は、無線環境内で動作および／または通信するように構成された任意のタイプのデバイスであってもよい。例として、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、無線信号を送信および／または受信するように構成されてもよく、ＵＥ、移動局、固定またはモバイルの加入者ユニット、ページャ、セルラー式電話、携帯情報端末（ＰＤＡ）、スマートフォン、ラップトップ、ネットブック、パーソナルコンピュータ、タブレットコンピュータ、無線センサ、家電などを含んでもよい。
【００４０】
通信システム１００は、基地局１１４ａと、基地局１１４ｂも含んでもよい。基地局１１４ａ、１１４ｂの各々は、コアネットワーク１０６、インターネット１１０、および／またはネットワーク１１２などの１つまたは複数の通信ネットワークへのアクセスを容易にするためにＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのうちの少なくとも１つと無線でインタフェースするように構成された任意のタイプのデバイスであってもよい。例として、基地局１１４ａ、１１４ｂは、送受信基地局（ＢＴＳ）、ＮｏｄｅＢ、ｅＮｏｄｅ  Ｂ、ホームＮｏｄｅＢ、ホームｅＮｏｄｅ  Ｂ、サイトコントローラ、アクセスポイント（ＡＰ）、無線ルータなどであってもよい。基地局１１４ａ、１１４ｂは各々、単一の要素として示されているが、基地局１１４ａ、１１４ｂは、任意の数の相互接続された基地局および／またはネットワーク要素を含んでもよいことが理解されるであろう。
【００４１】
基地局１１４ａはＲＡＮ１０４の一部であってもよく、ＲＡＮ１０４は、基地局コントローラ（ＢＳＣ）、無線ネットワークコントローラ（ＲＮＣ）、中継ノードなどの他の基地局および／またはネットワーク要素（図示せず）も含んでもよい。基地局１１４ａおよび／または基地局１１４ｂは、特定の地理的領域内で無線信号を送信および／または受信するように構成されてもよく、この特定の地理的領域は、セル（図示せず）と称されてもよい。セルは、セルセクタにさらに分割されてもよい。例えば、基地局１１４ａに関連付けられたセルは、３つのセクタに分割されてもよい。したがって、一実施形態では、基地局１１４ａは、３つの総う新規、すなわちセルの各セクタに対して１つを含んでもよい。別の実施形態では、基地局１１４ａは、多入力多出力（ＭＩＭＯ）技術を使用してもよく、したがって、セルの各セクタに対して複数の送受信機を利用してもよい。
【００４２】
基地局１１４ａ、１１４ｂは、エアインタフェース１１６上でＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのうちの１つまたは複数と通信してもよく、エアインタフェース１１６は、任意の適切な無線通信リンク（例えば、無線周波数（ＲＦ）、マイクロ波、赤外線（ＩＲ）、紫外線（ＵＶ）、可視光など）であってもよい。エアインタフェース１１６は、任意の適切な無線アクセス技術（ＲＡＴ）を使用して確立されてもよい。
【００４３】
より具体的には、本明細書に示されるように、通信システム１００は、多元接続システムであってもよく、ＣＤＭＡ、ＴＤＭＡ、ＦＤＭＡ、ＯＦＤＭＡ、ＳＣ−ＦＤＭＡなどの１つまたは複数のチャネルアクセススキームを使用してもよい。例えば、ＲＡＮ１０４内の基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ユニバーサル移動体通信システム（ＵＭＴＳ）地上無線アクセス（ＵＴＲＡ）などの無線技術を実施してもよく、無線技術は、広帯域ＣＤＭＡ（ＷＣＤＭＡ）を使用してエアインタフェース１１６を確立してもよい。ＷＣＤＭＡは、高速パケットアクセス（ＨＳＰＡ）および／または発展型ＨＳＰＡ（ＨＳＰＡ＋）などの通信プロトコルを含んでもよい。ＨＳＰＡは、高速ダウンリンクパケットアクセス（ＨＳＤＰＡ）および／または高速アップリンクパケットアクセス（ＨＳＵＰＡ）を含んでもよい。
【００４４】
別の実施形態では、基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、発展型ＵＭＴＳ地上無線アクセス（Ｅ−ＵＴＲＡ）などの無線技術を実施してもよく、無線技術は、ＬＴＥおよび／またはＬＴＥ−Ａｄｖａｎｃｅｄ（ＬＴＥ−Ａ）を使用してエアインタフェース１１６を確立してもよい。
【００４５】
他の実施形態では、基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ＩＥＥＥ８０２．１６（すなわち、Ｗｏｒｌｄｗｉｄｅ  Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ  ｆｏｒ  Ｍｉｃｒｏｗａｖｅ  Ａｃｃｅｓｓ（ＷｉＭＡＸ））、ＣＤＭＡ２０００、ＣＤＭＡ２０００１  Ｘ、ＣＤＭＡ２０００  ＥＶ−ＤＯ、Ｉｎｔｅｒｉｍ  Ｓｔａｎｄａｒｄ２０００（ＩＳ−２０００）、Ｉｎｔｅｒｉｍ  Ｓｔａｎｄａｒｄ  ９５（ＩＳ−９５）、Ｉｎｔｅｒｉｍ  Ｓｔａｎｄａｒｄ  ８５６（ＩＳ−８５６）、Ｇｌｏｂａｌ  Ｓｙｓｔｅｍ  ｆｏｒ  Ｍｏｂｉｌｅ  ｃｏｍｍｕｎｉｃａｔｉｏｎｓ（ＧＳＭ）、Ｅｎｈａｎｃｅｄ  Ｄａｔａ  ｒａｔｅｓ  ｆｏｒ  ＧＳＭ  Ｅｖｏｌｕｔｉｏｎ（ＥＤＧＥ）、ＧＳＭ  ＥＤＧＥ（ＧＥＲＡＮ）などの無線技術を実施してもよい。
【００４６】
図１Ａ中の基地局１１４ｂは、例えば、無線ルータ、ホームＮｏｄｅＢ、ホームｅＮｏｄｅ  Ｂ、またはアクセスポイントであってもよく、事業所、家庭、車両、キャンパスなどの局所化されたエリア内の無線接続性を容易にするために、任意の適切なＲＡＴを利用してもよい。一実施形態では、基地局１１４ｂおよびＷＴＲＵ１０２ｃ、１０２ｄは、ＩＥＥＥ８０２．１１などの無線技術を実施して、無線ローカルエリアネットワーク（ＷＬＡＮ）を確立してもよい。別の実施形態では、基地局１１４ｂおよびＷＴＲＵ１０２ｃ、１０２ｄは、ＩＥＥＥ８０２．１５などの無線技術を実施して、無線パーソナルエリアネットワーク（ＷＬＡＮ）を確立してもよい。さらに別の実施形態では、基地局１１４ｂおよびＷＴＲＵ１０２ｃ、１０２ｄは、セルラーベースのＲＡＴ（例えば、ＷＣＤＭＡ、ＣＤＭＡ２０００、ＧＳＭ、ＬＴＥ、ＬＴＥ−Ａなど）を利用して、ピコセルまたはフェムトセルを確立してもよい。図１Ａに示されるように、基地局１１４ｂは、インターネット１１０への直接接続を有してもよい。したがって、基地局１１４ｂは、コアネットワーク１０６を介してインターネット１１０にアクセスするよう要求されなくてもよい。
【００４７】
ＲＡＮ１０４はコアネットワーク１０６と通信してもよく、コアネットワーク１０６は、音声、データ、アプリケーション、および／またはｖｏｉｃｅ  ｏｖｅｒ  ｉｎｔｅｒｎｅｔ  ｐｒｏｔｏｃｏｌ（ＶｏＩＰ）サービスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのうちの１つまたは複数に提供するように構成された任意のタイプのネットワークであってもよい。例えば、コアネットワーク１０６は、呼制御、課金サービス、モバイルロケーションベースサービス、プリペイドコーリング、インターネット接続性、ビデオ配信などを提供し、および／またはユーザ認証などのハイレベルセキュリティ機能を実行してもよい。図１Ａに示されていないが、ＲＡＮ１０４および／またはコアネットワーク１０６は、ＲＡＮ１０４と同一のＲＡＴまたは異なるＲＡＴを使用する他のＲＡＮと直接または間接的に通信してもよいことが理解されるであろう。例えば、Ｅ−ＵＴＲＡ無線技術を利用することができるＲＡＮ１０４に接続されることに加えて、コアネットワーク１０６は、ＧＳＭ無線技術を使用して別のＲＡＮ（図示せず）とも通信してもよい。
【００４８】
コアネットワーク１０６は、ＰＳＴＮ１０８、インターネット１１０、および／または他のネットワーク１１２にアクセスするようにＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのためのゲートウェイとして機能してもよい。ＰＳＴＮ１０８は、簡易電話サービス（ＰＯＴＳ）を提供する回線交換電話網を含んでもよい。インターネット１１０は、ＴＣＰ／ＩＰインターネットプロトコルスイートにおける伝送制御プロトコル（ＴＣＰ）、ユーザデータグラムプロトコル（ＵＤＰ）、およびインターネットプロトコル（ＩＰ）などの一般的な通信プロトコルを使用する、相互接続されたコンピュータネットワークおよびデバイスのグローバルシステムを含んでもよい。ネットワーク１１２は、他のサービスプロバイダによって所有および／または動作される有線通信ネットワークまたは無線通信ネットワークを含んでもよい。例えば、ネットワーク１１２は、１つまたは複数のＲＡＮに接続された別のコアネットワークを含んでもよく、ＲＡＮは、ＲＡＮ１０４と同一のＲＡＴまたは異なるＲＡＴを使用してもよい。
【００４９】
通信システム１００内のＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのうちのいくつかまたはすべては、マルチモード能力を含んでもよく、すなわち、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、異なる無線リンク上で異なる無線ネットワークと通信するための複数の送受信機を含んでもよい。例えば、図１Ａに示されるＷＴＲＵ１０２ｃは、セルラーベースの無線技術を使用することができる基地局１１４ａと、ＩＥＥＥ８０２無線技術を使用することができる基地局１１４ｂと通信するように構成されてもよい。
【００５０】
図１Ｂは、例示的なＷＴＲＵ１０２のシステム図である。図１Ｂに示されるように、ＷＴＲＵ１０２は、プロセッサ１１８と、送受信機１２０と、送信／受信要素１２２と、スピーカ／マイクロホン１２４と、キーパッド１２６と、ディスプレイ／タッチパッド１２８と、着脱不能メモリ１９と、着脱可能メモリ１３２と、電源１３４と、全地球測位システム（ＧＰＳ）チップセット１３６と、他の周辺機器１３８とを含んでもよい。ＷＴＲＵ１０２は、一実施形態との整合性を維持しながら、前述の要素の任意の副組み合わせを含んでもよいことが理解されるであろう。
【００５１】
プロセッサ１１８は、汎用プロセッサ、専用プロセッサ、従来型プロセッサ、デジタルシグナルプロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアと連携する１つまたは複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、他の任意のタイプの集積回路（ＩＣ）、状態機械などであってもよい。プロセッサ１１８は、信号符号化、データ処理、電力制御、入力／出力処理、および／またはＷＴＲＵ１０２が無線環境内で動作することを可能にする他の任意の機能を実行してもよい。プロセッサ１１８は送受信機１２０に結合されてもよく、送受信機１２０は送信／受信要素１２２に結合されてもよい。図１Ｂは、プロセッサ１１８および送受信機１２０を別個の構成要素として示しているが、プロセッサ１１８および送受信機１２０は、電子パッケージまたはチップにともに一体化されてもよいことが理解されるであろう。
【００５２】
送信／受信要素１２２は、エアインタフェース１１６上で基地局（例えば、基地局１１４ａ）に信号を送信し、またはこれから信号を受信するように構成されてもよい。例えば、一実施形態では、送信／受信要素１２２は、ＲＦ信号を送信および／または受信するように構成されたアンテナであってもよい。別の実施形態では、送信／受信要素１２２は、例えば、ＩＲ信号、ＵＶ信号、または可視光信号を送信および／または受信するように構成されたエミッタ／ディテクタであってもよい。さらに別の実施形態では、送信／受信要素１２２は、ＲＦ信号と光信号の両方を送信および受信するように構成されてもよい。送信／受信要素１２２は、無線信号の任意の組み合わせを送信および／または受信するように構成されてもよいことが理解されるであろう。
【００５３】
さらに、送信／受信要素１２２は、図１Ｂでは単一の要素として示されているが、ＷＴＲＵ１０２は、任意の数の送信／受信要素１２２を含んでもよい。より具体的には、ＷＴＲＵ１０２は、ＭＩＭＯ技術を使用してもよい。したがって、一実施形態では、ＷＴＲＵ１０２は、エアインタフェース１１６上で無線信号を送信および受信するための２つ以上の送信／受信要素１２２（例えば、複数のアンテナ）を含んでもよい。
【００５４】
送受信機１２０は、送信／受信要素１２２によって送信されることになる信号を変調し、送信／受信要素１２２によって受信される信号を復調するように構成されてもよい。前述のように、ＷＴＲＵ１０２は、マルチモード能力を有してもよい。したがって、送受信機１２０は、例えば、ＷＴＲＵ１０２がＵＴＲＡおよびＩＥＥＥ８０２．１１などの複数のＲＡＴを介して通信することを可能にするための複数の送受信機を含んでもよい。
【００５５】
ＷＴＲＵ１０２のプロセッサ１１８は、スピーカ／マイクロホン１２４、キーパッド１２６、および／またはディスプレイ／タッチパッド１２８（例えば、液晶ディスプレイ（ＬＣＤ）ディスプレイユニットまたは有機発光ダイオード（ＯＬＥＤ）ディスプレイユニット）に結合されてもよく、これからユーザ入力データを受信してもよい。プロセッサ１１８は、スピーカ／マイクロホン１２４、キーパッド１２６、および／またはディスプレイ／タッチパッド１２８にユーザデータを出力してもよい。さらに、プロセッサ１１８は、着脱不能メモリ１３０および／または着脱可能メモリ１３２などの任意のタイプの適切なメモリからの情報にアクセスし、これらにデータを記憶してもよい。着脱不能メモリ１９は、ランダムアクセスメモリ（ＲＡＭ）、リードオンリメモリ（ＲＯＭ）、ハードディスク、または他の任意のタイプのメモリストレージデバイスを含んでもよい。着脱可能メモリ１３２は、加入者識別モジュール（ＳＩＭ）カード、メモリスティック、セキュアデジタル（ＳＤ）メモリカードなどを含んでもよい。他の実施形態では、プロセッサ１１８は、サーバまたはホームコンピュータ（図示せず）上などの、ＷＴＲＵ１０２上に物理的に位置していないメモリからの情報にアクセスし、これらにデータを記憶してもよい。
【００５６】
プロセッサ１１８は、電源１３４から電力を受信してもよく、ＷＴＲＵ１０２内の他の構成要素に電力を配信および／または制御するように構成されてもよい。電源１３４は、ＷＴＲＵ１０２に給電するための任意の適切なデバイスであってもよい。例えば、電源１３４は、１つまたは複数の乾電池バッテリ（例えば、ニッケル−カドミウム（ＮｉＣｄ）、ニッケル−亜鉛（ＮｉＺｎ）、ニッケル水素（ＮｉＭＨ）、リチウムイオン（Ｌｉイオン）など）、太陽電池、燃料電池などを含んでもよい。
【００５７】
プロセッサ１１８はまた、ＧＰＳチップセット１３６に結合されてもよく、ＧＰＳチップセット１３６は、ＷＴＲＵ１０２の現在の位置に関する位置情報（例えば、経度および緯度）を提供するように構成されてもよい。ＧＰＳチップセット１３６からの情報に加えて、またはその代わりに、ＷＴＲＵ１０２は、基地局（例えば、基地局１１４ａ、１１４ｂ）からエアインタフェース１１６上で位置情報を受信するおよび／またはその位置を２つ以上の近くの基地局から信号が受信されるタイミングに基づいて判定してもよい。ＷＴＲＵ１０２は、一実施形態との整合性を維持しながら、任意の適切な位置判定方法によって位置情報を取得してもよいことが理解されるであろう。
【００５８】
プロセッサ１１８は他の周辺機器１３８にさらに結合されてもよく、周辺機器１３８は、追加の特徴、機能、および／または有線接続もしくは無線接続性を提供する、１つまたは複数のソフトウェアモジュールおよび／またはハードウェアモジュールを含んでもよい。例えば、周辺機器１３８は、加速度計、電子コンパス、衛星トランシーバ、デジタルカメラ（写真またはビデオのための）、ユニバーサルシリアルバス（ＵＳＢ）ポート、振動デバイス、テレビ送受信機、ハンズフリーヘッドセット、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール、周波数変調（ＦＭ）無線ユニット、デジタル音楽プレイヤ、メディアプレイヤ、ビデオゲームプレイヤモジュール、インターネットブラウザなどを含んでもよい。
【００５９】
図１Ｃは、一実施形態に従ったＲＡＮ１０４およびコアネットワーク１０６のシステム図である。前述のように、ＲＡＮ１０４は、ＵＴＲＡ無線技術を使用して、エアインタフェース１１６上でＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信してもよい。ＲＡＮ１０４は、コアネットワーク１０６と通信してもよい。図１Ｃに示されるように、ＲＡＮ１０４はＮｏｄｅＢ１４０ａ、１４０ｂ、１４０ｃを含んでもよく、ＮｏｄｅＢ１４０ａ、１４０ｂ、１４０ｃは各々、エアインタフェース１１６上でＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するための１つまたは複数の送受信機を含んでもよい。ＮｏｄｅＢ１４０ａ、１４０ｂ、１４０ｃは各々、ＲＡＮ１０４内の特定のセル（図示せず）に関連付けられてもよい。ＲＡＮ１０４は、ＲＮＣ１４２ａ、１４２ｂも含んでもよい。ＲＡＮ１０４は、一実施形態との整合性を維持しながら、任意の数のＮｏｄｅＢとＲＮＣとを含んでもよいことが理解されるであろう。
【００６０】
図１Ｃに示されるように、ＮｏｄｅＢ１４０ａ、１４０ｂは、ＲＮＣ１４２ａと通信してもよい。さらに、ＮｏｄｅＢ１４０ｃは、ＲＮＣ１４２ｂと通信してもよい。ＮｏｄｅＢ１４０ａ、１４０ｂ、１４０ｃは、ｌｕｂインタフェースを介してそれぞれのＲＮＣ１４２ａ、１４２ｂと通信してもよい。ＲＮＣ１４２ａ、１４２ｂは、ｌｕｒインタフェースを介して相互に通信してもよい。ＲＮＣ１４２ａ、１４２ｂの各々は、それが接続されたそれぞれのＮｏｄｅＢ１４０ａ、１４０ｂ、１４０ｃを制御するように構成されてもよい。さらに、ＲＮＣ１４２ａ、１４２ｂの各々は、アウターループ電力制御、負荷制御、アドミッション制御、パケットスケジューリング、ハンドオーバ制御、マクロダイバーシティ、セキュリティ機能、データ暗号化などの他の機能を実行またはサポートするように構成されてもよい。
【００６１】
図１Ｃに示されるコアネットワーク１０６は、メディアゲートウェイ（ＭＧＷ）１４４、モバイルスイッチングセンタ（ＭＳＣ）１４６、サービング汎用パケット無線サービス（ＧＰＲＳ）サポートノード（ＳＧＳＮ）１４８、および／またはゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）１５０を含んでもよい。前述の要素の各々は、コアネットワーク１０６の一部として示されているが、これらの要素のいずれか１つが、コアネットワークオペレータ以外のエンティティによって所有および／または動作されてもよいことが理解されるであろう。
【００６２】
ＲＡＮ１０４内のＲＮＣ１４２ａは、ｌｕＣＳインタフェースを介してコアネットワーク１０６内のＭＳＣ１４６に接続されてもよい。ＭＳＣ１４６は、ＭＧＷ１４４に接続されてもよい。ＭＳＣ１４６およびＭＧＷ１４４は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと従来の陸線通信デバイスとの間の通信を容易にするために、ＰＳＴＮ１０８などの回線交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供してもよい。
【００６３】
ＲＡＮ１０４内のＲＮＣ１４２ａは、ｌｕＰＳインタフェースを介してコアネットワーク１０６内のＳＧＳＮ１４８にも接続されてもよい。ＳＧＳＮ１４８は、ＧＧＳＮ１５０に接続されてもよい。ＳＧＳＮ１４８およびＧＧＳＮ１５０は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとＩＰ対応デバイスとの間の通信を容易にするために、インターネット１１０などのパケット交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供してもよい。
【００６４】
前述のように、コアネットワーク１０６はネットワーク１１２にも接続されてもよく、ネットワーク１１２は、他のサービスプロバイダによって所有および／または動作される、他の有線ネットワークまたは無線ネットワークを含んでもよい。
【００６５】
図１Ｄは、一実施形態に従ったＲＡＮ１０４およびコアネットワーク１０６のシステム図である。前述のように、ＲＡＮ１０４は、Ｅ−ＵＴＲＡ無線技術を使用して、エアインタフェース１１６上でＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信してもよい。ＲＡＮ１０４は、コアネットワーク１０６と通信してもよい。
【００６６】
ＲＡＮ１０４は、ｅＮｏｄｅ−Ｂ１６０ａ、１６０ｂ、１６０ｃを含んでもよいが、ＲＡＮ１０４は、一実施形態との整合性を維持しながら、任意の数のｅＮｏｄｅ−Ｂを含んでもよいことが理解されるであろう。ｅＮｏｄｅ−Ｂ１６０ａ、１６０ｂ、１６０ｃは各々、エアインタフェース１１６上でＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するための１つまたは複数の送受信機を含んでもよい。一実施形態では、ｅＮｏｄｅ−Ｂ１６０ａ、１６０ｂ、１６０ｃは、ＭＩＭＯ技術を実施してもよい。したがって、ｅＮｏｄｅ−Ｂ１６０ａは、例えば、複数のアンテナを使用して、ＷＴＲＵ１０２ａに無線信号を送信し、ＷＴＲＵ１０２ａから無線信号を受信してもよい。
【００６７】
ｅＮｏｄｅ−Ｂ１６０ａ、１６０ｂ、１６０ｃの各々は、特定のセル（図示せず）に関連付けられてよく、ＵＬおよび／またはＤＬなどにおける無線リソース管理決定、ハンドオーバ決定、ユーザのスケジューリングを扱うように構成されてもよい。図１Ｄに示されるように、ｅＮｏｄｅ−Ｂ１６０ａ、１６０ｂ、１６０ｃは、Ｘ２インタフェース上で相互に通信してもよい。
【００６８】
図１Ｄに示されるコアネットワーク１０６は、ＭＭＥ１６２と、サービングゲートウェイ１６４と、パケットデータネットワーク（ＰＤＮ）ゲートウェイ１６６とを含んでもよい。前述の要素の各々は、コアネットワーク１０６の一部として示されているが、これらの要素のいずれか１つが、コアネットワークオペレータ以外のエンティティによって所有および／または動作されてもよいことが理解されるであろう。
【００６９】
ＭＭＥ１６２は、Ｓ１インタフェースを介してＲＡＮ１０４内のｅＮｏｄｅ−Ｂ１６０ａ、１６０ｂ、１６０ｃの各々に接続されてもよく、制御ノードとして機能してもよい。例えば、ＭＭＥ１６２は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのユーザを認証すること、ベアラのアクティブ化／非アクティブ化、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃの初期アタッチの間に特定のサービングゲートウェイを選択することなどを担当してもよい。ＭＭＥ１４２はまた、ＲＡＮ１０４とＧＳＭまたはＷＣＤＭＡなどの他の無線技術を使用する他のＲＡＮ（図示せず）とを切り換えるための制御プレーン機能をもたらしてもよい。
【００７０】
サービングゲートウェイ１６４は、Ｓ１インタフェースを介してＲＡＮ１０４内のｅＮｏｄｅ  Ｂ１６０ａ、１６０ｂ、１６０ｃの各々に接続されてもよい。サービングゲートウェイ１６４は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃへ／からユーザデータパケットを全体的にルーティングおよび転送してもよい。サービングゲートウェイ１６４はまた、ｅＮｏｄｅ  Ｂ間のハンドオーバの間にユーザプレーンをアンカリングすること、ＤＬデータがＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのために利用可能なときにページングをトリガすること、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのコンテキストを管理および記憶することなどの他の機能を実行してもよい。
【００７１】
サービングゲートウェイ１６４はＰＤＮゲートウェイ１６６にも接続されてもよく、ＰＤＮゲートウェイ１６６は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとＩＰ対応デバイスとの間の通信を容易にするために、インターネット１１０などのパケット交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供してもよい。
【００７２】
コアネットワーク１０６は、他のネットワークとの通信を容易にしてもよい。例えば、コアネットワーク１０６は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと従来の陸線通信デバイスとの間の通信を容易にするために、ＰＳＴＮ１０８などの回路交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供してもよい。例えば、コアネットワーク１０６は、コアネットワーク１０６とＰＳＴＮ１０８との間のインタフェースとして機能するＩＰゲートウェイ（例えば、ＩＰマルチメディアサブシステム（ＩＭＳ）サーバ）を含んでもよく、またはこれと通信してもよい。さらに、コアネットワーク１０６は、ネットワーク１１２へのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供してもよく、ネットワーク１１２は、他のサービスプロバイダによって所有および／または動作される、他の有線ネットワークまたは無線ネットワークを含んでもよい。
【００７３】
図１Ｅは、一実施形態に従ったＲＡＮ１０４およびコアネットワーク１０６のシステム図である。ＲＡＮ１０４は、ＩＥＥＥ８０２．１６無線技術を使用して、エアインタフェース１１６上でＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するアクセスサービスネットワーク（ＡＳＮ）であってもよい。以下でさらに論じられるように、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、ＲＡＮ１０４の異なる機能エンティティとコアネットワーク１０６との間の通信リンクは、基準ポイントとして定義されてもよい。
【００７４】
図１Ｅに示されるように、ＲＡＮ１０４は、基地局１７０ａ、１７０ｂ、１７０ｃと、ＡＳＮゲートウェイ１４２とを含んでもよいが、ＲＡＮ１０４は、一実施形態との整合性を維持しながら、任意の数の基地局とＡＳＮゲートウェイとを含んでもよいことが理解されるであろう。基地局１７０ａ、１７０ｂ、１７０ｃは、各々、ＲＡＮ１０４内の特定のセル（図示せず）と関連付けられてよく、各々、エアインタフェース１１６上でＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するための１つまたは複数の送受信機を含んでもよい。一実施形態では、基地局１７０ａ、１７０ｂ、１７０ｃは、ＭＩＭＯ技術を実施してもよい。したがって、基地局１７０ａは、例えば、複数のアンテナを使用して、ＷＴＲＵ１０２ａに無線信号を送信し、ＷＴＲＵ１０２ａから無線信号を受信してもよい。基地局１７０ａ、１７０ｂ、１７０ｃはまた、ハンドオフトリガリング、トンネル確立、無線リソース管理、トラフィック分類、ＱｏＳポリシ強制などのモビリティ管理機能をもたらしてもよい。ＡＳＮゲートウェイ１４２は、トラフィックアグリゲーションポイントとして機能してもよく、ページング、加入者プロファイルのキャッシング、コアネットワーク１０６へのルーティングなどを担当してもよい。
【００７５】
ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとＲＡＮ１０４との間のエアインタフェース１１６は、ＩＥＥＥ８０２．１６規格を実施するＲ１基準ポイントとして定義されてもよい。さらに、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃの各々は、コアネットワーク１０６との論理インタフェース（図示せず）を確立してもよい。ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとコアネットワーク１０６との間の論理インタフェースは、Ｒ２基準ポイントとして定義されてもよく、Ｒ２基準ポイントは、認証、許可、ＩＰホスト構成管理、および／またはモビリティ管理に使用されてもよい。
【００７６】
基地局１７０ａ、１７０ｂ、１７０ｃの各々の間の通信リンクは、ＷＴＲＵハンドオーバおよび基地局間のデータの転送を容易にするためのプロトコルを含むＲ８基準ポイントとして定義されてもよい。基地局１７０ａ、１７０ｂ、１７０ｃとＡＳＮゲートウェイ１４２との間の通信リンクは、Ｒ６基準ポイントとして定義されてもよい。Ｒ６基準ポイントは、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃの各々と関連付けられたモビリティイベントに基づいてモビリティ管理を容易にするためのプロトコルを含んでもよい。
【００７７】
図１Ｅに示されるように、ＲＡＮ１０４は、コアネットワーク１０６に接続されてもよい。ＲＡＮ１０４とコアネットワーク１０６との間の通信リンクは、例えば、データ転送およびモビリティ管理能力を容易にするためのプロトコルを含むＲ３基準ポイントとして定義されてもよい。コアネットワーク１０６は、モバイルＩＰホームエージェント（ＭＩＰ−ＨＡ）１４４と、認証・認可・アカウンティング（ＡＡＡ）サーバ１４６と、ゲートウェイ１４８とを含んでもよい。前述の要素の各々は、コアネットワーク１０６の一部として示されているが、これらの要素のいずれか１つが、コアネットワークオペレータ以外のエンティティによって所有および／または動作されてもよいことが理解されるであろう。
【００７８】
ＭＩＰ−ＨＡ１４４は、ＩＰアドレス管理を担当してもよく、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃが、異なるＡＳＮおよび／または異なるコアネットワーク間でローミングすることを可能にしてもよい。ＭＩＰ−ＨＡ１４４は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとＩＰ対応デバイスとの間の通信を容易にするために、インターネット１１０などのパケット交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供してもよい。ＡＡＡサーバ１４６は、ユーザ認証と、ユーザサービスをサポートすることとを担当してもよい。ゲートウェイ１４８は、他のネットワークとのインターワーキングを容易にしてもよい。例えば、ゲートウェイ１４８は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと従来の陸線通信デバイスとの間の通信を容易にするために、ＰＳＴＮ１０８などの回路交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供してもよい。さらに、ゲートウェイ１４８は、ネットワーク１１２へのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供してもよく、ネットワーク１１２は、他のサービスプロバイダによって所有および／または動作される、他の有線ネットワークまたは無線ネットワークを含んでもよい。
【００７９】
図１Ｅには示されていないが、ＲＡＮ１０４は他のＡＳＮに接続されてもよく、コアネットワーク１０６は他のコアネットワークに接続されてもよいことが理解されるであろう。ＲＡＮ１０４と他のＡＳＮとの間の通信リンクは、Ｒ４基準ポイントとして定義されてもよく、Ｒ４基準ポイントは、ＲＡＮ１０４と他のＡＳＮとの間でＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのモビリティを協調させるためのプロトコルを含んでもよい。コアネットワーク１０６と他のコアネットワークとの間の通信リンクは、Ｒ５基準として定義されてもよく、Ｒ５基準は、ホームコアネットワークと移動先コアネットワークとの間のインターワーキングを容易にするためのプロトコルを含んでもよい。
【００８０】
ＧＣＳＥグループ通信アーキテクチャ２００を再度参照すると、グループ管理は、ＵＥ２０４、ＧＣＳＥ  ＡＳ２１４と、発展型パケットコア（ＥＰＣ）との間で扱われてよい。ＭｕＳｅ機能２１０は、ブラックボックスと考えられてもよい。したがって、グループ管理プロシージャは、アーキテクチャオプションから独立していてもよい。これらのプロシージャは、ネットワークによって制御されてもよく、ＧＣＳＥグループに参加するＵＥ２０４に適用されてもよい。さらに、それらは、ＧＣＳＥのためのアーキテクチャの選択とは独立していてもよい。
【００８１】
ＧＣＳＥサービスエリアの定義
【００８２】
本明細書で論じられる要件に基づいて、グループメンバは、ＧＣＳＥグループの地理的範囲によって示されるエリアに対応するセル内でのみ受信および／または送信してもよい。要求されたとき、グループメンバがＧＣＳＥグループから通信に参加することを中止する場合、例えば、制限された地理的範囲を有するグループの場合、グループメンバがグループのサービスエリアから出るとき、通知が要求元エンティティに送信されてもよい。
【００８３】
ＧＣＳＥサービスエリア（例えば、ＧＣＳＥサービスエリアとマルチキャスト／ブロードキャスト単一周波数ネットワーク（ＭＢＳＦＮ）エリアなどとの間の関係）、ＧＣＳＥが、地理的範囲を有するグループに対してどのように達成されてもよいか、および例えば、グループのサービスエリアから出ることに起因して、グループメンバがそのＧＣＳＥグループと通信することを中止するときに通知がどのように提供されてもよいかを説明するための解決策が提案することができる。さらに、グループサービスエリアが動的であることが可能であってもよく、すなわち、それは、グループ内のＵＥの数およびそれらの位置に基づいて拡大または縮小してもよい。
【００８４】
ＧＣＳＥグループ構成
【００８５】
グループ構成またはグループ管理要件のうちのいくつかは、非特許文献１において試験されていることがある。調査することができるグループ管理動作は、ＧＣＳＥグループの確立を含んでもよい。そのうえ、新たなグループが確立されるとき、いくつかのシナリオが考えられてもよい。これらのシナリオは、以下のうちの１または複数を含んでもよい。新たなグループは、静的に構成されてもよいし、または動的に作成されてもよい。新たなグループの作成は、サーバによって、またはユーザによって開始されてもよく、新たに作成されたグループ情報は潜在的メンバにもたらされてもよい。そのうえ、ＧＣＳＥグループに参加することを要求するユーザが承認されてもよい。
【００８６】
さらに、グループリーダの選択および役割が説明および調査されてもよい。ＧＣＳＥグループリーダの機能は、明確でなくてよい。試験では、特定のグループリーダをどのように選択することができるかは、明確でなくてもよい。したがって、そのような課題に対して明確な解決策が提供されなくてもよい。グループ作成について説明される問題は、グループの再編成または解放にも適用されてもよい。
【００８７】
グループ管理における３ＧＰＰネットワーク支援のための要件
【００８８】
概して、大部分のグループ管理プロシージャは、例えば、拡張されたセッション開始プロトコル（ＳＩＰ）シグナリングを介して、ＵＥのグループアプリケーションとアプリケーションレイヤにおいて実行されるグループアプリケーションサーバとの間で発生してもよく、３ＧＰＰネットワークに対して透過的であってもよい。
【００８９】
ここで図３を参照すると、グループ登録プロシージャ３００の説明が示されている。３ＧＰＰネットワークへのアタッチメントが成功すると、ＵＥ内のグループアプリケーションは、アプリケーションレイヤシグナリングを介してグループアプリケーションサーバに登録してもよい。それはまた、そのグループＩＤ、そのグループメンバＩＤ、その割り当てられたＩＰアドレス、その承認情報などの情報を提供してもよい。しかしながら、３ＧＰＰネットワークがグループ管理プロシージャを支援するよう要求されルことがあるケースが存在してもよい。本明細書で説明される動作およびアーキテクチャはＵＥに対して説明されてもよいが、説明が任意のタイプのＷＴＲＵデバイスを指す場合があることを理解されよう。
【００９０】
ＵＥステータス更新
【００９１】
グループメンバは、グループメンバが例えばＧＣＳＥによって到達することができるかを示すための到達可能性ステータス（reachability status）を有してもよい。特に、ＧＣＳＥアプリケーションサーバによるグループメンバの到達可能性が示されてもよい。そのうえ、グループメンバの到達可能性ステータスは変更されてもよく、グループアプリケーションサーバは、そのような変更により更新されなくてもよい。例えば、これは、種々の理由のうちのいずれかでＵＥがデタッチされたときに発生してもよい。アプリケーションレイヤ通信が可能でないことがあるので、ＵＥのグループアプリケーションは、この発生によりサーバを更新しなくてもよい。加えて、ＵＥは、グループ通信をサポートしない別のＲＡＴ／ネットワークを選択していてもよい。そのうえ、データサービスが、新たなＲＡＴ／ネットワークにおいて利用可能でなくてもよい。ＵＥは、グループ通信をサポートしないエリアに移動してもよく、またはグループ通信のいくつかの特徴（例えば、マルチキャスト）をサポートしなくてもよい。そのうえ、ＵＥアプリケーションは、いくつかまたはすべての変更を認識しなくてもよい。ＵＥアプリケーションは、いくつかの３ＧＰＰネットワーク制御に起因して、アプリケーションサーバと通信することが可能でないことがある。制御は、アクセス禁止、輻輳制御、アプリケーション特有アクセス制御、ロングＤＲＸ（long DRX）／節電状態などを含んでもよいが、それらに限定されない。
【００９２】
デタッチメント状況が発生し、および検出されるとき、グループメンバの到達可能性ステータスまたはグループ通信能力は、グループアプリケーションサーバにおいて正確でないことがある。したがって、サーバは、アプリケーションシグナリング／データをユーザに不必要に送信し続けることがある。これらの状況では、それは、３ＧＰＰネットワークがＵＥのステータス変更をグループアプリケーションサーバに適時に通信できる場合に有用となることがある。これは、グループアプリケーションサーバにグループメンバを再アタッチすることを支援することがある。
【００９３】
グループの登録／参加へのインビテーション
【００９４】
新たなグループが動的に作成されるとき、グループ管理者は、新たなグループに登録／参加することをそれに要求するインビテーションを潜在的グループメンバに送信してもよい。このインビテーションは、アプリケーションレイヤシグナリングを介して送信されてもよい。これらの状況の下で、新たなグループのメンバのうちのいくつかは、すでに別のグループのメンバであってもよい（例えば、それらは、静的に事前構成されたグループであってもよい）。あるいは、新たなグループの潜在的メンバのうちのいくつかは、他の任意のグループのメンバでなくてもよい。
【００９５】
最初のケースでは、新たな動的グループ管理者は、グループメンバの到達可能性情報（例えば、そのＩＰアドレス）へのアクセスを有してもよい。これは、新たなグループサーバと既存のグループサーバが同一である場合、または同一の組織の制御下で、発生してもよい。新たなグループがそのような情報へのアクセスを有していない可能性が存在することもある。後者のケースでは、新たなグループは、ユーザに到達する手段を有していないことがある。これらのケースでは、３ＧＰＰネットワークは、散在的グループメンバにインビテーションを送信することによって関与させられてもよい。
【００９６】
グループメンバの３ＧＰＰネットワーク情報収集／フィードバック
【００９７】
ＢＭ−ＳＣによって判定されるＭＢＭＳ制御プレーンノード（ＭＭＥ、ＭＢＭＳ  ＧＷのためのＳＧＳＮ）のリストが、ＭＢＭＳセッションのセッション開始プロシージャ内でシグナリングされてもよい。これは、例えば、非特許文献４で説明されてもよい。ＢＭ−ＳＣがどのように情報を取得するかが指定されてもよい。最も単純な構成は、グループ通信をグループ／ＧＣＳＥサービスエリア全体でブロードキャストすることができる構成であってもよい。しかしながら、これは、グループが小規模であり、小規模な地理的領域で動作する場合、リソースの最適な使用でないことがある。永続的なＲＲＣ接続デバイスが可能であってもよく、既存のユーザ位置報告機構がネットワークに利用されて、グループユーザの位置を判定してもよい。しかしながら、グループユーザは、ＲＲＣ接続デバイスであることを必要とすることがある。これは、グループ通信の頻度があまり高くない場合、バッテリ寿命ペナルティを有してもよい。
【００９８】
グループ通信のためのＰｒｏＳｅ  ＵＥ−ネットワーク中継機
【００９９】
ＧＣＳＥのためのＵＥ−ネットワーク中継機が、ＵＥ内のアプリケーションレベルプロキシに基づくことができるシステムが提案されている。これは、中継ＵＥが、グループのアプリケーションプロトコルを理解し、中継されるＧＣＳＥユーザのアプリケーションレベル情報を読み取ることを可能にすることを必要とすることがある。このモデルは、中継されるＧＣＳＥユーザと同一のグループに属するＵＥに適切となることがある。同一のグループに属するＰｒｏＳｅ  ＵＥ−ネットワーク中継機が存在しない場合、本明細書で論じられる機構は実行可能でないことがある。グループ提携（group affiliation）とは無関係に中継を可能にするための機構が必要とされることがある。
【０１００】
グループの優先度
【０１０１】
いくつかのグループ通信では、異なるトランスポート経路、例えばユニキャスト／マルチキャスト配信が可能となることがある。さらに、いくつかのグループ通信では、パブリックランドモバイルネットワーク（ＰＬＭＮ）内の特定の媒体に対する優先度およびプリエンプション能力（preemption capability）は、どのトランスポート経路が選択されても、同一であってもよい。
【０１０２】
そのうえ、グループ通信は、異なる媒体、例えば、音声および画像を含んでもよい。いくつかのＧＣＳＥグループ通信では、異なるユーザが異なる優先度を有してもよい。リソースが限定されるとき、システムは、優先度レベルに基づいてグループ通信に割り当てられたリソースを解放してもよい。それは、異なる通信グループのプリエンプション能力に基づいてリソースを解放してもよい。
【０１０３】
非グループ通信に対するグループ通信の優先度割り当てを含む、グループ通信のトラフィックおよび／またはユーザの優先度レベルおよびプリエンプション能力の割り当てに関するルールが設けられてもよい。ベアラ（例えば、ＭＢＭＳをサポートしていない）が、ＵＭＴＳ／ＬＴＥ内で双方向に備えられてもよい。グループ通信に対し、優先度およびプリエンプション対応（priority and pre-emption handling）、例えば同一の通信グループインスタンス内のユーザ優先度をサポートするベアラモデルが備えられてもよい。
【０１０４】
セキュリティプロシージャ
【０１０５】
グループ通信のためのセキュリティ要件は、システムが３ＧＰＰ  ＬＴＥパケットデータベアラ内のグループ通信と少なくとも同一のセキュリティレベルをサポートすることができることであってもよい。例えば、システムは、認証要件、完全性要件、秘匿性要件、およびプライバシー要件をサポートしてもよい。そのうえ、例えば、ＭＢＭＳセキュリティプロシージャ（例えば、非特許文献５において説明される）が再使用される場合、修正／変更が要求されてもよい。別の例として、グループメンバがグループから離れる場合（すなわち、グループ通信セッションが進行中である間、それがグループから離れる）場合、ユーザがもはやグループ通信を受信することができないことを保証することが必要となることがある。さらに、通信が、ＰＤＳＣＨを使用するグループキャストによって実現される場合、追加セキュリティプロシージャが要求されることがある。
【０１０６】
ＧＣＳＥサービスエリア定義
【０１０７】
ＧＣＳＥサービスエリアの考えられる実施形態では、ＧＣＳＥサービスエリアは、以下のうちのいずれかとして設けられてもよい。それはセルの収集であってもよく、例えば、セルは、同一の限定加入者グループ（ＣＳＧ）ＩＤを有してもよく、またはＣＳＧ  ＩＤのリストに属してもよい。さらに、セルは、ローカルホームネットワークであってもよい。あるいは、ＧＣＳＥサービスエリアは、例えば、ローカルエンタープライズネットワークであってもよく、またはトラッキングエリアＩＤの組み合わせであってもよい。ＧＣＳＥサービスエリアは、複数のＰＬＭＮからのセルにまたがって（span）もよいし、または、それは、複数のＣＳＧにまたがってもよい。ＧＣＳＥサービスエリアは、複数のＭＢＳＦＮエリアにまたがってもよい。それはまた、特定の数のＧＣＳＥグループによって説明されてもよい。そのうえ、非３ＧＰＰ  ＡＰ、例えば、同一のＳＳＩＤを有するＷｉ−Ｆｉ  ＡＰのリストがＧＣＳＥサービスエリアを形成してもよい。あるいは、非３ＧＰＰ  ＡＰのリストのＡＰは、本明細書で説明されるポイントのいずれかと組み合わせてもよい。そのうえ、アクティブなＵＥのエリアは、ＧＣＳＥサービスエリアを構成してもよい。
【０１０８】
ＧＣＳＥサービスエリアは識別子に関連付けられてよく、この識別子はＧＵＩＤであってもよい。そのような識別子は、ＧＣＳＥサービスエリア内でセルによってブロードキャストされてもよい。ＧＣＳＥサービスエリア識別子はまた、ＵＥ間で交換されてもよい。それは、専用ＲＲＣメッセージ内、ＮＡＳメッセージ、ＧＣＳＥ  ＡＳ固有メッセージ、または他の上位レイヤ方法において、ＵＥとネットワークエンティティとの間で交換されてもよい。他の方法は、ＡＮＤＳＦ、ＯＭＡ  ＤＭ、ＳＭＳなどを含んでもよいが、それらに限定されない。ＧＣＳＥサービスエリア識別子は、さまざまなＧＣＳＥ対応ＵＥ間のグループ管理またはグループ通信をサポートするＵＥまたはネットワークエンティティ（ＭＭＥ、ｅＮＢ／ＨｅＮＢ、ＧＣＳＥ  ＡＳまたはＭｕＳｅを含むＧＷ）によって使用されてもよい。グループサービスエリア内のＵＥは、同一のＧＣＳＥグループの一部であってもよく、または、それらは、異なるＧＣＳＥグループの一部であってもよい。
【０１０９】
グループサービスエリアＩＤは、特定のグループ内のユーザを追跡するために、グループアプリケーションサーバまたはＥＰＳによって使用されてもよい。ＵＥ内の、またはＵＥ内の他のプロトコルメッセージ（例えば、ＮＡＳ、ＲＲＣなど）内のＧＣＳＥアプリケーションは、ＧＣＳＥアプリケーションサーバ（または他の任意のネットワークノード、例えば、ＭＭＥ、ｅＮＢなど）と連絡するときのサービスエリアＩＤを含んでもよい。したがって、アプリケーションサーバは、特定のＧＣＳＥグループメンバの位置について高い粒度で認識することができる。
【０１１０】
そのうえ、グループサービスエリアＩＤはまた、グループが特定のサービスエリア内にあるかどうかを判定するためにＵＥによって使用されてもよい。そのような特徴を有効にするために、グループサービスＩＤとグループＩＤとの間のマッピングが存在してもよい。例えば、特定のＩＤを有するグループは、異なるグループサービスＩＤを有するさまざまなグループサービスエリア内で利用可能であってもよい。ＵＥが特定のグループサービスエリア内にあるとき、それは、サービスエリアに対するグループＩＤを使用して、どのグループが参加するのに利用可能とすることができるかを判定してもよい。これは、ＵＥにおいて、例えば、ＧＣＳＥアプリケーションにおいて、またはＯＭＡ  ＤＭもしくはユニバーサル加入者識別モジュール（ＵＳＩＭ）による構成によって、グループＩＤとグループサービスエリアＩＤとの間のマッピングを使用して達成可能されてもよい。あるいは、ＵＥは、グループサービスＩＤに関連付けられたグループＩＤを要求するＧＣＳＥアプリケーションサーバにグループサービスＩＤを送信してもよい。
【０１１１】
グループＩＤおよびグループアプリケーションＩＤのマッピング
【０１１２】
３ＧＰＰネットワークは、特定のセル内または特定のＧＣＳＥサービスエリア内でサポートすることができるグループのレイヤ−２グループＩＤをブロードキャストしてもよい。レイヤ−２  ＩＤは、システム情報ブロック（ＳＩＢ）シグナリング内のＲＡＮによってブロードキャストされてもよく、または、それは、ｅＮＢによる専用ＲＲＣによってＵＥに送信されてもよい。あるいは、それは、ＭＭＥによるＮＡＳシグナリングによって送信されてもよい。
【０１１３】
ＵＥがレイヤ−２グループＩＤを受信するとき、それは、ＩＤをＵＥ内のグループアプリケーションレイヤに転送してもよい。ＵＥ内のアプリケーションレイヤがレイヤ−２グループＩＤとグループアプリケーションレイヤＩＤのマッピングを含むことが可能である場合がある。アプリケーションレイヤがマッピングを有する場合、それは、ユーザまたはＵＥが特定のグループアプリケーションに関心があるかどうかを認識することができる。それが、そのグループアプリケーションの一部であることに関心がある場合、それは、グループアプリケーションサーバと連絡してもよい。
【０１１４】
あるいは、ＵＥ内のアプリケーションレイヤが、レイヤ−２グループＩＤとアプリケーションレイヤグループＩＤのマッピングを実行する能力を有していない場合、またはマッピング情報を有していない場合、それは、グループアプリケーションサーバＭＭＥまたはＰｒｏＳｅサーバと連絡してもよい。それは、それらのうちの１つにレイヤ−２グループＩＤを送信してもよい。グループアプリケーションサーバ、ＭＭＥ、またはＰｒｏＳｅサーバは、グループＩＤの変換で応答し、したがって、グループアプリケーションＩＤを提供してもよい。ＵＥ内のグループアプリケーションは、次いで、グループアプリケーションＩＤを使用して、適切なグループアプリケーションサーバと連絡してもよい。
【０１１５】
サービスエリアに入り、離れるための通知
【０１１６】
次に図４を参照すると、通知プロシージャ４００の考えられる実施形態が示されている。通知プロシージャ４００では、ＧＣＳＥグループアプリケーション４０２を実行しているＵＥ４０４は、それが新たなＧＣＳＥサービスエリアに入るときはいつでも、ＧＣＳＥシステムによって通知されてもよい。したがって、例えば、ＵＥ４０４は、それが非ＧＣＳＥエリアからＧＣＳＥサービスエリアに入るときに通知されてもよい。それが異なるＧＣＳＥサービスエリアＩＤを有するＧＣＳＥサービスエリアに入るときにも、それは通知されてもよい。このタイプの通知は、ＵＥ４０４が、それがＧＣＳＥのサポートがあるセル、トラッキングエリアなどによってサービスされてもよいかを判定することを支援することができる。それは、エリア内のどのグループが、ＵＥ４０４が参加するために利用可能であってもよい判定するのを支援することができる。通知は、ＵＥ４０４内のＧＣＳＥアプリケーションサーバ４１６とＧＣＳＥグループアプリケーション４０２との間のユーザプレーンシグナリングとして、またはＮＡＳメッセージ、ＡＮＤＳＦ、ＯＭＡ  ＤＭなどを介して、送信されてもよい。
【０１１７】
ＭｕＳｅ機能４１２は、それがＧＣ４インタフェースを介してＭＭＥ４０８とインタフェースすることができるので、３ＧＰＰシステム内で動作しているＧＣＳＥ  ＵＥを追跡してもよい。それは、ＧＣ３インタフェースを介してｅＮＢともインタフェースしてもよい。任意のＵＥ４０４に対して、ＭＭＥ４０８が、ＵＥ４０４がＧＣＳＥ対応であるかどうかを判定することが可能であることが仮定されてもよい。ＭＭＥ４０８は、この情報をホーム加入者サービス（ＨＳＳ）内の加入者パラメータから取得してもよい。したがって、あらゆるＧＣＳＥ対応ＵＥ４０４に対して、ＭＭＥ４０８は、ＵＥ４０４のトラッキングエリアＩＤまたはセルＩＤ（または他のＧＣＳＥサービス）の変更をＭｕＳｅ機能４１２に報告してもよい。
【０１１８】
ＭｕＳｅ機能４１２は、トラッキングエリアＩＤ、セルＩＤなどの変更がＧＣＳＥサービスエリアの変更を引き起こしたかどうか判定してもよい。それがＧＣＳＥサービスエリアＩＤへのトラッキングエリアＩＤのマッピングを有してもよいので、それが、この判定をすることができる。ＭｕＳｅ機能４１２が、ＧＣＳＥサービスの変更があったと判定した場合、それは、ＵＥ４０４に通知するために、通知プロシージャ４００などのプロシージャを実行してもよい。ＭｕＳｅ機能４１２は、ＧＣＳＥアプリケーションサーバ４１６と連絡して、ＵＥ４０４に通知メッセージを送信してもよい。それはまた、ＵＥ４０４にＧＣＳＥサービスエリアの変更を通知してもよい。ＧＣＳＥアプリケーションサーバ４１６はまた、このメッセージを、アプリケーションレベルシグナリングを介して送信してもよい。
【０１１９】
以下は、通知プロシージャ４００において実行されるステップのさらなる説明であってもよい。ＵＥ４０４は、新たなトラッキングエリアに入り、ＴＡＵプロシージャを実行してもよい。図を簡略化するために、通知プロシージャ４００には示されていないが、ＵＥ４０４は、セル内で別のＮＡＳプロシージャ（例えば、サービス要求）を実行してもよい。したがって、システムは、例えば、トラッキングエリア識別に関係なく、異なるセルＩＤに基づいて、ＧＣＳＥサービスエリアの変更を決定してもよい。これは、ＧＣＳＥサービスエリアの構成に依存してもよい。
【０１２０】
ＭＭＥ４０８は、ＵＥ４０４の新たなトラッキングエリアＩＤ（または、ＵＥ４０４を位置付けすることができる新たなＧＣＳＥサービスエリアＩＤ）でＭｕＳｅ機能４１２を更新してもよい。ＭｕＳｅ機能４１２は、新たなトラッキングエリアが新たなＧＣＳＥサービスエリアの一部であるかどうかを判定してもよい。したがって、それは、ＵＥ４０４に通知するために、ＧＣＳＥアプリケーションサーバ４１６にメッセージ（すなわち、通知要求）を送信してもよい。ＧＣＳＥグループアプリケーションサーバ４１６は、それが新たなＧＣＳＥサービスエリアに入ったことをＵＥ４０４に通知するために、アプリケーションレイヤシグナリングメッセージＧＣＳＥサービスエリア更新を送信してもよい。
【０１２１】
４０４  ＵＥが、接続モードであるとき、例えば、ハンドオーバが発生するとき、通知プロシージャ４００が実行されてもよい。さらに、それは、ＵＥ４０４が、アイドルモードで開始されるＴＡＵメッセージを送信するときに実行されてもよい。接続モードハンドオーバの場合、通知プロシージャ４００のステップ１は、異なってよく、例えば、ＴＡＵプロシージャは、ハンドオーバプロシージャと交換されてもよい。ステップ１によれば、ＭＭＥ４０８は、ＵＥ４０４のサービングトラッキングエリアまたはセルＩＤなどが更新されたと判定してもよい。
【０１２２】
ＵＥ４０４がＧＣＳＥサービスエリアを離れる場合、実質的に同様のプロシージャが、ＵＥ４０４に通知するために使用されてもよい。ＵＥ４０４がＧＣＳＥサービスエリアを離れ、ＧＣＳＥがもはや利用可能でないエリアに進むと、グループアプリケーションサーバ４１６は、ステップ４のメッセージ（ＧＣＳＥサービスエリア更新）をＵＥ４０４に送信してもよい。メッセージは、空のＧＣＳＥサービスエリアＩＤフィールド、またはダミーのＧＣＳＥサービスエリアＩＤを有してもよい。ＵＥ４０４がそのようなメッセージを受信すると、それは、それがＧＣＳＥサービスエリアを離れることを理解することができる。
【０１２３】
グループサービスエリアの動的管理
【０１２４】
いくつかのケースでは、グループサービスエリアの構成が動的であってもよいこと可能性がある。例えば、ＵＥ４０４が、サービスエリアから移動するが、グループの一部であることを依然として要求する場合、サービスエリアが増加されてもよい。ＥＰＳおよびＧＣＳＥシステムが、ＵＥ４０４が移動した新たなエリア内での進行中のＧＣＳＥグループ通信の継続をサポートすることが可能な場合にこれが可能となることがある。新たなエリアが、ＧＣＳＥエリア内に含まれる場合、このプロセスはＵＥ４０４に透過的であってもよく、ＵＥ４０４は、そのＧＣＳＥ通信を継続してもよい。
【０１２５】
ＧＣＳＥサービスエリア構成が更新されるとき、ＭｕＳｅ機能４１２は、それがＧＣＳＥサービスエリアＩＤとトラッキングエリアＩＤとの間のマッピングのために有するマッピングテーブルを更新してもよい。例えば、それは、ＧＣＳＥサービングエリアの新たな構成をサービスエリア内のすべてのＵＥ４０４に適用してもよい。
【０１２６】
サービスエリアが更新されると、ＵＥ４０４は、システム（ＧＣＳＥシステム、ＭｕＳｅ機能４１２、ＭＭＥ４０８、または上位レイヤ方法、例えば、ＡＮＤＳＦ）によって通知されてもよく、したがって、ＵＥ４０４は、そのマッピングも更新してもよい。ＵＥ４０４は、ＧＣＳＥサービスエリアＩＤに関する前の情報に基づいて、セッションをドロップせずに、そのセッションを継続することができる。
【０１２７】
ＧＣＳＥサービスエリアが、アクティブなＵＥのエリアから構成される場合、サービスエリアがグループ所有者に従ってもよい可能性がある。したがって、サービスエリアは、グループの所有者の移動により移動してもよく、それは、所有者の移動により拡大または収縮してもよい。
【０１２８】
３ＧＰＰネットワーク支援グループ管理
【０１２９】
次に図５を参照すると、グループ管理プロシージャ５００の一実施形態が示されている。グループ管理プロシージャ５００は、３ＧＰＰネットワーク５０２とグループアプリケーションサーバ５２０との間の通信を容易にしてもよい。グループアプリケーションサーバ５２０は、グループ通信サーバ５２０と称されてもよい。グループ管理プロシージャ５００は、本明細書で説明される課題の解決策を提供することができる。
【０１３０】
３ＧＰＰネットワークとグループアプリケーションサーバとの間のＩＷＦエンティティ
【０１３１】
グループ管理プロシージャ５００では、ＩＷＦエンティティ５１６は、３ＧＰＰネットワーク５０２とグループアプリケーションサーバ５２０との間で備えられてもよい。ＩＷＦエンティティ５１６は別個の物理ノードであってもよく、または、それはＭＭＥ５１２内の論理機能であってもよい。したがって、ＩＷＦエンティティ５１６は、論理ノード５１６と称されてもよい。さらに、ＩＷＦエンティティ５１６は、ＣＮ内の他の任意のノード内の論理機能、例えばＨＳＳ５０４、ＭＭＥ５１２、ＰｒｏＳｅサーバなどであってもよい。
【０１３２】
ＩＷＦエンティティ５１６によって実行される機能は、限定するものではないが、以下のものを含んでもよい。ＩＷＦエンティティ５１６は、３ＧＰＰネットワーク５０２またはグループアプリケーションサーバ５２０からの通信要求を承認してもよい。それはまた、ＵＥ５２４の３ＧＰＰＩＤとグループメンバＩＤとの間で変換してもよい。ＩＷＦエンティティ５１６はまた、サーバ名またはユニフォームリソース識別子（ＵＲＩ）により特定のグループアプリケーションサーバ５２０の宛先アドレス／ポートを位置付けるために、ドメインネームサーバ（ＤＮＳ）５０８ルックアップを実行してもよい。ＩＷＦエンティティ５１６は、グループアプリケーションサーバ５２０からの通信要求のために、宛先３ＧＰＰネットワークエンティティも位置付けてもよい。さらに、ＩＷＦエンティティ５１６は、３ＧＰＰネットワーク５０２からグループアプリケーションサーバ５２０に、もしくはその逆にメッセージを転送してもよく、または、メッセージをいずれの側から連結して、メッセージの数／負荷を減少させてもよい。
【０１３３】
ＩＷＦエンティティ５１６のためのインタフェースは、ＩＷＦ−ＭＭＥ、ＩＷＦ−ＨＳＳ、ＩＷＦ−ＤＮＳ、ＩＷＦ−グループアプリケーションサーバ、およびＩＷＦ（ホームネットワーク）−ＩＷＦ（訪問先ネットワーク）、または他の任意のタイプのインタフェースを含んでもよいが、それに限定されない。
【０１３４】
３ＧＰＰネットワーク支援ステータス更新
【０１３５】
次に図６を参照すると、グループ登録プロシージャ６００が示されている。グループユーザに対し、ＨＳＳ／ＨＬＲ内に記憶されたプロファイルが、そのステータスをグループユーザとして示してもよい。任意選択で、それは、任意の事前構成されたグループ名／識別子およびそれぞれのグループメンバＩＤを示してもよい。さらに、ＭＭＥは、ＵＥのアタッチメントまたは登録プロシージャ（例えば、ＴＡＵ／ルーティングエリア更新（ＲＡＵ）／位置エリア更新（ＬＡＵ））中に、そのグループ加入者データを取り出してもよい。ＵＥはまた、ＵＥのアタッチメントまたはエリア更新ＮＡＳメッセージ内で、そのグループ通信能力、ならびに任意選択で、事前構成されたグループ名／識別子およびそれぞれのグループメンバＩＤを示してもよい。グループ通信能力は、限定するものではないが、以下の能力情報を含んでもよい。この情報は、ＵＥがマルチキャストグループ通信をサポートするかどうか、それがデバイスツーデバイス通信をサポートするかどうか（ネットワークカバレッジなしで）、およびそれがグループ通信のためにサポートする媒体タイプ（音声、データ、ビデオなど）を含んでもよい。この情報は、サポートされるグループの最大数、それがグループ通信に地理的情報（例えば、ＧＰＳ座標）を提供できるかどうか、およびそれがグループ通信のためにサポートする認証／承認方法も含んでもよい。
【０１３６】
さらに、ＵＥは、そのアプリケーションレイヤグループ登録メッセージに、いくつかの形式の３ＧＰＰ識別子を有してもよい。３ＧＰＰ識別子は、グループアプリケーションサーバに記憶されてもよい。３ＧＰＰ識別子は、３ＧＰＰネットワークがグループアプリケーションサーバと連絡し、ユーザのステータスを更新するとき、対応するグループメンバを位置付けるインデックスとして機能してもよい。グループ登録メッセージにおいて使用することができる３ＧＰＰ識別子は、限定するものではないが、統合サービスデジタルネットワーク（ＩＳＤＮ）番号、Ｓｙｓｔｅｍ  ａｒｃｈｉｔｅｃｔｕｒｅ  ｅｖｏｌｕｔｉｏｎ  Ｔｅｍｐｏｒａｒｙ  Ｍｏｂｉｌｅ  Ｓｕｂｓｃｒｉｂｅｒ  Ｉｄｅｎｔｉｔｙ（Ｓ−ＴＭＳＩ）、Ｇｌｏｂａｌｌｙ  Ｕｎｉｑｕｅ  Ｔｅｍｐｏｒａｒｙ  ＩＤ（ＧＵＴＩ）、または国際モバイル加入者識別番号（ＩＭＳＩ）のうちの１つまたは組み合わせであってもよい。
【０１３７】
例えば、ＧＵＴＩ再割り当てプロシージャに起因した、３ＧＰＰ識別子の変更時、ＵＥ内のグループ通信アプリケーションが通知されてもよい。したがって、ＵＥは、アプリケーションサーバで登録更新を開始してもよい。また、すでに登録されたユーザが別のデバイスから再登録し、新たな３ＧＰＰ識別子で登録情報を更新することが可能であってもよい。アプリケーションロジックは、新たな３ＧＰＰ識別子が古い３ＧＰＰ識別子に優先するかどうかを判定してもよい。あるいは、同一のユーザが、複数のデバイス上で同時に登録可能である。
【０１３８】
さらに、ユーザがグループアプリケーションサーバに正常に登録した後、ＵＥは、ＮＡＳプロシージャを介して対応するＵＥコンテキストのためのＭＭＥ内の関連したグループ情報を更新してもよい。関連したグループ情報は、限定するものではないが、登録されたグループ、対応するメンバＩＤ、対応するグループ通信サーバＵＲＩもしくはＩＰアドレス／ポート、または他の有用な情報を含んでもよい。
【０１３９】
定期的グループ登録のケースでは、ＵＥは、グループ登録があるたびにＭＭＥコンテキストを更新するよう要求されなくてもよい。しかしながら、関連した情報の変更がある場合、登録が実行されてもよい。例えば、ＵＥ／ユーザが登録することができず、またはグループへの登録を解除する場合、ＵＥ／ユーザは、ＭＭＥコンテキスト内の登録されたグループリストからグループを除去してもよい。
【０１４０】
ＵＥはまた、ＭＭＥでグループ登録情報を定期的に更新するよう要求されてもよい。ＭＭＥおよびＵＥは、定期更新についてタイマをネゴシエートしてもよく、ＭＭＥ内のタイマが満了になったが、定期更新が受信されていない場合、ＭＭＥは、記憶されている登録されたグループ情報を除去することを決定してもよい。
【０１４１】
ＵＥが新たなＭＭＥでＴＡＵを実行するとき、それがさらなる情報を有する場合に、それがその更新メッセージに任意の情報を含んでもよい。既存のＴＡＵメッセージは、そのようなグループ登録情報を搬送ように拡張されてもよいし、または新たなＮＡＳプロシージャは、この目的のために設計されてもよい。
【０１４２】
次に図７を参照すると、グループインビテーションプロシージャ７００が示されている。グループインビテーションシステム７００の第１のステップでは、グループ登録インビテーションは、ＵＥ上で実行されているグループアプリケーションに送信されてもよい。グループ登録は、ＩＷＦエンティティおよび３ＧＰＰネットワークを介して送信されてもよい。グループ登録インジケーションおよびＴＡＵが提供されてもよい。３ＧＰＰネットワークは、グループアプリケーションサーバと連絡して、ＵＥのステータスの変更があるかどうかをサーバに通知してもよい。これは、ユーザ到達可能性に影響を与えることがある。したがって、ＵＥがデタッチされ、ＵＥが再アタッチされ、ＵＥが別のＲＡＴ（グループ通信をサポートしてもよく、またはしてなくてもよい）を選択しており、ＵＥがグループ通信もしくはいくつかのグループ通信機能（例えば、マルチキャスト）をサポートしないエリアに移動しており、または、複数のページング障害があり、それらのうちの１または複数が発生していることがある。
【０１４３】
次に図８を参照すると、ＭＭＥ通信プロシージャ８００が示されている。ＭＭＥ通信プロシージャ８００では、ＭＭＥは、ＩＷＦエンティティによってグループアプリケーションサーバと通信し、ユーザステータスを更新してもよい。この更新は、例えば、デタッチメントが検出されたときに行われてもよい。グループサーバは、グループアプリケーションサーバとも称されてもよい。
【０１４４】
ＵＥ内のグループアプリケーションは、グループアプリケーションサーバに登録してもよい。これは、アプリケーションレイヤプロシージャであってもよく、３ＧＰＰネットワークに透過的であってもよい。さらに、グループアプリケーションは、それがグループを登録した／これに参加したことをＵＥ（例えば、ＮＡＳレイヤ）に通知してもよい。グループＩＤ、グループメンバＩＤ、グループサーバ名（例えば、完全修飾ドメイン名（ＦＱＤＮ）、ユニフォームリソース識別子（ＵＲＩ）など）、グループサーバアドレス（ＩＰアドレス／ポート番号）、または他の任意の情報などの、登録されたグループについての情報がＵＥに提供されてもよい。
【０１４５】
そのうえ、ＵＥは、登録されたグループ情報でＭＭＥを更新してもよい。ＭＭＥは、ＵＥコンテキストに情報を記憶してもよい。このプロシージャは、例えば、既存のＴＡＵプロシージャまたは他のＮＡＳプロシージャと組み合わされてもよい。特定のＮＡＳプロシージャが、この目的のために設計されてもよい。
【０１４６】
デタッチ要求が受信されるときにＵＥがネットワークからデタッチする場合、および／またはＵＥが異なるグループアプリケーションサーバにすでに登録していた場合、ＭＭＥは、ＩＷＦエンティティにグループステータス更新メッセージを送信してもよい。グループステータス更新メッセージでは、グループ情報が提供されてもよい。この情報は、例えば、グループＩＤ、グループメンバＩＤ、グループサーバ名／アドレスなどを含んでもよい。それは、任意の新たなステータス情報（例えば、「到達不可能」）、ステータス変更の理由（例えば、「デタッチ」）なども含んでもよい。
【０１４７】
グループサーバアドレスがグループステータス更新メッセージ内で提供されない場合、ＩＷＦエンティティは、ＤＮＳにグループサーバ名について問い合わせてよい。したがって、ＩＷＦエンティティは、当該グループアプリケーションサーバの宛先アドレス／ポートを取得してもよい。ＩＷＦエンティティは、グループステータス更新メッセージを適切なグループアプリケーションサーバに転送してもよい。グループアプリケーションサーバは、それに応じて、そのレコードを更新してもよい。
【０１４８】
３ＧＰＰネットワーク支援グループインビテーション／通知
【０１４９】
本明細書で説明されるように、グループアプリケーションサーバは、グループメンバに到達することが可能でない場合がある。この場合、グループアプリケーションサーバは、３ＧＰＰネットワークに作用して、ユーザにインビテーションまたは通知を転送してもよい。したがって、ユーザは、グループを登録／これに参加することを開始してもよい。３ＧＰＰネットワークがグループユーザにインビテーション／通知を送信することができる方法は、ページングによるもの、ＤＬ  ＮＡＳメッセージによるもの、およびＳＭＳによるものを含んでもよいが、それらに限定されない
【０１５０】
ＵＥ位置報告は、ＭＢＭＳブロードキャスト領域を最適化するために、ダウンストリームＥＰＳ制御ノードをアクティブ化／非アクティブ化するために、および／またはユーザが、加入されたＧＣＳＥサービスエリア内にいてよいかどうか判定するために、ネットワークによって使用されてもよい。異なるグループのためのサービスエリアは異なってよく、グループ通信を送信するセルの数も、異なる時間で異なってよい。ＲＲＣ−ＣＯＮＮＥＣＴＥＤへの位置報告／遷移を開始するためにＵＥをトリガするための構成は、例えば、ＵＥにセルのリストをプロビジョニングするネットワークによって設けられてもよい。セルは、グループ通信配信の境界を定義してもよい。ＵＥ１は、構成に基づいて境界領域内でそれ自体を報告してもよい。ブロードキャストマルチキャストサービスセンタ（ＢＭ−ＳＣ）は、隣接するＭＢＳＦＮエリアを制御する追加ダウンストリームノード内のＭＢＭＳベアラをアクティブ化してもよい。同一の構成に基づいて後で同一のエリア内に位置付けされたＵＥ２は、それがもはや必要でないとしても、同一のプロシージャを繰り返してもよい。これを避けるために、グループアプリケーションサーバは、境界構成を変更するために、すべてのグループメンバとユニキャスト通信を実行しなくてよい。
【０１５１】
ＵＥがその位置を報告する構成は、ＭＢＭＳリソース上での送信を含んでもよい。一実施形態では、構成メッセージ（例えば、アプリケーションレベル）は、マルチキャストトラフィックチャネル（ＭＴＣＨ：Multicast Traffic channel）において、ＧＣＳＥグループのものと同一の一時移動グループ識別（ＴＭＧＩ：Temporary Mobile Group Identity）を使用して、ＭＢＭＳセッションＩＤとともに送信されてもよい。メッセージの存在は、ＴＭＧＩのためのグループ通信がＭＢＳＦＮエリアのために構成されることを暗示することができる。したがって、これは、グループ通信がサイレントのとき、アイドル状態のＵＥがＧＣＳＥ  ＡＳと連絡するのを防止することができる。ＭＢＭＳセッションＩＤは、構成メッセージのバージョンを暗黙的に表すことができる（同様に、Ｆｉｌｅ  Ｄｅｌｉｖｅｒｙ  ｏｖｅｒ  Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ  Ｔｒａｎｓｐｏｒｔ（ＦＬＵＴＥ））では、異なるセッションＩＤは、異なるファイルを表すことができる）。これは、位置報告構成が既存のＭＢＭＳ通知機構に基づいて変化した場合、ＭＴＣＨをＵＥが読み取ること、さらにはマルチキャストチャネル制御（ＭＣＣＨ）を防止することができる。境界構成は、ブロードキャスト構成メッセージを変更することによって変更されてもよい。これは、エリア内にないＵＥの再構成を防止することができる。構成は、グループが動作することができるすべての考えられる位置ではなく、エリアに関連する情報を伝達することのみが必要となることがある。
【０１５２】
構成メッセージは、トラッキングエリアコード（ＴＡＣ）に類似したコードを含んでもよく、ＴＡＣは、アプリケーション／ＢＭ−ＳＣ／ＰＬＭＮによって記述されてもよい。ＧＣＳＥ  ＡＳとの前回の連絡は、ＧＣＳＥ  ＡＳと連絡するようにＵＥをトリガしてもよいので、メッセージ内に出現するコードは、ＵＥによって覚えられたコードに合致しなくてよい。
【０１５３】
ＵＥ  ＥＰＳ位置のシグナリング
【０１５４】
ＧＣＳＥ  ＡＳは、ＵＥ  ＥＰＳの位置を複数の方法で取得してもよい。位置変更報告は、ＧＣＳＥ  ＰＤＮ接続のために構成されてもよい。ＥＰＳモビリティ管理（ＥＭＭ）−ＣＯＮＮＥＣＴＥＤに遷移することによって、ＵＥは、ＧＣＳＥ  ＰＤＮ接続のＰＧＷに位置報告をトリガしてもよい。ＩＰ−ＣＡＮ用に構成されたイベントトリガに基づいて、ＰＧＷは、ＵＥのポリシ・変更ルール機能（ＰＣＲＦ：Policy and Charging Rules Functions）に、その後ＧＣＳＥ  ＡＳに、ＵＥの位置を報告してもよい。ＵＥのＰＣＲＦは、位置がＵＥのＧＣＳＥに対する加入によって許可されるかどうかを示してもよい。ＧＣＳＥ  ＡＳは、ＵＥのＥＰＳ位置情報を理解することが可能でないことがあり、それは、（グループＩＤ、ＰＬＭＮ）に対するグループＰＣＲＦに情報を転送してもよい。グループＰＣＲＦは、位置がグループ通信について許可されるかどうかを示してもよい。許可される場合、グループＰＣＲＦは、ＭＢＭＳ配信エリアを更新するためにＢＭ−ＳＣと連絡してもよい。
【０１５５】
あるいは、ＵＥ位置は、アプリケーションシグナリング（例えば、本明細書で説明される位置報告メッセージ内で示されたコード）を介してＧＣＳＥ  ＡＳに報告されてもよい。ＡＳは、そのような位置がＧＣＳＥに許可されるかどうかを単独で決定してもよい。あるいは、ＡＳは、位置情報で、ＭＢＭＳリソースを適切に承認およびセットアップするために、ＵＥのＩＰアドレス、ＰＬＭＮ、およびそのグループ識別に基づいて判定を行い、ＵＥに対するＰＣＲＦおよび／または（グループＩＤ、ＰＬＭＮ）に対するＰＣＲＦと連絡してもよい。
【０１５６】
グループ独立ＭＢＭＳ中継機
【０１５７】
ｅＭＢＭＳ受信が可能なＵＥは、ネットワーク中継機に対してＭＢＭＳ  ＵＥとして示してもよい。中継されるＵＥと関連付けられると、または示している間、中継されるＵＥは、それがどのＰＬＭＮに登録されているかを宣言してもよい。同一のＰＬＭＮのＴＭＧＩを監視するＧＣＳＥ  ＵＥは、対象のＴＭＧＩのトラフィックおよび／または制御メッセージを受信するために中継されるＵＥに登録してもよい。登録後、中継されるＵＥは、中継されるＵＥが登録したＴＭＧＩを含むカウント要求に応答してもよい。中継されるＵＥは、中継されるＴＭＧＩのためのＢＭ−ＳＣを使用するＧＡＡ  ＧＢＡ  ＭＩＫＥＹプロシージャに参加しなくてよい。
【０１５８】
登録中、中継しているＵＥは、中継されるＵＥとＧＣＳＥ  ＡＳ／ＢＭ−ＳＣとの間でアプリケーションレイヤシグナリングを直接トランスポートするために、中継されるＵＥに少なくともＩＰアドレスを提供してもよい。中継されるＵＥは、中継ＵＥによって提供されるＩＰアドレスを使用して、アプリケーションレイヤシグナリングを直接トランスポートしてもよい。あるいは、セッション継続性／ＰＣＣ相互作用のために、中継されるＵＥは、デュアルスタックモバイルＩＰｖ６（ＤＳＭＩＰｖ６）または他のＥＰＳがサポートされたＭＩＰ機構を呼び出して、中継されるＵＥとＧＣＳＥ  ＡＳ／ＢＭ−ＳＣとの間でシグナリングをトランスポートしてもよい。例えば、内部ＩＰアドレスは、ＧＣＳＥ  ＰＤＮ接続のＰＧＷによって割り当てられたＥＰＳアドレスであってもよい。さらに、外部ＩＰアドレスは、中継ＵＥによって割り当てられてもよい。中継されるＵＥのためのＰＧＷは、中継ＵＥの位置を判定するために、ＰＣＲＦ／ＡＳに外部ＩＰアドレスを報告してもよい。
【０１５９】
ＭＢＭＳトラフィックを受信すると、ＩＰパケットはＵＥに中継されてもよい。中継されるＵＥは、中継ＵＥによって与えられたＩＰトランスポートによって、アプリケーションレイヤシグナリングを介してＢＭ−ＳＣ／ＧＣＳＥ  ＡＳを使用してＧｅｎｅｒｉｃ  Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  Ａｒｃｈｉｔｅｃｔｕｒｅ（ＧＡＡ）／Ｇｅｎｅｒｉｃ  Ｂｏｏｔｓｔｒａｐｐｉｎｇ  Ａｒｃｈｉｔｅｃｔｕｒｅ（ＧＢＡ）／ＭＩＫＥＹプロシージャを実行していた場合がある。中継されるＵＥは、ＢＭ−ＳＣ／ＧＣＳＥ−ＡＳによって生成されたいかなるＳＲＴＰ／ＳＲＴＣＰパケットも復号／認証することが可能であってもよい。
【０１６０】
３ＧＰＰ  ＮＡＳレイヤグループ管理
【０１６１】
本明細書で説明される方法は、３ＧＰＰ  ＮＡＳシグナリングを介してグループ管理を有効にすることができる。用語ＵＥはまた、別段明示的に言及されない限り、ユーザを指してもよいことが理解されよう。さらに、本明細書における開示は、ＰｒｏＳｅグループ通信とＧＣＳＥの両方に適用されてもよい。
【０１６２】
ユーザ加入情報者の修正
【０１６３】
ユーザ加入情報者を更新することができる方法は、限定するものではないが、以下のうちの任意の１または複数を含んでもよい。加入者情報は、ＵＥがグループ通信に参加することが許可されてもよいかどうかを示すように更新されてもよい。そうである場合、それは、どのグループまたはアプリケーションがＵＥに許可されてもよいかを示すように更新されてもよい。それはまた、ＵＥがグループ所有者であることが許可されるかどうか、またはＵＥが新たなグループを動的に作成する、グループにメンバを追加する、グループからメンバを削除する、もしくは開示される行為の任意の組み合わせが許可されるかどうかを示してもよい。加入情報者はまた、ＵＥが、グループ所有権を別のＵＥに移譲することが許可されてもよいかどうか、またはＵＥが、グループメンバＵＥの数およびステータスについての通知を要求することが許可されてもよいかどうかを示すように更新されてもよい。それはまた、ＵＥが、ネットワーク、グループメンバ、またはグループ所有者／管理者に通知することなくグループから出ることが許可されてもよいかどうかを示すように更新されてもよい。そのうえ、それは、ＵＥが送信することのみ、受信することのみ、もしくは他のグループメンバに送信し、これから受信することが許可されてもよいかどうか、ＵＥが、それがグループに追加されたとき通知されてもよいかどうか、および／またはグループから追加または取り除かれるためにＵＥの承諾が要求されてもよいかどうかを示すように更新されてもよい。さらに、加入情報者は、ＵＥが、作成または修正されてもよいグループの名前を修正または示唆できるかどうかを示すように更新されてもよい。そのうえ、前述のいずれかはＰＬＭＮ間（inter-PLMN）の場合に追加されてもよい、例えば、加入情報者は、ＵＥがグループを作成し、別のＰＬＭＮからＵＥを追加（または取り除く）ことが許可されてもよいかどうかを示すように更新されてもよい。前述のいずれも、任意の組み合わせで使用されてもよい。
【０１６４】
提案された加入情報者への追加は、ＵＥにサービスするＣＮノード、例えばＭＭＥおよび／またはＰｒｏＳｅサーバに、ＨＳＳによって転送されてもよい。ＵＥの登録中、ＭＭＥは、ＵＥのコンテキストをＨＳＳから取り出してもよい。これは、提案された情報のいずれをも含んでもよい。例えば、ＨＳＳは、上記のうちのいずれかを新たなコンテナすなわち情報要素（ＩＥ）に含んでもよく、ＩＥは「近接サービスＩＥ」と呼ばれてよい。近接サーバは、ＨＳＳからＭＭＥに送信されてもよい更新位置確認応答メッセージに含まれてよい。あるいは、ＨＳＳは、ＨＳＳから加入情報者を要求してもよい、システム内の他のノード（例えば、ＰｒｏＳｅサーバ）の情報を含んでもよい。列挙された情報は、ＭＭＥにおいてローカルに構成されてもよい。
【０１６５】
ＭＭＥは、列挙された情報のいずれかをＵＥに転送してもよい。これは、任意のＮＡＳメッセージに新たなＩＥを含めることによって行われてもよい。例えば、ＰｒｏＳｅ  ＩＥは、ＵＥに送信することができる、アタッチアクセプトメッセージ（Attach Accept message）またはＴＡＵアクセプトメッセージ（TA Accept message）に含まれてよい。そのうえ、ＭＭＥは、ＥＭＭ情報（ＮＡＳメッセージ）を使用して、列挙された情報のいずれかをＵＥに送信することができる。
【０１６６】
ＭＭＥはまた、開示されている情報のいずれかを少なくとも２つの目的でｅＮＢに送信してもよい。第１に、そのような送信は、情報をＵＥに配信する方法であってもよい。第２に、制御がｅＮＢでアンカリングされる場合、ｅＮＢは、この送信を使用してグループ動作を管理してもよい。
【０１６７】
したがって、グループ管理を目的とした、任意の情報（本明細書で列挙される情報など）の（例えば、ＭＭＥからの）受信時、ｅＮＢは、以下の動作のいずれかを実行してもよい。ｅＮＢは、既存のＲＲＣメッセージまたは新たなＲＲＣメッセージによって、情報をＵＥに転送してもよい。例えば、ｅＮＢは、ＲＲＣ接続再構成などの既存のＲＲＣメッセージ内で、ＰｒｏＳｅ  ＩＥコンテナを送信してもよい。さらに、ｅＮＢは、それがグループ管理および通信を制御することができるように、提供された情報を維持してもよい（例えば、ＭＭＥは、新たなＳ１ＡＰメッセージまたは既存のＳ１ＡＰメッセージを介してｅＮＢに情報を提供してもよい）。これは、グループ通信および管理が、ＵＥと協調したｅＮＢの責任であってもよいことを仮定してもよい。例えば、ＵＥは、ｅＮＢが、通信のためのグループと、関与するＵＥが同一のｅＮＢ内でサービスされてもよい位置を作成することを要求してもよい。したがって、受信された情報に基づいて、ｅＮＢは、ＵＥからの要求を受け付け、または拒否してもよい。
【０１６８】
さらに、ＵＥは、グループを作成し、またはグループのメンバシップを修正することを要求していることを示すために、新たなＲＲＣメッセージまたは既存のＲＲＣメッセージを送信してもよい。例えば、ＲＲＣメッセージは、グループのメンバを削除し、グループの他の任意の通信態様を修正するなどのインジケーションであってもよい。ｅＮＢは、受信された加入情報者またはローカル構成情報に基づいて、要求を受け付けまたは拒否してもよい。ｅＮＢはまた、新たなＲＲＣメッセージまたは既存のＲＲＣメッセージに応答してもよい。これは、要求の結果と、結果が到達された理由を記述する原因コードとを示してもよい。
【０１６９】
本明細書におけるグループ管理に関する開示は、ＵＥとＭＭＥとの間で説明されてもよい。しかしながら、本開示は、ＵＥとｅＮＢとの間の相互作用に等しく十分に適用されてもよい（例えば、ｅＮＢは、グループに関連した通信および管理に関するルールおよびポリシを施行することを担当するエンティティと考えられてもよい）ことが理解されよう。しかしながら、この場合、ＵＥとｅＮＢの相互作用は、ＲＲＣメッセージ（または下位レイヤシグナリング、例えば、ＭＡＣシグナリング）上で実行されてもよい。したがって、グループ管理に関する、情報および／またはＵＥおよびＭＭＥによってとられる動作のタイプは、ＵＥとｅＮＢとの間で（例えば、ＲＲＣまたは下位レイヤシグナリングを経由して）相互作用が行われる場合にも適用されてもよい。
【０１７０】
そのうえ、ＵＥは、グループ通信において動作するために、その能力および／またはローカル構成（もしあれば）を示してもよい。さらに、ＵＥは、本明細書で列挙された、動作のいずれかを実行するまたは情報のいずれかを処理するために、その能力および／または構成を示してもよい。例えば、アタッチプロシージャの間、ＵＥは、グループ通信において動作するために、その能力および／または構成を示してもよい。さらに、それは、グループ所有者として動作するための構成を有してもよい。それはまた、グループのメンバを追加または削除するなどのための構成を有してもよい。
【０１７１】
グループ管理のためのＵＥおよびネットワーク相互作用
【０１７２】
本明細書で説明されるように、シグナリングの多数のプロシージャおよびタイプが、グループ管理のためにＵＥとネットワークとの間で実行されてもよい。プロシージャはＵＥおよびＭＭＥに関して説明されてもよく、ＵＥとＭＭＥの両方は、通信にＮＡＳプロトコルを使用してもよく、プロシージャはまた、ＵＥとシステム内の他の任意のノードとの間で適用してもよい。例えば、それらは、ｅＮＢとＰｒｏＳｅサーバとの間に適用されてもよい。使用することができるプロトコルは、ＵＥおよびＭＭＥ通信のために提案することができる情報またはインジケーションのいずれかを含むように適合／修正されてもよい。さらに、提案されたインジケーション（要求など）のいずれかの受信によりＭＭＥによってとられる動作は、開示されているインジケーション、要求などを受信することができる他のノードにも適用されてもよい。例えば、ＵＥが、新たなＮＡＳメッセージまたは修正されたＮＡＳメッセージを使用してグループメンバを削除するための要求を送信して、ＭＭＥがターゲットメンバを削除する場合、ＵＥがＰｒｏＳｅサーバなどの別のエンティティと通信する場合に類似のプロシージャが適用されてもよい。
【０１７３】
グループ管理のためのＵＥの振舞い／プロシージャ
【０１７４】
ＵＥは、以下のプロシージャのいずれかを開始するように構成されてもよい。そのうえ、ＵＥは、それが、以下のプロシージャのいずれかが実行されてもよいことを示すルールおよび／またはポリシを受信した後、そのプロシージャを実行してもよい。ルール／ポリシは、ＮＡＳを介して（例えば、ＭＭＥによって）提供されてもよく、または、情報は、例えばアプリケーション固有シグナリングを使用するアプリケーションレイヤにおいて、ＡＮＤＳＦ、ＯＭＡ  ＤＭ、ＳＭＳ、または他の上位レイヤ方法を介してＵＥに提供されてもよい。さらに、ルール／ポリシは、ＵＥおよびサーバ通信（ユーザ制御プレーンおよび／または制御プレーン）のために実施されてもよい通信プロトコル、例えばＵＥとＰｒｏＳｅサーバとの間に存在するＰＣ５インタフェースを使用して、ＰｒｏＳｅサーバによって提供されてもよい。
【０１７５】
ネットワークへのグループ管理要求送信
【０１７６】
ＮＡＳプロシージャは、グループ管理を扱うために使用されてもよい。ＮＡＳメッセージは、近接サービス要求（Proximity Service Request）と称されてもよく、近接サービス要求は、アイドルモードまたは接続されたモードから開始されてもよく、すなわち、メッセージは、第１のＵＥ  ＮＡＳメッセージとして送信されてもよい。メッセージは、目的がグループ管理であることを示すフィールドを含んでもよい。例えば、要求は、グループを作成する、ＵＥメンバを追加する、ＵＥメンバを取り除くなどのために使用されてもよい。さらに、ＵＥは、要求によって影響することがあるターゲットＵＥの識別情報を示してもよい。ターゲットＵＥ  ＩＤは、送信元ＵＥが認識することができる近接ＩＤであってもよく、または、ソースＵＥがターゲットＵＥを識別するために使用することができる他の任意のＩＤ（おそらくアプリケーションレイヤユーザＩＤ）であってもよい。
【０１７７】
そのうえ、送信元ＵＥは、それに対して要求が送信されるアプリケーションを（例えば、アプリケーションＩＤを使用して）識別してもよい。これは、オペレータは異なるアプリケーションに対して異なるルールを有してもよいので、要求を許可することができるかどうかを検証するために受信側ノード（例えば、ＭＭＥまたは近接サーバ）によって使用されてもよい。開示されるメッセージは、他の目的にも、例えば、識別されたグループの一部であってもよいアクティブなＵＥのリスト／数を要求するために、使用されてもよい。機能はまた、既存のＮＡＳメッセージを使用して実施されてもよい。しかしながら、これは、特定の動作を要求するために、例えば、グループを作成するために、グループからＵＥを削除するなどのために、新たなフィールドの追加を要求してもよい。ＵＥは、要求を行うことができるグループの優先度レベルも示してもよい。例えば、イベント、ユーザ入力、ローカル構成、またはグループ識別子／アプリケーションに基づいて、ＵＥは、要求が高優先度を有することを示してもよい。これは、通常であれば他の通常の優先度要求について検証される条件のすべてを検証する必要なく、プロシージャを実行するように受信側ノード（例えば、ＭＭＥ）をトリガしてもよい。
【０１７８】
ＵＥは、要求が送信されるグループの名前も含んでもよい。名前は、人間が読むことができる名前であってもよい。受信者ノード（例えば、ＭＭＥ）は、グループコンテンツに名前を保存してもよい。それは、他のＵＥがひとたびメンバになると、それらに名前を転送してもよい。ＵＥはまた、名前を使用して、グループに関連する任意の情報をユーザに表示してもよい。さらに、要求（例えば、グループを作成する、ＵＥを削除する、ＵＥを追加する、グループ内のアクティブなＵＥの数を要求する、ＵＥがグループに入るまたはこれから離れるとき通知を要求するなど）は、近接サーバまたは他の任意のノード（例えば、アプリケーションサーバ）に送信されてもよい。
【０１７９】
ネットワークへのグループ管理要求送信
【０１８０】
ＵＥは、以下のいずれかが発生したとき、グループ管理の要求をネットワーク（例えば、ＭＭＥ、近接サーバ、アプリケーションサーバ、ＭｕＳｅエンティティなど）に送信してもよい。例えば、ＵＥは、それが、ネットワークがグループ通信をサポートするという明示的なインジケーションを受信したとき、それが、ＡＮＤＳＦ、ＯＭＡ  ＤＭ、もしくはアプリケーションレイヤを介して要求を開始するための明示的な通知を受信したとき、または、そのようにするための明示的なインジケーションをそれが近接サーバから受信したとき、要求を送信してもよい。ＵＥはまた、ＵＥが、グループ通信（ＰｒｏｓｅまたはＧＣＳＥ）に使用することができるアプリケーションをアクティブ化したとき、ユーザが、グループ通信を開始するための、またはグループを作成する、グループを修正する（追加する、削除する）などの要求を（ユーザインタフェース）を介して入力したとき、ネットワークにグループ管理の要求を送信してもよい。さらに、ＵＥは、公安のケースではＵＥが（構成、インジケーションを介して、またはハードウェア入力を介して）グループ通信モードに入るとき、またはＵＥが、グループ通信がサポートすることができるエリアに入るとき、そのような要求を送信してもよい。さらに、ＵＥは、特定のアプリケーションの要求を送信してもよい。
【０１８１】
ＵＥが入り、要求を送信することができる、グループ通信をサポートするエリアは、例えば、ｅＮＢ、セル、セルのグループ、少なくとも１つのトラッキングエリア（コード）、ＣＳＧなどであってもよい。さらに、ＵＥは、それが受信することができるブロードキャスト通知からの、エリア内のサービスのサポートを示す事前構成された情報から、サポートについて認識することができる。ＵＥはまた、ＮＡＳメッセージまたは他のレイヤメッセージ内の、それが受信することができる専用通知からのサポートについて認識することができる。
【０１８２】
グループ管理要求の受信時のＭＭＥの振舞い
【０１８３】
グループ管理要求を受信する任意のノード（例えば、ＭＭＥ、近接サーバなど）は応答してもよい。グループ管理の要求は、ＵＥ、ＭｕＳｅ、ＰｒｏＳｅサーバ、ＧＣＳＥ  ＡＳ、またはシステム内の他の任意のノードから受信されてもよい。
【０１８４】
ＭＭＥのネットワークルールおよびポリシの検証
【０１８５】
要求の受信時、ＭＭＥは、以下の動作のいずれかを実行してもよい。それは、要求元エンティティが、グループ管理（または通信）の要求を送信することが許可されるかどうか、グループを作成する要求がどこから生じたか、グループを削除するかどうか、グループメンバを追加するかどうか、グループメンバを削除するかどうか、またはグループ通信のメンバシップもしくはパラメータ（例えば、ＱｏＳ、優先度など）を修正するかどうかなどを判定してもよい。ＭＭＥは、加入情報者を検証して、要求元ＵＥが、要求を付与してもらうことが許可されているかどうか、送信元ＵＥがどこにあってもよいか、またはどのＵＥが要求によって影響されるかを判定してもよい。ＭＭＥはまた、要求を許可することができるかどうかを、別のノード（例えば、ＰｒｏＳｅサーバ、ＭｕＳｅなど）を使用して検証してもよい。任意選択で、それは、要求元ＵＥおよび／またはターゲットＵＥのために、特定のアプリケーションなどのために、前述のことを検証してもよい。それはまた、グループＩＤが有効であるか、またはそのような要求を許可してもらうかどうかを検証してもよい。さらに、ＭＭＥは、示されたアプリケーションが、そのような要求を付与してもらうことが許可されているかどうか、またはＰＬＭＮ間（inter-PLMN）のケースで、その要求が許可されてもよいかどうかを検証してもよい。前述の検証または他の検証の任意の組み合わせが実行されてもよい。そのうえ、検証および検証の組み合わせが、他の任意のノード、例えばＰｒｏＳｅサーバによって実行されてもよい。前述の検証が、ＭＭＥ以外のノードによって実行されるとき、同一のネットワークルールおよびポリシが適用されてもよい。
【０１８６】
ＭＭＥは要求を受け付けることができる
【０１８７】
要求が（例えば、本明細書で列挙された検証などの検証に基づいて）ネットワークによって受け付けられる場合、ＭＭＥは、以下の動作を実行してもよい。別のグループを作成する要求が受信されると、ＭＭＥは、新しく形成されたグループを含むようにＵＥコンテキストを更新してもよい。さらに、ＭＭＥは、ＵＥがグループ所有者／管理者であるというインジケーションを維持してもよい（これが許可され、または実際に当てはまる場合）。グループ所有者が別のＵＥである場合、ＭＭＥは、これが当てはまるという情報を維持してもよい。あるいは、ＭＭＥは、グループの所有権を示すようにグループ所有者のＵＥコンテキストのコンテキストを更新してもよい。
【０１８８】
ＭＭＥはまた、要求されたグループにグループＩＤを割り当ててもよい。この情報は、すでに要求に含まれてもよい。ＭＭＥはまた、システム内の別のノード、例えばＭｕＳｅ、ＰｒｏＳｅサーバなどに、グループの作成を通知してもよい。さらに、ＭＭＥは、他のＵＥのうちのどれがメンバであるかを示してもよく、または、グループのメンバであることが許可されてもよい。ＭＭＥは、要求内の任意の列挙されたＵＥを使用してもよく、または、ＭＭＥは、要求によって影響されることがあるＵＥ（例えば、グループのメンバであることが許可されるＵＥのリスト）を示すことができる構成（または、例えば、ＨＳＳからダウンロードされた情報）をローカルに取得してもよい。
【０１８９】
ＰｒｏＳｅサーバ（またはＭｕＳｅ）は、グループアプリケーションサーバに、グループを作成する要求（またはグループ作成の付与）を通知してもよい。それは、割り当てられたグループＩＤも含んでもよい。アプリケーションサーバは、ＭＭＥまたはＰｒｏＳｅサーバにインジケーションを確認応答してもよい。それはまた、作成されたグループに対して許可されるＵＥのリストを提供してもよい。ＰｒｏＳｅサーバは、インジケーションを確認応答してもよく、また、作成されたグループに許可されるＵＥのリストを提供してもよい。任意選択で、グループに対して許可されたＵＥのリストは、ＰｒｏＳｅサーバによって提供されるＵＥのリストに基づいてもよい。アプリケーションサーバ（またはＰｒｏＳｅサーバまたはＭｕＳｅ）は、グループの一部であることが許可されるＵＥと連絡して、それらにグループの作成を通知してもよい。したがって、各ＵＥは、グループに参加することを選択することができる。アプリケーションサーバ（またはＰｒｏＳｅサーバまたはＭｕＳｅ）は、アプリケーション名、グループＩＤ、グループ所有者の識別情報なども示してもよい。
【０１９０】
さらに、アプリケーションサーバ（またはＰｒｏＳｅサーバまたはＭｕＳｅ）は、グループについての以下の情報のいずれかを示してもよい。それは、例えば、グループに許可される媒体タイプ、グループ優先度、参加者の最大数、ＷＬＡＮを使用することができるか、および／またはＩＰフローが複数のＲＡＴ上で使用可能であるか（例えば、３ＧＰＰ  ＲＡＴ上のオーディオおよびＷＬＡＮ上のビデオなど）を示してもよい。それは、受信側ＵＥが、送信、受信、またはグループ所有者として機能することが許可されるかどうかも示してもよい。それは、フロア制御に関連するパラメータも示してもよく、例えば、ＵＥがデータを送信するために特定のスロットを有することができる時間パターンがあってもよい。アプリケーションサーバ（またはＰｒｏＳｅサーバまたはＭｕＳｅ）は、他の任意の情報を示してもよい。
【０１９１】
ＭＭＥは、新たなグループの形成を示すために、グループのメンバであることを許可／想定することができる他のＵＥと連絡してもよい。この情報は、ＭＭＥ情報によるものであってもよい。それは、ＨＳＳからダウンロードされるように、またはアプリケーションサーバもしくはＰｒｏＳｅサーバによって示されるように、ローカルであってもよい。ＭＭＥは、新たなＮＡＳメッセージを使用してもよいし、または既存のＮＡＳメッセージを使用してもよい。既存のＮＡＳメッセージは、これらのインジケーションおよび／またはグループ管理のための他のインジケーションを含むように更新されてもよい。ＭＭＥは、本明細書で列挙されたグループ／ＵＥについての他の任意の情報（媒体タイプ、優先度など）も含んでもよい。
【０１９２】
ＭＭＥは、ソース（すなわち、要求元）ＵＥに応答して、グループ作成の受け付けを示してもよい。ＭＭＥは、グループＩＤと、本明細書で説明されるグループについての他の任意の情報（例えば、グループ優先度、ＵＥがグループ所有者であってもよいかなど）も含んでもよい（または、前にＵＥによって提供されたかを確認してもよい）。ＭＭＥは、アクティブ（またはシステム内に登録された）であってもよいＵＥの数およびＩＤも示してもよい。さらに、ＭＭＥは、どのＵＥがグループの一部であることが許可されてもよいか、およびどのＵＥが許可されていなくてよいかを示してもよい。例えば、ＭＭＥおよび前に提供された（例えば、ソース／要求元ＵＥから）ターゲットＵＥのリストにおける情報に基づいて、ＭＭＥは、どのサブセットのＵＥがグループの一部であることが許可されてもよいかを示してもよい。この情報はまた、ＰｒｏＳｅサーバ、ＭｕＳｅ、またはアプリケーションサーバからＭＭＥに提供されてもよい。ＭＭＥは、どのＵＥがシステムにまだ登録されなくてよいかも示してもよい。
【０１９３】
要求が、グループを削除することである場合、ＭＭＥは、削除要求メッセージ内に示されたグループの関連した情報を除去するようにＵＥのコンテキストを更新してもよい。ＭＭＥはまた、以下のものなどの動作を実行してもよい。ＭＭＥは、システム内の別のノード、例えばＭｕＳｅ、ＰｒｏＳｅサーバなどにグループの削除を通知してもよい。さらに、ＭＭＥは、グループのメンバである他のＵＥを示してもよい。ＭＭＥは、要求内で列挙された任意のＵＥと通信してもよく、または、ＭＭＥは、要求によって影響されることがあるＵＥ（例えば、グループのメンバであってもよいＵＥのリスト）を示す構成（例えば、ＨＳＳからダウンロードされた情報）をローカルに有してもよい。
【０１９４】
ＰｒｏＳｅサーバ（またはＭｕＳｅ）は、アプリケーションサーバに、グループを削除する要求（またはグループ削除の付与）を通知してもよい。それは、削除されるグループＩＤも含んでもよい。アプリケーションサーバは、インジケーションを（例えば、ＭＭＥまたはＰｒｏＳｅサーバに）確認応答してもよく、また、グループ削除によって影響されることがあるＵＥのリストを提供してもよい。ＰｒｏＳｅサーバは、インジケーションも確認応答してもよいし、および／またはグループ削除によって影響されることがあるＵＥのリストを提供してもよい。ＵＥのリストは、任意選択で、ＰｒｏＳｅサーバによって提供されるＵＥのリストに基づいてもよい。アプリケーションサーバ（またはＰｒｏＳｅサーバまたはＭｕＳｅ）は、グループのメンバであってもよいＵＥと連絡して、それらにグループの削除を通知してもよい。
【０１９５】
ＭＭＥは、グループのメンバであることが想定され、またはグループのメンバであることが許可される他のＵＥと連絡してもよい。これは、ＭＭＥ情報により判定されてもよい。ＭＭＥ情報は、ＨＳＳからダウンロードされるように、またはグループの削除を示すためにアプリケーションサーバもしくはＰｒｏＳｅサーバによって示されるように、ローカルであってもよい。ＭＭＥは、新たなＮＡＳメッセージを使用してもよい。それは、このインジケーションおよび／またはグループ管理のための他のインジケーションを含むように更新することができる既存のＮＡＳメッセージも使用してもよい。
【０１９６】
要求は、アクティブなメンバに関する通知に対するものであってもよく、または、ＵＥがいつグループに入るかまたはこれから離れるかに関する通知に対するものであってもよい。ＵＥは、ＰｒｏＳｅサーバまたはアプリケーションサーバに要求を転送してもよく、したがって、ＵＥがグループに参加するとき、ＰｒｏＳｅサーバまたはアプリケーションサーバはＭＭＥに通知を送信してもよく、ＭＭＥは、それに応じてＵＥのコンテキストを更新してもよい。ＭＭＥはまた、グループメンバであることが許可／想定されるＵＥがグループに参加するとき、それらがＭＭＥに通知することを直接要求してもよい。通知要求は、新たなグループ作成のためのＮＡＳメッセージまたは別個のＮＡＳメッセージと組み合わされ得る。ＵＥからの通知は、ＮＡＳメッセージによるものであってもよい。
【０１９７】
優先度およびプリエンプションの扱い
【０１９８】
一実施形態では、ＧＣＳＥグループ内のユーザのＱＣＩ、優先度レベル、プリエンプション能力、およびプリエンプション脆弱性などの情報は、ユーザごとに割り当てられてもよい。ＤＬ通信トラフィックにマッピングされたベアラは、ユニキャストＵＬ通信トラフィックにマッピングされたベアラのものと異なるＱＣＩ、異なる優先度レベル、異なるプリエンプション能力、または異なるプリエンプション脆弱性などを有してもよい。別の実施形態では、ＧＣＳＥグループ内のユーザのＱＣＩ、優先度レベル、プリエンプション能力、およびプリエンプション脆弱性などは、ＵＬユニキャストトラフィックベアラごとに割り当てられてもよい。これらのベアラ属性は、同一のグループ通信インスタンス内の関与された異なるユーザに対して異なってもよい。ｅＮＢは、ユニキャストＵＬトラフィックにマッピングされたベアラの割り当ておよび保持優先度特性を使用してベアラごとにユーザに優先度を付けてもよい。一実施形態では、優先度レベル、プリエンプション能力、およびプリエンプション脆弱性値の範囲は、グループ通信ベアラと非グループ通信ベアラとの間の両方にまたがるように設定されてもよい。それは、ＵＬトラフィックおよびＤＬトラフィックの両方に関して設定されてもよい。別の実施形態では、ｅＮＢは、非グループ通信ベアラを経由してグループ通信ベアラに優先度を付けてもよい。特別なＱＣＩまたは予約されたＱＣＩは、グループ通信ベアラ、すなわち、ダウンリンクグループトラフィックにマッピングされてもよいベアラ、またはグループ通信をサポートする、ＵＬまたはＤＬ内のユニキャストトラフィックにマッピングされてもよいベアラに割り当てられてもよい。
【０１９９】
本明細書の開示に関連する参考文献は、非特許文献１、非特許文献６、非特許文献３、非特許文献７、および非特許文献４を含んでもよい。
【０２００】
通信方法は、通信グループのグループメンバとグループ通信システムとの間のアタッチメントをもたらすこと、グループメンバとグループ通信システムとの間のデタッチメントを検出すること、および３ＧＰＰシステムによりグループメンバとグループ通信システムとの間のアタッチメントを再確立することを含む。グループ利用可能性のインジケーションが、グループ通信システムによってグループメンバに提供される。ＧＰＰシステムはグループメンバの位置を判定し、判定された位置によるアタッチメントを再確立する。３ＧＰＰシステムは、決定された位置をグループ通信システムに送信し、グループ通信システムは、送信された位置によりアタッチメントを再確立する。
【０２０１】
ブロードキャスト領域は、判定された位置に従って最適化される。ＥＰＳノードは、決定された位置に従ってアクティブ化される。加入されたグループサービスエリア内にグループメンバがいるかの判定は、判定された場所によりなされる。グループメンバは、グループサービスエリア内に位置付けられる。グループサービスエリア内に複数のグループメンバが含まれるとき、複数のグループメンバのうちの少なくとも２人のグループメンバが、異なるグループ通信システムにアタッチする。
【０２０２】
グループ通信システムは、グループメンバがグループサービスエリアに入るとき、グループメンバに通知する。グループ通信内のグループアプリケーションは、グループメンバ内のグループアプリケーションに通知する。グループサービスエリアはＧＵＩＤを含む。ＧＵＩＤは、グループメンバまたはグループシステムによってブロードキャストされる。グループメンバは、ＧＵＩＤをグループ通信システムにブロードキャストする。複数のグループメンバのグループメンバは、互いにＧＵＩＤをブロードキャストする。グループメンバが、ＧＵＩＤを変換することができないとき、グループアプリケーションサーバはグローバル識別子を変換し、変換されたＧＵＩＤをグループメンバに提供する。
【０２０３】
グループサービスエリアは、グループサービスエリア内に位置付けられたいくつかのグループメンバに従って拡張および縮小する。グループサービスエリアは、グループメンバの位置に従って拡張および縮小する。グループサービスエリアは、複数のローカルホームネットワークを含む。グループサービスエリアは、複数のトラッキングエリア識別子を含む。グループサービスエリアは、複数のＰＬＭＮの各々からのセルを含む。グループサービスエリアは、複数のＣＳＧの各々からのセルを含む。グループサービスエリアは、複数のＭＢＳＦＮエリアの各々からのセルを含む。グループ通信システムはＧＣＳＥを備える。グループメンバおよびグループ通信システムは、それぞれのグループアプリケーションを含む。
【０２０４】
アタッチメントは、それぞれのグループアプリケーション間に提供される。グループメンバとグループ通信システムとの間のアタッチメントは、ＥＰＳにより再確立される。グループメンバとグループ通信システムとの間のアタッチメントは、ＭｕＳｅ機能により再確立される。グループメンバは、グループ通信をサポートしないＲＡＴネットワークのグループメンバによる選択によりグループ通信システムからデタッチする。グループメンバは、グループサービスエリアからのグループメンバの移動によりグループ通信システムからデタッチする。
【０２０５】
論理ノードは、グループ通信システムと３ＧＰＰシステムとの間に提供される。論理ノードはＩＷＦエンティティを含む。ＩＷＦエンティティは、３ＧＰＰシステムからの通信要求に許可を出す。ＩＷＦエンティティは、３ＧＰＰグループメンバ識別子とグループメンバ識別子との間で変換を実行する。ＩＷＦエンティティは、ＤＮＳ検索を実行して、通信グループサーバのアドレスを位置付ける。ＩＷＦエンティティは、グループ通信システムからの通信要求のために３ＧＰＰシステムを位置付ける。通信は、位置付けによりグループ通信システムから３ＧＰＰシステムに転送される。グループメンバは、グループサービスエリアのセル内で位置付けられる。セルはセル識別子を有する。グループ通信システムは、セル識別子によりアタッチメントを再確立する。セルは３ＧＰＰ識別子を有する。アタッチメントは、３ＧＰＰ識別子により再確立される。
【０２０６】
１つまたは複数の代表的な実施形態では、受信機、送信機、およびプロセッサのいずれかを含んでもよい装置は、方法を実行するように構成されてもよい。１つまたは複数の代表的な実施形態では、システムは、先の実施形態のうちの少なくとも１つに示された方法を実行するように構成されてもよい。
【０２０７】
特徴および要素は、上記で特定の組み合わせで説明されているが、当業者は、各特徴または要素が、単独で、または他の特徴および要素との任意の組み合わせで、使用できることを理解するであろう。さらに、本明細書で説明される方法は、コンピュータまたはプロセッサによる実行のために、コンピュータ可読媒体に組み込まれたコンピュータプログラム、ソフトウェア、またはファームウェアにおいて実施されてもよい。コンピュータ可読媒体の例は、電子信号（有線接続または無線接続を経由して送信される）およびコンピュータ可読記憶媒体を含む。コンピュータ可読記憶媒体の例は、限定するものではないが、リードオンリメモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、レジスタ、キャッシュメモリ、半導体メモリデバイス、内部ハードディスクおよび取外し可能なディスクなどの磁気媒体、光磁気媒体、ならびにＣＤ−ＲＯＭディスクおよびデジタル多用途ディスク（ＤＶＤ）などの光媒体を含む。ソフトウェアと関連するプロセッサは、ＷＴＲＵ、ＵＥ、端末、基地局、ＲＮＣ、または任意のホストコンピュータにおいて使用するための無線周波数トランシーバを実施するために使用されてもよい。
【図１Ａ】
2016536918.tif 000003
【図１Ｂ】
2016536918.tif 000004
【図１Ｃ】
2016536918.tif 000005
【図１Ｄ】
2016536918.tif 000006
【図１Ｅ】
2016536918.tif 000007
【図２】
2016536918.tif 000008
【図３】
2016536918.tif 000009
【図４】
2016536918.tif 000010
【図５】
2016536918.tif 000011
【図６】
2016536918.tif 000012
【図７】
2016536918.tif 000013
【図８】
2016536918.tif 000014
【図９】
2016536918.tif 000015
【国際調査報告】
2016536918.tif 000016
2016536918.tif 000017
2016536918.tif 000018