特許 6829295 サービス能力エクスポージャ機能におけるＭＢＭＳメンバシップ管理

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

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

(11)【特許番号】6829295

(24)【登録日】2021年1月25日

(45)【発行日】2021年2月10日

(54)【発明の名称】サービス能力エクスポージャ機能におけるＭＢＭＳメンバシップ管理

(51)【国際特許分類】

   H04W 4/06 20090101AFI20210128BHJP

   H04W 92/24 20090101ALI20210128BHJP

   H04W 76/40 20180101ALI20210128BHJP

【ＦＩ】

   H04W4/06 150

   H04W92/24

   H04W76/40

【請求項の数】11

【外国語出願】

【全頁数】29

(21)【出願番号】特願2019-180189(P2019-180189)

(22)【出願日】2019年9月30日

(62)【分割の表示】特願2017-551313(P2017-551313)の分割

【原出願日】2016年4月1日

(65)【公開番号】特開2020-14243(P2020-14243A)

(43)【公開日】2020年1月23日

【審査請求日】2019年10月29日

(31)【優先権主張番号】62/142,156

(32)【優先日】2015年4月2日

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

(73)【特許権者】

【識別番号】515222713

【氏名又は名称】コンヴィーダ ワイヤレス， エルエルシー

(74)【代理人】

【識別番号】110002147

【氏名又は名称】特許業務法人酒井国際特許事務所

(72)【発明者】

【氏名】スターシニック， マイケル エフ．

(72)【発明者】

【氏名】モハメド， アハメド

(72)【発明者】

【氏名】リ， チン

(72)【発明者】

【氏名】ルー， グアン

【審査官】 桑江 晃

(56)【参考文献】

【文献】 国際公開第２０１６／００７４９４（ＷＯ，Ａ１）

【文献】 国際公開第２０１５／２００８０１（ＷＯ，Ａ１）

【文献】 国際公開第２０１４／０４９４１８（ＷＯ，Ａ１）

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

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

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

ＳＡ ＷＧ１−４

ＣＴ ＷＧ１，４

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

【請求項1】

ネットワーク上の装置であって、前記装置は、
グループのメンバシップを構成するための実行可能命令を含む非一過性メモリと、
前記非一過性メモリに動作可能に結合されているプロセッサと
を備え、
前記プロセッサは、
デバイスを前記グループに追加するための要求をサーバから受信することと、
前記デバイスが前記グループに参加することが承認されているという返事を前記サーバに送信することと、
所定の条件が満たされると、前記サーバから受信したメッセージを前記デバイスに配信することであって、前記所定の条件は、前記グループ内でリッスンされているデバイスのパーセンテージ又は数、設定時間が経過したこと、のいずれか又はそれらの組み合わせにより構成されることと、
を行うように構成されている、装置。

【請求項2】

前記プロセッサは、
クエリ要求を前記サーバから受信することと、
前記クエリ要求に基づいて、前記デバイスのステータスをチェックすることと、
をさらに行うように構成されている、請求項１に記載の装置。

【請求項3】

前記プロセッサは、コアネットワークを介して、前記デバイスがアクティブであるという前記デバイスの前記ステータスを受信するようにさらに構成されている、請求項２に記載の装置。

【請求項4】

前記プロセッサは、ブロードキャストまたはマルチキャスト通信についての情報を伴うトリガを前記デバイスに送信することをさらに行うよう構成されている、請求項１に記載の装置。

【請求項5】

前記情報は、アクセスポイント名、マルチキャストアドレス、グループ名、ＴＭＧＩ、ＳＣＳ−ＩＤ、およびそれらの組み合わせから選択される、請求項４に記載の装置。

【請求項6】

前記デバイスの前記ステータスは、参加済み、アクティブ、承認済み、およびそれらの組み合わせから選択される、請求項２に記載の装置。

【請求項7】

前記クエリ要求は、前記グループに参加することが承認された全デバイスを含む、請求項２に記載の装置。

【請求項8】

ネットワーク化されたシステムであって、前記システムは、
サーバと、
前記サーバと通信している装置と
を備え、
前記装置は、
グループのメンバシップを構成するための実行可能命令を含む非一過性メモリと、
前記非一過性メモリに動作可能に結合されているプロセッサと
を含み、
前記プロセッサは、
デバイスを前記グループに追加するための要求をサーバから受信することと、
前記デバイスが前記グループに参加することが承認されているという返事を前記サーバに送信することと、
所定の条件が満たされると、前記サーバから受信したメッセージを前記デバイスに配信することであって、前記所定の条件は、前記グループ内でリッスンされているデバイスのパーセンテージ又は数、設定時間が経過したこと、のいずれか又はそれらの組み合わせにより構成されることと、
を行うように構成されている、システム。

【請求項9】

前記システムは、サービス能力エクスポージャ機能を含む、請求項８に記載のシステム。

【請求項10】

前記プロセッサは、コアネットワークを介して、前記デバイスがアクティブであるという前記デバイスのステータスを受信するようにさらに構成され、
前記コアネットワークは、ブロードキャストマルチメディアサービスセンタ、ＭＢＭＳゲートウェイ、ゲートウェイＧＰＲＳサポートノード、ホーム加入者サーバ、サービングゲートウェイ、パケットデータネットワークゲートウェイ、およびサービングＧＰＲＳサポートノードのうちの１つ以上のものを含む、請求項９に記載のシステム。

【請求項11】

グループのメンバシップを構成する方法であって、前記方法は、
デバイスを前記グループに追加するための要求をサーバから受信することと、
前記デバイスが前記グループに参加することが承認されているという返事を前記サーバに送信することと、
所定の条件が満たされると、前記サーバから受信したメッセージを前記デバイスに配信することであって、前記所定の条件は、前記グループ内でリッスンされているデバイスのパーセンテージ又は数、設定時間が経過したこと、のいずれか又はそれらの組み合わせにより構成されることと、
を含む、方法。

【発明の詳細な説明】

【技術分野】

【0001】

（関連出願の引用）
本願は、米国仮特許出願第６２／１４２，１５６号（２０１５年４月２日出願）に対する優先権を主張し、上記出願の開示は、その全体が参照により本明細書に引用される。

【0002】

（発明の分野）
本願は、サーバの代わりに、グループ内のデバイスを追跡するための装置および方法に関する。本願は、サーバの代わりに、グループ内のアクティブデバイスを決定するための装置および方法にも関する。

【背景技術】

【0003】

概して、デバイスまたはユーザ機器（ＵＥ）をマルチキャストグループに追加するために、サービス能力エクスポージャ機能（ＳＣＥＦ）が、サービス能力サーバ（ＳＣＳ）またはアプリケーションサーバ（ＡＳ）等のサーバによって要求される。デバイスまたはＵＥは、モバイルネットワークオペレータとコンタクトし得るが、デバイス上のアプリケーションは、モバイルネットワークオペレータがマルチキャストグループのメンバであるかどうかを把握していない。これに適応するために、２つのアプローチが、典型的には、採用される。１つのアプローチでは、サーバは、メッセージを各デバイスにユニキャストし、それをマルチキャストグループに知らせ得る。ユニキャストメッセージは、マルチメディアブロードキャストマルチキャストサービス（ＭＢＭＳ）の詳細を搬送し得る。別のアプローチでは、デバイスは、ユーザプレーンを経由して、ＳＣＥＦにコンタクトし、例えば、マルチキャストアドレスおよび一時的モバイルグループ識別（ＴＭＧＩ）を含む、グループに関する詳細を知り得る。しかしながら、デバイスは、ＳＣＥＦにコンタクトし、この情報をクエリすべきときを把握していない。

【0004】

それに加えた複雑性が、前述の２つのアプローチに関しても存在する。例えば、ＳＣＳ／ＡＳが、ＳＣＥＦにメンバをグループに追加することを要求するとき、ＳＣＥＦは、デバイスがグループに参加していると推測する。これは、特に、デバイスのポリシおよび能力がサーバによって要求されるそれらに一致しない場合、正確ではない場合がある。これは、デバイスが、グループに参加しない、またはグループに参加することを遅らせることを決定する場合において生じ得る。別個に、デバイスが、グループに参加していることもあるが、依然として、アクティブ化されていないこともある。すなわち、デバイスは、サーバからからのマルチキャストメッセージをリッスンしていない。

【0005】

前述のアプローチは、サーバが、デバイスへのＭＢＭＳの下層トランスポート詳細が分かっていることを要求する。具体的には、デバイスは、ＳＣＳ／ＡＳが、ＭＢＭＳデバイスコンテキストの具体的詳細、例えば、マルチキャストアドレス、ＴＭＧＩ等について把握していると仮定する。一方、ＳＣＳ／ＡＳは、ＭＢＭＳグループに参加するためのＳＣＳ／ＡＳからのユニキャストメッセージをリッスンするデバイス上のアプリケーションが存在すると仮定する。トランスポート詳細は、下層グループ配信およびトランスポート詳細をサーバから隠すという所望の目的から逸れる。

【発明の概要】

【課題を解決するための手段】

【0006】

本概要は、発明を実施するための形態において以下でさらに説明される、簡略化された形態における一連の概要を導入するように提供される。本概要は、請求された主題の範囲を限定することを意図していない。前述の必要性は、ネットワーク上のデバイスのメンバシップを管理するためのプロセスおよびシステムを対象とする本願によって、大いに満たされる。

【0007】

本願の一側面では、ネットワーク上のコンピュータ実装装置が、説明される。装置は、グループのメンバシップを構成するための実行可能命令を含む非一過性メモリを備えている。装置はまた、メモリに動作可能に結合されているプロセッサを含む。プロセッサは、デバイスをグループに追加するための要求をサーバから受信するように構成される。プロセッサはまた、デバイスがグループに参加するために承認されたことの返事をサーバに送信するように構成される。プロセッサはさらに、クエリ要求をサーバから受信するように構成される。さらに、プロセッサは、クエリ要求に基づいて、デバイスのステータスをチェックする。

【0008】

本願の別の側面では、サーバを含むネットワーク化されたシステムが、説明される。システムはまた、サーバと通信している装置を含む。装置は、グループのメンバシップを構成するための実行可能命令を含む非一過性メモリを含む。装置はまた、メモリに動作可能に結合されているプロセッサを含む。プロセッサは、デバイスをグループに追加するための要求をサーバから受信するように構成される。プロセッサはまた、デバイスがグループに参加するために承認されたことの返事をサーバに送信するように構成される。プロセッサはさらに、クエリ要求をサーバから受信するように構成される。さらに、プロセッサは、クエリ要求に基づいて、デバイスのステータスをチェックする。

【0009】

本願のさらに別の側面では、グループのメンバシップを構成するためのコンピュータ実装方法が、説明される。方法は、デバイスをグループに追加するための要求をサーバから受信するステップを含む。方法はまた、デバイスがグループに参加するために承認されたことの返事をサーバに送信するステップを含む。方法はさらに、クエリ要求をサーバから受信するステップを含む。方法はなおもさらに、クエリ要求に基づいて、デバイスのステータスをチェックするステップを含む。方法はなおもさらに、デバイスのステータスをサーバに送信するステップを含む。

【0010】

上に述べたように、その詳細な説明がより深く理解されるために、かつ当技術分野への本願の寄与がより深く認識されるために、本発明のある実施形態が、かなり広範に概略された。

【図面の簡単な説明】

【0011】

本願のより堅調な理解を促進するために、ここで、同一要素が同一数字で参照される、付随の図面を参照する。これらの図は、本願を限定するものと解釈されるべきではなく、例証にすぎないものであることを意図している。

【図1A】図１Ａは、マシンツーマシン（Ｍ２Ｍ）またはＩｏＴ通信システムの実施形態を図示する。

【図1B】図１Ｂは、Ｍ２Ｍサービスプラットフォームの本願の実施形態を図示する。

【図1C】図１Ｃは、例示的Ｍ２Ｍデバイスの系統図の本願の実施形態を図示する。

【図1D】図１Ｄは、例示的コンピューティングシステムのブロック図の本願の実施形態を図示する。

【図2】図２は、本願による、モバイルネットワークインフラストラクチャへのＢＭ−ＳＣ接続を図示する。

【図3】図３は、本願による、ＭＢＭＳマルチキャストサービスをアクティブ化するためのプロトコルを図示する。

【図4】図４は、本願による、サービス能力エクスポージャアーキテクチャを図示する。

【図5】図５は、本願による、ＳＭＳサービス能力エクスポージャを図示する。

【図6】図６は、本願のある実施形態による、グループメンバのＳＣＳ／ＡＳおよび識別によるグループベースのアドレスのためのアーキテクチャを図示する。

【図7】図７は、本願のある実施形態による、グループメンバのグループベースのアドレスおよび識別のためのプロトコルを図示する。

【図8】図８は、本願のある実施形態による、ＭＢＭＳベースのグループメッセージングアーキテクチャを図示する。

【図9】図９は、本願のある実施形態による、ＭＢＭＳベースのグループメッセージングのためのプロトコルを図示する。

【図10】図１０は、本願のある実施形態による、グループメンバシップを更新するためのプロトコルを図示する。

【図11】図１１は、本願のある実施形態による、図１０に関するユーザ機器のグラフィカルユーザインターフェースを図示する。

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

【0012】

発明を実施するための形態が、本明細書の種々の図、実施形態、および側面を参照して議論されるであろう。本説明は、可能な実装の詳細な実施例を提供するが、詳細は、実施例であることを意図し、したがって、本開示の範囲を限定しないことを理解されたい。

【0013】

本明細書における「一実施形態」、「ある実施形態」、「１つ以上の実施形態」、「ある側面」等の言及は、実施形態と関連して説明される特定の特徴、構造、または特性が、本開示の少なくとも１つの実施形態に含まれることを意味する。さらに、本明細書内の種々の場所における「実施形態」という用語は、必ずしも同一の実施形態を指しているわけではない。つまり、いくつかの実施形態によって提示され得るが、他の実施形態によって提示されない種々の特徴が説明される。

【0014】

本願は、グループへのデバイスの追加または更新のための新規技法およびシステムを説明する。そうすることによって、ＳＣＳ／ＡＳおよびＳＣＥＦは、グループに参加する権限が与えられ、アクティブ、例えば、リッスンしているデバイスを、グループに参加する権限が与えられているが、まだアクティブ化していない、例えば、リッスンしていないデバイスから区別し得る。特に、ＳＣＳ／ＡＳは、ＳＣＥＦに、１つ以上のデバイスがマルチキャストをリッスンするためにＭＢＭＳサービスをアクティブ化しているかどうかを尋ねることができる。

【0015】

別の実施形態は、好ましくは、下層トランスポート詳細、例えば、ＭＢＭＳトランスポート詳細が、ＳＣＳ／ＡＳから隠されているアーキテクチャおよびプロトコルを説明する。そうすることによって、ＳＣＳ／ＡＳは、データがグループメンバに配信されるであろう方法またはときを選択するタスクが、ＳＣＥＦによってハンドリングされるであろうため、より効率的に起動し得る。一実施形態では、ＳＣＥＦは、要求をデバイスに送信することによって、承認されたデバイスがＭＢＭＳサービスをアクティブ化し、サーバからマルチキャストアドレスのリッスンを開始するためのトリガまたは別の始動機構を採用し得る。例示的実施形態では、トリガは、サービスアドバタイズメントであり得る。

【0016】

（頭字語）
以下の頭字語が、以下の表１に提供されるように、本願全体を通して使用されるであろう。

【0017】

【表1】

【0018】

以下の用語は、別様に明示的に述べられない限り、以下に提供される当技術分野において理解されるようなその慣例的かつ通常の定義と一貫して、本願全体を通して使用されるであろう。

【0019】

（プラットフォーム）
本願は、アプリケーション対応プラットフォーム（ＡＥＰ）および接続デバイスプラットフォーム（ＣＤＰ）の両方のためのプラットフォーム機能性およびサポートを対象とすることが意図される。ＡＥＰは、ワールドワイドウェブおよびインターネットを含むアプリケーション対応層およびサービス層を含む。アプリケーション対応層は、限定ではないが、（ｉ）サービシングＡＰＩ、ルール／スクリプティングエンジン、（ｉｉ）ＳＤＫプログラミングインターフェース、および（ｉｉｉ）企業システム統合を含む。アプリケーション対応層は、限定ではないが、発見、解析、コンテキスト、およびイベントを含む、付加価値サービスも含み得る。ワールドワイドウェブおよびインターネットを含む、サービス層は、例えば、解析、請求、低レベルＡＰＩ、ウェブサービスインターフェース、セマンティックデータモデル、デバイス／サービス発見、デバイス管理、セキュリティ、データ収集、データ適応、集約、イベント管理、コンテキスト管理、最適化されたコネクティビティおよびトランスポート、Ｍ２Ｍゲートウェイ、ならびにアドレスおよび識別を含み得る。ＣＤＰは、コネクティビティ分析、使用分析／レポート／アラート、ポリシ制御、自動化されたプロビジョニング、ＳＩＭアクティブ化／非アクティブ化、およびサブスクリプションアクティブ化／非アクティブ化を含み得る。

【0020】

（一般的アーキテクチャ）
図１Ａは、１つ以上の開示される実施形態が実装され得る、例示的マシンツーマシン（Ｍ２Ｍ）、モノのインターネット（ＩｏＴ）、またはモノのウェブ（ＷｏＴ）通信システム１０の略図である。概して、Ｍ２Ｍ技術は、ＩｏＴ／ＷｏＴのための構築ブロックを提供し、任意のＭ２Ｍデバイス、ゲートウェイ、またはサービスプラットフォームは、ＩｏＴ／ＷｏＴのコンポーネントならびにＩｏＴ／ＷｏＴサービス層等であり得る。

【0021】

図１Ａに示されるように、Ｍ２Ｍ／ＩｏＴ／ＷｏＴ通信システム１０は、通信ネットワーク１２を含む。通信ネットワーク１２は、固定ネットワーク、例えば、Ｅｔｈｅｒｎｅｔ（登録商標）、Ｆｉｂｅｒ、ＰＬＣ、ＩＳＤＮ等、もしくは無線ネットワーク、例えば、ＷＬＡＮ、セルラー等、もしくは異種ネットワークのネットワークであり得る。例えば、通信ネットワーク１２は、音声、データ、ビデオ、メッセージング、ブロードキャスト等のコンテンツを複数のユーザに提供する、複数のアクセスネットワークから成り得る。例えば、通信ネットワーク１２は、符号分割多重アクセス（ＣＤＭＡ）、時分割多重アクセス（ＴＤＭＡ）、周波数分割多重アクセス（ＦＤＭＡ）、直交ＦＤＭＡ（ＯＦＤＭＡ）、単一キャリアＦＤＭＡ（ＳＣ−ＦＤＭＡ）等の１つ以上のチャネルアクセス方法を採用し得る。さらに、通信ネットワーク１２は、例えば、コアネットワーク、インターネット、センサネットワーク、工業制御ネットワーク、パーソナルエリアネットワーク、融合個人ネットワーク、衛星ネットワーク、ホームネットワーク、または企業ネットワーク等の他のネットワークを備え得る。

【0022】

図１Ａに示されるように、Ｍ２Ｍ／ＩｏＴ／ＷｏＴ通信システム１０は、インフラストラクチャドメインと、フィールドドメインとを含み得る。インフラストラクチャドメインは、エンドツーエンドＭ２Ｍ展開のネットワーク側を指し、フィールドドメインは、通常はＭ２Ｍゲートウェイの背後にあるエリアネットワークを指す。フィールドドメインは、プロキシを伴うＳＣＳ等のＭ２Ｍゲートウェイ１４およびＵＥデバイス等の端末デバイス１８を含む。任意の数のＭ２Ｍゲートウェイデバイス１４およびＭ２Ｍ端末デバイス１８が、所望に応じて、Ｍ２Ｍ／ＩｏＴ／ＷｏＴ通信システム１０に含まれ得ることが理解されるであろう。Ｍ２Ｍゲートウェイデバイス１４およびＭ２Ｍ端末デバイス１８の各々は、通信ネットワーク１２または直接無線リンクを介して、信号を伝送および受信するように構成される。Ｍ２Ｍゲートウェイデバイス１４は、無線Ｍ２Ｍデバイス（例えば、セルラーおよび非セルラー）ならびに固定ネットワークＭ２Ｍデバイス（例えば、ＰＬＣ）が、通信ネットワーク１２等のオペレータネットワークを通して、または直接無線リンクを通してのいずれかで、通信することを可能にする。例えば、Ｍ２Ｍデバイス１８は、データを収集し、通信ネットワーク１２または直接無線リンクを介して、データをＭ２Ｍアプリケーション２０またはＭ２Ｍデバイス１８に送信し得る。Ｍ２Ｍデバイス１８はまた、Ｍ２Ｍアプリケーション２０またはＭ２Ｍデバイス１８からデータを受信し得る。さらに、データおよび信号は、以下で説明されるように、Ｍ２Ｍ層２２を介して、Ｍ２Ｍアプリケーション２０に送信され、そこから受信され得る。一実施形態では、サービス層２２は、サービス能力サーバまたはアプリケーションサーバであり得る。Ｍ２Ｍデバイス１８およびゲートウェイ１４は、セルラー、ＷＬＡＮ、ＷＰＡＮ、例えば、Ｚｉｇｂｅｅ（登録商標）、６ＬｏＷＰＡＮ、Ｂｌｕｅｔｏｏｔｈ（登録商標）、直接無線リンク、および有線を含む、種々のネットワークを介して通信し得る。

【0023】

図１Ｂを参照すると、フィールドドメイン内の図示したＭ２Ｍサービス層２２は、Ｍ２Ｍアプリケーション２０、Ｍ２Ｍゲートウェイデバイス１４、Ｍ２Ｍ端末デバイス１８、および通信ネットワーク１２のためのサービスを提供する。Ｍ２Ｍサービス層２２は、所望に応じて、任意の数のＭ２Ｍアプリケーション、Ｍ２Ｍゲートウェイデバイス１４、Ｍ２Ｍ端末デバイス１８、および通信ネットワーク１２と通信し得ることが理解されるであろう。Ｍ２Ｍサービス層２２は、１つ以上のサーバ、コンピュータ等によって実装され得る。Ｍ２Ｍサービス層２２は、Ｍ２Ｍ端末デバイス１８、Ｍ２Ｍゲートウェイデバイス１４、およびＭ２Ｍアプリケーション２０に適用されるサービス能力を提供する。Ｍ２Ｍサービス層２２の機能は、種々の方法で実装され得る。例えば、Ｍ２Ｍサービス層２２は、ウェブサーバ、セルラーコアネットワーク、クラウド等で、実装されることができる。

【0024】

図示したＭ２Ｍサービス層２２と同様に、インフラストラクチャドメイン内にＭ２Ｍサービス層２２’が存在する。Ｍ２Ｍサービス層２２’は、インフラストラクチャドメイン内のＭ２Ｍアプリケーション２０’および下層通信ネットワーク１２’のためのサービスを提供する。Ｍ２Ｍサービス層２２’は、フィールドドメイン内のＭ２Ｍゲートウェイデバイス１４およびＭ２Ｍ端末デバイス１８のためのサービスも提供する。Ｍ２Ｍサービス層２２’は、任意の数のＭ２Ｍアプリケーション、Ｍ２Ｍゲートウェイデバイス、およびＭ２Ｍ端末デバイスと通信し得ることが理解されるであろう。Ｍ２Ｍサービス層２２’は、異なるサービスプロバイダによるサービス層と相互作用し得る。Ｍ２Ｍサービス層２２’は、１つ以上のサーバ、コンピュータ、仮想マシン（例えば、クラウド／計算／記憶ファーム等）等によって実装され得る。

【0025】

図１Ｂをさらに参照すると、Ｍ２Ｍサービス層２２および２２’は、多様なアプリケーションならびにバーティカルが活用することができるサービス配信能力のコアの組を提供する。これらのサービス能力は、Ｍ２Ｍアプリケーション２０および２０’がデバイスと相互作用し、データ収集、データ分析、デバイス管理、セキュリティ、課金、サービス／デバイス発見等の機能を果たすことを可能にする。本質的に、これらのサービス能力は、これらの機能性を実装する負担をアプリケーションから取り除き、したがって、アプリケーション開発を単純化し、市場に出す費用および時間を削減する。サービス層２２および２２’はまた、Ｍ２Ｍアプリケーション２０および２０’が、サービス層２２および２２’が提供するサービスと関連して、種々のネットワーク１２および１２’を通して通信することも可能にする。

【0026】

Ｍ２Ｍアプリケーション２０および２０’は、限定ではないが、輸送、健康および福祉、コネクテッドホーム、エネルギー管理、資産追跡、ならびにセキュリティおよび監視等、種々の産業におけるアプリケーションを含み得る。前述のように、デバイス、ゲートウェイ、および他のシステムのサーバを横断して起動するＭ２Ｍサービス層は、例えば、データ収集、デバイス管理、セキュリティ、課金、場所追跡／ジオフェンシング、デバイス／サービスの発見、および従来のシステムの統合等の機能をサポートし、サービスとしてのこれらの機能をＭ２Ｍアプリケーション２０および２０’に提供する。さらに、Ｍ２Ｍサービス層は、本願で議論され、図に図示されるように、ＵＥ、ＳＣＳ、およびＭＭＥ等の他のデバイスとインターフェースをとるようにも構成され得る。

【0027】

サービス層は、アプリケーションプログラミングインターフェース（ＡＰＩ）および下層ネットワーキングインターフェースの組を通して、付加価値サービス能力をサポートするソフトウェアミドルウェア層である。ＥＴＳＩ Ｍ２ＭおよびｏｎｅＭ２Ｍは両方とも、ＵＥがＰＳＭモードを制御および協調する方法を含み得るサービス層を使用する。ＥＴＳＩ Ｍ２Ｍのサービス層は、サービス能力層（ＳＣＬ）と称される。ＳＣＬは、Ｍ２Ｍデバイス（デバイスＳＣＬ（ＤＳＣＬ）と称される）、ゲートウェイ（ゲートウェイＳＣＬ（ＧＳＣＬ）と称される）、および／またはネットワークノード（ネットワークＳＣＬ（ＮＳＣＬ）と称される）内に実装され得る。ｏｎｅＭ２Ｍサービス層は、共通サービス機能（ＣＳＦ）（例えば、サービス能力）の組をサポートする。１つ以上の特定のタイプのＣＳＦの組のインスタンス化は、異なるタイプのネットワークノード、例えば、インフラストラクチャノード、ミドルノード、特定用途向けノード等の上にホストされ得るＳＣＳ等の共通サービスエンティティ（ＣＳＥ）と称される。さらに、本願で説明されるような方法は、サービス指向アーキテクチャ（ＳＯＡ）および／またはリソース指向アーキテクチャ（ＲＯＡ）を使用するＭ２Ｍネットワークの一部として実装されることができる。

【0028】

図１Ｃは、例えば、Ｍ２Ｍ端末デバイス１８またはＭ２Ｍゲートウェイデバイス１４等の例示的Ｍ２Ｍデバイス３０の系統図である。図１Ｃに示されるように、Ｍ２Ｍデバイス３０は、プロセッサ３２と、送受信機３４と、伝送／受信要素３６と、スピーカ／マイクロホン３８と、キーパッド４０と、ディスプレイ／タッチパッド／インジケータ４２と、非取り外し可能メモリ４４と、取り外し可能メモリ４６と、電源４８と、全地球測位システム（ＧＰＳ）チップセット５０と、他の周辺機器５２とを含み得る。ディスプレイ４２はまた、ユーザ機器のための要求を表示するグラフィカルユーザインターフェース（ＧＵＩ）を含み得る。これは、例えば、図１１に示される。Ｍ２Ｍデバイス４０は、実施形態と一致したままで、先述の要素の任意の副次的組み合わせを含み得ることが理解されるであろう。デバイスは、センサデータの組み込みセマンティック命名のための開示されるシステムおよび方法を使用するデバイスであり得る。Ｍ２Ｍデバイス３０はまた、本願に説明され、図に図示されるように、例えば、ＵＥ、ルータ、ゲートウェイ、およびサーバを含む他のデバイスとともに採用され得る。

【0029】

プロセッサ３２は、汎用プロセッサ、特殊目的プロセッサ、従来のプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアと関連する１つ以上のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、任意の他のタイプの集積回路（ＩＣ）、状態マシン等であり得る。プロセッサ３２は、信号符号化、データ処理、電力制御、入出力処理、および／またはＭ２Ｍデバイス３０が無線環境で動作することを可能にする任意の他の機能性を果たし得る。プロセッサ３２は、伝送／受信要素３６に結合され得る送受信機３４に結合され得る。図１Ｃは、プロセッサ３２および送受信機３４を別個のコンポーネントとして描写するが、プロセッサ３２および送受信機３４は、電子パッケージまたはチップにともに組み込まれ得ることが理解されるであろう。プロセッサ３２は、アプリケーション層プログラム（例えば、ブラウザ）および／または無線アクセス層（ＲＡＮ）プログラムならびに／もしくは通信を行い得る。プロセッサ３２は、例えば、アクセス層および／またはアプリケーション層等で、認証、セキュリティキー一致、ならびに／もしくは暗号化動作等のセキュリティ動作を行い得る。

【0030】

伝送／受信要素３６は、信号をＭ２Ｍサービスプラットフォーム２２に伝送するか、またはＭ２Ｍサービスプラットフォーム２２から信号を受信するように構成され得る。例えば、実施形態では、伝送／受信要素３６は、ＲＦ信号を伝送および／または受信するように構成されるアンテナであり得る。伝送／受信要素３６は、ＷＬＡＮ、ＷＰＡＮ、セルラー等の種々のネットワークならびにエアインターフェースをサポートし得る。実施形態では、伝送／受信要素３６は、例えば、ＩＲ、ＵＶ、もしくは可視光信号を伝送および／または受信するように構成されるエミッタ／検出器であり得る。さらに別の実施形態では、伝送／受信要素３６は、ＲＦおよび光信号の両方を伝送ならびに受信するように構成され得る。伝送／受信要素３６は、無線もしくは有線信号の任意の組み合わせを伝送および／または受信するように構成され得ることが理解されるであろう。

【0031】

加えて、伝送／受信要素３６は、単一の要素として図１Ｃで描写されているが、Ｍ２Ｍデバイス３０は、任意の数の伝送／受信要素３６を含み得る。より具体的には、Ｍ２Ｍデバイス３０は、ＭＩＭＯ技術を採用し得る。したがって、実施形態では、Ｍ２Ｍデバイス３０は、無線信号を伝送および受信するための２つ以上の伝送／受信要素３６（例えば、複数のアンテナ）を含み得る。

【0032】

送受信機３４は、伝送／受信要素３６によって伝送される信号を変調するように、および伝送／受信要素３６によって受信される信号を復調するように構成され得る。上記のように、Ｍ２Ｍデバイス３０は、マルチモード能力を有し得る。したがって、送受信機３４は、Ｍ２Ｍデバイス３０が、例えば、ＵＴＲＡおよびＩＥＥＥ８０２．１１等の複数のＲＡＴを介して通信することを可能にするための複数の送受信機を含み得る。

【0033】

プロセッサ３２は、非取り外し可能メモリ４４および／または取り外し可能メモリ４６等の任意のタイプの好適なメモリから情報にアクセスし、そこにデータを記憶し得る。非取り外し可能メモリ４４は、ランダムアクセスメモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、ハードディスク、または任意の他のタイプのメモリ記憶デバイスを含み得る。取り外し可能メモリ４６は、加入者識別モジュール（ＳＩＭ）カード、メモリスティック、セキュアデジタル（ＳＤ）メモリカード等を含み得る。他の実施形態では、プロセッサ３２は、サーバまたはホームコンピュータ上等のＭ２Ｍデバイス３０上に物理的に位置しないメモリから情報にアクセスし、それにデータを記憶し得る。

【0034】

プロセッサ３２は、電源４８から電力を受け取り得、Ｍ２Ｍデバイス３０内の他のコンポーネントへの電力を配布および／または制御するように構成され得る。電源４８は、Ｍ２Ｍデバイス３０に電力供給するための任意の好適なデバイスであり得る。例えば、電源４８は、１つ以上の乾電池バッテリ（例えば、ニッケルカドミウム（ＮｉＣｄ）、ニッケル亜鉛（ＮｉＺｎ）、ニッケル水素（ＮｉＭＨ）、リチウムイオン（Ｌｉ−ｉｏｎ）等）、太陽電池、燃料電池等を含み得る。

【0035】

プロセッサ３２は、Ｍ２Ｍデバイス３０の現在の場所に関する場所情報（例えば、経度および緯度）を提供するように構成されるＧＰＳチップセット５０にも結合され得る。Ｍ２Ｍデバイス３０は、実施形態と一致したままで、任意の好適な場所決定方法を介して場所情報を獲得し得ることが理解されるであろう。

【0036】

プロセッサ３２はさらに、追加の特徴、機能性、および／または有線もしくは無線接続を提供する、１つ以上のソフトウェアならびに／もしくはハードウェアモジュールを含み得る他の周辺機器５２に結合され得る。例えば、周辺機器５２は、加速度計、ｅ−コンパス、衛星送受信機、センサ、デジタルカメラ（写真またはビデオ用）、ユニバーサルシリアルバス（ＵＳＢ）ポート、振動デバイス、テレビ送受信機、ハンズフリーヘッドセット、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール、周波数変調（ＦＭ）ラジオユニット、デジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザ等を含み得る。

【0037】

図１Ｄは、例えば、図１Ａおよび１ＢのＭ２Ｍサービスプラットフォーム２２が実装され得る例示的なコンピュータシステム９０のブロック図である。コンピュータシステム９０は、コンピュータまたはサーバを備え得、主に、ソフトウェアの形態であり得るコンピュータ読み取り可能な命令によって制御され得、場所または手段を問わず、そのようなソフトウェアが記憶もしくはアクセスされる。そのようなコンピュータ読み取り可能な命令は、コンピュータシステム９０を起動させるように、中央処理装置（ＣＰＵ）９１内で実行され得る。多くの既知のワークステーション、サーバ、および周辺コンピュータでは、中央処理装置９１は、マイクロプロセッサと呼ばれる単一チップＣＰＵによって実装される。他のマシンでは、中央処理装置９１は、複数のプロセッサを備え得る。コプロセッサ８１は、追加の機能を果たすか、またはＣＰＵ９１を支援する、主要ＣＰＵ９１とは明確に異なる随意的なプロセッサである。ＣＰＵ９１および／またはコプロセッサ８１は、組み込みセマンティクスを伴うセンサデータのクエリ等の組み込みセマンティック命名のための開示されるシステムおよび方法に関連するデータを受信、生成、ならびに処理し得る。

【0038】

動作時、ＣＰＵ９１は、命令をフェッチ、復号、および実行し、コンピュータの主要データ転送パスであるシステムバス８０を介して、情報を他のリソースへ、およびそこから転送する。そのようなシステムバスは、コンピュータシステム９０内のコンポーネントを接続し、データ交換のための媒体を定義する。システムバス８０は、典型的には、データを送信するためのデータライン、アドレスを送信するためのアドレスライン、ならびにインタラプトを送信するため、およびシステムバスを動作するための制御ラインを含む。そのようなシステムバス８０の実施例は、ＰＣＩ（周辺コンポーネント相互接続）バスである。

【0039】

システムバス８０に結合されるメモリデバイスは、ランダムアクセスメモリ（ＲＡＭ）８２および読み取り専用メモリ（ＲＯＭ）９３を含む。そのようなメモリは、情報が記憶されて取り出されることを可能にする回路を含む。ＲＯＭ９３は、概して、容易に修正することができない、記憶されたデータを含む。ＲＡＭ８２に記憶されたデータは、ＣＰＵ９１または他のハードウェアデバイスによって読み取られ、または変更され得る。ＲＡＭ８２および／またはＲＯＭ９３へのアクセスは、メモリコントローラ９２によって制御され得る。メモリコントローラ９２は、命令が実行されると、仮想アドレスを物理的アドレスに変換する、アドレス変換機能を提供し得る。メモリコントローラ９２はまた、システム内のプロセスを単離し、ユーザプロセスからシステムプロセスを単離する、メモリ保護機能を提供し得る。したがって、第１のモードで作動するプログラムは、独自のプロセス仮想アドレス空間によってマップされるメモリのみにアクセスすることができ、プロセス間のメモリ共有が設定されていない限り、別のプロセスの仮想アドレス空間内のメモリにアクセスすることができない。

【0040】

加えて、コンピュータシステム９０は、ＣＰＵ９１からプリンタ９４、キーボード８４、マウス９５、およびディスクドライブ８５等の周辺機器に命令を伝達する責任がある周辺機器コントローラ８３を含み得る。

【0041】

ディスプレイコントローラ９６によって制御されるディスプレイ８６は、コンピュータシステム９０によって生成される視覚出力を表示するために使用される。そのような視覚出力は、テキスト、グラフィックス、動画グラフィックス、およびビデオを含み得る。ディスプレイ８６は、ＣＲＴベースのビデオディスプレイ、ＬＣＤベースのフラットパネルディスプレイ、ガスプラズマベースのフラットパネルディスプレイ、またはタッチパネルを伴って実装され得る。ディスプレイコントローラ９６は、ディスプレイ８６に送信されるビデオ信号を生成するために必要とされる、電子コンポーネントを含む。ディスプレイ８６は、組み込みセマンティクスを使用して、ファイルまたはフォルダ内のセンサデータを表示し得る。ディスプレイ８６はまた、例えば、図１１に示されるようなグラフィカルユーザインターフェースを表示し得る。さらに、コンピュータシステム９０は、図１Ａおよび１Ｂのネットワーク１２等の外部通信ネットワークにコンピュータシステム９０を接続するために使用され得る、ネットワークアダプタ９７を含み得る。

【0042】

（一般的ＩＰマルチキャスト（ＩＰｖ４およびＩＰｖ６））
別の実施形態によると、ＩＰマルチキャストアドレスは、単一送信側が、同一データを複数のリスナに送信することを可能にする。例えば、ＳＣＳ／ＡＳまたはＳＣＥＦ等の送信側は、データをマルチキャストＩＰアドレスに送信し、リスナは全て、同一マルチキャストアドレス上で受信する。ＩＰマルチキャストグループの１つの特徴は、アドレスが共有されることができることである。別の特徴は、多くのソースが情報を同一アドレスに送信することができることである。例示的実施形態では、ストリームまたはチャネルは、異なるＵＤＰポート番号で多重化されることができ、各マルチキャストリスナは、所望する情報を抽出することができる。

【0043】

（インターネットグループ管理プロトコル（ＩＧＭＰ））
ＩＧＭＰは、ＩＥＴＦ ＦＣ ３３７６，Ｉｎｔｅｒｎｅｔ Ｇｒｏｕｐ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ，Ｖｅｒｓｉｏｎ ３に定義されており、参照することによって組み込まれる。概して、ＩＧＭＰは、マルチキャストグループメンバシップを確立するためにホストとＩＰネットワーク上の隣接するルータとによって使用される、通信プロトコルである。それは、ＩＰｖ４システムでは、それらのＩＰマルチキャストメンバシップを近隣ルータにレポートするために使用される。ＩＧＭＰをサポートするシステムは、アプリケーションが、リッスンを所望するマルチキャストアドレスと、インターフェースをとるネットワーク、例えば、セルラー、Ｗｉ−Ｆｉ、Ｅｔｈｅｒｎｅｔ（登録商標）等とをシステムに伝えることを可能にするＡＰＩをアプリケーションにエクスポーズする。

【0044】

加えて、ＩＧＭＰは、ソースフィルタリングをサポートする。これはシステムが、特定のソースアドレス「のみ」または特定のソースアドレス「以外」からの特定のマルチキャストアドレスに送信されるパケットを受信することに関心があることをレポートするための能力である。デバイス上のアプリケーションが、リッスンを所望するマルチキャストアドレスを示すとき、デバイスは、フィルタを規定することもできる。

【0045】

さらに、２つの重要なタイプのＩＧＭＰメッセージ、すなわち、メンバシップレポートおよびメンバシップクエリが、存在する。メンバシップレポートは、それらが関心があるマルチキャストグループを近隣ルータにレポートするためにＩＰシステムによって使用される。メンバシップクエリは、近隣インターフェースのマルチキャスト受信状態をクエリするためにＩＰマルチキャストルータによって送信される。３つのタイプのクエリメッセージが、採用される。第１のタイプは、一般的クエリであり、クエリは、その近隣インターフェースの全てにおける完全マルチキャスト受信状態を知るためにルータによって送信される。言い換えると、どのマルチキャストメッセージが各インターフェース上で送信されるべきかを知るためのものである。第２のタイプは、グループ特定クエリであり、クエリは、特定のマルチキャストグループに関する受信状態を知るためにルータによって送信される。第３のグループおよびソース特定クエリは、任意の近隣インターフェースがソースの特定のリストによって特定のグループに送信されるパケットを受信することを所望するかどうかを知るためにルータによって送信される。

【0046】

（マルチキャストリスナ発見（ＭＬＤ））
ＭＬＤは、ＩＥＴＦ ＲＦＣ ３８１０，Ｍｕｌｔｉｃａｓｔ Ｌｉｓｔｅｎｅｒ Ｄｉｓｃｏｖｅｒ Ｖｅｒｓｉｏｎ ２（ＭＬＤｖ２）に定義されており、本明細書では、ＩＰｖ６に関して組み込まれる。ＭＬＤは、ＩＰｖ６のコンポーネントであり、直接アタッチされたリンク上のマルチキャストリスナを発見するために、ルータによって使用される。プロトコルは、別個のプロトコルを使用する代わりに、ＩＣＭＰｖ６に組み込まれる。加えて、ＭＬＤは、そのＩＰマルチキャストメンバシップを近隣ルータにレポートするためにＩＰｖ６システムにおいて使用される。ＭＬＤのＩＧＭＰとの類似性を前提として、ＩＧＭＰに対する任意の参考文献もまた、ＭＬＤに適用される。

【0047】

（マルチメディアブロードキャストマルチキャストサービス（ＭＢＭＳ））
ＭＢＭＳサービスは、３ＧＰＰ ＴＳ ２３．２４６ Ｍｕｌｔｉｍｅｄｉａ Ｂｒｏａｄｃａｓｔ／Ｍｕｌｔｉｃａｓｔ Ｓｅｒｖｉｃｅ；Ａｒｃｈｉｔｅｃｔｕｒｅ ａｎｄ Ｆｕｎｃｔｉｏｎａｌ Ｄｅｓｃｒｉｐｔｉｏｎに定義されており、本明細書に組み込まれる。ＭＢＭＢアーキテクチャの高レベル図は、図２に示されており、Ｍａｇｎｕｓ Ｏｌｓｓｏｎ、他による、ＥＰＣ ａｎｄ ４Ｇ Ｐａｃｋｅｔ Ｎｅｔｗｏｒｋｓ（Ａｃａｄｅｍｉｃ Ｐｒｅｓｓ，２０１３）にも見出されることができ、それも、全体として組み込まれる。図２に示されるように、コンテンツ２１０は、ＢＭ−ＳＣ２２０に提供される。コンテンツは、ラインＳＧｍｂ２１５または２ｇｉ−ｍｂ２１６を介して、ＭＢＭＳ−ＧＷ２３０に送信される。代替として、コンテンツは、ラインＳＧｉ２１７を通して、Ｐ−ＧＷ／Ｓ−ＧＷ２４０に送信される。ＭＢＭＳ−ＧＷ２２５からＵＥまたはデバイス２５０につながる通信は、ダウンリンク専用ＭＢＭＳブロードキャストとして説明される。一方、Ｐ−ＧＷ／Ｓ−ＧＷ２４０からＵＥ２５０への通信は、双方向データ接続として説明される。

【0048】

ＢＭ−ＳＣは、ＭＢＭＳセッションを制御するノードである。それは、ＭＢＭＳが特定のコンテンツをブロードキャストするために使用されるであろうことの通知を開始し、セッションに参加することを欲する端末に関連付けられた機能性を管理する。端末とＢＭ−ＳＣとの間の全相互作用は、ユニキャストを経由してハンドリングされる。概して、ＭＢＭＳサービスは、ユーザアウェアである。すなわち、セッションは、ユーザ毎ベースで制御される。ＢＭ−ＳＣの主要機能は、少なくとも、（ｉ）サービスアナウンスメント機能、（ｉｉ）キー管理機能、ならびに（ｉｉｉ）セッションおよび伝送機能を含む。

【0049】

ＵＥがＭＢＭＳをアクティブ化する方法に関するプロトコルは、例えば、図３に図示される。ステップの各々は、ローマ数字によって示される。特に、ステップ１は、ＵＥがそのデフォルトＰＤＮコンテキストをＳＧＳＮおよびＧＧＳＮと共にアクティブ化する方法を説明する。ステップ２では、ＵＥは、ＭＢＭＳサービスへの参加を試みる。グループへの参加の決定は、サービスアドバタイズメント（ここで示される）に応答し得る。アドバタイズメントは、限定ではないが、ＷＡＰプッシュおよびＳＭＳを含むプロトコルを介して、送信され得る。ステップ３−１７は、ＭＢＭＳのためのアクティブ化プロセスを説明する。特に、ステップ３は、ＧＧＳＮとＢＭ−ＳＣとの間の承認要求および応答を説明する。ステップ４では、ＭＢＭＢ通知要求が、ＧＧＳＮからＳＧＳＮに送信され、応答が、それを考慮して受信される。ステップ５では、ＳＧＳＮが、ＭＢＭＳコンテキストアクティブ化に対する要求をＵＥに送信する。ステップ６では、ＵＥは、ＭＢＭＳコンテキスト要求および情報をアクティブ化することによって、ＳＧＳＮを承諾する。ステップ７では、ＳＧＳＮは、通知拒否要求をＧＧＳＮに送信し得る、応答が、ＳＧＳＮに返信される。ステップ８に従って、セキュリティ機能が、ＵＥとＳＧＳＮとの間で伝送される。ステップ９では、トレースが、ＳＧＳＮとＲＡＮとの間で呼び出される。ステップ１０では、ＳＧＳＮは、ＭＧＭＳコンテキスト要求を作成する。ステップ１１は、ＧＧＳＮとＢＭ−ＳＣとの間のＭＢＭＳ承認要求および応答を伴う（上記ステップ３参照）。ステップ１２では、ＭＢＭＳ登録要求および応答が、ＧＧＳＮとＢＭＳＣとの間で伝送される。ステップ１３は、ＧＧＳＮからＳＧＳＮに送信されるＭＢＭＳコンテキスト応答の作成を伴う。その後、ステップ１４に従って、ＭＢＭＳ登録要求は、ＳＧＳＮからＧＧＳＮに送信され、応答がそこに送信され得る。ステップ１５は、ＭＢＭＳ ＵＥコンテキストをＲＡＮにプロビジョニングすることを伴う。トレースが、ステップ１６において呼び出され得る。最後に、ＵＥは、ＭＢＭＳコンテキスト承諾プロトコルをアクティブ化する（ステップ１７）。

【0050】

（ＳＡ２ ＡＥＳＥ ＴＲおよびＳＣＥＦ）
ＳＡ２ ＡＥＳＥ ＴＲは、参照することによってその全体として組み込まれる、３ＧＰＰ ＴＲ ２３．７０８，Ａｒｃｈｉｔｅｃｔｕｒｅ Ｅｎｈａｎｃｅｍｅｎｔｓ ｆｏｒ Ｓｅｒｖｉｃｅ Ｅｘｐｏｓｕｒｅにおいて対処されている。このアーキテクチャは、サービス能力エクスポージャフレームワーク（ＳＣＥＦ）に関する問題に対処する。ネットワークによるサービスのエクスポージャは、適切な承認を伴い、情報を読み出すこと、具体的サービスを要求すること、通知を受信すること、具体的パラメータの設定を要求すること等を行うために使用され得る能力の「ツールボックス」を作成する。図４は、ＳＣＥＦのための一般的アーキテクチャを図示する。図４における例証は、信頼ドメイン４００内のＳＣＥＦ４５０を描写する。信頼ドメイン４００は、適正なネットワークドメインセキュリティによって保護されるエンティティ４１０を対象とする。信頼ドメイン４００内のエンティティおよびインターフェースは全て、１つのモバイルオペレータの制御内にあり得る。代替として、エンティティは、モバイルオペレータと関係を有する信頼されたビジネスパートナによって制御され得る。ビジネスパートナは、別のオペレータまたは第三者であり得る。

【0051】

ＳＣＥＦは、３ＧＰＰネットワークインターフェースによって提供されるサービスおよび能力をセキュアにエクスポーズするための手段を提供する。ＳＣＥＦは、エクスポーズされたサービス能力の発見のための手段を提供する。ＳＣＥＦは、ＯＭＡ、ＧＳＭ（登録商標）Ａ、および、おそらく他の規格化団体によって定義される同種ネットワークアプリケーションプログラミングインターフェース、例えば、ネットワークＡＰＩ ４３０を通してネットワーク能力へのアクセスを提供する。ＳＣＥＦは、下層３ＧＰＰネットワークインターフェースおよびプロトコルからのサービスを抽象化する。

【0052】

ある実施形態によると、インターフェースを定義することは、ＳＣＥＦが、３ＧＰＰ内の新しいまたは既存の３ＧＰＰネットワーク要素のいずれかにおいて、サービスまたは能力にアクセスすることを可能にする。そのような新しい３ＧＰＰインターフェース、例えば、ＤＩＡＭＥＴＥＲ、ＲＥＳＴｆｕｌ ＡＰＩ、ＸＭＬ ｏｖｅｒ ＨＴＴＰ等のために規定すべきプロトコルの選択は、限定ではないが、特定のインターフェースのニーズ、要求される情報のエクスポージャの容易性を含む複数の要因に依存し得る。加えて、ＳＣＥＦの個々のインスタンスは、エクスポーズされるサービス能力およびサポートされるＡＰＩ特徴に応じて、変動し得る。

【0053】

ＳＣＥＦの機能性は、１つ以上の属性を含み得る。これらは、例えば、以下を含み得る：（ｉ）認証および承認、（ｉｉ）外部エンティティがエクスポーズされたサービス能力を発見するための能力、（ｉｉｉ）ポリシ施行、（ｉｖ）保証、（ｖ）会計、（ｖｉ）会計トラフィックドキュメンテーション、（ｖｉｉ）外部相互接続およびコンタクトポイントに関連するアクセス問題、（ｖｉｉｉ）抽象化。具体的には、認証および承認は、ＡＰＩ消費者の識別、プロファイル管理、およびＡＣＬ（アクセス制御リスト）管理を含む。

【0054】

上で導入されるポリシ施行は、インフラストラクチャポリシ、ビジネスポリシ、およびアプリケーション層ポリシを含む。インフラストラクチャポリシは、プラットフォームおよびネットワークを保護するためのポリシを含む。これは、例えば、ＳＭＳ−ＳＣ等のサービスノードがオーバーロードされないことを確実にすることを含み得る。ビジネスポリシは、エクスポーズされる特定の機能性に関連する。これは、例えば、番号ポータビリティ、サービスルーティング、加入者コンテンツ等を含み得る。さらに、アプリケーション層ポリシは、主に、アプリケーションによって提供されるメッセージペイロードまたはスループットに焦点が当てられる。これは、例えば、スロットリングを含み得る。

【0055】

保証属性は、Ｏ＆Ｍシステムとの統合を含み得る。加えて、保証属性は、ＡＰＩの使用に関連する保証プロセスを含み得る。

【0056】

抽象化は、下層３ＧＰＰネットワークインターフェースおよびプロトコルを隠し、完全ネットワーク統合を可能にすることを伴う。以下の機能がサポートされ得る：（ｉ）下層プロトコルコネクティビティ、ルーティング、およびトラフィック制御、（ｉｉ）特定のＡＰＩを適切なネットワークインターフェースにマッピングすること、および、（ｉｉｉ）プロトコル変換。抽象化は、要求される機能性が３ＧＰＰネットワークによってネイティブに提供されない場合に適用され得る。

【0057】

別個に、ＳＣＥＦは、種々のサービスのためにＯＭＡ／ＧＳＭ（登録商標）Ａによって定義されるネットワークＡＰＩを含む。これらのサービスは、限定ではないが、ＳＭＳ、ＭＭＳ、位置特定、支払、第三者コール、マルチメディア会議コール、および他のＩＭＳベースのサービス等を含み得る。ＯＭＡネットワークＡＰＩのリストは、'ＯＭＡ ＡＰ
Ｉ Ｉｎｖｅｎｔｏｒｙ，'３ＧＰＰＴＳ２３．４０１ Ｇｅｎｅｒａｌ Ｐａｃｋｅｔ
Ｒａｄｉｏ Ｓｅｒｖｉｃｅ （ＧＰＲＳ） Ｅｎｈａｎｃｅｍｅｎｔｓ ｆｏｒ Ｅｖｏｌｖｅｄ Ｕｎｉｖｅｒｓａｌ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ （Ｅ−ＵＴＲＡＮ） Ａｃｃｅｓｓにおいて利用可能である。任意の新しいサービス能力エクスポージャのために、ＦＦＳが、新しいネットワークＡＰＩおよび関連エクスポージャ機能性を定義するために、３ＧＰＰとＯＭＡ／ＧＳＭ（登録商標）Ａ／他の規格化団体との間で分割される作業のために採用される。

【0058】

さらに、信頼ドメイン内で動作するアプリケーションは、例えば、ＳＣＥＦによって提供される認証および承認等の機能性の一部のみを利用し得る。信頼ドメイン内で動作するアプリケーションは、要求される３ＧＰＰインターフェースが利用可能にされるならば、例えば、ＰＣＲＦ等のネットワークエンティティにもアクセスし得る。これは、ＳＣＥＦを経由する必要なく、直接、アクセスされ得る。

【0059】

図５に図示される実施例は、ＳＭＳサービス能力エクスポージャを描写する。具体的には、第三者アプリケーション５１０は、ＳＭＳメッセージを送信および受信するために、ＳＭＳ ｏｎｅＡＰＩ ５２０を使用する。ＳＣＥＦ５３０内に位置するＳＭＳ能力エクスポージャ５３１は、同種インターフェースを全アプリケーションに提供する。ＳＣＥＦ５３０内に同様に位置するＳＭＳ抽象化５３２は、ＳＭＰＰ、ＵＣＰ等の異なるＳＭＳメッセージングトランスポートプロトコルをサポートする。ＳＭＳ抽象化５３２は、それが接続する各ＳＭＳＣへの（負荷制御およびメッセージウィンドウイングを含む）全ネットワークセッションを管理および制御するであろう。ＳＭＳ抽象化５３２は、特定のＡＰＩをＳＭＳ−ＳＣ／ＧＭＳＣ／ＩＷＭＳＣ５５０に向けてＴ４およびＴｓｍｓインターフェース５４０にマップする。

【0060】

（ＳＡ２グループベースの拡張（ＧＲＯＵＰＥ）ＴＲ）
グループ拡張は、３ＧＰＰ ＴＲ ２３．７６９ Ｇｒｏｕｐ Ｂａｓｅｄ Ｅｎｈａｎｃｅｍｅｎｔｓに説明されており、参照することによってその全体として本明細書に組み込まれる。概して、アプリケーションは、デバイスのグループを伴い、各グループは、数百または数千のデバイスを伴う。マシンタイプ通信（ＭＴＣ）デバイスは、複数のアプリケーションをホストすることができ、各アプリケーションは、異なるグループのデバイスを伴う。グループに属するデバイスは、「グループメンバ」と称される。グループメンバシップは、静的であることができる、またはグループの存続期間の間、グループメンバの追加および／または除去に伴って動的に進化することができる。ＳＣＳ／ＡＳは、関連付けられたグループメンバと新しいグループを作成することができ、既存のグループを除去することができる。

【0061】

限定ではないが、比較的に静的メンバシップを有するものおよびより動的メンバシップを有するものを含む、異なるタイプのグループが、存在し得る。いくつかのグループ動作は、コアネットワークノード、例えば、ＨＳＳまたはＭＭＥが、グループ内のＵＥのメンバシップにアウェアであることを要求する。例えば、メンバシップは、グループベースのＡＰＮ輻輳、グループの全メンバのローミングステータス、および所与のエリア内のグループに属するデバイスのカウントを含み得る。本ソリューションは、ＨＳＳにおけるグループメンバシップの維持を使用し、したがって、比較的に静的メンバシップを有し、ＨＳＳおよび他のコアネットワークノードがグループメンバシップにアウェアであることを要求するグループにより適用可能となるであろう。

【0062】

加えて、ＳＣＳ／ＡＳ特定のグループは、外部グループＩＤによって識別される。グループのメンバである３ＧＰＰデバイスの外部ＩＤは、グループの外部グループＩＤに結合される。外部グループＩＤへのグループメンバの静的および動的両方の結合が、サポートされることができる。３ＧＰＰデバイスは、複数のアプリケーションをホストすることができ、３ＧＰＰデバイスの識別は、２つ以上の外部グループＩＤに結合されることができる。これは、ＳＣＥＦサービスが、（ｉ）外部グループＩＤおよびＳＣＳ／ＡＳによって提供される随意の外部ＩＤに基づいて、内部グループＩＤおよびグループメンバの内部ＩＤを決定し、（ｉｉ）ＨＳＳが内部ＩＤをＨＳＳが維持するグループに追加すること、またはそこから除去することを要求することを可能にする。

【0063】

図６は、ＳＣＥＦが、ユーザのグループに関連する内部機能性、例えば、グループ管理機能（ＧＭＦ）を含み得る、高レベルアーキテクチャを図示する。この内部機能を通して、ＳＣＥＦは、グループの内部グループＩＤおよび外部グループＩＤを有するグループメンバの内部ＩＤ（例えば、ＩＭＳＩ）と外部ＩＤ（例えば、ＭＳＩＳＤＮ）との結合のローカルコピー。およびグループサービスの配信のために必要とされる他の情報を維持することができる。例えば、ＭＢＭＳをサポートするＰＬＭＮのために、ＳＣＥＦ６５０の内部ＧＭＦは、グループに配分されたＴＭＧＩを維持することができる。内部グループＩＤへの外部グループＩＤのマッピングおよびグループメンバの場所情報も、必要とされる場合、ＧＭＦに維持されることができる。

【0064】

図７は、グループベースのアドレスおよびグループメンバの識別のためのプロトコルを図示する。この例証では、ＳＣＥＦは、内部ＧＭＦを含む。ステップの各々は、ローマ数字によって示される。ステップ１に従って、ＳＣＳ／ＡＳは、グループアドレス要求メッセージを送信することによって、アプリケーション特定グループに対するＳＣＥＦからのサポートを要求する。メッセージは、外部グループＩＤを含み、かつ外部グループのメンバであるデバイス（ＵＥ）の外部ＩＤを含み得る。ステップ２では、ＳＣＥＦは、グループ情報要求／応答メッセージをＨＳＳと交換し、ＳＣＳ／ＡＳが外部グループＩＤに対するグループ情報要求を送信することを承認されているかどうかを決定する。ＨＳＳは、任意の受信されたグループメンバ外部ＩＤを内部ＩＤにマップする。外部グループＩＤは、内部グループＩＤにマップされる。ＨＳＳは、外部ＩＤがグループ情報要求内でサブミットされた場合、内部グループＩＤおよび内部ＩＤ（内部ＩＤへの外部ＩＤのマッピングを含む）をＳＣＥＦに返す。

【0065】

ステップ３に従って、ＳＣＥＦは、その内部ＧＭＦを使用して、グループメンバ内部ＩＤ等の情報との外部グループＩＤのマッピングのローカルコピー、およびグループメンバに関連付けられた内部グループＩＤを維持することができる。一実施例では、情報のローカルコピーは、ＳＣＥＦにすでに既知の類似情報を返す可能性が高い頻繁なクエリからのコアネットワークノードへの影響を低減させるために維持され得る。次に、ＳＣＥＦは、グループアドレス応答メッセージを用いてＳＣＳ／ＡＳに確認する（ステップ４）。

【0066】

ステップ５−８に従って、構築ブロックは、グループメンバがＨＳＳによって維持される内部グループから追加または削除されることを要求するＳＣＳ／ＡＳのために提供される。ステップ５では、ＳＣＳ／ＡＳは、追加の外部ＩＤを外部グループＩＤに追加してもらうために、グループメンバ追加／削除要求をＳＣＥＦに送信する。ステップ６では、ＳＣＥＦは、グループ更新要求／応答メッセージをＨＳＳと交換し、ＳＣＳ／ＡＳが、グループメンバシップ要求を送信することを承認されているかどうかを決定する。ＨＳＳは、外部グループＩＤを内部グループＩＤにマップし、外部ＩＤを内部ＩＤにマップする。ＨＳＳは、デバイスのためのサブスクリプション記録を更新し、それを識別された内部グループに追加する。続いて、ＳＣＥＦにおけるグループメンバシップ情報のローカルコピーが、更新されることができる（ステップ７）。最後に、ＳＣＥＦは、グループメンバ追加／削除応答メッセージを用いて、グループ追加をＳＣＳ／ＡＳに確認する（ステップ８）。

【0067】

上記の図７におけるプロトコルは、既存のノードおよび機能性にいくつかの影響を及ぼし得る。例えば、ＳＣＥＦにおいて、プロシージャフロー内で識別されるようなＳＣＳ／ＡＳからの異なるサポートメッセージが存在する。ＳＣＥＦは、グループメンバシップおよびグループメンバステータス情報を管理するために、ＨＳＳと相互作用する。さらに、ＳＣＥＦは、グループ識別子とデバイスグループメンバシップとの間のマッピングを維持する。

【0068】

ＨＳＳにおいて、内部ＩＤへの外部ＩＤのマッピング、内部グループＩＤへの外部グループＩＤのマッピング等の情報を提供するためのＳＣＥＦとの相互作用をサポートするための影響があり得る。内部グループメンバシップを修正するための影響もあり得る。ＵＥに関して、概して、アプリケーション層特定機能性以外、影響はない。

【0069】

（ＭＢＭＳメッセージ配信ソリューション）
本願は、１つ以上の実施形態では、一般的グループメッセージ配信目的のために再使用され得るアーキテクチャを説明する。一実施形態では、ＢＭ−ＳＣは、特定のＭＢＭＳユーザサービスのためにＴＭＧＩを配分する。ある用途では、ｅＭＢＭＳがブロードキャストモードのみをサポートすることが望ましい。いくつかの用途では、ＥＰＳのためのｅＭＢＭＳがＥ−ＵＴＲＡＮおよびＵＴＲＡＮのみをサポートすることも望ましい。図８は、グループメッセージ配信アーキテクチャの一側面を図示する。ＳＣＥＦ８１０は、ＢＭ−ＳＣ８２０に接続される。ＳＣＳ／ＡＳ８３０は、ブロードキャストされるべきコンテンツおよび追加の情報をＳＣＥＦ８１０に提供する。図８に示されるように、ＳＣＥＦ８１０およびＢＭ−ＳＣ８２０は、同じ場所に位置せず、むしろ、ＭＢ２インターフェースが、それらの間に位置する。

【0070】

一実施形態によると、ＳＣＥＦは、グループメッセージング機能性を多くの方法のうちの１つにおいてサポートする。例えば、ＳＣＥＦは、ＳＣＳ／ＡＳからのグループメッセージ配信要求の受信をサポートする。これは、ＴＭＧＩ、無線周波数、地理的配信エリア、配信スケジュール、グループメッセージコンテンツのうちの１つ以上のものを含み得る。ＳＣＥＦは、ＳＣＳ／ＡＳからの制御プレーン要求を承認するための能力もサポートし得る。ＳＣＥＦは、適切なＨＳＳの照会もサポートする。これは、ＳＣＳ／ＡＳが、グループメッセージング要求を特定のグループに送信すること、およびＴＭＧＩ配分を求めることを可能にされるかどうかを決定することを含み得る。ＳＣＥＦは、ＳＣＳ／ＡＳへのグループメッセージ配信要求の承諾または非承諾をレポートすること、プロトコル変換、およびＭＢＭＳベアラアクティブ化要求をＢＭ−ＳＣに向かって転送することもサポートし得る。

【0071】

加えて、ＳＣＥＦは、ＴＭＧＩおよび周波数がＳＣＳ／ＡＳによって提供されない場合、ＭＢＭＳベアラのＴＭＧＩおよび周波数をＢＭ−ＳＣから得ることもある。そうでなければ、ＳＣＥＦは、グループメッセージ配信要求内のＳＣＳ／ＡＳによって提供されたＴＭＧＩを使用し得る。ＳＣＥＦは、グループ外部識別子およびＳＣＳ識別子を含むグループメッセージング特定ＣＤＲの生成およびＲｆ／Ｇａのインスタンスを経由したＣＤＦ／ＣＧＦへの転送もサポートし得る。ＳＣＥＦは、サービスエリアおよびＲＡＴに基づいてセッション開始プロシージャをトリガすることもサポートし得る。ＳＣＥＦは、ＳＣＳ／ＡＳがグループメッセージ配信要求内にグループメッセージコンテンツを提供する場合、スケジュールされた時間において、コンテンツをＭＢ２−Ｕインターフェース上でＢＭ−ＳＣに送信することもある。

【0072】

ＳＣＥＦは、グループメッセージ配信要求内でＳＣＳ／ＡＳによって要求される場合、ＴＭＧＩ、無線周波数、コンテンツ記述、および伝送スケジュールのために、ＵＥからの要求をハンドリングすることもある。さらなる側面では、ＳＣＥＦに、ＴＭＧＩ、無線周波数、コンテンツ記述、および伝送スケジュールのためのＵＥからの要求をハンドリングさせることは、ＳＣＳ／ＡＳをＭＢＭＳを介したコンテンツの配信の詳細から隔離するための手段を提供する。これは、ＳＣＥＦが、ＵＥに既知の識別、例えば、ＦＱＤＮを有していなければならないことを意味する。例示的実施形態では、大規模メッセージの配信は、電力が制約されないデバイスに提供される。電力が制約されるデバイスは、グループメッセージコンテンツを受信および理解するために必要とされるＴＭＧＩ、周波数、コンテンツ記述、伝送スケジュール、および任意の解読キーで事前に構成され得ることが予期される。

【0073】

ＳＣＥＦは、ＳＣＳ／ＡＳからのＴＭＧＩ配分要求の受信もサポートし得る。さらに、ＳＣＥＦは、ＢＭ−ＳＣへのＴＭＧＩ配分要求の転送をサポートし得る。さらに、ＳＣＥＦは、ＢＭ−ＳＣからのＴＭＧＩ配分要求の受信およびＳＣＳ／ＡＳへのＴＭＧＩの転送をサポートし得る。

【0074】

図９は、ＳＣＳ／ＡＳによるＴＭＧＩの配分とメッセージをＵＥのグループに配信するためのＭＢＭＳの使用とを図示する。ステップの各々は、ローマ数字によって示される。この場合、オペレータは、トリガ／メッセージングを通常のＭＢＭＳユーザサービスとして取り扱い、ＴＳ ２３．２４６に定義されるように、「サービスアナウンスメント」（ＳＭＳ、ＷＡＰ、ＨＴＴＰ）を使用し、メッセージ配信の前に、関連サービス情報を特定のグループのデバイスに配布し得る。例えば、図９の随意のステップ１−７に示されるこのアプローチは、特定のグループのデバイスに対して、それらに関連ＭＢＭＳサービス情報を提供するためにも適用され得る。

【0075】

ステップ１に従って、外部グループＩＤのために割り当てられたＴＭＧＩが存在しない場合、ＳＣＳ／ＡＳは、ＴＭＧＩ配分要求（外部グループＩＤ、ＳＣＳ ＩＤ）メッセージをＳＣＥＦに送信する。ＳＣＥＦは、ＳＣＳ／ＡＳがＴＭＧＩ配分を要求するために承認されていることをチェックする。ステップ２では、ＳＣＥＦは、ＳＣＳ／ＡＳが、グループのためのＴＭＧＩ配分を要求し、ＢＭ−ＳＣの識別を含む、関連ＨＳＳ記憶「ルーティング情報」を読み出すために承認されているかどうかを決定するために、加入者情報要求（外部グループＩＤおよびＳＣＳ ＩＤ）メッセージをＨＳＳに送信する。ステップ３では、ＨＳＳは、加入者情報応答（ＢＭ−ＳＣの識別を含む、「ルーティング情報」）メッセージを送信する。

【0076】

次に、ＳＣＥＦは、ＨＳＳから受信された情報に基づいて、ＴＭＧＩ配分要求（外部グループＩＤ）をＢＭ−ＳＣに送信する（ステップ４）。ＢＭ−ＳＣは、ＴＭＧＩを配分し、ＴＭＧＩのための期限時間を決定する。次いで、ＢＭ−ＳＣは、ＴＭＧＩ配分応答（ＴＭＧＩ、ＴＭＧＩ期限、周波数等）メッセージをＳＣＥＦに送信する（ステップ５）。ステップ６では、ＳＣＥＦは、受信されたＴＭＧＩ、ＴＭＧＩ期限、周波数等をＳＣＳ／ＡＳに転送する。続いて、ＳＣＳ／ＡＳは、ＴＭＧＩ、周波数、スケジュール等をグループに属する全ＵＥに信号伝達する（ステップ７）。

【0077】

その後、ＳＣＳ／ＡＳは、グループメッセージング要求（外部グループ識別子、ＳＣＳ識別子、グループメッセージのアプリケーション層コンテンツ、場所／エリア情報、ＲＡＴ情報、ＴＭＧＩ）メッセージをＳＣＥＦに送信する（ステップ８）。ＳＣＳ／ＡＳは、外部グループ識別子を使用して、またはローカルで構成されたＳＣＥＦ識別子／アドレスを使用して、ＤＮＳクエリを行うことによって、ＳＣＥＦのＩＰアドレス／ポートを決定し得る。ＳＣＳ／ＡＳによって示される場所／エリア情報は、地理的エリア情報であり得る。

【0078】

続いて、ステップ９では、ＳＣＥＦは、ＳＣＳ／ＡＳがグループメッセージング要求を送信することを承認されていることをチェックする。ＳＣＥＦは、ＳＣＳ／ＡＳがグループメッセージングを特定のグループに送信するために承認されたかどうかを決定するために、加入者情報要求（外部グループ識別子およびＳＣＳ識別子）メッセージをＨＳＳ／ＨＬＲに送信し得る（ステップ１０）。その後、ＨＳＳ／ＨＬＲは、加入者情報応答（配信方法、原因）メッセージを送信する。ＨＳＳ／ＨＬＲは、サブスクリプションおよび／またはポリシに基づいて、グループメッセージング配信方法、例えば、ＭＢＭＳを示し得る（ステップ１１）。原因値が、ＳＣＳ／ＡＳがグループメッセージング要求をこのグループに送信することを許可されないことを示すか、または有効サブスクリプション情報が存在しない場合、ＳＣＥＦは、グループメッセージング確認メッセージを失敗条件の理由を示す原因値とともに送信し、フローは、このステップにおいて停止する。そうでなければ、このフローは、ステップ５に進む。

【0079】

ステップ１２に従って、ＳＣＥＦは、ステップ８におけるＴＭＧＩの受信に基づいて、ＭＢＭＳ配信を選択する。ＳＣＥＦは、グループメッセージング確認メッセージをＳＣＳ／ＡＳに送信し、要求がＵＥへの配信のために承諾されたことを確認する（ステップ１３）。そのように構成される場合、ＵＥは、例えば、ＳＣＥＦのためのＦＱＤＮ等の既知のアドレスを使用して、ＭＢＭＳベアラパラメータをＳＣＥＦから得る（ステップ１４）。これは、グループコンテンツの実際のブロードキャスト伝送に先立って、有意な期間を生じさせ得る。

【0080】

次に、ＭＢＭＳ配信方法が選択される場合、ＳＣＥＦは、ＭＢＭＳベアラアクティブ化要求（ＭＢＭＳサービスエリア、ＴＭＧＩ）メッセージをＢＭ−ＳＣ／ＭＢＭＳ−ＧＷに送信する。ＭＢＭＳ−ＧＷは、ＭＭＥ／ＳＧＳＮとのセッション開始プロシージャを行う（ステップ１５）。次いで、ＭＢＭＳ−ＧＷは、ＭＭＥ／ＳＧＳＮとのセッション開始プロシージャを行う（ステップ１６）。次いで、ＢＭ−ＳＣは、ＭＢＭＳベアラアクティブ化応答をＳＣＥＦに送信する（ステップ１７）。ここで、ＳＣＥＦは、オペレータドメイン内の構成に基づいて、ＳＣＳ／ＡＳによって提供される場所／エリア情報と、グループメッセージの配布のためのＭＢＭＳサービスエリアとの間でマッピングを行う。さらに、ＳＣＥＦは、選択されたＭＢＭＳサービスエリアが、ＳＣＳ／ＡＳによって示され得るエリアより大きいエリアにわたってメッセージのブロードキャストをもたらし得ることを認識している。これは、セル粒度レベルにおけるＭＢＭＳブロードキャストがサポートされないからである。

【0081】

ステップ１８では、ＳＣＥＦは、グループメッセージコンテンツをＢＭ−ＳＣ／ＭＢＭＳ−ＧＷに転送する。グループメッセージコンテンツは、ＵＥに配信される。受信されたメッセージに応答して、ＵＥは、ペイロードのコンテンツを考慮した特定のアクションを行う（ステップ１９）。この応答は、典型的には、ＳＣＳ／ＡＳとの即時または後の通信の開始を伴う。

【0082】

ＳＣＥＦは、グループメッセージング機能性をサポートする。例えば、ＳＣＥＦは、ＳＣＳ／ＡＳからのグループメッセージング要求の受信をサポートする。ＳＣＥＦは、ＳＣＳ／ＡＳからの制御プレーン要求を承認するための能力もサポートする。ＳＣＥＦはた、ＳＣＳ／ＡＳへのグループメッセージング要求の承諾または非承諾のレポートもサポートする。ＳＣＥＦは、そのように要求される場合、ＳＣＳ／ＡＳへのＴＭＧＩおよび無線周波数の提供もサポートする。ＳＣＥＦは、適切なＨＳＳの照会もサポートし、例えば、ＳＣＳ／ＡＳが、グループメッセージング要求を特定のグループに送信し、ＴＭＧＩ配分を求めるか、またはＴＭＧＩ、無線周波数、コンテンツ記述、および伝送スケジュールをＵＥに提供することを許可されているかどうかを決定する。

【0083】

ＳＣＥＦは、プロトコル変換およびＢＭ−ＳＣ／ＭＢＭＳ−ＧＷに向かってのグループメッセージング要求の転送もサポートし得る。ＳＣＥＦは、グループ外部識別子およびＳＣＳ識別子を含むグループ特定メッセージングＣＤＲの生成およびＲｆ／Ｇａのインスタンスを経由したＣＤＦ／ＣＧＦへの転送もサポートし得る。ＳＣＥＦは、サービスエリアおよびＲＡＴに基づいてセッション開始プロシージャをトリガすることもサポートし得る。ＳＣＥＦは、ＳＣＳ／ＡＳからのＴＭＧＩ配分要求の受信およびＢＭ−ＳＣへの要求の転送もサポートし得る。ＳＣＥＦはさらに、ＢＭ−ＳＣからのＴＭＧＩの受信およびＳＣＳ／ＡＳへのＴＭＧＩの転送をサポートする。

【0084】

（グループメンバの追加）
本願のさらなる側面によると、図１０は、グループメンバシップ更新プロシージャを図示する。プロシージャは、既存のプロシージャに優るいくつかの利点を有する。例えば、新しいプロシージャは、ＳＣＥＦが、グループ内で承認されているデバイス、およびグループに参加している（例えば、リッスンしている）デバイスを追跡することを可能にする。ＳＣＳ／ＡＳは、デバイスがグループに参加すべきことを示し、デバイスがグループに参加するために承認されること求め得る。これが生じると、ＳＣＥＦおよびＢＭ−ＳＣは、デバイスがグループ内に存在可能であることを記録するであろう。ＳＣＳ／ＡＳが、ＳＣＥＦに、どのデバイスがグループ内であるかを確認するためにクエリすると、ＳＣＥＦは、グループに参加するための承認されているデバイスと、ＭＢＭＳサービスをアクティブ化しているデバイス、またはグループメッセージをリッスンしているデバイスとを区別するであろう。そうすることによって、ＳＣＳ／ＡＳは、メッセージを好機に送信し得る。

【0085】

例示的実施形態では、図１０に記載されるプロシージャは、下層ネットワーク詳細の全てをＳＣＳ／ＡＳから隠す。ＳＣＳ／ＡＳは、ＵＥにコンタクトし、ＵＥにマルチキャストアドレスおよび他のＭＢＭＳ ＵＥコンテキストを提供する必要はない。代わりに、ＳＣＥＦからのトリガメッセージが、ＵＥに送信され、トリガペイロードが、十分なＭＢＭＳ ＵＥコンテキスト情報を搬送し、ＵＥがサービスをアクティブ化することを可能にするであろう。例えば、トリガペイロードは、ＴＭＧＩ、ＡＰＮ、グループ名、またはマルチキャストアドレスを搬送するであろう。デバイスが、グループに実際に参加していると、例えば、サービスをアクティブ化していると、ＢＭ−ＳＣは、ＳＣＥＦにそれを知らせ、したがって、ＳＣＥＦは、デバイスがグループメッセージを実際にリッスンしていることを把握するであろう。順に、ＳＣＥＦは、ＳＣＳ／ＡＳに通知するであろう。代替として、ＳＣＥＦは、要求に応じてではなく、所定の周期で、ＳＣＳ／ＡＳに通知し得る。ＳＣＳ／ＡＳは、あるデバイスがグループメッセージをリッスンするまで、またはある数もしくはパーセンテージのグループがグループメッセージをリッスンするまで、グループメッセージを送信することを待つことによって、この特徴を利用し得る。

【0086】

図１０におけるステップの各々は、ローマ数字によって示される。本願のこの側面によると、コアネットワークは、ＢＭ−ＳＣ、ＨＳＳ、ＭＢＭＳ−ＧＷ／ＧＧＳＮ、およびＳ−ＧＷ／ＳＧＳＮのうちの１つ以上のものを含み得る。コアネットワークは、モバイルネットワークオペレータとも称され得る。本実施形態によると、ＳＣＥＦは、以下に議論される以下の場所のうちの１つに常駐し得る。例えば、ＳＣＥＦは、独立型ノード上に位置し得る。独立型ノードは、サービスプロバイダによって所有され得る。代替として、独立型ノードは、サービスプロバイダに関係する人物によって所有され得る。別の実施例では、ＳＣＥＦは、例えば、ＳＣＳ／ＡＳ等のサーバ上に位置し得る。さらに別の実施例では、ＳＣＥＦは、モバイルネットワークオペレータによって所有されるノード上に位置し得る。

【0087】

図１０に描写されるように、ステップ１に従って、ＳＣＳ／ＡＳは、メッセージをＳＣＥＦに送信し、特定のデバイスをグループに追加する。グループは、事前に確立されたグループであることができる。代替として、これは、新しいグループであることができる。グループは、外部グループＩＤによって識別される。追加されるべきデバイスは、外部ＩＤによって識別される。一実施形態によると、ＳＣＳ／ＡＳは、ＵＥがＭＢＭＳサービスをアクティブ化するときを通知されることを欲することを示し得る。このメッセージは、複数のＵＥをグループに追加するために使用され得る。

【0088】

ある実施形態によると、ＳＣＳ／ＡＳが、グループを作成すること、グループを修正すること、またはメッセージがグループに配信されることを要求するとき、それは、メッセージが送信される前に、リッスンしているべきであるグループのパーセンテージをＳＣＥＦに示すことができる。ＳＣＥＦは、要求される数のグループメンバがマルチキャストをリッスンするまで、メッセージのバッファまたは保持のいずれかを行い得る。ＳＣＥＦが、ＢＭ−ＳＣから、より多くのメンバがグループに参加したことの通知を受信すると、ＳＣＥＦは、ＳＣＳ／ＡＳからのメッセージに基づいて、十分なグループメンバがメッセージを配信するためにリッスンしていることを決定し得る。そして、ＳＣＥＦは、メッセージを送信する。

【0089】

別の実施形態によると、制限時間が、ＳＣＳ／ＡＳによってＳＣＥＦに提供され得る。この制限時間は、マルチキャストをリッスンしているグループメンバの数にかかわらず、メッセージがある時間量後に配信されるべきであることのＳＣＥＦへの指示であり得る。

【0090】

ステップ２では、ＳＣＥＦは、ＳＣＳ／ＡＳが外部グループＩＤのためのグループ情報要求を送信することを承認されているかどうかを決定するために、ＳＣＳ／ＡＳからのグループ情報要求／応答メッセージをＨＳＳと交換し得る。一実施形態では、ＨＳＳは、ＳＣＳ／ＡＳが、メンバをグループに追加すること、またはメンバをグループから削除することが許可されていることを承認、外部グループ識別子を内部グループ識別子にマップし、デバイスのサブスクリプションを更新し、グループのメンバであるために承認されていることを示す。ＳＣＥＦからの要求は、ＭＢＭＳがグループメッセージ配信のために使用され得ることを示し得る。例示的実施形態では、ＨＳＳからの応答は、ＡＰＮがグループメッセージ配信のために使用されるべきであることを示し得る。ＭＢＭＳメッセージを受信するＵＥは、このＡＰＮを使用して、ＩＧＭＰ参加を送信し、サービスをアクティブ化するであろう。

【0091】

ステップ３に従って、ＳＣＥＦは、ＭＢＭＳ承認要求をＢＭ−ＳＣに送信し、ＵＥがＭＢＭＳデータを受信することを承認されていることをチェックする。このメッセージは、ＭＢ２参照点上で送信される。ＭＢ２参照点は、例えば、３ＧＰＰ ＴＳ ２３．４６８において説明されている。一実施形態では、要求は、ＨＳＳから受信されたＡＰＮと、内部デバイス識別子とを含み得る。別の実施形態では、要求は、新しいデバイスがＭＢＭＳサービスをアクティブ化すると通知されることをＳＣＥＦが欲することの指示も含み得る。ステップ４では、応答が、デバイスがＭＢＭＳデータを受信するために承認されているかどうかについて、ＢＭ−ＳＣから受信される。一実施形態では、ＢＭ−ＳＣまたはＳＣＥＦは、そのサービスアナウンスメント機能を介して、ＭＢＭＳサービスのためのサービスアナウンスメントを開始するためのプロトコルを採用し得る。これらのプロトコルは、例えば、ＷＡＰ ＰＵＳＨ、ＨＴＴＰ、ＳＭＳ、およびＳＭＳ−ＣＢを含み得る。ここで、ＳＣＥＦは、サービスアナウンスメントが要求されるかどうかをＢＭ−ＳＣに示し得る。

【0092】

ステップ５に従って、ＳＣＥＦは、デバイスがグループに追加されるために承認されていることを確認する。一実施形態では、ＳＣＳ／ＡＳへのメッセージは、ＵＥが承認されていることのみを示す。別の実施形態では、ステップ５におけるメッセージは、デバイスがグループに参加していることの指示を含む。

【0093】

ステップ６に従って、トリガまたは他の機構が、コアネットワークを介してグループ詳細をＵＥに送信するために採用される。具体的には、ＳＣＥＦは、ＵＥがマルチキャストグループに参加すべきであることの指示をＵＥに送信する。トリガが、ＵＥがマルチキャストグループ招待をリッスンすることが予期される周知のポート番号に送信されるであろう。代替として、トリガが送信されるポート番号は、ＳＣＳ／ＡＳによって提供されていることもある。これは、上記のステップ１において生じ得る。一実施形態では、トリガペイロードは、以下の情報タイプのうちの１つ以上のものを搬送し得る：ＡＰＮ、マルチキャストアドレス、およびＳＣＳ−ＩＤ。

【0094】

ある実施形態によると、図１１に示されるように、例えば、トリガは、ＵＥのディスプレイ上のグラフィカルユーザインターフェース１１００上に出現し得る。ディスプレイは、図１Ｃおよび１Ｄにおいて上で説明ならびに図示される。具体的には、グラフィカルユーザインターフェース１１００上に現れるメッセージは、「マルチキャスト／ブロードキャストグループへの参加要求がＭ２ＭサーバＸＹＺから受信されました。参加しますか？」というものである。メッセージは、招待を送信したサーバも示し得る。メッセージは、マルチキャスト／ブロードキャストへの参加またはリッスンのためのユーザの許可も要求し得る。ユーザが、「はい」を選択する場合、ユーザは、以下のステップ９により詳細に議論されるように参加する。

【0095】

次に、ＳＣＳ／ＡＳは、グループメンバクエリをＳＣＥＦに送信し得る（ステップ７）。要求は、外部グループＩＤを示す。グループメンバクエリは、図１０のプロセスにおいて、随時生じ得る。これは、本明細書では、トリガ配信の後に生じるように説明される。ステップ８では、ＳＣＥＦは、グループに参加するために承認されたデバイスのリストを返す。例示的実施形態では、ＳＣＥＦは、ＭＢＭＳサービスをアクティブ化しているデバイスのリストも提供し得る。図１０に示されるように、ステップ５において承認されたデバイスは、ＭＢＭＳサービスをアクティブ化していない。これらのステップは、以下により詳細に議論されるであろう。したがって、ＳＣＳ／ＡＳへのメッセージは、デバイスが承認されているが、マルチキャストをまだリッスンしていないことを示すであろう。

【0096】

ステップ９に従って、ＵＥは、ステップ６に従って前述のトリガを処理し、その内部プロトコルを用いて、ＡＳ／ＳＣＳから最終的に受信されたＳＣＳ−ＩＤによって示されるマルチキャストメッセージのリッスンを欲するかどうかに関してチェックする。ＵＥは、トリガ内に示されたＡＰＮ内にデフォルトベアラを確立する。これは、ＡＰＮ接続がすでに存在していなかったことを仮定する。ＵＥは、次いで、ＩＧＭＰ／ＭＬＤ参加要求をマルチキャストアドレスに送信する。すなわち、ＵＥは、グループに参加し、ＳＣＡ／ＡＳまたはＳＣＥＦからのマルチキャストメッセージをアクティブにリッスンすることを要求している。

【0097】

次いで、ＭＢＭＳ−ＧＷまたはＧＧＳＮは、ＭＢＭＳ承認要求をＢＭ−ＳＣに送信する（ステップ１０）。ＢＭ−ＳＣは、次いで、ＭＢＭＳ承認要求に応答する（ステップ１１）。ＭＢＭＳサービスは、ＵＥを用いてアクティブ化される（ステップ１２）。これらのプロシージャは、例えば、３ＧＰＰ ＴＳ ２３．２４６ ＭｕｌｔｉｍｅｄｉａＢｒｏａｄｃａｓｔ／Ｍｕｌｔｉｃａｓｔ Ｓｅｒｖｉｃｅ；ａｒｃｈｉｔｅｃｔｕｒｅ ａｎｄ Ｆｕｎｃｔｉｏｎａｌ Ｄｅｓｃｒｉｐｔｉｏｎに説明されている。

【0098】

ステップ１３では、ＢＭ−ＳＣは、ＳＣＥＦに、デバイスがＭＢＭＳサービスをアクティブ化したことを知らせる。これは、ＭＢ２参照点上の新しいメッセージである。一実施形態では、ＢＭ−ＳＣは、ステップ１に従うサーバからＳＣＥＦへのメッセージ内に含まれた指示と、ステップ３に従うＳＣＥＦからＢＭ−ＳＣへの指示とにより、このメッセージを送信すべきことを把握し得る。ステップ１４では、ＳＣＥＦは、ＢＭ−ＳＣからの通知を肯定応答する。ステップ１３および１４は、ＳＣＥＦに、ＵＥがそのＭＢＭＳベアラを非アクティブ化したときを知らせるためにも使用され得る。この情報は、ＳＣＥＦによって、承認されたが、非アクティブ化されており、リッスンしていない、グループ内のＵＥのステータスを更新するために使用されるであろう。これは、以下のイベントの結果、生じ得る。あるイベントは、例えば、ＢＭ−ＳＣがＭＢＭＳサービスを終了することを選定したときを含み得る。ＢＭ−ＳＣは、「セッション停止要求」または「登録解除要求」をＧＧＳＮもしくはＭＢＭＳ−ＧＷに送信した後または前に、ＵＥもしくはグループがもはやリッスンしていないことをＳＣＥＦに通知するであろう。別のイベントは、例えば、ＵＥがマルチキャストのリッスンを停止することを決定したときを含み得る。この時点において、ＵＥは、典型的には、ＩＧＭＰ退去メッセージを送信するであろう。これは、ＧＧＳＮまたはＭＢＭＳ−ＧＷに「退去指示」をＢＭ−ＳＣに送信させるであろう。「退去指示」は、ＢＭ−ＳＣに、ＵＥがもはやリッスンしていないことをＳＣＥＦに通知させるであろう。

【0099】

ステップ１５に従って、一実施形態では、通知がステップ１において要求された場合、ＳＣＥＦは、ＳＣＳ／ＡＳにデバイスがＭＢＭＳサービスをアクティブ化したことを知らせるであろう。ステップ１６では、ＳＣＳ／ＡＳは、ＳＣＥＦからの通知を肯定応答する。続いて、ＳＣＳ／ＡＳは、グループメンバクエリをＳＣＥＦに送信する。要求は、外部グループＩＤを示す（ステップ１７）。この随意のメッセージは、グループメンバがＭＢＭＳサービスをアクティブ化する度にＳＣＳ／ＡＳに通知を送信する代替として使用されることができることに留意されたい。ステップ１８に従って、ＳＣＥＦは、グループに参加するために承認されたデバイスのリストを返す。リストは、さらなる実施形態では、ＭＢＭＳサービスをアクティブ化しているデバイスのリストも含み得る。ステップ１７および１８は、前述のステップ７および８のある範囲において類似する。図１０に従って、ステップ５において承認されたデバイスが、ここで、ＭＢＭＳサービスをアクティブ化する。すなわち、ＳＣＳ／ＡＳへのメッセージは、デバイスが承認されており、マルチキャストをリッスンしていることを示すであろう。

【0100】

別の実施形態によると、ステップ１６の後およびステップ１８の後、ＳＣＳ／ＡＳは、デバイスがマルチキャストをリッスンしていることのある保証を有し得る。ＳＣＳ／ＡＳは、この情報を使用して、マルチキャストデータをＳＣＥＦを介してグループに送信し始めるべきときを決定することに役立て得る。

【0101】

別の実施形態によると、ＵＥが、ＳＣＳ／ＡＳがＵＥがグループに追加されることを要求する前に、「ＩＧＭＰプロキシ参加」を送信する場合、ＢＭ−ＳＣは、ＵＥのためにＭＢＭＳサービスアクティブ化を承認しないであろう。この場合、ＢＭ−ＳＣは、ＵＥがグループに参加することを望むことを示す要求をＳＣＥＦに送信し得る。ＳＣＥＦは、ＵＥがグループに参加することを許可されるべきかどうかを確認するために、要求をグループを制御するＳＣＳ／ＡＳに送信し得る。ＳＣＳ／ＡＳは、ＵＥがグループに参加することが許可されるべきかどうかの指示でＳＣＥＦに応答し得る。順に、ＳＣＥＦは、ＵＥがグループに参加することが許可されるかどうかの指示でＢＭ−ＳＣに応答し得る。ＢＭ−ＳＣは、指示を使用して、ＵＥがＭＢＭＳサービスのために承認されるべきかどうかを決定し得る。

【0102】

さらに別の実施形態によると、ＵＥは、図１０のステップ６に示されるトリガを受信するアプリケーションを有し得る。これは、ＵＥがＭＢＭＳアドバタイズメントをリッスンしているであろう用意された周知のポートであり得る。アプリケーションが、トリガ要求を受信すると、トリガペイロードのコンテンツを使用して、ＡＰＮへの接続を開き、ＩＧＭＰ参加メッセージを構築し、次いで、ＩＧＭＰ／ＭＬＤ参加メッセージを送信し得る。ＡＰＮ、マルチキャストアドレス、およびマルチキャストソースアドレスが、トリガペイロードから得られ得る。代替実施形態では、ＵＥアプリケーションは、アプリケーション識別子をトリガペイロードから得て、ＡＰＮ、マルチキャストアドレス、およびマルチキャストソースアドレスを第２のアプリケーションにパスし得る。第２のアプリケーションは、次いで、ＩＧＭＰ／ＭＬＤ参加メッセージを保証し得る。ＩＧＭＰ参加動作は、ＩＥＴＦ ＲＦＣ ３３７６，Ｉｎｔｅｒｎｅｔ Ｇｒｏｕｐ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ Ｖｅｒｓｉｏｎ ３に説明され、参照することによって全体として組み込まれるようなＩＰＭｕｌｔｉｃａｓｔＬｉｓｔｅｎであり得る。加えて、ＭＬＤ参加動作は、ＩＰｖ６のためのＩＥＴＦ ＲＦＣ ３８１０，Ｍｕｌｔｉｃａｓｔ Ｌｉｓｔｅｎｅｒ Ｄｉｓｃｏｖｅｒｙ Ｖｅｒｓｉｏｎ ２，（ＭＬＤｖ２）に説明され、参照することによって全体として組み込まれるようなＩＰｖ６ＭｕｌｔｉｃａｓｔＬｉｓｔｅｎであり得る。

【0103】

本願によると、本明細書で説明されるシステム、方法、およびプロセスのうちのいずれかまたは全ては、命令が、コンピュータ、サーバ、Ｍ２Ｍ端末デバイス、またはＵＥ、Ｍ２Ｍゲートウェイデバイス、もしくはＳＣＥＦを含む、独立型ノード等のマシンによって実行されたときに、本明細書で説明されるシステム、方法、ならびにプロセスを行うおよび／または実装される、コンピュータ読み取り可能な記憶媒体上に記憶されたコンピュータ実行可能命令（例えば、プログラムコード）の形態で具現化され得ることが理解される。具体的には、上で説明されるステップ、動作、または機能のうちのいずれかは、そのようなコンピュータ実行可能命令の形態で実装され得る。コンピュータ読み取り可能な記憶媒体は、情報の記憶のための任意の方法または技術で実装される、揮発性および不揮発性、取り外し可能および非取り外し可能媒体の両方を含むが、そのようなコンピュータ読み取り可能な記憶媒体は、信号を含まない。コンピュータ読み取り可能な記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）または他の光学ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置または他の磁気記憶デバイス、もしくは所望の情報を記憶するために使用することができ、コンピュータによってアクセスすることができる任意の他の物理的媒体を含むが、それらに限定されない。

【0104】

本願のさらに別の側面によると、コンピュータ読み取り可能なまたは実行可能記命令を記憶するための非一過性のコンピュータ読み取り可能なもしくは実行可能記憶媒体が開示される。媒体は、図３および７−１０による、複数のコールフローにおいて上で開示されるような１つ以上のコンピュータ実行可能命令を含み得る。コンピュータ実行可能命令は、上記の図１Ｃおよび１Ｄで開示される、メモリ内に記憶され、プロセッサによって実行され、ＵＥ、ＳＣＥＦ、ＳＣＳ／ＡＳ、およびコアネットワークを含む、デバイス内で採用され得る。一実施形態では、図１Ｃおよび１Ｄに前述のように、不揮発性メモリおよびそこに動作可能に結合されるプロセッサを有する、コンピュータ実装ＳＣＥＦが、開示される。具体的には、不揮発性メモリは、マルチキャストメッセージを受信するグループへのメンバシップの制御および協調を配分するためのその上に記憶される命令を有する。プロセッサは、（ｉ）サーバからデバイスをグループに追加するための要求を受信し、（ｉｉ）デバイスがグループに参加するために承認されたことの返事をサーバに送信し、（ｉｉｉ）デバイスがグループに参加したことの通知を受信し、（ｉｖ）クエリ要求をサーバから受信し、（ｖ）クエリ要求に基づいて、デバイスのステータスをチェックし、（ｖｉ）サーバに、デバイスがグループに参加したことの指示を提供する命令を行うように構成される。

【0105】

システムおよび方法が、現在、具体的側面と見なされるものに関して説明されているが、本願は、開示される側面に限定される必要はない。請求項の精神および範囲内に含まれる種々の修正および類似配列を対象とすることが意図され、その範囲は、全てのそのような修正および類似構造を包含するよう、最も広い解釈を与えられるはずである。本開示は、以下の請求項のありとあらゆる側面を含む。

【図1A】

【図1B】

【図1C】

【図1D】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】