JP7681024B2 - シームレスなエッジアプリケーションハンドオーバ - Google Patents

Description

（関連出願の相互参照）
本出願は、２０１９年１２月２０日に出願された「Ｓｅａｍｌｅｓｓ Ｅｄｇｅ Ａｐｐｌｉｃａｔｉｏｎ Ｈａｎｄｏｖｅｒ」と題する米国仮特許出願第６２／９５１，３７７号の利益を主張し、その内容は参照により本明細書に組み込まれる。

マシンツーマシン（Ｍ２Ｍ）、モノのインターネット（ＩｏＴ）、及びモノのウェブ（ＷｏＴ）のネットワークの展開には、例えば、Ｖ２Ｘ（車車間／路車間）サービスのための３ＧＰＰアプリケーション層サポート（３ＧＰＰ（登録商標） ＴＳ２３．２８６ ｖ１６．１．０）、Ｖ２Ｘサービスのためのアプリケーション層サポートへの拡張に関する３ＧＰＰ調査（３ＧＰＰ ＴＲ２３．７６４、ｖ０．２．０）、３ＧＰＰ、エッジアプリケーションを可能にするためのアプリケーションアーキテクチャに関する調査（３ＧＰＰ ＴＲ２３．７５８、ｖ１．０．０）、ｏｎｅＭ２Ｍ ３ＧＰＰインターワーキング（ｏｎｅＭ２Ｍ ＴＳ－００２６、ｖ４．２．０）、及びオープンモバイルアライアンス（ＯＭＡ）軽量マシンツーマシン（ＬＷＭ２Ｍ）プロトコルｖ１．１に説明されるものなど、多種多様なサーバ、ゲートウェイ、及びデバイスが包含され得る。

エッジアプリケーションハンドオーバクライアント（ＥＡＨＣ）機能は、以下の動作のうちの１又は複数を実行するＵＥ上でホストされ、システム内のエッジアプリケーションサーバ（ＥＡＳ）の異なるインスタンス間のハンドオーバを用いてＵＥ上のアプリケーションクライアント（ＡＣ）を支援することができる。

ＵＥ上のＥＡＨＣ機能は、新しい専用機能であってもよく、又は３ＧＰＰエッジイネーブラクライアント、３ＧＰＰ Ｖ２Ｘアプリケーションイネーブラクライアント、ｏｎｅＭ２Ｍ共通サービスエンティティ（ＣＳＥ）、ｏｎｅＭ２Ｍ ＡＥ、若しくはＬＷＭ２Ｍクライアントなどの既存の機能のサブ機能であってもよい。

ＥＡＨＣは、ＥＡＨポリシーで構成される能力をサポートすることができる。ＥＡＨポリシーは、ＥＡＨＣがどのＥＡＨ動作を実行すべきか、及びどの条件下でこれらの動作を実行すべきかを判定するために使用される基準を含み得る。ＥＡＨポリシーは、以下を条件とするルールを含み得る。
・要求されたサービスの種類
・ユーザ、加入者、及び／又はＡＣ
・ネットワーク及び／又はサービスプロバイダ
・ＱｏＳ／ＱｏＥレベル
・ＵＥの位置（複数可）
・ＵＥの指定ルート（複数可）又は予想ルート（複数可）
・ＵＥが接続されるエッジ又はローカルエリアデータネットワークインスタンス
・エッジノードのステータス又は可用性
・要求されたサービスの展開ステータス

ＥＡＨＣは、ＵＥ上でホストされるＡＣとインターフェースする能力をサポートして、ＡＣが、それらの過去、現在、又は将来のアプリケーションサービス要件及びコンテキスト情報をＥＡＨＣと共有できるようにすることができる。ＥＡＨＣは、この情報をローカルに記憶し、処理して、ＥＡＳ間のＡＣのシームレスなエッジアプリケーションハンドオーバを支援することができる。ＥＡＨＣは、あるＥＡＳから別のＥＡＳへのＡＣのハンドオーバが必要かどうか／いつ必要かの判定に、このコンテキストを考慮することができる。ＥＡＨＣはまた、この情報をネットワーク内のＥＡＨＳと共有して、ＡＣがＥＡＳ間のシームレスなエッジアプリケーションハンドオーバを管理することを支援することができる。

ＵＥ上のＡＣとインターフェースすることによって、ＥＡＨＣはまた、ＡＣがＥＡＨを開始できる能力をサポートすることができる。例えば、ＡＣが、ＥＡＳから受信しているサービスのレベルがその要件を満たしていないことを検出した場合、ＡＣは、ＥＡＨＣへの要求を介してＥＡＨを開始してもよい。ＥＡＨＣは、かかる要求をＡＣから受信し、それらの代わりにＥＡＨ動作を実行することによってＡＣを支援することができる。

ＥＡＨＣは、ＡＣ、ＥＡＳ、及びＡＣとＥＡＳとを相互接続するネットワーク（複数可）に関するサービス要件及びコンテキスト情報を分析する能力をサポートすることができる。この分析及びＥＡＨポリシーに基づいて、ＥＡＨＣは、ＥＡＨが必要かどうか／いつ必要かを判定することができる。ＥＡＨＣは、ＡＣをトリガしてＥＡＨ動作を実行することができる。代替的に、ＥＡＨＣは、ＡＣの代わりにＥＡＨ動作を実行して、ＥＡＨの実行を支援することができる。

ＥＡＨＣは、ＵＥ上でホストされる全てのＡＣのサービス要件及びコンテキスト情報に関与し得るので、ＥＡＨＣは、この情報をアグリゲートして、ＵＥ上の全てのＡＣにわたって最適化されたＥＡＨ決定を行うことができる。例えば、ネットワーク中の単一のエッジノードが、ＵＥ上の異なるＡＣによって必要とされる全てのＥＡＳをサポートする場合、ＥＡＨＣは、ＵＥがより効率的な方法で動作し得るために、この単一のエッジノード上でホストされるＥＡＳをＡＣに使用させるＥＡＨ動作が望ましいと判定してもよい（例えば、ＵＥは、単一のエッジノードへの単一のＰＤＵセッションのみを必要とする）。

ＥＡＨＣは、ネットワーク内の１又は複数のＥＡＨＳに要求を発行して、それらにＥＡＨ動作を支援させることができる。要求の１つのタイプには、ＵＥの現在の近傍内（例えば、同じＬＡＤＮ内）にあり、ハンドオーバされるＡＣのための最良の候補ＥＡＳである利用可能なＥＡＳに関する情報を取得するための要求が含まれ得る。

ＥＡＨＣは、ネットワーク内のＥＡＨＳにサブスクリプション要求（複数可）を発行して、ＥＡＨＳから通知を受信することができる。サブスクリプションの１つのタイプは、ＡＣがあるＥＡＳから別のＥＡＳにハンドオフされるべきであるとＥＡＨＳが判定した場合／判定したときに通知を受信し得ることである。

ＥＡＨＳへのサブスクリプション要求に基づいて、ＥＡＨＣは、ＥＡＨＳから通知を受信することができる。通知の１つのタイプは、１又は複数の指定されたＡＣのためのＥＡＨ動作を実行するためのＥＡＨＣへのトリガであってもよい。

ＥＡＨＣは、ＥＡＨが発生したときにＥＡＳ ＦＱＤＮ解決支援動作を実行することができる。ＥＡＨがＡＣに及ぼす影響を最小限に抑え、ＥＡＨが発生する前後にＡＣが同じＥＡＳ ＦＱＤＮを使用し続けることを可能にするために、ＥＡＨＣは、ＡＣの代わりにＥＡＳ ＦＱＤＮ解決動作を実行することができる。これにより、ＥＡＨが発生した後であっても、ＡＣが同じＥＡＳ ＦＱＤＮを使用してＥＡＳと通信できるようになる。したがって、ＡＣは、ＥＡＨが発生した後に陳腐化する可能性がある、下位レベルのＥＡＳ窓口（ｐｏｉｎｔ－ｏｆ－ｃｏｎｔａｃｔ）情報（例えば、ＩＰアドレス、ポート、ＵＲＩ）を管理する負担を負わない。代わりに、ＥＡＨＣは、ＡＣに代わってこの負担を処理することができる。

ＥＡＨＣは、ＡＣの代わりに、ＥＡＨ認識方式でセキュリティセッションの確立及び切断を実行することができる。これらの動作は、ＥＡＨＣがＥＡＨをトリガするときに、又はＥＡＨＣがＡＣ若しくはＥＡＨＳから受信するＥＡＨ要求に応答して、ＥＡＨＣによって実行することができる。

ＥＡＨＣは、ＥＡＨ中にＥＡＳ間のアプリケーションの状態同期又は移行をトリガ及び監視し、状態同期又は移行のステータスに基づいて、ＥＡＨが成功したか、又は別のＥＡＨが必要とされているかを判定することができる。

ＥＡＨＣは、ＥＡＨ動作（例えば、ＤＮＳルックアップ結果のリフレッシュ、状態情報の新しいＥＡＳへの移行など）が実行されている間に、ＡＣからＥＡＳへの発信要求をバッファリングすることができる。ＥＡＨ動作が完了し、新しいＥＡＳがアクセス可能になると、ＥＡＨＣは、これらの要求を処理のために新しいＥＡＳに転送することができる。

エッジアプリケーションハンドオーバサーバ（ＥＡＨＳ）機能は、以下の動作のうちの１又は複数を実行して、システム内のエッジアプリケーションサーバ（ＥＡＳ）の異なるインスタンス間のシームレスなハンドオーバを用いてＵＥ上でホストされるアプリケーションクライアント（ＡＣ）を支援することができる。

ＥＡＨＳは、Ｖ２Ｘアプリケーションイネーブラサーバ、ＳＥＡＬサーバ、エッジイネーブラサーバ、エッジデータネットワーク構成サーバ、ｏｎｅＭ２Ｍ ＣＳＥ、又はＬＷＭ２Ｍサーバなどの既存のＥＡＨＳのスタンドアロン機能又はサブ機能であってもよい。

ＥＡＨＳは、ＥＡＨポリシーで構成される能力をサポートすることができる。ＥＡＨポリシーは、ＥＡＨＳがどのＥＡＨ動作を実行すべきか、及びどの条件下でこれらの動作を実行すべきかを判定するために使用されるルールを含み得る。ＥＡＨポリシーは、以下を条件とするルールを含み得る。
・要求されたサービスの種類
・ユーザ、加入者、及び／又はＡＣ
・ネットワーク及び／又はサービスプロバイダ
・ＱｏＳ／ＱｏＥレベル
・ＵＥの位置（複数可）
・ＵＥの指定ルート（複数可）又は予想ルート（複数可）
・ＵＥが接続されるエッジ又はローカルエリアデータネットワークインスタンス
・エッジノードのステータス又は可用性
・要求されたサービスの展開ステータス

ＥＡＨＳポリシールールは、ＵＥの現在の位置、ＵＥの計画ルート又は予想ルート、ネットワークに関係するステータス情報（例えば、輻輳レベル）などの情報に関係するコンテキスト情報を条件とし得る。

ＥＡＨＳは、３ＧＰＰシステム内の種々のエンティティとインターフェースし、これらのエンティティからコンテキスト情報を受信することができ、該エンティティには、コアネットワーク機能、アプリケーションクライアント、エッジイネーブラクライアント、エッジアプリケーションハンドオーバクライアント、Ｖ２Ｘアプリケーションイネーブラサーバ、ＳＥＡＬサーバ、エッジイネーブラサーバ、エッジデータネットワーク構成サーバ、ｏｎｅＭ２Ｍ ＣＳＥ、又はＬＷＭ２Ｍサーバが含まれるが、これらに限定されない。

ＥＡＨポリシーに基づいて、ＥＡＨＣは、システム内のエンティティからのコンテキスト情報及びサービス要件を分析し、ＥＡＨが必要かどうか／いつ必要かを判定することができる。ＥＡＨＳは、ＥＡＨＣをトリガして、ＡＣの代わりにＥＡＨ動作を実行し、ＥＡＨＣがＥＡＨを実行することを支援することができる。

ＥＡＨＳは、ＵＥ上でホストされるＥＡＨＣからサブスクリプション要求（複数可）を受信して、ＥＡＨＳから通知を受信することができる。サブスクリプションの１つのタイプは、ＡＣがあるＥＡＳから別のＥＡＳにハンドオフされるべきであるとＥＡＨＳが判定した場合／判定したときに通知を受信し得ることである。

ＥＡＨＣからのサブスクリプション要求に基づいて、ＥＡＨＳは、通知をＥＡＨＣに送信することができる。通知の１つのタイプは、１又は複数の指定されたＡＣのためのＥＡＨ動作を実行するためのＥＡＨＣへのトリガであってもよい。

ＥＡＨＳは、システム内の管理機能（複数可）とインターフェースして、１又は複数の指定されたタイプのＥＡＳをホストする（又はホストすることができる）利用可能なエッジノードを照会及び発見することができる。

ＥＡＨＳは更に、指定されたＵＥに近接して位置し、かつ／又はＵＥの予想ルートに沿って位置する、クエリされたエッジノードを指定することができる。

ＥＡＨポリシー及び関連するコンテキスト情報に基づいて、ＥＡＨＳは、エッジノード（例えば、ＡＣの現在位置に近接しているか、又は予想ルートに沿っているエッジノード）がＥＡＳ管理動作の実行を必要かどうか／いつ必要かを判定することができる。

ＥＡＨＳは、システム内の管理機能（複数可）とインターフェースして、利用可能なエッジノード（例えば、ＡＣの現在位置に近接しているか、又は予想ルートに沿っているエッジノード）上のＥＡＳの展開及びインストールされたＥＡＳのインスタンスを管理することができる。

ＥＡＨＳは、ＥＡＨ関連コンテキスト情報を共有することによって、かつ／又は管理機能（複数可）によって必要とされるＥＡＨを実行することによって、システム内の管理機能（複数可）を支援することができる。

ＥＡＨＳは、システム内の管理機能（複数可）がサービスプロバイダと相互作用して管理動作（例えば、新しいＥＡＳの展開、ＥＡＳのインストール／アクティブ化）をトリガすることを支援することができる。ＥＡＨＳは、３ＧＰＰネットワーク機能とインターフェースして、ＵＥ上のＡＣと、ＵＥの現在位置に近接した、又は予想ルートに沿ったＥＡＳとの間の３ＧＰＰネットワーク（例えば、ＱｏＳセッション）における接続性セントリックリソースを構成及び予約することができる。

ＥＡＨＳは、ＥＡＨＣに別のＤＮＳルックアップを実行させることによって、指定されたＥＡＳ ＦＱＤＮに対するキャッシュされたＤＮＳルックアップ結果をリフレッシュするようにＥＡＨＣに命令する要求を、ＥＡＨＣに送信することができる。この要求はまた、更新されたＤＮＳサーバ窓口情報をＥＡＨＣに提供することによって、新しいＤＮＳサーバに切り替えてルックアップを実行するようにＥＡＨＣに命令することができる。ＥＡＨＣに要求を発行する前に、ＥＡＨＳは、まず、ＥＡＳ ＦＱＤＮが異なるＥＡＳにマッピングされるように、ＤＮＳサーバのＤＮＳレコード内に記憶されたＥＡＳ窓口情報の更新を開始することができる。

新しいＥＡＳへのＡＣのハンドオーバが発生すると、ＥＡＨＳは、ＥＡＨＳとＥＡＳとの間に存在する安全な通信セッションを介して、ＡＣの資格情報を新しいＥＡＳと共有することができる。ＥＡＨＳはまた、ＥＡＨＳとＥＡＨＣとの間に存在する安全な通信セッションを介して、ＥＡＳの資格情報をＥＡＨＣと共有することができる。このプロセスの間、ＥＡＨＳは、新しい資格情報／更新された資格情報が必要とされる場合、ネットワーク内のセキュリティ機能と通信することもできる。

ＥＡＨが発生すると、ＥＡＨＳは、互いにハンドオフに関与するＥＡＳが、アプリケーション状態の安全な同期／移行など、ハンドオフ動作を安全に実行できるように、信頼関係の確立を支援することができる。新しいＥＡＳへのＡＣのハンドオーバが発生すると、ＥＡＨＳは、古いＥＡＳの資格情報を新しいＥＡＳと共有することができ、逆もまた同様である。

ＥＡＨが発生すると、ＥＡＨＳは、ＥＡＨ中にＥＡＳ間で発生するアプリケーションの状態同期又は移行の動作をトリガ及び監視することができる。アプリケーションの状態同期又は移行のステータスに基づいて、ＥＡＨＳは、ＥＡＨが成功したか、又は別のＥＡＨが必要とされるかを判定することができる。

コンテキスト情報を使用して、予測ルートがＥＡＨＳによって計算され、次いで、この予測ルートを使用して、ＵＥ上でホストされるＡＣ（複数可）がハンドオフされる次のＥＡＳ（複数可）を選択することができる。ＥＡＨＳは、ルートによって定義される異なるウェイポイントに対するＵＥ（複数可）の現在の位置を監視し、ルートに沿ったＵＥの移動並びに任意の予期せぬ逸脱を追跡することができる。

ＥＡＨＳは、１又は複数のＵＥについての予想ルート情報を３ＧＰＰネットワークと共有することができ、それにより、ネットワークは、ルートに沿って移動している間にＵＥ（複数可）の要件（例えば、ＱｏＳ）が満たされることを保証するように、そのネットワークリソースを構成及び最適化することができる。

ＥＡＨＳは、３ＧＰＰネットワークがその代わりに予想ルートに沿ったＵＥ（複数可）の移動を追跡することと、ＵＥ（複数可）がルートに沿った指定されたウェイポイントにいつ到着するか、又はＵＥがルートからいつ逸脱するかの通知など、ルートに沿ったＵＥの移動に関する通知を送信することと、を要求することができる。

この発明の概要は、以下の発明を実施するための形態において更に説明される概念の選択を簡略化された形態で紹介するために提供される。この発明の概要は、特許請求される主題の主要な特徴又は本質的な特徴を特定することを意図するものではなく、特許請求される主題の範囲を限定するために使用されることを意図するものでもない。更に、特許請求される主題は、本開示のいずれかの部分に記載されるいずれか又は全ての欠点を解決する限定に限定されない。

より詳細な理解は、添付の図面と併せて例として与えられる以下の説明から得ることができる。
図１は、ユーザ機器（ＵＥ）上のＶ２Ｘアプリケーションクライアントによるエッジ及びクラウドＶ２Ｘアプリケーションサーバの使用の一例のブロック図である。 図２は、エッジアプリケーションを可能にするための例示的な３ＧＰＰアーキテクチャのブロック図である。 図３は、Ｖ２Ｘアプリケーションを可能にするための例示的な３ＧＰＰ定義アーキテクチャのブロック図である。ＴＳ２３．２８６を参照されたい。 図４は、サービス層をサポートする例示的なプロトコルスタックを示す。 図５は、種々のタイプの接続されたネットワークノード上に展開される例示的なＩｏＴサービス層（ＳＬ）のブロック図である。 図６は、例示的なエッジアプリケーションハンドオーバクライアント機能及びエッジアプリケーションハンドオーバサーバ機能のブロック図である。 図７は、例示的なＩＥＡＨＣ－ＡＣ機能のコールフローである。 図８は、例示的なＩＥＡＨＳ－ＥＡＳ機能のコールフローである。 図９は、例示的なＩＥＡＨＳ－ＥＡＨＣ機能のコールフローである。 図１０は、例示的なＩＥＡＨＳ－３ＧＰＰ機能のコールフローである。 図１１は、例示的なＩＥＡＨＳ－ＭＦ機能のコールフローである。 図１２は、例示的なＥＡＨポリシー機能のコールフローである。 図１３Ａは、例示的なＥＡＨ認識ＦＱＤＮ解決のコールフローを示す。 図１３Ｂは、例示的なＥＡＨ認識ＦＱＤＮ解決のコールフローを示す。 図１４Ａは、例示的なＥＡＨ認識セッションの切断及び確立のコールフローを示す。 図１４Ｂは、例示的なＥＡＨ認識セッションの切断及び確立のコールフローを示す。 図１５Ａは、例示的なＥＡＨ認識状態同期／移行のコールフローを示す。 図１５Ｂは、例示的なＥＡＨ認識状態同期／移行のコールフローを示す。 図１６Ａは、例示的なＥＡＨ認識要求バッファリングのコールフローを示す。 図１６Ｂは、例示的なＥＡＨ認識要求バッファリングのコールフローを示す。 図１７Ａは、例示的なＥＡＨ認識セッションＱｏＳ継続性のコールフローを示す。 図１７Ｂは、例示的なＥＡＨ認識セッションＱｏＳ継続性のコールフローを示す。 図１７Ｃは、例示的なＥＡＨ認識セッションＱｏＳ継続性のコールフローを示す。 図１８Ａは、ＥＡＨ認識管理手順の種々の例示的なシナリオのコールフローを示す。 図１８Ｂは、ＥＡＨ認識管理手順の種々の例示的なシナリオのコールフローを示す。 図１８Ｃは、ＥＡＨ認識管理手順の種々の例示的なシナリオのコールフローを示す。 図１９Ａは、ＥＡＨ認識エッジコンピューティングサービスプロバイダ相互作用の２つの例示的なシナリオのコールフローを示す。 図１９Ｂは、ＥＡＨ認識エッジコンピューティングサービスプロバイダ相互作用の２つの例示的なシナリオのコールフローを示す。 図２０Ａは、ルート支援型ＥＡＨの一例のコールフローを示す。 図２０Ｂは、ルート支援型ＥＡＨの一例のコールフローを示す。 図２１は、３ＧＰＰ ＳＡ６ ＥＤＧＥＡＰＰの例のブロック図である。 図２２は、３ＧＰＰ ＳＡ６ Ｖ２Ｘの例のブロック図である。 図２３は、ｏｎｅＭ２Ｍの例のブロック図である。 図２４は、ＬＷＭ２Ｍの例のブロック図である。 図２５は、ＥＡＨポリシーを構成するための例示的なグラフィカルユーザインターフェース（ＧＵＩ）を示す。 図２６Ａは、本明細書で説明及び請求される方法及び装置が具現化され得る、例示的な通信システムを示す。 図２６Ｂは、ワイヤレス通信のために構成された例示的な装置又はデバイスのブロック図である。 図２６Ｃは、例示的な無線アクセスネットワーク（ＲＡＮ）及びコアネットワークのシステム図である。 図２６Ｄは、別の例示的なＲＡＮ及びコアネットワークのシステム図である。 図２６Ｅは、別の例示的なＲＡＮ及びコアネットワークのシステム図である。 図２６Ｆは、例示的なコンピューティングシステムのブロック図である。 図２６Ｇは、別の例示的な通信システムのブロック図である。

附属書の表１は、本明細書で使用される選択された略語の説明を含む。表２は、選択された用語の説明を含む。

（エッジアプリケーションの展開）
アプリケーションサーバ（ＡＳ）をクラウドではなく３ＧＰＰシステムのエッジに展開することの利点として、これらのＡＳによって提供されるサービスにアクセスするアプリケーションクライアント（ＡＣ）に対するアクセスレイテンシの低減及び信頼性の向上が挙げられる。加えて、この展開モデルは、（例えば、ＡＣとＡＳとの間の局所化された通信を可能にすることによって）ネットワークにおける負荷を分散させ、輻輳レベルを低減できるようにし得るため、ネットワークのエッジにおいてＡＳを展開することで、ネットワークオペレータも利益を得ることができる。

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

性能向上（アクセスレイテンシの低減及び信頼性の向上など）のためのＶ２Ｘ ＡＣによってＶ２Ｘサービスにアクセスする方法として、クラウドを介してＶ２Ｘ ＡＳにアクセスするのではなく、車両により近接したシステム内のエッジネットワーク内に展開されるＶ２Ｘ ＡＳを介してアクセスすることが好ましい。エッジにおいてＶ２Ｘ ＡＳにアクセスした場合、車両内のＵＥ上でホストされるＶ２Ｘ ＡＣは、他の車両並びに道路及び交通の状態に関する、より適時的で信頼できる情報を利用することができる。その結果、車両はより高い速度で走行でき、他の車両との距離を縮めることができる。車両はまた、安全性を犠牲にすることなく、より頻繁かつ効果的に車線を変更することができる。対照的に、クラウド内のＶ２Ｘ ＡＳにアクセスした場合、適時的な情報の可用性が低下するため、車両は、より保守的な動作モードに戻る必要がある。この結果、典型的には、車両の速度が低下し、他の車両との間の距離が長くなり、最適ではない車線変更をもたらす。

車両が道路を移動するにつれて、車両に最も近接した異なるエッジノード上でホストされるＶ２Ｘ ＡＳ間のＶ２Ｘ ＡＣのハンドオーバを調整する必要がある。同様に、エッジノード上でホストされるＶ２Ｘ ＡＳとクラウド内でホストされるＶ２Ｘ ＡＳとの間のＶ２Ｘ ＡＣのハンドオーバも、エッジネットワークカバレッジが車両の移動中にフェードイン及びフェードアウトする場合に対して調整する必要がある。これらのシナリオの全てについて、エッジノード上並びにクラウド内の両方でホストされるＡＳ間のシームレスな（例えば、低レイテンシで信頼できる）Ｖ２Ｘ ＡＣハンドオーバは、このタイプのＶ２Ｘのユースケース並びにＶ２Ｘと同様の要件を有する他のタイプのユースケースの展開を成功させるために重要かつ不可欠である。

（エッジアプリケーションを可能にするための３ＧＰＰアーキテクチャ）
図２は、エッジアプリケーションを可能にするための３ＧＰＰ定義アーキテクチャを示している。ＴＲ２３．７５８を参照されたい。エッジアプリケーションを可能にするためのフレームワークは、ＵＥ上でホストされるエッジイネーブラクライアント及びアプリケーションクライアント（複数可）と、エッジデータネットワーク内でホストされるエッジイネーブラサーバ及びエッジアプリケーションサーバ（複数可）とから構成される。エッジデータネットワーク構成サーバは、エッジイネーブラクライアント及びエッジイネーブラサーバを構成するために使用される。エッジイネーブラクライアント及びエッジイネーブラサーバは、それぞれ、アプリケーションクライアント及びアプリケーションサーバにエッジセントリック能力を提供する。エッジイネーブラサーバ及びエッジデータネットワーク構成サーバはまた、３ＧＰＰネットワークと相互作用することができる。

（Ｖ２Ｘアプリケーションを可能にするための３ＧＰＰアーキテクチャ）
図３は、Ｖ２Ｘアプリケーションを可能にするための３ＧＰＰ定義アーキテクチャを示している。ＴＳ２３．２８６を参照されたい。Ｖ２Ｘアプリケーションイネーブルメント（ＶＡＥ）層は、ＵＥ上でホストされるＶＡＥクライアントと、ネットワーク内でホストされるＶＡＥサーバとから構成される。ＶＡＥクライアント及びＶＡＥサーバは、ＶＡＥセントリック能力をＶ２Ｘアプリケーションクライアント及びＶ２Ｘアプリケーションサーバに提供する。ＶＡＥクライアント及びＶＡＥサーバは、それぞれ、サービスイネーブラアーキテクチャ層（ＳＥＡＬ）クライアント及びＳＥＡＬサーバによって提供される、より一般的な（例えば、非Ｖ２Ｘ特有の）サービスにインターフェースする。ＳＥＡＬサービスは、位置管理、グループ管理、構成管理、識別管理、鍵管理、及びネットワークリソース管理から構成される。

ＶＡＥサーバ及びＳＥＡＬサーバは、（例えば、Ｖ２、ＭＢ２、ｘＭＢ、Ｒｘ、及びＴ８などの３ＧＰＰ定義の基準点を介して）３ＧＰＰネットワークシステムと相互作用することもできる。

（ＩｏＴサービス層（ＳＬ））
ＩｏＴサービス層（ＳＬ）は、特に、ＩｏＴデバイス、ＩｏＴアプリケーション、及びＩｏＴデータのための付加価値サービスを提供することを対象とする技術である。近年、複数の業界標準団体が、インターネット／ウェブ、セルラー、企業、及びホームネットワークを用いた展開へのＩｏＴデバイス、アプリケーション、及びデータの統合に関連する課題に対処するために、ＩｏＴ ＳＬを開発している。これらには、例えば、ｏｎｅＭ２Ｍ、ＥＴＳＩ、ＯＣＦ、及びＯＭＡが含まれる。例えば、Ｖ２Ｘ（車車間／路車間）サービスのための３ＧＰＰアプリケーション層サポート（３ＧＰＰ ＴＳ２３．２８６ ｖ１６．１．０）、Ｖ２Ｘサービスのためのアプリケーション層サポートへの拡張に関する３ＧＰＰ調査（３ＧＰＰ ＴＲ２３．７６４、ｖ０．２．０）、ｏｎｅＭ２Ｍ ＴＲ２３．７５８、ｏｎｅＭ２Ｍ ３ＧＰＰインターワーキング（ｏｎｅＭ２Ｍ ＴＳ－００２６、ｖ４．２．０）、及びオープンモバイルアライアンス（ＯＭＡ）軽量マシンツーマシン（ＬＷＭ２Ｍ）プロトコルｖ１．１を参照されたい。

ＩｏＴ ＳＬは、アプリケーション及びデバイスに、ＩｏＴ指向能力の集合へのアクセスを提供することができる。一部の例には、セキュリティ、課金、データ管理、デバイス管理、発見、プロビジョニング、及び接続性管理が含まれる。これらの能力は、ＩｏＴ ＳＬによってサポートされるメッセージフォーマット、リソース構造、及びリソース表現を利用するＡＰＩを介して、デバイス及びアプリケーションに利用可能となる。

プロトコルスタックの観点から、ＳＬは、典型的には、アプリケーション層プロトコル上に位置し、それらがサポートするアプリケーションに付加価値サービスを提供する。したがって、ＳＬは、しばしば「ミドルウェア」サービスとして分類される。図４は、アプリケーションプロトコルとアプリケーションとの間の例示的なサービス層を示している。

展開の観点から、ＩｏＴ ＳＬは、図５に示されるように、ＩｏＴサーバ、ＩｏＴゲートウェイ、及びＩｏＴデバイスを含む、種々のタイプのネットワークノード上に展開することができる。

（例示的な課題）
３ＧＰＰは、５Ｇエッジアプリケーションアーキテクチャを定義する過程にある。例えば、ＴＲ２３．７５８を参照されたい。その動機は、ＵＥ上でホストされるアプリケーションクライアント（ＡＣ）に対する影響が最小限となるように、３ＧＰＰシステムのエッジノードにおいて種々のタイプのエッジアプリケーションサーバ（ＥＡＳ）を展開するための標準化されたフレームワークを定義することである。しかしながら、現在の５Ｇエッジアプリケーションアーキテクチャでは、ＥＡＳ間の頻繁なハンドオーバを必要とするＵＥ上でホストされるＡＣを伴うユースケースについて、あるＥＡＳから別のＥＡＳへのＡＣのシームレスなハンドオーバのための適切なサポートが未だ定義されていない。ここで、あるＥＡＳから別のＥＡＳへのＡＣのシームレスなハンドオーバとは、ＡＣが受けるサービスのレベルが維持され、顕著なサービス劣化又はサービス中断がないことを意味する。ハンドオーバの頻度は、ＡＣによって必要とされるサービスのレベル（例えば、レイテンシ）及び利用可能なＥＡＳのサービスカバレッジエリアによって決定される。

３ＧＰＰはまた、５Ｇ Ｖ２Ｘアプリケーションアーキテクチャを定義する過程にある。例えば、ＴＳ２３．２８６及びＴＲ２３．７６４を参照されたい。その動機は、３ＧＰＰシステム上で展開され得る標準化されたタイプのＶ２Ｘアプリケーションサーバ（例えば、隊列走行）を定義することである。しかしながら、現在の５Ｇ Ｖ２Ｘアプリケーションアーキテクチャでは、Ｖ２Ｘ ＥＡＳ間のＶ２Ｘ ＡＣのシームレスなハンドオーバのための適切なサポートが未だ定義されていない。

図１に示したＶ２Ｘの例などのユースケースをサポートするために、低レイテンシ及び高信頼性で、あるＥＡＳから別のＥＡＳにＡＣをシームレスに遷移させる（例えば、ハンドオーバする）能力が要求される。以下は、ＥＡＳ間のＡＣのシームレスなハンドオーバを達成することに関連する固有の課題の一部の概要である。これらの課題は、５Ｇエッジアプリケーションアーキテクチャ又は５Ｇ Ｖ２Ｘアプリケーションアーキテクチャによってまだ適切に対処されていない。

考慮すべき条件が多数あり、該条件は変動性が高く、システム内の複数の異なるエンティティから発生する可能性があるので、システム内のどのＥＡＳが所与の時点で使用するのに最適なものであるか、及びサービスの継続性が維持されることを保証するためにＡＣをこのＥＡＳの使用にいつ遷移させる必要があるかを判定することは、困難な場合がある。例えば、ＵＥ及びそれらのＡＣのステータス及びコンテキスト、ＵＥに近接するＥＡＳの正常性及び可用性、ＡＣとＥＡＳとを接続するネットワークの正常性及び可用性は全て、変動性が高いものである場合がある。どのＥＡＳを使用するか、及び異なるＥＡＳへのハンドオーバをいつ実行する必要があるかについて最適な決定を行うためにＡＣに依存することは、現実の展開において現実的ではなく、最適でもない。

ＥＡＳは、通常、システム内の異なるエッジノード上に展開される。各ＥＡＳは、それらが提供するサービス及びリソースのためのＩＰアドレス（複数可）、ポート（複数可）、及びＵＲＩ経路（複数可）を含む固有の窓口（複数可）を有する。所与のＥＡＳにアクセスするには、ＡＣがＥＡＳの窓口に要求を送信する必要がある。新しいＥＡＳへのハンドオーバが発生した場合／発生したときに、窓口情報の変更が発生する。ＥＡＳの窓口情報の変更は、ＡＣに重大な影響を及ぼす可能性がある。ＥＡＳの窓口情報が直接構成され、かつ／又はＡＣに符号化されることは珍しいことではない。したがって、ＥＡＳの窓口情報に変更が生じた場合、通常、ＡＣはこの変更を認識する必要がある。次いで、ＡＣは、古いＥＡＳとの通信を停止し、ＡＣと古いＥＡＳとの間の種々のタイプのセッション（例えば、ＰＤＵ、ＱｏＳ、セキュリティ）の切断を開始し、新しいＥＡＳとの間で対応するセッションを確立する必要がある。この種々のタイプのセッションの切断及び再確立は、ハンドオーバがシームレスに行われるように、新しいセッションが以前のセッションと整合した方法で構成されることを必要とする。これはまた、ＡＣに対してサービスの中断が生じないように適時に行われる必要がある。

ＡＣのサービス要件を依然として満たすことを保証しながらシステム内の限られたエッジノード及びエッジネットワークリソースの最適な使用量を保証することは、困難であり、これらは互いに直接競合する可能性がある。エッジノードは、通常、固定／制限された量のリソース（例えば、ＣＰＵ、メモリ、ストレージ）を用いて展開される。一般的にクラウドスケーリング技術を介して動的にスケーリングされる能力をサポートするクラウド展開とは異なり、通常、追加のリソースは、エッジノードのリソースが消費されると、容易に追加することができない。同様に、エッジノードは、典型的には、コアネットワークと比較して固定／制限された量のリソース（例えば、帯域幅）を有するエッジネットワーク（例えば、３ＧＰＰ ＬＡＤＮ）において展開される。これらの固定／制限された量のリソースを考慮すると、ＡＣがＥＡＳを必要とする時期よりかなり前には、静的な方法又は事前プロビジョニングされた方法でエッジノード上にＥＡＳを展開できない場合がある。このため、システム内のエッジノード上のＥＡＳをインテリジェントに管理して、エッジノード上のリソースを効率的に利用し、ＡＣのサービス要件を依然として満たすためには、より動的な方法が必要になる場合がある。例えば、エッジノード上にＥＡＳを展開するには、新しいＥＡＳのためにエッジノードリソースを解放するために、最初に、他のＥＡＳを削除又は無効にすることが必要になる場合がある。これには、どのＥＡＳがＡＣによってアクティブに使用され、どのＥＡＳがそうでないかを判定し、これにより、削除又は非アクティブ化の候補を決定することができるようにするために、システム内のエンティティ間の調整が必要になる場合がある。例えば、Ｖ２Ｘのユースケースには、典型的には、高い頻度でシステムの異なるエッジノードの近傍に出入りする車両上にホストされたＶ２Ｘ ＡＣが含まれる。これらのユースケースでは、Ｖ２Ｘ ＡＣは、それらがＶ２Ｘ ＥＡＳをホストするエッジノードに近接している間、Ｖ２Ｘ ＥＡＳを短時間使用する必要がある。車両及びそのＶ２Ｘ ＡＣが、Ｖ２Ｘ ＥＡＳをホストするエッジノードの近傍を離れ、他のエッジノードの近傍に入ると、必要なタイプ（複数可）のＶ２Ｘ ＥＡＳが、Ｖ２Ｘ ＡＣの近傍にある適切なエッジノード上で利用可能でアクセス可能であることを保証する方法が必要となる。これらの方法は、遷移がシームレスに、かつＶ２Ｘ ＡＣのサービス継続性を中断することなく行われるように、Ｖ２Ｘ ＥＡＳの必要なインスタンス（複数可）がインストールされ、実行され、Ｖ２Ｘ ＡＣによって安全にアクセス可能であることを保証する必要がある。車両が移動している速度及びそのＶ２Ｘ ＡＣのサービス要件（例えば、レイテンシ、信頼性など）によっては、システム内の異なるエッジノード上でホストされた異なるＶ２Ｘ ＥＡＳを管理してシームレスなエッジアプリケーションハンドオーバが行われ得るようにすることは、極めて困難であり得る。ＥＡＳの必要なインスタンスが、適切なエッジノード上で、適切な位置で、かつＡＣがそれらへのアクセスを必要とした場合の適切な時間ウィンドウ内で利用可能であることを保証することは、管理上困難なタスクであり得る。

（例示的な解決策）
図６は、エッジアプリケーションハンドオーバクライアント機能及びエッジアプリケーションハンドオーバサーバ機能を示している。本明細書では、既存の５Ｇエッジアプリケーションアーキテクチャ及び５Ｇ Ｖ２Ｘアプリケーションアーキテクチャの欠点に対処するための複数の概念が提示されており、該欠点は、３ＧＰＰシステムにおけるエッジアプリケーションサーバ（ＥＡＳ）及び／又はＶＡＥアプリケーションサーバなどの垂直アプリケーションサーバ間のＵＥアプリケーションクライアント（ＡＣ）のシームレスなハンドオーバの不十分なサポートに関連するものである。例えば、ＴＳ２３．２８６、ＴＲ２３．７５８、及びＴＲ２３．７６４を参照されたい。本明細書では、ＥＡＳは、明示的に指定されない限り、３ＧＰＰ ＳＡ６又は他の規格において定義されるＶＡＥアプリケーションサーバなどの垂直アプリケーションサーバを含み得るか、又はそれらを示唆し得る。

また、本明細書で説明されるＥＡＳ間のハンドオーバを用いてＡＣを支援する技術は、例えば、図１のユースケースのように、ＥＡＳとクラウドアプリケーションサーバとの間のハンドオーバを用いてＡＣを支援するために適用することができる。
（支援型エッジアプリケーションハンドオーバフレームワーク）
システム内のＥＡＳ間のＡＣのシームレスなハンドオーバ（例えば、ＵＥがあるＥＡＳの近傍から出て別のＥＡＳの近傍に入る場合）を可能にするために、ＡＣ及びＥＡＳに支援型ハンドオーバ機能を提供するエッジアプリケーションハンドオーバ（ＥＡＨ）フレームワークが説明される。ＥＡＨフレームワークは、図６に示すように、エッジアプリケーションハンドオーバクライアント（ＥＡＨＣ）及びエッジアプリケーションハンドオーバサーバ（ＥＡＨＳ）から構成される分散方式で展開することができる。

エッジアプリケーションハンドオーバクライアント（ＥＡＨＣ）及びエッジアプリケーションハンドオーバサーバ（ＥＡＨＳ）は、それぞれＩＥＡＨＣ－ＡＣ基準点、ＩＥＡＨＳ－ＥＡＳ基準点、ＩＥＡＨＳ－ＭＦ基準点、及びＩＥＡＨＳ－３ＧＰＰ基準点を介して示されるように、１又は複数のアプリケーションクライアント（ＡＣ）、エッジアプリケーションサーバ（ＥＡＳ）、管理機能（ＭＦ）、及び３ＧＰＰネットワークなど、システム内の種々の他のエンティティにインターフェースする。ＥＡＨＣ及びＥＡＨＳは、ＩＥＡＨＳ－ＥＡＨＣ基準点を介して互いにインターフェースすることもできる。

ＥＡＨＣ機能は、システム内のＵＥ上でホストされてもよく、ＥＡＨＳ機能と相互作用して、ＥＡＳ間のＡＣのシームレスなハンドオーバを支援する。ＥＡＨＣは、ＵＥ上のスタンドアロン機能として、又はエッジイネーブラクライアント若しくはＶ２Ｘアプリケーションイネーブラクライアントなどの既存の３ＧＰＰ定義機能のサブ機能として展開され得る。ＥＡＨＣはまた、ｏｎｅＭ２Ｍ ＣＳＥ又はＬＷＭ２Ｍクライアントなどの既存の非３ＧＰＰ定義機能のサブ機能として展開され得る。ＥＡＨＣは、エッジアプリケーションハンドオーバを支援するときに、システム内の種々の他の機能とインターフェースし、相互作用することができる。これは、ＥＡＨＣが情報を共有し、イベントを受信し、システム内の他の機能を含む動作を実行することを含み得る。この相互作用の更なる詳細は、本明細書の後続のセクションで提供される。

ＥＡＨＳ機能は、システム内のＵＥの外部に展開され得るように定義される。ＥＡＨＳは、システム内のスタンドアロン機能として、又は３ＧＰＰ Ｖ２Ｘアプリケーションイネーブラサーバ、ＳＥＡＬサーバ、エッジイネーブラサーバ、エッジデータネットワーク構成サーバ、若しくはＳＣＳ／ＡＳなどの既存の機能のサブ機能として展開され得る。ＥＡＨＳはまた、ｏｎｅＭ２Ｍ ＣＳＥ又はＬＷＭ２Ｍサーバなどの既存の非３ＧＰＰ定義機能のサブ機能として展開され得る。ＥＡＨＣは、ＥＡＨＳ機能と相互作用して、ＥＡＳ間のＡＣのシームレスなハンドオーバを支援する。ＥＡＨＳ機能は、エッジデータネットワーク内、クラウドネットワーク内、又は３ＧＰＰネットワーク内で展開され得る。ＥＡＨＳはまた、エッジアプリケーションハンドオーバを支援するときに、システム内の種々の他の機能とインターフェースし、相互作用することができる。これは、ＥＡＨＳが情報を共有し、イベントを受信し、システム内の他の機能を含む動作を実行することを含み得る。この相互作用の更なる詳細は、本明細書の後続のセクションで提供される。

管理機能（ＭＦ）機能は、システム内のＵＥの外部に展開され得るように定義される。ＭＦは、システム内のスタンドアロン機能として、又は３ＧＰＰエッジデータネットワーク構成サーバ若しくはＳＣＳ／ＡＳなどの既存の機能のサブ機能として展開され得る。ＭＦはまた、ｏｎｅＭ２Ｍ ＣＳＥ又はＬＷＭ２Ｍサーバなどの既存の非３ＧＰＰ定義機能のサブ機能として展開され得る。ＭＦは、ＥＡＨＳ機能と相互作用して、ＥＡＨＳの能力及びインスタンス化に関する情報を受信する。ＭＦはＥＡＨＣと相互作用して、ＥＡＨポリシーをＥＡＨＣに送信する。ＭＦ機能は、エッジデータネットワーク内、クラウドネットワーク内、又は３ＧＰＰネットワーク内で展開され得る。ＭＦはまた、エッジアプリケーションハンドオーバを支援するときに、システム内の種々の他の機能とインターフェースし、相互作用することができる。これは、ＭＦが情報を共有し、イベントを受信し、システム内の他の機能を含む動作を実行することを含み得る。この相互作用の更なる詳細は、本明細書の後続のセクションで提供される。

（支援型エッジアプリケーションハンドオーバの基準点）
（ＩＥＡＨＣ－ＡＣ基準点）
図７に示すように、ＥＡＨＣは、ＵＥ上でホストされるＡＣへの基準点（ＩＥＡＨＣ－ＡＣ）をサポートすることができる。ＩＥＡＨＣ－ＡＣを介して、ＥＡＨＣは、それ自体とＡＣとの間の種々のタイプのＥＡＨセントリック動作（例えば、附属書の表３に記載され、図７に示されるものなどであるが、これらに限定されない）をサポートすることができる。ＥＡＨ動作は、図示したシーケンスとは異なるシーケンスで実行されてもよく、動作は互いに独立して実行されてもよいことに留意されたい。

附属書の表３に定義された例示的なＩＥＡＨＣ－ＡＣ動作の追加の詳細を以下で説明する。

ＥＡＨＣは、ＡＣ、ＥＡＳ、及びＡＣとＥＡＳとを相互接続するネットワークから受信したサービス要件及びコンテキスト情報を（例えば、ＥＡＨポリシーに基づいて）分析する能力をサポートすることができる。この分析に基づいて、ＥＡＨＣは、ＥＡＨが必要かどうか／いつ必要かを判定することができる。次いで、ＥＡＨＣは、ＡＣをトリガしてＥＡＨを開始し得るか、又は代替的に、ＥＡＨＣは、ＡＣの代わりにＥＡＨ動作を実行して、ＥＡＨの実行を支援することができる。

ＥＡＨＣは、ＵＥ上でホストされる全てのＡＣのサービス要件及びコンテキスト情報に関与し得るので、ＥＡＨＣは、この情報をアグリゲートして、ＵＥ上の全てのＡＣにわたって最適化されたＥＡＨ決定を行う能力をサポートし得る。例えば、ネットワーク中の単一のエッジノードが、ＵＥ上の異なるＡＣによって必要とされる全てのＥＡＳをサポートする場合、ＥＡＨＣは、ＵＥがより効率的な方法で動作し得るために、この単一のエッジノード上でホストされるＥＡＳをＡＣに使用させるＥＡＨ動作が望ましいと判定してもよい（例えば、ＵＥは、単一のエッジノードへの単一のＰＤＵセッションのみを必要とする）。

ＥＡＨＣは、優先順位付け情報を受信することができる。優先順位付け情報は、ユーザインターフェース（例えば、グラフィカルユーザインターフェース）から取得することができる。優先順位付け情報は、アプリケーションクライアントの相対的重要性をＥＡＨＣに示すことができ、ＥＡＨＣは、どのエッジデータネットワーク及びＥＡＳに接続すべきかを判定するときに、この情報を使用することができる。例えば、ＥＡＨＣは、ハンドオーバアクションを実行せず、あるアプリケーションクライアントに接続性を失わせて、別のアプリケーションクライアントの接続を中断することを回避することを決定してもよい。代替的に、ＥＡＨＣは、ハンドオーバアクションを実行して、あるアプリケーションクライアントに接続性を失わせて、別のアプリケーションクライアントの接続を中断することを回避することを決定してもよい。

(ＩＥＡＨＳ－ＥＡＳ基準点)
図８に示すように、ＥＡＨＳは、基準点（ＩＥＡＨＳ－ＥＡＳ）をサポートして、システム内のＥＡＳと通信することができる。ＩＥＡＨＳ－ＥＡＳを介して、ＥＡＨＳは、それ自体とＥＡＳとの間の種々のタイプのＥＡＨセントリック動作（例えば、附属書の表４におけるものであるが、これに限定されない）をサポートすることができる。図８に示される動作は、図示のものとは異なる順序で実行されてもよく、動作は、他のものとは独立して実行されてもよいことに留意されたい。

ＩＥＡＨＳ－ＥＡＳ基準点は、限定はしないが、附属書の表４の動作などの動作をサポートすることができる。

(ＩＥＡＨＳ－ＥＡＨＣ基準点)
図９に示すように、ＥＡＨＣは、基準点（ＩＥＡＨＳ－ＥＡＨＣ）をサポートして、システム内の１又は複数のＥＡＨＳと通信することができる。例えば、ＥＡＨＣは、ＥＡＨＳがＡＣに代わってＥＡＨ動作を実行することでＥＡＨＣを支援できるように、ＥＡＨＳとインターフェースしてＡＣに関する情報をＥＡＨＳと共有する能力をサポートしてもよい。図９に示される動作は、図示のものとは異なる順序で実行されてもよく、一部の動作は、他のものとは独立して実行されてもよいことに留意されたい。

ＩＥＡＨＳ－ＥＡＨＣは、限定はしないが、附属書の表５の動作などの動作をサポートすることができる。

(ＩＥＡＨＳ－３ＧＰＰ基準点)
図１０は、ＩＥＡＨＳ－３ＧＰＰ機能を示している。図１０に示すように、ＥＡＨＳは、３ＧＰＰネットワーク及びそのそれぞれの機能（例えば、ＮＥＦ）と通信するために基準点（ＩＥＡＨＳ－３ＧＰＰ）をサポートすることができる。ＩＥＡＨＳ－３ＧＰＰを介して、ＥＡＨＳは、種々のタイプのＥＡＨセントリック動作を３ＧＰＰネットワークと交換することをサポートすることができる。例えば、ＥＡＨＳは、３ＧＰＰネットワークに要求を送信して、単一のＵＥ（例えば、車両）又はＵＥのグループ（例えば、車両の隊列）をトリガさせて、ＥＡＨＳがＵＥ（複数可）と同じ近傍にあると判定した特定のエッジデータネットワーク（例えば、３ＧＰＰ ＬＡＤＮ）に接続させてもよい。次いで、３ＧＰＰネットワークは、エッジデータネットワークに接続するようにＵＥ（複数可）をトリガすることができる。図１０に示される動作は、図示のものとは異なる順序で実行されてもよく、動作は、他のものとは独立して実行されてもよいことに留意されたい。ＩＥＡＨＳ－３ＧＰＰ基準点は、限定はしないが、附属書の表６の動作などの動作をサポートすることができる。

(ＩＥＡＨＳ－ＭＦ及びＩＥＡＨＣ－ＭＦ基準点)
図１１は、ＩＥＡＨＳ－ＭＦ機能を示している。図１１に示すように、ＥＡＨＳは、基準点（ＩＥＡＨＳ－ＭＦ）をサポートして、システム内の管理機能（ＭＦ）と通信することができる。システム内のＭＦは、システム内に展開されたＥＡＳを管理する責任を有し得る。例えば、システムのエッジネットワーク内のエッジノード上でホストされるＥＡＳのインストール／アンインストール、アクティブ化／非アクティブ化、構成／再構成である。ＩＥＡＨＳ－ＭＦを介して、ＥＡＨＳは、ＭＦとの通信をサポートして、ＥＡＳの管理を支援し、エッジアプリケーションハンドオーバがシームレスに行われることを保証することができる。例えば、ＥＡＨＳは、ＭＦにインターフェースして、ＵＥが接続したか、又は接続しようとしている特定のエッジネットワーク内のエッジノード上でＥＡＳがインストールされ、構成され、及び／又はアクティブ化されることを要求する能力をサポートしてもよい。ＭＦにインターフェースし、その管理を支援することによって、ＥＡＨＳは、ＵＥ上でホストされるＡＣが、ほとんど／全く中断なしに新しいＥＡＳに遷移できることを保証するのに役立ち得る。図１１に示される動作は、図示のものとは異なる順序で実行されてもよく、動作は、他のものとは独立して実行されてもよいことに留意されたい。ＩＥＡＨＳ－ＭＦ基準点は、限定はしないが、附属書の表７の動作などの動作をサポートすることができる。

加えて、附属書の図１１又は表７には示されていないが、ＥＡＨＣは、ＥＡＨポリシーを用いて構成されること、又はＩＥＡＨＣ－ＭＦ基準点上でＭＦを介してＥＡＨ関連の動作を実行するように命令されることをサポートすることができる。ＥＡＨＣはまた、ＩＥＡＨＣ－ＭＦ上でＥＡＨ関連の動作を実行するための要求をＭＦに発行することができる。

(支援型エッジアプリケーションハンドオーバ手順)
以下の副節では、ＥＡＨＣ及びＥＡＨＳがエッジアプリケーションハンドオーバを実行する際にＡＣ及びＥＡＳを支援できるようにする手順が定義される。これらの手順は、前述のＥＡＨＣ及びＥＡＨＳの基準点の各々によって定義される動作を活用する。

(ＥＡＨポリシー構成)
図１２は、ＥＡＨポリシー機能を示している。図１２の工程１ａ及び１ｂに示されるように、システム内のＥＡＨＳ及びＥＡＨＣの両方は、ＥＡＨポリシーを用いて構成することができる。ＥＡＨポリシーは、ＥＡＨＳ又はＥＡＨＣがどのＥＡＨ動作を実行すべきか、及びどの条件下でこれらの動作を実行すべきかを判定するために使用される基準を含み得る。これらのポリシーは、システム内のユーザ、コアネットワーク機能、アプリケーションクライアント、エッジイネーブラクライアント、エッジアプリケーションハンドオーバクライアント、Ｖ２Ｘアプリケーションイネーブラサーバ、ＳＥＡＬサーバ、エッジイネーブラサーバ、エッジデータネットワーク構成サーバ、及びＳＣＳ／ＡＳなどであるが、これらに限定されない、システム内の種々のエンティティによって構成されてもよい。これらのエンティティは、ＥＡＨＳ又はＥＡＨＣに要求を発行して、そのＥＡＨポリシーを構成することができる。代替的に、ＥＡＨＳ又はＥＡＨＣは、これらのエンティティからＥＡＨポリシーを取り出すか、又はこれらのエンティティに加入して、ＥＡＨポリシーへの変更が必要とされる場合／必要とされるときに通知を受信することができる（図１２には図示せず）。

ＥＡＨポリシーは、限定はしないが、表８において定義されているものなどのＥＡＨルールを含み得る。これらのルールは、ＥＡＨＳ又はＥＡＨＣによって記憶及び使用されて、どのＥＡＨ動作を実行するか、及びどの条件下でＥＡＨ動作を実行するかを制御することができる（図１２の工程２ａ及び２ｂ）。附属書の表８の情報は、ＥＡＳタイプ又はＥＡＳタイプごとに提供することができる。

ＥＡＨポリシールールは、システムにおいて利用可能な種々のタイプのＥＡＨ関連コンテキスト情報（例えば、附属書の表９において定義されるタイプであるが、これに限定されない）に対する依存性を有し得る。このコンテキスト情報は、限定はしないが、コアネットワーク機能、アプリケーションクライアント、エッジイネーブラクライアント、エッジアプリケーションハンドオーバクライアント、Ｖ２Ｘアプリケーションイネーブラサーバ、ＳＥＡＬサーバ、エッジイネーブラサーバ、エッジデータネットワーク構成サーバ、及びＳＣＳ／ＡＳなど、３ＧＰＰシステム内の種々のエンティティから生成されてもよい。図１２の工程３ａ及び３ｂに示されるように、これらのエンティティは、ＥＡＨＳ又はＥＡＨＣに要求を発行して、ＥＡＨ関連コンテキスト情報を共有することができる。代替的に、ＥＡＨＳ又はＥＡＨＣは、関心のあるコンテキスト情報が利用可能になる場合／利用可能になるときに、これらのエンティティからＥＡＨ関連コンテキストを取り出すか、又はこれらのエンティティに加入して通知を受信することができる（図１２には図示せず）。ＥＡＨ関連コンテキスト情報は、システム内のＥＡＨＳ及びＥＡＨＣに利用可能にされてもよく、それにより、ＥＡＨＳ及びＥＡＨＣは、どのＥＡＨ動作をどの条件下で実行するかを判定するために、ＥＡＨポリシー内で定義された指定されたルールとともにそれを評価することができる（図１２の工程４ａ及び４ｂ）。

(ＥＡＨ認識ＦＱＤＮ解決) ＡＣのためのＥＡＨの複雑さ及びオーバーヘッドを最小限に抑えるために、ＥＡＨＣ及びＥＡＨＳは、ＡＣが、ＥＡＨの前に使用していた同じＥＡＳ ＦＱＤＮをＥＡＨの後に使用し続けることを可能にする機能をサポートすることができる。この機能には、ＥＡＨＣ及びＥＡＨＳが、ＥＡＳの下位レベルの窓口情報（例えば、ＩＰアドレス、ポート、ＵＲＩ経路、識別子、セキュリティ資格情報、及び／又はサービス記述情報）を管理し、ＡＣの代わりにＥＡＳ ＦＱＤＮ解決動作を実行することが含まれる。そうすることで、ＥＡＨＣ及びＥＡＨＳは、これらの動作を実行する負担のＡＣを軽減することができ、又は更に、これらの動作が自身の代わりに実行されていることを認識するができる。

この機能は、ＥＡＨＣが拡張ＤＮＳクライアント機能をサポートすることを含んでおり、拡張ＤＮＳクライアント機能はまた、エッジアプリケーションハンドオーバがいつ行われるかを認識する。これにより、ＵＥが異なるエッジネットワークに／異なるエッジネットワークから接続し、ランタイムエッジアプリケーションハンドオーバが発生している場合であっても、ＥＡＨＣは、ＥＡＳ ＦＱＤＮを正しいＥＡＳ窓口に正常に解決することができる。ＥＡＨＣはまた、ＡＣがＥＡＨＣに要求を発行して、ＥＡＳ ＦＱＤＮをそれらの代わりに解決し、必要に応じてＥＡＳ窓口情報を受信できるようにするＡＰＩをサポートしてもよい。

図１３Ａ及び図１３Ｂは、ＥＡＨ認識ＦＱＤＮ解決機能の一例を示している。ＥＡＨＣがこの機能を実行できるようにするために、ＥＡＨＣは、ＤＮＳサーバ（複数可）のための窓口情報を用いて構成される能力をサポートすることができる（図１３Ａの工程１）。ＤＮＳサーバ（複数可）は、ＡＣに現在利用可能なＥＡＳ（例えば、ＥＡＳ＃１）のＤＮＳレコードをホストする。ＵＥが異なるネットワークドメイン（コア又はエッジネットワークドメインのいずれか）に接続した場合、ＵＥは、ＤＮＳサーバ（複数可）のこの窓口情報を用いて構成することができる。このＤＮＳサーバ窓口情報を用いてＵＥのＥＡＨＣを構成するエンティティは、工程１に示されるようなＥＡＨＳであってもよいし、エッジデータネットワーク構成サーバ、ＳＥＡＬサーバ、エッジイネーブラサーバ、又はＳＣＳ／ＡＳなどであるがこれらに限定されない、システム内の別のエンティティであってもよい。工程１において、複数のＤＮＳサーバ窓口が、ＵＥに提供され得る。各窓口は、Ｓ－ＮＳＳＡＩ及びＤＮＮに関連付けられ得る。ＥＡＳは、特定のネットワークスライスに関連付けることができる。例えば、ＵＥは、特定のネットワークスライスに関連付けられた特定の３ＧＰＰ ＰＤＵセッションを使用して、所与のＥＡＳにアクセスする。このため、所与のＤＮＳサーバは、特定のエッジデータネットワーク及び／又は特定の３ＧＰＰネットワークスライスに関連付けられ得る。ＳＭＦは、ＰＤＵセッション確立中にＤＮＳサーバ窓口をＵＥに提供することができることに留意されたい。ＥＡＨＣは、エッジデータネットワーク構成サーバ、ＳＥＡＬサーバ、エッジイネーブラサーバ、又はＳＣＳ／ＡＳによってプロビジョニングされたＤＮＳサーバ窓口に、より高い優先順位を与え、エッジデータネットワーク構成サーバ、ＳＥＡＬサーバ、エッジイネーブラサーバ、又はＳＣＳ／ＡＳによってプロビジョニングされた窓口が、ＦＱＤＮを解決することができない場合に、ＳＭＦによって提供されたＤＮＳサーバ窓口のみを使用することができる。

ＥＡＨＣが１又は複数のＤＮＳサーバの窓口情報で構成されると、ＥＡＨＣは、ＥＡＳのＦＱＤＮを解決するために、ＡＣからの要求を処理することができる（工程２）。ＥＡＨＣが所与のＥＡＳ ＦＱＤＮをターゲットとする要求を初めて受信するとき、ＥＡＨＣは、構成されたＤＮＳサーバに対してＤＮＳルックアップを実行して（工程３）、ＦＱＤＮを適切なＥＡＳ窓口情報へ解決することができる（工程４）。ＥＡＨＣは、ＥＡＳ窓口情報をＡＣに返すことができる（工程５）。ＥＡＨＣは、同じＡＣから同じＥＡＳへの後続の要求で別のＤＮＳルックアップを反復する必要がないように（工程８及び９）、窓口情報をキャッシュすることもできる（工程６）。次いで、ＡＣは、ＥＡＳ窓口情報を使用して、ＥＡＳにアクセスすることができる（工程７及び１０）。

１又は複数のＡＣのためのＥＡＨが、ＡＣ、ＥＡＨＣ、又はＥＡＨＳによってトリガされる場合／トリガされるとき（工程１１）、ＥＡＨＣは、ＥＡＨの発生を検出し、影響を受けるＡＣ及びＥＡＳを判定し（工程１２ａ）、これらの影響を受けるＡＣ及びＥＡＳのための任意のキャッシュされたＤＮＳルックアップ結果を無効／陳腐化としてマーキングして、使用されないようにすることができる（工程１２ｂ）。加えて、ＥＡＨＣは、ＵＥが、異なるエッジネットワークに接続され、該エッジネットワークがＥＡＳ ＦＱＤＮを異なる窓口にバインドする異なるＤＮＳサーバ（複数可）を有する場合、更新されたＤＮＳサーバ窓口（複数可）を受信することもできる（図１３Ｂの工程１３ａ）。代替的に、同じエッジネットワーク内の異なるＥＡＳへのハンドオーバが発生した場合、ＥＡＨＳは、ＥＡＳ ＦＱＤＮ窓口情報を更新して古いＥＡＳの代わりにアクセスされるべき新しいＥＡＳが反映されるように、代わりにＤＮＳサーバ上のＤＮＳサーバレコードを更新することができる（工程１３ｂ）。更新されたＤＮＳ情報は、ＥＡＨ通知要求内でＥＡＨＳからＥＡＨＣに送信されてもよい。ＤＮＳサーバを更新した後、ＥＡＨＳは、更新されたＤＮＳサーバ（複数可）に関する任意のキャッシュされたＤＮＳ結果をリフレッシュしたことをＥＡＨＣ（複数可）が認識するように、ＥＡＨＣ（複数可）に通知することができる（工程１３ｃ）。ＥＡＨに続いて、ＥＡＨＣがＥＡＳ ＦＱＤＮを解決するためにＡＣから次の要求を受信した場合（工程１４）、ＥＡＨＣは、新しいＤＮＳルックアップを実行し、最新のＥＡＳ窓口情報を取得することができる（工程１５及び１６）。ＥＡＨＣは、この窓口情報をＡＣに返すとともに、別のＥＡＨがトリガされる場合／トリガされるときまでそれをキャッシュすることができる（工程１７及び１８）。次いで、ＡＣは、ＥＡＳ窓口情報を使用して、新しいＥＡＳにアクセスすることができる（工程１９）。

代替的に、図１３Ａ及び図１３Ｂには示されていないが、ＡＣがＥＡＳ ＦＱＤＮ解決要求をＥＡＨＣに発行してＥＡＨＣにＥＡＳ窓口情報をＡＣに返させるのではなく、ＥＡＨＣは、代わりに、ＡＣとＥＡＳとの間のメッセージプロキシとして機能することができる。プロキシとして機能する場合、ＡＣは、ＥＡＳをターゲットとするその要求をＥＡＨＣに転送して、その代わりにプロキシを行うことができる。その要求内で、ＡＣは、ＥＡＳについて解決された窓口情報ではなく、ターゲットＥＡＳのＦＱＤＮを使用することができる。ＡＣから要求を受信すると、ＥＡＨＣは、次いで、ＥＡＨ認識方式でＥＡＳ ＦＱＤＮ解決を実行し、要求をＥＡＳに転送する前に、ＦＱＤＮを適切なＥＡＳ窓口情報で置き換えることができる。そうすることにより、ＡＣは、ＥＡＳ窓口情報を認識する必要がなくなる。ＥＡＨＣは、ＥＡＳ窓口情報をＡＣから隠し、ＡＣの代わりにＥＡＳ ＦＱＤＮ解決を実行することができる。

(ＥＡＨ認識セキュリティセッションの切断及び確立)
ユースケースの要件に応じて、ＡＣとＥＡＳとの間の安全な通信が必要とされる場合がある。安全な通信が必要とされる場合、ＡＣ及びＥＡＳは、ＡＣ及びＥＡＳが認証し、互いに安全で信頼できる通信セッションを確立する（例えば、ＴＬＳなどのセキュリティプロトコルを使用して双方向認証ハンドシェイクを実行する）ことを可能にするために必要な、適切な資格情報を用いて構成する必要がある。システム内の異なるＥＡＳ間のＡＣのシームレスなハンドオーバを可能にするために、ＥＡＨＣ及びＥＡＨＳは、ＡＣ及びＥＡＳに資格情報の管理に役立つ支援を提供して、ＡＣとＥＡＳとの間の安全な通信セッションのセットアップ及び切断を支援することができる。そうすることで、ＥＡＨＣ及びＥＡＨＳは、ＡＣ及びＥＡＳが自身のこれらの動作を実行する負担を軽減することができる。

図１４Ａ及び図１４Ｂは、エッジアプリケーションハンドオーバが発生した場合に、ＥＡＨＣ及びＥＡＨＳが、ＡＣとＥＡＳとの間の安全な通信セッションのセットアップ及び切断を支援することを含む機能の一例を示している。ＥＡＨＣ及びＥＡＨＳは、ＡＣ及びＥＡＨＣ、ＥＡＨＣ及びＥＡＨＳ、ＥＡＳ及びＥＡＨＳ、又はＥＡＨＳ及びネットワーク内のセキュリティ機能（例えば、ＡＡＡサーバ、認証局など）など、システム内の異なるペアワイズエンティティ間で確立された既存の信頼関係を活用することができる。これらのペアワイズ信頼関係は、既存の周知のセキュリティ方法（例えば、ＴＬＳセッション）を使用して確立することができる。

これらのペアワイズ信頼関係が確立されると、ＥＡＨＣ及びＥＡＨＳは、これらのペアワイズ信頼関係の上に追加のセキュリティ機能を重ねることができる。この追加の機能は、ＡＣがシステム内のＥＡＳとのランタイム信頼関係を確立することを支援し、ＥＡＳが他のＥＡＳとのランタイム信頼関係を確立することを支援することができる（例えば、ＥＡＳがエッジアプリケーションハンドオーバ中にエッジアプリケーション状態を安全に同期又は移行できるようにする）。ＡＣとＥＡＳとの間でセキュリティ資格情報を管理するオーバーヘッドは高くなる可能性があるため、この機能は、頻繁なエッジアプリケーションハンドオーバが発生する場合に特に有用であり得る。

ＥＡＨＣ及びＥＡＨＳは、エッジアプリケーションハンドオーバがいつ発生するかの認識、及び個々のＡＣ及びＥＡＳとの信頼関係（図１４Ａの工程０）を活用して、ＥＡＨが発生した場合／発生したときに、資格情報管理動作を実行して、互いの公開資格情報（例えば、ＰＳＫ、証明書など）を用いてＡＣ及びＥＡＳを安全に構成することができる。ＡＣは、ＥＡＨＣとＡＣとの間に存在する安全な通信セッションを介して、それらの資格情報をＥＡＨＣに安全に（例えば、暗号化された方法で）渡すことができる（工程１）。同様に、ＥＡＳは、ＥＡＨＳとＥＡＳとの間に存在する安全な通信セッションを介して、それらの資格情報をＥＡＨＳに安全に渡すことができる（工程２）。ＡＣの新しいＥＡＳへのハンドオーバが発生すると（工程３）、ＥＡＨＣは、ＥＡＨＣとＥＡＨＳとの間に存在する安全な通信セッションを介して、ＡＣの資格情報をＥＡＨＳに安全に渡すことができる（工程４）。次に、ＥＡＨＳは、ＥＡＨＳとＥＡＳとの間に存在する安全な通信セッションを介して、ＡＣの資格情報を新しいＥＡＳに安全に渡すことができる（工程５）。同様に、ＥＡＨＳは、ＥＡＨＳとＥＡＨＣとの間に存在する安全な通信セッションを介して、ＥＡＳの資格情報をＥＡＨＣに安全に渡すことができる（工程６）。ＥＡＨＣは、次に、ＥＡＨＣとＡＣとの間に存在する安全な通信セッションを介して、ＥＡＳの資格情報をＡＣに安全に渡すことができる（工程７）。このプロセスの間、ＥＡＨＳは、新しい資格情報／更新された資格情報が必要とされる場合、ネットワーク内のセキュリティ機能と通信することもできる（図１４Ａ及び図１４Ｂには図示せず）。ＡＣ及びＥＡＳが互いの資格情報で構成されると、それらは、双方向認証ハンドシェイクを実行して、アプリケーション層メッセージを互いに安全に交換するために使用可能な信頼関係及び安全な通信セッションを互いに確立することができる（工程１２ａ）。

同様に、ＥＡＨＳはまた、互いのハンドオフに関与するＥＡＳを支援し、それらがアプリケーション状態の安全な同期／移行などのハンドオフ動作を安全に実行することができるように、それらが互いに信頼関係を確立するのに役立てることができる。新しいＥＡＳへのＡＣのハンドオーバが発生すると、ＥＡＨＳは、古いＥＡＳの資格情報を新しいＥＡＳに安全に渡すことができ、逆もまた同様である（図１４Ａの工程８及び図１４Ｂの工程９）。これは、ＥＡＨＳと各ＥＡＳとの間に存在する安全な通信セッションを介して行うことができる。このプロセスの間、ＥＡＨＳは、新しい資格情報／更新された資格情報が必要とされる場合、ネットワーク内のセキュリティ機能と通信することもできる（図１４Ａ及び図１４Ｂには図示せず）。ＥＡＳが互いの資格情報を用いて構成されると、ＥＡＳは、双方向認証ハンドシェイクを実行して、信頼関係及び安全な通信セッションを互いに確立することができ（工程１０）、次いで、これを使用して、アプリケーション層の状態を互いに安全に同期／移行することができる（工程１１）。

資格情報管理を支援することに加えて、ＥＡＨＣ及び／又はＥＡＨＳはまた、ＡＣとＥＡＳとの間の安全な通信セッションを確立及び／又は切断することを支援することができる。ＥＡＨＣは、ＡＣと同じＩＰアドレスを有する同じＵＥ上でホストされるので、ＥＡＨＣは、ＡＣの代わりにセキュリティプロキシとして機能するように適切に配置される。ＥＡＨＣは、ＡＣの代わりにＥＡＳとの安全な通信セッションを確立し（工程１２ｂ）、かつ／又は切断することができる（工程１３）。これにより、ＡＣは、これを自身で行う負担が軽減されるため、ＡＣを解放して、他のアプリケーションセントリック動作をより効率的に実行することができる。更に、ＥＡＨＣは、ＡＣよりも早くＥＡＨ動作の発生に関与し得るので、ＥＡＨＣは、これらの動作をより効率的な方法で実行することが可能となり得る。したがって、ＥＡＨＣは、ＡＣよりも早く安全な通信セッションの確立又は切断を開始することが可能となり得る。これは、ＥＡＨレイテンシを低減し、全体的なシステム性能を改善するのに役立ち得る。例えば、ＥＡＨＣ及びＥＡＨＳが、ＥＡＨ中にＥＳＡ間で状態を移行／同期させるなどのＥＡＨ動作を実行している場合、ＥＡＨＣ及びＥＡＨＳは、ＥＳＡへの安全な通信セッションが不要になったことを認識することができ、ＡＣとＥＡＳとの間の安全な通信を効率的かつ適時に切断することができる。

(ＥＡＨ認識アプリケーション状態同期／移行)
ユースケースの要件に応じて、ＡＣが現在使用しているＥＡＳから、ＡＣがハンドオフされている新しいＥＡＳへのアプリケーション状態の同期又は移行が必要とされる場合がある。

システム内の異なるＥＡＳ間のＡＣのシームレスなハンドオーバを可能にするために、ＥＡＨＣ及びＥＡＨＳは、ＡＣ及びＥＡＳを支援して、ＥＡＳ間のアプリケーション状態の効率的な同期又は移行を管理するのに役立てることができる。そうすることで、ＥＡＨＣ及びＥＡＨＳは、これらの動作を実行するＡＣの負担を軽減することができる。

図１５Ａ及び図１５Ｂは、ＥＡＨＣ及び／又はＥＡＨＳが、ＥＡＨ中にアプリケーションの状態同期又は移行の動作をトリガすること（図１５Ａの工程１）を含む機能の一例を示している。これらのトリガは、ＡＣに同期又は移行の動作を開始及び／又は実行させるために、所望によりＡＣに送信することができる（工程２ａ）。代替的に、トリガは、ＥＡＨＳ又はＥＡＨＣから、ＥＡＨに関与する古いＥＡＳ（ＥＡＳ＃１）（工程２ｂ）及び／又は新しいＥＡＳ（ＥＡＳ＃２）（工程２ｃ）、あるいはその両方に送信され得る。ＥＡＨＣ及び／又はＥＡＨＳは、ＥＡＨが必要とされており、かつ他の必須のＥＡＨ動作（例えば、新たなＥＡＳの選択の発見、ハンドオフに関与するＥＡＳへのＥＡＳ資格情報のプロビジョニング）が完了したことを検出すると、アプリケーションの状態同期又は移行の動作をトリガすることができる。アプリケーションの状態同期又は移行の動作をトリガした後、ＥＡＨＣ及び／又はＥＡＨＣは、動作が正常に完了したか否かを監視することができる（図１５Ｂの工程４）。ＥＡＨＣ及び／又はＥＡＨＳは、アプリケーションの状態同期又は移行の動作が正常に完了したかどうかに関するステータス更新をＥＡＳ及び／又はＡＣから受信することができる。成功した場合、ＥＡＨＣ及び／又はＥＡＨＳは、これを、ＥＡＨが正常に完了したという資格として使用し、新しいＥＡＳがアクセスする準備ができたことの通知をＡＣに送信することができる（工程６ａ）。失敗した場合、ＥＡＨＣ及び／又はＥＡＨＳは、これを、ＥＡＨが失敗したという資格として使用し、次に、新しいＥＡＳを識別し、新しいＥＡＨをトリガするなどの追加の動作を実行することができる（工程６ｂ）。
エッジアプリケーションハンドオーバがいつ開始されるかの認識を活用して、ＥＡＨＣ及びＥＡＨＳは、ＡＣよりも最適な方法でこのトリガを実行するように良好に配置することができる。これにより、ＡＣは、自身でこの動作を開始する必要があるという負担を軽減することができる。

(ＥＡＨ認識要求バッファリング)
システム内の異なるＥＡＳ間でのＡＣのシームレスなハンドオーバを可能にするために、ＥＡＨＣは、ＥＡＨ動作が完了し、ＡＣがその新しいＥＡＳ（複数可）と通信できるようになるまで、ＡＣからＥＡＳ（複数可）への発信要求を記憶及び転送することができる。

図１６Ａ及び図１６Ｂは、ＥＡＨがシステムにおいてトリガされる（図１６Ａの工程１）機能の一例を示している。ＥＡＨが処理されている間、ＡＣは、ＥＡＳにアクセスする要求を発行し続ける（工程２）。ＥＡＨＣ及び／又はＥＡＨＳによってＥＡＨ動作が実行されている間、ＥＡＨＣはこれらの要求をバッファリングする。例えば、ＥＡＨ認識ＦＱＤＮ解決、ＥＡＨ認識セッションの切断及び確立、並びにＥＡＨ状態同期／移行などのＥＡＨ動作である（工程４）。全てのＥＡＳハンドオーバ動作が正常に完了すると（図１６Ｂの工程５）、ＥＡＨＣは、バッファリングされた要求をハンドオーバに関与する「新しい」ＥＡＳ（ＥＡＳ＃２）に転送することができ（工程６）、応答はＡＣに戻ることができる（工程７）。バッファリングされた要求を転送するとき、ＥＡＨＣは、バッファリングされた要求において指定されたターゲットＥＡＳ ＦＱＤＮが、ＡＣがハンドオフされた「新しい」ＥＡＳのリフレッシュされた窓口情報に正確に解決されたことを確認することができる。

(ＥＡＨ認識セッションＱｏＳ継続性)
システム内の異なるＥＡＳ間のＡＣのシームレスなハンドオーバを可能にするために、ＥＡＨＣ又はＥＡＨＳは、ＥＡＨ認識セッションＱｏＳ継続性機能をサポートする能力をサポートすることができる。この機能では、ＥＡＨハンドオーバが発生した場合に、ＥＡＨＣ又はＥＡＨＳによって、ＵＥ上でホストされるＡＣ（複数可）とエッジノード（複数可）上でホストされる対応するＥＡＳ（複数可）との間で確立された３ＧＰＰネットワークＱｏＳフロー（複数可）の構成が整合して保たれることを保証する必要がある。ＥＡＨハンドオーバが発生した場合、ＥＡＨＣ又はＥＡＨＳは、ＡＣ（複数可）と、それらがハンドオフされる新しいＥＡＳ（複数可）との間の新しいＱｏＳフロー（複数可）の確立を支援することができる。ＥＡＨＣ又はＥＡＨＳは、ＡＣ（複数可）とＥＡＳ（複数可）との間に存在するセッションＱｏＳフローの構成を、その確立を支援するときに追跡することができる。ＥＡＨがトリガされた場合／トリガされたときに、ＥＡＨＣ又はＥＡＨＳは、ＡＣ（複数可）と新しいＥＡＳ（複数可）との間のセッションＱｏＳフローを、それらが、ＡＣ（複数可）とそれらがアクセスしている現在のＥＡＳ（複数可）との間で確立された既存のフローとの整合性が保たれるように構成することができる。

図１７Ａ～図１７Ｃは、ＡＣがそのＱｏＳ要件をＥＡＨＣと共有し得る一例を示す（図１７Ａの工程１）。第１のＥＡＨがシステムにおいてトリガされる（工程２）。ＥＡＨが処理されている間、ＥＡＨＳは、３ＧＰＰネットワークへの要求を開始して、ＡＣとＥＡＳ＃１との間でＡＣのＱｏＳセッション要件を満たすセッションＱｏＳフローを確立する（工程３ａ）。３ＧＰＰネットワークは、要求を受信して処理し、ＡＣとＥＡＳ＃１との間のＱｏＳフローを構成する（工程３ｂ）。３ＧＰＰネットワークは、セッションＱｏＳフローを識別するために使用されるフロー識別子、例えば５ ＱＩ（５Ｇ ＱｏＳ識別子）を含む応答を返す（工程３ｃ）。ＥＡＨＳは、フロー識別子並びに適用可能なＡＣ及びＥＡＳを含むセッションＱｏＳフロー情報を維持する（工程４）。ＡＣは、ＥＡＳ＃１と通信を開始し、その提供されたサービスにアクセスする（工程５）。この通信の間、３ＧＰＰネットワークは、ＡＣのＱｏＳ要件が満たされることを保証する。

後続のある時点で、別のＥＡＨがトリガされ、ＥＡＳ＃２がハンドオーバのターゲットＥＡＳとして識別される（工程６）。ＥＡＨＳは、ＥＡＨ認識セッションＱｏＳ継続性機能を実行する。ＥＡＨＳがＥＡＨ認識セッションＱｏＳ継続性を実行するために使用し得る１つの方法は、新しいセッションＱｏＳ確立要求を３ＧＰＰネットワークに最初に送信して、ＡＣとＥＡＳ＃２との間に、ＡＣによって定義され、ＥＡＨＳによって維持されるものと同じＱｏＳ要件を有するセッションＱｏＳフローを確立することにより行われる（図１７Ｂの工程７ａ）。３ＧＰＰネットワークは、要求を受信及び処理し、ＡＣとＥＡＳ＃２との間のＱｏＳフローを構成する（工程７ｂ）。３ＧＰＰネットワークは、セッションＱｏＳフローを識別するために使用されるフロー識別子を含む応答を返す（工程７ｃ）。次に、ＥＡＨＳは、ＡＣとＥＡＳ＃１との間のセッションＱｏＳフローを終了するための別の要求を発行する（工程８ａ）。３ＧＰＰネットワークは、要求を受信して処理し、ＡＣとＥＡＳ＃１との間のＱｏＳフローを切断する（工程８ｂ）。３ＧＰＰネットワークは、応答を返す（工程８ｃ）。ＥＡＨＳは、フロー識別子並びに適用可能なＡＣ及びＥＡＳを含むセッションＱｏＳフロー情報を維持する（工程４）。ＡＣは、ＥＡＳ＃１と通信を開始し、その提供されたサービスにアクセスする（工程５）。この通信の間、３ＧＰＰネットワークは、ＡＣのＱｏＳ要件が満たされることを保証する。

ＥＡＨＳがＥＡＨ認識セッションＱｏＳ継続性を実行するために使用し得る別の方法は、セッションＱｏＳハンドオーバ要求を３ＧＰＰネットワークに発行することである（図１７Ｃの工程９ａ）。この要求において、ＥＡＨＳは、ＡＣとＥＡＳ＃１との間の既存のセッションＱｏＳフローのためのＱｏＳフロー識別子と、ハンドオーバの対象とされるＥＡＳ（ＥＡＳ＃２）の識別子とを含み得る。３ＧＰＰネットワークは、要求を受信して処理し、ＡＣとＥＡＳ＃２との間に、ＡＣとＥＡＳ＃１との間のフローと同じＱｏＳ要件を有するセッションＱｏＳフローを確立する（工程９ｂ）。このようにして、既存のセッションについてのＱｏＳフロー識別子を使用して、ターゲットＥＡＳとの新しいセッションについての所望のＱｏＳ特性が識別される。このセッションＱｏＳフローを確立した後、３ＧＰＰネットワークは、ＡＣとＥＡＳ＃１との間のセッションＱｏＳフローを切断する（工程９ｃ）。次いで、３ＧＰＰネットワークは、新しいセッションＱｏＳフローを識別するために使用されるフロー識別子を含む応答をＥＡＨＳに返す（工程９ｄ）。ＥＡＨＳは、フロー識別子並びに適用可能なＡＣ及びＥＡＳを含むセッションＱｏＳフロー情報を維持する（工程１０）。ＡＣは、ＥＡＳ＃２と通信を開始し、その提供されたサービスにアクセスする（工程１１）。この通信の間、３ＧＰＰネットワークは、ＡＣのＱｏＳ要件が満たされることを保証する。
(ＥＡＨ認識管理手順)
システム内の異なるＥＡＳ間でのＡＣのシームレスなハンドオーバを可能にするために、ＥＡＨＣ又はＥＡＨＳは、システム内の種々の管理機能インターフェースし、それらが異なるタイプの管理動作を実行することを支援することができる。逆に、管理機能は、エッジアプリケーションハンドオーバを実行する際にＥＡＨＣ又はＥＡＨＳを支援することもできる。

図１８Ａ及び図１８Ｂは、ＥＡＨＣ又はＥＡＨＳが、附属書の表９に定義されたコンテキストのタイプなどであるがこれらに限定されない、システム内の管理機能にＥＡＨ関連コンテキスト情報を提供し得る一例を示している（図１８Ａの工程１）。管理機能は、この情報を、特定の管理動作を実行するかどうか／いつ実行するかについての意思決定に考慮することができる（工程２及び３）。例えば、ＥＡＨＣ又はＥＡＨＳは、ＥＡＳがどこに展開され得るか（例えば、これらのノード上のＥＡＳステータスを管理することによって負荷分散又は性能スケーリングが実行され得るようなエッジノードのセット上）、ＥＡＨがいつ必要とされるか（例えば、すぐに、又は将来の何らかの指定された時間又はスケジュール）、ＥＡＨがどこに必要とされるか（例えば、指定された地理的位置又は領域内、指定されたエッジネットワーク内などのネットワークの指定されたエリア内、又は指定ルートに沿って）、ＥＡＨが誰に必要とされるか（例えば、どのＵＥ、ＡＣ、ＥＡＳ、エッジノード）、及びＥＡＨがなぜ必要とされるか（例えば、ＵＥが位置を変更したか、ＡＣが現在のＥＡＳからのサービスレベルに満足していないか、３ＧＰＰネットワークがネットワーク輻輳などの問題をシグナリングしたか）に関するＥＡＨ関連コンテキストを提供してもよい。

ＥＡＨＣ又はＥＡＨＳはまた、特定の管理動作が必要であると判定することができ（工程４）、トリガ要求を管理機能に送信して（工程５）、それに代わって、限定はしないが、指定されたエッジネットワーク内又は指定されたエッジノード上でのＥＡＳの展開、指定されたエッジネットワーク内又は指定されたエッジノード上でのＥＡＳのインストール及びアクティブ化／非アクティブ化など、特定のタイプの管理動作を実行させることができる（工程６）。

ＥＡＨＣ又はＥＡＨＳの支援が有効であり得る一部のタイプの管理動作には、以下が含まれ得るが、これらに限定されない。
・システム内のどのエッジネットワーク及びエッジノードが特定のＥＡＳの展開のための最良の候補であるかの最適選択
・システム内のどのエッジネットワーク及びエッジノードが、ＥＡＳの新しいインスタンスのインストール又はすでにインストールされたＥＡＳのアクティブ化のための最良の候補であるかの最適な選択
・システム内のどのエッジネットワーク、エッジノード、及び既存のＥＡＳが特定のＡＣによるアクセスのための最良の候補であるかの最適選択
・ＡＣが特定のＥＡＳにアクセスすることを完全に防止するか、又はＥＡＳにアクセスするときにＡＣのサービスレベルを低下させるかのいずれかであるサービス可用性問題がシステム内に存在するかどうかの検出
・エッジネットワーク又はエッジノードにおいて利用可能なリソースが不足している場合に、システム内のどの既存のＥＡＳが、エッジネットワーク及びエッジノードからの無効化及び／又はアンインストールのための最良の候補であるかの最適な選択
・ＥＡＳをインストール／アクティブ化／非アクティブ化／修正するための最適なタイミングの決定
・ＥＡＳをアクティブ化及び非アクティブ化するための最適スケジュールの決定
・ＥＡＳをホストするためのエッジノード上でのリソースの予約
・ＥＡＳのエッジリソース利用など、ＥＡＳのステータスの調整
・ＡＣがアクセスを許可されるエッジネットワーク、エッジノード、エッジサーバ、及びエッジアプリケーションサーバを決定するシステムにおけるアクセス制御ポリシーの構成

逆に、システム内の管理機能は、管理関連情報をＥＡＨＣ又はＥＡＨＳと共有することによって、ＥＡＨＣ又はＥＡＨＳを支援することができる（図１８Ｂの工程７）。一部のタイプの管理関連情報は、システム内のエッジネットワーク、エッジノード、又はＥＡＳのステータス及び／又は可用性であり得る。ＥＡＨＣ又はＥＡＨＳは、この情報を、ＥＡＨをトリガするか否かの判定に考慮することができる（工程８）。次いで、ＥＡＨＣ又はＥＡＨＳは、新しいＥＡＳへのＡＣのハンドオーバを開始することを決定して、ＡＣが現在アクセスしているＥＡＳ上の過負荷状態を緩和することができる（工程９）。

管理機能はまた、ＥＡＨが必要であると判定し（工程１０）、ＥＡＨＣ又はＥＡＨＳに要求を送信して、ＥＡＨＣ又はＥＡＨＳにＥＡＨを実行するようにトリガし（工程１１）、管理機能によって検出された問題を緩和することができる。次いで、ＥＡＨＣ又はＥＡＨＳは、ＡＣの新しいＥＡＳへのハンドオーバを開始して、ＡＣが現在アクセスしているＥＡＳ上の過負荷状態を緩和することができる（工程１２）。

図１９Ａ及び図１９Ｂは、例示的なＥＡＨ認識エッジコンピューティングサービスプロバイダ相互作用を示している。エッジコンピューティングサービスプロバイダ（ＥＣＳＰ）はまた、管理機能と相互作用して、新しいエッジアプリケーションをエッジネットワークに展開する、新しいＥＡＳインスタンスをインストールする、又は展開若しくはインストールされたＥＡＳの現在のステータスを調整するなどの管理動作をトリガすることができる。ＥＡＨＳは、ＥＡＨ関連コンテキスト情報を共有することによって、ＥＣＳＰと相互作用する際に管理機能を支援し、ＥＡＳの展開及びステータスを最適化することができる。

管理機能は、既存のＥＡＳ展開ステータス又はインスタンスステータスに関する情報をＥＡＨＳから受信することができ、それに基づいて、管理機能は、新しい／追加のＥＡＳを展開又はインストールする必要性（特定のタイプのＥＡＳがエッジネットワークで欠落している、特定のタイプの既存のＥＡＳが過負荷であり、新しいインスタンスが必要である、など）を識別することができる。管理機能は、行うべき最適な動作を決定することができ、これには、所望のＥＡＳのタイプ、所望のＥＡＳをホストし得るエッジノード及びエッジネットワーク、新しいＥＡＳが必要とされるとき、ＥＡＨが必要とされる場合／必要とされるときなどが含まれるが、これらに限定されない。次いで、かかる情報は、推奨事項としてＥＣＳＰに送信することができる。推奨事項を受信した後、ＥＣＳＰは、提案された動作が合意されるかどうかを決定することができる。合意された場合、ＥＣＳＰは、推奨動作をトリガするための要求を管理機能に送信して、例えば、所望のＥＡＳをより多くのエッジノードに展開し、又は所望のＥＡＳのより多くのインスタンスをインストールすることができる。

管理機能は、ＥＣＳＰから、ＥＡＳの展開ステータス及びインスタンスステータスに関するクエリを受信し、ＥＡＨＳから必要な情報を収集することができる。応答を受信した後、ＥＣＳＰは、新しいＥＡＳを展開すること、展開／インストールされたＥＡＳのステータスを調整すること、又はＥＡＨを実行することなどの管理動作をトリガすることができる。

(ルート支援型ＥＡＨ)
モバイルＵＥを伴うユースケースに対してエッジアプリケーションハンドオーバを更に最適化するために、ＵＥのルート情報を活用して、エッジアプリケーションハンドオーバの管理を支援することができる。ルート支援型エッジアプリケーションハンドオーバは、ルート情報を活用することを伴うものであり、どのターゲットＥＡＳにＡＣが次にハンドオフされるかを調整及び管理する。ルート情報は、一連のウェイポイントから構成され得る。ウェイポイントは、地理的座標に関して定義されてもよく、又は限定はしないが、ルートに沿ったエッジネットワーク、エッジノード、及び／又はエッジサーバの識別子などの他の用語で表現されてもよい。

図２０Ａ及び図２０Ｂは、ルート支援型ＥＡＨ機能の一例を示している。ルート情報は、事前に所定のルートを明示的に定義するユーザ又はＡＣを含むがこれらに限定されない、システム内の複数のタイプのエンティティから生じ得る（工程１）。例えば、旅程の計画では、開始点及び終了点並びに中間地点が定義される。所定のルートが定義されない場合、ルートは、システム内の種々のエンティティから利用可能なリアルタイム及び／又は履歴のコンテキスト情報に基づいて予測又は推測することができる（工程２）。例えば、ＵＥの通勤パターンなどの履歴のコンテキストと結合され、ＵＥが現在移動している道路などのコンテキスト情報を使用して、予測ルートがＥＡＨＳにより計算され、該予測ルートを使用して、ＵＥ上でホストされるＡＣ（複数可）がハンドオフされる次のＥＡＳ（複数可）の選択を支援することができる。予測分析技術を使用して、予測ルートの計算を支援することができる。所定のルートが指定されることを可能にする能力、並びにコンテキスト情報及び予測分析を活用してＵＥのルートを予測する能力の両方は、ＥＡＨＣ又はＥＡＨＳによってサポートされ得る機能である。

ルート情報が利用可能になると、所望のＥＡＳは、ルートに沿ったエッジノードに積極的に展開され得る。ＵＥルートに沿ったＥＡＳは、ＵＥのルート情報に基づいて予めインストールされ、予め構成されてもよい。代替的に、展開されたＥＡＳは、直ちにインストール又はアクティブ化される必要はなく、又は常にアクティブのままである必要はない。インストール／アクティブ化／非アクティブ化のタイミングは、ＵＥの位置に従って、ＥＡＨＣ又はＥＡＨＳによって決定され得る（図１８のシナリオ＃１又は＃２）。ＥＡＨＣ又はＥＡＨＳは、ルート情報を利用して、ルートによって定義される異なるウェイポイントに対するＵＥの現在の位置を監視し、ルートに沿ったＵＥ（複数可）の移動並びに任意の予期せぬ逸脱を追跡することができる。ルートに沿ってＵＥの位置を監視及び追跡するために（工程７）、ＥＡＨＣ又はＥＡＨＳは、ＵＥの現在位置の更新に依存することができる。これらの更新は、ＵＥ自体から（工程３）、３ＧＰＰネットワーク内の位置機能から（工程４）、又はシステム内の他のエンティティ（例えば、ＳＣＳ／ＡＳ）から生じ得る。

ＥＡＨＣ又はＥＡＨＳは、ＵＥについての予想ルート情報を３ＧＰＰネットワークと共有することができ、それにより、ネットワークは、ＵＥがルートに沿って移動する間にＵＥの要件（例えば、ＱｏＳ）が満たされることを保証するように、そのネットワークリソースを構成及び最適化することができる（工程５）。ＥＡＨＣ又はＥＡＨＳはまた、３ＧＰＰネットワークがその代わりにルートに沿ったＵＥの移動を追跡し、ルートに沿ったＵＥの移動に関する通知を送信することを要求することができる（工程６）。例えば、通知には、限定はしないが、ＵＥがルートに沿って指定されたウェイポイントに到着したとき、又はＵＥが指定ルートから逸脱したときが含まれる。

ルートに沿ったＵＥの移動に関する位置情報を活用して、ＥＡＨＣ又はＥＡＨＳは、ＵＥの移動を、同じルートに沿ってＵＥに近接して展開された利用可能なエッジネットワーク、エッジノード、及び／又はＥＡＳと比較することができる。この比較及び任意の構成されたＥＡＨポリシーに基づいて、ＥＡＨＣ又はＥＡＨＳは、ＥＡＨをトリガすべきかどうか／いつトリガすべきか、及びどのＥＡＳ（複数可）をＥＡＨのターゲット（複数可）として選択すべきかを決定することができる（工程８）。ＥＡＨＣ又はＥＡＨＳが、ＥＡＨが必要であると判定した場合、ＥＡＨ動作を実行することによって、システム内の他のエンティティをトリガし、支援することができる（工程９）。

図２０Ａ及び図２０Ｂは、ルート支援型ＥＡＨを示している。単一のＵＥのためのルート支援型エッジアプリケーションハンドオーバをサポートすることに加えて、ＥＡＨＣ又はＥＡＨＣは、一緒に移動するＵＥのグループ（例えば、Ｖ２Ｘ隊列走行）のためのルート支援型ＥＡＨ機能をサポートすることができる。この機能は、図２０Ａ及び２０Ｂには取り込まれていないことに留意されたい。

図２０Ａ及び２０Ｂに取り込まれた動作に加えて、ＥＡＨＳはまた、ＥＡＳが過負荷にならないように、特定の位置にある、又は指定ルートに沿ったエッジ又はクラウドノードに、ＡＣを登録し、かつ／又はＡＣによる使用のために既存のＥＡＳを予約する１又は複数の要求を送信することができる。これらの要求は、事前に（例えば、旅程が構成され、ルートが決定されるときに）、かつＡＣがクラウド／エッジノードの近傍にある前に送信され得る。代替的に、これらの要求は、ＥＡＨＳが、ＡＣの位置が変化し、所与のエッジ又はクラウドノードの特定の近傍内にあることを検出したときに、オンザフライで送信され得る。この要求には、ＡＣのセキュリティ資格情報及び識別子などの情報、必要とされるサービス可用性スケジュール（例えば、アプリケーション又はサービスの計画された使用の時間ウィンドウ）などの予測されるＱｏＳ／ＱｏＥサービス要件、ユーザプロファイル若しくはプリファレンス情報（例えば、アプリケーション設定）、並びに／あるいはサービス使用量要件（例えば、要求のレート、アプリケーション要求レート、データ制限など）が含まれ得る。これらの要求は、サービスをホストするエッジノード又はクラウドに直接送信されてもよく、あるいはエッジノード若しくはクラウド上でホストされるサービスの登録及び／又は予約を容易にするネットワーク内の別の機能に送信されてもよい。

(例示的なサービス層アプローチ)
本明細書で説明する支援型エッジアプリケーションハンドオーバの着想は、限定はしないが、３ＧＰＰ ＳＡ６、ｏｎｅＭ２Ｍ、及びＯＭＡ ＬＷＭ２Ｍなど、種々の複数のサービス層技術に適用することができる。

(３ＧＰＰ ＳＡ６ ＥＤＧＥＡＰＰの例)
図２１は、本明細書で説明される概念が、エッジアプリケーションを可能にするための３ＧＰＰ ＳＡ６定義アーキテクチャにおいてどのように適用され得るかの一例を示している。例えば、ＴＳ２３．２８６を参照されたい。

定義されたＥＡＨＣ機能は、既存のエッジイネーブラクライアント機能内の新しい機能として実現することができる。代替的に、ＥＡＨＣは、ＵＥの新たなスタンドアロン機能として実現されてもよい。この場合、新しい基準点（例えば、Ｅｄｇｅ－１３及びＥｄｇｅ－１４）は、新しいスタンドアロンＥＡＨＣとの相互作用をサポートように定義され得る。

定義されたＥＡＨＳ機能は、エッジイネーブラサーバ又はエッジデータネットワーク構成サーバ機能の新しい機能として実現することができる。代替的に、ＥＡＨＳは、システム内の新しいスタンドアロン機能として実現されてもよい。この新しいスタンドアロン機能は、クラウド内又はネットワークのエッジで展開され得る。新しい基準点（例えば、Ｅｄｇｅ－８、Ｅｄｇｅ－９、Ｅｄｇｅ－１０、Ｅｄｇｅ－１１、及びＥｄｇｅ－１２）はまた、新しいスタンドアロンＥＡＨＳと、ＥＡＳ、エッジイネーブラサーバ、エッジデータネットワーク構成サーバ、ＵＥ、及び／又は３ＧＰＰコアネットワークとの間の相互作用をサポートするように定義され得る。

附属書の表１０は、ＳＡ６ ＥＤＧＥＡＰＰアーキテクチャの基準点が、本明細書で説明されるそれぞれの基準点の各々に対して定義される機能とどのように整合され、拡張され得るかの一例を提供する。

(３ＧＰＰ ＳＡ６ Ｖ２Ｘの例) 図２２は、本明細書で説明される概念が３ＧＰＰ ＳＡ６ Ｖ２Ｘアーキテクチャにおいてどのように適用され得るかの一例を示している。例えば、ＴＳ２３．２８６及び３ＧＰＰ ＴＲ２３．７６４を参照されたい。

定義されたＥＡＨＣ機能は、ＵＥ上でホストされる既存のＶＡＥクライアント及び／又はＳＥＡＬクライアント機能に追加された新しい機能として実現され得る。代替的に、ＥＡＨＣは、ＵＥの新しいスタンドアロン機能として実現されてもよい（図２２には図示せず）。この場合、新しい基準点は、新しいスタンドアロンＥＡＨＣとの相互作用をサポートするように定義され得る。

定義されたＥＡＨＳ機能は、既存のＶ２Ｘアプリケーションイネーブラ（ＶＡＥ）サーバに追加される新しい機能として実現することができる。代替的に、ＥＡＨＳは、システム内の新しいスタンドアロン機能として実現されてもよい（図２２には図示せず）。この新しいスタンドアロン機能は、クラウド内又はネットワークのエッジで展開され得る。この場合、新しい基準点は、新しいスタンドアロンＥＡＨＳとの相互作用をサポートするように定義され得る。

附属書の表１１は、ＳＡ６ Ｖ２Ｘアーキテクチャの基準点が、本明細書で説明されるそれぞれの基準点の各々に対して定義される機能とどのように整合され、拡張され得るかの一例を提供する。

(ｏｎｅＭ２Ｍの例)
図２３は、本明細書に説明される機能がｏｎｅＭ２Ｍアーキテクチャにおいてどのように適用され得るかの一例を示している。例えば、ＴＳ２３．２８６及び３ＧＰＰ ＴＲ２３．７６４を参照されたい。

定義されたＥＡＨＣ機能は、ＵＥ上にホストされる既存のｏｎｅＭ２Ｍ ＡＳＮ／ＭＮ－ＣＳＥに追加される新しい機能として実現され得る。定義されたＥＡＨＳ機能は、既存のｏｎｅＭ２Ｍ ＩＮ－ＣＳＥに追加される新しい機能として実現され得る。

附属書の表１２は、ＳＡ６ ＥＤＧＥＡＰＰアーキテクチャの基準点が、本明細書で説明されるそれぞれの基準点の各々に対して定義される機能とどのように整合され、拡張され得るかの一例を提供する。

(ＬＷＭ２Ｍの例)
図２４は、本明細書で説明される概念がＯＭＡ ＬＷＭ２Ｍアーキテクチャにおいてどのように適用され得るかの一例を示している。ＥＡＨＣの定義された機能は、ＵＥ上でホストされる既存のＬＷＭ２Ｍクライアントに追加される新しい機能として実現され得る。ＥＡＨＳの定義された機能は、既存のＬＷＭ２Ｍサーバ機能に追加される新しい機能として実現され得る。

(グラフィカルユーザインターフェース（ＧＵＩ）)
図２５は、セルラーデバイスを操作している人が、セルラーデバイスに関連付けられたＥＡＨポリシー設定を構成することを要求するために使用できる例示的なＧＵＩを示している。これらのポリシーは、本明細書で説明されるＥＡＨＣ及び／又はＥＡＨＳサーバ機能によって使用され得る。

(例示的な環境)
第３世代パートナーシッププロジェクト（３ＧＰＰ）では、セルラー電気通信ネットワーク技術のための技術規格が開発されており、これには、無線アクセス、コアトランスポートネットワーク、並びにコーデック、セキュリティ、及びサービス品質に関する作業を含むサービス能力が含まれる。最近の無線アクセス技術（ＲＡＴ）規格は、ＷＣＤＭＡ（登録商標）（一般に３Ｇと称される）、ＬＴＥ（一般に４Ｇと称される）、及びＬＴＥ－Ａｄｖａｎｃｅｄ規格を含む。３ＧＰＰは、「５Ｇ」とも称される、新しい無線（ＮＲ：Ｎｅｗ Ｒａｄｉｏ）と称される次世代セルラー技術の標準化に取り組み始めている。３ＧＰＰ ＮＲ規格の開発は、次世代無線アクセス技術（新しいＲＡＴ）の定義を含むことが予想されており、これには、６ＧＨｚ未満の新しいフレキシブル無線アクセスの提供、及び６ＧＨｚを超える新しいウルトラモバイルブロードバンド無線アクセスの提供が含まれることが予想されている。フレキシブル無線アクセスは、６ＧＨｚ未満の新しいスペクトルにおける新しい後方互換性のない無線アクセスから構成されることが予想されており、同じスペクトルにおいて一緒に多重化され得る異なる動作モードを含み、異なる要件を有する幅広い３ＧＰＰ ＮＲユースケースのセットに対処することが予想されている。ウルトラモバイルブロードバンドは、センチメートル波及びミリ波のスペクトルを含むことが予想されており、これにより、例えば、屋内アプリケーション及びホットスポットのためのウルトラモバイルブロードバンドアクセスのための機会が提供される。特に、ウルトラモバイルブロードバンドは、センチメートル波及びミリ波特有の設計最適化を用いて、６ＧＨｚ未満のフレキシブル無線アクセスと共通の設計フレームワークを共有することが予想されている。

３ＧＰＰでは、ＮＲがサポートすることが予想される種々のユースケースが特定されており、データレート、レイテンシ、及びモビリティに関する多種多様なユーザエクスペリエンス要件がもたらされている。このユースケースには、以下の一般的なカテゴリ、すなわち、拡張モバイルブロードバンド（例えば、密集エリアにおけるブロードバンドアクセス、屋内超高ブロードバンドアクセス、群衆におけるブロードバンドアクセス、５０＋Ｍｂｐｓエブリウェア（ｅｖｅｒｙｗｈｅｒｅ）、超低費用ブロードバンドアクセス、車両におけるモバイルブロードバンド）、クリティカル通信、大規模マシンタイプ通信、ネットワーク動作（例えば、ネットワークスライシング、ルーティング、移行及びインターワーキング、エネルギー節約）、並びに拡張された車車間／路車間（ｅＶ２Ｘ）通信が含まれており、ｅＶ２Ｘには、車両－車両通信（Ｖ２Ｖ）、車両－インフラストラクチャ通信（Ｖ２Ｉ）、車両－ネットワーク通信（Ｖ２Ｎ）、車両－歩行者通信（Ｖ２Ｐ）、及び他のエンティティとの車両通信のうちのいずれかが含まれ得る。これらのカテゴリにおける特定のサービス及びアプリケーションには、一部例を挙げると、例えば、監視及びセンサネットワーク、デバイス遠隔制御、双方向遠隔制御、パーソナルクラウドコンピューティング、ビデオストリーミング、ワイヤレスクラウドベースのオフィス、ファーストレスポンダ接続、車両緊急通報システム、災害警報、リアルタイムゲーム、多人数ビデオ通話、自律運転、拡張現実、触覚インターネット、及び仮想現実が含まれる。これらのユースケース及びその他の全てが、本明細書で企図される。

図２６Ａは、本明細書で説明され特許請求される方法及び装置が具現化され得る例示的な通信システム１００の一実施形態を示している。図示のように、例示的な通信システム１００は、ワイヤレス送信／受信ユニット（ＷＴＲＵ）１０２ａ、１０２ｂ、１０２ｃ、１０２ｄ、１０２ｅ、１０２ｆ、及び／又は１０２ｇ（概して又は集合的にＷＴＲＵ１０２と称され得る）、無線アクセスネットワーク（ＲＡＮ）１０３／１０４／１０５／１０３ｂ／１０４ｂ／１０５ｂ、コアネットワーク１０６／１０７／１０９、公衆交換電話網（ＰＳＴＮ）１０８、インターネット１１０、他のネットワーク１１２、並びにＶ２Ｘサーバ（又はＰｒｏＳｅ機能及びサーバ）１１３を含むことができるが、開示される実施形態は、任意の数のＷＴＲＵ、基地局、ネットワーク、及び／又はネットワーク要素を企図することが理解されるであろう。ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄ、１０２ｅ、１０２ｆ、１０２ｇの各々は、ワイヤレス環境において動作及び／又は通信するように構成された任意のタイプの装置又はデバイスであり得る。各ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄ、１０２ｅ、１０２ｆ、１０２ｇは、ハンドヘルドワイヤレス通信装置として図２６Ａ～２６Ｅに示されているが、５Ｇワイヤレス通信のために企図される多種多様なユースケースを用いて、各ＷＴＲＵは、ワイヤレス信号を送信及び／又は受信するように構成された任意のタイプの装置又はデバイスを備えるか、又はその中で具現化され得ることを理解されたい。該装置又はデバイスには、ほんの一例として、ユーザ機器（ＵＥ）、移動局、固定又はモバイル加入者ユニット、ページャ、セルラー電話、携帯情報端末（ＰＤＡ）、スマートフォン、ラップトップ、タブレット、ネットブック、ノートブックコンピュータ、パーソナルコンピュータ、ワイヤレスセンサ、家庭用電子機器、スマートウォッチ又はスマート衣類などのウェアラブルデバイス、医療又はｅヘルスデバイス、ロボット、産業機器、ドローン、車、トラック、列車、あるいは飛行機などの車両などが含まれる。

通信システム１００は、基地局１１４ａ及び基地局１１４ｂを含むこともできる。基地局１１４ａは、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのうちの少なくとも１つとワイヤレスにインターフェースするように構成された任意のタイプのデバイスであり得、コアネットワーク１０６／１０７／１０９、インターネット１１０、及び／又は他のネットワーク１１２などの１又は複数の通信ネットワークへのアクセスを容易にする。基地局１１４ｂは、ＲＲＨ（リモート無線ヘッド）１１８ａ、１１８ｂ、ＴＲＰ（送信及び受信ポイント）１１９ａ、１１９ｂ、及び／又はＲＳＵ（ロードサイドユニット）１２０ａ及び１２０ｂのうちの少なくとも１つと有線で、かつ／又はワイヤレスでインターフェースするように構成された任意のタイプのデバイスであり得、コアネットワーク１０６／１０７／１０９、インターネット１１０、他のネットワーク１１２、及び／又はＶ２Ｘサーバ（又はＰｒｏＳｅ機能及びサーバ）１１３などの１又は複数の通信ネットワークへのアクセスを容易にする。ＲＲＨ１１８ａ、１１８ｂは、ＷＴＲＵ１０２ｃのうちの少なくとも１つとワイヤレスにインターフェースするように構成された任意のタイプのデバイスであり得、コアネットワーク１０６／１０７／１０９、インターネット１１０、及び／又は他のネットワーク１１２などの１又は複数の通信ネットワークへのアクセスを容易にする。ＴＲＰ１１９ａ、１１９ｂは、ＷＴＲＵ１０２ｄのうちの少なくとも１つとワイヤレスにインターフェースするように構成された任意のタイプのデバイスであり得、コアネットワーク１０６／１０７／１０９、インターネット１１０、及び／又は他のネットワーク１１２などの１又は複数の通信ネットワークへのアクセスを容易にする。ＲＳＵ１２０ａ及び１２０ｂは、ＷＴＲＵ１０２ｅ又は１０２ｆのうちの少なくとも１つとワイヤレスにインターフェースするように構成された任意のタイプのデバイスであり得、コアネットワーク１０６／１０７／１０９、インターネット１１０、他のネットワーク１１２、及び／又はＶ２Ｘサーバ（又はＰｒｏＳｅ機能及びサーバ）１１３などの１又は複数の通信ネットワークへのアクセスを容易にする。例として、基地局１１４ａ、１１４ｂは、基地トランシーバ局（ＢＴＳ）、ノードＢ、ｅノードＢ、ホームノードＢ、ホームｅノードＢ、サイトコントローラ、アクセスポイント（ＡＰ）、ワイヤレスルータなどであってもよい。基地局１１４ａ、１１４ｂは各々、単一の要素として示されているが、基地局１１４ａ、１１４ｂは、任意の数の相互接続された基地局及び／又はネットワーク要素を含み得ることが理解されよう。

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

基地局１１４ａは、エアインターフェース１１５／１１６／１１７を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのうちの１又は複数と通信することができ、エアインターフェースは、任意の適切なワイヤレス通信リンク（例えば、無線周波数（ＲＦ）、マイクロ波、赤外線（ＩＲ）、紫外線（ＵＶ）、可視光、センチメートル波、ミリ波など）であり得る。エアインターフェース１１５／１１６／１１７は、任意の適切な無線アクセス技術（ＲＡＴ）を使用して確立することができる。

基地局１１４ｂは、任意の適切な有線通信リンク（例えば、ケーブル、光ファイバなど）又はワイヤレス通信リンク（例えば、無線周波数（ＲＦ）、マイクロ波、赤外線（ＩＲ）、紫外線（ＵＶ）、可視光、センチメートル波、ミリ波など）であり得る有線又はエアインターフェース１１５ｂ／１１６ｂ／１１７ｂを介して、ＲＲＨ１１８ａ、１１８ｂ、ＴＲＰ１１９ａ、１１９ｂ、並びに／又はＲＳＵ１２０ａ及び１２０ｂのうちの１又は複数と通信することができる。エアインターフェース１１５ｂ／１１６ｂ／１１７ｂは、任意の適切な無線アクセス技術（ＲＡＴ）を使用して確立することができる。

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

ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄ、１０２ｅ、１０２ｆ、及び／又は１０２ｇは、任意の適切なワイヤレス通信リンク（例えば、無線周波数（ＲＦ）、マイクロ波、赤外線（ＩＲ）、紫外線（ＵＶ）、可視光、センチメートル波、ミリ波など）であり得るエアインターフェース１１５ｄ／１１６ｄ／１１７ｄ（図示せず）を介して互いに通信することができる。エアインターフェース１１５ｄ／１１６ｄ／１１７ｄは、任意の適切な無線アクセス技術（ＲＡＴ）を使用して確立することができる。

より具体的には、上述したように、通信システム１００は、多元接続システムであってもよく、ＣＤＭＡ、ＴＤＭＡ、ＦＤＭＡ、ＯＦＤＭＡ、ＳＣ－ＦＤＭＡなどの１又は複数のチャネルアクセス方式を採用してもよい。例えば、ＲＡＮ１０３／１０４／１０５内の基地局１１４ａとＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと、又はＲＡＮ１０３ｂ／１０４ｂ／１０５ｂ内のＲＲＨ１１８ａ、１１８ｂ、ＴＲＰ１１９ａ、１１９ｂ及びＲＳＵ１２０ａ、１２０ｂとＷＴＲＵ１０２ｃ、１０２ｄ、１０２ｅ、１０２ｆとは、ユニバーサル移動体通信システム（ＵＭＴＳ）地上無線アクセス（ＵＴＲＡ）などの無線技術を実装することができ、これにより、広帯域ＣＤＭＡ（ＷＣＤＭＡ）を使用して、それぞれエアインターフェース１１５／１１６／１１７又は１１５ｃ／１１６ｃ／１１７ｃを確立することができる。ＷＣＤＭＡは、高速パケットアクセス（ＨＳＰＡ）及び／又は進化型ＨＳＰＡ（ＨＳＰＡ＋）などの通信プロトコルを含み得る。ＨＳＰＡは、高速ダウンリンクパケットアクセス（ＨＳＤＰＡ）及び／又は高速アップリンクパケットアクセス（ＨＳＵＰＡ）を含み得る。

一実施形態では、基地局１１４ａとＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと、又はＲＡＮ１０３ｂ／１０４ｂ／１０５ｂ内のＲＲＨ１１８ａ、１１８ｂ、ＴＲＰ１１９ａ、１１９ｂ、及び／若しくはＲＳＵ１２０ａ、１２０ｂとＷＴＲＵ１０２ｃ、１０２ｄとは、進化型ＵＭＴＳ地上無線アクセス（Ｅ－ＵＴＲＡ）などの無線技術を実装することができ、これにより、ロングタームエボリューション（ＬＴＥ）及び／又はＬＴＥアドバンスト（ＬＴＥ－Ａ）を使用してそれぞれエアインターフェース１１５／１１６／１１７又は１１５ｃ／１１６ｃ／１１７ｃを確立することができる。将来的には、エアインターフェース１１５／１１６／１１７は、３ＧＰＰ ＮＲ技術を実装する可能性がある。ＬＴＥ及びＬＴＥ－Ａ技術は、ＬＴＥ Ｄ２Ｄ及びＶ２Ｘ技術及びインターフェース（例えば、サイドリンク通信など）を含む。３ＧＰＰ ＮＲ技術は、ＮＲ Ｖ２Ｘ技術及びインターフェース（例えば、サイドリンク通信など）を含む。

一実施形態では、ＲＡＮ１０３／１０４／１０５内の基地局１１４ａとＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと、又はＲＡＮ１０３ｂ／１０４ｂ／１０５ｂ内のＲＲＨ１１８ａ、１１８ｂ、ＴＲＰ１１９ａ、１１９ｂ、及び／若しくはＲＳＵ１２０ａ、１２０ｂとＷＴＲＵ１０２ｃ、１０２ｄ、１０２ｅ、１０２ｆとは、ＩＥＥＥ８０２．１６（例えば、ＷｉＭＡＸ（ワールドワイドインターオペラビリティフォーマイクロウェーブアクセス））、ＣＤＭＡ２０００、ＣＤＭＡ２０００ １Ｘ、ＣＤＭＡ２０００ＥＶ－ＤＯ、暫定規格２０００（ＩＳ－２０００）、暫定規格９５（ＩＳ－９５）、暫定規格８５６（ＩＳ－８５６）、ＧＳＭ（登録商標）（グローバルシステムフォーモバイルコミュニケーションズ）、ＥＤＧＥ（ＧＳＭ進化型高速データレート）、ＧＥＲＡＮ（ＧＳＭ ＥＤＧＥ）などの無線技術を実装することができる。

図２６Ａの基地局１１４ｃは、例えば、ワイヤレスルータ、ホームノードＢ、ホームｅノードＢ、又はアクセスポイントであってもよく、職場、家庭、車両、キャンパスなどの局所的エリアにおけるワイヤレス接続性を促進するために、任意の好適なＲＡＴを利用してもよい。一実施形態では、基地局１１４ｃ及びＷＴＲＵ１０２ｅは、ＩＥＥＥ８０２．１１などの無線技術を実装して、ワイヤレスローカルエリアネットワーク（ＷＬＡＮ）を確立することができる。一実施形態では、基地局１１４ｃ及びＷＴＲＵ１０２ｄは、ＩＥＥＥ８０２．１５などの無線技術を実装して、ワイヤレスパーソナルエリアネットワーク（ＷＰＡＮ）を確立することができる。更に別の実施形態では、基地局１１４ｃ及びＷＴＲＵ１０２ｅは、セルラーベースのＲＡＴ（例えば、ＷＣＤＭＡ、ＣＤＭＡ２０００、ＧＳＭ、ＬＴＥ、ＬＴＥ－Ａなど）を利用して、ピコセル又はフェムトセルを確立することができる。図２６Ａに示すように、基地局１１４ｂは、インターネット１１０への直接接続を有し得る。したがって、基地局１１４ｃは、コアネットワーク１０６／１０７／１０９を介してインターネット１１０にアクセスする必要がない場合がある。

ＲＡＮ１０３／１０４／１０５及び／又はＲＡＮ１０３ｂ／１０４ｂ／１０５ｂは、コアネットワーク１０６／１０７／１０９と通信することができ、該コアネットワーク１０６／１０７／１０９は、音声、データ、アプリケーション、及び／又はボイスオーバインターネットプロトコル（ＶｏＩＰ）サービスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのうちの１又は複数に提供するように構成された任意のタイプのネットワークであり得る。例えば、コアネットワーク１０６／１０７／１０９は、呼制御、課金サービス、モバイル位置情報サービス、プリペイド通話、インターネット接続、ビデオ配信などを提供し、かつ／又はユーザ認証などの高レベルのセキュリティ機能を実行することができる。

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

コアネットワーク１０６／１０７／１０９はまた、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄ、１０２ｅがＰＳＴＮ１０８、インターネット１１０、及び／又は他のネットワーク１１２にアクセスするためのゲートウェイとしての役割を果たすことができる。ＰＳＴＮ１０８は、従来の電話サービス（ＰＯＴＳ）を提供する回線交換電話網を含み得る。インターネット１１０は、ＴＣＰ／ＩＰインターネットプロトコルスイートにおける伝送制御プロトコル（ＴＣＰ）、ユーザデータグラムプロトコル（ＵＤＰ）、及びインターネットプロトコル（ＩＰ）などの共通通信プロトコルを使用する、相互接続されたコンピュータネットワーク及びデバイスのグローバルシステムを含み得る。ネットワーク１１２は、他のサービスプロバイダによって所有及び／又は運営される有線又はワイヤレス通信ネットワークを含み得る。例えば、ネットワーク１１２は、ＲＡＮ１０３／１０４／１０５及び／又はＲＡＮ１０３ｂ／１０４ｂ／１０５ｂと同じＲＡＴ又は異なるＲＡＴを使用し得る１又は複数のＲＡＮに接続された別のコアネットワークを含んでもよい。

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

図２６Ｂは、例えば、ＷＴＲＵ１０２など、本明細書で示される実施形態によるワイヤレス通信のために構成された例示的な装置又はデバイスのブロック図である。図２６Ｂに示すように、例示的なＷＴＲＵ１０２は、プロセッサ１１８、トランシーバ１２０、送信／受信要素１２２、スピーカ／マイクロフォン１２４、キーパッド１２６、ディスプレイ／タッチパッド／インジケータ１２８、非リムーバブルメモリ１３０、リムーバブルメモリ１３２、電源１３４、全地球測位システム（ＧＰＳ）チップセット１３６、及び他の周辺機器１３８を含み得る。ＷＴＲＵ１０２は、一実施形態との整合性を保ちながら、前述の要素の任意のサブコンビネーションを含み得ることが理解されよう。また、実施形態は、基地局１１４ａ及び１１４ｂ、並びに／又は基地局１１４ａ及び１１４ｂが表し得るノード、特に、限定されないが、トランシーバ局（ＢＴＳ）、ノードＢ、サイトコントローラ、アクセスポイント（ＡＰ）、ホームノードＢ、進化型ホームノードＢ（ｅＮｏｄｅＢ）、ホーム進化型ノードＢ（ＨｅＮＢ）、ホーム進化型ノードＢゲートウェイ、及びプロキシノードなどが、図２６Ｂに示されており、本明細書で説明される要素の一部又は全部を含み得ることを企図している。

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

送信／受信要素１２２は、エアインターフェース１１５／１１６／１１７を介して基地局（例えば、基地局１１４ａ）に信号を送信し、又は基地局から信号を受信するように構成することができる。例えば、一実施形態では、送信／受信要素１２２は、ＲＦ信号を送信及び／又は受信するように構成されたアンテナであってもよい。一実施形態では、送信／受信要素１２２は、例えば、ＩＲ、ＵＶ、又は可視光信号を送信及び／又は受信するように構成されるエミッタ／検出器であってもよい。更なる一実施形態では、送信／受信要素１２２は、ＲＦ信号と光信号との両方を送信及び受信するように構成されてもよい。送信／受信要素１２２は、ワイヤレス信号の任意の組み合わせを送信及び／又は受信するように構成され得ることが理解されよう。

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

トランシーバ１２０は、送信／受信要素１２２によって送信される信号を変調し、送信／受信要素１２２によって受信される信号を復調するように構成することができる。上述のように、ＷＴＲＵ１０２は、マルチモード能力を有し得る。したがって、トランシーバ１２０は、ＷＴＲＵ１０２が、例えば、ＵＴＲＡ及びＩＥＥＥ８０２．１１などの複数のＲＡＴを介して通信できるようにするための複数のトランシーバを含み得る。

ＷＴＲＵ１０２のプロセッサ１１８は、スピーカ／マイクロフォン１２４、キーパッド１２６、及び／又はディスプレイ／タッチパッド／インジケータ１２８（例えば、液晶ディスプレイ（ＬＣＤ）ディスプレイユニット又は有機発光ダイオード（ＯＬＥＤ）ディスプレイユニット）に結合することができ、それらからユーザ入力データを受信することができる。プロセッサ１１８はまた、スピーカ／マイクロフォン１２４、キーパッド１２６、及び／又はディスプレイ／タッチパッド／インジケータ１２８にユーザデータを出力することができる。加えて、プロセッサ１１８は、非リムーバブルメモリ１３０及び／又はリムーバブルメモリ１３２など、任意のタイプの適切なメモリからの情報にアクセスし、それらにデータを記憶することができる。非リムーバブルメモリ１３０は、ランダムアクセスメモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、ハードディスク、又は任意の他のタイプのメモリ記憶デバイスを含み得る。リムーバブルメモリ１３２は、加入者識別モジュール（ＳＩＭ）カード、メモリスティック、セキュアデジタル（ＳＤ）メモリカードなどを含み得る。一実施形態では、プロセッサ１１８は、サーバ又はホームコンピュータ（図示せず）上など、ＷＴＲＵ１０２上に物理的に配置されていないメモリからの情報にアクセスし、そのメモリにデータを記憶することができる。

プロセッサ１１８は、電源１３４から電力を受け取ることができ、ＷＴＲＵ１０２内の他の構成要素への電力を分散及び／又は制御するように構成することができる。電源１３４は、ＷＴＲＵ１０２に電力を供給するための任意の適切なデバイスであり得る。例えば、電源１３４は、１又は複数の乾電池、太陽電池、燃料電池などを含んでもよい。

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

プロセッサ１１８は、他の周辺機器１３８に更に結合することができ、該周辺機器１３８は、追加の特徴、機能、及び／又は有線若しくはワイヤレス接続性を提供する１又は複数のソフトウェアモジュール及び／又はハードウェアモジュールを含み得る。例えば、周辺機器１３８は、加速度計、バイオメトリクス（例えば、指紋）センサ、ｅコンパス、衛星トランシーバ、デジタルカメラ（写真又はビデオ用）、ユニバーサルシリアルバス（ＵＳＢ）ポート又は他の相互接続インターフェース、振動デバイス、テレビトランシーバ、ハンズフリーヘッドセット、ブルートゥース（登録商標）モジュール、周波数変調（ＦＭ）無線ユニット、デジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザなどの種々のセンサを含んでもよい。

ＷＴＲＵ１０２は、センサ、家庭用電子機器、スマートウォッチ又はスマート衣類などのウェアラブルデバイス、医療又はｅヘルスデバイス、ロボット、産業機器、ドローン、車、トラック、列車、又は飛行機などの車両など、他の装置又はデバイスにおいて具現化され得る。ＷＴＲＵ１０２は、周辺機器１３８のうちの１つを備え得る相互接続インターフェースなど、１又は複数の相互接続インターフェースを介して、かかる装置又はデバイスの他の構成要素、モジュール、又はシステムに接続することができる。

図２６Ｃは、一実施形態によるＲＡＮ１０３及びコアネットワーク１０６のシステム図である。上述のように、ＲＡＮ１０３は、ＵＴＲＡ無線技術を使用して、エアインターフェース１１５を介してＷＴＲＵ１０２ａ、１０２ｂ、及び１０２ｃと通信することができる。ＲＡＮ１０３はまた、コアネットワーク１０６と通信することができる。図２６Ｃに示されているように、ＲＡＮ１０３は、ノードＢ１４０ａ、１４０ｂ、１４０ｃを含むことができ、これらはそれぞれ、エアインターフェース１１５を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するための１又は複数のトランシーバを含み得る。ノードＢ１４０ａ、１４０ｂ、１４０ｃはそれぞれ、ＲＡＮ１０３内の特定のセル（図示せず）に関連付けられてもよい。ＲＡＮ１０３はまた、ＲＮＣ１４２ａ、１４２ｂを含み得る。ＲＡＮ１０３は、一実施形態との整合性を保ちながら、任意の数のノードＢ及びＲＮＣを含み得ることが理解されよう。

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

図２６Ｃに示されるコアネットワーク１０６は、メディアゲートウェイ（ＭＧＷ）１４４、モバイル交換センタ（ＭＳＣ）１４６、サービングＧＰＲＳサポートノード（ＳＧＳＮ）１４８、及び／又はゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）１５０を含み得る。前述の要素の各々は、コアネットワーク１０６の一部として示されているが、これらの要素のうちのいずれか１つが、コアネットワーク事業者以外のエンティティによって所有及び／又は運営され得ることが理解されよう。

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

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

上述したように、コアネットワーク１０６は、他のサービスプロバイダによって所有及び／又は運営される他の有線ネットワーク又はワイヤレスネットワークを含み得るネットワーク１１２にも接続され得る。

図２６Ｄは、一実施形態によるＲＡＮ１０４及びコアネットワーク１０７のシステム図である。上述のように、ＲＡＮ１０４は、Ｅ－ＵＴＲＡ無線技術を使用して、エアインターフェース１１６を介してＷＴＲＵ１０２ａ、１０２ｂ、及び１０２ｃと通信することができる。ＲＡＮ１０４はまた、コアネットワーク１０７と通信することができる。

ＲＡＮ１０４は、ｅノードＢ１６０ａ、１６０ｂ、１６０ｃを含むことができるが、ＲＡＮ１０４は、一実施形態との整合性を保ちながら、任意の数のｅノードＢを含み得ることが理解されよう。ｅノードＢ１６０ａ、１６０ｂ、１６０ｃはそれぞれ、エアインターフェース１１６を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するための１又は複数のトランシーバを含み得る。一実施形態では、ｅノードＢ１６０ａ、１６０ｂ、１６０ｃは、ＭＩＭＯ技術を実装することができる。したがって、ｅノードＢ１６０ａは、例えば、複数のアンテナを使用して、ＷＴＲＵ１０２ａにワイヤレス信号を送信し、ＷＴＲＵ１０２ａからワイヤレス信号を受信してもよい。

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

図２６Ｄに示すコアネットワーク１０７は、モビリティ管理ゲートウェイ（ＭＭＥ）１６２、サービングゲートウェイ１６４、及びパケットデータネットワーク（ＰＤＮ）ゲートウェイ１６６を含み得る。前述の要素の各々は、コアネットワーク１０７の一部として示されているが、これらの要素のうちのいずれか１つが、コアネットワーク事業者以外のエンティティによって所有及び／又は運営され得ることが理解されよう。

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

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

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

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

図２６Ｅは、一実施形態による、ＲＡＮ１０５及びコアネットワーク１０９のシステム図である。ＲＡＮ１０５は、エアインターフェース１１７を介してＷＴＲＵ１０２ａ、１０２ｂ、及び１０２ｃと通信するためにＩＥＥＥ８０２．１６無線技術を採用するアクセスサービスネットワーク（ＡＳＮ）であり得る。以下で更に説明するように、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、ＲＡＮ１０５、及びコアネットワーク１０９の異なる機能エンティティ間の通信リンクは、基準点として定義することができる。

図２６Ｅに示すように、ＲＡＮ１０５は、基地局１８０ａ、１８０ｂ、１８０ｃ、及びＡＳＮゲートウェイ１８２を含むことができるが、ＲＡＮ１０５は、一実施形態との整合性を保ちながら、任意の数の基地局及びＡＳＮゲートウェイを含み得ることが理解されよう。基地局１８０ａ、１８０ｂ、１８０ｃはそれぞれ、ＲＡＮ１０５内の特定のセルに関連付けることができ、エアインターフェース１１７を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するための１又は複数のトランシーバを含み得る。一実施形態では、基地局１８０ａ、１８０ｂ、１８０ｃは、ＭＩＭＯ技術を実装することができる。したがって、基地局１８０ａは、例えば、複数のアンテナを使用して、ＷＴＲＵ１０２ａにワイヤレス信号を送信し、ＷＴＲＵ１０２ａからワイヤレス信号を受信してもよい。基地局１８０ａ、１８０ｂ、１８０ｃはまた、ハンドオフトリガ、トンネル確立、無線リソース管理、トラフィック分類、サービス品質（ＱｏＳ）ポリシー施行などのモビリティ管理機能を提供することができる。ＡＳＮゲートウェイ１８２は、トラフィックアグリゲーションポイントとして機能することができ、ページング、加入者プロファイルのキャッシング、コアネットワーク１０９へのルーティングなどを担当することができる。

ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとＲＡＮ１０５との間のエアインターフェース１１７は、ＩＥＥＥ８０２．１６仕様を実装するＲ１基準点として定義することができる。加えて、ＷＴＲＵ１０２ａ、１０２ｂ、及び１０２ｃの各々は、コアネットワーク１０９との論理インターフェース（図示せず）を確立することができる。ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとコアネットワーク１０９との間の論理インターフェースは、認証、許可、ＩＰホスト構成管理、及び／又はモビリティ管理に使用され得るＲ２基準点として定義され得る。

基地局１８０ａ、１８０ｂ、及び１８０ｃの各々の間の通信リンクは、ＷＴＲＵハンドオーバ及び基地局間のデータの転送を容易にするためのプロトコルを含むＲ８基準点として定義することができる。基地局１８０ａ、１８０ｂ、１８０ｃとＡＳＮゲートウェイ１８２との間の通信リンクは、Ｒ６基準点として定義され得る。Ｒ６基準点は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃの各々に関連付けられたモビリティイベントに基づいてモビリティ管理を容易にするためのプロトコルを含み得る。

図２６Ｅに示されるように、ＲＡＮ１０５は、コアネットワーク１０９に接続され得る。ＲＡＮ１０５とコアネットワーク１０９との間の通信リンクは、例えば、データ転送及びモビリティ管理能力を容易にするためのプロトコルを含むＲ３基準点として定義され得る。コアネットワーク１０９は、モバイルＩＰホームエージェント（ＭＩＰ－ＨＡ）１８４、認証、許可、アカウンティング（ＡＡＡ）サーバ１８６、及びゲートウェイ１８８を含み得る。前述の要素の各々は、コアネットワーク１０９の一部として示されているが、これらの要素のうちのいずれか１つが、コアネットワーク事業者以外のエンティティによって所有及び／又は運営され得ることが理解されよう。

ＭＩＰ－ＨＡは、ＩＰアドレス管理を担当することができ、ＷＴＲＵ１０２ａ、１０２ｂ、及び１０２ｃが異なるＡＳＮ及び／又は異なるコアネットワークの間でローミングできるようにし得る。ＭＩＰ－ＨＡ１８４は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに、インターネット１１０などのパケット交換ネットワークへのアクセスを提供して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとＩＰ対応デバイスとの間の通信を容易にすることができる。ＡＡＡサーバ１８６は、ユーザ認証及びユーザサービスのサポートを担当することができる。ゲートウェイ１８８は、他のネットワークとの相互作用を容易にすることができる。例えば、ゲートウェイ１８８は、ＰＳＴＮ１０８などの回線交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと従来の陸線通信デバイスとの間の通信を容易にしてもよい。加えて、ゲートウェイ１８８は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに、他のサービスプロバイダによって所有及び／又は運営される他の有線ネットワーク又はワイヤレスネットワークを含み得るネットワーク１１２へのアクセスを提供することができる。

図２６Ｅには示されていないが、ＲＡＮ１０５は他のＡＳＮに接続されてもよく、コアネットワーク１０９は他のコアネットワークに接続されてもよいことが理解されよう。ＲＡＮ１０５と他のＡＳＮとの間の通信リンクは、Ｒ４基準点として定義することができ、これは、ＲＡＮ１０５と他のＡＳＮとの間のＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのモビリティを調整するためのプロトコルを含み得る。コアネットワーク１０９と他のコアネットワークとの間の通信リンクは、Ｒ５基準として定義され得、Ｒ５基準は、ホームコアネットワークと訪問先コアネットワークとの間の相互作用を容易にするためのプロトコルを含み得る。

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

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

動作中、プロセッサ９１は、命令をフェッチし、復号化し、実行し、コンピューティングシステムの主データ転送経路であるシステムバス８０を介して他のリソースとの間で情報を転送する。かかるシステムバスは、コンピューティングシステム９０内の構成要素を接続し、データ交換のための媒体を定義する。システムバス８０は、典型的には、データを送信するためのデータラインと、アドレスを送信するためのアドレスラインと、割込みを送信しシステムバスを動作させるための制御ラインとを含む。かかるシステムバス８０の一例は、ＰＣＩ（ペリフェラルコンポーネントインターコネクト）バスである。

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

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

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

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

図２６Ｇは、本明細書で説明され特許請求される方法及び装置が具現化され得る例示的な通信システム１１１の一実施形態を示している。図示のように、例示的な通信システム１１１は、ワイヤレス送信／受信ユニット（ＷＴＲＵ）Ａ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆ、基地局、Ｖ２Ｘサーバ、並びにＲＳＵ Ａ及びＢを含み得るが、開示される実施形態は、任意の数のＷＴＲＵ、基地局、ネットワーク、及び／又はネットワーク要素を企図することが理解されるであろう。１つ又は複数又は全てのＷＴＲＵ Ａ、Ｂ、Ｃ、Ｄ、Ｅは、ネットワークの範囲外にあり得る（例えば、図では、破線として示されるセルカバレッジ境界の外にある）。ＷＴＲＵ Ａ、Ｂ、ＣはＶ２Ｘグループを形成し、その中で、ＷＴＲＵ Ａはグループリードであり、ＷＴＲＵ Ｂ及びＣはグループメンバである。ＷＴＲＵ Ａ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆは、Ｕｕインターフェース又はサイドリンク（ＰＣ５）インターフェースを介して通信することができる。

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

〔附属書〕

Claims (20)

1. エッジアプリケーションハンドオーバクライアント（ＥＡＨＣ）をホストするユーザ機器（ＵＥ）であって、前記ＵＥは、プロセッサと、メモリと、通信回路とを備え、前記ＵＥは、前記通信回路を介して第１のネットワークに接続され、前記ＵＥは、前記メモリに記憶されたコンピュータ実行可能命令を更に備え、前記コンピュータ実行可能命令は、前記プロセッサによって実行されると、前記ＵＥに、
   １又は複数のアプリケーションクライアント（ＡＣ）からのアプリケーション情報を用いて前記ＥＡＨＣを構成することであって、前記ＡＣは、前記ＵＥ上に存在し、前記アプリケーション情報は、前記ＵＥの指定ルート又は前記ＵＥの予想ルートを含む、前記ＥＡＨＣを構成することと、
   前記ＥＡＨＣを使用して、前記ＵＥの指定ルート又は前記ＵＥの予想ルートを、３ＧＰＰネットワークと共有することと、
   前記３ＧＰＰネットワークから、前記ＵＥの移動に関する通知を受信することと、
   前記ＵＥの移動を、前記ＵＥの指定ルート又は前記ＵＥの予想ルートに沿って展開された複数のエッジアプリケーションサーバ（ＥＡＳ）と比較することと、
   前記ＥＡＨＣを使用して、かつ前記比較に基づいて、いつ前記ＥＡＨＣがエッジアプリケーションハンドオーバをトリガするかを決定することと、
   前記ＥＡＳ間のＡＣのシームレスなエッジアプリケーションハンドオーバのために、前記ＥＡＨＣを使用して、かつ前記決定に基づいて、支援を提供することと、
   を行わせる、
   ユーザ機器（ＵＥ）。
2. 前記ＥＡＨＣは、３ＧＰＰエッジイネーブラクライアント、３ＧＰＰ車車間／路車間（Ｖ２Ｘ）アプリケーションイネーブラクライアント、ｏｎｅＭ２Ｍ共通サービスエンティティ、ｏｎｅＭ２Ｍアプリケーションエンティティ（ＡＥ）、又はＬＷＭ２Ｍクライアントの専用機能又はサブ機能を備える、請求項１に記載のＵＥ。
3. 前記命令は、前記ＥＡＨＣに、
   コンテキスト情報を使用して、前記ＵＥの予想ルートを決定することと、
   前記予想ルート及び選択されたＵＥの位置に基づいて、前記ＡＣのハンドオフのための次のエッジアプリケーションサーバを決定することと、
   を更に行わせる、請求項１に記載のＵＥ。
4. 前記命令は、前記ＥＡＨＣに、
   前記ＡＣ、前記ＥＡＳ、及び前記ＡＣと前記ＥＡＳとを相互接続する１又は複数のネットワークの分析によってサービス要件及びコンテキスト情報を決定することと、
   シームレスなエッジアプリケーションハンドオーバのための前記支援を提供する際に、前記サービス要件及びコンテキスト情報を使用することと、
   を更に行わせる、請求項１に記載のＵＥ。
5. 前記命令は、前記ＥＡＨＣに、
   前記ＵＥ上の全てのＡＣのサービス要件及びコンテキスト情報をアグリゲートすることと、
   前記ＵＥ上の全てのＡＣにわたってエッジアプリケーションハンドオーバ決定を最適化することと、
   を更に行わせる、請求項１に記載のＵＥ。
6. 前記命令は、前記ＥＡＨＣに、前記第１のネットワーク内の１又は複数のエッジアプリケーションハンドオーバサーバ（ＥＡＨＳ）への要求を発行することを更に行わせ、前記要求は、エッジアプリケーションハンドオーバ動作の支援に関係する、請求項１に記載のＵＥ。
7. 前記命令は、前記ＥＡＨＣに、前記第１のネットワーク内のエッジアプリケーションハンドオーバサーバ（ＥＡＨＳ）へのサブスクリプション要求を発行することを更に行わせる、請求項１に記載のＵＥ。
8. 前記命令は、前記ＥＡＨＣに、前記ＥＡＨＳから、前記サブスクリプション要求に応答する通知を受信することを更に行わせる、請求項７に記載のＵＥ。
9. 前記命令は、前記ＥＡＨＣに、
   エッジアプリケーションハンドオーバ中に、エッジアプリケーションハンドオーバサーバ間のアプリケーションの状態同期又は移行を監視することと、
   前記アプリケーションの状態同期又は移行に基づいて、前記エッジアプリケーションハンドオーバが成功したかどうか、及び別のエッジアプリケーションハンドオーバが必要とされるかどうかを判定することと、
   を更に行わせる、請求項１に記載のＵＥ。
10. プロセッサと、メモリと、通信回路とを備えるエッジアプリケーションハンドオーバサーバ（ＥＡＨＳ）であって、前記ＥＡＨＳは、前記通信回路を介して第１のネットワークに接続され、前記ＥＡＨＳは、前記メモリに記憶されたコンピュータ実行可能命令を更に備え、前記コンピュータ実行可能命令は、前記プロセッサによって実行されると、前記ＥＡＨＳに、
    １又は複数のアプリケーションクライアント（ＡＣ）からのアプリケーション情報を用いてエッジアプリケーションハンドオーバ（ＥＡＨ）ポリシーを構成することであって、前記ＡＣは、ユーザ機器（ＵＥ）上に存在し、前記アプリケーション情報は、前記ＵＥの指定ルート又は前記ＵＥの予想ルートを含む、ことと、
    前記ＵＥの指定ルート又は前記ＵＥの予想ルートを、３ＧＰＰネットワークと共有することと、
    前記３ＧＰＰネットワークから、前記ＵＥの移動に関する通知を受信することと、
    前記ＵＥの移動を、前記ＵＥの指定ルート又は前記ＵＥの予想ルートに沿って展開された複数のエッジアプリケーションサーバ（ＥＡＳ）と比較することと、
    前記比較に基づいて、いつエッジアプリケーションハンドオーバをトリガするかを決定することと、
    前記ＥＡＳ間のＡＣのシームレスなエッジアプリケーションハンドオーバのために、前記決定に基づいて、支援を提供することと、
    を行わせる、
    エッジアプリケーションハンドオーバサーバ（ＥＡＨＳ）。
11. 前記ＥＡＨＳは、Ｖ２Ｘアプリケーションイネーブラサーバ、サービスイネーブラアーキテクチャ層サーバ、エッジイネーブラサーバ、エッジデータネットワーク構成サーバ、ｏｎｅＭ２Ｍ共通サービスエンティティ、又はＬＷＭ２Ｍサーバを備える、請求項１０に記載のＥＡＨＳ。
12. 前記命令は、前記ＥＡＨＳに、
    ３ＧＰＰシステム内の３ＧＰＰエンティティへのインターフェースをサポートすることと、
    前記３ＧＰＰエンティティから、コアネットワーク機能、アプリケーションクライアント、エッジイネーブラクライアント、エッジアプリケーションハンドオーバクライアント、Ｖ２Ｘアプリケーションイネーブラサーバ、サービスイネーブラアーキテクチャ層サーバ、エッジイネーブラサーバ、エッジデータネットワーク構成サーバ、ＯＮＥｍ２ｍ共通サービスエンティティ、及びＬＷＭ２Ｍサーバのうちの１又は複数に関する３ＧＰＰコンテキスト情報を受信することと、
    前記支援を提供する際に前記３ＧＰＰコンテキスト情報を使用することと、
    を更に行わせる、請求項１０に記載のＥＡＨＳ。
13. 前記命令は、前記ＥＡＨＳに、エッジアプリケーションハンドオーバクライアント（ＥＡＨＣ）をトリガし、ＡＣに代わってエッジアプリケーションハンドオーバ動作を実行し、エッジアプリケーションハンドオーバを実行する際に前記ＡＣを支援することを更に行わせる、請求項１０に記載のＥＡＨＳ。
14. 前記命令は、前記ＥＡＨＳに、第２のＵＥ上でホストされるＥＡＨＣから、前記ＥＡＨＳから通知を受信することに関係するサブスクリプション要求を受信することを更に行わせる、請求項１０に記載のＥＡＨＳ。
15. 前記命令は、前記ＥＡＨＳに、前記ＥＡＨＣへ、前記サブスクリプション要求に応答する通知を送信することを更に行わせる、請求項１４に記載のＥＡＨＳ。
16. 前記命令は、前記ＥＡＨＳに、
    管理機能へのインターフェースをサポートすることと、
    前記管理機能への前記インターフェースを介して、１又は複数の指定されたタイプのエッジアプリケーションサーバをホストすることができる利用可能なエッジノードを発見することと、
    を更に行わせる、請求項１０に記載のＥＡＨＳ。
17. 前記命令は、前記ＥＡＨＳに、前記管理機能に対して、選択されたＵＥのルートへの近接度に関するエッジノード基準を指定することを更に行わせる、請求項１６に記載のＥＡＨＳ。
18. 前記命令は、前記ＥＡＨＳに、エッジアプリケーションハンドオーバ中にエッジアプリケーションサーバ間で発生するアプリケーションの状態同期又は移行の動作を監視することを更に行わせる、請求項１０に記載のＥＡＨＳ。
19. 前記命令は、前記ＥＡＨＳに、
    コンテキスト情報を使用して、選択されたＵＥの予想ルートを決定することと、
    前記予想ルート及び前記選択されたＵＥの位置に基づいて、前記選択されたＵＥ上でホストされる１又は複数のアプリケーションクライアントのハンドオフのための次のエッジアプリケーションサーバを決定することと、
    を更に行わせる、請求項１０に記載のＥＡＨＳ。
20. 前記命令は、前記ＥＡＨＳに、
    前記３ＧＰＰネットワークへ、前記３ＧＰＰネットワークが予想ルートに沿って選択されたＵＥの移動を追跡する要求を送信することと、
    前記３ＧＰＰネットワークから、前記選択されたＵＥの前記移動に関する通知を受信することであって、前記通知は、前記予想ルートに沿ったウェイポイントの近傍内への前記選択されたＵＥの到着の表示、又は前記選択されたＵＥが前記予想ルートから逸脱したという表示のいずれかを含む、通知を受信することと、
    を更に行わせる、請求項１０に記載のＥＡＨＳ。