特表 2024-533920 モノのインターネット（ＩｏＴ）ネットワークにおいてサービス品質（ＱｏＳ）を最適化するためのシステムおよび方法

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

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2024-09-18

(54)【発明の名称】モノのインターネット（ＩｏＴ）ネットワークにおいてサービス品質（ＱｏＳ）を最適化するためのシステムおよび方法

(51)【国際特許分類】

   H04W 28/24 20090101AFI20240910BHJP

   H04W 24/02 20090101ALI20240910BHJP

   H04W 4/70 20180101ALI20240910BHJP

【ＦＩ】

H04W28/24

H04W24/02

H04W4/70

【審査請求】未請求

【予備審査請求】未請求

(21)【出願番号】P 2023520006

(86)(22)【出願日】2022-08-27

(85)【翻訳文提出日】2023-05-26

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

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

(87)【国際公開日】2023-03-09

(31)【優先権主張番号】202121039486

(32)【優先日】2021-08-31

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

(81)【指定国・地域】

【公序良俗違反の表示】

（特許庁注：以下のものは登録商標）

１．ＦＩＲＥＷＩＲＥ

(71)【出願人】

【識別番号】523112747

【氏名又は名称】ジェイアイオー・プラットフォームズ・リミテッド

(74)【代理人】

【識別番号】100108453

【弁理士】

【氏名又は名称】村山 靖彦

(74)【代理人】

【識別番号】100110364

【弁理士】

【氏名又は名称】実広 信哉

(74)【代理人】

【識別番号】100133400

【弁理士】

【氏名又は名称】阿部 達彦

(72)【発明者】

【氏名】サティシュ・ナンジュンダ・スワミー・ジャマダニ

(72)【発明者】

【氏名】マヘシュ・ナヤカ・マイソレ・アナイア

(72)【発明者】

【氏名】マシュー・オーメン

(72)【発明者】

【氏名】プラディープ・クリシュナムルティ・ヒリサヴェ

(72)【発明者】

【氏名】ヴィナイ・シュリヴァスタヴァ

【テーマコード（参考）】

5K067

【Ｆターム（参考）】

5K067AA41

5K067BB27

5K067EE02

5K067EE10

5K067EE16

5K067GG06

(57)【要約】

IoTネットワークにおいてUEのQoSプロファイルに基づいてネットワークリソースを割り当て、IoTネットワークのQoSを最適化するための手法が、説明される。一例において、要求が、ユーザ機器(UE)から受信されてよい。UEは、ネットワークを介してシステムと通信してよい。さらに、受信された要求は、UEパラメータのセットを含んでよい。その後、UEパラメータのセットが、受信された要求から抽出されてよい。抽出されたUEパラメータのセットに基づいて、サービス品質(QoS)プロファイルが、要求に割り振られてよい。その後、割り振られたQoSプロファイルに基づいて、複数のネットワークリソースのうちの少なくとも1つが、要求を生成するUEに割り当てられてよい。

【特許請求の範囲】

【請求項1】

モノのインターネット(IoT)ネットワークにおいてユーザ機器(UE)のサービス品質(QoS)プロファイルに基づいてネットワークリソースを割り当てるためのシステムであって、
プロセッサと、
前記プロセッサに結合された分析エンジンと
を備え、前記分析エンジンは、
ユーザ機器(UE)から要求を受信することであって、前記UEが、ネットワークを介してシステムと通信し、前記UEからの受信された要求が、UEパラメータのセットを含む、受信すること、
前記受信された要求からUEパラメータの前記セットを抽出すること、
UEパラメータの前記抽出されたセットに基づいて、前記要求にサービス品質(QoS)プロファイルを割り振ること、および
前記割り振られたQoSプロファイルに基づいて、前記要求を生成する前記UEに複数のネットワークリソースのうちの少なくとも1つを割り当てること
を行うように構成される、システム。

【請求項2】

前記要求が、通信モデムを通じて前記UEから受信され、
前記通信モデムが、前記ネットワークを介して前記UEおよび前記システムに通信可能なように結合される請求項1に記載のシステム。

【請求項3】

前記分析エンジンが、さらに、
前記UEからの前記受信された要求に基づいて、前記ネットワークを介して、前記UEとのプロトコルデータユニット(PDU)セッションを確立するように構成される請求項1に記載のシステム。

【請求項4】

前記分析エンジンが、
UEパラメータの前記抽出されたセットに基づいて、予め定義されたマッピング基準に基づいて前記要求に前記QoSプロファイルを割り振るように構成される請求項1に記載のシステム。

【請求項5】

前記分析エンジンが、
前記UEからの前記要求を、UEパラメータの前記抽出されたセットに基づいて、レイテンシに敏感な要求およびレイテンシに敏感でない要求のうちの1つであるようにカテゴリ分けするように構成される請求項1に記載のシステム。

【請求項6】

前記要求を生成する前記UEに割り当てられる前記複数のネットワークリソースが、処理リソースの割り当て、メモリリソースの割り当て、実行の優先レベルの割り振り、またはそれらの組合せのうちの1つを含む請求項1に記載のシステム。

【請求項7】

前記分析エンジンが、前記UEに前記処理リソースを割り当てるために、
前記要求を生成する前記UEに、前記ネットワーク内の複数のエンティティのうちの1つの複数の処理リソースのうちの1つを利用させるように構成される請求項6に記載のシステム。

【請求項8】

前記分析エンジンが、前記UEに前記メモリリソースを割り当てるために、
前記要求を生成する前記UEに、前記ネットワーク内の複数のエンティティのうちの1つの複数のキャッシュメモリのうちの1つを利用させるように構成される請求項6に記載のシステム。

【請求項9】

前記分析エンジンが、前記UEに実行の優先レベルを割り振るために、
特定の期間、前記要求を実行する際に遅延を引き起こすように構成される請求項6に記載のシステム。

【請求項10】

UEパラメータの前記セットが、センサーデータ、アプリケーションデータ、またはそれらの組合せのうちの1つを含む請求項1に記載のシステム。

【請求項11】

前記センサーデータが、前記UEと通信する複数のセンサーのうちの1つから取得される請求項10に記載のシステム。

【請求項12】

前記アプリケーションデータが、前記UE上で実行されるアプリケーションから取得される請求項10に記載のシステム。

【請求項13】

モノのインターネット(IoT)ネットワークにおいてユーザ機器(UE)のサービス品質(QoS)プロファイルに基づいてネットワークリソースを割り当てるための方法であって、
分析エンジンによって、ユーザ機器(UE)から要求を受信するステップであって、前記UEが、ネットワークを介してシステムと通信し、前記UEからの受信された要求が、UEパラメータのセットを含む、ステップと、
前記分析エンジンによって、前記受信された要求からUEパラメータの前記セットを抽出するステップと、
UEパラメータの前記抽出されたセットに基づいて、前記分析エンジンによって、前記要求にサービス品質(QoS)プロファイルを割り振るステップと、
前記割り振られたQoSプロファイルに基づいて、前記分析エンジンによって、前記要求を生成する前記UEに複数のネットワークリソースのうちの少なくとも1つを割り当てるステップと
を含む、方法。

【請求項14】

前記分析エンジンによって、前記UEから前記要求を受信するステップが、通信モデムを通じて前記要求を受信することであって、前記通信モデムが、前記ネットワークを介して前記UEおよび前記システムに通信可能なように結合される、受信することを含む請求項13に記載の方法。

【請求項15】

前記UEからの前記受信された要求に基づいて、前記ネットワークを介して、前記UEとのプロトコルデータユニット(PDU)セッションを確立するステップをさらに含む請求項13に記載の方法。

【請求項16】

前記分析エンジンによって、UEパラメータの前記抽出されたセットに基づいて、前記QoSプロファイルを割り振るステップが、予め定義されたマッピング基準に基づく請求項13に記載の方法。

【請求項17】

UEパラメータの前記抽出されたセットに基づいて、前記UEからの前記要求を、レイテンシに敏感な要求およびレイテンシに敏感でない要求のうちの1つであるようにカテゴリ分けするステップをさらに含む請求項13に記載の方法。

【請求項18】

前記要求を生成する前記UEに前記複数のネットワークリソースを割り当てるステップが、処理リソースを割り当てること、メモリリソースを割り当てること、実行の優先レベルを割り振ること、またはそれらの組合せを含む請求項13に記載の方法。

【請求項19】

前記分析エンジンによって、前記UEに前記処理リソースを割り当てるステップが、
前記要求を生成する前記UEに、前記ネットワーク内の複数のエンティティのうちの1つの複数の処理リソースのうちの1つを利用させることを含む請求項18に記載の方法。

【請求項20】

前記分析エンジンによって、前記UEに前記メモリリソースを割り当てるステップが、
前記要求を生成する前記UEに、前記ネットワーク内の複数のエンティティのうちの1つの複数のキャッシュメモリのうちの1つを利用させることを含む請求項18に記載の方法。

【請求項21】

前記分析エンジンによって、前記UEに実行の優先レベルを割り振るステップが、特定の期間、前記要求を実行する際に遅延を引き起こすことを含む請求項18に記載の方法。

【請求項22】

UEパラメータの前記セットが、センサーデータ、アプリケーションデータ、またはそれらの組合せのうちの1つを含む請求項13に記載の方法。

【請求項23】

前記センサーデータが、前記UEと通信する複数のセンサーのうちの1つから取得される請求項22に記載の方法。

【請求項24】

前記アプリケーションデータが、前記UE上で実行されるアプリケーションから取得される請求項22に記載の方法。

【発明の詳細な説明】

【技術分野】

【0001】

本開示の実施形態は、概して、モノのインターネット(IoT)ネットワークにおいてサービス品質(QoS)を最適化するための手法に関する。より詳細には、本開示は、モノのインターネット(IoT)ネットワークにおいてユーザ機器(UE)のサービス品質(QoS)プロファイルに基づいてネットワークリソースを割り当てるための手法に関する。

【背景技術】

【0002】

関連技術の以下の説明は、本開示の分野に関連する背景情報を提供するように意図されている。本節は、本開示の様々な特徴に関連する可能性がある技術の特定の態様を含む場合がある。しかし、本節は、本開示に関する読者の理解を深めるためにのみ使用され、従来技術を認めるものとして使用されないことを理解されたい。

【0003】

概して、センサー、ユーザデバイス、およびサーバなどの複数のデバイスが、モノのインターネット(IoT)ネットワークを形成するために接続される場合がある。現在、IoTデバイスからのデータは、任意のその他の通常の機器と同様に扱われる場合があり、データは、任意のインターネットデータと同様に扱われ、したがって、デフォルトのサービス品質(QoS)プロファイルが、設定される。現在、IoTアプリケーション/データが、信頼性、レイテンシへの敏感さの観点でのその全体的なエンドユースケースの属性に基づいて扱われるようなインテリジェンス(intelligence)/メカニズムは、現在のエコシステムに存在しない可能性がある。現実の世界では、データが特定の遅延の後にシステムを横断して送信されることが可能であり、その場合、ネットワークがそのリソースおよび計算負荷が原因でデータをキャッシュし、ある期間にわたってそのデータを送信することができる多くのそのようなIoTアプリケーションが存在する。また、エンドユースケースのシナリオが原因で、特定のデータが特定の計算を必要とする可能性がある。

【0004】

たとえば、農業IoT環境において、様々なセンサーによって収集されたデータは、時間が重要でない場合があり、したがって、システムを横断して即座に送信する必要がない場合があり、様々なレベルでキャッシュされることが可能であり、送信は、1日に1回、またはエンドユースケースのシナリオに基づいてシステム内のアプリケーションサーバもしくはデバイスによって構成される場合がある。また、土壌のpH、水分などのセンサーデータは、それがエンドユーザにまったく意味をなさない場合があり、センサーデータから意味のあるデータを作成するために特定の計算または数学的な統計モデルが実行されることを必要とするので、そのまま送信されない。そのような計算は、様々なレベル--デバイス、RAN、もしくはアプリケーションサーバ、またはアプリケーション機能(5Gネットワークの一部)--で行われる場合がある。したがって、本質的に、IoTアプリケーションは、レイテンシに敏感でないかまたはレイテンシに敏感である場合がある。レイテンシに敏感でないアプリケーションデータは、データがアプリケーションサーバに送信される前に、無線アクセスシステム(RAS)に長期間キャッシュされる場合がある。

【0005】

アプリケーションがレイテンシに敏感であるかまたはレイテンシに敏感でないかと、さらには、そのようなアプリケーションがGSMの進化のための高速化されたデータレート(EDGE: Enhanced Data rates for GSM Evolution)または無線アクセスエンティティにおけるキャッシュおよび/またはデータ処理のサポートを必要とする場合があるかどうかとを特定するための従来の方法は、存在しない。既存のセルラネットワーク(第4世代(4G)、5G、NB-IoT)は、新たに生まれたIoTアプリケーションタイプには適切でないQoSカテゴリをサポートする。IoTアプリケーションタイプは、医療用IoTデバイスなどのレイテンシに敏感なカテゴリから、農業分野で使用される土壌センサーIoTデバイスなどのレイテンシに敏感でないデバイスまたはアプリケーションタイプにまで及ぶ可能性がある。従来のQoSパラメータは、「スループット、通過遅延(transit delay)、優先度、保護」などの値を含む場合があるが、データストリーム、データのパケット、またはデバイスから発信される任意のデータがキャッシュを必要とするかどうか、キャッシュの局所性、データが処理の詳細の性質をローカルで処理することを必要とするかどうかを含まない場合がある。

【0006】

したがって、既存の従来技術の欠点を克服することができる方法およびシステムを提供するニーズが当技術分野に存在する。

【発明の概要】

【発明が解決しようとする課題】

【0007】

本明細書の少なくとも1つの実施形態が満たす本開示の目的のいくつかは、本明細書において以下に列挙される通りである。

【0008】

本開示の目的は、モノのインターネット(IoT)ネットワークにおけるサービス品質(QoS)の効率的で、レイテンシに敏感な、および信頼性の高い最適化のためのシステムおよび方法を提供することである。

【0009】

本開示の別の目的は、アプリケーションがレイテンシに敏感でないかどうか、EDGEおよび/または無線アクセスノードにおいてキャッシュのサポートおよび/または連携された処理能力を必要とするかどうかを特定するのに役立つ新しいQoSプロファイルのためのシステムおよび方法を提供することである。

【0010】

本開示の別の目的は、特定のアプリケーションのためのインテリジェントなデータ処理を実行してよい無線アクセスネットワーク内の追加のコンピュートエンティティをサポートするためのシステムおよび方法を提供することである。

【0011】

本開示の別の目的は、IoTアプリケーションカテゴリまたはタイプを認識するシステムおよび方法を提供することであり、そのとき、IoTアプリケーションカテゴリまたはタイプは、新しいQoSクラスを適切に割り振るためにIoTネットワークによって使用される。

【0012】

本開示の別の目的は、一部のアプリケーションの優先度が相対的であるときに、カテゴリタイプの間で(たとえば、レイテンシに敏感でないタイプからレイテンシに敏感なタイプへ)優先度を変更するためのシグナリングのためのシステムおよび方法を提供することである。

【0013】

本開示の別の目的は、新しいアプリケーションカテゴリを定義された新しいQoSクラス識別子にマッピングすることができる、アプリケーションと非アクセス層(NAS)との間のモデムインターフェースを利用するシステムおよび方法を提供することである。

【0014】

本開示の別の目的は、IoTアプリケーション/データを、信頼性、レイテンシへの敏感さの観点でのその全体的なエンドユースケースの属性に基づいて扱うためのシステムおよび方法を提供することである。

【0015】

本開示の別の目的は、データストリーム、データのパケット、またはデバイスから発信される任意のデータがキャッシュを必要とするかどうか、キャッシュの局所性、それが処理の詳細の性質をローカルで処理することを必要とするかどうかなどのQoSパラメータを含めるためのシステムおよび方法を提供することである。

【0016】

本開示の別の目的は、拡張されたQoSテンプレートのQoSメカニズム、レイテンシに敏感でないアプリケーションのためのそのような新しいQoSテンプレートを解釈し、適用するメカニズムのためのシステムおよび方法を提供することである。

【課題を解決するための手段】

【0017】

本開示の目的の本開示の実施形態は、モノのインターネット(IoT)ネットワークにおいてサービス品質(QoS)を最適化するための手法に関する。より詳細には、本開示は、モノのインターネット(IoT)ネットワークにおいてユーザ機器(UE)のサービス品質(QoS)プロファイルに基づいてネットワークリソースを割り当てるための手法に関する。

【0018】

本開示の実施形態は、モノのインターネット(IoT)ネットワークにおいてユーザ機器(UE)のサービス品質(QoS)プロファイルに基づいてネットワークリソースを割り当てるためのシステムに関する。システムは、プロセッサと、プロセッサに結合された分析エンジンとを含んでよい。分析エンジンは、ユーザ機器(UE)から要求を受信するように構成されてよい。UEは、ネットワークを介してシステムと通信してよい。さらに、受信された要求は、UEパラメータのセットを含んでよい。その後、UEパラメータのセットが、受信された要求から抽出されてよい。UEパラメータの抽出されたセットに基づいて、サービス品質(QoS)プロファイルが、要求に割り振られてよい。その後、割り振られたQoSプロファイルに基づいて、複数のネットワークリソースのうちの少なくとも1つが、要求を生成するUEに割り当てられてよい。

【0019】

1つの態様において、要求は、通信モデムを通じてUEから受信されてよい。通信モデムは、ネットワークを介してUEおよびシステムに通信可能なように結合されてよい。

【0020】

別の態様において、分析エンジンは、UEからの受信された要求に基づいて、UEとのプロトコルデータユニット(PDU)セッションを確立するようにさらに構成されてよい。

【0021】

さらに別の態様において、分析エンジンは、予め定義されたマッピング基準に基づいて、プロファイルにQoSプロファイルを割り振ってよい。

【0022】

さらに別の態様において、分析エンジンは、UEパラメータの抽出されたセットに基づいて、UEからの要求を、レイテンシに敏感な要求およびレイテンシに敏感でない要求のうちの1つであるようにカテゴリ分けしてよい。

【0023】

さらに別の態様において、要求を生成するUEへの複数のネットワークリソースの割り当ては、処理リソースの割り当て、メモリリソースの割り当て、実行の優先レベルの割り振り、またはそれらの組合せのうちの1つを含んでよい。

【0024】

さらに別の態様において、UEに処理リソースを割り当てることは、要求を生成するUEに、ネットワーク内の複数のエンティティのうちの1つの複数の処理リソースのうちの1つを利用させることを含んでよい。

【0025】

さらに別の態様において、UEにメモリリソースを割り当てることは、要求を生成するUEに、ネットワーク内の複数のエンティティのうちの1つの複数のキャッシュメモリのうちの1つを利用させることを含んでよい。

【0026】

さらに別の態様において、UEに実行の優先レベルを割り振ることは、特定の期間、要求を実行する際に遅延を引き起こすことを含んでよい。

【0027】

さらに別の態様において、UEパラメータのセットは、センサーデータ、アプリケーションデータ、またはそれらの組合せのうちの1つを含んでよい。

【0028】

さらに別の態様において、センサーデータは、UEと通信する複数のセンサーのうちの1つから取得されてよい。

【0029】

さらに別の態様において、アプリケーションデータは、UE上で実行されるアプリケーションから取得されてよい。

【0030】

本開示の別の実施形態は、モノのインターネット(IoT)ネットワークにおいてユーザ機器(UE)のサービス品質(QoS)プロファイルに基づいてネットワークリソースを割り当てるための方法に関する。方法は、分析エンジンによって、ユーザ機器(UE)から要求を受信するステップを含んでよい。UEは、ネットワークを介してシステムと通信してよい。さらに、受信された要求は、UEパラメータのセットを含んでよい。その後、UEパラメータのセットが、受信された要求から抽出されてよい。UEパラメータの抽出されたセットに基づいて、サービス品質(QoS)プロファイルが、要求に割り振られてよい。その後、割り振られたQoSプロファイルに基づいて、複数のネットワークリソースのうちの少なくとも1つが、要求を生成するUEに割り当てられてよい。

【0031】

1つの態様において、要求は、通信モデムを通じてUEから受信されてよい。通信モデムは、ネットワークを介してUEおよびシステムに通信可能なように結合されてよい。

【0032】

別の態様において、方法は、UEからの受信された要求に基づいて、UEとのプロトコルデータユニット(PDU)セッションを確立するステップをさらに含んでよい。

【0033】

さらに別の態様において、プロファイルにQoSプロファイルを割り振るステップが、予め定義されたマッピング基準に基づいてよい。

【0034】

さらに別の態様において、方法は、UEパラメータの抽出されたセットに基づいて、UEからの要求を、レイテンシに敏感な要求およびレイテンシに敏感でない要求のうちの1つであるようにカテゴリ分けするステップをさらに含んでよい。

【0035】

さらに別の態様において、要求を生成するUEに複数のネットワークリソースを割り当てるステップが、処理リソースを割り当てること、メモリリソースを割り当てること、実行の優先レベルを割り振ること、またはそれらの組合せを含んでよい。

【0036】

さらに別の態様において、UEに処理リソースを割り当てるステップは、要求を生成するUEに、ネットワーク内の複数のエンティティのうちの1つの複数の処理リソースのうちの1つを利用させることを含んでよい。

【0037】

さらに別の態様において、UEにメモリリソースを割り当てるステップは、要求を生成するUEに、ネットワーク内の複数のエンティティのうちの1つの複数のキャッシュメモリのうちの1つを利用させることを含んでよい。

【0038】

さらに別の態様において、UEに実行の優先レベルを割り振るステップは、特定の期間、要求を実行する際に遅延を引き起こすことを含んでよい。

【0039】

さらに別の態様において、UEパラメータのセットは、センサーデータ、アプリケーションデータ、またはそれらの組合せのうちの1つを含んでよい。

【0040】

さらに別の態様において、センサーデータは、UEと通信する複数のセンサーのうちの1つから取得されてよい。

【0041】

さらに別の態様において、アプリケーションデータは、UE上で実行されるアプリケーションから取得されてよい。

【0042】

発明の対象の様々な目的、特徴、態様、および利点は、同様の番号が同様のコンポーネントを表す添付の図面をともなう、好ましい実施形態の以下の詳細な説明からより明らかになるであろう。

【0043】

本明細書に組み込まれ、本発明の一部を構成する添付の図面は、開示される方法およびシステムの例示的な実施形態を示し、同様の参照番号が、様々な図面全体を通じて同じ部分を指す。図面のコンポーネントは必ずしも正しい縮尺でなく、その代わりに、本発明の原理を明瞭に示すことに重点が置かれる。一部の図面は、ブロック図を使用してコンポーネントを示す場合があり、各コンポーネントの内部回路を表さない場合がある。そのような図面の発明が電気的コンポーネント、電子的コンポーネント、またはそのようなコンポーネントを実装するためによく使用される回路の発明を含むことは、当業者には理解されるであろう。

【図面の簡単な説明】

【0044】

【図1】本開示の実施形態による、本開示の提案されるシステムが実装され得る例示的なネットワークアーキテクチャを示す図である。

【図2】本開示の実施形態による、モノのインターネット(IoT)ネットワークにおいてサービス品質(QoS)を最適化するために提案されるシステムの例示的な表現を示す図である。

【図3】本開示の実施形態による、システムに実装される、モノのインターネット(IoT)ネットワークにおいてサービス品質(QoS)を最適化するためのフローチャートである。

【図4】本開示の実施形態による、QoS設定のための計算レベルの例示的なシーケンス図表現である。

【図5A】本開示の実施形態による、アプリケーションと通信モデムとの間のアプリケーションタイプ(AT)コマンドの例示的なシーケンス図表現である。

【図5B】本開示の実施形態による、アプリケーションと通信モデムとの間のアプリケーションタイプ(AT)コマンドの例示的なシーケンス図表現である。

【図5C】本開示の実施形態による、アプリケーションと通信モデムとの間のアプリケーションタイプ(AT)コマンドの例示的なシーケンス図表現である。

【図5D】本開示の実施形態による、アプリケーションと通信モデムとの間のアプリケーションタイプ(AT)コマンドの例示的なシーケンス図表現である。

【図5E】本開示の実施形態による、アプリケーションと通信モデムとの間のアプリケーションタイプ(AT)コマンドの例示的なシーケンス図表現である。

【図5F】本開示の実施形態による、全体的なネットワークアーキテクチャにおけるキャッシュレベルの例示的なブロック図表現である。

【図5G】本開示の実施形態による、システム全体にわたるアプリケーションタイプの自動検出のための方法の例示的な流れ図表現である。

【図5H】本開示の実施形態による、アプリケーションタイプの認識に基づいて、QoSプロファイルに関して、通信ネットワークと、さらにはモデムとを構成するアプリケーションサーバ(AS)の例示的なシーケンス図表現である。

【図5I】本開示の実施形態による、第5世代(5G)ネットワークアーキテクチャにおけるアプリケーションタイプ(AT)コマンドの例示的なシーケンス図表現である。

【図5J】本開示の実施形態による、第5世代(5G)ネットワークアーキテクチャにおける新しい非アクセス層(NAS)を使用するアプリケーションタイプ(AT)コマンドの例示的なシーケンス図表現である。

【図5K】本開示の実施形態による、第5世代(5G)ネットワークアーキテクチャにおけるハンドオーバ中/後の失われたユーザ機器のコンテキスト/アプリケーションタイプ喪失シナリオの間の新しい非アクセス層(NAS)を使用するアプリケーションタイプ(AT)コマンドの例示的なシーケンス図表現である。

【図6】本開示の実施形態による、本発明の実施形態が利用され得る例示的なコンピュータシステムを示す図である。

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

【0045】

以上のことは、本発明の以下のより詳細な説明からより明らかになるであろう。

【0046】

以下の説明において、説明の目的で、本開示の実施形態の完全な理解をもたらすために様々な特定の詳細が示される。しかし、本開示の実施形態がこれらの特定の詳細なしに実施される場合があることは明らかであろう。以降で説明されるいくつかの特徴は、それぞれ、互いに独立してまたはその他の特徴の任意の組合せとともに使用され得る。個々の特徴は、上で検討された問題のすべてに対処しない場合があり、または上で検討された問題の一部にのみ対処する可能性がある。上で検討された問題の一部は、本明細書において説明される特徴のいずれによっても完全に対処されない可能性がある。

【0047】

以降の説明は、例示的な実施形態を提供するに過ぎず、本開示の範囲、適用可能性、または構成を限定するように意図されていない。むしろ、例示的な実施形態の以降の説明は、例示的な実施形態を実装するための実施を可能にする説明を当業者に与える。示される本発明の精神および範囲を逸脱することなく、要素の機能および構成に様々な変更がなされる場合があることを理解されたい。

【0048】

本開示は、モノのインターネット(IoT)ネットワークにおいてサービス品質(QoS)を最適化するための手法を提供する。本対象の手法に従って、ネットワークリソースは、ネットワーク内の様々なユーザ機器(UE)に、それらのそれぞれのQoSプロファイルに基づいて割り当てられてよい。異なるUE上で実行される様々なアプリケーションが、分析されてよく、それらのアプリケーションのレイテンシへの敏感さのレベルに基づいて、ネットワークリソースが、それに応じてそれらのアプリケーションに割り振られてよい。一例において、キャッシュのサポートおよび連携された処理能力が、提供される場合がある。別の例において、アプリケーションおよび対応するUEが、ネットワークの全体的なQoSを向上させるために、ネットワークの特定の処理リソースを割り振られる場合がある。理解されるであろうように、本対象は、したがって、モノのインターネット(IoT)ネットワークにおけるサービス品質(QoS)の効率的で、レイテンシに敏感な、および信頼性の高い最適化を提供する場合がある。

【0049】

別の例において、本開示は、特定のアプリケーションのためのインテリジェントなデータ処理を実行してよい無線アクセスネットワーク内の追加のコンピュートエンティティをサポートするためのシステムおよび方法を提供する。さらに別の例において、本開示は、IoTアプリケーションカテゴリまたはタイプを認識するシステムおよび方法を提供し、そのとき、IoTアプリケーションカテゴリまたはタイプは、新しいQoSクラスを適切に割り振るためにIoTネットワークによって使用される。さらに別の例において、本開示は、一部のアプリケーションの優先度が相対的であるときに、カテゴリタイプの間で(たとえば、レイテンシに敏感でないタイプからレイテンシに敏感なタイプへ)優先度を変更するためのシグナリングのためのシステムおよび方法を提供する。さらに別の例において、本開示は、新しいアプリケーションカテゴリを定義された新しいQoSクラス識別子にマッピングすることができる、アプリケーションと非アクセス層(NAS)との間のモデムインターフェースを利用するシステムおよび方法を提供する。さらに別の例において、本開示は、IoTアプリケーション/データを、信頼性、レイテンシへの敏感さの観点でのその全体的なエンドユースケースの属性に基づいて扱うためのシステムおよび方法を提供する。さらに別の例において、本開示は、データストリーム、データのパケット、またはデバイスから発信される任意のデータがキャッシュを必要とするかどうか、キャッシュの局所性、それが処理の詳細の性質をローカルで処理することを必要とするかどうかなどのQoSパラメータを含めるためのシステムおよび方法を提供する。さらに別の例において、本開示は、拡張されたQoSテンプレートのQoSメカニズム、レイテンシに敏感でないアプリケーションのためのそのような新しいQoSテンプレートを解釈し、適用するメカニズムのためのシステムおよび方法を提供する。

【0050】

この態様およびその他の態様は、図1～図6に関連してさらに詳細に説明される。図が説明のために過ぎず、いかなる形であれ本対象の範囲を限定するものと解釈されるべきではないことは留意されてよい。さらに、図1～図3が併せて説明され、妥当な場合、同じ参照番号が使用されたことは留意されてよい。

【0051】

本開示の実施形態による、サービス品質(QoS)最適化システムのための例示的なネットワークアーキテクチャ100(ネットワークアーキテクチャ100とも呼ばれる)を示す図1を参照する。図1に描かれているように、複数のユーザ機器(UE)102-1、102-2、102-3、...、102-N(集合的にユーザ機器(UE)102と呼ばれる)は、ネットワーク106を介してアプリケーションサーバ104と通信してよい。

【0052】

一例において、UE 102は、モバイル電話、スマートフォン、仮想現実(VR)デバイス、拡張現実(AR)デバイス、ラップトップ、多目的コンピュータ、デスクトップ、携帯情報端末、タブレットコンピュータ、IoTセンサー、IoTデバイス、IoT家電、メインフレームコンピュータ、または任意のその他のコンピューティングデバイスなどの任意の電気、電子、電気機械、または機器、または上記デバイスの1つもしくは複数の組合せを含んでよいがそれらに限定されず、コンピューティングデバイスは、カメラなどの視覚補助デバイス、音声補助装置、マイクロフォン、キーボード、タッチパッド、タッチ対応スクリーン、電子ペンなどのユーザからの入力を受け取るための入力デバイス、任意の範囲の周波数の任意の音声信号または視覚信号を受信するための受信デバイス、および任意の範囲の周波数の任意の音声信号または視覚信号を送信するための送信デバイスを含むがそれらに限定されない1つまたは複数の内蔵または外付けアクセサリを含んでよい。UE 102は、上述のデバイスに限定されない可能性があり、様々なその他のデバイスが使用されてよいことは理解されるであろう。スマートコンピューティングデバイスは、データおよびその他のプライベートな/機密の情報を記憶するための適切なシステムのうちの1つであってよい。

【0053】

さらに、アプリケーションサーバ104は、任意のハードウェアベース、ソフトウェアベース、ネットワークベース、またはクラウドベースのサーバとして実装されてよい。別の例において、アプリケーションサーバ104は、アプリケーションサーバ(AS)またはIoTサーバであってよい。

【0054】

別の例において、アプリケーションサーバ104は、AMF(アクセスおよびモビリティ管理機能(Access and Mobility Management function))、SMF(セッション管理機能)、PCF(ポリシー制御機能)、UPF(ユーザプレーン機能)、DN(データネットワーク)などのネットワーク100内の複数のその他のコンポーネントと通信してよい。これらのコンポーネントは、図4に描かれ、後の説明で説明されている。さらに別の例において、そのようなコンポーネントは、アプリケーションサーバ104の一部であってよい。任意のその他の実装も、本対象の範囲に包含される。

【0055】

さらに別の例において、アプリケーションサーバ104は、システムオンチップ(SoC)システムであってよいがその種のものに限定されない。さらに別の例において、オンサイトデータキャプチャ、ストレージ、マッチング、処理、意思決定、および作動論理が、マイクロサービスアーキテクチャ(MSA)を使用してコーディングされてよいがそれに限定されない。複数のマイクロサービスが、移植性をサポートするために、コンテナ化されてよく、イベントベースであってよい。

【0056】

さらに別の例において、ネットワークアーキテクチャ100は、モノのインターネット(IoT)ネットワークにおけるサービス品質(QoS)の最適化に向けて近接処理(proximate processing)が獲得されてよいとき、アプリケーションサーバ104のすべての種類の変更に対応するためにモジュール式および柔軟である場合がある。アプリケーションサーバ104の構成の内容は、オンザフライで修正され得る。

【0057】

さらに別の例において、アプリケーションサーバ104は、遠隔監視される場合があり、アプリケーションサーバ104のデータ、アプリケーション、および物理的セキュリティが、完全に保証される場合がある。実施形態において、データが収集され、利用可能な洞察を抽出するために処理されるようにクラウドベースのデータレイクに預けられる場合がある。したがって、予知保全の態様が、実現され得る。別の例示的な実施形態において、アプリケーションサーバ104は、限定ではなく例示として、スタンドアロンサーバ、サーバブレード、サーバラック、サーバのバンク、サーバファーム、クラウドサービスまたはシステムの一部をサポートするハードウェア、ホームサーバ、仮想化されたサーバを実行するハードウェア、サーバとして機能するコードを実行する1つまたは複数のプロセッサ、本明細書において説明されるサーバサイドの機能を実行する1つまたは複数のマシン、上記のいずれかの少なくとも一部、それらの何らかの組合せの1つまたは複数を含むかまたは包含してよい。

【0058】

アプリケーションサーバ104は、分析エンジン(図1に示さず)を含んでよい。一例において、分析エンジンは、アプリケーションサーバ104の一部であってよい。別の例において、分析エンジンは、アプリケーションサーバ104と通信してよい。さらに別の例において、分析エンジンは、集中型サーバ上に実装されてよく、そのような集中型サーバは、アプリケーションサーバ104と通信してよい。分析エンジンの任意のその他の実装も、本対象の範囲に包含される可能性がある。

【0059】

UE 102は、複数のセンサー(図1に示さず)とさらに通信してよい。そのようなセンサーは、それぞれのUE 102と通信する場合があり、状態を連続的に監視する場合がある。これらのセンサー、UE 102、およびアプリケーションサーバ104は、互いに通信してよく、IoTネットワークの一部を形成してよい。

【0060】

ネットワーク106は、IoT通信ネットワークとして実装されてよい。ネットワーク106は、イントラネット、ローカルエリアネットワーク(LAN)、広域ネットワーク(WAN)、インターネットなどの異なるタイプのネットワークのうちの1つとして実装され得るワイヤレスネットワーク、有線ネットワーク、またはそれらの組合せであることが可能である。さらに、ネットワーク106は、専用ネットワークかまたは共有ネットワークかのどちらかのどちらかであることが可能である。共有ネットワークは、様々なプロトコル、たとえば、ハイパーテキスト転送プロトコル(HTTP)、伝送制御プロトコル/インターネットプロトコル(TCP/IP)、ワイヤレスアプリケーションプロトコル(WAP)などを使用することができる異なるタイプのネットワークの連合を表し得る。

【0061】

例示的な実施形態において、IoT通信ネットワーク106は、限定ではなく例として、1つまたは複数のメッセージ、パケット、信号、波、電圧または電流レベル、それらの何らかの組合せなどを送信するか、受信するか、転送するか、生成するか、バッファリングするか、記憶するか、ルーティングするか、スイッチングするか、処理するか、またはそれらの組合せなどを行う1つまたは複数のノードを有する1つまたは複数のネットワークの少なくとも一部を含んでよい。ネットワークは、限定ではなく例として、ワイヤレスネットワーク、有線ネットワーク、インターネット、イントラネット、公衆ネットワーク、プライベートネットワーク、パケット交換ネットワーク、回線交換ネットワーク、アドホックネットワーク、インフラストラクチャネットワーク、公衆交換電話網(PSTN)、ケーブルネットワーク、セルラネットワーク、衛星ネットワーク、光ファイバネットワーク、それらの何らかの組合せのうちの1つまたは複数を含んでよい。

【0062】

一例において、UE 102は、Android(商標)、iOS(商標)、Kai OS(商標)などを含むがそれらに限定されない任意のオペレーティングシステム上に存在する実行可能命令のセットを介してアプリケーションサーバ104と通信してよい。

【0063】

それぞれのUE 102のQoSプロファイルに基づいてネットワークリソースを割り当て、したがって、ネットワーク環境100のQoSを最適化するためのアプリケーションサーバ104の働きが、図2および図3に関連してさらに詳細に説明される。

【0064】

図2は、本開示の実施形態による、モノのインターネット(IoT)ネットワークにおいてサービス品質(QoS)を最適化するために提案されるシステムの例示的な表現を示す。一例において、システムは、図1で説明されたように、アプリケーションサーバ104として実装されてよい。

【0065】

図2に描かれるように、アプリケーションサーバ104は、1つまたは複数のプロセッサ202を含んでよい。1つまたは複数のプロセッサ202は、1つまたは複数のマイクロプロセッサ、マイクロコンピュータ、マイクロコントローラ、エッジもしくはフォグマイクロコントローラ、デジタル信号プロセッサ、中央演算処理装置、論理回路、および/または動作命令に基づいてデータを処理する任意のデバイスとして実装されてよい。能力の中でもとりわけ、1つまたは複数のプロセッサ202は、アプリケーションサーバ104のメモリ204に記憶されたコンピュータ可読命令をフェッチし、実行するように構成されてよい。メモリ204は、非一時的コンピュータ可読ストレージ媒体に1つまたは複数のコンピュータ可読命令またはルーチンを記憶するように構成されてよく、それらのコンピュータ可読命令またはルーチンは、ネットワークサービス上でデータパケットを作成または共有するためにフェッチされ、実行されてよい。メモリ204は、たとえば、RAMなどの揮発性メモリ、またはEPROM、フラッシュメモリなどの不揮発性メモリを含む任意の非一時的ストレージデバイスを含んでよい。

【0066】

実施形態において、アプリケーションサーバ104は、インターフェース206を含んでよい。インターフェース206は、様々なインターフェース、たとえば、I/Oデバイスと呼ばれるデータ入出力デバイス、ストレージデバイスなどのためのインターフェースを含んでよい。インターフェース206は、アプリケーションサーバ104の通信を容易にする場合がある。インターフェース206は、アプリケーションサーバ104の1つまたは複数のコンポーネントに通信経路を提供する場合もある。そのようなコンポーネントの例は、処理エンジン208およびデータベース210を含むがそれらに限定されない。

【0067】

処理ユニット/エンジン208は、処理エンジン208の1つまたは複数の機能を実施するために、ハードウェアとプログラミング(たとえば、プログラミング可能な命令)との組合せとして実装されてよい。本明細書において説明される例において、ハードウェアとプログラミングとのそのような組合せは、いくつかの異なる方法で実装される場合がある。たとえば、処理エンジン208のためのプログラミングは、非一時的機械可読ストレージ媒体に記憶されたプロセッサが実行可能な命令である場合があり、処理エンジン208のためのハードウェアは、そのような命令を実行するための処理リソース(たとえば、1つまたは複数のプロセッサ)を含む場合がある。この例において、機械可読ストレージ媒体は、処理リソースによって実行されるときに処理エンジン208を実施する命令を記憶してよい。そのような例において、アプリケーションサーバ104が、命令を記憶する機械可読ストレージ媒体と、命令を実行するための処理リソースとを含んでよく、または機械可読ストレージ媒体が、別れているが、アプリケーションサーバ104および処理リソースによりアクセス可能であってよい。その他の例において、処理エンジン208は、電子回路によって実装されてよい。

【0068】

処理エンジン208は、分析エンジン212およびその他のエンジン214を含んでよい。一例において、処理エンジン208は、エッジベースのマイクロサービスイベント処理に基づいてよいがその種のものに限定されない。

【0069】

この説明は、単一のUE 102の文脈で説明されるが、それが、明瞭にする目的のためにのみ行われることは留意されてよい。本対象の手法は、本対象の範囲を逸脱することなく、ネットワーク環境100内の複数のUE 102のネットワークにおいて実施されてよい。

【0070】

動作中、アプリケーション108は、UE 102上で実行されていてよい。一例において、アプリケーション108は、エンドユーザ要件に従ってソフトウェア論理を実行するアプリケーションタイプであってよい。実行中のアプリケーション108は、ネットワーク100からのいくつかのリソースを利用することを求められる場合がある。そのようなネットワークリソースの例は、処理リソースおよびメモリリソースを含んでよいがそれらに限定されない。そのようなアプリケーション108は、実行中に、UE 102のセンサーと通信してよい。それぞれのUE 102で実行されるアプリケーション108は、対応するUE 102に要求を生成させる場合がある。実施形態において、要求は、それから、アプリケーションサーバ104によって受信されてよい(図3のブロック302として描かれる)。そのような要求は、利用可能なネットワークリソースの一部を利用するためにアプリケーションサーバ104と通信するためにUE 102によって使用されてよい。

【0071】

別の例において、要求は、通信モデム110を通じてUE 102からアプリケーションサーバ104に伝達されてよい。通信モデム110は、任意のハードウェアベースまたはソフトウェアベースのコンピューティングデバイスとして実装されてよい。別の例において、通信モデム110は、UE 102の一部であってよい。さらに別の例において、通信モデム110は、第2世代(2G)/第3世代(3G)/ロングタームエボリューション(LTE)/狭帯域モノのインターネット(NB-IoT)/第5世代(5G)/第6世代(6G)、またはローカルエリアネットワーク(LAN)/広域ネットワーク(WAN)を介した任意のその他の通信ネットワークに基づくモデムであってよい。しかし、そのような例は説明のために過ぎず、要求が、本対象の範囲から逸脱することなく、任意の方法でUE 102からアプリケーションサーバ104に伝達されてよいことは留意されてよい。

【0072】

さらに続けて、UE 102から要求を受信すると、アプリケーションサーバ104は、UE 102とのプロトコルデータユニット(PDU)セッションを確立してよい。UE 102からの受信された要求は、UEパラメータのセットを含んでよい。一例において、UEパラメータのセットは、UE 102によって生成されるメタデータである場合がある。別の例において、UEパラメータのセットは、センサーデータ、アプリケーションデータ、またはそれらの組合せのうちの1つを含む場合がある。さらに別の例において、センサーデータは、対応するUE 102と通信してよい複数のセンサーのうちの1つから取得される場合がある。さらに別の例において、アプリケーションデータは、1つまたは複数の要因に基づいて、UE上で実行されるアプリケーション108から取得される場合がある。さらに別の例において、メタデータは、予め決められたフラグビット、またはアプリケーションを実行している間にUE 102のユーザによって設定されてよいいくつかの優先クラス識別子ビットを含む場合がある。そのような優先クラス識別子は、アプリケーション108自体によってオンザフライで設定される場合があり、またはアプリケーション108をUE 102にダウンロードするときに定数として設定される場合がある。理解されるであろうように、UEパラメータは、アプリケーション108がUE 102上で実行されている可能性がある方法と、前記アプリケーション108の実行によって必要とされるネットワークリソースとを示す場合がある。

【0073】

さらに続けて、UEパラメータが、それから、受信された要求から抽出されてよい(図3のステップ304として描かれる)。その後、抽出されたUEパラメータに基づいて、サービス品質(QoS)プロファイルが、対応する要求に割り振られてよい(図3のステップ306として描かれる)。一例において、分析エンジン212は、予め定義されたマッピング基準に基づいて、対応する要求にQoSプロファイルを割り振る場合がある。別の例において、分析エンジン212は、対応するUEからの対応する要求を、レイテンシに敏感な要求およびレイテンシに敏感でない要求のうちの1つであるようにカテゴリ分けする場合がある。

【0074】

別の例において、対応するUEからの受信された要求のQoSプロファイルをレイテンシに敏感またはレイテンシに敏感でないとしてカテゴリ分けすると、分析エンジン212は、前記アプリケーションのレイテンシへの敏感でなさのグレードに基づいて、QoSプロファイルを複数のカテゴリにさらに分類する場合がある。

【0075】

さらに続けて、割り振られたQoSプロファイルに基づいて、複数のネットワークリソースのうちの少なくとも1つが、それから、対応する要求を生成する対応するUEに割り当てられてよい(図3のステップ308として描かれる)。一例において、対応する要求を生成する対応するUEに割り当てられる複数のネットワークリソースは、処理リソースの割り当て、メモリリソースの割り当て、実行の優先レベルの割り振り、またはそれらの組合せのうちの1つを含んでよい。別の例において、分析エンジン212は、対応する要求を生成する対応するUEに、ネットワーク内の複数のエンティティのうちの1つの複数の処理リソースのうちの1つを利用させる場合がある。さらに別の例において、分析エンジン212は、対応する要求を生成する対応するUEに、ネットワーク内の複数のエンティティのうちの1つの複数のキャッシュメモリのうちの1つを利用させる場合がある。さらに別の例において、分析エンジン212は、特定の期間、対応する要求を実行する際に遅延を引き起こす場合がある。

【0076】

さらに別の例において、分析エンジン212は、割り当てられたメモリリソースに基づいてキャッシュメカニズムを割り当てる場合がある。さらに別の例において、QoSプロファイルを決定し、ネットワークリソースを割り当てると、分析エンジン212は、新しい特定されたQoSプロファイルを構成およびマッピングするために通信モデム110およびネットワーク106にアプリケーションタイプを認識させるために、アプリケーション108にアプリケーションタイプ(AT)コマンドを使用させる場合がある。ATコマンドインターフェースは、特定および適用すべき正しいタイプのQoSプロファイルをネットワークに知らせるために、アプリケーションタイプ、センサータイプ、および必要なシグナリング識別子を特定してよい。

【0077】

さらに別の例において、分析エンジン212は、可能なキャッシュおよび適切な計算アルゴリズムの実行を含むQoSプロファイルの必要な属性を実行するために、IoT通信ネットワーク106内のアーキテクチャのエンティティに、QoSプロファイルを読ませ、解釈させる場合がある。IoT通信ネットワーク106などのIoT無線アクセスネットワーク内のそのような追加のコンピュートエンティティは、特定のアプリケーションのためのインテリジェントなデータ処理を実行する場合がある。

【0078】

さらに別の例において、異なるレベルのキャッシュおよび計算エンティティが、適切な無線アクセスネットワーク(RAN)シグナリングメカニズムを介して、インテリジェントなデータ処理および構成を適宜実施するためのレイテンシへの敏感でないアプリケーションタイプのために定義されてよい。

【0079】

さらに別の例において、ネットワークアーキテクチャ100のシステムおよびフローが、以下の方法、すなわち、ATコマンドに基づくアプリケーショントリガ、ネットワークが優先度の変更をインテリジェントに特定すること、およびアプリケーションサーバ104がUE 102かまたはIoT RANエンティティ(図1～図2に示さず)かのどちらかを特定し、適切にシグナリングすることなどの方法のいずれかに基づいてレイテンシに敏感であるとレイテンシに敏感でないとの間で優先度を動的に変更するために定義されてよい。

【0080】

さらに別の例において、アプリケーション優先度変更タイプが、IoT通信ネットワーク106によってインテリジェントに、ひいてはQoSプロファイルを構成するために検出されてよい。さらに別の例において、分析エンジン212は、アプリケーションサーバ104に、アプリケーションタイプの認識に基づいて、IoT通信ネットワーク106および通信モデム110において新しいQoSプロファイルを構成させてよい。

【0081】

さらに別の例において、トラフィックの特徴付けが、予め定義された周期で、トラフィックデータのバイトのセットが送信され、その後は次のタイマーが切れるまで何も送信されないようなものであるUE 102などのセンサーベースのIoTデバイスに関する。そのような場合、IoT通信ネットワーク106は、RRC非アクティブ状態を定義させないことを決定してよく、リソースを解放し、その他の必要とされるデバイスのためにそれらのリソースを再利用してよい。

【0082】

上記のアプリケーションタイプに対応するために、アプリケーションがレイテンシに敏感でないかどうか、GSMの進化のための高速化されたデータレート(EDGE)および/または無線アクセスノードにおけるキャッシュのサポートおよび/または連携された処理能力を必要とするかどうかを特定するのに役立つ場合がある新しいQoSプロファイルが実装されてよい。ネットワークアーキテクチャ100は、特定のアプリケーションのためのインテリジェントなデータ処理を実行してよいRAN内の追加のコンピュートエンティティをサポートしてよい。

【0083】

例において、ネットワークアーキテクチャ100は、IoTアプリケーションカテゴリまたはタイプを認識してよく、そのとき、IoTアプリケーションカテゴリまたはタイプは、新しいQoSクラスを適切に割り振るためにIoT通信ネットワーク106によって使用されてよい。これは、ネットワークのリソースを最適化するために必要な場合があり、新しいQoSカテゴリは、そのようなアプリケーションタイプを扱ってよい。さらに、シグナリングは、一部のアプリケーションの優先度が相対的であるときに、カテゴリタイプの間で(たとえば、レイテンシに敏感でないタイプからレイテンシに敏感なタイプへ)優先度を変更してよい。特に、アプリケーション108と非アクセス層(NAS)との間の新しいモデムインターフェースが、新しいアプリケーションカテゴリを定義された新しいQoSクラス識別子にマッピングしてよい。そのようなIoTアプリケーションカテゴリは、さらなるサブカテゴリをサポートしてもよい。

【0084】

別の例において、拡張されたQoSテンプレートのQoSメカニズムが、提供されてよく、メカニズムは、レイテンシに敏感でないアプリケーションのための新しいQoSテンプレートを解釈し、適用するために使用されてよい。実施形態において、サーバ104は、アプリケーションの属性を定義するのに役立つQoSテンプレートまたはプロファイルを定義してよい。

【0085】

さらに別の例において、レイテンシに敏感でないアプリケーションが、
グレード1 -- 24時間までまたはそれを超えて遅延を許容する。
グレード2 -- 数時間、ただし、24時間未満の遅延を許容する。
グレード3 -- 数10分単位の遅延を許容する。
グレード4 -- 分単位の、ただし、10分未満の遅延を許容する。
のような、異なるユースケースのシナリオに対応するために4つの異なるサブカテゴリに分類され得る。

【0086】

さらに別の例において、ネットワークリソースを割り当てることは、キャッシュの必要性、キャッシュの局所性、処理の要件、処理の性質、処理のインジケータ、パケットの連結、データの平均化、着信データの閾値設定、および指定されたデータ集約メカニズムの適用を決定することをさらに含む場合がある。しかし、そのような例が説明のために過ぎず、いかなる形であれ本対象の範囲を限定するものと解釈されるべきではないことは留意されてよい。任意のその他のネットワークリソース割り当て技術も、本対象の範囲に包含される。

【0087】

これらおよび他の例示的な態様および実施形態は、図4～図5において説明された。

【0088】

図4は、本開示の実施形態による、QoS設定のための計算レベルの例示的なシーケンス図表現を示す。

【0089】

RAN(402)(CU-UP)またはUPF(410)にキャッシュすることを示し、ストレージ空間、データ処理/パッケージング、UPF(410)に基づくストレージクラス、関連するタイマーなどのキャッシュに関連するパラメータを示すための登録 -> PDU確立(レイテンシに敏感でないタイプ) -> SMF(406)。

【0090】

ステップ(414-1)において、アプリケーション(108)は、アプリケーションタイプ(レイテンシに敏感である)をモデム(110)に送信してよい。ステップ(414-2)において、モデム(110)は、PDU確立要求をRAN(402)に送信してよい。ステップ(414-3)において、モデム(110)は、無線リソース制御(RRC)接続要求をRAN(402)に送信してよい。ステップ(414-4)において、RAN(402)は、RRC接続肯定応答をモデム(110)に送り返してよい。ステップ(414-5)において、AMF(404)は、SMF選択を実行してよい。ステップ(414-6)において、AMF(404)は、SMコンテキスト要求を作成するためのNsmf(すなわち、SMFによって提示されたサービスベースのインターフェース) PDUセッションをSMF(406)に送信してよい。

【0091】

ステップ(414-7)において、SMF(406)は、SM応答を作成するためのNsmf PDUセッションをAMF(404)に送り返してよい。ステップ(414-8)において、AMF(404)は、セットコンテキスト(set context)要求をSMF(406)に送信してよい。ステップ(414-9)において、SMF(406)は、セットコンテキストの確認をAMF(404)に送信してよい。

【0092】

ステップ(414-10)において、SMF(406)は、ポリシー制御機能(PCF)を選択してよく、ステップ(414-11)において、SMF(406)は、確立原因を含むSM開始ポリシー関連付け(SM initiated policy association)を修正してよく、ステップ(414-12)において、SMF(406)は、UPFを選択してよい。ステップ(414-13)において、SMF(406)は、N1 N2メッセージをAMF(404)に転送してよい。ステップ(414-14)において、SMF(406)は、キャッシュに関する追加のパラメータのIEを持つPFCPメッセージをUPF(410)に送信してよい。ステップ(414-15)において、AMF(404)は、新しいQFIを持つPDUセッション要求をRAN(402)に送信してよい。ステップ(414-16)において、RAN(402)は、PDU確立肯定応答をモデム(110)に送信してよい。

【0093】

図5A～図5Eは、アプリケーションと通信モデムとの間のアプリケーションタイプ(AT)コマンドの例示的なシーケンス図表現を示す。図1において説明されたように、アプリケーションは、108として実装されてよく、通信モデムは、通信モデム110として実装されてよい。図5Aのシーケンス図において、UE(102)およびモデム(110)は、ステップ(502-1)から(502-11)を実行してよい。図5Bのシーケンス図において、UE(102)およびモデム(110)は、ステップ(504-1)から(504-14)を実行してよい。図5Cのシーケンス図において、UE(102)およびモデム(110)は、ステップ(506-1)から(506-3)を実行してよい。図5Dのシーケンス図において、UE(102)およびモデム(110)は、ステップ(508-1)から(508-4)を実行してよい。図5Eのシーケンス図において、UE(102)およびモデム(110)は、ステップ(510-1)から(510-2)を実行してよい。

【0094】

モデムがセンサーデータを受信すると、それが、制御チャネルまたはデータチャネルおよびセンサーの能力上で送信され、それが、UE能力メッセージ、アプリケーションタイプ、アプリケーションから受信されるときのアプリケーションタイプに関する上記データ上で送信され、モデムは、以下に見られるようにService Request Establishment_Cause IEを介してPDU確立/変更/登録手順中にネットワークに送信するためにそれを使用してよいことに留意されたい。
Establishment Cause ::= ENUMERATED {emergency, high Priority Access, mt-Access, mo-Signalling, mo-Data, mo-Voice Call, mo-Video Call, mo-SMS, mps-Priority Access, mcs-Priority Access, IoT- Latency Sens / IoT-Latency Insen, IoT-Data Reliability, spare4, spare3, spare2, spare1}

【0095】

ネットワークが上記のEstablishment Causeを受信すると、RANは、それをAMFに転送し、それからSMFに転送し、SMFを介してPCFに転送する。PCFは、それに応じて、既存のメカニズムを使用して最終的にQCI/5QIおよびその他のパラメータを設定する。同様のフローは、5G NRだけに限定されず、4Gまたはその他のテクノロジーにも当てはまる。5G NRは、本質的に例としてここでは取りあげられるに過ぎない。

【0096】

図5Fは、本開示の実施形態による、全体的なネットワークアーキテクチャにおけるキャッシュレベルの例示的なブロック図表現を示す。

【0097】

前述のように、割り振られたQoSプロファイルに基づいて、複数のネットワークリソースのうちの少なくとも1つが、対応する要求を生成する対応するUEに割り当てられてよい。一例において、レイテンシへの敏感さのレベルに基づいて、異なるキャッシングレベルが定義されてよい。図5Fは、ネットワークリソースおよび計算能力を節約するために、レイテンシに敏感でないユースケースにおいてコンテンツをキャッシュする異なる可能な方法のうちの1つを描く。全体的なネットワークアーキテクチャにおけるキャッシュレベルは、UE(102)、アクセスネットワーク(512)、コアネットワーク(514)、およびデータネットワーク(DN)/インターネット(412)を含んでよい。

【0098】

さらに描かれたように、C1～C6(すなわち、UE(102)、無線アクセスネットワーク(RAN)(402)、ユーザプレーン機能(UPF)(410)、データネットワーク(DN)(412)、アクセスおよびモビリティ管理機能(AMF)(404)、セッション管理機能(SMF)(406)、アプリケーション機能(AF)(516)、およびポリシー制御機能(PCF)(408))は、レイテンシに敏感でないユースケースまたはサービスのために確認または構成されたUE(102)またはIoTデバイスから獲得されたデータに関して行われ得るキャッシュの異なる可能性の場所である場合がある。

【0099】

キャッシュのより好ましい場所は、集中ユニットユーザプレーン(CU-UP: Centralized Unit User Plane)のRAN(402)内であってよく、それは、(それを構成するためのマスターとして)SMF(406)を介して伝達される。UPF(410)またはCU-UPがキャッシュおよび計算を実行するためにSMF(406)が通信するためのメカニズムは、PDU確立手順の間にQoSプロファイルを設定しながら、下で定義されるフローの一部として伝達される。QoSテンプレートが適用されると、SMF(406)エンティティは、そのシグナリングの一部として、下に見られるように、追加のパラメータと一緒にキャッシュの場所に追加の情報を提供しなければならない。フローの一部として、(データの完全性を含む)コンテンツのキャッシュに関して、または5QI値に基づいてデフォルトの構成を設定させるために、SMF(406)によって、以下のようなパラメータが運ばれる場合がある。
メモリフットプリント -- これは、UPFまたはCU-UPがUEまたはデバイスのクラスごとにコンテンツのキャッシュのためのメモリを割り当てるのに役立つ。
コンテンツがキャッシュされる時間 -- これは、コンテンツがどれだけ長くキャッシュされる必要があるかを示すためのタイマーである。
コンテンツのキャッシュとは別に、以下の異なるレベルのキャッシュ、メッセージ -- L0 -- 通常のデータまたはメッセージのみがキャッシュされることを意味する、アラート/警告 -- L1 -- アラート/警告さえもキャッシュされる、構成 -- L2 -- 構成もキャッシュされる、などが見るために定義される。

【0100】

上記の新しい提案されるスキーマまたは構造は、以下に示されるようなものであってよい。
Caching Parameters IE:: ={
Caching Location:: = ENUM{C1, C2, C3, C4… },
Caching Level:: = ENUM{L0, L1, L2..},
Memroy:: STRING{XKB, YMB…},
Timer:: = STRING{xh:ym:zs},
Max Attempts:: = N}}

【0101】

すべての上述の構成は、PCFがQoSプロファイルを構成した後に、SMF(406)によってキャッシュエンティティに渡されてよい。メッセージが緊急サーバ(emergency server)にいつフラッシュされるべきかを示すタイマーとは別に、メッセージは、タイマーが切れる前に割り当てられたメモリがいっぱいになるときに転送されることが可能であり、またはコンテンツを転送しようとする試行の回数がその上限に達するとフラッシュされることが可能であることも留意されてよい。さらに、それに関する上限が、上記の構造の一部として伝達される。

【0102】

キャッシュと同様に、計算レベルも、QoS設定の通信部分である場合がある。計算は、CU-UP、UPF、あるいはすべてのEDGEの計算または任意のアルゴリズムもしくは数学的統計モデルが実施されてよい、アーキテクチャに導入されるまったく新しいエンティティのような異なるエンティティで発生する場合がある。たとえば、農業IoTのシナリオのために収集される必要があるセンサーデータは、EDGEの計算のために、または指定されたエンティティで構成され得る。たとえば、そのようなIoTシステムにおいて正しいQoSプロファイルを構成するために、システムを横断してアプリケーションタイプを伝達するための3つの異なる方法が存在する場合がある。一例において、これは、ATコマンドを使用して実施されてよい。そのような場合、アプリケーションおよびモデムは、QoSプロファイルをやりとりするためにATインターフェースを介してインタラクションしてよい。別の例において、そのような実施は、アプリケーションサーバを使用して行われてよい。そのような場合、アプリケーションサーバは、QoSプロファイルを構成してよい。さらに別の例において、そのような実施は、自動的に行われてよい。

【0103】

図5Gは、本開示の実施形態による、システム全体にわたるアプリケーションタイプの自動検出のための方法(500)の例示的な流れ図表現を示す。

【0104】

ブロック(518-1)において、ネットワークがPDUセッションを確立する間にデフォルトQoSを最初に設定するとき、RANレベルのネットワークは、トラフィックパターンのデータ分析を収集し続ける。方法は、QoSプロファイルのレイテンシの敏感さを判断する。そうである場合、ブロック(518-3)において、ネットワークは、5QIを「Y」として設定し、それを、関係するすべてのエンティティ -- PCF、AMF、SMF、RAN、およびUE -- に伝達する。そうでない場合、ステップ(518-2)において、ネットワークは、5QIを「X」として設定し、それを、関係するすべてのエンティティ -- PCF、AMF、SMF、RAN、およびUE -- に伝達する。

【0105】

RIC(無線インテリジェントコントローラ(Radio Intelligent Controller))の一部か、またはCU-UPもしくはDU-UPの一部かのどちらかで、データ収集およびトラフィックパターン分析が発生することが期待される。トラフィックパターンが分析されると、3節において(ATコマンドの定義の後に)定義される下のフローを使用することが、原因に関してAMF-SMF-PCFに共有するために使用され、それによって、正しいQCIが設定される。上記の手順がQoSプロファイルの設定を希望どおりに改善するまで、最初は、既存の手順によるデフォルトのQCIが、定義するために使用される。

【0106】

アプリケーションサーバ(104)の構成を使用するシステムを横断するアプリケーションタイプの伝達が、図5Hにおいて説明される可能性がある。図5Hに示されるように、ステップ(520-1)において、UE(102)のアタッチ手順/PDN確立手順が完了し、デフォルトQoSが割り振られる。ステップ(520-2)において、アプリケーションサーバ(104)は、ネットワーク(106)とのアプリケーションレベル構成{IMEI、QCI、5QI、Param1..N}を実行してよい。ステップ(520-3)において、ネットワーク(106)は、UE(102)とのアプリケーションレベル構成{QCI、5QI、Param1..N}を実行してよい。ステップ(520-4)において、UE(102)は、新たに設定されたQoSプロファイルを使用し、NWも使用する。また、したがって、設定されたレベル(C1 ... C6)に従ってキャッシュを行う。

【0107】

ATコマンドインターフェースを使用するシステムを横断するアプリケーションタイプの伝達は、IoTデバイス(102)のアプリケーション(108)が、アプリケーションタイプと、さらには、センサーデータおよびその能力とに関してモデム(110)に伝達してよい別の方法である場合がある。これらのATコマンドを使用して、モデム(110)は、センサーの能力と、センサーデータと、さらには、アプリケーションタイプとを認識してよい。また、アプリケーションによる必要に応じてネットワークによって送信される任意の構成に関して、同様のATインターフェースが、送信するために必要とされる場合がある。以下は、
AT%SENSORCMD
AT%SENSORDREQ
AT%SENSOREV
AT%SENSORCIND
AT%APPTYPE
AT%APPIND
AT%SENSORCMD
などの、ATインターフェース/ポートを介してモデムとアプリケーションとの間でやりとりされるために定義されたATコマンドのセットである。

【0108】

上記コマンドに関する可能な応答が、以下のTable 1(表1)に与えられる。

【0109】

【表1】

【0110】

説明: SENSORデータ/能力の受信を管理するためのATコマンド。電源投入時または新規セッションの確立中に、アプリケーションによってモデムに送信される。

【0111】

定義された値: センサーデバイスのセンサーデータ/能力情報を共有するため。

【0112】

説明: このコマンドは、最初の電源投入時に、そのときに利用可能なその能力およびすべてのセンサーデータと一緒にアプリケーションによって送信される。

【0113】

定義された値:
<cmd>:
"SENSOR_CAP" -- デバイスの能力情報を共有する
<Params>:
<Sensor_Capability> :: { <Sensor_Type> = ENUM{FUEL, SOIL-PH, SOIL-MOISTURE, ACC, GYRO .....} }
<cmd>:
"SENSOR_DATA" -- デバイスのセンサーデータを要求する
<Params>:
<Sensor_Data> :: { { <Sensor_Data> = ENUM{FUEL, SOIL-PH, SOIL-MOISTURE, ACC, GYRO .....} , {<Sesndor_Data> = Array[][]}}
AT%SENSORREQ

【0114】

上記コマンドに関する可能な応答が、以下のTable 2(表2)に与えられる。

【0115】

【表2】

【0116】

説明: SENSORデータ/能力を要求するためのATコマンド。REQUESTは、モデムからアプリケーションに送信される。

【0117】

定義された値: センサーデバイスのセンサーデータ/能力情報を取得する。

【0118】

説明: このコマンドは、センサーデータおよびセンサーデバイスの能力を取得するためにモデムによって使用される。これは、特定のセッションをアクティブ化する前、または最初のアタッチ/TAUなどの間にモデムによって取得される。

【0119】

定義された値:
<cmd>:
"REQUEST_CAP" -- デバイスの能力情報を要求する
<ResponseType>:
応答は<Sensor_Capability> :: { <Sensor_Type> = ENUM{FUEL, SOIL-PH, SOIL-MOISTURE, ACC, GYRO .....} }となる
<cmd>:
"REQUEST_SENSORDATA" -- デバイスのセンサーデータを要求する
<ResponseType>:
応答は<Sensor_Data> :: { { <Sensor_Type> = ENUM{FUEL, SOIL-PH, SOIL-MOISTURE, ACC, GYRO .....} , {<Sesndor_Data> = Array[][]}}となる
AT%SENSOREV

【0120】

上記コマンドに関する可能な応答が、以下のTable 3(表3)に与えられる。

【0121】

【表3】

【0122】

説明: この一方的コマンドは、ホストに、そのサービスに影響を与えるセンサーデータの変化があることを示す。そのとき、モデムは、AT%SENSORDREQを使用して追加のデータを問い合わせる。

【0123】

定義された値
<cmd>: 数値パラメータ
1 -- 一方的なセンサーデータのインジケーションを有効にする
<event1>: 数値パラメータ
0 -- センサーの能力の変化のインジケーション
1 -- センサーデータの変化のインジケーション
2 -- センサータイプ利用不可能
3 -- センサータイプ利用可能
3 -99 -- 予約済み
4 <event2>: 文字列
0 -- event1が4以外であるときに送信される。
AT%SENSORCIND

【0124】

上記コマンドに関する可能な応答が、以下のTable 4(表4)に与えられる。

【0125】

【表4】

【0126】

説明: アプリケーションに関連するアプリケーションサーバまたはネットワークによって送信されるときに、構成情報をモデムによってアプリケーションに共有するためのATコマンド。

【0127】

定義された値: センサーデバイスのセンサー構成情報を取得する。

【0128】

説明: このコマンドは、センサー構成データを共有するためにモデムによって使用される

【0129】

定義された値:
<cmd>:
"CONFIG_IND" -- センサーデバイスに関するアプリケーションレベルの構成の変化を示し、param1.. Nは、ネットワークまたはアプリケーションサーバによって定義された構成パラメータである
<ResponseType>:
OK/ERROR
AT%APPTYPE

【0130】

上記コマンドに関する可能な応答が、以下のTable 5(表5)に与えられる。

【0131】

【表5】

【0132】

説明: アプリケーションによって送信されるとき、アプリケーションタイプをその属性と一緒にモデムに共有するためのATコマンド。

【0133】

定義された値: モデムがアプリケーションによるアプリケーションタイプ情報を取得する。

【0134】

説明: このコマンドは、モデムがアプリケーションタイプを知るようにするためにアプリケーションによって使用される。

【0135】

定義された値:
<cmd>:
"APP_TYPE" -- IoTデバイスのアプリケーションレベルの構成を示し、param1.. Nは、ネットワークまたはアプリケーションサーバによって定義された構成パラメータである
Param 1...Nは、以下のようなタイプまたは属性を示す --
レイテンシに敏感である
レイテンシに敏感でない
バースト的トラフィック
ランダムウェイクアップ
高い即座のTPが必要
保証された送達
その他
<ResponseType>:
OK/ERROR
AT%APPIND

【0136】

上記コマンドに関する可能な応答が、以下のTable 6(表6)に与えられる。

【0137】

【表6】

【0138】

説明: アプリケーションに関連するアプリケーションサーバまたはネットワークによって送信されるときに、構成情報をモデムによってアプリケーションに共有するためのATコマンド。

【0139】

定義された値: IoTデバイスのアプリケーションサイドの構成情報を取得する。

【0140】

説明: このコマンドは、アプリケーション構成データを共有するためにモデムによって使用される。

【0141】

定義された値:
<cmd>:
"APP_Config" -- センサーデバイスに関するアプリケーションレベルの構成の変化を示し、param1.. Nは、ネットワークまたはアプリケーションサーバ(104)によって定義された構成パラメータである。
Param --
レイテンシに敏感である
レイテンシに敏感でない
バースト的トラフィック
ランダムウェイクアップ
高い即座のTPが必要
保証された送達、その他
<ResponseType>:
OK/ERROR

【0142】

図5Iは、本開示の実施形態による、第5世代(5G)ネットワークアーキテクチャにおけるアプリケーションタイプ(AT)コマンドの例示的なシーケンス図表現を示す。

【0143】

ステップ(522-1)において、UEが、ネットワークに登録されてよい。ステップ(522-2)において、アプリケーション(108)は、アプリケーションタイプ(レイテンシに敏感である)をモデム(110)に送信してよい。ステップ(522-3)において、モデム(110)は、PDU確立要求をRAN(402)に送信してよい。ステップ(522-4)において、モデム(110)は、無線リソース制御(RRC)接続要求をRAN(402)に送信してよい。ステップ(522-5)において、RAN(402)は、RRC接続肯定応答をモデム(110)に送り返してよい。ステップ(522-6)において、AMF(404)は、SMF選択を実行してよい。ステップ(522-7)において、AMF(404)は、SMコンテキスト要求を作成するためのNsmf(すなわち、SMFによって提示されたサービスベースのインターフェース) PDUセッションをSMF(406)に送信してよい。

【0144】

ステップ(522-8)において、SMF(406)は、SM応答を作成するためのNsmf PDUセッションをAMF(404)に送り返してよい。

【0145】

ステップ(522-9)において、SMF(406)は、ポリシー制御機能(PCF)を選択してよく、ステップ(522-10)において、SMF(406)は、確立原因を含むSM開始ポリシー関連付けを修正してよく、ステップ(522-11)において、SMF(406)は、UPFを選択してよい。ステップ(522-12)において、SMF(406)は、N1 N2メッセージをAMF(404)に転送してよい。ステップ(522-13)において、AMF(404)は、新しいQFIを持つPDUセッション要求をRAN(402)に送信してよい。ステップ(522-14)において、RAN(402)は、PDU確立肯定応答をモデム(110)に送信してよい。ステップ(522-15)において、モデム(110)は、AT% APPCINDをアプリケーション(108)に送信してよい。ステップ(522-16)において、メッセージが、モデム(110)とDN(412)との間で転送されてよい。

【0146】

図5Jは、本開示の実施形態による、第5世代(5G)ネットワークアーキテクチャにおける新しい非アクセス層(NAS)を使用するアプリケーションタイプ(AT)コマンドの例示的なシーケンス図表現を示す。

【0147】

ステップ(524-1)において、UE(102)が、ネットワークに登録されてよい。ステップ(524-2)において、アプリケーション(108)は、アプリケーションタイプ(レイテンシに敏感である)をモデム(110)に送信してよい。ステップ(524-3)において、モデム(110)は、PDU確立要求をRAN(402)に送信してよい。ステップ(524-4)において、モデム(110)は、無線リソース制御(RRC)接続要求をRAN(402)に送信してよい。ステップ(524-5)において、RAN(402)は、RRC接続肯定応答をモデム(110)に送り返してよい。ステップ(524-6)において、AMF(404)は、SMF選択を実行してよい。ステップ(524-7)において、AMF(404)は、SMコンテキスト要求を作成するためのNsmf(すなわち、SMFによって提示されたサービスベースのインターフェース) PDUセッションをSMF(406)に送信してよい。

【0148】

ステップ(524-8)において、SMF(406)は、SM応答を作成するためのNsmf PDUセッションをAMF(404)に送り返してよい。ステップ(524-9)において、AMF(404)は、セットコンテキスト要求をSMF(406)に送信してよい。ステップ(524-10)において、SMF(406)は、セットコンテキストの確認をAMF(404)に送信してよい。ステップ(524-11)において、SMF(406)は、ポリシー制御機能(PCF)を選択してよく、ステップ(524-12)において、SMF(406)は、確立原因を含むSM開始ポリシー関連付けを修正してよく、ステップ(524-13)において、SMF(406)は、UPFを選択してよい。ステップ(524-14)において、SMF(406)は、N1 N2メッセージをAMF(404)に転送してよい。ステップ(524-15)において、AMF(404)は、新しいQFIを持つPDUセッション要求をRAN(402)に送信してよい。ステップ(524-16)において、RAN(402)は、PDU確立肯定応答をモデム(110)に送信してよい。ステップ(524-17)において、モデム(110)は、AT% APPCINDをアプリケーション(108)に送信してよい。ステップ(524-18)において、メッセージが、モデム(110)とDN(412)との間で転送されてよい。

【0149】

図5Kは、本開示の実施形態による、第5世代(5G)ネットワークアーキテクチャにおけるハンドオーバ中/後の失われたユーザ機器のコンテキスト/アプリケーションタイプ喪失シナリオの間の新しい非アクセス層(NAS)を使用するアプリケーションタイプ(AT)コマンドの例示的なシーケンス図表現を示す。

【0150】

ステップ(526-1)において、UE(102)が登録されてよく、ハンドオーバが実行される。ステップ(526-2)において、PCFは、UE(102)からコンテキストを取得するためにSMF(406)を開始してよい。ステップ(526-3～526-11)において、UEからのコンテキストが取得されてよい。

【0151】

ステップ(526-12)において、SMF(406)は、確立原因を含むSM開始ポリシー関連付けを修正してよく、ステップ(526-13)において、SMF(406)は、UPFを選択してよい。ステップ(526-14)において、SMF(406)は、N1 N2メッセージをAMF(404)に転送してよい。ステップ(526-15)において、AMF(404)は、新しいQFIを持つPDUセッション要求をRAN(402)に送信してよい。ステップ(526-16)において、RAN(402)は、PDU確立肯定応答をモデム(110)に送信してよい。ステップ(526-17)において、モデム(110)は、AT% APPCINDをアプリケーション(108)に送信してよい。ステップ(526-18)において、メッセージが、モデム(110)とDN(412)との間で転送されてよい。

【0152】

別の実施形態において、リソース制御がセンサータイプの認識によってどのように達成され得るかが、以下に説明される可能性がある。
AS(アクセス層)のRRC(無線リソース制御) -- モデムスタックの一部が、リソースおよびモビリティ管理に大きな役割を果たす。RRC手順の一部 -- RRCは、以下の3つの主な状態 -- RRC_IDLE、RRC_CONNECTED、RRC_INACTIVE -- を保持する。
RRC_IDLE: RRC接続が解放される
RRC_CONNECTION: アクティブなセッションが進行している -- データ/シグナリング
RRC_INACTIVE: アクティブなデータ転送が済んだが、さらなるデータ転送を見込んで接続が引き続き維持される非アクティブな期間。

【0153】

しかし、アプリケーションが決まった量のデータのみを送信する必要があり、後で送信されるものがそれ以上ない特定のIoTのユースケースにおいて、ネットワークは、接続を直ちに解放することができ、デバイスをRRC_INACTIVE状態に維持することができず、それによって、ネットワークリソースを解放する。

【0154】

これを起こすために、UE(102)は、既存のメカニズムを使用するネットワークがデバイスにRRC_Inactive_Timerをゼロとして示し、その結果、RRC接続が直ちに解放されるように、ネットワーク(RAN)にこの特定の情報を送信する必要がある場合がある。上記の情報は、以下に見られるように、能力情報IEのRANの部分にUEによって渡される --
<RRC非アクティブ状態インジケーション>

【0155】

新しいフィールドUE-Sensor-Capabilityが、以下のように、UE Capability Information-NBオブジェクトに追加されてよい。
UE Capability Information-NB :: = SEQUENCE {
rrc- Transaction Identifier RRC-Transaction Identifier,
critical Extensions CHOICE{
ue Capability Information- r13 UECapabilityInformation-NB-r13-IEs,
critical Extensions Future SEQUENCE {
UE-Sensor-Capability-NB SEQUENCE {
UE Mobility Sensor,
ue Frequency Support,
ue Sensor Type,
ue Inactive State Ind
}
}
}
}

【0156】

センサーの能力が、ネットワークが様々な効率のユースケースのためにそれに対して使用するのを支援するために、UE-Sensor-capability_NBシーケンスに追加される可能性がある。この実施形態において、センサーの助けを借りて動きを感知するNB-IoTデバイスの能力が、-- UE-Sensor-Capability-NBシーケンスの下でネットワークに -- 示される。本提案において、これは、ブール値フラグue Mobility Sensorパラメータによって表される。

【0157】

さらに別の実施形態において、UE-Sensor-capability NBは、センサータイプ、たとえば、加速度計、またはジャイロスコープ、またはGPS、または任意のそのようなセンサーも含むことができ、一実施形態において、測定レポートが、そのようなセンサーからの読み取り値も含むことができる。これは、測定レポート自体を介したセンサーデータの送信に役立つ。そして、ネットワークは、事前の知識に基づいて、またはAPN/送信先アドレスのインジケーションを通じて、適切な送信先サーバにデータをルーティングする。これは、早期送信(early transmission)メカニズムを実現するのに役立ち、センサーデバイスにデータパスを提供する。ネットワークは、測定レポートの周期をスケジューリングすることができ、したがって、デバイスが送信することができる情報の量を制限することができる。

【0158】

さらに別の実施形態において、UEの能力は、デバイスによってサポートされる周波数も含み得る。非常に特定的な周波数(たとえば、バンド3またはバンド5のみ)をサポートすることは、測定の最適化に役立つことができ、また、バッテリ電力を節約する。また、これは、デバイスができるだけ長くセル内に維持され得るとき、ネットワークがハンドオーバを最適化するのに役立つことができる。

【0159】

さらに別の実施形態において、UE(センサーデバイス)は、非アクティブタイマーおよび状態がそれに応じて構成され得るように、その送信パターン、すなわち、決まったパターンの決まったバイトについてネットワークに知らせるその能力も含むことができる。これは、UEが非アクティブ状態の構成を必要とするのか、または最後のパケットの送信後にトランザクションを完了することができるのかを表すブール値フラグ -- ue Inactive State Ind -- を使用して実現され得る。

【0160】

最後のパケットを示すために、RLCヘッダ内でビットが示される。そのような情報は、UE能力情報要素に取り込まれる場合がある。例示的な実施形態として、モビリティセンサー情報を追加した後、NB-IoTのUE能力情報は、下で説明されるように、以下のように見える。
UE-Capability-NB-rxx ::= SEQUENCE {
access Stratum Release-r13 AccessStratumRelease-NB-r13,
ue-Category-NB-r13 ENUMERATED {nb1} OPTIONAL,
multiple DRB-r13 ENUMERATED {supported} OPTIONAL,
pdcp- Parameters-r13 PDCP-Parameters-NB-r13 OPTIONAL,
phy Layer Parameters-r13 PhyLayerParameters-NB-r13,
rf-Parameters-r13 RF-Parameters-NB-r13,
sensor-Parameters-NB-rxx Sensor-Parameters-NB-rxx,
dummy SEQUENCE {} OPTIONAL
}
Sensor-Parameters-NB-rxx ::= SEQUENCE {
supported-sensor-list-rxx Supported-Sensor-List-NB-rxx,
mobility-management-need-rxx ENUMERATED {Stationary, Nomadic, Low Mobile, Full mobile} DEFAULT Stationary,
}
Supported-Sensor-List-NB-rxx ::= SEQUENCE (SIZE (1.. maxSensorsSupported-NB-rxx)) OF Supported-Sensor-NB-rxx
Supported-Sensor-NB-rxx ::= SEQUENCE {
sensor-ID INTEGER (0..255),
sensor-type ENUMERATED {Energy Meter, Water Meter, Gas Meter, Altimeter, pH meter, Soil Moisture Sensor, ...},
sensor-specific-capability-NB-rxx Sensor-Specific-Capability-NB-rxx,
}
ue Inactive State Ind ::= {True, False}

【0161】

農業センサーのような追加のセンサータイプが同様の方法で構造に追加されることが可能であり、提供された例は1つの例示的なサンプルに過ぎないことを理解されたい。

【0162】

図6は、本開示の実施形態による、本発明の実施形態が利用され得る例示的なコンピュータシステム600を示す。図6に示されるように、コンピュータシステム600は、外部ストレージデバイス610、バス620、メインメモリ630、読み出し専用メモリ640、大容量ストレージデバイス650、通信ポート660、およびプロセッサ670を含み得る。当業者は、コンピュータシステムが2つ以上のプロセッサ670および通信ポート660を含む場合があることを理解するであろう。プロセッサ670の例は、Intel(登録商標) Itanium(登録商標)もしくはItanium 2プロセッサ、またはAMD(登録商標) Opteron(登録商標)もしくはAthlon MP(登録商標)プロセッサ、Motorola(登録商標)の系統のプロセッサ、FortiSOC(商標)システムオンチッププロセッサ、またはその他の将来のプロセッサを含むがそれらに限定されない。プロセッサ670は、本発明の実施形態に関連する様々なモジュールを含んでよい。通信ポート660は、モデムベースのダイアルアップ接続で使用するためのRS-232ポート、10/100イーサネットポート、銅もしくはファイバを使用するギガビットもしくは10ギガビットポート、シリアルポート、パラレルポート、またはその他の既存のもしくは将来のポートのいずれかであることが可能である。通信ポート660は、ローカルエリアネットワーク(LAN)、広域ネットワーク(WAN)、またはコンピュータシステムが接続する任意のネットワークのようなネットワークに応じて選択されてよい。メインメモリ630は、ランダムアクセスメモリ(RAM)、または当技術分野で広く知られている任意のその他のダイナミックストレージデバイスであることが可能である。読み出し専用メモリ640は、任意のスタティックストレージデバイス、たとえば、これに限定されないが、静的情報、たとえば、プロセッサ670のためのスタートアップまたはBIOS命令を記憶するためのプログラマブル読み出し専用メモリ(PROM)チップであることが可能である。大容量ストレージ650は、情報および/または命令を記憶するために使用され得る任意の現在または将来の大容量ストレージソリューションであってよい。例示的な大容量ストレージソリューションは、パラレルアドバンスドテクノロジーアタッチメント(PATA: Parallel Advanced Technology Attachment)またはシリアルアドバンスドテクノロジーアタッチメント(SATA: Serial Advanced Technology Attachment)ハードディスクドライブまたはソリッドステートドライブ(内蔵または外付け、たとえば、ユニバーサルシリアルバス(USB)またはFirewireインターフェースを有する)、たとえば、Seagateから入手可能なもの(たとえば、Seagate Barracuda 782ファミリー)またはHitachiから入手可能なもの(たとえば、Hitachi Deskstar 13K800)、1つまたは複数の光ディスク、独立したディスクの冗長なアレイ(RAID: Redundant Array of Independent Disks)ストレージ、たとえば、Dot Hill Systems Corp.、LaCie、Nexsan Technologies, Inc.、およびEnhance Technology, Inc.を含む様々なベンダから入手可能なディスクのアレイ(たとえば、SATAアレイ)を含むがそれらに限定されない。

【0163】

バス620は、プロセッサ670をその他のメモリ、ストレージ、および通信ブロックと通信可能なように結合する。バス620は、たとえば、拡張カード、ドライブ、およびその他のサブシステムを接続するための周辺装置相互接続(PCI: Peripheral Component Interconnect)/PCI拡張(PCI-X)バス、小型コンピュータシステムインターフェース(SCSI)、USBなど、ならびにプロセッサ670をソフトウェアシステムに接続するフロントサイドバス(FSB)などのその他のバスであることが可能である。

【0164】

任意で、オペレータおよび管理インターフェース、たとえば、ディスプレイ、キーボード、およびカーソル制御デバイスも、コンピュータシステムとの直接的なオペレータのインタラクションをサポートするためにバス620に結合されてよい。その他のオペレータおよび管理インターフェースが、通信ポート660を介して接続されたネットワーク接続を通じて提供され得る。外部ストレージデバイス610は、任意の種類の外付けハードディスク、フロッピードライブ、IOMEGA(登録商標) Zipドライブ、コンパクトディスク読み出し専用メモリ(CD-ROM)、コンパクトディスクリライタブル(CD-RW: Compact Disc-Re-Writable)、デジタルビデオディスク読み出し専用メモリ(DVD-ROM)であることが可能である。上述のコンポーネントは、様々な可能性を例示するようにのみ意図されている。前述の例示的なコンピュータシステムは、本開示の範囲を決して限定すべきでない。

【0165】

本明細書において好ましい実施形態にかなりの重点が置かれたが、多くの実施形態が作られることが可能であり、本発明の原理から逸脱することなく好ましい実施形態に多くの変更がなされることが可能であることは理解されるであろう。本発明の好ましい実施形態のこれらおよびその他の変更は、本明細書の開示から当業者に明らかになり、それによって、前述の説明的事項が、限定としてではなく、単に本発明を例示するものとして実施されることが明確に理解されることになる。

【0166】

本開示の利点
本開示は、モノのインターネット(IoT)ネットワークにおけるサービス品質(QoS)の効率的で、レイテンシに敏感な、および信頼性の高い最適化のためのシステムおよび方法を提供する。

【0167】

本開示は、アプリケーションがレイテンシに敏感でないかどうか、EDGEおよび/または無線アクセスノードにおいてキャッシュのサポートおよび/または連携された処理能力を必要とするかどうかを特定するのに役立つ新しいQoSプロファイルのためのシステムおよび方法を提供する。

【0168】

本開示は、特定のアプリケーションのためのインテリジェントなデータ処理を実行してよい無線アクセスネットワーク内の追加のコンピュートエンティティをサポートするためのシステムおよび方法を提供する。

【0169】

本開示は、IoTアプリケーションカテゴリまたはタイプを認識するシステムおよび方法を提供し、そのとき、IoTアプリケーションカテゴリまたはタイプは、新しいQoSクラスを適切に割り振るためにIoTネットワークによって使用される。

【0170】

本開示は、一部のアプリケーションの優先度が相対的であるときに、カテゴリタイプの間で(たとえば、レイテンシに敏感でないタイプからレイテンシに敏感なタイプへ)優先度を変更するためのシグナリングのためのシステムおよび方法を提供する。

【0171】

本開示は、新しいアプリケーションカテゴリを定義された新しいQoSクラス識別子にマッピングすることができる、アプリケーションと非アクセス層(NAS)との間のモデムインターフェースを利用するシステムおよび方法を提供する。

【0172】

本開示は、IoTアプリケーション/データを、信頼性、レイテンシへの敏感さの観点でのその全体的なエンドユースケースの属性に基づいて扱うためのシステムおよび方法を提供する。

【0173】

本開示は、データストリーム、データのパケット、またはデバイスから発信される任意のデータがキャッシュを必要とするかどうか、キャッシュの局所性、それが処理の詳細の性質をローカルで処理することを必要とするかどうかなどのQoSパラメータを含めるためのシステムおよび方法を提供する。

【0174】

本開示は、拡張されたQoSテンプレートのQoSメカニズム、レイテンシに敏感でないアプリケーションのためのそのような新しいQoSテンプレートを解釈し、適用するメカニズムのためのシステムおよび方法を提供する。

【符号の説明】

【0175】

100 ネットワークアーキテクチャ
102 ユーザ機器(UE)
102-1、102-2、102-3、...、102-N ユーザ機器(UE)
104 アプリケーションサーバ
106 ネットワーク
108 アプリケーション
110 通信モデム
202 プロセッサ
204 メモリ
206 インターフェース
208 処理エンジン
210 データベース
212 分析エンジン
214 その他のエンジン
402 無線アクセスネットワーク(RAN)
404 アクセスおよびモビリティ管理機能(AMF)
406 セッション管理機能(SMF)
408 ポリシー制御機能(PCF)
410 ユーザプレーン機能(UPF)
412 データネットワーク(DN)/インターネット
500 方法
512 アクセスネットワーク
514 コアネットワーク
516 アプリケーション機能(AF)
600 コンピュータシステム
610 外部ストレージデバイス
620 バス
630 メインメモリ
640 読み出し専用メモリ
650 大容量ストレージデバイス
660 通信ポート
670 プロセッサ

【図1】

【図2】

【図3】

【図4】

【図5A】

【図5B】

【図5C】

【図5D】

【図5E】

【図5F】

【図5G】

【図5H】

【図5I】

【図5J】

【図5K】

【図6】

【国際調査報告】