▶ テレフオンアクチーボラゲット エル エム エリクソン（パブル）の特許一覧
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-05-30
(45)【発行日】2024-06-07
(54)【発明の名称】ＰＦＤ管理の最適化手順
(51)【国際特許分類】
H04L 61/2557 20220101AFI20240531BHJP
【ＦＩ】
H04L61/2557
【請求項の数】
17
(21)【出願番号】P 2022576207
(86)(22)【出願日】2021-05-27
(65)【公表番号】
(43)【公表日】2023-07-11
(86)【国際出願番号】 EP2021064150
(87)【国際公開番号】W WO2021249779
(87)【国際公開日】2021-12-16
【審査請求日】2023-01-13
(31)【優先権主張番号】PCT/CN2020/095607
(32)【優先日】2020-06-11
(33)【優先権主張国・地域又は機関】CN
(73)【特許権者】
【識別番号】598036300
【氏名又は名称】テレフオンアクチーボラゲット エルエム エリクソン（パブル）
(74)【代理人】
【識別番号】110003281
【氏名又は名称】弁理士法人大塚国際特許事務所
(72)【発明者】
【氏名】ムニョス デ ラ トレ アロンソ， ミゲル アンヘル
(72)【発明者】
【氏名】カニェテ マルチネス， アントニオ
(72)【発明者】
【氏名】リャン， ティアンメイ
(72)【発明者】
【氏名】シュウ， ウェンリャン
【審査官】和平 悠希
(56)【参考文献】
【文献】欧州特許出願公開第０３６２７８６５（ＥＰ，Ａ１）
【文献】米国特許出願公開第２０２０／０１４５８７６（ＵＳ，Ａ１）
【文献】国際公開第２０１９／２３４４８１（ＷＯ，Ａ１）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｈ０４Ｌ １２／００－１２／６６
Ｈ０４Ｌ ４１／００－１０１／６９５
(57)【特許請求の範囲】
【請求項1】
パケットフロー記述（ＰＦＤ）を管理するためにネットワーク公開ノード（３０１）で実行される方法（８００）であって、コンテンツ提供ノード（３０４）から、前記ネットワーク公開ノードのＰＦＤ管理のためのノースバウンドＡＰＩを介して、アプリケーションの１つ以上のＰＦＤルールを受信することと、
ベースラインを前記アプリケーションの前記１つ以上のＰＦＤルールに関連付けることと、
ネットワークノード（２０１、３０２）から、アプリケーションの少なくとも１つのＰＦＤルールの要求を示し、ベースラインを含む要求メッセージを受信（Ｓ８０１）することと、
前記コンテンツ提供ノード（３０４）から受信した前記１つ以上のＰＦＤルールに関連付けられた前記ベースラインと、前記ネットワークノード（２０１、３０２）からの前記要求メッセージで受信した前記ベースラインとに基づいて、少なくとも１つの更新されたＰＦＤルールを検出（Ｓ８０２）することと、
前記少なくとも１つの更新されたＰＦＤルールを前記ネットワークノード（２０１、３０２）に通知（Ｓ８０３）することと、
を含み、
前記少なくとも１つの更新されたＰＦＤルールを前記ネットワークノード（２０１、３０２）に通知（Ｓ８０３）することは、さらに、
前記１つ以上の更新されたＰＦＤルールと、最新の前記ベースラインとを通知すること、又は、最新の前記ベースラインと共に前記１つ以上の更新されたＰＦＤルールを送信すること、を含み、
前記ベースラインはバージョン参照又はタイムスタンプである、方法。
【請求項2】
請求項１に記載の方法（８００）であって、さらに、ＰＦＤ格納ノード（３０３）に、前記アプリケーションの前記１つ以上のＰＦＤルールと、関連付けられた前記ベースラインと、を格納する様に要求することを含む、方法。
【請求項3】
請求項２に記載の方法（８００）であって、前記少なくとも１つのＰＦＤルールを検出（Ｓ８０２）することは、さらに、
前記ネットワークノード（２０１、３０２）からの前記要求メッセージで受信した前記ベースラインに基づいて、前記少なくとも１つのＰＦＤルールについて前記ＰＦＤ格納ノード（３０３）に問い合わせることと、
前記ＰＦＤ格納ノード（３０３）から変更された前記ＰＦＤルールを受信することと、
を含む方法。
【請求項4】
請求項２又は３に記載の方法（８００）であって、前記方法（８００）は、ネットワーク公開機能（ＮＥＦ）（３０１）又はサービス能力公開機能（ＳＣＥＦ）で実行され、
前記ネットワークノードは、セッション管理機能（ＳＭＦ）（２０１）、ユーザプレーン機能（ＵＰＦ）（３０２）、トラフィック検出機能ユーザプレーン機能（ＴＤＦ－Ｕ）又はＰＤＮゲートウェイユーザプレーン機能（ＰＧＷ－Ｕ）であり、
前記ＰＦＤ格納ノードは、統合データレポジトリ（ＵＤＲ）（３０３）又はパケットフロー記述機能（ＰＦＤＦ）エンティティであり、
前記コンテンツ提供ノードは、アプリケーション機能（ＡＦ）（３０４）又はサービス能力サーバ（ＳＣＳ）／アプリケーションサーバ（ＡＳ）である、方法。
【請求項5】
パケットフロー記述（ＰＦＤ）を管理するためにネットワークノード（２０１、３０２）で実行される方法（１０００）であって、アプリケーションの少なくとも１つのＰＦＤルールの要求を示し、ベースラインを含む要求メッセージをネットワーク公開ノード（３０１）に送信（Ｓ１００１）することと、
前記ベースラインに基づき、少なくとも１つの更新されたＰＦＤルールを前記ネットワーク公開ノード（３０１）から受信（Ｓ１００２）することと、
を含み、
前記少なくとも１つの更新されたＰＦＤルールに関する情報を前記ネットワーク公開ノード（３０１）から受信（Ｓ１００２）することは、さらに、
前記要求メッセージにおける前記ベースラインと前記ＰＦＤルールに関連する最新の前記ベースラインと、１つ以上の更新されたＰＦＤルールと、を受信すること、又は、前記１つ以上の更新されたＰＦＤルールを受信すること、を含み、
前記ベースラインはバージョン参照又はタイムスタンプである、方法。
【請求項6】
請求項５に記載の方法（１０００）であって、前記方法（１０００）は、セッション管理機能（ＳＭＦ）（２０１）、ユーザプレーン機能（ＵＰＦ）（３０２）、トラフィック検出機能ユーザプレーン機能（ＴＤＦ－Ｕ）又はＰＤＮゲートウェイユーザプレーン機能（ＰＧＷ－Ｕ）で実行され、
前記ネットワーク公開ノードは、ネットワーク公開機能（ＮＥＦ）（３０１）又はサービス能力公開機能（ＳＣＥＦ）である、方法。
【請求項7】
パケットフロー記述（ＰＦＤ）を管理するためにＰＦＤ格納ノード（３０３）で実行される方法（９００）であって、アプリケーションの少なくとも１つのＰＦＤルールと、関連づけられたベースラインと、を格納する格納要求を受信（Ｓ９０１）することと、
前記少なくとも１つのＰＦＤルールと、関連付けられた前記ベースラインと、を格納（Ｓ９０２）することと、
問い合わせ要求を、関連付けられたベースラインと共に受信（Ｓ９０３）することと、
前記問い合わせ要求に関連付けられた前記ベースラインと格納された前記ベースラインとを比較（Ｓ９０４）することと、
前記問い合わせ要求に関連付けられた前記ベースライン及び格納された前記ベースラインに基づいて、１つ以上の更新されたＰＦＤルールを提供（Ｓ９０５）することと、
を含み、
前記ベースラインはバージョン参照又はタイムスタンプである、方法。
【請求項8】
請求項７に記載の方法（９００）であって、前記方法（９００）は、統合データリポジトリ（ＵＤＲ）（３０３）又はパケットフロー記述機能（ＰＦＤＦ）エンティティで実行される、方法。
【請求項9】
パケットフロー記述（ＰＦＤ）を管理する装置（１１００）であって、少なくとも１つのプロセッサ（１１０１）と、
前記少なくとも１つのプロセッサ（１１０１）に結合された非一時的なコンピュータ可読媒体（１１０２）と、を備え、前記非一時的なコンピュータ可読媒体（１１０２）は、前記少なくとも１つのプロセッサ（１１０１）によって実行可能な命令を含み、それにより、前記少なくとも１つのプロセッサ（１１０１）は、
コンテンツ提供ノード（３０４）から、ネットワーク公開ノードのＰＦＤ管理のためのノースバウンドＡＰＩを介して、１つ以上のアプリケーションの１つ以上のＰＦＤルールを受信することと、
ベースラインを前記アプリケーションの前記１つ以上のＰＦＤルールに関連付けることと、
ネットワークノード（２０１、３０２）から、アプリケーションの少なくとも１つのＰＦＤルールの要求を示し、ベースラインを含む要求メッセージを受信（Ｓ８０１）することと、
前記コンテンツ提供ノード（３０４）から受信した前記１つ以上のＰＦＤルールに関連付けられた前記ベースラインと、前記ネットワークノード（２０１、３０２）からの前記要求メッセージで受信した前記ベースラインとに基づいて、少なくとも１つの更新されたＰＦＤルールを検出（Ｓ８０２）することと、
前記少なくとも１つの更新されたＰＦＤルールを前記ネットワークノード（２０１、３０２）に通知（Ｓ８０３）することと、
を行う様に構成され、
前記少なくとも１つの更新されたＰＦＤルールを前記ネットワークノード（２０１、３０２）に通知（Ｓ８０３）するとき、前記少なくとも１つのプロセッサ（１１０１）は、さらに、
前記１つ以上の更新されたＰＦＤルールと、最新の前記ベースラインとを通知すること、又は、最新の前記ベースラインと共に前記１つ以上の更新されたＰＦＤルールを送信すること、を行う様に構成され、
前記ベースラインはバージョン参照又はタイムスタンプである、装置。
【請求項10】
請求項９に記載の装置（１１００）であって、前記少なくとも１つのプロセッサ（１１０１）は、さらに、
ＰＦＤ格納ノード（３０３）に、前記アプリケーションの前記１つ以上のＰＦＤルールと、関連付けられた前記ベースラインと、を格納する様に要求することを行う様に構成される、装置。
【請求項11】
請求項１０に記載の装置（１１００）であって、前記少なくとも１つのＰＦＤルールを検出（Ｓ８０２）するとき、前記少なくとも１つのプロセッサ（１１０１）は、さらに、
前記ネットワークノード（２０１、３０２）からの前記要求メッセージで受信した前記ベースラインに基づいて、前記少なくとも１つのＰＦＤルールについて前記ＰＦＤ格納ノードに問い合わせることと、
前記ＰＦＤ格納ノード（３０３）から前記１つ以上の更新された前記ＰＦＤルールを受信することと、
を行う様に構成される、装置。
【請求項12】
請求項１０又は１１に記載の装置（１１００）であって、前記装置（１１００）は、ネットワーク公開機能（ＮＥＦ）（３０１）又はサービス能力公開機能（ＳＣＥＦ）に実装され、
前記ネットワークノードは、セッション管理機能（ＳＭＦ）（２０１）、ユーザプレーン機能（ＵＰＦ）（３０２）、トラフィック検出機能ユーザプレーン機能（ＴＤＦ－Ｕ）又はＰＤＮゲートウェイユーザプレーン機能（ＰＧＷ－Ｕ）であり、
前記ＰＦＤ格納ノードは、統合データレポジトリ（ＵＤＲ）（３０３）又はパケットフロー記述機能（ＰＦＤＦ）エンティティであり、
前記コンテンツ提供ノードは、アプリケーション機能（ＡＦ）（３０４）又はサービス能力サーバ（ＳＣＳ）／アプリケーションサーバ（ＡＳ）である、装置。
【請求項13】
パケットフロー記述（ＰＦＤ）を管理する装置（１３００）であって、少なくとも１つのプロセッサ（１３０１）と、
前記少なくとも１つのプロセッサ（１３０１）に結合された非一時的なコンピュータ可読媒体（１３０２）と、を備え、前記非一時的なコンピュータ可読媒体（１３０２）は、前記少なくとも１つのプロセッサ（１３０１）によって実行可能な命令を含み、それにより、前記少なくとも１つのプロセッサ（１３０１）は、
アプリケーションの少なくとも１つのＰＦＤルールの要求を示し、ベースラインを含む要求メッセージをネットワーク公開ノード（３０１）に送信（Ｓ１００１）することと、
前記ベースラインに基づき、少なくとも１つの更新されたＰＦＤルールを前記ネットワーク公開ノード（３０１）から受信（Ｓ１００２）することと、
を行う様に構成され、
前記少なくとも１つの更新されたＰＦＤルールに関する情報を前記ネットワーク公開ノード（３０１）から受信（Ｓ１００２）するとき、前記少なくとも１つのプロセッサ（１３０１）は、さらに、
前記要求メッセージにおける前記ベースラインと前記ＰＦＤルールに関連する最新の前記ベースラインと、前記１つ以上の更新されたＰＦＤルールと、を受信すること、又は、前記１つ以上の更新されたＰＦＤルールを受信すること、を行う様に構成され、
前記ベースラインはバージョン参照又はタイムスタンプである、装置。
【請求項14】
請求項１３に記載の装置（１３００）であって、前記装置（１３００）は、セッション管理機能（ＳＭＦ）（２０１）、ユーザプレーン機能（ＵＰＦ）（３０２）、トラフィック検出機能ユーザプレーン機能（ＴＤＦ－Ｕ）又はＰＤＮゲートウェイユーザプレーン機能（ＰＧＷ－Ｕ）に実装され、
前記ネットワーク公開ノードは、ネットワーク公開機能（ＮＥＦ）（３０１）又はサービス能力公開機能（ＳＣＥＦ）である、装置。
【請求項15】
パケットフロー記述（ＰＦＤ）を管理する装置（１２００）であって、少なくとも１つのプロセッサ（１２０１）と、
前記少なくとも１つのプロセッサ（１２０１）に結合された非一時的なコンピュータ可読媒体（１２０２）と、を備え、前記非一時的なコンピュータ可読媒体（１２０２）は、前記少なくとも１つのプロセッサ（１２０１）によって実行可能な命令を含み、それにより、前記少なくとも１つのプロセッサ（１２０１）は、
アプリケーションの少なくとも１つのＰＦＤルールと、関連づけられたベースラインと、を格納する格納要求を受信（Ｓ９０１）することと、
前記少なくとも１つのＰＦＤルールと、関連付けられた前記ベースラインと、を格納（Ｓ９０２）することと、
問い合わせ要求を、関連付けられたベースラインと共に受信（Ｓ９０３）することと、
前記問い合わせ要求に関連付けられた前記ベースラインと格納された前記ベースラインとを比較（Ｓ９０４）することと、
前記問い合わせ要求に関連付けられた前記ベースライン及び格納された前記ベースラインに基づいて、１つ以上の更新されたＰＦＤルールを提供（Ｓ９０５）することと、
を行う様に構成され、
前記ベースラインはバージョン参照又はタイムスタンプである、装置。
【請求項16】
請求項１５に記載の装置（１２００）であって、前記装置（１２００）は、統合データリポジトリ（ＵＤＲ）（３０３）又はパケットフロー記述機能（ＰＦＤＦ）エンティティに実装される、装置。
【請求項17】
コンピュータ可読コードを含むコンピュータ可読媒体（１４０２、１４０４）であって、前記コンピュータ可読コードは、装置（１４００）で実行されると、前記装置（１４００）に請求項１から８のいずれか１項に記載の方法（８００、９００、１０００）を実行させる、コンピュータ可読媒体。
【発明の詳細な説明】
【技術分野】
【0001】
本実施形態は、一般に無線通信の分野に関し、より詳細には、本実施形態は、ＰＦＤ管理の最適化手順に関する。
【背景技術】
【0002】
図１は、３ＧＰＰ（登録商標）によって定義された５Ｇ参照アーキテクチャを示す概略ブロック図である。図１に示す様に、５Ｇ参照アーキテクチャは、以下のネットワークノードを含み得る。
●ＡＦ（アプリケーション機能）；
●ＮＥＦ（ネットワーク公開機能）；
●ＳＭＦ：（セッション管理機能）；
●ＵＰＦ：（ユーザプレーン機能）。
●ＡＦ（アプリケーション機能）；
●ＮＥＦ（ネットワーク公開機能）；
●ＳＭＦ：（セッション管理機能）；
●ＵＰＦ：（ユーザプレーン機能）。
【0003】
ＡＦ（アプリケーション機能）
アプリケーション機能（ＡＦ）は、サービスを提供するために、特に、この開示の文脈においては、ネットワークオペレータがアプリケーションのトラフィックを分類することを可能にするＰＦＤルールをプロビジョニングするために、３ＧＰＰ（登録商標）コアネットワークとインタラクトする。
アプリケーション機能（ＡＦ）は、サービスを提供するために、特に、この開示の文脈においては、ネットワークオペレータがアプリケーションのトラフィックを分類することを可能にするＰＦＤルールをプロビジョニングするために、３ＧＰＰ（登録商標）コアネットワークとインタラクトする。
【0004】
ＮＥＦ（ネットワーク公開機能）
ネットワーク公開機能（ＮＥＦ）は、様々な機能をサポートし、具体的には、この開示の文脈において、ＮＥＦは、ＰＦＤ管理サービスをサポートし、これにより、ＮＥＦはＡＦからＰＦＤルールを受信し、それらをＵＤＲに格納し、それらをＳＭＦに提供することが可能になる。
ネットワーク公開機能（ＮＥＦ）は、様々な機能をサポートし、具体的には、この開示の文脈において、ＮＥＦは、ＰＦＤ管理サービスをサポートし、これにより、ＮＥＦはＡＦからＰＦＤルールを受信し、それらをＵＤＲに格納し、それらをＳＭＦに提供することが可能になる。
【0005】
ＳＭＦ（セッション管理機能）
セッション管理機能（ＳＭＦ）は様々な機能をサポートし、具体的には、この開示の文脈において、ＳＭＦは、ＮＥＦ（ＰＦＤ管理サービス）からアプリケーションのＰＦＤルールを取得できる。ＳＭＦは、特定のリスト又は総てのリストで、様々なアプリケーションのＰＦＤデータに関する通知について、ＮＥＦにサブスクライブすることもできる。ＳＭＦは、ＰＦＤルールをＵＰＦにプロビジョニングするために、ＰＦＣＰ ＰＦＤ管理手順もサポートする。
セッション管理機能（ＳＭＦ）は様々な機能をサポートし、具体的には、この開示の文脈において、ＳＭＦは、ＮＥＦ（ＰＦＤ管理サービス）からアプリケーションのＰＦＤルールを取得できる。ＳＭＦは、特定のリスト又は総てのリストで、様々なアプリケーションのＰＦＤデータに関する通知について、ＮＥＦにサブスクライブすることもできる。ＳＭＦは、ＰＦＤルールをＵＰＦにプロビジョニングするために、ＰＦＣＰ ＰＦＤ管理手順もサポートする。
【0006】
ＵＰＦ（ユーザプレーン機能）
ユーザプレーン機能（ＵＰＦ）は、様々な機能をサポートし、具体的には、この開示の文脈において、ＵＰＦは、パケット検査を含むユーザプレーントラフィックの処理をサポートし、アプリケーションのトラフィックを検出するためのルールは、ＵＰＦでローカルにプロビジョニングされる、又は、ＰＦＣＰ ＰＦＤ管理手順を介してＳＭＦから受信される。
ユーザプレーン機能（ＵＰＦ）は、様々な機能をサポートし、具体的には、この開示の文脈において、ＵＰＦは、パケット検査を含むユーザプレーントラフィックの処理をサポートし、アプリケーションのトラフィックを検出するためのルールは、ＵＰＦでローカルにプロビジョニングされる、又は、ＰＦＣＰ ＰＦＤ管理手順を介してＳＭＦから受信される。
【0007】
ＰＦＤ管理
３ＧＰＰ（登録商標）Ｒｅｌ１４の一部として、コンテンツプロバイダとオペレータネットワークとの間で（ＰＦＤの形式で）ユーザトラフィック分類ルールを交換するためのメカニズムが標準化された。３ＧＰＰ（登録商標）ＴＳ２９．１２２は、ＳＣＳ／ＡＳ（コンテンツプロバイダ）と、オペレータネットワークのパケットコアのサービス能力公開機能（ＳＣＥＦ）との間のＴ８インターフェースを定義、具体的には、セクション"４．４．１０ ＰＦＤ管理の手順" でＰＦＤ管理のＴ８ ＡＰＩを定義している。さらに、このためにＰＦＤＦと呼ばれる新しいエンティティが標準化された。
３ＧＰＰ（登録商標）Ｒｅｌ１４の一部として、コンテンツプロバイダとオペレータネットワークとの間で（ＰＦＤの形式で）ユーザトラフィック分類ルールを交換するためのメカニズムが標準化された。３ＧＰＰ（登録商標）ＴＳ２９．１２２は、ＳＣＳ／ＡＳ（コンテンツプロバイダ）と、オペレータネットワークのパケットコアのサービス能力公開機能（ＳＣＥＦ）との間のＴ８インターフェースを定義、具体的には、セクション"４．４．１０ ＰＦＤ管理の手順" でＰＦＤ管理のＴ８ ＡＰＩを定義している。さらに、このためにＰＦＤＦと呼ばれる新しいエンティティが標準化された。
【0008】
ＰＦＤは、ＳＣＥＦを介してコンテンツプロバイダ（ＳＣＳ／ＡＳ）からオペレータネットワークパケットコアにプロビジョニングされ、ＰＦＤＦに格納される。ＰＦＤは、コンテンツプロバイダアプリケーションによって使用される様々なタイプのトラフィックを記述し、例えば、ゼロレーティング又はＱｏＳユースケースを実装するために、ネットワークと交換される（つまり、コンテンツプロバイダのトラフィックを識別し、ユーザのクォータから差し引いたりしない、又は、デフォルトトラフィックよりも優れたＱｏＳを適用する）。
【0009】
ＰＦＤの例は、宛先ＩＰｖ４又はＩＰｖ６アドレス（これらのアドレスへの総てのトラフィックがＰＦＤによって照合される）又はＨＴＴＰ ＵＲＬを含む。
【0010】
３ＧＰＰ（登録商標）Ｒｅｌ１５において、５Ｇネットワークアーキテクチャの一部として、上記のメカニズムは、５Ｇコア（５ＧＣ）ＰＦＤ管理を示す概略ブロック図である図２に示す様に移植され、次の変更が加えられている。
－ＡＦ（ＳＣＳ／ＡＳの代わりに）
－ＮＥＦ（ＳＣＥＦの代わりに）
－ＮＥＦのＰＦＤ管理サービス（ＰＦＤＦエンティティの代わりに）
－ＵＰＦ（ＴＤＦ－Ｕ又はＰＧＷ－Ｕの代わりに）
－ＵＤＲにおけるＰＦＤの格納（ＰＦＤＦエンティティにそれらを格納する代わりに）
－ＡＦ（ＳＣＳ／ＡＳの代わりに）
－ＮＥＦ（ＳＣＥＦの代わりに）
－ＮＥＦのＰＦＤ管理サービス（ＰＦＤＦエンティティの代わりに）
－ＵＰＦ（ＴＤＦ－Ｕ又はＰＧＷ－Ｕの代わりに）
－ＵＤＲにおけるＰＦＤの格納（ＰＦＤＦエンティティにそれらを格納する代わりに）
【0011】
参照
３ＧＰＰ（登録商標）ＴＳ２９．５５１ Ｖ１６．３．０（２０２０年３月）５Ｇシステム；パケットフロー記述管理サービス：ステージ３
３ＧＰＰ（登録商標）ＴＳ２９．５５１ Ｖ１６．３．０（２０２０年３月）５Ｇシステム；パケットフロー記述管理サービス：ステージ３
【発明の概要】
【発明が解決しようとする課題】
【0012】
既存の５ＧＣ ＰＦＤ管理では、以下の課題が特定されている。
●多くのアプリケーション（Ｆａｃｅｂｏｏｋ等）のＰＦＤルールは非常に大きいサイズを有する（例えば、通常、数千のサーバＩＰアドレスを含む）。
●コンテンツプロバイダからネットワークオペレータにＰＦＤルールを伝達する既存のメカニズムは、シグナリングに関しても、プロデューサ（ＡＦ）とコンシューマ（ＵＰＦ）と間のホップ数に関しても効率的ではない。
●多くのアプリケーション（Ｆａｃｅｂｏｏｋ等）のＰＦＤルールは非常に大きいサイズを有する（例えば、通常、数千のサーバＩＰアドレスを含む）。
●コンテンツプロバイダからネットワークオペレータにＰＦＤルールを伝達する既存のメカニズムは、シグナリングに関しても、プロデューサ（ＡＦ）とコンシューマ（ＵＰＦ）と間のホップ数に関しても効率的ではない。
【課題を解決するための手段】
【0013】
既存の５ＧＣＰＦＤ管理における上記課題を考慮して、本実施形態は、上記課題を以下の様に解決するメカニズムを提案する。
●ＮＥＦ ＰＦＤ管理サービスのコンシューマとして（ＰＦＤ管理用のＮｎｅｆサウスバウンドＡＰＩを介して）ＵＰＦのサポートを追加する。現在、ＳＭＦが唯一のコンシューマである。
●以下のものを含むＰＦＤ管理用に最適化されたＮｎｅｆサウスバウンドＡＰＩ。
●最適化されたプッシュ手順：ＵＰＦがａｐｐＩｄｓのリストのＰＦＤ通知についてＮＥＦにサブスクライブする、通知プッシュを提案することにより。そして、ＮＥＦは、それに応じてＵＰＦに通知するが、ＰＦＤを渡さない（したがって、それらを取得するかどうかはＵＰＦに任される）。
●最適化されたプル手順：ａｐｐＩｄｓのリストのＰＦＤルールをＮＥＦに要求するＵＰＦを提案することにより、かつ、部分的な更新（ベースラインによる）又は完全な更新のいずれかの関心を要求で示すことにより。部分的な更新の場合、ＵＰＦは、ベースラインを示し、ＮＥＦは、そのベースラインに関する部分的な更新を返すことができる。
●最適化された結合プッシュプル手順：ＵＰＦがａｐｐＩｄｓのリストのＰＦＤ通知についてＮＥＦにサブスクライブすることを提案することにより、そして、必要に応じて（例えば、Ｏ＆Ｍ保守ウィンドウ中又は特定のａｐｐＩｄのＰＣＣルールのＰＤＵセッション確立時）、ＵＰＦが部分ＰＦＤをプルする。
●ＮＥＦ ＰＦＤ管理サービスのコンシューマとして（ＰＦＤ管理用のＮｎｅｆサウスバウンドＡＰＩを介して）ＵＰＦのサポートを追加する。現在、ＳＭＦが唯一のコンシューマである。
●以下のものを含むＰＦＤ管理用に最適化されたＮｎｅｆサウスバウンドＡＰＩ。
●最適化されたプッシュ手順：ＵＰＦがａｐｐＩｄｓのリストのＰＦＤ通知についてＮＥＦにサブスクライブする、通知プッシュを提案することにより。そして、ＮＥＦは、それに応じてＵＰＦに通知するが、ＰＦＤを渡さない（したがって、それらを取得するかどうかはＵＰＦに任される）。
●最適化されたプル手順：ａｐｐＩｄｓのリストのＰＦＤルールをＮＥＦに要求するＵＰＦを提案することにより、かつ、部分的な更新（ベースラインによる）又は完全な更新のいずれかの関心を要求で示すことにより。部分的な更新の場合、ＵＰＦは、ベースラインを示し、ＮＥＦは、そのベースラインに関する部分的な更新を返すことができる。
●最適化された結合プッシュプル手順：ＵＰＦがａｐｐＩｄｓのリストのＰＦＤ通知についてＮＥＦにサブスクライブすることを提案することにより、そして、必要に応じて（例えば、Ｏ＆Ｍ保守ウィンドウ中又は特定のａｐｐＩｄのＰＣＣルールのＰＤＵセッション確立時）、ＵＰＦが部分ＰＦＤをプルする。
【0014】
一実施形態において、パケットフロー記述（ＰＦＤ）を管理するための方法が提案され、方法は、アプリケーションの少なくとも１つのＰＦＤルールの要求を示す要求メッセージをユーザプレーンノードから受信することと、アプリケーションの少なくとも１つのＰＦＤルールを検出することと、少なくとも１つのＰＦＤルールに関する情報をユーザプレーンノードに通知することと、を含む。
【0015】
一実施形態において、方法は、さらに、コンテンツ提供ノードから１つ又は複数のアプリケーションの１つ又は複数のＰＦＤルールを受信することと、ベースラインをアプリケーションの１つ以上のＰＦＤルールに関連付けることと、を含む。
【0016】
一実施形態において、方法は、さらに、ＰＦＤ格納ノードに、アプリケーションの１つ又は複数のＰＦＤルールと、関連付けられたベースラインと、を格納する様に要求することを含む。
【0017】
一実施形態において、要求メッセージは、ＰＦＤ管理サービスのサブスクリプションを示し、要求メッセージは、ベースラインを含む、又は、ベースラインを含まず、要求メッセージは、さらに、プッシュ通知要求を含む。
【0018】
一実施形態において、少なくとも１つのＰＦＤルールを検出することは、さらに、コンテンツ提供ノードから受信した１つ又は複数のＰＦＤルールに関連付けられたベースラインと、ユーザプレーンノードからの要求メッセージで受信したベースラインとに基づいて、変更されたＰＦＤルールを検出することを含む。
【0019】
一実施形態において、要求メッセージは、ＰＦＤ管理サービスの要求を示し、要求メッセージは、ベースラインを含む、又は、ベースラインを含まない。
【0020】
一実施形態において、少なくとも１つのＰＦＤルールを検出することは、さらに、ユーザプレーンノードからの要求メッセージで受信したベースラインに基づいて、少なくとも１つのＰＦＤルールについてＰＦＤストレージノードに問い合わせることと、変更されたＰＦＤルールをＰＦＤ格納ノードから受信することと、を含む。
【0021】
一実施形態において、少なくとも１つのＰＦＤルールに関する情報をユーザプレーンノードに通知することは、さらに、変更されたＰＦＤルール及び最新のベースラインを通知することを含む。
【0022】
一実施形態において、少なくとも１つのＰＦＤルールに関する情報をユーザプレーンノードに通知することは、さらに、変更されたＰＦＤルールを通知と共に送信する、或いは、変更されたＰＦＤルールの存在を通知することを含む。
【0023】
一実施形態において、上記方法は、ネットワーク公開機能（ＮＥＦ）又はサービス機能公開機能（ＳＣＥＦ）で実行され、ユーザプレーンノードは、ユーザプレーン機能（ＵＰＦ）、トラフィック検出機能ユーザプレーン機能（ＴＤＦ－Ｕ）、又は、ＰＤＮゲートウェイユーザプレーン機能（ＰＧＷ－Ｕ）であり、ＰＦＤ格納ノードは、統合データレポジトリ（ＵＤＲ）又はパケットフロー記述機能（ＰＦＤＦ）エンティティであり、コンテンツ提供ノードは、アプリケーション機能（ＡＦ）又はサービス能力サーバ（ＳＣＳ）／アプリケーションサーバ（ＡＳ）であり、ベースラインはバージョン参照又はタイムスタンプである。
【0024】
別の実施形態において、パケットフロー記述（ＰＦＤ）を管理するための方法が提案され、方法は、アプリケーションの少なくとも１つのＰＦＤルールの要求を示す要求メッセージをネットワーク公開ノードに送信することと、ネットワーク公開ノードから少なくとも１つのＰＦＤルールに関する情報を受信することと、を含む。
【0025】
一実施形態において、要求メッセージは、ＰＦＤ管理サービスのサブスクリプションを示し、要求メッセージは、ベースラインを含む、又は、ベースラインを含まず、要求メッセージは、さらに、プッシュ通知要求を含む。
【0026】
一実施形態において、要求メッセージは、ＰＦＤ管理サービスの要求を示し、要求メッセージは、ベースラインを含む、又は、ベースラインを含まない。
【0027】
一実施形態において、ネットワーク公開ノードから少なくとも１つのＰＦＤルールに関する情報を受信することは、さらに、要求メッセージ内のベースラインに関連付けられたＰＦＤルールに関連する最新のベースライン及び変更されたＰＦＤルールを受信することを含む。
【0028】
一実施形態において、ネットワーク公開ノードから少なくとも１つのＰＦＤルールに関する情報を受信することは、さらに、変更されたＰＦＤルール、又は、変更されたＰＦＤルールの存在に関する通知を受信することを含む。
【0029】
一実施形態において、方法は、さらに、運用及び保守（Ｏ＆Ｍ）保守ウィンドウ中又はパケットデータユニット（ＰＤＵ）セッション確立時に、通知されたＰＦＤルールを取得することを含む。
【0030】
一実施形態において、方法は、ユーザプレーン機能（ＵＰＦ）、トラフィック検出機能ユーザプレーン機能（ＴＤＦ－Ｕ）又はＰＤＮゲートウェイユーザプレーン機能（ＰＧＷ－Ｕ）で実行され、ネットワーク公開ノードは、ネットワーク公開機能（ＮＥＦ）又はサービス能力公開機能（ＳＣＥＦ）であり、ベースラインはバージョン参照又はタイムスタンプである。
【0031】
さらに別の実施形態において、パケットフロー記述（ＰＦＤ）を管理するための方法が提案され、方法は、アプリケーションの少なくとも１つのＰＦＤルール及び関連付けられたベースラインを格納する格納要求を受信することと、少なくとも１つのＰＦＤルール及び関連付けられたベースラインを格納することと、を含む。
【0032】
一実施形態において、方法は、さらに、問い合わせ要求を関連付けられたベースラインと共に受信することと、問い合わせ要求に関連付けられたベースラインと、格納されたベースラインとを比較することと、比較及び格納されたベースラインに基づいて、変更されたＰＦＤルールを提供することと、を含む。
【0033】
一実施形態において、上記方法は、統合データリポジトリ（ＵＤＲ）又はパケットフロー記述機能（ＰＦＤＦ）エンティティで実行され、ベースラインはバージョン参照又はタイムスタンプである。
【0034】
さらに別の実施形態において、パケットフロー記述（ＰＦＤ）を管理するための装置が提案され、装置は、少なくとも１つのプロセッサと、少なくとも１つのプロセッサに結合された非一時的なコンピュータ可読媒体と、を備え、非一時的なコンピュータ可読媒体は、少なくとも１つのプロセッサによって実行可能な命令を含み、それにより、少なくとも１つのプロセッサは、ユーザプレーンノードからアプリケーションの少なくとも１つのＰＦＤルールの要求を示す要求メッセージを受信し、アプリケーションの少なくとも１つのＰＦＤルールを検出し、少なくとも１つのＰＦＤルールに関する情報をユーザプレーンノードに通知する様に構成される。
【0035】
一実施形態において、少なくとも１つのプロセッサは、さらに、コンテンツ提供ノードから１つ又は複数のアプリケーションの１つ又は複数のＰＦＤルールを受信し、ベースラインをアプリケーションの１つ又は複数のＰＦＤルールに関連付ける様に構成される。
【0036】
一実施形態において、少なくとも１つのプロセッサは、さらに、ＰＦＤ格納ノードに、アプリケーションの１つ又は複数のＰＦＤルールと、関連付けられたベースラインと、を格納することを要求する様に構成される。
【0037】
一実施形態において、要求メッセージは、ＰＦＤ管理サービスのサブスクリプションを示し、要求メッセージは、ベースラインを含む、又は、ベースラインを含まず、要求メッセージは、さらに、プッシュ通知要求を含む。
【0038】
一実施形態において、少なくとも１つのＰＦＤルールを検出するとき、少なくとも１つのプロセッサは、さらに、コンテンツ提供ノードから受信した１つ又は複数のＰＦＤルールに関連付けられたベースラインと、ユーザプレーンノードからの要求メッセージで受信したベースラインとに基づいて、変更されたＰＦＤルールを検出する様に構成される。
【0039】
一実施形態において、要求メッセージは、ＰＦＤ管理サービスの要求を示し、要求メッセージは、ベースラインを含む、又は、ベースラインを含まない。
【0040】
一実施形態において、少なくとも１つのＰＦＤルールを検出するとき、少なくとも１つのプロセッサは、さらに、ユーザプレーンノードからの要求メッセージで受信したベースラインに基づいて、少なくとも１つのＰＦＤルールについてＰＦＤ格納ノードに問い合わせを実行し、ＰＦＤ格納ノードから変更されたＰＦＤルールを取得する様に構成される。
【0041】
一実施形態において、少なくとも１つのＰＦＤルールに関する情報をユーザプレーンノードに通知するとき、少なくとも１つのプロセッサは、さらに、変更されたＰＦＤルール及び最新のベースラインを通知する様に構成される。
【0042】
一実施形態において、少なくとも１つのＰＦＤルールに関する情報をユーザプレーンノードに通知すると、少なくとも１つのプロセッサは、さらに、変更されたＰＦＤルールを通知と共に送信する、或いは、変更されたＰＦＤルールの存在を通知する様に構成される。
【0043】
一実施形態において、上記装置は、ネットワーク公開機能（ＮＥＦ）又はサービス機能公開機能（ＳＣＥＦ）に実装され、ユーザプレーンノードは、ユーザプレーン機能（ＵＰＦ）、トラフィック検出機能ユーザプレーン機能（ＴＤＦ－Ｕ）、又は、ＰＤＮゲートウェイユーザプレーン機能（ＰＧＷ－Ｕ）であり、ＰＦＤストレージノードは、統合データレポジトリ（ＵＤＲ）又はパケットフロー記述機能（ＰＦＤＦ）エンティティであり、コンテンツ提供ノードは、アプリケーション機能（ＡＦ）又はサービス能力サーバ（ＳＣＳ）／アプリケーションサーバ（ＡＳ）であり、ベースラインはバージョン参照又はタイムスタンプである。
【0044】
さらに別の実施形態において、パケットフロー記述（ＰＦＤ）を管理するための装置が提案され、装置は、少なくとも１つのプロセッサと、少なくとも１つのプロセッサに結合された非一時的なコンピュータ可読媒体と、を備え、非一時的なコンピュータ可読媒体は、少なくとも１つのプロセッサによって実行可能な命令を含み、それにより、少なくとも１つのプロセッサは、アプリケーションの少なくとも１つのＰＦＤルールの要求を示す要求メッセージをネットワーク公開ノードに送信し、ネットワーク公開ノードから少なくとも１つのＰＦＤルールに関する情報を受信する様に構成される。
【0045】
一実施形態において、要求メッセージは、ＰＦＤ管理サービスのサブスクリプションを示し、要求メッセージは、ベースラインを含む、又は、ベースラインを含まず、要求メッセージは、さらに、プッシュ通知要求を含む。
【0046】
一実施形態において、要求メッセージは、ＰＦＤ管理サービスの要求を示し、要求メッセージは、ベースラインを含む、又は、ベースラインを含まない。
【0047】
一実施形態において、ネットワーク公開ノードから少なくとも１つのＰＦＤルールに関する情報を受信するとき、少なくとも１つのプロセッサは、さらに、最新のベースライン及び要求メッセージ内のベースラインに関連付けられたＰＦＤルールに関連する変更されたＰＦＤルールを受信する様に構成される。
【0048】
一実施形態において、ネットワーク公開ノードから少なくとも１つのＰＦＤルールに関する情報を受信するとき、少なくとも１つのプロセッサは、さらに、変更されたＰＦＤルール、又は、変更されたＰＦＤルールの存在に関する通知を受信する様に構成される。
【0049】
一実施形態において、少なくとも１つのプロセッサは、さらに、運用及び保守（Ｏ＆Ｍ）保守ウィンドウ中又はパケットデータユニット（ＰＤＵ）セッション確立時に、通知されたＰＦＤルールを取得する様に構成される。
【0050】
一実施形態において、上記装置は、ユーザプレーン機能（ＵＰＦ）、トラフィックユーザプレーン機能（ＵＰＦ）又はＰＤＮゲートウェイユーザプレーン機能（ＰＧＷ－Ｕ）に実装され、ネットワーク公開ノードは、ネットワーク公開機能（ＮＥＦ）又はサービス能力公開機能（ＳＣＥＦ）であり、ベースラインはバージョン参照又はタイムスタンプである。
【0051】
さらに別の実施形態において、パケットフロー記述（ＰＦＤ）を管理するための装置が提案され、装置は、少なくとも１つのプロセッサと、少なくとも１つのプロセッサに結合された非一時的なコンピュータ可読媒体と、を備え、非一時的なコンピュータ可読媒体は、少なくとも１つのプロセッサによって実行可能な命令を含み、これにより、少なくとも１つのプロセッサは、アプリケーションの少なくとも１つのＰＦＤルールと、関連付けられたベースラインと、を格納する格納要求を受信し、少なくとも１つのＰＦＤルールと、関連付けられたベースラインと、を格納する様に構成される。
【0052】
一実施形態において、少なくとも１つのプロセッサは、さらに、問い合わせ要求を関連付けられたベースラインと共に受信し、問い合わせ要求に関連付けられたベースラインと、格納されたベースラインとを比較し、比較及び格納されたベースラインに基づいて、変更されたＰＦＤルールを提供する様に構成される。
【0053】
一実施形態において、上記装置は、統合データリポジトリ（ＵＤＲ）又はパケットフロー記述機能（ＰＦＤＦ）エンティティに実装され、ベースラインはバージョン参照又はタイムスタンプである。
【0054】
さらに別の実施形態において、装置で実行されると、装置に上記の方法のいずれかを実行させるコンピュータ可読コードを含むコンピュータ可読媒体が提案される。
【0055】
本明細書の実施形態により、以下の利点が達成され得る。
●本明細書の実施形態は、ＰＦＤルールの配信を最適化し、シグナリングの量を減らし、プロデューサ（ＡＦ）とコンシューマ（ＵＰＦ）との間のホップ数を減少させることにより、ネットワークオペレータが非常に効率的な方法でＰＦＤ管理手順をサポートすることを可能にし得る。
●本明細書の実施形態は、ＳＭＦにおけるＰＦＤ管理に関連するシグナリング、処理、及びメモリへの影響を取り除き、ＰＦＣＰ管理手順を処理するために利用可能な容量を増加させ得る。
●本明細書の実施形態は、オペレータネットワークにおいてＰＦＤ管理に関連するシグナリング要件を半分に減らし得る。
●本明細書の実施形態は、ＰＦＤ管理情報の受信機、及びプロデューサと受信機との間の通信チャネルの過負荷を防ぎ得る。その結果、ＮＥＦへの影響が最小化され得る。
●本明細書の実施形態は、ＰＦＤルールの配信を最適化し、シグナリングの量を減らし、プロデューサ（ＡＦ）とコンシューマ（ＵＰＦ）との間のホップ数を減少させることにより、ネットワークオペレータが非常に効率的な方法でＰＦＤ管理手順をサポートすることを可能にし得る。
●本明細書の実施形態は、ＳＭＦにおけるＰＦＤ管理に関連するシグナリング、処理、及びメモリへの影響を取り除き、ＰＦＣＰ管理手順を処理するために利用可能な容量を増加させ得る。
●本明細書の実施形態は、オペレータネットワークにおいてＰＦＤ管理に関連するシグナリング要件を半分に減らし得る。
●本明細書の実施形態は、ＰＦＤ管理情報の受信機、及びプロデューサと受信機との間の通信チャネルの過負荷を防ぎ得る。その結果、ＮＥＦへの影響が最小化され得る。
【0056】
本明細書に組み込まれ、明細書の一部を形成する添付の図面は、本開示の様々な実施形態を示し、説明とともに、本開示の原理を説明し、当業者が本明細書に開示された実施形態を実現し使用することを可能にする。図面において、同様の参照番号は、同一又は機能的に同様の要素を示す。
【図面の簡単な説明】
【0057】
【図1】３ＧＰＰ（登録商標）によって定義された５Ｇ参照アーキテクチャを示す概略ブロック図。
【図2】５ＧＣ ＰＦＤ管理を示す概略ブロック図。
【図3】本実施形態が実施され得る例示的な通信システムを示すブロック図。
【図4A】本実施形態による、提案プッシュ手順を示すシーケンス図。
【図4B】本実施形態による、提案プッシュ手順を示すシーケンス図。
【図5】本実施形態による、ＵＤＲへの提案ＰＦＤ格納を示すシーケンス図。
【図6A】本実施形態による、提案プル手順を示すシーケンス図。
【図6B】本実施形態による、提案プル手順を示すシーケンス図。
【図7A】本実施形態による、提案結合プッシュ－プル手順を示すシーケンス図。
【図7B】本実施形態による、提案結合プッシュ－プル手順を示すシーケンス図。
【図7C】本実施形態による、提案結合プッシュ－プル手順を示すシーケンス図。
【図8】本実施形態による、ＮＥＦにおける例示的なＰＦＤ管理方法を示すフローチャート。
【図9】本実施形態による、ＵＤＲにおける例示的なＰＦＤ管理方法を示すフローチャート。
【図10】本実施形態による、ＵＰＦにおける例示的なＰＦＤ管理方法を示すフローチャート。
【図11】本実施形態による、ＮＥＦにおける例示的なＰＦＤ管理装置を示すブロック図。
【図12】本実施形態による、ＵＤＲにおける例示的なＰＦＤ管理装置を示すブロック図。
【図13】本実施形態による、ＵＰＦにおける例示的なＰＦＤ管理装置を示すブロック図。
【図14】本実施形態による、例示的なコンピュータ実装装置を示すブロック図。
【発明を実施するための形態】
【0058】
実施形態が示された添付図面を参照して、本実施形態を以下に詳細に説明する。しかしながら、本実施形態は、多くの異なる形態で具現化され、本明細書に記載される実施形態に限定されると解釈するべきではない。図面の要素は、相対的に必ずしも縮尺通りではない。
【0059】
"一実施形態"又は"実施形態"への言及は、実施形態に関連して説明された特定の特徴、構造又は特性が少なくとも１つの実施形態に含まれることを意味する。したがって、明細書全体の様々な場所に現れる"一実施形態において"という語句の出現は、必ずしもすべて同じ実施形態を指しているわけではない。
【0060】
本明細書で使用される"Ａ、Ｂ又はＣ"という用語は、"Ａ"又は"Ｂ"又は"Ｃ"を意味し、本明細書で使用される"Ａ、Ｂ及びＣ"という用語は、"Ａ"及び"Ｂ"及び"Ｃ"を意味し、本明細書で使用される"Ａ、Ｂ及び／又はＣ"という用語は、"Ａ"、"Ｂ"、"Ｃ"、"Ａ及びＢ"、"Ａ及びＣ"、"Ｂ及びＣ"、"Ａ、Ｂ及びＣ"のいずれかを意味する。
【0061】
本実施形態は、シグナリングの量を減らし、プロデューサ（ＡＦ）とコンシューマ（ＵＰＦ）との間のホップ数を減少させることによりＰＦＤルールの配信を最適化する、最適化されたＰＦＤ管理手順を提案する。
【0062】
図３は、本実施形態を実施できる例示的な通信システムを示すブロック図である。
【0063】
一実施形態の例示的な通信システムでは、図３に示す様に、提案ソリューションは、ＰＦＤ管理のためのＮｎｅｆサウスバウンドＡＰＩの様々な拡張に基づき、具体的には：
●ＮＥＦ ＰＦＤ管理サービスのコンシューマとして（ＰＦＤ管理用のＮｎｅｆサウスバウンドＡＰＩを介して）ＵＰＦのサポートを追加する。現在、ＳＭＦ２０１が唯一のコンシューマである。
●ＰＦＤ管理用に最適化されたＮｎｅｆサウスバウンドＡＰＩは、以下を含む。
●最適化されたプッシュ手順：ＵＰＦがａｐｐＩｄｓのリストのＰＦＤ通知についてＮＥＦにサブスクライブする、通知プッシュを提案することにより。そして、ＮＥＦは、それに応じてＵＰＦに通知するが、ＰＦＤを渡さない（したがって、それらを取得するかどうかはＵＰＦに任される）。さらに、ＵＰＦは、ａｐｐＩｄｓのリストについて、ＰＦＤ差分（特定のベースラインに関して）でＮＥＦにサブスクライブできる。
●最適化されたプル手順：ａｐｐＩｄｓのリストのＰＦＤルールをＮＥＦに要求するＵＰＦを提案することにより、かつ、部分的な更新（ベースラインによる）又は完全な更新のいずれかの関心を要求で示すことにより。部分的な更新の場合、ＵＰＦは、ベースラインを示し、ＮＥＦは、そのベースラインに関する部分的な更新を返すことができる。
●最適化された結合プッシュプル手順：ＵＰＦがａｐｐＩｄｓのリストのＰＦＤ通知についてＮＥＦにサブスクライブすることを提案することにより、そして、必要に応じて（例えば、Ｏ＆Ｍ保守ウィンドウ中又は特定のａｐｐＩｄのＰＣＣルールのＰＤＵセッション確立時）、ＵＰＦが部分ＰＦＤをプルする。
●ＮＥＦ ＰＦＤ管理サービスのコンシューマとして（ＰＦＤ管理用のＮｎｅｆサウスバウンドＡＰＩを介して）ＵＰＦのサポートを追加する。現在、ＳＭＦ２０１が唯一のコンシューマである。
●ＰＦＤ管理用に最適化されたＮｎｅｆサウスバウンドＡＰＩは、以下を含む。
●最適化されたプッシュ手順：ＵＰＦがａｐｐＩｄｓのリストのＰＦＤ通知についてＮＥＦにサブスクライブする、通知プッシュを提案することにより。そして、ＮＥＦは、それに応じてＵＰＦに通知するが、ＰＦＤを渡さない（したがって、それらを取得するかどうかはＵＰＦに任される）。さらに、ＵＰＦは、ａｐｐＩｄｓのリストについて、ＰＦＤ差分（特定のベースラインに関して）でＮＥＦにサブスクライブできる。
●最適化されたプル手順：ａｐｐＩｄｓのリストのＰＦＤルールをＮＥＦに要求するＵＰＦを提案することにより、かつ、部分的な更新（ベースラインによる）又は完全な更新のいずれかの関心を要求で示すことにより。部分的な更新の場合、ＵＰＦは、ベースラインを示し、ＮＥＦは、そのベースラインに関する部分的な更新を返すことができる。
●最適化された結合プッシュプル手順：ＵＰＦがａｐｐＩｄｓのリストのＰＦＤ通知についてＮＥＦにサブスクライブすることを提案することにより、そして、必要に応じて（例えば、Ｏ＆Ｍ保守ウィンドウ中又は特定のａｐｐＩｄのＰＣＣルールのＰＤＵセッション確立時）、ＵＰＦが部分ＰＦＤをプルする。
【0064】
【0065】
ステップ１） ＡＦは、ＡｆＩｄ（ａｐｐＩｄ＝ｅｘａｍｐｌｅ１．ｃｏｍ、ＰＦＤ）、（ａｐｐＩｄ＝ｅｘａｍｐｌｅ２．ｃｏｍ、ＰＦＤ）を含むＨＴＴＰ ＰＯＳＴ要求をトリガすることにより、ＰＦＤ管理用のＮｎｅｆノースバウンドＡＰＩを介して、アプリケーションセット（ｅｘａｍｐｌｅ１．ｃｏｍ、ｅｘａｍｐｌｅ２．ｃｏｍ等）のＰＦＤルールをプロビジョニングする。
【0066】
ＡＦにサービス提供するＮＥＦがあることが想定される（つまり、ＡＦは、そのＮＥＦに対する特定のアプリケーションのＰＦＤをプロビジョニングする。）。
【0067】
ステップ２） ＮＥＦ（ＰＦＤ管理サービス）は、Ｎｎｅｆ２００ＯＫメッセージで要求に確認応答する。
【0068】
ステップ３、４、及び５） ＮＥＦ（ＰＦＤ管理サービス）は、上記ステップ１で受信したアプリケーションのＰＦＤを格納することをＵＤＲに要求する。ＮＥＦは、アプリケーション毎にＰＦＤのベースライン（例えば、ＡＦからのＰＦＤの最初のバージョンであるためベースライン１）を設定する。ベースラインは、バージョン参照又はタイムスタンプであり得る。ＵＤＲは、ＰＦＤを格納し、要求に確認応答する（動作成功を示す）。
【0069】
ステップ６及び７） ＵＰＦは、特定のアプリケーションセットのＰＦＤルールを取得するために、ＮＥＦ ＰＦＤ管理サービスにサブスクライブする。２つの異なるａｐｐＩｄｓリストでＵＰＦを構成することが提案される。
●一般的に使用されるアプリケーション（Ｆａｃｅｂｏｏｋ、ＹｏｕＴｕｂｅ（登録商標）、Ｎｅｔｆｌｉｘ等）に対応するａｐｐＩｄｓのリスト。
●一般的に使用されないアプリケーションに対応するａｐｐＩｄｓのリスト。
●一般的に使用されるアプリケーション（Ｆａｃｅｂｏｏｋ、ＹｏｕＴｕｂｅ（登録商標）、Ｎｅｔｆｌｉｘ等）に対応するａｐｐＩｄｓのリスト。
●一般的に使用されないアプリケーションに対応するａｐｐＩｄｓのリスト。
【0070】
上記に基づいて、ＵＰＦが上記の両方のリストを次の様にサブスクライブすることが提案される。
●上記の最初のリストでは、ＵＰＦは、ＰＦＤを取得するためにサブスクライブする（ＵＰＦが、特定のａｐｐＩｄのＰＦＤの以前に格納したバージョンを持っている場合、ＵＰＦは、差分、つまりベースラインに対して更新されたＰＦＤを取得するためにベースラインを示す。）。
●上記の２番目のリストでは、ＵＰＦは、ＰＦＤの存在に関するインジケーションを受信するためだけにサブスクライブする（ＵＰＦが、特定のａｐｐＩｄのＰＦＤの以前に格納したバージョンを持っている場合、ＵＰＦは、そのベースラインに関して更新されたＰＦＤの存在のインジケーションを受信するためにベースラインを示す。）。
●上記の最初のリストでは、ＵＰＦは、ＰＦＤを取得するためにサブスクライブする（ＵＰＦが、特定のａｐｐＩｄのＰＦＤの以前に格納したバージョンを持っている場合、ＵＰＦは、差分、つまりベースラインに対して更新されたＰＦＤを取得するためにベースラインを示す。）。
●上記の２番目のリストでは、ＵＰＦは、ＰＦＤの存在に関するインジケーションを受信するためだけにサブスクライブする（ＵＰＦが、特定のａｐｐＩｄのＰＦＤの以前に格納したバージョンを持っている場合、ＵＰＦは、そのベースラインに関して更新されたＰＦＤの存在のインジケーションを受信するためにベースラインを示す。）。
【0071】
これを行うために、ＰＦＤ管理（プッシュ手順）用にＮｎｅｆサウスバウンドＡＰＩを以下の様に拡張することが提案される。
●ａｐｐＩｄ毎に、ベースラインに従って、ＵＰＦは、ＰＦＤ又は更新されたＰＦＤの存在に関するインジケーションのみを要求する。
●ａｐｐＩｄ毎に、ベースラインに従って、ＵＰＦは、ＰＦＤ又は更新されたＰＦＤの存在に関するインジケーションのみを要求する。
【0072】
この例において、ＵＰＦは、ＰＦＤ管理サービス（Ｎｎｅｆ＿ＰＦＤＭａｎａｇｅｍｅｎｔ＿Ｓｕｂｓｃｒｉｂｅ）へのサブスクライブ動作を示し、以下のパラメータを含むＨＴＴＰ ＰＯＳＴメッセージをトリガする。
●ａｐｐＩｄ＝ｅｘａｍｐｌｅ１．ｃｏｍ、ベースライン＝なし、プッシュ通知
●ａｐｐＩｄ＝ｅｘａｍｐｌｅ２．ｃｏｍ、ベースライン＝なし
●ａｐｐＩｄ＝ｅｘａｍｐｌｅ１．ｃｏｍ、ベースライン＝なし、プッシュ通知
●ａｐｐＩｄ＝ｅｘａｍｐｌｅ２．ｃｏｍ、ベースライン＝なし
【0073】
この例において、ＵＰＦは、ａｐｐＩｄｓの以前に格納したＰＦＤを有していないため、ＵＰＦは、ベースラインなしを示す。
【0074】
ＡＦにサービス提供するＮＥＦが存在し（つまり、ＡＦがそのＮＥＦに対して特定のアプリケーションのＰＦＤをプロビジョニング）、ＵＰＦが、アプリケーション毎にそのＮＥＦを検出することが想定される。
【0075】
ステップ８） 前のステップでメッセージを受信した後、ＮＥＦは、Ｎｎｅｆ２００ＯＫ成功応答でＵＰＦに応答する。
【0076】
ステップ９） ＮＥＦ（ＰＦＤ管理サービス）は、ＵＤＲに対してＮｕｄｒ＿Ｑｕｅｒｙ要求メッセージをトリガし、（ベースラインに従って）ａｐｐＩｄ＝ｅｘａｍｐｌｅ１．ｃｏｍの更新されたＰＦＤがあるかどうかを尋ね、（ベースラインに従って）ａｐｐＩｄ＝ｅｘａｍｐｌｅ２．ｃｏｍの更新されたＰＦＤを直接取得する。
【0077】
ステップ１０及び１１） ＵＤＲは、（ベースラインに従って）ａｐｐＩｄ＝ｅｘａｍｐｌｅ１．ｃｏｍ及びａｐｐＩｄ＝ｅｘａｍｐｌｅ２の更新されたＰＦＤがあるかどうかを検査し、後者については、（ベースラインに従って）更新されたＰＦＤを直接取得し、最新のベースライン（ベースライン１）を示す。（ａｐｐＩｄ＝ｅｘａｍｐｌｅ１．ｃｏｍ、ＰＦＤ存在＝存在）、（ａｐｐＩｄ＝ｅｘａｍｐｌｅ２．ｃｏｍ、ＰＦＤ、ベースライン＝ベースライン１）。
【0078】
ステップ１２及び１３） ＮＥＦは、コンシューマ（ＵＰＦ）に、（ベースラインに従って）ａｐｐＩｄ＝ｅｘａｍｐｌｅ１．ｃｏｍの更新されたＰＦＤルールがあることを示す通知を行い、Ｎｎｅｆ＿ＰＦＤＭａｎａｇｅｍｅｎｔ＿Ｎｏｔｉｆｙメッセージをトリガすることにより、更新されたＰＦＤルール（ベースラインに従って）とａｐｐＩｄ＝ｅｘａｍｐｌｅ２．ｃｏｍの最新のベースラインを伝え、Ｎｎｅｆ＿ＰＦＤＭａｎａｇｅｍｅｎｔ＿Ｎｏｔｉｆｙメッセージは、（ａｐｐＩｄ＝ｅｘａｍｐｌｅ１．ｃｏｍ、ＰＦＤ存在＝存在）、（ａｐｐＩｄ＝ｅｘａｍｐｌｅ２．ｃｏｍ、ＰＦＤ、ベースライン＝ベースライン１）を含む。
【0079】
ステップ１４及び１５） ＵＰＦは、前のステップで受信した情報を格納し（例えば、後でＯ＆Ｍ保守ウィンドウ中に、ａｐｐＩｄ＝ｅｘａｍｐｌｅ１．ｃｏｍの更新されたＰＦＤを取得し得る）、Ｎｎｅｆ２００ＯＫ成功応答でＮＥＦに応答する。
【0080】
ステップ１６） ＡＦは、ＡｆＩｄ、（ａｐｐＩｄ＝ｅｘａｍｐｌｅ１．ｃｏｍ、ＰＦＤ）、（ａｐｐＩｄ＝ｅｘａｍｐｌｅ２．ｃｏｍ、ＰＦＤ）を含むＨＴＴＰ ＰＯＳＴ要求をトリガすることにより、ＰＦＤ管理用のＮｎｅｆノースバウンドＡＰＩを介して、アプリケーションセット（ｅｘａｍｐｌｅ１．ｃｏｍ、ｅｘａｍｐｌｅ２．ｃｏｍ等）の更新されたＰＦＤルールをプロビジョニングする。
【0081】
ステップ１７） ＮＥＦ（ＰＦＤ管理サービス）は、Ｎｎｅｆ２００ＯＫメッセージで要求に確認応答する。
【0082】
ステップ１８、１９及び２０） ＮＥＦ（ＰＦＤ管理サービス）は、上記のステップ１４で受信したアプリケーションのＰＦＤを格納することをＵＤＲに要求する。ＮＥＦは、アプリケーション毎にＰＦＤの新しいベースライン（例えば、ＡＦからのＰＦＤの２番目のバージョンであるため、ベースライン２）を設定する。ベースラインは、バージョン参照又はタイムスタンプであり得る。ＵＤＲは、ＰＦＤを格納し、要求に確認応答する（動作成功を示す）。
【0083】
ステップ２１及び２２） ＮＥＦは、消費者（ＵＰＦ）に次の様に通知する。ａｐｐＩｄ＝ｅｘａｍｐｌｅ１．ｃｏｍのプッシュ通知（以前のベースライン＝ベースライン１に関する差分ＰＦＤルールがあることを示す）と、差分ＰＦＤ（ベースライン１とベースライン２との間）を含むプッシュと、ａｐｐＩｄ＝ｅｘａｍｐｌｅ２．ｃｏｍの最新のベースライン（ベースライン２）。これを行うために、ＮＥＦは、（ａｐｐＩｄ＝ｅｘａｍｐｌｅ１．ｃｏｍ、ＰＦＤ存在＝存在）、（ａｐｐＩｄ＝ｅｘａｍｐｌｅ２．ｃｏｍ、ベースライン＝ベースライン２、差分ＰＦＤ）を含むＮｎｅｆ＿ＰＦＤＭａｎａｇｅｍｅｎｔ＿ＮｏｔｉｆｙメッセージをＵＰＦに対してトリガする。
【0084】
【0085】
最適化されたプル手順
提案される実施形態は、対応するベースラインを含むＵＤＲにおけるＰＦＤ格納に基づく。図５は、本実施形態による、ＵＤＲにおける提案ＰＦＤ格納を示すシーケンス図である。ステップの詳細は、以下の通りである。
提案される実施形態は、対応するベースラインを含むＵＤＲにおけるＰＦＤ格納に基づく。図５は、本実施形態による、ＵＤＲにおける提案ＰＦＤ格納を示すシーケンス図である。ステップの詳細は、以下の通りである。
【0086】
ステップ１） ＡＦは、ＡｆＩｄ（ａｐｐＩｄ＝ｅｘａｍｐｌｅ１．ｃｏｍ，ＰＦＤ）を含むＨＴＴＰ ＰＯＳＴ要求をトリガすることにより、ＰＦＤ管理用のＮｎｅｆノースバウンドＡＰＩを介して、特定のアプリケーション（ｅｘａｍｐｌｅ１．ｃｏｍ等）のＰＦＤルールをプロビジョニングする。
【0087】
ＡＦにサービス提供するＮＥＦがあることが想定される（つまり、ＡＦは、そのＮＥＦに対する特定のアプリケーションのＰＦＤをプロビジョニングする。）。
【0088】
ステップ２） ＮＥＦ（ＰＦＤ管理サービス）は、Ｎｎｅｆ２００ＯＫメッセージで要求に確認応答する。
【0089】
ステップ３及び４） ＮＥＦは、上記のステップ１で受信したＰＦＤのベースライン（ベースライン１）を設定し、ベースライン（ベースライン１）を含むアプリケーション（ｅｘａｍｐｌｅ．ｃｏｍ）のＰＦＤを格納することをＵＤＲに要求する。ベースラインは、バージョン参照又はタイムスタンプであり得る。
【0090】
ステップ５及び６） ＵＤＲは、対応するベースライン（ベースライン１）と共にＰＦＤをアプリケーションデータ（ａｐｐＩｄ＝ｅｘａｍｐｌｅ．ｃｏｍ）として格納し、要求に確認応答する（動作成功を示す）。
【0091】
ステップ７） ある時間後（例：１週間）、ＡＦは、ＡｆＩｄ（ａｐｐＩｄ＝ｅｘａｍｐｌｅ１．ｃｏｍ，ＰＦＤ）を含むＨＴＴＰ ＰＵＴ要求をトリガすることにより、ＰＦＤ管理用のＮｎｅｆノースバウンドＡＰＩを介して、アプリケーション（例：ｅｘａｍｐｌｅ１．ｃｏｍ）の更新されたＰＦＤルールをプロビジョニングする。
【0092】
ステップ８） ＮＥＦ（ＰＦＤ管理サービス）は、Ｎｎｅｆ２００ＯＫメッセージで要求に確認応答する。
【0093】
ステップ９及び１０） ＮＥＦは、上記のステップ７で受信したＰＦＤの新しいベースライン（ベースライン２）を設定し、ベースライン（ベースライン２）を含むアプリケーション（ｅｘａｍｐｌｅ．ｃｏｍ）のＰＦＤを格納することをＵＤＲに要求する。
【0094】
ステップ１１及び１２） ＵＤＲは、対応するベースライン（ベースライン２）と共にＰＦＤをアプリケーションデータ（ａｐｐＩｄ＝ｅｘａｍｐｌｅ．ｃｏｍ）として格納し、要求に確認応答する（動作成功を示す）。
【0095】
【0096】
【0097】
事前条件：ＵＰＦは、ベースライン１に従って、ａｐｐＩｄ＝ｅｘａｍｐｌｅ．ｃｏｍのＰＦＤを格納している（上記の図５を参照）。
【0098】
ステップ１及び２） ＵＥは、ＰＤＵセッション確立要求をＡＭＦに送信することによって、ＰＤＵセッション確立をトリガする。ＡＭＦは、ＰＤＵセッションを管理するＳＭＦを選択し（ＡＭＦのＳＭＦ選択機能は、ＮＲＦから取得した使用可能なＳＭＦインスタンス又はＡＭＦにおける構成されたＳＭＦ情報に基づいてＳＭＦインスタンスを選択）、ＮｓｍｆＰＤＵセッション作成をトリガする。図５のシーケンス図は、ＰＤＵセッション確立手順に含まれる総てのシグナリングメッセージを含んでいるわけではないことに留意されたい。この開示に関連するシグナリングメッセージが、後続のステップで説明される。
【0099】
ステップ３） ＳＭＦは、ユーザＰＤＵセッションのＳＭポリシを取得するために、Ｎｐｃｆ＿ＳＭＰｏｌｉｃｙＣｏｎｔｒｏｌ＿Ｃｒｅａｔｅ要求メッセージをトリガする。
【0100】
ステップ４） ＰＣＦは、この使用ＰＤＵセッションのポリシデータを取得するために、Ｎｕｄｒ＿Ｑｕｅｒｙ要求メッセージをトリガする。
【0101】
ステップ５） ＵＤＲは、加入者ポリシデータを含むＮｕｄｒ＿Ｑｕｅｒｙ応答メッセージで応答する。
【0102】
ステップ６） ＰＣＦは、加入者ポリシデータに基づいて、対応するＰＣＣルールを生成する。
【0103】
ステップ７） 上記に基づいて、ＰＣＦは、このユーザＰＤＵセッションに適用されるＰＣＣルールを含むＮｐｃｆ＿ＳＭＰｏｌｉｃｙＣｏｎｔｒｏｌ＿Ｃｒｅａｔｅ応答メッセージをトリガする。この場合、幾つかの実施アクション（課金及びＱｏＳ）を含む、ａｐｐＩｄ＝ｅｘａｍｐｌｅ．ｃｏｍのＰＣＣルールがある。
【0104】
ステップ８） ＳＭＦは、ＵＰＦを選択し、対応するＰＤＲ／ＦＡＲ／ＱＥＲ／ＵＲＲを含むＰＦＣＰセッション確立要求メッセージをトリガする。この場合、ａｐｐＩｄ＝ｅｘａｍｐｌｅ．ｃｏｍのアプリケーションタイプのＰＤＩを含むＰＤＲと、対応するＦＡＲ、ＱＥＲ及びＵＲＲが存在する。
【0105】
ステップ９） ＵＰＦは、ＰＤＲ／ＦＡＲ／ＱＥＲ／ＵＲＲを格納し、ＰＦＣＰセッション確立応答メッセージでＳＭＦに応答する。
【0106】
ステップ１０及び１１） 上記のステップ８で受信したＰＤＲ（この場合はａｐｐＩｄ＝ｅｘａｍｐｌｅ．ｃｏｍのＰＤＲ）に基づいて、ＵＰＦは、ａｐｐＩｄ＝ｅｘａｍｐｌｅ．ｃｏｍのＰＦＤルールを（以前の要求から）以前に格納したかどうかを検査する。この例では、ＵＰＦは、ベースライン１に従ってＰＦＤルールを格納しており、ＵＰＦが、"部分的ＧＥＴ要求"を示し、ベースライン（ベースライン１）を含む、ａｐｐＩｄ＝ｅｘａｍｐｌｅ．ｃｏｍのＮＥＦ ＰＦＤ管理サービスへの要求をトリガする、つまり、ＵＰＦが、ベースライン１と最新のベースライン（この例ではベースライン２）との間の差分変更（新規、更新、削除されたＰＦＤ）のみを要求することが提案される。
【0107】
ＡＦにサービス提供するＮＥＦが存在し（つまり、ＡＦがそのＮＥＦに対して特定のアプリケーションのＰＦＤをプロビジョニングする。）、ＵＰＦがアプリケーション毎にそのＮＥＦを検出することが想定される。
【0108】
ステップ１２） ＮＥＦ（ＰＦＤ管理サービス）は、ベースライン（ベースライン１）を含めることにより、ａｐｐＩｄ＝ｅｘａｍｐｌｅ．ｃｏｍの差分ＰＦＤを取得するために、ＵＤＲへのＮｕｄｒ＿Ｑｕｅｒｙ要求メッセージをトリガする。
【0109】
ステップ１３及び１４） ＵＤＲは、要求したａｐｐＩｄ（ｅｘａｍｐｌｅ．ｃｏｍ）のＰＦＤを取得するが、ベースライン１による差分のみを取得する（つまり、要求されたベースライン：ベースライン１と最新のベースライン：ベースライン２との間のＰＦＤ）。ＵＤＲは、差分ＰＦＤと最新のベースライン（ベースライン２）とを含むＮｕｄｒ＿Ｑｕｅｒｙ応答メッセージで応答する。
【0110】
ステップ１５） 前のステップでメッセージを受信した後、ＮＥＦは、差分ＰＦＤと最新のベースライン（ベースライン２）とを含むＮｎｅｆ２００ＯＫ成功応答でＵＰＦに応答する。
【0111】
ステップ１６及び１７） ＵＰＦは、差分ＰＦＤを、ターゲットアプリケーション（ｅｘａｍｐｌｅ．ｃｏｍ）及び最新のベースライン（ベースライン２）の格納されたＰＦＤと統合して、将来の要求に備える。ＵＰＦは、Ｎｎｅｆ２００ＯＫ成功応答でＮＥＦに応答する。
【0112】
ステップ１８及び１９） ユーザがｅｘａｍｐｌｅ．ｃｏｍアプリケーションを開く。ＵＰＦは、入力パケットをａｐｐＩｄ＝ｅｘａｍｐｌｅ．ｃｏｍ（最新のＰＦＤを含む）のアプリケーションタイプのＰＤＩのＰＤＲと照合することにより、ｅｘａｍｐｌｅ．ｃｏｍトラフィックを検出し、ＦＡＲ、ＱＥＲ及びＵＲＲ（課金、ＱｏＳ）で示される、対応する実施アクションを適用する。
【0113】
ステップ２０） ＵＰＦは、ＦＡＲに従ってアプリケーションサーバにトラフィックを転送する。
【0114】
【0115】
【0116】
ステップ１） ＡＦは、ＡｆＩｄ（ａｐｐＩｄ＝ｅｘａｍｐｌｅ１．ｃｏｍ、ＰＦＤ）、（ａｐｐＩｄ＝ｅｘａｍｐｌｅ２．ｃｏｍ、ＰＦＤ）含むＨＴＴＰ ＰＯＳＴ要求をトリガすることにより、ＰＦＤ管理用のＮｎｅｆノースバウンドＡＰＩを介して、アプリケーションセット（ｅｘａｍｐｌｅ１．ｃｏｍ、ｅｘａｍｐｌｅ２．ｃｏｍ等）のＰＦＤルールをプロビジョニングする。
【0117】
ＡＦにサービス提供するＮＥＦがあることが想定される（つまり、ＡＦは、そのＮＥＦに対する特定のアプリケーションのＰＦＤをプロビジョニングする。）。
【0118】
ステップ２） ＮＥＦ（ＰＦＤ管理サービス）は、Ｎｎｅｆ２００ＯＫメッセージで要求に確認応答する。
【0119】
ステップ３及び４） ＮＥＦは、上記のステップ１で受信したＰＦＤのベースライン（ベースライン１）を設定し、ベースライン（ベースライン１）を含むアプリケーションのＰＦＤを格納することをＵＤＲに要求する。ベースラインは、バージョン参照又はタイムスタンプであり得る。
【0120】
ステップ５及び６） ＵＤＲは、対応するベースライン（ベースライン１）と共にＰＦＤをアプリケーションデータとして保存し、要求に確認応答する（動作成功を示す）。
【0121】
ステップ７及び８） ＵＰＦは、特定のアプリケーションセットのＰＦＤルールを取得するために、ＮＥＦ ＰＦＤ管理サービスにサブスクライブする。２つの異なるａｐｐＩｄｓリストを使用してＵＰＦを構成することが提案される。
●一般的に使用されるアプリケーション（Ｆａｃｅｂｏｏｋ、ＹｏｕＴｕｂｅ（登録商標）、Ｎｅｔｆｌｉｘ等）に対応するａｐｐＩｄｓのリスト。
●一般的に使用されないアプリケーションに対応するａｐｐＩｄｓのリスト。
●一般的に使用されるアプリケーション（Ｆａｃｅｂｏｏｋ、ＹｏｕＴｕｂｅ（登録商標）、Ｎｅｔｆｌｉｘ等）に対応するａｐｐＩｄｓのリスト。
●一般的に使用されないアプリケーションに対応するａｐｐＩｄｓのリスト。
【0122】
上記に基づいて、ＵＰＦが上記の両方のリストを以下の様にサブスクライブすることが提案される。
●上記の最初のリストについて、ＵＰＦは、ＰＦＤを取得するためにサブスクライブする（ＵＰＦが特定のａｐｐＩｄのＰＦＤの以前に格納されたバージョンを有する場合、ＵＰＦは差分、つまりベースラインに対して更新されたＰＦＤを取得するためにベースラインを示す。）。
●上記の２番目のリストについて、ＵＰＦは、ＰＦＤの存在に関するインジケーションを受信するためだけにサブスクライブする（ＵＰＦが特定のａｐｐＩｄのＰＦＤの以前に格納されたバージョンを有する場合、ＵＰＦは、そのベースラインに関して更新されたＰＦＤの存在のインジケーションを受信するためにベースラインを示す。）。
●上記の最初のリストについて、ＵＰＦは、ＰＦＤを取得するためにサブスクライブする（ＵＰＦが特定のａｐｐＩｄのＰＦＤの以前に格納されたバージョンを有する場合、ＵＰＦは差分、つまりベースラインに対して更新されたＰＦＤを取得するためにベースラインを示す。）。
●上記の２番目のリストについて、ＵＰＦは、ＰＦＤの存在に関するインジケーションを受信するためだけにサブスクライブする（ＵＰＦが特定のａｐｐＩｄのＰＦＤの以前に格納されたバージョンを有する場合、ＵＰＦは、そのベースラインに関して更新されたＰＦＤの存在のインジケーションを受信するためにベースラインを示す。）。
【0123】
これを行うために、以下の様にＰＦＤ管理（プッシュ手順）のＮｎｅｆサウスバウンドＡＰＩを拡張することが提案される。
●ａｐｐＩｄ毎に、ベースラインに従って、ＵＰＦは、ＰＦＤ又は更新されたＰＦＤの存在に関するインジケーションのみを要求する。
●ａｐｐＩｄ毎に、ベースラインに従って、ＵＰＦは、ＰＦＤ又は更新されたＰＦＤの存在に関するインジケーションのみを要求する。
【0124】
この例において、ＵＰＦは、ＰＦＤ管理サービス（Ｎｎｅｆ＿ＰＦＤＭａｎａｇｅｍｅｎｔ＿Ｓｕｂｓｃｒｉｂｅ）へのサブスクライブ動作を示し、パラメータとして、
●ａｐｐＩｄ＝ｅｘａｍｐｌｅ１．ｃｏｍ、ベースライン＝なし、プッシュ通知
●ａｐｐＩｄ＝ｅｘａｍｐｌｅ２．ｃｏｍ、ベースライン＝なし
を含むＨＴＴＰＰＯＳＴメッセージをトリガする。
●ａｐｐＩｄ＝ｅｘａｍｐｌｅ１．ｃｏｍ、ベースライン＝なし、プッシュ通知
●ａｐｐＩｄ＝ｅｘａｍｐｌｅ２．ｃｏｍ、ベースライン＝なし
を含むＨＴＴＰＰＯＳＴメッセージをトリガする。
【0125】
この例において、ＵＰＦはａｐｐＩｄｓの以前に格納されたＰＦＤを有していないため、ＵＰＦはベースラインがないことを示す。
【0126】
ＡＦにサービス提供するＮＥＦが存在し（つまり、ＡＦがそのＮＥＦに対して特定のアプリケーションのＰＦＤをプロビジョニングする）、ＵＰＦがアプリケーション毎にそのＮＥＦを検出することが想定される。
【0127】
ステップ９） 前のステップでメッセージを受信した後、ＮＥＦは、Ｎｎｅｆ２００ＯＫ成功応答でＵＰＦに応答する。
【0128】
ステップ１０） ＮＥＦ（ＰＦＤ管理サービス）は、ＵＤＲに対してＮｕｄｒ＿Ｑｕｅｒｙ要求メッセージをトリガして、（ベースラインに従って）ａｐｐＩｄ＝ｅｘａｍｐｌｅ１．ｃｏｍの更新されたＰＦＤがあるかどうかを尋ね、（ベースラインに従って）ａｐｐＩｄ＝ｅｘａｍｐｌｅ２．ｃｏｍの更新されたＰＦＤを直接取得する。
【0129】
ステップ１１及び１２） ＵＤＲは、（ベースラインに従って）ａｐｐＩｄ＝ｅｘａｍｐｌｅ１．ｃｏｍ及びａｐｐＩｄ＝ｅｘａｍｐｌｅ２の更新されたＰＦＤがあるかどうかを検査し、後者については、（ベースラインに従って）更新されたＰＦＤを直接取得して最新のベースライン（ベースライン１）を示す。（ａｐｐＩｄ＝ｅｘａｍｐｌｅ１．ｃｏｍ、ＰＦＤ存在＝存在）、（ａｐｐＩｄ＝ｅｘａｍｐｌｅ２．ｃｏｍ、ＰＦＤ、ベースライン＝ベースライン１）。
【0130】
ステップ１３及び１４） ＮＥＦは、コンシューマ（ＵＰＦ）に通知して、（ベースラインに従って）ａｐｐＩｄ＝ｅｘａｍｐｌｅ１．ｃｏｍの更新されたＰＦＤルールがあることを示し、（ａｐｐＩｄ＝ｅｘａｍｐｌｅ１．ｃｏｍ、ＰＦＤ存在＝存在）、（ａｐｐＩｄ＝ｅｘａｍｐｌｅ２．ｃｏｍ、ＰＦＤ、ベースライン＝ベースライン１）を含むＮｎｅｆ＿ＰＦＤＭａｎａｇｅｍｅｎｔ＿Ｎｏｔｉｆｙメッセージをとりがすることにより、（ベースラインに従って）更新されたＰＦＤルールと、ａｐｐＩｄ＝ｅｘａｍｐｌｅ２．ｃｏｍの最新のベースラインを伝える。
【0131】
ステップ１５及び１６） ＵＰＦは、前のステップで受信した情報を格納し（例えば、後のＯ＆Ｍ保守ウィンドウ中にａｐｐＩｄ＝ｅｘａｍｐｌｅ１．ｃｏｍの更新されたＰＦＤを取得し得る）、Ｎｎｅｆ２００ＯＫ成功応答でＮＥＦに応答する。
【0132】
ステップ１７及び１８） ＵＥは、ＰＤＵセッション確立要求をＡＭＦに送信することによって、ＰＤＵセッション確立をトリガする。ＡＭＦは、ＰＤＵセッションを管理するＳＭＦを選択し（ＡＭＦのＳＭＦ選択機能は、ＮＲＦから取得した使用可能なＳＭＦインスタンス又はＡＭＦにおける構成されたＳＭＦ情報に基づいてＳＭＦインスタンスを選択）、ＮｓｍｆＰＤＵセッションの作成をトリガする。図７Ａ～図７Ｃのシーケンス図は、ＰＤＵセッション確立手順に含まれる総てのシグナリングメッセージを含んでいるわけではないことに留意されたい。この開示に関連するシグナリングメッセージが、後続のステップで説明される。
【0133】
ステップ１９） ＳＭＦは、ユーザＰＤＵセッションのＳＭポリシを取得するために、Ｎｐｃｆ＿ＳＭＰｏｌｉｃｙＣｏｎｔｒｏｌ＿Ｃｒｅａｔｅ要求メッセージをトリガする。
【0134】
ステップ２０） ＰＣＦは、この使用ＰＤＵセッションのポリシデータを取得するために、Ｎｕｄｒ＿Ｑｕｅｒｙ要求メッセージをトリガする。
【0135】
ステップ２１） ＵＤＲは、加入者ポリシデータを含むＮｕｄｒ＿Ｑｕｅｒｙ応答メッセージで応答する。
【0136】
ステップ２２） ＰＣＦは、加入者ポリシデータに基づいて、対応するＰＣＣルールを生成する。
【0137】
ステップ２３）上記に基づいて、ＰＣＦは、このユーザＰＤＵセッションに適用されるＰＣＣルールを含むＮｐｃｆ＿ＳＭＰｏｌｉｃｙＣｏｎｔｒｏｌ＿Ｃｒｅａｔｅ応答メッセージをトリガする。この場合、幾つかの実施アクション（課金及びＱｏＳ）を含む、ａｐｐＩｄ＝ｅｘａｍｐｌｅ１．ｃｏｍのＰＣＣルールと、があり、幾つかの実施アクション（課金及びＱｏＳ）を含む、ａｐｐＩｄ＝ｅｘａｍｐｌｅ２．ｃｏｍの別のＰＣＣルールがある。
【0138】
ステップ２４） ＳＭＦはＵＰＦを選択し、対応するＰＤＲ／ＦＡＲ／ＱＥＲ／ＵＲＲを含むＰＦＣＰセッション確立要求メッセージをトリガする。この場合、ａｐｐＩｄ＝ｅｘａｍｐｌｅ１．ｃｏｍのタイプアプリケーションのＰＤＩを含むＰＤＲと、ａｐｐＩｄ＝ｅｘａｍｐｌｅ２．ｃｏｍのタイプアプリケーションのＰＤＩを含む別のＰＤＲと、対応するＦＡＲ、ＱＥＲ及びＵＲＲがある。
【0139】
ステップ２５） ＵＰＦは、ＰＤＲ／ＦＡＲ／ＱＥＲ／ＵＲＲを格納し、ＰＦＣＰセッション確立応答メッセージでＳＭＦに応答する。
【0140】
ステップ２６及び２７） 上記のステップ２４で受信したＰＤＲ（この場合はａｐｐＩｄ＝ｅｘａｍｐｌｅ１．ｃｏｍのＰＤＲとａｐｐＩｄ＝ｅｘａｍｐｌｅ２．ｃｏｍの別のＰＤＲ）に基づいて、ＵＰＦは、これらのアプリケーションのＰＦＤルールを以前に格納したかどうかを検査する（以前の要求から）。この例において、ＵＰＦは、ａｐｐＩｄ＝ｅｘａｍｐｌｅ２．ｃｏｍのＰＦＤルールを格納している（ＰＦＤプッシュ通知がないため、更新される）。さらに、ＵＰＦは、ａｐｐＩｄ＝ｅｘａｍｐｌｅ１．ｃｏｍのＰＦＤルールを格納していないため（ただし、取得するＰＦＤルールがあることはわかっている）、ＮＥＦ ＰＦＤ管理サービスへの要求をトリガしてそれらを取得する。あるいは、シグナリングの過負荷を避けるために、ＵＰＦは、後にＰＦＤルールを取得し得る。
【0141】
ステップ２８） ＮＥＦ（ＰＦＤ管理サービス）は、ａｐｐＩｄ＝ｅｘａｍｐｌｅ１．ｃｏｍのＰＦＤを取得するために、ベースライン（ベースラインなし）を含めてＵＤＲへのＮｕｄｒ＿Ｑｕｅｒｙ要求メッセージをトリガする。
【0142】
ステップ２９及び３０） ＵＤＲは、要求されたａｐｐＩｄ（ｅｘａｍｐｌｅ１．ｃｏｍ）のＰＦＤを取得する。ＵＤＲは、ＰＦＤと最新のベースライン（ベースライン１）を含むＮｕｄｒ＿Ｑｕｅｒｙ応答メッセージで応答する。
【0143】
ステップ３１） 前のステップでメッセージを受信した後、ＮＥＦは、ＰＦＤと最新のベースライン（ベースライン１）を含むＮｎｅｆ２００ＯＫ成功応答でＵＰＦに応答する。
【0144】
ステップ３２及び３３） ＵＰＦは、アプリケーション（ｅｘａｍｐｌｅ１．ｃｏｍ）のＰＦＤを格納し、将来の要求のために新しいベースライン（ベースライン１）を格納する。ＵＰＦはＮｎｅｆ２００ＯＫ成功応答でＮＥＦに応答する。
【0145】
ステップ３４及び３５） ユーザはｅｘａｍｐｌｅ１．ｃｏｍアプリケーションを開く。ＵＰＦは、入力パケットをａｐｐＩｄ＝ｅｘａｍｐｌｅ１．ｃｏｍ（最新のＰＦＤを含む）のアプリケーションタイプのＰＤＩのＰＤＲと照合することでｅｘａｍｐｌｅ１．ｃｏｍトラフィックを検出し、ＦＡＲ、ＱＥＲ及びＵＲＲ（課金、ＱｏＳ）で示される、対応する実施アクションを適用する。
【0146】
ステップ３６） ＵＰＦは、ＦＡＲに従ってアプリケーションサーバにトラフィックを転送する。
【0147】
ステップ３７及び３８） ユーザがｅｘａｍｐｌｅ２．ｃｏｍアプリケーションを開く。ＵＰＦは、入力パケットをａｐｐＩｄ＝ｅｘａｍｐｌｅ２．ｃｏｍ（最新のＰＦＤを含む）のアプリケーションタイプのＰＤＩのＰＤＲと照合することでｅｘａｍｐｌｅ２．ｃｏｍトラフィックを検出し、ＦＡＲ、ＱＥＲ及びＵＲＲ（課金、ＱｏＳ）で示される、対応する実施アクションを適用する。
【0148】
ステップ３９） ＵＰＦは、ＦＡＲに従ってアプリケーションサーバにトラフィックを転送する。
【0149】
本実施形態により、以下の技術的効果が達成され得る。
●本実施形態は、ＰＦＤルールの配信を最適化し、シグナリングの量を減らし、プロデューサ（ＡＦ）とコンシューマ（ＵＰＦ）との間のホップ数を減少させることにより、ネットワークオペレータが非常に効率的な方法でＰＦＤ管理手順をサポートすることを可能にし得る。
●本実施形態は、ＳＭＦにおけるＰＦＤ管理に関連するシグナリング、処理及びメモリへの影響を取り除き、ＰＦＣＰ管理手順を処理するために利用可能な容量を増加させ得る。
●本実施形態は、オペレータネットワークにおいてＰＦＤ管理に関連するシグナリング要件を半分に減らし得る。
●本明細書の実施形態は、ＰＦＤ管理情報の受信機と、プロデューサと受信機との間の通信チャネルの過負荷を防ぎ得る。その結果、ＮＥＦへの影響が最小化され得る。
●本実施形態は、ＰＦＤルールの配信を最適化し、シグナリングの量を減らし、プロデューサ（ＡＦ）とコンシューマ（ＵＰＦ）との間のホップ数を減少させることにより、ネットワークオペレータが非常に効率的な方法でＰＦＤ管理手順をサポートすることを可能にし得る。
●本実施形態は、ＳＭＦにおけるＰＦＤ管理に関連するシグナリング、処理及びメモリへの影響を取り除き、ＰＦＣＰ管理手順を処理するために利用可能な容量を増加させ得る。
●本実施形態は、オペレータネットワークにおいてＰＦＤ管理に関連するシグナリング要件を半分に減らし得る。
●本明細書の実施形態は、ＰＦＤ管理情報の受信機と、プロデューサと受信機との間の通信チャネルの過負荷を防ぎ得る。その結果、ＮＥＦへの影響が最小化され得る。
【0150】
【0151】
【0152】
方法８００は、ＮＥＦ３０１がアプリケーションの少なくとも１つのＰＦＤルールの要求を示す要求メッセージをＵＰＦ３０２から受信する、ステップＳ８０１で開始し得る。
【0153】
一実施形態において、要求メッセージは、ＰＦＤ管理サービスへの加入（サブスクリプション）を示し得る。すなわち、図４Ａ～図４Ｂ及び図７Ａ～７Ｃに示す様に、ＵＰＦ３０２は、ＮＥＦ ＰＦＤ管理サービスに加入（サブスクライブ）し、その結果、ＡＦ３０４からＰＦＤの新しいバージョン（新しいベースライン）をＮＥＦ３０１が受信する度に、ＮＥＦ３０１は、新しいバージョンについてＵＰＦ３０２に通知することができる（プッシュ）。
【0154】
一実施形態において、要求メッセージ（この実施形態のサブスクリプション）は、ベースラインを含んでも、ベースラインを含まなくてもよい。すなわち、ＵＰＦ３０２がこのアプリケーションのＰＦＤの古いバージョン（ベースライン）を有する場合、ＵＰＦ３０２はサブスクリプションのベースラインを示し、その結果、ＮＥＦ３０１は、変更された（追加、削除又は更新された）ＰＦＤのみをＵＰＦ３０２に示すことができる。一方、ＵＰＦ３０２がこのアプリケーションのＰＦＤのバージョン（ベースライン）を有していない場合、ＵＰＦ３０２はベースラインがないことを示し得る。
【0155】
一実施形態において、要求メッセージ（この実施形態のサブスクリプション）は、プッシュ通知要求を含み、その結果、ＮＥＦ３０１は、新しいバージョンが受信された場合にのみプッシュ通知をＵＰＦ３０２に送信することができ、ＵＰＦ３０２は可能なときにＰＦＤルールをダウンロードし得る。例えば、ＵＰＦ３０２は、図４Ａ～図４Ｂ及び図７Ａ～図７Ｃに示される様に、運用及び保守（Ｏ＆Ｍ）保守ウィンドウ中又はパケットデータユニット（ＰＤＵ）セッション確立時に、通知されたＰＦＤルールを取得し得る。
【0156】
一実施形態において、プッシュ通知要求は、頻繁に使用されないアプリケーションにのみ適用され得る。頻繁に使用されるアプリケーションの場合、ＮＥＦ３０１は、ＰＦＤルールをプッシュすることができ、その結果、ＵＰＦ３０２は、ＰＦＤルールをすぐに取得し得る。
【0157】
一実施形態において、要求メッセージは、図６Ａ～図６Ｂ及び図７Ａ～図７Ｃに示す様に、ＰＦＤ管理サービスの要求を示し得る。すなわち、ＵＰＦ３０２は、ＮＥＦ３０１に、アプリケーションのＰＦＤを提供する様に求める（要求する）ことができる（プル）。
【0158】
一実施形態において、要求メッセージ（この実施形態のＰＦＤ要求）は、プッシュシナリオと同様に、ベースラインを含んでもベースラインを含まなくてもよい。
【0159】
一実施形態において、ＵＰＦ３０２は、図７Ｃ～図７Ｃに示される様に、要求メッセージを１回以上送信し得る。すなわち、ＵＰＦ３０２は、プッシュサブスクリプションが成功した場合でもプル要求を送信し得る。さらに、ＵＰＦ３０２は、プル要求及び／又はプッシュサブスクリプションを繰り返し送信し得る。
【0160】
一実施形態において、方法８００は、図８には示していないが、ＡＦ３０４からＰＦＤルールを受信し、それらをＵＤＲ３０３に格納するステップも含み得る。これらのステップは、図８に示すステップと同時に実行することも、図８に示すステップの前又は後に実行することもできる。さらに、これらのステップは、繰り返し実行され得る。すなわち、ＮＥＦ３０１がＡＦ３０４からＰＦＤルールを受信する度に、ＮＥＦ３０１は、受信したＰＦＤルールをＵＤＲ３０３に格納する。
【0161】
一実施形態において、ＮＥＦ３０１は、ＡＦ３０４から１つ又は複数のアプリケーションに対する１つ又は複数のＰＦＤルールを受信し得る。次いで、ＮＥＦ３０１は、ベースラインを同じアプリケーションの１つ又は複数のＰＦＤルールに関連付け得る。ベースラインは、バージョン数又はタイムスタンプであり得る。
【0162】
一実施形態において、ＮＥＦ３０１は、ＵＤＲ３０３に、アプリケーションの１つ又は複数のＰＦＤルールと、関連付けられたベースラインと、を格納する様に要求し得る。
【0163】
次いで、方法８００は、ＮＥＦ３０１が、ＵＰＦ３０２から受信した要求メッセージに応答して、アプリケーションの少なくとも１つのＰＦＤルールを検出し得る、ステップＳ８０２に進み得る。
【0164】
一実施形態において、ＵＰＦ３０２から要求メッセージ（サブスクリプション又は要求のいずれか）を受信すると、ＮＥＦ３０１は、ＵＤＲ３０３を検査することによって、アプリケーションの少なくとも１つのＰＦＤルールを検出し得る。一実施形態において、ＮＥＦ３０１は、ＵＰＦからの要求メッセージ（サブスクリプション又は要求のいずれか）で受信したベースラインに基づいて、少なくとも１つのＰＦＤルールについてＵＤＲ３０３に問い合わせることができる。次いで、ＮＥＦ３０１からの問い合わせに応答して、ＵＤＲ３０３は、問い合わせ要求に関連付けられたベースラインと、ＵＤＲ３０３に格納されたこのアプリケーションのベースラインとを比較し、このアプリケーションの新しいベースライン（例えば、新しいバージョン）があるかどうかを判断し得る。特に、要求メッセージ（サブスクリプション又は要求のいずれか）がベースラインを示さず、したがって問い合わせ要求がそれに応じてベースラインを示さない場合、ＵＤＲ３０３は、格納されたＰＦＤルールが新しいバージョンになると判断し得る。新しいベースラインが見つかった場合、ＵＤＲ３０３は変更されたＰＦＤルールを提供し得る。ＵＤＲ３０３は、ベースライン（例えば、バージョン番号又はタイムスタンプ）を提供し得る。
【0165】
一実施形態において、ＵＰＦ３０２のためのＰＦＤ管理サービスのサブスクリプションの成功に応答して、ＮＥＦ３０１は、ＰＦＤルールの新しいバージョンがＡＦ３０４から受信されたかどうかを検出し得る。例えば、ＡＦ３０４からＰＦＤルールを受信する度に、ＮＥＦ３０１は、ＰＦＤルールの新しいベースラインを設定することができ、同時に、ＮＥＦ３０１は、ＡＦから受信した１つ又は複数のＰＦＤルールに関連付けられた新しいベースラインと、ＵＰＦからの要求メッセージで受信したベースラインと、に基づいて、更新されたＰＦＤルールを検出し得る。特に、ＮＥＦ３０１は、ＡＦ３０４から受信した（新しいベースラインに関連付けられた）ＰＦＤルールを、サブスクリプションメッセージで示されたベースラインに関連付けられたＰＦＤルールと比較し得る。ＮＥＦ３０１は、必要に応じて、サブスクリプションメッセージで示されるベースラインに関連付けられたＰＦＤルールについてＵＤＲ３０３に問い合わせることができる。
【0166】
次いで、方法８００は、ＮＥＦ３０１が少なくとも１つのＰＦＤルールに関する情報をＵＰＦ３０２に通知し得る、ステップＳ８０３に進み得る。
【0167】
一実施形態において、ＵＰＦ３０２からの要求メッセージに応じて、ＮＥＦ３０２は、変更されたＰＦＤルール（部分的なＰＦＤルール）及び最新のベースラインの存在をＵＰＦ３０２に通知するか、変更されたＰＦＤルールを通知と共に送信し得る。
【0168】
【0169】
【0170】
方法９００は、ＵＤＲ３０３が、ＮＥＦ３０１から、アプリケーションの少なくとも１つのＰＦＤルールと、関連付けられたベースラインと、を格納する格納要求を受信し得る、ステップＳ９０１から開始し得る。ベースラインは、バージョン参照又はタイムスタンプである。次いで、ステップＳ９０２で、ＵＤＲ３０３は、少なくとも１つのＰＦＤルール及び関連付けられたベースラインを格納し得る。
【0171】
方法９００は、Ｓ９０３をさらに含み、ここで、ＵＤＲ３０３は、ＮＥＦ３０１から関連付けられたベースラインと共に問い合わせ要求を受信し得る。次に、ＮＥＦ３０１からの問い合わせ要求に応答して、ステップＳ９０４で、ＵＤＲ３０３は、問い合わせ要求に関連付けられたベースラインと、このアプリケーションのＵＤＲ３０３に格納されているベースラインとを比較し、このアプリケーションの新しいベースライン（例：新しいバージョン）があるかどうかを判断し得る。特に、問い合わせ要求がベースラインを示さない場合、ＵＤＲ３０３は、格納されたＰＦＤルールが新しいバージョンになると判断し得る。次に、ステップＳ９０５で、ＵＤＲ３０３は、新しいベースラインが見つかった場合、変更されたＰＦＤルールを提供し得る。ＵＤＲ３０３は、ベースライン（例えば、バージョン番号又はタイムスタンプ）も提供し得る。
【0172】
なお、上記ステップＳ９０１～Ｓ９０２及びＳ９０３～Ｓ９０５は、任意順序で行う、同時に行う、或いは、別々に行う等の任意の方法で行われ得る。さらに、これらのステップは、繰り返し実行され得る。上記のステップは単なる例であり、ＵＤＲ３０３は、ＰＦＤルールを管理するために、図３～図７Ｃに関連して説明した任意のアクションを実行し得る。
【0173】
【0174】
方法１０００は、ＵＰＦ３０２がアプリケーションの少なくとも１つのＰＦＤルールの要求を示す要求メッセージをＮＥＦ３０１に送信し得る、ステップＳ１００１で開始し得る。
【0175】
一実施形態において、要求メッセージは、ＰＦＤ管理サービスのサブスクリプションを示し得る。すなわち、図４Ａ～図４Ｂ及び図７Ａ～７Ｃに示す様に、ＵＰＦ３０２は、ＮＥＦＰＦＤ管理サービスにサブスクライブし、その結果、ＮＥＦ３０１は、ＡＦ３０４からＰＦＤの新しいバージョン（新しいベースライン）を受信する度に、ＮＥＦ３０１は、新しいバージョンについてＵＰＦ３０２に通知することができる（プッシュ）。
【0176】
一実施形態において、要求メッセージ（この実施形態のサブスクリプション）は、ベースラインを含んでも、ベースラインを含まなくてもよい。すなわち、ＵＰＦ３０２がこのアプリケーションのＰＦＤの古いバージョン（ベースライン）を有する場合、ＵＰＦ３０２は、サブスクリプションのベースラインを示し、その結果、ＮＥＦ３０１は、変更された（追加、削除又は更新された）ＰＦＤのみをＵＰＦ３０２に示すことができる。一方、ＵＰＦ３０２がこのアプリケーションのＰＦＤのバージョン（ベースライン）を有していない場合、ＵＰＦ３０２は、ベースラインがないことを示し得る。ベースラインは、バージョン番号又はタイムスタンプであり得る。
【0177】
一実施形態において、要求メッセージ（この実施形態のサブスクリプション）は、プッシュ通知要求を含み、その結果、ＮＥＦ３０１は、新しいバージョンが受信された場合にのみプッシュ通知をＵＰＦ３０２に送信することができ、ＵＰＦ３０２は、可能なときにＰＦＤルールをダウンロードし得る。例えば、ＵＰＦ３０２は、図４Ａ～図４Ｂ及び図７Ａ～図７Ｃに示される様に、運用及び保守（Ｏ＆Ｍ）保守ウィンドウ中又はパケットデータユニット（ＰＤＵ）セッション確立時に、通知されたＰＦＤルールを取得し得る。
【0178】
一実施形態において、プッシュ通知要求は、頻繁に使用されないアプリケーションにのみ適用され得る。頻繁に使用されるアプリケーションの場合、ＮＥＦ３０１はＰＦＤルールをプッシュすることができ、その結果、ＵＰＦ３０２はＰＦＤルールを直ちに取得し得る。
【0179】
一実施形態において、要求メッセージは、図６Ａ～図６Ｂ及び図７Ａ～図７Ｃに示す様に、ＰＦＤ管理サービスの要求を示し得る。すなわち、ＵＰＦ３０２は、ＮＥＦ３０１に、アプリケーションのＰＦＤを提供するよう求める（要求する）ことができる（プル）。
【0180】
一実施形態において、要求メッセージ（この実施形態のＰＦＤ要求）は、プッシュシナリオと同様に、ベースラインを含んでもベースラインを含まなくてもよい。
【0181】
次いで、方法１０００は、ＵＰＦ３０２がＮＥＦ３０１から少なくとも１つのＰＦＤルールに関する情報を受信し得る、ステップＳ１００２に進み得る。
【0182】
一実施形態において、ＵＰＦ３０２からの要求メッセージに応じて、ＮＥＦ３０２は、変更されたＰＦＤルール（部分的なＰＦＤルール）及び最新のベースラインの存在をＵＰＦ３０２に通知するか、変更されたＰＦＤルールを通知とともに送信し得る。
【0183】
次いで、ステップＳ１００３で、ＵＰＦ３０２は、運用保守（Ｏ＆Ｍ）保守ウィンドウ中又はパケットデータユニット（ＰＤＵ）セッション確立時に、通知されたＰＦＤルールを取得し得る。ＮＥＦ３０２は変更されたＰＦＤルールを通知と共に送信することができるので、このステップは総てのアプリケーションに必要ではないことに留意されたい。
【0184】
【0185】
図１１は、本実施形態による、ＮＥＦ３０１における例示的なＰＦＤ管理装置を示すブロック図である。
【0186】
一実施形態において、ＮＥＦ３０１内の例示的なＰＦＤ管理装置は、少なくとも１つのプロセッサ１１０１と、少なくとも１つのプロセッサ１１０１に結合された非一時的コンピュータ可読媒体１１０２と、を含み得る。非一時的コンピュータ可読媒体１１０２は、少なくとも１つのプロセッサ１１０１によって実行可能な命令を含み、それにより、少なくとも１つのプロセッサ１１０１は、図８の概略フローチャートに示される様に、例示的な方法８００のステップを実行する様に構成され、その詳細については省略する。
【0187】
ＮＥＦ３０１内の例示的なＰＦＤ管理装置は、ハードウェア、ソフトウェア、ファームウェア、及び、それらの任意の組み合わせとして実装され得ることに留意されたい。例えば、ＮＥＦ３０１内の例示的なＰＦＤ管理装置は、複数のユニット、回路、モジュール等を含むことができ、それらの各々は、例示的な方法８００の１つ又は複数のステップ、又は、ＮＥＦ３０１に関連する図３～図７Ｃに示される１つ又は複数のステップを実行するために使用され得る。
【0188】
図１２は、本実施形態による、ＵＤＲ３０３における例示的なＰＦＤ管理装置を示すブロック図である。
【0189】
一実施形態において、ＵＤＲ３０３内の例示的なＰＦＤ管理装置は、少なくとも１つのプロセッサ１２０１と、少なくとも１つのプロセッサ１２０１に結合された非一時的コンピュータ可読媒体１２０２と、を含み得る。非一時的コンピュータ可読媒体１２０２は、少なくとも１つのプロセッサ１２０１によって実行可能な命令を含み、それにより、少なくとも１つのプロセッサ１２０１は、図９の概略フローチャートに示される様に、例示的な方法９００のステップを実行する様に構成され、その詳細については省略する。
【0190】
ＵＤＲ３０３内の例示的なＰＦＤ管理装置は、ハードウェア、ソフトウェア、ファームウェア及びそれらの任意の組み合わせとして実装され得ることに留意されたい。例えば、ＵＤＲ３０３内の例示的なＰＦＤ管理装置は、複数のユニット、回路、モジュール等を含むことができ、それらの各々は、例示的な方法９００の１つ又は複数のステップ、又は、ＵＤＲ３０３に関連する図３～図７Ｃに示される１つ又は複数のステップを実行するために使用され得る。
【0191】
図１３は、本実施形態による、ＵＰＦ３０３における例示的なＰＦＤ管理装置を示すブロック図である。
【0192】
一実施形態において、ＵＰＦ３０３内の例示的なＰＦＤ管理装置は、少なくとも１つのプロセッサ１３０１と、少なくとも１つのプロセッサ１３０１に結合された非一時的コンピュータ可読媒体１３０２と、を含み得る。非一時的コンピュータ可読媒体１３０２は、少なくとも１つのプロセッサ１３０１によって実行可能な命令を含み、それにより、少なくとも１つのプロセッサ１３０１は、図１０の概略フローチャートに示される様に、例示的な方法１０００のステップを実行する様に構成され、その詳細については省略する。
【0193】
ＵＰＦ３０２内の例示的なＰＦＤ管理装置は、ハードウェア、ソフトウェア、ファームウェア及びそれらの任意の組み合わせとして実装され得ることに留意されたい。例えば、ＵＰＦ３０３内の例示的なＰＦＤ管理装置は、複数のユニット、回路、モジュール等を含むことができ、それらの各々は、例示的な方法１０００の１つ又は複数のステップ、又は、ＵＰＦ３０２に関連する図３～図７Ｃに示される１つ又は複数のステップを実行するために使用され得る。
【0194】
図１４は、本実施形態による例示的なコンピュータ実装装置１４００を示すブロック図である。一実施形態において、装置１４００は、ＮＥＦ３０１内の例示的なＰＦＤ管理装置、ＵＰＦ３０２内の例示的なＰＦＤ管理装置、及び、ＵＤＲ３０３内の例示的なＰＦＤ管理装置等の上述の装置として構成され得る。
【0195】
一実施形態において、装置１４００は、限定はしないが、中央処理装置（ＣＰＵ）１４０１等の少なくとも１つのプロセッサ、コンピュータ可読媒体１４０２及びメモリ１４０３を含み得る。メモリ１４０３は、揮発性（例えば、ランダムアクセスメモリ、ＲＡＭ）及び／又は不揮発性メモリ（例えば、ハードディスク又はフラッシュメモリ）を含み得る。一実施形態において、コンピュータ可読媒体１４０２は、プロセッサ１４０１によって実行されると、プロセッサ１４０１に上記の方法のいずれかを実行させるコンピュータプログラム及び／又は命令を格納する様に構成され得る。
【0196】
一実施形態において、コンピュータ可読媒体１４０２（非一時的コンピュータ可読媒体等）は、メモリ１４０３に格納され得る。別の実施形態において、コンピュータプログラムは、例えば、コンピュータプログラム製品１４０４等の遠隔場所に格納することもでき（コンピュータ可読媒体として実施することもできる）、例えば、キャリア１４０５を介してプロセッサ１４０１によってアクセス可能である。
【0197】
コンピュータ可読媒体１４０２及び／又はコンピュータプログラム製品１４０４は、例えば、ディスケット、ＣＤ（コンパクトディスク）、ＤＶＤ（デジタルビデオディスク）、フラッシュ又は同様のリムーバブルメモリメディア（コンパクトフラッシュ（登録商標）、ＳＤ（セキュアデジタル）、メモリスティック、ミニＳＤカード、ＭＭＣマルチメディアカード、スマートメディア）、ＨＤ－ＤＶＤ（高精細ＤＶＤ）又はＢｌｕ－ｒａｙ（登録商標）ＤＶＤ、ＵＳＢ（ユニバーサルシリアルバス）ベースのリムーバブルメモリメディア、磁気テープメディア、光ストレージメディア、光磁気メディア、バブルメモリ等の取り外し可能なコンピュータ可読媒体に分散及び／又は格納することができる、或いは、ネットワーク経由で伝播信号として配信（例：イーサネット、ＡＴＭ、ＩＳＤＮ、ＰＳＴＮ、Ｘ．２５、インターネット、ローカルエリアネットワーク（ＬＡＮ）、又は、データパケットをインフラストラクチャノードに転送できる同様のネットワーク）され得る。
【0198】
例示的な実施形態は、５Ｇアーキテクチャを用いて上述されているが、実施形態は、４Ｇ ＬＴＥ（発展型パケットコア、ＥＰＣ）又は他の通信システムにも同様に適用可能である。
【0199】
例えば、一実施形態において、ＡＦと、その各アクションは、ＳＣＳ／ＡＳと、その各アクションであってもよく、ＮＥＦと、その各アクションは、ＳＣＥＦと、その各アクションに置き換えられてもよく、ＮＥＦ内のＰＦＤ管理サービスと、その各アクションは、ＰＦＤＦエンティティと、その各アクションに置き換えられてもよく、ＵＰＦと、その各アクションは、ＴＤＦ－Ｕ又はＰＧＷ－Ｕと、その各アクションに置き換えられてもよく、ＵＤＲでのＰＦＤの保存と、その各アクションは、ＰＦＤＦエンティティでの保存と、その各アクションに置き換えられてもよい。
【0200】
例えば、ネットワーク公開ノードは、例示的な実施形態においてネットワーク公開機能（ＮＥＦ）３０１を用いて上述されているが、ネットワーク公開ノードは、サービス能力公開機能（ＳＣＥＦ）に置き換えることもできる。
【0201】
例えば、ユーザプレーンノードは、例示的な実施形態においてユーザプレーン機能（ＵＰＦ）３０２を用いて上述されているが、ネットワーク公開ノードはまた、トラフィック検出機能ユーザプレーン機能（ＴＤＦ－Ｕ）又はＰＤＮゲートウェイユーザプレーン機能（ＰＧＷ－Ｕ）に置き換えられてもよい。
【0202】
例えば、ＰＦＤ格納ノードは、例示的な実施形態において統合データレポジトリ（ＵＤＲ）３０３で上述されているが、ネットワーク公開ノードは、パケットフロー記述機能（ＰＦＤＦ）エンティティに置き換えられてもよい。
【0203】
例えば、コンテンツ提供ノードは、例示的な実施形態においてアプリケーション機能（ＡＦ）３０４で上述されたが、ネットワーク公開ノードは、サービス機能サーバ（ＳＣＳ）／アプリケーションサーバ（ＡＳ）に置き換えられてもよい。
【0204】
例示的な実施形態は、コンピュータで実施される方法、装置（システム及び／又はデバイス）及び／又はコンピュータプログラム製品のブロック図及び／又はフローチャート図を参照して本明細書で説明される。ブロック図及び／又はフローチャートのブロック、ならびにブロック図及び／又はフローチャートにおけるブロックの組み合わせは、１つ又は複数のコンピュータ回路によって実行されるコンピュータプログラム命令によって実現され得ることが理解される。これらのコンピュータプログラム命令は、汎用コンピュータ回路、専用コンピュータ回路、及び／又は他のプログラム可能なデータ処理回路のプロセッサ回路に提供されてマシンが生成され、コンピュータのプロセッサ及び／又は他のプログラム可能なデータ処理装置を介して実行される命令、トランジスタ、メモリ位置に格納された値、ブロック図及び／又はフローチャートのブロックで指定された機能／動作を実現するためのそのような回路内の他のハードウェアコンポーネントを変換及び制御し、それにより、ブロック図及び／又はフローチャートのブロックで指定された機能／動作を実現するための手段（機能）及び／又は構造を作成する。
【0205】
これらのコンピュータプログラム命令は、また、コンピュータ又は他のプログラム可能なデータ処理装置が特定の方法で機能する様に命令できる有形のコンピュータ可読媒体に格納されてもよく、その結果、コンピュータ可読媒体に格納された命令は、ブロック図及び／又はフローチャートのブロックで指定された機能／動作を実現する命令を含む製品を生産する。したがって、本発明の概念の実施形態は、デジタル信号プロセッサ等のプロセッサ上で実行されるハードウェア及び／又はソフトウェア（ファームウェア、常駐ソフトウェア、マイクロコード等を含む）で実施することができ、まとめて"回路"、"モジュール"又はその変形としても参照され得る。
【0206】
また、幾つかの代替実装では、ブロックに記載されている機能／動作が、フローチャートに記載されている順序とは異なる順序で発生する場合があることにも注意されたい。例えば、関連する機能／動作に応じて、連続して示されている２つのブロックが実際には実質的に同時に実行されてもよく、あるいはブロックが逆の順序で実行されてもよい。さらに、フローチャート及び／又はブロック図の所与のブロックの機能は、複数のブロックに分離される、及び／又は、フローチャート及び／又はブロック図の２つ以上のブロックの機能は、少なくとも部分的に統合され得る。最後に、他のブロックを、図示されているブロックの間に追加／挿入することができ、及び／又は発明の概念の範囲から逸脱することなく、ブロック又は動作を省略することができる。さらに、いくつかの図は、通信の主要な方向を示すために通信経路上に矢印を含んでいるが、通信は、描かれた矢印とは反対の方向で起こり得ることを理解されたい。
【0207】
本発明の概念の原理から実質的に逸脱することなく、実施形態に対して多くの変更及び修正を行うことができる。そのような総ての変形及び修正は、本発明の概念の範囲内で本明細書に含まれることが意図されている。したがって、上記で開示された主題は、限定的ではなく例示的であると見なされるべきであり、添付の実施形態の例は、本発明の概念の精神及び範囲内にある総てのそのような修正、強化、及び他の実施形態をカバーすることを意図する。したがって、法律で許可される最大限の範囲で、本発明の概念の範囲は、以下の実施形態の例及びその等価物を含む本開示の最も広い許容可能な解釈によって決定されるべきであり、前述の詳細な説明によって制限又は限定されない。
【0208】
略語
ＡＦ アプリケーション機能
ＡＭＦ アクセス及びモビリティ機能
ＡＳ アプリケーションサーバ
ＣＰ 制御プレーン
ＣＵＰＳ 制御プレーンユーザプレーン分離
ＤＬ ダウンリンク
ＤＰＩ ディープパケット検査
ＦＡＲ 転送アクションルール
ＩＥ 情報要素
ＮＥＦ ネットワーク公開機能
ＰＣＦ ポリシ制御機能
ＰＣＲＦ ポリシ及び課金ルール機能
ＰＤＮ パケットデータネットワーク
ＰＤＲ パケット検出ルール
ＰＤＵ パケットデータユニット
ＰＦＣＰ パケットフロー制御プロトコル
ＰＦＤＦ パケットフロー記述機能
ＰＦＤ パケットフロー記述
ＰＧＷ パケットゲートウェイ
ＰＧＷ－Ｕ ＰＤＮゲートウェイユーザプレーン機能
ＱｏＳ サービス品質
ＲＡＮ 無線アクセスネットワーク
ＳＣＥＦ サービス能力公開機能
ＳＣＳ サービス能力サーバ
ＳＤＦ サービスデータフロー
ＳＭＦ セッション管理機能
ＳＵＰＩ サブスクリプションパラメータ識別子
ＴＤＦ－Ｕ トラフィック検出機能ユーザプレーン機能
ＵＤＲ 統合データリポジトリ
ＵＥ ユーザ装置
ＵＬ アップリンク
ＵＰ ユーザプレーン
ＵＰＦ ユーザプレーン機能
ＵＲＲ 利用報告ルール
ＷＩＤ ワークアイテム識別子
ＡＦ アプリケーション機能
ＡＭＦ アクセス及びモビリティ機能
ＡＳ アプリケーションサーバ
ＣＰ 制御プレーン
ＣＵＰＳ 制御プレーンユーザプレーン分離
ＤＬ ダウンリンク
ＤＰＩ ディープパケット検査
ＦＡＲ 転送アクションルール
ＩＥ 情報要素
ＮＥＦ ネットワーク公開機能
ＰＣＦ ポリシ制御機能
ＰＣＲＦ ポリシ及び課金ルール機能
ＰＤＮ パケットデータネットワーク
ＰＤＲ パケット検出ルール
ＰＤＵ パケットデータユニット
ＰＦＣＰ パケットフロー制御プロトコル
ＰＦＤＦ パケットフロー記述機能
ＰＦＤ パケットフロー記述
ＰＧＷ パケットゲートウェイ
ＰＧＷ－Ｕ ＰＤＮゲートウェイユーザプレーン機能
ＱｏＳ サービス品質
ＲＡＮ 無線アクセスネットワーク
ＳＣＥＦ サービス能力公開機能
ＳＣＳ サービス能力サーバ
ＳＤＦ サービスデータフロー
ＳＭＦ セッション管理機能
ＳＵＰＩ サブスクリプションパラメータ識別子
ＴＤＦ－Ｕ トラフィック検出機能ユーザプレーン機能
ＵＤＲ 統合データリポジトリ
ＵＥ ユーザ装置
ＵＬ アップリンク
ＵＰ ユーザプレーン
ＵＰＦ ユーザプレーン機能
ＵＲＲ 利用報告ルール
ＷＩＤ ワークアイテム識別子
【図1】
【図2】
【図3】
【図4A】
【図4B】
【図5】
【図6A】
【図6B】
【図7A】
【図7B】
【図7C】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】