特許 7568868 アプリケーション関連機能のためのリソース割り当てステータスサブスクリプション

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

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

(11)【特許番号】

(24)【登録日】2024-10-07

(45)【発行日】2024-10-16

(54)【発明の名称】アプリケーション関連機能のためのリソース割り当てステータスサブスクリプション

(51)【国際特許分類】

   H04W 28/24 20090101AFI20241008BHJP

【ＦＩ】

H04W28/24

【請求項の数】 19

(21)【出願番号】P 2023543059

(86)(22)【出願日】2022-01-14

(65)【公表番号】

(43)【公表日】2024-01-24

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

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

(87)【国際公開日】2022-07-21

【審査請求日】2023-10-02

(31)【優先権主張番号】PCT/CN2021/072057

(32)【優先日】2021-01-15

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

(73)【特許権者】

【識別番号】598036300

【氏名又は名称】テレフオンアクチーボラゲット エルエム エリクソン（パブル）

(74)【代理人】

【識別番号】100109726

【弁理士】

【氏名又は名称】園田 吉隆

(74)【代理人】

【識別番号】100150670

【弁理士】

【氏名又は名称】小梶 晴美

(74)【代理人】

【識別番号】100194294

【弁理士】

【氏名又は名称】石岡 利康

(72)【発明者】

【氏名】シュ， ウェンリャン

【審査官】松原 徳久

(56)【参考文献】

【文献】国際公開第２０２０／０９８２４５（ＷＯ，Ａ１）

【文献】Huawei, HiSilicon, Ericsson，Correction to setting up an AF session with required QoS[online]，3GPP TSG SA WG2 #134 S2- 1908605，Internet<URL:https://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_134_Sapporo/Docs/S2-1908605.zip>，2019年09月04日

【文献】Huawei，Correction to Alternative QoS Parameter，3GPP TSG CT WG3 #112e C3-205453，2020年11月12日，https://www.3gpp.org/ftp/tsg_ct/WG3_interworking_ex-CN3/TSGC3_112e/Docs

【文献】SA2，Reply LS on Clarifications for the T8 interface[online]，3GPP TSG SA WG2 #123 S2-177802（２ページ目右上の「S2-177801」は誤記と考えられる），Internet<URL:http://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_123_Ljubljana/Docs/S2-177802.zip>，2017年10月30日

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

ＩＰＣ Ｈ０４Ｂ ７／２４－ ７／２６

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

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

ＳＡ ＷＧ１－４、６

ＣＴ ＷＧ１、４

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

【請求項1】

アプリケーション関連機能（ＡＲＦ）（１２００）の動作の方法であって、
リソース割り当てステータス通知が必要とされているかどうかを示すリソース割り当て確認表示を含む要求を公開機能（ＥＦ）（１２０２）へ送信すること（１２１０）を含み、前記リソース割り当てステータス通知がリソース割り当て成功またはリソース割り当て失敗を示す、方法。

【請求項2】

前記要求が、前記ＡＲＦがリソース割り当てステータスをサポートしているかどうかを示すリソース割り当てステータス特性をさらに含む、請求項１に記載の方法。

【請求項3】

前記ＡＲＦと前記ＥＦとの両方が前記リソース割り当てステータスをサポートしているかどうかを示すステータス応答特性を含む応答を前記ＥＦから受信すること（１２１８）をさらに含む、請求項２に記載の方法。

【請求項4】

前記リソース割り当て確認表示が、前記リソース割り当てステータス通知が前記ＡＲＦによって必要とされていることを示し、かつ、前記ステータス応答特性が、前記ＡＲＦと前記ＥＦとの両方が前記リソース割り当てステータスをサポートしていることを示すとき、前記応答がリソース割り当てステータス通知をさらに含む、請求項３に記載の方法。

【請求項5】

前記リソース割り当て確認表示が、前記リソース割り当てステータス通知が前記ＡＲＦによって要求されていないことを示し、かつ／または、前記ステータス応答特性が、前記ＡＲＦおよび前記ＥＦのうちの少なくとも一方が前記リソース割り当てステータスをサポートしていないことを示すとき、前記方法が、前記ＥＦからのリソース割り当てステータス通知を待機することを抑制すること（１２２０）をさらに含む、請求項３に記載の方法。

【請求項6】

前記リソース割り当て確認表示が、前記リソース割り当てステータス通知が前記ＡＲＦによって要求されていないことを示すとき、前記方法が、前記ＥＦからのリソース割り当てステータス通知を待機することを控えること（１２２０）をさらに含む、請求項５に記載の方法。

【請求項7】

前記ステータス応答特性が、前記ＡＲＦおよび前記ＥＦのうちの少なくとも一方が前記リソース割り当てステータスをサポートしていないことを示すとき、前記方法が、前記ＥＦからのリソース割り当てステータス通知を待機することを抑制すること（１２２０）をさらに含む、請求項５に記載の方法。

【請求項8】

前記要求が、
必要とされるＱｏＳを有するＡＳセッションもしくはＡＦセッションをセットアップするための要求、
必要とされるＱｏＳを有する前記ＡＳセッションもしくは前記ＡＦセッションを更新するための要求、
ＡＳセッションもしくはＡＦセッションのセットアップ時に課金先を設定するための要求、または
前記ＡＳセッションもしくは前記ＡＦセッション中に前記課金先を変更するための要求
であり、
前記応答のそれぞれが、
必要とされるＱｏＳを有するＡＳセッションもしくはＡＦセッションをセットアップするための応答、
必要とされるＱｏＳを有する前記ＡＳセッションもしくは前記ＡＦセッションを更新するための応答、
ＡＳセッションもしくはＡＦセッションのセットアップ時に課金先を設定するための応答、または
前記ＡＳセッションもしくは前記ＡＦセッション中に課金先を変更するための応答
である、請求項３から７のいずれか一項に記載の方法。

【請求項9】

前記リソース割り当て確認表示が、リソース割り当てステータス通知が必要とされているかどうかを示すために、ビットマスクが使用され、
前記リソース割り当てステータス特性が、前記ＡＲＦが前記リソース割り当てステータスをサポートしているかどうかを示すために、ビットマスクが使用され、かつ
前記ステータス応答特性が、前記ＡＲＦと前記ＥＦとの両方がリソース割り当てステータスをサポートしているかどうかを示すために、ビットマスクが使用される、請求項３から８のいずれか一項に記載の方法。

【請求項10】

前記ＡＲＦが第５世代システム内にあり、
前記ＡＲＦがアプリケーション機能（ＡＦ）（１１００）であり、かつ
前記ＥＦがネットワーク公開機能（ＮＥＦ）（１１０２）である、請求項３から９のいずれか一項に記載の方法。

【請求項11】

前記要求が、
必要とされるＱｏＳを有するＡＦセッションをセットアップするための要求、
必要とされるＱｏＳを有する前記ＡＦセッションを更新するための要求、
ＡＦセッションのセットアップ時に課金先を設定するための要求、または
前記ＡＦセッション中に前記課金先を変更するための要求
であり、
前記応答のそれぞれが、
必要とされるＱｏＳを有するＡＦセッションをセットアップするための応答、
必要とされるＱｏＳを有する前記ＡＦセッションを更新するための応答、
ＡＦセッションのセットアップ時に課金先を設定するための応答、または
前記ＡＦセッション中に前記課金先を変更するための応答
である、請求項１０に記載の方法。

【請求項12】

前記ＡＲＦが、第４世代システム内にあり、
前記ＡＲＦが、サービス能力サーバまたはアプリケーションサーバ（ＳＣＳ／ＡＳ）（１０００）であり、かつ
前記ＥＦがサービス能力公開機能（ＳＣＥＦ）（１１０２）である、請求項３から８のいずれか一項に記載の方法。

【請求項13】

前記要求が、
必要とされるＱｏＳを有するＡＳセッションをセットアップするための要求、
必要とされるＱｏＳを有する前記ＡＳセッションを更新するための要求、
ＡＳセッションのセットアップ時に課金先を設定するための要求、または
前記ＡＳセッション中に前記課金先を変更するための要求
であり、
前記応答のそれぞれが、
必要とされるＱｏＳを有するＡＳセッションをセットアップするための応答、
必要とされるＱｏＳを有する前記ＡＳセッションを更新するための応答、
ＡＳセッションのセットアップ時に課金先を設定するための応答、または
前記ＡＳセッション中に前記課金先を変更するための応答
である、請求項１２に記載の方法。

【請求項14】

請求項１から１３のいずれか一項に記載の方法を実施するように適合された、アプリケーション関連機能（ＡＲＦ）（１２００）。

【請求項15】

アプリケーション関連機能（ＡＲＦ）（１２００）を実装するネットワークノード（１３００）であって、
ネットワークインターフェース（１３０８）と、
前記ネットワークインターフェースに関連付けられた処理回路（１３０４）と
を備え、前記処理回路が、前記ネットワークノードに、
リソース割り当てステータス通知が必要とされているかどうかを示すリソース割り当て確認表示を含む要求を公開機能（ＥＦ）（１２０２、１００２、１１０２）へ送信させる（１２１０）ように設定され、前記リソース割り当てステータス通知がリソース割り当て成功またはリソース割り当て失敗を示す、ネットワークノード（１３００）。

【請求項16】

前記要求が、前記ＡＲＦがリソース割り当てステータスをサポートしているかどうかを示すリソース割り当てステータス特性をさらに含む、請求項１５に記載のネットワークノード。

【請求項17】

前記処理回路が、前記ネットワークノードに、前記ＡＲＦと前記ＥＦとの両方が前記リソース割り当てステータスをサポートしているかどうかを示すステータス応答特性を含む応答を前記ＥＦからさらに受信させる（１２１８）ように設定された、請求項１６に記載のネットワークノード。

【請求項18】

公開機能（ＥＦ）（１２０２）の動作の方法であって、
リソース割り当てステータス通知が必要とされているかどうかを示すリソース割り当て確認表示を含む要求をアプリケーション関連機能（ＡＲＦ）（１２００）から受信すること（１２１０）を含み、前記リソース割り当てステータス通知がリソース割り当て成功またはリソース割り当て失敗を示す、方法。

【請求項19】

公開機能（ＥＦ）（１２０２）を実装するネットワークノード（１３００）であって、
ネットワークインターフェース（１３０８）と、
前記ネットワークインターフェースに関連付けられた処理回路（１３０４）と
を備え、前記処理回路が、前記ネットワークノードに、
リソース割り当てステータス通知が必要とされているかどうかを示すリソース割り当て確認表示を含む要求をアプリケーション関連機能（ＡＲＦ）（１２００）から受信させる（１２１０）ように設定され、前記リソース割り当てステータス通知がリソース割り当て成功またはリソース割り当て失敗を示す、ネットワークノード（１３００）。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、セルラ通信システムにおけるアプリケーション関連機能（ＡＲＦ）と公開機能（ＥＦ）との間の相互運用性の問題を解決することに関し、詳細には、ＡＲＦのためのリソース割り当てステータスサブスクリプションにおける問題を解決することに関する。

【背景技術】

【0002】

一般に、本明細書で使用されるすべての用語は、異なる意味が明確に与えられている、かつ／または、その用語が使用される文脈から異なる意味が示唆される場合を除き、関連する技術分野におけるその用語の通常の意味に従って解釈されるべきである。エレメント、装置、構成要素、手段、ステップなどに対するすべての参照は、別段の明示的な提示がない限り、エレメント、装置、構成要素、手段、ステップなどの少なくとも１つの事例を指すものとオープンに解釈されるべきである。本明細書に開示されるいかなる方法のステップも、あるステップが別のステップに後続もしくは先行するものとして明示的に記載されている、および／またはあるステップが別のステップに後続もしくは先行しなければならないことが暗示されている場合を除き、開示される正確な順序で実行される必要はない。本明細書に開示される実施形態のいずれかの任意の特徴は、適切な場合はいつでも、他の任意の実施形態に適用され得る。同様に、実施形態のいずれかの任意の利点は、他の任意の実施形態に適用され得、逆もまた同様である。同封された実施形態の他の目的、特徴、および利点は、以下の説明から明らかになろう。

【0003】

４Ｇにおけるネットワーク能力の外部公開
ＥＰＣにおけるネットワーク能力の外部公開は、ＭＴＣ（マシン型通信）によって推進された。図１に示されるように、サービス能力公開機能（ＳＣＥＦ）は、３ＧＰＰネットワークインターフェースによって提供されるサービスおよび能力をセキュアに公開するための手段を提供する。ＳＣＥＦは、公開されたサービスおよび能力を発見するための手段を提供する。ＳＣＥＦは、Ｔ８インターフェース上で規定されたホモジニアスネットワークアプリケーションプログラミングインターフェース（例えば、ネットワークＡＰＩ）を通してネットワーク能力へのアクセスを提供する。ＳＣＥＦは、基盤となる３ＧＰＰネットワークインターフェースおよびプロトコルからサービスを抽象化する。Ｔ８は、ＳＣＥＦとサービス能力サーバまたはアプリケーションサーバ（ＳＣＳ／ＡＳ）との間のインターフェースである。ＳＣＥＦが公開したネットワークサービスは、Ｔ８インターフェース上のＡＰＩを通してＳＣＳ／ＡＳによってアクセスされ得る（ＴＳ２３．６８２、４．２節を参照）。

【0004】

サードパーティＳＣＳ／ＡＳは、サードパーティサービスプロバイダによってサーブされるＵＥへのデータセッション（ＡＳセッション）が特定のＱｏＳ（例えば、低レイテンシまたはジッタ）および優先順位ハンドリングとともにセットアップされるように要求し得る。この機能は、ＳＣＥＦを介してＳＣＳ／ＡＳに公開される。図２に図示されるように、ＳＣＳ／ＡＳは、あらかじめ規定されたＱｏＳ情報を参照するＱｏＳ参照パラメータを利用して、アプリケーションおよびサービス要件に基づいてＡＳセッションにＱｏＳを提供するようネットワークに要求することができる。ＳＣＥＦが、ＡＳセッションにＱｏＳを提供するよう求める要求をＳＣＳ／ＡＳから受信すると、ＳＣＥＦは、ＴＳ２３．２０３［２７］仕様に従ってＡＦとして作用し、ＡＳセッションにＱｏＳを提供するよう求める要求を、Ｒｘインターフェースを介してポリシおよび課金ルール機能（ＰＣＲＦ）に転送する。ＳＣＥＦがＲｘセッションのベアラレベルイベントについて通知された（例えば、送信リソースが解放／喪失された）場合、ＳＣＥＦは、ＲｘセッションのベアラレベルイベントについてＳＣＳ／ＡＳに通知するものとする（ＴＳ２３．６８２、４．５．１１節および５．１１節を参照）。

【0005】

ＳＣＳ／ＡＳは、サードパーティサービスプロバイダによってサーブされるＵＥのデータセッション（ＡＳセッション）をスポンサ提供することを開始または停止するよう、すなわち、サードパーティサービスプロバイダのいずれかがトラフィックに対して課金されるか（開始）、課金されないか（停止）を認識するよう、ＳＣＥＦに要求し得る。図３に図示されるように、ＳＣＳ／ＡＳは、ＡＳセッションのセットアップ時に課金先として設定されるように、すなわち、トラフィックをスポンサ提供するように、または進行中のＡＳセッション中に課金先を変更するよう要求し得る。ＳＣＥＦはＡＦとして作用し、スポンサ提供されるデータコネクティビティについてＴＳ２３．２０３［２７］において規定されている既存の機能が、この機能をサポートするために使用される。ＳＣＥＦが、（例えば、ＰＤＮ接続の解放に起因して）Ｒｘセッションが終了したとの通知を受けた場合、ＳＣＥＦは、それについてＳＣＳ／ＡＳに通知し、ＰＣＲＦから受信された任意の累積された使用量報告をフォワーディングするものとする（ＴＳ２３．６８２、４．５．１２節および５．１２節を参照）。

【0006】

５Ｇにおけるネットワーク能力の外部公開
図４に示されるように、ネットワーク公開機能（ＮＥＦ）は、ネットワーク機能の能力の外部公開をサポートする。外部公開は、監視能力、プロビジョニング能力、ポリシ／課金能力、および分析報告能力として分類され得る。監視能力は、５Ｇシステム内のＵＥの特定のイベントを監視し、そのような監視イベント情報をＮＥＦを介して外部公開できるようにするためのものである。プロビジョニング能力は、５Ｇシステム内のＵＥのために使用され得る情報を外部当事者がプロビジョニングできるようにするためのものである。ポリシ／課金能力は、外部当事者からの要求に基づいてＵＥのＱｏＳおよび課金ポリシをハンドリングするためのものである。分析報告能力、外部当事者が５Ｇシステムによって生成された分析情報を、フェッチまたはサブスクライブ／サブスクライブ解除できるようにするためのものである。ポリシ／課金能力は、セッションおよび課金ポリシについての要求を許可し、ＱｏＳポリシを施行し、アカウンティング機能を適用する手段で構成される。これは、ＵＥのセッションのための特定のＱｏＳ／優先順位のハンドリング、および適用可能な課金先または課金レートの設定に使用され得る。Ｎ３３参照ポイントは、ＡＦに対するＴ８インターフェースと同等のＡＰＩを提供する（ＴＳ２３．５０１、５．２０節を参照）。

【0007】

５ＧにおけるＡＦにより要求されるＱｏＳは、ＴＳ２９．１２２（４．４．１３節）におけるＳＣＥＦ Ｔ８ ＡＰＩを再利用している、ＴＳ２９．５２２（４．４．９節）におけるＮＥＦ Ｎ３３ ＡＰＩによってサポートされている。図５および図６は、ＴＳ２３．５０２、４．１５．６．６節における必要とされるＱｏＳ手順を有するＡＦセッションのセットアップ、およびＴＳ２３．５０２、４．１５．６．６ａ節における必要とされるＱｏＳ手順を有するＡＦセッションの更新のための情報フローである。

【0008】

課金先の設定は、ＴＳ２９．１２２（４．４．４節）におけるＳＣＥＦ Ｔ８ ＡＰＩを再利用している、ＴＳ２９．５２２（４．４．８節）におけるＮＥＦ Ｎ３３ ＡＰＩによってサポートされている。これに対応して、図７および図８は、ＴＳ２３．５０２、４．１５．６．４節および４．１５．６．５節におけるＡＦセッションセットアップ時およびＡＦセッション更新中の課金先手順の設定に関する情報フローである。

【0009】

既存の解決策に関する問題
既存の技術（３ＧＰＰ ＴＳ２９．１２２ リリース１６）では、公開機能（ＮＥＦまたはＳＣＥＦなど）は、リソース割り当てステータス（リソース割り当て成功またはリソース割り当て失敗）のイベント通知をアプリケーション関連機能（ＡＦまたはＳＣＳ／ＡＳなど）へ送信し得る。しかし、このようなイベントは、プレリリース１６バージョンでは指定されていない。したがって、（リリース１６バージョン以降の）アプリケーション関連機能が（プレリリース１６バージョンの）公開機能と通信するとき、（リリース１６バージョン以降の）アプリケーション関連機能がリソース割り当てステータスのイベント通知を受信することを期待しているが、（プレリリース１６バージョンの）公開機能ではそのようなイベントがサポートされていない場合、（リリース１６バージョン以降の）アプリケーション関連機能は無限に待機することになる。

【0010】

加えて、公開機能がリソース割り当てステータスイベント（リソース割り当て成功またはリソース割り当て失敗）をサポートしている場合でも、公開機能はさらに、イベント通知をアプリケーション関連機能へ送信しないことがある。したがって、アプリケーション関連機能は、成功または失敗したリソース割り当ての結果を永久に待機することになる。

【発明の概要】

【0011】

本開示およびその実施形態の特定の態様は、前述の課題または他の課題に対する解決策を提供し得る。本明細書では、アプリケーション関連機能のリソース割り当てステータスサブスクリプションにおける問題を解決するためにリソース割り当て確認表示およびリソース割り当てステータス特性が使用される方法ならびに装置が開示される。

【0012】

本明細書で開示される問題のうちの１つまたは複数に対処する様々な実施形態が、本明細書で提案される。一実施形態では、アプリケーション関連機能（ＡＲＦ）の動作の方法は、要求を公開機能（ＥＦ）へ送信することを含む。本明細書では、要求は、リソース割り当てステータス通知が必要とされているかどうかを示すリソース割り当て確認表示を含む。リソース割り当てステータス通知は、リソース割り当て成功またはリソース割り当て失敗を示す。

【0013】

一実施形態では、要求は、ＡＲＦがリソース割り当てステータスをサポートしているかどうかを示すリソース割り当てステータス特性をさらに含む。

【0014】

一実施形態では、ＡＲＦの動作の方法は、ステータス応答特性を含む応答をＥＦから受信することをさらに含む。本明細書では、ステータス応答特性は、ＡＲＦとＥＦとの両方がリソース割り当てステータスをサポートしているかどうかを示す。

【0015】

一実施形態では、リソース割り当て確認表示が、リソース割り当てステータス通知がＡＲＦによって必要とされていることを示し、かつ、ステータス応答特性が、ＡＲＦとＥＦとの両方がリソース割り当てステータスをサポートしていることを示すとき、応答は、リソース割り当てステータス通知をさらに含む。

【0016】

一実施形態では、リソース割り当て確認表示が、リソース割り当てステータス通知がＡＲＦによって要求されていないことを示し、かつ／または、ステータス応答特性が、ＡＲＦおよびＥＦのうちの少なくとも一方がリソース割り当てステータスをサポートしていないことを示すとき、方法は、ＥＦからのリソース割り当てステータス通知を待機することを抑制することをさらに含む。

【0017】

一実施形態では、リソース割り当て確認表示が、リソース割り当てステータス通知がＡＲＦによって要求されていないことを示すとき、方法は、ＥＦからのリソース割り当てステータス通知を待機することを抑制することをさらに含む。

【0018】

一実施形態では、ステータス応答特性が、ＡＲＦおよびＥＦのうちの少なくとも一方がリソース割り当てステータスをサポートしていないことを示すとき、方法は、ＥＦからのリソース割り当てステータス通知を待機することを抑制することをさらに含む。

【0019】

一実施形態では、要求は、必要とされるＱｏＳを有するＡＳセッションもしくはＡＦセッションをセットアップするための要求、必要とされるＱｏＳを有するＡＳセッションもしくはＡＦセッションを更新するための要求、ＡＳセッションもしくはＡＦセッションのセットアップ時に課金先を設定するための要求、またはＡＳセッションもしくはＡＦセッション中に課金先を変更するための要求であり、応答が、必要とされるＱｏＳを有するＡＳセッションもしくはＡＦセッションをセットアップするための応答、必要とされるＱｏＳを有するＡＳセッションもしくはＡＦセッションを更新するための応答、ＡＳセッションもしくはＡＦセッションのセットアップ時に課金先を設定するための応答、またはＡＳセッションもしくはＡＦセッション中に課金先を変更するための要求である。

【0020】

一実施形態では、リソース割り当て確認表示が、リソース割り当てステータス通知が必要とされているかどうかを示すために、ビットマスクが使用され、リソース割り当てステータス特性が、ＡＲＦがリソース割り当てステータスをサポートしているかどうかを示すために、ビットマスクが使用され、ステータス応答特性が、ＡＲＦとＥＦとの両方がリソース割り当てステータスをサポートしているかどうかを示すために、ビットマスクが使用される。

【0021】

一実施形態では、ＡＲＦは、第５世代システム内にある。ＡＲＦはアプリケーション機能（ＡＦ）であり、ＥＦはネットワーク公開機能（ＮＥＦ）である。

【0022】

一実施形態では、要求は、必要とされるＱｏＳを有するＡＦセッションをセットアップするための要求、必要とされるＱｏＳを有するＡＦセッションを更新するための要求、ＡＦセッションのセットアップ時に課金先を設定するための要求、またはＡＦセッション中に課金先を変更するための要求であり、応答は、必要とされるＱｏＳを有するＡＦセッションをセットアップするための応答、必要とされるＱｏＳを有するＡＦセッションを更新するための応答、ＡＦセッションのセットアップ時に課金先を設定するための応答、またはＡＦセッション中に課金先を変更するための要求である。

【0023】

一実施形態では、ＡＲＦは、第４世代システム内にある。ＡＲＦは、サービス能力サーバまたはアプリケーションサーバ（ＳＣＳ／ＡＳ）であり、ＥＦは、サービス能力公開機能（ＳＣＥＦ）である。

【0024】

一実施形態では、要求は、必要とされるＱｏＳを有するＡＳセッションをセットアップするための要求、必要とされるＱｏＳを有するＡＳセッションを更新するための要求、ＡＳセッションのセットアップ時に課金先を設定するための要求、またはＡＳセッション中に課金先を変更するための要求であり、応答は、必要とされるＱｏＳを有するＡＳセッションをセットアップするための応答、必要とされるＱｏＳを有するＡＳセッションを更新するための応答、ＡＳセッションのセットアップ時に課金先を設定するための応答、またはＡＳセッション中に課金先を変更するための要求である。

【0025】

ＡＲＦの対応する実施形態も開示される。一実施形態では、ＡＲＦは、ＥＦへ要求を送信し、ＥＦから応答を受信するように適合される。本明細書では、要求は、リソース割り当てステータス通知が必要とされているかどうかを示すリソース割り当て確認表示と、ＡＲＦがリソース割り当てステータスをサポートしているかどうかを示すリソース割り当てステータス特性とを含む。リソース割り当てステータス通知は、リソース割り当て成功またはリソース割り当て失敗を示す。応答は、ＡＲＦとＥＦとの両方がリソース割り当てステータスをサポートしているかどうかを示すステータス応答特性を含む。

【0026】

一実施形態では、ＡＲＦを実装するネットワークノードは、ネットワークインターフェースと、ネットワークインターフェースに関連付けられた処理回路とを備える。処理回路は、ネットワークノードに、ＥＦへ要求を送信させ、ＥＦから応答を受信させるように設定される。本明細書では、要求は、リソース割り当てステータス通知が必要とされているかどうかを示すリソース割り当て確認表示と、ＡＲＦがリソース割り当てステータスをサポートしているかどうかを示すリソース割り当てステータス特性とを含む。応答は、ＡＲＦとＥＦとの両方がリソース割り当てステータスをサポートしているかどうかを示すステータス応答特性を含む。

【0027】

一実施形態では、ＥＦの動作の方法は、ＡＲＦから要求を受信することを含む。本明細書では、要求は、リソース割り当てステータス通知が必要とされているかどうかを示すリソース割り当て確認表示を含む。リソース割り当てステータス通知は、リソース割り当て成功またはリソース割り当て失敗を示す。

【0028】

一実施形態では、要求は、ＡＲＦがリソース割り当てステータスをサポートしているかどうかを示すリソース割り当てステータス特性をさらに含む。

【0029】

一実施形態では、ＥＦの動作の方法は、ステータス応答特性を含む応答をＥＦから送信することをさらに含む。本明細書では、ステータス応答特性は、ＡＲＦとＥＦとの両方がリソース割り当てステータスをサポートしているかどうかを示す。

【0030】

一実施形態では、リソース割り当て確認表示が、リソース割り当てステータス通知がＡＲＦによって必要とされていることを示し、かつ、ステータス応答特性が、ＡＲＦとＥＦとの両方がリソース割り当てステータスをサポートしていることを示すとき、応答は、リソース割り当てステータス通知をさらに含む。

【0031】

一実施形態では、リソース割り当て確認表示が、リソース割り当てステータス通知がＡＲＦによって要求されていないことを示し、かつ／または、ステータス応答特性が、ＡＲＦおよびＥＦのうちの少なくとも一方がリソース割り当てステータスをサポートしていないことを示すとき、方法は、ＥＦからのリソース割り当てステータス通知を待機することを抑制することをさらに含む。

【0032】

一実施形態では、リソース割り当て確認表示が、リソース割り当てステータス通知がＡＲＦによって要求されていないことを示すとき、方法は、ＥＦからのリソース割り当てステータス通知を待機することを抑制することをさらに含む。

【0033】

一実施形態では、ステータス応答特性が、ＡＲＦおよびＥＦのうちの少なくとも一方がリソース割り当てステータスをサポートしていないことを示すとき、方法は、ＥＦからのリソース割り当てステータス通知を待機することを抑制することをさらに含む。

【0034】

一実施形態では、要求は、必要とされるＱｏＳを有するＡＳセッションもしくはＡＦセッションをセットアップするための要求、必要とされるＱｏＳを有するＡＳセッションもしくはＡＦセッションを更新するための要求、ＡＳセッションもしくはＡＦセッションのセットアップ時に課金先を設定するための要求、またはＡＳセッションもしくはＡＦセッション中に課金先を変更するための要求であり、応答が、必要とされるＱｏＳを有するＡＳセッションもしくはＡＦセッションをセットアップするための応答、必要とされるＱｏＳを有するＡＳセッションもしくはＡＦセッションを更新するための応答、ＡＳセッションもしくはＡＦセッションのセットアップ時に課金先を設定するための応答、またはＡＳセッションもしくはＡＦセッション中に課金先を変更するための要求である。

【0035】

一実施形態では、リソース割り当て確認表示が、リソース割り当てステータス通知が必要とされているかどうかを示すために、ビットマスクが使用され、リソース割り当てステータス特性が、ＡＲＦがリソース割り当てステータスをサポートしているかどうかを示すために、ビットマスクが使用され、ステータス応答特性が、ＡＲＦとＥＦとの両方がリソース割り当てステータスをサポートしているかどうかを示すために、ビットマスクが使用される。

【0036】

一実施形態では、ＡＲＦは、第５世代システム内にある。ＡＲＦはＡＦであり、ＥＦはＮＥＦである。

【0037】

一実施形態では、要求は、必要とされるＱｏＳを有するＡＦセッションをセットアップするための要求、必要とされるＱｏＳを有するＡＦセッションを更新するための要求、ＡＦセッションのセットアップ時に課金先を設定するための要求、またはＡＦセッション中に課金先を変更するための要求であり、応答は、必要とされるＱｏＳを有するＡＦセッションをセットアップするための応答、必要とされるＱｏＳを有するＡＦセッションを更新するための応答、ＡＦセッションのセットアップ時に課金先を設定するための応答、またはＡＦセッション中に課金先を変更するための要求である。

【0038】

一実施形態では、ＡＲＦは、第４世代システム内にある。ＡＲＦはＳＣＳ／ＡＳであり、ＥＦはＳＣＥＦである。

【0039】

一実施形態では、要求は、必要とされるＱｏＳを有するＡＳセッションをセットアップするための要求、必要とされるＱｏＳを有するＡＳセッションを更新するための要求、ＡＳセッションのセットアップ時に課金先を設定するための要求、またはＡＳセッション中に課金先を変更するための要求であり、応答は、必要とされるＱｏＳを有するＡＳセッションをセットアップするための応答、必要とされるＱｏＳを有するＡＳセッションを更新するための応答、ＡＳセッションのセットアップ時に課金先を設定するための応答、またはＡＳセッション中に課金先を変更するための要求である。

【0040】

一実施形態では、ＥＦの動作の方法は、要求を受信した後、リソース割り当てステータスがＥＦによってサポートされているかどうかを判定することをさらに含む。

【0041】

一実施形態では、ＥＦの動作の方法は、ＡＲＦからの要求を認可することをさらに含む。

【0042】

一実施形態では、ＥＦの動作の方法は、認可が与えられたとき、ポリシ機能（ＰＦ）と対話することをさらに含む。

【0043】

一実施形態では、ＰＦは、ポリシおよび課金ルール機能（ＰＣＲＦ）またはポリシ制御機能（ＰＣＦ）である。

【0044】

一実施形態では、リソース割り当てステータスがＡＲＦおよびＥＦのうちの少なくとも一方によってサポートされていないとき、ＥＦは、リソース割り当てステータス通知を取得するためにＰＦをサブスクライブするが、リソース割り当てステータス通知をＡＲＦに送信しない。

【0045】

一実施形態では、ＡＲＦとＥＦとの両方がリソース割り当てステータスをサポートしているとき、リソース割り当てステータス通知がＡＲＦによって必要とされている場合にのみ、ＥＦは、リソース割り当てステータス通知を取得するためにＰＦをサブスクライブする。

【0046】

ＥＦの対応する実施形態も開示される。一実施形態では、ＥＦは、ＡＲＦから要求受信し、ＡＲＦへ応答を送信するように適合される。本明細書では、要求は、リソース割り当てステータス通知が必要とされているかどうかを示すリソース割り当て確認表示と、ＡＲＦがリソース割り当てステータスをサポートしているかどうかを示すリソース割り当てステータス特性とを含む。リソース割り当てステータス通知は、リソース割り当て成功またはリソース割り当て失敗を示す。応答は、ＡＲＦとＥＦとの両方がリソース割り当てステータスをサポートしているかどうかを示すステータス応答特性を含む。

【0047】

一実施形態では、ＥＦを実装するネットワークノードは、ネットワークインターフェースと、ネットワークインターフェースに関連付けられた処理回路とを備える。処理回路は、ネットワークノードに、ＡＲＦから要求を受信させ、ＡＲＦへ応答を送信させるように設定される。本明細書では、要求は、リソース割り当てステータス通知が必要とされているかどうかを示すリソース割り当て確認表示と、ＡＲＦがリソース割り当てステータスをサポートしているかどうかを示すリソース割り当てステータス特性とを含む。応答は、ＡＲＦとＥＦとの両方がリソース割り当てステータスをサポートしているかどうかを示すステータス応答特性を含む。

【0048】

ある特定の実施形態は、以下の（１つまたは複数の）技術的利点のうちの１つまたは複数を提供することができる。例えば、特定の実施形態は、ＡＲＦとＥＦとの間の相互運用性の問題を解決する。ＡＲＦは、リソース割り当て失敗またはリソース割り当て成功を示すリソース割り当てステータス通知を、そのような通知を送信することをサポートしていないＥＦから受信することを期待している場合でも、無限に待機することはない。

【0049】

本明細書に組み込まれ、本明細書の一部を形成する添付図面は、本開示のいくつかの態様を図示し、説明とともに本開示の原理を解説する役割を果たす。

【図面の簡単な説明】

【0050】

【図1】４Ｇネットワークにおけるサービス能力公開機能のためのアーキテクチャを示す図である。

【図2】必要とされるＱｏＳを有するＡＳセッションをセットアップするための手順を示す図である。

【図3】ＡＳセッションセットアップ時またはＡＳセッション中に課金先を設定または変更するための手順をそれぞれ示す図である。

【図4】５Ｇネットワークにおけるネットワーク公開機能ためのアーキテクチャを示す図である。

【図5】必要とされるＱｏＳを有するＡＦセッションをセットアップするための手順を示す図である。

【図6】必要とされるＱｏＳを有するＡＦセッションを更新するための手順を示す図である。

【図7】ＡＦセッションセットアップ時に課金先を設定するための手順を示す図である。

【図8】ＡＳセッション中に課金先を変更するための手順を示す図である。

【図9】本開示のいくつかの実施形態による、セルラ通信システムの一例を示す図である。

【図10】４Ｇネットワークにおけるサービス能力公開機能のためのアーキテクチャの一例を示す図である。

【図11】５Ｇネットワークにおけるネットワーク公開機能のためのアーキテクチャの一例を示す図である。

【図12A-12C】本開示のいくつかの実施形態による、図１０または図１１に示されるアーキテクチャ内の動作を示す図である。

【図13】本開示のいくつかの実施形態による、ネットワークノードの概略ブロック図である。

【図14】本開示のいくつかの実施形態による、図１３のネットワークノードの仮想化された実施形態を示す概略ブロック図である。

【図15】本開示のいくつかの他の実施形態による、図１３のネットワークノードの概略ブロック図である。

【図16】本開示のいくつかの実施形態による、中間ネットワークを介してホストコンピュータに接続された通信ネットワークを示す図である。

【図17】本開示のいくつかの実施形態による、部分的無線接続上で基地局を介してＵＥと通信するホストコンピュータの一般化されたブロック図である。

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

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

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

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

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

【0051】

以下に記載される実施形態は、当業者が実施形態を実践することを可能にするための情報を表しており、実施形態を実践する最良の態様を例示したものである。添付図面に照らして以下の説明を読むことで、当業者は、本開示の概念を理解し、本明細書で詳細に扱われていないこれらの概念の応用を認識するであろう。これらの概念および応用は、本開示の範囲内に入ると理解されるべきである。

【0052】

無線ノード：本明細書で使用される「無線ノード」は、無線アクセスノードまたは無線通信デバイスのどちらかである。

【0053】

無線アクセスノード：本明細書で使用される「無線アクセスノード」または「無線ネットワークノード」または「無線アクセスネットワークノード」は、信号を無線で送信および／または受信するように動作する、セルラ通信ネットワークの無線アクセスネットワーク（ＲＡＮ）内の任意のノードである。無線アクセスノードのいくつかの例は、基地局（例えば、第３世代パートナーシッププロジェクト（３ＧＰＰ）第５世代（５Ｇ）ＮＲネットワークにおける新無線（ＮＲ）基地局（ｇＮＢ）、または３ＧＰＰ Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ（ＬＴＥ）ネットワークにおける拡張もしくはエボルブドノードＢ（ｅＮＢ））、高電力もしくはマクロ基地局、低電力基地局（例えば、マイクロ基地局、ピコ基地局、ホームｅＮＢなど）、中継ノード、基地局の機能の一部を実装するネットワークノードもしくはｇＮＢ分散ユニット（ｇＮＢ－ＤＵ）を実装するネットワークノード、または他の何らかのタイプの無線アクセスノードの機能の一部を実装するネットワークノードを含むが、これらに限定されない。

【0054】

コアネットワークノード：本明細書で使用される「コアネットワークノード」は、コアネットワーク内の任意のタイプのノードまたはコアネットワーク機能を実装する任意のノードである。コアネットワークノードのいくつかの例は、例えば、モビリティ管理エンティティ（ＭＭＥ）、パケットデータネットワークゲートウェイ（Ｐ－ＧＷ）、サービス能力公開機能（ＳＣＥＦ）、ホーム加入者サーバ（ＨＳＳ）、または同様のものを含む。コアネットワークノードのいくつかの他の例は、アクセスおよびモビリティ機能（ＡＭＦ：Ａｃｃｅｓｓ ａｎｄ Ｍｏｂｉｌｉｔｙ Ｆｕｎｃｔｉｏｎ）、ユーザプレーン機能（ＵＰＦ）、セッション管理機能（ＳＭＦ）、認証サーバ機能（ＡＵＳＦ：Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｓｅｒｖｅｒ Ｆｕｎｃｔｉｏｎ）、ネットワークスライス選択機能（ＮＳＳＦ：Ｎｅｔｗｏｒｋ Ｓｌｉｃｅ Ｓｅｌｅｃｔｉｏｎ Ｆｕｎｃｔｉｏｎ）、ネットワーク公開機能（ＮＥＦ：Ｎｅｔｗｏｒｋ Ｅｘｐｏｓｕｒｅ Ｆｕｎｃｔｉｏｎ）、ネットワーク機能（ＮＦ）リポジトリ機能（ＮＲＦ：ＮＦ Ｒｅｐｏｓｉｔｏｒｙ Ｆｕｎｃｔｉｏｎ）、ポリシ制御機能（ＰＣＦ）、統合データ管理（ＵＤＭ：Ｕｎｉｆｉｅｄ Ｄａｔａ Ｍａｎａｇｅｍｅｎｔ）、または同様のものを実装するノードを含む。

【0055】

通信デバイス：本明細書で使用される「通信デバイス」は、アクセスネットワークへのアクセスを有する任意のタイプのデバイスである。通信デバイスのいくつかの例は、携帯電話、スマートフォン、センサデバイス、メータ、車両、家庭用電気器具、医療器具、メディアプレーヤ、カメラ、または任意のタイプの家電製品、例えば非限定的に、テレビ、ラジオ、照明装置、タブレットコンピュータ、ラップトップコンピュータ、もしくはパーソナルコンピュータ（ＰＣ）を含むが、これらに限定されない。通信デバイスは、無線接続もしくは有線接続を介して音声および／またはデータを通信できるようにされた、携帯型、手持ち式、コンピュータ搭載型、または車載型のモバイルデバイスであり得る。

【0056】

無線通信デバイス：１つのタイプの通信デバイスは、無線ネットワーク（例えば、セルラネットワーク）へのアクセスを有する（すなわち、無線ネットワークによってサーブされる）任意のタイプの無線デバイスであり得る無線通信デバイスである。無線通信デバイスのいくつかの例は、３ＧＰＰネットワークにおけるユーザ機器デバイス（ＵＥ）、マシン型通信（ＭＴＣ）デバイス、およびモノのインターネット（ＩｏＴ）デバイスを含むが、これらに限定されない。そのような無線通信デバイスは、携帯電話、スマートフォン、センサデバイス、メータ、車両、家庭用電気器具、医療器具、メディアプレーヤ、カメラ、もしくは任意のタイプの家電製品、例えば非限定的に、テレビ、ラジオ、照明装置、タブレットコンピュータ、ラップトップコンピュータ、もしくはＰＣであり得るか、またはこれらに統合され得る。無線通信デバイスは、無線接続を介して音声および／またはデータを通信できるようにされた、携帯型、手持ち式、コンピュータ搭載型、または車載型のモバイルデバイスであり得る。

【0057】

ネットワークノード：本明細書で使用される「ネットワークノード」は、ＲＡＮ、またはセルラ通信ネットワーク／システムのコアネットワークのどちらかの一部である、任意のノードである。

【0058】

送信／受信ポイント（ＴＲＰ）：いくつかの実施形態では、ＴＲＰは、ネットワークノード、無線ヘッド、空間関係、または送信設定インジケータ（ＴＣＩ）状態のいずれかであり得る。ＴＲＰは、いくつかの実施形態において、空間関係またはＴＣＩ状態によって表され得る。いくつかの実施形態では、ＴＲＰは、複数のＴＣＩ状態を使用し得る。

【0059】

なお、本明細書で与えられる説明は３ＧＰＰセルラ通信システムに焦点を当てており、したがって３ＧＰＰ専門用語または３ＧＰＰ専門用語に類似した専門用語がしばしば使用されることに留意されたい。しかし、本明細書に開示される概念は３ＧＰＰシステムに限定されない。

【0060】

本明細書の説明では、「セル」という用語に言及され得ることに留意されたい。しかし、特に５Ｇ ＮＲ概念に関しては、セルの代わりにビームが使用されることがあり、したがって本明細書で説明される概念はセルとビームとの両方に等しく適用可能であることに留意することが重要である。

【0061】

図９は、本開示の実施形態が実装され得るセルラ通信システム９００の一例を示す。本明細書で説明される実施形態では、セルラ通信システム９００は、次世代ＲＡＮ（ＮＧ－ＲＡＮ）と５Ｇコア（５ＧＣ）とを含む５Ｇシステム（５ＧＳ）、またはＬＴＥなどの４Ｇシステム（４ＧＳ）である。この例では、ＲＡＮは、基地局９０２－１および９０２－２を含み、これら基地局は、５ＧＳでは、ＮＲ基地局（ｇＮＢ）および任意選択的に次世代ｅＮＢ（ｎｇ－ｅＮＢ）（例えば、５ＧＣに接続されたＬＴＥ ＲＡＮノード）を含み、４ＧＳでは、対応する（マクロ）セル９０４－１および９０４－２を制御するｅＮＢを含む。基地局９０２－１および９０２－２は、一般に、本明細書では総称して基地局９０２と呼ばれ、個別に基地局９０２と呼ばれる。同様に、（マクロ）セル９０４－１および９０４－２は、一般に、本明細書では総称して（マクロ）セル９０４と呼ばれ、個別に（マクロ）セル９０４と呼ばれる。ＲＡＮは、対応する小型セル９０８－１～９０８－４を制御するいくつかの低電力ノード９０６－１～９０６－４も含み得る。低電力ノード９０６－１～９０６－４は、小型基地局（ピコ基地局もしくはフェムト基地局など）、もしくはリモート無線ヘッド（ＲＲＨ）、または同様のものあり得る。とりわけ、図示されていないが、小型セル９０８－１～９０８－４のうちの１つまたは複数は、代替的に基地局９０２によって提供され得る。低電力ノード９０６－１～９０６－４は、一般に、本明細書では総称して低電力ノード９０６と呼ばれ、個別に低電力ノード９０６と呼ばれる。同様に、小型セル９０８－１～９０８－４は、一般に、本明細書では総称して小型セル９０８と呼ばれ、個別に小型セル９０８と呼ばれる。セルラ通信システム９００は、５Ｇシステム（５ＧＳ）において５ＧＣと呼ばれるコアネットワーク９１０も含む。基地局９０２（および任意選択的に低電力ノード９０６）は、コアネットワーク９１０に接続される。

【0062】

基地局９０２および低電力ノード９０６は、対応するセル９０４および９０８内の無線通信デバイス９１２－１～９１２－５にサービスを提供する。無線通信デバイス９１２－１～９１２－５は、一般に、本明細書では総称して無線通信デバイス９１２と呼ばれ、個別に無線通信デバイス９１２と呼ばれる。以下の説明では、無線通信デバイス９１２は、しばしばＵＥであるが、本開示はそれに限定されない。

【0063】

図１０および図１１は、本開示の実施形態が実装され得る、セルラ通信システム９００のいくつかのシステムアーキテクチャを示す。図１０は、３ＧＰＰ ＴＳ２３．６８２Ｖ１６．６．０の図４．２－２と同じである４Ｇネットワークにおけるサービス能力公開のための３ＧＰＰアーキテクチャを概略的に示しており、その開示全体が参照により本明細書に組み込まれる。図１０のシステムアーキテクチャは、サービス能力サーバ／アプリケーションサーバ（ＳＣＳ／ＡＳ）１０００、サービス能力公開機能（ＳＣＥＦ）１００２、ホーム加入者サーバ（ＨＳＳ）１００４、ポリシおよび課金ルール機能（ＰＣＲＦ）１００６、パケットフロー記述機能（ＰＦＤＦ：ｐａｃｋｅｔ ｆｌｏｗ ｄｅｓｃｒｉｐｔｉｏｎ ｆｕｎｃｔｉｏｎ）１００８、移動管理エンティティ／サービングＧＰＲＳ（汎用パケット無線サービス）サポートノード（ＭＭＥ／ＳＧＳＮ）１０１０、ブロードキャストマルチキャスト－サービスセンタ（ＢＭ－ＳＣ）１０１２、サービング－呼セッション制御機能（Ｓ－ＣＳＣＦ：Ｓｅｒｖｉｎｇ－Ｃａｌｌ Ｓｅｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｆｕｎｃｔｉｏｎ）１０１４、ＲＡＮ輻輳認識機能（ＲＣＡＦ：ＲＡＮ Ｃｏｎｇｅｓｔｉｏｎ Ａｗａｒｅｎｅｓｓ Ｆｕｎｃｔｉｏｎ）１０１６、およびネットワークエンティティ１０１８などのいくつかの例示的なエレメントを備え得る。図１０に示されたネットワークエレメントおよびインターフェースは、３ＧＰＰ ＴＳ２３．６８２ Ｖ１６．６．０に記載されている対応するネットワークエレメントおよびインターフェースと同じであり得る。

【0064】

図１１は、３ＧＰＰ ＴＳ２３．５０１Ｖ１６．４．０の図４．２．３－５と同じであるネットワーク公開機能参照ポイント表現（５Ｇコアネットワーク）のための非ローミングアーキテクチャを示しており、その開示全体が参照により本明細書に組み込まれる。図１１のシステムアーキテクチャは、アプリケーション機能（ＡＦ）１１００、ネットワーク公開機能（ＮＥＦ）１１０２、およびネットワーク機能（ＮＦ）１１０４などのいくつかの例示的なエレメントを備え得る。一実施形態では、ＮＦ１１０４は、ポリシ制御機能（ＰＣＦ）１１０４であり得、Ｎ３０インターフェースは、ＮＥＦ１１０２とＰＣＦ１１０４との間にある。図１１に示されたネットワークエレメント、参照ポイント、およびインターフェースは、３ＧＰＰ ＴＳ２３．５０１ Ｖ１６．４．０に記載されている対応するネットワークエレメント、参照ポイント、およびインターフェースと同じであり得る。

【0065】

図１０におけるＳＣＥＦ１００２または図１１におけるＮＥＦ１１０２などの公開機能エンティティは、ネットワーク（３ＧＰＰネットワークなど）インターフェースによって提供されるサービスおよび能力をセキュアに公開する手段を提供し得る。公開機能エンティティは、公開されたサービスおよび能力を発見するための手段を提供する。公開機能エンティティは、ネットワークアプリケーションプログラミングインターフェース（例えば、ネットワークＡＰＩ）を介してネットワーク能力へのアクセスを提供し得る。公開機能エンティティは、基盤となるネットワークインターフェースおよびプロトコルからサービスを抽象化し得る。

【0066】

様々な種類のネットワーク公開サービスが存在し得る。例えば、監視能力は、４Ｇ／５Ｇシステムなどのネットワーク内の端末デバイスの特定のイベントを監視し、そのような監視イベント情報をＳＣＥＦ１００２またはＮＥＦ１１０２などの公開機能エンティティを介して外部公開に利用できるようにするために使用され得る。プロビジョニング能力は、４Ｇ／５Ｇシステムなどのネットワーク内のＵＥなどの端末デバイスのために使用され得る情報を外部当事者がプロビジョニングできるようにするために使用され得る。ポリシ／課金能力は、外部当事者からの要求に基づいて、ＵＥなどの端末デバイスに対するＱｏＳ（サービス品質）および課金ポリシをハンドリングするために使用され得る。分析報告能力は、４Ｇ／５Ｇシステムなどのネットワークによって生成された分析情報を外部当事者がフェッチまたはサブスクライブ／サブスクライブ解除できるようにするために使用され得る。データ能力は、外部当事者がアプリケーションプログラミングインターフェースを介してＵＥなどの端末デバイスと通信できるようにするために使用され得る。

【0067】

一実施形態では、公開機能エンティティは、３ＧＰＰ ＴＳ２３．５０１ Ｖ１６．４．０に記載されているように、ネットワーク公開機能およびネットワーク公開サービスをサポートし得る。別の実施形態では、公開機能エンティティは、３ＧＰＰ ＴＳ２３．６８２ Ｖ１６．６．０に記載されているように、ネットワーク公開機能をサポートし得る。

【0068】

図１２Ａは、本開示のいくつかの実施形態による、図１０または図１１に示されるアーキテクチャ内の動作を示す。図示されるように、アプリケーション関連機能（ＡＲＦ）１２００は、要求を送信し、公開機能（ＥＦ）１２０２は、要求を受信する（ステップ１２１０）。本明細書では、ＡＲＦ１２００は、図１０の４Ｇシステムに示されているＳＣＳ／ＡＳ１０００、または図１１の５Ｇシステムに示されているＡＦ１１００であり得る。ＥＦ１２０２は、図１０の４Ｇシステムに示されているＳＣＥＦ１００２、または図１１の５Ｇシステムに示されているＮＥＦ１１０２であり得る。

【0069】

ＡＲＦ１２００からＥＦ１２０２への要求は、異なるネットワークシステムおよび／または異なる手順に対する異なる要求であり得る。例えば、図１０に示す４Ｇシステムでは、要求は、必要とされるＱｏＳを有するＡＳセッションをセットアップするための要求（３ＧＰＰ ＴＳ２３．６８２ Ｖ１６．６．０に記載のオンデマンドＱｏＳ要求メッセージを利用する）、必要とされるＱｏＳを有するＡＳセッションを更新するための要求、ＡＳセッションのセットアップ時に課金先を設定するための要求（３ＧＰＰ ＴＳ２３．６８２ Ｖ１６．６．０に記載の課金先設定要求メッセージ）、またはＡＳセッション中に課金先を変更するための要求（３ＧＰＰ ＴＳ２３．６８２ Ｖ１６．６．０に記載の課金先変更要求メッセージ）であり得る。別の事例として、図１１に示す５Ｇシステムでは、要求は、必要とされるＱｏＳを有するＡＦセッションをセットアップするための要求（３ＧＰＰ ＴＳ２３．５０２ Ｖ１６．５．０に記載のＮｎｅｆ＿ＡＦｓｅｓｓｉｏｎＷｉｔｈＱｏＳ＿Ｃｒｅａｔｅ要求メッセージを利用する）、必要とされるＱｏＳを有するＡＦセッションを更新するための要求（３ＧＰＰ ＴＳ２３．５０２ Ｖ１６．５．０に記載のＮｎｅｆ＿ＡＦｓｅｓｓｉｏｎＷｉｔｈＱｏＳ＿Ｕｐｄａｔｅ要求メッセージ）、ＡＦセッションのセットアップ時に課金先を設定するための要求（３ＧＰＰ ＴＳ２３．５０２ Ｖ１６．５．０に記載のＮｎｅｆ＿ＣｈａｒｇｅａｂｌｅＰａｒｔｙ＿Ｃｒｅａｔｅ要求メッセージ）、またはＡＦセッション中に課金先を変更するための要求（３ＧＰＰ ＴＳ２３．５０２ Ｖ１６．５．０に記載のＮｎｅｆ＿ＣｈａｒｇｅａｂｌｅＰａｒｔｙ＿Ｕｐｄａｔｅ要求メッセージ）であり得る。

【0070】

ＡＲＦ１２００からＥＦ１２０２への要求は、リソース割り当てステータス特性およびリソース割り当て確認表示を含む。本明細書では、リソース割り当てステータス特性は、ＡＲＦ１２００がリソース割り当てステータスをサポートしているかどうかを示し、リソース割り当て確認表示は、リソース割り当てステータス特性に従って、ＡＲＦ１２００によってリソース割り当てステータス通知が必要とされているかどうかを示す。ＡＲＦ１２００がリソース割り当てステータス通知を要求する場合、ＡＲＦ１２００は、ＥＦ１２０２からのリソース割り当てステータス通知を待機することになる。ＡＲＦ１２００がリソース割り当てステータス通知を要求しない場合、ＡＲＦ１２００は、ＥＦ１２０２からのリソース割り当てステータス通知を待機しない。

【0071】

一実施形態では、リソース割り当てステータス特性がＡＲＦ１２００がリソース割り当てステータスをサポートしているかどうかを示すために、ビットマスクが使用され得る。リソース割り当てステータス特性は、値セット「０および１」または「真および偽」を利用し得る。リソース割り当てステータス特性の値が「１」または「真」であるとき、リソース割り当てステータス特性は、ＡＲＦ１２００がリソース割り当てステータスをサポートしていること（ＡＲＦ１２００が、リソース割り当て失敗またはリソース割り当て成功を示すリソース割り当てステータス通知を（ＥＦ１２０２から）受信することが可能であること）を示す。リソース割り当てステータス特性の値が「０」または「偽」であるとき、リソース割り当てステータス特性は、ＡＲＦ１２００がリソース割り当てステータスをサポートしていないことを示す。

【0072】

同様に、リソース割り当て確認表示がＡＲＦ１２００によってリソース割り当てステータス通知が必要とされているかどうかを示すために、ビットマスクが使用され得る。リソース割り当て確認表示は、値セット「０および１」または「真および偽」を利用し得る。リソース割り当て確認表示の値が「１」または「真」であるとき、リソース割り当て確認表示は、ＡＲＦ１２００によってリソース割り当てステータス通知が必要とされていることを示す。リソース割り当て確認表示の値が「０」または「偽」であるとき、リソース割り当て確認表示は、ＡＲＦ１２００によってリソース割り当てステータス通知が要求されていないことを示す。

【0073】

要求を受信した後、ＥＦ１２０２は、リソース割り当てステータスがＥＦ１２０２によってサポートされているかどうか（ＥＦ１２０２が、リソース割り当て失敗またはリソース割り当て成功を示すリソース割り当てステータス通知を（ＡＲＦ１２００に）送信することが可能かどうか）を判定する（ステップ１２１２）。リソース割り当てステータスがＡＲＦ１２００とＥＦ１２０２との両方によってサポートされている場合にのみ、ＡＲＦ１２００は、リソース割り当てステータス通知を受信し得る。

【0074】

ＥＦ１２０２において、ＥＦ１２０２はまた、ＡＲＦ１２００からの要求を認可する（ステップ１２１４）。認可は、どの要求が実装されるかに基づいて実行される。認可が与えられると、ＥＦ１２０２は、ポリシ機能（ＰＦ）１２０４と対話する（ステップ１２１６）。本明細書において、ＰＦ１２０４は、図１０の４Ｇシステムに示されているＰＣＲＦ１００６、または図１１の５Ｇシステムに示されているＰＣＦ１１０４であり得る。ＥＦ１２０２は、（ＡＲＦ１２００からの）要求に含まれる少なくともいくつかの情報をＰＦ１２０４に提供し、ＰＦ１２０４は、要求が許可されるかどうかを判定し、要求が認可されない場合はＥＦ１２０２に通知する。さらに、ＰＦ１２０４との対話中、ＥＦ１２０２はまた、ＰＦ１２０４によってリソース割り当てステータスについて通知を受けることを要求し得る。

【0075】

一実施形態では、リソース割り当てステータスがＡＲＦ１２００とＥＦ１２０２との両方によってサポートされているとき、ＥＦ１２０２は、リソース割り当てステータス通知がＡＲＦ１２００によって必要とされている（リソース割り当て確認表示の値は「１」または「真」である）場合にのみ、リソース割り当てステータス通知を取得するためにＰＦ１２０４をサブスクライブする。本明細書では、リソース割り当てステータス通知は、ＩＮＤＩＣＡＴＩＯＮ＿ＯＦ＿ＳＵＣＣＥＳＳＦＵＬ＿ＲＥＳＯＵＲＣＥＳ＿ＡＬＬＯＣＡＴＩＯＮイベントおよびＩＮＤＩＣＡＴＩＯＮ＿ＯＦ＿ＦＡＩＬＥＤ＿ＲＥＳＯＵＲＣＥＳ＿ＡＬＬＯＣＡＴＩＯＮイベントなどのリソース割り当て失敗またはリソース割り当て成功を示す。

【0076】

一実施形態では、リソース割り当てステータスがＡＲＦ９００およびＥＦ１２０２のうちの少なくとも一方によってサポートされていないとき、ＥＦ１２０２は、リソース割り当てステータス通知を取得するために依然としてＰＦ１２０４をサブスクライブし得るが、リソース割り当てステータス通知をＡＲＦ１２００に渡さない。本明細書では、ＥＦ１２０２は、サブスクライブされたイベントに基づいて特定のローカル統計を実行し得る。

【0077】

次いで、ＥＦ１２０２は応答を送信し、ＡＦ１２０は応答を受信する（ステップ１２１８）。本明細書では、ＥＦ１２０２からＡＲＦ１２００への応答は、実装された要求に応じて異なる応答であり得る。例えば、図１０に示す４Ｇシステムでは、応答は、必要とされるＱｏＳを有するＡＳセッションをセットアップするための応答（３ＧＰＰ ＴＳ２３．６８２ Ｖ１６．６．０に記載のオンデマンドＱｏＳ応答メッセージを利用する）、必要とされるＱｏＳを有するＡＳセッションを更新するための応答、ＡＳセッションのセットアップ時に課金先を設定するための応答（３ＧＰＰ ＴＳ２３．６８２ Ｖ１６．６．０に記載の課金先設定応答メッセージ）、またはＡＳセッション中に課金先を変更するための応答（３ＧＰＰ ＴＳ２３．６８２ Ｖ１６．６．０に記載の課金先変更応答メッセージ）であり得る。別の事例として、図１１に示す５Ｇシステムでは、応答は、必要とされるＱｏＳを有するＡＦセッションをセットアップするための応答（３ＧＰＰ ＴＳ２３．５０２ Ｖ１６．５．０に記載のＮｎｅｆ＿ＡＦｓｅｓｓｉｏｎＷｉｔｈＱｏＳ＿Ｃｒｅａｔｅ応答メッセージを利用する）、必要とされるＱｏＳを有するＡＦセッションを更新するための応答（３ＧＰＰ ＴＳ２３．５０２ Ｖ１６．５．０に記載のＮｎｅｆ＿ＡＦｓｅｓｓｉｏｎＷｉｔｈＱｏＳ＿Ｕｐｄａｔｅ応答メッセージ）、ＡＦセッションのセットアップ時に課金先を設定するための応答（３ＧＰＰ ＴＳ２３．５０２ Ｖ１６．５．０に記載のＮｎｅｆ＿ＣｈａｒｇｅａｂｌｅＰａｒｔｙ＿Ｃｒｅａｔｅ応答メッセージ）、またはＡＦセッション中に課金先を変更するための応答（３ＧＰＰ ＴＳ２３．５０２ Ｖ１６．５．０に記載のＮｎｅｆ＿ＣｈａｒｇｅａｂｌｅＰａｒｔｙ＿Ｕｐｄａｔｅ応答メッセージ）であり得る。

【0078】

応答は、ＡＲＦ１２００とＥＦ１２０２との両方がリソース割り当てステータスをサポートしているかどうかを示すステータス応答特性を含む。一実施形態では、ステータス応答特性が、ＡＲＦ１２００とＥＦ１２０２との両方がリソース割り当てステータスをサポートしているかどうかを示すために、ビットマスクが使用される。ステータス応答特性は、値セット「０および１」または「真および偽」を利用し得る。ステータス応答特性の値が「１」または「真」であるとき、ステータス応答特性は、ＡＲＦ１２００とＥＦ１２０２との両方がリソース割り当てステータスをサポートしていることを示す。ステータス応答特性の値が「０」または「偽」であるとき、ステータス応答特性は、ＡＲＦ１２００およびＥＦ１２０２のうちの少なくとも一方がリソース割り当てステータスをサポートしていないことを示す。

【0079】

ＡＲＦ１２００は、「１」または「真」の値を有するステータス応答特性を受信することによって、ＡＲＦ１２００とＥＦ１２０２との両方がリソース割り当てステータスをサポートしていることを通知される。結果として、リソース割り当て確認表示の値が「１」または「真」である（リソース割り当てステータス通知がＡＲＦ１２００によって必要とされている）場合、ＥＦ１２０２からＡＲＦ１２００への応答は、ＩＮＤＩＣＡＴＩＯＮ＿ＯＦ＿ＳＵＣＣＥＳＳＦＵＬ＿ＲＥＳＯＵＲＣＥＳ＿ＡＬＬＯＣＡＴＩＯＮイベントおよびＩＮＤＩＣＡＴＩＯＮ＿ＯＦ＿ＦＡＩＬＥＤ＿ＲＥＳＯＵＲＣＥＳ＿ＡＬＬＯＣＡＴＩＯＮイベントなど、リソース割り当て失敗またはリソース割り当て成功を示すリソース割り当てステータス通知をさらに含む。しかし、リソース割り当て確認表示の値が「０」または「偽」である（リソース割り当てステータス通知がＡＲＦ１２００によって要求されていない）場合、ＥＦ１２０２は、ＡＲＦ１２００へリソース割り当てステータス通知を送信することは可能であるが、リソース割り当てステータス通知を送信しない。ＡＲＦ１２００は、リソース割り当てステータス通知を待機することを抑制する（ステップ１２２０）。

【0080】

ＡＲＦ１２００は、「０」または「偽」の値を有するステータス応答特性を受信することによって、ＡＲＦ１２００およびＥＦ１２０２のうちの少なくとも一方がリソース割り当てステータスをサポートしていないことを通知される。次いで、ＡＲＦ１２００は、リソース割り当てステータス通知を待機することを抑制する（ステップ１２２０）。

【0081】

図１２Ｂは、いくつかの実施形態による、ＡＲＦ１２００のようなアプリケーション関連機能の動作を示すフローチャートである。ステップ１２１０において、ＡＲＦ１２００は、リソース割り当てステータス特性とリソース割り当て確認表示とを含む要求を、ＥＦ１２０２のような公開機能へ送信する。リソース割り当てステータス特性は、ＡＲＦ１２００がリソース割り当てステータスをサポートしているかどうかを示し、リソース割り当て確認表示は、リソース割り当てステータス特性に従って、ＡＲＦ１２００によってリソース割り当てステータス通知が必要とされているかどうかを示す。次いで、ステップ１２１８において、ＡＲＦ１２００は、ＡＲＦ１２００とＥＦ１２０２との両方がリソース割り当てステータスをサポートしているかどうかを示すステータス応答特性と、任意選択的に、リソース割り当て失敗またはリソース割り当て成功を示すためのリソース割り当てステータス通知とを含む応答を、ＥＦ１２０２から受信する。一実施形態では、リソース割り当て確認表示が、リソース割り当てステータス通知がＡＲＦ１２００によって必要とされていることを示し、かつ、ステータス応答特性が、ＡＲＦ１２００とＥＦ１２０２との両方がリソース割り当てステータスをサポートしていることを示す場合、応答は、リソース割り当て失敗またはリソース割り当て成功を示すためのリソース割り当てステータス通知も含む。別の実施形態では、ステータス応答特性が、ＡＲＦ１２００およびＥＦ１２０２のうちの少なくとも一方がリソース割り当てステータスをサポートしていないことを示すとき、応答は、リソース割り当てステータス通知を含まず、ステップ１２２０において、ＡＲＦ１２００は、ＥＦからのリソース割り当てステータス通知を待機することを抑制する。

【0082】

図１２Ｃは、いくつかの実施形態による、ＥＦ１２０２のような公開機能の動作を示すフローチャートである。ステップ１２１０において、ＥＦ１２０２は、ＡＲＦ１２００のようなアプリケーション関連機能から、リソース割り当てステータス特性とリソース割り当て確認表示とを含む要求を受信する。本明細書では、リソース割り当てステータス特性は、ＡＲＦ１２００がリソース割り当てステータスをサポートしているかどうかを示し、リソース割り当て確認表示は、リソース割り当てステータス特性に従って、ＡＲＦ１２００によってリソース割り当てステータス通知が必要とされているかどうかを示す。次いで、ステップ１２１２において、ＥＦ１２０２は、リソース割り当てステータスがＥＦ１２０２によってサポートされているかどうかを判定する。ステップ１２１４において、ＥＦ１２０２は、ＡＲＦ１２００からの要求を認可する。本明細書では、ステップ１２１２は、ステップ１２１４の前、ステップ１２１４の後、またはステップ１２１４と同時に実行され得る。要求が認可されると、ステップ１２１６において、ＥＦ１２０２は、ＰＦ１２０４のようなポリシ機能と対話する。ＰＦ１２０４との対話中、ＥＦ１２０２は、ＰＦ１２０４によってリソース割り当てステータスについて通知を受けることを要求し得る。最後に、ステップ１２１８において、ＥＦ１２０２は、ＡＲＦ１２００とＥＦ１２０２との両方がリソース割り当てステータスをサポートしているかどうかを示すステータス応答特性と、任意選択的に、リソース割り当て失敗またはリソース割り当て成功を示すためのリソース割り当てステータス通知とを含む応答を、ＡＲＦ１２００へ送信する。一実施形態では、リソース割り当て確認表示が、リソース割り当てステータス通知がＡＲＦ１２００によって必要とされていることを示し、かつ、ステータス応答特性が、ＡＲＦ１２００とＥＦ１２０２との両方がリソース割り当てステータスをサポートしていることを示す場合、応答は、リソース割り当て失敗またはリソース割り当て成功を示すためのリソース割り当てステータス通知も含む。別の実施形態では、ステータス応答特性が、ＡＲＦ１２００およびＥＦ１２０２のうちの少なくとも一方がリソース割り当てステータスをサポートしていないことを示すとき、応答は、リソース割り当てステータス通知を含まない。

【0083】

本明細書で説明される実施形態の少なくともいくつかの態様の例示的な一実装形態について、３ＧＰＰ ＴＳ２９．１２２ Ｖ１６．８．０への変更点として以下に説明する。特に、４．４．４項、４．４．１３項、５．５．２．１．２項（表５．５．２．１．２－１を含む）、５．５．４項（表５．５．４－１を含む）、５．１４．２．１．２（表５．１４．２．１．２－１を含む）、５．１５．２．２．３項（表５．１４．２．２．３－１を含む）、５．１４．４項（表５．１４．４－１を含む）、Ａ．２項、Ａ．５項、およびＡ．１４項が変更されている。５．２．１．２．５項（表５．２．１．２．５－１を含む）、５．２．１．２．６項（表５．２．１．２．６－１を含む）、および５．２．１．３．３項（表５．２．１．３．３－１を含む）が無効となっている。５．５．２．１．ｘ項（表５．５．２．１．ｘ－１を含む）、５．５．２．１．ｙ項（表５．５．２．１．ｙ－１を含む）、５．５．２．ｘ項、５．５．２．ｘ．１項、５．５．２．ｘ．２項（表５．５．２．ｘ．２－１を含む）、および５．５．２．ｘ．３項（表５．５．２．ｘ．３－１を含む）が新たに追加されている。

【0084】

４．４．４ セッションセットアップ時またはセッション中に課金先を変更するための手順
この手順は、最初からトラフィックをスポンサ提供するよう要求するか、または後の時間的ポイントでＴ８インターフェースを介して課金先となるよう要求するために、ＳＣＳ／ＡＳによって使用される。

【0085】

ＳＣＥＦを介してＡＳとＵＥとの間の接続をセットアップするとき、ＳＣＳ／ＡＳは、セットアップされるべきセッションの課金先となるために、「課金先トランザクション」リソースをターゲットとして、ＨＴＴＰ ＰＯＳＴ要求をＳＣＥＦへ送信するものとする。ＨＴＴＰ ＰＯＳＴメッセージの本文は、ＳＣＳ／ＡＳ識別子、ＵＥ ＩＰアドレス、ＩＰフローの説明、スポンサＩＤ、ＡＳＰ ＩＤ、スポンサ提供ステータス、「ｎｏｔｉｆｉｃａｔｉｏｎＤｅｓｔｉｎａｔｉｏｎ」属性内の通知の受信者を識別する通知先ＵＲＩを含むものとし、またスポンサ提供のために使用される期間および／またはトラフィック量を含み得る。ＳＣＳ／ＡＳはまた、ＨＴＴＰ ＰＯＳＴメッセージの本文中に関連する参照ＩＤを含めることによって、バックグラウンドデータ転送の以前に選択されたポリシをアクティブ化するよう要求し得る。

【0086】

ＨＴＴＰ ＰＯＳＴ要求を受信した後、ＳＣＥＦによって実施された認可が成功した場合、ＳＣＥＦは、ＡＦとして作用し、３ＧＰＰ ＴＳ２９．２１４［１０］または３ＧＰＰ ＴＳ２９．２０１［１３］において規定されているように、Ｒｘインターフェースを介してＰＣＲＦと対話して、ＰＣＲＦが始動したＩＰ－ＣＡＮセッションの修正をトリガする。ＳＣＥＦは、ＳＣＳ／ＡＳ識別子をＡＦアプリケーション識別子にマッピングし得、トラフィックプレーンステータスについて通知を受けることを要求し得る。期間および／またはトラフィック量がＡＦから受信された場合、ＳＣＥＦは、ＰＣＲＦを用いて、ＵＳＡＧＥ＿ＲＥＰＯＲＴイベントをサブスクライブするべきである。「ＲｅｓＡｌｌｏｃＳｔａｔｕｓ」特性がサポートされており、かつ、「ｒｅｓｃｏｎｆｉｒｍＩｎｄ」が真にセットされる場合、ＳＣＥＦは、ＩＮＤＩＣＡＴＩＯＮ＿ＯＦ＿ＳＵＣＣＥＳＳＦＵＬ＿ＲＥＳＯＵＲＣＥＳ＿ＡＬＬＯＣＡＴＩＯＮイベント、およびＩＮＤＩＣＡＴＩＯＮ＿ＯＦ＿ＦＡＩＬＥＤ＿ＲＥＳＯＵＲＣＥＳ＿ＡＬＬＯＣＡＴＩＯＮイベントでＰＣＲＦをサブスクライブするものとする。

【0087】

ＰＣＲＦから成功の応答を受信した後、ＳＣＥＦは、ＳＣＳ／ＡＳ識別情報とＳＣＥＦが作成したトランザクション識別子とを含むＵＲＩによってアドレス指定される、課金先のトランザクションを表す新しい「個別課金先トランザクション」リソースを作成するものとし、作成されたリソースのＵＲＩを含むＬｏｃａｔｉｏｎヘッダフィールドを含む２０１ Ｃｒｅａｔｅｄステータスコードによって、ＳＣＳ／ＡＳに応答するものとする。ＳＣＳ／ＡＳは、この課金先トランザクションを参照するために、ＳＣＥＦへの後続の要求内のＬｏｃａｔｉｏｎヘッダにおいて受信されたＵＲＩを使用するものとする。ＳＣＥＦがＰＣＲＦからエラーコードを有する応答を受信した場合、ＳＣＥＦは、リソースを作成せず、５．２．６項で説明されているように、対応する失敗コードによってＳＣＳ／ＡＳに応答するものとする。

【0088】

確立されたＡＳセッションのスポンサ提供ステータスを更新するために、ＳＣＳ／ＡＳは、スポンサ提供ステータスを変更するよう要求する、関連する「個別課金先トランザクション」リソースをターゲットとするＨＴＴＰ ＰＡＴＣＨメッセージをＳＣＥＦへ送信するものとする。ＨＴＴＰ ＰＡＴＣＨメッセージを受信したとき、ＳＣＥＦは、３ＧＰＰ ＴＳ２９．２１４［１０］または３ＧＰＰ ＴＳ２９．２０１［１３］において規定されているように、変更を加え、ＰＣＲＦと対話してＲｘセッションを修正するものとする。ＰＣＲＦから成功の結果コードを有する応答を受信した後、ＳＣＥＦは、ＨＴＴＰ応答の本文内に２００ ＯＫステータスコードと結果とを有するＨＴＴＰ応答をＳＣＳ／ＡＳに送信するものとする。ＳＣＳ／ＡＳがスポンサ提供を無効化するよう要求した場合、ＰＣＲＦから受信された累積使用量が含まれるものとする。ＳＣＥＦがＰＣＲＦからエラーコードを有する応答を受信した場合、ＳＣＥＦは、リソースを更新せず、５．２．６項で説明されているように、対応する失敗コードによってＳＣＳ／ＡＳに応答するものとする。

【0089】

ＳＣＥＦがトラフィックプレーン通知を受信した場合（例えば、使用量閾値に達した、もしくは送信リソースが失われた場合）、または（例えば、ＰＤＮ接続の解放に起因して）Ｒｘセッションが終了したとの通知を受けた場合、ＳＣＥＦは、通知されたイベント（例えば、セッション終了）と累積使用量とを含むＨＴＴＰ ＰＯＳＴメッセージを、セッションのセットアップ中に受信された通知先ＵＲＩによって識別されるＳＣＳ／ＡＳへ送信するものとする。ＳＣＳ／ＡＳは、受信された通知を確認するためにＨＴＴＰ応答によって応答するものとする。

【0090】

確立されたＡＳセッションを削除するために、ＳＣＳ／ＡＳは、関連する「個別課金先トランザクション」リソースをターゲットとするＨＴＴＰ ＤＥＬＥＴＥメッセージをＳＣＥＦへ送信するものとする。ＨＴＴＰ ＤＥＬＥＴＥメッセージを受信した後、ＳＣＥＦは、（３ＧＰＰ ＴＳ２９．２１４［１０］または３ＧＰＰ ＴＳ２９．２０１［１３］において規定されているように）リソースのすべてのプロパティを削除し、ＰＣＲＦと対話してＲｘセッションを終了するものとする。ＰＣＲＦから応答を受信した後、ＳＣＥＦは、対応するステータスコードと累積使用量（ＰＣＲＦから受信された場合）とを有するＨＴＴＰ応答をＳＣＳ／ＡＳへ送信するものとする。

【0091】

４．４．１３ 必要とされるＱｏＳを有するＡＳセッションをセットアップするための手順
この手順は、３ＧＰＰ ＴＳ２３．６８２［２］において規定されているように、サービスに必要とされるＱｏＳを有するＡＳセッションをセットアップするために使用される。

【0092】

最初のＡＳセッションの作成では、ＳＣＳ／ＡＳは、「必要とされるＱｏＳサブスクリプションを有するＡＳセッション」リソースに関するＨＴＴＰ ＰＯＳＴメッセージをＳＣＥＦへ送信するものとする。ＨＴＴＰ ＰＯＳＴメッセージの本文は、ＳＣＳ／ＡＳ識別子、ＵＥ ＩＰアドレス、ＩＰフローの説明、ＱｏＳ参照、および通知先アドレスを含むものとする。また、ＨＴＴＰ ＰＯＳＴメッセージの本文は、スポンサ提供されるデータのコネクティビティを目的とした期間および／またはトラフィック量も含み得る。

【0093】

ＨＴＴＰ ＰＯＳＴメッセージを受信した後、ＳＣＥＦは、要求を認可し、要求されたＱｏＳ参照の総数がＳＣＳ／ＡＳの制限を超えているかどうかを確認し得る。認可が成功した場合、ＳＣＥＦは、ＳＣＳ／ＡＳ識別子をＡＦアプリケーション識別子にマッピングし、必要に応じてＳＣＳ／ＡＳ識別子をＡＳＰ識別情報およびスポンサ識別情報にマッピングするものとする。
注記１：ＱｏＳ参照がＲｘパラメータにマッピングされる前に、ＳＣＥＦは、サードパーティＳＣＳ／ＡＳの名前空間からオペレータの名前空間へのマッピングを実行することができる。
注記２：ＳＣＥＦ内のあらかじめ規定されたＱｏＳ情報を参照するＱｏＳ参照は、ＳＬＡに従ってメディア構成要素の説明（例えば、帯域幅、メディアタイプ）にマッピングされ得る。

【0094】

ＳＣＥＦによって実行された認可が成功した場合、ＳＣＥＦは、ＡＦとして作用し、３ＧＰＰ ＴＳ２９．２１４［１０］または３ＧＰＰ ＴＳ２９．２０１［１３］において規定されているように、Ｒｘインターフェースを介してＰＣＲＦと対話し、ＰＣＲＦが始動したＩＰ－ＣＡＮセッションの修正をトリガするものとする。ＳＣＥＦは、送信リソースステータス、すなわち、ＩＮＤＩＣＡＴＩＯＮ＿ＯＦ＿ＲＥＬＥＡＳＥ＿ＯＦ＿ＢＥＡＲＥＲ、ならびに任意選択的に、ＩＮＤＩＣＡＴＩＯＮ＿ＯＦ＿ＬＯＳＳ＿ＯＦ＿ＢＥＡＲＥＲおよびＩＮＤＩＣＡＴＩＯＮ＿ＯＦ＿ＲＥＣＯＶＥＲＹ＿ＯＦ＿ＢＥＡＲＥＲについて通知を受けることも要求するものとする。ＡＦから期間および／またはトラフィック量が受信された場合、ＳＣＥＦは、ＵＳＡＧＥ＿ＲＥＰＯＲＴイベントでＰＣＲＦをサブスクライブするべきである。「ＲｅｓＡｌｌｏｃＳｔａｔｕｓ」特性がサポートされていない場合、ＳＣＥＦは、ＩＮＤＩＣＡＴＩＯＮ＿ＯＦ＿ＳＵＣＣＥＳＳＦＵＬ＿ＲＥＳＯＵＲＣＥＳ＿ＡＬＬＯＣＡＴＩＯＮイベントおよびＩＮＤＩＣＡＴＩＯＮ＿ＯＦ＿ＦＡＩＬＥＤ＿ＲＥＳＯＵＲＣＥＳ＿ＡＬＬＯＣＡＴＩＯＮイベントでＰＣＲＦをサブスクライブするものとし、それ以外の場合、「ｒｅｓｃｏｎｆｉｒｍＩｎｄ」が真にセットされている場合にのみ、ＳＣＥＦは、ＩＮＤＩＣＡＴＩＯＮ＿ＯＦ＿ＳＵＣＣＥＳＳＦＵＬ＿ＲＥＳＯＵＲＣＥＳ＿ＡＬＬＯＣＡＴＩＯＮイベントおよびＩＮＤＩＣＡＴＩＯＮ＿ＯＦ＿ＦＡＩＬＥＤ＿ＲＥＳＯＵＲＣＥＳ＿ＡＬＬＯＣＡＴＩＯＮイベントでＰＣＲＦをサブスクライブするものとする。

【0095】

ＳＣＥＦは、ＰＣＲＦからＲｘインターフェース上で成功の結果コードを有するＡＡＡメッセージを受信した後、ＳＣＳ／ＡＳ識別情報とＳＣＥＦが作成したＡＳセッション識別子とを含むＵＲＩによってアドレス指定される、ＡＳセッションを表すリソース「必要とされるＱｏＳを有する個別ＡＳセッション」を作成するものとし、ＨＴＴＰ応答の本文内の結果と作成されたリソースのＵＲＩを含むＬｏｃａｔｉｏｎヘッダフィールドとを含む２０１ Ｃｒｅａｔｅｄメッセージによって、ＳＣＳ／ＡＳに応答するものとする。ＳＣＳ／ＡＳは、このＡＳセッションを参照するために、ＳＣＥＦへの後続の要求内のＬｏｃａｔｉｏｎヘッダにおいて受信されたＵＲＩを使用するものとする。それ以外の場合、ＳＣＥＦは、対応するステータスコードを有するＨＴＴＰ応答をＳＣＳ／ＡＳへ送信し、ＨＴＴＰ応答内の本文内に結果を含めるものとする。ＳＣＥＦがＰＣＲＦからエラーコードを有する応答を受信した場合、ＳＣＥＦは、リソースを作成せず、５．２．６項で説明されているように、対応する失敗コードによってＳＣＳ／ＡＳに応答するものとする。

【0096】

確立されたＡＳセッションを更新するために、ＳＣＳ／ＡＳは、リソースを作成した要求への応答において受信されたＵＲＩによってアドレス指定される、既存のリソース内のすべてのプロパティを置き換えることを要求する「必要とされるＱｏＳサブスクリプションを有する個別ＡＳセッション」リソースについてのＨＴＴＰ ＰＵＴメッセージを、ＳＣＥＦへ送信し得る。ＵＥ ＩＰアドレスは、以前に提供された値から依然として変更されないものとする。そのようなメッセージを受信した後、ＳＣＥＦは、（３ＧＰＰ ＴＳ２９．２１４［１０］または３ＧＰＰ ＴＳ２９．２０１［１３］において規定されているように）変更を加え、ＰＣＲＦと対話してＲｘセッションを修正するものとする。ＰＣＲＦから成功の結果コードを有する応答を受信した後、ＳＣＥＦは、既存のリソースのすべてのプロパティを置き換え、対応するステータスコードを有するＨＴＴＰ応答をＳＣＳ／ＡＳへ送信し、ＨＴＴＰ応答の本文内に結果を含めるものとする。ＳＣＥＦがＰＣＲＦからエラーコードを有する応答を受信した場合、ＳＣＥＦは、リソースを更新せず、５．２．６項で説明されているように、対応する失敗コードによってＳＣＳ／ＡＳに応答するものとする。

【0097】

ＳＣＳ／ＡＳはまた、いくつかの作成されたプロパティ（例えば、フローの説明）を変更するようを要求する「必要とされるＱｏＳサブスクリプションを有する個別ＡＳセッション」リソースについてのＨＴＴＰ ＰＡＴＣＨメッセージを、ＳＣＥＦへ送信し得る。ＨＴＴＰ ＰＡＴＣＨメッセージを受信した後、ＳＣＥＦは、（３ＧＰＰ ＴＳ２９．２１４［１０］または３ＧＰＰ ＴＳ２９．２０１［１３］において規定されているように）変更を加え、ＰＣＲＦと対話してＲｘセッションを修正するものとする。ＰＣＲＦから応答を受信した後、ＳＣＥＦは、対応するステータスコードを有するＨＴＴＰ応答をＳＣＳ／ＡＳへ送信し、ＨＴＴＰ応答の本文内に結果を含めるものとする。

【0098】

ＳＣＥＦがトラフィックプレーン通知を受信した場合（例えば、使用量閾値に達した、もしくは送信リソースが失われた場合）、またはＳＣＥＦが（例えば、ＰＤＮ接続の解放に起因して）Ｒｘセッションが終了したとの通知を受けた場合、ＳＣＥＦは、通知されたイベント（例えば、セッション終了）と累積使用量（ＰＣＲＦから受信された場合）とを含むＨＴＴＰ ＰＯＳＴメッセージを、必要とされるＱｏＳサブスクリプションを有する個別ＡＳセッションの作成中にＳＣＳ／ＡＳによって提供されるコールバックＵＲＩ「ｎｏｔｉｆｉｃａｔｉｏｎＵｒｉ」へ送信するものとする。ＳＣＳ／ＡＳは、受信された通知を確認するためにＨＴＴＰ応答によって応答するものとする。

【0099】

確立されたＡＳセッションを削除するために、ＳＣＳ／ＡＳは、「必要とされるＱｏＳサブスクリプションを有する個別ＡＳセッション」についてのＨＴＴＰ ＤＥＬＥＴＥメッセージをＳＣＥＦへ送信するものとする。ＨＴＴＰ ＤＥＬＥＴＥメッセージを受信した後、ＳＣＥＦは、（３ＧＰＰ ＴＳ２９．２１４［１０］または３ＧＰＰ ＴＳ２９．２０１［１３］において規定されているように）すべてのプロパティを削除し、ＰＣＲＦと対話してＲｘセッションを終了するものとする。ＰＣＲＦから応答を受信した後、ＳＣＥＦは、対応するステータスコードを有するＨＴＴＰ応答をＳＣＳ／ＡＳへ送信し、（ＰＣＲＦから受信された場合）累積使用量を含むものとする。

【0100】

５．５．２．１．２ 型：ＣｈａｒｇｅａｂｌｅＰａｒｔｙ
この型は、課金先の設定を表す。設定要求および設定応答において同じ構造が使用される。

【0101】

５．５．２．１．ｘ 型：ＮｏｔｉｆｉｃａｔｉｏｎＤａｔａ
この型は、ベアラレベルイベントについてＳＣＳ／ＡＳに通知されるパラメータを表す。

【0102】

５．５．２．１．ｙ 型：ＥｖｅｎｔＲｅｐｏｒｔ
この型は、イベント報告を表す。

【0103】

５．５．２．ｘ 参照される単純なデータ型および列挙体
５．５．２．ｘ．１ 序論
本節は、前の節において規定されているデータ構造から参照される単純なデータ型および列挙体を規定する。加えて、５．２．１項において規定されているデータ型および列挙体が参照され得る。

【0104】

５．５．２．ｘ．２ 単純なデータ型
表５．５．２．ｘ．２－１において規定されている単純なデータ型がサポートされるものとする。

【0105】

５．５．２．ｘ．３ 列挙体：Ｅｖｅｎｔ
列挙体Ｅｖｅｎｔは、ＳＣＥＦによって報告されたイベントを表す。

【0106】

５．５．４ 使用される特性
以下の表は、ＣｈａｒｇｅａｂｌｅＰａｒｔｙ ＡＰＩに適用可能な特性を規定する。これらの特性は、５．２．７項に説明されているようにネゴシエートされる。

【0107】

５．１４．２．１．２ 型：ＡｓＳｅｓｓｉｏｎＷｉｔｈＱｏＳＳｕｂｓｃｒｉｐｔｉｏｎ
この型は、ＳＣＳ／ＡＳによってＴ８インターフェースを介してＳＣＥＦに提供されるサービスに対する特定のＱｏＳを有するＡＳセッション要求を表す。構造は、サブスクリプションの要求および応答に使用される。

【0108】

５．１４．２．２．３ 列挙体：ＵｓｅｒＰｌａｎｅＥｖｅｎｔ
列挙体ＵｓｅｒＰｌａｎｅＥｖｅｎｔは、ユーザプレーンイベントを表す。

【0109】

５．１４．４ 使用される特性
以下の表は、ＡｓＳｅｓｓｉｏｎＷｉｔｈＱｏＳ ＡＰＩに適用可能な特性を規定する。これらの特性は、５．２．７項に説明されているようにネゴシエートされる。

【0110】

図１３は、本開示のいくつかの実施形態によるネットワークノード１３００の概略ブロック図である。任意選択的なエレメントは、破線のボックスによって表されている。ネットワークノード１３００は、例えば、本明細書で説明される機能を有するＡＲＦ１２００またはＥＦ１２０２を実装するネットワークノードであってもよい。図示されるように、ネットワークノード１３００は、１つまたは複数のプロセッサ１３０４（例えば、中央処理ユニット（ＣＰＵ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、および／または同様のもの）と、メモリ１３０６と、ネットワークインターフェース１３０８とを含む。１つまたは複数のプロセッサ１３０４は、本明細書では処理回路とも称される。１つまたは複数のプロセッサ１３０４は、本明細書で説明されるネットワークノード１３００の１つまたは複数の機能（例えば、図１２Ａ、図１２Ｂ、および／もしくは図１２Ｃに関するＡＲＦ１２００またはＥＦ１２０２の１つもしくは複数の機能）を提供するように動作する。いくつかの実施形態では、機能は、例えばメモリ１３０６に記憶されたソフトウェアに実装され、１つまたは複数のプロセッサ１３０４によって実行される。

【0111】

図１４は、本開示のいくつかの実施形態によるネットワークノード１３００の仮想化された実施形態を示す概略ブロック図である。本明細書で使用される場合、「仮想化された」ネットワークノードは、ネットワークノード１３００の機能の少なくとも一部分が（例えばネットワーク内の物理的処理ノード上で実行する仮想マシンを介して）仮想構成要素として実装される、ネットワークノード１３００の一実装形態である。図示されるように、この例では、ネットワークノード１３００は、ネットワーク１４０２に結合された、またはネットワーク１４０２の一部として含まれた、１つまたは複数の処理ノード１４００を含み得る。各処理ノード１４００は、１つまたは複数のプロセッサ１４０４（例えば、ＣＰＵ、ＡＳＩＣ、ＦＰＧＡ、および／または同様のもの）と、メモリ１４０６と、ネットワークインターフェース１４０８とを含む。

【0112】

この例では、本明細書で説明されるネットワークノード１３００の機能１４１０（例えば、ＡＲＦ１２００またはＥＦ１２０２の１つまたは複数の機能）は、任意の所望の方式で１つまたは複数の処理ノード１４００において実装される。いくつかの特定の実施形態では、本明細書で説明されるネットワークノード１３００の機能１４１０の一部または全部は、処理ノード１４００によってホストされる仮想環境において実装される１つまたは複数の仮想マシンによって実行される仮想構成要素として実装される。

【0113】

いくつかの実施形態では、少なくとも１つのプロセッサによって実行されたとき、本明細書で説明される実施形態のうちのいずれかによる仮想環境内のネットワークノード１３００の機能１４１０のうちの１つまたは複数を実装するネットワークノード１３００またはノード（例えば、処理ノード１４００）の機能を少なくとも１つのプロセッサに実行させる命令を含むコンピュータプログラムが提供される。いくつかの実施形態では、前述のコンピュータプログラム製品を備えるキャリアが提供される。キャリアは、電子信号、光信号、無線信号、またはコンピュータ可読記憶媒体（例えば、メモリなどの非一過性コンピュータ可読媒体）のうちの１つである。

【0114】

図１５は、本開示のいくつかの他の実施形態によるネットワークノード１３００の概略ブロック図である。ネットワークノード１３００は１つまたは複数のモジュール１５００を含み、モジュール１５００のそれぞれは、ソフトウェアにおいて実装される。モジュール１５００は、本明細書で説明されるネットワークノード１３００の機能（例えば、ＡＲＦ１２００またはＥＦ１２０２の１つもしくは複数の機能）を提供する。この解説は、モジュール１５００が処理ノード１４００のうちの１つにおいて実装され得るか、または複数の処理ノード１４００にわたって分散され得る、図１４の処理ノード１４００に等しく適用可能である。

【0115】

図１６を参照すると、一実施形態によれば、通信システムは、ＲＡＮなどのアクセスネットワーク１６０２とコアネットワーク１６０４とを備える、３ＧＰＰタイプのセルラネットワークなどの通信ネットワーク１６００を含む。アクセスネットワーク１６０２は、ノードＢ、ｅＮＢ、ｇＮＢ、または他のタイプの無線アクセスポイント（ＡＰ）など、複数の基地局１６０６Ａ、１６０６Ｂ、１６０６Ｃを備え、各々が、対応するカバレッジエリア１６０８Ａ、１６０８Ｂ、１６０８Ｃを規定する。各基地局１６０６Ａ、１６０６Ｂ、１６０６Ｃは、有線接続または無線接続１６１０を介してコアネットワーク１６０４に接続可能である。カバレッジエリア１６０８Ｃ中に位置する第１のＵＥ１６１２は、対応する基地局１６０６Ｃに無線で接続するか、または対応する基地局１６０６Ｃによってページングされるように設定される。カバレッジエリア１６０８Ａ中の第２のＵＥ１６１４は、対応する基地局１６０６Ａに無線で接続可能である。この例では複数のＵＥ１６１２、１６１４が示されているが、開示される実施形態は、１つのＵＥのみがカバレッジエリア中にある状況、または１つのＵＥのみが対応する基地局１６０６に接続している状況に等しく適用可能である。

【0116】

通信ネットワーク１６００自体は、ホストコンピュータ１６１６に接続され、ホストコンピュータ１６１６は、スタンドアロンサーバ、クラウド実装サーバ、分散サーバのハードウェアおよび／もしくはソフトウェアにおいて、またはサーバファーム中の処理リソースとして具現化され得る。ホストコンピュータ１６１６は、サービスプロバイダの所有下もしくは制御下にあり得るか、またはサービスプロバイダによってもしくはサービスプロバイダに代わって動作され得る。通信ネットワーク１６００とホストコンピュータ１６１６との間の接続１６１８および１６２０は、コアネットワーク１６０４からホストコンピュータ１６１６まで直接延び得るか、または任意選択的な中間ネットワーク１６２２を介して進み得る。中間ネットワーク１６２２は、パブリックネットワーク、プライベートネットワーク、またはホストされたネットワークのうちの１つ、またはそれらのうちの２つ以上の組合せであり得、中間ネットワーク１６２２は、存在する場合、バックボーンネットワークまたはインターネットであり得、特に、中間ネットワーク１６２２は、２つまたはそれ以上のサブネットワーク（図示せず）を備え得る。

【0117】

図１６の通信システムは全体として、接続されたＵＥ１６１２、１６１４とホストコンピュータ１６１６との間のコネクティビティを可能にする。コネクティビティは、オーバーザトップ（ＯＴＴ）接続１６２４として説明され得る。ホストコンピュータ１６１６および接続されたＵＥ１６１２、１６１４は、アクセスネットワーク１６０２、コアネットワーク１６０４、任意の中間ネットワーク１６２２、および可能なさらなるインフラストラクチャ（図示せず）を媒介として使用して、ＯＴＴ接続１６２４を介してデータおよび／またはシグナリングを通信するように設定される。ＯＴＴ接続１６２４は、ＯＴＴ接続１６２４が通過する関与する通信デバイスがアップリンク通信およびダウンリンク通信のルーティングを認識しないという意味で透過的であり得る。例えば、基地局１６０６は、接続されたＵＥ１６１２にフォワーディング（例えば、ハンドオーバ）されるべき、ホストコンピュータ１６１６から発生したデータを伴う着信ダウンリンク通信の過去のルーティングについて、知らされないことがあるかまたは知らされる必要がない。同様に、基地局１６０６は、ＵＥ１６１２から発生してホストコンピュータ１６１６に向かう発信アップリンク通信の将来のルーティングを認識する必要はない。

【0118】

次に、一実施形態による、前の段落で説明されたＵＥ、基地局、およびホストコンピュータの例示的な実装形態について、図１７を参照して説明する。通信システム１７００において、ホストコンピュータ１７０２は、通信システム１７００の異なる通信デバイスのインターフェースとの有線または無線接続をセットアップおよび維持するように設定された通信インターフェース１７０６を含むハードウェア１７０４を備える。ホストコンピュータ１７０２は、記憶能力および／または処理能力を有し得る処理回路１７０８をさらに備える。特に、処理回路１７０８は、命令を実行するように適合された、１つまたは複数のプログラマブルプロセッサ、ＡＳＩＣ、ＦＰＧＡ、またはこれらの組合せ（図示せず）を備え得る。ホストコンピュータ１７０２は、ソフトウェア１７１０をさらに備え、ソフトウェア１７１０は、ホストコンピュータ１７０２に記憶されているか、またはホストコンピュータ１７０２によってアクセス可能であり、処理回路１７０８によって実行可能である。ソフトウェア１７１０は、ホストアプリケーション１７１２を含む。ホストアプリケーション１７１２は、ＵＥ１７１４およびホストコンピュータ１７０２において終端するＯＴＴ接続１７１６を介して接続するＵＥ１７１４などのリモートユーザにサービスを提供するように動作可能であり得る。リモートユーザにサービスを提供する際、ホストアプリケーション１７１２は、ＯＴＴ接続１７１６を使用して送信されるユーザデータを提供し得る。

【0119】

通信システム１７００は、通信システム内に提供される基地局１７１８をさらに含み、基地局１７１８は、基地局１７１８がホストコンピュータ１７０２およびＵＥ１７１４と通信することを可能にするハードウェア１７２０を備える。ハードウェア１７２０は、通信システム１７００の異なる通信デバイスのインターフェースとの有線接続または無線接続をセットアップおよび維持するための通信インターフェース１７２２、ならびに基地局１７１８によってサーブされるカバレッジエリア（図１７に図示せず）中に位置するＵＥ１７１４との少なくとも無線接続１７２６をセットアップおよび維持するための無線インターフェース１７２４を含み得る。通信インターフェース１７２２は、ホストコンピュータ１７０２への接続１７２８を容易にするように設定され得る。接続１７２８は直接的であり得るか、または接続１７２８は、通信システムのコアネットワーク（図１７に図示せず）および／または通信システムの外側の１つもしくは複数の中間ネットワークを通過し得る。図示の実施形態では、基地局１７１８のハードウェア１７２０は、処理回路１７３０をさらに含み、処理回路１７３０は、命令を実行するように適合された、１つまたは複数のプログラマブルプロセッサ、ＡＳＩＣ、ＦＰＧＡ、またはこれらの組合せ（図示せず）を備え得る。基地局１７１８は、内部に記憶されるかまたは外部接続を介してアクセス可能なソフトウェア１７３２をさらに有する。

【0120】

通信システム１７００は、すでに言及されたＵＥ１７１４をさらに含む。ＵＥ１７１４のハードウェア１７３４は、ＵＥ１７１４が現在位置するカバレッジエリアをサーブする基地局との無線接続１７２６をセットアップおよび維持するように設定された、無線インターフェース１７３６を含み得る。ＵＥ１７１４のハードウェア１７３４は、処理回路１７３８をさらに含み、処理回路１７３８は、命令を実行するように適合された、１つまたは複数のプログラマブルプロセッサ、ＡＳＩＣ、ＦＰＧＡ、またはこれらの組合せ（図示せず）を備え得る。ＵＥ１７１４は、ソフトウェア１７４０をさらに備え、ソフトウェア１７４０は、ＵＥ１７１４に記憶されているか、またはＵＥ１７１４によってアクセス可能であり、処理回路１７３８によって実行可能である。ソフトウェア１７４０は、クライアントアプリケーション１７４２を含む。クライアントアプリケーション１７４２は、ホストコンピュータ１７０２のサポートを伴って、ＵＥ１７１４人間のまたは人間でないユーザにサービスを提供するように動作可能であり得る。ホストコンピュータ１７０２では、実行しているホストアプリケーション１７１２は、ＵＥ１７１４およびホストコンピュータ１７０２において終端するＯＴＴ接続１７１６を介して、実行しているクライアントアプリケーション１７４２と通信し得る。ユーザにサービスを提供する際、クライアントアプリケーション１７４２は、ホストアプリケーション１７１２から要求データを受信し、要求データに応答してユーザデータを提供し得る。ＯＴＴ接続１７１６は、要求データとユーザデータとの両方を伝達し得る。クライアントアプリケーション１７４２は、クライアントアプリケーション１７４２が提供するユーザデータを生成するためにユーザと対話し得る。

【0121】

図１７に示されているホストコンピュータ１７０２、基地局１７１８、およびＵＥ１７１４は、それぞれ、図１６のホストコンピュータ１６１６、基地局１６０６Ａ、１６０６Ｂ、１６０６Ｃのうちの１つ、およびＵＥ１６１２、１６１４のうちの１つと同様または同等であり得ることに留意されたい。すなわち、これらのエンティティの内部の働きは図１７に示されているようなものであり得、またそれとは別に、周囲のネットワークトポロジは、図１６のものであり得る。

【0122】

図１７では、ＯＴＴ接続１７１６は、仲介デバイスとこれらのデバイスを介したメッセージの厳密なルーティングとへの明示的言及なしに、基地局１７１８を介したホストコンピュータ１７０２とＵＥ１７１４との間の通信を示すために抽象的に描かれている。ネットワークインフラストラクチャは、ルーティングを決定し得、ルーティングは、ＵＥ１７１４からもしくはホストコンピュータ１７０２を動作させるサービスプロバイダから、またはその両方から隠れるように設定され得る。ＯＴＴ接続１７１６がアクティブである間、ネットワークインフラストラクチャはさらに、ネットワークインフラストラクチャが（例えば、負荷分散の考慮またはネットワークの再設定に基づいて）ルーティングを動的に変更する際の決定を行い得る。

【0123】

ＵＥ１７１４と基地局１７１８との間の無線接続１７２６は、本開示全体にわたって説明される実施形態の教示に従う。様々な実施形態のうちの１つまたは複数は、無線接続１７２６が最後のセグメントを形成するＯＴＴ接続１７１６を使用して、ＵＥ１７１４に提供されるＯＴＴサービスの性能を改善する。

【0124】

１つまたは複数の実施形態が改善の対象とするデータレート、レイテンシ、および他の要因を監視することを目的として、測定手順が提供され得る。測定結果の変動に応じてホストコンピュータ１７０２とＵＥ１７１４との間のＯＴＴ接続１７１６を再設定するための任意選択的なネットワーク機能がさらに存在し得る。測定手順および／またはＯＴＴ接続１７１６を再設定するためのネットワーク機能は、ホストコンピュータ１７０２のソフトウェア１７１０およびハードウェア１７０４において、もしくはＵＥ１７１４のソフトウェア１７４０およびハードウェア１７３４において、またはその両方において実装され得る。いくつかの実施形態では、ＯＴＴ接続１７１６が通過する通信デバイスにおいて、またはその通信デバイスに関連して、センサ（図示せず）が展開され得、センサは、上記で例示された監視された量の値を供給すること、またはソフトウェア１７１０、１７４０が監視される量を計算もしくは推定し得る際の基となる他の物理量の値を供給することによって、測定手順に関与し得る。ＯＴＴ接続１７１６の再設定は、メッセージフォーマット、再送信セッティング、好ましいルーティングなどを含み得、再設定は、基地局１７１８に影響を及ぼす必要はなく、再設定は、基地局１７１８にとって未知または認識不可能であり得る。このような手順および機能は、当技術分野において知られており、実践され得る。いくつかの実施形態では、測定は、スループット、伝搬時間、レイテンシなどのホストコンピュータ１７０２の測定を容易にする独自のＵＥシグナリングを伴い得る。測定は、ソフトウェア１７１０および１７４０が伝搬時間、エラーなどを監視する間、ソフトウェア１７１０および１７４０が、ＯＴＴ接続１７１６を使用して、メッセージ、具体的には空のメッセージまたは「ダミー」メッセージを送信させるという点において実装され得る。

【0125】

図１８は、一実施形態による、通信システムにおいて実装される方法を示すフローチャートである。通信システムは、図１６および図１７を参照しながら説明されたものであり得る、ホストコンピュータと基地局とＵＥとを含む。本開示を簡潔にするために、図１８への図面参照のみがこのセクションに含まれる。ステップ１８００において、ホストコンピュータは、ユーザデータを提供する。ステップ１８００の（任意選択的であり得る）サブステップ１８０２において、ホストコンピュータは、ホストアプリケーションを実行することによってユーザデータを提供する。ステップ１８０４において、ホストコンピュータは、ユーザデータをＵＥに搬送する送信を始動する。（任意選択的であり得る）ステップ１８０６において、本開示全体にわたって説明される実施形態の教示に従って、基地局は、ホストコンピュータが始動した送信において搬送されたユーザデータをＵＥへ送信する。（同様に任意選択的であり得る）ステップ１８０８において、ＵＥは、ホストコンピュータによって実行されたホストアプリケーションに関連したクライアントアプリケーションを実行する。

【0126】

図１９は、一実施形態による、通信システムにおいて実装される方法を示すフローチャートである。通信システムは、図１６および図１７を参照しながら説明されたものであり得る、ホストコンピュータと基地局とＵＥとを含む。本開示を簡潔にするために、図１９への図面参照のみがこのセクションに含まれる。方法のステップ１９００において、ホストコンピュータは、ユーザデータを提供する。任意選択的であるサブステップ（図示せず）において、ホストコンピュータは、ホストアプリケーションを実行することによってユーザデータを提供する。ステップ１９０２において、ホストコンピュータは、ユーザデータをＵＥに搬送する送信を始動する。本開示全体にわたって説明される実施形態の教示に従って、送信は、基地局を経由し得る。（任意選択的であり得る）ステップ１９０４において、ＵＥは、送信において搬送されたユーザデータを受信する。

【0127】

図２０は、一実施形態による、通信システムにおいて実装される方法を示すフローチャートである。通信システムは、図１６および図１７を参照しながら説明されたものであり得る、ホストコンピュータと基地局とＵＥとを含む。本開示を簡潔にするために、図２０への図面参照のみがこのセクションに含まれる。（任意選択的であり得る）ステップ２０００において、ＵＥは、ホストコンピュータによって提供された入力データを受信する。追加としてまたは代替として、（任意選択的であり得る）ステップ２００２において、ＵＥは、ユーザデータを提供する。ステップ２０００の（任意選択的であり得る）サブステップ２００４において、ＵＥは、クライアントアプリケーションを実行することによって、ユーザデータを提供する。ステップ２００２の（任意選択的であり得る）サブステップ２００６において、ＵＥは、ホストコンピュータによって提供された受信された入力データに応答してユーザデータを提供するクライアントアプリケーションを実行する。ユーザデータを提供する際、実行されたクライアントアプリケーションは、ユーザから受信されたユーザ入力をさらに考慮し得る。ユーザデータが提供された特定の様式にかかわらず、（任意選択的であり得る）サブステップ２００８において、ＵＥは、ホストコンピュータへのユーザデータの送信を始動する。方法のステップ２０１０において、本開示全体にわたって説明される実施形態の教示に従って、ホストコンピュータは、ＵＥから送信されたユーザデータを受信する。

【0128】

図２１は、一実施形態による、通信システムにおいて実装される方法を示すフローチャートである。通信システムは、図１６および図１７を参照しながら説明されたものであり得る、ホストコンピュータと基地局とＵＥとを含む。本開示を簡潔にするために、図２１への図面参照のみがこのセクションに含まれる。（任意選択的であり得る）ステップ２１００において、本開示全体にわたって説明される実施形態の教示に従って、基地局は、ＵＥからユーザデータを受信する。（任意選択的であり得る）ステップ２１０２において、基地局は、ホストコンピュータへの受信されたユーザデータの送信を始動する。ステップ２１０４において、ホストコンピュータは、基地局によって始動された送信において搬送されたユーザデータを受信する。

【0129】

本明細書に開示される任意の適切なステップ、方法、特徴、機能、または利益は、１つまたは複数の仮想装置の１つまたは複数の機能ユニットまたはモジュールを通じて実行され得る。各仮想装置は、いくつかのこれらの機能ユニットを備え得る。これらの機能ユニットは、１つまたは複数のマイクロプロセッサまたはマイクロコントローラを含み得る処理回路、ならびにデジタル信号プロセッサ（ＤＳＰ）、専用デジタル論理、および同様のものを含み得る他のデジタルハードウェアを介して、実装され得る。処理回路は、読出し専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、キャッシュメモリ、フラッシュメモリデバイス、光学記憶デバイスなどの１つまたはいくつかのタイプのメモリを含み得るメモリに記憶されたプログラムコードを実行するように設定され得る。メモリに記憶されるプログラムコードは、１つまたは複数の通信および／またはデータ通信プロトコルを実行するためのプログラム命令、ならびに本明細書で説明される技法のうちの１つまたは複数を実行するための命令を含む。いくつかの実装形態では、処理回路は、それぞれの機能ユニットに、本開示の１つまたは複数の実施形態による対応する機能を実行させるために使用され得る。

【0130】

図中のプロセスは、本開示のいくつかの実施形態によって実行される動作の特定の順序を示し得るが、このような順序が例示であること（例えば、代替実施形態が、異なる順序で動作を実行する、いくつかの動作を組み合わせる、いくつかの動作を重複させ得ることなど）が理解されるべきである。

【0131】

本開示において、以下の略語の少なくともいくつかが使用され得る。略語間に不整合がある場合、その略語が上記でどのように使用されているかが優先されるべきである。以下で複数回列挙される場合、最初の列挙が任意の後続の列挙よりも優先されるべきである。
・３ＧＰＰ 第３世代パートナーシッププロジェクト
・５Ｇ 第５世代
・５ＧＣ 第５世代コア
・５ＧＳ 第５世代システム
・ＡＦ アプリケーション機能
・ＡＭＦ アクセスおよびモビリティ機能
・ＡＮ アクセスネットワーク
・ＡＰ アクセスポイント
・ＡＲＦ アプリケーション関連機能
・ＡＳ アプリケーションサーバ
・ＡＳＩＣ 特定用途向け集積回路
・ＡＵＳＦ 認証サーバ機能
・ＣＰＵ 中央処理ユニット
・ＤＮ データネットワーク
・ＤＳＰ デジタル信号プロセッサ
・ｅＮＢ 拡張またはエボルブドノードＢ
・ＥＦ 公開機能
・ＥＰＳ エボルブドパケットシステム
・Ｅ－ＵＴＲＡ 拡張ユニバーサル地上無線アクセス
・ＦＰＧＡ フィールドプログラマブルゲートアレイ
・ｇＮＢ 新無線基地局
・ｇＮＢ－ＤＵ 新無線基地局分散ユニット
・ＨＳＳ ホーム加入者サーバ
・ＩｏＴ モノのインターネット
・ＩＰ インターネットプロトコル
・ＬＴＥ Ｌｏｎｇ－Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ
・ＭＭＥ モビリティ管理エンティティ
・ＭＴＣ マシン型通信
・ＮＥＦ ネットワーク公開機能
・ＮＦ ネットワーク機能
・ＮＲ 新無線
・ＮＲＦ ネットワーク機能リポジトリ機能
・ＮＳＳＦ ネットワークスライス選択機能
・ＯＴＴ オーバーザトップ
・ＰＣ パーソナルコンピュータ
・ＰＣＦ ポリシ制御機能
・ＰＦ ポリシ機能
・ＰＣＲＦ ポリシおよび課金ルール機能
・Ｐ－ＧＷ パケットデータネットワークゲートウェイ
・ＱｏＳ サービス品質
・ＲＡＭ ランダムアクセスメモリ
・ＲＡＮ 無線アクセスネットワーク
・ＲＯＭ 読出し専用メモリ
・ＲＲＨ リモート無線ヘッド
・ＲＴＴ ラウンドトリップタイム
・ＳＣＥＦ サービス能力公開機能
・ＳＣＳ サービス能力サーバ
・ＳＭＦ セッション管理機能
・ＴＣＩ 送信設定インジケータ
・ＴＲＰ 送信／受信ポイント
・ＵＤＭ 統合データ管理
・ＵＥ ユーザ機器
・ＵＰＦ ユーザプレーン機能

【0132】

当業者は、本開示の実施形態に対する改良および修正を認識するであろう。このような改良および修正はすべて、本明細書に開示される概念の範囲内にあると見なされる。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12A】

【図12B】

【図12C】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】