JP7197574B2

JP7197574B2 - 通信ネットワークにおけるサービス登録

Info

Publication number: JP7197574B2
Application number: JP2020521308A
Authority: JP
Inventors: ぺスタニャ，ミゲルアンヘルプエンテ; ロドリゴ，マリアクルスバルトロメ
Original assignee: テレフオンアクチーボラゲットエルエムエリクソン（パブル）
Priority date: 2017-10-17
Filing date: 2018-10-03
Publication date: 2022-12-27
Anticipated expiration: 2038-10-03
Also published as: MX2020003447A; RU2742289C1; CN111226497B; EP3659394A1; US20230209330A1; CA3084719A1; CN111226497A; JP2020537449A; EP4102931A1; WO2019076634A1; US20200296571A1; CA3084719C; US11576031B2

Description

本開示の少なくともいくつかの例は、通信ネットワークにおけるサービス登録のための方法および装置の技術分野に関するものである。

一般に、本明細書で使用されるすべての用語は、使用される文脈から、別の意味が明瞭に与えられるかまたは暗示されることがなければ、関連する技術分野における通常の意味に従って解釈されるべきである。１つの（ａ）／１つの（ａｎ）／その（ｔｈｅ）要素、装置、構成要素、手段、ステップなどに対するすべての参照は、別様に明示されなければ、要素、装置、構成要素、手段、ステップなどのうち少なくとも１つを参照するように、オープンに解釈されるべきである。本明細書で開示されるいかなる方法のステップも、あるステップが別のステップに先行もしくは後続すると明示されるか、またはあるステップが別のステップに先行もしくは後続する必要があると暗示されることがなければ、開示された正確な順番で行う必要はない。本明細書で開示されるあらゆる実施形態のあらゆる機能が、適切であればあらゆる他の実施形態に適用され得る。同様に、あらゆる実施形態のあらゆる利点が、あらゆる他の実施形態に当てはまり得、逆の場合も同じである。含まれる実施形態の他の目的、機能および利点は、以下の説明から明らかになるはずである。

開発中の第５世代（「５Ｇ」）システムは、複数のネットワーク機能を含むＳｅｒｖｉｃｅＢａｓｅｄＡｒｃｈｉｔｅｃｔｕｒｅ（ＳＢＡ）の形をとり、各ネットワーク機能（ＮＦ）が、１つまたは複数のサービス消費者（それぞれが消費者ＮＦである）に対して（提供者ＮＦとして）１つまたは複数のサービスを提供する。たとえば、ＨＴＴＰを使用するＲｅｐｒｅｓｅｎｔａｔｉｏｎａｌＳｔａｔｅＴｒａｎｓｆｅｒ（ＨＴＴＰ／ＲＥＳＴ）ＡｐｐｌｉｃａｔｉｏｎＰｒｏｇｒａｍｍｉｎｇＩｎｔｅｒｆａｃｅ（ＡＰＩ）は、提供者サービスと消費者サービスの間の相互作用のために使用され得る。場合によっては、ＮＦは、１つまたは複数の消費者サービスおよび１つまたは複数の提供者サービスを含み得る。

図１は、ローミング５Ｇシステムアーキテクチャの一例を示すものである。５Ｇシステムのサービスベースアーキテクチャでは、サービス提供者によって提供されるサービスがサービス消費者によって使用される（たとえば消費される）ことが意図されている。５Ｇシステムで利用可能なサービス（またはサービスインスタンス）の数は、（たとえばスケールアップもしくはスケールダウン、障害、計画された保守および／または他の要因のために）動的である。したがって、５Ｇシステムは、
－ＮＲＦにおけるＮＦサービス登録および登録解除と、
－ＮＦサービス消費者によるＮＦサービスの発見と、
－提供者に対するＮＦサービス消費者のアクセスの権限付与と
を含む機能をサポートするＮｅｔｗｏｒｋＲｅｐｏｓｉｔｏｒｙＦｕｎｃｔｉｏｎ（ＮＲＦ）を構想する。

図１に示されたものなどの５Ｇアーキテクチャでは、ＵｎｉｆｉｅｄＤａｔａＭａｎａｇｅｍｅｎｔ（ＵＤＭ）ネットワーク機能はサブスクライバデータをデータベースに記憶し得る。階層化アーキテクチャでは、ＵＤＭは、ＵＤＭフロントエンド（ＵＤＭ－ＦＥ）にデータベースを加えたものである。図２は、（たとえば１つまたは複数のネットワーク機能における）ＵＤＲコンテンツおよび消費者サービスの一例を示すものである。示されるように、ＵＤＲは、サブスクリプションデータ、サブスクリプションポリシーデータ、暴露用データおよびアプリケーションデータを含有しており、Ｎｕｄｒインターフェースを介してＵＤＭ－ＦＥ、ＰＣＦおよびＮＥＦネットワーク機能とインターフェースをとる。図２に示された構造は単なる例であり、表現されたエンティティは、異なるやり方で、かつ／または異なるインターフェース（複数可）を使用して、組織化され得る。

記憶されたデータの特定のビューにアクセスするため、データの読取り、更新（追加、修正を含む）および削除のため、ならびにＵＤＲから関連するデータの変更通知をサブスクライブするために、ＵＤＭＦＥ、ＰＣＦおよびＮＥＦなどのネットワーク機能に関してＮｕｄｒインターフェースが規定されている。ＵＤＲにアクセスする各ネットワーク機能は、変更する権限を与えられているデータに対してのみ、付加、修正、更新、または削除が可能である。この権限付与は、ＵＤＲによって、ビューごとかつＮＦ消費者ごと、また可能性として、ＵＥごと、サブスクリプションごと、および／またはローミング契約ごとに、行われ得る。

下記の表１は、ＵＤＭに関して規定されたサービスの例および関連したサービスの動作を示すものである。

ＵＤＲについては、下記の表２に示されるように、１つのサービスだけが関連したサービス動作とともに規定されている。

図３は、サービス（たとえばＮＦにおけるサービスすなわちＮＦサービス）の登録のためのＮＦ（たとえばＮＦサービス、ＮＦサービス提供者）とＮＲＦの間の通信の一例を示すものである。ステップ１において、ＮＦサービス（サービス提供者）は、ＮＲＦにサービスプロファイル（たとえばＮＦサービスプロファイル）を送信する。ステップ２において、ＮＲＦはＮＦプロファイルを記憶する。ステップ３において、ＮＲＦは、ＮＦ（サービス提供者）に対する応答として受信通知を送信する。「ＮＦサービス」、「ＮＦサービスプロファイル」という用語は、「サービス」および「サービスプロファイル」で置換され得る。

ＮＦサービスプロファイルは以下の情報を含み得る。
・ＮＦインスタンスＩＤ
・ＮＦタイプ
・ＰＬＭＮＩＤ
・たとえばＳ－ＮＳＳＡＩ、ＮＳＩＩＤといった、ネットワークスライスに関連した識別子（複数可）
・ＮＦのＦＱＤＮまたはＩＰアドレス
・ＮＦの容量情報
・ＮＦに特有のサービスの権限付与情報
・サポートされるサービスの名称
・それぞれのサポートされるサービスのインスタンス（複数可）のエンドポイント情報
・たとえばＮＦサービスが受信を期している各タイプの通知のための通知エンドポイント（ＤＮＮ）といった他のサービスパラメータ（複数可）

図４は、サービス発見プロセス中のＮＦサービス（ＮＦ消費者）とＮＲＦの間の通信の一例を示すものである。ステップ１において、サービス消費者（ＮＦサービス）は、ネットワークにおける特定のサービスの利用可能なインスタンスを発見しようとする。サービス消費者は、ＮＲＦに、
・ＮＦサービスの名称と、
・ＮＦタイプの予期されるＮＦインスタンスと、
・ＮＦ消費者のＮＦタイプと
を指示する発見要求を送り、
・任意選択でＳ－ＮＳＳＡＩを指示してもよい。

ステップ２において、ＮＲＦは、発見要求における判定基準に合うものを求めて、登録されているサービスを探索する。ステップ３において、ＮＲＦは、判定基準に合うサービスのうち１つ、いくつかもしくはすべてを含む発見されたＮＦインスタンス（複数可）またはＮＦサービスインスタンス（複数可）のセット（たとえば、これらはセットにおける各サービスに関するＦＱＤＮまたはＩＰアドレスを指示し得る）を用いてＮＦに返信する。

図５は、ＮＦ消費者とＮＦ提供者（たとえばサービスプロバイダ）の間の通信の一例を示すものである。ＮＦサービス機構の内部の２つのネットワーク機能（消費者と提供者）の間の相互作用は、２つの機構に従う。

最初の「要求－応答」において、制御プレーンＮＦ＿Ｂ（ＮＦサービス提供者）は、別の制御プレーンＮＦ＿Ａ（ＮＦサービス消費者）によって、アクションを行うサービス、情報を提供するサービス、または両方である一定のＮＦサービスを提供するように要求される。ＮＦ＿Ｂは、ＮＦ＿Ａによる要求に基づいてＮＦサービスを提供する。要求を満たすために、ＮＦ＿Ｂも、他のＮＦからのＮＦサービスを消費してよい。要求－応答の機構では、２つのＮＦ（消費者と提供者）の間で１対１の通信が行われ、一定の時間フレームの範囲内で、消費者からの要求に対して提供者から１回の応答があることが予期される。

２番目の「サブスクライブ－通知」において、制御プレーンＮＦ＿Ａ（ＮＦサービス消費者）は、別の制御プレーンＮＦ＿Ｂ（ＮＦサービス提供者）によって提供されるＮＦサービスをサブスクライブする。複数の制御プレーンのＮＦが同一の制御プレーンのＮＦサービスをサブスクライブしてよい。ＮＦ＿Ｂは、このＮＦサービスをサブスクライブして関心を寄せているＮＦ（複数可）に、このＮＦサービスの結果を通知する。サブスクリプション要求は、ＮＦサービス提供者からイベント通知を送信されるべきＮＦサービス消費者の通知エンドポイント（たとえば通知ＵＲＬ）を含むものとする。加えて、サブスクリプション要求は、一定のイベント（たとえば、要求された情報が変更された、一定の閾値に達した、など）によってトリガされる周期的な更新または通知を求める通知要求を含み得る。

制御プレーンＮＦ＿Ａは、別の消費者にイベント通知を送信することをＮＦサービス提供者に要求している制御プレーンＮＦ＿Ｃのために制御プレーンＮＦ＿Ｂによって提供されるＮＦサービスもサブスクライブしてよい。この場合、ＮＦ＿Ａは、サブスクリプション要求の中にＮＦ＿Ｃの通知エンドポイントを含める。

本開示の一態様によれば、通信ネットワークにおけるサービス登録のための方法が提供される。この方法は、サービス、サービスのタイプ、およびサービスのバージョンを提供するためのネットワーク機能を識別するサービス登録要求を受信することを含む。この方法は、ネットワーク機能、サービスのタイプ、およびサービスのバージョンを識別する情報をリポジトリに記憶することも含む。

本開示の別態様によれば、通信ネットワークにおけるサービス登録のための方法が提供される。この方法は、サービス、サービスのタイプ、およびサービスのバージョンを提供するためのネットワーク機能を提供するサービスを識別するサービス登録要求を、サービス登録ネットワーク機能に送信することを含む。

本開示のさらなる態様によれば、少なくとも１つのプロセッサ上で実行されたとき、少なくとも１つのプロセッサに、上記の態様のうちいずれかによる方法を実行させる命令を含むコンピュータプログラムが提供される。別の態様は、コンピュータプログラムを含有しているキャリアを含み、キャリアは、電子信号、光信号、無線信号またはコンピュータ可読記憶媒体のうち１つを含む。別の態様は、コンピュータプログラムを記憶している非一時的コンピュータ可読媒体を備えたコンピュータプログラム製品を備える。

本開示の別態様によれば、通信ネットワークにおけるサービス登録のための装置が提供される。この装置は、サービス、サービスのタイプ、およびサービスのバージョンを提供するためのネットワーク機能を識別するサービス登録要求を受信するように設定された受信モジュールを備える。この装置は、ネットワーク機能、サービスのタイプ、およびサービスのバージョンを識別する情報をリポジトリに記憶するように設定された記憶モジュールも備える。

本開示のさらなる態様によれば、通信ネットワークにおけるサービス登録のための装置が提供される。この装置は、サービス、サービスのタイプ、およびサービスのバージョンを提供するためのネットワーク機能を提供するサービスを識別するサービス登録要求を、サービス登録ネットワーク機能に送信するように設定された送信モジュールを備える。

本開示の例のさらなる理解のため、また、これらの例が実施される様子をより明確に示すために、次に、ほんの一例として以下の図面を参照する。

ローミング５Ｇシステムアーキテクチャの一例の概略図である。ＵＤＲコンテンツおよび消費者ネットワーク機能の一例の概略図である。ＮＦサービスを登録するための、ＮＦとＮＲＦの間の通信の一例の図示である。サービス発見プロセス中の、ＮＦサービスとＮＲＦの間の通信の一例の図示である。ＮＦ消費者とＮＦ提供者の間の通信の一例の図示である。通信ネットワークにおけるサービス登録のための例示の方法の流れ図である。通信ネットワークにおけるサービス登録のための方法の流れ図である。通信ネットワークにおけるサービス登録のための装置の一例の概略図である。通信ネットワークにおけるサービス登録のための装置の一例の概略図である。通信ネットワークにおけるサービス登録のための例示の装置の概略図である。通信ネットワークにおけるサービス登録のための例示の装置の概略図である。一定の実施形態に包含されるエンティティおよびインターフェースの一例の概略図である。サービス登録プロセス中の、ＮＦサービスとＮＲＦの間の通信の一例の図示である。サービス発見プロセス中の、ＮＦサービスとＮＲＦの間の通信の一例の図示である。

以下は、限定ではなく説明のために、特定の実施形態または例などの具体的な詳細を明らかにするものである。これらの具体的な詳細とは別に他の例が採用され得ることが、当業者には理解されよう。いくつかの事例では、無用の詳細で説明を曖昧にすることのないように、周知の方法、ノード、インターフェース、回路、およびデバイスの詳細な説明が省略されている。当業者なら、説明された機能は、１つまたは複数のノードにおいて、ハードウェアサーキットリ（たとえば、特化された機能を行うように相互接続されたアナログおよび／または個別の論理ゲート、ＡＳＩＣ、ＰＬＡなど）を使用して、かつ／または１つまたは複数のデジタルマイクロプロセッサもしくは汎用コンピュータとともにソフトウエアプログラムおよびデータを使用して、実施され得ることを理解するであろう。エアインターフェースを使用して通信するノードは、適切な無線通信サーキットリも有する。その上に、この技術は、適切な場合には、本明細書で説明された技法をプロセッサに実行させるコンピュータ命令の適切なセットを含有している、ソリッドステートメモリ、磁気ディスク、または光ディスクなどの任意の形式のコンピュータ可読記憶装置の内部でそっくり具現されるものとさらに考えられ得る。

ハードウェア実装形態は、制限なく、デジタル信号プロセッサ（ＤＳＰ）ハードウェア、縮小命令セットプロセッサ、特定用途向け集積回路（ＡＳＩＣ）および／またはフィールドプログラマブルゲートアレイ（ＦＰＧＡ）（複数可）を含むがこれらには限定されないハードウェア（たとえばデジタルまたはアナログ）サーキットリ、および（適切な場合には）そのような機能を行うことができるステートマシンを含み得、または包含し得る。

本明細書で開示された任意の適切なステップ、方法、特徴、機能または利益が、１つまたは複数の仮想装置の１つまたは複数の機能ユニットまたはモジュールを介して行われ得る。それぞれの仮想装置が、複数のこれら機能ユニットを備え得る。これらの機能ユニットは、１つまたは複数のマイクロプロセッサあるいはマイクロコントローラ、ならびにデジタル信号プロセッサ（ＤＳＰ）、専用デジタル論理等を含み得る他のデジタルハードウェアを含み得る、処理サーキットリによって実施されてよい。処理サーキットリは、記憶装置に記憶されたプログラムコードを実行するように設定されてよく、読取り専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、キャッシュメモリ、フラッシュメモリ素子、光学記憶デバイスなど１つまたはいくつかのタイプの記憶装置を含み得る。記憶装置に記憶されたプログラムコードは、１つまたは複数の遠隔通信プロトコルおよび／またはデータ通信プロトコルを実行するためのプログラム命令、ならびに本明細書で説明された技法のうち１つまたは複数を実行するための命令を含む。いくつかの実装形態では、処理サーキットリは、それぞれの機能ユニットに本開示の１つまたは複数の実施形態による対応する機能を行わせるように使用されてよい。

本開示のいくつかの実施形態によれば、ＵＤＲはネットワークにおける唯一のエンティティではない。たとえば、以下の事例ではネットワークに複数のＵＤＲが存在し得る。
－たとえば複数の管区が配備されている中国では、顧客の配備において、同一のネットワークに配備された複数のＵＤＲが存在し得る。
－複数のＵＤＲがそれぞれ別々のデータを保持する。
－複数のＵＤＲが別々のサービス消費者（たとえばＰＣＦ、ＵＤＭ、ＮＥＦおよび／または他の消費者（複数可））に対して別々のサービスを提供する。

これらの事例では、ネットワークにおける各ＵＤＲはＮＲＦにＵＤＭサービスを登録してよいが、各ＵＤＭがサーブするのはいくつかの特定のデータのみであり、たとえば第１のＵＤＲに保持され得るのはすべてのサブスクライバに関するサブスクリプションデータうち一部分でしかなく、第２のＵＤＲがサブスクライバの残りを保持し得、あるいは、第１のＵＤＲがＵＤＭ－ＦＥおよびＰＣＦに関するサブスクリプションデータのみを記憶し得、第２のＵＤＲがアプリケーションデータを記憶し、さらには第３のＵＤＲが暴露用データを記憶する。

これは、各ＵＤＲが提供者サービスを同一の名称で登録してよい（たとえば「ＵｎｉｆｉｅｄＤａｔａＭａｎａｇｅｍｅｎｔ」）が、サービスのインスタンスによってアクセスされる／サーブされるデータが識別され得ないことを意味する。結果として、たとえばＵＤＭ－ＦＥといった消費者ＮＦは、この消費者サービスが関心を寄せているデータへのアクセスを提供するＵＤＲサービスインスタンスの選択を可能にする情報を、ＮＲＦを用いる発見から取得することができない。

ＵＤＭがデータをローカルに記憶するとき（すなわち外部データベースとしてのＵＤＲが配備されていないとき）、同じ問題がＵＤＭに起こる。たとえば、ＵＤＭがサブスクライバのグループまたは層に関するデータを記憶する場合、ＵＤＭ消費者（たとえばＡＭＦ、ＳＭＦ、ＳＭＳＦ）は、どのＵＤＭ－ＦＥインスタンスが対応するＵＥ／サブスクライバに関するデータを記憶するのか認識しない。

加えて、サービスバージョンが扱われるやり方、ベンダ専用のサービス機能が扱われるやり方、（５Ｇシステムにおいて何らかのデータも記憶するための）ベンダ専用のデータベース機能が扱われるやり方、またはサービスのアップグレードが扱われるやり方は、現在明示されていない。

図６は、通信ネットワークにおけるサービス登録のための例示の方法６００の流れ図である。方法６００は、ブロック６０２において、サービス、サービスのタイプ、およびサービスのバージョンを提供するためのネットワーク機能を識別するサービス登録要求を受信することと、ブロック６０４において、ネットワーク機能、サービスのタイプ、およびサービスのバージョンを識別する情報をリポジトリに記憶することとを含む。したがって、リポジトリは、様々な目的に使用され得るサービスのバージョンを識別する情報を記憶することができる。また、サービスのバージョンは、このサービスと、依然として登録されている可能性がある旧バージョンのサービス（たとえば、旧バージョンに関する情報が依然としてリポジトリに記憶されていることがある）との相違を示すことができる。

サービス登録要求はネットワーク機能から受信され得る。情報はＮｅｔｗｏｒｋＲｅｐｏｓｉｔｏｒｙＦｕｎｃｔｉｏｎ（ＮＲＦ）に記憶されてよく、および／または、この方法はＮｅｔｗｏｒｋＲｅｐｏｓｉｔｏｒｙＦｕｎｃｔｉｏｎ（ＮＲＦ）によって行われてよい。

いくつかの実施形態では、この方法は、サービスのタイプを識別するサービス発見要求を受信することと、サービス発見要求の送信側に、ネットワーク機能を識別するサービス発見応答を送信することとを含む。サービス発見応答は、サービスのバージョンを識別し得る。したがって、サービス発見要求の送信側は、いくつかの例ではサービスのバージョンを通知され得、たとえば承認されたバージョンを有するサービス、同一のタイプの別のサービスよりも新しいバージョンのサービス、または（互換性がない新しいバージョンの使用を回避し得る）より古いバージョンのサービスを使用することにより、適切に作動することができる。サービス発見要求の送信側は、異なるバージョンを有する同一のタイプの複数のサービス（たとえば同一のサービス）を認識すると、たとえば１つまたは複数のサービス発見応答においてバージョンを比較して、使用するバージョンを選択してよい。

リポジトリは、さらなるネットワーク機能、サービスのタイプ、およびサービスの旧バージョンであるサービスのさらなるバージョンを識別するさらなる情報を記憶する。したがって、たとえば、異なるバージョンを有する同一のタイプのサービス（たとえば同一のサービス）も、リポジトリに登録されてよい。さらなるネットワーク機能は、同一のネットワーク機能でも異なるネットワーク機能でもよい。いくつかの例では、リポジトリは、サービスのバージョンが、サービスのさらなるバージョンと下位互換性があることを識別する情報を記憶する。たとえば、この情報がサービス発見要求に応答して共有される場合には、これらの要求の送信側は下位互換性を認識し得、したがって、機能性を失うことなく、サービスのより新しいバージョンを旧バージョンと同一または同様のやり方で使用し得る。

いくつかの例では、この方法は、サービスのタイプを識別する複数のサービス発見要求を受信することと、それぞれのサービス発見要求について、サービス発見要求の送信側にサービス発見応答を送信することであって、サービス発見応答の第１のサブセットがサービスのバージョンを識別して、サービス発見応答の第２のサブセットがサービスのさらなるバージョンを識別するように、サービス発見応答が、サービスのバージョンとサービスのさらなるバージョンのうち１つを識別する、サービス発見応答を送信することとを含む。これによって、いくつかの例では、サービス間のロードバランシングを達成し得る。たとえば、サービス発見要求の送信側の第１のセットがサービスの１つのバージョンを通知され得、第２のセットがサービスの別のバージョンを通知され得て、それぞれが（たとえばサービス発見応答において）通知されたサービスのバージョンを使用する。これは、あるバージョンのサービスが他のものと下位互換性があるとき特に有効であり得る。たとえば、バージョンの間で少なくともある程度のロードバランシングを達成するために、サービス発見応答において識別されたサービスのバージョンは、ラウンドロビンのやり方、ランダムなやり方、または任意の他の適切なやり方で選択されてよい。この例は２つのバージョンを識別するものであるが、３つ以上のバージョンの間でのロードバランシングもあり得る。

この方法はまた、いくつかの例では、サービスのタイプを識別するサービス発見要求を受信することや、サービスのバージョンが使用不能であるのを検知することに応答して、サービス発見要求の送信側に、サービスのさらなるバージョンを識別するサービス発見応答の送信することを含み得る。したがって、たとえば、サービスの１つのバージョンが使用不能であれば、サービスは、さらなるバージョンから、引き続き利用可能になり得る。さらなるバージョンが早期のバージョンすなわち旧バージョンであるなら、これは、より新しい、すなわち最近のバージョンが使用不能になったとき（たとえば、より新しい、すなわち最近のバージョンに関連した計算エンティティおよび／またはネットワーク接続が利用不可能になったとき）、さらなるバージョンへの「ロールバック」を表現し得る。

この方法はまた、サービスのタイプを識別するサービス発見要求を受信することに応答して、サービスのバージョンを識別するとともにサービスのバージョンがサービスのさらなるバージョンと下位互換性があることを示すサービス発見要求の送信側に、サービス発見応答を送信することを含み得る。リポジトリに記憶される情報は、いくつかの例では、サービスのバージョンに関するベンダ識別子と、サービスのさらなるバージョンに関するさらなるベンダ識別子とを指示してよく、サービス発見応答は、ベンダ識別子がさらなるベンダ識別子と同一である場合のみ、サービスのバージョンがサービスのさらなるバージョンと下位互換性があることを指示する。これは、以前に使用したバージョンよりも古いバージョンまたは新しいバージョンのサービスを使用する可能性がある、サービスのユーザが、同一のベンダからの別のバージョンのサービスを使用することを保証し得、互換性を拡張し得る。

いくつかの例では、サービス登録要求は、サービスのバージョンが、サービスのさらなるバージョンと下位互換性があることを指示する。したがって、下位互換性情報は、たとえばサービスのプロバイダによって提供され得る。

この方法は、いくつかの実施形態では、さらなるバージョンを識別するサービス発見要求が所定の時間期間にわたってなかったと判定することに応答して、さらなるネットワーク機能に、さらなるバージョンを識別するサービス発見要求が所定の時間期間にわたってなかったと通知すること、ならびに／あるいは、さらなるネットワーク機能、サービスのタイプ、およびサービスのさらなるバージョンを識別するさらなる情報をリポジトリから削除することをさらに含み得る。したがって、たとえば、さらなるバージョン（たとえばより古いバージョンすなわち旧バージョン）は、所定の時間期間にわたって発見されなければ、ある期間にわたって使用されていないので、廃止されている可能性がある（たとえば、サービス消費者は代わりに最近のバージョンのサービスを使用している）。したがって、適切なアクションが採用され得、たとえば、ネットワーク機能は、このことを通知されると、たとえばサービスの旧バージョンを削除することができ、たとえば、さらなる情報がリポジトリから削除されると、リポジトリは最新の状態に保たれ、かつ／またはサービス発見要求においてサービスのさらなるバージョンがもはや識別されなくなる。

いくつかの例では、この方法は、サービス、サービスのタイプ、およびサービスのさらなるバージョンを提供するためのさらなるネットワーク機能を識別するさらなるサービス登録要求を受信することと、さらなるネットワーク機能、サービスのタイプ、およびサービスのさらなるバージョンを識別するさらなる情報をリポジトリに記憶することとを含む。したがって、たとえば複数のバージョンのサービスがリポジトリに登録され得る。

ネットワーク機能（および／または、存在する場合には、さらなるネットワーク機能）は、いくつかの例では、ＵｎｉｆｉｅｄＤａｔａＲｅｐｏｓｉｔｏｒｙ（ＵＤＲ）、ＵｎｉｆｉｅｄＤａｔａＭａｎａｇｅｍｅｎｔ（ＵＤＭ）、ＰｏｌｉｃｙＣｏｎｔｒｏｌＦｕｎｃｔｉｏｎ（ＰＣＦ）、ＮｅｔｗｏｒｋＥｘｐｏｓｕｒｅＦｕｎｃｔｉｏｎ（ＮＥＦ）またはＡｃｃｅｓｓａｎｄＭｏｂｉｌｉｔｙＭａｎａｇｅｍｅｎｔＦｕｎｃｔｉｏｎ（ＡＭＦ）であり得る。通信ネットワークは、いくつかの例では５Ｇシステムでよい。

図７は、通信ネットワークにおけるサービス登録のための方法７００の流れ図である。方法７００は、ブロック７０２において、サービス、サービスのタイプ、およびサービスのバージョンを提供するためのネットワーク機能を提供するサービスを識別するサービス登録要求を、サービス登録ネットワーク機能に送信することを含む。したがって、サービスプロバイダ（たとえばＮＦサービス提供者）は、サービスをバージョン情報とともに登録することができる。サービス登録ネットワーク機能は、たとえばＮｅｔｗｏｒｋＲｅｐｏｓｉｔｏｒｙＦｕｎｃｔｉｏｎ（ＮＲＦ）でよい。

いくつかの例では、方法７００は、サービス登録ネットワーク機能に、サービス、サービスのタイプ、およびサービスのさらなるバージョンを提供するためのネットワーク機能を提供するサービスを識別するさらなるサービス登録要求を送信することを含み、サービスのさらなるバージョンは、サービスのバージョンに対する、サービスの後続のバージョンである。したがって、たとえばサービスの複数のバージョンが登録され得る。さらなるサービス登録要求は、サービスの後続のバージョンがサービスのバージョンと下位互換性があるかどうかを指示してよい。さらなるサービス登録要求は、サービスの旧バージョンであるサービスのバージョンを識別してよく、かつ／またはサービスのバージョンに関するベンダ識別子を指示し、またサービスのさらなるバージョンに関するベンダ識別子を指示する。

方法７００は、いくつかの例では、ネットワーク機能サービス提供者によって行われ得る。ネットワーク機能サービス提供者は、たとえばＵｎｉｆｉｅｄＤａｔａＲｅｐｏｓｉｔｏｒｙ（ＵＤＲ）、ＵｎｉｆｉｅｄＤａｔａＭａｎａｇｅｍｅｎｔ（ＵＤＭ）、ＰｏｌｉｃｙＣｏｎｔｒｏｌＦｕｎｃｔｉｏｎ（ＰＣＦ）、ＮｅｔｗｏｒｋＥｘｐｏｓｕｒｅＦｕｎｃｔｉｏｎ（ＮＥＦ）またはＡｃｃｅｓｓａｎｄＭｏｂｉｌｉｔｙＭａｎａｇｅｍｅｎｔＦｕｎｃｔｉｏｎ（ＡＭＦ）を備え得る。

図８は、通信ネットワークにおけるサービス登録のための例示の装置８００の概略図である。装置８００はプロセッサ８０２および記憶装置８０４を備える。記憶装置８０４は、たとえば図６に示された方法６００を行うことができるように、プロセッサ８０２によって実行可能な命令を含有している。

図９は、通信ネットワークにおけるサービス登録のための装置９００の一例の概略図である。装置９００はプロセッサ９０２および記憶装置９０４を備える。記憶装置９０４は、たとえば図７の方法７００を行うことができるようにプロセッサ９０２によって実行可能な命令を含有している。

図１０は、通信ネットワークにおけるサービス登録のための例示の装置１０００の概略図である。装置１０００は、サービス、サービスのタイプ、およびサービスのバージョンを提供するためのネットワーク機能を識別するサービス登録要求を受信するように設定された受信モジュール１００２０を備える。装置１０００は、ネットワーク機能、サービスのタイプ、およびサービスのバージョンを識別する情報をリポジトリに記憶するように設定された記憶モジュール１００４も備える。

図１１は、通信ネットワークにおけるサービス登録のための例示の装置１１００の概略図である。装置１１００は、サービス、サービスのタイプ、およびサービスのバージョンを提供するためのネットワーク機能を提供するサービスを識別するサービス登録要求をサービス登録ネットワーク機能に送信するように設定された送信モジュール１１０２を備える。

次に、本開示のさらなる実施形態を説明する。

本開示の実施形態は、たとえば５Ｇシステムなどにおいて、サービスバージョン、ＳＢＡにおけるベンダの専用の機能性および／またはサービスアップグレードを扱うためのやり方を提供するものである。たとえば、以下のことの各々が提案される。
１．それぞれの登録されたＮＦサービスのベンダＩＤおよびサービスバージョンを、ＮＲＦに登録されるＮＦプロファイルに含める。したがって、この情報が、たとえばＮＦサービス提供者からのＮＦサービス登録要求にも含まれる。
２．新しいサービスバージョンによって前バージョンが廃止されるかどうかを（たとえばサービス登録要求、別の通信、またはいくつかの他のやり方で）ＮＲＦに指示する。
３．新しいサービスバージョンが前のバージョンと下位互換性があるかどうかを（たとえばサービス登録要求、別の通信、またはいくつかの他のやり方で）ＮＲＦに指示する。
４．ＮＲＦが、（たとえば一定のベンダＩＤ向けに）より新しいバージョンの利用可能なサービスインスタンスがあるかどうかということをサービス発見応答で指示し、そのため、対応するサービス発見要求の送信側（たとえばＮＦサービス消費者）が、新しいサービスバージョンに気付いて、新しいサービスバージョンの使用を開始し得る。
５．ＮＲＦが、サービスバージョンに基づき、発見方法／発見プロセスを実行して（たとえば発見要求応答を送信して）、
Ａ．互換性（たとえば下位互換性）のあるサービスバージョンの間のバランス発見要求をロードし、
Ｂ．サービスバージョンをロールバックする。新バージョンが機能しない場合には、全体的なシステム動作を損なうことなく旧バージョンにロールバックできるように、ＮＲＦは、一定の漸進的モデル（たとえば線形モデル、段階的モデルなど）に続く新しいサービスバージョンのインスタンスを発見する。
６．期間中に一定のサービスバージョンの発見要求が受信されなかったため、または期間中に発見応答がこのバージョンを識別しなかったために、このバージョンが廃止されたとき、ＮＲＦが（たとえばＮＦサービス消費者またはＮＦサービス提供者に）通知する。

本明細書で開示された実施形態は、以下の利点のうち１つまたは複数を必然的に伴い得る。
・たとえば５ＧシステムといったＳＢＡにおけるサービスバージョンおよびサービスアップグレードの処理が可能になる。たとえば、サービスは、バグ修正または資源効率の改善ためにアップグレードされ得る。
・ベンダ専用の機能をサポートすることおよびこの機能にアクセスすることが可能になる。サービス消費者は、（たとえば）技術仕様にあるものよりも新しい入力パラメータ／出力パラメータといった専用の機能性を用いて、特定のベンダおよびバージョンのサービスを発見することができる。
・異なるサービスバージョンの共存が可能になる。
－たとえば、新しいサービスバージョンのほんの少数のインスタンスが導入されるとき、新バージョンインスタンスに過負荷がかからないように、古いバージョンと新しいバージョンの間のロードバランシング方法が適用され得る。
－漸進的なサービスアップグレードが可能になる。新バージョンのサービスインスタンスは漸進的に発見される。新バージョンが機能しない場合、全体的なシステム動作を損なことなく、古いバージョンへの迅速なロールバックが行われ得る。
・消費者は新バージョンに自動的に気付く。消費者は、サービスのより新しいバージョンを自動的に要求することができるように、サービス発見と同時に新しいサービスバージョンを通知され得る。

図１２は、一定の実施形態に包含されるエンティティおよびインターフェースの一例の概略図である。ＳｅｒｖｉｃｅＭａｎａｇｅｍｅｎｔａｎｄＯｒｃｈｅｓｔｒａｔｉｏｎ（ＳＭＯ）は、ネットワークの管理および編成のレイヤにおいてホスティングされ得る、本明細書で開示された実施形態において提案されたエンティティである。ＮＲＦとＳＭＯはＮｏａｍインターフェースを介して相互作用し得る。

図１３は、サービス登録プロセス中の、ＮＦサービスとＮＲＦの間の通信の一例の図示である。図１３に示されるものなど、本明細書で開示される実施形態は、サービスインスタンスごとに、サービス登録要求の中に（任意選択で）以下の情報のうち１つまたは複数を含めることを提案するものである。
・ベンダＩＤ（ベンダの規格化された識別子）。
・サービスバージョン（規格化された表記法、または標準的な長さを有する、ベンダに固有のものであり得る）。
・旧バージョン（新バージョンに先行するバージョン）。これはサービスバージョンと同一の表記法タイプに従うものとする。
・下位互換性（新バージョンが旧バージョンと下位互換性のあるかどうかのインジケータ）。

ＮＲＦは、この情報から、異なるサービスおよびベンダに関するバージョンの階層構造のビューを構築して、どのバージョンの間に互換性があるかといったビューを得ることができる。

図１４は、サービス発見プロセス中の、ＮＦサービスとＮＲＦの間の通信の一例の図示である。本明細書で開示される実施形態は、（たとえば図１４に図示されるように）サービス発見要求の中に、以下の情報のうち１つまたは複数を（任意選択で）含めることを提案するものである。
・ベンダＩＤ（ベンダの規格化された識別子）。
・サービスバージョン（規格化された表記法、または標準的な長さを有するベンダに固有のものであり得る）。

これによって、ＮＦサービス消費者は、一定のベンダおよびバージョンのサービスインスタンスを発見することが可能になり得る。

本明細書で開示される実施形態は、たとえばすべての場合、または要求されたベンダおよびバージョンのサービスインスタンスがシステムに存在する場合に、発見応答の中に、
・専用のサービスインスタンスリスト（要求されたベンダおよびバージョンのサービスインスタンスのリスト）の情報のうち１つまたは複数を含めることを提案するものである。このリストは、いかなるベンダまたはバージョンも登録されていないサービスインスタンスの通常のリストとは区別される。

サービス消費者は、システム上の最新ではないバージョンの発見要求を送信してよい。本明細書で開示される実施形態は、サービス発見応答の中に、
・新バージョンが利用可能であること（要求されたサービスのより最近のバージョンが利用可能であるという指示）の情報を（任意選択で）含めることを提案するものである。この指示はサービス発見応答とともに送信され得、そのときから、サービス消費者は新バージョンを発見することができる。

ＮＲＦは、この指示を送信する時期を決定してよい。たとえば、利用可能な新しいサービスバージョンがあっても、ＮＲＦは、負荷バランスのため、下位互換性がないため、オペレータの指針のため、および／または何らかの他の理由のために、この通知を省略してよい。

新しいサービスバージョンを配備するとき、旧バージョンにロールバックすることによって新バージョンのあらゆる障害を軽減し得るように、新しいサービスインスタンスの発見を漸進的に許容し始めることは、優れた実践であり得る。他のアップグレード方法も適用されてよい。この程度まで、本明細書で開示される実施形態は、ＮＲＦの、サービスアップグレードを設定して始動するとともに、必要に応じて旧バージョンへのロールバックを指令するための新しい能力（たとえばサービス）を提案するものである。下記の表３は、サービス動作とともにこれを達成する、例示のサービスを示すものである。

一例では、（表３に示された）開始動作の前に、新しいサービスバージョンの１つまたは複数のインスタンスがＮＲＦを用いて既に登録されていると想定される。開始要求メッセージ（すなわちサービス動作開始要求）は、以下の情報／パラメータのうち１つまたは複数を含み得る。
・サービス名
・ベンダＩＤ
・サービスバージョン（たとえば新バージョン）
・アップグレードのタイプ（ＮＲＦが新しいサービスバージョンのインスタンスを発見するためのモデルを規定する）
・それぞれのタイプのアップグレードのためのパラメータ（サービスアップグレードのタイプに関連したパラメータを規定する）。たとえば線形アップグレードについては傾斜、段階的アップグレードについては一段の高さおよび持続時間など

開始応答メッセージは、ＮＲＦからの、開始要求メッセージの受信通知でよい。

新しいサービスバージョンが機能しない場合には、サービスをホスティングするＮＦまたはＯ＆Ｍシステム（ＳＭＯモジュール）のいずれかによってロールバック要求メッセージがＮＲＦに送信され得る。これは、以下のパラメータのうち１つまたは複数を含み得る。
・サービス名
・ベンダＩＤ
・サービスバージョン
・ロールバックタイプ（異なるロールバックタイプが規定され得る）。たとえば全面的ロールバック（そのときから、古いバージョンのみが発見される）、部分的ロールバック（新バージョンのサブセットは発見可能に保たれる）など

ロールバック応答メッセージは、ＮＲＦからの、ロールバック要求メッセージの受信通知でよい。

新しいサービスバージョンが配備されて、アップグレードがうまく完了したら、いくつかの実施形態では、サービス消費者はもはやサービスの古いバージョンを発見するべきではない。一定期間を通じて、古いバージョンのさらなる発見要求がないとき、ＮＲＦはこの状況を検知し得る。これは、たとえば編成レイヤが、廃止されたバージョンのサービスインスタンスを削除するのに役立ち得る。本明細書で開示された実施形態は、ＮＲＦにおいて、サービス廃止に関して通知するべきサービス動作を提案するものである。このサービス動作は、ＮＲＦにおける上記の「サービスアップグレード」サービス（たとえばＮｎｒｆ＿ＳｅｒｖｉｃｅＵｐｇｒａｄｅ）の一部分または異なるサービスの一部分であり得る。一例では、このサービス動作は、下記の表４に示されるような「サービスアップグレード」サービスの一部分である。

サービス廃止の通知を望むエンティティは、いくつかの例では、ＮＲＦにおけるこの動作をサブスクライブして、ＮＲＦがそのような通知を送信するのを待ってよい。廃止サブスクライブメッセージは、以下の情報／パラメータのうち１つまたは複数を含み得る。
・サービス名
・ベンダＩＤ
・サービスバージョン（使用されているもの）。サブスクライブしているエンティティが、廃止された場合には通知されることを望むバージョンである
・期間（指示されたサービスバージョンが発見要求を受信しない、廃止されたと見なされるための期間）

廃止通知メッセージは、サブスクライブしているエンティティに対するサービス廃止の指示を含み得る（たとえば特定のバージョンも指示され得る）。

前述の例は、本明細書で開示された実施形態を限定するものではなく、当業者なら多くの代替例を設計できるはずであることに留意されたい。「備える」という語は、追加の要素またはステップの存在を除外するものではなく、「１つの（ａ）」または「１つの（ａｎ）」は複数を除外せず、シングルプロセッサまたは他のユニットは、いくつかのユニットの機能を満たし得る。「第１の」、「第２の」などの用語が使用される場合には、単に特定の特徴の好都合な識別子のラベルとして理解されるべきである。詳細には、これらは、はっきりと別様に明示されない限り、複数のそのような特徴（すなわち時間または空間において生じるそのような第１の特徴または第２の特徴）のうち第１の特徴または第２の特徴を説明していると解釈されるべきではない。本明細書で開示された方法のステップは、別様に明示されない限り、任意の順番で実行されてよい。記述におけるいかなる参照符号も、記述の範囲を限定するようには解釈されないものとする。

Claims

第５世代通信ネットワークのサービスベースアーキテクチャにおけるサービスの登録および発見のための、サービス登録ネットワーク機能により実行される方法であって、前記サービス登録ネットワーク機能は、ネットワークリポジトリファンクション（ＮＲＦ）であり、
サービス、前記サービスのタイプ、および前記サービスのバージョンを提供するネットワーク機能を識別するサービス登録要求を受信することと、
前記ネットワーク機能、前記サービスの前記タイプ、および前記サービスの前記バージョンを識別する情報をリポジトリに記憶することと、
前記サービスのタイプを識別するサービス発見要求を受信することと、
前記サービス発見要求の送信側に、前記ネットワーク機能および前記サービスの前記バージョンを識別するサービス発見応答を送信することとを含み、
前記リポジトリが、前記サービスの旧バージョンである前記サービスのさらなるバージョンを識別するさらなる情報を記憶する、方法。
前記リポジトリが、さらなるネットワーク機能、および前記サービスの前記タイプを識別するさらなる情報を記憶する、請求項１に記載の方法。
前記リポジトリが、前記サービスの前記バージョンが前記サービスの前記さらなるバージョンと下位互換性があることを識別する情報を記憶する、請求項２に記載の方法。
前記サービスのタイプを識別する複数のサービス発見要求を受信することと、
それぞれのサービス発見要求について、前記サービス発見要求の送信側にサービス発見応答を送信することであって、前記サービス発見応答の第１のサブセットが前記サービスの前記バージョンを識別して、前記サービス発見応答の第２のサブセットが前記サービスの前記さらなるバージョンを識別するように、前記サービス発見応答が、前記サービスの前記バージョンと前記サービスの前記さらなるバージョンのうち１つを識別する、サービス発見応答を送信することとを含む、請求項３に記載の方法。
前記サービスのタイプを識別するサービス発見要求を受信することと前記サービスの前記バージョンが使用不能であるのを検知することに応答して、前記サービスの前記さらなるバージョンを識別する前記サービス発見要求の送信側に、サービス発見応答を送信することを含む、請求項３または４に記載の方法。
前記サービスのタイプを識別するサービス発見要求を受信することに応答して、前記サービスの前記バージョンを識別しかつ前記サービスの前記バージョンが前記サービスの前記さらなるバージョンと下位互換性があることを示す前記サービス発見要求の送信側に、サービス発見応答を送信することを含む、請求項３から５のいずれか一項に記載の方法。
前記リポジトリに記憶される前記情報が、前記サービスの前記バージョンに関するベンダ識別子と、前記サービスの前記さらなるバージョンに関するさらなるベンダ識別子とを指示し、前記サービス発見応答は、前記ベンダ識別子が前記さらなるベンダ識別子と同一である場合のみ、前記サービスの前記バージョンが前記サービスの前記さらなるバージョンと下位互換性があることを指示する、請求項６に記載の方法。
前記サービス登録要求が、前記サービスの前記バージョンが前記サービスの前記さらなるバージョンと下位互換性があることを指示する、請求項３から７のいずれか一項に記載の方法。
前記さらなるバージョンを識別するサービス発見要求が所定の時間期間にわたってなかったと判定することに応答して、
前記さらなるネットワーク機能に、前記さらなるバージョンを識別するサービス発見要求が前記所定の時間期間にわたってなかったと通知すること、ならびに／あるいは、
前記さらなるネットワーク機能、前記サービスの前記タイプ、および前記サービスの前記さらなるバージョンを識別する前記さらなる情報を前記リポジトリから削除することをさらに含む、請求項３から８のいずれか一項に記載の方法。
前記サービス、前記サービスの前記タイプ、および前記サービスの前記さらなるバージョンを提供するための前記さらなるネットワーク機能を識別するさらなるサービス登録要求を受信することと、
前記さらなるネットワーク機能、前記サービスの前記タイプ、および前記サービスの前記さらなるバージョンを識別する前記さらなる情報を前記リポジトリに記憶することとを含む、請求項２から９のいずれか一項に記載の方法。
第５世代通信ネットワークのサービスベースアーキテクチャにおける、ネットワーク機能サービス提供者により実行されるサービス登録のための方法であって、
サービス、前記サービスのタイプ、および前記サービスのバージョンを提供するためのネットワーク機能を提供するサービスを識別するサービス登録要求を、サービス登録ネットワーク機能に送信することと、
前記サービス登録ネットワーク機能に、サービス、前記サービスの前記タイプ、および前記サービスのさらなるバージョンを提供するためのネットワーク機能を提供するサービスを識別するさらなるサービス登録要求を送信することであって、前記サービスの前記さらなるバージョンが、前記サービスの前記バージョンに対する前記サービスの後続のバージョンである、さらなるサービス登録要求を送信することを含み、
前記サービスの旧バージョンである前記サービスのさらなるバージョンを識別するさらなる情報がリポジトリに記憶される、方法。
前記さらなるサービス登録要求が、前記サービスの前記後続のバージョンが前記サービスの前記バージョンと下位互換性があるかどうかを指示する、請求項１１に記載の方法。
前記さらなるサービス登録要求が、前記サービスの前記旧バージョンである前記サービスの前記バージョンを識別する、請求項１１または１２に記載の方法。
前記サービス登録要求が前記サービスの前記バージョンに関するベンダ識別子を指示し、前記さらなるサービス登録要求が前記サービスの前記さらなるバージョンに関する前記ベンダ識別子を指示する、請求項１１から１３のいずれか一項に記載の方法。
所定の時間期間にわたって前記サービスの前記バージョンを識別するサービス発見要求がなかったという通知を受信することを含む、請求項１１から１４のいずれか一項に記載の方法。
前記通知が、前記ネットワーク機能、前記サービスの前記タイプ、および前記サービスの前記バージョンを識別する情報が前記リポジトリから削除されたことを指示する、請求項１５に記載の方法。
少なくとも１つのプロセッサ上で実行されたとき、前記少なくとも１つのプロセッサに、請求項１から１６のいずれか一項に記載の方法を実行させる命令を含む、コンピュータプログラム。
請求項１７に記載のコンピュータプログラムを含有しているコンピュータ可読記憶媒体。
第５世代通信ネットワークのサービスベースアーキテクチャにおけるサービス登録のための装置であって、プロセッサと、前記装置が請求項１から１０のいずれか一項に記載の方法を行うことができるように前記プロセッサによって実行可能な命令を含有している記憶装置とを備える装置。
第５世代通信ネットワークのサービスベースアーキテクチャにおけるサービス登録のための装置であって、プロセッサと、前記装置が請求項１１から１６のいずれか一項に記載の方法を行うことができるように前記プロセッサによって実行可能な命令を含有している記憶装置とを備える装置。