特許 7626771 エッジサービス構成

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2025-01-27

(45)【発行日】2025-02-04

(54)【発明の名称】エッジサービス構成

(51)【国際特許分類】

   H04W 76/10 20180101AFI20250128BHJP

   H04W 88/18 20090101ALI20250128BHJP

   H04W 28/084 20230101ALI20250128BHJP

【ＦＩ】

H04W76/10

H04W88/18

H04W28/084

【請求項の数】 17

(21)【出願番号】P 2022540671

(86)(22)【出願日】2020-12-17

(65)【公表番号】

(43)【公表日】2023-03-13

(86)【国際出願番号】 US2020065702

(87)【国際公開番号】W WO2021138069

(87)【国際公開日】2021-07-08

【審査請求日】2023-12-11

(31)【優先権主張番号】62/955,506

(32)【優先日】2019-12-31

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】63/018,582

(32)【優先日】2020-05-01

(33)【優先権主張国・地域又は機関】US

(73)【特許権者】

【識別番号】510030995

【氏名又は名称】インターデイジタル パテント ホールディングス インコーポレイテッド

(74)【代理人】

【識別番号】100079108

【弁理士】

【氏名又は名称】稲葉 良幸

(74)【代理人】

【識別番号】100109346

【弁理士】

【氏名又は名称】大貫 敏史

(74)【代理人】

【識別番号】100117189

【弁理士】

【氏名又は名称】江口 昭彦

(74)【代理人】

【識別番号】100134120

【弁理士】

【氏名又は名称】内藤 和彦

(74)【代理人】

【識別番号】100108213

【弁理士】

【氏名又は名称】阿部 豊隆

(72)【発明者】

【氏名】ムラディン、カタリナ

(72)【発明者】

【氏名】スターシニック、マイケル

(72)【発明者】

【氏名】リー、チュアン

(72)【発明者】

【氏名】リー、ホンクン

(72)【発明者】

【氏名】ニンレク、チーワン

(72)【発明者】

【氏名】シード、デイル

【審査官】小林 正明

(56)【参考文献】

【文献】3GPP TR 23.758 V17.0.0(2019-12)，3GPP，2019年12月，pages:19-23,61-63

【文献】3GPP TR 33.839 V0.4.0(2021-01)，3GPP，2021年01月，pages;13,14,36,37

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｈ０４Ｂ ７／２４－７／２６

Ｈ０４Ｗ ４／００－９９／００

３ＧＰＰ ＴＳＧ ＲＡＮ ＷＧ１－４

ＳＡ ＷＧ１－４

ＣＴ ＷＧ１，４

(57)【特許請求の範囲】

【請求項1】

エッジイネーブラクライアント、ＥＥＣをホストするワイヤレス送信／受信ユニット、すなわち、ＷＴＲＵであって、前記ＷＴＲＵが、プロセッサと、ネットワークに接続された通信回路と、メモリと、を備え、前記メモリが、前記プロセッサによって実行されるときに、前記ＷＴＲＵに、
前記ネットワークに、エッジデータネットワーク構成サーバ、ＥＤＮＣＳ、発見要求指示を含む非アクセス層、ＮＡＳ、要求を送信することであって、前記ＥＤＮＣＳ発見要求指示が、前記ＵＥが前記ネットワークのエッジコンピューティングリソースにアクセスすることを望むことを示す、送信することと、
前記ネットワークから、ＥＤＮＣＳ発見情報を含むＮＡＳ応答を受信することと、を行わせる、コンピュータ実行可能命令を含む、ＷＴＲＵ。

【請求項2】

前記ＥＤＮＣＳ発見情報が、ＥＤＮＣＳの少なくとも１つの識別子を含む、請求項１に記載のＷＴＲＵ。

【請求項3】

前記ＥＤＮＣＳの前記識別子が、完全修飾ドメイン名である、請求項２に記載のＷＴＲＵ。

【請求項4】

前記命令が、前記ＷＴＲＵに、前記ＥＤＮＣＳ発見情報に少なくとも部分的に基づいて、ＰＤＵセッションを確立するように決定することを更に行わせる、請求項１に記載のＷＴＲＵ。

【請求項5】

前記命令が、前記ＷＴＲＵに、前記ＥＤＮＣＳ発見情報に少なくとも部分的に基づいて、エッジサービスを取得するように決定することを更に行わせる、請求項１に記載のＷＴＲＵ。

【請求項6】

ネットワーク機能、ＮＦ、をホストするサーバであって、前記サーバが、プロセッサと、ネットワークに接続された通信回路と、メモリと、を備え、前記メモリが、前記プロセッサによって実行されるときに、前記サーバに、
ワイヤレス送信／受信ユニット、すなわち、ＷＴＲＵから、エッジデータネットワーク構成サーバ、ＥＤＮＣＳ、発見要求指示を含むＮＡＳ要求を受信することであって、前記ＥＤＮＣＳ発見要求指示が、前記ＮＦに、前記ＷＴＲＵが前記ネットワークのエッジコンピューティングリソースにアクセスすることを望むことを示す、受信することと、
前記ＷＴＲＵに、ＥＤＮＣＳ発見情報を含むＮＡＳ応答を送信することと、を行わせる、コンピュータ実行可能命令を含む、サーバ。

【請求項7】

前記ＥＤＮＣＳ発見情報が、ＥＤＮＣＳの少なくとも１つの識別子を含む、請求項６に記載のサーバ。

【請求項8】

前記識別子が、完全修飾ドメイン名、ＦＱＤＮである、請求項７に記載のサーバ。

【請求項9】

前記命令が、前記ＮＦに、前記ＷＴＲＵの加入情報から前記ＥＤＮＣＳ発見情報を導出することを更に行わせる、請求項６に記載のサーバ。

【請求項10】

前記識別子が、インターネットプロトコル、ＩＰ、アドレスである、請求項７に記載のサーバ。

【請求項11】

前記命令が、前記ＷＴＲＵに、前記ＥＤＮＣＳ発見情報に少なくとも部分的に基づいて、ＰＤＵセッションを確立するように決定することを更に行わせる、請求項２に記載のＷＴＲＵ。

【請求項12】

前記ＥＤＮＣＳの前記識別子が、インターネットプロトコル、ＩＰ、アドレスである、請求項２に記載のＷＴＲＵ。

【請求項13】

前記命令が、前記ＷＴＲＵに、前記ＥＤＮＣＳ発見情報に少なくとも部分的に基づいて、ＰＤＵセッションを確立するように決定することを更に行わせる、請求項１２に記載のＷＴＲＵ。

【請求項14】

前記命令が、前記ＷＴＲＵに、前記ＥＤＮＣＳ発見情報に少なくとも部分的に基づいて、ＰＤＵセッションを確立するように決定することを更に行わせる、請求項３に記載のＷＴＲＵ。

【請求項15】

前記命令が、前記ＷＴＲＵに、前記ＥＤＮＣＳ発見情報に少なくとも部分的に基づいて、エッジサービスを取得するように決定することを更に行わせる、請求項２に記載のＷＴＲＵ。

【請求項16】

前記命令が、前記ＷＴＲＵに、前記ＥＤＮＣＳ発見情報に少なくとも部分的に基づいて、エッジサービスを取得するように決定することを更に行わせる、請求項３に記載のＷＴＲＵ。

【請求項17】

前記命令が、前記ＷＴＲＵに、前記ＥＤＮＣＳ発見情報に少なくとも部分的に基づいて、エッジサービスを取得するように決定することを更に行わせる、請求項１２に記載のＷＴＲＵ。

【発明の詳細な説明】

【技術分野】

【0001】

（関連出願の相互参照）
本出願は、「Ｅｄｇｅ Ｓｅｒｖｉｃｅｓ Ｃｏｎｆｉｇｕｒａｔｉｏｎ」と題された２０１９年１２月３１日に出願された米国特許出願第６２／９５５，５０６号、及び「Ｅｄｇｅ Ｓｅｒｖｉｃｅｓ Ｃｏｎｆｉｇｕｒａｔｉｏｎ」と題された２０２０年５月１日に出願された米国特許出願第６３／０１８，５８２号の利益を主張するものであり、それらの内容は、参照によりそれらの全体が本明細書に組み込まれる。

【背景技術】

【0002】

第３世代パートナーシッププロジェクト（3rd Generation Partnership Project、３ＧＰＰ）は、コーデック、セキュリティ、及びサービス品質に関する作業を含む、無線アクセス、コア移送ネットワーク、及びサービス能力を含む、セルラ電気通信ネットワーク技術の技術標準を開発している。最近の無線アクセス技術（radio access technology、ＲＡＴ）標準には、ＷＣＤＭＡ（一般に３Ｇと呼ばれる）、ＬＴＥ（一般に４Ｇと呼ばれる）、ＬＴＥ－Ａｄｖａｎｃｅｄ標準、及び「５Ｇ」とも称されるＮｅｗ Ｒａｄｉｏ（ＮＲ）が含まれる。３ＧＰＰ ＮＲ標準の開発は、継続し、次世代無線アクセス技術（新しいＲＡＴ）の定義を含むと予想され、これは、７ＧＨｚ未満の新しいフレキシブル無線アクセスの提供、及び７ＧＨｚを超える新しいウルトラモバイルブロードバンド無線アクセスの提供を含むと予想される。フレキシブル無線アクセスは、７ＧＨｚ未満の新しいスペクトルにおける新しい非後方互換性無線アクセスからなると予想され、同じスペクトルで一緒に多重化されて、分岐要件を有する一連の広範な３ＧＰＰ ＮＲの使用事例に対処することができる異なる動作モードを含むことが予想される。ウルトラモバイルブロードバンドは、例えば、屋内用途及びホットスポットのためのウルトラモバイルブロードバンドアクセスの機会を提供するセンチメートル波及びミリ波スペクトルを含むと予想される。特に、ウルトラモバイルブロードバンドは、センチメートル波及びミリ波固有のデザイン最適化を用いて、７ＧＨｚ未満のフレキシブル無線アクセスと共通のデザインフレームワークを共有することが予想される。

【0003】

３ＧＰＰは、ＮＲがサポートすることが予想される様々な使用事例を識別し、データ転送速度、待ち時間、及びモビリティのための多種多様なユーザ経験要件をもたらす。使用事例としては、以下の一般的なカテゴリ：強化されたモバイルブロードバンド（enhanced mobile broadband、ｅＭＢＢ）、超信頼性低遅延通信（ultra-reliable low-latency Communication、ＵＲＬＬＣ）、大量機械型通信（massive machine type communications、ｍＭＴＣ）、ネットワーク動作（例えば、ネットワークスライシング、ルーティング、マイグレーション、及びインターワーキング、エネルギー節約）、並びに車車間通信（Vehicle-to-Vehicle Communication、Ｖ２Ｖ）、車両対インフラストラクチャ通信（Vehicle-to-Infrastructure、Ｖ２Ｉ）、車両対ネットワーク通信（Vehicle-to-Network Communication、Ｖ２Ｎ）、車両対歩行者通信（Vehicle-to-Pedestrian Communication、Ｖ２Ｐ）、及び他のエンティティとの車両通信のうちのいずれかを含み得る、強化されたビークルツーエブリシング（vehicle-to-everything、ｅＶ２Ｘ）通信が挙げられる。これらのカテゴリにおける特定のサービス及び用途には、数例を挙げると、例えば、監視及びセンサネットワーク、デバイスリモート制御、双方向リモート制御、パーソナルクラウドコンピューティング、ビデオストリーミング、無線クラウドベースのオフィス、第１対応者の接続性、自動車用ｅコール、災害警報、リアルタイムのゲーム、多人数テレビ電話、自律走行、拡張現実、触覚インターネット、仮想現実、ホームオートメーション、ロボット、及び空中ドローンが含まれる。これらの使用事例などの全てが本明細書で企図される。

【発明の概要】

【0004】

本明細書に開示される態様は、外部ＡＦ／ＡＳがエッジデータネットワーク構成に関して５ＧＣに情報を提供することを可能にする方法について説明する。本明細書に開示される更なる態様は、１）エッジを認識していないアプリケーションクライアントがエッジサービスを利用することを可能にするために、ＥＥＣをホストしていないＵＥがＥＤＮ情報のプロビジョニングを要求することを可能にするメカニズムであって、このようなメカニズムが、ＵＥ登録手順、並びにＵＲＳＰルールのプロビジョニング及び使用に基づき得る、メカニズム、２）ＵＥによってホストされたＥＥＣが、構成サーバとのＩＰ接続性を確立するためのＵＲＳＰルールを使用することによってエッジ構成情報を取得することを可能にするメカニズム、及び３）ＵＥによってホストされたＥＥＣが、登録中にエッジデータネットワーク構成情報を取得することを可能にするメカニズムなどの、エッジサービスの有効化のためのＵＥプロビジョニングに対処するメカニズムについて説明する。

【0005】

本明細書に開示される追加の態様は、１）ＡＦが、ＮＥＦを介してイベント監視露出に加入し、最適化された報告（例えば、待ち時間が少ない）又はＵＥを介した配信を報告するための選好を要求することを可能にするメカニズム、２）集中型ＮＦからの加入及びポリシーを、ＵＥを介して、ＵＥの経路に沿ってエッジ又はローカルの展開に配信することを可能にするメカニズム、並びに３）ＵＥを介して、待ち時間が少なく、集中型ＮＦからエッジサーバへのイベント監視の露出を可能にするメカニズムなど、エッジにおいて待ち時間が少なく、ネットワーク情報の露出を可能にする方法について説明する。

【図面の簡単な説明】

【0006】

より詳細な理解は、以下の説明から、例示として添付の図面と併せて与えられ得る。

【図1A】例示的な通信システムを例示する。

【図1B】例示的なＲＡＮ及びコアネットワークのシステム図である。

【図1C】例示的なＲＡＮ及びコアネットワークのシステム図である。

【図1D】例示的なＲＡＮ及びコアネットワークのシステム図である。

【図1E】別の例示的な通信システムを例示する。

【図1F】ＷＴＲＵなどの例示的な装置又はデバイスのブロック図である。

【図1G】例示的なコンピューティングシステムのブロック図である。

【図2】ＵＥ上のＶ２Ｘ ＡＣによるエッジ及びクラウドＶ２Ｘアプリケーションサーバの使用を例示する。

【図3】エッジアプリケーションを可能にするための３ＧＰＰ定義のアーキテクチャを例示する。（エッジアプリケーションｖ１．０．０（２０１９－０９）を可能にするためのアプリケーションアーキテクチャに関する研究３ＧＰＰ ＴＲ ２３．７５８を参照されたい）。

【図4A】例示的な強化登録手順（ＥＥＣ事例なし）のコールフローを示す。

【図4B】例示的な強化登録手順（ＥＥＣ事例なし）のコールフローを示す。

【図4C】例示的な強化登録手順（ＥＥＣ事例なし）のコールフローを示す。

【図5A】例示的な強化ＵＥ要求ＰＤＵセッション確立のコールフローを示す。

【図5B】例示的な強化ＵＥ要求ＰＤＵセッション確立のコールフローを示す。

【図6A】例示的な強化登録手順（ＥＥＣベースの事例）のコールフローを示す。

【図6B】例示的な強化登録手順（ＥＥＣベースの事例）のコールフローを示す。

【図7】ネットワーク機能を備えた例示的なコアネットワークアーキテクチャのシステム図である。

【図8】エッジ展開のための例示的な最適化されていないネットワーク露出報告経路の一例である。

【図9】集中型ネットワーク機能からの例示的な最適化された報告経路の一例である。

【図10】集中型ネットワーク露出機能からのエッジ報告加入の転送の一例のコールフローである。

【図11】ＵＥを介したエッジ監視ポリシーの例示的なルーティング／配信のコールフローである。

【図12】ＵＥを介した集中型ＮＦからの例示的な報告ルーティングのコールフローである。

【図13A】ＵＥが監視報告をルーティングするためにそのサポートを通信することを可能にする、例示的な強化登録手順のコールフローを示す。

【図13B】ＵＥが監視報告をルーティングするためにそのサポートを通信することを可能にする、例示的な強化登録手順のコールフローを示す。

【図13C】ＵＥが監視報告をルーティングするためにそのサポートを通信することを可能にする、例示的な強化登録手順のコールフローを示す。

【図13D】ＵＥが監視報告をルーティングするためにそのサポートを通信することを可能にする、例示的な強化登録手順のコールフローを示す。

【図13E】ＵＥが監視報告をルーティングするためにそのサポートを通信することを可能にする、例示的な強化登録手順のコールフローを示す。

【図14】ローカルで展開されたＮＦからの最適化された報告経路の一例を例示する。

【発明を実施するための形態】

【0007】

図１Ａは、本明細書に記載及び特許請求されるシステム、方法、及び装置が使用され得る例示的な通信システム１００を例示する。通信システム１００は、無線送／受信ユニット（wireless transmit/receive unit、ＷＴＲＵ）１０２ａ、１０２ｂ、１０２ｃ、１０２ｄ、１０２ｅ、１０２ｆ、及び／又は１０２ｇを含み得、これらは一般的又は集合的にＷＴＲＵ１０２又は複数のＷＴＲＵ１０２と称され得る。通信システム１００は、無線アクセスネットワーク（radio access network、ＲＡＮ）１０３／１０４／１０５／１０３ｂ／１０４ｂ／１０５ｂ、コアネットワーク１０６／１０７／１０９、公衆交換電話網（public switched telephone network、ＰＳＴＮ）１０８、インターネット１１０、他のネットワーク１１２、及びネットワークサービス１１３を含み得る。ネットワークサービス１１３は、例えば、Ｖ２Ｘサーバ、Ｖ２Ｘ機能、ＰｒｏＳｅサーバ、ＰｒｏＳｅ機能、ＩｏＴサービス、ビデオストリーミング、及び／又はエッジコンピューティングなどを含み得る。

【0008】

本明細書に開示される概念は、任意の数のＷＴＲＵ、基地局、ネットワーク、及び／又はネットワーク要素と共に使用され得ることが理解されよう。ＷＴＲＵ１０２の各々は、無線環境において動作し、かつ／又は通信するように構成された任意のタイプの装置又はデバイスであり得る。図１Ａの例では、ＷＴＲＵ１０２の各々は、ハンドヘルド無線通信装置として図１Ａ～図１Ｅに図示されている。無線通信のために企図される多種多様な使用事例では、各ＷＴＲＵは、単なる例として、ユーザ機器（user equipment、ＵＥ）、移動局、固定若しくは移動加入者ユニット、ページャ、携帯電話、携帯情報端末（personal digital assistant、ＰＤＡ）、スマートフォン、ラップトップコンピュータ、タブレット、ネットブック、ノートパソコン、パーソナルコンピュータ、無線センサ、家庭用電気機械器具、スマートウォッチ若しくはスマートクロージングなどのウェアラブルデバイス、医療若しくはｅヘルスデバイス、ロボット、産業機器、ドローン、自動車、バス、若しくはトラックなどの車両、又は飛行機などを含む無線信号を送信及び／又は受信するように構成された任意のタイプの装置又はデバイスを含むか、又はこれらに含まれ得ることが理解される。

【0009】

通信システム１００はまた、基地局１１４ａ、及び基地局１１４ｂを含み得る。図１Ａの例では、各基地局１１４ａ及び１１４ｂは、単一の要素として図示されている。実際には、基地局１１４ａ及び１１４ｂは、任意の数の相互接続された基地局及び／又はネットワーク要素を含み得る。基地局１１４ａは、コアネットワーク１０６／１０７／１０９、インターネット１１０、ネットワークサービス１１３、及び／又は他のネットワーク１１２などの、１つ以上の通信ネットワークへのアクセスを容易にするために、ＷＴＲＵ１０２ａ、１０２ｂ、及び１０２ｃのうちの少なくとも１つと無線でインターフェース接続するように構成された任意のタイプのデバイスであり得る。同様に、基地局１１４ｂは、コアネットワーク１０６／１０７／１０９、インターネット１１０、他のネットワーク１１２、及び／又はネットワークサーバ１１３などの１つ以上の通信ネットワークへのアクセスを容易にするために、リモート無線ヘッド（Remote Radio Head、ＲＲＨ）１１８ａ、１１８ｂ、送信及び受信点（Transmission and Reception Point、ＴＲＰ）１１９ａ、１１９ｂ、及び／又は路側ユニット（Roadside Unit、ＲＳＵ）１２０ａ及び１２０ｂのうちの少なくとも１つと有線でかつ／又は無線でインターフェース接続するように構成された任意のタイプのデバイスであり得る。ＲＲＨ１１８ａ、１１８ｂは、コアネットワーク１０６／１０７／１０９、インターネット１１０、ネットワークサービス１１３、及び／又は他のネットワーク１１２などの、１つ以上の通信ネットワークへのアクセスを容易にするために、ＷＴＲＵ１０２、例えば、ＷＴＲＵ１０２ｃのうちの少なくとも１つと無線でインターフェース接続するように構成された任意のタイプのデバイスであり得る。

【0010】

ＴＲＰ１１９ａ、１１９ｂは、コアネットワーク１０６／１０７／１０９、インターネット１１０、ネットワークサービス１１３、及び／又は他のネットワーク１１２などの、１つ以上の通信ネットワークへのアクセスを容易にするために、ＷＴＲＵ１０２ｄのうちの少なくとも１つと無線でインターフェース接続するように構成された任意のタイプのデバイスであり得る。ＲＳＵ１２０ａ及び１２０ｂは、コアネットワーク１０６／１０７／１０９、インターネット１１０、他のネットワーク１１２、及び／又はネットワークサービス１１３などの、１つ以上の通信ネットワークへのアクセスを容易にするために、ＷＴＲＵ１０２ｅ又は１０２ｆのうちの少なくとも１つと無線でインターフェース接続するように構成された任意のタイプのデバイスであり得る。例として、基地局１１４ａ、１１４ｂは、基地トランシーバ局（base transceiver station、ＢＴＳ）、ノードＢ、ｅＮｏｄｅ Ｂ、ホームノードＢ、ホームｅＮｏｄｅ Ｂ、次世代ノードＢ（Next Generation Node-B、ｇＮｏｄｅ Ｂ）、衛星、サイトコントローラ、アクセスポイント（access point、ＡＰ）、無線ルータなどであってもよい。

【0011】

基地局１１４ａは、基地局コントローラ（Base Station Controller、ＢＳＣ）、無線ネットワークコントローラ（Radio Network Controller、ＲＮＣ）、中継ノードなどの他の基地局及び／又はネットワーク要素（図示せず）も含み得る、ＲＡＮ１０３／１０４／１０５の一部であり得る。同様に、基地局１１４ｂは、ＢＳＣ、ＲＮＣ、中継ノードなどの他の基地局及び／又はネットワーク要素（図示せず）も含み得る、ＲＡＮ１０３ｂ／１０４ｂ／１０５ｂの一部であり得る。基地局１１４ａは、セル（図示せず）と称され得る、特定の地理的領域内で無線信号を送信及び／又は受信するように構成され得る。同様に、基地局１１４ｂは、セル（図示せず）と称され得る、特定の地理的領域内で有線及び／又は無線信号を送信及び／又は受信するように構成され得る。セルは更にセルセクタに分割され得る。例えば、基地局１１４ａと関連付けられたセルは、３つのセクタに分割され得る。したがって、例えば、基地局１１４ａは、３つのトランシーバ、例えば、セルの各セクタについて１つのトランシーバを含み得る。基地局１１４ａは、多重入力多重出力（Multiple-Input Multiple Output、ＭＩＭＯ）技術を用い得、したがって、例えば、セルの各セクタについて複数のトランシーバを利用し得る。

【0012】

基地局１１４ａは、エアインターフェース１１５／１１６／１１７を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、及び１０２ｇのうちの１つ以上と通信し得、これらは、任意の好適な無線通信リンク（例えば、無線周波数（radio frequency、ＲＦ）、マイクロ波、赤外線（infrared、ＩＲ）、紫外線（ultraviolet、ＵＶ）、可視光、センチメートル波、ミリ波、など）であり得る。エアインターフェース１１５／１１６／１１７は、任意の好適な無線アクセス技術（ＲＡＴ）を使用して確立され得る。

【0013】

基地局１１４ｂは、有線又はエアインターフェース１１５ｂ／１１６ｂ／１１７ｂを介して、ＲＲＨ１１８ａ及び１１８ｂ、ＴＲＰ１１９ａ及び１１９ｂ、及び／又はＲＳＵ１２０ａ及び１２０ｂのうちの１つ以上と通信し得、これは、任意の好適な有線（例えば、ケーブル、光ファイバなど）又は無線通信リンク（例えば、ＲＦ、マイクロ波、ＩＲ、ＵＶ、可視光、センチメートル波、ミリ波など）であり得る。エアインターフェース１１５ｂ／１１６ｂ／１１７ｂは、任意の好適なＲＡＴを使用して確立され得る。

【0014】

ＲＲＨ１１８ａ、１１８ｂ、ＴＲＰ１１９ａ、１１９ｂ、及び／又はＲＳＵ１２０ａ、１２０ｂは、エアインターフェース１１５ｃ／１１６ｃ／１１７ｃを介して、ＷＴＲＵ１０２ｃ、１０２ｄ、１０２ｅ、１０２ｆのうちの１つ以上と通信し得、これは、任意の好適な無線通信リンク（例えば、ＲＦ、マイクロ波、ＩＲ、紫外線ＵＶ、可視光、センチメートル波、ミリ波など）であり得る。エアインターフェース１１５ｃ／１１６ｃ／１１７ｃは、任意の好適なＲＡＴを使用して確立され得る。

【0015】

ＷＴＲＵ１０２は、任意の好適な無線通信リンク（例えば、ＲＦ、マイクロ波、ＩＲ、紫外線ＵＶ、可視光、センチメートル波、ミリ波など）であり得るサイドリンク通信などの直接エアインターフェース１１５ｄ／１１６ｄ／１１７ｄを介して互いに通信し得る。エアインターフェース１１５ｄ／１１６ｄ／１１７ｄは、任意の好適なＲＡＴを使用して確立され得る。

【0016】

通信システム１００は、複数のアクセスシステムであり得、ＣＤＭＡ、ＴＤＭＡ、ＦＤＭＡ、ＯＦＤＭＡ、ＳＣ－ＦＤＭＡなどの１つ以上のチャネルアクセススキームを用い得る。例えば、ＲＡＮ１０３／１０４／１０５における基地局１１４ａ、並びにＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、又はＲＡＮ１０３ｂ／１０４ｂ／１０５ｂにおけるＲＲＨ１１８ａ、１１８ｂ、ＴＲＰ１１９ａ、１１９ｂ、及び／又はＲＳＵ１２０ａ、１２０ｂ、並びにＷＴＲＵ１０２ｃ、１０２ｄ、１０２ｅ、及び１０２ｆは、ユニバーサル移動体通信システム（Universal Mobile Telecommunications System、ＵＭＴＳ）、地上無線アクセス（Terrestrial Radio Access、ＵＴＲA）などの無線技術を実装し得、これは、広帯域ＣＤＭＡ（Wideband CDMA、ＷＣＤＭＡ）を使用して、エアインターフェース１１５／１１６／１１７又は１１５ｃ／１１６ｃ／１１７ｃをそれぞれ確立し得る。ＷＣＤＭＡは、高速パケットアクセス（High-Speed Packet Access、ＨＳＰＡ）及び／又は進化型ＨＳＰＡ（ＨＳＰＡ＋）などの通信プロトコルを含み得る。ＨＳＰＡは、高速ダウンリンクパケットアクセス（High-Speed Downlink Packet Access、ＨＳＤＰＡ）及び／又は高速アップリンクパケットアクセス（High-Speed Uplink Packet Access、ＨＳＵＰＡ）を含み得る。

【0017】

ＲＡＮ１０３／１０４／１０５における基地局１１４ａ、並びにＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、及び１０２ｇ、又はＲＡＮ１０３ｂ／１０４ｂ／１０５ｂにおけるＲＲＨ１１８ａ及び１１８ｂ、ＴＲＰ１１９ａ及び１１９ｂ、並びに／又はＲＳＵ１２０ｂ及び１２０ｂ、並びにＷＴＲＵ１０２ｃ、１０２ｄは、進化型ＵＭＴＳ地上無線アクセス（Evolved UMTS Terrestrial Radio Access、Ｅ－ＵＴＲＡ）などの無線技術を実装し得、これは、例えば、ロングタームエボリューション（Long Term Evolution、ＬＴＥ）及び／又はＬＴＥ－Ａｄｖａｎｃｅｄ（ＬＴＥ－Ａ）を使用して、エアインターフェース１１５／１１６／１１７又は１１５ｃ／１１６ｃ／１１７ｃをそれぞれ確立し得る。エアインターフェース１１５／１１６／１１７又は１１５ｃ／１１６ｃ／１１７ｃは、３ＧＰＰ ＮＲ技術を実装し得る。ＬＴＥ及びＬＴＥ－Ａ技術は、ＬＴＥ Ｄ２Ｄ及び／又はＶ２Ｘ技術、並びにインターフェース（サイドリンク通信など）を含み得る。同様に、３ＧＰＰ ＮＲ技術は、ＮＲ Ｖ２Ｘ技術、及びインターフェース（サイドリンク通信など）を含み得る。

【0018】

ＲＡＮ１０３／１０４／１０５における基地局１１４ａ、並びにＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、及び１０２ｇ、又はＲＡＮ１０３ｂ／１０４ｂ／１０５ｂにおけるＲＲＨ１１８ａ及び１１８ｂ、ＴＲＰ１１９ａ及び１１９ｂ、並びに／又はＲＳＵ１２０ａ及び１２０ｂ、並びにＷＴＲＵ１０２ｃ、１０２ｄ、１０２ｅ、及び１０２ｆは、ＩＥＥＥ８０２．１６（例えば、ワイマックス（Worldwide Interoperability for Microwave Access、ＷｉＭＡＸ）、ＣＤＭＡ２０００、ＣＤＭＡ２０００ １ｘ、ＣＤＭＡ２０００ ＥＶ－ＤＯ、暫定規格２０００（Interim Standard、ＩＳ－２０００）、暫定規格９５（Interim Standard、ＩＳ－９５）、暫定規格８５６（Interim Standard、ＩＳ－８５６）、汎欧州デジタル移動電話方式（Global System for Mobile communications、ＧＳＭ）、ＧＳＭ進化型高速データレート（Enhanced Data rates for GSM Evolution、ＥＤＧＥ）、ＧＳＭ ＥＤＧＥ（ＧＥＲＡＮ）などの無線技術を実装し得る。

【0019】

図１Ａの基地局１１４ｃは、例えば、無線ルータ、ホームノードＢ、ホームｅＮｏｄｅ Ｂ、又はアクセスポイントであってもよく、事業所、家庭、車両、列車、空中、衛星、工場、キャンパスなどの局所的エリアにおける無線接続性を容易にするために、任意の好適なＲＡＴを利用し得る。基地局１１４ｃ及びＷＴＲＵ１０２、例えば、ＷＴＲＵ１０２ｅは、ＩＥＥＥ８０２．１１などの無線技術を実装して、無線ローカルエリアネットワーク（Wireless Local Area Network、ＷＬＡＮ）を確立し得る。同様に、基地局１１４ｃ及びＷＴＲＵ１０２、例えば、ＷＴＲＵ１０２ｄは、ＩＥＥＥ８０２．１５などの無線技術を実装して、無線パーソナルエリアネットワーク（wireless personal area network、ＷＰＡＮ）を確立し得る。基地局１１４ｃ及びＷＴＲＵ１０２、例えば、ＷＴＲＵ１０２ｅは、セルラベースのＲＡＴ（例えば、ＷＣＤＭＡ、ＣＤＭＡ２０００、ＧＳＭ、ＬＴＥ、ＬＴＥ－Ａ、ＮＲなど）を利用して、ピコセル又はフェムトセルを確立し得る。図１Ａに示されるように、基地局１１４ｃは、インターネット１１０への直接接続を有し得る。したがって、基地局１１４ｃは、コアネットワーク１０６／１０７／１０９を介してインターネット１１０にアクセスする必要がない場合がある。

【0020】

ＲＡＮ１０３／１０４／１０５及び／又はＲＡＮ１０３ｂ／１０４ｂ／１０５ｂは、コアネットワーク１０６／１０７／１０９と通信し得、これは、音声、データ、メッセージング、認可及び認証、アプリケーション、及び／又はボイスオーバインターネットプロトコル（Voice Over Internet Protocol、ＶｏＩＰ）サービスをＷＴＲＵ１０２のうちの１つ以上に提供するように構成された、任意のタイプのネットワークであり得る。例えば、コアネットワーク１０６／１０７／１０９は、コール制御、請求サービス、移動体位置ベースのサービス、プリペイド発呼、インターネット接続性、パケットデータネットワーク接続性、イーサネット接続性、ビデオ配信などを提供し得、かつ／又はユーザ認証などの、高レベルセキュリティ機能を実行し得る。

【0021】

図１Ａには示されていないが、ＲＡＮ１０３／１０４／１０５及び／若しくはＲＡＮ１０３ｂ／１０４ｂ／１０５ｂ並びに／又はコアネットワーク１０６／１０７／１０９は、ＲＡＮ１０３／１０４／１０５及び／若しくはＲＡＮ１０３ｂ／１０４ｂ／１０５ｂと同じＲＡＴ、又は異なるＲＡＴを採用する他のＲＡＮと直接又は間接的に通信し得ることが理解されよう。例えば、Ｅ－ＵＴＲＡ無線技術を利用し得るＲＡＮ１０３／１０４／１０５及び／又はＲＡＮ１０３ｂ／１０４ｂ／１０５ｂに接続されることに加えて、コアネットワーク１０６／１０７／１０９はまた、ＧＳＭ又はＮＲ無線技術を用いて別のＲＡＮ（図示せず）と通信し得る。

【0022】

コアネットワーク１０６／１０７／１０９はまた、ＰＳＴＮ１０８、インターネット１１０、及び／又は他のネットワーク１１２にアクセスするために、ＷＴＲＵ１０２のためのゲートウェイとして機能し得る。ＰＳＴＮ１０８は、旧来の電話サービス（Plain Old Telephone Service、ＰＯＴＳ）を提供する回線交換電話ネットワークを含み得る。インターネット１１０は、ＴＣＰ／ＩＰインターネットプロトコルスイートにおける伝送制御プロトコル（Transmission Control Protocol、ＴＣＰ）、ユーザデータグラムプロトコル（User Datagram Protocol、ＵＤＰ）、及びインターネットプロトコル（internet protocol、ＩＰ）などの共通通信プロトコルを使用する、相互接続されたコンピュータネットワーク及びデバイスのグローバルシステムを含み得る。他のネットワーク１１２は、他のサービスプロバイダによって所有及び／又は操作される、有線及び／又は無線通信ネットワークを含み得る。例えば、ネットワーク１１２は、ＲＡＮ１０３／１０４／１０５及び／若しくはＲＡＮ１０３ｂ／１０４ｂ／１０５ｂと同じＲＡＴ、又は異なるＲＡＴを採用し得る、１つ以上のＲＡＮに接続された任意のタイプのパケットデータネットワーク（例えば、ＩＥＥＥ８０２．３イーサネットネットワーク）又は別のコアネットワークを含み得る。

【0023】

通信システム１００におけるＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄ、１０２ｅ、及び１０２ｆのいくつか又は全ては、マルチモード能力を含んでもよく、例えば、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄ、１０２ｅ、及び１０２ｆは、異なる無線リンクを介して異なる無線ネットワークと通信するための複数のトランシーバを含み得る。例えば、図１Ａに示されるＷＴＲＵ１０２ｇは、セルラベースの無線技術を用い得る基地局１１４ａ、及びＩＥＥＥ８０２無線技術を用い得る基地局１１４ｃと通信するように構成され得る。

【0024】

図１Ａには示されていないが、ユーザ機器は、ゲートウェイへの有線接続を行い得ることが理解されよう。ゲートウェイは、レジデンシャルゲートウェイ（Residential Gateway、ＲＧ）であってもよい。ＲＧは、コアネットワーク１０６／１０７／１０９への接続性を提供し得る。本明細書に含まれるアイデアの多くは、ネットワークに接続するために有線接続を使用するＷＴＲＵ及びＵＥであるＵＥに等しく適用され得ることが理解されよう。例えば、無線インターフェース１１５、１１６、１１７、及び１１５ｃ／１１６ｃ／１１７ｃに適用されるアイデアは、有線接続に等しく適用され得る。

【0025】

図１Ｂは、例示的なＲＡＮ１０３及びコアネットワーク１０６のシステム図である。上記のように、ＲＡＮ１０３は、ＵＴＲＡ無線技術を用いて、エアインターフェース１１５を介してＷＴＲＵ１０２ａ、１０２ｂ、及び１０２ｃと通信し得る。ＲＡＮ１０３はまた、コアネットワーク１０６と通信し得る。図１Ｂに示されるように、ＲＡＮ１０３は、ノードＢ１４０ａ、１４０ｂ、及び１４０ｃを含み得、これらは各々、エアインターフェース１１５を介して、ＷＴＲＵ１０２ａ、１０２ｂ、及び１０２ｃと通信するための１つ以上のトランシーバを含み得る。ノードＢ１４０ａ、１４０ｂ、及び１４０ｃは各々、ＲＡＮ１０３内の特定のセル（図示せず）と関連付けられ得る。ＲＡＮ１０３はまた、ＲＮＣ１４２ａ、１４２ｂを含み得る。ＲＡＮ１０３は、任意の数のノードＢ及び無線ネットワークコントローラ（ＲＮＣ）を含み得ることが理解されよう。

【0026】

図１Ｂに示されるように、ノードＢ１４０ａ、１４０ｂは、ＲＮＣ１４２ａと通信することができる。更に、ノードＢ１４０ｃは、ＲＮＣ１４２ｂと通信することができる。ノードＢ１４０ａ、１４０ｂ、及び１４０ｃは、Ｉｕｂインターフェースを介して、それぞれのＲＮＣ１４２ａ及び１４２ｂと通信することができる。ＲＮＣ１４２ａ及び１４２ｂは、Ｉｕｒインターフェースを介して互いに通信することができる。ＲＮＣ１４２ａ及び１４２ｂの各々は、それが接続されるそれぞれのノードＢ１４０ａ、１４０ｂ、及び１４０ｃを制御するように構成され得る。加えて、ＲＮＣ１４２ａ及び１４２ｂの各々は、外部ループ電力制御、負荷制御、アドミッション制御、パケットスケジューリング、ハンドオーバ制御、マクロダイバーシティ、セキュリティ機能、データ暗号化などの他の機能を実行又はサポートするように構成され得る。

【0027】

図１Ｂに示されるコアネットワーク１０６は、メディアゲートウェイ（media gateway、ＭＧＷ）１４４、モバイルスイッチングセンタ（Mobile Switching Center、ＭＳＣ）１４６、サービングＧＰＲＳサポートノード（Serving GPRS Support Node、ＳＧＳＮ）１４８、及び／又はゲートウェイＧＰＲＳサポートノード（Gateway GPRS Support Node、ＧＧＳＮ）１５０を含み得る。前述の要素の各々は、コアネットワーク１０６の一部として図示されているが、これらの要素のいずれも、コアネットワークオペレータ以外のエンティティによって所有及び／又は操作され得ることが理解されよう。

【0028】

ＲＡＮ１０３内のＲＮＣ１４２ａは、ＩｕＣＳインターフェースを介してコアネットワーク１０６内のＭＳＣ１４６に接続され得る。ＭＳＣ１４６は、ＭＧＷ１４４に接続され得る。ＭＳＣ１４６及びＭＧＷ１４４は、ＷＴＲＵ１０２ａ、１０２ｂ、及び１０２ｃと従来の地上回線通信デバイスとの間の通信を容易にするために、ＰＳＴＮ１０８などの回路交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、及び１０２ｃに提供し得る。

【0029】

ＲＡＮ１０３内のＲＮＣ１４２ａはまた、ＩｕＰＳインターフェースを介してコアネットワーク１０６内のＳＧＳＮ１４８に接続され得る。ＳＧＳＮ１４８は、ＧＧＳＮ１５０に接続され得る。ＳＧＳＮ１４８及びＧＧＳＮ１５０は、ＷＴＲＵ１０２ａ、１０２ｂ、及び１０２ｃとＩＰ対応デバイスとの間の通信を容易にするために、インターネット１１０などのパケット交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、及び１０２ｃに提供し得る。

【0030】

コアネットワーク１０６はまた、他のサービスプロバイダによって所有及び／又は操作される他の有線又は無線ネットワークを含み得る他のネットワーク１１２に接続され得る。

【0031】

図１Ｃは、例示的なＲＡＮ１０４及びコアネットワーク１０７のシステム図である。上記のように、ＲＡＮ１０４は、Ｅ－ＵＴＲＡ無線技術を用いて、エアインターフェース１１６を介してＷＴＲＵ１０２ａ、１０２ｂ、及び１０２ｃと通信し得る。ＲＡＮ１０４はまた、コアネットワーク１０７と通信し得る。

【0032】

ＲＡＮ１０４は、ｅＮｏｄｅ－Ｂ１６０ａ、１６０ｂ、及び１６０ｃを含み得るが、ＲＡＮ１０４が、任意の数のｅＮｏｄｅ－Ｂを含み得ることが理解されよう。ｅＮｏｄｅ－Ｂ１６０ａ、１６０ｂ、及び１６０ｃは各々、エアインターフェース１１６を介してＷＴＲＵ１０２ａ、１０２ｂ、及び１０２ｃと通信するための１つ以上のトランシーバを含み得る。例えば、ｅＮｏｄｅ－Ｂ１６０ａ、１６０ｂ、及び１６０ｃは、ＭＩＭＯ技術を実装し得る。したがって、ｅＮｏｄｅ－Ｂ１６０ａは、例えば、複数のアンテナを使用して、ＷＴＲＵ１０２ａに無線信号を伝送し、ＷＴＲＵ１０２ａから無線信号を受信することができる。

【0033】

ｅＮｏｄｅ－Ｂ１６０ａ、１６０ｂ及び１６０ｃの各々は、特定のセル（図示せず）と関連付けられ得、アップリンク及び／又はダウンリンクにおいて、無線リソース管理決定、ハンドオーバ決定、ユーザのスケジューリングなどを処理するように構成され得る。図１Ｃに示されるように、ｅＮｏｄｅ－Ｂ１６０ａ、１６０ｂ、及び１６０ｃは、Ｘ２インターフェースを介して互いに通信し得る。

【0034】

図１Ｃに示されるコアネットワーク１０７は、モビリティ管理ゲートウェイ（Mobility Management Gateway、ＭＭＥ）１６２、サービングゲートウェイ１６４、及びパケットデータネットワーク（Packet Data Network、ＰＤＮ）ゲートウェイ１６６を含み得る。前述の要素の各々は、コアネットワーク１０７の一部として図示されているが、これらの要素のいずれも、コアネットワークオペレータ以外のエンティティによって所有及び／又は操作され得ることが理解されよう。

【0035】

ＭＭＥ１６２は、Ｓ１インターフェースを介して、ＲＡＮ１０４内のｅＮｏｄｅ－Ｂ１６０ａ、１６０ｂ及び１６０ｃの各々に接続され得、制御ノードとして機能し得る。例えば、ＭＭＥ１６２は、ＷＴＲＵ１０２ａ、１０２ｂ、及び１０２ｃ、ベアラアクティブ化／非アクティブ化のユーザを認証し、ＷＴＲＵ１０２ａ、１０２ｂ、及び１０２ｃの初期アタッチ中に特定のサービングゲートウェイを選択するなどの役割を果たし得る。ＭＭＥ１６２はまた、ＲＡＮ１０４と、ＧＳＭ又はＷＣＤＭＡなどの他の無線技術を用いる他のＲＡＮ（図示せず）との間の交換のための制御プレーン機能を提供し得る。

【0036】

サービングゲートウェイ１６４は、Ｓ１インターフェースを介してＲＡＮ１０４におけるｅＮｏｄｅ－Ｂ１６０ａ、１６０ｂ、及び１６０ｃの各々に接続され得る。サービングゲートウェイ１６４は、一般に、ユーザデータパケットを、ＷＴＲＵ１０２ａ、１０２ｂ、及び１０２ｃに／ＷＴＲＵ１０２ａ、１０２ｂ、及び１０２ｃからルーティング及び転送し得る。サービングゲートウェイ１６４はまた、ｅＮｏｄｅ Ｂ間ハンドオーバ中にユーザプレーンをアンカリングすること、ダウンリンクデータがＷＴＲＵ１０２ａ、１０２ｂ、及び１０２ｃに利用可能であるときにページングをトリガすること、ＷＴＲＵ１０２ａ、１０２ｂ、及び１０２ｃのコンテキストを管理及び記憶することなど、他の機能を実行し得る。

【0037】

サービングゲートウェイ１６４はまた、ＰＤＮゲートウェイ１６６に接続され得、ＰＤＮゲートウェイ１６６は、インターネット１１０など、パケット交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、及び１０２ｃに提供して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとＩＰ対応デバイスとの間の通信を容易にし得る。

【0038】

コアネットワーク１０７は、他のネットワークとの通信を容易にし得る。例えば、コアネットワーク１０７は、ＰＳＴＮ１０８などの回線交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、及び１０２ｃに提供して、ＷＴＲＵ１０２ａ、１０２ｂ、及び１０２ｃと従来の固定電話回線通信デバイスとの間の通信を容易にし得る。例えば、コアネットワーク１０７は、コアネットワーク１０７とＰＳＴＮ１０８との間のインターフェースとして機能するＩＰゲートウェイ（例えば、ＩＰマルチメディアサブシステム（IP Multimedia Subsystem、ＩＭＳ）サーバ）を含み得るか、又はこれと通信し得る。加えて、コアネットワーク１０７は、ネットワーク１１２へのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、及び１０２ｃに提供し得、ネットワーク１１２は、他のサービスプロバイダによって所有及び／又は操作される他の有線及び／又は無線ネットワークを含み得る。

【0039】

図１Ｄは、例示的なＲＡＮ１０５及びコアネットワーク１０９のシステム図である。ＲＡＮ１０５は、ＮＲ無線技術を用いて、エアインターフェース１１７を介してＷＴＲＵ１０２ａ及び１０２ｂと通信し得る。ＲＡＮ１０５はまた、コアネットワーク１０９と通信し得る。非３ＧＰＰインターワーキング機能（Non-3GPP Interworking Function、Ｎ３ＩＷＦ）１９９は、非３ＧＰＰ無線技術を用いて、エアインターフェース１９８を介してＷＴＲＵ１０２ｃと通信し得る。Ｎ３ＩＷＦ１９９はまた、コアネットワーク１０９と通信し得る。

【0040】

ＲＡＮ１０５は、ｇＮｏｄｅ－Ｂ１８０ａ及び１８０ｂを含み得る。ＲＡＮ１０５は、任意の数のｇＮｏｄｅ－Ｂを含み得ることが理解されよう。ｇＮｏｄｅ－Ｂ１８０ａ及び１８０ｂは各々、エアインターフェース１１７を介してＷＴＲＵ１０２ａ及び１０２ｂと通信するための１つ以上のトランシーバを含み得る。統合アクセス及びバックホール接続が使用されるとき、同じエアインターフェースが、ＷＴＲＵとｇＮｏｄｅ－Ｂとの間で使用され得、このエアインターフェースは、１つ又は複数のｇＮＢを介したコアネットワーク１０９であってもよい。ｇＮｏｄｅ－Ｂ１８０ａ及び１８０ｂは、ＭＩＭＯ、ＭＵ－ＭＩＭＯ、及び／又はデジタルビームフォーミング技術を実装し得る。したがって、ｇＮｏｄｅ－Ｂ１８０ａは、例えば、複数のアンテナを使用して、ＷＴＲＵ１０２ａに無線信号を送信し、かつＷＴＲＵ１０２ａから無線信号を受信し得る。ＲＡＮ１０５は、ｅＮｏｄｅ－Ｂなどの他のタイプの基地局を用い得ることを理解されたい。また、ＲＡＮ１０５は、２つ以上のタイプの基地局を採用してもよいことも理解されたい。例えば、ＲＡＮは、ｅＮｏｄｅ－Ｂ及びｇＮｏｄｅ－Ｂを用い得る。

【0041】

Ｎ３ＩＷＦ１９９は、非３ＧＰＰアクセスポイント１８０ｃを含み得る。Ｎ３ＩＷＦ１９９は、任意の数の非３ＧＰＰアクセスポイントを含み得ることが理解されよう。非３ＧＰＰアクセスポイント１８０ｃは、エアインターフェース１９８を介してＷＴＲＵ１０２ｃと通信するための、１つ以上のトランシーバを含み得る。非３ＧＰＰアクセスポイント１８０ｃは、８０２．１１プロトコルを使用して、エアインターフェース１９８を介してＷＴＲＵ１０２ｃと通信し得る。

【0042】

ｅＮｏｄｅ－Ｂ１８０ａ及び１８０ｂの各々は、特定のセル（図示せず）と関連付けられ得、アップリンク及び／又はダウンリンクにおいて、無線リソース管理決定、ハンドオーバ決定、ユーザのスケジューリングなどを処理するように構成され得る。図１Ｄに示されるように、ｇＮｏｄｅ－Ｂ１８０ａ及び１８０ｂは、例えば、Ｘｎインターフェースを介して互いに通信し得る。

【0043】

図１Ｄに示されるコアネットワーク１０９は、５Ｇコアネットワーク（5G core network、５ＧＣ）であってもよい。コアネットワーク１０９は、無線アクセスネットワークによって相互接続されている顧客に多数の通信サービスを提供し得る。コアネットワーク１０９は、コアネットワークの機能性を実行するいくつかのエンティティを含む。本明細書で使用されるとき、「コアネットワークエンティティ」又は「ネットワーク機能」という用語は、コアネットワークの１つ以上の機能を実行する任意のエンティティを指す。そのようなコアネットワークエンティティは、無線及び／若しくはネットワーク通信のために構成された装置、又は図１Ｇに例示されるシステム９０などのコンピュータシステムのメモリに記憶された、及びこれらのプロセッサで実行されるコンピュータ実行可能命令（ソフトウェア）の形態で実装される論理エンティティであり得ることが理解される。

【0044】

図１Ｄの例では、５Ｇコアネットワーク１０９は、アクセス及びモビリティ管理機能（access and mobility management function、ＡＭＦ）１７２、セッション管理機能（Session Management Function、ＳＭＦ）１７４、ユーザプレーン機能（User Plane Function、ＵＰＦ）１７６ａ及び１７６ｂ、ユーザデータ管理機能（User Data Management Function、ＵＤＭ）１９７、認証サーバ機能（Authentication Server Function、ＡＵＳＦ）１９０、ネットワーク露出機能（Network Exposure Function、ＮＥＦ）１９６、ポリシー制御機能（Policy Control Function、ＰＣＦ）１８４、非３ＧＰＰインターワーキング機能（Non-3GPP Interworking Function、Ｎ３ＩＷＦ）１９９、ユーザデータリポジトリ（User Data Repository、ＵＤＲ）１７８を含み得る。前述の要素の各々は、５Ｇコアネットワーク１０９の一部として図示されているが、これらの要素のいずれも、コアネットワークオペレータ以外のエンティティによって所有及び／又は操作され得ることが理解されよう。また、５Ｇコアネットワークは、これらの要素の全てからなるとは限らず、追加の要素からなる場合があり、これらの要素の各々の複数の実例からなる場合があることも理解されるであろう。図１Ｄは、ネットワーク機能が互いに直接接続することを示しているが、これらが直径ルーティングエージェント又はメッセージバスなどのルーティングエージェントを介して通信し得ることを理解されたい。

【0045】

図１Ｄの例では、ネットワーク機能間の接続性は、一組のインターフェース又は基準点を介して達成される。ネットワーク機能は、他のネットワーク機能又はサービスによって呼び出されるか、又はコールされる一組のサービスとしてモデル化されるか、記載されるか、又は実装され得ることが理解されよう。ネットワーク機能サービスの呼び出しは、ネットワーク機能間の直接接続、メッセージバス上のメッセージングの交換、ソフトウェア機能の発呼などを介して達成され得る。

【0046】

ＡＭＦ１７２は、Ｎ２インターフェースを介してＲＡＮ１０５に接続され得、制御ノードとして機能し得る。例えば、ＡＭＦ１７２は、登録管理、接続管理、到達可能性管理、アクセス認証、アクセス認可の役割を果たし得る。ＡＭＦは、ユーザプレーントンネル構成情報を、Ｎ２インターフェースを介してＲＡＮ１０５に転送する役割を果たし得る。ＡＭＦ１７２は、ユーザプレーントンネル構成情報を、Ｎ１１インターフェースを介してＳＭＦから受信し得る。ＡＭＦ１７２は、一般に、ＮＡＳパケットを、Ｎ１インターフェースを介して、ＷＴＲＵ１０２ａ、１０２ｂ、及び１０２ｃに／からルーティングし、転送し得る。Ｎ１インターフェースは、図１Ｄに示されていない。

【0047】

ＳＭＦ１７４は、Ｎ１１インターフェースを介してＡＭＦ１７２に接続され得る。同様に、ＳＭＦは、Ｎ７インターフェースを介してＰＣＦ１８４に、かつＮ４インターフェースを介してＵＰＦ１７６ａ及び１７６ｂに接続され得る。ＳＭＦ１７４は、制御ノードとして機能し得る。例えば、ＳＭＦ１７４は、セッション管理、ＷＴＲＵ１０２ａ、１０２ｂ、及び１０２ｃのＩＰアドレス割り当て、ＵＰＦ１７６ａ及びＵＰＦ１７６ｂにおけるトラフィックステアリングルールの管理及び構成、並びにＡＭＦ１７２へのダウンリンクデータ通知の生成の役割を果たし得る。

【0048】

ＵＰＦ１７６ａ及びＵＰＦ１７６ｂは、ＷＴＲＵ１０２ａ、１０２ｂ、及び１０２ｃと他のデバイスとの間の通信を容易にするために、インターネット１１０などのパケットデータネットワーク（ＰＤＮ）へのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、及び１０２ｃに提供し得る。ＵＰＦ１７６ａ及びＵＰＦ１７６ｂはまた、他のタイプのパケットデータネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、及び１０２ｃに提供し得る。例えば、他のネットワーク１１２は、イーサネットネットワーク、又はデータのパケットを交換する任意のタイプのネットワークであってもよい。ＵＰＦ１７６ａ及びＵＰＦ１７６ｂは、Ｎ４インターフェースを介して、ＳＭＦ１７４からトラフィックステアリングルールを受信し得る。ＵＰＦ１７６ａ及びＵＰＦ１７６ｂは、パケットデータネットワークをＮ６インターフェースと接続することによって、又はＮ９インターフェースを介して互いに若しくは他のＵＰＦに接続することによって、パケットデータネットワークへのアクセスを提供し得る。パケットデータネットワークへのアクセスを提供することに加えて、ＵＰＦ１７６は、パケットルーティング及び転送、ポリシールールの施行、ユーザプレーントラフィックのサービス処理品質、ダウンリンクパケットバッファリングの役割を果たし得る。

【0049】

ＡＭＦ１７２はまた、Ｎ３ＩＷＦ１９９に、例えば、Ｎ２インターフェースを介して接続され得る。Ｎ３ＩＷＦは、例えば、３ＧＰＰによって定義されていない無線インターフェース技術を介して、ＷＴＲＵ１０２ｃと５Ｇコアネットワーク１７０との間の接続を容易にする。ＡＭＦは、ＲＡＮ１０５と相互作用するのと同じ又は同様の様式で、Ｎ３ＩＷＦ１９９と相互作用し得る。

【0050】

ＰＣＦ１８４は、Ｎ７インターフェースを介してＳＭＦ１７４に接続され、Ｎ１５インターフェースを介してＡＭＦ１７２に接続され、Ｎ５インターフェースを介してアプリケーション機能（Application Function、ＡＦ）１８８に接続され得る。Ｎ１５及びＮ５インターフェースは、図１Ｄには示されていない。ＰＣＦ１８４は、ＡＭＦ１７２及びＳＭＦ１７４などの制御プレーンノードにポリシールールを提供してもよく、制御プレーンノードがこれらのルールを施行することを可能にする。ＰＣＦ１８４は、ＡＭＦがＮ１インターフェースを介してＷＴＲＵ１０２ａ、１０２ｂ、及び１０２ｃにポリシーを送達することができるように、ＷＴＲＵ１０２ａ、１０２ｂ、及び１０２ｃのためにＡＭＦ１７２にポリシーを送信することができる。次いで、ポリシーは、ＷＴＲＵ１０２ａ、１０２ｂ、及び１０２ｃにおいて施行又は適用され得る。

【0051】

ＵＤＲ１７８は、認証証明書及び加入情報のためのリポジトリとして機能し得る。ＵＤＲは、ネットワーク機能に接続してもよく、その結果、ネットワーク機能は、リポジトリ内にあるデータに追加し、そのデータを読み取り、かつこのデータを修正することができる。例えば、ＵＤＲ１７８は、Ｎ３６インターフェースを介してＰＣＦ１８４に接続してもよい。同様に、ＵＤＲ１７８は、Ｎ３７インターフェースを介してＮＥＦ１９６に接続してもよく、ＵＤＲ１７８は、Ｎ３５インターフェースを介してＵＤＭ１９７に接続してもよい。

【0052】

ＵＤＭ１９７は、ＵＤＲ１７８と他のネットワーク機能との間のインターフェースとして機能し得る。ＵＤＭ１９７は、ＵＤＲ１７８のアクセスに対するネットワーク機能を認可し得る。例えば、ＵＤＭ１９７は、Ｎ８インターフェースを介してＡＭＦ１７２に接続してもよく、ＵＤＭ１９７は、Ｎ１０インターフェースを介してＳＭＦ１７４に接続してもよい。同様に、ＵＤＭ１９７は、Ｎ１３インターフェースを介してＡＵＳＦ１９０に接続してもよい。ＵＤＲ１７８とＵＤＭ１９７とは、緊密に統合されてもよい。

【0053】

ＡＵＳＦ１９０は、認証関連動作を実行し、Ｎ１３インターフェースを介してＵＤＭ１７８に、及びＮ１２インターフェースを介してＡＭＦ１７２に接続する。

【0054】

ＮＥＦ１９６は、５Ｇコアネットワーク１０９における能力及びサービスをアプリケーション機能（ＡＦ）１８８に露出する。露出は、Ｎ３３ ＡＰＩインターフェースで発生し得る。ＮＥＦは、Ｎ３３インターフェースを介してＡＦ１８８に接続してもよく、５Ｇコアネットワーク１０９の能力及びサービスを露出させるために、他のネットワーク機能に接続してもよい。

【0055】

アプリケーション機能１８８は、５Ｇコアネットワーク１０９内のネットワーク機能と相互作用してもよい。アプリケーション機能１８８とネットワーク機能との間の相互作用は、直接インターフェースを介してもよいし、又はＮＥＦ１９６を介して発生してもよい。アプリケーション機能１８８は、５Ｇコアネットワーク１０９の一部と見なされてもよいし、又は５Ｇコアネットワーク１０９の外部にあり、モバイルネットワークオペレータと取引関係を有する企業によって展開されてもよい。

【0056】

ネットワークスライシングは、モバイルネットワークオペレータが使用して、オペレータのエアインターフェースの後ろの、１つ以上の「仮想」コアネットワークをサポートすることができるメカニズムである。これは、コアネットワークを１つ以上の仮想ネットワークに「スライス」して、単一のＲＡＮ全体で実行される、異なるＲＡＮ又は異なるサービスタイプをサポートすることを含む。ネットワークスライシングにより、オペレータは、例えば、機能性、性能、及び分離の領域において、多様な要件を必要とする異なる市場シナリオのための最適化された解決策を提供するようにカスタマイズされたネットワークを作成することを可能にする。

【0057】

３ＧＰＰは、ネットワークスライシングをサポートするために５Ｇコアネットワークを設計している。ネットワークスライシングは、ネットワークオペレータが、非常に多様でときには極端な要件を必要とする５Ｇの使用事例の多様なセット（例えば、大規模なＩｏＴ、重要な通信、Ｖ２Ｘ、及び強化されたモバイルブロードバンド）をサポートするために使用することができる良好なツールである。ネットワークスライシング技術を使用することなく、ネットワークアーキテクチャは、各使用事例が自らの特定の組の性能、スケーラビリティ、及び可用性要件を有するときに必要な、より広範囲の使用事例を効率的にサポートするのに十分な柔軟性及び拡張性がない可能性が高い。更に、新しいネットワークサービスの導入をより効率的にするべきである。

【0058】

再び図１Ｄを参照すると、ネットワークスライシングシナリオでは、ＷＴＲＵ１０２ａ、１０２ｂ、又は１０２ｃは、Ｎ１インターフェースを介してＡＭＦ１７２に接続してもよい。ＡＭＦは、１つ以上のスライスの論理的に一部であり得る。ＡＭＦは、ＷＴＲＵ１０２ａ、１０２ｂ、又は１０２ｃの、１つ以上のＵＰＦ１７６ａ及び１７６ｂ、ＳＭＦ１７４、並びに他のネットワーク機能との接続又は通信を調整してもよい。ＵＰＦ１７６ａ及び１７６ｂ、ＳＭＦ１７４、並びに他のネットワーク機能の各々は、同じスライス又は異なるスライスの一部であってもよい。それらが異なるスライスの一部であるとき、それらは、異なるコンピューティングリソース、セキュリティ証明書などを利用し得るという意味で、互いに分離され得る。

【0059】

コアネットワーク１０９は、他のネットワークとの通信を容易にし得る。例えば、コアネットワーク１０９は、５Ｇコアネットワーク１０９とＰＳＴＮ１０８との間のインターフェースとして機能するＩＰマルチメディアサブシステム（ＩＭＳ）サーバなどのＩＰゲートウェイを含み得るか、又はこれと通信し得る。例えば、コアネットワーク１０９は、ショートメッセージサービスを介して通信を容易にするショートメッセージサービス（short message service、ＳＭＳ）サービスセンターを含むか、又はこれと通信し得る。例えば、５Ｇコアネットワーク１０９は、ＷＴＲＵ１０２ａ、１０２ｂ、及び１０２ｃとサーバ又はアプリケーション機能１８８との間の非ＩＰデータパケットの交換を容易にし得る。加えて、コアネットワーク１７０は、ネットワーク１１２へのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、及び１０２ｃに提供し得、ネットワーク１１２は、他のサービスプロバイダによって所有及び／又は操作される他の有線及び／又は無線ネットワークを含み得る。

【0060】

本明細書に記載され、図１Ａ、図１Ｃ、図１Ｄ、及び図１Ｅに例示されるコアネットワークエンティティは、特定の既存の３ＧＰＰ仕様においてそれらのエンティティに与えられる名前によって識別されるが、将来のそれらのエンティティ及び機能は、他の名前によって識別され得、将来の３ＧＰＰ ＮＲ仕様を含む、３ＧＰＰによって公開された将来の仕様において、特定のエンティティ又は機能が組み合わされ得ることが理解される。したがって、図１Ａ、図１Ｂ、図１Ｃ、図１Ｄ、及び図１Ｅに記載及び例示される特定のネットワークエンティティ及び機能は、ほんの一例として提供されており、本明細書に開示及び特許請求される主題は、現在定義されているか又は将来定義されるかにかかわらず、任意の同様の通信システムで具体化又は実装され得ることが理解される。

【0061】

図１Ｅは、本明細書に記載のシステム、方法、装置が使用され得る例示的な通信システム１１１を例示する。通信システム１１１は、無線送／受信ユニット（ＷＴＲＵ）Ａ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆ、基地局ｇＮＢ１２１、Ｖ２Ｘサーバ１２４、及び路側ユニット（ＲＳＵ）１２３ａ及び１２３ｂを含み得る。実際には、本明細書に提示される概念は、任意の数のＷＴＲＵ、基地局ｇＮＢ、Ｖ２Ｘネットワーク、及び／又は他のネットワーク要素に適用され得る。１つ又は複数の、又は全てのＷＴＲＵＡ、Ｂ、Ｃ、Ｄ、Ｅ、及びＦは、アクセスネットワークのカバレッジ１３１の範囲外であってもよい。ＷＴＲＵ Ａ、Ｂ、及びＣはＶ２Ｘグループを形成し、このときＷＴＲＵ Ａはグループリードであり、ＷＴＲＵ Ｂ及びＣはグループメンバーである。

【0062】

ＷＴＲＵ Ａ、Ｂ、Ｃ、Ｄ、Ｅ、及びＦは、それらがアクセスネットワークのカバレッジ１３１内にある場合、ｇＮＢ１２１を介してＵｕインターフェース１２９を介して互いに通信し得る。図１Ｅの例では、ＷＴＲＵ Ｂ及びＦは、アクセスネットワークのカバレッジ１３１内に示されている。ＷＴＲＵ Ａ、Ｂ、Ｃ、Ｄ、Ｅ、及びＦは、それらがアクセスネットワークのカバレッジ１３１の下に、又はアクセスネットワークのカバレッジ１３１の外側にあるかどうかにかかわらず、インターフェース１２５ａ、１２５ｂ、又は１２８などのサイドリンクインターフェース（例えば、ＰＣ５又はＮＲ ＰＣ５）を介して互いに直接通信してもよい。例えば、図１Ｅの例では、アクセスネットワークのカバレッジ１３１の外側にあるＷＲＴＵ Ｄは、カバレッジ１３１内にあるＷＴＲＵ Ｆと通信する。

【0063】

ＷＴＲＵＡ、Ｂ、Ｃ、Ｄ、Ｅ、及びＦは、車両対ネットワーク通信（Ｖ２Ｎ）１３３又はサイドリンクインターフェース１２５ｂを介してＲＳＵ１２３ａ又は１２３ｂと通信し得る。ＷＴＲＵ Ａ、Ｂ、Ｃ、Ｄ、Ｅ、及びＦは、車両対インフラストラクチャ通信（Ｖ２Ｉ）インターフェース１２７を介してＶ２Ｘサーバ１２４に通信し得る。ＷＴＲＵ Ａ、Ｂ、Ｃ、Ｄ、Ｅ、及びＦは、車両対人間通信（Ｖ２Ｐ）インターフェース１２８を介して別のＵＥに通信し得る。

【0064】

図１Ｆは、図１Ａ、図１Ｂ、図１Ｃ、図１Ｄ、又は図１ＥのＷＴＲＵ１０２などの、本明細書に記載のシステム、方法、及び装置による無線通信及び動作のために構成され得る、例示的な装置又はデバイスＷＴＲＵ１０２のブロック図である。図１Ｆに示されるように、例示的なＷＴＲＵ１０２は、プロセッサ１１８、トランシーバ１２０、送／受信要素１２２、スピーカ／マイクロフォン１２４、キーパッド１２６、ディスプレイ／タッチパッド／インジケータ１２８、非リムーバブルメモリ１３０、リムーバブルメモリ１３２、電源１３４、全地球測位システム（global positioning system、ＧＰＳ）チップセット１３６、及び他の周辺機器１３８を含み得る。ＷＴＲＵ１０２は、前述の要素の任意の二次組み合わせを含み得ることが理解されよう。また、基地局１１４ａ及び１１４ｂ、並びに／又は基地局１１４ａ及び１１４ｂは、限定されないが、トランシーバ局（ＢＴＳ）、ノードＢ、サイトコントローラ、アクセスポイント（ＡＰ）、ホームノードＢ、進化型ホームノード－Ｂ（evolved home node-B、ｅＮｏｄｅＢ）、ホーム進化型ノード－Ｂ（home evolved node-B、ＨｅＮＢ）、ホーム進化型ノード－Ｂゲートウェイ、次世代ノードＢ（ｇＮｏｄｅ－Ｂ）、及びプロキシノードなどを表してもよく、数ある中でも、図１Ｆに図示され、本明細書に記載される要素のうちのいくつか又は全てを含んでもよい。

【0065】

プロセッサ１１８は、汎用プロセッサ、専用プロセッサ、従来のプロセッサ、デジタル信号プロセッサ（digital signal processor、ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアに関連付けられた１つ以上のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（Application Specific Integrated Circuit、ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（Field Programmable Gate Array、ＦＰＧＡ）回路、任意の他のタイプの集積回路（integrated circuit、ＩＣ）、状態機械などであり得る。プロセッサ１１８は、信号コーディング、データ処理、電力制御、入力／出力処理、及び／又はＷＴＲＵ１０２が無線環境で動作することを可能にする任意の他の機能性を実行し得る。プロセッサ１１８は、送／受信要素１２２に結合され得るトランシーバ１２０に結合され得る。図１Ｆは、プロセッサ１１８及びトランシーバ１２０を別個の構成要素として図示しているが、プロセッサ１１８及びトランシーバ１２０は、電子パッケージ又はチップ内に一緒に統合され得ることが理解されよう。

【0066】

ＵＥの送／受信要素１２２は、エアインターフェース１１５／１１６／１１７を介して、基地局（例えば、図１Ａの基地局１１４ａ）に信号を送信するか、若しくは基地局（例えば、図１Ａの基地局１１４ａ）から信号を受信するか、又はエアインターフェース１１５ｄ／１１６ｄ／１１７ｄを介して、別のＵＥに信号を送信するか、若しくは別のＵＥから信号を受信するように構成され得る。例えば、送／受信要素１２２は、ＲＦ信号を送信及び／又は受信するように構成されたアンテナであり得る。送／受信要素１２２は、例えば、ＩＲ、ＵＶ、又は可視光信号を送信及び／又は受信するように構成されたエミッタ／検出器であり得る。送／受信要素１２２は、ＲＦ信号及び光信号の両方を送信及び受信するように構成され得る。送／受信要素１２２は、無線又は有線信号の任意の組み合わせを送信及び／又は受信するように構成され得ることが理解されよう。

【0067】

加えて、送／受信要素１２２は、単一の要素として図１Ｆに図示されているが、ＷＴＲＵ１０２は、任意の数の送／受信要素１２２を含み得る。より具体的には、ＷＴＲＵ１０２は、ＭＩＭＯ技術を用い得る。したがって、ＷＴＲＵ１０２は、エアインターフェース１１５／１１６／１１７を介して無線信号を送信及び受信するための２つ以上の送／受信要素１２２（例えば、多重アンテナ）を含み得る。

【0068】

トランシーバ１２０は、送／受信要素１２２によって送信される信号を変調し、送／受信要素１２２によって受信される信号を復調するように構成され得る。上記のように、ＷＴＲＵ１０２は、マルチモード能力を有し得る。したがって、トランシーバ１２０は、ＷＴＲＵ１０２が、複数のＲＡＴ、例えば、ＮＲ及びＩＥＥＥ８０２．１１若しくはＮＲ及びＥ－ＵＴＲＡを介して通信すること、又は異なるＲＲＨ、ＴＲＰ、ＲＳＵ、又はノードへの複数のビームを介して同じＲＡＴと通信することを可能にするための複数のトランシーバを含み得る。

【0069】

ＷＴＲＵ１０２のプロセッサ１１８は、スピーカ／マイクロフォン１２４、キーパッド１２６、及び／又はディスプレイ／タッチパッド／インジケータ１２８（例えば、液晶ディスプレイ（liquid crystal display、ＬＣＤ）ディスプレイユニット若しくは有機発光ダイオード（organic light-emitting diode、ＯＬＥＤ）ディスプレイユニットに結合され得、それらからユーザ入力データを受信し得る。プロセッサ１１８はまた、ユーザデータをスピーカ／マイクロフォン１２４、キーパッド１２６、及び／又はディスプレイ／タッチパッド／インジケータ１２８に出力し得る。更に、プロセッサ１１８は、非リムーバブルメモリ１３０及び／又はリムーバブルメモリ１３２などの任意のタイプの好適なメモリから情報にアクセスし、当該メモリにデータを記憶し得る。非リムーバブルメモリ１３０は、ランダムアクセスメモリ（random-access memory、ＲＡＭ）、読み取り専用メモリ（read-only memory、ＲＯＭ）、ハードディスク又は任意の他のタイプのメモリ記憶デバイスを含み得る。リムーバブルメモリ１３２は、加入者識別モジュール（subscriber identity module、ＳＩＭ）カード、メモリスティック、セキュアデジタル（secure digital、ＳＤ）メモリカードなどを含み得る。プロセッサ１１８は、クラウド又はエッジコンピューティングプラットフォーム又はホームコンピュータ（図示せず）でホストされるサーバ上など、ＷＴＲＵ１０２上に物理的に位置していないメモリから情報にアクセスし、そのメモリにデータを記憶し得る。

【0070】

プロセッサ１１８は、電源１３４から電力を受信し得、ＷＴＲＵ１０２における他のコンポーネントに電力を分配し、かつ／又は制御するように構成され得る。電源１３４は、ＷＴＲＵ１０２に電力を供給するための任意の好適なデバイスであり得る。例えば、電源１３４は、１つ以上の乾式セル電池、太陽電池、燃料電池などを含み得る。

【0071】

プロセッサ１１８はまた、ＧＰＳチップセット１３６に結合され得、これは、ＷＴＲＵ１０２の現在の場所に関する場所情報（例えば、経度及び緯度）を提供するように構成され得る。ＧＰＳチップセット１３６からの情報に加えて又はその代わりに、ＷＴＲＵ１０２は、基地局（例えば、基地局１１４ａ、１１４ｂ）からエアインターフェース１１５／１１６／１１７を介して場所情報を受信し、かつ／又は２つ以上の近くの基地局から受信されている信号のタイミングに基づいて、その場所を決定し得る。ＷＴＲＵ１０２は、任意の好適な位置決定方法によって場所情報を取得し得ることが理解されよう。

【0072】

プロセッサ１１８は、他の周辺機器１３８に更に結合され得、他の周辺機器１３８は、追加の特徴、機能性、及び／又は有線若しくは無線接続性を提供する、１つ以上のソフトウェア及び／又はハードウェアモジュールを含み得る。例えば、周辺機器１３８は、加速度計、生体認証（例えば、指紋認証）センサ、電子コンパス、衛星トランシーバ、デジタルカメラ（写真又はビデオ用）、ユニバーサルシリアルバス（universal serial bus、ＵＳＢ）ポート、又は他の相互接続インターフェース、振動デバイス、テレビトランシーバ、ハンズフリーヘッドセット、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール、周波数変調（frequency modulated、ＦＭ）無線ユニット、デジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュールなどの様々なセンサを含み得る。

【0073】

ＷＴＲＵ１０２は、センサ、家庭用電気機械器具、スマートウォッチ若しくはスマートクロージングなどのウェアラブルデバイス、医療若しくはｅヘルスデバイス、ロボット、産業機器、ドローン、自動車、トラック、列車などの車両、又は飛行機などの他の装置又はデバイスに含まれ得る。ＷＴＲＵ１０２は、周辺機器１３８のうちの１つを含み得る相互接続インターフェースなどの１つ以上の相互接続インターフェースを介して、そのような装置又はデバイスの他の構成要素、モジュール、又はシステムに接続することができる。

【0074】

図１Ｇは、ＲＡＮ１０３／１０４／１０５、コアネットワーク１０６／１０７／１０９、ＰＳＴＮ１０８、インターネット１１０、他のネットワーク１１２、又はネットワークサービス１１３における、特定のノード又は機能エンティティなどの、図１Ａ、図１Ｃ、図１Ｄ、及び図１Ｅに例示される通信ネットワークのうちの１つ以上の装置が具体化され得る、例示的なコンピューティングシステム９０のブロック図である。コンピューティングシステム９０は、コンピュータ又はサーバを含み得、主にコンピュータ可読命令によって制御され得、これは、ソフトウェアの形態であり得るか、又はそのようなソフトウェアが格納又はアクセスされるあらゆる手段であり得る。そのようなコンピュータ可読命令は、プロセッサ９１内で実行されて、コンピューティングシステム９０を作業させることができる。プロセッサ９１は、汎用プロセッサ、専用プロセッサ、従来のプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアに関連付けられた１つ以上のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、任意の他のタイプの集積回路（ＩＣ）、状態機械などであり得る。プロセッサ９１は、信号コーディング、データ処理、電力制御、入力／出力処理、及び／又はコンピューティングシステム９０が通信ネットワークで動作することを可能にする任意の他の機能性を実行し得る。コプロセッサ８１は、メインプロセッサ９１とは異なる任意選択のプロセッサであり、追加の機能を実行し得るか、又はプロセッサ９１を支援し得る。プロセッサ９１及び／又はコプロセッサ８１は、本明細書に開示される方法及び装置に関連するデータを受信、生成、及び処理することができる。

【0075】

動作中、プロセッサ９１は、命令をフェッチ、復号、及び実行し、コンピューティングシステムのメインデータ転送経路、システムバス８０を介して他のリソースに情報を伝送する。そのようなシステムバスは、コンピューティングシステム９０内の構成要素を接続し、データ交換のための媒体を定義する。システムバス８０は、典型的には、データを送信するためのデータライン、アドレスを送信するためのアドレスライン、及び割り込みを送信し、システムバスを動作させるための制御ラインを含む。そのようなシステムバス８０の例は、ＰＣＩ（周辺構成要素相互接続）バスである。

【0076】

システムバス８０に結合されたメモリは、ランダムアクセスメモリ（ＲＡＭ）８２及び読み取り専用メモリ（ＲＯＭ）９３を含む。そのようなメモリは、情報が記憶及び取り出されることを可能にする回路を含む。ＲＯＭ９３は一般に、容易に修正することができない記憶されたデータを含む。ＲＡＭ８２に記憶されたデータは、プロセッサ９１又は他のハードウェアデバイスによって読み取られるか、又は変更され得る。ＲＡＭ８２及び／又はＲＯＭ９３へのアクセスは、メモリコントローラ９２によって制御され得る。メモリコントローラ９２は、命令が実行されると、仮想アドレスを物理アドレスに変換するアドレス変換機能を提供することができる。メモリコントローラ９２はまた、システム内のプロセスを分離し、システムプロセスをユーザプロセスから分離するメモリ保護機能を提供し得る。したがって、第１のモードで実行されるプログラムは、それ自体のプロセス仮想アドレス空間によってマッピングされたメモリのみにアクセスすることができ、プロセス間のメモリ共有が設定されていない限り、別のプロセスの仮想アドレス空間内のメモリにアクセスすることができない。

【0077】

加えて、コンピューティングシステム９０は、プリンタ９４、キーボード８４、マウス９５、及びディスクドライブ８５などの、プロセッサ９１から周辺機器に命令を通信する役割を果たす周辺機器コントローラ８３を含み得る。

【0078】

ディスプレイコントローラ９６によって制御されるディスプレイ８６は、コンピューティングシステム９０によって生成された視覚的出力を表示するために使用される。そのような視覚的出力は、テキスト、グラフィック、アニメーショングラフィック、及びビデオを含み得る。視覚的出力は、グラフィカルユーザインターフェース（graphical user interface、ＧＵＩ）の形態で提供され得る。ディスプレイ８６は、ＣＲＴベースのビデオディスプレイ、ＬＣＤベースのフラットパネルディスプレイ、ガスプラズマベースのフラットパネルディスプレイ、又はタッチパネルで実装され得る。ディスプレイコントローラ９６は、ディスプレイ８６に送信されるビデオ信号を生成するために必要な電子部品を含む。

【0079】

更に、コンピューティングシステム９０は、コンピューティングシステム９０を、図１Ａ、図１Ｂ、図１Ｃ、図１Ｄ、及び図１ＥのＲＡＮ１０３／１０４／１０５、コアネットワーク１０６／１０７／１０９、ＰＳＴＮ１０８、インターネット１１０、ＷＴＲＵ１０２、又は他のネットワーク１１２などの外部通信ネットワーク若しくはデバイスに接続するために使用され得る、例えば、無線若しくは有線ネットワークアダプタ９７などの通信回路を含み得、コンピューティングシステム９０が、それらのネットワークの他のノード又は機能的エンティティと通信することを可能にする。通信回路は、単独で、又はプロセッサ９１と組み合わせて、本明細書に記載の特定の装置、ノード、又は機能エンティティの伝送及び受信ステップを実行するために使用され得る。

【0080】

本明細書に記載の装置、システム、方法、及びプロセスのいずれか又は全ては、コンピュータ可読記憶媒体上に記憶されたコンピュータ実行可能命令（例えば、プログラムコード）の形態で具体化され得、その命令は、プロセッサ１１８又は９１などのプロセッサによって実行されるときに、プロセッサに、本明細書に記載のシステム、方法、及びプロセスを実行及び／又は実装させることが理解される。具体的には、本明細書に記載のステップ、動作、又は機能のいずれかは、無線及び／又は有線ネットワーク通信のために構成された装置又はコンピューティングシステムのプロセッサ上で実行される、そのようなコンピュータ実行可能命令の形態で実装され得る。コンピュータ可読記憶媒体は、任意の非一時的な（例えば、有形又は物理的）方法又は技術で実装される、情報を記憶するための、揮発性及び不揮発性、リムーバブル及び非リムーバブルな媒体を含むが、そのようなコンピュータ可読記憶媒体は、信号を含まない。コンピュータ可読記憶媒体には、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、又は他のメモリ技術、ＣＤ－ＲＯＭ、デジタル多用途ディスク（digital versatile disks、ＤＶＤ）又は他の光ディスク記憶、磁気カセット、磁気テープ、磁気ディスク記憶装置、若しくは他の磁気記憶デバイス、又は所望の情報を記憶するために使用され得、コンピューティングシステムによってアクセスされ得る任意の他の有形若しくは物理媒体が含まれる。

【0081】

以下は、以下の説明に出現し得る頭字語のリストである。別段の指定がない限り、本明細書で使用される頭字語は、下記に列挙される対応する用語を指す。

【0082】

５ＧＣ ５Ｇコアネットワーク
ＡＦ アプリケーション機能
ＡＭＦ アクセス管理機能
ＡＰＩ アプリケーションプログラミングインターフェース
ＡＳ アプリケーションサーバ
ＡＣ アプリケーションクライアント
ＢＳ 結合機能
ＣＮ コアネットワーク
ＤＮＮ データネットワーク名
ＤＮＳ ドメイン名サーバ
ＥＡＳ エッジアプリケーションサーバ
ＥＤＮ エッジデータネットワーク
ＥＣＳＰ エッジコンピューティングサービスプロバイダ
ＥＤＮＣＳ エッジデータネットワーク構成サーバ
ＥＥＳ エッジイネーブラサーバ
ＥＥＣ エッジイネーブラクライアント
ＥＨＥ エッジホスティング環境
ＥＭＲＰ エッジ監視ルーティングポリシー
ＦＱＤＮ 完全修飾ドメイン名
ＧＭＬＣ ゲートウェイ移動体位置センター
ＧＵＩ グラフィカルユーザインターフェース
ＬＡＤＮ ローカルエリアデータネットワーク
ＮＥＦ ネットワーク露出機能
ＮＦ ネットワーク機能
ＰＤＵ プロトコルデータユニット
ＳＭＦ セッション管理機能
ＵＤＭ 一元データ管理
ＵＥ ユーザ機器
ＵＰ ユーザプレーン
アプリケーションサーバ－アプリケーションクライアントにサービスを提供するネットワークノード上に展開されたエンティティ。

【0083】

アプリケーションクライアント－アプリケーションサーバのサービスにアクセスするエンティティ。

【0084】

エッジアプリケーションサーバ－エッジノード又はエッジホスティング環境にホストされているアプリケーションサービスを提供するサーバ。

【0085】

エッジノード－エッジネットワーク内に展開され、エッジベースのアプリケーション及びサービスをホストする仮想又は物理エンティティ。

【0086】

エッジデータネットワーク－エッジホスティング環境の配信展開をサポートするローカルデータネットワーク。本開示では、エッジデータネットワークという用語は、エッジホスティング環境という用語と互換的に使用され得る。例えば、エッジデータネットワーク内にある本明細書に記載のサーバは、対応するエッジホスティング環境で実行される。

【0087】

エッジイネーブラサーバ－エッジネットワーク中心サービスをエッジイネーブラクライアント及びエッジアプリケーションサーバに提供するエッジネットワーク内に展開されるエンティティ。いくつかの３ＧＰＰ仕様では、エッジイネーブラサーバは、エッジアプリケーションサーバと機能的に区別されず、「エッジアプリケーションサーバ」という用語は、両方に適用され得る。

【0088】

エッジイネーブラクライアント－エッジネットワーク中心サービスを、デバイスにホストされているアプリケーションクライアントに提供するデバイス上に展開される。

【0089】

エッジデータネットワーク構成サーバ－エッジデータネットワークによって提供されたサービスを可能にするために、エッジイネーブラクライアント及びエッジイネーブラサーバを構成するネットワーク内のエンティティ。また、エッジデータネットワーク構成サーバは、エッジ構成サーバと呼ばれることもある。

【0090】

エッジホスティング環境－エッジアプリケーションサーバの実行に必要なサポートを提供する環境。

【0091】

エッジアプリケーションの展開。

【0092】

アプリケーションサーバ（Application Server、ＡＳ）を、クラウドではなく、３ＧＰＰシステムのエッジに展開する利点は、アクセスする待ち時間の低減、及びこれらのＡＳによって提供されるサービスにアクセスするアプリケーションクライアント（Application Client、ＡＣ）の信頼性の増加を含み得る。加えて、ネットワークオペレータはまた、この展開モデルが負荷を分散し、（例えば、ＡＣとＡＳとの間の局所的な通信を可能にすることによって）ネットワークの混雑レベルを低減することができ得るため、ネットワークのエッジにおけるＡＳの展開から利益を得ることができる。

【0093】

例えば、図２は、自律型車両の使用事例を例示している。車両はＵＥをホストし、ＵＥにホストされているのは、車両の自律走行制御システムによって使用されるＶ２Ｘ ＡＣである。Ｖ２Ｘ ＡＣは、３ＧＰＰシステム（例えば、隊列走行サービス、協調走行サービス、又は衝突回避サービス）に展開されたＶ２Ｘサービスと通信する。Ｖ２Ｘサービスは、エッジノード（例えば、路側ユニット又はセルタワー）上に、並びにクラウドに展開されたＶ２Ｘ ＡＳの組み合わせとして、システム全体に配信される様式で展開され得る。

【0094】

増強性能（例えば、アクセスする待ち時間が低減され、信頼性がより高い）のために、Ｖ２Ｘ ＡＣによるＶ２Ｘサービスにアクセスするための好ましい方法は、クラウドを介してＶ２Ｘ ＡＳにアクセスするのではなく、典型的には、車両に近接しているシステム内のエッジネットワークに展開されるＶ２Ｘ ＡＳを介してもよい。エッジにおいてＶ２Ｘ ＡＳにアクセスするときに、車両内のＵＥにホストされているＶ２Ｘ ＡＣは、他の車両、並びに車道及び交通状況に関して、よりタイムリーでより信頼性の高い情報を利用してもよい。その結果として、車両は、より高速で、他の車両に対してより近い距離に移動することができる。車両はまた、安全性を犠牲にすることなく、より頻繁に効果的にレーンを変更することができ得る。対照的に、クラウドのＶ２Ｘ ＡＳにアクセスするとき、車両は、タイムリーな情報の利用可能性の減少により、より保守的な動作モードに戻らなければならない場合がある。これは、典型的には、車両の速度の低下、車両と他の車両との間の距離の増加、及び／又は最適なレーン変更に満たないという結果になり得る。

【0095】

車両が車道を移動するとき、車両に最も近接している異なるエッジノードにホストされているＶ２Ｘ Ａｓ間のＶ２Ｘ ＡＣのハンドオーバが調整されなければならない場合がある。同様に、エッジノードにホストされているＶ２Ｘ ＡＳとクラウドにホストされているＶ２Ｘ ＡＳとの間のＶ２Ｘ ＡＣのハンドオーバはまた、エッジネットワークのカバレッジが車両の行程中にフェードイン及びフェードアウトする場合についても調整されなければならない場合がある。そのようなシナリオでは、シームレスの（待ち時間が少なく信頼性のある）、エッジノード並びにクラウドの両方にホストされているＡＳ間のＶ２Ｘ ＡＣハンドオーバは、このタイプのＶ２Ｘの使用事例並びにＶ２Ｘと同様の要件を有する他のタイプの使用事例の成功した展開に重要不可欠であり得る。

【0096】

エッジアプリケーションを可能にするための３ＧＰＰアーキテクチャ。
エラー！参照元が見つからない。これは、エッジアプリケーションを可能にするための３ＧＰＰ定義のアーキテクチャを示す。エッジアプリケーションを可能にするためのフレームワークは、ＵＥにホストされているエッジイネーブラクライアント及びアプリケーションクライアント、及びエッジデータネットワークにホストされたエッジイネーブラサーバを含み得る。エッジデータネットワーク構成サーバを使用して、エッジイネーブラクライアント及びエッジイネーブラサーバを構成し得る。エッジイネーブラクライアント及びサーバは、アプリケーションクライアント及びサーバにエッジ中心能力をそれぞれ提供し得る。エッジイネーブラサーバ及びエッジデータネットワーク構成サーバはまた、３ＧＰＰネットワークと相互作用し得る。

【0097】

ネットワーク露出のための３ＧＰＰアーキテクチャ。
図７は、下記に説明するように、ネットワーク機能を備えたコアネットワークアーキテクチャのシステム図である。５ＧＳにおける現在のネットワーク露出メカニズムは、ＮＥＦ及び他の制御プレーンＮＦ、例えば、ＡＭＦ、ＳＭＦ、又はＰＣＦに基づいて設計され得る。ＮＥＦ（３ＧＰＰ ＴＳ ２３．５０１、５Ｇシステムのシステムアーキテクチャ、ステージ２、Ｖ１６．３．０（２０１９－１２）に記載されているように）は、以下の機能性を含み得る。
・第三者、アプリケーション機能などのための、能力及びイベントの安全な露出。
・ＮＥＦは、標準化されたインターフェース（Ｎｕｄｒ）を使用して、統一データリポジトリ（Unified Data Repository、ＵＤＲ）に、情報を構造化されたデータとして記憶する／これを取り出す。
・外部アプリケーションから３ＧＰＰネットワークへの情報の安全なプロビジョニング。これは、３ＧＰＰネットワークに情報、例えば、予想されるＵＥ挙動、５ＧＬＡＮグループ情報、又はサービス固有情報を安全に提供するためのアプリケーション機能のための手段を提供する。その場合、ＮＥＦは、アプリケーション機能のスロットルを認証、認可、及び支援してもよい。
・内部外部情報の変換。変換は、ＡＦと交換された情報と内部ネットワーク機能と交換された情報との間で行われる。例えば、変換は、ＡＦサービス識別子と、ＤＮＮ、又はＳ－ＮＳＳＡＩなどの内部５Ｇコア情報との間で行われ得る。
・具体的には、ＮＥＦは、ネットワークポリシーに従って、ネットワークのマスキング及びユーザの保護必要情報を外部ＡＦに処理する。
・ネットワーク露出機能は、（他のネットワーク機能の露出能力に基づいて）他のネットワーク機能から情報を受信する。ＮＥＦは、標準化されたインターフェースを使用して、統一データリポジトリ（ＵＤＲ）に、受信された情報を構造化されたデータとして記憶する。記憶された情報は、ＮＥＦによって、他のネットワーク機能及びアプリケーション機能にアクセス及び「再露出」され、分析などの他の目的のために使用されることができる。
・ＮＥＦは、ＵＤＲ内のＰＦＤを記憶及び取り出し、ＰＦＤを、ＳＭＦ（プルモード）の要求又はＮＥＦ（プッシュモード）からのＰＦＤ管理の要求により、ＳＭＦに提供することによって、パケットフロー記述機能をサポートし得る。
・ＮＥＦはまた、５ＧＬＡＮグループ管理機能をサポートし得る。
・分析の露出。ＮＷＤＡＦ分析は、ＴＳ ２３．２８８で指定されたように、外部当事者のＮＥＦによって安全に露出され得る。
・ＮＷＤＡＦによる、外部当事者からのデータの取り出し。外部当事者によって提供されるデータは、分析生成目的のためにＮＥＦを介してＮＷＤＡＦによって収集され得る。ＮＥＦは、ＴＳ ２３．２８８で指定されたように、ＮＷＤＡＦとＡＦとの間の要求及び通知を処理し、転送する。

【0098】

特定のＮＥＦの実例は、上述の機能性のうちの１つ以上をサポートし得、その結果、個々のＮＥＦは、能力露出のために指定されたＡＰＩのサブセットをサポートし得る。ＮＥＦは、ＮＥＦと同じＰＬＭＮに位置され得るＵＤＲにアクセスすることができる。特定のＵＥに関連するサービスの外部露出の場合、ＮＥＦは、ＨＰＬＭＮに存在し得る。オペレータの合意に応じて、ＨＰＬＭＮ内のＮＥＦは、ＶＰＬＭＮ内のＮＦを有するインターフェースを有し得る。

【0099】

問題の記述。
ＳＡ６は、エッジコンピューティングアプリケーション層アーキテクチャを設計している。このアーキテクチャでは、ＵＥ上のアプリケーションクライアントは、ＵＥ上のエッジイネーブラクライアントのサービスにアクセスし得る。ＵＥ上のアプリケーションクライアントはまた、エッジアプリケーションサーバと通信し得る。エッジアプリケーションサーバは、エッジデータネットワークに存在し得る。エッジのサーバは、機能性及びネットワークによって露出された情報にアクセスするために、５ＧＳと相互作用し得る。現在、露出は、再配置を回避するために一元的に展開される可能性が高い、制御プレーンＮＦ、例えば、ＮＥＦ又はＰＣＦを介して提供され得る。ＵＥ上のアプリケーションクライアントがＳＡ６定義の手順及びＡＰＩを使用してエッジイネーブラクライアントにアクセスする場合、「エッジを認識している」と言われる。

【0100】

ＳＡ６アーキテクチャでは、エッジイネーブラクライアントは、Ｎ６－ＬＡＮでホストされ得るＥＤＮ構成サーバと通信し得る（すなわち、ＥＤＮ構成サーバは、エッジに展開されない場合がある）。エッジイネーブラクライアントは、所与の位置でどのエッジデータネットワークが利用可能であるか、又はどのエッジアプリケーションサーバが利用可能であるかなどの情報を取得するために、ＥＤＮ構成サーバと通信し得る。したがって、エッジイネーブラクライアントは、ＥＤＮ構成サーバとの通信を確立し、アプリケーションクライアントにサービスを提供することができる前に、構成情報を取得しなければならない場合がある。３ＧＰＰは、ＥＤＮ構成サーバを発見するためのエッジイネーブラクライアントの手段を定義していない。

【0101】

他のシナリオでは、ＵＥ上のアプリケーションクライアントは、「エッジを認識して」いない場合がある。したがって、例えば、これらは、エッジイネーブラクライアントと通信せず、３ＧＰＰアプリケーション層プロトコルに従わない。

【0102】

アプリケーションクライアントは「エッジを認識して」いないが、ＵＥ上のアプリケーションがエッジサービスを使用することができるシナリオでは、３ＧＰＰは、エッジコンピューティングが可能になったときに、ＵＥプロトコルスタックがアプリケーションデータをどこに送信するかをどのように知り得るのかを定義していない。言い換えれば、ＵＥが独立して（アプリケーションの補助なしに）、いつエッジにデータをルーティングするのかを決定するための方法はない。例えば、スマートフォンがエッジを認識していないアプリケーションをホストしている事例を考慮する。スマートフォンは、ユーザがエッジコンピューティングを可能にすることを望むアプリケーションをユーザが示すことができるＧＵＩを表示し得る。「エッジを認識して」いない場合、ＵＥプロトコルスタックが、示されたアプリケーションのエッジコンピューティングを可能にするための方法はない。

【0103】

エッジサービスがＮＥＦからのネットワーク露出情報（例えば、報告）に依存するとき、ネットワークからエダーサーバに移動する報告における長い遅延により、エッジサーバに到達する時間によって情報が時代遅れのものになる場合がある。これは、次に、古いネットワーク情報に基づいて、アプリケーションの挙動変更（例えば、ビデオストリーム解像度を調整すること又は走行自動化のレベルを切り替えること）を引き起こす可能性がある。したがって、対処する必要がある問題の１つは、ネットワーク露出情報（例えば、報告）が、よりタイムリーに又は最適化された様式でエッジサーバにどのように配信されることができるかである。新しくてより効率的な露出メカニズムが定義される場合、それらはまた、複数のメカニズムがシステム内に同時存在し得るように、どの露出メカニズムを使用するかを決定する５Ｇシステムのための方法を含むべきである。この問題は、下記で更に考察され、図８に示される。

【0104】

エッジサービスの有効化のためのプロビジョニング
エッジサービスの有効化のためのプロビジョニングを説明するにあたり、以下の仮説又は慣例が使用され得る。

【0105】

ＵＥは、エッジサービスを認識しているか、又は認識していない場合がある。

【0106】

エッジを認識しているＵＥは、エッジで提供されるサービスの明示的な要求をトリガすることができる。エッジを認識しているＵＥを実装するために２つの方法が利用可能であり得る。エッジを認識しているＵＥを実装する第１の様式は、ＳＡ６アーキテクチャに記載されているように、エッジサービスをエッジイネーブラサーバ及びエッジイネーブラ構成サーバなどのネットワークエンティティと一緒にすることを可能にする、ＵＥでホストされるエッジイネーブラクライアントをプロビジョニングすることによる。本開示は、これらのエンティティのためのＳＡ６学名を使用するが、同等のエンティティを有する非ＳＡ６ベースの実装が想定され得ることに留意されたい。例えば、エッジイネーブラクライアントは、サービス層又は共通サービスエンティティと呼ばれる場合がある。エッジを認識しているＵＥを実装する第２の様式は、エッジイネーブラクライアントがＵＥでホストされることはないが、特殊なプロトコルスタック及び構成エッジ機能性を有する。例えば、ＵＥは、特定のアプリケーションがエッジサービスへのアクセスを許可されるべきであることをユーザが示すことができるＧＵＩを提供してもよい。この場合、ＵＥプロトコルスタックは、エッジコンピューティングが可能であるときにアプリケーションデータを送信する方法を知るために、ＵＥを可能にする必要がある。

【0107】

エッジを認識していないＵＥは、エッジで提供されるサービスの明示的な要求をトリガする能力を有さない。エッジを認識していないＵＥは、ネットワークによってエッジサービスにルーティングされたトラフィックを有し得るが、ＵＥは、一般にこれを認識しない。

【0108】

エッジを認識しているＵＥのアプリケーションクライアント（ＥＥＣの有無にかかわらず）は、エッジサービスを認識しているか、又は認識していない場合がある。

【0109】

エッジを認識しているアプリケーションクライアントは、ＵＥ、又はエッジ関連能力及び要件に関する情報を有するＵＥによってホストされたＥＥＣに明示的に提供され得る構成情報を用いて事前にプロビジョニングされる。エッジを認識しているアプリケーションクライアントはまた、エッジで提供されるサービスの明示的な要求をトリガすることができ得る。これらの要求は、ネットワークから要求される前に、ＵＥ又はＵＥにホストされているＥＥＣによって処理される。

【0110】

エッジを認識していないアプリケーションクライアントは、エッジサービスの明示的な要求をトリガするための能力を有さないが、そのようなサービスを構成又はトリガするためにＵＥ又はＵＥにホストされているＥＥＣによって使用され得る、エッジを認識していないアプリケーションクライアントの能力及び要件に関する情報を事前にプロビジョニングしてもよい。例えば、ＵＥは、アプリケーションがエッジコンピューティングを可能にすることをユーザが示すことができるＧＵＩを提供し得る。ＧＵＩによって可能にされた機能性は、アプリケーションクライアントが事前にプロビジョニングした構成情報を使用してもよいが、アプリケーションクライアント自体は、エッジを認識していない場合がある。

【0111】

エッジデータネットワークは、エッジホスティング環境の配信展開をサポートするローカルデータネットワークである。

【0112】

エッジデータネットワークにおけるサービスは、モバイルネットワークオペレータ（Mobile Network Operator、ＭＮＯ）と同じであってもなくてもよいエッジコンピューティングサービスプロバイダ（Edge Computing Service Provider、ＥＣＳＰ）によって提供される。

【0113】

エッジデータネットワークは、ＬＡＤＮとして構成され得（例えば、ＭＮＯがＥＣＳＰでもあるとき）、その場合、そのサービスエリアは、既存の５ＧＣ手順に基づいて、ＬＡＤＮサービスエリアとして発見され得る。しかしながら、これらの手順は、ＥＤＮがＬＡＤＮとして構成されていない、より一般的な場合では、エッジデータネットワークサービスエリアの発見を可能にしない。以下の説明では、ＬＡＤＮの場合の特定の参照を伴う、より一般的な場合に対処する。

【0114】

エッジデータネットワーク構成サーバは、ＥＣＳＰ又はＭＮＯのいずれかによって展開／管理され、１つ以上のエッジデータネットワークに構成サービスを提供し得る。構成サーバは、一般に、エッジに存在せず、むしろ、ＭＮＯのＮ６－ＬＡＮの一部である。

【0115】

５ＧＣのＥＤＮ情報。５ＧＳは、外部アプリケーションサーバとのインターワーキングのためのネットワーク能力を指定する。これには、ＮＥＦを介した露出能力、例えば、外部機能へのプロビジョニング能力の露出が含まれる。また、ＰＬＭＮがルーティング決定に影響を与える一致を有する第三者に属するアプリケーションサーバの能力も含む。強化を伴うこれらの能力は、ＥＣＳＰのための手段を提供するために使用されて、ＥＤＮに外部管理されたＥＤＮ情報を提供し得る。

【0116】

アプリケーションサーバは、ＵＥにサービスを提供するＰＬＭＮによって管理されない場合があるエッジデータネットワークのための構成を、１）ＥＤＮサービスエリアに関する情報がＥＤＮ及びＥＤＮＣＳ発見を支援するために使用されるＡＭＦに、２）トラフィック情報がルーティングに影響を与えるために使用される場合、そのルーティング影響は、ＥＤＮＣＳにアクセスするために、又はエッジサービスの接続性を提供するために使用され得るＳＭＦに、提供し得る。

【0117】

ＰＣＦは、対応するポリシーでＡＭＦ及びＳＭＦの両方を提供し得ることに留意されたい。下記では、ＡＭＦ及びＳＭＦ構成について個々に詳細に説明する。しかしながら、ＡＦはまた、単一の組のプロビジョニング情報をＰＣＦに提供し得、結果として、対応するポリシーを介してＡＭＦ及びＳＭＦの両方にその情報が提供される。

【0118】

ＡＭＦは、ＡＭＦのサービスエリアの任意の追跡エリアで利用可能である全てのＥＤＮについての任意のＥＤＮ関連情報で構成され得、ＰＬＭＮ内の追加のＥＤＮに関する情報でも構成され得る。

【0119】

エッジデータネットワーク情報がＡＭＦにおいて、例えば、一組の追跡エリアとして構成され得る方法に対する異なるアプローチが存在し得る。一例では、情報は、ＤＮＮごとに、すなわち、同じＤＮＮを使用してエッジサービスにアクセスする、異なるＵＥについて構成され、構成されたエッジサービスエリアは、ＵＥ加入情報とは無関係に同じである。第２の例では、情報は、ＥＤＮＣＳごとに、すなわち、同じタイプの、又は同じＥＣＳＰからのエッジサービスにアクセスする、異なるＵＥについて構成され、構成されたエッジサービスエリアは、ＵＥ登録エリアとは無関係に同じである。ＵＥ加入情報は、加入されたエッジサービスのタイプを導出するために使用され、これは次に、対応するＥＤＮ－ＣＳを導出するために使用される。ＵＥによって提供された異なるＤＮＮは、同じＥＤＮ－ＣＳにマッピングしてもよい。

【0120】

上記の両方の例では、ＡＭＦにおいて構成されたＥＤＮ情報は、ＵＥ登録エリア（例えば、モビリティパターン及び許可／非許可エリア）であるかどうかを決定する要因に依存し得る。例えば、同じＥＤＮサービスエリア内にあり、同じサービスに加入された（又は同じＤＮＮを使用する）が、異なるモビリティパターンを有するＵＥは、異なるＥＤＮＣＳ（又はＥＤＮ）にマッピングされ得る。情報は、各ＥＤＮについて、ＥＤＮ識別子、サービスエリア（例えば、対応するＴＡＩのリスト）、ＤＮＮ若しくは複数のＤＮＮ、ＥＤＮがＬＡＤＮとして構成され、発見可能であるかどうかを指定するインジケータ、ＥＣＳＰと関連付けられたＩＤ、各又は複数のＤＮＮに関連付けられたＥＤＮ－ＣＳのＦＱＤＮ、及びＤＮＮ（例えば、サービスタイプごと）へのＥＤＮＣＳ関連付けを決定するための条件付きパラメータを含み得る。この情報がＡＭＦによって使用され得る方法は、後述の手順において説明される。

【0121】

ＳＭＦは、ＡＦから、ＰＣＦを介して、トラフィックルーティング影響の情報を受信する。エッジ構成情報を５ＧＣでプロビジョニングするとき、アプリケーションサーバの要求は、例えば、ＵＥのグループを標的とし得る。そのような要求の場合、情報は、ＵＤＲに記憶され得、ＰＣＦは、アプリケーションサーバ要求の、対応する通知を受信する。ＳＭＦに提供されるトラフィックルーティング影響情報には、１）トラフィック記述子（ＩＰフィルタ又はアプリケーションＩＤ）、２）ＤＮＡＩ、３）Ｎ６ルーティング情報（ＩＰアドレス、ポートを含み得る）、及び４）ＥＤＮＣＳ ＦＱＤＮが含まれ得る。この情報がＳＭＦによって使用され得る方法は、後で説明される手順において説明される。

【0122】

ＥＥＣなしのエッジを認識していないＵＥアプリケーションの処理。本明細書に開示される態様は、ＥＥＣをホストしていないＵＥがエッジを認識していないＵＥアプリケーションにエッジサービスを提供する必要がある場合によく適し得る手順を含む。例えば、ＵＥは、特定のアプリケーションがエッジサービスへのアクセスを許可されるべきであることをユーザが示すことができるＧＵＩを提供してもよい。ＵＥプロトコルスタックは、この指示を使用して、示されたアプリケーションからのトラフィックがエッジデータネットワークにルーティングされるべきであると決定し得る。

【0123】

ＥＥＣなしのエッジを認識していないＵＥアプリケーションの処理－登録ベースのＵＥプロビジョニング。ＵＥは、モビリティ追跡を可能にし、到達可能性を可能にするために、サービスを受信することを認可されるようにネットワークに登録しなければならない場合がある。ＵＥをネットワークに登録するとき、ネットワークのエッジコンピューティングリソースにアクセスすることを望むことを、ネットワークに示すことが提案される。このメカニズムは、ＵＥが、ＥＥＣをホストしていないが、エッジを認識しておらず、かつユーザがエッジコンピューティングを可能にするアプリケーションを示すことができるＧＵＩを提供するアプリケーションをホストしているシナリオで使用され得る。

【0124】

図４Ａ～図４Ｃは、本開示の一態様による、強化登録手順（ＥＥＣ事例なし）を示す。図４Ａ～図４Ｃに示される手順は、２３．５０２のセクション４．２．２．２．２に記載されている一般登録手順の強化バージョンである（３ＧＰＰ ＴＳ ２３．５０２、５Ｇシステムの手順、ステージ２、Ｖ１６．１．１（２０１９－０９））。一般登録手順の強化は、以下のとおりである。図４Ａのステップ１では、ＵＥは、登録タイプ「初期登録」又は「モビリティ登録更新」を使用して登録手順を開始することができ、ＵＥがネットワークのエッジコンピューティングリソースにアクセスすることを望むことを示し得る、フラグ及び追加情報であるＥＤＮ情報指示を提供することによって、エッジデータネットワーク情報を取り出すことを要求することができる。ＥＤＮ情報指示はまた、ＵＥ上の特定のアプリケーションがエッジコンピューティングサービスへのアクセスを有するべきであることをネットワークに示すためのアプリケーション記述子（ＯＳＩｄ及び／又はＯＳＡｐｐＩｄ）を含み得る。ＥＤＮ情報指示は、図４Ａのステップ３のＡＭＦに、及び図４Ｂのステップ１６においてＰＣＦに転送され得る。ＰＣＦは、この情報を使用して、どのＵＲＳＰルールがＵＥに転送するかを決定し得る。ＰＣＦは、ＵＥがエッジコンピューティングを可能にするＵＲＳＰルールで構成することができるかどうかの指示を用いてＡＭＦに応答してもよい。この指示は、アプリケーション記述子当たりのＰＣＦによって提供され得る。図４Ｃのステップ２１では、ＰＣＦからの指示は、ＡＭＦによってＵＥに提供され得る。ＰＣＦは、エッジコンピューティングに関連するＵＥのＵＲＳＰルールを更新することができるように、ＵＥの位置が変更されるときの通知を受信するためにＡＭＦに更に加入してもよい。

【0125】

ＥＥＣなしのエッジを認識していないＵＥアプリケーションの処理－ＵＲＳＰルールの使用。ＵＲＳＰは、ＰＣＦによってＵＥに提供されるポリシーである。これらは、ＵＥによって使用されて、ＵＥからの発信トラフィックをルーティングする方法を決定し得る。トラフィックは、確立されたＰＤＵセッションにルーティングされてもよく、ＰＤＵセッションの外側の非３ＧＰＰアクセスにオフロードされてもよく、又は新しいＰＤＵセッションの確立をトリガしてもよい。

【0126】

上述の登録手順の強化を使用して、ＵＥは、トラフィックがエッジサービスにルーティングされることから利益を得る場合があるアプリケーションをホストするという指示をＰＣＦに提供し得る。この情報（例えば、アプリケーション記述子）は、ＰＣＦによって使用されて、エッジサービスにアクセスするためのＵＲＳＰルールが必要とされ得ることを決定し得る。その結果として、ＥＤＮに特有のＵＲＳＰルールは、登録受諾応答でＵＥに返され得る。ＵＲＳＰルールはまた、構成更新手順でＵＥに提供され得る。この特徴をサポートするために、ＵＲＳＰルールのルート選択構成要素は、新しいエッジ対応指示を含むように修正され得る。この指示を有するルートは、関連付けられたアプリケーション記述子がエッジサービスを可能にするように、ＵＥが（例えば、ＧＵＩを介して）構成されている場合にのみ有効であると見なされ得る。ＲＳＤは、ルートが有効であると見なすことができる位置（例えば、エッジコンピューティングサービスが利用可能である場所）を更に示し得る。

【0127】

エッジコンピューティングがＵＥ上で可能である場合にのみ、エッジ対応指示を含むルート記述子を有するＵＲＳＰポリシーが使用され得る。ルート選択検証基準は、必要とされる特定のエッジサービスと関連付けられた位置（及び時間）状況を提供し得る。エッジ対応指示は、エッジ構成目的のＰＤＵセッション確立をエッジサービスにルーティングすることになるＵＲＳＰルールに使用され得る。エッジ対応指示を有する他のＵＲＳＰルールは、エッジ構成目的のＰＤＵセッション確立を構成サーバに送信させ得る。

【0128】

エッジ構成サーバのＥＥＣ発見（ＵＲＳＰベースのアプローチ）。ＰＤＵセッション確立手順は、ＵＥによって５ＧＳで使用されて、ＥＰＳからのいくつかのハンドオーバで、又は３ＧＰＰの事例と非３ＧＰＰの事例との間で、又はネットワークトリガＰＤＵセッション確立手順に続いて、新しいＰＤＵセッションを確立する。この手順は、ＵＥが登録され、ＡＭＦがＵＤＭからユーザ加入データを取り出したと仮定してもよい。

【0129】

いくつかのシナリオでは、エッジイネーブラクライアントは、エッジ構成サーバのＦＱＤＮで事前にプロビジョニングされた後、又は登録において取得された後に、エッジ構成サーバにＩＰ接続性を確立しようと試みてもよい。例えば、ＵＥは、ＥＤＮサービスエリアを発見し、アプリケーションクライアントのうちの１つには、構成サーバにアクセスするために、よく知られているＦＱＤＮが事前にプロビジョニングされている。ＵＥのＵＲＳＰルールは、ＦＱＤＮが最初にアクセスされるときに、ＵＥに新しいＰＤＵセッションを確立することを試みさせる場合がある。ＵＲＳＰルールは、ＰＤＵセッションを使用してエッジ構成データを取得するか、又は一般にオペレータ構成データを取得することをＵＥに示し得る。このメカニズムはまた、例えば、エッジサービス自体を取得するために、オペレータ又はエッジ構成データを取得すること以外の目的のためにも使用され得る。メカニズムはまた、例えば、ＵＲＳＰルールを介して提供されるのではなく、ＦＱＤＮが事前に構成されたときに、エッジを認識しているＵＥ又はアプリケーションによって使用され得る。

【0130】

２３．５０２のセクション４．３．２．２．１のＰＤＵセッション確立手順（３ＧＰＰ ＴＳ ２３．５０２、５Ｇシステムの手順、ステージ２、Ｖ１６．１．１（２０１９－０９）を参照）は、図５Ａ及び図５Ｂに示すように、強化され得る。本開示によって導入される手順に対する変更のみが詳述され、他の全てのステップは、本明細書に従って実行されることに留意されたい。

【0131】

図５Ａ及び図５Ｂは、強化されたＵＥ要求ＰＤＵセッション確立のコールフロー例を示す。ここで、図５Ａのステップ１では、ＵＥは、エッジ構成要求指示を含む、ＡＭＦ ＮＡＳメッセージ（Ｓ－ＮＳＳＡＩ、ＤＮＮ、ＰＤＵセッションＩＤ、要求タイプ、古いＰＤＵセッションＩＤ、Ｎ１ ＳＭコンテナ（ＰＤＵセッション確立要求）を送信してもよい。エッジ構成要求指示を含めることは、ＰＤＵセッションが、エッジ構成サーバから構成情報を取り出す目的で使用されることを示し得る。

【0132】

ステップ２では、ＡＭＦはＳＭＦ選択に進んでもよく、エッジ構成要求インジケータが含まれる場合、ＥＤＮＣＳを決定する。メッセージが既知のＥＤＮＣＳに対応するＤＮＮを含む場合、ＡＭＦは、ＳＭＦが、どのＤＮＳサーバアドレスをＵＥに提供するのかを決定してもよいように、ＦＱＤＮが、オペレータのＥＣＳのＩＰアドレスに決定されるように、その情報をＳＭＦに転送し得る。ＤＮＳサーバアドレスは、単純なリストとして、各ＤＮＳアドレスをある位置（例えば、セルＩＤ）にマッピングするリストとしてなど、複数の方法で提供され得る。メッセージが既知のＥＤＮＣＳに対応するＤＮＮを含まない場合には、提供されるＳ－ＮＳＳＡＩについて、ＡＭＦは、１）利用可能なＬＡＤＮに対応するＥＤＮＣＳ、２）加入されたエッジサービス又は使用されるデフォルトのＤＮＮの相対的な優先度に関するＵＥ加入情報から確立された優先度に基づくＥＤＮＣＳ、又は３）ローカルのＯＡＭ構成に基づくＥＤＮＣＳを選択／決定してもよい。ＡＭＦは、存在通知がＳＭＦに送信されるように、「ＥＤＮエリア内のＵＥの存在」に暗黙の加入を作成してもよい。

【0133】

ステップ３では、ＡＭＦは、Ｎｓｍｆ＿ＰＤＵＳｅｓｓｉｏｎ＿ＣｒｅａｔｅＳＭＣｏｎｔｅｘｔ Ｒｅｑｕｅｓｔを、ＳＭＦへのエッジ構成選択モードフラグを有する選択されたＳＭＦに送信してもよく、ＳＭＦは、この指示を使用して、どのＤＮＳサーバアドレスがＰＤＵセッション確立応答でＵＥに送信されるべきかを決定してもよい。ＤＮＳサーバアドレスは、単純なリストとして、各ＤＮＳアドレスをある位置（例えば、セルＩＤ）にマッピングするリストとしてなど、複数の方法で提供され得る。また、ＰＤＵセッション確立応答を使用して、ＰＤＵセッションを使用してエッジ構成サーバに到達し得ることをＵＥに送信してもよい。

【0134】

ステップ５では、ＳＭＦは、Ｎｓｍｆ＿ＰＤＵＳｅｓｓｉｏｎ＿ＣｒｅａｔｅＳＭＣｏｎｔｅｘｔ応答をＡＭＦに送信してもよい。応答は、ＥＤＮＣＳのＦＱＤＮを含み得るか、又はＵＥで更新されるＥＤＮＣＳのＤＮＳサーバアドレスを提供し得る（すなわち、３ＧＰＰ ＴＳ ２３．５０１、５Ｇシステムのシステムアーキテクチャ、ステージ２、Ｖ１６．３．０（２０１９－１２）に記載されているように、ＰＤＵセッション中に）。ステップ８では、ＳＭＦは、ＥＤＮＣＳのＦＱＤＮを使用して、適切なＵＰＦを選択してもよい。ステップ１０ａでは、ＳＭＦは、選択されたＵＰＦにＮ４セッション確立要求を送信してもよく、適切なＣＮトンネル情報を含んでもよい。次いで、ステップ６から続けて、任意選択の二次認証／認可のような様々な手順は、ＰＤＵセッションが構成目的のために使用されることを考慮に入れてもよい。図５Ｂのステップ１２及び１３は、応答情報をＵＥに転送するために使用される。

【0135】

エッジ構成サーバのＥＥＣ発見（登録ベースのアプローチ）。ＵＥには、登録中にエッジ構成サーバ情報が提供され得る。一般的な登録手順の強化は、図６Ａ及び図６Ｂに示されており、以下のように説明される。図６Ａのステップ１では、ＵＥは、登録タイプ「初期登録」又は「モビリティ登録更新」を使用して登録手順を開始することができ、ＵＥがネットワークのエッジコンピューティングリソースにアクセスすることを望むことを示す、フラグ及び追加情報であるＥＤＮＣＳ発見要求指示を提供することによって、エッジ構成サーバを発見することを要求することができる。ＥＤＮＣＳ発見要求指示はまた、ＵＥ上の特定のアプリケーションがエッジコンピューティングサービスへのアクセスを有するべきであることをネットワークに示すためのアプリケーション記述子（ＯＳＩｄ及び／又はＯＳＡｐｐＩｄ）を含み得る。ＥＤＮ発見要求指示は、ステップ３でＡＭＦに転送され得る。ＡＭＦは、この情報を使用して、どのＥＤＮＣＳ発見情報をＵＥに転送するかを決定し得る。

【0136】

ＵＥがＥＤＮ発見要求指示を介してＥＤＮＣＳ発見情報を要求するとき、ＡＭＦは、登録手順に対する応答を介して提供されるＥＤＮＣＳ発見情報を識別し得る。ＡＭＦは、ＵＥがエッジサービス加入を有するサービスを決定するために、加入情報（既存の、又は図６Ｂのステップ１４を介して取得された）を使用してもよい。ＡＭＦは、登録エリア内のＵＥに利用可能なＥＤＮ及びＥＤＮＣＳのリストを、登録受諾においてＵＥに提供するように作成してもよい（図６Ｂのステップ２１）。ＵＥに提供される情報は、例えば、ＵＥによって発見される基準を満たす各ＥＤＮについて、１）ＥＤＮ識別子、２）ＥＤＮ上のＵＥの認可範囲（例えば、サービス又は記憶装置上の）、３）対応するＥＤＮサービスエリア（例えば、対応するＴＡＩのリスト）、４）エッジサービスを取得するために使用される１つ以上のＤＮＮと、５）ＥＤＮがＬＡＤＮとして構成され、発見可能であるかどうかを指定する任意選択のインジケータ、６）条件付きパラメータ（例えば、サービスタイプ又はモビリティパターンごとの）に基づいて決定された、各又は複数のＤＮＮに関連付けられたＥＤＮＣＳのＦＱＤＮ、又は７）ＥＤＮＣＳ発見情報を含み得る。ＥＤＮＣＳ発見情報は、以下の情報：１）ＥＤＮＣＳのＦＱＤＮ又はＩＰアドレス、２）どのエッジサービスが提供されることができるかについてのサービスのリスト（例えば、アプリケーション記述子）、又は３）ＵＥがアクセスするためにＥＣＤと関連付けられた１つ以上のＤＮＮを含み得る。図６Ｂのステップ２１における「ＥＤＮ情報」は、上述のこの「ＥＤＮＣＳ発見情報」を含むことに留意されたい。

【0137】

上記リスト内の全ての情報がＡＭＦで利用可能であり得るわけではないことに留意されたい。例えば、ＥＤＮサービスエリアが構成されてもよいが、ＥＤＮＣＳ情報は利用可能ではない場合がある。また、ＵＥがＬＡＤＮ ＤＮＮ又はＬＡＤＮ情報を要求するインジケータも含んでいた場合、ＡＭＦは、ＬＡＤＮとして構成され、発見可能なＥＤＮについてのみ情報を提供し得る。あるいは、ＵＥは、ＥＤＮがＬＡＤＮとして構成され、発見可能であるかどうかを指定する任意選択のインジケータを使用して、この情報を抽出することができる場合がある。

【0138】

ＵＥにおいて利用可能なＥＤＮサービスエリアに基づいて、ＵＥは、エッジサービスのためのＰＤＵセッションを要求し得るかどうかを後で決定してもよい。あるいは、この情報は、ＵＥサービス要求又は構成更新手順で要求され、提供され得る。ＡＭＦが、上述のプロセスに基づいて、２つ以上の適用可能なＥＤＮＣＳが利用可能であると決定する場合、ＡＭＦは、提供されるＳ－ＮＳＳＡＩについて、１）利用可能なＬＡＤＮに対応するＥＤＮＣＳ、２）加入されたエッジサービス又は使用されるデフォルトのＤＮＮの相対的な優先度に関するＵＥ加入情報から確立された優先度に基づくＥＤＮＣＳ、３）ローカルのＯＡＭ構成に基づくＥＤＮＣＳを選択／決定してもよい。ＡＭＦは、存在通知がＳＭＦに送信されるように、「ＥＤＮエリア内のＵＥの存在」に暗黙の加入を作成してもよい。ＡＭＦは、選ばれたＥＤＮＣＳに対応するＳＭＦを決定するか、又はＥＤＮＣＳを決定することができない場合は、セッション確立要求を拒否してもよい。

【0139】

ＵＥを介した効率的なネットワーク露出及び代替的な経路を可能にする。
監視イベントは、アプリケーション機能（ＡＦ）に露出され得る（３ＧＰＰ ＴＳ ２３．５０２のセクション４．１５．３、５Ｇシステムの手順、ステージ２、Ｖ１６．１．１（２０１９－０９）に記載されているように）。監視イベントがＮＥＦを介してＡＦに露出されるとき、報告は、イベントを検出したＮＦ（ＡＭＦ、ＧＭＬＣ、ＵＤＭ、又はＳＭＦ）から、ＮＥＦに、及びＡＦ上に送信され得る。イベントを検出し、報告を送信する前に、イベントを検出したＮＦは、例えば、ＡＭＦのＴＳ ２３．５０２のセクション４．１５．３．２における手順のうちの１つを監視するように構成され得る。構成は通常、加入動作を呼び出すことからなる。

【0140】

図８は、エッジ展開のための最適化されていないネットワーク露出報告経路の一例である。本明細書に記載される「ローカルの展開」は、ローカルの展開機能が一般に、ＵＥに地理的により近づくように展開されるときに、ＬＡＤＮ及び／又はエッジ展開における機能性の有効化に専用であり得るコアネットワーク機能（例えば、ＵＰＦ又はＳＭＦ）を示す。ローカルの展開機能は、サービスが提供されたＵＥの位置とは独立して展開される「集中型」コアネットワーク機能から独立して図示され得る。

【0141】

エッジホスティング環境は、ローカルの展開及びＵＥに地理的に近接している場合があるが、機能的には、ＣＮ展開の一部ではない。したがって、本開示の一態様では、エッジホスティング環境から分離されるローカルの展開を考慮すると、例えば、ローカルの展開が複数のＥＨＥに役立ち、異なるプロバイダによって管理され得る。しかしながら、これは、単に論理的構成であり、ローカルの展開は、あるいは、５ＧＣの一部と見なされるか、又はＥＨＥなどを含み得る。また、いくつかの３ＧＰＰ仕様（例えば、３ＧＰＰ ＳＡ２からの）では、このローカルの展開の概念は、「エッジ」又は「エッジ展開」と称され得ることに留意されたい。

【0142】

図８は、エッジアプリケーションサーバと共にエッジホスティング環境（Edge Hosting Environment、ＥＨＥ）における、又は集中型クラウドにおけるＡＦ展開の２つの可能性を図示する。点線は、ＡＭＦ又はローカルＳＭＦのいずれかによって生成され得る報告について、ＡＦへの報告経路を例示する。

【0143】

図８は、現在の露出アーキテクチャが、いくつかのエッジ展開で問題を引き起こす可能性がある理由を例示している。監視報告を集中型ＮＥＦを通って横断する必要があるという事実は、特にエッジＡＦに向かう、ＡＦにおけるイベントの発生とイベント報告の受信との間に許容できない遅延を引き起こす場合ある。ＡＭＦ及びＮＥＦは、「集中型」コアネットワークにあってもよい、すなわち、「エッジ」にはなくてもよいが、互いに近づかない場合があることに留意されたい。例えば、ＡＭＦ、ＳＭＦ、及びＮＥＦは、各々異なる／別個の都市であってもよい。

【0144】

本開示の態様は、ＵＥがローカルの展開を介してエッジホスティング環境（ＥＨＥ）に接続されているときに、イベント報告を送信するために使用され得る新しい報告方法を提案する。一態様では、新たなＣＮ機能「ローカル有効化機能」（Local Enablement Function、ＬＥＦ）が提案されている。ＬＥＦは、監視報告をＡＦにルーティングするために使用され得る、ＮＥＦのタイプであり得る。遅延敏感ではないＡＦの監視報告構成要求は、集中型コアネットワーク内に存在するＮＥＦに依然として送信され得る。

【0145】

図９は、集中型ネットワーク機能からの最適化された報告経路の一例である。図９は、ローカルの展開に接続されたＥＨＥにおいて、ＡＦに露出するために使用されるローカルの展開のＬＥＦを図示する。点線は、ＡＭＦ又はローカルＳＭＦのいずれかから、エッジＡＦへの報告経路を例示する。図示される報告経路は、本明細書に導入される方法に対応している。最適化は、集中型ＮＦと、エッジの地理的に近接したエンティティとの間でメッセージが地理的境界を超える回数を最小化（又は排除）することによって起きる。

【0146】

集中型ＮＥＦを介したエッジ報告加入のための方法－加入再標的化を使用する方法。以下は、ＡＦが、集中型ＮＥＦを介して監視イベントに加入し得る方法について説明する。ＵＥが移動し、異なるローカルの展開及びＥＨＥに接続するとき、加入は、対応する展開に役立つＬＥＦに転送され得る。

【0147】

図１０は、集中型ネットワーク露出機能からのエッジ報告加入の転送を実証するコールフロー例である。図１０のフローは、集中型ＮＥＦがＰＣＦに転送されるイベント、例えば、ダウンリンク送達データ状態への加入を図示する。フローでは、ＰＣＦは、他のタイプのイベントのＵＤＭ、例えば、ＤＤＮ障害後の可用性によって置き換えられ得る。したがって、ＰＣＦについて説明された転送機能性及びフローメッセージは、ＵＤＭなどの他のＮＦに適用され得る。

【0148】

集中型ＮＥＦを介してイベント監視のためのＡＦ加入を可能にするために、報告要件（例えば、遅延）を満たすために最も好適なＮＥＦ又はＬＥＦによって報告露出が提供される一方で、報告要件、ＡＦ可用性情報、及びＵＥルーティング選好インジケータを含む、新たに提案された報告パラメータを含むように、報告加入手順を強化することが提案される。報告要件（例えば、遅延公差）は、各加入のためのものであってもよく、また、提供される報告要件が、いくつかの条件、例えば、ＵＥの位置、ＵＥの到達可能性状態、時刻などに基づいて異なって適用され得るように、修飾子のリストを含んでもよい。ＡＦ可用性情報は、例えば、ＡＦの位置パラメータ、又は可用性時間であってもよい。ＵＥルーティング選好インジケータは、報告経路内のＵＥを含む（又は含むことを好む）ための必須又は任意選択の要件として使用され得る。この特徴は、報告に基づいてＡＦ処理を待機する代わりに、ＵＥが処理のために報告（例えば、ＱｏＳ変更）を使用し得るときにも使用され得る。報告パラメータを使用して、報告要件を満たすために、どのエンティティ（例えば、ＮＥＦ又はＬＥＦ）が報告露出に最適であることを決定し得る。

【0149】

図１０のステップ１では、ＡＦは、Ｎｎｅｆ＿ＥｖｅｎｔＥｘｐｏｓｕｒｅ＿Ｓｕｂｓｃｒｉｂｅ要求を、エッジホスティング環境検出報告、例えば、データ送達状態を要求する集中型ＮＥＦに送信し得る。要求は、ＩＰトラフィックフィルタ及び監視イベントを含み得る。ステップ２では、ＮＥＦは、Ｎｐｃｆ＿ＥｖｅｎｔＥｘｐｏｓｕｒｅ＿Ｓｕｂｓｃｒｉｂｅ要求をＰＣＦに送信し得る。ＩＰフィルタ情報、ステップ１から受信された監視イベントは、メッセージ、並びに要求ＡＦのエンドポイントに含まれ得る。ＮＥＦは、例えば、ＢＳＦをクエリすることによって、ＰＤＵセッションのための選択されたＰＣＦのアドレスを決定し得る。

【0150】

上記で提案された加入された報告パラメータを使用して、ＮＥＦは、加入された報告の露出をサポートするのに最も好適なエンティティを決定し得る。ＢＳＦにおいてこの機能性をサポートするために、登録Ｎｂｓｆ管理登録動作は（３ＧＰＰ ＴＳ ２３．５０２の５．２．１３．２．２、５Ｇシステムの手順、ステージ２、Ｖ１６．１．１（２０１９－０９）に記載されているように）、利用可能なＮＥＦ及びＬＥＦに関する情報を含むように強化されることが提案されている。これは、ＰＣＦがＮｂｓｆ＿Ｍａｎａｇｅｍｅｎｔ＿Ｒｅｇｉｓｔｅｒを呼び出すときに、ＰＤＵセッション及びＰＣＦ ｉｄのためのタプル（ＵＥアドレス、ＳＵＰＩ、ＧＰＳＩ、ＤＮＮ、ＤＮ情報（例えば、Ｓ－ＮＳＳＡＩ）、ＰＣＦ ｉｄ）に加えて、例えば、報告要件又はエンドポイント（ＡＦ）情報に基づいて、好適なＮＥＦ／ＬＥＦ情報も提供し得ることを意味する。

【0151】

加入されたＮＥＦがこれらの要件を満たすとき、既存の加入／通知手順が適用され得る。以下の説明は、主に、ローカルの展開におけるＬＥＦが最も効率的な報告露出を提供する事例を取り上げる。

【0152】

ステップ３では、ＰＣＦは、Ｎｓｍｆ＿ＥｖｅｎｔＥｘｐｏｓｕｒｅ＿Ｓｕｂｓｃｒｉｂｅ要求メッセージを、ＩＰフィルタ情報に関連するＰＤＵセッションに役立ち得るローカルＳＭＦに送信し得、ＬＥＦ、並びに要求ＡＦの通知エンドポイントを含み得る。次に、ステップ４では、ローカルＳＭＦは、Ｎｎｅｆ＿ＥｖｅｎｔＥｘｐｏｓｕｒｅ＿Ｓｕｂｓｃｒｉｂｅ要求を、報告の露出を要求する、対応するＬＥＦに送信し得る。この要求は、要求ＡＦのエンドポイントを含み得る。次いで、ステップ５では、ＬＥＦは、Ｎｓｍｆ＿ＥｖｅｎｔＥｘｐｏｓｕｒｅ＿Ｓｕｂｓｃｒｉｂｅ応答をローカルＳＭＦに応答し、ステップ６では、ローカルＳＭＦは、Ｎｐｃｆ＿ＥｖｅｎｔＥｘｐｏｓｕｒｅ＿Ｓｕｂｓｃｒｉｂｅ応答メッセージを、ＬＥＦ情報を含むＰＣＦに送信し得る。続いて、ステップ７は、ＰＣＦが、ＬＥＦ情報を含むＮｐｃｆ＿ＥｖｅｎｔＥｘｐｏｓｕｒｅ＿Ｓｕｂｓｃｒｉｂｅ応答メッセージをＮＥＦに送信し得る。ステップ８では、ＮＥＦは、ＬＥＦ情報を含み得るＮｓｍｆ＿ＥｖｅｎｔＥｘｐｏｓｕｒｅ＿Ｓｕｂｓｃｒｉｂｅ応答をＡＦに送信し得る。ローカルＳＭＦは、ステップ９で、イベント、例えば、ダウンリンク送達状態の変更を検出し得る。また、ステップ１０では、ＳＭＦは、Ｎｓｍｆ＿ＥｖｅｎｔＥｘｐｏｓｕｒｅ＿Ｎｏｔｉｆｙを、ダウンリンク送達状態イベントメッセージと共にＬＥＦに送信し得る。

【0153】

ＬＥＦと通信するためには、ローカルＳＭＦは、ローカルＵＰＦへの、及びＬＥＦにすでに提案されたＮｘインターフェースであるローカルＵＰＦからのＮ４インターフェースを使用し得る。あるいは、新しいインターフェース又はＡＰＩを、ローカルＳＭＦとＬＥＦとの間に定義してもよい。あるいは、新しいサービスベースのインターフェースを、ローカルＳＭＦとＬＥＦとの間で定義してもよく、サービスベースのインターフェースのＡＰＩを使用して報告をＬＥＦに送信してもよい。ステップ１１では、ＬＥＦは、Ｎｎｅｆ＿ＥｖｅｎｔＥｘｐｏｓｕｒｅ＿Ｎｏｔｉｆｙを、ダウンリンク送達状態イベントメッセージと共にＡＦに送信し得る。

【0154】

上記の説明におけるステップ４、５、１０、１１のメッセージは、ＬＥＦインターフェースが３ＧＰＰによって現在定義されているＮＥＦ動作の拡張として実装されると仮定して、Ｎｎｅｆ動作を使用し得ることに留意されたい。しかしながら、ＬＥＦメッセージングは、３ＧＰＰによって現在説明されているＮｎｅｆ動作と同様に実装され得るが、独立して実装され得る。

【0155】

本明細書で提案されたＢＳＦ機能性の強化に加えて、本方法は、ＰＣＦが対応するローカルＳＭＦを決定することに依存することに留意されたい。これは、ＵＥがローカルの展開Ａからローカルの展開Ｂに移動し、接続を変更するときに、ＰＣＦが、ローカルのＳＭＦ及びローカルの展開Ａに役立つＬＥＦに送信された加入を追跡し、これらをローカルの展開Ｂに転送し、古い加入を削除する必要があることを意味する。ＰＣＦはまた、新しいＬＥＦを有するＮＥＦ（ステップ７に対応する）に対する加入応答の更新を送信し得る。加入応答の更新は、ＮＥＦによってＡＦ（ステップ８に対応する）に転送される。

【0156】

集中型ＮＥＦを介したエッジ報告加入のための方法－ＵＥを介して転送するポリシーを使用する方法。図１１は、ＵＥを介したエッジ監視ポリシーのルーティング／配信を実証するコールフロー例である。図１１のフローは、ＡＦが、集中型ＮＥＦを介して、ローカルの展開でＮＦによって生成されたイベントを監視するためにどのように加入し得るかを記載している。本方法をサポートするために、以前に提案された報告パラメータを使用して、ＡＦ加入手順を強化し得る。報告パラメータは、報告要件、ＡＦ可用性情報、及びＵＥルーティング選好インジケータを含み得る。報告パラメータは、この加入が、例えば、ローカルの展開におけるＬＥＦを介して、最適化された様式で送達されるのに必要なエッジにおけるイベント監視に関連しているかどうかを決定するために使用され得る。ＵＥを介して転送するポリシーを使用する方法を可能にするために、ＡＦの１つ以上のイベント加入を使用して、エッジ監視ポリシー（Edge Monitoring Policy、ＥＭＰ）を作成し得る。

【0157】

ＡＭＦは、ＮＡＳメッセージにＥＭＰをカプセル化し、それをＵＥに送信し得る。ＵＥが１つのローカルの展開から別のローカルの展開への接続を変更するとき、事前に構成されたＦＱＤＮ（又はポリシー自体に提供された）を使用して、ユーザプレーンメッセージングを介して各ローカルＳＭＦにＥＭＰを提供し得る。あるいは、ＵＥは、ＮＡＳ－ＳＭメッセージング（例えば、ＰＤＵセッション確立又はＰＤＵセッション修正メッセージ）を介して、各ローカルＳＭＦにＥＭＰを提供し得る。ＵＰＦが事前に構成されたＦＱＤＮにアドレス指定されたメッセージを受信するとき、このＵＰＦは、ＰＤＵセッションと関連付けられたローカルＳＭＦにそのメッセージを送達し得る。この機能性を可能にするために、ＵＥがポリシー転送をサポートすることを示すことが提案されている。サポートの指示は、様々な手順中に、例えば、コアネットワークに登録するときに、提供され得る。ネットワーク（すなわち、ＡＭＦ）は、このインジケータを使用して、ＥＭＰをＵＥに送信することが許容されるかどうかを決定し得る。

【0158】

ＵＥからローカルＳＭＦに送信され得るポリシー情報（ＥＭＰ）を使用して、ＳＭＦを構成し得る。また、ＵＥを介してＳＭＦにポリシーを送達する本方法は、ＳＭＦがＰＣＦと直接通信することができないか、又はＡＭＦからポリシー情報を受信することができない場合、又はローカルの展開において、集中型ＮＦからＮＦに他のポリシー又は構成メッセージを送達するためになど、他の事例にも使用されることができる。

【0159】

図１１のステップ１では、ＡＦは、Ｎｎｅｆ＿ＥｖｅｎｔＥｘｐｏｓｕｒｅ＿Ｓｕｂｓｃｒｉｂｅ要求を、エッジホスティング環境検出報告、例えば、データ送達状態を要求する集中型ＮＥＦに送信し得る。この要求は、ＩＰトラフィックフィルタ及び監視イベントを含み得る。次いで、ステップ２では、ＮＥＦは、この要求を対応するＮＦに、例えば、Ｎｐｃｆ＿ＥｖｅｎｔＥｘｐｏｓｕｒｅ＿Ｓｕｂｓｃｒｉｂｅ要求をＰＣＦに送信し得る。ＰＣＦは、いくつかのタイプのイベントのＵＤＭ、例えば、ＤＤＮ障害後の可用性後に置き換えられ得る。ＩＰフィルタ情報、ステップ１から受信された監視イベントは、メッセージ、並びに要求ＡＦのエンドポイントに含まれ得る。ＮＥＦは、ＢＳＦをクエリすることによって、ＰＤＵセッションのための選択されたＰＣＦのアドレスを決定し得る。

【0160】

ステップ３では、ＰＣＦ又はＵＤＭは、対応するＥＭＰを作成してもよいし、又は新しい加入を含むように既存のＥＭＰを修正してもよい。ＥＭＰは、例えば、ＰＣＦによって作成され、ＵＤＭに記憶され得る。ＥＭＰはまた、ＡＭＦに転送されてもよく、ここで、監視が関連しているＵＥのＮＡＳメッセージにカプセル化される。ＥＭＰは、１つ以上の監視イベントに関する情報、及び１つ以上の受信ＡＦを含み得る。本方法を使用して配信され得るＥＭＰは、
・ポリシーのための固有のＩＤを提供するポリシー識別子と、
・監視ポリシーが適用するＵＥを識別する方法を提供するＵＥ識別フィルタと、を含み得る。フィルタは、例えば、ＩＰフィルタ又は加入相関ＩＤ、
・受信ＡＦのエンドポイント情報と関連付けられた、通知エンドポイントとして表現され得る。これは、２つ以上の受信ＡＦと、
・どの測定値又はメッセージタイプが、ローカルの展開において生成され、ポリシーが適用されるＡＦに送信されるべきかを決定する測定値又はメッセージタイプの識別子（例えば、ダウンリンク送達データ状態イベントＩＤ）と、
・例えば、イベント通知がＡＦに転送されるべき時間窓を含み得る通知パラメータと、を含み得る。通知基準は、イベント監視を構成するためにローカルＳＭＦによって使用される。通知パラメータは、ＬＥＦ情報を含み得るか、又はＬＥＦ情報は、ローカルＳＭＦにおいて事前に構成され得、
・例えば、地理的エリア、特定のＬＡＤＮ情報などを示すことによって、どのローカルの展開が適用されるべきかを指定するポリシー適用性基準を含み得る。ポリシー適用性基準は、ポリシーを検証するか、又は監視を構成するにあたりローカルＳＭＦによって使用され得、
・ＵＥがＥＭＰをローカルの展開にどのように送達するべきかを定義する他の基準を指定するポリシー送達基準を含み得る。例えば、ポリシー送達基準は、送達をトリガするために、ＡＭＦトリガが必要とされることをＵＥに示し得る。別の例では、基準は、ＵＥが、定期的になど、検出された任意の新しいＬＡＤＮのＥＭＰ送達をトリガするべきであることを示し得る。これらの基準はまた、ＵＥがＥＭＰ送達のために事前に構成されたＦＱＤＮを使用するべきかどうか、又は別の特定のＦＱＤＮを構成してもよいかどうかを示し得る。

【0161】

ステップ４では、ＡＭＦは、ＮＡＳメッセージを使用して、ＥＭＰをＵＥに送信し得る。ＮＡＳメッセージには、ＥＭＰ、及びローカルの展開に接続するときに、報告をローカルＳＭＦに送信する方法についての命令が含まれ得る。例えば、上述のポリシー送達基準は、ポリシー自体に含まれる代わりに、ＮＡＳメッセージに含まれ得る。

【0162】

ＵＥが新しいローカルの展開と接続するとき、図１１の後続ステップは、新しいローカルの各展開について繰り返される。ステップ５では、ＵＥは、例えば、新しいＬＡＤＮを検出することによって、新しいローカルの展開を検出してもよい。あるいは、ＵＥは、ローカルの展開に接続した後、ＡＭＦによってトリガされ得る。次いで、ステップ６では、ＵＥは、ＵＰメッセージにカプセル化されたＥＭＰをローカルＵＰＦに送信し得、次いで、このメッセージを、ＥＭＰに指定された、又はＡＭＦから受信したＮＡＳメッセージに指定されたポリシー送達基準を使用して、ローカルＳＭＦに転送し得る。ＵＥは、ＥＭＰをＳＭＦに送信するために使用され得るＤＮＮ及び／又はＳ－ＮＳＳＡＩで構成され得る。ＵＥは、ＥＭＰを搬送するトラフィックが特定のＤＮＮ及び／又はＳ－ＮＳＳＡＩに向かってルーティングされるべきであることを示すＵＲＳＰルールで構成され得る。ステップ７では、ローカルＳＭＦは、ローカルの展開における監視を構成し得る。ローカルＳＭＦは、ローカルの展開（例えば、ＮＷＤＡＦ）に実装された他のＮＦを構成して、監視報告を提供し得る。イベントは、ローカルＳＭＦによってステップ８で検出され得る。あるいは、イベントは、ローカルの展開に実装された他のＮＦによって検出され得る。ステップ９では、ローカルＳＭＦは、Ｎｓｍｆ＿ＥｖｅｎｔＥｘｐｏｓｕｒｅ＿Ｎｏｔｉｆｙを、監視されたイベントと共にＬＥＦに送信し得、ＬＥＦは、ステップ１０で、Ｎｎｅｆ＿ＥｖｅｎｔＥｘｐｏｓｕｒｅ＿Ｎｏｔｉｆｙを、監視されたイベントメッセージ共にＡＦに送信し得る。

【0163】

集中型ＮＦ（すなわち、ＮＥＦ）を介してＡＦによって提供される加入情報を配信するための上述の方法は、ＵＥの経路に沿ったローカルの展開において、集中型ＮＦを介してＮＦに提供される任意のポリシー又は構成情報の配信に使用され得る。本方法はまた、ローカルの展開に接続されたエッジホスティング環境内のサーバに、集中型ＮＦを介して提供されるポリシー又は構成情報を配信するために使用されることができる。

【0164】

エッジサーバに報告するための方法－ＵＥを介した集中型ＮＦイベント報告のための方法。イベントが中央コアネットワーク内で検出され（例えば、図８のＡＭＦにより）、かつＡＦがエッジにあるとき、ＮＥＦを介して報告をエッジに送信することは効率的ではない場合がある。図８に例示されるように、ＮＥＦを介して報告を送信することにより、かなりの遅延を引き起こし得る。一態様では、ＵＥがローカルの／エッジ展開、及び報告を受信するべきＡＦに接続されている場合、ＡＭＦは、ＮＡＳメッセージを使用して、ＵＥを介して報告を送信し得ることが提案されている。ＮＡＳメッセージは、ＡＦに報告を送信する方法について、イベント報告及び命令（すなわち、アドレス）を含み得る。例えば、以下の情報がＵＥに送信され得る。
・位置変更、ＳＵＰＩ／ＰＥＩ関連付けの変更、ＭＩＣＯモード設定の変更、ＵＥ到達性報告、もはや（又は再び）満たされることができないＱｏＳターゲット、又はＱｏＳ監視パラメータなどの、イベントを説明するイベント報告、
・報告を受信するべきであるＬＥＦのＩＰアドレス又はＦＱＤＮ、
・報告をＵＥに送信するために使用されるＰＤＵセッションと関連付けられて使用されるべきＤＮＮ又はＳ－ＮＳＳＡＩ、
・ＬＥＦが報告を転送するべきであるＡＦを識別するＡＦ識別子、及び
・報告を受信するためにＡＦの早期要求と報告を相関させるように、ＡＦによって使用され得るトランザクション参照ＩＤ。

【0165】

本方法は、ＵＥが到達可能であるときに、集中型コアネットワーク内のＡＭＦ又は他のＮＦからの監視報告を転送するために更に使用され得る。本方法はまた、報告パラメータが精密に導入された加入をサポートし得、ＵＥルーティング選好インジケータは、ＵＥルーティングの選好を命令するか、又は示す。これは、ＱｏＳ監視など、ＡＦ動作又はコマンドを待機することなく、報告に直接作用するＵＥが有益な場合に特に有用である。同時に、ＡＦはまた、最適化された経路を介して報告を通知し得る。

【0166】

図１２は、ＵＥを介した集中型ＮＦからの報告ルーティングを実証するコールフロー例である。図１２は、ＵＥを介して集中型ＮＦ（例えば、ＡＭＦ）からＥＨＥに位置するＡＦにルーティングされている報告を監視するための高レベルフロー方法を図示する。

【0167】

ＵＥが図１２のステップ２でＡＭＦから監視報告を受信した後、ステップ３で、この監視報告をローカルＵＰＦを介してＬＥＦに送信し得る。ＵＥが監視報告をＬＥＦに送信するとき、ＵＥは、ＤＮＮ、及び監視報告がＵＥに送信されたときにＡＭＦによって提供されたＳ－ＮＳＳＡＩとすでに関連付けられている既存のＰＤＵセッションを使用することを選び得る。あるいは、ＵＥは、ＤＮＮ、及びＡＭＦによって提供されたＳ－ＮＳＳＡＩを使用して、新しいＰＤＵセッションを確立し、報告を送信するために新しいＰＤＵセッションを使用し得る。ＵＥはまた、ＬＥＦに、ＡＦ識別子などの情報を転送し得、その結果、ＬＥＦは、どのＡＦに報告を転送するかを決定することができる。ＵＥはまた、ＡＭＦから報告が受信されたときを示すタイムスタンプ、ＡＭＦから受信されたトランザクション参照ＩＤなどの他の情報を含み得る。

【0168】

ＵＰＦは、ステップ４で、報告をＬＥＦに送信するためにインターフェース又はＡＰＩを使用し得る。例えば、図９のＮｘインターフェースは、Ｎ６ベースのインターフェースであり得、ＩＰベースのルーティングは、報告をＮＥＦに送信するために使用され得る。あるいは、新しいサービスベースのインターフェースを、ＵＰＦとＬＥＦとの間で定義してもよく、サービスベースのインターフェースのＡＰＩを使用して報告をＬＥＦに送信してもよい。

【0169】

次に、ＬＥＦは、集中型ＮＥＦ（図９）において使用されるのと同じＡＰＩを使用して、ステップ５で、エッジＡＦに情報を露出させ得る。Ｎｙインターフェースは、エッジＡＦをＬＥＦインターフェースにサポートし、ＴＳ ２９．１２２で定義されるＮ３３／Ｎｎｅｆインターフェースとして実現され得る。このＡＰＩは、ＵＥがエッジ環境を介してＡＦに接続されているため、報告がＵＥを介して届くエッジＡＦに示すように強化され得る。

【0170】

この機能性を可能にするために、ＵＥが、エッジへの監視報告のルーティングをサポートすることを示すことが提案されている。サポートの指示は、様々な手順中に、例えば、コアネットワークに登録するときに、ＰＤＵセッション確立手順の一部として提供され得る。ネットワーク（すなわち、ＡＭＦ）は、このインジケータを使用して、監視報告をＵＥに送信することが許容されるかどうかを決定し得る。

【0171】

この機能性を可能にするために、コアネットワークがＵＥにエッジ監視ルーティングポリシー（Edge Monitoring Routing Policy、ＥＭＲＰ）を提供することも提案されている。ＵＥは、ＥＭＲＰを使用して監視報告を受信し、それらをＬＥＦにルーティングし得、次に、その情報を要求したエッジＡＦに露出させ得る。

【0172】

図１３Ａ～図１３Ｅは、ＵＥが監視報告をルーティングするためにそのサポートを通信することを可能にする、強化登録手順のコールフロー例を示す。図１３Ａ～図１３Ｅは、（３ＧＰＰ ＴＳ ２３．５０２、５Ｇシステムの手順、ステージ２、Ｖ１６．１．１（２０１９－０９）に記載されているように）一般的な登録手順を図示しており、ＵＥが、ＬＥＦに監視報告をルーティングするためにそのサポートを通信できるように強化されている。

【0173】

以下の強化は、ＵＥがＬＥＦへのルーティング監視報告をサポートすることを可能にするために、図１３Ａ～図１３Ｅに示される手順で提案されている。

【0174】

図１３Ａのステップ１では、ＵＥは、登録要求内のＬＥＦ報告能力インジケータを含み、コアネットワークに、ＵＥが、ＡＭＦから監視報告を受信することができ、ＬＥＦに監視報告を提供することができることを通知する。この登録要求は、ステップ３で、ＡＭＦに転送され得る。

【0175】

図１３Ｃのステップ１６では、ＡＭＦは、ＵＥのＡＭポリシー関連付けを確立するときに、ＰＣＦへのＬＥＦ報告能力インジケータを含む。ＰＣＦは、新しいエッジ監視ルーティングポリシー（ＥＭＲＰ）ポリシーを作成するか、又は既存のエッジ監視ルーティングポリシーを更新する。ポリシーを作成／更新するためにＰＣＦによって使用される情報は、ＵＥ位置、加入されたサービスエリア制限（ＵＤＭ情報に基づいてＡＭＦからの）を含み得る。ＰＣＦはまた、様々なＮＦ（例えば、ＡＭＦ、ＧＭＬＣ、ＵＤＭ）をクエリすることによって、ＵＥが有効にされた監視に関する情報を取得する。ＰＣＦは、ネットワーク構成又はポリシーの一部として、利用可能なＬＥＦに関する情報をプロビジョニングされ得る。ＥＭＲＰポリシーは、
ａ）ポリシーのための固有のＩＤを提供するポリシー識別子と、
ｂ）データネットワークを識別するＤＮＮであって、ＵＥが、所与のＬＥＦに監視報告をルーティングするときに接続されている、ＤＮＮと、
ｃ）ポリシーが適用されるＬＥＦのＩＰアドレス又はＦＱＤＮと、
ｄ）受信ＡＦのエンドポイント情報と関連付けられた通知エンドポイントと、
ｅ）どの測定値又はメッセージタイプが、ポリシーが適用されるＬＥＦに転送されるべきかを決定する測定値又はメッセージタイプの識別子（例えば、イベントＩＤ）と、
ｆ）ＬＥＦ情報のアプリケーション層レベルの露出のインジケータと、を含み得る。これは、アプリケーション層シグナリングを使用して、ＵＥがＬＥＦ情報をＡＦに送信することができるバイナリインジケータである。これは、接続するべきＬＥＦを発見するために、エッジにおいてＡＦをサポートするのに有用である。ＡＦは、一般に、集中型ＮＥＦに関する情報を事前にプロビジョニングされ得る。しかしながら、エッジ展開の急増によって、ＥＣＳＰがＭＮＯとは異なるときに、全てのＬＥＦに関する情報を事前にプロビジョニングすることは、実行可能ではない場合がある。代わりに、ＵＥは、受信されたＥＭＲＰに基づいて、アプリケーションレベルにおけるこの情報をＡＦに送信することができる。

【0176】

図１３Ｅのステップ２１では、ＥＭＲＰは、登録受諾メッセージでＵＥに返される。ステップ１で、ＵＥがＬＥＦ報告能力インジケータを含めなかった場合、ＡＭＦは、登録受諾メッセージにＬＥＦ報告を提供することを望むかどうかをＵＥに求め得る。

【0177】

ステップ２２では、ＵＥがＡＭＦによってそのＬＥＦ報告能力を提供するように求められた場合、ＵＥは、登録完了メッセージ内のＡＭＦにインジケータを返す。ＬＥＦ報告能力インジケータを受信すると、ＡＭＦは、ＥＭＲＰを生成及び送信するために、透過的なＵＥポリシー送達のためのＵＥ構成更新手順の実行をトリガし得る。ＥＭＲＰを受信した後、ＵＥは、ポリシーによって指定された監視報告をルーティングし、それらをＬＥＦに送信する。

【0178】

ＵＥは、あるいは、ＰＤＵセッション確立手順の一部として、ＬＥＦ報告能力インジケータを送信してもよい。このシナリオでは、ＵＥは、ＰＤＵセッション確立要求にインジケータを含むか、又はＰＤＵセッションを修正するときにこれを含む。ＳＭＦは、インジケータを受信し、それをＰＣＦに転送する。ＥＭＲＰは、ＰＣＦによって生成され、ＰＤＵセッション確立受諾応答でＵＥに返される。本方法を使用した既存のタイプのＡＭＦ監視報告の例は、ＵＥの到達可能性、位置報告、ダウンリンクデータ通知障害後の可用性などである。

【0179】

本方法を使用した既存のタイプのＰＣＦ監視報告の例は、アクセスタイプの変更、シグナリング経路状態、もはや（又は再び）満たされることができないＱｏＳターゲット、ＱｏＳ監視パラメータである。

【0180】

図８の中央コアネットワークで検出される別のイベントは、進行中のＰＤＵセッション（ＴＳ ２３．５０３セクション６．１．３．２２）のＱｏＳの変更である。この報告は、ＳＭＦ及びＮＡＳシグナリングを介して送信されることができる。

【0181】

エッジサーバに報告するための方法－エッジ展開されたＮＦイベントルーティングのための方法。図１４は、ローカルで展開されたＮＦからの最適化された報告経路の一例である。エッジでイベント（例えば、図１４のＳＭＦによるダウンリンク送達データ状態）が検出され、ＡＦがエッジにあるとき、エッジから離れない経路を介してＡＦに報告を送信することが効率的である。

【0182】

ローカルの展開（例えば、ＮＷＤＡＦ）で他のＮＦによって生成された報告については、ＰＣＦは、ローカルの展開に接続された全ての（又は一組の）ＵＥに適用可能であり、ローカルＳＭＦに提供されるエッジ監視ポリシー（ＥＭＰ）を生成し得る。ＥＭＰは、ＤＤＮ障害イベント後の可用性のために、他のＮＦ、例えば、ＵＤＭによって生成又は記憶され得る。ローカルＳＭＦに提供されるエッジ監視ポリシーは、
・ポリシーのための固有のＩＤを提供するポリシー識別子と、
・監視ポリシーが適用するＵＥを識別する方法を提供するＵＥ識別フィルタであって、フィルタが、例えば、ＩＰフィルタ又は加入相関ＩＤとして表現され得る、ＵＥ識別フィルタと、
・２つ以上の受信ＡＦを含み得る、受信ＡＦのエンドポイント情報と関連付けられた通知エンドポイントと、
・どの測定値又はメッセージタイプが、ポリシーが適用されるＬＥＦに転送されるべきかを決定する測定値又はメッセージタイプの識別子（例えば、ダウンリンク送達データ状態イベントＩＤ）と、
・ポリシーが適用するＬＥＦのアドレス（例えば、ＩＰアドレス）を含む通知パラメータであって、通知パラメータが、ＡＦに転送するイベント通知のための他の基準（例えば、時間窓）を含み得、そのような通知基準が、イベント監視を構成するために、及び通知ルーティングのためにローカルＳＭＦによって使用され得る、通知パラメータと、
・例えば、地理的エリア、特定のＬＡＤＮ情報などを示すことによって、どのローカルの展開が適用されるべきかを指定するポリシー適用性基準と、を含み得る。ポリシー適用性基準は、ポリシーを検証するか、又は監視を構成するにあたりローカルＳＭＦによって使用され得る。

【0183】

ローカルＳＭＦは、エッジ監視ポリシーを使用して、監視を構成する方法を決定し、監視報告を送信し得る。ローカルＳＭＦは、ローカルの展開（例えば、ＮＷＤＡＦ）に実装された他のＮＦを構成して、監視報告を提供し得る。この構成に基づいて、ＵＥ識別フィルタ及び測定又はメッセージタイプ識別子に基づくフィルタリングによって識別された報告が生成され、ポリシーによって示されるＬＥＦに送信される。ＬＥＦに対するローカルＳＭＦによって送信されるメッセージはまた、ポリシーによって提供された知エンドポイントも含み、これは、報告を転送する場所を決定するためにＬＥＦによって使用される。

【0184】

多くの場合、ローカルＮＦによって生成されたイベントを報告するために、既存のインターフェースを再利用することができる。例えば、ローカルＳＭＦは、Ｎ４インターフェースをローカルＵＰＦに使用してもよい。ローカルＵＰＦから、報告は、すでに提案されたインターフェース、すなわち、ローカルＵＰＦとＬＥＦとの間のＮｘインターフェース、及びＬＥＦと（Ｅ）ＡＦとの間のＮｙインターフェースを使用し得る。あるいは、新しいインターフェース又はＡＰＩを、ローカルＳＭＦとＬＥＦとの間に定義してもよい。別の代替例では、新しいサービスベースのインターフェースを、ローカルＳＭＦとＬＥＦとの間で定義してもよく、サービスベースのインターフェースのＡＰＩを使用して報告をＬＥＦに送信してもよい。新しいインターフェース／ＡＰＩ又はサービスベースのインターフェースはまた、他のローカルで展開されたＮＦ（例えば、ＮＷＤＡＦ）とＬＥＦとの間に定義され得る。

【図1A】

【図1B】

【図1C】

【図1D】

【図1E】

【図1F】

【図1G】

【図2】

【図3】

【図4A】

【図4B】

【図4C】

【図5A】

【図5B】

【図6A】

【図6B】

【図7】

【図8】

【図9】

【図11】

【図12】

【図13A】

【図13B】

【図13C】

【図13D】

【図13E】

【図14】

【図10】