特許 7561840 中間プロキシノードにおいて、サービスのために、保証されたトラフィック帯域幅を提供するための方法、システム、およびコンピュータ可読媒体

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

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

(11)【特許番号】

(24)【登録日】2024-09-26

(45)【発行日】2024-10-04

(54)【発明の名称】中間プロキシノードにおいて、サービスのために、保証されたトラフィック帯域幅を提供するための方法、システム、およびコンピュータ可読媒体

(51)【国際特許分類】

   H04W 28/12 20090101AFI20240927BHJP

   H04W 28/14 20090101ALI20240927BHJP

   H04W 92/24 20090101ALI20240927BHJP

【ＦＩ】

H04W28/12

H04W28/14

H04W92/24

【請求項の数】 11

(21)【出願番号】P 2022522375

(86)(22)【出願日】2020-09-21

(65)【公表番号】

(43)【公表日】2022-12-19

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

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

(87)【国際公開日】2021-04-22

【審査請求日】2023-06-21

(31)【優先権主張番号】16/601,371

(32)【優先日】2019-10-14

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

(73)【特許権者】

【識別番号】502303739

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

(74)【代理人】

【識別番号】110001195

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

(72)【発明者】

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

(72)【発明者】

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

【審査官】石原 由晴

(56)【参考文献】

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

【文献】米国特許第０９４２４０５９（ＵＳ，Ｂ１）

【文献】Ericsson，Informative description of internal NF routing of HTTP messages[online]，3GPP TSG-CT WG4 Meeting #93 C4-193285，Internet<URL:https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_93_Wroclaw/Docs/C4-193285.zip>，2019年08月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】コンシューマＮＦとプロデューサＮＦとの間の中間プロキシノードにおけるサービスのための保証されたトラフィック帯域幅を提供するための例示的なプロセスを示すフローチャートである。

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

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

本明細書で説明される主題は、保証されたトラフィック帯域幅が特定のサービスに割り当てられ得るように機構をサポートする、コンシューマＮＦとプロデューサＮＦとの間のサービスメッシュノード、ＳＣＰ、ＳＥＰＰ、または他の中間プロキシノードを含む。この機構は、本明細書では、サービスのための保証されたトラフィック帯域幅（ＧＴＢＳ）と呼ばれる。

【0059】

以下に示す表１は、中間プロキシノードによって実現されてもよい、異なるサービスための保証されたトラフィック帯域幅サービスレートの例を示す。

【0060】

【表1】

【0061】

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

【0062】

このモデルでは、ネットワークオペレータは、以下を設定する：
１．中間プロキシノードの全体容量。

【0063】

例えば、ノード／サービスメッシュ／ＳＣＰ等の全体容量は１００Ｋである。
２．中間プロキシノードを介する各サポートされるサービスに対するＧＴＢ。

【0064】

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

【0065】

機能的詳細：
以下は、サービスのために、保証されたトラフィック帯域幅を提供する、ＳＣＰ、ＳＥＰＰ、サービスメッシュ、または他の中間プロキシノード等の中間プロキシノードによって実現されてもよい、機能的詳細である。

【0066】

１．中間プロキシノードの過負荷状態をチェックする。中間プロキシノードが過負荷状態にない場合、さらなるチェックは必要とされない。メッセージは、非ＧＴＢＳ帯域幅の一部として中間プロキシノードを通過することを許可されるべきである。これは、（非過負荷の場合の間）中間プロキシノードの正常な機能を扱う場合である。

【0067】

２．中間プロキシノードが過負荷状態にある場合、受信されたメッセージのターゲットサービスがＧＴＢＳを設定されているかどうかをチェックする。

【0068】

ａ．ＧＴＢＳが設定されており、利用可能な帯域幅が依然としてある場合、（メッセージ優先度に関わらず）メッセージが中間プロキシノードを通過するのを許可する。

【0069】

非ＧＴＢＳ帯域幅バケットの下で処理されているメッセージのみが、優先度に基づいて抑制される。

【0070】

ｂ．ＧＴＢＳが設定されており、（非ＧＴＢＳトラフィックのために）利用可能な帯域幅がない場合、以下を行う。

【0071】

ｉ．ＧＴＢＳバケット内により低い優先度（すなわち、現在のメッセージの優先度よりも低い）のメッセージがある場合、そのメッセージをＧＴＢＳ帯域幅から許可する。

【0072】

ＧＴＢＳバケットは、そのサービスについての他のメッセージの中で、より高い優先度のメッセージを許可するために、きめ細かい論理を考慮する。

【0073】

たとえば、所与のサービスについて、Ｐ５は、そのサービスについてのすべてのメッセージの中で最も高い優先度のメッセージであるかもしれない。したがって、過負荷の間、そのようなサービスについてのＰ５メッセージは、過負荷ポリシーが他のサービスのＰ３メッセージを拒否しているかもしれない場合でさえも、（そのサービスのための設定された帯域幅まで）許可されなければならない。

【0074】

ｉｉ．ＧＴＢＳバケット内に、より低いかまたは同じ優先度のメッセージが存在しない場合、メッセージ処理手順は、ＧＴＢＳが設定されていないサービスの場合と同じである。（ステップｃの詳細を参照されたい）
ｃ．ＧＴＢＳが設定されていない場合、非ＧＴＢＳバケットを介してメッセージを実行する。したがって、メッセージは、システムの過負荷ポリシーに基づいて許可／拒否される（過負荷ポリシーは、メッセージ優先度およびシステム過負荷レベルに基づいてメッセージを受け入れる／拒否する）。

【0075】

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

【0076】

ｉｉ．そうでない場合、メッセージは拒否されることになる。
このアプローチでは、設定されたＧＴＢＳを有するサービスは、サービスメッシュ／中間プロキシノードを介して、保証されたサービス性を有する。これは、ネットワークにおけるデータストームまたは他の異常の間であっても当てはまる。

【0077】

各サービスは、対応するネットワーク機能仕様において３ＧＰＰによって指定されるＰＡＴＨ／ＵＲＩを用いて分類および識別され得る。このアプローチは、ＰＡＴＨ／ＵＲＩに基づく非５Ｇメッセージにも適用され得る。したがって、ネットワークオペレータは、パス／ＵＲＩ要素に基づいて、任意のサービスのためにＧＴＢを設定することが可能であるべきである。このアプローチは、（ＦＱＤＮに基づいて）所与のプロデューサにＧＴＢを提供するためにも適用され得る。これは、緊急サービスおよび他のプレミアム顧客を管理する使用例において役立つ。優先度が割り当てられていないメッセージの場合、アプリケーションは、オペレータがデフォルトメッセージ優先度を指定すべきであることを推奨する。（３ＧＰＰ ＴＳ２９．５００に従って、クライアントによって定義される優先度を伴わないすべての５Ｇコア（５ＧＣ）メッセージは、２４のデフォルト優先度を有するものとする）。

【0078】

ＧＴＢＳを実現する中間プロキシノードは、ＧＴＢＳを実施するために以下のタイプの追跡／監視を実現してもよい：
設定されたＧＴＢＳを有するサービスの場合、ＧＴＢＳの下で処理される所与の優先度のメッセージレートを追跡する；
全体メッセージレートを追跡し、中間プロキシノードの全体トラフィック容量と比較する；および
個々の優先度メッセージについて、非ＧＴＢＳメッセージレートを追跡する。

【0079】

以下に示される表２は、サービスのために保証されたトラフィック帯域幅を実現する中間プロキシノードにおいて追跡されてもよいメッセージレートの例を示す。

【0080】

【表2】

【0081】

表２において、サービスＳｖｃ－Ｘ、Ｓｖｃ－Ｙ、およびＳｖｃ－Ｚの各々のトラフィックレートが追跡されることが分かる。加えて、所与のサービス内の各設定されたメッセージ優先度のレートも追跡される。例えば、サービスＳｖｃ－Ｘの場合、優先度Ｐ０およびＰ５のメッセージレートが追跡される。保証された帯域幅を有するものとして定義されていないサービスは、設定された保証された帯域幅サービスレートを有さないことに留意されたい。

【0082】

上述のように、保証された帯域幅サービスを有するメッセージのメッセージレートを追跡することに加えて、中間プロキシノードは、非ＧＴＢＳトラフィックについての優先度に基づいてメッセージレートを追跡することもできる。以下に示す表３は、中間プロキシノードによって追跡されてもよい例示的な非ＧＴＢＳトラフィックを示す。

【0083】

【表3】

【0084】

表３において、非ＧＴＢＳトラフィックのメッセージレートは、定義されたメッセージ優先度ごとに追跡される。

【0085】

ＧＴＢＳサービスを実現する中間プロキシノードによって追跡されてもよい別のメトリックは、非ＧＴＢＳトラフィックとＧＴＢＳトラフィックとの総メッセージレートである。以下に示す表４は、そのような中間プロキシノードによって追跡されてもよい総メッセージレートを示す。

【0086】

【表4】

【0087】

表４は、中間プロキシノードによって現在処理されているトラフィックの総レートである、表１および表２のすべてのトラフィックレートの合計を示す。そのようなレートは、ノードが過負荷状態にあるかどうかを判断するために、ノードの全体的なメッセージ容量と比較されてもよい。たとえば、ネットワークオペレータは、ノードの過負荷トリガ状態を総容量の８０％になるよう設定することができる。ノードが１００ｋメッセージ／ｓを処理することができ、設計された過負荷閾値が８０ｋで定義される場合、表４の８３ｋのレートは、ノードが過負荷状態にあり、本明細書で説明されるようにＧＴＢＳサービスをトリガすることを示す。

【0088】

ＧＴＢＳアルゴリズムの簡単な説明のために、表５の以下の例は、過負荷ポリシーが１００％のノード容量でメッセージを拒否すると仮定する。しかしながら、非ＧＴＢＳバケットからのメッセージの拒否は、複数のスロットルレベルおよびメッセージ優先度マッピングを有する過負荷ポリシーを用いて適用することができる（ある優先度レベルまでのメッセージは、あるシステム過負荷レベルで拒否される）。

【0089】

【表5】

【0090】

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

【0091】

表５のシナリオ２では、Ｓｖｃ－Ａについての別のメッセージが受信される。例１と同様に、メッセージのために設定された、保証された帯域幅サービスは存在しないので、メッセージは、非ＧＴＢＳバケットに対して定義されたポリシーに従って処理されることになる。シナリオ２では、メッセージは１８の優先度を有する。非ＧＴＢＳバケットには優先度が１８より低いメッセージはないと仮定する。したがって、メッセージは、優先度１８の非ＧＴＢＳメッセージのために利用可能な帯域幅がある場合に、ルーティングされることになる。そのような帯域幅が利用可能でない場合、メッセージは拒否される。

【0092】

シナリオ３では、Ｓｖｃ－Ａについて優先度１８を有するメッセージが受信される。しかしながら、システムは１００％の容量で動作していると仮定する。Ｓｖｃ－Ａのために設定された、保証された帯域幅サービスはなく、非ＧＴＢＳバケットにおいて、処理中の、より低い優先度のメッセージはなく、利用可能なシステム容量がないので、メッセージは拒否される。

【0093】

表５のシナリオ４では、優先度２０のメッセージがＳｖｃ－Ｘについて受信される。保証された帯域幅サービスが、Ｓｖｃ－Ｘのために設定されている。Ｓｖｃ－Ｘの保証されたレート内に利用可能な割当があることも仮定される。したがって、メッセージは渡され、Ｓｖｃ－Ｘの優先度２０トラフィックのレートは更新されることになる。

【0094】

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

【0095】

表５のシナリオ６では、優先度４のメッセージがＳｖｃ－Ｙについて受信される。また、Ｓｖｃ－Ｙ保証容量は使い果たされていると仮定される。しかしながら、Ｓｖｃ－ＹのＧＴＢＳバケットには、優先度が４よりも低いメッセージが存在する。したがって、当該メッセージは、Ｓｖｃ－ＹのＧＴＢＳバケットから許可され、優先度Ｐ４についてのＧＴＢＳトラフィックレートが、Ｓｖｃ－Ｙについて更新されることになる。

【0096】

表５のシナリオ７では、優先度６のメッセージがＳｖｃ－Ｙについて受信される。Ｓｖｃ－Ｙ保証容量は使い果たされ、Ｓｖｃ－ＹのためのＧＴＢＳバケット内には、より低い優先度のメッセージはないことも仮定される。したがって、メッセージは、非ＧＴＢＳバケットから処理されることになる。メッセージは、非ＧＴＢＳバケットに対して定義されたポリシーに基づいてルーティングまたは拒否される。

【0097】

シナリオ８では、システムが１００％の容量で動作しており、優先度６を有するメッセージがＳｖｃ－Ｙについて受信されると仮定する。また、Ｓｖｃ－Ｙ保証容量は使い果たされ、Ｓｖｃ－ＹのためのＧＴＢＳバケット内には、より低い優先度のメッセージはないとも仮定される。したがって、メッセージは、非ＧＴＢＳバケットから処理されることになる。メッセージは、その優先度および非ＧＴＢＳバケットのために設定されたポリシーに基づいて許可または拒否されることになる。

【0098】

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

【0099】

図４は、本明細書で説明される、サービスのために保証されたトラフィック帯域幅を実現する中間プロキシノードのブロック図である。図４を参照すると、中間プロキシノード４００は、サービスコンシューマとサービスプロデューサとの間でメッセージをルーティングするＳＣＰ、ＳＥＰＰ、サービスメッシュノード、サービスプロキシ、または他のノードであってもよい。図示の例では、中間プロキシノード４００は、少なくとも１つのプロセッサ４０２およびメモリ４０４を含む。中間プロキシノード４００は、中間プロキシノードは過負荷状態にあるかどうかを判断し、上述のように、中間プロキシノードの、設定された、サービスごとの、保証された最小帯域幅で、ＧＴＢＳサービスを実現する、サービスのための保証されたトラフィック帯域幅（ＧＴＢＳ）コントローラ４０６をさらに含む。図示の例では、サービスごとの保証された最小帯域幅は、サービスごとのバケットを用いて確保され追跡される。例えば、サービスＳｖｃ－Ｘのためのバケット４０８は、中間プロキシノード４００が過負荷状態にあるとき、サービスＳｖｃ－Ｘについて５ｋ（５０００）メッセージを許可するように設定される。図示の例では、サービスＳｖｃ－Ｘの入来レートは８ｋである。したがって、サービスＳｖｃ－Ｘについてのより高い優先度のメッセージのうちの５ｋは許可されるが、サービスＳｖｃ－Ｘについてのメッセージのうちの残りの３ｋは、保証されないバケット４１０に渡され、メッセージは、保証されない帯域幅トラフィックに対する過負荷制御ポリシーに基づいて許可または拒否される。

【0100】

中間プロキシノード４００は、サービスＳｖｃ－Ｙのトラフィックのためにバケット４１２を実現する。バケット４１２は、サービスＳｖｃ－Ｙについて１０ｋメッセージの保証された最小帯域幅の利用を確保および追跡するように設定される。図示の例では、サービスＳｖｃ－Ｙの入来メッセージレートは２２ｋである。したがって、サービスＳｖｃ－Ｙについてのメッセージの１０ｋは許可されるが、サービスＳｖｃ－Ｙについてのメッセージの１２ｋは保証されないバケット４１０に渡され、そこで、メッセージは、保証されない帯域幅トラフィックのための中間プロキシノード４００の過負荷制御ポリシーに基づいて許可または拒否されることになる。

【0101】

中間プロキシノード４００は、サービスＳｖｃ－Ｚについてのメッセージのために３ｋの保証された最小帯域幅でバケット４１４を実現する。図示の例では、サービスＳｖｃ－Ｚの入来メッセージレートは３３ｋである。したがって、トラフィックの３ｋは通される一方で、サービスＳｖｃ－Ｚのメッセージトラフィックの３０ｋは保証されないバケット４１０に渡されることになり、ここで、メッセージは、保証されないトラフィックに対する過負荷制御ポリシーに基づいて、通されるかまたは拒否される。

【0102】

中間プロキシノード４００は、ネットワークオペレータがサービスのために保証された最小帯域幅を設定することを可能にするＧＴＢＳ設定インタフェース４１６を含む。ＧＴＢＳ設定インターフェイス４１６は、ユーザが、各サービスのためのサービス識別パラメータと、複数の異なるサービスのためのサービスごとの保証された最小帯域幅とを定義することを可能にしてもよい。保証された最小帯域幅は、バケット４０８および４１２などの、サービスごとのＧＴＢＳバケットを用いて確保および追跡されてもよい。保証されないバケット４１０は、中間プロキシノード４００の確保されない（システム）帯域幅を追跡するようデフォルトで設定されてもよい。

【0103】

図５は、中間プロキシノードにおいてサービスのために保証されたトラフィック帯域幅を実現するための例示的なプロセスを示すフローチャートである。図５を参照すると、ステップ５００において、メッセージが、過負荷状態にある中間プロキシノードにおいて受信される。たとえば、メッセージは、ＳＣＰ、ＳＥＰＰ、サービスメッシュノード、または他の中間プロキシノードにおいて受信されてもよい。「過負荷状態」は、中間プロキシノードの利用が、メッセージを処理するための利用可能な容量の８０％などのオペレータ定義閾値を超えたことを意味する。

【0104】

ステップ５０２において、メッセージは、保証された帯域幅サービスに関連付けられているものとして識別される。たとえば、ＧＴＢＳコントローラ４０６は、メッセージを、メッセージ中の１つ以上のパラメータに基づいて、保証された帯域幅サービスに関連付けられているものとして、識別してもよい。そのようなパラメータの例は、ＵＲＩまたは他のサービス識別パラメータを含む。

【0105】

ステップ５０４において、サービスに利用可能な保証された帯域幅があるかどうかが判断される。たとえば、サービスのための保証された帯域幅が現在の測定間隔について５ｋメッセージであり、３ｋメッセージのみが送信された場合、２ｋの利用可能な帯域幅が残る。保証された帯域幅が利用可能である場合、制御はステップ５０６に進み、メッセージは渡されるかまたはルーティングされ、メッセージカウントが更新される。たとえば、ＧＴＢＳコントローラ４０６は、各サービスについて、設定された保証された帯域幅を下回るメッセージを通過させ、サービスごと、サービス内の優先度ごとに、メッセージカウントを更新し、全体のメッセージカウントを更新してもよい。

【0106】

ステップ５０４において、サービスに対する保証された帯域幅が利用可能でないと判断された場合、制御はステップ５０８に進み、より低い優先度のメッセージがＧＴＢＳバケットに存在するかどうかを判断する。例えば、メッセージがサービスＡに対するものであり、４という優先度値を携えると仮定する。ＧＴＢＳコントローラ４０６は、送信されるべく待機している、サービスＡについてのＧＴＢＳバケット内のメッセージを分析することになる。優先度５以上のメッセージが少なくとも１つある場合、ＧＴＢＳコントローラ４０６は、そのより低い優先度のメッセージをサービスＡについてのメッセージと置き換えてもよい。次に、制御はステップ５０６に進み、そこでサービスＡについてのメッセージは送信され、メッセージカウントは更新される。

【0107】

ステップ５０８において、ＧＴＢＳバケット内に、より低い優先度のメッセージはないと判断された場合、制御はステップ５１０に進み、非ＧＴＢＳ帯域幅が利用可能であるかどうかが判断される。たとえば、ＧＴＢＳコントローラ４０６は、非ＧＴＢＳバケットが任意の残りのメッセージ処理容量を有するかどうかを判断することによって、非ＧＴＢＳ帯域幅が利用可能であるかどうかを判断してもよい。非ＧＴＢＳバケットは確保された容量を有さないので、非ＧＴＢＳバケットが利用可能な容量を有するかどうかに関する判断は、メッセージを処理するために利用可能なシステム容量があるかどうかに基づいて判断されてもよい。システムが過負荷状態にあるにもかかわらず、過負荷閾値を上回るいくらかの残存容量が存在する場合がある。ＧＴＢＳコントローラ４０６が、利用可能な非ＧＴＢＳ容量があると判断する場合、制御はステップ５１２に進み、メッセージはルーティングされる。

【0108】

ステップ５１０において、非ＧＴＢＳ容量が利用可能でないと判断された場合、制御はステップ５１４に進み、より低い優先度のメッセージが非ＧＴＢＳバケットに存在するかどうかを判断する。例えば、メッセージが４という優先度値を携えると仮定する。ＧＴＢＳコントローラ４０６は、送信されるべく待機している、非ＧＴＢＳバケット内のメッセージを分析することになる。優先度５以上の少なくとも１つのメッセージがある場合、ＧＴＢＳコントローラ４０６は、そのより低い優先度のメッセージを優先度４のメッセージと置き換えてもよい。次に、制御はステップ５１２に進み、優先度４のメッセージが送信され、メッセージカウントが更新される。ステップ５１４において、非ＧＴＢＳバケット内に、より低い優先度のメッセージがない場合、制御はステップ５１６に進み、メッセージは拒否される。

【0109】

本明細書で説明される主題は、オペレータが５Ｇルートを用いて、５Ｇ ＮＦサービス間のサービス性を微調整および保証することを可能にする。そのような保証されたサービス性サポートがなければ、データストーム／不正サービス／機能は、中間プロキシノードを過負荷にし得、サービス障害につながり得る。本解決策は、任意の非５Ｇサービスにも適用することができ、したがって、中間ゲートウェイ／プロキシ上でこの推奨を実現し、任意のサービス間において最小限の実行可能なサービス性保証することができる。

【0110】

以下の参考文献の各々の開示が、参照によりその全体が本明細書に組み込まれる。
参照：
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).
本開示の主題の様々な詳細は、本開示の主題の範囲から逸脱することなく変更されてもよいことが理解されよう。さらに、前述の説明は、例示のみを目的としており、限定を目的としていない。

【図1】

【図2】

【図3】

【図4】

【図5】