JP2023052823A - ３ｇｐｐネットワークにおけるスモールデータ使用有効化 - 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. 前記方法は、前記ＭＭＥによって、前記アタッチ受諾メッセージに従って、前記スモー
    ルデータプレーンを経由してデータを前記ＵＥに送信することをさらに含む、請求項１８
    および１９のいずれか１項に記載の方法。

Images