特許 7439111 サービス能力公開機能（ＳＣＥＦ）を介してモノのインターネット（ＩｏＴ）デバイスの状態を監視する方法、システム、およびコンピュータ可読媒体

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

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

(11)【特許番号】

(24)【登録日】2024-02-16

(45)【発行日】2024-02-27

(54)【発明の名称】サービス能力公開機能（ＳＣＥＦ）を介してモノのインターネット（ＩｏＴ）デバイスの状態を監視する方法、システム、およびコンピュータ可読媒体

(51)【国際特許分類】

   H04W 4/70 20180101AFI20240219BHJP

   H04W 88/18 20090101ALI20240219BHJP

   H04W 92/24 20090101ALI20240219BHJP

【ＦＩ】

H04W4/70

H04W88/18

H04W92/24

【請求項の数】 20

(21)【出願番号】P 2021543455

(86)(22)【出願日】2020-01-16

(65)【公表番号】

(43)【公表日】2022-04-01

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

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

(87)【国際公開日】2020-08-27

【審査請求日】2022-10-21

(31)【優先権主張番号】16/280,672

(32)【優先日】2019-02-20

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

(73)【特許権者】

【識別番号】502303739

【氏名又は名称】オラクル・インターナショナル・コーポレイション

(74)【代理人】

【識別番号】110001195

【氏名又は名称】弁理士法人深見特許事務所

(72)【発明者】

【氏名】ナラヤナン，ゴクル

(72)【発明者】

【氏名】マハランク，シャシキラン・バラチャンドラ

(72)【発明者】

【氏名】クリシャン，ラジブ

【審査官】桑原 聡一

(56)【参考文献】

【文献】3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; T8 reference point for Northbound APIs; (Release 16)，3GPP TS 29.122 V16.0.0 (2018-12)，2018年12月，第２０－２６頁

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

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

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

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

ＳＡ ＷＧ１－４

ＣＴ ＷＧ１、４

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

【請求項1】

モノのインターネット（ＩｏＴ）デバイスの状態を監視する方法であって、前記方法は、
少なくとも１つのプロセッサを使用して実現されたサービス能力公開機能（ＳＣＥＦ）において、
複数の異なる世代のネットワークのＩｏＴデバイスの状態を監視するために、ＩｏＴアプリケーションサーバ（ＡＳ）またはサービス能力サーバ（ＳＣＳ）から、サブスクリプション要求を受信するための共通インターフェイスを提供することと、
前記ＳＣＥＦにおいて、前記複数の異なる世代のネットワークのうちの第１ネットワークのＩｏＴデバイスの識別子のデータベースを保持することと、
前記ＳＣＥＦにおいて、前記第１ネットワークのサブスクライバデータリポジトリノードへのインターフェイスを提供することと、
前記共通インターフェイスを介して、ＩｏＴデバイスに関する状態情報を受信することをサブスクライブするためのサブスクリプション要求を受信することと、
前記データベース内のルックアップを実行し、前記サブスクリプション要求を、前記第１ネットワークに登録されたＩｏＴデバイスに関連しているものとして識別することと、
前記第１ネットワークへの前記インターフェイスを介して、前記ＩｏＴデバイスに関する状態情報を受信するために、メッセージを前記サブスクライバデータリポジトリノードに送信することとを含む、方法。

【請求項2】

前記共通インターフェイスはＴ８インターフェイスを備え、
前記第１ネットワークは、２Ｇまたは３Ｇネットワークを含み、
前記Ｔ８インターフェイスは、４Ｇまたは５Ｇ ＩｏＴデバイスに関する状態情報のサブスクリプション要求を受信するようにさらに構成されており、
前記方法は、前記４Ｇまたは５Ｇ ＩｏＴデバイスに関する状態情報の受信をサブスクライブするために、前記複数の異なる世代のネットワークのうちの第２ネットワークへのインターフェイスを介して、メッセージを前記第２ネットワーク内のノードに送信することをさらに含む、請求項１に記載の方法。

【請求項3】

前記データベースを提供することは、モバイルサブスクライバインテグレーテッドサービスデジタルネットワーク（ＭＳＩＳＤＮ）番号、または外部識別子のドメイン部分によって索引付けされたデータベースを提供することを含む、請求項１または２に記載の方法。

【請求項4】

前記サブスクライバデータリポジトリノードは、ホームロケーションレジスタ（ＨＬＲ）を備える、請求項１～３のいずれかに記載の方法。

【請求項5】

前記サブスクライバデータリポジトリノードに前記メッセージを送信することは、前記サブスクライバデータリポジトリノードに、エニタイムインテロゲーション（ＡＴＩ）要求メッセージを送信することを含む、請求項１～４のいずれかに記載の方法。

【請求項6】

前記サブスクリプション要求は、１回の監視の要求であり、前記ＡＴＩ要求メッセージは、１回の監視を示す情報要素を含む、請求項５に記載の方法。

【請求項7】

前記サブスクリプション要求は、連続監視の要求であり、前記ＡＴＩ要求メッセージは、連続監視を示す情報要素を含む、請求項５に記載の方法。

【請求項8】

前記ＳＣＥＦにおいてタイマーを保持し、前記タイマーが満了するごとに、前記サブスクライバデータリポジトリノードにＡＴＩ要求メッセージを定期的に送信し、前記連続監視を行うことを含む、請求項７に記載の方法。

【請求項9】

前記ＳＣＥＦにおいて、前記ＩｏＴデバイスに関する状態情報を受信することと、前記共通インターフェイスを介して、前記ＳＣＳまたは前記ＡＳに前記状態情報を提供することとを含む、請求項１～８のいずれかに記載の方法。

【請求項10】

前記ＳＣＥＦは、スタンドアロンノード、または、ダイアメータシグナリングルータ（ＤＳＲ）もしくはポリシーサーバのコンポーネントを備える、請求項１～９のいずれかに記載の方法。

【請求項11】

モノのインターネット（ＩｏＴ）デバイスの状態を監視するためのシステムであって、前記システムは、
サービス能力公開機能（ＳＣＥＦ）を備え、前記サービス能力公開機能（ＳＣＥＦ）は、
少なくとも１つのプロセッサと、
複数の異なる世代のネットワークのＩｏＴデバイスの状態を監視するために、ＩｏＴアプリケーションサーバ（ＡＳ）またはサービス能力サーバ（ＳＣＳ）から、サブスクリプション要求を受信するための共通インターフェイスと、
前記複数の異なる世代のネットワークのうちの第１ネットワークのＩｏＴデバイスの識別子のデータベースと、
前記第１ネットワークのサブスクライバデータリポジトリノードへのインターフェイスとを含み、
前記ＳＣＥＦは、前記共通インターフェイスを介して、ＩｏＴデバイスに関する状態情報を受信することをサブスクライブするためのサブスクリプション要求を受信し、前記データベース内のルックアップを実行し、前記サブスクリプション要求を前記第１ネットワークに登録されているＩｏＴデバイスに関連するものとして識別し、前記ＩｏＴデバイスに関する状態情報を受信するために、前記第１ネットワークへの前記インターフェイスを介して、メッセージを前記サブスクライバデータリポジトリノードに送信する、システム。

【請求項12】

前記共通インターフェイスは、Ｔ８インターフェイスを含み、
前記第１ネットワークは、２Ｇまたは３Ｇネットワークを含み、
前記Ｔ８インターフェイスは、４Ｇまたは５Ｇ ＩｏＴデバイスに関する状態情報のサブスクリプション要求を受信するようにさらに構成され、
前記ＳＣＥＦは、前記複数の異なる世代のネットワークのうちの第２ネットワークへのインターフェイスをさらに含み、前記第２ネットワークへの前記インターフェイスを介して、前記４Ｇまたは５Ｇ ＩｏＴデバイスに関する状態情報を受信することをサブスクライブするために、メッセージを前記第２ネットワークのノードに送信する、請求項１１に記載のシステム。

【請求項13】

前記データベースは、モバイルサブスクライバインテグレーテッドサービスデジタルネットワーク（ＭＳＩＳＤＮ）番号、または外部識別子のドメイン部分によって索引付けされている、請求項１１または１２に記載のシステム。

【請求項14】

前記サブスクライバデータリポジトリノードは、ホームロケーションレジスタ（ＨＬＲ）を備える、請求項１１～１３のいずれかに記載のシステム。

【請求項15】

前記サブスクライバデータリポジトリノードに送信される前記メッセージは、エニタイムインテロゲーション（ＡＴＩ）要求メッセージを含む、請求項１１～１４のいずれかに記載のシステム。

【請求項16】

前記サブスクリプション要求は、１回の監視の要求であり、前記ＡＴＩ要求メッセージは、１回の監視を示す情報要素を含む、請求項１５に記載のシステム。

【請求項17】

前記サブスクリプション要求は、連続監視の要求であり、前記ＡＴＩ要求メッセージは、連続監視を示す情報要素を含む、請求項１５に記載のシステム。

【請求項18】

前記ＳＣＥＦは、タイマーを保持し、前記タイマーの満了ごとに、ＡＴＩ要求メッセージを前記サブスクライバデータリポジトリノードに定期的に送信し、前記連続監視を行う、請求項１７に記載のシステム。

【請求項19】

前記ＳＣＥＦは、前記ＩｏＴデバイスに関する状態情報を受信し、前記共通インターフェイスを介して、前記ＳＣＳまたは前記ＡＳに前記状態情報を提供する、請求項１１～１８のいずれかに記載のシステム。

【請求項20】

コンピュータのプロセッサによって実行されると、前記コンピュータを制御して請求項１～１０のいずれかに記載の方法を実行させるための、プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

優先権主張
本出願は、２０１９年２月２０日に出願された米国特許出願番号１６／２８０，６７２の優先権を主張するものであり、参照により、その開示内容全体が本明細書に組み込まれる。

【0002】

技術分野
本明細書に記載の主題は、ＩｏＴデバイスの状態を監視することに関する。より具体的には、本明細書に記載の主題は、異なる世代のネットワークのＩｏＴデバイスを監視するための共通インターフェイスを提供することによってＩｏＴデバイスの状態を監視することに関する。

【背景技術】

【0003】

背景
第３世代パートナーシッププロジェクト（３ＧＰＰ: Third Generation Partnership Project）は、ＩｏＴアプリケーションサーバ（ＡＳ : Application Servers）およびサービス能力サーバ（ＳＣＳ : Service Capability Servers）が４Ｇ ＩｏＴデバイスの状態を監視することを可能にする機械式通信（ＭＴＣ : Machine Type Communication）監視手順を定義している。監視可能な状態の例として、位置情報、ローミングステータス、デバイス到達可能性等がある。しかしながら、現在の３ＧＰＰで定義された手順では、ＩｏＴアプリケーションサーバまたはサービス能力サーバが、２Ｇおよび３ＧネットワークのＩｏＴデバイス、または２Ｇおよび３Ｇネットワークに接続されたＩｏＴデバイスのデバイス状態を監視することはできない。

【0004】

この問題に対する１つの可能な解決策は、ＩｏＴアプリケーションサーバが４Ｇ ＩｏＴデバイスの状態を受信することをサブスクライブするための１つのインターフェイスを提供し、ＩｏＴアプリケーションサーバが２Ｇまたは３Ｇ ＩｏＴデバイスの状態を受信することをサブスクライブするための別のインターフェイスを提供することである。このような解決策は、ＩｏＴアプリケーションサーバとサービス能力サーバが、監視対象のＩｏＴデバイスのタイプに応じて異なるインターフェイスの要件に準拠する必要があり、望ましくない。

【0005】

したがって、ＩｏＴデバイスの状態を監視するための改善された方法、システム、およびコンピュータ可読媒体が必要とされている。

【発明の概要】

【0006】

概要
本明細書に記載の主題は、ＩｏＴデバイスの状態を監視するための方法、システム、およびコンピュータ可読媒体を含む。ある方法は、少なくとも１つのプロセッサを使用して実現されたサービス能力公開機能（ＳＣＥＦ : Service Capability Exposure Function）において、複数の異なる世代のネットワークのＩｏＴデバイスの状態を監視するために、ＩｏＴアプリケーションサーバ（ＡＳ）またはサービス能力サーバ（ＳＣＳ）からサブスクリプション要求を受信するための共通インターフェイスを提供することを含む。

【0007】

「複数の異なる世代のネットワークのＩｏＴデバイス」および「異なる世代のネットワークのＩｏＴデバイス」という表現は、３ＧＰＰで定義されたネットワークの世代において、異なる世代のネットワークに接続されて動作するＩｏＴデバイスを意味する。例えば、２Ｇネットワークは、ある世代のネットワークであってもよい。３Ｇネットワークは、別の世代の別のネットワークであってもよい。４Ｇネットワークは、さらに別の世代のネットワークであってもよい。５Ｇネットワークは、さらに別の世代のネットワークであってもよい。一般的に、ＳＣＥＦが提供する共通インターフェイスは、n世代のネットワークに接続されたＩｏＴデバイスと、m世代のネットワークに接続されたＩｏＴデバイスのイベントサブスクリプションを監視することを可能にする。なお、nとmは整数であり、等しくない。

【0008】

方法は、ＳＣＥＦにおいて、第１世代ネットワークのＩｏＴデバイスの識別子のデータベースを保持することをさらに含む。方法は、ＳＣＥＦにおいて、第１世代ネットワークのサブスクライバデータリポジトリノードへのインターフェイスを提供することをさらに含む。方法は、共通インターフェイスを介して、ＩｏＴデバイスに関する状態情報を受信することをサブスクライブするためのサブスクリプション要求を受信することをさらに含む。方法は、データベースでルックアップを実行し、サブスクリプション要求が第１世代ネットワークに登録されたＩｏＴデバイスに関連するものであると識別することをさらに含む。方法はさらに、第１世代ネットワークへのインターフェイスを介して、ＩｏＴデバイスに関する状態情報を受信するために、メッセージをサブスクライバデータリポジトリノードに送信することを含む。

【0009】

一例では、共通インターフェイスは、Ｔ８インターフェイスを備え、第１世代ネットワークは、２Ｇまたは３Ｇネットワークを備え、Ｔ８インターフェイスは、さらに、４Ｇまたは５Ｇ ＩｏＴデバイスに関する状態情報のサブスクリプション要求を受信するように構成され、方法は、第２世代ネットワークへのインターフェイスを介して、４Ｇまたは５Ｇ ＩｏＴデバイスに関する状態情報を受信することをサブスクライブするために、メッセージを第２世代ネットワーク内のノードに送信することをさらに含む。

【0010】

別の例では、データベースを提供することは、モバイルサブスクライバインテグレーテッドサービスデジタルネットワーク（ＭＳＩＳＤＮ : Mobile Subscriber Integrated Services Digital Network）番号または外部識別子のドメイン部分によって索引付けされたデータベースを提供することを含む。

【0011】

さらに別の例では、サブスクライバデータリポジトリノードは、ホームロケーションレジスタ（ＨＬＲ: Home Location Register）を備える。

【0012】

さらに別の例では、サブスクライバデータリポジトリノードにメッセージを送信することは、データリポジトリノードに、エニタイムインテロゲーション（ＡＴＩ : Anytime Interrogation）要求メッセージを送信することを備える。

【0013】

さらに別の例では、サブスクリプション要求は１回の監視の要求であり、ＡＴＩ要求メッセージは１回の監視を示す情報要素を含む。

【0014】

さらに別の例では、サブスクリプション要求は、連続監視の要求であり、ＡＴＩ要求メッセージは、連続監視を示す情報要素を含む。

【0015】

さらに別の例では、ＳＣＥＦにはタイマーが保持されている。ＳＣＥＦは、タイマーが満了するたびに、サブスクライバデータリポジトリノードにＡＴＩ要求メッセージを定期的に送信することで、連続監視を実現する。

【0016】

さらに別の例では、ＳＣＥＦは、ＩｏＴデバイスに関する状態情報を受信し、共通インターフェイスを介してその状態情報をＳＣＳまたはＡＳに提供する。

【0017】

さらに別の例では、ＳＣＥＦは、スタンドアロンのノード、または、ダイアメータシグナリングルータ（ＤＳＲ : Diameter Signaling Router）またはポリシーサーバのコンポーネントを備える。

【0018】

ＩｏＴデバイスの状態を監視するシステムは、サービス能力公開機能（ＳＣＥＦ）を含む。ＳＣＥＦは、少なくとも１つのプロセッサを含む。ＳＣＥＦは、複数の異なる世代のネットワークのＩｏＴデバイスの状態を監視するために、ＩｏＴアプリケーションサーバ（ＡＳ）またはサービス能力サーバ（ＳＣＳ）からサブスクリプション要求を受信するための共通インターフェイスをさらに含む。ＳＣＥＦは、第１世代のネットワークのＩｏＴデバイスの識別子のデータベースをさらに含む。ＳＣＥＦは、第１世代ネットワークのサブスクライバデータリポジトリノードへのインターフェイスをさらに含む。ＳＣＥＦは、共通インターフェイスを介して、ＩｏＴデバイスに関する状態情報を受信することをサブスクライブするためのサブスクリプション要求を受信し、データベース内のルックアップを実行し、第１世代ネットワークに登録されたＩｏＴデバイスに関連するものとしてサブスクリプション要求を識別し、ＩｏＴデバイスに関する状態情報を受信するために、第１世代ネットワークへのインターフェイスを介して、メッセージをサブスクライバデータリポジトリノードに送信する。

【0019】

本明細書に記載の主題の別の態様によれば、コンピュータのプロセッサによって実行されたときに、ステップを実行するようにコンピュータを制御する実行可能な命令を格納した非一時的なコンピュータ可読媒体が提供される。ステップは、少なくとも１つのプロセッサを使用して実現されたサービス能力公開機能（ＳＣＥＦ）において、含む。ステップは、複数の異なる世代のネットワークのＩｏＴデバイスの状態を監視するために、ＩｏＴアプリケーションサーバ（ＡＳ）またはサービス能力サーバ（ＳＣＳ）からサブスクリプション要求を受信するための共通インターフェイスを提供することをさらに含む。ステップは、ＳＣＥＦにおいて、第１世代ネットワークのＩｏＴデバイスの識別子のデータベースを保持することをさらに含む。ステップは、ＳＣＥＦにおいて、第１世代ネットワークのサブスクライバデータリポジトリノードへのインターフェイスを提供することと、上記共通インターフェイスを介して、ＩｏＴデバイスに関する状態情報を受信することをサブスクライブするためのサブスクリプション要求を受信することとをさらに含む。ステップは、データベース内のルックアップを実行し、サブスクリプション要求が第１世代ネットワークに登録されたＩｏＴデバイスに関連するものであることを特定することをさらに含む。ステップは、ＩｏＴデバイスに関する状態情報を受信するために、第１世代ネットワークへのインターフェイスを介してメッセージをサブスクライバデータリポジトリノードに送信することをさらに含む。

【0020】

本明細書に記載されている主題は、ハードウェアおよび／またはファームウェアと組み合わせてソフトウェアにより実現されてもよい。例えば、本明細書に記載の主題は、プロセッサによって実行されるソフトウェアにより実現されてもよい。ある実施の例において、本明細書に記載された主題は、コンピュータのプロセッサによって実行されると、ステップを実行するようにコンピュータを制御するコンピュータ実行可能命令を格納した非一時的なコンピュータ可読媒体を用いて実現されてもよい。本明細書に記載の主題を実現するのに適した例示的なコンピュータ可読媒体には、ディスクメモリデバイス、チップメモリデバイス、プログラマブルロジックデバイス、およびアプリケーション固有の集積回路などの非一時的コンピュータ可読媒体が含まれる。さらに、本明細書に記載されている主題を実現するコンピュータ可読媒体は、単一のデバイスまたはコンピューティングプラットフォーム上に配置されてもよいし、複数のデバイスまたはコンピューティングプラットフォーム上に分散されて配置されてもよい。

【0021】

図面の簡単な説明
添付の図面を参照して本明細書に記載されている主題を説明する。

【図面の簡単な説明】

【0022】

【図1】ホームサブスクライバーサーバー（ＨＳＳ : Home Subscriber Server）が要求された状態情報を含む場合に、４Ｇ ＩｏＴデバイスのＩｏＴデバイス状態を受信することをサブスクライブするためにＴ８インターフェイスを使用するための例示的なメッセージフローを示すメッセージフロー図である。

【図2】ＨＳＳが要求された状態情報を含んでいない場合に、４Ｇ ＩｏＴデバイスのＩｏＴデバイス状態を受信することをサブスクライブするために交換される例示的なメッセージングを示すメッセージフロー図である。

【図3】監視イベントのサブスクリプションが単一のイベント監視のためのものである場合に、２Ｇまたは３ＧのＩｏＴデバイスの状態を受信することをサブスクライブするための例示的なメッセージングを示すメッセージフロー図である。

【図4】監視イベントのサブスクリプションが連続監視のためのものである場合に、２Ｇまたは３ＧのＩｏＴデバイスの状態を受信することをサブスクライブするための例示的なメッセージングを示すメッセージフロー図である。

【図5】複数の異なる世代のネットワークのＩｏＴデバイスに対するＩｏＴデバイス状態を監視するための例示的なプロセスを示すフローチャートである。

【図6】複数の異なる世代のネットワークのＩｏＴデバイスのＩｏＴデバイス状態を受信することをサブスクライブするための共通インターフェイスを提供するスタンドアロンＳＣＥＦのブロック図である。

【図7】ダイアメータシグナリングルータのコンポーネントであるＳＣＥＦのブロック図であり、ＳＣＥＦは、複数の異なる世代のネットワークのＩｏＴデバイスの状態情報を受信することのサブスクリプションを可能にするための共通インターフェイスを含む。

【図8】複数の異なる世代のネットワークのＩｏＴデバイスの状態情報の更新を受信することのサブスクリプションを可能にするための共通インターフェイスを持つＳＣＥＦを含むポリシーサーバのブロック図である。

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

【0023】

詳細な説明
本明細書に記載の主題は、ＩｏＴアプリケーションサーバが異なる世代のネットワークのＩｏＴデバイスの状態情報を受信することをサブスクライブするための共通インターフェイスを提供するＳＣＥＦを含む。一例では、共通インターフェイスは、３ＧＰＰ標準文書で規定されているＴ８インターフェイスであってもよく、ＩｏＴ ＡＳおよびＳＣＳは、４Ｇ ＩｏＴデバイスの状態情報の更新を受信することをサブスクライブする。しかしながら、更新を受信することをサブスクライブするために規定された手順は、現在、４Ｇ ＩｏＴデバイスに対してのみ有効である。本明細書に記載の主題は、同じインターフェイスを使用して、２Ｇおよび３Ｇネットワークに接続されたＩｏＴデバイスを含む異なる世代のネットワークのＩｏＴデバイスの更新を受信することをサブスクライブすることを可能にする。また、Ｔ８インターフェイスは、３ＧＰＰＡＳおよびＳＣＳによって、５Ｇ ＩｏＴデバイスの状態情報の更新をサブスクライブして受信するために使用されてもよい。

【0024】

ＡＳおよびＳＣＳが異なる世代のネットワークのＩｏＴデバイスの状態情報の更新をサブスクライブして受信するための共通インターフェイスを提供することは、異なる世代のネットワークのＩｏＴデバイスのＩｏＴ状態情報の更新を受信することをサブスクライブするための個別のインターフェイスを必要とするアプローチよりも有利である。例えば、２Ｇおよび３Ｇ ＩｏＴデバイスの状態情報の更新を受信することをサブスクライブするための１つのインターフェイスが提供され、４Ｇ ＩｏＴデバイスの状態情報の更新を受信することをサブスクライブするための別のインターフェイスが提供される場合、各ＳＣＳまたはＡＳは、両方のインターフェイスを実装し、ＩｏＴデバイスが接続されているネットワークのタイプ（例えば、２Ｇ、３Ｇ、または４Ｇ）を知ることを要求される。世代の異なるネットワークのＩｏＴデバイスの状態情報をサブスクライブおよび受信するために、ＳＣＳとＡＳに異なるインターフェイスの実装を要求することは、ＳＣＥＦデバイスの数に対応付けられるＳＣＳおよびＡＳデバイスの予想される数に照らし合わせると非効率的である。

【0025】

共通インターフェイスを介して、複数の世代のＩｏＴデバイスの状態情報に対するサブスクリプション要求を受信するＳＣＥＦは、異なる世代のネットワークのＩｏＴデバイスの状態情報を取得するために、全てのＳＣＳおよびＡＳに別々のインターフェイスを実装することを要求することよりも、技術的に改善されている。なぜなら、各ＳＣＳおよびＡＳで別々のサブスクリプションインターフェイスを実装するのに対して、共通インターフェイスは単一の場所、すなわちＳＣＥＦにおいて実装されることのみを要求されるためである。また、ＳＣＥＦは、セキュリティおよび効率性の観点から、ＳＣＳまたはＡＳよりも、各ＩｏＴデバイスが接続されているネットワークの種類を知る上で有利な立場にある。例えば、ネットワークオペレータは、状態情報の要求が適切なネットワークに送信されることができるように、各ＩｏＴデバイスが接続されているネットワークの種類を示すデータベースをＳＣＥＦに設けることができる。また、ネットワークオペレータは、許可されたネットワークからのＳＣＳおよびＡＳへのアクセスを制限することにより、ＩｏＴデバイスの状態へのアクセスを制御することを望むかもしれない。ＩｏＴデバイスの状態にアクセスするためにＳＣＥＦのインターフェイスを使用することで、ＳＣＥＦは、ＩｏＴデバイスの状態情報に対する受信サブスクリプション要求を許可または拒否するためのセキュリティチェックポイントとして使用されることができる。

【0026】

図１は、４Ｇデバイスの状態を監視するための、本明細書に記載されているＳＣＥＦによって実現することができる４Ｇマシンタイプ通信監視イベント構成メッセージフローを示すメッセージフロー図である。図１に示されたメッセージフローは、連続的または１回のＨＳＳのみの監視のためのものであり、ＨＳＳは、ＳＣＳまたはＡＳに代り、ＳＣＥＦから連絡を受けて、ＩｏＴデバイスの状態情報を提供する。

【0027】

サブスクリプションを設定し、ＩｏＴデバイスに関する状態情報を提供するためにＳＣＥＦとＳＣＳ／ＡＳとの間で使用されるインターフェイスは、Ｔ８インターフェイスと呼ばれる。Ｔ８インターフェイスは、３ＧＰＰＴＳ ２９.１２２「Technical Specification Group Core Network and Terminals; T8 reference point for Northbound ＡＰＩs; (Release 15) (December 2018)」で定義されており、その内容を参照することで、その開示内容全体は本明細書に組み込まれる。３ＧＰＰＴＳ ２９.１２２によると、Ｔ８インターフェイスまたは参照点は、ＳＣＳ／ＡＳとＳＣＥＦとの間のインターフェイスである。「ＳＣＳ／ＡＳ」という用語は、ＳＣＳおよび／またはＡＳを指すが、これは、ある場合には、ＡＳがＳＣＥＦと直接対話し、他の場合には、ＡＳがＳＣＳを介してＳＣＥＦと対話するためである。

【0028】

３ＧＰＰＴＳ ２９.１２２で規定されているＴ８インターフェイスの目的の１つは、「監視手順」である。ＳＣＳ／ＡＳを介して４Ｇ ＩｏＴデバイスに関する情報の受信をサブスクライブすることができる監視手順は、監視イベント設定手順と呼ばれる。ＳＣＳ／ＡＳ側に新しいインターフェイスと新しい手順を実装するのではなく、２Ｇおよび３Ｇ ＩｏＴデバイスの状態を監視および報告するためのＳＣＥＦとダウンストリーム要素を構成するために、ＳＣＳとＡＳが同じインターフェイスと同じ手順を使用することができる。最初に４Ｇメッセージフローを説明し、続いて２Ｇ／３Ｇコールフローを説明する。

【0029】

図１に示された４Ｇメッセージフローを参照すると、メッセージフローは、設定またはサブスクリプションフェーズと、報告フェーズとに分けられる。設定フェーズのライン１において、ＳＣＳ／ＡＳ１００は、ＳＣＥＦ１０２に、監視イベントサブスクリプションメッセージを送信する。監視イベントサブスクリプションメッセージは、Ｔ８インターフェイスまたはＳＣＥＦ１０２の参照点を介して、ＳＣＥＦ１０２に送信されてもよい。監視イベントサブスクリプション要求は、要求されたイベントのタイプと、ＵＥの識別子とを含む。要求される可能性のあるイベントの例には、位置情報の要求、ＵＥの到達可能性、または国際移動局識別番号（ＩＭＳＩ : International Mobile Station Identity）から、国際移動体装置識別番号（ＩＭＥＩ : International Mobile Equipment Identity）へのマッピングの変更が含まれる。また、監視イベントサブスクリプション要求は、ＳＣＳ／ＡＳ識別子および監視イベントタイプを含んでもよい。監視イベントタイプの例には、１回の報告および指定された期間の連続監視が含まれる。監視イベントサブスクリプション要求メッセージは、ハイパーテキスト転送プロトコル（ＨＴＴＰ : Hypertext Transfer Protocol）ポストメッセージでＳＣＥＦ１０２に送信されてもよい。

【0030】

設定フェーズのライン２において、ＳＣＥＦ１０２が監視イベントサブスクリプション要求を検証し、Ｓ６ｔインターフェイスを介して、ホームサブスクライバサーバ（ＨＳＳ）１０４にダイアメータ接続情報要求（ＣＩＲ : Connection Information Request）メッセージを送信する。ＣＩＲメッセージは、ユーザのために生成された一意のＳＣＥＦ参照識別子を含む。監視イベントサブスクリプション要求を検証することは、送信元のＳＣＳ／ＡＳが、特定のＩｏＴデバイスの状態情報を監視することを許可されているか否かを判断することを含んでもよい。ＳＣＳ／ＡＳがＩｏＴデバイスの状態情報を監視することを許可されていない場合、ＳＣＥＦ１０２は、監視イベントサブスクリプション要求を拒否してもよい。図１に示された例では、監視イベント要求は、監視イベント要求メッセージで識別されたＩｏＴデバイスの状態情報を監視することを許可されたＳＣＳ／ＡＳからのものであると想定される。

【0031】

設定フェーズのライン３において、ＨＳＳ１０４がリクエストを検証し、ＩｏＴデバイスの状態情報が利用可能な場合はそれを含むレスポンスを送信する。この応答は、ダイアメータ接続情報回答（ＣＩＡ : Connection Information Answer）メッセージであり、Ｓ６ｔインターフェイスを介してＳＣＥＦ１０２に送信される。メッセージフロー図のライン４において、ＳＣＥＦ１０２は、ＨＴＴＰ応答２０１をＳＣＳ／ＡＳ１００に送信する。この応答は、状態情報を受信するためのサブスクリプションが受け入れられたことを示す。一旦、状態情報を受信するためのサブスクリプションが受け入れられると、監視イベント手順のサブスクリプションまたは設定フェーズは終了する。

【0032】

ＨＳＳ１０４は、サブスクリプション情報を含むＣＩＲを受信した後、ＵＥについて監視データが利用可能になるまで待機する。一旦、監視データが利用可能になると、ＨＳＳ１０４は、要求された情報をＳＣＥＦ１０２に送信する。メッセージフロー図の報告フェーズのライン１において、ＨＳＳ１０４は、要求された状態情報とＳＣＥＦ参照識別子とを含むダイアメータルーティング情報要求（ＲＩＲ : Routing Information Request）メッセージをＳＣＥＦ１０２に送信する。ＳＣＥＦ１０２が、１回の報告の生成（１回の報告の場合）、または報告期間の満了または指定された数の報告の受信（連続報告の場合）のいずれかにより、監視要求が失効したと判断した場合、ＳＣＥＦ１０２はＵＥの監視設定を削除する。

【0033】

メッセージフロー図の報告フェーズのライン２において、ＳＣＥＦ１０２は、ＩｏＴデバイスの状態をＳＣＳ／ＡＳ１００に伝達する。デバイスの状態情報は、Ｔ８インターフェイスまたは参照点を介してＳＣＳ／ＡＳ１００に伝達される。

【0034】

メッセージフロー図の報告フェーズのライン３において、ＳＣＳ／ＡＳ１００は、Ｔ８インターフェイスを介して、成功を示す原因コードと共に応答をＳＣＥＦ１０２に送信する。メッセージフロー図の報告フェーズのライン４で、ＳＣＥＦ１０２はダイアメータルーティング情報回答（ＲＩＡ : Routing Information Answer）メッセージをＨＳＳに送信して、成功を示す。

【0035】

図１において、ＨＳＳは、要求されたＩｏＴデバイスの状態情報を保持していることが想定される。別の例では、ＨＳＳは、要求されたＩｏＴデバイス状態情報を持っていない場合があり、要求されたＩｏＴデバイス状態情報を取得するために、モビリティマネージメントエンティティ（ＭＭＥ : Mobility Management Entity）またはサービングジェネラルパケットラジオサービスサポートノード（ＳＧＳＮ : Serving General packet radio service Support Node）に連絡する場合がある。図２は、ＭＭＥまたはＳＧＳＮから４Ｇ ＩｏＴデバイス状態情報を取得するための監視イベント設定手順および報告手順を示すメッセージフロー図である。

【0036】

図２を参照すると、図１と同様に、メッセージフローは、設定フェーズと、サブスクリプションまたは報告フェーズとに分けられる。設定フェーズのライン１において、ＳＣＳ／ＡＳ１００は、ＳＣＥＦ１０２に監視イベントサブスクリプションメッセージを送信する。監視イベントサブスクリプションメッセージは、Ｔ８インターフェイスまたはＳＣＥＦ１０２の参照点を介して、ＳＣＥＦ１０２に送信されてもよい。監視イベントサブスクリプション要求は、要求されたイベントのタイプと、ＵＥの識別子とを含む。要求される可能性のあるイベントの例には、位置情報の要求、ＵＥの到達可能性、またはＩＭＳＩからＩＭＥＩへのマッピングの変更が含まれる。また、監視イベントサブスクリプション要求は、ＳＣＳ／ＡＳ識別子および監視イベントタイプを含んでもよい。監視イベントタイプの例には、１回の報告および指定された期間の連続監視が含まれる。監視イベント要求メッセージは、ＨＴＴＰポストメッセージでＳＣＥＦ１０２に送信されてもよい。

【0037】

設定フェーズのライン２において、ＳＣＥＦ１０２は、監視イベント要求を検証し、Ｓ６ｔインタフェースを介してＨＳＳ１０４にダイアメータＣＩＲメッセージを送信する。ＣＩＲメッセージは、ユーザのために生成された一意のＳＣＥＦ参照識別子を含む。監視イベント要求を検証することは、送信元のＳＣＳ／ＡＳが特定のＩｏＴデバイスの状態情報を監視することを許可されているか否かを判定することを含んでもよい。ＳＣＳ／ＡＳがＩｏＴデバイスの状態情報を監視することを許可されていない場合、ＳＣＥＦ１０２は、監視イベント要求を拒否してもよい。図２に示される例において、監視イベント要求は、監視イベント要求メッセージで識別されたＩｏＴデバイスの状態情報を監視することが許可されているＳＣＳ／ＡＳからのものであると想定される。

【0038】

設定フェーズのライン３において、ＨＳＳ１０４は要求を検証し、ＭＭＥ／ＳＧＳＮ１０６等のＩｏＴデバイスサービスノードに要求を転送し、ＳＣＥＦ１０２に利用可能なあらゆるＩｏＴデバイス状態情報を報告する。ＨＳＳ１０４からＭＭＥ／ＳＧＳＮ１０６への要求は、ダイアメータ挿入サブスクライバデータ要求（ＩＤＲ : Insert subscriber Data Request）メッセージにより運ばれる。ＭＭＥ／ＳＧＳＮ１０６は、監視サブスクリプションの要求が受け入れられたことを示すダイアメータ挿入サブスクライバデータ回答（ＩＤＡ : Insert subscriber Data Answer）メッセージで応答し、ＩＤＡメッセージには、利用可能な任意のＩｏＴデバイス状態情報が含まれる。設定フェーズのライン５において、ＨＳＳ１０４はＩＤＡメッセージを受信し、ＩｏＴデバイスの監視の設定が成功したことを示すＣＩＡメッセージをＳＣＥＦ１０２に送信する。設定フェーズのライン６において、ＳＣＥＦ１０２は、ＳＣＳ／ＡＳ１００にＨＴＴＰ応答２０１を送信する。この応答は、状態情報を受信するためのサブスクリプションが受け入れられたことを示す。一旦、状態情報を受信するために要求されたサブスクリプションが受け入れられると、監視イベント手順のサブスクリプションまたは設定フェーズは終了する。

【0039】

報告フェーズにおいて、ＭＭＥ／ＳＧＳＮ１０６がＩｏＴデバイスについて報告すべき状態情報を有する場合、ＭＭＥ／ＳＧＳＮ１０６はＳＣＥＦ１０２に通知する。図２において、通知は、報告フェーズのライン１で、ＭＭＥ／ＳＧＳＮ１０６からＳＣＥＦ１０２に、ダイアメータＲＩＲメッセージで送信される。ダイアメータＲＩＲメッセージは、要求された状態情報とＳＣＥＦ参照識別子を含む。ＳＣＥＦが、１回の報告の受信（１回の報告の場合）、サブスクリプション期間の満了、または指定された数の報告の受信（連続報告の場合）のいずれかにより、監視要求が失効したと判定した場合、ＳＣＥＦ１０２はＩｏＴデバイスの監視設定を削除する。

【0040】

メッセージフロー図の報告フェーズのライン２において、ＳＣＥＦ１０２は、ＩｏＴデバイスの状態をＳＣＳ／ＡＳ１００に伝達する。デバイスの状態情報は、Ｔ８インターフェイスまたは参照点を介してＳＣＳ／ＡＳ１００に伝達される。

【0041】

メッセージフロー図の報告フェーズのライン３において、ＳＣＳ／ＡＳ１００は、Ｔ８インターフェイスを介して、成功を示す原因コードと共に応答をＳＣＥＦ１０２に送信する。メッセージフロー図の報告フェーズのライン４において、ＳＣＥＦ１０２は、ダイアメータＲＩＡメッセージをＨＳＳに送信して、成功を示す。

【0042】

図１および図２に示される例では、Ｔ８インターフェイスおよび監視イベント設定手順は、４Ｇ ＩｏＴデバイスのＩｏＴデバイス状態を監視するための下流デバイス（すなわち、ＳＣＥＦ、ＨＳＳ、およびＭＭＥ／ＳＧＳＮ）を設定するために使用される。上述のように、Ｔ８インターフェイスおよび監視イベント設定手順は、２Ｇおよび３Ｇ ＩｏＴデバイスを含む非４Ｇ ＩｏＴデバイスのデバイス状態情報を監視および報告するために、下流デバイスを設定するためにも使用され得る。図３は、２Ｇおよび３Ｇ ＩｏＴデバイスの状態を監視および報告するために、下流のデバイスを設定するための、Ｔ８インターフェイスおよび監視イベント設定手順の使用を示すメッセージフロー図である。図３のメッセージフローは、１回の監視のためのものである。図３を参照すると、メッセージフロー図のライン１において、ＳＣＳ／ＡＳ１００は、Ｔ８インターフェイスを介して、ＳＣＥＦ１０２に監視サブスクリプション要求を送信する。この例では、要求は、１回の監視のためのものである。したがって、監視サブスクリプション要求における監視期間パラメータは０に設定されてもよく、または、報告数パラメータは１に設定されてもよい。

【0043】

メッセージフロー図のライン２において、ＳＣＥＦ１００は、監視サブスクリプション要求を検証し、監視サブスクリプション要求メッセージに含まれるデバイス識別子に基づいて、デバイスが２Ｇ／３Ｇ ＩｏＴデバイスであることを判定し、ホームロケーションレジスタ（ＨＬＲ）３００に、モバイルアプリケーションパート（ＭＡＰ : Mobile Application Part）エニタイムインテロゲーション（ＡＴＩ）要求メッセージを送信する。以下により詳細に説明するように、ＳＣＥＦ１０２は、２Ｇ／３Ｇ ＩｏＴデバイスのデバイス識別子のデータベースを保持してもよい。デバイス識別子は、ＭＳＩＳＤＮの範囲であってもよいし、２Ｇおよび３Ｇ ＩｏＴデバイスの状態情報を保持するＨＬＲまたはＨＬＲ／ＨＳＳにマッピングされた外部識別子のドメイン識別子であってもよい。ＳＣＥＦ１０２は、ＭＡＰ ＡＴＩ要求メッセージに、メッセージをＩｏＴデバイス状態情報サブスクリプション要求として識別し、要求されたサブスクリプションのタイプを識別する１つまたは複数の情報要素（ＩＥｓ : Information Elements）を挿入してもよい。ＳＣＥＦ１０２は、監視サブスクリプション要求で受信した監視イベントタイプに基づいて、監視イベントタイプを判定してもよい。以下の表は、監視イベントサブスクリプションタイプと、ＭＡＰ ＡＴＩ要求メッセージに含まれる可能性のある情報要素との間のマッピングを含む。

【0044】

【表1】

【0045】

表１から、監視イベントタイプが位置報告である場合、ＳＣＥＦ１０２は、１回の報告のためにＡＴＩ要求メッセージに位置情報要素を含め、連続報告のために現在位置情報要素を含めてもよい。ＳＣＳ／ＡＳがＵＥ到達性に関する通知を要求する場合、ＳＣＥＦ１０２は、ＭＡＰ ＡＴＩ要求メッセージにサブスクライバ状態ＩＥを含めてもよい。ＳＣＳ／ＡＳが、ＩＭＳＩ－ＩＭＥＩ関連の変更の通知を要求する場合、ＳＣＥＦ１０２は、ＡＴＩ要求メッセージにＩＭＥＩ情報要素を含めてもよい。ＳＣＳ／ＡＳから２Ｇ／３Ｇデバイスのために来る他の監視タイプは、適切なエラー原因により、ＳＣＥＦ１０２によって拒否されてもよい。

【0046】

メッセージフロー図のライン３において、ＨＬＲ３００は、２Ｇまたは３Ｇ ＩｏＴデバイス状態情報のサブスクリプションが成功したことを示すＭＡＰ ＡＴＩ確認（Ａｃｋ）メッセージをＳＣＥＦ１０２に送信することにより、ＡＴＩ要求に応答する。ライン４において、ＳＣＥＦ１０２は、作成されたｈｔｔｐ ｃａｕｓｅ ２０１と共に、監視イベントサブスクリプション応答をＳＣＳ／ＡＳ１００に送信する。ライン４の後、２Ｇまたは３Ｇ ＩｏＴデバイス状態を受信するための設定またはサブスクリプションフェーズが完了する。

【0047】

報告フェーズの間、メッセージフロー図のライン５において、ＳＣＥＦ１０２は、Ｔ８インターフェイスを介して、要求された監視情報と共に、監視イベントステータス通知をＳＣＳ／ＡＳ１００に送信する。メッセージフロー図のライン６において、ＳＣＳ／ＡＳ１００は、ＳＣＥＦ１０２に監視イベント状態通知応答を送信する。

【0048】

図３の例では、監視サブスクリプション要求は、１回の監視のためのものである。ＳＣＥＦ１０２は、２Ｇおよび３ＧのＩｏＴデバイスに関する状態情報の連続監視を提供してもよい。図４は、２Ｇおよび３ＧのＩｏＴデバイスに関する状態情報の連続監視のために、ＳＣＥＦ１０２によって実行される例示的なステップを示すメッセージフロー図である。図４を参照すると、ライン１において、ＳＣＳ／ＡＳ１００は、Ｔ８インターフェイスを介して、ＳＣＥＦ１０２に監視サブスクリプション要求を送信する。監視サブスクリプション要求は、０ではない監視継続時間パラメータ、または、１より大きい報告数パラメータを含むことができ、これらのいずれかは、ＩｏＴデバイスの連続監視を示す。

【0049】

メッセージフロー図のライン２において、ＳＣＥＦ１０２は、監視サブスクリプション要求メッセージを検証し、Ｔ８メッセージに含まれるターゲットＩｏＴデバイス識別子に基づいて、デバイスが２Ｇまたは３Ｇ ＩｏＴデバイスであると判定し、ＭＡＰ ＡＴＩ要求をＨＬＲ３００に送信する。上述のように、ＳＣＥＦ１０２は、２Ｇ／３Ｇ ＩｏＴデバイスのデバイス識別子および対応するＨＬＲアドレスのデータベースを含んでいてもよい。以下に示される表２は、ＳＣＥＦ１０２に存在する可能性のあるＩｏＴデバイス識別子データベースの一例である。

【0050】

【表2】

【0051】

表２は、ＩｏＴデバイス識別子および対応する２Ｇ／３Ｇ ＨＬＲアドレスのリストを含む。図示された例において、ＩｏＴデバイスは、ＭＳＩＳＤＮ番号の範囲と、ＩｏＴデバイス監視イベントサブスクリプション要求メッセージの外部識別子のドメイン部分とによって識別される。ＳＣＥＦ１０２が監視イベントサブスクリプション要求メッセージを受信すると、ＳＣＥＦ１０２は、メッセージからＩｏＴデバイス識別子を抽出し、ＩｏＴデバイス識別子データベースでルックアップを実行する。ＩｏＴデバイス識別子データベースがそのＩｏＴデバイス識別子を含んでいる場合、そのＩｏＴデバイスは２Ｇまたは３ＧのＩｏＴデバイスであると判定され、ＳＣＥＦ１０２は、データベースルックアップで特定されたＩｏＴデバイスに対応するＨＬＲに、サブスクリプション要求メッセージを送信する。ＩｏＴデバイス識別子がＩｏＴデバイス識別子データベース内に存在しない場合、ＩｏＴデバイスは４Ｇまたは５ＧのＩｏＴデバイスであると判定され、クエリは対応する４Ｇまたは５Ｇネットワークに送信される。ＳＣＥＦ１０２は、４Ｇおよび５ＧのＩｏＴデバイス識別子と、４Ｇまたは５ＧネットワークのＨＳＳ、ＭＭＥ、またはＳＧＳＮノードに対応するアドレスとの間のマッピングを保持してもよいことが理解される。

【0052】

また、表２のＩｏＴデバイスの識別子は、２Ｇまたは３Ｇネットワークに接続されている４Ｇまたは５ＧのＩｏＴデバイスを含み得ることも留意すべきである。ＩｏＴデバイスの状態情報更新をサブスクライブして受信するための図３および４に例示された手順は、ＡＴＩメッセージに応答する、ＨＬＲに情報が格納されている任意のＩｏＴデバイスに使用されることができる。また、図３と図４に例示されたＡＴＩ手順は、ＡＴＩメッセージに応答するＨＳＳまたはＨＬＲ／ＨＳＳの組み合わせから、ＩｏＴデバイスの状態情報をサブスクライブして取得するために使用され得ることに留意すべきである。

【0053】

図４に戻ると、監視サブスクリプション要求で受信された監視イベントタイプに基づいて、ＳＣＥＦ１０２は、表１に示されたマッピングに従い、要求された情報ＩＥをＭＡＰ ＡＴＩ要求に挿入する。例えば、連続位置監視の場合、ＭＡＰ ＡＴＩ ＩＥは現在の位置情報ＩＥを含むことができる。ＳＣＥＦ１０２が、ＳＣＳ／ＡＳ１００から受信した監視イベントタイプを認識しない場合、ＳＣＥＦ１０２は、エラー原因を示すエラーメッセージと共に、監視イベントサブスクリプションを拒否してもよい。

【0054】

メッセージフロー図のライン３において、ＨＬＲ３００は、（現在利用可能な場合）要求されたＩｏＴデバイス状態情報と共に、ＭＡＰ ＡＴＩ ＡｃｋをＳＣＥＦ１０２に送信する。メッセージフロー図のライン４において、ＳＣＥＦ１０２は、応答コード２０１と共に、監視イベントサブスクリプション応答をＳＣＳ／ＡＳ１００に送信する。

【0055】

メッセージフロー図のライン５において、ＳＣＥＦ１０２は、Ｔ８インターフェイスを介して、監視サブスクリプションが成功したことを示す監視イベントステータス通知をＳＣＳ／ＡＳ１００に送信する。メッセージフロー図のライン６において、ＳＣＳ／ＡＳ１００は、ＳＣＥＦ１０２に監視イベントステータス通知応答を送信する。

【0056】

この例では、連続監視を行う必要がある間隔を示すために、ＳＣＥＦ１０２に静的なタイマーが設定される。タイマーの満了ごとに、ＳＣＥＦ１０２はＨＬＲ３００にＭＡＰ ＡＴＩ要求を送信し、そのうちの１つはメッセージフロー図のライン７に示される。ＳＣＥＦ１０２は、要求されたサブスクリプション期間または報告数に達するまで、タイマーの静的に構成された値に基づいて、定期的な間隔でＨＬＲ３００にＡＴＩ要求メッセージを送信してもよい。一旦、要求されたサブスクリプション期間または報告数に達すると、ＳＣＥＦ１０２は、ＩｏＴデバイスに関するＡＴＩ要求メッセージの送信を停止してもよい。

【0057】

メッセージフロー図のライン８において、ＨＬＲ３００は、要求された監視情報と共に、ＭＡＰ ＡＴＩ ＡｃｋをＳＣＥＦ１０２に送信する。メッセージフロー図のライン９において、ＳＣＥＦ１０２は、Ｔ８インターフェイスを介して、要求された監視情報と共に、監視イベント状態通知をＳＣＳ／ＡＳ１００に送信する。ライン１０において、ＳＣＳ／ＡＳ１００は、監視イベント状態通知応答をＳＣＥＦ１０２に送信する。

【0058】

図５は、複数の異なる世代のネットワークのＩｏＴデバイスの状態情報を監視するための例示的なプロセスを示すフローチャートである。図５を参照すると、ステップ５００において、異なる世代のネットワークのＩｏＴデバイスの状態を監視するために、ＩｏＴアプリケーションサーバからサブスクリプション要求を受信するための共通インターフェイスがＳＣＥＦに提供される。例えば、図６を参照すると、ＳＣＥＦ１０２は、スタンドアロンのコンピューティングプラットフォームとして実現されてもよい。ＳＣＥＦ１０２は、ＩｏＴ ＳＣＳおよびＡＳからサブスクリプション要求を受信するための、図示される例ではＴ８インターフェイスである第１のインターフェイス６００を含む。サブスクリプション要求は、異なる世代のネットワークのＩｏＴデバイスのＩｏＴデバイス状態情報を要求してもよい。例えば、サブスクリプション要求は、図１および図２に図示された監視イベント手順を使用して、４Ｇまたは５ＧのＩｏＴデバイス状態情報を要求してもよい。他のサブスクリプション要求は、図３および４に図示された手順を使用して、２Ｇまたは３Ｇ ＩｏＴデバイスに関するＩｏＴデバイス状態情報を要求してもよい。ＩｏＴアプリケーションサーバおよびサービス能力サーバが、異なる世代のネットワークのＩｏＴデバイスのＩｏＴデバイス状態情報をサブスクライブおよび受信するための単一の共通インターフェイスを提供することで、アプリケーションサーバおよびサービス能力サーバは、ＩｏＴデバイス状態情報を要求するための複数の異なるインターフェイスタイプに準拠する必要がなくなる。

【0059】

ステップ５０２において、プロセスは、ＳＣＥＦにおいて、第１世代ネットワークのＩｏＴデバイスのＩｏＴデバイス識別子のデータベースを保持することを含む。一例では、第１世代ネットワークは、ＩｏＴデバイスの状態情報を含む２Ｇまたは３Ｇネットワークであってもよい。上記の表２は、保持され得るＩｏＴデバイス識別子データベースの例を示す。

【0060】

ステップ５０４において、プロセスは、共通インターフェイスを介して受信したサブスクリプション要求に応じて、第１世代および第２世代のネットワークからＩｏＴデバイス状態情報をそれぞれ収集するために、ＳＣＥＦにおいて、第１および第２のＩｏＴデバイス状態情報収集インターフェイスを提供することを含む。図６を参照すると、ＳＣＥＦ１０２は、ＨＬＲから２Ｇ／３Ｇ ＩｏＴデバイスのＩｏＴデバイス状態情報を収集するための２Ｇ／３Ｇ ＩｏＴデバイス状態情報収集インターフェイス６０４と、４Ｇおよび５G ＩｏＴデバイスに関する状態情報を収集するための４Ｇ／５Ｇ ＩｏＴデバイス状態情報収集インターフェイス６０６とを含む。２Ｇ／３Ｇ ＩｏＴデバイス状態情報収集インターフェイス６０４は、ＩｏＴデバイス状態を受信することをサブスクライブするためのＡＴＩメッセージを送信するための上述の手順を実現し得る。ＡＴＩメッセージは、ＳＳ７ネットワーク上で送信されるＭＡＰメッセージである。したがって、２Ｇ／３Ｇ ＩｏＴデバイス状態情報収集インターフェイス６０４は、ＭＡＰ層、トランザクション性能アプリケーション部（ＴＣＡＰ : Transaction Capabilities Application Part）層、シグナリング接続制御部（ＳＣＣＰ : Signaling Connection Control part）層、メッセージ転送部レベル３（ＭＴＰ３ : Message Transfer Part Level ３）層、およびＩＰまたはＳＳ７トランスポート層（Sigtran over IPまたはＳＳ７層１、２のいずれか）を実現するＳＳ７インターフェイスであってもよい。４Ｇ／５Ｇ ＩｏＴデバイス状態情報収集インターフェイス６０６は、ＨＳＳ、ＳＧＳＮ、またはＭＭＥ等のダイアメータノードから、ＩｏＴデバイス状態情報をサブスクライブおよび受信するための１つ以上のダイアメータ層を実現してもよい。ＳＣＥＦ１０２はまた、少なくとも１つのプロセッサ６０７およびメモリ６０８を含む。

【0061】

図６に示す例において、ＳＣＥＦ１０２は、スタンドアロンコンポーネントである。スタンドアロンＳＣＥＦは、ＭＴＣデバイスのインターワーキング機能だけでなく、ＳＣＳおよびＡＳの機能に加えて、ＳＣＥＦの機能を含んでもよい。別の実施において、ＳＣＥＦ１０２は、ダイアメータシグナリングルータ（ＤＳＲ：Diameter Signaling Router）のコンポーネントとして実現されてもよい。図７は、そのような実施例を示している。図７において、ＤＳＲ７００は、複数のメッセージプロセッサ７０２、７０４、７０６および７０８を含む。各メッセージプロセッサ７０２、７０４、７０６および７０８は、プリント回路基板と、プリント回路基板に搭載された少なくとも１つのプロセッサ７１０およびメモリ７１２とを含む。メッセージプロセッサ７０２、７０４、７０６および７０８は、イーサネットバックプレーン等の通信媒体７１４を介して、メッセージを交換してもよい。

【0062】

図示の例において、メッセージプロセッサ７０２は、ダイアメータ接続層７１６と、ダイアメータルーティング層７１８とを実現している。ダイアメータ接続層７１６は、ピアのダイアメータノードと、ダイアメータ接続を確立して維持する。ダイアメータルーティング層７１８は、メッセージに含まれる宛先ホストおよび宛先レルムパラメータ等のダイアメータ層の情報に基づいて、ダイアメータメッセージをルーティングする。

【0063】

メッセージプロセッサ７０４は、ＳＳ７通信を実現する。このように、メッセージプロセッサ７０４は、シグトラン（Sigtran）層７２０とＳＳ７層７２２とを含む。シグトラン層７２０は、ＩＰネットワーク上でＳＳ７メッセージを運ぶためのシグトランプロトコルを実現する。ＳＳ７層７２２は、ＳＳ７のポイントコードに基づいてＳＳ７シグナリングメッセージをルーティングするためのＳＳ７ ＭＴＰレベル３を実現する。

【0064】

メッセージプロセッサ７０６は、ＳＣＥＦ１０２を実現し、図６に示されるコンポーネントを含んでいる。このように、２Ｇまたは３ＧネットワークからＩｏＴデバイス状態情報を取得するために、ＳＣＥＦ１０２は、ＳＳ７メッセージプロセッサ７０４を介して、アウトバウンドサブスクリプション要求を送信し、ＳＳ７メッセージプロセッサ７０４からサブスクリプション情報を受信してもよい。４Ｇおよび５ＧのＩｏＴデバイス状態情報については、ＳＣＥＦ１０２は、ＳＣＥＦ１０２への直接的なＡＰＩベースのインターフェイス等、非ダイアメータインターフェイスを介して、サブスクリプション要求を送信してもよい。

【0065】

メッセージプロセッサ７０８は、ダイアメータアプリケーション７２４を実現する。ダイアメータアプリケーション７２４は、ダイアメータファイアウォールアプリケーション、パフォーマンス監視アプリケーション、またはその他の適切なダイアメータアプリケーション等、任意の適切なダイアメータアプリケーションであってよい。

【0066】

図７に示される例において、ＳＣＥＦ１０２はＤＳＲ７００のコンポーネントである。さらに別の代替の実現例において、ＳＣＥＦ１０２は、ポリシーマネージャのコンポーネントであってもよい。図８は、そのような実現例を示している。図８において、ポリシーマネージャ８００は、図７に図示されているように、メッセージプロセッサ７０２、７０４、７０６および７０８を含む。各メッセージプロセッサ７０２、７０４、７０６および７０８は、プロセッサ７１０およびメモリ７１２を含む。メッセージプロセッサ７０２、７０４、７０６および７０８は、通信媒体７１４を介して通信することができる。しかしながら、ダイアメータルーティングまたはダイアメータルーティングのみを実現するのではなく、図８に例示されたメッセージプロセッサ７０２は、ＰＣＲＦ機能を実現するポリシーおよび課金ルール機能（ＰＣＲＦ : Policy and Charging Rules Function）８０２を含む。ＰＣＲＦ機能は、ダイアメータノードからのポリシーおよび課金要求への応答を含む。また、メッセージプロセッサ７０２は、外部のダイアメータノードとの接続を確立および維持するためのダイアメータ接続層７１６を実現している。

【0067】

メッセージプロセッサ７０４は、図６に図示されるＳＣＥＦ機能を実現する。簡単に説明すると、そのような機能は、Ｔ８インターフェイス等の共通インターフェイスを介して、ＩｏＴデバイスの状態情報のサブスクリプション要求を受信することと、対応するサブスクリプション要求をＨＬＲおよびＨＳＳに送信することとを含む。メッセージプロセッサ７０６および７０８は、ポリシー関連のアプリケーションや非ポリシー関連のダイアメータアプリケーション等、他のダイアメータアプリケーションを実現してもよい。

【0068】

このように、複数の世代のＩｏＴデバイスの状態を監視するための共通インターフェイスを提供するＳＣＥＦは、スタンドアロンのノードとしても、ＤＳＲやＰＣＲＦ等の別のノードのコンポーネントとしても実現され得る。このようなＳＣＥＦは、異なる世代のネットワークのＩｏＴデバイスのＩｏＴデバイス状態情報を監視するための専用のインターフェイスを提供することを必要としない。このような装置は、ＳＣＳやＡＳのベンダーが、異なる世代のネットワークのＩｏＴデバイスを監視するための異なるインターフェイスの要件に準拠することを要求されないため、ＩｏＴデバイスの状態監視の技術分野を向上させる。

【0069】

本開示の主題の範囲から逸脱することなく、本開示の主題の様々な詳細を変更することができることろう。さらに、上記の説明は例示のみを目的としたものであり、限定を目的としたものではない。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】