JP6670926B2 - ユーザ機器のためのモバイルコアネットワークサービスエクスポージャ - Google Patents

Description

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

第３世代パートナーシッププロジェクト（３ＧＰＰ）は、電気通信協会のグループ間の協力であり、無線、コアネットワーク、およびサービスアーキテクチャを包含する。３ＧＰＰは、参考文献３ＧＰＰ ＴＳ ２３．６８２「Ａｒｃｈｉｔｅｃｔｕｒｅ ｅｎｈａｎｃｅｍｅｎｔｓ ｔｏ ｆａｃｉｌｉｔａｔｅ ｃｏｍｍｕｎｉｃａｔｉｏｎｓ ｗｉｔｈ ｐａｃｋｅｔ ｄａｔａ ｎｅｔｗｏｒｋｓ ａｎｄ ａｐｐｌｉｃａｔｉｏｎｓ」の中でサービス能力エクスポージャ機能（ＳＣＥＦ）を定義する。図１は、この参考文献から複製され、ＳＣＥＦ１０２のアーキテクチャを示す。

サービス能力エクスポージャ機能（ＳＣＥＦ）１０２は、３ＧＰＰネットワークによって提供されるサービスおよび能力をセキュアにエクスポーズする手段を提供する。ＳＣＥＦ１０２は、エクスポーズされたサービス能力の発見のための手段を提供する。ＳＣＥＦ１０２は、Ｏｐｅｎ Ｍｏｂｉｌｅ Ａｌｌｉａｎｃｅ（ＯＭＡ）、Ｇｒｏｕｐ Ｓｐｅｃｉａｌｅ Ｍｏｂｉｌｅ Ａｓｓｏｃｉａｔｉｏｎ（ＧＳＭＡ）、およびおそらく他のシグナリング局団体によって定義される同種のネットワークアプリケーションプログラミングインターフェース（例えば、ネットワークＡＰＩ）を通して、ネットワーク能力へのアクセスを提供する。ＳＣＥＦ１０２は、下層３ＧＰＰネットワークインターフェースおよびプロトコルからサービスを抽象化する。ＳＣＥＦ１０２の個々のインスタンスは、どのようなサービス能力がエクスポーズされるか、およびどのようなアプリケーションプロトコルインターフェース（ＡＰＩ）特徴がサポートされるかに応じて、変動し得る。ＳＣＥＦ１０２は、常に、信頼ドメイン内にある。アプリケーションは、信頼ドメインに属することができるか、または信頼ドメインの外側に位置し得る。

参考文献Ｓ２−１５１４２６「Ｓｏｌｕｔｉｏｎ Ｕｐｄａｔｅ ｆｏｒ Ｂａｃｋｇｒｏｕｎｄ Ｄａｔａ Ｔｒａｎｓｆｅｒ，Ｈｕａｗｅｉ，ＨｉＳｉｌｉｃｏｎ，ＮＴＴ Ｄｏｃｏｍｏ，Ａｐｒｉｌ １３−１７，２０１５」は、アプリケーションサーバ／サービス能力サーバ（ＡＳ／ＳＣＳ）がネットワークとのバックグラウンドデータ転送をスケジュールすることを可能にするための３ＧＰＰのソリューションを説明する。この参考文献で説明されるアプローチは、ＡＳ／ＳＣＳがポリシおよび課金規則機能（ＰＣＲＦ）１０４とのデータ転送をスケジュールすることを可能にする。ＰＣＲＦ１０４は、データ転送を開始すべきときをＡＳ／ＳＣＳに知らせることができる。図２の以下の説明は、参考文献Ｓ２−１５１４２６からの出典である。

このアプローチでは、本地理的地域にサービス提供するネットワーク内の利用可能なＰＣＲＦ１０４のうちのいずれかが、非ローミングユーザ機器（ＵＥ）のためのバックグラウンドデータ転送のための転送ポリシについて決定を行うことができる。

このアプローチでは、バックグラウンドデータ転送のために標的にされるＵＥは、単一のＰＣＲＦ１０４によってサービス提供され得るか、または同一もしくは異なる地理的地域にサービス提供する複数のＰＣＲＦに広められ得る。

転送ポリシは、最終的に、要求のトランザクション参照付与承認と一緒に、サブスクリプションプロファイルリポジトリ（ＳＰＲ）２０４の中に記憶される。これは、転送ポリシが、将来的にこのバックグラウンドデータ転送を受けるＵＥに責任がある全ＰＣＲＦに利用可能であることを確実にする。加えて、他の（または同一の）ＰＣＲＦは、他のＡＳに関連するバックグラウンドデータのための転送ポリシについての後の決定中、この転送ポリシを考慮することができる。

ＡＳ２０２が後の時点で（既存のＲｘインターフェースを介して）個々のＵＥのためのＰＣＲＦ１０４にコンタクトするとき、ＡＳ２０２は、参照を提供する必要もある。参照は、ポリシおよび課金規則機能（ＰＣＲＦ）１０４が、（ＵＥに関連する）ＡＳ２０２要求を（ＡＳに関連する）ＳＰＲ２０４から読み出される転送ポリシと互いに関係づけることを可能にする。ＰＣＲＦ１０４は、最終的に、３ＧＰＰ ＴＳ ２３．２０３に従ってポリシおよび課金制御（ＰＣＣ）プロシージャをトリガし、それぞれのポリシングおよび課金情報をポリシおよび課金実施機能（ＰＣＥＦ）２０６に提供する。

ＡＳ２０２は、典型的には、バックグラウンドデータ転送のためのスポンサ付き接続性を要求するために、個々のＵＥのためのＰＣＲＦ１０４にコンタクトするであろう。

図２のステップ１では、第三者ＡＳ２０２は、ＵＥの組のためのバックグラウンドデータ転送に対する要求をＳＣＥＦ１０２に送信し得る。バックグラウンドデータ転送要求メッセージは、アプリケーション情報と、トラフィック情報（例えば、ＵＥ当たり送信されるデータの量およびＵＥの予期される数）と、所望の時間窓と、随意に、地理的地域情報とを含む。アプリケーションサーバ（ＡＳ）は、ＵＥの識別についていかなる情報も提供しない。

図２のステップ２では、ＳＣＥＦ１０２は、ＡＳ要求を認可する。ＳＣＥＦ１０２は、認可が失敗した場合、この時点でＡＳ２０２に通知する。

図２のステップ３では、ＳＣＥＦ１０２は、利用可能なＰＣＲＦのうちのいずれかを選択し、ＡＳによって提供されるパラメータを含むバックグラウンドデータ転送要求をＰＣＲＦ１０４に送信する。ＡＳ２０２が地理的地域情報を提供した場合、ＳＣＥＦ１０２は、地理的地域を対応するネットワークエリア（例えば、セルＩＤ、ＴＡ／ＲＡのリスト）に転送する。この要求が所与のＵＥのＩＰ−ＣＡＮセッションに特定ではないので、新しいインターフェースが、ＡＳ２０２とＰＣＲＦ１０４との間の情報交換のために、ＳＣＥＦ１０２とＰＣＲＦ１０４との間の相互作用のために導入される。

図２のステップ４では、ＰＣＲＦ１０４は、（ステップ３での要求に同等であり得る）全ての既存の転送ポリシに対してＳＰＲ２０４にクエリを行う。

図２のステップ５では、ＰＣＲＦ１０４は、ＡＳ２０２によって提供される情報および他の情報（例えば、ネットワークポリシ、輻輳レベル（入手可能である場合）、要求される時間窓およびネットワークエリアの負荷ステータス推定、既存の転送ポリシ）に基づいて、ＡＳデータ転送のための１つ以上の推奨時間窓を決定する。各時間窓のために、ＰＣＲＦ１０４は、随意に、ＵＥの組のための最大総ビットレートと、最大総ビットレート未満にとどまるトラフィックのためのそれぞれの時間窓において適用可能であろう課金率とを割り当てる。ＰＣＲＦ１０４からＳＣＥＦ１０２／ＡＳ２０２に提供される最大総ビットレートは、ネットワーク内で実施されない。

図２のステップ６では、ＰＣＲＦ１０４は、承認された付与を識別する参照ＩＤ、および転送ポリシオファーでＳＣＥＦ１０２に応答し、転送ポリシオファーは、データ転送のための１つ以上の推奨時間窓と、随意に、各時間窓に対するＵＥの組のための最大総ビットレートと、課金率とを含む。

図２のステップ７では、ＳＣＥＦ１０２は、参照ＩＤおよび転送ポリシオファーを第三者ＡＳに転送する。ＡＳは、ＰＣＲＦ１０４との将来の相互作用のために参照ＩＤを記憶する。

図２のステップ８−１１では、転送ポリシオファーが２つ以上の時間窓を含む場合、第三者ＡＳは、時間窓のうちの１つを選択し、それについてＳＣＥＦ１０２およびＰＣＲＦ１０４に知らせるために、バックグラウンドデータ転送メッセージのための別の要求を送信するものとする。

転送ポリシオファーの中に１つのみの時間窓がある場合、ＡＳ２０２は、確認することを要求されない。

図２のステップ１２では、ＰＣＲＦ１０４は、ＳＰＲ２０４の中に参照ＩＤおよび新しい転送ポリシを記憶する。

図２のステップ４では、ＡＳ２０２が（既存のＲｘインターフェースを介して）個々のＵＥのために後の時点でＰＣＲＦ１０４にコンタクトするとき、ＡＳ２０２は、参照ＩＤを提供する。ＰＣＲＦ１０４は、参照ＩＤを介して、ＡＳ要求をＳＰＲ２０４から読み出される転送ポリシと互いに関係づける。ＰＣＲＦ１０４は、最終的に、３ＧＰＰ ＴＳ ２３．２０３に従ってＰＣＣプロシージャをトリガし、このＵＥのバックグラウンドデータ転送のために、それぞれのポリシングおよび課金情報をＰＣＥＦ２０６に提供する。ＡＳ２０２は、典型的には、バックグラウンドデータ転送のためのスポンサ付き接続性を要求するために、個々のＵＥのためのＰＣＲＦ１０４にコンタクトするであろう。

参考文献Ｓ２−１５１２３７（Ｐｒｅｄｉｃａｂｌｅ ＵＥ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｐａｔｔｅｒｎ，Ｅｒｉｃｓｓｏｎ，ＮＥＣ，Ａｐｒｉｌ １３−１７，２０１５）は、ＡＳ／ＳＣＳがネットワークとの周期的通信をスケジュールすることを可能にするための３ＧＰＰの最新のソリューションを説明する。この参考文献で説明されるアプローチは、ＡＳ／ＳＣＳがネットワークとの周期的データ転送をスケジュールし、その予期されるモビリティパターンをネットワークに提供することを可能にする。ＰＣＲＦ１０４は、データ転送を開始すべきときをＡＳ／ＳＣＳに知らせることができる。図３の以下の説明は、参考文献Ｓ２−１５１２３７からの出典である。

図３のソリューションは、「予測可能通信パターンのための情報についての第三者相互作用のサポート」を提供する。ここで説明されるソリューションは、ＵＥまたはＵＥのグループのためのネットワークリソース最適化を可能にするために、そのようなＵＥの通信パターンの関連情報を対応するコアネットワークノードに提供する機構を定義する。

ＳＣＥＦ１０２は、データトラフィックおよび／またはモビリティパターンのための通信パターンを受信し得る。どのような種類のパラメータがこれらの通信パターン（ＣＰ）に含まれ得るかという例が、以下の表に示されている。ＳＣＥＦ１０２は、これらの通信パターンからコアネットワークノードのための通信パターン（ＣＰ）パラメータを選択できるものとする。

ＣＰパラメータの組が、標準化されることができるが、全てのＣＰパラメータは随意である。

以下の過程が、このソリューションのために行われる。
−ＳＣＥＦ１０２が、第三者サービスプロバイダからの受信された通信パターンに基づいて、ＣＰパラメータをフィルタ処理し、転送する。
−ＳＣＥＦ１０２が、ＣＰパラメータをホームサブスクライバサーバ（ＨＳＳ）３０２に提供すし、ＨＳＳ３０２は、それらを選択された適切な機能エンティティ（例えば、ＭＭＥ３０４）に提供する。
−ＣＰパラメータの１つの組のみが一度に有効であり、すなわち、同一のＳＣＳ／ＡＳ２０２または別個のＳＣＳ／ＡＳ２０２が新しいＣＰパラメータを提供する場合、新しいＣＰパラメータは、前もって提供されたあらゆるＣＰパラメータを無効にする。

ＳＣＥＦ１０２は、第三者サービスプロバイダから受信される個々のＵＥまたはＵＥのグループの通信パターンに基づいて、ＭＭＥ３０４への配布のために、選択されたＣＰパラメータをＨＳＳ３０２に提供する。ＳＣＥＦ１０２およびＨＳＳ３０２からのＣＰパラメータを含む、信号伝達は、（ＨＳＳ３０２からＭＭＥ３０４へと同様に）サブスクライバレベルによる。

図３（Ｓ２−１５１２３７からの図６．５．１．３−１）は、ＣＰパラメータのプロビジョニングのための信号伝達シーケンスを示す。

第三者サービスプロバイダは、ＵＥまたはＵＥのグループのための通信パターンについてＳＣＥＦ１０２に通知する。ＳＣＥＦ１０２は、追加の情報についてＨＳＳ３０２にクエリを行い、要求を認証および認可し、そして、オペレータポリシまたは構成に基づいてＣＰパラメータを選択し得る。ＳＣＥＦ１０２は、ネットワークリソース最適化を開始する関連ノード（例えば、ＨＳＳ３０２を介したＭＭＥ３０４）にＣＰパラメータを提供する。ＳＣＥＦ１０２とＡＳ／ＳＣＳとの間のインターフェースは、３ＧＰＰの範囲外であり、図３のメッセージは、例示的である。

ＵＥ要求ベアラリソース修正について議論するこの節の内容は、参考文献３ＧＰＰ ＴＳ ２３．４０１（「Ｇｅｎｅｒａｌ Ｐａｃｋｅｔ Ｒａｄｉｏ Ｓｅｒｖｉｃｅ （ＧＰＲＳ） ｅｎｈａｎｃｅｍｅｎｔｓ ｆｏｒ Ｅｖｏｌｖｅｄ Ｕｎｉｖｅｒｓａｌ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ（Ｅ−ＵＴＲＡＮ） ａｃｃｅｓｓ」）の第５．４．５節からの出典である。

Ｅ−ＵＴＲＡＮのためのＵＥ要求ベアラリソース修正プロシージャが、図４で描写されている。プロシージャは、ＵＥが、特定のＱｏＳ要求を伴う１つのトラフィクフローアグリゲートのためのベアラリソースの修正（例えば、リソースの配分または解放）を要求することを可能にする。代替として、プロシージャは、ＵＥが、ＱｏＳを変化させることなく、アクティブトラフィクフローアグリゲートに使用されるパケットフィルタの修正を要求することを可能にする。ネットワークによって容認された場合、要求が、専用ベアラアクティブ化プロシージャ、ベアラ修正プロシージャを起動するか、または専用ベアラが、パケットデータネットワーク（ＰＤＮ）ゲートウェイ（ＧＷ）開始型ベアラ非アクティブ化プロシージャを使用して、非アクティブにされるかのいずれかである。プロシージャは、ＵＥがすでにＰＤＮ ＧＷ４０４とのＰＤＮ接続を有しているとき、ＵＥによって使用される。ＵＥは、前のプロシージャが完了する前に後続の要求ベアラリソース修正メッセージを送信することができる。

このプロシージャでは、ＵＥは、プロシージャトランザクション識別子（ＰＴＩ）およびＥＰＳベアラ識別（ＴＡＤ動作が、修正、削除、または既存のパケットフィルタに追加するとき）と一緒に、部分トラフィックフローテンプレート（ＴＦＴ）であるトラフィックアグリゲート記述（ＴＡＤ）を信号伝達する。ＴＡＤ動作が修正または削除であるとき、ＴＡＤのパケットフィルタ識別子は、（ＴＦＴパケットフィルタ識別子およびＥＰＳベアラ識別子の連結がＰＤＮ接続内の一意のパケットフィルタ識別子を表すため）リソースが修正されている、参照された進化型パケットシステム（ＥＰＳ）ベアラのＴＦＴパケットフィルタ識別子と同一である。ＴＡＤは、ネットワークから現在のＰＴＩに関連するＴＦＴを受信した後にＵＥによって解放される。

図４のステップ１、２、および５は、ＧＰＲＳトンネリングプロトコル（ＧＴＰ）ベースのＳ５／Ｓ８およびプロキシモバイルＩＰｖ６（ＰＭＩＰ）ベースのＳ５／Ｓ８を用いたアーキテクチャ変異型に共通する。（Ａ）とマークされたプロシージャステップは、ＰＭＩＰベースのＳ５／Ｓ８が採用され、ＴＳ ２３．４０２で定義される場合では異なる。

図４のステップ１では、ＵＥ４０２は、要求ベアラリソース修正［リンクされたベアラＩｄ（ＬＢＩ）、プロシージャトランザクション識別子（ＰＴＩ）、ＥＰＳベアラ識別、サービスの質（ＱｏＳ）、トラフィックアグリゲート記述（ＴＡＤ）、プロトコル構成オプション］メッセージをＭＭＥ３０４に送信する。ＵＥ４０２がＥＣＭ−ＩＤＬＥモード（ＥＣＭはＥＰＳ接続管理を表す）であった場合、この非アクセス層（ＮＡＳ）メッセージは、サービス要求プロシージャによって先行される。

ＴＡＤは、１つの要求される動作（パケットフィルタを追加、修正、または削除する）を示す。トラフィックフローが追加される場合、ＴＡＤは、追加されるべきパケットフィルタ（パケットフィルタプレシデンスを含むがパケットフィルタ識別子がないパケットフィルタ情報から成る）を含む。ＵＥ４０２は、追加されるトラフィックフローのために、適用可能である場合、要求されるＱｏＳクラス識別子（ＱＣＩ）および保証ビットレート（ＧＢＲ）も送信する。ＵＥ４０２が、新しいパケットフィルタのための既存のベアラリソースの使用を可能にするように、新しいパケットフィルタを既存のパケットフィルタにリンクすることを欲する場合、ＵＥ４０２は、新しいパケットフィルタと一緒に、既存のパケットフィルタ識別子を提供する。ＵＥ４０２が、加えて、ＧＢＲを変更することを欲する場合、ＵＥ４０２は、ＥＰＳベアラのＧＢＲ要件を含む。ＴＡＤは、プロシージャが完了するときに解放される。

ＧＢＲの修正（すなわち、減少または増加）を要求するとき、ＴＡＤは、ＧＢＲ変更要求が適用されるパケットフィルタ識別子を含むものとする。ＵＥ４０２は、ＥＰＳベアラのＧＢＲ要件を含む。ＴＡＤは、プロシージャが完了するときに解放される。

パケットフィルタの修正（例えば、ポート番号の変更）を要求するとき、ＴＡＤは、変更されたパケットフィルタ情報とともに、変更要求が適用されるパケットフィルタ識別子を含むものとする。

ＵＥ４０２がトラフィックフローの削除を要求する場合、ＴＡＤは、削除されるパケットフィルタ識別子を含む。削除されるパケットフィルタがＧＢＲベアラにマップされた場合、ＵＥ４０２は、ＥＰＳベアラの新しいＧＢＲ要件を含む。

ＵＥ４０２は、いずれのＰＤＮ接続に追加のベアラリソースがリンクされるかを示すために、要求される動作が追加であるときのみ、リンクされたベアラＩｄ（ＬＢＩ）を送信する。ＥＰＳベアラ識別は、要求される動作が修正または削除であるときのみ送信される。プロシージャトランザクションＩｄは、このプロシージャのためにＵＥ４０２によって動的に配分される。ＵＥ４０２は、以前に使用されたＰＴＩ値が即時に再利用されないことを可能な限り速く確実にするべきである。ＰＴＩは、プロシージャが完了するときに解放される。プロトコル構成オプションは、ＵＥ４０２とＰＤＮゲートウェイ（ＧＷ）４０４との間でアプリケーションレベルパラメータを転送するために使用され得、ＭＭＥ３０４およびサービングＧＷ４０６を通して透過的に送信される。

図４のステップ２では、ＭＭＥ３０４は、ベアラリソースコマンド［国際移動電話サブスクライバ識別（ＩＭＳＩ）、ＬＢＩ、ＰＴＩ、ＥＰＳベアラ識別、ＱｏＳ、ＴＡＤ、プロトコル構成オプション］メッセージを選択されたサービングＧＷ４０６に送信する。ＭＭＥ３０４は、リンクされたベアラＩｄを使用して、要求を確認する。同一のサービングＧＷアドレスが、要求ベアラリソース修正メッセージの中で受信されるリンクされたベアラＩｄによって識別されるＥＰＳベアラに関して、ＭＭＥ３０４によって使用される。

図４のステップ３では、サービングＧＷ４０６は、ベアラリソースコマンド（ＩＭＳＩ、ＬＢＩ、ＰＴＩ、ＥＰＳベアラ識別、ＱｏＳ、ＴＡＤ、プロトコル構成オプション）メッセージをＰＤＮ ＧＷ４０４に送信する。サービングＧＷは、リンクされたベアラＩｄによって識別されるＥＰＳベアラに関して、メッセージを同一のＰＤＮ ＧＷ４０４に送信する。

図４のステップ４では、ＰＤＮ ＧＷ４０４は、ローカルで構成されたＱｏＳポリシを適用し得るか、または、それは、サブスクリプション情報を考慮し得る、適切なＰＣＣ決定をトリガするためにＰＣＲＦ１０４と相互作用し得る。これは、ＰＤＮ ＧＷ４０４がＩＰ−ＣＡＮベアラ信号伝達を要求する時点まで、ＴＳ ２３．２０３で定義されるようなＰＣＥＦ開始型ＩＰ−ＣＡＮセッション修正プロシージャの開始に対応する。ＰＣＲＦ１０４と相互作用するとき、ＰＤＮ ＧＷ４０４は、ＴＡＤのコンテンツ、および適用可能である場合、ＴＡＤに含まれるパケットフィルタ情報に関連付けられるＧＢＲ変更（増加または減少）をＰＣＲＦ１０４に提供する。ＧＢＲ変更は、現在のベアラＱｏＳおよびＵＥ４０２からの要求されるベアラＱｏＳから計算されるか、またはＴＡＤが追加動作を示し、ＥＰＳベアラ識別が受信されなかった場合、要求されるＧＢＲに設定される。ＴＡＤが追加動作を示す場合、既存のパケットフィルタ識別子が新しいパケットフィルタとともに提供されない限り、要求されるＱＣＩも、ＰＣＲＦ１０４に提供される。

ＴＡＤ動作が修正または削除である場合、ＰＤＮ ＧＷ４０４は、受信されたＥＰＳベアラ識別によって示されるＥＰＳベアラの受信されたパケットフィルタ識別子に対応する、Ｇｘ上で前もって割り当てられたサービスデータフロー（ＳＤＦ）フィルタ識別子を提供する。

図４のステップ５では、要求が容認される場合、専用ベアラアクティブ化プロシージャ（３ＧＰＰ ＴＳ ２３．４０１の第５．４．１節「Ｇｅｎｅｒａｌ Ｐａｃｋｅｔ Ｒａｄｉｏ Ｓｅｒｖｉｃｅ （ＧＰＲＳ） ｅｎｈａｎｃｅｍｅｎｔｓ ｆｏｒ Ｅｖｏｌｖｅｄ Ｕｎｉｖｅｒｓａｌ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ （Ｅ−ＵＴＲＡＮ） ａｃｃｅｓｓ」による）、ＰＤＮ ＧＷ開始型ベアラ非アクティブ化プロシージャ（３ＧＰＰ ＴＳ ２３．４０１の第５．４．４．１節による）、または、専用ベアラ修正プロシージャのうちの１つ（３ＧＰＰ ＴＳ ２３．４０１の第５．４．２．１節または第５．４．３節による）が、起動される。ＵＥ４０２によって配分されるＰＴＩは、それをＵＥ要求ベアラリソース修正プロシージャと互いに関係づけるために、起動された専用ベアラアクティブ化プロシージャ、ＰＤＮ ＧＷ開始型ベアラ非アクティブ化プロシージャ、または専用ベアラ修正プロシージャでパラメータとして使用される。これは、新しいトラフィックフローアグリゲートに使用されるべきＥＰＳベアラへの必要な結び付けをＵＥ４０２に提供する。ＰＤＮ ＧＷ４０４は、ＵＥ４０２によって要求されるＱｏＳパラメータを修正しないものとする。

ＰＤＮ ＧＷ４０４は、ＴＡＤに対応するパケットフィルタを、ＥＰＳベアラのためのＴＦＴの中に挿入するか、修正するか、または削除する。新しいパケットフィルタがＴＦＴの中に挿入されるとき、ＰＤＮ ＧＷ４０４は、ＴＦＴ内で一意である新しいパケットフィルタ識別子を割り当てる。ＰＤＮ ＧＷ４０４は、ＰＣＲＦ１０４から受信されるＰＣＣ規則の中のＳＤＦフィルタ識別子とこのＥＰＳベアラのＴＦＴのパケットフィルタ識別子との間の関係を維持する。専用ＥＰＳベアラのためのパケットフィルタの全てがＴＦＴから除去された場合、ＰＤＮ ＧＷは、ＰＤＮ ＧＷ開始型ベアラ非アクティブ化プロシージャを行う。

要求されるＱｏＳが許可されない（すなわち、要求されるＱｏＳが容認されることができない、またはリソースが配分されることができなかった）場合、ＰＤＮ ＧＷ４０４は、ＵＥ４０２に配信されるものである（要求が失敗した、または拒否された理由を示す原因とともに）ベアラリソース失敗指示メッセージを送信する。

図４のステップ６では、ＰＤＮ ＧＷ４０４がステップ４でＰＣＲＦ１０４と相互作用した場合、ＰＤＮ ＧＷ４０４は、ＰＣＣ決定が実施され得るかどうかをＰＣＲＦ１０４に示す。これは、ＩＰ−ＣＡＮベアラ信号伝達の完了後に続行するＴＳ ２３．２０３で定義されるようなＰＣＥＦ開始型ＩＰ−ＣＡＮセッション修正プロシージャの完了に対応する。

Ｍ２Ｍ通信では、サービス層（ＳＬ）は、Ｍ２Ｍデバイスと顧客アプリケーションとの間のセキュアなエンドツーエンドデータ／制御交換をサポートすることによって、第３者付加価値サービスおよびアプリケーションの配信のためのプラットフォームを有効にすることと、遠隔プロビジョニングおよびアクティブ化、認証、暗号化、接続性設定、バッファリング、同期化、集約、ならびにデバイス管理のための能力を提供することとを目指す。ＳＬは、下層ネットワークへのインターフェースを提供し、アプリケーションプログラミングインターフェース（ＡＰＩ）を通した第三者コンテンツプロバイダを通してアクセスされる、サービスプロバイダ（ＳＰ）によって所有されるサーバを使用して、能力を有効にする。

Ｍ２Ｍ／ＩｏＴサービス層は、具体的には、Ｍ２Ｍ／ＩｏＴタイプデバイスおよびアプリケーションのための付加価値サービスを提供することに向けられている。ＥＴＳＩ Ｍ２Ｍ（「Ｍａｃｈｉｎｅ−ｔｏ−Ｍａｃｈｉｎｅ ｃｏｍｍｕｎｉｃａｔｉｏｎｓ （Ｍ２Ｍ） Ｆｕｎｃｔｉｏｎａｌ Ａｒｃｈｉｔｅｃｔｕｒｅ」、草案ＥＴＳＩ ＴＳ １０２ ６９０ １．１．１（２０１１−１０））およびｏｎｅＭ２Ｍ ＴＳ−０００１（ｏｎｅＭ２Ｍ機能的アーキテクチャ）等の標準化団体が、センサならびにデバイスネットワークを特にに標的にするＭ２Ｍサービス層を開発している。デバイス管理（ＤＭ）は、ファームウェアおよびソフトウェア管理、セキュリティおよびアクセス制御、デバイス監視ならびにロギング等の問題のための解決策を提供するために、殆どのＳＬプラットフォームによって標的にされる付加価値サービスの間にある。

ｏｎｅＭ２Ｍアーキテクチャは、異なるタイプのネットワークノード（例えば、インフラストラクチャノード、中間ノード、アピリケーション特定のノード）上でホストされることができる共通サービスエンティティ（ＣＳＥ）に基づく。

ｏｎｅＭ２Ｍ ＲＥＳＴｆｕｌアーキテクチャ（リソース指向アーキテクチャまたはＲｏＡとしても公知である）内で、ＣＳＥ５０２は、図６に示されるように、共通サービス機能（ＣＳＦ）の組のインスタンス化をサポートする。ＣＳＦ機能性は、作成、読み出し、更新、および削除等のＲＥＳＴｆｕｌ方法を介して操作されることができる表現を有する一意にアドレス可能なエンティティであるリソースを介して、実装される。これらのリソースは、ユニバーサルリソース識別子（ＵＲＩ）を使用してアドレス可能である。リソースは、リソースについての関連情報を記憶し、子リソースと称される他のリソースへの参照を含み得る属性の組をサポートする。子リソースは、親リソースと包含関係を有し、その存続期間が親リソースの存続期間によって限定される、リソースである。

ｏｎｅＭ２Ｍは、導入されるＲｏＡアーキテクチャに加えて、サービス指向アーキテクチャ（ＳｏＡ）アプローチ（「Ｓｅｒｖｉｃｅ Ｃｏｍｐｏｎｅｎｔ Ａｒｃｈｉｔｅｃｔｕｒｅ」 ｏｎｅＭ２Ｍ−ＴＳ−０００７、ｏｎｅＭ２Ｍ Ｓｅｒｖｉｃｅ Ｃｏｍｐｏｎｅｎｔ Ａｒｃｈｉｔｅｃｔｕｒｅ−Ｖ−０．６．０）を使用して、仕様を提供している。ＳｏＡアーキテクチャの概念は、異なるソフトウェアモジュールによって提供され、サービスとして公知である機能性を基礎的要素と見なすことに基づく。サービスは、ベンダ、製品、または技術から独立している規定インターフェースを介して、アプリケーションに提供される。ｏｎｅＭ２ＭにおけるＣＳＥ５０２のＳｏＡ表現が、図７に示されている。

展開の観点から、図８は、ｏｎｅＭ２Ｍアーキテクチャによってサポートされる構成を描写する。

以下の用語が、この文脈で使用される。
● アプリケーションサービスノード（ＡＳＮ）：
○ ＡＳＮは、１つのＣＳＥ５０２を含み、かつ少なくとも１つのアプリケーションエンティティ（ＡＥ）を含む。例として、ＡＳＮは、Ｍ２Ｍデバイスの中に常駐し得る。
● アプリケーション専用ノード（ＡＤＮ）：
○ ＡＤＮは、少なくとも１つのＡＥを含み、ＣＳＥ５０２を含まない。例として、ＡＤＮは、制約されたＭ２Ｍデバイスの中に常駐し得る。
● 中間ノード（ＭＮ）：
○ ＭＮは、１つのＣＳＥ５０２を含み、かつ０以上のＡＥを含む。例として、ＭＮは、Ｍ２Ｍゲートウェイの中に常駐し得る。
● インフラストラクチャノード（ＩＮ）：
○ ＩＮは、１つのＣＳＥ５０２を含み、かつ０以上のＡＥを含むノードである。インフラストラクチャドメイン内にｏｎｅＭ２Ｍサービスプロバイダにつき正確に１つのＩＮがある。例として、ＩＮは、Ｍ２Ｍサービスインフラストラクチャの中に常駐し得る。
● 非ｏｎｅＭ２Ｍノード（ＮｏＤＮ）：
○ 非ｏｎｅＭ２Ｍノードは、ｏｎｅＭ２Ｍエンティティを含まない（ＡＥもＣＳＥも含まない）ノードである。そのようなノードは、管理を含むインターワーキング目的のためにｏｎｅＭ２Ｍシステムにアタッチされたデバイスを表す。

サービス能力エクスポージャ機能が、ＵＥに追加される（Ｕ−ＳＣＥＦ）。Ｕ−ＳＣＥＦは、ＵＥのオペレーティングシステム（ＯＳ）の一部であり、これらのアプリケーションにＡＰＩをエクスポーズし得。アプリケーションが周期的センサ測定またはファームウェアダウンロード等のデータプレーン通信をスケジュールすることを可能にする。代替として、Ｕ−ＳＣＥＦは、ＵＥのＯＳの上方に位置するアプリケーションまたはサービスであり得る。

Ｕ−ＳＣＥＦは、モバイルネットワークオペレータの（Ｓ）Ｇｉ−ＬＡＮの中に常駐する進化型パケットコア（ＥＰＣ）インターワーキングサービスと通信する。ＥＰＣインターワーキングサービスは、Ｕ−ＳＣＥＦとＳＣＥＦを介してモバイルネットワークオペレータ（ＭＮＯ）によってエクスポーズされるサービス能力との間でインターフェースとしての役割を果たす。Ｕ−ＳＣＥＦは、ＵＥの予想通信スケジュールおよびモビリティステータスについての情報をＥＰＣインターワーキングサービスに提供し得る。ＥＰＣインターワーキングサービスは、ＵＥが通信するための最適時間、最適モビリティ管理構成等を決定するために、ＳＣＥＦによってエクスポーズされるサービスを使用するであろう。Ｕ−ＳＣＥＦは、汎用パケット無線サービス（ＧＰＲＳ）ベースのコアネットワーク等の他のタイプのコアネットワークと連携するサービスとも通信し得ることに留意されたい。

ＥＰＣインターワーキングサービスは、ＵＥ（Ｕ−ＳＣＥＦ）の代わりにＥＰＣ（ＳＣＥＦ）と通信スケジュールをネゴシエートし、ＵＥおよびモバイルネットワークの必要性に一致通信ポリシまたはモビリティ管理ポリシをＵ−ＳＣＥＦに提供する。

プロシージャは、ＵＥアプリケーションが、ＭＮＯと直接、通信スケジュールおよびモビリティ管理構成をネゴシエートすることを可能にする。ＵＥアプリケーションが通信するサーバは、ＭＮＯとのインターフェースをサポートするか、またはＭＮＯとビジネス関係を確立する必要がない。サーバは、大部分、ＵＥとＭＮＯとのネゴシエーションを認識することができない。

本概要は、発明を実施するための形態において以下でさらに説明される簡略化形態の一連の概念を導入するために提供される。本概要は、請求される主題の主要な特徴または不可欠な特徴を識別することを意図せず、請求される主題の範囲を限定するために使用されることも意図していない。さらに、請求される主題は、本開示の任意の部分で記述されるいずれかまたは全ての不利点を解決する制限に限定されない。
本発明はさらに、例えば、以下を提供する。
（項目１）
プロセッサと、メモリとを備えている装置であって、前記装置は、前記装置の前記メモリ内に記憶されたコンピュータ実行可能命令をさらに備え、前記命令は、前記装置の前記プロセッサによって実行されると、
アプリケーションから情報を受信することであって、前記アプリケーションは、前記装置に位置している、ことと、
前記情報を含むメッセージをコアネットワークサービスエクスポージャ機能に送信することと、
前記コアネットワークサービスエクスポージャ機能から応答を受信することと
を前記装置に行わせる、装置。
（項目２）
前記装置は、ユーザ機器（ＵＥ）である、項目１に記載の装置。
（項目３）
前記メッセージは、所望のスケジュールを示す、項目１に記載の装置。
（項目４）
前記所望のスケジュールは、前記装置における複数のアプリケーションからの入力を反映する、項目３に記載の装置。
（項目５）
前記メッセージは、前記装置のためのモビリティ情報を示す、項目１に記載の装置。
（項目６）
前記装置は、ＵＥサービスエクスポージャ機能を含む、項目１に記載の装置。
（項目７）
前記ＵＥサービスエクスポージャ機能は、前記コアネットワークサービスエクスポージャ機能と相互作用する、項目６に記載の装置。
（項目８）
前記ＵＥサービスエクスポージャ機能は、参照番号を前記コアネットワークサービスエクスポージャ機能に提供し、前記コアネットワークサービスエクスポージャ機能から前記装置への前記応答は、前記参照番号を含む、項目７に記載の装置。
（項目９）
前記装置は、セッション管理またはモビリティ管理メッセージの中で前記参照番号を前記コアネットワークに提供する、項目８に記載の装置。
（項目１０）
前記応答は、スケジュールを含む、項目１に記載の装置。
（項目１１）
前記装置は、前記スケジュールを使用して通信する、項目１０に記載の装置。
（項目１２）
前記応答は、１つ以上のモビリティ管理タイマを含む、項目１に記載の装置。
（項目１３）
前記装置は、前記１つ以上のモビリティ管理タイマ値を前記コアネットワークに送信する、項目１２に記載の装置。
（項目１４）
前記メッセージは、前記装置のためのバッテリレベル情報を示す、項目１に記載の装置。
（項目１５）
装置によって使用するための方法であって、前記装置は、プロセッサと、メモリとを備え、前記装置は、前記メモリ内に記憶されたコンピュータ実行可能命令をさらに備え、前記命令は、前記プロセッサによって実行されると、
アプリケーションから情報を受信することであって、前記アプリケーションは、前記装置に位置している、ことと、
前記情報を含むメッセージをコアネットワークサービスエクスポージャ機能に送信することと、
前記コアネットワークサービスエクスポージャ機能から応答を受信することと
を含む方法の機能を果たす、方法。
（項目１６）
前記装置は、ユーザ機器（ＵＥ）である、項目１５に記載の方法。
（項目１７）
前記メッセージは、所望のスケジュールを示す、項目１５に記載の方法。
（項目１８）
前記所望のスケジュールは、前記装置における複数のアプリケーションからの入力を反映する、項目１７に記載の方法。
（項目１９）
前記メッセージは、前記装置のためのモビリティ情報を示す、項目１５に記載の方法。
（項目２０）
前記装置は、ＵＥサービスエクスポージャ機能を含む、項目１５に記載の方法。

より詳細な理解が、付随の図面と併せて一例として挙げられる、以下の説明からもたらされ得る。
図１は、サービス能力エクスポージャ機能アーキテクチャの略図である。 図２は、バックグラウンドデータ転送のためのリソース管理用の一般的アプローチの略図である。 図３は、ＣＰパラメータのプロビジョニングのための信号伝達シーケンスの略図である。 図４は、ＵＥ要求ベアラリソース修正の略図である。 図５は、ｏｎｅＭ２Ｍ機能的アーキテクチャの略図である。 図６は、ｏｎｅＭ２ＭにおけるＣＳＥ内の共通サービス機能のＲＯＡ表現の略図である。 図７は、ｏｎｅＭ２ＭにおけるＣＳＥのＳＯＡ表現の略図である。 図８は、ｏｎｅＭ２Ｍアーキテクチャによってサポートされる構成の略図である。 図９は、ＵＥアプリケーションインターワーキングアーキテクチャの略図である。 図１０は、スケジュールされた通信ユースケースの略図である。 図１１は、周期的通信ユースケースの略図である。 図１２は、モビリティ指示ユースケースの略図である。 図１３は、一実施形態のグラフィカルユーザインターフェースの略図である。 図１４Ａは、通信ネットワークを含む、Ｍ２Ｍ／ＩｏＴ／ＷｏＴ通信システムの略図である。 図１４Ｂは、Ｍ２Ｍアプリケーション、Ｍ２Ｍゲートウェイデバイス、およびＭ２Ｍ端末デバイスのためのサービス、ならびに通信ネットワークを提供する、フィールドドメイン内の図示されるＭ２Ｍサービス層の略図である。 図１４Ｃは、本明細書に説明されるネットワークノードのうちのいずれかを実装するために使用され得る、例示的デバイスの略図である。 図１４Ｄは、本明細書に説明されるネットワークノードのうちのいずれかを実装するために使用され得る、コンピュータシステムまたはサーバのブロック図である。 図１５は、仮想化ネットワーク機能転送グラフ（ＶＮＦ−ＦＧ）の概念を図示する略図である。 図１６は、ネットワークスライシングの概念的アーキテクチャを図示する略図である。 図１７は、複数のネットワークスライスインスタンスを選択する際のＣＮＳＦを図示する略図である。 図１８は、ネットワーク機能の相互接続のための非ローミング参照モデルを図示する略図である。 図１９は、ネットワーク機能の相互接続のためのローミング参照モデルを図示する略図である。

ある時は、デバイス特性は、実行時間中に変化する。ある特性を変化させる事象が、ＵＥ４０２において起こり得る。例えば、ユーザは、ＵＥアプリケーション上の設定を変更し得、それは、ＵＥのスケジュール、優先順位等を変化させる。

ＵＥ４０２は、その動作特性についてネットワークに知らせる能力を殆ど有していない。したがって、ネットワークは、常に、いくつかのデバイスが静止していることが知られている、既知の時間に通信するという事実を利用できるわけではない。１つの例外は、デバイスが低い優先順位であることを示すために、ＮＡＳメッセージが使用され得ることである。別の例外は、ＲＲＣメッセージが低電力選好インジケータを伝えるために使用され得ることである。しかしながら、通信スケジュール、予想されるモビリティ（またはそれがないこと）、バッテリレベル等の情報を全て３ＧＰＰ制御メッセージの中で伝えることは、合理的ではない。

リリース１３では、３ＧＰＰは、ＳＣＳとＥＰＣとの間のインターワーキング能力（ＳＣＥＦ１０２を介する）を追加することに取り組んでいる。サービス、機能、またはノードがエクスポーズされる、このタイプのインターワーキングは、サービスエクスポージャとも呼ばれ得る。インターワーキング特徴のうちのいくつかは、ＳＣＳがＵＥの動作特性についてＥＰＣに知らせることを可能にするであろう。しかしながら、これらの特徴は、ＭＮＯとビジネス関係を有するＳＣＳのためのみに有効にされる。したがって、ＵＥ４０２は、それがＭＮＯとビジネス関係を有するＳＣＳとペアリングされない限り、そのスケジュール、予想されるモビリティ（またはそれがないこと）、バッテリレベル等を認識し得るが、情報をＥＰＣに伝える方法を有しない。多数のデバイスが、ＭＮＯとビジネス関係を有していないＭ２Ｍサーバと通信するであろうことが予期される。したがって、これらのタイプのデバイスは、より頻繁にネットワークをリッスンすること、ネットワークが比較的混雑しているときに伝送すること、または必要よりも頻繁にモビリティ管理プロシージャを行うことを余儀なくされ得る。

図９は、ＵＥ４０２プラットフォームがＥＰＣ９０８と連携することを可能にするアーキテクチャを示す。黄色のブロックは、ＭＮＯとビジネス関係を有していないこともあるアプリケーションを表す。橙色のブロックは、本開示の焦点であり、デバイスアプリケーションがＥＰＣ９０８と連携することを可能にするために必要である論理を表す。

ＵＥサービス能力エクスポージャ機能（Ｕ−ＳＣＥＦ）１００２が、ＵＥプラットフォームに追加されることができる。ＵＥプラットフォームは、３ＧＰＰモデム（Ｌ１、Ｌ２、およびＬ３）と、オペレーティングシステムと、アプリケーションとを含むことができる。

Ｕ−ＳＣＥＦ９０２は、ＵＥのＯＳの一部であり得る。代替として、それは、ＵＥのＯＳの上で起動するアプリケーションまたはサービスであり得る。例えば、それは、ｏｎｅＭ２Ｍ ＡＥまたはｏｎｅＭ２Ｍ ＣＳＦであり得る。

Ｕ−ＳＣＥＦ９０２は、ノースバウンドＡＰＩ（Ｎ−ＡＰＩ）をＵＥ４０２アプリケーションにエクスポーズし得る。ＵＥアプリケーションの例は、ファームウェア管理アプリケーション、マルチメディアアプリケーション、車両診断アプリケーション、センサ測定を収集するアプリケーション、パッケージまたは在庫のステータスを追跡するアプリケーション、サービス層（すなわち、ｏｎｅＭ２Ｍ ＡＳＮ−ＣＳＥまたはＭＮ−ＳＣＥ）等である。

Ｕ−ＳＣＥＦ９０２は、ＥＰＣインターワーキングサービスに接続するためにＰＤＮ接続を使用することができる。ＥＰＣインターワーキングサービスは、ＭＮＯによって所有され、信頼ドメイン内にあることが予期される。ＥＰＣインターワーキングサービスは、ｏｎｅＭ２Ｍ共通サービスエンティティ（ＣＳＥ）、ＣＳＥ５０２内のサービス、またはアプリケーションであり得る。

Ｕ−ＳＣＥＦ９０２およびＥＰＣインターワーキングサービス１００２は、Ｓ−ＡＰＩ ９０６を介して通信することができる。

ＥＰＣインターワーキングサービス１００２は、Ｓ−ＡＰＩ ９０６からＵＥ情報を取得し、ＳＣＥＦ１０２を介してそれをＥＰＣ９０８にパスする。

Ｕ−ＳＣＥＦ９０２は、それがＵＥのモデムを構成することを可能にする、ＡＰＩへのアクセスを有し得る。例えば、Ｕ−ＳＣＥＦ９０２は、アプリケーションからの入力に基づいて、モデムのモビリティ管理タイマを構成し得る。

Ｕ−ＳＣＥＦ９０２は、３ＧＰＰ ＵＥ４０２上で起動する論理機能である。それは、ＵＥアプリケーションとＯＳとの間に位置するモデムＯＳまたはミドルウェアの一部であり得る。

始動時、Ｕ−ＳＣＥＦ９０２は、通信するためにＵＥのデフォルトＰＤＮ接続を使用し得る。代替として、ユーザは、ＧＵＩ、ＡＰＩコマンド、アテンション（ＡＴ）コマンド等のユーザインターフェースを介して、Ｕ−ＳＣＥＦアクセスポイント名（ＡＰＮ）を入力し得るか、またはＵ−ＳＣＥＦ ＡＰＮをＵＥのサブスクライバ識別モジュール（ＳＩＭ）カードの中に記憶し得る。Ｕ−ＳＣＥＦ ＡＰＮは、ネットワーク接続を確立するためにＵ−ＳＣＥＦ９０２によって使用され得る。Ｕ−ＳＣＥＦ ＡＰＮは、ＰＤＮ接続の目的がＥＰＣインターワーキングサービス１００２にコンタクトすることであるというＥＰＣへの指示としての役割を果たし得る。ＰＤＮ接続が確立されるとき、ＭＭＥ３０４は、ＵＥ４０２がこのＵ−ＳＣＥＦ ＡＰＮに接続することを認可されていることをＵＥのサブスクリプション情報が示すことをチェックし得る。Ｕ−ＳＣＥＦの接続に特別なＡＰＮを使用し、ＵＥサブスクリプション情報を介してそれを認可することは、無認可ＵＥがＥＰＣインターワーキングサービスにアクセスすることをＥＰＣが防止するための便利な方法を提供する。

ＨＳＳ３０２の中のＵＥのサブスクリプション情報は、ＵＥがＵ−ＳＣＥＦ９０２を起動することを可能にされていることを示し得る。その指示は、ＵＥ４０２が、ＥＰＣインターワーキングサービスにアクセスするためにＵ−ＳＣＥＦによって使用される特別なＡＰＮにアクセスすることを可能にされていることであり得る。

Ｕ−ＳＣＥＦ９０２は、Ｎ−ＡＰＩ（ノースバウンドＡＰＩ）９０４をＵＥ４０２上でホストされるアプリケーションにエクスポージャし得る。このＡＰＩは、ＵＥ４０２上で起動するアプリケーションにエクスポージャされるであろう。例えば、それは、ファームウェア管理アプリケーション、マルチメディアアプリケーション、車両診断アプリケーション、センサ測定を収集するアプリケーション、パッケージまたは在庫のステータスを追跡するアプリケーション、サービス層（すなわち、ｏｎｅＭ２Ｍ ＡＳＮ−ＣＳＥまたはＭＮ−ＳＣＥ）等によって使用されるであろう。例示的Ｎ−ＡＰＩが、表３−７に関して説明される。

アプリケーションがＵ−ＳＣＥＦ９０２を使用するであろうことをＵ−ＳＣＥＦ９０２に示すように、アプリケーション登録ＡＰＩが、アプリケーションによって呼び出される。このＡＰＩは、別のアプリケーションによって、またはＧＵＩによって、ＵＥ４０２始動時にトリガされることができる。アプリケーションは、そのアプリケーション識別子をＵ−ＳＣＥＦ９０２に提供し、Ｕ−ＳＣＥＦ９０２は、Ｕ−ＳＣＥＦ９０２のどのような能力にアプリケーションがアクセスすることを許可されているかを示すことによって、応答するであろう。

アプリケーション識別子は、ＯＳによって割り当てられたＵＥローカルアプリケーション識別子である。

能力応答は、アプリケーションが、Ｕ−ＳＣＥＦ９０２の能力（すなわち、スケジューリング、バッテリレベルの設定等）のうちのいずれか、または単純にＵＥの能力のサブセットを使用することを許可されていないことを示し得る。ＵＥ４０２は、どのようなアプリケーションがＵ−ＳＣＥＦ９０２にアクセスすることを許可されているかを把握するように、Ｕ−ＳＣＥＦ９０２またはＵＥ４０２を構成するために使用されることができる、ＧＵＩ、ＡＰＩコマンド、もしくはＡＴコマンド等のユーザインターフェースを提供し得る。

アプリケーションバッテリレベル指示ＡＰＩは、バッテリレベルをＵ−ＳＣＥＦ９０２に示すために、アプリケーション、ＯＳ、またはバッテリドライバによって使用されることができる。

Ｕ−ＳＣＥＦ９０２は、ＥＰＣインターワーキングサービスが、ＵＥの通信スケジュール、不連続受信（ＤＲＸ）サイクル、節電モード（ＰＳＭ）サイクル、モビリティ管理タイマ等を考慮するとき、バッテリレベルを考慮することができるように、この情報をＥＰＣインターワーキングサービスに転送し得る。代替として、ＵＥ４０２は、どれくらいの頻度でセル選択／再選択を行うかを調節するために、この指示を使用することができる。

Ｕ−ＳＣＥＦ９０２は、どのような通信スケジュール、ＤＲＸサイクル、ＰＳＭサイクル等をネットワークから要求するかを決定するために、この情報を使用し得る。

アプリケーションワンタイム通信スケジュール要求ＡＰＩは、ＡＰＩ入力で説明されるデータ交換を開始することができるときをＵ−ＳＣＥＦ９０２が示すことをアプリケーションが要求するために、アプリケーションによって使用される。

このＡＰＩは、車両ゲートウェイＵＥ４０２上でホストされるアプリケーションによって使用され得る。アプリケーションは、ネットワークからファームウェアアップグレードをダウンロードすることを望み得る。一例では、アプリケーションは、ファームウェアイメージをダウンロードすべき最良の時間がいつであろうかをＵ−ＳＣＥＦ９０２に尋ねることを望む。

一実施形態では、ＡＰＩは、非阻止挙動をもたらし得る。アプリケーションは、要求される通信が開始し得るときに呼び出され得る、リターン機能へのポインタを提供し得る。

代替実施形態では、ＡＰＩコールは、阻止挙動をもたらし得る。ＡＰＩは、開始時間をアプリケーションに返し得る。アプリケーションは、示された開始時間にデータ交換を開始する責任があろう。

このＡＰＩが呼び出されると、Ｕ−ＳＣＥＦ９０２は、データ交換のための最良の時間を独立して決定し得るか、または、それは、ＥＰＣインターワーキングサービスが最適通信時間を提供することを要求するＵ−ＳＣＥＦワンタイム通信スケジュール要求Ｓ−ＡＰＩを使用し得る。このＡＰＩがどのようにしてアプリケーションによって使用され得るかを実証するコールフローが、図１０に示されている。

アプリケーション周期的時間通信スケジュール要求ＡＰＩは、アプリケーションがＡＰＩ入力で説明される周期的データ交換を開始することができるときをＵ−ＳＣＥＦ９０２が示すことを要求するために、アプリケーションまたはＧＵＩによって使用される。

このＡＰＩは、１時間に１回データをアップロードすることを望む感知アプリケーションによって使用され得る。ＡＰＩは、通信サイクルを開始することが最適であるときにＵ−ＳＣＥＦ９０２からの指示を入手するために使用されることができる。例えば、正時の２０分後に１時間に１回よりも、正時の１０分後に１時間に１回、センサデータをアップロードすることが最適であり得る。

一実施形態では、ＡＰＩコールは、非阻止様式でモデル化され得る。アプリケーションは、要求される通信期間が開始し得るときに呼び出され得るリターン機能へのポインタを提供し得る。

別の実施形態では、ＡＰＩコールは、阻止様式でモデル化され得る。ＡＰＩは、開始時間をアプリケーションに返し得る。アプリケーションは、示された開始時間にデータ交換を開始する責任があろう。

このＡＰＩが呼び出されると、Ｕ−ＳＣＥＦ９０２は、データ交換のための最良の時間を独立して決定し得るか、またはＥＰＣインターワーキングサービスが最適通信時間を提供することを要求するために、Ｕ−ＳＣＥＦ周期的通信要求Ｓ−ＡＰＩを使用し得る。このＡＰＩがどのようにしてアプリケーションによって使用され得るかを実証するコールフローが、図１１に示されている。

このＡＰＩは、周期的様式で通信することを望む、ＵＥ４０２上で起動する２つ以上のアプリケーションがあるとき、特に有用であることに留意されたい。Ｕ−ＳＣＥＦ９０２は、それらの通信期間が整列させられるように、アプリケーションを同期化し得る。それらの通信期間を整列させることによって、ＵＥ４０２は、より長い期間にわたってスリープし得る（すなわち、より長い期間にわたってＤＲＸまたはＰＳＭに留まる）。通信パターンを整列させることは、両方のアプリケーションが同時に、または互いの直後に始動するように求められることを意味し得る。

アプリケーションモビリティ指示ＡＰＩは、予期されるモビリティレベルをＵ−ＳＣＥＦ９０２に示すために、アプリケーションまたはＧＵＩによって示される。表７の中のパラメータは、予期されるモビリティレベルを示すために使用されることができる。

Ｕ−ＳＣＥＦ９０２は、ＵＥのモビリティ管理タイマ、ページングエリア等を構成する場合、ＥＰＣインターワーキングサービスが予期されるモビリティレベルを考慮することができるように、この情報をＥＰＣインターワーキングサービスに転送し得る。

Ｕ−ＳＣＥＦ９０２は、ＵＥのモビリティ管理タイマ、ＰＳＭタイマ、ＤＲＸタイマ等を設定する方法を決定するために、この情報を使用し得る。Ｕ−ＳＣＥＦ９０２は、モビリティ情報または推奨タイマ値をＵＥ４０２にパスするために、ＡＰＩ、ＡＴコマンドを使用し得る。代替として、ＵＥ４０２は、どれくらいの頻度でセル選択／再選択を行うかを調節するために、この指示を使用することができる。

このＡＰＩは、車両ゲートウェイプラットフォーム上で起動するアプリケーションに有用であろう。アプリケーションは、車両が駐車されているとき、充電ステーションに差し込まれているとき、渋滞に巻き込まれているとき等に、車両が比較的静止していることをＵ−ＳＣＥＦ９０２に示し得る。ＵＥ４０２およびＥＰＣは、次いで、ＵＥのモビリティ管理タイマ、ＰＳＭタイマ、ＤＲＸタイマ、ページングエリア等をより効率的に構成し得る。

このＡＰＩは、自動販売機アプリケーションにも有用であろう。アプリケーションは、自動販売機がプラグに差し込まれているときは常に静止していることをＵ−ＳＣＥＦ９０２に示し得る。

複数のアプリケーションが異なるモビリティレベルをＵ−ＳＣＥＦ９０２に示す場合、Ｕ−ＳＣＥＦ９０２は、異なる指示を集約し、モビリティ指示の単一の組をＥＰＣインターワーキングサービスに提供するであろう。Ｕ−ＳＣＥＦ９０２は、「最高」レベルのモビリティを示す指示および最大エリアにわたるモビリティを示す指示を使用すること、または示されたエリアの上位集合を使用することを選定し得る。

Ｕ−ＳＣＥＦ９０２は、ＥＰＣインターワーキングサービスと通信するためにＳ−ＡＰＩ（サウスバウンドＡＰＩ）を使用し得る。Ｕ−ＳＣＥＦ９０２は、ＩＰベースの接続を介してメッセージをＥＰＣインターワーキングサービスに送信するために使用され得る。代替として、Ｓ−ＡＰＩが、制御情報をコアネットワークノードに伝送するであろうＵＥのモデムに構成情報を送信するために、使用され得る。例示的Ｓ−ＡＰＩが、表８−１２に関して以下で議論される。

ＵＥ４０２が、ＥＰＣインターワーキングサービスにアクセスするために使用されることができるＡＰＮへのＰＤＮ接続を確立した後、ＵＥ４０２は、初期登録メッセージをＥＰＣインターワーキングサービスに送信するために、Ｕ−ＳＣＥＦ登録ＡＰＩを使用する。

一実施形態では、１つだけのＵ−ＳＣＥＦ９０２が、デバイス上に常駐する。Ｕ−ＳＣＥＦ９０２は、その３ＧＰＰ外部識別子でそれ自体を識別することができる。Ｕ−ＳＣＥＦ９０２登録プロシージャは、以下のユースケースで示される。

Ｕ−ＳＣＥＦバッテリレベル指示ＡＰＩは、バッテリレベルをＥＰＣインターワーキングサービスに示すために、Ｕ−ＳＣＥＦ９０２によって使用されることができる。

ＥＰＣインターワーキングサービスは、ＵＥの通信スケジュール、ＤＲＸサイクル、ＰＳＭサイクル、モビリティ管理タイマ等を構成するとき、バッテリレベルを考慮することができる。

ＥＰＣインターワーキングサービスは、どのような通信スケジュール、ＤＲＸサイクル、ＰＳＭサイクル、モビリティ管理タイマ等をネットワークから要求すべきかを決定するために、この情報を考慮することができる。

Ｕ−ＳＣＥＦワンタイム通信スケジュール要求ＡＰＩは、データ転送が許可されているときの指示を要求するために、Ｕ−ＳＣＥＦ９０２によって使用されることができる。

ＵＥ４０２上の複数のアプリケーションが（すなわち、５．１．１．３のアプリケーションワンタイム通信スケジュール要求ＡＰＩを介して）ワンタイムデータ転送を要求する場合、Ｕ−ＳＣＥＦ９０２は、要求をＥＰＣインターワーキングサービスへの単一の要求に統合し得る。

Ｕ−ＳＣＥＦ周期的時間通信スケジュール要求ＡＰＩは、ＵＥ４０２がＡＰＩ入力で説明される周期的データ交換を開始し得るときをＥＰＣインターワーキングサービスが示すことを要求するために、Ｕ−ＳＣＥＦ９０２によって使用されることができる。

ＵＥ４０２上の複数のアプリケーションが（すなわち、アプリケーションワンタイム通信スケジュール要求ＡＰＩを介して）周期的データ転送を要求する場合、Ｕ−ＳＣＥＦ９０２は、要求をＥＰＣインターワーキングサービス１００２への単一の要求に統合し得る。Ｕ−ＳＣＥＦ９０２は、それらの通信期間が整列させられるように、アプリケーションを同期化し得る。それらの通信期間を整列させることによって、ＵＥ４０２は、より長い期間にわたってスリープし得る（すなわち、より長い期間にわたってＤＲＸまたはＰＳＭに留まる）。通信パターンを整列させることは、両方のアプリケーションが同時に、または互いの直後に始動するように求められることを意味し得る。

Ｕ−ＳＣＥＦモビリティ指示ＡＰＩは、予期されるモビリティレベルをＥＰＣインターワーキングサービス１００２に示すために、Ｕ−ＳＣＥＦ９０２によって使用される。

Ｕ−ＳＣＥＦ９０２は、ＥＰＣインターワーキングサービス１００２が、ＵＥのモビリティ管理タイマ、ページングエリア等を構成するとき、予期されるモビリティレベルを考慮することができるように、この情報をＥＰＣインターワーキングサービスに転送し得る。

モデムＡＰＩは、アプリケーションまたはＥＰＣインターワーキングサービスからの入力に基づいてモデムを構成するために、Ｕ−ＳＣＥＦ９０２によって使用され得る。

ベアラが周期的通信または１回限りのスケジュールされたダウンロードのために確立されるとき、Ｕ−ＳＣＥＦ９０２は、ポリシ参照番号を３ＧＰＰモデムに提供し得、それによって、３ＧＰＰモデムは、通信するために使用されるであろうベアラを修正するとき、ポリシ参照番号をネットワークに提供し得る。

ＥＰＣインターワーキングサービス１００２がモビリティ管理タイマまたはＭＭ参照番号をＵ−ＳＣＥＦ９０２に提供すると、Ｕ−ＳＣＥＦ９０２は、それらを３ＧＰＰモデムに提供し得、それによって、モデムは、追跡エリア更新等のＭＭプロシージャを行うとき、タイマ値またはＭＭ参照番号をネットワークに提供することができる。

図９に示されるように、Ｕ−ＳＣＥＦ９０２は、ＥＰＣインターワーキングサービス１００２と通信し、エクスポーズされたサービスにアクセスするために、確立されたＰＤＮ接続またはデータネットワーク接続を使用し得る。ＥＰＣインターワーキングサービスは、仮想化ネットワーク機能であり得る。ＵＥのオペレーティングシステムまたはＳＩＭカードは、ＰＤＮ接続、データネットワーク接続、またはネットワークスライス接続を確立するときにＵ−ＳＣＥＦ９０２が使用するべきＡＰＮ、データネットワーク名、ネットワークスライス名、ネットワークスライスタイプ名、サービス名、またはサービス記述子をプロビジョニングされ得る。ＨＳＳ３０２内のＵＥのサブスクリプション情報は、ＵＥ４０２がこのＡＰＮまたはデータネットワークにアクセスすることを可能にされていること、またはサービスエクスポージャサービスにアクセスすることを可能にされていることを示し得る。ＵＥ４０２がアタッチするとき、モビリティ管理エンティティ（ＭＭＥ）３０４は、ＰＤＮおよびＥＰＣインターワーキングサービスにアクセスすることを可能にされているかどうかを確認するために、ＵＥのサブスクリプション情報をチェックすることができる。したがって、ＵＥのサブスクリプションの中の既存のＰＤＮ接続プロシージャおよびＡＰＮ情報は、無認可ＵＥがＥＰＣインターワーキングサービス１００２にアクセスすることを防止するために使用され得る。５Ｇネットワークでは、ＵＥ４０２がアタッチするとき、ネットワーク機能は、ＵＥがネットワークスライスにアクセスすることを可能にされているか、データネットワークにアクセスすることを可能にされているか、およびサービスエクスポージャ機能にアクセスすることを可能にされているかを確認するために、ＵＥのサブスクリプション情報をチェックすることができる。このチェックを行うネットワーク機能は、ＣＮＳＦであり得る。

ＵＥ４０２がＥＰＣインターワーキングサービスにアクセスすることを可能にし、無認可ＵＥがＥＰＣインターワーキングサービス１００２にアクセスすることを防止するために、代替方法が使用され得る。

代替実施形態では、Ｕ−ＳＣＥＦ９０２またはＳＩＭカードは、ＥＰＣインターワーキングサービス１００２の識別子、ＩＰアドレス、またはＦＱＤＮをプロビジョニングされ得、Ｕ−ＳＣＥＦ９０２は、ＰＤＮ接続にアクセスするために、そのデフォルトＰＤＮ接続またはある他のＰＤＮ接続を使用し得る。ＥＰＣインターワーキングサービス１００２は、ＵＥ４０２がサービスにアクセスすることを認可されていることをチェックする任務を負い得る。

代替実施形態では、Ｕ−ＳＣＥＦ９０２とＥＰＣインターワーキングサービス１００２との間の信号伝達および情報交換は、ユーザプレーンを経由して起こらないこともあり、したがって、ＰＤＮ接続を要求しないであろう。代わりに、ＥＰＣインターワーキングサービス１００２は、独立したコアネットワーク機能であり得るか、または、それは、ＭＭＥ３０４、ＳＣＥＦ１０２、マシンタイプ通信インターワーキング機能（ＭＴＣ−ＩＷＦ）、もしくはＰＣＲＦ１０４等のコアネットワークノードの中に常駐し得る。ＥＰＣインターワーキングサービス１００２は、仮想化機能として実装され得る。Ｕ−ＳＣＥＦ９０２は、ＮＡＳメッセージング等の制御プレーン信号伝達を介して、ＥＰＣインターワーキングサービス１００２と通信し得る。

ＥＰＣインターワーキングサービス１００２は、ＵＥ４０２（Ｕ−ＳＣＥＦ）とコアネットワーク（ＳＣＥＦ）との間の「コーディネータ」としての役割を果たす。ＥＰＣインターワーキングサービス１００２は、ＵＥ４０２からの調整要求を受け入れ、コアネットワークとネゴシエートし、ＵＥ４０２がその通信をより最適にスケジュールすることができるように、フィードバックをＵＥ４０２に提供する。ＥＰＣインターワーキングサービス１００２は、ＳＣＥＦ１０２の一部であり得ることに留意されたい。換言すると、Ｕ−ＳＣＥＦ９０２とＳＣＥＦ１０２とは、直接通信し得る。

図９に図示される機能性は、以下に説明される図１４Ｃまたは１４Ｄに図示されるもののうちの１つ等のＭ２Ｍネットワークのノード（例えば、サーバ、ゲートウェイ、デバイス、または他のコンピュータシステム）のメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得ることが理解される。

以下は、いくつかのユースケースを説明する。図１０に示されるようなスケジュールされたダウンロード／アップロードプロシージャは、ネットワークとのデータ転送をスケジュールするために、ＵＥ４０２によって使用される。このプロシージャは、以下の状況下で特に有用である。

ＵＥ４０２が次の２４時間内にファームウェアイメージをダウンロードすることを望むと仮定されたい。このプロシージャは、ダウンロードを行う必要があることをネットワークに伝え、ネットワークがダウンロードを行うときをＵＥ４０２に伝えることを可能にするために、ＵＥ４０２によって使用されることができる。ネットワークは、トラフィック量が比較的少ないことを予期する時間にイメージをダウンロードするようにＵＥ４０２に伝えることができる。

ＵＥ４０２が、最近、大量のセンサデータ、画像、またはビデオを記録し、情報をサーバにアップロードすることを望むと仮定されたい。このプロシージャは、アップロードを行う必要があることをネットワークに伝え、ネットワークがアップロードを行うときをＵＥ４０２に伝えることを可能にするために、ＵＥ４０２によって使用されることができる。ネットワークは、トラフィック量が比較的少ないことを予期する時間にイメージをアップロードするようにＵＥ４０２に伝えることができる。

図１０のステップ０では、Ｕ−ＳＣＥＦ９０２は、ＥＰＣインターワーキングサービス１００２と接続を確立する。これは、Ｕ−ＳＣＥＦ９０２がＥＰＣインターワーキングサービス１００２と通信するための特別なＰＤＮ接続または専用ベアラを確立することを意味し得る。接続が確立されると、Ｕ−ＳＣＥＦ９０２は、ＥＰＣインターワーキングサービス１００２に登録するためにＵ−ＳＣＥＦ登録ＡＰＩを使用する。ＥＰＣインターワーキングサービス１００２は、サポートされ、Ｕ−ＳＣＥＦ９０２がアクセスすることを許可されている特徴のリストで応答し得る。

図１０のステップ１では、アプリケーション＃２は、その識別をＵ−ＳＣＥＦ９０２に登録し、アプリケーションがアクセスすることをＵ−ＳＣＥＦ９０２が可能にするであろう特徴のリストを取得するために、アプリケーション登録Ｎ−ＡＰＩを使用する。

図１０のステップ２では、アプリケーション＃２は、午後５時の前に２ＧＢのデータをダウンロードすることを望むことをＵ−ＳＣＥＦ９０２に示すために、アプリケーションワンタイム通信スケジュールＮ−ＡＰＩを使用する。

図１０のステップ３では、Ｕ−ＳＣＥＦ９０２は、ＥＰＣインターワーキングサービス１００２から通信時間を要求するために、そのインターワーキングＰＤＮ接続、およびＵ−ＳＣＥＦワンタイム通信スケジュール要求Ｓ−ＡＰＩを使用する。

ＡＰＩコールは、ＵＥ４０２がその外部識別子でそれ自体を識別することを可能にする。ＥＰＣインターワーキングサービス１００２がステップ４で要求をＳＣＥＦ１０２に転送するとき、ＥＰＣインターワーキングサービス１００２は、その外部識別子および発信ＩＰアドレスをＳＣＥＦ１０２に提供し得る。ＳＣＥＦ１０２は、ソースＵＥ４０２を検証（認証）するために、発信ＩＰアドレスおよび外部識別子を使用し得る。例えば、ＳＣＥＦ１０２は、ＩＰアドレスが外部識別子に関連付けられるＵＥ４０２に属することを検証するために、ＨＳＳ３０２、Ｐ−ＧＷ４０４、ＰＣＲＦ１０４、ＤＨＣＰサーバ、またはＤＮＳサーバにクエリを行い得る。

図１０のステップ４では、ＥＰＣインターワーキングサービス１００２（ＡＳ／ＳＣＳ／ＡＦ／ＭＴＣサーバ／ＣＳＥとしての役割を果たす）は、データ転送要求をＳＣＥＦ１０２に転送するであろう。

図１０のステップ５では、ＳＣＥＦ１０２は、２．３で見出されるもの等のプロシージャを使用して、ＥＰＣからデータ転送時間を要求するであろう。２．３で説明されるように、ＳＣＥＦ１０２は、転送を行うための時間窓と、転送オファーに関連付けられるＳＭ参照ＩＤとを含むであろう転送ポリシオファーを取得するであろう。

図１０のステップ６では、ＳＣＥＦ１０２は、データ転送オファーでＥＰＣインターワーキングサービス１００２に応答するであろう。参考文献Ｓ２−１５１４２６で説明されるように、ＳＣＥＦ１０２は、転送を行うための時間窓と、転送オファーに関連付けられるＳＭ参照ＩＤとを含むであろう転送ポリシオファーを取得するであろう。

図１０のステップ７では、ＥＰＣインターワーキングサービス１００２は、データ転送オファーおよびＳＭ参照ＩＤをＵ−ＳＣＥＦ９０２に転送するであろう。

図１０のステップ８ａでは、Ｕ−ＳＣＥＦ９０２は、データ転送オファーおよびＳＭ参照ＩＤをアプリケーション＃２に転送するであろう。

図１０のステップ８ｂでは、Ｕ−ＳＣＥＦ９０２は、データ転送オファーの中で示される時間まで待ち、データ転送が開始するべきであるという指示をアプリケーション＃２に送信するであろう。

Ｕ−ＳＣＥＦ９０２がデータ転送オファーを受信すると、それは、オファーの中で示される時間まで、ＵＥ４０２がモバイルネットワークと通信する必要がないであろうことを推測し得る。したがって、それは、データ転送時間に近くなるまで、スリープ状態になることを選定し得る。スリープ状態になることは、クロック周波数を低下させること、メモリまたはメモリの部品をオフにすること、モデムのメモリもしくは部品への電圧を低下させること、ディスプレイを暗くすること等を伴い得る。

図１０のステップ９ａでは、アプリケーション＃２は、Ｕ−ＳＣＥＦ９０２からデータ転送オファーを受信し、示された時間まで待ち、次いで、データを転送するであろう。

図１０のステップ９ｂでは、アプリケーション＃２は、Ｕ−ＳＣＥＦ９０２から指示を受信するまで待ち、次いで、データ転送を開始するであろう。

図１０のステップ１０では、アプリケーション＃２は、アプリケーションサーバとのそのデータ転送を開始するであろう。データ転送は、ＵＥのデフォルトＰＤＮ接続におけるものあろう。

アプリケーションサーバとのデータ転送を開始することに先立って、ＵＥ４０２は、アプリケーションサーバへ、およびそこからデータを転送するために使用されるＰＤＮ接続（すなわち、ＥＰＣインターワーキングサービス１００２と通信するために使用されるＰＤＮ接続ではない）上で、ベアラリソースアクティブ化修正メッセージをＭＭＥ３０４に送信し得る。ベアラリソースアクティブ化修正プロシージャは、参考文献３ＧＰＰ ＴＳ ２３．４０１の第５．４．５節で詳述されている。ベアラリソース修正要求メッセージは、参考文献３ＧＰＰ ＴＳ ２４．３０１の第８．３．１０節（「Ｎｏｎ−Ａｃｃｅｓｓ−Ｓｔｒａｔｕｍ （ＮＡＳ） Ｐｒｏｔｏｃｏｌ ｆｏｒ Ｅｖｏｌｖｅｄ Ｐａｃｋｅｔ Ｓｙｓｔｅｍ （ＥＰＳ）」；Ｓｔａｇｅ ３）で詳述されている。ＵＥ４０２が転送ポリシ参照番号をネットワークに示すことができるように、新しい情報要素が、このメッセージに追加されることができる。参考文献３ＧＰＰ ＴＳ ２３．４０１の第５．４．５節のフローの中のメッセージは、ＭＭＥ３０４が転送ポリシ参照番号をＳ−ＧＷ４０６にパスするためにベアラリソースコマンドを使用し、Ｓ−ＧＷ４０６が転送ポリシ参照番号をＰ−ＧＷ４０４にパスするためにベアラリソースコマンドを使用するであろうように、更新されることができる。Ｐ−ＧＷ４０４は、転送ポリシ参照番号をＰＣＲＦ１０４にパスし、参照番号は、どのようなＰＣＣ規則がアクティブにされるであろうかを決定するために使用されることができる。ネットワーク（すなわち、ＰＣＥＦ２０６）は、参照番号が既知の時間に開始するであろう通信スケジュール要求に関連付けられていることを認識する。ネットワーク（すなわち、ＰＣＲＦ１０４）は、事前に編成された時間までＱｏＳが提供される必要がなく、通信が完了したとき、ＱｏＳがもはや提供される必要がないであろうことを認識する。ＰＣＲＦ１０４は、通信が完了するか、またはタイマが満了するとき、自動的にベアラを終了させ得る。

代替として、データ転送とＳＣＥＦ１０２との通信とは、同一のＰＤＮ接続上で起こることができる。

アプリケーションバッテリレベルＮ−ＡＰＩおよびＵ−ＳＣＥＦバッテリレベルＳ−ＡＰＩは、通信をスケジュールすることに先立って、ＵＥのバッテリレベルをＥＰＣインターワーキングサービス１００２に示すために使用されることができる。ＥＰＣインターワーキングサービス１００２およびコアネットワークは、ＵＥ４０２が通信するための最適時間を決定するとき、バッテリレベルを考慮し得る。例えば、低バッテリレベルは、ＵＥ４０２がすぐに通信を開始するように告げられるべきであることを示し得る。

このプロシージャは、図１１に示されるように、ネットワークとの周期的通信をスケジュールするためにＵＥ４０２によって使用される。以下のシナリオを考慮されたい。

ＵＥ４０２は、２つのアプリケーションをホストする。１つのアプリケーション（Ａｐｐ１）は、５秒毎に１回写真をキャプチャするカメラに関連付けられる。第２のアプリケーション（Ａｐｐ２）は、１０秒毎に１回データをアップロードする診断センサに関連付けられる。各アプリケーションは、それが周期的通信を行うことを望むことをＵ−ＳＣＥＦ９０２に示し、Ｕ−ＳＣＥＦ９０２は、それらの周期的通信を開始すべきときを各アプリケーションに示すであろう。したがって、Ｕ−ＳＣＥＦ９０２は、それらのそれぞれのサーバと同時に接続するか、またはほぼ同時に通信するように、アプリケーションを構成することができる。両方のアプリケーションが通信を終了したとき、ＵＥ４０２は、節電またはスリープ状態になることができる。アプリケーションが同時またはほぼ同時に通信することを確実にすることによって、節電またはスリープモードの内外への移行が低減させられる。

図１１のプロシージャは、どのようにしてＵ−ＳＣＥＦ９０２がネットワークとのＵＥの周期的通信を調整することができるかを示す。プロシージャは、ネットワークが、その周期的通信のための最適開始時間でＵＥ４０２を構成することを可能にする。したがって、多くのＵＥが周期的通信を行うことを望む場合、ネットワークは、同時に通信するＵＥの数が削減されるように、ＵＥを構成し得る。

要約すると、ＵＥ４０２上のアプリケーションは、それらの所望の周期的通信スケジュールをＵ−ＳＣＥＦ９０２に求めることができる。Ｕ−ＳＣＥＦ９０２は、集約されたスケジュールを形成するために、全てのアプリケーションの所望のスケジュールを組み合わせ、集約された通信スケジュールに基づいて、最適開始時間をネットワークに求めることができる。ネットワークは、最適開始時間をＵ−ＳＣＥＦ９０２に知らせることができ、Ｕ−ＳＣＥＦ９０２は、ＵＥ４０２が最適開始時間に通信するようにアプリケーションを構成することができる。

図１１のステップ０では、Ｕ−ＳＣＥＦ９０２は、ＥＰＣインターワーキングサービスと接続を確立する。これは、Ｕ−ＳＣＥＦ９０２がＥＰＣインターワーキングサービスと通信するための特別なＰＤＮ接続または専用ベアラを確立することを意味し得る。接続が確立されると、Ｕ−ＳＣＥＦ９０２は、ＥＰＣインターワーキングサービス１００２に登録するためにＵ−ＳＣＥＦ登録ＡＰＩを使用する。ＥＰＣインターワーキングサービス１００２は、サポートされ、Ｕ−ＳＣＥＦ９０２がアクセスすることを許可されている特徴のリストで応答し得る。

図１１のステップ１では、アプリケーション＃１は、その識別をＵ−ＳＣＥＦ９０２に登録し、アプリケーションがアクセスすることをＵ−ＳＣＥＦ９０２が可能にするであろう特徴のリストを取得するために、アプリケーション登録Ｎ−ＡＰＩを使用する。

図１１のステップ２では、アプリケーション＃２は、その識別をＵ−ＳＣＥＦ９０２に登録し、アプリケーションがアクセスすることをＵ−ＳＣＥＦ９０２が可能にするであろう特徴のリストを取得するために、アプリケーション登録Ｎ−ＡＰＩを使用する。

図１１のステップ３では、アプリケーション＃１は、５秒毎に１キロバイトのデータをアップロードすることを望むことをＵ−ＳＣＥＦ９０２に示すために、アプリケーション周期的通信スケジュールＮ−ＡＰＩを使用する。

図１１のステップ４では、アプリケーション＃２は、１０秒毎に３キロバイトのデータをアップロードすることを望むことをＵ−ＳＣＥＦ９０２に示すために、アプリケーション周期的通信スケジュールＮ−ＡＰＩを使用する。

図１１のステップ５では、Ｕ−ＳＣＥＦ９０２は、集約通信スケジュールを形成する。集約通信スケジュールは、ＵＥ４０２が、５秒毎に４キロバイトのデータ、または別の例では１０秒毎に５キロバイトのデータをアップロードすることを望むことを示す。

図１１のステップ６では、Ｕ−ＳＣＥＦ９０２は、ネットワークとの周期的通信をスケジュールするために、そのインターワーキングＰＤＮ接続およびＵ−ＳＣＥＦ周期的通信スケジュール要求Ｓ−ＡＰＩを使用する。

図１１のステップ７では、ＥＰＣインターワーキングサービス１００２は、ＡＳ／ＳＣＳとしての役割を果たし、周期的通信スケジュールをネットワークに提供する。

図１１のステップ８では、ＳＣＥＦ１０２は、通信パターンについての情報でネットワークを構成するであろう。

図１１のステップ９では、ＳＣＥＦ１０２は、ネットワークから、周期的通信パターンを確認する応答を受信するであろう。この応答は、周期的通信パターンのための最適開始時間を含むように強化され得ることに留意されたい。例えば、それは、通信が正時の１０分後に開始するべきであることを示し得る。応答は、ポリシＳＭ参照ＩＤを含むようにもアップデートされ得る。

図１１のステップ１０では、ＥＰＣインターワーキングサービス１００２は、周期的通信開始時間およびＳＭ参照ＩＤをＵ−ＳＣＥＦ９０２に転送するであろう。

図１１のステップ１１ａでは、Ｕ−ＳＣＥＦ９０２は、データ転送開始時間およびＳＭ参照ＩＤをアプリケーション１および２に転送するであろう。

図１１のステップ１１ｂでは、Ｕ−ＳＣＥＦ９０２は、データ転送オファーの中で示される時間まで待ち、データ転送が開始するべきであるという指示をアプリケーション１および２に送信する。

Ｕ−ＳＣＥＦ９０２がデータ転送オファーを受信すると、それは、オファーの中で示される時間まで、ＵＥ４０２がモバイルネットワークと通信する必要がないであろうことを推測し得る。したがって、それは、データ転送時間に近くなるまで、スリープ状態になることを選定し得る。スリープ状態になることは、クロック周波数を低下させること、メモリまたはメモリの部品をオフにすること、モデムのメモリもしくは部品への電圧を低下させること、ディスプレイを暗くすること等を伴い得る。

図１１のステップ１２ａでは、アプリケーション１および２は、Ｕ−ＳＣＥＦ９０２からデータ転送オファーを受信し、示された時間まで待ち、次いで、データを転送するであろう。

図１１のステップ１２ｂでは、アプリケーション１および２は、Ｕ−ＳＣＥＦ９０２から指示を受信するまで待ち、次いで、データ転送を開始する。

図１１のステップ１３では、アプリケーション１および２は、アプリケーションサーバとのそれらのデータ転送を開始する。データ転送は、ＵＥのデフォルトＰＤＮ接続におけるものであろう。

アプリケーションサーバとのデータ転送を開始することに先立って、ＵＥ４０２は、ベアラリソースアクティブ化修正メッセージをＭＭＥ３０４に送信し得る。ベアラリソースアクティブ化修正プロシージャは、参考文献３ＧＰＰ ＴＳ ２３の第５．４．５節で詳述されている。ベアラリソース修正要求メッセージは、参考文献３ＧＰＰ ＴＳ ２４．３０１の第８．３．１０節で詳述されている。ＵＥ４０２が転送ポリシ参照番号をネットワークに示すことができるように、新しい情報要素が、このメッセージに追加されることができる。参考文献３ＧＰＰ ＴＳ ２３．４０１の第５．４．５節のフローの中のメッセージは、ＭＭＥ３０４が転送ポリシ参照番号をＳ−ＧＷ４０６にパスするためにベアラリソースコマンドを使用し、Ｓ−ＧＷ４０６が転送ポリシ参照番号をＰ−ＧＷ４０４にパスするためにベアラリソースコマンドを使用するであろうように、更新されるであろう。Ｐ−ＧＷ４０４は、転送ポリシ参照番号をＰＣＲＦ１０４にパスし、参照番号は、どのようなＰＣＣ規則がアクティブにされるであろうかを決定するために使用されるであろう。ネットワーク（すなわち、ＰＣＥＦ２０６）は、参照番号が既知の時間に開始するであろう周期的通信スケジュール要求に関連付けられていることを認識する。ネットワーク（すなわち、ＰＣＲＦ１０４）は、ＱｏＳが予期される通信ウィンドウ外で提供される提供される必要がないであろうことを認識する。ＰＣＲＦ１０４は、設定された数の通信サイクル後、または所定数の通信サイクルがＵＥ４０２によって逃された後、自動的にベアラを終了させ得る。

代替として、データ転送とＳＣＥＦ１０２との通信とは、同一のＰＤＮ接続上で起こることができる。アプリケーションは、新しい周期的通信スケジュールをＥＰＣインターワーキングサービス１００２にパスするためにアプリケーション周期的通信スケジュールＮ−ＡＰＩを使用することによって、その周期的通信スケジュールを変更し得る。

図１２に示されるようなモビリティ指示プロシージャは、それらの予期されるモビリティをＵ−ＳＣＥＦ９０２に示すために、ＵＥ４０２上のアプリケーションによって使用される。例えば、車両ゲートウェイ上で起動するアプリケーションは、ＵＥの場所、モビリティの予期されるレベル、予期される平均速度、およびＵＥ４０２が静止しているかどうかを認識し得る。例えば、アプリケーションは、車が駐車されている場合、または充電ステーションに差し込まれている場合、ＵＥ４０２が静止しているであろうことをＵ−ＳＣＥＦ９０２に示し得る。アプリケーションは、ＵＥ４０２が高速道路上にあり、おそらく、ある時間にわたって高速で移動するであろうことを検出するために、ＧＰＳを使用し得る。

Ｕ−ＳＣＥＦ９０２は、モデムのモビリティ管理タイマを調節するためにこの情報を使用し得る。例えば、Ｕ−ＳＣＥＦ９０２は、追跡エリア更新（ＴＡＵ）のタイミングを制御するために使用されるＴ３４１２およびＴ３４３０タイマの値を決定するために、この情報を使用し得る。これらのタイマは、参考文献３ＧＰＰ ＴＳ ２４．３０１の中で定義される。

Ｕ−ＳＣＥＦ９０２は、情報がネットワークで使用される（例えば、モビリティ管理タイマを設定するために）ことができるように、モビリティ情報をＥＰＣインターワーキングサービス１００２にパスし得る。

図１２のステップ０では、Ｕ−ＳＣＥＦ９０２は、ＥＰＣインターワーキングサービスと接続を確立する。それは、Ｕ−ＳＣＥＦ９０２がＥＰＣインターワーキングサービス１００２と通信するために特別なＰＤＮ接続または専用ベアラを確立することを意味し得る。接続が確立されると、Ｕ−ＳＣＥＦ９０２は、ＥＰＣインターワーキングサービス１００２に登録するためにＵ−ＳＣＥＦ登録ＡＰＩを使用するであろう。ＥＰＣインターワーキングサービス１００２は、サポートされ、Ｕ−ＳＣＥＦ９０２がアクセスすることを許可されている特徴のリストで応答し得る。

図１２のステップ１では、アプリケーション＃１は、その識別をＵ−ＳＣＥＦ９０２に登録し、アプリケーションがアクセスすることをＵ−ＳＣＥＦ９０２が可能にするであろ特徴のリストを取得するために、アプリケーション登録Ｎ−ＡＰＩを使用する。

図１２のステップ２では、アプリケーション＃１は、予期されるモビリティ特性をＵ−ＳＣＥＦ９０２に示すために、アプリケーションモビリティ指示Ｎ−ＡＰＩを使用する。

図１２のステップ３ａでは、Ｕ−ＳＣＥＦ９０２は、モデムのモビリティ管理タイマを構成し、例えば、Ｕ−ＳＣＥＦ９０２は、追跡エリア更新（ＴＡＵ）のタイミングを制御するために使用されるＴ３４１２およびＴ３４３０タイマを調節するために、この情報を使用し得る。これらのタイマは、参考文献３ＧＰＰ ＴＳ ２４．３０１で定義される。代替として、ＵＥ４０２は、どれくらいの頻度でセル選択／再選択を行うかを調節するために、この指示を使用することができる。

図１２のステップ３ｂでは、Ｕ−ＳＣＥＦ９０２は、モビリティ指示情報をＥＰＣインターワーキングサービス１００２にパスするために、Ｕ−ＳＣＥＦモビリティ指示Ｎ−ＡＰＩを使用する。

図１２のステップ４では、ＥＰＣインターワーキングサービス１００２は、ＡＳ／ＳＣＳとしての役割を果たし、モビリティインジケータをネットワークに提供する。

図１２のステップ５では、ＳＣＥＦ１０２は、モビリティインジケータについての情報でネットワークを構成するであろう。

図１２のステップ６では、ＳＣＥＦ１０２は、ネットワークから、モビリティインジケータを確認する応答を受信するであろう。この応答は、モビリティパターン参照ＩＤを含むように強化され得る。ＭＭ参照ＩＤは、以降の時間に、ネットワークに提供されることができ（すなわち、ＵＥ４０２によって）、ネットワークは、それに応じて、そのモビリティ管理タイマを設定することができる。代替として、この応答は、Ｔ３４１２およびＴ３４４２等のモビリティ管理タイマを提供するように強化されることができる。

図１２のステップ７では、ネットワークは、モビリティインジケータに基づいて、ＵＥのＭＭタイマを調節し得る。

図１２のステップ８では、ＥＰＣインターワーキングサービス１００２は、Ｕ−ＳＣＥＦモビリティ指示Ｎ−ＡＰＩに応答するであろう。応答は、ＭＭタイマ値と、ＭＭ参照ＩＤとを含み得る。

図１２のステップ９では、Ｕ−ＳＣＥＦ９０２は、新しいＭＭタイマ値およびＭＭ参照ＩＤをモデムに提供し得る。モデムは、次に追跡エリア更新等のＭＭプロシージャを行うとき、そのＭＭタイマを調節し得る。モデムはまた、追跡エリア更新等のＭＭプロシージャを行うとき、ＭＭ参照ＩＤをネットワークに提供し得る。ＭＭ参照ＩＤは、最適ＭＭタイマ値を決定するために、ネットワーク（すなわち、ＭＭＥ３０４）によって使用され得る。

後に、アプリケーションは、新しいモビリティ指示情報をＥＰＣインターワーキングサービス１００２にパスするためにＵ−ＳＣＥＦモビリティ指示Ｎ−ＡＰＩを使用することによって、そのモビリティ状態を変更し得る。

図１０−１２に図示されるステップを行うエンティティは、図１４Ｃまたは図１４Ｄに図示されるもの等のネットワークノードもしくはコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る論理エンティティであることが理解される。すなわち、図１０−１２に図示される方法は、図１４Ｃまたは図１４Ｄに図示されるノードもしくはコンピュータシステム等のネットワークノードのメモリ内に記憶されたソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得、そのコンピュータ実行可能命令は、ノードのプロセッサによって実行されると、図１０−１２に図示されるステップを行う。図１０−１２に図示される任意の伝送および受信ステップは、ノードのプロセッサならびにそれが実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下で、ノードの通信回路によって行われ得ることも理解される。図１０−１２のエンティティは、仮想化ネットワーク機能の形態で実装され得ることが理解される。

グラフィカルユーザインターフェース（ＧＵＩ）等のインターフェースは、ユーザがモバイルコアネットワークならびにＵＥ４０２アプリケーションインターワーキングに関連する機能性を制御および／または構成することを支援するために、使用されることができる。図１３は、インターフェース１３０２を図示する略図である。ＵＥ４０２は、ユーザが、あるスケジュールを用いて通信するように、デバイスが移動しているか、静止しているかを示すように等、デバイスを構成することを可能にするＧＵＩ １３０２をサポートし得る。他の作業では、Ｎ−ＡＰＩを介してＵ−ＳＣＥＦ９０２と通信するアプリケーションは、ＧＵＩベースのアプリケーションであり得る。ＧＵＩは、構成情報をＵ−ＳＣＥＦ９０２にパスするために、上で説明されるＮ−ＡＰＩを使用し得る。インターフェース１３０２は、以下で説明される図１４Ｃ−Ｄに示されるもの等の表示を使用して、生成され得ることを理解されたい。

（追加の背景資料）
ネットワーク機能仮想化（ＮＦＶ）は、標準ＩＴ仮想化技術を進化させ、データセンタ、ネットワークノード、およびエンドユーザ構内に位置し得る業界標準大容量サーバ、スイッチ、ならびに記憶装置上に多くのネットワーク機器タイプを統合することによって、ネットワークオペレータがネットワークを設計する方法を変換することを目指す。それは、ソフトウェアにおけるネットワーク機能（例えば、モビリティ管理、セッション管理、ＱｏＳ）の実装を伴い、ソフトウェアは、広範な業界標準サーバハードウェア上で起動することができ、新しい機器の設置を必要とすることなく、要求に応じて、ネットワーク内の種々の場所に移動またはインスタンス化されることができる。ＮＦＶは、モバイルおよび固定ネットワークにおける任意のデータプレーンパケット処理と制御プレーン機能とに適用可能である。潜在的例は、以下を含み得る。
● 切り替え要素：ＢＮＧ、ＣＧ−ＮＡＴ、ルータ
● モバイルネットワークノード：ＨＬＲ／ＨＳＳ、ＭＭＥ、ＳＧＳＮ、ＧＧＳＮ／ＰＤＮ−ＧＷ、ＲＮＣ、ｅＮｏｄｅＢ
● 仮想化ホーム環境を作成するためにホームルータおよびセットトップボックスに含まれる機能
● 集中型およびネットワーク規模の機能：ＡＡＡサーバ、ポリシ制御および課金プラットフォーム
● アプリケーションレベル最適化：ＣＤＮ、キャッシュサーバ、負荷バランサ、アプリケーションアクセラレータ
● セキュリティ機能：ファイアウォール、ウイルススキャナ、侵入検出システム、スパム保護
ＮＦＶの適用は、ネットワークオペレータに多くの利益をもたらし、電気通信業界の状況の劇的な変化に貢献する。ＮＦＶは、以下の利益をもたらし得る。
● 機器を統合し、ＩＴ業界の規模の経済を活用することを通した、機器コストの削減および電力消費量の削減
● 革新の典型的ネットワークオペレータサイクルを最小化することによる、製品化までの時間の速度の増加
● 同一のインフラストラクチャ上で生産、試験、および参照設備を起動する可能性が、はるかに効率的な試験ならびに統合を提供し、開発コストおよび製品化までの時間を削減する
● 地理または顧客の組に基づく標的サービス導入が、可能である。サービスは、要求に応じて急速に拡大／縮小されることができる。
● 多種多様なエコシステムを可能にし、オープン性を促す
● 実際のトラフィック／モビリティパターンならびにサービス需要に基づいて、ほぼリアルタイムでネットワーク構成および／またはトポロジを最適化する
● マルチテナント機能をサポートし、それによって、ネットワークオペレータが、全て管理ドメインの適切でセキュアな分離を伴って同一のハードウェア上に共存する複数のユーザ、アプリケーション、または内部システム、もしくは他のネットワークオペレータのための適合サービスおよび接続性を提供することを可能にする
● 標準サーバおよび記憶装置内の電力管理特徴、ならびに作業負荷統合および場所最適化を活用することによる、エネルギー消費の削減。

Ｅｕｒｏｐｅａｎ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｓｔａｎｄａｒｄｓ Ｉｎｓｔｉｔｕｔｅ（ＥＴＳＩ）は、仕様グループ「ネットワーク機能仮想化」を形成し、いくつかのホワイトペーパを公開し、かつＮＦＶを実装することを考えているベンダおよびオペレータのための参照としての役割を果たすＮＦＶのための標準用語定義ならびにユースケースを含む、いくつかのさらに綿密な資料を生成している。

ＥＴＳＩ ＧＳ ＮＦＶ ００２，Ｎｅｔｗｏｒｋ Ｆｕｎｃｔｉｏｎｓ Ｖｉｒｔｕａｌｉｚａｔｉｏｎ （ＮＦＶ）； Ａｒｃｈｉｔｅｃｔｕｒａｌ Ｆｒａｍｅｗｏｒｋは、ＮＦＶ概念をモバイルコアネットワークに適用するためのアーキテクチャのフレームワークを確立するＥＴＳＩ刊行物である。

図１５は、ＥＴＳＩ ＧＳ ＮＦＶ ００２から複製されたＶＮＦとネスト化転送グラフとを伴う例示的エンドツーエンドネットワークサービスである。この図は、仮想化ネットワーク機能転送グラフ（ＶＮＦ−ＦＧ）の概念を図示する。ＶＮＦ−ＧＷは、どのようにしてＶＮＦの組がサービスを提供するように接続されるかを説明する。

Ｎｅｘｔ Ｇｅｎｅｒａｔｉｏｎ Ｍｏｂｉｌｅ Ｎｅｔｗｏｒｋ （ＮＧＭＮ）Ａｌｌｉａｎｃｅ，“Ｄｅｓｃｒｉｐｔｉｏｎ ｏｆ Ｎｅｔｗｏｒｋ Ｓｌｉｃｉｎｇ Ｃｏｎｃｅｐｔ”で説明されるようなネットワークスライシングは、バックホールおよびコアネットワークの両方であるモバイルオペレータのネットワークの固定部分を横断するエアインターフェースの背後の複数の「仮想」ネットワークをサポートするためにモバイルネットワークオペレータによって使用されることができる機構である。これは、異なるＲＡＮまたは単一のＲＡＮを横断して起動する異なるサービスタイプをサポートするためにネットワークを複数の仮想ネットワークに「スライスすること」を伴う。ネットワークスライシングは、オペレータが、例えば、機能性、性能、および隔離の領域で、多様な要件を要求する異なる市場シナリオのための最適化されたソリューションを提供するためにカスタマイズされたネットワークを作成することを可能にする。図１６は、ネットワークスライシングの概念的アーキテクチャを示す。異なる色が、異なるネットワークスライスインスタンスまたはサブネットワークスライスインスタンスを示すために使用される。

３ＧＰＰは、５Ｇネットワークを設計しており、５Ｇネットワークに適合するネットワークスライシング技術を組み込むことを考えている。なぜなら、５Ｇユースケース（例えば、大規模ＩｏＴ、重要通信、および拡張型モバイルブロードバンド）が、非常に多様であり、ある時は極端な要件を要求するからである。現在のアーキテクチャは、スマートフォン、ＯＴＴコンテンツ、フィーチャフォン、データカード、および組み込みＭ２Ｍデバイスからのモバイルトラフィック等の種々のサービスに適応するために、比較的モノリシックなネットワークならびにトランスポートフレームワークを利用する。現在のアーキテクチャは、各々がそれ自身の特定の性能、拡張性、および可用性要件の組を有する場合、より広範囲のビジネスニーズを効率的にサポートするために十分に柔軟かつ拡張可能ではないことが予想される。さらに、新しいネットワークサービスの導入は、より効率的にされるべきである。それでもなお、いくつかのユースケースが、同一のオペレータネットワーク内で同時にアクティブであることが予想され、したがって、５Ｇネットワークの高度な融通性および拡張性を要求する。

ネットワークスライシングは、オペレータが、例えば、機能性、性能、および隔離の領域で、多様な要件を要求する異なる市場シナリオのための最適化されたソリューションを提供するためにカスタマイズされたネットワークを作成することを可能にする。しかしながら、将来の５Ｇネットワーク内でネットワークスライシングをサポートするためにいくつかの課題および問題がある。
● ネットワークスライスインスタンス間の隔離／分離を達成する方法、および、要求されるであろう隔離／分離のレベルおよびタイプ
● ネットワークスライスインスタンス間で使用されることができるリソースおよびネットワーク機能の共有の方法およびタイプ
● ＵＥが１つのオペレータの１つ以上の特定のネットワークスライスインスタンスからサービスを同時に取得することを可能にする方法
● ネットワークスライシング（例えば、ネットワークスライス作成／構成、修正、削除）に関して、何が３ＧＰＰの範囲内であるか
● 特定のネットワークスライスインスタンスに含まれ得るネットワーク機能、およびネットワークスライスから独立しているネットワーク機能
● ＵＥのための特定のネットワークスライスの選択のためのプロシージャ
● ネットワークスライシングローミングシナリオをサポートする方法
● オペレータが、類似ネットワーク特性を要求する複数の第三者（例えば、企業、サービスプロバイダ、コンテンツプロバイダ等）を効率的にサポートするために、ネットワークスライシング概念を使用することを可能にする方法。

さらなる詳細（すなわち、問題、課題、および可能な解決策）が、どのようにして３ＧＰＰが５Ｇネットワークアーキテクチャにおいてネットワークスライシングを適用するかについて、３ＧＰＰ ＴＲ ２３．７９９，Ｓｔｕｄｙ ｏｎ Ａｒｃｈｉｔｅｃｔｕｒｅ ｆｏｒ Ｎｅｘｔ Ｇｅｎｅｒａｔｉｏｎ Ｓｙｓｔｅｍで見出され得る。

ＵＥが１つのネットワークオペレータの複数のネットワークスライスからサービスを同時に取得することを可能にするために、制御プレーン機能の単一の組が、図１７に示されるように、複数のコアネットワークインスタンスを横断して共有される。この図は、複数のネットワークスライスへの複数の接続のサポートのためのソリューションの最新情報である３ＧＰＰ Ｓ２−１６２２５９から複製された。

コアネットワークインスタンスは、制御プレーン機能の単一の組およびユーザプレーン機能の単一の組から成る。さらに、コアネットワークインスタンスは、同一のＵＥタイプに属するＵＥ専用である。ＵＥタイプを識別することは、特定のパラメータ、例えば、ＵＥ使用タイプ、および／またはＵＥのサブスクリプションからの情報を使用することによって、行われる。コアネットワークインスタンス内のユーザプレーン機能の組は、特定のサービスをＵＥに提供し、特定のサービスのデータをユーザプレーンにトランスポートする責任がある。例えば、コアネットワークインスタンス＃１におけるユーザプレーン機能の１つの組が、拡張型モバイルブロードバンドサービスをＵＥに提供する一方で、コアネットワークインスタンス＃２におけるユーザプレーン機能の別の組は、重要通信サービスをＵＥに提供する。ＵＥが最初にオペレータのネットワークに接続するとき、ＵＥ使用タイプに一致するデフォルトコアネットワークインスタンスが、ＵＥに割り当てられる。各ＵＥは、同時に異なるコアネットワークインスタンスにおいて利用可能であるユーザプレーン機能の異なる組への複数のユーザプレーン接続を有することができる。制御プレーン機能は、ネットワークスライスを横断して共有され得る。

コアネットワーク選択機能（ＣＮＳＦ）は、以下を行う責任がある。
● ＵＥのサブスクリプションおよび特定のパラメータ、例えば、ＵＥ使用タイプを考慮することによって、いずれのコアネットワークインスタンスがＵＥに適応するかを選択すること
● 基地局と通信すべき選択されたコアネットワークインスタンス内の制御プレーン機能を選択すること。制御プレーン機能のこの選択は、特定のパラメータ、例えば、ＵＥ使用タイプを使用することによって行われる。
● 異なるサービスのユーザプレーンデータをトランスポートするために、基地局が接続を確立するべきユーザプレーン機能の組を選択すること。ユーザプレーン機能のこの選択は、特定のパラメータ、例えば、ＵＥ使用タイプおよびサービスタイプを使用することによって行われる。

ネットワーク機能の相互接続を可能にするために、相互接続およびルーティング機能（ＩＲＦ）２０５８が、３ＧＰＰ ＴＲ ２３．７９９，Ｓｔｕｄｙ ｏｎ Ａｒｃｈｉｔｅｃｔｕｒｅ ｆｏｒ Ｎｅｘｔ Ｇｅｎｅｒａｔｉｏｎ Ｓｙｓｔｅｍで提案されている。図１８および図１９は、それぞれ、非ローミングおよびローミングシナリオのためのＩＲＦ２０５８の参照モデルを示す。ＩＲＦ２０５８の機能は、以下を含む。
● ＵＥの識別と、ＵＥのためのアクティブなセッションを有する各サービングＮＦのインターフェース層識別（例えば、インスタンス番号）との間のバインディングを記憶する。例えば、ローミングシナリオで、ＩＲＦ２０５８と直接インターフェースをとらないＮＦに対して、ＩＲＦ２０５８は、それを介してこれらのＮＦが到達可能である遠隔ＰＬＭＮのＩＲＦ２０５８の識別を記憶する。
● 例えば、ＵＥモビリティ、負荷再バランシング（すなわち、仮想マシンの縮小もしくは拡大）、または復元理由に起因して、サービングＮＦの識別が所与のＵＥのために変化するとき、バインディングリポジトリを更新する。
● （メッセージが送信される）ＵＥの識別および宛先ＮＦを決定するために、メッセージヘッダを調べる。ＵＥの識別に対して、宛先ＮＦのインターフェース層識別（例えば、インスタンス番号）または遠隔ＩＲＦ２０５８の識別を決定するために、内部バインディングリポジトリを調べる。それに応じて、メッセージをルーティングする。
● 随意に、オペレータの構成に基づいて、メッセージの認可を行い、例えば、オペレータの構成が、ＮＦ１がＮＦ４に向かってあるメッセージ（「ＵＥのＡＰＮ−ＡＭＢＲの変更」）を送信することを禁止する場合、ＩＲＦ２０５８は、対応するメッセージを拒否する。随意に、過負荷制御、例えば、その負荷／過負荷状態に基づいて所与のＮＦに送信されるメッセージのペーシングを行うことによって、激しい信号伝達中にＮＦを保護する。

各ＮＦは、それ自身のＰＬＭＮ内の所与の参照点を介して、ＩＲＦ２０５８とインターフェースをとる。ＮＦは、直接互いにインターフェースしないが、ＩＲＦ２０５８を介して互いに通信する（すなわち、要求または応答メッセージを送信する）ことができる。したがって、要求されるとき、このモデルは、パス内にいかなる他の無関係なネットワーク機能も伴うことなく、任意のＮＦが任意の他のＮＦと直接通信することを可能にし、例えば、ＮＦ１は、ＮＦ２の関与が必要とされない場合、ＮＦ２を伴うことなく、ＩＲＦ２０５８を介してメッセージをＮＦ３に送信することができる。

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

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

図１４Ａは、１つ以上の開示される実施形態が実装され得る、例示的マシンツーマシン（Ｍ２Ｍ）、モノのインターネット（ＩｏＴ）、またはモノのウェブ（ＷｏＴ）通信システム１０の略図である。概して、Ｍ２Ｍ技術は、ＩｏＴ／ＷｏＴのための構築ブロックを提供し、任意のＭ２Ｍデバイス、Ｍ２Ｍゲートウェイ、Ｍ２Ｍサーバ、またはＭ２Ｍサービスプラットフォームは、ＩｏＴ／ＷｏＴのコンポーネントもしくはノードならびにＩｏＴ／ＷｏＴサービス層等であり得る。通信システム１０は、開示される実施形態の機能性を実装するために使用されることができ、ＳＣＥＦ１０２、ＰＣＲＦ１０２、ＰＣＥＦ２０６、ＳＰＲ２０４、ＡＳ２０２、ＭＭＥ３０４、ＨＳＳ３０２、ＵＥ４０２、Ｓ−ＧＷ４０６、Ｐ−ＧＷ４０４、ＣＳＥ５０２、ＣＳＦ、Ｕ−ＳＣＥＦ９０２、Ｎ−ＡＰＩ ９０４、Ｓ−ＡＰＩ ９０６、ＥＰＣ９０８、ＥＰＣインターネットワーキングサービス１００２、およびＧＵＩ １３０２等のＧＵＩを生成する論理エンティティ等の機能性および論理エンティティを含むことができる。

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

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

例示的Ｍ２Ｍ端末デバイス１８は、タブレット、スマートフォン、医療デバイス、温度および気象モニタ、コネクテッドカー、スマートメータ、ゲームコンソール、携帯情報端末、保健および健康モニタ、照明、サーモスタット、電化製品、ガレージドア、および他のアクチュエータベースのデバイス、セキュリティデバイス、ならびにスマートコンセントを含むが、それらに限定されない。

図１４Ｂを参照すると、フィールドドメイン内に例証のＭ２Ｍサービス層２２は、Ｍ２Ｍアプリケーション２０、Ｍ２Ｍゲートウェイデバイス１４、ならびにＭ２Ｍ端末デバイス１８、ならびに通信ネットワーク１２のためのサービスを提供する。通信システムネットワーク１２は、開示される実施形態の機能性を実装するために使用されることができ、ＳＣＥＦ１０２、ＰＣＲＦ１０２、ＰＣＥＦ２０６、ＳＰＲ２０４、ＡＳ２０２、ＭＭＥ３０４、ＨＳＳ３０２、ＵＥ４０２、Ｓ−ＧＷ４０６、Ｐ−ＧＷ４０４、ＣＳＥ５０２、ＣＳＦ、Ｕ−ＳＣＥＦ９０２、Ｎ−ＡＰＩ ９０４、Ｓ−ＡＰＩ ９０６、ＥＰＣ９０８、ＥＰＣインターネットワーキングサービス１００２、およびＧＵＩ １３０２等のＧＵＩを生成する論理エンティティ等の機能性および論理エンティティを含むことができる。Ｍ２Ｍサービス層２２は、例えば、以下で説明される図１４Ｃおよび１４Ｄで図示されるデバイスを含む１つ以上のサーバ、コンピュータ、デバイス、仮想マシン（例えば、クラウド／記憶ファーム等）等によって実装され得る。Ｍ２Ｍサービス層２２は、所望に応じて、任意の数のＭ２Ｍアプリケーション、Ｍ２Ｍゲートウェイ１４、Ｍ２Ｍ端末デバイス１８、および通信ネットワーク１２と通信し得ることが理解されるであろう。Ｍ２Ｍサービス層２２は、サーバ、コンピュータ、デバイス等を備え得る、ネットワークの１つ以上のノードによって実装され得る。Ｍ２Ｍサービス層２２は、Ｍ２Ｍ端末デバイス１８、Ｍ２Ｍゲートウェイ１４、およびＭ２Ｍアプリケーション２０に適用されるサービス能力を提供する。Ｍ２Ｍサービス層２２の機能は、例えば、ウェブサーバとして、セルラーコアネットワークで、クラウドで等、種々の方法で実装され得る。

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

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

本願の方法は、サービス層２２および２２’の一部として実装され得る。サービス層２２および２２’は、アプリケーションプログラミングインターフェース（ＡＰＩ）および下層ネットワーキングインターフェースの組を通して付加価値サービス能力をサポートするソフトウェアミドルウェア層である。ＥＴＳＩ Ｍ２ＭおよびｏｎｅＭ２Ｍは両方とも、本願の接続方法を含み得るサービス層を使用する。ＥＴＳＩ Ｍ２Ｍのサービス層は、サービス能力層（ＳＣＬ）と称される。ＳＣＬは、Ｍ２Ｍデバイス（デバイスＳＣＬ（ＤＳＣＬ）と称される）、ゲートウェイ（ゲートウェイＳＣＬ（ＧＳＣＬ）と称される）、および／またはネットワークノード（ネットワークＳＣＬ（ＮＳＣＬ）と称される）内に実装され得る。ｏｎｅＭ２Ｍサービス層は、共通サービス機能（ＣＳＦ）（すなわち、サービス能力）の組をサポートする。１つ以上の特定のタイプのＣＳＦの組のインスタンス化は、異なるタイプのネットワークノード（例えば、インフラストラクチャノード、中間ノード、特定用途向けノード）上でホストされ得る共通サービスエンティティ（ＣＳＥ）と称される。さらに、本願の接続方法は、本願の接続方法等のサービスにアクセスするために、サービス指向アーキテクチャ（ＳＯＡ）および／またはリソース指向アーキテクチャ（ＲＯＡ）を使用するＭ２Ｍネットワークの一部として実装されることができる。

いくつかの実施形態では、Ｍ２Ｍアプリケーション２０および２０’は、開示されるシステムおよび方法と併せて使用され得る。Ｍ２Ｍアプリケーション２０および２０’は、ＵＥまたはゲートウェイと相互作用するアプリケーションを含み得、他の開示されるシステムおよび方法とも併せて使用され得る。

一実施形態では、ＳＣＥＦ１０２、ＰＣＲＦ１０２、ＰＣＥＦ２０６、ＳＰＲ２０４、ＡＳ２０２、ＭＭＥ３０４、ＨＳＳ３０２、ＵＥ４０２、Ｓ−ＧＷ４０６、Ｐ−ＧＷ４０４、ＣＳＥ５０２、ＣＳＦ、Ｕ−ＳＣＥＦ９０２、Ｎ−ＡＰＩ ９０４、Ｓ−ＡＰＩ ９０６、ＥＰＣ９０８、ＥＰＣインターネットワーキングサービス１００２、およびＧＵＩ １３０２等のＧＵＩを生成する論理エンティティ等の論理エンティティは、図１４Ｂに示されるように、Ｍ２Ｍサーバ、Ｍ２Ｍゲートウェイ、またはＭ２Ｍデバイス等のＭ２ＭノードによってホストされるＭ２Ｍサービス層インスタンス内でホストされ得る。例えば、ＳＣＥＦ１０２、ＰＣＲＦ１０２、ＰＣＥＦ２０６、ＳＰＲ２０４、ＡＳ２０２、ＭＭＥ３０４、ＨＳＳ３０２、ＵＥ４０２、Ｓ−ＧＷ４０６、Ｐ−ＧＷ４０４、ＣＳＥ５０２、ＣＳＦ、Ｕ−ＳＣＥＦ９０２、Ｎ−ＡＰＩ ９０４、Ｓ−ＡＰＩ ９０６、ＥＰＣ９０８、ＥＰＣインターネットワーキングサービス１００２、およびＧＵＩ １３０２等のＧＵＩを生成する論理エンティティ等の論理エンティティは、Ｍ２Ｍサービス層インスタンス内で、または既存のサービス能力内のサブ機能として、個々のサービス能力を備え得る。

Ｍ２Ｍアプリケーション２０および２０’は、限定ではないが、輸送、保健および健康、コネクテッドホーム、エネルギー管理、アセット追跡、ならびにセキュリティおよび監視等の種々の業界でのアプリケーションを含み得る。上記のように、システムのデバイス、ゲートウェイ、サーバ、および他のノードを横断して起動するＭ２Ｍサービス層は、例えば、データ収集、デバイス管理、セキュリティ、請求、場所追跡／ジオフェンシング、デバイス／サービス発見、およびレガシーシステム統合等の機能をサポートし、サービスとしてこれらの機能をＭ２Ｍアプリケーション２０および２０’に提供する。

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

さらに、ＳＣＥＦ１０２、ＰＣＲＦ１０２、ＰＣＥＦ２０６、ＳＰＲ２０４、ＡＳ２０２、ＭＭＥ３０４、ＨＳＳ３０２、ＵＥ４０２、Ｓ−ＧＷ４０６、Ｐ−ＧＷ４０４、ＣＳＥ５０２、ＣＳＦ、Ｕ−ＳＣＥＦ９０２、Ｎ−ＡＰＩ ９０４、Ｓ−ＡＰＩ ９０６、ＥＰＣ９０８、ＥＰＣインターネットワーキングサービス１００２、およびＧＵＩ １３０２等のＧＵＩを生成する論理エンティティ等の論理エンティティは、本願のサービスにアクセスするために、サービス指向アーキテクチャ（ＳＯＡ）および／またはリソース指向アーキテクチャ（ＲＯＡ）を使用するＭ２Ｍネットワークの一部として実装されることができる。

図１４Ｃは、Ｍ２Ｍデバイス１８、Ｍ２Ｍゲートウェイ１４、Ｍ２Ｍサーバ等のＭ２Ｍネットワークノード３０の例示的ハードウェア／ソフトウェアアーキテクチャのブロック図である。ノード３０は、ＳＣＥＦ１０２、ＰＣＲＦ１０２、ＰＣＥＦ２０６、ＳＰＲ２０４、ＡＳ２０２、ＭＭＥ３０４、ＨＳＳ３０２、ＵＥ４０２、Ｓ−ＧＷ４０６、Ｐ−ＧＷ４０４、ＣＳＥ５０２、ＣＳＦ、Ｕ−ＳＣＥＦ９０２、Ｎ−ＡＰＩ ９０４、Ｓ−ＡＰＩ ９０６、ＥＰＣ９０８、ＥＰＣインターネットワーキングサービス１００２、およびＧＵＩ １３０２等のＧＵＩを生成する論理エンティティ等の論理エンティティを実行するか、または含むことができる。

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

プロセッサ３２は、汎用プロセッサ、特殊目的プロセッサ、従来のプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアと関連する１つ以上のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、任意の他のタイプの集積回路（ＩＣ）、状態マシン等であり得る。一般に、プロセッサ３２は、ノードの種々の要求される機能を果たすために、ノードのメモリ（例えば、メモリ４４および／またはメモリ４６）内に記憶されたコンピュータ実行可能命令を実行し得る。例えば、プロセッサ３２は、信号符号化、データ処理、電力制御、入出力処理、および／またはＭ２Ｍノード３０が無線もしくは有線環境内で動作することを可能にする任意の他の機能性を果たし得る。プロセッサ３２は、アプリケーション層プログラム（例えば、ブラウザ）および／または無線アクセス層（ＲＡＮ）プログラムならびに／もしくは他の通信プログラムを起動し得る。プロセッサ３２はまた、例えば、アクセス層および／またはアプリケーション層等で、認証、セキュリティキー一致、ならびに／もしくは暗号動作等のセキュリティ動作を行い得る。

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

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

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

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

プロセッサ３２は、非取り外し可能メモリ４４および／または取り外し可能メモリ４６等の任意のタイプの好適なメモリから情報にアクセスし、そこにデータを記憶し得る。例えば、プロセッサ３２は、上で説明されるように、セッションコンテキストをそのメモリ内に記憶し得る。非取り外し可能メモリ４４は、ランダムアクセスメモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、ハードディスク、または任意の他のタイプのメモリ記憶デバイスを含み得る。取り外し可能メモリ４６は、サブスクライバ識別モジュール（ＳＩＭ）カード、メモリスティック、セキュアデジタル（ＳＤ）メモリカード等を含み得る。他の実施形態では、プロセッサ３２は、サーバまたはホームコンピュータ上等のＭ２Ｍノード３０上に物理的に位置しないメモリから情報にアクセスし、そこにデータを記憶し得る。プロセッサ３２は、ディスプレイまたはインジケータ４２上の照明パターン、画像、または色を制御し、Ｍ２Ｍサービス層セッション移行もしくは共有のステータスを反映するか、またはノードのセッション移行または共有能力もしくは設定についての入力をユーザから取得するか、または情報をユーザに表示するように構成され得る。別の例では、ディスプレイは、セッション状態に関する情報を示し得る。本開示は、ｏｎｅＭ２Ｍ実施形態においてＲＥＳＴｆｕｌユーザ／アプリケーションＡＰＩを定義する。ディスプレイ上に示され得る、グラフィカルユーザインターフェースは、ユーザが、本明細書に説明される下層サービス層セッション機能性を介して、Ｅ２Ｅセッションまたはその移行もしくは共有を双方向に確立および管理することを可能にするように、ＡＰＩの上で層化され得る。

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

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

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

ノード３０は、センサ、消費者電子機器、スマートウォッチまたはスマート衣類等のウェアラブルデバイス、医療またはｅ−ヘルスデバイス、ロボット、産業機器、ドローン、車、トラック、電車、または飛行機等の車両等の他の装置もしくはデバイスで具現化され得る。ノード３０は、周辺機器５２のうちの１つを備え得る相互接続インターフェース等の１つ以上の相互接続インターフェースを介して、そのような装置もしくはデバイスの他のコンポーネント、モジュール、またはシステムに接続し得る。代替として、ノード３０は、センサ、消費者電子機器、スマートウォッチまたはスマート衣類等のウェアラブルデバイス、医療またはｅ−ヘルスデバイス、ロボット、産業機器、ドローン、車、トラック、電車、または飛行機等の車両等の装置もしくはデバイスを備え得る。

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

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

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

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

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

さらに、コンピューティングシステム９０は、例えば、図１４Ａおよび図１４Ｂのネットワーク１２等の外部通信ネットワークにコンピューティングシステム９０を接続するために使用され得るネットワークアダプタ９７等の通信回路を含み、コンピューティングシステム９０が、ネットワークの他のノードと通信することを可能にし得る。

ユーザ機器（ＵＥ）は、通信するためにエンドユーザによって使用される任意のデバイスであることができる。これは、ハンドヘルド携帯電話、モバイルブロードバンドアダプタを具備するラップトップコンピュータ、または任意の他のデバイスであることができる。例えば、ＵＥは、図１４Ａ−ＢのＭ２Ｍ端末デバイス１８または図１４Ｃのデバイス３０として実装されることができる。

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

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

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

Claims (14)

1. プロセッサと、メモリと、通信回路とを備えているユーザ機器（ＵＥ）であって、前記ＵＥは、その通信回路を介してネットワークに接続されており、前記ＵＥは、ＵＥサービスエクスポージャ機能を備え、前記ＵＥは、前記ＵＥの前記メモリ内に記憶されたコンピュータ実行可能命令をさらに備え、前記命令は、前記ＵＥの前記プロセッサによって実行されると、
   アプリケーションから情報を受信することであって、前記アプリケーションは、前記ＵＥに位置している、ことと、
   前記ネットワークにおけるコアネットワークが備えるコアネットワークサービスエクスポージャ機能と前記ＵＥサービスエクスポージャ機能との接続を確立するための要求を前記ネットワークに送信することと、
   前記情報を含むメッセージを前記接続を介して前記コアネットワークサービスエクスポージャ機能に送信することと、
   前記コアネットワークサービスエクスポージャ機能から応答を受信することと
   を含む動作を前記ＵＥに行わせる、ＵＥ。
2. 前記コアネットワークサービスエクスポージャ機能と認証するための要求を送信することをさらに含む、請求項１に記載のＵＥ。
3. 前記メッセージは、所望のスケジュールを示す、請求項１に記載のＵＥ。
4. 前記所望のスケジュールは、前記ＵＥにおける複数のアプリケーションからの入力を反映する、請求項３に記載のＵＥ。
5. 前記メッセージは、前記ＵＥのためのモビリティ情報を示す、請求項１に記載のＵＥ。
6. 前記コアネットワークサービスエクスポージャ機能からの前記応答は、参照番号を前記ＵＥに提供する、請求項１に記載のＵＥ。
7. セッション管理またはモビリティ管理メッセージの中で前記参照番号を前記コアネットワークに提供することをさらに含む、請求項６に記載のＵＥ。
8. 前記応答は、スケジュールを含み、前記ＵＥは、前記スケジュールを使用して通信する、請求項１に記載のＵＥ。
9. 前記応答は、１つ以上のモビリティ管理タイマ値を含み、前記ＵＥは、前記１つ以上のモビリティ管理タイマ値を前記コアネットワークに送信する、請求項１に記載のＵＥ。
10. 前記メッセージは、前記ＵＥのためのバッテリレベル情報を示す、請求項１に記載のＵＥ。
11. ユーザ機器（ＵＥ）によって使用するための方法であって、前記ＵＥは、プロセッサと、メモリと、通信回路とを備え、前記ＵＥは、ＵＥサービスエクスポージャ機能を備え、前記ＵＥは、その通信回路を介してネットワークに接続されており、前記ＵＥは、前記ＵＥの前記メモリ内に記憶されたコンピュータ実行可能命令をさらに備え、前記命令は、前記プロセッサによって実行されると、
    アプリケーションから情報を受信することであって、前記アプリケーションは、前記ＵＥに位置している、ことと、
    前記ネットワークにおけるコアネットワークが備えるコアネットワークサービスエクスポージャ機能と前記ＵＥサービスエクスポージャ機能との接続を確立するための要求を前記ネットワークに送信することと、
    前記情報を含むメッセージを前記接続を介して前記コアネットワークサービスエクスポージャ機能に送信することと、
    前記コアネットワークサービスエクスポージャ機能から応答を受信することと
    を含む方法の機能を果たす、方法。
12. 前記メッセージは、所望のスケジュールを示し、前記所望のスケジュールは、前記ＵＥにおける複数のアプリケーションからの入力を反映する、請求項１１に記載の方法。
13. 前記メッセージは、前記ＵＥのためのモビリティ情報を示す、請求項１１に記載の方法。
14. 一又は複数のユーザ機器（ＵＥ）と通信するネットワークによって使用するための方法であって、前記ネットワークは、コアネットワークの機能として、コアネットワークサービスエクスポージャ機能を備え、前記方法は、
    アプリケーションから情報を受信することであって、前記アプリケーションは、前記ＵＥに位置している、ことと、
    前記コアネットワークサービスエクスポージャ機能と前記一又は複数のＵＥが備えるＵＥサービスエクスポージャ機能との接続を確立するための要求を前記一又は複数のＵＥから受信することと、
    前記一又は複数のＵＥがアプリケーションから受信した情報を含むメッセージを前記接続を介して前記ＵＥサービスエクスポージャ機能から受信することであって、前記アプリケーションは前記一又は複数のＵＥに位置することと、
    前記コアネットワークサービスエクスポージャ機能から前記ＵＥサービスエクスポージャ機能への応答を送信すること
    を含む方法の機能を果たす、方法。