(57)【特許請求の範囲】
【請求項１】
少なくとも１つの端末とサーバーの間の通信パスを確立するために前記少なくとも１つの端末をトリガする方法であって、前記方法は、前記少なくとも１つの端末にトリガメッセージを伝送するステップを有し、前記トリガメッセージはタイミング情報を含み、前記タイミング情報は、前記少なくとも１つの端末と前記サーバーの間の前記通信パスを確立する時間をランダムに選択する指示を含み、
前記通信パスが、少なくとも１つのデータ接続を含み、前記トリガメッセージが、第１のタイプの前記少なくとも１つのデータ接続を示す接続情報を更に含み、
前記接続情報が示す前記第１のタイプの前記少なくとも１つのデータ接続が前記少なくとも１つの端末によりサポートされているか、及び／又は、前記少なくとも１つの端末のために許可されているかを判断するステップを更に含むことを特徴とする方法。
【請求項２】
前記タイミング情報が、時間遅延及び時間ウィンドウの１以上を含むことを特徴とする請求項１に記載の方法。
【請求項３】
前記トリガメッセージが、複数の端末に伝送され、前記複数の端末が、前記少なくとも１つの端末を含むことを特徴とする請求項１又は２に記載の方法。
【請求項４】
前記接続情報を含む前記トリガメッセージが、前記少なくとも１つの端末に伝送される前に、前記サーバーで生成されて第１の中間ネットワークノードに伝送され、前記方法が、
前記第１のタイプの前記少なくとも１つのデータ接続が前記少なくとも１つの端末によりサポートされ、及び／又は、前記少なくとも１つの端末のために許可されているかを判断するステップと、
肯定的な判断のときに、前記トリガメッセージを前記第１の中間ネットワークノードから前記少なくとも１つの端末に伝送するステップとを有することを特徴とする請求項１に記載の方法。
【請求項５】
否定的な判断のときに、前記第１のタイプの前記少なくとも１つのデータ接続を示す情報を、前記少なくとも１つの端末によりサポートされ、前記少なくとも１つの端末のために許可されている第２のタイプの少なくとも１つのデータ接続を示す情報で置き換えることで前記トリガメッセージを更新するステップと、
前記トリガメッセージが更新された後で、前記トリガメッセージを前記第１の中間ネットワークノードから前記少なくとも１つの端末に伝送するステップとを更に有することを特徴とする請求項４に記載の方法。
【請求項６】
前記トリガメッセージが前記第１の中間ネットワークノードから前記少なくとも１つの端末に第２の中間ネットワークノードを介して伝送され、任意的に、前記第１の中間ネットワークノードがコントロールプレーンのゲートウェイを有し、前記第２の中間ネットワークノードがユーザープレーンのゲートウェイを有することを特徴とする請求項４又は５に記載の方法。
【請求項７】
請求項１〜３のいずれか一項に記載の方法を実行するように構成された手段を有するサーバー。
【請求項８】
サーバー及び少なくとも１つの端末に通信的に接続され、請求項１〜６のいずれか一項に記載の方法を実行するように構成された手段を有することを特徴とする第１の中間ネットワークノード。
【請求項９】
前記第１の中間ネットワークノードがコントロールプレーンのゲートウェイ又はユーザープレーンのゲートウェイであることを特徴とする請求項８に記載の第１の中間ネットワークノード。
【請求項１０】
端末が当該端末とサーバーの間の通信パスを確立する方法であって、前記方法が、
タイミング情報を含むトリガメッセージを受信するステップと、
前記タイミング情報に従って前記端末と前記サーバーの間の前記通信パスを確立するステップとを有し、
前記タイミング情報が、前記端末と前記サーバーの間の前記通信パスを確立する時間をランダムに選択する指示を含み、
前記端末と前記サーバーの間の前記通信パスが、少なくとも１つのデータ接続を含み、
前記トリガメッセージが第１のタイプの前記少なくとも１つのデータ接続を示す接続情報を更に含み、
前記接続情報が示す前記第１のタイプの前記少なくとも１つのデータ接続が前記少なくとも１つの端末によりサポートされているか、及び／又は、前記少なくとも１つの端末のために許可されているかを判断するステップを更に含むことを特徴とする方法。
【請求項１１】
前記タイミング情報が、時間遅延及び時間ウィンドウの１以上を含むことを特徴とする請求項１０に記載の方法。
【請求項１２】
前記端末と前記サーバーの間の前記通信パスが前記接続情報に従って確立されることを特徴とする請求項１０又は１１に記載の方法。
【請求項１３】
請求項１０〜１２のいずれか一項に記載の方法を実行するように構成された手段を有する端末。
【請求項１４】
請求項１３に記載の端末と、請求項８に記載のサーバーを有するシステム。
【請求項１５】
プロセッサーにより実行されたときに、請求項１〜６及び請求項１０〜１２のいずれか一項に記載のステップを実行するように構成されたソフトウェアコード部分を有するコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
一般に、本発明は、データ通信の分野に関する。より詳細には、本発明は、例えば、マシンツーマシン（Ｍ２Ｍ）通信など、端末とアプリケーションサーバーの間のデータ通信の分野に関する。
【背景技術】
【０００２】
既存のデータ伝送環境では、装置（「端末」とも呼ばれる）は、ときに、ネットワーク上でデータをサーバーに伝送することが必要とされ、その逆もそうである。固定又はモバイルネットワークでのデータ接続の確立は、一般に、デバイス指向である。例えば、ＧＳＭ及びＵＭＴＳネットワークでのデータ接続の１つのタイプを表すPacket Data Protocol（ＰＤＰ）コンテキストは、ユーザー端末によりセットアップされる。また、ファイアウォールやネットワークアドレス変換装置のような、殆どのＩＰミドルボックスは、装置によるデータセッションの開始に依存する。
【０００３】
このような装置は、現在３ＧＰＰ（例えば、ＴＳ２２．３６８参照）で標準化されているマシンツーマシン（Ｍ２Ｍ）通信の分野に適用され得る。多くのＭ２Ｍアプリケーションでは、Ｍ２Ｍ装置がＭ２Ｍ装置とＭ２Ｍサーバーの間の通信パスを確立することで十分であるが、Ｍ２Ｍサーバーがデータ接続を開始できることが要求されるアプリケーションもある。
【０００４】
Ｍ２Ｍサーバーが装置との通信を開始する例は、スマート電気メータリングアプリケーションである。通常、メーターは、各月末のメーターの読みを報告し得る。しかし、例えば、顧客が異なる電気プロバイダに変えた場合は、Ｍ２Ｍサーバーは、特定の契約終了日のメーターの読みを要求するようにメーターをトリガできることが必要である。
【０００５】
サーバー側から接続をセットアップするには、サーバーは、装置に、その装置が接続をセットアップすべきであることを通知する必要がある。このプロセスは、トリガリングと呼ばれる。トリガリングには異なる方法があり、これらは全て、場合によっては、装置がセットアップしなければならないデータ接続のためのサーバーのアドレスが端末に事前設定されていなければ、そのサーバーのアドレス（例えば、ＡＰＮ，ＩＰアドレス又はＦＱＤＮ）を示しつつ、トリガが、サーバーへの接続をセットアップすることの要求を端末に単に提供するという事実を共通して有する。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
端末とサーバーの間のサーバー開始型の通信パスを確立するための改善された方法及びシステムを提供することが本発明の目的である。
【課題を解決するための手段】
【０００７】
この目的のため、端末とサーバーの間の通信パスを確立するように少なくとも１つの端末をトリガする方法が開示される。この方法は、端末にトリガメッセージを伝送するステップを有し、トリガメッセージは、少なくとも１つの端末とサーバーの間の通信パスがいつ確立されるべきかを示すタイミング情報を含む。
【０００８】
本発明は、これまで、端末がいつサーバーへの通信パスをセットアップすべきかのタイミングにサーバーが影響を有していなかったという認識に基づいている。一旦サーバーがトリガメッセージを端末に伝送すると、接続がいつセットアップされるかの決定は端末に委ねられていた。このような構成は、一群の端末がすべて同時にトリガされるときに特に問題となり得る。各端末は、典型的には、他の端末が何をしているかにつての情報を有さないため、同時にトリガされた全ての端末がサーバーへの接続のセットアップを同時に開始し、そのため、システムの処理及び通信資源に過剰の負荷を課すという状況を生じ得た。本発明は、端末がいつサーバーへの接続を確立すべきかを指定するタイミング情報を端末に提供するトリガメッセージに含めることにより、この状況を軽減又は回避することを助ける。端末にこのようなタイミング情報を提供することで、端末は、接続がいつセットアップされるかについての少なくともある程度のコントロールをサーバーと共有することが可能になる。その結果、サーバーは、トリガメッセージに応答して異なる端末がいつそれらの接続をセットアップするかを管理することが可能となる。サーバーは、典型的には、システム内で何が生じているかのより広い概観（全体像）を有する（例えば、サーバーは、いつ、いくつの端末がトリガされたか、及び、システムで他に何が生じているかについての概観を有する）ため、このようなシステム内の異なる端末の集中化された管理は、システムをより効率的にする。トリガメッセージにタイミング情報を挿入することにより、サーバーは、個々の端末がそれらの接続をセットアップするタイミングを制御するために、サーバーの知識を利用することが可能である。例えば、多数の端末が同時にトリガされた場合、サーバーは、個々の端末の接続のセットアップの発生を時間的に拡散させることができる。
【０００９】
集中化された管理は、システム内の異なる端末間の競合の可能性も低下させる。
【００１０】
代替的に、上記の機能は、サーバー内で実施されず、何らかの中間ネットワークノード（例えば、ネットワークゲートウェイ）内で実施され得る。専ら端末により決定されるというよりはむしろ、システムのより広い概観を有する何らかのエンティティにより端末とサーバーの間の通信パスがいつ確立されるべきかについてのタイミング情報が端末に提供される限り、全体的なシステムが利益を受ける。
【００１１】
本書で使用されるところの、サーバーへの通信パスをセットアップする端末の文脈における「通信パス」の語は、端末とサーバーの間でデータ（典型的には、ユーザーデータ）を通信するためのパス又はチャネルを意味し、その少なくとも一部は、典型的には、端末とネットワークゲートウェイなどの何らかの中間ネットワークノードの間の少なくとも１つのデータ接続を含み、それの上で、端末とネットワークゲートウェイは、ＰＤＰコンテキスト又は３ＧＰＰ  ＴＳ  ２３．０６０に記載のＵＭＴＳベアラ又は３ＧＰＰ  ＴＳ  ２３．４０１に記載のＥＰＳベアラなどの１以上のプロトコルに従ってデータを交換することができる。当業者は、「ネットワークゲートウェイ」の語が、インターネット又はコーポレートパケットデータネットワークなどの外部パケットネットワークとモバイルネットワークの間のゲートウェイとして機能するように適合された中間ネットワークノードを意味することを認識する。既存のＧＰＲＳ／ＵＭＴＳネットワークでは、ゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）は、ネットワークゲートウェイとして動作し、一方、ＬＴＥネットワークでは、ＰＤＮゲートウェイ（Ｐ−ＧＷ）ノードは、ネットワークゲートウェイである。
【００１２】
Ｍ２Ｍ通信は典型的にはサーバーとの通信パスをセットアップすることを要し得る幾百、幾千又は幾百万の端末を含むため、開示された解決策は、この分野に限定されないが、Ｍ２Ｍ通信に特に有利である。単一の端末が１以上のサーバーと通信し得るため、端末の数とこれらの端末が接続をセットアップし得るサーバーの数の関係は常にＮ：１ではないが、典型的には、端末の数は、なおサーバーの数よりも顕著に大きい。その結果、任意の単一のサーバーは、種々の端末がいつこのサーバーとの通信パスをセットアップするかについてのタイミングのコントロールを有することで利益を受けるであろう。
【００１３】
Ｍ２Ｍ通信の一例は、サーバーにより、例えば、大規模顧客基盤の家庭におけるスマート電気メーターから情報を収集することを含む。他の例は、様々なタイプのサーバーへの先進データ接続をサポートし得る通信モジュールを装備し得る監視システム、センサー等を含む。また、モバイルナビゲーション端末及び支払い端末は、Ｍ２Ｍアプリケーションの例である。提示した解決策は、このようなアプリケーションのための端末とサーバーの間の通信パスの確立の効率的なサーバーベースの開始を提供する。
【００１４】
種々の実施形態において、トリガメッセージに含まれるタイミング情報は、時間遅延、時間ウィンドウ、及び、端末が端末とサーバーの間の通信パスを確立するための時間をランダムに選択するための指示の１以上を含み得る。通信パスがいつ確立されるべきかの時点を示し得る情報の他の例も考えられ、本発明の範囲内である。
【００１５】
１実施形態では、トリガメッセージは、例えば、グループアドレッシングを用い、又は、トリガメッセージを複数の基地局上で同報することで、これらの基地局のカバレッジエリア内に位置する複数の端末に伝送され得る。
【００１６】
上記のように、端末とサーバーの間で確立される通信パスは、例えば、端末とネットワークゲートウェイの間の、端末とサーバーの間でどのタイプの通信が必要かに応じて、パラメータの組に従ってセットアップされた少なくとも１つのデータ接続を含み得る。１実施形態では、トリガメッセージは、このような端末とサーバーの間の通信パスにおける第１のタイプのデータ接続を示す接続情報を更に含み得る。
【００１７】
当業界で「ＱｏＳパラメータ」又は「ＱｏＳプロファイル」と通常呼ばれるパラメータの組は、例えば、最大ビットレート、保証ビットレート、アロケーションセットアップ、タイムアウトリミット及びキュー設定などのパラメータを含む。データ接続のタイプの幾つかの例は、ベストエフォート接続、会話式接続、又は、ストリーミング接続を含む。異なるタイプのデータ接続には、異なるＱｏＳパラメータの組が必要である。例えば、会話式データ接続は、音声通信を可能にするために、遅延やジッターに関する厳しい条件を有し得るが、ストリーミング接続では、遅延はさほど重要でない場合がある。
【００１８】
このように、端末とネットワークゲートウェイの間のデータ接続は、端末とゲートウェイの間でセットアップされた「トンネル」と見ることができる。そして、サーバー（又はトンネル外、すなわち、外部データパケットネットワークの他のエンティティ）が端末にＩＰパケットを送信することが必要なときは、サーバーは、ネットワークゲートウェイにルーティングされたＩＰアドレスを使用するであろう。そこから、ＩＰパケットは、データ接続を介して端末に「トンネリング」される。逆に、ＩＰパケットを端末から外部ネットワークのエンティティにルーティングするときは、ＩＰパケットは、トンネルにおける中間ノードのＩＰアドレスを知る必要無しに、データ接続を介して端末からネットワークゲートウェイに「トンネリング」される。端末とサーバーの間の全体的な通信パスは、１以上のこのような「トンネル」を含み得る。そして、ネットワークゲートウェイとサーバーの間で、パケットデータネットワークの従来のＩＰルーティングが使用され得る。
【００１９】
勿論、全体の通信パスがデータ接続のタイプを規定する何らかのパラメータの組に従ってセットアップされることを要し得る（すなわち、請求項１に規定の「少なくとも１つのデータ接続」が実際に端末とサーバーの間の全体の通信パスである）という点において、端末とサーバーの間の全体の通信パスが「トンネル」であり得る実施形態も可能である。また、例えば、端末からネットワークゲートウェイへの１つのトンネルとゲートウェイからサーバーへの他のトンネルなど、トンネルの連結が存在する実施形態も可能である。このような実施形態では、両トンネルのＱｏＳパラメータが同一のＱｏＳの指示から抽出されても良く、又は、異なるＱｏＳの指示が存在しても良い。特定の１実施態様では、ネットワークゲートウェイとサーバーの間のトンネル（及び関連するＱｏＳパラメータ）は、トリガメッセージにおけるこのトンネルのタイプの指示を提供することでは必ずしもセットアップされない。このような全ての実施形態は本発明の範囲に含まれ、どのようなパラメータの組（すなわち、必ずしも上記のＱｏＳパラメータではない）がこのようなデータ接続のタイプを指定するのに最も適切であるかを当業者が認識するであろうことが理解される。
【００２０】
端末がどのタイプの接続を確立すべきかについての情報を、トリガメッセージ内で、すなわち、端末がこのデータ接続を含む通信パスをセットアップする前に、端末に提供することで、端末が誤ったタイプのデータ接続をセットアップすることが回避され、サーバーと端末の間で交換されるメッセージの数を顕著に減少させることが可能になる。その結果、システムの処理資源が保全され、非効率な帯域幅使用が減少され得る。
【００２１】
サーバーが、端末がどのタイプのデータ接続をセットアップするかに影響することを許容することは、技術及び種々のアプリケーションが発展するにつれてますます重要になるだろう。（そこでは、潜在的にはより多様なタイプのデータ接続が端末により要求され、サポートされるであろう。）例えば、ビデオ監視のアプリケーションは、ビデオストリームに適切なＱｏＳを有するベアラを必要とするであろう。
【００２２】
種々の実施形態において、接続情報は、例えば、ＱｏＳプロファイル又はQoS Class Identifier（ＱＣＩ）の一部又は全部を含み得る。ＱＣＩは、データ接続をセットアップするためにどのＱｏＳパラメータの組を使用すべきかを示す数字の形態であり得る。例えば、１に等しいＱＣＩは、会話式のタイプのデータ接続に必要な全てのＱｏＳパラメータを意味し得る。ＱＣＩを用いる利点は、これがＱｏＳプロファイルよりもずっと小さく、したがって、トリガメッセージ内で移送することがずっと容易であることである。ＱＣＩは、トリガメッセージが同報チャネル上で送信されるアプリケーションに特に有利である。勿論、接続のタイプを示し得る情報（例えば、要求されたデータ接続のＱｏＳパラメータの範囲又は回路交換接続又はパケット交換接続が使用されるかなど）の他の例も考えられ、本発明の範囲内である。
【００２３】
他の実施形態では、上記方法に使用するサーバー及び端末も開示される。
【００２４】
更に、上記方法において及び／又は上記端末と共に使用されるように構成された中間ネットワークノードが開示される。このような中間ネットワークノードは、直接又は他の中間ノードを介して端末及びサーバーに通信的に接続され、サーバーで生成されたトリガメッセージは、ノードにより端末に伝送される前に中間ネットワークノードに送信され得る。このような中間ネットワークノードは、例えば、上記のＧＧＳＮ又はＰ−ＧＷノードなど、端末とサーバーの間でユーザーデータを通信するネットワークゲートウェイであり得、又は、後で詳述するマシンタイプの通信ゲートウェイ（ＭＴＣ  ＧＷ）など、制御データを通信するためのネットワークゲートウェイであり得る。
【００２５】
サーバーがトリガメッセージに接続情報を含めるように構成されている実施形態では、中間ネットワークノードは、第１のタイプのデータ接続が端末によりサポートされ、及び／又は、端末のために許可されているかを判断するように構成され得る。肯定的な判断のときに、中間ネットワークノードは、トリガメッセージを更に端末に伝送するように構成され得る。否定的な判断のときに、中間ネットワークノードは、第１のタイプのデータ接続を示す情報を第２のタイプのデータ接続を示す情報で置き換えることでトリガメッセージを更新するように構成され得る。代替的に、否定的な判断のときに、中間ネットワークノードは、場合によってそのことをサーバーに通知しつつ、端末へのトリガメッセージの伝送を停止するように構成され得る。このような機能は、端末に提供されるトリガメッセージが、例えば、端末の加入条件に従って、実際に端末によりサポートされ、及び／又は、これのために許可されたタイプのデータ接続のみについての要求を含むことを確実にする。
【００２６】
サーバーが、本発明に従ってタイミング情報を含めずにトリガメッセージを送信するように構成されたサーバーであり得る実施形態では、中間ネットワークノードは、本書に記載の方法を、サーバーから受信したトリガメッセージにタイミング情報及び、任意的に、接続情報を付加することで実施するように構成され得る。これは、有益であり得、その理由は、中間ネットワークノードが、例えば、端末の加入条件に従えば、いつデータ接続が確立されるべきであり、及び／又は、どのタイプのデータ接続が端末によりサポートされ、及び、端末のために許可されているかについての情報を有するエンティティであり得るためである。
【００２７】
種々の実施形態において、１以上の中間ネットワークノードがトリガメッセージを伝送するために使用され得る。例えば、１実施形態では、トリガメッセージが最初にサーバーから、例えば、コントロールプレーンのゲートウェイなどの第１の中間ネットワークノードに伝送され、その後、端末に伝送される前に、第１の中間ネットワークノードから例えば、ユーザープレーンのゲートウェイなどの第２の中間ネットワークノードに伝送され得る。このような実施形態は、トリガメッセージを伝送するために先に確立されたデータ接続が使用し得る場合に有利であり得る。さらに、これは、後続のデータ接続のセットアップに携わるエンティティ（例えば、ＳＧＳＮ、Ｓ−ＧＷ、ＭＭＥ、ＧＧＳＮ、Ｐ−ＧＷ）がトリガメッセージ内の情報に基づいて、それまでに準備することを可能にし得る。
【００２８】
また、本開示は、本書に記載の種々の機能を実施する（場合により分散した）部分を有するコンピュータプログラム、そのようなソフトウェア部分のためのデータキャリア、及び、上記のようなサーバー及び端末を少なくとも有する通信システムに関する。
【００２９】
以下、本発明の実施形態がより詳細に説明される。しかし、これらの実施形態は、本発明の保護の範囲を制限するものと解釈してはならないことが理解されるべきである。
【図面の簡単な説明】
【００３０】
【図１】端末をアプリケーションサーバーに接続する４Ｇ通信ネットワークの概略図。
【図２Ａ】本発明の種々の実施形態に従ってサーバーと端末の間の通信パスを確立するためのトリガメッセージの提供の概略図。
【図２Ｂ】本発明の種々の実施形態に従ってサーバーと端末の間の通信パスを確立するためのトリガメッセージの提供の概略図。
【図２Ｃ】本発明の種々の実施形態に従ってサーバーと端末の間の通信パスを確立するためのトリガメッセージの提供の概略図。
【図２Ｄ】本発明の種々の実施形態に従ってサーバーと端末の間の通信パスを確立するためのトリガメッセージの提供の概略図。
【図２Ｅ】本発明の種々の実施形態に従ってサーバーと端末の間の通信パスを確立するためのトリガメッセージの提供の概略図。
【図２Ｆ】本発明の種々の実施形態に従ってサーバーと端末の間の通信パスを確立するためのトリガメッセージの提供の概略図。
【図３】本発明の実施形態に従って、種々のトリガメッセージがどのようにコントロールプレーンのゲートウェイを介して端末に伝送され得るかの例示的な説明を提供する。
【図４】本発明の実施形態を実施するために適する種々のトリガリングメカニズムの概略図を提供する。
【図５】本発明の実施形態を実施するために適する種々のトリガリングメカニズムの概略図を提供する。
【図６】本発明の実施形態を実施するために適する種々のトリガリングメカニズムの概略図を提供する。
【図７】本発明の実施形態を実施するために適する種々のトリガリングメカニズムの概略図を提供する。
【図８】本発明の実施形態を実施するために適する種々のトリガリングメカニズムの概略図を提供する。
【発明を実施するための形態】
【００３１】
図１は、通信ネットワーク１の概略図を示す。通信ネットワーク１は、サーバー２と端末３の間のデータネットワーク４上でのデータセッションを許容し、端末の通信ネットワーク１へのアクセスはワイヤレスである。
【００３２】
図１の通信ネットワークでは、３つの世代の通信ネットワークが簡略の目的もあって概略的に示されている。構成及び概観のより詳細な説明は、その全体が参照により本願に含められる３ＧＰＰ  ＴＳ  ２３．００２に見られる。
【００３３】
図１の下方の分岐は、ＧＧＳＮ、サービング・ＧＰＲＳ・サポート・ノード（ＳＧＳＮ）及び無線アクセスネットワーク（ＲＡＮ）を有するＧＰＲＳ又はＵＭＴＳ通信ネットワークを示す。ＧＳＭ／ＥＤＧＥ無線アクセスネットワーク（ＧＥＲＡＮ）については、ＲＡＮは、いずれも図示されない、複数の基地局送受信機（ＢＴＳ）に接続された基地局制御装置（ＢＳＣ）を有する。ＵＭＴＳ無線アクセスネットワーク（ＵＴＲＡＮ）については、ＲＡＮは、同様に図示されない、複数のＮｏｄｅＢに接続された無線ネットワーク制御装置（ＲＮＣ）を有する。ＧＧＳＮ及びＳＧＳＮは、一般には、端末３の加入情報を含むホームロケーションレジスタ（ＨＬＲ）に接続される。図では、ＨＬＲは、ネットワークに端末３を認証する認証センター（ＡｕＣ）と組み合わされている。
【００３４】
図1の上方の分岐は、通常、Long Term Evolution（ＬＴＥ）又はEvolved Packet System（ＥＰＳ）と表される次世代通信ネットワークを示す。このようなネットワークは、Ｐ−ＧＷ及びServing Gateway（Ｓ−ＧＷ）を有する。ＬＴＥネットワークのＥ−ＵＴＲＡＮは、パケットネットワークを介してＳ−ＧＷに接続された端末３にワイヤレスアクセスを提供するevolved NodeB（ｅＮｏｄｅＢ又はｅＮＢ）を有する。Ｓ−ＧＷは、シグナリングの目的で、Home Subscriber Server（ＨＳＳ）及びMobility Management Entity（ＭＭＥ）に接続される。ＨＳＳは、加入プロファイルリポジトリ及び認証センター（ＡｕＣ）を含む。ＬＴＥネットワークの一般的な構成についての更なる情報は、３ＧＰＰ  ＴＳ  ２３．４０１に見出し得る。
【００３５】
ＧＰＲＳ及びＵＭＴＳネットワークのＧＧＳＮノード及びＬＴＥネットワークのＰ−ＧＷノードは、例えば、ＱｏＳポリシーエンフォーシング、使用メータリング及びＩＰアドレス割当などの機能を提供する外部データネットワーク４とモバイルネットワークの間のユーザープレーンのゲートウェイとして動作する。図１の全てのネットワークは、任意的に、現在標準化されている、例えば、ＭＴＣ  ＧＷなどのコントロールプレーンのゲートウェイも含み得る。コントロールプレーンのゲートウェイは、サーバーからの制御メッセージのためのモバイルネットワークにおけるエントリーポイントとして動作するように意図される。コントロールプレーンのゲートウェイの目的は、典型的には、許可されていない制御メッセージ、又は、許可されていないサーバーから送信された制御メッセージからネットワークを保護することである。コントロールプレーンのゲートウェイは、サーバーが１つのネットワーク運用者とのみ通信する場合に、サーバー中に事前規定され得る。さもなければ、サーバーは、本発明に記述されるトリガメッセージなどの制御メッセージをどの運用者に送信する必要があるかを最初に決定することが必要である。装置ＩＤ、グループＩＤ又はＩＭＳＩに基づいて、サーバーは、正しいモバイル運用者ネットワークを見つけることができるべきである。
【００３６】
勿論、ユーザープレーンのゲートウェイ及びコントロールプレーンのゲートウェイの機能は、単一のノードに結合し、又は、図１で示されるよりも多数のノードに分散し得る。
【００３７】
図２Ａ−２Ｆは、本発明の種々の実施形態に従ってサーバーと端末の間のデータ接続を確立するためのトリガメッセージの提供の概略図である。明確化ため、トリガメッセージの伝送の関連ステップのみが図２Ａ−２Ｆに示されている。他の手順、例えば、認証、実際のデータ接続のセットアップ及びユーザーデータの交換に関連する手順は、含まれていない。
【００３８】
図２Ａに示すように、１実施形態では、サーバー２は、トリガメッセージＴＭ１を生成してこれを直接端末３に伝送するように構成され得る。そのため、サーバー２は、トリガメッセージを生成するプロセッシングユニットと、トリガメッセージを伝送する通信モジュールを含み得る。
【００３９】
トリガメッセージを端末に直接伝送するサーバーの文脈では、「直接」の語は、図２Ａの実施形態を、サーバー２で生成されたトリガメッセージが１以上の中間ネットワークノードを介して伝送され、及び、場合によっては、更にこれらにより処理される図２Ｂ−２Ｆの実施形態と区別するためにのみ使用される。このように、図２Ａに示す実施形態では、トリガメッセージは、例えば、セルブロードキャストセンター（ＣＢＣ）又はＳＭＳサービスセンター（ＳＭＳ−ＳＣ）など、図２Ｂ−２Ｆに記載の中間ノード以外のエンティティを介して端末３に伝送され得る。
【００４０】
トリガメッセージＴＭ１は、端末３がサーバー２との通信パスを確立すべき時点を指定する少なくともタイミング情報を含むことにより形成される。通信パスの少なくとも一部は、少なくとも１つの特定のタイプのデータ接続を含むため、タイミング情報は、端末３がいつデータ接続のセットアップを開始すべきかを指定する。タイミング情報を有するトリガメッセージの受信に応答して、端末３は、タイミング情報に基づいて端末３が決定する時点まで、通信パス／データ接続の確立を遅延させる。
【００４１】
１実施形態では、タイミング情報は、例えば、端末３に（例えば、トリガメッセージの受信の時点から又はトリガメッセージがサーバー２からいつ送信されたかを示すタイムスタンプから測定して）１時間だけ通信パス／データ接続の確立を遅延させるように指示する遅延時間の形態で、トリガメッセージに含まれ得る。例えば、タイミング情報は、７５秒の遅延後に、又は、１３分１５秒の遅延後に通信パスを確立するように端末３を指示し得る（すなわち、タイミング情報は、遅延を数秒まで正確に指定し得る）。
【００４２】
タイミング情報はまた、０７：３５：３５に（すなわち、特定の時点に）通信パス確立するように端末３を指示し得る。
【００４３】
他の実施形態では、タイミング情報は、例えば、１６：００と１７：００の間、又は、より短い時間ウィンドウである０３：４５：１５と０３：４５：４５の間に通信パス／データ接続を確立するように端末３を指示するなど、時間ウィンドウの形態であり得る。
【００４４】
更に他の実施形態では、タイミング情報は、通信パス／データ接続を確立する時点をランダムに選択するように端末３を指示し得る。この実施形態は、例えば、グループアドレッシングを用いて、トリガメッセージが一群の端末に送信され、各端末がトリガメッセージに応答する時点をランダム化する状況で特に有益であり得る。
【００４５】
上記のタイミング情報の可能なタイプの１以上の例示的な説明は相互に組み合わされ得る。例えば、通信パス／データ接続を確立する時点をランダムに選択するように端末３を指示するタイミング情報の実施形態は、例えば、タイミング情報が、通信パス／データ接続を確立するために特定の時間ウィンドウの何らかのランダムな時点（例えば、０２：００と０４：００の間のランダムな時点）を選択するように端末３を指示し得るように、遅延時間又はウィンドウ時間の提供と組み合わされ得る。他の例では、タイミング情報は、今と１時間の間で通信パスを確立するための時点をランダム化するように端末３を指示し得る。代替的には、時間遅延及び時間ウィンドウの両方を提供するタイミング情報が可能であり、この場合、タイミング情報は、期間とともに遅延を示し、例えば、１時間の時間ウィンドウの間で１５分の遅延の後に通信パスを確立するように端末３を指示する。このような実施形態は、絶対的な時間の指示の提供と異なり、時間遅延及び時間ウィンドウ情報の提供に全ての関連するノードの間での（場合によっては、タイムゾーンやサマータイムも考慮した）同期を必要としないため、有益であり得る。更に他の例では、タイミング情報は、例えば、今から１５分後から今から３０分後までに通信パスを確立するように端末を指示する２つの遅延を含み得る。
【００４６】
タイミング情報は、（１つの）トリガが一群の端末に送信されるときにネットワーク負荷を拡散させる（すなわち、端末がそれらの負荷をランダム化する）、及び／又は、（複数の）トリガが個々の端末に送信されるときにネットワーク負荷を拡散させる（すなわち、サーバーが端末の負荷をランダム化する）ために使用され得る。
【００４７】
更に、トリガメッセージ内のタイミング情報は、例えば、データの記録を開始し、４日後にデータを送信し、又は、７月１日１３：００と７月４日１５：００の間にデータを記録し、その後データを送信するなど、端末３がそのデータのサーバー２への送信を開始する前に何かを行うように端末３を指示し得る。
【００４８】
上記例が示すように、タイミング情報は、数秒から数日の時間に関連し得る。どの時点で端末３が通信パス／データ接続を確立すべきであり、又は、すべきでないかを示す他のタイプのタイミング情報も考えることができ、本発明の範囲内であることが意図される。
【００４９】
トリガメッセージＴＭ１は、リクエストをその承認と関連づけ、アプリケーションがリクエストをキャンセルすることを可能にするために、端末３の識別、アプリケーションの識別及び／又は重複したリクエストを検出することを可能にするためのこのリクエストに関連するリクエストカウンターなど、従来のトリガメッセージに典型的に含まれていた情報をも含み得る。トリガメッセージＴＭ１は、また、任意的に、ＩＰアドレス（または完全修飾ドメイン名）及び／又は端末がデータ接続を確立することをトリガされるアプリケーションサーバー２のポート番号、緊急リクエストの指示、端末に（例えばＳＭＳで）接続できないときにネットワークに蓄積されたトリガの除去を許可する有効タイマー、トリガリングを送信すべきエリア、及び／又は、（例えば、サーバー２との通信パスを確立する前に端末３に何かをすることを指示するための）限定された程度の用途特定情報を含み得る。
【００５０】
トリガメッセージＴＭ１を受信すると、端末３は、メッセージからタイミング情報を取得し、その後、取得したタイミング情報に基づいて、どの時点でサーバー２との通信パスが確立されるべきかを判断し、最後に、その決定した時点に通信パスを確立するように構成さる。そのため、端末３は、トリガメッセージからタイミング情報を抽出し、通信パスがいつ確立されるべきかを決定できるプロセッシングユニットと、要求された通信パスを確立するための通信モジュールを含み得る。端末３のプロセッシングユニット及び／又は通信モジュールの機能の少なくとも一部は、端末３内の（Ｕ）ＳＩＭ内に含まれ得る。
【００５１】
図２Ｂ及び２Ｃは、図２Ｂ及び２Ｃでは、サーバー２がトリガメッセージ内にタイミング情報を含まない点で図２Ａと異なる。その代わり、端末３に伝送されるトリガメッセージにタイミング情報を含めるのが何らかの中間ネットワークノードである。
【００５２】
図２Ｂでは、サーバー２は、例えば、上記のＧＧＳＮ、Ｐ−ＧＷまたはＭＴＣ−ＧＷなどの中間ネットワークノード５にトリガメッセージＴＭ０を伝送する。中間ノード５は、直接又は他の中間ノードを介してサーバー２に通信的に接続され、中間ノード５は、サーバー２から（外部ネットワーク４上で）トリガメッセージを受信し得る。中間ノード５は、また、直接又は他の中間ノードを介して端末３に通信的に接続され、中間ノード５は、更に端末３にモバイルネットワーク上でトリガメッセージを伝送し得る。
【００５３】
図２Ｂに示される実施形態では、中間ノード５は、サーバー２からタイミング情報を含まないトリガメッセージＴＭ０（すなわち、トリガメッセージＴＭ０は、従来のトリガメッセージであり得る）を受信する。中間ノード５は、その後、トリガメッセージにタイミング情報を付加し、これにより、新たなトリガメッセージＴＭ１を生成し、そして、タイミング情報を有するトリガメッセージＴＭ１を端末３に伝送するように構成される。トリガメッセージＴＭ１及び端末３に関する上記の議論は、ここでも適用可能であり、したがって、繰り返さない。
【００５４】
図２Ｃは、２つの中間ノードである第１の中間ノード６及び第２の中間ノード７が使用される点で図２Ｂと相違する。第１の中間ノード６は、直接又は他の中間ノードを介してサーバー２に通信的に接続し、中間ノード６は、トリガメッセージをサーバー２から受信し得る。第１の中間ノード６は、また、直接又は他の中間ノードを介して中間ノード７に通信的に接続され、中間ノード６は、トリガメッセージを更にノード７に伝送し得る。中間ノード７は、同様に直接又は他の中間ノードを介して端末３に通信的に接続し、中間ノード７は、今度は、トリガメッセージを端末３に更に伝送し得る。
【００５５】
図２Ｃに示す実施形態では、第１の中間ノード６又は第２の中間ノード７のどちらかは、図２Ｂに示す中間ノード５が行うのと同様にして、トリガメッセージにタイミング情報を含ませることができる。
【００５６】
図２Ａ−２Ｃの全ての実施形態において、トリガメッセージは、サーバー２と端末３の間の通信パスを確立する端末３の一部として、サーバー２が端末３にセットアップさせることを要する少なくとも１つのデータ接続のタイプを指定する接続情報を更に含み得る。接続情報は、例えば、完全又は部分的なＱｏＳプロファイル、ＱＣＩ又は特定のタイプのデータ接続を適切に識別できる何らかの他の情報を含み得る。通信パス内の要求されたタイプのデータ接続を示す情報を、トリガメッセージにその情報を含めることにより、データ接続／通信パスがセットアップされる前に提供することで、当業界で現在なされているように、誤ったタイプの接続をセットアップし、その後、それを修正しなければならないことによりシステム資源の浪費をしなければならないことの防止を可能にする。
【００５７】
このような実施形態では、タイミング情報だけでなく、接続情報も含むトリガメッセージを受信すると、端末３は、メッセージから接続情報を取得し、サーバー２への通信パスを確立するように構成され、通信パスは、メッセージで指定されるタイプのデータ接続を含む。
【００５８】
図２Ｄ−２Ｆは、トリガメッセージが、タイミング情報に加えて、端末によりサポートされ、端末のために許可された通信パス内のデータ接続のタイプを指定する接続情報を含むときに、１以上の中間ノードが、端末へのトリガメッセージの提供に際してサーバー２をどのようにさらに補助するかを示す。
【００５９】
図２Ｄは、図２Ｂに示す中間ネットワークノード５と同様、例えば、ＧＧＳＮ、Ｐ−ＧＷ又はＭＴＣ  ＧＷなどの中間ネットワークノード５がサーバー２と端末３の間の通信パスに含まれ得ることを示す。
【００６０】
中間ノード５は、上記のように、サーバーからタイミング情報だけでなく接続情報も含むトリガメッセージＴＭ２を受信する。
【００６１】
中間ノード５は、その後、受信したトリガメッセージＴＭ２から接続情報を抽出し、その接続情報により識別される特定のＱｏＳプロファイルが端末３によりサポートされ、及び／又は、端末３の加入条件で許容されているかをチェックするように構成され得る。これは、例えば、加入者情報を含むＨＳＳでのチェックにより行われ得る。
【００６２】
中間ノード５がＴＭ２で識別されるタイプの接続が端末３によりサポートされ、そのために許容されていると判断した場合には、中間ノード５は、トリガメッセージＴＭ２を更に端末３に伝送し得る。他の場合は、中間ノード５は、端末３へのトリガメッセージの伝送を停止する（場合によっては、トリガメッセージＴＭ２の伝送が中断されたことをサーバー２に通知する）か、トリガメッセージから接続情報を削除することによりトリガメッセージを更新するか、或いは、サーバー２により要求された接続のタイプを指定するＴＭ２の接続情報を、端末３によりサポートされ、及び、端末３のために許可されるであろう接続のタイプを指定する最も適切な接続情報で上書きし得る。最後の２つの場合、中間ノード５は、その後、更新されたトリガメッセージＴＭ２′を端末３に伝送し得る。
【００６３】
例えば、中間ノード５は、端末３の加入のためのデフォルトのＱｏＳプロファイルが何であるかを確かめるようにＨＳＳでチェックし、後のトリガシグナリングに適切なＱｏＳ識別を挿入するように構成されたＭＴＣ  ＧＷを有し得る。
【００６４】
図２Ｅ及び２Ｆは、図２Ｃに記載の中間ノードと類似の２つの中間ノードが使用されている点で図２Ｄと相違する。図２Ｅ及び２Ｆに示されるサーバー２により伝送されるトリガメッセージＴＭ２、更新されたトリガメッセージＴＭ２′、サーバー２及び端末３は、図２Ｄに示されるものと同様であり、したがって、ここではこれらの議論は繰り返さない。図２Ｅは、１つではなく、２つの中間ネットワークノードが使用され、第１の中間ネットワークノード６がトリガメッセージＴＭ２を第２の中間ネットワークノード７に伝送し、これが、その後、サーバー２により要求されたタイプの接続が端末３によりサポートされ、端末３のために許可されているかをチェックするように構成されている点で図２Ｄと相違する。中間ノード７の機能は、図２Ｄの中間ノード５のそれと同様であり、簡単のため、ここでは繰り返さない。
【００６５】
図２Ｅに示す構成は、第１の中間ノード６が、サーバーがネットワークにメッセージを送信する権限を有するかどうかをチェックし、サーバー２が送信する権限を有するメッセージを送信するだけであるかをチェックするように構成されている場合に有利であり得る。
【００６６】
１実施形態では、第１の中間ノード６は、例えば、ＭＴＣ  ＧＷなどのコントロールプレーンのゲートウェイを含み、一方、第２の中間ノード７は、例えば、Ｐ−ＧＷなどのユーザープレーンのゲートウェイを含み得る。
【００６７】
図２Ｆは、図２Ｄに示す中間ノード５のものと同様のサーバー２によりトリガメッセージＴＭ２に含められた接続情報のチェックを行うのが既に第１の中間ネットワークノード６である点で図２Ｅと相違する。例えば、１実施形態では、中間ノード６はＨＳＳを有することができ、そしてこれは、受信したトリガメッセージＴＭ２内のＱｏＳ情報を端末３のための加入情報に基づいて修正し、更新したトリガメッセージＴＭ２′を中間ノード７に伝送することができ、中間ノード７はその後これを端末３に送信する。これは、ＨＳＳ及びＮＡＳシグナリングを介するトリガリングに特に有益である。
【００６８】
図２Ａ−２Ｆに示す種々の実施形態において、接続情報は、タイミング情報を含ませるのと同一のエンティティによりトリガメッセージに含められても良く、そうでなくても良い。例えば、図２Ｂの実施形態では、接続情報は、サーバー２によりトリガメッセージに含められ得るが、一方、タイミング情報は、後に、中間ノード５により付加される。他の例では、図２Ａの実施形態において、タイミング情報をトリガメッセージに含めるのはサーバー２であるが、接続情報をトリガメッセージに付加するのは中間ノード５（図２には示されていない）などの何らかの中間ノードであり得る。
【００６９】
サーバー２及び端末３と同様に、図２Ｂ−２Ｆに示す中間ネットワークノード５，６及び７のそれぞれは、トリガメッセージ及び他のデータを生成して処理するためのプロセッシングユニットと、端末、サーバー又は他のノード及びエンティティと通信するための通信モジュールを含み得る。
【００７０】
図３は、本発明の種々のＭ２Ｍの実施形態に従って、例えば、ＭＴＣ  ＧＷなどのコントロールプレーンのゲートウェイを介して種々のトリガメッセージがどのように端末に伝送されるかの例示的な説明を提供する。図３−８では、「Ｍ２Ｍ装置」の語は、これらの例示的な実施形態が特にＭ２Ｍアプリケーションに適することを指摘するために、本開示の他の部分に記載の端末３を識別するために使用される。
【００７１】
図３に示されるように、ＭＴＣ  ＧＷから先に、多数の潜在的な図２Ａ−２Ｆの実施形態で使用され得るトリガメカニズムが存在する。これらのメカニズムは、図４−８でそれぞれより詳細に説明される移動体着ＳＭＳを用いたトリガリング、ＩＭＳメッセージを用いたトリガリング、セルブロードキャストを用いたトリガリング、ＨＳＳ及びＮＡＳシグナリングを介するトリガリング、及び、Network RequestedＰＤＰコンテキストエスタブリッシュメントを介するトリガリングを含む。
【００７２】
１実施形態では、ＭＴＣ  ＧＷは、例えば、ネットワークからのステータス情報に基づいて、どのトリガリングメカニズムを選択するかを決定するように構成され得る。他の実施形態では、Ｍ２Ｍサーバーは、どのトリガ方法を使用するかの決定ポイントであり得る。これは、Ｍ２Ｍサーバーが、典型的には、特定のアプリケーション、そのアプリケーションに関連するＭ２Ｍ装置、及び、これらの装置がサポートするトリガリングメカニズムの種類についての殆どの知識を有するため、有利であり得る。
【００７３】
図３に示す全てのトリガリングメカニズムにおいて、タイミング情報及び、任意的に、接続情報は、図２Ａ−２Ｆの種々の実施形態に記載のように、トリガメッセージに付加され得る。ここで、図４−８に関連して種々のトリガリングメカニズムを簡単に記載するが、当業者は、図２Ａ−２Ｆの実施形態の場面でこれらのトリガリングメカニズムの１以上を実施できることを理解するであろう。
【００７４】
図４は、Ｍ２Ｍサーバーにより送信されたトリガメッセージがどのようにＭＴＣ  ＧＷによりＳＭＳサービスセンター（ＳＭＳ  ＳＣ）に送付されるかを示す。そこから、手順は、殆ど、３ＧＰＰ  ＴＳ  ２３．０４０に記載される標準的な移動体着ＳＭＳ手順である。主な違いは、通常のＳＭＳ手順では、ＭＳＩＳＤＮがデバイス識別子として使用されることである。Ｍ２Ｍ通信では、ＩＭＳＩ又はＭＳＩＳＤＮリプレースメントが使用されることができ、これは、SendRoutingInfoforSMS手順への変更を示唆する。
【００７５】
ＬＴＥネットワークでは、本来的なＳＭＳサポートは無く、テキストメッセージングは、ＩＭＳインスタントメッセージングを用いて実行される。したがって、ＬＴＥにおいてＳＭＳベースのトリガリングが困難であり得る場合は、他の選択肢は、ＳＩＰメッセージを用いることであり得る。図５は、Ｍ２Ｍ装置をトリガするためにＩＭＳメッセージがどのように使用され得るかを示す。最初に、Ｍ２Ｍ装置は、ＩＭＳメッセージを受信可能になるために、ＩＭＳで登録することが必要である。ＭＴＣ  ＧＷは、ＩＭＳアプリケーションサーバーと見なされ、Ｓ−ＣＳＣＳＦでのＭ２Ｍ装置の登録は、ＭＴＣ  ＧＷに送られる。トリガメッセージがＭＴＣ  ＧＷに受信されると、ＭＴＣ  ＧＷは、ＳＩＰメッセージをＳ−ＣＳＣＦを有するＩＳＣインターフェイスを介してＭ２Ｍ装置に伝送する。
【００７６】
図６は、セルブロードキャストを用いたトリガリングを示す。この解決策の背後にある仮定は、Ｍ２Ｍサーバーは、Ｍ２Ｍ装置が位置するエリアについての情報を有しているということである。エリア付きのトリガリクエストはＭＴＣ  ＧＷに送信され、ＭＴＣ  ＧＷはこれをセルブロードキャストセンター（ＣＢＣ）に送る。ここからは、３ＧＰＰ  ＴＳ  ２３．０４１に記載されるようなセルブロードキャストの標準手順が指示されたエリア内でトリガメッセージをブロードキャストするために使用され得る。Ｍ２Ｍ装置は、ブロードキャストされたメッセージを受信する。最初に、Ｍ２Ｍ装置は、どのブロードキャストメッセージがトリガメッセージかを判断する。トリガメッセージは、ブロードキャストチャネル識別子により、又は、ブロードキャストメッセージの特定のフォーマットを通して識別され得る。Ｍ２Ｍ装置は、任意のトリガメッセージの受信をトリガと解釈してＭ２Ｍサーバーへの接続をセットアップし得る。代替的には、Ｍ２Ｍ装置は、最初に、トリガで送信されたＩＤとＭ２Ｍ装置のＩＤの間の適合（match）があるかを判断し、肯定的な適合の際に、Ｍ２Ｍサーバーへの接続をセットアップする。
【００７７】
トリガメッセージに使用されるＩＤは、任意のアプリケーションレベルの識別子であり得、モバイルネットワークに対して完全にトランスペアレントであり得る。例えば、スマートメータリングのアプリケーションは、電気メーターのシリアル番号を使用し得る。また、トリガメッセージ内のＩＤは、Ｍ２Ｍ装置のグループを識別し得る。これは、一群のＭ２Ｍ装置が例えばソフトウェアアップグレードを行うことをトリガする効率的な方法を許容する。このような場合、本発明で記述されるように、トリガメッセージ内にタイミング情報も含めることは、トリガメッセージへの応答を時間的に拡散させ、過剰に大きいＭ２Ｍ装置のグループが同時にＭ２Ｍサーバーに接続を試みることを軽減又は防止することを可能にし得る。
【００７８】
図７は、既存のノンアクセスストラタム（ＮＡＳ）シグナリングを用いたトリガリングのためのメッセージシーケンスを示す。このコンセプトの背景のアイデアは、トリガメッセージは、これを、Ｍ２Ｍ装置とネットワークの間で交換される既存のシグナリングメッセージに添付することで、ピギーバックされ得るということである。トリガメッセージは、ＭＴＣ  ＧＷを介してＨＳＳに送信される。ＨＳＳは、リクエストを蓄積し、Ｍ２Ｍ装置が接続しているときは、これをInsert Subscriberメッセージ内でＭ２Ｍが登録されたＳＧＳＮ又はＭＭＥに送信する。例えば、周期的なルーティングエリアアップデートのために、Ｍ２Ｍ装置が次にＳＧＳＮ／ＭＭＳにシグナルするときに、ＳＧＳＮ／ＭＭＥは、Ｍ２Ｍ装置に応答してトリガメッセージをピギーバッグする。トリガメッセージがＭ２Ｍ装置により成功裏に受信されたときに、トリガリクエストは、ＳＧＳＮ／ＭＭＥ及びＨＳＳから削除され得る。Ｍ２Ｍ装置が接続していない場合、Ｍ２Ｍ装置が次回再度ネットワークに接続するまで、ＨＳＳは、トリガメッセージを蓄積し得る。
【００７９】
５つのトリガメカニズムの最後は、図８に示される。network requested PDP context activationの手順は、３ＧＰＰ  ＴＳ  ２３．０６０に詳述される。この手順の新しい側面は、ＭＴＣ  ＧＷからＧＧＳＮへの接続要求であろう。既存のnetwork requested PDP context activationの手順は、シグナリングメッセージにより開始されるのではなく、装置のためのＩＰパケットの受信による。どのＳＧＳＮにトリガメッセージが送信されるべきかの決定のためのRoutingInfoは、ＩＭＳＩに基づいてＨＳＳにおいて見出され得る。ＨＳＳにクエリを行うために、ＭＳＩＳＤＮの新しい装置ＩＤリプレースメントを用いることも選択肢であり得る。
【００８０】
本発明の１実施形態は、コンピュータシステムで使用されるプログラム製品として実施され得る。プログラム製品のプログラムは、実施形態（本書に記載の方法を含む）の機能を規定し、種々の、好ましくは、非一時的なコンピュータ可読記憶媒体に含まれ得る。例示的なコンピュータ可読記憶媒体は、（ｉ）情報が永続的に蓄積される書込不可の記憶媒体（例えば、ＣＤ−ＲＯＭドライブにより読み取り可能なＣＤ−ＲＯＭディスク、ＲＯＭチップ又は任意のタイプのソリッドステート不揮発性半導体メモリなどのコンピュータ内のリードオンリーメモリー装置）、及び、（ｉｉ）変更可能な情報が蓄積される書込可能記憶媒体（例えば、ディスクドライブ内のフロッピーディスク又はハードディスクドライブ又は任意のタイプのソリッドステートランダムアクセス半導体メモリー、フラッシュメモリー）を含むが、これらには限定されない。コンピュータプログラムは、本書に記載のプロセッシングユニット上で作動され得る。
【００８１】
追加の実施形態が以下に記載される。
時間インジケータを用いたトリガリングは、装置が通常、スタンバイモードにあるときにそれらの装置との通信を可能にする可能性を提供し、これは、バッテリー寿命の節約の利益を提供する。例えば、バッテリー寿命を節約するために、モバイルクライアントは一日の大半が停止モードであり、モバイルクライアントが同報チャネルに接続する（例えば、毎晩３：００など）ある瞬間にのみ起動し得る。場合により、上記のように、これらの「起動時間」の間だけでなく、これらの固定のタイムスロット外でも、これらの装置と通信できることが有用で有利であり得る。この一例は、サーバーが、例えば、１６：００にそのときの装置のステータスをチェックするために装置と通信するようにスケジュールされているかどうかである。このシナリオを可能にするため、装置の定期的にスケジュールされた起動時間の間にトリガが装置に送信され得る。このトリガに含まれるものは、サーバーとの通信を可能にするために、装置に、翌日の１６：００に起動してデータ接続をセットアップするように指示する時間インジケータであろう。この実施形態の利点は、これにより、装置が一日の大半の間電源切断モードであることを可能にし、それにより、サーバーにより要求される任意の期間においてその装置との通信が可能である柔軟性を維持しつつ、バッテリー寿命を節約し、それにより、メインテナンスの柔軟性を可能にすることである。
【００８２】
トリガリングはそれ自体ネットワーク資源を使用するが、トリガリングは、コスト低減のために使用され得る。一日の時間に応じて、モバイルクライアントのトリガリングは、他の時間よりも高価であり得る。例えば、多くのネットワークトラフィックのあるワーキング時間帯の間にモバイルクライアントをトリガリングすることは、同じモバイルクライアントをネットワーク負荷の小さい夜の間にトリガリングするよりも、より高価であり得る。しかし、場合により、例えば、午後の正確に１２：００に温度を読み取るなどのために、ある、又は、正確な時点でモバイルクライアントにデータ接続をセットアップさせることが必要であり得る。この場合、トリガメッセージに時間インジケータを含めることは、コスト効率的な解決策であり得る。上記の例では、サーバーは、オフピークの低コストな夜の時間の間にトリガメッセージを送信し得るが、トリガを送るには高価であり得る午後の１２：００にデータ接続をセットアップすることをモバイルクライアントに通知する時間インジケータを含め得る。トリガと結果としてのデータ接続を分けることでコストが低減され、これは、モバイル装置にトリガを送信するよりコスト効率的な方法を可能にする。
【００８３】
追加の実施形態：許可ウィンドウ外での通信
場合により、モバイルクライアントは、特定のタイムスロット（「アクセス許可時間ウィンドウ」）の間だけ、ネットワークに接続することを許可され得る。これらのタイムスロット外では、モバイルクライアントは、ネットワークに接続を試みると直ちに拒絶される。この方法の１つの欠点は、場合により、サーバ側の視点で見ると、この特定のタイムスロット外に装置と通信することを望むことが有用であり得ることである。換言すれば、場合により、ネットワークは、ネットワークにより装置に与えられたアクセス許可時間ウィンドウに違反することを装置に要求することを望み得る。しかし、所与の期間の間、ネットワークに接続することが許可されていないことを装置が知っているのなら、装置が移動電話無線のスイッチを入れることは道理にかなわないので、ネットワークがモバイルクライアントに、ネットワークに接続するために、ある瞬間にそのアクセス許可時間ウィンドウに違反する要求を通知することはできない。この場合、時間インジケータを有するトリガは、モバイルクライアントがネットワークに接続している時間帯（アクセス許可時間ウィンドウ）の間にモバイルクライアントに送信され得る。このトリガに含まれるものは、モバイルクライアントのアクセス許可時間ウィンドウ外の時間を含む時間インジケータであり得、従って、装置に、ネットワークに接続するために、その時点で、そのアクセス許可時間ウィンドウに違反して良いことを通知し得る。
【図１】
0005871733.tif 000002
【図２Ａ】
0005871733.tif 000003
【図２Ｂ】
0005871733.tif 000004
【図２Ｃ】
0005871733.tif 000005
【図２Ｄ】
0005871733.tif 000006
【図２Ｅ】
0005871733.tif 000007
【図２Ｆ】
0005871733.tif 000008
【図３】
0005871733.tif 000009
【図６】
0005871733.tif 000010
【図４】
0005871733.tif 000011
【図５】
0005871733.tif 000012
【図７】
0005871733.tif 000013
【図８】
0005871733.tif 000014