知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2024137085
(43)【公開日】2024-10-07
(54)【発明の名称】通信制御装置、端末装置及び通信制御方法
(51)【国際特許分類】
H04L 41/342 20220101AFI20240927BHJP
H04W 28/02 20090101ALI20240927BHJP
H04W 88/14 20090101ALI20240927BHJP
【ＦＩ】
H04L41/342
H04W28/02
H04W88/14
【審査請求】未請求
【請求項の数】5
【出願形態】ＯＬ
(21)【出願番号】P 2023048457
(22)【出願日】2023-03-24
【国等の委託研究の成果に係る記載事項】（出願人による申告）令和３年度、国立研究開発法人情報通信研究機構「エマージング技術に対応したダイナミックセキュアネットワーク技術の研究開発」、産業技術力強化法第１７条の適用を受ける特許出願
(71)【出願人】
【識別番号】000208891
【氏名又は名称】ＫＤＤＩ株式会社
(74)【代理人】
【識別番号】100165179
【弁理士】
【氏名又は名称】田▲崎▼ 聡
(74)【代理人】
【識別番号】100175824
【弁理士】
【氏名又は名称】小林 淳一
(74)【代理人】
【識別番号】100114937
【弁理士】
【氏名又は名称】松本 裕幸
(72)【発明者】
【氏名】小此木 謙一
(72)【発明者】
【氏名】鈴木 理基
(72)【発明者】
【氏名】田上 敦士
【テーマコード（参考）】
5K067
【Ｆターム（参考）】
5K067AA21
5K067DD11
5K067DD57
5K067EE02
5K067EE10
5K067EE16
(57)【要約】
【課題】制御プレーンにおいてユーザの通信品質要件を満たすことができるように複数のＮＦが連携することを図る。
【解決手段】複数のＮＦが連携して特定の手順を実行する際にＮＦ間で使用されるＡＰＩリクエストに対して処理優先度とユーザの通信品質要件を満たすためのユーザ品質要求値とを含め、受信したＡＰＩリクエストに含まれる処理優先度に基づいて当該ＡＰＩリクエストの優先制御を行う優先制御部と、当該ＡＰＩリクエストに含まれるユーザ品質要求値と自ＮＦにおける通信品質消費値とに基づいてユーザ品質要求値を更新し、更新後のユーザ品質要求値に基づいて処理優先度を更新する処理優先度設定部と、更新後の処理優先度及びユーザ品質要求値を含むＡＰＩリクエストを後段のＮＦへ送信するリクエスト送信部と、を備える。
【選択図】図１
【解決手段】複数のＮＦが連携して特定の手順を実行する際にＮＦ間で使用されるＡＰＩリクエストに対して処理優先度とユーザの通信品質要件を満たすためのユーザ品質要求値とを含め、受信したＡＰＩリクエストに含まれる処理優先度に基づいて当該ＡＰＩリクエストの優先制御を行う優先制御部と、当該ＡＰＩリクエストに含まれるユーザ品質要求値と自ＮＦにおける通信品質消費値とに基づいてユーザ品質要求値を更新し、更新後のユーザ品質要求値に基づいて処理優先度を更新する処理優先度設定部と、更新後の処理優先度及びユーザ品質要求値を含むＡＰＩリクエストを後段のＮＦへ送信するリクエスト送信部と、を備える。
【選択図】図１
【特許請求の範囲】
【請求項1】
通信ネットワークの制御プレーンのネットワーク機能を有する通信制御装置において、
複数の前記ネットワーク機能が連携して特定の手順を実行する際に前記ネットワーク機能の間で使用されるＡＰＩリクエストに対して処理優先度とユーザの通信品質要件を満たすためのユーザ品質要求値とを含め、
前記通信制御装置は、
前記ＡＰＩリクエストを受信するリクエスト受信部と、
受信した前記ＡＰＩリクエストに含まれる前記処理優先度に基づいて、当該受信した前記ＡＰＩリクエストの優先制御を行う優先制御部と、
当該受信した前記ＡＰＩリクエストに含まれる前記ユーザ品質要求値と自ネットワーク機能における通信品質消費値とに基づいて前記ユーザ品質要求値を更新し、更新後の前記ユーザ品質要求値に基づいて前記処理優先度を更新する処理優先度設定部と、
更新後の前記処理優先度及び前記ユーザ品質要求値を含む前記ＡＰＩリクエストを、前記特定の手順を実行する後段の前記ネットワーク機能へ送信するリクエスト送信部と、
を備える通信制御装置。
複数の前記ネットワーク機能が連携して特定の手順を実行する際に前記ネットワーク機能の間で使用されるＡＰＩリクエストに対して処理優先度とユーザの通信品質要件を満たすためのユーザ品質要求値とを含め、
前記通信制御装置は、
前記ＡＰＩリクエストを受信するリクエスト受信部と、
受信した前記ＡＰＩリクエストに含まれる前記処理優先度に基づいて、当該受信した前記ＡＰＩリクエストの優先制御を行う優先制御部と、
当該受信した前記ＡＰＩリクエストに含まれる前記ユーザ品質要求値と自ネットワーク機能における通信品質消費値とに基づいて前記ユーザ品質要求値を更新し、更新後の前記ユーザ品質要求値に基づいて前記処理優先度を更新する処理優先度設定部と、
更新後の前記処理優先度及び前記ユーザ品質要求値を含む前記ＡＰＩリクエストを、前記特定の手順を実行する後段の前記ネットワーク機能へ送信するリクエスト送信部と、
を備える通信制御装置。
【請求項2】
前記処理優先度設定部は、前記リクエスト受信部が受信した前記ＡＰＩリクエストに含まれる前記処理優先度が特定の優先度である場合に、前記処理優先度を変更せず、当該特定の優先度を維持する、
請求項１に記載の通信制御装置。
請求項１に記載の通信制御装置。
【請求項3】
前記特定の優先度は最高の優先度である、
請求項２に記載の通信制御装置。
請求項２に記載の通信制御装置。
【請求項4】
ユーザの通信品質要件を満たすためのユーザ品質要求値を含むサービスリクエストを、当該サービスリクエストに含まれるユーザ品質要求値を満たすようにＡＰＩリクエストに含まれる処理優先度及びユーザ品質要求値を各ネットワーク機能が更新する制御プレーンを有する通信ネットワークへ送信するサービスリクエスト送信部を備える、
端末装置。
端末装置。
【請求項5】
通信ネットワークの制御プレーンのネットワーク機能を有する通信制御装置が実行する通信制御方法であって、
複数の前記ネットワーク機能が連携して特定の手順を実行する際に前記ネットワーク機能の間で使用されるＡＰＩリクエストに対して処理優先度とユーザの通信品質要件を満たすためのユーザ品質要求値とを含め、
前記ＡＰＩリクエストを受信するリクエスト受信ステップと、
受信した前記ＡＰＩリクエストに含まれる前記処理優先度に基づいて、当該受信した前記ＡＰＩリクエストの優先制御を行う優先制御ステップと、
当該受信した前記ＡＰＩリクエストに含まれる前記ユーザ品質要求値と自ネットワーク機能における通信品質消費値とに基づいて前記ユーザ品質要求値を更新し、更新後の前記ユーザ品質要求値に基づいて前記処理優先度を更新する処理優先度設定ステップと、
更新後の前記処理優先度及び前記ユーザ品質要求値を含む前記ＡＰＩリクエストを、前記特定の手順を実行する後段の前記ネットワーク機能へ送信するリクエスト送信ステップと、
を含む通信制御方法。
複数の前記ネットワーク機能が連携して特定の手順を実行する際に前記ネットワーク機能の間で使用されるＡＰＩリクエストに対して処理優先度とユーザの通信品質要件を満たすためのユーザ品質要求値とを含め、
前記ＡＰＩリクエストを受信するリクエスト受信ステップと、
受信した前記ＡＰＩリクエストに含まれる前記処理優先度に基づいて、当該受信した前記ＡＰＩリクエストの優先制御を行う優先制御ステップと、
当該受信した前記ＡＰＩリクエストに含まれる前記ユーザ品質要求値と自ネットワーク機能における通信品質消費値とに基づいて前記ユーザ品質要求値を更新し、更新後の前記ユーザ品質要求値に基づいて前記処理優先度を更新する処理優先度設定ステップと、
更新後の前記処理優先度及び前記ユーザ品質要求値を含む前記ＡＰＩリクエストを、前記特定の手順を実行する後段の前記ネットワーク機能へ送信するリクエスト送信ステップと、
を含む通信制御方法。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、通信制御装置、端末装置及び通信制御方法に関する。
【背景技術】
【0002】
図２は、「3rd Generation Partnership Project」で標準化されている５Ｇシステムのモバイルコアのアーキテクチャを示す図である。５Ｇシステムでは、モバイルコアの機能がＮＦ（Network Function、ネットワーク機能）毎にマイクロサービス化されている。複数のＮＦは、各ＮＦが提供するＡＰＩ（Application Programming Interface）を利用してＮＦ間で連携することにより、「3rd Generation Partnership Project」で定義されている特定の手順（procedure）を実現する（例えば、非特許文献１参照）。
【0003】
また将来の６ＧやＢｅｙｏｎｄ５Ｇに向けて多種多様な通信サービスが誕生することが予想されるが、それらを実現するための新たな手順や新たなＮＦや既存のＮＦが提供する新たなＡＰＩなどが新たに定義されることが考えられる。その際には、制御プレーン（Control-plane：C-plane）バス上で使用されるＮＦ間連携用ＡＰＩの種類が増加する。
【0004】
また、従来のスマートフォンに加えてＩｏＴ機器など、モバイル通信を利用するデバイスが増加することが予想され、それらデバイスのレジストレーション等のリクエストや、モバイルコア外部からモバイルコア内部に対するトラフィック制御やポリシー変更等のリクエストが増加することにより、C-planeバス上の信号処理数も増加すると考えられる。
【0005】
ここで、ＮＦ間のインタラクションには、複数のＮＦに跨ってシーケンシャルに処理が行われるものがある。例えば、図３に示されるＡＦからの「traffic influence」手順では、ＡＦからＮＥＦを経由してＵＤＲ等の後段のＮＦへと、「http2/Rest API」を利用して、複数のＮＦに跨ってシーケンシャルに処理が行われる。
【先行技術文献】
【非特許文献】
【0006】
【非特許文献1】3GPP, TS 23.502, V18.0.0, 2022-12
【発明の概要】
【発明が解決しようとする課題】
【0007】
しかし、上述した従来の５ＧシステムのC-planeでは、次に示すような課題があった。各ＮＦは処理の優先度（Priority）やタイムアウト（timeout）値等のパラメータを自身で自由に設定することができるために、各ＮＦが独自に例えばPriorityを決めることによって、ユーザの通信品質要件を満たすことができない可能性があった。
【0008】
本発明は、このような事情を考慮してなされたものであり、その目的は、制御プレーンにおいてユーザの通信品質要件を満たすことができるように複数のＮＦが連携することを図ることにある。
【課題を解決するための手段】
【0009】
本発明の一態様は、通信ネットワークの制御プレーンのネットワーク機能を有する通信制御装置において、複数の前記ネットワーク機能が連携して特定の手順を実行する際に前記ネットワーク機能の間で使用されるＡＰＩリクエストに対して処理優先度とユーザの通信品質要件を満たすためのユーザ品質要求値とを含め、前記通信制御装置は、前記ＡＰＩリクエストを受信するリクエスト受信部と、受信した前記ＡＰＩリクエストに含まれる前記処理優先度に基づいて、当該受信した前記ＡＰＩリクエストの優先制御を行う優先制御部と、当該受信した前記ＡＰＩリクエストに含まれる前記ユーザ品質要求値と自ネットワーク機能における通信品質消費値とに基づいて前記ユーザ品質要求値を更新し、更新後の前記ユーザ品質要求値に基づいて前記処理優先度を更新する処理優先度設定部と、更新後の前記処理優先度及び前記ユーザ品質要求値を含む前記ＡＰＩリクエストを、前記特定の手順を実行する後段の前記ネットワーク機能へ送信するリクエスト送信部と、を備える通信制御装置である。
本発明の一態様は、上記の通信制御装置において、前記処理優先度設定部は、前記リクエスト受信部が受信した前記ＡＰＩリクエストに含まれる前記処理優先度が特定の優先度である場合に、前記処理優先度を変更せず、当該特定の優先度を維持する、通信制御装置である。
本発明の一態様は、上記の通信制御装置において、前記特定の優先度は最高の優先度である、通信制御装置である。
本発明の一態様は、上記の通信制御装置において、前記処理優先度設定部は、前記リクエスト受信部が受信した前記ＡＰＩリクエストに含まれる前記処理優先度が特定の優先度である場合に、前記処理優先度を変更せず、当該特定の優先度を維持する、通信制御装置である。
本発明の一態様は、上記の通信制御装置において、前記特定の優先度は最高の優先度である、通信制御装置である。
【0010】
本発明の一態様は、ユーザの通信品質要件を満たすためのユーザ品質要求値を含むサービスリクエストを、当該サービスリクエストに含まれるユーザ品質要求値を満たすようにＡＰＩリクエストに含まれる処理優先度及びユーザ品質要求値を各ネットワーク機能が更新する制御プレーンを有する通信ネットワークへ送信するサービスリクエスト送信部を備える、端末装置である。
【0011】
本発明の一態様は、通信ネットワークの制御プレーンのネットワーク機能を有する通信制御装置が実行する通信制御方法であって、複数の前記ネットワーク機能が連携して特定の手順を実行する際に前記ネットワーク機能の間で使用されるＡＰＩリクエストに対して処理優先度とユーザの通信品質要件を満たすためのユーザ品質要求値とを含め、前記ＡＰＩリクエストを受信するリクエスト受信ステップと、受信した前記ＡＰＩリクエストに含まれる前記処理優先度に基づいて、当該受信した前記ＡＰＩリクエストの優先制御を行う優先制御ステップと、当該受信した前記ＡＰＩリクエストに含まれる前記ユーザ品質要求値と自ネットワーク機能における通信品質消費値とに基づいて前記ユーザ品質要求値を更新し、更新後の前記ユーザ品質要求値に基づいて前記処理優先度を更新する処理優先度設定ステップと、更新後の前記処理優先度及び前記ユーザ品質要求値を含む前記ＡＰＩリクエストを、前記特定の手順を実行する後段の前記ネットワーク機能へ送信するリクエスト送信ステップと、を含む通信制御方法である。
【発明の効果】
【0012】
本発明によれば、制御プレーンにおいてユーザの通信品質要件を満たすことができるように複数のＮＦが連携することができるという効果が得られる。
【図面の簡単な説明】
【0013】
【図1】一実施形態に係る通信制御装置の構成例を示すブロック図である。
【図2】５Ｇシステムのモバイルコアのアーキテクチャを示す図である。
【図3】「3rd Generation Partnership Project」で標準化されている５Ｇシステムにおける「traffic influence」手順を示すシーケンス図である。
【発明を実施するための形態】
【0014】
以下、図面を参照し、本発明の実施形態について説明する。本実施形態では、通信ネットワークのC-plane（制御プレーン）の一例として図２に示される５ＧシステムのC-planeを挙げて説明する。
【0015】
本実施形態では、ＡＰＩリクエストに対して、処理優先度（Priority）とユーザの通信品質要件を満たすためのユーザ品質要求値（User requirement）とを含める。ＡＰＩリクエストは、複数のＮＦ（ネットワーク機能）が連携して特定の手順を実行する際にＮＦの間でC-planeバス上で使用される。ＡＰＩリクエストに対して、Priorityを格納するフィールドと、「User requirement」を格納するフィールドと、を設ける。Priorityは、ＡＰＩリクエストを受信したＮＦが当該ＡＰＩリクエストを処理する優先度である。「User requirement」は、ユーザの通信品質要件を満たすためのユーザ品質要求値である。本実施形態の一例として、「User requirement」は、ユーザの通信品質要件を満たすために必要な、ＡＰＩリクエストの処理に使用可能な残り時間であるタイムアウト（timeout）値である。
【0016】
ＮＦは、受信したＡＰＩリクエストに含まれるPriorityに基づいて当該ＡＰＩリクエストを処理する。ＮＦは、当該ＡＰＩリクエストに含まれるタイムアウト値と、自己が要する当該ＡＰＩリクエストの処理時間（通信品質消費値）とに基づいてタイムアウト値を更新し、更新後のタイムアウト値に基づいてPriorityを更新する。ＮＦは、更新後のPriority及びタイムアウト値を当該ＡＰＩリクエストの各フィールドに格納して当該ＡＰＩリクエストを後段のＮＦへ送信する。
【0017】
図１は、一実施形態に係る通信制御装置の構成例を示すブロック図である。図１に示す通信制御装置１は、５ＧシステムのC-planeのＮＦ（ネットワーク機能）を有する。図１において、通信制御装置１は、リクエスト受信部１１と、リクエスト送信部１２と、優先制御部１３と、リクエスト処理部１４と、処理優先度（Priority）設定部１５と、レスポンス処理部１６とを備える。
【0018】
通信制御装置１の各機能は、通信制御装置１がＣＰＵ（Central Processing Unit：中央演算処理装置）及びメモリ等のコンピュータハードウェアを備え、ＣＰＵがメモリに格納されたコンピュータプログラムを実行することにより実現される。なお、通信制御装置１として、汎用のコンピュータ装置を使用して構成してもよく、又は、専用のハードウェア装置として構成してもよい。例えば、通信制御装置１は、サーバコンピュータを使用して構成されてもよい。また、通信制御装置１の各機能はクラウドコンピューティングにより実現されてもよい。また、通信制御装置１は、単独のコンピュータにより実現するものであってもよく、又は通信制御装置１の機能を複数のコンピュータに分散させて実現するものであってもよい。
【0019】
リクエスト受信部１１は、ＡＰＩリクエストＡを受信する。当該ＡＰＩリクエストＡは、特定の手順を実行する前段のＮＦを有する他の通信制御装置１から、自通信制御装置１へ送信される。
【0020】
なお、通信制御装置１のＮＦが外部ネットワークとの接続機能を有するＮＥＦやＡＭＦ等である場合は、リクエスト受信部１１は、ユーザのサービスリクエストを受信する。サービスリクエストは、ユーザ所望のリクエストであって、５Ｇシステムのモバイルコアの外部からのリクエストである。
【0021】
リクエスト受信部１１は、受信したＡＰＩリクエストＡからPriority及び「User requirement」を取得する。リクエスト受信部１１は、ＡＰＩリクエストＡの情報をデータベース３０に格納する。データベース３０は、C-planeバス上に一ＮＦとして設けられてもよいし、ＮＥＦやＡＭＦ等の外部ネットワークとの接続機能を有するＮＦに設けられてもよいし、ＮＲＦやＳＣＰに設けられてもよい。
【0022】
優先制御部１３は、リクエスト受信部１１が受信したＡＰＩリクエストＡに含まれるPriorityに基づいて、当該受信したＡＰＩリクエストＡの優先制御を行う。具体的には、優先制御部１３は、当該Priorityに基づいて、当該受信したＡＰＩリクエストＡのキューイングを行う。
【0023】
リクエスト処理部１４は、Priorityに基づいてキューイングされたＡＰＩリクエストＡを処理する。
【0024】
Priority設定部１５は、当該受信したＡＰＩリクエストＡに含まれる「User requirement」のタイムアウト値（元のタイムアウト値）と自ＮＦにおける当該ＡＰＩリクエストＡの処理時間とに基づいてタイムアウト値を更新し、更新後のタイムアウト値に基づいてPriorityを更新する。
【0025】
ＡＰＩリクエストＡの「User requirement」のタイムアウト値は、次式で更新される。
更新後のタイムアウト値＝「元のタイムアウト値」－「（ＡＰＩリクエストＡの処理完了時刻）－（ＡＰＩリクエストＡの受信時刻）」
更新後のタイムアウト値＝「元のタイムアウト値」－「（ＡＰＩリクエストＡの処理完了時刻）－（ＡＰＩリクエストＡの受信時刻）」
【0026】
リクエスト送信部１２は、データベース３０からＡＰＩリクエストＡの情報を取得する。リクエスト送信部１２は、取得したＡＰＩリクエストＡの情報に対して更新後のPriority及びタイムアウト値を適用し、更新後のPriority及びタイムアウト値が各フィールドに格納されたＡＰＩリクエストＢを、特定の手順を実行する後段のＮＦを有する他の通信制御装置１へ送信する。
【0027】
レスポンス処理部１６は、リクエスト送信部１２が後段のＮＦから受信したレスポンスＣを処理し、処理後のレスポンスＤをリクエスト受信部１１から送信させる。
【0028】
なお、マイクロサービス毎に「Service mesh」と呼ばれるプロキシを配置してＮＦ間通信を実施する場合は、ＮＦ内の処理部の一部をプロキシに配置してもよい。
【0029】
［Priorityの決定方法］
Priority設定部１５におけるPriorityの決定方法について説明する。
Priority設定部１５におけるPriorityの決定方法について説明する。
【0030】
（Priorityの初期値の決定方法）
Priorityの初期値（初期Priority）は、ユーザのサービスリクエストに含まれる通信品質要件に基づいて決定する。ユーザのサービスリクエストは、ＮＥＦやＡＭＦ等の外部ネットワークとの接続機能を有するＮＦを有する通信制御装置１のリクエスト受信部１１が外部ネットワークから受信する。当該通信制御装置１のPriority設定部１５は、ユーザのサービスリクエストに含まれる通信品質要件に基づいて、当該通信品質要件を満たすために必要なタイムアウト値（初期タイムアウト値）を求める。
Priorityの初期値（初期Priority）は、ユーザのサービスリクエストに含まれる通信品質要件に基づいて決定する。ユーザのサービスリクエストは、ＮＥＦやＡＭＦ等の外部ネットワークとの接続機能を有するＮＦを有する通信制御装置１のリクエスト受信部１１が外部ネットワークから受信する。当該通信制御装置１のPriority設定部１５は、ユーザのサービスリクエストに含まれる通信品質要件に基づいて、当該通信品質要件を満たすために必要なタイムアウト値（初期タイムアウト値）を求める。
【0031】
Priority設定部１５は、初期タイムアウト値に基づいて初期Priorityを決定する。初期Priorityの決定方法の一例を以下に示す。
（１）初期タイムアウト値が閾値ＴＨ１未満である場合は、初期Priorityを「high」に決定する。
（２）初期タイムアウト値が閾値ＴＨ１以上閾値ＴＨ２未満である場合は、初期Priorityを「medium」に決定する。
（３）初期タイムアウト値が閾値ＴＨ２以上閾値ＴＨ３未満である場合は、初期Priorityを「normal」に決定する。
（４）初期タイムアウト値が閾値ＴＨ３以上である場合は、初期Priorityを「low」に決定する。
閾値ＴＨ１，ＴＨ２，ＴＨ３は所定値である。閾値ＴＨ１，ＴＨ２，ＴＨ３の一例として、ＴＨ１が５秒であり、ＴＨ２が１０秒であり、ＴＨ３が１５秒である。Priority「high」，「medium」，「normal」，「low」の優先度は、「high」が最優先であり、次いで「medium」が優先であり、次いで「normal」が優先であり、「low」が最も優先度が低い。
（１）初期タイムアウト値が閾値ＴＨ１未満である場合は、初期Priorityを「high」に決定する。
（２）初期タイムアウト値が閾値ＴＨ１以上閾値ＴＨ２未満である場合は、初期Priorityを「medium」に決定する。
（３）初期タイムアウト値が閾値ＴＨ２以上閾値ＴＨ３未満である場合は、初期Priorityを「normal」に決定する。
（４）初期タイムアウト値が閾値ＴＨ３以上である場合は、初期Priorityを「low」に決定する。
閾値ＴＨ１，ＴＨ２，ＴＨ３は所定値である。閾値ＴＨ１，ＴＨ２，ＴＨ３の一例として、ＴＨ１が５秒であり、ＴＨ２が１０秒であり、ＴＨ３が１５秒である。Priority「high」，「medium」，「normal」，「low」の優先度は、「high」が最優先であり、次いで「medium」が優先であり、次いで「normal」が優先であり、「low」が最も優先度が低い。
【0032】
（Priorityの更新方法）
Priorityの更新は、ＮＦにおける更新後のタイムアウト値に基づいて決定する。ＡＰＩリクエストＡを受信した通信制御装置１のPriority設定部１５は、当該受信したＡＰＩリクエストＡに含まれるタイムアウト値（元のタイムアウト値）を更新し、更新後のタイムアウト値に基づいてPriorityを更新する。
Priorityの更新は、ＮＦにおける更新後のタイムアウト値に基づいて決定する。ＡＰＩリクエストＡを受信した通信制御装置１のPriority設定部１５は、当該受信したＡＰＩリクエストＡに含まれるタイムアウト値（元のタイムアウト値）を更新し、更新後のタイムアウト値に基づいてPriorityを更新する。
【0033】
Priorityの更新方法の一例を以下に示す。ここでは、Priorityは、上述した「high」，「medium」，「normal」，「low」の４段階である場合を例に挙げる。
（１）更新後のタイムアウト値が「（元のタイムアウト値）÷４」未満である場合は、Priorityを「high」に決定する。
（２）更新後のタイムアウト値が「（元のタイムアウト値）÷４」以上「（元のタイムアウト値）÷２」未満である場合は、Priorityを「medium」に決定する。
（３）更新後のタイムアウト値が「（元のタイムアウト値）÷２」以上「（元のタイムアウト値）×（３÷４）」未満である場合は、Priorityを「normal」に決定する。
（４）更新後のタイムアウト値が「（元のタイムアウト値）×（３÷４）」以上である場合は、Priorityを「low」に決定する。
例えば、元のタイムアウト値が１０秒である場合において、更新後のタイムアウト値が２．５秒未満であるときはPriority「high」に決定し、更新後のタイムアウト値が２．５秒以上５秒未満であるときはPriority「medium」に決定し、更新後のタイムアウト値が５秒以上７．５秒未満であるときはPriority「normal」に決定し、更新後のタイムアウト値が７．５秒以上であるときはPriority「low」に決定する。
（１）更新後のタイムアウト値が「（元のタイムアウト値）÷４」未満である場合は、Priorityを「high」に決定する。
（２）更新後のタイムアウト値が「（元のタイムアウト値）÷４」以上「（元のタイムアウト値）÷２」未満である場合は、Priorityを「medium」に決定する。
（３）更新後のタイムアウト値が「（元のタイムアウト値）÷２」以上「（元のタイムアウト値）×（３÷４）」未満である場合は、Priorityを「normal」に決定する。
（４）更新後のタイムアウト値が「（元のタイムアウト値）×（３÷４）」以上である場合は、Priorityを「low」に決定する。
例えば、元のタイムアウト値が１０秒である場合において、更新後のタイムアウト値が２．５秒未満であるときはPriority「high」に決定し、更新後のタイムアウト値が２．５秒以上５秒未満であるときはPriority「medium」に決定し、更新後のタイムアウト値が５秒以上７．５秒未満であるときはPriority「normal」に決定し、更新後のタイムアウト値が７．５秒以上であるときはPriority「low」に決定する。
【0034】
なお、Priority設定部１５は、リクエスト受信部１１が受信したＡＰＩリクエストＡに含まれるPriorityが特定の優先度である場合には、Priorityを変更せず、当該特定の優先度を維持してもよい。例えば、Priority設定部１５は、リクエスト受信部１１が受信したＡＰＩリクエストＡに含まれるPriorityが「high」である場合には、Priorityを変更せず、Priority「high」を維持してもよい。この場合、Priority「high」のＡＰＩリクエストＡを受信した通信制御装置１は、後段の通信制御装置１に対して、Priority「high」のＡＰＩリクエストＢを送信する。したがって、ＡＰＩリクエストのPriorityは、特定の手順を実行する全てのＮＦにおいて「high」が維持され続ける。
【0035】
また、Priorityは、上述した「high」，「medium」，「normal」，「low」のような範囲ではなく、「3rd Generation Partnership Project」で定義されている０（最高の優先順位）から３１（最低の優先順位）までの数値rangeであってもよい。
【0036】
以上がPriorityの決定方法の説明である。
【0037】
［初期タイムアウト値の決定方法］
初期タイムアウト値の決定方法について、サービスリクエストに「User requirement」が含まれている場合と、サービスリクエストに「User requirement」が含まれていない場合とに分けて説明する。
初期タイムアウト値の決定方法について、サービスリクエストに「User requirement」が含まれている場合と、サービスリクエストに「User requirement」が含まれていない場合とに分けて説明する。
【0038】
（サービスリクエストに「User requirement」が含まれている場合の例１）
Priority設定部１５は、サービスリクエストに含まれている「User requirement」のタイムアウト値（ユーザ要求タイムアウト値）と、自ＮＦにおけるデフォルトのタイムアウト値とを比較する。当該比較の結果、以下により初期タイムアウト値を決定する。
（１）「ユーザ要求タイムアウト値＞デフォルトのタイムアウト値」である場合は、デフォルトのタイムアウト値を初期タイムアウト値に決定する。
（２）「ユーザ要求タイムアウト値≦デフォルトのタイムアウト値」である場合は、ユーザ要求タイムアウト値を初期タイムアウト値に決定する。
（３）ユーザ要求タイムアウト値の指定がない場合は、デフォルトのタイムアウト値を初期タイムアウト値に決定する。
Priority設定部１５は、サービスリクエストに含まれている「User requirement」のタイムアウト値（ユーザ要求タイムアウト値）と、自ＮＦにおけるデフォルトのタイムアウト値とを比較する。当該比較の結果、以下により初期タイムアウト値を決定する。
（１）「ユーザ要求タイムアウト値＞デフォルトのタイムアウト値」である場合は、デフォルトのタイムアウト値を初期タイムアウト値に決定する。
（２）「ユーザ要求タイムアウト値≦デフォルトのタイムアウト値」である場合は、ユーザ要求タイムアウト値を初期タイムアウト値に決定する。
（３）ユーザ要求タイムアウト値の指定がない場合は、デフォルトのタイムアウト値を初期タイムアウト値に決定する。
【0039】
（サービスリクエストに「User requirement」が含まれている場合の例２）
この例２は、サービスリクエストにおいて、「User requirement」のタイムアウト値（ユーザ要求タイムアウト値）とは別個に、さらに別のタイムアウト値（別タイムアウト値）が含まれている場合である。別タイムアウト値は、既存のｈｔｔｐやＡＰＩのプログラムによってリトライの判断に利用される。
Priority設定部１５は、ユーザ要求タイムアウト値と別タイムアウト値とを比較する。当該比較の結果、以下により初期タイムアウト値を決定する。
（１）「別タイムアウト値＞ユーザ要求タイムアウト値」である場合は、ユーザ要求タイムアウト値を初期タイムアウト値に決定する。
（２）「別タイムアウト値≦ユーザ要求タイムアウト値」である場合は、次の（１）式により初期タイムアウト値を決定する。
初期タイムアウト値＝別タイムアウト値×α ・・・（１）
αは、サービスリクエストに含まれるPriorityに基づいた係数である。
例えば、サービスリクエストに含まれるPriorityが、「high」である場合は「α＝０．６」とし、「medium」である場合は「α＝０．７」とし、「normal」である場合は「α＝０．８」とし、「low」である場合は「α＝１．０」とする。また、サービスリクエストにPriorityの指定がない場合は「α＝１．０」とする。なお、αの値は、「０．５＜α＜１．０」の範囲で任意に設定可能である。
この例２は、サービスリクエストにおいて、「User requirement」のタイムアウト値（ユーザ要求タイムアウト値）とは別個に、さらに別のタイムアウト値（別タイムアウト値）が含まれている場合である。別タイムアウト値は、既存のｈｔｔｐやＡＰＩのプログラムによってリトライの判断に利用される。
Priority設定部１５は、ユーザ要求タイムアウト値と別タイムアウト値とを比較する。当該比較の結果、以下により初期タイムアウト値を決定する。
（１）「別タイムアウト値＞ユーザ要求タイムアウト値」である場合は、ユーザ要求タイムアウト値を初期タイムアウト値に決定する。
（２）「別タイムアウト値≦ユーザ要求タイムアウト値」である場合は、次の（１）式により初期タイムアウト値を決定する。
初期タイムアウト値＝別タイムアウト値×α ・・・（１）
αは、サービスリクエストに含まれるPriorityに基づいた係数である。
例えば、サービスリクエストに含まれるPriorityが、「high」である場合は「α＝０．６」とし、「medium」である場合は「α＝０．７」とし、「normal」である場合は「α＝０．８」とし、「low」である場合は「α＝１．０」とする。また、サービスリクエストにPriorityの指定がない場合は「α＝１．０」とする。なお、αの値は、「０．５＜α＜１．０」の範囲で任意に設定可能である。
【0040】
（サービスリクエストに「User requirement」が含まれていない場合の例）
Priority設定部１５は、以下により初期タイムアウト値を決定する。
（１）サービスリクエストにおいて、別タイムアウト値が含まれているがPriorityが含まれていない場合は、別タイムアウト値を初期タイムアウト値に決定する。
（２）サービスリクエストにおいて、別タイムアウト値及びPriorityの両方が含まれている場合は、上記（１）式により初期タイムアウト値を決定する。
（３）サービスリクエストにおいて、別タイムアウト値の指定がない場合は、自ＮＦにおけるデフォルトのタイムアウト値を初期タイムアウト値に決定する。
（４）サービスリクエストにおいて、別タイムアウト値が含まれていないがPriorityが含まれている場合は、上記（１）式において、別タイムアウト値の代わりに、自ＮＦにおけるデフォルトのタイムアウト値を使用して、初期タイムアウト値を決定する。
Priority設定部１５は、以下により初期タイムアウト値を決定する。
（１）サービスリクエストにおいて、別タイムアウト値が含まれているがPriorityが含まれていない場合は、別タイムアウト値を初期タイムアウト値に決定する。
（２）サービスリクエストにおいて、別タイムアウト値及びPriorityの両方が含まれている場合は、上記（１）式により初期タイムアウト値を決定する。
（３）サービスリクエストにおいて、別タイムアウト値の指定がない場合は、自ＮＦにおけるデフォルトのタイムアウト値を初期タイムアウト値に決定する。
（４）サービスリクエストにおいて、別タイムアウト値が含まれていないがPriorityが含まれている場合は、上記（１）式において、別タイムアウト値の代わりに、自ＮＦにおけるデフォルトのタイムアウト値を使用して、初期タイムアウト値を決定する。
【0041】
以上が初期タイムアウト値の決定方法の説明である。
【0042】
なお、サービスリクエストに含まれる「User requirement」やPriorityや別タイムアウト値は、「3rd Generation Partnership Project」により既に定義されているパラメータが使用されてもよい。例えば、「User requirement」は、ＲＲＣリクエストに含まれている「establishment Cause」に基づいてタイムアウト値を設定してもよい。例えば、「User requirement」は、「ARP priority」や「5QI/QFI」の値に基づいてタイムアウト値を設定してもよい。また、それら複数を組み合わせて、「User requirement」のタイムアウト値を設定してもよい。
【0043】
またサービスリクエストやＡＰＩリクエストにおいて、「User requirement」やPriorityや別タイムアウト値は、ｈｔｔｐのカスタムヘッダーに配置してもよい。
【0044】
なお、ユーザの端末装置は、ユーザの通信品質要件を満たすための「User requirement」（ユーザ品質要求値）を含むサービスリクエストを、本実施形態に係る５Ｇシステムへ送信するサービスリクエスト送信部を備える。当該５Ｇシステムにおいて、ＮＥＦやＡＭＦ等の外部ネットワークとの接続機能を有するＮＦは、ユーザの端末装置から送信されたサービスリクエストを受信する。ユーザの端末装置が送信するサービスリクエストは、さらにサービスリクエストのPriorityや別タイムアウト値を含んでもよい。
【0045】
本実施形態によれば、通信ネットワークのC-planeにおいて、複数のＮＦが連携して特定の手順を実行する際に、ＮＦの間で使用されるＡＰＩリクエストに含まれるPriorityが、各ＮＦにより、ユーザの通信品質要件を満たすためのタイムアウト値の更新結果に基づいて更新されて後段のＮＦへ伝達される。これにより、通信ネットワークのC-planeにおいて、ユーザの通信品質要件を満たすことができるように複数のＮＦが連携することができるという効果が得られる。
【0046】
また、タイムアウト値が各ＮＦで順次更新されていくので、タイムアウト値の不整合を防止でき、不要なリトライが抑制される。
【0047】
なお、これにより、例えば無線ネットワークにおける総合的なサービス品質の向上を実現することができることから、国連が主導する持続可能な開発目標（SDGs）の目標９「レジリエントなインフラを整備し、持続可能な産業化を推進するとともに、イノベーションの拡大を図る」に貢献することが可能となる。
【0048】
以上、本発明の実施形態について図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、本発明の要旨を逸脱しない範囲の設計変更等も含まれる。
【0049】
また、上述した各装置の機能を実現するためのコンピュータプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行するようにしてもよい。なお、ここでいう「コンピュータシステム」とは、ＯＳや周辺機器等のハードウェアを含むものであってもよい。
また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、フラッシュメモリ等の書き込み可能な不揮発性メモリ、ＤＶＤ（Digital Versatile Disc）等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。
また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、フラッシュメモリ等の書き込み可能な不揮発性メモリ、ＤＶＤ（Digital Versatile Disc）等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。
【0050】
さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムが送信された場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリ（例えばＤＲＡＭ（Dynamic Random Access Memory））のように、一定時間プログラムを保持しているものも含むものとする。
また、上記プログラムは、このプログラムを記憶装置等に格納したコンピュータシステムから、伝送媒体を介して、あるいは、伝送媒体中の伝送波により他のコンピュータシステムに伝送されてもよい。ここで、プログラムを伝送する「伝送媒体」は、インターネット等のネットワーク（通信網）や電話回線等の通信回線（通信線）のように情報を伝送する機能を有する媒体のことをいう。
また、上記プログラムは、前述した機能の一部を実現するためのものであってもよい。さらに、前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるもの、いわゆる差分ファイル（差分プログラム）であってもよい。
また、上記プログラムは、このプログラムを記憶装置等に格納したコンピュータシステムから、伝送媒体を介して、あるいは、伝送媒体中の伝送波により他のコンピュータシステムに伝送されてもよい。ここで、プログラムを伝送する「伝送媒体」は、インターネット等のネットワーク（通信網）や電話回線等の通信回線（通信線）のように情報を伝送する機能を有する媒体のことをいう。
また、上記プログラムは、前述した機能の一部を実現するためのものであってもよい。さらに、前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるもの、いわゆる差分ファイル（差分プログラム）であってもよい。
【符号の説明】
【0051】
１…通信制御装置、１１…リクエスト受信部、１２…リクエスト送信部、１３…優先制御部、１４…リクエスト処理部、１５…Priority設定部、１６…レスポンス処理部、３０…データベース
【図1】
【図2】
【図3】