▶ マイクロソフト テクノロジー ライセンシング，エルエルシーの特許一覧
特許7178365サービス能力公開機能（ＳＣＥＦ）ベースのインターネットオブシングス（ＩＯＴ）通信の方法とシステム
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2022-11-16
(45)【発行日】2022-11-25
(54)【発明の名称】サービス能力公開機能（ＳＣＥＦ）ベースのインターネットオブシングス（ＩＯＴ）通信の方法とシステム
(51)【国際特許分類】
H04W 12/08 20210101AFI20221117BHJP
H04W 12/069 20210101ALI20221117BHJP
H04W 88/16 20090101ALI20221117BHJP
H04W 4/14 20090101ALI20221117BHJP
H04W 52/02 20090101ALI20221117BHJP
【ＦＩ】
H04W12/08
H04W12/069
H04W88/16
H04W4/14
H04W52/02 111
【請求項の数】
4
(21)【出願番号】P 2019560165
(86)(22)【出願日】2018-05-07
(65)【公表番号】
(43)【公表日】2020-06-25
(86)【国際出願番号】 US2018031423
(87)【国際公開番号】W WO2018204924
(87)【国際公開日】2018-11-08
【審査請求日】2021-05-06
(31)【優先権主張番号】62/502,070
(32)【優先日】2017-05-05
(33)【優先権主張国・地域又は機関】US
(73)【特許権者】
【識別番号】314015767
【氏名又は名称】マイクロソフト テクノロジー ライセンシング，エルエルシー
(74)【代理人】
【識別番号】100118902
【弁理士】
【氏名又は名称】山本 修
(74)【代理人】
【識別番号】100106208
【弁理士】
【氏名又は名称】宮前 徹
(74)【代理人】
【識別番号】100120112
【氏名又は名称】中西 基晴
(74)【代理人】
【識別番号】100173565
【弁理士】
【氏名又は名称】末松 亮太
(72)【発明者】
【氏名】パルナティ，プラサス
(72)【発明者】
【氏名】クリシャナマーシー，アナンド
(72)【発明者】
【氏名】カップラ，スリニヴァス
(72)【発明者】
【氏名】ガーグ，ディーパック
(72)【発明者】
【氏名】ダス，サントス，クマール
【審査官】石原 由晴
(56)【参考文献】
【文献】国際公開第２０１７／００４１５８（ＷＯ，Ａ１）
【文献】国際公開第２０１７／２１９９７３（ＷＯ，Ａ１）
【文献】国際公開第２０１６／０７２８１４（ＷＯ，Ａ１）
【文献】国際公開第２０１６／１９０６７２（ＷＯ，Ａ１）
【文献】米国特許出願公開第２０１８／００４９１５６（ＵＳ，Ａ１）
【文献】国際公開第２０１７／１２４８３８（ＷＯ，Ａ１）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｈ０４Ｂ ７／２４－７／２６
Ｈ０４Ｗ ４／００－９９／００
３ＧＰＰ ＴＳＧ ＲＡＮ ＷＧ１－４
ＳＡ ＷＧ１－４
ＣＴ ＷＧ１、４
(57)【特許請求の範囲】
【請求項1】
方法であって、
拡張サービス能力公開機能（Ａ－ＳＣＥＦ）によって、アプリケーションサーバ（ＡＳ）からコマンドメッセージを受信するステップであって、前記コマンドメッセージが、外部識別タグと、前記外部識別タグに関連付けられたアプリケーションプログラミングインターフェース（ＡＰＩ）命令と、セキュリティ証明書と、を含む、ステップと、
前記セキュリティ証明書が前記外部識別タグに対して認可されていることを確認するステップと、
前記確認するステップに応答して、前記Ａ－ＳＣＥＦによって、第１の電子的に検索可能なカタログ内に、前記外部識別タグに関連付けられた少なくとも１つのネットワーク識別子を位置付けるステップであって、前記少なくとも１つのネットワーク識別子が、前記外部識別タグとは異なる、ステップと、
前記Ａ－ＳＣＥＦによって、選択階層に少なくとも部分的に基づいて、少なくとも２つのデータ接続経路から少なくとも１つのユーザ機器（ＵＥ）へのデータ接続経路を選択するステップと、
前記ＡＰＩ命令が転送データ命令である場合に、前記転送データ命令に応答して、前記ＡＳまたは前記ＵＥの少なくとも１つに関連付けられたポリシープロファイルにおいて、転送データポリシー設定を識別するステップであって、前記転送データポリシー設定が、
アクティブプル設定、
ストアアンドフォワード設定、
データレート設定、
メモリ割り当て設定、または
優先度設定
のうちの少なくとも１つである、
ステップと、
前記Ａ－ＳＣＥＦによって、前記ＡＰＩ命令に基づいて、前記少なくとも１つのネットワーク識別子に関連付けられた前記少なくとも１つのＵＥに通信を送信するステップであって、前記通信が、選択された前記データ接続経路を介して送信されており、
前記Ａ－ＳＣＥＦによって前記少なくとも１つのＵＥに前記通信を前記送信するステップが、前記Ａ－ＳＣＥＦによって、前記転送データポリシー設定に基づいて、ある時間間隔で、あるレートで、または、前記ＵＥと前記Ａ－ＳＣＥＦとの間もしくは前記ＡＳと前記Ａ－ＳＣＥＦとの間の他の通信後に、のうちの少なくとも１つにおいて前記通信を送信することのうちの少なくとも１つを含む、ステップと、
前記コマンドメッセージが返信間隔を含む場合に、
前記Ａ－ＳＣＥＦによって、前記ネットワーク識別子に関連付けられた前記ＵＥから、データを含む少なくとも1つの更新メッセージを受信するステップと、
前記Ａ－ＳＣＥＦによって、前記第１の電子的に検索可能なカタログ内に、前記ネットワーク識別子に関連付けられた前記外部識別タグを位置付けるステップと、
前記Ａ－ＳＣＥＦによって、前記返信間隔に従って、前記ＡＳへ返信メッセージを送信するステップであって、前記返信メッセージが、
前記外部識別タグ、および
前記ネットワーク識別子に関連付けられた前記ＵＥから受信した前記データ
を含む、ステップと、
を含む、方法。
【請求項2】
方法であって、
拡張サービス能力公開機能（Ａ－ＳＣＥＦ）によって、アプリケーションサーバ（ＡＳ）からコマンドメッセージを受信するステップであって、前記コマンドメッセージが、外部識別タグと、前記外部識別タグに関連付けられたアプリケーションプログラミングインターフェース（ＡＰＩ）命令と、セキュリティ証明書と、を含む、ステップと、
前記セキュリティ証明書が前記外部識別タグに対して認可されていることを確認するステップと、
前記確認するステップに応答して、前記Ａ－ＳＣＥＦによって、第１の電子的に検索可能なカタログ内に、前記外部識別タグに関連付けられた少なくとも１つのネットワーク識別子を位置付けるステップであって、前記少なくとも１つのネットワーク識別子が、前記外部識別タグとは異なる、ステップと、
前記Ａ－ＳＣＥＦによって、選択階層に少なくとも部分的に基づいて、少なくとも２つのデータ接続経路から少なくとも１つのユーザ機器（ＵＥ）へのデータ接続経路を選択するステップと、
前記Ａ－ＳＣＥＦによって、前記ＡＰＩ命令に基づいて、前記少なくとも１つのネットワーク識別子に関連付けられた前記少なくとも１つのＵＥに通信を送信するステップであって、前記通信が、選択された前記データ接続経路を介して送信されている、ステップと、
を含み、
前記Ａ－ＳＣＥＦが、デバイスゲートウェイ機能（ＤＧ）および複数のサービス能力公開機能（ＳＣＥＦ）を含み、
前記少なくとも１つのネットワーク識別子を前記位置付けるステップが、前記ＤＧによるものであり、
前記Ａ－ＳＣＥＦによって、前記少なくとも１つのＵＥに前記通信を前記送信するステップが、
前記ＤＧが、前記複数のＳＣＥＦの中から前記ＵＥに関連付けられたアクティブＳＣＥＦを選択することと、
前記ＤＧが、前記選択されたＳＣＥＦへの前記ＡＰＩ命令に基づいて、前記ネットワーク識別子および情報を送信することと、
を含む、方法。
【請求項3】
方法であって、
拡張サービス能力公開機能（Ａ－ＳＣＥＦ）によって、アプリケーションサーバ（ＡＳ）からコマンドメッセージを受信するステップであって、前記コマンドメッセージが、外部識別タグと、前記外部識別タグに関連付けられたアプリケーションプログラミングインターフェース（ＡＰＩ）命令と、セキュリティ証明書と、を含む、ステップと、
前記セキュリティ証明書が前記外部識別タグに対して認可されていることを確認するステップと、
前記確認するステップに応答して、前記Ａ－ＳＣＥＦによって、第１の電子的に検索可能なカタログ内に、前記外部識別タグに関連付けられた少なくとも１つのネットワーク識別子を位置付けるステップであって、前記少なくとも１つのネットワーク識別子が、前記外部識別タグとは異なる、ステップと、
前記Ａ－ＳＣＥＦによって、選択階層に少なくとも部分的に基づいて、少なくとも２つのデータ接続経路から少なくとも１つのユーザ機器（ＵＥ）へのデータ接続経路を選択するステップと、
前記Ａ－ＳＣＥＦによって、前記ＡＰＩ命令に基づいて、前記少なくとも１つのネットワーク識別子に関連付けられた前記少なくとも１つのＵＥに通信を送信するステップであって、前記通信が、選択された前記データ接続経路を介して送信されている、ステップと、
を含み、
前記Ａ－ＳＣＥＦが、デバイスゲートウェイ機能（ＤＧ）およびサービス能力公開機能（ＳＣＥＦ）を含み、
前記少なくとも１つのネットワーク識別子を前記位置付けるステップが、前記ＤＧによるものであり、
前記Ａ－ＳＣＥＦによって、前記少なくとも１つのＵＥに前記通信を前記送信するステップが、前記ＤＧが前記ＳＣＥＦへの前記ＡＰＩ命令に基づいて、前記ネットワーク識別子および情報を送信することを含む、方法。
【請求項4】
前記受信するステップが前記ＤＧによるものであり、前記受信するステップが、完全修飾ドメイン名（ＦＱＤＮ）を介して受信することを含む、請求項３に記載の方法。
【発明の詳細な説明】
【技術分野】
【0001】
関連出願の相互参照
本出願は、米国特許法１１９条（ｅ）に基づいて、「ＭＥＴＨＯＤＳ ＯＦ ＡＮＤ ＳＹＳＴＥＭＳ ＯＦ ＳＥＲＶＩＣＥ ＣＡＰＡＢＩＬＩＴＩＥＳ ＥＸＰＯＳＵＲＥ ＦＵＮＣＴＩＯＮ（ＳＣＥＦ） ＢＡＳＥＤ ＩＮＴＥＲＮＥＴ－ＯＦ－ＴＨＩＮＧＳ（ＩＯＴ） ＣＯＭＭＵＮＩＣＡＴＩＯＮＳ」と題する２０１７年５月５日に出願された米国仮特許出願第６２／５０２，０７０号の利益を主張し、その内容は参照により本明細書に組み込まれる。
本出願は、米国特許法１１９条（ｅ）に基づいて、「ＭＥＴＨＯＤＳ ＯＦ ＡＮＤ ＳＹＳＴＥＭＳ ＯＦ ＳＥＲＶＩＣＥ ＣＡＰＡＢＩＬＩＴＩＥＳ ＥＸＰＯＳＵＲＥ ＦＵＮＣＴＩＯＮ（ＳＣＥＦ） ＢＡＳＥＤ ＩＮＴＥＲＮＥＴ－ＯＦ－ＴＨＩＮＧＳ（ＩＯＴ） ＣＯＭＭＵＮＩＣＡＴＩＯＮＳ」と題する２０１７年５月５日に出願された米国仮特許出願第６２／５０２，０７０号の利益を主張し、その内容は参照により本明細書に組み込まれる。
【0002】
本発明は、概して、通信ネットワークに関し、特に、パケットデータネットワーク（「ＰＤＮ」）アーキテクチャに関する。
【背景技術】
【0003】
第３世代のパートナーシッププロジェクト（「３ＧＰＰ」）は、標準文書２３．６８２「パケットデータネットワーク（「ＰＤＮ」）およびアプリケーションとの通信を容易にするためのアーキテクチャの強化」でサービス能力公開機能（「ＳＣＥＦ」）を定義している。ＳＣＥＦは、移動するデータと制御プレーンアクションの両方のパスを定義し、すべての通信プロトコルを知らなくても、外部アプリケーションサーバが様々なネットワーク機能と通信できるようにする。
【発明の概要】
【0004】
本明細書では、ｅＮｏｄｅＢ固有の相対容量割り当てを実装するためのシステムおよび方法を開示する。いくつかの実施形態では、拡張ＳＣＥＦ（Ａ－ＳＣＥＦ）は、アプリケーションサーバ（ＡＳ）からコマンドメッセージを受信することができる。コマンドメッセージは、外部識別タグ、外部識別タグに関連付けられたアプリケーションプログラミングインターフェース（ＡＰＩ）命令、およびセキュリティ証明書を含むことができる。次に、Ａ－ＳＣＥＦは、セキュリティ証明書が外部識別タグに対して認可されていることを確認し、確認することに応答して、Ａ－ＳＣＥＦ上またはＡ－ＳＣＥＦに接続された第１の電子的に検索可能なカタログ内に、外部識別タグに関連付けられた少なくとも１つのネットワーク識別子を位置付ける（設定する）ことができる。少なくとも１つのネットワーク識別子は、外部識別タグと異なっていてもよい。Ａ－ＳＣＥＦは、アプリケーションプログラマインターフェース（ＡＰＩ）命令に基づいて、少なくとも１つのネットワーク識別子に関連付けられた少なくとも１つのユーザ機器（ＵＥ）に通信を送信する（通信を行う）ことができる。
【0005】
いくつかの実施形態では、Ａ－ＳＣＥＦはＡＳからのコマンドメッセージを受信することができる。コマンドメッセージは、外部識別タグ、外部識別タグに関連付けられたＡＰＩ命令、およびＡＳに関連付けられたエンティティに関連するセキュリティ証明書を含むことができる。Ａ－ＳＣＥＦは、セキュリティ証明書が外部識別タグに対して認可されていることを確認し、確認することに応答して、ＡＰＩ命令に基づいてＡＳに通信を送信することができる。
【0006】
いくつかの実施形態では、Ａ－ＳＣＥＦは、ポリシープロファイルを少なくとも１つのＡＳに関連付けることができる。ポリシープロファイルは、ネットワークトラフィック管理、課金、および通知のうちの少なくとも１つを統治することができる。Ａ－ＳＣＥＦは、少なくとも１つのＡＳからコマンドメッセージを受信することができる。コマンドメッセージは、外部識別タグおよび外部識別タグに関連付けられたＡＰＩ命令を含むことができる。次いで、Ａ－ＳＣＥＦは、電子的に検索可能なカタログ内に、外部識別タグに関連付けられた少なくとも１つのネットワーク識別子を位置付けることができ、少なくとも１つのネットワーク識別子は、外部識別タグとは異なる。次いで、Ａ－ＳＣＥＦは、ポリシープロファイルに従って、ＡＰＩに基づいて少なくとも１つのネットワーク識別子に関連付けられた少なくとも１つのＵＥに通信を送信することを促進することができる。
【0007】
いくつかの実施形態では、Ａ－ＳＣＥＦは、ポリシープロファイルを少なくとも１つのＡＳに関連付けることができる。ポリシープロファイルは、ネットワークトラフィック管理、課金、および通知のうちの少なくとも１つを統治することができる。次いで、Ａ－ＳＣＥＦは、外部識別タグ、および外部識別タグに関連付けられたＡＰＩ命令を含むコマンドメッセージをＡＳから受信することができる。次いで、Ａ－ＳＣＥＦは、電子的に検索可能なカタログ内に、外部識別タグに関連付けられた少なくとも１つのネットワーク識別子を位置付けることができ、少なくとも１つのネットワーク識別子は、外部識別タグとは異なる。次いで、Ａ－ＳＣＥＦは、少なくとも１つのポリシープロファイルに従って、少なくとも１つのＡＳに少なくとも１つの通信を送信することができる。そのメッセージには、ＡＰＩ命令に基づく外部識別タグおよび情報が含まれてもよい。
【0008】
いくつかの実施形態では、Ａ－ＳＣＥＦは、ポリシープロファイルを少なくとも１つのＡＳに関連付けることができる。ポリシープロファイルは、課金および通知のうちの少なくとも１つを統治できる。Ａ－ＳＣＥＦは、ＵＥのネットワーク識別子およびデータを含むＵＥからの通信を受信することができる。Ａ－ＳＣＥＦは、第１の電子的に検索可能なカタログ内に、ネットワーク識別子に関連付けられた少なくとも１つの外部識別タグを位置付けることができ、少なくとも１つのネットワーク識別子は、外部識別タグとは異なる。次いで、Ａ－ＳＣＥＦは、第２の電子的に検索可能なカタログ内に、ネットワーク識別子、外部識別タグ、またはデータの少なくとも１つに関連付けられた少なくとも１つのポリシープロファイルを位置付けることができる。次いで、Ａ－ＳＣＥＦは、外部識別タグまたはデータの少なくとも１つに基づいて少なくとも１つのＡＳを識別し、少なくとも１つのポリシープロファイルに従って、少なくとも１つのメッセージを識別された少なくとも１つのＡＳに送信することができ、メッセージは、データに基づく外部識別タグおよび情報を含む。
【0009】
いくつかの実施形態では、Ａ－ＳＣＥＦは、セキュリティ証明書を少なくとも１つのＵＥに関連付けることができ、セキュリティ証明書は、ＡＳ、少なくとも１つのＡＳに関連付けられたテナント、または少なくとも１つのテナントに関連付けられた事業者のうちの少なくとも１つにデータを送信する少なくとも１つのＵＥを認可する。Ａ－ＳＣＥＦはまた、ＵＥのネットワーク識別子およびデータを含む通信をＵＥから受信することができる。Ａ－ＳＣＥＦは、データベースで、ＡＳ、テナント、または事業者の少なくとも１つにデータを送信するＡＰＩ命令を識別できる。Ａ－ＳＣＥＦは、ＵＥに関連付けられたセキュリティ証明書が、ＡＳ、テナント、または事業者のうちの少なくとも１つに対して認可されていることを確認することができる。確認することに応答して、Ａ－ＳＣＥＦは、ＡＰＩ命令に基づいて、ＡＳ、テナントに関連付けられたＡＳ、または事業者に関連付けられたテナントに関連付けられたＡＳに通信を送信することができる。
【0010】
上記および本明細書で説明した様々な実施形態は、ステップまたは要素を追加のリストされたステップまたは要素で置換および追加することを含む様々な方法で組み合わせることができる。
【0011】
開示された主題のこれらの能力および他の能力は、以下の図、詳細な説明、および特許請求の範囲を検討した後により完全に理解されるであろう。本明細書で使用される語法および用語は説明を目的とするものであり、限定とみなされるべきではないことを理解されたい。
【0012】
開示された主題の様々な実施形態のより完全な理解のために、参照は、今ここで、添付の図面と関連してなされる以下の説明に言及する。
【図面の簡単な説明】
【0013】
【図1】開示された主題のいくつかの実施形態による、ＳＣＥＦに対するノースバウンドおよびサウスバウンドインターフェースを示すブロック図である。
【図2】開示された主題のいくつかの実施形態による、ＳＣＥＦベースＩＯＴ通信システムの「直接モデル」実装形態を例解する。
【図3】開示された主題のいくつかの実施形態による、ＳＣＥＦベースＩＯＴ通信システムの「間接モデル」実装形態を例解する。
【図4】開示された主題のいくつかの実施形態による、ＳＣＥＦベースＩＯＴ通信システムのコンポーネントを示すブロック図である。
【図5】開示された主題のいくつかの実施形態による、アプリケーションサーバ（「ＡＳ」）とホーム加入者サーバ（「ＨＳＳ」）との間の例示的な呼び出しフローを例解する。
【図6】開示された主題のいくつかの実施形態による、デバイス取り付けフローを例解する。
【図7】開示された主題のいくつかの実施形態による、デバイス発信データ呼び出しフローを例解する。
【図8】開示された主題のいくつかの実施形態による、モバイル終端メッセージデータの配信を例解する。
【図9】開示された主題のいくつかの実施形態による、デバイス取り外しフローを例解する。
【図10】開示された主題のいくつかの実施形態によるローミングシナリオを例解する。
【図11】開示された主題のいくつかの実施形態による、アドミッション制御機能と、ＣＳＧＮインターフェースごとのキューイングおよびスケジューリングブロックの強調表示したＴｘトラフィック管理機能の高レベルブロック図である。
【図12】開示された主題のいくつかの実施形態による、３ＧＰＰマシンタイプ通信（「ＭＴＣ」）参照アーキテクチャのブロック図である。
【図13】開示された主題のいくつかの実施形態による、（Ｓ）Ｇｉを介したインターネットプロトコル（「ＩＰ」）および非ＩＰメッセージの配信を示すブロック図である。
【図14】開示された主題のいくつかの実施形態による、マシンプロトコル通信インターワーキング機能（「ＭＴＣ－ＩＷＦ」）を介したインターネットプロトコルショートメッセージサービス（「ＳＭＳ」）メッセージ配信を示すブロック図である。
【図15】開示された主題のいくつかの実施形態による、ＳＣＥＦを介した非ＩＰメッセージ配信を示すブロック図である。
【図16】２３．６８２仕様からのサービス能力公開機能（「ＳＣＥＦ」）のブロック図の再現である。
【図17】開示された主題のいくつかの実施形態による、デバイスゲートウェイ（「ＤＧ」）およびサービス能力公開機能（「ＳＣＥＦ」）インターフェースを示すＳＣＥＦベースＩＯＴ通信システムのブロック図である。
【図18】開示された主題のいくつかの実施形態による、ＳＣＥＦベースＩＯＴ通信システム展開モデルのブロック図である。
【図19】は、標準文書２３．６８２「パケットデータネットワーク（「ＰＤＮ」）およびアプリケーションとの通信を促進するためのアーキテクチャの強化」からの第３世代パートナーシッププロジェクト（「３ＧＰＰ」）定義のＳＣＥＦ機能のブロック図である。
【図20】開示された主題のいくつかの実施形態による、ＩＯＴサービスプラットフォーム（「ＩＯＴＳＰ」）の機能ブロックの高レベル図を例解する。
【図21】開示された主題のいくつかの実施形態による、様々なエンティティの階層およびそれらに関連付けられたプロファイルを例解する。
【図22】開示された主題のいくつかの実施形態による、Ａ－ＳＣＥＦの基本的な接続性を例解する。
【図23A】開示された主題のいくつかの実施形態による、Ａ－ＳＣＥＦの様々な展開を例解する。
【図23B】開示された主題のいくつかの実施形態による、Ａ－ＳＣＥＦの様々な展開を例解する。
【図23C】開示された主題のいくつかの実施形態による、Ａ－ＳＣＥＦの様々な展開を例解する。
【図23D】開示された主題のいくつかの実施形態による、Ａ－ＳＣＥＦの様々な展開を例解する。
【発明を実施するための形態】
【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】
図２は、１つの可能な展開モデル（本明細書では「直接モデル」と称される）を示しており、Ａ－ＳＣＥＦ２０２の動作の前提は、Ａ－ＳＣＥＦ２０２の一部が信頼されていないドメインにあるＡＳノードと対話することであり（例えば、ノースバウンドＡＰＩはインターネット経由で呼び出される）、また、事業者ＡＳは、インターネット上のノースバウンドＡＰＩを使用してＡ－ＳＣＥＦと直接対話する。また、オペレータ（例えば、ＡＴ＆Ｔ）ホストするプラットフォーム２１０Ｄも示されており、そこでは、オペレータが信頼するＡＳがＮＢＩＯＴデバイスと通信する。前述したように、ＩＯＴＳＰはそのようなプラットフォームの一例である。図２に示すように、 ＡＳ２１０Ａおよび２１０Ｂ（事業者１に関連付けられている）およびＡＳ２１０Ｃ（事業者２に関連付けられている）は、「信頼されていないドメイン」内にあり、管理ポータル２２０およびＡＳ２１０Ｄ（ホスト型プラットフォームに関連付けられている）は、「信頼されたドメイン」内にある。Ａ－ＳＣＥＦ２０２は部分的に信頼されたドメイン内に、部分的に信頼されていないドメイン内に存在し、両方のドメインの素子と対話する。
【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】
ＩＯＴサービスプラットフォーム（「ＩＯＴＳＰ」）
ＩＯＴＳＰを使用すると、サービスプロバイダは、統合されたＩＰ、非ＩＰ、およびＳＭＳ配信を備えた３ＧＰＰ ＩＯＴデバイス用の完全なエンドツーエンドソリューションを迅速に展開できる。ＩＯＴＳＰは、デバイス管理、分析、課金、証明書プロファイルの管理および他の機能を提供する。さらに、サービスプロバイダは、ＩＯＴＳＰのサポートされている特定の機能のみを展開し、代わりに既に展開されている既存の機能と統合することを選択できる。
ＩＯＴＳＰを使用すると、サービスプロバイダは、統合されたＩＰ、非ＩＰ、およびＳＭＳ配信を備えた３ＧＰＰ ＩＯＴデバイス用の完全なエンドツーエンドソリューションを迅速に展開できる。ＩＯＴＳＰは、デバイス管理、分析、課金、証明書プロファイルの管理および他の機能を提供する。さらに、サービスプロバイダは、ＩＯＴＳＰのサポートされている特定の機能のみを展開し、代わりに既に展開されている既存の機能と統合することを選択できる。
【0133】
ＩＳＰのソリューションは、２つの主要顧客のモデルをサポートするように設定することができる。
【0134】
直接－直接モデルでは、ＩｏＴの顧客はＩｏＴデバイスから抽出されたデータを収集、保存、分析する知識と能力を有していると想定される場合がある。
【0135】
ホスト型－ホスト型モデルでは、ＩｏＴの顧客は、データ収集、ストレージ、および分析の機能をオペレータにアウトソーシングすることを望む場合がある。
【0136】
図１７は、開示された主題のいくつかの実施形態によるＤＧ（１７６０Ａ、１７６０Ｂ）および３ＧＰＰ－ＳＣＥＦ－Ｅ（１７０２）インターフェースを示すＳＣＥＦベースＩＯＴ通信システム（１７００）のブロック図である。ＤＧ１７６０Ａと１つ以上のオプションのサードパーティＤＧ／ＳＣＳまたはＡＳノード（１７６０Ｂ）の両方は、 ＲＥＳＴ ＡＰＩ（それぞれ１７５４Ａおよび１７５４Ｃ）を介して３ＧＰＰ－ＳＣＥＦ－Ｅ（１７０２）とインターフェースする。ＤＧ１７６０Ａは、ＲＥＳＴ ＡＰＩ１７５４Ｂを介して１つ以上のＡＳノードと同様に、ＳＧｉ（１７９２）を介して１つ以上のＵＥ（ｅＮｏｄｅＢ１７７０など）と直接インターフェースするようにも構成されている。３ＧＰＰ－ＳＣＥＦ－Ｅ１７０２は、Ｓ６ｔ（１７５３）および／またはＳ６ｎ／ｍ（１７５０）インターフェースを介してＨＳＳ１７３４とインターフェースするように構成されており、かつ、Ｔ６ａインターフェース（１７４４）を介してＭＭＥ／ＣＩｏＴサービングゲートウェイノード（「Ｃ－ＳＧＮ」）／サービングＧＰＲＳサポートノード（「ＳＧＳＮ」）（１７１８）とインターフェースするように構成されている。ＭＭＥ／Ｃ－ＳＧＮ／ＳＧＳＮ（１７１８）は、ｅＮＢ１７７０と直接通信している。図２０に示すように、Ａ－ＳＣＥＦ機能をＩＯＴＳＰに統合して、ホスト型展開モデルのサポートを最適化できる。Ａ－ＳＣＥＦがこのようなホスト型ソリューションに統合されると、多くの最適化が可能になる。そのような可能性のいくつかは、次のとおりである。
【0137】
セキュリティの最適化：ＡＳ（例えば、この場合はＩＯＴＳＰ）は、信頼されたドメインにあるため、Ａ－ＳＣＥＦは、非常に堅牢なセキュリティ機能を提供する必要はない。例えば、証明書管理は、ＩＯＴＳＰの一部とすることができる。
【0138】
統合分析：Ａ－ＳＣＥＦとＩＯＴＳＰプラットフォームは対話して、より深い分析のループを閉じることができる。デバイスごと／事業者レベルの洞察には、ＩＯＴＳＰとＡ－ＳＣＥＦが提供するトランスポートの両方からのメトリックが組み込まれる場合がある。例えば、ＩＯＴＳＰがＵＥへのデータ転送を開始し、ＵＥが現在到達不能であるためＤＧ＋３ＧＰＰ－ＳＣＥＦ－Ｅがデータをバッファリングする必要があると仮定する。その後、ＵＥが使用可能になると、データが配信される。１つのメトリックは、デバイス／事業者レベルごとにこれが発生する頻度を理解することである。例えば、これがすべてのＵＥで頻繁に発生する場合は、ＵＥのパラメータを更新して、より頻繁に起動する必要がある可能性がある。ＭＴＣ－ＩＷＦ機能にはＴｓｐベースの入力があり、ＨＳＳとのＳ６ｍインターフェースおよびＳＭＳ－ＳＣとのＴ４インターフェースを使用して、デバイストリガー機能を実装する。デバイストリガー機能は、ＳＭＳを介してデバイスを起動し、関連するアプリケーションへの接続を要求する。代替的に、または加えて、そのような遅延が特定のＵＥで頻繁に発生する場合、そのＵＥで障害を調べることができる。パス全体をセグメントのストリングとしてではなく、単一のユニットとして検査することにより、有用なメトリックを取得できる。
【0139】
データ送信の最適化：例として、ＩＯＴＳＰプラットフォームでのデバイスデータ送信スケジュールは、ピーク使用時間に関するＡ－ＳＣＥＦ分析からのフィードバックに基づいて更新できる。別の例として、３ＧＰＰネットワーク機能からの輻輳／過負荷表示をＩＯＴＳＰプラットフォームにフィードバックして、データ送信を最適化できる。
【0140】
事業者アクセスの簡素化：事業者は（カスタマイズ可能なポータルまたは指定されたノースバウンドＡＰＩを介して）ＩＯＴＳＰと対話でき、３ＧＰＰ固有の部分を認識しない。さらに、デバイスの構成、プロビジョニング、管理などを簡素化できる。
【0141】
図１８は、開示された主題のいくつかの実施形態による、Ａ－ＳＣＥＦベースＩＯＴ通信システム１８００展開モデルのブロック図である。これは、ＤＧによっておよび３ＧＰＰ－ＳＣＥＦ－Ｅによって公開されるＲＥＳＴ ＡＰＩは、複数のエンティティによって消費することができることを示している。ＡＳの１８１０Ａおよび１８１０Ｂは、ＤＧの１８６０ＲＥＳＴ ＡＰＩを消費し、ＤＧの１８６０は、３ＧＰＰ－ＳＣＥＦ－Ｅの１８０２Ａ ＲＥＳＴ ＡＰＩと１つ以上のサードパーティＳＣＥＦ１８０２Ｂを消費する。同時に、３ＧＰＰ－ＳＣＥＦ－Ｅ１８０２Ａは、ＲＥＳＴ ＡＰＩを介して１つ以上のサードパーティＤＧおよび／またはＡＳ（１８１０Ｃ）とインターフェースするようにも構成されている。３ＧＰＰ－ＳＣＥＦ－Ｅ１８０２ＡおよびＤＧ１８６０のそれぞれは、対応するデータベース（それぞれ１８７２Ａおよび１８７２Ｂ）に動作可能に結合されている。Ａ－ＳＣＥＦ機能は、そのようなホスト型プラットフォームソリューションに、またはスタンドアロン機能として展開できる。
【0142】
図１９は、標準文書２３．６８２「パケットデータネットワーク（「ＰＤＮ」）およびアプリケーションとの通信を促進するためのアーキテクチャの強化」からの第３世代パートナーシッププロジェクト（「３ＧＰＰ」）定義のＳＣＥＦ機能のブロック図である。図１９のノースバウンドＡＰＩは、ＯＭＡとＧＳＭＡのような他のフォーラムで標準化することができる。本明細書で説明する実施形態は、ナローバンドモノのインターネット（「ＮＢＩＯＴ」）デバイスの非ＩＰトランスポートに必要なありとあらゆるＡＰＩをサポートするように設計されており、新しいユースケースが出現した場合、より多くのＡＰＩをサポートするように変更できる。
【0143】
図２０は、例示的なＩＯＴＳＰ（２０００）の機能ブロックの高レベル図を示している。示されているように、ＩＯＴＳＰ２０００には、ＤＧ２０６０、３ＧＰＰ－ＳＣＥＦ－Ｅ２００２、およびＩＰ－ＳＭＳセンタ（「ＩＰ－ＳＭＳ－Ｃ」）２０２８が含まれている。ＩＯＴＳＰ２０００の他の機能には、サードパーティフィード、デバイスマネージャ２０４１、ルールエンジン２０４２、分析エンジン２０４３、課金サービスモジュール２０４４、加入マネージャセキュアルーティング（「ＳＭ－ＳＲ」）および加入マネージャデータプレパレーション（「ＳＭ－ＤＰ」）コンポーネントを使用した証明書およびプロファイル管理２０４５モジュール（例えば、認可を含む）、ならびにデバイスレジストリ２０３４（例えば、ＨＳＳ２０３４を含む）。３ＧＰＰ－ＳＣＥＦ－Ｅ２００２は、ＳＭ－ＳＲとのインターフェースＳ６ｔ（２０５３）を有している。監視イベント（ＭＯＮＴＥ）は、Ｓ６ｔ（ＨＳＳから）またはＴ６ａ（ＭＭＥから）を介して受信され、ＡＰＩを介して報告される。１つ以上のＣ－ＳＧＮ２０９０は、Ｇｄ／Ｇｄｄを介してＩＰ－ＳＭＳ－Ｃ２０２８と、ＳＧｉを介してデバイスゲートウェイ２０６０（ＩＰ用）と、Ｔ６ａを介して３ＧＰＰ－ＳＣＥＦ－Ｅ２００２（非ＩＰ用）と、およびＳ６ａ２０８３を介してデバイスレジストリとインターフェースする。この図では、Ｃ－ＳＧＮがＭＭＥ、ＳＧＷ、およびＰＧＷ機能を実装すると想定されていることに注意されたい。非アクセス層シグナリング（「ＮＡＳ」）データは、Ｃ－ＳＧＮ２０９０（ｅＮＭなど）と１つ以上のＩＯＴデバイス２０１２（サーモスタット、携帯電話、ランプなど）の間で交換できる。ＩＯＴＳＰ２０００は、１つ以上のノースバウンドＡＰＩ２０８０を介して１つ以上のアプリケーション（図示せず）と通信する。事業２０７０向けのカスタマイズ可能なポータルは、ＩＯＴデバイス２０１２との直接かつ安全な通信（エンドツーエンド暗号化（「Ｅ－２－Ｅ」）など）のために、ＩＯＴシステムに含めることもできる。ＤＧは、図示のインターフェースを使用してＩＰ、非ＩＰまたはＳＭＳを介して接続を提供するＩＯＴＳＰにおいて役割を果たしている。適用可能なデータパス間のポリシーベースの選択はＤＧの重要な機能であり、その結果、アプリケーションはデバイスへの到達方法（接続のため）を認識する必要がない。ＤＧ２０６０は、ＩＯＴＳＰ２０００の他のコンポーネントの多くの機能を引き受ける可能性があることに注意されたい。
【0144】
図２２に戻ると、Ａ－ＳＣＥＦ２２００は、一緒にまたは別々に、様々な方法で動作することができ、これにより、ポリシーとエンティティレベルの両方でプロビジョニングを実装し、ノースバウンド側からのＩＯＴ対話を簡素化しながら、オペレータの制御と機能を追加する。一実施形態によれば、上述のプロビジョニングおよびエンティティレベルがＭＧＭＴブロック２２４０および２２４５を介して管理されている。一実施形態によれば、Ａ－ＳＣＥＦ２２００は、ＡＳ（例えば、アプリケーション２２０４）からコマンドメッセージを受信してもよい。コマンドメッセージは、公開されたＡＰＩなどによって、経路２２０２を介して送信され得る。コマンドメッセージは、外部識別タグ、外部識別タグに関連付けられたアプリケーションプログラミングインターフェース（ＡＰＩ）命令、およびセキュリティ証明書を含むことができる。次に、Ａ－ＳＣＥＦ２２００は、セキュリティ証明書が外部識別タグに対して認可されていることを確認し、確認することに応答して、Ａ－ＳＣＥＦ２２００上またはＡ－ＳＣＥＦ２２００に接続された第１の電子的に検索可能なカタログ内に、外部識別タグに関連付けられた少なくとも１つのネットワーク識別子を位置付けることができる。少なくとも１つのネットワーク識別子は、外部識別タグと異なっていてもよい。Ａ－ＳＣＥＦ２２００は、アプリケーションプログラマインターフェース（ＡＰＩ）命令に基づいて、少なくとも１つのネットワーク識別子に関連付けられた少なくとも１つのユーザ機器（ＵＥ）（例えば、ＩＯＴデバイス２２６０）に通信を送信することができる。これは、ＳＣＥＦ２２５０を介して調整され、３ＧＰＰコアの経路上で、またはＩＰまたは非ＩＰデータ転送としてＳＧｉを介して達成され得る。
【0145】
一実施形態によれば、Ａ－ＳＣＥＦ２２００は、アプリケーションサーバ（ＡＳ）２２０４からコマンドメッセージを受信してもよい。コマンドメッセージは、メッセージのタイプに応じて、経路２２０２または２２４２を介して到着し得る。コマンドメッセージは、外部識別タグ、外部識別タグに関連付けられたアプリケーションプログラミングインターフェース（ＡＰＩ）命令、およびＡＳに関連付けられたエンティティに関連するセキュリティ証明書を含むことができる。Ａ－ＳＣＥＦ２２００は、セキュリティ証明書が外部識別タグに対して認可されていることを確認し、確認することに応答して、アプリケーションプログラマインターフェース（ＡＰＩ）命令に基づいてＡＳに通信を送信することができる。非限定的な例として、エンティティがアクティブプルを認可されている場合、ＡＳ２２０４は、ＩＯＴデバイス２２６０からＡ－ＳＣＥＦ２２００に送信され、上記のポリシーに従って保存されたデータを引き出すことができる。
【0146】
一実施形態によれば、Ａ－ＳＣＥＦ２２００は、ポリシープロファイルを少なくとも１つのアプリケーションサーバ（ＡＳ）２２６０と関連付けることができる。ポリシープロファイルは、Ａ－ＳＣＥＦ２２００に保存でき、または別のデータベースで、ネットワークトラフィック管理（Ａ－ＳＣＥＦ２２００および３ＧＰＰコアなど）、課金、および通知（ノースバウンドまたはサウスバウンド）の少なくとも１つを統治することができる。Ａ－ＳＣＥＦ２２００は次に少なくとも１つのアプリケーションサーバ（ＡＳ）２２０４からのコマンドメッセージを受信することができる。コマンドメッセージは、外部識別タグおよび外部識別タグに関連付けられたアプリケーションプログラミングインターフェース（ＡＰＩ）を含むことができる。次いで、Ａ－ＳＣＥＦ２２００は、電子的に検索可能なカタログ内に、外部識別タグに関連付けられた少なくとも１つのネットワーク識別子を位置付けることができ、少なくとも１つのネットワーク識別子は、外部識別タグとは異なる。次いで、Ａ－ＳＣＥＦ２２００は、ポリシープロファイルに従って、アプリケーションプログラマインターフェース（ＡＰＩ）命令（例えば、３ＧＰＰコアを介したＳＣＥＦ２２５０経由または経路２２２６経由）に基づいて少なくとも１つのネットワーク識別子に関連付けられた少なくとも１つのユーザ機器（ＵＥ）２２６０に通信を送信することを促進することができる。ポリシープロファイルは、ＤＧ２２１０、Ａ－ＳＣＥＦ２２００、および／または上記のオペレータのポリシーで規定されている３ＧＰＰコア内の他の要素を介して実装できる。
【0147】
（上述のように、例えば）の実施形態によれば、Ａ－ＳＣＥＦ２２００は、ポリシープロファイルを少なくとも１つのアプリケーションサーバ（ＡＳ）２２０４と関連付けることができる。ポリシープロファイルは、ネットワークトラフィック管理、課金、およびアプリケーション２２０４へのアップストリーム通知のうちの少なくとも１つを統治することができる。次いで、Ａ－ＳＣＥＦ２２００は、外部識別タグ、および外部識別タグに関連付けられたアプリケーションプログラマインターフェース（ＡＰＩ）命令を含むコマンドメッセージをアプリケーションサーバ（ＡＳ）２２０４から受信することができる。次いで、Ａ－ＳＣＥＦ２２００は、電子的に検索可能なカタログ内に、外部識別タグに関連付けられた少なくとも１つのネットワーク識別子を位置付けることができ、少なくとも１つのネットワーク識別子は、外部識別タグとは異なる。次いで、Ａ－ＳＣＥＦ２２００は、少なくとも１つのポリシープロファイルに従って、少なくとも１つのＡＳ２２０４に少なくとも１つの通信を送信することができる。そのメッセージには、ＡＰＩ命令に基づく外部識別タグおよび情報が含まれてもよい。非限定的な例として、エンティティがアクティブプルを認可されている場合、ＡＳ２２０４は、ＩＯＴデバイス２２６０からＡ－ＳＣＥＦ２２００に送信され、上記のポリシーに従って保存されたデータを引き出すことができる。一実施形態によれば、ポリシープロファイルは、ＡＳ２２０４がプッシュ通知に対してのみ認可されることを指示してもよい。したがって、ＡＳ２２０４への通信は、外部ＩＤに関連付けられたＩＯＴデバイス２２６０を介して受信されたときに、後でＡＳ２２０４にプッシュされるデータであり得る。ＡＳ２２０４は、このプロセスで３ＧＰＰネットワークの複雑さに対処する必要はない。一実施形態によれば、ＡＳ２２０４への通信は、ポリシープロファイルの認可の欠如に基づいて、要求の拒否を示す場合がある。
【0148】
一実施形態によれば、Ａ－ＳＣＥＦ２２００は、ポリシープロファイルを少なくとも１つのアプリケーションサーバ（ＡＳ）２２０４と関連付けることができる。ポリシープロファイルは、課金および通知のうちの少なくとも１つを統治できる。次いで、Ａ－ＳＣＥＦ２２００は、ＵＥのネットワーク識別子およびデータを含むユーザ機器（ＵＥ）２２６０から（例えば、ＳＧｉ経路２２６またはＳＣＥＦ２２５０を介して）通信を受信することができる。Ａ－ＳＣＥＦ２２００は、第１の電子的に検索可能なカタログ内（例えば、ＤＧ２２１０またはＤＧ２２１０にアクセス可能）に、ネットワーク識別子に関連付けられた少なくとも１つの外部識別タグを位置付けることができ、少なくとも１つのネットワーク識別子は、外部識別タグとは異なる。次いで、Ａ－ＳＣＥＦ２２００は、第２の電子的に検索可能なカタログ内に、ネットワーク識別子、外部識別タグ、またはデータの少なくとも１つに関連付けられた少なくとも１つのポリシープロファイルを位置付けることができる。次いで、Ａ－ＳＣＥＦ２２００は、外部識別タグまたはデータの少なくとも１つに基づいて少なくとも１つのアプリケーションサーバ（ＡＳ）２２０４を識別し、少なくとも１つのポリシープロファイル（例えば、上記のような）に従って、少なくとも１つのメッセージを識別された少なくとも１つのＡＳ２２０４に送信することができ、メッセージは、データに基づく外部識別タグおよび情報を含む。
【0149】
一実施形態によれば、Ａ－ＳＣＥＦ２２００は、セキュリティ証明書を少なくとも１つのユーザ機器（ＵＥ）２２６０に関連付けることができ、セキュリティ証明書は、アプリケーションサーバ（ＡＳ）、少なくとも１つのＡＳに関連付けられたテナント、または少なくとも１つのテナントに関連付けられた事業者（例えば、アプリケーション２２０４）のうちの少なくとも１つにデータを（例えばＳＧｉまたは３ＧＰＰ経路経由で）送信する少なくとも１つのＵＥ２２６０を認可する。Ａ－ＳＣＥＦ２２００はまた、ＵＥ２２６０のネットワーク識別子およびデータを含む通信をＵＥ２２６０から受信することができる。次いで、Ａ－ＳＣＥＦ２２００は、データベース（例えば、ＤＧ２２１０上またはＤＧ２２１０にアクセス可能）で、ＡＳ、テナント、または事業者の少なくとも１つにデータを送信するＡＰＩ命令を識別することができる。次いで、Ａ－ＳＣＥＦ２２００は、ＵＥ２２６０に関連付けられたセキュリティ証明書が、ＡＳ、テナント、または事業者２２０４のうちの少なくとも１つに対して認可されていることを確認することができる。確認することに応答して、Ａ－ＳＣＥＦ２２００は、アプリケーションプログラマインターフェース（ＡＰＩ）命令に基づいて、ＡＳ、テナントに関連付けられたＡＳ、または事業者に関連付けられたテナントに関連付けられたＡＳ（例えば、アプリケーション２２０４）に通信を送信することができる。
【0150】
上記実施例の手順では、組み合わせ、または置き換え様々なタスクを実行するために、および方法は、本明細書に記載されてもよい。それらは、ＤＧとＳＣＥＦの様々な比率、さらに様々なレベルの地理冗長性を含む、図２３Ａ～Ｄに関連して上記で議論された様々な展開で実装され得る。上記の様々なポリシーおよびテナンシーレベルを実装して、上流のエンティティとＩＯＴデバイス間の通信プロセスを簡素化しながら、オペレータに制御を提供することができる。また、上記実施形態はまた、以下の態様を含むことができる。
【0151】
一実施形態によれば、確認するステップは、外部識別タグとセキュリティ証明書との間の関連付けを、複数の外部識別タグの第２の電子的に検索可能なカタログおよび関連するセキュリティ証明書（例えば、ＤＧ２２１０またはそのアクセス可能）内に位置付けることを含んでもよい。
【0152】
一実施形態によれば、外部識別タグは、外部グループ識別タグ（例えば、上記のグループエンティティに基づく）であり、グループ外部識別タグに関連付けられた少なくとも１つのネットワーク識別子は、複数の関連するネットワーク識別子を含み、複数の関連するネットワーク識別子のそれぞれが、それぞれのＵＥ２２６０を識別し、かつ、通信を送信することは、複数のネットワーク識別子に関連付けられた各ＵＥ２２６０にそれぞれの通信を送信することを含む。
【0153】
一実施形態によれば、ＡＰＩ命令は転送データ命令であり、方法は、ＵＥ２２６０またはＡＳ２２０４のうちの少なくとも１つに関連付けられたポリシープロファイルにおいて、転送データポリシー設定を識別することをさらに含み、転送データポリシー設定は、アクティブプッシュ設定、ストアアンドフォワード設定、データレート設定、メモリ割り当て設定、または優先度設定のうちの少なくとも１つである。少なくとも１つのユーザ機器（ＵＥ）２２６０への通信を送信することは、データポリシー設定に基づいて、ＡＰＩ命令とは無関係に、時間間隔、レート、または他の通信後のうちの少なくとも１つにおいて通信を送信することのうちの少なくとも１つを含む。一実施形態によれば、コマンドメッセージまた、返信間隔を含み、 Ａ－ＳＣＥＦ２２００は、ネットワーク識別子に関連付けられたＵＥ２２６０から、データを含む更新メッセージを受信し、電子的に検索可能なカタログ内に、ネットワーク識別子に関連付けられた外部識別タグを位置付け、返信間隔に従って、外部識別タグおよびネットワーク識別子に関連付けられたＵＥから受信したデータを含むメッセージなどの返信メッセージをＡＳ２２０４に送信する。
【0154】
一実施形態によれば、コマンドメッセージは、データを含む送信データコマンドメッセージであり、方法は、通信中のデータを少なくとも１つのＵＥ２２６０に送信することをさらに含む。例えば、データは、上述のポリシーに従って、経路２２２６または経路２２６２の１つを介して送信され得る。
【0155】
一実施形態によれば、通信は、ショートメッセージサービス（ＳＭＳ）であり、かつ、ＡＰＩ命令が、電力消費が削減されたスリープ状態から非スリープ状態へ移行し、アプリケーション２２０４のようなアプリケーションに接続するように少なくとも１つのＵＥ２２６０に命令するデバイストリガーである。
【0156】
一実施形態によれば、Ａ－ＳＣＥＦ２２００は、少なくとも２つのデータ接続経路から少なくとも１つのＵＥ２２６０へのデータ接続経路を選択し、ＡＰＩ命令に基づく少なくとも１つのネットワーク識別子に関連付けられた少なくとも１つのＵＥへの通信を送信することは、経路２２２６または上記のポリシーに従った経路２２６２などの選択された、データ接続経路を介して、少なくとも１つのネットワーク識別子に関連付けられた少なくとも１つのＵＥ２２６０に通信を送信することをさらに含む。一実施形態によれば、データ接続経路の選択は、ＡＰＩ命令のタイプとは無関係に行われる。一実施形態によれば、少なくとも２つのデータ接続経路から少なくとも１つのＵＥ２２６０へのデータ接続経路をＡ－ＳＣＥＦ２２００によって選択することは、少なくとも２つのデータ接続経路のうちの２つ以上が開いているかどうかを判定することを含む。少なくとも２つのデータ接続経路のうち２つ以上が開いている（開放されている）場合、 Ａ－ＳＣＥＦ２２００による、少なくとも２つのデータ接続経路からＵＥ２２６０へのデータ接続経路の選択は、選択階層に基づいて、優先データ接続経路を決定し、優先データ接続経路を選択することを含んでもよい。これは、オペレータ定義されたポリシーに基づいてもよい。さらに、少なくとも２つのデータ接続経路のうち１つだけが開いている場合、Ａ－ＳＣＥＦ２２００は開いた経路を選択することができる。一実施形態によれば、Ａ－ＳＣＥＦは、ＵＥ２２６０能力データベース（例えば、Ａ－ＳＣＥＦ２２００またはそこにアクセス可能）において、ＵＥ２２６０に関連付けられたデバイス能力リストを位置付けることにより経路を選択することができる。一実施形態によれば、選択されたデータ接続経路は、例えば、非ＩＰ－ｖｉａ－ＳＧｉ接続経路、ＩＰ－ｖｉａ－ＳＧｉ接続経路、ＮＩＤＤ－ｖｉａ－Ｔ６ａ接続経路、ＭＴ－ＳＭＳ－ｖｉａ－Ｔ４接続経路、ＳＭＳ－ｖｉａ－ＳＧｄ接続経路、またはＳＭＳ－ｖｉａ－Ｇｄ接続経路のうちの少なくとも１つを含んでもよい。一実施形態によれば、接続経路は、少なくとも２つのデータ接続経路のうちの少なくとも１つに関連付けられたトラフィックデータに基づいて選択されてもよい。さらに、３ＧＰＰネットワークに関連付けられたトラフィックデータは、少なくとも１つの接続経路を介したネットワーク遅延などの様々なタイプのデータ、少なくとも１つの接続経路にわたる履歴ネットワーク遅延、３ＧＰＰネットワークの少なくとも一部の負荷情報、３ＧＰＰネットワークの少なくとも一部の履歴負荷情報、または優先度情報を含んでもよい。
【0157】
一実施形態によれば、Ａ－ＳＣＥＦ２２００は、ＤＧ機能２２１０および複数のサービス能力公開機能２２５０を含む。さらに、少なくとも１つのネットワーク識別子を位置付けることは、ＤＧ２２１０によるものである。少なくとも１つのＵＥ２２６０に通信を送信することは、 ＤＧ２２１０が、複数のＳＣＥＦの中からＵＥ２２６０に関連付けられたアクティブＳＣＥＦ２２５０を選択すること、およびＤＧ２２１０が、選択されたＳＣＥＦ２２５０へのＡＰＩ命令に基づいてネットワーク識別子および情報を送信することを含む。受信することは、ＤＧによるものであってもよいし、完全修飾ドメイン名（ＦＱＤＮ）を介して受信することを含んでもよい。
【0158】
一実施形態によれば、Ａ－ＳＣＥＦ２２００は、デバイスゲートウェイ機能２２１０およびサービス能力公開機能２２５０を含む。少なくとも１つのネットワーク識別子を位置付けることは、ＤＧ２２１０によるものであり、少なくとも１つのＵＥ２２６０に通信を送信することは、ＤＧ２２１０がＳＣＥＦ２２５０へのＡＰＩ命令に基づいてネットワーク識別子および情報を送信することを含んでもよい。受信することは、ＤＧによるものであってもよいし、受信することは、完全修飾ドメイン名（ＦＱＤＮ）を介して受信することを含んでもよい。
【0159】
一実施形態によれば、少なくとも１つのＵＥに通信を送信することは、ＳＧｉ経路２２６０を選択し、選択されたＳＧＩ経路２２６０を介してＰＧＷにＡＰＩ命令に基づいてネットワーク識別子および情報を送信することを含む。
【0160】
いくつかの実施形態によれば、図２３Ｂおよび２３Ｄの実施形態のように、２つのＡ－ＳＣＥＦが含まれ、各Ａ－ＳＣＥＦは少なくとも１つのＤＧを有する。このようなＡ－ＳＣＥＦは、上記のポリシーに従って動作するＭＱＴＴをサポートすることができる。
【0161】
いくつかの実施形態によれば、ＡＳは、図２１に関連して説明したエンティティシステムの一部であってもよい。例えば、ＡＳは、複数のテナントのうちの少なくとも１つのテナントおよび複数の事業者のうちの少なくとも１つの事業者に関連付けられてもよい。各事業者は、少なくとも１つのテナントに関連付けられ、各事業者は、事業者に関連付けられたすべてのテナントのネットワークトラフィック管理、課金、または通知の少なくとも１つを統治するポリシープロファイル定義のサブセットを有してもよい。各テナントは、少なくとも１つのテナントに関連付けられ、各テナントは、テナントに関連付けられた各ＡＳのネットワークトラフィック管理、課金、または通知の少なくとも１つを統治するポリシープロファイル定義のサブセットを有してもよい。各ＡＳは、ネットワークトラフィック管理、課金、または通知の少なくとも１つを統治するポリシープロファイル定義のサブセットに関連付けられてもよい。各事業者やテナントは、少なくとも１つのデバイスの少なくとも１つのグループに関連付けられてもよい。各デバイスは、ネットワークトラフィック管理、課金、または通知の少なくとも１つを統治するポリシープロファイル定義のサブセットに関連付けられてもよい。各グループは、ネットワークトラフィック管理、課金、または通知の少なくとも１つを統治するポリシープロファイル定義のサブセットに関連付けられてもよい。ポリシープロファイルに従って送信することは、デバイス、グループ、ＡＳ、関連付けられたテナント、または関連付けられた事業者のポリシープロファイル定義の関連付けられたサブセットの少なくとも１つに従って送信することを含んでもよい。
【0162】
一実施形態によれば、ポリシープロファイルを少なくとも１つのＡＳに関連付けることは、ＡＳを関連付けられたポリシープロファイルを有する少なくとも１つのＵＥに関連付けることを含んでもよい。したがって、ポリシープロファイルに従って送信することは、少なくとも１つのＵＥに関連付けられたポリシープロファイルに従って送信することを含んでもよい。一実施形態によれば、ＵＥは、ＵＥのグループの一部である。グループは、ＵＥに関連付けられたポリシープロファイルを有してもよく、したがって、グループポリシープロファイルに従って送信を行うことができる。
【0163】
ポリシープロファイルは、本明細書で論じたものなどの特性の数を定義することができる。例えば、一実施形態によれば、ポリシープロファイルは、ネットワークトラフィック管理を統治し、ポリシープロファイルに従って送信することは、少なくとも１つのＵＥに通信が送信されるレートを統治する。
【0164】
例えば、一実施形態によれば、ポリシープロファイルは、ネットワークトラフィック管理を統治し、ポリシープロファイルに従って送信することは、少なくとも１つのＵＥに送信される通信の優先度を統治する。
【0165】
例えば、一実施形態によれば、ポリシープロファイルは、ネットワークトラフィック管理を統治し、ポリシープロファイルに従って送信することは、少なくとも１つのＵＥに送信される通信に割り当てられたメモリの量を統治する。一実施形態によれば、通信に割り当てられたメモリは、送信することの保留中に保存され得る通信の数、または送信することの保留中に保存された通信に使用可能なメモリ量のうちの少なくとも１つ、およびそれを超えると送信することが保留されて通信が保存されない時間制限を含む。
【0166】
例えば、一実施形態によれば、ポリシープロファイルは、ネットワークトラフィック管理を統治し、ポリシープロファイルに従って送信することは、少なくとも１つのＵＥに送信される通信のスケジューリングを統治する。
【0167】
いくつかの実施形態によれば、ＡＰＩ命令は、外部識別タグに関連付けられた少なくとも１台のユーザ機器（ＵＥ）またはＵＥのグループに加入するＭＱＴＴ命令である。したがって、関連付けられたポリシープロファイルは、ＡＳに関連付けられたポリシープロファイル、ＵＥに関連付けられたポリシープロファイル、ＵＥのグループに関連付けられたポリシープロファイル、またはＵＥのグループ内のＵＥのポリシープロファイルのうちの少なくとも１つである。ＡＰＩ命令に基づいて少なくとも１つの通信のＡＳに送信することは、少なくとも１つのポリシープロファイルに従って、ＵＥまたはＵＥのグループ内の少なくとも１つのＵＥからＡＳにデータを送信することを含んでもよい。
【0168】
本明細書で開示される技術およびシステムは、ネットワーク、コンピュータシステム、またはコンピュータ化された電子デバイスとともに使用するためのコンピュータプログラム製品として実装され得る。そのような実装は、コンピュータ可読媒体（例えば、ディスケット、ＣＤ－ＲＯＭ、ＲＯＭ、フラッシュメモリまたは他のメモリまたは固定ディスク）などの有形媒体のいずれかに固定され、または、メディアを介してネットワークに接続された通信アダプタなどのモデムまたは他のインターフェースデバイスを介してネットワーク、コンピュータシステム、またはデバイスに送信可能である一連のコンピュータ命令またはロジックを含んでもよい。
【0169】
媒体は、有形媒体（例えば、光またはアナログ通信回線）または無線技術（例えば、Ｗｉ－Ｆｉ、セルラー、マイクロ波、赤外線または他の送信技術）で実装された媒体のいずれかであり得る。一連のコンピュータ命令は、システムに関して本明細書で説明されている機能の少なくとも一部を具現化する。当業者は、そのようなコンピュータ命令は多くのコンピュータアーキテクチャまたはオペレーティングシステムで使用するためのプログラミング言語の数で記述することができることを理解すべきである。
【0170】
さらに、そのような命令は、半導体、磁気、光学または他のメモリデバイスのような任意の有形のメモリデバイスに保存されてもよく、例えば、光、赤外線、マイクロ波、または他の送信技術などの任意の通信技術を使用して送信されてもよい。
【0171】
このようなコンピュータプログラム製品は、印刷または電子文書（シュリンクラップソフトウェアなどを添付したリムーバブルメディアとして配布し得ること、コンピュータシステム（システムＲＯＭや固定ディスクなど）がプリロードされ得ること、または、サーバまたは電子掲示板からネットワーク（インターネット、Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂなど）を介して配布され得ることが期待されている。当然のことながら、本発明のいくつかの実施形態は、ソフトウェア（例えば、コンピュータプログラム製品）とハードウェアの両方の組み合わせとして実装されてもよい。本発明のさらに他の実施形態は、完全にハードウェア、または完全にソフトウェア（例えば、コンピュータプログラム製品）として実装される。
【0172】
前述の説明では、特定のステップまたはプロセスは、特定のサーバ上または特定のエンジンの一部として実行することができる。これらの説明は、サーバシステムおよび／またはモバイルデバイスを含むが、これらに限定されない、様々なハードウェアデバイスで特定のステップを実行することができるため、単なる例解に過ぎない。代替的に、または加えて、本明細書で説明するステップのいずれかまたはすべては、物理サーバ自体で実行される仮想化マシンで実行することができる。同様に、特定のステップが実行される場所の区分は変化する可能性があり、区分または異なる区分は本発明の範囲内にないことが理解される。さらに、コンピュータシステムの処理を説明するために使用される「モジュール」および／または他の用語の使用は、互換性があり、機能を実行できるロジックまたは回路を表すことを意図している。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図 】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23A】
【図23B】
【図23C】
【図23D】
