JP2024513718A

JP2024513718A - 端末機器にサービスを提供するための構成を提供するための方法および装置

Info

Publication number: JP2024513718A
Application number: JP2023557172A
Authority: JP
Inventors: ピンチェン，; ウェンリャンシュー，; ティアンメイリャン，; エミリアーノメリノバスケス，; アントニオイニエスタゴンザレス，
Original assignee: テレフオンアクチーボラゲットエルエムエリクソン（パブル）
Priority date: 2021-03-20
Filing date: 2022-03-14
Publication date: 2024-03-27
Also published as: KR20230145485A; CN117015993A; WO2022199411A1; EP4309394A1

Abstract

本開示の実施形態は、端末機器にサービスを提供するための構成を提供するための方法および装置に関する。本開示の第1の態様は、第1のネットワーク機能によって実行される方法を提供する。方法は、UEまたはUEのグループに少なくとも１つのサービスパラメータを提供することを求める要求を第2のネットワーク機能に送信すること(S201)と、要求が承認されたか否かについての応答を前記第2のネットワーク機能から受信すること(S202)とを有しうる。本開示の実施形態によれば、第1のネットワーク機能が端末機器に少なくとも1つのサービスパラメータを提供することを求める要求を送信した後、第1のネットワーク機能は、要求が承認されたか否かを認識することができる。【選択図】図2

Description

本開示は概して通信システムの技術に関し、特には端末機器にサービスを提供するための構成を提供するための方法および装置に関する。

このセクションでは、本開示のより良い理解を支援しうる態様を紹介する。したがって、このセクションの記述はこの観点から解されるべきであり、従来技術に属するものまたは従来技術に属しないものの自認として解されるべきではない。

通信ネットワークにおいて、端末機器は、（アクセスネットワークとコアネットワーク、および/または他の端末機器にわたって）直接または間接的に確立された接続を通じて、ネットワーク機能によってサービスを受けることができる。

通常、（サーバから端末装置へのサービス品質に影響を与え得る、接続を確立するための通信リソースに関する構成のような）サービスの構成(configuration)は、通信ネットワークに記憶されている、端末機器の購読(subscription)情報に基づいて決定されうる。

いくつかのシナリオでは、ネットワーク機能はまた、上記接続の確立、および/または端末機器のためのサービスなどに影響を与えるための設定をコアネットワークに提供することを望む/必要としうる。

この概要では、詳細な説明で後述するコンセプトの一部を簡略化して紹介する。この概要は、特許請求される主題の主要な特徴または本質的な特徴を特定することを意図しておらず、特許請求される主題の範囲を限定するために用いられることも意図していない。

本開示およびそれらの実施形態のある態様は、これらの課題または他の課題に対する解決策を提供しうる。ここで開示される課題の1つ以上に対処する様々な実施形態が提案されうる。本開示の実施形態によれば、端末機器にサービスを提供するための構成を提供するために方法および装置が利用されうる。

本開示の第1の態様は、第1のネットワーク機能によって実行される方法を提供する。方法は、UEまたはUEのグループに少なくとも1つのサービスパラメータを提供することを求める要求を第2のネットワーク機能に送信することと、要求が承認されたか否かについての応答を前記第2のネットワーク機能から受信することとを有しうる。

本開示の実施形態では、前記少なくとも1つのサービスパラメータが第3のネットワーク機能内の購読データに属している場合に要求が承認されうる。

本開示の実施形態では、前記第3のネットワーク機能が統合データ管理(UDM)を含みうる。前記第3のネットワーク機能は、ポリシ制御機能(PCF)を含みうる。

本開示の実施形態では、前記応答が前記少なくとも1つのサービスパラメータの有効時間を含みうる。

本開示の実施形態では、前記少なくとも1つのサービスパラメータがサービスの識別情報(ID)を含みうる。前記少なくとも1つのサービスパラメータは、前記UEまたは前記UEのグループのIDを含みうる。

本開示の実施形態では、前記少なくとも1つのサービスパラメータがさらにサービスプロバイダのIDを含みうる。前記少なくとも1つのサービスパラメータは、前記UEまたは前記UEのグループのための購読データの一部であるサービス関連データをさらに含みうる。前記サービス関連データは、スライシング情報、および/またはデータネットワーク名(DNN)、および/または単一ネットワークスライス選択支援情報(S-NSSAI)を含みうる。

本開示の実施形態では、前記サービスのIDがUEルート選択ポリシ(URSP)、またはQoSを有するAFセッション、またはAF関与(AF influenced)トラフィックルーティング、またはサービス固有パラメータプロビジョニング、またはサービスエリア制限、またはPCFポリシ評価を必要とするトラフィックステアリングポリシのいずれか1つに関連付けられうる。前記サービスプロバイダは、AF、またはマシンタイプ通信(MTC)プロバイダを含みうる。

本開示の実施形態では、前記サービスの前記IDによって示されるサービスが前記UEまたは前記UEのグループに対して承認される場合、および/または購読されているDNNおよび/またはS-NSSAIのリストに属するDNNおよび/またはS-NSSAIを前記サービス関連データが含む場合に、前記要求が承認されうる。

本開示の実施形態において、前記第1のネットワーク機能はアプリケーション機能(AF)を含みうる。前記第2のネットワーク機能はネットワークエクスポージャ機能(NEF)を含みうる。

本開示の第2の態様は、第2のネットワーク機能によって実行される方法を提供する。方法は、第1のネットワーク機能から、UEまたはUEのグループに少なくとも1つのサービスパラメータを提供することを求める第1の要求を受信することと、前記第1のネットワーク機能が前記UEまたは前記UEのグループのための前記少なくとも1つのサービスパラメータを提供することを承認されているか否かを求める第2の要求を第3のネットワーク機能に送信することと、承認の結果を示す、前記第2の要求に対する応答を前記第3のネットワーク機能から受信することと、前記第1の要求が承認されたか否かについての応答を前記第1のネットワーク機能に送信することと、を有しうる。

本開示の実施形態では、前記少なくとも1つのサービスパラメータが前記第3のネットワーク機能内の購読データに属する場合に、前記第1の要求および/または前記第2の要求が許可されうる。

本開示の実施形態では、前記第1の要求に対する前記応答および/または前記第2の要求に対する前記応答が前記少なくとも1つのサービスパラメータの有効時間を含みうる。

本開示の実施形態では、前記方法が、前記第1の要求および/または前記第2の要求が承認された場合、前記少なくとも1つのサービスパラメータを第4のネットワーク機能に保存することをさらに有しうる。

本開示の実施形態では、前記第4のネットワーク機能が統合データリポジトリ(UDR)を含みうる。

本開示の実施形態では、前記サービスの前記IDによって示されるサービスが前記UEまたは前記UEのグループに対して承認される場合、および/または購読されているDNNおよび/またはS-NSSAIのリストに属するDNNおよび/またはS-NSSAIを前記サービス関連データが含む場合に、前記第1の要求および/または前記第2の要求が承認されうる。

本開示の実施形態では、前記第4のネットワーク機能が、第5のネットワーク機能に前記少なくとも1つのサービスパラメータを通知しうる。

本開示の実施形態において、前記第5のネットワーク機能はポリシ制御機能(PCF)を含みうる。

本開示の第3の態様は、第3のネットワーク機能によって実行される方法を提供する。方法は、第2のネットワーク機能から、第1のネットワーク機能がUEまたはUEのグループに少なくとも1つのサービスパラメータを提供することを承認されているか否かの提供を求める要求を受信することと、承認の結果を示す応答を前記第2のネットワーク機能に送信することと、を有しうる。

本開示の実施形態では、前記少なくとも1つのサービスパラメータが前記第3のネットワーク機能内の購読データに属している場合に要求が承認されうる。

本開示の実施形態では、前記第3のネットワーク機能がUDMまたはPCFを含みうる。前記第2のネットワーク機能はNEFを含みうる。

本開示の第4の態様は、第1のネットワーク機能を提供する。前記第1のネットワーク機能は、1つ以上のプロセッサと、コンピュータプログラムコードを有する1つ以上のメモリとを有しうる。前記1つ以上のメモリおよび前記コンピュータプログラムコードは、前記1つ以上のプロセッサとともに、前記第1のネットワーク機能に、少なくとも、UEまたはUEのグループに少なくとも1つのサービスパラメータを提供することを求める要求を第2のネットワーク機能に送信させ、前記要求が承認されたか否かについての応答を前記第2のネットワーク機能から受信させる、ように構成されうる。

本開示の実施形態では、第1のネットワーク機能がさらに、上述の実施形態のいずれかによる方法をさらに実行させられうる。

本開示の第5の態様は、第2のネットワーク機能を提供する。前記第2のネットワーク機能は、1つ以上のプロセッサと、コンピュータプログラムコードを有する1つ以上のメモリとを有しうる。前記1つ以上のメモリおよび前記コンピュータプログラムコードは、前記1つ以上のプロセッサとともに、前記第2のネットワーク機能に、少なくとも、第1のネットワーク機能から、UEまたはUEのグループに少なくとも1つのサービスパラメータを提供することを求める第1の要求を受信させ、前記第1のネットワーク機能が前記UEまたは前記UEのグループのための前記少なくとも1つのサービスパラメータを提供することを承認されているか否かを求める第2の要求を第3のネットワーク機能に送信させ、前記承認の結果を示す、前記第2の要求に対する応答を前記第3のネットワーク機能から受信させ、前記第1の要求が承認されているか否かについての応答を前記第1のネットワーク機能に送信させる、ように構成されうる。

本開示の実施形態では、第2のネットワーク機能がさらに、上述の実施形態のいずれかによる方法をさらに実行させられうる。

本開示の第6の態様は、第3のネットワーク機能を提供する。前記第3のネットワーク機能は、1つ以上のプロセッサと、コンピュータプログラムコードを有する1つ以上のメモリとを有しうる。前記1つ以上のメモリおよび前記コンピュータプログラムコードは、前記1つ以上のプロセッサとともに、前記第3のネットワーク機能に、少なくとも、第1のネットワーク機能がUEまたはUEのグループに少なくとも1つのサービスパラメータを提供することを承認されているか否かを提供することの要求を第2のネットワーク機能から受信させ、承認の結果を示す応答を前記第2のネットワーク機能に送信させる、ように構成されうる。

本開示の実施形態では、第3のネットワーク機能がさらに、上述の実施形態のいずれかによる方法をさらに実行させられうる。

本開示の第7の態様は、ネットワーク機能とともに用いるために具現化されたコンピュータプログラムコードを有するコンピュータ可読媒体を提供し、前記コンピュータプログラムコードは、上述の実施形態のいずれか1つによる方法を実行するためのコードを含む。

本開示の第8の態様は、第1のネットワーク機能を提供する。前記第1のネットワーク機能は、端末機器に少なくとも1つのサービスパラメータを第1のネットワーク機能によって提供することを求める要求を第2のネットワーク機能に送信するように構成された送信ユニットを有しうる。前記第1のネットワーク機能は、前記第2のネットワーク機能から、前記要求が承認されたか否かについての応答を受信するように構成された受信ユニットをさらに有しうる。

本開示の第9の態様は、第2のネットワーク機能を提供する。前記第2のネットワーク機能は、第1のネットワーク機能から、端末機器に少なくとも1つのサービスパラメータを前記第1のネットワーク機能によって提供することを求める要求を受信するように構成された受信ユニットを有しうる。前記第2のネットワーク機能は、前記第1のネットワーク機能に、前記要求が承認されたか否かについての応答を送信するように構成された送信ユニットをさらに有しうる。

本開示の第10の態様は、第3のネットワーク機能を提供する。前記第3のネットワーク機能は、第2のネットワーク機能から、端末機器に少なくとも1つのサービスパラメータを第1のネットワーク機能によって提供することを求める要求を受信するように構成された受信ユニットを有しうる。前記第3のネットワーク機能は、前記第2のネットワーク機能に、前記要求が承認されたか否かについての応答を送信するように構成された送信ユニットをさらに有しうる。

本開示の第11の態様によれば、ホストコンピュータと、基地局と、UEとを含みうる通信システムにおいて実施される方法が提供される。方法は、前記ホストコンピュータでユーザデータを提供することを有しうる。場合により、方法は、前記ホストコンピュータで、前記基地局を有するセルラネットワークを介して前記UEに前記ユーザデータを搬送する送信を開始することを有しうる。

本開示の第12の態様によれば、ホストコンピュータを含む通信システムが提供される。前記ホストコンピュータは、ユーザデータを提供するように構成された処理回路と、UEへの送信のために前記ユーザデータをセルラーネットワークに転送するように構成された通信インターフェースとを有しうる。前記セルラーネットワークは、無線インターフェースおよび処理回路を有する基地局を有しうる。

本開示の第13の態様によれば、ホストコンピュータを含む通信システムが提供される。前記ホストコンピュータは、ユーザデータを提供するように構成された処理回路と、UEへの送信のためにセルラーネットワークにユーザデータを転送するように構成された通信インターフェースとを有しうる。前記UEは、無線インターフェースおよび処理回路を有しうる。

本開示の第14の態様によれば、ホストコンピュータと、基地局と、UEとを含みうる通信システムにおいて実施される方法が提供される。方法は、前記ホストコンピュータで、前記UEから前記基地局に送信されたユーザデータを受信することを有しうる。

本開示の第15の態様によれば、ホストコンピュータを含む通信システムが提供される。前記ホストコンピュータは、UEから基地局への送信に由来するユーザデータを受信するように構成された通信インターフェースを有しうる。前記UEは、無線インターフェースおよび処理回路を有しうる。

本開示の第16の態様によれば、ホストコンピュータと、基地局と、UEとを含みうる通信システムにおいて実施される方法が提供される。方法は、前記ホストコンピュータで、前記基地局から、前記基地局が前記UEから受信した送信に由来するユーザデータを受信することを有しうる。

本開示の第17の態様によれば、ホストコンピュータを含みうる通信システムが提供される。前記ホストコンピュータは、UEから基地局への送信に由来するユーザデータを受信するように構成された通信インターフェースを有しうる。前記基地局は、無線インターフェースおよび処理回路を有しうる。

本開示の実施形態によれば、端末機器にサービスを提供するための構成を提供するための方法または装置が提供される。特に、第1のネットワーク機能が端末機器に少なくとも1つのサービスパラメータを提供することを求める要求を送信した後、前記第1のネットワーク機能は、前記要求が承認されたか否かについての応答を取得しうる。

添付図面における本開示のいくつかの実施形態のより詳細な説明を通じて、本開示の上記および他の目的、特徴および利点がより明らかになるであろう。ここで、同一の参照符号は、一般に、本開示の実施形態における同じ構成要素を示す。

図1Aは、サービスパラメータプロビジョニングのための例示的な手順を示す図である。

図1Bは、スライス選択フローの一例を示す図である。

図1Cは、5GCにおける例示的なネットワークエクスポージャ機能を示す図である。

図2は、本開示の実施形態による、第1のネットワーク機能によって実行される方法を示すフローチャートである。

図3Aは、本開示の実施形態による、第2のネットワーク機能によって実行される方法を示すフローチャートである。

図3Bは、本開示の実施形態による、第2のネットワーク機能によって実行される方法の追加ステップを示すフローチャートである。

図3Cは、本開示の実施形態による、第2のネットワーク機能によって実行される方法の別の追加ステップを示すフローチャートである。

図3Dは、本開示の実施形態による、第2のネットワーク機能によって実行される別の方法を示すフローチャートである。

図4は、本開示の実施形態による、第3のネットワーク機能によって実行される方法を示すフローチャートである。

図5Aは、本開示のいくつかの実施形態のハイレベルソリューションの概要を示す図である。

図5Bは、例示的なUDMベースの早期承認手順を示すコールフロー図である。

図6は、本開示の実施形態による、端末機器にサービスを提供するための構成を提供するための例示的なコールフロー図である。

図7Aは、本開示の実施形態による、第1のネットワーク機能、第2のネットワーク機能、および第3のネットワーク機能のための装置を示すブロック図である。

図7Bは、本開示の実施形態による、コンピュータ可読記憶媒体を示すブロック図である。

図8Aは、本開示の実施形態による、第1のネットワーク機能のための装置のユニットを模式的に示す図である。

図8Bは、本開示の実施形態による、第2のネットワーク機能のための装置のユニットを模式的に示す図である。

図8Cは、本開示の実施形態による、第3のネットワーク機能のための装置のユニットを模式的に示す図である。

図9は、本開示のいくつかの実施形態に従って、中間ネットワークを介してホストコンピュータに接続された電気通信ネットワークを示すブロック図である。

図10は、本開示のいくつかの実施形態に従って、一部が無線である接続により、基地局を介してUEと通信するホストコンピュータを示すブロック図である。

図11は、本開示の実施形態による、通信システムにおいて実施される方法を示すフローチャートである。

図12は、本開示の実施形態による、通信システムにおいて実施される方法を示すフローチャートである。

図13は、本開示の実施形態による、通信システムにおいて実施される方法を示すフローチャートである。

図14は、本開示の実施形態による、通信システムにおいて実施される方法を示すフローチャートである。

本開示で企図される実施形態のいくつかを、添付図面を参照してより完全に説明する。しかしながら、ここに開示された主題はその範囲に他の実施形態を包含する。開示された主題は、記載された実施形態のみに限定されると解釈されるべきではなく、むしろ、これらの実施形態は、主題の範囲を当業者に知らせるための例として提供される。

一般に、ここで用いられるすべての用語は、異なる意味が明確に与えられ、かつ/あるいは異なる意味が文脈から暗示されない限り、関連する技術分野における通常の意味に従って解釈されるべきである。要素、装置、構成要素、手段、ステップなどへのすべての言及は、明示的に別段の定めがない限り、要素、装置、構成要素、手段、ステップなどの少なくとも1つのインスタンスを意味するものとして非限定的に解釈されるべきである。ここに開示される任意の方法のステップは、別のステップとの前後関係が明示的に記載されていない限り、および/または別のステップと特定の前後関係の必要性が暗示されない限り、開示される通りの順序で実行されなくてもよい。ここに開示される任意の実施形態の任意の特徴は、それが適切であれば任意の他の実施形態に適用されうる。同様に、任意の実施形態の任意の利点は任意の他の実施形態に適用することができ、その逆も同様である。以下の実施形態の他の目的、特徴、および利点は、以下の説明から明らかになるであろう。

本明細書を通じて、特徴、利点、または類似の言葉への言及は、本開示で実現され得る特徴および利点のすべてが、本開示の任意の単一の実施形態にあるべきである、またはあることを意味するものではない。むしろ、特性および利点に言及する言葉は、実施形態に関連して説明される特定の特性、利点、または特性が本開示の少なくとも１つの実施形態に含まれることを意味すると理解される。さらに、本開示に記載される特性、利点、および特性は、１つまたは複数の実施形態において任意の適切な方法で組み合わせることができる。当業者は、本開示が特定の実施形態の特定の特徴または利点の１つまたは複数を欠いた状態で実施されうることを認識するであろう。他の例において、本開示のいずれの実施形態にも存在しないかもしれない追加の特徴および利点が、特定の実施形態で認識されうる。

本明細書で用いられる場合、「ネットワーク」または「通信ネットワーク/システム」という用語は、ニューラジオ(NR)、ロングタームエボリューション(LTE)、LTEアドバンスト、広帯域符号分割多元接続(WCDMA(登録商標))、高速パケットアクセス(HSPA)などの任意の適切な通信規格に従うネットワーク/システムを意味する。さらに、通信ネットワーク内の端末機器とネットワークノードとの間の通信は第1世代(1G)、第2世代(2G)、2.5G、2.75G、第3世代(3G)、4G、4.5G、5G通信プロトコル、および／または現在知られているか、将来開発されるべき任意の他のプロトコルを含み、かつこれらに限定されない、任意の適切な世代通信プロトコルに従って実行されうる。

「機能(function)」という用語は、端末装置がネットワークにアクセスしたり、ネットワークからサービスを受けたりするための、通信システム内のアクセス機能を有する、装置／機器／ノード／エンティティを意味する。機能は、基地局(BS)、アクセスポイント(AP)、マルチセル/マルチキャスト協調エンティティ(MCE)、サーバノード/機能(サービス能力サーバ/アプリケーションサーバ(SCS/AS)、グループ通信サービスアプリケーションサーバ(GCS AS)、アプリケーション機能(AF)など)、エクスポージャノード/機能(サービス能力エクスポージャ機能、モビリティマネジメントエンティティ、ネットワークエクスポージャ機能(NEF)など)、統合データ管理(UDM)、ホーム加入者サーバ(HSS)、セッション管理機能(SMF)、アクセスおよびモビリティ管理機能(AMF)、モビリティ管理エンティティ(MME)、無線通信ネットワーク内のコントローラまたは他の任意の適切な機器、を含みうる。BSは例えば、ノードB(NodeBまたはNB)、発展型NodeB(eNodeBまたはeNB)、次世代NodeB(gNodeBまたはgNB)、遠隔無線ユニット(RRU)、無線ヘッダ(RH)、遠隔無線ヘッド(RRH)、リレー、低電力ノード(フェムト、ピコなど)でありうる。

ネットワーク機能のさらなる例は、MSR BSなどのマルチ標準無線(MSR)無線機器、無線ネットワークコントローラ(RNC)または基地局コントローラ(BSC)などのネットワークコントローラ、送受信基地局(BTS)、送信ポイント、送信ノード、測位ノードなどを含みうる。

しかしながら、より一般的には、ネットワーク機能は、無線通信ネットワークへの端末機器アクセスを可能にする、および/または提供する、あるいは、無線通信ネットワークにアクセスした端末機器に何らかのサービスを提供する、ことが可能な、ように構成された、ように配置された、および/または、ように動作可能な、任意の適切な機器(または機器群)を表しうる。

たとえば、本開示の実施形態では、そのような機能がスタンドアロン装置、仮想マシン、クラウド実装サーバ、および/または分散サーバなどの任意の種類のハードウェアおよび/またはソフトウェアで実施されうる。

「端末機器」という用語は、無線信号を送信および/または受信することによって、基地局などのネットワークエンティティ/ネットワーク機能と、または他の無線機器と通信可能な機器を包含する。したがって、端末機器という用語は、携帯電話、マシンツーマシン通信のための据え置き型または移動型の無線機器、内蔵または埋め込み型の無線カード、外部から挿入されるタイプの無線カード、車両などを包含するが、これらに限定されない。

さらに別の特定の例として、モノのインターネット(IoT)シナリオでは、端末機器がIoTデバイスとも呼ばれ、監視、検知および/または測定などを実行し、そのような監視、検知および/または測定などの結果を別の端末機器および/またはネットワーク機器に送信する機械または他の機器を表しうる。端末機器はこの場合、マシンツーマシン(M2M)デバイスであってよく、第3世代パートナーシッププロジェクト(3GPP)の文脈ではマシンタイプ通信(MTC)機器と呼ばれうる。

１つの特定の例として、端末機器は、3GPP狭帯域モノのインターネット(NB－IoT)規格を実装するUEであってもよい。そのような機械または機器の具体例は、センサ、電力メータなどの計量装置、産業機械、または家庭用または個人用機器、例えば冷蔵庫、テレビ、時計などの個人用ウェアラブルなどである。他のシナリオでは、端末機器は、車両または他の機器、例えば、自身の動作ステータスまたは自身の動作に関連する他の機能を監視、検知、および/または報告することができる医療機器を表しうる。

本明細書において、用語「第1の」、「第2の」などは、異なる要素を意味する。単数形「a」および「an」は文脈上明らかに背反する場合を除き、複数形も含むことが意図される。用語「備える(comprises)」、「有する(comprising)」、「有する(has)」、「有する(having)」、「含む(includes)」、および／または「含む(including)」は本明細書で用いられる場合、述べられた特徴、要素、および／または構成要素などの存在を特定するが、１つまたは複数の他の特徴、要素、構成要素、および／またはそれらの組み合わせの存在を除外しない。用語「～に基づく」は、「～に少なくとも部分的に基づく」と解釈すべきである。用語「一実施形態」および「ある実施形態」は、「少なくとも１つの実施形態」と解釈すべきである。用語「別の実施形態」は、「少なくとも１つの別の実施形態」と解釈されるべきである。その他の定義（明示的および暗示的なもの）を以下に記載する。

サービス固有のパラメータを提供するため、ネットワーク機能に提供されるいくつかの解決策がある。

例えば、3GPP TS(技術仕様)23.502 Rel-16 V16.6.0(図1AはこのTSの図4.15.6.7-1に対応する)では、AFがNEFを通じて5Gシステムにサービス固有のパラメータを提供できるように、NEFサービス手順が規定されている。

ステップ1において、AFは、AF要求を作成することができる。例えば、NEFに送信されるAF要求は、以下のような情報を含みうる。

１）サービス記述

DNNおよびS-NSSAIの組み合わせ

AFサービス識別子

アプリケーション識別子

２）(1以上の)ターゲットUE、またはUEのグループ

GPSI（汎用公衆加入者識別子）、UE IPv4/IPv6/MACアドレス、UEグループID、任意のUE ID

３）サービスパラメータ

V2X (Vehicle to everything)用構成パラメータ

この手順は、すべてのサービスに共通するものとして規定されている。仕様書の現リリースでは、V2X UC(V2Xユースケース)への使用が意図されている。

ステップ2、3において、NEFはAFから受信した要求を承認し(例えば、NEFは、AFがAPI(アプリケーションプログラムインターフェース)/動作の呼び出すことを承認されているか否かをチェックする)、情報を「アプリケーションデータ」としてUDRに保存する。

3GPP TS 23.502 V16.6.0節4.2.4.3に規定されるUEポリシ配信手順に従って目標のUEに到達可能な場合、サービスパラメータはステップ5、6を用いてPCFによって目標のUEに配信される。UEポリシ配信失敗がPCFに通知された場合、PCFは5.2.2.3節に規定されるように、「接続性状態変化(IDLEまたはCONNECTED)」イベントを購読しうる。

ステップ4において、AFは、要求が正常に受信されたことを示す応答をNEFから受信しうる。しかしながら、問題は、AFが、UEのためのサービスを構成することについて要求が承認されたのか否かを認識しておらず、AFは要求がなされた場合にNEFから提供される受信成功の応答をただ信頼することしかできないことである。

3GPP Rel 17では、5GC(5Gコアネットワーク)でのエッジコンピューティングのためのサポートの強化のために新しいWID(ワークアイテム記述)が作成されており、TR(技術報告)23.748 V2.0.0における、Key Issue #1: 複数のPDUセッションのためのDNSベースのソリューション(TRの9.1.1節)における推奨に基づいて、UEのためのUEルート選択ポリシ(URSP)の決定にAFが影響を及ぼすことを可能にするために、この手順を再利用し、強化することが提案されている。

UEルートは、ネットワークスライシングに関連しうる。ネットワークスライシングのコンセプトは、様々な5Gユースケースの多様な要件を満たすために用いられる。異なる特性を有する様々なネットワークサービスが、様々な新しいビジネスモデルを可能にする能力として、第三者のアプリケーション/ユーザ/オペレータに利用されることになる。特定のネットワークサービスは、サードパーティユーザ/オペレータのオンデマンド要件、およびネットワークサービスプロバイダとサービスコンシューマとの間のビジネスポリシに従ってインスタンス化することができる。

今後は、異なる用途のための多くの異なるタイプの専用コアネットワークが存在するようになることが予想される。特定の用途と、特別な特性を有するネットワークサービスとの関係は、柔軟な/機動的なビジネスモデルをサポートするために、動的かつ柔軟でありうる。例えば、特別な用途の開始当初は、特別な用途のトラフィックは、基本ネットワークサービスのための共通ネットワークによって依然として供給される可能性がある。特別なユーザまたはVIPユーザの数が増えるにつれて、専用ネットワークサービスがインスタンス化され、必要な機能をサポートし、柔軟なビジネスモデルを可能にする。さらに、3GPPによって言及されているように、通常、1つのデフォルトCNは、1つまたは複数の専用コアネットワークに関連付けられる。専用コアネットワークが利用できない場合、または十分な情報がない場合、特別用途UEは、基本ネットワークサービスのデフォルトCNに誘導されるか、サービス提供事業者固有のポリシーを用いて専用ネットワークスライスまたは DCN(専用コアネットワーク)に誘導される。

5GCは、UEルート選択ポリシ(URSP)などのポリシ情報を、UEに提供する。このポリシは、検出されたアプリケーショントラフィックを、確立済みのPDU(プロトコルデータユニット)セッションに関連付けることができるか、PDUセッション外の非3GPPアクセスにオフロードすることができるか、または新たなPDUセッションの確立をトリガすることができるか、を決定するためにUEによって用いられる。

URSPの一部は、ネットワークスライシング選択ポリシ(NSSP)である。これは、マッチングアプリケーションを特定のネットワークスライスに関連付けるためにUEによって用いられる。したがって、UEは、所定のビジネスモデルを満たすことが可能な予め定められた特徴およびサービス品質を有する指定されたネットワークスライス内の接続セットアップを用してアプリケーションを実行することができる。

現在、URSP/NSSP規則は、UEに事前構成するか、PCFを用いて5GCによってUEに提供することができる。PCFは、購読情報、ローカル構成、および(UEの場所、ToD(時刻)などの動的条件を入力として受け取ることができる)オペレータポリシーに基づいて、各UEに適用可能なURSP/NSSPルールを選択する。

さらに、3GPP Rel17には、AFがNEFおよびUDRを介してPCFに入力情報を提供することによって、UEまたはUEのグループのために適用可能なURSPに影響を及ぼすことを可能にし、適用可能なURSP(3GPP TR 23.748)の決定に用いられる、現在進行形のWIDがある。

ネットワークスライスを介したデータネットワークへのユーザプレーン接続性の確立は、以下の2つのステップを有する。

必要なネットワークスライスをサポートするAMFを選択するために5GCレジストレーション手順を実行することと、

選択されたネットワークスライス内の必要なデータネットワークと1つ以上のPDUセッションを確立すること、である。

UEがPLMN(Public Land Mobile Network)に事例ストレーションする場合、UEはネットワークに、UEが登録を希望する(1以上の)スライスに対応する(1以上の)S-NSSAIを含んだ要求NSSAIを提供する。UEは、URSPルールのNSSPに基づいてアプリケーションをS-NSSAIに関連付ける。

図1Bは、スライス選択フローの一例を示す図である。

3GPP規定のネットワークスライス選択フロー(TS 23.502から引用)を図1Bに示す(図1Bは、TSの図4.2.2.2.3-1に対応する)。

UE用のネットワークスライスのセットの選択は、通常、NSSFとの対話によるレジストレーション手順で最初にコンタクトしたAMFによってトリガされる。

ステップ4a［条件付き］では、初期AMFからNSSFへ、スライス選択要求(要求NSSAI(Network Slice Selection Assistance Information)、購読S-NSSAI、TAI(tracking area identity)、SUPI(subscription permanent identifier)のPLMN ID)が送信される。

スライス選択の必要性がある場合、例えば、初期AMFが購読情報によって許可された要求NSSAIから(1以上の)S-NSSAIのすべてを提供できない場合、初期AMFはNSSFにスライス選択要求(Slice Selection Request)を送信する。初期AMFはNSSFに、要求NSSAI、購読S-NSSAI、SUPIのPLMN ID、およびUEのTAIを送信する。

ステップ4b［条件付き］において、NSSFから初期AMFへ、スライス選択応答(Slice Selection Response)(AMFセットまたはAMFアドレスのリスト、許可NSSAI、[NSI ID]、[NRF](ネットワークリポジトリ機能)、[拒否された(1以上の)(S-NSSAI), (1以上の)要因値)]が送信される。

NSSFは、許可NSSAIおよび目標AMFセット、または構成に基づいて、(1以上の)候補AMFのリストを、初期AMFに戻す。

3GPPの規定によれば、NSSFは、この情報、ローカル構成、および他の利用可能な情報(UEの現在のトラッキングエリアにおけるRAN能力、またはNWDAF(ネットワークデータ分析機能)によって提供される分析情報を含む)に基づいて、スライス選択決定を行う。

UEのためのネットワークスライスのセットは、UEがネットワークに登録されている間、いつでも変更することができ、またネットワークによってもUEによっても開始されうる。

URSPルールが更新されるか、それらの有効性が変化する場合、UE側では既存のアプリケーションのPDUセッションへの関連付けを再評価する必要がありうる。UEはまた、以下の理由により、アプリケーションのPDUセッションへの関連付けを再評価することができる。-
UE実装に基づく定期的な再評価-
URSPルールに基づいてアプリケーションのトラフィックをルーティングするために用いられる既存のPDUセッションが解放される。

再評価がアプリケーションのPDUセッションへの関連付けの変更につながる場合、たとえば、アプリケーションが別のPDUセッションに関連付けられるべきであったり、新しいPDUセッションを確立する必要があったりする場合、UEは、実装に基づいて適時にそのような変更を実施することができる。

5GCは、例えば、それぞれ、大規模IoT、クリティカル通信、および拡張モバイルブロードバンドなどの様々なサービスに対応するように設計される。サードパーティー/UEがネットワークによって提供されるサービスに関する情報(例えば、接続性情報、QoS、モビリティなど)にアクセスすることを可能にし、オペレータによって設定された制限内で異なる多様なユースケースのためにネットワーク能力を動的にカスタマイズするために、5GCは、サードパーティまたはUEにネットワーク情報の適切なアクセス/交換を可能にするネットワークエクスポージャ機能を提供する。

ネットワークエクスポージャ機能(NEF)は、3GPPのネットワーク内部インタフェースを通じて収集された情報を利用し、適切なAPIを通じてアプリケーション機能(AF)に向けて公開することで、ネットワーク機能のこのような機能の公開をサポートする。TS 23.501 V16.6.0に従った、5CGが規定するエクスポージャアーキテクチャを以下に示す(図1Cは該TSの図4.2.3-5に対応する)。

しかしながら、NEF/UDMサービスAPIのために規定された既存の3GPP手順は、UDR内の購読情報でUEのためにプロビジョニングされている許可値に対する、AFが要求する特定のサービス情報の適切かつ最適な早期検証/チェックを欠いている(たとえば、URSPルールについて要求されるDNN/S-NSSAIは、UEのために許可されされているS-NSSAI/DNNの組合せのリストに属さないことがある)。

確かに、ネットワーク(例えばPCF)は、URSPの誤った情報がUEに送信されるのを避けるために、後で、サービス固有パラメータプロビジョニング手順においてこの種の検証を行うが、この種の検証は、(UEがまだ登録されていない場合や、UEの位置によっては)AFがリクエストを行ったときよりもずっと後に発生する可能性がある。その結果、AFはサービス固有パラメータプロビジョニングのAF要求に対して望ましい応答を得るものの、それが実際には有効な要求でなく、後になって(例えば何時間も経ってから)UEがネットワークに接続したり、特定の場所にアクセスしたりしたときにPCFがこの検証を行い、有効でないため要求をスキップする可能性がある。問題は、AFがこのエラーに気づかず、要求時にNEFから提供された望ましい応答を信頼してしまうことである。

図2に示すように、第1のネットワーク機能200によって実行される方法は、第1のネットワーク機能によって端末機器に少なくとも1つのサービスパラメータを提供することを求める要求を第2のネットワーク機能に送信すること(S201)と、第2のネットワーク機能から、要求が承認されたか否かについての応答を受信することと(S202)、を有しうる。

本開示の実施形態では、少なくとも1つのサービスパラメータが、端末機器または、端末機器を含む端末機器のグループのためのものでありうる。

さらに、端末機器は、具体例としてUEを含みうる。すなわち、ステップS201において、少なくとも1つのサービスパラメータは、UEまたはUEグループに提供されうる。

本開示の実施形態によれば、第1のネットワーク機能は、要求が承認されているか否かについての応答を取得することができる。第1のネットワーク機能からの構成のための早期の承認および検証が実行されうる。したがって、第1のネットワーク機能は、端末機器に対するサービスの状況をより認識することができる。第1のネットワーク機能によってサービスを提供するための、および/またはサービスを構成するための効率が改善されうる。

本開示の実施形態において端末機器は、SUPI、GPSIなどによって示されるユーザ装置(UE)、または無線局と通信可能な任意の他の種類の機器を含みうる。

本開示の実施形態では、少なくとも1つのサービスパラメータが第3のネットワーク機能内の購読データに属している場合に要求が承認されうる。

本開示の実施形態では、第3のネットワーク機能がUDMまたはPCFを含みうる。

実施形態によれば、少なくとも1つのサービスパラメータが、UDMなどの第3のネットワーク機能における購読データに属する場合に要求は承認されうる。特に、UDMは現在、多くの他の公開機能に対する承認を実行しているため、現在のUDMを改良して、第1のネットワーク機能からの要求を承認する機能をさらに持たせることが効率的であろう。

本開示の実施形態では、応答が少なくとも1つのサービスパラメータの有効時間を含みうる。

本開示の実施形態によれば、少なくとも1つのサービスパラメータの有効時間を使用することによって、第1のネットワーク機能は、構成の再要求/更新がいつ必要になるかを認識することができる。

本開示の実施形態では、少なくとも1つのサービスパラメータがサービスの識別情報(ID)を含みうる。少なくとも1つのサービスパラメータは、端末機器のIDを含みうる。

本開示の実施形態によれば、サービスを示すID、および/または端末機器を示すIDなどのいくつかのパラメータが、推奨されるか、または必須とされてもよい。たとえば、これらのパラメータを使用することによって、要求は、特定の端末機器のための特定のサービスが第1のネットワーク機能によって構成されることを少なくとも示しうる。

本開示の実施形態では、少なくとも1つのサービスパラメータがさらにサービスプロバイダのIDを含みうる。少なくとも1つのサービスパラメータは、端末機器のための購読データの一部であるサービス関連データをさらに含みうる。サービス関連データは、スライシング情報、および/またはデータネットワーク名(DNN)、および/または単一ネットワークスライス選択支援情報(S-NSSAI)を含みうる。

本開示の実施形態では、サービスのIDが任意の既存のサービスに関連付けられてもよく、または新しいサービスに関連付けられてもよい。例えば、本開示の実施形態では、サービスのIDがUEルート選択ポリシ(URSP)、またはQoSを有するAFセッション、またはAF関与(AF influenced)トラフィックルーティング、またはサービス固有パラメータプロビジョニング、またはサービスエリア制限、またはPCFポリシ評価を必要とするトラフィックステアリングポリシのいずれか1つに関連付けられうる。サービスプロバイダは、AF、またはマシンタイプ通信(MTC)プロバイダを含みうる。

実施形態において、サービスプロバイダは、MTCサービスプロバイダまたは任意の他のコンテンツサービスプロバイダ(例えば、Netflix、YouTube(登録商標))を意味し、それはAFIdまたはSCSAsId(Service Capability Server/Application Server Id)またはmtcProviderIdによって、NEFノースバウンドAPIの観点から特定されうる。

本開示の実施形態では、サービスのIDによって示されるサービスが端末機器に対して承認される場合、および/または購読されているDNNおよび/またはS-NSSAIのリストに属するDNNおよび/またはS-NSSAIをサービス関連データが含む場合に、要求が承認されうる。

本開示の実施形態によれば、サービスのIDは、第1のネットワーク機能によって端末機器に対して提供される可能性がある任意の種類のサービスを示しうる。さらに、異なるサービスに基づいて、異なる追加のパラメータも要求に含まれうる。

本開示の実施形態において、第1のネットワーク機能はアプリケーション機能(AF)を含みうる。第2のネットワーク機能はネットワークエクスポージャ機能(NEF)を含みうる。

第2のネットワーク機能300によって実行される方法は、第1のネットワーク機能から、第1のネットワーク機能によって少なくとも1つのサービスパラメータを端末機器に提供することを求める要求を受信すること(S301)と、要求が承認されたか否かについての応答を第1のネットワーク機能に送信すること(S302)と、を有しうる。

本開示の実施形態では、方法が、ローカルポリシに基づいて、第1のネットワーク機能が端末機器のためのサービスについて承認されているか否かを決定すること(S303)と、第1のネットワーク機能が承認されている場合に、第3のネットワーク機能に要求を送信すること(S304)と、第3のネットワーク機能から、要求が承認されたか否かについての応答を受信すること(S305)と、をさらに有しうる。

第3のネットワーク機能に要求を送信する場合、第2のネットワーク機能が厳密に同一な要求を送信する必要がないことを理解されたい。例えば、いくつかのパラメータが削除または追加されうる。さらに、いくつかのパラメータは、外部フォーマット/値から内部フォーマット/値にマッピングされうる。

本開示の実施形態では、少なくとも1つのサービスパラメータが第3のネットワーク機能内の購読データに属する場合に、(第1の要求および/または第2の要求のような)要求が許可されうる。

本開示の実施形態では、第3のネットワーク機能が統合データ管理(UDM)またはPCFを含みうる。

本開示の実施形態では、(第1の要求に対する応答および/または第2の要求に対する応答のような)応答が、少なくとも1つのサービスパラメータの有効時間を含みうる。

本開示の実施形態では、方法が、要求が承認された場合、少なくとも1つのサービスパラメータを第4のネットワーク機能に保存すること(S306)をさらに有しうる。少なくとも1つのサービスパラメータは、第1の要求および/または第2の要求が承認された場合に保存されうる。

本開示の実施形態では、第4のネットワーク機能が統合データリポジトリ(UDR)を含みうる。

本開示の実施形態によれば、要求が承認されれば、少なくとも1つのサービスパラメータは、端末機器のためのサービスを構成するために保存されうる。

図3Dに示すように、第2のネットワーク機能によって実行される方法は、第1のネットワーク機能から、UEまたはUEのグループに少なくとも1つのサービスパラメータを提供することを求める第1の要求を受信すること(S307)と、第1のネットワーク機能がUEまたはUEのグループに少なくとも1つのサービスパラメータを提供することを承認されているか否かを求める第2の要求を第3のネットワーク機能に送信すること(S308)と、承認の結果を示す、第2の要求に対する応答を第3のネットワーク機能から受信すること(S309)と、第1の要求が承認されたか否かについての応答を第1のネットワーク機能に送信すること(S310)と、を有しうる。

本開示の実施形態では、少なくとも1つのサービスパラメータがサービスの識別情報(ID)を含みうる。少なくとも1つのサービスパラメータは、端末機器のIDを含みうる。IDは、UEのグループのUEのものでありうる。

本開示の実施形態では、サービスのIDがUEルート選択ポリシ(URSP)、またはQoSを有するAFセッション、またはAF関与(AF influenced)トラフィックルーティング、またはサービス固有パラメータプロビジョニング、またはサービスエリア制限、またはPCFポリシ評価を必要とするトラフィックステアリングポリシのいずれか1つに関連付けられうる。サービスプロバイダは、AF、またはマシンタイプ通信(MTC)プロバイダを含みうる。

本開示の実施形態では、サービスのIDによって示されるサービスが端末機器に対して承認される場合、および/または購読されているDNNおよび/またはS-NSSAIのリストに属するDNNおよび/またはS-NSSAIをサービス関連データが含む場合に、(第1の要求および/または第2の要求のような)要求が承認されうる。

本開示の実施形態では、第4のネットワーク機能が、第5のネットワーク機能に前記少なくとも1つのサービスパラメータを通知しうる。

本開示の実施形態において、第5のネットワーク機能はポリシ制御機能(PCF)を含みうる。

本開示の実施形態によれば、PCFが少なくとも1つのサービスパラメータ(または端末機器にサービスを提供するためのポリシを含む、少なくとも1つのサービスパラメータの一部)を受信した後、ポリシは、3GPP TSに規定されるようにUEに配信されうる。

第3のネットワーク機能400によって実行される方法は、第2のネットワーク機能から、第1のネットワーク機能によって端末機器に少なくとも1つのサービスパラメータを提供することを求める要求を受信すること(S401)と、要求が承認されたか否かについての応答を第2のネットワーク機能に送信すること(S402)と、を有しうる。

S401において、要求は、第1のネットワーク機能がUEまたはUEのグループに少なくとも1つのサービスパラメータを提供することを承認されているか否かを提供するためのものでありうる。S402において、応答は、承認の結果を示すものであってよい。

本開示の実施形態では、第3のネットワーク機能がUDMまたはPCFを含みうる。第2のネットワーク機能はNEFを含みうる。

本開示の実施形態では、少なくとも1つのサービスパラメータがサービスの識別情報(ID)、および/または端末機器のIDを含みうる。端末機器のIDは、UEのグループのUEのためのものでありうる。

本開示の実施形態では、少なくとも1つのサービスパラメータがさらにサービスプロバイダのIDを含みうる。少なくとも1つのサービスパラメータは、端末機器のための購読データの一部であるサービス関連データをさらに含みうる。端末機器のための購読データは、UEのグループのUEのためのものでありうる。サービス関連データは、スライシング情報、および/またはデータネットワーク名(DNN)、および/または単一ネットワークスライス選択支援情報(S-NSSAI)を含みうる。

本開示の実施形態では、サービスのIDによって示されるサービスが端末機器に対して承認される場合、および/または購読されているDNNおよび/またはS-NSSAIのリストに属するDNNおよび/またはS-NSSAIをサービス関連データが含む場合に、要求が承認されうる。サービスのIDによって示されるサービスは、UEのグループのUEに対して承認される。

図5Aに示すように、ステップ1において、AF要求が、データネットワーク(例えば、オペレータまたはインターネット)のような場所にあるAFによって作成されうる。

ステップ2において、AFは拡張NEFサービスAPI(すなわち、Nnef_ServiceParameter_Create)を呼び出し、(1以上の)目標UE、サービス記述およびポリシ(例えば、AFServiceId、AppId、(1以上の)UE ID、ドメイン記述子)を含む、自身の要求をNEFに送信する。

ステップ2aにおいて、NEFはローカルSLA(サービスレベル合意)ポリシに基づいて、受信されたAF要求を承認する。すなわち、AFはサービスの使用を承認および許可され、AFServiceIdからマッピングされたDNN/S-NSSAIは、(ローカルSLAに基づいて)外部IDを用いることおよび、UDMを用いて外部IDを内部SUPI/グループIDに使用することを許可される。

好ましくは、いくつかのパラメータ(例えば、サービスのID=URSP、またはQoSありのAFセッション、端末機器のID)を必須としてもよい。残りのパラメータはオプションであるが、UDMはこの2つの最小パラメータ(サービスidと機器id)に基づいて要求を承認することができる。他のパラメータ(たとえば、MTCプロバイダId)が追加されてもよい。そして、サービス、例えばURSPに基づいて、追加のパラメータ、例えばNSSAI/DNNも必要とされる。さらに好ましくは、すべてのこれらのパラメータが機器について承認される必要があってよい。すなわち、1)サービス(たとえば、URSP)、2)MTCプロバイダ(複数のアプリケーションを生成するサービスプロバイダ)(たとえば、google.com)、3)サービス関連パラメータ(たとえば、URSPの場合、URSPが要求されたときに必須であるNSSAI/DNNが該当する)。

ローカルポリシは加入者/機器ごとであってよい。すなわち、ローカルポリシは、すべての機器に共通ではない。これは、機器ごとにプロビジョニングされたポリシである(たとえば、device-1の場合、MTC provider-1によって要求されたURSPは、URSPで要求されたNSSAI/DNNがdevice-1にもプロビジョニングされている限り、承認される)。

ステップ2b(改善されたステップ)において、NEFは、要求されたサービス固有情報(DNN/S-NSSAIおよび他のサービス情報)をUEまたはUEのグループが使用することを承認されているか否かを検証するために、UDMを通じた承認を実行する。

ステップ3において、NEFは、情報を「アプリケーションデータ」としてUDRに保存する。

ステップ4において、NEFは、UDRにAF要求を正常に保存した後、AFに応答する。

ステップ5a (前提条件)：PCFはUEが登録されたときに、UDRにおけるデータ変更の通知を購読する。

ステップ5bにおいて、PCFは、Nudr_DM_Notifyサービスを通じてて、UDRからアプリケーション固有情報のデータ変更の通知を受信する。

ステップ6において、PCFは3GPP TS 23.502の4.2.4.3節に規定されるように、UEポリシ配信を開始する。PCFがUEポリシ配信失敗を通知された場合、PCFは、「接続状態変更(IDLEまたはCONNECTED)」イベントを購読することができる。

PCFは、URSPのための所与のサービスのためにUDRによって提供されるS-NSSAI/DNNが、(UDR内のポリシデータの一部としてもプロビジョニングされる)購読されているS-NSSAI/DNNのリストに属することをチェックすべきである。

図5Bは、UDMベースの早期承認手順を示す例示的なコールフロー図である。

図5Bは、サービス固有情報がUEまたはUEのグループに対して承認されていないとき、NEFが要求を即座に拒否するための早期許可(図5Aのステップ2b)を実行することを可能にするための例示的な解決策を示す。

この解決策はAFによる他のサービス固有情報要求、例えば、PCFポリシ評価を必要とするサービス固有パラメータプロビジョニング、URSP、SAR(サービスエリア制限)およびトラフィックステアリングポリシのための初期検証/承認のための一般的な手順として用いることができる。

図5Bに示されるように、AFは、「Nnef_service_specific_create」(UE-ID、サービス固有情報(Service Specific Info)を含む)をNEFに送信して、早期サービス固有承認のためにそのような手順をトリガすることができる。

NEFは、要求されたサービス固有パラメータを用いてAPIを呼び出すことをAFが許可されていることを承認する。の場合、NEFは「Nudm_Service_Specific_Aothorization」(UE-ID、Service Specific Infoを含む)を送信することで、特定のUEまたはUEグループに対するさらなる早期承認をUDMに要求する。

サービスが、AFによって要求されるすべての追加のパラメータを含む特定の(1以上の)UEに対して許可されていれば、UDMは、有効時間を含み得る成功応答を返す。有効時間に達すると承認は期限切れになる。これは、サービス固有情報が依然として許可されていることを確認するために、(例えばNEFまたはAFによって開始される)再承認を強制する。

NEFは、UDMから「Nudm_Service_Specific_Aothorization_Response」を受信することができる。肯定応答は、指示「OK」および有効時間を含みうる。

そして、NEFはフロー(図5Bと同様に、解決策#1、ステップ3参照)に従って動作し、サービス固有情報をUDRに保存する。

NEFは、「Nnef_service_specific_create_response」を送信することによって、要求が特定の(1以上の)UEに対して本当に承認されていることを保証してAFに応答することができる。

新規メッセージのための用語/名称は、限定ではなく単なる例であることを理解されたい。

別の解決策として、NEFはPCFと連絡を取り、UDMの代わりにPCFが早期承認を実行するようにすることができる(購読されているDNN/S-NSSAIもポリシデータの一部である）。しかしながら、他の公開機能(例えば、イベント公開、NIDD(非IPデータ配信)、パラメータプロビジョニング)についてのUEごとの承認をUDMが現在実行しているため、AF要求に応じて様々なNFで承認を実行するよりも、単一のNFに承認を集中させるほうが一貫性があるという点でUDMの方が好ましいかもしれない。さらに、PCFは後で、UDRから通知されたときに連絡を受ける。したがって、同じ手続きのために同じNFが2回(初期段階と後期段階)関与することは、NEFがPCFを経由する代わりに直接UDRにサービス固有の情報を保存し、UDRに保存された情報が適切に承認されていることをPCFが保証するという解決策を考えることにつながるかもしれない。

好ましさはやや劣るものの、適用可能である別の実施形態は、DNN/NSSAIを取得するために、NEFが既存のUDM SDM(加入者データ管理)サービスを再利用することである。しかし、同じリソースには、NEFにとって関心のないAMデータ(例えば、RAT(無線アクセス技術)制限、UPU(UEパラメータ更新)情報、SOR(ローミングのステアリング)情報、タイマなど)が大量に存在するため、いずれにせよ、SDMでの適応が必要になる。さらに、より重要なのは、(一貫したDNN/NSSAIチェックに先立つ)UEごとのサービス承認を解決していないことである。すなわち、あるUEは適切なDNN/NSSAIを持つかもしれないが、AFがこのサービスを使用することは許可されないかもしれない(この場合、それはURSPルールであるが、NEF/AFによるDNNも購読データと一致する必要があるため、既存のNIDDがこの一般的な手続きに該当する可能性がある)、または、UEは、AFによって呼び出されるサービス(例えばURSP変更)については許可されるが、要求するAF/MTCプロバイダについては許可されない可能性がある。Nudm_SDMサービスは、これを行うことは意図されておらず、可能でもない。

本開示の実施形態はPCFポリシ評価を必要とするAF、例えば、URSP、SAR(サービスエリア制限)による現在および/または将来のサービス固有情報要求のために再利用される早期検証/承認のための一般的な手順を提供する。PCF/UDRに連絡する前に、NEFは異なるレベル(サービス、DNN/NSSAI)に基づいて加入者ごとに承認を要求してもよく、その結果、AFは適切な応答(OKまたは「要求禁止」のいずれか)で応答され、5GCネットワークにおいてリソース/シグナリングを節約し、AFに信頼できる応答を即座に提供する。

UDMはさらに、要求されたUEグループ(または任意のUE)の管理が、要求しているAF/MTCプロバイダに対して承認されていること、およびおそらくDNN/NSSAI(この特定の場合では。サービスによって異なる)もそのグループに対して適用可能であることを確認できる。

UEのグループおよび個々のUEメンバーの両方のためのプロビジョニングされた情報が一貫していること、たとえば、グループ内のすべてのUEがグループに適用可能/許可されたDNN/NSSAIを有することを確実にすることは、オペレータのタスクでありうる。

ステップ2bは、既存の3GPP R16サービスパラメータプロビジョニング手順の拡張ステップでありうる。さらに、手順は、既存のステップで新しいパラメータを用いることによって強化されうる。

ステップ1は、AF/AS(アプリケーション機能/アプリケーションサーバ)によるAF要求の作成を示す。

ステップ2は、新しい要求を作成するために、AFが強化されたNEFサービスAPI(すなわち、Nnef_ServiceParameter_create)サービス動作を呼び出し、その要求をNEFに送信することを示している。要求は、以下の情報を含みうる。1) サービス記述DNNとS-NSSAIとの組合せ、AFサービス識別子、アプリケーション識別子。2) (1以上の)目標UEまたはUEのグループ GPSI、UE IPv4/IPv6/MACアドレス、UEグループID、任意のUE ID 3) サービスパラメータUEルートポリシ(トラフィック記述子、アプリケーション/ドメイン記述子、位置/時間条件など)

ステップ2a-1および2a-2は、NEFがローカルSLA(サービスレベル合意)ポリシ(パートナー管理)に基づいてAFを承認することを示し、NEFは、UDMサービスを通じて外部UE IDまたはグループIDを内部IDに変換する。

ステップ2b(拡張ステップ)は、AFから受信したS-NSSAI/DNNおよび他のサービス情報がUDM購読データ内の購読/許可されたS-NSSAI/DNNおよびサービスのリストに属することを検証するために、NEFが拡張されたUDMサービスを使用することを示す(図5参照)。承認が失敗した場合(例えば、DNNがUEに対して購読されていない場合、UEがAFまたはそのような特定のAFによって動的にURSPルールを変更することを許可していない場合)、UDMはAFに対してHTTP 403応答(forbidden)にマッピングされる否定応答を返す。このようにして、AFは、条件が変化するまで(例えば、UEがそのようなAFがURSPルールに影響を与えることを許可するまで)要求を試みるべきではないことが通知される。

ステップ3は、NEFが、AF要求情報を、割り当てられたトランザクション基準IDと共に、アプリケーションデータの一部としてUDRに保存することを示す。

ステップ4は、UDRにAF要求データを保存した後のAFに対するNEF応答を示す。

ステップ5は、UEがネットワークに登録され、PCFが、Nudr_DM_Subscribe(AFサービスパラメータプロビジョニング情報(SUPI))を呼び出すことによって、UDR内で変更されたデータの通知の購読を実行している場合に、(1以上の)PCFがUDRからデータ変更のNudr_DM_Notify通知を受信することを示している。

ステップ6は、PCFが3GPP TS 23.502 V16.6.0節4.2.4.3で規定されるように、UEポリシ配信を開始することを示す。UEポリシ配信失敗がPCFに通知された場合、PCFは5.2.2.3節に規定されるように、「接続性状態変化(IDLEまたはCONNECTED)」イベントを購読しうる。

このような具体的な実装において、本開示の実施形態の利点には、AF影響型(AF infuenced)URSP変更(および他のサービス固有のAF要求)の早期承認および検証を強化する方法を導入し、このような機能をサードパーティアプリケーションに公開することが含まれる。これにより、エンタープライズサービスプロバイダは、エンドユーザのスライステナント利用を制御し、スライス利用効率をさらに向上させることができる。URSPのためのAF影響型PCF決定のための最適化された手順が提供されうる。

図7Aに示されるように、第1/第2/第3のネットワーク機能200/300/400は、1つまたは複数のプロセッサ701/703/705と、コンピュータプログラムコードを有する1つまたは複数のメモリ702/704/706とを有しうる。1つまたは複数のメモリおよびコンピュータプログラムコードは1つまたは複数のプロセッサを用いて、第1/第2/第3のネットワーク機能200/300/400に、少なくとも、図2から図4に示されるような、上述の実施形態のいずれか1つによる方法を実行させるように構成されうる。

例えば、第1のネットワーク機能200は少なくとも、第2のネットワーク機能に、第1のネットワーク機能によって端末機器に少なくとも1つのサービスパラメータを提供することを求める要求を送信し、第2のネットワーク機能から、要求が承認されたか否かについての応答を受信する、ようにさせられる。

別の例では、第1のネットワーク機能200は少なくとも、第2のネットワーク機能に、UEまたはUEのグループに少なくとも1つのサービスパラメータを提供することを求める要求を送信し、要求が承認されたか否かについての応答を第2のネットワーク機能から受信する、ようにさせられうる。

たとえば、第2のネットワーク機能は少なくとも、第1のネットワーク機能から、第1のネットワーク機能によって端末機器に少なくとも1つのサービスパラメータを提供することを求める要求を受信し、要求が承認されたか否かについての応答を第1のネットワーク機能に送信する、ようにさせられる。

別の例では、第2のネットワーク機能が少なくとも、第1のネットワーク機能から、UEまたはUEのグループに少なくとも1つのサービスパラメータを提供することを求める第1の要求を受信し、第1のネットワーク機能がUEまたはUEのグループに少なくとも1つのサービスパラメータを提供することを承認されているか否かを求める第2の要求を第3のネットワーク機能に送信し、承認の結果を示す、第2の要求に対する応答を第3のネットワーク機能から受信し、第1の要求が承認されたか否かについての応答を第1のネットワーク機能に送信する、ようにさせられうる。

例えば、第3のネットワーク機能は少なくとも、第2のネットワーク機能から、第1のネットワーク機能によって端末機器に少なくとも1つのサービスパラメータを提供することを求める要求を受信し、要求が承認されたか否かについての応答を第2のネットワーク機能に送信する、ようにさせられる。

別の例では、第3のネットワーク機能は少なくとも、第2のネットワーク機能から、第1のネットワーク機能がUEまたはUEのグループに少なくとも1つのサービスパラメータを提供することを承認されているか否かを提供することを求める要求を受信し、承認の結果を示す応答を第2のネットワーク機能に送信する、ようにさせられうる。

プロセッサ701、703、705は、1つまたは複数のマイクロプロセッサまたはマイクロコントローラ、ならびにデジタル信号プロセッサ(DSP)、専用デジタルロジックなどの他のデジタルハードウェアなどの、任意の種類の処理構成要素であってよい。メモリ702、704、706は、読み出し専用メモリ(ROM)、ランダムアクセスメモリ、キャッシュメモリ、フラッシュメモリデバイス、光学記憶デバイスなど、任意の種類の記憶構成要素であってよい。

図7Bに示すように、コンピュータ可読媒体700は、第1のネットワーク機能/第2のネットワーク機能/ショートメッセージサービス機能とともに使用するために具現化されたコンピュータプログラムコード707を有しうる。コンピュータプログラムコード707は、図2から図4に示されるような、上述の方法のいずれかを実行するためのコードを有しうる。

たとえば、コンピュータプログラムコード707は、第1のネットワーク機能200、第2のネットワーク機能300、または第3のネットワーク機能400のためのコードを有しうる。

コンピュータ可読記憶媒体700は、RAM、ROM、プログラム可能読み出し専用メモリ(PROM)、消去可能プログラム可能読み出し専用メモリ(EPROM)、電気的消去可能プログラム可能読み出し専用メモリ(EEPROM)、磁気ディスク、光ディスク、フロッピーディスク(登録商標)、ハードディスク、リムーバブルカートリッジ、またはフラッシュドライブなどのメモリを含むように構成されてもよい。

図8Aに示すように、例えば、第1のネットワーク機能のための装置200は、第1のネットワーク機能によって端末機器に少なくとも1つのサービスパラメータを提供することを求める要求を第2のネットワーク機能に送信するように構成された送信部8001と、要求が承認されたか否かについての応答を第2のネットワーク機能から受信するように構成された受信ユニット8002とを有しうる。

別の例では、送信部8001が第2のネットワーク機能に、ユーザ装置(UE)またはUEのグループに少なくとも1つのサービスパラメータを提供することを求める要求を送信するように構成されうる。受信ユニット8002は第2のネットワーク機能から、要求が承認されたか否かについての応答を受信するように構成されうる。

例えば、図8Bに示されるように、第2のネットワーク機能のための装置300は、第1のネットワーク機能から、端末機器に少なくとも1つのサービスパラメータを第1のネットワーク機能によって提供することを求める要求を受信するように構成された受信ユニット8003と、要求が承認されたか否かについての応答を第1のネットワーク機能に送信するように構成された送信部8004とを有しうる。

別の例では、受信ユニット8003が第1のネットワーク機能から、UEまたはUEのグループに少なくとも1つのサービスパラメータを提供することを求める第1の要求を受信するように構成されうる。送信部8004は第1のネットワーク機能がUEまたはUEのグループに少なくとも1つのサービスパラメータを提供することを承認されているか否かを要求するために、第3のネットワーク機能に第2の要求を送信するように構成されうる。受信ユニット8003は、承認の結果を示す、第2の要求に対する応答を第3のネットワーク機能から受信するように構成されうる。送信部8004は、第1の要求が承認されたか否かについての応答を第1のネットワーク機能に送信するように構成されうる。

例えば、図8Cに示されるように、第3のネットワーク機能のための装置400は、第2のネットワーク機能から、端末機器に少なくとも1つのサービスパラメータを第1のネットワーク機能によって提供することを求める要求を受信するように構成された受信ユニット8005と、要求が承認されたか否かについての応答を第2のネットワーク機能に送信するように構成された送信部8006とを有しうる。

別の例では、受信ユニット8005が、第1のネットワーク機能がUEまたはUEのグループに少なくとも1つのサービスパラメータを提供することを承認されているか否かを提供することを求める要求を受信するように構成されうる。送信部8006は、承認の結果を示す応答を第2のネットワーク機能に送信するように構成されうる。

用語「ユニット」は、エレクトロニクス、電気機器、および／または電子機器の分野における従来の意味を有しうるとともに、本開示で説明したもののようなそれぞれのタスク、手順、計算、出力、および／または表示機能などを実行するための、例えば、電気および／または電子回路、デバイス、モジュール、プロセッサ、メモリ、論理半導体および／またはディスクリートデバイス、コンピュータプログラムまたは命令などを含みうる。

これらのユニットにより、第1のネットワーク機能200、第2のネットワーク機能300、および/または第3のネットワーク機能400は、固定されたプロセッサやメモリを必要とせず、通信システム内の少なくとも1つのネットワーク機能/ノード/デバイス/エンティティ/装置から、任意のコンピューティングリソースおよびストレージリソースを手配することができる。ネットワークリソースの使用効率およびネットワークの柔軟性を改善するため、仮想化技術およびネットワークコンピューティング技術を導入することができる。

本開示の例示的な実施形態は、通信システムにおいて実施される方法をさらに提供しうる。

本開示の実施形態によれば、ホストコンピュータと、基地局と、UEとを含みうる通信システムにおいて実施される方法が提供される。方法は、ホストコンピュータでユーザデータを提供することを有しうる。場合により、方法は、ホストコンピュータで、基地局を有するセルラネットワークを介してUEにユーザデータを搬送する送信を開始することを有しうる。

本開示の実施形態によれば、ホストコンピュータを含む通信システムが提供される。ホストコンピュータは、ユーザデータを提供するように構成された処理回路と、UEへの送信のためにユーザデータをセルラーネットワークに転送するように構成された通信インターフェースとを有しうる。セルラーネットワークは、無線インターフェースおよび処理回路を有する基地局を有しうる。

本開示の実施形態によれば、ホストコンピュータを含む通信システムが提供される。ホストコンピュータは、ユーザデータを提供するように構成された処理回路と、UEへの送信のためにセルラーネットワークにユーザデータを転送するように構成された通信インターフェースとを有しうる。UEは、無線インターフェースおよび処理回路を有しうる。

本開示の実施形態によれば、ホストコンピュータと、基地局と、UEとを含みうる通信システムにおいて実施される方法が提供される。方法は、ホストコンピュータで、UEから基地局に送信されたユーザデータを受信することを有しうる。

本開示の実施形態によれば、ホストコンピュータを含む通信システムが提供される。ホストコンピュータは、UEから基地局への送信に由来するユーザデータを受信するように構成された通信インターフェースを有しうる。UEは、無線インターフェースおよび処理回路を有しうる。

本開示の実施形態によれば、ホストコンピュータと、基地局と、UEとを含みうる通信システムにおいて実施される方法が提供される。方法は、ホストコンピュータで、基地局から、基地局がUEから受信した送信に由来するユーザデータを受信することを有しうる。

本開示の実施形態によれば、ホストコンピュータを含みうる通信システムが提供される。ホストコンピュータは、UEから基地局への送信に由来するユーザデータを受信するように構成された通信インターフェースを有しうる。基地局は、無線インターフェースおよび処理回路を有しうる。

図9を参照すると、ー実施形態に従って、通信システムは、無線アクセスネットワークなどのアクセスネットワーク911とコアネットワーク914とからなる、3GPPタイプのセルラネットワークなどの電気通信ネットワーク910を含んでいる。アクセスネットワーク911はNB、eNB、gNB、または他のタイプの無線アクセスポイントなどの複数の基地局912a、912b、912cを有し、複数の基地局912a、912b、912cはそれぞれ対応するカバレッジエリア913a、913b、913cを規定する。各基地局912a、912b、912cは、有線または無線接続915を用いてコアネットワーク914に接続可能である。カバレッジエリア913cに位置する第1のUE991は対応する基地局912cに無線で接続するように、または対応する基地局912cによってページングされるように構成される。カバレッジエリア913a内の第2のUE992は、対応する基地局912aに無線で接続可能である。複数のUE991、992がこの例に示されているが、開示された実施形態は単一のUEがカバレッジエリア内にある状況、または単一のUEが対応する基地局912に接続している状況に等しく適用可能である。

電気通信ネットワーク910はそれ自体がホストコンピュータ930に接続されており、ホストコンピュータ930は、スタンドアロンサーバ、クラウド実装サーバ、分散サーバ、のハードウェアおよび／またはソフトウェアで実施されてもよいし、サーバファーム内の処理リソースとして実施されてもよい。ホストコンピュータ930は、サービスプロバイダの所有または管理下にある場合もあれば、サービスプロバイダによって、またはサービスプロバイダに代わって運用されている場合もある。電気通信ネットワーク910とホストコンピュータ930との間の接続921および922は、コアネットワーク914からホストコンピュータ930に直接延びてもよいし、オプションの中間ネットワーク920を経由してもよい。中間ネットワーク920は、公衆ネットワーク、プライベートネットワーク、ホステッドネットワークのうちの1つ、または2つ以上の組み合わせであってもよく、中間ネットワーク920がある場合は、中間ネットワーク920はバックボーンネットワークまたはインターネットであってもよく、具体的には、中間ネットワーク920は2以上のサブネットワーク（図示せず）を有してもよい。

図9の通信システムは、全体として、接続されたUE991、992とホストコンピュータ930との間の接続性を実現する。この接続性は、オーバーザトップ(OTT)接続950として記述されうる。ホストコンピュータ930および接続されたUE991、992は、アクセスネットワーク911、コアネットワーク914、任意の中間ネットワーク920、および場合によってはさらなるインフラストラクチャ（図示せず）を媒介として使用して、OTT接続950を通じてデータおよび／またはシグナリングを通信するように構成される。OTT接続950は、OTT接続950が通過する参加通信装置がアップリンク通信およびダウンリンク通信のルーティングに気付かないという意味で、透過的でありうる。例えば、基地局912は、接続されたUE991に転送される（例えばハンドオーバされる）ホストコンピュータ930から発信されるデータをもつ入方向ダウンリンク通信の過去のルーティングについて通知されないか、通知される必要がないであろう。同様に、基地局912は、UE991からホストコンピュータ930に向けて発信される出方向アップリンク通信の将来のルーティングを意識する必要はない。

先の段落で論じたUE、基地局、およびホストコンピュータの、一実施形態による例示的な実装を、図10を参照して説明する。通信システム1000において、ホストコンピュータ1010は、通信システム1000の異なる通信装置のインタフェースとの有線または無線接続をセットアップおよび維持するように構成された通信インタフェース1016を含むハードウェア1015を有する。ホストコンピュータ1010は、記憶および／または処理能力を有することができる処理回路1018をさらに有する。特に、処理回路1018は、命令を実行するように構成された1つ以上のプログラマブルプロセッサ、特定用途向け集積回路、フィールドプログラマブルゲートアレイ、またはこれらの組み合わせ（図示せず）を有してもよい。ホストコンピュータ1010は、ホストコンピュータ1010に記憶されるか、ホストコンピュータ1610がアクセス可能で、処理回路1018によって実行可能なソフトウェア1011をさらに有する。ソフトウェア1011は、ホストアプリケーション1012を含む。ホストアプリケーション1012は、UE830およびホストコンピュータ1010で終端するOTT接続1050を介して接続するUE1030のようなリモートユーザに、サービスを提供するように動作可能であってよい。サービスをリモートユーザに提供する際に、ホストアプリケーション1012は、OTT接続1050を使用して送信されるユーザデータを提供することができる。

通信システム1000はさらに、通信システム内に設けられた基地局1020であって、ホストコンピュータ1010およびUE1030と通信することを可能にするハードウェア1025を有する基地局1020を含む。ハードウェア1025は、通信システム1000の異なる通信装置のインタフェースとの有線または無線接続をセットアップおよび維持するための通信インタフェース1026、ならびに基地局1020によってサービスされるカバレッジエリア（図10には示されていない）内に位置するUE1030との少なくとも無線接続1070をセットアップおよび維持するための無線インタフェース1027を含みうる。通信インタフェース1026は、ホストコンピュータ1010への接続1060を容易にするように構成されうる。接続1060は直接的であってもよく、または電気通信システムのコアネットワーク（図10には示されていない）を経由し、および／または電気通信システムの外部の1つ以上の中間ネットワークを経由してもよい。図示の実施形態では、基地局1020のハードウェア1025が、命令を実行するように構成された1つ以上のプログラマブルプロセッサ、特定用途向け集積回路、フィールドプログラマブルゲートアレイ、またはこれらの組み合わせ（不図示）を有しうる処理回路1028をさらに含む。基地局1020はさらに、内部に記憶された、または外部接続を介してアクセス可能なソフトウェア1021を有する。

通信システム1000は、既に言及したUE1030をさらに含む。そのハードウェア1035は、UE1030が現在位置するカバレッジエリアにサービスを提供する基地局との無線接続1070をセットアップし、維持するように構成された無線インタフェース1037を含むことができる。UE1030のハードウェア1035はさらに、命令を実行するように構成された1つ以上のプログラマブルプロセッサ、特定用途向け集積回路、フィールドプログラマブルゲートアレイ、またはこれらの組み合わせ（図示せず）を有しうる処理回路1038を含む。UE1030は、UE1030に記憶されるかUE1030がアクセス可能で、処理回路1038によって実行可能なソフトウェア1031をさらに有する。ソフトウェア1031は、クライアントアプリケーション1032を含む。クライアントアプリケーション1032はホストコンピュータ1010のサポートにより、UE1030を介して人間または人間以外のユーザにサービスを提供するように動作可能である。ホストコンピュータ1010において、実行中のホストアプリケーション1012は、UE1030およびホストコンピュータ1010で終端するOTT接続1050を介して、実行中のクライアントアプリケーション1032と通信することができる。サービスをユーザに提供する際に、クライアントアプリケーション1032は、ホストアプリケーション1012から要求データを受信し、要求データに応答してユーザデータを提供してもよい。OTT接続1050は、要求データおよびユーザデータの両方を転送することができる。クライアントアプリケーション1032は、ユーザと対話して、提供するユーザデータを生成することができる。

図10に示されるホストコンピュータ1010、基地局1020、およびUE1030は、図9のホストコンピュータ930、基地局912a、912b、912cのうちの1つ、およびUE991、992のうちの1つとそれぞれ類似または同一でありうることに留意されたい。つまり、これらのエンティティの内部動作は図10に示したものと同様でありうるとともに、それとは独立して、周囲のネットワークトポロジは図9に示すものとなりうる。

図10において、OTT接続1050は、基地局1020を介したホストコンピュータ1010とUE1030との間の通信を説明するために抽象的に描かれており、中間装置やこれらの装置を介したメッセージの正確なルーティングについては明示的に示されていない。ネットワークインフラストラクチャは、UE1030から、またはサービスプロバイダが運用するホストコンピュータ1010から、あるいはその両方から隠すように構成されてもよいルーティングを決定することができる。OTT接続1050がアクティブである間、ネットワークインフラストラクチャはルーティングを動的に変更する決定を（例えば、負荷分散の考慮やネットワークの再構成に基づいて）さらに行いうる。

UE1030と基地局1020との間の無線接続1070は、本開示全体にわたって説明される実施形態の教示に従う。様々な実施形態のうちの1つ以上は、無線接続1070が最後のセグメントを形成するOTT接続1050を使用して、UE1030に提供されるOTTサービスの性能を改善する。より正確には、これらの実施形態の教示は、レイテンシおよび電力消費を改善する可能性があり、それによって、より低い複雑さ、セルにアクセスするために必要とされる時間の短縮、より良好な応答性、バッテリ寿命の延長などの利点を提供することができる。

データレート、レイテンシ、および1つ以上の実施形態が改善する他のネットワーク動作態様を監視するために測定手順が提供されてもよい。さらに、測定結果の変動に応答して、ホストコンピュータ1010とUE1030との間のOTT接続1050を再構成するためのオプションネットワーク機能があってもよい。OTT接続1050を再構成するための測定手順および／またはネットワーク機能は、ホストコンピュータ1010のソフトウェア1011およびハードウェア1015、またはUE1030のソフトウェア1031およびハードウェア1035、あるいはその両方で実施することができる。いくつかの実施形態において、OTT接続1050が経由する通信機器の中または通信機器に付随してセンサ（図示せず）を設けることができ、センサは、先に例示した監視量の値を供給することによって、またはソフトウェア1011、1031が監視量を計算または推定しうる他の物理量の値を供給することによって、測定手順に参加することができる。OTT接続1050の再構成は、メッセージフォーマット、再送信設定、優先ルーティングなどを含むことができる。再構成は、基地局1020に影響を与える必要はなく、基地局1020には不明または感知不能であってもよい。このような手順および機能は当技術分野で公知かつ実践されているであろう。特定の実施形態において、測定は、スループット、伝搬時間、遅延などのホストコンピュータ1010の測定を容易にする、専用のUEシグナリングを伴いうる。測定は、ソフトウェア1011および1031が伝搬時間、エラーなどを監視しながら、OTT接続1050を使用して、メッセージ、特に空または「ダミー」メッセージを送信させることによって実施することができる。

図11は、一実施形態による、通信システムにおいて実施される方法を示すフローチャートである。通信システムは、図9および図10に関して説明したものであってよい、ホストコンピュータと、基地局と、UEとを含む。本開示を簡単にするために、図11への図面参照のみが、このセクションに含まれる。工程1110において、ホストコンピュータは、ユーザデータを提供する。工程1110の副工程1111（オプションであってよい）において、ホストコンピュータは、ホストアプリケーションを実行することによって、ユーザデータを提供する。工程1120において、ホストコンピュータは、ユーザデータをUEに搬送する送信を開始する。工程1130（オプションであってよい）において、基地局は、本開示全体にわたって説明される実施形態の教示に従って、ホストコンピュータが開始した送信において搬送されたユーザデータをUEに送信する。工程1140（これもオプションであってよい）において、UEは、ホストコンピュータによって実行されるホストアプリケーションに関連するクライアントアプリケーションを実行する。

図12は、一実施形態による、通信システムにおいて実施される方法を示すフローチャートである。通信システムは、図9および図10に関して説明したものであってよい、ホストコンピュータと、基地局と、UEとを含む。本開示を簡単にするために、図12への図面参照のみが、このセクションに含まれる。方法の工程1210において、ホストコンピュータは、ユーザデータを提供する。オプションの副工程（図示せず）では、ホストコンピュータが、ホストアプリケーションを実行することによってユーザデータを提供する。工程1220において、ホストコンピュータは、ユーザデータをUEに搬送する送信を開始する。送信は、本開示全体にわたって説明される実施形態の教示に従って、基地局を介して渡されうる。工程1230（オプションであってよい）において、UEは、送信において搬送されたユーザデータを受信する。

図13は、一実施形態による、通信システムにおいて実施される方法を示すフローチャートである。通信システムは、図9および図10に関して説明したものであってよい、ホストコンピュータと、基地局と、UEとを含む。本開示を簡単にするために、図13への図面参照のみが、このセクションに含まれる。工程1310（オプションであってよい）において、UEは、ホストコンピュータによって提供される入力データを受信する。追加的にまたは代替的に、工程1320において、UEは、ユーザデータを提供する。工程1320の副工程1321（オプションであってよい）において、UEは、クライアントアプリケーションを実行することによってユーザデータを提供する。工程1310の副工程1311（オプションであってよい）においてUEは、ホストコンピュータによって提供された受信入力データに応答して、ユーザデータを提供するクライアントアプリケーションを実行する。ユーザデータを提供する際に、実行されたクライアントアプリケーションは、ユーザから受け取ったユーザ入力をさらに考慮してもよい。ユーザデータが提供された具体的な方法にかかわらず、UEは、副工程1330（オプションであってよい）において、ユーザデータのホストコンピュータへの送信を開始する。方法の工程1340において、ホストコンピュータは、本開示全体にわたって説明される実施形態の教示に従って、UEから送信されたユーザデータを受信する。

図14は、一実施形態による、通信システムにおいて実施される方法を示すフローチャートである。通信システムは、図9および図10に関して説明したものであってよい、ホストコンピュータと、基地局と、UEとを含む。本開示を簡単にするために、図14への図面参照のみが、このセクションに含まれる。工程1410（オプションであってよい）において、本開示全体にわたって説明される実施形態の教示に従って、基地局は、UEからユーザデータを受信する。工程1420（オプションであってよい）において、基地局は、受信したユーザデータのホストコンピュータへの送信を開始する。工程1430（オプションであってよい）において、ホストコンピュータは、基地局によって開始された送信で搬送されるユーザデータを受信する。

一般に、本開示の様々な例示的な実施形態は、ハードウェアまたは専用回路、ソフトウェア、ロジック、またはそれらの任意の組合せによって実施されうる。例えば、いくつかの態様はハードウェアで実施されうる一方で、他の態様はコントローラ、マイクロプロセッサ、または他のコンピューティングデバイスによって実行されうるファームウェアまたはソフトウェアで実施されてもよいが、本開示はそれらに限定されない。本開示の例示的な実施形態の様々な態様は、ブロック図、フローチャート、または他の何らかの視覚的表現を用いて図示および説明され得るが、本明細書に記載されるこれらのブロック、装置、システム、技術または方法は、非限定例として、ハードウェア、ソフトウェア、ファームウェア、専用回路またはロジック、汎用ハードウェアまたはコントローラまたは他のコンピューティングデバイス、またはこれらの何らかの組み合わせで実施され得ることは十分に理解されるところである。

したがって、本開示の例示的な実施形態の少なくともいくつかの態様は、集積回路チップおよびモジュールといった様々な部品で実施されうることを理解すべきである。したがって、本開示の例示的な実施形態は、集積回路として実施される装置で実現されてもよく、集積回路は、本開示の例示的な実施形態に従って動作するように構成可能なデータプロセッサ、デジタル信号プロセッサ、ベースバンド回路および無線周波数回路の少なくとも１つを実施するための回路（ならびに場合によってはファームウェア）を含みうることが理解されよう。

本開示の例示的な実施形態の少なくともいくつかの態様は、１つまたは複数のコンピュータまたは他の機器によって実行される、１つまたは複数のプログラムモジュールなどのコンピュータ実行可能命令で実施されうることを理解すべきである。一般に、プログラムモジュールは、特定のタスクを実行するか、またはコンピュータまたは他の機器内のプロセッサによって実行されたときに特定の抽象データタイプを実施する、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。コンピュータ実行可能命令は、ハードディスク、光ディスク、リムーバブル記憶媒体、半導体メモリ、RAMなどのコンピュータ可読媒体に格納されうる。当業者が理解するように、プログラムモジュールの機能は様々な実施形態における要求に応じて組み合わされたり分散されたりしてもよい。さらに、機能は全体的または部分的に、集積回路、フィールドプログラマブルゲートアレイ(FPGA)などのファームウェアまたはハードウェア均等物で実施されうる。

本開示は、本明細書に明示的に開示された任意の新規な特徴または特徴の組み合わせ、あるいはその一般化された形態を含む。本開示の前述の例示的な実施形態に対する様々な修正および適応化は、添付の図面と併せて読むことにより、前述の説明を考慮して関連する技術の当業者には明らかになるであろう。しかしながら、任意のおよび全ての変更は、本開示の非限定的かつ例示的な実施形態の範囲内に依然として含まれる。特許請求の範囲

Claims

第1のネットワーク機能によって実行される方法であって、
ユーザ装置(UE)またはUEのグループに少なくとも1つのサービスパラメータを提供することを求める要求を第2のネットワーク機能に送信すること(S201)と、
前記第2のネットワーク機能から、前記要求が承認されたか否かについての応答を受信する(S202)ことと、を有する、方法。
前記少なくとも1つのサービスパラメータが第3のネットワーク機能内の購読データに属している場合に前記要求が承認される、請求項1に記載の方法。
前記第3のネットワーク機能が統一データ管理(UDM)を含む、請求項1または2に記載の方法。
前記応答が、前記少なくとも1つのサービスパラメータの有効時間を含む、請求項1から3のいずれか1項に記載の方法。
前記少なくとも1つのサービスパラメータは、
サービスの識別情報、および/または
前記UEまたは前記UEのグループの識別情報、を含む、請求項1から4のいずれか1項に記載の方法。
前記少なくとも1つのサービスパラメータは、
サービスプロバイダの識別情報、および/または、
前記UEまたは前記UEのグループのための購読データの一部であるサービス関連データ、をさらに含み、
前記サービス関連データは、スライシング情報および/またはデータネットワーク名(DNN)および/または単一ネットワークスライス選択支援情報(S-NSSAI)を含む、請求項5に記載の方法。
前記サービスの識別情報は、UEルート選択ポリシ(URSP)、またはQoSを有するAFセッション、またはAF影響型トラフィックルーティング、またはサービス固有パラメータプロビジョニング、またはサービスエリア制限、またはPCFポリシ評価を必要とするトラフィックステアリングポリシのいずれか１つに関連付けられ、および/または
前記サービスプロバイダは、AF、またはマシンタイプ通信(MTC)プロバイダを含む、請求項6に記載の方法。
前記要求は、前記サービスの識別情報によって示されるサービスが前記UEまたは前記UEのグループに対して承認される場合、および/または、前記サービス関連データが、購読されているDNNおよび/またはS-NSSAIのリストに属するDNNおよび/またはS-NSSAIを含む場合に承認される、請求項7に記載の方法。
前記第1のネットワーク機能がアプリケーション機能(AF)を含み、および/または
前記第2のネットワーク機能がネットワークエクスポージャ機能(NEF)を含む、請求項1から8のいずれか1項に記載の方法。
第2のネットワーク機能によって実行される方法であって、
第1のネットワーク機能から、UEまたはUEのグループに少なくとも1つのサービスパラメータを提供することを求める第1の要求を受信すること(S307)と、
前記第1のネットワーク機能が前記UEまたは前記UEのグループに前記少なくとも1つのサービスパラメータを提供することを承認されているか否かを要求する第2の要求を第3のネットワーク機能に送信すること(S308)と、
前記第3のネットワーク機能から、承認の結果を示す、前記第2の要求に対する応答を受信すること(S309)と、
前記第1の要求が承認されたか否かについての応答を前記第1のネットワーク機能に送信すること(S310)と、を有する、方法。
前記少なくとも1つのサービスパラメータが前記第3のネットワーク機能内の購読データに属する場合に、前記第1の要求および/または前記第2の要求が承認される、請求項10に記載の方法。
前記第3のネットワーク機能が統一データ管理(UDM)を含む、請求項10または11に記載の方法。
前記第1の要求に対する前記応答、および/または前記第2の要求に対する前記応答が、前記少なくとも1つのサービスパラメータの有効時間を含む、請求項10から12のいずれか1項に記載の方法。
前記第1の要求および/または前記第2の要求が承認された場合、前記少なくとも1つのサービスパラメータを第4のネットワーク機能に保存することをさらに有する、請求項10から13のいずれか1項に記載の方法。
前記第4のネットワーク機能が統一データリポジトリ(UDR)を含む、請求項14に記載の方法。
前記少なくとも1つのサービスパラメータが、
サービスの識別情報、および/または
前記UEまたは前記UEのグループの識別情報、を含む、請求項10から15のいずれか1項に記載の方法。
前記少なくとも1つのサービスパラメータは、
サービスプロバイダの識別情報、および/または
前記UEまたは前記UEのグループのための購読データの一部であるサービス関連データ、をさらに含み、
前記サービス関連データは、スライシング情報および/またはデータネットワーク名(DNN)および/または単一ネットワークスライス選択支援情報(S-NSSAI)を含む、請求項16に記載の方法。
前記サービスの識別情報は、UEルート選択ポリシ(URSP)、またはQoSを有するAFセッション、またはAF影響型トラフィックルーティング、またはサービス固有パラメータプロビジョニング、またはサービスエリア制限、またはPCFポリシ評価を必要とするトラフィックステアリングポリシのいずれか１つに関連付けられ、および/または、
前記サービスプロバイダは、AF、またはマシンタイプ通信(MTC)プロバイダを含む、請求項17に記載の方法。
前記第1の要求および/または前記第2の要求は、前記サービスの識別情報によって示されるサービスが前記UEまたは前記UEのグループに対して承認される場合、および/または、前記サービス関連データが、購読されているDNNおよび/またはS-NSSAIのリストに属するDNNおよび/またはS-NSSAIを含む場合に承認される、請求項18に記載の方法。
前記第4のネットワーク機能が、前記少なくとも1つのサービスパラメータに関して第5のネットワーク機能に通知する、請求項10から19のいずれか1項に記載の方法。
前記第5のネットワーク機能は、ポリシ制御機能(PCF)を含む、請求項20に記載の方法。
前記第1のネットワーク機能がアプリケーション機能(AF)を含み、および/または
前記第2のネットワーク機能がネットワークエクスポージャ機能(NEF)を含む、請求項10から21のいずれか1項に記載の方法。
第3のネットワーク機能によって実行される方法であって、
第2のネットワーク機能から、第1のネットワーク機能がUEまたはUEのグループに少なくとも1つのサービスパラメータを提供することを承認されているか否かの提供を求める要求を受信すること(S401)と、
前記第2のネットワーク機能に、承認の結果を示す応答を送信すること(S402)と、を有する、方法。
前記少なくとも1つのサービスパラメータが前記第3のネットワーク機能内の購読データに属している場合に前記要求が承認される、請求項23に記載の方法。
前記第3のネットワーク機能がUDMを含み、および/または
前記第2のネットワーク機能がNEFを含む、請求項23または24に記載の方法。
前記応答が、前記少なくとも1つのサービスパラメータの有効時間を含む、請求項23から25のいずれか1項に記載の方法。
前記少なくとも1つのサービスパラメータは、
サービスの識別情報、および/または
前記UEまたは前記UEのグループの識別情報、を含む、請求項23から26のいずれか1項に記載の方法。
前記少なくとも1つのサービスパラメータは、サービスプロバイダの識別情報および/または、前記UEまたは前記UEのグループのための購読データの一部であるサービス関連データをさらに含み、
前記サービス関連データは、スライシング情報および/またはデータネットワーク名(DNN)および/または単一ネットワークスライス選択支援情報(S-NSSAI)を含む、請求項27に記載の方法。
前記サービスの識別情報は、UEルート選択ポリシ(URSP)、またはQoSを有するAFセッション、またはAF影響型トラフィックルーティング、またはサービス固有パラメータプロビジョニング、またはサービスエリア制限、またはPCFポリシ評価を必要とするトラフィックステアリングポリシのいずれか１つに関連付けられ、および/または
前記サービスプロバイダは、AF、またはマシンタイプ通信(MTC)プロバイダを含む、請求項28に記載の方法。
前記要求は、前記サービスの識別情報によって示されるサービスが前記UEまたは前記UEのグループに対して承認される場合、および/または、前記サービス関連データが、購読されているDNNおよび/またはS-NSSAIのリストに属するDNNおよび/またはS-NSSAIを含む場合に承認される、請求項29に記載の方法。
第1のネットワーク機能(200)であって、
1つ以上のプロセッサ(701)と、
コンピュータプログラムコードを有する1つ以上のメモリ(702)と、を有し、
前記1つ以上のメモリおよび前記コンピュータプログラムコードは、前記1つ以上のプロセッサとともに、前記第1のネットワーク機能に少なくとも、
第2のネットワーク機能に、UEまたはUEのグループに少なくとも1つのサービスパラメータの提供を求める要求を送信させ、
前記要求が承認されたか否かについての応答を前記第2のネットワーク機能から受信させる、ように構成される、第1のネットワーク機能(200)。
請求項2から9のいずれか1項に記載の方法をさらに実行するようにされる、請求項31に記載の第1のネットワーク機能(200)。
第2のネットワーク機能(300)であって、
1つ以上のプロセッサ(703)と、
コンピュータプログラムコードを有する1つ以上のメモリ(704)と、を有し、
前記1つ以上のメモリおよび前記コンピュータプログラムコードは、前記1つ以上のプロセッサとともに、前記第2のネットワーク機能に少なくとも、
第1のネットワーク機能から、UEまたはUEのグループに少なくとも1つのサービスパラメータを提供することを求める第1の要求を受信させ、
前記第1のネットワーク機能が前記UEまたは前記UEのグループに前記少なくとも1つのサービスパラメータを提供することを承認されているか否かを求める第2の要求を第3のネットワーク機能に送信させ、
前記承認の結果を示す、前記第2の要求に対する応答を前記第3のネットワーク機能から受信させ、
前記第1の要求が承認されたか否かについての応答を前記第1のネットワーク機能に送信させる、ように構成される、第2のネットワーク機能(300)。
請求項11から22のいずれか1項に記載の方法をさらに実行するようにされる、請求項33に記載の第2のネットワーク機能(300)。
第3のネットワーク機能(400)であって、
1つ以上のプロセッサ(705)と、
コンピュータプログラムコードを有する1つ以上のメモリ(706)と、有し、
前記1つ以上のメモリおよび前記コンピュータプログラムコードは、前記1つ以上のプロセッサとともに、前記第3のネットワーク機能に少なくとも、
第2のネットワーク機能から、第1のネットワーク機能がUEまたはUEのグループに少なくとも1つのサービスパラメータを提供することを承認されているか否かの提供を求める要求を受信させ、
前記第2のネットワーク機能に、承認の結果を示す応答を送信させる、ように構成される、第3のネットワーク機能(400)。
請求項24から30のいずれか1項に記載の方法をさらに実行するようにされる、請求項35に記載の第3のネットワーク機能(400)。
ネットワーク機能とともに用いるために具現化されたコンピュータプログラムコード(707)を有するコンピュータ可読媒体(700)であって、前記コンピュータプログラムコードは、請求項1から30のいずれか1項に記載の方法を実行するためのコードを含む、コンピュータ可読媒体(700)。