JP7123036B2 - Ｕｅのアウェイク状態の維持 - Google Patents

Description

（関連出願の相互参照）
本出願は、２０１６年８月１６日に出願された米国仮特許出願第６２／３７５，６９５号に対する利点を主張し、その開示内容は全体が参照することにより本明細書に援用される。

３ＧＰＰでは、電力を維持するために、ユーザ装置（User Equipment：ＵＥ）が長期間スリープ状態でいることを可能にする、いくつかの機能がサポートされている。省電力モード（Power Savings Mode：ＰＳＭ）と拡張アイドルモードＤＲＸ（Extended Idle Mode DRX：ｅＤＲＸ）とは、ＵＥを比較的長期間スリープ状態にさせる機能である。「スリープ」状態にいる間は、ＵＥは通常ネットワークからのページをリスンしないので、モバイル着信（Mobile Terminated：ＭＴ）通信に接続されない。拡張Ｓ－ＧＷバッファリングは、長いスリープ期間中のＵＥを対象としたＭＴデータを、そのＵＥがネットワークにリスンするまで、Ｓ－ＧＷにバッファすることができる機能である。接続可能性通知は、ＵＥがＭＴ通信に可用になる時を、サービス機能サーバまたはアプリケーションサーバ（Service Capability Server or Application Server：ＳＣＳ／ＡＳ）に知らせる機能である。

省電力モード（ＰＳＭ）は、３ＧＰＰ Ｒｅｌｅａｓｅ １２で提示されたＵＥ状態である。このＰＳＭ機能は、３ＧＰＰ ＴＳ ２３．６８２（「パケットデータネットワークとアプリケーションとの通信を容易にするアーキテクチャ機能向上」）と、３ＧＰＰ ＴＳ ２３．４０１（「進化型ユニバーサル地上波無線アクセスネットワーク（Evolved Universal Terrestrial Radio Access Network：Ｅ－ＵＴＲＡＮ）アクセスのための汎用パケット無線サービス（General Packet Radio Service：ＧＰＲＳ）の機能向上」）の４．３．２２節および４．３．５．２節に規定されている。

省電力モード（ＰＳＭ）機能の目的は、ＵＥにおける電力消費の低減である。ＰＳＭモード下のＵＥは電源オフに類似しているが、ＵＥはネットワークに登録されたままになっており、ＰＤＮ接続を再アタッチまたは再確立する必要はない。ＰＳＭ機能は「アクティブタイム」と呼ばれる新しいタイマを導入したものであり、このタイマによりＵＥがＰＳＭ状態になる前に接続可能な状態でいる時間が示される。ＵＥはアイドルモードに移るとアクティブタイムをスタートし、アクティブタイムの間はすべてのモバイル着信要求に対して可用になる。アクティブタイマが満了すると、ＵＥは自身のアクセス層機能を無効にし、ＰＳＭに入る。ＰＳＭでは、アクセス層機能が無効にされているので、ＵＥはアイドルモード手順を中止するが、適用可能なすべてのＮＡＳタイマ（例えば、周期的ＴＡＵタイマ）の実行を続ける。

一般に、ＵＥがＰＳＭをサポートする場合、ＵＥはアタッチまたはＴＡＵ／ＲＡＵ手順の間にアクティブタイム値を提示することによってＵＥがＰＳＭの使用を必要としていることをＣＮに通知する。ネットワークがＰＳＭをサポートしていて、かつＵＥにＰＳＭを使用させたい場合は、アクティブタイム値をＵＥに割り当てることによってＰＳＭの使用を確認する。ネットワークは、ＵＥのリクエスト値と、ネットワーク構成と、ネットワークポリシとを考慮してこのアクティブタイムを決定する。場合により、ＵＥがアクティブタイム値を修正したい場合、ＵＥは次周期のＴＡＵ／ＲＡＵ手順で所望の値をリクエストする。モバイル発信イベント（例えば、周期的ＲＡＵ／ＴＡＵ、モバイル発信データ、またはデタッチ）が、ネットワークに対する任意の手順を開始するようにＵＥに要求するまで、ＵＥはＰＳＭモードの状態でいる。

通常、ＰＳＭは低頻度のモバイル発信および着信サービスを待ち受けしているＵＥと、モバイル着信通信における通信遅延を受け入れ可能なＵＥとに対して用いられることを意図している。このことは、いずれのアプリケーションにおいても、ＰＳＭを使用したい場合は、起こり得るモバイル着信サービスやデータ配信に備える上で十分長いアクティブタイムをリクエストする必要がある、ことを意味する。

次に拡張間欠受信（Discontinuous Reception：ＤＲＸ）について考える。拡張アイドルモードＤＲＸ（拡張ＤＲＸ、ｅＤＲＸ）を用いているＵＥの場合、ページングオケージョン（Paging Occasion：ＰＯ）の時間間隔が長くなる。ページングオケージョン毎に、ＵＥはネットワークにページをリスンする。ページによって、ＵＥに送信されるデータがネットワークにあるため、ＵＥのＲＲＣ接続を有効にしてＵＥがデータ受信できるようにする必要があることがＵＥに示される。ＵＥがページングされないと、ＵＥはページングオケージョンの間にスリープ状態（電力消費が低下した状態）になる。場合により、ｅＤＲＸページングオケージョンの間の時間は４５分程であるように設定される。

ＵＥは、アタッチまたはトラッキングエリアアップデート（Tracking Area Update：ＴＡＵ）手順の間にｅＤＲＸの使用をリクエストする。ＵＥはアタッチまたはＴＡＵリクエストを用いて特定のｅＤＲＸパラメータの使用をリクエストする。ネットワークは、ＵＥのｅＤＲＸパラメータを受け入れること、ＵＥによるｅＤＲＸの使用のリクエストを拒絶すること、または異なるｅＤＲＸパラメータを提供しながらＵＥによるｅＤＲＸの使用のリクエストを受け入れることのいずれかで応答する。

場合により、ＵＥが例えばＰＳＭまたはｅＤＲＸなどのスリープモードを用いている時に、Ｓ－ＧＷがＭＴデータの拡張バッファリングをサポートする。Ｓ－ＧＷは、ＵＥが（ＴＡＵを実行することによって）ＰＳＭから出るまで、またはＵＥの次のページングオケージョンまで、ＭＴデータをバッファする。ＳＣＥＦはＳＣＳ／ＡＳに複数のＡＰＩを提供する。これらのＡＰＩは、ＳＣＳ／ＡＳに、Ｓ－ＧＷがＵＥ用に拡張バッファリングを使用するように、設定させる。例えば、これらＡＰＩは、どれだけ多くのＭＴパケットがバッファされるか、およびそれらのパケットが廃棄前にどれだけ長くバッファ内に留まる必要があるかを、ＳＣＳ／ＡＳに設定させる。あるいは、例えば、ＵＥによる拡張Ｓ－ＧＷバッファリングの使用がネットワークオペレータによってＵＥの加入情報に設定される。現在のところ、ＳＣＳ／ＡＳがＵＥにパケットを送信してそのパケットがＳ－ＧＷバッファに保存された場合、ＳＣＳ／ＡＳはパケットが該バッファ内にあるとの肯定応答（確認応答）をＭＣＮから受信しない。

ここで接続可能性通知について考える。ＳＣＥＦは、ＳＣＳ／ＡＳにＡＰＩを開示して、ＵＥが接続可能になる時、またはまもなく接続可能になる時を知らせるように、ＳＣＳ／ＡＳがリクエストすることを可能にする。例えば、ＭＣＮは、ＵＥがアタッチする時、ＵＥがＴＡＵの実行によりＰＳＭから抜け出す時、またはＵＥのページングオケージョンが近づいている時をＳＣＳ／ＡＳに通知する。ＳＣＳ／ＡＳは、接続可能性通知を用いてＵＥとの通信をコーディネートする場合にはＰＳＭの使用を避ける。接続可能性通知についてはＴＳ ２３．６８２により詳しい記述がある。

ＳＣＥＦがＡＰＩをＳＣＳ／ＡＳに開示することにより、バックグラウンドデータ転送について、ＳＣＳ／ＡＳがＭＣＮとのスケジューリングとネゴシエーションとを行うことが可能になる。このＡＰＩにより、ＳＣＳ／ＡＳは、転送時のＵＥの数と、送信されるデータの規模と、ＵＥの地理的位置とを通知することが可能になる。ＭＣＮは、データ転送が行われる時をＳＣＳ／ＡＳに教える。バックグラウンドデータ転送についてはＴＳ ２３．６８２と３ＧＰＰ ＴＳ ２３．２０３（「ネットワークポリシおよび課金制御アーキテクチャ」）により詳しい記述がある。

ここでトランスポートレイヤとアプリケーションレイヤとのプロトコルにおける再送についての現行の手法について考える。あるトランスポートレイヤプロトコルでは、一部のパケットが肯定応答されることが要求される。例えば、伝送制御プロトコル（Transmission Control Protocol：ＴＣＰ）は、パケットの受信者が肯定応答を送信することを要求するプロトコルである。送信者がタイムアウト期間（例えば、１秒）内に肯定応答を受信しない場合は、送信者はパケットを再送する。送信者がタイムアウトの枠を広げて肯定応答を受信するまでパケット送信を試み続けることもある。ＴＣＰは、重複したパケットを廃棄できるように受信者に重複受信したパケットを識別させる。場合により、送信者は、他のパケットの送信前に肯定応答されるパケットを待つ必要はなく、複数のパケットが同時に送信されていることもある。

ＣｏＡＰは、一部のパケットを肯定応答しなければならないように構成されているアプリケーションレイヤプロトコルの一例である。ＴＣＰと同様に、ＣｏＡＰはタイムアウト期間を有するように構成されており、タイムアウト期間が終了すると肯定応答されなかったパケットが再送される。ＣｏＡＰプロトコルもまた、重複したパケットを廃棄できるように受信者に重複受信したパケットを識別させる。場合により、送信者は、他のパケットの送信前に肯定応答されるパケットを待つ必要はなく、複数のパケットが同時に送信されていることもある。

図１に、ネットワーク機能仮想化（Network Functions Virtualization：ＮＦＶ）の全体像の一例を示す。概略、ＮＦＶは、ネットワークオペレータによるネットワーク構成法を変形することを目的としたものである。特に、ＩＴ仮想化技術は、多くのネットワーク装置の種類を業界標準の高容量サーバ、スイッチ、ならびに記憶装置に統合するために用いられている。これら装置類は、データセンタ内と、ネットワークノード内と、エンドユーザ構内とに設置可能なものである。ネットワーク機能（例えば、モビリティ管理、セッション管理、ＱｏＳなど）はソフトウェアにより実現され、業界標準のサーバハードウェアとの関連で実行可能なものである。この機能は、新しい装置を設置することなく、必要に応じてネットワーク内の様々な位置に移動させることができる、または様々な位置でインスタンス化することができる。図１は、ＥＴＳＩから提示されたＮＦＶの構造的枠組の一例を示したものである。

ＮＦＶは、モバイルネットワークと固定ネットワークとにおける任意のデータプレーンパケット処理と制御プレーン機能に適用可能なことは明らかである。例えば、限定はしないが次の機能などがある。
スイッチング素子（例えば、ＢＮＧルータやＣＧ－ＮＡＴルータ）
モバイルネットワークノード（例えば、ＨＬＲ／ＨＳＳ、ＭＭＥ、ＳＧＳＮ、ＧＧＳＮ／ＰＤＮ－ＧＷ、ＲＮＣ、ｅＮｏｄｅＢ）
仮想家庭環境を作成するためにホームルータやセットトップボックスに含まれる機能
ネットワーク規模の集中型機能（例えば、ＡＡＡサーバ、ポリシ制御、課金プラットフォーム）
アプリケーションレベル最適化（例えば、ＣＤＮｓ、キャッシュサーバ、負荷分散装置、アプリケーションアクセレレータ）
セキュリティ機能（例えば、ファイアウォール、ウィルススキャナ、侵入検知システム、スパムプロテクション）

ＮＦＶの適用はネットワークオペレータに種々の便益をもたらし、それによって電話通信産業の状況に劇的な変化がもたらされると考えられる。例えば、限定するものではないが、ＮＦＶによって以下のメリットをもたらすと考えられる。
装置の統合とＩＴ産業における規模の経済の活用による装置価格と電力消費量との低減。
一般ネットワークオペレータのイノベーションサイクルの最小化による商品化速度の向上。
同一インフラストラクチャでの製造、検査、基準設備の実施の可能性による検査と集積化との効率向上、それによる開発コストの低減と商品化時間の短縮。
地勢や顧客群に基づく目標サービスの導入。必要に応じた迅速なサービス規模の拡大縮小。
様々なエコシステムの利用可能性（開放性の促進）。
実際のトラフィックまたはモビリティパターンとサービス需要に基づくほぼリアルタイムでの最適なネットワーク構成および／または形態。
マルチテナンシのサポート、それによるネットワークオペレータからのサービスとコネクティビティであって、管理領域が適切かつ確実に分離した同一ハードウェアに共存可能な、複数のユーザ、アプリケーション、内部システム、または他のネットワークオペレータに適合するサービスとコネクティビティとの提供。
標準のサーバと記憶装置とにおけるパワーマネジメント機能の活用、ならびにワークロードの統合と位置最適化とによるエネルギ消費量の低減。

図２に、ＶＮＦとネスト化転送グラフとによるエンドツーエンドのネットワークサービスの一例（ＥＴＳＩ ＧＳ ＮＦＶ ００２から）を示す。図２は、仮想化ネットワーク機能転送グラフ（ＶＮＦ－ＦＧ）の概念を示す図である。ＶＮＦ－ＧＷにより、如何にしてＶＮＦの一群が接続されてサービスを提供するかが説明される。

次世代モバイルネットワーク（Next Generation Mobile Network：ＮＧＭＮ）アライアンス「ネットワークスライシングの概念の解説」に記載されているような、ネットワークスライシングは、モバイルネットワークオペレータにより使用されて、モバイルオペレータのネットワーク（バックホールとコアネットワークとの両方）の固定部分にわたるエアインタフェースの背後の複数の仮想ネットワークをサポートすることができる手法である。このことは、ネットワークを複数の仮想ネットワークに「スライシング」して種々の異なるＲＡＮをサポートすること、または１つのＲＡＮで実行される種々のサービスタイプをサポートすることを含む。ネットワークスライシングにより、オペレータは、例えば、性能やアイソレーションといった機能面での多様な要件が要求される、種々の市場シナリオ毎に最適化されたソリューションを与えるようにカスタマイズされたネットワークを形成することができる。図３は、ネットワークスライシングのアーキテクチャの概念の１例を示す。自明であるが、図３では、種々の濃淡によって、種々のネットワークスライスインスタンスまたはサブネットワークスライスインスタンスを示している。

３ＧＰＰは、５Ｇネットワークをデザインすると共に、ネットワークスライシング技術を組み込むべきか否かを検討している。ネットワークスライシング技術は５Ｇネットワークによく適合し得る。これは、５Ｇユースケース（例えば、大規模ＩｏＴ、クリティカル通信、モバイルブロードバンドの高度化）はきわめて多様で時に極度の要件を要するためである。現行のアーキテクチャは、比較的モノリシックなネットワークとトランスポート フレームワークとを用いて、例えば、スマートフォンからのモバイルトラフィック、ＯＴＴコンテンツ、フィーチャーフォン、データカード、および埋め込みＭ２Ｍデバイスなどの、種々のサービスに適応している。現行のアーキテクチャは、広範囲のビジネスニーズのそれぞれが特有の、性能と、拡張性と、可用性との要件を有している場合、それらビジネスニーズを効率よくサポートするのに十分な適応性と拡張性とを有していないことが予想される。さらに、自明であるが、新しいネットワークサービスの導入はより効率的に行う必要がある。しかし、複数のユースケースが同一のオペレータネットワークで同時に有効になり、そのために高度の適応性と拡張性をもつ５Ｇネットワークが必要になることが予想される。

５Ｇネットワークにおける省電力モードについては、５Ｇネットワークは、例えば、ある種の省電力モード（またはＵＥ状態）をサポートしており、このモードにおいて、ＵＥは所定の機能をオフにして消費電力を低減し、かつモバイルコアネットワーク（Mobile Core Network：ＭＣＮ）にページをリスンしない。ＵＥが省電力モード（状態）にあってＭＣＮにページをリスンしない場合、ＵＥはモバイル着信（ＭＴ）通信に接続不能である。

ＰＳＭおよび／またはｅＤＲＸが使用される場合などの、ユーザ装置（ＵＥ）が長期間のスリープ状態にされた場合に、ＵＥは接続不能であるが、ネットワークまたはサードパーティサーバがモバイル着信イベントについてＵＥにコンタクトする必要がある状況が起こり得る。

前述の通り、モバイル着信デバイスがスリープ状態のとき、デバイスは必要時（例えば、デバイスがサードパーティサーバからのデータの受信者であるとき）に接続できない恐れがある。本明細書で述べる通り、サードパーティアプリケーションサーバは、特定のＵＥまたはＵＥグループに送信するデータを有していることをネットワークに通知する。

一例では、モバイルコアネットワーク（ＭＣＮ）はサードパーティサーバからの情報を用いて、必要な場合にＵＥがアウェイク状態であることを保証する。例えば、ＵＥが、データ転送が完了する前にスリープ状態になることを防ぐことができる。

一例として、サーバは、例えば、モバイル着信（ＭＴ）デバイスまたはＵＥに関連する接続状態を通知するメッセージを受信する。このメッセージとして、例えば、限定はしないが、間欠受信（ＤＲＸ）タイマまたは省電力モード（ＰＳＭ）タイマ、アクティブタイマ値、トラッキングエリアアップデート（ＴＡＵ）タイマ値、またはＤＲＸサイクル長がある。このメッセージに基づいて、サーバはプロトコルの再送時間を第１値に設定する。サーバは、データパケットを少なくとも１つのモバイル着信デバイスに送信し、上記プロトコルを用いて第１値に応じて所定回数データパケットを再送する。場合により、このプロトコルは伝送制御プロトコル（ＴＣＰ）または制約付きアプリケーションプロトコル（Constrained Application Protocol：ＣｏＡＰ）である。さらに、サーバは、モバイル着信デバイスからのデータの受信、またはネットワークからの通知の受信に応じてプロトコルの再送時間を第２値に変更する。その後、このプロトコルを用いて第２値に応じて所定回数データパケットを再送する。ネットワークからの通知は、タイマ値、可用性通知、またはコネクティビティ通知の消失を含む。場合により、サーバは、ネットワークからの第２通知の受信に応じて再送時間を第１値に戻す。一例では、第２通知は（ＵＥの）コネクティビティ通知の消失からなる。

一実施形態例における装置は、プロセッサと、メモリと、通信回路とを備える。この装置は自身の通信回路を介してネットワークに接続される。この装置はさらに、該装置のメモリに保存されたコンピュータ実行可能な命令を含み、この命令が装置のプロセッサにより実行されると、種々の動作を行う。例えば、この装置は、第１データ配信リクエストメッセージを受信する。このメッセージは、サードパーティサーバからのデータ転送時にデータの受信者となる、少なくとも１つのユーザ装置を示している。第１データ配信リクエストメッセージはさらに、サードパーティサーバの所望のデータ転送実行時を示している。第１データ配信リクエストメッセージに基づいて、装置は、少なくとも１つのＵＥがデータ転送に備えてアウェイク状態であることを保証するアクションを行う。一例では、この少なくとも１つのユーザ装置はユーザ装置グループからなり、上記アクションはグループ内の各ＵＥが同時にデータ転送に備えてアウェイク状態であることを保証する。

本要旨は、後に詳細な説明で述べる複数の概念の一部を選択して簡単に紹介したものである。本要旨は、本特許請求された内容の重要な特徴を特定するものではなく、また本要旨を用いて本特許請求された内容の範囲を限定するものでもない。さらに、本特許請求された内容は、本明細書のいずれかの箇所に記載された、いずれの課題を解決する上での制約にも限定されるものではない。

添付図面を参照して本出願のより容易かつ確実な理解を図る。各図において、同様の構成要素には同様の参照数字を付している。これら図面は本出願を限定するものではなく、あくまでも例として示したものである。
ネットワーク機能仮想化（Ｎｅｔｗｏｒｋ Ｆｕｎｃｔｉｏｎｓ Ｖｉｒｔｕａｌｉｚａｔｉｏｎ（ＮＦＶ））のアーキテクチャフレームワークの一例を示す図であり、このアーキテクチャフレームワークにおいて１つ以上の本開示の実施形態が具現される。 仮想化ネットワーク機能転送グラフ（Virtualized Network Function Forwarding Graph：ＶＮＦ－ＦＧ）の一例を示す図である。 ネットワークスライシングのアーキテクチャの一例を示す図であり、このアーキテクチャにおいて１つ以上の本開示の実施形態が具現される。 モバイルネットワークインフラストラクチャへのＢＭ－ＳＣ接続の一例を示す図である。 ＭＢＭＳマルチキャストサービス有効化のコールフローの一例を示す図である。 ＭＢＭＳを用いたグループメッセージ配信のコールフローの一例を示す図である。 ２つの通信パターンの例を示す図である。 一実施形態例による、サードパーティ開始データ配信のコールフローを示す図である。 一実施形態例による、アップデートバックグラウンドデータ転送のコールフローを示す図である。 ＷｉＦｉネットワークの一例におけるＳＣＥＦの一例を示す図である。 一実施形態例による、グラフィカルユーザインタフェースの一例を示す図である。 一実施形態例による、グラフィカルユーザインタフェースの一例を示す図である。 マシンツーマシン（Ｍ２Ｍ）またはモノのインターネット（ＩｏＴ）通信システムの一例となるシステム図であり、この通信システムにおいて１つ以上の本開示の実施形態が具現される。 図１８Ａに示したＭ２ＭまたはＩｏＴ通信システム内で使用されるアーキテクチャの一例のシステム図である。 図１８Ａに示した通信システム内で使用されるＭ２ＭまたはＩｏＴ端末もしくはゲートウェイデバイスの一例のシステム図である。 図１８Ａの通信システムの態様が埋め込まれた通信システムの一例のブロック図である。

前述の通り、省電力モード（ＰＳＭ）および／または拡張アイドルモード間欠受信（ｅＤＲＸ）が使用された場合等の、ＵＥが長期間のスリープ状態にされた場合に、ネットワークまたはサードパーティサーバがモバイル着信イベントについてＵＥにコンタクトする必要がある場合にＵＥが接続不能である状況が起こり得る。

サードパーティサーバがＰＳＭ状態にいるＵＥにデータを送信すると、モバイルコアネットワークは、ＵＥの次のページングオケージョンまでデータをドロップまたはバッファすることになる。このため、ＰＳＭを用いたＵＥとの通信に用いる、アプリケーションレイヤと、トランスポートレイヤと、サービスレイヤとの各プロトコルは、ＵＥが長期のスリープ状態にいると共に、ＵＥに送信されたデータをバッファするようにＭＣＮが構成されていると考える。さらに、サードパーティサーバがＵＥのページングオケージョンよりずっと前にＵＥにデータを送信した場合は、モバイルコアネットワーククはＵＥの次のページングオケージョンまでデータをドロップまたはバッファする。ｅＤＲＸを用いたＵＥとの通信に用いる、アプリケーションレイヤと、トランスポートレイヤと、サービスレイヤとの各プロトコルは、ＵＥが長期のスリープ状態にいると共に、ＵＥに送信されたデータをバッファするようにＭＣＮが構成されていると考える。

サービスレイヤはネットワークサービスアーキテクチャ内の機能レイヤである。サービスレイヤは、通常ＨＴＴＰ、ＣｏＡＰ，またはＭＱＴＴなどのアプリケーションプロトコルレイヤの上に位置して、クライアントアプリケーションに付加価値サービスを提供する。また、サービスレイヤは、例えば制御レイヤやトランスポート／アクセスレイヤなどの、下位リソースレイヤにおけるコアネットワークにインタフェースを提供する。サービスレイヤは、サービス定義、サービスランタイムイネーブルメント、ポリシ管理、アクセス制御、サービスクラスタリングなどの（サービスの）諸機能の複数のカテゴリをサポートする。最近、複数の業界標準化団体（例えば、ｏｎｅＭ２Ｍ）がＭ２Ｍサービスレイヤを開発して、Ｍ２ＭタイプのデバイスとアプリケーションとをＩｎｔｅｒｎｅｔ／Ｗｅｂ、セルラ、エンタープライズ、ホームネットワークなどのデプロイメントに統合することに伴う課題に対処している。Ｍ２Ｍサービスレイヤは、アプリケーションおよび／または種々のデバイスに、ＣＳＥまたはＳＣＬとも呼ばれるサービスレイヤにサポートされた一群の前述の諸機能へのアクセスを提供することができる。いくつかの例として、限定はしないが、種々のアプリケーションに共通に使用可能な、セキュリティ、課金、データ管理、デバイス管理、ディスカバリ、プロビジョニング、コネクティビティ管理がある。これらの機能は、Ｍ２Ｍサービスレイヤによって定義された、メッセージフォーマットと、リソースストラクチャと、リソース表現とを利用するＡＰＩを介して、これら様々なアプリケーションに可用にされる。ＣＳＥまたはＳＣＬは、ハードウェアおよび／またはソフトウェアによって実現されて、種々のアプリケーションおよび／またはデバイス（例えば、これら機能エンティティ間の機能インタフェースなど）に、使用できるように開示された（サービス）機能を提供する、機能エンティティである。

拡張Ｓ－ＧＷバッファリングを用いたＵＥとの通信に用いる、アプリケーションレイヤと、トランスポートレイヤと、サービスレイヤとの各プロトコルは、ＵＥに送信されたデータがＳ－ＧＷのＭＣＮにバッファされるものと考える。例えば、Ｓ－ＧＷが、特定のＵＥに対して最大３０分ダウンリンクパケットをバッファするように構成されている場合は、アプリケーションレイヤ再送タイマは、ＵＥに送信されるパケットが、パケットがＵＥに配信され、ＵＥがＰＳＭから抜け出る時の前に３０分間Ｓ－ＧＷにバッファされることがわかるように調整される。パケットがＳ－ＧＷバッファに残っている間に同一パケットの第２送信を試みることは非効率的である。接続可能性通知に関しては、ＳＣＳ／ＡＳは、接続可能性通知を受信した後、ＵＥが省電力状態に戻る前に、またはＵＥのｅＤＲＸページングオケージョンが終わる前に慎重にＵＥにデータを送信する。現行の手法では、転送に係るＵＥが、ＰＳＭまたはｅＤＲＸなどの、スリープモードを用いている場合は考慮されていない。さらに、現行の手法では、ＳＣＳ／ＡＳにデータ転送に係る特定のＵＥのアイデンティティを表示させるようになっていない。

さらなる背景として、ＷｉＦｉにおける省電力モードに関して、ＷｉＦｉ受信経路における消費電力は多くの場合送信経路に比べて低く、約１／３である。したがって、送信経路を遮断して発信フレームが存在しない時のリスンだけ行うことで電力効率が高まる。ＷｉＦｉステーション（Station：ＳＴＡ）が省電力モードに入っていて受信経路を遮断していることを、該ＷｉＦｉステーションがアクセスポイント（Access Point：ＡＰ）（またはワイヤレスＬＡＮコントローラ）に表示している場合、そのＷｉＦｉステーションによってさらなる省電力を達成することができる。ＡＰ（またはワイヤレスＬＡＮコントローラ）は、省電力モードの状態にいるＳＴＡ宛のフレームを保存し、リクエストされるとそのＳＴＡに該フレームを送信する。アソシエーション時に、ＳＴＡはリスンインターバルパラメータを用いて、該ＳＴＡがキューされたフレームをＡＰから検索する前にどれだけの数のビーコン間隔をスリープするか、をＡＰに表示する。ＡＰは、ＳＴＡのリスン間隔が経過するまでキューされたいずれのフレームもドロップしない。

既存の手法では、ＳＴＡは、パワーマネージメントビットセットと併せてＡＰにヌルフレームを送信することによって省電力モードに入る。それ以降、ＡＰ（またはワイヤレスＬＡＮコントローラ）は、ＳＴＡ宛のパケットをｐｅｒ－ＳＴＡキューに保存し、ビーコンフレーム内のＴＩＭフィールドを、ＳＴＡ宛てのパケットがＡＰでキューされたことを通知するように設定する。ＳＴＡは、リスン間隔ごとにスリープからウェイクアップしてビーコンフレームを受信し、ＳＴＡ向けのＴＩＭフィールドが設定されていることを検出すると、ＰＳ－ＰｏｌｌフレームをＡＰに送信する。これに応じて、ＡＰは第１のキューされたフレームをＳＴＡに送信する。ＳＴＡはキューされたデータフレームを受信し、このフレームにさらにデータフィールドが設定されていると、別のＰＳ－ＰｏｌｌフレームをＡＰに送信する。場合により、ＳＴＡがＰＳ－Ｐｏｌｌフレームの送信を継続してキューされたフレームを受信し、何も残っていなくなると、ＳＴＡは次のリスン間隔までスリープ状態に戻る。

前述の方法はポーリングを用いており、ポーリングは一般に軽トラフィック状態に適しているので、この方法はきわめて効率的なデータ転送方法と言えるものではない。この方法の一改良例として、パワーマネジメントビットのオフに伴いヌルフレームを送信することによって、キューされたフレームの検出時に省電力モードを抜け出ることがある。この後、ＡＰ（またはワイヤレスＬＡＮコントローラ）はキューされたフレームをＳＴＡに送信することができる。次いでＳＴＡは、パワーマネジメントビットのオンに伴いヌルフレームを送信することによって再び省電力モードに入る。例えば、ＳＴＡは、ＡＰ（またはワイヤレスＬＡＮコントローラ）からフレームを全く受信しない期間である、短時間待機し、ＡＰ（またはワイヤレスＬＡＮコントローラ）において該ＳＴＡ向けの未処理のキューされたフレームの発信はないと推定する。

ここでスケジューリング外の非同期パワーセーブデリバリ（Unscheduled Asynchronous Power Save Delivery：Ｕ－ＡＰＳＤ）について考える。レガシーパワーセーブ方法は例えばＶｏＩＰなどの短フレームからなる周期的双方向データトラフィックに高い省電力効果をもたらす方法ではない。一例として、ＡＰからの未処理のキューされたフレームの発信がないことを推定する時間は、多くの場合連続したＶｏＩＰフレーム間の期間よりはるかに長く、それによりＳＴＡはＶｏＩＰ呼の間に省電力モードにならないようになっている。このＵ―ＡＰＳＤ手法は８０２．１１ｅの一部として定められたものであり、従来の手法よりも適切にこの状況に対処することを意図したものである。

Ｕ―ＡＰＳＤは、クライアントに、ＶｏＩＰ呼の予測可能なトラフィックパターンに基づいてＳＴＡとＡＰとの間の通信パターンを前もってスケジュールさせる。例えば、クライアントは、ＡＰとネゴシエーションして、標準的な２０ミリ秒ごとにＶｏＩＰフレームを交換することができる。このネゴシエーションが行われると、クライアントは、ＡＰに通知することなくパケット交換の間にスリープする。非ＶｏＩＰトラフィックの場合は、ＳＴＡは、トリガフレームを送信することによって、ＡＰにキューされたユニキャストトラフィックを検索する。ＡＰは、ビーコンと，プローブレスポンスフレームとアソシエーション／リアソシエーションレスポンスフレームとでこの機能をアドバタイズすることによって、この手法をサポートしていることを通知する。

レガシー省電力モードと同様に、ＳＴＡはＮｕｌｌフレームにパワーマネジメントビットを設定してＳＴＡが省電力モードの状態にいることをＡＰに通知する。省電力モードの状態にいるＳＴＡは、ＱｏＳ ＮｕｌｌフレームまたはＱｏＳ Ｄａｔａフレームを送信してＡＰをトリガしキューされたフレームを送信させる。ＡＰはトリガに肯定応答し、次いでネゴシエーションされた最大数までフレームを処理する。場合により、ＡＰにキューされたフレームがないと、トリガの受信時に、ＡＰはＱｏＳ Ｎｕｌｌフレームで応答する。レガシー省電力モードに対するＵ―ＡＰＳＤの利点は、ＳＩＦＳ分離に伴ってフレームの交換が生じ、メディアがその交換の間ロックされたままになることである。レガシー省電力モードでは、フレームはＤＩＦＳ分離に伴い交換されて、他のＳＴＡがメディアを乗っ取ることができるようになる。

図４に、ハイレベルのマルチメディアブロードキャスト／マルチメディアサービス（Multimedia Broadcast/Multicast Service：ＭＢＭＳ）の一例を示す。ＭＢＭＳは、３ＧＰＰ ＴＳ ２３．２４６．（マルチメディア／ブロードキャスト／マルチメディアサービス、アーキテクチャと機能記述）に詳述されており、その内容は参照することにより本明細書に援用される。図４において、ＢＭ－ＳＣはＭＢＭＳセッションを制御するノードである。ＢＭ－ＳＣは、ＭＢＭＳを用いて特定のコンテンツをブロードキャストするとの通知を開始し、セッションと結合したい端末に関連する機能を管理する。端末とＢＭ－ＳＣとのインタラクションは通常のユニキャストを通じてハンドルされる。ＭＢＭＳサービスはユーザを意識したものである。例えば、セッションはユーザ単位で制御される。ＢＭ－ＳＣの機能の例として、広告機能と、キーマネジメント機能と、セッションおよびトランスミッション機能とがある。

図５は、ＵＥがＭＢＭＳを有効化する方法の一例を示している。ステップ１で、ＵＥはデフォルトのＰＤＮコンテキストを有効にする。ステップ２で、ＵＥはＭＢＭＳとの結合を試みる。このグループ結合の判断は、図示していないサービスアドバタイズメントに応答して行われる。例えば、アドバタイズメントがＷＡＰプッシュ、ＳＭＳ等を介して送信されている。ステップ３－１７で、ＭＢＭＳサービスが有効にされる。これについては３ＧＰＰ ＴＳ ２３．２４６に詳しく述べられている。

図６を参照する。サービス機能サーバ（Services Capability Server：ＳＣＳ）またはアプリケーションサーバ（Application Server：ＡＳ）（ＳＣＳ／ＡＳ）（本明細書ではサードパーティサーバと称することもある）はＭＢＭＳシステムにアクセスして、サービスケイパビリティエクスポージャファンクション（Service Capability Exposure Function：ＳＣＥＦ）を介してデータをブロードキャストまたはマルチキャストする。図６において、ステップ５で、ＴＭＧＩがグループに配信される。ＴＭＧＩは、グループメッセージのリスンのためにグループのメンバに用いられる。ステップ６で、ＳＣＳ／ＡＳはブロードキャストまたはマルチキャストの開始時をＳＣＥＦに通知する。ステップ１３で、グループメッセージが配信される。図６については、３ＧＰＰ ＴＳ ２３．６８２により詳しく説明されており、その内容は参照することにより本明細書に組み込まれる。

前述の通り、例えば、ＵＥがスリープ状態にいる間での、モバイルコアネットワーク（ＭＣＮ）内へのモバイル着信（ＭＴ）データのバッファリングは、ＭＮＯがサードパーティのサービスプロバイダを提供する上での好ましいサービスになり得る。例えば、ある場合において、このサービスは、サードパーティのサービスプロバイダが１個のパケットをＵＥに送信することを必要としている場合で、かつサードパーティのサービスプロバイダが、アプリケーションレイヤ、サービスレイヤ、またはトランスポートレイヤからタイムリーな肯定応答を受信することに関心がない場合に有用となる。しかし、他の通信シナリオでは、ＭＣＮ内へのＭＴデータのバッファリングは、ネットワーク内に、アプリケーションレイヤプロトコル、サービスレイヤプロトコル、またはトランスポートレイヤプロトコルに関連する問題を起こす可能性がある。

例えば、ＭＣＮ内のバッファリングのサポートには、ＭＣＮが、スリープ状態のデバイスにアドレスされる任意のＭＴデータのバッファに可用なメモリリソースを有することが必要になる。したがって、例えば、ＭＴデータのサイズが重要である場合、特に多数のＩｏＴデバイスに対してバッファリングが必要な場合に、メモリ必要量がきわめて大きくなる可能性がある。さらに、ＭＴデータが旧ネットワークエレメントにバッファされている状態で、スリープ状態のＵＥがウェイクアップして新ネットワークエレメント（例えば、ＭＭＥやＳ－ＧＷ）にアタッチすると、問題が起こり得る。場合により、新ネットワークエレメントは旧ネットワークエレメントからバッファされたデータをフェッチしなければならない。あるいは、例えば、サードパーティサーバがＭＣＮにもバッファされるデータをバッファする場合に、旧ネットワークエレメントがバッファされたデータを「ドロップ」することがある（このことは、サードパーティサーバがデータを再び送信する必要があることを意味する）。

さらに、場合により、ＡＳ／ＳＣＳがデータ（またはトリガ）をＵＥグループにブロードキャスト（またはマルチキャスト）することを望むことがある。ＵＥグループは、例えばＰＳＭや拡張アイドルモードＤＲＸ（ｅＤＲＸ）などの、種々の省電力機能を利用する。このため、ＡＳ／ＳＣＳ（サードパーティアプリケーションサーバ）は、データまたはトリガがブロードキャストまたはマルチキャストされる時に、グループメンバが確実にリスンしている（例えば、スリープしていない）ようにする。

前述の、ならびにＴＳ ２３． ６８２に記載された、ＭＣＮバックグラウンドデータ転送手順により、サードパーティサーバ（例えば、ＳＣＳ／ＡＳ）はＰＣＲＦとのデータ転送をコーディネートする。これらのＳＣＳ、ＡＳ、サードパーティサーバ、サードパーティアプリケーションサーバ等の用語は、本明細書において互換性があるが、これに限定するものではない。前述のバックグラウンドデータ転送手順では、ＵＥがスリープ状態にいる（例えば、ｅＤＲＸおよび／またはＰＳＭを用いている）時を把握し得ないことは明らかである。さらに、このバックグラウンドデータ転送手順とＵＥのスリープモードとのコーディネーションの不足によりＭＣＮ内に大量のデータがバッファされることになることは明らかである。例えば、ＵＥがＰＳＭ状態にいる間にＳＣＳ／ＡＳがデータ転送を行うと、大量のデータがバッファされる可能性がある。

ＭＣＮ内のバッファリングのサポートもまた、アプリケーションレイヤと、サービスレイヤと、トランスポートレイヤとの各プロトコルを難しいものにする。例えば、ＭＴデータがＭＣＮ内にバッファされると、アプリケーションレイヤと、サービスレイヤと、トランスポートレイヤとの各プロトコル内のいずれかの再送タイマを、肯定応答がＵＥの可能な最長のスリープ期間より早めとの予想にならないように調整する必要がある。場合により、ＵＥがウェイクアップすると、再送タイマはより迅速に肯定応答を予想できるように調整される。アプリケーションレイヤと、サービスレイヤと、トランスポートレイヤとの各プロトコルが再送タイマの調整をサポートしない場合、それらプロトコルはＭＣＮバッファリングに適合しない。

アプリケーションレイヤと、サービスレイヤと、トランスポートレイヤとの各プロトコルがＭＣＮバッファリングに適合しない場合は、ＵＥがスリープ状態を抜け出るまでデータはサードパーティによってバッファされる。この手法では、ＵＥがスリープ状態である時がサードパーティサーバにわかるようにサードパーティサーバとＵＥとが時刻同期している必要がある。さらに（もしくはその代わりに）、この手法では、ＵＥが接続可能である時を、ＭＣＮがサードパーティサーバに通知することが必要になる。さらに、サードパーティサーバからのデータは、ＵＥがスリープ状態に戻る前にＵＥに届く必要がある。さらに、低価格ＩｏＴデバイスとサードパーティサーバとの時刻同期は、例えば、低価格ＩｏＴデバイスに時間を合わせる必要のある物理的ハードウェアの面から現実的でない。また、ＩｏＴデバイスとサードパーティサーバとの間のメッセージングが追加されることからも現実的でない。

前述の通り、ＭＣＮは、ＵＥが接続可能である時、または接続可能になりそうな時をサードパーティサーバに通知することができる。この手法では、ＵＥがスリープ（非アクティブ）状態に戻る決定をする前に、サードパーティサーバがデータを送信することが必要になる。

図７に、好適な通信パターンの例（例１）と好適でない通信パターンの例（例２）とを示す。図に示す通り、例１では、ＵＥは長期間スリープしていて、ＭＴデータを受信する必要があるかどうかをチェックするために定期的にウェイクアップする。好適な例では、ＭＴデータのチェック（またはリスン）に費やす時間量が最小になる。好適でない例（例２）では、ＵＥはウェイクアップしており、サードパーティサーバからのデータは未だＭＣＮに届いていないので、ＵＥはスリープ状態に戻る。一方、ＭＴデータは、ＵＥがスリープしている間にＭＣＮに届く。ＵＥがアウェイク状態のままで長時間リスンしていた場合、サードパーティサーバの接続の成功の機会は増す。しかし、より長いウェイクアップ通知応答時間をサードパーティサーバに与えるために、ＵＥがより長期間リスンする必要がある場合、ＵＥの消費電力は増える。

前述の通り、ＷｉＦｉデバイス（ＳＴＡｓ）は省電力モードをサポートしており、このモードにおいてはＷｉＦｉデバイスは何時間もダウンリンク通信をリスンしない。ＵＥが省電力モードの状態でいる時間量は、ＳＴＡとＷｉＦｉ ＡＰまたはＷＬＣとの間でネゴシエートされる。ＳＴＡが省電力モードの状態にいる間は、ＡＰまたはＷＬＣは、ＳＴＡに送信されるすべてのダウンリンクデータをバッファする。現在のところ、アプリケーションサーバは、例えば、どれだけ長くＳＴＡが省電力モードの状態にいるか、またはＳＴＡが省電力モードの状態にいる場合どれだけ多くのデータをバッファするべきか等の、様々なファンクションに影響を及ぼし得るものではない。さらに、ＡＳは、ＳＴＡが、ダウンリンクデータの受信が必要になる前に、どれだけ長くスリープしてよいかを知っている唯一のアクタであることが明らかである。しかし、現行の手法では、ＡＳは、ＳＴＡの省電力モード設定のコントロールを行わないため、省電力モードを最適に設定することができない。

本明細書で述べる種々の実施形態において、サードパーティアプリケーションサーバは、特定のＵＥまたはＵＥグループに送信されるデータを有していることをネットワークに通知する。さらに、以下で詳述する様々な例において、ＭＣＮはサードパーティアプリケーションサーバから、ＵＥがアウェイク状態にあることを保証し、データ転送が完了する前にスリープ状態に入ることができないという通知を受ける。

一例において、既存のバックグラウンドデータ転送手順が最適化される。例えば、場合により、ＨＳＳとＭＥＥとは、予定の転送時にＵＥが接続可能であることをＭＭＥが保証できるようにしたＰＣＲＦのバックグラウンドデータ転送デシジョンを通知される。他の例では、トランスポートレイヤと、アプリケーションレイヤと、サービスレイヤとの各プロトコルが最適化されて、それによりプロトコル内の再送タイマが、ＭＣＮがＭＴデータをバッファすることと、ＵＥが長いスリープサイクルを用いている場合はサードパーティアプリケーションサーバとＵＥとの間で観察されるＭＴパケットの遅延が大きく変動すること、とを知ることができるようにされている。ＭＣＮからの通知はサードパーティアプリケーションサーバに使用されて、プロトコルの再送タイマを動的に調整することができるようにされる。

他の例では、「ＤＤＮ故障後の可用性」手順が最適化されて、サードパーティアプリケーションサーバが、ＵＥが可用であるとの通知を受けるが、ＵＥがスリープ状態に戻った後にＵＥにデータを送信する場合がわかるようにされる。

本明細書に述べた種々の実施形態は、省電力モードを用いるＷｉＦｉデバイスにも適用できる。例えば、後述するように、ＳＣＥＦは、ＷＬＣまたはＷｉＦｉ ＡＰへのインタフェースを有し、このインタフェースを用いてＳＴＡによる省電力モードの使用を設定することができる。

以下、サードパーティサーバにおけるバッファリングについて述べる。一実施形態例において、モバイルネットワークオペレータ（Mobile Network Operator：ＭＮＯ）がネットワークバッファリングをサポートしていない場合、ＭＮＯは、サードパーティサーバ（例えば、ＳＣＳ／ＡＳ）に、サードパーティサーバが特定のＵＥまたはＵＥグループに送信されるデータを有していることをＭＣＮに通知させる。ＭＣＮはＵＥをウェイクして、そのＵＥのアウェイク状態を維持する。ＵＥをウェイクしてそのアウェイク状態を維持することには、ＵＥのページング、拡張アイドルモードＤＲＸが一定期間無効になることをＵＥに通知すること、および／またはＰＳＭの利用が一定期間無効になることをＵＥに通知することが含まれる。ＵＥをアウェイク状態に維持することは、例えばＭＭＥやｅＮｏｄｅＢなどの、ネットワークノードに、ＵＥのＲＲＣ接続を一時停止するべきでないこと、またはＵＥのＲＲＣ接続を解放するべきでないことを通知することを含む。例えば、ＵＥはネットワークノードからメッセージを受信する。このネットワークノードは、以前にスケジュールされたスリープスケジュールをアボートするべきであることをＵＥに通知するノードである。データ転送がＵＥグループ向けとされている場合は、ＭＭＥは、そのグループのＰＳＭタイマまたはｅＤＲＸタイマを調整して、それによりＵＥ相互の配置が整えられると共に、グループのメンバがアウェイク状態になって同時ダウンリンクデータ転送が可用になる。

一実施形態例において、サードパーティサーバがＵＥに送るデータを有している場合、サードパーティサーバは、特定のＵＥに送信可能なデータを有していることをＭＣＮに伝える。３ＧＰＰ ＴＳ ２３．６８２に詳述されている現行の「バックグラウンドデータ転送」リクエストは、サードパーティサーバに、該サーバが一定量のデータを複数のＵＥに送信する必要があることを表示させるもので、特定のＵＥまたはＵＥグループを表示させるものではない。サードパーティサーバに特定のＵＥまたはＵＥグループを表示させることによって、ＭＣＮは、表示された複数のＵＥがページングされるべきか、スリープ状態に入ることを防ぐべきか、アウェイク状態を維持するべきか、および／またはＲＲＣ接続の解放を開始することを防ぐべきかを、前もって知ることが可能になる。どのＵＥがデータの受取人であるかとの情報を用いて、データ転送を行うべき時を計算することができる。例えば、グループのメンバ（例えば全メンバ）がアウェイク状態になると予想されるようにタイマを選択することができる。

図８および９（以下記述）は少なくとも１つのＵＥのアウェイク状態を維持する様々な実施形態を示す。同図には、１つ以上のノード、装置、デバイス、サーバ、ファンクション、またはネットワークにより実行される種々のステップや操作が示されている。例えば、各装置は、単独または共同で動作して本明細書で述べた方法を実行する。本明細書で用いた通り、装置と、ネットワーク装置と、ノードと、サーバと、デバイスと、エンティティと、ネットワークファンクションと、ネットワークノードとは互換的に用いることが可能である。上記各図に示すノード、サーバ、ファンクション、またはネットワークは通信ネットワークにおける論理エンティティを表し、そのネットワークのノードのメモリに保存されて該ノードのプロセッサで実行されるソフトウェア（例えば、コンピュータ実行可能な命令）の形で実現される。このネットワークは、後述の図１２Ａまたは１２Ｂに示した、いずれかの全体的アーキテクチャからなるものである。すなわち、図８および９に示した方法は、例えば図１２Ｃまたは１２Ｄに示したノードまたはコンピュータシステムなどの、ネットワークノードのメモリに保存されたソフトウェア（例えば、コンピュータ実行可能な命令）の形で実現される。コンピュータ実行可能な命令は、ノードのプロセッサで実行されると、各図に示したステップを実行する。さらに、これらの図に示したすべての送信および受信ステップは、ノードのプロセッサとそのプロセッサが実行するコンピュータ実行可能な命令（例えば、ソフトウェア）との制御下で、ノードの通信回路（例えば図１２Ｃおよび１２Ｄの回路３４または９７）によって行われる。さらに、本明細書で述べた、ノードと、デバイスと、ファンクションとは仮想ネットワークファンクションとして実行されることは明らかである。

図８を参照する。ネットワーク８００は、ｅＮｏｄｅＢ８０２と、ＭＭＥ８０４と、ＨＳＳ８０６と、ＳＣＥＦ８０８と、ＳＣＳ／ＡＳ８１０（サードパーティサーバとも呼ばれる）とを含む。ネットワーク例８００は開示内容の説明を容易にするために簡略化されており、本開示の範囲を限定するものではないことは明らかである。他のデバイスと、システムと、構成とを用いて、ネットワーク８００などのネットワークに加えて、またはその代わりに本開示の実施形態が具現される。これらすべての実施形態は本開示の範囲内にあるものと考えられる。

図示の実施形態によれば、ステップ１で、ＳＣＳ／ＡＳ８１０はデータ配信リクエストをＳＣＥＦ８０８に送信する。データ配信リクエストは、例えば、限定はしないが、ＳＣＳ／ＡＳ識別子と、ＳＣＳ／ＡＳリファレンスＩＤと、ＵＥ当たりのボリュームと、外部グループ識別子またはＭＳＩＳＤＮまたは外部グループＩＤと、所望の時間ウィンドウと、ＱｏＳメッセージプライオリティとを含んでいる。ＳＣＳ／ＡＳ識別子は、どのＳＣＳ／ＡＳがリクエストを開始しているかを通知する。ＳＣＳ／ＡＳリファレンスＩＤは、ＳＣＳ／ＡＳによって指定されたトランザクションＩＤである。一例では、ＵＥ当たりのボリュームが所望のデータ転送の概略の大きさになる。外部グループ識別子、ＭＳＩＳＤＮ、または外部グループＩＤは、データ転送の受信者となる特定の１つ以上のＵＥの識別に用いられる。所望の時間ウィンドウは、ＳＣＳ／ＡＳが次にデータ転送を行いたい時を示す。場合により、この値がないことによってＳＣＳ／ＡＳができるだけ早くデータ転送を行いたいことを表す。一例では、ＱｏＳメッセージプライオリティインディケータはオペレータが定義した値であり、この値を用いてＳＣＳ／ＡＳがメッセージの優先度または重要度を表す。この情報は課金記録に取り込まれて、サードパーティアプリケーションサーバが表示された優先度に応じて課金されるようになっている。

さらに図８を参照する。図示の例によれば、ステップ２で、リクエストを認可した後、ＳＣＥＦ８０８はデータ配信リクエストメッセージをＨＳＳ８０８に送信する。このメッセージは、ＳＣＥＦリファレンスＩＤと，ＵＥ当たりのボリュームと、外部グループ識別子またはＭＳＩＳＤＮまたは外部グループＩＤと、所望の時間ウィンドウとを含んでいる。このメッセージにおいて、例えば、ＳＣＥＦリファレンスＩＤは、ＳＣＥＦによって指定されたトランザクションＩＤである。他の例では、ＳＣＥＦ８０８がこのメッセージを直接ＭＭＥ８０４に送信する。ＳＣＥＦ８０８は、ＨＳＳ８０６にクエリすることによってＭＭＥ８０４の存在を知る。

図示の例によれば、ステップ３で、リクエストを認可した後、ＨＳＳ８０６はデータ配信リクエストメッセージをＭＭＥ８０４に送信する。このメッセージは、ＳＣＥＦリファレンスＩＤと，ＵＥ当たりのボリュームと、ＩＭＳＩと、所望の時間ウィンドウとを含んでいる。このメッセージは、少なくとも１つのＵＥに対してサードパーティサーバ８１０内にバッファされたデータがあることを、ＭＭＥ８０４に通知するものである。これにより、１つの装置からなるＭＭＥは、サードパーティサーバからのデータ転送時にデータの受信者となる少なくとも１つのユーザ装置（ＵＥ）を通知する、データ配信リクエストメッセージを受信する。データ配信リクエストメッセージはさらに、サードパーティサーバがデータ転送を行いたい時を表示する。ＭＭＥは、この情報を用いて、ＵＥの省電力モード（例えば、スリープモードまたはＤＲＸモード）のハンドリング法と、ＵＥをページングする時とを決定する。これにより、ＭＭＥは、データ配信リクエストメッセージに基づいて、少なくとも１つのＵＥがデータ転送に備えてアウェイク状態であることを保証するアクションを行う。例えば、予定されたデータ転送の受信者がＵＥグループである場合、このアクションはグループ内の各ＵＥがデータ転送に備えて同時にアウェイク状態であることを保証する。

一例では、この少なくとも１つのＵＥがアウェイク状態であることを保証するアクションの実行は、データ配信リクエストメッセージの受信に応じて少なくとも１つのＵＥをページングすることを含む。例えば、ＵＥ（またはＵＥグループ）がＲＲＣ接続状態になく、データウィンドウ用の所望の時間ウィンドウが近づいている場合、またはサードパーティサーバができるだけ早くデータ転送を行いたい場合は、ＭＭＥは一番早いページングオケージョンにページングを開始する。場合により、ＵＥがページングされてＲＲＣ接続状態になると、ＭＭＥは、所望の時間ウィンドウが経過してデータ転送が完了するまで、またはタイマが満了するまでＲＲＣ接続の解放を開始しない。すなわち、ＵＥをページングしてそのＵＥが無線リソース制御（Radio Resource Control：ＲＲＣ）接続状態になるようにした後は、データ配信リクエストメッセージ内の少なくとも１つの時間ウィンドウが経過してデータ転送が完了するまで、またはタイマが満了するまで、ＭＭＥはＵＥをＲＲＣ接続状態から解放することを控える。

ＵＥがＰＳＭモードの状態にいる例では、ＭＭＥは、所望の時間ウィンドウが経過するまでＵＥがＰＳＭモードを用いることを防ぐ。さらに、一例によると、ＭＭＥは、データ配信リクエストメッセージ内の時間ウィンドウが経過するまで、ＵＥまたはＵＥグループが省電力モード（ＰＳＭ）または拡張アイドルモード間欠受信（ｅＤＲＸ）に入ることを防ぐ。ＵＥがＰＳＭまたはｅＤＲＸに入ることを防ぐことは、トラッキングエリアアップデート時にＵＥが提示したタイマ値を拒絶することを含み得る。別の例では、ＵＥがＰＳＭまたはｅＤＲＸに入ることを防ぐことは、ＵＥに関連するタイマを調整し、かつＵＥに関連するトラッキングエリアアップデートタイマを調整して、データ転送が行われると少なくとも１つのＵＥがアウェイク状態になるようにすることを含み得る。ＭＭＥは、ＴＡＵ時にＵＥが提示したアクティブタイマ値を拒絶する。ＭＭＥは、配信実施時にＵＥが確実にＰＳＭ状態にいないようにするために、例えば、アクティブタイマを拒絶することによって、またはＵＥが提示した値よりも長時間のアクティブタイマを提供することによって、ＰＳＭが許可されていないという通知をＵＥに提供する。場合により、ＭＭＥ８０４はさらに、データはサードパーティサーバ８１０においてＵＥ向けにバッファされているという通知をＵＥに提供する、またはデータ転送、ブロードキャスト、またはトリガは保留されているという通知をＵＥに提供する。あるいは、ＭＭＥ８０４は、ＵＥのアクティブタイマとＴＡＵタイマとを調整して、データ転送が行われるとＵＥがアウェイク状態になるようにする。

ＳＣＥＦ８０８が外部グループＩＤを提供する場合は、ステップ３のメッセージは複数のＩＭＳＩを含む。さらに、ステップ３のメッセージは、ＭＭＥが機能しているグループ内のＩＭＳＩ毎に複数回ＭＭＥに送信される。また、このメッセージは、グループ内の１ＵＥに対して機能している各ＭＭＥに１回以上送信される。

さらに図８を参照する。図示の例によれば、ステップ４で、ＭＭＥ８０４は、ＳＣＥＦリファレンスＩＤと，ＵＥ当たりのボリュームと、ＩＭＳＩと、所望の時間ウィンドウとを含むデータ配信リクエストメッセージを、ｅＮｏｄｅＢに送信する。ＵＥがＲＲＣ接続状態にいる場合は、ステップ４のメッセージは、所望の時間ウィンドウが経過するまでｅＮｏｄｅＢはＵＥのＲＲＣ接続を遮断するべきでないことをｅＮｏｄｅＢに通知するものとして機能する。ＵＥがＲＲＣ接続状態にない場合は、メッセージは、所望の時間ウィンドウ内でＵＥのページングをリクエストするものとして機能する。したがって、ＵＥがアウェイク状態であることを保証するためにＭＭＥが行うアクションは、データ配信リクエストメッセージを無線アクセスノード（例えば、ｅＮｏｄｅＢ８０２）に送信することを含む。このデータ配信リクエストメッセージはＵＥのページングのリクエストを含んでいる。ｅＮｏｄｅＢと無線アクセスノードとは本明細書において互換的に用いられるが、これに限定するものではない。別の例では、ＭＭＥからのデータ配信リクエストメッセージは、無線アクセスノードに、データ転送リクエスト（例えば、サードパーティサーバからのリクエスト）内の時間ウィンドウが経過するまで少なくとも１つのＵＥとの無線リソース制御（ＲＲＣ）接続を維持するように指示する。さらに以下に述べるように、ＭＭＥ８０４から送信されたデータ配信メッセージはページを含み、このページは、サードパーティサーバ８１０にデータがバッファされていることを無線アクセスノード８０２に示している。

さらに図８に示した例を参照する。ステップ４のメッセージは、ＭＭＥ８０４からｅＮｏｄｅＢ８０２へのページングメッセージである。ページングメッセージの例として、限定はしないが、ページング用ＮＡＳ ＩＤと、ＴＡＩと、ＵＥアイデンティティベースのＤＲＸインデックスと、ページングＤＲＸ長と、ページング用ＣＳＧ ＩＤのリストと、ページング優先度通知と、ＳＣＥＦリファレンスＩＤと，ＵＥ当たりのボリュームと、ＩＭＳＩと、所望の時間ウィンドウとがある。場合により、既存のページング優先度インディケータを用いて、ページングの理由が、ダウンリンクデータがＭＣＮにおいて可用であることではなく、データがサードパーティサーバにおいてＵＥ向けにバッファされていること（すなわち可用）であることをｅＮｏｄｅＢ８０２に通知する。他の実施形態例では、新しいインディケータを用いて、ページングの理由が、ダウンリンクデータがＭＣＮに可用であることではなく、データがサードパーティサーバ（例えば、ＳＣＳ／ＡＳ８１０）においてＵＥ向けにバッファされていること（すなわち可用）であることをｅＮｏｄｅＢ８０２に通知する。例えば、新しいインディケータが、３ＧＰＰ ＴＳ ３６．４１３に規定されている「ページングのためのアシスタンスデータ」情報要素に付加される。例えば、重度の輻輳時に、ｅＮｏｄｅＢ８０２は、ＭＣＮに新しいデータが保存されてＵＥ向けに準備が整っている場合でも、次のページングオケージョンでＵＥをページングしないことを選択する。その代わりに、ｅＮｏｄｅＢ８０２は次のページングオケージョンまでＵＥのページングを遅らせることを選択する。

一例では、新しいＮＡＳメッセージがＭＭＥ８０４からＵＥに送られて以前に承認したＰＳＭサイクルがアボートされる。例えば、アクティブタイマが最新のＴＡＵで承認されると、ＭＭＥからＵＥにメッセージが送信されて、ＵＥによるＰＳＭの使用がキャンセルされる。

図示の実施形態によれば、ステップ５で、ｅＮｏｄｅＢ８０２がデータ配信Ａｃｋ（ＳＣＥＦリファレンスＩＤ）をＭＭＥ８０４に送信する。この肯定応答は、ページングの理由はサードパーティサーバ８１０にデータがバッファされていることであるので、ｅＮｏｄｅＢ８０２はＵＥの次のページングオケージョンにＵＥをページングしないという通知を含む。一方、場合により、ｅＮｏｄｅＢ８０２は、ＭＭＥ８０４が後にページングを試みることを要求し、再試行すべき時をＭＭＥ８０４に通知する。別の例では、ｅＮｏｄｅＢ８０２が、ページの配信を試みる時を通知する。

図示の例によれば、ステップ６で、ＭＭＥ８０４はデータ配信Ａｃｋ（ＳＣＥＦリファレンスＩＤ）をＨＳＳ８０６に送信する。ステップ７で、ＨＳＳ８０６はデータ配信Ａｃｋ（ＳＣＥＦリファレンスＩＤ）をＳＣＥＦ８０８に送信する。ステップ８で、図示のように、ＳＣＥＦ８０８はデータ配信Ａｃｋ（ＳＣＳ／ＡＳリファレンスＩＤ）をＳＣＳ／ＡＳ８１０に送信する。

図示の例によれば、ステップ９で、ＵＥ（またはＵＥグループ）は、ＲＲＣ接続状態になるとデータ転送の準備が整い、ネットワークがＵＥによるＰＳＭの使用を無効にするか、またはＵＥがＵＥによる拡張アイドルモードＤＲＸの使用を無効にすると、ＴＡＵまたはアタッチを実行する。ステップ１０で、ＭＭＥ８０４は、データ配信可用性通知（ＳＣＥＦリファレンスＩＤ）をＳＣＥＦ８０８に送信する。ＭＭＥ８０６は、サードパーティバッファからのデータを現在ＵＥに送信可能と判断すると、上記データ配信可用性通知を送信する。ＭＭＥはこの判断を何度も行う。例えば、ＭＭＥ８０６は、ＵＥがＲＲＣ接続状態に入ると、サードパーティバッファからのデータをＵＥに送信可能と判断する。これは、ＭＭＥがＵＥのページングを開始したために行い得ることである。通常、データがＳ－ＧＷに届いた後にＭＭＥはＵＥをページングする。Ｓ－ＧＷからのＤＤＮメッセージは、ＭＭＥにページングを開始させる。一例では、ＭＭＥは、ＨＳＳからのデータ配信リクエストの受信に基づいてページングを開始する。このページングによりＵＥはＲＲＣ接続状態になり、モバイル着信データを受信可能になる。

他の例では、ＵＥがＴＡＵまたはアタッチを行うと、ＭＭＥ８０６はサードパーティバッファからのデータをＵＥに送信できると判断し、そのＴＡＵまたはアタッチ時に拡張アイドルモードＤＲＸの使用をリクエストする。ネットワークは、例えば、ＴＡＵまたはアタッチのレスポンスに拡張アイドルモードＤＲＸのパラメータを含めないことによって、拡張アイドルモードＤＲＸの使用を無効にする。場合により、ＴＡＵまたはアタッチのレスポンスは、サードパーティがＵＥ向けのバッファデータを有しているので拡張アイドルモードＤＲＸはアクセプトされないという通知を含む。拡張アイドルモードＤＲＸの利用を無効にすることにより、ＵＥは必然的に３ＧＰＰ ＴＳ ２３．４０１で詳細に規定されている正規の間欠受信を使用する。一例では、ＵＥが正規のＤＲＸを使用している間にサードパーティサーバ８１０がバッファデータを送信すると、そのバッファデータは、例えばＳ－ＧＷなどのネットワークノードにおいて拡張バッファリングを要さなくなる。

他の例では、ＵＥがＴＡＵまたはアタッチを行うと、ＭＭＥ８０６はサードパーティバッファからのデータをＵＥに送信できると判断し、例えば、そのＴＡＵまたはアタッチの間にアクティブタイムを設けることによってＰＳＭの使用をリクエストする。ネットワークは、ＴＡＵまたはアタッチのレスポンスにアクティブタイムを含めないことによって、ＰＳＭの使用を無効にする。ＴＡＵまたはアタッチレスポンスは、サードパーティがＵＥ向けのバッファデータを有しているのでＰＳＭはアクセプトされないという通知を含む。

さらに図８を参照する。図示の例によれば、ステップ１１で、ＳＣＥＦ８０８はデータ配信可用性通知（ＳＣＳ／ＡＳリファレンスＩＤ）をＳＣＳ／ＡＳ８１０に送信する。次いで、ＳＣＳ／ＡＳ８１０は、バッファデータのＵＥへの送信を開始する。上記通知を受信後、ＳＣＳ／ＡＳ８１０は、ユーザプレーン接続、ＳＭＳ－ＳＣ、またはＳＣＥＦ８０８を用いた他の制御プレーン手順を介してデータをＵＥに送信する。ＳＣＳ／ＡＳ８１０は、後にデータ配信完了メッセージをＳＣＥＦ８０８に送信して、データ転送が完了してそれによりＵＥが再び低電力モードを使用することを許可されることをＳＣＥＦ８０８が知る時を通知する。例えば、メッセージは、ＳＣＳ／ＡＳリファレンスＩＤであって、元のデータ配信リクエスト（ステップ１）に設けられてどの動作が完了したかをＳＣＥＦ８０８がわかるようにした、ＳＣＳ／ＡＳリファレンスＩＤを含む。次いで、ＳＣＥＦ８０８は完了通知をＭＣＮに出す。ＳＣＥＦ８０８からの完了メッセージはＳＣＥＦリファレンスＩＤを含む。このＩＤは、どの動作が完了したかをＭＣＮがわかるように元のデータ配信リクエストに設けられたものである。

場合により、時間ウィンドウの満了後、データ転送が開始したこと、またはリクエストされたデータボリュームが転送されたことをＳ－ＧＷが認めると、Ｓ－ＧＷまたはＭＭＥは、もはやＵＥをアウェイク状態に保つ必要はないことをｅＮｏｄｅＢに通知する。これにより、ｅＮｏｄｅＢは、他のポリシを用いてＵＥのＲＲＣ接続を終了すべき時を決定し始める。

一例では、ＭＣＮは、ＵＥに、エマージェンシＮＡＳメッセージであって、ＵＥのバッテリ残量不足と、ＵＥがＲＲＣ接続を終了するか、中断するか、ｅＤＲＸを使用するか、またはＰＳＭに入るかしなければならないこと、とを示すメッセージを送信させる。例えばＭＭＥなどのＭＣＮノードがこのようなメッセージを受信すると、ＭＭＥは、Ｓ－ＧＷとｅＮｏｄｅＢとが以前にリクエストしたデータ配信をキャンセルしなければならないことをわかるように、Ｓ－ＧＷとｅＮｏｄｅＢとに通知する。ＳＣＥＦにも通知を送って、以前にリクエストしたデータ配信をキャンセルしなければならないことを、ＳＣＥＦからＳＣＳ／ＡＳに通知できるようにする。ＳＣＥＦはさらに、キャンセルの理由が、ＵＥのバッテリ残量不足または省電力モードのリクエストであることを通知する。

図９を参照する。バックグラウンドデータ転送手順への拡張について以下説明する。前述の通り、３ＧＰＰ ＴＳ ２３．６８２に記載されたバックグラウンドデータ転送手順を一実施形態例に基づき修正して、データ転送の対象であるＵＥがアウェイク状態であってリクエストされた時間ウィンドウ内にデータを確実に受信できるようにされる。

図９に示すように、ネットワーク９００は、ｅＮｏｄｅＢ９０２と、ＭＭＥ９０４と、ＳＰＲ／ＨＳＳ／ＵＤＲ９０６と、ＰＣＲＦ９０８と、ＳＣＥＦ９１０と、ＳＣＳ／ＡＳ９１０（サードパーティサーバとも呼ばれる）とを備えている。ネットワーク例９００は開示内容の説明を容易にするために簡略化されており、本開示の範囲を限定するものではないことは明らかである。他のデバイスと、システムと、構成とを用いて、ネットワーク９００などのネットワークに加えてまたはその代わりに本開示の実施形態が具現される。これらすべての実施形態は本開示の範囲内にあるものと考えられる。ポリシが作成されてＰＣＲＦ９０８に承認されると、ＳＰＲ９０６は、例えば転送ポリシなどのポリシをＨＳＳ９０６に提供し、ＨＳＳ９０６はこのポリシをＭＭＥ９０４に提供する。ポリシに関連する時間ウィンドウに到達するかまたは到達しようとしている場合、ＭＭＥ９０４はＵＥをＲＲＣ接続状態に保ち、ＵＥがＰＳＭを用いることならびにｅＤＲＸを用いることを防ぐ。ＵＥがデータ転送の実行に可用になると、ＭＭＥ９０４はＳＣＥＦ９１０に通知する。

さらに図９を参照する。図示の例によれば、ステップ１で、ＳＣＳ／ＡＳ９１２はデータ配信リクエストメッセージをＳＣＥＦ９１０に送信する。このメッセージは、ＳＣＳ／ＡＳ識別子と、ＳＣＳ／ＡＳリファレンスＩＤと、ＵＥ当たりのボリュームと、外部グループ識別子またはＭＳＩＳＤＮまたは外部グループＩＤと、所望の時間ウィンドウとを含む。このメッセージは、修正されたバックグラウンドデータ転送リクエストとなる。このバックグラウンドデータ転送リクエストは、データ転送に係わることになる特定の１つ以上のＵＥを含むように修正される。また、このバックグラウンドデータ転送リクエストは、データ転送に係わるＵＥがＰＳＭ、ｅＤＲＸ、または他のスリープモードを使用しており、ＵＥが可用になる時の通知をＳＣＳ／ＡＳ９１２が必要としているという通知を含むようにアップデートされる。

ステップ２で、リクエストを認可した後、ＳＣＥＦ９１０はいずれかの可用なＰＣＲＦを選択して、今後のバックグラウンドデータ転送手順についてのＰＣＲＦ９０８とのネゴシエーションをトリガする。ＰＣＲＦ９０８は、実行可能な転送ポリシとリファレンスＩＤとを付してＳＣＥＦ９１０に応答する。一実施形態例において、ＳＣＥＦ９１０は、データ転送に係わるＵＥがＰＳＭ、ｅＤＲＸ、または他のスリープモードを使用していることと、ＵＥが可用になる時の通知をＳＣＥＦ９１０が必要としていることと、をＰＣＲＦ９０８に通知することができる。場合により、この通知はデータ転送ポリシの一部として維持される。他の例では、ＳＣＥＦ９１０は、データ転送に係わるＵＥがＰＳＭ、ｅＤＲＸ、または他のスリープモードを使用していることを、プロビジョニングまたはＳＣＳ／ＡＳ９１２からのメッセージを介して知り得る。さらに、ステップ２で、ＳＣＥＦ９１０は、データ転送ポリシのリファレンスＩＤを提供される。図示の例によれば、ステップ３で、ＳＣＥＦ９１０はＰＣＲＦ９０８から提供されたパラメータを転送する。このメッセージはＳＣＳ／ＡＳリファレンスＩＤを含む。図示の例によれば、ステップ４で、ＳＰＲがＨＳＳと同一位置にない場合、ＳＰＲは、ＵＥがデータ転送に可用になる時の通知の提供をＳＣＥＦ９１０が必要としているという通知と共に、データ転送ポリシをＭＭＥ９０４に送る。ＳＰＲとＨＳＳとはＵＤＲ形式のデプロイメントで同一位置にあることは明らかである。データ転送ポリシは、ＳＣＥＦ ＩＤと，ＳＣＥＦリファレンスＩＤと、ポリシに係わるＵＥがデータ転送を実行可能な時の通知をＳＣＥＦが必要としているという通知と、を含む。あるいは、ＳＣＥＦ９１０がこの転送ポリシ情報を直接ＭＭＥ９０４に送る。ＳＣＥＦ９１０はＨＳＳ９０６にクエリすることによってＭＭＥアイデンティティを知る。このように、ＭＭＥが少なくとも１つのユーザ装置に係る転送ポリシを受信することで、ＵＥがアウェイク状態であることを保証するために行うアクションも転送ポリシに基づくものとなる。前述のように、転送ポリシは、１つ以上のスリープモードが少なくとも１つのＵＥに使用されているかどうかを示している。

図８を併せて参照する。図９のステップ５，６，７，８，９，１０をそれぞれ図８の図４，５，６，９，１０，１１と関連して説明する。場合により、ＳＣＳ／ＡＳがモニタリングイベントを設定するか、またはデータ配信リクエストを作成すると、ＳＣＳ／ＡＳは、受信者のＵＥが可用であるという通知を受信した後のデータ転送の準備に要する期間の推定値を提供する。ＭＭＥはこの情報を用いて、ＵＥに先行してどれだけ長く可用性通知の送信が可能な状態でいるかを決定する。

一例では、ＳＣＳ／ＡＳとＳＣＥＦとが、パケットの配信が失敗した後ＵＥが何時可用になるか、の通知をリクエストする。これについては先述している。場合により、ＵＥが短期間アウェイクするのみのこともある。ＵＥがスリープ状態に戻る前にサードパーティサーバからＳ－ＧＷへのデータ送信が失敗すると、データ配信を再度試みても失敗する。一実施例によれば、この状況をハンドルしやすくするために、ＳＣＳ／ＡＳとＳＣＥＦとは、この通知を、ＭＴパケットの送信が成功するまでクリアされないように設定することができる。言い換えると、ＭＣＮ（例えば、ＭＭＥ）は、データパケットのＵＥへの送信が成功するまで、ＵＥが接続可能になる度に通知を送る。

ここで再送タイマの動的調整について考える。場合により、データのバッファリングがＭＣＮにサポートされると、サードパーティサーバからＵＥに送信される第１パケットに比較的大きい配信遅延が生じることがある。例えば、ＵＥのＤＲＸサイクル長が４５分であると、第１パケットはＵＥに届くまでに４５分もかかる。ＵＥがアウェイク状態にいると、パケットに生じる配信遅延ははるかに短くなる、と考えられる。

場合により、データパケットがＭＣＮにバッファされると、パケットがネットワークにバッファされることがサードパーティサーバによって保証されなくなる。ある例では、パケットがＵＥに肯定応答されるまで、パケットがネットワークにバッファされているのか、またはうまく配信できなくて消失したのか、がサードパーティサーバにはわからない。したがって、パケットがＭＣＮにバッファされている場合でも、場合によっては、サードパーティサーバは、ＵＥから肯定応答を受信するまで同一パケットをバッファする必要がある。ある例では、サードパーティサーバは、パケットがＭＣＮにバッファされて問題なくＵＥに配信されることを想定できないことがある。また、場合によっては、大量のデータをＭＣＮにバッファすることはサードパーティサーバにとって効率的でないことがある。

一実施形態例において、トランスポートレイヤ（例えば、ＴＣＰ）とアプリケーションレイヤ（例えば、ＣｏＡＰ）とのプロトコルは、それぞれの再送タイマを動的に調整して、ＵＥが長いスリープサイクルを用いている可能性と、ＭＣＮがパケットをバッファしている可能性とを把握するように構成される。一例では、サーバは、例えば、モバイル着信デバイスすなわちＵＥに関連する接続状態を通知するメッセージを受信する。このメッセージは、例えば、限定はしないが、ＤＲＸタイマまたは省電力モード（ＰＳＭ）タイマ、アクティブタイマ値、トラッキングエリアアップデート（ＴＡＵ）タイマ値、またはＤＲＸサイクル長を含む。このメッセージに基づき、サーバはプロトコルの再送タイムを第１値に設定する。サーバはデータパケットを少なくとも１つのモバイル着信デバイスに送り、上記プロトコルを用いてデータパケットを第１値に基づく所定の回数だけ再送する。前述した通り、場合により、プロトコルは伝送制御プロトコル（ＴＣＰ）または制約付きアプリケーションプロトコル（ＣｏＡＰ）である。さらに、サーバは、モバイル着信デバイスからデータを受信すると、またはネットワークからの通知を受信すると、プロトコルの再送時間を第２値に変更する。その後、このプロトコルを用いてデータパケットを第２値に基づく所定の回数だけ再送する。このネットワークからの通知は、タイマ値と可用性通知とを含む。場合により、サーバは、ネットワークから第２通知を受信すると、再送タイムを第１値に戻す。第２通知は、ＵＥに関するコネクティビティ通知の消失からなる。

例えば、ＵＥの間欠受信（ＤＲＸ）サイクルが４５分であると、トランスポートレイヤ（例えば、ＴＣＰ）またはアプリケーションレイヤ（例えば、ＣｏＡＰ）のプロトコル再送タイマは最初に第１値（例えば、４５分）に設定される。ＭＣＮはＳＣＥＦにＵＥのＤＲＸまたはＰＳＭタイマを通知し、ＳＣＥＦはＳＣＳ／ＡＳに通知する。このように、ＳＣＳ／ＡＳはＵＥに関連する接続状態を通知するメッセージを受信する。このメッセージは、例えば、限定はしないが、ＤＲＸタイムまたは省電力モード（ＰＳＭ）タイマを含む。このメッセージはさらに、アクティブタイマ値、トラッキングエリアアップデート（ＴＡＵ）タイマ値、またはＤＲＸサイクル長を含む。トランスポートレイヤまたはアプリケーションレイヤの肯定応答が受信されると、プロトコルの最初の再送タイマは第２値（例えば、１秒）に再設定（変更）される。すなわち、再送タイムはＵＥからのデータ受信に応じて変更される。第２値は所望に応じて変更可能であり、上記の１秒は例示のために用いたものであることはいうまでもない。一例では、ＵＥにパケットが配信されない場合の、所定数の配信の試みが失敗に終わった後または時間伸長の後、サードパーティサーバは、ＵＥは再びスリープ状態にあって、最初の再送タイマは再び４５分に設定されていると想定する。さらに、ＳＣＳ／ＡＳは、ネットワークから通知を受信後プロトコルの再送タイムを第１値（例えば、４５分）に戻す。

前述の通り、一例では、サードパーティサーバは、その最初の再送タイマを調整すべき時を単独で決定する。サードパーティサーバは、ＭＣＮからの可用性通知をトリガに用いて再送タイマをより短い値に調整する。すなわち、サードパーティサーバは、ネットワークからの通知の受信に基づいて、プロトコルの再送タイムを、第１値よりも大小いずれかの第２値に変える。さらに、この通知は、推奨再送タイマ値として使用可能なタイマ値、または再送タイマ値の採取における基準として使用可能な値を含む。したがって、この通知は第２値を含む。場合により、サードパーティサーバは、例えばＳＣＥＦなどのＭＣＮノードからのコネクティビティ通知の消失をトリガに用いて、再送タイマを、第１値より大きい第２値に調整する。さらに、この通知は、推奨再送タイマ値として使用可能なタイマ値、または再送タイマ値の採取における基準として使用可能な値を含む。再送タイマは、本明細書で述べた種々の実施形態に基づいて任意の所望の回数変更可能であり、上記参照した第１値と第２値とは例示のために用いたものであることは明らかである。

他の例では、サードパーティサーバは、ＭＣＮから通知を受けるのではなく、送信前にＳＣＥＦまたは他のＭＣＮノードにクエリしてＵＥの状態を判定する。ＳＣＥＦは、サードパーティサーバに、ＵＥがどれだけ長くスリープ状態にいることになるかを教える。次いで、サードパーティサーバは、パケットの送信まで待機する、またはＳＣＥＦが示したＵＥの予想スリープ期間に基づいて調整された再送タイマを含むパケットを送信する。

ＳＣＥＦにおけるバッファリングについて考える。ＳＣＥＦは、ＡＰＩであって、ＳＣＳ／ＡＳに、例えばデータ配信リクエストと共に転送すべきデータを提供させる、ＡＰＩをＳＣＳ／ＡＳに提供する。ＳＣＳ／ＡＳからのＡＰＩ呼はノンブロッキングであり、コールバックのアドレスまたはエンドポイントを指定するものである。次いでＳＣＥＦはデータをバッファして肯定応答をＳＣＳ／ＡＥに返す。この肯定応答は、ＳＣＥＦがリクエストを受信して、あり得る他の情報（例えば、ＵＥが可用になるまでの予想待機時間）と共にデータをバッファしたことを伝えるものである。

ＳＣＥＦは、Ｐ－ＧＷ（例えば、ＳＧｉ基準点）とのデータプレーンインタフェースを有する。ＵＥが可用になると、ＳＣＥＦは、ユーザプレーンまたはコントロールプレーンを通じてＵＥにデータを送信し、リクエストが届いたかどうかを示すレスポンス（例えば、新規リクエストに埋め込まれたレスポンス）をＳＣＳ／ＡＳコールバックアドレスに返すことが可能になる。このレスポンスは独立したＴＣＰ接続（または独立したＨＴＴＰ／ＣｏＡＰリクエスト／レスポンス対）を通じて送信される。ＳＣＳ／ＡＳは、状況により応答の受信を肯定応答する。したがって、ＳＣＳ／ＡＳによるブロッキングやウェイティングは起こらず、ＳＣＳ／ＡＳは管理すべき再送タイマを有していない。むしろ、この場合、ＳＣＥＦは、バッファされたデータの配信の問題を管理することができる。

マルチキャスト／ブロードキャストシステムにおけるある種のＩｏＴトラフィック例は、ＳＣＳ／ＡＳに報告するようにＵＥグループをトリガすると想定されるメッセージになり得る、ことは明らかである。ＭＢＭＳベアラを介してトリガを問題なく配信するためには、グループのＵＥは、ブロードキャスト時にＭＢＭＳトラフィックを受信する用意が整っていることが必要なことは言うまでもない。しかし、ＩｏＴトラフィックを受信するＵＥは、多くの場合、例えば省電力モードや拡張アイドルモードＤＲＸなどの、省電力機能を用いている。ＵＥが、ブロードキャスト伝送時にＰＳＭまたはｅＤＲＸを用いている場合、ＵＥがＭＢＭＳトラフィックの受信に可用でないため、トリガが機能しないことは明らかである。ＳＣＳ／ＡＳがＳＣＥＦにグループメッセージリクエストを発行する際、メッセージ開始時も併せて提供される。グループメッセージが配信される時、ＳＣＥＦは、この開始時の前にグループのメンバによるＰＳＭおよび／またはｅＤＲＸの使用を確実に中止させる必要があることは明らかである。

図６を参照する。３ＧＰＰ ＴＳ ２３．６８２に記載されている通り、ＭＢＭＳを用いてＳＣＥＦを介してデータを送信する場合、すべてのトリガの実行前に、ステップ５でＭＢＭＳサービス情報（ＴＭＧＩ）がグループに提供される。ある例では、ステップ１２はＴＭＧＩの送信に使用されない。ブロードの送信前にグループ内の各ＵＥを個別にアドレス指定することができれば、トリガは必要ないことは明らかである。

図６を参照する。一実施形態例によれば、ステップ１３でグループのメンバがアウェイク状態にあってブロードキャストをリスンしていることを確実にするために、ステップ７でＳＣＥＦは、認可リクエスト内の開始時と外部グループ識別子とをＨＳＳに提供する。開始時と外部グループ識別子とが認可リクエストに含まれている場合は、ＨＳＳは、グループ内のＵＥごとにインサートサブスクリプションデータ手順を開始して開始時をＭＭＥ／ＳＧＳＮに送信する。次いで、ＭＭＥ／ＳＧＳＮはこの情報を用いて、ブロードキャストの前にＵＥが確実に可用である（例えば、ＰＳＭおよび／または拡張アイドルモードＤＲＸを使用していない）ようにする。

このように、ＳＣＥＦは、グループメッセージ認可リクエストにおいて、ブロードキャストの開始時をＨＳＳに送信する。ＨＳＳは、グループメッセージ認可リクエストにおいて、ＳＣＥＦからブロードキャスト開始時を受信する。ＨＳＳは、ＵＥグループがブロードキャストの開始時を受信できるようにＵＥグループの加入データを修正することをサポートする。一例では、グループ内のＵＥ毎に、ＨＳＳはブロードキャストの開始時をＭＭＥに送信する。つまり、ＭＭＥはＵＥ毎にブロードキャストの開始時を受信する。ＭＭＥは、受信したブロードキャストの開始時に基づいて各ＵＥのＭＭコンテキストを修正する。

さらに、他の例によれば、ブロードキャストの地理的領域がＨＳＳとＭＭＥとに提供される。ＭＭＥが、ブロードキャストが行われようとしている地理的領域の一部でない場合は、ＨＳＳは開始時をＭＭＥに提供していないことがわかる、またはＨＳＳが該地理的領域をＭＭＥに提供しているが、ブロードキャストがＵＥの地理的領域に届こうとしていない場合、ＭＭＥはＵＥが省電力機能を用いることを防いでいないことがわかる。

前述の概念が、ＮＦＶに基づく５Ｇ ＭＣＮアーキテクチャに適用された実施形態例を考える。この場合、ＳＣＥＦはＡＰＩを開示するＮＦとして実装され、このＡＰＩにより、サードパーティサーバが特定ＵＥに送信するデータを有していることを、該サーバがＭＣＮに通知可能にする。あるいは、ＡＰＩを開示するノードが他のＮＦのこともある。ＵＥが、ＮＧ＿ＰＯＷＥＲ－ＳＡＶＩＮＧ状態などの、５Ｇ省電力状態を用いている場合、ＡＰＩは、サードパーティサーバに、該サードパーティサーバがＵＥへのデータ送信を欲していることをＭＣＮに通知させる。ＭＣＮは、データがサードパーティサーバでバッファされているので、ＵＥはＮＧ＿ＰＯＷＥＲ－ＳＡＶＩＮＧ状態またはＲＲＣ低エネルギ状態を離脱する必要があることをＵＥに通知する。

場合によっては、ＵＥがＮＧ＿ＰＯＷＥＲ－ＳＡＶＩＮＧ状態にいる場合、ＵＥは定期的にＮＧ＿ＰＯＷＥＲ－ＳＡＶＩＮＧ状態を離脱してページングについてネットワークにリスンするか、またはネットワークに関する手順（例えば、ＴＡＵに類似の手順）を実行して、ＵＥが一時的に接続可能であることをＭＣＮに知らせると考えられる。ＭＣＮはこの機会を利用してＵＥをページングして、サードパーティのデータをバッファできるようにするか、またはＵＥのメッセージ（例えば、ＴＡＵメッセージ）に応答してデータがＵＥ向けにサードパーティサーバにバッファされていることをＵＥに通知することができるようにする。このＭＣＮによるページングまたはバッファされたデータの通知により、ＵＥはＮＧ＿ＰＯＷＥＲ－ＳＡＶＩＮＧ状態に戻ることができない。

ＵＥがＲＲＣ低エネルギ状態にいる場合、ＵＥは定期的にページングについてネットワークにリスンするか、またはネットワークに関する手順（例えば、ＴＡＵに類似の手順）を実行して、ＵＥが一時的に接続可能であることをＭＣＮに知らせると考えられる。ＭＣＮはこの機会を利用してＵＥをページングして、サードパーティのデータをバッファできるようにするか、またはＵＥのメッセージ（すなわち、ＴＡＵメッセージ）に応答してデータがＵＥ向けにサードパーティサーバにバッファされていることをＵＥに通知することができるようにする。このＭＣＮによるページングまたはバッファされたデータの通知により、ＵＥはＲＲＣ低エネルギ状態を離脱する。

一例では、ＵＥのページングと、データがＵＥ向けにバッファされているという通知の送信とを開始するＭＣＮネットワーク機能は、モビリティまたはセッション管理ネットワーク機能である。ＵＥ宛のデータ転送が保留されているということと、ＵＥが省電力モードまたは状態を用いるように指示されるべきではないということを、ＮＦがコアネットワークアンカーポイントに通知することもある。ＵＥ宛のデータ転送が保留されているということと、ＵＥが省電力モードを用いないように明確に指示されるべきであるということを、ＮＦがコアネットワークアンカーポイントに通知することもある。ＵＥは省電力モードまたは状態の使用を禁止されることもある。コアネットワークアンカーポイントはこの情報をＲＡＮに送る。あるいは、ＮＦが直接ＲＡＮに伝える。

ＭＭ ＮＦが、ＵＥはダウンリンクデータの受信に可用であるとの通知をＳＣＥＦ ＮＦに送信することもある。次いでＳＣＥＦはこの通知をサードパーティサーバに転送する。これによりサードパーティサーバは自身のバッファデータを送信可能になる。

５Ｇのバックグラウンドデータ転送について考える。５Ｇ ＭＣＮはポリシエンジンＮＦを含む。ＳＣＥＦ ＮＦがＡＰＩを開示し、これによりサードパーティサーバはＭＣＮを用いた特定ＵＥ向けのバックグラウンドデータ転送をスケジュールする。ＳＣＥＦは、バックグラウンドデータ転送のリクエストをポリシエンジンＮＦとＭＭまたはＳＭ ＮＦとに転送する。ＳＣＥＦは、ポリシエンジンＮＦとＭＭまたはＳＭ ＮＦとの両方からの情報を用いてバックグラウンドデータ転送のスケジュールに最適な時間を決定する。例えば、ポリシエンジンＮＦは、バックグラウンドデータを実行すべき時の時間ウィンドウをＳＣＥＦに示す。ポリシエンジンからの時間ウィンドウは、ＵＥに関連するＭＣＮまたはＲＡＴが最も輻輳していないと予想される時に基づいている。次いでＳＣＥＦは、ＭＭまたはＳＭ ＮＦと通信して、ポリシエンジンＮＦから提供された時間ウィンドウ内でＵＥがＭＴ通信に可用になる時を決定する。例えば、ＳＣＥＦはＭＭまたはＳＭと通信して、ＵＥが省電力状態またはモードでなくなる時を決定する。

前述の概念をＷｉＦｉに適用した実施形態例を考える。図１０に、ＳＣＥＦ１００２をＷｉＦｉネットワーク１００１と合わせて展開する方法の一例を示す。図に示すように、ネットワーク１００１は、１つ以上のアクセスポイント（ＡＰ）１００８を介してワイヤレスＬＡＮコントローラ（Wireless LAN Controller：ＷＬＣ）１００６と通信する、１つ以上のＷｉＦｉステーション（ＳＴＡ）１００４を含む。図１０に示したＳＴＡ１００４はセルラ機能のＵＥであってもなくてもよい。図１０のＷＬＣ１００６とＷｉＦｉ ＡＰ１００８とは、トラステッドまたはアントラステッドＷｉＦｉネットワーク１００１を表す。トラステッドとアントラステッドとは、モバイルネットワークオペレータとのネットワーク関係を指す。

図１０を参照する。ＳＣＥＦ１００２がＡＰＩ１０１０を開示し、これによりＳＣＳ／ＡＳ１０１２が所定のＳＴＡの省電力モードを設定する。例えば、ＡＰＩ１０１０は、ＳＣＳ／ＡＳ１０１２にＳＴＡ１００４の１つを（ＩＰアドレス、ＭＡＣアドレス、または外部識別子を介して）識別させ、ＳＴＡをスリープ状態にさせる所望の時間量を指定する。図１０に示す通り、ＳＣＥＦ１００２はＷＬＣへのインタフェース１０１４を有している。図１０において、このインタフェース１０１４はＳｗｔと称されている。ダイアメータプロトコルがインタフェース１０１４上で使用される。ＳＣＥＦ１００２がインタフェース１０１４を用いてＷＬＣ１００６に設定情報を提供する。この情報を用いて、ＳＴＡ１００４がスリープ状態になるビーコン間隔の数が決定される。また、ＡＰＩ１０１０は、ダウンリンクデータ中のどれだけのデータまたはどれだけのフレームがＷＬＣ１００６またはＡＰ１００４にバッファされるかを、ＳＣＳ／ＡＳ１０１２に設定させる。

場合により、ＳＣＥＦ１００２はさらに、前述したダウンリンクデータ配信リクエストＡＰＩなどのＡＰＩを開示する。このＡＰＩで提供される情報はＷＬＣ／ＡＰに送られ、この情報を用いて、ＳＴＡが例えば省電力モードを用いる必要はないことと、ＳＴＡの省電力モードは次の機会に終了する必要があることとが決定される。

ＩＭＳネットワークにおいて、図１０に示したＳＣＥＦ１００２のＷＬＣ１００６への接続と同様に、Ｓ－ＣＳＣＦはＷＬＣ１００６に接続される。Ｓ－ＣＳＣＦはＳｗｔインタフェース１０１４を用いて、ＳＴＡ１００４がＶｏＩＰフレームを交換する割合を設定する。これに応じて各ＳＴＡが設定され、それによりＳＴＡ１００４がパケット交換の間にスリープ状態になることが可能になる。ＷＬＣ１００６はオプションのネットワークエレメントであり、ＳＣＥＦ１００２はＡＰ１００４に直接接続可能なことは明らかである。さらに、ＳＣＥＦ１００２はＷＬＣ１００６またはＡＰ１００８と統合可能なことは明らかである。

前述の通り、サードパーティアプリケーションサーバは、ＵＥまたはＳＴＡに転送するダウンリンクデータを有していることをＭＣＮに通知する。次いで、ＭＣＮは、ダウンリンクデータがＵＥまたはＳＴＡに送られるまで、ＵＥまたはＳＴＡが、Ｐｏｗｅｒ Ｓａｖｅ Ｍｏｄｅ、ＰＳＭ、および／またはｅＤＲＸなどの低電力モードを使用することを防ぐ。さらに、ネットワークはＵＥをページングして、ＵＥがＲＲＣ接続状態に入ってダウンリンクデータの受信準備が整うようにする。

ＵＥまたはＳＴＡが、データ転送が差し迫っているのでＰｏｗｅｒ Ｓａｖｅ Ｍｏｄｅ、ＰＳＭ、およびｅＤＲＸなどの省電力モードが許可されないことを通知されると、ＭＣＮは、低電力モードが許可されない理由ならびに許可されないでいる期間の通知をＵＥまたはＳＴＡに提供する。例えば、この通知は、ＵＥにデータを送信したいＡＳがあることと、低電力モードを一定時間（例えば、５分等）許可してはいけないこととを示している。ＵＥまたはＳＴＡがこのような通知を受けとると、図１１Ａに示したメッセージ例１１０２などのメッセージが表示される。

差し迫っているデータ転送を予期してＵＥがＲＲＣ接続状態に入るようにページングされると、ＭＣＮは、ＵＥがページングされた理由の通知をＵＥに提供する。例えば、この通知は、ＵＥにデータを送信したいＡＳがあることと、低電力モードは一定時間無効にする必要があることとを示している。ＵＥまたはＳＴＡがこのような通知を受信すると、図１１Ｂに示したメッセージ例１１０４などのメッセージが表示される。

図１１Ａ、１１ＢのＧＵＩ１１０２と１１０４とはそれぞれ例として示したものであり、これらＧＵＩを所望により構成して、所望により設定パラメータを観察および変更できるようにすることが可能なことは明らかである。また、所望によりこのユーザインタフェース例を用いて他のパラメータをモニタして制御することができることは明らかである。さらに、ＧＵＩは、ユーザが様々な図表や他の視覚表現を通じて興味を抱く種々の情報をユーザに提供することができることは明らかである。

図１２Ａは、本開示の１つ以上の実施形態が実施される、マシンツーマシン（Machine-to-Machine：Ｍ２Ｍ）、モノのインターネット（Internet of Things：ＩｏＴ）、またはモノのＷｅｂ（Web of Things：ＷｏＴ）通信システム１０の一例の図である。一般に、Ｍ２Ｍ技術によりＩｏＴ／ＷｏＴの構成要素が提供され、あらゆるＭ２Ｍデバイス、Ｍ２Ｍゲートウェイ、またはＭ２Ｍサービスプラットフォームが、ＩｏＴ／ＷｏＴならびにＩｏＴ／ＷｏＴサービスレイヤ等の構成要素になり得る。図８－１０のいずれかに示されたいずれのデバイス、機能、ノード、またはネットワークも、図１２Ａ、１２Ｂに示したような通信システムのノードを含む。

図１２Ａに示す通り、Ｍ２Ｍ／ＩｏＴ／ＷｏＴ通信システム１０は通信ネットワーク１２を含む。通信ネットワーク１２は、固定ネットワーク（例えば、イーサネット、Ｆｉｂｅｒ、ＩＳＤＮ、ＰＬＣなど）、ワイヤレスネットワーク（例えば、ＷＬＡＮ、セルラなど）、または異機種ネットワークにおける１ネットワークである。例えば、通信ネットワーク１２は、音声、データ、映像、メッセージング、ブロードキャストなどのコンテンツを複数ユーザに提供する、多元接続ネットワークからなる。例えば、通信ネットワーク１２は、符号分割多重アクセス（Code Division Multiple Access：ＣＤＭＡ）、時分割多重アクセス（Time Division Multiple Access：ＴＤＭＡ）、周波数分割多重アクセス（Frequency Division Multiple Access：ＦＤＭＡ）、直交ＦＤＭＡ（Orthogonal FDMA：ＯＦＤＭＡ）、シングルキャリアＦＤＭＡ（Single-Carrier FDMA：ＳＣ－ＦＤＭＡ）などの、１つ以上のチャネルアクセス方法を用いている。さらに、通信ネットワーク１２の例として、コアネットワーク、イーサネット、センサネットワーク、工業制御ネットワーク、パーソナルエリアネットワーク、フューズドパーソナルネットワーク、衛星ネットワーク、ホームネットワーク、または企業ネットワークがある。

図１２Ａに示す通り、Ｍ２Ｍ／ＩｏＴ／ＷｏＴ通信システム１０はインフラストラクチャドメインとフィールドドメインとを含む。インフラストラクチャドメインとはエンドツーエンドのＭ２Ｍデプロイメントのネットワーク側を指し、フィールドドメインとは、通常はＭ２Ｍゲートウェイの背後の、エリアネットワークを指す。フィールドドメインとインフラストラクチャドメインとは共にネットワークの種々の異なるノード（例えば、サーバ、ゲートウェイ、デバイスなど）からなる。例えば、フィールドドメインはＭ２Ｍゲートウェイ１４と端末デバイス１８とを含む。任意の数のＭ２Ｍゲートウェイ１４とＭ２Ｍ端末デバイス１８とが所望によりＭ２Ｍ／ＩｏＴ／ＷｏＴ通信システム１０に含まれ得ることは明らかである。Ｍ２Ｍゲートウェイ１４とＭ２Ｍ端末デバイス１８とのそれぞれは、通信ネットワーク１２またはダイレクト無線リンクを介して信号を送受信するように構成されている。Ｍ２Ｍゲートウェイ１４は、ワイヤレスＭ２Ｍデバイス（例えば、セルラと非セルラ）ならびに固定ネットワークＭ２Ｍデバイス（例えば、ＰＬＣ）をそれぞれ、通信ネットワーク１２やダイレクト無線リンクなどのオペレータネットワークを通じて通信される。例えば、Ｍ２Ｍデバイス１８はデータを収集して、そのデータを通信ネットワーク１２やダイレクト無線リンクを介して、Ｍ２Ｍアプリケーション２０またはＭ２Ｍデバイス１８に送る。また、Ｍ２Ｍデバイス１８は、Ｍ２Ｍアプリケーション２０またはＭ２Ｍデバイス１８からデータを受け取る。さらに、後述の通り、データと信号とはＭ２Ｍサービスレイヤ２２を介してＭ２Ｍアプリケーション２０との間で送受信される。Ｍ２Ｍデバイス１８とゲートウェイ１４とは、例えば、セルラ、ＷＬＡＮ、ＷＰＡＮ（例えば、ジグビー、６ＬｏＷＰＡＮ、ブルートゥースなど）、ダイレクト無線リンク、有線ネットワークなどの、種々のネットワークを通じて通信する。Ｍ２Ｍデバイスの例として、限定はしないが、タブレット、スマートフォン、医療機器、温度と天候モニタ、コネクテッドカー、スマートメータ、ゲーム機携帯端末、健康とフィットネスモニタ、照明、サーモスタット、家庭用器具、ガレージドアその他のアクチュエータベースのデバイス、セキュリティデバイス、およびスマートアウトレットとがある。

図１２Ｂを参照する。図示のフィールドドメインにおけるＭ２Ｍサービスレイヤ２２は、Ｍ２Ｍアプリケーション２０、Ｍ２Ｍゲートウェイ１４と、Ｍ２Ｍ端末デバイス１８と、通信ネットワーク１２とにサービスを提供する。Ｍ２Ｍサービスレイヤ２２は、所望により、任意の数のＭ２Ｍアプリケーション、Ｍ２Ｍゲートウェイ１４、Ｍ２Ｍ端末デバイス１８、および通信ネットワーク１２と通信する。Ｍ２Ｍサービスレイヤ２２は、１つ以上のサーバ、コンピュータ等により具現される。Ｍ２Ｍサービスレイヤ２２は、Ｍ２Ｍ端末デバイス１８と、Ｍ２Ｍゲートウェイ１４と、Ｍ２Ｍアプリケーション２０とに付与するサービス機能を提供する。Ｍ２Ｍサービスレイヤ２２の諸機能は、例えば、セルラコアネットワーク内またはクラウド内のウェブサーバ等の、種々の形で具現される。

図示のＭ２Ｍサービスレイヤ２２と同様に、インフラストラクチャドメインにＭ２Ｍサービスレイヤ２２'がある。Ｍ２Ｍサービスレイヤ２２'は、インフラストラクチャドメイン内のＭ２Ｍアプリケーション２０'と下位の通信ネットワーク１２'とにサービスを提供する。また、Ｍ２Ｍサービスレイヤ２２'は、フィールドドメイン内のＭ２Ｍゲートウェイ１４とＭ２Ｍ端末デバイス１８とにサービスを提供する。Ｍ２Ｍサービスレイヤ２２'は、任意の数のＭ２Ｍアプリケーション、Ｍ２Ｍゲートウェイデバイス、およびＭ２Ｍ端末デバイスと通信する。Ｍ２Ｍサービスレイヤ２２'は、異なるサービスプロバイダによってサービスレイヤと交信する。Ｍ２Ｍサービスレイヤ２２'は、１つ以上のサーバ、コンピュータ、仮想マシン（例えば、クラウド／コンピュータ／ストレージファームなど）などによって具現される。

さらに図１２Ｂを参照する。Ｍ２Ｍサービスレイヤ２２および２２'は、様々なアプリケーションや産業分野で使用可能なサービス配信機能のコアセットを提供する。これらのサービス機能により、Ｍ２Ｍアプリケーション２０および２０'がデバイスと交信して、データ収集、データ解析、デバイス管理、セキュリティ、ビリング、サービス発見とデバイス発見等の機能を果たすことが可能になる。基本的に、これらのサービス機能により上記アプリケーションはこれら機能の具現という負荷から解放され、それによりアプリケーション開発が簡単になると共に、コスト低減ならびに市場投入時間の短縮が図れる。サービスレイヤ２２および２２'もまた、これらサービスレイヤ２２および２２'が提供するサービスに関連した種々のネットワーク１２および１２'を通じてＭ２Ｍアプリケーション２０および２０'が通信することを可能にする。

Ｍ２Ｍアプリケーション２０および２０'として、限定はしないが、運輸、健康保健、コネクテッドホーム、エネルギ管理、資産管理、セキュリティならびにサーベイランスなどの様々な産業におけるアプリケーションがある。前述のように、システムのデバイス、ゲートウェイ、その他のサーバ全体にわたる、Ｍ２Ｍサービスレイヤは、例えば、データ収集、デバイス管理、セキュリティ、ビリング、位置追尾とジオフェンシング、デバイス発見とサービス発見、レガシーシステム統合等の機能をサポートして、これらの機能をサービスとしてＭ２Ｍアプリケーション２０および２０'に提供する。

一般に、図１２Ａおよび１２Ｂに示したサービスレイヤ２２および２２'などの、サービスレイヤ（Service Layer：ＳＬ）は、一群のアプリケーションプログラミングインターフェース（Application Programming Interface：ＡＰＩ）と下層のネットワークインタフェースとを通じて、付加価値サービス機能をサポートするソフトウェアミドルウェアレイヤを定義している。ＥＴＳＩ Ｍ２ＭアーキテクチャとｏｎｅＭ２Ｍアーキテクチャとはそれぞれサービスレイヤを定義している。ＥＴＳＩ Ｍ２Ｍのサービスレイヤはサービス機能レイヤ（Service Capability Layer：ＳＣＬ）と呼ばれる。ＳＣＬは、ＥＴＳＩ Ｍ２Ｍアーキテクチャの種々の異なるノードで実装される。例えば、サービスレイヤのインスタンスは、Ｍ２Ｍデバイス（ここではデバイスＳＣＬ（Device SCL：ＤＳＣＬ）と呼ばれる）、ゲートウェイ（ここではゲートウェイＳＣＬ（Gateway SCL：ＧＳＣＬ）と呼ばれる）、および／またはネットワークノード（ここではネットワークＳＣＬ（Network SCL：ＮＳＣＬ）と呼ばれる）内で実装される。ｏｎｅＭ２Ｍサービスレイヤは、一群の共通サービスファンクション（Common Service Function：ＣＳＦ）（すなわち、サービス機能）をサポートしている。一群の１つ以上の特定タイプのＣＳＦのインスタンス化は共通サービスエンティティ（Common Services Entity：ＣＳＥ）と呼ばれ、このＣＳＥは、種々のタイプのネットワークノード（例えば、インフラストラクチャノード、ミドルノード、アプリケーション特定ノード）で動作し得る。第３世代パートナーシッププロジェクト（Third Generation Partnership Project：３ＧＰＰ）もまたマシン型通信（Machine-type Communications：ＭＴＣ）の構成を定義している。このアーキテクチャでは、サービスレイヤとそのサービスレイヤが提供するサービスとはサービス機能サーバ（ＳＣＳ）の一部として具現される。３ＧＰＰ ＭＴＣアーキテクチャのサービス機能サーバ（ＳＣＳ）において、ＥＴＳＩ Ｍ２ＭアーキテクチャのＤＳＣＬ、ＧＳＣＬ、またはＮＳＣＬ内、ｏｎｅＭ２ＭアーキテクチャのＣＳＦまたはＣＳＥ内、もしくはその他のネットワークのノード内のいずれに埋め込まれた場合でも、サービスレイヤのインスタンスは、ネットワーク内の１つ以上のスタンドアロンノードのいずれかで実行される論理エンティティ（例えば、ソフトウェア、コンピュータ実行可能な命令など）として具現される。スタンドアロンノードとしては、サーバ、コンピュータ、およびその他の演算装置またはノードなどがある。あるいは、該インスタンスは１つ以上の既存ノードの一部として具現される。一例として、サービスレイヤまたはその構成要素のインスタンスは、後述の図１２Ｃまたは１２Ｄに示した概略アーキテクチャを有する、ネットワークノード（例えば、サーバ、コンピュータ、ゲートウェイ、デバイスなど）上で走るソフトウェアの形で具現される。

さらに、本明細書で述べた方法と機能とは、サービス指向アーキテクチャ（Service Oriented Architecture：ＳＯＡ）および／またはリソース指向アーキテクチャ（Resource-oriented Architecture：ＲＯＡ）を用いて、例えば前述のネットワークとアプリケーション管理サービス（Network and Application Management Service）などの、サービスにアクセスするＭ２Ｍネットワークの一部として具現される。

図１２Ｃは、図１２Ａおよび１２Ｂに示したようなＭ２ＭネットワークにおけるＭ２Ｍサーバ、Ｍ２Ｍゲートウェイ、Ｍ２Ｍデバイス、または他のノードとして機能する、図８－１０に示したノード、デバイス、ファンクション、またはネットワークのいずれかなどの、ネットワークのノードのハードウェアまたはソフトウェアアーキテクチャの一例のブロック図である。図１２Ｃに示したように、ノード３０は、プロセッサ３２と、トランシーバ３４と、送受信素子３６と、スピーカならびにマイクロフォン３８と、キーパッド４０と、ディスプレイならびにタッチパッド４２と、ノンリムーバルメモリ４４と、リムーバルメモリ４６と、電源４８と、全地球測位システム（Global Positioning System：ＧＰＳ）チップセット５０と、他の周辺機器５２とを含む。ノード３０はさらに、トランシーバ３４や送受信素子３６などの、通信回路を含む。ノード３０は、実施形態に一致した状態を維持したまま、前述の部品の任意のサブコンビネーションを含むことはいうまでもない。このノードは、本明細書で述べたノードに関連する通知やトリガを具現するノードになり得る。

プロセッサ３２は、汎用プロセッサ、専用プロセッサ、従来型プロセッサ、デジタルシグナルプロセッサ（Digital Signal Processor：ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアに関連した１つ以上のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（Application Specific Integrated Circuit：ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（Field Programmable Gate Array：ＦＰＧＡ）回路、その他の種類の集積回路（Integrated Circuit：ＩＣ）、状態機械、などである。プロセッサ３２は、シグナルコーディング、データ処理、電力制御、入出力処理、および／またはワイヤレス環境でのノード３０の動作を可能にするその他の機能を実行する。プロセッサ３２はトランシーバ３４に接続され、トランシーバ３４は送受信素子３６に接続される。図１２Ｃはプロセッサ３２とトランシーバ３４とを独立した構成要素として示しているが、プロセッサ３２とトランシーバ３４とは電子パッケージまたはチップに統合可能なことは明らかである。プロセッサ３２は、アプリケーションレイヤプログラム（例えば、ブラウザ）、および／またはラジオアクセスレイヤ（Radio Access-layer：ＲＡＮ）プログラムおよび／または通信を実行する。プロセッサ３２は、例えばアクセスレイヤおよび／またはアプリケーションレイヤにおける、認証、セキュリティキーアグリーメント、および／または暗号化動作などのセキュリティ動作を行う。

図１２Ｃに示すように、プロセッサ３２は、当該通信回路（例えば、トランシーバ３４と送受信素子３６）に接続される。コンピュータ実行可能な命令の実行を通じて、プロセッサ３２は、ノード３０を、ノード３０が接続されているネットワークを介して他のノードと通信させるためにこの通信回路を制御する。特に、プロセッサ３２は、本明細書（例えば、図８－１０）ならびに請求の範囲で述べた送受信ステップを実行するために通信回路を制御する。図１２Ｃはプロセッサ３２とトランシーバ３４とを独立した構成要素として示しているが、プロセッサ３２とトランシーバ３４とは電子パッケージまたはチップに統合可能なことは明らかである。

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

さらに、図１２Ｃには送受信素子３６は単一の素子として示されているが、ノード３０は任意の数の送受信素子３６を含み得る。より詳細には、ノード３０はＭＩＭＯ技術を用いたものである。すなわち、ある実施形態では、ノード３０は、無線信号の送受信用に２つ以上の送受信素子３６（例えば、多重アンテナ）を備えている。

トランシーバ３４は、送受信素子３６から送信されることになっている信号を変調し、送受信素子３６に受信される信号を復調するように構成される。前述のように、ノード３０はマルチモードの機能を有している。したがって、トランシーバ３４は、ノード３０が、例えばＵＴＲＡやＩＥＥＥ ８０２．１１などの、複数のＲＡＴを介して通信できるように、複数のトランシーバを含んでいる。

プロセッサ３２は、ノンリムーバルメモリ４４および／またはリムーバルメモリ４６などの、任意の種類の適当なメモリから情報を呼び出すと共にそのメモリにデータを保存する。ノンリムーバルメモリ４４として、ランダムアクセスメモリ（Random-access Memory：ＲＡＭ）、読み出し専用メモリ（Read-only Memory：ＲＯＭ）、ハードディスク、その他の種類の記憶装置などがある。リムーバルメモリ４６として、加入者識別モジュール（Subscriber Identity Module：ＳＩＭ）カード、メモリスティック、セキュアデジタル（Secure Digital：ＳＤ）メモリカードなどがある。他の実施形態では、プロセッサ３２は、サーバやホームコンピュータに位置するメモリなどの、物理的にノード３０に位置していないメモリから情報を呼び出すと共にそのメモリにデータを保存する。プロセッサ３２は、ノードの状態を反映するようにディスプレイまたは表示器４２における照明パターン、画像、または色を調整し、ＵＥ（例えば、図１３－１６）と通信するようにノード、特に下層のネットワーク、アプリケーション、またはＵＥと通信している他のサービス、を設定する。プロセッサ３２は、電源４８から電力を受けて、その電力をノード３０の他の構成要素に配電および／または調整する。電源４８は、ノード３０に電力供給する任意の適当なデバイスからなる。例えば、電源４８は、１つ以上の乾電池（例えば、ニッケル－カドミウム（ＮｉＣｄ）、ニッケル－亜鉛（ＮｉＺｎ）、ニッケルメタルハイドライド（ＮｉＭＨ）、リチウムイオン（Ｌｉ－ｉｏｎ）など）、太陽電池、燃料電池、などである。

また、プロセッサ３２はＧＰＳチップセット５０に接続される。ＧＰＳチップセットは、ノード３０の現在位置に関する位置情報（例えば、経度や緯度）を提供するように構成されている。ノード３０は、実施形態に一致した状態を維持したまま、適当な位置決定法を用いて位置情報を取得し得ることは明らかである。

プロセッサ３２はさらに他の周辺機器５２に接続される。周辺機器５２は、１つ以上のソフトウェアおよび／またはハードウェアモジュールを含んでおり、これらにより付加的な特徴、機能、および／または有線または無線のコネクティビティがもたらされる。例えば、周辺機器５２として、加速度計やバイオメトリクス（例えば、指紋）センサなどの種々のセンサ、電子コンパス、衛星トランシーバ、デジタルカメラ（写真または映像用）、ユニバーサルシリアルバス（Universal Serial Bus：ＵＳＢ）ポートその他の相互接続デバイス、震動装置、テレビジョントランシーバ、ハンズフリーヘッドセット、ブルートゥース（登録商標）モジュール、周波数変調（Frequency Modulated：ＦＭ）ラジオユニット、デジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザなどがある。

図１２Ｄは、コンピュータシステム９０の一例のブロック図である。このシステムを用いることによっても、図１２Ａおよび１２Ｂに示したような、Ｍ２ＭネットワークにおけるＭ２Ｍサーバ、ゲートウェイ、デバイス、または他のノードとして機能する、図８－１０に示したノード、デバイス、ファンクション、またはネットワークなどの、ネットワークの１つ以上のノードが実現される。コンピュータシステム９０はコンピュータまたはサーバを含み、主としてコンピュータ読取可能な、ソフトウェア形式の命令によって制御される。この制御は、如何なる場所であっても、または如何なる手段によっても、このようなソフトウェアが保存またはアクセスされる場合に行われ得る。このようなコンピュータ読取可能な命令は中央演算装置（Central Processing Unit：ＣＰＵ）９１内で実行され、それによりコンピュータシステム９０が動作する。多くの公知のワークステーションと、サーバと、パーソナルコンピュータとにおいて、中央演算装置９１は、マイクロプロセッサと呼ばれるシングルチップＣＰＵによって実現される。他の装置では、中央演算装置９１は複数のプロセッサを含む。コプロセッサ８１は、メインのＣＰＵ９１とは異なるオプションのプロセッサであり、付加的な機能を果たすか、またはＣＰＵ９１を支援する。ＣＰＵ９１および／またはコプロセッサ８１は、機密保持のために、開示されたシステムや方法に関するデータを受信、生成、および処理する。

動作時には、ＣＰＵ９１は、命令をフェッチ、デコード、および実行して、コンピュータのメインのデータ伝送経路であるシステムバス８０を介して他のリソースとの間で情報を伝送し合う。このシステムバスによりコンピュータシステム９０内の構成要素が接続され、データ交換用の媒体が規定される。通常システムバス８０は、データ送信用データラインと、アドレス送信用アドレスラインと、割り込み送信およびシステムバス操作用制御ラインとを含む。このようなシステムバス８０の例としてペリフェラルコンポーネントインターコネクト（Peripheral Component Interconnect：ＰＣＩ）バスがある。

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

さらに、コンピュータシステム９０は、ＣＰＵ９１からプリンタ９４、キーボード８４、マウス９５、ディスクドライブ８５などの周辺機器への命令の通信に関与する周辺機器コントローラ８３を含む。

ディスプレイコントローラ９６に制御されるディスプレイ８６を用いてコンピュータシステム９０からの画像出力が表示される。この画像出力は、テキストと、グラフィックスと、動画グラフィックスと、映像とを含む。ディスプレイ８６は、ＣＲＴ系ビデオディスプレイ、ＬＣＤ系フラットパネルディスプレイ、ガスプラズマ系フラットパネルディスプレイ、またはタッチパネルを備えて実現される。ディスプレイコントローラ９６は、ディスプレイ８６に送信されるビデオ信号の生成に必要な電子部品を含む。

さらに、コンピュータシステム９０は、例えばネットワークアダプタ９７などの通信回路を含む。ネットワークアダプタ９７を用いて、コンピュータシステム９０を，図１２Ａおよび１２Ｂのネットワーク１２などの、外部通信ネットワークに接続することによりコンピュータシステム９０とネットワークの他のノードとの通信を可能にする。この通信回路を単独またはＣＰＵ９１と組み合わせて用いることで本明細書（例えば、図８－１０）と請求の範囲とで述べた送受信ステップが実行される。

各図に示した、本開示の内容の好適な実施形態の説明において、明示のために特定の専門用語を用いた。しかしながら、本特許請求された内容は上記選択された特定の専門用語に限定されるものではなく、それぞれ個別の構成要素は、同様に動作して同様の目的を達成するすべての技術的同等物を包含するものであることは明らかである。

下記は、以上の説明に見られたサービスレベル技術に関する頭字語のリストである。

Claims (9)

1. プロセッサと、メモリと、通信回路とを備えた装置であって、前記装置は前記通信回路を介してネットワークに接続され、前記装置の前記メモリに保存されたコンピュータ実行可能な命令を含み、前記命令が前記装置の前記プロセッサにより実行されたとき、
   サードパーティサーバからのデータ転送時にデータの受信者になる少なくとも１つのユーザ装置（User Equipment：ＵＥ）を通知し、さらに前記サードパーティサーバが前記データ転送を行いたい時を通知する第１メッセージを受信し、
   前記第１メッセージに基づき、前記少なくとも１つのＵＥが前記データ転送に備えてアウェイク状態であることを保証するアクションを行う、
   ことを含む動作を前記装置に行わせ、
   前記アウェイク状態であることを保証するアクションは、前記少なくとも１つのＵＥが通信を行う基地局に、前記ＵＥのＲＲＣ接続を維持すべきことと、前記アウェイク状態に関するタイマと、を含む通知を行うことを含む、
   ことを特徴とする装置。
2. 前記装置は、コンピュータ実行可能な命令を含み、前記命令が前記装置の前記プロセッサにより実行されたとき、さらに
   少なくとも１つのユーザ装置に関連する転送ポリシを受信することを含む動作を前記装置に行わせて、前記アクションを前記転送ポリシにも基づいたものとする、請求項１に記載の装置。
3. 前記少なくとも１つのユーザ装置はユーザ装置のグループからなり、前記アクションは、前記グループの各ＵＥが同時に前記データ転送に備えてアウェイク状態であることを保証する、請求項１に記載の装置。
4. 前記アクションの実行は、時間ウィンドウをｅＮｏｄｅＢに提供することを含み、前記時間ウィンドウは、前記少なくとも１つのＵＥのＲＲＣ接続をどれだけ長く維持するべきかを通知するものである、請求項１に記載の装置。
5. 前記アクションの実行は、前記第１メッセージ内の時間ウィンドウが経過するまで、前記少なくとも１つのＵＥが省電力モード（Power Savings Mode：ＰＳＭ）または拡張アイドルモード間欠受信（Extended Idle Mode Discontinuous Reception：ｅＤＲＸ）に入ることを防ぐことを含む、請求項１に記載の装置。
6. 前記少なくとも１つのＵＥが前記ＰＳＭまたはｅＤＲＸに入ることを防ぐことは、トラッキングエリアアップデート時に前記少なくとも１つのＵＥから提示されるタイマ値を拒絶することを含む、請求項５に記載の装置。
7. 前記少なくとも１つのＵＥが前記ＰＳＭまたはｅＤＲＸに入ることを防ぐことは、前記データ転送が行われる時に前記少なくとも１つのＵＥがアウェイク状態であるように、前記少なくとも１つのＵＥに関連するタイマと前記少なくとも１つのＵＥに関連するトラッキングエリアアップデートタイマとを調整することを含む、請求項５に記載の装置。
8. 前記アクションの実行は、第２メッセージを前記ネットワーク内の無線アクセスノードに送信することを含み、前記第２メッセージは、前記少なくとも１つのＵＥのページングリクエストを含む、請求項１に記載の装置。
9. ネットワーク装置が実行する無線通信方法であって、
   サードパーティサーバからのデータ転送時にデータの受信者になる少なくとも１つのユーザ装置（User Equipment：ＵＥ）を通知し、さらに前記サードパーティサーバが前記データ転送を行いたい時を通知する第１メッセージを受信するステップと、
   前記第１メッセージに基づき、前記少なくとも１つのＵＥが前記データ転送に備えてアウェイク状態であることを保証するアクションを行うステップと、を含み、
   前記アウェイク状態であることを保証するアクションは、前記少なくとも１つのＵＥが通信を行う基地局に、前記ＵＥのＲＲＣ接続を維持すべきことと、前記アウェイク状態に関するタイマと、を含む通知を行うことを含む、
   無線通信方法。

Images