JP7600413B2 - コアネットワークにおいてサービングネットワークノードを動的に発見するための方法、ネットワークノード、及びコンピュータ読取可能媒体 - Google Patents

Description

本開示は、全体として通信技術の技術分野に関するものであり、特に、コアネットワークにおいてサービングネットワークノードを動的に発見するための方法、ネットワークノード、及びコンピュータ読取可能媒体に関するものである。

本セクションは、本開示で説明される技術の種々の実施形態の背景を提供することを意図している。本セクションの説明は、追求されうるが必ずしも以前に考えられた又は追求されたものではない概念を含みうる。したがって、本明細書において別段の記載がない限り、本セクションで説明されるものは、本開示の説明及び／又は特許請求の範囲に対する先行技術ではなく、単にこのセクションに含めることによって先行技術であることを認めるものではない。

５ＧネットワークにおけるイーサネットタイプＰＤＵセッション
５ＧネットワークにおけるイーサネットタイプのＰＤＵセッションの典型的なユースケースには、５Ｇローカルエリアネットワーク（ＬＡＮ）タイプのサービス、タイムセンシティブネットワーク（ＴＳＮ：Time Sensitive Network）等が含まれるが、これらに限定されない。

3GPP TS 22.261v18.1.0のように、５Ｇ ＬＡＮタイプのサービスは、以下の異なるタイプのトラフィックを有しうる：
１）５Ｇ ＬＡＮタイプサービスのためのホーム環境（センサからビデオストリーミングまで、グループごとに比較的少量のＵＥ、多くのデバイスは時々しか使用されない）において典型的に見られるトラフィックシナリオ；
２）５Ｇ ＬＡＮタイプサービスのためのオフィス環境（センサから、例えば会議用の非常に高いデータレートまで、グループごとに中程度の数のＵＥ）に典型的に見られるトラフィックシナリオ；
３）５Ｇ ＬＡＮタイプサービスのための工業環境（センサから遠隔制御まで、グループごとに大量のＵＥ）で典型的に見られるトラフィックシナリオ。

図１Ａ及び図１Ｂは、3GPP TS 23.501 v16.7.0から引用されたものであり、これらは、ローカルスイッチ及びＮ１９トンネルをそれぞれ使用する、５Ｇ ＬＡＮタイプサービスをサポートするためのユーザプレーンアーキテクチャを概略的に示す。

同じ領域内のＵＥの場合、図１Ａに示されるようなローカルスイッチベースのアーキテクチャが、他の領域内のＵＥとの通信用の図１Ｂに示されるようなＮ１９ベースのアーキテクチャとともに、より良好な体感品質（ＱｏＥ：Quality of Experience）を提供するために使用されうる。

3GPP TS 29.122 v17.0.0で論じられたように、第３世代パートナシッププロジェクト（３ＧＰＰ(登録商標)）ネットワークは、アプリケーション機能（ＡＦ）が、（インターネットプロトコル（ＩＰ）又はイーサネット）タイプのパケットデータユニット（ＰＤＵ）セッション内の（１つ以上の）サービスデータフローのために必要とされるサービス品質（ＱｏＳ）を有するアプリケーションサーバ（ＡＳ）セッションをセットアップすることを可能にする。特に、信頼できないＡＦの場合、ネットワーク公開機能（ＮＥＦ）のような公開機能を介して、必要とされるＱｏＳを有するＡＳセッションをセットアップすることが可能になる。ＡＦ要求は、ＵＥアドレス（例えば、ＩＰｖ４、又はＩＰｖ６、又はメディアアクセス制御（ＭＡＣ：Media Access Control）アドレス）、（ＩＰ又はイーサネット）サービスデータフロー情報、ＩＰｖ４アドレスドメイン識別子、ＱｏＳ参照識別子、及び他の属性を含みうる。

ＮＥＦがそのようなＡＦ要求を受信すると、ＮＥＦは、対応する（ＩＰ又はイーサネット）ＰＤＵセッションのサービングポリシー制御機能（ＰＣＦ）を見つける必要があり、次いで、必要とされるＱｏＳをセットアップするために、Ｒｘ又はサービスベースインタフェース（ＳＢＩ）のいずれかを介してＰＣＦとのインタラクションを行う。

ＩＰタイプＰＤＵセッションの場合、ＩＰアドレスは、５Ｇコア（５ＧＣ）によって、当該ＩＰタイプＰＤＵセッションと関連付けられたＵＥに対して割り当てられ、ＡＦ要求で受信される。サービングＰＣＦを動的な方法で見つけることを可能にするために、ＮＥＦは、最初に、クエリパラメータとしてＩＰアドレスを使用することによって、ネットワークリポジトリ機能（ＮＲＦ）を介してバインディングサポート機能（ＢＳＦ）を発見する。ＢＳＦは、ある範囲のＩＰアドレスに対応することが知られており、このため、ＮＥＦは、ＡＦ要求で受信されたＩＰアドレスを使用することによって、ＢＳＦについてＮＲＦに問い合わせを行いうる。ＢＳＦは、対応するＩＰタイプＰＤＵセッションをサービングするＰＣＦの（ＰＤＵ）セッションバインディング情報を保持している。このため、ＮＥＦは更に、ＩＰアドレス（及び、オプションとして、ＩＰｖ４アドレスドメイン識別子）を使用することによって、対応するＰＣＦの（ＰＤＵ）セッションバインディング情報を見つけるためにＢＳＦに問い合わせを行う。その結果、ＮＥＦは、セッションバインディング情報内のサービングＰＣＦアドレス情報を取得しうる（即ち、サービングＰＣＦを発見しうる）。

3GPP TS 23.501 v16.7.0に規定されるように、イーサネットタイプＰＤＵセッションの場合、ＭＡＣアドレスも、ＭＡＣアドレスを介したＩＰアドレスも、イーサネットタイプＰＤＵセッションと関連付けられたＵＥに対して５ＧＣによって割り当てられない。このため、ＢＳＦは、いずれのＭＡＣアドレスをサービング可能であるかを認識しない。

イーサネットタイプＰＤＵセッションの場合、AFsessionWithQoS、ChargeableParty、及び他の適切なＡＰＩ等の、ＮＥＦにおける現在のＡＰＩは、イーサネットタイプＰＤＵセッションと関連付けられたＵＥのＵＥ ＭＡＣアドレス、イーサネットサービスデータフロー情報（本開示全体を通して「イーサネットフロー情報」とも呼ばれる）等のみを提供し、イーサネットタイプＰＤＵセッションのこれらの属性は、前述のＩＰタイプＰＤＵセッションと同様に動的な方法でＮＥＦがサービングＰＣＦを見つけるのには十分ではなく、特に、ＮＥＦが、ＵＥ ＭＡＣアドレス、イーサネットサービスデータフロー情報等の、ＡＰＩにおいて現在提供されているこれらの属性を使用することによってＮＲＦを介して正しいＢＳＦを見つけることはできない。現在、対応するイーサネットタイプＰＤＵセッションのサービングＰＣＦをＮＥＦがどのように動的に識別／発見するかについては定められていない。

例えば、ＮＥＦが、イーサネットタイプＰＤＵセッションの（１つ以上の）サービスデータフローに対してＱｏＳをセットアップするために、（ＵＥ ＭＡＣアドレス、イーサネットサービスデータフロー情報等の属性を有する）Nnef_AFsessionWithQoS_Createサービスオペレーションを、ＡＦから受信した場合に、（対応するＰＤＵセッションをサービングするＰＣＦの（ＰＤＵ）セッションバインディング情報を保持する）ＢＳＦを、ＭＡＣアドレスを使用することによってＮＲＦから発見する方法はない。なぜなら、前述のように、ＭＡＣアドレスもＭＡＣアドレスを介したＩＰアドレスも、イーサネットタイプＰＤＵセッションのために５ＧＣによってＵＥに対して割り当てられず、それ故に、いずれのＭＡＣアドレスをサービング可能であるかをＢＳＦは認識しないからである。したがって、ＮＥＦは、対応するイーサネットタイプＰＤＵセッションをサービングするＰＣＦを動的に発見することができない。

上述の問題を解決するために、本開示の実施形態は、イーサネットタイプＰＤＵセッションをサービングする、外部グループ識別子（ＩＤ）、データネットワーク名（ＤＮＮ：Data Network Name）、及び／又は単一ネットワークスライス選択支援情報（Ｓ－ＮＳＳＡＩ：Single-Network Slice Selection Assistance Information）等の、ネットワーク関連識別情報を、ＮＥＦがＡＦに公開することを提案する。

これにより、ＡＦは、イーサネットＰＤＵタイプセッション、イーサネットサービスデータフロー情報等と関連付けられたＵＥについてのＵＥ ＭＡＣアドレス、並びに新たに導入された外部グループＩＤ、ＤＮＮ及び／又はＳ－ＮＳＳＡＩ等の属性を有するイーサネットタイプセッションについて、対応するサービスを要求する。したがって、ＮＥＦは、関係するイーサネットタイプＰＤＵセッションをサービングするＰＣＦを動的に発見するために、ＵＥ ＭＡＣアドレス、外部グループＩＤ、又はＤＮＮ及び／又はＳ－ＮＳＳＡＩを使用しうる。

本開示の第１の態様によれば、イーサネットタイプのセッションをサービングするＰＣＦをコアネットワークのＮＥＦが動的に発見することを容易にするための、ＡＦにおける方法が提供される。本方法は、イーサネットタイプセッションについてのサービス要求メッセージをＮＥＦへ送信することを含み、サービス要求メッセージは、イーサネットタイプセッションについてのネットワーク関連識別情報を含む。

例示的な実施形態では、イーサネットタイプセッションについてのネットワーク関連識別情報は、ＡＦにおいて事前設定されるか又は動的に提供される。

例示的な実施形態では、イーサネットタイプセッションについてのネットワーク関連識別情報は、イーサネットタイプセッションについてのＤＮＮと、イーサネットタイプセッションについてのＳ－ＮＳＳＡＩとのうちの少なくとも１つを含む。

例示的な実施形態では、サービス要求メッセージは、イーサネットタイプセッションと関連付けられたＵＥについてのＵＥ ＭＡＣアドレスを更に含む。

例示的な実施形態では、本方法は、要求されたサービスがイーサネットタイプセッションのために正常に呼び出されたか否かを示す応答を、ＮＥＦから受信することを更に含む。

例示的な実施形態では、サービス要求メッセージは、イーサネットタイプセッションのサービスデータフローについての必要とされるＱｏＳを管理するための要求メッセージと、イーサネットタイプセッションの課金可能パーティを管理するための要求メッセージとのうちの少なくとも１つを含む。

本開示の第２の態様によれば、イーサネットタイプセッションについてのＰＣＦを動的に発見するための、コアネットワークのＮＥＦにおける方法が提供される。本方法は、イーサネットタイプセッションについてのサービス要求メッセージをＡＦから受信することであって、サービス要求メッセージが、イーサネットタイプセッションについてのネットワーク関連識別情報を含む、ことと、ネットワーク関連識別情報に基づいて、イーサネットタイプセッションについてのＰＣＦのバインディング情報を保持するＢＳＦを発見することとを含む。

例示的な実施形態では、サービス要求メッセージは、イーサネットタイプセッションと関連付けられたＵＥのＵＥ ＭＡＣアドレスを更に含む。

例示的な実施形態では、本方法は、ＢＳＦに問い合わせることによって、ＡＦから受信されたＵＥ ＭＡＣアドレスを使用してＰＣＦを発見することを更に含む。

例示的な実施形態では、本方法は、ネットワーク関連識別情報に基づいてＰＣＦを発見することを更に含む。

例示的な実施形態では、イーサネットタイプセッションについてのネットワーク関連識別情報は、ＡＦにおいて事前設定されるか又はＡＦに動的に提供される。

例示的な実施形態では、イーサネットタイプセッションについてのネットワーク関連識別情報は、イーサネットタイプセッションについてのＤＮＮと、イーサネットタイプセッションについてのＳ－ＮＳＳＡＩとのうちの少なくとも１つを含む。

例示的な実施形態では、ＢＳＦは、ＮＥＦがイーサネットタイプセッションについてのＤＮＮ及びイーサネットタイプセッションについてのＳ－ＮＳＳＡＩのうちの少なくとも１つを使用してＮＲＦに問い合わせることによって、発見される。

例示的な実施形態では、本方法は、イーサネットタイプセッションのために要求されたサービスを呼び出すための別のサービス要求メッセージを、ＰＣＦへ送信することと、要求されたサービスがイーサネットタイプセッションのために正常に呼び出されたか否かを示す応答を、ＰＣＦから受信することとを更に含む。

例示的な実施形態では、サービス要求メッセージは、イーサネットタイプセッションのサービスデータフローに対して必要とされるＱｏＳを管理するための要求メッセージを含み、Nnef_AFsessionWithQoS APIを介して受信される。

例示的な実施形態では、サービス要求メッセージは、イーサネットタイプセッションについての課金可能パーティを管理するための要求メッセージを含み、Nnef_ChargeableParty APIを介して受信される。

本開示の第３の態様によれば、ＡＦが提供される。ＡＦは、少なくとも１つのプロセッサと、少なくとも１つのプロセッサ上で実行されると当該ＡＦに、本開示の第１の態様による方法のいずれかを実行させる命令を格納した少なくとも１つのメモリとを備える。

本開示の第４の態様によれば、ＮＥＦが提供される。ＮＥＦは、少なくとも１つのプロセッサと、少なくとも１つのプロセッサ上で実行されると当該ＮＥＦに、本開示の第２の態様による方法のいずれかを実行させる命令を格納する少なくとも１つのメモリとを備える。

本開示の第５の態様によれば、コンピュータ読取可能な記憶媒体が提供される。コンピュータ読取可能な記憶媒体は、当該記憶媒体に格納されたコンピュータプログラム命令を有し、当該コンピュータプログラム命令は、少なくとも１つのプロセッサによって実行されると当該少なくとも１つのプロセッサに、本開示の第１及び第２の態様のいずれかによる方法を実行させる。

本開示の実施形態の技術的解決策は、コアネットワーク内のＮＥＦが、ＮＲＦを介して対応するイーサネットタイプセッションをサービングするＰＣＦ、及びＢＳＦの動的発見を実行することを可能にしうる。

本開示の目的、効果及び特徴は、以下の図面に関連する好適な実施形態の説明によって、より明らかになる。

図１Ａは、ローカルスイッチを使用する５Ｇ ＬＡＮタイプサービスをサポートするためのユーザプレーンアーキテクチャを概略的に示す。 図１Ｂは、Ｎ１９トンネルを使用する５Ｇ ＬＡＮタイプサービスをサポートするためのユーザプレーンアーキテクチャを概略的に示す。 図２は、本開示の例示的な実施形態による、イーサネットタイプのセッションをサービングする第３のネットワークノードを、コアネットワークにおける第２のネットワークノードが動的に発見することを容易にするための、第１のネットワークノードにおける方法を概略的に示す。 、 図３Ａ及び図３Ｂは、本開示の例示的な実施形態による、イーサネットタイプセッションについての第３のネットワークノードを動的に発見するための、コアネットワークにおける第２のネットワークノードにおける方法を概略的に示す。 図４は、本開示の例示的な実施形態による、イーサネットタイプセッションについての第３のネットワークノードを動的に発見するための第１のネットワークノード及び第２のネットワークノードにおける方法が適用される、必要とされるＱｏＳを有するＡＦセッションをセットアップするための手順の例示的なシグナリングシーケンス図を概略的に示す。 図５は、本開示の例示的な実施形態による、外部グループＩＤからＤＮＮ及び／又はＳ－ＮＳＳＡＩを導出する例示的なシグナリングシーケンス図を概略的に示す。 図６は、本開示の例示的な実施形態による、イーサネットタイプのセッションについての第３のネットワークノードを動的に発見するための第１のネットワークノード及び第２のネットワークノードにおける方法が適用される、セッションセットアップ時又はセッション中に課金可能パーティを設定するための手順の例示的なシグナリングシーケンス図を概略的に示す。 図７は、本開示の例示的な実施形態による第１のネットワークノードの構造的なブロック図を概略的に示す。 図８は、本開示の別の例示的な実施形態による第１のネットワークノードの構造的なブロック図を概略的に示す。 図９は、本開示の例示的な実施形態による第２のネットワークノードの構造的なブロック図を概略的に示す。 図１０は、本開示の別の例示的な実施形態による第２のネットワークノードの構造的なブロック図を概略的に示す。

図面全体を通して、同一の又は同様の参照番号は、同一の又は同様の要素を示すために使用され、図面中の種々の部分は縮尺通りに描かれておらず、説明目的のためだけに描かれており、このため、本開示の範囲に対する限定及び制約として理解されるべきではないことに留意されたい。

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

「例示的（exemplary）」という用語は、本明細書では「例示的（illustrative）」又は「例として機能する（serving as an example）」を意味するために使用され、特定の実施形態が別の実施形態よりも好ましいこと、又は特定の特徴が必須であることを暗示することを意図しないことが当業者には理解されよう。同様に、「第１の」及び「第２の」との用語並びに類似の用語は、単に、項目又は特徴の１つの特定のインスタンスを別のものと区別するために使用され、コンテキストがそれ以外のことを明らかに示さない限り、特定の順序又は配置を示さない。更に、本明細書で使用される「ステップ」との用語は、「動作」又は「アクション」と同義であることが意図されている。一連のステップについての本明細書におけるあらゆる説明は、説明される動作のコンテキスト又は詳細がそれ以外のことを明らかに示さない限り、これらの動作が特定の順序で実行されなければならないこと、又はこれらの動作が任意の順序で実行されることさえも意味するものではない。

本明細書において、「一実施形態」、「実施形態」、「例示的な実施形態」等への言及は、記載される実施形態が特定の特徴、構造、又は特性を含みうることを示すが、全ての実施形態が当該特定の特徴、構造、又は特性を含む必要はない。更に、そのようなフレーズは、必ずしも同じ実施形態を参照するものではない。更に、特定の特徴、構造、又は特性が実施形態に関連して説明される場合、明示的に説明されているか否かにかかわらず、他の実施形態に関連してそのような特徴、構造、又は特性に影響を及ぼすことは、当業者の知識の範囲内であると言える。

本明細書で使用される用語は、特定の実施形態を説明することのみを目的としており、例示的な実施形態を限定することを意図したものではない。 本明細書で使用される場合、単数形「a」、「an」及び「the」は、コンテキストが明らかにそれ以外を示さない限り、複数形も含むことが意図される。用語「含む、備える（comprises）」、「含む、備える（comprising）」、「有する（has）」、「有する（having）」、「含む、備える（includes）」、及び／又は「含む、備える（including）」は、本明細書で使用される場合、述べられた特徴、要素、及び／又はコンポーネント等の存在を特定するが、１つ以上の他の特徴、要素、及び／又はコンポーネント、又はそれらの組み合わせの存在又は追加を除外するものではないことを更に理解されたい。

本明細書で使用される場合、「及び／又は」との用語は、関連する列挙された用語のうちの１つ以上の任意の及び全ての組み合わせを含む。

以下の説明及び請求項では、別途定義されない限り、本明細書で使用される全ての技術用語及び科学用語は、本開示が属する技術分野の当業者によって一般に理解されるのと同じ意味を有する。

本明細書で使用される場合、「ネットワーク」との用語は、任意の適切な（無線又は有線）通信規格に従うネットワークを指す。例えば、無線通信規格は、ニューレディオ（ＮＲ）、ロングタームエボリューション（ＬＴＥ）、ＬＴＥ－Ａｄｖａｎｃｅｄ、広帯域符号分割多元接続（ＷＣＤＭＡ(登録商標)）、高速パケットアクセス（ＨＳＰＡ）、符号分割多元接続（ＣＤＭＡ）、時分割多元接続（ＴＤＭＡ）、周波数分割多元接続（ＦＤＭＡ）、直交周波数分割多元接続（ＯＦＤＭＡ）、シングルキャリア周波数分割多元接続（ＳＣ－ＦＤＭＡ）、及び他の無線ネットワークを含みうる。ＣＤＭＡネットワークは、Universal Terrestrial Radio Access（ＵＴＲＡ）等の無線技術を実装しうる。ＵＴＲＡは、ＷＣＤＭＡ及びＣＤＭＡの他の変形を含む。ＴＤＭＡネットワークは、Global System for Mobile Communications（ＧＳＭ）等の無線技術を実装しうる。ＯＦＤＭＡネットワークは、Evolved UTRA（Ｅ－ＵＴＲＡ）、Ultra Mobile Broadband（ＵＭＢ）、IEEE 802.11（Ｗｉ－Ｆｉ）、IEEE 802.16（ＷｉＭＡＸ）、IEEE 802.20（Ｆｌａｓｈ－ＯＦＤＭＡ）、アドホックネットワーク、無線センサネットワーク等の無線技術を実装しうる。以下の説明では、「ネットワーク」及び「システム」との用語は、互いに交換可能に使用されうる。

更に、ネットワーク内の２つのデバイス間の通信は、３ＧＰＰ又は有線通信プロトコル等の標準組織によって定められた無線通信プロトコルを含むがこれらに限定されない、任意の適切通信プロトコルに従って、実行されうる。例えば、無線通信プロトコルは、第１世代（１Ｇ）、２Ｇ、３Ｇ、４Ｇ、４．５Ｇ、５Ｇ通信プロトコル、及び／又は現在知られているか又は将来開発予定の任意の他のプロトコルを含みうる。

本明細書で使用される「ノード」又は「ネットワークノード」との用語は、通信ネットワークにおけるネットワークデバイス又はネットワークノード又はネットワーク機能を指し、クラウド上に実装されうる仮想化エンティティも指しうる。例えば、３ＧＰＰタイプのセルラネットワーク等の無線通信ネットワークでは、コアネットワークデバイスは、アクセスネットワークデバイスによって相互接続されている顧客に多数のサービスを提供しうる。各アクセスネットワークデバイスは、有線又は無線接続を介してコアネットワークデバイスに接続可能である。

「ＣＮネットワークノード」との用語は、通信ネットワークのネットワークノード（物理的又は仮想的）に実装可能な任意の適切な機能を指す。例えば、ネットワークノードは、専用ハードウェア上のネットワーク要素として、専用ハードウェア上で実行されるソフトウェアインスタンスとして、又は適切なプラットフォーム上で（例えばクラウドインフラストラクチャ上で）インスタンス化された仮想化機能として実装されうる。例えば、５ＧＣは、ＡＭＦ、セッション管理機能（ＳＭＦ）、ＵＤＭ、ＰＣＦ、ＵＰＦ（ユーザプレーン機能）、ＮＲＦ等の、複数の機能を備えうる。例えば、４Ｇコアネットワークシステム（ＥＰＣ等）は、モビリティ管理エンティティ（ＭＭＥ）、ＨＳＳ（ホーム加入者サーバ）、パケットデータネットワークゲートウェイ（ＰＧＷ）、ブロードキャストマルチキャスト‐サービスセンター（ＢＭ－ＳＣ）等を含みうる。他の実施形態では、ＣＮネットワークノードは、例えば、特定のネットワークに依存して、異なるタイプの機能を備えうる。

本開示の基本的なアイデアは主に次のとおりである。

１） イーサネットタイプセッションについてのネットワーク関連識別情報が、第２のネットワークノード（例えば、ＮＥＦ）に向かう、第１のネットワークノード（例えば、ＡＦ）のサービス要求メッセージに含まれる。

２） 第２のネットワークノード（例えば、ＮＥＦ）が、イーサネットＰＤＵタイプセッション、イーサネットサービスデータフロー情報等と関連付けられたＵＥ ＭＡＣアドレスに加えて、新しい属性（例えば、外部グループＩＤ、又はイーサネットタイプセッションにサービングするＤＮＮ及び／又はＳ－ＮＳＳＡＩ等のネットワーク関連識別情報）を第１のネットワークノード（例えば、ＡＦ）に公開することによって、AFsessionWithQoS、ChargeableParty、及び他の適切なＡＰＩ等の、当該第２のネットワークノードのＡＰＩを強化し、それにより、第１のネットワークノード（例えば、ＡＦ）が、たとえば、イーサネットＰＤＵタイプセッション、イーサネットサービスデータフロー情報等と関連付けられたＵＥ ＭＡＣアドレスに加えて、属性（例えば、外部グループＩＤ、又はイーサネットタイプセッションにサービングするＤＮＮ及び／又はＳ－ＮＳＳＡＩ等のネットワーク関連識別情報）を有するイーサネットタイプセッションについての対応するサービスを要求しうるとともに、ＮＥＦは、例えば、ＵＥ ＭＡＣアドレス、外部グループＩＤ、又はＤＮＮ及び／又はＳ－ＮＳＳＡＩを使用して、イーサネットタイプのセッションをサービングする第３のネットワークノード（例えば、ＰＣＦ）を動的に発見しうる。

３） 第２のネットワークノード（例えば、ＮＥＦ）は、ＤＮＮ及び／又はＳ－ＮＳＳＡＩに基づいて、第６のネットワークノード（例えば、ＮＲＦ）を介して第５のネットワークノード（例えば、ＢＳＦ）を動的に発見し、ＤＮＮ及び／又はＳ－ＮＳＳＡＩは、サービス要求メッセージで第１のネットワークノード（例えば、ＡＦ）から直接受信されうるか、又は第４のネットワークノード（例えば、ＵＤＭ）への問い合わせを介して、第２のネットワークノード（例えば、ＮＥＦ）によって受信されたサービス要求メッセージ内の外部グループＩＤから導出されうる。

４） 第２のネットワークノード（例えば、ＮＥＦ）は、ＵＥ ＭＡＣアドレスとＤＮＮ及び／又はＳ－ＮＳＳＡＩとを使用して、イーサネットタイプセッションをサービングする第３のネットワークノード（例えば、ＰＣＦ）のセッションバインディング情報を、第５のネットワークノード（例えば、ＢＳＦ）に問い合わせ、セッションバインディング情報内のサービング・第３のネットワークノード（例えば、サービングＰＣＦ）のアドレス情報を取得して、サービング・第３のネットワークノード（例えば、サービングＰＣＦ）を動的に発見する。

以下では、図２を参照して、本開示の例示的な実施形態による、イーサネットタイプセッションをサービングする第３のネットワークノード（例えば、ＰＣＦ）をコアネットワーク内の第２のネットワークノード（例えば、ＮＥＦ）が動的に発見することを容易にするための、第１のネットワークノード（例えば、ＡＦ）における方法２００について説明する。第１のネットワークノード（例えば、ＡＦ）は、クラウド上に実装されうる仮想化エンティティを含む、以下で説明される方法２００を実行するように構成されうる任意のノードでありうることを理解されたい。方法２００は、５ＧＳ、又は他の将来の開発版おいて適切に適用されうることを理解されたい。

図２に示されるように、方法２００は、ステップＳ２０１を含みうる。

ステップＳ２０１で、第１のネットワークノード（例えば、ＡＦ）は、イーサネットタイプセッションについてのサービス要求メッセージを第２のネットワークノード（例えば、ＮＥＦ）へ送信することによって、第２のネットワークノード（例えば、ＮＥＦ）からイーサネットタイプセッションについてのサービス動作を呼び出しうる。サービス要求メッセージは、イーサネットタイプセッションについてのネットワーク関連識別情報を含む。

イーサネットタイプセッションについてのネットワーク関連識別情報は、第１のネットワークノード（例えば、ＡＦ）に対して事前設定されうるか、又はシグナリングを介して第１のネットワークノード（例えば、ＡＦ）に対して動的に提供されうる。

例示的な実施形態では、イーサネットタイプセッションについてのネットワーク関連識別情報は、以下のうちの少なくとも１つを含みうる：
イーサネットタイプセッションについてのＤＮＮ、及び
イーサネットタイプセッションについてのＳ－ＮＳＳＡＩ。

代替的又は追加的に、イーサネットタイプセッションについてのネットワーク関連識別情報は、イーサネットタイプセッションについての仮想ネットワーク（ＶＮ）（例えば、５Ｇ ＬＡＮ－ＶＮ）の外部グループＩＤを含んでよく、以下のうちの少なくとも１つと関連付けられる：
イーサネットタイプセッションについてのＤＮＮ、及び
イーサネットタイプセッションについてのＳ－ＮＳＳＡＩ。

外部グループＩＤは、以下のうちの少なくとも１つについての第１のネットワークノード（例えば、ＡＦ）のサポートを示しうる：
外部グループＩＤ機能、
イーサネットアプリケーションサーバ（ＡＳ）セッションＱｏＳ機能、及び
イーサネット課金可能パーティ機能。

本開示の例示的な実施形態において提案されるように、外部グループＩＤ、又はＤＮＮ及び／又はＳ－ＮＳＳＡＩ等のネットワーク関連識別情報に加えて、サービス要求メッセージは、イーサネットタイプセッションと関連付けられたＵＥについてのＵＥ ＭＡＣアドレス、イーサネットサービスデータフロー情報、及びイーサネットタイプセッションの他の従来の属性を含みうることが理解されうる。

方法２００は更に、ステップＳ２０１において、第１のネットワークノード（例えば、ＡＦ）が、ネットワーク関連識別情報を含むサービス要求メッセージを第２のネットワークノード（例えば、ＮＥＦ）へ送信し、第２のネットワークノード（例えば、ＮＥＦ）が、当該ネットワーク関連識別情報に基づいて、イーサネットタイプセッションをサービングする第３のネットワークノード（例えば、ＰＣＦ）を動的に発見した後に、第２のネットワークノード（例えば、ＮＥＦ）から、要求されたサービスがイーサネットタイプセッションのために正常に呼び出されたか否かを示す応答を受信することを更に含む。

例示的な実施形態では、サービス要求メッセージは、第１のネットワークノード（例えば、ＡＦ）によって、Nnef_AFsessionWithQoS APIを介して第２のネットワークノード（例えば、ＮＥＦ）からNnef_AFsessionWithQoS関連サービスを呼び出す／要求するために使用される、イーサネットタイプセッションのサービスデータフローに対して必要とされるＱｏＳを管理する（例えば、作成する、更新する、取り消す等）ための要求メッセージを含みうる。したがって、サービス要求メッセージ内の外部グループＩＤは、以下のうちの少なくとも１つについての第１のネットワークノード（例えば、ＡＦ）のサポートを示しうる：
外部グループＩＤ（例えば、ExternalGroupId_5G）機能、及び
イーサネットＡＳセッションＱｏＳ（例えば、EthAsSessionQoS_5G）機能。

代替的又は追加的に、サービス要求メッセージは、Nnef_ChargeableParty APIを介して第２のネットワークノード（例えば、ＮＥＦ）からNnef_ChargeableParty関連サービスを呼び出す／要求するために第１のネットワークノード（例えば、ＡＦ）によって使用される、イーサネットタイプセッションについての課金可能パーティを管理する（例えば、作成する、更新する等）ための要求メッセージを含みうる。したがって、サービス要求メッセージ内の外部グループＩＤは、以下のうちの少なくとも１つについての第１のネットワークノード（例えば、ＡＦ）のサポートを示しうる：
外部グループＩＤ（例えば、ExternalGroupId_5G）機能、及び
イーサネット課金可能パーティ（例えば、EthChgParty_5G）機能。

以下では、本開示の例示的な実施形態による、イーサネットタイプセッションをサービングする第３のネットワークノード（例えば、ＰＣＦ）を動的に発見するための、第２のネットワークノード（例えば、ＮＥＦ）における方法３００及び方法３００'について、それぞれ図３Ａ及び図３Ｂを参照して説明する。第２のネットワークノード（例えば、ＮＥＦ）は、クラウド上に実装されうる仮想化エンティティを含む、以下で説明される方法３００及び３００'を実行するように構成されうる任意のノードでありうることを理解されたい。方法３００及び３００'は、５ＧＳ、又は他の将来の開発版おいて適切に適用されうることを理解されたい。

第２のネットワークノード（例えば、ＮＥＦ）における方法３００及び３００'は、それぞれ、第１のネットワークノード（例えば、ＡＦ）における方法２００に対応しうる。このため、方法３００及び３００'の一部の説明は、方法２００の説明を参照してもよく、それ故に簡略化のために省略される。

図３Ａに示すように、方法３００は、ステップＳ３０１及びＳ３０３を含みうる。

ステップＳ３０１で、第２のネットワークノード（例えば、ＮＥＦ）は、イーサネットタイプセッションについてのサービス要求メッセージを、第１のネットワークノード（例えば、ＡＦ）から受信しうる。サービス要求メッセージは、イーサネットタイプセッションについてのネットワーク関連識別情報を含む。

その後ステップＳ３０３で、第２のネットワークノード（例えば、ＮＥＦ）は、少なくともネットワーク関連識別情報に基づいて、第３のネットワークノード（例えば、ＰＣＦ）を発見しうる。

前述のように、イーサネットタイプセッションについてのネットワーク関連識別情報は、第１のネットワークノード（例えば、ＡＦ）に対して事前設定されうるか、又はシグナリングを介して第１のネットワークノード（例えば、ＡＦ）に対して動的に提供されうる。

例示的な実施形態では、イーサネットタイプセッションについてのネットワーク関連識別情報は、以下のうちの少なくとも１つを含みうる：
イーサネットタイプセッションについてのＤＮＮ、及び
イーサネットタイプセッションについてのＳ－ＮＳＳＡＩ。

この場合、第２のネットワークノード（例えば、ＮＥＦ）は、受信されたネットワーク関連識別情報から、イーサネットタイプセッションについてのＤＮＮ及び／又はＳ－ＮＳＳＡＩを取得しうる。

代替的又は追加的に、イーサネットタイプセッションについてのネットワーク関連識別情報は、イーサネットタイプセッションについての仮想ネットワーク（ＶＮ）（例えば、５Ｇ ＬＡＮ－ＶＮ）の外部グループＩＤを含んでよく、以下のうちの少なくとも１つと関連付けられる：
イーサネットタイプセッションについてのＤＮＮ、及び
イーサネットタイプセッションについてのＳ－ＮＳＳＡＩ。

この場合、第２のネットワークノード（例えば、ＮＥＦ）は、受信されたネットワーク関連識別情報内の外部グループＩＤから、イーサネットタイプセッションについてのＤＮＮ及び／又はＳ－ＮＳＳＡＩを導出しうる。

例示的な実施形態では、イーサネットタイプセッションについてのＤＮＮ及び／又はＳ－ＮＳＳＡＩは、第２のネットワークノード（例えば、ＮＥＦ）が、外部グループＩＤを使用して、イーサネットタイプセッションについてのＤＮＮ及びイーサネットタイプセッションについてのＳ－ＮＳＳＡＩのうちの少なくとも１つについて、外部グループＩＤとＤＮＮ及び／又はＳ－ＮＳＳＡＩとの間の関連付け関係を格納している第４のネットワークノード（例えば、ＵＤＭ）に問い合わせを行うことによって導出されうる。

特に、第２のネットワークノード（例えば、ＮＥＦ）は、外部グループＩＤを使用して第４のネットワークノード（例えば、ＵＤＭ）を見つけるために第６のネットワークノード（例えば、ＮＲＦ）に問い合わせを行い、その後、外部グループＩＤを使用して、イーサネットタイプセッションについてのＤＮＮ及びイーサネットタイプセッションについてのＳ－ＮＳＳＡＩのうちの少なくとも１つについて、第４のネットワークノード（例えば、ＵＤＭ）に問い合わせを行ってもよく、これは、図５に関連して例示的に説明される。

前述のように、外部グループＩＤは、以下のうちの少なくとも１つについての第１のネットワークノード（例えば、ＡＦ）のサポートを示しうる：
外部グループＩＤ機能、
イーサネットアプリケーションサーバ（ＡＳ）セッションＱｏＳ機能、及び
イーサネット課金可能パーティ機能。

本開示の例示的な実施形態において提案されるように、外部グループＩＤ、又はＤＮＮ及び／又はＳ－ＮＳＳＡＩ等のネットワーク関連識別情報に加えて、サービス要求メッセージは、イーサネットタイプセッションと関連付けられたＵＥについてのＵＥ ＭＡＣアドレス、イーサネットサービスデータフロー情報、及びイーサネットタイプセッションの他の従来の属性を含みうることが理解されうる。

図３Ｂに示されるような別の例示的な実施形態では、方法３００'は、図３Ａと同じステップＳ３０１（それ故に、簡略化のためここでは説明が省略される）と、代わりにステップＳ３０３'とを含みうる。ステップＳ３０３'は、ネットワーク関連識別情報に基づいて、イーサネットタイプセッションについての第３のネットワークノード（例えば、ＰＣＦ）のバインディング情報を保持する第５のネットワークノード（例えば、ＢＳＦ）を発見することを含みうる。その後、第２のネットワークノード（例えば、ＮＥＦ）は、第５のネットワークノード（例えば、ＢＳＦ）に問い合わせを行うことによって、第１のネットワークノード（例えば、ＡＦ）から受信されたＵＥ ＭＡＣアドレスを使用して、第３のネットワークノード（例えば、ＰＣＦ）を発見しうる。

特に、第５のネットワークノード（例えば、ＢＳＦ）は、第２のネットワークノード（例えば、ＮＥＦ）が、イーサネットタイプセッションについてのＤＮＮ及びイーサネットタイプセッションについてのＳ－ＮＳＳＡＩのうちの少なくとも１つを使用して、第６のネットワークノード（例えば、ＮＲＦ）に問い合わせを行うことによって発見されうる。

図３ＡのステップＳ３０３又は図３ＢのステップＳ３０３'の後、第２のネットワークノード（例えば、ＮＥＦ）は、第３のネットワークノード（例えば、ＰＣＦ）へ、イーサネットタイプセッションについての要求されたサービスを呼び出すための別のサービス要求メッセージを送信し、第３のネットワークノード（例えば、ＰＣＦ）から、要求されたサービスがイーサネットタイプセッションのために正常に呼び出されたか否かを示す応答を受信しうる。

例示的な実施形態では、サービス要求メッセージは、イーサネットタイプセッションのサービスデータフローに対して必要とされるＱｏＳを管理する（例えば、作成する、更新する、取り消す／削除する等）ための要求メッセージを含んでよく、これは、要求側の第１のネットワークノード（例えば、要求側のＡＦ）にNnef_AFsessionWithQoS関連サービスを提供するために、Nnef_AFsessionWithQoS APIを介して第２のネットワークノード（例えば、ＮＥＦ）によって受信され、これは図４に関連して例示的に後述される。したがって、サービス要求メッセージ内の外部グループＩＤは、以下のうちの少なくとも１つについての第１のネットワークノード（例えば、ＡＦ）のサポートを示しうる：
外部グループＩＤ（例えば、ExternalGroupId_5G）機能、及び
イーサネットＡＳセッションＱｏＳ（例えば、EthAsSessionQoS_5G）機能。

代替的に又は追加的に、サービス要求メッセージは、イーサネットタイプセッションについての課金可能パーティを管理する（例えば、作成する、更新する等）ための要求メッセージを含んでよく、これは、

Nnef_ChargeableParty関連サービスを要求側の第１のネットワークノード（例えば、要求側ＡＦ）に提供するために、Nnef_ChargeableParty APIを介して第２のネットワークノード（例えば、ＮＥＦ）によって受信され、これは図６に関連して例示的に後述される。したがって、サービス要求メッセージ内の外部グループＩＤは、以下のうちの少なくとも１つについての第１のネットワークノード（例えば、ＡＦ）のサポートを示しうる：
外部グループＩＤ（例えば、ExternalGroupId_5G）機能、及び
イーサネット課金可能パーティ（例えば、EthChgParty_5G）機能。

以下では、図４を参照して、必要とされるＱｏＳを有するＡＦセッションをセットアップするための手順の例示的なシグナリングシーケンス図について説明する。ここでは、本開示の例示的な実施形態による、第２のネットワークノードがサービング・第３のネットワークノードを動的に発見することを容易にするための第１のネットワークノードにおける方法２００と、サービング・第３のネットワークノードを動的に発見するための第２のネットワークノードにおける方法３００とが適用される。

以下の説明は主に、方法２００及び３００に関連するシグナリングに焦点を当て、いくつかの他のシグナリングは、本開示の原理を不明瞭にすることを避けるために詳細には説明されないことに留意されたい。図４では、方法２００及び３００に関連するシグナリングの修正が太字のイタリック体で示されており、シグナリングＳ４＿１及びＳ４＿２が含まれる。

図４の手順は、イーサネットタイプＰＤＵセッションが確立され、ＰＣＦ（前述の第３のネットワークノードの一例）がＢＳＦ（前述の第５のネットワークノードの一例）にセッションバインディング情報を登録した際に生じ、これはＳ４＿０として示される。

Ｓ４＿１で、ＡＦ（前述の第１のネットワークノードの一例）は、サービス要求メッセージ（例えば、イーサネットタイプＰＤＵセッションと関連付けられたＵＥのＵＥ ＭＡＣアドレスを有するNnef_AFSessionWithQoS_Create要求メッセージ）、イーサネットタイプＰＤＵセッションのイーサネットサービスデータフロー情報（ethFlowInfoとして表される）、及びイーサネットタイプＰＤＵセッションの他の属性を、ＮＥＦ（前述の第２のネットワークノードの一例）へ送信することによって、Nnef_AFSessionWithQoS_Createサービス動作を呼び出す。サービス要求メッセージは、ＵＥ ＭＡＣアドレス、ethFlowInfo、及び他の属性に加えて、イーサネットタイプＰＤＵセッションのネットワーク関連識別情報（対応する５Ｇ ＬＡＮ－ＶＮグループの外部グループＩＤ、又はイーサネットタイプＰＤＵセッションについてのＤＮＮ及び／又はＳ－ＮＳＳＡＩ等）を更に含みうる。

Nnef_AFSessionWithQoS_Createは、図４に例示的に示されているが、本開示はNnef_AFSessionWithQoS_Update/Revokeにも適用可能であることを理解されたい。

Nnef_AFSessionWithQoS_Create要求は、HTTP POST要求でありうる。

Ｓ４＿２で、ＮＥＦは、ＡＦから受信したサービス要求メッセージから、対応する５Ｇ ＬＡＮ－ＶＮグループのＤＮＮ及び／又はＳ－ＮＳＳＡＩを取得する。

例示的な実施形態では、サービス要求メッセージは、直接的に使用可能なＤＮＮ及び／又はＳ－ＮＳＳＡＩを含む。

別の例示的な実施形態では、サービス要求メッセージは、対応する５Ｇ ＬＡＮ－ＶＮグループの外部グループＩＤを含む。この場合、ＮＥＦは、受信したサービス要求メッセージ内の外部グループＩＤからＤＮＮ及び／又はＳ－ＮＳＳＡＩを導出するために、外部グループＩＤを用いて、外部グループＩＤとＤＮＮ及び／又はＳ－ＮＳＳＡＩとの間の関連付け関係を格納しているＵＤＭに、ＤＮＮ及び／又はＳ－ＮＳＳＡＩについて問い合わせることによって、外部グループＩＤをＤＮＮ及び／又はＳ－ＮＳＳＡＩにマッピングする必要がある。

図５を参照すると、図５は、本開示の例示的な実施形態による、外部グループＩＤからＤＮＮ及び／又はＳ－ＮＳＳＡＩを導出する例示的なシグナリングシーケンス図を概略的に示す。

Ｓ５＿２．１において、ＮＥＦは、外部グループＩＤをクエリパラメータとして用いてＵＤＭ（前述の第４のネットワークノードの一例）を見つけるために、ＮＲＦ（ｔの第６のネットワークノード例の一例）にNnrf_NFDiscovery_Requestによって問合せを行いうる。

次に、Ｓ５＿２．２において、ＮＥＦは、クエリパラメータとして外部グループＩＤを使用して、ＤＮＮ及び／又はＳ－ＮＳＳＡＩについてNudm_ParameterProvision_GetによってＵＤＭに問い合わせを行いうる。

その後、Ｓ５＿２．３において、ＮＥＦは、Nudm_ParameterProvision_Responseによって、ＤＮＮ及び／又はＳ－ＮＳＳＡＩをＵＤＭから受信しうる。

ここで図４に戻ると、ＮＥＦがＳ４＿２においてＤＮＮ及び／又はＳ－ＮＳＳＡＩを取得した後に、ＮＥＦは、Nnrf_NFDiscovery_RequestによってＮＲＦに問い合わせを行うことで、Ｓ４＿３においてＤＮＮ及び／又はＳ－ＮＳＳＡＩを問い合わせパラメータとして使用してＢＳＦを動的に発見しうる。

Ｓ４＿４において、ＮＥＦは、Nbsf_Management_Discovery_Requestによって、Ｓ４＿３で発見されたＢＳＦに問い合わせを行うことで、ＵＥ ＭＡＣアドレス、ＤＮＮ及び／又はＳ－ＮＳＳＡＩを問い合わせパラメータとして使用して、対応するイーサネットタイプＰＤＵセッションのサービングＰＣＦを動的に発見しうる。

Ｓ４＿５において、ＮＥＦは、例えばNpcf_PolicAuthorization_Create要求によって、ポリシー認可（authorization）関連サービス要求メッセージをサービングＰＣＦへ送信することで、ポリシー認可関連サービスを呼び出しうる。

Npcf_PolicAuthorization_Create要求は、HTTP POST要求であってもよい。

Ｓ４＿６において、サービングＰＣＦは、ポリシー認可関連サービス呼び出しの結果を知らせるために、例えばNpcf_PolicAuthorization_Create応答によってポリシー認可関連サービス応答メッセージをＮＥＦへ送信しうる。

Npcf_PolicAuthorization_Createは、図４に例示的に示されているが、本開示はNpcf_PolicAuthorization_Update/Deleteにも適用可能であることを理解されたい。

Ｓ４＿７において、サービングＰＣＦは、イーサネットタイプＰＤＵセッションについての更新された可能性のあるポリシー情報を用いて、Npcf_SMPolicyControl_UpdateNotifyサービス動作を呼び出しうる。

Ｓ４＿８で、ＮＥＦは、要求されたサービスの呼び出し結果を示すために、例えば、Nnef_AFSessionWithQoS_Create応答によって応答メッセージをＡＦに送信しうる。

図４に示されるような例示的な手順は、例えば、下線付きの太字で示される、3GPP TS 29.122 v17.0.0における以下のセクションの修正に関するものである。

図４に示されるような例示的な手順は更に、例えば、下線付きの太字で示される、3GPP TS 29.522 v17.0.0における以下のセクションの修正に関するものである。

以下、図６は、セッションセットアップ時又はセッション中に課金可能パーティを設定するための手順の例示的なシグナリングシーケンス図を概略的に示す。ここでは、本開示の例示的な実施形態による、第２のネットワークノードがサービング・第３のネットワークノードを動的に発見することを容易にするための第１のネットワークノードにおける方法２００と、サービング・第３のネットワークノードを動的に発見するための第２のネットワークノードにおける方法３００とが適用される。

前述のように、本開示の実施形態は、Nnef_AFsessionWithQoS APIに適用可能でありうるとともに、ＮＥＦにおけるNnef_ChargeableParty APIにも適用可能でありうる。図６の手順は、第１のシグナリングＳ６＿１を除いて図４の手順と同一である。したがって、Ｓ６＿０及びＳ６＿２～Ｓ６＿８の説明については、Ｓ４＿０及びＳ４＿２～Ｓ４＿８の前述の説明を参照することができ、それ故に、簡略化のためにここでは省略する。以下では、図６と図４との手順の違いを説明するためにＳ６＿１について説明する。

Ｓ６＿１で、ＡＦ（前述の第１のネットワークノードの一例）は、サーサネットタイプＰＤＵセッションと関連付けられたＵＥのＵＥ ＭＡＣアドレスを有するサービス要求メッセージ、イーサネットタイプＰＤＵセッションのイーサネットサービスデータフロー情報（ethFlowInfoとして表される）、及びイーサネットタイプＰＤＵセッションの他の属性を、ＮＥＦ（前述の第２のネットワークノードの一例）へ送信することによって、Nnef_ChargeableParty_Createサービス動作を呼び出す。サービス要求メッセージは、ＵＥ ＭＡＣアドレス、ethFlowInfo、及び他の属性に加えて、イーサネットタイプＰＤＵセッションのネットワーク関連識別情報（対応する５Ｇ ＬＡＮ－ＶＮグループの外部グループＩＤ、又はイーサネットタイプＰＤＵセッションについてのＤＮＮ及び／又はＳ－ＮＳＳＡＩ等）を更に含みうる。

Nnef_ChargeableParty_Createは、図６に例示的に示されているが、本開示はNnef_ChargeableParty _Updateにも適用可能であることを理解されたい。

図６に示されるような例示的な手順は、例えば、下線付きの太字で示される、3GPP TS 29.122 v17.0.0における以下のセクションの修正に関するものである。

図６に示されるような例示的な手順は更に、例えば、下線付きの太字で示される、3GPP TS 29.522 v17.0.0における以下のセクションの修正に関するものである。

以下では、図７を参照して、本発明の一実施形態による第１ネットワークノードの構成を説明する。図７は、本開示の例示的な実施形態による第１のネットワークノード７００のブロック図を概略的に示す。図７の第１のネットワークノード７００は、図２を参照しながら前述した方法２００を実行しうる。したがって、第１のネットワークノード７００についてのいくつかの詳細な説明は、これまでに論じた図２の方法２００と図４及び図５のシグナリングシーケンス図とについての対応する説明を参照しうるため、簡略化のためにここでは省略する。

図７に示されるように、第１のネットワークノード７００は、イーサネットタイプセッションについてのサービス要求メッセージを第２のネットワークノードへ送信するように構成されうる送信部７０１を備えうる。ここで、サービス要求メッセージは、イーサネットタイプセッションについてのネットワーク関連識別情報を含む。

例示的な実施形態では、イーサネットタイプセッションについてのネットワーク関連識別情報は、ＡＦにおいて事前設定されるか又は動的に提供される。

例示的な実施形態では、イーサネットタイプセッションについてのネットワーク関連識別情報は、以下のうちの少なくとも１つを含む：
イーサネットタイプセッションについてのＤＮＮ、及び
イーサネットタイプセッションについてのＳ－ＮＳＳＡＩ。

例示的な実施形態では、イーサネットタイプセッションについてのネットワーク関連識別情報は、イーサネットタイプセッションについての仮想ネットワークの外部グループＩＤを含み、これは、以下のうちの少なくとも１つと関連付けられる：
イーサネットタイプセッションについてのＤＮＮ、及び
イーサネットタイプセッションについてのＳ－ＮＳＳＡＩ。

例示的な実施形態では、外部グループＩＤは、以下のうちの少なくとも１つについての第１のネットワークノードのサポートを示す：
外部グループＩＤ機能、
イーサネットアプリケーションサーバセッションＱｏＳ機能、及び
イーサネット課金可能パーティ機能。

例示的な実施形態では、サービス要求メッセージは、イーサネットタイプセッションと関連付けられたＵＥについてのＵＥ ＭＡＣアドレスを更に含む。

例示的な実施形態では、第１のネットワークノード７００は、要求されたサービスが、イーサネットタイプセッションのために正常に呼び出されたか否かを示す応答を、第２のネットワークノードから受信するように構成されうる受信ユニットを更に備えうる。

例示的な実施形態では、第１のネットワークノードはＡＦであり、第２のネットワークノードはＮＥＦであり、第３のネットワークノードはＰＣＦである。

例示的な実施形態において、サービス要求メッセージは、以下のうちの少なくとも１つを含む：
イーサネットタイプセッションのサービスデータフローのために必要とされるＱｏＳを管理するための要求メッセージ、及び
イーサネットタイプセッションについての課金可能パーティを管理するための要求メッセージ。

以下では、図８を参照して、本発明の他の実施形態による第１ネットワークノードの構成を説明する。図８は、本開示の例示的な実施形態による第１のネットワークノード８００のブロック図を概略的に示す。図８の第１のネットワークノード８００は、図２を参照しながら前述した方法２００を実行しうる。したがって、第１のネットワークノード８００についてのいくつかの詳細な説明は、これまでに論じた図２の方法２００と図４及び図５のシグナリングシーケンス図とについての対応する説明を参照しうるため、簡略化のためにここでは省略する。

図８に示されるように、第１のネットワークノード８００は、少なくとも１つのプロセッサ８０１と少なくとも１つのメモリ８０３とを備える。少なくとも１つのプロセッサ８０１は、例えば、コンピュータプログラム命令を実行することが可能な任意の適切なＣＰＵ（中央演算処理装置）、マイクロコントローラ、ＤＳＰ（デジタルシグナルプロセッサ）等を含む。少なくとも１つのメモリ８０３は、ＲＡＭ（ランダムアクセスメモリ）及びＲＯＭ（リードオンリーメモリ）の任意の組み合わせでありうる。少なくとも１つのプロセッサメモリ８０３は、例えば、磁気メモリ、光メモリ、又はソリッドステートメモリのうちの任意の単一の１つ又は組み合わせでありうるか、又は遠隔搭載型メモリでありうる、永続的ストレージを含みうる。

少なくとも１つのメモリ８０３は、少なくとも１つのプロセッサ８０１によって実行可能な命令を格納する。命令は、少なくとも１つのメモリ８０３からロードされ、少なくとも１つのプロセッサ８０１上で実行されると第１のネットワークノード８００に、例えば、前述のように図４及び図５のシグナリングシーケンス図を参照して図２にそれぞれ関連してこれまでに説明してきたような手順の動作を実行させうる。このため、簡略化のためにここでは省略する。

以下では、図９を参照して、本発明の一実施形態による第２ネットワークノードの構成を説明する。図９は、本開示の例示的な実施形態による第２のネットワークノード９００のブロック図を概略的に示す。図９の第２のネットワークノード９００は、図３を参照しながら前述した方法３００を実行しうる。したがって、第２のネットワークノード９００についてのいくつかの詳細な説明は、これまでに論じた図３の方法３００と図６及び図５のシグナリングシーケンス図とについての対応する説明を参照しうるため、簡略化のためにここでは省略する。

図９に示されるように、第２のネットワークノード９００は、受信ユニット９０１と発見ユニット９０３とを備えうる。

受信ユニット９０１は、イーサネットタイプセッションについてのサービス要求メッセージを第１のネットワークノードから受信するように構成されうる。ここで、サービス要求メッセージは、イーサネットタイプセッションについてのネットワーク関連識別情報を含む。

発見ユニット９０３は、少なくともネットワーク関連識別情報に基づいて、第３のネットワークノードを発見するように構成されうる。

例示的な実施形態では、サービス要求メッセージは、イーサネットタイプセッションと関連付けられたＵＥのＵＥ ＭＡＣアドレスを更に含む。

代替的に、発見ユニット９０３は、ネットワーク関連識別情報に基づいて、イーサネットタイプセッションについての第３のネットワークノードのバインディング情報を保持する第５のネットワークノードを発見し、第５のネットワークノードに問い合わせることによって、ＡＦから受信されたＵＥ ＭＡＣアドレスを使用して第３のネットワークノードを発見するように構成されうる。

例示的な実施形態では、イーサネットタイプセッションについてのネットワーク関連識別情報は、事前設定されるか又は動的に提供される。

例示的な実施形態では、イーサネットタイプセッションについてのネットワーク関連識別情報は、以下のうちの少なくとも１つを含む：
イーサネットタイプセッションについてのＤＮＮ、及び
イーサネットタイプセッションについてのＳ－ＮＳＳＡＩ。

例示的な実施形態では、イーサネットタイプセッションについてのネットワーク関連識別情報は、イーサネットタイプセッションについての仮想ネットワークの外部グループＩＤを含み、これは、以下のうちの少なくとも１つと関連付けられる：
イーサネットタイプセッションについてのＤＮＮ、及び
イーサネットタイプセッションについてのＳ－ＮＳＳＡＩ。

例示的な実施形態では、外部グループＩＤは、以下のうちの少なくとも１つについての第１のネットワークノードのサポートを示す：
外部グループＩＤ機能、
イーサネットアプリケーションサーバセッションＱｏＳ機能、及び
イーサネット課金可能パーティ機能。

例示的な実施形態では、第２のネットワークノード９００は、イーサネットタイプセッションについてのＤＮＮ及びイーサネットタイプセッションについてのＳ－ＮＳＳＡＩのうちの少なくとも１つを、外部グループＩＤから導出するように構成されうる導出ユニット（図示せず）を更に備えうる。

例示的な実施形態では、導出ユニットは更に、外部グループＩＤとＤＮＮ及び／又はＳ－ＮＳＳＡＩとの間の関連付け関係を格納している第４のネットワークノードに対して、イーサネットタイプセッションについてのＤＮＮ及びイーサネットタイプセッションについてのＳ－ＮＳＳＡＩのうちの少なくとも１つを、外部グループＩＤを使用して問い合わせるように構成されうる。

例示的な実施形態では、発見ユニット９０３は更に、イーサネットタイプセッションについてのＤＮＮ及びイーサネットタイプセッションについてのＳ－ＮＳＳＡＩのうちの少なくとも１つに基づいて、イーサネットタイプセッションについての第３のネットワークノードのバインディング情報を保持する第５のネットワークノードを発見し、第３のネットワークノードを発見するために、ＵＥ ＭＡＣアドレスと、イーサネットタイプセッションについてのＤＮＮ及びイーサネットタイプセッションについてのＳ－ＮＳＳＡＩのうちの少なくとも１つとを使用して、第５のネットワークノードに問い合わせを行うように構成されうる。

例示的な実施形態では、第５のネットワークノードは、第２のネットワークノードが、イーサネットタイプセッションについてのＤＮＮ及びイーサネットタイプセッションについてのＳ－ＮＳＳＡＩのうちの少なくとも１つを使用して第６のネットワークノードに問い合わせを行うことによって発見される。

例示的な実施形態では、第２のネットワークノード９００は、イーサネットタイプセッションについての要求されたサービスを呼び出すための別のサービス要求メッセージを、第３のネットワークノードへ送信するように構成されうる送信ユニット（図示せず）を更に備えうる。また、受信ユニット９０１は更に、要求されたサービスがイーサネットタイプセッションのために正常に呼び出されたか否かを示す応答を、第３のネットワークノードから受信するように構成されうる。

例示的な実施形態では、第１のネットワークノードはＡＦであり、第２のネットワークノードはＮＥＦであり、第３のネットワークノードはＰＣＦであり、第４のネットワークノードはＵＤＭであり、第５のネットワークノードはＢＳＦであり、第６のネットワークノードはＮＲＦである。

例示的な実施形態では、サービス要求メッセージは、イーサネットタイプセッションのサービスデータフローに対して必要とされるＱｏＳを管理するための要求メッセージを含み、Nnef_AFsessionWithQoS APIを介して受信される。

例示的な実施形態では、サービス要求メッセージは、イーサネットタイプセッションについての課金可能パーティを管理するための要求メッセージを含み、Nnef_ChargeableParty APIを介して受信される。

以下では、図１０を参照して、本発明の他の実施形態による第２ネットワークノードの構成を説明する。図１０は、本開示の例示的な実施形態による第２のネットワークノード１０００のブロック図を概略的に示す。図１０の第２のネットワークノード１０００は、図３を参照しながら前述した方法３００を実行しうる。したがって、第２のネットワークノード１０００についてのいくつかの詳細な説明は、これまでに論じた図３の方法３００と図６及び図５のシグナリングシーケンス図とについての対応する説明を参照しうるため、簡略化のためにここでは省略する。

図１０に示されるように、第２のネットワークノード１０００は、少なくとも１つのプロセッサ１００１と少なくとも１つのメモリ１００３とを備える。少なくとも１つのプロセッサ１００１は、例えば、コンピュータプログラム命令を実行することが可能な任意の適切なＣＰＵ（中央演算処理装置）、マイクロコントローラ、ＤＳＰ（デジタルシグナルプロセッサ）等を含む。少なくとも１つのメモリ１００３は、ＲＡＭ（ランダムアクセスメモリ）及びＲＯＭ（リードオンリーメモリ）の任意の組み合わせでありうる。少なくとも１つのプロセッサメモリ１００３は、例えば、磁気メモリ、光メモリ、又はソリッドステートメモリのうちの任意の単一の１つ又は組み合わせでありうるか、又は遠隔搭載型メモリでありうる、永続的ストレージを含みうる。

少なくとも１つのメモリ１００３は、少なくとも１つのプロセッサ１００１によって実行可能な命令を格納する。命令は、少なくとも１つのメモリ１００３からロードされ、少なくとも１つのプロセッサ１００１上で実行されると第２のネットワークノード１０００に、例えば、前述のように図６及び図５のシグナリングシーケンス図を参照して図３にそれぞれ関連してこれまでに説明してきたような手順の動作を実行させうる。このため、簡略化のためにここでは省略する。

本開示は更に、不揮発性メモリ又は揮発性メモリ（例えば、非一時的コンピュータ読取可能記憶媒体、電気的消去可能プログラマブル読み出し専用メモリ（ＥＥＰＲＯＭ）、フラッシュメモリ、及びハードドライブ）の形態の、少なくとも１つのコンピュータプログラム製品を提供する。コンピュータプログラム製品は、コンピュータプログラムを含む。

コンピュータプログラムは、少なくとも１つのプロセッサ８０１によって実行されると第１のネットワークノード８００に、例えば、図２に関連して前述した手順の動作を実行させるコード／コンピュータ読取可能命令、又は、少なくとも１つのプロセッサ１００１によって実行されると第２のネットワークノード１０００に、例えば、それぞれ図３に関連して前述した手順の動作を実行させるコード／コンピュータ読取可能命令を含む。

コンピュータプログラム製品は、コンピュータプログラムモジュール内に構造化されたコンピュータプログラムコードとして構成されてもよい。コンピュータプログラムモジュールは、基本的に、図２乃至図６のいずれかに示されるフローのアクションを実行しうる。

プロセッサは、単一のＣＰＵ（中央演算処理装置）でありうるが、２つ以上の処理ユニットを備えてもよい。例えば、プロセッサは、汎用マイクロプロセッサ、命令セットプロセッサ及び／又は関連するチップセット及び／又は特定用途向け集積回路（ＡＳＩＣ）等の専用マイクロプロセッサを含みうる。プロセッサは、キャッシュ目的のためのボードメモリを備えてもよい。コンピュータプログラムは、プロセッサに結合されたコンピュータプログラム製品によって担持されうる。コンピュータプログラム製品は、コンピュータプログラムが格納される非一時的コンピュータ読取可能記憶媒体を含みうる。例えば、コンピュータプログラム製品は、フラッシュメモリ、ランダムアクセスメモリ（ＲＡＭ）、リードオンリーメモリ（ＲＯＭ）、又はＥＥＰＲＯＭであってもよく、上記のコンピュータプログラムモジュールは、代替の実施形態ではメモリの形態で種々のコンピュータプログラム製品に分散されうる。

本開示について、その実施形態を参照して上述してきた。当業者であれば、本開示の精神及び範囲から逸脱することなく、種々の変形、変更及び追加を行うことが可能であることを理解されたい。したがって、本開示の範囲は、上記の特定の実施形態に限定されず、添付の特許請求の範囲によってのみ定められる。

Claims (20)

1. イーサネットタイプセッションをサービングするＰＣＦ（ポリシー制御機能）を、コアネットワークのＮＥＦ（ネットワーク公開機能）が動的に発見することを容易にするための、ＡＦ（アプリケーション機能）における方法（200）であって、
   前記イーサネットタイプセッションについてのサービス要求メッセージを前記ＮＥＦへ送信すること（S201）を含み、前記サービス要求メッセージは、前記イーサネットタイプセッションについてのネットワーク関連識別情報を含み、前記イーサネットタイプセッションについての前記ネットワーク関連識別情報は、
   前記イーサネットタイプセッションについてのＤＮＮ（データネットワーク名）と、
   前記イーサネットタイプセッションについてのＳ－ＮＳＳＡＩ（単一ネットワークスライス選択支援情報）と、
   のうちの少なくとも１つを含む、方法。
2. 請求項１に記載の方法（200）であって、前記イーサネットタイプセッションについての前記ネットワーク関連識別情報は、前記ＡＦにおいて事前設定されるか又は前記ＡＦへ動的に提供される、方法。
3. 請求項１又は２に記載の方法（200）であって、前記サービス要求メッセージは、前記イーサネットタイプセッションと関連付けられたＵＥ（ユーザ装置）についてのＵＥ ＭＡＣ（メディアアクセス制御）アドレスを更に含む、方法。
4. 請求項１乃至３のいずれか一項に記載の方法（200）であって、
   要求されたサービスが、前記イーサネットタイプセッションのために正常に呼び出されたか否かを示す応答を、前記ＮＥＦから受信することを更に含む、方法。
5. 請求項１乃至４のいずれか一項に記載の方法（200）であって、前記サービス要求メッセージは、
   前記イーサネットタイプセッションのサービスデータフローのために要求されるＱｏＳ（サービス品質）を管理するための要求メッセージと、
   前記イーサネットタイプセッションについての課金可能パーティを管理するための要求メッセージと、
   のうちの少なくとも１つを含む、方法。
6. イーサネットタイプセッションについてのＰＣＦ（ポリシー制御機能）を動的に発見するための、コアネットワークのＮＥＦ（ネットワーク公開機能）における方法（300'）であって、
   前記イーサネットタイプセッションについてのサービス要求メッセージをＡＦ（アプリケーション機能）から受信すること（S301）であって、前記サービス要求メッセージは、前記イーサネットタイプセッションについてのネットワーク関連識別情報を含む、ことと、
   前記ネットワーク関連識別情報に基づいて、前記イーサネットタイプセッションについての前記ＰＣＦのバインディング情報を保持するＢＳＦ（バインディングサポート機能）を発見すること（S303'）と、を含み、前記イーサネットタイプセッションについての前記ネットワーク関連識別情報は、
   前記イーサネットタイプセッションについてのＤＮＮ（データネットワーク名）と、
   前記イーサネットタイプセッションについてのＳ－ＮＳＳＡＩ（単一ネットワークスライス選択支援情報）と、
   のうちの少なくとも１つを含む、方法。
7. 請求項６に記載の方法（300'）であって、前記サービス要求メッセージは、前記イーサネットタイプセッションと関連付けられたＵＥ（ユーザ装置）についてのＵＥ ＭＡＣ（メディアアクセス制御）アドレスを更に含む、方法。
8. 請求項７に記載の方法（300'）であって、
   前記ＡＦから受信された前記ＵＥ ＭＡＣアドレスを使用して、前記ＢＳＦに問い合わせることによって、前記ＰＣＦを発見することを更に含む、方法。
9. 請求項６又は７に記載の方法（300'）であって、
   前記ネットワーク関連識別情報に基づいて前記ＰＣＦを発見すること（S303）を更に含む、方法。
10. 請求項６乃至９のいずれか一項に記載の方法（300'）であって、前記イーサネットタイプセッションについての前記ネットワーク関連識別情報は、前記ＡＦにおいて事前設定されるか又は前記ＡＦへ動的に提供される、方法。
11. 請求項６に記載の方法（300'）であって、前記ＢＳＦは、前記ＮＥＦが、前記イーサネットタイプセッションについての前記ＤＮＮと、前記イーサネットタイプセッションについての前記Ｓ－ＮＳＳＡＩと、のうちの前記少なくとも１つを使用して、ＮＲＦ（ネットワークリポジトリ機能）に問い合わせをすることによって発見される、方法。
12. 請求項６乃至１１のいずれか一項に記載の方法（300'）であって、
    前記イーサネットタイプセッションのために要求されたサービスを呼び出すための別のサービス要求メッセージを、前記ＰＣＦへ送信することと、
    前記要求されたサービスが、前記イーサネットタイプセッションのために正常に呼び出されたか否かを示す応答を、前記ＰＣＦから受信することと、
    を更に含む、方法。
13. 請求項６乃至１２のいずれか一項に記載の方法（300'）であって、
    前記サービス要求メッセージは、前記イーサネットタイプセッションのサービスデータフローのために要求されるＱｏＳ（サービス品質）を管理するための要求メッセージを含み、Nnef_AFsessionWithQoS API（アプリケーションプログラミングインタフェース）を介して受信される、方法。
14. 請求項６乃至１３のいずれか一項に記載の方法（300'）であって、
    前記サービス要求メッセージは、前記イーサネットタイプセッションについての課金可能パーティを管理するための要求メッセージを含み、Nnef_ChargeableParty APIを介して受信される、方法。
15. ＡＦ（アプリケーション機能）（800）であって、
    少なくとも１つのプロセッサ（801）と、
    命令を格納した少なくとも１つのメモリ（803）と、を備え、当該命令は、前記少なくとも１つのプロセッサ（801）上で実行されると前記ＡＦ（800）に、
    イーサネットタイプセッションについてのサービス要求メッセージをＮＥＦ（ネットワーク公開機能）へ送信させ、前記サービス要求メッセージは、前記イーサネットタイプセッションについてのネットワーク関連識別情報を含み、前記イーサネットタイプセッションについての前記ネットワーク関連識別情報は、
    前記イーサネットタイプセッションについてのＤＮＮ（データネットワーク名）と、
    前記イーサネットタイプセッションについてのＳ－ＮＳＳＡＩ（単一ネットワークスライス選択支援情報）と、
    のうちの少なくとも１つを含む、ＡＦ。
16. 請求項１５に記載のＡＦ（800）であって、前記命令は更に、前記少なくとも１つのプロセッサ（801）上で実行されると前記ＡＦ（800）に、請求項２乃至５のいずれか一項に記載の方法を実行させる、ＡＦ。
17. ＮＥＦ（ネットワーク公開機能）（1000）であって、
    少なくとも１つのプロセッサ（1001）と、
    命令を格納した少なくとも１つのメモリ（1003）と、を備え、当該命令は、前記少なくとも１つのプロセッサ（1001）上で実行されると前記ＮＥＦ（1000）に、
    イーサネットタイプセッションについてのサービス要求メッセージをＡＦ（アプリケーション機能）から受信することであって、前記サービス要求メッセージは、前記イーサネットタイプセッションについてのネットワーク関連識別情報を含む、ことと、
    前記ネットワーク関連識別情報に基づいて、前記イーサネットタイプセッションについてのＰＣＦ（ポリシー制御機能）のバインディング情報を保持するＢＳＦ（バインディングサポート機能）を発見することと、を行わせ、前記イーサネットタイプセッションについての前記ネットワーク関連識別情報は、
    前記イーサネットタイプセッションについてのＤＮＮ（データネットワーク名）と、
    前記イーサネットタイプセッションについてのＳ－ＮＳＳＡＩ（単一ネットワークスライス選択支援情報）と、
    のうちの少なくとも１つを含む、ＮＥＦ。
18. 請求項１７に記載のＮＥＦ（1000）であって、前記命令は更に、前記少なくとも１つのプロセッサ（1001）上で実行されると前記ＮＥＦ（1000）に、請求項７乃至１４のいずれか一項に記載の方法を実行させる、ＮＥＦ。
19. コンピュータプログラム命令が格納されたコンピュータ読取可能な記憶媒体であって、前記コンピュータプログラム命令は、少なくとも１つのプロセッサによって実行されると前記少なくとも１つのプロセッサに、請求項１乃至５のいずれか一項に記載の方法を実行させる、記憶媒体。
20. コンピュータプログラム命令が格納されたコンピュータ読取可能な記憶媒体であって、前記コンピュータプログラム命令は、少なくとも１つのプロセッサによって実行されると前記少なくとも１つのプロセッサに、請求項６乃至１４のいずれか一項に記載の方法を実行させる、記憶媒体。

Images