JP6434618B2 - マルチトランスポート機構をサポートするネットワークのためのアプリケーションデータ配信サービス - Google Patents

Description

第３世代パートナーシッププロジェクト（３ＧＰＰ）は、いくつかの電気通信規格開発団体を統一し、無線アクセス、コアトランスポートネットワーク、およびサービス能力を含む、セルラー電気通信ネットワーク技術のための仕様を開発する環境を、それらのメンバーに提供する。３ＧＰＰ仕様はまた、コアネットワークへの非無線アクセスのためのフック、および他のネットワークとのインターワーキングも提供する。

無線通信のための３ＧＰＰコアネットワークアーキテクチャの最新の進化は、進化型パケットコア（ＥＰＣ）と称される。ＥＰＣは、最初に、規格のリリース８において３ＧＰＰによって導入された。これは、性能および費用の観点から、データトラフィックを効率的に取り扱うために、「平坦なアーキテクチャ」を有するように設計され、少ないネットワークノードが、トラフィックの取扱に関与している。プロトコル変換も、概して、回避される。また、信号通信（「制御プレーン」としても公知である）からユーザデータ（「ユーザプレーン」としても公知である）を分離することも決定され、これは、ネットワークオペレータが、それらのネットワークを容易に定寸および適合することを可能にする。

図１は、Ｅ−ＵＴＲＡＮ（ＬＴＥアクセスネットワーク）を経由してＥＰＣ１０２に接続されたユーザ機器（ＵＥ）１０４（例えば、携帯電話または他の無線デバイス）を図示する、基本アーキテクチャである。進化型ノードＢ（ｅＮｏｄｅＢ））１０６は、ＬＴＥ無線用の基地局である。この図では、ＥＰＣは、４つのネットワーク要素、すなわち、サービングゲートウェイ（サービングＧＷ）１１０、パケットデータネットワークゲートウェイ（ＰＤＮ ＧＷ）１１２、ＭＭＥ１１４、およびＨＳＳ１１６から成る。ＥＰＣは、外部ネットワーク１０８に接続されてもよい。

ＨＳＳ（ホーム加入者サーバ）１１６は、ユーザ関連および加入者関連情報を含有するデータベースである。これはまた、移動性管理、呼び出しおよびセッション設定、ユーザ認証ならびにアクセス認可におけるサポート機能も提供する。

ゲートウェイ（サービングＧＷ１１０およびＰＤＮ ＧＷ１１２）は、ユーザプレーンを取り扱う。それらは、ユーザ機器（ＵＥ）と外部ネットワークとの間でＩＰデータトラフィックを輸送する。サービングＧＷ１１０は、無線側とＥＰＣとの間の相互接続点である。その名前が示すように、このゲートウェイは、着信および発信ＩＰパケットを送ることによってＵＥにサービス提供する。これは、ＬＴＥ内移動性のアンカポイントであり（すなわち、ｅＮｏｄｅＢ間のハンドオーバの場合）、ＬＴＥと他の３ＧＰＰアクセスとの間にある。これは、論理的に、他方のゲートウェイ、すなわち、ＰＤＮ ＧＷに接続される。

ＰＤＮ ＧＷ１１２は、ＥＰＣとインターネット等の外部ＩＰネットワークとの間の相互接続点である。これらのネットワークは、ＰＤＮ（パケットデータネットワーク）、したがって、名前と呼ばれる。ＰＤＮ ＧＷは、ＰＤＮへ、およびそこからパケットを送る。ＰＤＮ ＧＷはまた、ＩＰアドレス／ＩＰプレフィックス割付またはポリシー制御、および課金等の種々の機能も果たす。３ＧＰＰは、独立してこれらのゲートウェイを規定するが、実践では、それらは、ネットワークベンダによって単一の「ボックス」の中で組み合わせられてもよい。

ＭＭＥ（移動性管理エンティティ）１１４は、コントロールプレーンを取り扱う。これは、Ｅ−ＵＴＲＡＮアクセスのための移動性およびセキュリティに関係付けられる信号通信を取り扱う。ＭＭＥは、アイドルモードでＵＥの追跡およびページングに関与する。これはまた、非アクセス層（ＮＡＳ）の終端点でもある。

図１に示されるように、ＵＥ１０４は、Ｅ−ＵＴＲＡＮを使用してＥＰＣ１０２に到達することができるが、これは、サポートされる唯一のアクセス技術ではない。３ＧＰＰは、複数のアクセス技術、また、これらのアクセスの間のハンドオーバもサポートすることを規定する。本概念は、複数のアクセス技術にわたって種々のＩＰベースのサービスを提供する一意のコアネットワークを使用して、集中をもたらすことである。既存の３ＧＰＰ無線アクセスネットワークがサポートされる。３ＧＰＰ仕様は、どのようにしてインターワーキングがＥ−ＵＴＲＡＮ（ＬＴＥおよびＬＴＥ−Ａｄｖａｎｃｅｄ）、ＧＥＲＡＮ（ＧＳＭ（登録商標）／ＧＰＲＳの無線アクセスネットワーク）、およびＵＴＲＡＮ（ＵＭＴＳベース技術ＷＣＤＭＡ（登録商標）およびＨＳＰＡの無線アクセスネットワーク）の間で達成されるかを定義する。

アーキテクチャはまた、ＵＥおよびＥＰＣを相互接続する非３ＧＰＰ技術も可能にする。非３ＧＰＰは、これらのアクセスが３ＧＰＰで規定されなかったことを意味する。これらの技術は、例えば、ＷｉＭＡＸ、ｃｄｍａ２０００（登録商標）、ＷＬＡＮ、または固定ネットワークを含む。非３ＧＰＰアクセスは、２つのカテゴリ、すなわち、「信頼できる」ものおよび「信頼できない」ものに分けられることができる。信頼できる非３ＧＰＰアクセスは、ＥＰＣと直接相互作用することができる。信頼できない非３ＧＰＰアクセスは、ｅＰＤＧ（進化型パケットデータゲートウェイ）（図示せず）と呼ばれるネットワークエンティティを介してＥＰＣとインターワーキングする。ｅＰＤＧの主要な役割は、信頼できない非３ＧＰＰアクセスを経由したＵＥとの接続のＩＰｓｅｃトンネリング等のセキュリティ機構を提供することである。３ＧＰＰは、どの非３ＧＰＰ技術が信頼できる、または信頼できないと見なされるべきであるかを規定しない。この決定は、オペレータによって行われる。

図１に図示される３ＧＰＰネットワークアーキテクチャは、本来、人間によって従来的に操作されるデバイスの間の通信を可能にするように設計された。例えば、３ＧＰＰネットワークは、インターネット等のパケット交換ネットワークおよびグローバルシステムフォーモバイルコミュニケーションズ（ＧＳＭ（登録商標））ネットワーク等の回路交換ネットワークへのアクセスをスマートフォンに提供するためによく適している。３ＧＰＰネットワークは、本来、スマート計測、ホームオートメーション、ｅＨｅａｌｔｈ、消費者製品、フリート管理等を伴う通信等の、マシンまたはデバイスがネットワークを経由して相互と通信する、マシン型通信（ＭＴＣ）とも称される、いわゆるマシンツーマシン（Ｍ２Ｍ）通信を取り扱うために最適化される方法で設計されなかった。

３ＧＰＰ仕様のリリース１１（Ｒ１１）では、３ＧＰＰは、マシン型通信／マシンツーマシン通信のためのＵＭＴＳコアネットワークのインターワーキング能力を増進した。インターワーキングとは、情報を交換する、デバイスを制御する、またはデバイスを監視する、もしくはデバイスと通信する目的で、コアネットワークにインターフェース接続する、サーバまたはアプリケーションを指す。図２は、ＴＳ ２３．６８２ Ｖ１１．５．０において３ＧＰＰによって提示されるＭＴＣアーキテクチャを示す。

図２に図示されるように、サービス能力サーバ（ＳＣＳ）２１２は、サービスをコアネットワーク、デバイス、およびアプリケーションに提供してもよい。ＳＣＳはまた、Ｍ２Ｍサーバ、ＭＴＣサーバ、サービス能力層（ＳＣＬ）、または共通サービスエンティティ（ＣＳＥ）と呼ばれてもよい。ＳＣＳ２１２は、ホーム公衆陸上移動ネットワーク（ＨＰＬＭＮ）のオペレータによって、またはＭＴＣサービスプロバイダによって制御されてもよい。ＳＣＳは、オペレータドメインの内側または外側に展開されてもよい。ＳＣＳがオペレータドメインの内側に展開される場合、ＳＣＳは、内部ネットワーク機能であってもよく、かつオペレータによって制御されてもよい。ＳＣＳがオペレータドメインの外側に展開される場合、ＳＣＳは、ＭＴＣサービスプロバイダによって制御されてもよい。

ＳＣＳは、Ｔｓｐ基準点（すなわち、インターフェース）を介して、マシン型通信（ＭＴＣ）インターワーキング機能（ＭＴＣ−ＩＷＦ）２１０と通信してもよい。Ｔｓｐ基準点は、コアネットワークとインターワーキングするために使用されるインターフェースの実施例である。

さらに図２に図示されるように、基準点（すなわち、インターフェース）Ｔｓｍｓ２０２は、ショートメッセージサービス（ＳＭＳ）サービスセンタ（ＳＭＳ−ＳＣ）２０４をショートメッセージエンティティ（ＳＭＥ）２０６に接続してもよい。Ｔｓｍｓ基準点は、コアネットワークとインターワーキングするために使用されるインターフェースの別の実施例である。ＳＭＳ−ＳＣ２０４は、Ｔ４基準点を経由してＭＴＣ−ＩＷＦと通信する。

同様に図２に図示されるように、ＳＣＳ２１２は、デバイストリガのために、ユーザ機器ＭＴＣ（ＵＥ ＭＴＣ）アプリケーション２１６、（例えば、境界２１８によって画定されるような）ＨＰＬＭＮ内のＭＴＣ−ＩＷＦ２１０、またはＳＭＳ−ＳＣ２０４と通信するように、３ＧＰＰネットワークに接続し得る、エンティティであってもよい。ＳＣＳ２１２は、１つまたはそれを上回るアプリケーションサーバＭＴＣ（ＡＳ ＭＴＣ）アプリケーションによって使用するための能力を提供してもよい。

ＵＥは、無線アクセスネットワーク（ＲＡＮ）２１９を含む公衆陸上移動ネットワーク（ＰＬＭＮ）を通して、ＳＣＳおよび／または他のＭＴＣ ＵＥと通信してもよい。ＭＴＣ ＵＥ２１４は、１つまたはそれを上回るＭＴＣアプリケーション２１６をホストしてもよい。ＭＴＣアプリケーションはまた、１つまたはそれを上回るＡＳ２２０／２２２上でホストされてもよい。ＭＴＣアプリケーション２１６は、ＳＣＳ２１２、ＡＳ ＭＴＣアプリケーション、または他のＵＥ ＭＴＣアプリケーションと相互作用し得る、ＭＴＣ通信エンドポイントであってもよい。

アプリケーションサーバ（ＡＳ）２２０／２２２はまた、１つまたはそれを上回るＭＴＣアプリケーションをホストしてもよい。ＡＳは、ＳＣＳ２１２またはＧＧＳＮ／Ｐ−ＧＷ２２４とインターワーキングしてもよい。ＡＳ上のＭＴＣアプリケーションは、ＳＣＳ、ＵＥ ＭＴＣアプリケーション、または他のＭＴＣアプリケーションと相互作用してもよい。

ＭＴＣインターワーキング機能（ＭＴＣ−ＩＷＦ）２１０は、ＳＣＳ２１２から内部ＰＬＭＮトポロジを隠してもよい。ＭＴＣ−ＩＷＦは、ＰＬＭＮ内でＭＴＣ機能性（例えば、ＭＴＣ ＵＥトリガ）をサポートするように、（例えば、Ｔｓｐ基準点２０８を経由して）それ自体とＳＣＳとの間で使用される信号通信プロトコルを中継および／または変換してもよい。例えば、ＳＣＳは、ＭＴＣ−ＩＷＦがトリガをＭＴＣデバイスに送信することを要求してもよい。ＭＴＣ−ＩＷＦは、ＳＭＳを介して、ＭＴＣトリガをＭＴＣデバイス２１４に配信してもよい。ＭＴＣデバイス２１６は、トリガに基づいて、ＳＣＳ２１２に応答してもよい。ＭＴＣデバイス２１６は、例えば、センサ示度値で応答してもよい。ＭＴＣデバイス２１６がＳＣＳ２１２に応答するとき、ＭＴＣデバイスは、ＳＣＳ２１２と通信するために、パケットデータネットワーク（ＰＤＮ）／パケットデータプロトコル（ＰＤＰ）接続を使用してもよい。ＭＴＣデバイスは、ＩＰ接続を使用して、ＳＣＳと接続してもよい。

ＭＴＣ−ＩＷＦ２１０は、ＳＣＳが３ＧＰＰネットワークとの通信を確立し得る前に、ＳＣＳ２１２を認可してもよい。例えば、ＳＣＳ２１２がＴｓｐ基準点上でトリガ要求を行うとき、ＭＴＣ−ＩＷＦ２１０は、ＳＣＳがトリガ要求を送信する権限を与えられているかどうか、およびＳＣＳがそのトリガ提出の割当または割合を超えていないことをチェックしてもよい。

さらに図２に示されるように、移動切替センタ（ＭＳＣ）２３８は、音声電話およびＳＭＳならびに他のサービス（電話会議、ＦＡＸ、および回路交換データ）を送る責任がある、ＧＳＭ（登録商標）／ＣＤＭＡ用の主要サービス配信ノードである。ＭＳＣは、エンドツーエンド接続を設定して公開し、通話中に移動性およびハンドオーバ要件を取り扱い、課金およびリアルタイムプリペイドアカウント監視を管理する。

サービング汎用パケット無線サービス（ＧＰＲＳ）サポートノード（ＳＧＳＮ）２３４は、その地理的サービス地域内のモバイルデバイスを往復するデータパケットの配信に責任がある。そのタスクは、パケットルーティングおよび転送、移動性管理（アタッチ／デタッチおよび場所管理）、論理リンク管理、ならびに認証および課金機能を含む。ＳＧＳＮの場所レジスタは、場所情報（例えば、現在のセル、現在のＶＬＲ）、およびそれに登録された全てのＧＰＲＳユーザのユーザプロファイル（例えば、ＩＭＳＩ、パケットデータネットワークで使用されるアドレス）を記憶する。

Ｍ２Ｍ／ＭＴＣ通信は、人間の相互作用を伴う従来のデータ通信と異なる。例えば、データ通信を必要とするＭ２Ｍ／ＭＴＣアプリケーションは、全て同一の特性を有するわけではない。各タイプのＭ２Ｍ／ＭＴＣアプリケーションは、異なるタイプの通信サービスを必要とし得る。３ＧＰＰ ＴＳ ２２．３６８は、これらの異なるサービス要件を識別し、これらのサービスを提供する、異なるＭＴＣ特徴を列挙する。例えば、ＭＴＣ特徴‘Ｌｏｗ Ｍｏｂｉｌｉｔｙ’は、移動しない、稀に移動する、またはある領域内のみで移動するＭＴＣデバイスとともに使用するために意図される。ＭＴＣ特徴‘Ｔｉｍｅ Ｃｏｎｔｒｏｌｌｅｄ’は、定義された時間間隔中のみにデータを送信または受信するように許容し、これらの定義された時間間隔外で不必要な信号通信を回避することができる、ＭＴＣアプリケーションとともに使用するために意図される。ＭＴＣ特徴‘Ｓｍａｌｌ Ｄａｔａ Ｔｒａｎｓｍｉｓｓｉｏｎｓ’は、少量のデータを送信または受信するＭＴＣデバイスとともに使用するために意図される。ＭＴＣ特徴‘Ｉｎｆｒｅｑｕｅｎｔ Ｍｏｂｉｌｅ Ｔｅｒｍｉｎａｔｅｄ’は、モバイル発信通信を主に利用する、ＭＴＣデバイスとともに使用するために意図される。ＭＴＣ特徴‘ＭＴＣ Ｍｏｎｉｔｏｒｉｎｇ’は、ＭＴＣデバイス関連イベントを監視するために意図される。ＭＴＣ特徴‘Ｓｅｃｕｒｅ Ｃｏｎｎｅｃｔｉｏｎ’は、ＭＴＣデバイスとＭＴＣサーバ／ＭＴＣアプリケーションサーバとの間の安全な接続を必要とするＭＴＣデバイスとともに使用するために意図される。最後に、ＭＴＣ特徴‘Ｇｒｏｕｐ Ｂａｓｅｄ’は、ＭＴＣデバイスのグループに適用され、グループベースのポリシー、グループベースのアドレス指定等を含む。

既存の３ＧＰＰネットワークでは、アプリケーション層データ通信は、主に、パケットドメインを通して、およびＳＭＳを通してサポートされる。（ｉ）（ＳＧｉおよびＧｉ基準点を介した）パケットドメイン、（ｉｉ）ショートメッセージサービス（ＳＭＳ）、（ｉｉｉ）マルチメディアメッセージングサービス（ＭＭＳ）、および（ｉｖ）非アクセス層（ＮＡＳ）を含む、いくつかの異なるトランスポート機構が利用可能である。

パケットドメインメッセージングに関して、ＰＧＷおよびＧＧＳＮは、データ通信用のアンカポイントの役割を果たし、それらは、コアネットワーク内のＧＴＰ−Ｕトンネルを通してユーザプレーンデータを送ってもよい（ＰＭＩＰもまた、Ｓ５／Ｓ８インターフェースで使用されてもよい）。３ＧＰＰ ＴＳ ２３．４０１が、本ＥＰＣアーキテクチャを定義する。ＧＴＰ−Ｕトンネルは、共通ＱｏＳ処置を、それらを通してトランスポートされるＩＰフローに提供する。パケットフィルタは、規定ＧＴＰ−Ｕトンネルを通してトランスポートされるフローを決定する。

ＳＭＳの目的は、３ＧＰＰ ＴＳ ２３．０４０で説明されるように、ＳＣ（サービスセンタ）を介してＭＳ／ＵＥとＳＭＥ（ショートメッセージエンティティ）との間にショートテキストメッセージを転送する手段を提供することである。ＳＭＳは、主に、ユーザの間でショートテキストメッセージを交換するために使用される。しかしながら、ＳＭＳはまた、ショートデータ通信用のいくつかの上位層アプリケーションによって使用されることもできる。ＳＭＳはまた、ストアアンドフォワード機構を提供することもできる。ＳＭＳは、通常のユーザプレーンデータとは異なって送られ、概して、ＳＧｉ／Ｇｉインターフェースパスを使用しない。

ＭＭＳは、マルチメディアメッセージングコンテキストにおいてコンテンツの豊富なセットを加入者に提供するために使用される、サービスである。これは、ＳＭＳに類似するストアアンドフォワードパラダイムを提供する。しかしながら、ＭＭＳは、マルチメディアメッセージをトランスポートするために、パケットドメインユーザプレーン（ＳＧｉ／Ｇｉ）を使用する。ＭＭＳは、ユーザプレーンを経由して作動するアプリケーションレベルサービスと見なされることができる。３ＧＰＰ ＴＳ ２３．１４０は、ＭＭＳアーキテクチャを説明する。ＭＭＳは、マルチメディアメッセージの受信側にアドレス指定するように、Ｅメールアドレス（ＲＦＣ ２８２２）またはＭＳＩＳＤＮ（Ｅ．１６４）もしくは両方の使用をサポートする。ＭＭＳはまた、マルチメディアメッセージの受信側にアドレス指定するように、サービスプロバイダ特有のアドレスの使用をサポートしてもよい。

ＮＡＳに関して、ＭＴＣ−ＩＷＦが、少量データメッセージをＳＧＳＮ／ＭＭＥに送信するためにＴ５インターフェースを使用することを可能にし、次いで、データをＵＥに送信するためにＮＡＳまたはＲＲＣメッセージを使用することについて、３ＧＰＰ ＳＡ２内で議論が行われている。本特徴は、まだ３ＧＰＰによってサポートされていないが、将来、何らかのそのようなサービスがサポートされ得ることが予測される。

３ＧＰＰネットワーク内のデータトランスポートのための別の既存の機構は、デバイストリガと呼ばれる。デバイストリガは、ＳＣＳとの通信を開始することを含む、アプリケーション特有の動作を行うようにＵＥにトリガするために、ＳＣＳが３ＧＰＰネットワークを介して情報をＵＥに送信する手段である。３ＧＰＰ ＴＳ ２３．６８２は、３ＧＰＰネットワークによってサポートされるデバイストリガ機構を定義する。デバイストリガは、ＵＥのＩＰアドレスがＳＣＳ／ＡＳによって利用可能または到達可能ではないときに、必要とされる。

デバイストリガが必要であるかどうかを判定するために、ＳＣＳ／ＡＳは、デバイスのＩＰアドレスの有効性を追跡する必要があろう。デバイスが過剰に長い間アイドルである場合、ネットワーク／ＰＤＮが、Ｍ２Ｍデバイスに割り当てられたＩＰアドレスを別のＵＥに再び割り付け得る可能性がある。ある場合には、ＳＣＳ／ＡＳは、ＳＣＳ／ＡＳにおいて公知であるデバイスのＩＰアドレスを使用して、初期通信を試行してもよく、（おそらくＩＣＭＰメッセージに基づいて）通信が失敗した後に、ＩＰアドレスが無効であることを検出してもよい。これは、Ｍ２Ｍデバイスとの通信を確立するために時間がかかり得る。また、既存のデバイストリガアプリーチは、アプリケーションデータを交換する前に、デバイストリガが必要とされるかどうかを判定するようにＳＣＳ／ＡＳに要求し、ＳＣＳ／ＡＳは、デバイストリガメッセージを構築し、デバイストリガプロシージャを開始する必要があろう。

本願は、限定ではないが、３ＧＰＰ ＭＴＣアーキテクチャ等のＭ２ＭまたはＭＴＣ通信ネットワーク内のアプリケーションの間のアプリケーションデータ転送のための新しい方法およびシステムを開示する。

上記のように、Ｍ２Ｍ／ＭＴＣ通信は、人間を伴う従来の通信と異なる特性を有する。いくつかのＭ２Ｍ／ＭＴＣアプリケーションが、即時（低遅延）データ転送を必要とし得る一方で、他のＭ２Ｍ通信は、数日程度の遅延に耐えることができる。３ＧＰＰは、データを転送するために利用可能ないくつかの方法を有し、制御プレーンを経由して小さいユーザデータパケットを送信するためのアプローチを開発しているが、これらの既存の方法は、データを送信しているアプリケーションの基本的な基礎通信要件を考慮しない。アプリケーションデータを送信する、コアネットワークノードまたはアプリケーションサーバ（すなわち、ＳＣＳ）は、どのようなデータトランスポート方法が選択されるかに影響を及ぼすことができない。アプリケーション認識をＥＰＣに導入することによって、ＥＰＣは、ＱｏＳおよびＩＰフロー制御のみよりもアプリケーション認識したサービスならびに効率的なトランスポートサービスをアプリケーションに提供してもよい。

アプリケーション認識はまた、トリガをより効率的にすることもできる。３ＧＰＰネットワーク内の既存のデバイストリガ機構は、トリガがＳＣＳによって開始されることを要求する。ＳＣＳは、ＵＥの状態を判定し、トリガが必要であるかどうかを決定することが期待される。同様に、ＳＣＳは、少量データ伝送を使用するときをコアネットワークに示す必要がある。ＳＣＳは、最適なデータ配信方法を把握することが期待される。しかし、これらの決定は、ＳＣＳからの支援を受けて、コアネットワークによって、より知的または効率的に行われることができる。

３ＧＰＰネットワーク内の複数の異なるデータトランスポート機構の存在もまた、Ｍ２Ｍ／ＭＴＣアプリケーション開発をより困難にする。開発者が、異なるシナリオで異なるトランスポート機構を利用しようと希望する場合、アプリケーション開発者は、これらの異なる機構のそれぞれをコードしなければならず、また、所与の状況で適切な機構を選択するために必要なコードを提供しなければならない。

既存の技術分野におけるこれらの不足に対処するために、本願は、デバイスドメイン内に常駐し得るアプリケーション、例えば、Ｍ２Ｍ／ＭＴＣデバイスおよびゲートウェイと、ネットワークドメイン内に常駐するアプリケーション、例えば、ＡＳまたはＳＣＳとの間のアプリケーションデータ転送を促進する、本明細書ではアプリケーションデータ配信サービス（ＡＤＤＳ）と称される、新しいサービスを開示する。また、本明細書では、新しいデータ配信サービスを提供するためのＡＤＤＳと３ＧＰＰコアネットワークノードとの間の新しいインターフェース（すなわち、基準点）も開示される。

一実施形態では、アプリケーションはそれぞれ、ＡＤＤＳサービスにアプリケーションを識別する、一意のＡＤＤＳサービス特有の識別子を割り当てられる。本識別子は、種々の３ＧＰＰ層識別子を経由して抽象化を提供し、ＡＤＤＳ特有の機能性をシームレスに提供するように、ＡＤＤＳサービスおよびエンドノードがアプリケーションをホストすることに役立つ。本アプリケーション識別子を用いると、アプリケーションは、ＩＰアドレス、ＦＱＤＮ、外部ＩＤ、ＭＳＩＳＤＮ、または同等物のような他のトランスポート層特有の識別を認識する必要がない。

一実施形態では、ＡＤＤＳは、ＮＡＳ、ＳＭＳ、ＵＳＳＤ、およびユーザプレーン等の既存の３ＧＰＰトランスポート機構を活用し、それは、アプリケーションデータ特性、アプリケーション／エンドノード特性および可用性、加入情報、ネットワークのポリシー、ネットワーク状態（混雑、ノード可用性等）、ならびに同等物等の基準に基づいて、アプリケーションデータを配信するためのトランスポート機構を選択するように構成される。

ＡＤＤＳによって提供される他の特徴は、アプリケーション移動性（たとえネットワークにアクセスするモードが変化したとしても、アプリケーションがＡＤＤＳサービスを使用し続ける能力）、ストアアンドフォワード能力、および以降で明白となるであろうその他を含む。

本概要は、発明を実施するための形態において以下でさらに説明される、簡略化形態の概念の選択を導入するように提供される。本概要は、請求された主題の主要な特徴または不可欠な特徴を識別することを目的としておらず、また、請求された主題の範囲を限定するために使用されることも目的としていない。さらに、請求された主題は、本開示の任意の部分で記述されるいずれかまたは全ての不利点を解決する制限に限定されない。

類似数字が全体を通して類似要素を示す、添付の図面と併せて、一例として挙げられる、以下の発明を実施するための形態から、より詳細に理解され得る。
本明細書は、例えば、以下を提供する。
（項目１）
ネットワーク内の第１のエンドノード上で実行される第１のアプリケーションが、メッセージを第２のエンドノード上で実行される第２のアプリケーションに伝送し得、上記ネットワークは、上記メッセージを上記第２のアプリケーションに送信するために使用され得る、複数の異なるメッセージトランスポート機構をサポートすることが可能である、通信ネットワークにおいて、
上記第１のエンドノード上で実行される上記第１のアプリケーションから、メッセージを上記第２のエンドノード上で実行される上記第２のアプリケーションに送信する要求を受信するステップであって、上記要求は、上記第２のアプリケーションの一意の識別子を含む、ステップと、
上記第１のアプリケーションについての情報、上記第１または第２のエンドノードについての情報、もしくは伝送される上記メッセージについての情報のうちの少なくとも１つに基づいて、上記ネットワークによってサポートされる上記複数の異なるメッセージトランスポート機構のうちの１つを選択するステップと、
上記選択されたトランスポート機構を使用して、上記メッセージを上記第２のアプリケーションが常駐する上記第２のエンドノードに送信するステップと、
を含む、方法。
（項目２）
上記複数の異なるメッセージトランスポート機構は、ショートメッセージサービス（ＳＭＳ）トランスポート機構、非アクセス層（ＮＡＳ）トランスポート機構、非構造化補足サービスデータ（ＵＳＳＤ）機構、または３ＧＰＰネットワークのユーザプレーントランスポート機構を備える、項目１に記載の方法。
（項目３）
上記第１および第２のエンドノードのそれぞれは、Ｍ２ＭまたはＭＴＣデバイスもしくはゲートウェイ、マシン、センサ、アプライアンス、移動局、固定または移動加入者ユニット、ポケットベル、携帯情報端末、コンピュータ、携帯電話、スマートフォン、サービス能力サーバ（ＳＣＳ）、Ｍ２Ｍサーバ、ＭＴＣサーバ、サービス能力層（ＳＣＬ）、共通サービスエンティティ（ＣＳＥ）、もしくはアプリケーションサーバ（ＡＳ）のうちの１つを備え得る、項目１に記載の方法。
（項目４）
上記方法のステップは、上記第１のエンドノード上で実行される論理エンティティによって行われる、項目１に記載の方法。
（項目５）
上記方法のステップは、コアネットワークノード上で実行される論理エンティティによって行われる、項目１に記載の方法。
（項目６）
上記第１のアプリケーションについての上記情報は、メッセージ率、サービス品質要件、遅延耐性、アプリケーション可用性、および許容メッセージ損失率のうちの１つまたはそれを上回るものを含む、項目１に記載の方法。
（項目７）
上記メッセージについての上記情報は、メッセージサイズおよびメッセージ重要性のうちの１つまたはそれを上回るものを含む、項目１に記載の方法。
（項目８）
上記第１もしくは第２のエンドノードについての上記情報は、エンドノード能力およびエンドノード可用性のうちの１つまたはそれを上回るものを含む、項目１に記載の方法。
（項目９）
複数の異なるメッセージトランスポート機構をサポートするネットワーク接続の要求を上記第１のエンドノードから送信するステップをさらに含む、項目１に記載の方法。
（項目１０）
複数の異なるメッセージトランスポート機構をサポートするネットワーク接続の上記要求は、ＮＡＳメッセージの中に指示アクセスポイント名（ＡＰＮ）または要求フラグを含むことによって、上記ネットワークに示される、項目９に記載の方法。
（項目１１）
プロセッサと、メモリとを備える、ネットワークノードであって、上記ネットワークノードは、ネットワーク内のエンドノード上で実行されるアプリケーションの間でメッセージを送信するために使用され得る、複数の異なるメッセージトランスポート機構をサポートする通信ネットワークに接続され、上記ネットワークノードの上記メモリは、上記ネットワークノードの上記プロセッサによって実行されたときに、上記ネットワークノードに、
第１のアプリケーションから、メッセージを上記通信ネットワークのエンドノード上で実行される第２のアプリケーションに送信する要求を受信するステップであって、上記要求は、上記第２のアプリケーションの一意の識別子を含む、ステップと、
上記第１のアプリケーションについての情報、上記第２のアプリケーションが常駐する上記エンドノードについての情報、もしくは伝送される上記メッセージについての情報のうちの少なくとも１つに基づいて、上記ネットワークによってサポートされる上記複数の異なるメッセージトランスポート機構のうちの１つを選択するステップと、
上記選択されたトランスポート機構を使用して、上記メッセージを上記第２のアプリケーションが常駐する上記エンドノードに送信するステップと、
を含む、ステップを行わせる、コンピュータ実行可能命令を記憶する、
ネットワークノード。
（項目１２）
上記複数の異なるメッセージトランスポート機構は、ショートメッセージサービス（ＳＭＳ）トランスポート機構、非アクセス層（ＮＡＳ）トランスポート機構、非構造化補足サービスデータ（ＵＳＳＤ）機構、または３ＧＰＰネットワークのユーザプレーントランスポート機構を備える、項目１１に記載のネットワークノード。
（項目１３）
上記ネットワークノードは、Ｍ２ＭまたはＭＴＣデバイスもしくはゲートウェイ、マシン、センサ、アプライアンス、移動局、固定または移動加入者ユニット、ポケットベル、携帯情報端末、コンピュータ、携帯電話、スマートフォン、サービス能力サーバ（ＳＣＳ）、Ｍ２Ｍサーバ、ＭＴＣサーバ、サービス能力層（ＳＣＬ）、共通サービスエンティティ（ＣＳＥ）、もしくはアプリケーションサーバ（ＡＳ）のうちの１つを備える、項目１１に記載のネットワークノード。
（項目１４）
上記第１のアプリケーションは、上記ネットワークノード上で実行される、項目１１に記載のネットワークノード。
（項目１５）
上記ネットワークノードは、コアネットワークノードを備える、項目１１に記載のネットワークノード。
（項目１６）
上記第１のアプリケーションについての上記情報は、メッセージ率、サービス品質要件、遅延耐性、アプリケーション可用性、および許容メッセージ損失率のうちの１つまたはそれを上回るものを含む、項目１１に記載のネットワークノード。
（項目１７）
上記メッセージについての上記情報は、メッセージサイズおよびメッセージ重要性のうちの１つまたはそれを上回るものを含む、項目１１に記載のネットワークノード。
（項目１８）
上記第２のアプリケーションが常駐する上記エンドノードについての上記情報は、エンドノード能力およびエンドノード可用性のうちの１つまたはそれを上回るものを含む、項目１１に記載のネットワークノード。
（項目１９）
上記ネットワークによってサポートされる上記複数の異なるメッセージトランスポート機構のうちの１つを選択するステップはさらに、上記ネットワークノードについての上記情報に基づく、項目１１に記載のネットワークノード。
（項目２０）
上記コンピュータ実行可能命令はさらに、上記ネットワークノードに、複数の異なるメッセージトランスポート機構をサポートするネットワーク接続の要求を送信させる、項目１１に記載のネットワークノード。
（項目２１）
複数の異なるメッセージトランスポート機構をサポートするネットワーク接続の上記要求は、ＮＡＳメッセージの中に指示アクセスポイント名（ＡＰＮ）または要求フラグを含む、上記ネットワークノードによって、上記ネットワークに示される、項目２０に記載のネットワークノード。

図１は、３ＧＰＰコアネットワークアーキテクチャの基本アーキテクチャ図である。 図２は、３ＧＰＰマシン型通信（ＭＴＣ）アーキテクチャのブロック図である。 図３は、その一実施形態による、ＡＤＤクライアントおよびＡＤＤＳエンティティを含む、新しいアプリケーションデータ配信サービス（ＡＤＤＳ）のアーキテクチャの高レベル概観を表す、ブロック図である。 図４Ａは、ＡＤＤＳエンティティがコアネットワーク内で別個の論理ノードとして実装される、ＡＤＤＳの一実施形態を図示する、ブロック図である。 図４Ｂは、ＡＤＤＳエンティティが３ＧＰＰ ＭＴＣ−ＩＷＦと一緒に配置される、実施形態を図示する。 図４Ｃは、ＡＤＤＳエンティティが３ＧＰＰ ＰＧＷの一部として統合される、実施形態を図示する。 図４Ｄは、ＡＤＤＳエンティティがサービスドメインの一部であり、３ＧＰＰネットワークオペレータにとって外部エンティティであり得る、別の実施形態を図示する。 図４Ｅは、ＡＤＤＳエンティティが３ＧＰＰ ＩＰマルチメディアサブシステム（ＩＭＳ）アプリケーションサーバ（ＡＳ）として実装される、さらに別の実施形態を図示する。 図５は、ＡＤＤＳクライアントおよびＡＤＤＳクライアントを利用するアプリケーションが同一のエンドノード内に常駐するときのＡＤＤＳクライアントのアーキテクチャの一実施形態を図示する。 図６は、ＡＤＤＳクライアントが、ＡＤＤＳクライアントがホストされるエンドノードと異なる物理デバイス上で作動するアプリケーションとインターワーキングする、ＡＤＤＳクライアントのアーキテクチャの別の実施形態を図示する。 図７は、ＵＥへのＡＤＤＳ広告のための方法の一実施形態を図示する。 図８は、ＵＥへのＡＤＤＳ広告のための方法の別の実施形態を図示する。 図９は、ＵＥへのＡＤＤＳ広告のための方法のさらに別の実施形態を図示する。 図１０は、ＳＣＳへのＡＤＤＳ広告のための方法の一実施形態を図示する。 図１１Ａは、ＮＡＳを経由したＡＤＤＳメッセージ転送のためのプロトコルスタックを示す。 図１１Ｂは、ユーザプレーンを経由したＡＤＤＳメッセージ転送のためのプロトコルスタックを示す。 図１１Ｃは、ＳＭＳを使用するＡＤＤＳメッセージ転送のためのプロトコルスタックを示す。 図１１Ｄは、ＵＳＳＤを使用するＡＤＤＳメッセージ転送のためのプロトコルスタックを示す。 図１２は、その一実施形態による、ＡＤＤＳメッセージの形式を図示する。 図１３は、その一実施形態による、アプリケーション登録の方法のための例示的呼び出しフローを示す。 図１４は、エンドノードまたはネットワークがＡＤＤＳ更新プロシージャを開始して行う、プロセスの実施形態を図示する。 図１５は、一実施形態による、ＡＤＤＳデータ転送プロセスを図示するフロー図である。 図１６は、その一実施形態による、ＡＤＤＳイベント加入のための方法を図示する。 図１７は、エンドノードによって、またはネットワークによって開始される、アプリケーション登録解除のための方法の実施形態を図示する。 図１８は、ＡＤＤＳクライアントが常駐し得る、例示的エンドノードの略図である。 図１９は、ＡＤＤＳエンティティまたはＡＤＤＳクライアントが実装され得る、任意のノードを含む、図１−１７に図示されるコアネットワークノードもしくはエンドポイントのうちのいずれかを実装するために使用され得る、コンピュータシステムまたはサーバのブロック図である。

（ＡＤＤＳアーキテクチャ）
図３は、その一実施形態による、新しいアプリケーションデータ配信サービス（ＡＤＤＳ）のアーキテクチャの高レベル概観を表す、ブロック図である。本実施形態では、ＡＤＤＳは、３ＧＰＰコアネットワーク（すなわち、ＥＰＣ）１０２内に配置されるＡＤＤＳエンティティ３２２、およびシステム３００内のデータ転送のためにＡＤＤＳを使用し得る種々のエンドノード上でホストされる複数のＡＤＤＳクライアント３２４によって、実装される。ＡＤＤＳを使用し得るエンドノードは、ＵＥ３１２および３１８等のユーザ機器（ＵＥ）、ならびにＳＣＳ（サービス能力サーバ）３０６またはＡＳ（アプリケーションサーバ）３０８もしくは３１０等のネットワークエンティティを含む。

ＵＥは、例えば、マシン、センサ、アプライアンス、または同等物を含む、Ｍ２ＭもしくはＭＴＣデバイスまたはゲートウェイ、移動局、固定または移動加入者ユニット、ポケットベル、携帯情報端末（ＰＤＡ）、コンピュータ、携帯電話またはスマートフォン、もしくは有線または無線環境で動作することが可能な任意の他のタイプのデバイス等の、３ＧＰＰまたは他の無線ネットワーク内で通信することが可能な任意の無線デバイスを備えてもよい。ＵＥの例示的アーキテクチャが、図１８に関連して以下で説明される。ＳＣＳまたはＡＳ（例えば、ＡＳ３０８、３１０のＳＣＳ３０６）は、図１９に関連して以下で説明される例示的コンピュータシステムまたはサーバ等のコンピュータシステムまたはサーバ上で実装されてもよい。

一実施形態では、ＡＤＤＳクライアント３２４は、ＵＥ、ＳＣＳ、またはＡＳのメモリに記憶され得、そのデバイスのプロセッサ上で実行され得る、論理エンティティ（例えば、ソフトウェア）である。しかしながら、他の実施形態では、ＡＤＤＳクライアントは、完全にハードウェアで、またはハードウェアおよびソフトウェアの任意の組み合わせで、実装されてもよい。ＵＥ上のＡＤＤＳクライアント３２４は、ＵＥ上で（例えば、ＵＥ３１２上で作動するＡｐｐ３およびＡｐｐ４、またはＵＥ３１８上で作動するＡｐｐ５およびＡｐｐ６）、またはネットワーク内のデータ転送のためにＡＤＤＳを使用することを希望する別のデバイス上で作動するアプリケーション（例えば、デバイス３１４上で作動するＡｐｐ１およびＡｐｐ２）とインターワーキングする。同様に、ＳＣＳ（例えば、ＳＣＳ３０６）上でホストされるＡＤＤＳクライアント３２４は、ＳＣＳ上で作動するアプリケーション（例えば、ＳＣＳ Ａｐｐ）またはＳＣＳと通信するＡＳ上で作動するアプリケーション（例えば、ＡＳ３０８上で作動するＡｐｐ１およびＡｐｐ２）とインターワーキングしてもよい。さらに示されるように、ＡＤＤＳクライアント３２４は、ＡＳ上でホストされ、そのＡＳ上で作動するアプリケーション（例えば、ＡＳ３１０上で作動するＡｐｐ３およびＡｐｐ４）と直接インターワーキングしてもよい。さらに示されるように、ＵＥ上で作動するＡＤＤＳクライアント３２４は、ＥＰＣ１０２内のＡＤＤＳエンティティ３２２と通信するように、３ＧＰＰアクセスネットワーク３１６または非３ＧＰＰアクセスネットワーク３２０のいずれか一方を使用することができる。

ＡＤＤＳエンティティ３２２はまた、ＥＰＣ１０２内の独立型ノードまたはサーバ上で、もしくは既存のノードまたはサーバの一部として実行される、論理エンティティ（例えば、ソフトウェア）として実装されてもよい。この点に関する種々の実施形態は、以下でさらに完全に議論される。ＳＣＳ、ＡＳ、またはＥＰＣ１０２内の任意のノードもしくはエンティティのように、ＡＤＤＳエンティティ３２２はまた、図１９に関連して以下で説明されるもの等のコンピュータシステムまたはサーバ上で実装されてもよい。

一般に、ＡＤＤＳは、アプリケーションメッセージ交換のためのゲートウェイの役割を果たし、ネットワークを通したデータの最適化された転送を可能にする。ＡＤＤＳは、アプリケーション層が、アプリケーションの特性および転送されているデータの特性を提供することを可能にし、次いで、それらの特性は、データを配信するための最適なトランスポート機構（例えば、ＳＭＳ、ＮＡＳ、ＵＳＳＤ、ユーザプレーン等）を選択する際に、ＡＤＤＳエンティティによって使用されてもよい。エンドノード内に常駐するＡＤＤＳクライアント３２４は、それがサービス提供するアプリケーションをネットワーク内のＡＤＤＳエンティティ３２２に登録し、これらのアプリケーションおよびエンドノードデバイスの特性をＡＤＤＳエンティティ３２２にパスする。ＡＤＤＳクライアント３２４は、アプリケーション、それらの状態および特性を記録する。図３に図示されるように、アプリケーションおよびＡＤＤＳクライアント３２４は、同一の物理デバイス上に共存する必要はない。例えば、Ｍ２Ｍネットワークでは、アプリケーションは、Ｍ２Ｍデバイス（例えば、図３のデバイス３１４）上で作動するデバイスアプリケーション（ＤＡ）であってもよく、ＡＤＤＳクライアント３２４は、Ｍ２Ｍデバイスにサービス提供するＭ２Ｍゲートウェイ（例えば、図３のＵＥ３１２）上に常駐してもよい。ダウンリンク方向では、ＡＤＤＳクライアント３２４は、受信されたメッセージを正しいアプリケーションに転送する責任がある。アップリンク方向では、ＡＤＤＳクライアント３２４は、ネットワークＡＤＤＳエンティティ３２２によって提供されるポリシー／命令に基づいて、メッセージを送信する適切なトランスポート機構（ＳＭＳ、ＮＡＳ、ユーザプレーン等）を選定するであろう。

ＡＤＤＳエンティティ３２２は、所与のＡＤＤＳクライアント３２４とのアプリケーションの関連を追跡して維持し、アプリケーションのためのメッセージを適切なＡＤＤＳクライアント３２４に送る。記述されるように、ＡＤＤＳクライアント３２４は、メッセージを適切なアプリケーションに送る。一実施形態では、ＡＤＤＳは、ＡＤＤＳ内の各アプリケーションを一意に識別するように、本明細書ではアプリケーションＩＤと称される一意の識別子をそのアプリケーションに割り当てる。

したがって、ＡＤＤＳは、データ通信の手段であり、その通信必要性のために、（Ｍ２Ｍネットワーク内のＳＣＳのように）サービス層内または（Ｍ２Ｍネットワーク内のＮＡまたはＡＳのように）アプリケーション層内の任意のアプリケーション／エンティティによって使用されることができる。アプリケーションＩＤが公知である限り、任意のエンティティは、送信アプリケーション／エンドノードがそうする権限を与えられ、ＡＤＤＳクライアント３２４にインターフェース接続される限り、メッセージをそのアプリケーションに送信することができる。ＡＤＤＳは、主にＭ２Ｍ／ＭＴＣ通信との関連で本明細書に説明され得るが、ＡＤＤＳは、そのような通信に限定されないが、非Ｍ２Ｍアプリケーションおよびノードによっても使用され得ることが理解される。例えば、ＡＤＤＳは、ＵＥ上で作動するアプリケーションとネットワーク側の外部アプリケーションサーバ上のアプリケーションと、１つのＵＥ上で作動するアプリケーションと他のＵＥ上で作動するアプリケーションと、およびネットワーク側のサーバ／ノード上のアプリケーションと他のサーバ／ノード上の他のアプリケーションとの間の通信のために使用されてもよい。

上記のように、ＡＤＤＳエンティティは、論理的であり、別個のエンティティとして実装されることができ、または３ＧＰＰ ＭＴＣアーキテクチャ内のＰＧＷもしくはＭＴＣ−ＩＷＦ等の他のネットワークノードの機能的部分としてマージされることができる。種々の代替案が、以下で説明される。ＡＤＤＳは、３ＧＰＰ制御プレーンまたはユーザプレーンパスを経由してメッセージを転送することができるため、（ＭＭＥ、ＨＳＳ等のような）制御プレーンノードおよび（ＰＧＷのような）ユーザプレーンノードの両方と通信してもよく、したがって、以下で説明される種々の代替案は、どのようにしてＡＤＤＳエンティティ３２２が、ユーザプレーンおよび制御プレーンの両方において異なる方法で統合され得るかを例証する。

図４Ａは、ＡＤＤＳエンティティ３２２がコアネットワーク内で別個の論理ノードとして実装される、ＡＤＤＳの一実施形態を図示する、ブロック図である。ｅＮｏｄｅＢ１０６、ＳＧＷ１１０、ＰＧＷ１１２、ＭＭＥ１１４、ＨＳＳ１１６、ＳＭＳ−ＳＣ２０４、ＭＴＣ−ＩＷＦ２１０、およびＭＳＣ２３８を含む、図４Ａに図示されるコアネットワークノードの大部分は、上記で説明され、また、図１および／または２に図示される。図４Ａは、３つの付加的コアネットワークノード、すなわち、オンライン課金システム（ＯＣＳ）３３０、オフライン課金システム（ＯＦＣＳ）３３２、ならびにポリシーおよび課金規則機能（ＰＣＲＦ）３３４を導入する。

ＯＣＳ３３０、ＯＦＣＳ３３２、およびＰＣＲＦ３３４は、ネットワーク内で課金および請求する責任がある、コアネットワーク内の論理エンティティ／機能である。それらは、次いで、適切な課金および請求システムに転送される、課金情報の生成ならびに収集を取り扱う。オンライン課金とは、課金情報がレンダリングされるサービスにリアルタイムで影響を及ぼし得る、機構を指す。オフライン課金とは、課金情報がレンダリングされるサービスにリアルタイムで影響を及ぼさない、機構を指す。ＯＣＳ３３０は、オンライン課金のためにリアルタイムクレジット制御を行う、エンティティである。その機能性は、トランザクション取扱、評定、オンライン相関、および加入者アカウント／残高の管理を含む。ＯＦＣＳ３３２が、オンライン課金機能を取り扱う一方で、ＯＦＣＳ３３２は、請求システムへの配信に先立ってオフライン課金情報を収集して処理する、エンティティである。ＰＣＲＦ３３４は、ＰＧＷ１１２とインターワーキングし、それの代わりに課金実施決定を行う。これは、ネットワークオペレータのためのポリシー決定点の役割を果たすことができる。例えば、サービスプロバイダは、高帯域幅アプリケーションのそれらの使用量に基づいて、加入者に課金し、ＱｏＳ保証のために余分に課金し、ユーザがローミングしている間にアプリケーション使用を制限し、またはピーク使用時間中に大量帯域幅アプリケーションを使用して無線加入者の帯域幅を低下させるために、ＰＣＲＦ３３４を使用することができる。

ＡＤＤＳエンティティ３２２がコアネットワーク内の独立型エンティティである、図４Ａに図示される実施形態では、ＡＤＤＳエンティティ３２２は、新たに定義された基準点、すなわち、ＡＤ１、ＡＤ２、ＡＤ３、ＡＤ４、ＡＤ５、ＡＤ６、ＡＤ７、ＡＤ８、ＡＤ９、ＡＤ１０、およびＡＤ１１を介して、他のコアネットワークエンティティ、ならびにＳＣＳまたはＡＳ３４０等の外部エンティティとインターワーキングする。本実施形態では、これらの基準点は、ネットワーク内のＡＤＤＳ機能性を有効にするための専用インターフェースである。各基準点は、以下でさらに詳細に説明される。

図４Ａに図示される実施形態では、ＳＣＳまたはＡＳ３４０等の任意の外部ノードが、ＡＤＤＳサービスを使用するためにＡＤＤＳエンティティ３２２に接続するであろう。ＡＤＤＳエンティティ３２２は、メッセージをＵＥ（例えば、ＵＥ３３８）に送信および受信するであろう。別個のプライベートパケットデータネットワーク（ＰＤＮ）３４２が、ＡＤＤＳエンティティ３２２とＰＧＷ１１２との間の通信のために、モバイルネットワークオペレータ（ＭＮＯ）によって使用されてもよい。

単一のＡＤＤＳエンティティ３２２が図４Ａに図示されているが、他の実施形態では、複数の別個にアドレス可能なＡＤＤＳエンティティ（図示せず）があり得る。これは、オペレータが、パケットデータネットワーク基準で、または加入者のサブセットへ、ＡＤＤＳ機能性を有効にすることを可能にし得る。

図４Ｂ−４Ｅは、ＡＤＤＳエンティティ３２２が、他のコアネットワークノードと統合され、またはＥＰＣへの外部エンティティとしてサービスドメインの一部として配置される、他の実施形態を図示する。これらの他の代替実施形態では、本明細書で定義される新しい基準点（ＡＤ１−ＡＤ１１）は、既存の基準点にマージまたはマップされ得る。図４Ｂ−４Ｅのそれぞれの略図は、どの既存の基準点が、ＡＤＤＳサービスのために本明細書で定義される新しい基準点にマージまたはマップされ得るかを示す。

図４Ｂは、ＡＤＤＳエンティティ３２２がＭＴＣ−ＩＷＦ１１０と一緒に配置される、実施形態を図示する。すなわち、ＡＤＤＳエンティティ３２２の論理機能は、ＭＴＣ−ＩＷＦ１１０の論理機能を実装する、同一のコンピュータシステムまたはサーバ上で実装される。ＡＤＤＳエンティティ３２２が、ＳＣＳまたはＡＳ３４０内のＡＤＤＳクライアント３２４にインターフェース接続するために使用する、ＡＤ１基準点（プロトコルおよびプロシージャ）は、３ＧＰＰ Ｔｓｐインターフェースにマップし、またはそれと統合されてもよく、ＡＤ１基準点の情報要素（ＩＥ）は、その実施形態では、Ｔｓｐおよび他の既存の３ＧＰＰ基準点を横断してメッセージを伝送するために使用されるプロトコルである、Ｄｉａｍｅｔｅｒプロトコルを使用して、属性値ペア（ＡＶＰ）として転送されることができる。本実施形態は、ＭＴＣ−ＩＷＦ２１０が、ＨＳＳ１１６、ＳＣＳ、またはＡＳ３４０、およびその他のような他のノードとすでに有しているインターフェースが、ＡＤＤＳ機能性をサポートするように増進されることができるため、有利であり得る。例えば、ＡＤ６インターフェースは、３ＧＰＰ Ｓ６ｍインターフェースにマップしてもよく、ＡＤ５インターフェースは、３ＧＰＰ Ｔ５インターフェースにマップしてもよく、ＡＤ４インターフェースは、３ＧＰＰ Ｔ４インターフェースにマップしてもよい。

図４Ｃは、ＡＤＤＳエンティティ３２２がＰＧＷ１１２の一部として統合される、実施形態を図示する。本実施形態は、特定のＰＤＮ上のＡＳ／ＳＣＳおよびその特定のＰＤＮに接続するＵＥのみが、ＡＤＤＳサービスを使用することを可能にするように、ネットワークオペレータが、ＰＤＮ基準でＡＤＤＳ機能性を有効にしたい場合に、有利であり得る。例えば、示されるように、ネットワークオペレータは、ＡＤＤＳエンティティ３２２の１つのインスタンスが、外部ＰＤＮ３４６ａにサービス提供するＰＧＷ１１２ａと通信することを可能にし得、オペレータは、ＡＤＤＳエンティティ３２２の第２のインスタンスが、外部ＰＤＮ３４６ｂにサービス提供するＰＧＷ１１２ｂと通信することを可能にし得る。外部ネットワーク３４６ａ上のＳＣＳ／ＡＳ３４０ａのみが、ＰＧＷ１１２ａ上のＡＤＤＳエンティティによって提供されるＡＤＤＳサービスを使用することができる。同様に、ＳＣＳ／ＡＳ３４０ｂのみが、ＰＧＷ１１２ｂ上のＡＤＤＳエンティティによって提供されるＡＤＤＳサービスを使用することができる。

また、図４Ｃでは、ＨＳＳ１１６が、加入プロファイルレポジトリ（ＳＰＲ）またはユーザデータレポジトリ（ＵＤＲ）であり得る、論理エンティティ３５２と置換されることに留意されたい。ＳＰＲ３５２は、ＰＣＲＦ３３４による加入ベースのポリシーおよびベアラレベル課金規則のために必要とされる、全ての加入者／加入関連情報を含有する、３ＧＰＰ論理エンティティである。ＵＤＲは、３ＧＰＰアーキテクチャに近年導入された、より新しい概念である。現在、加入者データは、いくつかの異なるエンティティ内に常駐することができる。ＨＳＳは、加入者データが記憶される、最も周知のエンティティのうちの１つであるが、加入者データはまた、ＳＰＲおよびＵＤＲ等の場所に記憶されることもできる。ＵＤＲの背景にある発想は、全ての加入者情報が１つのスポット（ＵＤＲ）に記憶されることである。ＵＤＲは、加入者データにアクセスするために使用されることができる、単一のインターフェース（Ｕｄ）を提示するであろう。本実施形態では、ＰＣＲＦ３３４（Ｇｘ）、加入プロファイルレポジトリ（ＳＰＲ）３５２（Ｓｐ）、およびＵＤＲ（Ｕｄ）とのＰＧＷの既存のインターフェースは、ＡＤＤＳ機能性を提供するように増進されてもよい。ＯＦＣＳ３３２およびＯＣＳ３３０とのＰＧＷの既存のインターフェースもまた、ＡＤＤＳをサポートするように増進されることもできる。また、本実施形態では、別個のプライベートＰＤＮは、必要ではなくてもよい。

図４Ｄは、ＡＤＤＳエンティティ３２２がサービスドメインの一部であり、３ＧＰＰネットワークオペレータにとって外部エンティティであり得る、別の実施形態を図示する。図４Ｄでは、ＡＤＤＳエンティティ３２２は、サービスドメイン内の別個のエンティティであるが、ＳＣＳの一部として実装されることができる。ＡＤＤＳエンティティ３２２は、本実施形態では、既存の３ＧＰＰ Ｔｓｐ、Ｍｈ、Ｍｏ、Ｍｆ、Ｒｘ、およびＳＧｉ／Ｇｉインターフェースを使用して、コアネットワークと相互作用することができる。ＭｈおよびＴｓｐインターフェースは、（ＡＤ４と同様に）デバイス構成、監視および報告、加入情報の受信、デバイストリガ等に使用されてもよい。Ｒｘインターフェースは、（ＡＤ３と同様に）ポリシー情報を提供および受信するために使用されてもよい。

図４Ｅは、ＡＤＤＳエンティティが３ＧＰＰ ＩＰマルチメディアサブシステム（ＩＭＳ）アプリケーションサーバ（ＡＳ）として実装される、さらに別の実施形態を図示する。本実施形態では、Ｓ−ＣＳＣＦ３５４、ＨＳＳ１１６、ＯＦＣＳ３３２、ＯＣＳ３３０、およびＰＣＲＦ３３４へのＡＳ３２２の接続が、それぞれ、ＡＤ１１、ＡＤ６、ＡＤ９、ＡＤ８、およびＡＤ３基準点を展開するために使用されてもよい。Ｓ−ＣＳＣＦ（サービング呼び出しセッション制御機能）は、信号通信プレーンの中心ノードとしての機能を果たす、３ＧＰＰ ＩＭＳネットワークアーキテクチャ内の論理エンティティである。これは、セッション開始プロトコル（ＳＩＰ）サーバであるが、セッション制御も行う。これは、ＨＳＳにインターフェース接続して、ユーザプロファイルをダウンロードし、ユーザとＳ−ＣＳＣＦの関連をアップロードするために、ＤｉａｍｅｔｅｒプロトコルのＣｘおよびＤｘインターフェースを使用する。全ての必要な加入者プロファイル情報が、ＨＳＳからロードされる。

図４Ｅの実施形態では、ＵＥ２１４とＩＭＳ ＡＳ３２２’との間のＨＴＴＰベースのＵｔ基準点が、ＩＭＳ ＡＳ３２２’内のＡＤＤＳエンティティのＡＤ１基準点のためのデータプレーン通信を搬送するために使用されてもよい。ＩＳＣ／ＡＤ１１基準点は、ＳＩＰメッセージングを介してメッセージをＡＤＤＳクライアント３２４に送信するために、ＩＭＳ ＡＳ３２２’によって使用されてもよい。

（ＡＤＤＳ基準点）
図３および４Ａ−Ｅに図示されるように、ＡＤＤＳサービスは、新しい基準点（すなわち、インターフェース）ＡＤ１−ＡＤ１１の定義を備える。基準点およびインターフェースという用語は、本明細書では同意語として使用される。各基準点／インターフェースは、以下でさらに説明される。

ＡＤ１−ＡＤ１基準点は、エンドノード上のＡＤＤＳクライアント３２４とＥＰＣ内のＡＤＤＳエンティティ３２２との間に常駐する。ＡＤＤＳ制御およびデータメッセージは、本基準点を経由して転送される。本基準点上のＡＤＤＳメッセージは、３ＧＰＰネットワーク制御プレーンまたはユーザプレーンを経由してトランスポートされてもよい。本基準点は、とりわけ、（１）アプリケーションをＡＤＤＳエンティティに登録／登録解除する、（２）アプリケーションペイロードをトランスポートする、（３）アプリケーション関連イベントに加入する、ならびに（４）エンドノード能力、状態情報、スケジュール、および通信要件を更新するために使用されてもよい。

ＡＤ２−ＡＤ２基準点は、エンドノード上のアプリケーションとそのエンドノード上のＡＤＤＳクライアント３２４との間に常駐する。本インターフェースは、アプリケーションがＡＤＤＳ機能性を利用することを可能にする。例えば、本基準点は、（１）ＡＤＤＳエンティティに登録する、（２）アプリケーション特性をプロビジョニングする、および（３）アプリケーションデータをＡＤＤＳクライアント３２４に送信／から受信するために、アプリケーションによって使用されてもよい。

ＡＤ３−ＡＤ３基準点は、ＡＤＤＳエンティティ３２２とＥＰＣ内のＰＣＲＦ３３４との間に常駐する。本基準点は、（１）ＰＣＲＦからエンドノードまたはアプリケーションのためのポリシーを要求する、（２）アプリケーションおよび通信セッション特性をＰＣＲＦに提供する、ならびに（３）課金特性に関係付けられる情報を受信するために、ＡＤＤＳエンティティ３２２によって使用されてもよい。一実施形態では、ＡＤ３インターフェースは、例えば、図４Ｄの実施形態に示されるように、ＡＤＤＳエンティティ３２２がＥＰＣの外側に配置される場合に、３ＧＰＰ Ｒｘ基準点に基づいてもよい。またはこれは、図４Ｃの実施形態に示されるように、ＡＤＤＳエンティティ３２２がＰＧＷ１１２と統合される場合に、３ＧＰＰ Ｇｘインターフェースに基づき得る。

ＡＤ４−ＡＤ４基準点は、ＡＤＤＳエンティティ３２２と３ＧＰＰ ＳＭＳ−ＳＣ２０４との間に常駐する。本基準点は、ＥＰＣ内のＳＭＳトランスポート機構／パスを使用して、ＵＥ（例えば、ＵＥ２１４）上のＡＤＤＳクライアント３２４と通信するために、ＡＤＤＳエンティティ３２２によって使用されてもよい。本インターフェースの機能性は、上記で説明されるＡＤ１インターフェースに類似するが、実装される基礎的トランスポート機構は、ＳＧｉ／Ｇｉユーザプレーンパスの代わりにＳＭＳであってもよい。ＡＤ４インターフェースは、一実施形態では、３ＧＰＰ Ｔ４インターフェースに基づいてもよい。

ＡＤ５−ＡＤ５基準点は、ＡＤＤＳエンティティ３２２とＭＭＥ１１４との間に常駐する。本基準点は、ＮＡＳまたはＲＲＣトランスポート機構を経由してＵＥ２１４上のＡＤＤＳクライアント３２４と通信するために、ＡＤＤＳエンティティ３２２によって使用されてもよい。本インターフェースの機能性は、上記で説明されるＡＤ１インターフェースに類似するが、基礎的トランスポートプロトコルは、ＳＧｉ／Ｇｉユーザプレーンパスの代わりにＮＡＳまたはＲＲＣ制御プレーンであろう。一実施形態では、ＡＤ５インターフェースは、Ｔ５ｂインターフェースに基づいてもよい。

ＡＤ６−ＡＤ６基準点は、ＡＤＤＳエンティティ３２２とＨＳＳ１１６との間に常駐する。同一の基準点はまた、例えば、図４Ｃの実施形態に示されるように、ＳＰＲまたはＵＤＲ３５２がＨＳＳ１１６の代わりにコアネットワークで使用される場合に、使用されてもよい。本基準点は、（１）エンドノードおよびＵＥの加入情報を要求する、（２）ユーザの加入情報の変更についての通知を受信する、（３）デバイス監視情報およびデバイス特性をプロビジョニングする、（４）デバイス状態および能力についての更新を受信する、（５）ＡＤＤＳ情報および能力をプロビジョニングして、以降で説明されるＡＤＤＳ広告プロシージャ中に、ＨＳＳ／ＳＰＲ／ＵＤＲが本情報をＭＭＥに提供することを可能にするために、ＡＤＤＳエンティティ３２２によって使用されてもよい。一実施形態では、ＡＤ６は、ＨＳＳ１１６がコアネットワークで使用される場合に、Ｍｈインターフェースの３ＧＰＰ Ｓ６ｍにマップされてもよい。代替として、ＡＤ６インターフェースは、ＵＤＲがコアネットワークで使用される場合に、３ＧＰＰ Ｕｄインターフェースにマップされてもよく、または（図４Ｃに示されるように）ＳＰＲが使用される場合に、Ｓｐインターフェースにマップされてもよい。別の実施形態では、ＡＤＤＳエンティティ３２２は、３ＧＰＰ ＴＳ ２３．３３５で定義されるように、アプリケーションフロントエンドの役割を果たし、上記の用途を達成するようにＵＤＲとのＵｄインターフェースを有してもよい。

ＡＤ７−ＡＤ７基準点は、ＡＤＤＳエンティティ３２２とＭＴＣ−ＩＷＦ２１０との間に存在する。本基準点は、ＡＤＤＳエンティティ３２２が、デバイストリガのように、ＭＴＣ−ＩＷＦ２１０によって提供されるサービスを利用することを可能にする。一実施形態では、ＡＤ７インターフェースは、３ＧＰＰ Ｔｓｐインターフェースに基づいてもよい。

ＡＤ８−ＡＤ８基準点は、ＡＤＤＳエンティティ３２２とＯＣＳ３３０との間に存在する。本基準点は、ＡＤＤＳサービスのオンライン課金をサポートするようにＯＣＳと通信するために、ＡＤＤＳエンティティ３２２によって使用されてもよい。一実施形態では、ＡＤ８インターフェースは、３ＧＰＰ Ｒｏインターフェースに基づいてもよい。

ＡＤ９−ＡＤ９基準点は、ＡＤＤＳエンティティ３２２とＯＦＣＳ３３２との間に存在する。本基準点は、ＡＤＤＳサービスのオフライン課金をサポートするようにＯＦＣＳ３３２と通信するために、ＡＤＤＳエンティティ３２２によって使用されてもよい。一実施形態では、ＡＤ９インターフェースは、Ｒｆインターフェースに基づいてもよい。

ＡＤ１０−ＡＤ１０基準点は、ＡＤＤＳエンティティ３２２とＭＳＣ２３８との間に存在する。本基準点は、非構造化補足サービスデータ（ＵＳＳＤ）トランスポート機構を使用してＵＥ（例えば、ＵＥ２１４）上のＡＤＤＳクライアント３２２と通信するために、ＡＤＤＳエンティティ３２２によって使用されてもよい。本インターフェースの機能性は、上記で説明されるＡＤ１インターフェースに類似するが、基礎的トランスポートプロトコルは、ＳＧｉ／Ｇｉユーザプレーンパスの代わりにＵＳＳＤであろう。一実施形態では、ＡＤ１０インターフェースは、３ＧＰＰ Ｔ５ｃインターフェースに基づいてもよい。

ＡＤ１１−ＡＤ１１基準点は、図４Ｅの実施形態では、ＡＤＤＳ３２２とＩＭＳ Ｓ−ＣＳＣＦ３５４との間に存在する。本基準点は、ＳＩＰメッセージングを介してＵＥ（例えば、ＵＥ２１４）上のＡＤＤＳクライアント３２２と通信するために、ＡＤＤＳエンティティ３２２によって使用されてもよい。本インターフェースの機能性は、上記で説明されるＡＤ１インターフェースに類似する。一実施形態では、ＡＤ１１インターフェースは、３ＧＰＰ ＩＳＣインターフェースに基づいてもよい。

（ＡＤＤＳ機能性）
本節は、ＡＤＤＳサービスがアプリケーション通信を提供する、特徴および機能性を説明する。

（アプリケーション識別子）
ＡＤＤＳサービスの一実施形態では、ＡＤＤＳサービスを使用することを希望するアプリケーション（例えば、図２のＵＥ２１６上で作動するＭＴＣアプリケーション２１６、または図３のＵＥ３１２／３１８、デバイス３１４、ＳＣＳ３０６、ＡＳ３０８、もしくはＡＳ３１０上で作動するＡｐｐ１−Ａｐｐ６）は、一意のアプリケーション識別子（本明細書では「アプリケーションＩＤ」と称されることもある）を割り当てられる。エンドノード上のアプリケーションは、受信アプリケーションのアプリケーション識別子にアドレス指定されるＡＤＤＳメッセージを送信することによって、他のアプリケーションと通信することができる。

アプリケーション識別子は、大域的にアプリケーションを一意に識別するために使用される。ネットワーク内のＡＤＤＳエンティティ３２２は、アプリケーション識別子を割り当て、エンドノードの中に常駐するアプリケーションのリストを維持し、エンドノードＩＭＳＩ、ＩＰアドレス、ＭＳＩＳＤＮ、または同等物等のエンドノードのアドレス指定情報を有する、エンドノードコンテキストを用いてアプリケーション識別子のマッピングを維持する。

メッセージがアプリケーション識別子に送信されるとき、ＡＤＤＳエンティティ３２２は、それが記憶したマッピングテーブルから、アプリケーションが常駐するエンドノードを見出し、エンドノードＩＭＳＩ、ＩＰアドレス、ＭＳＩＳＤＮ、または同等物等のエンドノードのアドレス指定情報を読み出す。エンドノードアドレスは、ＡＤＤＳメッセージを正しいエンドノードに送信するために使用され、アプリケーション識別子は、メッセージを正しい宛先アプリケーションに配信するために、エンドノード内のＡＤＤＳクライアント３２４によって使用される。

したがって、アプリケーションＩＤは、識別目的で使用され、エンドノードアドレスは、ネットワーク内の既存のトランスポート機構のうちの１つを介してＡＤＤＳメッセージを送る目的で使用される。ＡＤＤＳサービスを用いると、アプリケーションは、それが通信することを希望する別のアプリケーションが存在する、エンドノードのアドレスを認識する必要がない。送信アプリケーションは、単純に、メッセージを送信／受信し、ネットワーク内のＡＤＤＳエンティティ３２２にエンドノードアドレス指定情報を維持させるために、その他方のアプリケーションのアプリケーションＩＤを使用してもよい。

一実施形態では、アプリケーション識別子は、以降で説明されるＡＤＤＳアプリケーション登録プロシージャの一部としてネットワークＡＤＤＳエンティティ３２２によって割り付けられる、英数字値である。いくつかの実施形態では、これは、大域的に一意であり得る。加えて、一実施形態では、アプリケーションＩＤの一部は、同一のタイプである、またはグループに属するアプリケーションの共通グループＩＤを前に付けられてもよい。共通グループＩＤは、ＡＤＤＳメッセージがグループＩＤにアドレス指定されることを可能にすることによって、グループ通信に使用されることができる。本実施形態では、ＡＤＤＳエンティティは、メッセージを、それらのアプリケーションＩＤの中の接頭語としてグループＩＤを有する全てのアプリケーションに配信してもよい。

実施形態では、同一のエンドノード内の同一のアプリケーションの異なるインスタンスが、異なるアプリケーション識別子を割り当てられてもよい。加えて、アプリケーション識別子は、アプリケーションと関連付けられ、アプリケーションがそのエンドノード上に常駐する限り、アプリケーションが現在常駐しているエンドノードに一時的にのみリンクされる。本機能性は、以下で説明されるようなアプリケーション移動性をサポートする。

（予約アプリケーション識別子）
別の実施形態では、アプリケーション識別子の範囲が、予約されると見なされてもよい。その実施形態では、ＡＤＤＳエンティティ３２２は、本範囲内のアプリケーション識別子を割り当てなくてもよい。予約アプリケーション識別子は、アプリケーションをＡＤＤＳエンティティ３２２に登録することなく、アプリケーションによって使用されることができる。これらのアプリケーション識別子は、ＡＤＤＳクライアント内のみで一意であり得、大域的に一意ではなくてもよい。予約アプリケーションＩＤは、単独では、ＡＤＤＳメッセージを送信するための宛先アプリケーションＩＤとして使用されることができない。送信エンティティもまた、予約アプリケーション識別子とともに、エンドノードＡＤＤＳクライアント３２４アドレス指定詳細を提供するはずである。

いくつかのアプリケーションは、これらの予約アプリケーションＩＤを利用することができ、エンドノードのためのデフォルトＡＤＤＳメッセージ取扱アプリケーションの役割を果たすことができる。予約アプリケーションＩＤは、アプリケーション発見等のある目的で指定されてもよい。例えば、Ｍ２Ｍデバイスがブートアップされるとき、そのデバイス上で作動するＭ２Ｍアプリケーションは、それが通信する必要があるＳＣＳアプリケーションＩＤを認識しなくてもよいが、ＳＣＳ完全修飾ドメイン名（ＦＱＤＮ）が利用可能であり得る。Ｍ２Ｍデバイスアプリケーションは、メッセージを受信するであろうＳＣＳ上の予約アプリケーションにＡＤＤＳメッセージを送信し、ＳＣＳ上のアプリケーションの詳細を要求Ｍ２Ｍアプリケーションに送信することができる。別の実施例では、Ｍ２ＭデバイスアプリケーションがＡＤＤＳエンティティ３２２に登録し、アプリケーションＩＤを入手し、本アプリケーションＩＤをＳＣＳに伝達したいとき、それは、次いで、Ｍ２ＭデバイスアプリケーションのＡＤＤＳアプリケーションＩＤを習得するためにマークされるＳＣＳ上の予約アプリケーションに、その詳細をＡＤＤＳメッセージとして送信してもよい。

（アプリケーション移動性）
本実施形態では、ＡＤＤＳエンティティ３２２は、アプリケーションが、移動し、または（ＡＤＤＳサービスを提供する）ネットワークにアクセスするそのモードを変更し、ＡＤＤＳサービスを使用して、依然としてその通信を保持することを可能にし得る。本明細書で使用されるように、アプリケーション移動性とは、アプリケーションがネットワークに接続する方法の変化を指す。

例えば、アプリケーションが作動しているエンドノードは、ＥＰＣと接続し、または異なる３ＧＰＰ加入（例えば、異なる３ＧＰＰモデムもしくは異なるＳＩＭカード）を使用するために、Ｗｉ−ＦｉまたはＷｉＭＡＸ等の異なるアクセス技術を使用してもよい。Ｍ２Ｍアプリケーションの場合、アプリケーションをホストするＭ２Ｍデバイスは、３ＧＰＰネットワークを経由してＭ２Ｍサーバに接続する、異なるＭ２Ｍ ＧＷによってサービス提供される別の地域に移動することができる。

実施形態では、ＡＤＤＳサービスは、アプリケーション移動後に、アプリケーションがそれらのアプリケーションＩＤを保持することを可能にすることによって、アプリケーション移動を可能にし得る。ＡＤＤＳエンティティ３２２がアプリケーションＩＤを割り当てるとき、それはまた、セキュリティトークンを提供してもよい。アプリケーション移動の間に、アプリケーションがコアネットワークと接続するために使用するＡＤＤＳクライアント３２４の変更があるとき、アプリケーションとの通信に使用される新しいＡＤＤＳクライアント３２４のアドレス指定情報を更新するように、アプリケーション再登録が行われてもよい。アプリケーションは、前のアプリケーション識別子の再割付を要求し、セキュリティトークンを提供してもよい。次いで、ＡＤＤＳエンティティ３２２は、セキュリティトークンを検証し、同一のアプリケーションＩＤを再び割り付け、そのマッピングテーブルを新しいＡＤＤＳクライアント／エンドノードの詳細で更新してもよい。

（ストアアンドフォワード）
別の実施形態では、ＡＤＤＳサービスは、ストアアンドフォワード機能性を提供してもよい。ストアアンドフォワード機能性は、宛先アプリケーションに意図されるメッセージがＡＤＤＳエンティティ３２２に記憶され、次いで、後になって中継される、機構を提供する。メッセージを記憶するＡＤＤＳエンティティ決定は、以下の基準に依存し得る。
（１）アプリケーション特性−アプリケーションがその通信の遅延に耐性があるかどうか。
（３）アプリケーション可用性−宛先アプリケーションは、ＡＤＤＳメッセージを受信するために利用可能ではない場合がある。これは、作動していない場合があり、またはＡＤＤＳから一時的に登録解除され得る。
（３）アプリケーション通知−アプリケーションが、着信ＡＤＤＳメッセージを記憶し、メッセージ指示のみを送信するようにＡＤＤＳエンティティ３２２に通知し得る。さらなる特徴として、ＡＤＤＳエンティティ３２２は、あるサイズを超えるメッセージが以降の配信のために記憶されるべきである一方で、サイズ限界を下回るメッセージが即座に伝送されるであろうことを、アプリケーションが規定することを可能にし得る。
（４）エンドノード特性−エンドノードが、１日の規定時間周期のみにわたってデータ通信のために利用可能であり得る。例えば、ＵＥは、１日のある持続時間のみにわたってＵＥを通信のために利用可能にするであろう、いくつかのＭ２Ｍ特徴に加入していてもよい。
（５）エンドノード到達可能性−エンドノードが、データ通信のために利用可能／到達可能ではない場合がある。それは、ネットワークからデタッチした可能性があり、または無線受信可能範囲地域内にない場合がある。
（６）ネットワーク条件−ネットワークノードは、オーバーロード状態下にあってもよく、またはネットワークノードは、一時的にダウンし、または保守中であり得る。
（７）加入情報−ＨＳＳ１１６／ＵＤＲ３５２からの加入情報
（８）ポリシー規則−ＰＣＲＦ３３４からのポリシーおよび課金規則

（パス選択）
ＡＤＤＳクライアント３２４およびＡＤＤＳエンティティ３２２の顕著な機能のうちの１つは、それらのトランスポート機構／パス選択機能である。本特徴は、ＡＤＤＳメッセージをトランスポートするために３ＧＰＰネットワークに利用可能な種々の既存のトランスポート機構を活用する。例えば、一実施形態では、ＡＤＤＳクライアントとネットワークとの間のＡＤＤＳメッセージは、以下の既存の３ＧＰＰトランスポート機構、すなわち、ショートメッセージサービス（ＳＭＳ）、非アクセス層（ＮＡＳ）、非構造化補足サービスデータ（ＵＳＳＤ）、またはユーザプレーンのうちの選択されたものを使用して、トランスポートされてもよい。上記のトランスポート方法および使用されるプロトコルスタックを経由してＡＤＤＳメッセージをトランスポートするための方法は、以下でさらに完全に説明される。

他の実施形態では、ＡＤＤＳサービスはまた、グループ通信のために３ＧＰＰネットワークで利用可能である、ブロードキャスティングおよびマルチキャスティング機構を採用してもよい。例えば、ＡＤＤＳメッセージが複数の異なるエンドノードに伝送される場合には、以下の機構、すなわち、セルブロードキャストサービス（ＣＢＳ）、マルチメディアブロードキャストマルチキャストサービス（ＭＢＭＳ）、進化型マルチメディアブロードキャストマルチキャストサービス（ｅＭＢＭＳ）、ＩＰマルチキャスティング、および同等物のうちの選択されたものが採用されてもよい。

一実施形態では、以下の基準が、所与のＡＤＤＳメッセージをトランスポートするために使用されるトランスポート機構／パスを選択する際に、ＡＤＤＳクライアント３２４またはＡＤＤＳエンティティ３２２によって使用されてもよい。
（１）メッセージ長−メッセージ長は、選択するトランスポート機構／パスを決定することの重要な要因であってもよい。例えば、メッセージサイズが小さい場合、ＳＭＳパスが使用されてもよく、代替として、メッセージサイズが非常に大きい場合は、ユーザプレーンパスが使用され得る。
（２）メッセージ特性およびアプリケーション特性−ソースアプリケーション（すなわち、メッセージが送信されることを要求するアプリケーション）は、アプリケーションの特性ならびにメッセージの特性を提供してもよく、これらの特性は、パス選択においてＡＤＤＳクライアント３２４またはＡＤＤＳエンティティ３２２によって考慮されてもよい。例えば、メッセージ率、サービス品質（ＱｏＳ）要件、メッセージの重要性（例えば、高い重要性または低い重要性）、利用可能な識別子、および同等物等のアプリケーションまたはメッセージ特性が、使用される適切なトランスポート機構／パスを決定する際にＡＤＤＳクライアント３２４もしくはＡＤＤＳエンティティ３２２によって使用されてもよい。
（４）エンドノード能力および可用性−エンドノードは、いくつかのトランスポートパスのみをサポートすることが可能であり得る。例えば、ＬＴＥ ＵＥは、ＵＳＳＤトランスポート機構をサポートしなくてもよく、ＳＣＳは、ＩＰパス（すなわち、ユーザプレーン）通信のみをサポートしてもよい。これらの制限は、所与のＡＤＤＳメッセージのためにトランスポート機構／パスを選択する際に考慮されるであろう。
（５）コアネットワークノード可用性およびネットワーク状態−ネットワーク内のＡＤＤＳエンティティ３２２は、３ＧＰＰコアネットワークノード（ＭＭＥ１１４、ＭＳＣ２３８、ＰＧＷ１１２、および同等物等）の可用性に基づいて、トランスポート機構／パスを選択してもよい。いくつかの実施形態では、ＡＤＤＳエンティティ３２２は、あるトランスポート機構を提供するコアネットワークエンティティ／インターフェースが現在オーバーロード状態であることを識別する場合、これらのトランスポート機構を使用しないように１つまたはそれを上回るエンドノードにおけるＡＤＤＳクライアント３２４に知らせてもよい。
（６）加入情報−ＨＳＳ１１６／ＵＤＲ３５２からの加入情報は、ＡＤＤＳサービスを限定数の利用可能なトランスポート機構／パスの使用に制限してもよい。
（７）ポリシー情報−最後に、（ＯＣＳ３３０、ＯＦＣＳ３３２、およびＰＣＲＦ３３４を含む）コアネットワークのポリシーおよび課金制御（ＰＣＣ）機能からのポリシーおよび課金情報もまた、ＡＤＤＳメッセージ転送のために選択されるパスを動的に制御するために使用されてもよい。

トランスポート機構／パス選択のためのこれらの７つの基準のうちの１つまたはそれを上回るものが、種々の実施形態で採用されてもよいが、ＡＤＤＳサービスは、これらの基準のみの使用に限定されないことが理解される。むしろ、適切なパスの選択を補助し得る、任意の基準が採用されてもよい。多くの実施形態では、ネットワークオペレータは、ネットワークのトポロジおよび現在のネットワーク状態に基づいて、パス選択ポリシーを決定するであろう。

一実施例では、「メッセージ特性およびアプリケーション特性」が、アプリケーションが高遅延に耐えることができ、低いメッセージ率を有し、メッセージが低い重要性であり、比較的短い「メッセージ長」であることを示す、アプリケーションがあってもよい。ネットワークオペレータは、ＳＭＳが少ない待ち時間を要求しない、小さいデータパケットによく適しているため、ＳＭＳトランスポート機構が本用途のために選択されるように、ＡＤＤＳトランスポート機構／パス選択ポリシーを構成してもよい。代替として、ネットワークオペレータは、余分なＳＭＳトラフィックを生成したくないことを決定してもよく、再度、データパケットが小さく希少であるため、ＮＡＳまたはＲＲＣ等のある制御プレーントランスポート機構が、本用途のために選択されるように、ポリシーを構成してもよい。さらに別の代替案では、ネットワークオペレータは、ＳＭＳ、ＮＡＳ、またはＲＲＣ等の制御プレーントランスポート機構が、現在のところ特に混雑していないことをＡＤＤＳクライアント３２４および／またはＡＤＤＳエンティティ３２２に示してもよく、したがって、本メッセージに使用するトランスポート機構として、ユーザプレーンの選択をもたらす。

別の実施例では、「メッセージ特性およびアプリケーション特性」が、アプリケーションデータパスが高遅延に耐えられず、低いメッセージ率を有し、低い重要性であり、「メッセージ長」が比較的低いことを示す、アプリケーションがあってもよい。ネットワークオペレータは、ＳＭＳメッセージングが少ない配信待ち時間を保証しないため、ＳＭＳが本用途のために選択されないように、ＡＤＤＳトランスポート機構／パス選択ポリシーを構成してもよい。

さらに別の実施例では、「メッセージ特性およびアプリケーション特性」が、アプリケーションデータパスが高遅延に耐えられ、低いメッセージ率を有し、低い重要性であり、「メッセージ長」が比較的高いことを示す、アプリケーションがあってもよい。ネットワークオペレータは、比較的大きいメッセージサイズが多くの制御プレーントラフィックを生成するであろうため、ＳＭＳ、ＮＳＡ、およびＲＲＣ等の制御プレーントランスポート機構が本用途のために選定されないように、ＡＤＤＳトランスポート機構／パス選択ポリシーを構成してもよい。したがって、ネットワークオペレータのポリシーは、ユーザプレーンが本用途のために選択されることを決定付けてもよい。

（ＡＤＤＳクライアント）
上記のように、一実施形態では、ＡＤＤＳクライアント３２４は、ＵＥ、ＳＣＳ、またはＡＳのメモリに記憶され得、そのデバイスのプロセッサ上で実行され得る、論理エンティティ（例えば、ソフトウェア）を備える。しかしながら、他の実施形態では、ＡＤＤＳクライアント３２４は、完全にハードウェアで、またはハードウェアおよびソフトウェアの任意の組み合わせで実装されてもよい。ＡＤＤＳクライアント３２４は、エンドノード上のアプリケーションが相互と通信することを可能にするように、ネットワーク内のＡＤＤＳ機能性（例えば、ＡＤＤＳエンティティ３２２）とインターワーキングする。それらのデータ通信のためにＡＤＤＳを必要とするアプリケーションは、エンドノード上のＡＤＤＳクライアント３２４に結合してもよい。一実施形態では、ＡＤＤＳクライアント３２４は、以下の機能性を提供する。
（１）アプリケーションをネットワークＡＤＤＳエンティティ３２２に登録し、アプリケーションＩＤを取得し、それぞれのアプリケーションへのアプリケーションＩＤのマッピングを維持し、ＡＤＤＳサービスに関係付けられるアプリケーション状態を維持する。
（２）アプリケーション通信の特性の通りのアプリケーションデータの転送。これは、トランスポート機構／パス（例えば、ＮＡＳ、ＳＭＳ、ＵＤＤＳ、またはユーザプレーン）およびデータを転送する時間の選択、ならびにアプリケーションデータバッファリングを含む。
（３）基礎的データトランスポート方法および他のＡＤＤＳプロシージャからアプリケーションを抽象化する。
（４）必要であればアプリケーションデータを暗号化する。
（５）ＡＤＤＳプロトコルヘッダを符号化および復号する。
（６）ＡＰＩをアプリケーションに提供する

本実施形態では、アプリケーションは、ＡＤ２インターフェースを経由してＤＤＳクライアント３２４と結合する。アプリケーションおよびＡＤＤＳクライアントが、異なる物理エンティティ内にある（例えば、デバイス３１４のＡｐｐ１が図３のＵＥ３１２上のＡＤＤＳクライアント３２４と結合される）、またはそれらが同一の物理デバイス内で統合され得る（例えば、図３のＵＥ３１２上のＡｐｐ３およびＡｐｐ４）ことが可能である。

図５は、ＡＤＤＳクライアント３２４およびアプリケーション（例えば、アプリケーション＃１、アプリケーション＃２、およびアプリケーション＃３）が同一のエンドノード５００内に存在するときのＡＤＤＳクライアント３２４のアーキテクチャの一実施形態を図示する。エンドノード５００は、ＵＥ（図１−４のＵＥ１０４、２１４、３２４、および３１８、ＳＣＳ３０６、ＡＳ３１０、ならびにＳＣＳまたはＡＳ３４０等）を備えてもよい。

示されるように、ホストエンドノード５００内のアプリケーションは、ＡＤＤＳクライアント３２４と通信するためにＡＤ２インターフェースを使用する。一実施形態では、本インターフェースは、アプリケーションがＡＤＤＳサービスを使用することを可能にするように、ＡＤＤＳクライアントによって提供されるＡＰＩ５０２のセットを備えてもよい。アプリケーションは、それら自体をＡＤＤＳエンティティ３２２に登録するため、およびアプリケーションＩＤを入手するために、これらのＡＰＩ５０２を使用することができる。アプリケーションはまた、異なる通信要件に基づいて、必要に応じて、異なるＡＤＤＳソケット（図示せず）を作成してもよい。例えば、１つのソケットが、メッセージの即時配信に使用されてもよく、１つのソケットが、遅延配信に使用されてもよい。一実施形態では、ＡＰＩが、ＡＤＤＳソケットを開放し、ソケットを経由してデータを送信および受信し、アプリケーション特性を伴ってソケットを構成するように提供される。ＡＤＤＳクライアント３２４は、ソケットの特性およびアプリケーション識別子とのそれらの関連を維持する（すなわち、エンドノード５００のメモリに記憶する）。一実施形態では、ＡＰＩ５０２は、以下を備えてもよい。
ａｄｄｓＲｅｇｉｓｔｅｒ（）
アプリケーションによって記憶されるアプリケーション識別子およびセキュリティトークンを返す。アプリケーションはまた、使用される具体的ＩＤまたは予約アプリケーションＩＤを要求することもできる。
ａｄｄｓＯｐｅｎＳｏｃｋｅｔ（）
ソケットを識別するファイル記述子のようなソケットを返す。本ファイル記述子は、ＡＤＤＳメッセージを送信するために使用されるはずである。
ａｄｄｓＳｏｃｋＯｐｔｉｏｎｓ（）
遅延配信、確実な配信等のような通信特性を伴ってＡＤＤＳクライアントを構成するために、アプリケーションによって使用される。
ａｄｄｓＳｅｎｄ（）
ＡＤＤＳを使用してアプリケーションデータを送信する。
ａｄｄｓＣｌｏｓｅＳｏｃｋｅｔ（）
ＡＤＤＳソケットを閉鎖する。
ａｄｄｓＤａｔａＱｕｅｒｙ（）
ネットワークから配信される保留メッセージをチェックする。
ａｄｄｓＲｅｃｅｉｖｅ（）
アプリケーションデータを読み取る。ソケット記述子は、メッセージを読み取るために必要とされない。
ａｄｄｓＥｖｅｎｔＳｕｂｓｃｒｉｐｔｉｏｎ（）
他のアプリケーションの（登録、登録解除のような）いくつかのイベントのために、ネットワークＡＤＤＳエンティティに登録する。
ａｄｄｓＮｏｔｉｆｉｃａｔｉｏｎＣａｌｌｂａｃｋＲｅｇｉｓｔｅｒ（）
行われる加入に基づいて、ネットワークから通知があるときに呼び出されるコールバック機能を登録する。
ａｄｄｓＤｅｒｅｇｉｓｔｅｒ（）
アプリケーションを登録解除し、アプリケーションＩＤを解放する。

さらに示されるように、ＡＤＤＳクライアント３２４は、データを送信／受信するため、ならびにネットワークトランスポートパスを習得および構成するために、それらのサービスを利用するように、エンドノード５００のネットワークドライバとインターワーキングする。例えば、ＵＥの場合、ＡＤＤＳクライアントは、ＡＤＤＳデータを送信／受信し、ＭＴの能力を読み出し、ＭＴを構成するために、ネットワーク／モデムドライバを使用して、ＭＴ（モバイル端末）とインターワーキングしてもよい。

ＴＥ（例えば、コンピュータ）と、（３ＧＰＰ ＴＳ ２７．００７で説明されるように）ＴＡによってインターフェース接続されるＭＴとを備える、抽象アーキテクチャが、ＵＥで採用される、一実施形態では、ＴＥとＭＴとの間の‘Ｒ’インターフェースが、ＡＤＤＳ機能性を有効にするために以下の機能を果たすように、以下の新しいＡＴコマンドで更新されてもよい。
（１）ＡＤＤＳ Ｃｏｎｆｉｇｕｒｅ．本機能は、ＡＤＤＳクライアントの存在についてＭＴに知らせるため、およびＭＴにネットワークからＡＤＤＳエンティティ詳細を要求させるために果たされてもよい。本コマンドを使用して登録され得るＡＤＤＳクライアント情報は、制御プレーンを経由して（ＮＡＳを経由して）データを受信するときに、データをＡＤＤＳクライアントに配信するためにＭＴによって使用されてもよい。
（２）ＡＤＤＳ Ｉｎｆｏｒｍａｔｉｏｎ Ｒｅｔｒｉｅｖａｌ．本機能は、以下で説明されるように、ＭＴがネットワークから受信したＡＤＤＳ接触情報詳細を読み出すために使用されてもよい。
（３）Ｄａｔａ ｏｖｅｒ ＮＡＳ．本機能は、ＡＤＤＳクライアントに、データが制御プレーン（ＮＡＳ）を経由して送信される必要があることをＭＴに知らせるために使用されてもよい。

図６は、ＡＤＤＳクライアント３２４が、ＡＤＤＳクライアント３２４がホストされるエンドノード５００’と異なる物理デバイス５２０上で作動するアプリケーション（アプリケーション＃１、＃２、および＃３）とインターワーキングする、ＡＤＤＳクライアント３２４のアーキテクチャの別の実施形態を図示する。例えば、本アーキテクチャは、Ｍ２ＭアプリケーションがＭ２Ｍゲートウェイに接続するデバイス上で作動し、ゲートウェイが３ＧＰＰ ネットワークに接続する３ＧＰＰ ＵＥである、Ｍ２Ｍシナリオで使用されてもよい。本アーキテクチャでは、ＡＤ２インターフェースは、エンドノード５００’とアプリケーションが常駐するデバイスとの間で使用される、ネットワークに依存するであろう。例えば、Ｍ２Ｍシナリオでは、本ネットワークは、ＺｉｇＢｅｅ、６ＬｏＷＰＡＮ、Ｗｉ−Ｆｉ、または同等物に基づいてもよい。

（ＡＤＤＳ広告）
本節は、ＵＥおよびＳＣＳが、ＡＤＤＳエンティティ３２２およびＡＤＤＳサービスによって提供されるサービスについて認識させられ得る、方法を説明する。ＡＤＤＳ広告の目的は、ネットワークがＡＤＤＳ機能性をサポートすることをＵＥおよびＳＣＳに認識させること、サポートされたトランスポート方法／プロトコル、アプリケーションペイロードのサイズ、および同等物のようなＡＤＤＳエンティティの能力を提供すること、ならびにＩＰアドレス、ＭＳＩＳＤＮ、ＦＱＤＮ、または同等物等のＡＤＤＳエンティティ３２２の接触詳細を提供することである。いくつかの実施形態では、異なる方法が、ＳＣＳまたはＡＳ等の外部ノード上のＡＤＤＳクライアントと対比して、ＵＥ上のＡＤＤＳクライアントへのＡＤＤＳ広告に使用されてもよい。

（ＵＥへのＡＤＤＳ広告）
以下の副節は、ＵＥへのＡＤＤＳ広告に使用されることができる、種々の方法を説明する。どの方法が採用されるかという選択は、展開されるＡＤＤＳアーキテクチャ（すなわち、ＡＤＤＳがオペレータレベルまたはＰＤＮレベルで実装されるかどうか、もしくはＡＤＤＳがサービスドメイン内にあるかどうか）、およびエンドデバイスのアクセスタイプ（すなわち、デバイスがＡＤＤＳエンティティにアクセスするために３ＧＰＰアクセスまたは非３ＧＰＰアクセスを使用するかどうか）に依存する。

（アタッチ方法）
一実施形態では、ＡＤＤＳをＵＥに宣伝するための方法は、ＡＤＤＳ詳細をＵＥに提供するために、既存の３ＧＰＰアタッチ容認メッセージを採用する。具体的には、３ＧＰＰ ＵＥ／ＭＳ（例えば、図２および４Ａ−ＥのＵＥ２１４）が、３ＧＰＰ ＴＳ ２３．４０１または３ＧＰＰ ＴＳ ２３．０６０で記述されるアタッチプロシージャの通りにネットワークにアタッチするとき、ＵＥ／ＭＳ２１４は、アタッチ要求メッセージにおいてＡＤＤＳ詳細を要求してもよい。ＭＭＥ１１４は、ＡＤＤＳ情報を伴って構成されることができ、またはＨＳＳ１１６もしくはＨＬＲ（図示せず）に記憶されたＵＥの加入情報からそれを読み出すことができる。ＭＭＥ１１４は、アタッチ容認メッセージにおいて、ＡＤＤＳ詳細をＵＥに伝えることができる。図７は、既存の３ＧＰＰ ＬＴＥ ＵＥアタッチプロシージャとの関連で本方法を図示する。本実施形態では、修正されたメッセージが、ＡＤＤＳ広告を行うように、ステップ１、２、８、１１、１６、１７、および１８で使用される。残りのステップは、既存の３ＧＰＰアタッチプロシージャから実質的に不変である。図７は、ＬＴＥネットワーク内のアタッチプロシージャを図示するが、ＵＭＴＳ、ＧＰＲＳ、または他のタイプのネットワーク内のアタッチプロシージャもまた、ＡＤＤＳ広告を行うように同様に増進され得ることに留意されたい。

図７のアタッチプロシージャのステップ、具体的には、本実施形態ではＡＤＤＳ広告をサポートするように修正されるステップを参照すると、ステップ１−２では、ＵＥ２１４は、ＵＥが、存在する場合、ネットワークによってサポートされるＡＤＤＳ詳細について把握することを希望することを示すように、情報要素（ＩＥ）がメッセージに追加されることができる、アタッチ要求をコアネットワークに送信する。「ＵＥネットワーク能力」ＩＥもまた、ＵＥがＡＤＤＳ機能性をサポートするかどうかという指示を含むように増進されることができる。

ステップ８では、ＵＬＲメッセージは、ＭＭＥ１１４がＵＥによって加入されるＡＤＤＳ情報を必要とすることを示すためにフラグを含むように、更新されてもよい。

ステップ１１では、ＨＳＳが、ＵＬＡメッセージにＡＤＤＳ詳細を含んでもよい。３ＧＰＰ ＴＳ ２９．２７２で定義される「加入データ」Ｄｉａｍｅｔｅｒ ＡＶＰは、ＡＤＤＳ詳細を含むように修正されてもよい。詳細は、サポートされたＡＤＤＳ特徴、ＡＤＤＳトランスポートパス、およびそれらの関連情報を含んでもよい。含まれ得る詳細の実施例が、以下の表１に示される。

ステップ１７では、ＭＭＥ１１４が、アタッチ容認メッセージを送信するとき、表１に列挙されるようなＡＤＤＳ情報を含むことができる。ステップ１８では、ｅＮＢ１０６からのＲＲＣ再構成メッセージは、修正されなくてもよいが、代わりに、ピギーバック式ＮＡＳアタッチ容認メッセージが、ＡＤＤＳ情報を含有してもよい。アタッチプロシージャにおける全ての他のステップは、影響を受けず、３ＧＰＰ ＴＳ ２３．４０１で定義されるように実行されてもよい。

（ＡＤＤＳ情報要求プロシージャ方法）
図８は、一実施形態による、ＡＤＤＳ広告のための別の方法を図示する。本方法では、ＵＥ２１４は、独立型ＡＤＤＳ情報要求を実行することによって、ＡＤＤＳ機能性についての情報を要求してもよい。具体的には、図８に示されるように、ステップ１では、ＵＥ２１４は、ＡＤＤＳ情報を要求するＮＡＳ ＥＭＭメッセージをＭＭＥ１１４に送信する。ステップ２では、ＭＭＥ１１４が、ＡＤＤＳ情報を要求するようにＵＬＲメッセージをＨＳＳ１１６に送信する。一実施形態では、本ステップは、随意であり、ＭＭＥ１１４は、ＭＭＥ１１４がＡＤＤＳ情報をまだ有していない場合に本要求を送信してもよい。ステップ３では、ＨＳＳ１１６が、上記で説明される図７に図示される方法のステップ１１で説明されるものと同様に、ＵＬＡメッセージを送信する。ステップ４では、ＭＭＥ１１４が、ＵＥ２１４をＡＤＤＳ情報で更新するように、ＮＡＳ ＥＭＭメッセージを送信する。他の実施形態では、サービングＧＰＲＳサポートノード（ＳＧＳＮ）がＡＤＤＳ情報要求に応答し得る、類似アプローチが、ＧＰＲＳおよびＵＭＴＳネットワークで使用されてもよい。

（特殊ＡＰＮ方法）
図９は、その実施形態による、ＡＤＤＳ広告のためのさらに別の方法を図示する。概して、ネットワークオペレータは、独占的にＡＤＤＳ機能性のためにＡＰＮをマークすることができる。ＡＤＤＳを使用することを希望するＵＥは、本特殊ＡＰＮへのＰＤＮ接続を要求することができる。コアネットワークは、ＵＥがＡＤＤＳ情報を必要とすることを推論することができ、既存の３ＧＰＰ ＰＤＮ接続容認メッセージにおいて詳細をＵＥに伝えることができる。本方法は、例えば、図４Ａおよび４Ｂに図示されるように、ＰＧＷをＡＤＤＳエンティティに接続するために「プライベートＰＤＮ」が使用されるときに適用されてもよい。特殊ＡＰＮへのＰＤＮ接続は、ＵＥがネットワークオペレータのプライベートＰＤＮを通してＡＤＤＳと通信することを可能にし得る。

図９のステップは、本方法の一実施形態を図示する。ＡＰＮ名を提供する代わりに、ＵＥ２１４が、ＡＤＤＳにアクセスするためにＰＤＮ接続を行うことを希望するという指示を含み得ることに留意されたい。ＭＭＥ１１４／ＨＳＳ１１６は、それを通してＡＤＤＳがアクセスされ得る、プライベートＰＤＮに接続するために使用されるはずであるＡＰＮを判定することができる。

図９を参照すると、ステップ１では、ＵＥ２１４が、ＡＤＤＳを必要とすることを示すように、３ＧＰＰ「ＰＤＮ接続要求」メッセージ等のＮＡＳメッセージの中で特殊ＡＰＮまたはフラグ（新しいＩＥ）を提供することができる。ステップ２および３では、特殊ＡＰＮがＰＧＷ１１２にパスされる。ステップ４ａでは、ＰＧＷ１１２が、随意に、ＡＤＤＳ情報クエリ要求を送信することによって、ＡＤＤＳから最新情報を読み出すことができる。ＡＤＤＳは、ＡＤＤＳを使用するＵＥ２１４の認可詳細についてＨＳＳ１１６（またはＳＰＲもしくはＵＤＲ）をチェックし、次いで、詳細をＰＧＷ１１２に提供することができる。

ステップ５では、ＰＧＷ１１２が、「セッション作成応答」メッセージの既存の３ＧＰＰ ＰＣＯ ＩＥに（表１に列挙されるような）ＡＤＤＳ情報を含み、それをＵＥ２１４に向かって送信してもよい。ステップ６、７、および８では、ＰＧＷ１１２からの修正されたＰＣＯ ＩＥが、ＵＥ２１４に転送される。本実施形態では、本ＰＤＮ接続プロシージャにおける全ての他のステップは、影響を受けず、実質的に３ＧＰＰ ＴＳ ２３．４０１で定義される通りのままである。

（ＰＤＮ接続方法）
ＡＤＤＳ広告に採用され得る別の方法は、図９に図示される方法に類似するが、特殊ＰＤＮは、ＡＤＤＳ３２２とＰＧＷ１１２との間の通信に使用されない。本方法では、ＵＥ２１４は、任意のＰＤＮに接続されてもよく、そのＰＤＮに使用されるＡＤＤＳ機能性を要求してもよい。「ＰＤＮ接続要求」で特殊ＡＰＮを使用する代わりに、ＵＥは、ＡＤＤＳ詳細が要求されることを示すように、「ＰＤＮ接続要求」に新しいＩＥ（例えば、フラグ）を含むことができる。ＰＧＷ１１２は、「セッション作成応答」メッセージのＰＣＯＩＥの中のＡＤＤＳ詳細で応答することができる。本方法では、呼び出しフローは、図９に類似するであろう。

（ユーザ／オペレータプロビジョニング）
ＡＤＤＳ広告のための別の方法は、ネットワークオペレータによって公開され得る、またはネットワークオペレータから取得され得る値の通りに、デバイス上でＡＤＤＳ情報を手動でプロビジョニングするように、デバイスのユーザに依拠してもよい。ＡＤＤＳ機能性を提供するネットワークオペレータは、代替として、既存のオープンモバイルアライアンス（ＯＭＡ）デバイス管理（ＤＭ）または汎用加入者識別モジュール（ＵＳＩＭ）オーバーザエア（ＯＴＡ）更新方法を使用して、ＡＤＤＳ情報でデバイスを動的にプロビジョニングしてもよい。

（ＳＣＳへのＡＤＤＳ広告）
本節は、ＳＣＳがコアネットワークによって提供されるＡＤＤＳ詳細を認識させられ得る、方法を説明する。

（Ｔｓｐインターフェース方法）
図１０は、ＴｓｐインターフェースがＳＣＳへのＡＤＤＳ広告に使用される、方法の一実施形態を図示する。本実施形態では、ＳＣＳ３４０は、ステップ１に示されるように、Ｔｓｐインターフェースを経由してＡＤＤＳ情報要求を送信することによって、ＡＤＤＳ情報を要求することができる。ステップ２では、ＭＴＣ−ＩＷＦ２１０は、ＡＤＤＳを使用するＳＣＳ３４０の認可についてＨＳＳ１１６をチェックし、ステップ３に示されるように、ＡＤＤＳ情報をＳＣＳに提供することができる。ＡＤＤＳとＳＣＳとの間のトランスポート機構／パスオプションの数が限定され得るため、ＳＣＳに提供されるＡＤＤＳ詳細は、ＵＥに提供されるＡＤＤＳ詳細と異なり、限定された情報を有し得る。ＳＣＳに提供されるＡＤＤＳ詳細の実施例が、以下の表２に列挙される。

（Ｍｈ／Ｒｘインターフェース方法）
ＳＣＳへのＡＤＤＳ広告のための別の方法によると、ＳＣＳ３４０はまた、既存の３ＧＰＰ ＭｈまたはＲｘインターフェースを経由して、表２に列挙されるＡＤＤＳ情報を読み出してもよい。本方法では、ＡＤＤＳ情報は、ＳＣＳ／ＡＳ３４０がＭｈまたはＲｘインターフェースを介して本情報を読み出すことを可能にするように、ＨＳＳ１１６もしくはＰＣＲＦ３３４においてプロビジョニングされてもよい。ＨＳＳおよびＰＣＲＦにおける本情報のプロビジョニングは、ネットワークオペレータによって、またはＡＤＤＳがＨＳＳ１１６およびＰＣＲＦ３４０と有するＡＤ６ならびにＡＤ３インターフェースを経由してＡＤＤＳエンティティ３２２によって動的に行われてもよい。

他の実施形態では、ＳＣＳ上のＡＤＤＳ情報は、Ｍ２Ｍネットワークのオペレータによって、手動でプロビジョニングされてもよい。

（ＡＤＤＳプロトコルスタック）
上記で説明されるように、ＡＤＤＳサービスの重要な特徴は、アプリケーションの間でＡＤＤＳデータメッセージを搬送するためにコアネットワークで利用可能な複数の異なるトランスポート機構／パスのうちの１つの選択である。ネットワーク内のＡＤＤＳクライアント３２４およびＡＤＤＳエンティティ３２２は、上記で議論されるトランスポートパス選択基準に従って、トランスポートパスを選択する。データメッセージを伝送するプロセスは、図１５に関連して以下でさらに完全に説明される。ＳＣＳまたはＡＳ３４０等のネットワーク側エンドノード上のＡＤＤＳクライアント３２２とＡＤＤＳエンティティ３２２との間の通信は、一実施形態では、概して、ＩＰベースであってもよい。ＡＤＤＳサービスが使用する、ＴＣＰ、ＵＤＰ、またはＳＣＴＰ等のトランスポート層は、メッセージの重要性および確実なトランスポート機構が特定のメッセージもしくはアプリケーションに必要とされるかどうか等の送信されているメッセージの特性に依存し得る。

ＵＥ（例えば、図２−４のＵＥ２１４、３１２、および３１８）等のアクセス側エンドノード上のＡＤＤＳクライアント３２４とＡＤＤＳエンティティ３２２との間の通信は、一実施形態では、ＮＡＳ、ＳＭＳのユーザプレーン等の複数の利用可能なトランスポート機構のうちのその他の選択されたものを経由して行われてもよい。図１１Ａ−Ｄは、これらの異なるトランスポート機構のそれぞれに採用されるプロトコルスタック、およびこれらの異なるトランスポートパスを経由してＡＤＤＳメッセージをトランスポートする方式を図示する。

図１１Ａは、ＮＡＳを経由したＡＤＤＳメッセージ転送のためのプロトコルスタックを示す。本実施形態では、以下でさらに詳細に説明されるように、ＡＤＤＳヘッダおよびペイロードを含み得る、ＡＤＤＳメッセージは、一般ＮＡＳトランスポートメッセージにカプセル化される。この場合、ＵＰＬＩＮＫ ＧＥＮＥＲＩＣ ＮＡＳ ＴＲＡＮＳＰＯＲＴメッセージが、ＵＥ２１４からＭＭＥ１１４にＡＤＤＳメッセージを搬送するために使用されてもよく、ＤＯＷＮＬＩＮＫ ＧＥＮＥＲＩＣ ＮＡＳ ＴＲＡＮＳＰＯＲＴメッセージが、ＭＭＥ１１４からＵＥ２１４にメッセージを搬送するために使用されてもよい。これらのメッセージは、３ＧＰＰ ＴＳ ２３．４０１（第５．６．４節および第８．２．３０節）で説明される。また、本実施形態では、ＮＡＳトランスポートメッセージの一般メッセージコンテナタイプＩＥは、メッセージがＡＤＤＳメッセージであることを示すように、未使用フィールドのうちの１つ（例えば、「００００００１１」）に設定されることができ、一般メッセージコンテナＩＥはまた、ＡＤＤＳに配信される完全ペイロードを搬送するために使用されてもよい。

アップリンクパスでは、ＭＭＥ１１４は、一般ＮＡＳメッセージがＡＤＤＳに配信される必要があると解釈し、ペイロードをＤｉａｍｅｔｅｒメッセージに変換し、ＡＤ５インターフェースを経由してそれをＡＤＤＳエンティティ３２２に送信する。ＡＤＤＳエンティティ３２２は、メッセージヘッダを解釈し、宛先ＡＤＤＳアプリケーション識別子／デバイス識別子を抽出し、ＡＤ１インターフェースを経由してメッセージをＳＣＳ３４０に送信する。

ダウンリンクパスでは、ＳＣＳ３４０は、ＡＤ１インターフェースを経由して、ＭＴＣアプリケーションのアプリケーション識別子ならびにＡＤＤＳヘッダおよびペイロード情報をＡＤＤＳエンティティ３２２に提供する。ＡＤ５転送パスがメッセージ配信のために選定される場合には、ＡＤＤＳエンティティ３２２は、宛先アプリケーション識別子を使用し、宛先アプリケーションが常駐するＵＥ（例えば、ＵＥ２１４）のＩＭＳＩを見出す。ＡＤＤＳエンティティは、データをＤｉａｍｅｔｅｒメッセージに変換し、ＮＡＳを介してメッセージが送信される必要があるＵＥのＩＭＳＩとともに、それをＭＭＥ１１４に送信する。ＭＭＥ１１４は、メッセージをＵＥ２１４に転送するように、ＤｉａｍｅｔｅｒメッセージをＤｏｗｎｌｉｎｋ Ｇｅｎｅｒｉｃ ＮＡＳ Ｔｒａｎｓｐｏｒｔメッセージに変換する。

図１１Ｂは、ユーザプレーンを経由したＡＤＤＳメッセージ転送のためのプロトコルスタックを示す。この場合、ＡＤＤＳメッセージは、通常のユーザプレーンＩＰパケットとしてトランスポートされ、ＧＴＰユーザプレーンを経由して転送されてもよい。

アップリンクでは、ＵＥ２１４上のＡＤＤＳクライアント３２４は、メッセージ特性に基づいて、使用されるトランスポートプロトコル（例えば、ＴＣＰ、ＵＤＰ、またはＳＣＴＰ）を選定してもよく、ＡＤＤＳエンティティ３２２のＩＰアドレスにアドレス指定されるＩＰパケットを送信する。本ＩＰパケットは、通常のユーザプレーンを辿ってもよく、ＧＴＰ−Ｕパケットにカプセル化され、ｅＮｏｄｅＢ１０６、ＳＧＷ１１０、およびＰＧＷ１１２を経由してＡＤＤＳエンティティ３２２にトランスポートされてもよい。ＡＤＤＳエンティティ３２２は、受信されたメッセージを解釈し、宛先ＡＤＤＳアプリケーション識別子／デバイス識別子を抽出し、ＡＤ１インターフェースを経由してメッセージをＳＣＳ３４０に送信する。

ダウンリンクパスでは、ＳＣＳ３４０は、ＡＤ１インターフェースを経由して、ＭＴＣアプリケーションのアプリケーション識別子ならびにＡＤＤＳヘッダおよびペイロード情報をＡＤＤＳエンティティ３２２に提供する。ユーザプレーンパスがメッセージ配信のために選択される場合には、ＡＤＤＳエンティティ３２２は、宛先アプリケーション識別子を使用し、（ＡＤＤＳエンティティ３２２に記憶されたマッピングテーブルから）宛先アプリケーションが常駐するＵＥのＩＰアドレスを見出す。次いで、ＡＤＤＳエンティティは、使用されるトランスポートプロトコル（例えば、ＴＣＰ、ＵＤＰ、またはＳＣＴＰ）を選定し、ＵＥのＩＰアドレスにアドレス指定されるＩＰパケットを構築し、ＳＧｉインターフェース上でそれをＰＧＷ１１２に送信する。

図１１Ｃは、ＳＭＳを使用するＡＤＤＳメッセージ転送のためのプロトコルスタックを示す。本実施形態では、ＡＤＤＳメッセージは、ＳＭＳメッセージとしてトランスポートされてもよい。

アップリンクパスでは、ＵＥは、ＳＭＳ ＴＰＤＵにＡＤＤＳメッセージをカプセル化し、それをモバイル発信ＳＭＳ（ＭＯ ＳＭＳ）メッセージとしてトランスポートする。本実施形態では、ＳＭＳメッセージは、ＴＰ宛先アドレス（ＴＰ−ＤＡ）をＡＤＤＳエンティティ３２２のアドレスに設定することによって、ＡＤＤＳエンティティにアドレス指定される。ＡＤＤＳエンティティ３２２は、受信されたメッセージを解釈し、宛先ＡＤＤＳアプリケーション識別子／デバイス識別子を抽出し、ＡＤ１インターフェースを経由してメッセージをＳＣＳ３４０に送信する。

ダウンリンクパスでは、ＳＣＳ３４０は、ＡＤ１インターフェースを経由して、ＭＴＣアプリケーションのアプリケーション識別子ならびにＡＤＤＳヘッダおよびペイロード情報をＡＤＤＳエンティティ３２２に提供する。ＳＭＳトランスポート機構／パスがメッセージ配信のために選定される場合には、ＡＤＤＳエンティティ３２２は、その記憶されたマッピングテーブルから、宛先アプリケーションが常駐するＵＥ２１４のアドレス（ＭＳＩＳＤＮ）を見出すために、宛先アプリケーション識別子を使用する。本実施形態では、ＡＤＤＳ３２２は、外部ＳＭＥの役割を果たし、モバイル端末（ＭＴ）ＳＭＳとしてトランスポートされるように、ＡＤＤＳメッセージをＳＭＳ−ＳＣ２０４に送信する。ＳＭＳ−ＳＣ２０４とＡＤＤＳエンティティ３２２との間のインターフェースは、ＭＴＣ−ＩＷＦ２１０とＳＭＳ−ＳＣ２０４との間のＴ４インターフェースに類似するＤｉａｍｅｔｅｒプロトコルに基づいてもよい。代替として、ショートメッセージピアツーピア（ＳＭＰＰ）、メッセージ分配へのコンピュータインターフェース（ＣＩＭＤ）、または汎用コンピュータプロトコル／外部マシンインターフェース（ＵＣＰ／ＥＭＩ）等の他のプロトコルが使用されてもよい。ＳＭＳメッセージは、ＳＧｓ基準点を経由したＳＭＳ、ＩＭＳネットワークを経由して、または回路交換（ＣＳ）フォールバックを使用する等、利用可能な方法のうちのいずれかを使用して、ＵＥ２１４とＡＤＤＳエンティティ３２２との間でトランスポートされてもよい。

図１１Ｄは、ＵＳＳＤを使用するＡＤＤＳメッセージ転送のためのプロトコルスタックを示す。この場合、ＡＤＤＳメッセージは、ＵＳＳＤメッセージとしてトランスポートされる。

アップリンクパスでは、ＵＥ２１４内のＵＳＳＤ要素は、ＵＳＳＤデータバーストメッセージにＡＤＤＳメッセージをカプセル化し、それは、モバイル開始ＵＳＳＤとしてトランスポートされる。ＵＳＳＤメッセージは、ＡＤＤＳエンティティ３２２内のＵＳＳＤゲートウェイのＵＳＳＤショートコードを設定することによって、ＡＤＤＳエンティティにアドレス指定されてもよい。ＡＤＤＳエンティティ３２２は、受信されたメッセージを解釈し、宛先ＡＤＤＳアプリケーション識別子／デバイス識別子を抽出し、ＡＤ１インターフェースを経由してメッセージをＳＣＳ３４０に送信する。

ダウンリンクパスでは、ＳＣＳ３４０は、ＡＤ１インターフェースを経由して、ＭＴＣアプリケーションのアプリケーション識別子ならびにＡＤＤＳヘッダおよびペイロード情報をＡＤＤＳエンティティ３２２に提供する。ＵＳＳＤトランスポート機構／パスがメッセージ配信のために選定される場合には、ＡＤＤＳエンティティ３２２は、その内部マッピングテーブルから、ＵＥ２１４のＵＳＳＤコードを見出すために、宛先アプリケーション識別子を使用する。本実施形態では、ＡＤＤＳ３２２は、ＵＳＳＤゲートウェイの役割を果たし、ネットワーク開始ＵＳＳＤとしてトランスポートされるように、ＵＳＳＤ要求メッセージにカプセル化されるＡＤＤＳメッセージまたはＵＳＳＤ通知メッセージをＭＳＣ２３８に送信する。ＭＳＣ２３８とＡＤＤＳエンティティ３２２内のＵＳＳＤゲートウェイとの間のインターフェースは、一実施形態では、ＭＡＰプロトコルベースであってもよい。

（ＡＤＤＳプロトコルおよびメッセージ形式）
図１１Ａ−Ｄに図示されるように、ＡＤＤＳプロトコルが、ＵＥ（例えば、ＵＥ２１４）またはＳＣＳ（例えば、ＳＣＳ３４０）上のＡＤＤＳクライアント３２４とネットワーク内のＡＤＤＳエンティティ３２２との間の通信に使用される。ＡＤＤＳプロトコルは、メッセージ配信のために選択されるトランスポート機構／パスに基づいて、ＡＤＤＳメッセージのセグメンテーションおよび再アセンブリを行ってもよい。シーケンス番号が、異なるパスを介してトランスポートされるＡＤＤＳメッセージの並べ換えを可能にするために、ＡＤＤＳプロトコルで使用されてもよい。

一実施形態では、ＡＤＤＳメッセージは、共通ヘッダを有してもよく、トランスポート特性、アプリケーション特性、および同等物等のＡＤＤＳプロシージャに関係付けられるＡＤＤＳ制御情報を搬送してもよい。アプリケーションデータはまた、データについての情報を含有する付加的データヘッダの包含とともに同様に搬送されてもよい。データヘッダおよびペイロードは、以下でさらに完全に説明される、「ＡＤＤＳデータ転送要求」および「ＡＤＤＳデータ配信」メッセージのみの中に存在し得る。図１２は、その一実施形態による、ＡＤＤＳメッセージの形式を図示する。以下は、メッセージ形式の共通ヘッダのフィールドのそれぞれを説明する。
メッセージタイプ：送信されているメッセージのタイプを示す。
メッセージ長：ＡＤＤＳメッセージの全長。
シーケンス番号：増加する順序で送信エンティティによって割り当てられる番号。
セグメンテーションビット：メッセージがセグメント化されるかどうかを示す。
セグメントシーケンス番号：ＡＤＤＳメッセージの個々のセグメントのシーケンス番号。これは、セグメンテーションビットＩＥが‘００’に設定されない場合のみ有効である。
チェックサム：ペイロードの完全性チェックのためのチェックサム。
拡張ヘッダ情報：これは、エラー情報、セキュリティ等のような付加的情報が搬送される場合に使用されてもよい。

さらに図７に示されるように、ＡＤＤＳ共通ヘッダの後には、メッセージタイプに応じて、ゼロまたはそれを上回る情報要素（ＩＥ）が続き、次いで、伝送されているデータに特有であるヘッダ、次いで、アプリケーションペイロードフィールド内のアプリケーションデータ自体が続く。

以下は、ＡＤＤＳサービスの一実施形態による、伝送され得るＡＤＤＳメッセージのリストである。これらのメッセージのコンテンツは、それらを利用する種々のＡＤＤＳプロシージャの説明に関連して以下で説明される。
ＡＤＤＳアプリケーション登録要求
ＡＤＤＳアプリケーション登録応答
ＡＤＤＳアプリケーションイベント通知
ＡＤＤＳアプリケーションイベント応答
ＡＤＤＳアプリケーション更新要求
ＡＤＤＳアプリケーション更新応答
ＡＤＤＳデータ転送要求＊
ＡＤＤＳデータ転送容認
ＡＤＤＳデータ配信＊
ＡＤＤＳデータ転送完了
ＡＤＤＳデータ通知
ＡＤＤＳデータ通知確認応答
ＡＤＤＳデータクエリ
ＡＤＤＳデータクエリ確認応答
ＡＤＤＳデータ要求
ＡＤＤＳイベント加入要求
ＡＤＤＳイベント加入確認応答
ＡＤＤＳアプリケーション登録解除要求
ＡＤＤＳアプリケーション登録解除応答
メッセージタイプのうちの特定のものの隣のアスタリスク（「＊」）は、メッセージタイプがアプリケーションデータを搬送し得ることを示す。

（ＡＤＤＳプロシージャ）
本節は、その機能性を提供するためにＡＤＤＳサービスによって実行され得る、いくつかのプロシージャを説明する。これらのプロシージャは、ＡＤＤＳアプリケーション登録、ＡＤＤＳ更新プロシージャ、ＡＤＤＳデータ転送、ＡＤＤＳイベント加入、およびＡＤＤＳアプリケーション登録解除を含む。他の実施形態では、より多いまたは少ないプロシージャが提供されてもよい。これらのプロシージャのそれぞれが、以下でさらに完全に議論される。

（ＡＤＤＳアプリケーション登録）
アプリケーション登録プロシージャの目的は、ＡＤＤＳ機能性を使用することを必要とするアプリケーションにアプリケーション識別子を割り当てることである。エンドノード内のアプリケーションがＡＤＤＳソケットを開放するとき、ＡＤＤＳクライアントは、ＡＤＤＳアプリケーション識別子をアプリケーションに割り付けるようにネットワークＡＤＤＳエンティティに要求するために、「ＡＤＤＳアプリケーション登録」プロシージャを開始する。ＡＤＤＳエンティティは、要求エンドノード（ＵＥまたはＳＣＳ）の加入情報のため、およびデバイス識別子をＩＭＳＩまたはＳＣＳ ＩＤのような内部識別子に変換するための要求をＨＳＳ／ＵＤＲに提出する。次いで、ＡＤＤＳエンティティは、アプリケーション識別子を割り付け、デバイス識別子（例えば、ＵＥ ＩＤまたはＳＣＳ ＩＤ）（本明細書では「デバイスＩＤ」とも称される）とのアプリケーション識別子のマッピングを維持する。ＡＤＤＳエンティティはまた、アプリケーションのために実施されるポリシーおよび課金詳細を入手するように、アプリケーション詳細をＰＣＲＦに提供してもよい。

ネットワークは、アプリケーションを登録しようとしているエンドノードに応じて、付加的ステップを行なってもよい。例えば、プロシージャがＵＥ内のアプリケーションによって開始された場合には、ＡＤＤＳエンティティは、対応するＳＣＳをチェック／通知し、ＵＥの（アプリケーションタイプおよびアプリケーションＩＤのような）アプリケーション詳細を提供してもよい。したがって、ＳＣＳは、アプリケーション詳細を習得し、ＵＥとの将来の通信にＵＥのアプリケーションＩＤを使用することができる。ＳＣＳは、アプリケーショントラフィックの付加的ポリシーおよび課金情報を提供することができる。例えば、ＳＣＳは、その応答において、アプリケーションの遅延耐性時間、アプリケーション可用性時間、および同等物のようなアプリケーション詳細を変更することができる。ＳＣＳはまた、ＳＣＳがアプリケーショントラフィックに対して課金される必要がある場合に、適用されるオンラインまたはオフライン課金等の課金特性およびスポンサ詳細を提供することもできる。図１３は、その一実施形態による、本プロシージャのための例示的呼び出しフローを示す。

ステップ１では、ＡＤＤＳクライアント３２４が、上記で説明されるＡＤＤＳ広告プロシージャのうちの１つを通して、ネットワークＡＤＤＳエンティティ３２２の接触詳細を習得する。

ステップ２では、アプリケーションが、ＡＤＤＳクライアント３２４に登録するためにＡＤ２インターフェースＡＰＩを使用する。

ステップ３では、ＡＤＤＳクライアント３２４が、アプリケーションのアプリケーション識別子を要求するように、「ＡＤＤＳアプリケーション登録要求」をＡＤＤＳエンティティ３２２に送信する。本メッセージは、ＡＤ１インターフェースを経由して送信され、本メッセージは、利用可能なトランスポート機構（例えば、ＮＡＳ、ＳＭＳ、ＵＳＳＤ、ユーザプレーン）のうちのいずれかを経由して送信されることができる。一実施形態では、以下の情報が、本メッセージの中で送信される。
（ａ．ＡＤＤＳメッセージタイプ：）
これは、メッセージが「ＡＤＤＳアプリケーション登録要求」メッセージであることを示す。
（ｂ．デバイスタイプ：）
これは、アプリケーションが作動しているエンドノートが、ＵＥまたはＳＣＳのようなネットワークエンティティであるかどうかを示すものである。
（ｃ．デバイス識別：）
デバイスを一意に識別するためにネットワークによって使用されることができる、デバイス識別子。これは、ネットワークによって割り付けられた識別子、または大域的に公知である／分解可能な識別子であり得る。以下は、デバイス識別に使用されることができる、いくつかの識別子である。使用される識別子は、エンドノードタイプに依存する。
（ＵＥに関して）
ｉ．ＩＭＳＩ
ｉｉ．ＭＳＩＳＤＮ
ｉｉｉ．ＧＵＴＩ／ＰＴＭＳＩ
ｉｖ．ネットワーク割当ＩＰアドレス（ＵＥがＮＡＴデバイスの背後にある場合、ローカルＩＰではない）
ｖ．Ｍ２Ｍ外部識別子
ｖｉ．ＳＩＰ ＵＲＩ
ｖｉｉ．ＮＡＩ
（ネットワークノードに関して）
ｉ．ＳＣＳ ＩＤ／外部ＩＤ
ｉｉ．ＦＱＤＮ
ｉｉｉ．ＳＩＰ ＵＲＩ
ｉｖ．ＮＡＩ
ｖ．ＩＰアドレス
（ａ．要求されたアプリケーション識別子）
これは、随意のフィールドであり、有効なアプリケーション識別子を含有する。アプリケーションは、それに割り付けられるアプリケーション識別子を要求することができる。通常、これは、アプリケーションが前もって登録され、アプリケーション再開または失敗もしくはアプリケーションが別のデバイスに移動した後に、同一のアプリケーション識別子を再利用したい場合に、使用されてもよい。しかしながら、これはまた、具体的アプリケーションＩＤを要求するために、前もって登録されなかったアプリケーションによって使用されてもよい。
（ｂ．セキュリティトークン）
本フィールドは、アプリケーションがそれに前もって割り付けられたアプリケーション識別子の再利用を要求する場合に含まれてもよい。これは、前もってアプリケーションＩＤをアプリケーションに割り当てたときに、ＡＤＤＳエンティティによって提供されたセキュリティトークン値と同一であり得る。これは、ある他のアプリケーションがアプリケーションを欺こうとしていないことを認証するものとする。これは、そのメッセージを受信するよう、別のアプリケーションのアプリケーションＩＤを不当に請求することから他のアプリケーションを回避させるように、認証目的のためのものである。
（ｃ．アプリケーション詳細）
本フィールドは、アプリケーション特性および詳細を含有する。これは、データスケジューリングおよびトランスポート機構／パス選択目的でＡＤＤＳによって使用されることができる。
−アプリケーションタイプ
−アプリケーション名
−アプリケーションインスタンス
−アプリケーション特性
遅延耐性−アプリケーションへ、またはアプリケーションから向かうことになっているメッセージがどれだけ遅延させられ得るか
アプリケーション可用性−アプリケーションが利用可能になるであろう時間周期
最大メッセージサイズ−アプリケーションが送信／受信するであろうメッセージの最大サイズ
ＵＬ最大サイズ
ＤＬ最大サイズ
周期性−これは、どれだけ頻繁にアプリケーションがＡＤＤＳを使用してデータ転送を行う意向があるかを示す。これは、アプリケーションレベルプロシージャまたはセッションに関し得る。
データ転送の持続時間−ＡＤＤＳを経由したデータ転送が使用されるであろう持続時間
メッセージ率−「データ転送の持続時間」で送信／受信されるであろうメッセージの数。これは、２つのサブフィールドを有し得る。
ＵＬメッセージ率
ＤＬメッセージ率
データの最大総量−転送されるであろうデータの最大総量。これは、２つのサブフィールドを有し得る。
ＵＬ最大データ
ＤＬ最大データ
メッセージを破棄する−通信が合意されたパラメータを超えるかどうかを示すフラグ。例えば、メッセージサイズまたは率がより高くなる場合。
許容メッセージ損失率
確実な配信
メッセージ提出レポート
メッセージ配信レポート
これらのパラメータの全ては、強制的ではない。これは、アプリケーションデータ転送要件を説明するように、アプリケーション必要性の通りに含まれることができる。例えば、温度読取アプリケーションが、時間単位で示度値を送信する必要がある場合には、以下のように特性を設定してもよい。
遅延耐性：２５分
周期性：１時間毎
転送の持続時間：５秒
最大メッセージサイズ
ＵＬ最大サイズ：１２０バイト
ＤＬ最大サイズ：８０バイト
メッセージ率
ＵＬメッセージ率：４
ＤＬメッセージ率：２
最大合計データ
ＵＬ最大データ：３５０バイト
ＤＬ最大データ：１００バイト
（ｇ．デバイス情報）
これは、随意のフィールドである。デバイスレベル情報もまた、ＡＤＤＳメッセージスケジューリングおよびルーティングにおいてＡＤＤＳエンティティを支援するように提供されてもよい。
−デバイス利用可能時間−デバイスがＭＴデータのために接触されることができるとき
−デバイス移動性情報−デバイスが静止またはローミングし得るかどうか。
（ｈ．ＡＤＤＳオプション）
（ｉ．要求されるメッセージ通知）
本オプションが設定されるとき、ＡＤＤＳエンティティは、メッセージを記憶し、ＡＤＤＳメッセージおよび（そのサイズのような）メッセージ詳細の到着についてエンドノードに知らせてもよい。ＡＤＤＳクライアントは、後になってメッセージをプル配信することができる。
（ｉｉ．通知のための最大メッセージサイズ）
通知が送信される必要がある最大メッセージサイズ
（ｉ．利用可能なトランスポートパス）
デバイスおよびそれらの特性とともに利用可能である、異なるトランスポート機構／パスのリスト。以下の情報のうちの１つまたはそれを上回るものが提供されてもよい。情報は、デバイスタイプに依存する（例えば、ＮＡＳがＵＥのみに適用可能であり得る）：
１．ＳＭＳ
ａ．ＳＭＳ−ＳＣアドレス
ｂ．デバイスのＭＳＩＳＤＮ
ｃ．最大メッセージサイズ
ｄ．使用されるデータコーディング
ｅ．使用されるＳＭＳアプリケーションポート番号
２．ＮＡＳ
ａ．最大メッセージサイズ
３．ＵＳＳＤ
ａ．ＵＳＳＤコード
４．ユーザプレーン
ａ．使用されるＩＰアドレス
ｂ．使用されるトランスポートプロトコル

ステップ４では、ＡＤＤＳエンティティ３２２が、「ＡＤＤＳ加入要求」メッセージをＨＳＳ１１６に送信する。本メッセージは、以下の情報を含有してもよい。
ａ．デバイスタイプ
ｂ．デバイス識別子
ｃ．デバイス詳細
ｄ．報告されたトランスポートパス
ｅ．要求されたアプリケーション識別子

提供された「デバイス識別子」は、対応する加入記録を読み出すために、ＩＭＳＩまたは「ＳＣＳ識別」に変換される必要があり得る。ＨＳＳ／ＵＤＲは、「デバイス識別子」変換プロシージャを実行してもよく、デバイス識別子をＩＭＳＩまたは「ＳＣＳ識別」に分解するように、ＤＮＳサーバ、ＭＭＥ、ＳＧＳＮ、ＰＧＷ、もしくは同等物等のいくつかのノードに接触してもよい。「外部識別子」または「ＭＳＩＳＤＮ」等のＩＤのうちのいくつかが、ＨＳＳ／ＵＤＲ自体によって変換されてもよい。ＨＳＳ／ＵＤＲは、関連加入情報を読み出し、ＵＥまたはＳＣＳがＡＤＤＳサービスを使用する権限を与えられているかどうかをチェックする。

ステップ５では、ＨＳＳ／ＵＤＲは、以下のＡＤＤＳ認可情報を含有する、ＡＤＤＳ加入回答メッセージを送信する。
ａ．ＩＭＳＩまたはＳＣＳ識別子
ｂ．加入情報
ｉ．許容トランスポートパス
ｉｉ．加入アプリケーションＩＤ
ｉｉｉ．アプリケーションＩＤ可搬性−アプリケーションがホストデバイスを変更することができるように、アプリケーションＩＤが割り付けられるべきであるかどうかを示す
ｉｖ．デバイス特性−デバイス移動性詳細および可用性時間等のような加入／制約デバイス特性（例えば、ＭＴＣ特徴）
ｖ．ピア情報−対応するＳＣＳおよびＳＣＳに報告されるイベントのような情報

ステップ６では、ＡＤＤＳエンティティが、ＡＤＤＳ特有のポリシーおよび課金情報を要求するように、「ＡＤＤＳポリシー応答」メッセージをＰＣＲＦに送信する。本メッセージは、以下の情報を含有してもよい。
ａ．ＩＭＳＩまたはＳＣＳ識別子
ｂ．アプリケーション詳細／特性

ステップ７では、ＰＣＲＦ３３４が、アプリケーションに使用されるポリシーおよび課金詳細を提供する、「ＡＤＤＳポリシー応答」メッセージで応答する。本メッセージは、以下の情報を含有してもよい。
ａ．ポリシー情報−メッセージスケジューリング、サイズ、およびルーティング情報
ｂ．課金情報

ステップ８では、ＡＤＤＳエンティティ３２２が、そのデバイスのうちの１つがＡＤＤＳのためのアプリケーションを登録したことをＳＣＳ等のエンドノードに通知するように、「ＡＤＤＳアプリケーションイベント通知」メッセージを送信する。関心があるアプリケーションは、以下で説明される「ＡＤＤＳイベント加入プロシージャ」の通りに、本イベントに登録してもよい。以下の詳細が、本メッセージにおいて送信されてもよい。
ａ．宛先アプリケーションＩＤ−通知を受けるはずである宛先アプリケーション
ｂ．起こったイベントタイプ：これは、「アプリケーション登録イベント」に送信されてもよい
ｃ．アプリケーションＩＤ−登録アプリケーションに割り付けられたアプリケーションＩＤ
ｄ．デバイス情報
ｅ．ステップ３ｆに説明されるようなアプリケーション詳細

ステップ９では、エンドノードが、「ＡＤＤＳアプリケーションイベント応答」メッセージを送信する。ＳＣＳは、ある認可情報、また、アプリケーションに伝えられる必要がある、ある情報で応答してもよい。本メッセージは、以下の情報を含有してもよい。
ａ．ポリシー情報−適用されるアプリケーション特性
ｂ．課金情報−適用されるオフライン・オンライン課金、およびアプリケーションがＳＣＳによって後援されるかどうかのような情報
ｃ．アプリケーション制約−ＵＥアプリケーションが他のアプリケーションと通信することを許可されるか、またはその通信がＳＣＳのみに制約されるべきであるかどうかのような情報。ＡＤＤＳエンティティは、いかなる他のエンドノードもメッセージをＵＥのアプリケーションに送信していない、および／またはＵＥも他のエンドノードに送信してないことを確実にすることができる。
ｄ．ピアアプリケーション情報−ＵＥに提供される対応するＳＣＳアプリケーションＩＤおよびその特性のような情報

ステップ１０では、ＡＤＤＳエンティティが、「ＡＤＤＳアプリケーション登録容認」メッセージをエンドノード内のＡＤＤＳクライアントに送信する。本メッセージは、以下の情報を含有してもよい。
ａ．許容アプリケーション識別子
ｂ．アプリケーションＩＤ可搬性
ｃ．アプリケーションＩＤリース時間
ｄ．許容トランスポートパスおよびそれらの特性。これは、表６ ２に列挙される情報に類似する。
ｅ．交渉アプリケーション特性−これは、ネットワークが容認した最終アプリケーション特性であろう。
ｆ．セキュリティトークン
ｇ．ピアアプリケーション情報

最後に、ステップ１１では、ＡＤＤＳクライアントが、ＡＤＤＳエンティティから受信される情報をアプリケーションにパスする。本情報は、以下を含有してもよい。
ａ．許容アプリケーション識別子
ｂ．アプリケーションＩＤ可搬性
ｃ．アプリケーションＩＤリース時間
ｄ．交渉アプリケーション特性
ｅ．セキュリティトークン
ｆ．ピアアプリケーション情報

（ＡＤＤＳ更新プロシージャ）
ＡＤＤＳクライアント３２４またはネットワークＡＤＤＳエンティティ３２２は、ＡＤＤＳ能力もしくはアプリケーション特性の任意の変更について知らせるように、ＡＤＤＳ更新プロシージャを行なってもよい。本プロシージャは、（エンドノード上の全てのアプリケーションに影響を及ぼす）パスレベル変更または（アプリケーション特性のような）アプリケーションレベルあたりの変更についてＡＤＤＳに知らせるために使用されてもよい。以下の特性および能力が、本プロシージャを使用して更新されてもよい。
１．データパス変更
２．アプリケーション特性変更
３．ＵＥ特性変更
４．ＡＤＤＳオプション変更
５．加入変更
６．アプリケーションＩＤ更改

本プロシージャは、エンドノードまたはネットワークＡＤＤＳエンティティによって開始されてもよく、プロシージャは、どのエンティティがプロシージャを開始するかに基づいて若干異なる。両方の変形例が、図１４に示される。

（エンドノード開始ＡＤＤＳ更新プロシージャ）
エンドノード内のＡＤＤＳクライアントは、以下のイベントに基づいて、ＡＤＤＳ更新メッセージを送信することを決定してもよい。
ａ．アプリケーション指示。アプリケーションが、ＡＤＤＳクライアントへのその通信要件／特性を更新する。
ｂ．ユーザプロビジョニング：エンドノードのユーザが、利用可能であるトランスポートパスまたはそれらの特性のようなノードのＡＤＤＳ能力に影響を及ぼす、いくつかのノードレベルパラメータを変更している。
ｃ．アプリケーションＩＤ更改−アプリケーションＩＤリースタイマが、満了しようとしているところであり、更新される必要がある。

図１４のステップＡ１−Ａ６は、エンドノードがＡＤＤＳ更新プロシージャを開始して行う、プロセスの一実施形態を図示する。示されるように、ステップＡ１では、ＡＤＤＳクライアントは、以下の情報を含有し得る「ＡＤＤＳ更新要求」メッセージをＡＤＤＳエンティティに送信する。
ａ．ＡＤＤＳメッセージタイプ−これが「ＡＤＤＳ更新要求」メッセージであることを示す。
ｂ．更新タイプ−これは、アプリケーションレベルまたはエンドノードレベルであり得る。これは、以下の値のうちのいずれかをとることができる。
ｉ．アプリケーション特性更新
ｉｉ．アプリケーションＩＤ更改
ｉｉｉ．デバイス特性更新
ｉｖ．利用可能なトランスポートパス
ｖ．ＡＤＤＳオプション更新
注記：以下のＩＥの包含は、更新タイプに依存する。これらのＩＥは、６．７．１のステップ３で詳細に説明される。
ｃ．アプリケーションＩＤ−これは、具体的アプリケーション詳細が更新される必要がある場合に含まれる。
ｄ．アプリケーション詳細
ｅ．デバイス情報
ｆ．ＡＤＤＳオプション
ｇ．デバイス識別−デバイスが、「ＡＤＤＳアプリケーション登録プロシージャ」において提供した同一の識別を提供する必要がある。

ステップＡ２では、ＡＤＤＳエンティティが、更新された特性に基づいて更新されたポリシー情報を入手するように、「ＡＤＤＳポリシー更新要求」メッセージをＰＣＲＦに送信する。

ステップＡ３では、ＰＣＲＦが、更新されたポリシーおよび課金情報とともに「ＡＤＤＳポリシー更新応答」メッセージを送信する。

ステップＡ４では、ＡＤＤＳエンティティが、「ＡＤＤＳアプリケーションイベント通知」メッセージをピアアプリケーションエンドノードに送信する。本メッセージは、ピアアプリケーションエンドノード情報が加入情報の中で利用可能である場合、またはノードが以下で説明される「ＡＤＤＳイベント加入プロシージャ」を使用して通知に加入した場合に、送信されてもよい。本ステップは、図１３のステップ８に類似する。

ステップＡ５では、エンドノードは、「ＡＤＤＳアプリケーションイベント応答」メッセージを送信する。本ステップは、図１３のステップ９に類似する。

ステップＡ６では、ＡＤＤＳエンティティは、ネットワークによって容認されるパラメータを提供するように、「ＡＤＤＳ更新応答」メッセージを送信する。本メッセージは、図１３のステップ１０に説明される「ＡＤＤＳ登録容認」メッセージに類似する情報を含有する。

（ネットワーク開始ＡＤＤＳ更新プロシージャ）
ネットワーク内のＡＤＤＳエンティティは、ある変更について知らせるように、または使用される必要があるトランスポートパスについてコマンドを提供するように、ＡＤＤＳ更新コマンドメッセージをＡＤＤＳクライアントに送信することを決定してもよい。本メッセージは、以下のイベントに基づいて送信されてもよい。
ａ．オペレータプロビジョニング
ｂ．オーバーロード状態または他のノード／サービス可用性のようなネットワーク状態
ｃ．ＰＣＲＦからのポリシー変更通知
ｄ．ＨＳＳ／ＵＤＲからの加入変更通知

図１４のステップＢ１−Ｂ４は、ネットワークＡＤＤＳエンティティがＡＤＤＳ更新プロシージャを開始して行う、プロセスの一実施形態を図示する。

示されるように、ステップＢ１では、ＡＤＤＳエンティティが、「ＡＤＤＳ更新コマンド」メッセージをエンドノード内のＡＤＤＳクライアントに送信する。本更新は、具体的アプリケーション用またはエンドノード用であってもよい。本メッセージは、以下の情報を含有してもよい。
ａ．ＡＤＤＳメッセージタイプ−これが「ＡＤＤＳ更新コマンド要求」メッセージであることを示す。
ｂ．更新タイプ−具体的アプリケーションが影響を受けるか、またはエンドノートが影響を受けるかどうかを示す。
注記：以下のＩＥの包含は、更新タイプに依存する。これらのＩＥは、図１３に関連して上記で詳細に説明される。
ｃ．アプリケーションＩＤ−これは、具体的アプリケーション詳細が更新される必要がある場合に含まれる。
ｄ．アプリケーションＩＤリース時間
ｅ．交渉アプリケーション特性
ｆ．ＡＤＤＳエンティティトランスポートパス情報

ＡＤＤＳクライアントは、情報を受信し、それに応じてそれ自体を構成する。これは、随意に、更新される情報に基づいて、影響を受けたアプリケーションに知らせてもよい。

ステップＢ２は、上記のステップＡ４に類似し、ステップＢ３は、上記のステップＡ５に類似する。

ステップＢ４では、ＡＤＤＳクライアントは、ＡＤＤＳクライアントが提供された情報でそれ自体を更新したことを確認するように、「ＡＤＤＳ更新コマンド応答」をＡＤＤＳエンティティに送信する。

（ＡＤＤＳデータ転送）
ＡＤＤＳデータ転送プロシージャは、ＡＤＤＳを使用してデータを転送するために、アプリケーションによって使用されるプロシージャである。本プロシージャは、ＡＤＤＳエンドノード（ＳＣＳ／ＵＥ）に常駐するアプリケーションが、ＡＤＤＳを使用してアプリケーション特有のデータを送信することを可能にする。ＡＤＤＳエンドノードは、宛先識別子としてアプリケーション識別子を使用し、アプリケーションデータおよびその特性を基礎的ＡＤＤＳクライアントにパスする。ＡＤＤＳクライアントは、メッセージをＡＤＤＳサーバにトランスポートするように配信機構／パスを選定する。ＡＤＤＳクライアントはまた、アプリケーションデータのサイズが、（例えば、ＮＡＳおよびＳＭＳの場合に）選定されたトランスポートプロトコルによってサポートされるペイロードの最大限界を超える場合に、アプリケーションデータにセグメンテーションを行なってもよい。ＡＤＤＳエンティティは、データを宛先アプリケーションに配信する時間および方法を決定する際に、ネットワークポリシー、負荷状態、エンドノード状態、ならびにアプリケーションデータ特性を考慮する。ＡＤＤＳエンティティは、課金制御目的でＯＦＣＳおよびＯＣＳと相互作用してもよい。

送信アプリケーションは、確実なデータ配信を要求することができ、データの受信を承認し、また、ＡＤＤＳメッセージが宛先アプリケーションに失敗なく配信されるときについての配信レポートを提供するようにＡＤＤＳに要求してもよい。

（データ配信通知プロシージャ）
一実施形態では、受信アプリケーション／エンドノードが、（アプリケーション登録プロシージャに関連して上記のように）ＡＤＤＳメッセージを配信する前に、それらについて通知されることをＡＤＤＳに要求した場合には、ＡＤＤＳエンティティは、メッセージについての詳細を含有する通知をエンドノードに送信する。次いで、エンドノード／アプリケーションは、後になって、本メッセージを読み出す具体的要求を送信することができる。随意に、エンドノードは、メッセージが即時に配信される必要がある場合に、通知確認応答メッセージの中でフラグを設定し、または配信試行が行われ得る時間周期を提供することができる。

（データクエリ／ポーリングプロシージャ）
一実施形態では、ＡＤＤＳクライアントまたはアプリケーションは、任意のデータが配信されるよう保留中であるかどうかをチェックするように、クエリをＡＤＤＳエンティティに送信し、メッセージ詳細を要求する、または実際のメッセージが配信されることを要求することができる。

（登録を伴わないデータ転送）
一実施形態では、ソースアプリケーションを登録することなく、アプリケーションがデータ転送要求を送信することが可能である。そのような場合において、ＡＤＤＳは、メッセージを配信しようとする前に、認可についてＨＳＳ１１６／ＵＤＲおよびＰＣＲＦ３３４をチェックしてもよい。

また、受信アプリケーションも登録されていない可能性がある。これは、例えば、予約アプリケーション識別子が使用される場合である。ここで、データ転送要求メッセージは、加えて、メッセージが正しいエンドノードに配信され、予約アプリケーション識別子のためにマークされる、そのエンドノード内のアプリケーションがメッセージを受信するように、デバイス識別子を有してもよい。

しかしながら、これら両方の場合において、送信および受信エンドノードは、それらのＡＤＤＳ能力をネットワークに示していたはずである。

図１５は、プロシージャのデータメッセージ通知、クエリ、および要求部分を含む、一実施形態による、ＡＤＤＳデータ転送プロセスを図示するフロー図である。

示されるように、ステップ１では、ＵＥまたはＳＣＳ３４０内のＡＤＤＳクライアントは、ＡＤＤＳデータ転送要求をＡＤＤＳエンティティ３２２に送信する。上記のように、ＡＤＤＳクライアントは、パス選択の節で上記に説明される様式において、トランスポート機構／パスを選定する。例えば、ＡＤＤＳクライアントは、例えば、メッセージのサイズ、トランスポートパスの状態、およびデバイス状態（アイドルモードであるかどうか等）を含む、種々の基準に基づいて、トランスポート機構／パスを選択してもよい。一実施形態では、以下の情報が、本メッセージにおいて送信される。
ａ．ＡＤＤＳメッセージタイプ：
これは、メッセージが「ＡＤＤＳデータ転送要求」メッセージであることを示す。
ｂ．ソースアプリケーション識別子：
そのアプリケーション登録プロシージャ中にアプリケーションによってフェッチされるアプリケーション識別子または予約アプリケーション識別子
ｃ．宛先アプリケーション識別子：
アプリケーションがデータを送信することを意図するアプリケーション識別子
ｄ．宛先デバイス識別子
これは、随意のフィールドであり、「宛先アプリケーション識別子」が予約アプリケーション識別子である場合に含まれる。本フィールドは、図１３のステップ３に説明される。
ｅ．アプリケーションデータ：
エンドアプリケーションに配信される必要がある実際のデータを含有する、アプリケーション特有のデータ
ｆ．アプリケーションデータ特性：
データおよび配信命令の特性が、本ＩＥの中で提供される。
メッセージ重要性が、以下のように提供されてもよい。
ｉ．重要
ｉｉ．通常
ｉｉｉ．不必要
加えて、エンドアプリケーションへの配信または通知の時間もまた、提供されてもよい。メッセージが有効性周期内に配信されることができなかった場合に、ＡＤＤＳエンティティから削除されるように、メッセージ有効性フィールドもまた、提供されてもよい。
ｇ．提出状態通知
本フラグは、ＡＤＤＳエンティティがＡＤＤＳメッセージの成功した受信について確認応答をソースアプリケーションに送信するべきであるかどうかを示す。
ｈ．配信状態通知
メッセージが失敗なく宛先アプリケーションに配信された後に、ソースアプリケーションが配信レポートを受信することを希望するかどうかをＡＤＤＳエンティティに示す。

ステップ２では、ＡＤＤＳエンティティは、送信アプリケーションおよび／または受信アプリケーションが前もって登録されていない場合に、認可情報についてＨＳＳ１１６／ＵＤＲならびにＰＣＲＦ３３４をチェックしてもよい。本プロシージャは、図１３に説明される方法で行われるチェックに類似する。本プロシージャはまた、「宛先デバイス識別子」をＩＭＳＩ／ＳＣＳ ＩＤ等のローカル識別子に変換するために使用されてもよい。

ステップ３では、オンライン課金が使用される場合には、ＡＤＤＳエンティティが、ＡＤＤＳデータ転送プロシージャの認可のために、３ＧＰＰ ＴＳ ３２．２９６で説明されるクレジット制御プロシージャを行なってもよい。

ステップ４では、ＡＤＤＳサーバが、メッセージが配信のために容認されたことを承認する、ＡＤＤＳデータ転送容認メッセージを送信する。これは、随意のメッセージであり、「提出状態通知」フラグが「ＡＤＤＳデータ転送要求」メッセージの中で設定される場合のみ送信される。メッセージは、サーバが宛先アプリケーション識別子を無効として識別した、または十分なクレジットが利用可能ではない場合に、エラーコードを含有し得る。エラーコードはまた、（アプリケーションデータ特性フィールドにおいて要求されるような）要求機能性がサポートされなかった場合に通知し得る。ＡＤＤＳエンティティは、メッセージを記憶し、または通知を送信し、もしくはアプリケーション特性およびネットワーク状態の通りにメッセージを配信しようとしてもよい。

ステップ５では、受信エンドノードが「ＡＤＤＳデータ通知」メッセージを要求した場合に、ＡＤＤＳエンティティが、そのような通知を受信エンドノードに送信する。本実施形態では、本メッセージは、以下の情報を含有する。
ａ．メッセージサイズ
ｂ．メッセージ識別番号（これは、メッセージのシーケンス番号、またはＡＤＤＳによって割り付けられる一時的識別子であり得る）
ｃ．送信アプリケーション識別子
ｄ．受信アプリケーション識別子
ｅ．メッセージ重要度
ｆ．メッセージ有効性

ステップ６では、エンドノードが、メッセージに留意したことを示す、「ＡＤＤＳデータ通知確認応答」メッセージを送信する。本メッセージはまた、随意に、示されたメッセージが即時に配信される必要があるというフラグと、メッセージがその時間に配信される必要があることを示す別の随意の時間周期値とを含有してもよい。即時配信が要求される場合には、１０から先のステップが、本時点で行われる。

そうでなければ、ステップ７では、ＡＤＤＳクライアントが、保留メッセージについての情報または保留メッセージの配信を要求するように、「ＡＤＤＳデータクエリ」メッセージをＡＤＤＳエンティティに送信してもよい。

ステップ８では、ＡＤＤＳエンティティは、保留メッセージについての情報を提供する、「ＡＤＤＳデータクエリ」確認応答メッセージを送信する。本メッセージは、保留メッセージのそれぞれについて、ステップ５に列挙されるような情報を含有してもよい。実際のメッセージ配信が要求された場合には、ステップ１０から先のステップが行われる。

ステップ９では、エンドノードが、「データ要求」メッセージをＡＤＤＳエンティティに送信し、（上記のステップ５のように）それが前もって通知された、またはステップ７でＡＤＤＳクエリメッセージにおいて知らされた、具体的メッセージの配信を要求してもよい。本メッセージは、要求されているメッセージを識別するように、「メッセージ識別番号」を含有してもよい。ステップ１０から先のステップは、本メッセージの受信後に行われる。

ステップ１０では、ＡＤＤＳエンティティが、アプリケーションデータを配信するように、「ＡＤＤＳデータ配信」メッセージを送信する。ＡＤＤＳエンティティは、データ配信のためのトランスポートパスを選択してもよい。ＡＤＤＳエンティティは、そのマッピングテーブルから、ＳＭＳのＭＳＩＳＤＮ、ＮＡＳのＩＭＳＩ、およびユーザプレーンのＩＰアドレスのような選択されたパスのエンドノードアドレス指定情報を見出すために、宛先アプリケーション識別子を使用する。ＡＤＤＳエンティティ３２２は、選択されたパスのためのメッセージ（ＩＰヘッダ等）を構築し、メッセージを送信してもよい。以下の情報が、本メッセージの中に存在し得る。本情報の一部は、ステップ１において上記で説明される。
ａ．ＡＤＤＳメッセージタイプ：
これは、メッセージが「ＡＤＤＳデータ配信」メッセージであることを示す。
ｂ．ソースアプリケーション識別子：
ｃ．宛先アプリケーション識別子：
ｄ．アプリケーションデータ：
ｅ．アプリケーションデータ特性：
「メッセージ重要性」等のステップ１で列挙される情報の一部が提供されてもよい。
ｆ．配信状態指示
本フラグは、受信ノードがＡＤＤＳメッセージの成功した受信を承認するべきかどうかを示す。

ステップ１１では、エンドノードが、メッセージが失敗なく取り扱われた／エンドアプリケーションに配信されたことを示すように、「ＡＤＤＳデータ配信確認応答」メッセージを送信する。本メッセージは、任意の復号失敗のようなメッセージを取り扱うことのエラーがある場合、または（「宛先アプリケーション識別子」によって示される）エンドアプリケーションが利用可能ではない場合に、エラーコードを含有してもよい。

本メッセージはまた、返信データパケットをソースアプリケーションに搬送するように増進されてもよい。この場合、本メッセージは、ステップ１に列挙されるような情報を含有してもよい。ソースアプリケーションＩＤ、宛先アプリケーションＩＤのような情報の一部は、省略されてもよく、これは、ＡＤＤＳエンティティによって記入されることができる。本目的で、ＡＤＤＳエンティティは、「ＡＤＤＳデータ配信確認応答」メッセージを受信するまで、実際のメッセージを保持してもよい。データが本メッセージにおいて送信される場合には、「ＡＤＤＳデータ転送要求」メッセージに類似すると見なされてもよく、ステップ１からのステップが辿られてもよい。

ステップ１２では、ＡＤＤＳエンティティが、「ＡＤＤＳデータ転送完了」メッセージを発信アプリケーションに送信することによって、メッセージの成功した配信を示すように、配信レポートをソースアプリケーションに提供する。本メッセージは、メッセージ配信のタイムスタンプを含有してもよい。

最後に、ＡＤＤＳエンティティは、ＡＤＤＳメッセージ配信の課金目的で、課金詳細をＯＦＣＳ３３２に提供してもよい。

（ＡＤＤＳイベント加入）
図１６は、その一実施形態による、ＡＤＤＳイベント加入のための方法を図示する。アプリケーションは、イベント加入をＡＤＤＳ３２２に送信し、例えば、登録解除等のこれらのアプリケーションで起こるイベントを通知されるべきであるアプリケーション識別子のリストを提供してもよい。ＡＤＤＳエンティティ３２２は、そのメモリに本情報を記憶し、イベントについての通知を要求されたアプリケーションに送信する。

図１６を参照すると、ステップ１では、エンドノード（例えば、ＵＥ２１４またはＳＣＳ３４０）が、「ＡＤＤＳイベント加入要求」メッセージをＡＤＤＳエンティティに送信する。本メッセージは、以下の情報を含有してもよい。
ａ．ソースアプリケーションＩＤ：通知される必要があるアプリケーション
ｂ．ソースデバイスＩＤ：本フィールドは、随意であり、ソースアプリケーションがＡＤＤＳに登録されない場合、または予約アプリケーションＩＤが使用される場合に含まれる。
ｃ．イベント加入リスト
ｉ．標的アプリケーションＩＤ
ｉｉ．標的デバイスＩＤ：これは、標的アプリケーションＩＤが把握されていない場合に含まれてもよい。例えば、ＳＣＳがＵＥからアプリケーション登録イベントについて把握したい場合には、ＳＣＳは、（図１３の説明に関連して上記で記述されるように）ＵＥがアプリケーションを登録するときにＳＣＳが通知されるように、ＵＥの外部識別子を提供してもよい。
ｉｉｉ．加入したイベント：通知が必要とされるイベントのリスト。一実施形態では、イベントは、以下であってもよい。
１．アプリケーション登録
２．アプリケーション登録解除
３．アプリケーション移動（例えば、アプリケーションがホストデバイスを変更する）

ステップ２では、ＡＤＤＳエンティティが、容認されたイベントのリストを提供するように、「ＡＤＤＳイベント加入確認応答」メッセージを送信する。

（アプリケーション登録解除）
図１７は、アプリケーション登録解除のための方法を図示する。登録解除は、エンドノードによって（図１７のステップＡ１−Ａ４）によって、またはネットワークによって（図１７のステップＢ１−Ｂ４）によって開始されてもよい。アプリケーション登録解除プロシージャは、エンドノードがＡＤＤＳのそれらの使用を正常に終了することを可能にする。アプリケーションが登録解除するとき、ＡＤＤＳエンティティ３２２は、割り付けられたアプリケーションＩＤを解放し、それと関連付けられるトランスポートマッピングを除去する。ＡＤＤＳエンティティはまた、登録解除について他の関心があるアプリケーションに通知してもよい。

一実施形態では、ＡＤＤＳクライアントは、（アプリケーションＩＤおよびデバイス情報のマッピング詳細のような）任意のアプリケーション特有のデータを除去し、プロシージャの終了についてアプリケーションに知らせてもよい。

一実施形態では、ネットワークは、以下の理由のうちのいずれかでプロシージャを開始してもよい。
１．ＡＤＤＳ加入撤回
２．アプリケーションＩＤリース時間満了
３．ＰＣＲＦから示されるポリシーに基づく
４．クレジットの非可用性についてのＯＣＳからの指示

また、一実施形態では、本プロシージャは、以下の理由のうちのいずれかでエンドノードによって開始されてもよい。
１．アプリケーションシャットダウン
２．ＡＤＤＳクライアントシャットダウン
３．アプリケーションからの指示

いくつかのシナリオでは、アプリケーションが、ＡＤＤＳ通信を閉鎖したいのみであり得る一方で、ユーザプレーンパスを経由して、その通常のデータ通信を継続し得ることに留意されたい。

アプリケーションが登録解除されるとき、関心があるアプリケーションまたはエンドノードは、それについて通知されてもよい。通知されるアプリケーションまたはエンドノードは、以下に基づいて決定されてもよい。
１．登録解除されているアプリケーションによって提供されるリスト
２．図１６に関連して上記のような他のアプリケーションからのイベント加入
３．ＨＳＳ／ＵＤＲからの加入情報

（エンドノード開始登録解除）
図１７のステップＡ１−Ａ４は、エンドノード開始登録解除を図示する。示されるように、ステップＡ１では、ＡＤＤＳエンドノードが、「ＡＤＤＳアプリケーション登録解除要求」メッセージをＡＤＤＳエンティティ３２２に送信する。本メッセージは、以下の情報を含有してもよい。
ａ．メッセージタイプ：
これは、「ＡＤＤＳアプリケーション登録解除要求」に設定されるであろう。
ｂ．登録解除の原因：
ＡＤＤＳクライアントシャットダウンまたはアプリケーションシャットダウン等のような登録解除の理由
ｃ．登録解除応答フラグ：
本フラグは、ＡＤＤＳエンドノードが登録解除応答を期待するかどうかを示す。いくつかの小型／制約付きデバイスは、本フラグを、応答を送信しないようにＡＤＤＳエンティティに示すＦＡＬＳＥに設定してもよい。本フラグはまた、ＡＤＤＳクライアントがシャットダウンされるときに、ＦＡＬＳＥに設定されてもよい。
ｄ．アプリケーション識別子：
登録解除される必要があるアプリケーション識別子
ｅ．通知リスト：
登録解除について通知される必要がある、他のアプリケーション識別子のリスト。ＡＤＤＳクライアントがシャットダウンされる場合には、「アプリケーション識別子」のリストおよび各アプリケーションＩＤの「通知リスト」が提供されてもよい。

ステップＡ２では、ＡＤＤＳエンティティ３２２が、「ＡＤＤＳアプリケーションイベント通知」メッセージを、通知されるアプリケーション／エンドノードに送信する。本メッセージは、以下の情報を含有してもよい。
ａ．宛先アプリケーションＩＤ：
本通知を受信するはずである宛先アプリケーション
ｂ．起こったイベントタイプ：
これは、「アプリケーション登録解除」に設定されるであろう。
ｃ．登録解除の原因
ｄ．影響を受けたアプリケーションＩＤ：
登録解除されているアプリケーションＩＤ
ｅ．デバイス情報：
これは、アプリケーションが常駐していたエンドノードについての情報を含有してもよい。

ステップＡ３では、エンドノードが、イベント通知メッセージを受信したことを確認するように、「ＡＤＤＳアプリケーションイベント通知確認応答」メッセージをＡＤＤＳエンティティ３２２に送信する。

最後に、ステップＡ４では、ＡＤＤＳエンティティが、登録解除プロシージャが完了したことを知らせるように、「ＡＤＤＳ登録解除容認」メッセージをエンドノードに送信する。

（ネットワーク開始登録解除）
図１７のステップＢ１−Ｂ４は、ネットワーク開始登録解除を図示する。示されるように、ステップＢ１では、ＡＤＤＳエンティティ３２２が、「ＡＤＤＳアプリケーション登録解除コマンド」メッセージをエンドノードに送信し、本メッセージは、以下の情報を含有してもよい。
ａ．影響を受けたアプリケーションＩＤ：
登録解除されているアプリケーションＩＤ。これらのＩＤのリストは、１つより多くのアプリケーションが登録解除されている場合に提供されてもよい。
ｂ．登録解除原因

ステップＢ２では、ＡＤＤＳエンティティが、「ＡＤＤＳアプリケーションイベント通知」を、通知されるアプリケーション／エンドノードに送信してもよい。本メッセージは、上記のステップＡ２で説明される。本メッセージおよび上記のステップＢ１における「ＡＤＤＳアプリケーション登録解除コマンド」は、同時に送信されてもよく、順序は問題ではない。

ステップＢ３では、エンドノードが、イベント通知メッセージを受信したことを確認するように、「ＡＤＤＳアプリケーションイベント通知確認応答」メッセージをＡＤＤＳエンティティに送信する。

ステップＢ４では、ＡＤＤＳクライアントが、登録解除プロシージャが完了したことを知らせるように、「ＡＤＤＳ登録解除コマンド容認」メッセージをエンドノードに送信する。

（他の特徴）
ＥＰＣにおけるＡＤＤＳの導入およびＡＤＤＳの特徴は、Ｍ２Ｍ型通信のために有益であり得る。ＡＤＤＳは、Ｍ２Ｍ通信のための特殊化機能／サービスを提供するように増進されることができる。

一実施例として、ＡＤＤＳは、レポジトリの役割を果たし、Ｍ２ＭデバイスおよびＭ２Ｍゲートウェイに関係付けられる、ある情報を維持することができる。ＳＣＳが、ＡＤＤＳメッセージを使用して、そのような情報のクエリを行うとき、ＡＤＤＳは、メッセージを覗き見、クエリが行われているリソース名を見出し、本クエリをエンドＭ２ＭゲートウェイまたはエンドＭ２Ｍデバイスアプリケーションに転送することさえなく、本情報を自律的に提供することができる。

このようにして、ＡＤＤＳは、いくつかのＭ２Ｍアプリケーションにとって代理の役割を果たし、あるクエリに応答することができる。したがって、デバイスがオフラインであるとき、あるデータが、依然としてフェッチされてもよい。

本アプローチは、無線で送信されるメッセージの数を節約し、無線リソース、ネットワークリソース、およびデバイスバッテリ電力を節約してもよい。例えば、同一のリソース情報が、複数のネットワーク側アプリケーションによってクエリを行われる場合、ＡＤＤＳは、本情報を一度フェッチし、要求をエンドＭ２Ｍ ＧＷに実際に送信することなく、これを全ての要求アプリケーションに転送することができる。

第２の実施例として、ＡＤＤＳは、アプリケーション発見またはＭ２Ｍサービス発見を支援することができる。Ｍ２ＭアプリケーションがＡＤＤＳに登録するときはいつでも、ＡＤＤＳは、アプリケーションについての情報を記憶し、全てのアプリケーションタイプおよびそれらの詳細についてレポジトリを維持することができる。Ｍ２ＭサービスまたはＭ２Ｍアプリケーションを見出したい、新しいＭ２Ｍアプリケーションは、ＡＤＤＳにクエリを行い、サービスまたはアプリケーションを見出すことができる。

第３の実施例として、Ｍ２Ｍデバイス上のアプリケーションは、通信を確立する必要がある、ＳＣＳのＦＱＤＮを有してもよい。ＤＮＳクエリを行うＭ２Ｍデバイスの代わりに、それは、ＳＣＳ ＦＱＤＮとして宛先デバイス識別子とともにＡＤＤＳメッセージを送信することができる。ＡＤＤＳは、ＦＱＤＮを解決し、メッセージをＳＣＳに転送してもよい。本特徴は、Ｍ２Ｍデバイス上のＤＮＳ解決プロシージャを節約し、無線でのメッセージの数を削減する。

第４の実施例として、ＡＤＤＳは、ＳＣＳからブートストラッピングパラメータを受信し、ＡＤＤＳに登録するときに、それをＭ２Ｍアプリケーションに安全にパスすることができる。

（例示的ノードおよびネットワークエンティティアーキテクチャ）
図１８は、ＵＥ（例えば、図１−４Ａ−ＤのＵＥ１０４、２１４、３１２、３１８）または他のエンドノードデバイス等のＡＤＤＳクライアント３２４が常駐し得る例示的エンドノード３０の略図である。図１８に示されるように、エンドノード３０は、プロセッサ３２と、送受信機３４と、伝送／受信要素３６と、スピーカ／マイクロホン３８と、キーパッド４０と、ディスプレイ／タッチパッド４２と、非可撤性メモリ４４と、可撤性メモリ４６と、電源４８と、全地球測位システム（ＧＰＳ）チップセット５０と、他の周辺機器５２とを含んでもよい。エンドノード４０は、実施形態と一致したままで、先述の要素の任意の副次的組み合わせを含み得ることが理解されるであろう。

プロセッサ３２は、汎用プロセッサ、特殊用途プロセッサ、従来のプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアと関連する１つまたはそれを上回るマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、任意の他のタイプの集積回路（ＩＣ）、状態機械、および同等物であってもよい。プロセッサ３２は、信号符号化、データ処理、電力制御、入出力処理、および／またはエンドノード３０が無線環境で動作することを可能にする任意の他の機能性を果たしてもよい。プロセッサ３２は、伝送／受信要素３６に連結され得る、送受信機３４に連結されてもよい。図１８は、プロセッサ３２および送受信機３４を別個の構成要素として描写するが、プロセッサ３２および送受信機３４は、電子パッケージまたはチップにともに組み込まれ得ることが理解されるであろう。プロセッサ３２は、アプリケーション層プログラム、例えば、ブラウザ、および／または無線アクセス層（ＲＡＮ）プログラム、ならびに／もしくは通信を行ってもよい。プロセッサ３２は、例えば、アクセス層および／またはアプリケーション層等で、認証、セキュリティキー一致、ならびに／もしくは暗号化動作等のセキュリティ動作を行ってもよい。

伝送／受信要素３６は、信号を別のピアに伝送し、または別のピアから信号を受信するように構成されてもよい。例えば、実施形態では、伝送／受信要素３６は、ＲＦ信号を伝送および／または受信するように構成されるアンテナであってもよい。伝送／受信要素３６は、ＷＬＡＮ、ＷＰＡＮ、セルラー、および同等物等の種々のネットワークならびにエアインターフェースをサポートしてもよい。実施形態では、伝送／受信要素３６は、例えば、ＩＲ、ＵＶ、もしくは可視光信号を伝送および／または受信するように構成されるエミッタ／検出器であってもよい。さらに別の実施形態では、伝送／受信要素３６は、ＲＦおよび光信号の両方を伝送ならびに受信するように構成されてもよい。伝送／受信要素３６は、無線もしくは有線信号の任意の組み合わせを伝送および／または受信するように構成され得ることが理解されるであろう。

加えて、伝送／受信要素３６は、単一の要素として図１８で描写されているが、エンドノード３０は、任意の数の伝送／受信要素３６を含んでもよい。より具体的には、エンドノード３０は、ＭＩＭＯ技術を採用してもよい。したがって、実施形態では、エンドノード３０は、無線信号を伝送および受信するための２つまたはそれを上回る伝送／受信要素３６（例えば、複数のアンテナ）を含んでもよい。

送受信機３４は、伝送／受信要素３６によって伝送される信号を変調するように、および伝送／受信要素３６によって受信される信号を復調するように構成されてもよい。上記のように、エンドノード３０は、マルチモード能力を有してもよい。したがって、送受信機３４は、エンドノード３０が、例えば、ＵＴＲＡおよびＩＥＥＥ８０２．１１または８０２．１５等の複数のＲＡＴを介して通信することを可能にするための複数の送受信機を含んでもよい。

プロセッサ３２は、非可撤性メモリ４４および／または可撤性メモリ４６等の任意のタイプの好適なメモリから情報にアクセスし、そこにデータを記憶してもよい。非可撤性メモリ４４は、ランダムアクセスメモリ（ＲＡＭ）、読取専用メモリ（ＲＯＭ）、ハードディスク、または任意の他のタイプのメモリ記憶デバイスを含んでもよい。可撤性メモリ４６は、加入者識別モジュール（ＳＩＭ）カード、メモリスティック、セキュアデジタル（ＳＤ）メモリカード、および同等物を含んでもよい。他の実施形態では、プロセッサ３２は、サーバまたはホームコンピュータ等のエンドノード３０上に物理的に位置しないメモリから情報にアクセスし、そこにデータを記憶してもよい。

プロセッサ３２は、電源４８から電力を受容してもよく、エンドノード３０内の他の構成要素への電力を分配および／または制御するように構成されてもよい。電源４８は、エンドノード３０に電力供給するための任意の好適なデバイスであってもよい。例えば、電源４８は、１つまたはそれを上回る乾電池バッテリ（例えば、ニッケルカドミウム（ＮｉＣｄ）、ニッケル亜鉛（ＮｉＺｎ）、ニッケル水素（ＮｉＭＨ）、リチウムイオン（Ｌｉ−ｉｏｎ）等）、太陽電池、燃料電池、および同等物を含んでもよい。

プロセッサ３２はまた、エンドノード３０の現在の場所に関する場所情報、例えば、経度および緯度を提供するように構成される、ＧＰＳチップセット５０に連結されてもよい。エンドノード３０は、実施形態と一致したままで、任意の好適な場所判定方法を介して場所情報を獲得し得ることが理解されるであろう。

プロセッサ３２はさらに、付加的な特徴、機能性、および／または有線もしくは無線接続を提供する、１つまたはそれを上回るソフトウェアならびに／もしくはハードウェアモジュールを含み得る、他の周辺機器５２に連結されてもよい。例えば、周辺機器５２は、加速度計、ｅ−コンパス、衛星送受信機、センサ、デジタルカメラ（写真またはビデオ用）、ユニバーサルシリアルバス（ＵＳＢ）ポート、振動デバイス、テレビ送受信機、ハンズフリーヘッドセット、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール、周波数変調（ＦＭ）ラジオユニット、デジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザ、および同等物を含んでもよい。

図１９は、ＡＤＤＳエンティティ３２２が実装され得る、任意のノードを含む、またはネットワーク内で独立型ノードとして動作するＡＤＤＳエンティティ３２２の場合に、図１−４Ａ−Ｄに図示されるコアネットワークノードのうちのいずれかを実装するために使用され得る、コンピュータシステムもしくはサーバのブロック図である。図１９のコンピュータシステムまたはサーバは、主に、ソフトウェアの形態であり得るコンピュータ可読命令によって制御されてもよく、どこでも、またはどのような手段を用いても、そのようなソフトウェアが記憶もしくはアクセスされる。そのようなコンピュータ可読命令は、コンピュータシステム９０を稼働させるように、中央処理装置（ＣＰＵ）９１等のプロセッサ内で実行されてもよい。多くの既知のワークステーション、サーバ、およびパーソナルコンピュータでは、中央処理装置９１は、マイクロプロセッサと呼ばれる単一チップＣＰＵによって実装される。他の機械では、中央処理装置９１は、複数のプロセッサを備えてもよい。コプロセッサ８１は、付加的な機能を果たすか、またはＣＰＵ９１を支援する、主要ＣＰＵ９１とは明確に異なる、随意のプロセッサである。ＣＰＵ９１および／またはコプロセッサ８１は、Ｐ２Ｐ通信に関連して、データを受信、生成、ならびに処理してもよい。

動作中、ＣＰＵ９１は、命令をフェッチ、復号、および実行し、コンピュータの主要データ転送パスであるシステムバス８０を介して、情報を他のリソースへ、およびそこから転送する。そのようなシステムバスは、コンピュータシステム９０内の構成要素を接続し、データ交換のための媒体を定義する。システムバス８０は、典型的には、データを送信するためのデータライン、アドレスを送信するためのアドレスライン、ならびに割り込みを送信するため、およびシステムバスを動作するための制御ラインを含む。そのようなシステムバス８０の実施例は、ＰＣＩ（周辺構成要素相互接続）バスである。

システムバス８０に連結されるメモリデバイスは、ランダムアクセスメモリ（ＲＡＭ）８２および読取専用メモリ（ＲＯＭ）９３を含む。そのようなメモリは、情報が記憶されて取り出されることを可能にする回路を含む。ＲＯＭ９３は、概して、容易に修正することができない、記憶されたデータを含有する。ＲＡＭ８２に記憶されたデータは、ＣＰＵ９１または他のハードウェアデバイスによって読み取られ、もしくは変更されることができる。ＲＡＭ８２および／またはＲＯＭ９３へのアクセスは、メモリコントローラ９２によって制御されてもよい。メモリコントローラ９２は、命令が実行されると、仮想アドレスを物理的アドレスに変換する、アドレス変換機能を提供してもよい。メモリコントローラ９２はまた、システム内のプロセスを単離し、ユーザプロセスからシステムプロセスを単離する、メモリ保護機能を提供してもよい。したがって、第１のモードで作動するプログラムは、独自のプロセス仮想アドレス空間によってマップされるメモリのみにアクセスすることができ、プロセス間のメモリ共有が設定されていない限り、別のプロセスの仮想アドレス空間内のメモリにアクセスすることができない。

加えて、コンピュータシステム９０は、ＣＰＵ９１からプリンタ９４、キーボード８４、マウス９５、およびディスクドライブ８５等の周辺機器に命令を伝達する責任がある、周辺機器コントローラ８３を含有してもよい。

ディスプレイコントローラ９６によって制御されるディスプレイ８６は、コンピュータシステム９０によって生成される視覚出力を表示するために使用される。そのような視覚出力は、テキスト、グラフィックス、動画グラフィックス、およびビデオを含んでもよい。ディスプレイ８６は、ＣＲＴベースのビデオディスプレイ、ＬＣＤベースのフラットパネルディスプレイ、ガスプラズマベースのフラットパネルディスプレイ、またはタッチパネルを伴って実装されてもよい。ディスプレイコントローラ９６は、ディスプレイ８６に送信されるビデオ信号を生成するために必要とされる、電子構成要素を含む。さらに、コンピュータシステム９０は、コンピュータシステム９０を外部通信ネットワークに接続するために使用され得る、ネットワークアダプタ９７を含有してもよい。

ＡＤＤＳクライアント３２４ならびにＡＤＤＳエンティティ３２２を含む、本明細書に説明されるシステム、方法、およびプロセスのうちのいずれかまたは全ては、命令が、コンピュータ、サーバ、ピア、プロセッサ、もしくは同等物等の機械によって実行されたときに、本明細書に説明されるシステム、方法、およびプロセスを行うおよび／または実装する、コンピュータ可読記憶媒体上に記憶されたコンピュータ実行可能命令、例えば、プログラムコードの形態で具現化され得ることが理解される。具体的には、本明細書に説明されるようなステップ、動作、または機能のうちのいずれかは、そのようなコンピュータ実行可能命令の形態で実装されてもよい。コンピュータ可読記憶媒体は、情報の記憶のための任意の方法または技術で実装される、揮発性および不揮発性、可撤性および非可撤性媒体の両方を含むが、そのようなコンピュータ可読記憶媒体は、信号を含まない。コンピュータ可読記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）または他の光学ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置または他の磁気記憶デバイス、もしくは所望の情報を記憶するために使用されることができ、コンピュータによってアクセスされることができる任意の他の物理的媒体を含むが、それらに限定されない。

Claims (20)

1. プロセッサおよびメモリを含む装置であって、前記メモリは、コンピュータ実行可能命令を記憶しており、前記コンピュータ実行可能命令は、前記プロセッサによって実行されると、前記装置に、通信ネットワークのインターワーキング機能として動作させ、前記コンピュータ実行可能命令は、さらに、前記インターワーキング機能に、ユーザ機器上でホストされる第１のアプリケーションとサーバ上でホストされる第２のアプリケーションとの間の通信を可能にするためのアプリケーションデータ配信サービスを提供させ、前記アプリケーションデータ配信サービスは、
   前記第２のアプリケーションに対して前記アプリケーションデータ配信サービスによってエクスポーズされたアプリケーションプログラミングインターフェースを含む第１のインターフェース上の前記第２のアプリケーションから、前記通信ネットワークを介して前記第１のアプリケーションにパケットを送信せよという第１の要求を受信することであって、前記第１の要求は、前記第２のアプリケーションが、前記パケットが承認されることを所望しているかどうかの指示と、前記第１のアプリケーションの識別子とを含む、ことと、
   前記第１の要求に基づいて、前記パケットが承認されるべきかどうかの前記指示と、前記第１のアプリケーションの前記識別子と、パケットのシーケンシングをサポートするために用いられるフィールドとを含むヘッダを符号化することと、
   前記通信ネットワークの移動性管理エンティティに、ｄｉａｍｅｔｅｒインターフェースを含む第２のインターフェースを介して、前記ヘッダおよび前記パケットが前記ユーザ機器に送信されることを要求する第２の要求を送信することであって、前記第２の要求は、前記パケットおよび前記ヘッダを含む、ことと
   を含む動作を実行するように構成されている、装置。
2. 前記アプリケーションデータ配信サービスは、最初に、
   前記第２のアプリケーションから、前記第２のアプリケーションと前記第１のアプリケーションをホストする前記ユーザ機器との間の接続を構成せよという第３の要求を受信することであって、前記第３の要求は、前記ユーザ機器の識別子、前記第１のアプリケーションの前記識別子、および前記第２のアプリケーションの識別子を含む、ことと、
   前記ユーザ機器に対する前記接続を認可せよという第４の要求を前記通信ネットワークのホーム加入者サーバに送信することであって、前記第４の要求は、ユーザ機器識別子を含む、ことと、
   前記第４の要求に対する応答を受信することであって、前記応答は、ｉｎｔｅｒｎａｔｉｏｎａｌ ｍｏｂｉｌｅ ｓｕｂｓｃｒｉｂｅｒ ｉｄｅｎｔｉｔｙと、前記ユーザ機器に対する前記接続が認可されているかどうかの指示とを含む、ことと、
   前記ユーザ機器識別子と、前記第１のアプリケーションの前記識別子と、前記第２のアプリケーションの前記識別子と、前記ｉｎｔｅｒｎａｔｉｏｎａｌ ｍｏｂｉｌｅ ｓｕｂｓｃｒｉｂｅｒ ｉｄｅｎｔｉｔｙとの間のマッピングを維持することと、
   前記第３の要求に応答することであって、前記応答は、前記第１のアプリケーションと前記第２のアプリケーションとの間の前記アプリケーションデータ配信サービスがサポートされていることを示す、ことと
   により、前記第１のアプリケーションとの通信のために構成されている、請求項１に記載の装置。
3. 前記アプリケーションデータ配信サービスは、前記ユーザ機器に関連付けられた加入が変更されたことを示すメッセージを前記ホーム加入者サーバから受信する、請求項２に記載の装置。
4. 前記アプリケーションデータ配信サービスは、
   前記ユーザ機器に、前記アプリケーションデータ配信サービスがサポートされているという指示を有するメッセージを送信すること
   を含む付加的動作を実行する、請求項１に記載の装置。
5. 前記ユーザ機器に対する前記指示を有する前記メッセージは、パケットデータネットワーク（ＰＤＮ）接続要求に応答して、ｐｒｏｔｏｃｏｌ ｃｏｎｆｉｇｕｒａｔｉｏｎ ｏｐｔｉｏｎｓ（ＰＣＯ）フィールドにおいて送信される、請求項４に記載の装置。
6. 前記指示を有する前記メッセージは、最大パケットサイズを含む、請求項５に記載の装置。
7. 前記第１の要求は、前記パケットが前記アプリケーションデータ配信サービスによってバッファされることが可能であるかどうかの指示と、どのくらい長く前記パケットが有効であるかの指示と、前記パケットの優先順位とのうちの少なくとも１つを含む、請求項１に記載の装置。
8. 前記アプリケーションデータ配信サービスは、前記サーバに応答し、パケットを送信せよという前記第１の要求が配信のために容認されたことを示す、請求項１に記載の装置。
9. 前記第１の要求が、前記要求が遅延に耐性があるという指示を含む場合、前記アプリケーションデータ配信サービスは、前記第１のアプリケーションが到達可能になるまで前記要求をバッファする、請求項１に記載の装置。
10. 前記アプリケーションデータ配信サービスは、前記ユーザ機器から前記パケットの確認応答を受信する、請求項１に記載の装置。
11. 前記アプリケーションデータ配信サービスは、前記ユーザ機器から前記確認応答を受信した後、前記パケットの送信が完了したという指示を前記サーバに送信する、請求項１０に記載の装置。
12. 前記第２の要求は、パケットのセグメンテーションおよび再アセンブリをサポートするために用いられる第２のフィールドをさらに含む、請求項１に記載の装置。
13. 通信ネットワークのインターワーキング機能において実装される方法であって、前記インターワーキング機能は、ユーザ機器上でホストされる第１のアプリケーションとサーバ上でホストされる第２のアプリケーションとの間の通信を可能にするためのアプリケーションデータ配信サービスを提供し、前記方法は、
    前記第２のアプリケーションに対して前記アプリケーションデータ配信サービスによってエクスポーズされたアプリケーションプログラミングインターフェースを含む第１のインターフェース上の前記第２のアプリケーションから、前記通信ネットワークを介して前記第１のアプリケーションにパケットを送信せよという第１の要求を受信することであって、前記第１の要求は、前記第２のアプリケーションが、前記パケットが承認されることを所望しているかどうかの指示と、前記第１のアプリケーションの識別子とを含む、ことと、
    前記第１の要求に基づいて、前記パケットが承認されるべきかどうかの前記指示と、前記第１のアプリケーションの前記識別子と、パケットのシーケンシングをサポートするために用いられるフィールドとを含むヘッダを符号化することと、
    前記通信ネットワークの移動性管理エンティティに、ｄｉａｍｅｔｅｒインターフェースを含む第２のインターフェースを介して、前記ヘッダおよび前記パケットが前記ユーザ機器に送信されることを要求する第２の要求を送信することであって、前記第２の要求は、前記パケットおよび前記ヘッダを含む、ことと
    を含む、方法。
14. 前記アプリケーションデータ配信サービスは、最初に、
    前記第２のアプリケーションから、前記第２のアプリケーションと前記第１のアプリケーションをホストする前記ユーザ機器との間の接続を構成せよという第３の要求を受信することであって、前記第３の要求は、前記ユーザ機器の識別子、前記第１のアプリケーションの前記識別子、および前記第２のアプリケーションの識別子を含む、ことと、
    前記ユーザ機器に対する前記接続を認可せよという第４の要求を前記通信ネットワークのホーム加入者サーバに送信することであって、前記第４の要求は、ユーザ機器識別子を含む、ことと、
    前記第４の要求に対する応答を受信することであって、前記応答は、ｉｎｔｅｒｎａｔｉｏｎａｌ ｍｏｂｉｌｅ ｓｕｂｓｃｒｉｂｅｒ ｉｄｅｎｔｉｔｙと、前記ユーザ機器に対する前記接続が認可されているかどうかの指示とを含む、ことと、
    前記ユーザ機器識別子と、前記第１のアプリケーションの前記識別子と、前記第２のアプリケーションの前記識別子と、前記ｉｎｔｅｒｎａｔｉｏｎａｌ ｍｏｂｉｌｅ ｓｕｂｓｃｒｉｂｅｒ ｉｄｅｎｔｉｔｙとの間のマッピングを維持することと、
    前記第３の要求に応答することであって、前記応答は、前記第１のアプリケーションと前記第２のアプリケーションとの間の前記アプリケーションデータ配信サービスがサポートされていることを示す、ことと
    により、前記第１のアプリケーションとの通信のために構成されている、請求項１３に記載の方法。
15. 前記アプリケーションデータ配信サービスは、前記ユーザ機器に関連付けられた加入が変更されたことを示すメッセージを前記ホーム加入者サーバから受信する、請求項１４に記載の方法。
16. 前記アプリケーションデータ配信サービスは、
    前記ユーザ機器に、前記アプリケーションデータ配信サービスがサポートされているという指示を有するメッセージを送信すること
    を含む付加的動作を実行する、請求項１３に記載の方法。
17. 前記ユーザ機器に対する前記指示を有する前記メッセージは、パケットデータネットワーク（ＰＤＮ）接続要求に応答して、ｐｒｏｔｏｃｏｌ ｃｏｎｆｉｇｕｒａｔｉｏｎ ｏｐｔｉｏｎｓ（ＰＣＯ）フィールドにおいて送信される、請求項１６に記載の方法。
18. 前記第１の要求は、前記パケットが前記アプリケーションデータ配信サービスによってバッファされることが可能であるかどうかの指示と、どのくらい長く前記パケットが有効であるかの指示と、前記パケットの優先順位とのうちの少なくとも１つを含む、請求項１３に記載の方法。
19. 前記第１の要求が、前記要求が遅延に耐性があるという指示を含む場合、前記アプリケーションデータ配信サービスは、前記第１のアプリケーションが到達可能になるまで前記要求をバッファする、請求項１３に記載の方法。
20. 前記アプリケーションデータ配信サービスは、前記ユーザ機器から前記パケットの確認応答を受信する、請求項１３に記載の方法。