特許 7613650 ノードをバッチでアップグレードするための方法、関連する装置、およびデバイス

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

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

(11)【特許番号】

(24)【登録日】2025-01-06

(45)【発行日】2025-01-15

(54)【発明の名称】ノードをバッチでアップグレードするための方法、関連する装置、およびデバイス

(51)【国際特許分類】

   H04L 41/082 20220101AFI20250107BHJP

   G06F 9/455 20180101ALI20250107BHJP

   G06F 8/65 20180101ALI20250107BHJP

【ＦＩ】

H04L41/082

G06F9/455 150

G06F8/65

【請求項の数】 15

(21)【出願番号】P 2023541555

(86)(22)【出願日】2021-01-15

(65)【公表番号】

(43)【公表日】2024-01-23

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

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

(87)【国際公開日】2022-07-21

【審査請求日】2023-07-07

(73)【特許権者】

【識別番号】503433420

【氏名又は名称】華為技術有限公司

【氏名又は名称原語表記】ＨＵＡＷＥＩ ＴＥＣＨＮＯＬＯＧＩＥＳ ＣＯ．，ＬＴＤ．

【住所又は居所原語表記】Ｈｕａｗｅｉ Ａｄｍｉｎｉｓｔｒａｔｉｏｎ Ｂｕｉｌｄｉｎｇ， Ｂａｎｔｉａｎ， Ｌｏｎｇｇａｎｇ Ｄｉｓｔｒｉｃｔ， Ｓｈｅｎｚｈｅｎ， Ｇｕａｎｇｄｏｎｇ ５１８１２９， Ｐ．Ｒ． Ｃｈｉｎａ

(74)【代理人】

【識別番号】100107766

【弁理士】

【氏名又は名称】伊東 忠重

(74)【代理人】

【識別番号】100070150

【弁理士】

【氏名又は名称】伊東 忠彦

(74)【代理人】

【識別番号】100135079

【弁理士】

【氏名又は名称】宮崎 修

(72)【発明者】

【氏名】ゴン，ヤンソォン

【審査官】速水 雄太

(56)【参考文献】

【文献】米国特許出願公開第２０２０／０２１８４５３（ＵＳ，Ａ１）

【文献】米国特許出願公開第２０２０／００７３６５５（ＵＳ，Ａ１）

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

Ｈ０４Ｌ １２／００－１２／６６

４１／００－１０１／６９５

Ｇ０６Ｆ ９／４５５

８／６５

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

【請求項1】

コンピュータによって実行される、ノードをバッチでアップグレードする方法であって：
アップグレードのためのバッチ情報を取得する段階であって、アップグレードのための前記バッチ情報は、一つまたは複数のグループを含み、各グループは、バッチに対応し、アップグレードされるべき一つまたは複数のグループ・ノードを含み、前記バッチ情報は、各グループのアップグレード・シーケンスを含む、段階と；
前記アップグレード・シーケンスに基づいて、アップグレードされるべきグループ・ノードを決定する段階と；
前記アップグレードされるべきグループ・ノード上のサービスを別のアップグレードされないノードに移行する段階と；
前記アップグレードされるべきグループ・ノードをアップグレードして、アップグレードされたグループ・ノードにする段階と；
前記別のアップグレードされないノード上のサービスの一部のみを、前記アップグレードされたグループ・ノードに戻す移行をする段階とを含む、
方法。

【請求項2】

各グループ・ノードは、仮想マシンである、請求項１に記載の方法。

【請求項3】

前記別のアップグレードされないノード上のサービスをアップグレードされたグループ・ノードに移行した後、当該方法はさらに：
アップグレード・シーケンスに基づいて次のアップグレードされるべきグループ・ノードを決定する段階と；
前記次のアップグレードされるべきグループ・ノード上のサービスを別のアップグレードされないノードに移行する段階と；
前記次のアップグレードされるべきグループ・ノードをアップグレードする段階とを含む、
請求項１または２に記載の方法。

【請求項4】

前記バッチ情報は、各グループのグループ・ノードのノード・タイプと、各グループのアップグレード・シーケンスに対応する識別子と、各グループ内のノードに対応するノード識別子と、各グループ内の前記ノードに対応するホスト識別子とを含み、
前記アップグレードされるべきグループ・ノードのノード・タイプは、前記別のアップグレードされないノードのノード・タイプと同じである、
請求項１ないし３のうちいずれか一項に記載の方法。

【請求項5】

アップグレードのためのバッチ情報を取得する前に、当該方法は：
ノード・セットを取得する段階であって、前記ノード・セットにおける各ノードが1つのノード・タイプに対応する、段階と；
ノード・バッチ規則セットを取得する段階であって、前記ノード・バッチ規則セットは各ノード・タイプに対応するノード・バッチ規則を含む、段階と；
前記ノード・バッチ規則セットに基づいて前記ノード・セットに対してバッチ化を実行して、アップグレードのための前記バッチ情報を取得する段階とをさらに含む、
請求項１ないし４のうちいずれか一項に記載の方法。

【請求項6】

ノード上で実行されているサービスを決定する段階であって、前記サービスはあるサービス・タイプに対応する、段階と；
前記サービス・タイプに対応するバッチ規則を決定する段階と；
前記サービス・タイプに対応する前記バッチ規則に従って、前記ノード・タイプに対応するノード・バッチ規則を決定する段階とをさらに含む、
請求項５に記載の方法。

【請求項7】

前記アップグレードされるべきグループ・ノード上のサービスを別のアップグレードされないノードに移行する前に、当該方法は：
第1のメッセージを取得する段階をさらに含み、前記第1のメッセージは、前記アップグレードされるべきグループ・ノードがアップグレードされることを示す、
請求項１ないし６のうちいずれか一項に記載の方法。

【請求項8】

前記アップグレードされるべきグループ・ノードをアップグレードする前に、当該方法は：
第2のメッセージを取得する段階をさらに含み、前記第2のメッセージは、前記アップグレードされるべきグループ・ノード上のすべてのサービスが前記別のアップグレードされないノードに移行されたことを示す、
請求項１ないし６のうちいずれか一項に記載の方法。

【請求項9】

前記別のアップグレードされないノード上のサービスをアップグレードされたグループ・ノードに移行する前に、当該方法は：
第3メッセージを取得する段階をさらに含み、前記第3メッセージは、前記アップグレードされるべきグループ・ノードがアップグレードされたことを示す、
請求項２ないし６のうちいずれか一項に記載の方法。

【請求項10】

前記アップグレード・シーケンスに基づいて次のアップグレードされるべきグループ・ノードを決定する前に、当該方法は：
第4のメッセージを取得する段階をさらに含み、前記第4のメッセージは、前記別のアップグレードされないノード上のサービスがアップグレードされた前記グループ・ノードに移行されたことを示す、
請求項３ないし６のうちいずれか一項に記載の方法。

【請求項11】

ノードをバッチでアップグレードする装置であって：
アップグレードのためのバッチ情報を取得するように構成された取得モジュールであって、アップグレードのための前記バッチ情報は、一つまたは複数のグループを含み、各グループは、バッチに対応し、アップグレードされるべき一つまたは複数のグループ・ノードを含み、前記バッチ情報は、各グループのアップグレード・シーケンスを含む、取得モジュールと；
前記アップグレード・シーケンスに基づいて、アップグレードされるべきグループ・ノードを決定するように構成された決定モジュールと；
前記アップグレードされるべきグループ・ノード上のサービスを別のアップグレードされないノードに移行するように構成された移行モジュールと；
前記アップグレードされるべきグループ・ノードをアップグレードして、アップグレードされたグループ・ノードにするように構成されたアップグレード・モジュールとを有しており、
前記移行モジュールは、前記アップグレードされるべきグループ・ノードがアップグレードされた後に、前記別のアップグレードされないノード上のサービスの一部のみを、前記アップグレードされたグループ・ノードに戻す移行をするようにさらに構成されている、
装置。

【請求項12】

各グループ・ノードは、仮想マシンである、請求項１１に記載の装置。

【請求項13】

前記決定モジュールは、前記別のアップグレードされないノード上のサービスがアップグレードされた前記グループ・ノードに移行された後に、前記アップグレード・シーケンスに基づいて、次のアップグレードされるべきグループ・ノードを決定するようにさらに構成されており、
前記移行モジュールは、前記次のアップグレードされるべきグループ・ノード上のサービスを別のアップグレードされないノードに移行するようにさらに構成されており、
前記アップグレード・モジュールは、前記次のアップグレードされるべきグループ・ノードをアップグレードするようにさらに構成されている、
請求項１１または１２に記載の装置。

【請求項14】

ノードをバッチでアップグレードするための当該装置は、バッチ化モジュールをさらに有しており；
前記取得モジュールは、アップグレードのための前記バッチ情報を取得する前にノード・セットを取得するようにさらに構成され、前記ノード・セット内の各ノードは1つのノード・タイプに対応し；
前記取得モジュールは、ノード・バッチ規則セットを取得するようにさらに構成され、前記ノード・バッチ規則セットは、各ノード・タイプに対応するノード・バッチ規則を含み；
前記バッチ化モジュールは、アップグレードのための前記バッチ情報を取得するために、前記ノード・バッチ規則セットに基づいて前記ノード・セットに対してバッチ化を実行するように構成されている、
請求項１１ないし１３のうちいずれか一項に記載の装置。

【請求項15】

コンピュータに請求項１ないし１０のうちいずれか一項に記載の方法を実行させるためのコンピュータ・プログラムを記憶しているコンピュータ可読記憶媒体。

【発明の詳細な説明】

【技術分野】

【0001】

本出願の実施形態は、通信分野に関し、特に、ノードをバッチでアップグレードするための方法、関連する装置、およびデバイスに関する。

【背景技術】

【0002】

ネットワーク・クラウド化の傾向がより明確になるにつれて、第3世代パートナーシッププロジェクト（3rd generation partnership project、3GPP）機関は、欧州電気通信標準化機構（European telecommunications standards institute、ETSI）ネットワーク機能仮想化（network functions virtualization、NFV）アーキテクチャーを立ち上げた。重要な技術として、NFVは通信産業から広く注目されている。上記標準化団体は、NFVに関する詳細な研究を行い、NFVを産業チェーンの複数のフェーズに適用している。実際のネットワークのサービス変更および進化の間、NFVアーキテクチャーにおける仮想化ネットワーク機能（virtualized network function、VNF）レイヤーも、サービス要件に基づいてアップグレードされる必要がある。

【0003】

現在、NFV解決策の実際の展開中に、NFVアーキテクチャーに含まれるネットワーク機能仮想化インフラストラクチャー（network function virtualization infrastructure、NFVI）およびVNFレイヤーは、独立して進化する。したがって、VNFが位置するIレイヤー資源のバッチが事前に手動で編成されてもよく、次いで、Iレイヤー資源は、それらのバッチのシーケンスに基づいて、バッチでアップグレードされる。バッチごとに、サービスが手動で移行され、次いで、対応するIレイヤー・ボードがアップグレードされる。Iレイヤー・ボードがアップグレードされた後、アップグレード前のサービスは手動で元に移行し戻される。

【0004】

しかしながら、サービスを手動で移行する／移行し戻すことによって、各バッチの前／後に操作処理を手動で実行する必要があり、その結果、アップグレード・プロセスが比較的複雑になる。この場合、操作期間は比較的長く、操作プロセス全体に注意を払う必要があり、アップグレード効率は比較的低い。これはサービス品質を低下させる。

【発明の概要】

【発明が解決しようとする課題】

【0005】

本願の実施形態は、ノードをバッチでアップグレードするための方法、関連する装置、およびデバイスを提供し、これらは、ノードをバッチでアップグレードするプロセスにおいて通常のサービスを提供するために使用される。したがって、アップグレード効率が保証されながら、サービス品質が改善される。

【課題を解決するための手段】

【0006】

第1の側面によれば、ノードをバッチでアップグレードするための方法が提供される。バッチでノードをアップグレードする方法は、コンテナ化シナリオで使用される。本方法では、アップグレードのためのバッチ情報は、NFVIアップグレード・ツールまたはNFVIバッチ・アップグレード・ツールを使用することによって取得される。アップグレードのためのバッチ情報は、各グループのアップグレード・シーケンスを含む。次いで、NFVIアップグレード・ツールまたはNFVIバッチ・アップグレード・ツールは、アップグレード・シーケンスに基づいて、アップグレードされるべきグループ・ノードを決定し、VNFMは、アップグレードされるべきグループ・ノード上のサービスを別のアップグレードされないノードに移行する。次いで、NFVIアップグレード・ツールまたはNFVIバッチ・アップグレード・ツールは、アップグレードされるべきグループ・ノードをアップグレードする。

【0007】

この実装では、アップグレードされるべきグループ・ノードがアップグレードされる前に、アップグレードされるべきグループ・ノード上のサービスは、別のアップグレードされないノードに移行される。したがって、アップグレードされるべきグループ・ノードをアップグレードするプロセスにおいて、サービスのために、通常のサービスが提供されることを保証することができる。したがって、アップグレード効率が保証されながら、サービス品質が改善される。

【0008】

第1の側面に関連して、第1の側面の第1の可能な実装において、前記アップグレードされるべきグループ・ノードがアップグレードされた後、VNFMは、前記別のアップグレードされないノード上のサービスを、アップグレードされたグループ・ノードにさらに移行してもよい。

【0009】

この実装では、前記アップグレードされるべきグループ・ノードがアップグレードされた後、前記別のアップグレードされないノード上のサービスは、アップグレードされたグループ・ノードに移行される。したがって、これは、各ノードがサービスを担うことを保証し、サービスのバランスのとれた分配を保証し、それによって、サービス品質を改善する。

【0010】

第1の側面の第1の可能な実装に関連して、第1の側面の第2の可能な実装において、VNFMが前記別のアップグレードされないノード上のサービスをアップグレードされた前記グループ・ノードに移行した後、NFVIアップグレード・ツールまたはNFVIバッチ・アップグレード・ツールは、アップグレード・シーケンスに基づいて次のアップグレードされるべきグループ・ノードをさらに決定してもよい。次いで、VNFMは、該次のアップグレードされるべきグループ・ノード上のサービスを別のアップグレードされないノードに移行し、NFVIアップグレード・ツールまたはNFVIバッチ・アップグレード・ツールは、前記次のアップグレードされるべきグループ・ノードをアップグレードする。

【0011】

この実装では、前記アップグレードされるべきグループ・ノードが一度アップグレードされた後、前記次のアップグレードされるべきグループ・ノード上のサービスが連続的に移行されてもよく、前記次のアップグレードされるべきグループ・ノードがアップグレードされてもよい。これは、アップグレードされる必要があるすべてのグループ・ノードをアップグレードするプロセスにおけるサービスについて通常のサービスが提供されることをさらに保証する。したがって、アップグレード効率が保証されながら、サービス品質が改善される。

【0012】

第1の側面の第2の可能な実装のいずれか1つに関連して、第1の側面の第3の可能な実装において、各グループは、各グループのノード・タイプと、各グループのグループ・シーケンスに対応する識別子と、各グループ内のノードに対応するノード識別子と、各グループ内のノードに対応するホスト識別子とを含む。前記アップグレードされるべきグループ・ノードのノード・タイプは、前記別のアップグレードされないノードのノード・タイプと同じである。

【0013】

この実装では、各グループに含まれる情報がより多様化され、そのため、NFVIアップグレード・ツールまたはNFVIバッチ・アップグレード・ツールは、アップグレードされるべきグループ・ノードをより正確に決定することができる。アップグレードされるべきグループ・ノードのノード・タイプは、別のアップグレードされないノードのノード・タイプと同じであり、そのため、アップグレードされないノードは、移行されたサービスをより良好に担うことができ、それにより、バッチ・アップグレード・プロセスにおけるサービス品質をさらに改善する。

【0014】

第1の側面の第3の可能な実装のいずれか1つに関連して、第1の側面の第4の可能な実装において、NFVIアップグレード・ツールまたはNFVIバッチ・アップグレード・ツールがアップグレードのためのバッチ情報を取得する前に、NFVIバッチ・ツールまたはNFVIバッチ・アップグレード・ツールは、ノード・セットを取得する段階であって、ノード・セット内の各ノードが1つのノード・タイプに対応する、段階と；ノード・バッチ規則セットを取得する段階であって、該ノード・バッチ規則セットは各ノード・タイプに対応するノード・バッチ規則を含む、段階と；前記ノード・バッチ規則セットに基づいて前記ノード・セットに対してバッチ化〔バッチング〕を実行して、アップグレードのための前記バッチ情報を取得する段階とを実行してもよい。

【0015】

この実装では、ノード・タイプに対応するバッチ規則は、ノード・タイプの特徴によって必要とされるバッチ規則を反映することができる。したがって、バッチ化は、ノード・タイプに対応するバッチ規則に従って異なるノード・タイプに対して実行され、そのため、アップグレードのための取得されたバッチ情報に含まれるグループは、より正確でありえ、アップグレードのためのバッチ情報は、各異なるノード・タイプによって必要とされるアップグレード・シーケンスに、より適合される。

【0016】

第1の側面の第4の可能な実装のいずれか1つに関連して、第1の側面の第5の可能な実装では、NFVIバッチ・ツールまたはNFVIバッチ・アップグレード・ツールはさらに、ノード上で実行されるサービスを決定する段階であって、該サービスはあるサービス・タイプに対応する、段階と；次いで、前記サービス・タイプに対応するバッチ規則を決定する段階と；最後に、前記サービス・タイプに対応するバッチ規則に従って、前記ノード・タイプに対応するノード・バッチ規則を決定する段階とを実行する必要がある。

【0017】

この実装では、ノード・タイプに対応するノード・バッチ規則は、ノード上で実行中のサービスに対応するサービス・タイプのバッチ規則に従って決定される。これは、この解決策の実現可能性およびノード・バッチ規則の精度を改善する。

【0018】

第1の側面の第5の可能な実装のいずれか1つに関連して、第1の側面の第6の可能な実装では、VNFMが、前記アップグレードされるべきグループ・ノード上のサービスを前記別のアップグレードされないノードに移行する前に、VNFMは、第1のメッセージをさらに取得してもよく、第1のメッセージは、前記アップグレードされるべきグループ・ノードがアップグレードされることを示す。

【0019】

この実装では、第1のメッセージは、前記アップグレードされるべきグループ・ノードがアップグレードされることを示す。したがって、VNFMは、第1のメッセージを使用することによって、どのノードがアップグレードされるべきグループ・ノードであるかを決定しうる。この場合、VNFMは、アップグレードされるべきグループ・ノード上のサービスを移行する。これは、この解決策の実現可能性および信頼性を改善する。

【0020】

第1の側面の第5の可能な実装のいずれか1つに関連して、第1の側面の第7の可能な実装では、前記アップグレードされるべきグループ・ノードをアップグレードする前に、NFVIアップグレード・ツールまたはNFVIバッチ・アップグレード・ツールは、第2のメッセージをさらに取得してもよく、第2のメッセージは、前記アップグレードされるべきグループ・ノード上のすべてのサービスが前記別のアップグレードされないノードに移行されたことを示す。

【0021】

この実装では、第2のメッセージは、前記アップグレードされるべきグループ・ノード上のすべてのサービスが前記別のアップグレードされないノードに移行されたことを示すので、第2のメッセージを受信した後、NFVIアップグレード・ツールまたはNFVIバッチ・アップグレード・ツールは、前記アップグレードされるべきグループにおいてサービスが担われないことを判別しうる。したがって、サービスに影響することなく、アップグレードされるべきグループ・ノードがアップグレードされることができる。

【0022】

第1側面の第1の可能な実装ないし第1側面の第5の可能な実装のいずれか1つに関連して、第1側面の第8の可能な実装では、前記別のアップグレードされないノード上のサービスをアップグレードされた前記グループ・ノードに移行する前に、VNFMは、第3メッセージをさらに取得してもよく、第3メッセージは、前記アップグレードされるべきグループ・ノードがアップグレードされたことを示す。

【0023】

この実装では、第3のメッセージは、前記アップグレードされるべきグループ・ノードがアップグレードされたことを示すので、VNFMは、第3のメッセージを使用することによって、前記グループ・ノードがアップグレードされたことを判別しうる。この場合、VNFMは、前記別のアップグレードされないノード上のサービスを、アップグレードされた前記グループ・ノードに移行し戻す。これは、この解決策の実現可能性および信頼性を改善する。

【0024】

第1の側面の第2の可能な実装ないし第1の側面の第5の可能な実装のいずれか1つに関連して、第1の側面の第9の可能な実装において、アップグレード・シーケンスに基づいて次のアップグレードされるべきグループ・ノードを決定する前に、NFVIアップグレード・ツールまたはNFVIバッチ・アップグレード・ツールは、第4のメッセージをさらに取得してもよく、第4のメッセージは、前記別のアップグレードされないノード上のサービスがアップグレードされた前記グループ・ノードに移行されたことを示す。前記別のアップグレードされないノード上のいくつかのサービスは、アップグレードされた前記グループ・ノードに移行されるが、すべてのサービスが移行されるわけではなく、この時点ですべてのサービス・ノードがサービスを担うことを確実にすることが理解されうる。

【0025】

この実装では、第4のメッセージは、前記別のアップグレードされないノード上のサービスが前記アップグレードされたグループ・ノードに移行されたことを示すので、第4のメッセージを受信した後、NFVIアップグレード・ツールまたはNFVIバッチ・アップグレード・ツールは、前記アップグレードされたグループ・ノードがアップグレードされ、サービスを担い始めると決定することができる。この場合、すべてのアップグレードされるべきグループ・ノードが順次アップグレードされることを保証するために、次のアップグレードされるべきグループ・ノードがさらに決定されてよい。これは、バッチでノードをアップグレードする効率を改善し、さらに、この解決策の実現可能性および信頼性を改善する。

【0026】

第2の側面によれば、ノードをバッチでアップグレードするための装置が提供され、ノードをバッチでアップグレードするための装置は、コンテナ化シナリオにおいて使用される。ノードをバッチでアップグレードするための装置は、第1の側面および第1の側面の可能な実装のいずれか1つにおけるネットワーク・デバイスを実装する機能の一部または全部を有する。たとえば、装置の機能は、本願におけるネットワーク・デバイスの一部または全部の実施形態における機能を含んでいてもよく、または本願の実施形態のいずれか1つを別個に実装する機能を含んでいてもよい。機能は、ハードウェアによって実装されてもよく、または対応するソフトウェアを実行するハードウェアによって実装されてもよい。ハードウェアまたはソフトウェアは、機能に対応する一つまたは複数のユニットまたはモジュールを含む。

【0027】

ある実装では、ノードをバッチでアップグレードするための装置は
アップグレードのためのバッチ情報を取得するように構成された取得モジュールであって、前記アップグレードのためのバッチ情報は、各グループのアップグレード・シーケンスを含む、取得モジュールと；
前記アップグレード・シーケンスに基づいて、アップグレードされるべきグループ・ノードを決定するように構成された決定モジュールと；
前記アップグレードされるべきグループ・ノード上のサービスを別のアップグレードされないノードに移行するように構成された移行モジュールと；
前記アップグレードされるべきグループ・ノードをアップグレードするように構成されたアップグレード・モジュールとを含む。

【0028】

ある可能な実装では、前記移行モジュールは、前記アップグレードされるべきグループ・ノードがアップグレードされた後に、前記別のアップグレードされないノード上のサービスを、アップグレードされたグループ・ノードに移行するようにさらに構成される。

【0029】

ある可能な実装では、前記決定モジュールは、前記別のアップグレードされないノード上のサービスがアップグレードされたグループ・ノードに移行された後に、前記アップグレード・シーケンスに基づいて次のアップグレードされるべきグループ・ノードを決定するようにさらに構成される。

【0030】

前記移行モジュールは、前記次のアップグレードされるべきグループ・ノード上のサービスを別のアップグレードされないノードに移行するようにさらに構成される。

【0031】

前記アップグレード・モジュールは、前記次のアップグレードされるべきグループ・ノードをアップグレードするようにさらに構成される。

【0032】

ある可能な実装では、各グループは、各グループのノード・タイプと、各グループのグループ・シーケンスに対応する識別子と、各グループ内のノードに対応するノード識別子と、各グループ内の前記ノードに対応するホスト識別子とを含む。

【0033】

前記アップグレードされるべきグループ・ノードのノード・タイプは、前記別のアップグレードされないノードのノード・タイプと同じである。

【0034】

ある可能な実装では、ノードをバッチでアップグレードするための装置は、バッチ化モジュールをさらに含む。

【0035】

前記取得モジュールは、アップグレードのための前記バッチ情報を取得する前にノード・セットを取得するようにさらに構成され、前記ノード・セット内の各ノードは1つのノード・タイプに対応する。

【0036】

前記取得モジュールは、ノード・バッチ規則セットを取得するようにさらに構成され、前記ノード・バッチ規則セットは、各ノード・タイプに対応するノード・バッチ規則を含む。

【0037】

前記バッチ化モジュールは、アップグレードのための前記バッチ情報を取得するために、前記ノード・バッチ規則セットに基づいて前記ノード・セットに対してバッチ化を実行するように構成される。

【0038】

ある可能な実装では、前記決定モジュールは、ノード上で実行中のサービスを決定するようにさらに構成され、前記サービスはあるサービス・タイプに対応する。

【0039】

前記決定モジュールは、前記サービス・タイプに対応するバッチ規則を決定するようにさらに構成される。

【0040】

前記決定モジュールは、前記サービス・タイプに対応する前記バッチ規則に従って、前記ノード・タイプに対応するノード・バッチ規則を決定するようにさらに構成される。

【0041】

ある可能な実装では、前記取得モジュールは、前記アップグレードされるべきグループ・ノード上の前記サービスが前記別のアップグレードされないノードに移行される前に、第1のメッセージを取得するようにさらに構成される。前記第1のメッセージは、前記アップグレードされるべきグループ・ノードがアップグレードされることを示す。

【0042】

ある可能な実装では、前記取得モジュールは、前記アップグレードされるべきグループ・ノードがアップグレードされる前に、第2のメッセージを取得するようにさらに構成される。前記第2のメッセージは、前記アップグレードされるべきグループ・ノード上のすべてのサービスが前記別のアップグレードされないノードに移行されることを示す。

【0043】

ある可能な実装では、前記取得モジュールは、前記別のアップグレードされないノード上の前記サービスがアップグレードされたグループ・ノードに移行される前に、第3のメッセージを取得するようにさらに構成される。前記第3のメッセージは、前記アップグレードされるべきグループ・ノードがアップグレードされたことを示す。

【0044】

ある可能な実装では、前記取得モジュールは、前記アップグレード・シーケンスに基づいて前記次のアップグレードされるべきグループ・ノードが決定される前に、第4のメッセージを取得するようにさらに構成される。前記第4のメッセージは、前記別のアップグレードされないノード上の前記サービスが、アップグレードされたグループ・ノードに移行されたことを示す。

【0045】

第3の側面によれば、プロセッサを含む、ノードをバッチでアップグレードするための装置が提供される。プロセッサは、メモリに結合され、第1の側面の任意の可能な実装による方法を実施するために、メモリ内の命令を実行するように構成されうる。任意的に、通信装置は前記メモリをさらに含む。任意的に、通信装置は、通信インターフェースをさらに含む。プロセッサは、通信インターフェースに結合される。通信インターフェースは、情報を入力および／または出力するように構成される。情報は、命令およびデータのうちの少なくとも1つを含む。

【0046】

ある実装では、前記通信装置はネットワーク・デバイスである。通信装置がネットワーク・デバイスである場合、通信インターフェースは、トランシーバまたは入力／出力インターフェースであってもよい。

【0047】

任意的に、トランシーバはトランシーバ回路であってもよい。任意的に、入力／出力インターフェースは、入力／出力回路であってもよい。

【0048】

別の実装では、通信装置は、ネットワーク・デバイス内に配置されたチップまたはチップ・システムである。通信装置がネットワーク・デバイス内に配置されたチップまたはチップ・システムである場合、通信インターフェースは、入力／出力インターフェース、インターフェース回路、出力回路、入力回路、ピン、関連回路などであってもよい。プロセッサは、代替的に、処理回路または論理回路として具現されてもよい。

【0049】

第4の側面によれば、入力回路と、出力回路と、処理回路とを含むプロセッサが提供される。処理回路は：プロセッサが第1の側面の任意の可能な実装形態による方法を実行するように、入力回路を介して信号を受信し、出力回路を介して信号を送信するように構成される。

【0050】

ある特定の実装プロセスでは、プロセッサはチップであってもよく、入力回路は入力ピンであってもよく、出力回路は出力ピンであってもよく、処理回路はトランジスタ、ゲート回路、トリガー、さまざまな論理回路などであってもよい。入力回路によって受信される入力信号は、たとえば限定されないが受信機によって受信および入力されてもよく、出力回路によって出力される信号は、たとえば限定されないが送信機に出力され、該送信機によって送信されてもよく、入力回路および出力回路は、同じ回路であってもよく、その回路は、異なる瞬間に入力回路および出力回路として使用される。プロセッサおよびさまざまな回路の特定の実装は、本願の実施形態において限定されない。

【0051】

第5の側面によれば、通信インターフェースおよびプロセッサを含む、ノードをバッチでアップグレードするための装置が提供される。通信インターフェースは、プロセッサに結合される。通信インターフェースは、情報を入力および／または出力するように構成される。情報は、命令およびデータのうちの少なくとも1つを含む。プロセッサは、コンピュータ・プログラムを実行するように構成され、それにより、ノードをバッチでアップグレードするための装置は、第1の側面の任意の可能な実装による方法を実行する。

【0052】

任意的に、一つまたは複数のプロセッサがあり、一つまたは複数のメモリがある。

【0053】

第6の側面によれば、プロセッサおよびメモリを含む、ノードをバッチでアップグレードするための装置が提供される。プロセッサは、メモリに記憶された命令を読み取るように構成され、装置が第1の側面の任意の可能な実装による方法を実行するように、受信機を通じて信号を受信し、送信機を通じて信号を送信してもよい。

【0054】

任意的に、一つまたは複数のプロセッサがあり、一つまたは複数のメモリがある。

【0055】

任意的に、メモリはプロセッサと統合されてもよく、またはメモリおよびプロセッサは別々に配置される。

【0056】

ある特定の実装プロセスでは、メモリは、非一時的（non-transitory）メモリ、たとえば、読み出し専用メモリ（read-only memory、ROM）であってもよい。メモリおよびプロセッサは、1つのチップに統合されてもよく、または異なるチップに別々に配置されてもよい。メモリのタイプ、ならびにメモリおよびプロセッサが配置される仕方は、本願の実施形態において限定されない。

【0057】

関連情報交換プロセスにおいて、たとえば、メッセージを送信することは、プロセッサからメッセージを出力するプロセスであってもよく、メッセージを受信することは、受信されたメッセージをプロセッサに入力するプロセスであってもよいことが理解されるべきである。具体的には、プロセッサによって出力される情報は送信機に出力されてもよく、プロセッサによって受信される入力情報は受信機からのものであってもよい。送信機および受信機は、トランシーバと総称されることがある。

【0058】

第5の側面および第6の側面におけるノードをバッチでアップグレードする装置は、チップであってもよい。プロセッサは、ハードウェアによって実装されてもよいし、ソフトウェアによって実装されてもよい。プロセッサがハードウェアによって実装される場合、プロセッサは、論理回路、集積回路などであってもよい。プロセッサがソフトウェアによって実装されるとき、プロセッサは、汎用プロセッサであってもよく、メモリに記憶されたソフトウェア・コードを読み取ることによって実装される。メモリは、プロセッサに統合されてもよく、プロセッサの外部に配置され、独立して存在してもよい。

【0059】

第7の側面によれば、コンピュータ・プログラム・プロダクトが提供される。コンピュータ・プログラム・プロダクトは、コンピュータ・プログラム（コードまたは命令と呼ばれることもある）を含む。コンピュータ・プログラムが実行されると、コンピュータは、第1の側面の任意の可能な実装による方法を実行することが可能にされる。

【0060】

第8の側面によれば、コンピュータ可読記憶媒体が提供される。コンピュータ可読記憶媒体は、コンピュータ・プログラム（コードまたは命令と呼ばれることもある）を記憶する。コンピュータ・プログラムがコンピュータ上で実行されると、コンピュータは、第1の側面の任意の可能な実装による方法を実行することが可能にされる。

【0061】

第9の側面によれば、本願はチップ・システムを提供する。チップ・システムは、プロセッサおよびインターフェースを含む。インターフェースは、プログラムまたは命令を取得するように構成される。プロセッサは、該プログラムまたは命令を呼び出して、第1の側面における機能を実装する際に、たとえば前述の方法におけるデータおよび情報のうちの少なくとも1つを決定または処理する際に、ネットワーク・デバイスを実装またはサポートするように構成される。

【0062】

ある可能な設計では、チップ・システムはメモリをさらに含む。メモリは、ネットワーク・デバイスにとって必要なプログラム命令およびデータを記憶するように構成される。チップ・システムは、チップを含んでいてもよく、またはチップおよび別の離散的コンポーネントを含んでいてもよい。

【0063】

本願の第2の側面ないし第9の側面の実装によってもたらされる有益な効果は、第1の側面の実装を参照して理解されうることに留意されたい。したがって、詳細は繰り返さない。

【図面の簡単な説明】

【0064】

【図1】本願のある実施形態によるNFVアーキテクチャーの概略図である。

【0065】

【図2A】本願のある実施形態による、ノードをバッチでアップグレードするための方法の概略図の前半である。

【図2B】本願のある実施形態による、ノードをバッチでアップグレードするための方法の概略図の後半である。

【0066】

【図3】本願のある実施形態による、ノード・セットを取得することのフローチャートである。

【0067】

【図4】本願のある実施形態による、ノード・セットを取得することの別のフローチャートである。

【0068】

【図5】本願のある実施形態による、ノード・バッチ規則セットを取得することのフローチャートである。

【0069】

【図6】本願のある実施形態による、ノード・バッチ規則セットを取得することの別のフローチャートである。

【0070】

【図7】本願のある実施形態によるサービス移行のフローチャートである。

【0071】

【図8】本願のある実施形態によるサービス移行の概略図である。

【0072】

【図9A】本願のある実施形態による、ノードをバッチでアップグレードするための別の方法の概略図の前半である。

【図9B】本願のある実施形態による、ノードをバッチでアップグレードするための別の方法の概略図の後半である。

【0073】

【図10】本願のある実施形態による、ノードをバッチでアップグレードするための装置の概略図である。

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

【0074】

以下は、本願の実施形態における添付の図面を参照して、本願の実施形態における技術的解決策を明確かつ完全に説明する。説明される実施形態は、本願の実施形態の全部ではなく、単に一部であることは明らかである。本願の実施形態の理解を容易にするために、以下の説明が提供される。

【0075】

（1）以下に示される実施形態において、技術的特徴について、「第1」、「第2」、「第3」などは、前記技術的特徴において諸技術的特徴の間で区別するために使用される。「第1」、「第2」、および「第3」によって記述される技術的特徴の間に、逐次順またはサイズの順序はない。

【0076】

（2）「少なくとも1つ」は、一つまたは複数を意味し、「複数」は、2つ以上を意味する。「および／または」は、関連付けられたオブジェクト間の関連付け関係を記述し、3つの関係が存在しうることを表す。たとえば、Aおよび／またはBは、以下の場合を表しうる：Aのみが存在、AとBの両方が存在、Bのみが存在、ここでAおよびBは単数または複数でありうる。記号「／」は、概して、関連付けられたオブジェクト間の「または」関係を示す。「以下の項目（ピース）のうちの少なくとも1つ」またはその類似表現は、単一の項目（ピース）または複数の項目（ピース）の任意の組み合わせを含む、これらの項目の任意の組み合わせを指す。たとえば、a、b、およびcのうちの少なくとも1つは、a、b、c、aとb、aとc、bとc、またはaとbとcを表してもよく、ここで、a、b、cはそれぞれ、単数または複数でありうる。

【0077】

（3）本願の側面、実施形態、または特徴は、複数のデバイス、コンポーネント、モジュールなどを含むシステムを記述することによって、本願において開示される実施形態において提示される。各システムは、別のデバイス、コンポーネント、モジュールなどを含んでいてもよく、および／または添付の図面を参照して説明されるすべてのデバイス、コンポーネント、モジュールなどを含まなくてもよいことが理解されるべきである。さらに、これらの解決策の組み合わせが使用されてもよい。

【0078】

（4）本願の実施形態では、「の（of）」、「関連する（relevant）」、および「対応する（corresponding）」は、交換可能に使用される場合がある。なお、これらの用語によって表される意味は、相違点が強調されない場合には、整合していることに注意しておくべきである。

【0079】

本願の実施形態において開示される、ノードをバッチでアップグレードするための方法、関連する装置、およびデバイスをより良く理解するために、本願の実施形態において説明されるノードは、仮想マシン（virtual machine、VM）またはベアメタルであってもよい。以下では、まず、本発明の実施形態において使用される標準的なアーキテクチャーについて説明する。NFVは、主に、ネットワーク・クラウド化のための業界における共通標準のために使用される。現代のインターネット技術（Internet technology、IT）仮想化技術に基づいて、コストを削減し、効率を改善し、機敏性を高めるために、新しいネットワーク製品環境が提供される。x86などのユニバーサルなハードウェアおよび仮想化技術が、ネットワークの高いデバイス・コストを低減するために、複数の機能のソフトウェア処理をサポートするように使用される。ソフトウェアおよびハードウェアの分離および機能抽象化が使用されてもよい。このようにして、ネットワーク・デバイス機能は、もはや専用ハードウェアに依存しない。資源は完全かつ柔軟に共有できる。新しいサービスが迅速に開発され、展開される。実際のサービス要件に基づいて、自動配備、柔軟なスケーリング、障害隔離、自己修復などが実行される。仮想化技術では、電気通信ネットワーク機能は、ソフトウェアの形で実装され、汎用サーバーのハードウェア上で実行でき、必要に応じてネットワークの異なる物理的位置に移行、インスタンス化、および展開されることができ、新しいデバイスを設置する必要がない。

【0080】

NFV標準化は、主に、ネットワーク・サービス、仮想化ネットワーク機能、および仮想化資源の管理および編成〔オーケストレーション〕に焦点を当てている。一般に、ETSIにおけるNFVインターフェースおよびアーキテクチャー・グループ・ワーキング・グループは、仮想資源の管理およびオーケストレーション（management and orchestration、MANO）フレームワークにおける機能定義を完了する。図1は、本願の実施形態によるNFVアーキテクチャーの概略図である。NFVアーキテクチャーは、複数のネットワーク、たとえば、ローカルエリアネットワーク（local area network、LAN）、インターネットプロトコル（internet protocol、IP）ネットワーク、進化型パケットコア（evolved packet core、EPC）ネットワーク等を実装してもよい。NFVアーキテクチャーは、NFVIと、VNFと、仮想化インフラストラクチャーマネージャ（virtualized infrastructure manager、VIM）と、仮想ネットワーク機能マネージャ（virtual network function manager、VNFM）とを含みうる。NFVIは、仮想機能をホストし、接続するために使用される資源のグループである。具体的には、NFVIは、サーバー、仮想化された管理プログラム（ハイパーバイザー）、オペレーティング・システム、仮想マシン、仮想スイッチ、およびネットワーク資源を含むクラウド・データ・センターである。VIMは、FusionSphereおよびVMwareなどのインフラストラクチャー資源（コンピューティング資源、ストレージ資源、およびネットワーク資源を含む）を管理および監視する。VNFMは、展開機能、スケールアウトおよびスケールイン機能、オンラインおよびオフライン機能、ならびにアップグレード機能などの自動化機能を含むがこれらに限定されないVNFのライフサイクルを管理し、テンプレートおよびVNF容量要件に基づいて仮想マシンなどの仮想資源の要件を、分解によって取得し、VNFおよびVIMと協働して、VNFをインスタンス化する機能を完了することなどができる。コンテナ化シナリオ（たとえば、VMコンテナまたはベアメタル・コンテナ）では、VNFMは、サービスとしてのコンテナ（container as a service、CaaS）マネージャとさらに協働して、VNFをインスタンス化する機能を完了することなどしてもよい。VNFは、より低い機能レベルの一つまたは複数のVNFコンポーネント（VNF component、VNFC）を含む。さらに、1つのVNFが複数のVM上に展開されてもよく、各VMは1つのVNFCの機能を担う。VNFは、代替的に、1つのVM上に展開されうる。

【0081】

加えて、本願の実施形態は、クラウドコンピューティング（Cloud Computing）をさらに開示する。クラウドコンピューティングは、インターネット上の異種の自律的なサービスを使用することによって個人および企業ユーザーにオンデマンド・コンピューティングを提供する新しいインターネット・ベースのコンピューティング態様である。資源がインターネット上にあり、インターネットはフローチャートではしばしば雲〔クラウド〕のように表されるので、このインターネット・ベースのコンピューティング態様はクラウドになぞらえられる。インターネットを通じて提供されるクラウドコンピューティング資源は、動的にスケーラブルであり、仮想化される。端末は、「クラウド」内のインフラストラクチャーの詳細を知り、対応する専門知識を有したり、またはインフラストラクチャーを直接制御したりする必要がない。代わりに、端末は、端末が実際に必要とする特定の資源と、どうやってネットワークを介してサービスを取得するかに集中するだけでよい。クラウドコンピューティングは、サービスとしてのインフラストラクチャー（infrastructure as a service、IaaS）、サービスとしてのプラットフォーム（platform as a service、PaaS）、およびサービスとしてのソフトウェア（software as a service、SaaS）の3つのレベルのサービスを含む。PaaSは、サーバー・プラットフォームをサービスとして提供する商用態様である。PaaSは、実際には、SaaS態様でユーザーに提供されるサービスとしてソフトウェア開発プラットフォームが用いられることを意味する。コンテナは、オペレーティングシステム・レベルの仮想化技術であり、CaaSの略称である。CaaSは、サービスとしてのプラットフォーム（platform as a service、PaaS）サービスの特定のタイプである。コンテナは、LinuxにおけるCGroupおよびNameSpaceなどのオペレーティング・システム分離技術を使用することによって、異なるプロセスを分離する。ハードウェア仮想化技術とは異なり、コンテナ技術は仮想ハードウェアを有さず、オペレーティング・システムはなく、コンテナ内部のプロセスのみが存在する。コンテナ技術のこの特徴のおかげで、コンテナは、仮想マシンと比較して、より軽量であり、管理がより容易である。管理を容易にするために、コンテナの実行状態において、コンテナのライフサイクルを統一された方法で管理するよう、コンテナの開始、停止、一時停止、および削除などの一般的な管理動作のグループが定義される。

【0082】

現在のNFV解決策の実際の展開中に、NFVアーキテクチャーに含まれるNFVIおよびVNFレイヤーは、独立して進化する。したがって、VNFが位置するIレイヤー資源の諸バッチが、事前に手動で編成されてもよく、次いで、それらのIレイヤー資源は、それらのバッチのシーケンスに基づいて、諸バッチにおいてアップグレードされる。バッチごとに、サービスが手動で移行され、次いで、対応するIレイヤー・ボードがアップグレードされる。Iレイヤー・ボードがアップグレードされた後、アップグレード前のサービスは手動で移行し戻される。しかしながら、サービスを手動で移行する／移行し戻すことによって、各バッチの前／後に操作処理を手動で実行される必要があり、その結果、アップグレード・プロセスが比較的複雑になる。この場合、操作期間は比較的長く、動作プロセス全体に注意を払う必要があり、アップグレード効率は比較的低い。これはサービス品質を低下させる。

【0083】

前述の問題を解決するために、本願の実施形態は、ノードをバッチでアップグレードするための方法を提供する。本方法は、コンテナ化シナリオにおいて使用され、サービスの正常な提供を保証し、ノードをバッチでアップグレードするプロセスにおいてサービス品質を改善するために使用される。

【0084】

本願のこの実施形態では、ノード・バッチ化機能を実行するためのツールはNFVIバッチ・ツールであり、ノード・アップグレード機能を実行するためのツールはNFVIアップグレード・ツールである。NFVIバッチ・ツールおよびNFVIアップグレード・ツールは、バッチ化およびノード・アップグレードを別々に実行するための異なるツールであってもよい。NFVIバッチ・ツールおよびNFVIアップグレード・ツールは代替的に、ノード・バッチ化およびノード・アップグレードの機能を共同で実行するためのツール（NFVIバッチ・アップグレード・ツール）として統合されてもよい。以下では、上記の2つのケースを別々に説明する。

【0085】

1. NFVIバッチ・ツールとNFVIアップグレード・ツールは異なるツールである。

【0086】

図2Aおよび図2Bは、本願のある実施形態による、ノードをバッチでアップグレードするための方法の概略図である。図2Aおよび図2Bに示されるように、ノードをバッチでアップグレードするための方法は、以下のステップを含む。

【0087】

S101：NFVIバッチ・ツールがノード・セットを取得する。

【0088】

この実施形態では、NFVIバッチ・ツールはノード・セットを取得し、ノード・セット内の各ノードは1つのノード・タイプに対応する。実際の適用では、ノード・セット内の各ノードは、ノード識別子、ノード名、およびホスト識別子にさらに対応してもよいことを理解されたい。したがって、各ノードに対応する情報は、実際の状況に基づいて柔軟に決定されるべきである。

【0089】

具体的には、NFVIバッチ・ツールは、2つの態様でノード・セットを取得する。一方の態様では、NFVIバッチ・ツールは、ノード・セットを直接取得する。他方の態様では、EMSは、ノード・セットを取得し、取得されたノード・セットをNFVIバッチ・ツールに配信し、それにより、NFVIは、ノード・セットを取得する。したがって、アップグレードのためのバッチ情報を取得する前述の2つの異なる態様は、以下で別々に説明される。

【0090】

（1）NFVIバッチ・ツールは、ノード・セットを直接取得する。

【0091】

理解を容易にするために、図3を参照されたい。図3は、本願のある実施形態による、ノード・セットを取得することのフローチャートである。図3に示されるように、ステップS201において、NFVIバッチ・ツールは、アップグレードされる必要があるノードのノード情報についてVIMに能動的に問い合わせる。ステップS202において、VIMは、インフラストラクチャー・レイヤー資源を管理および監視することによってノード情報を取得し、NFVIバッチ・ツールがノード・セットを取得するように、取得されたノード情報を含むノード・セットをNFVIバッチ・ツールに送信する。

【0092】

たとえば、表1を参照されたい。表1は、ノードが仮想マシンであるノード・セットの例であり、ノード・セット内の各ノードは、ノード・タイプ（Node-Type）、ノード識別子（Node-Id）、ノード名（Node-Name）、およびホスト識別子（Host-Id）に対応する。

【表1】

【0093】

ノード名が「OMU-1」および「OMU-2」であるノードに対応するノード・タイプは、「OMU_VM」である。ノード識別子が「vm-spu-id-1」、「vm-spu-id-2」、「vm-spu-id-3」および「vm-spu-id-4」であるノードに対応するノード・タイプは、「SPU_VM」である。ホスト識別子が「host-cpu-id-1」および「host-cpu-id-2」であるノードに対応するノード・タイプは「CPU_VM」である。したがって、各ノードに対応するノード識別子、ノード名、およびホスト識別子が異なることがわかる。しかしながら、異なるノードが同じノード・タイプであってもよい。表1の例は、この解決策を理解するために使用されるにすぎないことを理解されたい。各ノードに対応する具体的な情報は、実際の状況に基づいて柔軟に決定されるべきである。

【0094】

（2）NFVIバッチ・ツールは、EMSを使用することによってノード・セットを取得する。

【0095】

理解を容易にするために、図4を参照されたい。図4は、本願のある実施形態による、ノード・セットを取得すること別のフローチャートである。図4に示されるように、ステップS301において、オペレータは、VNFMを介してEMSを使用することによって、アップグレードされる必要があるノードのノード情報についてVIMに問い合わせる。ステップS302において、VIMは、インフラストラクチャー・レイヤー資源を管理および監視することによってノード情報を取得し、取得されたノード情報を含むノード・セットをEMSに送信する。次いで、ステップS303において、ノード・セットは、EMSを使用することによって、VNFMを介してVIMに送達される。次いで、VIMはノード・セットをNFVIバッチ・ツールに送信し、それにより、NFVIバッチ・ツールがノード・セットを取得する。

【0096】

図3および図4の例は、この解決策を理解するために使用されるにすぎないことを理解されたい。ノード・セットを取得するための具体的な手順は、実際の状況に従って柔軟に決定されるべきである。

【0097】

S102：NFVIバッチ・ツールは、ノード・バッチ規則セットを取得する。

【0098】

この実施形態では、NFVIバッチ・ツールは、ノード・バッチ規則セットを取得し、ノード・バッチ規則セットは、各ノード・タイプに対応するノード・バッチ規則を含む。具体的には、ノード・バッチ規則は、ノード・タイプの優先度、ノード・タイプの数量閾値、およびノード・タイプのパーセンテージ閾値を含んでいてもよいが、これらに限定されない。たとえば、ノード・タイプAはプレバッチにおいてリセットされる、1つのノード・タイプAのみが各バッチにおいてリセットされる、ノード・タイプBについての最大リセット・パーセンテージは50%である、ノード・タイプCはポストバッチにおいてリセットされる、などである。特定のノード・バッチ規則は、ここでは限定されない。

【0099】

任意的に、若干数のノード・タイプがあるとき、すなわち、ノード・バッチ規則セットに含まれる各ノード・タイプに対応する若干数のノード・バッチ規則もあるとき、ノード・バッチ規則セットは、手動で直接決定されてもよい。具体的には、図5を参照されたい。図5は、本願のある実施形態による、ノード・バッチ規則セットを取得することのフローチャートである。図5に示されるように、ステップS401において、オペレータは、VNFMを介してEMSを使用することによって、決定されたノード・バッチ規則セットをVIMに送達する。次いで、VNFMは、ノード・バッチ規則セットをNFVIバッチ・ツールに送信し、それにより、NFVIバッチ・ツールがノード・バッチ規則セットを取得する。

【0100】

たとえば、表2を参照されたい。表2は、ノードが仮想マシンである場合のバッチ規則の例である。

【表2】

【0101】

ノード・タイプ「OMU_VM」に対応するバッチ規則は、「PreBatch&OnlyOneEachBatch」である。すなわち、ノード・タイプ「OMU_VM」に対応するノードは、プレバッチにおいてリセットされる必要があり、各バッチにおいて1つのノードのみがリセットされる。ノード・タイプ「SPU_VM」に対応するバッチ規則は、「MultipleEachBatch&50%」である。すなわち、各バッチ内のノード・タイプ「SPU_VM」に対応するノードの最大リセット・パーセンテージは50%である。たとえば、ノード・タイプ「SPU_VM」に対応するノードが4つある場合、各バッチの最大リセット・パーセンテージは50%であるので、各バッチ内のノード・タイプ「SPU_VM」に対応するノードの最大数は2である。すなわち、ノード・タイプ「SPU_VM」に対応する1つまたは2つのノードが各バッチにおいてリセットされることができる。ノード・タイプ「CPU_VM」に対応するバッチ規則は、「PostBatch&OnlyOneEachBatch」である。すなわち、ノード・タイプ「CPU_VM」に対応するノードは、ポストバッチにおいてリセットされる必要があり、各バッチにおいて1つのノードのみがリセットされる。表2の例は、この解決策を理解するために使用されるにすぎないことを理解されたい。ノード・タイプに対応する特定のバッチ規則は、実際の状況に基づいて柔軟に決定されるべきである。

【0102】

また、複数のノード・タイプがある場合、ノード・バッチ規則セットは、手動で直接決定することができない。具体的には、図6を参照されたい。図6は、本願のある実施形態によるノード・バッチ規則セットを取得することの別のフローチャートである。図6に示されるように、ステップS501において、NFVIバッチ・ツールは、EMSを使用することによってVNFからノード・バッチ規則セットを問い合わせて取得することを含むことができるが、これに限定されない。ステップS502では、VNFは、サービスとノードとの間の対応関係をEMSに送信する。ステップS503では、EMSは、サービスとノードとの間の対応関係を取得して決定し、ここで、サービスとノードとの間の対応関係は、サービス・タイプとノードとの間の対応関係を含む。次いで、ステップS503では、EMSは、サービス・タイプに対応するバッチ規則を決定する。ノード・セット内の各ノードが1つのノード・タイプに対応するので、ステップS504において、EMSは、サービスとノードとの間の対応関係に基づいて、ノード・タイプに対応するバッチ規則を決定することができる。次いで、ステップS505において、EMSは、ノード・セットに含まれるノード・タイプに基づいて、各ノード・タイプに対応するノード・バッチ規則を含むノード・バッチ規則セットを取得し、ノード・バッチ規則セットをNFVIバッチ・ツールに送達する。

【0103】

具体的には、サービスとノードとの間の対応関係は、サービス識別子、サービス・タイプ、ノード識別子、およびノード・タイプを含むが、これらに限定されない。理解を容易にするために、表3を参照されたい。表3は、ノードが仮想マシンである場合のサービスとノードとの間の対応関係の一例である。対応関係は、各サービスに対応するサービス識別子（Pod-Id）およびサービスタイプ（Pod-Type）と、各ノードに対応するノード識別子（Node-Id）およびノード・タイプ（Node-Type）とを含む。

【表3】

【0104】

サービス・タイプが「om-pod」であるサービスは、ノード・タイプが「OMU_VM」であるノードに対応する。サービス・タイプが「sp-pod」であるサービスは、ノード・タイプが「SPU_VM」であるノードに対応する。サービス・タイプが「cp-pod」であるサービスは、ノード・タイプが「CPU_VM」であるノードに対応する。したがって、各ノードに対応するノード識別子および各サービスに対応するサービス識別子は異なるが、異なるノードが同じノード・タイプでありうることがわかる。同じノード・タイプは、同じサービス・タイプに対応する。

【0105】

表4は、ノードが仮想マシンである場合のバッチ規則の例である。

【表4】

【0106】

サービス・タイプ「om-pod」に対応するバッチ規則は、「PreBatch&OnlyOneEachBatch」である。すなわち、サービス・タイプ「om-pod」に対応するノードは、プレバッチにおいてリセットされる必要があり、各バッチにおいて1つのノードのみがリセットされる。サービス・タイプ「sp-pod」に対応するバッチ規則は、「MultipleEachBatch&50%」である。すなわち、各バッチにおけるサービス・タイプ「sp-pod」に対応するノードの最大リセット・パーセンテージは、50%である。たとえば、サービス・タイプ「sp-pod」に対応する6つのノードが存在する場合、各バッチの最大リセット・パーセンテージは50%であるので、各バッチにおけるサービス・タイプ「sp-pod」に対応するノードの最大数は3である。すなわち、サービス・タイプ「sp-pod service」に対応する1つ、2つ、または3つのノードが、各バッチにおいてリセットされてもよい。次いで、サービス・タイプ「cp-pod」に対応するバッチ規則は、「PostBatch&OnlyOneEachBatch」である。すなわち、サービス・タイプ「cp-pod」に対応するノードは、ポストバッチにおいてリセットされる必要があり、各バッチにおいて1つのノードのみがリセットされる。

【0107】

表3および表4の例は、この解決策を理解するために使用されるにすぎないことを理解されたい。サービスとノードとの間の特定の対応関係、およびサービス・タイプに対応する特定のバッチ規則は、実際の状況に基づいて柔軟に決定されるべきである。

【0108】

S103：NFVIバッチ・ツールは、ノード・バッチ規則セットに基づいてノード・セットに対してバッチ化を実行して、アップグレードのためのバッチ情報を取得する。

【0109】

この実施形態では、ステップS101およびステップS102を使用することによってノード・バッチ規則セットおよびノード・セットを取得した後、NFVIバッチ・ツールは、ノード・バッチ規則セットに基づいてノード・セットに対してバッチ化を実行して、アップグレードのためのバッチ情報を取得することができる。具体的には、アップグレードのためのバッチ情報は、各グループのアップグレード・シーケンスを含む。実際の適用において、アップグレードのためのバッチ情報は、各グループのノード・タイプ、各グループのグループ・シーケンスに対応する識別子、各グループ内のノードに対応するノード識別子、および各グループ内のノードに対応するホスト識別子をさらに含んでいてもよいが、これらに限定されない。アップグレードのための特定のバッチ情報は、本願のこの実施形態の限定として理解されるべきではない。

【0110】

理解を容易にするために、説明のための例として、ノード・セットを表1に示し、ノード・バッチ規則セットを表2に示す。表1から、ノード・セットに含まれるノード・タイプは、「OMU_VM」、「SPU_VM」および「CPU_VM」であることがわかる。表2に示されるように、ノード・タイプ「OMU_VM」に対応するノードは、プレバッチにおいてリセットされる必要があり、各バッチにおいて1つのノードのみがリセットされ、各バッチにおけるノード・タイプ「SPU_VM」に対応するノードについての最大リセット・パーセンテージは50%であり、ノード・タイプ「CPU_VM」に対応するノードは、ポストバッチにおいてリセットされる必要があり、各バッチにおいて1つのノードのみがリセットされる必要がある。したがって、アップグレードのためのバッチ情報を取得するために、前述のノード・バッチ規則セットに基づいてノード・セットに対してバッチ化が実行されうる。

【0111】

具体的には、「OMU_VM」に対応するノードはプレバッチにおいてリセットされる必要があり、各バッチにおいて1つのノードのみがリセットされるので、ノード・タイプ「OMU_VM」に対応する「vm-omu-id-1」および「vm-omu-id-2」としてのノード識別子を有する2つのノードは、同じバッチにおいてリセットされることができず、両方ともプレバッチにおいてリセットされる必要がある。すなわち、ノード識別子「vm-omu-id-1」および「vm-omu-id-2」に対応するノードは、より高いランキングを有するアップグレード・バッチに別々にバッチ化される。次いで、各バッチにおける「SPU_VM」に対応するノードについての最大リセット・パーセンテージは50%であり、ノード・タイプ「SPU_VM」に対応する4つのノード識別子は、「vm-spu-id-1」～「vm-spu-id-4」に対応するノードである。すなわち、「vm-spu-id-1」から「vm-spu-id-4」までのノード識別子を有する1つまたは2つのノードのみが、各バッチにおいてリセットされてもよい。「CPU_VM」に対応するノードは、ポストバッチにおいてリセットされる必要があり、各バッチにおいて1つのノードのみがリセットされるので、ノード・タイプ「CPU_VM」に対応する「vm-cpu-id-1」および「vm-cpu-id-2」としてのノード識別子を有する2つのノードは、同じバッチにおいてリセットされることができず、両方ともポストバッチにおいてリセットされる必要がある。すなわち、ノード識別子「vm-cpu-id-1」および「vm-cpu-id-2」に対応するノードは、より低いランキングをもつアップグレード・バッチに別々にバッチ化される。

【0112】

前述の説明に基づいて、表5を参照されたい。表5は、表2に示されるノード・バッチ規則セットに基づいて表1に示されるノード・セットに対してバッチ化を実行することによって取得される、アップグレードのためのバッチ情報の例である。表5の例は、この解決策を理解するためにのみ使用され、アップグレードのための具体的なバッチ情報は、実際の状況に従って柔軟に決定されるべきであることを理解されたい。

【表5】

【0113】

S104：NFVIアップグレード・ツールは、アップグレードのためのバッチ情報を取得する。

【0114】

この実施形態では、NFVIアップグレード・ツールは、アップグレードのためのバッチ情報をNFVIバッチ・ツールから取得する。

【0115】

S105：NFVIアップグレード・ツールは、アップグレード・シーケンスに基づいて、アップグレードされるべきグループ・ノードを決定する。

【0116】

この実施形態では、アップグレードのためのバッチ情報が各グループのアップグレード・シーケンスを含むので、NFVIアップグレード・ツールは、アップグレード・シーケンスに基づいてアップグレードされるべきグループ・ノードを決定することができる。

【0117】

たとえば、表5に示されるアップグレードのためのバッチ情報が、説明のための例として使用される。表5から、NFVIアップグレード・ツールは、アップグレード・シーケンスに基づいて、グループ・シーケンス識別子が「1」であるグループに含まれるあるノードがアップグレードされるべきグループ・ノードであると決定しうることがわかる。すなわち、ノード識別子vm-omu-id-1、vm-spu-id-1、およびvm-spu-id-3に対応するノードが、アップグレードされるべきグループ・ノードである。

【0118】

S106：VNFMは第1のメッセージを取得する。

【0119】

この実施形態では、NFVIアップグレード・ツールがアップグレードされるべきグループ・ノードを決定した後に、NFVIアップグレード・ツールは、第1のメッセージをVNFMにさらに送信してよく、第1のメッセージは、前記アップグレードされるべきグループ・ノードがアップグレードされるべきであると示す。このようにして、VNFMは、NFVIアップグレード・ツールによって送信された第1のメッセージを受信し、VNFMは、ステップS107を実行するようにトリガーされる。

【0120】

たとえば、NFVIアップグレード・ツールは、ノード識別子「vm-omu-id-1」、「vm-spu-id-1」、および「vm-spu-id-3」に対応するノードがアップグレードされるべきグループ・ノードであると決定する。この場合、VNFMは、第1のメッセージを使用することによって、ノード識別子「vm-omu-id-1」、「vm-spu-id-1」、および「vm-spu-id-3」に対応するノードがアップグレードされる必要があると判別しうる。

【0121】

S107：VNFMは、前記アップグレードされるべきグループ・ノード上のサービスを、別のアップグレードされないノードに移行する。

【0122】

この実施形態では、VNFMは、アップグレードされるべきグループ・ノード上のすべてのサービスを前記別のアップグレードされないノードに移行する。任意的に、前記アップグレードされるべきグループ・ノードのノード・タイプは、前記別のアップグレードされないノードのノード・タイプと同じである。

【0123】

具体的には、図7を参照されたい。図7は、本願のある実施形態によるサービス移行のフローチャートである。図7に示されるように、ステップS601において、VNFMは、ノード展開のサービス・ステータスおよびスタック・ステータスについてCaaSマネージャに問い合わせる。ステップS602において、CaaSマネージャは、ノード展開のサービス・ステータスおよびスタック・ステータスをVNFMにフィードバックする。スタックが正常状態にあるとき、ステップS603において、VNFMは、バッチ・アップグレード・メッセージをVNFに送信し、バッチ・アップグレード・メッセージは、サービスが移行される必要があるノードのリストを含む。すなわち、前記アップグレードされるべきグループ・ノードが含まれ、そのため、VNFは、前記アップグレードされるべきグループ・ノードに対応するサービスまたはトラフィックを移行するようにトリガーされる。したがって、ステップS604において、VNFは、前記アップグレードされるべきグループ・ノード上の前記サービスを前記別のアップグレードされないノードに移行し、それにより、サービス移行を完了する。任意的に、前記アップグレードされるべきグループ・ノードに対応する前記サービスまたはトラフィックを移行するプロセスにおいて、VNFは、サービスまたはトラフィック移行結果および進捗をVNFMにさらに通知してよい。たとえば、前記アップグレードされるべきグループ・ノードのサービスの80%の移行が完了している、または前記アップグレードされるべきグループ・ノードの移行が完了している、またはアップグレードされるべき諸グループ・ノードのうちのあるノードの移行が失敗しているなどである。前述の例は、この解決策を理解するために使用されるにすぎず、具体的なサービス移行プロセスおよび態様は、実際の状況に基づいて柔軟に決定されるべきであることを理解されたい。

【0124】

さらに、VNFMは、前記アップグレードされるべきグループ・ノード上で担われるもとのサービスを、同じノード・タイプを有し、アップグレードに参加しないノードに移行する必要がある。たとえば、表1が、説明のための例として使用される。アップグレードされるべきグループ・ノードが、ノード識別子「vm-omu-id-1」、「vm-spu-id-1」、および「vm-spu-id-3」に対応するノードである場合、ノード識別子「vm-omu-id-1」に対応するノードのノード・タイプと同じノード・タイプを有するアップグレードされないノードは、「vm-omu-id-2」に対応するノードである。したがって、ノード識別子「vm-omu-id-1」に対応するノード上のサービスは、ノード識別子「vm-omu-id-2」に対応するノードに移行されることができる。同様に、ノード識別子「vm-spu-id-1」および「vm-spu-id-3」に対応するノード上のサービスは、ノード識別子「vm-spu-id-2」および「vm-spu-id-4」に対応するノードのうちの少なくとも1つに移行されうる。理解を容易にするために、図8を参照されたい。図8は、本願のある実施形態によるサービス移行の概略図である。図8に示されるように、A1およびA2はアップグレードされるべきグループ・ノードを示し、A3およびA4はアップグレードされないノードを示す。前述の実施形態から、以下のことがわかる。アップグレードされるべきグループ・ノードA1、アップグレードされるべきグループ・ノードA2、アップグレードされないノードA3、およびアップグレードされないノードA4はすべて、「SPU_VM」のノード・タイプにはいる。したがって、正常なサービス実行を保証するために、アップグレードされるべきグループ・ノードA1およびアップグレードされるべきグループ・ノードA2のサービスは、アップグレードされないノードA3およびアップグレードされないノードA4に移行されうる。前述の例は、この解決策を理解するためにのみ使用される。サービス移行のための特定のアップグレードされないノードは、実際の状況に従って柔軟に決定されるべきである。

【0125】

加えて、本願のこの実施形態において説明される移行は、バランスされた移行であってもよく、またはバランスされていない移行であってもよい。たとえば、アップグレードされるべきグループ・ノードが6つのサービスを担い、該アップグレードされるべきグループ・ノードのノード・タイプと同じノード・タイプを有する2つのアップグレードされないノードがある。この場合、バランスされた移行は、6つのサービスを2つのアップグレードされないノードにバランスさせる必要があり、すなわち、2つのアップグレードされないノードは、3つの移行されるサービスを別々に受信する。同様に、バランスされていない移行は、サービスが、あるバランスされたノードにおいて完全に移行される必要がないことを意味し、そのため、6つのサービスは、2つのアップグレードされないノードのうちの1つに直接移行されうる。前述の例は、この解決策を理解するためにのみ使用される。移行されるサービスの具体的な量は、実際の状況に従って柔軟に決定されるべきである。

【0126】

S108：NFVIアップグレード・ツールは、第2のメッセージを取得する。

【0127】

この実施形態では、VNFMが複数のVNFに対応しうる場合を考慮して、VNFMは、前記アップグレードされるべきグループ・ノードのサービス移行処理進捗を統合する必要がある。すなわち、VNFは、前記アップグレードされるべきグループ・ノードがサービス移行に成功した、すなわち、サービス移行を完了したというサービスまたはトラフィック移行結果をVNFMに通知する。この場合、前記アップグレードされるべきグループ・ノードは、サービスを担っておらず、アップグレードされることができる。したがって、VNFMは、第2のメッセージをNFVIアップグレード・ツールに送信して、前記アップグレードされるべきグループ・ノード上のすべてのサービスが前記別のアップグレードされないノードに移行されたことを示す。すなわち、NFVIアップグレード・ツールは、VNFMによって送信された第2のメッセージを取得する。

【0128】

次いで、前記アップグレードされるべきグループ・ノードのうちのいずれか1つが故障した場合、移行が失敗したことが判別される。この場合、VNFMは、第2のメッセージをNFVIアップグレード・ツールに送信しない。

【0129】

S109：NFVIアップグレード・ツールは、前記アップグレードされるべきグループ・ノードをアップグレードする。

【0130】

この実施形態では、ステップS108において第2のメッセージを取得した後に、NFVIアップグレード・ツールは、グループ・ノード上のすべてのサービスが前記別のアップグレードされないノードに移行されている、すなわち、前記アップグレードされるべきグループ・ノードにおいてサービスが担われていないと判別してもよい。この場合、NFVIアップグレード・ツールは、前記アップグレードされるべきグループ・ノードをアップグレードするようにNFVIレイヤー（VIMインターフェースを呼び出す）に通知する。具体的には、前記アップグレードされるべきグループ・ノードをアップグレードするプロセスは、アップグレードされるべきグループ・ノードを無効にし、ホストをリセットし、新しいバージョンのソフトウェアをロードし、次いで、前記アップグレードされるべきグループ・ノードをリスタートして有効にすることを含むが、これらに限定されない。

【0131】

S110：VNFMが第3のメッセージを取得する。

【0132】

この実施形態では、前記アップグレードされるべきグループ・ノードがアップグレードされたと判別した後、NFVIアップグレード・ツールは、第3のメッセージをVNFMに送信する必要がある。第3のメッセージは、前記アップグレードされるべきグループ・ノードがアップグレードされたことを示す。したがって、VNFMは、NFVIアップグレード・ツールによって送信された第3のメッセージを取得する。

【0133】

S111：VNFMは、前記別のアップグレードされないノード上のサービスを、アップグレードされたグループ・ノードに移行する。

【0134】

この実施形態では、ステップS110において第3のメッセージを取得した後、VNFMは、前記アップグレードされるべきグループ・ノードがアップグレードされたことを判別してもよい。この場合、前記別のアップグレードされないノード上の前記サービスは、アップグレードされた前記グループ・ノードに移行される必要がある。サービスを移行する態様は、ステップS107と同様である。詳細はここでは再び説明されない。

【0135】

前記別のアップグレードされないノード上のいくつかのサービスは、アップグレードされた前記グループ・ノードに移行されるが、すべてのサービスが移行されるわけではないことが理解されうる。これにより、すべてのサービス・ノードがこの時点でサービスを担うことが保証される。

【0136】

任意的に、サービス移行が完了した後に前記別のアップグレードされないノードにおいて担われるサービスの量と、アップグレードされた前記グループ・ノードにおいて担われるサービスの量との間の差は、トラフィック・バランシングを達成するために、事前設定された閾値未満であってもよい。たとえば、サービス移行が完了した後に前記別のアップグレードされないノードにおいて担われるサービスの量は、単一ノード当たり990であり、アップグレードされた前記グループ・ノードにおいて担われるサービスの量は、単一ノード当たり980である。この場合、トラフィック・バランシングが達成されたと判定されてもよい。代替的に、サービス移行が完了した後に前記別のアップグレードされないノードにおいて担われるサービス負荷は、単一ノード当たり90%であり、アップグレードされた前記グループ・ノードにおいて担われるサービス負荷は、単一ノード当たり85%である。この場合、トラフィック・バランシングが達成されたと判定されてもよい。前述の例は、この解決策を理解するために使用されるにすぎず、本願のこの実施形態に対する限定として理解されるべきではないことを理解されたい。

【0137】

S112：NFVIアップグレード・ツールが、第4のメッセージを取得する。

【0138】

この実施形態では、VNFMが複数のVNFに対応しうる場合を考慮して、VNFMは、前記別のアップグレードされないノードのサービス移行処理進捗を統合する必要がある。すなわち、VNFは、前記別のアップグレードされないノードがサービス移行に成功した、すなわち、サービス移行を完了したというサービスまたはトラフィック移行結果をVNFMに通知する。この場合、サービスは、前記アップグレードされるべきグループ・ノードにおいて再び担われる。したがって、VNFMは、第4のメッセージをNFVIアップグレード・ツールに送信して、前記別のアップグレードされないノード上の前記サービスがアップグレードされた前記グループ・ノードに移行されたことを示す。すなわち、NFVIアップグレード・ツールは、VNFMによって送信された第4のメッセージを取得する。

【0139】

次いで、アップグレードされないノードのうちのいずれか1つが失敗した場合、移行が失敗したと判定される。この場合、VNFMは、第4のメッセージをNFVIアップグレード・ツールに送信しない。

【0140】

S113：NFVIアップグレード・ツールは、アップグレード・シーケンスに基づいて次のアップグレードされるべきグループ・ノードを決定する。

【0141】

この実施形態では、アップグレードのためのバッチ情報が各グループのアップグレード・シーケンスを含むので、NFVIアップグレード・ツールは、アップグレード・シーケンスに基づいて前記次のアップグレードされるべきグループ・ノードを決定することができる。

【0142】

たとえば、表5に示されるアップグレードのためのバッチ情報が、説明のための例として使用される。グループ・シーケンス識別子「1」に対応するグループに含まれるノードが前記アップグレードされるべきグループ・ノードである場合、前記アップグレード・シーケンスに基づいて、前記次のアップグレードされるべきグループ・ノードがグループ・シーケンス識別子「2」に対応するグループに含まれるノードであると決定されうることが、表5からわかる。すなわち、ノード識別子「vm-omu-id-2」、「vm-spu-id-2」および「vm-spu-id-4」に対応するノードが、次のアップグレードされるべきグループ・ノードである。

【0143】

S114：VNFMは第1のメッセージを取得する。

【0144】

この実施形態では、NFVIアップグレード・ツールが前記アップグレードされるべきグループ・ノードを決定した後、NFVIアップグレード・ツールはさらに、第1のメッセージをVNFMに送信してもよく、第1のメッセージは、前記次のアップグレードされるべきグループ・ノードがアップグレードされるべきであることを示す。このようにして、VNFMは、NFVIアップグレード・ツールによって送信された第1のメッセージを受信し、VNFMは、ステップS115を実行するようにトリガーされる。

【0145】

S115：VNFMは、前記次のアップグレードされるべきグループ・ノード上のサービスを、別のアップグレードされないノードに移行する。

【0146】

この実施形態では、VNFMが次のアップグレードされるべきグループ・ノード上のすべてのサービスを別のアップグレードされないノードに移行する態様は、ステップS107と同様である。詳細はここでは再び説明されない。

【0147】

S116：NFVIアップグレード・ツールは、第2のメッセージを取得する。

【0148】

この実施形態では、NFVIアップグレード・ツールが第2のメッセージを取得する態様は、ステップS108の方式と同様である。詳細はここでは再び説明されない。第2の情報は、前記次のアップグレードされるべきグループ・ノード上のすべてのサービスが前記別のアップグレードされないノードに移行されたことを示す。

【0149】

S117：NFVIアップグレード・ツールは、前記次のアップグレードされるべきグループ・ノードをアップグレードする。

【0150】

この実施形態では、NFVIアップグレード・ツールが前記次のアップグレードされるべきグループ・ノードをアップグレードする態様は、ステップS109と同様である。詳細はここでは再び説明されない。

【0151】

2. NFVIバッチ・アップグレード・ツールおよびNFVIアップグレード・ツールが、NFVIバッチ・アップグレード・ツールとして統合される。

【0152】

図9Aおよび図9Bは、本願のある実施形態による、ノードをバッチでアップグレードするための別の方法の概略図である。図9Aおよび図9Bに示されるように、ノードをバッチでアップグレードするための方法は、以下のステップを含む。

【0153】

S701：NFVIバッチ・アップグレード・ツールがノード・セットを取得する。

【0154】

この実施形態では、NFVIバッチ・アップグレード・ツールがノード・セットを取得する態様は、ステップS101と同様である。詳細はここでは再び説明されない。

【0155】

S702：NFVIバッチ・アップグレード・ツールがノード・バッチ規則セットを取得する。

【0156】

この実施形態では、NFVIバッチ・アップグレード・ツールがノード・バッチ規則セットを取得する態様は、ステップS102と同様である。詳細はここでは再び説明されない。

【0157】

S703：NFVIバッチ・アップグレード・ツールは、ノード・バッチ規則セットに基づいてノード・セットに対してバッチ化を実行して、アップグレードのためのバッチ情報を取得する。

【0158】

この実施形態では、NFVIバッチ・アップグレード・ツールがノード・バッチ規則セットに基づいてノード・セットに対してバッチ化を実行して、アップグレードのためのバッチ情報を取得する態様は、ステップS103と同様である。詳細はここでは再び説明されない。

【0159】

S704：NFVIバッチ・アップグレード・ツールが、アップグレード・シーケンスに基づいて、アップグレードされるべきグループ・ノードを決定する。

【0160】

この実施形態では、NFVIバッチ・アップグレード・ツールによって取得されたアップグレードのためのバッチ情報が各グループのアップグレード・シーケンスを含むので、NFVIバッチ・アップグレード・ツールは、アップグレード・シーケンスに基づいて、アップグレードされるべきグループ・ノードを決定することができる。NFVIバッチ・アップグレード・ツールがアップグレード・シーケンスに基づいてアップグレードされるべきグループ・ノードを決定する態様は、ステップS105と同様である。詳細はここでは再び説明されない。

【0161】

S705：VNFMが第1のメッセージを取得する。

【0162】

この実施形態では、VNFMが第1のメッセージを取得する態様は、ステップS106と同様である。詳細はここでは再び説明されない。

【0163】

S706：VNFMが、アップグレードされるべきグループ・ノード上のサービスを別のアップグレードされないノードに移行する。

【0164】

この実施形態では、VNFMがアップグレードされるべきグループ・ノード上のサービスを別のアップグレードされないノードに移行する態様は、ステップS107と同様である。詳細はここでは再び説明されない。

【0165】

S707：NFVIバッチ・アップグレード・ツールが第2のメッセージを取得する。

【0166】

この実施形態では、NFVIバッチ・アップグレード・ツールが第2のメッセージを取得する態様は、ステップS108と同様である。詳細はここでは再び説明されない。

【0167】

S708：NFVIバッチ・アップグレード・ツールが、前記アップグレードされるべきグループ・ノードをアップグレードする。

【0168】

この実施形態では、NFVIバッチ・アップグレード・ツールが前記アップグレードされるべきグループ・ノードをアップグレードする態様は、ステップS109と同様である。詳細はここでは再び説明されない。

【0169】

S709：VNFMが第3のメッセージを取得する。

【0170】

この実施形態では、VNFMが第3のメッセージを取得する態様は、ステップS110と同様である。詳細はここでは再び説明されない。

【0171】

S710：VNFMが、前記別のアップグレードされないノード上のサービスを、アップグレードされたグループ・ノードに移行する。

【0172】

この実施形態では、VNFMが前記別のアップグレードされないグループ・ノード上のサービスをアップグレードされた前記グループ・ノードに移行する態様は、ステップS111と同様である。詳細はここでは再び説明されない。

【0173】

S711：NFVIバッチ・アップグレード・ツールが第4のメッセージを取得する。

【0174】

この実施形態では、NFVIバッチ・アップグレード・ツールが第4のメッセージを取得する態様は、ステップS112と同様である。詳細はここでは再び説明されない。

【0175】

S712：NFVIバッチ・アップグレード・ツールが、アップグレード・シーケンスに基づいて、次のアップグレードされるべきグループ・ノードを決定する。

【0176】

この実施形態では、NFVIバッチ・アップグレード・ツールがアップグレード・シーケンスに基づいて次のアップグレードされるべきグループ・ノードを決定する方式は、ステップS113と同様である。詳細はここでは再び説明されない。

【0177】

S713：VNFMが第1のメッセージを取得する。

【0178】

この実施形態では、VNFMが第1のメッセージを取得する態様は、ステップS114と同様である。詳細はここでは再び説明されない。

【0179】

S714：VNFMが、前記次のアップグレードされるべきグループ・ノード上のサービスを別のアップグレードされないノードに移行する。

【0180】

この実施形態では、VNFMが前記次のアップグレードされるべきグループ・ノード上のサービスを前記別のアップグレードされないノードに移行する態様は、ステップS115と同様である。詳細はここでは再び説明されない。

【0181】

S715：NFVIバッチ・アップグレード・ツールが第2のメッセージを取得する。

【0182】

この実施形態では、NFVIバッチ・アップグレード・ツールが第2のメッセージを取得する態様は、ステップS116と同様である。詳細はここでは再び説明されない。

【0183】

S716：NFVIバッチ・アップグレード・ツールが、前記次のアップグレードされるべきグループ・ノードをアップグレードする。

【0184】

この実施形態では、NFVIバッチ・アップグレード・ツールが前記次のアップグレードされるべきグループ・ノードをアップグレードする態様は、ステップS117と同様である。詳細はここでは再び説明されない。

【0185】

上記は主に、方法の観点から本願の実施形態において提供される解決策を説明している。前述の機能を実装するために、ノードをバッチでアップグレードするための装置は、対応する機能を実行するためのハードウェア構造および／またはソフトウェア・モジュールを含むことが理解されうる。当業者は、本明細書で開示される実施形態で説明される例示的なモジュールおよびアルゴリズム・ステップと組み合わせて、本願がハードウェアまたはハードウェアとコンピュータ・ソフトウェアとの組み合わせによって実装されてもよいことを容易に認識するはずである。機能がハードウェアによって実行されるか、またはコンピュータ・ソフトウェアによって駆動されるハードウェアによって実行されるかは、技術的解決策の特定の用途および設計制約に依存する。当業者は、各特定の用途について、説明された機能を実装するために異なる方法を使用しうるが、かかる実装が本願の範囲を超えると考えられるべきではない。

【0186】

本願の実施形態では、ノードをバッチでアップグレードするための装置は、前述の方法実施形態に基づいて機能モジュールに分割されうる。たとえば、各機能モジュールは、各対応する機能に基づく分割を通じて得られてもよく、または2つ以上の機能が1つの処理モジュールに統合されてもよい。統合されたモジュールは、ハードウェアの形で実装されてもよく、ソフトウェア機能モジュールの形で実装されてもよい。本願の実施形態では、モジュール分割は一例であり、論理的な機能分割にすぎないことに留意されたい。実際の実装中に、別の分割方式が使用されてもよい。

【0187】

以下では、本願においてノードをバッチでアップグレードするための装置を詳細に説明する。図10は、本願の実施形態による、ノードをバッチでアップグレードするための装置の概略図である。図10に示されるように、ノードをバッチでアップグレードするための装置1000は、以下を含む：
アップグレードのためのバッチ情報を取得するように構成された取得モジュール1001であって、前記アップグレードのためのバッチ情報は、各グループのアップグレード・シーケンスを含む、取得モジュールと；
前記アップグレード・シーケンスに基づいて、アップグレードされるべきグループ・ノードを決定するように構成された決定モジュール1002と；
前記アップグレードされるべきグループ・ノード上のサービスを別のアップグレードされないノードに移行するように構成された移行モジュール1003と；
前記アップグレードされるべきグループ・ノードをアップグレードするように構成されたアップグレード・モジュール1004。

【0188】

ある任意的な実装では、図10に対応する実施形態に基づいて、本願のこの実施形態において提供されるノードをバッチでアップグレードするための装置1000の別の実施形態において、移行モジュール1003は、前記アップグレードされるべきグループ・ノードがアップグレードされた後に、前記別のアップグレードされないノード上のサービスをアップグレードされたグループ・ノードに移行するようにさらに構成される。

【0189】

ある任意的な実装では、図10に対応する実施形態に基づいて、本願のこの実施形態において提供されるノードをバッチでアップグレードするための装置1000の別の実施形態において、決定モジュール1002は：前記別のアップグレードされないノード上のサービスがアップグレードされた前記グループ・ノードに移行された後に、アップグレード・シーケンスに基づいて次のアップグレードされるべきグループ・ノードを決定するようにさらに構成される。

【0190】

移行モジュール1003は、前記次のアップグレードされるべきグループ・ノード上のサービスを別のアップグレードされないノードに移行するようにさらに構成される。

【0191】

アップグレード・モジュール1004は、前記次のアップグレードされるべきグループ・ノードをアップグレードするようにさらに構成される。

【0192】

ある任意的な実装では、図10に対応する実施形態に基づいて、本願のこの実施形態において提供される、ノードをバッチでアップグレードするための装置1000の別の実施形態において、各グループは、各グループのノード・タイプと、各グループのグループ・シーケンスに対応する識別子と、各グループ内のノードに対応するノード識別子と、各グループ内のノードに対応するホスト識別子とを含む。

【0193】

前記アップグレードされるべきグループ・ノードのノード・タイプは、前記別のアップグレードされないノードのノード・タイプと同じである。

【0194】

ある任意的な実装では、図10に対応する実施形態に基づいて、本願のこの実施形態において提供される、ノードをバッチでアップグレードするための装置1000の別の実施形態では、ノードをバッチでアップグレードするための装置1000は、バッチ化モジュール1005をさらに含む。

【0195】

取得モジュール1001は、アップグレードのためのバッチ情報を取得する前にノード・セットを取得するようにさらに構成される。ノード・セット内の各ノードは、1つのノード・タイプに対応する。

【0196】

取得モジュール1001は、ノード・バッチ規則セットを取得するようにさらに構成される。ノード・バッチ規則セットは、各ノード・タイプに対応するノード・バッチ規則を含む。

【0197】

バッチ化モジュール1005は、アップグレードのためのバッチ情報を取得するために、ノード・バッチ規則セットに基づいてノード・セットに対してバッチ化を実行するように構成される。

【0198】

ある任意的な実装では、図10に対応する実施形態に基づいて、本願のこの実施形態において提供される、ノードをバッチでアップグレードするための装置1000の別の実施形態では、決定モジュール1002は、ノード上で実行されているサービスを決定するようにさらに構成される。サービスは、サービス・タイプに対応する。

【0199】

決定モジュール1002は、サービス・タイプに対応するバッチ規則を決定するようにさらに構成される。

【0200】

決定モジュール1002は、サービス・タイプに対応するバッチ規則に従って、ノード・タイプに対応するノード・バッチ規則を決定するようにさらに構成される。

【0201】

ある任意的な実装では、図10に対応する実施形態に基づいて、本願のこの実施形態において提供されるノードをバッチでアップグレードするための装置1000の別の実施形態において、取得モジュール1001は、前記アップグレードされるべきグループ・ノード上のサービスが前記別のアップグレードされていないノードに移行される前に、第1のメッセージを取得するようにさらに構成される。第1のメッセージは、前記アップグレードされるべきグループ・ノードがアップグレードされることを示す。

【0202】

ある任意的な実装では、図10に対応する実施形態に基づいて、本願のこの実施形態において提供されるノードをバッチでアップグレードするための装置1000の別の実施形態において、取得モジュール1001は、前記アップグレードされるべきグループ・ノードがアップグレードされる前に第2のメッセージを取得するようにさらに構成される。第2のメッセージは、前記アップグレードされるべきグループ・ノード上のすべてのサービスが前記別のアップグレードされないノードに移行されたことを示す。

【0203】

ある任意的な実装では、図10に対応する実施形態に基づいて、本願のこの実施形態において提供されるノードをバッチでアップグレードするための装置1000の別の実施形態において、取得モジュール1001は、前記別のアップグレードされないノード上のサービスが、アップグレードされた前記グループ・ノードに移行される前に、第3のメッセージを取得するようにさらに構成される。第3のメッセージは、前記アップグレードされるべきグループ・ノードがアップグレードされたことを示す。

【0204】

ある任意的な実装では、図10に対応する実施形態に基づいて、本願のこの実施形態において提供されるノードをバッチでアップグレードするための装置1000の別の実施形態において、取得モジュール1001は、アップグレード・シーケンスに基づいて前記次のアップグレードされるべきグループ・ノードが決定される前に、第4のメッセージを取得するようにさらに構成される。第4のメッセージは、前記別のアップグレードされないノード上のサービスが、アップグレードされた前記グループ・ノードに移行されることを示す。

【0205】

本願はさらに、少なくとも1つのプロセッサを含む、ノードをバッチでアップグレードするための装置を提供する。前記少なくとも1つのプロセッサは、メモリに記憶されたコンピュータ・プログラムを実行するように構成され、その結果、ノードをバッチでアップグレードするための装置は、前述の方法実施形態のうちのいずれか1つにおけるNFVIバッチ・ツール、NFVIアップグレード・ツール、NFVIバッチ・アップグレード・ツール、およびVNFMによって実行される方法を実行する。

【0206】

ノードをバッチでアップグレードするための前述の装置は、一つまたは複数のチップでありうることを理解されたい。たとえば、ノードをバッチでアップグレードするための装置は、フィールドプログラマブルゲートアレイ（field programmable gate array、FPGA）、特定用途向け集積チップ（application-specific integrated circuit、ASIC）、システムオンチップ（system on chip、SoC）、中央処理装置（central processor unit、CPU）、ネットワークプロセッサ（network processor、NP）、デジタル信号プロセッサ（digital signal processor、DSP）回路、マイクロコントローラユニット（micro controller unit、MCU）、プログラマブルコントローラ（プログラマブルロジックデバイス［programmable logic device］、PLD）、または別の集積チップであってもよい。

【0207】

本願のある実施形態は、プロセッサおよび通信インターフェースを含む、ノードをバッチでアップグレードするための装置をさらに提供する。通信インターフェースは、プロセッサに結合される。通信インターフェースは、情報を入力および／または出力するように構成される。情報は、命令およびデータのうちの少なくとも1つを含む。プロセッサは、コンピュータ・プログラムを実行するように構成され、その結果、ノードをバッチでアップグレードするための装置は、前述の方法実施形態のいずれか1つにおけるNFVIバッチ・ツール、NFVIアップグレード・ツール、NFVIバッチ・アップグレード・ツール、およびVNFMによって実行される方法を実行する。

【0208】

本願のある実施形態は、プロセッサおよびメモリを含む、ノードをバッチでアップグレードするための装置をさらに提供する。メモリは、コンピュータ・プログラムを記憶するように構成され、プロセッサは、メモリからコンピュータ・プログラムを呼び出して実行するように構成され、その結果、ノードをバッチでアップグレードするための装置は、前述の方法実施形態のいずれか1つにおけるNFVIバッチ・ツール、NFVIアップグレード・ツール、NFVIバッチ・アップグレード・ツール、およびVNFMによって実行される方法を実行する。

【0209】

ある実装プロセスでは、前述の方法におけるステップは、プロセッサ内のハードウェア集積論理回路を使用することによって、またはソフトウェアの形の命令を使用することによって実装されうる。本願の実施形態を参照して開示される方法のステップは、ハードウェアプロセッサによって直接実行および達成されてもよく、またはプロセッサ内のハードウェアとソフトウェア・モジュールとの組み合わせを使用することによって実行および達成されてもよい。ソフトウェア・モジュールは、ランダムアクセスメモリ、フラッシュメモリ、読み出し専用メモリ、プログラマブル読み出し専用メモリ、電気的に消去可能なプログラマブルメモリ、またはレジスタなど、当技術分野における成熟した記憶媒体内に配置されてもよい。記憶媒体はメモリ内に配置され、プロセッサはメモリ内の情報を読み取り、プロセッサのハードウェアと組み合わせて前述の方法のステップを完了する。繰り返しを避けるために、詳細はここでは再び説明されない。

【0210】

本願の実施形態におけるプロセッサは、集積回路チップであってもよく、信号処理機能を有することに留意されたい。ある実装プロセスでは、前述の方法実施形態におけるステップは、プロセッサ内のハードウェア集積論理回路を使用することによって、またはソフトウェアの形の命令を使用することによって実装できる。プロセッサは、汎用プロセッサ、デジタル信号プロセッサ（DSP）、特定用途向け集積回路（ASIC）、フィールドプログラマブルゲートアレイ（FPGA）もしくは別のプログラマブル論理デバイス、離散的ゲートもしくはトランジスタ論理デバイス、または離散的ハードウェア・コンポーネントでありうる。それは、本願の実施形態において開示される方法、ステップ、および論理ブロック図を実装または実行しうる。汎用プロセッサはマイクロプロセッサであってもよく、またはプロセッサは任意の従来のプロセッサなどであってもよい。本願の実施形態を参照して開示される方法のステップは、ハードウェア復号プロセッサによって直接実行および達成されてもよく、または復号プロセッサ内のハードウェアおよびソフトウェア・モジュールの組み合わせを使用することによって実行および達成されてもよい。ソフトウェア・モジュールは、ランダムアクセスメモリ、フラッシュメモリ、読み出し専用メモリ、プログラマブル読み出し専用メモリ、電気的に消去可能なプログラマブルメモリ、またはレジスタなど、当技術分野における成熟した記憶媒体内に配置されうる。記憶媒体はメモリ内に配置され、プロセッサはメモリ内の情報を読み取り、プロセッサのハードウェアと組み合わせて前述の方法のステップを完了する。

【0211】

本願のこの実施形態におけるメモリは、揮発性メモリまたは不揮発性メモリであってもよく、あるいは揮発性メモリおよび不揮発性メモリを含んでいてもよいことが理解されうる。不揮発性メモリは、読み出し専用メモリ（read-only memory、ROM）、プログラマブル読み出し専用メモリ（programmable ROM、PROM）、消去可能なプログラマブル読み出し専用メモリ（erasable PROM、EPROM）、電気的に消去可能なプログラマブル読み出し専用メモリ（electrically EPROM、EEPROM）、またはフラッシュメモリであってもよい。揮発性メモリは、外部キャッシュとして使用されるランダムアクセスメモリ（random access memory、RAM）であってもよい。限定ではなく例示的な記述を通じて、多くの形のRAM、たとえば、スタティックランダムアクセスメモリ（static RAM、SRAM）、ダイナミックランダムアクセスメモリ（dynamic RAM、DRAM）、シンクロナスダイナミックランダムアクセスメモリ（synchronous DRAM、SDRAM）、ダブルデータレートシンクロナスダイナミックランダムアクセスメモリ（double data rate SDRAM、DDR SDRAM）、エンハンスドシンクロナスダイナミックランダムアクセスメモリ（enhanced SDRAM、ESDRAM）、シンクリンクダイナミックランダムアクセスメモリ（synchlink DRAM、SLDRAM）、およびダイレクトラムバスダイナミックランダムアクセスメモリ（direct rambus RAM、DR RAM）が使用されうる。本明細書で説明されるシステムおよび方法のメモリは、これらおよび別の適切なタイプの任意のメモリを含むが、それらに限定されないことに留意されたい。

【0212】

本願の実施形態において提供される方法によれば、本願は、コンピュータ・プログラム・プロダクトをさらに提供する。コンピュータ・プログラム・プロダクトは、コンピュータ・プログラム・コードを含む。コンピュータ・プログラム・コードがコンピュータ上で実行されるとき、コンピュータは、図2Aおよび図2Bないし図9Aおよび図9Bに示される実施形態におけるNFVIバッチ・ツール、NFVIアップグレード・ツール、NFVIバッチ・アップグレード・ツール、およびVNFMによって実行される方法を実行することが可能にされる。

【0213】

本願の実施形態において提供される方法によれば、本願は、コンピュータ可読記憶媒体をさらに提供する。コンピュータ可読記憶媒体は、コンピュータ・プログラム・コードを記憶する。コンピュータ・プログラム・コードがコンピュータ上で実行されるとき、コンピュータは、図2Aおよび図2Bないし図9Aおよび図9Bに示される実施形態におけるNFVIバッチ・ツール、NFVIアップグレード・ツール、NFVIバッチ・アップグレード・ツール、およびVNFMによって実行される方法を実行することが可能にされる。

【0214】

本願の実施形態において提供される方法によれば、本願は、NFVIバッチ・ツール、NFVIアップグレード・ツール、NFVIバッチ・アップグレード・ツール、およびVNFMのうちの一つまたは複数を含むシステムをさらに提供する。

【0215】

前述の装置実施形態におけるNFVIバッチ・ツール、NFVIアップグレード・ツール、NFVIバッチ・アップグレード・ツール、またはVNFMは、方法実施形態におけるNFVIバッチ・ツール、NFVIアップグレード・ツール、NFVIバッチ・アップグレード・ツール、またはVNFMに完全に対応し、対応するモジュールまたはユニットを使用することによってステップを実行する。たとえば、通信ユニット（トランシーバ）が、方法実施形態における受信または送信ステップを実行し、送信および受信以外の他のステップは、処理ユニット（プロセッサ）によって実行されてもよい。特定のユニットの機能については、対応する方法実施形態を参照されたい。一つまたは複数のプロセッサがあってもよい。

【0216】

本明細書で使用される「コンポーネント」、「モジュール」、および「システム」などの用語は、コンピュータ関連エンティティ、ハードウェア、ファームウェア、ハードウェアとソフトウェアの組み合わせ、ソフトウェア、または実行されているソフトウェアを示すために使用される。たとえば、コンポーネントは、プロセッサ上で実行されるプロセス、プロセッサ、オブジェクト、実行可能ファイル、実行スレッド、プログラム、および／またはコンピュータであってもよいが、これらに限定されない。図を使用することによって示されるように、コンピューティングデバイスおよびコンピューティングデバイス上で実行されるアプリケーションの両方が、コンポーネントでありうる。一つまたは複数のコンポーネントが、プロセスおよび／または実行スレッド内に存在してもよく、コンポーネントは、1つのコンピュータ上に配置されてもよく、および／または2つ以上のコンピュータ間に分散されてもよい。加えて、これらのコンポーネントは、さまざまなデータ構造を記憶するさまざまなコンピュータ可読媒体から実行されうる。たとえば、コンポーネントは、ローカルおよび／またはリモートプロセスを使用することによって、たとえば、一つまたは複数のデータパケットを有する信号（たとえば、ローカルシステム、分散システム内で、および／または信号を使用することによって他のシステムと相互作用するインターネットなどのネットワークにわたって別のコンポーネントと相互作用する2つのコンポーネントからのデータ）に基づいて通信することができる。

【0217】

当業者は、本明細書で開示される実施形態で説明される例と組み合わせて、ユニットおよびアルゴリズム・ステップが、電子ハードウェアまたはコンピュータ・ソフトウェアと電子ハードウェアとの組み合わせによって実装されうることを認識しうる。機能がハードウェアによって実行されるかソフトウェアによって実行されるかは、技術的解決策の特定の用途および設計制約条件に依存する。当業者は、各特定の用途について、説明された機能を実装するために異なる方法を使用してもよいが、かかる実装が本願の範囲を超えると考えられるべきではない。

【0218】

簡便な説明のために、前述のシステム、装置、およびユニットの詳細な稼働プロセスについては、前述の方法実施形態における対応するプロセスが参照されることが、当業者によって明確に理解されうる。詳細はここでは再び説明されない。

【0219】

本願で提供されるいくつかの実施形態では、開示されるシステム、装置、および方法は、他の態様で実装されてもよいことを理解されたい。たとえば、説明された装置実施形態は単に例である。たとえば、ユニットへの分割は、論理的な機能分割に過ぎず、実際の実装の際には他の分割であってもよい。たとえば、複数のユニットまたはコンポーネントは、組み合わされ、または別のシステムに統合されてもよく、またはいくつかの特徴が無視されてもよく、または実行されなくてもよい。加えて、表示または議論された相互結合または直接結合または通信接続は、いくつかのインターフェースを使用することによって実装されてもよい。装置またはユニット間の間接的な結合または通信接続は、電子的、機械的、または他の形で実装されてもよい。

【0220】

別個の部分として説明されるユニットは、物理的に別個であってもなくてもよく、ユニットとして表示される部分は、物理的ユニットであってもなくてもよく、1つの位置に配置されてもよく、または複数のネットワークユニット上に分散されてもよい。ユニットの一部または全部は、実施形態の解決策の目的を達成するために、実際の要件に基づいて選択されうる。

【0221】

加えて、本願の実施形態における機能ユニットは、1つの処理ユニットに統合されてもよく、またはユニットのそれぞれが物理的に単独で存在してもよく、または2つ以上のユニットが1つのユニットに統合される。

【0222】

機能がソフトウェア機能ユニットの形で実装され、独立した製品として販売または使用されるとき、機能は、コンピュータ可読記憶媒体に記憶されうる。そのような理解に基づいて、本願の技術的解決策は本質的に、または従来技術に寄与する部分は、または技術的解決策の一部は、ソフトウェア・プロダクトの形態で実装されてもよい。コンピュータ・ソフトウェア・プロダクトは、記憶媒体に記憶され、コンピュータデバイス（パーソナルコンピュータ、サーバー、ネットワーク・デバイスなどであってもよい）に、本願の実施形態において説明される方法のステップのすべてまたは一部を実行するように命令するためのいくつかの命令を含む。前述の記憶媒体は、USBフラッシュドライブ、リムーバブルハードディスク、読み出し専用メモリ（Read-Only Memory、ROM）、ランダムアクセスメモリ（Random Access Memory、RAM）、磁気ディスク、または光ディスクなど、プログラムコードを記憶することができる任意の媒体を含む。

【0223】

前述の説明は、単に本願の特定の実装であり、本願の保護範囲を限定することを意図するものではない。本願において開示される技術的範囲内で当業者によって容易に考え出される任意の変形または置換は、本願の保護範囲内に入るものとする。したがって、本願の保護範囲は、特許請求の範囲の保護範囲に従うものとする。

【図1】

【図2A】

【図2B】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9A】

【図9B】

【図10】