JP7241202B2

JP7241202B2 - テレスコピックｆｑｄｎをハンドリングするためのシステムおよび方法

Info

Publication number: JP7241202B2
Application number: JP2021559546A
Authority: JP
Inventors: ヘスス－アンヘルデ－グレゴリオ－ロドリゲス，; サモーラ，ダビドカステリャノス; ユハクヤネン，
Original assignee: テレフオンアクチーボラゲットエルエムエリクソン（パブル）
Priority date: 2019-04-08
Filing date: 2020-04-07
Publication date: 2023-03-16
Anticipated expiration: 2040-04-07
Also published as: CN113661696A; ZA202108576B; EP3788773A1; US12010103B2; PL3788773T3; BR112021020121A2; CN113661696B; WO2020208033A1; JP2022529234A; US20220200966A1; EP3788773B1; EP3886405A1

Description

概して、本明細書で使用されるすべての用語は、異なる意味が、明確に与えられ、および／またはその用語が使用されるコンテキストから暗示されない限り、関連する技術分野における、それらの用語の通常の意味に従って解釈されるべきである。１つの（ａ／ａｎ）／その（ｔｈｅ）エレメント、装置、構成要素、手段、ステップなどへのすべての言及は、別段明示的に述べられていない限り、そのエレメント、装置、構成要素、手段、ステップなどの少なくとも１つの事例に言及しているものとしてオープンに解釈されるべきである。本明細書で開示されるいずれの方法のステップも、ステップが、別のステップに後続するかまたは先行するものとして明示的に説明されない限り、および／あるいはステップが別のステップに後続するかまたは先行しなければならないことが暗黙的である場合、開示される厳密な順序で実施される必要はない。本明細書で開示される実施形態のうちのいずれかの任意の特徴は、適切であればいかなる場合も、任意の他の実施形態に適用され得る。同様に、実施形態のうちのいずれかの任意の利点は、任意の他の実施形態に適用され得、その逆も同様である。同封の実施形態の他の目的、特徴、および利点は、以下の説明から明らかになる。

５Ｇシステムでは、ローミングシナリオの場合、訪問先ＰＬＭＮ中のネットワーク機能（ＮＦ）が、ホームＰＬＭＮ中のネットワーク機能と対話する必要がある。そのようなシグナリング対話は、両方のＰＬＭＮのエッジにある、ＳＥＰＰ（ＳｅｃｕｒｉｔｙＥｄｇｅＰｒｏｔｅｃｔｉｏｎＰｒｏｘｙ：セキュリティエッジ保護プロキシ）と呼ばれる境界エンティティを横断しなければならない。

シグナリングのセキュリティ要件は、一般に、所与のＰＬＭＮ内でさえ、ＮＦ間のシグナリングをＴＬＳ（トランスポートレイヤセキュリティ）を介して保護するための要件を課す。したがって、ホームＰＬＭＮ中の所与のＮＦをアドレス指定するために訪問先ＮＦによって使用されるＵＲＩ（ユニフォームリソース識別子）は、通常、「ｈｔｔｐｓ」ＵＲＩである。たとえば、ＵＤＭ（ｈＰＬＭＮ）と対話するＡＭＦ（ｖＰＬＭＮ）は、以下のＵＲＩを使用することができる。
ｈｔｔｐｓ：／／ｕｄｍ１．ｈｏｍｅ－ｏｐｅｒａｔｏｒ．ｃｏｍ／ｎｕｄｍ－ｓｄｍ／ｖ１／．．．

同時に、訪問先ＰＬＭＮ中にあるＳＥＰＰは、あるビジネス論理を適用するために、平文の、メッセージのコンテンツにアクセスすることが可能である必要がある。

しかしながら、ＴＬＳ（ｈｔｔｐｓ）を使用することは、メッセージがエンドツーエンドで暗号化されることを必要とし、これは、ＳＥＰＰがメッセージへのアクセスを得ることを不可能にする。

これを解決するために、「テレスコピック完全修飾ドメイン名（ＦＱＤＮ：ＦｕｌｌｙＱｕａｌｉｆｉｅｄＤｏｍａｉｎＮａｍｅ）」の概念が、訪問先ＳＥＰＰにおいてＴＬＳ接続を終端する目的で、ＴＳ３３．５０１において紹介された。上記の例示的なＵＲＩは、以下に変換される。
ｈｔｔｐｓ：／／ｕｄｍ１．ｈｏｍｅ－ｏｐｅｒａｔｏｒ．ｃｏｍ．ｓｅｐｐ．ｖｉｓｉｔｅｄ－ｏｐｅｒａｔｏｒ．ｃｏｍ
（すなわち、このテレスコピックＦＱＤＮでは、ホームＵＤＭのＦＱＤＮは訪問先ＳＥＰＰのＦＱＤＮと連結される。）

訪問先ＰＬＭＮのＤＮＳは、「．．．．ｓｅｐｐ．ｖｉｓｉｔｅｄ－ｏｐｅｒａｔｏｒ．ｃｏｍ」で終わる任意のアドレスが訪問先ＳＥＰＰのＩＰアドレスに対して解決されるように設定される。

考慮に入れるべき追加の問題点があり、すなわち、訪問先ＳＥＰＰは、ＴＬＳ接続を終端するために、有効な公開鍵基盤（ＰＫＩ）証明書を訪問先ＮＦ（ＴＬＳ接続の発信者）に提示する必要がある。証明書は、ターゲットＵＲＩが、その証明書中で、サブジェクト代替名（ＳｕｂｊｅｃｔＡｌｔｅｒｎａｔｉｖｅＮａｍｅ）フィールド中で見つけられる、１つまたは複数のＦＱＤＮに「一致する」とき、「有効」である。

テレスコピックＦＱＤＮが動的に築かれるとすれば、および第１の部分が訪問先ＮＦのＦＱＤＮであるとすれば、証明書内にそのようなＦＱＤＮをもつ証明書を作成することは可能でない。ソリューションは、「ワイルドカード証明書」を作成することである。たとえば、上記の例では、ワイルドカード証明書は、以下のようなサブジェクト代替名を含んでいる。
＊．ｓｅｐｐ．ｖｉｓｉｔｅｄ－ｏｐｅｒａｔｏｒ．ｃｏｍ

ワイルドカード証明書の重要な制限は、「＊」がＦＱＤＮ中のシングルレベルドメインのみを表すことができることである。したがって、上記の例は以下に一致する。
ｎｏｄｅ１．ｓｅｐｐ．ｖｉｓｉｔｅｄ－ｏｐｅｒａｔｏｒ．ｃｏｍ

しかし、上記の例は、その一般的なマルチレベル形式では、テレスコピックＦＱＤＮに一致しない。
ｕｄｍ１．ｈｏｍｅ－ｏｐｅｒａｔｏｒ．ｃｏｍ．ｓｅｐｐ．ｖｉｓｉｔｅｄ－ｏｐｅｒａｔｏｒ．ｃｏｍ

その結果、ホームＰＬＭＮ中のＮＦのＦＱＤＮが単一のラベルに「平坦化される（ｆｌａｔｔｅｎ）」ように、テレスコピックＦＱＤＮがもう一度変換されなければならず、たとえば、以下の通りである。
ｕｄｍ１．ｈｏｍｅ－ｏｐｅｒａｔｏｒ．ｃｏｍ－＞ｌａｂｅｌ
その場合、最終ＵＲＩは以下の形式となる。
ｈｔｔｐｓ：／／ｌａｂｅｌ．ｓｅｐｐ．ｖｉｓｉｔｅｄ－ｏｐｅｒａｔｏｒ．ｃｏｍ
これは、訪問先ＳＥＰＰが、上記で示されたようなワイルドカード証明書（＊．ｓｅｐｐ．ｖｉｓｉｔｅｄ－ｏｐｅｒａｔｏｒ．ｃｏｍ）を訪問先ＮＦに提示するとき、正常に一致する。

現在、（１つまたは複数の）ある課題が存在する。上述のように、テレスコピック完全修飾ドメイン名（ＦＱＤＮ）がＴＳ３３．５０１において紹介された。ただし、ホームＮＦのＦＱＤＮからそのような単一のラベルを生成するためのアルゴリズムが、ＣＴ４が規定するために残されたことが、ＴＳ３３．５０１において述べられた。

しかしながら、ＣＴ４は、以下の理由のために、これまでこれを行っていない。

訪問先ＰＬＭＮ中のＮＦは、一般に、ＮＲＦの発見サービス要求を介してホームＰＬＭＮ中のＮＦのＦＱＤＮを得る。これは、発見サービス要求のメッセージもＳＥＰＰを通ることを意味し、したがって、訪問先ＳＥＰＰは、訪問先ＮＦに発見サービス応答を送る前にホームＰＬＭＮの発見されたＮＦのテレスコピックＦＱＤＮを作成することができる。この時点で、訪問先ＳＥＰＰは、テレスコピックＦＱＤＮのために必要とされる「単一ラベル」ドメインを生成するために、訪問先ＳＥＰＰが選定する任意のプロプライエタリアルゴリズムを適用することができる。

次いで、訪問先ＮＦは、実際の「サービス」要求を送る（たとえば、ＡＭＦが、発見されたＵＤＭにサービス要求を送る）ために、訪問先ＳＥＰＰによって築かれたそのようなテレスコピックＦＱＤＮを使用する。

要求は訪問先ＳＥＰＰによって受信され、訪問先ＳＥＰＰは、ホームＮＦの元のＦＱＤＮへのテレスコピックＦＱＤＮの逆変換（ｒｅｖｅｒｓｅｔｒａｎｓｆｏｒｍａｔｉｏｎ）を行わなければならない。たとえば、以下の通りである。
ｈｔｔｐｓ：／／ｌａｂｅｌ．ｓｅｐｐ．ｖｉｓｉｔｅｄ－ｏｐｅｒａｔｏｒ．ｃｏｍ－＞ｈｔｔｐｓ：／／ｕｄｍ１．ｈｏｍｅ－ｏｐｅｒａｔｏｒ．ｃｏｍ

ＳＥＰＰが「ｕｄｍ１．ｈｏｍｅ－ｏｐｅｒａｔｏｒ．ｃｏｍ」から「ｌａｂｅｌ」を作成したとすれば、ＳＥＰＰは、常に、「ｌａｂｅｌ」を、（アルゴリズム変換を適用すること、またはラベルとＦＱＤＮとの間のマッピングテーブルを保つことのいずれかによって）元のＦＱＤＮ「ｕｄｍ１．ｈｏｍｅ－ｏｐｅｒａｔｏｒ．ｃｏｍ」に変換することができる。

上記の仮定に関する問題は、ＳＥＰＰがシグナリング経路に前に関与していないことがあり、訪問先ＮＦがホームＮＦと対話する必要がある場合があることである。そのようなシナリオは、ここまで述べられた「訪問先ＮＦ」および「ホームＮＦ」が事実上「訪問先ＮＲＦ」および「ホームＮＲＦ」である場合である。特に、以下の通りである。

－訪問先ＮＲＦが、ホームＮＲＦに発見要求を送る

－訪問先ＮＲＦが、ホームＮＲＦにＯａｕｔｈ２アクセストークン要求を送る

－訪問先ＮＲＦが、ホームＮＲＦにサブスクリプション要求を送る

すべてのそれらの場合において、訪問先ＮＲＦは、以下のいずれかによってホームＮＲＦのＦＱＤＮを学習する。
－（ホームＰＬＭＮのＭＣＣ／ＭＮＣに基づいて構築された）ＴＳ２３．００３において規定されている規格化されたよく知られているアドレス、または
－ホームＰＬＭＮとのＳＬＡ／ローミング契約の一部として訪問先ＰＬＭＮ中で設定される

したがって、それらの場合、訪問先ＮＲＦは、訪問先ＳＥＰＰを指すホームＮＲＦのテレスコピックＦＱＤＮを構成しなければならない。たとえば、以下の通りである。
ｈｔｔｐｓ：／／ｎｒｆ．ｈｏｍｅ－ｏｐｅｒａｔｏｒ．ｃｏｍ．ｓｅｐｐ．ｖｉｓｉｔｅｄ－ｏｐｅｒａｔｏｒ．ｃｏｍ

また、これは、以下のものなど、単一ラベルドメインに変換される必要がある。
ｈｔｔｐｓ：／／ｌａｂｅｌ．ｓｅｐｐ．ｖｉｓｉｔｅｄ－ｏｐｅｒａｔｏｒ．ｃｏｍ

したがって、元の変換が別のエンティティ（訪問先ＮＲＦ）中で行われたとすれば、逆変換（ｒｅｖｅｒｓｅｔｒａｎｓｆｏｒｍ）を行い、「ｌａｂｅｌ」を「ｎｒｆ．ｈｏｍｅ－ｏｐｅｒａｔｏｒ．ｃｏｍ」にコンバートするために、訪問先ＳＥＰＰのための改善されたシステムおよび方法が必要である。

本開示のいくつかの態様およびそれらの実施形態は、上述のまたは他の課題のソリューションを提供し得る。本開示は、ＳＥＰＰによって提供される新しいサービスを提案し、したがって、他のＮＦは、ＳＥＰＰに、テレスコピックＦＱＤＮを生成（および元のＦＱＤＮを単一のラベルに平坦化）し、また、逆マッピングを行って、平坦化されたテレスコピックＦＱＤＮをホームＰＬＭＮ中のＮＦの元のＦＱＤＮにコンバートするように要求し得る。

たとえば、訪問先ＮＲＦは、以下に接触する必要がある。
ｈｔｔｐｓ：／／ｎｒｆ．ｈｏｍｅ－ｏｐｅｒａｔｏｒ．ｃｏｍ

したがって、訪問先ＮＲＦは、以下のようなＧＥＴ要求を訪問先ＳＥＰＰに送る。
ＧＥＴｈｔｔｐｓ：／／ｓｅｐｐ．ｖｉｓｉｔｅｄ－ｏｐｅｒａｔｏｒ．ｃｏｍ／ｔｅｌｅｓｃｏｐｉｃ？ｆｑｄｎ＝“ｎｒｆ．ｈｏｍｅ－ｏｐｅｒａｔｏｒ．ｃｏｍ”、ここで、「ｓｅｐｐ．ｖｉｓｉｔｅｄ－ｏｐｅｒａｔｏｒ．ｃｏｍ」は訪問先ＳＥＰＰのＦＱＤＮであり、「ｎｒｆ．ｈｏｍｅ－ｏｐｅｒａｔｏｒ．ｃｏｍ」はホームＮＲＦのＦＱＤＮである。

また、訪問先ＳＥＰＰは、たとえば、以下のようなＪＳＯＮドキュメントで答える。
｛“ｔｅｌｅｓｃｏｐｉｃ”：“０ｘ１２７３ｂｃ８９．ｓｅｐｐ．ｖｉｓｉｔｅｄ－ｏｐｅｒａｔｏｒ．ｃｏｍ”｝
（すなわち、このテレスコピックＦＱＤＮ「０ｘ１２７３ｂｃ８９．ｓｅｐｐ．ｖｉｓｉｔｅｄ－ｏｐｅｒａｔｏｒ．ｃｏｍ」では、ホームＮＲＦのＦＱＤＮはラベル「０ｘ１２７３ｂｃ８９」に平坦化され、これは、訪問先ＳＥＰＰのＦＱＤＮ、すなわち「ｓｅｐｐ．ｖｉｓｉｔｅｄ－ｏｐｅｒａｔｏｒ．ｃｏｍ」と連結される。）

逆のサービスも提供され得る。
ＧＥＴｈｔｔｐｓ：／／ｓｅｐｐ．ｖｉｓｉｔｅｄ－ｏｐｅｒａｔｏｒ．ｃｏｍ／ｔｅｌｅｓｃｏｐｉｃ？ｌａｂｅｌ＝“０ｘ１２７３ｂｃ８９”

また、訪問先ＳＥＰＰは、たとえば、以下の通り答える。
｛“ｆｑｄｎ”：“ｎｒｆ．ｈｏｍｅ－ｏｐｅｒａｔｏｒ．ｃｏｍ”｝

ＳＥＰＰによって提供される機構および関連するサービスは、後でＳＥＰＰが逆マッピングを行い、テレスコピックＦＱＤＮに基づいて外部ＮＦのＦＱＤＮを取得することができるように、他のＮＦが別のＰＬＭＮ中のＮＦのテレスコピックＦＱＤＮを取得することを可能にする。

本明細書で開示される問題点のうちの１つまたは複数に対処する様々な実施形態が、本明細書で提案される。いくつかの実施形態では、第３のノードと通信するための、第１のノードによって実施される方法が、第３のノードと通信するべきであると決定することと、第２のノードに、第３のノードと通信するために使用すべきアドレスを要求することと、第２のノードから、第３のノードと通信するために使用すべきアドレスを受信することと、アドレスを使用して第３のノードと通信することとを含む。

いくつかの実施形態では、第１のノードが、訪問先ＮＲＦなど、訪問先ネットワーク中のノードである、第２のノードが、訪問先ＳＥＰＰなど、訪問先ネットワーク中のノードである、および第３のノードが、ホームＮＲＦなど、ホームネットワーク中のノードである、のうちの１つまたは複数である。

いくつかの実施形態では、第３のノードと通信するために使用すべきアドレスを要求することは、第３のノードについてのテレスコピックＦＱＤＮを要求することを含む。いくつかの実施形態では、第３のノードと通信するために使用すべきアドレスを受信することは、第３のノードについてのテレスコピックＦＱＤＮを受信することを含む。いくつかの実施形態では、第３のノードと通信するために使用すべきアドレスを要求することは、第３のノードについてのＦＱＤＮを送ることを含む。いくつかの実施形態では、第３のノードと通信するために使用すべきアドレスを受信することは、第３のノードについての平坦化されたＦＱＤＮを受信することを含む。

いくつかの実施形態では、本方法は、第３のノードと通信するために使用すべきアドレスを使用して第２のノードにサービス要求を送ることによって第３のノードと通信することをも含む。いくつかの実施形態では、本方法は、第３のノードと通信するために使用すべきアドレスを使用して別のノードにサービス要求を送ることによって第３のノードと通信することをも含む。

いくつかの実施形態では、第３のノードとの通信を可能にするための、第２のノードによって実施される方法が、第１のノードから、第３のノードと通信するために使用すべきアドレスについての要求を受信することと、第１のノードに、第３のノードと通信するために使用すべきアドレスを送信することとを含む。

いくつかの実施形態では、第１のノードが、訪問先ＮＲＦなど、訪問先ネットワーク中のノードである、第２のノードが、訪問先ＳＥＰＰなど、訪問先ネットワーク中のノードである、および第３のノードが、ホームＮＲＦなど、ホームネットワーク中のノードである、のうちの１つまたは複数である。いくつかの実施形態では、第３のノードと通信するために使用すべきアドレスについての要求を受信することは、第３のノードについてのテレスコピックＦＱＤＮについての要求を受信することを含む。いくつかの実施形態では、第３のノードと通信するために使用すべきアドレスを送信することは、第３のノードについてのテレスコピックＦＱＤＮを送信することを含む。いくつかの実施形態では、第３のノードと通信するために使用すべきアドレスについての要求を受信することは、第３のノードについてのＦＱＤＮを受信することを含む。いくつかの実施形態では、第３のノードと通信するために使用すべきアドレスを送信することは、第３のノードについての平坦化されたＦＱＤＮを送信することを含む。

いくつかの実施形態では、本方法は、第１のノードから、第３のノードと通信するために使用すべきアドレスを使用して第３のノードと通信するためのサービス要求を受信することをも含む。

特に、一実施形態は、ホームネットワーク（たとえば、ホームパブリックランドモバイルネットワーク（ＨＰＬＭＮ））中の第２のネットワーク機能（ＮＦ）を実装する第３のノードと通信するための、訪問先ネットワーク（たとえば、訪問先パブリックランドモバイルネットワーク（ＶＰＬＭＮ））中の第１のＮＦを実装する第１のノードによって実施される方法を対象とし、本方法は、第３のノードと通信するべきであると決定することと、訪問先ネットワーク中のセキュリティエッジ保護プロキシ（ＳＥＰＰ）を実装する第２のノードのほうへ、ホームネットワーク中の第３のノードと通信するために訪問先ネットワーク中の第１のノードによって使用されるべき、ホームネットワーク中の第３のノードについてのテレスコピック完全修飾ドメイン名（ＦＱＤＮ）についての要求を送ることであって、要求がホームネットワーク中の第３のノードのＦＱＤＮ（たとえば、ＦＱＤＮ「ｎｒｆ．ｈｏｍｅ－ｏｐｅｒａｔｏｒ．ｃｏｍ」）を備える、第３のノードについてのテレスコピック完全修飾ドメイン名（ＦＱＤＮ）についての要求を送ることと、第２のノードから、第３のノードについてのテレスコピックＦＱＤＮを受信することであって、ホームネットワーク中の第３のノードについてのＦＱＤＮが、第３のノードと通信するために第１のノードによって使用されるように単一のラベルに平坦化される、第３のノードについてのテレスコピックＦＱＤＮを受信することとを含む。好ましくは、受信されたテレスコピックＦＱＤＮは、第２のノードのＦＱＤＮと連結されたラベルに平坦化された、第３のノードのＦＱＤＮを備える。たとえば、受信されたテレスコピックＦＱＤＮは、「０ｘ１２７３ｂｃ８９．ｓｅｐｐ．ｖｉｓｉｔｅｄ－ｏｐｅｒａｔｏｒ．ｃｏｍ」であり得、第３のノードは、ラベル「０ｘ１２７３ｂｃ８９」に平坦化されたＦＱＤＮ「ｎｒｆ．ｈｏｍｅ－ｏｐｅｒａｔｏｒ．ｃｏｍ」をもつホームＮＲＦであり、第２のノードは、ＦＱＤＮ「ｓｅｐｐ．ｖｉｓｉｔｅｄ－ｏｐｅｒａｔｏｒ．ｃｏｍ」をもつ訪問先ＳＥＰＰである。

１つの他の実施形態は、ホームネットワーク（たとえば、ホームパブリックランドモバイルネットワーク（ＨＰＬＭＮ））中の第２のネットワーク機能（ＮＦ）を実装する第３のノードとの通信を可能にするための、訪問先ネットワーク（たとえば、訪問先パブリックランドモバイルネットワーク（ＶＰＬＭＮ））中のセキュリティエッジ保護プロキシ（ＳＥＰＰ）を実装する第２のノードによって実施される方法を対象とし、本方法は、訪問先ネットワーク中の第１のＮＦを実装する第１のノードから、ホームネットワーク中の第３のノードと通信するために訪問先ネットワーク中の第１のノードによって使用されるべき、ホームネットワーク中の第３のノードについてのテレスコピック完全修飾ドメイン名（ＦＱＤＮ）についての要求を受信することであって、要求がホームネットワーク中の第３のノードのＦＱＤＮを備える、第３のノードについてのテレスコピック完全修飾ドメイン名（ＦＱＤＮ）についての要求を受信することと、第１のノードに、第３のノードについてのテレスコピックＦＱＤＮを送信することであって、ホームネットワーク中の第３のノードについてのＦＱＤＮが、第３のノードと通信するために第１のノードによって使用されるように単一のラベルに平坦化される、第３のノードについてのテレスコピックＦＱＤＮを送信することとを含む。

いくつかの実施形態は、（１つまたは複数の）以下の技術的利点のうちの１つまたは複数を提供し得る。ソリューションは、多くのフレキシビリティを提供し、テレスコピックＦＱＤＮの生成およびハンドリングにおける相互運用性を容易にする。

この問題を解決するための他の示唆された手法は、たとえば、以下のように単一のラベルを作成するために訪問先ＮＦの元のＦＱＤＮ中の「．」をシンボル「－」と置き換えることによる、元のテレスコピックＦＱＤＮの極めて初歩的なアルゴリズム変換に依拠していた。
ｎｒｆ．ｏｐｅｒａｔｏｒ．ｃｏｍ－＞ｎｒｆ－ｏｐｅｒａｔｏｒ－ｃｏｍ

したがって、テレスコピックＦＱＤＮは以下の通りである。
ｎｒｆ－ｏｐｅｒａｔｏｒ－ｃｏｍ．ｓｅｐｐ．ｖｉｓｉｔｅｄ－ｏｐｅｒａｔｏｒ．ｃｏｍ

これは、本当に不格好で柔軟性のないソリューションであり、なぜなら、この本開示において繰り返し使用される例などのＦＱＤＮ、すなわち、
ｎｒｆ．ｈｏｍｅ－ｏｐｅｒａｔｏｒ．ｃｏｍ
は、元のＦＱＤＮ中の「－」の存在により、そのようなアルゴリズムを用いて変換されることが可能でないからである。ＦＱＤＮ中で許容される唯一の非アルファベットシンボルは「－」シンボルであり、したがって、他のいかなるシンボルも「．」を置き換えるために使用され得ないことに留意されたい。

「－」自体を複数の「－」シンボルと置き換えることによってこの問題を克服することも示唆されたが、この場合も、これは、極めて不格好で柔軟性がない（たとえば、国際化されたドメイン名は、しばしば、２つの連続する「－」シンボルを含んでいる）。

また、アルゴリズム変換の別の制限は、所与のラベルの全長が６３文字を超えることができず、したがって、複数のドメインレベルを伴う長いドメイン名の場合、長さの上限に容易に到達し得ることである。

この問題を解決するために述べられた別の手法は、訪問先ＮＲＦにおいてホームＮＲＦについてのテレスコピックＦＱＤＮを設定することであった。これも、設定が、所与のＰＬＭＮがローミング契約を有するあらゆるＨＰＬＭＮ中のホームＮＲＦに関与することになるので、極めて非効率的で煩雑なタイプのソリューションである。さらに、この設定は、訪問先ＳＥＰＰがホームＮＲＦについてのテレスコピックＦＱＤＮを元のホームＮＲＦのＦＱＤＮにマッピングすることが可能である必要があるので、訪問先ＮＲＦにおいてだけでなく訪問先ＳＥＰＰにおいても必要とされる。

次に、例として、添付の図面を参照しながら、提案されるソリューションが説明される。

本開示のいくつかの実施形態による、セルラ通信ネットワーク１００の一例を示す図である。５Ｇネットワークアーキテクチャとして表される無線通信システムを示す図である。５Ｇネットワークアーキテクチャとして表される無線通信システムを示す図である。本開示のいくつかの実施形態が実装され得る、サービスベースインターフェースをもつ例示的なローミング５Ｇ参照アーキテクチャを示す図である。本開示のいくつかの実施形態の一例を示す図である。本開示のいくつかの実施形態の一例を示す図である。本開示のいくつかの実施形態による、ネットワーク機能を実装するノード６００の概略ブロック図である。本開示のいくつかの実施形態による、ノード６００の仮想化された実施形態を示す概略ブロック図である。本開示のいくつかの他の実施形態による、ノード６００の概略ブロック図である。

添付の図面を参照しながら、次に、本明細書で企図される実施形態のうちのいくつかがより十分に説明される。しかしながら、他の実施形態は、本明細書で開示される主題の範囲内に含まれており、開示される主題は、本明細書に記載される実施形態のみに限定されるものとして解釈されるべきではなく、むしろ、これらの実施形態は、当業者に主題の範囲を伝達するために、例として提供される。

無線ノード：本明細書で使用される「無線ノード」は、無線アクセスノードまたは無線デバイスのいずれかである。

無線アクセスノード：本明細書で使用される「無線アクセスノード」または「無線ネットワークノード」は、信号を無線で送信および／または受信するように動作する、セルラ通信ネットワークの無線アクセスネットワークにおける任意のノードである。無線アクセスノードのいくつかの例は、限定はしないが、基地局（たとえば、第３世代パートナーシッププロジェクト（３ＧＰＰ）第５世代（５Ｇ）ＮＲネットワークにおける新無線（ＮｅｗＲａｄｉｏ：ＮＲ）基地局（ｇＮＢ）、あるいは３ＧＰＰＬｏｎｇＴｅｒｍＥｖｏｌｕｔｉｏｎ（ＬＴＥ）ネットワークにおける拡張またはエボルブドノードＢ（ｅＮＢ））と、高電力またはマクロ基地局と、低電力基地局（たとえば、マイクロ基地局、ピコ基地局、ホームｅＮＢなど）と、リレーノードとを含む。

コアネットワークノード：本明細書で使用される「コアネットワークノード」は、コアネットワークにおける任意のタイプのノードである。コアネットワークノードのいくつかの例は、たとえば、図２および図３Ａ～図３Ｂに示されているコアネットワークノードのうちのいずれかなど、たとえば、モビリティ管理エンティティ（ＭＭＥ）、パケットデータネットワークゲートウェイ（Ｐ－ＧＷ）、サービス能力公開機能（ＳＣＥＦ）などを含む。

無線デバイス：本明細書で使用される「無線デバイス」は、（１つまたは複数の）無線アクセスノードに対して信号を無線で送信および／または受信することによって、セルラ通信ネットワークへのアクセスを有する（すなわち、セルラ通信ネットワークによってサーブされる）任意のタイプのデバイスである。無線デバイスのいくつかの例は、限定はしないが、３ＧＰＰネットワークにおけるユーザ機器デバイス（ＵＥ）と、マシン型通信（ＭＴＣ）デバイスとを含む。

ネットワークノード：本明細書で使用される「ネットワークノード」は、セルラ通信ネットワーク／システムの無線アクセスネットワークまたはコアネットワークのいずれかの一部である任意のノードである。

本明細書で与えられる説明は３ＧＰＰセルラ通信システムに焦点を当て、したがって、３ＧＰＰ専門用語または３ＧＰＰ専門用語に類似した専門用語がしばしば使用されることに留意されたい。しかしながら、本明細書で開示される概念は、３ＧＰＰシステムに限定されない。

本明細書の説明では、「セル」という用語に対して、参照が行われ得ることに留意されたい。しかしながら、特に５ＧＮＲ概念に関して、ビームがセルの代わりに使用されることがあり、したがって、本明細書で説明される概念は、セルとビームの両方に等しく適用可能であることに留意することが重要である。

図１
図１は、本開示のいくつかの実施形態による、セルラ通信ネットワーク１００の一例を示す。本明細書で説明される実施形態では、セルラ通信ネットワーク１００は、５ＧＮＲネットワークである。この例では、セルラ通信ネットワーク１００は、ＬＴＥにおいてｅＮＢと呼ばれ、５ＧＮＲにおいてｇＮＢと呼ばれる、基地局１０２－１および１０２－２を含み、対応するマクロセル１０４－１および１０４－２を制御する。基地局１０２－１および１０２－２は、概して、本明細書では、まとめて基地局１０２と呼ばれ、個別に基地局１０２と呼ばれる。同様に、マクロセル１０４－１および１０４－２は、概して、本明細書では、まとめてマクロセル１０４と呼ばれ、個別にマクロセル１０４と呼ばれる。セルラ通信ネットワーク１００は、対応するスモールセル１０８－１～１０８－４を制御するいくつかの低電力ノード１０６－１～１０６－４をも含み得る。低電力ノード１０６－１～１０６－４は、（ピコ基地局またはフェムト基地局などの）小さい基地局、またはリモート無線ヘッド（ＲＲＨ）などであり得る。特に、示されていないが、スモールセル１０８－１～１０８－４のうちの１つまたは複数は、基地局１０２によって代替的に提供され得る。低電力ノード１０６－１～１０６－４は、概して、本明細書では、まとめて低電力ノード１０６と呼ばれ、個別に低電力ノード１０６と呼ばれる。同様に、スモールセル１０８－１～１０８－４は、概して、本明細書では、まとめてスモールセル１０８と呼ばれ、個別にスモールセル１０８と呼ばれる。基地局１０２（および、随意に低電力ノード１０６）は、コアネットワーク１１０に接続される。

基地局１０２と低電力ノード１０６とは、対応するセル１０４および１０８中の無線デバイス１１２－１～１１２－５にサービスを提供する。無線デバイス１１２－１～１１２－５は、概して、本明細書では、まとめて無線デバイス１１２と呼ばれ、個別に無線デバイス１１２と呼ばれる。無線デバイス１１２は、本明細書では、ＵＥと呼ばれることもある。

図２
図２は、任意の２つのネットワーク機能（ＮＦ）間の対話がポイントツーポイント参照ポイント／インターフェースによって表される、コアＮＦから組み立てられた５Ｇネットワークアーキテクチャとして表される無線通信システムを示す。図２は、図１のシステム１００の特定の一実装形態と見なされ得る。

アクセス側から見ると、図２に示されている５Ｇネットワークアーキテクチャは、無線アクセスネットワーク（ＲＡＮ）またはアクセスネットワーク（ＡＮ）のいずれか、ならびにアクセスおよびモビリティ管理機能（ＡＭＦ）に接続される複数のユーザ機器（ＵＥ）を備える。一般に、Ｒ（ＡＮ）は、たとえばエボルブドノードＢ（ｅＮＢ）または５Ｇ基地局（ｇＮＢ）あるいは同様のものなど、基地局を備える。コアネットワーク側から見ると、図２に示されている５ＧコアＮＦは、ネットワークスライス選択機能（ＮＳＳＦ）、認証サーバ機能（ＡＵＳＦ）、統合データ管理（ＵＤＭ）、ＡＭＦ、セッション管理機能（ＳＭＦ）、ポリシ制御機能（ＰＣＦ）、およびアプリケーション機能（ＡＦ）などのコアネットワークノードを含む。

標準的な規格化における詳細なコールフローを展開するために５Ｇネットワークアーキテクチャの参照ポイント表現が使用される。ＵＥとＡＭＦとの間のシグナリングを搬送するために、Ｎ１参照ポイントが規定される。ＡＮとＡＭＦとの間を、およびＡＮとＵＰＦとの間を接続するための参照ポイントが、それぞれ、Ｎ２およびＮ３として規定される。ＡＭＦとＳＭＦとの間に参照ポイントＮ１１があり、これは、ＳＭＦがＡＭＦによって少なくとも部分的に制御されることを暗示する。Ｎ４が、ＳＭＦおよびＵＰＦによって使用され、したがって、ＵＰＦは、ＳＭＦによって生成された制御信号を使用してセットされ得、ＵＰＦは、その状態をＳＭＦに報告することができる。それぞれ、Ｎ９が、異なるＵＰＦ間の接続のための参照ポイントであり、Ｎ１４が、異なるＡＭＦ間を接続する参照ポイントである。ＰＣＦが、それぞれ、ＡＭＦおよびＳＭＰにポリシを適用するので、Ｎ１５およびＮ７が規定される。Ｎ１２は、ＡＭＦがＵＥの認証を実施するために必要とされる。ＵＥのサブスクリプションデータがＡＭＦおよびＳＭＦに必要とされるので、Ｎ８およびＮ１０が規定される。

５Ｇコアネットワークは、ユーザプレーンと制御プレーンとを分離することを目的とする。ユーザプレーンはユーザトラフィックを搬送し、制御プレーンはネットワーク中のシグナリングを搬送する。図２では、ＵＰＦはユーザプレーン中にあり、すべての他のＮＦ、すなわち、ＡＭＦ、ＳＭＦ、ＰＣＦ、ＡＦ、ＡＵＳＦ、およびＵＤＭは制御プレーン中にある。ユーザプレーンと制御プレーンとを分離することは、各プレーンリソースが独立してスケーリングされることを保証する。ユーザプレーンと制御プレーンとを分離することはまた、ＵＰＦが、分散して制御プレーン機能とは別個に展開されることを可能にする。このアーキテクチャでは、ＵＰＦは、低レイテンシを必要とするいくつかの適用例についてＵＥとデータネットワークとの間のラウンドトリップタイム（ＲＴＴ）を短縮するために、ＵＥの極めて近くに展開され得る。

コア５Ｇネットワークアーキテクチャは、モジュール化された機能から組み立てられる。たとえば、ＡＭＦとＳＭＦとは、制御プレーン中の独立した機能である。分離されたＡＭＦとＳＭＦとは、独立した発展およびスケーリングを可能にする。ＰＣＦおよびＡＵＳＦのような他の制御プレーン機能が、図２に示されているように分離され得る。モジュール化された機能設計は、５Ｇコアネットワークが様々なサービスをフレキシブルにサポートすることを可能にする。

各ＮＦは、別のＮＦと直接対話する。あるＮＦから別のＮＦにメッセージをルーティングするために中間機能を使用することが可能である。制御プレーンでは、２つのＮＦ間の対話のセットがサービスとして規定され、したがって、その再使用が可能である。このサービスは、モジュラリティのサポートを可能にする。ユーザプレーンは、異なるＵＰＦ間のフォワーディング動作など、対話をサポートする。

図３Ａ
図３Ａは、図２の５Ｇネットワークアーキテクチャにおいて使用されるポイントツーポイント参照ポイント／インターフェースの代わりに、制御プレーン中でＮＦ間でサービスベースインターフェースを使用する５Ｇネットワークアーキテクチャを示す。しかしながら、図２を参照しながら上記で説明されたＮＦは、図３Ａに示されているＮＦに対応する。ＮＦが他の許可されたＮＦに提供する（１つまたは複数の）サービスなどは、サービスベースインターフェースを通して、許可されたＮＦに公開され得る。図３Ａでは、サービスベースインターフェースは、文字「Ｎ」およびその後に続くＮＦの名前、たとえば、ＡＭＦのサービスベースインターフェースの場合はＮａｍｆおよびＳＭＦのサービスベースインターフェースの場合はＮｓｍｆなどによって指示される。図３Ａ中のネットワーク公開機能（ＮＥＦ）およびネットワークリポジトリ機能（ＮＲＦ）は、上記で説明された図２に示されていない。しかしながら、図２中で明示的に指示されていないが、図２に図示されているすべてのＮＦが、必要に応じて図３ＡのＮＥＦおよびＮＲＦと対話することができることが、明瞭にされるべきである。

図２および図３Ａに示されているＮＦのいくつかの特性が、以下の様式で説明され得る。ＡＭＦは、ＵＥベース認証、許可、モビリティ管理などを提供する。ＡＭＦはアクセス技術から独立しているので、多元接続技術を使用するＵＥでさえ、基本的に単一のＡＭＦに接続される。ＳＭＦは、セッション管理を担当し、インターネットプロトコル（ＩＰ）アドレスをＵＥに割り当てる。ＳＭＦはまた、データ転送のためにＵＰＦを選択し、制御する。ＵＥが複数のセッションを有する場合、複数のセッションを個々に管理し、場合によってはセッションごとに異なる機能を提供するために、異なるＳＭＦが各セッションに割り当てられ得る。ＡＦは、サービス品質（ＱｏＳ）をサポートするために、ポリシ制御を担当するＰＣＦに、パケットフローに関する情報を提供する。その情報に基づいて、ＰＣＦは、ＡＭＦおよびＳＭＦを適切に動作させるために、モビリティおよびセッション管理に関するポリシを決定する。ＡＵＳＦは、ＵＥまたは同様のものについての認証機能をサポートし、したがって、ＵＥまたは同様のものの認証のためのデータを記憶し、ＵＤＭは、ＵＥのサブスクリプションデータを記憶する。５Ｇコアネットワークの一部でないデータネットワーク（ＤＮ）は、インターネットアクセスまたはオペレータサービスおよび同様のものを提供する。

ＵＤＭは、上記で説明されたＬＴＥ／ＥＰＣネットワーク中のＨＳＳと同様である。ＵＤＭは、３ＧＰＰＡＫＡ認証証明の生成、ユーザ識別情報ハンドリング、サブスクリプションデータに基づくアクセス許可、および他のサブスクライバ関係機能をサポートする。この機能を提供するために、ＵＤＭは、５ＧＣ統合データリポジトリ（ＵＤＲ）に記憶された（認証データを含む）サブスクリプションデータを使用する。ＵＤＭに加えて、ＵＤＲは、ＰＣＦによるポリシデータの記憶および取出し、ならびにＮＥＦによるアプリケーションデータの記憶および取出しをサポートする。

図３Ｂ
図３Ｂは、サービスベースインターフェースをもつ例示的なローミング５Ｇ参照アーキテクチャを示す。この参照アーキテクチャでは、ユーザは、ユーザのホームＰＬＭＮ（ＨＰＬＭＮ）とは異なる訪問先パブリックランドモバイルネットワーク（ＶＰＬＭＮ）中にローミングする。特に、図３Ｂは、ホームオペレータのアドミニストレーティブドメインがユーザのデータセッションに関与し、ＵＥがＨＰＬＭＮ中のデータネットワーク（ＤＮ）をインターフェースする、ホームルーティングされた（ｈｏｍｅ－ｒｏｕｔｅｄ）データサービスをサポートするローミングアーキテクチャを示す。ユーザの観点から、図３Ａの非ローミングアーキテクチャにおいて示されているＨＰＬＭＮの様々なネットワーク機能は、図３Ｂに示されているホームルーティングされたローミングアーキテクチャでは、ＨＰＬＭＮおよびＶＰＬＭＮの間で分散される。たとえば、ＡＭＦはＶＰＬＭＮ中にあり、ＡＵＳＦはＨＰＬＭＮ中にあり、ＳＭＦとＵＰＦとは、ＶＰＬＭＮとＨＰＬＭＮの両方中に存在する（たとえば、ＶＰＬＭＮとＨＰＬＭＮとの間で分割される）。両方のネットワーク中に存在するこれらの機能を区別するために、「Ｈ－ＵＰＦ」および「Ｖ－ＵＰＦ」など、「Ｈ」または「Ｖ」のプレフィックスが使用され得る。

ローミングシナリオと非ローミングシナリオの両方において、ユーザ（たとえば、ＵＥ）が、５Ｇネットワークを介してデータネットワーク（ＤＮ、たとえば、インターネット）との（「ＰＤＵセッション」とも呼ばれる）データセッションを確立することを希望し得る。「プロトコルデータユニット」の省略である「ＰＤＵ」という用語は、しばしば、プロトコルレイヤにおいて指定された、ならびにプロトコル制御情報および場合によってはユーザデータを備える、データのユニットを指すために使用される。「ＰＤＵ」は、しばしば「パケット」と互換的に使用される。ＰＤＵセッション確立は、以下のうちのいずれかに対応し得る。
ＵＥ主導型ＰＤＵセッション確立プロシージャ、
３ＧＰＰネットワークと非３ＧＰＰネットワークとの間のＵＥ主導型ＰＤＵセッションハンドオーバ、
ＬＴＥからＮＲへの（たとえば、ＥＰＣから５ＧＣへの）ＵＥ主導型ＰＤＵセッションハンドオーバ、および
ネットワークトリガ型ＰＤＵセッション確立プロシージャ。この場合、ネットワークは、ＵＥ側の（１つまたは複数の）アプリケーションにデバイストリガメッセージを送る。デバイストリガ要求メッセージ中に含まれるペイロードは、ＵＥ側のどのアプリケーションが、ＰＤＵセッション確立要求をトリガすることが予想されるかに関する情報を含んでいる。その情報に基づいて、ＵＥ側の（１つまたは複数の）アプリケーションは、ＰＤＵセッション確立プロシージャをトリガする。

ホームルーティングされたローミングに基づくＵＥ主導型（またはＵＥ要求型）ＰＤＵセッション確立の場合、ＶＰＬＭＮ中の機能は、しばしば、ユーザに関する情報をＨＰＬＭＮ中のそれらのピアおよび／または対応する機能と交換する必要がある。たとえば、Ｖ－ＳＭＦは、しばしば、情報をＨ－ＳＭＦと交換する必要がある。しかしながら、ＶＰＬＭＮ機能（たとえば、Ｖ－ＳＭＦ）が、対応するＨＰＬＭＮ機能（たとえば、Ｈ－ＳＭＦ）に関する必要な情報を欠くことにより、様々な問題および／または困難が起こり得る。

ＮＦは、専用ハードウェア上のネットワークエレメントとして、専用ハードウェア上で稼働するソフトウェアインスタンスとして、または適切なプラットフォーム、たとえば、クラウドインフラストラクチャ上でインスタンス化される仮想化された機能としてのいずれかで実装され得る。ＮＦはＮＦインスタンスであり得る。

図４
図４は、本開示のいくつかの実施形態の一例を示す。訪問先ＮＲＦ（たとえばＮＲＦインスタンス）は、ホームＮＲＦ（たとえばＮＲＦインスタンス）にメッセージ（サービス要求）を送る必要がある（ステップ４００）。使用事例は、以下であり得る。
－発見要求
－Ｏａｕｔｈ２アクセストークン要求
－ホームＮＲＦに登録されたＮＦのイベントについて通知されるべきホームＮＲＦへのサブスクリプション
ホームＮＲＦのＦＱＤＮは、訪問先ＮＲＦによって次のように決定され得る。
－ホームＰＬＭＮのＭＣＣ／ＭＮＣから構築された標準ＦＱＤＮ
－ホーム／訪問先ＰＬＭＮ間のローミング契約から、ローカルに設定される

訪問先ＮＲＦは、ホームＮＲＦにサービス要求を送る前に、訪問先ＳＥＰＰに、ホームＮＲＦのＦＱＤＮについてのテレスコピックＦＱＤＮを取得するようにとの要求を送る（ステップ４０２）。たとえば、訪問先ＮＲＦは、以下のようなＧＥＴ要求を訪問先ＳＥＰＰに送り得る。
ＧＥＴｈｔｔｐｓ：／／ｓｅｐｐ．ｖｉｓｉｔｅｄ－ｏｐｅｒａｔｏｒ．ｃｏｍ／ｔｅｌｅｓｃｏｐｉｃ？ｆｑｄｎ＝“ｎｒｆ．ｈｏｍｅ－ｏｐｅｒａｔｏｒ．ｃｏｍ、ここで、「ｓｅｐｐ．ｖｉｓｉｔｅｄ－ｏｐｅｒａｔｏｒ．ｃｏｍ」は訪問先ＳＥＰＰのＦＱＤＮであり、「ｎｒｆ．ｈｏｍｅ－ｏｐｅｒａｔｏｒ．ｃｏｍ」はホームＮＲＦのＦＱＤＮである。
訪問先ＳＥＰＰのアドレス／ＩＤ（たとえば、ｓｅｐｐ．ｖｉｓｉｔｅｄ－ｏｐｅｒａｔｏｒ．ｃｏｍ）は、この新しいサービスを提供する訪問先ＳＥＰＰがそれら自体を５ＧＣ内の他のＮＦとして訪問先ＮＲＦに登録しない限り、訪問先ＮＲＦ中でローカルに設定され得、訪問先ＳＥＰＰがそれら自体を５ＧＣ内の他のＮＦとして訪問先ＮＲＦに登録する場合、訪問先ＮＦは、訪問先ＳＥＰＰによって提供されたサービスを発見するために、訪問先ＮＲＦに対してサービス発見を行い得る。

訪問先ＳＥＰＰは、たとえば、（たとえば、文字、数字および場合によっては「－」シンボルのみを有する）ランダムラベルを生成し、そのランダムラベルを、たとえば以下のようにＪＳＯＮドキュメントにおいて、訪問先ＳＥＰＰのＦＱＤＮに付加することによって、テレスコピックＦＱＤＮを作成する（ステップ４０４）。
｛“ｔｅｌｅｓｃｏｐｉｃ”：“０ｘ１２７３ｂｃ８９．ｓｅｐｐ．ｖｉｓｉｔｅｄ－ｏｐｅｒａｔｏｒ．ｃｏｍ”｝
ここで、例示しているランダムラベルは、「０ｘ１２７３ｂｃ８９」である。ホームＮＲＦについてのテレスコピックＦＱＤＮは訪問先ＮＲＦに返され（ステップ４０６）、ホームＮＲＦについてのＦＱＤＮは単一のラベルに平坦化される。

訪問先ＮＲＦは、訪問先ＳＥＰＰのＩＰアドレスを効果的に指す平坦化されたテレスコピックＦＱＤＮを使用して、たとえば、平坦化されたテレスコピックＦＱＤＮと訪問先ＳＥＰＰのＦＱＤＮとを連結することによって、サービス要求（発見、トークン要求、サブスクリプション．．．）を送り（ステップ４０８）、したがって、ＳＥＰＰは、ＴＬＳ接続を終端し、有効なワイルドカード証明書を呈することができる。ＴＬＳが訪問先ＳＥＰＰにおいて終端されるとすれば、訪問先ＳＥＰＰは、メッセージ（サービス要求）を別のＰＬＭＮのほうへ外部的に送る前に、メッセージを解読し、必要な変更を進めることができる。

訪問先ＳＥＰＰは、マッピングテーブルを検査し、訪問先ＮＲＦによって送られた（単一ラベルに平坦化された）テレスコピックＦＱＤＮに基づいて、ホームＮＲＦの実際のＦＱＤＮを取得する（ステップ４１０）。

訪問先ＳＥＰＰは、ホームＰＬＭＮにメッセージをルーティングし（ステップ４１２）、メッセージをホームＳＥＰＰのほうへ効果的に送り、ＩＰＸにおいて追加の媒介を潜在的に横断する。フローの残りは、本開示の範囲外である。

追加の実施形態は、テレスコピックＦＱＤＮを生成するための新しいサービスを他のＮＦに公開する訪問先ＳＥＰＰが、ＮＦが実際のサービス要求を送るための訪問先ＳＥＰＰとは異なる、すなわち、図４中のステップ４０２およびステップ４０８において使用される訪問先ＳＥＰＰが異なる訪問先ＳＥＰＰインスタンスである可能性を提案する。これは、図５に示されている。

図５
訪問先ＮＲＦは、図４に図示されているように（ステップ４００～４０６は、それぞれ図５中のステップ５００～５０６に対応する）、ＶＰＬＭＮ内でこのサービスを公開するＳＥＰＰ、訪問先ＳＥＰＰ１の１つのインスタンスから、ホームＮＲＦのＦＱＤＮについてのテレスコピックＦＱＤＮを得る。

本開示のいくつかの実施形態によれば、このサービスを提供する訪問先ＳＥＰＰ１は、訪問先ＮＲＦが実際のサービス要求をＨＰＬＭＮのほうへ送るために使用するべきである実際の訪問先ＳＥＰＰ（たとえば訪問先ＳＥＰＰ２）を選択することができる。この目的で、訪問先ＳＥＰＰ１は、以下のようにＳＥＰＰ２のドメイン中でテレスコピックＦＱＤＮを生成することができる。
｛“ｔｅｌｅｓｃｏｐｉｃ”：“ｌａｂｅｌ．ｓｅｐｐ２．ｖｉｓｉｔｅｄ－ｏｐｅｒａｔｏｒ．ｃｏｍ”｝

訪問先ＮＲＦは、訪問先ＳＥＰＰのＩＰアドレスを効果的に指す平坦化されたテレスコピックＦＱＤＮにサービス要求（発見、トークン要求、サブスクリプション．．．）を送る（ステップ５０８）。ＮＲＦは、たとえばローカル設定に基づいて、または訪問先ＳＥＰＰ１によって提供されるテレスコピックＦＱＤＮ内の情報に基づいて、上記のステップ２において使用される訪問先ＳＥＰＰインスタンスとは異なる訪問先ＳＥＰＰインスタンス（訪問先ＳＥＰＰ２）を選定する。

訪問先ＳＥＰＰ２がテレスコピックＦＱＤＮ内のラベルを認識しない場合、訪問先ＳＥＰＰ２は、そのラベルを生成した訪問先ＳＥＰＰ１、すなわち訪問先ＳＥＰＰ１（たとえば「ｓｅｐｐ１－０ｘ１２７３ｂｃ８９」）から、訪問先ＮＲＦによって送られたテレスコピックＦＱＤＮに基づいて、ホームＮＲＦの実際のＦＱＤＮを取得する（ステップ５１０）。

この場合、訪問先ＳＥＰＰ１はまた、テレスコピックＦＱＤＮを解決するための（すなわち、ラベルをホームＮＲＦのＦＱＤＮにマッピングするための）サービスを公開する。フローは図４において説明されたように続き、ステップ５１２はステップ４１２と同様である。

図６
図６は、本開示のいくつかの実施形態による、ネットワーク機能を実装するノード６００（たとえば、コアネットワークノード）の概略ブロック図である。ノード６００は、たとえば、たとえばＮＥＦ、ＡＵＳＦ、ＵＤＭ、ＡＭＦ、ＳＭＦ、ＰＣＦ、ＵＰＦまたは同様のもの、特にＮＳＳＦまたはＮＲＦまたはＳＥＰＰあるいは同様のもののうちのいずれか１つなど、コアネットワークノードであり得る。示されているように、ノード６００は、１つまたは複数のプロセッサ６０４（たとえば、中央処理ユニット（ＣＰＵ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）など）と、メモリ６０６と、ネットワークインターフェース６０８とを含む制御システム６０２を含む。１つまたは複数のプロセッサ６０４は、本明細書では処理回路とも呼ばれる。１つまたは複数のプロセッサ６０４は、本明細書で説明されるようにノード６００の１つまたは複数の機能を提供するように動作する。いくつかの実施形態では、（１つまたは複数の）機能は、たとえば、メモリ６０６に記憶され、１つまたは複数のプロセッサ６０４によって実行される、ソフトウェアで実装される。

図７
図７は、本開示のいくつかの実施形態による、ノード６００の仮想化された実施形態を示す概略ブロック図である。この説明は、他のタイプのネットワークノードに等しく適用可能である。さらに、他のタイプのネットワークノードは、同様の仮想化されたアーキテクチャを有し得る。

本明細書で使用される「仮想化された」ノードは、ノード６００の機能の少なくとも一部分が、（たとえば、（１つまたは複数の）ネットワークにおける（１つまたは複数の）物理処理ノード上で実行する（１つまたは複数の）仮想マシンを介して）（１つまたは複数の）仮想構成要素として実装されるノード６００の一実装形態である。示されているように、この例では、ノード６００は、１つまたは複数のプロセッサ６０４（たとえば、ＣＰＵ、ＡＳＩＣ、ＦＰＧＡなど）と、メモリ６０６と、ネットワークインターフェース６０８とを含む制御システム６０２を含む。制御システム６０２は、ネットワークインターフェース６０８を介して、（１つまたは複数の）ネットワーク７０２に結合されるかまたは（１つまたは複数の）ネットワーク７０２の一部として含まれる、１つまたは複数の処理ノード７００に接続される。各処理ノード７００は、１つまたは複数のプロセッサ７０４（たとえば、ＣＰＵ、ＡＳＩＣ、ＦＰＧＡなど）と、メモリ７０６と、ネットワークインターフェース７０８とを含む。

この例では、本明細書で説明されるノード６００の機能７１０は、１つまたは複数の処理ノード７００において実装されるか、または制御システム６０２および１つまたは複数の処理ノード７００にわたって任意の所望の様式で分散される。いくつかの特定の実施形態では、本明細書で説明されるノード６００の機能７１０の一部または全部は、（１つまたは複数の）処理ノード７００によってホストされる（１つまたは複数の）仮想環境において実装される１つまたは複数の仮想マシンによって実行される仮想構成要素として実装される。当業者によって諒解されるように、（１つまたは複数の）処理ノード７００と制御システム６０２との間の追加のシグナリングまたは通信が、所望の機能７１０のうちの少なくともいくつかを行うために使用される。特に、いくつかの実施形態では、制御システム６０２が含まれないことがあり、その場合、（１つまたは複数の）無線ユニット６１０は、（１つまたは複数の）適切なネットワークインターフェースを介して（１つまたは複数の）処理ノード７００と直接通信する。

いくつかの実施形態では、少なくとも１つのプロセッサによって実行されたとき、本明細書で説明される実施形態のうちのいずれかに従って、少なくとも１つのプロセッサに、ノード６００、または仮想環境におけるノード６００の機能７１０のうちの１つまたは複数を実装するノード（たとえば、処理ノード７００）の機能を行わせる命令を含むコンピュータプログラムが提供される。いくつかの実施形態では、上述のコンピュータプログラム製品を備えるキャリアが提供される。キャリアは、電子信号、光信号、無線信号、またはコンピュータ可読記憶媒体（たとえば、メモリなど、非一時的コンピュータ可読媒体）のうちの１つである。

図８
図８は、本開示のいくつかの他の実施形態による、ノード６００の概略ブロック図である。ノード６００は、１つまたは複数のモジュール８００を含み、その各々はソフトウェアで実装される。（１つまたは複数の）モジュール８００は、本明細書で説明されるノード６００の機能を提供する。この説明は、モジュール８００が処理ノード７００のうちの１つにおいて実装されるか、あるいは複数の処理ノード７００にわたって分散され、ならびに／または（１つまたは複数の）処理ノード７００および制御システム６０２にわたって分散され得る、図７の処理ノード７００に等しく適用可能である。

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

図におけるプロセスが本開示のいくつかの実施形態によって実施される動作の特定の順序を示し得るが、そのような順序は例示的である（たとえば、代替実施形態が、異なる順序で動作を実施する、いくつかの動作を組み合わせる、いくつかの動作を重ね合わせる、などを行い得る）ことを理解されたい。

上記で説明されたいくつかの実施形態は、以下の様式で要約され得る。
１．ホームネットワーク（ＨＰＬＭＮ）中の第２のネットワーク機能（ＮＦ）を実装する第３のノード（４３０）と通信するための、訪問先ネットワーク（ＶＰＬＭＮ）中の第１のＮＦを実装する第１のノード（４２０）によって実施される方法であって、方法は、
－第３のノードと通信するべきであると決定すること（４００）と、
－訪問先ネットワーク中のセキュリティエッジ保護プロキシ（ＳＥＰＰ）を実装する第２のノード（４４０）のほうへ、ホームネットワーク中の第３のノードと通信するために訪問先ネットワーク中の第１のノードによって使用されるべき、ホームネットワーク中の第３のノードについてのテレスコピック完全修飾ドメイン名（ＦＱＤＮ）についての要求を送ること（４０２）であって、要求が、ホームネットワーク中の第３のノードのＦＱＤＮを備える、第３のノードについてのテレスコピック完全修飾ドメイン名（ＦＱＤＮ）についての要求を送ること（４０２）と、
－第２のノードから、第３のノードについてのテレスコピックＦＱＤＮを受信すること（４０６）であって、ホームネットワーク中の第３のノードについてのＦＱＤＮが、第３のノードと通信するために第１のノードによって使用されるように単一のラベルに平坦化される、第３のノードについてのテレスコピックＦＱＤＮを受信すること（４０６）と
を含む、方法。
２．第３のノードについての受信されたテレスコピックＦＱＤＮを使用して訪問先ネットワーク中の第２のノードを介してホームネットワーク中の第３のノードと通信すること（４０８、５０８）をさらに含み、ホームネットワーク中の第３のノードについてのＦＱＤＮが単一のラベルに平坦化される、実施形態１に記載の方法。
３．第３のノードについての受信されたテレスコピックＦＱＤＮを備えるサービス要求を訪問先ネットワーク中の第２のノードに送ることによって、ホームネットワーク中の第３のノードと通信すること（４０８）をさらに含む、実施形態１または２に記載の方法。
４．サービス要求が、発見要求、Ｏａｕｔｈ２アクセストークン要求またはサブスクリプション要求のうちのいずれか１つである、実施形態３に記載の方法。
５．第１のノードが訪問先ＮＲＦを実装する、第２のノードが訪問先ＳＥＰＰを実装する、および第３のノードがホームＮＲＦを実装する、のうちの１つまたは複数である、実施形態１から４のいずれか１つに記載の方法。
６．テレスコピックＦＱＤＮを要求することが、ホームネットワーク中の第３のノードについてのＦＱＤＮを送ることを含む、実施形態１から５のいずれか１つに記載の方法。
７．テレスコピックＦＱＤＮを受信することが、第３のノードについての平坦化されたＦＱＤＮを受信することを含む、実施形態１から６のいずれか１つに記載の方法。
８．第３のノードと通信するために使用すべきテレスコピックＦＱＤＮを使用して別のノード（ＳＥＰＰ２）にサービス要求を送ることによって第３のノードと通信することをさらに含む、実施形態２から７のいずれか１つに記載の方法。
９．ホームネットワーク（ＨＰＬＭＮ）中の第２のネットワーク機能（ＮＦ）を実装する第３のノード（４３０）との通信を可能にするための、訪問先ネットワーク（ＶＰＬＭＮ）中のセキュリティエッジ保護プロキシ（ＳＥＰＰ）を実装する第２のノード（４４０）によって実施される方法であって、方法は、
－訪問先ネットワーク中の第１のＮＦを実装する第１のノード（４２０）から、ホームネットワーク中の第３のノードと通信するために訪問先ネットワーク中の第１のノードによって使用されるべき、ホームネットワーク中の第３のノードについてのテレスコピック完全修飾ドメイン名（ＦＱＤＮ）についての要求を受信すること（４０２）であって、要求が、ホームネットワーク中の第３のノードのＦＱＤＮを備える、第３のノードについてのテレスコピック完全修飾ドメイン名（ＦＱＤＮ）についての要求を受信すること（４０２）と、
－第１のノードに、第３のノードについてのテレスコピックＦＱＤＮを送信すること（４０６）であって、ホームネットワーク中の第３のノードについてのＦＱＤＮが、第３のノードと通信するために第１のノードによって使用されるように単一のラベルに平坦化される、第３のノードについてのテレスコピックＦＱＤＮを送信すること（４０６）と
を含む、方法。
１０．第１のノードが訪問先ＮＲＦを実装する、第２のノードが訪問先ＳＥＰＰを実装する、および第３のノードがホームＮＲＦを実装する、のうちの１つまたは複数である、実施形態９に記載の方法。
１１．テレスコピックＦＱＤＮについての要求を受信することが、ホームネットワーク中の第３のノードについてのＦＱＤＮを受信することを含む、実施形態９または１０に記載の方法。
１２．テレスコピックＦＱＤＮを送信することが、第３のノードについての平坦化されたＦＱＤＮを送信することを含む、実施形態９から１１のいずれか１つに記載の方法。
１３．テレスコピックＦＱＤＮを送信することが、第３のノードについてのテレスコピックＦＱＤＮを送信することを含み、ホームネットワーク中の第３のノードについてのＦＱＤＮが単一のラベルに平坦化される、実施形態９から１２のいずれか１つに記載の方法。
１４．第１のノードからサービス要求を受信すること（４０８）をさらに含み、サービス要求が、第１のノードに代わってテレスコピックＦＱＤＮを使用して第３のノードと通信するための受信されたテレスコピックＦＱＤＮを備える、実施形態９から１３のいずれか１つに記載の方法。
１５．ホームネットワーク（ＨＰＬＭＮ）中の第２のネットワーク機能（ＮＦ）を実装する第３のノード（４３０）と通信するための、訪問先ネットワーク（ＶＰＬＭＮ）中の第１のＮＦを実装する第１のノード（４２０）であって、第１のノードが、
－実施形態１から８のいずれか１つに記載のステップを実施するように設定された処理回路
を備える、第１のノード（４２０）。
１６．ホームネットワーク（ＨＰＬＭＮ）中の第２のネットワーク機能（ＮＦ）を実装する第３のノード（４３０）との通信を可能にするための、訪問先ネットワーク（ＶＰＬＭＮ）中のセキュリティエッジ保護プロキシ（ＳＥＰＰ）を実装する第２のノード（４４０）であって、第２のノードが、
－実施形態９から１４のいずれか１つに記載のステップを実施するように設定された処理回路
を備える、第２のノード（４４０）。

上記で説明されたいくつかのさらなる実施形態は、以下の様式で要約され得る。
グループＡの実施形態
１．ホームネットワーク（ＨＰＬＭＮ）中の第２のネットワーク機能（ＮＦ）を実装する第３のノード（４３０）と通信するための、訪問先ネットワーク（ＶＰＬＭＮ）中の第１のＮＦを実装する第１のノード（４２０）によって実施される方法であって、方法は、
－第３のノードと通信するべきであると決定すること（４００）と、
－訪問先ネットワーク中のセキュリティエッジ保護プロキシ（ＳＥＰＰ）を実装する第２のノード（４４０）に、第３のノードと通信するために訪問先ネットワーク中の第１のノードによって使用されるべき、ホームネットワーク中の第３のノードについてのテレスコピック完全修飾ドメイン名（ＦＱＤＮ）を要求すること（４０２）と、
－第２のノードから、第３のノードと通信するために第１のノードによって使用されるべき、第３のノードについてのテレスコピックＦＱＤＮを受信すること（４０６）と
を含む、方法。
２．第３のノードについての受信されたテレスコピックＦＱＤＮを使用して訪問先ネットワーク中の第２のノードを介してホームネットワーク中の第３のノードと通信すること（４０８）をさらに含む、実施形態１に記載の方法。
３．第３のノードについての受信されたテレスコピックＦＱＤＮを備えるサービス要求を訪問先ネットワーク中の第２のノードに送ることによって、ホームネットワーク中の第３のノードと通信すること（４０８）をさらに含む、実施形態１または２に記載の方法。
４．サービス要求が、発見要求、Ｏａｕｔｈ２アクセストークン要求またはサブスクリプション要求のうちのいずれか１つである、実施形態３に記載の方法。
５．第１のノードが訪問先ＮＲＦを実装する、第２のノードが訪問先ＳＥＰＰを実装する、および第３のノードがホームＮＲＦを実装する、のうちの１つまたは複数である、実施形態１から４のいずれか１つに記載の方法。
６．テレスコピックＦＱＤＮを要求することが、ホームネットワーク中の第３のノードについてのＦＱＤＮを送ることを含む、実施形態１から５のいずれか１つに記載の方法。
７．テレスコピックＦＱＤＮを受信することが、第３のノードについての平坦化されたＦＱＤＮを受信することを含む、実施形態１から６のいずれか１つに記載の方法。
８．テレスコピックＦＱＤＮを受信することが、テレスコピックＦＱＤＮを受信することを含み、ホームネットワーク中の第３のノードについてのＦＱＤＮが単一のラベルに平坦化される、実施形態１から７のいずれか１つに記載の方法。
９．
－第３のノードと通信するために使用すべきテレスコピックＦＱＤＮを使用して別のノード（ＳＥＰＰ２）にサービス要求を送ることによって第３のノードと通信すること
をさらに含む、実施形態２から７のいずれか１つに記載の方法。

グループＢの実施形態
１０．ホームネットワーク（ＨＰＬＭＮ）中の第２のネットワーク機能（ＮＦ）を実装する第３のノード（４３０）との通信を可能にするための、訪問先ネットワーク（ＶＰＬＭＮ）中のセキュリティエッジ保護プロキシ（ＳＥＰＰ）を実装する第２のノード（４４０）によって実施される方法であって、方法は、
－訪問先ネットワーク中の第１のＮＦを実装する第１のノード（４２０）から、第３のノードと通信するために訪問先ネットワーク中の第１のノードによって使用されるべき、ホームネットワーク中の第３のノードについてのテレスコピック完全修飾ドメイン名（ＦＱＤＮ）についての要求を受信すること（４０２）と、
－第１のノードに、ホームネットワーク中の第３のノードと通信するために使用すべき、第３のノードについてのテレスコピックＦＱＤＮを送信すること（４０６）と
を含む、方法。
１１．第１のノードが訪問先ＮＲＦを実装する、第２のノードが訪問先ＳＥＰＰを実装する、および第３のノードがホームＮＲＦを実装する、のうちの１つまたは複数である、実施形態１０に記載の方法。
１２．第３のノードと通信するために使用すべきテレスコピックＦＱＤＮについての要求を受信することが、ホームネットワーク中の第３のノードについてのＦＱＤＮを受信することを含む、実施形態１０または１１に記載の方法。
１３．第３のノードと通信するために使用すべきテレスコピックＦＱＤＮを送信することが、第３のノードについての平坦化されたＦＱＤＮを送信することを含む、実施形態１０から１２のいずれか１つに記載の方法。
１４．第３のノードと通信するために使用すべきテレスコピックＦＱＤＮを送信することが、第３のノードについてのテレスコピックＦＱＤＮを送信することを含み、ホームネットワーク中の第３のノードについてのＦＱＤＮが単一のラベルに平坦化される、実施形態１０から１３のいずれか１つに記載の方法。
１５．第１のノードからサービス要求を受信すること（４０８）をさらに含み、サービス要求が、第１のノードに代わってテレスコピックＦＱＤＮを使用して第３のノードと通信するための受信されたテレスコピックＦＱＤＮを備える、実施形態１０から１４のいずれか１つに記載の方法。

グループＣの実施形態
１６．ホームネットワーク（ＨＰＬＭＮ）中の第２のネットワーク機能（ＮＦ）を実装する第３のノード（４３０）と通信するための、訪問先ネットワーク（ＶＰＬＭＮ）中の第１のＮＦを実装する第１のノード（４２０）であって、第１のノードが、
－グループＡの実施形態のいずれか１つに記載のステップのいずれかを実施するように設定された処理回路
を備える、第１のノード（４２０）。
１７．ホームネットワーク（ＨＰＬＭＮ）中の第２のネットワーク機能（ＮＦ）を実装する第３のノード（４３０）との通信を可能にするための、訪問先ネットワーク（ＶＰＬＭＮ）中のセキュリティエッジ保護プロキシ（ＳＥＰＰ）を実装する第２のノード（４４０）であって、第２のノードが、
－グループＢの実施形態のいずれか１つに記載のステップのいずれかを実施するように設定された処理回路
を備える、第２のノード（４４０）。

本開示の様々な実施形態が本明細書で説明されたが、それらの実施形態は、限定ではなく、例として提示されたにすぎないことを理解されたい。したがって、本開示の広さおよび範囲は、上記で説明された例示的な実施形態のうちのいずれによっても限定されるべきでない。その上、本明細書で別段に指示されていない限り、またはコンテキストによって明確に否定されていない限り、上記で説明されたエレメントのそれらのすべての考えられる変形形態における任意の組合せが、本開示によって包含される。

さらに、上記で説明され、図面に示されたプロセスまたは方法は、ステップのシーケンスとして示されたが、これは、説明のためにのみ行われた。したがって、いくつかのステップが追加され得、いくつかのステップが省略され得、ステップの順序が並べ替えられ得、いくつかのステップが並行して実施され得ることが企図される。

Claims

ホームネットワーク（ＨＰＬＭＮ）中の第２のネットワーク機能（ＮＦ）を実装する第３のノード（４３０）と通信するための、訪問先ネットワーク（ＶＰＬＭＮ）中の第１のＮＦを実装する第１のノード（４２０）によって実施される方法であって、前記方法は、
－前記第３のノードと通信するべきであると決定すること（４００、５００）と、
－前記訪問先ネットワーク中のセキュリティエッジ保護プロキシ（ＳＥＰＰ）を実装する第２のノード（４４０）のほうへ、前記ホームネットワーク中の前記第３のノードと通信するために前記訪問先ネットワーク中の前記第１のノードによって使用されるべき、前記ホームネットワーク中の前記第３のノードについてのテレスコピック完全修飾ドメイン名（ＦＱＤＮ）についての要求を送ること（４０２、５０２）であって、前記要求が、前記ホームネットワーク中の前記第３のノードのＦＱＤＮを備えることと、
－前記第２のノードから、前記第３のノードについてのテレスコピックＦＱＤＮを受信すること（４０６、５０６）であって、前記ホームネットワーク中の前記第３のノードについての前記ＦＱＤＮが、前記第３のノードと通信するために前記第１のノードによって使用されるように、前記第２のノードによって、単一のラベルに平坦化されることと
を含む、方法。
前記第３のノードについての前記受信されたテレスコピックＦＱＤＮを使用して前記訪問先ネットワーク中の前記第２のノードを介して前記ホームネットワーク中の前記第３のノードと通信すること（４０８、５０８）をさらに含み、前記ホームネットワーク中の前記第３のノードについての前記ＦＱＤＮが単一のラベルに平坦化されている、請求項１に記載の方法。
前記第３のノードについての前記受信されたテレスコピックＦＱＤＮを備えるサービス要求を前記訪問先ネットワーク中の前記第２のノードに送ることによって、前記ホームネットワーク中の前記第３のノードと通信すること（４０８）をさらに含む、請求項１または２に記載の方法。
前記サービス要求が、発見要求、Ｏａｕｔｈ２アクセストークン要求またはサブスクリプション要求のうちのいずれか１つである、請求項３に記載の方法。
前記第１のノードが訪問先ＮＲＦを実装する、前記第２のノードが訪問先ＳＥＰＰを実装する、および前記第３のノードがホームＮＲＦを実装する、のうちの１つまたは複数である、請求項１から４のいずれか一項に記載の方法。
前記第３のノードと通信するために使用すべき前記テレスコピックＦＱＤＮを使用して別のノード（ＳＥＰＰ２）にサービス要求を送ることによって前記第３のノードと通信することをさらに含む、請求項２から５のいずれか一項に記載の方法。
ホームネットワーク（ＨＰＬＭＮ）中の第２のネットワーク機能（ＮＦ）を実装する第３のノード（４３０）との通信を可能にするための、訪問先ネットワーク（ＶＰＬＭＮ）中のセキュリティエッジ保護プロキシ（ＳＥＰＰ）を実装する第２のノード（４４０）によって実施される方法であって、前記方法は、
－前記訪問先ネットワーク中の第１のＮＦを実装する第１のノード（４２０）から、前記ホームネットワーク中の前記第３のノードと通信するために前記訪問先ネットワーク中の前記第１のノードによって使用されるべき、前記ホームネットワーク中の前記第３のノードについてのテレスコピック完全修飾ドメイン名（ＦＱＤＮ）についての要求を受信すること（４０２、５０２）であって、前記要求が、前記ホームネットワーク中の前記第３のノードのＦＱＤＮを備えることと、
－前記第３のノードについての前記テレスコピックＦＱＤＮを生成すること（４０４）と、
－前記第１のノードに、前記第３のノードについての前記テレスコピックＦＱＤＮを送信すること（４０６）であって、前記ホームネットワーク中の前記第３のノードについての前記ＦＱＤＮが、前記第３のノードと通信するために前記第１のノードによって使用されるように単一のラベルに平坦化されることと
を含む、方法。
前記第１のノードが訪問先ＮＲＦを実装する、前記第２のノードが訪問先ＳＥＰＰを実装する、および前記第３のノードがホームＮＲＦを実装する、のうちの１つまたは複数である、請求項７に記載の方法。
前記第１のノードからサービス要求を受信すること（４０８）をさらに含み、前記サービス要求が、前記第１のノードによって受信された前記テレスコピックＦＱＤＮを備え、前記テレスコピックＦＱＤＮは、前記第１のノードに代わって前記第３のノードと通信するために使用される、請求項７または８に記載の方法。
ホームネットワーク（ＨＰＬＭＮ）中の第２のネットワーク機能（ＮＦ）を実装する第３のノード（４３０）と通信するための、訪問先ネットワーク（ＶＰＬＭＮ）中の第１のＮＦを実装する第１のノード（４２０）であって、前記第１のノードが、
－請求項１から６のいずれか一項に記載のステップを実施するように設定された処理回路
を備える、第１のノード（４２０）。
ホームネットワーク（ＨＰＬＭＮ）中の第２のネットワーク機能（ＮＦ）を実装する第３のノード（４３０）との通信を可能にするための、訪問先ネットワーク（ＶＰＬＭＮ）中のセキュリティエッジ保護プロキシ（ＳＥＰＰ）を実装する第２のノード（４４０）であって、前記第２のノードが、
－請求項７から９のいずれか一項に記載のステップを実施するように設定された処理回路
を備える、第２のノード（４４０）。