JP5824154B2 - マシンタイプコミュニケーション接続性共有 - Google Patents

Description

本発明は、マシンツーマシン（「Ｍ２Ｍ」）通信に関する。

マシンツーマシン（「Ｍ２Ｍ」）通信とは、スマートメータ、ホームオートメーション、ｅヘルス、およびフリート管理など、様々なアプリケーション（「Ｍ２Ｍアプリケーション」）を実行するための情報を、そのようなＭ２Ｍ通信を介して送信、受信、または交換するように適合された、マシンと呼ばれるデバイスによって、２つのデバイスの間で、および／または３つ以上のデバイスの間で実施される通信のカテゴリのことである。一般に、様々なアプリケーションの実行、ひいては、そのような実行に付随するＭ２Ｍ通信は、Ｍ２Ｍ通信の開始をトリガし、起動し、および／または引き起こすための人間の介入を必要とせずに、マシンによって実施される。

理解できるように、Ｍ２Ｍアプリケーションの実施および普及が成功するかどうかは、様々な企業主体によって製造および運用され得る様々なマシン間の相互運用性を保証する（例えば、保証するための要件を定義する）規格を、産業界全体が受け入れるかどうかにおそらく係っている。

一実施形態では、マシンタイプコミュニケーションを管理する方法は、第１の３ＧＰＰネットワークノードと第２の３ＧＰＰネットワークノードとの間の論理３ＧＰＰ経路を介して、第１のマシンタイプコミュニケーション（ＭＴＣ）デバイスから第１のＭＴＣサーバに、第１の通信をルーティングするステップを含む。論理３ＧＰＰ経路には、経路識別子が割り当てられる。方法は、論理３ＧＰＰ経路を介して、第２のＭＴＣデバイスから第２のＭＴＣサーバに、第２の通信をルーティングするステップも含むことができる。方法は、装置または有形なコンピュータ可読記憶媒体内で具体化することができる。

より詳細な理解は、添付の図面とともに、例として与えられた以下の説明から得ることができる。

図１Ａは、１または複数の開示される実施形態を実施できる例示的な通信システムのシステム図である。 図１Ｂは、図１Ａに示された通信システム内で使用できる例示的な無線送受信ユニット（ＷＴＲＵ）のシステム図である。 図１Ｃは、図１Ａに示された通信システム内で使用できる例示的な無線アクセスネットワークおよび例示的なコアネットワークのシステム図である。 図１Ｄは、図１Ａに示された通信システム内で使用できる例示的な無線アクセスネットワークおよび例示的なコアネットワークのシステム図である。 図１Ｅは、図１Ａに示された通信システム内で使用できる例示的な無線アクセスネットワークおよび例示的なコアネットワークのシステム図である。 図２は、非限定的な一実施形態による、様々なＭＴＣトラフィック経路を示すシステム図である。 図３は、非限定的な一実施形態による、共有されるネットワークセグメントを示すブロック図である。 図４は、様々な非限定的な実施形態によるメッセージ構造を示す図である。 図５は、様々な非限定的な実施形態によるメッセージ構造を示す図である。 図６は、様々な非限定的な実施形態によるメッセージ構造を示す図である。 図７は、様々な３ＧＰＰコアネットワークノードと、それらの間に確立され得る論理接続性エンティティとを有する、３ＧＰＰネットワークを示すネットワーク図である。

図１Ａは、１または複数の開示される実施形態を実施できる例示的な通信システム１００の図である。通信システム１００は、音声、データ、ビデオ、メッセージング、放送などのコンテンツを複数の無線ユーザに提供する、多元接続システムとすることができる。通信システム１００は、複数の無線ユーザが、無線帯域幅を含むシステムリソースの共用を通して、そのようなコンテンツにアクセスすることを可能にすることができる。例えば、通信システム１００は、符号分割多元接続（ＣＤＭＡ）、時分割多元接続（ＴＤＭＡ）、周波数分割多元接続（ＦＤＭＡ）、直交ＦＤＭＡ（ＯＦＤＭＡ）、およびシングルキャリアＦＤＭＡ（ＳＣ−ＦＤＭＡ）など、１または複数のチャネルアクセス方法を利用することができる。

図１Ａに示されるように、通信システム１００は、無線送受信ユニット（ＷＴＲＵ）１０２ａ、１０２ｂ、１０２ｃ、１０２ｄ、無線アクセスネットワーク（ＲＡＮ）１０４、コアネットワーク１０６、公衆交換電話網（ＰＳＴＮ）１０８、インターネット１１０、および他のネットワーク１１２を含むことができるが、開示される実施形態は、任意の数のＷＴＲＵ、基地局、ネットワーク、および／またはネットワーク要素を企図していることが理解されよう。ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄの各々は、無線環境において動作および／または通信するように構成された任意のタイプのデバイスとすることができる。例を挙げると、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、無線信号を送信および／または受信するように構成することができ、ユーザ機器（ＵＥ）、移動局、固定もしくは移動加入者ユニット、ページャ、セルラ電話、携帯情報端末（ＰＤＡ）、スマートフォン、ラップトップ、ネットブック、パーソナルコンピュータ、無線センサ、および家電製品などを含むことができる。

通信システム１００は、基地局１１４ａおよび基地局１１４ｂも含むことができる。基地局１１４ａ、１１４ｂの各々は、コアネットワーク１０６、インターネット１１０、および／またはネットワーク１１２などの１または複数の通信ネットワークへのアクセスを円滑化するために、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄの少なくとも１つと無線でインタフェースを取るように構成された、任意のタイプのデバイスとすることができる。例を挙げると、基地局１１４ａ、１１４ｂは、基地トランシーバ局（ＢＴＳ）、ノードＢ、ｅノードＢ、ホームノードＢ、ホームｅノードＢ、サイトコントローラ、アクセスポイント（ＡＰ）、および無線ルータなどとすることができる。基地局１１４ａ、１１４ｂは各々、単一の要素として示されているが、基地局１１４ａ、１１４ｂは、任意の数の相互接続された基地局および／またはネットワーク要素を含むことができることが理解されよう。

基地局１１４ａは、ＲＡＮ１０４の部分とすることができ、ＲＡＮ１０４は、他の基地局、および／または基地局コントローラ（ＢＳＣ）、無線ネットワークコントローラ（ＲＮＣ）、中継ノードなどのネットワーク要素（図示されず）も含むことができる。基地局１１４ａおよび／または基地局１１４ｂは、セル（図示されず）と呼ばれることがある特定の地理的領域内で、無線信号を送信および／または受信するように構成することができる。セルは、さらにセルセクタに分割することができる。例えば、基地局１１４ａに関連付けられたセルは、３つのセクタに分割することができる。したがって、一実施形態では、基地局１１４ａは、送受信機を３つ、すなわち、セルのセクタ毎に１つずつ含むことができる。別の実施形態では、基地局１１４ａは、多入力多出力（ＭＩＭＯ）技術を利用することができ、したがって、セルのセクタ毎に複数の送受信機を利用することができる。

基地局１１４ａ、１１４ｂは、エアインタフェース１１６を介して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄの１または複数と通信することができ、エアインタフェース１１６は、任意の適切な無線通信リンク（例えば、無線周波（ＲＦ）、マイクロ波、赤外線（ＩＲ）、紫外線（ＵＶ）、可視光など）とすることができる。エアインタフェース１１６は、任意の適切な無線アクセス技術（ＲＡＴ）を使用して確立することができる。

より具体的には、上で言及したように、通信システム１００は、多元接続システムとすることができ、ＣＤＭＡ、ＴＤＭＡ、ＦＤＭＡ、ＯＦＤＭＡ、およびＳＣ−ＦＤＭＡなどの、１または複数のチャネルアクセス方式を利用することができる。例えば、ＲＡＮ１０４内の基地局１１４ａ、およびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、広帯域ＣＤＭＡ（ＷＣＤＭＡ（登録商標））を使用してエアインタフェース１１６を確立できる、ユニバーサル移動体通信システム（ＵＭＴＳ）地上無線アクセス（ＵＴＲＡ）などの無線技術を実施することができる。ＷＣＤＭＡは、高速パケットアクセス（ＨＳＰＡ）および／または進化型ＨＳＰＡ（ＨＳＰＡ＋）などの通信プロトコルを含むことができる。ＨＳＰＡは、高速ダウンリンクパケットアクセス（ＨＳＤＰＡ）および／または高速アップリンクパケットアクセス（ＨＳＵＰＡ）を含むことができる。

別の実施形態では、基地局１１４ａ、およびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ロングタームエボリューション（ＬＴＥ）および／またはＬＴＥアドバンスト（ＬＴＥ−Ａ）を使用してエアインタフェース１１６を確立できる、進化型ＵＭＴＳ地上無線アクセス（Ｅ−ＵＴＲＡ）などの無線技術を実施することができる。

他の実施形態では、基地局１１４ａ、およびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ＩＥＥＥ８０２．１６（すなわちマイクロ波アクセス用の世界的相互運用性（ＷｉＭＡＸ））、ＣＤＭＡ２０００、ＣＤＭＡ２０００ １Ｘ、ＣＤＭＡ２０００ ＥＶ−ＤＯ、暫定標準２０００（ＩＳ−２０００）、暫定標準９５（ＩＳ−９５）、暫定標準８５６（ＩＳ−８５６）、移動体通信用グローバルシステム（ＧＳＭ（登録商標））、ＧＳＭエボリューション用の高速データレート（ＥＤＧＥ）、およびＧＳＭ ＥＤＧＥ（ＧＥＲＡＮ）などの無線技術を実施することができる。

図１Ａの基地局１１４ｂは、例えば、無線ルータ、ホームノードＢ、ホームｅノードＢ、またはアクセスポイントとすることができ、職場、家庭、乗物、およびキャンパスなどの局所的エリアにおける無線接続性を円滑化するために、任意の適切なＲＡＴを利用することができる。一実施形態では、基地局１１４ｂ、およびＷＴＲＵ１０２ｃ、１０２ｄは、ＩＥＥＥ８０２．１１などの無線技術を実施して、無線ローカルエリアネットワーク（ＷＬＡＮ）を確立することができる。別の実施形態では、基地局１１４ｂ、およびＷＴＲＵ１０２ｃ、１０２ｄは、ＩＥＥＥ８０２．１５などの無線技術を実施して、無線パーソナルエリアネットワーク（ＷＰＡＮ）を確立することができる。また別の実施形態では、基地局１１４ｂ、およびＷＴＲＵ１０２ｃ、１０２ｄは、セルラベースのＲＡＴ（例えば、ＷＣＤＭＡ、ＣＤＭＡ２０００、ＧＳＭ、ＬＴＥ、ＬＴＥ−Ａなど）を利用して、ピコセルまたはフェムトセルを確立することができる。図１Ａに示されるように、基地局１１４ｂは、インターネット１１０への直接的な接続を有することがある。したがって、基地局１１４ｂは、コアネットワーク１０６を介して、インターネット１１０にアクセスする必要がないことがある。

ＲＡＮ１０４は、コアネットワーク１０６と通信することができ、コアネットワーク１０６は、音声、データ、アプリケーション、および／またはボイスオーバインターネットプロトコル（ＶｏＩＰ）サービスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄの１または複数に提供するように構成された、任意のタイプのネットワークとすることができる。例えば、コアネットワーク１０６は、呼制御、請求サービス、モバイルロケーションベースのサービス、プリペイド通話、インターネット接続、ビデオ配信などを提供することができ、および／またはユーザ認証など、高レベルのセキュリティ機能を実行することができる。図１Ａには示されていないが、ＲＡＮ１０４および／またはコアネットワーク１０６は、ＲＡＮ１０４と同じＲＡＴまたは異なるＲＡＴを利用する他のＲＡＮと直接的または間接的に通信できることが理解されよう。例えば、Ｅ−ＵＴＲＡ無線技術を利用できるＲＡＮ１０４に接続するのに加えて、コアネットワーク１０６は、ＧＳＭ無線技術を利用する別のＲＡＮ（図示されず）と通信することもできる。

コアネットワーク１０６は、ＰＳＴＮ１０８、インターネット１１０、および／または他のネットワーク１１２にアクセスするための、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのためのゲートウェイとしてサービスすることもできる。ＰＳＴＮ１０８は、基本電話サービス（ＰＯＴＳ）を提供する回路交換電話網を含むことができる。インターネット１１０は、ＴＣＰ／ＩＰインターネットプロトコルスイート内の伝送制御プロトコル（ＴＣＰ）、ユーザデータグラムプロトコル（ＵＤＰ）、およびインターネットプロトコル（ＩＰ）など、共通の通信プロトコルを使用する、相互接続されたコンピュータネットワークとデバイスとからなるグローバルシステムを含むことができる。ネットワーク１１２は、他のサービスプロバイダによって所有および／または運営される有線または無線通信ネットワークを含むことができる。例えば、ネットワーク１１２は、ＲＡＮ１０４と同じＲＡＴまたは異なるＲＡＴを利用できる１または複数のＲＡＮに接続された、別のコアネットワークを含むことができる。

通信システム１００内のＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのいくつかまたはすべては、マルチモード機能を含むことができ、すなわち、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、異なる無線リンクを介して異なる無線ネットワークと通信するための複数の送受信機を含むことができる。例えば、図１Ａに示されたＷＴＲＵ１０２ｃは、セルラベースの無線技術を利用できる基地局１１４ａと通信するように、またＩＥＥＥ８０２無線技術を利用できる基地局１１４ｂと通信するように構成することができる。

図１Ｂは、例示的なＷＴＲＵ１０２のシステム図である。図１Ｂに示されるように、ＷＴＲＵ１０２は、プロセッサ１１８と、送受信機１２０と、送信／受信要素１２２と、スピーカ／マイクロフォン１２４と、キーパッド１２６と、ディスプレイ／タッチパッド１２８と、着脱不能メモリ１３０と、着脱可能メモリ１３２と、電源１３４と、全地球測位システム（ＧＰＳ）チップセット１３６と、他の周辺機器１３８とを含むことができる。ＷＴＲＵ１０２は、一実施形態との整合性を保ちながら、上記の要素の任意のサブコンビネーションを含むことができることが理解されよう。

プロセッサ１１８は、汎用プロセッサ、専用プロセッサ、従来型プロセッサ、デジタル信号プロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアと連携する１または複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、他の任意のタイプの集積回路（ＩＣ）、および状態機械（状態マシーン）などとすることができる。プロセッサ１１８は、信号符号化、データ処理、電力制御、入出力処理、および／またはＷＴＲＵ１０２が無線環境で動作することを可能にする他の任意の機能を実行することができる。プロセッサ１１８は、送受信機１２０に結合することができ、送受信機１２０は、送信／受信要素１２２に結合することができる。図１Ｂは、プロセッサ１１８と送受信機１２０を別々のコンポーネントとして示しているが、プロセッサ１１８と送受信機１２０は、電子パッケージまたはチップ内に一緒に統合できることが理解されよう。

送信／受信要素（エレメント）１２２は、エアインタフェース１１６を介して、基地局（例えば基地局１１４ａ）に信号を送信し、または基地局から信号を受信するように構成することができる。例えば、一実施形態では、送信／受信要素１２２は、ＲＦ信号を送信および／または受信するように構成されたアンテナとすることができる。別の実施形態では、送信／受信要素１２２は、例えば、ＩＲ、ＵＶ、または可視光信号を送信および／または受信するように構成された放射器／検出器とすることができる。また別の実施形態では、送信／受信要素１２２は、ＲＦ信号と光信号の両方を送信および受信するように構成することができる。送信／受信要素１２２は、無線信号の任意の組み合わせを送信および／または受信するように構成できることが理解されよう。

加えて、図１Ｂでは、送信／受信要素１２２は単一の要素として示されているが、ＷＴＲＵ１０２は、任意の数の送信／受信要素１２２を含むことができる。より具体的には、ＷＴＲＵ１０２は、ＭＩＭＯ技術を利用することができる。したがって、一実施形態では、ＷＴＲＵ１０２は、エアインタフェース１１６を介して無線信号を送信および受信するための２つ以上の送信／受信要素１２２（例えば複数のアンテナ）を含むことができる。

送受信機１２０は、送信／受信要素１２２によって送信される信号を変調し、送信／受信要素１２２によって受信された信号を復調するように構成することができる。上で言及したように、ＷＴＲＵ１０２は、マルチモード機能を有することができる。したがって、送受信機１２０は、ＷＴＲＵ１０２が、例えばＵＴＲＡおよびＩＥＥＥ８０２．１１などの複数のＲＡＴを介して通信することを可能にするための、複数の送受信機を含むことができる。

ＷＴＲＵ１０２のプロセッサ１１８は、スピーカ／マイクロフォン１２４、キーパッド１２６、および／またはディスプレイ／タッチパッド１２８（例えば、液晶表示（ＬＣＤ）ディスプレイユニットもしくは有機発光ダイオード（ＯＬＥＤ）ディスプレイユニット）に結合することができ、それらからユーザ入力データを受け取ることができる。プロセッサ１１８は、スピーカ／マイクロフォン１２４、キーパッド１２６、および／またはディスプレイ／タッチパッド１２８にユーザデータを出力することもできる。加えて、プロセッサ１１８は、着脱不能メモリ１３０および／または着脱可能メモリ１３２など、任意のタイプの適切なメモリから情報を入手することができ、それらにデータを記憶することができる。着脱不能メモリ１３０は、ランダムアクセスメモリ（ＲＡＭ）、リードオンリメモリ（ＲＯＭ）、ハードディスク、または他の任意のタイプのメモリ記憶デバイスを含むことができる。着脱可能メモリ１３２は、加入者識別モジュール（ＳＩＭ）カード、メモリスティック、およびセキュアデジタル（ＳＤ）メモリカードなどを含むことができる。他の実施形態では、プロセッサ１１８は、ＷＴＲＵ１０２上に物理的に配置されたメモリではなく、サーバまたはホームコンピュータ（図示されず）などの上に配置されたメモリから情報を入手することができ、それらにデータを記憶（ストア）することができる。

プロセッサ１１８は、電源１３４から電力を受け取ることができ、ＷＴＲＵ１０２内の他のコンポーネントへの電力の分配および／または制御を行うように構成することができる。電源１３４は、ＷＴＲＵ１０２に給電するための任意の適切なデバイスとすることができる。例えば、電源１３４は、１または複数の乾電池（例えば、ニッケル−カドミウム（ＮｉＣｄ）、ニッケル−亜鉛（ＮｉＺｎ）、ニッケル水素（ＮｉＭＨ）、リチウムイオン（Ｌｉ−ｉｏｎ）など）、太陽電池、および燃料電池などを含むことができる。

プロセッサ１１８は、ＧＰＳチップセット１３６に結合することもでき、ＧＰＳチップセット１３６は、ＷＴＲＵ１０２の現在位置に関する位置情報（例えば経度および緯度）を提供するように構成することができる。ＧＰＳチップセット１３６からの情報に加えて、またはその代わりに、ＷＴＲＵ１０２は、基地局（例えば基地局１１４ａ、１１４ｂ）からエアインタフェース１１６を介して位置情報を受け取ることができ、および／または２つ以上の近くの基地局から受信した信号のタイミングに基づいて、自らの位置を決定することができる。ＷＴＲＵ１０２は、一実施形態との整合性を保ちながら、任意の適切な位置決定方法を用いて、位置情報を獲得できることが理解されよう。

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

図１Ｃは、一実施形態による、ＲＡＮ１０４およびコアネットワーク１０６のシステム図である。上で言及したように、ＲＡＮ１０４は、ＵＴＲＡ無線技術を利用して、エアインタフェース１１６を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信することができる。ＲＡＮ１０４は、コアネットワーク１０６とも通信することができる。図１Ｃに示されるように、ＲＡＮ１０４は、ノードＢ１４０ａ、１４０ｂ、１４０ｃを含むことができ、ノードＢ１４０ａ、１４０ｂ、１４０ｃは各々、エアインタフェース１１６を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するための１または複数の送受信機を含むことができる。ノードＢ１４０ａ、１４０ｂ、１４０ｃは各々、ＲＡＮ１０４内の特定のセル（図示されず）に関連付けることができる。ＲＡＮ１０４は、ＲＮＣ１４２ａ、１４２ｂも含むことができる。ＲＡＮ１０４は、一実施形態との整合性を保ちながら、任意の数のノードＢおよびＲＮＣを含むことができることが理解されよう。

図１Ｃに示されるように、ノードＢ１４０ａ、１４０ｂは、ＲＮＣ１４２ａと通信することができる。加えて、ノードＢ１４０ｃは、ＲＮＣ１４２ｂと通信することができる。ノードＢ１４０ａ、１４０ｂ、１４０ｃは、Ｉｕｂインタフェースを介して、それぞれのＲＮＣ１４２ａ、１４２ｂと通信することができる。ＲＮＣ１４２ａ、１４２ｂは、Ｉｕｒインタフェースを介して、互いに通信することができる。ＲＮＣ１４２ａ、１４２ｂの各々は、それが接続されたそれぞれのノードＢ１４０ａ、１４０ｂ、１４０ｃを制御するように構成することができる。加えて、ＲＮＣ１４２ａ、１４２ｂの各々は、アウタループ電力制御、負荷制御、アドミッションコントロール、パケットスケジューリング、ハンドオーバ制御、マクロダイバーシティ、セキュリティ機能、およびデータ暗号化など、他の機能を実施またはサポートするように構成することができる。

図１Ｃに示されるコアネットワーク１０６は、メディアゲートウェイ（ＭＧＷ）１４４、モバイル交換センタ（ＭＳＣ）１４６、サービングＧＰＲＳサポートノード（ＳＧＳＮ）１４８、および／またはゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）１５０を含むことができる。上記の要素の各々は、コアネットワーク１０６の部分として示されているが、これらの要素は、どの１つをとっても、コアネットワーク運営体とは異なる主体によって所有および／または運営できることが理解されよう。

ＲＡＮ１０４内のＲＮＣ１４２ａは、ＩｕＣＳインタフェースを介して、コアネットワーク１０６内のＭＳＣ１４６に接続することができる。ＭＳＣ１４６は、ＭＧＷ１４４に接続することができる。ＭＳＣ１４６とＭＧＷ１４４は、ＰＳＴＮ１０８などの回路交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと従来の陸線通信デバイスの間の通信を円滑化することができる。

ＲＡＮ１０４内のＲＮＣ１４２ａは、ＩｕＰＳインタフェースを介して、コアネットワーク１０６内のＳＧＳＮ１４８にも接続することができる。ＳＧＳＮ１４８は、ＧＧＳＮ１５０に接続することができる。ＳＧＳＮ１４８とＧＧＳＮ１５０は、インターネット１１０などのパケット交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとＩＰ対応デバイスの間の通信を円滑化することができる。

上で言及したように、コアネットワーク１０６は、ネットワーク１１２にも接続することができ、ネットワーク１１２は、他のサービスプロバイダによって所有および／または運営される他の有線または無線ネットワークを含むことができる。

図１Ｄは、別の実施形態による、ＲＡＮ１０４およびコアネットワーク１０６のシステム図である。上で言及したように、ＲＡＮ１０４は、エアインタフェース１１６を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するために、Ｅ−ＵＴＲＡ無線技術を利用することができる。ＲＡＮ１０４は、コアネットワーク１０６と通信することもできる。

ＲＡＮ１０４は、ｅノードＢ１６０ａ、１６０ｂ、１６０ｃを含むことができるが、ＲＡＮ１０４は、一実施形態との整合性を保ちながら、任意の数のｅノードＢを含むことができることが理解されよう。ｅノードＢ１６０ａ、１６０ｂ、１６０ｃは、各々が、エアインタフェース１１６を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するための１または複数の送受信機を含むことができる。一実施形態では、ｅノードＢ１６０ａ、１６０ｂ、１６０ｃは、ＭＩＭＯ技術を実施することができる。したがって、ｅノードＢ１６０ａは、例えば、複数のアンテナを使用して、ＷＴＲＵ１０２ａに無線信号を送信し、ＷＴＲＵ１０２ａから無線信号を受信することができる。

ｅノードＢ１６０ａ、１６０ｂ、１６０ｃの各々は、特定のセル（図示されず）に関連付けることができ、無線リソース管理決定、ハンドオーバ決定、ならびにアップリンクおよび／またはダウンリンクにおけるユーザのスケジューリングなどを処理するように構成することができる。図１Ｄに示されるように、ｅノードＢ１６０ａ、１６０ｂ、１６０ｃは、Ｘ２インタフェースを介して互いに通信することができる。

図１Ｄに示されるコアネットワーク１０６は、モビリティ管理エンティティ（ＭＭＥ）１６２、サービングゲートウェイ１６４、およびパケットデータネットワーク（ＰＤＮ）ゲートウェイ１６６を含むことができる。上記の要素の各々は、コアネットワーク１０６の部分として示されているが、これらの要素は、どの１つをとっても、コアネットワーク運営体とは異なる主体によって所有および／または運営できることが理解されよう。

ＭＭＥ１６２は、Ｓ１インタフェースを介して、ＲＡＮ１０４内のｅノードＢ１６０ａ、１６０ｂ、１６０ｃの各々に接続することができ、制御ノードとしての役割を果たすことができる。例えば、ＭＭＥ１６２は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのユーザの認証、ベアラアクティブ化／非アクティブ化、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃの初期接続中における特定のサービングゲートウェイの選択などを担うことができる。ＭＭＥ１６２は、ＲＡＮ１０４とＧＳＭまたはＷＣＤＭＡなどの他の無線技術を利用する他のＲＡＮ（図示されず）との間の交換のためのコントロールプレーン機能を提供することもできる。

サービングゲートウェイ１６４は、Ｓ１インタフェースを介して、ＲＡＮ１０４内のｅノードＢ１６０ａ、１６０ｂ、１６０ｃの各々に接続することができる。サービングゲートウェイ１６４は、一般に、ユーザデータパケットのＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃへの／からの経路選択および転送を行うことができる。サービングゲートウェイ１６４は、ｅノードＢ間ハンドオーバ中におけるユーザプレーンのアンカリング（ａｎｃｈｏｒｉｎｇ）、ダウンリンクデータがＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに利用可能な場合に行う一斉呼出のトリガ、ならびにＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのコンテキストの管理および記憶など、他の機能を実行することもできる。

サービングゲートウェイ１６４は、ＰＤＮゲートウェイ１６６に接続することもでき、ＰＤＮゲートウェイ１６６は、インターネット１１０などのパケット交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとＩＰ対応デバイスの間の通信を円滑化することができる。

コアネットワーク１０６は、他のネットワークとの通信を円滑化することができる。例えば、コアネットワーク１０６は、ＰＳＴＮ１０８などの回路交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと従来の陸線通信デバイスの間の通信を円滑化することができる。例えば、コアネットワーク１０６は、コアネットワーク１０６とＰＳＴＮ１０８の間のインタフェースとしての役割を果たすＩＰゲートウェイ（例えばＩＰマルチメディアサブシステム（ＩＭＳ）サーバ）を含むことができ、またはＩＰゲートウェイと通信することができる。加えて、コアネットワーク１０６は、ネットワーク１１２へのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供することができ、ネットワーク１１２は、他のサービスプロバイダによって所有および／または運営される他の有線または無線ネットワークを含むことができる。

図１Ｅは、別の実施形態による、ＲＡＮ１０４およびコアネットワーク１０６のシステム図である。ＲＡＮ１０４は、ＩＥＥＥ８０２．１６無線技術を利用して、エアインタフェース１１６を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信する、アクセスサービスネットワーク（ＡＳＮ）とすることができる。以下でさらに説明するように、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、ＲＡＮ１０４、およびコアネットワーク１０６の異なる機能エンティティ間の通信リンクは、参照点として定義することができる。

図１Ｅに示されるように、ＲＡＮ１０４は、基地局１７０ａ、１７０ｂ、１７０ｃと、ＡＳＮゲートウェイ１７２とを含むことができるが、ＲＡＮ１０４は、一実施形態との整合性を保ちながら、任意の数の基地局とＡＳＮゲートウェイとを含むことができることが理解されよう。基地局１７０ａ、１７０ｂ、１７０ｃは、各々が、ＲＡＮ１０４内の特定のセル（図示されず）に関連付けることができ、各々が、エアインタフェース１１６を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するための１または複数の送受信機を含む。一実施形態では、基地局１７０ａ、１７０ｂ、１７０ｃは、ＭＩＭＯ技術を実施することができる。したがって、基地局１７０ａは、例えば、複数のアンテナを使用して、ＷＴＲＵ１０２ａに無線信号を送信し、ＷＴＲＵ１０２ａから無線信号を受信することができる。基地局１７０ａ、１７０ｂ、１７０ｃは、ハンドオフトリガリング、トンネル確立、無線リソース管理、トラフィック分類、およびサービス品質（ＱｏＳ）ポリシ実施などの、モビリティ管理機能も提供することができる。ＡＳＮゲートウェイ１７２は、トラフィック集約ポイントとしてサービスすることができ、ページング、加入者プロファイルのキャッシング、およびコアネットワーク１０６へのルーティングなどを担うことができる。

ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとＲＡＮ１０４の間のエアインタフェース１１６は、ＩＥＥＥ８０２．１６仕様を実施する、Ｒ１参照点として定義することができる。加えて、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃの各々は、コアネットワーク１０６との論理インタフェース（図示されず）を確立することができる。ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとコアネットワーク１０６の間の論理インタフェースは、Ｒ２参照点として定義することができ、Ｒ２参照点は、認証、認可、ＩＰホスト構成管理、および／またはモビリティ管理のために使用することができる。

基地局１７０ａ、１７０ｂ、１７０ｃの各々の間の通信リンクは、ＷＴＲＵハンドオーバおよび基地局間でのデータの転送を円滑化するためのプロトコルを含む、Ｒ８参照点として定義することができる。基地局１７０ａ、１７０ｂ、１７０ｃとＡＳＮゲートウェイ１７２の間の通信リンクは、Ｒ６参照点として定義することができる。Ｒ６参照点は、ＷＴＲＵ１０２ａ、１０２ｂ、１００ｃの各々に関連するモビリティイベントに基づいたモビリティ管理を円滑化するためのプロトコルを含むことができる。

図１Ｅに示されるように、ＲＡＮ１０４は、コアネットワーク１０６に接続することができる。ＲＡＮ１０４とコアネットワーク１０６の間の通信リンクは、例えばデータ転送およびモビリティ管理機能を円滑化するためのプロトコルを含む、Ｒ３参照点として定義することができる。コアネットワーク１０６は、モバイルＩＰホームエージェント（ＭＩＰ−ＨＡ）１７４と、認証認可課金（ＡＡＡ）サーバ１７６と、ゲートウェイ１７８とを含むことができる。上記の要素の各々は、コアネットワーク１０６の部分として示されているが、これらの要素は、どの１つをとっても、コアネットワーク運営体とは異なる主体によって所有および／または運営できることが理解されよう。ＭＩＰ−ＨＡ１７４は、ＩＰアドレス管理を担うことができ、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃが、異なるＡＳＮの間で、および／または異なるコアネットワーク１０６の間でローミングを行うことを可能にすることができる。ＭＩＰ−ＨＡ１７４は、インターネット１１０などのパケット交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとＩＰ対応デバイスの間の通信を円滑化することができる。ＡＡＡサーバ１７６は、ユーザ認証、およびユーザサービスのサポートを担うことができる。ゲートウェイ１７８は、他のネットワークとの網間接続を円滑化することができる。例えば、ゲートウェイ１７８は、ＰＳＴＮ１０８などの回路交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと従来の陸線通信デバイスの間の通信を円滑化することができる。加えて、ゲートウェイ１７８は、ネットワーク１１２へのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供し、ネットワーク１１２は、他のサービスプロバイダによって所有および／または運営される他の有線または無線ネットワークを含むことができる。図１Ｅには示されていないが、ＲＡＮ１０４は、他のＡＳＮに接続でき、コアネットワーク１０６は、他のコアネットワークに接続できることが理解されよう。ＲＡＮ１０４と他のＡＳＮの間の通信リンクは、Ｒ４参照点として定義することができ、Ｒ４参照点は、ＲＡＮ１０４と他のＡＳＮの間で、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのモビリティを調整するためのプロトコルを含むことができる。コアネットワーク１０６と他のコアネットワークの間の通信リンクは、Ｒ５参照として定義することができ、Ｒ５参照は、ホームコアネットワークと在圏コアネットワークの間の網間接続を円滑化するためのプロトコルを含むことができる。

一般に、マシンツーマシン（Ｍ２Ｍ）通信、または３ＧＰＰによってそう呼ばれることがあるマシンタイプコミュニケーション（ＭＴＣ）は、必ずしも人間の介入を必要としない、エンティティ間のデータ通信の形態である。ＭＴＣデバイスおよびスマートサービスの提供は、ヘルスケア、製造業、公益事業、小売業、流通業、および消費者製品を含むが、これらに限定されない、多種多様な市場セグメントおよび用途にわたって行うことができる。ＭＴＣデバイスは、電力会社が、回路遮断器、変圧器、および他の変電所機器などの送電網資産に無線で接続することを可能にする、スマートグリッド技術を可能にすることができる。

ＭＴＣデバイスおよび関連するＭ２Ｍ通信が、そのような急速に拡大するセクタとなるのに伴って、消費されるネットワークリソースの増大が、解決すべき問題となっている。３ＧＰＰは、マシンタイプコミュニケーション（ＭＴＣ）をサポートする３ＧＰＰネットワークシステム改良に必要な要件を確立する途上にある。３ＧＰＰシステムによって提供されるようなＭＴＣのためのトランスポートサービス、および関連する最適化が、ＭＴＣデバイス、ＭＴＣサーバ、および／またはＭＴＣアプリケーションがネットワーク輻輳またはシステム過負荷を引き起こさないことを保証するのに必要な態様とともに、検討されている。マスマーケットのマシンタイプサービスおよび用途に対する期待を満たすには、ネットワーク事業者が、低いコストレベルでＭＴＣサービスを提供することを可能にすることも重要である。

ＭＴＣデバイスのために追求すべき１つの目標は、多数のＭＴＣデバイスに対する接続性（Connectivity）を効率的に維持することである。ＭＴＣデバイスは、「高可用性(High availability)」用途向けに分類することができる。「高可用性」ＭＴＣデバイスのカテゴリは、データの送信が通常は緊急イベントに結び付けられているので、ネットワーク接続がほとんどの時間利用可能でなければならない用途を含むことができる。例えば、効率的に維持される接続性を必要とするＭＴＣデバイスは、セキュリティモニタリング、火災報知器、洪水検出器など、公衆安全用途および／またはセキュリティ関連用途のために配備することができる。そのようなＭＴＣデバイスの場合、アップリンク通信とダウンリンク通信の両方が、ネットワークシステムにおける高い接続性を必要とし得る。したがって、遅延を許容するようなシステム通信設定にすることはできない。この観点から、そのようなＭＴＣデバイスは、ネットワークへのアクセスに関して、およびネットワークリソースの使用に関して、通常のＭＴＣデバイスよりも「高いプライオリティ」を有すると見なすことができる。

汎用パケット無線サービス（ＧＰＲＳ）／進化型パケットシステム（ＥＰＳ）では、ＵＥがネットワークにアクセスし、ＩＰアドレスを獲得した後、アプリケーションレイヤの観点からは、それを「常時接続(always on)」ＵＥと見なすことができる。そのようなＵＥの場合、多数のＭＴＣデバイスに対する接続性を効率的に維持するという目標は、アクセスされるいくつかのＵＥにできるだけ速やかにアクセスすることを含むことができる。そのようなＭＴＣデバイスの場合、ネットワークにおける接続性を効率的に維持することが望まれることがある。言い換えると、そのようなＭＴＣデバイスは、ネットワークにおいて「常時接続」デバイスとして、また「できるだけ速やかにアクセスされる」デバイスとして扱われることが期待されることがある。

多数のＭＴＣデバイスに対する接続性を効率的に維持することを促進する機能は、ＭＴＣデバイスがＭＴＣサーバへの接続をできるだけ速やかに設定するための能力、ＭＴＣサーバがＭＴＣデバイスへの接続をできるだけ速やかに設定するための能力、多数のＭＴＣデバイスに対する接続性を効率的に維持するための、ネットワークにおけるリソース消費を低減させる能力、およびモビリティ管理手順およびセッション管理手順を最適化する能力を含むことができる。さらに、ネットワークは、接続性を維持するために使用されるシグナリングリソースを削減する機構、および接続性イベント（例えば、接続性の設定、切断、喪失など）に効果的かつ迅速に応答できる機構を有することができる。ネットワークノード（例えば、ＭＭＥ／ＳＧＳＮ、Ｓ−ＧＷ、Ｐ−ＧＷ）は、ＭＴＣ用に構成されたＵＥの接続性のための計算リソース（例えば、ＣＰＵサイクル、コンテキストのためのメモリなど）の使用を削減する機構を有することができる。

「常時接続」ＵＥの場合、ネットワークは、ネットワークにおけるＵＥコンテキストを維持する必要がある。多数のＭＴＣデバイスが「常時接続」状態にある場合、ネットワークは、多数のそのようなコンテキストを維持する必要があり得、これは、大量のネットワークリソース消費をもたらし得る。いくつかの実施形態では、本明細書で説明されるシステムおよび方法は、ネットワークリソース消費も考慮しながら、多数のＭＴＣデバイスに対する接続性を効率的に維持するという目標に対処することができる。

モバイル発信（ＭＯ：ｍｏｂｉｌｅ ｏｒｉｇｉｎａｔｅｄ）通信とモバイル着信（ＭＴ：ｍｏｂｉｌｅ ｔｅｒｍｉｎａｔｅｄ）通信の両方をできるだけ速やかに確立すべきことを考慮して、ネットワークは、輻輳状態または過負荷状態にある場合であっても、そのようなＭＴＣデバイスに、通常のＭＴＣデバイスと比較して、より高いプライオリティで、ネットワークリソースを割り当てることができるべきである。接続は、そのようなＭＴＣデバイスに対しては、ほとんどの時間、利用可能であるべきであり、または迅速に確立できるべきである。

それに対する接続性を効率的に維持することが望ましいＭＴＣデバイスをサポートするために、本明細書で説明される詳細なネットワーク能力および機能は、接続性共有（connectivity sharing）および維持効率とともに、ネットワークリソース消費を低減させるという目的と、可能なＭＴＣデバイスモビリティ管理およびセッション管理を容易にするという目的とに対処する。コアネットワークリソースとＬＴＥ無線アクセスネットワークリソースの両方における、ＭＴＣ接続性エンティティ生成、共有、および維持のための機構も、本明細書で説明される。

さらに、ＭＴＣデバイスがネットワーク接続性共有構成を受け取るための機構、および異なるＭＴＣデバイスを異なる共有可能接続性エンティティに分類するための方法が、本明細書で説明される。ＭＴＣデバイス共有可能データ形式および関連するルーティング方法も、本明細書で説明される。

本開示において使用される場合、「トラフィック」という用語は、アプリケーションデータトラフィック、アプリケーションシグナリングトラフィック、またはアプリケーションレイヤよりも下でＷＴＲＵとネットワークとの間で生成および交換されるシグナリング、もしくはネットワークノード間で生成および交換されるシグナリングトラフィックを広く指すことができる。さらに、ｅノードＢは、ノードＢ、ＲＮＣ、ホームｅノードＢ、ホームノードＢ、またはホームノードＢゲートウェイも指すことができる。同様に、ＭＭＥは、サービングＧＰＲＳサポートノード（ＳＧＳＮ）、またはＭＳＣ／ＶＬＲも指すことができる。したがって、本明細書で説明されるシステムおよび方法は、いずれか特定のタイプのアクセスネットワークに限定されず、代わりに、多種多様なアクセスネットワーク技術に適用することができる。アクセスネットワークは、例えば、（ｉ）デジタル加入者回線技術（一括して「ｘＤＳＬ」と呼ばれる）、（ｉｉ）ハイブリッド光ファイバ同軸ケーブル（ＨＦＣ）ネットワーク、（ｉｉｉ）プログラマブルロジックコントローラ（ＰＬＣ）、（ｉｖ）衛星通信およびネットワーク、（ｖ）移動体通信用グローバルシステム（ＧＳＭ）／拡張データＧＳＭ環境（ＥＤＧＥ）無線アクセスネットワーク（ＧＥＲＡＮ）、（ｖｉ）ユニバーサル移動体通信システム（ＵＭＴＳ）地上無線アクセスネットワーク（ＵＴＲＡＮ）、（ｖｉｉ）進化型ＵＴＲＡＮ（ｅＵＴＲＡＮ）、（ｖｉｉｉ）無線ローカルエリアネットワーク（ＷＬＡＮ）およびマイクロ波アクセス用の世界的相互運用性（ＷｉＭＡＸ）などのための１または複数のプロトコルに従った通信のために構成されたネットワークとすることができる。

本明細書で説明されるシステムおよび方法は、ＭＴＣデータ経路共有または接続性共有を提供する。様々な実施形態によれば、ＭＴＣデバイスがデバイスから終点のＭＴＣサーバもしくは宛先にデータを送信するときに、または逆方向にデータが送信されるときに、複数のＭＴＣデバイスは、ネットワークにおいて、同じ論理および／または物理データ経路と、経路が通過するネットワークノード／エンティティとを共有する。データ経路または接続性は、以下でより詳細に説明するように、トラフィックエンドツーエンドの全行程または２つのノード間のセグメントにわたることができる。一般に、本明細書で説明されるＭＴＣデータ接続性共有は、多数のＭＴＣデバイスによって消費されるネットワークリソースを低減させることができ、シグナリング過負荷およびネットワーク管理オーバヘッドも低減させることができる。

図２は、非限定的な一実施形態による、様々なＭＴＣトラフィック経路を示すシステム図である。図２に示されるように、ネットワーク２００におけるノード間の様々な可能なルート（例えば、ネットワークセグメントまたは接続性セグメント）は、共有することができる。ｅノードＢ２０２、２０４から出発する共有可能ルートは、ＭＭＥ２０６へのルート、サービングゲートウェイ（Ｓ−ＧＷ）２０８へのルート、およびローカルＩＰアドレスもしくはＩＰオフロードが使用される場合、またはこれらのデバイスによる使用が可能なＬＧＷが配備されている場合は、ローカルＧＷ（ＬＧＷ）２１０へのルートを含むことができる。Ｓ−ＧＷ２０８から出発する共有可能ルートは、特定のＭＴＣサーバ２１６、２１８がそれを介して接続される、特定のＰ−ＧＷ２１２、２１４またはＬＧＷ（ＡＰＮ）２１０へのルート、すべてのＭＴＣサーバがその１つのＰ−ＧＷ２１２、２１４を介してこのコアネットワーク（ＣＮ）に接続される場合は、汎用のＰ−ＧＷ２１２、２１４またはＬＧＷ２１０へのルート、そのＭＴＣデバイスのためのＩＰポイントオブプレゼンス（Ｐｏｉｎｔ ｏｆ Ｐｒｅｓｅｎｃｅ）であるＰ−ＧＷ２１２、２１４またはＬＧＷ２１０へのルート、およびＣＮとＭＴＣサーバとの間のすべてのＭＴＣ関連トラフィックを処理する、ＭＴＣ−ＧＷまたはＭＴＣ−ＩＷＦまたはＭＴＣ−ＳＭＳなどの、ＣＮ内の可能なＭＴＣ固有ノードへのルートを含むことができる。理解されるように、ＭＴＣ固有ノードは、ｅノードＢ、ＭＭＥ、ＳＧＷ、もしくはＰＤＮ ＧＷ、またはそのようなノードの任意の組み合わせに接続することができる。ＭＭＥ２０６から出発する共有可能ルートは、後で続いてＰ−ＧＷ２１２、２１４に、または上で説明されたようなＭＴＣ−ＧＷなどのＭＴＣ固有ノードに接続される、Ｓ−ＧＷ２０８へのルート、およびＣＮとＭＴＣサーバとの間のすべてのＭＴＣ関連トラフィックを処理する、上で説明されたようなＭＴＣ−ＧＷもしくはＭＴＣ−ＩＷＦもしくはＭＴＣ−ＳＭＳなどの、ＣＮ内の可能なＭＴＣ固有ノードへのルートを含むことができる。

図２の共有可能ルートは、ＬＴＥ／Ｅ−ＵＴＲＡＮに関連して説明されているが、本開示は、そのようには限定されない。類似のシステムおよび方法は、ｅノードＢがノードＢによって表される、ＵＴＲＡＮまたはＧＲＥＡＮなどの、他のアクセスネットワークにも適用することができる。加えて、ＲＮＣが、ノードＢとＣＮノードとの間に存在することができる。したがって、ＵＴＲＡＮ／ＧＥＲＡＮの場合、上で列挙されたものと同じ接続性経路も当てはまる。さらに、ＲＮＣ／ＨＮｏｄｅＢ／ＨＮｏｄｅＢ ＧＷは、経路の中間に存在することができ、または経路の終点となることもできる。共有される経路は、ＣＳドメインリソースにおいても利用することができ、例えば、ＭＳＣ／ＶＬＲがＳＧＳＮ／ＭＭＥに取って代わり得るなど、最小限の変更を施すだけで、本明細書におけるのと同じ提案が当てはまる。

さらに、図２に示される１または複数のＭＴＣデバイスは、ＭＴＣデバイスアグリゲーションノードまたはＭＴＣデバイス集中ノード（すなわち、ＭＴＣデバイスのネットワーク）とすることができる。したがって、各個別ＭＴＣデバイスは、ＲＡＮまたはコアネットワークから直接的に見えることもあり、または見えないこともある。例えば、ＭＴＣアグリゲーションノードは、ＲＡＮまたはコアネットワークから見え、一方、個々のＭＴＣデバイスは、ＭＴＣサーバから見える。さらに、個々のＭＴＣデバイスとＭＴＣデバイスアグリゲーションノードとの間の接続は、ＭＴＣデバイスアグリゲーションノードとセルラネットワークとの間の接続と同じアクセス技術を使用しても良いし、または使用しなくても良い。例えば、個々のＭＴＣデバイスとＭＴＣデバイスアグリゲーションノードとの間の接続は、Ｂｌｕｅｔｏｏｔｈ技術を使用することができ、一方、ＭＴＣデバイスアグリゲーションノードとリモートＭＴＣサーバとの間の接続は、セルラネットワーク接続を使用することができる。ＭＴＣデバイスアグリゲーションノードは、ＵＥ、通常のｅノードＢ、中継ノード、またはホームｅノードＢなどの形態を取ることができる。

いくつかの実施形態では、ＭＴＣデバイスは、経路共有について最初から知っていても良いし、もしくは知らなくても良いし、または共有を最初から許可されても良いし、もしくは許可されなくても良い。いくつかの実施形態では、デバイスが、そのアプリケーションまたはトラフィックに対して、定められた期間にわたることができる、または他のメトリックを条件とすることができる共有が許可されることを明示的に示した後にだけ、共有を行うことができる。

一般に、ＭＴＣデータ経路共有は、ｅノードＢ、ノードＢ、またはＲＮＣ／ＨＮｏｄｅＢ／ＨＮｏｄｅＢ ＧＷなどの、しかしこれらに限定されない、基地局から開始することができる。そこから、最終的な宛先、例えば、ＭＴＣサーバに到るまでの、途中のいずれか２つのノード間の、接続性経路の複数のセグメントを、トラフィックのために使用することができる。各セグメントは、異なる共有属性についての１または複数のインスタンスを有することができる。特に３Ｇ ＵＴＲＡＮアクセスネットワークに関しては、接続性経路は、ノードＢとＲＮＣとの間のセグメントを含むことができる。

システムアクティビティとしては、ＭＴＣ接続性共有は、ネットワークノードに電源が入り、ネットワークノードが初期化されたときに、有効にする（例えば、アクティブ化する）ことができる。いくつかの実施形態では、１または複数のセグメントについてのＭＴＣ接続性共有（または共有経路）は、以下の条件のうちの１または複数からなる任意の組み合わせが満たされた後にだけ、有効にする、または開始することができる。

（１）Ｎを事前定義（例えば、通信事業者によって設定）され得る整数とした場合に、接続を共有するのに利用可能な、または接続を共有する用意があるＮ個のデバイスが存在する。

（２）接続性は、知られた／事前設定された時間内だけ共有することができる。

（３）接続性は、特定のモード（例えば、遅延を許容できる、時間制御される、ＭＯトラフィックを実行するデバイスなど）またはモードの組み合わせで動作しているデバイスのグループによってだけ共有することができる。

（４）接続性共有は、ＵＥからの、またはＣＮノード、例えば、ＭＭＥもしくはホーム加入者サーバ（ＨＳＳ）からの明示的な指示の結果として行うことができる。および／あるいは
（５）接続性共有は、特定のタイプのアプリケーションが必要とされるとき、またはトラフィックが特定のＱｏＳを必要とするとき、またはトラフィックが特定の形態（例えば、ＳＭＳなど）を取るときに開始することができる。

他の実施形態では、他の条件を定義することができる。限定することなく、例を挙げると、パケット交換（ＰＳ）ドメイン上でだけ、または回路交換（ＣＳ）ドメイン上でだけ、接続性共有を行うことができるという条件を定義することができる。別の例として、トラフィックがＣＳベースまたはＰＳベースであるときだけ、接続性共有を行うことができるという条件を定義することができる。

いくつかの実施形態では、ＭＴＣ接続性共有は、以下の条件のうちの１または複数からなる任意の組み合わせが満たされた後に、終了することができる。

（１）Ｎを、例えば、通信事業者によって定義され得る整数とした場合に、共有デバイスの数がＮを下回った。

（２）共有時間間隔が終了したとき。

（３）デバイスの動作モードがあるモードから別のモードに変化したとき（いくつかの実施形態では、ＭＴＣ接続性共有の終了をトリガする実際のモード変化は、ネットワーク通信事業者によって定義することができる）。

（４）ＵＥが（例えば、ネットワークから）、またはネットワークが（例えば、ＵＥ、もしくは、ＨＳＳ、もしくはＭＴＣサーバ、もしくはＭＴＣピアから）明示的な指示を受け取った。および／あるいは
（５）リソースを共有できないような、特定のＱｏＳが必要とされたとき。

接続性共有を開始および／または終了するために、あるノードが明示的な指示を必要とする場合、指示は、様々なネットワークインタフェースを介する、ＮＡＳ、ＲＲＣ、または他の制御メッセージ（例えば、ＯＭＡ ＤＭ、ＯＴＡ、ＳＭＳなど）の形態を取ることができる。

ネットワークおよび／またはＵＥは、様々な要因に基づいて、共有される特定の経路を選択することができる。限定することなく、例を挙げると、特定の経路上または特定の１組の経路上のネットワーク負荷を考慮することができる。特定の経路が輻輳しており、その経路上の接続を必要とするデバイスが複数存在する場合、デバイス毎にリソースを確保するせいで、その経路上でネットワーク負荷が増加しないように、ネットワークは、これらのデバイスに接続／リソースを共有させることを決定することができる。ネットワークおよび／またはＵＥによって考慮される別の要因は、デバイス加入情報とすることができる。デバイス加入情報は、エンドツーエンドまたは特定のセグメントなど、どの経路を、どのタイプのトラフィックの場合に、どの時間に、または上述の基準および他の基準のいずれの場合に、共有すべきかを定義することができる。いくつかの実施形態では、加入情報は、デバイスと共有されないことが明示されたリソースを使用することがＵＥに許可されているかどうかも定義することができる。

本明細書で使用される場合、ＭＴＣ共有可能データトラフィックは、別のＭＴＣデバイスからの／への別の共有可能データトラフィックと一緒に論理経路および／または物理経路において送信できる、ＭＴＣデバイスからの、またはＭＴＣデバイスへの指定されたＭＴＣトラフィック（例えば、すべてのＭＴＣトラフィックまたは定められた１組のＭＴＣトラフィック）を含む。一般に、ＭＴＣ接続性共有は、以下の原理を利用することができる。開始地点から終了地点までのＭＴＣトラフィック経路が、その経路上に２つ以上の（終点のＭＴＣサーバを含むが、ＭＴＣデバイス自体は除外される、Ｎ個の）ネットワークノードを有すると仮定すると、ネットワークを通過する経路の全行程は、（Ｎ−１）個のセグメントを含む。例えば、図２を参照すると、ＭＴＣ−１とＭＴＣサーバ１との間の１つの可能な経路は、４つのノード（ｅノードＢ１、ＭＭＥ、ＭＴＣ−ＧＷ、ＭＴＣサーバ１）と、３つのセグメント（Ｓ１−ＭＭＥ−１、Ｃ−ＭＴＣ、ＭＴＣ−ＧＷとＭＴＣサーバ１との間のセグメント）とから成る。接続性共有の下では、各ネットワークノードは、異なるノードから入って来る、１または複数のＭＴＣ接続性共有経路を有することができ、または異なるノードに出て行く、１または複数のＭＴＣ接続性共有経路を有することができる。２つのノード間の接続性共有経路は、異なるＭＴＣデバイスから発信されたものであるが、２つの同じノードを含む経路上を伝わる、ＭＴＣ共有可能トラフィックによって共有することができる。

いくつかの実施形態では、ネットワークセグメント上に構築または確立されるＭＴＣ共有接続性は、論理エンティティである。論理エンティティの使用は、最小量のリソースおよび最小量のシグナリングオーバヘッドだけで、接続性を効率的に維持することを促進することができる。論理接続性エンティティは、物理接続の上に、例えば、非同期転送モード（ＡＴＭ）レイヤのデータリンクレイヤの上に、直接的に構築することができる。あるいは、論理接続性エンティティは、ＧＴＰ−Ｕに基づいて、構築することができる。別の代替として、論理エンティティは、Ｓ１またはＳ５など、３ＧＰＰ ＥＰＳベアラと同様に構築することができる。

論理接続性エンティティの１または複数は、２つのコアネットワークエンドポイント間に確立することができる。図７は、様々な３ＧＰＰコアネットワークノードと、それらの間に確立され得る論理接続性エンティティとを有する、３ＧＰＰネットワーク７００を示すネットワーク図である。論理接続性エンティティは、３ＧＰＰコアネットワークノードのいずれか２つのポイントにおいて、例えば、ｅＮＢ７０２とＳ−ＧＷ７０４との間、ＭＭＥ７０６とＳ−ＧＷ７０４もしくはＰ−ＧＷとの間、またはＭＭＥ７０６とＰ−ＧＷとの間、またはＭＴＣ−ＩＷＦ７０８とＳ−ＧＷ７０４もしくはＰ−ＧＷとの間などに存在することができる。理論的に、ネットワークにおける共有接続性は、ＭＴＣトラフィックを処理する３ＧＰＰコアネットワークにおけるマシンツーマシン状況において構成される。

いくつかの実施形態では、１または複数のＭＴＣ接続性共有経路が、ネットワークセグメントの各々に存在することができる。例えば、セグメントは、ＭＴＣ共有可能データトラフィックのすべての種類に適合するように定義された、１つのＭＴＣ接続性共有経路を有することができる。あるいは、セグメントに対して複数の接続性共有経路を定義することができ、複数の接続性共有経路の各々は、特定の種類のＭＴＣ共有可能データトラフィックに適合する。

いくつかの実施形態では、１つのネットワークセグメントにおいて、（例えば、特定のＭＴＣデバイスから発信された、特定のｅノードＢから開始して、特定のＭＴＣサーバに到る）第１のＭＴＣ共有可能データトラフィックは、第２のＭＴＣ共有可能データトラフィックと共有を行うことができる。しかし、また別の、または次のネットワークセグメントでは、トラフィックルートの起点および終点に応じて、第１のＭＴＣ共有可能データトラフィックは、第３のＭＴＣ共有可能データトラフィックと共有を行うことができる。したがって、特定のネットワークセグメント（例えば、ＭＴＣ接続性共有経路）は、異なる無線アクセス技術に基づいたデバイスによって共有することができる。例えば、ＷＬＡＮを介して接続されるＭＴＣデバイスは、ＳＧＷ／ＰＤＮ ＧＷにおいて、ＣＮリソースを共有することができる。したがって、共有ＥＰＳリソースは、これらのデバイスの無線アクセスを必ずしも３ＧＰＰアクセスに限定しない。

図３は、非限定的な一実施形態による、共有されるネットワークセグメントを示すブロック図である。示されるように、共有可能トラフィック１は、ＭＴＣ−Ａから、ノード３０２、３０８、３１４、３１６、３１８を介してルーティングされる。共有可能トラフィック２は、ＭＴＣ−Ｂから、ノード３０４、３１０、３０８、３１４、３１６、３２０、３２２を介してルーティングされる。共有可能トラフィック３は、ＭＴＣ−Ｃから、ノード３０６、３１２、３１４、３１６、３２０、３２４を介してルーティングされる。共有可能トラフィック１と共有可能トラフィック２は、ノード３０８、３１４、３１６の間のセグメントを共有する。示されるように、共有可能トラフィック１と共有可能トラフィック２は、ノード３０８とノード３１４の間のＭＴＣ接続性共有経路３２６を共有する。共有可能トラフィック１、共有可能トラフィック２、および共有可能トラフィック３はどれも、ノード３１４とノード３１６の間の同じ経路を共有するので、トラフィックのすべては、ＭＴＣ接続性共有経路３３０を共有する。示されるように、共有可能トラフィック２と共有可能トラフィック３は、ＭＴＣ接続性共有経路３２８を共有する。

いくつかの実施形態では、２つのノード間のネットワークセグメント上において、（アップリンク／ダウンリンク両方の）ＭＴＣ共有トラフィックのためのＭＴＣ接続性共有経路は、ＭＴＣトラフィックのための固定された共有経路として、またはＭＴＣトラフィックのための半動的な経路として確立することができる。例えば、ＭＴＣトラフィックのための固定された共有経路の場合、セグメントは、「常時接続」と見なすことができる。経路は、所定の時間の間などあるＭＴＣトラフィック共有に対して「半動的」とすることができ、そうでない場合にはイベントベースとなるように構成され、または他のアクティブ化および非アクティブ化時間もしくはイベント、そうでない場合には「必要ベース」とすることができる。「半動的」経路の場合、共有される接続性経路の構成／アクティブ化は、以下のうちの１または複数を含む様々なイベントまたは条件によって、すなわち、事前決定または事前設定された時間によって、特定の種類の共有経路を使用するように定義および／または割り当てられたＭＴＣ共有可能トラフィックのうちの最初の１つまたはＮ個によって、定義されたイベント（例えば、ある量の共有可能トラフィック負荷、またはある種のトラフィックルーティング決定、またはネットワークノードアップ／ダウン状況）によって、ＭＴＣサーバ、またはＭＴＣ−ＧＷ／ＭＴＣ−ＩＷＦもしくは同等物、または特定のＭＴＣトラフィック統御および管理エンティティを代理する、ネットワーク制御ノード（例えば、ＭＭＥ、Ｓ−ＧＷ、もしくはＰ−ＧＷ）からの明示的なコマンドによって、ならびに／あるいは運用および保守（ＯＡＭ）構成によってトリガすることができる。

いくつかの実施形態では、解放または共有経路の非アクティブ化をトリガすることができる。解放または非アクティブ化をトリガできるいくつかの条件は、以下のもの、すなわち、事前決定または事前設定された時間、ＭＴＣ共有可能トラフィックが経路内を通過するたびに始動またはリセットされる（事前決定または事前設定された時間に設定され得る）非アクティブ化タイマの満了、定義されたイベント（例えば、ある量の共有可能トラフィック負荷、またはある種のトラフィックルーティング決定、またはネットワークノードアップ／ダウン状況）、および／あるいはネットワーク制御ノード、またはＭＴＣサーバもしくは特定のＭＴＣトラフィック統御および管理エンティティを代理するノードが用いる特定のコマンド
を含むことができるが、これらに限定されない。

様々な実施形態によれば、固定された経路および半動的な経路はともに、以下のうちの１または複数を用いて、すなわち、ＱｏＳの再構成もしくは経路の様々なレベルのネットワークリソースの再構成、および／または経路に対してより多数もしくは少数のＭＴＣ共有可能トラフィックを許可することを用いて再構成することによって再構成することができる。あるいは、または加えて、ＭＴＣ共有可能トラフィックは、サービス別、またはカテゴリ別、またはＭＴＣユーザ／加入者別などとすることができる。いくつかの実施形態では、カウント手順が、経路を共有する資格のあるＭＴＣデバイスの数を追跡することができる。デバイスの数が一定の閾値を超えた場合、経路を専用経路から共有経路に再構成することができる。

ＵＥから宛先、例えば、ＭＴＣサーバへのＭＴＣデータ経路は、途中の物理ネットワークノードの個々のペア間において定義される共有経路にマッピングする必要があり得る。ネットワークセグメントにおいて、すべてのＭＴＣ共有可能データトラフィックに適合する共通のＭＴＣ接続性共有経路を定義することができる。あるいは、いくつかの実施形態では、ネットワークセグメントにおいて、ある指定されたＭＴＣ共有可能データトラフィックに適合するＭＴＣ接続性共有経路を複数定義することができる。セグメント内の複数の共有経路は、以下でより詳細に説明するように、トラフィック、デバイス、および／または接続性経路特性に基づいて形成することができる。したがって、共有される経路のマッピングが、ＭＴＣ共有可能データトラフィックと特定のＭＴＣ接続性共有経路との間で必要とされ得る。

いくつかの実施形態では、ＭＴＣ共有可能データトラフィックには、ネットワークによって、共有トラフィックインジケータ（例えば、英数字コード）を明示的に割り当てることができ、またはＭＴＣ共有可能データトラフィックは、ＭＴＣデバイスカテゴリに基づいて、もしくは（例えば、ＵＳＩＭパラメータからの）ＭＴＣデータトラフィックカテゴリ／プライオリティ／ＱｏＳに基づいて、所定の共有トラフィックインジケータを暗黙的に継承することができる。ＭＴＣ接続性共有経路は、共有経路インジケータを用いて構成／再構成または事前決定することもできる。事前決定または実行時構成もしくは再構成によって、共有トラフィックインジケータの１または複数を、経路全体の、またはセグメント毎の、共有マッピングルールとして、共有経路インジケータに割り当てることができる。いくつかの実施形態では、ネットワークノード内のマッピングエンティティが、異なる共有経路へのマッピングを、例えば、それ自体のトラフィック、ＱｏＳ、または他のネットワークもしくはＭＴＣ通信事業者ルールに基づいて可能にする柔軟性を有することができるように、１つの共有トラフィックインジケータを複数の共有経路インジケータに割り当てることができる。共有トラフィックインジケータが指すＭＴＣ共有可能データトラフィックと共有経路インジケータが指すＭＴＣ接続性共有経路との間のマッピングアクションは、ＭＴＣ接続性が共有されるＭＴＣトラフィック経路全体上の各ネットワークノードにおいて、共有マッピングルールに従って実行されることを必要とし得る。共有トラフィックインジケータおよび共有経路インジケータを使用することによって、共有マッピングルールを動的に再構成することができ、ネットワークがトラフィック経路共有を柔軟に調整することを可能にする。

いくつかの実施形態では、ネットワークノードは、どのトラフィックがどの論理接続性エンティティまたはベアラに割り当てられるかに関する情報を含むように動的または半静的に構成され得る、マッピングテーブルを記憶（ストア）することができる。例えば、図７では、ｅＮＢ７０２は、共有トラフィックインジケータ１０、１５、２０を共有経路インジケータ３、３、６にそれぞれマッピングする、マッピングテーブル７１０を記憶（ストア）することができる。同様に、ＭＭＥ７０６は、共有トラフィックインジケータ１０、１５、２０を共有経路インジケータ１４、１３、１４にそれぞれマッピングする、マッピングテーブル７１２を記憶（ストア）することができる。したがって、共有トラフィックインジケータは、各トラフィックに固有であるが、異なるトラフィックが、同じ共有経路識別子を有することができ、それによって、それらが共有経路識別子に関連付けられた論理接続性エンティティまたはベアラを共有することが示される。

いくつかの状況では、ＭＴＣデバイスおよび／またはＭＴＣ共有可能データトラフィックは、割り当てられた、または別の方法で継承された、複数の共有トラフィックインジケータを有することができる。マッピングアクションは、対応する共有される接続性経路にマッピングするために、最高のプライオリティまたは最高のクラスのトラフィックに関連付けられた、１つの共有トラフィックインジケータを取得することができる。マッピングを見つけることができない場合、次に高いプライオリティに関連付けられた共有トラフィックインジケータを、マッピングアクションのために使用することができる。

いくつかの実施形態では、ネットワークは、ネットワークトラフィック負荷およびＭＴＣトラフィック量、ならびに他のネットワーク保守作業に適応するために、共有トラフィックインジケータから共有経路インジケータへのマッピングルールをときどき調整することができる。例えば、時刻Ｔ１において、特定のＭＴＣ共有可能データトラフィックコンテキスト（すなわち、共有トラフィックインジケータＮ１）は、共有経路インジケータＭ１を有する特定の共有経路にマッピングすることができる。時刻Ｔ２において、ＭＴＣトラフィックが減少すると、ノードは、共有経路インジケータＭ１を有する共有経路を非アクティブ化することができ、一方、共有コンテキストＭ０はそのまま残しておくことができる。したがって、その後、Ｎ１は、Ｍ０にマッピングすることができる。後で、時刻Ｔ３において、ノードは、共有経路インジケータＭ１を有する共有経路を再アクティブ化することができ、Ｎ１は、再び、やはり共有経路インジケータＭ１を有する共有経路にマッピングすることができる。

いくつかの実施形態では、共有経路マッピングルールは、異なるノード毎に様々であることができる。例えば、各ノードは、負荷によって、全体的なＱｏＳ要件が満たされるかによって、またはネットワーク方針もしくはＭＴＣ−ＯＡＭルールによってマッピング決定を行うことができる。

ＭＴＣ接続性共有経路は、バッファリング能力を有することができる。その場合、全体的なＭＴＣトラフィックを調整して、割り当てられた共有リソースを順番に使用し、帯域幅割り当ておよびＱｏＳ要件を円滑に満たすようにすることができる。

２つのネットワークノード間に構成されたＭＴＣ接続性共有経路をただ１つ有する実施形態では、各共有ＭＴＣデータトラフィックのための共有トラフィックインジケータは、優先順位付けされたスケジュールのための基礎として使用することができる。いくつかの実施形態では、トークンバケット（ｔｏｋｅｎ−ｂｕｃｋｅｔ）アルゴリズムまたは他の制御機構を、データトラフィックの公平性のために使用することができる。

デバイスからＭＴＣサーバまでのＭＴＣデータトラフィック経路のあらゆるセグメント上に経路が存在し、トラフィックから経路へのマッピングのルールが設定される、上で説明されたセグメントベースのＭＴＣ接続性共有方式を用いれば、長くオーバヘッドの大きいＵプレーン経路を確立および維持する必要なしに、ＭＴＣ共有可能データトラフィックを送信することができる。したがって、ネットワークシグナリングおよび接続性維持コストを低減させることができる。同様に、個々のセッション確立時に、またはデータ転送セッション開始時に、少なくとも、ＭＴＣサーバへの経路を含むＲＡＮおよびコアネットワーク内では、Ｃプレーン経路確立の労力を必要としなくてよい。

同じ経路を共有するＭＴＣデバイスは、それらがネットワークにアクセスできるようになる前に、ネットワークによって認証され得る。いくつかの実施形態では、ネットワークは、共有される経路毎に同じ１組のセキュリティ鍵をＭＴＣデバイスに割り当てる。

セグメントベースのＭＴＣ接続性共有方式は、ＭＴＣデバイスのモビリティに適合するように、柔軟な接続性共有も可能にする。例えば、ＭＴＣデバイス共有可能データトラフィックは、新しい基地局（ノードＢもしくはｅノードＢ）、基地局コントローラ（ＲＮＣ）、および／またはＭＭＥ／ＳＧＳＮもしくはＳ−ＧＷからの接続性共有経路にマッピングすることができる。

データ経路ＱｏＳおよび／または他の課題を考慮して、１または複数の共通属性を有するＭＴＣデバイスの間で、ＭＴＣデータ接続性共有を有効にすることができる。１つの例示的な属性は、ＭＴＣデータ接続性共有をサポートする能力とすることができる。この能力は、すべてのＭＴＣデバイスに存在することができ、またはＭＴＣデバイスのいくつかが有する特別な能力とすることができる。別の例示的な属性は、ＭＴＣユーザ／加入者が同じであること、または特定のＭＴＣサービス用であること、またはＭＴＣサービス／使用カテゴリもしくは特定のＭＴＣユーザグループに属することとすることができる。また別の例示的な属性は、ＭＴＣデバイスがあるＣＳＧまたは特定のローカルホームネットワーク（ＬＨＮ）に属することとすることができる。さらに別の例示的な属性は、データ送信または受信が、加入契約、またはトラフィック緊急性の性質、またはＭＴＣデータ量に基づくことができる、特定の割り当てられたトラフィック／ルーティングプライオリティまたは共有／ルーティングカテゴリのためのものであることとすることができる。１つの例示的な属性は、データ送信または受信が、特定の割り当てられたＱｏＳ（またはＱＣＩ値、またはＧＢＲ値、またはＡＭＢＲ値）を有することとすることができる。別の例示的な属性は、ＭＴＣデバイスが、ネットワークにおいて、同じまたは共通のネットワーク接続ポイント（例えば、同じｅノードＢ、もしくは同じノードＢ、もしくは同じホームｅノードＢ）、または同じシグナリングエンドポイントを有することとすることができる。さらに別の例示的な属性は、ＭＴＣデバイスのＵＥ−ＩＤ属性、ＩＭＳＩ属性、ＨＰＬＭＮ番号もしくはそれらのグループＩＤ属性、または他の割り当てられた共有識別情報属性に基づくことができる。また別の例示的な属性は、ＭＴＣデバイスが、同じＭＴＣ集中ノードまたはＭＴＣアグリゲーションノードを共有することとすることができる。１つの例示的な属性は、ＭＴＣデバイスが、同じマルチキャストＩＰアドレスを共有することとすることができる。

いくつかの実施形態では、ＭＴＣデバイスのトラフィックのすべては、共通属性の考慮にも係わらず、単一の共通経路／ベアラに、または少数の共通経路／ベアラにマッピングされることがある。例えば、利用可能な共有可能経路上における負荷条件は、与えられたＭＴＣトラフィックがマッピングされる経路を左右することがある。

特定の共有能力および共有割り当てコンテキストは、１つのＭＴＣデバイスと別のＭＴＣデバイスとでは異なることができる。いくつかの実施形態では、そのような共有能力またはコンテキストをＭＴＣデバイスに対して定めるために、ＭＴＣサービスプロバイダまたはネットワークプロバイダは、ＵＳＩＭパラメータを使用することができる。ネットワークは、例えば、特定のセグメントについての、その共有能力を、ＲＲＣおよび／またはＮＡＳメッセージを介して示すこともできる。ＵＥは、例えば、共有を要求するために、この情報も同じく使用することができる。

ＭＴＣデータ接続性共有は、無線インタフェースの後または前の、ＭＴＣトラフィックのための収束または発散ポイントである、ｅノードＢまたはノードＢなどの基地局から開始することができる。ＭＴＣ接続性共有をサポートするｅノードＢから、次のネットワークノード、例えば、ＭＭＥまたはＳ−ＧＷに向かって、設定されると、ノードの電源が落とされない限り、意図的には切断されない、１または複数の固定された共有経路、および／または１または複数の動的な共有経路、あるいはその両方が存在することができる。ｅノードＢ／ノードＢに対して２つ以上の次のネットワークノードが存在することがある。

固定された共有接続性の場合、接続性経路は、ｅノードＢ／ノードＢに電源が入れられたときに、またはｅノードＢ／ノードＢがリセットされたときに、確立することができる。ｅノードＢ／ノードＢとＭＭＥ／ＲＮＣ（またはＳＧＳＮ）との間に共有経路が存在する場合、ｅノードＢ／ノードＢおよびＭＭＥ／ＲＮＣ（またはＳＧＳＮ）は、ｅノードＢに電源が入れられたときに、または「Ｓ１設定」もしくは「ＥＮｏｄｅＢ構成更新」もしくは「ＥＮｏｄｅＢ構成転送」もしくは「ＭＭＥ構成転送」などの手順中にｅノードＢがリセットされたときに、そのような共有経路の設定を開始することができる。ｅノードＢは、２つ以上のＭＭＥを、各々に少なくとも１つが向かう、それらとのＭＴＣ共有経路のためのターゲットとして有することができる。あるいは、共有経路は、最初のトラフィックパケットを送信するときに、または最初のセッション管理手順のときに、またはＣＮノード（ＭＭＥ／ＳＧＳＮ／ＭＳＣ＿ＶＬＲ）が、サービス要求メッセージなど、最初のＵＥメッセージをＲＡＮから受信したときに、確立することもできる。ｅノードＢとＳ−ＧＷとの間に共有経路が存在する場合、ｅノードＢのためのＳ−ＧＷを見つけるように、上記の手順の１つにおいて、ＭＭＥに要求することができ、その後、それは、ｅノードＢに応答を返して、ｅノードＢに、そのような共有経路を確立するためにＳ−ＧＷと交信させることができ、またはそれは、ｅノードＢとの共有経路を確立するようにＳ−ＧＷに命じるコマンドをＳ−ＧＷに送信することができる。ｅノードＢは、ＭＴＣ共有経路のためのターゲットとして２つ以上のＳ−ＧＷを有することができる。

様々な実施形態によれば、ｅノードＢは、受信したパケットを共有経路に多重化することができ、または共有経路から逆多重化することができる。多重化機能は、パケットデータ収束プロトコル（ＰＤＣＰ）レイヤまたはＰＤＣＰレイヤの上位のレイヤにおいて実施することができる。多重化／逆多重化をサポートするために、ｅノードＢ／ノードＢ／ＲＮＣは、その対応するＩＰアドレスとともにＵＥを、またはアドレス可能なＷＴＲＵを、または宛先ＭＴＣサーバ識別情報を動作中に記憶（ストア）しておく、テーブルを設定することができる。受信した各パケットに対して、ｅノードＢ／ノードＢ／ＲＮＣは、パケットの宛先であるターゲットＵＥを決定するために、ＩＰヘッダまたはＷＴＲＵ−Ｉｄを検査する必要があり得る。

ｅノードＢ／ＲＮＣとＰ−ＧＷ／ＧＧＳＮとの間に共有経路が存在する場合、最初のセッション開始のために、Ｐ−ＧＷを見つけるように、ｅノードＢからＭＭＥに要求することができ、その後、それは、接続性共有コンテキストが同じすべての後続のセッションに対して、同じＰ−ＧＷを用いて応答することができる。ｅノードＢとＰ−ＧＷとの間でＳ１ベアラおよびＳ５ベアラを共有することができる。

いくつかの実施形態では、ｅノードＢは、受信したパケットを共有されるＳ１ ＧＷに多重化することができ、または共有されるＳ１ ＧＷから逆多重化することができる。多重化は、例えば、ディープパケットインスペクション（Ｄｅｅｐ Ｐａｃｋｅｔ Ｉｎｓｐｅｃｔｉｏｎ）を使用すること、特定のルックアップテーブルを維持すること、またはネットワークアドレス変換機能を実行することなど、任意の適切な技法を使用して、ｅノードＢによって実行することができる。Ｐ−ＧＷは、例えば、ディープパケットインスペクションを実行すること、ルックアップテーブルを検査すること、ネットワークアドレス変換機能を実行すること、または他の適切な技法を使用することによって、多重化または逆多重化をサポートすることができる。

Ｓ−ＧＷとＰ−ＧＷとの間に共有経路が存在する場合、ｅノードＢのためのＰ−ＧＷを見つけるように、ＭＭＥに要求することができ、その後、それは、Ｓ−ＧＷに応答を返して、Ｓ−ＧＷに、そのような共有経路を確立するためにＰ−ＧＷと交信させることができる。いくつかの実施形態では、ＭＭＥは、Ｓ−ＧＷとの共有経路を確立するようにＰ−ＧＷに命じるコマンドをＰ−ＧＷに送信することができる。Ｓ−ＧＷは、受信したパケットを共有経路に多重化することができ、または共有経路から逆多重化することができる。いくつかの実施形態では、Ｓ−ＧＷは、ＧＴＰレイヤまたはＧＴＰレイヤの上位のレイヤにおいて、多重化機能を実施することができる。多重化／逆多重化をサポートするために、Ｓ−ＧＷは、その対応するＩＰアドレスとともにＵＥを、またはアドレス可能なＷＴＲＵを、または宛先ＭＴＣサーバ識別情報を動作中にセーブしておく、テーブルを設定することができる。受信した各パケットに対して、Ｓ−ＧＷは、パケットの宛先であるターゲットＵＥを見出すために、ＩＰヘッダまたはアドレス可能ＷＴＲＵ−Ｉｄを検査することができる。

様々な実施形態では、モビリティをサポートするために、ｅノードＢ間にも共有可能経路が存在することができる。そのような実施形態では、上で説明されたｅノードＢとＭＭＥの共有可能経路確立の場合と同様に、ｅノードＢに電源が入れられたときに、手順（例えば、Ｘ２設定手順、Ｘ２リセット手順、および／もしくはＸ２ ＥＮｏｄｅＢ構成更新手順）を使用してｅノードＢがリセットされたときに、または他の適切なときに、そのような経路を確立することができる。

動的な共有接続性の場合、アクティブ化および非アクティブ化手順（およびロジック）は、対応するＭＭＥに配置することができ、または例えば、それは、他の任意のＣＮノードもしくはＲＡＮに配置することができる。トリガ時に、ＭＭＥは、ｅノードＢとＭＭＥ経路との間の経路については、ｅノードＢに対して、またはｅノードＢとＳ−ＧＷ経路との間の経路については、ｅノードＢおよび／もしくはＳ−ＧＷに対して、共有経路アクティブ化または非アクティブ化コマンドを発行することができる。いくつかの実施形態では、ＭＭＥは、ＭＴＣデバイス、ｅノードＢ、またはＳ−ＧＷによる通知を受けて、共有経路アクティブ化または非アクティブ化コマンドを発行することができる。

ＭＴＣデバイスまたはＭＴＣデバイスアグリゲーションノードは、そのデータ通信のために、動的な共有接続性経路、または静的もしくは半静的に構成可能な共有可能経路を使用できるかどうかを示すことができる。いくつかの実施形態では、ＨＬＲ／ＨＳＳに記憶されたＭＴＣ ＩＭＳＩを用いて、情報を問い合わせること、または他の方法で獲得することができる。

いくつかの実施形態では、本明細書で説明される共有されるＭＴＣ接続性は、中継ノードとともに使用することができる。中継ノードを含む、いくつかの実施形態では、ＭＴＣトラフィック共有のために、（例えば、事前定義されたＱｏＳ属性を有する）ベアラを、バックホールリンク上に、例えば、中継ノードとドナーｅノードＢ（Ｄｏｎｏｒ ｅＮｏｄｅＢ）との間のＵｎインタフェース上に確立することができる。中継バックホール上でのＭＴＣデバイス無線ベアラの多重化は、上で説明されたものと同様のルールに従うことができる。さらに、ネットワークから見えるデバイスがＭＴＣアグリゲーションノードである実施形態では、ＭＴＣデバイスアグリゲーションノード（ＵＥ）側および／またはネットワーク側において、ＭＡＣレベルでの多重化または逆多重化を提供するために、セル無線ネットワーク一時識別子（ＣＲＮＴＩ）に類似した特別のＭＴＣアグリゲーションノード識別情報、例えば、特別のＭＴＣアグリゲーションノードＬＣＩＤ、または２つの組み合わせを使用することができる。さらに、すべてのＭＴＣトラフィックは、共有ベアラＵＬおよびＤＬを介してルーティングすることができ、そのため、頻繁なＵｎインタフェースベアラの確立または変更を回避することができる。いくつかの実施形態では、共有経路に割り当てられたスループット能力を超え得るピークトラフィック負荷を平坦化するのに役立つように、例えば、ＵＬの場合は、中継ノードに、または例えば、ＤＬの場合は、ドナーノードＢに、ＭＴＣトラフィックをバッファリングすることができる。

いくつかの実施形態では、本明細書で説明される共有されるＭＴＣ接続性は、ホームｅノードＢとともに使用することができる。ホームｅノードＢから開始するＭＴＣデータ共有接続性は、上で説明されたｅノードＢ実施形態のものと概ね同様とすることができる。ローカルＧＷを使用して、ＳＩＰＴＯに類似したトラフィックとなるように、ＭＴＣ共有可能経路を構成することができる。いくつかの実施形態では、ＬＧＷは、ＭＴＣサーバまたはＭＴＣ ＧＷに直接的に接続することができる。

ホームｅノードＢは、例えば、特別のＭＴＣデバイス識別情報を用いて、ＭＴＣデバイスアグリゲーションポイントのパーソナリティ（ｐｅｒｓｏｎａｌｉｔｙ）を取得することができる。ホームｅノードＢの制御下のＭＴＣデバイスからのトラフィックは、ホームｅノードＢにおいて多重化することができる。この多重化は、ＲＡＮおよびコアネットワークからは透過的とすることができるが、ＭＴＣサーバからは非透過的である。ＭＴＣデバイスアグリゲーションポイントとしてのホームｅノードＢは、ネットワークには、ＭＴＣデバイスシグナリングおよびデータトラフィックのために確保された、関連する特別のユーザプレーンベアラを用いる、通常のＵＥとも見え得る。さらに、ホームｅノードＢサブシステム内のＭＴＣデバイスによって取られる経路は、デバイスのＣＳＧプロファイルに依存し得る。例えば、ハイブリッドＣＳＧセルにおいて、限定加入者グループ（ＣＳＧ）のメンバは、非メンバとは異なる経路を取ることができる。

いくつかの実施形態では、ＣＳＧセルには、ＭＴＣデバイスだけがアクセスすることができる。本明細書で使用する場合、ＭＴＣデバイスは、プライオリティが低いデバイス、遅延を許容できるデバイス、または他の任意のタイプのデバイスとして動作するように構成された、デバイスを含むことができる。したがって、ＭＴＣデバイスは、「ＭＴＣデバイス」と呼ばれるＵＥに限定されない。ＣＳＧセルがＭＴＣデバイスのみによって使用される実施形態では、ＣＳＧセルは、ＭＴＣデバイスのみがセルにアクセスできることをＵＥに通知する特定の表示をブロードキャストすることができる。この表示は、任意のブロードキャストメッセージ内に収めることができる。

いくつかの実施形態では、ＵＥは、どのセルにＭＴＣデバイスとしてアクセスできるかをＵＥに通知する情報を、ＲＲＣ、ＮＡＳ、ＯＭＡ ＤＭ、ＯＴＡなどの専用メッセージングを介して受信することができる。これらの実施形態では、ＵＥは、ＣＳＧがＭＴＣデバイスのみによってアクセスされるべきかどうかを示す、ＣＳＧ識別情報毎の表示を（例えば、ＣＳＧホワイトリスト内に、通信事業者ＣＳＧリスト内に、許可ＣＳＧリスト内に、ＵＳＩＭ内に、またはそれらの任意の組み合わせで）有することができる。依然として、通常のアクセスチェックも適用可能とすることができる。

いくつかの実施形態では、ＣＳＧセルに非ＭＴＣデバイスはアクセスすることができない。さらに、これらのＵＥは、例えば、緊急通報を行うため、または特定の時間の間だけ、セルにアクセスすることができる。非ＭＴＣデバイスがＭＴＣ−ＣＳＧセルにアクセスを許可される特定の時間またはイベントはいずれも、上で説明されたような専用メッセージングを介して、すべてのＵＥまたは非ＭＴＣ ＵＥにブロードキャストまたは提供することができる。

様々な実施形態によれば、特定の期間内だけ、特定のイベントが発生したとき（例えば、緊急セッションがあるとき、もしくは一定のＱｏＳのトラフィックが必要とされたとき）だけ、または他の条件が存在する間だけ、既存のＣＳＧセルへのアクセスをＭＴＣデバイスに通知または許可することができる。この情報は、ブロードキャストもしくは専用ＲＲＣ／ＮＡＳメッセージを介して、または上で説明されたメッセージングなど、他の適切なメッセージを介して、ＭＴＣデバイスに提供することができる。ＭＴＣデバイスは、この制限されたアクセスが適用される、（例えば、ホワイトリスト、通信事業者ＣＳＧリスト、または許可ＣＳＧリスト内の）各ＣＳＧ ＩＤの隣に表示を有することができる。

ネットワークは、ＭＴＣデバイスだけが使用できる、または一定の時間間隔の間、もしくは一定のイベントが発生したときに、ＭＴＣデバイスがそれらを入手して使用することが可能な、特定の１組のＣＳＧ ＩＤを確保することもできる。ネットワークは、専用メッセージング（ＲＲＣ、ＮＡＳなど）を介して、ＭＴＣデバイスにこれらのＣＳＧ ＩＤを提供することができ、またはＭＴＣデバイスは、（例えば、ＵＳＩＭ内の）これらの情報を用いて構成することができる。

一般に、本明細書で説明されるシステムおよび方法は、多くのＭＴＣデバイスがネットワークへのアクセスを試みて、非ＭＴＣデバイスがシステムにアクセスできなくなるような輻輳を引き起こすことがある、ＲＡＮベースの輻輳制御を回避するためにも使用することができる。

ＭＴＣ接続性共有をサポートするネットワークは、可能なＭＴＣデバイスがプロビジョン（ｐｒｏｖｉｓｉｏｎ）を利用することを公開する必要があり得る。いくつかの実施形態では、サポート可能性およびＭＴＣ接続性共有構成に関する通知を公開または他の方法で提供するために、以下のシステムおよび方法のうちの１または複数を使用することができる。

いくつかの実施形態では、ＲＡＮ ＳＩＢブロードキャストを利用することができる。例えば、ｅノードＢまたはセルは、ＭＴＣ接続性共有を含むＭＴＣの特別な動作に対する、そのサポート、またはネットワークサポートおよび構成を、システム情報ブロードキャストによって公表することができる。情報は、既存のＳＩＢ内に、または別のもしくは新しいＳＩＢ内に含むことができ、そのため、ＭＴＣ動作についての、この新しいＳＩＢの存在によって、ＭＴＣサポートを認識することができる。

いくつかの実施形態では、ＭＴＣ接続性共有構成またはコンテキストは、以下の情報要素のうちの１または複数を含むことができる。

（１）ＲＡＮもしくはＣＮのための、またはＰＬＭＮ全体のための、ＭＴＣ接続性共有インジケータ、および／あるいは
（２）１または複数のＭＴＣ接続性共有トラフィックインジケータまたは識別子。
各情報要素は、１または複数の異なるＭＴＣデバイスのための、あるいは（例えば、特定のＭＴＣユーザ／加入者別の、特定のＭＴＣサービス別の、またはＭＴＣサーバ、Ｐ−ＧＷ、もしくはＡＰＮなどの、特定のネットワークエンドポイント別の）トラフィックカテゴリのための、共有トラフィックインジケータを表すことができる。

ＭＴＣ共有可能データトラフィックは、従来のＵプレーンベアラ／コンテキスト設定を使用できないので、Ｕｕトラフィック経路は、セグメントベースのＭＴＣ接続性共有をサポートする必要があり得る。システム情報は、ＭＴＣ接続性共有設定をサポートするための特別な構成をブロードキャストする必要があり得る。いくつかの実施形態では、ＭＴＣヘッダパラメータに対する（ルーティングおよび共有を決定する）ｅノードＢにおける特別な処理が必要であり得ることを示すために、ＭＴＣトラフィックのための、またはＭＴＣデバイスからのＭＴＣ共有可能データトラフィックのための、１または複数の特別なＭＴＣベアラＩＤが必要とされ得る。１または複数のＭＴＣベアラＩＤは、ＭＡＣ ＬＣＩＤドメインにおけるシグニフィカンス（ｓｉｇｎｉｆｉｃａｎｃｅ）およびＩＤ値範囲を有することができる。ＭＴＣ共有可能データトラフィックに適合するように、特別なアップリンクリソースおよびスケジューリングを割り当て、公開することができる。

いくつかの実施形態では、ＭＴＣ接続性共有ブロードキャスト情報は、システム情報内に暗号化することができ、鍵は、ネットワークによって、共有される経路の使用を望む個々のＭＴＣデバイスに、専用の１または複数のメッセージによって送信することができる。

いくつかの実施形態では、サポート可能性およびＭＴＣ接続性共有構成に関する通知を公開または他の方法で提供するために、専用の１または複数のメッセージを利用することができる。共有トラフィックインジケータ値を、ＮＡＳ、ＲＲＣ、ＯＭＡ ＤＭ、ＯＴＡ、および／またはＬ１／Ｌ２メッセージなどの、専用シグナリングメッセージを介して、ネットワークから、特定のＭＴＣデバイスに、および／または特定のＭＴＣ共有可能トラフィックに割り当てることができる。接続性共有パラメータも、以下のうちの１または複数を介して、ＭＴＣデバイスにもたらすことができる。

（１）（例えば、ページングメッセージを介する、またはＭＴＣデバイストリガもしくはリーチ（ｒｅａｃｈｉｎｇ）のためのＭＴＣ−ＲＮＴＩシグナリングを介する）ＭＴＣダウンリンクデバイストリガまたはリーチ時間において、
（２）「デフォルトＥＰＳベアラコンテキストアクティブ化要求（Ａｃｔｉｖａｔｅ Ｄｅｆａｕｌｔ ＥＰＳ Ｂｅａｒｅｒ Ｃｏｎｔｅｘｔ Ｒｅｑｕｅｓｔ）」メッセージ、または「専用ＥＰＳベアラコンテキストアクティブ化要求（Ａｃｔｉｖａｔｅ Ｄｅｄｉｃａｔｅｄ ＥＰＳ Ｂｅａｒｅｒ Ｃｏｎｔｅｘｔ Ｒｅｑｕｅｓｔ）」メッセージ、または「ＥＰＳベアラコンテキスト変更要求（Ｍｏｄｉｆｙ ＥＰＳ Ｂｅａｒｅｒ Ｃｏｎｔｅｘｔ Ｒｅｑｕｅｓｔ）」メッセージ、またはＮＡＳ「通知」メッセージ、または新しいＮＡＳメッセージなどの、アタッチアクセプト（Ａｔｔａｃｈ Ａｃｃｅｐｔ）もしくはＴＡＵアクセプトメッセージ、または他のＮＡＳレベルダウンリンクメッセージ、
（３）（例えば、ＬＴＥ「ＲＲＣ接続再構成要求」またはＵＭＴＳ「無線ベアラ再構成要求」を介する）ＵＥ／ＭＴＣデバイス「サービス要求」または「拡張サービス要求」に対するネットワークからの肯定的な応答、および／あるいは
（４）例えば、ＬＴＥ ＲＲＣ接続設定要求メッセージ、またはＵＭＴＳ ＲＲＣ接続設定要求もしくは無線ベアラ設定要求など、ＲＲＣ接続確立時におけるダウンリンクメッセージ。

いくつかの実施形態では、サポート可能性およびＭＴＣ接続性共有構成に関する通知を提供するために、ＵＳＩＭパラメータを利用することができる。例えば、ネットワークおよび／またはＭＴＣ通信事業者は、以下のＵＳＩＭまたはＵＩＣＣデバイスパラメータのうちの１または複数を用いて、ＭＴＣタスクを実施するＭＴＣデバイスまたはＵＥを構成することができる。

（１）ＭＴＣデバイスＩＤ、
（２）ＵＥ能力に関連し得るＭＴＣデバイスクラス、
（３）ＭＴＣデバイスカテゴリ（例えば、ＭＴＣのみ、ＭＴＣを用いるＵＥ、固定、低モビリティ、通常のモビリティ）、
（４）実行するように申し込まれたＭＴＣサービス（例えば、測定、セキュリティモニタリング、イベントモニタリング、地震モニタリング、洪水モニタリング、濃度モニタリングなど）、および／または
（５）ＭＴＣデバイスウェイクアップスケジューリング。

ＭＴＣデバイスウェイクアップスケジューリングは、１または複数の延長された長いＭＴＣ不連続受信（ＤＲＸ）サイクル、異なる長さのＤＲＸサイクルの混合について定義されたルール、および／または特別なウェイクアップ時間を含むことができる。さらに、ＭＴＣ接続性共有の場合、ＭＴＣデバイスが生成する、デバイスクラス／カテゴリ／サービスに対応する異なるデータトラフィックに対して、１または複数の共有トラフィックインジケータ値を、ＵＳＩＭ内に構成または再構成することもできる。

いくつかの実施形態では、サポート可能性およびＭＴＣ接続性共有構成に関する通知または表示を、コアネットワークエンティティからダウンロードすることができる。ＭＴＣ共有コンテキストおよび他のＭＴＣ共有パラメータ（例えば、ＭＴＣ共有インジケータ、トラフィックインジケータ、ベアラＩＤ、および／または他のパラメータ）は、例えば、ＡＮＤＳＦまたはＤＮＳサーバなどの、ＣＮエンティティからダウンロードすることができる。ＭＴＣデバイスは、これらのＣＮエンティティに問い合わせを行うことができ、応答として、これらの構成およびパラメータを受け取ることができる。このシナリオをサポートするために、拡張ＡＮＤＳＦ機能またはＤＮＳ機能を利用することができる。

様々な実施形態によれば、ヘッダパラメータは、送信されるＭＴＣデータの上にフォーマットすることができ、そのため、ネットワークは、データトラフィックを正しくルーティングし、指定されたＭＴＣサーバまでの接続性経路を共有することができる。ヘッダ内には以下のパラメータのうちの１または複数を含むことができる。

（１）宛先ＭＴＣサーバ識別情報もしくはＦＱＤＮもしくはＩＰアドレス、
（２）永続的もしくは一時的に割り当てることができるＭＴＣデバイス識別情報、
（３）ＭＴＣデバイスクラス／サービスカテゴリに関連付けることができる、例えば、トラフィックのサービスもしくはプライオリティを表す、ＭＴＣデータのタイプ、
（４）ＭＴＣトラフィックの共有トラフィックインジケータ値、および／または
（５）再送もしくは肯定応答必要インジケータ。

ＭＴＣトラフィックパラメータは、ＭＴＣデータブロックレベルにおいてセグメントベースのルーティングを実施するために、ＵＥ ＰＤＣＰプロトコルデータユニット（ＰＤＵ）の上の（または内に配置される）ＭＴＣ共有可能データの隣に配置することができる。ｅノードＢは、ＭＴＣトラフィックの宛先ＩＤ／アドレスを検査してルーティングを決定するために、また共有トラフィックインジケータを検査して共有を決定するために、ＰＤＣＰの上のＭＴＣデータブロックレベルにおいて、ＭＴＣパラメータを復号することができる。Ｓ−ＧＷなどの、後続のネットワークノードも、ＭＴＣ共有可能データトラフィックブロックのルーティングおよび共有に関して類似のアクションを実行することができる。

ＭＴＣトラフィックパラメータは、ＮＡＳ汎用メッセージコンテナ（例えば、ＣプレーンＮＡＳ「アップリンク汎用ＮＡＳトランスポート」メッセージがＭＴＣデータトラフィックのために使用される）の上の（または内に配置される）ＭＴＣ共有可能データの隣に配置することができる。いくつかの実施形態では、ＭＭＥは、ＭＴＣトラフィックの宛先ＩＤ／アドレスを検査してルーティングを決定するために、また共有トラフィックインジケータを検査して共有を決定するために、ＭＴＣパラメータを復号することができる。後続のネットワークノードも、ＭＴＣ共有可能データトラフィックブロックをルーティングおよび共有するために、類似のアクションを実行することができる。

ＭＴＣトラフィックパラメータは、ＣプレーンＲＲＣ「ＵＬＩｎｆｏｒｍａｔｉｏｎＴｒａｎｓｆｅｒ」メッセージなど、ＲＲＣ信号メッセージの上の（または内に配置される）ＭＴＣ共有可能データの隣に配置することができる。ｅノードＢは、ＭＴＣトラフィックの宛先ＩＤ／アドレスを検査してルーティングを決定するために、また共有トラフィックインジケータを検査して共有を決定するために、（ＲＲＣの上の）ＭＴＣデータブロックレベルにおいて、パラメータを復号することができる。例えば、Ｓ−ＧＷなど、後続のネットワークノードも、ＭＴＣ共有可能データトラフィックブロックをルーティングおよび共有するために、類似のアクションを実行する必要があり得る。

様々な実施形態では、ＭＴＣデバイスは、ＭＴＣパラメータをデータＰＤＵのアップリンクにフォーマットすることを担当することができ、ＭＴＣサーバは、ＭＴＣパラメータをデータＰＤＵのダウンリンクにフォーマットすることを担当することができる。

通常のＭＴＣデータトラフィック送信、および／またはネットワークにおける接続性共有のためのＭＴＣ共有可能データトラフィック送信を支援するために、以下でより詳細に説明される以下のシステムおよび装置のうちの１または複数を用いて、ＭＴＣ共有可能データブロックを送信することができる。

いくつかの実施形態では、ＭＴＣ固有の論理チャネルＩＤ（ＬＣＩＤ）を使用することができる。例えば、デバイスからのＭＴＣ共有可能データトラフィックを識別するための１または複数の特別のベアラＩＤまたはインジケータは、ＭＴＣヘッダパラメータに対する（例えば、ルーティングおよび共有を決定するための）ｅノードＢにおける特別な処理の必要性を示す。ＭＴＣトラフィックまたはＭＴＣ共有可能データトラフィックは、ＭＴＣのために所定の、あるいはシステム情報ブロードキャストから、または１つもしくは複数の専用メッセージから受け取った、１または複数の特別な値を有する、ＭＴＣベアラＩＤまたはＭＴＣ共有可能データベアラＩＤを、ＬＣＩＤとして有することができる。ＭＴＣのためのＬＣＩＤ値は、デバイスからのＭＡＣトランスポートブロック内において、ＭＴＣトラフィックまたはＭＴＣ共有可能データトラフィックのためのデータブロックを識別するために、例えば、ＭＡＣヘッダ「Ｒ／Ｒ／Ｅ／ＬＣＩＤ／Ｆ／Ｌ」内に符号化することができる。

ＭＴＣトラフィックの場合、またはＵＥ／ＭＴＣデバイスからＭＴＣサーバへのＰＬＭＮ（例えば、ＡＮおよびＣＮ）を介するＭＴＣ共有可能データトラフィック送信の場合、必要とされる特定のＰＤＰコンテキストまたはＥＰＳベアラがないことがある。アクセスネットワーク（例えば、ＲＡＮ）のノードは、ＵＥ／ＭＴＣデバイスから送信されたＭＴＣデータ内のＭＴＣパラメータに従って、ＭＴＣデータまたは共有可能データを宛先に配送することができる。

接続されたモードでは、ＭＴＣデータトラフィックおよび／またはＭＴＣ共有可能データトラフィックは、新しいＬ３メッセージを介して、またはＭＭＥへのＭＴＣトラフィックまたはＭＴＣ共有可能データブロックトラフィックを識別するために、メッセージ内に特別なインジケータを有する、アップリンク汎用ＮＡＳトランスポートメッセージなどの既存のＮＡＳアップリンクメッセージを介して、コントロールプレーンを通過してＭＭＥに達することができる。アイドルモードでは、ネットワークは、ＵＥ／ＭＴＣデバイスが、ＲＲＣ接続設定完了メッセージ上で搬送されるＮＡＳメッセージを使用することを可能にすることができる。メッセージは、ＭＴＣデータまたはＭＴＣ共有可能データを搬送するために、通常のＥＰＳベアラ／ＰＤＰコンテキストを確立し、使用し、または後で維持する必要がないことを、例えば、新しいパラメータを介して明示的に指示することができる。メッセージは、例えば、ＭＴＣデータまたはＭＴＣ共有可能データを直接的に搬送することができ、または後続のＬ３データが、ＭＴＣデータまたは共有可能データを搬送する。メッセージ構造は、図４に示されるメッセージ４００と同様とすることができる。図４に示されるように、メッセージ４００は、ＭＡＣ部４０２と、ＲＬＣ部４０４と、ＰＤＣＰ部４０６と、ＲＲＣヘッダ４０８と、ＮＡＳメッセージヘッダ４１０と、ＭＴＣパラメータ４１２と、ＭＴＣ共有可能データ部４１４とを含むことができる。

ＭＴＣトラフィックまたはＭＴＣ共有可能トラフィックが、Ｌ３／ＮＡＳシグナリングメッセージを使用しない場合、様々な適切なフォーマットで、それを送信することができる。例えば、上で説明したように、ＲＲＣシグナリングメッセージ（例えば、ＭＴＣインジケータを有する新しいものまたは既存のもの）と一緒に、ＳＲＢの１つの上およびＲＲＣ接続上のペイロードとして、それを送信することができる。いくつかの実施形態では、メッセージ構造は、図５に示されるメッセージ５００と同様とすることができる。図５に示されるように、メッセージ５００は、ＭＡＣ部５０２と、ＲＬＣ部５０４と、ＰＤＣＰ部５０６と、ＲＲＣヘッダ５０８と、ＭＴＣパラメータ５１０と、ＭＴＣ共有可能データ部５１２とを含むことができる。

いくつかの実施形態では、メッセージは、ＭＴＣ固有のＵプレーンベアラを介する、純粋なＵプレーンパケットとすることができる。Ｕプレーンベアラは、ＵＥ／ＭＴＣデバイスとＲＡＮとの間にあることができ、ＵＥ／ＭＴＣデバイスが、ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｑｕｅｓｔメッセージで、そのようなＭＴＣ固有のＵプレーン設定を要求でき、ＲＡＮが、図６のメッセージ６００によって示されるようなＲＲＣＣｏｎｎｅｃｔｉｏｎＳｅｔｕｐＲｅｑｕｅｓｔメッセージで、ＭＴＣ ＬＣＩＤまたは同等物を有する、そのようなＵプレーンベアラを構成できる、ＲＲＣ接続確立手順を用いて確立することができる。図６に示されるように、メッセージ６００は、ＭＡＣ ＬＣＩＤを含むＭＡＣ部６０２と、ＲＬＣ部６０４と、ＰＤＣＰ部６０６と、ＭＴＣパラメータ６０８と、ＭＴＣ共有可能データ部６１０とを含むことができる。

いくつかの実施形態では、ＭＴＣ ＬＣＩＤの代わりに、Ｃ−ＲＮＴＩ範囲に類似した範囲内の特別なＭＴＣ識別情報を使用することができる。例えば、各経路が与えられたＱｏＳ要件にマッピングされる、複数の共有可能経路が確立されると仮定すると、異なるＭＴＣデバイスからの同じＱｏＳ要件を有するＭＴＣトラフィックは、同じＱｏＳレベルにある同じ共有可能経路にマッピングすることができる。そのような場合、異なるＭＴＣデバイスに属するトラフィックを、ＭＴＣアグリゲーションノードのために、多重化／逆多重化する方法として、ＭＡＣプロトコルデータユニット（ＰＤＵ）において、特別なＭＴＣ識別情報を使用することができる。

いくつかの実施形態では、１組のＭＴＣデバイスのための共有可能な特定のコンテキストのためのＵプレーンデータは、事前構成または専用に構成されたＭＢＭＳセッションを使用して、マルチキャストブロードグループ（ｍｕｌｔｉｃａｓｔ ｂｒｏａｄ ｇｒｏｕｐ）にマッピングすることができる。セッション生成は、ＭＴＣデバイスの数が事前定義された閾値を超えた場合に、ＭＢＭＳカウント手順によってトリガすることができる。いくつかの実施形態では、セッション生成は、ＭＴＣデバイス能力情報で示すことができる、ＭＢＭＳ動作が可能なように構成されたＭＴＣデバイスのためにトリガすることができる。

上では特徴および要素を特定の組み合わせで説明したが、各特徴または要素は、単独で使用でき、または他の特徴および要素との任意の組み合わせで使用できることを当業者は理解されよう。加えて、本明細書で説明された方法は、コンピュータまたはプロセッサによって実行される、コンピュータ可読媒体内に包含された、コンピュータプログラム、ソフトウェア、またはファームウェアで実施することができる。コンピュータ可読媒体の例は、（有線接続または無線接続を介して送信される）電子信号と、コンピュータ可読記憶媒体とを含む。コンピュータ可読記憶媒体の例は、リードオンリメモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、レジスタ、キャッシュメモリ、半導体メモリデバイス、内蔵ハードディスクおよび着脱可能ディスクなどの磁気媒体、光磁気媒体、ならびにＣＤ−ＲＯＭディスクおよびデジタル多用途ディスク（ＤＶＤ）などの光媒体を含むが、それらに限定されない。ソフトウェアと連携するプロセッサは、ＷＴＲＵ、ＵＥ、端末、基地局、ＲＮＣ、または任意のホストコンピュータのための無線周波送受信機を実施するために使用することができる。

Claims (36)

1. 複数の３ＧＰＰネットワークノードを含む３ＧＰＰネットワークにおけるマシンタイプコミュニケーションを管理するための方法であって、
   第１のマシンタイプコミュニケーション（ＭＴＣ）デバイスおよび第２のＭＴＣデバイスに、共有可能ネットワークセグメント能力について通知するステップと、
   第１の３ＧＰＰネットワークノードと第２の３ＧＰＰネットワークノードとの間の論理３ＧＰＰ経路を介して、前記第１のＭＴＣデバイスから第１のＭＴＣサーバに、第１の通信をルーティングするステップであって、前記論理３ＧＰＰ経路には、経路識別子が割り当てられる、ステップと、
   前記論理３ＧＰＰ経路を介して、前記第２のＭＴＣデバイスから第２のＭＴＣサーバに、第２の通信をルーティングするステップと
   を備えることを特徴とする方法。
2. 前記論理３ＧＰＰ経路は、前記第１の通信と前記第２の通信によって共有されることを特徴とする請求項１に記載の方法。
3. 前記第１の通信と前記第２の通信は、同時に行われることを特徴とする請求項１に記載の方法。
4. 前記第１の通信をルーティングするステップは、３ＧＰＰネットワークノード間の複数の共有可能な論理３ＧＰＰ経路を含む共有可能なネットワークセグメントを介して、前記第１の通信をルーティングするステップを含むことを特徴とする請求項１に記載の方法。
5. 前記複数の共有可能な論理３ＧＰＰ経路の各々にそれぞれの経路識別子を割り当てるステップと、
   前記第１の通信にトラフィックインジケータを割り当てるステップと、
   前記トラフィックインジケータおよび前記共有可能な経路の前記経路識別子に少なくとも部分的に基づいて、前記第１の通信を前記複数の共有可能な論理３ＧＰＰ経路の１つにマッピングするステップと
   をさらに備えることを特徴とする請求項４に記載の方法。
6. ネットワークトラフィックの量に基づいて、前記第１の通信を再マッピングするステップをさらに含むことを特徴とする請求項５に記載の方法。
7. 前記共有可能なネットワークセグメントにおいて、前記第１の通信および前記第２の通信において多重化を行うステップをさらに備えることを特徴とする請求項４に記載の方法。
8. 前記第１のＭＴＣデバイスが、前記第１のＭＴＣデバイスのための第１のアドレスをストアするステップと、
   前記第１のＭＴＣデバイスが、前記第２のＭＴＣデバイスのための第２のアドレスをストアするステップと
   をさらに備えることを特徴とする請求項７に記載の方法。
9. 前記第１のアドレスは、第１のＩＰアドレス、第１のＷＴＲＵアドレス、または第１の宛先ＭＴＣサーバ識別のいずれかであることを特徴とする請求項８に記載の方法。
10. 前記第２のアドレスは、第２のＩＰアドレス、第２のＷＴＲＵアドレス、または第２の宛先ＭＴＣサーバ識別のいずれかであることを特徴とする請求項９に記載の方法。
11. 多重化を行うステップは、ディープパケットインスペクションを使用するステップ、およびルックアップテーブルを使用するステップの少なくとも一方を含むことを特徴とする請求項７に記載の方法。
12. 前記第１の３ＧＰＰネットワークノードは、無線アクセスネットワーク（ＲＡＮ）およびコアネットワーク（ＣＮ）の一方の内の第１のネットワークノードであり、前記第２の３ＧＰＰネットワークノードは、前記ＲＡＮおよび前記ＣＮの一方の内の第２のネットワークノードであり、前記第１のネットワークノードと前記第２のネットワークノードは、物理的接続を介して通信することを特徴とする請求項１に記載の方法。
13. 前記第１の３ＧＰＰネットワークノードは、ｅノードＢであり、前記第２の３ＧＰＰネットワークノードは、ｅノードＢであることを特徴とする請求項１２に記載の方法。
14. 前記物理的接続は、Ｘ２インタフェースを含むことを特徴とする請求項１２に記載の方法。
15. 前記第１の３ＧＰＰネットワークノードは、ｅノードＢであり、前記第２の３ＧＰＰネットワークノードは、モビリティ管理エンティティ（ＭＭＥ）であることを特徴とする請求項１に記載の方法。
16. 前記第１の３ＧＰＰネットワークノードと前記第２の３ＧＰＰネットワークノードは、物理的接続を介して通信することを特徴とする請求項１５に記載の方法。
17. 前記物理的接続は、Ｓ１−ＭＭＥインタフェースを含むことを特徴とする請求項１６に記載の方法。
18. 前記第１の通信は、前記Ｓ１−ＭＭＥインタフェースを介して、前記第１のＭＴＣデバイスから前記第１のＭＴＣサーバにルーティングされることを特徴とする請求項１７に記載の方法。
19. 前記第１の３ＧＰＰネットワークノードは、ノードＢであり、前記第２の３ＧＰＰネットワークノードは、無線ネットワークコントローラ（ＲＮＣ）であることを特徴とする請求項１に記載の方法。
20. 前記第１の３ＧＰＰネットワークノードは、無線ネットワークコントローラ（ＲＮＣ）であり、前記第２の３ＧＰＰネットワークノードは、サービングＧＰＲＳサポートノード（ＳＧＳＮ）であることを特徴とする請求項１に記載の方法。
21. 前記第１の３ＧＰＰネットワークノードは、ｅノードＢであり、前記第２の３ＧＰＰネットワークノードは、サービングゲートウェイ（Ｓ−ＧＷ）であることを特徴とする請求項１に記載の方法。
22. 前記ｅノードＢと前記サービングゲートウェイ（Ｓ−ＧＷ）は、Ｓ１−Ｕインタフェースを含む物理的接続を介して通信することを特徴とする請求項２１に記載の方法。
23. 前記第１の通信は、前記Ｓ１−Ｕインタフェースを介して、前記第１のＭＴＣデバイスから前記第１のＭＴＣサーバにルーティングされることを特徴とする請求項２２に記載の方法。
24. 前記第１の３ＧＰＰネットワークノードは、モビリティ管理エンティティ（ＭＭＥ）であり、前記第２の３ＧＰＰネットワークノードは、ＭＴＣサーバと連携するためのＭＴＣゲートウェイ（ＭＴＣ−ＧＷ）ノードであることを特徴とする請求項１に記載の方法。
25. 前記第１の３ＧＰＰネットワークノードは、サービングゲートウェイ（Ｓ−ＧＷ）であり、前記第２の３ＧＰＰネットワークノードは、ＭＴＣサーバと連携するためのＭＴＣゲートウェイ（ＭＴＣ−ＧＷ）ノードであることを特徴とする請求項１に記載の方法。
26. 前記第１の３ＧＰＰネットワークノードは、中継ノードであり、前記第２の３ＧＰＰネットワークノードは、ドナーｅノードＢであることを特徴とする請求項１に記載の方法。
27. 前記論理３ＧＰＰ経路は、複数の共有可能ネットワークセグメントを含むことを特徴とする請求項１に記載の方法。
28. 前記通知するステップは、システム情報ブロードキャスト（ＳＩＢ）をブロードキャストするステップを含むことを特徴とする請求項１に記載の方法。
29. 前記通知するステップは、
    第１のメッセージを前記第１のＭＴＣデバイスに送信するステップと、
    第２のメッセージを前記第２のＭＴＣデバイスに送信するステップと
    を含むことを特徴とする請求項１に記載の方法。
30. 前記通知するステップは、ユニバーサル加入者識別モジュール（ＵＳＩＭ）を使用するステップを含むことを特徴とする請求項１に記載の方法。
31. 所定の時間、イベント、およびコマンドのうちの少なくとも１つに基づいて、前記論理３ＧＰＰ経路の共有を選択的にアクティブ化または非アクティブ化するステップをさらに備えることを特徴とする請求項１に記載の方法。
32. 後続の共有可能なトラフィックが接続性共有を使用することを示すメッセージを処理するステップをさらに備え、前記第２の通信をルーティングするステップは、前記メッセージに従ってルーティングするステップを含み、前記メッセージは、レイヤ３メッセージまたはＮＡＳアップリンクメッセージのいずれかを含むことを特徴とする請求項１に記載の方法。
33. 複数の３ＧＰＰネットワークノードを含む３ＧＰＰネットワークにおけるマシンタイプコミュニケーションを管理するデバイスであって、
    第１のマシンタイプコミュニケーション（ＭＴＣ）デバイスおよび第２のＭＴＣデバイスに、共有可能ネットワークセグメント能力について通知するよう構成されたプロセッサを備え、
    前記プロセッサは、第１のルーティングおよび第２のルーティングのために構成され、
    前記第１のルーティングは、第１の３ＧＰＰネットワークノードと第２の３ＧＰＰネットワークノードとの間の論理３ＧＰＰ経路を介して、前記第１のＭＴＣデバイスから第１のＭＴＣサーバに、第１の通信をルーティングし、前記論理３ＧＰＰ経路には、経路識別子が割り当てられ、
    前記第２のルーティングは、前記論理３ＧＰＰ経路を介して、前記第２のＭＴＣデバイスから第２のＭＴＣサーバに、第２の通信をルーティングする
    ことを特徴とするデバイス。
34. 前記論理３ＧＰＰ経路は、前記第１の通信と前記第２の通信によって共有されることを特徴とする請求項３３に記載のデバイス。
35. 前記第１の通信と前記第２の通信は、同時に行われることを特徴とする請求項３３に記載のデバイス。
36. 前記第１のルーティングは、３ＧＰＰネットワークノード間の複数の共有可能な論理３ＧＰＰ経路を含む共有可能なネットワークセグメントを介して、前記第１の通信をルーティングすることを含むことを特徴とする請求項３３に記載のデバイス。

Images