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