本文書においては、「モバイルノード」などの用語は、通信ネットワーク内の物理エンティティを表す。1つのノードがいくつかの機能エンティティを有することができる。機能エンティティとは、所定の一連の機能を実施する、もしくは、ノードまたはネットワークの別の機能エンティティに所定の一連の機能を提供する、またはその両方であるソフトウェアモジュールまたはハードウェアモジュールを意味する。ノードは、自身を通信設備または通信媒体にアタッチする1つまたは複数のインタフェースを有することができ、ノードはこれら通信設備または通信媒体を通じて通信することができる。同様に、ネットワークエンティティは、機能エンティティを通信設備または通信媒体にアタッチする論理インタフェースを有することができ、ネットワークエンティティはこれら通信設備または通信媒体を通じて他の機能エンティティや通信先ノードと通信することができる。
本明細書において、用語「サーバ」または「トリガリングサーバ」は、ネットワーク内、あるいは外部ネットワークまたは外部ノード内に存在するエンティティを意味する。「サーバ」または「トリガリングサーバ」は、例えば、(MTC)端末または複数の端末から自動的にデータを収集し、トリガリング要求を端末に送ることのできるサーバとすることができる。トリガリング要求は、端末に伝えられるメッセージまたはインジケータであり、測定データ、サーバに送信されるデータ、自身の識別情報を示すためのシグナリングデータ、あるいは(本発明によって提供されるように)実際のデータが送られる、送られない、または遅延して送られることを示すためのシグナリングデータなどのデータを提供する目的で、端末がネットワークもしくはサーバまたはその両方との接続を確立するべきであることを示す。なお、サーバを別の端末によって実施することもできる。例えば、第1の端末を、第2の端末をトリガーするように構成することができる。このように構成することは、例えば、(場合によってはユーザが操作する)端末が別のMTC端末からデータを収集するときに有利であり得る。背景技術のセクションにおいて説明したように、端末は、LTE端末、UMTS端末、またはGSM/GPRS/EDGE端末とすることができる。トリガリング要求は、さまざまな手段を介して送信することができ、そのうちの3つの例について図2を参照しながら説明した。しかしながら、本発明はこれらに制限されず、任意の別のネットワーク、もしくは、ネットワーク内の任意の別のメカニズム、またはその両方を採用することもできる。
一般にMTC端末によって提供される少量のデータは、小さなデータの塊と理解することができ、小さなIPパケット、SMS、または何らかの別のアプリケーション固有データとすることができる。データの量は、例えばSMSの中に収まるとき、十分に小さいとみなすことができる。したがって、少量のデータは、140バイト(SMSの現在のペイロードサイズ)より小さい。したがって、本発明の意味においては、少量のデータはSMSと理解することもできる。しかしながら、本発明はこれに制限されず、トリガリング後に端末によって提供されるデータが大量の情報を含んでいることもできる。
用語「加入している」は、ユーザ機器がネットワークに加入しているとき、少なくとも、ネットワークに接続するようにユーザ機器をトリガーするための十分な情報をネットワークが認識していることと理解することができる。特に、この情報はユーザ機器の識別情報(IMSIなど)とすることができる。さらには、ユーザ機器の効率的な「探索」を行うことができるようにする目的で、ネットワークはユーザ機器のおよその位置を認識していることができる。ユーザ機器がIDLE(アイドル)モードにある場合、ネットワークは、ユーザ機器のページングを可能にするため、コアネットワークにおける格納されたコンテキストデータ(IMSI、可能なトラッキングエリア、ベアラコンテキスト(EPS)を含む)を有することができる。
ユーザプレーンと制御プレーンとの区別に関して、データベアラはユーザプレーンに関連付けられており、ユーザプレーンの一部である。データベアラは、ユーザデータを伝送するために確立される。これとは異なり、制御プレーンおよびシグナリングベアラは、一般的には制御シグナリングの伝送を目的とする。
本発明は、トリガーに応えて端末デバイスからトリガリング開始エンティティに送信されるアップリンクデータが遅延する、または配信されないことを、トリガリング開始エンティティに示すことを可能にするデバイストリガリング手順に関する。
なお、一般的には、トリガー要求を送るトリガリング開始デバイスは、トリガーされた端末がデータを送信する先のデバイスに必ずしも一致しない。トリガリングデバイスと受信デバイスは、位置もしくは実装またはその両方が異なっている異なるエンティティとすることができる。しかしながら、以下の例においては、トリガリングサーバ(またはMTCサーバ)などのトリガリングエンティティが、トリガー要求に応えて端末から送られるデータを受信するものと想定する。
トリガー開始エンティティは、トリガー要求の発行元であるエンティティである。さらに、トリガリング開始エンティティにおいて発行されたトリガー要求は、ネットワークまたは複数のネットワークを通じてさまざまな方法で送信することができる。例えば、トリガー要求を、ネットワークに対して透過的に(不透明に)端末に送ることができる。すなわち、ネットワークはトリガーインジケータを利用することなく、トリガーインジケータをトリガー開始エンティティからの「ユーザデータ」として、トリガーされるデバイス(端末)に送信するのみである。これに代えて、トリガー要求の少なくとも一部分を制御シグナリングとして送信して、任意のネットワークノードによって解釈もしくは処理またはその両方を行うことができ、そのネットワークノードは、端末がトリガーされたことを端末に通知するための必要なステップをさらに行うことができる。
トリガリングサーバは、トリガーされたデバイスからのデータを自動的に収集するMTCサーバであることが有利である。この意味において、「自動的に」とは、ユーザの直接的な入力なしに、を意味する。例えば、MTCサーバにおけるアプリケーションは、事前定義された時間期間ごとにトリガー要求の送信を制御する。アプリケーションは人間のユーザによって設定することができるが、それぞれのトリガー要求はアプリケーションによって自動的に生成および送信される。
本発明は、ネットワークにおいて輻輳制御メカニズムが有効にされており、したがって、トリガーされたデバイスがネットワークとの接続を確立できない、もしくはアップリンクデータをトリガリングサーバに送ることができない、またはその両方である状況において、トリガリングサーバからデバイスをトリガーする方法を提供する。
このシナリオにおいては、現在のLTEネットワークアーキテクチャではいくつかの問題が発生することがあり、場合によってはリソースの利用効率が低下する。しかしながら、これらの問題点は必ずしもLTEアーキテクチャに限定されない。トリガリングデバイスがトリガーされるデバイスにトリガー要求を送り、トリガーされたデバイスがネットワークの輻輳のためにトリガー要求に応えることができないトリガリング手順を提供する任意の通信システムにおいても、これらの問題は発生しうる。
背景技術のセクションにおいて、既存の技術において発生する問題点を説明する目的で、開発下にある現在のLTEシステムのメカニズムについて簡単に紹介した。特に、デバイストリガー要求がMTCサーバから送られると、ネットワークは、ユーザ機器が登録されているSGSN/MMEにこの要求を転送する。SGSN/MMEは、ユーザ機器をページングし、NAS MM接続を確立した後、デバイストリガー要求をユーザ機器に配信する。
GERAN/UTRANアクセスの場合、ユーザ機器がアップリンクデータを送ろうとしているAPNに、APNベースの輻輳制御が適用されていると、ユーザ機器はそのAPNへのPDPコンテキストを確立またはアクティブにすることが許可されない。したがって、デバイストリガー要求を伝えるMT−SMSが端末によって正常に受信され、正常に受信されたことがMTCサーバに報告されたが、このAPNへのユーザプレーンベアラを確立することができず、ユーザ機器はアップリンクデータを送信することができない。したがって、このシナリオにおいては、ネットワークは、デバイストリガー要求が正常に配信されたことをMTCサーバに報告し、MTCサーバは、ユーザ機器のデータ報告(すなわちアップリンク(UL)データまたはユーザ機器からMTCサーバへの接続の開始)を受信することを予測する。
MTCサーバは、デバイストリガーが肯定応答された後にユーザ機器からのデータを受信しない場合、ユーザ機器をもう一度トリガーすることができる。しかしながら、たとえ第2のデバイストリガーの後も、例えばユーザ機器においてSM−BOタイマーが依然として作動しているために、ユーザ機器が依然としてデータを報告できないことがある。したがって、本発明の基礎をなす課題の1つは、MTCサーバからユーザ機器への不必要な複数のトリガリングを回避することである。
ユーザ機器がEPSシステムにアタッチされているとき、すなわちE−UTRANアクセスを介してネットワークに接続されているときにも、類似する問題が発生することがある。GERAN/UTRANアクセスの場合との違いとして、既存のPDN接続の場合、またはベアラ修正手順が要求されないEPSベアラの場合、ユーザ機器はアップリンクデータを送ることができる。しかしながら、デバイストリガーの結果として新しいEPSベアラまたは修正されたEPSベアラが必要となる場合、ユーザ機器は新しいベアラの確立、または既存のベアラの修正を行うことができない。したがって、ユーザ機器は、アップリンクデータをMTCサーバに送ることができない、またはMTCサーバとの接続を確立することができない。
一般的には、ユーザ機器は、SM−BOタイマーが作動している限りは、新しいベアラの確立または既存のベアラの修正(すなわちあらゆるセッション管理手順)を行うことができず、結果として、ユーザ機器はアップリンクデータをMTCサーバに送ることもできない。
さらに、デバイストリガリング手順において、ネットワークは、端末がどの外部ネットワークにアップリンクデータを送るかを判定できないことがある。外部ネットワークは、3GPPの術語ではいわゆるアクセスポイントネーム(APN)に基づいて識別される。結果として、ネットワークは、そのAPNに対して輻輳制御が有効にされているかも認識できないことがある。したがって、ネットワークは、トリガーされたデバイスによってトリガー開始エンティティに送られる、結果としてのアップリンクデータに輻輳制御が適用されるかを判定できないことがある。一般的に、端末が特定の外部ネットワークとの接続を有していないときには、端末がどのネットワークとの接続を確立するかを判定することが不可能なことがある。
本発明が解決しようとしているさらなる問題点として、デバイストリガリングがSMSを通じて行われるとき、サービングネットワークノード(SGSN/MME)は、「通常の」MT−SMSと「DTに関連する」MT−SMSとを区別することができない。SGSN/MMEは、受信されたMT−SMSに何らかの特定の処理を適用するかを認識しない。1つの可能なオプションは、SGSN/MMEが、SM輻輳したAPNに加入しているすべてのユーザ機器へのすべてのMT−SMSを拒否することである。さらには、ユーザ機器が複数のAPNに加入しているが、SM CCが1つのみのAPNに適用されている場合、非特許文献2のセクション6.59に記載されている従来技術の「MTC−IWFによる過負荷制御」メカニズムを適用するネットワーク(MTC−IWFまたはSGSN/MME)によって、すべてのデバイストリガー要求がブロックされる。この場合、用語「通常の」MT−SMSとは、デバイストリガリング(DT)とは異なる目的のMT−SMS、例えば自動的に生成されるトリガー要求ではなくユーザデータを有するMT−SMSを意味する。
上に要約した問題点のいくつかを解決する目的で、本発明は、SGSN/MMEが、デバイストリガー要求メッセージの内部処理に基づいて、MTCサーバへのデバイストリガー配信報告(後からも説明されるように、「アップリンクデータ配信の指示情報」または他の何らかの指示情報を含んでいてもよい)を生成できるものと考える。この内部処理は、APNベースのSM CC、ユーザ機器の能力、加入しているAPNまたはデバイストリガーに関連するAPN、格納されているPDP/PDNコンテキスト、またはユーザ機器あるいはネットワークエンティティからの他のデータまたは明示的なシグナリングについての情報に基づくことが好ましい。特に、サービングネットワークノードエンティティ(モバイル管理エンティティ)に、デバイストリガー要求メッセージの内部処理をサポートする情報を提供することを考える。このような情報は、デバイストリガリングのSMSと、他の目的のSMSとを区別することを可能にする情報、もしくは、端末がトリガー要求メッセージの受信後に接続の確立を試みるAPNの識別を可能にする情報、またはその両方を可能にする情報とすることができる。
サービングネットワークノードは、提供される情報と内部処理とに従って、デバイストリガー要求メッセージ(例えばSMS)を端末に配信しないことと、デバイストリガー要求メッセージが端末(ユーザ機器)に配信されないことを示す指示情報を送信側エンティティ(MTC−IWF、SM−SC、またはMTCサーバ)に発行することとを決定することができる。オプションとして、デバイストリガー要求の再送信が望ましくない、もしくは、新しいデバイストリガー要求メッセージを送信するべきではない、またはその両方である時間期間について、MTCサーバに通知するタイマーを示すことができる。本発明のこの実施形態については、後から詳しく説明する。
本発明は、さらに解決策を提供し、この解決策によると、指示情報がサーバに送られる。特に、3GPPシステムに関しては、ネットワークにおけるAPNベースのセッション管理輻輳制御(SM CC)の場合に、指示情報がMTCサーバに送られる。このインジケータは、デバイストリガリングの結果としてのアップリンクデータが配信されるか、遅延するか、またはその両方を示すことが好ましい。結果としてのデータは、例えば、測定データ(トリガーされたときに端末が収集して送信する)とすることができる。これに代えて、データは、外部から、または内部的に(すなわちネットワーク内で)端末を一意に識別することを可能にする端末識別情報(例:IPアドレス)とすることができる。通常のトリガー配信報告に加えて、またはこれに代えて、指示情報(「アップリンクデータ配信の指示情報」と称することができる)がMTCサーバに送られる。アップリンクデータ配信の指示情報は、端末において、またはネットワーク内で、例えばSGSNやMMEなどのサービングコアネットワーク(CN)ノードにおいて、SM−BOタイマーの持続時間もしくはアップリンクデータの推定される有効性またはその両方に基づいて求められる。
デバイス(端末)またはネットワークノード(SGSN/MME)が、有効にされている輻輳制御の持続時間を認識している場合、デバイスまたはネットワークは、輻輳が低減/抑制された後にアップリンクデータが有効であるかを判定することができる。特に、端末またはネットワークは、トリガー要求が到着したときに端末において作動しているバックオフタイマーの情報を有することができる。バックオフ時間とは、端末がネットワークとの接続の確立を試みることを控える、またはサーバにデータを送信することを控える時間期間である。バックオフ状態の持続時間が既知であるとき、端末またはネットワークノードは、アップリンクデータが配信されないこと、配信されること、または推定される配信遅延、のうちの少なくとも1つをサーバに示すことができる。
デバイストリガー要求が受信されたときにデバイスにおいて作動中のBOタイマーが存在しない場合、本発明の実施形態は、別の解決策を考える。特に、端末またはネットワーク(例:SGSN/MMEまたはMTC−IWF)は、デバイスがユーザプレーン(U−プレーン)接続の確立または修正のためのシグナリングを開始した後に、アップリンクデータのターゲットAPNを求め、輻輳制御を適用するかを判定することができる。デバイスまたはネットワーク(例:SGSN/MMEまたはMTC−IWF)は、このような判定に基づいて、アップリンクデータの配信または遅延についての指示情報をMTCサーバに送る。
MTCサーバは、SM−BOが作動している間にアップリンクデータ配信の指示情報を受信した後、本発明の実施形態によると、以下の動作の少なくとも1つを決定することができる。
− SM−BOタイマーが切れた後にデバイストリガー要求を再送信する。または、
− 新しいデバイストリガーをただちに送る。結果としてユーザ機器は、アップリンクデータを異なる(輻輳していない)APNに送る。または、
− 新しいデバイストリガーを高い優先度でただちに送る。これにより、デバイストリガリングの結果としての接続の確立にセッション管理輻輳制御を適用しないようにネットワークに指示される。または、
− 遅延するアップリンクデータの受信を待機する。
アップリンクデータ配信の指示情報は、ネットワーク(例:SGSN/MMEまたはMTC−IWF)またはユーザ機器のいずれかからMTCサーバに送ることができる。ユーザ機器は、ユーザプレーン接続を確立できないため、指示情報をメッセージ(例:小さなデータ)として制御プレーンを通じてMTCサーバに送ることができる。
要約すると、本発明の特有の方法によると、ネットワーク輻輳の場合にデータが遅れて配信される、またはまったく配信されないことをサーバに通知するため、本発明は、端末において実行される方法と、ネットワークノードにおいて実行される方法と、トリガリングサーバおよび対応する装置(端末、ネットワークノード、およびトリガリングサーバ)において実行される方法とを提供する。
上に説明した問題点を解決する目的で、すなわちデバイストリガー要求の再送信を回避する目的で、デバイストリガリングの結果としてのアップリンクデータの配信/非配信/遅延についてMTCサーバに通知することを提案する。MTCサーバは、受信された指示情報および内部状態に基づいて、どのオプションを実行するかを決定する。
トリガリングサーバへの指示情報の提供を容易にする目的で、端末またはネットワークノードは、端末からサーバへの接続を確立できるか否かの評価を行うことができ、この場合、ネットワークが輻輳しているかと、バックオフタイマーが作動しているかと、端末におけるバックオフタイマーの残り時間、のうちの少なくとも1つを判定する。次いで、トリガー後にサーバとの接続を確立できないこと、データを送信できないこと、データが遅延して送信されること、のうちの少なくとも1つを示す配信遅延メッセージをサーバに送信する。
これに対して、トリガリングサーバは、端末またはネットワークノードによって提供される配信遅延インジケータを受信し、配信遅延インジケータの処理を実行し、トリガー要求を後の時点で再送信するのか、またはトリガー要求を高い優先度で、または異なるAPNを対象に再送信するのか、または同じネットワークについては別の端末へのトリガー要求の送信を省くのかを決定することができる。
配信遅延指示情報は、端末からのアップリンクデータが遅れて配信されることを示すことができる。したがって、このインジケータは、「アップリンクデータは遅れて配信される」という値を有することができる。オプションとして、遅延の理由を、情報要素「理由」としてシグナリングすることができる。遅延の理由は、例えば、ネットワークの輻輳や、報告されるデータが利用可能ではないこととすることができる。さらなるオプションとして、アップリンクデータの遅延時間の推定値を、情報要素「アップリンクデータの遅延時間」として提供することができる。この遅延は、例えば、SM−BOタイマーなどの作動中のバックオフタイマーに基づいて、例えば作動中のSM−BOタイマーの残りの値として、求めることができる。
MTCサーバは、配信遅延インジケータに応えて、予測されるアップリンクデータの緊急性(または有効性)に応じてその次のステップを決定することができる。例えば以下のとおりである。
MTCサーバは、示された遅延時間の後、遅延したデータが有効であるかを評価することができる。示された遅延時間の後にアップリンクデータがMTCサーバにおいて有効である場合、MTCサーバは何らの動作も実行する必要がなく、遅延したアップリンクデータを待機することができる。これに対して、示された遅延時間の後にアップリンクデータがMTCサーバにおいて有効ではない状況が起こりうる。このケースは、例えば、アップリンクデータが遅れて配信されることをユーザ機器またはネットワークが示したが、示された遅延の経過後に配信されたときにアップリンクデータがMTCサーバにおいて利用するには有用または有効ではないものとMTCサーバが推定するときに起こりうる。この場合、MTCサーバは以下を行うことができる。
− 新しいデバイストリガリングの結果としてのアップリンクデータが配信される代替APNをMTCサーバが使用できる場合、またはオプションとしてデバイストリガリング手順の優先度が高い場合、MTCサーバは、遅延時間が切れる前に新しいデバイストリガー要求を送る。
− それ以外の場合、MTCサーバは、遅延時間が切れるのを待って、新しいデバイストリガー要求を送る。
あるいは、配信遅延インジケータは、データが配信されないことを示すことができる。オプションとして、前のケースと同様に、アップリンクデータが配信されない「理由」をシグナリングすることができ、この理由としては、ネットワークの輻輳や、端末においてデータが利用可能ではないことである。さらなるオプションとして、例えばSM−BOタイマーに基づく「輻輳の持続時間」をインジケータに含めることができる。MTCサーバは、予測されるアップリンクデータの緊急性(または有効性)に応じてその次のステップを決定する。例えば、前のケースと同様に、以下のとおりである。
− 新しいデバイストリガリングの結果としてのアップリンクデータが配信される代替APNをMTCサーバが使用できる場合、またはオプションとしてデバイストリガリング手順の優先度が高い場合、MTCサーバは、遅延時間が切れる前に新しいデバイストリガー要求を送る。
− それ以外の場合、MTCサーバは、遅延時間が切れるのを待って、新しいデバイストリガー要求を送る。
一般的には、トリガリングサーバによって実行される本方法では、受信されたインジケータを評価することによって、もしくは、輻輳しない別のネットワークを端末が使用できるかを評価することによって、またはその両方によって、処理ステップを実行する。サーバの処理ユニットは、このような評価を行うように構成することができる。
遅延を示すことを目的として、SM−BOタイマーの(残りの)値をシグナリングすることができる。なお、現段階のLTEによると、ネットワークからユーザ機器に送信されるSM拒否メッセージの中にSM−BOタイマーを含めるかはオプションである。したがって、デバイストリガリング要求の後にPDP/PDN接続を確立または修正するためのユーザ機器のシグナリングが、SM−BOタイマーの提供なしに拒否されることがある。このような場合、サービングコアネットワークノード(SGSN/MME)も、SM CCの持続時間を認識していないことがあり、したがって遅延をMTCサーバに示すことができない。結果として、MTCサーバへの指示情報には、アップリンクデータが配信されないことについての情報、またはMTCサーバとの接続を確立することができないことについての情報が含まれる。
MTCサーバに送られる指示情報の決定は、ネットワークにおいて(SGSNまたはMMEによって)、またはユーザ機器において行われる。この理由は、デバイストリガリング手順が制御プレーンを通じて実行されるものと想定されるためである。しかしながら、デバイストリガリング手順がユーザプレーンを通じて実行される場合、ユーザプレーンのネットワークエンティティが、MTCサーバへの指示情報を決定、生成して送ることが可能である。
MTCサーバは、アップリンクデータの配信/有効性(SM−BOタイマー)の指示情報を受信した後、異なるAPNを示す新しいデバイストリガー要求をユーザ機器に送ることを決定することができる。このAPNは、データを送るためのバックアップAPNとして使用することができる。この目的のため、MTCサーバは、ユーザ機器に対して異なる外部IDを使用することができる。異なる外部IDを使用することの利点として、後から説明するように、外部IDは、アップリンクデータを送るためにユーザ機器によって使用されるAPNを直接または間接的に符号化することができる。
さらに、MTCサーバは、アップリンクデータの配信/有効性(SM−BOタイマー)のインジケータを、以下のポリシーの1つの適用を開始するための指示情報として使用することができる。
− 同じユーザ機器、または特定のAPNに属しているすべてのユーザ機器、または同じグループまたはAPNの複数のユーザ機器の一部に対して、さらなるデバイストリガー要求を送ることを省く。
− 特定のグループまたはAPNに属しているユーザ機器へのデバイストリガー要求の送信レートを下げる。
これらのポリシーは、ユーザ機器の優先度やデータの緊急性などに従って、いくつかのユーザ機器に選択的に適用することができる。MTCサーバは、ユーザ機器がデータ接続を確立/アクティブにしているAPNについて認識していないことがある。したがって、特定のMTCアプリケーションのメンバーまたは特定の加入のメンバーによって、ユーザ機器のグループを形成することができる。
上のポリシーの1つを適用する期間は、アップリンクデータ配信/有効性(SM−BOタイマー)のインジケータにオプションとして含まれる「データ送信遅延」(またはSM−BOタイマー)とすることができる。なお、この場合のオプション性は、標準的なオプション性、すなわち、ユーザ機器またはネットワークノードが、データ配信遅延をMTCに示すか否かをこれらが決定できること、または、ユーザ機器またはネットワークが、事前定義された条件(例えばSM−BOが既知である、もしくは作動中である、またはその両方である)下でのみデータ配信遅延を送ること、と理解することができる。しかしながら、端末もしくはネットワークまたはその両方が遅延の推定値をつねに提供できるようにシステムが構成されているときには、配信遅延を示すことを必須とすることもできる。
これに代えて、またはこれに加えて、新しいデバイストリガー要求を、元々の最初の(または前の)デバイストリガー要求よりも高い優先度で送ることができる。このことは、MTCサービスプロバイダが、デバイストリガー要求の配信もしくは結果としてのアップリンクデータまたはその両方に、より高い価格を支払うことを意味しうる。しかしながら、たとえユーザ機器がPDP/PDN接続要求に高い優先度を使用する場合でも、要求は依然として同じAPNを対象とする。APNベースのSM CCでは、輻輳したターゲットAPNにSM要求メッセージを送ることは許可されないため、3GPPシステムの現在のリリースでは、この解決策は単独では機能することができない。しかしながら、今後のリリース、あるいは輻輳制御メカニズムにおいて優先度が考慮されるシステムでは、この解決策は依然として採用可能である。なお、デバイストリガー要求の優先度は、以下のように使用できることに留意されたい。
− ネットワークにおける配信メカニズムにおいて使用する。例えばネットワークがある程度(モビリティ管理:MM)輻輳しており、トリガー要求を配信するか否かを決定するときに使用する。または、
− ユーザ機器によって使用する。例えば、デバイストリガー要求の不透明な(ネットワークに対して透過的な)データ部分に優先度が含まれているときに使用する。この場合、ユーザ機器は、MTCサーバからのトリガー情報を処理し、より高い優先度を有するPDP/PDN接続要求を生成することができる。
しかしながら、反復されるデバイストリガー要求の高い優先度は、一般的に、SGSN/MMEまたはネットワークにおいて、図5〜図7にも示した次の方法において使用することもできる。
− デバイストリガリング要求(図5〜図7における「デバイストリガー配信」を参照)の後、ユーザ機器において作動しているSM−BOタイマーが存在しない場合、ユーザ機器はPDP/PDN接続要求(「新しいPDP/PDN要求」を参照)を送る。この場合、ネットワーク(例えばSGSN/MME)は、デバイストリガー要求の高い優先度の指示情報を格納しているはずであり、高い優先度を適用することができ、したがってネットワークはユーザ機器からのPDP/PDN接続要求を拒否しない。
− デバイストリガリング要求の後、ユーザ機器において作動しているSM−BOタイマーが存在する場合、ユーザ機器は、図8を参照しながら後から説明する内部処理を実行する。次いで、ユーザ機器は、アップリンクデータの配信/有効性(SM−BOタイマー)の指示情報をSGSN/MMEに送ることを決定する(図8における「1)アップリンクデータの有効性+2)SM−BO」を参照)。SGSN/MMEは、ユーザ機器におけるSM−BOタイマーを削除することを決定する目的で、デバイストリガー要求の高い優先度を適用することができる(図8における「SM DLメッセージ(SM−BOを削除)」を参照)。
以下では、デバイストリガー要求がネットワークに格納される実施形態について説明する。
SM輻輳制御が有効であり得るにもかかわらず、SGSN/MMEがユーザ機器をページングしてデバイストリガー要求を配信する主な理由は2つある。この状況が起こり得るのは、SGSN/MMEにデバイストリガー要求が到着したときに、SGSN/MMEがAPNベースのSM CCについて認識していないことがあるためである。1つの理由として、ユーザ機器からのSM要求がSM−BOタイマーを伴って拒否されたときに(図7における「PDP/ベアラの拒否(SM−BO)」を参照)、SGSN/MMEはSM−BOタイマーを格納しないことがある。もう1つの理由として、ユーザ機器がデバイストリガーの受信後にアップリンクデータを送るAPNが、SGSN/MMEにおいて認識されていないことがある。
SM−CCステータス情報の可用性の問題を解決するため、ネットワーク(SGSN/MME)は、ユーザ機器がデバイストリガーの受信後にアップリンクデータを送るAPNを解決することができる。
APNを解決する方法の一例は、事前設定に基づく。MTCサーバから送信されるデバイストリガーにおいて使用されるユーザ機器の外部識別子(ID)は、次の構造である。
<ドメイン><ローカルID>
用語<ドメイン>は、ユーザ機器のHPLMNおよびMTC−IWFを識別するためにMTCサーバによって使用される。用語<ローカルID>は、ユーザ機器の加入と内部ID(例:IMSI)を識別するためにMTC−IWFによって使用される。用語<ローカルID>は、ユーザ機器がデバイストリガー要求を受信した後にアップリンクデータを送るAPN(以下では「ターゲットAPN」と称する)を、ネットワーク/MTC−IWFが事前設定に基づいて識別することができるような構造とすることができる。
ネットワーク(例:SGSN/MME)は、ターゲットAPNを求めた後、そのターゲットAPNが輻輳制御下にあるかを判定する。APNの輻輳制御ステータスを求める目的には、以下にリストするいくつかの動作をネットワークによって実行することができる。
解決されたターゲットAPNに対してMM輻輳制御が有効にされている場合、SGSN/MMEはユーザ機器へのページング手順を開始するべきではなく、代わりに、MM輻輳についてSM−SCまたはMTC−IWFに報告し、配信されないデバイストリガー要求についても報告する。MTC−IWF/SM−SCは、配信されないデバイストリガー要求についてと、オプションとしてその理由(例:MM輻輳)についてと、オプションとしてMM輻輳の残りの持続時間(例:MMバックオフタイマー)についてと、をMTCサーバに通知する。
解決されたターゲットAPNに対してSM輻輳制御が有効にされており、ユーザ機器がE−UTRANアクセス下でキャンプしている(すなわちMMEに接続されている)場合、MMEは、ターゲットユーザ機器の格納されているSMコンテキストの内部チェックを実行することができる。
− MMEが、解決されたターゲットAPNへのEPSベアラコンテキストを格納している場合、このことは、ユーザ機器からのSMシグナリングなしにEPSベアラが自動的に確立されることを意味しうる。したがって、MMEはページング手順を開始して、ユーザ機器にデバイストリガーを送信することができる。通常では、サービス要求手順時にユーザプレーンベアラが確立され、ユーザ機器はアップリンクデータをMTCサーバに送信することができる。
− MMEが、解決されたターゲットAPNへのEPSベアラコンテキストを格納していない場合、このことは、ユーザ機器が、ターゲットAPNへのPDN接続要求手順(すなわちSMシグナリング)を開始することを意味する。MMEは、デバイストリガー要求を送信するためのページング手順を開始するべきではない。代わりに、MMEは、ネットワーク内に輻輳が存在しておりデバイストリガーが配信されないことを、SM−SC(T4インタフェースまたはTsmsインタフェースを通じてMT−SMSが使用される場合)またはMTC−IWF(T5インタフェースが使用される場合)に通知することができる。さらに、MMEは、デバイストリガー要求が配信されない理由/原因(例えばターゲットAPNにSM CCが適用されている)を通知することもできる。MTC−IWFは、この指示情報/情報をMTCサーバに転送することができる。
解決されたターゲットAPNに対してSM輻輳制御が有効にされており、ユーザ機器がGERAN/UTRANアクセス下でキャンプしている(すなわちSGSNに接続されている)場合、SGSNはデバイストリガー要求を送信しない。さらなる動作は、MMEがEPSベアラコンテキストを格納していない上記の場合に実行される動作と同じである。
図4は、SGSN/MMEがMT−SMSの形のデバイストリガー要求を受信したときにAPNベースのSM CCを解決できる場合におけるシグナリングフローの例を示している。通信の個々のステップは、参照数字(1)〜(9)によって表してある。SM−SCは、端末に送信されるトリガー要求をT4/Tsmsインタフェースを通じてMTCサーバから受信する。第1のステップ(1)において、SM−SCが、移動体着の対応する(MT)SMSをSGSNに配信する。MT−SMSはトリガー要求を含んでいる。APNは輻輳しているものと想定する。したがって、第2のステップ(2)において、SGSN(サービングネットワークノード)は、ネットワークが輻輳していること、特に、セッション管理または接続の確立を実行できないことを、SM−SCに報告する。これに応えて、SM−SCはMT−SMSを格納し、格納されたMT−SMSについてHSSに通知する(3)。SM−SCは、格納されているMT−SMSを配信する目的で、ユーザ機器が到達可能になった(すなわちSM CCが終了した)時点でSM−SCに通知するべきことをHSSに知らせるため、フラグ(例:待機フラグ)を使用することができる。輻輳の場合においてより効率的なシグナリングを可能にする目的で、既存の技術にステップ(4)およびステップ(5)を次のように追加する。ステップ(4)において、HSS/HLRは、輻輳が終了したときに報告するようにSGSNを設定する。したがって、SGSNは、輻輳が依然として存在しているかを監視し(5)、ステップ(6)において、輻輳が終了した時点でただちに(すなわち輻輳が終了したことをSGSNが検出した時点でただちに)HSSに報告する。HSS/HLRは、MT−SMSを送信するようにSM−SCをトリガーし(7)、SM−SCがMT−SMSをSGSNに配信する(8)。SGSNが端末をページングする(9)。
要約すると、上の方法では、輻輳状態において、輻輳したネットワークのサービングネットワークノード(例えばSGSNまたはMME)を、輻輳が終了したかをループ方式でチェックするように設定することが可能である。ネットワークノードにおいて輻輳が終了したと判定された時点でただちに、ネットワークノードは輻輳の終了を報告する。この設定は、端末の位置を解決することのできるネットワークエンティティによって実行されることが有利であり、報告もこのエンティティに行うことができる。このエンティティは、上の例のように、ホームロケーションレジスタまたは類似するエンティティとすることができる。今後のシステムにおいては最適化が可能であり、サービングネットワークノード(SGSN/MME)は、輻輳制御の終了についてSM−SCに直接示すことができる。図4において、実線のシグナリングラインは、ユーザ機器に到達できないためにMT−SMSを遅れて配信するための手順を示している。破線のシグナリングライン(ステップ4およびステップ5)は、デバイストリガー要求を格納する理由として(ユーザ機器に到達できないという通常の理由ではなく)SM CCが想定されるときに提供される新しい機能を示している。
デバイストリガー要求をネットワークに格納するという提案する解決策には、いくつかの問題点が依然として存在する。例えば、ユーザ機器が接続を確立するAPNをネットワークが解決できないことがある。特に、ネットワークは、外部IDもしくはMTCアプリケーションID(内部ID)またはその両方と、対応するAPNとの間のマッピングテーブルを維持する必要がない。
デバイストリガーをネットワーク(例:SM−SCネットワークノード)に格納することに起因して、コアネットワークにおいてかなり多くのシグナリング(HSSインタラクションを含む)が発生する(図4を参照)。ネットワーク内に数多くのユーザ機器が存在しうることを考えれば、シグナリングが増大すること自体によって、輻輳の確率が増大したり、輻輳につながることがある。
すでに上述したように、ターゲットAPNに対してSM輻輳制御が有効であるかをSGSNが認識していないことがある。SM CCは、PDPコンテキスト/EPSベアラ要求の拒否(図5における「PDP/ベアラ拒否(SM−BO)」を参照)時に、SGW/PGW/GGSNによって有効にすることができ、この拒否は少し前に起きたかもしれず、したがってSGSNがSM−BOタイマーをユーザ機器に渡したかもしれないが、SGSN自体はPDPコンテキスト(およびSM−BOタイマー)を格納する必要はない。あるいは、SGSN/MMEは、デバイストリガリング要求を受信した時点で、ターゲットAPNが輻輳していることを認識していないことがあり、なぜならSGSN/MMEが関連する情報を格納していないことがあるためである。要約すると以下のとおりである。SGSNは、デバイストリガー要求が受信されたときにAPN SM−CCが適用されていることを認識していないことがあり、これはユーザ機器の最初の拒否された(E)SM要求の場合に起こりうる。EPSセッション管理(ESM)情報要求がネットワークから端末に送られる。端末は、ESM情報応答によって応える。これらのメッセージは、EPSベアラコンテキストに関連する、ネットワークによって開始される手順に属し、ネットワークによって開始される(EPS)コンテキストをアクティブにする役割を果たす。
さらに、SGSNは、ユーザ機器がアップリンクデータをただちに送る/報告するかを必ずしも認識せず、なぜなら、ユーザ機器はデバイストリガー要求の受信後にアップリンクデータを収集するためのいくらかの時間を必要とすることがあるためである。背景技術のセクションで説明したように、ユーザ機器を対象とするデバイストリガー要求の中の情報は、ネットワークに対して不透明/透過的である。要約すると、デバイストリガー要求をネットワーク(例:SM−SC)に格納し、それを後から再送信することは最適ではなく、なぜなら、いずれにしてもユーザ機器は、アップリンクデータが利用可能となるまでに長い時間を必要とすることがあり、したがってアップリンクデータを後から送信しうるためである。留意すべき点として、ネットワークは、ユーザ機器における固有の処理(すなわちユーザ機器がアップリンクデータをただちに送るか、またはPDP/PDN接続をただちに確立するか、あるいは、MTCサーバに報告されるデータを測定/収集するための時間をユーザ機器が必要とするか)を認識していない。この情報または固有な処理は、デバイストリガー要求または特にデバイストリガー要求の不透明な(ネットワークに対して透過的な)部分の受信後にユーザ機器において判明するのみである。
要約すると、SGSN/MMEは、APNベースのSM CCを認識しておらず、さらには、データをMTCサーバに送る前にデータを収集/測定するためにユーザ機器において必要な遅延についても認識していない。以下では、これらの問題点も克服することが可能な、本発明の例示的な実施形態を提供する。以下に説明されている実施形態では、ユーザ機器がデバイストリガー要求を受信した時点でユーザ機器においてSM−BOタイマーが作動していない場合に、ユーザ機器にデバイストリガー要求を送信した後にAPNベースのSM CCを解決することが可能である。
一実施形態によると、トリガリングサーバがデバイストリガリング要求を端末に送信する通信ネットワークにおけるサービングネットワークノード(MME/SGSNなど)によって実行される方法であって、端末をトリガーするデバイストリガー要求をメッセージサーバから(または一般的にはトリガリングサーバからメッセージサーバを通じて)受信するステップと、デバイストリガー要求もしくは要求されるデータまたはその両方の配信に使用されるネットワークが輻輳制御下にあるかを判定し、輻輳状態をメッセージサーバに報告するステップと、輻輳が終了したかをチェックするステップと、輻輳が終了したと判定された時点で、終了したことを通信ネットワーク内のノードに報告するステップと、を含んでいる、前記方法、を提供する。
特に、報告するステップは、ホーム加入者サーバに向けて実行することができ、ホーム加入者サーバは、デバイストリガー要求をサービングネットワークノードに送信するようにメッセージサーバをトリガーすることができる。しかしながら、後から説明するように、サービングネットワークノードがメッセージサーバに直接報告することもできる。
メッセージサーバは、サービングネットワークノードから輻輳インジケータを受信した時点で、ネットワークが輻輳状態にあることをホーム加入者サーバ(HLR/HSS)に通知することができる。ホーム加入者サーバは、輻輳が終了することを自身が待機していることを示す内部フラグをセットすることができる。輻輳が終了した時点で、ホーム加入者サーバは、輻輳の終了について通知するメッセージをサービングネットワークノードから受信することができる。ホーム加入者サーバは、このメッセージを受信した時点で、格納されているデバイストリガーメッセージを送信するようにメッセージサーバに指示することができる。
以下では、上にリストした問題点のいくつかを回避するための可能な最適化について説明する。最初に、SGSN/MMEが、有効にされているAPNベースのSM CCについて認識しているものと想定する。SGSN/MMEがユーザ機器ごとに(およびAPNごとに)SM−BOタイマーを格納するかとは無関係に、SGSN/MMEは、タイマーが切れていない限り、または、SM CCを停止させるさらなる指示が別のネットワークエンティティから到着しない限りは、APNベースのSM CCを適用する。したがって、デバイストリガー(DT)要求が受信されたときにAPN SM CCが適用されていることをSGSNが認識していない状況は、ユーザ機器の(E)SM要求が最初に拒否されるときにのみ起こりうるが、それ以降はこの問題が存在しないものと想定することができる。
上述したようにデバイストリガーをネットワークに格納することによる問題点としては、図4を参照しながら上述したように、これにより、HSSを含むコアネットワークにおいてシグナリングメッセージ量が増大する。この問題は、SGSN/MMEとSM−SCとの間のシグナリング交換を最適化することによって解決することができる。特に、SGSN/MMEは、T5を通じてのデバイストリガーメッセージまたはMT−SMSを拒否するとき、MM/SM−BOタイマーをMTC−IWFまたはSM−SCに含める。MTC−IWF(T4を使用する)またはSM−SCは、デバイストリガー有効時間とMM/SM−BOタイマーとを次のように比較することにより、後からのデバイストリガー配信のためにMT−SMSを格納するかを決定する。
− デバイストリガー有効時間>MM/SM−BOタイマーである場合、デバイストリガー/MT−SMSを格納する。
− デバイストリガー有効時間<MM/SM−BOタイマーである場合、(すでに上述したように)配信できないデバイストリガー要求もしくはMM/SM−BOタイマーまたはその両方をMTCサーバに報告する。
上に提案した最適化について分かりやすく説明するため、以下では2つの例を示す。最初の例は図12に示してあり、デバイストリガー要求は、MT−SMSの形で、T4インタフェースまたはTsmsインタフェースを通じてSM−SCに送られる。図12では、サービングネットワークノードとしてSGSNを示しているが、一般的にこのエンティティはMMEまたは他のサービングノードとすることもできる。さらに、図12は、図を簡潔にするため、SM−SCとサービングノード(SGSN)との間の直接的なインタフェースを示している。しかしながら、これらの間に別のネットワークエンティティが存在することもできる。MT−SMSを送信するステップと、MT−SMSを格納するまたは格納しないステップは、図には簡潔に記載されている。
第1のステップ(1)において、MT−SMSがサービングネットワークノード(SGSN/MME)に配信される。次いで、ステップ(2)において、サービングネットワークノードは、MM輻輳制御またはSM輻輳制御が適用されているかを判定するための内部チェックを実行する。さらに、ステップ(2)では、送信前にSGSN/MMEにおいてMT−SMSの処理を実行する。現在の技術によると、SGSN/MMEは、MT−SMSが「通常の」目的に使用されるのかデバイストリガー要求として使用されるのかをおそらく解決できないため、SGSN/MMEは、保守的な方法を選択し、ユーザ機器がデバイストリガーサービスに加入している、またはデバイストリガーサービスに対して設定されている場合、MT−SMSがデバイストリガー要求として使用されているものと想定することができる。しかしながら、将来的には、MT−SMSがデバイストリガー目的に使用されることをSGSN/MMEに示す情報を、MT−SMSメッセージが(好ましくは、SGSN/MMEに対して透過的であるMT−SMSヘッダの中に)含んでいることができる。さらには、SGSN/MMEがターゲットAPNを解決できないことがある。これが実際に起こる理由として、MTCアプリケーションの関連情報が、SGSN/MMEに対して透過的であるSMS本体に含まれているためである。この場合も、SGSN/MMEは保守的な方法を選択することができ、ユーザ機器が加入しているAPNの少なくとも1つが輻輳している場合、特にMM輻輳制御が適用されている場合、MT−SMSを拒否することを決定することができる。
ステップ(3)において、サービングノードは、MT−SMSを配信できないことを、端末へのメッセージを生成する責務を負うサーバ(SM−SCなど)に通知する。さらに、サービングネットワークノード(MME/SGSN)は、このメッセージにMM/SM−BOタイマーを添付することができる。サーバにMM/SM−BOタイマーを提供する利点として、その場合、サーバは、実行するべきさらなるステップについて決定することができる。サーバは、受信されたMM/SM−BOタイマーと、MT−SMSの有効時間とを比較することが好ましい。特に、(残りの)バックオフ時間(SM−BOまたはMM−BO)がMT−SMSメッセージの有効性よりも長い場合、メッセージを生成するサーバ(SM−SC)は、デバイストリガーを配信できないことを、MTCサーバ(トリガリングサーバであり、デバイストリガーの発行元であるサーバ)に通知する。さらに、メッセージを生成するサーバは、MTCサーバがデバイストリガーをただちに再送信することを回避する目的で、MM−BOもしくはSM−BOまたはその両方を添付し、それをMTCサーバに送ることができる(ステップ(5.1)を参照)。
これに対して、(残りの)バックオフ時間(SM−BOまたはMM−BO)がMT−SMSメッセージの有効性よりも短い場合、メッセージを生成するサーバ(SM−SC)は、MT−SMSを格納し、後からそれを再送信することができる(ステップ(5.2)を参照)。例えば、メッセージを生成するサーバ(エンティティ)は、バックオフタイマー(SMまたはMM)が切れた時点でただちに、格納されているMT−SMSをサービングネットワークノードに再送信することができる。
サービングネットワークノードは、(再)送信されたMT−SMSを受信した後、端末をページングし、端末にMT−SMSを配信することができる。
なお、上の方法は、MM輻輳のみに適用することができる、または、SM輻輳のみに適用することができる。しかしながら、上の方法をMM輻輳制御およびSM輻輳制御の両方に適用することもできる。
図13は、さらなる1つの例を示しており、この場合、デバイストリガー要求はT5インタフェースを通じてSGSN/MMEに配信される(ステップ(1)を参照)。ステップ(2)において、SGSN/MMEは、図12において上述したように、類似する処理をデバイストリガー要求に適用する。しかしながら、前の例との違いとして、サービングネットワークノード(SGSN/MME)は、受信されたダウンリンク(DL)メッセージの目的について、より確信を持つことができ、すなわち、SGSN/MMEは、このメッセージはT5インタフェースを通じて受信されたためデバイストリガー要求メッセージであると結論することができる。言い換えれば、T5インタフェースを通じてダウンリンクメッセージが受信されることは、そのメッセージがデバイストリガー目的に使用されることを示している。ターゲットAPNに関しては、SGSN/MMEは、(図12と同様に)ターゲットAPNを解決できないことがあり、なぜなら関連情報がデバイストリガー要求メッセージ本体内の、ネットワークに対して不透明な情報の中に含まれているためである。したがって、ユーザ機器が加入しているAPNの1つが現時点でMM輻輳制御下またはSM輻輳制御下にある場合、SGSN/MMEは、保守的な方法を選択して、デバイストリガー要求を拒否することを決定することが有利である。
サービングネットワークノードは、輻輳制御のためデバイストリガー要求を配信できないことをMTC−IWFに通知する(ステップ(3)を参照)。さらに、サービングネットワークノードは、この情報にバックオフタイマーを添付することができる。MTC−IWFは、受信されたバックオフ時間とデバイストリガーメッセージの有効時間とを比較する(ステップ(4)を参照)。特に、(残りの)バックオフ時間(SM−BOまたはMM−BO)がデバイストリガーメッセージの有効性よりも長い場合、MTC−IWFは、デバイストリガー要求を配信できないことをMTCサーバに通知する。さらに、MTCサーバがデバイストリガー要求をただちに再送信することを回避する目的で、MTC−IWFは、MM−BOもしくはSM−BOまたはその両方を添付して、それをMTCサーバに送ることができる(ステップ(5.1)を参照)。
これに対して、(残りの)バックオフ時間(SM−BOまたはMM−BO)がMT−SMSメッセージの有効性よりも短い場合、MTC−IWFは、デバイストリガー要求をT4インタフェースを通じてSM−SCに送信する。SM−SCは、デバイストリガー要求を格納する。SM−SCは、バックオフ時間が切れた後、デバイストリガー要求を端末に送信する。バックオフタイマーは、MTC−IWFからSM−SCにシグナリングすることができる、または、タイマーが切れた後にデバイストリガー要求を再送信するように、別の方法においてMTC−IWFからSM−SCに指示することができる。
以下では、ターゲットAPNを求めるためのSGSN/MMEにおけるさらなる処理オプションについて説明する。
重要な点として、図4、図12、および図13に示した例は、SGSN/MMEがMM輻輳制御およびSM輻輳制御の両方を適用するときにあてはまる。MM CC(輻輳制御)は、一般的なMMおよびAPNベースの輻輳制御のいずれのタイプとすることもできる。
一実施形態によると、サービングネットワークノードを含み、トリガリングサーバがトリガー要求を端末に送信する通信ネットワーク、における制御サーバにおいて実行される方法、を提供する。本方法は、端末をトリガーするデバイストリガリング要求をトリガリングサーバから受信するステップと、トリガー要求をデバイストリガリングメッセージにカプセル化するステップと、デバイストリガリングメッセージをサービングネットワークノードに送信するステップと、デバイストリガリングメッセージを配信できないという情報およびバックオフタイマーを、サービングネットワークノードから受信するステップと、バックオフ時間がデバイストリガリングメッセージの有効性よりも長いかを評価するステップと、バックオフ時間の方が長いとき、デバイストリガー要求を配信できないことの指示情報と、デバイストリガー要求がただちに再送信されることを抑制するためのバックオフタイマー(必要時)とを、トリガリングサーバに送信するステップと、を含んでいる。この場合、制御サーバは、メッセージサーバ、すなわち、デバイストリガー要求がカプセル化されて端末に提供されるメッセージを作成する通信ネットワークエンティティとすることができる。このエンティティは、例えばSM−SCとすることができる。しかしながら、上述したように、制御サーバは、MTC−IWFなどのデバイストリガー制御サーバとすることもでき、このサーバは、デバイストリガーメッセージを生成するサーバとトリガリングサーバとの間に、特にデバイストリガー機能のためのインタフェースを提供する通信ネットワークエンティティである。
トリガリングサーバは、デバイストリガー要求の発行元であるサーバである。このサーバはMTCサーバとすることができ、MTCサーバは通信ネットワークの外側に位置することができる。デバイストリガーメッセージは、SMSとすることができる。
バックオフタイマーの方が短いとき、メッセージサーバは、バックオフタイマーが切れたとき、または切れた後に、デバイストリガーメッセージをサービングネットワークノードに(サービングネットワークノードを通じて端末に)送信するステップをさらに実行することが有利である。
これに代えて、バックオフタイマーがデバイストリガー要求の有効時間よりも短いとき、デバイストリガー制御サーバは、バックオフタイマーが切れたとき、または切れた後に、デバイストリガー要求をメッセージサーバに送信するステップをさらに実行することができ、メッセージサーバは、デバイストリガー要求を格納し、輻輳が終了したとき、もしくはバックオフタイマーが切れたとき、またはその両方の時点で、デバイストリガー要求をサービングネットワークノードに送信する。さらなる代替形態として、デバイストリガー制御サーバは、バックオフタイマーを含むデバイストリガー要求を、格納してサービングネットワークノードに送信できるように、ただちにメッセージサーバに送信することができ、メッセージサーバは、バックオフタイマーが切れた後、または切れたときに、デバイストリガー要求を格納する。なお、バックオフタイマーは、トリガリングサーバまたはメッセージサーバがデバイストリガー要求の(再)送信を抑制するべき時間期間の意味を持つことに留意されたい。
上の3つの実施形態に共通する点として、トリガリングサーバがトリガー要求を端末に送信する通信ネットワーク内の通信ネットワークエンティティは、輻輳に起因してトリガー要求を端末に配信できないという指示情報を、通信ネットワーク内のサービングネットワークノードから取得する。この場合、ネットワークエンティティは、輻輳が終了するまで待機し、終了した後にデバイストリガー要求を端末に送信する。輻輳の終了は、サービングネットワークノードから情報を取得することによって、または、サービングネットワークノードから受信されるバックオフ時間を、デバイストリガー要求の有効時間とともに評価することによって、判定することができる。
前述した欠点を回避する目的で、この実施形態においては、サービングコアネットワークノード(例:SGSN/MME)は、たとえターゲットAPNに対してSM CCが動作していることを検出できる場合にも、デバイストリガー要求をユーザ機器に配信する。デバイストリガー要求をユーザ機器に配信することによって、以下が回避される。
− デバイストリガーがネットワークに不必要に格納されること。
− ユーザ機器が、測定、またはユーザ機器内部の別のデータ収集手順を開始するべき場合の、ユーザ機器における不必要な遅延。したがって、サービングコアネットワークノードがターゲットAPNを求めることができるかには無関係に、かつ、サービングコアネットワークノードが、APNベースのSM CCが適用されているかを判定できるかには無関係に、サービングコアネットワークノードは、つねにデバイストリガー要求をユーザ機器に送信する。
この実施形態に従って、SM CC中にデバイストリガー要求をユーザ機器に配信する結果として、次の2つの異なる手順につながる。
− デバイストリガリングの結果をMTCサーバに報告するトリガー配信報告(3GPPによってすでに考えられている、図5における「トリガー配信報告」を参照)
− アップリンクデータをMTCサーバに送ることに対するSM CCの影響を報告するためのアップリンクデータ指示情報(本発明によって提供され、本文書では配信遅延指示情報とも称する)(図5における「オプション1」および「オプション2」を参照)
両方の手順は、互いに独立して実行することができ、例えば、アップリンクデータ指示情報手順を後から実行する、または両方の手順を平行して実行することができる。両方の手順が平行して実行される場合、これらの手順は依然として独立していることができ、例えば、個別のメッセージをユーザ機器/ネットワークノードからMTCサーバに送ることができる。これに代えて、例えば両方の手順に関連する情報(データ)を伝える1つのメッセージを提供することによって、2つの手順を1つの手順に融合することができる。図5〜図9に図解されているさまざまな実施形態においては、アップリンクデータ指示情報もしくはトリガー配信報告またはその両方を提供するためのさまざまな可能な方法が示されており、以下ではこれらについて詳しく説明する。
図5は、デバイストリガー要求がつねにユーザ機器に送られ、アップリンクデータ配信の結果をMTCサーバに示すための手順が実行される場合のシグナリングフローを示している。特に、図5は、MTCサーバがトリガー要求を生成し、それを端末に送信することを示している。この送信は、背景技術のセクションで説明したように、T4インタフェースまたはT5インタフェースを通じて実行することができる。これは、「デバイストリガー配信(T4またはT5を通じて)」および「NAS/RR接続」に対応する。さらに、図5は、デバイストリガー要求を受信した後、ユーザ機器が、アップリンクデータを生成してMTCサーバに報告する前に、例えば測定を実行するためのいくらかの時間を必要としうることを示している(図5における「不確定な時間長」を参照)。アップリンクデータを生成するためにユーザ機器に必要とされる時間の長さ(例:測定のための時間長)は、一般にはネットワークには認識されない。SGSN/MMEは、通常では、ステップ(A)において、「トリガー配信報告」を生成し、MTC−IWFおよびさらにはMTCサーバに送信する。デバイストリガーが端末に正常に配信されたときには、トリガー配信報告は「成功」を示す。結果として、MTCサーバは、ユーザ機器が例えばアップリンクデータを報告するために通信を開始することを予測する。
図5は、アップリンクデータの配信/遅延の指示情報についてMTCサーバに通知するための2つの可能なオプションを示している。いずれのオプションも、灰色の四角の中に示してある。最初のオプション(「オプション1」を参照)においては、SGSN/MME(すなわちネットワークノード)が指示情報(「アップリンクデータ指示情報」メッセージ)を生成し、それをMTCサーバに送る。
第2のオプション(「オプション2」を参照)においては、ユーザ機器が指示情報を生成し、それをMTCサーバに送る。図5において理解できるように、指示情報をMTCサーバに送る前に、ユーザ機器は、SM−BOタイマーを含む拒否メッセージを受信している(「PDP/ベアラ拒否(SM−BO)」)。
第1のオプションの利点として、ネットワーク輻輳の場合にシグナリング量の増大を回避するための効率的なメカニズムが提供される。しかしながら、この第1のオプションには、依然として以下の問題点が存在する。
図5において、「問題点1」と示した囲みは、SGSN/MMEが「アップリンクデータの配信」の指示情報を生成できないことがあることを示している。指示情報を生成できないことがある理由としては、SGSN/MMEがMTCサーバのアドレスを必ずしも認識していないことや、SGSN/MMEが、トリガー配信報告を送った後、デバイストリガープロトコルのインタラクションについての情報を格納しないためである。後者は、デバイストリガーメカニズムはステートレス(状態を持たない)である、すなわち、デバイストリガー要求を配信するための経路に沿ったネットワークノードは、特にデバイストリガーが正常に配信された場合(これは想定されるシナリオの場合である)、デバイストリガーについての状態を格納しないという3GPPにおける現在の想定に基づく。「状態」の意味は、「ユーザ機器ID」(メッセージが配信された先)、配信の「タイムスタンプ」、メッセージの「宛先ID」または「送信元ID」、「使用されたインタフェース」(T4またはT5、あるいはSMSインフラストラクチャまたはT5が使用された場合)など、一連の格納されるパラメータである。なお、ここに説明した問題点は、3GPPの現在の想定に基づいて示した。しかしながら、本発明はこれに制限されず、したがって、異なるシナリオやネットワークにおいては、第1のオプションは、輻輳の場合のシグナリング負荷を減らすための極めて効率的な手段を提供することができる。
図5において「問題点2」と示した囲みは、アップリンクデータの遅延の指示情報を含めることができるようにユーザ機器からのフィードバックを受信するためには、SGSN/MMEによるMTCサーバへのトリガー配信報告(A)が遅延しうることを示している。しかしながら、遅延の長さは不確定であり、なぜならユーザ機器がPDP/PDN要求手順をいつ開始するか、すなわち送信されるデータの準備がいつ完了するかが不確定であるためである。
結果として、MTCサーバは、トリガー配信報告が時間どおりに受信されない場合、デバイストリガー要求を再送信することがある。さらには、SGSN/MMEが、「新しいPDP/PDN要求」を不確定な時間だけ待機することは、プロトコルの設計として不利である。
問題点1を解決するため、本発明の実施形態によると、サービングコアネットワークノード(SGSN/MME)は、正常に配信されたデバイストリガー要求についての「状態」を、いくらかの(事前定義されたまたは所定の)時間だけ格納する。この状態は、「デバイストリガーコンテキスト」と称することができ、ユーザ機器のNASコンテキストの追加要素/一部として格納することができる。例えば、デバイストリガーコンテキストは、ユーザ機器のMMコンテキストの一部として格納することができる。あるいは、SGSN/MMEがターゲットAPNを解決でき、かつそのAPNのコンテキストを有する場合、デバイストリガーコンテキストを、対応するユーザ機器のSMコンテキストに格納することができる。デバイストリガーコンテキストに関連する格納されるパラメータは、例えば、ユーザ機器ID、メッセージを生成した送信元ノードの送信元ノードID(例:MTC−IWF ID)、デバイストリガー要求の優先度のうちの1つまたは複数とすることができる。格納しておく時間長は、実装に固有とする、またはデバイストリガー有効時間に等しくする、または、ユーザ機器がデバイストリガリング要求への応答としてMM/SM手順を開始するまでの動的な時間長とすることができる。図5におけるオプション1に示したように、SGSN/MMEが後から「アップリンクデータ指示情報」を生成する場合、SGSN/MMEは、ユーザ機器IDおよび宛先ノードID(例:T5インタフェースを通じてのトリガリングが使用された場合にはMTC−IWF ID、T4またはTsmsを通じてのトリガリングが使用された場合にはSM−SC ID)をシグナリングメッセージに含める。これは、図5には、「SGSNがアップリンクデータの遅延の報告(SM−BO)を生成する」としてオプション1に示してある。
要約すると、ネットワークノードは、少なくとも、端末のID、トリガリング要求メッセージを送ったデバイスのID、他のトランザクションIDのうちの1つまたは複数を含むトリガー要求の状態を格納するステップと、配信遅延メッセージを生成して送信するステップであって、配信遅延メッセージが、端末のID、もしくは、トリガリング要求メッセージを送ったデバイスのID、またはその両方を含む、ステップと、をさらに含んでいることができる。
T5インタフェースを通じてのデバイストリガリングの場合、SGSN/MMEは、MTC−IWFへの「アップリンクデータ指示情報」メッセージを生成する。MTC−IWFは、ユーザ機器ID(通常ではユーザ機器の内部ID)に基づいて、ユーザ機器の外部IDと、「アップリンクデータ指示情報」メッセージを送るべきMTCサーバとを求める。さらに、MTC−IWFは、「アップリンクデータ指示情報」メッセージをMTCサーバに転送する前に、Tspインタフェースにおいて使用されるプロトコル構造にこのメッセージを適合させる目的で、このメッセージを再フォーマットすることもできる。このオプションの場合、「アップリンクデータ指示情報」をメッセージの中で伝えることができるように、T5およびTspにおけるプロトコルを拡張するべきである。これは既存のメッセージとすることができ、または、それぞれのプロトコルにおいて新規のメッセージを定義することができる。
T4インタフェースまたはTsmsインタフェースを通じてのデバイストリガリングの場合、SGSN/MMEは、MT−SMSの形のデバイストリガー要求をSM−SCから受信している。この場合、SGSN/MMEは、格納されているデバイストリガーステータス/コンテキストの中にSM−SCのIDを格納している。したがって、SGSN/MMEは、「アップリンクデータ指示情報」メッセージを生成すると、そのメッセージをSM−SCに送る。SGSN/MMEにおいて生成される「アップリンクデータ指示情報」メッセージのフォーマットは、MO−SMSフォーマットと互換性があることが有利である。SM−SCは、「アップリンクデータ指示情報」メッセージを受信して、それを正しいMTC−IWF(デバイストリガリングにT4が使用された場合)に、または正しいMTCサーバ(デバイストリガリングにTsmsが使用された場合)に転送することができることが好ましい。
上の解決策の結果として、SGSN/MMEは、ユーザ機器からのSM要求が拒否されたとき、つねに「アップリンクデータ指示情報」を生成し、(MTC−IWFまたはSM−SCを介して)MTCサーバに送る。この解決策の場合、2つの問題がさらに考えられる。
第1の問題として、ユーザ機器からのSM要求(図5における「PDP/PDN要求」を参照)が、デバイストリガリング手順に必ずしも関連していないことがある。例えば、トリガーされたMTCアプリケーションが依然としてデータを収集/測定している間に、ユーザ機器における別のアプリケーションが通信を開始することがある。この場合、SGSN/MMEは、アップリンクデータが配信されないことを「アップリンクデータ指示情報」の中で誤って報告することがある。この状況を回避するため、SGSN/MMEは、ユーザ機器からの拒否されるSM要求がデバイストリガリングに起因して開始されていることを確認するべきである。これを実行するため、SGSN/MMEは、ターゲットAPNを「デバイストリガーコンテキスト」に追加的に格納しておき、そのAPNと、ユーザ機器がSM要求を送るAPNとを比較することができる。APNが一致する場合のみ、SGSN/MMEは「アップリンクデータ指示情報」を生成してMTCサーバに送るべきである。
もう1つの問題として、ユーザ機器は、ネットワークからのSM拒否メッセージを受信した後、既存の接続を介してアップリンクデータを配信することを決定することがある。例えば、E−UTRANの場合、ユーザ機器がMMEにアタッチされているとき、実際の接続がすでに存在している間に、ユーザ機器のSMによってPDP/PDN接続修正が要求される場合である。あるいは、ユーザ機器は制御プレーンシグナリングを通じて(例えば後から説明するようにスモールデータメッセージとして)アップリンクデータを送ることを決定することができる。このような状況においては、SGSN/MMEは、アップリンクデータが配信されないことをMTCサーバに報告するが、ユーザ機器は代替手段を介してアップリンクデータをMTCサーバに依然として配信する。この状況を回避する目的で、SGSN/MMEは、アップリンクデータが配信されないことの指示情報がMTCサーバに送られたことをユーザ機器に示すことができ、したがってユーザ機器はアップリンクデータを送らない。しかしながら、これは最適ではないことがあり、なぜならこの場合、ユーザ機器は代替手段を介してアップリンクデータを送ることができる。したがって、代替の解決策として、SGSN/MMEからのアップリンクデータ指示情報が、MTCサーバへの条件付きフラグ/指示情報を含んでおり、この条件付きフラグ/指示情報は、予測される「第1の選択肢」の方法を介してではなく代替方法を介してユーザ機器がアップリンクデータを配信しうることを示す。例えば、MTCサーバがアップリンクデータをIPパケットとして受信することを予測している場合に、ユーザ機器はSMSとしてフォーマットされたアップリンクデータを送る。当然ながら、MTCサーバは、両方の配信方法におけるアップリンクデータを解析して利用することができるように構成される。
本発明の別の実施形態によると、図5を参照しながら説明した両方の問題点を解決する目的で、拡張機能を実装することができ、この場合、サービングコアネットワークノードは、いずれかのAPNにAPNベースのSM CCが適用されていることを検出できる場合(すなわち、SM CCがターゲットAPNに適用されているか任意の他のAPNに適用されているかは無関係)、ユーザプレーン接続を有効にするためのSM手順をただちに開始させるための、ユーザ機器への追加の指示情報を含めることができる。SGSN/MMEからユーザ機器へのこの指示情報は、例えば、「トリガー要求有効時間」(通常はMTCサーバから3GPPコアネットワークに伝送されるパラメータであるがユーザ機器には使用されない)とすることができる。オプションとして、SGSN/MMEからユーザ機器への別の指示情報も可能であり、例えば、デバイストリガー配信手順時に、デバイストリガーを伝えるNASメッセージにおいて特殊なフラグを使用することができる。この追加の指示情報は、図6におけるトリガー配信手順のステップ(「デバイストリガー配信」)において太字(「指示情報SM CC」)で示してある。この解決策を使用する場合、SGSN/MMEは、図5のオプション1における前述した実施形態において実行したように、デバイストリガーコンテキストを格納する必要がない。しかしながら、図6を参照しながら説明した解決策の場合、ユーザ機器への特殊な指示情報を実装する目的で、NASプロトコルの拡張と、ユーザ機器およびSGSN/MMEの変更とが必要である。
要約すると、ネットワークノードにおいて実行される本方法は、端末にネットワークとのユーザプレーン接続をただちに確立させるコマンドと、ネットワークが同じデバイストリガー要求を端末に配信することを試行する時間長を示すデバイストリガー有効時間の少なくとも一方を含む輻輳インジケータを、ネットワークノードから端末に送信するステップ、をさらに含んでいることができる。これに対応して、端末において実行される本方法は、そのような輻輳インジケータをネットワークノードから端末において受信するステップ、をさらに含んでいることができる。同様に、本発明の実施形態によるネットワークノードの送信ユニットは、輻輳インジケータを端末に送信するように構成することができ、その一方で、端末の受信ユニットは、輻輳インジケータを受信するように構成することができる。さらに、端末は、ネットワークノードから輻輳インジケータ(「指示情報SM CC」を参照)が受信された時点で、接続の確立を含むネットワークとの通信(図6における「新しいPDP/PDN要求」を参照)をただちに開始するようにさらにすることができる。
なお、端末への輻輳インジケータは、デバイストリガリングに対応するアップリンクデータが送られる同じAPN(ターゲットAPNまたは外部ネットワーク)との接続の確立を開始するようにユーザ機器をトリガーする。これは、ターゲットAPNが輻輳しているかを確認する目的で必要である。したがって、ユーザ機器の内部処理は、SGSN/MMEからの輻輳インジケータを、MTCサーバから受信されるデバイストリガー情報に関連付ける機能を提供する。特に、ユーザ機器において複数のアプリケーションが実行中である場合、ユーザ機器から送られるSM要求と、デバイストリガーが受信されるユーザ機器のアプリケーションから発生するSM要求とが一致するようにする。
ユーザ機器は、たとえアップリンクデータが利用可能になるのが後からになる場合にも、SM手順を実行することができる。ただちにSM手順を開始させるための追加の指示情報は、その特定のユーザ機器に対してAPNベースのSM CCが有効にされるかを判定する目的で有利である。SM CCが有効にされる場合、図6に示したように、「PDP/ベアラ拒否(SM−BO)」メッセージがSGSN/MMEからユーザ機器に送信される。
なお、(例えばサービングコアネットワークノードが特定のAPNに対するSM−BOタイマーを格納しないために)APNベースのSM CCが適用されているかをサービングコアネットワークノードが検出できない場合、サービングコアネットワークノードは、ただちにSM手順を開始させるためのユーザ機器への指示情報を含めず、図5のシグナリングフローを適用することができる。
この実施形態では、輻輳インジケータを受信した時点でユーザ機器において作動しているSM−BOタイマーが存在しないものと想定し、したがって、ユーザ機器はPDP/PDN接続確立要求を開始する。図6に示したように、ユーザ機器からのこの要求をネットワークがSM−BOタイマーを使用して拒否する場合、ユーザ機器はSM−BOタイマーを格納することができ、非特許文献4に指定されているように、APNベースのSM CCの場合の通常の手順を適用することができる。
図6および図7に示したように、MTCサーバへの「アップリンクデータ配信の指示情報」をどちらのエンティティが生成するかに応じて、2つのオプションが存在する。
オプション1は、図6に示してある。この場合、SGSN/MME(一般的にはネットワークノード)が、MTCサーバへの指示情報を生成する。この場合、SGSN/MMEは、ユーザ機器のSM要求にSM CCが適用されることと、したがってアップリンクデータが送られないままでありうることとを認識することができる。拒否メッセージの中でSM−BOタイマーがシグナリングされる場合、SGSN/MMEは、対応するアップリンクデータの遅延の指示情報としてSM−BOタイマー値を使用することもできる。したがって、SGSN/MMEは、「アップリンクデータの非配信」と、オプションとして、起こりうる(推定される)遅延とを、MTCサーバに示すことができる。しかしながら、SGSN/MMEは、アップリンクデータが有効であるか否かを判定することができず、なぜなら、SGSN/MMEは、ユーザ機器におけるデータの可用性についての情報と、トリガーデータの有効時間の情報の少なくとも一方を有さないためである。この実施形態においては、SGSN/MMEは、「トリガー配信報告」と「アップリンクデータ指示情報」とを1回のステップにおいて一緒に送る(図6における「トリガー配信報告+ULデータ遅延指示情報(SM−BO)」)。SGSN/MMEは、ユーザ機器からの「新しいPDP/PDN要求」(すなわちPDP/PDN接続の要求であり、これは例えばPDPコンテキスト要求またはPDN接続要求とすることができる)を待機する。SGSN/MMEは、PDP/PDN接続を確立または修正する目的で、この要求をコアネットワーク内のユーザプレーンエンティティに転送することができる。PDP/PDN接続の確立/修正の要求が拒否されるかに応じて、SGSN/MMEは、デバイストリガー手順の結果として特定のユーザ機器にAPNベースのSM CCが適用されるかを確認することができる。この場合にも、図5においてオプション1を参照しながら説明した問題に類似する問題が発生することがあり、すなわち、ユーザ機器からのSM要求が、デバイストリガリング要求のターゲットAPNに関連していない場合、SGSN/MMEは、SM CC輻輳が有効であるものと誤って判定し、「アップリンクデータ非配信の指示情報」をMTCサーバに送る。この問題は、すでに上述した解決策によって回避することができ、すなわち、SGSN/MMEは、ユーザ機器からのSM要求が送られる先のAPNと、デバイストリガリング要求のターゲットAPNとを比較する。
さらに別のオプション(実施形態)によると、サービングコアネットワークノード(SGSN/MME)は、「アップリンクデータ配信」の指示情報をMTC−IWFに送る。この処理は、デバイストリガリングにT5インタフェースが使用されるときに特に有利である。MTC−IWFは、「アップリンクデータ配信」の指示情報を受信して格納することができる。MTC−IWFは、指示情報を格納しておく(すなわちMTCサーバに転送しない)、または指示情報を再フォーマットした後にMTCサーバに転送する、またはその両方(すなわち格納および転送)を実行することを決定することができる。MTC−IWFは、指示情報を格納しておくことを決定した場合、それに続く、ユーザ機器(またはターゲットAPNが同じである別のユーザ機器)へのデバイストリガー要求を、ネットワークを介してユーザ機器に転送する代わりに、拒否することができる。この場合、デバイストリガリングは、MTC−IWFがその特定のデバイストリガリングの状態を格納するため、ステートフル(stateful)プロトコルである。MTC−IWFは、指示情報を転送することを決定した場合(当然ながらMTC−IWFは平行して指示情報を格納することができる)、Tspインタフェースを通じてMTCサーバに送られる対応するメッセージを生成する。
オプション2は、図7に詳しく示してある。この場合、ユーザ機器が、MTCサーバへの指示情報を生成する。図6においてオプション1に関して上述したように、SGSN/MMEは、アップリンクデータの遅延のみをMTCサーバに報告することができる。しかしながら、SGSN/MMEは、送られるアップリンクデータの有効性を判定することができない(「アップリンクデータの配信/有効性」)。図7に示したように、ユーザ機器側では、PDP/ベアラ拒否(SM−BO)メッセージを受信した後、本発明の別の実施形態に従って追加の処理を適用し、アップリンクデータの配信/有効性をSM−BOタイマーに基づいて判定する。これについては後からさらに詳しく説明する。「アップリンクデータの配信/遅延」を求める処理は、ユーザ機器においてのみ高い信頼性で実行することができ、なぜなら、アップリンクデータ報告がMTCサーバに送られる前に必要な測定のための時間はユーザ機器のみが認識しているためである。このことは、オプション1と比較したときのオプション2の利点である。図7の実施形態によると、ユーザ機器は、SM−BOタイマーを含むことのできる「アップリンクデータの配信/遅延」の指示情報(「制御プレーンを通じてのシグナリング/スモールデータ(ULデータ指示情報)」)を、制御プレーンを通じて伝えられるメッセージ(例:スモールデータメッセージ、または移動体発信SMS(MO−SMS))としてMTCサーバに送る。
要約すると、配信遅延インジケータを送信するステップは、ネットワークノードへの制御プレーンを通じて実行することができ、このネットワークノードから同様に制御プレーンにおいてインジケータをさらに伝送することができる。
ユーザ機器は、「アップリンクデータの配信/遅延」の指示情報を生成してMTCサーバに送ることのできる自身の能力について、ネットワークに通知するように構成できることが好ましく、したがって、SGSNは、「アップリンクデータの遅延」の指示情報を報告することなくトリガー配信報告をMTCサーバに送ることができる。さらには、「アップリンクデータの配信/遅延」の指示情報がユーザ機器から送られることをSGSN/MMEが認識している場合、MMEは、トリガー配信報告をより早期に、デバイストリガー配信手順の直後に、MTCサーバに送ることができる。このことも図7に示してある。具体的には、ユーザ機器にトリガーが配信された後、接続の確立(「新しいPDP/PDN要求」)と、ユーザ機器からMTCサーバへのデータ配信遅延インジケータの送信の前に、SGSN/MMEによって「トリガー配信報告」が送られる。
オプション1またはオプション2の使用は、ユーザ機器とSGSN/MMEとの間で交渉することができる。この交渉は、手順における整合性を確保する目的で有利であり得る。例えば、アタッチ手順またはトラッキングエリア更新(TAU)手順時、ユーザ機器とネットワークは、サポートされる好ましいオプションを交渉することができる。しかしながら、本発明では、両方のオプションをサポートする(提供する)ことは要求されない。一方のオプションのみを固定的にサポートし、他方のオプションは提供されないようにMTCシステムを構成することができる。遅延配信指示情報についてMTCサーバに通知するための異なるオプションをサポートする能力を交渉することは、図7を参照しながら説明した実施形態のみならず、本発明のすべての実施形態において適用することができる。
要約すると、ネットワークノードもしくは端末またはその両方は、端末が遅延配信指示情報をサーバに提供するのか、またはネットワークノードが遅延配信指示情報をサーバに提供するのかを示すインジケータを含むメッセージを生成するステップ、をさらに実行することができる。端末もしくはネットワークまたはその両方は、それぞれ、端末が遅延配信指示情報をサーバに提供するのか、またはネットワークノードが遅延配信指示情報をサーバに提供するのかの指示情報に対する肯定確認もしくは否定確認またはその両方を含むメッセージを生成するステップ、をさらに実行することができる。
以下では、本発明の別の実施形態として、デバイストリガーの受信時にユーザ機器においてSM−BOタイマーが作動しているものと想定したとき、デバイストリガーをユーザ機器に送信した後にAPNベースのSM CCをユーザ機器ベースで解決する方式をサポートする実施形態について説明する。
図5〜図7を参照しながら上述した実施形態とは異なり、この実施形態においては、デバイストリガー要求が受信されたときにユーザ機器においてSM−BOタイマーが作動している。したがって、ユーザ機器は、適用されているAPNベースのSM CCについて認識している。なお、この実施形態は、これまでの任意の実施形態と組み合わせることができる。
この実施形態においては、SGSN/MMEがユーザ機器におけるSM−BOタイマーについて認識していないものとさらに想定する。SGSNは、適用されているSM CCについて認識することができるが、非特許文献4のセクション4.3.7.4.2.2に記載されているように、SGSN/MMEは、ユーザ機器ごとおよびAPNごとにSM−BOタイマーを必ずしも格納しない(EPSおよびMMEの場合)。SGSN/MMEがSM−BOタイマーを格納する場合、図4を参照しながら上述したメカニズム/解決策、または図6を参照しながら説明したオプション1を適用することができる。
この実施形態においては、SGSN/MMEは、一般に適用されているSM CCについて認識している場合、デバイストリガーの配信時に、デバイストリガー有効時間についてユーザ機器に通知することができる。このパラメータ「デバイストリガー有効時間」については、すでに上に簡潔に説明してある。デバイストリガー有効時間は、現時点では(すなわち現在の3GPPコンセプトでは)、ネットワークがデバイストリガー要求をユーザ機器に配信することを試みるべき時間長を求める目的で、または、最初の配信の試みが(例えばユーザ機器に到達できないために)失敗した場合に、ネットワークがデバイストリガーを格納しておく時間長を求める目的で、ネットワークによって使用される。
この実施形態においては、デバイストリガー有効時間がユーザ機器に提供される。デバイストリガー有効時間についてユーザ機器に通知する利点として、ユーザ機器は、アップリンクデータをMTCサーバに配信するときの、時間遅延に対する耐性を判定するための指示情報として、このパラメータを使用することができる。具体的には、ユーザ機器は、MTCサーバによって送信されてユーザ機器によって受信される特定のトリガー要求への応答としてMTCサーバに送られるアップリンクデータが、どれくらい遅延しても依然として有効であるかを判定するために、デバイストリガー有効時間を使用することができる。
要約すると、有効時間の指示情報をネットワークノードから端末に送信することができる。有効時間は、現時点で送信されたデバイストリガー要求が有効である時間期間を示すことができる。この時間期間は、ネットワークが現在のデバイストリガー要求の配信を試みる時間期間、もしくは、最初の配信の試みにおいて配信できなかった場合にデバイストリガー要求をネットワークが格納しておく時間、またはその両方に一致させることができる。
上の想定はわずかに不正確なことがあり、なぜならアップリンクデータが有効である時間が、デバイストリガー有効時間よりも短いことがあるためである。例えば、ユーザ機器がデバイストリガリングを受信した後、アップリンクデータはただちに配信されるべきである。しかしながら、デバイストリガー自体は、遅延耐性とすることができる。したがって、MTCサーバは、アップリンクデータ(配信/遅延)の指示情報を受信した後、SM−BOタイマーが切れた後にデバイストリガー要求メッセージを再送信する、あるいは新しいデバイストリガー要求メッセージをただちに送るなど、次の動作を決定することができる。さらに、MTCサーバは、ユーザ機器またはSGSN/MMEによって送られる指示情報の値を反映する動作とは異なる動作をとることを決定することもできる。例えば、ユーザ機器またはSGSN/MMEからのアップリンクデータ指示情報が、アップリンクデータが配信される/有効であることと、遅延SM−BOタイマーとともに送られることをMTCサーバに通知することがある。しかしながら、MTCサーバは、依然としてデバイストリガー要求をただちに再送信することを決定することができる(例えば、異なるAPNへの指示情報、ただし一般には同じAPNへの指示情報を含む)。したがって、パラメータ「測定のための時間」が利用可能ではない場合、デバイストリガー有効時間は、ユーザ機器における単なる指示情報として使用される。
図8は、この実施形態の例示的なシグナリングフローを示している。点「1)」は、デバイストリガー配信手順時、またはそのわずか後に、SGSN/MMEがデバイストリガー有効時間をユーザ機器に示すことを示している(「デバイストリガー有効時間」)。以前の段落で、SGSN/MMEはデバイストリガー有効時間をユーザ機器に示すかを決定するときにSM CCの存在を考慮できることを説明した。SGSN/MMEには、デバイストリガー有効時間について他のネットワークエンティティ(MTC−IWFやSMS−SCなど)によって通知されるものと想定する。したがって、SGSN/MMEは、さまざまな方法でデバイストリガー有効時間をユーザ機器に示すことができる。
− このパラメータを、個別のダウンリンクNASメッセージとして送信する、または、
− デバイストリガー要求メッセージを伝えるNASメッセージの中の個別の情報要素としてこのパラメータを含める、または、
− デバイストリガー要求の「不透明なデータ」の中にこのパラメータを含める。
最初の2つの代替方式はSGSN/MMEによって実行することができ、なぜならダウンリンクNASメッセージまたはNASメッセージの中の情報要素はSGSN/MME自体において生成されるためである。最後の代替方式は、デバイストリガー要求の不透明な部分を解析および処理するための追加の機能がSGSN/MMEに存在する場合に、SGSN/MMEによって実行することができる。したがって、デバイストリガー要求の「不透明なデータ」の中にデバイストリガー有効時間を含める最後の代替方式は、さまざまなエンティティによって実行することができ、例えば以下のとおりである。
− SGSN/MME:このエンティティは、「不透明なデータ」を修正または再フォーマットすることが許可されている場合にのみ関与することができる。これは通常の仕様ではなく、場合によっては望ましくない方法であり、なぜなら「不透明なデータ」はネットワークに対して透過的であるべきであるためである。しかしながら、SGSN/MMEを採用することも可能であり、意図するように機能する。
− MTC−IWF:MTC−IWFは、MTCサーバからデバイストリガー要求を受信した後、「不透明なデータ」を修正することができ、ただしこの場合も、「不透明なデータ」を解析するためのMTC−IWFの能力に依存する。
− MTCサーバ:MTCサーバは、デバイストリガー要求における「不透明なデータ」を生成するため、問題なしにこのシグナリングを実施することのできるエンティティである。しかしながら、デバイストリガー要求における「不透明なデータ」の中に含まれる場合、指示情報の名前および意味は、「デバイストリガー有効時間」とは異なるものとするべきである。1つの可能なオプションは、「アップリンクデータの有効時間」を示すことである。もう1つのオプションは、アップリンクデータをただちに送ることができない場合に、「ユーザ機器におけるデバイストリガーの有効性」を示すことである。アップリンクデータの有効時間は、トリガー要求に応えてユーザ機器からMTCサーバによって受信されるデータが有効であるとみなされる時間期間を示すことができる。
デバイストリガーがユーザ機器に正常に配信された後、SGSN/MMEは、トリガー配信報告をMTC−IWFおよびさらにMTCサーバに送ることができる。
図8の点「2)」は、この時点においてユーザ機器内で内部処理が実行されることを示している。デバイストリガリング要求を受信した後、この処理は、アップリンクデータが送られるAPNを求め(データがただちに送られるか、いくらかの「測定」時間の後に送られるかには無関係)、そのAPNが輻輳制御下にあるか(すなわちそのAPNに対してSM−BOタイマーが作動しているか)を判定する。そのAPNが輻輳制御下にある場合、ユーザ機器は、アップリンクデータの有効性を求める(推定する)ための内部処理をさらに実行する。以下では、ユーザ機器においてSM−BOタイマーが作動しているものと想定する。
ユーザ機器の内部処理2)において、アップリンクデータの配信/有効性を求めた後、ユーザ機器は、図8および図9にそれぞれ示したように、オプションA(「オプションA」)またはオプションB(「オプションB」)の一方を実行することを決定することができる。どちらのオプションを実行するかの決定は、ユーザ機器もしくはネットワークまたはその両方における設定に基づくことができ、アタッチ手順またはTAU手順時に交渉することができる。しかしながら、オプションの一方を通信システムにおいて事前定義することができ、他方は必ずしもサポートしなくてもよい。
ユーザ機器は、図8に示したオプションAを実行することを決定した場合、求めたアップリンクデータの配信/有効性の指示情報1)、もしくは、残りのSM−BOタイマー値2)、またはその両方を、SGSN/MMEに送る(「1)アップリンクデータの有効性+2)SM−BO」)。点「3)」は、SGSN/MMEが、ユーザ機器からの指示情報を受信したときに自身の内部処理を実行できることを示している。この内部処理は、SGSN/MMEが、アップリンクデータの配信/有効性の指示情報をMTCサーバに転送する/送るか、または、ユーザ機器におけるSM−BOタイマーを削除するための手順を開始するかを、輻輳状況もしくはデバイストリガー要求の優先度またはその両方に基づいて決定することを含んでいることができる。例えば、輻輳状況が緩和されている場合、またはデバイストリガー要求が高い優先度を有する場合、SGSN/MMEは、代替オプションA.2を実行することを決定することができ、すなわち、SGSN/MMEは、SM−BOを削除する指示を有するセッション管理ダウンリンクメッセージ(「SM DLメッセージ」として示してある)をユーザ機器に送る。
例えば、3GPPシステムにおいては、このようなメッセージは、ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST(デフォルトEPSベアラコンテキストの有効化要求)メッセージ、ACTIVATE DEDICATED EPS BEARER CONTEXT REQUEST(専用EPSベアラコンテキストの有効化要求)メッセージ、またはMODIFY EPS BEARER CONTEXT REQUEST(EPSベアラコンテキストの修正要求)メッセージとすることができる。
ユーザ機器は、「SMダウンリンクメッセージ」を受信した後、SM−BOタイマーを削除/停止することが好ましい。その後、ユーザ機器はSM手順の実行を続行することができる(図5〜図7に示されているように「PDP/PDN要求」の送信を含む)。
代替オプションA.1では、SGSN/MMEは、アップリンクデータの配信/有効性の指示情報、もしくはSM−BOタイマー、またはその両方をMTCサーバに転送することを決定する。
要約すると、この実施形態によると、端末は、アップリンクデータの有効性インジケータをネットワークノードに送信することができ、このインジケータは、SM−BOタイマーを含んでいることができるが必須ではなく、トリガー要求に応えて送信されるデータが有効であるか否かを示す。ネットワークノードは、アップリンクデータの有効性インジケータをさらにサーバに転送することができる。輻輳が終了する場合、ネットワークノードは、作動しているバックオフタイマーを削除するように端末に指示するインジケータを含むメッセージを、輻輳の終了時に生成することができる。したがって、端末は、メッセージを受信および解析して、作動しているバックオフタイマーを削除するように端末に指示するアップリンクデータの有効性インジケータを取得できるようにすることができる。したがって、端末は、作動しているバックオフタイマーを削除することができる。
上述した機能をサポートする目的で、ネットワークノードは、端末がサーバと通信するネットワークに輻輳が存在するかを判定する判定手段を含んでいることができる。ネットワークの送信ユニットは、メッセージを生成してそれを端末に送信する手段をさらに含んでいることができる。端末は、メッセージを受信することのできる受信セクションと、バックオフタイマーを削除する(すなわちタイマー機能を終了させる)バックオフタイマー制御ユニットとを含んでいることができる。
ユーザ機器がオプションBを実行することを決定する、またはオプションBがユーザ機器によってサポートされるように定義されている場合、ユーザ機器は、MTCサーバに直接送られる、または中間エンティティを介して送られるシグナリングを生成する。このシグナリングは、例えば以下の形で実行することができる。
− 非特許文献1または非特許文献2に記載されているスモールデータ、または、
− MTCサーバへの直接的なユーザプレーン送信、または、
− ネットワークエンティティへの制御プレーン送信(このネットワークエンティティは指示情報をさらにMTCサーバに転送することができる)、または、
− 移動体発信SMS(MO−SMS)。
ユーザ機器は、新しいユーザプレーン接続を使用できないため、ネットワーク内の制御プレーン(C−プレーン)を通じて伝えられる、MTCサーバへのシグナリングを作成することができる。しかしながら、オプションとして、アップリンクデータの配信/有効性(SM−BOタイマー)の指示情報を、既存のユーザプレーン接続/ベアラを通じて送ることもできる。
なお、図8における点1)、点2)、および点3)は、本発明の実施形態に対応する、ユーザ機器およびSGSN/MMEにおける新規の機能または新規の内部処理を示していることに留意されたい。
以下では、アップリンクデータの配信/有効性の指示情報を求める目的でユーザ機器において点2)において実行することのできる内部処理について、さらに詳しく説明する。
1つの可能な解決策は、アプリケーションに固有なメカニズムに基づく。この場合、ユーザ機器におけるアプリケーションは、アップリンクデータがMTCサーバにおいて有効である時間長(すなわちアップリンクデータを使用または利用できる時間長)を決定する。この解決策は、標準化(すなわち3GPP)には関連しておらず、ユーザ機器および場合によってはMTCサーバにおけるMTC実装に依存する。
別の可能な解決策は、通信層からの(すなわち標準化に関連する)パラメータを考慮する、ユーザ機器における処理に基づく。これらのパラメータとしては以下が挙げられる。
− アップリンクデータを報告する前の測定のための時間、または、
− デバイストリガー要求の有効時間(デバイストリガー有効時間)。
ネットワークからユーザ機器へのデバイストリガー有効時間の配信については、上に説明した。アップリンクデータを報告する前の「測定のための時間」は、ユーザ機器に格納しておく、または「不透明なデータ」(すなわち、デバイストリガー要求の中の、MTCサーバからMTCデバイス(端末)を宛先とする情報)に含めることのできるパラメータである。
アップリンクデータの有効性を求める目的で、以下の例示的なロジックをユーザ機器において適用することができる。
If "time for measurements" is available,
then [UL data validity = "time for measurements"],
else [UL data validity = "Device Trigger validity time"]
If UL data validity > SM-BO timer,
then the UL data will NOT be outdated => UE may/need not indicate anything
elseif UL data validity < SM-BO timer,
Then the UL data will be outdated => UE shall indicate this to the SGSN or to the MTC server.
要約すると、端末は、トリガー要求が受信された後、データの有効時間を、ネットワークを通じてサーバに送信されるデータを収集するのに必要な時間期間として、または、ネットワークが同じデバイストリガー要求を端末に配信することを試みる時間長を示すデバイストリガー有効時間として、求めるステップ、をさらに実行することができる。データを収集するのに必要な時間期間は、測定を実行する、もしくは、サーバに報告できるようにデータを処理する、またはその両方を行うのに必要な時間期間とすることができる。端末においてバックオフタイマーが作動しており、データの有効時間が残りのバックオフ時間よりも小さい場合、端末は、データが期限切れとなること、もしくは、トリガー要求に応えてデータが送られないこと、またはその両方を示す配信遅延インジケータをサーバに示すことができる。一般的には、有効性の指示情報をサーバに送信するとき、この指示情報をサーバに直接送信する、すなわち端末とサーバの間のネットワーク全体に対して透過的に送信することができる。これに代えて、有効性の指示情報は、ネットワークノード(端末がサーバに接続されているネットワークにおいて端末をサーブするネットワークノード)などのネットワークエンティティを通じて送ることができる。
端末またはネットワークノードのいずれかにおいて評価ステップを実行することができ、この評価ステップは、データを端末からサーバに送信するかを判定する、もしくは、端末からサーバへのデータの送信の遅延を求める、またはその両方を目的として、端末側において作動しているバックオフタイマーを評価するステップと、端末によって送信されるデータの有効期間を評価するステップ、のうちの少なくとも一方を含んでいることができる。評価ステップの結果に従って、有効性の指示情報を端末またはネットワークノードによって送信することができる。
ユーザ機器は、アップリンクデータが期限切れとならないものと判定する場合、アップリンクデータの配信/有効性の指示情報をSGSN/MMEに送る(オプションA)、または直接MTCサーバに送る(オプションB)ことができ、ただしこのステップは必須ではない。しかしながら、アップリンクデータが期限切れとなるものと判定する場合、ユーザ機器は、アップリンクデータの配信/有効性をSGSN/MMEに(オプションA)、またはMTCサーバに(オプションB)、送るべきである。
ユーザ機器がアップリンクデータの配信/有効性(SM−BOタイマー)の指示情報をSGSN/MMEに送ることを決定した場合(すなわち図8におけるオプションA)、ユーザ機器は、デバイストリガー配信メカニズムに応じて以下のシグナリングオプションの1つを使用することができる。
デバイストリガー配信にMT−SMSが使用される場合、ユーザ機器は、拡張されたSM−CP/SM−RPプロトコル(ショートメッセージ制御プロトコル/ショートメッセージ中継プロトコル)シグナリングを使用することができる。標準化の観点からは、このメカニズムは欠点を有し、なぜならユーザ機器およびSGSN/MMEにおいてかなり大きな実装の変更が必要となりうるためである。したがって、別のオプションとして、アップリンクデータの配信/有効性(および場合によってはSM−BOタイマー)の指示情報を、NASシグナリングを通じて(例えば所定のNAS情報メッセージの中で)、新規の情報要素としてSGSNに送る。例えば、ESM情報要求手順を使用することができ、この手順は、デバイストリガー配信手順時にネットワークによって開始され、したがって、ユーザ機器は、アップリンクデータの配信/有効性(SM−BOタイマー)について、をINFORMATION RESPONSE(情報応答)メッセージの中でSGSN/MMEに示すことができる。
一般的には、デバイストリガー配信にはNASが使用される。SGSNへのNASシグナリングにおける特殊な指示情報を使用することができる。一例として、すでに上に示したように、ESM情報要求手順が使用される。
デバイストリガー配信にユーザプレーンが使用される場合、デバイストリガー配信用にユーザプレーン接続/ベアラがすでに確立されているため、同じ接続を使用してアップリンクデータを送ることができる。しかしながら、別のPDP/PDN接続を通じて、または新しい専用ベアラ(適用されているSM CCのためこれは可能ではない)を通じて、アップリンクデータを送るべきである場合、アップリンクデータの配信/有効性(SM−BOタイマー)の指示情報を、既存のユーザプレーン接続/ベアラを通じて送ることができる。これはむしろオプションB(図9を参照)に適用することができ、この場合、ユーザ機器はアップリンクデータの配信/有効性(SM−BOタイマー)の指示情報を直接MTCサーバに送る。別の代替方式としては、上述したように、この指示情報をNASシグナリングを通じて送ることができる。
ユーザ機器は、デバイストリガー配信メカニズムには無関係に、アップリンクデータの配信/有効性(もしくはSM−BOタイマーまたはその両方)の指示情報を生成して送ることもできる。ユーザ機器は、アップリンクデータの配信/有効性(SM−BOタイマー)の指示情報をフォーマットして送信するための事前定義されたメカニズムを実装することができる。例えば、デフォルトのMTC−IWFを使用するようにユーザ機器が事前に設定されるメカニズムを実装することができる。ユーザ機器は、アップリンクデータの配信/有効性(SM−BOタイマー)の指示情報をMTC−IWFに送ることができ、MTC−IWFは、アップリンクデータの配信/有効性(SM−BOタイマー)の指示情報を再フォーマットし、事前定義されたTspプロトコルを通じてMTCサーバに転送する。
アップリンクデータの有効性を求めることに関する上の説明は、SM−BOタイマーが利用可能であることに基づいている。しかしながら、SM拒否メッセージの中でSM−BOタイマーがユーザ機器に送られない場合、ユーザ機器は、アップリンクデータの有効性を求めることができない。さらに別のオプションにおいては、ユーザ機器がSM−BOタイマーを受信するが、パラメータ「測定のための時間」またはデバイストリガー有効時間をユーザ機器が認識していなければ、この場合もユーザ機器はアップリンクデータの有効性を求めることができない。このような場合、ユーザ機器は、アップリンクデータが配信されないことをMTCサーバに示すことができる。SM−BOタイマーが利用可能である場合、ユーザ機器はSM−BOタイマーをMTCサーバに示すことができる。したがって、ユーザ機器からMTCサーバへの指示情報の意味は、「アップリンクデータは遅延し、SM−BOタイマーが含まれている場合、残りのSM−BOタイマー値だけ遅延する」というものである。MTCサーバにおける評価と、MTCサーバからのさらなる動作は、MTCサーバにおける実装に依存することができる。
以下に説明する実施形態によると、デバイストリガリングがSMSを通じて実行されるときに、サービングネットワークノード(SGSNやMMEなど)が「通常の」MT−SMSと「DTに関連する」MT−SMSとを区別できないという問題の解決策を提供する。
SGSN/MMEは、一般的には、受信されたMT−SMSに何らかの特定の処理を適用するかを認識しない。デバイストリガリングに使用されるMT−SMSには特殊な処理が必要であることがあり、なぜなら、デバイストリガリングに使用されるMT−SMSに起因して、ユーザ機器がMTCサーバとの通信を開始し、したがって3GPPネットワーク内に新しい接続/ベアラ(またはPDP/PDNコンテキスト)を確立するためである。SM CCの場合、SGSN/MMEは、新しいPDP/PDNコンテキストの確立を制限することを望むことがあり、したがって、デバイストリガリングに使用されるMT−SMSを制限/ブロックすることを望むことがある。
いくつかの可能な解決策を考慮することができる。
− SGSN/MMEは、現時点でSM CC下にあるAPNに加入しているユーザ機器へのすべてのMT−SMSを拒否することができる。
− SGSN/MMEは、SMSをユーザ機器に送信(転送)するかを決定するとき、そのSMSの優先度を考慮することができる。SMSの優先度は利用可能なパラメータであり、一般にはSMSのヘッダにおいて送信され、SGSN/MMEから可視である。
− 上の両方の解決策を組み合わせることも可能である。
デバイストリガリングがT5インタフェースを通じて実行される場合(すなわちデバイストリガー要求がT5インタフェースを通じてSGSN/MMEに到着する場合)、このこと自体を、ユーザ機器がデバイストリガーサービスを使用している(またはデバイストリガーサービスに加入している、またはデバイストリガーサービスを使用することができる)ことをSGSN/MMEに示す指示情報とみなすことができる。
しかしながら、デバイストリガリングがSMSを通じて実行される場合、SGSN/MMEは、ユーザ機器がデバイストリガーサービスを使用している(またはデバイストリガーサービスに加入している、またはデバイストリガーサービスを使用することができる)かを認識することができない。
したがって、本発明は、ネットワークノード(すなわちUMTS/LTEに具体化する場合、SGSN/MME)の新規の機能/能力として、対象のユーザ機器がデバイストリガー機能に対して設定されている/デバイストリガー機能に加入している/デバイストリガー機能の能力を有するという情報を確立および格納する機能/能力を提供する。この能力の1つの特殊な場合は、SGSN/MMEが、受信されたデバイストリガー要求メッセージがデバイストリガリング機能に関連することを判定できることである。このことは、デバイストリガー要求メッセージがMT−SMSとしてSGSN/MMEに送られるときには、特に課題である。この情報の確立/作成は、いくつかの方法(これらは組み合わせることができる)で実行することができ、以下ではその例を提供する。
端末のデバイストリガリング設定に関する情報をサービングネットワークノードが登録するための第1の可能な方法は、端末に割り当てられている優先度またはサービス品質を評価することである。例えば、ユーザ機器が「低優先度」のサービスに対して設定されている、または、RRCプロトコルに挿入された「遅延耐性」指示情報(これは一般的には「低優先度」に等しい意味を持つ)を有するRANにユーザ機器がアクセスするとき、SGSN/MMEは、この情報をユーザ機器に関連するコンテキストに格納する。現在、LTEにおいては、この情報はユーザ機器/デバイスの設定に関連し、対象のアプリケーションに対してのみではない。SGSN/MMEは、「低優先度」または「遅延耐性」情報を使用して、ユーザ機器がMTCアプリケーションに対して設定されており、したがってユーザ機器がデバイストリガリング機能を使用しうることを決定することができる。したがって、SGSN/MMEは、受信されたMT−SMSがデバイストリガリングに使用されるものと結論することができ、そのMT−SMSをユーザ機器(端末)に送信しないことを決定することができる。言い換えれば、サービングネットワークノードは、特定の端末(通信デバイス)についてその優先度またはサービス品質を求め、求めた情報を端末に関連して格納する。端末が接続を確立する外部(セッション管理)ネットワーク(APN)が輻輳している場合、サービングネットワークノードは、デバイストリガー要求を端末に転送するか否かを、格納されている情報を使用して決定する。特に、端末の優先度(またはサービス品質)が低い場合、サービングネットワークノードはデバイストリガー要求(もしくは他のメッセージまたはその両方)を端末に配信しない。端末の優先度(またはサービス品質)が高い場合、サービングネットワークノードはデバイストリガー要求(もしくは他のメッセージまたはその両方)を端末に配信する。用語「低優先度」は、そのようにマークされているサービスを意味する。用語「低サービス品質」は、高い品質要件(すなわち配信遅延もしくは誤り率またはその両方に関する要件)が課されていないサービスに関連する。
この解決策の欠点として、LTEにおいては、「低優先度」に対して設定されているすべてのユーザ機器がMTCアプリケーションを使用しているわけではない。例えば、ネットワーク事業者は、低優先度のアプリケーション(例:マルチメディアサービスを使用せずにインターネットにアクセスする)のみを使用しているいくつかのデバイス/ユーザ機器を、これらのデバイスがMTCアプリケーションを実装していなくても、「低優先度」ユーザ機器として設定することがある。したがって、ネットワークは、MTCアプリケーションを実装していないこれらの「低優先度」ユーザ機器が、デバイストリガリングサービスを使用しているものと誤って結論することになる。さらには、MTCアプリケーションを使用しているすべてのユーザ機器が、実際にデバイストリガリングサービスに対して設定されている、またはデバイストリガリングサービスの能力を有するわけではない。例えば、仕様書である非特許文献1には、MTCを使用する場合として、例えばユーザ機器のみが通信を開始することができる(すなわちネットワークはこれらのユーザ機器をトリガーしない)場合が数多く記載されている。この意味において、デバイストリガリングは、ユーザ機器において実装または設定されていることもあれば、そうでないこともある機能または能力であると考えられる。したがって、この方法(すなわちユーザ機器における「低優先度」設定を考慮する)を使用すると、そのユーザ機器がデバイストリガリングに対して設定されている、またはデバイストリガリング能力があるものとSGSN/MMEが誤って解釈することにつながりうる。
端末のデバイストリガリング設定に関する情報をサービングネットワークノードが登録するための第2の可能な方法は、端末のトリガー要求が、デバイストリガリングのトラフィックのみに使用されるインタフェースを通じて受信されたか、またはそのようなエンティティから受信されたかを評価することである。例えば、LTEにおけるT5インタフェースおよびMTC−IWFは、このようなインタフェースおよびエンティティに相当する。トリガー要求が端末のMTC−IWFから受信された場合、その端末は、デバイストリガリングをサポートする端末としてサービングネットワークノードに格納される。そうでない場合、その端末は、デバイストリガリングをサポートしない端末としてサービングネットワークノードに格納される。この場合、サービングネットワークノードは、メッセージ(SMS)を端末に転送するか否かを、端末について格納されている情報を使用して決定する。特に、端末がデバイストリガリングをサポートするものとして格納されている場合、メッセージは転送されない。端末がデバイストリガリングをサポートしないものとして格納されている場合、メッセージは転送される。
3GPPシステム(GPRS/UMTS/LTE)においては、SGSN/MMEが、あるユーザ機器へのデバイストリガー要求をT5インタフェースを通じて受信したとき、このことは、そのユーザ機器がデバイストリガーサービスを使用している(または加入しているまたは能力がある)ことの指示情報として使用することができる。したがって、SGSN/MMEは、このユーザ機器がデバイストリガーサービスに対して設定されている/能力があるという情報を確立/作成して、ユーザ機器のコンテキストに格納することができる。しかしながら、この解決策の欠点として、ユーザ機器によってはSMSを介してのみトリガーされる(すなわちそれらのユーザ機器ではデバイストリガー要求がT5インタフェースを通じて到着することはない)。さらに、ネットワーク事業者によっては、T5インタフェースが実装されない、またはローミングユーザ機器にT5インタフェースが使用されないことがある。なお、第1の可能な方法および第2の可能な方法(本方法)の両方を組み合わせて、端末がデバイストリガリングをサポートしているか否かを判定(推定)することができる。
端末のデバイストリガリング設定に関する情報をサービングネットワークノードが登録するための第3の可能な方法は、加入者データを格納しているホーム加入者サーバから情報を取得することである。特に、HSS/HLRから例えばS6aインタフェースを通じてSGSN/MMEに伝えられる加入情報において、デバイストリガーサービスを使用するためのユーザ機器の設定/能力についてSGSN/MMEが認識することが可能である。
端末のデバイストリガリング設定に関する情報をサービングネットワークノードが登録するための第4の可能な方法は、ポート番号を評価することである。ポート番号は、トランスポート層プロトコルメッセージ(伝送制御プロトコル(TCP)またはユーザデータグラムプロトコル(UDP))またはMT−SMSにおけるポートとして求めることができる。ポート番号の意味(ポートの目的)は、端末から、またはホーム加入者サーバから取得することができる。この場合、サービングネットワークノードは、受信したメッセージの中のポートと、デバイストリガリングに使用されるポート番号とを比較し、メッセージのポート番号がデバイストリガリングに使用されるポート番号に一致しない場合、メッセージを端末に送信することができる。これに対して、特にNAS SM CCの場合、ポート番号が一致するとき、サービングネットワークノードは、メッセージを端末に送信しないことを決定することができる。LTEシステムの表現法においては、デバイストリガーサービスを使用するためのユーザ機器の設定/能力についての情報をSGSN/MMEが求めるための別の可能な方法は、T5を通じてのトリガリングが採用されているときに、MT−SMS、または場合によってはTCP/UDPメッセージにおいて使用される特殊ポート番号に基づく。用語「ポート番号」は、プロトコルメッセージのペイロードに含まれている情報が転送される先のアプリケーションまたは機能を示す。例えば、SMSポート番号は、SMSのペイロードが転送されるアプリケーション(例:汎用加入者識別モジュール(Universal Subscriber Identity Module:USIM)アプリケーションまたはワイヤレスアプリケーションプロトコル(Wireless Application Protocol:WAP)アプリケーション)を意味する。同様に、特殊ポート番号は、MT−SMSに含まれている情報をデバイストリガリングサービス層またはディスパッチャ機能に転送するため、ユーザ機器において指定することができる。SGSN/MMEは、この特殊ポート番号を使用できるように設定することができ、デバイストリガー要求メッセージを検査することができる。SGSN/MMEは、特殊ポート番号について、ユーザ機器から、またはHSS/HLRからの加入情報から認識することができる。この解決策の欠点として、SGSN/MMEは、使用されているポート番号の場合にデバイストリガー要求メッセージを検査できないことがある。ポート番号情報がSGSN/MMEに対して透過的であると考えることができる。
なお、ポート番号に代えて、またはポート番号に加えて、ペイロードタイプを使用して、デバイストリガリング機能に関する端末の能力を判定することができる。特に、プロトコルは、一般に、ペイロードのタイプを示すためにヘッダに含まれている一種の「ペイロードタイプ」フィールドを有する。このフィールドは、プロトコル記述子またはプロトコル識別子と称される。例えば、IPプロトコルにおいては、TCPプロトコルのペイロードが含まれているのか、UDPプロトコルのペイロードが含まれているのかをシグナリングすることができる。IPv6のヘッダは、「次のヘッダ」と称されるフィールドを有し、このフィールドは、次のプロトコルヘッダのタイプを示す。同様に、NASメッセージのヘッダは、デバイストリガリングに固有のプロトコルなどのペイロードタイプをシグナリングするペイロードタイプ記述子を含んでいることができる。
端末のデバイストリガリング設定に関する情報をサービングネットワークノードが登録するための第5の可能な方法は、端末から明示的にシグナリングされる情報を受信することである。特に、端末は、例えば、自身がデバイストリガリングをサポートするか、デバイストリガリングが現時点で設定されている/アクティブであるか、現時点でデバイストリガー要求をディスパッチするか、またはデバイストリガリング機能のための設定することのできる任意のパラメータを、サービングネットワークノードにシグナリングすることができる。3GPPシステムの表現法においては、ユーザ機器は、自身のデバイストリガー設定/能力についての情報をSGSN/MMEに明示的に示すことができる。この明示的なシグナリングは、アタッチ手順またはTAU/RAU(トラッキングエリア更新またはルーティングエリア更新)手順時に実行することができる。この明示的なシグナリングは、図14に示してある(「DT設定+関連するAPN」を参照)。ユーザ機器は、自身のデバイストリガー能力を、電源オン時または他の初期化手順時に有効にされる自身の内部設定に基づいて判定することができる。これに代えて、またはこれに加えて、端末は、自身のデバイストリガーステータスを、デバイストリガーアクティビティ/設定の何らかの変更時に求めることができる。さらに、ユーザ機器は、デバイストリガー要求メッセージの内部ルーティング/ディスパッチングのための特殊機能を有することができる。この機能が利用可能であることは、デバイストリガー設定/能力の情報をSGSN/MMEに伝えるNAS層に示すことができる。
端末のデバイストリガリング設定に関する情報をサービングネットワークノードが登録するための第6の可能な方法は、デバイストリガー要求が送られるMT−SMSのヘッダから情報を取り出すことである。特に、トリガー要求メッセージ(SMS)は、そのメッセージがデバイストリガーメッセージであることを示すインジケータをヘッダ内に含んでいることができる。この場合、サービングネットワークノードは、ヘッダからこの情報を取り出すことができ、メッセージがデバイストリガーメッセージであるとき、そのメッセージを端末に送信しないことを決定することができる。これに対して、メッセージがデバイストリガーメッセージではないとき(例えば通常のユーザデータを有するメッセージであり、そのメッセージに起因して端末が応答せず、したがってネットワークへのコンテキスト/接続を確立することがないとき)、サービングネットワークノードはメッセージを端末に送信することを決定することができる。なお、サービングネットワークノードによって実行されるこの決定は、ネットワーク輻輳の状態において、シグナリングトラフィックを減らすうえで有利である。3GPPシステムの表現法においては、デバイストリガー要求メッセージがMT−SMSにカプセル化される場合、SMS(メッセージ)を生成するエンティティ(通常ではSM−SCエンティティ)は、そのSMSがデバイストリガー目的に使用されることをSMSの中で示す。この指示情報は、SGSN/MMEに可視であるMT−SMSヘッダの一部とすることができる。SM−SCエンティティは、MT−SMSがデバイストリガー目的であることを認識し、なぜならそのSMSがT4インタフェースを通じて受信された、あるいはMTCサーバまたはMTCアプリケーションから受信されたためである。例えば、メッセージ(SMS)の発行元のエンティティは、デバイストリガー目的に(好ましくはデバイストリガーのみを目的として)使用される特定のSMS優先度を指定することができる。別の例として、このようなSMS優先度を、MT−SMSをSM−SCからGMSCを介してMSC/SGSN/MMEに伝えるMAPまたはDIAMETERあるいは他のプロトコルにおける指示情報の中で指定する。さらに別のオプションとして、SGSN/MMEが検査してMT−SMSの目的を判定することができる指示情報を、ショートメッセージ伝送プロトコル(SM−TP)の中に指定する。以下では、MM CCの場合におけるMT−SMSの処理に関するさらなる情報を示す。
上述したメカニズムの1つまたはいくつかを組み合わせて使用して、サービングネットワークノード(SGSN/MME)においてユーザ機器のデバイストリガー設定/能力を求め、それを格納しておき、輻輳状態において、受信された端末へのメッセージを端末に転送するかを決定する目的に使用することができる。特に、デバイストリガリングメッセージである(可能性がある)ものと判断されたメッセージは端末に送信されず、他のメッセージは端末に送信される。
メッセージを端末に送信するか否かに関する効率的な判断を実行する目的で、トリガリングの後に端末が接続の確立を試みるAPN、もしくは、そのAPNが輻輳状態にあるか否か、またはその両方に関する情報をサービングネットワークノードが有するならば有利である。
本発明の別の実施形態は、この問題(すなわちターゲットAPNの解決の問題)に対処する。この実施形態と本発明の他の実施形態とを組み合わせることは、特に有利である。例えば、端末のデバイストリガー能力またはデバイストリガー設定の検出と、トリガー時に端末が接続の確立を試みるAPNの輻輳状態(ネットワークが輻輳しているか否か)に関する情報とを合わせることで、サービングネットワークノードが、トリガリングを引き起こすすべてのメッセージを停止させ、デバイス(端末)のトリガリングを必ずしも引き起こさないメッセージを中継することを可能にする、十分な情報が提供される。
本発明の説明の別の部分ですでに述べたように、サービングネットワークノード(SGSN/MME)がターゲットAPNを求めることができないことがある。ターゲットAPNを解決するための上述した解決策は、SGSN/MMEにおいて外部IDが利用可能であり、かつ外部IDに特殊設定が使用されている場合に、適用することができる。このことは、T5インタフェースを通じてのデバイストリガリングの場合に部分的に可能である。しかしながら、デバイストリガリングにMT−SMSが使用されるときには、MT−SMSのヘッダの中で外部IDを伝えることはできず、したがって、外部IDはSGSN/MMEから可視ではない。さらには、今後においてもレガシーMT−SMSがデバイストリガリングに使用されると想定すると、SGSN/MMEにおける輻輳制御の場合に(特にSM CCの場合に)デバイストリガー要求をユーザ機器に送信するか否かを決定する目的で、SGSN/MMEがデバイストリガー要求(MT−SMSの形、またはT5インタフェースを通じての他の一般的なシグナリングフォーマットの形)を処理することのできる解決策を探す必要がある。
輻輳制御(CC)の場合にデバイストリガー要求メッセージに特殊処理を適用するかを判定するための1つの可能な方法は、SGSN/MMEが、ユーザ機器の加入APNを考慮することである。加入APNは、アタッチ手順時にHSS/HLRからSGSN/MMEに伝えられる加入情報の一部である。したがって、SGSN/MMEは、ユーザ機器の加入APNをつねに認識している。ユーザ機器が1つのAPNに加入している場合、SGSN/MMEにおける処理は単純なものとすることができる。SGSN/MMEは、デバイストリガー要求メッセージを受信すると、そのメッセージを処理して、メッセージを配信するべきユーザ機器を求める。次いで、SGSN/MMEは、加入APNをチェックすることができる。加入APNがMM CCまたはSM CC下にある場合、SGSN/MMEはメッセージを送信しないことができ、なぜならユーザ機器がネットワークへのMMシグナリングまたはSMシグナリングを生成するものと想定されるためである。
言い換えれば、サービングネットワークノードは、ホーム加入者サーバから情報を受信し、この情報は、1つまたは複数の外部ネットワークへの端末の加入情報を含んでいる。次いで、サービングネットワークノードは、加入ネットワークの1つまたは複数が輻輳状態にあるか否かを評価することができる。加入ネットワークの1つまたは複数が輻輳状態にあるとき、サービングネットワークノードは、デバイストリガリングメッセージを端末に転送しないことを決定することができる。デバイストリガリングメッセージ以外は、端末に配信することを決定することができる。
この実施形態においては、輻輳制御は、SM CCまたはモビリティ管理(MM)CCとすることができる。特にMM CCに対処する理由として、オフラインデバイストリガリング(今後3GPPにおいて仕様が策定される予定)は、3GPPネットワークにアタッチされていないデバイス(端末)を対象としてSGSN/MMEに送られるデバイストリガー要求(またはデバイスをトリガーするための類似するメッセージ)を含むことができる。言い換えれば、このデバイストリガー要求メッセージは、ユーザ機器を宛先とし、ネットワークにアタッチするようにユーザ機器に要求するメッセージである。これは、どのユーザ機器がネットワークにアタッチするかを取得した後、対応するシグナリング情報をブロードキャストすることによって実行することができる。このような場合には、SGSN/MMEがAPNベースのMM CCを適用する場合、SGSN/MMEはユーザ機器へのデバイストリガー要求メッセージをブロックすることができ、なぜなら、デバイストリガー要求メッセージが受信されることに起因してネットワークへのNAS MMシグナリングが発生し、このことはAPNベースのMM CCにおいて明らかに望ましくないためである。
上の説明では、ユーザ機器が1つのAPNに加入している場合について検討した。しかしながら、ユーザ機器が複数のAPNに加入しており、ただしSM CCが1つのAPNのみに適用される場合、非特許文献2のセクション6.59に記載されている従来技術の「MTC−IWFによる過負荷制御」メカニズムを適用しているとき、すべてのデバイストリガー要求がネットワーク(MTC−IWFまたはSGSN/MME)によってブロックされる。したがって、輻輳したAPNへのシグナリングを開始するようにユーザ機器をトリガーするデバイストリガー要求メッセージのみをブロックする解決策が好ましい。
この要件を満たすため、本発明の実施形態によると、SGSN/MMEは、ユーザ機器がデバイストリガー要求メッセージの受信後に接続を有効にする、またはデータを送る先の(1つまたは複数の)APN(簡潔さのため「DT関連APN」と称する)を認識する。SGSN/MMEは、この情報を、他の情報(例:加入APN)とともにユーザ機器のコンテキストに格納することができる。言い換えれば、SGSN/MMEは、加入APNと、DT関連APNとを区別することができる。DT関連APNは、加入APNのサブセットであり、ユーザ機器は、特にデバイストリガー要求メッセージの受信後、これらのAPNとのデータ接続を使用する。
SGSN/MMEがDT関連APNについての情報を認識するための1つの可能な方法は、HSS/HLRからの加入情報から認識することである。すなわち、HSS/HLRは、加入APNについての情報とともに、DT関連APNについての情報を格納しており、それをSGSN/MMEにシグナリングする。
SGSN/MMEがDT関連APNについて認識するための別の可能な方法は、ユーザ機器からの明示的なシグナリングから認識することである。例えば、アタッチ手順またはTAU/RAU手順時、ユーザ機器は(1つまたは複数の)DT関連APNをSGSN/MMEにシグナリングする。ユーザ機器がこの情報を認識できるのは、デバイストリガー要求によってトリガーされたMTCアプリケーションが新しい接続の確立を開始するときに、ユーザ機器はセッション管理(SM)要求メッセージの中にAPNを挿入することができるためである。したがって、ユーザ機器は、どのMTCアプリケーションがデバイストリガー要求によって有効にされているかと、それらのMTCアプリケーションによってどのAPNが使用されているかの情報を有することができる。MMEに通知するためにユーザ機器が使用することのできるシグナリング手順の一例として、NAS EMM STATUSメッセージを使用することができる。NAS EMM STATUSメッセージについてのさらなる情報は、非特許文献5のセクション8.2.14に記載されている。
言い換えれば、サービングネットワークノードは、メッセージを端末に転送するか否かに関する自身の決定を、端末がトリガーされた後に接続しうる外部ネットワークにおける輻輳状態に依存することができる。この方法は、端末が加入している外部ネットワークに基づくため、より正確かつ効率的である。端末がトリガーされた後に接続する外部ネットワークについての情報は、ホーム加入者サーバから、または端末から取得する(取り出す)ことができる。
要約すると、本発明の好ましい実施形態によると、SGSN/MME(サービングネットワークノード)は、ユーザ機器(端末)と、ユーザ機器のデバイストリガー能力/設定と、DT関連APNとの間の関連性についての情報を、維持するべきである。SGSN/MMEがデバイストリガー要求メッセージを受信し、SGSN/MMEにおいてAPNベースの輻輳制御が有効にされているとき、SGSN/MMEはチェックを実行して、ターゲットユーザ機器がデバイストリガーに対して設定されているかと、どれがDT関連APNであるかとを認識する。SGSN/MMEにおいて有効にされているAPNベースの輻輳制御が、ユーザ機器のDT関連APNに関連している場合のみ、SGSN/MMEは、デバイストリガー要求メッセージを拒否/ブロックすることを決定することができる。なお、拒否することを決定するとは、デバイストリガー要求が削除され、そのデバイストリガー要求の送信元ノードに削除について通知され、サービングネットワークノードがデバイストリガー要求を後から送信することを試みないことを意味する。ブロックは、一時的に実行することができ、この場合、デバイストリガー要求メッセージがサービングネットワークノードに格納され、後から、おそらくは輻輳状態が輻輳を示さない時点で、デバイストリガー要求メッセージが送信される。
上述したように、端末がデバイストリガー目的のために1つのAPNに接続できるのみである場合、決定は効率的に実行することができる。以下では、複数のDT関連APNの場合、またはSGSN/MMEがDT関連APNを認識できない場合について説明する。
上に説明した解決策は、ユーザ機器が1つのDT関連APNを有する(かつ複数の加入APNを有することができる)ものと想定したときに有利に適用することができる。しかしながら、複数のDT関連APNの場合、またはSGSN/MMEがDT関連APNについて認識しない場合、サービングネットワークノードがデバイストリガー要求を送信するかブロックするかを判定するための別のメカニズムが有利であり得る。1つのこのようなメカニズムは、格納されているEPSベアラコンテキストまたはPDPコンテキスト(簡潔さのためPDN/PDPコンテキストとしてすでに使用されている)に基づいて決定を行うことである。SGSN/MMEは、デバイストリガー要求(SM−SCからのMT−SMSの形、またはMTC−IWFからT5インタフェースを通じての別の種類のシグナリングの形)を受信したとき、加入APNと、DT関連APN(利用可能である場合)と、格納されているPDN/PDPコンテキストとをチェックする。以下の処理を適用することができる。
1.ユーザ機器の加入APNまたはDT関連APN(後者はSGSN/MMEにおいて利用可能である場合)のうちの1つのAPNも輻輳していない場合、SGSN/MMEは、デバイストリガー要求メッセージをユーザ機器に送信することを結論し、なぜなら、端末からネットワークへの、およびネットワークから端末への、後から発生しうるNASシグナリング(EMM要求またはESM要求)が、ネットワークにおいて有効にされているAPNベースの輻輳制御に影響しないためである。
2.加入APNまたはDT関連APN(後者はSGSN/MMEにおいて利用可能である場合)のうちの1つのAPNが輻輳しており、輻輳している(DT関連)APNに対するPDN/PDPコンテキストが存在しない場合、SGSN/MMEは、ユーザ機器がMTCサーバ/アプリケーションとのデータ接続を確立する目的でおそらくネットワークにESM要求を送るものと結論することができる。SGSN/MMEは、この結論に基づいて、デバイストリガー要求メッセージを拒否することができる。さらに、複数の加入APNまたは複数のDT関連APNが存在し、SGSN/MMEが加入APNまたはDT関連APNの一部についてPDN/PDPコンテキストを維持している場合にも、デバイストリガー要求を拒否することができ、なぜなら、SGSN/MMEは、どのAPNにデバイストリガー要求が送られるかについて100%の確信がなく、ユーザ機器が輻輳したAPNに(E)SM要求を送る可能性が依然として存在するためである。SGSN/MMEは、MTC−IWFエンティティおよびさらにはMTCサーバに返されるデバイストリガー配信報告の中に、拒否/失敗の理由に加えて、MTCサーバ/アプリケーションがそのユーザ機器へのデバイストリガー要求メッセージの再送信または送信を試みるべきではない時間を含めることができる。したがって、サービングネットワークノードは、トリガー要求を端末に配信しないことを決定したとき、失敗した配信の理由と、サーバ(トリガリングサーバまたはデバイストリガー要求の発信元)がデバイストリガーメッセージを端末に送信または再送信するべきではない時間期間(場合によってはオプション)とを示す報告メッセージを、サーバにさらに送信することができる。本発明の別の態様によると、トリガリングサーバを、受信された報告メッセージと、受信された報告メッセージの対象の端末とに基づいて、輻輳した外部ネットワークを求めるように構成することができる。したがって、トリガリングサーバは、同じ外部ネットワークに加入している他の端末に、類似する手段(すなわちトリガー要求の送信の抑制)を適用することを決定することができる。言い換えれば、オプションとして、MTCサーバ/アプリケーションは、このモバイルネットワークに登録またはアタッチされている他のユーザ機器に、さらなるデバイストリガー要求メッセージを送ることの抑制を適用することができる。
3.加入APNまたはDT関連APN(後者はSGSN/MMEにおいて利用可能である場合)のうちの1つのAPNが輻輳しており、その加入APNまたはDT関連APNに対するPDN/PDPコンテキストが存在する場合、SGSN/MMEは、ユーザ機器がデバイストリガー要求メッセージの受信後にネットワークにESM要求を送らないものと結論することができる。SGSN/MMEは、この結論に基づいて、デバイストリガー要求メッセージをユーザ機器に送ることを決定することができる。さらに正確な決定を行う目的で、SGSN/MMEは、以下についての情報をさらに考慮することができる。
3.a) 輻輳したAPNに対して許可されるPDNタイプ。通常、ユーザ機器は、新しいPDN接続(すなわちデフォルトのベアラ)を確立するときにPDNタイプを要求する。PDNタイプは接続タイプであり、例えば、IPv4もしくはIPv6またはその両方とすることができ、要求されたPDN接続に対してユーザ機器に割り当てるIPアドレスのタイプをネットワークに示す。
3.b) 輻輳したAPNに対して許可されるEPSベアラの最大数。この情報は、例えば、加入情報の一部とすることができ、加入情報リポジトリ(HSS/HLR)から取得することができる。
例えば、ユーザ機器に許可される、APN(たまたま現在輻輳している)へのEPSベアラが1つのみであることをユーザ機器の加入情報が示しており、SGSN/MMEがそのAPNに対するPDN/PDP(すなわちベアラ)コンテキストをすでに格納している場合、SGSN/MMEは、ユーザ機器がそのAPNに対して新しいEPSベアラまたはPDPコンテキストを確立しない(すなわちユーザ機器は(E)SM要求メッセージを送らない)ものと結論することができる。したがって、SGSN/MMEは、デバイストリガー要求メッセージを送信することができる。
上記における「2.」は、「保守的な」方法として特徴付けることができ、なぜなら、SGSN/MMEは保守的に動作し、たとえユーザ機器がデバイストリガー要求メッセージの受信後に(E)SM要求を送らない可能性があっても、デバイストリガー要求を拒否またはブロックするためである。これに対して、上記の「3.」に説明したケースは、「非保守的な」方法と表現することができ、なぜなら、SGSN/MMEは、たとえユーザ機器がデバイストリガー要求メッセージの受信後に(E)SM要求を送る可能性があっても、デバイストリガー要求を拒否しないためである。
図14は、対応するメッセージ交換の例を示している。図中の「非保守的な」方法は、SGSN/MMEからユーザ機器にデバイストリガー要求をシグナリングするステップと、ユーザ機器において処理するステップと、場合によってはユーザ機器からSGSN/MMEにシグナリングするステップと、SGSN/MMEからMTC−IWFにシグナリングするステップとを含んでいる。
上に説明した「非保守的な」方法における問題は、SGSN/MMEがデバイストリガー要求メッセージをユーザ機器に送信し、ユーザ機器が新しいベアラを確立する、または既存のベアラを修正する必要があるときに起こりうる。この場合、ユーザ機器は、ネットワーク(SGSN/MME)と、場合によっては輻輳したAPNとにESM要求を送り、その場合、ユーザ機器からの(E)SM要求は拒否される。さらに、この問題は、SGSN/MMEに複数のDT関連APNが存在するが、そのうちの1つのみが現時点で輻輳している場合にも起こりうる。SGSN/MMEが、DT関連APNのいくつかに対してPDN/PDPコンテキストを格納している場合、新しいデータ接続(ベアラ)が確立される可能性が低いため、SGSN/MMEは、デバイストリガー要求メッセージを送信することを決定することができる。しかしながら、ユーザ機器は、新しい接続を必要とする場合、ESM要求メッセージを送る。このような場合、SGSN/MMEは、そのESM要求メッセージを拒否する。
輻輳したAPNに対するESM要求メッセージを送ることを回避する目的で、デバイストリガー要求を送信するためのNASシグナリング手順時に、現時点で輻輳しているAPNについて(さらにオプションとしてSM−BOタイマーについて)SGSN/MMEがユーザ機器に通知することが有利である。SGSN/MMEは、現時点で輻輳しているAPNがユーザ機器の加入APNの1つである場合にのみ、その輻輳しているAPNを通知する。このことは、図14においては、デバイストリガー要求メッセージを送信するためのSGSN/MMEからユーザ機器へのシグナリングによって示してある。サービングネットワークノードから端末へのデバイストリガー要求配信メッセージにおけるカッコ内の太字は、輻輳したAPN(「輻輳制御下のAPN」)および場合によってはSM−BOタイマーが含まれることを示している。さらに、図14は、ユーザ機器がBOタイマーを含むESM拒否をSGSN/MMEから受信した場合と同様に、ユーザ機器が、受信したこの情報(輻輳制御下のAPNおよび場合によってはSM−BOタイマー)を格納し、アップリンク(UL)ESM要求メッセージの監視を有効にすることを示している。例えば、SGSN/MMEは、輻輳したAPNおよびSM−BOタイマーについて、何らかの既存のNAS手順、例えばEMM INFORMATIONメッセージ(MMEからユーザ機器への一方向)またはEMM STATUSメッセージを使用して、ユーザ機器に通知することができる。さらに、輻輳したAPNに対するEPSベアラコンテキストが存在する場合、SGSN/MMEは、ESM NOTIFICATIONメッセージを使用することができる。プロトコルの仕様におけるこれらのメッセージには、新規の情報要素またはパラメータを指定する必要がありうる。これらのメッセージのフォーマットについてのさらなる情報は、非特許文献6(3GPPのウェブサイトから自由に入手可能)に記載されている。しかしながら、本発明は、UMTS/LTEに存在するメッセージを再利用することに制限されない。SGSN/MMEとユーザ機器との間の新規の手順を指定することができる。
なお、この実施形態は、(データ)接続を確立するための端末の要求を拒否した後にSM−BOタイマーを送信することに関する利点を有する。特に、この実施形態では、端末は接続の確立を試みず、したがって、輻輳したネットワークへのシグナリングメッセージの量が減少する。サービングネットワークノードは、輻輳した外部ネットワークについての情報を端末に送信する。特に、サービングネットワークノードは、端末に関連するネットワーク(すなわち端末が接続の確立を試みうるネットワーク)についての情報を送信する。この情報は、バックオフタイマーを含んでいることもできる。端末への情報の送信は、端末に(デバイストリガリング)メッセージを送信するとき、端末が輻輳したネットワークとの接続の確立を試みうる/試みると判断された後に、実行することができる。
SM−BOタイマーが作動している間に、ユーザ機器のアプリケーション/サービス層が、格納されている輻輳したAPNとの新しい接続の確立を要求するときには、ユーザ機器はESM要求メッセージを送らない。ユーザ機器は、要求される新しいデータ接続(ベアラまたはPDPコンテキスト)を確立できないことを、NAS手順を使用してSGSN/MMEに通知することができる。例えば、ユーザ機器は、NAS EMM STATUSメッセージ(例えば非特許文献5のセクション5.7に定義されている)を使用することができる。NAS EMM STATUSメッセージにおいて、ユーザ機器は、輻輳したAPNについてと、オプションとして残りのSM−BOタイマーについてと、デバイストリガー要求メッセージIDとについて、SGSN/MMEに通知することができる。デバイストリガー要求メッセージIDは、NAS EMMメッセージに含まれる情報とデバイストリガー要求メッセージとの間の関係を確立する目的で、SGSN/MMEにおいて必要となることがある。このようにすることで、SGSN/MMEは、デバイストリガー要求メッセージが正常に配信されたが、APNの輻輳に起因してユーザ機器がデータ接続またはIPベアラを確立できないため、データ接続またはMTCアプリケーションの応答が遅延しうることを示すデバイストリガー配信報告を生成して、MTC−IWFに送信することができる。
「非保守的な」方法は、図6のオプション1(「オプション1」)において説明した解決策に似ているように見える。異なる点として、図6のオプション1では、デバイストリガーの配信時に、輻輳したAPNについてユーザ機器に通知されず、ネットワークにSM CCが存在することがユーザ機器に通知される。したがって、ユーザ機器が(E)SM要求メッセージをSGSN/MMEに送ることがあり、SGSN/MMEはこのメッセージを拒否する。図6のオプション1と図14の解決策を組み合わせることが可能である。例えば、図14の上側部分(すなわち、SGSN/MMEにおいてターゲットAPNを求める処理)を適用することができ、SGSN/MMEが「非保守的な」方法を適用することを決定した場合(ただし、デバイストリガー要求メッセージの送信時に輻輳したAPNを示していない)、ユーザ機器は、図6のオプション1に示したように、輻輳したAPNへの(E)SM要求を開始しうる。この場合、SGSN/MMEは、輻輳したAPNへの(E)SM要求を拒否し、MTC−IWFへのデバイストリガー配信報告を生成し、この報告がMTCサーバ/アプリケーションに転送される。なお、サービングネットワークノードは、上述した方法のどちらを適用するか、例えば、「保守的な」方法(図14においてオプションAとして示してある)を適用するか、「非保守的な」方法(図14においてオプションBとして示してある)を適用するかを決定するための手段を有することができる。しかしながら、本発明はこれに制限されず、一般的には、これらの方法のうちの一方のみをサービングネットワークノードにおいて適用可能とする/設定することができる。
図14に示した1つのさらなる細部として、デバイストリガー要求をユーザ機器に送信してから、デバイストリガー配信報告をMTC−IWFに送るまでの間の遅延が、SGSN/MMEにおいて発生する。図14および図6のいずれも、デバイストリガー配信報告はMTC−IWFに送られることを示しているが、デバイストリガリングにMT−SMSが使用される場合、デバイストリガー配信報告がSMSコアネットワークエンティティ(例:SM−SC)に送られることも可能である。図14に示したように、SGSN/MMEにおいて発生する遅延は、ユーザ機器が無線リンクを通じてパケットを送信/受信しないときにCONNECTED(接続)状態からIDLE(アイドル)状態への移行を有効にする目的で基地局装置において使用されるタイマーと同じ値または近い値を有することができる。このとき、SGSN/MMEは遅延(すなわちタイマー)を有効にする必要はなく、IDLE(アイドル)モードへの移行のためのS1−AP要求を基地局装置が送るまで待機するものと想定することができる。これも可能なオプションである。しかしながら、ユーザ機器が別の有効な接続を有し、長時間にわたりACTIVE(アクティブ)/CONNECTED(接続)状態にある場合、基地局装置はIDLE(アイドル)モードへの移行のためにSGSN/MMEをトリガーしない。したがって、SGSN/MMEが自身の遅延タイマー(基地局装置におけるインアクティビティタイマー(inactivity timer)に近い値を有することができる)を有効にすることが有利である。
図6および図14の両方に関連する1つのさらなる態様を考慮することができる。MTCサービス層プロトコル(すなわちユーザ機器の観点からは、これはNAS層の上のアプリケーション層であり、3GPPによって標準化されたプロトコルである)の実装によっては、ユーザ機器のアプリケーションが、デバイストリガー要求メッセージを受信したことをMTCサーバまたはMTCアプリケーションに肯定応答する必要がある。これは、要求<−>肯定応答交換を有する通常のプロトコル設計である。このような交換が特に要求されるのは、デバイストリガー要求メッセージによって、ユーザ機器からの即座のデータ報告ではなく何らかの測定がトリガーされるときであり、なぜなら、MTCサーバは、ユーザ機器がデータ(例:測定値)の収集を開始したことを確認したいためである。デバイストリガー要求を受信したことの肯定応答(あるいは「受信確認」と称することもができる)は、データパケットとしてユーザプレーンを介して、またはデバイストリガー要求メッセージ配信の場合と同じプロトコルを使用して(例:SMSまたはT5プロトコルを通じて)制御プレーンを介して、MTCサーバまたはMTCアプリケーションに送り返すことができる。デバイストリガー要求の受信の確認は、例えばSGSN/MMEからMTC−IWFに送り返されてMTCサーバに転送されるデバイストリガー配信報告とは独立していることができる。したがって、トリガリングサーバを発行元とするデバイストリガー要求を受信した端末は、要求受信の確認メッセージを(例えば複数のネットワークノードもしくは外部ネットワークまたはその両方を通じて)トリガリングサーバに送信することによって、要求の受信を確認することができる。
図15は、デバイストリガー要求の受信確認の制御プレーン送信およびユーザプレーン送信の両方の場合の可能な仕様を記述したものであり、以下ではこれについて説明する。
・ この図の右側は、2つの異なるMTCアプリケーション(「MTCアプリケーション1」および「MTCアプリケーション2」)が、対応するMTCアプリケーションとの通信を開始するようにMTCサーバからユーザ機器をトリガーすることを要求する例を示している。MTCサーバは、デバイストリガー要求メッセージを生成し、それをTspインタフェースを通じてMTC−IWFに送る。MTC−IWFは、T4インタフェースまたはT5インタフェースを通じての配信を選択し、それに応じてデバイストリガーメッセージを転送する。デバイストリガーメッセージはサービングネットワークノード(SGSN/MME)に到着し、SGSN/MMEはメッセージをユーザ機器におけるNAS層に転送する。
・ デバイストリガー要求メッセージは、NAS層における処理の後、おそらくは一種のディスパッチ機能によって処理される。デバイストリガー要求がMT−SMSにカプセル化されている場合、MT−SMSのペイロード(デバイストリガー情報を含んでいる)が、(例えばSMSディスパッチ機能によって)MTC固有機能(デバイストリガーディスパッチ機能とすることができる)に転送される、またはMTCサービス層内部ルーティング機能に直接転送される。言い換えれば、NAS層とMTC関連機能との間に、SMSに固有な機能が存在しうる(図15には示していない)。なお、ユーザ機器の中のいくつかの四角い囲みは、ユーザ機器における機能または層の例示的な構造を示しているが、正確な細部は実装に依存することに留意されたい。デバイストリガー要求がT5インタフェースを通じて伝えられ、フォーマットがSMSとは異なる場合、ユーザ機器におけるNAS層は、デバイストリガー要求をデバイストリガーディスパッチ機能またはMTCに固有なサービス層機能に転送し、これらの機能は、正しいアプリケーションを識別し、さらにメッセージを転送/ルーティングするべきである。(MTC)IPベアラサービスとMTCアプリケーション1との間のデータ接続(またはベアラ)は、実線によって示してあり、このことは、これらの接続/ベアラのPDN/PDPコンテキストがユーザ機器およびSGSN/MMEに存在することを意味する。これに対して、(MTC)IPベアラサービスとMTCアプリケーション2との間のデータ接続/ベアラは、破線によって示してあり、このことは、これらの接続/ベアラのPDN/PDPコンテキストが存在しないことを意味する。
・ デバイストリガー要求の受信確認を、制御プレーンを通じてMTCサーバに送ることができる。これは、以下のいずれかとして実行することができる。
1. MO−SMSとして。MO−SMSは、MTCアプリケーションまたはMTCサービス層ルーティング機能において生成され、ユーザ機器のSMSプロトコルスタックに転送され、その後にユーザ機器におけるNAS層に転送される。
2. 他のシグナリングプロトコルメッセージとして。このメッセージは、ユーザ機器におけるNAS層に転送され、ネットワークに送信される。
ユーザ機器においてAPNベースのSM輻輳制御が有効にされている場合(すなわち図9に示したようにユーザ機器が作動中のSM−BOタイマーを有する場合)、ユーザ機器は、有効にされているSM−BOタイマーが、データ接続(ベアラ1またはベアラ2)を確立しなければならない先のAPNに関連しているかを判定する目的で、NAS層において特殊なチェックを実行することができる。関連している場合、ユーザ機器(NAS層またはMTCアプリケーション層またはMTCサービス層)は、対応する情報(すなわち、有効にされている輻輳制御のため、アップリンクデータをただちに配信することができない)を、MTCサーバへのデバイストリガー要求の受信確認の中に含める。このような方法においては、デバイストリガー要求の受信確認は、デバイストリガー要求メッセージが正常に受理されたが、有効にされているSM−BOタイマーのためデータ接続を確立できないという情報をMTCサーバに伝える。これは、図9のオプションBに似ている。
・ デバイストリガー要求の受信確認は、ユーザプレーンを通じてMTCサーバに送り返すことができる。(図15においてベアラ1について示したように)PDN/PDPコンテキストがすでに確立されている場合、ユーザ機器は、デバイストリガー要求の受信確認を送信することができる。しかしながら、(ベアラ2について示したように)PDN/PDPコンテキストが確立されておらず、ベアラ2のAPNが輻輳制御下にある場合、ユーザ機器は、デバイストリガー要求の受信確認メッセージを送信することができない。
一般的には、MTCサーバまたはMTCアプリケーションがデバイストリガー要求の受信確認を受信することを予測していたが、そのような確認が受信されない場合、MTCサーバまたはMTCアプリケーションは、デバイストリガー要求メッセージを再送信する。このような場合、MTCアプリケーション、MTCサーバ、MTC−IWF、SGSN/MMEのうちの1つのエンティティは、この状況を判定して新しいデバイストリガー要求メッセージをユーザ機器に再送信しないようにするための機能を実装しているべきである。例えば、このような機能としては、本発明における実施形態の1つにおいてすでに説明した、ユーザ機器におけるAPNベースの輻輳検出の解決策が挙げられる。別の可能な解決策としては、ユーザ機器がデータまたはデバイストリガー要求の受信確認を送信するためのIPベアラを確立できないものと判定した後、NAS接続が依然として確立されているかまたはアクティブである場合、ユーザ機器はAPNベースのSM CCについてSGSN/MMEに通知することができる。類似する方法は図14においてすでに説明してあり、この場合、ユーザ機器はNAS EMMステータスメッセージを使用して、輻輳状況についてSGSN/MMEに通知する。
これに代えて、デバイストリガー要求メッセージが再送信される問題を解決するため、ネットワーク(例:SGSN/MME)は、MTCサーバによってデバイストリガー要求が再送信されたときに、ユーザ機器において作動しているSM−BOタイマーを終了させて、デバイストリガー要求メッセージをユーザ機器に送信することを決定することができる。SGSN/MMEは、ユーザ機器におけるSM−BOタイマーを、非特許文献4のセクション4.3.7.4.2.2に記載されているように終了させることができる。すなわち、SGSN/MMEは、ユーザ機器に向かう(E)SM手順を開始する。ユーザ機器は、SGSN/MMEからの(E)SM要求メッセージを受信すると、SM−BOタイマーを終了させる。
複数のDT関連APNが存在する場合、ユーザ機器がデバイストリガー要求メッセージを受信したときに正確にどのAPNがトリガーされるかをMMEが検出できないとき、「非保守的な」方法が有利である。
本発明の別の実施形態によると、MTC−IWFまたはSGSN/MMEは、デバイストリガー要求の送信元に基づいてDT関連APNを解決する。
上の説明においては、SGSN/MMEがターゲットAPNをどのように解決するかに関して、いくつかの方法を提供してきた。これらの方法は、本質的には、SGSN/MMEにおける内部処理に基づく(これは特に加入APNまたはDT関連APNが1つである場合にあてはまる)、または、ユーザ機器から受信される明示的な指示情報に基づいている。以下の実施形態においては、デバイストリガー要求メッセージの送信元に基づくさらに別の方法が提供される。この方法は他の方法とは異なり、なぜならこの方法では、ターゲットAPNの解決を、必ずしもサービングネットワークノード(MME/SGSN)ではなく、MTC−IWFにおいて実行する、またはMTC−IWFの支援を受けて実行することができるためである。
この方法における1つの主たる想定として、1つのMTCサーバまたはMTCアプリケーションから発行されるデバイストリガー要求メッセージの結果として、おそらくはユーザ機器から1つの特定のAPNへのデータ接続が確立される。したがって、この方法は、MTC−IWFまたはSGSN/MMEが、デバイストリガー要求メッセージの送信元(発行元ノード)または送り手に基づいてターゲットAPNを解決することのできる解決策を提供する。一般には、Tspインタフェースを通じてのデバイストリガー要求メッセージには、送信元エンティティまたは送信側エンティティのIDを示す情報要素またはパラメータが含まれるものと理解される。言い換えれば、Tspインタフェースを通じてのデバイストリガー要求メッセージは、一種の「MTCサーバID」パラメータを含む。したがって、この「MTCサーバID」は、少なくともMTC−IWFにおいて認識される。提案として、「MTCサーバID」をさらにT4インタフェースを通じて伝え、したがってSM−SCエンティティが「MTCサーバID」を格納することができる。「MTCサーバID」をSM−SCおよびMTC−IWFに格納することは、さまざまな目的に使用することができる。例えば、1つの目的は課金(課金が送り手ごと、すなわちMTCサーバごとに行われるとき)であり、別の目的は、デバイストリガー配信報告を生成して送り返すことである。
この実施形態では、「MTCサーバID」とターゲットAPNとの間の関係を、3GPPネットワークエンティティのいずれかにおいて維持することを提案する。いくつかのオプションが可能である。
・ 「MTCサーバID」とターゲットAPNとの間の関係を、加入情報リポジトリ(HSSまたはHLR)において維持する。MTC−IWFは、デバイストリガー要求メッセージを受信すると、HSS/HLRに連絡して、ユーザ機器の内部IDと、ユーザ機器が登録されているMMEまたはSGSNを解決する。新しい提案として、HSS/HLRは、(ユーザ機器のネットワーク内部IDに加えて)関連するターゲットAPNをMTC−IWFに報告することができる。
・ 「MTCサーバID」とターゲットAPNとの間の関係を、MTC−IWFにおいて維持する。この目的のため、MTC−IWFをこの情報を使用できるように構成するべきである。
・ 「MTCサーバID」とターゲットAPNとの間の関係を、SGSN/MMEにおいて作成する、またはSGSN/MMEによって維持する。しかしながら、SGSN/MMEはデバイストリガー要求の送信元を認識しない。したがって、「MTCサーバID」をMTC−IWFからSGSN/MMEに伝えるため、T5インタフェースプロトコルの拡張が必要である。克服するべき1つの問題は、デバイストリガリングにMT−SMSが使用されているときであり、なぜならその場合、「MTCサーバID」をSMSヘッダの中でSGSN/MMEに伝える必要があるが、SMSヘッダのサイズは限られているためである。したがって、このオプションは、T5インタフェースを通じてのデバイストリガリングの場合に容易に適用することができる。SGSN/MMEは、「MTCサーバID」を取得すると、HSS/HLRに問い合わせてターゲットAPNを解決することができ、または、SGSN/MMEは、「MTCサーバID」とターゲットAPNとの間の関係について自身のデータベースを維持する。なお、これは上記の最初のオプションに関連しており(すなわちHSS/HLRが「MTCサーバID」とターゲットAPNとの間の関係を格納している)、ただしMTC−IWFではなくSGSN/MMEが「MTCサーバID」を使用してHSS/HLRに問い合わせる。このオプションの1つの利点として、SGSN/MMEは、APNベースの輻輳制御が有効にされているかと、そのAPNがターゲットユーザ機器の加入APNの1つであるかの問い合わせを実行するのみでよい。
MTC−IWFは、デバイストリガー要求メッセージのターゲットAPNを解決した後、そのターゲットAPNを、追加のパラメータとして、例えばT5インタフェースを通じてSGSN/MMEに報告することができる。SGSN/MMEにおいては、上述したようにデバイストリガー要求メッセージおよびターゲットAPNを受信した後、別の実施形態において説明したようにデバイストリガー要求を処理する。例えば、SGSN/MMEは、デバイストリガー要求メッセージを送信するか拒否するかを、ネットワークにおけるAPN輻輳状況と、オプションとして、そのAPNへのPDN/PDPコンテキストが利用可能であるかに基づいて、決定する。
別の可能な方法として、SGSN/MMEが、有効にされているAPNベースの輻輳制御をMTC−IWFに報告する。MTC−IWFは、MMEに登録されているユーザ機器を対象とするデバイストリガー要求メッセージにフィルタリングを適用するかまたは拒否し、この場合、ターゲットAPNは、APNベースの輻輳制御下にあるものとMMEから報告されている。言い換えれば、MTC−IWFは、ターゲットAPNが輻輳制御下にあることを認識している場合、デバイストリガー要求メッセージをSGSN/MMEに転送しない。
要約すると、輻輳状態にある外部ネットワークの識別情報を求める目的で、トリガリングサーバの識別情報(MTCサーバ)と、端末がトリガーされたときにデータを報告するために接続するターゲット外部ネットワーク(APN)との間の関連性を、特定のネットワークエンティティが維持する。この関連性により、エンティティによって外部ネットワークを求めることが可能になる。これに代えて、このエンティティは、関連性、または検出された輻輳した外部ネットワークを、別のエンティティに送信することができる。具体的には、ネットワークエンティティは、MTC−IWF、SGSN/MME(サービングネットワークノード)、またはSM−SCとすることができる。
なお、本発明は、セッション管理輻輳制御に制限されず、モビリティ管理輻輳制御(MM CC)に適用することもできる。
本発明の大部分では、主として考慮されるシナリオとして、APNベースのSM CCについて説明してある。しかしながら、特に、デバイストリガー要求メッセージがMT−SMSにカプセル化される場合、MT−SMSを送信するか拒否するかのSGSN/MMEにおける決定は、APN SM CCに依存するのみならず、APNベースのMM CCおよび一般的なMM CCにも依存して行うことができる。MT−SMSの送信とMM CCとの間のこの相互関係の理由は、ユーザ機器の挙動であり、すなわち移動体着(MT)サービスについてページングされたとき、ユーザ機器はMM BOタイマーを終了させる必要がある。通常、3G(すなわちUMTS)においては、MT−SMSが送信されるとき、ユーザ機器は、シグナリング接続の確立を示す特殊な理由を伴ってページングされる。しかしながら、LTEの場合、またはPSのみの加入の場合、MT−SMSを送信する目的で移動体着(MT)ページング理由を伴ってユーザ機器がページングされるかは不確定である。さらに、ユーザ機器が、作動中のMM BOタイマーを停止させる理由としてページングを処理するかも不確定である。いずれにしても、SGSN/MMEはユーザ機器をページングすることをまったく望まないことがあり、なぜなら、たとえユーザ機器とSGSN/MMEの間のシグナリング接続の確立であっても、望ましくないMMシグナリングにつながるためである。
APNベースのMM CCの場合、ユーザ機器はSGSN/MMEに登録されず、トリガリングの種類はいわゆるオフラインデバイストリガリングである。オフラインデバイストリガリングの場合、SGSN/MMEは、登録されていないユーザ機器に到達するようにデバイストリガー要求メッセージをブロードキャストすることができる。問題点として、多くのユーザ機器がデバイストリガー要求メッセージの受信後にネットワークへのアタッチを試みることがあり、これらのユーザ機器に対してAPNベースのMM CCが有効にされている場合、多くのアタッチ試行は望ましくなく、なぜならMM CC状況が悪化するためである。デバイストリガー要求メッセージのブロードキャスト/送信を回避する目的で、SGSN/MMEは、デバイストリガー要求メッセージを送信する前に、デバイストリガーメッセージを処理して、ネットワークにおいてAPNベースのMM CCが有効にされているかを判定することができる。SGSN/MMEはターゲットユーザ機器のNAS MMコンテキストを有さないことがあるため(なぜならターゲットユーザ機器が登録されていない、またはネットワークにアタッチされていない)、この処理は複雑であることがある。SGSN/MMEがNAS MMコンテキストを有する場合、処理は以下に説明するとおりである。
以下では、一般的なMM CCに焦点を当てる。この場合、一般的なMM CC下にあるユーザ機器は、SGSN/MMEにおいてNAS MMコンテキストを有することができる。この場合の一般的な解決策として、SGSN/MMEは、デバイストリガー要求メッセージの受信後、ターゲットユーザ機器がMM CC下にあるか(すなわちSGSN/MMEがそのユーザ機器のMM BOタイマーを格納しているか)のチェックを実行する。SGSN/MMEは、たとえそのユーザ機器のMM BOタイマーを格納していない場合にも、ユーザ機器またはユーザ機器のグループの優先度、または何らかの他のパラメータが、現在進行中のMM CCに使用されているかチェックを実行することができる。一例として、ユーザ機器が「低優先度」に対して設定されており、現時点でSGSN/MMEがすべての低優先度ユーザ機器にMM CCを適用している。したがって、たとえユーザ機器が有効にされているMM BOタイマーを有さない場合でも、ページング後にユーザ機器のNAS MMシグナリングによってMM CC状況が悪化する可能性がある。以下は、SGSN/MMEにおける処理の条件である。
− ユーザ機器が一般的なMM CC下にあり、ネットワークにおけるMM CC状況が依然として進行中である場合、SGSN/MMEは、ユーザ機器をページングせず、デバイストリガー目的に使用されるMT−SMSを拒否することを決定することができる。SGSN/MMEは、別の実施形態において説明したように、SM−SCへの拒否されたデバイストリガー要求配信メッセージにMM BOタイマー値を含めることができる。SM−SCは、MT−SMSを格納するか、または失敗したデバイストリガー配信をMTCサーバ/アプリケーションに転送するかを、SGSN/MMEからのデバイストリガー配信報告の中でシグナリングされるSMSの有効時間およびMM BOタイマーの値に基づいて決定することができる(上の実施形態の1つにおいて説明した処理に似ている)。
− ユーザ機器が一般的なMM CC下にあり、ネットワークにおけるMM CCがそれ以上存在しない(すなわちMM CCが終了する)場合、SGSN/MMEは、ユーザ機器をページングすることを決定することができる。SGSN/MMEは、ユーザ機器が作動中のMM BOタイマーを停止することができるように、適切なページング理由を選択するべきである。
なお、上に説明した機能は、デバイストリガー目的に使用されるMT−SMSのための機能であり、すなわち、ユーザ機器は、MT−SMSの受信後、データ接続を確立または再設定する目的で追加のNAS MMシグナリングもしくはSMシグナリングまたはその両方をおそらく開始する。しかしながら、MT−SMSが「通常の」(デバイストリガー以外の目的の)SMSである場合、SGSN/MMEは、NAS MM/SMシグナリングがほとんどの場合にはMT−SMS送信のためのものである(すなわち追加のNAS MMシグナリングまたはSMシグナリングが発生しない)と結論することができ、したがってSGSN/MMEは、そのような「通常の」ユーザ機器を上記とは異なって扱うことができる。例えば、SGSN/MMEは、「通常の」MT−SMSを送信することを決定することができるのに対して、デバイストリガー目的に使用されるMT−SMSは拒否される。したがって、上述した、デバイストリガー目的に使用されるMT−SMSを判定する方法、特に、第6の可能な方法における解決策(デバイストリガー要求が送られるMT−SMSのヘッダから情報を取り出す)は、SGSN/MMEにおいて役立ち得る。オプションとして、SGSN/MMEは、MT−SMSが「通常の」SMSまたはデバイストリガーに関連するSMSであるとき、SM−SCエンティティに返される配信報告の中にさまざまな失敗理由を含めることができる。例えば、SGSN/MMEは、再送信抑制タイマーを配信報告に含めるか否かを決定することができる。さらに、SGSN/MMEは、「通常の」SMSの場合にのみ、「メッセージ待機フラグ」(ユーザ機器が到達可能になったときにHSS/HLRから指示情報が来ることをSM−SCに示す)を含めることを決定することができる。逆に、デバイストリガーに関連するSMSの場合、そのような「メッセージ待機フラグ」を回避することができ、なぜなら、MMEは配信報告の中で再送信抑制タイマーを使用することができるためである。
以下の実施形態では、この解決策の別の変形形態について説明する。ユーザ機器は、(図8および図9でユーザ機器における点「2)」を参照しながら上述したように)アップリンクデータが期限切れとなるものと判定した後、アップリンクデータの配信/有効性(SM−BOタイマー)の指示情報をSGSN/MMEまたはMTCサーバに送る代わりに、アップリンクデータを(例えばSMSまたはスモールデータとして)制御プレーンを通じて送ることを決定することができる。これが可能であるのは、SMSが制御プレーン接続を通じて送られ、新しいPDP/PDN接続のためのセッション管理シグナリングが必要ないためである。ユーザ機器は、報告/指示情報を生成して制御プレーンを通じてネットワークエンティティ(ただし最終的にはMTCサーバ宛)に送信することができるべきである。
この代替実施形態の1つの問題として、MTCサーバがSMSとしてのアップリンクデータを受信できないことがある。この問題が起こりうるのは、SMSが制御プレーン接続を通じて送られ、新しいPDP/PDN接続のためのセッション管理シグナリングが必要ないためである。この問題を解決するため、いくつかの解決策を適用することができる。
− ユーザ機器が、アップリンクIPデータをMO−SMSペイロード(または分割SMS)にカプセル化し、それをMTCサーバに送り、MTC−IWFがSMS(分割SMS)からアップリンクIPデータを取り出す。次いで、MTC−IWFはアップリンクIPデータをMTCサーバに転送する。この場合、MTC−IWFは、アップリンクIPデータを転送するときにIPルータとして動作する。
− ユーザ機器が、アップリンクデータをMO−SMSペイロード(または分割SMS)としてMTC−IWFに送る。MTC−IWFは、SMS(または分割SMS)データのペイロードをIPデータに変換する。この目的のため、MTC−IWFはIPパケットを生成する。MTC−IWFはIPパケットをMTCサーバに転送する。
なお、IPパケットがユーザ機器から送られたことをMTCサーバが認識するように、MTC−IWFは送信元IPアドレスをスプーフする必要がある。この目的のため、ユーザ機器は自身のIPアドレスについてMTC−IWFに通知する。オプションとして、IPアドレスのスプーフィングを回避する目的で、MTC−IWFはユーザ機器のホームエージェントとして動作することができる(モバイルIP仕様書である非特許文献7および非特許文献8を参照)。
本発明の実施形態によると、端末は、トリガリング要求の受信後、IPアドレスをサーバに報告することができる。デバイストリガリングは、一般的には、MTCサーバとの通信を確立するようにユーザ機器をトリガーするために使用される。この場合、一般的な想定として、ユーザ機器は、デバイストリガリングを受信した後、(ただちに、またはデータの収集/測定のため特定の遅延の後に)アップリンクデータを送る。しかしながら、MTCサーバから送られる、ユーザ機器のIPアドレスの要求として、デバイストリガリングを使用することも可能である。MTCサーバは、ユーザ機器のIPアドレスを使用してユーザ機器と通信する。言い換えれば、デバイストリガー要求は、PDP/PDN接続を確立してIPアドレスをMTCサーバに報告させるための、(ネットワークに対して不透明なデータの中の)ユーザ機器へのコマンド、またはネットワークへのコマンドを含んでいることができる。要求されたPDP/PDN接続がすでに存在する場合、ユーザ機器またはネットワークは、IPアドレスを報告する。この実施形態は、このシナリオの場合の可能な解決策を記述する。以下の2つの場合を扱う。
− デバイストリガリングが実行されるとき、PDP/PDN接続がすでに確立されている/存在する場合
− デバイストリガリングが実行されるとき、PDP/PDN接続が存在しない場合
デバイストリガリングが実行されるとき、PDP/PDN接続がすでに確立されている/存在する場合、ユーザ機器は、そのPDP/PDN接続に対して設定されているIPアドレスを有する。このIPアドレスは、ユーザ機器およびネットワークが認識している。デバイストリガリングによって、ユーザ機器が自身のIPアドレスを報告することが要求される場合、ユーザ機器は、IPアドレスを含む指示情報メッセージを、制御プレーンを介して、またはユーザプレーンを介して送る。デバイストリガリングによって、ネットワークがユーザ機器のIPアドレスを報告することが要求される場合、ネットワーク(おそらくはMTC−IWF)は、サービングコアネットワークノード(SGSN/MME)から、またはユーザプレーン上のネットワークノード(例:SGW、PGW、GGSN)から、IPアドレスを認識する。その後、ネットワーク(SGSN/MMEもしくはMTC−IWFまたはその両方)は、ユーザ機器のIPアドレスについてMTCサーバに通知する。
これに対して、デバイストリガリングが実行されるとき、PDP/PDN接続が存在しない場合、ユーザ機器は、要求されたPDP/PDN接続に対して設定されたIPアドレスを有さない。以下の2つのサブケースが考えられる。
− デバイストリガリングがユーザ機器を対象としている(すなわちトリガー要求が、ネットワークに対して不透明なデバイストリガーデータに含まれている)場合、ユーザ機器は、PDP/PDN接続の確立を開始する。ネットワーク内に適用されているSM CCが存在するため、ユーザ機器はPDP/PDN接続を確立することができず、したがって、ユーザ機器はIPアドレスを設定することができない。結果として、ユーザ機器は、PDP/PDN接続とIPアドレスを確立できないことを、制御プレーンを通じてMTCに報告することができる。言い換えれば、ユーザ機器は、エラー理由をMTCサーバに報告する必要がある。さらに、ユーザ機器は、SM−BOタイマー値(利用可能な場合)をMTCサーバに報告する。ユーザ機器は、報告/指示情報を生成して制御プレーンを通じてMTCサーバに送信することができる。
− デバイストリガリングの対象がネットワークである(すなわちネットワークがユーザ機器のIPアドレスをMTCサーバに報告するべきである)場合、ネットワークは、ネットワークによって開始されるPDP/PDN接続確立手順を実行する。GPRS/UMTSの場合、ネットワークによって開始されるPDP接続確立手順は標準化されている。EPSの場合、ネットワークによって開始されるPDN接続確立手順は、指定されていない。いずれの場合も、ネットワーク(特に、サービングコアネットワークノードまたは他の何らかのエンティティのNAS層におけるセッション管理サブレイヤ)は、PDP/PDN接続確立のためにネットワークによって開始されるSM要求を実行するかを評価し、なぜならネットワーク(SGSN/MME)は、要求されている/ターゲットのAPNに対して適用されているSM CCが存在するかを認識しているためである。ネットワーク(SGSN/MME)が、例えば高レベルのデバイストリガー要求に起因して、PDP/PDN接続確立のためにネットワークによってトリガーされるSM要求を開始することを決定する場合、SM CCに関連する問題は存在せず、なぜならSM CCは対応するユーザ機器のSM応答に適用されないためである。結果として、ネットワーク(SGSN/MMEもしくはMTC−IWFまたはその両方)は、PDP/PDN接続が正常に確立された後、ユーザ機器のIPアドレスについてMTCサーバに通知する。そうではなく、ネットワーク(SGSN/MME)がPDP/PDN接続確立のためにネットワークによってトリガーされるSM要求を開始しないことを決定する場合、ネットワーク(SGSN/MMEもしくはMTC−IWFまたはその両方)は、エラー理由についてと、オプションとして、SM CCが適用される遅延(SM−BOタイマー値)について、MTCサーバに通知する。
要約すると、端末側においては、送信ユニットを、端末のネットワークアドレス(IPアドレスなど)をサーバに送信するようにさらに構成することができる。特に、端末の受信ユニットは、トリガー要求を評価ユニットに提供することができ、評価ユニットは、端末のネットワークアドレスをサーバに報告することを決定する。これに代えて、ネットワークノードが、ネットワークアドレスをサーバに報告することができる。したがって、データをサーバに送信するためのネットワークノードの送信ユニットは(上記の第2の送信ユニットを参照)、端末のネットワークアドレスを、配信遅延指示情報の中で、またはこれとは個別に提供するようにさらに構成することができる。
図10は、本発明の上述した実施形態を実施するために、端末において実行される方法のステップと、ネットワークノードにおいて実行される方法のステップと、サーバにおいて実行される方法のステップとを示している。具体的には、サーバにおいて、トリガー要求が生成される(1032)。生成されたトリガー要求は、ネットワークノードを含むネットワークを通じて端末に送信される(1034)。一実施形態においては、ネットワークノードがトリガー要求を格納および評価することができ、別の実施形態においては、トリガー要求をネットワークノードに対して透過的に端末に直接送ることができる。実施形態によると、端末は、トリガー要求を受信し(1011)、ネットワークとの接続を確立できるか否かについての評価を実行し(1013)、この評価ステップは、ネットワークが輻輳しているか、もしくは、送信されるデータの準備ができているか、またはその両方を判定するステップを含んでいることができる。評価の後、特に、輻輳が検出される、またはデータの準備ができていない場合、配信遅延インジケータがサーバに送信され(1015)、このインジケータは、評価の結果によるとトリガー後にサーバとの接続を確立できないこと、またはデータ送信が遅延することのうちの少なくとも一方(これらは輻輳状況のため、またはデータが利用可能ではないことによる)を示す。なお、評価ステップ1013は、端末におけるバックオフタイマー、もしくは、ネットワークノードからトリガー要求シグナリング1021と一緒に、または個別に端末にシグナリングされうるトリガー有効時間、またはその両方に基づいて、データの有効性を求めるステップを含んでいることもできる。この実施形態に代えて、ネットワークノードが、データの配信遅延またはデータが配信されないことについてサーバに通知することができる。これは図10においてネットワークノードの側に示してあり、サーバからのトリガー要求を受信するステップ1021の後、場合によってはトリガー要求を格納し、端末からサーバへの接続を確立できるか否かを評価し、この評価ステップは、ネットワークが輻輳しているか、ユーザ機器においてバックオフタイマーが作動しているか、端末におけるバックオフタイマーの残り時間、のうちの少なくとも1つを判定するステップを含む。格納するステップは、少なくとも端末ID、サーバのID、任意の他のトランザクションIDのうちの1つまたは複数を含む、トリガー要求の状態を格納する目的で有利に実行することができる。これにより、データの配信もしくはデータの遅延またはその両方の可能性をネットワークノードが評価することを可能にする目的で、端末がデータを送信するネットワークを識別することが可能になる。評価および場合によっては格納するステップ1023の後、ネットワークノードによって配信遅延指示情報がサーバに送信される(1025)。サーバ側では、上述した2つの実施形態それぞれの場合に、端末から、またはネットワークノードから、配信遅延指示情報が受信される(1036)。次いで、サーバは、上述したように、配信遅延指示情報を使用してさらなるステップを決定することができる(1038)。
図11は、本発明の実施形態による、端末1110と、ネットワークノード1120と、サーバ1130の機能ブロックを示している。具体的には、端末1110は、端末機能を実行する通常の機能ブロック1117を含んでおり、さらに、サーバからのトリガー要求を受信する受信ユニット1113と、接続を確立できるか否か、送信されるデータの準備ができているか、データを送信できるか、のうちの少なくとも1つを評価する評価ユニット1114を含んでいる。さらに、端末1110は、評価ユニット1114の評価結果に基づいて配信遅延インジケータをサーバに送信する送信ユニット1115を含んでいる。さらに、端末1110は、有効データの有効時間を求める処理ユニット1116(有効性チェックユニットとも称する)を含んでいることができる。これらのユニットは、デバイストリガリングの能力を提供するブロックを含む、端末のデバイストリガリング部分1111に含まれている。
ネットワークノード1120も、ネットワークノードの一般的な機能に対応するユニット1127と、デバイストリガリング手順の能力に関連するユニット1121とを含んでいる。具体的には、送信ユニット1123は、トリガー要求を端末に送信するように構成されている。評価ユニット1124は、接続を確立できるか、もしくは、端末からデータを送信できるか、またはその両方を、ネットワーク輻輳の評価と、端末において作動しているバックオフタイマーのうちの少なくとも一方に基づいて評価するように構成されている。第2の送信ユニット1125は、評価ユニットからの入力に従って配信遅延インジケータをサーバに送信するように構成されている。さらに、ネットワークノードには、トリガー要求に関する情報(例えば、端末の識別情報、トリガー要求の発行元であるノードの識別情報、サーバの識別情報など)を格納する格納手段1126を設けることができる。
最後に、サーバ1130は、サーバの一般的な機能を提供する手段1137と、デバイストリガリングの能力に関連する手段1131とを含んでいる。具体的には、サーバは、トリガリング要求を送信する送信ユニット1135と、ネットワークまたは端末から配信遅延指示情報を受信する受信ユニット1133と、受信されたインジケータおよび送られたトリガー要求に基づいて、さらなる処理方法について決定する処理ユニット1134とを含んでいる。
背景技術のセクションに示した説明は、本明細書に記載されている特定の例示的な実施形態を深く理解できるようにすることを目的としており、3GPPの標準規格に準拠するネットワークなどのモバイル通信ネットワークにおけるプロセスおよび機能の、説明されている特定の実施形態に、本発明を制限するものではないことを理解されたい。しかしながら、本明細書に提案されている改良・改善は、背景技術のセクションに説明されているアーキテクチャ/システムに容易に適用することができ、本発明のいくつかの実施形態において、これらのアーキテクチャ/システムの標準の手順と、改良された手順とを利用することもできる。具体的な実施形態に示した本発明には、広義に記載されている本発明の概念または範囲から逸脱することなく、さまざまな変更もしくは修正またはその両方を行うことができることが、当業者には理解されるであろう。
本発明の別の実施形態は、ハードウェアおよびソフトウェアを使用して、上述したさまざまな実施形態を実施することに関する。本発明のさまざまな実施形態は、コンピューティングデバイス(プロセッサ)を使用して実施または実行することができるものと認識される。コンピューティングデバイスまたはプロセッサは、例えば、汎用プロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)、または、その他プログラマブルロジックデバイスなどである。本発明のさまざまな実施形態は、これらのデバイスの組合せによっても実行または具体化され得る。
さらに、本発明のさまざまな実施形態は、ソフトウェアモジュールによっても実施することができる。これらのソフトウェアモジュールは、プロセッサによって実行され、または、ハードウェアにおいて直接実行される。また、ソフトウェアモジュールとハードウェア実装の組合せも可能である。ソフトウェアモジュールは、任意の種類のコンピュータ可読記憶媒体、例えば、RAMやEPROM、EEPROM、フラッシュメモリ、レジスタ、ハードディスク、CD−ROM、DVDなどに格納することができる。
以下では、本発明に関連する実施形態について要約する。
本発明の第1の態様によると、通信ネットワークにおいて端末をトリガーする方法を提供する。本方法は、端末において実行され、以下に記載するステップを含んでいる。トリガー要求を受信するステップは、端末からサーバへの接続の確立(もしくはデータ送信またはその両方)をトリガーすることを目的とする。トリガー要求は、サーバによって通信ネットワークを通じて端末に送られるものと想定する。接続を確立できるか、もしくは、データを送信できるか、またはその両方を評価するステップは、ネットワークが輻輳しているか、もしくは送信されるデータの準備ができているか、またはその両方を判定するステップを含んでいる。最後に、配信遅延インジケータをサーバに送信するステップは、評価結果によると輻輳状況に起因してトリガーの後にサーバとの接続を確立できないこと、またはデータ送信が遅延することのうちの少なくとも一方を示す目的で設けられている。
本発明の第1の態様に対応して、本発明の別の態様によると、ネットワークノードを含む通信ネットワークにおいて端末をトリガーする方法であって、トリガリングサーバにおいて実行される、方法、を提供する。本方法は、端末からサーバへの接続の確立またはデータの送信をトリガーするトリガー要求を通信ネットワークを通じて端末に送信するステップと、トリガーの後にデータを送信できないこと、またはトリガリング遅延のうちの少なくとも一方を示す配信遅延メッセージを、ネットワークノードまたは端末から受信するステップと、を含んでいる。
しかしながら、本発明は、ユーザ機器によってではなくネットワークノードによって採用することもできる。したがって、本発明の別の態様によると、ネットワークノードを含む通信ネットワークにおいて端末をトリガーする方法であって、本方法がネットワークノードにおいて実行され、端末からサーバへのデータの送信または接続の確立をトリガーするトリガー要求を端末に送信するステップと、端末からサーバへの接続を確立できるか(またはデータを送信できるか)を評価するステップであって、ネットワークが輻輳しているか、バックオフタイマーが作動しているか、端末におけるバックオフタイマーの残り時間、のうちの少なくとも1つを判定するステップを含む、ステップと、トリガー後にサーバとの接続を確立できないこと、データを送信できないこと、データ送信が遅延すること、のうちの少なくとも1つを示す配信遅延メッセージをサーバに送信するステップと、を含んでいる、方法、を提供する。
特に、送信するステップは、制御プレーンを通じて行うことができる。
端末において実行される方法は、ネットワークノードから輻輳インジケータを受信するステップであって、輻輳インジケータが、端末にネットワークとのユーザプレーン接続をただちに確立させるコマンド、または、ネットワークが同じデバイストリガー要求を端末に配信することを試みる時間長を示すデバイストリガー有効時間、のうちの少なくとも一方を含む、ステップ、をさらに含んでいることが有利である。
これによって提供される利点として、端末が状況を評価する(すなわち輻輳が起きているかを判定する)ことと、状況に応じて送られるデータの有効性を推定することとが可能になる。
本方法は、トリガー要求が受信された後、ネットワークを通じてサーバに送信されるデータを収集するのに必要な時間期間としてのデータの有効時間、または、ネットワークが同じデバイストリガー要求を端末に配信することを試みる時間長を示すデバイストリガー有効時間としてのデータの有効時間を求めるステップと、端末においてバックオフタイマーが作動しており、データの有効時間が残りのバックオフ時間より小さい場合に、データが期限切れとなること、もしくは、トリガー要求に応えてデータが送られないこと、またはその両方を示す配信遅延メッセージをサーバに示すステップと、をさらに含んでいることが好ましい。
データの有効性を求め、それをサーバに送信することによって提供される利点として、サーバはさらなる動作について効率的に決定することが可能になる。
ネットワークノードにおいて実行される方法は、端末のID、もしくは、トリガリング要求メッセージを送ったデバイスのID、またはその両方を含む、トリガー要求の状態を格納するステップと、配信遅延メッセージを送信するステップであって、配信遅延メッセージが、端末のID、もしくは、トリガリング要求メッセージを送ったデバイスのID、またはその両方を含む、ステップと、をさらに含んでいることが有利である。
トリガー要求の状態および端末の識別情報を格納することによって提供される利点として、特定のシナリオにおいてネットワークが配信遅延の指示情報をサーバに提供することが可能になる。
(端末側またはネットワークノード側における)評価ステップは、端末からサーバにデータを送信するかを決定する、もしくは、端末からサーバへのデータの送信の遅延を求める、またはその両方を目的として、端末側において作動しているバックオフタイマーを評価するステップ、もしくは、端末によって送信されるデータの有効期間を評価するステップ、またはその両方を、さらに含んでいることができる。
本発明の別の態様によると、通信ネットワークの端末であって、端末からサーバへの接続の確立をトリガーするトリガー要求を受信する受信ユニットであって、トリガー要求がサーバによって通信ネットワークを通じて端末に送られる、受信ユニットと、接続を確立することができるか否かを評価する評価ユニットであって、ネットワークが輻輳しているか、もしくは、送信されるデータの準備ができているか、またはその両方を判定するステップを含む、評価ユニットと、評価結果によると輻輳状況に起因してトリガーの後にサーバとの接続を確立できないこと、またはデータ送信が遅延することのうちの少なくとも一方を示す配信遅延インジケータをサーバに送信する送信ユニットと、を備えている、端末、を提供する。
受信ユニットは、端末にネットワークとのユーザプレーン接続をただちに確立させるコマンド、または、ネットワークが同じデバイストリガー要求を端末に配信することを試みる時間長を示すデバイストリガー有効時間、のうちの少なくとも一方を含む輻輳インジケータを、ネットワークノードから受信するように、さらに構成することができる。
本端末は、トリガー要求が受信された後に、データの有効時間を、ネットワークを通じてサーバに送信されるデータを収集するのに必要な時間期間として、または、ネットワークが同じデバイストリガー要求を端末に配信することを試みる時間長を示すデバイストリガー有効時間として、求める有効性チェックユニット、をさらに備えていることができる。端末においてバックオフタイマーが作動しており、データの有効時間が残りのバックオフ時間より小さい場合に、データが期限切れとなること、もしくは、トリガー要求に応えてデータが送られないこと、またはその両方を示す配信遅延メッセージをサーバに示すように、送信ユニットをさらに構成することができる。
本発明のさらに別の態様によると、通信ネットワークにおいて端末をトリガーするネットワークノードであって、通信ネットワークの一部である、ネットワークノード、を提供する。本ネットワークノードは、端末からサーバへの接続の確立をトリガーするトリガー要求を端末に送信する第1の送信ユニットと、端末からサーバへの接続を確立できるか否かを評価する評価ユニットであって、ネットワークが輻輳しているかと、バックオフタイマーが作動しているかと、端末におけるバックオフタイマーの残り時間、のうちの少なくとも1つを判定するステップを含む、評価ユニットと、トリガーの後にサーバとの接続を確立できないこと、またはデータ送信が遅延することのうちの少なくとも一方を示す配信遅延メッセージをサーバに送信する第2の送信ユニットと、を備えている。
ネットワークノードは、端末のID、もしくは、トリガリング要求メッセージを送ったデバイスのID、またはその両方を含む、トリガー要求の状態を格納する格納手段、をさらに備えていることが有利である。第2の送信ユニットは、配信遅延メッセージを送信するようにさらに構成することができ、配信遅延メッセージは、端末のID、もしくは、トリガリング要求メッセージを送ったデバイスのID、またはその両方を含む。
端末もしくはネットワークノードまたはその両方の評価ユニットは、端末からサーバにデータを送信するかを決定する、もしくは、端末からサーバへのデータの送信の遅延を求める、またはその両方を目的として、端末側において作動しているバックオフタイマーを評価する、もしくは、端末によって送信されるデータの有効期間を評価する、またはその両方を行うように構成されていることが好ましい。
本発明の別の態様によると、ネットワークノードを含む通信ネットワークにおいて端末をトリガーするサーバを提供する。サーバは、端末からサーバへの接続の確立またはデータの送信をトリガーするトリガー要求を通信ネットワークを通じて端末に送信する送信ユニットと、トリガーの後にデータを送信できないこと、またはトリガリング遅延のうちの少なくとも一方を示す配信遅延メッセージを、ネットワークノードまたは端末から受信する受信ユニットと、を備えている。さらに、サーバは、トリガー要求を後の時点で再送信するか、トリガー要求を高い優先度で再送信するか、または同じネットワークについては別の端末へのトリガー要求の送信を省くのかを判定するため、配信遅延インジケータを処理する処理ユニットを、さらに含んでいることができる。本方法は、トリガー要求を後の時点で再送信するか、トリガー要求を高い優先度で再送信するか、または同じネットワークについては別の端末へのトリガー要求の送信を省くのかを判定するため、配信遅延インジケータを処理するステップ、をさらに含んでいることができる。
要約すると、本発明は、輻輳制御の場合におけるデバイストリガリングに関する。トリガリングサーバは、サービングネットワークノードを含む通信ネットワークを通じてデバイストリガー要求を端末に送信する。サービングネットワークノードは、メッセージにカプセル化された透過的なデバイストリガー要求を受信する。サービングネットワークノードは、受信されたメッセージがデバイストリガリングに関連するかを判定する目的で、端末のデバイストリガリング能力を判定し、それに基づき、適用されている輻輳制御に応じて、メッセージを端末に転送するか否かを決定する。この方法では、輻輳の場合におけるシグナリングトラフィックが減少し、なぜなら、端末がデバイストリガリングに応えて接続の確立およびデータの送信を試みることが防止されるためである。