JP6077561B2 - デバイストリガリングおよびａｐｎベースの輻輳制御 - Google Patents

デバイストリガリングおよびａｐｎベースの輻輳制御 Download PDF

Info

Publication number
JP6077561B2
JP6077561B2 JP2014546398A JP2014546398A JP6077561B2 JP 6077561 B2 JP6077561 B2 JP 6077561B2 JP 2014546398 A JP2014546398 A JP 2014546398A JP 2014546398 A JP2014546398 A JP 2014546398A JP 6077561 B2 JP6077561 B2 JP 6077561B2
Authority
JP
Japan
Prior art keywords
user equipment
terminal
network
mme
sgsn
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2014546398A
Other languages
English (en)
Other versions
JP2015511409A5 (ja
JP2015511409A (ja
Inventor
ジェナディ ヴェルヴ
ジェナディ ヴェルヴ
イェンス バッハマン
イェンス バッハマン
啓吾 阿相
啓吾 阿相
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Panasonic Intellectual Property Corp of America
Original Assignee
Panasonic Intellectual Property Corp of America
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Panasonic Intellectual Property Corp of America filed Critical Panasonic Intellectual Property Corp of America
Publication of JP2015511409A publication Critical patent/JP2015511409A/ja
Publication of JP2015511409A5 publication Critical patent/JP2015511409A5/ja
Application granted granted Critical
Publication of JP6077561B2 publication Critical patent/JP6077561B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/10—Flow control between communication endpoints
    • H04W28/12—Flow control between communication endpoints using signalling between network elements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q3/00—Selecting arrangements
    • H04Q3/0016—Arrangements providing connection between exchanges
    • H04Q3/0029—Provisions for intelligent networking
    • H04Q3/0045—Provisions for intelligent networking involving hybrid, i.e. a mixture of public and private, or multi-vendor systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/70—Services for machine-to-machine communication [M2M] or machine type communication [MTC]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/0289—Congestion control

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Telephonic Communication Services (AREA)

Description

本発明は、通信システムにおいてサーバによって端末をトリガーすることに関する。特に、本発明は、輻輳制御を考慮する効率的なトリガリングメカニズムを提供することに関する。
第３世代パートナーシッププロジェクト（３ＧＰＰ）組織は、例えばＧＳＭ（Global System for Mobile Communications）やＵＭＴＳ（ユニバーサル移動体通信システム：Universal Mobile Telecommunications System）などのモバイルセルラーネットワークのアーキテクチャの仕様を策定している。ＷＣＤＭＡ（登録商標）無線アクセス技術をベースとする第３世代の移動通信システム（３Ｇ）（ＵＭＴＳなど）は、世界中で広範な規模で配備されつつある。この技術を機能強化または進化・発展させるうえでの最初のステップとして、高速ダウンリンクパケットアクセス（ＨＳＤＰＡ）と、エンハンストアップリンク（高速アップリンクパケットアクセス（ＨＳＵＰＡ）とも称する）とが導入された。しかしながら、より長期的な展望においては、さらに高まるユーザの需要に対応し、新しい無線アクセス技術に対する競争力をつける必要がある。この課題を満たすため、３ＧＰＰは、進化型３ＧＰＰパケット交換ドメイン（ＥＰＳ（進化型パケットシステム：Evolved Packet System）という名称でも知られている）につながる検討項目に着手した。ＥＰＳは、Ｅ−ＵＴＲＡＮ（進化型ユニバーサル地上無線アクセスネットワーク：Evolved Universal Terrestrial Radio Access Network）と称される新しい世代のアクセスネットワーク技術と、ＵＴＲＡＮ（ユニバーサル地上無線アクセスネットワーク：Universal Terrestrial Radio Access Network）と称されるＥ−ＵＴＲＡＮの前バージョンを結合することのできるＥＰＣ（進化型パケットコア：Evolved Packet Core）ネットワークを組み合わせる。Ｅ−ＵＴＲＡＮの代わりに広く使用されている（かつ同じ意味を有する）別の用語は、ＬＴＥ（ロングタームエボリューション：Long Term Evolution）である。ＬＴＥは、今後１０年間にわたり、データおよびメディアの高速伝送ならびに大容量の音声サポートに要求される加入者およびネットワーク事業者のニーズを満たすように設計されている。
図１は、ネットワークエンティティおよびそれらの間のインタフェースを含むＬＴＥネットワークアーキテクチャを例示的に示している。図１から理解できるように、ＬＴＥアーキテクチャは、ＵＴＲＡＮやＧＥＲＡＮ（GSM EDGE Radio Access Network）などの異なる無線アクセスネットワーク（ＲＡＮ）の相互接続をサポートしており、これらはＳＧＳＮ（サービングＧＰＲＳサポートノード：Serving GPRS Support Node）を介してＥＰＣに接続されている。以下では、本発明の例示的な実施形態の理解を容易にする目的で、いくつかのエンティティおよびインタフェースについて説明する。
３ＧＰＰモバイルネットワークにおいては、移動端末１１０（ユーザ機器、ＵＥ、またはデバイスと称される）は、ＵＴＲＡＮではＮｏｄｅＢ（ＮＢ）を介してアクセスネットワークにアタッチされ、Ｅ−ＵＴＲＡＮアクセスでは進化型ＮｏｄｅＢ（基地局装置、ｅＮＢ）を介してアクセスネットワークにアタッチされる。エンティティＮＢ１２０およびｅＮＢ１２０は、他のモバイルネットワークにおいては基地局として知られている。本文書では、ＮＢおよびｅＮＢの共通の呼称として（ｅ）ＮＢが使用される。ＥＰＳ内には、ユーザ機器のモビリティをサポートするための２つのデータパケットゲートウェイとして、サービングゲートウェイ（ＳＧＷ）１３０とパケットデータネットワークゲートウェイ１６０（ＰＤＮ−ＧＷまたは略してＰＧＷ）が位置している。ＳＧＷは、無線アクセスネットワーク（例えばＵＴＲＡＮやＥ−ＵＴＲＡＮ）に向かうインタフェースを終端させる。１つの無線アクセスネットワーク（ＵＴＲＡＮまたはＥ−ＵＴＲＡＮ）内のモビリティは、アクセスに固有である。ＥＰＣ内のモビリティは、ＰＧＷによって管理される。ＰＧＷとＳＧＷとの間のＥＰＣ内のモビリティ管理は、ＰＭＩＰ（Proxy MIPv6）プロトコルまたはＧＴＰ（GPRS Tunneling Protocol）のいずれかに基づくことができる。ＳＧＷとＰＧＷとの間のインタフェースはＳ５と称され、Ｓ５は、ＧＴＰまたはＰＭＩＰｖ６プロトコルのいずれかに基づくことができる。ＰＧＷは、ユーザ機器へのＩＰアドレスの割当てと、ユーザ機器のトラフィックを適切なサービス品質（ＱｏＳ）レベルにマッピングするためのパケットフィルタリング（例：ディープパケットインスペクション、パケットスクリーニング）とをさらに実行する。
Ｅ−ＵＴＲＡＮアクセスを想定すると、エンティティｅＮＢ１２０は、１つまたは複数のＳＧＷにＳ１−Ｕインタフェース（「Ｕ」は「ユーザプレーン」を意味する）を介して有線を通じて接続することができ、ＭＭＥ（モビリティ管理エンティティ）１４０にはＳ１−ＭＭＥインタフェースを介して接続することができる。Ｓ１−ＵインタフェースはＧＴＰプロトコルに基づいており、Ｓ１−ＭＭＥインタフェースはＳ１−ＡＰプロトコルに基づいている。
ＳＧＳＮ１５０およびＭＭＥ１４０は、サービングコアネットワーク（ＣＮ）ノードとも称される。これらのネットワークノードは、ネットワークにおけるユーザ機器のコンテキスト、すなわち、セキュリティパラメータ、モビリティ管理に使用されるパラメータ（例：ユーザ機器が到達可能である場合にユーザ機器がキャンプしているセル）、およびセッション管理（ＳＭ）に使用されるパラメータ（例えば通信セッションを記述するＱｏＳパラメータ）、を維持する。
ＳＧＷ１３０は、ユーザデータパケットをルーティングして転送する一方で、基地局装置（ｅＮｏｄｅＢ）間のハンドオーバー時におけるユーザプレーンのモビリティアンカーとして機能し、さらに、ＬＴＥと別の３ＧＰＰ技術との間のモビリティのためのアンカー（Ｓ４インタフェースを終端させ、２Ｇ／３ＧシステムとＰＤＮ ＧＷとの間でトラフィックを中継する）として機能する。ＳＧＷは、アイドル状態のユーザ機器に対しては、ダウンリンクデータ経路を終端させ、そのユーザ機器へのダウンリンクデータが到着したときにページングをトリガーする。ＳＧＷは、ユーザ機器のコンテキスト（例えばＩＰベアラサービスのパラメータ、ネットワーク内部ルーティング情報）を管理および格納する。さらに、ＳＧＷは、合法傍受（lawful interception）の場合にユーザトラフィックの複製を実行する。
ＭＭＥ１４０は、ＬＴＥのアクセスネットワークの主要な制御ノードである。ＭＭＥは、アイドルモードのユーザ機器の追跡およびページング手順（再送信を含む）の役割を担う。ＭＭＥは、ベアラの有効化／無効化プロセスに関与し、さらには、最初のアタッチ時と、コアネットワーク（ＣＮ）ノードの再配置を伴うＬＴＥ内ハンドオーバー時とに、ユーザ機器のＳＧＷを選択する役割も担う。ＭＭＥは、（ＨＳＳと対話することによって）ユーザを認証する役割を担う。非アクセス層（ＮＡＳ：Non-Access Stratum）シグナリングはＭＭＥにおいて終端され、ＭＭＥは、一時的なＩＤを生成してユーザ機器に割り当てる役割も担う。ＭＭＥは、サービスプロバイダの公衆陸上移動網（ＰＬＭＮ：Public Land Mobile Network）に入るためのユーザ機器の認証をチェックし、ユーザ機器のローミング制約を実施する。ＭＭＥ１４０は、ＮＡＳシグナリングの暗号化／整合性保護においてネットワーク内の終端点であり、セキュリティキーの管理を行う。シグナリングの合法傍受も、ＭＭＥによってサポートされる。さらに、ＭＭＥは、ＬＴＥのアクセスネットワークと２Ｇ／３Ｇのアクセスネットワークとの間のモビリティのための制御プレーン機能を提供し、ＳＧＳＮ１５０からのＳ３インタフェースを終端させる。さらに、ＭＭＥは、ローミングするユーザ機器のためのＨＳＳ（ホーム加入者サーバ）に向かうＳ６ａインタフェースを終端させる。
Ｅ−ＵＴＲＡＮは基地局装置を備えており、基地局装置は、パケットデータ制御プロトコル（ＰＤＣＰ）層プロトコル、無線リンク制御（ＲＬＣ）層プロトコル、メディアアクセス制御（ＭＡＣ）層プロトコル、および物理（ＰＨＹ）層プロトコルによってＥ−ＵＴＲＡユーザプレーンを提供し、ユーザ機器に向かう無線リソース制御（ＲＲＣ）プロトコルの終端処理によって制御プレーンを提供する。基地局装置（ｅＮｏｄｅＢまたはｅＮＢ）は、ＰＨＹ層、ＭＡＣ層、ＲＬＣ層、およびＰＤＣＰ層（これらの層はユーザプレーンのヘッダ圧縮および暗号化の機能を含む）をホストする。ユーザ機器と基地局装置との間の制御プレーンにおいてＲＬＣ層によって提供されるサービスは、シグナリング無線ベアラ（ＳＲＢ）と称される。ユーザ機器と基地局装置との間のユーザプレーンにおいてＲＬＣ層によって提供されるサービスは、無線ベアラ（ＲＢ）またはデータ無線ベアラ（ＤＲＢ）と称される。基地局装置は、制御プレーンに対応するＲＲＣ機能も提供する。基地局装置は、無線リソース管理、アドミッション制御、スケジューリング、交渉によるアップリンクＱｏＳ（サービス品質）の実施、セル情報のブロードキャスト、ユーザプレーンデータおよび制御プレーンデータの暗号化／復号化、ダウンリンク／アップリンクのユーザプレーンパケットヘッダの圧縮／復元など、多くの機能を実行する。複数の基地局装置は、Ｘ２インタフェースによって互いに接続されている。
特に、上位層（すなわち非アクセス層（ＮＡＳ））のメッセージは、ユーザ機器と基地局装置との間でＲＲＣメッセージによって（例：ＲＲＣ直接情報転送メッセージを使用して）伝えられる。非アクセス層とは、ユーザ機器とコアネットワーク（ＣＮ）との間に延びる機能層であり、ＲＲＣの上に位置する。さらに、非アクセス層（ＮＡＳ）は、回路交換音声／データのための呼制御（ＣＣ）と、パケット交換データのためのセッション管理（ＳＭ）およびモビリティ管理（ＭＭ）と、パケット交換ドメインおよび回路交換ドメインのためのショートメッセージサービス（ＳＭＳ）とを目的とするプロトコルの機能グルーピングである。ＮＡＳ層によって生成される制御メッセージはＮＡＳメッセージと称される。このようなメッセージは、例えば、モビリティ管理、セッション管理、ＳＭＳ転送、および呼管理を制御するために使用される。ＮＡＳメッセージは、ＮＡＳトランスポートをサポートするための機能およびプロトコルを含むアクセス層の層（層３−２−１、ＲＲＣ、ＰＤＣＰ、ＲＬＣ、ＭＡＣ、ＰＨＹ）を通じて透過的に伝送される。ユーザ機器は、最初の非アクセス層メッセージを送る目的で、最初に基地局装置とのＲＲＣ（無線リソース制御）接続をエアインタフェース（Ｕｕインタフェース）を通じて確立する。ＲＲＣ接続の確立時、ユーザ機器と基地局装置は同期し、非アクセス層メッセージの伝送に使用することのできるシグナリング無線ベアラ（ＳＲＢ）を確立する。
アクセス層は、アクセス技術（この場合にはＲＲＣ、ＰＤＣＰ、ＲＬＣ、ＭＡＣ、およびＰＨＹ）に固有なプロトコルの機能グルーピングである。アクセス層は、無線に関する情報の伝送をサポートするためのプロトコルと、ユーザ機器とアクセスネットワークとの間で無線リソースの使用を調整するためのプロトコルと、アクセスネットワークによって提供されるリソースへのサービングネットワークからのアクセスをサポートするためのプロトコルとを含んでいる。アクセス層は、サービスアクセスポイント（ＳＡＰ）を通じて非アクセス層にサービスを提供する（コアネットワークに関連するシグナリングおよびサービス）、すなわち、ユーザ機器とコアネットワークとの間のアクセスリンクを提供し、このアクセスリンクは、ユーザ機器とコアネットワーク間の１つまたは複数の独立かつ同時の無線アクセスベアラサービスと、ユーザ機器の上位層エンティティとコアネットワークとの間のただ１つのシグナリング接続とから構成される。
ユーザ機器は、そのスイッチがオフになっている、またはモバイルネットワークにアタッチされていないときには、ＤＥＲＥＧＩＳＴＥＲＥＤ（登録解除）状態にある。ＤＥＲＥＧＩＳＴＥＲＥＤ（登録解除）状態においては、ＥＭＭコンテキストが存在せず、ユーザ機器の位置はＭＭＥによって認識されておらず、したがってＭＭＥはユーザ機器に到達できない。
移動端末（またはユーザ機器、ＵＥ）がネットワークにアタッチされているときには、ユーザ機器はいわゆるＲＥＧＩＳＴＥＲＥＤ（登録）状態にあり、すなわち、ＥＰＳモビリティ管理（ＥＭＭ）コンテキストが確立されており、デフォルトのＥＰＳベアラコンテキストがネットワークおよびユーザ機器において有効になっている。ユーザ機器がモバイルネットワークに「登録」されているとき、ユーザ機器は、２つの異なる接続管理状態として、ＩＤＬＥ（アイドル）状態およびＣＯＮＮＥＣＴＥＤ（接続）状態のいずれかをとることができる。
送信するデータが存在せず、無線リソースが解放されているが、ユーザ機器が依然として有効なＩＰ設定を有するとき、そのユーザ機器はＩＤＬＥ（アイドル）状態にある。ＩＤＬＥ（アイドル）状態にあるユーザ機器は、基地局装置との無線アソシエーション（すなわち無線リソース接続：ＲＲＣ）を有さず、したがって、シグナリング無線ベアラおよびデータ無線ベアラが確立されていない。さらに、ユーザ機器とネットワーク（例：ＭＭＥ）との間の非アクセス層（ＮＡＳ）シグナリング接続が存在せず、基地局装置とＳＧＷとの間のＳ１−Ｕ接続も存在しない。
ユーザ機器がＣＯＮＮＥＣＴＥＤ（接続）状態にあり、ユーザ機器が特定の期間にわたりデータを送信／受信していないことをネットワーク（通常では基地局装置）が検出すると、ネットワーク（通常では基地局装置）は、無線リソースとＳ１接続を解放することを決定する。結果として、ユーザ機器はＣＯＮＮＥＣＴＥＤ（接続）状態からＩＤＬＥ（アイドル）状態に移行する。さらに、ＭＭＥは、そのユーザ機器に対する自身の内部状態をＩＤＬＥ（アイドル）に変更し、基地局装置とのＳ１−Ｕ接続を解放するようにＳＧＷに通知する。
上述したＩＤＬＥ（アイドル）状態およびＣＯＮＮＥＣＴＥＤ（接続）状態は、ＮＡＳ層状態図に関連する。その一方で、ＡＳ層においてもＩＤＬＥ（アイドル）状態およびＣＯＮＮＥＣＴＥＤ（接続）状態が定義される。ＡＳ ＩＤＬＥ（アクセス層アイドル）状態およびＡＳ ＣＯＮＮＥＣＴＥＤ（アクセス層接続）状態は似ているが、ＮＡＳ ＩＤＬＥ（非アクセス層アイドル）状態およびＮＡＳ ＣＯＮＮＥＣＴＥＤ（非アクセス層接続）状態と完全には同じではなく、すなわち、ＲＲＣ接続が確立されている場合、ＡＳ状態はＣＯＮＮＥＣＴＥＤ（接続）であり、ＲＲＣ接続が解放されている場合、ＡＳ状態はＩＤＬＥ（アイドル）である。ＡＳ状態がＣＯＮＮＥＣＴＥＤ（接続）であるとき、必ずしもＮＡＳ状態はＣＯＮＮＥＣＴＥＤ（接続）ではない（例：アクティブフラグなしでのＴＡＵ手順の場合）。ＲＲＣ接続の確立、したがってＡＳ ＣＯＮＮＥＣＴＥＤ（アクセス層接続）状態への移行は、ユーザ機器によって開始され、なぜならユーザ機器のみが「ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｑｕｅｓｔ」メッセージを送ることができるためである。ユーザ機器は、アップリンクデータまたはアップリンクシグナリングが利用可能であることにより、あるいはダウンリンクデータまたはダウンリンクシグナリングを受信するためネットワークからページングされることにより、ＲＲＣ接続の確立を開始する。
最近、３ＧＰＰは、マシンタイプ通信（ＭＴＣ）におけるネットワークの改善に関する活動を開始した。サービスの要件は、非特許文献１（３ＧＰＰのウェブサイトから自由に入手可能）に記載されており、可能なアーキテクチャのソリューションの研究は、非特許文献２（３ＧＰＰのウェブサイトから自由に入手可能）に記載されている。ＭＴＣ端末またはＭＴＣデバイスは、通常では人によって操作されないことを特徴とする。そうではなく、通信ピアは、いわゆるＭＴＣサーバや別のＭＴＣ端末など、別のマシンである。ＭＴＣデバイスは３ＧＰＰによって指定される移動端末とすることもできるため、本発明の全体を通じて、「ユーザ機器（ＵＥ）」などのより一般的な呼称を使用し、したがって、ＭＴＣデバイス、ＭＴＣ端末、またはユーザ機器（ＵＥ）は、互いに置き換えて使用することができる。
ＭＴＣは、通常の人対人の通信とは異なるいくつかの特定の特徴を有する。３ＧＰＰでは、ネットワーク動作を最適化する目的でこれらの特定の特徴を識別することを試みている。これらの固有な特徴は「ＭＴＣ特徴」と称される。例えば、ＭＴＣデバイスは、一般には少量のデータを送る、または受信する。ＭＴＣデバイスおよび３ＧＰＰコアネットワーク（ＣＮ）の別の特徴は、ＭＴＣサーバとの通信を開始するように外部サーバ（ＭＴＣサーバ）がＭＴＣデバイスをトリガーできる能力である。これは、いわゆる「デバイストリガリング」によって可能になる。標準化の現在の状態においては、デバイストリガリングは、ネットワークにアタッチされているＭＴＣデバイス（すなわちデバイスがオンラインである）に対して指定されている。したがって、このトリガリングはしばしば「オンラインデバイストリガリング」と称される。デバイストリガリングは、ＭＴＣサーバによって開始され、さまざまな手段によって実行することができる。
第１の可能な方法は、通常のショートメッセージサービス（ＳＭＳ）を使用することである。したがって、ＭＴＣサーバは、ＳＭＳメッセージを生成し、それをショートメッセージサービングセンタ（ＳＭ−ＳＣ）に送る。ＳＭ−ＳＣは、ユーザ機器に配信できるようにメッセージをコアネットワーク（ＣＮ）内でＭＳＣまたはＳＧＳＮ１５０に転送する。
図２は、標準化の現在の状態によるネットワークアーキテクチャ（ＭＴＣメッセージトリガリングに関与しうるエンティティを含む）（非特許文献３を参照：この文書は３ＧＰＰのウェブサイトから自由に入手可能）を、例示的に示している。特に、ＭＴＣサーバ２１０は、ＳＭＳを生成してそれをＳＭ−ＳＣ２７０に送ることができ、ＳＭ−ＳＣ２７０は、ＲＡＮを通じてユーザ機器２６０に配信できるように、メッセージをＭＳＣやＳＧＳＮなどのネットワークノード２４０に転送する。
別の可能な方法は、ＭＴＣサーバ２１０が、３ＧＰＰコアネットワーク内の専用エンティティ（ＭＴＣインターワーキング機能（ＭＴＣ−ＩＷＦ）と称される）にデバイストリガー要求を送ることである。この場合、ＭＴＣ−ＩＷＦ２２０は、さまざまなデバイストリガー伝送メカニズムを適用することができる。例えば、デバイストリガーをＴ４インタフェースを通じて送信することができる（図２における「間接モデル」を参照）。この目的のため、ＭＴＣ−ＩＷＦ２２０は、ＳＭＳ準拠情報を生成し、それをエンティティＳＭ−ＳＣ２７０に送る。ＳＭ−ＳＣ２７０からユーザ機器２６０への伝送は、通常のＳＭＳ送信に基づく。ＳＭＳとしてのデバイストリガー送信のシグナリングフローは、非特許文献３のセクションＡ.３に記載されている。
これに代えて、Ｔ５インタフェースを通じてデバイストリガーを送信することができる。これを目的として、ＭＴＣ−ＩＷＦ２２０は、デバイストリガー要求を直接インタフェースを通じてサービングコアネットワークノードに送る（図２における「直接モデル」を参照）。サービングコアネットワークノードは、デバイストリガー要求メッセージを、汎用のＮＡＳシグナリング伝送を通じてユーザ機器に伝える。
ＭＴＣサーバから送られるデバイストリガー要求は、次の２種類の情報を伝えることができる。
− デバイストリガーを配信するためにネットワークによって使用される情報
− ＭＴＣデバイスを宛先とし、ネットワークに対して不透明な（透過的な）情報
デバイストリガーを配信するためにネットワークによって使用される情報としては、例えば、ユーザ機器の外部ＩＤ（トリガーされるユーザ機器を識別するためにＭＴＣサーバおよびＭＴＣ−ＩＷＦによって使用される）、ＭＴＣサーバＩＤ（例えばデバイストリガー配信報告を配信するときにＭＴＣサーバに連絡するためにネットワークによって使用される）、デバイストリガーの優先度／緊急性、デバイストリガーの有効時間などが挙げられる。
ＭＴＣデバイスを宛先とし、ネットワークに対して不透明な（透過的な）情報としては、例えば、ＭＴＣデバイスにおけるアプリケーションの識別情報、ターゲットＭＴＣサーバ／アプリケーションＩＤ（ＭＴＣサーバ／アプリケーションに連絡するためにＭＴＣデバイスによって使用され、例えば、ＭＴＣサーバ／アプリケーションのＩＰアドレス、ポート、またはＦＱＤＮ）、特定のＱｏＳパラメータ、アップリンクデータの優先度または緊急性、オプションとしてＭＴＣアプリケーションに固有な情報（サイズは制限されており、例えば、ＭＴＣデバイスが報告するべき情報／パラメータ）、オプションとして測定時間（すなわち報告を開始する前にＭＴＣデバイスが情報を収集する時間長）などが挙げられる。
デバイストリガーがＴ４インタフェースを通じて正常に送信されない場合については、非特許文献３のセクションＡ.３.２に記載されている。これは、ＳＭＳが正常に送信されない場合に似ており、この場合、ユーザ機器が到達可能となるまでＳＭＳがＳＭ−ＳＣに格納される。図３は、後から送信できるようにデバイストリガーがネットワーク（ＳＭ−ＳＣ）に格納される場合のシグナリングフローを示している。ステップ１〜ステップ７は、非特許文献３における図Ａ.２−１の対応するステップを参照している。ステップ１４において、デバイストリガーの格納が行われる。その後、ユーザ機器のアクティビティが存在するとき（ステップ１６）、ユーザ機器が到達可能であることがＨＳＳを介してＳＭ−ＳＣに通知され（ステップ１８）、ＳＭ−ＳＣは、デバイストリガーの新たな配信を開始する（ステップ１９、２０）。
３ＧＰＰの仕様書では、デバイストリガリング手順時におけるＭＴＣデバイスの２つの異なる識別子を予測している。第１の識別子は外部識別子（ＩＤ）と称され、ネットワークに登録されているユーザ機器を一意に識別する目的で、３ＧＰＰネットワークの外側（例：ＭＴＣサーバ／アプリケーションとネットワークの間）で使用される。外部ＩＤの例は、ＧＳＭやＵＭＴＳ、ＬＴＥへの加入を一意に識別するために現在使用されているＭＳＩＳＤＮ（移動体加入者統合サービスデジタルネットワーク番号：Mobile Subscriber Integrated Services Digital Network Number）である。第２の識別子は、内部識別子（ＩＤ）と称され、ネットワーク内でメッセージのルーティングを行うなどを目的として、ユーザ機器の加入を識別するために３ＧＰＰネットワーク内で使用される。内部ＩＤの例は、ＩＭＳＩ（国際移動体加入者識別番号：International Mobile Subscriber Identity）である。
３ＧＰＰ標準化のリリース１０においては、ネットワークにおける輻輳制御メカニズムの拡張として、ＮＡＳレベル輻輳制御が加わった。ＮＡＳレベル輻輳制御の導入は、ネットワークに対するマシンタイプ通信の影響に関して３ＧＰＰ内で行われた検討の結果であった。結論として、多数のＭＴＣデバイスが同時に作動すると、ネットワークにおける輻輳や過負荷につながりうる。ＮＡＳレベル輻輳制御は、「ＡＰＮベースの輻輳制御」と「一般ＮＡＳレベルモビリティ管理制御」とに分けることができる。ＡＰＮベースの輻輳制御は、特定のＡＰＮのメンバーであるユーザ機器に適用することができる。特定のＡＰＮに対して、接続（ベアラ）の最大数や、ネットワークへのネットワークアクセスの数の制限を、ネットワークによって設けることができる。一般ＮＡＳレベルモビリティ管理制御は、多くのユーザ機器がネットワークアクセス試行をほぼ同時に開始することに起因してサービングコアネットワークノード（ＭＭＥ／ＳＧＳＮ）において輻輳が発生しうるときに適用することができる。
セッション管理（ＳＭ）およびモビリティ管理（ＭＭ）のいずれも、ユーザ機器およびＭＭＥ／ＳＧＳＮにおけるＮＡＳ（非アクセス層）層のサブレイヤとみなされる。通常、ＭＭＥ／ＳＧＳＮおよびユーザ機器は、個別のＭＭコンテキストおよびＳＭコンテキストを格納する。さらに、ＳＭコンテキストは、ＰＤＰ（パケットデータプロトコル）接続またはＰＤＮ（パケットデータネットワーク）接続あたり１つである。ユーザ機器が複数の異なるＡＰＮとの複数のＰＤＰ／ＰＤＮ接続を有する場合、そのユーザ機器は、１つのＭＭコンテキストと複数のＳＭコンテキストを有する。
なお、ＧＰＲＳモバイルネットワークにおいては、ユーザ機器のための個別のトンネル（すなわち接続）それぞれに対して個別のパケットデータプロトコル（ＰＤＰ）コンテキストがＳＧＳＮにおいて確立される。ＥＰＳモバイルネットワークにおいては、パケットデータネットワーク（ＰＤＮ）接続それぞれに対して、ＭＭＥにおける個別のＥＰＳベアラコンテキストが確立される。モバイルネットワークの一般的な術語（すなわちＧＰＲＳネットワークおよびＥＰＳネットワーク）が使用される場合、単純さのため、用語「ＰＤＰ／ＰＤＮ接続」および「ＰＤＰ／ＰＤＮコンテキスト」（より正確にはＰＤＰ／ＥＰＳベアラコンテキストと称される）を使用することができる。
ＡＰＮベースのセッション管理輻輳制御においては、ＳＧＳＮ／ＭＭＥは、対象のＡＰＮに関連付けられるＳＭ輻輳が検出されるとき、ユーザ機器からのセッション管理（ＳＭ）要求を拒否する。オプションとして、拒否メッセージは、セッション管理バックオフ（ＳＭ ＢＯ）タイマーを含むことができ、このタイマーはユーザ機器に格納されなければならない。ユーザ機器は、作動中のＳＭ−ＢＯタイマーを有する場合、その特定のＡＰＮに関連する、ＭＭＥ／ＳＧＳＮへのＳＭ要求を開始しない。言い換えれば、ユーザ機器は、ＳＭ−ＢＯタイマーが作動している間は、その特定のＡＰＮへの新しいＰＤＰコンテキストまたはＥＰＳベアラを確立することができない、または既存のＰＤＰコンテキストまたはＥＰＳベアラを修正することができない。ユーザ機器は、ＭＭ手順（すなわち、トラッキングエリア更新（ＴＡＵ）、サービス要求など）は依然として行うことができる。ＳＧＳＮ／ＭＭＥにおけるセッション管理を対象とする、ユーザ機器から送られるあらゆるタイプの要求（例えば、ＰＤＮ接続要求、ベアラリソース割り当て要求、ベアラリソース修正要求など）は、簡潔に一般的な用語「ＳＭ要求」を使用して表現することができる。
ＡＰＮベースのモビリティ管理輻輳制御においては、ＭＭＥ／ＳＧＳＮは、特定のＡＰＮに加入しているユーザ機器に対して、モビリティ管理バックオフ（ＭＭ−ＢＯ）タイマーを使用してアタッチ手順を拒否することによって、この制御を実行する。
一般ＮＡＳレベルモビリティ管理輻輳制御においては、ＭＭＥ／ＳＧＳＮが一般的な過負荷条件（例：それ以上の処理パワーがない、メモリが占有されている、格納されているＭＭ／ＳＭコンテキストの最大数に達しようとしている）を経験しているとき、ＭＭＥ／ＳＧＳＮはユーザ機器からのモビリティ管理シグナリング要求を拒否することができる。ＭＭＥ／ＳＧＳＮは、ユーザ機器へのモビリティ管理バックオフ（ＭＭ−ＢＯ）タイマーを拒否メッセージの中に含めることができる。
ＮＡＳレベル輻輳制御のいずれの場合にも、ネットワーク（ＳＧＳＮ／ＭＭＥ）がＳＭ−ＢＯタイマー（ＡＰＮベースのＳＭ ＣＣの場合）またはＭＭ−ＢＯタイマー（ＭＭ ＣＣの場合）を、対応する拒否メッセージにおいてユーザ機器に送るかはオプションである。さらに、ＳＧＳＮ／ＭＭＥが、送られるＳＭ−ＢＯタイマーまたはＭＭ−ＢＯタイマーを格納するかはオプションである。例えば、ＳＧＳＮ／ＭＭＥが新しいＰＤＰコンテキスト要求またはＰＤＮ接続要求を拒否するとき、ＳＧＳＮ／ＭＭＥはユーザ機器のＰＤＰコンテキストまたはＰＤＮコンテキストを有さず、対応するコンテキストを有することなくＳＭ−ＢＯタイマーを格納することは困難である。しかしながら、ユーザ機器がＰＤＰ／ＰＤＮコンテキストをすでに有しており、ＳＧＳＮ／ＭＭＥがユーザ機器からの修正要求を拒否する場合、関連するコンテキストが存在するため、ＳＧＳＮ／ＭＭＥはＳＭ−ＢＯタイマーを格納することができる。輻輳制御のさらなる詳細については、非特許文献４のセクション４.３.７.４.２「ＮＡＳレベル輻輳制御」に記載されている。
ネットワークにおいてＮＡＳレベル輻輳制御が有効にされているとき、ＭＴＣサーバから送られるデバイストリガー要求を制限するための解決策が、非特許文献２のセクション６.５９に記載されている。この解決策では、ＳＧＳＮ／ＭＭＥ（サービングネットワークノード）は、Ｔ５インタフェース（ＭＴＣ−ＩＷＦとＳＧＳＮ／ＭＭＥとの間）を通じて、デバイストリガー要求の送信レートを制限するための過負荷制御を有効にする。しかしながら、このメカニズムは、ＡＰＮベースのＳＭ輻輳制御の影響を極めて正確には記述しておらず、一般的なＭＭ輻輳制御に適用することができる。
ＡＰＮベースのＳＭ輻輳制御（ＣＣ）は、トリガーされたユーザ機器がアップリンクデータを送る先のＡＰＮに適用される。デバイストリガー要求がユーザ機器に送られると、ＰＤＰ／ＰＤＮ接続を確立または修正するためのユーザ機器のシグナリングに、ＡＰＮベースのＳＭ ＣＣが適用される。基本的には２つのケースが存在する。第１のケースは、デバイストリガリングの時点でユーザ機器においてＳＭ−ＢＯタイマーが作動しており、第２のケースは、ユーザ機器においてＳＭ−ＢＯタイマーが作動していないが、ＰＤＰコンテキストの確立を試行するとき、ユーザ機器はＳＭ−ＢＯタイマーを含んだＳＭ拒否メッセージを取得する。
ユーザ機器は、ネットワークに対して不透明な情報を含んだデバイストリガー要求を受信すると、トリガー情報を正しいアプリケーションに処理する（すなわち内部的にルーティングする）。ユーザ機器は、アップリンクデータをターゲットＡＰＮに送らなければならないかを判定する。ターゲットＡＰＮは、セッション管理輻輳制御（ＳＭ ＣＣ）下にあるものと想定する。ユーザ機器は、適用されているＳＭ ＣＣを認識している、または認識していない。ターゲットＡＰＮとの接続の確立は、ユーザ機器がアタッチされているアクセスネットワークタイプ（Ｅ−ＵＴＲＡ、ＵＴＲＡＮ、ＧＥＲＡＮ）に依存する。
現在のＥ−ＵＴＲＡＮアクセスにおいては、デバイストリガー要求をユーザ機器に送信する目的で、ダウンリンクＮＡＳメッセージ（デバイストリガー要求を伝える）のためのＥＭＭ／ＲＣＣ接続が確立され、ユーザプレーンベアラが自動的に確立される。ターゲットＡＰＮとの以前に確立されたＰＤＮ接続（ＥＰＳベアラ）が存在する場合、たとえターゲットＡＰＮが輻輳していても、ユーザ機器は、ＭＭＥ／ＳＧＳＮへのＳＭシグナリングなしにユーザプレーンを通じてアップリンクデータを送ることができる。以前に確立されたＥＰＳベアラが存在しない場合、ユーザ機器はアップリンクデータを送ることができず、なぜなら、新しいＰＤＮ接続のためのＰＤＮ接続要求メッセージ、または既存のＥＰＳベアラを修正するためのＥＰＳベアラ修正メッセージを送信できないためである。なお、ＳＭ輻輳制御は、Ｃ−プレーン（制御プレーン）シグナリングに適用され、Ｕ−プレーン（ユーザプレーン）には影響しない。ユーザ機器は、（例えばユーザプレーン接続の確立や修正のための）シグナリングをＳＧＳＮ／ＭＭＥに送ることはできない。しかしながら、ユーザプレーン接続がすでに確立されている場合、ユーザ機器はデータを送信および受信することができる。
ＧＥＲＡＮ／ＵＴＲＡＮアクセス（２Ｇ／３Ｇアクセスとしても知られている）においては、デバイストリガー要求をユーザ機器に送信する目的で、ダウンリンクＮＡＳメッセージ（例えばＭＴ−ＳＭＳまたは他のタイプ／フォーマットのトリガー要求を伝えることができる）のためのＭＭ／ＲＲＣ接続が確立されるが、ユーザプレーンベアラは確立されない。ユーザ機器は、ＮＡＳ ＳＭシグナリング要求を使用して、ＰＤＰコンテキストを個別に確立またはアクティブにする必要がある。ユーザ機器においてＳＭ−ＢＯタイマーが作動している場合、ユーザ機器はＳＭ要求を送ることが許可されず、したがって、ＰＤＰコンテキストを確立／アクティブにすることができない。結果として、ユーザ機器はアップリンクデータを送ることができない。
これに対して、ＳＭ−ＢＯタイマーが作動していない場合、ユーザ機器はＰＤＰコンテキストを確立するためにＮＡＳ ＳＭ要求メッセージを送り、このメッセージが輻輳したＡＰＮを対象とする場合、ＳＧＳＮはこのメッセージを拒否する。これは効率的ではなく、なぜなら、デバイストリガー要求を送信するために、ページングが行われ、無線リソース接続（ＲＲＣ）およびＮＡＳシグナリング接続が確立され、ユーザ機器のＮＡＳ ＳＭ要求が拒否された後に解放されるためである。したがって、可能な場合に、デバイストリガー要求メッセージの送信を回避するための解決策が必要である。
ＳＭ輻輳制御に関連するさらなるシナリオにおいては、サービングネットワークノード（ＳＧＳＮ／ＭＭＥ）は、以下を判定できないことがある。
− ＳＧＳＮ／ＭＭＥにおいて受信された（ユーザ機器を宛先とする）ダウンリンクメッセージが、デバイストリガリング（ＤＴ）を目的としているかどうか。このことは、特に、デバイストリガー要求が移動体着のＳＭＳ（ＭＴ−ＳＭＳ）において伝えられる場合にあてはまる。この場合、ＳＧＳＮ／ＭＭＥは、ＭＴ−ＳＭＳが「通常の」ＳＭＳであるのか、ＭＴＣアプリケーションをトリガーするための特殊情報をＳＭＳ本体において伝える「ＤＴ関連」ＳＭＳであるのかを判定することができない。
− どれがターゲットＡＰＮ（すなわち、ユーザ機器がデバイストリガー要求を受信して処理した後にユーザプレーン接続を確立／アクティブにする先のＡＰＮ）であるのか。この場合、ＳＧＳＮ／ＭＭＥは、有効にされているＡＰＮベースのＳＭ輻輳制御がユーザ機器に適用されるか否かを推定することができない。
したがって、このシナリオでは、輻輳制御を効率的に行うことができない。
ＳＧＳＮ／ＭＭＥがＭＭ輻輳制御を適用している場合、デバイストリガー要求を送信しなければならないときＳＧＳＮ／ＭＭＥがユーザ機器をページングしないものと想定する。この理由として、ページングによってＳＧＳＮ／ＭＭＥへの追加のＭＭシグナリングが発生し、これは望ましくないためである。さらには、ユーザ機器がデバイストリガーのページングを受信したときにユーザ機器においてＭＭバックオフタイマーが作動している場合、そのユーザ機器はＭＭバックオフタイマーを削除してＭＭ輻輳制御を省く。したがって、ＳＧＳＮ／ＭＭＥは、おそらくはユーザ機器をページングせず、デバイストリガー要求が配信されないことを、（Ｔ４インタフェースまたはＴ５インタフェースのどちらが使用されるかに応じて）ＳＭ−ＳＣまたはＭＴＣ−ＩＷＦにシグナリングする。ＭＴＣ−ＩＷＦはトリガー配信報告（配信されなかった理由がＭＭ輻輳制御であることの理由値を含んでいることができる）を生成し、それをＭＴＣサーバに送る。ネットワーク（ＳＭ−ＳＣまたはＭＴＣ−ＩＷＦ）は、輻輳状況についてＭＴＣサーバに通知し、特定のデバイスのグループに対してはデバイストリガー要求の送信を制限（または停止）するようにＭＴＣサーバに要求する。この状況は、さまざまな問題につながることがある。
3GPP TS 22.368, v.11.3.0, Oct. 2011, "Service requirements for Machine-Type Communications (MTC)" 3GPP TS 23.888, v.1.5.0, Oct. 2011, "System Improvements for Machine-Type Communications (MTC)" 3GPP TS 23.682 "Architecture Enhancements to facilitate communications with Packet Data Networks and Applications", v0.1.0, Nov. 2011 3GPP TS 23.401, v.10.5.0, Sep. 2011, "General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN)" 3GPP TS 24.301 3GPP TS 24.301, ver. 10.5.0, Dec. 2011 RFC 3775 RFC 5944
本発明の基礎をなす問題点は、トリガリング手順を提供する通信システムにおいて、トリガリングする側のデバイスが、トリガーされるデバイスにトリガー要求を送り、トリガーされたデバイスがネットワーク輻輳のためにトリガー要求に応えることができないとき、複数のトリガー要求もしくは接続確立要求またはその両方が送信されることにより、シグナリングの効率が低下することがあるという観察に基づく。さらに、輻輳に関する情報の可用性が、ネットワークエンティティごとに異なることがある。
本発明の目的は、ネットワーク輻輳の状態においてデバイストリガリング手順に必要なシグナリング交換量を減らすことによって、効率的な輻輳制御を促進することである。
この目的は、独立請求項の特徴によって達成される。
有利な実施形態は、従属請求項の主題である。
本発明の特有の方法は、サービングネットワークノードにおいて、デバイストリガリングに関連する端末の能力についての情報を取得し、これらの能力および輻輳状況に従って、トリガー要求を端末に転送するか否かを決定することである。
本発明の一態様によると、サービングネットワークノードを含む通信ネットワークにおいて端末をトリガーする方法であって、サービングネットワークノードにおいて実行される、方法、を提供する。本方法は、端末のデバイストリガリング能力に関する情報を、端末、サーバ、または別のネットワークノードから受信されるメッセージから求めるステップと、端末からサーバへの接続の確立をトリガーするトリガー要求を受信するステップであって、トリガー要求がサーバによって通信ネットワークを通じて端末に送られる、ステップと、端末のデバイストリガリング能力に関する情報に基づき、かつ、現在の輻輳状態に基づいて、トリガー要求を端末に送信するか否かを判断するステップと、判断するステップの結果に従って、トリガー要求を端末に送信する、または送信しないステップと、を含んでいる。
トリガー要求は、通信を確立するように、もしくは、トリガリングデバイスまたは別の所定のエンティティに情報を送信するように、またはその両方を行うように、端末に指示する命令を含んでいる。トリガリングデバイス（トリガリングサーバ）は、端末およびサービングネットワークノードを含むセルラーネットワークなどのネットワークの外側に位置していることができる。サーバは、トリガー要求を発行する発行元ノードとすることができる。トリガー要求は、さまざまな方法で端末に伝送することができる。１つの方法は、端末に送信されるショートメッセージサービス（ＳＭＳ）である。このような場合、トリガリングサーバが、ＳＭ−ＳＣサーバなどの別のサーバにおいてＳＭＳにカプセル化されるトリガー要求を発行することが可能である。しかしながら、本発明は、特定のアーキテクチャに制限されず、端末は、ＳＭＳを介する以外の方法でトリガー要求を受信することができる。
この場合、通信ネットワークは、任意の通信ネットワーク、セルラーネットワーク、またはアドホックネットワークを意味し、無線または有線を問わない。一般的には、通信ネットワークは、任意のヘテロジニアス（異種）ネットワークとすることもできる。
好ましくは、端末のデバイストリガリング能力に関する情報は、以下のうちの少なくとも１つであり、すなわち、端末が位置している無線アクセスネットワークの無線リソース制御プロトコルによって示される、端末の優先度またはサービス品質、メッセージが事前定義されたインタフェースまたは事前定義されたネットワークエンティティを通じて受信されるかどうか、加入者サーバから受信されるメッセージから求められる能力、メッセージから求められるポート番号（所定のポート番号がデバイストリガリングに使用される）、トリガー要求を伝えるメッセージのヘッダから求められるプロトコル識別子（ペイロードのコンテンツタイプを示す）、端末から受信されるメッセージから求められる端末のデバイストリガリング能力またはステータス、トリガー要求メッセージのヘッダから判定される、メッセージがデバイストリガリングメッセージであるかどうか、のうちの少なくとも１つである。
なお、これらは、デバイストリガリング能力に関する情報の例にすぎない。一般的には、端末のデバイストリガリング能力を推定するために使用できる任意の情報を、この目的に使用することができる。特に、端末の能力をより良好に推定する目的で、もしくは、デバイストリガリング機能に使用される異なるネットワークアーキテクチャを含む異なるシナリオにおいて端末の能力を推定する目的で、またはその両方を目的として、上記の情報を組み合わせることができる。
上の方法は、端末が接続を確立しうる外部ネットワークを求めるステップと、端末の求められた外部ネットワークをサービングネットワークノードに格納するステップと、外部ネットワークが輻輳状態にあるか否かを、現在の輻輳状態に従って判定するステップと、をさらに含んでいることが有利である。
外部ネットワークとは、端末のアクセスネットワークの外側のネットワークを意味する。端末のアクセスネットワークは、例えば、ＧＰＲＳネットワーク、ＵＭＴＳネットワーク、ＬＴＥネットワークなどの３ＧＰＰネットワークとすることができる。外部ネットワークは、３ＧＰＰネットワークおよびそのプロバイダの外側のネットワークとすることができる。一般的には、外部ネットワークはＡＰＮ（アクセスポイントネーム）とすることができる。特に、外部ネットワークは、ユーザ向けのソフトウェアまたはサービスのプロバイダのネットワークとすることができ、ユーザはこれらのソフトウェアやサービスに「ネットワーク」を通じて接続される。デバイストリガリングは、自動的なソフトウェアアップデート、トラフィック情報、ステータス情報などの役割を果たすことができる。したがって、外部ネットワークは、例えば、インターネット以外の、所有権が保持されたネットワークとすることができる。
外部ネットワークの情報／識別情報を求めるステップおよび格納するステップは、トリガー要求メッセージの受信時に行われることが好ましい。
特に、トリガーされたときに端末が接続を確立する外部ネットワークは、以下のステップのうちの少なくとも１つによって求めることができる。
− 端末が加入している外部ネットワークを、加入者サーバから受信されるメッセージから求めるステップ。加入者サーバは、例えば、周知のセルラーシステムにおいて採用されているホーム加入者サーバまたはホームロケーションレジスタとすることができる。しかしながら、本発明はこれに制限されず、サービスプロバイダによって提供されるサービスへのユーザの加入に関する情報を格納する任意のサーバとすることができる。加入者サーバがデバイストリガリングサービスについての情報も含み、この情報をサービングネットワークノードに提供することが考えられる。
− 端末がトリガーされた後に接続を確立しうる外部ネットワークを、加入者サーバから受信されるメッセージから求めるステップ。この方法は、特定のシナリオにおいては、前の方法よりも信頼性が高い。特に、デバイストリガリング能力は、端末が加入しているのみならず、トリガーされた後に接続を確立しうるネットワークに関連する。
− 端末がトリガーされた後に接続を確立しうる外部ネットワークを、端末から受信されるメッセージから求めるステップ。トリガーされた後に端末が接続を確立しうる外部ネットワークは、端末において認識することができ、それをサービングネットワークノードに送信することができる。この目的のために新規のメッセージを定義する必要はない。能力情報は、すでに存在するシグナリングメッセージにおいて送信することができる。しかしながら、これに代えて、この目的のために新規のメッセージを定義することもできる。
− サービングネットワークノードが、端末のために確立されたベアラコンテキストを有するかを判定するステップ。
− ベアラコンテキストが、輻輳したネットワークへのベアラのコンテキストかを判定するステップ。
− 輻輳したネットワークに許可されるベアラの最大数、もしくは、輻輳した外部ネットワークに許可される接続タイプ、またはその両方を求めるステップ。この場合、接続タイプとは、ＩＰｖ４接続またはＩＰｖ６接続（ＰＤＮ）を意味する。輻輳したネットワークにおける接続の数は、異なる接続タイプごとに個別に制限することができる。
− 端末が接続を確立しうる外部ネットワークを、端末のトリガリングを開始したサーバの識別情報に基づいて求めるステップ。
本発明の実施形態によると、本方法は、デバイストリガー要求の配信に関する報告と、トリガー要求を端末に送信または再送信するべきではない時間期間とを含んだメッセージを、サーバに送信するステップ、をさらに含んでいる。なお、この場合、サーバは、例えば、ＳＭＳ−ＳＣサーバなど、ＳＭＳの発行元のサーバとすることができる。しかしながら、別のシナリオにおいては、サーバは、論理的にトリガー要求の発行元であるサーバ、すなわちデバイストリガリング（アプリケーション）サーバとすることもできる。
サービングネットワークノードは、デバイストリガー要求を端末に送信することを決定したとき、輻輳している外部ネットワークを示す情報を端末にさらに送信することが有利である。この方法では、端末が輻輳したネットワークへのデータ送信を試みることを防止することができる。さらに、サービングネットワークノードは、バックオフタイマーを端末に送信することができる。バックオフタイマーは、端末が輻輳したネットワークへのデータ送信を試みるべきではない時間期間を定義する。
好ましくは、輻輳した外部ネットワークを示す情報もしくはバックオフタイマーまたはその両方を端末に送信するとき、サービングネットワークエンティティにおいてタイマーがセットされ、タイマーの期間中、サービングネットワークエンティティは、端末からのデバイストリガー応答に関する配信報告を送信しない。
本発明の実施形態によると、サービングネットワークは、端末が外部ネットワークとのデータ接続を確立できないことおよび外部ネットワークの識別情報と、残りのバックオフタイマーと、送信できなかったデバイストリガー応答の識別情報、のうちの少なくとも１つを示す情報を、端末から受信するステップ、をさらに行うことができる。「残りのバックオフタイマー」とは、端末が輻輳したネットワークにデータを（再）送信しない期間である残りの時間を示すことを意味する。デバイストリガー応答の識別情報とは、メッセージが関連しているトリガー要求をサーバが認識することを可能にする任意の指示情報である。
本発明の別の態様によると、サービングネットワークノードを含む通信ネットワークにおいてサーバによって端末をトリガーする方法であって、本方法が端末において実行され、デバイストリガリングに関連する端末の能力を求めるステップと、求められた端末の能力を含む情報をサービングネットワークノードに送信するステップと、を含んでいる、前記方法、を提供する。
本方法は、輻輳した外部ネットワークを示す情報をサービングネットワークノードから受信するステップと、受信された情報を格納するステップと、シグナリングまたはデータを外部ネットワークに送信するか否かを、格納された情報に基づいて判断するステップと、をさらに含んでいることが有利である。
シグナリングは、非アクセス層（ＮＡＳ）シグナリングとすることができる。しかしながら、本発明は、この種類のシグナリングに制限されない。上記の端末の機能により、端末はサービングネットワークノードと通信することが可能であり、これによりサービングネットワークノードは端末のトリガリング能力についての情報を取得することができる。さらに、輻輳したネットワークについて端末に通知することによって、端末が輻輳したネットワークにデータを送ることを回避することが可能である。
本発明の別の態様によると、サービングネットワークノードを含む通信ネットワークにおいてサーバによって端末をトリガーする装置であって、本装置がサービングネットワークノードであり、端末のデバイストリガリング能力に関する情報を、端末、サーバ、または別のネットワークノードから受信されるメッセージから求める能力判定ユニットと、端末からサーバへの接続の確立をトリガーするトリガー要求を受信する受信ユニットであって、トリガー要求がサーバによって通信ネットワークを通じて端末に送られる、受信ユニットと、端末のデバイストリガリング能力に関する情報に基づき、かつ、現在の輻輳状態に基づいて、トリガー要求を端末に送信するか否かを判断する判断ユニットと、判断ユニットの判断に従って、トリガー要求を端末に送信する、または送信しない送信ユニットと、を備えている、前記装置、を提供する。
本装置は、端末がトリガー要求メッセージを受信したときに接続を確立しうる外部ネットワークを求めるＡＰＮ判定ユニットと、ＡＰＮ判定ユニットによって求められた端末の外部ネットワークをサービングネットワークノードに格納するための格納手段と、外部ネットワークが輻輳状態にあるか否かを、現在の輻輳状態に従って判定する輻輳検出ユニットと、をさらに備えていることが有利である。
ＡＰＮ判定ユニットは、端末が、トリガーされたときに接続を確立する外部ネットワークを、以下のステップ、すなわち、端末が加入している外部ネットワークを、加入者サーバから受信されるメッセージから求めるステップ、端末がトリガーされた後に接続を確立しうる外部ネットワークを、加入者サーバから受信されるメッセージから求めるステップ、端末がトリガーされた後に接続を確立しうる外部ネットワークを、端末から受信されるメッセージから求めるステップ、サービングネットワークノードが、端末のための確立されたベアラコンテキストを有するかと、ベアラコンテキストが、輻輳したネットワークへのベアラのコンテキストかを判定するステップと、輻輳したネットワークに許可されるベアラの最大数、もしくは、輻輳した外部ネットワークに許可される接続タイプ、またはその両方を求めるステップ、のうちの少なくとも一方のステップ、端末が接続を確立しうる外部ネットワークを、端末のトリガリングを開始したサーバの識別情報に基づいて求めるステップ、のうちの少なくとも１つによって求めるように構成されていることが好ましい。
送信ユニットは、デバイストリガー要求の配信に関する報告と、サーバがトリガー要求を端末に送信または再送信するべきではない時間期間とを含んだメッセージを、サーバに送信するようにさらに構成することができる。
送信ユニットは、輻輳した外部ネットワークもしくはバックオフタイマーまたはその両方を示す情報を端末に送信するように構成することができる。
本装置は、バックオフユニットをさらに備えていることができ、輻輳した外部ネットワークもしくはバックオフタイマーまたはその両方を示す情報を端末に送信するときに、バックオフユニットがサービングネットワークノードにおいてタイマーをセットし、タイマーの期間中は、サービングネットワークエンティティが端末からのデバイストリガー応答に関する配信報告を送信しない。
受信ユニットは、端末が外部ネットワークとのデータ接続を確立できないことおよび対応する外部ネットワークの識別情報と、残りのバックオフタイマーと、送信できなかったデバイストリガー応答の識別情報、のうちの少なくとも１つを示す情報を、端末から受信するようにさらに構成することができる。
本発明の別の態様によると、サービングネットワークノードを含む通信ネットワークにおいてサーバによって端末をトリガーする装置（端末）であって、本装置が端末であり、デバイストリガリングに関連する端末の能力を求める能力判定ユニットと、求められた端末の能力を含む情報をサービングネットワークノードに送信する送信ユニットと、を備えている、前記装置、を提供する。
本端末は、輻輳した外部ネットワークを示す情報をサービングネットワークノードから受信する受信ユニットと、受信された情報を格納する格納手段と、非アクセス層シグナリングまたはデータを外部ネットワークに送信するか否かを、格納された情報に基づいて判断する判断ユニットと、をさらに備えていることができる。
本発明の別の態様によると、コンピュータ可読プログラムコードが具体化されているコンピュータ可読媒体を備えたコンピュータプログラム製品であって、プログラムコードが本発明を実行するようにされている、コンピュータプログラム製品、を提供する。
本発明のさらに別の態様によると、上述した任意の装置を具体化する集積回路が提供される。
本発明の上記および他の目的および特徴は、以下の説明と、添付の図面を参照しながら提示されている好ましい実施形態とから、さらに明らかになるであろう。
３ＧＰＰ ＬＴＥにおいて定義されているダウンリンクコンポーネントキャリアにおけるサブフレームの一般構造を示した概略図である。 マシンタイプ通信の現在の３ＧＰＰアーキテクチャを示したブロック図である。 図２のマシンタイプ通信の３ＧＰＰアーキテクチャに対応する、デバイストリガーが遅延して正常に配信されるフローの例を示したメッセージフロー図である。 輻輳の場合におけるネットワークの選択されたエンティティ間の通信（特に、デバイストリガーを格納する）を示したブロック図である。 トリガー要求の受信時に端末においてバックオフタイマーが作動していない場合の、可能なオプションおよび問題点の例を示したメッセージフロー図である。 トリガー要求の受信時に端末においてバックオフタイマーが作動していないときにネットワークによって開始される配信遅延指示情報の例を示したメッセージフロー図である。 トリガー要求の受信時に端末においてバックオフタイマーが作動していないときに端末によって開始される配信遅延指示情報の例を示したメッセージフロー図である。 端末においてバックオフタイマーが作動しているときに、端末によって開始され、ネットワークノードに送られ、次いでサーバに送られる配信遅延指示情報の例を示したメッセージフロー図である。 端末においてバックオフタイマーが作動しているときに、端末によって開始され、サーバに直接送られる配信遅延指示情報の例を示したメッセージフロー図である。 本発明の実施形態による方法の例を示したフローダイアグラムである。 本発明の実施形態による装置の論理構造の例を示したブロック図である。 ＭＭ ＣＣ／ＳＭ ＣＣが有効にされているときに（ＭＴ−ＳＭＳを通じての）デバイストリガーの格納に関連する改善された通信を示したブロック図である。 ＭＭ ＣＣ／ＳＭ ＣＣが有効にされているときに（Ｔ５を通じての）デバイストリガーの格納に関連する改善された通信を示したブロック図である。 デバイストリガー要求をユーザ機器に送信するかを決定するため、本発明の実施形態に従ってＳＧＳＮ／ＭＭＥによって適用される方法を示したメッセージフロー図である。 デバイストリガリングおよびデータ接続確立の機能モデルを示したブロック図である。
本文書においては、「モバイルノード」などの用語は、通信ネットワーク内の物理エンティティを表す。１つのノードがいくつかの機能エンティティを有することができる。機能エンティティとは、所定の一連の機能を実施する、もしくは、ノードまたはネットワークの別の機能エンティティに所定の一連の機能を提供する、またはその両方であるソフトウェアモジュールまたはハードウェアモジュールを意味する。ノードは、自身を通信設備または通信媒体にアタッチする１つまたは複数のインタフェースを有することができ、ノードはこれら通信設備または通信媒体を通じて通信することができる。同様に、ネットワークエンティティは、機能エンティティを通信設備または通信媒体にアタッチする論理インタフェースを有することができ、ネットワークエンティティはこれら通信設備または通信媒体を通じて他の機能エンティティや通信先ノードと通信することができる。
本明細書において、用語「サーバ」または「トリガリングサーバ」は、ネットワーク内、あるいは外部ネットワークまたは外部ノード内に存在するエンティティを意味する。「サーバ」または「トリガリングサーバ」は、例えば、（ＭＴＣ）端末または複数の端末から自動的にデータを収集し、トリガリング要求を端末に送ることのできるサーバとすることができる。トリガリング要求は、端末に伝えられるメッセージまたはインジケータであり、測定データ、サーバに送信されるデータ、自身の識別情報を示すためのシグナリングデータ、あるいは（本発明によって提供されるように）実際のデータが送られる、送られない、または遅延して送られることを示すためのシグナリングデータなどのデータを提供する目的で、端末がネットワークもしくはサーバまたはその両方との接続を確立するべきであることを示す。なお、サーバを別の端末によって実施することもできる。例えば、第１の端末を、第２の端末をトリガーするように構成することができる。このように構成することは、例えば、（場合によってはユーザが操作する）端末が別のＭＴＣ端末からデータを収集するときに有利であり得る。背景技術のセクションにおいて説明したように、端末は、ＬＴＥ端末、ＵＭＴＳ端末、またはＧＳＭ／ＧＰＲＳ／ＥＤＧＥ端末とすることができる。トリガリング要求は、さまざまな手段を介して送信することができ、そのうちの３つの例について図２を参照しながら説明した。しかしながら、本発明はこれらに制限されず、任意の別のネットワーク、もしくは、ネットワーク内の任意の別のメカニズム、またはその両方を採用することもできる。
一般にＭＴＣ端末によって提供される少量のデータは、小さなデータの塊と理解することができ、小さなＩＰパケット、ＳＭＳ、または何らかの別のアプリケーション固有データとすることができる。データの量は、例えばＳＭＳの中に収まるとき、十分に小さいとみなすことができる。したがって、少量のデータは、１４０バイト（ＳＭＳの現在のペイロードサイズ）より小さい。したがって、本発明の意味においては、少量のデータはＳＭＳと理解することもできる。しかしながら、本発明はこれに制限されず、トリガリング後に端末によって提供されるデータが大量の情報を含んでいることもできる。
用語「加入している」は、ユーザ機器がネットワークに加入しているとき、少なくとも、ネットワークに接続するようにユーザ機器をトリガーするための十分な情報をネットワークが認識していることと理解することができる。特に、この情報はユーザ機器の識別情報（ＩＭＳＩなど）とすることができる。さらには、ユーザ機器の効率的な「探索」を行うことができるようにする目的で、ネットワークはユーザ機器のおよその位置を認識していることができる。ユーザ機器がＩＤＬＥ（アイドル）モードにある場合、ネットワークは、ユーザ機器のページングを可能にするため、コアネットワークにおける格納されたコンテキストデータ（ＩＭＳＩ、可能なトラッキングエリア、ベアラコンテキスト（ＥＰＳ）を含む）を有することができる。
ユーザプレーンと制御プレーンとの区別に関して、データベアラはユーザプレーンに関連付けられており、ユーザプレーンの一部である。データベアラは、ユーザデータを伝送するために確立される。これとは異なり、制御プレーンおよびシグナリングベアラは、一般的には制御シグナリングの伝送を目的とする。
本発明は、トリガーに応えて端末デバイスからトリガリング開始エンティティに送信されるアップリンクデータが遅延する、または配信されないことを、トリガリング開始エンティティに示すことを可能にするデバイストリガリング手順に関する。
なお、一般的には、トリガー要求を送るトリガリング開始デバイスは、トリガーされた端末がデータを送信する先のデバイスに必ずしも一致しない。トリガリングデバイスと受信デバイスは、位置もしくは実装またはその両方が異なっている異なるエンティティとすることができる。しかしながら、以下の例においては、トリガリングサーバ（またはＭＴＣサーバ）などのトリガリングエンティティが、トリガー要求に応えて端末から送られるデータを受信するものと想定する。
トリガー開始エンティティは、トリガー要求の発行元であるエンティティである。さらに、トリガリング開始エンティティにおいて発行されたトリガー要求は、ネットワークまたは複数のネットワークを通じてさまざまな方法で送信することができる。例えば、トリガー要求を、ネットワークに対して透過的に（不透明に）端末に送ることができる。すなわち、ネットワークはトリガーインジケータを利用することなく、トリガーインジケータをトリガー開始エンティティからの「ユーザデータ」として、トリガーされるデバイス（端末）に送信するのみである。これに代えて、トリガー要求の少なくとも一部分を制御シグナリングとして送信して、任意のネットワークノードによって解釈もしくは処理またはその両方を行うことができ、そのネットワークノードは、端末がトリガーされたことを端末に通知するための必要なステップをさらに行うことができる。
トリガリングサーバは、トリガーされたデバイスからのデータを自動的に収集するＭＴＣサーバであることが有利である。この意味において、「自動的に」とは、ユーザの直接的な入力なしに、を意味する。例えば、ＭＴＣサーバにおけるアプリケーションは、事前定義された時間期間ごとにトリガー要求の送信を制御する。アプリケーションは人間のユーザによって設定することができるが、それぞれのトリガー要求はアプリケーションによって自動的に生成および送信される。
本発明は、ネットワークにおいて輻輳制御メカニズムが有効にされており、したがって、トリガーされたデバイスがネットワークとの接続を確立できない、もしくはアップリンクデータをトリガリングサーバに送ることができない、またはその両方である状況において、トリガリングサーバからデバイスをトリガーする方法を提供する。
このシナリオにおいては、現在のＬＴＥネットワークアーキテクチャではいくつかの問題が発生することがあり、場合によってはリソースの利用効率が低下する。しかしながら、これらの問題点は必ずしもＬＴＥアーキテクチャに限定されない。トリガリングデバイスがトリガーされるデバイスにトリガー要求を送り、トリガーされたデバイスがネットワークの輻輳のためにトリガー要求に応えることができないトリガリング手順を提供する任意の通信システムにおいても、これらの問題は発生しうる。
背景技術のセクションにおいて、既存の技術において発生する問題点を説明する目的で、開発下にある現在のＬＴＥシステムのメカニズムについて簡単に紹介した。特に、デバイストリガー要求がＭＴＣサーバから送られると、ネットワークは、ユーザ機器が登録されているＳＧＳＮ／ＭＭＥにこの要求を転送する。ＳＧＳＮ／ＭＭＥは、ユーザ機器をページングし、ＮＡＳ ＭＭ接続を確立した後、デバイストリガー要求をユーザ機器に配信する。
ＧＥＲＡＮ／ＵＴＲＡＮアクセスの場合、ユーザ機器がアップリンクデータを送ろうとしているＡＰＮに、ＡＰＮベースの輻輳制御が適用されていると、ユーザ機器はそのＡＰＮへのＰＤＰコンテキストを確立またはアクティブにすることが許可されない。したがって、デバイストリガー要求を伝えるＭＴ−ＳＭＳが端末によって正常に受信され、正常に受信されたことがＭＴＣサーバに報告されたが、このＡＰＮへのユーザプレーンベアラを確立することができず、ユーザ機器はアップリンクデータを送信することができない。したがって、このシナリオにおいては、ネットワークは、デバイストリガー要求が正常に配信されたことをＭＴＣサーバに報告し、ＭＴＣサーバは、ユーザ機器のデータ報告（すなわちアップリンク（ＵＬ）データまたはユーザ機器からＭＴＣサーバへの接続の開始）を受信することを予測する。
ＭＴＣサーバは、デバイストリガーが肯定応答された後にユーザ機器からのデータを受信しない場合、ユーザ機器をもう一度トリガーすることができる。しかしながら、たとえ第２のデバイストリガーの後も、例えばユーザ機器においてＳＭ−ＢＯタイマーが依然として作動しているために、ユーザ機器が依然としてデータを報告できないことがある。したがって、本発明の基礎をなす課題の１つは、ＭＴＣサーバからユーザ機器への不必要な複数のトリガリングを回避することである。
ユーザ機器がＥＰＳシステムにアタッチされているとき、すなわちＥ−ＵＴＲＡＮアクセスを介してネットワークに接続されているときにも、類似する問題が発生することがある。ＧＥＲＡＮ／ＵＴＲＡＮアクセスの場合との違いとして、既存のＰＤＮ接続の場合、またはベアラ修正手順が要求されないＥＰＳベアラの場合、ユーザ機器はアップリンクデータを送ることができる。しかしながら、デバイストリガーの結果として新しいＥＰＳベアラまたは修正されたＥＰＳベアラが必要となる場合、ユーザ機器は新しいベアラの確立、または既存のベアラの修正を行うことができない。したがって、ユーザ機器は、アップリンクデータをＭＴＣサーバに送ることができない、またはＭＴＣサーバとの接続を確立することができない。
一般的には、ユーザ機器は、ＳＭ−ＢＯタイマーが作動している限りは、新しいベアラの確立または既存のベアラの修正（すなわちあらゆるセッション管理手順）を行うことができず、結果として、ユーザ機器はアップリンクデータをＭＴＣサーバに送ることもできない。
さらに、デバイストリガリング手順において、ネットワークは、端末がどの外部ネットワークにアップリンクデータを送るかを判定できないことがある。外部ネットワークは、３ＧＰＰの術語ではいわゆるアクセスポイントネーム（ＡＰＮ）に基づいて識別される。結果として、ネットワークは、そのＡＰＮに対して輻輳制御が有効にされているかも認識できないことがある。したがって、ネットワークは、トリガーされたデバイスによってトリガー開始エンティティに送られる、結果としてのアップリンクデータに輻輳制御が適用されるかを判定できないことがある。一般的に、端末が特定の外部ネットワークとの接続を有していないときには、端末がどのネットワークとの接続を確立するかを判定することが不可能なことがある。
本発明が解決しようとしているさらなる問題点として、デバイストリガリングがＳＭＳを通じて行われるとき、サービングネットワークノード（ＳＧＳＮ／ＭＭＥ）は、「通常の」ＭＴ−ＳＭＳと「ＤＴに関連する」ＭＴ−ＳＭＳとを区別することができない。ＳＧＳＮ／ＭＭＥは、受信されたＭＴ−ＳＭＳに何らかの特定の処理を適用するかを認識しない。１つの可能なオプションは、ＳＧＳＮ／ＭＭＥが、ＳＭ輻輳したＡＰＮに加入しているすべてのユーザ機器へのすべてのＭＴ−ＳＭＳを拒否することである。さらには、ユーザ機器が複数のＡＰＮに加入しているが、ＳＭ ＣＣが１つのみのＡＰＮに適用されている場合、非特許文献２のセクション６.５９に記載されている従来技術の「ＭＴＣ−ＩＷＦによる過負荷制御」メカニズムを適用するネットワーク（ＭＴＣ−ＩＷＦまたはＳＧＳＮ／ＭＭＥ）によって、すべてのデバイストリガー要求がブロックされる。この場合、用語「通常の」ＭＴ−ＳＭＳとは、デバイストリガリング（ＤＴ）とは異なる目的のＭＴ−ＳＭＳ、例えば自動的に生成されるトリガー要求ではなくユーザデータを有するＭＴ−ＳＭＳを意味する。
上に要約した問題点のいくつかを解決する目的で、本発明は、ＳＧＳＮ／ＭＭＥが、デバイストリガー要求メッセージの内部処理に基づいて、ＭＴＣサーバへのデバイストリガー配信報告（後からも説明されるように、「アップリンクデータ配信の指示情報」または他の何らかの指示情報を含んでいてもよい）を生成できるものと考える。この内部処理は、ＡＰＮベースのＳＭ ＣＣ、ユーザ機器の能力、加入しているＡＰＮまたはデバイストリガーに関連するＡＰＮ、格納されているＰＤＰ／ＰＤＮコンテキスト、またはユーザ機器あるいはネットワークエンティティからの他のデータまたは明示的なシグナリングについての情報に基づくことが好ましい。特に、サービングネットワークノードエンティティ（モバイル管理エンティティ）に、デバイストリガー要求メッセージの内部処理をサポートする情報を提供することを考える。このような情報は、デバイストリガリングのＳＭＳと、他の目的のＳＭＳとを区別することを可能にする情報、もしくは、端末がトリガー要求メッセージの受信後に接続の確立を試みるＡＰＮの識別を可能にする情報、またはその両方を可能にする情報とすることができる。
サービングネットワークノードは、提供される情報と内部処理とに従って、デバイストリガー要求メッセージ（例えばＳＭＳ）を端末に配信しないことと、デバイストリガー要求メッセージが端末（ユーザ機器）に配信されないことを示す指示情報を送信側エンティティ（ＭＴＣ−ＩＷＦ、ＳＭ−ＳＣ、またはＭＴＣサーバ）に発行することとを決定することができる。オプションとして、デバイストリガー要求の再送信が望ましくない、もしくは、新しいデバイストリガー要求メッセージを送信するべきではない、またはその両方である時間期間について、ＭＴＣサーバに通知するタイマーを示すことができる。本発明のこの実施形態については、後から詳しく説明する。
本発明は、さらに解決策を提供し、この解決策によると、指示情報がサーバに送られる。特に、３ＧＰＰシステムに関しては、ネットワークにおけるＡＰＮベースのセッション管理輻輳制御（ＳＭ ＣＣ）の場合に、指示情報がＭＴＣサーバに送られる。このインジケータは、デバイストリガリングの結果としてのアップリンクデータが配信されるか、遅延するか、またはその両方を示すことが好ましい。結果としてのデータは、例えば、測定データ（トリガーされたときに端末が収集して送信する）とすることができる。これに代えて、データは、外部から、または内部的に（すなわちネットワーク内で）端末を一意に識別することを可能にする端末識別情報（例：ＩＰアドレス）とすることができる。通常のトリガー配信報告に加えて、またはこれに代えて、指示情報（「アップリンクデータ配信の指示情報」と称することができる）がＭＴＣサーバに送られる。アップリンクデータ配信の指示情報は、端末において、またはネットワーク内で、例えばＳＧＳＮやＭＭＥなどのサービングコアネットワーク（ＣＮ）ノードにおいて、ＳＭ−ＢＯタイマーの持続時間もしくはアップリンクデータの推定される有効性またはその両方に基づいて求められる。
デバイス（端末）またはネットワークノード（ＳＧＳＮ／ＭＭＥ）が、有効にされている輻輳制御の持続時間を認識している場合、デバイスまたはネットワークは、輻輳が低減／抑制された後にアップリンクデータが有効であるかを判定することができる。特に、端末またはネットワークは、トリガー要求が到着したときに端末において作動しているバックオフタイマーの情報を有することができる。バックオフ時間とは、端末がネットワークとの接続の確立を試みることを控える、またはサーバにデータを送信することを控える時間期間である。バックオフ状態の持続時間が既知であるとき、端末またはネットワークノードは、アップリンクデータが配信されないこと、配信されること、または推定される配信遅延、のうちの少なくとも１つをサーバに示すことができる。
デバイストリガー要求が受信されたときにデバイスにおいて作動中のＢＯタイマーが存在しない場合、本発明の実施形態は、別の解決策を考える。特に、端末またはネットワーク（例：ＳＧＳＮ／ＭＭＥまたはＭＴＣ−ＩＷＦ）は、デバイスがユーザプレーン（Ｕ−プレーン）接続の確立または修正のためのシグナリングを開始した後に、アップリンクデータのターゲットＡＰＮを求め、輻輳制御を適用するかを判定することができる。デバイスまたはネットワーク（例：ＳＧＳＮ／ＭＭＥまたはＭＴＣ−ＩＷＦ）は、このような判定に基づいて、アップリンクデータの配信または遅延についての指示情報をＭＴＣサーバに送る。
ＭＴＣサーバは、ＳＭ−ＢＯが作動している間にアップリンクデータ配信の指示情報を受信した後、本発明の実施形態によると、以下の動作の少なくとも１つを決定することができる。
− ＳＭ−ＢＯタイマーが切れた後にデバイストリガー要求を再送信する。または、
− 新しいデバイストリガーをただちに送る。結果としてユーザ機器は、アップリンクデータを異なる（輻輳していない）ＡＰＮに送る。または、
− 新しいデバイストリガーを高い優先度でただちに送る。これにより、デバイストリガリングの結果としての接続の確立にセッション管理輻輳制御を適用しないようにネットワークに指示される。または、
− 遅延するアップリンクデータの受信を待機する。
アップリンクデータ配信の指示情報は、ネットワーク（例：ＳＧＳＮ／ＭＭＥまたはＭＴＣ−ＩＷＦ）またはユーザ機器のいずれかからＭＴＣサーバに送ることができる。ユーザ機器は、ユーザプレーン接続を確立できないため、指示情報をメッセージ（例：小さなデータ）として制御プレーンを通じてＭＴＣサーバに送ることができる。
要約すると、本発明の特有の方法によると、ネットワーク輻輳の場合にデータが遅れて配信される、またはまったく配信されないことをサーバに通知するため、本発明は、端末において実行される方法と、ネットワークノードにおいて実行される方法と、トリガリングサーバおよび対応する装置（端末、ネットワークノード、およびトリガリングサーバ）において実行される方法とを提供する。
上に説明した問題点を解決する目的で、すなわちデバイストリガー要求の再送信を回避する目的で、デバイストリガリングの結果としてのアップリンクデータの配信／非配信／遅延についてＭＴＣサーバに通知することを提案する。ＭＴＣサーバは、受信された指示情報および内部状態に基づいて、どのオプションを実行するかを決定する。
トリガリングサーバへの指示情報の提供を容易にする目的で、端末またはネットワークノードは、端末からサーバへの接続を確立できるか否かの評価を行うことができ、この場合、ネットワークが輻輳しているかと、バックオフタイマーが作動しているかと、端末におけるバックオフタイマーの残り時間、のうちの少なくとも１つを判定する。次いで、トリガー後にサーバとの接続を確立できないこと、データを送信できないこと、データが遅延して送信されること、のうちの少なくとも１つを示す配信遅延メッセージをサーバに送信する。
これに対して、トリガリングサーバは、端末またはネットワークノードによって提供される配信遅延インジケータを受信し、配信遅延インジケータの処理を実行し、トリガー要求を後の時点で再送信するのか、またはトリガー要求を高い優先度で、または異なるＡＰＮを対象に再送信するのか、または同じネットワークについては別の端末へのトリガー要求の送信を省くのかを決定することができる。
配信遅延指示情報は、端末からのアップリンクデータが遅れて配信されることを示すことができる。したがって、このインジケータは、「アップリンクデータは遅れて配信される」という値を有することができる。オプションとして、遅延の理由を、情報要素「理由」としてシグナリングすることができる。遅延の理由は、例えば、ネットワークの輻輳や、報告されるデータが利用可能ではないこととすることができる。さらなるオプションとして、アップリンクデータの遅延時間の推定値を、情報要素「アップリンクデータの遅延時間」として提供することができる。この遅延は、例えば、ＳＭ−ＢＯタイマーなどの作動中のバックオフタイマーに基づいて、例えば作動中のＳＭ−ＢＯタイマーの残りの値として、求めることができる。
ＭＴＣサーバは、配信遅延インジケータに応えて、予測されるアップリンクデータの緊急性（または有効性）に応じてその次のステップを決定することができる。例えば以下のとおりである。
ＭＴＣサーバは、示された遅延時間の後、遅延したデータが有効であるかを評価することができる。示された遅延時間の後にアップリンクデータがＭＴＣサーバにおいて有効である場合、ＭＴＣサーバは何らの動作も実行する必要がなく、遅延したアップリンクデータを待機することができる。これに対して、示された遅延時間の後にアップリンクデータがＭＴＣサーバにおいて有効ではない状況が起こりうる。このケースは、例えば、アップリンクデータが遅れて配信されることをユーザ機器またはネットワークが示したが、示された遅延の経過後に配信されたときにアップリンクデータがＭＴＣサーバにおいて利用するには有用または有効ではないものとＭＴＣサーバが推定するときに起こりうる。この場合、ＭＴＣサーバは以下を行うことができる。
− 新しいデバイストリガリングの結果としてのアップリンクデータが配信される代替ＡＰＮをＭＴＣサーバが使用できる場合、またはオプションとしてデバイストリガリング手順の優先度が高い場合、ＭＴＣサーバは、遅延時間が切れる前に新しいデバイストリガー要求を送る。
− それ以外の場合、ＭＴＣサーバは、遅延時間が切れるのを待って、新しいデバイストリガー要求を送る。
あるいは、配信遅延インジケータは、データが配信されないことを示すことができる。オプションとして、前のケースと同様に、アップリンクデータが配信されない「理由」をシグナリングすることができ、この理由としては、ネットワークの輻輳や、端末においてデータが利用可能ではないことである。さらなるオプションとして、例えばＳＭ−ＢＯタイマーに基づく「輻輳の持続時間」をインジケータに含めることができる。ＭＴＣサーバは、予測されるアップリンクデータの緊急性（または有効性）に応じてその次のステップを決定する。例えば、前のケースと同様に、以下のとおりである。
− 新しいデバイストリガリングの結果としてのアップリンクデータが配信される代替ＡＰＮをＭＴＣサーバが使用できる場合、またはオプションとしてデバイストリガリング手順の優先度が高い場合、ＭＴＣサーバは、遅延時間が切れる前に新しいデバイストリガー要求を送る。
− それ以外の場合、ＭＴＣサーバは、遅延時間が切れるのを待って、新しいデバイストリガー要求を送る。
一般的には、トリガリングサーバによって実行される本方法では、受信されたインジケータを評価することによって、もしくは、輻輳しない別のネットワークを端末が使用できるかを評価することによって、またはその両方によって、処理ステップを実行する。サーバの処理ユニットは、このような評価を行うように構成することができる。
遅延を示すことを目的として、ＳＭ−ＢＯタイマーの（残りの）値をシグナリングすることができる。なお、現段階のＬＴＥによると、ネットワークからユーザ機器に送信されるＳＭ拒否メッセージの中にＳＭ−ＢＯタイマーを含めるかはオプションである。したがって、デバイストリガリング要求の後にＰＤＰ／ＰＤＮ接続を確立または修正するためのユーザ機器のシグナリングが、ＳＭ−ＢＯタイマーの提供なしに拒否されることがある。このような場合、サービングコアネットワークノード（ＳＧＳＮ／ＭＭＥ）も、ＳＭ ＣＣの持続時間を認識していないことがあり、したがって遅延をＭＴＣサーバに示すことができない。結果として、ＭＴＣサーバへの指示情報には、アップリンクデータが配信されないことについての情報、またはＭＴＣサーバとの接続を確立することができないことについての情報が含まれる。
ＭＴＣサーバに送られる指示情報の決定は、ネットワークにおいて（ＳＧＳＮまたはＭＭＥによって）、またはユーザ機器において行われる。この理由は、デバイストリガリング手順が制御プレーンを通じて実行されるものと想定されるためである。しかしながら、デバイストリガリング手順がユーザプレーンを通じて実行される場合、ユーザプレーンのネットワークエンティティが、ＭＴＣサーバへの指示情報を決定、生成して送ることが可能である。
ＭＴＣサーバは、アップリンクデータの配信／有効性（ＳＭ−ＢＯタイマー）の指示情報を受信した後、異なるＡＰＮを示す新しいデバイストリガー要求をユーザ機器に送ることを決定することができる。このＡＰＮは、データを送るためのバックアップＡＰＮとして使用することができる。この目的のため、ＭＴＣサーバは、ユーザ機器に対して異なる外部ＩＤを使用することができる。異なる外部ＩＤを使用することの利点として、後から説明するように、外部ＩＤは、アップリンクデータを送るためにユーザ機器によって使用されるＡＰＮを直接または間接的に符号化することができる。
さらに、ＭＴＣサーバは、アップリンクデータの配信／有効性（ＳＭ−ＢＯタイマー）のインジケータを、以下のポリシーの１つの適用を開始するための指示情報として使用することができる。
− 同じユーザ機器、または特定のＡＰＮに属しているすべてのユーザ機器、または同じグループまたはＡＰＮの複数のユーザ機器の一部に対して、さらなるデバイストリガー要求を送ることを省く。
− 特定のグループまたはＡＰＮに属しているユーザ機器へのデバイストリガー要求の送信レートを下げる。
これらのポリシーは、ユーザ機器の優先度やデータの緊急性などに従って、いくつかのユーザ機器に選択的に適用することができる。ＭＴＣサーバは、ユーザ機器がデータ接続を確立／アクティブにしているＡＰＮについて認識していないことがある。したがって、特定のＭＴＣアプリケーションのメンバーまたは特定の加入のメンバーによって、ユーザ機器のグループを形成することができる。
上のポリシーの１つを適用する期間は、アップリンクデータ配信／有効性（ＳＭ−ＢＯタイマー）のインジケータにオプションとして含まれる「データ送信遅延」（またはＳＭ−ＢＯタイマー）とすることができる。なお、この場合のオプション性は、標準的なオプション性、すなわち、ユーザ機器またはネットワークノードが、データ配信遅延をＭＴＣに示すか否かをこれらが決定できること、または、ユーザ機器またはネットワークが、事前定義された条件（例えばＳＭ−ＢＯが既知である、もしくは作動中である、またはその両方である）下でのみデータ配信遅延を送ること、と理解することができる。しかしながら、端末もしくはネットワークまたはその両方が遅延の推定値をつねに提供できるようにシステムが構成されているときには、配信遅延を示すことを必須とすることもできる。
これに代えて、またはこれに加えて、新しいデバイストリガー要求を、元々の最初の（または前の）デバイストリガー要求よりも高い優先度で送ることができる。このことは、ＭＴＣサービスプロバイダが、デバイストリガー要求の配信もしくは結果としてのアップリンクデータまたはその両方に、より高い価格を支払うことを意味しうる。しかしながら、たとえユーザ機器がＰＤＰ／ＰＤＮ接続要求に高い優先度を使用する場合でも、要求は依然として同じＡＰＮを対象とする。ＡＰＮベースのＳＭ ＣＣでは、輻輳したターゲットＡＰＮにＳＭ要求メッセージを送ることは許可されないため、３ＧＰＰシステムの現在のリリースでは、この解決策は単独では機能することができない。しかしながら、今後のリリース、あるいは輻輳制御メカニズムにおいて優先度が考慮されるシステムでは、この解決策は依然として採用可能である。なお、デバイストリガー要求の優先度は、以下のように使用できることに留意されたい。
− ネットワークにおける配信メカニズムにおいて使用する。例えばネットワークがある程度（モビリティ管理：ＭＭ）輻輳しており、トリガー要求を配信するか否かを決定するときに使用する。または、
− ユーザ機器によって使用する。例えば、デバイストリガー要求の不透明な（ネットワークに対して透過的な）データ部分に優先度が含まれているときに使用する。この場合、ユーザ機器は、ＭＴＣサーバからのトリガー情報を処理し、より高い優先度を有するＰＤＰ／ＰＤＮ接続要求を生成することができる。
しかしながら、反復されるデバイストリガー要求の高い優先度は、一般的に、ＳＧＳＮ／ＭＭＥまたはネットワークにおいて、図５〜図７にも示した次の方法において使用することもできる。
− デバイストリガリング要求（図５〜図７における「デバイストリガー配信」を参照）の後、ユーザ機器において作動しているＳＭ−ＢＯタイマーが存在しない場合、ユーザ機器はＰＤＰ／ＰＤＮ接続要求（「新しいＰＤＰ／ＰＤＮ要求」を参照）を送る。この場合、ネットワーク（例えばＳＧＳＮ／ＭＭＥ）は、デバイストリガー要求の高い優先度の指示情報を格納しているはずであり、高い優先度を適用することができ、したがってネットワークはユーザ機器からのＰＤＰ／ＰＤＮ接続要求を拒否しない。
− デバイストリガリング要求の後、ユーザ機器において作動しているＳＭ−ＢＯタイマーが存在する場合、ユーザ機器は、図８を参照しながら後から説明する内部処理を実行する。次いで、ユーザ機器は、アップリンクデータの配信／有効性（ＳＭ−ＢＯタイマー）の指示情報をＳＧＳＮ／ＭＭＥに送ることを決定する（図８における「１）アップリンクデータの有効性＋２）ＳＭ−ＢＯ」を参照）。ＳＧＳＮ／ＭＭＥは、ユーザ機器におけるＳＭ−ＢＯタイマーを削除することを決定する目的で、デバイストリガー要求の高い優先度を適用することができる（図８における「ＳＭ ＤＬメッセージ（ＳＭ−ＢＯを削除）」を参照）。
以下では、デバイストリガー要求がネットワークに格納される実施形態について説明する。
ＳＭ輻輳制御が有効であり得るにもかかわらず、ＳＧＳＮ／ＭＭＥがユーザ機器をページングしてデバイストリガー要求を配信する主な理由は２つある。この状況が起こり得るのは、ＳＧＳＮ／ＭＭＥにデバイストリガー要求が到着したときに、ＳＧＳＮ／ＭＭＥがＡＰＮベースのＳＭ ＣＣについて認識していないことがあるためである。１つの理由として、ユーザ機器からのＳＭ要求がＳＭ−ＢＯタイマーを伴って拒否されたときに（図７における「ＰＤＰ／ベアラの拒否（ＳＭ−ＢＯ）」を参照）、ＳＧＳＮ／ＭＭＥはＳＭ−ＢＯタイマーを格納しないことがある。もう１つの理由として、ユーザ機器がデバイストリガーの受信後にアップリンクデータを送るＡＰＮが、ＳＧＳＮ／ＭＭＥにおいて認識されていないことがある。
ＳＭ−ＣＣステータス情報の可用性の問題を解決するため、ネットワーク（ＳＧＳＮ／ＭＭＥ）は、ユーザ機器がデバイストリガーの受信後にアップリンクデータを送るＡＰＮを解決することができる。
ＡＰＮを解決する方法の一例は、事前設定に基づく。ＭＴＣサーバから送信されるデバイストリガーにおいて使用されるユーザ機器の外部識別子（ＩＤ）は、次の構造である。
＜ドメイン＞＜ローカルＩＤ＞
用語＜ドメイン＞は、ユーザ機器のＨＰＬＭＮおよびＭＴＣ−ＩＷＦを識別するためにＭＴＣサーバによって使用される。用語＜ローカルＩＤ＞は、ユーザ機器の加入と内部ＩＤ（例：ＩＭＳＩ）を識別するためにＭＴＣ−ＩＷＦによって使用される。用語＜ローカルＩＤ＞は、ユーザ機器がデバイストリガー要求を受信した後にアップリンクデータを送るＡＰＮ（以下では「ターゲットＡＰＮ」と称する）を、ネットワーク／ＭＴＣ−ＩＷＦが事前設定に基づいて識別することができるような構造とすることができる。
ネットワーク（例：ＳＧＳＮ／ＭＭＥ）は、ターゲットＡＰＮを求めた後、そのターゲットＡＰＮが輻輳制御下にあるかを判定する。ＡＰＮの輻輳制御ステータスを求める目的には、以下にリストするいくつかの動作をネットワークによって実行することができる。
解決されたターゲットＡＰＮに対してＭＭ輻輳制御が有効にされている場合、ＳＧＳＮ／ＭＭＥはユーザ機器へのページング手順を開始するべきではなく、代わりに、ＭＭ輻輳についてＳＭ−ＳＣまたはＭＴＣ−ＩＷＦに報告し、配信されないデバイストリガー要求についても報告する。ＭＴＣ−ＩＷＦ／ＳＭ−ＳＣは、配信されないデバイストリガー要求についてと、オプションとしてその理由（例：ＭＭ輻輳）についてと、オプションとしてＭＭ輻輳の残りの持続時間（例：ＭＭバックオフタイマー）についてと、をＭＴＣサーバに通知する。
解決されたターゲットＡＰＮに対してＳＭ輻輳制御が有効にされており、ユーザ機器がＥ−ＵＴＲＡＮアクセス下でキャンプしている（すなわちＭＭＥに接続されている）場合、ＭＭＥは、ターゲットユーザ機器の格納されているＳＭコンテキストの内部チェックを実行することができる。
− ＭＭＥが、解決されたターゲットＡＰＮへのＥＰＳベアラコンテキストを格納している場合、このことは、ユーザ機器からのＳＭシグナリングなしにＥＰＳベアラが自動的に確立されることを意味しうる。したがって、ＭＭＥはページング手順を開始して、ユーザ機器にデバイストリガーを送信することができる。通常では、サービス要求手順時にユーザプレーンベアラが確立され、ユーザ機器はアップリンクデータをＭＴＣサーバに送信することができる。
− ＭＭＥが、解決されたターゲットＡＰＮへのＥＰＳベアラコンテキストを格納していない場合、このことは、ユーザ機器が、ターゲットＡＰＮへのＰＤＮ接続要求手順（すなわちＳＭシグナリング）を開始することを意味する。ＭＭＥは、デバイストリガー要求を送信するためのページング手順を開始するべきではない。代わりに、ＭＭＥは、ネットワーク内に輻輳が存在しておりデバイストリガーが配信されないことを、ＳＭ−ＳＣ（Ｔ４インタフェースまたはＴｓｍｓインタフェースを通じてＭＴ−ＳＭＳが使用される場合）またはＭＴＣ−ＩＷＦ（Ｔ５インタフェースが使用される場合）に通知することができる。さらに、ＭＭＥは、デバイストリガー要求が配信されない理由／原因（例えばターゲットＡＰＮにＳＭ ＣＣが適用されている）を通知することもできる。ＭＴＣ−ＩＷＦは、この指示情報／情報をＭＴＣサーバに転送することができる。
解決されたターゲットＡＰＮに対してＳＭ輻輳制御が有効にされており、ユーザ機器がＧＥＲＡＮ／ＵＴＲＡＮアクセス下でキャンプしている（すなわちＳＧＳＮに接続されている）場合、ＳＧＳＮはデバイストリガー要求を送信しない。さらなる動作は、ＭＭＥがＥＰＳベアラコンテキストを格納していない上記の場合に実行される動作と同じである。
図４は、ＳＧＳＮ／ＭＭＥがＭＴ−ＳＭＳの形のデバイストリガー要求を受信したときにＡＰＮベースのＳＭ ＣＣを解決できる場合におけるシグナリングフローの例を示している。通信の個々のステップは、参照数字（１）〜（９）によって表してある。ＳＭ−ＳＣは、端末に送信されるトリガー要求をＴ４／Ｔｓｍｓインタフェースを通じてＭＴＣサーバから受信する。第１のステップ（１）において、ＳＭ−ＳＣが、移動体着の対応する（ＭＴ）ＳＭＳをＳＧＳＮに配信する。ＭＴ−ＳＭＳはトリガー要求を含んでいる。ＡＰＮは輻輳しているものと想定する。したがって、第２のステップ（２）において、ＳＧＳＮ（サービングネットワークノード）は、ネットワークが輻輳していること、特に、セッション管理または接続の確立を実行できないことを、ＳＭ−ＳＣに報告する。これに応えて、ＳＭ−ＳＣはＭＴ−ＳＭＳを格納し、格納されたＭＴ−ＳＭＳについてＨＳＳに通知する（３）。ＳＭ−ＳＣは、格納されているＭＴ−ＳＭＳを配信する目的で、ユーザ機器が到達可能になった（すなわちＳＭ ＣＣが終了した）時点でＳＭ−ＳＣに通知するべきことをＨＳＳに知らせるため、フラグ（例：待機フラグ）を使用することができる。輻輳の場合においてより効率的なシグナリングを可能にする目的で、既存の技術にステップ（４）およびステップ（５）を次のように追加する。ステップ（４）において、ＨＳＳ／ＨＬＲは、輻輳が終了したときに報告するようにＳＧＳＮを設定する。したがって、ＳＧＳＮは、輻輳が依然として存在しているかを監視し（５）、ステップ（６）において、輻輳が終了した時点でただちに（すなわち輻輳が終了したことをＳＧＳＮが検出した時点でただちに）ＨＳＳに報告する。ＨＳＳ／ＨＬＲは、ＭＴ−ＳＭＳを送信するようにＳＭ−ＳＣをトリガーし（７）、ＳＭ−ＳＣがＭＴ−ＳＭＳをＳＧＳＮに配信する（８）。ＳＧＳＮが端末をページングする（９）。
要約すると、上の方法では、輻輳状態において、輻輳したネットワークのサービングネットワークノード（例えばＳＧＳＮまたはＭＭＥ）を、輻輳が終了したかをループ方式でチェックするように設定することが可能である。ネットワークノードにおいて輻輳が終了したと判定された時点でただちに、ネットワークノードは輻輳の終了を報告する。この設定は、端末の位置を解決することのできるネットワークエンティティによって実行されることが有利であり、報告もこのエンティティに行うことができる。このエンティティは、上の例のように、ホームロケーションレジスタまたは類似するエンティティとすることができる。今後のシステムにおいては最適化が可能であり、サービングネットワークノード（ＳＧＳＮ／ＭＭＥ）は、輻輳制御の終了についてＳＭ−ＳＣに直接示すことができる。図４において、実線のシグナリングラインは、ユーザ機器に到達できないためにＭＴ−ＳＭＳを遅れて配信するための手順を示している。破線のシグナリングライン（ステップ４およびステップ５）は、デバイストリガー要求を格納する理由として（ユーザ機器に到達できないという通常の理由ではなく）ＳＭ ＣＣが想定されるときに提供される新しい機能を示している。
デバイストリガー要求をネットワークに格納するという提案する解決策には、いくつかの問題点が依然として存在する。例えば、ユーザ機器が接続を確立するＡＰＮをネットワークが解決できないことがある。特に、ネットワークは、外部ＩＤもしくはＭＴＣアプリケーションＩＤ（内部ＩＤ）またはその両方と、対応するＡＰＮとの間のマッピングテーブルを維持する必要がない。
デバイストリガーをネットワーク（例：ＳＭ−ＳＣネットワークノード）に格納することに起因して、コアネットワークにおいてかなり多くのシグナリング（ＨＳＳインタラクションを含む）が発生する（図４を参照）。ネットワーク内に数多くのユーザ機器が存在しうることを考えれば、シグナリングが増大すること自体によって、輻輳の確率が増大したり、輻輳につながることがある。
すでに上述したように、ターゲットＡＰＮに対してＳＭ輻輳制御が有効であるかをＳＧＳＮが認識していないことがある。ＳＭ ＣＣは、ＰＤＰコンテキスト／ＥＰＳベアラ要求の拒否（図５における「ＰＤＰ／ベアラ拒否（ＳＭ−ＢＯ）」を参照）時に、ＳＧＷ／ＰＧＷ／ＧＧＳＮによって有効にすることができ、この拒否は少し前に起きたかもしれず、したがってＳＧＳＮがＳＭ−ＢＯタイマーをユーザ機器に渡したかもしれないが、ＳＧＳＮ自体はＰＤＰコンテキスト（およびＳＭ−ＢＯタイマー）を格納する必要はない。あるいは、ＳＧＳＮ／ＭＭＥは、デバイストリガリング要求を受信した時点で、ターゲットＡＰＮが輻輳していることを認識していないことがあり、なぜならＳＧＳＮ／ＭＭＥが関連する情報を格納していないことがあるためである。要約すると以下のとおりである。ＳＧＳＮは、デバイストリガー要求が受信されたときにＡＰＮ ＳＭ−ＣＣが適用されていることを認識していないことがあり、これはユーザ機器の最初の拒否された（Ｅ）ＳＭ要求の場合に起こりうる。ＥＰＳセッション管理（ＥＳＭ）情報要求がネットワークから端末に送られる。端末は、ＥＳＭ情報応答によって応える。これらのメッセージは、ＥＰＳベアラコンテキストに関連する、ネットワークによって開始される手順に属し、ネットワークによって開始される（ＥＰＳ）コンテキストをアクティブにする役割を果たす。
さらに、ＳＧＳＮは、ユーザ機器がアップリンクデータをただちに送る／報告するかを必ずしも認識せず、なぜなら、ユーザ機器はデバイストリガー要求の受信後にアップリンクデータを収集するためのいくらかの時間を必要とすることがあるためである。背景技術のセクションで説明したように、ユーザ機器を対象とするデバイストリガー要求の中の情報は、ネットワークに対して不透明／透過的である。要約すると、デバイストリガー要求をネットワーク（例：ＳＭ−ＳＣ）に格納し、それを後から再送信することは最適ではなく、なぜなら、いずれにしてもユーザ機器は、アップリンクデータが利用可能となるまでに長い時間を必要とすることがあり、したがってアップリンクデータを後から送信しうるためである。留意すべき点として、ネットワークは、ユーザ機器における固有の処理（すなわちユーザ機器がアップリンクデータをただちに送るか、またはＰＤＰ／ＰＤＮ接続をただちに確立するか、あるいは、ＭＴＣサーバに報告されるデータを測定／収集するための時間をユーザ機器が必要とするか）を認識していない。この情報または固有な処理は、デバイストリガー要求または特にデバイストリガー要求の不透明な（ネットワークに対して透過的な）部分の受信後にユーザ機器において判明するのみである。
要約すると、ＳＧＳＮ／ＭＭＥは、ＡＰＮベースのＳＭ ＣＣを認識しておらず、さらには、データをＭＴＣサーバに送る前にデータを収集／測定するためにユーザ機器において必要な遅延についても認識していない。以下では、これらの問題点も克服することが可能な、本発明の例示的な実施形態を提供する。以下に説明されている実施形態では、ユーザ機器がデバイストリガー要求を受信した時点でユーザ機器においてＳＭ−ＢＯタイマーが作動していない場合に、ユーザ機器にデバイストリガー要求を送信した後にＡＰＮベースのＳＭ ＣＣを解決することが可能である。
一実施形態によると、トリガリングサーバがデバイストリガリング要求を端末に送信する通信ネットワークにおけるサービングネットワークノード（ＭＭＥ／ＳＧＳＮなど）によって実行される方法であって、端末をトリガーするデバイストリガー要求をメッセージサーバから（または一般的にはトリガリングサーバからメッセージサーバを通じて）受信するステップと、デバイストリガー要求もしくは要求されるデータまたはその両方の配信に使用されるネットワークが輻輳制御下にあるかを判定し、輻輳状態をメッセージサーバに報告するステップと、輻輳が終了したかをチェックするステップと、輻輳が終了したと判定された時点で、終了したことを通信ネットワーク内のノードに報告するステップと、を含んでいる、前記方法、を提供する。
特に、報告するステップは、ホーム加入者サーバに向けて実行することができ、ホーム加入者サーバは、デバイストリガー要求をサービングネットワークノードに送信するようにメッセージサーバをトリガーすることができる。しかしながら、後から説明するように、サービングネットワークノードがメッセージサーバに直接報告することもできる。
メッセージサーバは、サービングネットワークノードから輻輳インジケータを受信した時点で、ネットワークが輻輳状態にあることをホーム加入者サーバ（ＨＬＲ／ＨＳＳ）に通知することができる。ホーム加入者サーバは、輻輳が終了することを自身が待機していることを示す内部フラグをセットすることができる。輻輳が終了した時点で、ホーム加入者サーバは、輻輳の終了について通知するメッセージをサービングネットワークノードから受信することができる。ホーム加入者サーバは、このメッセージを受信した時点で、格納されているデバイストリガーメッセージを送信するようにメッセージサーバに指示することができる。
以下では、上にリストした問題点のいくつかを回避するための可能な最適化について説明する。最初に、ＳＧＳＮ／ＭＭＥが、有効にされているＡＰＮベースのＳＭ ＣＣについて認識しているものと想定する。ＳＧＳＮ／ＭＭＥがユーザ機器ごとに（およびＡＰＮごとに）ＳＭ−ＢＯタイマーを格納するかとは無関係に、ＳＧＳＮ／ＭＭＥは、タイマーが切れていない限り、または、ＳＭ ＣＣを停止させるさらなる指示が別のネットワークエンティティから到着しない限りは、ＡＰＮベースのＳＭ ＣＣを適用する。したがって、デバイストリガー（ＤＴ）要求が受信されたときにＡＰＮ ＳＭ ＣＣが適用されていることをＳＧＳＮが認識していない状況は、ユーザ機器の（Ｅ）ＳＭ要求が最初に拒否されるときにのみ起こりうるが、それ以降はこの問題が存在しないものと想定することができる。
上述したようにデバイストリガーをネットワークに格納することによる問題点としては、図４を参照しながら上述したように、これにより、ＨＳＳを含むコアネットワークにおいてシグナリングメッセージ量が増大する。この問題は、ＳＧＳＮ／ＭＭＥとＳＭ−ＳＣとの間のシグナリング交換を最適化することによって解決することができる。特に、ＳＧＳＮ／ＭＭＥは、Ｔ５を通じてのデバイストリガーメッセージまたはＭＴ−ＳＭＳを拒否するとき、ＭＭ／ＳＭ−ＢＯタイマーをＭＴＣ−ＩＷＦまたはＳＭ−ＳＣに含める。ＭＴＣ−ＩＷＦ（Ｔ４を使用する）またはＳＭ−ＳＣは、デバイストリガー有効時間とＭＭ／ＳＭ−ＢＯタイマーとを次のように比較することにより、後からのデバイストリガー配信のためにＭＴ−ＳＭＳを格納するかを決定する。
− デバイストリガー有効時間＞ＭＭ／ＳＭ−ＢＯタイマーである場合、デバイストリガー／ＭＴ−ＳＭＳを格納する。
− デバイストリガー有効時間＜ＭＭ／ＳＭ−ＢＯタイマーである場合、（すでに上述したように）配信できないデバイストリガー要求もしくはＭＭ／ＳＭ−ＢＯタイマーまたはその両方をＭＴＣサーバに報告する。
上に提案した最適化について分かりやすく説明するため、以下では２つの例を示す。最初の例は図１２に示してあり、デバイストリガー要求は、ＭＴ−ＳＭＳの形で、Ｔ４インタフェースまたはＴｓｍｓインタフェースを通じてＳＭ−ＳＣに送られる。図１２では、サービングネットワークノードとしてＳＧＳＮを示しているが、一般的にこのエンティティはＭＭＥまたは他のサービングノードとすることもできる。さらに、図１２は、図を簡潔にするため、ＳＭ−ＳＣとサービングノード（ＳＧＳＮ）との間の直接的なインタフェースを示している。しかしながら、これらの間に別のネットワークエンティティが存在することもできる。ＭＴ−ＳＭＳを送信するステップと、ＭＴ−ＳＭＳを格納するまたは格納しないステップは、図には簡潔に記載されている。
第１のステップ（１）において、ＭＴ−ＳＭＳがサービングネットワークノード（ＳＧＳＮ／ＭＭＥ）に配信される。次いで、ステップ（２）において、サービングネットワークノードは、ＭＭ輻輳制御またはＳＭ輻輳制御が適用されているかを判定するための内部チェックを実行する。さらに、ステップ（２）では、送信前にＳＧＳＮ／ＭＭＥにおいてＭＴ−ＳＭＳの処理を実行する。現在の技術によると、ＳＧＳＮ／ＭＭＥは、ＭＴ−ＳＭＳが「通常の」目的に使用されるのかデバイストリガー要求として使用されるのかをおそらく解決できないため、ＳＧＳＮ／ＭＭＥは、保守的な方法を選択し、ユーザ機器がデバイストリガーサービスに加入している、またはデバイストリガーサービスに対して設定されている場合、ＭＴ−ＳＭＳがデバイストリガー要求として使用されているものと想定することができる。しかしながら、将来的には、ＭＴ−ＳＭＳがデバイストリガー目的に使用されることをＳＧＳＮ／ＭＭＥに示す情報を、ＭＴ−ＳＭＳメッセージが（好ましくは、ＳＧＳＮ／ＭＭＥに対して透過的であるＭＴ−ＳＭＳヘッダの中に）含んでいることができる。さらには、ＳＧＳＮ／ＭＭＥがターゲットＡＰＮを解決できないことがある。これが実際に起こる理由として、ＭＴＣアプリケーションの関連情報が、ＳＧＳＮ／ＭＭＥに対して透過的であるＳＭＳ本体に含まれているためである。この場合も、ＳＧＳＮ／ＭＭＥは保守的な方法を選択することができ、ユーザ機器が加入しているＡＰＮの少なくとも１つが輻輳している場合、特にＭＭ輻輳制御が適用されている場合、ＭＴ−ＳＭＳを拒否することを決定することができる。
ステップ（３）において、サービングノードは、ＭＴ−ＳＭＳを配信できないことを、端末へのメッセージを生成する責務を負うサーバ（ＳＭ−ＳＣなど）に通知する。さらに、サービングネットワークノード（ＭＭＥ／ＳＧＳＮ）は、このメッセージにＭＭ／ＳＭ−ＢＯタイマーを添付することができる。サーバにＭＭ／ＳＭ−ＢＯタイマーを提供する利点として、その場合、サーバは、実行するべきさらなるステップについて決定することができる。サーバは、受信されたＭＭ／ＳＭ−ＢＯタイマーと、ＭＴ−ＳＭＳの有効時間とを比較することが好ましい。特に、（残りの）バックオフ時間（ＳＭ−ＢＯまたはＭＭ−ＢＯ）がＭＴ−ＳＭＳメッセージの有効性よりも長い場合、メッセージを生成するサーバ（ＳＭ−ＳＣ）は、デバイストリガーを配信できないことを、ＭＴＣサーバ（トリガリングサーバであり、デバイストリガーの発行元であるサーバ）に通知する。さらに、メッセージを生成するサーバは、ＭＴＣサーバがデバイストリガーをただちに再送信することを回避する目的で、ＭＭ−ＢＯもしくはＳＭ−ＢＯまたはその両方を添付し、それをＭＴＣサーバに送ることができる（ステップ（５.１）を参照）。
これに対して、（残りの）バックオフ時間（ＳＭ−ＢＯまたはＭＭ−ＢＯ）がＭＴ−ＳＭＳメッセージの有効性よりも短い場合、メッセージを生成するサーバ（ＳＭ−ＳＣ）は、ＭＴ−ＳＭＳを格納し、後からそれを再送信することができる（ステップ（５.２）を参照）。例えば、メッセージを生成するサーバ（エンティティ）は、バックオフタイマー（ＳＭまたはＭＭ）が切れた時点でただちに、格納されているＭＴ−ＳＭＳをサービングネットワークノードに再送信することができる。
サービングネットワークノードは、（再）送信されたＭＴ−ＳＭＳを受信した後、端末をページングし、端末にＭＴ−ＳＭＳを配信することができる。
なお、上の方法は、ＭＭ輻輳のみに適用することができる、または、ＳＭ輻輳のみに適用することができる。しかしながら、上の方法をＭＭ輻輳制御およびＳＭ輻輳制御の両方に適用することもできる。
図１３は、さらなる１つの例を示しており、この場合、デバイストリガー要求はＴ５インタフェースを通じてＳＧＳＮ／ＭＭＥに配信される（ステップ（１）を参照）。ステップ（２）において、ＳＧＳＮ／ＭＭＥは、図１２において上述したように、類似する処理をデバイストリガー要求に適用する。しかしながら、前の例との違いとして、サービングネットワークノード（ＳＧＳＮ／ＭＭＥ）は、受信されたダウンリンク（ＤＬ）メッセージの目的について、より確信を持つことができ、すなわち、ＳＧＳＮ／ＭＭＥは、このメッセージはＴ５インタフェースを通じて受信されたためデバイストリガー要求メッセージであると結論することができる。言い換えれば、Ｔ５インタフェースを通じてダウンリンクメッセージが受信されることは、そのメッセージがデバイストリガー目的に使用されることを示している。ターゲットＡＰＮに関しては、ＳＧＳＮ／ＭＭＥは、（図１２と同様に）ターゲットＡＰＮを解決できないことがあり、なぜなら関連情報がデバイストリガー要求メッセージ本体内の、ネットワークに対して不透明な情報の中に含まれているためである。したがって、ユーザ機器が加入しているＡＰＮの１つが現時点でＭＭ輻輳制御下またはＳＭ輻輳制御下にある場合、ＳＧＳＮ／ＭＭＥは、保守的な方法を選択して、デバイストリガー要求を拒否することを決定することが有利である。
サービングネットワークノードは、輻輳制御のためデバイストリガー要求を配信できないことをＭＴＣ−ＩＷＦに通知する（ステップ（３）を参照）。さらに、サービングネットワークノードは、この情報にバックオフタイマーを添付することができる。ＭＴＣ−ＩＷＦは、受信されたバックオフ時間とデバイストリガーメッセージの有効時間とを比較する（ステップ（４）を参照）。特に、（残りの）バックオフ時間（ＳＭ−ＢＯまたはＭＭ−ＢＯ）がデバイストリガーメッセージの有効性よりも長い場合、ＭＴＣ−ＩＷＦは、デバイストリガー要求を配信できないことをＭＴＣサーバに通知する。さらに、ＭＴＣサーバがデバイストリガー要求をただちに再送信することを回避する目的で、ＭＴＣ−ＩＷＦは、ＭＭ−ＢＯもしくはＳＭ−ＢＯまたはその両方を添付して、それをＭＴＣサーバに送ることができる（ステップ（５.１）を参照）。
これに対して、（残りの）バックオフ時間（ＳＭ−ＢＯまたはＭＭ−ＢＯ）がＭＴ−ＳＭＳメッセージの有効性よりも短い場合、ＭＴＣ−ＩＷＦは、デバイストリガー要求をＴ４インタフェースを通じてＳＭ−ＳＣに送信する。ＳＭ−ＳＣは、デバイストリガー要求を格納する。ＳＭ−ＳＣは、バックオフ時間が切れた後、デバイストリガー要求を端末に送信する。バックオフタイマーは、ＭＴＣ−ＩＷＦからＳＭ−ＳＣにシグナリングすることができる、または、タイマーが切れた後にデバイストリガー要求を再送信するように、別の方法においてＭＴＣ−ＩＷＦからＳＭ−ＳＣに指示することができる。
以下では、ターゲットＡＰＮを求めるためのＳＧＳＮ／ＭＭＥにおけるさらなる処理オプションについて説明する。
重要な点として、図４、図１２、および図１３に示した例は、ＳＧＳＮ／ＭＭＥがＭＭ輻輳制御およびＳＭ輻輳制御の両方を適用するときにあてはまる。ＭＭ ＣＣ（輻輳制御）は、一般的なＭＭおよびＡＰＮベースの輻輳制御のいずれのタイプとすることもできる。
一実施形態によると、サービングネットワークノードを含み、トリガリングサーバがトリガー要求を端末に送信する通信ネットワーク、における制御サーバにおいて実行される方法、を提供する。本方法は、端末をトリガーするデバイストリガリング要求をトリガリングサーバから受信するステップと、トリガー要求をデバイストリガリングメッセージにカプセル化するステップと、デバイストリガリングメッセージをサービングネットワークノードに送信するステップと、デバイストリガリングメッセージを配信できないという情報およびバックオフタイマーを、サービングネットワークノードから受信するステップと、バックオフ時間がデバイストリガリングメッセージの有効性よりも長いかを評価するステップと、バックオフ時間の方が長いとき、デバイストリガー要求を配信できないことの指示情報と、デバイストリガー要求がただちに再送信されることを抑制するためのバックオフタイマー（必要時）とを、トリガリングサーバに送信するステップと、を含んでいる。この場合、制御サーバは、メッセージサーバ、すなわち、デバイストリガー要求がカプセル化されて端末に提供されるメッセージを作成する通信ネットワークエンティティとすることができる。このエンティティは、例えばＳＭ−ＳＣとすることができる。しかしながら、上述したように、制御サーバは、ＭＴＣ−ＩＷＦなどのデバイストリガー制御サーバとすることもでき、このサーバは、デバイストリガーメッセージを生成するサーバとトリガリングサーバとの間に、特にデバイストリガー機能のためのインタフェースを提供する通信ネットワークエンティティである。
トリガリングサーバは、デバイストリガー要求の発行元であるサーバである。このサーバはＭＴＣサーバとすることができ、ＭＴＣサーバは通信ネットワークの外側に位置することができる。デバイストリガーメッセージは、ＳＭＳとすることができる。
バックオフタイマーの方が短いとき、メッセージサーバは、バックオフタイマーが切れたとき、または切れた後に、デバイストリガーメッセージをサービングネットワークノードに（サービングネットワークノードを通じて端末に）送信するステップをさらに実行することが有利である。
これに代えて、バックオフタイマーがデバイストリガー要求の有効時間よりも短いとき、デバイストリガー制御サーバは、バックオフタイマーが切れたとき、または切れた後に、デバイストリガー要求をメッセージサーバに送信するステップをさらに実行することができ、メッセージサーバは、デバイストリガー要求を格納し、輻輳が終了したとき、もしくはバックオフタイマーが切れたとき、またはその両方の時点で、デバイストリガー要求をサービングネットワークノードに送信する。さらなる代替形態として、デバイストリガー制御サーバは、バックオフタイマーを含むデバイストリガー要求を、格納してサービングネットワークノードに送信できるように、ただちにメッセージサーバに送信することができ、メッセージサーバは、バックオフタイマーが切れた後、または切れたときに、デバイストリガー要求を格納する。なお、バックオフタイマーは、トリガリングサーバまたはメッセージサーバがデバイストリガー要求の（再）送信を抑制するべき時間期間の意味を持つことに留意されたい。
上の３つの実施形態に共通する点として、トリガリングサーバがトリガー要求を端末に送信する通信ネットワーク内の通信ネットワークエンティティは、輻輳に起因してトリガー要求を端末に配信できないという指示情報を、通信ネットワーク内のサービングネットワークノードから取得する。この場合、ネットワークエンティティは、輻輳が終了するまで待機し、終了した後にデバイストリガー要求を端末に送信する。輻輳の終了は、サービングネットワークノードから情報を取得することによって、または、サービングネットワークノードから受信されるバックオフ時間を、デバイストリガー要求の有効時間とともに評価することによって、判定することができる。
前述した欠点を回避する目的で、この実施形態においては、サービングコアネットワークノード（例：ＳＧＳＮ／ＭＭＥ）は、たとえターゲットＡＰＮに対してＳＭ ＣＣが動作していることを検出できる場合にも、デバイストリガー要求をユーザ機器に配信する。デバイストリガー要求をユーザ機器に配信することによって、以下が回避される。
− デバイストリガーがネットワークに不必要に格納されること。
− ユーザ機器が、測定、またはユーザ機器内部の別のデータ収集手順を開始するべき場合の、ユーザ機器における不必要な遅延。したがって、サービングコアネットワークノードがターゲットＡＰＮを求めることができるかには無関係に、かつ、サービングコアネットワークノードが、ＡＰＮベースのＳＭ ＣＣが適用されているかを判定できるかには無関係に、サービングコアネットワークノードは、つねにデバイストリガー要求をユーザ機器に送信する。
この実施形態に従って、ＳＭ ＣＣ中にデバイストリガー要求をユーザ機器に配信する結果として、次の２つの異なる手順につながる。
− デバイストリガリングの結果をＭＴＣサーバに報告するトリガー配信報告（３ＧＰＰによってすでに考えられている、図５における「トリガー配信報告」を参照）
− アップリンクデータをＭＴＣサーバに送ることに対するＳＭ ＣＣの影響を報告するためのアップリンクデータ指示情報（本発明によって提供され、本文書では配信遅延指示情報とも称する）（図５における「オプション１」および「オプション２」を参照）
両方の手順は、互いに独立して実行することができ、例えば、アップリンクデータ指示情報手順を後から実行する、または両方の手順を平行して実行することができる。両方の手順が平行して実行される場合、これらの手順は依然として独立していることができ、例えば、個別のメッセージをユーザ機器／ネットワークノードからＭＴＣサーバに送ることができる。これに代えて、例えば両方の手順に関連する情報（データ）を伝える１つのメッセージを提供することによって、２つの手順を１つの手順に融合することができる。図５〜図９に図解されているさまざまな実施形態においては、アップリンクデータ指示情報もしくはトリガー配信報告またはその両方を提供するためのさまざまな可能な方法が示されており、以下ではこれらについて詳しく説明する。
図５は、デバイストリガー要求がつねにユーザ機器に送られ、アップリンクデータ配信の結果をＭＴＣサーバに示すための手順が実行される場合のシグナリングフローを示している。特に、図５は、ＭＴＣサーバがトリガー要求を生成し、それを端末に送信することを示している。この送信は、背景技術のセクションで説明したように、Ｔ４インタフェースまたはＴ５インタフェースを通じて実行することができる。これは、「デバイストリガー配信（Ｔ４またはＴ５を通じて）」および「ＮＡＳ／ＲＲ接続」に対応する。さらに、図５は、デバイストリガー要求を受信した後、ユーザ機器が、アップリンクデータを生成してＭＴＣサーバに報告する前に、例えば測定を実行するためのいくらかの時間を必要としうることを示している（図５における「不確定な時間長」を参照）。アップリンクデータを生成するためにユーザ機器に必要とされる時間の長さ（例：測定のための時間長）は、一般にはネットワークには認識されない。ＳＧＳＮ／ＭＭＥは、通常では、ステップ（Ａ）において、「トリガー配信報告」を生成し、ＭＴＣ−ＩＷＦおよびさらにはＭＴＣサーバに送信する。デバイストリガーが端末に正常に配信されたときには、トリガー配信報告は「成功」を示す。結果として、ＭＴＣサーバは、ユーザ機器が例えばアップリンクデータを報告するために通信を開始することを予測する。
図５は、アップリンクデータの配信／遅延の指示情報についてＭＴＣサーバに通知するための２つの可能なオプションを示している。いずれのオプションも、灰色の四角の中に示してある。最初のオプション（「オプション１」を参照）においては、ＳＧＳＮ／ＭＭＥ（すなわちネットワークノード）が指示情報（「アップリンクデータ指示情報」メッセージ）を生成し、それをＭＴＣサーバに送る。
第２のオプション（「オプション２」を参照）においては、ユーザ機器が指示情報を生成し、それをＭＴＣサーバに送る。図５において理解できるように、指示情報をＭＴＣサーバに送る前に、ユーザ機器は、ＳＭ−ＢＯタイマーを含む拒否メッセージを受信している（「ＰＤＰ／ベアラ拒否（ＳＭ−ＢＯ）」）。
第１のオプションの利点として、ネットワーク輻輳の場合にシグナリング量の増大を回避するための効率的なメカニズムが提供される。しかしながら、この第１のオプションには、依然として以下の問題点が存在する。
図５において、「問題点１」と示した囲みは、ＳＧＳＮ／ＭＭＥが「アップリンクデータの配信」の指示情報を生成できないことがあることを示している。指示情報を生成できないことがある理由としては、ＳＧＳＮ／ＭＭＥがＭＴＣサーバのアドレスを必ずしも認識していないことや、ＳＧＳＮ／ＭＭＥが、トリガー配信報告を送った後、デバイストリガープロトコルのインタラクションについての情報を格納しないためである。後者は、デバイストリガーメカニズムはステートレス（状態を持たない）である、すなわち、デバイストリガー要求を配信するための経路に沿ったネットワークノードは、特にデバイストリガーが正常に配信された場合（これは想定されるシナリオの場合である）、デバイストリガーについての状態を格納しないという３ＧＰＰにおける現在の想定に基づく。「状態」の意味は、「ユーザ機器ＩＤ」（メッセージが配信された先）、配信の「タイムスタンプ」、メッセージの「宛先ＩＤ」または「送信元ＩＤ」、「使用されたインタフェース」（Ｔ４またはＴ５、あるいはＳＭＳインフラストラクチャまたはＴ５が使用された場合）など、一連の格納されるパラメータである。なお、ここに説明した問題点は、３ＧＰＰの現在の想定に基づいて示した。しかしながら、本発明はこれに制限されず、したがって、異なるシナリオやネットワークにおいては、第１のオプションは、輻輳の場合のシグナリング負荷を減らすための極めて効率的な手段を提供することができる。
図５において「問題点２」と示した囲みは、アップリンクデータの遅延の指示情報を含めることができるようにユーザ機器からのフィードバックを受信するためには、ＳＧＳＮ／ＭＭＥによるＭＴＣサーバへのトリガー配信報告（Ａ）が遅延しうることを示している。しかしながら、遅延の長さは不確定であり、なぜならユーザ機器がＰＤＰ／ＰＤＮ要求手順をいつ開始するか、すなわち送信されるデータの準備がいつ完了するかが不確定であるためである。
結果として、ＭＴＣサーバは、トリガー配信報告が時間どおりに受信されない場合、デバイストリガー要求を再送信することがある。さらには、ＳＧＳＮ／ＭＭＥが、「新しいＰＤＰ／ＰＤＮ要求」を不確定な時間だけ待機することは、プロトコルの設計として不利である。
問題点１を解決するため、本発明の実施形態によると、サービングコアネットワークノード（ＳＧＳＮ／ＭＭＥ）は、正常に配信されたデバイストリガー要求についての「状態」を、いくらかの（事前定義されたまたは所定の）時間だけ格納する。この状態は、「デバイストリガーコンテキスト」と称することができ、ユーザ機器のＮＡＳコンテキストの追加要素／一部として格納することができる。例えば、デバイストリガーコンテキストは、ユーザ機器のＭＭコンテキストの一部として格納することができる。あるいは、ＳＧＳＮ／ＭＭＥがターゲットＡＰＮを解決でき、かつそのＡＰＮのコンテキストを有する場合、デバイストリガーコンテキストを、対応するユーザ機器のＳＭコンテキストに格納することができる。デバイストリガーコンテキストに関連する格納されるパラメータは、例えば、ユーザ機器ＩＤ、メッセージを生成した送信元ノードの送信元ノードＩＤ（例：ＭＴＣ−ＩＷＦ ＩＤ）、デバイストリガー要求の優先度のうちの１つまたは複数とすることができる。格納しておく時間長は、実装に固有とする、またはデバイストリガー有効時間に等しくする、または、ユーザ機器がデバイストリガリング要求への応答としてＭＭ／ＳＭ手順を開始するまでの動的な時間長とすることができる。図５におけるオプション１に示したように、ＳＧＳＮ／ＭＭＥが後から「アップリンクデータ指示情報」を生成する場合、ＳＧＳＮ／ＭＭＥは、ユーザ機器ＩＤおよび宛先ノードＩＤ（例：Ｔ５インタフェースを通じてのトリガリングが使用された場合にはＭＴＣ−ＩＷＦ ＩＤ、Ｔ４またはＴｓｍｓを通じてのトリガリングが使用された場合にはＳＭ−ＳＣ ＩＤ）をシグナリングメッセージに含める。これは、図５には、「ＳＧＳＮがアップリンクデータの遅延の報告（ＳＭ−ＢＯ）を生成する」としてオプション１に示してある。
要約すると、ネットワークノードは、少なくとも、端末のＩＤ、トリガリング要求メッセージを送ったデバイスのＩＤ、他のトランザクションＩＤのうちの１つまたは複数を含むトリガー要求の状態を格納するステップと、配信遅延メッセージを生成して送信するステップであって、配信遅延メッセージが、端末のＩＤ、もしくは、トリガリング要求メッセージを送ったデバイスのＩＤ、またはその両方を含む、ステップと、をさらに含んでいることができる。
Ｔ５インタフェースを通じてのデバイストリガリングの場合、ＳＧＳＮ／ＭＭＥは、ＭＴＣ−ＩＷＦへの「アップリンクデータ指示情報」メッセージを生成する。ＭＴＣ−ＩＷＦは、ユーザ機器ＩＤ（通常ではユーザ機器の内部ＩＤ）に基づいて、ユーザ機器の外部ＩＤと、「アップリンクデータ指示情報」メッセージを送るべきＭＴＣサーバとを求める。さらに、ＭＴＣ−ＩＷＦは、「アップリンクデータ指示情報」メッセージをＭＴＣサーバに転送する前に、Ｔｓｐインタフェースにおいて使用されるプロトコル構造にこのメッセージを適合させる目的で、このメッセージを再フォーマットすることもできる。このオプションの場合、「アップリンクデータ指示情報」をメッセージの中で伝えることができるように、Ｔ５およびＴｓｐにおけるプロトコルを拡張するべきである。これは既存のメッセージとすることができ、または、それぞれのプロトコルにおいて新規のメッセージを定義することができる。
Ｔ４インタフェースまたはＴｓｍｓインタフェースを通じてのデバイストリガリングの場合、ＳＧＳＮ／ＭＭＥは、ＭＴ−ＳＭＳの形のデバイストリガー要求をＳＭ−ＳＣから受信している。この場合、ＳＧＳＮ／ＭＭＥは、格納されているデバイストリガーステータス／コンテキストの中にＳＭ−ＳＣのＩＤを格納している。したがって、ＳＧＳＮ／ＭＭＥは、「アップリンクデータ指示情報」メッセージを生成すると、そのメッセージをＳＭ−ＳＣに送る。ＳＧＳＮ／ＭＭＥにおいて生成される「アップリンクデータ指示情報」メッセージのフォーマットは、ＭＯ−ＳＭＳフォーマットと互換性があることが有利である。ＳＭ−ＳＣは、「アップリンクデータ指示情報」メッセージを受信して、それを正しいＭＴＣ−ＩＷＦ（デバイストリガリングにＴ４が使用された場合）に、または正しいＭＴＣサーバ（デバイストリガリングにＴｓｍｓが使用された場合）に転送することができることが好ましい。
上の解決策の結果として、ＳＧＳＮ／ＭＭＥは、ユーザ機器からのＳＭ要求が拒否されたとき、つねに「アップリンクデータ指示情報」を生成し、（ＭＴＣ−ＩＷＦまたはＳＭ−ＳＣを介して）ＭＴＣサーバに送る。この解決策の場合、２つの問題がさらに考えられる。
第１の問題として、ユーザ機器からのＳＭ要求（図５における「ＰＤＰ／ＰＤＮ要求」を参照）が、デバイストリガリング手順に必ずしも関連していないことがある。例えば、トリガーされたＭＴＣアプリケーションが依然としてデータを収集／測定している間に、ユーザ機器における別のアプリケーションが通信を開始することがある。この場合、ＳＧＳＮ／ＭＭＥは、アップリンクデータが配信されないことを「アップリンクデータ指示情報」の中で誤って報告することがある。この状況を回避するため、ＳＧＳＮ／ＭＭＥは、ユーザ機器からの拒否されるＳＭ要求がデバイストリガリングに起因して開始されていることを確認するべきである。これを実行するため、ＳＧＳＮ／ＭＭＥは、ターゲットＡＰＮを「デバイストリガーコンテキスト」に追加的に格納しておき、そのＡＰＮと、ユーザ機器がＳＭ要求を送るＡＰＮとを比較することができる。ＡＰＮが一致する場合のみ、ＳＧＳＮ／ＭＭＥは「アップリンクデータ指示情報」を生成してＭＴＣサーバに送るべきである。
もう１つの問題として、ユーザ機器は、ネットワークからのＳＭ拒否メッセージを受信した後、既存の接続を介してアップリンクデータを配信することを決定することがある。例えば、Ｅ−ＵＴＲＡＮの場合、ユーザ機器がＭＭＥにアタッチされているとき、実際の接続がすでに存在している間に、ユーザ機器のＳＭによってＰＤＰ／ＰＤＮ接続修正が要求される場合である。あるいは、ユーザ機器は制御プレーンシグナリングを通じて（例えば後から説明するようにスモールデータメッセージとして）アップリンクデータを送ることを決定することができる。このような状況においては、ＳＧＳＮ／ＭＭＥは、アップリンクデータが配信されないことをＭＴＣサーバに報告するが、ユーザ機器は代替手段を介してアップリンクデータをＭＴＣサーバに依然として配信する。この状況を回避する目的で、ＳＧＳＮ／ＭＭＥは、アップリンクデータが配信されないことの指示情報がＭＴＣサーバに送られたことをユーザ機器に示すことができ、したがってユーザ機器はアップリンクデータを送らない。しかしながら、これは最適ではないことがあり、なぜならこの場合、ユーザ機器は代替手段を介してアップリンクデータを送ることができる。したがって、代替の解決策として、ＳＧＳＮ／ＭＭＥからのアップリンクデータ指示情報が、ＭＴＣサーバへの条件付きフラグ／指示情報を含んでおり、この条件付きフラグ／指示情報は、予測される「第１の選択肢」の方法を介してではなく代替方法を介してユーザ機器がアップリンクデータを配信しうることを示す。例えば、ＭＴＣサーバがアップリンクデータをＩＰパケットとして受信することを予測している場合に、ユーザ機器はＳＭＳとしてフォーマットされたアップリンクデータを送る。当然ながら、ＭＴＣサーバは、両方の配信方法におけるアップリンクデータを解析して利用することができるように構成される。
本発明の別の実施形態によると、図５を参照しながら説明した両方の問題点を解決する目的で、拡張機能を実装することができ、この場合、サービングコアネットワークノードは、いずれかのＡＰＮにＡＰＮベースのＳＭ ＣＣが適用されていることを検出できる場合（すなわち、ＳＭ ＣＣがターゲットＡＰＮに適用されているか任意の他のＡＰＮに適用されているかは無関係）、ユーザプレーン接続を有効にするためのＳＭ手順をただちに開始させるための、ユーザ機器への追加の指示情報を含めることができる。ＳＧＳＮ／ＭＭＥからユーザ機器へのこの指示情報は、例えば、「トリガー要求有効時間」（通常はＭＴＣサーバから３ＧＰＰコアネットワークに伝送されるパラメータであるがユーザ機器には使用されない）とすることができる。オプションとして、ＳＧＳＮ／ＭＭＥからユーザ機器への別の指示情報も可能であり、例えば、デバイストリガー配信手順時に、デバイストリガーを伝えるＮＡＳメッセージにおいて特殊なフラグを使用することができる。この追加の指示情報は、図６におけるトリガー配信手順のステップ（「デバイストリガー配信」）において太字（「指示情報ＳＭ ＣＣ」）で示してある。この解決策を使用する場合、ＳＧＳＮ／ＭＭＥは、図５のオプション１における前述した実施形態において実行したように、デバイストリガーコンテキストを格納する必要がない。しかしながら、図６を参照しながら説明した解決策の場合、ユーザ機器への特殊な指示情報を実装する目的で、ＮＡＳプロトコルの拡張と、ユーザ機器およびＳＧＳＮ／ＭＭＥの変更とが必要である。
要約すると、ネットワークノードにおいて実行される本方法は、端末にネットワークとのユーザプレーン接続をただちに確立させるコマンドと、ネットワークが同じデバイストリガー要求を端末に配信することを試行する時間長を示すデバイストリガー有効時間の少なくとも一方を含む輻輳インジケータを、ネットワークノードから端末に送信するステップ、をさらに含んでいることができる。これに対応して、端末において実行される本方法は、そのような輻輳インジケータをネットワークノードから端末において受信するステップ、をさらに含んでいることができる。同様に、本発明の実施形態によるネットワークノードの送信ユニットは、輻輳インジケータを端末に送信するように構成することができ、その一方で、端末の受信ユニットは、輻輳インジケータを受信するように構成することができる。さらに、端末は、ネットワークノードから輻輳インジケータ（「指示情報ＳＭ ＣＣ」を参照）が受信された時点で、接続の確立を含むネットワークとの通信（図６における「新しいＰＤＰ／ＰＤＮ要求」を参照）をただちに開始するようにさらにすることができる。
なお、端末への輻輳インジケータは、デバイストリガリングに対応するアップリンクデータが送られる同じＡＰＮ（ターゲットＡＰＮまたは外部ネットワーク）との接続の確立を開始するようにユーザ機器をトリガーする。これは、ターゲットＡＰＮが輻輳しているかを確認する目的で必要である。したがって、ユーザ機器の内部処理は、ＳＧＳＮ／ＭＭＥからの輻輳インジケータを、ＭＴＣサーバから受信されるデバイストリガー情報に関連付ける機能を提供する。特に、ユーザ機器において複数のアプリケーションが実行中である場合、ユーザ機器から送られるＳＭ要求と、デバイストリガーが受信されるユーザ機器のアプリケーションから発生するＳＭ要求とが一致するようにする。
ユーザ機器は、たとえアップリンクデータが利用可能になるのが後からになる場合にも、ＳＭ手順を実行することができる。ただちにＳＭ手順を開始させるための追加の指示情報は、その特定のユーザ機器に対してＡＰＮベースのＳＭ ＣＣが有効にされるかを判定する目的で有利である。ＳＭ ＣＣが有効にされる場合、図６に示したように、「ＰＤＰ／ベアラ拒否（ＳＭ−ＢＯ）」メッセージがＳＧＳＮ／ＭＭＥからユーザ機器に送信される。
なお、（例えばサービングコアネットワークノードが特定のＡＰＮに対するＳＭ−ＢＯタイマーを格納しないために）ＡＰＮベースのＳＭ ＣＣが適用されているかをサービングコアネットワークノードが検出できない場合、サービングコアネットワークノードは、ただちにＳＭ手順を開始させるためのユーザ機器への指示情報を含めず、図５のシグナリングフローを適用することができる。
この実施形態では、輻輳インジケータを受信した時点でユーザ機器において作動しているＳＭ−ＢＯタイマーが存在しないものと想定し、したがって、ユーザ機器はＰＤＰ／ＰＤＮ接続確立要求を開始する。図６に示したように、ユーザ機器からのこの要求をネットワークがＳＭ−ＢＯタイマーを使用して拒否する場合、ユーザ機器はＳＭ−ＢＯタイマーを格納することができ、非特許文献４に指定されているように、ＡＰＮベースのＳＭ ＣＣの場合の通常の手順を適用することができる。
図６および図７に示したように、ＭＴＣサーバへの「アップリンクデータ配信の指示情報」をどちらのエンティティが生成するかに応じて、２つのオプションが存在する。
オプション１は、図６に示してある。この場合、ＳＧＳＮ／ＭＭＥ（一般的にはネットワークノード）が、ＭＴＣサーバへの指示情報を生成する。この場合、ＳＧＳＮ／ＭＭＥは、ユーザ機器のＳＭ要求にＳＭ ＣＣが適用されることと、したがってアップリンクデータが送られないままでありうることとを認識することができる。拒否メッセージの中でＳＭ−ＢＯタイマーがシグナリングされる場合、ＳＧＳＮ／ＭＭＥは、対応するアップリンクデータの遅延の指示情報としてＳＭ−ＢＯタイマー値を使用することもできる。したがって、ＳＧＳＮ／ＭＭＥは、「アップリンクデータの非配信」と、オプションとして、起こりうる（推定される）遅延とを、ＭＴＣサーバに示すことができる。しかしながら、ＳＧＳＮ／ＭＭＥは、アップリンクデータが有効であるか否かを判定することができず、なぜなら、ＳＧＳＮ／ＭＭＥは、ユーザ機器におけるデータの可用性についての情報と、トリガーデータの有効時間の情報の少なくとも一方を有さないためである。この実施形態においては、ＳＧＳＮ／ＭＭＥは、「トリガー配信報告」と「アップリンクデータ指示情報」とを１回のステップにおいて一緒に送る（図６における「トリガー配信報告＋ＵＬデータ遅延指示情報（ＳＭ−ＢＯ）」）。ＳＧＳＮ／ＭＭＥは、ユーザ機器からの「新しいＰＤＰ／ＰＤＮ要求」（すなわちＰＤＰ／ＰＤＮ接続の要求であり、これは例えばＰＤＰコンテキスト要求またはＰＤＮ接続要求とすることができる）を待機する。ＳＧＳＮ／ＭＭＥは、ＰＤＰ／ＰＤＮ接続を確立または修正する目的で、この要求をコアネットワーク内のユーザプレーンエンティティに転送することができる。ＰＤＰ／ＰＤＮ接続の確立／修正の要求が拒否されるかに応じて、ＳＧＳＮ／ＭＭＥは、デバイストリガー手順の結果として特定のユーザ機器にＡＰＮベースのＳＭ ＣＣが適用されるかを確認することができる。この場合にも、図５においてオプション１を参照しながら説明した問題に類似する問題が発生することがあり、すなわち、ユーザ機器からのＳＭ要求が、デバイストリガリング要求のターゲットＡＰＮに関連していない場合、ＳＧＳＮ／ＭＭＥは、ＳＭ ＣＣ輻輳が有効であるものと誤って判定し、「アップリンクデータ非配信の指示情報」をＭＴＣサーバに送る。この問題は、すでに上述した解決策によって回避することができ、すなわち、ＳＧＳＮ／ＭＭＥは、ユーザ機器からのＳＭ要求が送られる先のＡＰＮと、デバイストリガリング要求のターゲットＡＰＮとを比較する。
さらに別のオプション（実施形態）によると、サービングコアネットワークノード（ＳＧＳＮ／ＭＭＥ）は、「アップリンクデータ配信」の指示情報をＭＴＣ−ＩＷＦに送る。この処理は、デバイストリガリングにＴ５インタフェースが使用されるときに特に有利である。ＭＴＣ−ＩＷＦは、「アップリンクデータ配信」の指示情報を受信して格納することができる。ＭＴＣ−ＩＷＦは、指示情報を格納しておく（すなわちＭＴＣサーバに転送しない）、または指示情報を再フォーマットした後にＭＴＣサーバに転送する、またはその両方（すなわち格納および転送）を実行することを決定することができる。ＭＴＣ−ＩＷＦは、指示情報を格納しておくことを決定した場合、それに続く、ユーザ機器（またはターゲットＡＰＮが同じである別のユーザ機器）へのデバイストリガー要求を、ネットワークを介してユーザ機器に転送する代わりに、拒否することができる。この場合、デバイストリガリングは、ＭＴＣ−ＩＷＦがその特定のデバイストリガリングの状態を格納するため、ステートフル（stateful）プロトコルである。ＭＴＣ−ＩＷＦは、指示情報を転送することを決定した場合（当然ながらＭＴＣ−ＩＷＦは平行して指示情報を格納することができる）、Ｔｓｐインタフェースを通じてＭＴＣサーバに送られる対応するメッセージを生成する。
オプション２は、図７に詳しく示してある。この場合、ユーザ機器が、ＭＴＣサーバへの指示情報を生成する。図６においてオプション１に関して上述したように、ＳＧＳＮ／ＭＭＥは、アップリンクデータの遅延のみをＭＴＣサーバに報告することができる。しかしながら、ＳＧＳＮ／ＭＭＥは、送られるアップリンクデータの有効性を判定することができない（「アップリンクデータの配信／有効性」）。図７に示したように、ユーザ機器側では、ＰＤＰ／ベアラ拒否（ＳＭ−ＢＯ）メッセージを受信した後、本発明の別の実施形態に従って追加の処理を適用し、アップリンクデータの配信／有効性をＳＭ−ＢＯタイマーに基づいて判定する。これについては後からさらに詳しく説明する。「アップリンクデータの配信／遅延」を求める処理は、ユーザ機器においてのみ高い信頼性で実行することができ、なぜなら、アップリンクデータ報告がＭＴＣサーバに送られる前に必要な測定のための時間はユーザ機器のみが認識しているためである。このことは、オプション１と比較したときのオプション２の利点である。図７の実施形態によると、ユーザ機器は、ＳＭ−ＢＯタイマーを含むことのできる「アップリンクデータの配信／遅延」の指示情報（「制御プレーンを通じてのシグナリング／スモールデータ（ＵＬデータ指示情報）」）を、制御プレーンを通じて伝えられるメッセージ（例：スモールデータメッセージ、または移動体発信ＳＭＳ（ＭＯ−ＳＭＳ））としてＭＴＣサーバに送る。
要約すると、配信遅延インジケータを送信するステップは、ネットワークノードへの制御プレーンを通じて実行することができ、このネットワークノードから同様に制御プレーンにおいてインジケータをさらに伝送することができる。
ユーザ機器は、「アップリンクデータの配信／遅延」の指示情報を生成してＭＴＣサーバに送ることのできる自身の能力について、ネットワークに通知するように構成できることが好ましく、したがって、ＳＧＳＮは、「アップリンクデータの遅延」の指示情報を報告することなくトリガー配信報告をＭＴＣサーバに送ることができる。さらには、「アップリンクデータの配信／遅延」の指示情報がユーザ機器から送られることをＳＧＳＮ／ＭＭＥが認識している場合、ＭＭＥは、トリガー配信報告をより早期に、デバイストリガー配信手順の直後に、ＭＴＣサーバに送ることができる。このことも図７に示してある。具体的には、ユーザ機器にトリガーが配信された後、接続の確立（「新しいＰＤＰ／ＰＤＮ要求」）と、ユーザ機器からＭＴＣサーバへのデータ配信遅延インジケータの送信の前に、ＳＧＳＮ／ＭＭＥによって「トリガー配信報告」が送られる。
オプション１またはオプション２の使用は、ユーザ機器とＳＧＳＮ／ＭＭＥとの間で交渉することができる。この交渉は、手順における整合性を確保する目的で有利であり得る。例えば、アタッチ手順またはトラッキングエリア更新（ＴＡＵ）手順時、ユーザ機器とネットワークは、サポートされる好ましいオプションを交渉することができる。しかしながら、本発明では、両方のオプションをサポートする（提供する）ことは要求されない。一方のオプションのみを固定的にサポートし、他方のオプションは提供されないようにＭＴＣシステムを構成することができる。遅延配信指示情報についてＭＴＣサーバに通知するための異なるオプションをサポートする能力を交渉することは、図７を参照しながら説明した実施形態のみならず、本発明のすべての実施形態において適用することができる。
要約すると、ネットワークノードもしくは端末またはその両方は、端末が遅延配信指示情報をサーバに提供するのか、またはネットワークノードが遅延配信指示情報をサーバに提供するのかを示すインジケータを含むメッセージを生成するステップ、をさらに実行することができる。端末もしくはネットワークまたはその両方は、それぞれ、端末が遅延配信指示情報をサーバに提供するのか、またはネットワークノードが遅延配信指示情報をサーバに提供するのかの指示情報に対する肯定確認もしくは否定確認またはその両方を含むメッセージを生成するステップ、をさらに実行することができる。
以下では、本発明の別の実施形態として、デバイストリガーの受信時にユーザ機器においてＳＭ−ＢＯタイマーが作動しているものと想定したとき、デバイストリガーをユーザ機器に送信した後にＡＰＮベースのＳＭ ＣＣをユーザ機器ベースで解決する方式をサポートする実施形態について説明する。
図５〜図７を参照しながら上述した実施形態とは異なり、この実施形態においては、デバイストリガー要求が受信されたときにユーザ機器においてＳＭ−ＢＯタイマーが作動している。したがって、ユーザ機器は、適用されているＡＰＮベースのＳＭ ＣＣについて認識している。なお、この実施形態は、これまでの任意の実施形態と組み合わせることができる。
この実施形態においては、ＳＧＳＮ／ＭＭＥがユーザ機器におけるＳＭ−ＢＯタイマーについて認識していないものとさらに想定する。ＳＧＳＮは、適用されているＳＭ ＣＣについて認識することができるが、非特許文献４のセクション４.３.７.４.２.２に記載されているように、ＳＧＳＮ／ＭＭＥは、ユーザ機器ごとおよびＡＰＮごとにＳＭ−ＢＯタイマーを必ずしも格納しない（ＥＰＳおよびＭＭＥの場合）。ＳＧＳＮ／ＭＭＥがＳＭ−ＢＯタイマーを格納する場合、図４を参照しながら上述したメカニズム／解決策、または図６を参照しながら説明したオプション１を適用することができる。
この実施形態においては、ＳＧＳＮ／ＭＭＥは、一般に適用されているＳＭ ＣＣについて認識している場合、デバイストリガーの配信時に、デバイストリガー有効時間についてユーザ機器に通知することができる。このパラメータ「デバイストリガー有効時間」については、すでに上に簡潔に説明してある。デバイストリガー有効時間は、現時点では（すなわち現在の３ＧＰＰコンセプトでは）、ネットワークがデバイストリガー要求をユーザ機器に配信することを試みるべき時間長を求める目的で、または、最初の配信の試みが（例えばユーザ機器に到達できないために）失敗した場合に、ネットワークがデバイストリガーを格納しておく時間長を求める目的で、ネットワークによって使用される。
この実施形態においては、デバイストリガー有効時間がユーザ機器に提供される。デバイストリガー有効時間についてユーザ機器に通知する利点として、ユーザ機器は、アップリンクデータをＭＴＣサーバに配信するときの、時間遅延に対する耐性を判定するための指示情報として、このパラメータを使用することができる。具体的には、ユーザ機器は、ＭＴＣサーバによって送信されてユーザ機器によって受信される特定のトリガー要求への応答としてＭＴＣサーバに送られるアップリンクデータが、どれくらい遅延しても依然として有効であるかを判定するために、デバイストリガー有効時間を使用することができる。
要約すると、有効時間の指示情報をネットワークノードから端末に送信することができる。有効時間は、現時点で送信されたデバイストリガー要求が有効である時間期間を示すことができる。この時間期間は、ネットワークが現在のデバイストリガー要求の配信を試みる時間期間、もしくは、最初の配信の試みにおいて配信できなかった場合にデバイストリガー要求をネットワークが格納しておく時間、またはその両方に一致させることができる。
上の想定はわずかに不正確なことがあり、なぜならアップリンクデータが有効である時間が、デバイストリガー有効時間よりも短いことがあるためである。例えば、ユーザ機器がデバイストリガリングを受信した後、アップリンクデータはただちに配信されるべきである。しかしながら、デバイストリガー自体は、遅延耐性とすることができる。したがって、ＭＴＣサーバは、アップリンクデータ（配信／遅延）の指示情報を受信した後、ＳＭ−ＢＯタイマーが切れた後にデバイストリガー要求メッセージを再送信する、あるいは新しいデバイストリガー要求メッセージをただちに送るなど、次の動作を決定することができる。さらに、ＭＴＣサーバは、ユーザ機器またはＳＧＳＮ／ＭＭＥによって送られる指示情報の値を反映する動作とは異なる動作をとることを決定することもできる。例えば、ユーザ機器またはＳＧＳＮ／ＭＭＥからのアップリンクデータ指示情報が、アップリンクデータが配信される／有効であることと、遅延ＳＭ−ＢＯタイマーとともに送られることをＭＴＣサーバに通知することがある。しかしながら、ＭＴＣサーバは、依然としてデバイストリガー要求をただちに再送信することを決定することができる（例えば、異なるＡＰＮへの指示情報、ただし一般には同じＡＰＮへの指示情報を含む）。したがって、パラメータ「測定のための時間」が利用可能ではない場合、デバイストリガー有効時間は、ユーザ機器における単なる指示情報として使用される。
図８は、この実施形態の例示的なシグナリングフローを示している。点「１）」は、デバイストリガー配信手順時、またはそのわずか後に、ＳＧＳＮ／ＭＭＥがデバイストリガー有効時間をユーザ機器に示すことを示している（「デバイストリガー有効時間」）。以前の段落で、ＳＧＳＮ／ＭＭＥはデバイストリガー有効時間をユーザ機器に示すかを決定するときにＳＭ ＣＣの存在を考慮できることを説明した。ＳＧＳＮ／ＭＭＥには、デバイストリガー有効時間について他のネットワークエンティティ（ＭＴＣ−ＩＷＦやＳＭＳ−ＳＣなど）によって通知されるものと想定する。したがって、ＳＧＳＮ／ＭＭＥは、さまざまな方法でデバイストリガー有効時間をユーザ機器に示すことができる。
− このパラメータを、個別のダウンリンクＮＡＳメッセージとして送信する、または、
− デバイストリガー要求メッセージを伝えるＮＡＳメッセージの中の個別の情報要素としてこのパラメータを含める、または、
− デバイストリガー要求の「不透明なデータ」の中にこのパラメータを含める。
最初の２つの代替方式はＳＧＳＮ／ＭＭＥによって実行することができ、なぜならダウンリンクＮＡＳメッセージまたはＮＡＳメッセージの中の情報要素はＳＧＳＮ／ＭＭＥ自体において生成されるためである。最後の代替方式は、デバイストリガー要求の不透明な部分を解析および処理するための追加の機能がＳＧＳＮ／ＭＭＥに存在する場合に、ＳＧＳＮ／ＭＭＥによって実行することができる。したがって、デバイストリガー要求の「不透明なデータ」の中にデバイストリガー有効時間を含める最後の代替方式は、さまざまなエンティティによって実行することができ、例えば以下のとおりである。
− ＳＧＳＮ／ＭＭＥ：このエンティティは、「不透明なデータ」を修正または再フォーマットすることが許可されている場合にのみ関与することができる。これは通常の仕様ではなく、場合によっては望ましくない方法であり、なぜなら「不透明なデータ」はネットワークに対して透過的であるべきであるためである。しかしながら、ＳＧＳＮ／ＭＭＥを採用することも可能であり、意図するように機能する。
− ＭＴＣ−ＩＷＦ：ＭＴＣ−ＩＷＦは、ＭＴＣサーバからデバイストリガー要求を受信した後、「不透明なデータ」を修正することができ、ただしこの場合も、「不透明なデータ」を解析するためのＭＴＣ−ＩＷＦの能力に依存する。
− ＭＴＣサーバ：ＭＴＣサーバは、デバイストリガー要求における「不透明なデータ」を生成するため、問題なしにこのシグナリングを実施することのできるエンティティである。しかしながら、デバイストリガー要求における「不透明なデータ」の中に含まれる場合、指示情報の名前および意味は、「デバイストリガー有効時間」とは異なるものとするべきである。１つの可能なオプションは、「アップリンクデータの有効時間」を示すことである。もう１つのオプションは、アップリンクデータをただちに送ることができない場合に、「ユーザ機器におけるデバイストリガーの有効性」を示すことである。アップリンクデータの有効時間は、トリガー要求に応えてユーザ機器からＭＴＣサーバによって受信されるデータが有効であるとみなされる時間期間を示すことができる。
デバイストリガーがユーザ機器に正常に配信された後、ＳＧＳＮ／ＭＭＥは、トリガー配信報告をＭＴＣ−ＩＷＦおよびさらにＭＴＣサーバに送ることができる。
図８の点「２）」は、この時点においてユーザ機器内で内部処理が実行されることを示している。デバイストリガリング要求を受信した後、この処理は、アップリンクデータが送られるＡＰＮを求め（データがただちに送られるか、いくらかの「測定」時間の後に送られるかには無関係）、そのＡＰＮが輻輳制御下にあるか（すなわちそのＡＰＮに対してＳＭ−ＢＯタイマーが作動しているか）を判定する。そのＡＰＮが輻輳制御下にある場合、ユーザ機器は、アップリンクデータの有効性を求める（推定する）ための内部処理をさらに実行する。以下では、ユーザ機器においてＳＭ−ＢＯタイマーが作動しているものと想定する。
ユーザ機器の内部処理２）において、アップリンクデータの配信／有効性を求めた後、ユーザ機器は、図８および図９にそれぞれ示したように、オプションＡ（「オプションＡ」）またはオプションＢ（「オプションＢ」）の一方を実行することを決定することができる。どちらのオプションを実行するかの決定は、ユーザ機器もしくはネットワークまたはその両方における設定に基づくことができ、アタッチ手順またはＴＡＵ手順時に交渉することができる。しかしながら、オプションの一方を通信システムにおいて事前定義することができ、他方は必ずしもサポートしなくてもよい。
ユーザ機器は、図８に示したオプションＡを実行することを決定した場合、求めたアップリンクデータの配信／有効性の指示情報１）、もしくは、残りのＳＭ−ＢＯタイマー値２）、またはその両方を、ＳＧＳＮ／ＭＭＥに送る（「１）アップリンクデータの有効性＋２）ＳＭ−ＢＯ」）。点「３）」は、ＳＧＳＮ／ＭＭＥが、ユーザ機器からの指示情報を受信したときに自身の内部処理を実行できることを示している。この内部処理は、ＳＧＳＮ／ＭＭＥが、アップリンクデータの配信／有効性の指示情報をＭＴＣサーバに転送する／送るか、または、ユーザ機器におけるＳＭ−ＢＯタイマーを削除するための手順を開始するかを、輻輳状況もしくはデバイストリガー要求の優先度またはその両方に基づいて決定することを含んでいることができる。例えば、輻輳状況が緩和されている場合、またはデバイストリガー要求が高い優先度を有する場合、ＳＧＳＮ／ＭＭＥは、代替オプションＡ.２を実行することを決定することができ、すなわち、ＳＧＳＮ／ＭＭＥは、ＳＭ−ＢＯを削除する指示を有するセッション管理ダウンリンクメッセージ（「ＳＭ ＤＬメッセージ」として示してある）をユーザ機器に送る。
例えば、３ＧＰＰシステムにおいては、このようなメッセージは、ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST（デフォルトＥＰＳベアラコンテキストの有効化要求）メッセージ、ACTIVATE DEDICATED EPS BEARER CONTEXT REQUEST（専用ＥＰＳベアラコンテキストの有効化要求）メッセージ、またはMODIFY EPS BEARER CONTEXT REQUEST（ＥＰＳベアラコンテキストの修正要求）メッセージとすることができる。
ユーザ機器は、「ＳＭダウンリンクメッセージ」を受信した後、ＳＭ−ＢＯタイマーを削除／停止することが好ましい。その後、ユーザ機器はＳＭ手順の実行を続行することができる（図５〜図７に示されているように「ＰＤＰ／ＰＤＮ要求」の送信を含む）。
代替オプションＡ.１では、ＳＧＳＮ／ＭＭＥは、アップリンクデータの配信／有効性の指示情報、もしくはＳＭ−ＢＯタイマー、またはその両方をＭＴＣサーバに転送することを決定する。
要約すると、この実施形態によると、端末は、アップリンクデータの有効性インジケータをネットワークノードに送信することができ、このインジケータは、ＳＭ−ＢＯタイマーを含んでいることができるが必須ではなく、トリガー要求に応えて送信されるデータが有効であるか否かを示す。ネットワークノードは、アップリンクデータの有効性インジケータをさらにサーバに転送することができる。輻輳が終了する場合、ネットワークノードは、作動しているバックオフタイマーを削除するように端末に指示するインジケータを含むメッセージを、輻輳の終了時に生成することができる。したがって、端末は、メッセージを受信および解析して、作動しているバックオフタイマーを削除するように端末に指示するアップリンクデータの有効性インジケータを取得できるようにすることができる。したがって、端末は、作動しているバックオフタイマーを削除することができる。
上述した機能をサポートする目的で、ネットワークノードは、端末がサーバと通信するネットワークに輻輳が存在するかを判定する判定手段を含んでいることができる。ネットワークの送信ユニットは、メッセージを生成してそれを端末に送信する手段をさらに含んでいることができる。端末は、メッセージを受信することのできる受信セクションと、バックオフタイマーを削除する（すなわちタイマー機能を終了させる）バックオフタイマー制御ユニットとを含んでいることができる。
ユーザ機器がオプションＢを実行することを決定する、またはオプションＢがユーザ機器によってサポートされるように定義されている場合、ユーザ機器は、ＭＴＣサーバに直接送られる、または中間エンティティを介して送られるシグナリングを生成する。このシグナリングは、例えば以下の形で実行することができる。
− 非特許文献１または非特許文献２に記載されているスモールデータ、または、
− ＭＴＣサーバへの直接的なユーザプレーン送信、または、
− ネットワークエンティティへの制御プレーン送信（このネットワークエンティティは指示情報をさらにＭＴＣサーバに転送することができる）、または、
− 移動体発信ＳＭＳ（ＭＯ−ＳＭＳ）。
ユーザ機器は、新しいユーザプレーン接続を使用できないため、ネットワーク内の制御プレーン（Ｃ−プレーン）を通じて伝えられる、ＭＴＣサーバへのシグナリングを作成することができる。しかしながら、オプションとして、アップリンクデータの配信／有効性（ＳＭ−ＢＯタイマー）の指示情報を、既存のユーザプレーン接続／ベアラを通じて送ることもできる。
なお、図８における点１）、点２）、および点３）は、本発明の実施形態に対応する、ユーザ機器およびＳＧＳＮ／ＭＭＥにおける新規の機能または新規の内部処理を示していることに留意されたい。
以下では、アップリンクデータの配信／有効性の指示情報を求める目的でユーザ機器において点２）において実行することのできる内部処理について、さらに詳しく説明する。
１つの可能な解決策は、アプリケーションに固有なメカニズムに基づく。この場合、ユーザ機器におけるアプリケーションは、アップリンクデータがＭＴＣサーバにおいて有効である時間長（すなわちアップリンクデータを使用または利用できる時間長）を決定する。この解決策は、標準化（すなわち３ＧＰＰ）には関連しておらず、ユーザ機器および場合によってはＭＴＣサーバにおけるＭＴＣ実装に依存する。
別の可能な解決策は、通信層からの（すなわち標準化に関連する）パラメータを考慮する、ユーザ機器における処理に基づく。これらのパラメータとしては以下が挙げられる。
− アップリンクデータを報告する前の測定のための時間、または、
− デバイストリガー要求の有効時間（デバイストリガー有効時間）。
ネットワークからユーザ機器へのデバイストリガー有効時間の配信については、上に説明した。アップリンクデータを報告する前の「測定のための時間」は、ユーザ機器に格納しておく、または「不透明なデータ」（すなわち、デバイストリガー要求の中の、ＭＴＣサーバからＭＴＣデバイス（端末）を宛先とする情報）に含めることのできるパラメータである。
アップリンクデータの有効性を求める目的で、以下の例示的なロジックをユーザ機器において適用することができる。
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.
要約すると、端末は、トリガー要求が受信された後、データの有効時間を、ネットワークを通じてサーバに送信されるデータを収集するのに必要な時間期間として、または、ネットワークが同じデバイストリガー要求を端末に配信することを試みる時間長を示すデバイストリガー有効時間として、求めるステップ、をさらに実行することができる。データを収集するのに必要な時間期間は、測定を実行する、もしくは、サーバに報告できるようにデータを処理する、またはその両方を行うのに必要な時間期間とすることができる。端末においてバックオフタイマーが作動しており、データの有効時間が残りのバックオフ時間よりも小さい場合、端末は、データが期限切れとなること、もしくは、トリガー要求に応えてデータが送られないこと、またはその両方を示す配信遅延インジケータをサーバに示すことができる。一般的には、有効性の指示情報をサーバに送信するとき、この指示情報をサーバに直接送信する、すなわち端末とサーバの間のネットワーク全体に対して透過的に送信することができる。これに代えて、有効性の指示情報は、ネットワークノード（端末がサーバに接続されているネットワークにおいて端末をサーブするネットワークノード）などのネットワークエンティティを通じて送ることができる。
端末またはネットワークノードのいずれかにおいて評価ステップを実行することができ、この評価ステップは、データを端末からサーバに送信するかを判定する、もしくは、端末からサーバへのデータの送信の遅延を求める、またはその両方を目的として、端末側において作動しているバックオフタイマーを評価するステップと、端末によって送信されるデータの有効期間を評価するステップ、のうちの少なくとも一方を含んでいることができる。評価ステップの結果に従って、有効性の指示情報を端末またはネットワークノードによって送信することができる。
ユーザ機器は、アップリンクデータが期限切れとならないものと判定する場合、アップリンクデータの配信／有効性の指示情報をＳＧＳＮ／ＭＭＥに送る（オプションＡ）、または直接ＭＴＣサーバに送る（オプションＢ）ことができ、ただしこのステップは必須ではない。しかしながら、アップリンクデータが期限切れとなるものと判定する場合、ユーザ機器は、アップリンクデータの配信／有効性をＳＧＳＮ／ＭＭＥに（オプションＡ）、またはＭＴＣサーバに（オプションＢ）、送るべきである。
ユーザ機器がアップリンクデータの配信／有効性（ＳＭ−ＢＯタイマー）の指示情報をＳＧＳＮ／ＭＭＥに送ることを決定した場合（すなわち図８におけるオプションＡ）、ユーザ機器は、デバイストリガー配信メカニズムに応じて以下のシグナリングオプションの１つを使用することができる。
デバイストリガー配信にＭＴ−ＳＭＳが使用される場合、ユーザ機器は、拡張されたＳＭ−ＣＰ／ＳＭ−ＲＰプロトコル（ショートメッセージ制御プロトコル／ショートメッセージ中継プロトコル）シグナリングを使用することができる。標準化の観点からは、このメカニズムは欠点を有し、なぜならユーザ機器およびＳＧＳＮ／ＭＭＥにおいてかなり大きな実装の変更が必要となりうるためである。したがって、別のオプションとして、アップリンクデータの配信／有効性（および場合によってはＳＭ−ＢＯタイマー）の指示情報を、ＮＡＳシグナリングを通じて（例えば所定のＮＡＳ情報メッセージの中で）、新規の情報要素としてＳＧＳＮに送る。例えば、ＥＳＭ情報要求手順を使用することができ、この手順は、デバイストリガー配信手順時にネットワークによって開始され、したがって、ユーザ機器は、アップリンクデータの配信／有効性（ＳＭ−ＢＯタイマー）について、をINFORMATION RESPONSE（情報応答）メッセージの中でＳＧＳＮ／ＭＭＥに示すことができる。
一般的には、デバイストリガー配信にはＮＡＳが使用される。ＳＧＳＮへのＮＡＳシグナリングにおける特殊な指示情報を使用することができる。一例として、すでに上に示したように、ＥＳＭ情報要求手順が使用される。
デバイストリガー配信にユーザプレーンが使用される場合、デバイストリガー配信用にユーザプレーン接続／ベアラがすでに確立されているため、同じ接続を使用してアップリンクデータを送ることができる。しかしながら、別のＰＤＰ／ＰＤＮ接続を通じて、または新しい専用ベアラ（適用されているＳＭ ＣＣのためこれは可能ではない）を通じて、アップリンクデータを送るべきである場合、アップリンクデータの配信／有効性（ＳＭ−ＢＯタイマー）の指示情報を、既存のユーザプレーン接続／ベアラを通じて送ることができる。これはむしろオプションＢ（図９を参照）に適用することができ、この場合、ユーザ機器はアップリンクデータの配信／有効性（ＳＭ−ＢＯタイマー）の指示情報を直接ＭＴＣサーバに送る。別の代替方式としては、上述したように、この指示情報をＮＡＳシグナリングを通じて送ることができる。
ユーザ機器は、デバイストリガー配信メカニズムには無関係に、アップリンクデータの配信／有効性（もしくはＳＭ−ＢＯタイマーまたはその両方）の指示情報を生成して送ることもできる。ユーザ機器は、アップリンクデータの配信／有効性（ＳＭ−ＢＯタイマー）の指示情報をフォーマットして送信するための事前定義されたメカニズムを実装することができる。例えば、デフォルトのＭＴＣ−ＩＷＦを使用するようにユーザ機器が事前に設定されるメカニズムを実装することができる。ユーザ機器は、アップリンクデータの配信／有効性（ＳＭ−ＢＯタイマー）の指示情報をＭＴＣ−ＩＷＦに送ることができ、ＭＴＣ−ＩＷＦは、アップリンクデータの配信／有効性（ＳＭ−ＢＯタイマー）の指示情報を再フォーマットし、事前定義されたＴｓｐプロトコルを通じてＭＴＣサーバに転送する。
アップリンクデータの有効性を求めることに関する上の説明は、ＳＭ−ＢＯタイマーが利用可能であることに基づいている。しかしながら、ＳＭ拒否メッセージの中でＳＭ−ＢＯタイマーがユーザ機器に送られない場合、ユーザ機器は、アップリンクデータの有効性を求めることができない。さらに別のオプションにおいては、ユーザ機器がＳＭ−ＢＯタイマーを受信するが、パラメータ「測定のための時間」またはデバイストリガー有効時間をユーザ機器が認識していなければ、この場合もユーザ機器はアップリンクデータの有効性を求めることができない。このような場合、ユーザ機器は、アップリンクデータが配信されないことをＭＴＣサーバに示すことができる。ＳＭ−ＢＯタイマーが利用可能である場合、ユーザ機器はＳＭ−ＢＯタイマーをＭＴＣサーバに示すことができる。したがって、ユーザ機器からＭＴＣサーバへの指示情報の意味は、「アップリンクデータは遅延し、ＳＭ−ＢＯタイマーが含まれている場合、残りのＳＭ−ＢＯタイマー値だけ遅延する」というものである。ＭＴＣサーバにおける評価と、ＭＴＣサーバからのさらなる動作は、ＭＴＣサーバにおける実装に依存することができる。
以下に説明する実施形態によると、デバイストリガリングがＳＭＳを通じて実行されるときに、サービングネットワークノード（ＳＧＳＮやＭＭＥなど）が「通常の」ＭＴ−ＳＭＳと「ＤＴに関連する」ＭＴ−ＳＭＳとを区別できないという問題の解決策を提供する。
ＳＧＳＮ／ＭＭＥは、一般的には、受信されたＭＴ−ＳＭＳに何らかの特定の処理を適用するかを認識しない。デバイストリガリングに使用されるＭＴ−ＳＭＳには特殊な処理が必要であることがあり、なぜなら、デバイストリガリングに使用されるＭＴ−ＳＭＳに起因して、ユーザ機器がＭＴＣサーバとの通信を開始し、したがって３ＧＰＰネットワーク内に新しい接続／ベアラ（またはＰＤＰ／ＰＤＮコンテキスト）を確立するためである。ＳＭ ＣＣの場合、ＳＧＳＮ／ＭＭＥは、新しいＰＤＰ／ＰＤＮコンテキストの確立を制限することを望むことがあり、したがって、デバイストリガリングに使用されるＭＴ−ＳＭＳを制限／ブロックすることを望むことがある。
いくつかの可能な解決策を考慮することができる。
− ＳＧＳＮ／ＭＭＥは、現時点でＳＭ ＣＣ下にあるＡＰＮに加入しているユーザ機器へのすべてのＭＴ−ＳＭＳを拒否することができる。
− ＳＧＳＮ／ＭＭＥは、ＳＭＳをユーザ機器に送信（転送）するかを決定するとき、そのＳＭＳの優先度を考慮することができる。ＳＭＳの優先度は利用可能なパラメータであり、一般にはＳＭＳのヘッダにおいて送信され、ＳＧＳＮ／ＭＭＥから可視である。
− 上の両方の解決策を組み合わせることも可能である。
デバイストリガリングがＴ５インタフェースを通じて実行される場合（すなわちデバイストリガー要求がＴ５インタフェースを通じてＳＧＳＮ／ＭＭＥに到着する場合）、このこと自体を、ユーザ機器がデバイストリガーサービスを使用している（またはデバイストリガーサービスに加入している、またはデバイストリガーサービスを使用することができる）ことをＳＧＳＮ／ＭＭＥに示す指示情報とみなすことができる。
しかしながら、デバイストリガリングがＳＭＳを通じて実行される場合、ＳＧＳＮ／ＭＭＥは、ユーザ機器がデバイストリガーサービスを使用している（またはデバイストリガーサービスに加入している、またはデバイストリガーサービスを使用することができる）かを認識することができない。
したがって、本発明は、ネットワークノード（すなわちＵＭＴＳ／ＬＴＥに具体化する場合、ＳＧＳＮ／ＭＭＥ）の新規の機能／能力として、対象のユーザ機器がデバイストリガー機能に対して設定されている／デバイストリガー機能に加入している／デバイストリガー機能の能力を有するという情報を確立および格納する機能／能力を提供する。この能力の１つの特殊な場合は、ＳＧＳＮ／ＭＭＥが、受信されたデバイストリガー要求メッセージがデバイストリガリング機能に関連することを判定できることである。このことは、デバイストリガー要求メッセージがＭＴ−ＳＭＳとしてＳＧＳＮ／ＭＭＥに送られるときには、特に課題である。この情報の確立／作成は、いくつかの方法（これらは組み合わせることができる）で実行することができ、以下ではその例を提供する。
端末のデバイストリガリング設定に関する情報をサービングネットワークノードが登録するための第１の可能な方法は、端末に割り当てられている優先度またはサービス品質を評価することである。例えば、ユーザ機器が「低優先度」のサービスに対して設定されている、または、ＲＲＣプロトコルに挿入された「遅延耐性」指示情報（これは一般的には「低優先度」に等しい意味を持つ）を有するＲＡＮにユーザ機器がアクセスするとき、ＳＧＳＮ／ＭＭＥは、この情報をユーザ機器に関連するコンテキストに格納する。現在、ＬＴＥにおいては、この情報はユーザ機器／デバイスの設定に関連し、対象のアプリケーションに対してのみではない。ＳＧＳＮ／ＭＭＥは、「低優先度」または「遅延耐性」情報を使用して、ユーザ機器がＭＴＣアプリケーションに対して設定されており、したがってユーザ機器がデバイストリガリング機能を使用しうることを決定することができる。したがって、ＳＧＳＮ／ＭＭＥは、受信されたＭＴ−ＳＭＳがデバイストリガリングに使用されるものと結論することができ、そのＭＴ−ＳＭＳをユーザ機器（端末）に送信しないことを決定することができる。言い換えれば、サービングネットワークノードは、特定の端末（通信デバイス）についてその優先度またはサービス品質を求め、求めた情報を端末に関連して格納する。端末が接続を確立する外部（セッション管理）ネットワーク（ＡＰＮ）が輻輳している場合、サービングネットワークノードは、デバイストリガー要求を端末に転送するか否かを、格納されている情報を使用して決定する。特に、端末の優先度（またはサービス品質）が低い場合、サービングネットワークノードはデバイストリガー要求（もしくは他のメッセージまたはその両方）を端末に配信しない。端末の優先度（またはサービス品質）が高い場合、サービングネットワークノードはデバイストリガー要求（もしくは他のメッセージまたはその両方）を端末に配信する。用語「低優先度」は、そのようにマークされているサービスを意味する。用語「低サービス品質」は、高い品質要件（すなわち配信遅延もしくは誤り率またはその両方に関する要件）が課されていないサービスに関連する。
この解決策の欠点として、ＬＴＥにおいては、「低優先度」に対して設定されているすべてのユーザ機器がＭＴＣアプリケーションを使用しているわけではない。例えば、ネットワーク事業者は、低優先度のアプリケーション（例：マルチメディアサービスを使用せずにインターネットにアクセスする）のみを使用しているいくつかのデバイス／ユーザ機器を、これらのデバイスがＭＴＣアプリケーションを実装していなくても、「低優先度」ユーザ機器として設定することがある。したがって、ネットワークは、ＭＴＣアプリケーションを実装していないこれらの「低優先度」ユーザ機器が、デバイストリガリングサービスを使用しているものと誤って結論することになる。さらには、ＭＴＣアプリケーションを使用しているすべてのユーザ機器が、実際にデバイストリガリングサービスに対して設定されている、またはデバイストリガリングサービスの能力を有するわけではない。例えば、仕様書である非特許文献１には、ＭＴＣを使用する場合として、例えばユーザ機器のみが通信を開始することができる（すなわちネットワークはこれらのユーザ機器をトリガーしない）場合が数多く記載されている。この意味において、デバイストリガリングは、ユーザ機器において実装または設定されていることもあれば、そうでないこともある機能または能力であると考えられる。したがって、この方法（すなわちユーザ機器における「低優先度」設定を考慮する）を使用すると、そのユーザ機器がデバイストリガリングに対して設定されている、またはデバイストリガリング能力があるものとＳＧＳＮ／ＭＭＥが誤って解釈することにつながりうる。
端末のデバイストリガリング設定に関する情報をサービングネットワークノードが登録するための第２の可能な方法は、端末のトリガー要求が、デバイストリガリングのトラフィックのみに使用されるインタフェースを通じて受信されたか、またはそのようなエンティティから受信されたかを評価することである。例えば、ＬＴＥにおけるＴ５インタフェースおよびＭＴＣ−ＩＷＦは、このようなインタフェースおよびエンティティに相当する。トリガー要求が端末のＭＴＣ−ＩＷＦから受信された場合、その端末は、デバイストリガリングをサポートする端末としてサービングネットワークノードに格納される。そうでない場合、その端末は、デバイストリガリングをサポートしない端末としてサービングネットワークノードに格納される。この場合、サービングネットワークノードは、メッセージ（ＳＭＳ）を端末に転送するか否かを、端末について格納されている情報を使用して決定する。特に、端末がデバイストリガリングをサポートするものとして格納されている場合、メッセージは転送されない。端末がデバイストリガリングをサポートしないものとして格納されている場合、メッセージは転送される。
３ＧＰＰシステム（ＧＰＲＳ／ＵＭＴＳ／ＬＴＥ）においては、ＳＧＳＮ／ＭＭＥが、あるユーザ機器へのデバイストリガー要求をＴ５インタフェースを通じて受信したとき、このことは、そのユーザ機器がデバイストリガーサービスを使用している（または加入しているまたは能力がある）ことの指示情報として使用することができる。したがって、ＳＧＳＮ／ＭＭＥは、このユーザ機器がデバイストリガーサービスに対して設定されている／能力があるという情報を確立／作成して、ユーザ機器のコンテキストに格納することができる。しかしながら、この解決策の欠点として、ユーザ機器によってはＳＭＳを介してのみトリガーされる（すなわちそれらのユーザ機器ではデバイストリガー要求がＴ５インタフェースを通じて到着することはない）。さらに、ネットワーク事業者によっては、Ｔ５インタフェースが実装されない、またはローミングユーザ機器にＴ５インタフェースが使用されないことがある。なお、第１の可能な方法および第２の可能な方法（本方法）の両方を組み合わせて、端末がデバイストリガリングをサポートしているか否かを判定（推定）することができる。
端末のデバイストリガリング設定に関する情報をサービングネットワークノードが登録するための第３の可能な方法は、加入者データを格納しているホーム加入者サーバから情報を取得することである。特に、ＨＳＳ／ＨＬＲから例えばＳ６ａインタフェースを通じてＳＧＳＮ／ＭＭＥに伝えられる加入情報において、デバイストリガーサービスを使用するためのユーザ機器の設定／能力についてＳＧＳＮ／ＭＭＥが認識することが可能である。
端末のデバイストリガリング設定に関する情報をサービングネットワークノードが登録するための第４の可能な方法は、ポート番号を評価することである。ポート番号は、トランスポート層プロトコルメッセージ（伝送制御プロトコル（ＴＣＰ）またはユーザデータグラムプロトコル（ＵＤＰ））またはＭＴ−ＳＭＳにおけるポートとして求めることができる。ポート番号の意味（ポートの目的）は、端末から、またはホーム加入者サーバから取得することができる。この場合、サービングネットワークノードは、受信したメッセージの中のポートと、デバイストリガリングに使用されるポート番号とを比較し、メッセージのポート番号がデバイストリガリングに使用されるポート番号に一致しない場合、メッセージを端末に送信することができる。これに対して、特にＮＡＳ ＳＭ ＣＣの場合、ポート番号が一致するとき、サービングネットワークノードは、メッセージを端末に送信しないことを決定することができる。ＬＴＥシステムの表現法においては、デバイストリガーサービスを使用するためのユーザ機器の設定／能力についての情報をＳＧＳＮ／ＭＭＥが求めるための別の可能な方法は、Ｔ５を通じてのトリガリングが採用されているときに、ＭＴ−ＳＭＳ、または場合によってはＴＣＰ／ＵＤＰメッセージにおいて使用される特殊ポート番号に基づく。用語「ポート番号」は、プロトコルメッセージのペイロードに含まれている情報が転送される先のアプリケーションまたは機能を示す。例えば、ＳＭＳポート番号は、ＳＭＳのペイロードが転送されるアプリケーション（例：汎用加入者識別モジュール（Universal Subscriber Identity Module:USIM）アプリケーションまたはワイヤレスアプリケーションプロトコル（Wireless Application Protocol：ＷＡＰ）アプリケーション）を意味する。同様に、特殊ポート番号は、ＭＴ−ＳＭＳに含まれている情報をデバイストリガリングサービス層またはディスパッチャ機能に転送するため、ユーザ機器において指定することができる。ＳＧＳＮ／ＭＭＥは、この特殊ポート番号を使用できるように設定することができ、デバイストリガー要求メッセージを検査することができる。ＳＧＳＮ／ＭＭＥは、特殊ポート番号について、ユーザ機器から、またはＨＳＳ／ＨＬＲからの加入情報から認識することができる。この解決策の欠点として、ＳＧＳＮ／ＭＭＥは、使用されているポート番号の場合にデバイストリガー要求メッセージを検査できないことがある。ポート番号情報がＳＧＳＮ／ＭＭＥに対して透過的であると考えることができる。
なお、ポート番号に代えて、またはポート番号に加えて、ペイロードタイプを使用して、デバイストリガリング機能に関する端末の能力を判定することができる。特に、プロトコルは、一般に、ペイロードのタイプを示すためにヘッダに含まれている一種の「ペイロードタイプ」フィールドを有する。このフィールドは、プロトコル記述子またはプロトコル識別子と称される。例えば、ＩＰプロトコルにおいては、ＴＣＰプロトコルのペイロードが含まれているのか、ＵＤＰプロトコルのペイロードが含まれているのかをシグナリングすることができる。ＩＰｖ６のヘッダは、「次のヘッダ」と称されるフィールドを有し、このフィールドは、次のプロトコルヘッダのタイプを示す。同様に、ＮＡＳメッセージのヘッダは、デバイストリガリングに固有のプロトコルなどのペイロードタイプをシグナリングするペイロードタイプ記述子を含んでいることができる。
端末のデバイストリガリング設定に関する情報をサービングネットワークノードが登録するための第５の可能な方法は、端末から明示的にシグナリングされる情報を受信することである。特に、端末は、例えば、自身がデバイストリガリングをサポートするか、デバイストリガリングが現時点で設定されている／アクティブであるか、現時点でデバイストリガー要求をディスパッチするか、またはデバイストリガリング機能のための設定することのできる任意のパラメータを、サービングネットワークノードにシグナリングすることができる。３ＧＰＰシステムの表現法においては、ユーザ機器は、自身のデバイストリガー設定／能力についての情報をＳＧＳＮ／ＭＭＥに明示的に示すことができる。この明示的なシグナリングは、アタッチ手順またはＴＡＵ／ＲＡＵ（トラッキングエリア更新またはルーティングエリア更新）手順時に実行することができる。この明示的なシグナリングは、図１４に示してある（「ＤＴ設定＋関連するＡＰＮ」を参照）。ユーザ機器は、自身のデバイストリガー能力を、電源オン時または他の初期化手順時に有効にされる自身の内部設定に基づいて判定することができる。これに代えて、またはこれに加えて、端末は、自身のデバイストリガーステータスを、デバイストリガーアクティビティ／設定の何らかの変更時に求めることができる。さらに、ユーザ機器は、デバイストリガー要求メッセージの内部ルーティング／ディスパッチングのための特殊機能を有することができる。この機能が利用可能であることは、デバイストリガー設定／能力の情報をＳＧＳＮ／ＭＭＥに伝えるＮＡＳ層に示すことができる。
端末のデバイストリガリング設定に関する情報をサービングネットワークノードが登録するための第６の可能な方法は、デバイストリガー要求が送られるＭＴ−ＳＭＳのヘッダから情報を取り出すことである。特に、トリガー要求メッセージ（ＳＭＳ）は、そのメッセージがデバイストリガーメッセージであることを示すインジケータをヘッダ内に含んでいることができる。この場合、サービングネットワークノードは、ヘッダからこの情報を取り出すことができ、メッセージがデバイストリガーメッセージであるとき、そのメッセージを端末に送信しないことを決定することができる。これに対して、メッセージがデバイストリガーメッセージではないとき（例えば通常のユーザデータを有するメッセージであり、そのメッセージに起因して端末が応答せず、したがってネットワークへのコンテキスト／接続を確立することがないとき）、サービングネットワークノードはメッセージを端末に送信することを決定することができる。なお、サービングネットワークノードによって実行されるこの決定は、ネットワーク輻輳の状態において、シグナリングトラフィックを減らすうえで有利である。３ＧＰＰシステムの表現法においては、デバイストリガー要求メッセージがＭＴ−ＳＭＳにカプセル化される場合、ＳＭＳ（メッセージ）を生成するエンティティ（通常ではＳＭ−ＳＣエンティティ）は、そのＳＭＳがデバイストリガー目的に使用されることをＳＭＳの中で示す。この指示情報は、ＳＧＳＮ／ＭＭＥに可視であるＭＴ−ＳＭＳヘッダの一部とすることができる。ＳＭ−ＳＣエンティティは、ＭＴ−ＳＭＳがデバイストリガー目的であることを認識し、なぜならそのＳＭＳがＴ４インタフェースを通じて受信された、あるいはＭＴＣサーバまたはＭＴＣアプリケーションから受信されたためである。例えば、メッセージ（ＳＭＳ）の発行元のエンティティは、デバイストリガー目的に（好ましくはデバイストリガーのみを目的として）使用される特定のＳＭＳ優先度を指定することができる。別の例として、このようなＳＭＳ優先度を、ＭＴ−ＳＭＳをＳＭ−ＳＣからＧＭＳＣを介してＭＳＣ／ＳＧＳＮ／ＭＭＥに伝えるＭＡＰまたはＤＩＡＭＥＴＥＲあるいは他のプロトコルにおける指示情報の中で指定する。さらに別のオプションとして、ＳＧＳＮ／ＭＭＥが検査してＭＴ−ＳＭＳの目的を判定することができる指示情報を、ショートメッセージ伝送プロトコル（ＳＭ−ＴＰ）の中に指定する。以下では、ＭＭ ＣＣの場合におけるＭＴ−ＳＭＳの処理に関するさらなる情報を示す。
上述したメカニズムの１つまたはいくつかを組み合わせて使用して、サービングネットワークノード（ＳＧＳＮ／ＭＭＥ）においてユーザ機器のデバイストリガー設定／能力を求め、それを格納しておき、輻輳状態において、受信された端末へのメッセージを端末に転送するかを決定する目的に使用することができる。特に、デバイストリガリングメッセージである（可能性がある）ものと判断されたメッセージは端末に送信されず、他のメッセージは端末に送信される。
メッセージを端末に送信するか否かに関する効率的な判断を実行する目的で、トリガリングの後に端末が接続の確立を試みるＡＰＮ、もしくは、そのＡＰＮが輻輳状態にあるか否か、またはその両方に関する情報をサービングネットワークノードが有するならば有利である。
本発明の別の実施形態は、この問題（すなわちターゲットＡＰＮの解決の問題）に対処する。この実施形態と本発明の他の実施形態とを組み合わせることは、特に有利である。例えば、端末のデバイストリガー能力またはデバイストリガー設定の検出と、トリガー時に端末が接続の確立を試みるＡＰＮの輻輳状態（ネットワークが輻輳しているか否か）に関する情報とを合わせることで、サービングネットワークノードが、トリガリングを引き起こすすべてのメッセージを停止させ、デバイス（端末）のトリガリングを必ずしも引き起こさないメッセージを中継することを可能にする、十分な情報が提供される。
本発明の説明の別の部分ですでに述べたように、サービングネットワークノード（ＳＧＳＮ／ＭＭＥ）がターゲットＡＰＮを求めることができないことがある。ターゲットＡＰＮを解決するための上述した解決策は、ＳＧＳＮ／ＭＭＥにおいて外部ＩＤが利用可能であり、かつ外部ＩＤに特殊設定が使用されている場合に、適用することができる。このことは、Ｔ５インタフェースを通じてのデバイストリガリングの場合に部分的に可能である。しかしながら、デバイストリガリングにＭＴ−ＳＭＳが使用されるときには、ＭＴ−ＳＭＳのヘッダの中で外部ＩＤを伝えることはできず、したがって、外部ＩＤはＳＧＳＮ／ＭＭＥから可視ではない。さらには、今後においてもレガシーＭＴ−ＳＭＳがデバイストリガリングに使用されると想定すると、ＳＧＳＮ／ＭＭＥにおける輻輳制御の場合に（特にＳＭ ＣＣの場合に）デバイストリガー要求をユーザ機器に送信するか否かを決定する目的で、ＳＧＳＮ／ＭＭＥがデバイストリガー要求（ＭＴ−ＳＭＳの形、またはＴ５インタフェースを通じての他の一般的なシグナリングフォーマットの形）を処理することのできる解決策を探す必要がある。
輻輳制御（ＣＣ）の場合にデバイストリガー要求メッセージに特殊処理を適用するかを判定するための１つの可能な方法は、ＳＧＳＮ／ＭＭＥが、ユーザ機器の加入ＡＰＮを考慮することである。加入ＡＰＮは、アタッチ手順時にＨＳＳ／ＨＬＲからＳＧＳＮ／ＭＭＥに伝えられる加入情報の一部である。したがって、ＳＧＳＮ／ＭＭＥは、ユーザ機器の加入ＡＰＮをつねに認識している。ユーザ機器が１つのＡＰＮに加入している場合、ＳＧＳＮ／ＭＭＥにおける処理は単純なものとすることができる。ＳＧＳＮ／ＭＭＥは、デバイストリガー要求メッセージを受信すると、そのメッセージを処理して、メッセージを配信するべきユーザ機器を求める。次いで、ＳＧＳＮ／ＭＭＥは、加入ＡＰＮをチェックすることができる。加入ＡＰＮがＭＭ ＣＣまたはＳＭ ＣＣ下にある場合、ＳＧＳＮ／ＭＭＥはメッセージを送信しないことができ、なぜならユーザ機器がネットワークへのＭＭシグナリングまたはＳＭシグナリングを生成するものと想定されるためである。
言い換えれば、サービングネットワークノードは、ホーム加入者サーバから情報を受信し、この情報は、１つまたは複数の外部ネットワークへの端末の加入情報を含んでいる。次いで、サービングネットワークノードは、加入ネットワークの１つまたは複数が輻輳状態にあるか否かを評価することができる。加入ネットワークの１つまたは複数が輻輳状態にあるとき、サービングネットワークノードは、デバイストリガリングメッセージを端末に転送しないことを決定することができる。デバイストリガリングメッセージ以外は、端末に配信することを決定することができる。
この実施形態においては、輻輳制御は、ＳＭ ＣＣまたはモビリティ管理（ＭＭ）ＣＣとすることができる。特にＭＭ ＣＣに対処する理由として、オフラインデバイストリガリング（今後３ＧＰＰにおいて仕様が策定される予定）は、３ＧＰＰネットワークにアタッチされていないデバイス（端末）を対象としてＳＧＳＮ／ＭＭＥに送られるデバイストリガー要求（またはデバイスをトリガーするための類似するメッセージ）を含むことができる。言い換えれば、このデバイストリガー要求メッセージは、ユーザ機器を宛先とし、ネットワークにアタッチするようにユーザ機器に要求するメッセージである。これは、どのユーザ機器がネットワークにアタッチするかを取得した後、対応するシグナリング情報をブロードキャストすることによって実行することができる。このような場合には、ＳＧＳＮ／ＭＭＥがＡＰＮベースのＭＭ ＣＣを適用する場合、ＳＧＳＮ／ＭＭＥはユーザ機器へのデバイストリガー要求メッセージをブロックすることができ、なぜなら、デバイストリガー要求メッセージが受信されることに起因してネットワークへのＮＡＳ ＭＭシグナリングが発生し、このことはＡＰＮベースのＭＭ ＣＣにおいて明らかに望ましくないためである。
上の説明では、ユーザ機器が１つのＡＰＮに加入している場合について検討した。しかしながら、ユーザ機器が複数のＡＰＮに加入しており、ただしＳＭ ＣＣが１つのＡＰＮのみに適用される場合、非特許文献２のセクション６.５９に記載されている従来技術の「ＭＴＣ−ＩＷＦによる過負荷制御」メカニズムを適用しているとき、すべてのデバイストリガー要求がネットワーク（ＭＴＣ−ＩＷＦまたはＳＧＳＮ／ＭＭＥ）によってブロックされる。したがって、輻輳したＡＰＮへのシグナリングを開始するようにユーザ機器をトリガーするデバイストリガー要求メッセージのみをブロックする解決策が好ましい。
この要件を満たすため、本発明の実施形態によると、ＳＧＳＮ／ＭＭＥは、ユーザ機器がデバイストリガー要求メッセージの受信後に接続を有効にする、またはデータを送る先の（１つまたは複数の）ＡＰＮ（簡潔さのため「ＤＴ関連ＡＰＮ」と称する）を認識する。ＳＧＳＮ／ＭＭＥは、この情報を、他の情報（例：加入ＡＰＮ）とともにユーザ機器のコンテキストに格納することができる。言い換えれば、ＳＧＳＮ／ＭＭＥは、加入ＡＰＮと、ＤＴ関連ＡＰＮとを区別することができる。ＤＴ関連ＡＰＮは、加入ＡＰＮのサブセットであり、ユーザ機器は、特にデバイストリガー要求メッセージの受信後、これらのＡＰＮとのデータ接続を使用する。
ＳＧＳＮ／ＭＭＥがＤＴ関連ＡＰＮについての情報を認識するための１つの可能な方法は、ＨＳＳ／ＨＬＲからの加入情報から認識することである。すなわち、ＨＳＳ／ＨＬＲは、加入ＡＰＮについての情報とともに、ＤＴ関連ＡＰＮについての情報を格納しており、それをＳＧＳＮ／ＭＭＥにシグナリングする。
ＳＧＳＮ／ＭＭＥがＤＴ関連ＡＰＮについて認識するための別の可能な方法は、ユーザ機器からの明示的なシグナリングから認識することである。例えば、アタッチ手順またはＴＡＵ／ＲＡＵ手順時、ユーザ機器は（１つまたは複数の）ＤＴ関連ＡＰＮをＳＧＳＮ／ＭＭＥにシグナリングする。ユーザ機器がこの情報を認識できるのは、デバイストリガー要求によってトリガーされたＭＴＣアプリケーションが新しい接続の確立を開始するときに、ユーザ機器はセッション管理（ＳＭ）要求メッセージの中にＡＰＮを挿入することができるためである。したがって、ユーザ機器は、どのＭＴＣアプリケーションがデバイストリガー要求によって有効にされているかと、それらのＭＴＣアプリケーションによってどのＡＰＮが使用されているかの情報を有することができる。ＭＭＥに通知するためにユーザ機器が使用することのできるシグナリング手順の一例として、NAS EMM STATUSメッセージを使用することができる。NAS EMM STATUSメッセージについてのさらなる情報は、非特許文献５のセクション８.２.１４に記載されている。
言い換えれば、サービングネットワークノードは、メッセージを端末に転送するか否かに関する自身の決定を、端末がトリガーされた後に接続しうる外部ネットワークにおける輻輳状態に依存することができる。この方法は、端末が加入している外部ネットワークに基づくため、より正確かつ効率的である。端末がトリガーされた後に接続する外部ネットワークについての情報は、ホーム加入者サーバから、または端末から取得する（取り出す）ことができる。
要約すると、本発明の好ましい実施形態によると、ＳＧＳＮ／ＭＭＥ（サービングネットワークノード）は、ユーザ機器（端末）と、ユーザ機器のデバイストリガー能力／設定と、ＤＴ関連ＡＰＮとの間の関連性についての情報を、維持するべきである。ＳＧＳＮ／ＭＭＥがデバイストリガー要求メッセージを受信し、ＳＧＳＮ／ＭＭＥにおいてＡＰＮベースの輻輳制御が有効にされているとき、ＳＧＳＮ／ＭＭＥはチェックを実行して、ターゲットユーザ機器がデバイストリガーに対して設定されているかと、どれがＤＴ関連ＡＰＮであるかとを認識する。ＳＧＳＮ／ＭＭＥにおいて有効にされているＡＰＮベースの輻輳制御が、ユーザ機器のＤＴ関連ＡＰＮに関連している場合のみ、ＳＧＳＮ／ＭＭＥは、デバイストリガー要求メッセージを拒否／ブロックすることを決定することができる。なお、拒否することを決定するとは、デバイストリガー要求が削除され、そのデバイストリガー要求の送信元ノードに削除について通知され、サービングネットワークノードがデバイストリガー要求を後から送信することを試みないことを意味する。ブロックは、一時的に実行することができ、この場合、デバイストリガー要求メッセージがサービングネットワークノードに格納され、後から、おそらくは輻輳状態が輻輳を示さない時点で、デバイストリガー要求メッセージが送信される。
上述したように、端末がデバイストリガー目的のために１つのＡＰＮに接続できるのみである場合、決定は効率的に実行することができる。以下では、複数のＤＴ関連ＡＰＮの場合、またはＳＧＳＮ／ＭＭＥがＤＴ関連ＡＰＮを認識できない場合について説明する。
上に説明した解決策は、ユーザ機器が１つのＤＴ関連ＡＰＮを有する（かつ複数の加入ＡＰＮを有することができる）ものと想定したときに有利に適用することができる。しかしながら、複数のＤＴ関連ＡＰＮの場合、またはＳＧＳＮ／ＭＭＥがＤＴ関連ＡＰＮについて認識しない場合、サービングネットワークノードがデバイストリガー要求を送信するかブロックするかを判定するための別のメカニズムが有利であり得る。１つのこのようなメカニズムは、格納されているＥＰＳベアラコンテキストまたはＰＤＰコンテキスト（簡潔さのためＰＤＮ／ＰＤＰコンテキストとしてすでに使用されている）に基づいて決定を行うことである。ＳＧＳＮ／ＭＭＥは、デバイストリガー要求（ＳＭ−ＳＣからのＭＴ−ＳＭＳの形、またはＭＴＣ−ＩＷＦからＴ５インタフェースを通じての別の種類のシグナリングの形）を受信したとき、加入ＡＰＮと、ＤＴ関連ＡＰＮ（利用可能である場合）と、格納されているＰＤＮ／ＰＤＰコンテキストとをチェックする。以下の処理を適用することができる。
１．ユーザ機器の加入ＡＰＮまたはＤＴ関連ＡＰＮ（後者はＳＧＳＮ／ＭＭＥにおいて利用可能である場合）のうちの１つのＡＰＮも輻輳していない場合、ＳＧＳＮ／ＭＭＥは、デバイストリガー要求メッセージをユーザ機器に送信することを結論し、なぜなら、端末からネットワークへの、およびネットワークから端末への、後から発生しうるＮＡＳシグナリング（ＥＭＭ要求またはＥＳＭ要求）が、ネットワークにおいて有効にされているＡＰＮベースの輻輳制御に影響しないためである。
２．加入ＡＰＮまたはＤＴ関連ＡＰＮ（後者はＳＧＳＮ／ＭＭＥにおいて利用可能である場合）のうちの１つのＡＰＮが輻輳しており、輻輳している（ＤＴ関連）ＡＰＮに対するＰＤＮ／ＰＤＰコンテキストが存在しない場合、ＳＧＳＮ／ＭＭＥは、ユーザ機器がＭＴＣサーバ／アプリケーションとのデータ接続を確立する目的でおそらくネットワークにＥＳＭ要求を送るものと結論することができる。ＳＧＳＮ／ＭＭＥは、この結論に基づいて、デバイストリガー要求メッセージを拒否することができる。さらに、複数の加入ＡＰＮまたは複数のＤＴ関連ＡＰＮが存在し、ＳＧＳＮ／ＭＭＥが加入ＡＰＮまたはＤＴ関連ＡＰＮの一部についてＰＤＮ／ＰＤＰコンテキストを維持している場合にも、デバイストリガー要求を拒否することができ、なぜなら、ＳＧＳＮ／ＭＭＥは、どのＡＰＮにデバイストリガー要求が送られるかについて１００％の確信がなく、ユーザ機器が輻輳したＡＰＮに（Ｅ）ＳＭ要求を送る可能性が依然として存在するためである。ＳＧＳＮ／ＭＭＥは、ＭＴＣ−ＩＷＦエンティティおよびさらにはＭＴＣサーバに返されるデバイストリガー配信報告の中に、拒否／失敗の理由に加えて、ＭＴＣサーバ／アプリケーションがそのユーザ機器へのデバイストリガー要求メッセージの再送信または送信を試みるべきではない時間を含めることができる。したがって、サービングネットワークノードは、トリガー要求を端末に配信しないことを決定したとき、失敗した配信の理由と、サーバ（トリガリングサーバまたはデバイストリガー要求の発信元）がデバイストリガーメッセージを端末に送信または再送信するべきではない時間期間（場合によってはオプション）とを示す報告メッセージを、サーバにさらに送信することができる。本発明の別の態様によると、トリガリングサーバを、受信された報告メッセージと、受信された報告メッセージの対象の端末とに基づいて、輻輳した外部ネットワークを求めるように構成することができる。したがって、トリガリングサーバは、同じ外部ネットワークに加入している他の端末に、類似する手段（すなわちトリガー要求の送信の抑制）を適用することを決定することができる。言い換えれば、オプションとして、ＭＴＣサーバ／アプリケーションは、このモバイルネットワークに登録またはアタッチされている他のユーザ機器に、さらなるデバイストリガー要求メッセージを送ることの抑制を適用することができる。
３．加入ＡＰＮまたはＤＴ関連ＡＰＮ（後者はＳＧＳＮ／ＭＭＥにおいて利用可能である場合）のうちの１つのＡＰＮが輻輳しており、その加入ＡＰＮまたはＤＴ関連ＡＰＮに対するＰＤＮ／ＰＤＰコンテキストが存在する場合、ＳＧＳＮ／ＭＭＥは、ユーザ機器がデバイストリガー要求メッセージの受信後にネットワークにＥＳＭ要求を送らないものと結論することができる。ＳＧＳＮ／ＭＭＥは、この結論に基づいて、デバイストリガー要求メッセージをユーザ機器に送ることを決定することができる。さらに正確な決定を行う目的で、ＳＧＳＮ／ＭＭＥは、以下についての情報をさらに考慮することができる。
３．ａ） 輻輳したＡＰＮに対して許可されるＰＤＮタイプ。通常、ユーザ機器は、新しいＰＤＮ接続（すなわちデフォルトのベアラ）を確立するときにＰＤＮタイプを要求する。ＰＤＮタイプは接続タイプであり、例えば、ＩＰｖ４もしくはＩＰｖ６またはその両方とすることができ、要求されたＰＤＮ接続に対してユーザ機器に割り当てるＩＰアドレスのタイプをネットワークに示す。
３．ｂ） 輻輳したＡＰＮに対して許可されるＥＰＳベアラの最大数。この情報は、例えば、加入情報の一部とすることができ、加入情報リポジトリ（ＨＳＳ／ＨＬＲ）から取得することができる。
例えば、ユーザ機器に許可される、ＡＰＮ（たまたま現在輻輳している）へのＥＰＳベアラが１つのみであることをユーザ機器の加入情報が示しており、ＳＧＳＮ／ＭＭＥがそのＡＰＮに対するＰＤＮ／ＰＤＰ（すなわちベアラ）コンテキストをすでに格納している場合、ＳＧＳＮ／ＭＭＥは、ユーザ機器がそのＡＰＮに対して新しいＥＰＳベアラまたはＰＤＰコンテキストを確立しない（すなわちユーザ機器は（Ｅ）ＳＭ要求メッセージを送らない）ものと結論することができる。したがって、ＳＧＳＮ／ＭＭＥは、デバイストリガー要求メッセージを送信することができる。
上記における「２．」は、「保守的な」方法として特徴付けることができ、なぜなら、ＳＧＳＮ／ＭＭＥは保守的に動作し、たとえユーザ機器がデバイストリガー要求メッセージの受信後に（Ｅ）ＳＭ要求を送らない可能性があっても、デバイストリガー要求を拒否またはブロックするためである。これに対して、上記の「３．」に説明したケースは、「非保守的な」方法と表現することができ、なぜなら、ＳＧＳＮ／ＭＭＥは、たとえユーザ機器がデバイストリガー要求メッセージの受信後に（Ｅ）ＳＭ要求を送る可能性があっても、デバイストリガー要求を拒否しないためである。
図１４は、対応するメッセージ交換の例を示している。図中の「非保守的な」方法は、ＳＧＳＮ／ＭＭＥからユーザ機器にデバイストリガー要求をシグナリングするステップと、ユーザ機器において処理するステップと、場合によってはユーザ機器からＳＧＳＮ／ＭＭＥにシグナリングするステップと、ＳＧＳＮ／ＭＭＥからＭＴＣ−ＩＷＦにシグナリングするステップとを含んでいる。
上に説明した「非保守的な」方法における問題は、ＳＧＳＮ／ＭＭＥがデバイストリガー要求メッセージをユーザ機器に送信し、ユーザ機器が新しいベアラを確立する、または既存のベアラを修正する必要があるときに起こりうる。この場合、ユーザ機器は、ネットワーク（ＳＧＳＮ／ＭＭＥ）と、場合によっては輻輳したＡＰＮとにＥＳＭ要求を送り、その場合、ユーザ機器からの（Ｅ）ＳＭ要求は拒否される。さらに、この問題は、ＳＧＳＮ／ＭＭＥに複数のＤＴ関連ＡＰＮが存在するが、そのうちの１つのみが現時点で輻輳している場合にも起こりうる。ＳＧＳＮ／ＭＭＥが、ＤＴ関連ＡＰＮのいくつかに対してＰＤＮ／ＰＤＰコンテキストを格納している場合、新しいデータ接続（ベアラ）が確立される可能性が低いため、ＳＧＳＮ／ＭＭＥは、デバイストリガー要求メッセージを送信することを決定することができる。しかしながら、ユーザ機器は、新しい接続を必要とする場合、ＥＳＭ要求メッセージを送る。このような場合、ＳＧＳＮ／ＭＭＥは、そのＥＳＭ要求メッセージを拒否する。
輻輳したＡＰＮに対するＥＳＭ要求メッセージを送ることを回避する目的で、デバイストリガー要求を送信するためのＮＡＳシグナリング手順時に、現時点で輻輳しているＡＰＮについて（さらにオプションとしてＳＭ−ＢＯタイマーについて）ＳＧＳＮ／ＭＭＥがユーザ機器に通知することが有利である。ＳＧＳＮ／ＭＭＥは、現時点で輻輳しているＡＰＮがユーザ機器の加入ＡＰＮの１つである場合にのみ、その輻輳しているＡＰＮを通知する。このことは、図１４においては、デバイストリガー要求メッセージを送信するためのＳＧＳＮ／ＭＭＥからユーザ機器へのシグナリングによって示してある。サービングネットワークノードから端末へのデバイストリガー要求配信メッセージにおけるカッコ内の太字は、輻輳したＡＰＮ（「輻輳制御下のＡＰＮ」）および場合によってはＳＭ−ＢＯタイマーが含まれることを示している。さらに、図１４は、ユーザ機器がＢＯタイマーを含むＥＳＭ拒否をＳＧＳＮ／ＭＭＥから受信した場合と同様に、ユーザ機器が、受信したこの情報（輻輳制御下のＡＰＮおよび場合によってはＳＭ−ＢＯタイマー）を格納し、アップリンク（ＵＬ）ＥＳＭ要求メッセージの監視を有効にすることを示している。例えば、ＳＧＳＮ／ＭＭＥは、輻輳したＡＰＮおよびＳＭ−ＢＯタイマーについて、何らかの既存のＮＡＳ手順、例えばEMM INFORMATIONメッセージ（ＭＭＥからユーザ機器への一方向）またはEMM STATUSメッセージを使用して、ユーザ機器に通知することができる。さらに、輻輳したＡＰＮに対するＥＰＳベアラコンテキストが存在する場合、ＳＧＳＮ／ＭＭＥは、ESM NOTIFICATIONメッセージを使用することができる。プロトコルの仕様におけるこれらのメッセージには、新規の情報要素またはパラメータを指定する必要がありうる。これらのメッセージのフォーマットについてのさらなる情報は、非特許文献６（３ＧＰＰのウェブサイトから自由に入手可能）に記載されている。しかしながら、本発明は、ＵＭＴＳ／ＬＴＥに存在するメッセージを再利用することに制限されない。ＳＧＳＮ／ＭＭＥとユーザ機器との間の新規の手順を指定することができる。
なお、この実施形態は、（データ）接続を確立するための端末の要求を拒否した後にＳＭ−ＢＯタイマーを送信することに関する利点を有する。特に、この実施形態では、端末は接続の確立を試みず、したがって、輻輳したネットワークへのシグナリングメッセージの量が減少する。サービングネットワークノードは、輻輳した外部ネットワークについての情報を端末に送信する。特に、サービングネットワークノードは、端末に関連するネットワーク（すなわち端末が接続の確立を試みうるネットワーク）についての情報を送信する。この情報は、バックオフタイマーを含んでいることもできる。端末への情報の送信は、端末に（デバイストリガリング）メッセージを送信するとき、端末が輻輳したネットワークとの接続の確立を試みうる／試みると判断された後に、実行することができる。
ＳＭ−ＢＯタイマーが作動している間に、ユーザ機器のアプリケーション／サービス層が、格納されている輻輳したＡＰＮとの新しい接続の確立を要求するときには、ユーザ機器はＥＳＭ要求メッセージを送らない。ユーザ機器は、要求される新しいデータ接続（ベアラまたはＰＤＰコンテキスト）を確立できないことを、ＮＡＳ手順を使用してＳＧＳＮ／ＭＭＥに通知することができる。例えば、ユーザ機器は、ＮＡＳ ＥＭＭ ＳＴＡＴＵＳメッセージ（例えば非特許文献５のセクション５.７に定義されている）を使用することができる。ＮＡＳ ＥＭＭ ＳＴＡＴＵＳメッセージにおいて、ユーザ機器は、輻輳したＡＰＮについてと、オプションとして残りのＳＭ−ＢＯタイマーについてと、デバイストリガー要求メッセージＩＤとについて、ＳＧＳＮ／ＭＭＥに通知することができる。デバイストリガー要求メッセージＩＤは、ＮＡＳ ＥＭＭメッセージに含まれる情報とデバイストリガー要求メッセージとの間の関係を確立する目的で、ＳＧＳＮ／ＭＭＥにおいて必要となることがある。このようにすることで、ＳＧＳＮ／ＭＭＥは、デバイストリガー要求メッセージが正常に配信されたが、ＡＰＮの輻輳に起因してユーザ機器がデータ接続またはＩＰベアラを確立できないため、データ接続またはＭＴＣアプリケーションの応答が遅延しうることを示すデバイストリガー配信報告を生成して、ＭＴＣ−ＩＷＦに送信することができる。
「非保守的な」方法は、図６のオプション１（「オプション１」）において説明した解決策に似ているように見える。異なる点として、図６のオプション１では、デバイストリガーの配信時に、輻輳したＡＰＮについてユーザ機器に通知されず、ネットワークにＳＭ ＣＣが存在することがユーザ機器に通知される。したがって、ユーザ機器が（Ｅ）ＳＭ要求メッセージをＳＧＳＮ／ＭＭＥに送ることがあり、ＳＧＳＮ／ＭＭＥはこのメッセージを拒否する。図６のオプション１と図１４の解決策を組み合わせることが可能である。例えば、図１４の上側部分（すなわち、ＳＧＳＮ／ＭＭＥにおいてターゲットＡＰＮを求める処理）を適用することができ、ＳＧＳＮ／ＭＭＥが「非保守的な」方法を適用することを決定した場合（ただし、デバイストリガー要求メッセージの送信時に輻輳したＡＰＮを示していない）、ユーザ機器は、図６のオプション１に示したように、輻輳したＡＰＮへの（Ｅ）ＳＭ要求を開始しうる。この場合、ＳＧＳＮ／ＭＭＥは、輻輳したＡＰＮへの（Ｅ）ＳＭ要求を拒否し、ＭＴＣ−ＩＷＦへのデバイストリガー配信報告を生成し、この報告がＭＴＣサーバ／アプリケーションに転送される。なお、サービングネットワークノードは、上述した方法のどちらを適用するか、例えば、「保守的な」方法（図１４においてオプションＡとして示してある）を適用するか、「非保守的な」方法（図１４においてオプションＢとして示してある）を適用するかを決定するための手段を有することができる。しかしながら、本発明はこれに制限されず、一般的には、これらの方法のうちの一方のみをサービングネットワークノードにおいて適用可能とする／設定することができる。
図１４に示した１つのさらなる細部として、デバイストリガー要求をユーザ機器に送信してから、デバイストリガー配信報告をＭＴＣ−ＩＷＦに送るまでの間の遅延が、ＳＧＳＮ／ＭＭＥにおいて発生する。図１４および図６のいずれも、デバイストリガー配信報告はＭＴＣ−ＩＷＦに送られることを示しているが、デバイストリガリングにＭＴ−ＳＭＳが使用される場合、デバイストリガー配信報告がＳＭＳコアネットワークエンティティ（例：ＳＭ−ＳＣ）に送られることも可能である。図１４に示したように、ＳＧＳＮ／ＭＭＥにおいて発生する遅延は、ユーザ機器が無線リンクを通じてパケットを送信／受信しないときにＣＯＮＮＥＣＴＥＤ（接続）状態からＩＤＬＥ（アイドル）状態への移行を有効にする目的で基地局装置において使用されるタイマーと同じ値または近い値を有することができる。このとき、ＳＧＳＮ／ＭＭＥは遅延（すなわちタイマー）を有効にする必要はなく、ＩＤＬＥ（アイドル）モードへの移行のためのＳ１−ＡＰ要求を基地局装置が送るまで待機するものと想定することができる。これも可能なオプションである。しかしながら、ユーザ機器が別の有効な接続を有し、長時間にわたりＡＣＴＩＶＥ（アクティブ）／ＣＯＮＮＥＣＴＥＤ（接続）状態にある場合、基地局装置はＩＤＬＥ（アイドル）モードへの移行のためにＳＧＳＮ／ＭＭＥをトリガーしない。したがって、ＳＧＳＮ／ＭＭＥが自身の遅延タイマー（基地局装置におけるインアクティビティタイマー（inactivity timer）に近い値を有することができる）を有効にすることが有利である。
図６および図１４の両方に関連する１つのさらなる態様を考慮することができる。ＭＴＣサービス層プロトコル（すなわちユーザ機器の観点からは、これはＮＡＳ層の上のアプリケーション層であり、３ＧＰＰによって標準化されたプロトコルである）の実装によっては、ユーザ機器のアプリケーションが、デバイストリガー要求メッセージを受信したことをＭＴＣサーバまたはＭＴＣアプリケーションに肯定応答する必要がある。これは、要求＜−＞肯定応答交換を有する通常のプロトコル設計である。このような交換が特に要求されるのは、デバイストリガー要求メッセージによって、ユーザ機器からの即座のデータ報告ではなく何らかの測定がトリガーされるときであり、なぜなら、ＭＴＣサーバは、ユーザ機器がデータ（例：測定値）の収集を開始したことを確認したいためである。デバイストリガー要求を受信したことの肯定応答（あるいは「受信確認」と称することもができる）は、データパケットとしてユーザプレーンを介して、またはデバイストリガー要求メッセージ配信の場合と同じプロトコルを使用して（例：ＳＭＳまたはＴ５プロトコルを通じて）制御プレーンを介して、ＭＴＣサーバまたはＭＴＣアプリケーションに送り返すことができる。デバイストリガー要求の受信の確認は、例えばＳＧＳＮ／ＭＭＥからＭＴＣ−ＩＷＦに送り返されてＭＴＣサーバに転送されるデバイストリガー配信報告とは独立していることができる。したがって、トリガリングサーバを発行元とするデバイストリガー要求を受信した端末は、要求受信の確認メッセージを（例えば複数のネットワークノードもしくは外部ネットワークまたはその両方を通じて）トリガリングサーバに送信することによって、要求の受信を確認することができる。
図１５は、デバイストリガー要求の受信確認の制御プレーン送信およびユーザプレーン送信の両方の場合の可能な仕様を記述したものであり、以下ではこれについて説明する。
・ この図の右側は、２つの異なるＭＴＣアプリケーション（「ＭＴＣアプリケーション１」および「ＭＴＣアプリケーション２」）が、対応するＭＴＣアプリケーションとの通信を開始するようにＭＴＣサーバからユーザ機器をトリガーすることを要求する例を示している。ＭＴＣサーバは、デバイストリガー要求メッセージを生成し、それをＴｓｐインタフェースを通じてＭＴＣ−ＩＷＦに送る。ＭＴＣ−ＩＷＦは、Ｔ４インタフェースまたはＴ５インタフェースを通じての配信を選択し、それに応じてデバイストリガーメッセージを転送する。デバイストリガーメッセージはサービングネットワークノード（ＳＧＳＮ／ＭＭＥ）に到着し、ＳＧＳＮ／ＭＭＥはメッセージをユーザ機器におけるＮＡＳ層に転送する。
・ デバイストリガー要求メッセージは、ＮＡＳ層における処理の後、おそらくは一種のディスパッチ機能によって処理される。デバイストリガー要求がＭＴ−ＳＭＳにカプセル化されている場合、ＭＴ−ＳＭＳのペイロード（デバイストリガー情報を含んでいる）が、（例えばＳＭＳディスパッチ機能によって）ＭＴＣ固有機能（デバイストリガーディスパッチ機能とすることができる）に転送される、またはＭＴＣサービス層内部ルーティング機能に直接転送される。言い換えれば、ＮＡＳ層とＭＴＣ関連機能との間に、ＳＭＳに固有な機能が存在しうる（図１５には示していない）。なお、ユーザ機器の中のいくつかの四角い囲みは、ユーザ機器における機能または層の例示的な構造を示しているが、正確な細部は実装に依存することに留意されたい。デバイストリガー要求がＴ５インタフェースを通じて伝えられ、フォーマットがＳＭＳとは異なる場合、ユーザ機器におけるＮＡＳ層は、デバイストリガー要求をデバイストリガーディスパッチ機能またはＭＴＣに固有なサービス層機能に転送し、これらの機能は、正しいアプリケーションを識別し、さらにメッセージを転送／ルーティングするべきである。（ＭＴＣ）ＩＰベアラサービスとＭＴＣアプリケーション１との間のデータ接続（またはベアラ）は、実線によって示してあり、このことは、これらの接続／ベアラのＰＤＮ／ＰＤＰコンテキストがユーザ機器およびＳＧＳＮ／ＭＭＥに存在することを意味する。これに対して、（ＭＴＣ）ＩＰベアラサービスとＭＴＣアプリケーション２との間のデータ接続／ベアラは、破線によって示してあり、このことは、これらの接続／ベアラのＰＤＮ／ＰＤＰコンテキストが存在しないことを意味する。
・ デバイストリガー要求の受信確認を、制御プレーンを通じてＭＴＣサーバに送ることができる。これは、以下のいずれかとして実行することができる。
１． ＭＯ−ＳＭＳとして。ＭＯ−ＳＭＳは、ＭＴＣアプリケーションまたはＭＴＣサービス層ルーティング機能において生成され、ユーザ機器のＳＭＳプロトコルスタックに転送され、その後にユーザ機器におけるＮＡＳ層に転送される。
２． 他のシグナリングプロトコルメッセージとして。このメッセージは、ユーザ機器におけるＮＡＳ層に転送され、ネットワークに送信される。
ユーザ機器においてＡＰＮベースのＳＭ輻輳制御が有効にされている場合（すなわち図９に示したようにユーザ機器が作動中のＳＭ−ＢＯタイマーを有する場合）、ユーザ機器は、有効にされているＳＭ−ＢＯタイマーが、データ接続（ベアラ１またはベアラ２）を確立しなければならない先のＡＰＮに関連しているかを判定する目的で、ＮＡＳ層において特殊なチェックを実行することができる。関連している場合、ユーザ機器（ＮＡＳ層またはＭＴＣアプリケーション層またはＭＴＣサービス層）は、対応する情報（すなわち、有効にされている輻輳制御のため、アップリンクデータをただちに配信することができない）を、ＭＴＣサーバへのデバイストリガー要求の受信確認の中に含める。このような方法においては、デバイストリガー要求の受信確認は、デバイストリガー要求メッセージが正常に受理されたが、有効にされているＳＭ−ＢＯタイマーのためデータ接続を確立できないという情報をＭＴＣサーバに伝える。これは、図９のオプションＢに似ている。
・ デバイストリガー要求の受信確認は、ユーザプレーンを通じてＭＴＣサーバに送り返すことができる。（図１５においてベアラ１について示したように）ＰＤＮ／ＰＤＰコンテキストがすでに確立されている場合、ユーザ機器は、デバイストリガー要求の受信確認を送信することができる。しかしながら、（ベアラ２について示したように）ＰＤＮ／ＰＤＰコンテキストが確立されておらず、ベアラ２のＡＰＮが輻輳制御下にある場合、ユーザ機器は、デバイストリガー要求の受信確認メッセージを送信することができない。
一般的には、ＭＴＣサーバまたはＭＴＣアプリケーションがデバイストリガー要求の受信確認を受信することを予測していたが、そのような確認が受信されない場合、ＭＴＣサーバまたはＭＴＣアプリケーションは、デバイストリガー要求メッセージを再送信する。このような場合、ＭＴＣアプリケーション、ＭＴＣサーバ、ＭＴＣ−ＩＷＦ、ＳＧＳＮ／ＭＭＥのうちの１つのエンティティは、この状況を判定して新しいデバイストリガー要求メッセージをユーザ機器に再送信しないようにするための機能を実装しているべきである。例えば、このような機能としては、本発明における実施形態の１つにおいてすでに説明した、ユーザ機器におけるＡＰＮベースの輻輳検出の解決策が挙げられる。別の可能な解決策としては、ユーザ機器がデータまたはデバイストリガー要求の受信確認を送信するためのＩＰベアラを確立できないものと判定した後、ＮＡＳ接続が依然として確立されているかまたはアクティブである場合、ユーザ機器はＡＰＮベースのＳＭ ＣＣについてＳＧＳＮ／ＭＭＥに通知することができる。類似する方法は図１４においてすでに説明してあり、この場合、ユーザ機器はNAS EMMステータスメッセージを使用して、輻輳状況についてＳＧＳＮ／ＭＭＥに通知する。
これに代えて、デバイストリガー要求メッセージが再送信される問題を解決するため、ネットワーク（例：ＳＧＳＮ／ＭＭＥ）は、ＭＴＣサーバによってデバイストリガー要求が再送信されたときに、ユーザ機器において作動しているＳＭ−ＢＯタイマーを終了させて、デバイストリガー要求メッセージをユーザ機器に送信することを決定することができる。ＳＧＳＮ／ＭＭＥは、ユーザ機器におけるＳＭ−ＢＯタイマーを、非特許文献４のセクション４.３.７.４.２.２に記載されているように終了させることができる。すなわち、ＳＧＳＮ／ＭＭＥは、ユーザ機器に向かう（Ｅ）ＳＭ手順を開始する。ユーザ機器は、ＳＧＳＮ／ＭＭＥからの（Ｅ）ＳＭ要求メッセージを受信すると、ＳＭ−ＢＯタイマーを終了させる。
複数のＤＴ関連ＡＰＮが存在する場合、ユーザ機器がデバイストリガー要求メッセージを受信したときに正確にどのＡＰＮがトリガーされるかをＭＭＥが検出できないとき、「非保守的な」方法が有利である。
本発明の別の実施形態によると、ＭＴＣ−ＩＷＦまたはＳＧＳＮ／ＭＭＥは、デバイストリガー要求の送信元に基づいてＤＴ関連ＡＰＮを解決する。
上の説明においては、ＳＧＳＮ／ＭＭＥがターゲットＡＰＮをどのように解決するかに関して、いくつかの方法を提供してきた。これらの方法は、本質的には、ＳＧＳＮ／ＭＭＥにおける内部処理に基づく（これは特に加入ＡＰＮまたはＤＴ関連ＡＰＮが１つである場合にあてはまる）、または、ユーザ機器から受信される明示的な指示情報に基づいている。以下の実施形態においては、デバイストリガー要求メッセージの送信元に基づくさらに別の方法が提供される。この方法は他の方法とは異なり、なぜならこの方法では、ターゲットＡＰＮの解決を、必ずしもサービングネットワークノード（ＭＭＥ／ＳＧＳＮ）ではなく、ＭＴＣ−ＩＷＦにおいて実行する、またはＭＴＣ−ＩＷＦの支援を受けて実行することができるためである。
この方法における１つの主たる想定として、１つのＭＴＣサーバまたはＭＴＣアプリケーションから発行されるデバイストリガー要求メッセージの結果として、おそらくはユーザ機器から１つの特定のＡＰＮへのデータ接続が確立される。したがって、この方法は、ＭＴＣ−ＩＷＦまたはＳＧＳＮ／ＭＭＥが、デバイストリガー要求メッセージの送信元（発行元ノード）または送り手に基づいてターゲットＡＰＮを解決することのできる解決策を提供する。一般には、Ｔｓｐインタフェースを通じてのデバイストリガー要求メッセージには、送信元エンティティまたは送信側エンティティのＩＤを示す情報要素またはパラメータが含まれるものと理解される。言い換えれば、Ｔｓｐインタフェースを通じてのデバイストリガー要求メッセージは、一種の「ＭＴＣサーバＩＤ」パラメータを含む。したがって、この「ＭＴＣサーバＩＤ」は、少なくともＭＴＣ−ＩＷＦにおいて認識される。提案として、「ＭＴＣサーバＩＤ」をさらにＴ４インタフェースを通じて伝え、したがってＳＭ−ＳＣエンティティが「ＭＴＣサーバＩＤ」を格納することができる。「ＭＴＣサーバＩＤ」をＳＭ−ＳＣおよびＭＴＣ−ＩＷＦに格納することは、さまざまな目的に使用することができる。例えば、１つの目的は課金（課金が送り手ごと、すなわちＭＴＣサーバごとに行われるとき）であり、別の目的は、デバイストリガー配信報告を生成して送り返すことである。
この実施形態では、「ＭＴＣサーバＩＤ」とターゲットＡＰＮとの間の関係を、３ＧＰＰネットワークエンティティのいずれかにおいて維持することを提案する。いくつかのオプションが可能である。
・ 「ＭＴＣサーバＩＤ」とターゲットＡＰＮとの間の関係を、加入情報リポジトリ（ＨＳＳまたはＨＬＲ）において維持する。ＭＴＣ−ＩＷＦは、デバイストリガー要求メッセージを受信すると、ＨＳＳ／ＨＬＲに連絡して、ユーザ機器の内部ＩＤと、ユーザ機器が登録されているＭＭＥまたはＳＧＳＮを解決する。新しい提案として、ＨＳＳ／ＨＬＲは、（ユーザ機器のネットワーク内部ＩＤに加えて）関連するターゲットＡＰＮをＭＴＣ−ＩＷＦに報告することができる。
・ 「ＭＴＣサーバＩＤ」とターゲットＡＰＮとの間の関係を、ＭＴＣ−ＩＷＦにおいて維持する。この目的のため、ＭＴＣ−ＩＷＦをこの情報を使用できるように構成するべきである。
・ 「ＭＴＣサーバＩＤ」とターゲットＡＰＮとの間の関係を、ＳＧＳＮ／ＭＭＥにおいて作成する、またはＳＧＳＮ／ＭＭＥによって維持する。しかしながら、ＳＧＳＮ／ＭＭＥはデバイストリガー要求の送信元を認識しない。したがって、「ＭＴＣサーバＩＤ」をＭＴＣ−ＩＷＦからＳＧＳＮ／ＭＭＥに伝えるため、Ｔ５インタフェースプロトコルの拡張が必要である。克服するべき１つの問題は、デバイストリガリングにＭＴ−ＳＭＳが使用されているときであり、なぜならその場合、「ＭＴＣサーバＩＤ」をＳＭＳヘッダの中でＳＧＳＮ／ＭＭＥに伝える必要があるが、ＳＭＳヘッダのサイズは限られているためである。したがって、このオプションは、Ｔ５インタフェースを通じてのデバイストリガリングの場合に容易に適用することができる。ＳＧＳＮ／ＭＭＥは、「ＭＴＣサーバＩＤ」を取得すると、ＨＳＳ／ＨＬＲに問い合わせてターゲットＡＰＮを解決することができ、または、ＳＧＳＮ／ＭＭＥは、「ＭＴＣサーバＩＤ」とターゲットＡＰＮとの間の関係について自身のデータベースを維持する。なお、これは上記の最初のオプションに関連しており（すなわちＨＳＳ／ＨＬＲが「ＭＴＣサーバＩＤ」とターゲットＡＰＮとの間の関係を格納している）、ただしＭＴＣ−ＩＷＦではなくＳＧＳＮ／ＭＭＥが「ＭＴＣサーバＩＤ」を使用してＨＳＳ／ＨＬＲに問い合わせる。このオプションの１つの利点として、ＳＧＳＮ／ＭＭＥは、ＡＰＮベースの輻輳制御が有効にされているかと、そのＡＰＮがターゲットユーザ機器の加入ＡＰＮの１つであるかの問い合わせを実行するのみでよい。
ＭＴＣ−ＩＷＦは、デバイストリガー要求メッセージのターゲットＡＰＮを解決した後、そのターゲットＡＰＮを、追加のパラメータとして、例えばＴ５インタフェースを通じてＳＧＳＮ／ＭＭＥに報告することができる。ＳＧＳＮ／ＭＭＥにおいては、上述したようにデバイストリガー要求メッセージおよびターゲットＡＰＮを受信した後、別の実施形態において説明したようにデバイストリガー要求を処理する。例えば、ＳＧＳＮ／ＭＭＥは、デバイストリガー要求メッセージを送信するか拒否するかを、ネットワークにおけるＡＰＮ輻輳状況と、オプションとして、そのＡＰＮへのＰＤＮ／ＰＤＰコンテキストが利用可能であるかに基づいて、決定する。
別の可能な方法として、ＳＧＳＮ／ＭＭＥが、有効にされているＡＰＮベースの輻輳制御をＭＴＣ−ＩＷＦに報告する。ＭＴＣ−ＩＷＦは、ＭＭＥに登録されているユーザ機器を対象とするデバイストリガー要求メッセージにフィルタリングを適用するかまたは拒否し、この場合、ターゲットＡＰＮは、ＡＰＮベースの輻輳制御下にあるものとＭＭＥから報告されている。言い換えれば、ＭＴＣ−ＩＷＦは、ターゲットＡＰＮが輻輳制御下にあることを認識している場合、デバイストリガー要求メッセージをＳＧＳＮ／ＭＭＥに転送しない。
要約すると、輻輳状態にある外部ネットワークの識別情報を求める目的で、トリガリングサーバの識別情報（ＭＴＣサーバ）と、端末がトリガーされたときにデータを報告するために接続するターゲット外部ネットワーク（ＡＰＮ）との間の関連性を、特定のネットワークエンティティが維持する。この関連性により、エンティティによって外部ネットワークを求めることが可能になる。これに代えて、このエンティティは、関連性、または検出された輻輳した外部ネットワークを、別のエンティティに送信することができる。具体的には、ネットワークエンティティは、ＭＴＣ−ＩＷＦ、ＳＧＳＮ／ＭＭＥ（サービングネットワークノード）、またはＳＭ−ＳＣとすることができる。
なお、本発明は、セッション管理輻輳制御に制限されず、モビリティ管理輻輳制御（ＭＭ ＣＣ）に適用することもできる。
本発明の大部分では、主として考慮されるシナリオとして、ＡＰＮベースのＳＭ ＣＣについて説明してある。しかしながら、特に、デバイストリガー要求メッセージがＭＴ−ＳＭＳにカプセル化される場合、ＭＴ−ＳＭＳを送信するか拒否するかのＳＧＳＮ／ＭＭＥにおける決定は、ＡＰＮ ＳＭ ＣＣに依存するのみならず、ＡＰＮベースのＭＭ ＣＣおよび一般的なＭＭ ＣＣにも依存して行うことができる。ＭＴ−ＳＭＳの送信とＭＭ ＣＣとの間のこの相互関係の理由は、ユーザ機器の挙動であり、すなわち移動体着（ＭＴ）サービスについてページングされたとき、ユーザ機器はＭＭ ＢＯタイマーを終了させる必要がある。通常、３Ｇ（すなわちＵＭＴＳ）においては、ＭＴ−ＳＭＳが送信されるとき、ユーザ機器は、シグナリング接続の確立を示す特殊な理由を伴ってページングされる。しかしながら、ＬＴＥの場合、またはＰＳのみの加入の場合、ＭＴ−ＳＭＳを送信する目的で移動体着（ＭＴ）ページング理由を伴ってユーザ機器がページングされるかは不確定である。さらに、ユーザ機器が、作動中のＭＭ ＢＯタイマーを停止させる理由としてページングを処理するかも不確定である。いずれにしても、ＳＧＳＮ／ＭＭＥはユーザ機器をページングすることをまったく望まないことがあり、なぜなら、たとえユーザ機器とＳＧＳＮ／ＭＭＥの間のシグナリング接続の確立であっても、望ましくないＭＭシグナリングにつながるためである。
ＡＰＮベースのＭＭ ＣＣの場合、ユーザ機器はＳＧＳＮ／ＭＭＥに登録されず、トリガリングの種類はいわゆるオフラインデバイストリガリングである。オフラインデバイストリガリングの場合、ＳＧＳＮ／ＭＭＥは、登録されていないユーザ機器に到達するようにデバイストリガー要求メッセージをブロードキャストすることができる。問題点として、多くのユーザ機器がデバイストリガー要求メッセージの受信後にネットワークへのアタッチを試みることがあり、これらのユーザ機器に対してＡＰＮベースのＭＭ ＣＣが有効にされている場合、多くのアタッチ試行は望ましくなく、なぜならＭＭ ＣＣ状況が悪化するためである。デバイストリガー要求メッセージのブロードキャスト／送信を回避する目的で、ＳＧＳＮ／ＭＭＥは、デバイストリガー要求メッセージを送信する前に、デバイストリガーメッセージを処理して、ネットワークにおいてＡＰＮベースのＭＭ ＣＣが有効にされているかを判定することができる。ＳＧＳＮ／ＭＭＥはターゲットユーザ機器のＮＡＳ ＭＭコンテキストを有さないことがあるため（なぜならターゲットユーザ機器が登録されていない、またはネットワークにアタッチされていない）、この処理は複雑であることがある。ＳＧＳＮ／ＭＭＥがＮＡＳ ＭＭコンテキストを有する場合、処理は以下に説明するとおりである。
以下では、一般的なＭＭ ＣＣに焦点を当てる。この場合、一般的なＭＭ ＣＣ下にあるユーザ機器は、ＳＧＳＮ／ＭＭＥにおいてＮＡＳ ＭＭコンテキストを有することができる。この場合の一般的な解決策として、ＳＧＳＮ／ＭＭＥは、デバイストリガー要求メッセージの受信後、ターゲットユーザ機器がＭＭ ＣＣ下にあるか（すなわちＳＧＳＮ／ＭＭＥがそのユーザ機器のＭＭ ＢＯタイマーを格納しているか）のチェックを実行する。ＳＧＳＮ／ＭＭＥは、たとえそのユーザ機器のＭＭ ＢＯタイマーを格納していない場合にも、ユーザ機器またはユーザ機器のグループの優先度、または何らかの他のパラメータが、現在進行中のＭＭ ＣＣに使用されているかチェックを実行することができる。一例として、ユーザ機器が「低優先度」に対して設定されており、現時点でＳＧＳＮ／ＭＭＥがすべての低優先度ユーザ機器にＭＭ ＣＣを適用している。したがって、たとえユーザ機器が有効にされているＭＭ ＢＯタイマーを有さない場合でも、ページング後にユーザ機器のＮＡＳ ＭＭシグナリングによってＭＭ ＣＣ状況が悪化する可能性がある。以下は、ＳＧＳＮ／ＭＭＥにおける処理の条件である。
− ユーザ機器が一般的なＭＭ ＣＣ下にあり、ネットワークにおけるＭＭ ＣＣ状況が依然として進行中である場合、ＳＧＳＮ／ＭＭＥは、ユーザ機器をページングせず、デバイストリガー目的に使用されるＭＴ−ＳＭＳを拒否することを決定することができる。ＳＧＳＮ／ＭＭＥは、別の実施形態において説明したように、ＳＭ−ＳＣへの拒否されたデバイストリガー要求配信メッセージにＭＭ ＢＯタイマー値を含めることができる。ＳＭ−ＳＣは、ＭＴ−ＳＭＳを格納するか、または失敗したデバイストリガー配信をＭＴＣサーバ／アプリケーションに転送するかを、ＳＧＳＮ／ＭＭＥからのデバイストリガー配信報告の中でシグナリングされるＳＭＳの有効時間およびＭＭ ＢＯタイマーの値に基づいて決定することができる（上の実施形態の１つにおいて説明した処理に似ている）。
− ユーザ機器が一般的なＭＭ ＣＣ下にあり、ネットワークにおけるＭＭ ＣＣがそれ以上存在しない（すなわちＭＭ ＣＣが終了する）場合、ＳＧＳＮ／ＭＭＥは、ユーザ機器をページングすることを決定することができる。ＳＧＳＮ／ＭＭＥは、ユーザ機器が作動中のＭＭ ＢＯタイマーを停止することができるように、適切なページング理由を選択するべきである。
なお、上に説明した機能は、デバイストリガー目的に使用されるＭＴ−ＳＭＳのための機能であり、すなわち、ユーザ機器は、ＭＴ−ＳＭＳの受信後、データ接続を確立または再設定する目的で追加のＮＡＳ ＭＭシグナリングもしくはＳＭシグナリングまたはその両方をおそらく開始する。しかしながら、ＭＴ−ＳＭＳが「通常の」（デバイストリガー以外の目的の）ＳＭＳである場合、ＳＧＳＮ／ＭＭＥは、ＮＡＳ ＭＭ／ＳＭシグナリングがほとんどの場合にはＭＴ−ＳＭＳ送信のためのものである（すなわち追加のＮＡＳ ＭＭシグナリングまたはＳＭシグナリングが発生しない）と結論することができ、したがってＳＧＳＮ／ＭＭＥは、そのような「通常の」ユーザ機器を上記とは異なって扱うことができる。例えば、ＳＧＳＮ／ＭＭＥは、「通常の」ＭＴ−ＳＭＳを送信することを決定することができるのに対して、デバイストリガー目的に使用されるＭＴ−ＳＭＳは拒否される。したがって、上述した、デバイストリガー目的に使用されるＭＴ−ＳＭＳを判定する方法、特に、第６の可能な方法における解決策（デバイストリガー要求が送られるＭＴ−ＳＭＳのヘッダから情報を取り出す）は、ＳＧＳＮ／ＭＭＥにおいて役立ち得る。オプションとして、ＳＧＳＮ／ＭＭＥは、ＭＴ−ＳＭＳが「通常の」ＳＭＳまたはデバイストリガーに関連するＳＭＳであるとき、ＳＭ−ＳＣエンティティに返される配信報告の中にさまざまな失敗理由を含めることができる。例えば、ＳＧＳＮ／ＭＭＥは、再送信抑制タイマーを配信報告に含めるか否かを決定することができる。さらに、ＳＧＳＮ／ＭＭＥは、「通常の」ＳＭＳの場合にのみ、「メッセージ待機フラグ」（ユーザ機器が到達可能になったときにＨＳＳ／ＨＬＲから指示情報が来ることをＳＭ−ＳＣに示す）を含めることを決定することができる。逆に、デバイストリガーに関連するＳＭＳの場合、そのような「メッセージ待機フラグ」を回避することができ、なぜなら、ＭＭＥは配信報告の中で再送信抑制タイマーを使用することができるためである。
以下の実施形態では、この解決策の別の変形形態について説明する。ユーザ機器は、（図８および図９でユーザ機器における点「２）」を参照しながら上述したように）アップリンクデータが期限切れとなるものと判定した後、アップリンクデータの配信／有効性（ＳＭ−ＢＯタイマー）の指示情報をＳＧＳＮ／ＭＭＥまたはＭＴＣサーバに送る代わりに、アップリンクデータを（例えばＳＭＳまたはスモールデータとして）制御プレーンを通じて送ることを決定することができる。これが可能であるのは、ＳＭＳが制御プレーン接続を通じて送られ、新しいＰＤＰ／ＰＤＮ接続のためのセッション管理シグナリングが必要ないためである。ユーザ機器は、報告／指示情報を生成して制御プレーンを通じてネットワークエンティティ（ただし最終的にはＭＴＣサーバ宛）に送信することができるべきである。
この代替実施形態の１つの問題として、ＭＴＣサーバがＳＭＳとしてのアップリンクデータを受信できないことがある。この問題が起こりうるのは、ＳＭＳが制御プレーン接続を通じて送られ、新しいＰＤＰ／ＰＤＮ接続のためのセッション管理シグナリングが必要ないためである。この問題を解決するため、いくつかの解決策を適用することができる。
− ユーザ機器が、アップリンクＩＰデータをＭＯ−ＳＭＳペイロード（または分割ＳＭＳ）にカプセル化し、それをＭＴＣサーバに送り、ＭＴＣ−ＩＷＦがＳＭＳ（分割ＳＭＳ）からアップリンクＩＰデータを取り出す。次いで、ＭＴＣ−ＩＷＦはアップリンクＩＰデータをＭＴＣサーバに転送する。この場合、ＭＴＣ−ＩＷＦは、アップリンクＩＰデータを転送するときにＩＰルータとして動作する。
− ユーザ機器が、アップリンクデータをＭＯ−ＳＭＳペイロード（または分割ＳＭＳ）としてＭＴＣ−ＩＷＦに送る。ＭＴＣ−ＩＷＦは、ＳＭＳ（または分割ＳＭＳ）データのペイロードをＩＰデータに変換する。この目的のため、ＭＴＣ−ＩＷＦはＩＰパケットを生成する。ＭＴＣ−ＩＷＦはＩＰパケットをＭＴＣサーバに転送する。
なお、ＩＰパケットがユーザ機器から送られたことをＭＴＣサーバが認識するように、ＭＴＣ−ＩＷＦは送信元ＩＰアドレスをスプーフする必要がある。この目的のため、ユーザ機器は自身のＩＰアドレスについてＭＴＣ−ＩＷＦに通知する。オプションとして、ＩＰアドレスのスプーフィングを回避する目的で、ＭＴＣ−ＩＷＦはユーザ機器のホームエージェントとして動作することができる（モバイルＩＰ仕様書である非特許文献７および非特許文献８を参照）。
本発明の実施形態によると、端末は、トリガリング要求の受信後、ＩＰアドレスをサーバに報告することができる。デバイストリガリングは、一般的には、ＭＴＣサーバとの通信を確立するようにユーザ機器をトリガーするために使用される。この場合、一般的な想定として、ユーザ機器は、デバイストリガリングを受信した後、（ただちに、またはデータの収集／測定のため特定の遅延の後に）アップリンクデータを送る。しかしながら、ＭＴＣサーバから送られる、ユーザ機器のＩＰアドレスの要求として、デバイストリガリングを使用することも可能である。ＭＴＣサーバは、ユーザ機器のＩＰアドレスを使用してユーザ機器と通信する。言い換えれば、デバイストリガー要求は、ＰＤＰ／ＰＤＮ接続を確立してＩＰアドレスをＭＴＣサーバに報告させるための、（ネットワークに対して不透明なデータの中の）ユーザ機器へのコマンド、またはネットワークへのコマンドを含んでいることができる。要求されたＰＤＰ／ＰＤＮ接続がすでに存在する場合、ユーザ機器またはネットワークは、ＩＰアドレスを報告する。この実施形態は、このシナリオの場合の可能な解決策を記述する。以下の２つの場合を扱う。
− デバイストリガリングが実行されるとき、ＰＤＰ／ＰＤＮ接続がすでに確立されている／存在する場合
− デバイストリガリングが実行されるとき、ＰＤＰ／ＰＤＮ接続が存在しない場合
デバイストリガリングが実行されるとき、ＰＤＰ／ＰＤＮ接続がすでに確立されている／存在する場合、ユーザ機器は、そのＰＤＰ／ＰＤＮ接続に対して設定されているＩＰアドレスを有する。このＩＰアドレスは、ユーザ機器およびネットワークが認識している。デバイストリガリングによって、ユーザ機器が自身のＩＰアドレスを報告することが要求される場合、ユーザ機器は、ＩＰアドレスを含む指示情報メッセージを、制御プレーンを介して、またはユーザプレーンを介して送る。デバイストリガリングによって、ネットワークがユーザ機器のＩＰアドレスを報告することが要求される場合、ネットワーク（おそらくはＭＴＣ−ＩＷＦ）は、サービングコアネットワークノード（ＳＧＳＮ／ＭＭＥ）から、またはユーザプレーン上のネットワークノード（例：ＳＧＷ、ＰＧＷ、ＧＧＳＮ）から、ＩＰアドレスを認識する。その後、ネットワーク（ＳＧＳＮ／ＭＭＥもしくはＭＴＣ−ＩＷＦまたはその両方）は、ユーザ機器のＩＰアドレスについてＭＴＣサーバに通知する。
これに対して、デバイストリガリングが実行されるとき、ＰＤＰ／ＰＤＮ接続が存在しない場合、ユーザ機器は、要求されたＰＤＰ／ＰＤＮ接続に対して設定されたＩＰアドレスを有さない。以下の２つのサブケースが考えられる。
− デバイストリガリングがユーザ機器を対象としている（すなわちトリガー要求が、ネットワークに対して不透明なデバイストリガーデータに含まれている）場合、ユーザ機器は、ＰＤＰ／ＰＤＮ接続の確立を開始する。ネットワーク内に適用されているＳＭ ＣＣが存在するため、ユーザ機器はＰＤＰ／ＰＤＮ接続を確立することができず、したがって、ユーザ機器はＩＰアドレスを設定することができない。結果として、ユーザ機器は、ＰＤＰ／ＰＤＮ接続とＩＰアドレスを確立できないことを、制御プレーンを通じてＭＴＣに報告することができる。言い換えれば、ユーザ機器は、エラー理由をＭＴＣサーバに報告する必要がある。さらに、ユーザ機器は、ＳＭ−ＢＯタイマー値（利用可能な場合）をＭＴＣサーバに報告する。ユーザ機器は、報告／指示情報を生成して制御プレーンを通じてＭＴＣサーバに送信することができる。
− デバイストリガリングの対象がネットワークである（すなわちネットワークがユーザ機器のＩＰアドレスをＭＴＣサーバに報告するべきである）場合、ネットワークは、ネットワークによって開始されるＰＤＰ／ＰＤＮ接続確立手順を実行する。ＧＰＲＳ／ＵＭＴＳの場合、ネットワークによって開始されるＰＤＰ接続確立手順は標準化されている。ＥＰＳの場合、ネットワークによって開始されるＰＤＮ接続確立手順は、指定されていない。いずれの場合も、ネットワーク（特に、サービングコアネットワークノードまたは他の何らかのエンティティのＮＡＳ層におけるセッション管理サブレイヤ）は、ＰＤＰ／ＰＤＮ接続確立のためにネットワークによって開始されるＳＭ要求を実行するかを評価し、なぜならネットワーク（ＳＧＳＮ／ＭＭＥ）は、要求されている／ターゲットのＡＰＮに対して適用されているＳＭ ＣＣが存在するかを認識しているためである。ネットワーク（ＳＧＳＮ／ＭＭＥ）が、例えば高レベルのデバイストリガー要求に起因して、ＰＤＰ／ＰＤＮ接続確立のためにネットワークによってトリガーされるＳＭ要求を開始することを決定する場合、ＳＭ ＣＣに関連する問題は存在せず、なぜならＳＭ ＣＣは対応するユーザ機器のＳＭ応答に適用されないためである。結果として、ネットワーク（ＳＧＳＮ／ＭＭＥもしくはＭＴＣ−ＩＷＦまたはその両方）は、ＰＤＰ／ＰＤＮ接続が正常に確立された後、ユーザ機器のＩＰアドレスについてＭＴＣサーバに通知する。そうではなく、ネットワーク（ＳＧＳＮ／ＭＭＥ）がＰＤＰ／ＰＤＮ接続確立のためにネットワークによってトリガーされるＳＭ要求を開始しないことを決定する場合、ネットワーク（ＳＧＳＮ／ＭＭＥもしくはＭＴＣ−ＩＷＦまたはその両方）は、エラー理由についてと、オプションとして、ＳＭ ＣＣが適用される遅延（ＳＭ−ＢＯタイマー値）について、ＭＴＣサーバに通知する。
要約すると、端末側においては、送信ユニットを、端末のネットワークアドレス（ＩＰアドレスなど）をサーバに送信するようにさらに構成することができる。特に、端末の受信ユニットは、トリガー要求を評価ユニットに提供することができ、評価ユニットは、端末のネットワークアドレスをサーバに報告することを決定する。これに代えて、ネットワークノードが、ネットワークアドレスをサーバに報告することができる。したがって、データをサーバに送信するためのネットワークノードの送信ユニットは（上記の第２の送信ユニットを参照）、端末のネットワークアドレスを、配信遅延指示情報の中で、またはこれとは個別に提供するようにさらに構成することができる。
図１０は、本発明の上述した実施形態を実施するために、端末において実行される方法のステップと、ネットワークノードにおいて実行される方法のステップと、サーバにおいて実行される方法のステップとを示している。具体的には、サーバにおいて、トリガー要求が生成される（１０３２）。生成されたトリガー要求は、ネットワークノードを含むネットワークを通じて端末に送信される（１０３４）。一実施形態においては、ネットワークノードがトリガー要求を格納および評価することができ、別の実施形態においては、トリガー要求をネットワークノードに対して透過的に端末に直接送ることができる。実施形態によると、端末は、トリガー要求を受信し（１０１１）、ネットワークとの接続を確立できるか否かについての評価を実行し（１０１３）、この評価ステップは、ネットワークが輻輳しているか、もしくは、送信されるデータの準備ができているか、またはその両方を判定するステップを含んでいることができる。評価の後、特に、輻輳が検出される、またはデータの準備ができていない場合、配信遅延インジケータがサーバに送信され（１０１５）、このインジケータは、評価の結果によるとトリガー後にサーバとの接続を確立できないこと、またはデータ送信が遅延することのうちの少なくとも一方（これらは輻輳状況のため、またはデータが利用可能ではないことによる）を示す。なお、評価ステップ１０１３は、端末におけるバックオフタイマー、もしくは、ネットワークノードからトリガー要求シグナリング１０２１と一緒に、または個別に端末にシグナリングされうるトリガー有効時間、またはその両方に基づいて、データの有効性を求めるステップを含んでいることもできる。この実施形態に代えて、ネットワークノードが、データの配信遅延またはデータが配信されないことについてサーバに通知することができる。これは図１０においてネットワークノードの側に示してあり、サーバからのトリガー要求を受信するステップ１０２１の後、場合によってはトリガー要求を格納し、端末からサーバへの接続を確立できるか否かを評価し、この評価ステップは、ネットワークが輻輳しているか、ユーザ機器においてバックオフタイマーが作動しているか、端末におけるバックオフタイマーの残り時間、のうちの少なくとも１つを判定するステップを含む。格納するステップは、少なくとも端末ＩＤ、サーバのＩＤ、任意の他のトランザクションＩＤのうちの１つまたは複数を含む、トリガー要求の状態を格納する目的で有利に実行することができる。これにより、データの配信もしくはデータの遅延またはその両方の可能性をネットワークノードが評価することを可能にする目的で、端末がデータを送信するネットワークを識別することが可能になる。評価および場合によっては格納するステップ１０２３の後、ネットワークノードによって配信遅延指示情報がサーバに送信される（１０２５）。サーバ側では、上述した２つの実施形態それぞれの場合に、端末から、またはネットワークノードから、配信遅延指示情報が受信される（１０３６）。次いで、サーバは、上述したように、配信遅延指示情報を使用してさらなるステップを決定することができる（１０３８）。
図１１は、本発明の実施形態による、端末１１１０と、ネットワークノード１１２０と、サーバ１１３０の機能ブロックを示している。具体的には、端末１１１０は、端末機能を実行する通常の機能ブロック１１１７を含んでおり、さらに、サーバからのトリガー要求を受信する受信ユニット１１１３と、接続を確立できるか否か、送信されるデータの準備ができているか、データを送信できるか、のうちの少なくとも１つを評価する評価ユニット１１１４を含んでいる。さらに、端末１１１０は、評価ユニット１１１４の評価結果に基づいて配信遅延インジケータをサーバに送信する送信ユニット１１１５を含んでいる。さらに、端末１１１０は、有効データの有効時間を求める処理ユニット１１１６（有効性チェックユニットとも称する）を含んでいることができる。これらのユニットは、デバイストリガリングの能力を提供するブロックを含む、端末のデバイストリガリング部分１１１１に含まれている。
ネットワークノード１１２０も、ネットワークノードの一般的な機能に対応するユニット１１２７と、デバイストリガリング手順の能力に関連するユニット１１２１とを含んでいる。具体的には、送信ユニット１１２３は、トリガー要求を端末に送信するように構成されている。評価ユニット１１２４は、接続を確立できるか、もしくは、端末からデータを送信できるか、またはその両方を、ネットワーク輻輳の評価と、端末において作動しているバックオフタイマーのうちの少なくとも一方に基づいて評価するように構成されている。第２の送信ユニット１１２５は、評価ユニットからの入力に従って配信遅延インジケータをサーバに送信するように構成されている。さらに、ネットワークノードには、トリガー要求に関する情報（例えば、端末の識別情報、トリガー要求の発行元であるノードの識別情報、サーバの識別情報など）を格納する格納手段１１２６を設けることができる。
最後に、サーバ１１３０は、サーバの一般的な機能を提供する手段１１３７と、デバイストリガリングの能力に関連する手段１１３１とを含んでいる。具体的には、サーバは、トリガリング要求を送信する送信ユニット１１３５と、ネットワークまたは端末から配信遅延指示情報を受信する受信ユニット１１３３と、受信されたインジケータおよび送られたトリガー要求に基づいて、さらなる処理方法について決定する処理ユニット１１３４とを含んでいる。
背景技術のセクションに示した説明は、本明細書に記載されている特定の例示的な実施形態を深く理解できるようにすることを目的としており、３ＧＰＰの標準規格に準拠するネットワークなどのモバイル通信ネットワークにおけるプロセスおよび機能の、説明されている特定の実施形態に、本発明を制限するものではないことを理解されたい。しかしながら、本明細書に提案されている改良・改善は、背景技術のセクションに説明されているアーキテクチャ／システムに容易に適用することができ、本発明のいくつかの実施形態において、これらのアーキテクチャ／システムの標準の手順と、改良された手順とを利用することもできる。具体的な実施形態に示した本発明には、広義に記載されている本発明の概念または範囲から逸脱することなく、さまざまな変更もしくは修正またはその両方を行うことができることが、当業者には理解されるであろう。
本発明の別の実施形態は、ハードウェアおよびソフトウェアを使用して、上述したさまざまな実施形態を実施することに関する。本発明のさまざまな実施形態は、コンピューティングデバイス（プロセッサ）を使用して実施または実行することができるものと認識される。コンピューティングデバイスまたはプロセッサは、例えば、汎用プロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、または、その他プログラマブルロジックデバイスなどである。本発明のさまざまな実施形態は、これらのデバイスの組合せによっても実行または具体化され得る。
さらに、本発明のさまざまな実施形態は、ソフトウェアモジュールによっても実施することができる。これらのソフトウェアモジュールは、プロセッサによって実行され、または、ハードウェアにおいて直接実行される。また、ソフトウェアモジュールとハードウェア実装の組合せも可能である。ソフトウェアモジュールは、任意の種類のコンピュータ可読記憶媒体、例えば、ＲＡＭやＥＰＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、レジスタ、ハードディスク、ＣＤ−ＲＯＭ、ＤＶＤなどに格納することができる。
以下では、本発明に関連する実施形態について要約する。
本発明の第１の態様によると、通信ネットワークにおいて端末をトリガーする方法を提供する。本方法は、端末において実行され、以下に記載するステップを含んでいる。トリガー要求を受信するステップは、端末からサーバへの接続の確立（もしくはデータ送信またはその両方）をトリガーすることを目的とする。トリガー要求は、サーバによって通信ネットワークを通じて端末に送られるものと想定する。接続を確立できるか、もしくは、データを送信できるか、またはその両方を評価するステップは、ネットワークが輻輳しているか、もしくは送信されるデータの準備ができているか、またはその両方を判定するステップを含んでいる。最後に、配信遅延インジケータをサーバに送信するステップは、評価結果によると輻輳状況に起因してトリガーの後にサーバとの接続を確立できないこと、またはデータ送信が遅延することのうちの少なくとも一方を示す目的で設けられている。
本発明の第１の態様に対応して、本発明の別の態様によると、ネットワークノードを含む通信ネットワークにおいて端末をトリガーする方法であって、トリガリングサーバにおいて実行される、方法、を提供する。本方法は、端末からサーバへの接続の確立またはデータの送信をトリガーするトリガー要求を通信ネットワークを通じて端末に送信するステップと、トリガーの後にデータを送信できないこと、またはトリガリング遅延のうちの少なくとも一方を示す配信遅延メッセージを、ネットワークノードまたは端末から受信するステップと、を含んでいる。
しかしながら、本発明は、ユーザ機器によってではなくネットワークノードによって採用することもできる。したがって、本発明の別の態様によると、ネットワークノードを含む通信ネットワークにおいて端末をトリガーする方法であって、本方法がネットワークノードにおいて実行され、端末からサーバへのデータの送信または接続の確立をトリガーするトリガー要求を端末に送信するステップと、端末からサーバへの接続を確立できるか（またはデータを送信できるか）を評価するステップであって、ネットワークが輻輳しているか、バックオフタイマーが作動しているか、端末におけるバックオフタイマーの残り時間、のうちの少なくとも１つを判定するステップを含む、ステップと、トリガー後にサーバとの接続を確立できないこと、データを送信できないこと、データ送信が遅延すること、のうちの少なくとも１つを示す配信遅延メッセージをサーバに送信するステップと、を含んでいる、方法、を提供する。
特に、送信するステップは、制御プレーンを通じて行うことができる。
端末において実行される方法は、ネットワークノードから輻輳インジケータを受信するステップであって、輻輳インジケータが、端末にネットワークとのユーザプレーン接続をただちに確立させるコマンド、または、ネットワークが同じデバイストリガー要求を端末に配信することを試みる時間長を示すデバイストリガー有効時間、のうちの少なくとも一方を含む、ステップ、をさらに含んでいることが有利である。
これによって提供される利点として、端末が状況を評価する（すなわち輻輳が起きているかを判定する）ことと、状況に応じて送られるデータの有効性を推定することとが可能になる。
本方法は、トリガー要求が受信された後、ネットワークを通じてサーバに送信されるデータを収集するのに必要な時間期間としてのデータの有効時間、または、ネットワークが同じデバイストリガー要求を端末に配信することを試みる時間長を示すデバイストリガー有効時間としてのデータの有効時間を求めるステップと、端末においてバックオフタイマーが作動しており、データの有効時間が残りのバックオフ時間より小さい場合に、データが期限切れとなること、もしくは、トリガー要求に応えてデータが送られないこと、またはその両方を示す配信遅延メッセージをサーバに示すステップと、をさらに含んでいることが好ましい。
データの有効性を求め、それをサーバに送信することによって提供される利点として、サーバはさらなる動作について効率的に決定することが可能になる。
ネットワークノードにおいて実行される方法は、端末のＩＤ、もしくは、トリガリング要求メッセージを送ったデバイスのＩＤ、またはその両方を含む、トリガー要求の状態を格納するステップと、配信遅延メッセージを送信するステップであって、配信遅延メッセージが、端末のＩＤ、もしくは、トリガリング要求メッセージを送ったデバイスのＩＤ、またはその両方を含む、ステップと、をさらに含んでいることが有利である。
トリガー要求の状態および端末の識別情報を格納することによって提供される利点として、特定のシナリオにおいてネットワークが配信遅延の指示情報をサーバに提供することが可能になる。
（端末側またはネットワークノード側における）評価ステップは、端末からサーバにデータを送信するかを決定する、もしくは、端末からサーバへのデータの送信の遅延を求める、またはその両方を目的として、端末側において作動しているバックオフタイマーを評価するステップ、もしくは、端末によって送信されるデータの有効期間を評価するステップ、またはその両方を、さらに含んでいることができる。
本発明の別の態様によると、通信ネットワークの端末であって、端末からサーバへの接続の確立をトリガーするトリガー要求を受信する受信ユニットであって、トリガー要求がサーバによって通信ネットワークを通じて端末に送られる、受信ユニットと、接続を確立することができるか否かを評価する評価ユニットであって、ネットワークが輻輳しているか、もしくは、送信されるデータの準備ができているか、またはその両方を判定するステップを含む、評価ユニットと、評価結果によると輻輳状況に起因してトリガーの後にサーバとの接続を確立できないこと、またはデータ送信が遅延することのうちの少なくとも一方を示す配信遅延インジケータをサーバに送信する送信ユニットと、を備えている、端末、を提供する。
受信ユニットは、端末にネットワークとのユーザプレーン接続をただちに確立させるコマンド、または、ネットワークが同じデバイストリガー要求を端末に配信することを試みる時間長を示すデバイストリガー有効時間、のうちの少なくとも一方を含む輻輳インジケータを、ネットワークノードから受信するように、さらに構成することができる。
本端末は、トリガー要求が受信された後に、データの有効時間を、ネットワークを通じてサーバに送信されるデータを収集するのに必要な時間期間として、または、ネットワークが同じデバイストリガー要求を端末に配信することを試みる時間長を示すデバイストリガー有効時間として、求める有効性チェックユニット、をさらに備えていることができる。端末においてバックオフタイマーが作動しており、データの有効時間が残りのバックオフ時間より小さい場合に、データが期限切れとなること、もしくは、トリガー要求に応えてデータが送られないこと、またはその両方を示す配信遅延メッセージをサーバに示すように、送信ユニットをさらに構成することができる。
本発明のさらに別の態様によると、通信ネットワークにおいて端末をトリガーするネットワークノードであって、通信ネットワークの一部である、ネットワークノード、を提供する。本ネットワークノードは、端末からサーバへの接続の確立をトリガーするトリガー要求を端末に送信する第１の送信ユニットと、端末からサーバへの接続を確立できるか否かを評価する評価ユニットであって、ネットワークが輻輳しているかと、バックオフタイマーが作動しているかと、端末におけるバックオフタイマーの残り時間、のうちの少なくとも１つを判定するステップを含む、評価ユニットと、トリガーの後にサーバとの接続を確立できないこと、またはデータ送信が遅延することのうちの少なくとも一方を示す配信遅延メッセージをサーバに送信する第２の送信ユニットと、を備えている。
ネットワークノードは、端末のＩＤ、もしくは、トリガリング要求メッセージを送ったデバイスのＩＤ、またはその両方を含む、トリガー要求の状態を格納する格納手段、をさらに備えていることが有利である。第２の送信ユニットは、配信遅延メッセージを送信するようにさらに構成することができ、配信遅延メッセージは、端末のＩＤ、もしくは、トリガリング要求メッセージを送ったデバイスのＩＤ、またはその両方を含む。
端末もしくはネットワークノードまたはその両方の評価ユニットは、端末からサーバにデータを送信するかを決定する、もしくは、端末からサーバへのデータの送信の遅延を求める、またはその両方を目的として、端末側において作動しているバックオフタイマーを評価する、もしくは、端末によって送信されるデータの有効期間を評価する、またはその両方を行うように構成されていることが好ましい。
本発明の別の態様によると、ネットワークノードを含む通信ネットワークにおいて端末をトリガーするサーバを提供する。サーバは、端末からサーバへの接続の確立またはデータの送信をトリガーするトリガー要求を通信ネットワークを通じて端末に送信する送信ユニットと、トリガーの後にデータを送信できないこと、またはトリガリング遅延のうちの少なくとも一方を示す配信遅延メッセージを、ネットワークノードまたは端末から受信する受信ユニットと、を備えている。さらに、サーバは、トリガー要求を後の時点で再送信するか、トリガー要求を高い優先度で再送信するか、または同じネットワークについては別の端末へのトリガー要求の送信を省くのかを判定するため、配信遅延インジケータを処理する処理ユニットを、さらに含んでいることができる。本方法は、トリガー要求を後の時点で再送信するか、トリガー要求を高い優先度で再送信するか、または同じネットワークについては別の端末へのトリガー要求の送信を省くのかを判定するため、配信遅延インジケータを処理するステップ、をさらに含んでいることができる。
要約すると、本発明は、輻輳制御の場合におけるデバイストリガリングに関する。トリガリングサーバは、サービングネットワークノードを含む通信ネットワークを通じてデバイストリガー要求を端末に送信する。サービングネットワークノードは、メッセージにカプセル化された透過的なデバイストリガー要求を受信する。サービングネットワークノードは、受信されたメッセージがデバイストリガリングに関連するかを判定する目的で、端末のデバイストリガリング能力を判定し、それに基づき、適用されている輻輳制御に応じて、メッセージを端末に転送するか否かを決定する。この方法では、輻輳の場合におけるシグナリングトラフィックが減少し、なぜなら、端末がデバイストリガリングに応えて接続の確立およびデータの送信を試みることが防止されるためである。

Claims (4)

  1. ネットワークノードを含む通信ネットワークにおいて、トリガリングサーバとの接続を確立する、または前記トリガリングサーバにデータを送信するように端末をトリガーする方法であって、前記方法が前記ネットワークノードにおいて実行され、
    前記端末のデバイストリガリング能力に関する情報を、前記端末、前記トリガリングサーバ、または別のネットワークノードから受信されるメッセージから求めるステップと、
    前記端末から前記トリガリングサーバへの接続の確立をトリガーするトリガー要求を前記トリガリングサーバから受信するステップと、
    前記トリガー要求を前記端末に送信するか否かを、前記端末のデバイストリガリング能力に関する前記情報に基づき、かつ、現在の輻輳状態に基づいて、判断するステップと、
    前記判断するステップの結果に従って、前記トリガー要求を前記端末に送信する、または送信しないステップと、
    前記端末から前記トリガリングサーバへの接続を確立できるか否かを評価するステップであって、前記ネットワークが輻輳しているか、前記端末においてバックオフタイマーが作動しているか、前記端末における前記バックオフタイマーの残り時間、のうちの少なくとも１つを判定するステップを含む、ステップと、
    前記トリガリングサーバに通知するために配信遅延指示情報を前記トリガリングサーバに送信するステップであって、前記配信遅延指示情報が、トリガー後に前記トリガリングサーバとの接続を確立できないこと、またはデータ送信が遅延することのうちの少なくとも一方を示す、ステップと、
    を含んでいる、前記方法。
  2. 少なくとも、前記端末のＩＤ、前記トリガリング要求を送ったデバイスのＩＤ、他のトランザクションＩＤのうちの１つまたは複数を含む、トリガー要求の状態、を格納するステップと、
    前記配信遅延指示情報を生成して送信するステップであって、前記配信遅延指示情報が、前記端末のＩＤ、もしくは、前記トリガリング要求メッセージを送った前記デバイスのＩＤ、またはその両方を含む、ステップと、
    をさらに含んでいる、請求項１に記載の方法。
  3. 前記評価するステップが、前記端末から前記トリガリングサーバに前記データを送信するかを決定する、もしくは、前記端末から前記トリガリングサーバへの前記データの送信の遅延を求める、またはその両方を目的として、前記端末側において作動しているバックオフタイマーを評価するステップと、前記端末によって送信される前記データの有効期間を評価するステップ、のうちの少なくとも一方を含んでいる、
    請求項１または請求項２のいずれかに記載の方法。
  4. 前記端末のデバイストリガリング能力に関する前記情報が、
    前記端末が位置している無線アクセスネットワークの無線リソース制御プロトコルによって示される、前記端末の優先度またはサービス品質、
    メッセージが事前定義されたインタフェースまたは事前定義されたネットワークエンティティを通じて受信されるかどうか、
    加入者サーバから受信されるメッセージから求められる能力、
    前記メッセージから求められるポート番号であって、所定のポート番号がデバイストリガリングに使用される、前記ポート番号、
    前記トリガー要求を伝える前記メッセージのヘッダから求められるプロトコル識別子であって、ペイロードのコンテンツタイプを示す、前記プロトコル識別子、
    前記端末から受信されるメッセージから求められる端末のデバイストリガリング能力またはステータス、
    前記トリガー要求メッセージのヘッダから判定される、前記メッセージがデバイストリガリングメッセージであるかどうか、
    のうちの少なくとも１つである、請求項１に記載の方法。
JP2014546398A 2011-12-13 2012-11-26 デバイストリガリングおよびａｐｎベースの輻輳制御 Expired - Fee Related JP6077561B2 (ja)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
EP11193341.2 2011-12-13
EP11193341.2A EP2608567A1 (en) 2011-12-13 2011-12-13 Device triggering and congestion control
EP12153129.7A EP2605606B1 (en) 2011-12-13 2012-01-30 Device triggering and apn-based congestion control
EP12153129.7 2012-01-30
PCT/EP2012/073630 WO2013087403A1 (en) 2011-12-13 2012-11-26 Device triggering and apn-based congestion control

Publications (3)

Publication Number Publication Date
JP2015511409A JP2015511409A (ja) 2015-04-16
JP2015511409A5 JP2015511409A5 (ja) 2015-09-17
JP6077561B2 true JP6077561B2 (ja) 2017-02-08

Family

ID=45524458

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2014546398A Expired - Fee Related JP6077561B2 (ja) 2011-12-13 2012-11-26 デバイストリガリングおよびａｐｎベースの輻輳制御

Country Status (4)

Country Link
US (1) US9648515B2 (ja)
EP (3) EP2608567A1 (ja)
JP (1) JP6077561B2 (ja)
WO (1) WO2013087403A1 (ja)

Families Citing this family (54)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107204938B (zh) 2012-01-20 2021-09-21 三星电子株式会社 发送低优先级数据的方法和装置及处理其的方法和装置
CN103634841A (zh) * 2012-08-20 2014-03-12 中兴通讯股份有限公司 拥塞控制方法及装置
CN103686939B (zh) * 2012-09-25 2017-07-21 华为终端有限公司 触发终端的方法及相关设备
US8923880B2 (en) * 2012-09-28 2014-12-30 Intel Corporation Selective joinder of user equipment with wireless cell
CN103781037B (zh) * 2012-10-26 2017-10-10 华为技术有限公司 一种短消息信令优化方法、设备和***
GB2509072B (en) * 2012-12-19 2015-08-05 Samsung Electronics Co Ltd Bearer management
US9084158B2 (en) * 2012-12-21 2015-07-14 Spreadtrum Communications (Shanghai) Co., Ltd. Supplementary service implementation method, LTE network system and mobile terminal
US10250558B2 (en) * 2013-01-08 2019-04-02 Iot Holdings, Inc. Method and apparatus for triggering devices and delivering small data
CN103929730B (zh) * 2013-01-16 2017-12-29 华为终端有限公司 触发消息发送的方法、设备及***
US10104703B2 (en) * 2013-05-14 2018-10-16 Telefonaktiebolaget Lm Ericsson (Publ) Node and method for establishing direct communications
EP2997746A2 (en) 2013-05-17 2016-03-23 NEC Europe Ltd. Method for managing overload in a mobile communication network
WO2014187479A1 (en) * 2013-05-22 2014-11-27 Nokia Solutions And Networks Oy Mitigating backend signaling overload
UA116025C2 (uk) * 2013-07-04 2018-01-25 Нек Корпорейшн Система, спосіб і пристрій зв'язку
KR102179105B1 (ko) 2013-07-08 2020-11-16 삼성전자 주식회사 무선 랜에서 제어 혼잡을 방지하는 방법 및 장치
US9473931B2 (en) * 2013-07-17 2016-10-18 Qualcomm Incorporated Methods to achieve modem-assisted-service-classification functionality in a device with multiple subscriptions
ES2689847T3 (es) * 2013-09-17 2018-11-16 Intel IP Corporation Control de congestión para servicio de mensajería corta en sistemas de Proyecto de Asociación de 3era Generación (3GPP)
US9516541B2 (en) * 2013-09-17 2016-12-06 Intel IP Corporation Congestion measurement and reporting for real-time delay-sensitive applications
CN104823469B (zh) * 2013-09-23 2019-01-18 华为技术有限公司 传输数据的方法和实体
US9419916B2 (en) * 2013-11-01 2016-08-16 Google Inc. Network fallback using resource request expectations
CN104768137B (zh) * 2014-01-08 2019-03-12 阿尔卡特朗讯 一种用于mtc的触发报告的传递方法与装置
US20150223107A1 (en) * 2014-01-31 2015-08-06 Intel IP Corporation User equipment and method for application specific packet filter
WO2015119003A1 (ja) * 2014-02-04 2015-08-13 株式会社Ｎｔｔドコモ サービス制御システム、ユーザ装置、及びサービス制御方法
US10904946B2 (en) * 2014-03-31 2021-01-26 Convida Wireless, Llc Overload control and coordination between M2M service layer and 3GPP networks
US11012837B2 (en) * 2014-05-14 2021-05-18 Telefonaktiebolaget Lm Ericsson (Publ) Periodic management stabilization for internet of things
US10645572B2 (en) * 2014-06-18 2020-05-05 Telefonaktiebolaget Lm Ericsson (Publ) Method for generating a common identifier for a wireless device in at least two different types of networks
US11159980B2 (en) * 2014-07-22 2021-10-26 Parallel Wireless, Inc. Signaling storm reduction from radio networks
US9794377B2 (en) 2014-09-09 2017-10-17 Telefonaktiebolaget Lm Ericsson (Publ) Simplified notification of network triggered reporting—wireless device (E.G., IoT device) and method
CA2944925C (en) * 2014-10-08 2017-04-25 Tsx Inc. Selective delayed and undelayed database updating
US10992820B2 (en) * 2014-10-28 2021-04-27 Convida Wireless, Llc Methods and apparatuses for service layer charging correlation with underlying networks
US20180007614A1 (en) * 2015-01-21 2018-01-04 Nec Europe Ltd. Mitigation of signalling congestion in cellular networks
CN106465443B (zh) * 2015-05-18 2020-01-17 华为技术有限公司 D2d通信中的ip地址分配方法及用户设备
DK3509337T3 (da) * 2015-08-14 2021-06-28 Ericsson Telefon Ab L M Knude og fremgangsmåde til styring af en Packet Data Network-forbindelse
US10616949B2 (en) * 2015-09-11 2020-04-07 Lg Electronics Inc. Method for operating idle mode by applying extended DRX mode in wireless communication system, and apparatus therefor
CN109982299B (zh) * 2015-10-28 2020-08-21 华为技术有限公司 一种数据传输的方法及装置
US10129689B2 (en) 2015-11-02 2018-11-13 Definition Networks, Inc. Systems and methods for machine-type communication
KR101725143B1 (ko) * 2015-11-09 2017-04-26 최현규 컴퓨터 수행 가능한 그룹 내의 고객관리방법, 장치 및 이를 저장한 기록매체
US20190069196A1 (en) * 2016-03-03 2019-02-28 Nec Corporation Core node, radio terminal, communication method, and non-transitory computer readable medium
WO2018063453A1 (en) * 2016-09-30 2018-04-05 Intel IP Corporation Core network overload control for control plane evolved packet system
US10743246B2 (en) 2016-10-07 2020-08-11 Idac Holdings, Inc. Methods for enforcing limited mobility in mobile network
WO2018084115A1 (ja) * 2016-11-01 2018-05-11 株式会社Ｎｔｔドコモ 無線端末装置及び通信方法
WO2018084686A1 (ko) * 2016-11-07 2018-05-11 엘지전자 주식회사 세션을 관리하는 방법
CN108366430B (zh) * 2017-01-26 2023-10-03 华为技术有限公司 调度请求的方法和终端设备
US10791443B2 (en) * 2017-03-03 2020-09-29 Verizon Patent And Licensing Inc. System and method for enhanced messaging using external identifiers
EP3606115B1 (en) * 2017-03-20 2022-05-04 LG Electronics Inc. Method for interaction between layers in wireless communication system and apparatus therefor
EP4243567A3 (en) * 2017-04-28 2024-02-21 Guangdong Oppo Mobile Telecommunications Corp., Ltd. Congestion processing method and device
US11330428B2 (en) * 2017-05-08 2022-05-10 Telefonaktiebolaget Lm Ericsson (Publ) Privacy key in a wireless communication system
CN109429348B (zh) 2017-07-19 2022-03-29 华为技术有限公司 一种数据的处理方法、移动性管理设备和终端设备
WO2019074411A1 (en) * 2017-10-12 2019-04-18 Telefonaktiebolaget Lm Ericsson (Publ) COMMUNICATION DEVICE, NETWORK NODE, RADIO NETWORK NODE AND ASSOCIATED METHODS IMPLEMENTED FOR MANAGING COMMUNICATION IN A COMMUNICATION NETWORK
US10764779B2 (en) * 2017-11-28 2020-09-01 Mediatek Singapore Pte. Ltd. Apparatuses and methods for mobility management (MM) congestion control
US10887824B2 (en) 2018-07-17 2021-01-05 At & T Intellectual Property I, L.P. Protective response to failed network attach operations
EP3697040B1 (en) * 2019-02-15 2022-03-09 Nokia Solutions and Networks Oy Congestion control in a wireless communication network
US10887187B2 (en) * 2019-05-14 2021-01-05 At&T Mobility Ii Llc Integration of a device platform with a core network or a multi-access edge computing environment
TWI761720B (zh) 2019-10-24 2022-04-21 緯創資通股份有限公司 自適應設定存取點名稱的方法
WO2023245607A1 (en) * 2022-06-24 2023-12-28 Nokia Shanghai Bell Co., Ltd. Positioning configuration update

Family Cites Families (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7161914B2 (en) * 2002-04-11 2007-01-09 Ntt Docomo, Inc. Context aware application level triggering mechanism for pre-authentication, service adaptation, pre-caching and handover in a heterogeneous network environment
JP4500269B2 (ja) * 2003-01-21 2010-07-14 インターデイジタル テクノロジー コーポレーション オブジェクトリクエストブローカの方法論を使用した無線リソース管理スケジューラ
US8000242B2 (en) * 2006-07-06 2011-08-16 Alcatel Lucent Reducing packet loss for a packet data service during congestion in a transport network
CN101635932B (zh) * 2008-07-21 2012-08-29 华为技术有限公司 信道检测和上报方法及***、终端、管理中心
US9125053B2 (en) * 2008-10-06 2015-09-01 Nec Corporation Communication system, connection control apparatus, mobile terminal, base station control method, service request method, and program
KR101810260B1 (ko) * 2010-02-12 2017-12-18 인터디지탈 패튼 홀딩스, 인크 상향링크 랜덤 액세스 채널 전송을 최적화하는 방법 및 장치
KR101762468B1 (ko) * 2010-02-12 2017-07-27 인터디지탈 패튼 홀딩스, 인크 머신간 통신에서의 액세스 제어 및 혼잡 제어
EP2941026B1 (en) * 2010-03-23 2017-12-13 Interdigital Patent Holdings, Inc. Method for communication for a machine type communication device and corresponding wireless transmit/receive unit
EP2369890A1 (en) * 2010-03-26 2011-09-28 Panasonic Corporation Connection peak avoidance for machine-type-communication (MTC) devices
US9143461B2 (en) * 2010-04-30 2015-09-22 Panasonic Intellectual Property Corporation Of America Communication device, network node, and communication server
ES2657263T3 (es) * 2010-05-03 2018-03-02 Alcatel Lucent Control de sobrecarga en un sistema de comunicación móvil de paquetes
EP2416604B1 (en) * 2010-08-05 2017-09-20 HTC Corporation Handling signalling congestion and related communication device
CN102387492B (zh) * 2010-08-27 2014-01-22 上海贝尔股份有限公司 机器型通信的特性激活及机器设备
GB2484922B (en) * 2010-10-25 2014-10-08 Sca Ipla Holdings Inc Infrastructure equipment and method
US9253178B2 (en) * 2011-01-17 2016-02-02 Telefonaktiebolaget L M Ericsson Method and apparatus for authenticating a communication device
US20120252481A1 (en) * 2011-04-01 2012-10-04 Cisco Technology, Inc. Machine to machine communication in a communication network
CN103548322B (zh) * 2011-04-06 2017-05-17 高通股份有限公司 用于触发分离的机器类型通信设备的方法和装置
CN102740400B (zh) * 2011-04-07 2016-08-10 宏达国际电子股份有限公司 处理机器型态通讯的装置触发的方法
EP2709291B1 (en) * 2011-05-11 2018-10-10 LG Electronics Inc. Method and apparatus for mtc in a wireless communication system
US20130044659A1 (en) * 2011-08-16 2013-02-21 Renesas Mobile Corporation Wireless Devices and Base Stations and Methods of Operating
CN102958025B (zh) * 2011-08-24 2018-01-16 中兴通讯股份有限公司 发送mtc设备触发信息的方法、***和目标用户设备
EP2761928B1 (en) * 2011-09-29 2020-03-25 Nokia Solutions and Networks Oy Methods and apparatuses for device triggering
US9603037B2 (en) * 2011-12-08 2017-03-21 Htc Corporation Method of handling delayed signaling of target mobile device
CN103686939B (zh) * 2012-09-25 2017-07-21 华为终端有限公司 触发终端的方法及相关设备
CN103906023B (zh) * 2012-12-28 2019-06-18 中兴通讯股份有限公司 机器类型设备mtc设备的触发信息的处理方法及装置

Also Published As

Publication number Publication date
WO2013087403A1 (en) 2013-06-20
US20140341041A1 (en) 2014-11-20
EP2605606B1 (en) 2019-03-06
EP2608567A1 (en) 2013-06-26
EP2605606A2 (en) 2013-06-19
EP2792159B1 (en) 2018-06-20
EP2792159A1 (en) 2014-10-22
JP2015511409A (ja) 2015-04-16
EP2605606A3 (en) 2016-12-21
US9648515B2 (en) 2017-05-09

Similar Documents

Publication Publication Date Title
JP6077561B2 (ja) デバイストリガリングおよびａｐｎベースの輻輳制御
JP6593725B2 (ja) 改良されたショート・メッセージ送信手順およびハンドオーバ手順
US12028912B2 (en) Method for (re)selection of control plane and user plane data transmission
US11617072B2 (en) Reliable data delivery over non-access stratum
US11064457B2 (en) Paging policy differentiation in 5G system
US9439073B2 (en) Server and communication terminal
EP2852210B1 (en) Method and device for processing message overload

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20150731

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20150731

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20160407

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20160426

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20160721

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20170104

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20170112

R150 Certificate of patent or registration of utility model

Ref document number: 6077561

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees