特許 7516598 使用量監視データ制御

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-07-05

(45)【発行日】2024-07-16

(54)【発明の名称】使用量監視データ制御

(51)【国際特許分類】

   H04W 8/20 20090101AFI20240708BHJP

   H04W 4/24 20240101ALI20240708BHJP

   H04W 88/18 20090101ALI20240708BHJP

   H04W 92/24 20090101ALI20240708BHJP

【ＦＩ】

H04W8/20

H04W4/24

H04W88/18

H04W92/24

【請求項の数】 22

【外国語出願】

(21)【出願番号】P 2023041041

(22)【出願日】2023-03-15

(62)【分割の表示】P 2021523446の分割

【原出願日】2019-09-24

(65)【公開番号】P2023085329

(43)【公開日】2023-06-20

【審査請求日】2023-04-13

(31)【優先権主張番号】62/769,095

(32)【優先日】2018-11-19

(33)【優先権主張国・地域又は機関】US

(73)【特許権者】

【識別番号】598036300

【氏名又は名称】テレフオンアクチーボラゲット エルエム エリクソン（パブル）

(74)【代理人】

【識別番号】110003281

【氏名又は名称】弁理士法人大塚国際特許事務所

(72)【発明者】

【氏名】ガルシア アゾレロ， フエンシスラ

(72)【発明者】

【氏名】フェルナンデス アロンソ， スザーナ

(72)【発明者】

【氏名】イニエスタ ゴンザレス， アントニオ

(72)【発明者】

【氏名】マーティン カベロ， イレ－ネ

(72)【発明者】

【氏名】リヴァス モリーナ， イグナチオ

【審査官】桑江 晃

(56)【参考文献】

【文献】特表２０１７－５２９８１０（ＪＰ，Ａ）

【文献】特開２０１４－１９５２５２（ＪＰ，Ａ）

【文献】特表２０１３－５４１２７８（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｈ０４Ｗ ４／００ － ９９／００

３ＧＰＰ ＴＳＧ ＲＡＮ ＷＧ１－４

ＳＡ ＷＧ１－４

ＣＴ ＷＧ１，４

(57)【特許請求の範囲】

【請求項1】

ポリシ機能（２０２）が実行する、使用量情報を管理する方法（４００）であって、
デポジトリ機能（２０４）に情報に対する要求（２５２）を送信する（ｓ４０６）ことと、
前記要求に対する応答（２５４）を受信する（ｓ４０８）ことと、を有し、前記応答（２５４）が、
制限定義と、前記制限定義によって定義される制限を特定する制限識別子とを有するusageMonDataLimitインスタンスと、
前記usageMonDataLimitインスタンスによって定義される制限に関する使用量消費情報を有するusageMonDataインスタンスとを有し、前記usageMonDataインスタンスもまた前記制限識別子を有する、方法。

【請求項2】

請求項１に記載の方法であって、さらに、
前記要求（２５２）を送信する前に、管理機能（２０１）から要求（２５１）を受信する（ｓ４０２）ことと、
前記要求（２５１）に応じて、前記デポジトリ機能から前記情報を前記ポリシ機能（２０２）がフェッチする必要があるか否かを判定する（ｓ４０４）ことと、を有する、方法。

【請求項3】

請求項１または２に記載の方法であって、前記usageMonDataLimitインスタンスに関連付けられた前記usageMonDataインスタンスに変更が生じたときに前記ポリシ機能に通知を提供することを前記デポジトリ機能に要求する要求（２５６）を前記デポジトリ機能に送信することをさらに有する、方法。

【請求項4】

請求項１から３のいずれか１項に記載の方法であって、更新要求（３０４）を前記デポジトリ機能（２０４）に送信することをさらに有する、方法。

【請求項5】

請求項４に記載の方法であって、
前記更新要求（３０４）が、前記制限識別子を有するusageMonDataインスタンスを有するＨＴＴＰ ＰＡＴＣＨリクエストであるか、
前記更新要求（３０４）が、前記制限識別子を有するリソース識別子を有するＨＴＴＰ ＰＵＴリクエストである、方法。

【請求項6】

請求項１から５のいずれか１項に記載の方法であって、前記デポジトリ機能（２０４）に加入解除要求（３０６）を送信することをさらに有し、前記加入解除要求を送信することは、前記制限識別子を有するリソース識別子を有するボディを有するＨＴＴＰ ＰＵＴリクエストを送信することを有する、方法。

【請求項7】

請求項１から６のいずれか１項に記載の方法であって、前記usageMonDataLimitインスタンスが、
前記usageMonDataLimitインスタンスがPDUセッションレベルで適用されるのか、サービスレベルで適用されるのかを示す使用量監視レベルインスタンス、
開始日時を示す開始日情報、
終了日時を示す終了日情報、
最大許容トラフィック量を示す使用量制限閾値、または
許容使用量をリセットする必要がある時間を示すために使用されるリセット期間、の少なくとも１つをさらに有する、方法。

【請求項8】

請求項１から７のいずれか１項に記載の方法であって、前記usageMonDataLimitインスタンスは、前記usageMonDataLimitインスタンスが適用されるS-NSSAIとDNNの組み合わせを示すデータ適用範囲をさらに有する、方法。

【請求項9】

請求項１から８のいずれか１項に記載の方法であって、前記usageMonDataインスタンスがさらに、
前記usageMonDataインスタンスがPDUセッションレベルで適用されるのか、サービスレベルで適用されるのかを示す使用量監視レベル(umLevel)インスタンス、または
許容使用量値の少なくとも１つを有し、前記許容使用量値は残りの許容トラフィック量を示し、および／または前記許容使用量値は残り時間の長さを示す、方法。

【請求項10】

請求項１から９のいずれか１項に記載の方法であって、前記usageMonDataインスタンスは使用量消費情報を有し、前記使用量消費情報は前記特定された制限の残り使用量を定義する、方法。

【請求項11】

請求項１から１０のいずれか１項に記載の方法であって、前記制限識別子が、前記定義される制限の名前を特定する、方法。

【請求項12】

デポジトリ機能（２０４）が実行する、使用量情報を管理する方法（５００）であって、
ポリシ機能（２０２）から情報に対する要求（２５２）を受信する（ｓ５０２）ことと、
前記ポリシ機能（２０２）からの前記要求に応じて、応答（２５４）を送信する（ｓ５０４）ことと、を有し、前記応答（２５４）が、
制限定義と、前記制限定義によって定義される制限を特定する制限識別子とを有するusageMonDataLimitインスタンスと、
前記usageMonDataLimitインスタンスによって定義される制限に関する使用量消費情報を有するusageMonDataインスタンスとを有し、前記usageMonDataインスタンスもまた前記制限識別子を有する、方法。

【請求項13】

請求項１２に記載の方法であって、前記ポリシ機能から更新要求（３０４）を受信する（ｓ５０６）ことをさらに有する、方法。

【請求項14】

請求項１３に記載の方法であって、
前記更新要求（３０４）が、前記制限識別子を有するusageMonDataインスタンスを有するＨＴＴＰ ＰＡＴＣＨリクエストであるか、
前記更新要求（３０４）が、前記制限識別子を有するリソース識別子を有するＨＴＴＰ ＰＵＴリクエストである、方法。

【請求項15】

請求項１２から１４のいずれか１項に記載の方法であって、前記usageMonDataLimitインスタンスが、
前記usageMonDataLimitインスタンスがＰＤＵセッションレベルで適用されるのか、サービスレベルで適用されるのかを示す使用量監視レベルインスタンス、
開始日時を示す開始日情報、
終了日時を示す終了日情報、
最大許容トラフィック量を示す使用量制限閾値、または
許容使用量をリセットする必要がある時間を示すために使用されるリセット期間、の少なくとも１つをさらに有する、方法。

【請求項16】

請求項１２から１５のいずれか１項に記載の方法であって、前記usageMonDataLimitインスタンスは、前記usageMonDataLimitインスタンスが適用されるS-NSSAIとDNNの組み合わせを示すデータ適用範囲をさらに有する、方法。

【請求項17】

請求項１２から１６のいずれか１項に記載の方法であって、前記usageMonDataインスタンスがさらに、
前記usageMonDataインスタンスがＰＤＵセッションレベルで適用されるのか、サービスレベルで適用されるのかを示す使用量監視レベル(umLevel)インスタンス、または
許容使用量値の少なくとも１つを有し、前記許容使用量値は残りの許容トラフィック量を示し、および／または前記許容使用量値は残り時間の長さを示す、方法。

【請求項18】

装置（６００）の処理回路（６０２）によって実行されると、請求項１から１７のいずれか１項に記載の方法を前記装置（６００）に実行させる命令（６４４）を有するコンピュータプログラム（６４３）。

【請求項19】

ポリシ機能装置（６０１）であって、
デポジトリ機能（２０４）に、情報に対する要求（２５２）を送信し、
前記要求に対する応答（２５４）を受信するように適合され、
前記応答（２５４）は、制限定義と、前記制限定義によって定義される制限を特定する制限識別子とを有するusageMonDataLimitインスタンスと、前記usageMonDataLimitインスタンスによって定義される制限に関する使用量消費情報を有するusageMonDataインスタンスとを有し、前記usageMonDataインスタンスもまた前記制限識別子を有する、ポリシ機能装置。

【請求項20】

請求項１９に記載のポリシ機能装置であって、請求項２から１１のいずれか１項に記載の方法を実行するようにさらに適合される、ポリシ装置。

【請求項21】

デポジトリ機能装置（６０１）であって、
ポリシ機能（２０２）から、情報に対する要求（２５２）を受信し、
前記ポリシ機能（２０２）からの前記要求に応じて、応答（２５４）を送信するように適合され、
前記応答（２５４）は、制限定義と、前記制限定義によって定義される制限を特定する制限識別子とを有するusageMonDataLimitインスタンスと、前記usageMonDataLimitインスタンスによって定義される制限に関する使用量消費情報を有するusageMonDataインスタンスとを有し、前記usageMonDataインスタンスもまた前記制限識別子を有する、デポジトリ機能装置。

【請求項22】

請求項２１に記載のデポジトリ機能装置であって、請求項１３から１７のいずれか１項に記載の方法を実行するようにさらに適合される、デポジトリ機能装置。

【発明の詳細な説明】

【技術分野】

【0001】

[001] 本開示は使用量監視データの管理に関する。

【背景技術】

【0002】

[002] 使用量監視機能により、ネットワーク事業者は加入者のデータ利用を制御することができる。これはサービスレベルで、または各ＰＤＵセッションレベルで実施可能である。例えば、ネットワーク事業者は、所定の加入者について、Netflixデータを１ヶ月あたり５ギガバイトを超えてダウンロードできないように指定することができる。

【0003】

[003] 使用量監視機能は、ポリシ機能（例えば４Ｇポリシおよび課金ルール機能（ＰＣＲＦ）または５Ｇポリシ制御機能（ＰＣＦ））を実装するネットワークノードによって制御される。監視鍵がポリシ機能（例えばＰＣＲＦ／ＰＣＦ）によって割り当てられることにより、トラフィックハンドリングネットワーク機能（例えば４Ｇ ＰＧＷ／ＵＰまたは５Ｇ ＳＭＦ／ＵＰＦ）がその監視鍵に関するトラフィックを監視できるようになる。

【0004】

[004] 監視鍵はポリシ機能によって割り当てられる。監視鍵は、監視がサービスレベルで適用される場合には、ポリシルール（例えば、ＰＣＣルール）の一部として提供され、監視がセッション（例えば、ＩＰ－ＣＡＮ／ＰＤＵセッション）に適用される場合には、セッション情報の一部として提供される。同じ監視鍵を共有するすべてのサービスデータフローまたはアプリケーションは、APN（4G）／DNN（5G）ごとに、加入者の端末装置（ユーザー機器（UE）とも呼ばれる）について共通の許容使用量を持つことになる。

【0005】

[005] 使用量監視情報は、ＳＰＲ（４Ｇ）またはＵＤＲ（４Ｇおよび５Ｇ）に保存される。

【0006】

[006] 非５Gシナリオについては、データベースに向かうインタフェースは規定されていない。５Ｇでは、３ＧＰＰ ＴＳ ２３.５０３（ステージ２）およびＴＳ ２９.５１９（ステージ３）が、ＰＣＦとＵＤＲの間のインターフェースを規定している。

【発明の概要】

【0007】

[007] 現在、ある課題が存在している。３ＧＰＰ ＴＳ ２９．５１９ Ｖ１５．１．０（以下、ＴＳ ２９．５１９とする）は、ＰＣＦとＵＤＲ(Unified Data Repository)の間のインタフェースを規定している。ＴＳ ２９．５１９によれば、使用量監視情報を制御するために特定のリソースが定義されている。使用状況監視情報は、以下の構造に従って保存される：{apiRoot}/nudr-dr/v1/policy-data{ueId}/sm-data/{usageMonId}。

【0008】

[008] ＰＣＦは、UsageMonIdに関する残りの利用量を保存するために、使用量監視リソースを作成することができる。このリソースは、対応する制限が存在しなくなると削除されてもよい。ＰＣＦは、ＰＤＵセッションのライフタイム中、いつでもUE idおよびUsageMonIdに関する使用量監視情報を取得および変更することができる。

【表1】

【0009】

[009] ＰＣＦがどのようにusageMonIdを得るのか、また、usageMonIdが利用制限（UsageMonDataLimitデータタイプ）もしくは監視データ(UsageMonData)内の情報とどのように関連するのかについては規定されていない。

【0010】

[0010] UsageMonitoringInformationリソースのリソース定義では、変数フィールド「usageMonId」にどの識別子を使用するかが明確に定義されていない。

【0011】

[0011] 「UsageMonId」変数フィールドは、ＰＣＦがＳＭＦへのトラフィックを監視するために用いる監視鍵に対応していると仮定することができる。しかし、「usageMonId」で監視鍵が使用されているとすると、現在規定されている監視鍵の対象範囲（すなわち、ＵＥごとおよびＤＮＮごと）を制限する必要がある。以下に示すような、監視鍵の値の新しい対象範囲が考えられるであろう。

【0012】

[0012] 1)監視鍵の値の対象範囲をS-NSSAI/DNNペアごとにすること。しかし、監視鍵の値の対象範囲をS-NSSAI/DNNペアごとにすると、S-NSSAI/DNNの違った組み合わせについて利用料を蓄積する可能性を制限しうる。さらに、現在の仕様に対して以下の変更が必要になるであろう：UsageMonitoringInformationの個々のリソースは、異なる制限に対応して蓄積された使用状況情報を表すことができる。結果として、UsageMonDataはS-NSSAI/DNN情報を含むように更新される必要があり、また、蓄積装置の更新中に高い制御を維持するため、PUTの代わりにPATCHメソッドが使用されるべきである。

【0013】

[0013] 2)監視鍵の値の対象範囲を制限定義ごとにし、同じ制限定義に該当するDNN/S-NSSAIペアには同じ監視鍵の値が割り当てられ、制限が異なれば常に異なる監視鍵の値が割り当てられるようにする。これを実施した場合、現在の監視鍵の定義方法が制限され、累積利用量がＳＭＦにおける監視利用量とリンクされることになる。以下の影響を考慮する必要があるであろう：UsageMonitoringInformationの個々のリソースは、ある制限に対応する蓄積利用情報を表す。つまり、DNN/S-NSSAI情報はUsageMonitoringInformation資源とは関係しない。これは、DNN/S-NSSAI情報がSm-Dataリソースの制限定義において考慮されるためである。S-NSSAI/DNNのクエリパラメータは削除することができる。

【0014】

[0014] 3)監視鍵の値がユニークになるように、監視鍵の対象範囲をデプロイメントごとにすること。これにより、UsageMonitoringInformationの個々のリソースが、S-NSSAI/DNNペアの最新の更新に対応する蓄積利用情報を表すようになる。つまり、DNN/S-NSSAI情報はUsageMonitoringInformation資源とは関係しない。これは、DNN/S-NSSAI情報が既に監視鍵を含んでいるSm-Dataリソースの制限定義において考慮されるためである。S-NSSAI/DNNクエリパラメータは削除することができ、UsageMonitoringInformationの個々のリソースは正確な制限情報ではないが、最後のPDUセッション更新時の残値を含む。

【0015】

[0015] これら可能性のある手法はいずれも、SMF/UPFでの利用量監視という文脈における監視鍵の利用をユーザデータベースで実行される蓄積方法から切り離すという、今日における監視鍵の利用方法を制限するものである。

【0016】

[0016] したがって、本開示は、「usageMonId」リソース識別子（例えばURI）変数において、ある利用量の制限を特定する識別子を使用することを提案する。この識別子は、「Accumulator/Limit Identifier」または（略して「limitId」）と呼ばれうる。UsageMonitoringInformationの個々のリソースは、制限識別子によって特定される所定の制限に対応する、蓄積利用量情報を表す。そのため、監視鍵の値の定義には制限はない。本手法では、UsageMonDataLimitおよびUsageMonDataデータタイプにlimitIdを含めることを必要とする。提案する手法の利点は、監視鍵の現在の対象範囲に対して最も高い柔軟性を提供することである。提案する手法はまた、UDRでの蓄積方法から監視鍵の利用を切り離すことを可能にし、さらに、蓄積方法の柔軟なモデルを可能にする。監視鍵の定義には制限がないため、DNNとS-NSSAIの異なる組み合わせごとに蓄積を行うさまざまなビジネスモデルが可能となる。さらに、規定されている使用量の監視方法に影響を与えないという利点もある。

【0017】

[0017] したがって、一態様において、ポリシ機能（例えば、PCF）が、デポジトリ機能（例えば、UDR）に情報要求を送信することを含む方法が提供される。方法はまた、ポリシ機能が応答を受信することを含み、応答は、制限識別子を有するUsageMonDataLimitインスタンスと、UsageMonDataLimitインスタンスに対応するUsageMonDataインスタンスとを有し、UsageMonDataインスタンスも制限識別子を有する。

【0018】

[0018] いくつかの実施形態において、方法は、要求を送信する前に、ポリシ機能が、管理機能から要求を受信することと、ポリシ機能がデポジトリ機能から情報をフェッチする必要があるかどうかを、要求に応答してポリシ機能が決定することと、をさらに含む。

【0019】

[0019] いくつかの実施形態において、方法は、UsageMonDataLimitインスタンスに関連付けられたUsageMonDataインスタンスに変更が生じたときに、ポリシ機能に通知を提供することをデポジトリ機能に要求する要求を、ポリシ機能がデポジトリ機能に送信することをさらに含む。

【0020】

[0020] いくつかの実施形態において、方法は、ポリシ機能が更新要求をデポジトリ機能に送信することをさらに含む。いくつかの実施形態において、更新要求は、制限識別子を有するUsageMonDataインスタンスを有するＨＴＴＰ ＰＡＴＣＨリクエストであり、または、更新要求は、制限識別子を有するリソース識別子（例えば、ＵＲＩ）を有するＨＴＴＰ ＰＵＴリクエストである。

【0021】

[0021] いくつかの実施形態において、方法は、ポリシ機能が、デポジトリ機能に加入解除要求を送信することをさらに含み、加入解除要求を送信することは、制限識別子を有するリソース識別子を有するボディを有するＨＴＴＰ ＰＵＴリクエストを送信することを有する。

【0022】

[0022] いくつかの実施形態において、UsageMonDataLimitインスタンスは、さらに、UsageMonDataLimitインスタンスがPDUセッションレベルまたはサービスレベルのいずれで適用されるかを示す使用量監視レベルインスタンス、開始日時を示す開始日情報、終了日時を示す終了日情報、最大許容トラフィック量を示す利用量制限閾値、または許容利用量をリセットする必要がある時間を示すために使用されるリセット期間、の少なくとも１つを有する。

【0023】

[0023] いくつかの実施形態において、UsageMonDataLimitインスタンスは、UsageMonDataLimitインスタンスが適用されるS-NSSAIとDNNの組み合わせを示すデータスコープをさらに有する。

【0024】

[0024] いくつかの実施形態において、UsageMonDataインスタンスはさらに、usageMonDataインスタンスがPDUセッションレベルで適用されるのか、サービスレベルで適用されるのかを示す使用量監視レベル(umLevel)インスタンス、または許容使用量値の少なくとも１つを有し、許容使用量値は残りの許容トラフィック量および／または残り時間の長さを示す。

【0025】

[0025] いくつかの実施形態において、usageMonDataインスタンスは、許容使用量を使用量制限閾値にリセットする時間を示す情報をさらに有する。

【0026】

[0026] 別の態様において方法が提供され、この方法は、デポジトリ機能（例えばＵＤＲ）が、ポリシ機能（例えばＰＣＦ）から情報の要求を受信することを含む。方法はまた、デポジトリ機能が要求に応じて応答を送信することを含み、応答は、制限識別子を有するusageMonDataLimitインスタンスと、usageMonDataLimitインスタンスに対応するusageMonDataインスタンスとを有し、usageMonDataインスタンスもまた制限識別子を有する。

【0027】

[0027] いくつかの実施形態において方法は、デポジトリ機能がポリシ機能から更新要求を受信することをさらに含む。いくつかの実施形態において、更新要求は、制限識別子を有するUsageMonDataインスタンスを有するＨＴＴＰ ＰＡＴＣＨリクエストであり、または、更新要求は、制限識別子を有するリソース識別子（例えば、URI）を有するＨＴＴＰ ＰＵＴリクエストである。

【0028】

[0028] いくつかの実施形態において方法は、デポジトリ機能がポリシ機能から加入解除要求を受信することをさらに含む。いくつかの実施形態において、加入解除要求は、制限識別子を有するリソース識別子を有するボディを有するＨＴＴＰ ＰＵＴリクエストである。

【0029】

[0029] いくつかの実施形態において、usageMonDataLimitインスタンスはさらに、usageMonDataLimitインスタンスがPDUセッションレベルまたはサービスレベルのいずれで適用されるかを示す使用量監視レベルインスタンス、開始日時を示す開始日情報、終了日時を示す終了日情報、最大許容トラフィック量を示す使用量制限閾値、または許容使用量をリセットする必要のある時間を示すために用いられるリセット期間、の少なくとも１つを有する。

【0030】

[0030] いくつかの実施形態において、usageMonDataLimitインスタンスは、usageMonDataLimitインスタンスが適用されるS-NSSAIとDNNの組み合わせを示すデータ適用範囲(data scope)をさらに有する。

【0031】

[0031] いくつかの実施形態において、usageMonDataインスタンスはさらに、usageMonDataインスタンスがPDUセッションレベルで適用されるのか、サービスレベルで適用されるのかを示す使用量監視レベル(umLevel)インスタンス、または許容使用量値の少なくとも１つを有し、許容使用量値は残りの許容トラフィック量および／または残り時間の長さを示す。

【0032】

[0032] いくつかの実施形態において、usageMonDataインスタンスは、許容使用量を使用量制限閾値にリセットする時間を示す情報をさらに有する。

【0033】

[0033] 別の態様において、装置の処理回路によって実行されると、本明細書に記載された方法を装置に実行させる命令を有するコンピュータプログラムが提供される。別の態様において、前段落に記載のコンピュータプログラムを含んだ担体(carrier)が提供され、担体は、電子信号、光信号、無線信号、およびコンピュータ可読記憶媒体の１つである。

【0034】

[0034] 別の態様において、ポリシ機能装置が提供される。ポリシ機能装置は、情報の要求をデポジトリ機能に送信し、要求に対する応答を受信するように適合されている。応答は、制限識別子を有するusageMonDataLimitインスタンスと、usageMonDataLimitインスタンスに対応するusageMonDataインスタンスとを含み、usageMonDataインスタンスもまた制限識別子を有する。

【0035】

[0035] 別の態様において、デポジトリ機能装置が提供される。デポジトリ機能装置は、ポリシ機能から情報の要求を受信し、ポリシ機能からの要求に応じて応答を送信するように適合されている。応答は、制限識別子を有するusageMonDataLimitインスタンスと、usageMonDataLimitインスタンスに対応するusageMonDataインスタンスとを有し、usageMonDataインスタンスもまた制限識別子を有する。

【図面の簡単な説明】

【0036】

[0036] 本明細書に組み込まれ、本明細書の一部を構成する添付図面は、様々な実施形態を例示している。

【図1】[0037] 図１は、リソース構造の例を示す。

【図2】[0038] 図２は、フロー図の例である。

【図3】[0039] 図３は、メッセージフロー図の例である。

【図4】[0040] 図４は、一実施形態に係る手順を説明するフローチャートである。

【図5】[0041] 図５は、一実施形態に係る手順を説明するフローチャートである。

【図6】[0042] 図６は、一実施形態に係る装置のブロック図である。

【発明を実施するための形態】

【0037】

[0043] 上述の通り、TS 29.519はＰＣＦとＵＤＲの間のインタフェースを規定している。TS 29.519によれば、使用量監視情報を制御するための特定のリソースが定義される。使用状況監視情報は、以下の構造に従って保存される：{apiRoot}/nudr-dr/v1/policy-data/{ueId}/sm-data/{usageMonId}。リソース構造を図１に示す。

【0038】

[0044] ここで提案する解決策は、TS 29.519の現行バージョンへの変更を必要とする。TS 29.519の5.4.2節では、さまざまな構造化データタイプを定義している。定義された構造化データタイプの１つは「UsageMonDataLimit」タイプであり、これはTS 29.519の表5.4.2.6-1で定義されている。この表を以下に示す。

【表2】

【0039】

[0045] UsageMonDataLimitタイプは、時間の経過とともに、他の属性を含むように変化してもよい。例えば、UsageMonDataLimitタイプは、「scopes」という名前の属性をさらに含みうる。「scopes」属性は、UsageMonDataScopeタイプであり、usageMonDataLimitインスタンスが適用されるS-NSSAIとDNNの組み合わせを特定する情報を有する。

【0040】

[0046] 本開示では、UsageMonDataLimitタイプが「limitId」という名前の属性を含むように定義を修正することを提案する。limitId属性は、データタイプ「string」を有し、必須(M)であり、濃度(cardinality)１を有する。この新しい属性の説明は、「制限を特定する(Identifies the limit)」である。つまり、limitId属性は、使用量監視制御インスタンスを特定する。

【0041】

[0047] 定義される構造化データタイプの別の１つは「UsageMonData」タイプであり、これは現在、以下に示すTS 29.519の表5.4.2.7-1に定義されている。

【表3】

【0042】

[0048] 本開示では、「monKey」属性を「limitId」という名前の属性で置き換えることを提案する。limitId属性は、データタイプ「string」を有し、必須(M)であり、濃度１を有する。この新しい属性の説明は以下の通りである。UsageMonDataLimitデータタイプの「limitId」属性に定義されている制限を特定する（TS 29.519の5.4.2.6節参照）。

【0043】

[0049] UsageMonDataタイプは、時間の経過とともに、他の属性を含むように変化してもよい。例えば、UsageMonDataタイプは、「resetTime」という名前の属性を含みうる。「resetTime」属性は、DateTimeタイプであり、許容使用量を、対応するUsageMonDataLimitのusageLimitに戻すリセットを行う時間を示す情報を有する。

【0044】

[0050] 「UsageMonitoringInformation」リソースは、TS 29.519の5.2.6節に説明されている。TS 29.519の5.2.6.1節で説明されているように、UsageMonitoringInformation「リソースは、UDR で作成され、ueIdとusageMonIdに関連付けられる、個々の使用量監視リソースを表す。」

【0045】

[0051] TS 29.519の5.2.6.2節は、「リソース定義 」を規定している。具体的には、本節では、リソースについてのリソース識別子を「{apiRoot}/nudr-dr/v1/policy-data/{ueId}/sm-data/{usageMonId}」と規定している。TS 29.519の5.2.6.2節では現在、変数apiRoot、ueId、usageMonIdを、（TS 29.519の表5.2.6.2-1に対応する）以下の表に示すように定義している。

【表4】

【0046】

[0052] 本開示では、usageMonIdの定義をさらに拡張し、usageMonId変数が「個々のSMポリシ使用量監視リソースの一意の識別子」であるだけでなく、上述したUsageMonDataLimitデータタイプの「limitId」属性に定義されるような対応する制限のＩＤ(identity)を含むようにする。本開示ではさらに、UsageMonitoringInformationリソースについてのGETメソッドがURIクエリパラメータをサポートしないように技術仕様を変更することを提案する。

【0047】

[0053] 図２は、例えば、ＵＤＲ２０４と通信しているＰＣＦ２０２を示すメッセージフロー図である。ＵＤＲ２０４は、ＰＣＦ２０２がユーザ、S-NSSAI、およびDNNのためのポリシデータを格納および取得する加入者リポジトリである。ＰＣＣフローにおけるＵＤＲとのやりとりの詳細については、C3-186391（現在、www.3gpp.org/FTP/Meetings_3GPP_SYNC/CT3/Inbox/C3-186391.zipで入手可能）に取り決めされている。

【0048】

[0054] 図２に示すこの手順は、ローミングシナリオと非ローミングシナリオの両方に関するものである。home routed方式のローミングの場合、ＰＣＦ２０２はＨ－ＰＣＦとして動作する。LBO方式のローミングの場合、ＰＣＦ２０２はＶーＰＣＦとして動作し、ステップ２から４はスキップされてもよい。

【0049】

[0055] ステップ１：ＳＭＦ２０１は、ユーザ機器(UE)からＰＤＵセッション確立要求を受信する。つまり、ＳＭＦ２０１は、ＵＥがＳＭＦに向けて送信したＰＤＵセッション確立要求を受信する。ＳＭＦ２０１は、TS 29.513の8.3節に記載されているようにＰＣＦを選択し、リソースＵＲＩ「{apiRoot}/npcf-smpolicycontrol/v1/sm-policies」にＨＴＴＰ ＰＯＳＴリクエストを送信することにより、Npcf_SMPolicyControl_Createサービスオペレーションを呼び出す。リクエストオペレーションは、ＳＵＰＩ、ＰＤＵセッションＩＤ、ＰＤＵセッションタイプ、ＤＮＮ、およびS-NSSAIを提供し、GPSI、内部グループ識別子、アクセスタイプ、IPv4アドレスまたはIPv6ネットワークプレフィックス（利用可能な場合）、ＳＭＦ２０１で受信した場合はＰＥＩ、ユーザロケーション情報、ＵＥタイムゾーン、サービングネットワーク、ＲＡＴタイプ、課金情報、加入Session-AMBR、および加入デフォルトの5QI/ARP（利用可能な場合）を提供することができる。リクエストオペレーションはさらに、ＳＭ関連ポリシが更新されたときに通知を送信する場所をＰＣＦに指示すための通知ＵＲＩを含む。

【0050】

[0056] ステップ２：ＰＣＦ２０２は、自身がＳＵＰＩおよびＤＮＮについての加入データを有するか否かを判定する。ＰＣＦ２０２がＳＵＰＩおよびＤＮＮについての加入データを有していなければ、ＰＣＦ２０２はNudr_DataRepository_QueryサービスオペレーションをＵＤＲ２０４に呼び出しする（例えば、ＰＣＦ２０２は、TS 29.519に規定されるように、リソースURI：{apiRoot}/nudr-dr/v1/policy-data/{ueId}/sm-dataを特定するＨＴＴＰ ＧＥＴリクエストをＵＤＲ２０４に送信する）。

【0051】

[0057] ステップ３：ＵＤＲ２０４はＧＥＴリクエストを受信し、その後ＨＴＴＰ「２００ ＯＫ」応答をＰＣＦ２０２に送信する。この応答には、制限定義を有するUsageMonDataLimit適用インスタンスと、使用量消費情報を有するUsageMonData適用インスタンスとを含む、{apiRoot}/nudr-dr/v1/policy-data/{ueId}/sm-data下のリソースが含まれている。

【0052】

[0058] UsageMonDataLimitインスタンスは.../sm-dataリソースに格納され、UsageMonDataインスタンスは/{usageMonId}リソースに格納され、両方とも.../sm-dataリソースＵＲＩへのＧＥＴリクエストを用いて取得されることに留意されたい。

【0053】

[0059] 各UsageMonDataLimitインスタンスは、制限の名前を特定する「limitId」属性（例えば「limitId」：「Facebook-limit」）とともに、定義されたusageLimit（例えば「UsageLimit」：「500MB」）および他のオプションのパラメータを含む。

【0054】

[0060] 各UsageMonDataインスタンスは、制限の名前を特定する「limitId」属性（例えば「limitId」：「Facebook-limit」）とともに、「allowedUsage」属性に残りの使用量（例えば「allowedUsage」：「200MB」）を含む。

【0055】

[0061] ＵＤＲ２０４は、既存の{usageMonId}ごとにUsageMonDataを提供する。UsageMonDataは、monitoringKeyの代わりにlimitIdを含む。

【0056】

[0062] ステップ４：ＰＣＦ２０２がＵＤＲ２０４によって送信された応答を受信すると、ＰＣＦ２０２は、応答がＵＥについてのUsageMonDataLimitインスタンスを含むか否かを検出する。ＰＣＦ２０２が、ＵＥについてのUsageMonDataLimitが存在することを検出した場合、ＰＣＦ２０２は、UsageMonDataLimitインスタンスに関連付けられたUsageMonDataインスタンス（すなわち、UsageMonDataLimitインスタンスに含まれ、UsageMonDataLimitインスタンスを特定するlimitIdと同じlimitIdを含むUsageMonDataインスタンス）に変更が生じたときにＰＣＦ２０２に通知を提供することをＵＤＲ２０４に要求してもよい。ＰＣＦ２０２は、Nudr_DataRepository_Subscribeサービスオペレーションを呼び出す（例えば、ＵＲＩ：{apiRoot}/nudr-dr/v1/policy-data/{ueId}/sm-data/{usageMonId}を有するＨＴＴＰメッセージをＵＤＲ２０４に送信する）ことにより、ＵＤＲ２０４にこれらの通知を要求する。ここで、「UsageMonId」は、受信したUsageMonDataLimitインスタンスに含まれる「limitId」である。ＰＣＦ２０２は、sm-dataリソースで表されるデータの変更通知を受信するために加入してもよいことに留意されたい。

【0057】

[0063] ステップ５：ＵＤＲ２０４は、ＰＣＦ２０２からの加入を確認するために、ＨＴＴＰ「２０１ Ｃｒｅａｔｅｄ」応答を送信する。

【0058】

[0064] ステップ６：ＰＣＦ２０２が、ポリシ決定がＣＨＦ２０６で利用可能なポリシカウンタの状態に依存すると判定し、そのような報告が加入者に対して確立されていない場合、ＰＣＦ２０２は、3GPP TS 29.594 V15.1.0の5.3.2節に定義されているように、初期支出制限レポート取得(Initial Spending Limit Report Retrieval)を開始する。ポリシカウンタの状態報告が加入者に対して既に確立されており、さらなるポリシカウンタの状態が必要であるとＰＣＦ２０２が判断した場合、ＰＣＦ２０２は、3GPP TS 29.594 V15.1.0の5.3.3節に定義されているように、中間支出限度額レポート取得(Intermediate Spending Limit Report Retrieval)を開始する。

【0059】

[0065] ステップ７：ＰＣＦ２０２は、ステップ６で提供された情報を判断してポリシ決定を行う。

【0060】

[0066] ステップ８：ＰＣＦ２０２は、3GPP TS 29.512 V15.1.0の4.2.2節に記載されているように、決定されたポリシとともに、ＳＭＦ２０１にＨＴＴＰ「２０１ Ｃｒｅａｔｅｄ」応答を送信する。このステップの後、ＰＣＦ２０２は、ＰＤＵセッションに関連付けられたＳＭＦ２０１のイベントに加入することができる。

【0061】

[0067] 図３は、ＰＣＦ２０２およびＵＤＲ２０４を含む、様々な機能間の通信を示す別のメッセージフロー図である。

【0062】

[0068] ステップ１：ＳＭＦ２０１は、ＰＣＦにＳＭ関連ポリシのコンテキストの削除を要求するため、「{apiRoot}/npcf-smpolicycontrol/v1/sm-policies/{smPolicyId}/delete」をリソースＵＲＩとして用いたＨＴＴＰ ＰＯＳＴリクエストを送信することにより、Npcf＿SMPolicyControl＿Deleteサービスオペレーションを呼び出す。リクエストオペレーションは、使用量監視情報（該当する場合）とアクセスネットワーク情報とを含んでもよい。

【0063】

[0069] ステップ２：Npcf_SMPolicyControl_Deleteサービスオペレーションを受信すると、ＰＣＦは、ＡＦ３０１への通知が必要なＰＣＣルールを特定するとともに、ＰＤＵセッションに関するＰＣＣルールを削除する。

【0064】

[0070] ステップ３：ＳＭＦ２０１は、ＰＤＵセッションに適用されている全てのＰＣＣルールを削除する。

【0065】

[0071] ステップ４：ＰＣＦ２０２は、ＡＦ３０１から要求されていれば、サービス用の送信リソースが存在しないことを示すために、リソースＵＲＩとして「{notifUri}/notify」を用いたＨＴＴＰ ＰＯＳＴリクエストをＡＦ３０１に送信することによって、Npcf_PolicyAuthorization_Notifyサービスオペレーションを呼び出す。

【0066】

[0072] ステップ５：ＡＦ３０１は、ＨＴＴＰ「２０４ Ｎｏ Ｃｏｎｔｅｎｔ」応答をＰＣＦ２０２に送信する。

【0067】

[0073] ステップ６：ＡＦ３０１は、リソースＵＲＩ「{apiRoot}/npcf-policyauthorization/v1/app-sessions/{appSessionId}/delete」にＨＴＴＰ ＰＯＳＴリクエストを送信することにより、Npcf_PolicyAuthorization_Deleteサービスオペレーションを呼び出す。リクエストは、加入するイベントを含んでいてもよい。

【0068】

[0074] ステップ７：ＰＣＦ２０２は、ＡＦアプリケーションセッションコンテキストを削除し、ＨＴＴＰ「２０４ Ｎｏ Ｃｏｎｔｅｎｔ」応答をＡＦに送信する。ＰＣＦ２０２が使用量データまたはアクセスネットワーク情報を報告する必要がある場合、ＰＣＦ２０２はＨＴＴＰ「２００ ＯＫ」応答を送信する。使用量閾値が事前にＡＦから提供されており、ＰＣＦ２０２がまだＡＦに報告されていない使用量データを有する場合、ＰＣＦ２０２は、前回の報告以降にユーザによって消費されたリソースに関してＡＦ３０１に知らせる。また、ステップ１でＳＭＦ２０１がアクセスネットワーク情報を報告し、かつ、ＡＦ３０１がＰＣＦ２０２にアクセスネットワーク情報の報告を事前に要求していた場合、ＰＣＦ２０２は、アクセスネットワーク情報をＡＦ３０１に知らせる。ＰＣＦ２０２はまた、そのＡＦアプリケーションセッションについて、ＰＣＦ２０２が検出したイベントの加入を削除する。

【0069】

[0075] ステップ４ａ：ＰＣＦ２０２は、ｄｉａｍｅｔｅｒ ＡＳＲをＡＦ３０１に送信することにより、ＡＦ３０１にセッションの中止を指示する。

【0070】

[0076] ステップ５ａ：ＡＦ３０１は、ＰＣＦ２０２にｄｉａｍｅｔｅｒ ＡＳＡを送信することによって応答する。

【0071】

[0077] ステップ６ａ：ＡＦ３０１は、セッションが終了したことを示すために、ｄｉａｍｅｔｅｒ ＳＴＲをＰＣＦ２０２に送信する。

【0072】

[0078] ステップ７ａ：ＰＣＦ２０２は、ｄｉａｍｅｔｅｒ ＳＴＡをＡＦ３０１に送信することによって応答する。ステップ４ａ、５ａ、６ａ、および７ａは、「Ｒｘ」の場合、すなわち、ＰＣＦ２０２がＡＦ３０１とのＲｘインタフェースをサポートする場合に関するものである。Ｒｘインターフェースの詳細は、3GPP TS 29.214 V15.4.0に記載されている。

【0073】

[0079] ステップ８：これがこの加入者について最後のＰＤＵセッションである場合、3GPP TS 29.594 V15.1.0の5.3.4節に定義されている最終支出限度額報告要求(Final Spending Limit Report Request)が送信される。この加入者についての既存ＰＤＵセッションのいずれかがポリシカウンタのステータス報告を必要とする場合、加入されているポリシカウンタのリストを変更するために、3GPP TS 29.594 V15.1.0の5.3.3節に定義されているような中間支出限度額報告要求(Intermediate Spending Limit Report Request)を送信することができる。

【0074】

[0080] ステップ９：ＰＣＦ２０２は、終了したＰＤＵセッションについてのＰＣＣルールを削除し、ＳＭＦ２０１にＨＴＴＰ「２０４ Ｎｏ Ｃｏｎｔｅｎｔ」応答を送信する。

【0075】

[0081] ステップ１０：ＳＭポリシアソシエーション終了時に、ＰＣＦ２０２は、適用可能な制限について、ＵＤＲ内の残りの使用量を更新する。ＰＣＦ２０２は、対応する「UsageMonData」インスタンスに含まれる「allowedUsage」属性内の残り使用量の更新された値を含んだ、...／sm-dataリソースＵＲＩにＰＡＴＣＨリクエストを送信することができる。ここで、各「UsageMonData」インスタンスは、その「limitId」（例えば、「limitId」：「Facebook-limit」および「allowedUsage」：「125MB」）によって特定される。あるいは、ＰＣＦ２０２は、ＰＣＦ２０２が更新する必要のある「UsageMonData」インスタンスごとに、.../{usageMonId}リソースＵＲＩにＰＵＴリクエストを送信することができる。「UsageMonId」の値は、「limitId」の値である（例えば、Facebookの消費については、.../facebook-limitリソースＵＲＩ、Netflixプレミアムの消費については、.../netflix-premiumリソースＵＲＩなど）。ＵＤＲはlimitIdに関連する残り使用量を（監視鍵を使う代わりに）保存します。

【0076】

[0082] ステップ１１：ＵＤＲ２０４は、ＨＴＴＰ「２０４ Ｎｏ Ｃｏｎｔｅｎｔ」応答をＰＣＦ２０２に送信する。

【0077】

[0083] ステップ１２：ＰＣＦ２０２は、limitIdによって特定されるResource ID .../{usageMonId}に関連する変更を受信するために加入を解除してもよい。ＰＣＦ２０２は、sm-dataリソースで表されるデータの変更通知を受信するために加入を解除してもよいことに留意されたい。.../{usageMonId}で表される使用量監視データの変更の加入を終了するために、ＰＣＦ２０２は、リソースＵＲＩ：{apiRoot}/nudr-dr/v1/policy-data/subs-to-notifyにＰＵＴリクエストを送信してもよい。このＰＵＴリクエストのボディには、「monitoredResourceUris」の更新されたリストを有するPolicyDataSubscriptionデータ構造が含まれ、このリストには、前述の.../{usageMonId}リソースＵＲＩは含まれないであろう。あるいは、ＰＣＦ２０２は、{apiRoot}/nudr-dr/v1/policy-data/subs-to-notifyリソースＵＲＩにＤＥＬＥＴＥリクエストを送信することによって、任意のデータ変更に対する通知の加入を終了してもよい。

【0078】

[0084] ステップ１３ＵＤＲ２０４は、ＨＴＴＰ「２０４ Ｎｏ Ｃｏｎｔｅｎｔ」応答をＰＣＦ２０２に送信する。

【0079】

[0085] 図４は、一実施形態に係る手順４００を説明するフローチャートである。手順４００はステップｓ４０２で開始することができる。

【0080】

[0086] ステップｓ４０２は、ポリシ機能（例えばＰＣＦ２０２）が、管理機能（例えばＳＭＦ２０１）から要求２５１（図２参照）を受信することを有し、この要求はＵＥに関連するものである。すなわち、管理機能は、ポリシ機能が管理機能から（直接または間接的に）要求を受信するように、ポリシ機能に向けて要求２５１を送信した。

【0081】

[0087] ステップｓ４０４は、ポリシ機能がＵＥに関連する情報をデポジトリ機能（例えば、ＵＤＲ２０４）からフェッチする必要があるか否かを、ポリシ機能が判定することを有する。ポリシ機能が情報をフェッチする必要があれば手順４００はステップ４０６に進み、そうでない場合はステップ４１０に進む。

【0082】

[0088] ステップｓ４０６は、ポリシ機能が、情報の要求２５２をデポジトリ機能に送信することを有する。すなわち、例えば、ポリシ機能がソフトウェアで実装されている実施形態では、そのソフトウェアが、自身が稼働しているハードウェアに要求２５２の送信を指示する。

【0083】

[0089] ステップｓ４０８は、ポリシ機能が、要求に対する応答２５４を受信することを有する。応答はデポジトリ機能によって送信され、制限識別子を含むusageMonDataLimitインスタンスと、usageMonDataLimitインスタンスに対応するusageMonDataインスタンスとを有する。usageMonDataインスタンスもまた制限識別子を有する。ポリシ機能が（直接的または間接的に）デポジトリ機能から応答を受信すると、ポリシ機能は、応答がＵＥについてのUsageMonDataLimitインスタンスを含んでいるか否かを検出する。ＵＥについてのUsageMonDataLimitが存在することをポリシ機能が検出した場合、ポリシ機能はステップｓ４０９を実行する。

【0084】

[0090] ステップｓ４０９は、ポリシ機能が、UsageMonDataLimitインスタンスに関連付けられたUsageMonDataインスタンスに変更が生じたときに通知を提供することの要求２５６を、デポジトリ機能に送信することを有する。

【0085】

[0091] ステップｓ４１０は、ポリシ機能が応答２６０を管理機能に送信することを有する。

【0086】

[0092] ステップｓ４１２は、ポリシ機能が、管理機能から、ＳＭ関連ポリシのコンテキストの削除の要求３０２を（直接または間接的に）受信することを有する。

【0087】

[0093] ステップｓ４１４は、ポリシ機能が、更新要求３０４をデポジトリ機能に送信することを有する（例えば、図３のステップ１０に関して上述したようなＨＴＴＰ ＰＡＴＣＨまたはＰＵＴ）。

【0088】

[0094] ステップｓ４１６は、ポリシ機能が、図３のステップ１２に関して上述したように、加入解除要求３０６をデポジトリ機能に送信することを有する。

【0089】

[0095] 図５は、一実施形態に係る手順５００を説明するフローチャートである。手順５００はステップｓ５０２で開始することができる。

【0090】

[0096] ステップｓ５０２は、デポジトリ機能（例えばＵＤＲ２０４）が、ポリシ機能（例えばＰＣＦ２０２）から情報に対する要求２５２を受信することを有する。

【0091】

[0097] ステップｓ５０４は、デポジトリ機能が、要求２５２に応じて応答２５４を送信することを有する。応答は、制限識別子を有するusageMonDataLimitインスタンスと、usageMonDataLimitインスタンスに対応するusageMonDataインスタンスとを有し、usageMonDataインスタンスもまた制限識別子を有する。

【0092】

[0098] ステップｓ５０６は、デポジトリ機能が、ポリシ機能から更新要求３０４（例えば、図３のステップ１０に関して上述したようなＨＴＴＰ ＰＡＴＣＨまたはＰＵＴ）を受信することを有する。

【0093】

[0099] ステップｓ５０８は、図３のステップ１２に関して上述したように、デポジトリ機能がポリシ機能から加入解除要求３０６を受信することを有する。

【0094】

[00100] 図６は、いくつかの実施形態に係る、ＰＣＦ２０２またはＵＤＲ２０４を実装するための装置６０１のブロック図である。例えば、ＰＣＦ２０２および／またはＵＤＲ２０４がソフトウェア（例えば、スクリプトおよび／またはコンパイルされたコード）から成る実施形態において、装置６０１は、ＰＣＦ／ＵＤＲソフトウェアを実行することができる。したがって、装置６０１は、装置６０１がＰＣＦソフトウェアを実行する実施形態において、ポリシ機能装置と呼ばれうる。同様に、装置６０１は、装置６０１がＵＤＲソフトウェアを実行する実施形態において、デポジトリ機能装置と呼ばれうる。図６に示すように、装置６０１は、処理回路(PC)６０２を有してもよい。処理回路６０２は、１つ以上のプロセッサ(P)６５５（例えば、１つ以上の汎用マイクロプロセッサおよび／または、ＡＳＩＣ(Application Specific Integrated Circuit)、ＦＰＧＡ(Field-Programmable Gate Array)などの１つ以上の他のプロセッサ）を含みうる。これらのプロセッサは、単一のハウジングまたは単一のデータセンターに配置されてもよいし、地理的に分散していてもよい。装置６０１はまた、ネットワークインタフェース６４８を有してもよい。ネットワークインタフェース６４８は、ネットワークインタフェース６４８が接続されているネットワーク１１０（例えばインターネットプロトコル(IP)ネットワーク）に接続されている他のノードと、装置６０１がデータを送受信することを可能にするための送信器(Tx)６４５および受信器(Rx)６４７を有する。装置６０１はまた、「データストレージシステム」とも呼ばれるローカルストレージユニット６０８を有してもよい。ローカスストレージユニット６０８は、１つ以上の不揮発性記憶装置および／または１つ以上の揮発性記憶装置を含むことができる。ＰＣ６０２がプログラマブルプロセッサを含んだ実施形態では、コンピュータプログラム製品(CPP)６４１が提供されてもよい。ＣＰＰ６４１は、コンピュータ可読命令(CRI)６４４を有するコンピュータプログラム(CP)６４３を格納するコンピュータ可読媒体(CRM)６４２を含む。ＣＲＭ６４２は、磁気媒体（例えば、ハードディスク）、光学媒体、メモリデバイス（例えば、ランダムアクセスメモリ、フラッシュメモリ）などの恒久的(non-transitory)なコンピュータ可読媒体であってよい。いくつかの実施形態において、コンピュータプログラム６４３のＣＲＩ６４４は、ＰＣ６０２によって実行されると、ＣＲＩが装置６０２に本明細書に記載されたステップ（例えば、フローチャートに関して本明細書で説明したステップ）を実行させるように構成される。他の実施形態において、装置６０１は、コードを必要とせずに本明細書に記載されたステップを実行するように構成されてもよい。すなわち、例えば、ＰＣ６０２は、１つ以上のＡＳＩＣだけで構成されてもよい。したがって、本明細書で説明した実施形態の機能は、ハードウェアおよび／またはソフトウェアによって実装されうる。

【0095】

[00101] 実施態様
[00102] Ａ１．方法（４００）であって、ポリシ機能（例えばＰＣＦ２０２）が、情報に対する要求（２５２）をデポジトリ機能（例えばＵＤＲ２０４）に送信する（ｓ４０６）することと、ここでデポジトリ機能は、要求に応じて応答（２５４）を送信するように構成されており、ポリシ機能が、応答を受信する（ｓ４０８）ことと、を有し、応答は、制限識別子を有するusageMonDataLimitインスタンスと、usageMonDataLimitインスタンスに対応するusageMonDataインスタンスを有し、usageMonDataインスタンスもまた制限識別子を有する、方法。

【0096】

[00103] Ａ２．実施態様Ａ１の方法であって、要求（２５２）を送信する前に、ポリシ機能が、管理機能（例えばＳＭＦ）によって送信された要求（２５１）を受信することと、ポリシ機能がデポジトリ機能から情報をフェッチすることが必要か否かを、ポリシ機能が判定する（ｓ４０４）ことと、をさらに有する、方法。

【0097】

[00104] Ｂ１．方法であって、デポジトリ機能（例えばＵＤＲ２０４）が、ポリシ機能（例えばＰＣＦ２０２）によって送信された、情報の要求を受信することと、デポジトリ機能が、要求に応じて応答を送信することとを有し、応答が、制限識別子を有するusageMonDataLimitインスタンスと、usageMonDataLimitインスタンスに対応するusageMonDataインスタンスとを有し、usageMonDataインスタンスもまた制限識別子を有する、方法。

【0098】

[00105] Ｂ２．実施態様Ｂ１の方法であって、デポジトリ機能が、ポリシ機能によって送信された更新要求（３０４）を受信する（ｓ５０６）ことをさらに有する、方法。

【0099】

[00106] Ｂ３．実施態様Ｂ２の方法であって、更新要求が、制限識別子を有するUsageMonDataインスタンスを有するＨＴＴＰ ＰＡＴＣＨリクエストである、方法。

【0100】

[00107] Ｂ４．実施態様Ｂ２の方法であって、更新要求が、制限識別子を有するリソース識別子（例えばＵＲＩ）を有するＨＴＴＰ ＰＵＴリクエストである、方法。

【0101】

[00108] Ｂ５．実施態様Ｂ１からＢ４のいずれか１つの方法であって、デポジトリ機能が、ポリシ機能によって送信された加入解除要求（３０６）を受信する（ｓ５０８）ことをさらに有する、方法。

【0102】

[00109] Ｂ６．実施態様Ｂ５の方法であって、加入解除要求は、制限識別子を有するリソース識別子を有するボディを有するＨＴＴＰ ＰＵＴリクエストである、方法。

【0103】

[00110] Ｃ１．装置（６０１）であって、デポジトリ機能（例えばＵＤＲ２０４）に、情報に対する要求（２５２）を送信（ｓ４０６）し、ここで、ＵＤＲ２０４は、要求に応じて応答（２５４）を送信するように構成されており、応答を受信（ｓ４０８）する、ように適合され、応答は、制限識別子を有するusageMonDataLimitインスタンスと、usageMonDataLimitインスタンスに対応するusageMonDataインスタンスとを有し、usageMonDataインスタンスもまた制限識別子を有する、装置。

【0104】

[00111] Ｃ２．実施態様Ａ１の装置であって、要求（２５２）を送信する前、管理機能によって送信された要求（２５１）を受信した後に、デポジトリ機能から情報をフェッチする必要があるか否かを判定する（ｓ４０４）ようにさらに適合された、装置。

【0105】

[00112] Ｄ１．装置（６０１）であって、ポリシ機能（例えばＰＣＦ２０２）によって送信された、情報に対する要求を受信し、要求に応じて応答を送信する、ように適合され、応答が、制限識別子を有するusageMonDataLimitインスタンスと、usageMonDataLimitインスタンスに対応するusageMonDataインスタンスとを有し、usageMonDataインスタンスもまた制限識別子を有する、装置。

【0106】

[00113] Ｄ２．実施態様Ｄ１の装置であって、実施態様Ｂ２からＢ６のいずれか１つの方法を実行するようにさらに適合された、装置。

【0107】

[00114] 以下に、本明細書で提案したTS 29.519に対する変更を説明する。
[00115] 第１の変更
[00116] 5.2.6.2リソース定義
[00117] リソースＵＲＩ：{apiRoot}/nudr-dr/v1/policy-data/{ueId}/sm-data/{usageMonId}

【0108】

[00118] 本リソースは、以下の表に定義されるリソースＵＲＩ変数をサポートしなければならない。

【表5】

【0109】

[00119] 第２の変更
[00120] 5.2.6.3.3GET
[00121] 本メソッドは、以下の表に規定されるＵＲＩクエリパラメータをサポートしなければならない。

【表6】

【0110】

[00122] 本明細書では様々な実施形態が説明されているが、それらは例示のみを目的として提示されたものであって、限定ではないことを理解すべきである。したがって、本開示の広さおよび範囲は、上述した例示的な実施形態のいずれによっても限定されるべきではない。さらに、本明細書で別段の記載がない限り、あるいは文脈上明らかに矛盾しない限り、上述した要素のあらゆる可能な変形物の組み合わせが本開示に包含される。

【0111】

[00123] さらに、上述し、また図面に示された手順は、一連のステップとして示されているが、これは単に説明を目的としたものである。したがって、いくつかのステップが追加され、いくつかのステップが省略され、ステップの順序が再配置され、いくつかのステップが並行して実行されてもよいことが想定されている。また、「～から受信する」という表現は、「～から直接受信する」または「～から間接的に受信する」を包含するものとして解すべきである。つまり、第２のエンティティが送信したメッセージを第３のエンティティが受信し、第３のエンティティがそのメッセージを第１のエンティティに転送する場合であっても、第１のエンティティは第２のエンティティからメッセージを受信する。

【0112】

[00124] 略語
[00125] ＡＦ アプリケーション機能
[00126] ＡＭＢＲ 集約最大ビットレート
[00127] ＡＰＮ アクセスポイント名
[00128] ＡＲＰ 割り当ておよび保持優先度
[00129] ＡＳＡ アボートセッションアンサー
[00130] ＡＳＲ アボートセッションリクエスト
[00131] ＣＨＦ 課金機能
[00132] ＤＮＮ データネットワーク名
[00133] ＨＴＴＰ ハイパーテキスト転送プロトコル
[00134] ＩＰ－ＣＡＮ ＩＰ接続可能なアクセスネットワーク
[00135] ＧＰＳＩ 汎用公衆加入識別子
[00136] Ｈ－ＰＣＦ ホームポリシ制御機能
[00137] ＰＣＣ ポリシおよび課金制御
[00138] ＰＣＦ ポリシ制御機能
[00139] ＰＣＲＦ ポリシおよび課金ルール機能
[00140] ＰＤＵ プロトコルデータユニット
[00141] ＰＥＩ 恒久機器識別子
[00142] ＰＧＷ パケットデータネットワークゲートウェイ
[00143] ＲＡＴ 無線アクセス技術
[00144] ＳＭ ショートメッセージ(?)
[00145] ＳＭＦ セッション管理機能
[00146] ＳＰＲ 加入プロファイルリポジトリ
[00147] ＳＴＡ セッション終了応答
[00148] ＳＴＲ セッション終了リクエスト
[00149] ＳＵＰＩ 加入恒久識別子
[00150] Ｓ－ＮＳＳＡＩ 単一ネットワークスライス選択支援情報
[00151] ＵＤＲ 統合データリポジトリ
[00152] ＵＰ ユーザプレーン
[00153] ＵＰＦ ユーザプレーン機能
[00154] Ｖ－ＰＣＦ 移動先ポリシ制御機能
[00155] ５ＱＩ ５Ｇサービス品質(QoS)識別子

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】