JP2018517337A - ３ｇｐｐネットワークにおけるスモールデータ使用有効化 - Google Patents

Abstract

規格化組織である３ＧＰＰは、マシンタイプ通信（ＭＴＣ）のための新しいスモールデータ配信技法を模索している。本明細書では、既存のアプローチは、「スモールデータ」決定を、ダウンリンクデータに対してサービス能力サーバ（ＳＣＳ）に、アップリンクデータに対してユーザ機器（ＵＥ）に任せていると認識される。ユーザ機器（ＵＥ）またはコアネットワークは、スモールデータとして特徴付けられるべきサービス（またはフロー）を識別することができ、かつ最適化されたスモールデータプロシージャを採用すべきときを決定することができる。

Description

（関連出願の引用）
本願は、米国仮特許出願第６２／１５１，０８８号（２０１５年４月２２日出願）の利益を主張し、上記出願の開示は、その全体が記述されているかのように参照により本明細書に引用される。

（背景）
マシンタイプ通信（ＭＴＣ）アプリケーションは、多くの場合、小量のデータを送信または受信し、小量のデータは、概して、スモールデータと称され得る。ある場合には、「スモールデータ」アプリケーションが、頻繁ではない通信セッションに従事する場合、通信ネットワーク内のリソース、例えば、３ＧＰＰシステムは、非効率的に使用される。

所与のユーザ機器（ＵＥ）上のＭＴＣアプリケーションが、サービスを３ＧＰＰネットワークから得る必要がある場合、最初に、ネットワークに「アタッチ」しなければならない。アタッチプロシージャは、電源がオンされた後、ＵＥによって行われ得る。図１Ａは、３ＧＰＰネットワーク２００内で行われる例示的アタッチプロシージャを描写する。高レベルにおいて、アタッチプロシージャは、ＵＥの有無についてネットワークに知らせ、アタッチプロシージャは、ネットワーク内のデフォルトベアラを確立し、トラフィックがＵＥへまたはそこからフローすることを可能にする。図１Ａを参照すると、図示される例によると、２０１では、ＵＥ２０２は、ＵＥ２０２の識別、要求される接続のタイプ（例えば、パケットデータネットワーク（ＰＤＮ）タイプ）、および随意に、ＵＥ２０２がアクセスを要求しているパケットデータネットワークを指す文字列であるアクセスポイント名（ＡＰＮ）等の種々のパラメータを含むアタッチ要求を発行する。２０３では、この情報は、３ＧＰＰ基地局２０４からモビリティ管理エンティティ（ＭＭＥ）２０６に転送される。ＭＭＥ２０６は、ＡＰＮ情報を使用して、接続を行うべきパケットデータネットワークを選択し、次いで、ＰＤＮタイプを使用して、接続のタイプ（例えば、ＩＰｖ４および／またはＩＰｖ６）を決定する。ＭＭＥ２０６は、ホーム加入者サーバ（ＨＳＳ）２０８内に含まれるデバイスのサブスクリプションプロファイルをクエリすることによって（２０５ａにおいて）、ＵＥ２０２がＰＤＮへのアクセスを有することを検証し得る。ＵＥ２０２が、ＡＰＮを提供しない場合、例えば、ＭＭＥ２０６は、ＵＥのサブスクリプションプロファイルの一部として定義されたデフォルトＡＰＮを使用し得る。ＭＭＥとＨＳＳとの間の交換（２０５ａおよび２０５ｂにおいて）は、場所更新要求／回答または加入者データ挿入要求／回答交換であり得る。いずれの場合も、ＭＭＥ２０６は、ＰＤＳおよびＰＤＮゲートウェイ（ＰＤＮ−ＧＷ）を決定し得る。示されるように、２０７では、ＭＭＥは、次いで、ベアラを３ＧＰＰネットワーク２００内に設定し得る。２０９では、ＭＭＥ２０６は、基地局２０４を介して、アタッチ受諾メッセージをＵＥ２０２に発行し得る。２１１では、ＵＥ２０２は、次いで、基地局２０４を介してＭＭＥ２０６に送信され得るアタッチ完了メッセージでアタッチプロシージャを終了し得る。

アタッチ後、例えば、図１Ａに示されるアタッチプロシージャが行われた後、所与のユーザ機器（ＵＥ）上のアプリケーションが通信していないとき、無線ベアラは、解放され、ＵＥは、アイドル（ＩＤＬＥ）状態に移動し得る。本明細書で使用される場合、別様に規定されない限り、アイドル状態またはモードにあるＵＥは、進化型パケットコア（ＥＰＣ）モビリティ管理（ＥＭＭ）登録状態（ＲＥＧＩＳＴＥＲＥＤ）にあるＵＥ、および進化型パケットシステム（ＥＰＳ）接続管理（ＥＣＭ）アイドル状態にあるＵＥを指す。さらなる実施例として、所与のアプリケーションが、アイドル状態にあるＵＥとの接続の確立を欲する場合、ＵＥは、データベアラを確立し、ネットワークとの接続を信号伝達することによって、接続（ＣＯＮＮＲＣＴＥＤ）モードに移行する必要があるであろう。本明細書で使用される場合、別様に規定されない限り、接続モードにあるＵＥは、ＥＣＭ接続状態にあるＵＥを指す。

少量のデータのみを送信または受信するＵＥに対して、前述の移行は、例えば、スモールデータ転送を行うための相対的信号伝達オーバーヘッドが大きいので、非効率性を生じさせ得る。このリソース問題は、ＭＴＣアプリケーションに制限されず、スモールデータ通信を行う任意のアプリケーションにも当てはまり得る。この問題に対処し、最小限のネットワーク影響を伴ってスモールデータの伝送をサポートするために、ソリューションが、３ＧＰＰ ＴＲ ２３．８８７「Ｍａｃｈｉｎｅ−Ｔｙｐｅ ａｎｄ ｏｔｈｅｒ Ｍｏｂｉｌｅ Ｄａｔａ Ａｐｐｌｉｃａｔｉｏｎｓ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｅｎｈａｎｃｅｍｅｎｔｓ」において提案されている（ネットワーク影響とは、例えば、信号伝達オーバーヘッド、ネットワークリソースの使用、および再配分に関する遅延を指し得る）。スモールデータおよびデバイストリガ機能拡張（ＳＤＤＴＥ）のための３ＧＰＰ ＴＲ ２３．８８７に説明されるソリューションは、２つのカテゴリに大きくカテゴリ化されることができる：１）スモールデータ（ＳＤ）のための無線アクセスネットワーク（ＲＡＮ）制御プレーンの使用、２）ＳＤのためのデータプレーンの使用。

スモールデータのためにＲＡＮ制御プレーンを使用する例示的方法では、データは、無線インターフェース上で、進化型ノードＢ（ｅＮＢ）とユーザ機器（ＵＥ）との間で信号伝達無線ベアラ（ＳＲＢ）を経由して転送される。ｅＮＢからコアネットワーク（ＣＮ）への転送は、モビリティ管理エンティティ（ＭＭＥ）へのＳ１−ＭＭＥインターフェースを経由するＣＮ制御プレーン、またはサービングゲートウェイ（Ｓ−ＧＷ）へのＳ１−Ｕインターフェースを経由するＣＮデータプレーンを使用し得る。図１Ｂは、ＬＴＥベアラアーキテクチャを示す。この例では、スモールデータは、無線ベアラ上でｅＮＢに搬送されるであろう。

スモールデータのためにデータプレーンを使用する例示的方法では、データは、無線インターフェース上で、ｅＮＢとＵＥとの間でデータ無線ベアラ（ＤＲＢ）を経由して転送される。ｅＮＢからＣＮへの転送は、多くの場合、Ｓ−ＧＷへのＳ１−Ｕインターフェースを経由して、ＣＮデータプレーン上で行われる。しかしながら、ある場合には、例えば、ステートレスゲートウェイの使用または単一ベアラへの制限等の追加の条件が、適用され得る。図１Ｂを参照すると、ＬＴＥベアラアーキテクチャ内に実装されるようなこの例では、スモールデータは、Ｅ−ＲＡＢ上でＳ−ＧＷに、またはＥＰＳベアラ上でＰ−ＧＷに搬送されるであろう。

概して、本明細書では、アイドルモード（ＥＭＭ登録（ＥＭＭ−ＲＥＧＩＳＴＥＲＥＤ）およびＥＣＭアイドル（ＥＭＣ−ＩＤＬＥ）状態）にある所与のＵＥは、ＵＥが信号伝達プロシージャ（例えば、ＴＡＵまたはデタッチ）を行う必要がある場合、またはＵＥが伝送するためのアップリンクデータを有する場合、接続モード（ＥＣＭ接続（ＥＣＭ−ＣＯＮＮＥＣＴＥＤ））に移行する必要があることが認識される。ＵＥが、データを伝送するために、ＥＣＭ接続状態への移動を欲するとき、ＵＥは、サービス要求プロシージャを行う。サービス要求プロシージャは、ベアラ情報においてＵＥとＣＮとを同期させ、対応するデータベアラも確立する。確立されたデータベアラは、次いで、ＵＥによって、そのデータを伝送するために使用され得る。

ＵＥがＥＣＭアイドルからＥＣＭ接続に移行し、データを伝送するケースは、ＳＤＤＴＥのための３ＧＰＰ ＴＲ２３．８８７に説明されるように前述のソリューションにおいて修正されている。３ＧＰＰ ＴＲ ２３．８８７に説明される例示的ソリューションは、新しいプロシージャ（例えば、サービス要求プロシージャを伴わないデータ転送）が使用されることを要求するか、または既存のプロシージャに対する修正（例えば、サービス要求プロシージャに対する修正）を要求する。多くの場合、新しい／修正されるプロシージャは、ＵＥから開始される。

図２を参照すると、ポリシおよび課金制御（ＰＣＣ）アーキテクチャが、示される。ＰＣＣアーキテクチャは、ＴＳ ２３．２０３「Ｐｏｌｉｃｙ ａｎｄ ｃｈａｒｇｉｎｇ ｃｏｎｔｒｏｌ ａｒｃｈｉｔｅｃｔｕｒｅ」において３ＧＰＰによって定義されている。ＰＣＣアーキテクチャは、ポリシ、ポリシルール、ＱｏＳルール、および課金情報を実施するために使用される。図２に示されるインターフェースは、ＴＳ ２３．２０３の第５．２節に詳細に説明されているが、便宜上、以下に要約される。ここでの以下に説明されるインターフェースは、３ＧＰＰネットワーク内でのインターネットプロトコル（ＩＰ）フローおよびその対応するルールをプロビジョニングするために使用される。

図２を参照すると、ＡＦ（第三者アプリケーションサーバ）が、Ｒｘインターフェースを使用して、アプリケーションレベルセッション情報（例えば、ＩＰフィルタ情報、帯域幅要件、スポンサデータ等）をポリシおよび課金ルール機能（ＰＣＲＦ）に転送する。ＰＣＲＦは、ＩＰフロー情報に基づいて、ポリシおよび課金制御（ＰＣＣ）ルールを形成し、Ｇｘインターフェースを使用して、ポリシおよび課金実施機能（ＰＣＥＦ）にこのＰＣＣルールをプロビジョニングする。ＰＣＲＦは、ＩＰフロー情報に基づいて、ＱｏＳルールを形成し、Ｇｘｘインターフェースを使用して、ベアラ結合およびイベント報告機能（ＢＢＥＲＦ）にこのＱｏＳルールをプロビジョニングする。Ｓｐ／Ｕｄインターフェースは、ＰＣＲＦが、加入者ＩＤに基づいて、ＩＰフローについてのサブスクリプション情報を要求することを可能にする。ＰＣＲＦは、Ｓｐインターフェースを使用して、サブスクリプションプロファイルレポジトリ（ＳＰＲ）と相互作用し、ユーザデータレポジトリ（ＵＤＲ）に対してＵｄインターフェースを使用する。

依然として、図２を参照すると、課金関連情報を転送するために使用されるインターフェースが、ここで議論される。ＰＣＲＦは、Ｓｄインターフェースを使用して、ＡＤＣ決定をトラフィック検出機能（ＴＤＦ）に信号伝達する。ＰＣＲＦは、Ｓｙインターフェースを使用して、ポリシカウンタステータス情報をＯＣＳに送信する。Ｇｚインターフェースは、サービスデータフローベースのオフライン課金情報のトランスポートを有効にする。Ｇｙｎインターフェースは、ＴＤＦにおけるＡＤＣルールベースの課金の場合、課金のためのオンラインクレジット制御を可能にする。Ｇｚｎインターフェースは、ＴＤＦにおけるＡＤＣルールベースの課金の場合、オフライン課金情報のトランスポートを有効にする。

図３は、マシンタイプ通信（ＭＴＣ）のための３ＧＰＰアーキテクチャを示す。マシンタイプ通信は、概して、ヒト相互作用を伴わずに、異なるデバイスおよび／またはアプリケーション間の通信を伴う。ＭＴＣデバイスは、サービス能力サーバ（ＳＣＳ）のサービスを利用して、外部ＭＴＣアプリケーションと通信し得る。３ＧＰＰシステムは、基本的に、マシンツーマシン（Ｍ２Ｍ）デバイス通信のためのトランスポートを提供する。加えて、３ＧＰＰシステムは、マシンタイプ通信のための他の付加価値サービスを提供し得る。本明細書では、異なるアーキテクチャモデルも、ＭＴＣサービスプロバイダ（ＳＣＳ）と３ＧＰＰネットワークオペレータとの関係に基づいて、３ＧＰＰシステム内で可能なことが認識される。ＭＴＣのための例示的アーキテクチャ拡張は、３ＧＰＰ ＴＳ ２３．６８３「Ａｒｃｈｉｔｅｃｔｕｒｅ ｅｎｈａｎｃｅｍｅｎｔｓ ｔｏ ｆａｃｉｌｉｔａｔｅ ｃｏｍｍｕｎｉｃａｔｉｏｎｓ ｗｉｔｈ ｐａｃｋｅｔ ｄａｔａ ｎｅｔｗｏｒｋｓ ａｎｄ ａｐｐｌｉｃａｔｉｏｎｓ」に定義されている。ＴＳ２３．６８３からの主要アーキテクチャ略図は、図３に示される。ＭＴＣ−ＩＷＦ（マシンタイプ通信−インターワーキング機能）が、３ＧＰＰシステム内に導入され、３ＧＰＰネットワークの１つ以上のサービス能力サーバ（ＳＣＳ）との通信を有効にする。ＭＴＣ−ＩＷＦは、独立型エンティティまたは別のネットワーク要素の論理エンティティであり得る。ＭＴＣ−ＩＷＦは、内部ＣＮトポロジを隠し、ダイアメータベースのＴｓｐ参照点を経由して送信される情報を中継または変換し、ＣＮ内の特定の機能性を呼び出す。他のアーキテクチャモデルも、３ＧＰＰ ＴＳ ２３．７０８に定義されている。例えば、サービス能力エクスポージャ機能（ＳＣＥＦ）が、３ＧＰＰシステム内に導入され、３ＧＰＰネットワークと１つ以上のサービス能力サーバ（ＳＣＳ）の通信を有効にする。ＳＣＥＦは、独立型エンティティまたは別のネットワーク要素の論理エンティティであり得る。ＳＣＥＦは、内部ＣＮトポロジを隠し、ＡＰＩコールを介して受信された情報を中継または変換し、種々のコアネットワークノードとインターフェースをとり、ＡＰＩコールによって要求される機能性を呼び出す。例えば、ＳＣＥＦは、ＭＴＣ−ＩＷＦ、ＨＳＳ、ＰＣＲＦ、ＵＤＲ、ＭＭＥ等とインターフェースをとり得る。

本明細書では、３ＧＰＰは、ＭＴＣ通信のための新しいスモールデータ配信技法を模索していることが認識される。例えば、ＴＲ２３．８８７におけるソリューションは、信号伝達オーバーヘッドを低減させることによって、スモールデータ転送をより効率的に搬送する問題に対処する。しかしながら、既存のアプローチは、能力および効率を欠いている。

前述のように、３ＧＰＰは、ＭＴＣ通信のための新しいスモールデータ配信技法を模索している。提案される技法は、制御プレーンを経由して、例えば、非アクセス層（ＮＡＳ）または無線リソース制御（ＲＲＣ）メッセージ内でデータを送信することを伴う。本明細書では、既存のアプローチは、「スモールデータ」決定を、ダウンリンクデータに対してサービス能力サーバ（ＳＣＳ）に、アップリンクデータに対してユーザ機器（ＵＥ）に任せていることが認識される。本明細書に開示される実施形態は、ユーザ機器（ＵＥ）またはコアネットワークがスモールデータとして特徴付けられるべきサービス（またはフロー）を識別する方法に対処する。本明細書に開示される実施形態はまた、最適化されたスモールデータプロシージャを採用すべきときにも対処する。本明細書に開示される実施形態はまた、同義的または集合的に、ＳＣＳ／ＡＳ／ＡＦと称され得る、ＳＣＳまたはアプリケーションサーバ（ＡＳ）もしくはアプリケーション機能（ＡＦ）が、例えば、ＭＴＣ−ＩＷＦ、ホーム加入者サーバ（ＨＳＳ）、ポリシおよび課金ルール機能（ＰＣＲＦ）、ユーザデータレポジトリ（ＵＤＲ）、およびモバイル管理エンティティ（ＭＭＥ）等のコアネットワークノードと直接通信し得る方法を開示する。コアネットワークノードと直接通信するのではなく、ＳＣＳ／ＡＳ／ＡＦは、サービス能力エクスポージャ機能（ＳＣＥＦ）を介して、コアネットワークノードと通信し得ることを理解されたい。

例示的実施形態では、コアネットワーク（ＣＮ）は、スモールデータ（ＳＤ）通信を制御する。例えば、集合的に、ＡＦ／ＳＣＳ／ＡＳまたはその任意の変形例と称され得る、アプリケーション機能（ＡＦ）またはサービス能力サーバ（ＳＣＳ）もしくはアプリケーションサービス（ＡＳ）は、３ＧＰＰネットワークに、３ＧＰＰネットワークが「スモールデータ」と見なされるべきフローに関する決定を行い得るように、データフローに関連付けられた情報をプロビジョニングし得る。一側面では、ＡＦ／ＳＣＳは、ＰＣＲＦに、Ｒｘインターフェースを介して、スモールデータフロー情報をプロビジョニングする。別の側面では、ＡＦ／ＳＣＳは、ＰＣＲＦに、ＴｓｐインターフェースおよびＭＴＣ−ＩＷＦを介して、スモールデータフロー情報をプロビジョニングする。さらに別の側面では、ＡＦ／ＳＣＳは、サブスクリプションデータベース（ＨＳＳ／ＵＤＲ）に、Ｕｄ／Ｍｈインターフェースを介して、スモールデータフロー情報をプロビジョニングする。本明細書に説明されるように、３ＧＰＰネットワークに提供されるスモールデータフロー情報は、３ＧＰＰネットワークによって使用され得る。例えば、コアネットワークは、スモールデータ配信方法を介して、ダウンリンクデータをＵＥにルーティングし得る。一実施例では、スモールデータフロー情報は、３ＧＰＰネットワークによって、アップリンクデータをスモールデータ配信方法を使用して３ＧＰＰネットワークに向かってルーティングするようにＵＥを構成するために使用される。３ＧＰＰネットワーク内のスモールデータフローをサポートする新しいサブスクリプション情報が、本明細書に説明される。さらに別の実施例では、追加の情報要素が、説明され、既存の情報要素は、修正される。そのような情報要素は、３ＧＰＰネットワークとＵＥとの間で共有されるメッセージ内に含まれ、アップリンクにおいてスモールデータ配信を使用するようにＵＥの構成をサポートし得る。

別の例示的実施形態では、装置、例えば、ＭＭＥを備えている装置は、第１のメッセージをＵＥから受信し得る。第１のメッセージは、ＵＥがスモールデータプロシージャをサポートすることの指示を含むアタッチ要求を含み得る。代替として、または加えて、第１のメッセージは、ＵＥがスモールデータプロシージャを使用することの要求を含むアタッチ要求を備え得る。装置はまた、第２のメッセージをネットワークノード、例えば、ＨＳＳから受信し得る。第２のメッセージは、スモールデータプロシージャを使用すべきである１つ以上のＰＤＮ接続を示し得る。第２のメッセージはまた、１つ以上のＰＤＮ接続の各々に対応するスモールデータプロシージャのタイプを示し得る。第２のメッセージに基づいて、装置は、第１のメッセージに応答し得る。例えば、応答は、ＵＥが第２のメッセージに示されているスモールデータプロシージャのうちの１つを使用するスモールデータモードで機能すべきことの指示を含むアタッチ応答メッセージを備え得る。装置は、次いで、第２のメッセージに示されているスモールデータプロシージャのうちの１つを使用して、データを配信し得る。装置はまた、第２のメッセージに示されているスモールデータプロシージャのうちの１つに従って、データをＵＥから受信し得る。ある場合には、スモールデータプロシージャは、非アクセス層（ＮＡＳ）メッセージングを介して示され得る。

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

本願のより堅調な理解を促進するために、ここで、類似要素が類似数字で参照される、付随の図面を参照する。これらの図は、本願を限定するものと解釈されるべきではなく、例証にすぎないものであることを意図している。

図１Ａは、３ＧＰＰネットワークにおいて行われ得る例示的アタッチプロシージャを示すコールフローである。 図１Ｂは、とりわけ、図１Ａに示されるプロシージャが行われ得るＬＴＥアーキテクチャの例示的略図である。 図２は、ポリシおよび課金制御（ＰＣＣ）論理アーキテクチャを描写するブロック図である。 図３は、マシンタイプ通信（ＭＴＣ）のための３ＧＰＰアーキテクチャを描写するブロック図である。 図４は、アプリケーション機能（ＡＦ）セッション確立の例示的実施形態を示すコールフローである。 図５は、例示的実施形態による、図３に示される３ＧＰＰ ＭＴＣアーキテクチャ内のＴ７インターフェースと称され得る追加のインターフェースを描写する。 図６は、図５に描写されるＴｓｐインターフェースおよびＴ７インターフェースを経由したサービス能力サーバ（ＳＣＳ）情報プロビジョニングを示すコールフローである。 図７は、３ＧＰＰインターワーキングアーキテクチャの例示的ブロック図である。 図８は、例示的プル配信方法（ポリシおよび課金実施機能（ＰＣＥＦ）によって請求されたプロビジョニング）を示す、Ｇｘ参照点を経由したコールフローである。 図９は、ある実施形態による、例示的プッシュ配信方法（非請求プロビジョニング）を示す、Ｇｘ参照点を経由したコールフローである。 図１０は、例示的プル配信方法（ベアラ結合およびイベント報告機能（ＢＢＥＲＦ）によって請求されたＱｏＳプロビジョニング）を示す、Ｇｘｘ参照点を経由したコールフローである。 図１１は、例示的実施形態による、例示的プッシュ配信方法（非請求ＱｏＳプロビジョニング）を示す、Ｇｘｘ参照点を経由したコールフローである。 図１２は、進化型パケットシステム（ＥＰＳ）におけるベアラ概念を用いたトラフィックフローテンプレート（ＴＦＴ）の現在のリンケージを描写する。 図１３は、例示的実施形態による、パケットデータネットワーク（ＰＤＮ）接続にリンクされたスモールデータ（ＳＤ）ＴＦＴを描写する。 図１４は、例示的実施形態による、例示的グラフィカルユーザインターフェース（ＧＵＩ）を描写する。 図１５Ａは、１つ以上の開示される実施形態が実装され得る例示的マシンツーマシン（Ｍ２Ｍ）またはモノのインターネット（ＩｏＴ）通信システムの系統図である。 図１５Ｂは、図１５Ａで図示されるＭ２Ｍ／ＩｏＴ通信システム内で使用され得る、例示的アーキテクチャの系統図である。 図１５Ｃは、図１５Ａで図示される通信システム内で使用され得る、例示的Ｍ２Ｍ／ＩｏＴ端末またはゲートウェイデバイスの系統図である。 図１５Ｄは、図１５Ａの通信システムの側面が具現化され得る、例示的コンピューティングシステムのブロック図である。

本明細書で使用される場合、別様に規定されない限り、「アイドル（ＩＤＬＥ）」モードまたは状態にあるユーザ機器（ＵＥ）は、進化型パケットコア（ＥＰＣ）モビリティ管理（ＥＭＭ）登録状態（ＥＭＭ−ＲＥＧＩＳＴＥＲＥＤ ｓｔａｔｅ）および進化型パケットシステム（ＥＰＳ）接続管理（ＥＣＭ）アイドル状態（ＥＣＭ−ＩＤＬＥ ｓｔａｔｅ）にあるＵＥを指す。「接続」モードにあるＵＥは、ＥＣＭ接続状態にあるＵＥを指す。本明細書で使用される場合、用語「スモールデータフィルタ」は以下を指し得る：１）３ＧＰＰ ＴＳ ２４．００８「Ｍｏｂｉｌｅ ｒａｄｉｏ ｉｎｔｅｒｆａｃｅ Ｌａｙｅｒ ３ ｓｐｅｃｉｆｉｃａｔｉｏｎ；Ｃｏｒｅ ｎｅｔｗｏｒｋ ｐｒｏｔｏｃｏｌｓ」におけるトラフィックフローテンプレート（ＴＦＴ）に説明されるようなパケットフィルタ、２）ＲＦＣ ３５８８「Ｄｉａｍｅｔｅｒ Ｂａｓｅ Ｐｒｏｔｏｃｏｌ」に説明されるようなＩＰＦｉｌｔｅｒＲｕｌｅ、または３）ＩＰトラフィックにマッチングするように使用され得るカスタマイズされたフィルタ。用語「スモールデータ情報」、「データフロー情報」、およびその形例変は、本明細書では同義的に使用され、概して、スモールデータと見なされるＩＰトラフィックに関連付けられた１つ以上の特性を記述する情報を指す。例えば、スモールデータ情報は、スモールデータフィルタを含み得る。本明細書で使用される場合、別様に規定されない限り、用語「スモールデータプレーン」は、スモールデータが転送され得る経路を指す。ある実施例では、経路は、無線アクセスネットワーク（ＲＡＮ）制御プレーン、ＲＡＮデータプレーン、コアネットワーク（ＣＮ）制御プレーン、およびＣＮデータプレーンの組み合わせであり得る。ある場合には、組み合わせは、スモールデータ転送のために３ＧＰＰによって選定されるソリューションに依存し得る。本明細書で使用される場合、別様に規定されない限り、用語「スモールデータプロシージャ」は、スモールデータの転送のために３ＧＰＰによって選択されるアプローチ（例えば、メッセージおよびプロシージャ）を指す。前述のように、いくつかのアプローチは、３ＧＰＰ ＴＲ ２３．８８７に説明されており、それらのアプローチのうちの１つ以上のものが、完成させられ得る。

前述のように、提案されているスモールデータを管理するための既存のアプローチまたは技法は、概して、制御プレーンもしくはデータプレーンを経由したデータの送信を伴う。本明細書では、３ＧＰＰにおいて議論されているアプローチは、これまで、「スモールデータ決定」を、ダウンリンクデータに関してはＳＣＳに、アップリンクデータに関してはＵＥに任せていたことが認識される。言い換えると、ユーザプレーン（例えば、ＩＰベースのＳＧｉ参照点）を経由してデータを送信するために既存のプロシージャを使用するか、または別のスモールデータ配信方法を使用するために既存のプロシージャを使用するかは、ＵＥもしくはＳＣＳ次第である。

本明細書では、「スモールデータ決定」をＳＣＳまたはＵＥに任せることは、非効率的であり得ることが認識される。ある場合には、ＵＥまたはＳＣＳは、３ＧＰＰネットワークではなく、ＵＥまたはＳＣＳのために最良であるものに基づいて決定を行うであろう。例えば、ＵＥは、より長い配信時間が性能に影響を及ぼさないであろう場合でも、常時、最速配信方法を使用することを選定し得る。少なくとも、３ＧＰＰコアネットワークは、例えば、ネットワーク条件を認識しているので、本明細書では、３ＧＰＰコアネットワークは、データを配信するための最も効率的方法に関して決定を行うようにより良好に位置付けられ得ることが認識される。

種々の実施形態によると、３ＧＰＰコアネットワークが「スモールデータ決定」の制御を行い得るようなアーキテクチャ拡張が、開示される。例えば、一側面では、便宜上、限定ではないが、ＳＣＳ／ＡＳ（またはその変形例）と集合的に称され得るサービス能力サーバ（ＳＣＳ）またはアプリケーションサーバ（ＡＳ）が、３ＧＰＰネットワークに、ＳＣＳ／ＡＳとそのＵＥとの間のデータフローの特性を提供することができる。さらに、以下に説明されるように、ＳＣＳ／ＡＳによって提供される情報に基づいて、３ＧＰＰネットワークは、ＵＥに、スモールデータプレーンを使用すべきときを命令することができ、３ＧＰＰネットワークは、ＳＣＳ／ＡＳからのダウンリンクトラフィックをスモールデータプレーンに向かわせるべきときを決定することができる。

ある場合には、アップリンクでは、ＵＥは、データ転送のために、スモールデータプロシージャを使用すること、または既存のサービス要求プロシージャを使用することに関して決定を行うことを要求される。本明細書では、ＵＥは、スモールデータプロシージャを開始すべきときを認識すべきであることが認識される。例示的実施形態では、ＣＮおよび／またはＳＣＳは、ＵＥが、典型的サービス要求プロシージャを使用する代わりに、スモールデータプロシージャを使用すべきときを把握するように、ＵＥを構成することが可能である。ある場合には、ダウンリンクでは、ネットワークは、どのフロー／ベアラがスモールデータとして扱われるべきかを決定する。例示的実施形態では、ネットワークは、ＳＣＳから受信されたフロー情報に基づいて、そのような決定を行い得る。

ＡＳ／ＳＣＳからの種々の入力が、ここで説明される。本明細書では、概して、サービス層は、所与のサービスのデータレートニーズを最も良く知らされていることが認識される。例えば、サービス層は、多くの場合、サービスが、常時、スモールデータと見なされるであろうかどうか、または所与のサービスが、そのアクティビティをスモールデータ（例えば、ハートビートメッセージ）として周期的にのみ分類可能であろうかどうかを予期することが可能である。さらなる実施例として、ある場合には、サービス層は、特定の期間中に伝送されるであろうパケットの数および典型的に伝送されるパケットのサイズを把握していることが予期され得る。本明細書では、前述のような種々の情報、例えば、サービス層内の情報が、ネットワークと共有され得る場合、ネットワークは、情報を使用して、ネットワークのリソースを効率的様式で管理することができることが認識される。例えば、ネットワークは、サービスの実際の要件に基づくルールをリアルタイムで作成することができる。

例示的実施形態では、Ｒｘインターフェースは、データフロー情報、例えば、スモールデータフロー情報をサポートするように拡張される。例えば、ＡＦ／ＳＣＳは、Ｒｘインターフェースを介して、フロー情報を調整することができる。特に、例えば、ＡＦは、Ｍ２Ｍアプリケーションに関連付けられたスモールデータ情報を、Ｒｘインターフェースを使用して、ＰＣＲＦにプロビジョニングし得る。以下に説明される別の例示的側面では、新しい属性値対（ＡＶＰ）が、スモールデータ情報をＲｘインターフェースの既存のＡＡ−要求（ＡＡＲ）ダイアメータメッセージ内に含むように追加される。概して、図２に図示されるＡＦを参照すると、本明細書で使用される場合、ＡＦは、ＭＴＣサーバ、Ｍ２Ｍサーバ、ＳＣＳ等であり得、したがって、ＡＦは、概して、ネットワークノードとも称され得ることを理解されたい。

以下の表１を参照して、例示的実施形態によると、ＡＦ／ＳＣＳは、Ｒｘインターフェースを経由して、各アプリケーションに関連付けられたスモールデータフロー情報を提供する。情報は、オペレータによって、ＡＦ／ＳＣＳにおいて事前にプロビジョニングされることができる。代替として、または加えて、アプリケーションは、アプリケーショントラフィックを監視し、アプリケーションに関連付けられた統計的データを収集することによって、情報を獲得することができる。表１は、アプリケーションごとにＰＣＲＦに提供され得る例示的情報要素を含む。表１における要素は、随意であり得、いくつかの要素は、条件付きであり得る（例えば、トラフィックモード）。説明されるように、ＰＣＲＦは、この情報を使用して、スモールデータルール（例えば、ＰＣＣルール、ＱｏＳルール等）が採用され得るかどうかを判断することができる。情報要素（アイテム）は、限定ではないが、一例として提示されることを理解されたい。

表１に説明される例示的情報は、アプリケーションに関連付けられたトラフィックの性質を決定するために使用されることができる。したがって、情報は、頻繁ではないスモールデータ転送および頻繁なスモールデータ転送を識別することにおいて役立つことができる。概して、アプリケーション機能（ＡＦ）は、アプリケーション層信号伝達に基づいて、またはアプリケーションサービスプロバイダ（ＡＳＰ）から、サービス情報を獲得する。ＡＦは、ＰＣＲＦとの新しいセッションを作成し、ＰＣＲＦに、例えば、ＱｏＳ要件、フロー情報、課金詳細等、種々のセッション詳細をプロビジョニングし得る。ある場合には、セッション情報が後の時点で変化する場合、ＡＦは、これらの修正をＰＣＲＦに送信する。前述の新しい追加のセッション情報は、例えば、初期セッションプロビジョニング中、または後にセッション修正要求として、ＰＣＲＦに送信され得る。

図４−６、８−１１、および１３−１４（以降で説明される）は、スモールデータを管理する方法および装置の種々の実施形態を図示する。これらの図では、１つ以上のクライアント、サーバ、および／もしくはプロキシによって行われている種々のステップまたは動作が、示されている。これらの図に図示されるクライアント、サーバ、およびプロキシは、通信ネットワーク内の論理エンティティを表し得、以下で説明される図１５Ａまたは１５Ｂに図示される一般的アーキテクチャのうちの１つを備え得るそのようなネットワークのノードまたは装置のメモリに記憶され、そのプロセッサ上で実行するソフトウェア（例えば、コンピュータ実行可能命令）の形態で実装され得ることが理解される。すなわち、図４−６、８−１１、および１３−１４に図示される方法は、例えば、図１５Ｃまたは１５Ｄに図示されるノードもしくはコンピュータシステム等、ネットワークノードまたは装置のメモリに記憶されたソフトウェア（例えば、コンピュータ実行可能命令）の形態で実装され得、そのコンピュータ実行可能命令は、ノードまたは装置のプロセッサによって実行されると、図に図示されるステップを行う。これらの図に図示される任意の伝送および受信ステップは、ノードまたは装置のプロセッサならびにそれが実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下で、ノードまたは装置の通信回路（例えば、それぞれ、図１５Ｃおよび１５Ｄの回路３４または９７）によって行われ得ることも理解される。

ここで図４を参照すると、例示的ネットワーク４００は、ベアラ結合およびイベント報告機能（ＢＢＥＲＦ）１０２、ポリシおよび課金実施機能（ＰＣＥＦ）１０４、訪問ポリシおよび課金ルール機能（Ｖ−ＰＣＲＦ）１０６、ホームポリシおよび課金ルール機能（Ｈ−ＰＣＲＦ）１０８、ＡＦ／ＳＣＳ１００、ならびにサブスクリプションプロファイルレポジトリ（ＳＰＲ）１１０を含む。ある場合には、便宜上、Ｖ−ＰＣＲＦ１０６およびＨ−ＰＣＲＦ１０８は、概して、ＰＣＲＦ、例えば、図５に図示されるＰＣＲＦ１０１と称され得る。例示的ネットワーク４００は、開示される主題の説明を促進するために簡略化され、本開示の範囲を限定することを意図するものではないことを理解されたい。他のデバイス、システム、および構成は、ネットワーク４００等のネットワークに加え、またはその代わりに、本明細書に開示される実施形態を実装するために使用され得、全てのそのような実施形態は、本開示の範囲内として検討される。さらに、参照番号は、図中の同一または類似特徴を示すために、種々の図中で繰り返され得ることを理解されたい。

図４は、セッション確立のための例示的コールフローを図示する。図示される実施例によると、ＳＣＳ１００によるセッション情報の初期プロビジョニングまたは修正は、ダイアメータＡＡ−要求（ＡＡＲ）メッセージをＨ−ＰＣＲＦ１０８に送信することによって、Ｒｘインターフェースを経由して行われる。３ＧＰＰ ＴＳ ２９．２１３「Ｐｏｌｉｃｙ ａｎｄ Ｃｈａｒｇｉｎｇ Ｃｏｎｔｒｏｌ ｓｉｇｎａｌｉｎｇ ｆｌｏｗｓ ａｎｄ Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ （ＱｏＳ）ｐａｒａｍｅｔｅｒ ｍａｐｐｉｎｇ」は、図４に図示されるメッセージを説明するが、図４に図示されるステップ２および７は、図示される実施形態に従って修正される。

依然として、図４を参照すると、１では、「トリガ」イベントが、フローを開始させる。ＡＳ／ＳＣＳ１００にこのフローを開始させ得るイベントの例は、限定として提示されるわけではないが、以下が含まれる：
・ ＡＳ／ＳＣＳ１００またはＡＳ／ＳＣＳ１００に接続されるアプリケーションとＵＥとの間のデータフローのプロパティが、変化する必要がある。
・ ＡＳ／ＳＣＳ１００またはＡＳ／ＳＣＳ１００に接続されるアプリケーションが、大容量ファイル（例えば、ソフトウェア画像、ビデオクリップ、およびオーディオクリップ、新しいアプリケーション等）をＵＥにダウンロードすることを望む。
・ ＡＳ／ＳＣＳ１００またはＡＳ／ＳＣＳ１００に接続されるアプリケーションが、ＵＥとのそのデータレートを増加または減少させることを計画する。例えば、これは、ＵＥ上のアプリケーションが、有効にされる、無効にされる、または新しい状態に移動させられることにより生じ得る。
・ ＡＳ／ＳＣＳ１００またはＡＳ／ＳＣＳ１００に接続されるアプリケーションが、ＵＥと通信する頻度を増加または減少させることを計画する。例えば、例えば、これは、ＵＥ上のアプリケーションが、有効にされる、無効にされる、または新しい状態に移動させられることにより生じ得る。

ある実施例では、ＡＳ／ＳＣＳ１００は、ｓｕｂｓｃｒｉｐｔｉｏｎ−ｉｄ属性値対（ＡＶＰ）を所与のＵＥの外部識別子に設定し得、ＰＣＲＦ１０６は、限定ではないが、ＨＳＳ／ＵＤＲと集合的に称され得るそれぞれのホーム加入者サーバ（ＨＳＳ）またはユーザデータレポジトリ（ＵＤＲ）にクエリし、外部ｉｄを、例えば、ＩＭＳＩまたはＭＳＩＳＤＮに変換し得る。用語「ＵＥ」は、任意のノード、例えば、Ｍ２Ｍデバイスまたは無線伝送／受信ユニット（ＷＴＲＵ）を指し得ることを理解されたい。図示されるセッション確立プロシージャ（図４）および例示的セッション修正プロシージャ（図示せず）の両方では、ＡＦ１００は、ダイアメータＡＡＲメッセージを使用する。例示的実施形態によると、このＡＡＲメッセージは、表１に列挙される情報を含み得る。例示的更新されたＡＡＲコマンドは、以下に示される。

（例示的更新されたＡＡ−要求メッセージ）
例示的メッセージフォーマット：

例示的実施形態では、新しいグループ化されたＡＶＰは、表１に列挙される新しい情報のために定義される。ＡＶＰは、コマンドレベルにおける別個のＡＶＰとしてＡＡＲメッセージ内に、または「Ｍｅｄｉａ−Ｃｏｍｐｏｎｅｎｔ−Ｄｅｓｃｒｉｐｔｉｏｎ」ＡＶＰ内に含まれることができる。

３ＧＰＰ ＴＳ ２９．２１４「Ｐｏｌｉｃｙ ａｎｄ Ｃｈａｒｇｉｎｇ Ｃｏｎｔｒｏｌ ｏｖｅｒ Ｒｘ ｒｅｆｅｒｅｎｃｅ ｐｏｉｎｔ」に説明されるように、ＡＦ−Ａｐｐｌｉｃａｔｉｏｎ−ｉｄｅｎｔｉｆｉｅｒ ＡＶＰ（ＡＶＰコード５０４）は、タイプＯｃｔｅｔＳｔｒｉｎｇであり、それは、ＡＦサービスセッションが属する特定のサービスを識別する情報を含む。この情報は、ＰＣＲＦによって、異なるアプリケーションサービスのためのＱｏＳを区別するために使用され得る。ある例では、新しい値は、このＡＶＰは、アプリケーション特定のデフォルト値を使用することをＰＣＲＦに示すために使用されることができる。例えば、「ＸＹＺ＿Ｅｌｅｃｔｒｉｃ＿Ｍｅａｓｕｒｅｍｅｎｔ＿Ａｐｐ１０９」の値が、使用され得る。例によると、この値は、このタイプのアプリケーションのために任意のローカルで構成された値を探すことをＰＣＲＦに示す。値は、その関連付けられたフロー情報詳細とともに、スモールデータアプリケーションとして、ＰＣＲＦ内に構成され得る。

「Ｍｅｄｉａ−Ｃｏｍｐｏｎｅｎｔ−Ｄｅｓｃｒｉｐｔｉｏｎ」ＡＶＰは、例えば、一例示的実施形態に従って、以下に示されるように修正されることができる。下線が引かれたＡＶＰは、一実施例に従って新しく追加されたＡＶＰである。

例示的ＡＶＰフォーマット：

上で示されるように、３つの例示的新しく定義されたＡＶＰは、「Ｍｅｄｉａ−Ｓｕｂ−Ｃｏｍｐｏｎｅｎｔ」ＡＶＰの一部として含まれ、サブフローのための詳細を提供し得る。上の例示的定義は、ある持続時間にわたるフローの帯域幅（ＢＷ）要件を提供する。ある例では、ＰＣＲＦは、時間が満了した後、新しい帯域幅値を要求し得るか、またはＡＦ１００は、時間間隔が満了後、これらの詳細をＰＣＲＦにプッシュ配信することができる。代替として、例えば、Ｍａｘ−Ｒｅｑｕｅｓｔｅｄ−Ｂａｎｄｗｉｄｔｈ値および持続時間が、新しいＡＶＰにグループ化されることができ、新しいＡＶＰの複数のインスタンスが、含まれ得る。「Ｔｒａｆｆｉｃ−Ｍｏｄｅ」ＡＶＰは、アプリケーションの現在のモードを示し得（例えば、重または軽もしくはアイドル等として）、所定のトラフィック特性が、例えば、モードおよびアプリケーション識別子に基づいて、割り当てられることができる。

例示的「Ｔｒａｆｆｉｃ−Ｃｈａｒａｃｔｅｒｉｓｔｉｃｓ」ＡＶＰは、以下のように定義されることができる。
例示的ＡＶＰフォーマット：

例示的実施形態では、「Ｓｕｐｐｏｒｔｅｄ−Ｆｅａｔｕｒｅｓ」ＡＶＰは、ＡＦ１００が前述のもの等の１つ以上の新しい特徴をサポートすることの指示を含むように修正されることができる。

依然として、図４を参照すると、７では、図示される実施例によると、ＰＣＲＦからＡＦ１００に送信されるＡＡＡメッセージは、必要に応じて、例えば、スモールデータと見なされたフローについてＡＦ１００に知らせるように修正されることができる。ＡＦ１００によってＡＡＲメッセージ内に提供される情報がＰＣＲＦによって受諾されないある場合には、ＰＣＲＦは、拒否を送信することができ、ＰＣＲＦは、スモールデータサービスを提供するための容認可能値についてＡＦ１００に知らせることもできる。例示的更新されたＡＡＡメッセージは、以下に示される。

例示的メッセージフォーマット：

類似修正が、フローが再承認または再構成されるとき、ＳＣＳ１００およびＰＣＲＦによって使用されるＲＡＲおよびＲＡＡメッセージに行われることができることを理解されたい。

したがって、表１および図４を参照して上で述べたように、第１のノード、例えば、ＳＣＳ１００は、トリガに基づいて、第２のノードをプロビジョニングすることができる。第２のノード、例えば、ＰＣＲＦは、第１のノードによって、データフローおよびアプリケーションに関連付けられた情報をプロビジョニングされることができ、それによって、第２のノードは、情報をアプリケーションに配信するために、または情報をアプリケーションから受信するために使用されるべき方法を選択するためのルールを決定することができる。ユーザ機器は、アプリケーションをホストすることができ、ＵＥは、ルールに従って、アップリンクデータをルーティングするように構成されることができる。以下にさらに説明されるように、ルールは、とりわけ、サービスの品質（ＱｏＳ）であることができる。図４を参照して説明されるように、第１のノードは、Ｒｘインターフェースを経由して、ダイアメータメッセージを直接第２のノードに送信することによって、第２のノードをプロビジョニングし得る。第２のノードは、情報をデータフローに関連付けられた観察される挙動と比較するように構成され得、観察される挙動が予期される挙動と異なるとき、第２のノードは、アクションを行い得る（例えば、データフローを終了する、第１のノードに知らせる等）。例示的実施形態によると、表１を参照して、ダイアメータメッセージは、アプリケーションに関連付けられた媒体タイプ、アプリケーションのアプリケーション識別子、アプリケーションの帯域幅要件、アプリケーションのトラフィック挙動に関連付けられたパラメータ、およびアプリケーションのトラフィックタイプのうちの少なくとも１つを含み得る。パラメータは、例えば、限定ではないが、所定の時間間隔あたりの通信の数、通信間の時間遅延、通信セッションあたりもしくは所定の持続時間あたりの伝送されるパケットの数、パケットサイズ、パラメータが適用される持続時間、または遅延許容誤差を示し得る。さらに前述のように、トリガは、アプリケーションもしくは第１のノードに関連付けられたデータレートが変化すべき必要があることの指示、アプリケーションもしくは第１のノードに関連付けられたデータフロープロパティが変化すべき必要があることの指示、データ転送イベントの通知、またはアプリケーションと第１のノードとの間の通信の周波数が変化するであろうことの指示を含み得る。

例示的実施形態によると、図５を参照して、「Ｔ７」とも称され得る新しいインターフェース５０２が、ＭＴＣ−ＩＷＦ１１２とＰＣＲＦ１０１との間でＭＴＣアーキテクチャ内に追加される。一側面では、ＡＦは、ＰＣＲＦ１０１に、ＭＴＣ−ＩＷＦおよびＴｓｐインターフェースを介して、スモールデータフロー情報をプロビジョニングする。別の例示的側面では、アプリケーションフロー情報要求／回答と呼ばれる新しいダイアメータメッセージが、このスモールデータフロー情報をＴｓｐおよびＴ７インターフェース上で搬送するために導入される。

いくつかのＭＴＣシナリオでは、ＳＣＳは、Ｔｓｐインターフェースを経由して、サービス情報を送信し得る。ＡＦセッションを確立および維持するためのＡＦとＰＣＲＦとの間のメッセージは、ＳＣＳによって、ＭＴＣ−ＩＷＦへのＴｓｐインターフェースを経由して再使用されることができる。ＭＴＣ−ＩＷＦは、この情報を適切なＰＣＲＦに転送することができる。ＭＴＣ−ＩＷＦは、ＰＣＲＦに向かうダイアメータプロキシとしての役割りを果たし得るか、または、それは、ＰＣＲＦとの新しいインターフェース（例えば、Ｔ７またはＲｘ’）を有することができる。

図６も参照すると、ＳＣＳ１００がＰＣＲＦ１０１とのセッション情報を作成または修正するための例示的コールフローが、示される。図６は、ＢＢＥＲＦ１０２、ＰＣＥＦ１０４、ＭＴＣ−ＩＷＦ１１２、ＰＣＲＦ１０１、およびＳＣＳ１００を含む例示的ネットワーク６００を示す。例示的ネットワーク６００は、開示される主題の説明を促進するために簡略化され、本開示の範囲を限定することを意図するものではないことを理解されたい。他のデバイス、システム、および構成は、ネットワーク６００等のネットワークに加え、またはその代わりに、本明細書に開示される実施形態を実装するために使用され得、全てのそのような実施形態は、本開示の範囲内として検討される。さらに、参照番号は、図中の同一または類似特徴を示すために、種々の図中で繰り返され得ることを理解されたい。

図６の３および９を参照すると、Ｔｓｐインターフェースを経由したアプリケーションフロー情報（ＡＦＩ）要求／回答メッセージは、限定ではないが、一例として提示される以下のＡＶＰを含み得る。

図６のステップ５および８を参照すると、Ｔ７インターフェースを経由したアプリケーションフロー情報要求／回答メッセージは、限定ではないが、一例として提示される、以下のＡＶＰを含み得る。Ｔ７インターフェース上の例示的ＡＶＰは、ｅｘｔｅｒｎａｌ−ｉｄの代わりに、ｕｓｅｒ−ｎａｍｅ ＡＶＰを使用することに留意されたい。ＭＴＣ−ＩＷＦ１１２は、ｅｘｔｅｒｎａｌ−ｉｄを、例えば、ＩＭＳＩ等の内部オペレータ識別子である、ｕｓｅｒ−ｎａｍｅに変換し得る。

したがって、図５および６を参照して上で述べたように、第１のノード、例えば、ＳＣＳ１００は、トリガに基づいて、第２のノードをプロビジョニングすることができる。第２のノード、例えば、ＰＣＲＦは、第１のノードによって、データフローおよびアプリケーションに関連付けられた情報をプロビジョニングされることができ、第２のノードは、情報をアプリケーションに配信するために、または情報をアプリケーションから受信するために使用されるべき方法を選択するためのルールを決定することができる。第１のノードは、ダイアメータメッセージをＭＴＣ−ＩＷＦまたはサービス能力エクスポージャ機能（ＳＣＥＦ）に送信することによって、第２のノードをプロビジョニングすることができる。ダイアメータメッセージは、アプリケーションに関連付けられた媒体タイプ、アプリケーションのアプリケーション識別子、アプリケーションの帯域幅要件、アプリケーションのトラフィック挙動に関連付けられたパラメータ、およびアプリケーションのトラフィックタイプのうちの少なくとも１つを含み得る。

ここで図７を参照すると、別の例示的実施形態では、スモールデータフロー情報をＭＴＣ−ＩＷＦ１１２を介してＣＮに送信する代わりに、ＡＳ／ＳＣＳ１００は、スモールデータフロー情報を直接ＵＤＲ内に記憶し得、それによって、スモールデータフロー情報は、データフローがアクティブにされると、または新しいベアラが構成されると、ＰＣＲＦもしくは他のコアネットワークノードによって読み出されることができる。ＡＳ／ＳＣＳは、前述の同一メッセージを使用することができる。図７は、３ＧＰＰ ＴＲ ２３．８６２「ＥＰＣ ｅｎｈａｎｃｅｍｅｎｔｓ ｔｏ Ｓｕｐｐｏｒｔ Ｉｎｔｅｒｗｏｒｋｉｎｇ ｗｉｔｈ Ｄａｔａ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｖｉｄｅｒｓ（ＭＯＳＡＰ）」から再現されている。図７に図示される非ＩＭＳ ＡＳは、ＳＣＳであり得る。Ｍｈインターフェースは、ＳＣＳによって、ＨＳＳ−ＦＥ（ＨＳＳフロントエンド）を介して、スモールデータフロー情報をＵＤＲにプロビジョニングするために使用され得る。そして、ＰＣＲＦは、そのＵｄインターフェースを使用して、スモールデータフロー情報をＵＤＲから読み出し得る。

本明細書に説明されるように、スモールデータフロー情報は、例えば、限定ではないが、パケットの数、パケットサイズ等、フローの種々のトラフィック特性を含み得る。ＰＣＲＦは、この情報を読み取り、スモールデータのためにマークされるべきフローを決定することができる。一例として、ＡＳ／ＳＣＳにトラフィック特性を提供させる目的は、ＡＳ／ＳＣＳにスモールデータを決定させ、単に、フロー情報（５−タプル）を提供させるのではなく、ネットワーク、例えば、（ＰＣＲＦ）が、ＳＤと見なされることができるものを決定することを可能にすることである。

ある例では、ＡＳ／ＳＣＳは、Ｍｈインターフェースを使用して、トラフィック特性をＵＤＲの共通ユーザエリア内に記憶する。ＵＤＲは、アクセス制御を行い、動作が許可されるかどうかをチェックする。ＩＰ−ＣＡＮセッション確立中、ＰＣＲＦは、ユーザに関連付けられたトラフィック特性に対してＵＤＲにクエリし得る。ＰＣＲＦは、ＰＣＣルール形成中、トラフィック特性情報を使用することができる。そして、例えば、ダウンリンクＰＣＣルールが、以下に説明されるように構成されることができ、そして、アップリンクＰＣＣルールが、以下に説明されるように構成されることができる。ＡＳ／ＳＣＳがＵＤＲ内のフロー情報を更新すると、ＰＣＲＦは、例えば、変更が知らされるようにサブスクライブしている場合、変更されたデータを通知され得る。ＰＣＲＦは、次いで、適宜、ＰＣＣルールを修正し得る。

（ダウンリンクＩＰフローへのスモールデータフロー情報の適用）
ここで、例示的実施形態による、ＰＣＲＦがＡＳ／ＳＣＳから受信したスモールデータの新しい情報がネットワーク内に適用され得る方法に目を向けると、ＰＣＲＦが新しいサービス情報をＡＳ／ＳＣＳから受信すると、ＰＣＣ／ＱｏＳルールを形成し、既存のプロシージャを使用して、それをＰＣＥＦ／ＢＢＥＲＦに送信し得る。ＰＣＣ／ＱｏＳルールにおいて、ＰＣＲＦは、スモールデータと見なされるべきフロー／サービスを示すための新しい情報を含み得る。これは、ＰＣＲＦがＰＣＥＦに送信するＰＣＣルールまたはＰＣＲＦがＢＢＥＲＦに送信するＱｏＳルール内の「サービスデータフローフィルタ」情報を修正することによって行われることができる。一側面では、ＰＣＣルールは、Ｇｘインターフェースを経由して、ＰＣＥＦに送信され、ＱｏＳルールは、Ｇｘｘインターフェースを経由して、ＢＢＥＲＦに送信される。図２は、ＰＣＣアーキテクチャ内のこれらのインターフェースを示す。

ＰＣＲＦ、ＰＧＷ、ＰＣＥＦ、およびＢＢＲＥＦ等のネットワークノードは、ここでは、データフローがプロビジョニングされているルールに準拠するであろうという仮定の下で進行し得ることに留意されたい。ネットワークノードは、各フローを監視し、フローの挙動がＡＳ／ＳＣＳによってプロビジョニングされているものと異なるかどうかを検出し得る。

一例として、アップリンクフローの挙動がＡＳ／ＳＣＳによって構成されたものと異なる場合、それは、デバイスに関する問題が存在すること、デバイスが危険にさらされていること等の指示であり得る。例示的実施形態では、３ＧＰＰコアネットワークノードは、フローを終了させるメッセージを開始、および／またはＡＳ／ＳＣＳに送信されるべき通知を開始し得る。通知は、検出されたものの指示およびネットワークによって行われたアクション（例えば、終了）を含み得る。メッセージは、ＡＳ／ＳＣＳに、デバイスの接続を終了させ得る。通知は、例えば、ＰＣＲＦ、ＭＴＣ−ＩＷＦ、またはＳＣＥＦ等の中間ノードを介して送信され得る。

別の例として、ダウンリンクフローの挙動がＡＳ／ＳＣＳによって構成されたものと異なる場合、それは、誰かがデバイスに違法にアクセスすること、不適切な様式でデバイスにアクセスすること、サービス拒否攻撃を開始することを試みていること等の指示であり得る。例示的実施形態では、３ＧＰＰコアネットワークノードは、フローを終了させるメッセージを開始、および／またはＡＳ／ＳＣＳに送信されるべき通知を開始し得る。通知は、検出されたものの指示およびネットワークによって行われたアクション（例えば、終了）を含み得る。メッセージは、ＡＳ／ＳＣＳに、デバイスの接続を終了させ得る。通知は、ＰＣＲＦ、ＭＴＣ−ＩＷＦ、またはＳＣＥＦ等の中間ノードを介して送信され得る。

ここで図８および９を参照すると、Ｇｘ参照点（ＰＣＲＦ−ＰＣＥＦ）は、例示的実施形態に従って、ＰＣＲＦがまとめたスモールデータ情報をＰＣＥＦに提供するために修正され得る。図８は、ＢＢＥＲＦ１０２、ＰＣＥＦ１０４、ＴＤＦ１１４、Ｖ−ＰＣＲＦ１０６、Ｈ−ＰＣＲＦ１０８、ＳＰＲ１１０、およびＯＣＳ１１６を含む例示的ネットワーク８００を示す。図９は、ＢＢＥＲＦ１０２、ＰＣＥＦ１０４、ＴＤＦ１１４、Ｖ−ＰＣＲＦ１０６、Ｈ−ＰＣＲＦ１０８、およびＯＣＳ１１６を含む、例示的ネットワーク９００を示す。例示的ネットワーク８００および９００は、開示される主題の説明を促進するために簡略化され、本開示の範囲を限定することを意図するものではないことを理解されたい。他のデバイス、システム、および構成は、ネットワーク８００ならびに９００等のネットワークに加え、またはその代わりに、本明細書に開示される実施形態を実装するために使用され得、全てのそのような実施形態は、本開示の範囲内として検討される。さらに、参照番号は、図中の同一または類似特徴を示すために、種々の図中で繰り返され得ることを理解されたい。

図８および９は、ＰＣＣルールプロビジョニングのために、Ｇｘインターフェースを経由して使用され得る例示的プロシージャを示す。種々の例示的実施形態によると、スモールデータ情報は、ＰＣＲＦとＰＣＥＦ（Ｐ−ＧＷ）との間で搬送される。例示的プル配信プロシージャ（ＰＣＥＦ１０４によって請求されたプロビジョニング）が、図８に示される。図８を参照すると、ＰＣＥＦ１０４は、ＣＣ−Ｒｅｑｕｅｓｔメッセージを使用して、スモールデータ情報をＰＣＲＦから得ることができる。ある実施形態による、例示的更新されたＣＣ−Ｒｅｑｕｅｓｔメッセージが、以下に説明される。図示される例では、ＣＣ−Ａｎｓｗｅｒメッセージは、ＰＣＣルールをプロビジョニングするために使用される。このメッセージは、スモールデータフローフィルタ／情報を含むように修正されることができる。ある実施形態による、例示的更新されたＣＣ−Ａｎｓｗｅｒメッセージが、以下に説明される。図８に示されるコールフローは、概して、３ＧＰＰＴＳ２９．２１３から再現されているが、３、３ａ、３ｃ、１２、１２ａ、１２ｄ、１２ｅ、および１２ｇにおけるメッセージは、図示される実施形態に従って修正される。

図９は、例示的実施形態による、例示的プッシュ配信プロシージャ（非請求プロビジョニング）を描写する。例えば、ＰＣＲＦ開始ＩＰ−ＣＡＮセッション修正中、ＰＣＲＦは、このプロシージャを使用して、ＰＣＥＦ１０４内のＰＣＣルールをプロビジョニング（例えば、アクティブ化または非アクティブ化もしくは修正）することができる。このプロシージャの一部としてＰＣＲＦからＰＣＥＦに送信されるＲＡ−Ｒｅｑｕｅｓｔメッセージは、ＰＣＣルールをプロビジョニングし得る。このメッセージは、スモールデータフローフィルタ／情報を含むように修正されることができる。例示的更新されたＲＡ−Ｒｅｑｕｅｓｔメッセージが、以下に説明される。図９に示されるコールフローは、概して、３ＧＰＰ ＴＳ ２９．２１３から再現されているが、６、６ａ、６ｄ、６ｆ、８、８ａ、８ｂ、および８ｄにおけるにおけるメッセージは、図示される実施形態に従って修正される。

前述のように、例えば、ＣＣＲ、ＣＣＡ、およびＲＡＲ等の種々のダイアメータメッセージは、種々の実施形態に従って修正され得る。さらに、ＡＶＰも、修正され得る。例示的実施形態に従って修正される例示的ＡＶＰは、以下で下線が引かれている。さらに、「Ｓｕｐｐｏｒｔｅｄ−Ｆｅａｔｕｒｅｓ」ＡＶＰは、それぞれのノードのスモールデータ情報ハンドリング能力を示すように修正されることができる。

（例示的ＣＣ−Ｒｅｑｕｅｓｔ（ＣＣＲ）コマンド）
メッセージフォーマット：

上で示されるように、新しいＡＶＰが、「Ｐａｃｋｅｔ−Ｆｉｌｔｅｒ−Ｉｎｆｏｒｍａｔｉｏｎ」ＡＶＰ、「ＱｏＳ−Ｉｎｆｏｒｍａｔｉｏｎ」ＡＶＰ、および「Ｒｏｕｔｉｎｇ−Ｆｉｌｔｅｒ」ＡＶＰ（「Ｒｏｕｔｉｎｇ−Ｒｕｌｅ−Ｉｎｓｔａｌｌ」ＡＶＰの一部）に追加され、スモールデータパケットフィルタ／情報を示すことができる。

（例示的ＣＣ−Ａｎｓｗｅｒ（ＣＣＡ）コマンド）
例示的メッセージフォーマット：

前述のように、「Ｃｈａｒｇｉｎｇ−Ｒｕｌｅ−Ｉｎｓｔａｌｌ」ＡＶＰおよび／または「ＱｏＳ−Ｉｎｆｏｒｍａｔｉｏｎ」ＡＶＰは、本明細書の表１に説明される情報およびフィルタ等のスモールデータフローフィルタ／情報を含むように修正されることができる。
（例示的Ｒｅ−Ａｕｔｈ−Ｒｅｑｕｅｓｔ（ＲＡＲ）コマンド）
例示的メッセージフォーマット：
前述のように、「Ｃｈａｒｇｉｎｇ−Ｒｕｌｅ−Ｉｎｓｔａｌｌ」ＡＶＰは、スモールデータフローフィルタ／情報を含むように修正されることができる。

ここで図１０および１１を参照すると、Ｇｘｘ参照点（ＰＣＲＦ−ＢＢＲＥＦ）は、例示的実施形態に従って、ＰＣＲＦがまとめたスモールデータ情報をＢＢＲＥＦに提供するように修正され得る。図１０は、ＢＢＥＲＦ１０２、ＰＣＥＦ１０４、Ｖ−ＰＣＲＦ１０６、Ｈ−ＰＣＲＦ１０８、およびＳＰＲ１１０を含む、例示的ネットワーク１０００を示す。図１１は、ＢＢＥＲＦ１０２、ＰＣＥＦ１０４、Ｖ−ＰＣＲＦ１０６、およびＨ−ＰＣＲＦ１０８を含む例示的ネットワーク１１００を示す。例示的ネットワーク１０００および１１００は、開示される主題の説明を促進するために簡略化され、本開示の範囲を限定することを意図するものではないことを理解されたい。他のデバイス、システム、および構成は、ネットワーク１０００ならびに１１００等のネットワークに加え、またはその代わりに、本明細書に開示される実施形態を実装するために使用され得、全てのそのような実施形態は、本開示の範囲内として検討される。さらに、参照番号は、図中の同一または類似特徴を示すために、種々の図中で繰り返され得ることを理解されたい。

図１０および１１は、ＱｏＳルールプロビジョニングのために、Ｇｘｘインターフェースを経由して使用され得る例示的プロシージャを示す。種々の例示的実施形態によると、スモールデータ情報は、ＰＣＲＦとＢＢＥＲＦ１０２との間で搬送される。例示的プル配信プロシージャ（ＢＢＥＲＦ１０２によって請求されたプロビジョニング）が、図１０に示される。図１０を参照すると、ＰＣＥＦ１０４は、前述のＣＣ−Ｒｅｑｕｅｓｔメッセージを使用して、スモールデータ情報をＰＣＲＦから得ることができる。図示される実施例では、ＣＣ−Ａｎｓｗｅｒメッセージは、ＱｏＳルールをプロビジョニングするために使用される。このメッセージは、スモールデータフローフィルタ／情報を含むように修正されることができる（例えば、前述のように）。図１０に示されるコールフローは、概して、３ＧＰＰ ＴＳ ２９．２１３から再現されているが、２、２ａ、２ｃ、８、８ａ、８ｃ、８ｄ、および８ｅにおけるメッセージは、図示される実施形態に従って修正される。

図１１は、例示的実施形態による、例示的プッシュ配信プロシージャ（非請求プロビジョニング）を描写する。例えば、ＰＣＲＦ開始ＩＰ−ＣＡＮセッション修正中、ＰＣＲＦは、このプロシージャを使用して、ＢＢＥＲＦ１０２内のＱｏＳルールをプロビジョニング（例えば、アクティブ化または非アクティブ化もしくは修正）することができる。このプロシージャの一部としてＰＣＲＦからＢＢＥＲＦ１０２に送信されるＲＡ−Ｒｅｑｕｅｓｔメッセージは、ＱｏＳルールをプロビジョニングし得る。このメッセージは、スモールデータフローフィルタ／情報を含むように修正されることができる。例示的更新されたＲＡ−Ｒｅｑｕｅｓｔメッセージは、前述の通りである。図１１に示されるコールフローは、概して、３ＧＰＰ ＴＳ ２９．２１３から再現されているが、２および２ｃにおけるメッセージは、図示される実施形態に従って修正される。

ＰＣＥＦ／ＢＢＥＲＦが、前述のようにＰＣＣ／ＱｏＳルールを受信すると、それは、３ＧＰＰ ＴＳ ２３．２０３第６．１．１．４節に規定されるように、ベアラ結合を行い得る。本明細書に説明されるスモールデータフロー／サービスをサポートするために、ベアラ結合機能は、ＰＣＣ／ＱｏＳルール内でスモールデータのためにマークされているフローを検討し、新しいベアラがスモールデータフローをサポートするために作成される必要があるかどうか、または既存のベアラが使用されることができるかどうかを決定し得る。機能は、スモールデータフィルタルールがデフォルトベアラＴＦＴまたは専用ベアラＴＦＴの一部として含まれることができるかどうかも決定し得る。ある実施例では、ベアラ結合機能は、スモールデータの使用を３ＧＰＰネットワーク内の関連エンティティ（例えば、ＵＥ、Ｓ−ＧＷ、ＭＭＥ等）に通信する。

例示的実施形態によると、新しいＱＣＩ値が、スモールデータベアラのために使用される。例示的ＱＣＩ値は、以下の表２に説明される。例えば、ＱＣＩ値は、遅延耐性があるが、低パケット損失を要求し得る、スモールデータベアラのために使用されることができる。さらなる実施例として、別のＱＣＩ値は、遅延耐性があり得るが、パケット損失の耐性がないスモールデータベアラのために使用されることができる。

（ダウンリンクＩＰフローへのスモールデータフロー情報の適用）
一例として、スモールデータのためにベアラを指定することは、ベアラ上の全データフローがスモールデータと見なされるようにし得る。これは、いくつかのシナリオ、例えば、非ＭＴＣ ＵＥアプリケーション（例えば、チャットアプリケーション）を伴うシナリオでは、望ましくない場合がある。これらのシナリオでは、いくつかのＭＴＣデバイスに対して、ネットワークは、例えば、ベアラ全体をマークするのではなく、特定のＩＰフローまたはＩＰフローの組のみがスモールデータフローとして見なされることを欲し得る。例示的実施形態では、ネットワークは、ＴＦＴを使用して、どのＩＰフローがスモールデータのために検討される必要があるかについてＵＥに知らせる。

ＴＦＴに関する背景として、３ＧＰＰネットワークでは、ＵＥからのデータトラフィックは、ＱｏＳ要件に基づいて分類され、異なるベアラを経由して伝送される。データトラフィックの分類は、ＴＦＴの助けを借りて達成される。ＴＦＴは、ＩＰフローまたはサービス（ＩＰフローの組）を固有に識別することができるパケットフィルタを含む。１つのベアラは、それに関連付けられた１つのＴＦＴを有することができる。デフォルトベアラは、ＴＦＴを有することも、有しないこともある。専用ベアラは、コアネットワークによって、「専用ＥＰＳベアラコンテキストアクティブ化要求」メッセージ内でＴＦＴを割り当てられ、デフォルトベアラは、「ＥＰＳベアラコンテキスト修正要求」メッセージ内でＴＦＴを割り当てられることができる。デフォルトＥＰＳベアラコンテキストは、アクティブ化プロシージャ中に割り当てられる任意のＴＦＴを有していない（例えば、「デフォルトＥＰＳベアラコンテキストアクティブ化要求」メッセージ内に）。専用またはデフォルトベアラのＴＦＴの修正は、「ＥＰＳベアラコンテキスト修正要求」メッセージ内のベアラ修正プロシージャ中にコアネットワークによって行われることができる。ＴＦＴは、特定のＥＰＳベアラに関連付けられた全パケットフィルタの組を有する。ＴＦＴは、最大１６のパケットフィルタを有し得る。各パケットフィルタは、優先値を有し、この値は、ＰＤＮ接続に関連付けられた全ＴＦＴ内の全パケットフィルタ間で固有である必要がある。ＵＥは、データが伝送される必要があるベアラを見つけるために、その優先度において、ＰＤＮ接続の全ＴＦＴの全パケットフィルタを評価する。図１２は、ＥＰＳにおいてベアラ概念を用いるＴＦＴの現在のリンケージを描写する。以下の表３は、３ＧＰＰ ＴＳ ２４．００８の第１０．５．６．１２節に定義される、例示的トラフィックフローテンプレート（ＴＦＴ）情報要素（ＩＥ）を示す。

上の表４は、ＴＦＴの例示的パケットフィルタのリストを示す。種々の例示的実施形態によると、修正が、上で要約されたＴＦＴに行われる。表４を参照すると、示されるパケットフィルタリスト内の各パケットフィルタは、２つのスペアビットを有する。例示的実施形態では、これらのスペアビットは、スモールデータ専用パケットフィルタ、通常パケットフィルタ、または両方として特定のパケットフィルタをマークするために使用されることができる。例示的修正されたパケットフィルタリストは、以下に示される（表１６参照）。専用ベアラのためのＴＦＴおよびデフォルトベアラのためのＴＦＴは、この修正されたパケットフィルタリストを含むことができる。本明細書に開示される修正に対して、いくつかの利点が存在する。

例えば、限定ではないが、「スモールデータ専用」としてマークされたパケットフィルタは、これらのパケットフィルタが、接続モードにおける通常のパケット分類中、評価されないであろうため、特定のベアラに結び付けられるのではなく、ＰＤＮ接続に属するものとして見なされ得る。さらなる例として、「スモールデータ専用」としてマークされたパケットフィルタは、「通常」または「両方」としてマークされたパケットフィルタより低い優先順位を有するであろう。最低優先順位を示す一般的予備値は、「スモールデータ専用」としてマークされたフィルタのために使用されることができる。アイドルモードにあるとき、「スモールデータ専用」フローのための低優先順位を割り当てることによって、パケットフィルタがアップリンクパケットのためにマッチングされる場合、スモールデータのためにマークされたベアラのためのマッチングが、スモールデータのためにマークされたＩＰフローのマッチングが見つけられる前に識別される。接続モードでは、例えば、「スモールデータ専用」パケットフィルタは、評価されないこともあり、したがって、それらの優先順位値は、どんな有意性も有していないこともある。

例示的実施形態では、「スモールデータ専用」または「両方」としてマークされたパケットフィルタは、ＵＥによって、アイドルモードから接続モードへの移行中、評価されるであろう。ある場合には、所与のＵＥが送信すべきアップリンクデータを有し、かつＵＥがアイドルモードにあるとき、ＵＥは、最初に、アップリンクデータが送信される必要があるＰＤＮ接続を決定し得る。これは、アップリンクデータのソースＩＰアドレスに基づいて、ＵＥによって決定され得る。ＰＤＮ接続が決定された後、例えば、次いで、ＵＥは、それが有するアップリンクデータが、このＰＤＮ接続に属するＴＦＴ内で「スモールデータ専用」または「両方」としてマークされたパケットフィルタのいずれかにマッチングするかどうかチェックし得る。マッチングがある場合、例示的実施形態によると、ＵＥは、通常のサービス要求プロシージャの代わりに、スモールデータ転送プロシージャを行う。

ある実施例では、「スモールデータ専用」としてマークされたパケットフィルタは、ＵＥがすでに接続モードにあるとき、データを伝送するためのベアラを識別する目的のための通常のトラフィックフロー分類中、ＵＥによって評価されない。本例示的場合では、「通常」または「両方」としてマークされたパケットフィルタは、ＵＥによって評価される。スモールデータのために修正されたパケットフィルタは、コアネットワークによって、ベアラ修正プロシージャまたは専用ベアラアクティブ化プロシージャにおいてＵＥに通信されることができる。例示的実施形態によると、専用ＥＰＳベアラコンテキストアクティブ化要求ＥＳＭメッセージおよびＥＰＳベアラコンテキスト修正要求ＥＭＳメッセージは、以下にさらに説明されるように、更新されたＴＦＴ ＩＥを搬送するように修正される。例示的実施形態では、ＴＦＴ概念、およびＵＥ内でＴＦＴを作成または修正するためのプロシージャは、同一のままであるが、ＥＳＭメッセージは、修正される。

例示的実施形態によると、ＩＰフローを識別するための既存のＴＦＴ概念は、スモールデータのために拡張され、コアネットワークは、別個のＴＦＴを使用して、ＵＥに、どのＩＰフローがスモールデータフローとして検討される必要があるかを知らせることができる。本明細書に開示されるように、スモールデータＩＰフローにマッチングするためのパケットフィルタを含む新しいスモールデータＴＦＴが、使用されることができる。図１３を参照すると、図示される実施形態によると、このＴＦＴは、特定のベアラではなく、ＰＤＮ接続にリンクされる。ＴＦＴは、例えば、アイドルモードから接続モードへの移行中、所与のＵＥが、最初に、それを通してアップリンクデータが送信されるＰＤＮ接続を選択するので、ＰＤＮ接続にリンクされる。ＵＥは、次いで、ＰＤＮ接続内でＴＦＴを検索する。この例を継続すると、ＳＤ ＴＦＴがＰＤＮ接続ごとである場合、ＵＥは、最初に、ＳＤ ＴＦＴ内でパケットデータフィルタマッチングを探すことができる（他のＴＦＴを探す前に）。マッチングがある場合、ＵＥは、通常のサービスプロシージャの代わりに、スモールデータプロシージャを行う。これは、データがスモールデータであるかどうかを識別するためのＣＮとのトランザクションを低減させることができる。スモールデータＴＦＴは、ネットワークによって、ＰＤＮ接続設定中作成されるか、またはベアラ修正プロシージャを通して動的に作成されることができる。

例示的実施形態では、スモールデータＴＦＴは、アイドルモードから接続モードへの移行の間のみ、所与のＵＥによって評価される。ＵＥが送信するためのアップリンクデータを有し、かつＵＥがアイドルモードにあるとき、ＵＥは、最初に、アップリンクデータが送信される必要があるＰＤＮ接続を決定し得る。これは、ＵＥによって、アップリンクデータのソースＩＰアドレスに基づいて決定され得る。ＰＤＮ接続が決定された後、例えば、次いで、ＵＥは、スモールデータＴＦＴがこのＰＤＮ接続のために利用可能であるかどうかをチェックする。利用可能である場合、例えば、ＵＥは、それが有するアップリンクデータがこのＴＦＴ内のパケットフィルタのいずれかにマッチングするかどうかを決定するためにチェックする。マッチングがある場合、ＵＥは、通常のサービス要求プロシージャの代わりに、スモールデータ転送プロシージャを行い得る。ある実施例では、「パケットフィルタ評価優先順位」は、ＳＤ ＴＦＴ内のパケットフィルタのためのマッチングを行う間、使用されない。ＳＤ ＴＦＴ内のパケットフィルタの「パケットフィルタ評価優先順位」は、このＰＤＮ接続に属する他のベアラのＴＦＴ内の他のパケットフィルタに関して固有である必要はない。「パケットフィルタ評価優先順位」値は、ＳＤ ＴＦＴ内のパケットフィルタのための予備値に設定されることができる。ある実施例では、ＳＤ ＴＦＴ内のパケットフィルタは、ＵＥがデータを搬送する必要があるベアラを決定する必要があるとき、接続モード中、マッチングされない。この例示的場合では、通常のＴＦＴマッチングが、ＳＤ ＴＦＴ内のパケットフィルタを検討せずに、行われ得る。

種々の実施形態によると、ＨＳＳ／ＨＬＲ／ＵＤＲ内の加入者プロファイルは、限定ではないが、一例として提示される、以下の詳細で更新されることができる：加入者がスモールデータプロシージャを行うことが許可されるかどうか、および／またはそれが可能であるかどうかと、許可されるプロシージャのタイプ；ＵＥからの全データがスモールデータプレーン（ＵＥをスモールデータサービスのみに接続するように制限するために使用され得る）を使用すべきかどうか；および、あるＰＤＮ接続がスモールデータプレーンを使用すべきかどうか。

初期アタッチ中、ＭＭＥ、Ｓ−ＧＷ、またはＰ−ＧＷは、３ＧＰＰ ＴＳ ２９．２７２「Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ （ＭＭＥ） ａｎｄ Ｓｅｒｖｉｎｇ ＧＰＲＳ Ｓｕｐｐｏｒｔ Ｎｏｄｅ （ＳＧＳＮ） ｒｅｌａｔｅｄ ｉｎｔｅｒｆａｃｅｓ ｂａｓｅｄ ｏｎ Ｄｉａｍｅｔｅｒ Ｐｒｏｔｏｃｏｌ」に説明される、加入者データ挿入メッセージ内の加入者情報とともに、前述の情報を読み出し得る。前述の情報は、ＭＭＥ、Ｓ−ＧＷ、またはＰ−ＧＷによって、ＵＥからのスモールデータ接続要求を承認し、スモールデータサービスのための制限を適用するためにも使用されることができる。ＭＭＥ、Ｓ−ＧＷ、またはＰ−ＧＷは、例えば、アタッチ受諾メッセージ等のメッセージ内において、この情報をＵＥにパスし得る。この情報は、ＭＭＥ、Ｓ−ＧＷ、またはＰ−ＧＷによって、データが、例えば、ＳＭＳ、ＮＡＳメッセージング、ＲＲＣメッセージング等のスモールデータ配信方法を使用して、ＵＥに／から配信されるべきであるかどうかを決定するためにも使用され得る。代替として、ＭＭＥ、Ｓ−ＧＷ、またはＰ−ＧＷは、同様に３ＧＰＰ ＴＳ ２９．２７２に説明される、場所更新要求メッセージを用いて加入者情報とともに、前述の情報を読み出し得る。

したがって、ある場合には、装置、例えば、ＭＭＥを備えている装置は、第１のメッセージをＵＥから受信し得る。第１のメッセージは、ＵＥがスモールデータプロシージャをサポートすることの指示を含むアタッチ要求（図１Ａ参照）を含み得る。代替として、または加えて、第１のメッセージは、ＵＥがスモールデータプロシージャを使用することの要求を含むアタッチ要求を備え得る。装置はまた、第２のメッセージをネットワークノード、例えば、ＨＳＳから受信し得る。第２のメッセージは、スモールデータプロシージャを使用すべきである１つ以上のＰＤＮ接続を示し得る。第２のメッセージは、１つ以上のＰＤＮ接続の各々に対応するスモールデータプロシージャのタイプも示し得る。第２のメッセージに基づいて、装置は、第１のメッセージに応答し得る。例えば、以下にさらに説明されるように、応答は、ＵＥが第２のメッセージに示されているスモールデータプロシージャのうちの１つを使用するスモールデータモードで機能すべきことの指示を含むアタッチ応答メッセージ（図１Ａ参照）を備え得る。装置は、次いで、第２のメッセージに示されているスモールデータプロシージャのうちの１つを使用して、データを配信し得る。装置はまた、第２のメッセージに示されているスモールデータプロシージャのうちの１つに従って、データをＵＥから受信し得る。さらに、スモールデータプロシージャは、ＮＡＳメッセージングを介して示され得る。

別の例示的実施形態では、オペレータは、加入者プロファイルをＳＰＲ／ＵＤＲ内にスモールデータ情報とともに構成し得る。限定ではないが、一例として提示される、以下の情報は、ＳＰＲ／ＵＤＲ内に構成されることができる。
・ スモールデータと見なされるべきサービスおよびＩＰフロー情報（サービスデータフローフィルタ−以下参照）。
・ 例えば、パケットサイズ、パケット周波数等のスモールデータのトラフィック特性。表１は、例示的特性を提供する。ＰＣＣアーキテクチャ要素（例えば、ＰＣＲＦ、ＰＣＥＦ、ＢＢＥＲＦ、およびＴＤＦ）は、この情報を使用して、スモールデータフローを決定することができる。
・ スモールデータ情報をネットワーク（ＰＣＲＦ）に提供することができる、ＡＳ／ＳＣＳのリストと、ＡＳ／ＳＣＳからの情報がＳＰＲ／ＵＤＲからＰＣＲＦに提供される情報をオーバーライドすることができるかどうかを示すフラグ。このプロシージャの例は、上で詳細に説明されている。ある例では、ＰＣＲＦは、承認されたＡＳ／ＳＣＳからのＳＤ情報のみを受諾することができる。

ある例では、ＡＳ／ＳＣＳは、ＰＣＲＦによって読み出され、ネットワーク上に適用され得るスモールデータ情報をＵＤＲ内に記憶することもできる。このプロシージャの例は、前述の通りである。ＳＰＲ内の類似構成は、ＧＰＲＳおよびＵＭＴＳネットワーク内にも適用可能であることを理解されたい。

前述のように、ＥＭＭおよびＥＳＭメッセージは、例示的実施形態に従って修正され得る。表５を参照すると、例示的アタッチ要求メッセージの情報要素が、示される。このメッセージは、ＵＥのスモールデータ能力およびスモールデータモードでアタッチするその要求について、ＭＭＥに知らせるように修正される。したがって、表５に示されるように、スモールデータ指示ＩＥ（前述）が、追加され、ＵＥネットワーク能力ＩＥは、修正される。代替実施例では、例えば、「ＥＰＳアタッチタイプ」または「ＭＳネットワーク能力」等の既存の情報要素は、スモールデータ指示を搬送するために使用され得る。

ここで表６を参照すると、アタッチ受諾メッセージが、例示的実施形態に従って修正され得る。アタッチ応答メッセージとも称され得る、アタッチ受諾メッセージは、ＵＥが、加入者レポジトリ、例えば、ＨＳＳから読み出されたスモールデータプロシージャのうちの１つを使用するスモールデータモードで機能することの指示を含み得る。アタッチ受諾または応答メッセージは、ＵＥがネットワークとアタッチされたままである持続時間全体にわたってスモールデータモードで機能する必要があるかどうかをＵＥに知らせるようにも修正され得る。スモールデータ指示ＩＥは、アタッチ受諾メッセージに追加されることができる。代替実施例では、スモールデータ指示は、例えば、「ＥＰＳアタッチ結果」ＩＥの「スペアハーフオクテット」等、既存のＩＥに追加されることができる。

表７を参照すると、例示的ＰＤＮ接続性要求メッセージの情報要素が、示される。このメッセージは、ネットワークがスモールデータのためのデフォルトベアラをマークすることを要求するように修正される。したがって、示されるように、スモールデータ指示ＩＥが、追加される。

表８を参照すると、例示的ベアラリソース配分要求メッセージの情報要素が、示される。この例示的メッセージは、スモールデータのための専用ベアラをマークし、および／または新しいスモールデータＩＰフローフィルタを提供することを要求するように修正される。したがって、示されるように、スモールデータ指示ＩＥが、追加され、トラフィックフロー集合体ＩＥが、修正され得る。

表９を参照すると、例示的ベアラリソース修正要求メッセージの情報要素が、示される。この例示的メッセージは、ベアラのスモールデータマーキングのステータスを変更することを要求するように、またはスモールデータＩＰフローパケットフィルタのステータスを修正するように修正される。したがって、示されるように、スモールデータ指示ＩＥが、追加され、トラフィックフロー集合体ＩＥが、修正され得る。

表１０を参照すると、例示的デフォルトＥＰＳベアラコンテキストアクティブ化要求メッセージの情報要素が、示される。この例示的メッセージは、デフォルトベアラがスモールデータベアラと見なされる必要があるかどうかの指示を提供するように修正される。したがって、示されるように、スモールデータ指示ＩＥが、追加され得る。

表１１を参照すると、例示的専用ＥＰＳベアラコンテキストアクティブ化要求メッセージの情報要素が、示される。この例示的メッセージは、専用ベアラがスモールデータベアラと見なされる必要があるかどうかの指示を提供するように修正される。したがって、示されるように、スモールデータ指示ＩＥが、追加され得、ＴＦＴ ＩＥは、前述のように修正され得る。このメッセージはまた、スモールデータパケットフィルタをＵＥに提供し得る。ある例では、依然として、表１１を参照すると、スモールデータ指示ＩＥがこのメッセージ内に存在する場合、かつＳＤベアラを示す場合、このベアラ上の全データは、ＳＤと見なされるであろう。さらなる例として、スモールデータ指示ＩＥが存在する場合、かつ通常ベアラを示すが、ＴＦＴがスモールデータのためのパケットフィルタを有する場合、パケットフィルタにマッチングするデータは、依然として、スモールデータと見なされるであろう。

ここで表１２を参照すると、例示的ＥＰＳベアラコンテキスト修正要求メッセージの情報要素が、示される。この例示的メッセージは、ＳＤベアラとしてのベアラの動的修正につてＵＥに知らせるように、またはＴＦＴ内のスモールデータパケットフィルタを変更するように修正され得る。したがって、示されるように、スモールデータ指示ＩＥが、追加され得、ＴＦＴ ＩＥは、前述のように修正され得る。さらに、概して、表１１および１２を参照すると、第１のノード、例えば、ＳＣＳ１００は、トリガに基づいて、第２のノードをプロビジョニングすることができる。第２のノード、例えば、ＰＣＲＦは、第２のノードが情報をアプリケーションに配信するために、または情報をアプリケーションから受信するために使用されるべき方法を選択するためのルールを決定し得るように、第１のノードによって、データフローおよびアプリケーションに関連付けられた情報をプロビジョニングされることができる。第２のノードは、第３のノード、例えば、Ｐ−ＧＷ／ＰＣＥＦに、情報をアプリケーションに配信するために、または情報をアプリケーションから受信するために使用されるべき配信方法を選択するためのルールをプロビジョニングすることができる。ユーザ機器は、アプリケーションをホストすることができる。前述のように、第３のノードは、専用ＥＰＳベアラコンテキストアクティブ化要求メッセージまたは修正ＥＰＣベアラコンテキスト要求メッセージを使用して、ＵＥが使用するためのルールを配信することができる。さらに、第３のノードは、データフロー情報をデータの観察される挙動と比較し得、したがって、第３のノードは、比較に関連付けられたアクションを行うことができる（データフローを終了すること、または第２のノードに比較の結果を知らせること等）。代替として、前述のように、第２のノードは、サブスクリプションデータベースであることができ、サブスクリプションデータベースは、ｈインターフェースを経由して、プロビジョニングされることができる。

新しい情報要素（ＩＥ）が、本明細書に開示され、既存のＩＥｓは、種々の実施形態に従って、本明細書で修正される。例えば、ＵＥネットワーク能力ＩＥは、スモールデータプロシージャをサポートするためのＵＥの能力を示すように修正され得る。このＩＥおよびコーディング詳細の完全な定義は、３ＧＰＰ ＴＳ ２４．３０１の第９．９．３．３４節「Ｎｏｎ−Ａｃｃｅｓｓ−Ｓｔｒａｔｕｍ （ＮＡＳ） ｐｒｏｔｏｃｏｌ ｆｏｒ Ｅｖｏｌｖｅｄ Ｐａｃｋｅｔ Ｓｙｓｔｅｍ（ＥＰＳ）」に列挙される。表１３は、例示的実施形態による、修正されたＵＥネットワーク能力の実施例を示す。示されるように、オクテット７のビット７（元々は、スペアとしてマークされていた）は、ＵＥによって、スモールデータをサポートするためのその能力を示すために使用されることができる。

スモールデータ指示ＩＥが、本開示全体を通して使用される。スモールデータ指示情報要素は、所与のＵＥに、ＵＥがスモールデータモードで動作する必要があるかどうかを知らせてもよい。スモールデータ指示情報要素は、表１４および１５に示されるようにコーディングされ得る。ある実施例では、スモールデータ指示は、タイプ１情報要素である。

前述のように、パケットフィルタリストは、ＴＦＴ ＩＥの一部である。ＴＦＴ ＩＥは、３ＧＰＰ ＴＳ ２４．００８の第１０．５．６．１２節に定義される。パケットフィルタリストコーディングに対する例示的変更は、以下の表１６に示され、例示的変更は、下線が引かれる。表１７は、種々の実施形態による、例示的パケットフィルタタイプ値を示す。

ここで図１４を参照すると、３ＧＰＰ ＴＳ ２４．３０５「Ｓｅｌｅｃｔｉｖｅ Ｄｉｓａｂｌｉｎｇ ｏｆ ３ＧＰＰ Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ Ｃａｐａｂｉｌｉｔｉｅｓ （ＳＤｏＵＥ） Ｍａｎａｇｅｍｅｎｔ Ｏｂｊｅｃｔ （ＭＯ）」は、種々のＵＥ能力を選択的に有効および無効にするために使用され得る、管理オブジェクトを定義する。例示的実施形態によると、管理オブジェクトは、あるスモールデータフロー能力が有効および無効にされることを可能にするように拡張され得る。一例として、図１４に描写される例示的グラフィカルユーザインターフェース１４００を参照すると、リーフオブジェクトが、ＮＡＳおよびＲＲＣメッセージング等の制御プレーンメッセージングを介して、データパケットの伝送および受信を有効ならびに無効にするために追加されることができる。リーフオブジェクトは、ＮＡＳおよびＲＲＣメッセージング等の制御プレーンメッセージングを介して、パケットの数および周波数を限定するために追加されることができる。ＵＥは、ユーザが、制御プレーンメッセージングを介して、データパケットの伝送および受信を有効ならびに無効にすることを可能にするＧＵＩ、例えば、ＧＵＩ １４００を含み得る。ＧＵＩは、ユーザが、制御プレーンメッセージングを介して、パケットの数および周波数を限定することも可能にし得る。ＧＵＩは、所望に応じて、代替パラメータを監視および制御するために使用されることができることを理解されたい。さらに、ＧＵＩは、ユーザに、種々のチャートまたは代替視覚的描写を介して、ユーザが関心を持つ種々の情報を提供することができることを理解されたい。例えば、ＧＵＩは、ＧＵＩ設定に基づいて、リーフオブジェクト設定を調節し得るか、またはＧＵＩは、他の条件を検出し、ＧＵＩ設定およびＵＥのリアルタイム動作条件に基づいて、リーフオブジェクトを調節するアプリケーションに関連付けられ得る。例えば、ＧＵＩは、ユーザが、１時間あたりに送信されることができる制御プレーンメッセージの数を限定することを可能にし得る。アプリケーションが、ＵＥが制御プレーンメッセージングのその限界に到達したことを検出すると、リーフオブジェクトの設定を調節し、制御プレーンメッセージングを介して、データパケットを無効にし得る。後に、例えば、ある時間が経過後、アプリケーションは、再び、リーフオブジェクトに関する設定を調節することによって、制御プレーンメッセージングを介して、データパケットを再度有効にし得る。

前述のように、本明細書に説明される種々の技法は、ハードウェア、ファームウェア、ソフトウェア、もしくは適切である場合、それらの組み合わせに関連して実装され得る。そのようなハードウェア、ファームウェア、およびソフトウェアは、通信ネットワークの種々のノードに位置する装置の中に常駐し得る。装置は、本明細書に説明される方法をもたらすように、単独で、または互いに組み合わせて動作し得る。本明細書で使用される場合、用語「装置」、「ネットワーク装置」、「ノード」、「デバイス」、および「ネットワークノード」は、同義的に使用され得る。

図１５Ａは、１つ以上の開示される実施形態が実装され得る例示的マシンツーマシン（Ｍ２Ｍ）、モノのインターネット（ＩｏＴ）、またはモノのウェブ（ＷｏＴ）通信システム１０の略図である。概して、Ｍ２Ｍ技術は、ＩｏＴ／ＷｏＴのための構築ブロックを提供し、任意のＭ２Ｍデバイス、Ｍ２Ｍゲートウェイ、またはＭ２Ｍサービスプラットフォームは、ＩｏＴ／ＷｏＴのコンポーネントならびにＩｏＴ／ＷｏＴサービス層等であり得る。図４−６、８−１１および１３−１４のうちのいずれかに図示されるクライアント、プロキシ、もしくはサーバデバイスのうちのいずれかは、図１５Ａ−Ｄに図示されるもの等の通信システムのノードを備え得る。

図１５Ａに示されるように、Ｍ２Ｍ／ＩｏＴ／ＷｏＴ通信システム１０は、通信ネットワーク１２を含む。通信ネットワーク１２は、固定ネットワーク（例えば、Ｅｔｈｅｒｎｅｔ（登録商標）、Ｆｉｂｅｒ、ＩＳＤＮ、ＰＬＣ等）、または無線ネットワーク（例えば、ＷＬＡＮ、セルラー等）、もしくは異種ネットワークのネットワークであり得る。例えば、通信ネットワーク１２は、音声、データ、ビデオ、メッセージング、ブロードキャスト等のコンテンツを複数のユーザに提供する複数のアクセスネットワークから成り得る。例えば、通信ネットワーク１２は、符号分割多重アクセス（ＣＤＭＡ）、時分割多重アクセス（ＴＤＭＡ）、周波数分割多重アクセス（ＦＤＭＡ）、直交ＦＤＭＡ（ＯＦＤＭＡ）、単一キャリアＦＤＭＡ（ＳＣ−ＦＤＭＡ）等の１つ以上のチャネルアクセス方法を採用し得る。さらに、通信ネットワーク１２は、例えば、コアネットワーク、インターネット、センサネットワーク、工業制御ネットワーク、パーソナルエリアネットワーク、融合個人ネットワーク、衛星ネットワーク、ホームネットワーク、または企業ネットワーク等の他のネットワークを備え得る。

図１５Ａに示されるように、Ｍ２Ｍ／ＩｏＴ／ＷｏＴ通信システム１０は、インフラストラクチャドメインと、フィールドドメインとを含み得る。インフラストラクチャドメインは、エンドツーエンドＭ２Ｍ展開のネットワーク側を指し、フィールドドメインは、通常はＭ２Ｍゲートウェイの背後にあるエリアネットワークを指す。フィールドドメインおよびインフラストラクチャドメインは両方とも、ネットワークの種々の異なるノード（例えば、サーバ、ゲートウェイ、デバイス）を備え得る。例えば、フィールドドメインは、Ｍ２Ｍゲートウェイ１４と、端末デバイス１８とを含み得る。任意の数のＭ２Ｍゲートウェイデバイス１４およびＭ２Ｍ端末デバイス１８が、所望に応じてＭ２Ｍ／ＩｏＴ／ＷｏＴ通信システム１０に含まれ得ることが理解されるであろう。Ｍ２Ｍゲートウェイデバイス１４およびＭ２Ｍ端末デバイス１８の各々は、通信ネットワーク１２または直接無線リンクを介して、信号を伝送および受信するように構成される。Ｍ２Ｍゲートウェイデバイス１４は、無線Ｍ２Ｍデバイス（例えば、セルラーおよび非セルラー）ならびに固定ネットワークＭ２Ｍデバイス（例えば、ＰＬＣ）が、通信ネットワーク１２等のオペレータネットワークを通して、または直接無線リンクを通してのいずれかで、通信することを可能にする。例えば、Ｍ２Ｍデバイス１８は、データを収集し、通信ネットワーク１２または直接無線リンクを介して、データをＭ２Ｍアプリケーション２０もしくはＭ２Ｍデバイス１８に送信し得る。Ｍ２Ｍデバイス１８はまた、Ｍ２Ｍアプリケーション２０またはＭ２Ｍデバイス１８からデータを受信し得る。さらに、データおよび信号は、以下で説明されるように、Ｍ２Ｍサービスプラットフォーム２２を介して、Ｍ２Ｍアプリケーション２０に送信され、そこから受信され得る。Ｍ２Ｍデバイス１８およびゲートウェイ１４は、例えば、セルラー、ＷＬＡＮ、ＷＰＡＮ（例えば、Ｚｉｇｂｅｅ（登録商標）、６ＬｏＷＰＡＮ、Ｂｌｕｅｔｏｏｔｈ（登録商標））、直接無線リンク、および有線を含む、種々のネットワークを介して通信し得る。例示的Ｍ２Ｍデバイスは、タブレット、スマートフォン、医療デバイス、温度および気象モニタ、コネクテッドカー、スマートメータ、ゲームコンソール、携帯情報端末、健康および福祉モニタ、ライト、サーモスタット、電化製品、ガレージドア、および他のアクチュエータベースのデバイス、セキュリティデバイス、ならびにスマートコンセントを含むが、それらに限定されない。

用語「サービス層」は、ネットワークサービスアーキテクチャ内の機能層を指す。サービス層は、典型的には、ＨＴＴＰ、ＣｏＡＰ、またはＭＱＴＴ等のアプリケーションプロトコル層の上方に位置し、付加価値サービスをクライアントアプリケーションに提供する。サービス層はまた、インターフェースを、例えば、制御層およびトランスポート／アクセス層等の下位リソース層におけるコアネットワークに提供する。サービス層は、サービス定義、サービスランタイム有効化、ポリシ管理、アクセス制御、およびサービスクラスタリングを含む、（サービス）能力または機能性の複数のカテゴリをサポートする。最近、いくつかの産業規格団体、例えば、ｏｎｅＭ２Ｍが、インターネット／ウェブ、セルラー、企業、およびホームネットワーク等の展開へのＭ２Ｍタイプのデバイスならびにアプリケーションの統合に関連付けられた課題に対処するためのＭ２Ｍサービス層を開発している。Ｍ２Ｍサービス層は、アプリケーションおよび／または種々のデバイスに、ＣＳＥもしくはＳＣＬと称され得るサービス層によってサポートされる前述の能力または機能性の集合もしくは組へのアクセスを提供することができる。いくつかの実施例として、限定ではないが、種々のアプリケーションによって一般に使用され得る、セキュリティ、課金、データ管理、デバイス管理、発見、プロビジョニング、および接続性管理が挙げられる。これらの能力または機能性は、Ｍ２Ｍサービス層によって定義されたメッセージフォーマット、リソース構造、およびリソース表現を利用するＡＰＩを介して、そのような種々のアプリケーションに利用可能となる。ＣＳＥまたはＳＣＬは、それらにそのような能力もしくは機能性を使用するために、ハードウェアおよび／もしくはソフトウェアによって実装され得、種々のアプリケーションならびに／もしくはデバイスにエクスポーズされる（サービス）能力または機能性を提供する、機能エンティティ（例えば、そのような機能エンティティ間の機能インターフェース）である。

図１５Ｂを参照すると、フィールドドメイン内の図示されるＭ２Ｍサービス層２２は、Ｍ２Ｍアプリケーション２０、Ｍ２Ｍゲートウェイデバイス１４、およびＭ２Ｍ端末デバイス１８ならびに通信ネットワーク１２のためのサービスを提供する。Ｍ２Ｍサービス層２２は、所望に応じて、任意の数のＭ２Ｍアプリケーション、Ｍ２Ｍゲートウェイデバイス１４、Ｍ２Ｍ端末デバイス１８、および通信ネットワーク１２と通信し得ることが理解されるであろう。Ｍ２Ｍサービス層２２は、１つ以上のサーバ、コンピュータ等によって実装され得る。Ｍ２Ｍサービス層２２は、Ｍ２Ｍ端末デバイス１８、Ｍ２Ｍゲートウェイデバイス１４、およびＭ２Ｍアプリケーション２０に適用されるサービス能力を提供する。Ｍ２Ｍサービス層２２の機能は、例えば、ウェブサーバとして、セルラーコアネットワークで、クラウドで等の種々の方法で実装され得る。

図示されるＭ２Ｍサービス層２２と同様に、インフラストラクチャドメイン内にＭ２Ｍサービス層２２’がある。Ｍ２Ｍサービス層２２’は、インフラストラクチャドメイン内のＭ２Ｍアプリケーション２０’および下層通信ネットワーク１２’のためのサービスを提供する。Ｍ２Ｍサービス層２２’はまた、フィールドドメイン内のＭ２Ｍゲートウェイデバイス１４およびＭ２Ｍ端末デバイス１８のためのサービスも提供する。Ｍ２Ｍサービス層２２’は、任意の数のＭ２Ｍアプリケーション、Ｍ２Ｍゲートウェイデバイス、およびＭ２Ｍ端末デバイスと通信し得ることが理解されるであろう。Ｍ２Ｍサービス層２２’は、異なるサービスプロバイダによるサービス層と相互作用し得る。Ｍ２Ｍサービス層２２’は、１つ以上のサーバ、コンピュータ、仮想マシン（例えば、クラウド／計算／記憶ファーム等）等によって実装され得る。

依然として図１５Ｂを参照すると、Ｍ２Ｍサービス層２２および２２’は、多様なアプリケーションならびにバーティカルが活用することができるサービス配信能力のコアの組を提供する。これらのサービス能力は、Ｍ２Ｍアプリケーション２０および２０’がデバイスと相互作用し、データ収集、データ分析、デバイス管理、セキュリティ、課金、サービス／デバイス発見等の機能を果たすことを可能にする。本質的に、これらのサービス能力は、これらの機能性を実装する負担をアプリケーションから取り除き、したがって、アプリケーション開発を単純化し、市場に出す費用および時間を削減する。サービス層２２および２２’はまた、Ｍ２Ｍアプリケーション２０および２０’が、サービス層２２および２２’が提供するサービスと関連して、種々のネットワーク１２および１２’を通して通信することも可能にする。

Ｍ２Ｍアプリケーション２０および２０’は、限定ではないが、輸送、健康および福祉、コネクテッドホーム、エネルギー管理、資産追跡、ならびにセキュリティおよび監視等の種々の産業における用途を含み得る。前述のように、システムのデバイス、ゲートウェイ、および他のサーバにわたって稼働するＭ２Ｍサービス層は、例えば、データ収集、デバイス管理、セキュリティ、課金、場所追跡／ジオフェンシング、デバイス／サービス発見、およびレガシーシステム統合等の機能をサポートし、サービスとしてこれらの機能をＭ２Ｍアプリケーション２０および２０’に提供する。

概して、図１５Ａならびに１５Ｂに図示されるサービス層２２および２２’等のサービス層（ＳＬ）は、アプリケーションプログラミングインターフェース（ＡＰＩ）および下層ネットワーキングインターフェースの組を通して付加価値サービス能力をサポートするソフトウェアミドルウェア層を定義する。ＥＴＳＩ Ｍ２ＭおよびｏｎｅＭ２Ｍアーキテクチャは両方とも、サービス層を定義する。ＥＴＳＩ Ｍ２Ｍのサービス層は、サービス能力層（ＳＣＬ）と称される。ＳＣＬは、種々の異なるノードのＥＴＳＩ Ｍ２Ｍアーキテクチャで実装され得る。例えば、サービス層のインスタンス化は、Ｍ２Ｍデバイス（デバイスＳＣＬ（ＤＳＣＬ）と称される）、ゲートウェイ（ゲートウェイＳＣＬ（ＧＳＣＬ）と称される）、および／またはネットワークノード（ネットワークＳＣＬ（ＮＳＣＬ）と称される）内で実装され得る。ｏｎｅＭ２Ｍサービス層は、共通サービス機能（ＣＳＦ）（すなわち、サービス能力）の組をサポートする。１つ以上の特定のタイプのＣＳＦの組のインスタンス化は、異なるタイプのネットワークノード（例えば、インフラストラクチャノード、中間ノード、アプリケーション特定のノード）上でホストされ得る、共通サービスエンティティ（ＣＳＥ）と称される。第３世代パートナーシッププロジェクト（３ＧＰＰ）はまた、マシンタイプ通信（ＭＴＣ）のためのアーキテクチャも定義している。そのアーキテクチャでは、サービス層およびそれが提供するサービス能力は、サービス能力サーバ（ＳＣＳ）の一部として実装される。ＥＴＳＩ Ｍ２ＭアーキテクチャのＤＳＣＬ、ＧＳＣＬ、もしくはＮＳＣＬで、３ＧＰＰ ＭＴＣアーキテクチャのサービス能力サーバ（ＳＣＳ）で、ｏｎｅＭ２ＭアーキテクチャのＣＳＦもしくはＣＳＥで、またはネットワークのある他のノードで具現化されるかどうかにかかわらず、サービス層のインスタンスが、サーバ、コンピュータ、および他のコンピューティングデバイスもしくはノードを含む、ネットワーク内の１つ以上の独立型ノード上で、または１つ以上の既存のノードの一部としてのいずれかで実行する論理エンティティ（例えば、ソフトウェア、コンピュータ実行可能命令等）で実装され得る。実施例として、サービス層またはそのコンポーネント（例えば、ＡＳ／ＳＣＳ１００）のインスタンスが、以下で説明される図１５Ｃまたは１５Ｄに図示される一般的アーキテクチャを有する、ネットワークノード（例えば、サーバ、コンピュータ、ゲートウェイ、デバイス等）上で起動するソフトウェアの形態で実装され得る。

さらに、本明細書に説明される方法および機能性は、例えば、上のネットワークおよびアプリケーション管理サービス等のサービスにアクセスするために、サービス指向アーキテクチャ（ＳＯＡ）および／またはリソース指向アーキテクチャ（ＲＯＡ）を使用するＭ２Ｍネットワークの一部として実装され得る。

図１５Ｃは、図１５Ａおよび１５Ｂに図示されるもの等のＭ２Ｍネットワーク内のＭ２Ｍサーバ、ゲートウェイ、デバイス、または他のノードとして動作し得る、図４−６、８−１１、および１３−１４に図示されるクライアント、サーバ、またはプロキシのうちの１つ等のネットワークのノードの例示的ハードウェア／ソフトウェアアーキテクチャのブロック図である。図１５Ｃに示されるように、ノード３０は、プロセッサ３２と、送受信機３４と、伝送／受信要素３６と、スピーカ／マイクロホン３８と、キーパッド４０と、ディスプレイ／タッチパッド４２と、非取り外し可能メモリ４４と、取り外し可能メモリ４６と、電源４８と、全地球測位システム（ＧＰＳ）チップセット５０と、他の周辺機器５２とを含み得る。ノード３０はまた、送受信機３４および伝送／受信要素３６等の通信回路を含み得る。ノード３０は、実施形態と一致したままで、先述の要素の任意の副次的組み合わせを含み得ることが理解されるであろう。このノードは、本明細書に説明されるスモールデータ機能性を実装するノードであり得る。

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

図１５Ｃに示されるように、プロセッサ３２は、その通信回路（例えば、送受信機３４および伝送／受信要素３６）に結合される。プロセッサ３２は、コンピュータ実行可能命令の実行を通して、それが接続されるネットワークを介してノード３０を他のノードと通信させるために、通信回路を制御し得る。具体的には、プロセッサ３２は、（例えば、図５−１６、１８−２２、および２４で）本明細書ならびに請求項に説明される、伝送および受信するステップを行うために、通信回路を制御し得る。図１５Ｃは、プロセッサ３２および送受信機３４を別個のコンポーネントとして描写するが、プロセッサ３２および送受信機３４は、電子パッケージまたはチップに一緒に統合され得ることが理解されるであろう。

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

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

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

プロセッサ３２は、非取り外し可能メモリ４４および／または取り外し可能メモリ４６等の任意のタイプの好適なメモリから情報にアクセスし、そこにデータを記憶し得る。非取り外し可能メモリ４４は、ランダムアクセスメモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、ハードディスク、または任意の他のタイプのメモリ記憶デバイスを含み得る。取り外し可能メモリ４６は、加入者識別モジュール（ＳＩＭ）カード、メモリスティック、セキュアデジタル（ＳＤ）メモリカード等を含み得る。他の実施形態では、プロセッサ３２は、サーバまたはホームコンピュータ上等のノード３０上に物理的に位置しないメモリから情報にアクセスし、そこにデータを記憶し得る。プロセッサ３２は、ＵＥ（例えば、ＧＵＩ１４００参照）、具体的には、ＵＥと通信する下層ネットワーク、アプリケーション、または他のサービスのステータスを反映するために、ディスプレイもしくはインジケータ４２上の照明パターン、画像、または色を制御するように構成され得る。プロセッサ３２は、電源４８から電力を受け取り得、ノード３０内の他のコンポーネントへの電力を分配および／または制御するように構成され得る。電源４８は、ノード３０に給電するための任意の好適なデバイスであり得る。例えば、電源４８は、１つ以上の乾電池バッテリ（例えば、ニッケルカドミウム（ＮｉＣｄ）、ニッケル亜鉛（ＮｉＺｎ）、ニッケル水素（ＮｉＭＨ）、リチウムイオン（Ｌｉ−ｉｏｎ）等）、太陽電池、燃料電池等を含み得る。

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

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

図１５Ｄは、図１５Ａおよび１５Ｂに図示されるもの等のＭ２Ｍネットワーク内のＭ２Ｍサーバ、ゲートウェイ、デバイス、または他のノードとして動作し得る、図４−６、８−１１、および１３−１４に図示されるクライアント、サーバ、もしくはプロキシ等のネットワークの１つ以上のノードを実装するためにも使用され得る例示的コンピューティングシステム９０のブロック図である。コンピューティングシステム９０は、コンピュータまたはサーバを備え得、主に、そのようなソフトウェアが記憶またはアクセスされる場所もしくは手段にかかわらず、ソフトウェアの形態であり得るコンピュータ読み取り可能な命令によって制御され得る。そのようなコンピュータ読み取り可能な命令は、コンピューティングシステム９０を起動させるように、中央処理装置（ＣＰＵ）９１内で実行され得る。多くの既知のワークステーション、サーバ、およびパーソナルコンピュータでは、中央処理装置９１は、マイクロプロセッサと呼ばれる単一チップＣＰＵによって実装される。他のマシンでは、中央処理装置９１は、複数のプロセッサを備え得る。コプロセッサ８１は、追加の機能を果たす、またはＣＰＵ９１を支援する、主要ＣＰＵ９１とは異なる、随意のプロセッサである。ＣＰＵ９１および／またはコプロセッサ８１は、セッション証明書を受信すること、またはセッション証明書に基づいて認証すること等のＥ２Ｅ Ｍ２Ｍサービス層セッションのための開示されるシステムおよび方法に関連するデータを受信、生成、ならびに処理し得る。

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

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

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

ディスプレイコントローラ９６によって制御されるディスプレイ８６は、コンピューティングシステム９０によって生成される視覚出力を表示するために使用される。そのような視覚出力は、テキスト、グラフィックス、動画グラフィックス、およびビデオを含み得る。ディスプレイ８６は、ＣＲＴベースのビデオディスプレイ、ＬＣＤベースのフラットパネルディスプレイ、ガスプラズマベースのフラットパネルディスプレイ、またはタッチパネルを伴って実装され得る。ディスプレイコントローラ９６は、ディスプレイ８６に送信されるビデオ信号を生成するために要求される、電子コンポーネントを含む。

さらに、コンピューティングシステム９０は、コンピューティングシステム９０がネットワークの他のノードと通信することを可能にするように、図１５Ａおよび図１５Ｂのネットワーク１２等の外部通信ネットワークにコンピューティングシステム９０を接続するために使用され得る、例えば、ネットワークアダプタ９７等の通信回路を含み得る。通信回路は、単独で、またはＣＰＵ９１と組み合わせて、（例えば、図４−６、８−１１、および１３−１４で）本明細書ならびに請求項に説明される、伝送および受信するステップを行うために使用され得る。

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

図で図示されるような本開示の主題の好ましい実施形態を説明することにおいて、具体的用語が、明確にするために採用される。しかしながら、請求される主題は、そのように選択された具体的用語に限定されることを意図せず、各具体的要素は、類似目的を達成するように同様に動作する、全ての技術的均等物を含むことを理解されたい。

以下は、上の説明の中で出現し得る、サービスレベル技術に関する頭字語のリストである。別様に規定されない限り、本明細書で使用される頭字語は、以下に列挙される対応する用語を指す。
ＡＡＡ ＡＡ−回答
ＡＡＲ ＡＡ−要求
ＡＦ アプリケーション機能
ＡＰＮ アクセスポイント名
ＡＳ アプリケーションサーバ
ＡＳＰ アプリケーションサービスプロバイダ
ＡＶＰ 属性値対
ＢＢＥＲＦ ベアラ結合およびイベント報告機能
ＣＮ コアネットワーク
ＤＲＢ データ無線ベアラ
ＥＭＭ ＥＰＳモビリティ管理
ｅＮＢ 進化型ノードＢ
ＥＰＳ 進化型パケットシステム
ＥＳＭ ＥＰＳセッション管理
ＧＰＲＳ 汎用パケット無線サービス
ＧＴＰ ＧＰＲＳトンネリングプロトコル
ＧＴＰ−Ｃ ＧＴＰ制御
ＧＴＰ−Ｕ ＧＴＰユーザ
ＨＳＳ ホーム加入者サーバ
ＭＭＥ モビリティ管理エンティティ
ＭＯ 管理オブジェクト
ＭＴ モバイル終了
ＭＴＣ マシンタイプ通信
ＭＴＣ−ＩＷＦ マシンタイプ通信−インターワーキング機能
ＮＡＳ 非アクセス層
ＰＣＣ ポリシおよび課金制御
ＰＣＥＦ ポリシおよび課金実施機能
ＰＣＲＦ ポリシおよび課金ルール機能
ＰＤＮ パケットデータネットワーク
Ｐ−ＧＷ ＰＤＮゲートウェイ
ＲＡＡ 再承認回答（ＲＡ−Ａｎｓｗｅｒ）
ＲＡＲ 再承認要求（ＲＡＲ）
ＳＣＥＦ サービス能力エクスポージャ機能
ＳＣＳ サービス能力サーバ
ＳＤ スモールデータ
ＳＤＤＴＥ スモールデータおよびデバイストリガ拡張
Ｓ−ＧＷ サービングゲートウェイ
ＳＰＲ サブスクリプションプロファイルレポジトリ
ＳＲＢ 信号伝達無線ベアラ
ＴＡ 端末適応
ＴＡＵ 追跡エリア更新
ＴＤＦ トラフィック検出機能
ＴＥ 端末機器
ＴＦＴ トラフィックフローテンプレート
ＵＤＲ ユーザデータレポジトリ
ＵＥ ユーザ機器
ＵＩＣＣ ユニバーサル集積回路カード

本明細書は、最良の様態を含む、本発明を開示するために、また、当業者が、任意のデバイスまたはシステムを作製して使用すること、および任意の組み込まれた方法を行うことを含む、本発明を実践することを可能にするために、実施例を使用する。本発明の特許性のある範囲は、請求項によって定義され、当業者に想起される他の実施例を含み得る。そのような他の実施例は、請求項の文字通りの用語と異ならない構造要素を有する場合に、または請求項の文字通りの用語からごくわずかな差異を伴う同等の構造要素を含む場合に、請求項の範囲内であることを意図している。

Claims (20)

1. プロセッサと、メモリと、通信回路とを備えている装置であって、前記装置は、その通信回路を介して通信ネットワークに接続され、前記装置は、前記装置の前記メモリ内に記憶されているコンピュータ実行可能命令をさらに備え、前記命令は、前記装置の前記プロセッサによって実行されると、
   第１のメッセージをユーザ機器（ＵＥ）から受信することと、
   第２のメッセージをネットワークノードから受信することであって、前記第２のメッセージは、スモールデータプロシージャを使用すべき１つ以上のパケットデータネットワーク（ＰＤＮ）接続を示し、前記第２のメッセージは、前記１つ以上のＰＤＮ接続の各々に対応するスモールデータプロシージャのタイプをさらに示す、ことと、
   前記第２のメッセージに基づいて、前記第１のメッセージに応答することと
   を含む動作を前記装置に行わせる、装置。
2. 前記第１のメッセージは、前記ＵＥがスモールデータプロシージャをサポートすることの指示を含むアタッチ要求メッセージを備えている、請求項１に記載の装置。
3. 前記第１のメッセージは、前記ＵＥがスモールデータプロシージャを使用することの要求を含むアタッチ要求メッセージを備えている、請求項１に記載の装置。
4. 前記第１のメッセージに対する前記応答は、アタッチ応答メッセージを備え、前記アタッチ応答メッセージは、前記ＵＥが前記第２のメッセージに示されている前記スモールデータプロシージャのうちの１つを使用するスモールデータモードで機能すべきことの指示を含む、請求項１から３のいずれか１項に記載の装置。
5. 前記装置は、コンピュータ実行可能命令をさらに備え、前記命令は、前記装置のプロセッサによって実行されると、
   前記第２のメッセージに示されている前記スモールデータプロシージャのうちの１つを使用して、データを前記ＵＥに配信することを含むさらなる動作を前記装置に行わせる、請求項１から４のいずれか１項に記載の装置。
6. 前記装置は、コンピュータ実行可能命令をさらに備え、前記命令は、前記装置のプロセッサによって実行されると、
   前記第２のメッセージに示されている前記スモールデータプロシージャのうちの１つに従って、データを前記ＵＥから受信することを含むさらなる動作を前記装置に行わせる、請求項１から５のいずれか１項に記載の装置。
7. 前記スモールデータプロシージャは、非アクセス層（ＮＡＳ）メッセージングを介して示される、請求項４から６のいずれか１項に記載の装置。
8. ユーザ機器と、ネットワークノードとを備えている通信ネットワークに接続されている装置によって行われる方法であって、前記方法は、
   第１のメッセージを前記ＵＥから受信することと、
   第２のメッセージを前記ネットワークノードから受信することであって、前記第２のメッセージは、スモールデータプロシージャを使用すべき１つ以上のパケットデータネットワーク（ＰＤＮ）接続を示し、前記第２のメッセージは、前記１つ以上のＰＤＮ接続の各々に対応するスモールデータプロシージャのタイプをさらに示す、ことと
   前記第２のメッセージに基づいて、前記第１のメッセージに応答することと
   を含む、方法。
9. 前記第１のメッセージは、前記ＵＥがスモールデータプロシージャをサポートすることの指示を含むアタッチ要求メッセージを備えている、請求項８に記載の方法。
10. 前記第１のメッセージは、前記ＵＥがスモールデータプロシージャを使用することの要求を含むアタッチ要求メッセージを備えている、請求項８に記載の方法。
11. 前記第１のメッセージに対する前記応答は、アタッチ応答メッセージを備え、前記アタッチ応答メッセージは、前記ＵＥが前記第２のメッセージに示されている前記スモールデータプロシージャのうちの１つを使用するスモールデータモードで機能すべきことの指示を含む、請求項８から１０のいずれか１項に記載の方法。
12. 前記方法は、前記第２のメッセージに示されている前記スモールデータプロシージャのうちの１つを使用して、データを前記ＵＥに配信することをさらに含む、請求項８から１１のいずれか１項に記載の方法。
13. 前記方法は、前記第２のメッセージに示されている前記スモールデータプロシージャのうちの１つに従って、データを前記ＵＥから受信することをさらに含む、請求項８から１２のいずれか１項に記載の方法。
14. 前記示されているスモールデータプロシージャは、非アクセス層（ＮＡＳ）メッセージングを介して示される、請求項１１から１３のいずれか１項に記載の方法。
15. 前記装置は、モバイル管理エンティティを備えている、請求項８から１４のいずれか１項に記載の方法。
16. 前記ネットワークノードは、ホーム加入者サーバを備えている、請求項８から１５のいずれか１項に記載の方法。
17. 前記第２のメッセージは、加入者データ挿入メッセージまたは場所更新要求メッセージを備えている、請求項８から１５のいずれか１項に記載の方法。
18. ユーザ機器と、モバイル管理エンティティ（ＭＭＥ）と、ホーム加入者サーバ（ＨＳＳ）とを備えているシステムにおける方法であって、前記方法は、
    前記ＵＥによって、アタッチ要求メッセージを前記ＭＭＥに送信することと、
    前記アタッチ要求メッセージに基づいて、前記ＭＭＥが、前記ＨＳＳから、前記ＵＥが前記ＭＭＥとＵＥとの間でスモールデータプレーンを使用すべきかどうかを示す情報を読み出すことと、
    前記読み出された情報に基づいて、前記ＭＭＥが、前記ＵＥに、前記ＵＥが前記スモールデータプレーンを使用すべきことを示すアタッチ受諾メッセージを送信することと
    を含む、方法。
19. 前記方法は、前記ＵＥによって、前記アタッチ受諾メッセージに従って、前記スモールデータプレーンを経由してデータを前記ＭＭＥに送信することをさらに含む、請求項１８に記載の方法。
20. 前記方法は、前記ＭＭＥによって、前記アタッチ受諾メッセージに従って、前記スモールデータプレーンを経由してデータを前記ＵＥに送信することをさらに含む、請求項１８および１９のいずれか１項に記載の方法。