JP7200237B2

JP7200237B2 - 異なるアーキテクチャ間のプロキシのための方法および装置

Info

Publication number: JP7200237B2
Application number: JP2020519752A
Authority: JP
Inventors: イードンヤオ，; ジュインガン，; ショウリー，; ガンレン，; イーミンウー，; デキンジャン，; ハンビンチャン，
Original assignee: テレフオンアクチーボラゲットエルエムエリクソン（パブル）
Priority date: 2017-10-13
Filing date: 2017-10-13
Publication date: 2023-01-06
Anticipated expiration: 2037-10-13
Also published as: EP3695579A4; JP2020537401A; CN111164945A; WO2019071584A1; US11750708B2; EP3695579A1; US20210377357A1

Description

本開示は、通信ネットワークに関し、特に、通信ネットワークにおける異なるアーキテクチャ間のプロキシのための方法および装置に関する。

通信ネットワークは、例えば、種々のサービスを提供したり、種々の機能を実行したりするために、多くのネットワーク機能（NF）を有することができる。ネットワーク機能は、専用ハードウェア上のネットワーク要素として、専用ハードウェア上で実行されるソフトウェアインスタンスとして、またはクラウドインフラストラクチャなどの適切なプラットフォーム上でインスタンス化される仮想化された機能として実装可能である。

アーキテクチャにおけるネットワーク機能間の相互作用は、アーキテクチャに都合の良いように表現される。通信ネットワークは、複数の異なるアーキテクチャ、例えば、サービスベースアーキテクチャおよびポイントツーポイント（P2P）アーキテクチャを有し得る。

サービスベースのアーキテクチャでは、コントロールプレーン内のネットワーク機能（例：アクセスおよびモビリティ管理機能、AMF）により、他の許可されたネットワーク機能がサービスにアクセスできるようになる。このアーキテクチャはまた、必要に応じてポイントツーポイントリファレンスポイントを含む。図1は、例示的なサービスベースのアーキテクチャを示す。

図1において、NRFとは、ネットワークリポジトリ機能の略称であり、以下に示すように、ネットワーク機能サービスの登録、登録解除、許可、探索をサポートするネットワーク機能である。

ネットワーク機能サービスの登録・登録解除

NRFが、利用可能なNFおよびそれらのサポートされるサービスの情報を適切に維持するために、各NFは、それがサポートするNFサービスのリストをNRFに通知する。

NFは、NFが初めて動作可能になったとき（登録動作）、または、例えばスケーリング動作の後にトリガされたNF (更新動作）内の個々のNFサービスインスタンスのアクティブ化／非アクティブ化の時に、この情報をNRFに利用可能にすることができる。NFは、サポートするNFサービスのリストを登録しながら、NFサービスごとに、NFサービスが消費する準備ができている通知サービスのタイプごとに、NF登録中にNRFに通知エンドポイント情報を提供することができる。NFは、NFサービス関連パラメータを更新または削除することもできる（たとえば、通知エンドポイント情報を削除するため）。あるいは、別の許可されたエンティティ（運用管理保守、OA＆M、機能など）が、NFサービスライフサイクルイベント（インスタンス化、終了、アクティブ化、または非アクティブ化に応じて登録または登録解除動作）によってトリガされたNFに代わって、NRFに通知することができる。NRFへの登録は、インスタンス化時のキャパシティとコンフィギュレーション（構成）の情報を含む。

NF は、制御された方法で、ネットワークを適切にシャットダウンまたは切断しようとしているときに、NRF から登録を解除することもできる。NFが、計画されていないエラー（例えば、NFクラッシュ、またはネットワーク問題の存在）のために利用不能になるか、または到達不能になる場合、許可されたエンティティは、NRFからNFを登録解除しなければならない。

ネットワーク機能サービスの許可

NFサービス許可は、NFサービスコンシューマが、例えば、NFのポリシー、サービングオペレータからのポリシー、オペレータ間の合意に従って、NFサービスプロバイダによって提供されるNFサービスにアクセスすることを許可されることを保証する。

サービス許可情報は、NFサービスプロデューサのNFプロファイル内の構成要素の1つである。これは、NFサービスプロデューサのNFサービスを消費することが許可されたNFタイプを含むものとする。

ローミング契約およびオペレータポリシーのために、NFサービスコンシューマは、UE／加入者／ローミングの情報およびNFタイプに基づいて、許可され、サービス許可は2つのステップを伴うことができる。

・NFサービスコンシューマが、NFサービス探索手順中に、要求されたNFサービスプロデューサを探索することを許可されているかどうかをチェックする。これは、NRFによるNF毎の粒度で実行される。

・NFサービスコンシューマが、NFサービスを消費するために、要求されたNFサービスプロデューサにアクセスすることを許可されているかどうかをチェックする。これは、UE ごと、サブスクリプション（加入契約）ごと、またはローミング契約の粒度で実行される。このタイプのNF サービス許可は、関連するNF サービスロジックに組み込まれている。

ネットワーク機能サービス探索

予想されるNF およびNF サービスの情報がリクエスタNF でローカルに設定されていない限り、NF サービスの探索はNRF を介して実施される。

要求されたNFサービスへのアクセスを可能にするために、要求元NFは、要求されたサービスのサービスパラメータを提供して、ターゲットNFを探索することによって、NFサービスディスカバリ（探索）を開始する。

選択されたメッセージ・ルーティング・モデルに応じて、NRFは、ターゲットNFを選択するために、IPアドレスまたは完全修飾ドメイン名（FQDN）、あるいは関連サービスおよび／またはNFの識別情報をリクエスタNFに提供することができる。その情報に基づいて、リクエスタNFは、特定のNFサービスを提供することができるNFを選択することができる。

PLMN(公衆陸上移動体ネットワーク)にわたるNF探索のために、リクエスタNFは、ターゲットNFのPLMN IDをNRFに提供する。ローカルPLMN内のNRFは、リクエスタNFによって提供されるPLMN IDを使用してターゲットPLMN固有のクエリを形成することによって、ターゲットPLMN内のNRFに到達する。

ローカルPLMN のNRF は、ターゲットPLMN のNRF と対話して、ターゲットNF のIP アドレスまたはFQDN、または関連するサービスの識別情報を取得する。

図2は、任意の2つのネットワーク機能間のポイントツーポイントリファレンスポイントによって記述されるネットワーク機能のペア間の相互作用に焦点を当てた例示的なP2Pアーキテクチャを示す。P2Pアーキテクチャでは、ネットワーク機能間の相互作用は厳密に定義され、インターフェース、メッセージなどの各々は厳密なシーケンス、使用法、および定義を有する。

本開示の発明者は、アーキテクチャ内のネットワーク機能が、別のアーキテクチャ内のネットワーク機能と双方向で容易には通信できず、異なるアーキテクチャ内でのネットワーク機能間の通信を困難にすることを見つけた。例えば、SBAおよびP2Pアーキテクチャの場合、本開示の発明者は、（１）SBAに含まれるP2Pリファレンスポイントがネットワークの複雑さを増大させること、（２）SBA内のネットワーク機能がP2Pアーキテクチャ内のネットワーク機能と容易に通信することができず、逆もまた同様であること、（３）5Gコアと進化型パケットコア（EPC）との間の相互作用がサービスベースにできないこと、という課題を見出した。

上記の課題のうちの少なくともいくつかを解決または軽減するために、本発明者らは、異なるアーキテクチャ間に新しいプロキシを追加して、NFに対するコンフィギュレーション／挙動変更の影響なしに、異なるアーキテクチャ内のNF間の通信を可能にすることを提案する。

本開示の一態様によれば、第2のアーキテクチャにおいてリクエスタNFから第1のアーキテクチャにおけるサービスに対するリクエスト（要求）を受信することと、リクエスタNFの代わりにサービングNFからサービスのレスポンス（応答）を取得することと、サービスのレスポンスに基づいてリクエスタNFにさらなるレスポンスを送信することと、を有するプロキシ方法が提供される。当該プロキシ方法は、NFまたはNF内の機能エンティティ上に実装されてもよい。

本開示の別の態様によれば、第2のアーキテクチャにおいてリクエスタNFから第1のアーキテクチャにおけるサービスのリクエストを受信するための受信ユニットと、リクエスタNFの代わりにサービスのレスポンスをサービングNFから取得するための取得ユニットと、サービスのレスポンスに基づいてリクエスタNFにさらなるレスポンスを送信するための送信ユニットとを備えるプロキシデバイスが提供される。プロキシデバイスは、NFまたはNF内の機能エンティティであってもよい。

本開示のさらに別の態様によれば、プロセッサと、プロセッサによって実行されたときにプロキシデバイスに上記の方法を実行させる命令を記憶しているメモリと、を有するプロキシデバイスが提供される。

上記で提供される解決策は、以下の利点を有する。

・アーキテクチャの標準定義と機能要件に純粋に沿ったままアーキテクチャ内でNFを維持でき、

・NFに影響を与えることなく、アーキテクチャ内でNFを別のアーキテクチャのNFに接続されることを維持でき、

・ネットワークの導入を簡素化することができる。

ここで、本明細書の実施形態は、実施形態を示す添付の図面を参照することによって、以下の詳細な説明においてより詳細に説明される：
図1は、例示的なサービスベースのアーキテクチャを概略的に示す。図2は、例示的なP2Pアーキテクチャを概略的に示す。図3は、本開示のプロキシ方法のフローチャートを概略的に示す。図4は、プロキシデバイスによる例示的なサービス登録を概略的に示す。図5は、本開示の例示的な実施形態を概略的に示す。図6は、本開示の別の例示的な実施形態を概略的に示す。図7は、本開示のプロキシデバイスの概略ブロック図である。図8は、本開示のプロキシデバイスの別の概略ブロック図である。図面の要素は、必ずしも互いに相対的な縮尺であるとは限らない。図面全体を通して、同様の番号は同様の要素を指す。

本明細書の実施形態は、添付の図面を参照して、以下でより完全に説明される。しかしながら、本明細書の実施形態は、多くの異なる形態で具現化されてもよく、添付の特許請求の範囲を限定するものとして解釈されるべきではない。

本明細書で使用される用語は、特定の実施形態を説明するためだけのものであり、限定することを意図するものではない。本明細書で使用される場合、単数形「a」、「an」、および「the」は、文脈が明確にそうでないことを示さない限り、複数形も含むことが意図される。用語「備える」、「含む」、および／または「含む」は、本明細書で使用される場合、述べられた特徴、整数、ステップ、操作、要素、および／または構成要素の存在を指定するが、1つまたは複数の他の特徴、整数、ステップ、操作、要素、構成要素、および／またはそれらのグループの存在または追加を排除しないことがさらに理解されるであろう。

また、クレーム要素を修飾する「第1」、「第2」、「第3」等のような序数詞のクレーム内での使用は、それ自体では、あるクレーム要素の優先度、優位度、順序は、他のクレーム要素又は方法の行為が実行される時間的順序を勝るものではなく、ある名称を付与されたクレーム要素と、同一名称を有する他の要素（ただし、序数詞を使用する場合を除く）とを区別するためのラベルとしてのみ使用される。

別段の定義がない限り、本明細書で使用されるすべての用語（技術用語および科学用語を含む）は、一般に理解されるものと同じ意味を有する。さらに、本明細書で使用される用語は、本明細書および関連技術の文脈におけるそれらの意味と一致する意味を有すると解釈されるべきであり、本明細書で明示的にそのように定義されない限り、理想化された、または過度に形式的な意味で解釈されるべきでないことが理解されるであろう。

上述のように、従来技術の欠点の少なくともいくつかを解決または軽減するために、本発明者らは、異なるアーキテクチャ間に新しいプロキシを追加して、NFに対するコンフィギュレーション／挙動変更の影響なしに、異なるアーキテクチャ内のNF間の通信を可能にすることを提案する。

本開示のプロキシ方法のフローチャートが図3に示されており、この方法は、方法300として図3に示されており、以下のステップ、すなわち、第2のアーキテクチャにおいてリクエスタNFから第1のアーキテクチャにおけるサービスのリクエスト（要求）を受信するステップ301と、リクエスタNFに代わってサービスのレスポンス（応答）をサービングNFから取得するステップ302と、サービスのレスポンスに基づいてリクエスタNFにさらなるレスポンスを送信するステップ303とを含む。プロキシ方法は、NFまたはNF内の機能エンティティ上で実施され得る。

ここで、さらなる実施形態を、SBAおよびP2Pアーキテクチャと関連付けて説明する。ここでは、特定の用語が使用されるが、実施形態は、それらの特定の用語に限定されるものではなく、全ての類似のエンティティに適用され得ることが理解されるであろう。例えば、本明細書における「デバイス」は、例えば、装置、ステーション（局）、ノードなどを指すことができる。本明細書のさらなる実施形態は、SBAおよびP2Pアーキテクチャの文脈で説明されるが、異なるアーキテクチャにおけるネットワーク機能間の対話が所望される場合、実施形態は、他の異なるアーキテクチャにも適用され得ることも理解されよう。

I. 第1のアーキテクチャはP2Pアーキテクチャであり、第2のアーキテクチャはSBAである。

この状況では、サービスを要求するリクエスタNFはSBAに配置され、サービスを提供するサービングNFはP2Pアーキテクチャに配置される。

図4は、この状況に対するプロキシデバイスによる例示的なサービスレジストレーション（登録）を概略的に示す。SBA内のNF 10は、そのサービスをNRF 20に登録することができる（401）。P2Pアーキテクチャ内のNF 40によって提供されるサービスがNRF 20に登録されていない場合、当該サービスは、NF 40に代わって、例えばプロキシデバイス30によって、NRF 20に登録されてもよい（403）。NF 40に代わってサービス登録を行う前に、初期化が必要な場合、NF 40とのP2Pコネクションが、例えば、プロキシデバイス30とNF 40との間で確立される（402）。

図5は、この状況に対する本開示の例示的な実施形態を概略的に示す。SBA内のNF 10がターゲットNFがまだどのNFであるかを知らない場合、NF 10は、NRF 20の助けを借りて、NF 10によって求められているサービスに関連している特定のターゲットNFを探索する（501）。この例示的な実施形態では、サービスは、例えば、NRF 20上に登録され、P2Pアーキテクチャ内のNF 40によって提供されるサービスであり、ターゲットNFは、例えば、プロキシデバイス30を備えているNF、またはNF 40の代わりにNRF 20上にサービスを登録したプロキシデバイス30である。さらに、NRF 20のNFサービス許可は、サービスの許可が必要な場合に、サービスリクエスタNF 10は、希望のNFサービスにアクセスすることを許可される（501）ことを保証する。いで、NF 10は、発見されたNF、例えば、この例示的な実施形態ではプロキシデバイス30に、サービスに対するサービスリクエストを送信する（502）。プロキシデバイス30は、サービスリクエストを受信し、要求されたサービスがP2Pアーキテクチャ内のサービングNF 40によって提供されることを実現し、次いで、プロキシデバイス30は、例えば、NF 40からレスポンスを得るために、サービングNF 40とP2Pコールフローを開始することによって、リクエスタNF 10に代わって、サービングNF 40からサービスのレスポンスを取得する（503）。レスポンスを受信すると、プロキシデバイス30は、NF 40からのレスポンスに基づいて、さらなるレスポンスをリクエスタNF 10に送信する（504）。

II. 第1のアーキテクチャはSBAであり、第2のアーキテクチャはP2Pアーキテクチャである。

この場合、サービスを要求するリクエスタ（要求元）NF はP2P アーキテクチャに配置され、サービスを提供するサービングNF はSBA に配置される。

図6は、この状況に対する本開示の例示的な実施形態を概略的に示す。P2PアーキテクチャにおけるNF 40は、特定のサービス、例えばプロキシデバイス30に対するコールフロー要求を開始する（601）。プロキシデバイス30は、P2Pコールフローリクエストを受信し、要求されたサービスがSBA内のサービングNFによって提供されることを実現する。プロキシデバイス30が、サービングNFがどのNFであるか（例えば、サービスに関する情報およびサービングNFがプロキシデバイス30上で既にローカルに構成されているか）を既に知っている場合、プロキシデバイス30は、サービングNF 10にサービスに対するさらなるリクエストを送ることによって、リクエスタNF 40の代わりに、サービングNF、例えば、例示的な実施形態ではNF 10からサービスのレスポンスを取得することができる（603）。プロキシデバイス30が、サービングNFがどのNFであるかを知らない場合、プロキシデバイス30は、サービスを求めるさらなるリクエストをサービングNF、例えば、例示的な実施形態ではNF 10に送信する（603）前に、NRF 20の助けを借りて、要求されたサービスを提供するサービングNFを探索することができる（602）。プロキシデバイス30は、サービスの許可が必要な場合、NRF 20の助けを借りてサービスの許可を得ることもできる（602）。NF 10は、サービスに対するさらなるリクエストを処理し、サービスレスポンスでプロキシデバイス10に応答する（604）。レスポンスを受信すると、プロキシデバイス30は、NF 10からのレスポンスに基づいて、さらなるレスポンス、たとえば、p2pコールフローレスポンスをリクエスタNF 40に送信する（605）。

図7は、本開示のプロキシデバイスの概略ブロック図であり、図中のプロキシデバイス700として図示されている。プロキシデバイス700は、第2のアーキテクチャにおいてリクエスタNFから第1のアーキテクチャにおけるサービスのリクエストを受信するための受信ユニット701と、リクエスタNFに代わってサービスのレスポンスをサービングNFから取得するための取得ユニット702と、サービスのレスポンスに基づいてリクエスタNFにさらなるレスポンスを送信するための送信ユニット703とを含む。

本明細書で説明されるプロキシデバイス700は、実施形態で説明されるプロキシデバイスの1つまたは複数の機能を実装するプロキシデバイス700が、ユニット701、703、および703だけでなく、実施形態で説明されるプロキシデバイスの1つまたは複数の機能を実装するための他のユニットも備えることができるように、様々なユニットによって実装されてもよく、たとえば、プロキシデバイス700は、サービングNFに代わってサービスをサービスベースのアーキテクチャに登録するための登録ユニットをさらに含むことができることを諒解されたい。さらに、プロキシデバイス700は、それぞれの別個の機能のための別個のユニットを備えてもよく、または単一のユニットが2つ以上の機能を実行するように構成されてもよい。さらに、これらのユニットは、ハードウェア、ファームウェア、ソフトウェア、またはそれらの組合せで実装されてもよい。

ブロック図および／またはフローチャートのブロックと、ブロック図および／またはフローチャートの複数のブロックの組合せとは、コンピュータプログラム命令によって実装され得ることを理解されたい。これらのコンピュータプログラム命令は、汎用コンピュータ、専用コンピュータ、および／または他のフィールドプログラマブルゲートアレイデータ処理装置のプロセッサに提供されて、コンピュータおよび／または他のフィールドプログラマブルゲートアレイデータ処理装置のプロセッサを介して実行される命令が、ブロック図および／またはフローチャートの1つまたは複数のブロックで指定された機能／動作を実施するための手段を作成するように、マシンを生成することができる。

さらに、本発明の解決策は、命令実行システムによって、またはそれとコネクションて使用するために、媒体内に具現化されたコンピュータ使用可能またはコンピュータ可読プログラムコードを有するメモリー上のコンピュータプログラムの形態をとることができる。本書の文脈では、メモリは、命令実行システム、装置、またはデバイスによって、またはそれと関連して使用されるために、プログラムを収容、記憶、または通信するようになっている任意の媒体であってもよい。

したがって、本開示はまた、図8に示されるように、プロセッサ801およびメモリ802を含むプロキシデバイス800を提供する。プロキシデバイス800において、メモリ802は、プロセッサ801によって実行されると、プロキシデバイス800に、実施形態で上述されたプロキシ方法を実行させる命令を格納する。

本明細書は、多くの具体的な実装の詳細を含むが、これらは、任意の実装または特許請求され得るものの範囲に対する限定として解釈されるべきではなく、むしろ、特定の実装の特定の実施形態に固有であり得る特徴の説明として解釈されるべきである。
別個の実施形態の文脈で本明細書に記載される特定の特徴は、単一の実施形態において組み合わせて実施することもできる。逆に、単一の実施形態の文脈で説明される様々な特徴は、複数の実施形態で別々に、または任意の適切なサブコンビネーションで実装することもできる。さらに、特徴は、特定の組合せで動作するものとして上記で説明されてもよく、そのようなものとして最初に特許請求されてもよいが、特許請求される組合せからの1つまたは複数の特徴は、場合によっては、その組合せから削除されてもよく、特許請求される組合せは、サブ組合せまたはサブ組合せの変形に向けられてもよい。

当業者には、技術が進歩するにつれて、本発明の概念を様々な方法で実施できることが明らかであろう。上述の実施形態は、本開示を限定するのではなく、説明するために与えられ、当業者が容易に理解するように、本開示の精神および範囲から逸脱することなく、修正および変形を行うことができることを理解されたい。そのような修正および変形は、本開示および添付の特許請求の範囲の範囲内にあると考えられる。開示の保護範囲は、添付の特許請求の範囲によって定義される。

Claims

プロキシデバイスによって実行されるセルラー通信におけるコアネットワークのためのプロキシ方法（300）であって、
第2のアーキテクチャにおけるリクエスタNF（ネットワーク機能）から第1のアーキテクチャにおけるサービスのリクエストを受信すること（301）であって、ここで、前記第1のアーキテクチャは、ポイントツーポイント（P2P）アーキテクチャであり、かつ、前記第2のアーキテクチャは、サービスベースアーキテクチャであるか、または、前記第1のアーキテクチャは、サービスベースアーキテクチャであり、かつ、前記第2のアーキテクチャは、P2Pアーキテクチャである、ことと、
前記サービスのレスポンスを取得すること（302）であって、
前記プロキシデバイスがどのNFがサービングNFであるかを知らない場合、前記リクエストされたサービスを提供する当該サービングNFを探索し、ここで、前記探索は、ネットワークリポジトリ機能（NRF）の助けを借りて実行され、
前記サービングNFが発見された後に、前記サービスについてのさらなるリクエストを前記サービングNFに送信し（603）、
前記プロキシデバイスが前記リクエストされたサービスが前記第1のアーキテクチャにおけるサービングNFによって提供されることを知っている場合、前記リクエスタNFに代わって前記サービスのレスポンスをサービングNFから取得し、ここで、前記第1のアーキテクチャがP2Pアーキテクチャであり、かつ、前記第2のアーキテクチャがサービスベースアーキテクチャである場合、当該レスポンスは前記サービングNFとP2Pコールフローを開始することによって取得される、取得することと、
前記レスポンスを取得すると、前記サービスの前記レスポンスに基づいて、前記第2のアーキテクチャにおける前記リクエスタNFにさらなるレスポンスを送信すること（303）
を有し、
前記第1のアーキテクチャがP2Pアーキテクチャであり、かつ、前記第2のアーキテクチャがサービスベースアーキテクチャである場合、前記リクエストはサービスリクエストであり、かつ、前記さらなるレスポンスをサービスレスポンスであり、
前記第1のアーキテクチャがサービスベースアーキテクチャであり、かつ、前記第2のアーキテクチャがP2Pアーキテクチャである場合、前記リクエストはP2Pコールフローリクエストであり、かつ、前記さらなるレスポンスはP2Pコールフローレスポンスである、プロキシ方法。
請求項1に記載のプロキシ方法（300）であって、前記プロキシ方法は、NFまたはNF内の機能エンティティ上に実装される、プロキシ方法。
請求項1に記載のプロキシ方法（300）であって、前記サービスを前記サービングNF (40）に代わって前記サービスベースアーキテクチャに登録すること（403）をさらに含む、プロキシ方法。
請求項1に記載のプロキシ方法（300）であって、前記取得することは、前記サービス（602）に対する許可を得ることを含む、プロキシ方法。
セルラー通信におけるコアネットワークのためのプロキシデバイス（700）であって、
第2のアーキテクチャにおけるリクエスタNF（ネットワーク機能）から第1のアーキテクチャにおけるサービスに対するリクエストを受信するための受信ユニット（701）であって、前記第1のアーキテクチャは、ポイントツーポイント（P2P）アーキテクチャであり、かつ、前記第2のアーキテクチャは、サービスベースアーキテクチャであるか、または、前記第1のアーキテクチャは、サービスベースアーキテクチャであり、かつ、前記第2のアーキテクチャは、P2Pアーキテクチャである、受信ユニットと、
取得部であって、
前記プロキシデバイスがどのNFがサービングNFであるかを知らない場合、前記リクエストされたサービスを提供する当該サービングNFの探索し、ここで、前記探索は、ネットワークリポジトリ機能（NRF）の助けを借りて実行され、
前記サービングNFが発見された後に、前記サービスについてのさらなるリクエストを前記サービングNFに送信し（603）、
前記プロキシデバイスが前記リクエストされたサービスが前記第1のアーキテクチャにおけるサービングNFによって提供されることを知っている場合、前記リクエスタNFに代わって、サービングNFから前記サービスのレスポンスを取得し、ここで、前記第1のアーキテクチャがP2Pアーキテクチャであり、かつ、前記第2のアーキテクチャがサービスベースアーキテクチャである場合、当該レスポンスは前記サービングNFとP2Pコールフローを開始することによって取得される、取得部（702）と、
前記レスポンスを取得すると、前記サービスの前記レスポンスに基づいて前記リクエスタNFにさらなるレスポンスを送信するための送信部（703）と、
を有し、
前記第1のアーキテクチャがP2Pアーキテクチャであり、かつ、前記第2のアーキテクチャがサービスベースアーキテクチャである場合、前記リクエストはサービスリクエストであり、かつ、前記さらなるレスポンスをサービスレスポンスであり、
前記第1のアーキテクチャがサービスベースアーキテクチャであり、かつ、前記第2のアーキテクチャがP2Pアーキテクチャである場合、前記リクエストはP2Pコールフローリクエストであり、かつ、前記さらなるレスポンスはP2Pコールフローレスポンスである、プロキシデバイス。
請求項5に記載のプロキシデバイス（700）であって、前記プロキシデバイスは、NFまたはNF内の機能エンティティである、プロキシデバイス。
請求項5に記載のプロキシデバイス（700）であって、前記サービスを前記サービングNF (40）に代わって前記サービスベースアーキテクチャに登録する（403）ための登録ユニットをさらに有する、プロキシデバイス。
請求項5に記載のプロキシデバイス（700）であって、前記取得することは、前記サービス（602）に対する許可を得ることを含む、プロキシデバイス。
セルラー通信におけるコアネットワークのためのプロキシデバイス（800）であって、
プロセッサ（801）と、
前記プロセッサによって実行されると、前記プロキシデバイスに、請求項1～4のいずれか1項に記載のプロキシ方法を実行させる命令を記憶したメモリ（802）と、
を有するプロキシデバイス。