特許 7599507 ５Ｇサービスのためのルールベースの過負荷制御のための方法、システム、およびコンピュータ可読媒体

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

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

(11)【特許番号】

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

(45)【発行日】2024-12-13

(54)【発明の名称】５Ｇサービスのためのルールベースの過負荷制御のための方法、システム、およびコンピュータ可読媒体

(51)【国際特許分類】

   H04W 28/02 20090101AFI20241206BHJP

   H04W 72/53 20230101ALI20241206BHJP

   H04W 88/18 20090101ALI20241206BHJP

【ＦＩ】

H04W28/02

H04W72/53

H04W88/18

【請求項の数】 11

(21)【出願番号】P 2022576542

(86)(22)【出願日】2021-02-26

(65)【公表番号】

(43)【公表日】2023-07-25

(86)【国際出願番号】 US2021020115

(87)【国際公開番号】W WO2021262261

(87)【国際公開日】2021-12-30

【審査請求日】2023-09-12

(31)【優先権主張番号】16/914,231

(32)【優先日】2020-06-26

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

(73)【特許権者】

【識別番号】502303739

【氏名又は名称】オラクル・インターナショナル・コーポレイション

(74)【代理人】

【識別番号】110001195

【氏名又は名称】弁理士法人深見特許事務所

(72)【発明者】

【氏名】クリシャン，ラジブ

(72)【発明者】

【氏名】ヤーダブ，ラジディープ

【審査官】山中 実

(56)【参考文献】

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

【文献】国際公開第２０２０／０９１９３４（ＷＯ，Ａ１）

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

【文献】3GPP TSG CT WG4，Presentation of Specification/Report to TSG: 3GPP TR 29.843 v2.1.0 on Study on Load and Overload Control of 5GC Service Based Interfaces[online]，3GPP TSG CT #85 CP-192241，Internet<URL:https://www.3gpp.org/ftp/tsg_ct/TSG_CT/TSGC_85_Newport_Beach/Docs/CP-192241.zip>，2019年09月16日

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

Ｈ０４Ｗ ２８／０２

Ｈ０４Ｗ ７２／５３

Ｈ０４Ｗ ８８／１８

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

【請求項1】

５Ｇサービスのためのルールベースの過負荷制御のための方法であって、
中間ノードまたはプロデューサネットワーク機能（ＮＦ）において、過負荷メッセージ処理ルールを構成することを含み、前記過負荷メッセージ処理ルールのうちの少なくともいくつかは、宛先ネットワーク名（ＤＮＮ）またはネットワークスライス、サブスクリプションもしくはロケーション識別パラメータをルール選択基準として含み、前記方法はさらに、
前記中間ノードまたはプロデューサＮＦにおいて、前記中間ノードまたはプロデューサＮＦの保証された処理帯域幅を、前記過負荷メッセージ処理ルールの少なくともいくつかと関連付けることと、
前記中間ノードまたはプロデューサＮＦにおいて第１のメッセージを受信することと、
前記中間ノードまたはプロデューサＮＦが、過負荷状態が存在すると判断することと、
前記中間ノードまたはプロデューサＮＦが、前記第１のメッセージは、前記過負荷メッセージ処理ルールのうちの１つについて前記ルール選択基準に合致するパラメータを含む旨を識別することと、
前記中間ノードまたはプロデューサＮＦが、当該合致する過負荷メッセージ処理ルールについての前記中間ノードまたはプロデューサＮＦの前記保証された処理帯域幅の一部が、前記第１のメッセージを処理するために利用可能である、と判断することと、
前記中間ノードまたはプロデューサＮＦが、前記合致する過負荷メッセージ処理ルールについての前記中間ノードまたはプロデューサＮＦの前記保証された処理帯域幅の一部を使用して、前記第１のメッセージを処理することとを含む、方法。

【請求項2】

前記過負荷メッセージ処理ルールを構成することは、前記ＤＮＮまたはネットワークスライス、サブスクリプション、もしくはロケーション識別パラメータに基づいて、同じサービスタイプのメッセージを異なるように扱うルールを構成することを含む、請求項１に記載の方法。

【請求項3】

前記過負荷メッセージ処理ルールを構成することは、定義されたパラメータまたはパラメータの組合せに基づいて、同じサービスタイプのメッセージを異なるように扱うルールを構成することを含む、請求項１に記載の方法。

【請求項4】

前記中間ノードまたはプロデューサＮＦの保証された処理帯域幅を前記過負荷メッセージ処理ルールの少なくともいくつかと関連付けることは、前記過負荷メッセージ処理ルールの少なくともいくつかをバケットと関連付けることと、各ルールについて保証される帯域幅に対応するメッセージカウントを各ルールの対応するバケットとともに構成することとを含む、請求項１～３のいずれか１項に記載の方法。

【請求項5】

応答メッセージから取得された情報を使用して動的過負荷メッセージ処理ルールを作成することと、共通セッションに関連するメッセージが前記中間ノードまたはプロデューサＮＦの共通プロセッサによって処理されることを確実にするために前記動的過負荷メッセージ処理ルールを使用することとを含む、請求項１～４のいずれか１項に記載の方法。

【請求項6】

前記中間ノードまたはプロデューサＮＦは、セキュリティエッジ保護プロキシ（ＳＥＰＰ）、サービス通信プロキシ（ＳＣＰ）、またはサービスメッシュノードを備える、請求項１～５のいずれか１項に記載の方法。

【請求項7】

前記中間ノードまたはプロデューサＮＦはプロデューサＮＦを含む、請求項１～６のいずれか１項に記載の方法。

【請求項8】

前記中間ノードまたはプロデューサＮＦにおいて、前記中間ノードまたはプロデューサＮＦの保証された帯域幅が構成される前記過負荷メッセージ処理ルールのうちの１つに合致しないメッセージに利用可能な前記中間ノードまたはプロデューサＮＦの帯域幅を追跡するために使用可能な保証されない帯域幅バケットを構成することを含む、請求項１～７のいずれか１項に記載の方法。

【請求項9】

前記中間ノードまたはプロデューサＮＦにおいて第２のメッセージを受信することと、
前記第２のメッセージは、前記中間ノードまたはプロデューサＮＦの保証された帯域幅が構成される前記過負荷メッセージ処理ルールのうちの１つに合致しない、と判断することと、
前記保証されない帯域幅バケットを使用して、保証されない帯域幅が前記第２のメッセージに利用可能である、と判断することと、
前記保証されない帯域幅を使用して前記メッセージを処理することとを含む、請求項８に記載の方法。

【請求項10】

５Ｇサービスのためのルールベースの過負荷制御のためのシステムであって、
少なくとも１つのプロセッサを含む中間ノードまたはプロデューサネットワーク機能（ＮＦ）と、
前記中間ノードまたはプロデューサＮＦに関連付けられ、過負荷状態中にメッセージの処理を管理するために前記中間ノードまたはプロデューサＮＦによって使用される過負荷メッセージ処理ルールであって、前記過負荷メッセージ処理ルールのうちの少なくともいくつかは、宛先ネットワーク名（ＤＮＮ）またはネットワークスライス、サブスクリプションもしくはロケーション識別パラメータをルール選択基準として含むルールを構成すること、および保証された帯域幅サービスを、前記過負荷メッセージ処理ルールの少なくともいくつかと関連付けることに備えるための過負荷制御構成インターフェイスと、
前記中間ノードまたはプロデューサＮＦによって実現され、第１のメッセージを受信すること、過負荷状態が存在する、と判断すること、前記第１のメッセージは、前記過負荷メッセージ処理ルールのうちの１つについて前記ルール選択基準に合致するパラメータを含む旨を識別すること、合致する過負荷メッセージ処理ルールについての前記保証された帯域幅サービスの一部が、前記第１のメッセージを処理するために利用可能である、と判断すること、および、前記中間ノードまたはプロデューサＮＦによるさらなる処理のために前記第１のメッセージを転送することのための過負荷コントローラとを備える、システム。

【請求項11】

請求項１～９のいずれか１項に記載の方法をプロセッサに実行させるためのコンピュータ可読プログラム。

【発明の詳細な説明】

【技術分野】

【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】

【図1】例示的な５Ｇネットワークアーキテクチャを示すネットワーク図である。

【図2】サービスメッシュなどの中間プロキシノードを介して接続される５Ｇネットワーク機能を示す図である。

【図3】５Ｇネットワーク機能間の中間プロキシノードで発生し得る潜在的な輻輳を示すネットワーク図である。

【図4】５Ｇルールベースの過負荷制御を実現するネットワーク機能を示すブロック図である。

【図5】５Ｇルールベースの過負荷制御を実現するための例示的なデータ構造を示す図である。

【図6】５Ｇルールベースの過負荷制御のための例示的なプロセスを示すフローチャートである。

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

【0034】

詳細な説明
本明細書で説明する主題は、５Ｇサービスのためのルールベースの過負荷制御のための方法、システム、およびコンピュータ可読媒体に関する。図１は、例示的な５Ｇシステムネットワークアーキテクチャを示すブロック図である。図１のアーキテクチャは、同じホーム公衆陸上移動体通信網（ＨＰＬＭＮ：Home Public Land Mobile Network）に位置し得るＮＲＦ１００およびＳＣＰ１０１を含む。前述したように、ＮＲＦ１００は、利用可能なプロデューサＮＦサービスインスタンスのプロファイルおよびそれらのサポートされたサービスを維持し、コンシューマＮＦまたはＳＣＰが新規の／更新されたプロデューサＮＦサービスインスタンスに加入し、その登録を通知されるようにし得る。ＳＣＰ１０１はまた、プロデューサＮＦのサービス発見および選択をサポートし得る。加えて、ＳＣＰ１０１は、コンシューマＮＦとプロデューサＮＦとの間の接続の負荷分散を実行し得る。

【0035】

ＮＲＦ１００は、ＮＦプロファイルのリポジトリである。プロデューサＮＦと通信するために、コンシューマＮＦまたはＳＣＰは、ＮＲＦ１００からＮＦプロファイルを取得しなければならない。ＮＦプロファイルは、３ＧＰＰ ＴＳ２９．５１０で定義されるJavaScriptオブジェクト表記（ＪＳＯＮ）データ構造である。ＮＦプロファイル定義は、完全修飾ドメイン名（ＦＱＤＮ）、インターネットプロトコル（ＩＰ）バージョン４（ＩＰｖ４）アドレス、またはＩＰバージョン６（ＩＰｖ６）アドレスのうちの少なくとも１つを含む。

【0036】

図１では、（ＳＣＰ１０１およびＮＲＦ１００以外の）いずれのノードも、それらがサービスを要求しているか提供しているかに応じて、コンシューマＮＦまたはプロデューサＮＦとなり得る。図示した例では、ノードは、ネットワーク内でポリシー関連動作を実行するポリシー制御機能（ＰＣＦ）１０２と、ユーザデータを管理するユーザデータ管理（ＵＤＭ）機能１０４と、アプリケーションサービスを提供するアプリケーション機能（ＡＦ）１０６とを含む。図１に示すノードは、アクセスおよびモビリティ管理機能（ＡＭＦ）１１０とＰＣＦ１０２との間のセッションを管理するセッション管理機能（ＳＭＦ）１０８をさらに含む。ＡＭＦ１１０は、４Ｇネットワークにおいてモビリティ管理エンティティ（ＭＭＥ）によって実行されるモビリティ管理動作と同様の動作を実行する。認証サーバ機能（ＡＵＳＦ）１１２は、ＵＥ１１４のようにネットワークへのアクセスを求めるユーザ機器（ＵＥ）のための認証サービスを実行する。

【0037】

ネットワークスライス選択機能（ＮＳＳＦ）１１６は、ネットワークスライスに関連付けられる特定のネットワーク機能および特性にアクセスしようとするデバイスのためにネットワークスライスサービスを提供する。ネットワーク公開機能（ＮＥＦ）１１８は、モノのインターネット（ＩｏＴ）デバイスおよびネットワークに接続された他のＵＥに関する情報を取得しようとするアプリケーション機能のためにアプリケーションプログラミングインターフェイス（ＡＰＩ）を提供する。ＮＥＦ１１８は、４Ｇネットワークにおけるサービス機能公開機能（ＳＣＥＦ）と同様の機能を実行する。

【0038】

無線アクセスネットワーク（ＲＡＮ）１２０は、無線リンクを介してＵＥ１１４をネットワークに接続する。無線アクセスネットワーク１２０は、ｇノードＢ（ｇＮＢ）（図１には示さず）または他の無線アクセスポイントを用いてアクセスされてもよい。ユーザプレーン機能（ＵＰＦ）１２２は、ユーザプレーンサービスのための様々なプロキシ機能をサポート可能である。そのようなプロキシ機能の一例は、マルチパス送信制御プロトコル（ＭＰＴＣＰ）プロキシ機能である。ＵＰＦ１２２はまた、ネットワーク性能測定値を取得するためにＵＥ１１４によって用いられ得る性能測定機能もサポートし得る。また、図１には、インターネットサービスなどのデータネットワークサービスにＵＥがアクセスするデータネットワーク（ＤＮ）１２４も示されている。

【0039】

ＳＥＰＰ１２６は、別のＰＬＭＮからの着信トラフィックをフィルタリングし、ホームＰＬＭＮを出るトラフィックのためにトポロジー隠蔽を実行する。ＳＥＰＰ１２６は、外部ＰＬＭＮのセキュリティを管理する、外部ＰＬＭＮ内のＳＥＰＰと通信することができる。したがって、異なるＰＬＭＮ内のＮＦ間のトラフィックは、一方はホームＰＬＭＮ用であり、他方は外部ＰＬＭＮ用である、２つのＳＥＰＰ機能を横断し得る。上述のように、ＳＥＰＰは、適切な輻輳制御および／または帯域幅確保手順が中間プロキシノードにおいて実現されない場合に圧倒され得る中間プロキシノードの例である。

【0040】

過負荷メッセージ処理ルールに合致するメッセージのための保証されたトラフィック帯域幅
５Ｇ展開アーキテクチャでは、３ＧＰＰリリース１５および１６は、クライアント／コンシューマＮＦとサーバ／プロデューサＮＦとの間にあるＳＣＰまたはＳＥＰＰなどのプロキシノードを推奨する。ＳＣＰなどのプロキシノードは、Ｎ個のコンシューマＮＦとＭ個のプロデューサＮＦとの間のトランスポートおよびルーティング機能を提供し、ここでＮおよびＭは整数である。同様に、ネットワークオペレータは、それ自体のサービスメッシュ／中間ゲートウェイ／コントローラノードを５Ｇ ＮＦ間に展開することができる。サービスメッシュ／中間ゲートウェイ／プロキシノードは、例えば、監視、過負荷制御、トラフィック管理、サービス発見などの様々なサービスの間で大抵の共通のアクティビティを実行するのに役立つ。５Ｇでは、各プロデューサＮＦは、その負荷レベルをＮＲＦに公開することができる。コンシューマＮＦは、そのような変更について登録し、それらのトラフィックレートを調整するために反応的であることができる。

【0041】

既存の３ＧＰＰネットワークアーキテクチャに関する１つの問題は、コンシューマＮＦとプロデューサＮＦとの間のすべてのノードが、それら自体を５Ｇ ＮＦとして登録できるわけではないことである。登録できないこれらのノードは、同じベンダのサイト間の中間プロキシ、サービスゲートウェイなどを含む。中間プロキシノードは、５Ｇ ＮＦとしてＮＲＦに登録することができないので、コンシューマノードは、中間プロキシノード上の負荷を知らないことがあり、中間プロキシノードを圧倒することがある。同様に、ＮＲＦは、コンシューマがターゲットプロデューサノードの負荷を見ることを可能にする通知をサービスコンシューマに提供する。しかしながら、中間プロキシノードはサービスプロデューサとして登録することができないので、そのような通知に応答することまたはそのような通知の発行について中間プロキシノード上での挙動を定義するための、３ＧＰＰからのガイドラインはない。

【0042】

たとえオペレータがそれの中間プロキシノードの容量を計画しても、不正サービス／ＮＦからの信号送信ストームは、中間ネットワーク／ノード／ルートを過負荷にする可能性がある。したがって、サービスメッシュ（またはＳＣＰ／ＳＥＰＰなどの中間プロキシ）では、所与のＮＦサービスメッセージングのために、保証されたトラフィック帯域幅を保証するポリシーを設定する必要がある。本明細書で説明される主題は、中間プロキシノードの輻輳／過負荷状態中における複数のサービスの保証されたサービス性のための、サービスメッシュ／ＳＣＰ／ＳＥＰＰ／中間ゲートウェイなどにおける強化を含む。本明細書で説明される主題はまた、プロデューサＮＦによるルールベースの過負荷制御に備える、プロデューサＮＦにおける拡張を含む。したがって、以下の説明では、「中間またはプロデューサＮＦ」という文言は、本明細書で説明するルールベースの過負荷制御が実現される、ＳＣＰ、ＳＥＰＰ、もしくはサービスメッシュなどの中間ノード、またはプロデューサＮＦを指すために使用される。

【0043】

共有または専用ネットワークにかかわらず、中間プロキシノードは、オペレータ指定の過負荷メッセージ処理ルールに合致するメッセージのために、保証されたサービス性を確実にする方法を必要とする。保証されたサービス性がないと、２つのノード間のメッセージングは、サービスメッシュ／中間プロキシノードの容量を超過する可能性があり、したがって、中間プロキシノードの機能および他のサービスに影響を及ぼし得る。

【0044】

図２は、エンドノード間のトラフィックが、サービスメッシュなどの中間ＮＦをどのように圧倒し得るかを示す。図２では、ＡＭＦ１１０は、サービスメッシュ２０２を介して、ＵＤＭ１０４および別のＮＦ２００に接続される。ＡＭＦ２００は、サービスＳｖｃ－Ｘを提供する。ＵＤＭ１０４は、サービスＳｖｃ－Ｙを提供する。ＮＦ２００は、サービスＳｖｃ－Ｚを提供する。Ｓｖｃ－ＸとＳｖｃ－Ｙとの間のメッセージングは、（データストームまたは他のそのようなシナリオ中に）中間プロキシノード２０２の容量を使い果たすかもしれない。その結果、Ｓｖｃ－Ｘ→Ｓｖｃ－ＺおよびＳｖｃ－Ｙ→Ｓｖｃ－Ｚサービスが悪影響を受けるかもしれない。

【0045】

５Ｇは、所与のサービス内でメッセージに使用されるべきメッセージ優先度に関してのガイダンスを提供しない。３ＧＰＰ ＴＳ ２９．５００に従って、クライアントによって定義される優先度のないすべてのメッセージは、２４のデフォルト優先度を有するものとする。また、ベンダ／オペレータは、サービスメッセージごとに優先度を駆動／割り当てることは極めて困難であり、これは、他のＮＦの他のサービスと比較して、その優先度をかなり正当化することができる。

【0046】

同時に、データストーム／過負荷状態中の中間プロキシノードの安定性を保証するために、オペレータは、システム容量がある点を超えると、低優先度メッセージを拒否するスロットリングポリシーを設定する。

【0047】

以下は、システム容量がある点を超えたときに中間プロキシノードにおいて実現されてもよいポリシーの例である。

【0048】

Ｉ．システム計算リソースの利用が６０％を超える場合、優先度≧１５のすべてのメッセージを拒否する。

【0049】

ＩＩ．システムコンピューティングリソースの利用が８０％を超える場合、優先度≧７のすべてのメッセージを拒否する。

【0050】

そのようなポリシーは有用であり得るが、それらは、輻輳イベント中に低優先度メッセージ／トラフィックを有するサービスに何が起こるかを考慮に入れない。

【0051】

輻輳状況においてすべてのより低い優先度のメッセージが拒否されるときに生じる別の問題は、所与のサービスのすべてのメッセージがより低い優先度である場合、優先度ベースの閾値が所与のサービスを途絶えさせ得ることである。例えば、図２において、サービスＳｖｃ－Ｚのすべてのメッセージがデフォルト優先度を有し、中間プロキシノードが過負荷になる場合、サービスＳｖｃ－Ｚについてのすべてのメッセージは拒否されることになり、サービスＳｖｃ－Ｚがネットワークにおいて提供されることを妨げる。

【0052】

５Ｇ展開では、ＮＦ（ネットワーク機能）とサービスとの間の多対多マッピングの可能性があり、すなわち、ある所与のＮＦは複数のサービスを提供する場合があり、あるサービスは複数のＮＦインスタンスによって提供される場合がある。

【0053】

図３は、複数のプロデューサＮＦが複数のコンシューマＮＦにサービスを提供する例を示すネットワーク図である。図示の例では、コンシューマＮＦまたはＡＭＦ１１０ａ～１１０ｃである。プロデューサＮＦは、ＵＤＭ１０４およびＮＦインスタンス２００である。プロデューサＮＦおよびコンシューマＮＦは、中間プロキシノード２０２を介して接続される。一例では、１０個のＡＭＦインスタンスおよび１０個のＵＤＭインスタンスが動作していると仮定することができる。各ＵＤＭインスタンスは、１０Ｋｂｐｓのトラフィックを処理することが可能であり得る。しかしながら、サービスＳｖｃ－Ｘを実行する複数のＡＭＦインスタンスは、中間プロキシノード２０２を、ＵＤＭ１０４の各インスタンスによって提供またはホストされるサービスＳｖｃ－Ｙに向かうメッセージングで氾濫させ得る。加えて、中間プロキシノード２０２は、Ｓｖｃ－ＸおよびＳｖｃ－Ｙに関連するメッセージを拒否することによってサービスＳｖｃ－Ｚについてのメッセージングが提供されることができることを保証するためのポリシーを必要とし得る。サービスＳｖｃ－Ｚについてのメッセージは、任意の優先度を有し得るが、サービスＳｖｃ－Ｚメッセージが他のサービスに関連するメッセージングよりも低い優先度を有する場合であっても、サービスＳｖｃ－Ｚについての完全なサービス拒否は、あるべきではない。

【0054】

５Ｇ展開では、ＨＴＴＰ接続はオンデマンドである。したがって、ＡＭＦインスタンス１のＳｖｃ－Ｘは、中間プロキシノードとの複数の接続をインスタンス化して、複数の接続上でトラフィックを分散することができることが考えられる。たとえば、ＡＭＦインスタンス１のＳＶＣ－ＸとＳＣＰ／ＳＥＰＰノードとの間に１０個の接続があり得る。したがって、所与のＳｖｃ－Ｘインスタンスによって生じる全体的なトラフィック（Ｓｖｃ－Ｙについては１０Ｋであり、Ｓｖｃ－Ｚについては１Ｋ）は、１０個の接続にわたって広がることになり、すなわち、各接続は１．１Ｋのみを処理する。

【0055】

したがって、ソースサービスに基づいて、または接続ごとに入来制御を実行することは、サービスの入来トラフィックのために、複数の、およびさらにはオンデマンド接続があるため、サービスメッシュを実現するネットワークにとっては実行可能なオプションではない。

【0056】

同様に、中間プロキシノードは、ＵＤＭの各インスタンスと１０個の接続を有し得、ＵＤＭの１０個の異なるインスタンスに接続され得る。したがって、ターゲットノードに基づいて、または接続ごとに出口制御を実行することは、サービスメッシュまたは中間ＮＦについては実行可能なオプションではない。

【0057】

中間プロキシノードにおける問題に加えて、プロデューサＮＦおよびプロデューサＮＦによって実現されるサービスは、メッセージングおよび／またはプロデューサＮＦが、過負荷メッセージ処理ルールに合致するメッセージのために保証された帯域幅を提供するように適切に構成されていない場合、過負荷イベント中にコンシューマＮＦにサービスの妨害を経験させ得る。概して、過負荷イベント中は、ノード安定性および機能処理を保証するために、ノードのローカルポリシーに基づいてメッセージをドロップする破棄ポリシーがあることになる。一般に、破棄ポリシーはメッセージ優先度に基づき、例えば、負荷レベルがＹである場合、破棄メッセージは優先度＜Ｘである。この概念は、コンシューマまたは発信者が、メッセージをプロデューサまたはエンドアプリケーションに送信するときに正しいまたは適切なメッセージ優先度を選択したという事実に基づく。

【0058】

５Ｇアーキテクチャの場合、３ＧＰＰ ＴＳ２９．５００は、５Ｇサービスメッセージ優先度を搬送する3gpp-Sbi-Message-Priorityヘッダを記述する。ＴＳ２９．５００によれば、０が最も高い優先度である。ただし、3gpp-Sbi-Message-Priorityパラメータの値の設定は、コンシューマＮＦの実現詳細として残される。

【0059】

５Ｇネットワークにおける以下のユースケースは、メッセージ優先度のみに基づいて破棄ポリシーを設定することを（不可能ではないにしても）非常に困難にする。例えば、同じタイプのサービスに基づくインターフェイス（ＳＢＩ）メッセージが異なるＤＮＮ、ネットワークスライス、加入者識別情報（ＳＵＰＩ）、ロケーションなどに関する情報を含むとき（そして、このリストが長く、追加のモデルが、垂直アプリケーション層、すなわち、５Ｇのためのサービス有効化アーキテクチャ層（ＳＥＡＬ）または車両対あらゆるモノ（Ｖ２Ｘ）サポートのために有効化されるとき）。異なるＤＮＮ、スライスなどは、解決するべき異なるユースケースを有するので、所与のユースケースに関連するメッセージを保護するためには、コンシューマＮＦは、ＱｏＳを保証するために異なるメッセージ優先度を使用しなければならない。したがって、コンシューマＮＦは、所与のサービスインターフェイス上ですべての同様のメッセージタイプに優先度「Ｘ」を割り当てるようフラットなポリシーを使用することはできない。

【0060】

例えば、ＳＭＦがSmPolicy作成コンテキストメッセージをＰＣＦに送信するとき（３ＧＰＰ ＴＳ２９．５１２参照）、SmPolicy作成コンテキストメッセージは、ＤＮＮおよびＳ－ＮＳＳＡＩを含む。ＳＭＦインスタンスが、異なるＤＮＮまたはＳ－ＮＳＳＡＩのためにメッセージを処理するとき、所与のSmPolicy作成コンテキストに割り当てられるべきメッセージ優先度を決定することは、ＳＭＦにとって困難である。したがって、コンシューマＮＦにおいてそのようなきめ細かいポリシーを可能にして、所与のサービスメッセージに対して正しい優先度を設定することは、複雑である。

【0061】

オペレータがそのようなポリシーを作成することによってその問題を解決しても、すべてのコンシューマＮＦが対応するインプリメンテーションを一様にサポートする可能性は非常に低い。中間（たとえば、ＳＣＰ／ＳＥＰＰ）およびプロデューサＮＦは、ＤＮＮ、ネットワークスライス、ＳＵＰＩなどの専用または共有セットを供してもよい。したがって、優先度に基づく過負荷状態中のメッセージの拒否は、サービスの妨害につながり得る。コンシューマＮＦが複雑なポリシーを有効にして適切な優先度を設定する場合であっても、中間またはプロデューサＮＦが優先度に基づいてメッセージを破棄するとき、優先度に基づくメッセージの破棄は、ＤＮＮ／ネットワークスライス／ＳＵＰＩなどの特定のセットに対するサービスの妨害につながる条件をトリガし得る。

【0062】

サービスの妨害攻撃は、ネットワークオペレータにとって深刻な結果をもたらし得る。たとえば、ＰＣＦが過負荷であるときに、オペレータは、所与のＤＮＮ／ネットワークスライスなどについてトラフィックの１００％をシャットダウンすることを望まないことがある。オペレータは、コンシューマＮＦが、サービスの妨害を回避するために、正しいメッセージ優先度を投入させることを期待することはできない。したがって、過負荷状態中であってもトラフィックルールに合致するメッセージの保証された処理を提供するカスタムポリシーを所与のノード上に構成する必要がある。この問題は、すべての中間ＮＦノードおよびプロデューサＮＦノードに対して一般的であるので、本明細書で説明される解決策は、所与のノードが過負荷状態にあるときでさえ、所与のノードにおいて保証されたサービスを保証するよう、すべての中間ノード（たとえば、ＳＣＰ／ＳＥＰＰ）およびプロデューサＮＦ（３ＧＰＰ定義または非３ＧＰＰ定義）に適用されることができる。

【0063】

本明細書で説明する主題は、中間またはプロデューサＮＦにおいて負荷レベルを追跡し、過負荷メッセージ処理ルールを用いて、パラメータが特定のルールに合致するメッセージのために、保証された帯域幅を識別する、ルールベースの過負荷制御を適用する、過負荷コントローラを含む。図４は、過負荷処理ルールに合致するメッセージのために保証された帯域幅を提供する過負荷コントローラを含む中間ＮＦまたはプロデューサＮＦであってもよい、ＮＦの例を図示する。図４を参照すると、ＮＦ４００は、少なくとも１つのプロセッサ４０２およびメモリ４０４を含む。ＮＦ４００はまた、３ＧＰＰまたは非３ＧＰＰ定義サービスを提供する、１つ以上のサービスインスタンス４０６を含む。例えば、サービスインスタンス４０６は、図１に図示される３ＧＰＰ定義サービスまたは図１に図示されない非３ＧＰＰ定義サービスのうちのいずれを提供してもよい。ＮＦ４００はまた、過負荷メッセージ処理ルールに合致するメッセージのために保証された帯域幅を提供するために、サービスレベルおよび／またはＮＦもしくはノードレベルで実現される過負荷コントローラ４０８を含む。ＮＦ４００はさらに、過負荷状態中のメッセージの処理を管理するために中間またはプロデューサＮＦによって使用される過負荷メッセージ処理ルールを構成することに備える過負荷制御構成インターフェイス４１０を含む。ルールのうちの少なくともいくつかは、宛先ネットワーク名（ＤＮＮ）またはネットワークスライス、サブスクリプション、もしくはロケーション識別パラメータを、ルール選択基準として含む。過負荷制御構成インターフェイス４１０はまた、保証された帯域幅サービスを過負荷メッセージ処理ルールのうちの少なくともいくつかと関連付けることに備えてもよい。

【0064】

上記の参照される親出願は、所与のサービスに役立つ保証されたトラフィックを提供する解決策を記載する。これは、５Ｇトラフィックおよび非５Ｇトラフィックについて適用される。その出願の解決策詳細は、サービス名だけでなく、ＤＮＮ、ネットワークスライス、ＳＵＰＩ範囲などの任意の５Ｇ定義パラメータにも基づく保証されたサービス提供を解決するために適用され得る。

【0065】

任意の好適な機構を用いて、中間またはプロデューサＮＦにおける過負荷状態を検出してもよい。たとえば、過負荷検出アルゴリズムは、ノードのＣＰＵ利用、ノードのメモリ利用、入来トラフィックレートなどを考慮してもよい。本明細書で説明される主題は、過負荷制御中に許可／拒否されるべきメッセージを選択するためのポリシーを定義することを含む。本解決策は、ＰＣＦ、ＮＲＦ、ＳＣＰ、ＳＥＰＰなどの５Ｇ ＮＦにおいて、または非３ＧＰＰ定義ＮＦにおいて適用され得る。本解決策は、任意のオペレータが、過負荷状態中であっても、所与のノード上で保証されたサービスを提供するために、カスタムポリシーを定義することを可能にする。これは、オペレータが、異なる顧客タイプ、ネットワークロケーション、および他の要因のサービス性をサポートするのに役立つ。過負荷状態において保証された帯域幅サポートを受けることができる顧客のタイプおよび他の要因の例は、以下を含む：
・プレミアム顧客、
・緊急呼、
・特定のＤＮＮ、
・特定のネットワークスライス、
・等。
全体として、（ノード過負荷／輻輳中であっても）様々なトラフィックパターンを処理するために本明細書で説明される主題によって可能にされるユースケースは、無制限であり、ネットワークオペレータにとって価値が高い。

【0066】

図５は、過負荷コントローラ４０８によって実行されてもよいメッセージ処理の一例を示す。図５を参照すると、所与のノード（中間またはプロデューサＮＦ）上で、以下の構成が、図４に示される過負荷制御構成インターフェイス４１０を介して実行されてもよい：
・バケット、例えばバケットＸを作成する。

【0067】

・バケットサイズ、例えば５Ｋをバケットに取り付ける（バケットサイズは、処理されることが保証される、所与のルールに合致するメッセージの数を示す）。

【0068】

・保証されたサービスサポートが要求されるルールを作成する。例：
method=post,service=npcf-smpolicycontrol, dnn=“device.abc.com”
・ルールをバケットに関連付ける。
・以下および親出願において説明されるように、保証されたサービス処理を適用する。
図５では、バケット５００，５０２，および５０４は、それぞれ、オーバーフローメッセージ処理ルールＸ、Ｙ、およびＺに関連付けられる。各バケット５００，５０２，および５０４は、過負荷状態中にノードまたはサービスが通過させることを保証される、ルールに合致するメッセージの数を示すメッセージ処理容量（バケットサイズ）で構成される。図示の例では、バケット５００は５０００メッセージの容量で構成され、バケット５０２は１０，０００メッセージの容量で構成され、バケット５０４は３０００メッセージのメッセージ処理容量で構成される。オーバーフローバケット５０６は、メッセージを処理することがバケット５００，５０２，および５０４のうちの１つの処理容量を超えるであろう場合に、バケット５００，５０２，および５０４からのメッセージの処理を取り扱うために使用される。処理がバケット５０６によって管理されるメッセージは、過負荷ポリシーに基づいて処理されてもよい。例えば、過負荷ポリシーは、高優先度メッセージのみが通過されることを示し、処理がバケット５０６によって管理されるメッセージは、メッセージの優先度に基づいて処理されるかまたはドロップされてもよい。

【0069】

図５に図示される処理例のうちの１つでは、バケット５００についてルールＸに合致する８０００個の入来メッセージがノードに到着する。バケット５００は、メッセージのうちの５０００個に対して、保証された処理帯域幅を提供するように構成される。したがって、バケット５００についてルールに合致するメッセージのうちの３０００個は、オーバーフローバケット５０６に対するルールを使用して処理されることになる。同様の処理およびオーバーフローがバケット５０２および５０４において実行され、各バケットは、各バケットに対して構成されるメッセージ処理量まで、メッセージのために、保証されたメッセージ処理帯域幅を提供する。各バケットについて構成された処理量を超えるメッセージは、オーバーフローバケット５０６について定義されたルールを使用して処理される。

【0070】

オーバーフローメッセージ処理ルールの例
本解決策が適用／有効にされているノードのタイプに基づいて、ネットワークオペレータは、過負荷制御構成インターフェイス４１０を使用して、過負荷コントローラ４０８によって使用される過負荷メッセージ処理ルールを構成することができる。たとえば、過負荷制御範囲が（ほぼすべての５Ｇ ＮＦ間通信のメッセージが通過する）ＳＣＰ／ＳＥＰＰである場合、オペレータは、ＳＣＰ／ＳＥＰＰがメッセージを転送することを許可される任意のプロデューサＮＦについて合致するルールを構成してもよい。過負荷コントローラ４０８によるアクセスのために構成されてもよいルールの２つの例は、以下の通りである：
method=post, service=npcf-smpolicycontrol, dnn=“device.abc.com”
method=post, service=nudm-sdm, supirange={A-B}
上述のルールは、過負荷コントローラ４０８によってアクセス可能なルールデータベースにポストされている。第１のルール例において、ルール定義の「method=post」部分は、ルールが適用される方法のタイプを定義する。ルール定義の「service=nfcp-smpolicycontrol」部分は、ルールが適用されるサービスのタイプを定義し、これは、この場合、ＰＣＦに宛てられるセッション管理ポリシー制御である。ルール定義の第３の部分「dnn=device.abc.com」は、ルールが、この例ではdevice.abc.comである特定の宛先ネットワーク名に固有であるように、サービス独立パラメータを指定する。第２のルール例では、ルール定義のサービス部分は、ルールを、ユーザデータ管理または加入者データ管理サービスへの適用として識別する。ルールのサービス独立範囲部分は、ルール定義についてＳＵＰＩ範囲を定義し、これは、ルールを、特定のＳＵＰＩ範囲を有するメッセージについては過負荷中に保証された帯域幅サービスを定義するよう適用可能にするが、同じサービスタイプのすべてのメッセージについて、そうするわけではない。

【0071】

過負荷制御範囲が所与のプロデューサＮＦである場合、ルールは、そのプロデューサＮＦによって提供されるサービスのセットに限定され得、例えば、ＰＣＦ ＮＦインスタンスに対して、ネットワークオペレータは、そのＰＣＦ ＮＦインスタンスによってサポートされるサービスのセットに合致するルールを構成してもよい。以下の２つのルール定義を使用して、ルールパラメータに合致するメッセージに対して、プロデューサＮＦレベルで、保証された帯域幅を提供することができる：
method=post, service=npcf-smpolicycontrol, dnn="device.abc.com"
method=post, service=npcf-am-policy-control, supi="imsi-1234567890"
過負荷制御範囲がプロデューサＮＦサービスインスタンスである場合、ルールは、たとえばＰＣＦポリシーサービスのために、その特定のサービスのみに限定され得る。以下のルール定義を用いて、メッセージのために、保証された帯域幅を、ＮＦサービスインスタンスレベルで提供することができる：
method=post, service=npcf-am-policy-control, supi="imsi-1234567890"
親出願に記載されているように、保証された帯域サービスは、所与のルールに合致するメッセージの数をカウントするために使用されるデータ構造であるバケットを使用して提供され、バケットは、各バケットによって表される保証された帯域に対応するサイズのバケットサイズを有する。ルールを構成するとき、本明細書で説明される解決策はまた、ネットワークオペレータが、ルールに合致する後続のメッセージが、初期合致メッセージと同じバケットおよび対応するプロセッサを使用して自動的に処理されるものとするかどうかを指定することを可能にする。例えば、以下のルールについて、GET/PUT/PATCH/DELETEのための後続のメッセージは、（初期メッセージが関連付けられた）対応するバケットおよびプロセッサに自動的に関連付けられるものとする：
method=post, service=npcf-smpolicycontrol, dnn="device.abc.com"
後続のメッセージの保証されたサービスサポートのサポートも可能にするために、過負荷コントローラ４０８は、初期メッセージから作成されたリソースについての情報を取得する。５Ｇサービスアーキテクチャは、プロデューサＮＦが、作成されたリソース参照を、応答メッセージのロケーションヘッダにおいて明記することを義務付ける。過負荷コントローラ４０８は、応答メッセージのロケーションヘッダからの作成されたリソースの識別を使用して動的ルールを作成し、それを、初期メッセージが関連付けられたバケットに添付する。後続のメッセージについて、動的ルールは、共通セッションに関連するメッセージが中間またはプロデューサＮＦの同じプロセッサによって処理されることを保証する。過負荷コントローラ４０８は、応答本文からの作成されたリソースの識別を使用して動的ルールを作成し、それを、初期メッセージが関連付けられたバケットに添付するように、拡張されることができる。

【0072】

そのような動的ルールは、中間またはプロデューサＮＦから（保証されたトラフィック帯域幅が構成される初期メッセージによって作成された）対応するリソースのコンシューマＮＦ削除時に削除される必要がある。ネットワークオペレータは、依然として、初期メッセージおよび後続メッセージのために静的ルールを構成するオプションを有する。静的ルールを構成することにより、過負荷コントローラ４０８が動的ルールを管理する必要がなくなる。

【0073】

以下の表１および表２は、中間またはプロデューサＮＦにおいて構成されてもよい静的ルールおよび動的ルールの例を示す。

【0074】

【表1】

【0075】

【表2】

【0076】

表１において、各ルールは、バケット５００，５０２，および５０４のうちの１つに関連付けられる。各ルールはまた、後続のメッセージを処理するための動的ルール生成が構成されるか否かに関してマークされる。表２は、表１において対応する静的ルールに合致する後続のメッセージに対して生成される動的ルールを示す。例えば、表２の第１の動的ルールは、表１において第１のルールに合致する初期メッセージに応答したプロデューサＮＦの完全修飾ドメイン名を含む。

【0077】

機能処理フロー
以下のステップを用いて、ルールベースの過負荷制御を提供するよう中間またはプロデューサＮＦを構成および使用してもよい。

【0078】

１．ネットワークオペレータは、バケット、ルールを定義し、バケットとルールとの間の関連付けを作成する。

【0079】

・オペレータはまた、各ルールについて、そのルールの後続のメッセージが過負荷コントローラ４０８によって同じバケットを使用して自動的に処理されるかどうかを設定する。

【0080】

・この情報は、永続データベースに格納される。
２．メッセージがノードによって受信されると、構成された静的ルールおよび動的ルールに対してメッセージパラメータをチェックし、メッセージがバケットのいずれかに対する処理ルールに合致するかどうかを判断する。

【0081】

・動的ルールは、ステップ４において追加される。
・本明細書に記載の過負荷制御手順を実行する（利用可能な場合、合致するルールに対して保証された帯域幅を使用してメッセージを処理するか、またはオーバーフローバケットに対して定義されたルールを使用してメッセージを処理する）。

【0082】

３．メッセージが処理されることを許可され、合致するルールが前のステップで見つかった場合、そのルールに対する後続のメッセージ処理が追跡される必要があるかどうかをチェックする。

【0083】

・後続のメッセージ処理が追跡される必要がある場合、参照をＨＴＴＰ要求コンテキストとともにバケットインデックスに記憶し、メッセージを処理して所与のサービスを提供するサービスインスタンスにメッセージを転送する。

【0084】

４．応答メッセージは、初期メッセージとして逆方向経路を通って移動するので、過負荷コントローラは、応答メッセージも見ることになる。

【0085】

・要求のコンテキストが、（ステップ３でマークされるように）後続のメッセージ処理が取り扱われる必要があることを示す場合、以下のように動的ルールを作成する：
・ＵＲＩ：作成されたリソースについてのＵＲＩ、バケット：bucketId
・要求メッセージがDELETEリソースに対するものである場合、動的テーブルからルールを除去する。

【0086】

以下に示される表３は、中間またはプロデューサＮＦによって実現されてもよい、異なる過負荷メッセージ処理ルールに合致する、トラフィックのための保証されたトラフィック帯域幅レートの例を示す。表３のレートは、図５に示すバケットに割り当てられる相対的なバケット容量に対応する。

【0087】

【表3】

【0088】

表３において、ルール－Ｘ、ルール－Ｙ、およびルール－Ｚの各ルールは、中間またはプロデューサＮＦの、あるパーセンテージの確保された容量である、保証された帯域幅サービスレートを有する。各ルールについて、中間またはプロデューサＮＦが過負荷状態にあるときに所与のルールに合致するメッセージによって排他的に使用されることになる中間またはプロデューサＮＦの、あるパーセンテージの確保された容量は、たとえ所与のルールに合致するメッセージが中間プロキシノードによって拒否される他のサービスのメッセージよりも低い優先度であるとしても、である。例えば、ルール－Ｘに対するメッセージが１０の優先度で中間プロキシノードにおいて受信される場合、ルール－Ｘに対するメッセージは、ルール－Ｘの保証された帯域幅の下で処理されてもよく、より高い優先度（より高い優先度は、３ＧＰＰに従うと、より低い数値優先度値を意味する）を有する別の保証されないメッセージは、中間またはプロデューサＮＦによって拒絶されてもよい。表３において、ルールＸに合致するメッセージは、中間またはプロデューサＮＦの確保された容量の５％を保証され、ルールＹに合致するメッセージは、中間またはプロデューサＮＦの確保された容量の１０％を保証され、ルールＺに合致するメッセージは、中間またはプロデューサＮＦの確保された容量の３％を保証される。

【0089】

このモデルでは、ネットワークオペレータは、以下を構成する。
１．中間またはプロデューサＮＦの全体的な容量。
例えば、中間またはプロデューサＮＦの全体的な容量は１００Ｋである。

【0090】

２．各ルールの保証された帯域幅
例えば、中間またはプロデューサＮＦの全体的な容量１００Ｋの場合、保証された帯域幅またはＧＴＢ（表３に基づく）は、以下のようになる：
ルールＸ：５Ｋ
ルール－Ｙ：１０Ｋ
ルールＺ：３Ｋ
したがって、（中間プロキシノードを通過するかまたはプロデューサＮＦによって処理される）複数のサービスメッセージタイプにわたるメッセージ優先度にかかわらず、（構成された保証された帯域幅サービスを有する）各ルールに合致するメッセージは、中間またはプロデューサＮＦ上に、確実に／保証される割り当てられた容量を有することになる。

【0091】

メッセージ処理の詳細：
以下は、特定の過負荷メッセージ処理ルールに合致するメッセージのために、保証されたトラフィック帯域幅を提供する、ＳＣＰ、ＳＥＰＰ、サービスメッシュなどの中間プロキシノード、またはプロデューサＮＦによって実現されてもよい、機能的詳細である。

【0092】

１．中間またはプロデューサＮＦの過負荷状態をチェックする。中間またはプロデューサＮＦが過負荷状態にない場合、さらなるチェックは必要とされない。メッセージは、保証されない帯域幅の一部として、中間もしくはプロデューサＮＦを通過することまたは中間もしくはプロデューサＮＦによって処理されることを許可されるべきである。これは、（非過負荷シナリオ中に）中間またはプロデューサＮＦの通常の機能を処理する場合である。

【0093】

２．中間またはプロデューサＮＦが過負荷状態にある場合、受信されたメッセージが過負荷メッセージ処理ルールのうちの１つに合致するかどうかをチェックする。

【0094】

ａ．メッセージが過負荷メッセージ処理ルールの１つに合致し、利用可能な帯域幅が依然としてある場合、（メッセージ優先度に関係なく）メッセージを処理のためにサービスインスタンスに転送する。過負荷メッセージ処理ルールの１つに合致しないメッセージのみが、優先度に基づいてスロットリングされることになる。

【0095】

ｂ．過負荷メッセージ処理ルールおよび対応するバケットが構成され、ルールのうちの１つに合致する所与のメッセージに利用可能な帯域幅が存在しない場合、以下を行う：
ｉ．合致するバケット内に、より低い優先度の（すなわち、現在のメッセージの優先度よりも低い）メッセージがある場合、そのバケットの保証された帯域幅からそのメッセージを許可する。合致するバケットは、ルールに合致することについて、他のメッセージの中で、より高い優先度のメッセージを許可にするために、細かい粒度の論理に備える。

【0096】

例えば、所与のルールに合致するメッセージについて、Ｐ５は、そのルールに対するすべてのメッセージの中で最も高い優先度のメッセージであるかもしれない。したがって、過負荷の間、そのルールに対するＰ５メッセージは、（過負荷ポリシーが他のルールに合致するメッセージのＰ３メッセージを拒否しているかもしれない場合でさえ、当該ルールに合致するメッセージに対して構成された帯域幅まで）許可されなければならない。

【0097】

ｉｉ．より低いまたは同じ優先度のメッセージがバケット内にない場合、メッセージ処理手順は、ルールが構成されないサービスの場合と同じである。（ステップｃの詳細を参照されたい）。

【0098】

ｃ．過負荷メッセージ処理ルールが構成されていない場合、保証されない帯域幅バケットを介してメッセージを実行する。したがって、メッセージは、システムの過負荷ポリシーに基づいて許可／拒否される（過負荷ポリシーは、メッセージ優先度およびシステム過負荷レベルに基づいてメッセージを受け入れる／拒否する）。

【0099】

ｉ．過負荷ポリシーがメッセージを通過させる場合、メッセージは処理されることになる。

【0100】

ｉｉ．そうでない場合、メッセージは拒否されることになる。
このアプローチでは、パラメータが過負荷制御ルールに合致するメッセージは、保証されたメッセージ処理帯域幅を、構成された量まで有することになる。これは、ネットワークにおけるデータストームまたは他の異常の間でさえも当てはまる。

【0101】

いくつかのメッセージ処理ルールは、対応するネットワーク機能仕様において３ＧＰＰによって指定されるＰＡＴＨ／ＵＲＩを使用してカテゴリ化および識別されることができる。上で示されたような、他のルールは、優先度が正しく構成されるよう、ネットワークスライスおよびＤＮＮ識別パラメータを必要としてもよい。このアプローチは、ＰＡＴＨ／ＵＲＩおよび要求ヘッダまたはボディ内の他のカスタム属性に基づいて、非５Ｇメッセージにも適用され得る。したがって、ネットワークオペレータは、それぞれのノードを通過する任意のルール合致タイプのトラフィックに対して、保証されたトラフィック帯域幅を構成することができるべきである。このアプローチはまた、保証されたトラフィック帯域幅を（ＦＱＤＮ、ネットワークスライス識別子、ＤＮＮなどに基づいて）所与のプロデューサにも提供するために適用することができる。これは、緊急サービスおよび他のプレミアム顧客を管理するユースケースにおいて役立つ。優先度が割り当てられていないメッセージについては、オペレータはデフォルトのメッセージ優先度を指定することができる。（３ＧＰＰ ＴＳ２９．５００に従って、クライアントによって定義される優先度を伴わないすべての５Ｇコア（５ＧＣ）メッセージは、２４のデフォルト優先度を有するものとする）。代替的に、ネットワークオペレータは、ネットワークスライスおよび／またはＤＮＮ識別パラメータに基づいて相対的なメッセージ優先度を決定することができる。

【0102】

過負荷メッセージ処理ルールを使用して保証された帯域幅を実現する中間またはプロデューサＮＦはまた、保証された帯域幅を実施するために以下のタイプの追跡／監視を実現してもよい。

【0103】

構成された過負荷メッセージ処理ルールを伴うメッセージについて、各合致するルールの下で処理される所与の優先度のメッセージレートを追跡し；
全体的なメッセージレートを追跡し、中間またはプロデューサＮＦの全体的なトラフィック容量と比較し；
個々の優先度メッセージについて、保証されない帯域幅メッセージレートを追跡する。

【0104】

以下に示される表４は、過負荷メッセージ処理ルールに合致するメッセージについて保証されたトラフィック帯域幅を実現する中間またはプロデューサＮＦにおいて追跡されてもよいメッセージレートの例を図示する。

【0105】

【表4】

【0106】

表４において、ルール－Ｘ、ルール－Ｙ、およびルール－Ｚの各々についてのトラフィックレートが追跡されることが分かる。加えて、所与のルール内の各許可されたメッセージ優先度のレートも追跡される。例えば、ルールＸの場合、優先度Ｐ０およびＰ５のメッセージレートが追跡される。これは、Ｐ０およびＰ５優先度メッセージの１Ｋトラフィックレートがルール－Ｘバケットを介して許可されることを表す。保証された帯域幅を有するものとして定義されないルールは、構成される保証された帯域幅レートを有さないことになることに留意されたい。

【0107】

上述のように、保証された帯域幅サービスを伴うメッセージのメッセージレートを追跡することに加えて、中間プロキシノードは、保証されない帯域幅トラフィックについて優先度に基づいてメッセージレートを追跡することも行ってもよい。以下に示す表５は、中間またはプロデューサＮＦによって追跡されてもよい例示的な保証されない帯域幅トラフィックを示す。

【0108】

【表5】

【0109】

表５において、保証されない帯域幅トラフィックについてのメッセージレートは、すべての許可されたメッセージ優先度について追跡される。

【0110】

保証されたトラフィック帯域幅サービスを実現する中間またはプロデューサＮＦノードによって追跡されてもよい別のメトリックは、保証されない帯域幅トラフィックおよび保証された帯域幅トラフィックの総メッセージレートである。以下に示す表６は、そのような中間またはプロデューサＮＦノードによって追跡されてもよい総メッセージレートを示す。

【0111】

【表6】

【0112】

表６は、表４および表５におけるすべてのトラフィックレートの合計を示し、それは、中間またはプロデューサＮＦノードによって現在処理されているトラフィックの総レートである。そのようなレートは、ノードが過負荷状態にあるかどうかを判断するために、ノードの全体的なメッセージ容量と比較されてもよい。たとえば、ネットワークオペレータは、ノードの過負荷トリガ状態を総容量の８０％になるように構成してもよい。ノードが１００ｋメッセージ／ｓを処理することができ、エンジニアリングされた過負荷閾値が８０ｋで定義される場合、表６の８３ｋのレートは、ノードが過負荷状態にあることを示し、本明細書で説明するように、保証されたトラフィック帯域幅サービスをトリガするであろう。

【0113】

保証された帯域幅サービスの単純化された説明のために、表７における以下の例は、過負荷ポリシーが１００％のノード容量でメッセージを拒否すると仮定する。しかしながら、保証されない帯域幅バケットからのメッセージの拒否は、複数のスロットルレベルおよびメッセージ優先度マッピングを伴う過負荷ポリシーを使用して適用されることができる（ある優先度レベルまでのメッセージは、あるシステム過負荷レベルで拒否されることになる）。

【0114】

【表7-1】

【0115】

【表7-2】

【0116】

【表7-3】

【0117】

表７のシナリオ１において、保証された帯域幅サービスが構成されていないサービスＡからメッセージが受信される。したがって、メッセージは、保証されないトラフィック帯域幅バケットに対して定義されたポリシーに従って処理されることになる。メッセージの優先度は４である。この例では、保証されないトラフィック帯域幅バケット内に優先度が４より低いメッセージがあり、利用可能な帯域幅があると仮定する。したがって、メッセージは渡されるかまたは処理されることになり、優先度Ｐ４に対する保証されない帯域幅トラフィックについてのカウントが更新されることになる。

【0118】

表７のシナリオ２では、ルールＡに対する別のメッセージが受信される。例１と同様に、メッセージのために構成された、保証された帯域幅サービスは存在しないので、メッセージは、保証されないトラフィック帯域幅バケットに対して定義されたポリシーに従って渡されるかまたは処理されることになる。シナリオ２では、メッセージは１８の優先度を有する。保証されない帯域幅バケットには、優先度が１８より低いメッセージはないと仮定する。したがって、メッセージは、優先度１８の保証されないトラフィック帯域幅メッセージに利用可能な帯域幅がある場合に、渡されるかまたは処理されることになる。そのような帯域幅が利用可能でない場合、メッセージは拒否される。

【0119】

シナリオ３では、ルールＡに対する優先度１８を有するメッセージが受信される。しかしながら、システムは１００％の容量で動作していると仮定する。ルールＡのために構成された、保証された帯域幅サービスはなく、保証されないトラフィック帯域幅バケットにおいて、処理中の、より低い優先度のメッセージはなく、利用可能なシステム容量がないので、メッセージは拒否されることになる。

【0120】

表７のシナリオ４では、優先度２０のメッセージがルールＸについて受信される。保証された帯域幅サービスが、ルールＸに対して構成される。ルールＸに対する保証されたレート内に利用可能な割当があることも仮定される。したがって、メッセージは渡されるかまたは処理されることになり、ルールＸの優先度２０トラフィックのレートは更新されることになる。

【0121】

表７のシナリオ５では、ルールＸに対する優先度２０のメッセージが受信される。この例では、システムは１００％の容量で動作しているが、ルールＸのメッセージに対して保証されたレート内に利用可能な割当があると仮定する。したがって、メッセージは渡されるかまたは処理されることになり、割当は優先度２０およびルールＸについて更新されることになる。システムが１００％の容量で動作しているとき、たとえ保証されないトラフィック帯域幅バケット内のメッセージが、所与のサービスについて確保された割当内で許可されるメッセージよりも高い優先度を有する場合であっても、システムは保証されないトラフィック帯域幅バケット内のメッセージを拒否することになることに留意されたい。

【0122】

表７のシナリオ６では、優先度４のメッセージがルールＹに対して受信される。また、ルール－Ｙ保証容量は使い果たされていると仮定される。しかしながら、ルール－Ｙの保証されたトラフィック帯域幅バケットには４より低い優先度を有するメッセージがある。したがって、当該メッセージは、ルール－Ｙに対する保証されたトラフィック帯域幅バケットから許可されることになり、優先度Ｐ４に対する保証されたトラフィック帯域幅トラフィックレートは、ルール－Ｙに対して更新されることになる。ルールＹに合致する任意のより低い優先度のメッセージについては、保証されないトラフィック帯域幅の下で処理されることになる。必要であれば、それらのメッセージは拒否されることになる。

【0123】

表７のシナリオ７では、優先度６を有するメッセージがルール－Ｙについて受信される。また、ルール－Ｙ保証容量は使い果たされ、ルール－Ｙのための保証されたトラフィック帯域幅バケット内には、より低い優先度のメッセージはないことも、仮定される。したがって、メッセージは、保証されないトラフィック帯域幅バケットから処理されることになる。メッセージは、保証されないトラフィック帯域幅バケットに対して定義されたポリシーに基づいて処理または拒否されることになる。

【0124】

シナリオ８では、システムが１００％の容量で動作しており、優先度６を有するメッセージがルールＹに対して受信されると仮定される。また、ルール－Ｙ保証容量は使い果たされ、ルール－Ｙのための保証されたトラフィック帯域幅バケットには、より低い優先度のメッセージはないことも、仮定される。したがって、メッセージは、保証されないトラフィック帯域幅バケットから処理されることになる。メッセージは、その優先度および保証されないトラフィック帯域幅バケットのために構成されたポリシーに基づいて許可または拒否されることになる。

【0125】

シナリオ９では、メッセージが１００％の容量で実行されていると仮定する。優先度１８のメッセージがルール－Ｙについて受信される。また、ルール－Ｙ保証容量は使い果たされ、ルール－Ｙのための保証されたトラフィック帯域幅バケットには、より低い優先度のメッセージはないことも、仮定される。したがって、メッセージは、保証されないトラフィック帯域幅バケットから処理されることになる。この例では、保証されないトラフィック帯域幅バケットには、より低い優先度のメッセージはないと仮定され、なぜならば、システムは１００％の容量で動作しており、メッセージを処理するためのさらなるバッファ空間はないので、メッセージは拒否されることになる。

【0126】

図６は、中間またはプロデューサＮＦにおいてルールベースの過負荷制御を提供するための例示的なプロセスを示すフローチャートである。図６を参照すると、ステップ６００において、プロセスは、中間またはプロデューサＮＦにおいて、過負荷メッセージ処理ルールを構成することを含み、過負荷メッセージ処理ルールのうちの少なくともいくつかは、ＤＮＮまたはネットワークスライス、サブスクリプション、もしくはロケーション、または３ＧＰＰもしくはベンダによって定義される任意の他の属性を識別するパラメータをルール選択基準として含む。例えば、ネットワークオペレータまたはＮＦベンダは、中間またはプロデューサＮＦのために、ＤＮＮ、Ｓ－ＮＳＳＡＩ、ＳＵＰＩ、または他のパラメータを選択基準として指定する過負荷制御ルールを構成してもよい。

【0127】

ステップ６０２において、プロセスは、中間またはプロデューサＮＦにおいて、保証された帯域幅サービスを過負荷メッセージ処理ルールのうちの少なくともいくつかと関連付けることを含む。たとえば、ネットワークオペレータまたはＮＦベンダは、過負荷制御ルールのいくつかまたはすべてについてＮＦの帯域幅の確保された部分を構成してもよい。ＮＦが過負荷状態にあるとき、ルールのうちの１つに合致するメッセージは、ノードのために確保された、保証された帯域幅を使用して、処理されることになる。

【0128】

ステップ６０４において、中間またはプロデューサＮＦにおいてメッセージが受信される。例えば、中間またはプロデューサＮＦは、ＰＣＦ等のネットワーク機能からサービスに対するサービス要求等の５Ｇトランザクションに関するメッセージを受信してもよい。

【0129】

ステップ６０６において、過負荷状態が存在する、と判断される。過負荷状態は、中間またはプロキシＮＦ全体の過負荷状態、または中間もしくはプロデューサＮＦによって提供される多くのサービスのうちの１つに影響を及ぼす過負荷状態であってもよい。たとえば、メッセージは、ＳＣＰ、ＳＥＰＰ、サービスメッシュノード、またはＰＣＦもしくはＵＤＭなどのプロデューサＮＦにおいて受信されてもよい。「過負荷状態」は、中間またはプロデューサＮＦの利用が、メッセージを処理するための利用可能な容量の８０％などのオペレータ定義閾値を超えたことを意味する。

【0130】

ステップ６０８では、プロセスは、中間またはプロデューサＮＦが、メッセージは、過負荷メッセージ処理ルールのうちの１つについてルール選択基準に合致するパラメータを含む旨を識別することを含む。たとえば、中間またはプロデューサＮＦは、メッセージが、過負荷メッセージ処理ルールのうちの１つに対してプロビジョニングされる選択基準に合致するＤＮＮ、Ｓ－ＮＳＳＡＩ、または他のパラメータもしくはパラメータの組合せを含む、と判断してもよい。

【0131】

ステップ６１０において、プロセスは、中間またはプロデューサＮＦが、合致するルールに対する保証された帯域幅の一部がメッセージを処理するために利用可能である、と判断することを含む。例えば、メッセージが、過負荷メッセージ処理ルールのうちの１つに合致するパラメータを含む場合、ステップ６１０は、そのルールについてのメッセージカウントを読み取ることと、メッセージカウントがその特定のルールに対する保証された帯域幅に対するメッセージカウント閾値未満であると判定することとを含んでもよい。

【0132】

ステップ６１２において、プロセスは、合致するルールに対する保証された帯域幅を使用してメッセージを処理することと、そのルールのメッセージカウントを更新することとを含む。たとえば、ノードが中間ノード、たとえば、ＳＣＰ、またはＳＥＰＰもしくはサービスメッシュである場合、メッセージを処理することは、メッセージをプロデューサＮＦに転送することを含んでもよい。ノードがプロデューサＮＦである場合、メッセージを処理することは、そのＮＦタイプによって提供されるサービスに従ってメッセージを処理することを含んでもよい。たとえば、プロデューサＮＦがＰＣＦである場合、メッセージを処理することは、コンシューマＮＦからのポリシー要求に応答することを含んでもよい。メッセージカウントを更新することは、ルールに対応するバケットに関連付けられるカウントを更新することを含んでもよい。

【0133】

本明細書で説明される主題は、オペレータが、５Ｇメッセージ優先度パラメータを正しく設定するためにコンシューマＮＦに依存する必要なく、異なるＤＮＮまたはネットワークスライスに関連するメッセージに、保証された帯域幅を提供することを可能にする。保証された帯域幅処理は、ＤＮＮまたはネットワークスライスに選択的に適用され得、これは、同じタイプのメッセージが異なるように扱われることを可能にする。

【0134】

以下の参考文献の各々の開示は、参照によりその全体が本明細書に組み込まれる。
参照：
3GPP TS 29.500, Technical Specification Group Core Network and Terminals; 5G System; Technical Realization of Service Based Architecture; Stage 3 (Release 16) V16.0.0, (2019-06).
3GPP TS 29.510, Technical Specification Group Core Network and Terminals; 5G System; Network Function Repository Services; Stage 3 (Release 16) V16.0.0 (2019-06).
3GPP TS 29.512, Technical Specification Group Core Network and Terminals; 5G System, Session Management Policy Control Service, Stage 3, (Release 16) V16.4.0 (2020-03)
本開示の主題の様々な詳細は、本開示の主題の範囲から逸脱することなく変更されてもよいことが理解されよう。さらに、前述の説明は、例示のみを目的としており、限定を目的としていない。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】