JP7190031B2 - 通信システムにおいてアプリケーションごとにポリシルールを実行するための方法およびデバイス - Google Patents

Description

本開示は、一般に、通信システムの分野に関し、より詳細には、第５世代（５Ｇ）通信ネットワークなどの通信システムのコアネットワーク内のサービスベースアーキテクチャ（ＳＢＡ）ドメインにおけるアプリケーションに関連するポリシルールの実行に関する。

第５世代（５Ｇ）通信コアネットワークアーキテクチャは、ネットワーク機能（ＮＦ）が、特定のＮＦからの通信サービスを必要とするエンティティに１つまたは複数のサービスを提供する、サービスベースアーキテクチャ（ＳＢＡ）の一例である。さらに、ＮＦは、例えば、別のＮＦからの通信サービスを要求することもできる。コアネットワーク（ＣＮ）のＮＦは、独立した方法で、すなわち、他のＮＦに影響を与えることなく、変更および更新され得る自己完結型の機能である。

アプリケーション機能（ＡＦ）は、トラフィックプレーンリソースのポリシおよび課金制御を必要とするアプリケーションを提供する要素であり、例えば、
－ トラフィックルーティングに対するアプリケーションの影響、
－ ポリシ制御のためのポリシフレームワークとの対話、および
－ ネットワーク公開機能（ＮＥＦ）へのアクセス
をサポートするサービスを提供するために、第３世代パートナーシッププロジェクト（３ＧＰＰ）コアネットワークと対話する。

例えば、信頼できると見なされるＡＦは、オペレータの展開に基づいて、ポリシ制御機能（ＰＣＦ）、セッション管理機能（ＳＭＦ）、およびユーザプレーン機能（ＵＰＦ）などの他の関連するＮＦと直接対話することを許可されてもよい。オペレータによって他のＮＦに直接アクセスすることを許可されていないＡＦは、ＮＥＦを介して、外部公開フレームワークを使用して他の関連するネットワーク機能と対話するものとする。

ポリシ制御機能（ＰＣＦ）は、とりわけ、次の機能を含む。
－ ネットワークの挙動を管理するための統合ポリシフレームワークをサポートすること、
－ 制御プレーン機能（ＣＰＦ）に、制御プレーン機能（ＣＰＦ）を施行するためのポリシルールを提供すること、および
－ 統合データリポジトリ（ＵＤＲ）内のポリシ決定に関連するサブスクリプション情報へのアクセス。

セッション管理機能（ＳＭＦ）は、セッションの確立、変更、解放などの様々な機能、
ならびに、ポリシ制御機能に対するインターフェースの終了、課金データ収集、課金インターフェースのサポート、およびＵＰＦでの課金データ収集の制御および調整のような、ポリシ関連の機能をサポートする。

ユーザプレーン機能（ＵＰＦ）は、例えば、パケットインスペクション、パケットルーティングおよびパケット転送、トラフィック使用レポート、ならびに、アップリンク／ダウンリンク（ＵＬ／ＤＬ）レート施行などのユーザプレーンをハンドリングするためのサービス品質（ＱｏＳ）を含む、ユーザプレーントラフィックのハンドリングをサポートする。

統合データ管理（ＵＤＭ）は、認証資格情報リポジトリおよび処理機能（ＡＲＰＦ）をサポートし、３ＧＰＰ ５Ｇアーキテクチャにおける認証および鍵合意（ＡＫＡ）プロシージャで使用されるロングタームセキュリティ資格情報を記憶する。

５Ｇシステムアーキテクチャにより、ＵＤＭ、ＰＣＦ、およびＮＥＦは、サブスクリプションデータおよびポリシデータと、公開用の構造化データと、ＮＥＦによるアプリケーション検出用のパケットフローの説明（ＰＦＤ）を含むアプリケーションデータとを含むデータを、ＵＤＲに記憶することが可能になる。

コンテンツプロバイダは、例えば、アプリケーショントラフィックの高ＱｏＳまたは課金処理など、特定のデータハンドリングを適用するネットワークサービスに関心がある場合がある。これを実現するために、コンテンツプロバイダは通常、特定のアプリケーションに提供されるサービスのレベルに関連して、１つまたは複数のネットワークオペレータとサービスレベル契約（ＳＬＡ）を締結する。

現在の３ＧＰＰ標準では、ポリシおよび課金制御をユーザごと、またはプロトコルデータユニット（ＰＤＵ）セッションごとに適用する必要があると指定されている。ポリシおよび課金制御フレームワークには、コンテンツプロバイダが、例えば、比較的多くの加入者を有するソーシャルメディアタイプのアプリケーションなどの、すべてのユーザセッションに対してアプリケーションごとに一定のＱｏＳまたは課金処理を要求できるメカニズムがない。

ＡＦとＮＥＦとの間の既存のノースバウンドアプリケーションプログラミングインターフェース（ＡＰＩ）により、コンテンツプロバイダは、一定のアプリケーションについてであるが個別のユーザセッションごとに、一定のＱｏＳ、例えば、高ＱｏＳ、またはスポンサデータなどの特別な課金を要求することが可能になる。これは、例えば、ノースバウンドＡＰＩの場合、現在３ＧＰＰ標準で規定されている「必要なＱｏＳを使用したＡＳセッションのセットアップ」または「セッションのセットアップ時またはセッション中に課金対象のパーティを変更する」について当てはまる。

米国特許出願第２０１７３１７８９４号では、ネットワーク内からネットワーク外のエンティティまでのサービス品質レベルへのアクセスを提供するための方法およびシステムが開示されている。

さらに、出版物「５Ｇ Ｓｙｓｔｅｍ ｄｅｔａｉｌｓ ｆｏｒ ＰＣＣ」、３ＧＰＰ ＤＲＡＦＴ、Ｓ２－１７３２１０ ２３２０３－Ｅ４０＿５ＧＵＰＤＡＴＥＳ＿ＰＡ２、第３世代パートナーシッププロジェクト（３ＧＰＰ）、ＭＯＢＩＬＥ ＣＯＭＰＥＴＥＮＣＥ ＣＥＮＴＲＥ、６５０、ＲＯＵＴＥ ＤＥＳ ＬＵＣＩＯＬＥＳ、Ｆ－０６９２１ ＳＯＰＨＩＡ－ＡＮＴＩＰＯＬＩＳ ＣＥＤＥＸ、ＦＲＡＮＣＥ、ｖｏｌ．ＳＡ ＷＧ２、ｎｏ．Ｓａｎ Ｊｏｓｅ Ｄｅｌ Ｃａｂｏ、２０１７０６２６－２０１７０６３０ ２０１７年６月２５日（２０１７－０６－２５）、ＸＰ０５１３０３０６５を参照する。

したがって、ＳＢＡにおいて、データの処理およびトラフィックの課金処理に関連するサービス機能をアプリケーションベースで実装する必要がある。

本開示の第１の態様では、通信システムのコアネットワーク内のサービスベースアーキテクチャ（ＳＢＡ）ドメインにおいてユーザセッション内でユーザ機器（ＵＥ）によってアクセスされるべきアプリケーションのためのアプリケーションルールを実装する方法が提示され、ＳＢＡは、とりわけ、ポリシ制御機能（ＰＣＦ）、アプリケーション機能（ＡＦ）、ユーザプレーン機能（ＵＰＦ）、およびセッション管理機能（ＳＭＦ）を備える。

方法は、ＰＣＦによって、それぞれのアプリケーションルールを識別するＡＦ識別子（ＡＦ－ＩＤ）と、それぞれのアプリケーションを識別するアプリケーション識別子（Ａｐｐ－ＩＤ）と、ＳＢＡドメイン内のそれぞれのアプリケーションをサービスするための少なくとも１つのサービス要件とを含むアプリケーションルールを受信するステップであって、アプリケーションルールが、既存のポリシ課金および制御（ＰＣＣ）ルールと異なり、既存のセッションごとのＰＣＣルールよりも優先順位が高い、アプリケーションルールを受信するステップと、ＰＣＦによって、それぞれのアプリケーションに関連する現在および将来のすべてのユーザセッションに対して少なくとも１つのサービス要件を実行するようにＳＭＦに命令するステップとを含む。

その第１の態様では、本開示は、アプリケーションごとにＳＢＡ通信システム内のデータをハンドリングするためにＰＣＦ内に実装される特別な一連のポリシルールを提供する。それぞれのポリシまたはアプリケーションルールは、そのＡＦ－ＩＤによって識別され、アプリケーションルールが関連するアプリケーションは、Ａｐｐ－ＩＤによって識別され、一方、提供される１つまたは複数のサービスは、少なくとも１つのサービス要件によって規定される。

通信システム内の特定のアプリケーションの均一な処理またはサービスを保証するために、ＰＣＦは、それぞれのアプリケーションに関連する現在および将来のすべてのユーザセッションに対して少なくとも１つのサービス要件を実行するようにＳＭＦに命令するように設定される。

例えば、５Ｇ ＳＢＡでは、ＰＣＦは、ＡＦ－ＩＤ、Ａｐｐ－ＩＤ、およびそれぞれのサービス要件を含む、ＳＭＦへのＮｓｍｆ ＨＴＴＰ ＰＯＳＴメッセージをトリガすることによって、ＳＭＦにアプリケーションルールをインストールすることができる。これらのアプリケーションルールは、特定のユーザセッションに適用されるのではなく、任意の既存または現在および将来のユーザセッションに適用されるので、既存のポリシ課金および制御（ＰＣＣ）ルールとは異なることに留意されたい。

代替として、ＰＣＦは、ユーザセッションごとに、サービスの変更を必要とし、ＰＣＣルールの変更をトリガする、既存のすべてのユーザセッションを識別することができるが、その結果、メッセージが多くなり、特に、ソーシャルメディアタイプのアプリケーションなどの広範囲に使用されるアプリケーションの場合、ネットワーク内のシグナリングが大幅に増加することになる。

本開示による解決策は、ＰＣＦにそれぞれのアプリケーションルールを実装するだけで、特定のコンテンツプロバイダまたは異なるコンテンツプロバイダの１つまたは複数のアプリケーションのためにＳＢＡドメインで交換されるデータの柔軟なサービスを可能にする。

本開示の一例では、特定のアプリケーションルールにおいて、個々のユーザまたはセッションごとにデータまたはトラフィックをハンドリングするためにＳＢＡドメインで利用可能なすべてのサービス要件を指定することができるが、アプリケーションルールは、ＵＥによってアクセスされるべきアプリケーションに関連するユーザセッションをハンドリングする特定のサービス品質（ＱｏＳ）、および／または、ＵＥによってアクセスされるべきアプリケーションに関連するユーザセッションのための特定の課金プロファイルのうちの少なくとも１つを含む。

すなわち、コンテンツプロバイダのそれぞれのアプリケーションと、アプリケーションルールが実装および施行される特定のアプリケーションにアクセスするシステム内のすべてのＵＥとの間で交換されるデータは、それぞれのアプリケーションルールで指定された、例えば、デフォルトのＱｏＳよりも優れた、必要とされるＱｏＳを受信し、かつ／または、特定の合意された、例えば、割引された料金または費用に対して課金される。

当業者には、ＰＣＦが、そのアプリケーションを使用する既存および将来のすべてのユーザセッションに対して少なくとも１つのサービス要件を実行するようにＳＭＦに命令すると、サービス要件は、ＳＭＦで実行され得るが、場合によっては、ＵＰＦでの実行が必要になる場合があることが理解されよう。例えば、ＱｏＳ帯域幅制限は、ＳＭＦがそのＳＭＦ自体で実行できないサービス要件であり、したがって、ＳＭＦは、アプリケーションごとに、新しいＮ４プロシージャを介して実行するようにＵＰＦに命令する必要がある場合がある。したがって、命令するステップは、追加として、ＳＭＦによって、ＰＣＦによってＳＭＦに提供されたアプリケーションルールを実行するようにＵＰＦに命令するステップを含んでもよい。

ＳＢＡドメインが統合データリポジトリ（ＵＤＲ）を備える一実施形態によれば、方法は、ＰＣＦによって、受信されたアプリケーションルールを、特にそれぞれのユーザセッションポリシルールに関連付けてアプリケーションルールとしてＵＤＲに記憶するために、ＵＤＲに送信するステップと、ＰＣＦによって、アプリケーションルールの記憶を確認するメッセージをＵＤＲから受信するステップとをさらに含む。

アプリケーションルールは、ユーザセッション、すなわち、プロトコルデータユニット（ＰＤＵ）セッションに関連する既存のポリシルール、およびそれぞれのアプリケーションデータに関連付けて、ＵＤＲに記憶されてもよい。例えば、個人またはユーザセッションごとに指定されたもの以外の特定のＱｏＳおよび／または課金処理を指定するアプリケーションルールの場合、このアプリケーションルールは、それぞれのユーザセッションごとのＱｏＳおよび／または課金ポリシルールに関連付けて、記憶される。当業者であれば、それぞれのアプリケーションについて、いくつかの異なるアプリケーションルールが記憶され得ることを理解するであろう。

ＵＥによるＰＤＵセッションの開始時に特定のアプリケーションルールを適用するために、本開示のさらなる実施形態は、ＰＣＦによって、ＰＤＵセッションのための少なくとも１つのポリシルールを取得することを求める要求を、ＳＭＦから受信するステップと、ＰＣＦによって、ＰＤＵセッションのための少なくとも１つのアプリケーションルールを含む記憶されたアプリケーションルール、またはそれぞれの記憶されたアプリケーションルールを、ＵＤＲから取得するステップと、ＰＣＦによって、取得されたポリシおよびアプリケーションルールをＳＭＦに提供するステップとを含む。

アプリケーションルールは、利用可能な場合、既存のユーザセッションごとまたはＰＤＵセッションごとのポリシルールよりも優先順位が高いと仮定している。しかしながら、本開示によれば、例えば、ユーザセッションに関連する他のポリシルールに勝る、アプリケーションルールの特定の優先度または優先順位レベルを示す優先順位パラメータが、アプリケーションルールに実装されてもよい。

一実施形態によれば、ＰＣＦは、特定の処理を必要とするアプリケーションをハンドリングするアプリケーションルールを、アプリケーション機能（ＡＦ）から受信してもよい。しかしながら、別の例示的な実施形態によれば、ＰＣＦはまた、アプリケーションルールを、ネットワークオペレータから受信してもよい。

本開示の第２の態様では、通信システムのコアネットワーク内のサービスベースアーキテクチャ（ＳＢＡ）ドメインにおいてユーザセッション内でユーザ機器（ＵＥ）によってアクセスされるべきアプリケーションのためのアプリケーションルールの実行をサポートする方法が提示され、ＳＢＡは、とりわけ、ポリシ制御機能（ＰＣＦ）、アプリケーション機能（ＡＦ）、ユーザプレーン機能、およびセッション管理機能（ＳＭＦ）を備える。

第２の態様による方法は、ＳＭＦによって、アプリケーションに関連する現在および将来のすべてのユーザセッションに対して所望のアプリケーションルールを実行するようにＳＭＦに命令する命令を、ＰＣＦから受信するステップであって、所望のアプリケーションルールが、既存のポリシ課金および制御（ＰＣＣ）ルールと異なり、既存のセッションごとのＰＣＣルールよりも優先順位が高い、命令を受信するステップと、ＳＭＦによって、所望のアプリケーションルールが適用可能であるユーザセッションを識別するステップと、ＳＭＦによって、識別されたユーザセッションに対して所望のアプリケーションルールを実行するステップとを含む。

ＳＭＦは、ＱｏＳの変更および／または新しい課金ハンドリングなどのサービスの変更を必要とするアクティブなユーザセッションを識別し、それぞれのセッションごとに１つまたは複数の新しいサービス要件を適用する。ＳＭＦは、例えば、５Ｇ ＳＢＡの場合、ＰＣＦにＮｓｍｆ ２００ ＯＫ成功応答で応答してもよい。

一実施形態によれば、受信される命令は、ＡＦ識別子（ＡＦ－ＩＤ）と、アプリケーション識別子（Ａｐｐ－ＩＤ）と、ＳＢＡドメイン内のアプリケーションを処理するための少なくとも１つのサービス要件とを含み、識別されるユーザセッションは、ＡＦ－ＩＤおよびＡｐｐ－ＩＤに基づいて識別される。

本開示の第３の態様では、通信システムのコアネットワーク内のサービスベースアーキテクチャ（ＳＢＡ）ドメインにおいてユーザセッション内でユーザ機器（ＵＥ）によってアクセスされるべきアプリケーションルールの実行をサポートする方法が提示され、ＳＢＡは、とりわけ、ポリシ制御機能（ＰＣＦ）、アプリケーション機能（ＡＦ）、および統合データリポジトリ（ＵＤＲ）を備える。

第３の態様による方法は、ＵＤＲによって、ＵＥによってアクセスされるべきアプリケーションに適用可能なアプリケーションルールを、ＰＣＦから受信するステップであって、受信されたアプリケーションルールが、既存のポリシ課金および制御（ＰＣＣ）ルールと異なり、既存のセッションごとのＰＣＣルールよりも優先順位が高い、アプリケーションルールを受信するステップと、ＵＤＲによって、受信されたアプリケーションルールを記憶するステップと、ＵＤＲによって、ユーザセッションに適用可能なアプリケーションルールを求める要求を、ＰＣＦから受信するステップであって、要求が、ＵＥによってアクセスされるべきアプリケーションを識別する、要求を受信するステップと、ＵＤＲによって、ＵＤＲに記憶されている要求されたアプリケーションルールをＰＣＦに送信するステップとを含む。

例えば、５ＧベースのＳＢＡドメインの場合、新しいユーザＰＤＵセッションについては、ＵＥが、ＳＢＡドメインのアクセスおよびモビリティ管理機能（ＡＭＦ）に、ＰＤＵセッション確立要求を送ることによって、ＰＤＵセッション確立をトリガする。ＡＭＦは、ＳＭＦを選択し、Ｎｓｍｆ ＰＤＵセッション作成をトリガする。続いて、ＳＭＦは、Ｎｐｃｆ＿ＳＭＰｏｌｉｃｙＣｏｎｔｒｏｌ＿Ｃｒｅａｔｅ Ｒｅｑｕｅｓｔメッセージをトリガして、ユーザＰＤＵセッションのセッション管理（ＳＭ）ポリシを取得する。ＰＣＦは、Ｎｕｄｒ＿ＤＭ＿Ｑｕｅｒｙ Ｒｅｑｕｅｓｔメッセージをトリガして、このユーザＰＤＵセッションのポリシデータを取得する。ＵＤＲは、サブスクライバポリシデータを含むＮｕｄｒ＿ＤＭ＿Ｑｕｅｒｙ Ｒｅｓｐｏｎｓｅメッセージで返答する。ＵＤＲはまた、ＡＦ－ＩＤ、Ａｐｐ－ＩＤ、および、例えばデフォルトのＱｏＳよりも優れていることを示すＱｏＳ基準などのサービス要件を含む、アプリケーションデータ、ならびに課金プロファイル、例えばスポンサデータを返してもよく、これにより、アプリケーショントラフィックは、エンドユーザではなく、コンテンツプロバイダに課金される。

本開示の第４の態様では、通信システムのコアネットワーク内のサービスベースアーキテクチャ（ＳＢＡ）ドメインにおけるポリシ制御機能（ＰＣＦ）が提示され、ＳＢＡは、とりわけ、アプリケーション機能（ＡＦ）およびセッション管理機能（ＳＭＦ）をさらに備え、ＰＣＦは、ＳＢＡドメインにおいてユーザセッション内でユーザ機器（ＵＥ）によってアクセスされるべきアプリケーションを実装するように設定される。

ＰＣＦは、それぞれのアプリケーションルールを識別するＡＦ識別子（ＡＦ－ＩＤ）と、アプリケーションを識別するアプリケーション識別子（Ａｐｐ－ＩＤ）と、ＳＢＡドメイン内のアプリケーションを処理するための少なくとも１つのサービス要件とを含むアプリケーションルールを受信するように設定された受信機器であって、アプリケーションルールが、既存のポリシ課金および制御（ＰＣＣ）ルールと異なり、既存のセッションごとのＰＣＣルールよりも優先順位が高い、受信機器と、アプリケーションに関連する現在および将来のすべてのユーザセッションに対して少なくとも１つのサービス要件を実行するようにＳＭＦに命令するように設定された命令機器とを備える。

一実施形態によれば、ＳＢＡドメインは、統合データリポジトリ（ＵＤＲ）を備え、ＰＣＦは、受信されたアプリケーションルールをＵＤＲに記憶するためにＵＤＲに送信するように設定された送信機器をさらに備え、受信機器は、アプリケーションデータの記憶を確認するメッセージをＵＤＲから受信するようにさらに設定される。

一実施形態では、受信機器は、プロトコルデータユニット（ＰＤＵ）セッションのためのアプリケーションルールを取得するための要求をＳＭＦから受信するようにさらに設定され、ＰＣＦは、ＰＤＵセッションのための記憶されたアプリケーションルールおよびアプリケーションデータをＵＤＲから取得するように設定された取得機器と、取得されたアプリケーションルールをＳＭＦに提供するように設定された提供機器とをさらに備える。

本開示の第５の態様では、通信システムのコアネットワーク内のサービスベースアーキテクチャ（ＳＢＡ）ドメインにおけるセッション管理機能（ＳＭＦ）が提示され、ＳＢＡは、とりわけ、アプリケーション機能（ＡＦ）、ユーザプレーン機能（ＵＰＦ）、およびポリシ制御機能（ＰＣＦ）をさらに備え、ＳＭＦは、ＳＢＡドメインにおいてユーザセッション内でユーザ機器（ＵＥ）によってアクセスされるべきアプリケーションの実装をサポートするように設定される。

ＳＭＦは、アプリケーションに関連する現在および将来のすべてのユーザセッションに対して所望のアプリケーションルールを実行するようにＳＭＦに命令する命令を、ＰＣＦから受信するように設定された受信機器であって、所望のアプリケーションルールが、既存のポリシ課金および制御（ＰＣＣ）ルールと異なり、既存のセッションごとのＰＣＣルールよりも優先順位が高い、受信機器と、所望のアプリケーションルールが適用可能であるユーザセッションを識別するように設定された識別機器と、識別されたユーザセッションに対して所望のアプリケーションルールを実装するように設定された実装機器とを備える。

当業者には、ＰＣＦが、そのアプリケーションを使用する既存および将来のすべてのユーザセッションに対して少なくとも１つのサービス要件を実行するようにＳＭＦに命令すると、サービス要件は、ＳＭＦで実行され得るが、場合によっては、ＵＰＦでの実行が必要になる場合があることが理解されよう。例えば、ＱｏＳ帯域幅制限は、ＳＭＦがそのＳＭＦ自体で実行できないサービス要件であり、したがって、ＳＭＦは、アプリケーションごとに、新しいＮ４プロシージャを介して実行するようにＵＰＦに命令する必要がある場合がある。したがって、アプリケーションルールがＳＭＦで直接実行可能ではなく、ＵＰＦまたはその他のノードで実行可能であるような状況では、実装機器は、アプリケーションルールを実装するために、前記アプリケーションルールをＵＰＦまたはその他のノードに送信するようにさらに設定されてもよい。

本開示の第６の態様では、通信システムのコアネットワーク内のサービスベースアーキテクチャ（ＳＢＡ）ドメインにおける統合データリポジトリ（ＵＤＲ）が提示され、ＳＢＡは、とりわけ、ポリシ制御機能（ＰＣＦ）、アプリケーション機能（ＡＦ）、およびセッション管理機能（ＳＭＦ）をさらに備え、ＵＤＲは、通信システム内のユーザ機器（ＵＥ）によってアクセスされるべきアプリケーションのためのアプリケーションルールの実装をサポートするように設定される。

ＵＤＲは、ＵＥによってアクセスされるべきアプリケーションに適用可能なアプリケーションルールをＰＣＦから受信するように設定された受信機器であって、アプリケーションルールが、アプリケーションルールが、既存のポリシ課金および制御（ＰＣＣ）ルールと異なり、既存のセッションごとのＰＣＣルールよりも優先順位が高い、受信機器と、受信されたアプリケーションルールを記憶するように設定された記憶機器とを備える。受信機器は、ユーザセッションに適用可能なアプリケーションルールを求める要求を、ＰＣＦから受信するようにさらに設定され、要求は、ＵＥによってアクセスされるべきアプリケーションを識別し、送信機器は、ＵＤＲの記憶機器に記憶されている要求されたアプリケーションルールを、ＰＣＦに送信するように設定される。

本開示の第７の態様では、コンピュータ可読記憶媒体を含み、ＳＢＡドメインで動作する少なくとも１つのプロセッサ上で実行されると、少なくとも１つのプロセッサに、本開示の第１、第２、および第３の態様のうちのそれぞれ１つによるサービスを実行するための処理ステップを実行させる命令を記憶する、コンピュータプログラム製品が提供される。

開示されるエンティティおよびモジュールは、別個のハードウェアおよび／またはソフトウェアのモジュールならびにエンティティとして実装されてもよく、プロセッサなどによって制御されるか、またはプロセッサなどで実行されてもよいことが理解されよう。

本開示の上記および他の特徴ならびに利点が、添付の図面を参照する以下の説明から最もよく理解されるであろう。図面において、同様の参照番号は、同一の部品、または同一もしくは同等の機能または動作を実行する部品を示す。

従来技術による第５世代（５Ｇ）通信システムの基準アーキテクチャの一部の概略図である。 本開示による方法の概略図である。 本開示によるポリシ制御機能（ＰＣＦ）ノードの概略図である。 本開示によるセッション管理機能（ＳＭＦ）ノードの概略図である。 本開示による統合データリポジトリ機能（ＵＤＲ）の概略図である。

次に、本開示により企図される実施形態について、添付の図面を参照してより詳細に説明する。しかしながら、本明細書に開示される主題の範囲内に、他の実施形態が含まれる。開示される主題は、本明細書に記載の実施形態のみに限定されると解釈されるべきではない。むしろ、例示された実施形態は、主題の範囲を当業者に伝えるために、例として提供されている。

図１は、第５世代（５Ｇ）サービスベースアーキテクチャ（ＳＢＡ）通信ネットワークの
の既知の基準アーキテクチャ１の概略図である。５Ｇシステムアーキテクチャは、次のネットワーク機能（ＮＦ）を備える。
－ アクセスおよびモビリティ管理機能（ＡＭＦ）８
－ ネットワーク公開機能（ＮＥＦ）３
－ ポリシ制御機能（ＰＣＦ）６
－ セッション管理機能（ＳＭＦ）９
－ 統合データリポジトリ（ＵＤＲ）２
－ ユーザプレーン機能（ＵＰＦ）１０
－ アプリケーション機能（ＡＦ）５
－ ネットワークデータ分析機能（ＮＷＤＡＦ）４
－ 課金機能（ＣＨＦ）７

これらのネットワーク機能の機能説明は、第３世代パートナーシッププロジェクト（３ＧＰＰ）標準２３．５０１、「５Ｇシステムのシステムアーキテクチャ」の第６章に定められており、その内容は参照により本明細書に含まれる。

提案される解決策により、コンテンツプロバイダ（またはネットワークオペレータ）は、アプリケーションルールを実装および実行することによって、特定のサービス品質（ＱｏＳ）および／または課金ハンドリングなどの特定の１つまたは複数のサービス要件を、例えばアプリケーションごとに、実行することができる。

図２に示すシーケンス図は、コンテンツプロバイダ、例えばソーシャルメディアアプリケーションのコンテンツプロバイダが、ＳＢＡ通信システムで交換されるデータにデフォルトのＱｏＳよりも優れたＱｏＳを適用すること、および／またはそれぞれのソーシャルメディアアプリケーションによって交換されるデータに特定の課金ハンドリングを適用することを要求する事例を示す。

最初のステップにおいて、コンテンツプロバイダは、ネットワークオペレータのＮＥＦ３に対して、ノースバウンドアプリケーションプログラミングインターフェース（ＡＰＩ）の新しいプロシージャをトリガすることによって、対象のアプリケーション用のデフォルトのＱｏＳよりも優れたＱｏＳ、および／または一定の課金ハンドリングを申請する６１。以下に説明するように、第３世代パートナーシッププロジェクト（３ＧＰＰ）技術仕様（ＴＳ）２９．５２２において、新しいＡＰＩ「アプリケーションの特定のＱｏＳおよび／または課金ハンドリングを要求するための、ＡＦ５のプロシージャ」を規定することが提案されている。

コンテンツプロバイダは、ＡＦ５を介して、ＨＴＴＰ ＰＯＳＴメッセージをＮＥＦ３に送る６２。ＨＴＴＰ ＰＯＳＴメッセージの本文は、アプリケーションルールを識別するＡＦ識別子（ＡＦ－ＩＤ）と、特定のアプリケーション、この例ではソーシャルメディアアプリケーションを識別する外部のＡｐｐ－ＩＤと、デフォルトのＱｏＳよりも優れていることを示すＱｏＳ基準と、スポンサデータなどの課金プロファイルとを含むものとし、これにより、アプリケーショントラフィックは、エンドユーザではなく、コンテンツプロバイダに課金される。当業者には、前述のサービスが単なる例示であり、消費者のニーズに合うように適切に変更され得ることが理解されよう。

ステップ６２においてメッセージを受信した後、ＮＥＦ３は、要求を承認し、外部のＡｐｐ－ＩＤを（内部の）Ａｐｐ－ＩＤにマッピングし、この事例では、ＡＦ５にＮｎｅｆ ２００ ＯＫ成功応答で応答するものとする６３。ＮＥＦ３は、上記のパラメータ、すなわちＡＦ－ＩＤ、Ａｐｐ－ＩＤ、ＱｏＳ基準、課金プロファイルを送ることによって、Ｎｐｃｆを介してＰＣＦと対話するものとする６４。図２では、簡潔にするために、単一のＰＣＦ６インスタンスが示されているが、ＮＥＦ３は、オペレータのネットワーク内の任意のＰＣＦ６インスタンスに対してプロシージャをトリガする必要がある。

ステップ６４においてメッセージを受信した後、ＰＣＦ６は、ＮＥＦ３にＮｐｃｆ ２００ ＯＫ成功応答で応答するものとし６５、アプリケーションルールを「アプリケーションデータ」として、すなわち上述のパラメータＡＦ－ＩＤ、Ａｐｐ－ＩＤ、ＱｏＳ基準、および課金プロファイルとしてＵＤＲ２に記憶するために６７、アプリケーションルールのパラメータをＵＤＲ２に送信する６６。第５世代（５Ｇ）データストレージアーキテクチャの一部として、ＵＤＲ２は、パケットフローの説明（ＰＦＤ）を「アプリケーションデータ」として記憶する。本開示では、「アプリケーションデータ」を拡張して、アプリケーションごとのＱｏＳおよび課金情報などのサービス要件を含むようにすることが提案されている。「アプリケーションデータ」を記憶した後６７、ＵＤＲ２は、ＰＣＦ６にＮｕｄｒ ２００ ＯＫ成功応答で応答するものとする６８。

ＰＣＦ６は、この例ではＡＦ－ＩＤ、Ａｐｐ－ＩＤ、ＱｏＳ基準、および課金プロファイルを含む、ＳＭＦ９へのＮｓｍｆ ＨＴＴＰ ＰＯＳＴメッセージをトリガすることによって６９、アプリケーションルールをインストールするものとする。これらのアプリケーションルールは、特定のユーザセッションに適用されるのではなく、任意の既存（および将来の）ユーザセッションに適用されるので、既存のポリシ課金および制御（ＰＣＣ）ルールとは異なることに留意されたい。さらに、優先順位パラメータは、アプリケーションルールにおいて伝達され得るが、本開示では、簡潔にするために、アプリケーションルールが既存のユーザセッションごとのＰＣＣルールよりも優先順位が高いと仮定する。

代替として、ＰＣＦ６は、ＱｏＳの変更および／または異なる課金ハンドリングを必要とする既存のすべてのユーザセッションを識別し、ユーザセッションごとにＰＣＣルールの変更をトリガできるが、その結果、通信システムで交換されるメッセージが多くなり、シグナリングが増加することになる。図２では、簡潔にするために、単一のＳＭＦインスタンス９が示されているが、ＰＣＦ６は、オペレータのネットワーク内の任意のＳＭＦインスタンス９に対してプロシージャをトリガする必要がある。

さらなるステップにおいて、ＳＭＦ９は、ＱｏＳの変更および／または新しい課金ハンドリングを必要とするアクティブなユーザセッションを識別し７０、そのセッションごとに新しいＱｏＳおよび／または課金ハンドリングを適用する。制御プレーンとユーザプレーンの分離（ＣＵＰＳ）機能により、ポリシおよび課金施行機能（ＰＣＥＦ）のＱｏＳおよび課金機能は、制御プレーンとユーザプレーンに分離される。これは、このステップ７０において、ＳＭＦ９がＱｏＳおよび／または課金の制御プレーン部分を適用するだけでよいことを意味する。以下は２つの例である。
－ 「アプリケーションルール」が、Ａｐｐ－ＩＤ＝ソーシャルメディアアプリケーション、およびＱｏＳ基準＝ｘ ｋｂｐｓまでの帯域幅制限で構成される場合、このアプリケーションルールは、ＳＭＦ９に影響を与えずに、ＵＰＦ１０によって施行される。
－ 「アプリケーションルール」が、Ａｐｐ－ＩＤ＝ソーシャルメディアアプリケーション、および課金プロファイル＝スポンサデータで構成される場合、このアプリケーションルールは、ＳＭＦ９とＵＰＦ１０の両方によって、次のように施行される。
－ ＳＭＦ９は、課金対象のエンティティがエンドユーザではなくコンテンツプロバイダ自体であることを示すソーシャルメディアアプリケーションのオフライン課金を想定して、呼詳細レコード（ＣＤＲ）をトリガする必要がある。
－ ＵＰＦ１０は、ソーシャルメディアアプリケーションのボリュームを報告するように命令される必要がある。

ステップ７１において、ＳＭＦ９は、ＰＣＦ６にＮｓｍｆ ２００ ＯＫ成功応答で応答するものとする。ＳＭＦ９は、ノードごとの（新しい）パケット転送制御プロトコル（ＰＦＣＰ）プロシージャ、例えば、アプリケーションについて要求されたＱｏＳおよび／または課金ハンドリングをＵＰＦ１０に示すためのＰＦＣＰアプリケーションルール要求をトリガするものとする７２。これらのアプリケーションルールは、特定のユーザセッションに適用されるのではなく、任意の既存（および将来）のユーザセッションに適用されるので、パケット検出ルール（ＰＤＲ）（ＰＤＩ＝Ａｐｐ－ＩＤ）、ＱｏＳ施行ルール（ＱＥＲ）、および使用レポートルール（ＵＲＲ）に基づく既存のＰＦＣＰルールとは異なる。さらに、優先順位パラメータは伝達され得るが、本開示では、簡潔にするために、アプリケーションルールは、既存のユーザセッションごとのＰＦＣＰルールよりも優先順位が高いと仮定している。

図２では、簡潔にするために、単一のＵＰＦ１０が示されているが、ＳＭＦ９は、ＳＭＦ９によってハンドリングされる任意のＵＰＦ１０に対してプロシージャをトリガする必要がある。ＵＰＦ１０は、ＱｏＳの変更および／または新しい課金ハンドリングを必要とするアクティブなユーザセッションを識別し７３、そのセッションごとに新しいＱｏＳおよび／または課金ハンドリングを適用する。ステップ７０で上述したように、ＣＵＰＳ機能により、ＰＣＥＦのＱｏＳおよび課金機能は、制御プレーンとユーザプレーンに分離される。これは、このステップ７３において、ＵＰＦ１０がＱｏＳおよび／または課金のユーザプレーン部分を適用するだけでよいことを意味する。ＵＰＦ１０は、ＳＭＦ９にＰＦＣＰアプリケーションルール応答で応答するものとする７４。

ステップ６１～７４では、任意の既存のユーザＰＤＵセッションに適用されるメカニズムについて説明する。ステップ７５～８４では、本開示に従って特定のアプリケーションルールを実行するために新しいまたは将来のユーザＰＤＵセッションに適用されるメカニズムを規定する。

ユーザ機器（ＵＥ）１１は、ＰＤＵセッション確立要求をＡＭＦ８に送ることによって、ＰＤＵセッション確立をトリガするものとする７５。ＡＭＦ８は、ＳＭＦ９を選択し、Ｎｓｍｆ ＰＤＵセッション作成をトリガする７６。図２のシーケンス図には、ＰＤＵセッション確立プロシージャに関わるすべてのシグナリングメッセージが含まれているわけではないことに留意されたい。これらのステップは、当業者には知られている。後続のステップでは、本開示に関連するシグナリングメッセージのみについて説明する。

ステップ７７において、ＳＭＦ９は、Ｎｐｃｆ＿ＳＭＰｏｌｉｃｙＣｏｎｔｒｏｌ＿Ｃｒｅａｔｅ Ｒｅｑｕｅｓｔメッセージをトリガして、ユーザＰＤＵセッションのセッション管理（ＳＭ）ポリシを取得する。ＰＣＦ６は、Ｎｕｄｒ＿ＤＭ＿Ｑｕｅｒｙ Ｒｅｑｕｅｓｔメッセージをトリガして、このユーザＰＤＵセッションのポリシデータを取得する７８。ＵＤＲ２は、サブスクライバポリシデータを含むＮｕｄｒ＿ＤＭ＿Ｑｕｅｒｙ Ｒｅｓｐｏｎｓｅメッセージで返答する７９。本開示の一部として、ＵＤＲ２はまた、ＡＦ－ＩＤ、Ａｐｐ－ＩＤ、例えばデフォルトのＱｏＳよりも優れていることを示すＱｏＳ基準、およびスポンサデータなどの課金プロファイルを含むアプリケーションデータを返す。

ＰＣＦ６は、サブスクライバポリシデータおよびアプリケーションデータの両方に基づいて、対応するＰＣＣルールを生成する８０。前述のように、優先順位パラメータを使用すると、競合が発生した場合にどのルールを適用しなければならないか（すなわち、サブスクライバポリシデータ内のルールか、またはアプリケーションデータ内のルールか）を判断することができるが、図２のシーケンス図の例では、簡潔にするために、アプリケーションデータルールが既存のサブスクライバポリシデータルールよりも優先度が高いと仮定している。

ＰＣＦ６は、ステップ８０において上記で生成されたＰＣＣルールに基づいて、このユーザＰＤＵセッションに適用されるべきＰＣＣルールを含むＮｐｃｆ＿ＳＭＰｏｌｉｃｙＣｏｎｔｒｏｌ＿Ｃｒｅａｔｅ Ｒｅｑｕｅｓｔメッセージをトリガする８１。この事例では、ソーシャルメディアアプリケーションのための、（例えば、デフォルトのＱｏＳよりも優れていることを示す）ＱｏＳ基準、および（例えば、これがスポンサデータであることを示すスポンサ識別情報を含む）課金プロファイルを伴うＰＣＣルールがある。

さらなるステップ８２において、ＳＭＦ９は、ＵＰＦ１０を選択し、対応するＰＤＲ／ＦＡＲ／ＱＥＲ／ＵＲＲを含むＰＦＣＰセッション確立要求メッセージをトリガする。この事例では、Ａｐｐ－ＩＤ＝ソーシャルメディアアプリケーションのタイプアプリケーションのＰＤＩを有するＰＤＲ、ＱｏＳ基準を含むＱＥＲ、および課金プロファイルに従ってレポートするためのＵＲＲがあり、これは、ソーシャルメディアアプリケーションが、デフォルトよりも優れたＱｏＳで実行され、課金プロファイルの条件に従ってレポートすべきであることを示す。

ＵＰＦ１０は、ＰＤＲ／ＦＡＲ／ＱＥＲ／ＵＲＲを記憶し、ＰＦＣＰセッション確立応答メッセージでＳＭＦ９に返答する８３。ユーザがそれぞれのソーシャルメディアアプリケーションを開くと、ＵＰＦ１０は、Ａｐｐ－ＩＤ＝ソーシャルメディアアプリケーションのタイプアプリケーションのＰＤＩを有するＰＤＲと、着信パケットとを照合することによって、ソーシャルメディアアプリケーショントラフィックを検出し、このＰＤＲにマッピングされたＱＥＲ内のＱｏＳを適用し８４、その結果、ソーシャルメディアアプリケーションのトラフィックは、デフォルトのユーザトラフィックよりも優れたＱｏＳを有することになる。また、ＵＰＦ１０は、課金プロファイルに従ってＵＲＲに基づいてレポートする。

最後に、本開示に記載の解決策は、５Ｇネットワークアーキテクチャに適用されるだけでなく、同じメカニズムが、
－ ＮＥＦ３を、サービス能力公開機能（ＳＣＥＦ）に、
－ ＡＦ５を、サービス能力サーバ／アプリケーションサーバ（ＳＣＳ／ＡＳ）に、
－ ＰＣＦ６を、ポリシおよび課金ルール機能（ＰＣＲＦ）に、
－ ＳＭＦ９を、ＰＤＮゲートウェイ制御プレーン機能（ＰＧＷ－Ｃ）またはトラフィック検出機能－制御プレーン機能（ＴＤＦ－Ｃ）に、
－ ＵＰＦ１０を、ＰＤＮゲートウェイユーザプレーン機能（ＰＧＷ－Ｕ）またはトラフィック検出機能－ユーザプレーン機能（ＴＤＦ－Ｕ）に
置き換えるだけで、第４世代（４Ｇ）通信ネットワークにも適用され得ることを理解されたい。

図３は、本開示による、ポリシ制御機能（ＰＣＦ）６ノードの概略図である。受信機器１０１、１０２は、それぞれのアプリケーションルールを識別するＡＦ識別子（ＡＦ－ＩＤ）と、アプリケーションを識別するアプリケーション識別子（Ａｐｐ－ＩＤ）と、ＳＢＡドメイン内のアプリケーションを処理するための少なくとも１つのサービス要件とを含むアプリケーションルールを受信するように設定される。命令機器１０５は、それぞれのアプリケーションに関連する現在および将来のすべてのユーザセッションに対して少なくとも１つのサービス要件を実行するようにＳＭＦ９に命令するように設定される。このような命令は、送信機器１０３、１０４を介してＳＭＦに送信されてもよい。

送信機器１０３、１０４は、受信されたアプリケーションルールを、アプリケーションデータとしてＵＤＲ２に記憶するためにＵＤＲ２に送信するようにさらに設定されてもよい。さらに、受信機器１０１、１０２は、アプリケーションデータの記憶を確認するメッセージをＵＤＲから受信するようにさらに設定される。

受信機器１０１、１０２は、プロトコルデータユニット（ＰＤＵ）セッションのためのアプリケーションルールを取得するための要求をＳＭＦ９から受信するようにさらに設定されてもよく、ＰＣＦ６は、ＰＤＵセッションのための記憶されたアプリケーションルールおよびアプリケーションデータをＵＤＲ２から取得するように設定された取得機器１０６と、取得されたアプリケーションルールをＳＭＦ９に提供するように設定された提供機器１０７とをさらに備える。ＰＣＦ６は、メモリ１０９に記憶されたコンピュータ可読命令を実行するように設定されたプロセッサ１０８をさらに備える。内部モジュールは、通信バス１１０を介して互いに通信する。

図４は、本開示による、セッション管理機能（ＳＭＦ）９ノードの概略図である。ＳＭＦ９は、それぞれのアプリケーションに関連する現在および将来のすべてのユーザセッションに対して所望のアプリケーションルールを実行するように命令する命令をＰＣＦ６から受信するように設定された受信機器１５１、１５２を備える。ＳＭＦ９はまた、所望のアプリケーションルールが適用可能であるユーザセッションを識別するように設定された識別機器１５５も備える。

ＳＭＦ９は、識別されたユーザセッションに対して所望のアプリケーションルールを実装するように設定された実装機器１５６をさらに備える。ＳＭＦノード９はまた、受信機器１５１、１５２および送信機器１５３、１５４を使用して、ＳＢＡドメイン内の他のノードと通信してもよい。ＳＭＦ９は、メモリ１５８に記憶されたコンピュータ可読命令を実行するように設定されたプロセッサ１５７を備える。内部モジュールは、通信バス１５９を介して互いに通信する。

図５は、本開示による、統合データリポジトリ（ＵＤＲ）２の概略図である。ＵＤＲ２は、ＵＥによってアクセスされるべきアプリケーションに適用可能なアプリケーションルールを、ＰＣＦ６から受信するように設定された受信機器２０１、２０２を備える。ＵＤＲ２は、受信されたアプリケーションルールを記憶するように設定された記憶機器２０５をさらに備える。

受信機器２０１、２０２は、ユーザセッションに適用可能なアプリケーションルールを求める要求をＰＣＦ６から受信するようにさらに設定され、要求は、ＵＥによってアクセスされるべきアプリケーションを識別し、送信機器２０３、２０４は、ＵＤＲ２の記憶機器２０５に記憶された要求されたアプリケーションルールを、ＰＣＦに送信するように設定される。ＵＤＲ２は、メモリ２０７に記憶されたコンピュータ可読命令を実行するように設定されたプロセッサ２０６をさらに備える。内部モジュールは、通信バス２０８を介して互いに通信する。

本開示を実施する際、当業者は、図面、開示、および添付の特許請求の範囲の研究から、開示された例の他の変形形態を理解および実現することができる。特許請求の範囲において、「備える」という単語は、他の要素またはステップを除外せず、不定冠詞「ａ」または「ａｎ」は、複数を除外しない。単一のプロセッサまたは他のユニットが、特許請求の範囲に記載されたいくつかの項目の機能を果たしてもよい。ある手段が互いに異なる従属請求項に記載されているという単なる事実は、これらの手段の組合せを有利に使用できないことを示すものではない。コンピュータプログラムは、他のハードウェアと共に、または他のハードウェアの一部として供給される適切な媒体に記憶／配布され得るが、インターネットまたは他の有線もしくは無線通信システムを介するなど、他の形態で配布されてもよい。特許請求の範囲における参照符号は、その範囲を限定するものとして解釈されるべきではない。同様の参照符号は、同様または同等の機能を示す。

本開示は、上記に開示された例に限定されず、任意のデータ通信、データ交換、およびデータ処理環境で使用するため、例えば、ＳＢＡドメインおよび固定ネットワークアクセスと、Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ（ＬＴＥ）ネットワークアクセスとの間の動作メッセージのハンドリングのために、発明の技能を適用する必要なく、当業者によって、添付の特許請求の範囲に開示された本開示の範囲を超えて変更および強化することができる。

Claims (15)

1. 通信システムのコアネットワーク内のサービスベースアーキテクチャ（ＳＢＡ）ドメインにおいてユーザセッション内でユーザ機器（ＵＥ）によってアクセスされるべきアプリケーションのためのアプリケーションルールを実装する方法であって、前記ＳＢＡが少なくとも、ポリシ制御機能（ＰＣＦ）（６）、アプリケーション機能（ＡＦ）（５）、ユーザプレーン機能（ＵＰＦ）（１０）、およびセッション管理機能（ＳＭＦ）（９）を備え、前記方法が、
   － 前記ＰＣＦ（６）によって、前記アプリケーションルールを識別するＡＦ識別子（ＡＦ－ＩＤ）と、前記アプリケーションを識別するアプリケーション識別子（Ａｐｐ－ＩＤ）と、前記ＳＢＡドメイン内の前記アプリケーションをサービスするための少なくとも１つのサービス要件とを含むアプリケーションルールを受信するステップであって、前記アプリケーションルールが、既存のポリシ課金および制御（ＰＣＣ）ルールと異なり、既存のセッションごとのＰＣＣルールよりも優先順位が高い、アプリケーションルールを受信するステップと、
   － 前記ＰＣＦ（６）によって、前記アプリケーションに関連する現在および将来のすべてのユーザセッションに対して前記少なくとも１つのサービス要件を実行するように前記ＳＭＦ（９）に命令するステップと
   を含む、方法。
2. 前記ＳＢＡドメインが、統合データリポジトリ（ＵＤＲ）（２）を備え、前記方法が、
   － 前記ＰＣＦ（６）によって、前記受信されたアプリケーションルールを、前記ＵＤＲ（２）に記憶するために前記ＵＤＲ（２）に送信するステップと、
   － 前記ＰＣＦ（６）によって、前記アプリケーションルールの記憶を確認するメッセージを、前記ＵＤＲ（２）から受信するステップと
   をさらに含む、請求項１に記載の方法。
3. 前記ＵＥによって新しいプロトコルデータユニット（ＰＤＵ）セッションを開始するステップをさらに含み、新しいＰＤＵセッションを開始する前記ステップが、
   － 前記ＰＣＦ（６）によって、前記ＰＤＵセッションのための少なくとも１つのポリシルールを取得することを求める要求を、前記ＳＭＦ（９）から受信するステップと、
   － 前記ＰＣＦ（６）によって、前記ＰＤＵセッションのための前記少なくとも１つのポリシルールおよび少なくとも１つの記憶されたアプリケーションルールを、前記ＵＤＲ（２）から取得するステップと、
   － 前記ＰＣＦ（６）によって、前記取得された少なくとも１つのアプリケーションルールを、前記ＳＭＦ（９）に提供するステップと
   を含む、請求項２に記載の方法。
4. 前記アプリケーションルールが、
   － 前記ＵＥによってアクセスされるべき前記アプリケーションに関連するユーザセッションをハンドリングする特定のサービス品質（ＱｏＳ）、および／または
   － 前記ＵＥによってアクセスされるべき前記アプリケーションに関連するユーザセッションのための特定の課金プロファイル
   のうちの少なくとも１つを含む、請求項１から３のいずれか一項に記載の方法。
5. 前記ＰＣＦ（６）が、前記アプリケーションルールを、前記アプリケーションのアプリケーション機能（ＡＦ）（５）から受信する、請求項１から４のいずれか一項に記載の方法。
6. 前記ＰＣＦ（６）が、前記アプリケーションルールを、前記通信システムのオペレータから受信する、請求項１から４のいずれか一項に記載の方法。
7. 通信システムのコアネットワーク内のサービスベースアーキテクチャ（ＳＢＡ）ドメインにおいてユーザセッション内でユーザ機器（ＵＥ）によってアクセスされるべきアプリケーションのためのアプリケーションルールの実行をサポートする方法であって、前記ＳＢＡが少なくとも、ポリシ制御機能（ＰＣＦ）（６）、アプリケーション機能（ＡＦ）（５）、ユーザプレーン機能（ＵＰＦ）（１０）、およびセッション管理機能（ＳＭＦ）（９）を備え、前記方法が、
   － 前記ＳＭＦ（９）によって、前記アプリケーションに関連する現在および将来のすべてのユーザセッションに対して所望のアプリケーションルールを実行するように前記ＳＭＦに命令する命令を、前記ＰＣＦ（６）から受信するステップであって、前記所望のアプリケーションルールが、既存のポリシ課金および制御（ＰＣＣ）ルールと異なり、既存のセッションごとのＰＣＣルールよりも優先順位が高い、命令を受信するステップと、
   － 前記ＳＭＦ（９）によって、前記所望のアプリケーションルールが適用可能である、前記アプリケーションに関連するユーザセッションを識別するステップと、
   － 前記ＳＭＦ（９）によって、前記アプリケーションに関連する前記識別されたユーザセッションに対して前記所望のアプリケーションルールを実行するステップと
   を含む、方法。
8. 前記命令が、ＡＦ識別子（ＡＦ－ＩＤ）と、アプリケーション識別子（Ａｐｐ－ＩＤ）と、前記ＳＢＡドメイン内の前記アプリケーションを処理するための少なくとも１つのサービス要件とを含み、前記識別されるユーザセッションが、前記ＡＦ－ＩＤおよび前記Ａｐｐ－ＩＤに基づいて識別される、請求項７に記載の方法。
9. 通信システムのコアネットワーク内のサービスベースアーキテクチャ（ＳＢＡ）ドメインにおいてユーザセッション内でユーザ機器（ＵＥ）によってアクセスされるべきアプリケーションのためのアプリケーションルールの実行をサポートする方法であって、前記ＳＢＡが少なくとも、ポリシ制御機能（ＰＣＦ）（６）、アプリケーション機能（ＡＦ）（５）、統合データリポジトリ（ＵＤＲ）（２）、およびセッション管理機能（ＳＭＦ）（９）を備え、前記方法が、
   － 前記ＵＤＲ（２）によって、前記ＵＥによってアクセスされるべきアプリケーションに適用可能なアプリケーションルールを、前記ＰＣＦ（６）から受信するステップであって、前記受信されたアプリケーションルールが、既存のポリシ課金および制御（ＰＣＣ）ルールと異なり、既存のセッションごとのＰＣＣルールよりも優先順位が高い、アプリケーションルールを受信するステップと、
   － 前記ＵＤＲ（２）によって、前記受信されたアプリケーションルールを記憶するステップと、
   － 前記ＵＤＲ（２）によって、前記ユーザセッションに適用可能な前記アプリケーションルールを求める要求を、前記ＰＣＦ（６）から受信するステップであって、前記要求が、前記ＵＥによってアクセスされるべきアプリケーションを識別する、要求を受信するステップと、
   － 前記ＰＣＦ（６）が前記アプリケーションに関連する現在および将来のすべてのユーザセッションに対して少なくとも１つのサービス要件を実行するように前記ＳＭＦ（９）に命令するように、前記ＵＤＲ（２）によって、前記ＵＤＲ（２）に記憶されている前記要求されたアプリケーションルールを、前記ＰＣＦ（６）に送信するステップと
   を含む方法。
10. 通信システムのコアネットワーク内のサービスベースアーキテクチャ（ＳＢＡ）ドメインにおけるポリシ制御機能（ＰＣＦ）（６）であって、前記ＳＢＡが少なくとも、アプリケーション機能（ＡＦ）（５）およびセッション管理機能（ＳＭＦ）（９）を備え、前記ＰＣＦ（６）が、前記ＳＢＡドメインにおいてユーザセッション内でユーザ機器（ＵＥ）によってアクセスされるべきアプリケーションのためのアプリケーションルールを実装するように設定され、前記ＰＣＦ（６）が、
    － 前記アプリケーションルールを識別するＡＦ識別子（ＡＦ－ＩＤ）と、前記アプリケーションを識別するアプリケーション識別子（Ａｐｐ－ＩＤ）と、前記ＳＢＡドメイン内の前記アプリケーションを処理するための少なくとも１つのサービス要件とを含む前記アプリケーションルールを受信するように設定された受信機器（１０１、１０２）であって、前記アプリケーションルールが、既存のポリシ課金および制御（ＰＣＣ）ルールと異なり、既存のセッションごとのＰＣＣルールよりも優先順位が高い、受信機器（１０１、１０２）と、
    － 前記アプリケーションに関連する現在および将来のすべてのユーザセッションに対して前記少なくとも１つのサービス要件を実行するように前記ＳＭＦ（９）に命令するように設定された命令機器（１０５）と
    を備える、ポリシ制御機能（ＰＣＦ）（６）。
11. 通信システムのコアネットワーク内のサービスベースアーキテクチャ（ＳＢＡ）ドメインにおけるセッション管理機能（ＳＭＦ）（９）であって、前記ＳＢＡが少なくとも、アプリケーション機能（ＡＦ）（５）、ユーザプレーン機能（ＵＰＦ）（１０）、およびポリシ制御機能（ＰＣＦ）（６）を備え、前記ＳＭＦ（９）が、前記ＳＢＡドメインにおいてユーザセッション内でユーザ機器（ＵＥ）によってアクセスされるべきアプリケーションのためのアプリケーションルールの実装をサポートするように設定され、前記ＳＭＦ（９）が、
    － 前記アプリケーションに関連する現在および将来のすべてのユーザセッションに対して所望のアプリケーションルールを実行するように命令する命令を、前記ＰＣＦ（６）から受信するように設定された受信機器（１５１、１５２）であって、前記所望のアプリケーションルールが、既存のポリシ課金および制御（ＰＣＣ）ルールと異なり、既存のセッションごとのＰＣＣルールよりも優先順位が高い、受信機器（１５１、１５２）と、
    － 前記所望のアプリケーションルールが適用可能である、前記アプリケーションに関連するユーザセッションを識別するように設定された識別機器（１５５）と、
    － 前記アプリケーションに関連する前記識別されたユーザセッションに対して前記所望のアプリケーションルールを実装するように設定された実装機器（１５６）と
    を備える、セッション管理機能（ＳＭＦ）（９）。
12. 通信システムのコアネットワーク内のサービスベースアーキテクチャ（ＳＢＡ）ドメインにおける統合データリポジトリ（ＵＤＲ）（２）であって、前記ＳＢＡが、とりわけ、ポリシ制御機能（ＰＣＦ）（６）、アプリケーション機能（ＡＦ）（５）、およびセッション管理機能（ＳＭＦ）（９）をさらに備え、前記ＵＤＲ（２）が、前記ＳＢＡドメインにおいてユーザセッション内でユーザ機器（ＵＥ）によってアクセスされるべきアプリケーションのためのアプリケーションルールの実装をサポートするように設定され、前記ＵＤＲ（２）が、
    － 前記ＵＥによってアクセスされるべき前記アプリケーションに適用可能な前記アプリケーションルールを前記ＰＣＦ（６）から受信するように設定された受信機器（２０１、２０２）であって、前記アプリケーションルールが、既存のポリシ課金および制御（ＰＣＣ）ルールと異なり、既存のセッションごとのＰＣＣルールよりも優先順位が高い、受信機器（２０１、２０２）と、
    － 前記受信されたアプリケーションルールを記憶するように設定された記憶機器（２０５）と、
    － ユーザセッションに適用可能なアプリケーションルールを求める要求を前記ＰＣＦ（６）から受信するようにさらに設定された前記受信機器（２０１、２０２）であって、前記要求が、前記ＵＥによってアクセスされるべきアプリケーションルールを識別する、前記受信機器（２０１、２０２）と、
    － 前記ＵＤＲ（２）の前記記憶機器に記憶された前記要求されたアプリケーションルールを、前記ＰＣＦ（６）に送信するように設定された送信機器（２０３、２０４）と
    を備える、統合データリポジトリ（ＵＤＲ）（２）。
13. 命令を含むコンピュータプログラムであって、前記命令が、少なくとも１つのプロセッサによって実行されると、前記少なくとも１つのプロセッサに、請求項１から６のいずれか一項に記載の方法を実行させる、コンピュータプログラム。
14. 命令を含むコンピュータプログラムであって、前記命令が、少なくとも１つのプロセッサによって実行されると、前記少なくとも１つのプロセッサに、請求項７または８に記載の方法を実行させる、コンピュータプログラム。
15. 命令を含むコンピュータプログラムであって、前記命令が、少なくとも１つのプロセッサによって実行されると、前記少なくとも１つのプロセッサに、請求項９に記載の方法を実行させる、コンピュータプログラム。

Images