時間インジケータを用いたトリガリング
【課題】端末とサーバーの間で通信パスを確立するために少なくとも1つの端末をトリガする方法及びシステムを提供する。
【解決手段】端末にトリガメッセージを伝送するステップを含み、トリガメッセージは、端末とサーバーの間の通信パスがいつ確立されるべきかを示すタイミング情報を含む。タイミング情報は、時間遅延、時間ウィンドウ又は端末とサーバーの間の通信パスを確立する時間をランダムに選択する指示の1以上を含み得る。
【解決手段】端末にトリガメッセージを伝送するステップを含み、トリガメッセージは、端末とサーバーの間の通信パスがいつ確立されるべきかを示すタイミング情報を含む。タイミング情報は、時間遅延、時間ウィンドウ又は端末とサーバーの間の通信パスを確立する時間をランダムに選択する指示の1以上を含み得る。
【発明の詳細な説明】
【技術分野】
【0001】
一般に、本発明は、データ通信の分野に関する。より詳細には、本発明は、例えば、マシンツーマシン(M2M)通信など、端末とアプリケーションサーバーの間のデータ通信の分野に関する。
【背景技術】
【0002】
既存のデータ伝送環境では、装置(「端末」とも呼ばれる)は、ときに、ネットワーク上でデータをサーバーに伝送することが必要とされ、その逆もそうである。固定又はモバイルネットワークでのデータ接続の確立は、一般に、デバイス指向である。例えば、GSM及びUMTSネットワークでのデータ接続の1つのタイプを表すPacket Data Protocol(PDP)コンテキストは、ユーザー端末によりセットアップされる。また、ファイアウォールやネットワークアドレス変換装置のような、殆どのIPミドルボックスは、装置によるデータセッションの開始に依存する。
【0003】
このような装置は、現在3GPP(例えば、TS22.368参照)で標準化されているマシンツーマシン(M2M)通信の分野に適用され得る。多くのM2Mアプリケーションでは、M2M装置がM2M装置とM2Mサーバーの間の通信パスを確立することで十分であるが、M2Mサーバーがデータ接続を開始できることが要求されるアプリケーションもある。
【0004】
M2Mサーバーが装置との通信を開始する例は、スマート電気メータリングアプリケーションである。通常、メーターは、各月末のメーターの読みを報告し得る。しかし、例えば、顧客が異なる電気プロバイダに変えた場合は、M2Mサーバーは、特定の契約終了日のメーターの読みを要求するようにメーターをトリガできることが必要である。
【0005】
サーバー側から接続をセットアップするには、サーバーは、装置に、その装置が接続をセットアップすべきであることを通知する必要がある。このプロセスは、トリガリングと呼ばれる。トリガリングには異なる方法があり、これらは全て、場合によっては、装置がセットアップしなければならないデータ接続のためのサーバーのアドレスが端末に事前設定されていなければ、そのサーバーのアドレス(例えば、APN,IPアドレス又はFQDN)を示しつつ、トリガが、サーバーへの接続をセットアップすることの要求を端末に単に提供するという事実を共通して有する。
【発明の概要】
【発明が解決しようとする課題】
【0006】
端末とサーバーの間のサーバー開始型の通信パスを確立するための改善された方法及びシステムを提供することが本発明の目的である。
【課題を解決するための手段】
【0007】
この目的のため、端末とサーバーの間の通信パスを確立するように少なくとも1つの端末をトリガする方法が開示される。この方法は、端末にトリガメッセージを伝送するステップを有し、トリガメッセージは、少なくとも1つの端末とサーバーの間の通信パスがいつ確立されるべきかを示すタイミング情報を含む。
【0008】
本発明は、これまで、端末がいつサーバーへの通信パスをセットアップすべきかのタイミングにサーバーが影響を有していなかったという認識に基づいている。一旦サーバーがトリガメッセージを端末に伝送すると、接続がいつセットアップされるかの決定は端末に委ねられていた。このような構成は、一群の端末がすべて同時にトリガされるときに特に問題となり得る。各端末は、典型的には、他の端末が何をしているかにつての情報を有さないため、同時にトリガされた全ての端末がサーバーへの接続のセットアップを同時に開始し、そのため、システムの処理及び通信資源に過剰の負荷を課すという状況を生じ得た。本発明は、端末がいつサーバーへの接続を確立すべきかを指定するタイミング情報を端末に提供するトリガメッセージに含めることにより、この状況を軽減又は回避することを助ける。端末にこのようなタイミング情報を提供することで、端末は、接続がいつセットアップされるかについての少なくともある程度のコントロールをサーバーと共有することが可能になる。その結果、サーバーは、トリガメッセージに応答して異なる端末がいつそれらの接続をセットアップするかを管理することが可能となる。サーバーは、典型的には、システム内で何が生じているかのより広い概観(全体像)を有する(例えば、サーバーは、いつ、いくつの端末がトリガされたか、及び、システムで他に何が生じているかについての概観を有する)ため、このようなシステム内の異なる端末の集中化された管理は、システムをより効率的にする。トリガメッセージにタイミング情報を挿入することにより、サーバーは、個々の端末がそれらの接続をセットアップするタイミングを制御するために、サーバーの知識を利用することが可能である。例えば、多数の端末が同時にトリガされた場合、サーバーは、個々の端末の接続のセットアップの発生を時間的に拡散させることができる。
【0009】
集中化された管理は、システム内の異なる端末間の競合の可能性も低下させる。
【0010】
代替的に、上記の機能は、サーバー内で実施されず、何らかの中間ネットワークノード(例えば、ネットワークゲートウェイ)内で実施され得る。専ら端末により決定されるというよりはむしろ、システムのより広い概観を有する何らかのエンティティにより端末とサーバーの間の通信パスがいつ確立されるべきかについてのタイミング情報が端末に提供される限り、全体的なシステムが利益を受ける。
【0011】
本書で使用されるところの、サーバーへの通信パスをセットアップする端末の文脈における「通信パス」の語は、端末とサーバーの間でデータ(典型的には、ユーザーデータ)を通信するためのパス又はチャネルを意味し、その少なくとも一部は、典型的には、端末とネットワークゲートウェイなどの何らかの中間ネットワークノードの間の少なくとも1つのデータ接続を含み、それの上で、端末とネットワークゲートウェイは、PDPコンテキスト又は3GPP TS 23.060に記載のUMTSベアラ又は3GPP TS 23.401に記載のEPSベアラなどの1以上のプロトコルに従ってデータを交換することができる。当業者は、「ネットワークゲートウェイ」の語が、インターネット又はコーポレートパケットデータネットワークなどの外部パケットネットワークとモバイルネットワークの間のゲートウェイとして機能するように適合された中間ネットワークノードを意味することを認識する。既存のGPRS/UMTSネットワークでは、ゲートウェイGPRSサポートノード(GGSN)は、ネットワークゲートウェイとして動作し、一方、LTEネットワークでは、PDNゲートウェイ(P−GW)ノードは、ネットワークゲートウェイである。
【0012】
M2M通信は典型的にはサーバーとの通信パスをセットアップすることを要し得る幾百、幾千又は幾百万の端末を含むため、開示された解決策は、この分野に限定されないが、M2M通信に特に有利である。単一の端末が1以上のサーバーと通信し得るため、端末の数とこれらの端末が接続をセットアップし得るサーバーの数の関係は常にN:1ではないが、典型的には、端末の数は、なおサーバーの数よりも顕著に大きい。その結果、任意の単一のサーバーは、種々の端末がいつこのサーバーとの通信パスをセットアップするかについてのタイミングのコントロールを有することで利益を受けるであろう。
【0013】
M2M通信の一例は、サーバーにより、例えば、大規模顧客基盤の家庭におけるスマート電気メーターから情報を収集することを含む。他の例は、様々なタイプのサーバーへの先進データ接続をサポートし得る通信モジュールを装備し得る監視システム、センサー等を含む。また、モバイルナビゲーション端末及び支払い端末は、M2Mアプリケーションの例である。提示した解決策は、このようなアプリケーションのための端末とサーバーの間の通信パスの確立の効率的なサーバーベースの開始を提供する。
【0014】
種々の実施形態において、トリガメッセージに含まれるタイミング情報は、時間遅延、時間ウィンドウ、及び、端末が端末とサーバーの間の通信パスを確立するための時間をランダムに選択するための指示の1以上を含み得る。通信パスがいつ確立されるべきかの時点を示し得る情報の他の例も考えられ、本発明の範囲内である。
【0015】
1実施形態では、トリガメッセージは、例えば、グループアドレッシングを用い、又は、トリガメッセージを複数の基地局上で同報することで、これらの基地局のカバレッジエリア内に位置する複数の端末に伝送され得る。
【0016】
上記のように、端末とサーバーの間で確立される通信パスは、例えば、端末とネットワークゲートウェイの間の、端末とサーバーの間でどのタイプの通信が必要かに応じて、パラメータの組に従ってセットアップされた少なくとも1つのデータ接続を含み得る。1実施形態では、トリガメッセージは、このような端末とサーバーの間の通信パスにおける第1のタイプのデータ接続を示す接続情報を更に含み得る。
【0017】
当業界で「QoSパラメータ」又は「QoSプロファイル」と通常呼ばれるパラメータの組は、例えば、最大ビットレート、保証ビットレート、アロケーションセットアップ、タイムアウトリミット及びキュー設定などのパラメータを含む。データ接続のタイプの幾つかの例は、ベストエフォート接続、会話式接続、又は、ストリーミング接続を含む。異なるタイプのデータ接続には、異なるQoSパラメータの組が必要である。例えば、会話式データ接続は、音声通信を可能にするために、遅延やジッターに関する厳しい条件を有し得るが、ストリーミング接続では、遅延はさほど重要でない場合がある。
【0018】
このように、端末とネットワークゲートウェイの間のデータ接続は、端末とゲートウェイの間でセットアップされた「トンネル」と見ることができる。そして、サーバー(又はトンネル外、すなわち、外部データパケットネットワークの他のエンティティ)が端末にIPパケットを送信することが必要なときは、サーバーは、ネットワークゲートウェイにルーティングされたIPアドレスを使用するであろう。そこから、IPパケットは、データ接続を介して端末に「トンネリング」される。逆に、IPパケットを端末から外部ネットワークのエンティティにルーティングするときは、IPパケットは、トンネルにおける中間ノードのIPアドレスを知る必要無しに、データ接続を介して端末からネットワークゲートウェイに「トンネリング」される。端末とサーバーの間の全体的な通信パスは、1以上のこのような「トンネル」を含み得る。そして、ネットワークゲートウェイとサーバーの間で、パケットデータネットワークの従来のIPルーティングが使用され得る。
【0019】
勿論、全体の通信パスがデータ接続のタイプを規定する何らかのパラメータの組に従ってセットアップされることを要し得る(すなわち、請求項1に規定の「少なくとも1つのデータ接続」が実際に端末とサーバーの間の全体の通信パスである)という点において、端末とサーバーの間の全体の通信パスが「トンネル」であり得る実施形態も可能である。また、例えば、端末からネットワークゲートウェイへの1つのトンネルとゲートウェイからサーバーへの他のトンネルなど、トンネルの連結が存在する実施形態も可能である。このような実施形態では、両トンネルのQoSパラメータが同一のQoSの指示から抽出されても良く、又は、異なるQoSの指示が存在しても良い。特定の1実施態様では、ネットワークゲートウェイとサーバーの間のトンネル(及び関連するQoSパラメータ)は、トリガメッセージにおけるこのトンネルのタイプの指示を提供することでは必ずしもセットアップされない。このような全ての実施形態は本発明の範囲に含まれ、どのようなパラメータの組(すなわち、必ずしも上記のQoSパラメータではない)がこのようなデータ接続のタイプを指定するのに最も適切であるかを当業者が認識するであろうことが理解される。
【0020】
端末がどのタイプの接続を確立すべきかについての情報を、トリガメッセージ内で、すなわち、端末がこのデータ接続を含む通信パスをセットアップする前に、端末に提供することで、端末が誤ったタイプのデータ接続をセットアップすることが回避され、サーバーと端末の間で交換されるメッセージの数を顕著に減少させることが可能になる。その結果、システムの処理資源が保全され、非効率な帯域幅使用が減少され得る。
【0021】
サーバーが、端末がどのタイプのデータ接続をセットアップするかに影響することを許容することは、技術及び種々のアプリケーションが発展するにつれてますます重要になるだろう。(そこでは、潜在的にはより多様なタイプのデータ接続が端末により要求され、サポートされるであろう。)例えば、ビデオ監視のアプリケーションは、ビデオストリームに適切なQoSを有するベアラを必要とするであろう。
【0022】
種々の実施形態において、接続情報は、例えば、QoSプロファイル又はQoS Class Identifier(QCI)の一部又は全部を含み得る。QCIは、データ接続をセットアップするためにどのQoSパラメータの組を使用すべきかを示す数字の形態であり得る。例えば、1に等しいQCIは、会話式のタイプのデータ接続に必要な全てのQoSパラメータを意味し得る。QCIを用いる利点は、これがQoSプロファイルよりもずっと小さく、したがって、トリガメッセージ内で移送することがずっと容易であることである。QCIは、トリガメッセージが同報チャネル上で送信されるアプリケーションに特に有利である。勿論、接続のタイプを示し得る情報(例えば、要求されたデータ接続のQoSパラメータの範囲又は回路交換接続又はパケット交換接続が使用されるかなど)の他の例も考えられ、本発明の範囲内である。
【0023】
他の実施形態では、上記方法に使用するサーバー及び端末も開示される。
【0024】
更に、上記方法において及び/又は上記端末と共に使用されるように構成された中間ネットワークノードが開示される。このような中間ネットワークノードは、直接又は他の中間ノードを介して端末及びサーバーに通信的に接続され、サーバーで生成されたトリガメッセージは、ノードにより端末に伝送される前に中間ネットワークノードに送信され得る。このような中間ネットワークノードは、例えば、上記のGGSN又はP−GWノードなど、端末とサーバーの間でユーザーデータを通信するネットワークゲートウェイであり得、又は、後で詳述するマシンタイプの通信ゲートウェイ(MTC GW)など、制御データを通信するためのネットワークゲートウェイであり得る。
【0025】
サーバーがトリガメッセージに接続情報を含めるように構成されている実施形態では、中間ネットワークノードは、第1のタイプのデータ接続が端末によりサポートされ、及び/又は、端末のために許可されているかを判断するように構成され得る。肯定的な判断のときに、中間ネットワークノードは、トリガメッセージを更に端末に伝送するように構成され得る。否定的な判断のときに、中間ネットワークノードは、第1のタイプのデータ接続を示す情報を第2のタイプのデータ接続を示す情報で置き換えることでトリガメッセージを更新するように構成され得る。代替的に、否定的な判断のときに、中間ネットワークノードは、場合によってそのことをサーバーに通知しつつ、端末へのトリガメッセージの伝送を停止するように構成され得る。このような機能は、端末に提供されるトリガメッセージが、例えば、端末の加入条件に従って、実際に端末によりサポートされ、及び/又は、これのために許可されたタイプのデータ接続のみについての要求を含むことを確実にする。
【0026】
サーバーが、本発明に従ってタイミング情報を含めずにトリガメッセージを送信するように構成されたサーバーであり得る実施形態では、中間ネットワークノードは、本書に記載の方法を、サーバーから受信したトリガメッセージにタイミング情報及び、任意的に、接続情報を付加することで実施するように構成され得る。これは、有益であり得、その理由は、中間ネットワークノードが、例えば、端末の加入条件に従えば、いつデータ接続が確立されるべきであり、及び/又は、どのタイプのデータ接続が端末によりサポートされ、及び、端末のために許可されているかについての情報を有するエンティティであり得るためである。
【0027】
種々の実施形態において、1以上の中間ネットワークノードがトリガメッセージを伝送するために使用され得る。例えば、1実施形態では、トリガメッセージが最初にサーバーから、例えば、コントロールプレーンのゲートウェイなどの第1の中間ネットワークノードに伝送され、その後、端末に伝送される前に、第1の中間ネットワークノードから例えば、ユーザープレーンのゲートウェイなどの第2の中間ネットワークノードに伝送され得る。このような実施形態は、トリガメッセージを伝送するために先に確立されたデータ接続が使用し得る場合に有利であり得る。さらに、これは、後続のデータ接続のセットアップに携わるエンティティ(例えば、SGSN、S−GW、MME、GGSN、P−GW)がトリガメッセージ内の情報に基づいて、それまでに準備することを可能にし得る。
【0028】
また、本開示は、本書に記載の種々の機能を実施する(場合により分散した)部分を有するコンピュータプログラム、そのようなソフトウェア部分のためのデータキャリア、及び、上記のようなサーバー及び端末を少なくとも有する通信システムに関する。
【0029】
以下、本発明の実施形態がより詳細に説明される。しかし、これらの実施形態は、本発明の保護の範囲を制限するものと解釈してはならないことが理解されるべきである。
【図面の簡単な説明】
【0030】
【図1】端末をアプリケーションサーバーに接続する4G通信ネットワークの概略図。
【図2A】本発明の種々の実施形態に従ってサーバーと端末の間の通信パスを確立するためのトリガメッセージの提供の概略図。
【図2B】本発明の種々の実施形態に従ってサーバーと端末の間の通信パスを確立するためのトリガメッセージの提供の概略図。
【図2C】本発明の種々の実施形態に従ってサーバーと端末の間の通信パスを確立するためのトリガメッセージの提供の概略図。
【図2D】本発明の種々の実施形態に従ってサーバーと端末の間の通信パスを確立するためのトリガメッセージの提供の概略図。
【図2E】本発明の種々の実施形態に従ってサーバーと端末の間の通信パスを確立するためのトリガメッセージの提供の概略図。
【図2F】本発明の種々の実施形態に従ってサーバーと端末の間の通信パスを確立するためのトリガメッセージの提供の概略図。
【図3】本発明の実施形態に従って、種々のトリガメッセージがどのようにコントロールプレーンのゲートウェイを介して端末に伝送され得るかの例示的な説明を提供する。
【図4】本発明の実施形態を実施するために適する種々のトリガリングメカニズムの概略図を提供する。
【図5】本発明の実施形態を実施するために適する種々のトリガリングメカニズムの概略図を提供する。
【図6】本発明の実施形態を実施するために適する種々のトリガリングメカニズムの概略図を提供する。
【図7】本発明の実施形態を実施するために適する種々のトリガリングメカニズムの概略図を提供する。
【図8】本発明の実施形態を実施するために適する種々のトリガリングメカニズムの概略図を提供する。
【発明を実施するための形態】
【0031】
図1は、通信ネットワーク1の概略図を示す。通信ネットワーク1は、サーバー2と端末3の間のデータネットワーク4上でのデータセッションを許容し、端末の通信ネットワーク1へのアクセスはワイヤレスである。
【0032】
図1の通信ネットワークでは、3つの世代の通信ネットワークが簡略の目的もあって概略的に示されている。構成及び概観のより詳細な説明は、その全体が参照により本願に含められる3GPP TS 23.002に見られる。
【0033】
図1の下方の分岐は、GGSN、サービング・GPRS・サポート・ノード(SGSN)及び無線アクセスネットワーク(RAN)を有するGPRS又はUMTS通信ネットワークを示す。GSM/EDGE無線アクセスネットワーク(GERAN)については、RANは、いずれも図示されない、複数の基地局送受信機(BTS)に接続された基地局制御装置(BSC)を有する。UMTS無線アクセスネットワーク(UTRAN)については、RANは、同様に図示されない、複数のNodeBに接続された無線ネットワーク制御装置(RNC)を有する。GGSN及びSGSNは、一般には、端末3の加入情報を含むホームロケーションレジスタ(HLR)に接続される。図では、HLRは、ネットワークに端末3を認証する認証センター(AuC)と組み合わされている。
【0034】
図1の上方の分岐は、通常、Long Term Evolution(LTE)又はEvolved Packet System(EPS)と表される次世代通信ネットワークを示す。このようなネットワークは、P−GW及びServing Gateway(S−GW)を有する。LTEネットワークのE−UTRANは、パケットネットワークを介してS−GWに接続された端末3にワイヤレスアクセスを提供するevolved NodeB(eNodeB又はeNB)を有する。S−GWは、シグナリングの目的で、Home Subscriber Server(HSS)及びMobility Management Entity(MME)に接続される。HSSは、加入プロファイルリポジトリ及び認証センター(AuC)を含む。LTEネットワークの一般的な構成についての更なる情報は、3GPP TS 23.401に見出し得る。
【0035】
GPRS及びUMTSネットワークのGGSNノード及びLTEネットワークのP−GWノードは、例えば、QoSポリシーエンフォーシング、使用メータリング及びIPアドレス割当などの機能を提供する外部データネットワーク4とモバイルネットワークの間のユーザープレーンのゲートウェイとして動作する。図1の全てのネットワークは、任意的に、現在標準化されている、例えば、MTC GWなどのコントロールプレーンのゲートウェイも含み得る。コントロールプレーンのゲートウェイは、サーバーからの制御メッセージのためのモバイルネットワークにおけるエントリーポイントとして動作するように意図される。コントロールプレーンのゲートウェイの目的は、典型的には、許可されていない制御メッセージ、又は、許可されていないサーバーから送信された制御メッセージからネットワークを保護することである。コントロールプレーンのゲートウェイは、サーバーが1つのネットワーク運用者とのみ通信する場合に、サーバー中に事前規定され得る。さもなければ、サーバーは、本発明に記述されるトリガメッセージなどの制御メッセージをどの運用者に送信する必要があるかを最初に決定することが必要である。装置ID、グループID又はIMSIに基づいて、サーバーは、正しいモバイル運用者ネットワークを見つけることができるべきである。
【0036】
勿論、ユーザープレーンのゲートウェイ及びコントロールプレーンのゲートウェイの機能は、単一のノードに結合し、又は、図1で示されるよりも多数のノードに分散し得る。
【0037】
図2A−2Fは、本発明の種々の実施形態に従ってサーバーと端末の間のデータ接続を確立するためのトリガメッセージの提供の概略図である。明確化ため、トリガメッセージの伝送の関連ステップのみが図2A−2Fに示されている。他の手順、例えば、認証、実際のデータ接続のセットアップ及びユーザーデータの交換に関連する手順は、含まれていない。
【0038】
図2Aに示すように、1実施形態では、サーバー2は、トリガメッセージTM1を生成してこれを直接端末3に伝送するように構成され得る。そのため、サーバー2は、トリガメッセージを生成するプロセッシングユニットと、トリガメッセージを伝送する通信モジュールを含み得る。
【0039】
トリガメッセージを端末に直接伝送するサーバーの文脈では、「直接」の語は、図2Aの実施形態を、サーバー2で生成されたトリガメッセージが1以上の中間ネットワークノードを介して伝送され、及び、場合によっては、更にこれらにより処理される図2B−2Fの実施形態と区別するためにのみ使用される。このように、図2Aに示す実施形態では、トリガメッセージは、例えば、セルブロードキャストセンター(CBC)又はSMSサービスセンター(SMS−SC)など、図2B−2Fに記載の中間ノード以外のエンティティを介して端末3に伝送され得る。
【0040】
トリガメッセージTM1は、端末3がサーバー2との通信パスを確立すべき時点を指定する少なくともタイミング情報を含むことにより形成される。通信パスの少なくとも一部は、少なくとも1つの特定のタイプのデータ接続を含むため、タイミング情報は、端末3がいつデータ接続のセットアップを開始すべきかを指定する。タイミング情報を有するトリガメッセージの受信に応答して、端末3は、タイミング情報に基づいて端末3が決定する時点まで、通信パス/データ接続の確立を遅延させる。
【0041】
1実施形態では、タイミング情報は、例えば、端末3に(例えば、トリガメッセージの受信の時点から又はトリガメッセージがサーバー2からいつ送信されたかを示すタイムスタンプから測定して)1時間だけ通信パス/データ接続の確立を遅延させるように指示する遅延時間の形態で、トリガメッセージに含まれ得る。例えば、タイミング情報は、75秒の遅延後に、又は、13分15秒の遅延後に通信パスを確立するように端末3を指示し得る(すなわち、タイミング情報は、遅延を数秒まで正確に指定し得る)。
【0042】
タイミング情報はまた、07:35:35に(すなわち、特定の時点に)通信パス確立するように端末3を指示し得る。
【0043】
他の実施形態では、タイミング情報は、例えば、16:00と17:00の間、又は、より短い時間ウィンドウである03:45:15と03:45:45の間に通信パス/データ接続を確立するように端末3を指示するなど、時間ウィンドウの形態であり得る。
【0044】
更に他の実施形態では、タイミング情報は、通信パス/データ接続を確立する時点をランダムに選択するように端末3を指示し得る。この実施形態は、例えば、グループアドレッシングを用いて、トリガメッセージが一群の端末に送信され、各端末がトリガメッセージに応答する時点をランダム化する状況で特に有益であり得る。
【0045】
上記のタイミング情報の可能なタイプの1以上の例示的な説明は相互に組み合わされ得る。例えば、通信パス/データ接続を確立する時点をランダムに選択するように端末3を指示するタイミング情報の実施形態は、例えば、タイミング情報が、通信パス/データ接続を確立するために特定の時間ウィンドウの何らかのランダムな時点(例えば、02:00と04:00の間のランダムな時点)を選択するように端末3を指示し得るように、遅延時間又はウィンドウ時間の提供と組み合わされ得る。他の例では、タイミング情報は、今と1時間の間で通信パスを確立するための時点をランダム化するように端末3を指示し得る。代替的には、時間遅延及び時間ウィンドウの両方を提供するタイミング情報が可能であり、この場合、タイミング情報は、期間とともに遅延を示し、例えば、1時間の時間ウィンドウの間で15分の遅延の後に通信パスを確立するように端末3を指示する。このような実施形態は、絶対的な時間の指示の提供と異なり、時間遅延及び時間ウィンドウ情報の提供に全ての関連するノードの間での(場合によっては、タイムゾーンやサマータイムも考慮した)同期を必要としないため、有益であり得る。更に他の例では、タイミング情報は、例えば、今から15分後から今から30分後までに通信パスを確立するように端末を指示する2つの遅延を含み得る。
【0046】
タイミング情報は、(1つの)トリガが一群の端末に送信されるときにネットワーク負荷を拡散させる(すなわち、端末がそれらの負荷をランダム化する)、及び/又は、(複数の)トリガが個々の端末に送信されるときにネットワーク負荷を拡散させる(すなわち、サーバーが端末の負荷をランダム化する)ために使用され得る。
【0047】
更に、トリガメッセージ内のタイミング情報は、例えば、データの記録を開始し、4日後にデータを送信し、又は、7月1日13:00と7月4日15:00の間にデータを記録し、その後データを送信するなど、端末3がそのデータのサーバー2への送信を開始する前に何かを行うように端末3を指示し得る。
【0048】
上記例が示すように、タイミング情報は、数秒から数日の時間に関連し得る。どの時点で端末3が通信パス/データ接続を確立すべきであり、又は、すべきでないかを示す他のタイプのタイミング情報も考えることができ、本発明の範囲内であることが意図される。
【0049】
トリガメッセージTM1は、リクエストをその承認と関連づけ、アプリケーションがリクエストをキャンセルすることを可能にするために、端末3の識別、アプリケーションの識別及び/又は重複したリクエストを検出することを可能にするためのこのリクエストに関連するリクエストカウンターなど、従来のトリガメッセージに典型的に含まれていた情報をも含み得る。トリガメッセージTM1は、また、任意的に、IPアドレス(または完全修飾ドメイン名)及び/又は端末がデータ接続を確立することをトリガされるアプリケーションサーバー2のポート番号、緊急リクエストの指示、端末に(例えばSMSで)接続できないときにネットワークに蓄積されたトリガの除去を許可する有効タイマー、トリガリングを送信すべきエリア、及び/又は、(例えば、サーバー2との通信パスを確立する前に端末3に何かをすることを指示するための)限定された程度の用途特定情報を含み得る。
【0050】
トリガメッセージTM1を受信すると、端末3は、メッセージからタイミング情報を取得し、その後、取得したタイミング情報に基づいて、どの時点でサーバー2との通信パスが確立されるべきかを判断し、最後に、その決定した時点に通信パスを確立するように構成さる。そのため、端末3は、トリガメッセージからタイミング情報を抽出し、通信パスがいつ確立されるべきかを決定できるプロセッシングユニットと、要求された通信パスを確立するための通信モジュールを含み得る。端末3のプロセッシングユニット及び/又は通信モジュールの機能の少なくとも一部は、端末3内の(U)SIM内に含まれ得る。
【0051】
図2B及び2Cは、図2B及び2Cでは、サーバー2がトリガメッセージ内にタイミング情報を含まない点で図2Aと異なる。その代わり、端末3に伝送されるトリガメッセージにタイミング情報を含めるのが何らかの中間ネットワークノードである。
【0052】
図2Bでは、サーバー2は、例えば、上記のGGSN、P−GWまたはMTC−GWなどの中間ネットワークノード5にトリガメッセージTM0を伝送する。中間ノード5は、直接又は他の中間ノードを介してサーバー2に通信的に接続され、中間ノード5は、サーバー2から(外部ネットワーク4上で)トリガメッセージを受信し得る。中間ノード5は、また、直接又は他の中間ノードを介して端末3に通信的に接続され、中間ノード5は、更に端末3にモバイルネットワーク上でトリガメッセージを伝送し得る。
【0053】
図2Bに示される実施形態では、中間ノード5は、サーバー2からタイミング情報を含まないトリガメッセージTM0(すなわち、トリガメッセージTM0は、従来のトリガメッセージであり得る)を受信する。中間ノード5は、その後、トリガメッセージにタイミング情報を付加し、これにより、新たなトリガメッセージTM1を生成し、そして、タイミング情報を有するトリガメッセージTM1を端末3に伝送するように構成される。トリガメッセージTM1及び端末3に関する上記の議論は、ここでも適用可能であり、したがって、繰り返さない。
【0054】
図2Cは、2つの中間ノードである第1の中間ノード6及び第2の中間ノード7が使用される点で図2Bと相違する。第1の中間ノード6は、直接又は他の中間ノードを介してサーバー2に通信的に接続し、中間ノード6は、トリガメッセージをサーバー2から受信し得る。第1の中間ノード6は、また、直接又は他の中間ノードを介して中間ノード7に通信的に接続され、中間ノード6は、トリガメッセージを更にノード7に伝送し得る。中間ノード7は、同様に直接又は他の中間ノードを介して端末3に通信的に接続し、中間ノード7は、今度は、トリガメッセージを端末3に更に伝送し得る。
【0055】
図2Cに示す実施形態では、第1の中間ノード6又は第2の中間ノード7のどちらかは、図2Bに示す中間ノード5が行うのと同様にして、トリガメッセージにタイミング情報を含ませることができる。
【0056】
図2A−2Cの全ての実施形態において、トリガメッセージは、サーバー2と端末3の間の通信パスを確立する端末3の一部として、サーバー2が端末3にセットアップさせることを要する少なくとも1つのデータ接続のタイプを指定する接続情報を更に含み得る。接続情報は、例えば、完全又は部分的なQoSプロファイル、QCI又は特定のタイプのデータ接続を適切に識別できる何らかの他の情報を含み得る。通信パス内の要求されたタイプのデータ接続を示す情報を、トリガメッセージにその情報を含めることにより、データ接続/通信パスがセットアップされる前に提供することで、当業界で現在なされているように、誤ったタイプの接続をセットアップし、その後、それを修正しなければならないことによりシステム資源の浪費をしなければならないことの防止を可能にする。
【0057】
このような実施形態では、タイミング情報だけでなく、接続情報も含むトリガメッセージを受信すると、端末3は、メッセージから接続情報を取得し、サーバー2への通信パスを確立するように構成され、通信パスは、メッセージで指定されるタイプのデータ接続を含む。
【0058】
図2D−2Fは、トリガメッセージが、タイミング情報に加えて、端末によりサポートされ、端末のために許可された通信パス内のデータ接続のタイプを指定する接続情報を含むときに、1以上の中間ノードが、端末へのトリガメッセージの提供に際してサーバー2をどのようにさらに補助するかを示す。
【0059】
図2Dは、図2Bに示す中間ネットワークノード5と同様、例えば、GGSN、P−GW又はMTC GWなどの中間ネットワークノード5がサーバー2と端末3の間の通信パスに含まれ得ることを示す。
【0060】
中間ノード5は、上記のように、サーバーからタイミング情報だけでなく接続情報も含むトリガメッセージTM2を受信する。
【0061】
中間ノード5は、その後、受信したトリガメッセージTM2から接続情報を抽出し、その接続情報により識別される特定のQoSプロファイルが端末3によりサポートされ、及び/又は、端末3の加入条件で許容されているかをチェックするように構成され得る。これは、例えば、加入者情報を含むHSSでのチェックにより行われ得る。
【0062】
中間ノード5がTM2で識別されるタイプの接続が端末3によりサポートされ、そのために許容されていると判断した場合には、中間ノード5は、トリガメッセージTM2を更に端末3に伝送し得る。他の場合は、中間ノード5は、端末3へのトリガメッセージの伝送を停止する(場合によっては、トリガメッセージTM2の伝送が中断されたことをサーバー2に通知する)か、トリガメッセージから接続情報を削除することによりトリガメッセージを更新するか、或いは、サーバー2により要求された接続のタイプを指定するTM2の接続情報を、端末3によりサポートされ、及び、端末3のために許可されるであろう接続のタイプを指定する最も適切な接続情報で上書きし得る。最後の2つの場合、中間ノード5は、その後、更新されたトリガメッセージTM2′を端末3に伝送し得る。
【0063】
例えば、中間ノード5は、端末3の加入のためのデフォルトのQoSプロファイルが何であるかを確かめるようにHSSでチェックし、後のトリガシグナリングに適切なQoS識別を挿入するように構成されたMTC GWを有し得る。
【0064】
図2E及び2Fは、図2Cに記載の中間ノードと類似の2つの中間ノードが使用されている点で図2Dと相違する。図2E及び2Fに示されるサーバー2により伝送されるトリガメッセージTM2、更新されたトリガメッセージTM2′、サーバー2及び端末3は、図2Dに示されるものと同様であり、したがって、ここではこれらの議論は繰り返さない。図2Eは、1つではなく、2つの中間ネットワークノードが使用され、第1の中間ネットワークノード6がトリガメッセージTM2を第2の中間ネットワークノード7に伝送し、これが、その後、サーバー2により要求されたタイプの接続が端末3によりサポートされ、端末3のために許可されているかをチェックするように構成されている点で図2Dと相違する。中間ノード7の機能は、図2Dの中間ノード5のそれと同様であり、簡単のため、ここでは繰り返さない。
【0065】
図2Eに示す構成は、第1の中間ノード6が、サーバーがネットワークにメッセージを送信する権限を有するかどうかをチェックし、サーバー2が送信する権限を有するメッセージを送信するだけであるかをチェックするように構成されている場合に有利であり得る。
【0066】
1実施形態では、第1の中間ノード6は、例えば、MTC GWなどのコントロールプレーンのゲートウェイを含み、一方、第2の中間ノード7は、例えば、P−GWなどのユーザープレーンのゲートウェイを含み得る。
【0067】
図2Fは、図2Dに示す中間ノード5のものと同様のサーバー2によりトリガメッセージTM2に含められた接続情報のチェックを行うのが既に第1の中間ネットワークノード6である点で図2Eと相違する。例えば、1実施形態では、中間ノード6はHSSを有することができ、そしてこれは、受信したトリガメッセージTM2内のQoS情報を端末3のための加入情報に基づいて修正し、更新したトリガメッセージTM2′を中間ノード7に伝送することができ、中間ノード7はその後これを端末3に送信する。これは、HSS及びNASシグナリングを介するトリガリングに特に有益である。
【0068】
図2A−2Fに示す種々の実施形態において、接続情報は、タイミング情報を含ませるのと同一のエンティティによりトリガメッセージに含められても良く、そうでなくても良い。例えば、図2Bの実施形態では、接続情報は、サーバー2によりトリガメッセージに含められ得るが、一方、タイミング情報は、後に、中間ノード5により付加される。他の例では、図2Aの実施形態において、タイミング情報をトリガメッセージに含めるのはサーバー2であるが、接続情報をトリガメッセージに付加するのは中間ノード5(図2には示されていない)などの何らかの中間ノードであり得る。
【0069】
サーバー2及び端末3と同様に、図2B−2Fに示す中間ネットワークノード5,6及び7のそれぞれは、トリガメッセージ及び他のデータを生成して処理するためのプロセッシングユニットと、端末、サーバー又は他のノード及びエンティティと通信するための通信モジュールを含み得る。
【0070】
図3は、本発明の種々のM2Mの実施形態に従って、例えば、MTC GWなどのコントロールプレーンのゲートウェイを介して種々のトリガメッセージがどのように端末に伝送されるかの例示的な説明を提供する。図3−8では、「M2M装置」の語は、これらの例示的な実施形態が特にM2Mアプリケーションに適することを指摘するために、本開示の他の部分に記載の端末3を識別するために使用される。
【0071】
図3に示されるように、MTC GWから先に、多数の潜在的な図2A−2Fの実施形態で使用され得るトリガメカニズムが存在する。これらのメカニズムは、図4−8でそれぞれより詳細に説明される移動体着SMSを用いたトリガリング、IMSメッセージを用いたトリガリング、セルブロードキャストを用いたトリガリング、HSS及びNASシグナリングを介するトリガリング、及び、Network RequestedPDPコンテキストエスタブリッシュメントを介するトリガリングを含む。
【0072】
1実施形態では、MTC GWは、例えば、ネットワークからのステータス情報に基づいて、どのトリガリングメカニズムを選択するかを決定するように構成され得る。他の実施形態では、M2Mサーバーは、どのトリガ方法を使用するかの決定ポイントであり得る。これは、M2Mサーバーが、典型的には、特定のアプリケーション、そのアプリケーションに関連するM2M装置、及び、これらの装置がサポートするトリガリングメカニズムの種類についての殆どの知識を有するため、有利であり得る。
【0073】
図3に示す全てのトリガリングメカニズムにおいて、タイミング情報及び、任意的に、接続情報は、図2A−2Fの種々の実施形態に記載のように、トリガメッセージに付加され得る。ここで、図4−8に関連して種々のトリガリングメカニズムを簡単に記載するが、当業者は、図2A−2Fの実施形態の場面でこれらのトリガリングメカニズムの1以上を実施できることを理解するであろう。
【0074】
図4は、M2Mサーバーにより送信されたトリガメッセージがどのようにMTC GWによりSMSサービスセンター(SMS SC)に送付されるかを示す。そこから、手順は、殆ど、3GPP TS 23.040に記載される標準的な移動体着SMS手順である。主な違いは、通常のSMS手順では、MSISDNがデバイス識別子として使用されることである。M2M通信では、IMSI又はMSISDNリプレースメントが使用されることができ、これは、SendRoutingInfoforSMS手順への変更を示唆する。
【0075】
LTEネットワークでは、本来的なSMSサポートは無く、テキストメッセージングは、IMSインスタントメッセージングを用いて実行される。したがって、LTEにおいてSMSベースのトリガリングが困難であり得る場合は、他の選択肢は、SIPメッセージを用いることであり得る。図5は、M2M装置をトリガするためにIMSメッセージがどのように使用され得るかを示す。最初に、M2M装置は、IMSメッセージを受信可能になるために、IMSで登録することが必要である。MTC GWは、IMSアプリケーションサーバーと見なされ、S−CSCSFでのM2M装置の登録は、MTC GWに送られる。トリガメッセージがMTC GWに受信されると、MTC GWは、SIPメッセージをS−CSCFを有するISCインターフェイスを介してM2M装置に伝送する。
【0076】
図6は、セルブロードキャストを用いたトリガリングを示す。この解決策の背後にある仮定は、M2Mサーバーは、M2M装置が位置するエリアについての情報を有しているということである。エリア付きのトリガリクエストはMTC GWに送信され、MTC GWはこれをセルブロードキャストセンター(CBC)に送る。ここからは、3GPP TS 23.041に記載されるようなセルブロードキャストの標準手順が指示されたエリア内でトリガメッセージをブロードキャストするために使用され得る。M2M装置は、ブロードキャストされたメッセージを受信する。最初に、M2M装置は、どのブロードキャストメッセージがトリガメッセージかを判断する。トリガメッセージは、ブロードキャストチャネル識別子により、又は、ブロードキャストメッセージの特定のフォーマットを通して識別され得る。M2M装置は、任意のトリガメッセージの受信をトリガと解釈してM2Mサーバーへの接続をセットアップし得る。代替的には、M2M装置は、最初に、トリガで送信されたIDとM2M装置のIDの間の適合(match)があるかを判断し、肯定的な適合の際に、M2Mサーバーへの接続をセットアップする。
【0077】
トリガメッセージに使用されるIDは、任意のアプリケーションレベルの識別子であり得、モバイルネットワークに対して完全にトランスペアレントであり得る。例えば、スマートメータリングのアプリケーションは、電気メーターのシリアル番号を使用し得る。また、トリガメッセージ内のIDは、M2M装置のグループを識別し得る。これは、一群のM2M装置が例えばソフトウェアアップグレードを行うことをトリガする効率的な方法を許容する。このような場合、本発明で記述されるように、トリガメッセージ内にタイミング情報も含めることは、トリガメッセージへの応答を時間的に拡散させ、過剰に大きいM2M装置のグループが同時にM2Mサーバーに接続を試みることを軽減又は防止することを可能にし得る。
【0078】
図7は、既存のノンアクセスストラタム(NAS)シグナリングを用いたトリガリングのためのメッセージシーケンスを示す。このコンセプトの背景のアイデアは、トリガメッセージは、これを、M2M装置とネットワークの間で交換される既存のシグナリングメッセージに添付することで、ピギーバックされ得るということである。トリガメッセージは、MTC GWを介してHSSに送信される。HSSは、リクエストを蓄積し、M2M装置が接続しているときは、これをInsert Subscriberメッセージ内でM2Mが登録されたSGSN又はMMEに送信する。例えば、周期的なルーティングエリアアップデートのために、M2M装置が次にSGSN/MMSにシグナルするときに、SGSN/MMEは、M2M装置に応答してトリガメッセージをピギーバッグする。トリガメッセージがM2M装置により成功裏に受信されたときに、トリガリクエストは、SGSN/MME及びHSSから削除され得る。M2M装置が接続していない場合、M2M装置が次回再度ネットワークに接続するまで、HSSは、トリガメッセージを蓄積し得る。
【0079】
5つのトリガメカニズムの最後は、図8に示される。network requested PDP context activationの手順は、3GPP TS 23.060に詳述される。この手順の新しい側面は、MTC GWからGGSNへの接続要求であろう。既存のnetwork requested PDP context activationの手順は、シグナリングメッセージにより開始されるのではなく、装置のためのIPパケットの受信による。どのSGSNにトリガメッセージが送信されるべきかの決定のためのRoutingInfoは、IMSIに基づいてHSSにおいて見出され得る。HSSにクエリを行うために、MSISDNの新しい装置IDリプレースメントを用いることも選択肢であり得る。
【0080】
本発明の1実施形態は、コンピュータシステムで使用されるプログラム製品として実施され得る。プログラム製品のプログラムは、実施形態(本書に記載の方法を含む)の機能を規定し、種々の、好ましくは、非一時的なコンピュータ可読記憶媒体に含まれ得る。例示的なコンピュータ可読記憶媒体は、(i)情報が永続的に蓄積される書込不可の記憶媒体(例えば、CD−ROMドライブにより読み取り可能なCD−ROMディスク、ROMチップ又は任意のタイプのソリッドステート不揮発性半導体メモリなどのコンピュータ内のリードオンリーメモリー装置)、及び、(ii)変更可能な情報が蓄積される書込可能記憶媒体(例えば、ディスクドライブ内のフロッピーディスク又はハードディスクドライブ又は任意のタイプのソリッドステートランダムアクセス半導体メモリー、フラッシュメモリー)を含むが、これらには限定されない。コンピュータプログラムは、本書に記載のプロセッシングユニット上で作動され得る。
【0081】
追加の実施形態が以下に記載される。
時間インジケータを用いたトリガリングは、装置が通常、スタンバイモードにあるときにそれらの装置との通信を可能にする可能性を提供し、これは、バッテリー寿命の節約の利益を提供する。例えば、バッテリー寿命を節約するために、モバイルクライアントは一日の大半が停止モードであり、モバイルクライアントが同報チャネルに接続する(例えば、毎晩3:00など)ある瞬間にのみ起動し得る。場合により、上記のように、これらの「起動時間」の間だけでなく、これらの固定のタイムスロット外でも、これらの装置と通信できることが有用で有利であり得る。この一例は、サーバーが、例えば、16:00にそのときの装置のステータスをチェックするために装置と通信するようにスケジュールされているかどうかである。このシナリオを可能にするため、装置の定期的にスケジュールされた起動時間の間にトリガが装置に送信され得る。このトリガに含まれるものは、サーバーとの通信を可能にするために、装置に、翌日の16:00に起動してデータ接続をセットアップするように指示する時間インジケータであろう。この実施形態の利点は、これにより、装置が一日の大半の間電源切断モードであることを可能にし、それにより、サーバーにより要求される任意の期間においてその装置との通信が可能である柔軟性を維持しつつ、バッテリー寿命を節約し、それにより、メインテナンスの柔軟性を可能にすることである。
【0082】
トリガリングはそれ自体ネットワーク資源を使用するが、トリガリングは、コスト低減のために使用され得る。一日の時間に応じて、モバイルクライアントのトリガリングは、他の時間よりも高価であり得る。例えば、多くのネットワークトラフィックのあるワーキング時間帯の間にモバイルクライアントをトリガリングすることは、同じモバイルクライアントをネットワーク負荷の小さい夜の間にトリガリングするよりも、より高価であり得る。しかし、場合により、例えば、午後の正確に12:00に温度を読み取るなどのために、ある、又は、正確な時点でモバイルクライアントにデータ接続をセットアップさせることが必要であり得る。この場合、トリガメッセージに時間インジケータを含めることは、コスト効率的な解決策であり得る。上記の例では、サーバーは、オフピークの低コストな夜の時間の間にトリガメッセージを送信し得るが、トリガを送るには高価であり得る午後の12:00にデータ接続をセットアップすることをモバイルクライアントに通知する時間インジケータを含め得る。トリガと結果としてのデータ接続を分けることでコストが低減され、これは、モバイル装置にトリガを送信するよりコスト効率的な方法を可能にする。
【0083】
追加の実施形態:許可ウィンドウ外での通信
場合により、モバイルクライアントは、特定のタイムスロット(「アクセス許可時間ウィンドウ」)の間だけ、ネットワークに接続することを許可され得る。これらのタイムスロット外では、モバイルクライアントは、ネットワークに接続を試みると直ちに拒絶される。この方法の1つの欠点は、場合により、サーバ側の視点で見ると、この特定のタイムスロット外に装置と通信することを望むことが有用であり得ることである。換言すれば、場合により、ネットワークは、ネットワークにより装置に与えられたアクセス許可時間ウィンドウに違反することを装置に要求することを望み得る。しかし、所与の期間の間、ネットワークに接続することが許可されていないことを装置が知っているのなら、装置が移動電話無線のスイッチを入れることは道理にかなわないので、ネットワークがモバイルクライアントに、ネットワークに接続するために、ある瞬間にそのアクセス許可時間ウィンドウに違反する要求を通知することはできない。この場合、時間インジケータを有するトリガは、モバイルクライアントがネットワークに接続している時間帯(アクセス許可時間ウィンドウ)の間にモバイルクライアントに送信され得る。このトリガに含まれるものは、モバイルクライアントのアクセス許可時間ウィンドウ外の時間を含む時間インジケータであり得、従って、装置に、ネットワークに接続するために、その時点で、そのアクセス許可時間ウィンドウに違反して良いことを通知し得る。
【技術分野】
【0001】
一般に、本発明は、データ通信の分野に関する。より詳細には、本発明は、例えば、マシンツーマシン(M2M)通信など、端末とアプリケーションサーバーの間のデータ通信の分野に関する。
【背景技術】
【0002】
既存のデータ伝送環境では、装置(「端末」とも呼ばれる)は、ときに、ネットワーク上でデータをサーバーに伝送することが必要とされ、その逆もそうである。固定又はモバイルネットワークでのデータ接続の確立は、一般に、デバイス指向である。例えば、GSM及びUMTSネットワークでのデータ接続の1つのタイプを表すPacket Data Protocol(PDP)コンテキストは、ユーザー端末によりセットアップされる。また、ファイアウォールやネットワークアドレス変換装置のような、殆どのIPミドルボックスは、装置によるデータセッションの開始に依存する。
【0003】
このような装置は、現在3GPP(例えば、TS22.368参照)で標準化されているマシンツーマシン(M2M)通信の分野に適用され得る。多くのM2Mアプリケーションでは、M2M装置がM2M装置とM2Mサーバーの間の通信パスを確立することで十分であるが、M2Mサーバーがデータ接続を開始できることが要求されるアプリケーションもある。
【0004】
M2Mサーバーが装置との通信を開始する例は、スマート電気メータリングアプリケーションである。通常、メーターは、各月末のメーターの読みを報告し得る。しかし、例えば、顧客が異なる電気プロバイダに変えた場合は、M2Mサーバーは、特定の契約終了日のメーターの読みを要求するようにメーターをトリガできることが必要である。
【0005】
サーバー側から接続をセットアップするには、サーバーは、装置に、その装置が接続をセットアップすべきであることを通知する必要がある。このプロセスは、トリガリングと呼ばれる。トリガリングには異なる方法があり、これらは全て、場合によっては、装置がセットアップしなければならないデータ接続のためのサーバーのアドレスが端末に事前設定されていなければ、そのサーバーのアドレス(例えば、APN,IPアドレス又はFQDN)を示しつつ、トリガが、サーバーへの接続をセットアップすることの要求を端末に単に提供するという事実を共通して有する。
【発明の概要】
【発明が解決しようとする課題】
【0006】
端末とサーバーの間のサーバー開始型の通信パスを確立するための改善された方法及びシステムを提供することが本発明の目的である。
【課題を解決するための手段】
【0007】
この目的のため、端末とサーバーの間の通信パスを確立するように少なくとも1つの端末をトリガする方法が開示される。この方法は、端末にトリガメッセージを伝送するステップを有し、トリガメッセージは、少なくとも1つの端末とサーバーの間の通信パスがいつ確立されるべきかを示すタイミング情報を含む。
【0008】
本発明は、これまで、端末がいつサーバーへの通信パスをセットアップすべきかのタイミングにサーバーが影響を有していなかったという認識に基づいている。一旦サーバーがトリガメッセージを端末に伝送すると、接続がいつセットアップされるかの決定は端末に委ねられていた。このような構成は、一群の端末がすべて同時にトリガされるときに特に問題となり得る。各端末は、典型的には、他の端末が何をしているかにつての情報を有さないため、同時にトリガされた全ての端末がサーバーへの接続のセットアップを同時に開始し、そのため、システムの処理及び通信資源に過剰の負荷を課すという状況を生じ得た。本発明は、端末がいつサーバーへの接続を確立すべきかを指定するタイミング情報を端末に提供するトリガメッセージに含めることにより、この状況を軽減又は回避することを助ける。端末にこのようなタイミング情報を提供することで、端末は、接続がいつセットアップされるかについての少なくともある程度のコントロールをサーバーと共有することが可能になる。その結果、サーバーは、トリガメッセージに応答して異なる端末がいつそれらの接続をセットアップするかを管理することが可能となる。サーバーは、典型的には、システム内で何が生じているかのより広い概観(全体像)を有する(例えば、サーバーは、いつ、いくつの端末がトリガされたか、及び、システムで他に何が生じているかについての概観を有する)ため、このようなシステム内の異なる端末の集中化された管理は、システムをより効率的にする。トリガメッセージにタイミング情報を挿入することにより、サーバーは、個々の端末がそれらの接続をセットアップするタイミングを制御するために、サーバーの知識を利用することが可能である。例えば、多数の端末が同時にトリガされた場合、サーバーは、個々の端末の接続のセットアップの発生を時間的に拡散させることができる。
【0009】
集中化された管理は、システム内の異なる端末間の競合の可能性も低下させる。
【0010】
代替的に、上記の機能は、サーバー内で実施されず、何らかの中間ネットワークノード(例えば、ネットワークゲートウェイ)内で実施され得る。専ら端末により決定されるというよりはむしろ、システムのより広い概観を有する何らかのエンティティにより端末とサーバーの間の通信パスがいつ確立されるべきかについてのタイミング情報が端末に提供される限り、全体的なシステムが利益を受ける。
【0011】
本書で使用されるところの、サーバーへの通信パスをセットアップする端末の文脈における「通信パス」の語は、端末とサーバーの間でデータ(典型的には、ユーザーデータ)を通信するためのパス又はチャネルを意味し、その少なくとも一部は、典型的には、端末とネットワークゲートウェイなどの何らかの中間ネットワークノードの間の少なくとも1つのデータ接続を含み、それの上で、端末とネットワークゲートウェイは、PDPコンテキスト又は3GPP TS 23.060に記載のUMTSベアラ又は3GPP TS 23.401に記載のEPSベアラなどの1以上のプロトコルに従ってデータを交換することができる。当業者は、「ネットワークゲートウェイ」の語が、インターネット又はコーポレートパケットデータネットワークなどの外部パケットネットワークとモバイルネットワークの間のゲートウェイとして機能するように適合された中間ネットワークノードを意味することを認識する。既存のGPRS/UMTSネットワークでは、ゲートウェイGPRSサポートノード(GGSN)は、ネットワークゲートウェイとして動作し、一方、LTEネットワークでは、PDNゲートウェイ(P−GW)ノードは、ネットワークゲートウェイである。
【0012】
M2M通信は典型的にはサーバーとの通信パスをセットアップすることを要し得る幾百、幾千又は幾百万の端末を含むため、開示された解決策は、この分野に限定されないが、M2M通信に特に有利である。単一の端末が1以上のサーバーと通信し得るため、端末の数とこれらの端末が接続をセットアップし得るサーバーの数の関係は常にN:1ではないが、典型的には、端末の数は、なおサーバーの数よりも顕著に大きい。その結果、任意の単一のサーバーは、種々の端末がいつこのサーバーとの通信パスをセットアップするかについてのタイミングのコントロールを有することで利益を受けるであろう。
【0013】
M2M通信の一例は、サーバーにより、例えば、大規模顧客基盤の家庭におけるスマート電気メーターから情報を収集することを含む。他の例は、様々なタイプのサーバーへの先進データ接続をサポートし得る通信モジュールを装備し得る監視システム、センサー等を含む。また、モバイルナビゲーション端末及び支払い端末は、M2Mアプリケーションの例である。提示した解決策は、このようなアプリケーションのための端末とサーバーの間の通信パスの確立の効率的なサーバーベースの開始を提供する。
【0014】
種々の実施形態において、トリガメッセージに含まれるタイミング情報は、時間遅延、時間ウィンドウ、及び、端末が端末とサーバーの間の通信パスを確立するための時間をランダムに選択するための指示の1以上を含み得る。通信パスがいつ確立されるべきかの時点を示し得る情報の他の例も考えられ、本発明の範囲内である。
【0015】
1実施形態では、トリガメッセージは、例えば、グループアドレッシングを用い、又は、トリガメッセージを複数の基地局上で同報することで、これらの基地局のカバレッジエリア内に位置する複数の端末に伝送され得る。
【0016】
上記のように、端末とサーバーの間で確立される通信パスは、例えば、端末とネットワークゲートウェイの間の、端末とサーバーの間でどのタイプの通信が必要かに応じて、パラメータの組に従ってセットアップされた少なくとも1つのデータ接続を含み得る。1実施形態では、トリガメッセージは、このような端末とサーバーの間の通信パスにおける第1のタイプのデータ接続を示す接続情報を更に含み得る。
【0017】
当業界で「QoSパラメータ」又は「QoSプロファイル」と通常呼ばれるパラメータの組は、例えば、最大ビットレート、保証ビットレート、アロケーションセットアップ、タイムアウトリミット及びキュー設定などのパラメータを含む。データ接続のタイプの幾つかの例は、ベストエフォート接続、会話式接続、又は、ストリーミング接続を含む。異なるタイプのデータ接続には、異なるQoSパラメータの組が必要である。例えば、会話式データ接続は、音声通信を可能にするために、遅延やジッターに関する厳しい条件を有し得るが、ストリーミング接続では、遅延はさほど重要でない場合がある。
【0018】
このように、端末とネットワークゲートウェイの間のデータ接続は、端末とゲートウェイの間でセットアップされた「トンネル」と見ることができる。そして、サーバー(又はトンネル外、すなわち、外部データパケットネットワークの他のエンティティ)が端末にIPパケットを送信することが必要なときは、サーバーは、ネットワークゲートウェイにルーティングされたIPアドレスを使用するであろう。そこから、IPパケットは、データ接続を介して端末に「トンネリング」される。逆に、IPパケットを端末から外部ネットワークのエンティティにルーティングするときは、IPパケットは、トンネルにおける中間ノードのIPアドレスを知る必要無しに、データ接続を介して端末からネットワークゲートウェイに「トンネリング」される。端末とサーバーの間の全体的な通信パスは、1以上のこのような「トンネル」を含み得る。そして、ネットワークゲートウェイとサーバーの間で、パケットデータネットワークの従来のIPルーティングが使用され得る。
【0019】
勿論、全体の通信パスがデータ接続のタイプを規定する何らかのパラメータの組に従ってセットアップされることを要し得る(すなわち、請求項1に規定の「少なくとも1つのデータ接続」が実際に端末とサーバーの間の全体の通信パスである)という点において、端末とサーバーの間の全体の通信パスが「トンネル」であり得る実施形態も可能である。また、例えば、端末からネットワークゲートウェイへの1つのトンネルとゲートウェイからサーバーへの他のトンネルなど、トンネルの連結が存在する実施形態も可能である。このような実施形態では、両トンネルのQoSパラメータが同一のQoSの指示から抽出されても良く、又は、異なるQoSの指示が存在しても良い。特定の1実施態様では、ネットワークゲートウェイとサーバーの間のトンネル(及び関連するQoSパラメータ)は、トリガメッセージにおけるこのトンネルのタイプの指示を提供することでは必ずしもセットアップされない。このような全ての実施形態は本発明の範囲に含まれ、どのようなパラメータの組(すなわち、必ずしも上記のQoSパラメータではない)がこのようなデータ接続のタイプを指定するのに最も適切であるかを当業者が認識するであろうことが理解される。
【0020】
端末がどのタイプの接続を確立すべきかについての情報を、トリガメッセージ内で、すなわち、端末がこのデータ接続を含む通信パスをセットアップする前に、端末に提供することで、端末が誤ったタイプのデータ接続をセットアップすることが回避され、サーバーと端末の間で交換されるメッセージの数を顕著に減少させることが可能になる。その結果、システムの処理資源が保全され、非効率な帯域幅使用が減少され得る。
【0021】
サーバーが、端末がどのタイプのデータ接続をセットアップするかに影響することを許容することは、技術及び種々のアプリケーションが発展するにつれてますます重要になるだろう。(そこでは、潜在的にはより多様なタイプのデータ接続が端末により要求され、サポートされるであろう。)例えば、ビデオ監視のアプリケーションは、ビデオストリームに適切なQoSを有するベアラを必要とするであろう。
【0022】
種々の実施形態において、接続情報は、例えば、QoSプロファイル又はQoS Class Identifier(QCI)の一部又は全部を含み得る。QCIは、データ接続をセットアップするためにどのQoSパラメータの組を使用すべきかを示す数字の形態であり得る。例えば、1に等しいQCIは、会話式のタイプのデータ接続に必要な全てのQoSパラメータを意味し得る。QCIを用いる利点は、これがQoSプロファイルよりもずっと小さく、したがって、トリガメッセージ内で移送することがずっと容易であることである。QCIは、トリガメッセージが同報チャネル上で送信されるアプリケーションに特に有利である。勿論、接続のタイプを示し得る情報(例えば、要求されたデータ接続のQoSパラメータの範囲又は回路交換接続又はパケット交換接続が使用されるかなど)の他の例も考えられ、本発明の範囲内である。
【0023】
他の実施形態では、上記方法に使用するサーバー及び端末も開示される。
【0024】
更に、上記方法において及び/又は上記端末と共に使用されるように構成された中間ネットワークノードが開示される。このような中間ネットワークノードは、直接又は他の中間ノードを介して端末及びサーバーに通信的に接続され、サーバーで生成されたトリガメッセージは、ノードにより端末に伝送される前に中間ネットワークノードに送信され得る。このような中間ネットワークノードは、例えば、上記のGGSN又はP−GWノードなど、端末とサーバーの間でユーザーデータを通信するネットワークゲートウェイであり得、又は、後で詳述するマシンタイプの通信ゲートウェイ(MTC GW)など、制御データを通信するためのネットワークゲートウェイであり得る。
【0025】
サーバーがトリガメッセージに接続情報を含めるように構成されている実施形態では、中間ネットワークノードは、第1のタイプのデータ接続が端末によりサポートされ、及び/又は、端末のために許可されているかを判断するように構成され得る。肯定的な判断のときに、中間ネットワークノードは、トリガメッセージを更に端末に伝送するように構成され得る。否定的な判断のときに、中間ネットワークノードは、第1のタイプのデータ接続を示す情報を第2のタイプのデータ接続を示す情報で置き換えることでトリガメッセージを更新するように構成され得る。代替的に、否定的な判断のときに、中間ネットワークノードは、場合によってそのことをサーバーに通知しつつ、端末へのトリガメッセージの伝送を停止するように構成され得る。このような機能は、端末に提供されるトリガメッセージが、例えば、端末の加入条件に従って、実際に端末によりサポートされ、及び/又は、これのために許可されたタイプのデータ接続のみについての要求を含むことを確実にする。
【0026】
サーバーが、本発明に従ってタイミング情報を含めずにトリガメッセージを送信するように構成されたサーバーであり得る実施形態では、中間ネットワークノードは、本書に記載の方法を、サーバーから受信したトリガメッセージにタイミング情報及び、任意的に、接続情報を付加することで実施するように構成され得る。これは、有益であり得、その理由は、中間ネットワークノードが、例えば、端末の加入条件に従えば、いつデータ接続が確立されるべきであり、及び/又は、どのタイプのデータ接続が端末によりサポートされ、及び、端末のために許可されているかについての情報を有するエンティティであり得るためである。
【0027】
種々の実施形態において、1以上の中間ネットワークノードがトリガメッセージを伝送するために使用され得る。例えば、1実施形態では、トリガメッセージが最初にサーバーから、例えば、コントロールプレーンのゲートウェイなどの第1の中間ネットワークノードに伝送され、その後、端末に伝送される前に、第1の中間ネットワークノードから例えば、ユーザープレーンのゲートウェイなどの第2の中間ネットワークノードに伝送され得る。このような実施形態は、トリガメッセージを伝送するために先に確立されたデータ接続が使用し得る場合に有利であり得る。さらに、これは、後続のデータ接続のセットアップに携わるエンティティ(例えば、SGSN、S−GW、MME、GGSN、P−GW)がトリガメッセージ内の情報に基づいて、それまでに準備することを可能にし得る。
【0028】
また、本開示は、本書に記載の種々の機能を実施する(場合により分散した)部分を有するコンピュータプログラム、そのようなソフトウェア部分のためのデータキャリア、及び、上記のようなサーバー及び端末を少なくとも有する通信システムに関する。
【0029】
以下、本発明の実施形態がより詳細に説明される。しかし、これらの実施形態は、本発明の保護の範囲を制限するものと解釈してはならないことが理解されるべきである。
【図面の簡単な説明】
【0030】
【図1】端末をアプリケーションサーバーに接続する4G通信ネットワークの概略図。
【図2A】本発明の種々の実施形態に従ってサーバーと端末の間の通信パスを確立するためのトリガメッセージの提供の概略図。
【図2B】本発明の種々の実施形態に従ってサーバーと端末の間の通信パスを確立するためのトリガメッセージの提供の概略図。
【図2C】本発明の種々の実施形態に従ってサーバーと端末の間の通信パスを確立するためのトリガメッセージの提供の概略図。
【図2D】本発明の種々の実施形態に従ってサーバーと端末の間の通信パスを確立するためのトリガメッセージの提供の概略図。
【図2E】本発明の種々の実施形態に従ってサーバーと端末の間の通信パスを確立するためのトリガメッセージの提供の概略図。
【図2F】本発明の種々の実施形態に従ってサーバーと端末の間の通信パスを確立するためのトリガメッセージの提供の概略図。
【図3】本発明の実施形態に従って、種々のトリガメッセージがどのようにコントロールプレーンのゲートウェイを介して端末に伝送され得るかの例示的な説明を提供する。
【図4】本発明の実施形態を実施するために適する種々のトリガリングメカニズムの概略図を提供する。
【図5】本発明の実施形態を実施するために適する種々のトリガリングメカニズムの概略図を提供する。
【図6】本発明の実施形態を実施するために適する種々のトリガリングメカニズムの概略図を提供する。
【図7】本発明の実施形態を実施するために適する種々のトリガリングメカニズムの概略図を提供する。
【図8】本発明の実施形態を実施するために適する種々のトリガリングメカニズムの概略図を提供する。
【発明を実施するための形態】
【0031】
図1は、通信ネットワーク1の概略図を示す。通信ネットワーク1は、サーバー2と端末3の間のデータネットワーク4上でのデータセッションを許容し、端末の通信ネットワーク1へのアクセスはワイヤレスである。
【0032】
図1の通信ネットワークでは、3つの世代の通信ネットワークが簡略の目的もあって概略的に示されている。構成及び概観のより詳細な説明は、その全体が参照により本願に含められる3GPP TS 23.002に見られる。
【0033】
図1の下方の分岐は、GGSN、サービング・GPRS・サポート・ノード(SGSN)及び無線アクセスネットワーク(RAN)を有するGPRS又はUMTS通信ネットワークを示す。GSM/EDGE無線アクセスネットワーク(GERAN)については、RANは、いずれも図示されない、複数の基地局送受信機(BTS)に接続された基地局制御装置(BSC)を有する。UMTS無線アクセスネットワーク(UTRAN)については、RANは、同様に図示されない、複数のNodeBに接続された無線ネットワーク制御装置(RNC)を有する。GGSN及びSGSNは、一般には、端末3の加入情報を含むホームロケーションレジスタ(HLR)に接続される。図では、HLRは、ネットワークに端末3を認証する認証センター(AuC)と組み合わされている。
【0034】
図1の上方の分岐は、通常、Long Term Evolution(LTE)又はEvolved Packet System(EPS)と表される次世代通信ネットワークを示す。このようなネットワークは、P−GW及びServing Gateway(S−GW)を有する。LTEネットワークのE−UTRANは、パケットネットワークを介してS−GWに接続された端末3にワイヤレスアクセスを提供するevolved NodeB(eNodeB又はeNB)を有する。S−GWは、シグナリングの目的で、Home Subscriber Server(HSS)及びMobility Management Entity(MME)に接続される。HSSは、加入プロファイルリポジトリ及び認証センター(AuC)を含む。LTEネットワークの一般的な構成についての更なる情報は、3GPP TS 23.401に見出し得る。
【0035】
GPRS及びUMTSネットワークのGGSNノード及びLTEネットワークのP−GWノードは、例えば、QoSポリシーエンフォーシング、使用メータリング及びIPアドレス割当などの機能を提供する外部データネットワーク4とモバイルネットワークの間のユーザープレーンのゲートウェイとして動作する。図1の全てのネットワークは、任意的に、現在標準化されている、例えば、MTC GWなどのコントロールプレーンのゲートウェイも含み得る。コントロールプレーンのゲートウェイは、サーバーからの制御メッセージのためのモバイルネットワークにおけるエントリーポイントとして動作するように意図される。コントロールプレーンのゲートウェイの目的は、典型的には、許可されていない制御メッセージ、又は、許可されていないサーバーから送信された制御メッセージからネットワークを保護することである。コントロールプレーンのゲートウェイは、サーバーが1つのネットワーク運用者とのみ通信する場合に、サーバー中に事前規定され得る。さもなければ、サーバーは、本発明に記述されるトリガメッセージなどの制御メッセージをどの運用者に送信する必要があるかを最初に決定することが必要である。装置ID、グループID又はIMSIに基づいて、サーバーは、正しいモバイル運用者ネットワークを見つけることができるべきである。
【0036】
勿論、ユーザープレーンのゲートウェイ及びコントロールプレーンのゲートウェイの機能は、単一のノードに結合し、又は、図1で示されるよりも多数のノードに分散し得る。
【0037】
図2A−2Fは、本発明の種々の実施形態に従ってサーバーと端末の間のデータ接続を確立するためのトリガメッセージの提供の概略図である。明確化ため、トリガメッセージの伝送の関連ステップのみが図2A−2Fに示されている。他の手順、例えば、認証、実際のデータ接続のセットアップ及びユーザーデータの交換に関連する手順は、含まれていない。
【0038】
図2Aに示すように、1実施形態では、サーバー2は、トリガメッセージTM1を生成してこれを直接端末3に伝送するように構成され得る。そのため、サーバー2は、トリガメッセージを生成するプロセッシングユニットと、トリガメッセージを伝送する通信モジュールを含み得る。
【0039】
トリガメッセージを端末に直接伝送するサーバーの文脈では、「直接」の語は、図2Aの実施形態を、サーバー2で生成されたトリガメッセージが1以上の中間ネットワークノードを介して伝送され、及び、場合によっては、更にこれらにより処理される図2B−2Fの実施形態と区別するためにのみ使用される。このように、図2Aに示す実施形態では、トリガメッセージは、例えば、セルブロードキャストセンター(CBC)又はSMSサービスセンター(SMS−SC)など、図2B−2Fに記載の中間ノード以外のエンティティを介して端末3に伝送され得る。
【0040】
トリガメッセージTM1は、端末3がサーバー2との通信パスを確立すべき時点を指定する少なくともタイミング情報を含むことにより形成される。通信パスの少なくとも一部は、少なくとも1つの特定のタイプのデータ接続を含むため、タイミング情報は、端末3がいつデータ接続のセットアップを開始すべきかを指定する。タイミング情報を有するトリガメッセージの受信に応答して、端末3は、タイミング情報に基づいて端末3が決定する時点まで、通信パス/データ接続の確立を遅延させる。
【0041】
1実施形態では、タイミング情報は、例えば、端末3に(例えば、トリガメッセージの受信の時点から又はトリガメッセージがサーバー2からいつ送信されたかを示すタイムスタンプから測定して)1時間だけ通信パス/データ接続の確立を遅延させるように指示する遅延時間の形態で、トリガメッセージに含まれ得る。例えば、タイミング情報は、75秒の遅延後に、又は、13分15秒の遅延後に通信パスを確立するように端末3を指示し得る(すなわち、タイミング情報は、遅延を数秒まで正確に指定し得る)。
【0042】
タイミング情報はまた、07:35:35に(すなわち、特定の時点に)通信パス確立するように端末3を指示し得る。
【0043】
他の実施形態では、タイミング情報は、例えば、16:00と17:00の間、又は、より短い時間ウィンドウである03:45:15と03:45:45の間に通信パス/データ接続を確立するように端末3を指示するなど、時間ウィンドウの形態であり得る。
【0044】
更に他の実施形態では、タイミング情報は、通信パス/データ接続を確立する時点をランダムに選択するように端末3を指示し得る。この実施形態は、例えば、グループアドレッシングを用いて、トリガメッセージが一群の端末に送信され、各端末がトリガメッセージに応答する時点をランダム化する状況で特に有益であり得る。
【0045】
上記のタイミング情報の可能なタイプの1以上の例示的な説明は相互に組み合わされ得る。例えば、通信パス/データ接続を確立する時点をランダムに選択するように端末3を指示するタイミング情報の実施形態は、例えば、タイミング情報が、通信パス/データ接続を確立するために特定の時間ウィンドウの何らかのランダムな時点(例えば、02:00と04:00の間のランダムな時点)を選択するように端末3を指示し得るように、遅延時間又はウィンドウ時間の提供と組み合わされ得る。他の例では、タイミング情報は、今と1時間の間で通信パスを確立するための時点をランダム化するように端末3を指示し得る。代替的には、時間遅延及び時間ウィンドウの両方を提供するタイミング情報が可能であり、この場合、タイミング情報は、期間とともに遅延を示し、例えば、1時間の時間ウィンドウの間で15分の遅延の後に通信パスを確立するように端末3を指示する。このような実施形態は、絶対的な時間の指示の提供と異なり、時間遅延及び時間ウィンドウ情報の提供に全ての関連するノードの間での(場合によっては、タイムゾーンやサマータイムも考慮した)同期を必要としないため、有益であり得る。更に他の例では、タイミング情報は、例えば、今から15分後から今から30分後までに通信パスを確立するように端末を指示する2つの遅延を含み得る。
【0046】
タイミング情報は、(1つの)トリガが一群の端末に送信されるときにネットワーク負荷を拡散させる(すなわち、端末がそれらの負荷をランダム化する)、及び/又は、(複数の)トリガが個々の端末に送信されるときにネットワーク負荷を拡散させる(すなわち、サーバーが端末の負荷をランダム化する)ために使用され得る。
【0047】
更に、トリガメッセージ内のタイミング情報は、例えば、データの記録を開始し、4日後にデータを送信し、又は、7月1日13:00と7月4日15:00の間にデータを記録し、その後データを送信するなど、端末3がそのデータのサーバー2への送信を開始する前に何かを行うように端末3を指示し得る。
【0048】
上記例が示すように、タイミング情報は、数秒から数日の時間に関連し得る。どの時点で端末3が通信パス/データ接続を確立すべきであり、又は、すべきでないかを示す他のタイプのタイミング情報も考えることができ、本発明の範囲内であることが意図される。
【0049】
トリガメッセージTM1は、リクエストをその承認と関連づけ、アプリケーションがリクエストをキャンセルすることを可能にするために、端末3の識別、アプリケーションの識別及び/又は重複したリクエストを検出することを可能にするためのこのリクエストに関連するリクエストカウンターなど、従来のトリガメッセージに典型的に含まれていた情報をも含み得る。トリガメッセージTM1は、また、任意的に、IPアドレス(または完全修飾ドメイン名)及び/又は端末がデータ接続を確立することをトリガされるアプリケーションサーバー2のポート番号、緊急リクエストの指示、端末に(例えばSMSで)接続できないときにネットワークに蓄積されたトリガの除去を許可する有効タイマー、トリガリングを送信すべきエリア、及び/又は、(例えば、サーバー2との通信パスを確立する前に端末3に何かをすることを指示するための)限定された程度の用途特定情報を含み得る。
【0050】
トリガメッセージTM1を受信すると、端末3は、メッセージからタイミング情報を取得し、その後、取得したタイミング情報に基づいて、どの時点でサーバー2との通信パスが確立されるべきかを判断し、最後に、その決定した時点に通信パスを確立するように構成さる。そのため、端末3は、トリガメッセージからタイミング情報を抽出し、通信パスがいつ確立されるべきかを決定できるプロセッシングユニットと、要求された通信パスを確立するための通信モジュールを含み得る。端末3のプロセッシングユニット及び/又は通信モジュールの機能の少なくとも一部は、端末3内の(U)SIM内に含まれ得る。
【0051】
図2B及び2Cは、図2B及び2Cでは、サーバー2がトリガメッセージ内にタイミング情報を含まない点で図2Aと異なる。その代わり、端末3に伝送されるトリガメッセージにタイミング情報を含めるのが何らかの中間ネットワークノードである。
【0052】
図2Bでは、サーバー2は、例えば、上記のGGSN、P−GWまたはMTC−GWなどの中間ネットワークノード5にトリガメッセージTM0を伝送する。中間ノード5は、直接又は他の中間ノードを介してサーバー2に通信的に接続され、中間ノード5は、サーバー2から(外部ネットワーク4上で)トリガメッセージを受信し得る。中間ノード5は、また、直接又は他の中間ノードを介して端末3に通信的に接続され、中間ノード5は、更に端末3にモバイルネットワーク上でトリガメッセージを伝送し得る。
【0053】
図2Bに示される実施形態では、中間ノード5は、サーバー2からタイミング情報を含まないトリガメッセージTM0(すなわち、トリガメッセージTM0は、従来のトリガメッセージであり得る)を受信する。中間ノード5は、その後、トリガメッセージにタイミング情報を付加し、これにより、新たなトリガメッセージTM1を生成し、そして、タイミング情報を有するトリガメッセージTM1を端末3に伝送するように構成される。トリガメッセージTM1及び端末3に関する上記の議論は、ここでも適用可能であり、したがって、繰り返さない。
【0054】
図2Cは、2つの中間ノードである第1の中間ノード6及び第2の中間ノード7が使用される点で図2Bと相違する。第1の中間ノード6は、直接又は他の中間ノードを介してサーバー2に通信的に接続し、中間ノード6は、トリガメッセージをサーバー2から受信し得る。第1の中間ノード6は、また、直接又は他の中間ノードを介して中間ノード7に通信的に接続され、中間ノード6は、トリガメッセージを更にノード7に伝送し得る。中間ノード7は、同様に直接又は他の中間ノードを介して端末3に通信的に接続し、中間ノード7は、今度は、トリガメッセージを端末3に更に伝送し得る。
【0055】
図2Cに示す実施形態では、第1の中間ノード6又は第2の中間ノード7のどちらかは、図2Bに示す中間ノード5が行うのと同様にして、トリガメッセージにタイミング情報を含ませることができる。
【0056】
図2A−2Cの全ての実施形態において、トリガメッセージは、サーバー2と端末3の間の通信パスを確立する端末3の一部として、サーバー2が端末3にセットアップさせることを要する少なくとも1つのデータ接続のタイプを指定する接続情報を更に含み得る。接続情報は、例えば、完全又は部分的なQoSプロファイル、QCI又は特定のタイプのデータ接続を適切に識別できる何らかの他の情報を含み得る。通信パス内の要求されたタイプのデータ接続を示す情報を、トリガメッセージにその情報を含めることにより、データ接続/通信パスがセットアップされる前に提供することで、当業界で現在なされているように、誤ったタイプの接続をセットアップし、その後、それを修正しなければならないことによりシステム資源の浪費をしなければならないことの防止を可能にする。
【0057】
このような実施形態では、タイミング情報だけでなく、接続情報も含むトリガメッセージを受信すると、端末3は、メッセージから接続情報を取得し、サーバー2への通信パスを確立するように構成され、通信パスは、メッセージで指定されるタイプのデータ接続を含む。
【0058】
図2D−2Fは、トリガメッセージが、タイミング情報に加えて、端末によりサポートされ、端末のために許可された通信パス内のデータ接続のタイプを指定する接続情報を含むときに、1以上の中間ノードが、端末へのトリガメッセージの提供に際してサーバー2をどのようにさらに補助するかを示す。
【0059】
図2Dは、図2Bに示す中間ネットワークノード5と同様、例えば、GGSN、P−GW又はMTC GWなどの中間ネットワークノード5がサーバー2と端末3の間の通信パスに含まれ得ることを示す。
【0060】
中間ノード5は、上記のように、サーバーからタイミング情報だけでなく接続情報も含むトリガメッセージTM2を受信する。
【0061】
中間ノード5は、その後、受信したトリガメッセージTM2から接続情報を抽出し、その接続情報により識別される特定のQoSプロファイルが端末3によりサポートされ、及び/又は、端末3の加入条件で許容されているかをチェックするように構成され得る。これは、例えば、加入者情報を含むHSSでのチェックにより行われ得る。
【0062】
中間ノード5がTM2で識別されるタイプの接続が端末3によりサポートされ、そのために許容されていると判断した場合には、中間ノード5は、トリガメッセージTM2を更に端末3に伝送し得る。他の場合は、中間ノード5は、端末3へのトリガメッセージの伝送を停止する(場合によっては、トリガメッセージTM2の伝送が中断されたことをサーバー2に通知する)か、トリガメッセージから接続情報を削除することによりトリガメッセージを更新するか、或いは、サーバー2により要求された接続のタイプを指定するTM2の接続情報を、端末3によりサポートされ、及び、端末3のために許可されるであろう接続のタイプを指定する最も適切な接続情報で上書きし得る。最後の2つの場合、中間ノード5は、その後、更新されたトリガメッセージTM2′を端末3に伝送し得る。
【0063】
例えば、中間ノード5は、端末3の加入のためのデフォルトのQoSプロファイルが何であるかを確かめるようにHSSでチェックし、後のトリガシグナリングに適切なQoS識別を挿入するように構成されたMTC GWを有し得る。
【0064】
図2E及び2Fは、図2Cに記載の中間ノードと類似の2つの中間ノードが使用されている点で図2Dと相違する。図2E及び2Fに示されるサーバー2により伝送されるトリガメッセージTM2、更新されたトリガメッセージTM2′、サーバー2及び端末3は、図2Dに示されるものと同様であり、したがって、ここではこれらの議論は繰り返さない。図2Eは、1つではなく、2つの中間ネットワークノードが使用され、第1の中間ネットワークノード6がトリガメッセージTM2を第2の中間ネットワークノード7に伝送し、これが、その後、サーバー2により要求されたタイプの接続が端末3によりサポートされ、端末3のために許可されているかをチェックするように構成されている点で図2Dと相違する。中間ノード7の機能は、図2Dの中間ノード5のそれと同様であり、簡単のため、ここでは繰り返さない。
【0065】
図2Eに示す構成は、第1の中間ノード6が、サーバーがネットワークにメッセージを送信する権限を有するかどうかをチェックし、サーバー2が送信する権限を有するメッセージを送信するだけであるかをチェックするように構成されている場合に有利であり得る。
【0066】
1実施形態では、第1の中間ノード6は、例えば、MTC GWなどのコントロールプレーンのゲートウェイを含み、一方、第2の中間ノード7は、例えば、P−GWなどのユーザープレーンのゲートウェイを含み得る。
【0067】
図2Fは、図2Dに示す中間ノード5のものと同様のサーバー2によりトリガメッセージTM2に含められた接続情報のチェックを行うのが既に第1の中間ネットワークノード6である点で図2Eと相違する。例えば、1実施形態では、中間ノード6はHSSを有することができ、そしてこれは、受信したトリガメッセージTM2内のQoS情報を端末3のための加入情報に基づいて修正し、更新したトリガメッセージTM2′を中間ノード7に伝送することができ、中間ノード7はその後これを端末3に送信する。これは、HSS及びNASシグナリングを介するトリガリングに特に有益である。
【0068】
図2A−2Fに示す種々の実施形態において、接続情報は、タイミング情報を含ませるのと同一のエンティティによりトリガメッセージに含められても良く、そうでなくても良い。例えば、図2Bの実施形態では、接続情報は、サーバー2によりトリガメッセージに含められ得るが、一方、タイミング情報は、後に、中間ノード5により付加される。他の例では、図2Aの実施形態において、タイミング情報をトリガメッセージに含めるのはサーバー2であるが、接続情報をトリガメッセージに付加するのは中間ノード5(図2には示されていない)などの何らかの中間ノードであり得る。
【0069】
サーバー2及び端末3と同様に、図2B−2Fに示す中間ネットワークノード5,6及び7のそれぞれは、トリガメッセージ及び他のデータを生成して処理するためのプロセッシングユニットと、端末、サーバー又は他のノード及びエンティティと通信するための通信モジュールを含み得る。
【0070】
図3は、本発明の種々のM2Mの実施形態に従って、例えば、MTC GWなどのコントロールプレーンのゲートウェイを介して種々のトリガメッセージがどのように端末に伝送されるかの例示的な説明を提供する。図3−8では、「M2M装置」の語は、これらの例示的な実施形態が特にM2Mアプリケーションに適することを指摘するために、本開示の他の部分に記載の端末3を識別するために使用される。
【0071】
図3に示されるように、MTC GWから先に、多数の潜在的な図2A−2Fの実施形態で使用され得るトリガメカニズムが存在する。これらのメカニズムは、図4−8でそれぞれより詳細に説明される移動体着SMSを用いたトリガリング、IMSメッセージを用いたトリガリング、セルブロードキャストを用いたトリガリング、HSS及びNASシグナリングを介するトリガリング、及び、Network RequestedPDPコンテキストエスタブリッシュメントを介するトリガリングを含む。
【0072】
1実施形態では、MTC GWは、例えば、ネットワークからのステータス情報に基づいて、どのトリガリングメカニズムを選択するかを決定するように構成され得る。他の実施形態では、M2Mサーバーは、どのトリガ方法を使用するかの決定ポイントであり得る。これは、M2Mサーバーが、典型的には、特定のアプリケーション、そのアプリケーションに関連するM2M装置、及び、これらの装置がサポートするトリガリングメカニズムの種類についての殆どの知識を有するため、有利であり得る。
【0073】
図3に示す全てのトリガリングメカニズムにおいて、タイミング情報及び、任意的に、接続情報は、図2A−2Fの種々の実施形態に記載のように、トリガメッセージに付加され得る。ここで、図4−8に関連して種々のトリガリングメカニズムを簡単に記載するが、当業者は、図2A−2Fの実施形態の場面でこれらのトリガリングメカニズムの1以上を実施できることを理解するであろう。
【0074】
図4は、M2Mサーバーにより送信されたトリガメッセージがどのようにMTC GWによりSMSサービスセンター(SMS SC)に送付されるかを示す。そこから、手順は、殆ど、3GPP TS 23.040に記載される標準的な移動体着SMS手順である。主な違いは、通常のSMS手順では、MSISDNがデバイス識別子として使用されることである。M2M通信では、IMSI又はMSISDNリプレースメントが使用されることができ、これは、SendRoutingInfoforSMS手順への変更を示唆する。
【0075】
LTEネットワークでは、本来的なSMSサポートは無く、テキストメッセージングは、IMSインスタントメッセージングを用いて実行される。したがって、LTEにおいてSMSベースのトリガリングが困難であり得る場合は、他の選択肢は、SIPメッセージを用いることであり得る。図5は、M2M装置をトリガするためにIMSメッセージがどのように使用され得るかを示す。最初に、M2M装置は、IMSメッセージを受信可能になるために、IMSで登録することが必要である。MTC GWは、IMSアプリケーションサーバーと見なされ、S−CSCSFでのM2M装置の登録は、MTC GWに送られる。トリガメッセージがMTC GWに受信されると、MTC GWは、SIPメッセージをS−CSCFを有するISCインターフェイスを介してM2M装置に伝送する。
【0076】
図6は、セルブロードキャストを用いたトリガリングを示す。この解決策の背後にある仮定は、M2Mサーバーは、M2M装置が位置するエリアについての情報を有しているということである。エリア付きのトリガリクエストはMTC GWに送信され、MTC GWはこれをセルブロードキャストセンター(CBC)に送る。ここからは、3GPP TS 23.041に記載されるようなセルブロードキャストの標準手順が指示されたエリア内でトリガメッセージをブロードキャストするために使用され得る。M2M装置は、ブロードキャストされたメッセージを受信する。最初に、M2M装置は、どのブロードキャストメッセージがトリガメッセージかを判断する。トリガメッセージは、ブロードキャストチャネル識別子により、又は、ブロードキャストメッセージの特定のフォーマットを通して識別され得る。M2M装置は、任意のトリガメッセージの受信をトリガと解釈してM2Mサーバーへの接続をセットアップし得る。代替的には、M2M装置は、最初に、トリガで送信されたIDとM2M装置のIDの間の適合(match)があるかを判断し、肯定的な適合の際に、M2Mサーバーへの接続をセットアップする。
【0077】
トリガメッセージに使用されるIDは、任意のアプリケーションレベルの識別子であり得、モバイルネットワークに対して完全にトランスペアレントであり得る。例えば、スマートメータリングのアプリケーションは、電気メーターのシリアル番号を使用し得る。また、トリガメッセージ内のIDは、M2M装置のグループを識別し得る。これは、一群のM2M装置が例えばソフトウェアアップグレードを行うことをトリガする効率的な方法を許容する。このような場合、本発明で記述されるように、トリガメッセージ内にタイミング情報も含めることは、トリガメッセージへの応答を時間的に拡散させ、過剰に大きいM2M装置のグループが同時にM2Mサーバーに接続を試みることを軽減又は防止することを可能にし得る。
【0078】
図7は、既存のノンアクセスストラタム(NAS)シグナリングを用いたトリガリングのためのメッセージシーケンスを示す。このコンセプトの背景のアイデアは、トリガメッセージは、これを、M2M装置とネットワークの間で交換される既存のシグナリングメッセージに添付することで、ピギーバックされ得るということである。トリガメッセージは、MTC GWを介してHSSに送信される。HSSは、リクエストを蓄積し、M2M装置が接続しているときは、これをInsert Subscriberメッセージ内でM2Mが登録されたSGSN又はMMEに送信する。例えば、周期的なルーティングエリアアップデートのために、M2M装置が次にSGSN/MMSにシグナルするときに、SGSN/MMEは、M2M装置に応答してトリガメッセージをピギーバッグする。トリガメッセージがM2M装置により成功裏に受信されたときに、トリガリクエストは、SGSN/MME及びHSSから削除され得る。M2M装置が接続していない場合、M2M装置が次回再度ネットワークに接続するまで、HSSは、トリガメッセージを蓄積し得る。
【0079】
5つのトリガメカニズムの最後は、図8に示される。network requested PDP context activationの手順は、3GPP TS 23.060に詳述される。この手順の新しい側面は、MTC GWからGGSNへの接続要求であろう。既存のnetwork requested PDP context activationの手順は、シグナリングメッセージにより開始されるのではなく、装置のためのIPパケットの受信による。どのSGSNにトリガメッセージが送信されるべきかの決定のためのRoutingInfoは、IMSIに基づいてHSSにおいて見出され得る。HSSにクエリを行うために、MSISDNの新しい装置IDリプレースメントを用いることも選択肢であり得る。
【0080】
本発明の1実施形態は、コンピュータシステムで使用されるプログラム製品として実施され得る。プログラム製品のプログラムは、実施形態(本書に記載の方法を含む)の機能を規定し、種々の、好ましくは、非一時的なコンピュータ可読記憶媒体に含まれ得る。例示的なコンピュータ可読記憶媒体は、(i)情報が永続的に蓄積される書込不可の記憶媒体(例えば、CD−ROMドライブにより読み取り可能なCD−ROMディスク、ROMチップ又は任意のタイプのソリッドステート不揮発性半導体メモリなどのコンピュータ内のリードオンリーメモリー装置)、及び、(ii)変更可能な情報が蓄積される書込可能記憶媒体(例えば、ディスクドライブ内のフロッピーディスク又はハードディスクドライブ又は任意のタイプのソリッドステートランダムアクセス半導体メモリー、フラッシュメモリー)を含むが、これらには限定されない。コンピュータプログラムは、本書に記載のプロセッシングユニット上で作動され得る。
【0081】
追加の実施形態が以下に記載される。
時間インジケータを用いたトリガリングは、装置が通常、スタンバイモードにあるときにそれらの装置との通信を可能にする可能性を提供し、これは、バッテリー寿命の節約の利益を提供する。例えば、バッテリー寿命を節約するために、モバイルクライアントは一日の大半が停止モードであり、モバイルクライアントが同報チャネルに接続する(例えば、毎晩3:00など)ある瞬間にのみ起動し得る。場合により、上記のように、これらの「起動時間」の間だけでなく、これらの固定のタイムスロット外でも、これらの装置と通信できることが有用で有利であり得る。この一例は、サーバーが、例えば、16:00にそのときの装置のステータスをチェックするために装置と通信するようにスケジュールされているかどうかである。このシナリオを可能にするため、装置の定期的にスケジュールされた起動時間の間にトリガが装置に送信され得る。このトリガに含まれるものは、サーバーとの通信を可能にするために、装置に、翌日の16:00に起動してデータ接続をセットアップするように指示する時間インジケータであろう。この実施形態の利点は、これにより、装置が一日の大半の間電源切断モードであることを可能にし、それにより、サーバーにより要求される任意の期間においてその装置との通信が可能である柔軟性を維持しつつ、バッテリー寿命を節約し、それにより、メインテナンスの柔軟性を可能にすることである。
【0082】
トリガリングはそれ自体ネットワーク資源を使用するが、トリガリングは、コスト低減のために使用され得る。一日の時間に応じて、モバイルクライアントのトリガリングは、他の時間よりも高価であり得る。例えば、多くのネットワークトラフィックのあるワーキング時間帯の間にモバイルクライアントをトリガリングすることは、同じモバイルクライアントをネットワーク負荷の小さい夜の間にトリガリングするよりも、より高価であり得る。しかし、場合により、例えば、午後の正確に12:00に温度を読み取るなどのために、ある、又は、正確な時点でモバイルクライアントにデータ接続をセットアップさせることが必要であり得る。この場合、トリガメッセージに時間インジケータを含めることは、コスト効率的な解決策であり得る。上記の例では、サーバーは、オフピークの低コストな夜の時間の間にトリガメッセージを送信し得るが、トリガを送るには高価であり得る午後の12:00にデータ接続をセットアップすることをモバイルクライアントに通知する時間インジケータを含め得る。トリガと結果としてのデータ接続を分けることでコストが低減され、これは、モバイル装置にトリガを送信するよりコスト効率的な方法を可能にする。
【0083】
追加の実施形態:許可ウィンドウ外での通信
場合により、モバイルクライアントは、特定のタイムスロット(「アクセス許可時間ウィンドウ」)の間だけ、ネットワークに接続することを許可され得る。これらのタイムスロット外では、モバイルクライアントは、ネットワークに接続を試みると直ちに拒絶される。この方法の1つの欠点は、場合により、サーバ側の視点で見ると、この特定のタイムスロット外に装置と通信することを望むことが有用であり得ることである。換言すれば、場合により、ネットワークは、ネットワークにより装置に与えられたアクセス許可時間ウィンドウに違反することを装置に要求することを望み得る。しかし、所与の期間の間、ネットワークに接続することが許可されていないことを装置が知っているのなら、装置が移動電話無線のスイッチを入れることは道理にかなわないので、ネットワークがモバイルクライアントに、ネットワークに接続するために、ある瞬間にそのアクセス許可時間ウィンドウに違反する要求を通知することはできない。この場合、時間インジケータを有するトリガは、モバイルクライアントがネットワークに接続している時間帯(アクセス許可時間ウィンドウ)の間にモバイルクライアントに送信され得る。このトリガに含まれるものは、モバイルクライアントのアクセス許可時間ウィンドウ外の時間を含む時間インジケータであり得、従って、装置に、ネットワークに接続するために、その時点で、そのアクセス許可時間ウィンドウに違反して良いことを通知し得る。
【特許請求の範囲】
【請求項1】
少なくとも1つの端末とサーバーの間の通信パスを確立するために前記少なくとも1つの端末をトリガする方法であって、前記方法は、前記少なくとも1つの端末にトリガメッセージを伝送するステップを有し、前記トリガメッセージは、前記少なくとも1つの端末と前記サーバーの間の前記通信パスがいつ確立されるべきかを示すタイミング情報を含むことを特徴とする方法。
【請求項2】
前記タイミング情報が、時間遅延、時間ウィンドウ及び前記少なくとも1つの端末と前記サーバーの間の前記通信パスを確立する時間をランダムに選択する指示の1以上を含むことを特徴とする請求項1に記載の方法。
【請求項3】
前記トリガメッセージが、複数の端末に伝送され、前記複数の端末が、前記少なくとも1つの端末を含むことを特徴とする請求項1又は2に記載の方法。
【請求項4】
前記通信パスが、少なくとも1つのデータ接続を含み、前記トリガメッセージが、第1のタイプの前記少なくとも1つのデータ接続を示す接続情報を更に含むことを特徴とする請求項1〜3のいずれか一項に記載の方法。
【請求項5】
前記接続情報を含む前記トリガメッセージが、前記少なくとも1つの端末に伝送される前に、前記サーバーで生成されて第1の中間ネットワークノードに伝送され、前記方法が、
前記第1のタイプの前記少なくとも1つのデータ接続が前記少なくとも1つの端末によりサポートされ、及び/又は、前記少なくとも1つの端末のために許可されているかを判断するステップと、
肯定的な判断のときに、前記トリガメッセージを前記第1の中間ネットワークノードから前記少なくとも1つの端末に伝送するステップとを有することを特徴とする請求項4に記載の方法。
【請求項6】
否定的な判断のときに、前記第1のタイプの前記少なくとも1つのデータ接続を示す情報を、前記少なくとも1つの端末によりサポートされ、前記少なくとも1つの端末のために許可されている第2のタイプの少なくとも1つのデータ接続を示す情報で置き換えることで前記トリガメッセージを更新するステップと、
前記トリガメッセージが更新された後で、前記トリガメッセージを前記第1の中間ネットワークノードから前記少なくとも1つの端末に伝送するステップとを更に有することを特徴とする請求項5に記載の方法。
【請求項7】
前記トリガメッセージが前記第1の中間ネットワークノードから前記少なくとも1つの端末に第2の中間ネットワークノードを介して伝送され、任意的に、前記第1の中間ネットワークノードがコントロールプレーンのゲートウェイを有し、前記第2の中間ネットワークノードがユーザープレーンのゲートウェイを有することを特徴とする請求項5又は6に記載の方法。
【請求項8】
請求項1〜4のいずれか一項に記載の方法を実行するように構成された手段を有するサーバー。
【請求項9】
サーバー及び少なくとも1つの端末に通信的に接続され、請求項1〜7のいずれか一項に記載の方法を実行するように構成された手段を有することを特徴とする第1の中間ネットワークノード。
【請求項10】
前記第1の中間ネットワークノードがコントロールプレーンのゲートウェイ又はユーザープレーンのゲートウェイであることを特徴とする請求項9に記載の第1の中間ネットワークノード。
【請求項11】
端末が当該端末とサーバーの間の通信パスを確立する方法であって、前記方法が、
前記端末と前記サーバーの間の前記通信パスがいつ確立されるべきかを示すタイミング情報を含むトリガメッセージを受信するステップと、
前記タイミング情報に従って前記端末と前記サーバーの間の前記通信パスを確立するステップとを有することを特徴とする方法。
【請求項12】
前記タイミング情報が、時間遅延、時間ウィンドウ及び前記端末と前記サーバーの間の前記通信パスを確立する時間をランダムに選択する指示の1以上を含むことを特徴とする請求項11に記載の方法。
【請求項13】
前記端末と前記サーバーの間の前記通信パスが、少なくとも1つのデータ接続を含み、
前記トリガメッセージが第1のタイプの前記少なくとも1つのデータ接続を示す接続情報を更に含み、
前記端末と前記サーバーの間の前記通信パスが前記接続情報に従って確立されることを特徴とする請求項11又は12に記載の方法。
【請求項14】
請求項11〜13のいずれか一項に記載の方法を実行するように構成された手段を有する端末。
【請求項15】
請求項14に記載の端末と、請求項8に記載のサーバーを有するシステム。
【請求項16】
プロセッサーにより実行されたときに、請求項1〜7及び請求項11〜13のいずれか一項に記載のステップを実行するように構成されたソフトウェアコード部分を有するコンピュータプログラム。
【請求項1】
少なくとも1つの端末とサーバーの間の通信パスを確立するために前記少なくとも1つの端末をトリガする方法であって、前記方法は、前記少なくとも1つの端末にトリガメッセージを伝送するステップを有し、前記トリガメッセージは、前記少なくとも1つの端末と前記サーバーの間の前記通信パスがいつ確立されるべきかを示すタイミング情報を含むことを特徴とする方法。
【請求項2】
前記タイミング情報が、時間遅延、時間ウィンドウ及び前記少なくとも1つの端末と前記サーバーの間の前記通信パスを確立する時間をランダムに選択する指示の1以上を含むことを特徴とする請求項1に記載の方法。
【請求項3】
前記トリガメッセージが、複数の端末に伝送され、前記複数の端末が、前記少なくとも1つの端末を含むことを特徴とする請求項1又は2に記載の方法。
【請求項4】
前記通信パスが、少なくとも1つのデータ接続を含み、前記トリガメッセージが、第1のタイプの前記少なくとも1つのデータ接続を示す接続情報を更に含むことを特徴とする請求項1〜3のいずれか一項に記載の方法。
【請求項5】
前記接続情報を含む前記トリガメッセージが、前記少なくとも1つの端末に伝送される前に、前記サーバーで生成されて第1の中間ネットワークノードに伝送され、前記方法が、
前記第1のタイプの前記少なくとも1つのデータ接続が前記少なくとも1つの端末によりサポートされ、及び/又は、前記少なくとも1つの端末のために許可されているかを判断するステップと、
肯定的な判断のときに、前記トリガメッセージを前記第1の中間ネットワークノードから前記少なくとも1つの端末に伝送するステップとを有することを特徴とする請求項4に記載の方法。
【請求項6】
否定的な判断のときに、前記第1のタイプの前記少なくとも1つのデータ接続を示す情報を、前記少なくとも1つの端末によりサポートされ、前記少なくとも1つの端末のために許可されている第2のタイプの少なくとも1つのデータ接続を示す情報で置き換えることで前記トリガメッセージを更新するステップと、
前記トリガメッセージが更新された後で、前記トリガメッセージを前記第1の中間ネットワークノードから前記少なくとも1つの端末に伝送するステップとを更に有することを特徴とする請求項5に記載の方法。
【請求項7】
前記トリガメッセージが前記第1の中間ネットワークノードから前記少なくとも1つの端末に第2の中間ネットワークノードを介して伝送され、任意的に、前記第1の中間ネットワークノードがコントロールプレーンのゲートウェイを有し、前記第2の中間ネットワークノードがユーザープレーンのゲートウェイを有することを特徴とする請求項5又は6に記載の方法。
【請求項8】
請求項1〜4のいずれか一項に記載の方法を実行するように構成された手段を有するサーバー。
【請求項9】
サーバー及び少なくとも1つの端末に通信的に接続され、請求項1〜7のいずれか一項に記載の方法を実行するように構成された手段を有することを特徴とする第1の中間ネットワークノード。
【請求項10】
前記第1の中間ネットワークノードがコントロールプレーンのゲートウェイ又はユーザープレーンのゲートウェイであることを特徴とする請求項9に記載の第1の中間ネットワークノード。
【請求項11】
端末が当該端末とサーバーの間の通信パスを確立する方法であって、前記方法が、
前記端末と前記サーバーの間の前記通信パスがいつ確立されるべきかを示すタイミング情報を含むトリガメッセージを受信するステップと、
前記タイミング情報に従って前記端末と前記サーバーの間の前記通信パスを確立するステップとを有することを特徴とする方法。
【請求項12】
前記タイミング情報が、時間遅延、時間ウィンドウ及び前記端末と前記サーバーの間の前記通信パスを確立する時間をランダムに選択する指示の1以上を含むことを特徴とする請求項11に記載の方法。
【請求項13】
前記端末と前記サーバーの間の前記通信パスが、少なくとも1つのデータ接続を含み、
前記トリガメッセージが第1のタイプの前記少なくとも1つのデータ接続を示す接続情報を更に含み、
前記端末と前記サーバーの間の前記通信パスが前記接続情報に従って確立されることを特徴とする請求項11又は12に記載の方法。
【請求項14】
請求項11〜13のいずれか一項に記載の方法を実行するように構成された手段を有する端末。
【請求項15】
請求項14に記載の端末と、請求項8に記載のサーバーを有するシステム。
【請求項16】
プロセッサーにより実行されたときに、請求項1〜7及び請求項11〜13のいずれか一項に記載のステップを実行するように構成されたソフトウェアコード部分を有するコンピュータプログラム。
【図1】
【図2A】
【図2B】
【図2C】
【図2D】
【図2E】
【図2F】
【図3】
【図6】
【図4】
【図5】
【図7】
【図8】
【図2A】
【図2B】
【図2C】
【図2D】
【図2E】
【図2F】
【図3】
【図6】
【図4】
【図5】
【図7】
【図8】
【公開番号】特開2013−17180(P2013−17180A)
【公開日】平成25年1月24日(2013.1.24)
【国際特許分類】
【外国語出願】
【出願番号】特願2012−150026(P2012−150026)
【出願日】平成24年7月3日(2012.7.3)
【公序良俗違反の表示】
(特許庁注:以下のものは登録商標)
1.GSM
2.フロッピー
【出願人】(500098057)コニンクリジケ ケーピーエヌ エヌブィー (9)
【出願人】(595115802)
【氏名又は名称原語表記】Nederlandse Organisatie voor toegepast−natuurwetenschappelijk onderzoek TNO
【Fターム(参考)】
【公開日】平成25年1月24日(2013.1.24)
【国際特許分類】
【出願番号】特願2012−150026(P2012−150026)
【出願日】平成24年7月3日(2012.7.3)
【公序良俗違反の表示】
(特許庁注:以下のものは登録商標)
1.GSM
2.フロッピー
【出願人】(500098057)コニンクリジケ ケーピーエヌ エヌブィー (9)
【出願人】(595115802)
【氏名又は名称原語表記】Nederlandse Organisatie voor toegepast−natuurwetenschappelijk onderzoek TNO
【Fターム(参考)】
[ Back to top ]