JP7337264B2 - 識別情報モジュールにおけるプロファイルのリモート管理を可能にするための方法および装置 - Google Patents

Description

本明細書に記載の実施形態は、狭帯域モノのインターネット（ＮＢ－ＩｏＴ：ｎａｒｒｏｗ ｂａｎｄ Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ）デバイス内の識別情報モジュールへのプロファイルのリモート管理を可能にするための方法および装置に関する。プロファイルのリモート管理は、プロファイルをＮＢ－ＩｏＴデバイスにプロビジョニングすること、および／または既存のプロファイルを更新もしくは調整することを含み得る。

加入者識別情報モジュール（ＳＩＭ：Ｓｕｂｓｃｒｉｂｅｒ Ｉｄｅｎｔｉｔｙ Ｍｏｄｕｌｅ）カードは、１９９１年に商業的に展開され、それ以来、モバイルネットワークへのセキュアで識別可能な認証済みのアクセスを保証してきた。消費者にとってのＳＩＭフォームファクタの別の利点は、連絡先がＳＩＭカード上のメモリに記憶されているため、ＳＩＭカードをデバイス間で入れ替えて、名前および番号を失うことなくハードウェアをアップグレードできることであった。ＳＩＭカードを使用すると、消費者は自分のデバイスを別のモバイルオペレータに容易に切り替えられることにもなる。

ＳＩＭは、導入以来、新世代のセルラ技術ごとにサイズが縮小され、能力が向上している。しかしながら、新興のマシンツーマシン（Ｍ２Ｍ：ｍａｃｈｉｎｅ－ｔｏ－ｍａｃｈｉｎｅ）およびモノのインターネット（ＩｏＴ：Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ）市場では、異なるサービスパラダイムがあり、時として非常に離れた場所にある大規模なＩｏＴデバイスフリートのＳＩＭを物理的に取り外すことおよび入れ替えることは、コストがかかり、煩雑になる。

ほとんどの企業にとっての課題は、長くてしばしば複雑なサプライチェーンにおける様々な地点で、ＳＩＭカードとデバイスとの組合せが発生することである。企業は、様々な市場の様々な（モバイル）オペレータを使用しており、可能な場合には、オペレータは、他のオペレータとの契約を利用してシームレスなグローバルコネクティビティを提供する。しかしながら、製品を異なる市場に販売する、または異なるオペレータネットワーク上で運用するフリートで使用する必要がある場合、新しいモバイルネットワークオペレータ（ＭＮＯ）によって発行されたすべてのＳＩＭカードについて、新しいコストのかかるロジスティクス管理およびライフサイクル管理の問題が生じる可能性がある。さらに、過去にデバイスの耐用期間中にモバイルオペレータを変更する必要があった場合、これは、履歴的には常に、ＳＩＭカードを変更していることを意味し、追加のロジスティクスおよびコストの問題が生じていた。

このますます厳しくなる市場のニーズにより、リモートでプログラムされた識別情報モジュール、例えば、組込みＳＩＭ（ｅＳＩＭ：ｅｍｂｅｄｄｅｄ ＳＩＭ）または組込みユニバーサル集積回路カード（ｅＵＩＣＣ：Ｅｍｂｅｄｄｅｄ Ｕｎｉｖｅｒｓａｌ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ Ｃａｒｄ）というソリューションが生まれた。ｅＵＩＣＣは、小型の電子チップであり、製造時にデバイスの回路基板に挿入およびはんだ付けされる。ｅＵＩＣＣのこの設定は、ＭＦＦ２というフォームファクタとして知られており、ＭＦＦ２では、ＳＩＭカードホルダーが不要であり、その結果、ＳＩＭに必要なスペースの量が削減される。

ｅＵＩＣＣは、モバイルオペレータによって提供される初期のブートストラッププロファイルを用いて製造中にプログラムされ得る。初期のブートストラッププロファイルは、ｅＵＩＣＣに運用プロファイルをリモートでプロビジョニングできるように初期のコネクティビティを提供し得る。これは、ＳＩＭに接続されている初期のネットワークオペレータを変更および再割り当てすることが可能であることを意味する。代替として、初期のコネクティビティは、動作プロファイルをリモートでプロビジョニングできる何らかの他の無線インターフェースを介して（例えば、コンピュータなどの別のデバイスを介して）実現され得る。この再プログラミングおよびプロビジョニングは、物理的な変更を必要とせずにオーバージエアで実行することができ、これは、企業に大きな利益をもたらす可能性がある。

ｅＵＩＣＣの標準は、モバイルネットワークオペレータの国際協会である汎欧州デジタル移動電話方式協会（ＧＳＭＡ：Ｇｌｏｂａｌ Ｓｙｓｔｅｍ ｆｏｒ Ｍｏｂｉｌｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ａｓｓｏｃｉａｔｉｏｎ）によって、最初はマシンツーマシン（Ｍ２Ｍ）用途向けに、さらに最近ではスマートフォンおよびウェアラブル機器などの消費者用途向けに確立された。

相手先商標製品製造業者（ＯＥＭ：Ｏｒｉｇｉｎａｌ Ｅｑｕｉｐｍｅｎｔ Ｍａｎｕｆａｃｔｕｒｅｒ）にとってこのｅＵＩＣＣ技術の唯一最大の利点は、このｅＵＩＣＣ技術がＳＩＭを単一ＳＫＵ（Ｓｔｏｃｋ Ｋｅｅｐｉｎｇ Ｕｎｉｔ：在庫管理単位）に変換することである。言い換えると、製造中にｅＵＩＣＣを他の構成要素と同様にデバイスに挿入し、その後、デバイスを世界のどこに出荷するかによって、後で適切なネットワークオペレータプロファイルを用いてｅＵＩＣＣをプロビジョニングすることができる。この技術は、生産プロセスを合理化し、デバイスのライフサイクル全体のコストを削減するとともに、ＩｏＴデバイスでのセルラコネクティビティのより広範な使用を妨げる障害を軽減する。リモートでプロビジョニングされた識別情報モジュールを使用する単一ＳＫＵビジネスモデルにより、企業は、自社のグローバル製品に共通のｅＵＩＣＣを１つだけ使用して、コネクテッド製品のロジスティクス管理およびライフサイクル管理を簡素化することができる。

ｅＵＩＣＣはまた、デバイスの耐用期間の間、任意の単一のオペレータによる「コネクティビティランサム」に拘束されることに対する保証ポリシーを提供する。ｅＵＩＣＣプロセスのロジスティクスは単純であり、例えば、企業は、契約期間の終了時に必要に応じてオペレータを変更できる権利を含む初期契約をモバイルオペレータと締結する。その後、企業は、契約期間の終了時に、サービスおよび価格の観点から代替のコネクティビティの提案を柔軟に探し求めることができ、場合によってはオペレータを変更する保証オプションを利用することができる。

自動車市場は最も先進的なＩｏＴ市場の１つであり、自動車産業にとっての現在の要件は、すべてのコネクテッドカーにｅＵＩＣＣを搭載しなければならないことである。例えば、欧州では、ｅＣａｌｌ法の施行により、すべての新車にｅＵＩＣＣを採用することが義務化されている。しかしながら、例えば、ユーティリティ産業、スマート製造、エネルギー産業、輸送＆ロジスティクスなど、グローバル産業全体においても、ｅＵＩＣＣの利点が見られ、急速に採用されている。ｅＵＩＣＣリモートＳＩＭプロビジョニングは、ＩｏＴのユースケース、デバイスメーカー、サービスプロバイダ、およびモバイルネットワークオペレータにとってますます重要になっている。

狭帯域ＩｏＴ（ＮＢ－ＩｏＴ）は、モノのインターネット（ＩｏＴ）の要件に対応する新しい３ＧＰＰ無線技術標準である。この技術は、屋内カバレッジの向上、多数の低スループットデバイスのサポート、低遅延感度、超低デバイスコスト、低デバイス消費電力、および最適化されたネットワークアーキテクチャを提供する。ＮＢ－ＩｏＴは、低電力ワイドエリアコネクティビティ市場の急速な拡大に対応するために、３ＧＰＰによってリリース１３で指定された、新しいセルラ無線アクセス技術（現在は公式の５Ｇ技術の一部）である。モバイル産業は現在、アプリケーションサービスプロバイダ、デバイスメーカーなどの顧客が自社のサービスを世界中に展開して運用できるようにするグローバルカバレッジソリューションとしてＮＢ－ＩｏＴを確立している。

国際特許第２０１９／１３６０４４号は、加入者識別情報モジュールおよび公衆陸上移動体ネットワーク情報の交換を通じて管理されるモノのインターネットおよび同様のデバイスのネットワーク登録を開示している。

いくつかの実施形態によれば、プロキシサーバにおいて、３ＧＰＰによる狭帯域モノのインターネット（ＮＢ－ＩｏＴ）デバイス内の識別情報モジュールにおけるプロファイルのリモート管理を可能にするための方法が提供され、プロキシサーバは、各々が１つまたは複数のそれぞれのＮＢ－ＩｏＴデバイスのうちのそれぞれ１つに関連付けられた１つまたは複数の外部識別子のデータベースへのアクセスを有するように設定され、１つまたは複数の外部識別子は各々、コアネットワーク内の公開機能を介して１つまたは複数のＮＢ－ＩｏＴデバイスのうちのそれぞれ１つをアドレス指定するために使用される。方法は、トリガメッセージをＮＢ－ＩｏＴデバイスに配信するよう求める要求を受信することであって、要求がＮＢ－ＩｏＴデバイスのデバイス識別子を含む、要求を受信することと、受信したデバイス識別子に基づいて、データベースからＮＢ－ＩｏＴデバイスの外部識別子を決定することと、非ＩＰデータ配信（ＮＩＤＤ）サービスを使用してＮＢ－ＩｏＴデバイスに転送するために、トリガメッセージを外部識別子とともに公開機能に送信することであって、トリガメッセージが、プロファイル管理サーバからプロファイルをダウンロードするようＮＢ－ＩｏＴデバイスをトリガするように設定されたプロファイルダウンロードトリガメッセージ、またはプロファイル管理動作を実行するようＮＢ－ＩｏＴデバイス内の識別情報モジュールをトリガするように設定されたプロファイル管理トリガメッセージのいずれかを含む、トリガメッセージを送信することとを含む。

いくつかの実施形態によれば、３ＧＰＰによる狭帯域モノのインターネット（ＮＢ－ＩｏＴ）デバイス内の識別情報モジュールにおけるプロファイルのリモート管理を可能にするためプロキシサーバが提供され、プロキシサーバは、各々が１つまたは複数のそれぞれのＮＢ－ＩｏＴデバイスのうちのそれぞれ１つに関連付けられた１つまたは複数の外部識別子のデータベースへのアクセスを有するように設定され、１つまたは複数の外部識別子は各々、コアネットワーク内の公開機能を介して１つまたは複数のＮＢ－ＩｏＴデバイスのうちのそれぞれ１つをアドレス指定するために使用される。プロキシサーバは、トリガメッセージをＮＢ－ＩｏＴデバイスに配信するよう求める要求を受信することであって、要求がＮＢ－ＩｏＴデバイスのデバイス識別子を含む、要求を受信することと、受信したデバイス識別子に基づいて、データベースからＮＢ－ＩｏＴの外部識別子を決定することと、非ＩＰデータ配信（ＮＩＤＤ）サービスを使用してＮＢ－ＩｏＴデバイスに転送するために、トリガメッセージを外部識別子とともに公開機能に送信することであって、トリガメッセージが、プロファイル管理サーバからプロファイルをダウンロードするようＮＢ－ＩｏＴデバイスをトリガするように設定されたプロファイルダウンロードトリガメッセージ、またはプロファイル管理動作を実行するようＮＢ－ＩｏＴデバイス内の識別情報モジュールをトリガするように設定されたプロファイル管理トリガメッセージのいずれかを含む、トリガメッセージを送信することとを行うように設定された処理回路を備える。

いくつかの実施形態によれば、狭帯域モノのインターネット（ＮＢ－ＩｏＴ）デバイス内の識別情報モジュールにおけるプロファイルのリモート管理を可能にするための、デバイスコネクティビティ（Ｄ／Ｃ）管理サーバが提供される。Ｄ／Ｃ管理サーバは、トリガメッセージをＮＢ－ＩｏＴデバイスに配信するよう求める要求をプロキシサーバ（１０８）に送信するように設定された処理回路を備え、要求はデバイス識別子およびトリガメッセージを含む。

いくつかの実施形態によれば、狭帯域モノのインターネット（ＮＢ－ＩｏＴ）デバイス内の識別情報モジュールにおけるプロファイルのリモート管理を可能にするためのＮＢ－ＩｏＴデバイスが提供される。ＮＢ－ＩｏＴデバイスは、プロキシサーバによって配信されたトリガメッセージを受信するように設定された処理回路を備える。

次に、本開示の実施形態をよりよく理解し、その実施形態がどのように実行され得るかを示すために、添付の図面をほんの一例として参照する。

１つまたは複数の異なるタイプのＮＢ－ＩｏＴデバイス内の識別情報モジュールにおいてプロファイルを管理するために使用され得る複数のノードを示す、ネットワーク１００のブロック図である。 プロキシサーバにおいて、ＮＢ－ＩｏＴデバイス内の識別情報モジュールのためにプロファイルのリモート管理を可能にするための方法を示す図である。 狭帯域モノのインターネット（ＮＢ－ＩｏＴ）デバイスにおいて、ＮＢ－ＩｏＴデバイス内の識別情報モジュールにおけるプロファイルのリモート管理を可能にするための方法を示す図である。 図１および図２の方法の例をより詳細に示すシグナリング図である。 図１および図２の方法の例をより詳細に示すシグナリング図である。 いくつかの実施形態によるプロファイルプロビジョニングプロセスの一例を示す図である。 いくつかの実施形態によるプロファイルプロビジョニングプロセスの一例を示す図である。 図５に示すシグナリング図の一例を示す図である。 図５に示すシグナリング図の一例を示す図である。 図５に示すシグナリング図の一例を示す図である。 図５に示すシグナリング図の一例を示す図である。 図５のプロファイルダウンロードおよびプロファイル有効化のフローの一例を示す図であり、フローは、ＧＳＭＡ ＲＳＰの適合された消費者版用に再描画されている。 図５のプロファイルダウンロードおよびプロファイル有効化のフローの一例を示す図であり、フローは、ＧＳＭＡ ＲＳＰの適合された消費者版用に再描画されている。 公開機能を介して、ＮＩＤＤを使用してＮＢ－ＩｏＴデバイスからアプリケーションサーバにＣｏＡＰ要求を送信することを示す図である。 公開機能を介して、ＮＩＤＤを使用してＮＢ－ＩｏＴデバイスからアプリケーションサーバにＣｏＡＰ要求を送信することを示す図である。 公開機能を介して、ＮＩＤＤを使用してアプリケーションサーバ９００からＮＢ－ＩｏＴデバイス１０１にＣｏＡＰ要求を送信することを示す図である。 公開機能を介して、ＮＩＤＤを使用してアプリケーションサーバ９００からＮＢ－ＩｏＴデバイス１０１にＣｏＡＰ要求を送信することを示す図である。 ＲＤＳが使用される場合、公開機能を介して、ＮＩＤＤを使用してＮＢ－ＩｏＴデバイスからアプリケーションサーバに要求メッセージを送信することを示す図である。 ＲＤＳが使用される場合、公開機能を介して、ＮＩＤＤを使用してＮＢ－ＩｏＴデバイスからアプリケーションサーバに要求メッセージを送信することを示す図である。 ＲＤＳが使用される場合、公開機能１０４を介して、ＮＩＤＤを使用してアプリケーションサーバからＮＢ－ＩｏＴデバイスに要求メッセージを送信することを示す図である。 ＲＤＳが使用される場合、公開機能１０４を介して、ＮＩＤＤを使用してアプリケーションサーバからＮＢ－ＩｏＴデバイスに要求メッセージを送信することを示す図である。 処理回路（または論理）を備えるプロキシサーバを示す図である。 処理回路（または論理）を備えるデバイスコネクティビティ（Ｄ／Ｃ）管理サーバを示す図である。 処理回路（または論理）を備える狭帯域モノのインターネット（ＮＢ－ＩｏＴ）デバイスを示す図である。

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

限定ではなく説明を目的とした具体的な実施形態または例などの具体的な詳細を以下に示す。当業者には、これらの具体的な詳細とは別に他の例が採用され得ることが理解されよう。いくつかの事例では、不要な詳細によって説明が不明瞭にならいように、よく知られた方法、ノード、インターフェース、回路、およびデバイスの詳細な説明は省略されている。当業者は、記載された機能が、ハードウェア回路（例えば、特殊な機能を実行するために相互接続されたアナログおよび／もしくはディスクリート論理ゲート、ＡＳＩＣ、ＰＬＡなど）を使用して、かつ／または１つまたは複数のデジタルマイクロプロセッサもしくは汎用コンピュータと組み合わせたソフトウェアプログラムおよびデータを使用して、１つまたは複数のノードに実装され得ることを理解するであろう。エアインターフェースを使用して通信するノードは、適切な無線通信回路も有する。また必要に応じて、当技術はさらに、本明細書に記載の技法をプロセッサに実行させる適切なコンピュータ命令セットを含むソリッドステートメモリ、磁気ディスク、または光ディスクなどの任意の形式のコンピュータ可読メモリ内で完全に具現化されると見なされ得る。

ハードウェア実装は、限定されないが、デジタル信号プロセッサ（ＤＳＰ）ハードウェアと、縮小命令セットプロセッサと、特定用途向け集積回路（ＡＳＩＣ：ａｐｐｌｉｃａｔｉｏｎ ｓｐｅｃｉｆｉｃ ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ）および／またはフィールドプログラマブルゲートアレイ（ＦＰＧＡ）を含むがこれらに限定されないハードウェア（例えば、デジタルもしくはアナログ）回路と、（必要に応じて）そのような機能を実行できるステートマシンとを含み得るか、または包含し得る。

ｅＵＩＣＣなどの識別情報モジュールへのプロファイルのリモートプロビジョニングは、ＧＳＭＡ技術の成熟度に依存し得るが、これは利点でもあり制限でもある。リモートプロビジョニングアクションのトリガは、数十年前から存在しているショートメッセージサービス（ＳＭＳ）およびハイパーテキスト転送プロトコル（ＨＴＴＰ）技術に基づいているが、常に信頼できるとは限らず、特にローミング中の場合、顧客は通常、リモートプロビジョニングをトリガして、新しいローカルＭＮＯプロファイルをｅＵＩＣＣ上でダウンロードおよび有効化する必要があり、トリガの配信能力が制限される。例えば、ローミングＳＭＳの商用問題またはＩｏＴコンテキスト内の技術的な問題に起因して、最初のＳＭＳトリガが配信に失敗する場合である。

その結果として、ｅＵＩＣＣが、新しいプロファイルのダウンロードを開始すること、および／またはあるプロファイルから別のプロファイルに切り替えることが可能になるには最初のＳＭＳトリガを受信する必要があるため、ｅＵＩＣＣリモートプロビジョニングが失敗する。ＳＭＳの技術的な制限に加えて、すべてのＳＭＳに追加コストがかかり、現在は各ｅＵＩＣＣリモートプロビジョニングフローに合計４つのＳＭＳが必要であるので、ＳＭＳの使用には商業上の問題もある。したがって、ＳＭＳを使用する場合、現在のｅＵＩＣＣリモートプロビジョニングソリューションを多数のＩｏＴデバイスに合わせてスケーリングすることが困難になる。

ほとんどのＮＢ－ＩｏＴデバイスは、小さいデータパケットを送受信するようにのみ設定され得る。例えば、ＮＢ－ＩｏＴデバイスは、データパケットがインターネットプロトコル（ＩＰ）ベースのプロトコルを介して送信される場合に、ＩＰプロトコルのオーバーヘッドが、交換される実際のデータをはるかに上回り得るほどに、小さいデータパケットを送信するように設定され得る。このようなＮＢ－ＩｏＴデバイスは、非ＩＰコントロールプレーンベースのデータ配信方法、すなわちＮＡＳベースの非ＩＰデータ配信（ＮＩＤＤ：Ｎｏｎ－ＩＰ Ｄａｔａ Ｄｅｌｉｖｅｒｙ）を使用してサーバとデータを交換するように設定され得る。

制約付きＮＢ－ＩｏＴデバイスに対してＳＭＳおよびＨＴＴＰがサポートされていない可能性があるため、既存のｅＵＩＣＣリモートプロビジョニング方法は大半のＮＢ－ＩｏＴデバイスに適していない可能性があり、したがって、プロファイルのダウンロードおよびプロファイルの切り替えが正常に実行されない可能性がある。

しかしながら、世界のＩｏＴ市場では、所有するＮＢ－ＩｏＴデバイスにｅＵＩＣＣ技術を組み合わせて、低コストでグローバルな広域コネクティビティを実現しようと模索している大口顧客が多い。したがって、現在ＮＢ－ＩｏＴに対してＳＭＳ、ＨＴＴＰ、およびローミングがサポートされていなくてもＮＢ－ＩｏＴネットワーク内で機能するとともにＮＢ－ＩｏＴデバイスによって機能することができる、新しいｅＵＩＣＣリモートプロビジョニングソリューションが求められている。

したがって、本明細書に記載の実施形態は、プロキシサーバを利用して、ＮＢ－ＩｏＴデバイス内の識別情報モジュール（例えば、ｅＵＩＣＣ）へのプロファイルのリモート管理を可能にする。

本明細書に記載の実施形態は、ＧＳＭＡリモートＳＩＭプロビジョニング（ＲＳＰ：ｒｅｍｏｔｅ ＳＩＭ ｐｒｏｖｉｓｉｏｎｉｎｇ）標準に依存する制約付きＮＢ－ＩｏＴデバイスのためのｅＵＩＣＣリモートプロビジョニングを可能にすることを提案する。このソリューションは、コアネットワーク内の公開機能（例えば、サービス能力公開機能（ＳＣＥＦ：Ｓｅｒｖｉｃｅ Ｃａｐａｂｉｌｉｔｙ Ｅｘｐｏｓｕｒｅ Ｆｕｎｃｔｉｏｎ）またはネットワーク公開機能（ＮＥＦ：Ｎｅｔｗｏｒｋ Ｅｘｐｏｓｕｒｅ Ｆｕｎｃｔｉｏｎ））によって提供される非ＩＰデータ配信（ＮＩＤＤ）サービスを使用して、プロファイル管理サーバとＩｏＴデバイスとの間で、プロファイルダウンロードメッセージおよびプロファイル管理メッセージを配信する。ＮＩＤＤサービスを使用すると、デバイスでのプロファイル管理動作をトリガすることが効果的に可能になり、制約付きＩｏＴデバイスによって送受信されるビット数を低減することもできる。

プロファイル管理サーバとＮＢ－ＩｏＴネットワークの公開機能の間でプロキシサーバを使用して、プロファイル管理サーバでの３ＧＰＰ固有のネットワーク関連機能の知識を省くとともに、ＩｏＴデバイスが複数のアプリケーションサーバと同時に通信できるようにすることができる。デバイス／コネクティビティ（Ｄ／Ｃ）管理サーバは、ビジネスプロセスを制御し、企業顧客とモバイルネットワークオペレータとの両方と対話し、エンドツーエンド通信フロー／設定を可能にし、ｅＵＩＣＣリモートプロビジョニング手順を開始および管理し得る。

本明細書に記載の実施形態は、ＮＢ－ＩｏＴデバイスが、ローカルモバイルネットワークオペレータから新しいプロファイルをダウンロードして有効化するために、ｅＵＩＣＣで（グローバルモバイルネットワークオペレータからの）事前にプロビジョニングされたプロファイルを使用する訪問ネットワークを介してプロファイル管理サーバに接続できるようなＮＢ－ＩｏＴに対してサポートされているローミングに依存し得る。現在、オペレータによって、ＮＢ－ＩｏＴローミングのビジネスセットアップについての合意を試みる取り組みが進行中であり、ここではそのようなセットアップが合意されているものと仮定する。

本明細書に記載の実施形態は、配信技術およびデバイスタイプの様々なセットアップに対処し、ソリューションの詳細は本質的に異なるが共通の手法を共有している様々な例について検討する。セットアップにおける違いにより、目標を達成するためにソリューションが非自明な方法で作成される場合がある。一実施形態では、ＧＳＭＡ ＲＳＰ Ｍ２Ｍ版によるリモートプロビジョニングが使用される。この場合、ＮＢ－ＩｏＴネットワークの公開機能ＮＩＤＤサービスを使用して、現在はプロファイル管理サーバとＩｏＴデバイスのｅＵＩＣＣとの間でＳＭＳとして送信される、プロファイルダウンロードメッセージおよびプロファイル管理メッセージを配信することができる。ＮＩＤＤソリューションは、制約付きＩｏＴデバイスとプロファイル管理サーバとの間で他の（ＳＭＳ以外の）プロファイルダウンロードおよびプロファイル管理関連のメッセージを転送する場合にも使用することができ、これにより、制約付きＩｏＴデバイスによって送受信されるビット数が削減される。ＮＩＤＤサービスを制約付きアプリケーションプロトコル（ＣｏＡＰ：Ｃｏｎｓｔｒａｉｎｅｄ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）または高信頼データサービス（ＲＤＳ：Ｒｅｌｉａｂｌｅ Ｄａｔａ Ｓｅｒｖｉｃｅ）プロトコルと組み合わせて使用すると、デバイスがＨＴＴＰ／ＴＣＰ／ＩＰスタックをサポートしていない場合でも、デバイスとプロファイル管理サーバとの間でプロキシサーバを介してＨＴＴＰＳメッセージを信頼できる方法で交換することができる。

いくつかの実施形態において、ＧＳＭＡ ＲＳＰ消費者版によるリモートプロビジョニングが使用される。ここでは、Ｄ／Ｃ管理サーバは、ＮＢ－ＩｏＴデバイス内のローカルプロファイルアシスタント（ＬＰＡｄ）を介して、プロファイルダウンロードおよびプロファイル管理動作をリモートで制御し得る。この場合、公開機能ＮＩＤＤサービスを使用して、ＬＰＡｄでのプロファイルダウンロードおよびプロファイル管理動作のトリガ、ならびにＮＢ－ＩｏＴデバイスとプロファイル管理サーバおよびＤ／Ｃ管理サーバとの間でのプロファイルダウンロードおよびプロファイル管理に関連するメッセージの転送を行うことができ、これにより、ＮＢ－ＩｏＴデバイスによって送受信されるビット数が削減される。いくつかの例では、ＩｏＴに適合したＧＳＭＡ ＲＳＰ消費者版によるリモートプロビジョニングが検討され、公開機能ＮＩＤＤサービスは、同様の方法でソリューションを提供する。

本明細書に記載の実施形態は、デバイスがＧＳＭＡリモートＳＩＭプロビジョニング標準をサポートする統合ＵＩＣＣ（ｉＵＩＣＣ：ｉｎｔｅｇｒａｔｅｄ ＵＩＣＣ）を備えた統合ＳＩＭ（ｉＳＩＭ）ソリューションにも適用される。本明細書に記載の実施形態は、ＧＳＭＡリモートＳＩＭプロビジョニング標準をサポートする（取り外し可能な）ＵＩＣＣまたはＥＴＳＩスマートセキュアプラットフォーム（ＳＳＰ）にも適用され得る。

本明細書に記載の実施形態は、既存のＧＳＭＡ ＲＳＰ標準、具体的にはＭ２Ｍ版を、ＧＳＭＡ ＲＳＰ準拠のＳＭ－ＳＲで必要とされる最小限の変更のみで、標準Ｍ２Ｍ準拠のｅＵＩＣＣを備えたＮＢ－ＩｏＴデバイスにも使用できるようにする。ＳＭＳがＮＢ－ＩｏＴネットワークによってサポートされていないという問題は、公開機能ＮＩＤＤサービスを使用したデバイスとの通信によって回避される。公開機能およびプロキシサーバを使用すると、制約付きＩｏＴデバイスがＨＴＴＰ／ＴＣＰ／ＩＰスタックをサポートしていない場合の問題も解決される。ＮＩＤＤ技術を使用すると、送信されるビット数を最小限に抑えることができ、したがって、制約付きデバイスの消費電力も削減することができる。

図１は、１つまたは複数の異なるタイプのＮＢ－ＩｏＴデバイス内の識別情報モジュールにおいてプロファイルを管理するために使用され得る複数のノードを示す、ネットワーク１００のブロック図である。

ＮＢ－ＩｏＴデバイスは、セルラＮＢ－ＩｏＴモデムおよび識別情報モジュール（例えば、ｅＵＩＣＣ）を備えると見なされ得る。識別情報モジュールは、ＧＳＭＡによるリモートＳＩＭプロビジョニングをサポートするように設定され得、リモートでのプロファイルダウンロードおよびプロファイル管理のための資格情報を備え得る。

ＮＢ－ＩｏＴネットワークは、ＮＢ－ＩｏＴデバイスが、ローカルモバイルネットワークオペレータから新しいプロファイルをダウンロードして有効化するために、ｅＵＩＣＣで（グローバルモバイルネットワークオペレータからの）事前にプロビジョニングされたプロファイルを使用して訪問ネットワークを介して接続できるように、ローミングをサポートし得る。

具体的には、図１は、第１のＮＢ－ＩｏＴデバイス１０１ａを示す。ＮＢ－ＩｏＴデバイス１０１ａは、第１のタイプのＮＢ－ＩｏＴデバイスを含む。第１のタイプのＮＢ－ＩｏＴデバイスは、アプリケーションサーバとの通信のために公開機能１０４（例えば、４Ｇの場合はＳＣＥＦ、または５Ｇの場合はＮＥＦ）を介して３ＧＰＰ非ＩＰデータ配信（ＮＩＤＤ）メカニズムを使用するデバイスを含む。この第１のタイプのＮＢ－ＩｏＴデバイスは、非ＩＰデバイス（例えば、伝送制御プロトコル／インターネットプロトコル（ＴＣＰ／ＩＰ：Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）もしくはユーザデータグラムプロトコル／ＩＰ ＵＤＰ／ＩＰプロトコルスタックをサポートしないデバイス）、またはＩＰベースのデバイス（例えば、ＴＣＰ／ＩＰもしくはＵＤＰ／ＩＰプロトコルスタックのいずれかをサポートしているが、例えば、送信されるビット数を最小限に抑える（したがって、デバイスの電力消費を削減し得る）ためであるかどうかに関わらず、ＮＩＤＤを使用しているデバイス）のいずれかを含み得る。

ネットワーク１００は、第２のＮＢ－ＩｏＴデバイス１０１ｂをさらに含む。ＮＢ－ＩｏＴデバイス１０１ｂは、第２のタイプのＮＢ－ＩｏＴデバイスを含む。第２のタイプのＮＢ－ＩｏＴデバイスは、アプリケーションサーバとの通信のためにパケットゲートウェイ（Ｐ－ＧＷ）１０２を介して３ＧＰＰ非ＩＰデータ配信（ＮＩＤＤ）メカニズムを使用するデバイスを含む。この第２のタイプのＮＢ－ＩｏＴデバイスは、非ＩＰデバイス（例えば、伝送制御プロトコル／インターネットプロトコル（ＴＣＰ／ＩＰ）もしくはユーザデータグラムプロトコル／ＩＰ ＵＤＰ／ＩＰプロトコルスタックをサポートしないデバイス）、またはＩＰベースのデバイス（例えば、ＴＣＰ／ＩＰもしくはＵＤＰ／ＩＰプロトコルスタックのいずれかをサポートしているが、例えば、送信されるビット数を最小限に抑える（したがって、デバイスの電力消費を削減し得る）ためであるかどうかに関わらず、ＮＩＤＤを使用しているデバイス）のいずれかを含み得る。

ネットワーク１００は、第３のＮＢ－ＩｏＴデバイス１０１ｃをさらに含む。第３のＮＢ－ＩｏＴデバイス１０１ｃは、第３のタイプのＮＢ－ＩｏＴデバイスを含む。第３のタイプのＮＢ－ＩｏＴデバイスは、ＮＢ－ＩｏＴ ＩＰベースのサービスを使用してアプリケーションサーバと通信するように設定されたＩＰベースのデバイスを含む。ＩＰベースのトラフィックは、例えば、コントロールプレーンシグナリングを介して、例えば、モビリティ管理エンティティ（ＭＭＥ：ｍｏｂｉｌｉｔｙ ｍａｎａｇｅｍｅｎｔ ｅｎｔｉｔｙ）に、さらにサービングゲートウェイ（Ｓ－ＧＷ）１０３に送信されるか、または専用のユーザプレーンベアラを介して直接Ｓ－ＧＷに、その後さらにＰ－ＧＷ１０２に送信され得る。

ネットワーク１００は、公開機能１０４をさらに含む。この例では、公開機能１０４は、アプリケーションサーバによって使用するためのＲＥＳＴｆｕｌ ＡＰＩを使用して３ＧＰＰセルラネットワークのサービスおよび能力を公開するように設定され得るサービス能力公開機能（ＳＣＥＦ）を含む。しかしながら、公開機能１０４が、同様に５Ｇコアネットワークアーキテクチャによるネットワーク公開機能（ＮＥＦ：Ｎｅｔｗｏｒｋ Ｅｘｐｏｓｕｒｅ Ｆｕｎｃｔｉｏｎ）も含み得ることが理解されよう。公開機能１０４によって公開されるサービスは、非ＩＰデータ配信（ＮＩＤＤ）サービスおよび監視サービスを含み得る。アプリケーションサーバは、例えば、上記の第１のタイプのＮＢ－ＩｏＴデバイスと通信するためにＮＩＤＤサービスを利用し得る。

例えば、アプリケーションサーバは、ＮＩＤＤサービスを使用して第１のＮＢ－ＩｏＴデバイス１０１ａと通信し得る。ＮＩＤＤを使用するとき、第１のＮＢ－ＩｏＴ １０１ａデバイスは、（ＩＰを使用せずに）メッセージを送受信することができ、これらのメッセージは、非アクセス階層（ＮＡＳ）シグナリングプロトコルでシグナリングデータとして伝達される。ＮＡＳシグナリングは、第１のＮＢ－ＩｏＴデバイス１０１ａとモビリティ管理エンティティ（ＭＭＥ）１０５との間で行われ得る。次いで、メッセージは、ＭＭＥ１０５から公開機能１０４に中継され得る。公開機能１０４のサービスを使用するために、アプリケーションサーバは、最初に公開機能１０４に登録するよう要求され得、使用したいサービスおよび対象となるデバイスを示し得る。各ＮＢ－ＩｏＴデバイスには、外部識別子またはＭＳＩＳＤＮが割り当てられ、これらは、ＩＭＳＩなどの他の加入詳細とともにホーム加入者サービス（ＨＳＳ：Ｈｏｍｅ Ｓｕｂｓｃｒｉｂｅｒ Ｓｅｒｖｉｃｅ）１０６に登録され得る。今後数年間でＭＴＣデバイスの数が増加すると、電話番号（すなわち、ＭＳＩＳＤＮ）が不足することになる。３ＧＰＰソリューションは、新しい識別子を加入データの一部として規定し、ＭＳＩＳＤＮが割り当てられていない動作を、代わりに新しい識別子を使用することによって可能にする。この新しい識別子の名称は「外部識別子」である。しかしながら、簡単にするために、本明細書では、「外部識別子」という用語は、ＭＳＩＳＤＮを包含すると理解されるべきである。次いで、外部識別子をアプリケーションサーバが使用して、ターゲットとするデバイスにインデックス付けすることができる。外部識別子の他の例には、車両登録／ＶＩＮ番号、スマートメータのシリアル番号、ＱＲコードなどが含まれる。

セルラネットワークは、Ｐ－ＧＷ１０２を介したポイントツーポイントトンネルを使用したＮＩＤＤトランスポートモードも提供する。例えば、第２のＮＢ－ＩｏＴデバイス１０１ｂは、（ＩＰを使用せずに）メッセージを送受信するように設定され得、これらのメッセージは、デバイスとＭＭＥ１０５との間のＮＡＳシグナリングプロトコルでシグナリングデータとして伝達される。次いで、メッセージはさらに、ＭＭＥ１０５からＳ－ＧＷ１０３に、さらにＰ－ＧＷ１０２へ中継され得る。Ｐ－ＧＷ１０２は、透過的な転送ノードとして作用し得る。ＮＢ－ＩｏＴデバイスごとに、Ｐ－ＧＷは、ＮＢ－ＩｏＴデバイスによって使用されるＰＤＮ接続のＡＰＮに基づいて、パケットの転送先および転送元となるアプリケーションサーバに関する知識を有し得る。Ｐ－ＧＷ１０２は、ＮＢ－ＩｏＴデバイスから受信したパケットをアプリケーションサーバに転送する前に、そのパケットにＵＤＰ／ＩＰヘッダを追加し得、アプリケーションサーバから受信したパケットをＮＢ－ＩｏＴデバイスに転送する前に、そのパケットからＵＤＰ／ＩＰヘッダを除去し得る。Ｐ－ＧＷ１０２はまた、アプリケーションサーバとの通信で使用するために、各ＮＢ－ＩｏＴデバイスにＩＰアドレスおよびポートを割り当て得る。

ネットワーク１００は、プロファイル管理サーバ１０７をさらに含む。プロファイル管理サーバは、プロファイルプロビジョニングおよびプロファイル管理動作（プロファイルの有効化、無効化、削除など）のために使用され得る。プロファイル管理サーバのタスクは、プロファイルのダウンロードをハンドリングするプロビジョニングサーバおよびプロファイル管理動作をハンドリングする管理サーバなどの別々のサーバによって実行される異なるタスクに分割され得るが、簡単にするために、単一のプロファイル管理サーバ１０７が示されている。

ＮＩＤＤを使用してＮＢ－ＩｏＴデバイスと通信する例では、プロファイル管理サーバ１０７は、公開機能１０４またはＰ－ＧＷ１０２に登録／設定され得、したがって、ＮＩＤＤを使用してこれらのノードを介してＮＢ－ＩｏＴデバイスと通信し得る。しかしながら、これらのＮＢ－ＩｏＴデバイスは、プロファイル管理サーバ１０７との通信と並行して、他の（アプリケーション）サーバと通信する必要があり得る。この並列通信を可能にするために、プロキシサーバ１０８が間で使用される。プロキシサーバ１０８は、公開機能１０４またはＰ－ＧＷ１０２に登録／設定され得るか、またはＮＢ－ＩｏＴデバイスとの間のトラフィックがプロキシサーバ１０８に送信され得、次いで、プロキシサーバ１０８は、異なるＮＢ－ＩｏＴデバイスによって生成されたメッセージを、必要に応じて別のアプリケーションサーバに転送し得る。

通常、デバイスで生成されたメッセージを正しいアプリケーションサーバへ方向付けるために、プロキシサーバによって、送信先のＩＰアドレスおよびポートが使用される。しかしながら、ここでは（ＩＰエンドツーエンドなしで）、プロキシサーバがＮＢ－ＩｏＴデバイスの１つのアプリケーションからのトラフィックを適切なアプリケーションサーバに接続できるように調整するかどうかは、プロキシサーバ、およびＮＢ－ＩｏＴデバイスのアプリケーション次第であり得る。プロキシサービスに加えて、プロキシサーバは、監視および通知サービスなど（ＳＣＥＦサービスおよび他のコアネットワークサービスに基づく）他のサービスを、プロファイル管理サーバを含むアプリケーションサーバに提供し得る。したがって、ＮＢ－ＩｏＴデバイス１０１ａから１０１ｃのいずれかにおける識別情報モジュールのためのプロファイルのリモート管理は、プロキシサーバ１０８を介して管理され得る。

ＩｏＴデバイス（またはＮＢ－ＩｏＴデバイス）を所有する企業は、モバイルネットワークオペレータ（ＭＮＯ）で自社のＩｏＴデバイスのための新しいセルラ加入（プロファイルと呼ばれ得る）を申し込むことができる。プロファイルは、プロファイル管理サーバ１０７において準備され、ダウンロードに使用できるようにされ得る。企業は、準備されたプロファイルを識別するプロファイル識別子のセットをＭＮＯから受信し得る。プロファイル識別子の例は、集積回路カード識別子（ＩＣＣＩＤ：Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ Ｃａｒｄ Ｉｄｅｎｔｉｆｉｅｒ）、国際移動体加入者識別情報（ＩＭＳＩ：Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｍｏｂｉｌｅ Ｓｕｂｓｃｒｉｂｅｒ Ｉｄｅｎｔｉｔｙ）、アクティベーションコード（ＡＣ）、およびマッチングＩＤである。次いで、企業は、デバイスコネクティビティ（Ｄ／Ｃ）管理サーバ１０９を利用して、企業が所有するＩｏＴデバイスのうちの１つの識別情報モジュールでプロファイルダウンロードをトリガし、かつ／またはすでにダウンロードされたプロファイルでのプロファイル管理動作をトリガし得る。Ｄ／Ｃ管理サーバ１０９は、デバイス管理サーバを含み得るが、コネクティビティ管理をハンドリングするサーバでもあり得る。

図２は、プロキシサーバにおいて、ＮＢ－ＩｏＴデバイス内の識別情報モジュールのためにプロファイルのリモート管理を可能にするための方法を示す。例えば、図２の方法は、図１に示すプロキシサーバ１０８によって実行され得る。プロキシサーバは、１つまたは複数のそれぞれのＮＢ－ＩｏＴデバイスに関連付けられた１つまたは複数の外部識別子のデータベースにアクセスするように設定される。例えば、プロキシサーバ１０８は、ＮＢ－ＩｏＴデバイス１０１ａから１０１ｃの各々の外部識別子に関連する情報を含むデータベースにアクセスすることが可能であり得る。１つまたは複数の外部識別子は、コアネットワーク内の公開機能を介してそれぞれの１つまたは複数のＮＢ－ＩｏＴデバイスをアドレス指定するために使用される。上記のように、公開機能は、ＳＣＥＦまたはＮＥＦを含み得る。プロファイルの管理は、例えば、識別情報モジュールへの新しいプロファイルのプロビジョニング、プロファイルの有効化もしくは無効化、またはプロファイルの削除を含み得る。

外部識別子は、加入識別子を含み得る。例えば、外部識別子は、モバイルステーション国際加入者電話番号（ＭＳＩＳＤＮ：Ｍｏｂｉｌｅ Ｓｔａｔｉｏｎ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｓｕｂｓｃｒｉｂｅｒ Ｄｉｒｅｃｔｏｒｙ Ｎｕｍｂｅｒ）を含み得る。

ステップ２０１において、プロキシサーバは、トリガメッセージをＮＢ－ＩｏＴデバイスに配信するよう求める要求を受信し、要求は、デバイス識別子を含む。トリガメッセージは、プロファイルダウンロードトリガメッセージを含み得る。プロファイルダウンロードトリガメッセージは、プロファイル管理サーバからプロファイルをダウンロードするようＮＢ－ＩｏＴデバイスをトリガすることを目的とし得る。トリガメッセージは、プロファイル管理トリガメッセージを含み得る。プロファイル管理トリガメッセージは、プロファイル管理動作を実行するようＮＢ－ＩｏＴデバイス内の識別情報モジュールをトリガするように設定され得る。例えば、プロファイル管理動作は、識別情報モジュール内の既存のプロファイルを更新、有効化、無効化、または削除することであり得る。

ステップ２０２において、プロキシサーバは、受信したデバイス識別子に基づいて外部識別子を決定する。

ステップ２０３において、プロキシサーバは、外部識別子を使用して、トリガメッセージをＮＢ－ＩｏＴデバイスに配信する。

図３は、狭帯域モノのインターネット（ＮＢ－ＩｏＴ）デバイスにおいて、ＮＢ－ＩｏＴデバイス内の識別情報モジュールにおけるプロファイルのリモート管理を可能にするための方法を示す。プロファイルの管理は、ＮＢ－ＩｏＴデバイス内の識別情報モジュールにおける、新しいプロファイルのリモートプロビジョニングまたは既存のプロファイルの管理を含み得る。

ステップ３０１において、ＮＢ－ＩｏＴデバイスは、プロキシサーバによって配信されたトリガメッセージを受信する。例えば、ＮＢ－ＩｏＴデバイスは、図２によるプロキシサーバによって配信されたようなトリガメッセージを受信し得る。

図４は、図１および図２の方法の例をより詳細に示すシグナリング図である。具体的には、図４は、トリガメッセージがプロキシサーバ（例えば、図１のプロキシサーバ１０８）から配信され得る方法の例を示す。

４０１に示すように、プロキシサーバ１０８は、１つまたは複数のそれぞれのＮＢ－ＩｏＴデバイスに関連付けられた１つまたは複数の外部識別子のデータベースにアクセスするように設定される。プロキシサーバはまた、公開機能１０４のためにユニフォームリソースロケータを有するように設定され得る。

ステップ４０２ａに示す一例では、プロキシサーバ１０８は、１組のＮＢ－ＩｏＴデバイスと通信するＮＩＤＤサービスのために、公開機能１０４に登録される。この例では、（図２のステップ２０１に対応する）ステップ４０３において、プロキシサーバ１０８は、トリガメッセージをＮＢ－ＩｏＴデバイスに配信するよう求める要求を受信し、（図２のステップ２０２に対応する）ステップ４０４において、プロキシサーバは、受信したデバイス識別子に基づいて外部識別子を決定し、その後、方法はステップ４０５に進む。

ステップ４０５は、図２のステップ２０３が実行され得る方法の例を示す。ステップ４０５において、公開機能１０４によって提供されるＮＩＤＤサービスを使用して、トリガメッセージを配信する。プロキシサーバ１０８は、公開機能１０４に登録され得、ＮＩＤＤサービスのデータ送信コマンドを使用して、トリガメッセージをＮＢ－ＩｏＴデバイス１０１に送信し得る。公開機能１０４は、トリガメッセージをバッファリングし得、ＮＢ－ＩｏＴデバイス１０１が電源投入されてネットワークに登録されるとき、トリガメッセージをＮＢ－ＩｏＴデバイス１０１に送信し得る。公開機能１０４のＮＩＤＤサービスを使用することは、公開機能のＮＩＤＤサービスがデバイスとアプリケーションサーバとの間のデータ転送に使用される第１のタイプのＮＢ－ＩｏＴデバイスにとって自然なことであり得る。しかしながら、この実施形態は、他の場合ＮＢ－ＩｏＴデバイスとアプリケーションサーバとの間のデータ転送に公開機能のＮＩＤＤサービスを使用できないタイプ２およびタイプ３のデバイスにも使用できることが理解されよう。

別の例では、ステップ４０１に続いて、方法はステップ４０２ｂに進む。ステップ４０２ｂにおいて、プロキシサーバ１０８は、１組のＮＢ－ＩｏＴデバイスの監視サービスのために、公開機能１０４に登録される。監視サービスは、１組のＮＢ－ＩｏＴデバイスのうちの１つがいつネットワークに登録するかをプロキシサーバ１０８に示し得る。この例では、ステップ４０４に続いて、方法はステップ４０６に進む。具体的には、この例におけるステップ４０６から４０９は、図２のステップ２０３が実行され得る方法を示す。ステップ４０６において、プロキシサーバ１０８は、１組のＮＢ－ＩｏＴデバイスのうちの１つがネットワークに登録したことを示す通知を公開機能１０４から受信する。ステップ４０６は、ステップ４０３およびステップ４０４の前に行われ得ることが理解されよう。

ステップ４０７において、プロキシサーバは、公開機能１０４、Ｐ－ＧＷ１０２、またはネットワーク内の第３のノードのいずれかを使用して、外部識別子またはＭＳ
ＩＳＤＮに基づいて、ＮＢ－ＩｏＴデバイスの現在のＩＰアドレス（場合によってはポート）を取得する。したがって、プロキシサーバ１０８は、このサービスを使用して、公開機能１０４監視サービスと組み合わせて現在のＩＰアドレスを取得する。言い換えれば、ステップ４０７は、アドレス要求を第３のネットワークノードに送信することを含み得、アドレス要求は、外部識別子を含む。

ステップ４０８において、プロキシサーバ１０８は、ＮＢ－ＩｏＴデバイス１０１の現在のＩＰアドレスを受信し得、ステップ４０９において、受信したＩＰアドレスを使用してトリガメッセージをＮＢ－ＩｏＴデバイスに送信する。言い換えれば、プロキシサーバ１０８は、アドレス要求を送信したことに応答して、ＮＢ－ＩｏＴデバイスのＩＰアドレスを受信する。

具体的には、ステップ４０９は、ＩＰアドレスを利用してトリガメッセージを送信することを含む。例えば、プロキシサーバは、（例えば、タイプ２のデバイスの場合）Ｐ－ＧＷ１０２を介してしてＮＩＤＤを利用してトリガメッセージを送信し得る。いくつかの例において、ステップ４０９は、（例えば、タイプ３のデバイスの場合）デバイスのＩＰアドレスを使用して、ＵＤＰ／ＩＰまたはＴＣＰ／ＩＰを介してトリガメッセージをＮＢ－ＩｏＴデバイスに送信することを含む。したがって、トリガメッセージは、Ｐ－ＧＷ１０２およびＳ－ＧＷ１０３を介して、ＮＢ－ＩｏＴデバイス１０１にルーティングされ得る。

プロキシサーバ１０８の（上記の図４に示す）トリガメッセージ配信サービスは、様々な方法で実装され得る。選択肢の１つは、プロキシサーバ１０８が、制約付きアプリケーションプロトコル（ＣｏＡＰ）またはハイパーテキスト転送プロトコル（ＨＴＴＰ）サーバとして作用し、ＮＢ－ＩｏＴデバイスに送られるべきトリガメッセージをプロキシサーバ１０８に送信することによって、トリガメッセージ配信サービスを、アプリケーションサーバが使用するリソースとして提供することである。プロキシサービスにおけるこのサービスに対する各ＣｏＡＰ／ＨＴＴＰ要求には、トリガメッセージおよびデバイス識別子が含まれ得る。次いで、プロキシサーバ１０８は、外部識別子がデバイス識別子としてまだ使用されていない場合、データベース検索を利用して、受信したデバイス識別子を外部識別子に変換し得る。プロキシサーバ１０８のトリガメッセージ配信サービスは、プロキシサーバ１０８に事前登録されているか、またはトリガメッセージ配信サービス使用するためにオンライン認証サーバ（例えば、ＯＡｕｔｈ２サーバもしくはＡＣＥ認証サーバ）からアクセストークンを取得したアプリケーションサーバに限定され得る。

図５は、いくつかの実施形態によるプロファイルプロビジョニングプロセスの一例を示す。

ＮＢ－ＩｏＴデバイス１０１（例えば、ｅＵＩＣＣ）の識別情報モジュールは、ＮＢ－ＩｏＴデバイス１０１がセルラネットワークに接続することを可能にするアクティブなセルラ加入（すなわち、有効化されたプロファイル）を有するように設定され得る。これは、動作プロファイルの提供を可能にする目的で製造時にインストールされたプロファイルであり得るか、または以前にＮＢ－ＩｏＴデバイス１０１によってダウンロードされた動作プロファイルであり得る。

ＨＳＳ１０６は、ＮＢ－ＩｏＴデバイス１０１の加入者資格情報を有するように設定され得る。加入者資格情報は、公開機能１０４（例えば、ＳＣＥＦ）を介してデバイスをアドレス指定するために使用される外部識別子を含み得る。プロキシサーバ１０８は、ＮＢ－ＩｏＴデバイス１０１をアドレス指定することが可能な外部識別子を有するように設定され得る。プロファイル管理サーバ１０７は、ダウンロード可能であり得るプロファイルパッケージのセットを含み得る。プロファイルパッケージに対する対応するプロファイル識別子は、ＮＢ－ＩｏＴデバイスを所有する企業に提供され得、Ｄ／Ｃ管理サーバ１０９に提供され得る。所与のプロファイルパッケージについて、プロファイルに対応するモバイルネットワークのＨＳＳ１０６は、プロファイルパッケージの加入者資格情報に対応する加入者資格情報、およびＮＢ－ＩｏＴ１０１の外部識別子を有するように設定される。

簡単にするために、ここでは両方のモバイルネットワーク内で同じ外部識別子またはＭＳＩＳＤＮが使用されていると仮定する。それ以外の場合、２つの間で変換を実行する必要がある（例えば、変換が発生するプロキシサーバに新しい外部識別子が設定される）。

ステップ５０１において、Ｄ／Ｃ管理サーバ１０９は、プロファイルのダウンロードをトリガするためのコマンドをプロファイル管理サーバ１０７に送信する。ステップ５０１において、Ｄ／Ｃ管理サーバ１０９は、少なくとも、プロファイルがダウンロードされるＮＢ－ＩｏＴデバイス１０１のデバイス識別子、ダウンロードされるプロファイルに対応するプロファイル識別子、およびプロキシサーバ１０８のＵＲＬを提供し得る。デバイス識別子は、プロファイル管理サーバによって、プロファイルダウンロードがトリガされるべきデバイスを識別するために使用され、プロファイル識別子は、ダウンロードされるプロファイルを識別する。デバイス識別子の例は、ＩＭＥＩ、外部識別子、ＭＳＩＳＤＮ、モデムモジュール識別子、およびｅＵＩＣＣ ＩＤ（ＥＩＤ）である。

ステップ５０２において、プロファイル管理サーバ１０７は、トリガメッセージをＮＢ－ＩｏＴデバイス１０１に配信するよう求める要求をプロキシサーバ１０８に送信し、要求は、デバイス識別子を含む（ステップ５０２は、図２のステップ２０１に対応し得る）。このトリガメッセージは、プロファイル管理サーバ１０７のＵＲＬを含み得る。プロファイル管理サーバ１０７はまた、トリガメッセージが適用されるＮＢ－ＩｏＴデバイス１０１のデバイス識別子を示し得る。いくつかの例において、ＮＢ－ＩｏＴデバイス１０１は、プロファイル管理サーバ１０７のＵＲＬを有するように事前設定され得、ＮＢ－ＩｏＴデバイス１０１の最初の起動時にステップ５０４を実行するように設定され得る。

ステップ５０３において、プロキシサーバ１０８は、ステップ５０２で受信したデバイス識別子によって識別されるＮＢ－ＩｏＴデバイスにトリガメッセージを配信する。具体的には、プロキシサーバは、ステップ５０２で受信したデバイス識別子に基づいて外部識別子を決定し得る。デバイス識別子が外部識別子と異なる場合、プロキシサーバは、提供されたデバイス識別子を使用してデータベース内の外部識別子を検索する。次いで、ステップ５０３は、図４に示すように実施され得る。いくつかの例において、ステップ５０３は任意選択であり、ＮＢ－ＩｏＴデバイス１０１がプロファイル管理サーバ１０７のＵＲＬを有するように事前設定され、デバイスの最初の起動時にステップ５０４を実行するように設定されている場合、実行されない。

ステップ５０４において、ＮＢ－ＩｏＴデバイス１０１は、ＮＢ－ＩｏＴデバイス１０１の識別情報モジュールとプロファイル管理サーバ１０７との間のセキュア通信を確立し得る。

ステップ５０５において、ＮＢ－ＩｏＴデバイス１０１およびプロファイル管理サーバ１０７は、例えば、相互認証を含むセキュア通信を確立するためにメッセージを交換する。

ステップ５０６において、ＮＢ－ＩｏＴデバイス１０１は、プロファイル管理サーバ１０７からプロファイルパッケージをダウンロードする。プロファイル管理サーバ１０７は、ステップ５０１で受信したデバイス識別子およびプロファイル識別子に基づいて、どのプロファイルパッケージをＮＢ－ＩｏＴデバイス１０１にダウンロードするかを認識する。次いで、ＮＢ－ＩｏＴによって、プロファイルパッケージが識別情報モジュールにインストールされ得る。例えば、ステップ５０６は、プロファイル管理サーバからプロファイルを受信することと、プロファイルを識別情報モジュールにインストールすることとを含み得る。

ステップ５０７において、プロファイル管理サーバ１０７は、任意選択として、トリガメッセージの結果について報告する応答をＤ／Ｃ管理サーバ１０９に提供し得る。例えば、プロファイル管理サーバ１０７は、プロファイルがＮＢ－ＩｏＴ１０１に正常にダウンロードされたか否かをＤ／Ｃ管理サーバ１０９に示し得る。

いくつかの例において、プロファイルは、新しいモバイルネットワークのプロファイルであり得る。これらの例では、Ｄ／Ｃ管理サーバ１０９は、ステップ５０８において、ＮＢ－ＩｏＴデバイス１０１について新しいモバイルネットワークに切り替えるよう求める要求をプロキシサーバ１０８に送信し得る。例えば、新しいモバイルネットワークに切り替えるよう求める要求は、プロキシサーバが、新しいモバイルネットワークに属するＰ－ＧＷなどを公開機能に登録することを求める要求を含み得る。Ｐ－ＧＷの場合、プロキシサーバはプロファイルの申込み／準備フェーズからＮＩＤＤで使用するように事前設定されている可能性があり、その場合このステップは省略され得ることに留意されたい。

ステップ５０８が実行される場合、プロキシサーバは、ステップ５０９において、新しいモバイルネットワークに登録し得る。例えば、プロキシサーバ１０８は、ＮＢ－ＩｏＴデバイス１０１から送信された任意のデータが新しいモバイルネットワークを介してアプリケーションサーバにルーティングされ得るように、新しいモバイルネットワークに登録し得る。登録が行われると、プロキシサーバ１０８は、古いモバイルネットワークを介してＮＢ－ＩｏＴデバイスにデータを送信するように設定されたまま、プロファイルが有効化されて切り替えが完了した状態が確立されるまで、両方のモバイルネットワークを介してＮＢ－ＩｏＴデバイスからデータを受信することが可能になり得、すなわち、プロキシサーバは、新しいモバイルネットワークを介してＮＢ－ＩｏＴデバイスにデータを送信するように設定される。

いくつかの例において、プロファイルは、ＮＢ－ＩｏＴへのプロファイルのダウンロードとは別に有効化され得る。これらの例では、ステップ５０６において、プロファイルがダウンロードされ得、ステップ５１０において、Ｄ／Ｃ管理サーバ１０９が、プロファイルの有効化をトリガするよう求める要求をプロファイル管理サーバ１０７に送信し得る。プロファイルの有効化をトリガするよう求める要求は、デバイス識別子、プロファイル識別子、およびプロキシサーバ１０８のＵＲＬを含み得る。このステップは任意選択であり、プロファイルの有効化は、Ｄ／Ｃ管理サーバがプロファイルダウンロードのためにプロファイル管理サーバをトリガするステップ５０１の一部であり得る。

ステップ５１０においてプロファイルの有効化をトリガするよう求める要求を受信したことに応答して、プロファイル管理サーバ１０７は、ステップ５１１において、ダウンロードされたプロファイルの有効化をトリガする情報を含むメッセージをプロキシサーバ１０８に送信し得る。このメッセージは、プロファイル管理サーバ１０７のＵＲＬを含み得る。プロファイル管理サーバ１０７はまた、メッセージが適用されるＮＢ－ＩｏＴデバイス１０１のデバイス識別子を示し得る。このステップは、ＮＢ－ＩｏＴデバイス１０１が依然としてアクティブである間にプロファイルダウンロードの直後にプロファイルの有効化が行われる場合は任意選択であり得、その場合、ステップ５１５が直ちに実行され得る。

ステップ５１２において、プロキシサーバ１０８は、ステップ５１１で受信したデバイス識別子によって識別されるＮＢ－ＩｏＴデバイス１０１に、ダウンロードされたプロファイルの有効化をトリガするためのメッセージを配信する。上記のように、このステップでは、トリガメッセージは、図４で説明されているようにＮＢ－ＩｏＴデバイスに配信され得る。ステップ５１２は任意選択であり、ステップ５１１が実行されない場合、実行されない可能性がある。また、以下に説明するステップ５１５のプロファイル有効化要求メッセージが、プロファイルの有効化をトリガするよう求める要求の一部として含まれ、すでに確立されたセキュリティアソシエーションを使用してプロファイル管理サーバ１０７からＮＢ－ＩｏＴデバイス１０１にエンドツーエンドで保護される場合もあり、この場合、プロファイル管理サーバ間のセキュア通信のさらなる確立（例えば、ステップ５１４）は必要とされない場合がある。

ステップ５１４において、ＮＢ－ＩｏＴデバイス１０１は、ＮＢ－ＩｏＴデバイス１０１の識別情報モジュールとプロファイル管理サーバ１０７との間のセキュア通信を確立し得る。このステップは任意選択であり、プロキシサーバ１０８からプロファイルの有効化をトリガするよう求める要求がない場合（例えば、ステップ５１２がない場合）、実行されない可能性がある。また、ステップ５１５のプロファイル有効化要求メッセージが、プロファイルの有効化をトリガするよう求める要求の一部として含まれ、プロファイル管理サーバからエンドツーエンドで保護されている場合、ステップ５１４は実行されない可能性がある。次いで、ＮＢ－ＩｏＴデバイスおよびプロファイル管理サーバ１０７は、メッセージを交換して、相互認証を含むセキュア通信を確立し得る。

ステップ５１５において、プロファイル管理サーバ１０７は、プロファイルを有効化するよう求める要求メッセージをデバイスに送信する。上記のように、このような小さいメッセージの場合、またプロファイルの有効化をトリガするよう求める要求が以前に送信されている場合、要求メッセージは、プロファイルの有効化をトリガするよう求める要求の一部として含まれる場合があり、その場合、ステップ５１３～５１５は実行されないことに留意されたい。ＮＢ－ＩｏＴデバイス１０１内の識別情報モジュールは、要求メッセージを処理し、プロファイルを有効化し得る。ＮＢ－ＩｏＴデバイス１０１からプロファイル管理サーバ１０７に返送される応答メッセージが準備され得る。ステップ５１４でセキュア通信が確立されていない場合、応答メッセージは、すでに確立されたセキュリティアソシエーションを使用して保護され得る。

ステップ５１６において、プロファイル管理サーバ１０７は、任意選択として、動作の結果について報告する応答をＤ／Ｃ管理サーバ１０９に提供する。例えば、プロファイル管理サーバ１０７は、プロファイルが有効化されたか否かを報告し得る。

プロファイルの有効化が成功し、プロファイルが新しいモバイルネットワークオペレータにあることに応答して、Ｄ／Ｃ管理サーバ１０９は、ステップ５１７において、新しいモバイルネットワークオペレータからのサービスを使用するように切り替えるようにプロキシサーバ１０８に命令し得る。例えば、プロキシサーバ１０８は、プロファイルが変更された特定のＮＢ－ＩｏＴデバイスの新しいモバイルネットワークで公開機能（例えば、ＳＣＥＦ）および／またはＰ－ＧＷを使用するように切り替えるように命令され得る。新しいモバイルネットワークへの登録は、以前に（例えば、ステップ５０９において）行われている可能性がある。ＮＢ－ＩｏＴデバイスのデバイス識別子は、使用される様々なＭＮＯサービス（ＳＣＥＦ、Ｐ－ＧＷなど）へのＵＲＬとともに提供され得る。

ステップ５１８において、プロキシサーバ１０８は、プロキシサーバ１０８の設定を、アプリケーションサーバからＮＢ－ＩｏＴデバイス１０１へのデータが今度は新しいモバイルネットワークを介して転送されるように変更し得る。プロキシサーバ１０８はまた、古いモバイルネットワークサービスから登録解除し得る。

フローの後半部分、例えばステップ５０８～５１８は、プロファイルの有効化、プロファイルの無効化、およびプロファイルの削除などの任意のスタンドアロンのプロファイル管理動作に適用され得る。ステップ５０８、５０９、５１７、および５１８は、プロファイルが有効化されている場合にのみ関連する可能性があり、これは、あるＭＮＯから別のＭＮＯへの切り替えも意味する。

制約付きアプリケーションプロトコル（ＣｏＡＰ）は、アプリケーション関連のメッセージを転送するために制約付きＩｏＴデバイスで使用するためのプロトコルである。いくつかの実施形態において、ＣｏＡＰは、プロファイルダウンロードおよびプロファイル管理関連のメッセージを転送するために、ＮＢ－ＩｏＴデバイス１０１とプロファイル管理サーバ１０７との間で使用される。

いくつかの実施形態において、プロファイル管理（新しいプロファイルの管理およびプロビジョニングを含む）は、ＧＳＭＡ ＲＳＰ Ｍ２Ｍ版による。この例では、プロファイル管理サーバ１０７は、ＳＭ－ＳＲおよびＳＭ－ＤＰと呼ばれる２つのサーバによって表され得る。ＳＭ－ＳＲおよびＳＭ－ＤＰは、企業が新しい加入プロファイルを申し込んだＭＮＯによって運用され得るか、または、ＳＭ－ＳＲおよびＳＭ－ＤＰは、サードパーティによって運用され得、ＭＮＯに提供されるサービスの一部であり得る。ＳＭ－ＳＲおよびＳＭ－ＤＰは、同じ場所に配置されて同一のエンティティによって管理され得るか、または離れた場所にあり、異なる当事者によって運営され得る。ＳＭ－ＳＲおよびＳＭ－ＤＰが、ＭＮＯが使用するサードパーティのサービスである場合、Ｄ／Ｃ管理サーバ１０９をＳＭ－ＤＰおよびＳＭ－ＳＲとリンクするプロファイル管理動作用の顧客向けのインターフェースを提供するＭＮＯポータルも、プロファイル管理サーバの一部として含まれる。

リモートでのプロファイルダウンロードおよびプロファイル管理に関連するＮＢ－ＩｏＴ１０１内の識別情報モジュールとのオーバージエアでのセキュア通信は、ＳＭ－ＳＲによって排他的にハンドリングされ得る。セキュア通信は、ＳＭ－ＳＲと識別情報モジュールとの間で共有される資格情報に基づき得る。ＳＭ－ＤＰは、ＳＭ－ＳＲと識別情報モジュールとの間に確立されたセキュア通信トンネルを介してプロファイルダウンロードをハンドリングするエンティティであり得る。また、ＳＭ－ＳＲは、プロファイル管理動作（プロファイルの有効化、無効化、および削除）を制御するエンティティであり得る。ＳＭ－ＳＲとＳＭ－ＤＰとＭＮＯポータルとの間の個々の通信はＧＳＭＡ ＲＳＰ標準に従い得ると仮定することができ、したがって、この通信の詳細は本明細書に含まれていない。しかしながら、ＳＭ－ＳＲとＳＭ－ＤＰとＭＮＯポータルとの間のこの通信は、任意の適切な通信方法を含み得ることが理解されよう。セキュア通信トンネル内で実行される識別情報モジュールとＭＮＯポータル／ＳＭ－ＤＰ／ＳＭ－ＳＲとの間の通信についても同様である。

ＳＭ－ＳＲ１０７間のセキュア通信は、（保護された）ＳＭＳ、ＨＴＴＰＳ、およびカードアプリケーションツールキットトランスポートプロトコル（ＣＡＴ＿ＴＰ）に基づき得る。ＳＭＳは、ＨＴＴＰＳおよびＣＡＴ＿ＴＰセッションをトリガするために、また１つまたはいくつかのＳＭＳに適合する単純なコマンドのために使用され得る。ＨＴＴＰＳまたはＣＡＴ＿ＴＰは、データ集約型の転送、例えば、プロファイルダウンロードに関連する転送のために使用され得る。

図６は、図５に示したシグナリング図の一例を示す。この例は、ＧＳＭＡ ＲＳＰ Ｍ２Ｍ版の使用に関連し得る。標準ＧＳＭＡ ＲＳＰの構成要素（例えば、ＳＭ－ＳＲ）およびＭ２Ｍ版をサポートする識別情報モジュールへの変更の数を最小限に抑え、プロファイル管理サーバ１０７におけるプロキシサーバ１０８、デバイスＩＤなどの知識を最小限に抑えるために、通信フローは、プロファイルの有効化をトリガするためのトリガメッセージおよび要求がＤ／Ｃ管理サーバ１０９を介してルーティングされるように修正される。

上記で示したように、ＮＢ－ＩｏＴデバイス１０１はＳＭＳをサポートしていないので、トリガメッセージは、図４を参照して説明したように送信され得る。この例では、トリガメッセージは、ＧＳＭＡ ＲＳＰで使用されるＳＭＳ形式と同じ形式であり得る。例えば、ＳＭＳ形式は、ＥＴＳＩによって規定された拡張リモートＡＰＤＵコマンド構造を含み得る。したがって、識別情報モジュールの観点からは、識別情報モジュールは、ＳＭＳサービスをサポートするデバイスで使用されるときと同一のメッセージをＮＢ－ＩｏＴデバイスから受信することになる。同様に、ＳＭ－ＳＲおよびＳＭ－ＤＰの場合、これらは、標準によるＳＭＳ形式のトリガメッセージを作成し得るが、ＳＭＳサービスを使用してＳＭＳメッセージを送信することはない。代わりに、ＮＢ－ＩｏＴデバイス１０１への配信のために、ＳＭＳトリガメッセージがＤ／Ｃ管理サーバ１０９に提供される。

ＮＢ－ＩｏＴデバイス１０１（例えば、ｅＵＩＣＣ）の識別情報モジュールは、ＮＢ－ＩｏＴデバイス１０１がセルラネットワークに接続することを可能にするアクティブなセルラ加入（すなわち、有効化されたプロファイル）を有するように設定され得る。これは、動作プロファイルの提供を可能にする目的で製造時にインストールされたプロファイルであり得るか、または以前にＮＢ－ＩｏＴデバイス１０１によってダウンロードされた動作プロファイルであり得る。

ＨＳＳ１０６は、ＮＢ－ＩｏＴデバイス１０１の加入者資格情報を有するように設定され得る。加入者資格情報は、公開機能１０４（例えば、ＳＣＥＦ）を介してデバイスをアドレス指定するために使用される外部識別子を含み得る。プロキシサーバ１０８は、ＮＢ－ＩｏＴデバイス１０１をアドレス指定することが可能な外部識別子を有するように設定され得る。プロファイル管理サーバ１０７は、ダウンロード可能であり得るプロファイルパッケージのセットを含み得る。プロファイルパッケージに対する対応するプロファイル識別子は、ＮＢ－ＩｏＴデバイスを所有する企業に提供されていることがあり、Ｄ／Ｃ管理サーバ１０９に提供され得る。所与のプロファイルパッケージについて、プロファイルに対応するモバイルネットワークのＨＳＳ１０６は、プロファイルパッケージの加入者資格情報に対応する加入者資格情報、およびＮＢ－ＩｏＴ１０１の外部識別子を有するように設定される。

ステップ６０１において、Ｄ／Ｃ管理サーバ１０９は、プロファイルのダウンロードをトリガするためのコマンドをプロファイル管理サーバ１０７に送信する。ステップ５０１において、Ｄ／Ｃ管理サーバ１０９は、少なくとも、プロファイルがダウンロードされるＮＢ－ＩｏＴデバイス１０１のデバイス識別子、ダウンロードされるプロファイルに対応するプロファイル識別子、およびプロキシサーバ１０８のＵＲＬを提供し得る。デバイス識別子は、プロファイル管理サーバ１０７によって、プロファイルダウンロードがトリガされるべきデバイスを識別するために使用され、プロファイル識別子は、ダウンロードされるプロファイルを識別する。この例では、デバイス識別子はｅＵＩＣＣ ＩＤ（ＥＩＤ）を含む。この例では、プロファイル識別子はＩＣＣＩＤを含む。

ステップ６０２において、プロファイル管理サーバ１０７は、ＧＳＭＡ ＲＳＰ Ｍ２Ｍ版「ＨＴＴＰＳセッショントリガのためのＳＭＳ」によるフォーマットされたデータを含むメッセージ（例えば、ＧＳＭＡ ＲＳＰ Ｍ２Ｍ版によるフォーマットされたトリガメッセージ）をＤ／Ｃ管理サーバ１０９に送信する。具体的には、メッセージは、ＥＩＤ、およびトリガメッセージのための情報を含み得る。

したがって、この例では、ステップ６０３において、Ｄ／Ｃ管理サーバ２０９は、トリガメッセージをＮＢ－ＩｏＴデバイス１０１に配信するよう求める要求をプロキシサーバ１０８に送信し、要求は、デバイス識別子を含む（ステップ６０３は、図２のステップ２０１に対応し得る）。この例では、Ｄ／Ｃ管理サーバは、ＥＩＤに対応するデバイス識別子を検索し得る

ステップ６０４において、プロキシサーバ１０８は、ステップ６０３で受信したデバイス識別子によって識別されるＮＢ－ＩｏＴデバイスにトリガメッセージを配信する。具体的には、プロキシサーバ１０８は、ステップ６０３で受信したデバイス識別子に基づいて外部識別子を決定し得る。デバイス識別子が外部識別子と異なる場合、プロキシサーバ１０８は、提供されたデバイス識別子を使用してデータベース内の外部識別子を検索する。次いで、ステップ６０４は、図４に示すように実施され得る。

ステップ６０５において、ＮＢ－ＩｏＴデバイス１０１内のデバイスアプリケーションは、「ＨＴＴＰＳセッショントリガのためのＳＭＳ」をＮＢ－ＩｏＴ１０１内の識別情報モジュールに送信し得る。

ステップ６０６において、ＮＢ－ＩｏＴデバイス１０１およびプロファイル管理サーバ１０７は、例えば、相互認証を含むセキュア通信を確立するためにメッセージを交換する。この例では、ステップ６０６は、ＧＳＭＡ ＲＳＰ Ｍ２Ｍ版によるＨＴＴＰＳセッションの確立を含む。ここでのソリューションは、プロファイル管理サーバ（ＳＭ－ＳＲ部分）１０７とＮＢ－ＩｏＴ１０１の識別情報モジュールの２つのエンドポイントが修正を必要とせず、それらの間で転送されるＨＴＴＰＳメッセージを交換できることを保証する。メッセージの転送方法についての詳細を以下に説明する。

ステップ６０７において、ＮＢ－ＩｏＴデバイス１０１は、プロファイル管理サーバ１０７からプロファイルパッケージをダウンロードする。プロファイル管理サーバ１０７は、ステップ６０１で受信したデバイス識別子およびプロファイル識別子に基づいて、どのプロファイルパッケージをＮＢ－ＩｏＴデバイス１０１にダウンロードするかを認識する。次いで、ＮＢ－ＩｏＴによって、プロファイルパッケージが識別情報モジュールにインストールされ得る。例えば、ステップ６０７は、プロファイル管理サーバからプロファイルを受信することと、プロファイルを識別情報モジュールにインストールすることとを含み得る。この例では、プロファイル管理サーバ（ＳＭ－ＳＲ部分）１０７と識別情報モジュールとの間のセキュアなトンネル内ですべて交換される一連のメッセージからなる標準ＧＳＭＡ ＲＳＰ Ｍ２Ｍプロトコルによる、プロファイルパッケージがＮＢ－ＩｏＴデバイスにダウンロードされ、識別情報モジュールにインストールされる。

ステップ６０８において、プロファイル管理サーバ１０７は、任意選択として、トリガメッセージの結果について報告する応答をＤ／Ｃ管理サーバ１０９に提供し得る。例えば、プロファイル管理サーバ１０７は、プロファイルがＮＢ－ＩｏＴ１０１に正常にダウンロードされたか否かをＤ／Ｃ管理サーバ１０９に示し得る。

この例では、プロファイルは、新しいモバイルネットワークのプロファイルである。したがって、この例では、Ｄ／Ｃ管理サーバ１０９は、ステップ６０９において、ＮＢ－ＩｏＴデバイス１０１について新しいモバイルネットワークに切り替えるよう求める要求をプロキシサーバ１０８に送信し得る。例えば、新しいモバイルネットワークに切り替えるよう求める要求は、プロキシサーバが、新しいモバイルネットワークに属するＰ－ＧＷなどを公開機能に登録することを求める要求を含み得る。要求には、プロキシサーバが登録するよう要求されているＭＮＯサービスのＵＲＬが含まれ得る。Ｐ－ＧＷの場合、プロキシサーバはプロファイルの申込み／準備フェーズからＮＩＤＤで使用するように事前設定されている可能性があり、その場合このステップは省略され得ることに留意されたい。

ステップ６０９に応答して、プロキシサーバは、ステップ６１０において、新しいモバイルネットワークに登録し得る。例えば、プロキシサーバ１０８は、ＮＢ－ＩｏＴデバイス１０１から送信された任意のデータが新しいモバイルネットワークを介してアプリケーションサーバにルーティングされ得るように、新しいモバイルネットワークに登録し得る。登録が行われると、プロキシサーバ１０８は、古いモバイルネットワークを介してＮＢ－ＩｏＴデバイスにデータを送信するように設定されたまま、新しいプロファイルが有効化されて切り替えが完了した状態が確立されるまで、すなわち、プロキシサーバが、新しいモバイルネットワークを介してＮＢ－ＩｏＴデバイスにデータを送信するように設定されるまで、両方のモバイルネットワークを介してＮＢ－ＩｏＴデバイスからデータを受信することが可能になり得る。

この例では、プロファイルは、ＮＢ－ＩｏＴへのプロファイルのダウンロードとは別に有効化され得る。したがって、この例では、ステップ６０７において、プロファイルがダウンロードされ得、ステップ６１１において、Ｄ／Ｃ管理サーバ１０９が、プロファイルの有効化をトリガするよう求める要求をプロファイル管理サーバ１０７に送信し得る。この例では、ステップ６１１で送信される要求は、ＥＩＤおよびＩＣＣＩＤを含む。このステップは任意選択であり、プロファイルの有効化は、Ｄ／Ｃ管理サーバがプロファイルダウンロードのためにプロファイル管理サーバをトリガするステップ６０１の一部であり得る。

ステップ６１２において、プロファイル管理サーバ１０７は、ＥＩＤおよびＧＳＭＡ ＲＳＰ Ｍ２Ｍ版「プロファイル有効化のためのＳＭＳ」によるフォーマットされたデータを含むメッセージをＤ／Ｃ管理サーバに送信する。さらに、メッセージには、プロファイル管理サーバのＵＲＬが含まれ得る。ステップ６１１が実行されない場合、「プロファイル有効化のためのＳＭＳ」を提供するためのトリガは、プロファイルが正常にダウンロードされたことであることに留意されたい。その場合、メッセージは、プロファイル管理サーバ１０７によって、ステップ６０８の一部としてＤ／Ｃ管理サーバ１０９に提供され得る。

ステップ６１２でメッセージを受信したことに応答して、Ｄ／Ｃ管理サーバ１０９は、ステップ６１３において、ダウンロードされたプロファイルの有効化をトリガするための情報を含むメッセージをプロキシサーバ１０８に送信し得る。具体的には、Ｄ／Ｃ管理サーバは、ステップ６１２で提供されたＥＩＤに対応するデバイス識別子を検索し、ＮＢ－ＩｏＴデバイス１０１へのメッセージの配信のために、メッセージ（「プロファイル有効化のためのＳＭＳ」）およびデバイス識別子をプロキシサーバ１０８に送信し得る。このメッセージは、プロファイル管理サーバ１０７のＵＲＬを含み得る。

ステップ６１４において、プロキシサーバ１０８は、ステップ６１３で受信したデバイス識別子によって識別されるＮＢ－ＩｏＴデバイス１０１に、ダウンロードされたプロファイルの有効化をトリガするためのメッセージを配信する。上記のように、このステップでは、トリガメッセージは、図４で説明されているようにＮＢ－ＩｏＴデバイスに配信され得る。

ステップ６１５において、ＮＢ－ＩｏＴデバイス１０１内のデバイスアプリケーションは、メッセージ（「プロファイル有効化のためのＳＭＳ」）を識別情報モジュールに配信する。

ステップ６１６において、識別情報モジュールは、プロファイルを有効化し、「ＳＭＳ」としてフォーマットされたプロファイル有効化動作の結果を有するメッセージを準備する。

ステップ６１７において、ステップ６１６で準備されたメッセージは、ＮＢ－ＩｏＴデバイス１０１内のデバイスアプリケーションに配信される。

ステップ６１８において、ステップ６１６およびステップ６１７のメッセージは、ＮＢ－ＩｏＴデバイス１０１内のデバイスアプリケーションからプロファイル管理サーバ１０７に配信される。プロファイル管理サーバ１０７のＵＲＬは、デバイスアプリケーション／識別情報モジュールに認識されているか、ステップ６１４で受信したメッセージ「プロファイル有効化のためのＳＭＳ」の一部であるか、またはステップ６１４において「プロファイル有効化のためのＳＭＳ」とともに配信され得るかである。

ステップ６１９において、プロファイルの有効化が成功すると、新しいネットワークへの連結が実行される（この例のように、新しいプロファイルは新しいモバイルネットワークを伴う）。

ステップ６２０において、識別情報モジュールは、デバイスアプリケーションに配信される「ＳＭＳ」としてフォーマットされた通知メッセージを準備する。

ステップ６２１において、メッセージ（「ＳＭＳ通知」）が、デバイスアプリケーションからプロファイル管理サーバ１０７に配信される。プロファイル管理サーバのＵＲＬは、以前からＮＢ－ＩｏＴデバイス１０１に知られている可能性がある。

ステップ６２１でのメッセージの配信において、プロキシサーバ１０８は、ステップ６１０で登録された新しいモバイルネットワークを介して、ＮＢ－ＩｏＴデバイス１０１からトラフィックを受信する。次いで、プロキシサーバ１０８は、ＮＢ－ＩｏＴデバイス１０１のモバイルネットワークを切り替えることを決定することができ、ステップ６２２において、新しいモバイルネットワークを介してＮＢ－ＩｏＴデバイス１０１にデータを送信し得る。

ステップ６２３において、プロファイル管理サーバ１０７は、任意選択として、動作の結果について報告する応答をＤ／Ｃ管理サーバ１０９に提供する。例えば、プロファイル管理サーバ１０７は、プロファイルが有効化されたか否かを報告し得る。

プロファイルの有効化が成功し、プロファイルが新しいモバイルネットワークオペレータにあることに応答して、Ｄ／Ｃ管理サーバ１０９は、ステップ６２４において、新しいモバイルネットワークオペレータからのサービスを使用するように切り替えるようにプロキシサーバ１０８に命令し得る。例えば、プロキシサーバ１０８は、プロファイルが変更された特定のＮＢ－ＩｏＴデバイスの新しいモバイルネットワークで公開機能（例えば、ＳＣＥＦ）および／またはＰ－ＧＷを使用するように切り替えるように命令され得る。新しいモバイルネットワークへの登録は、以前に（例えば、ステップ６１０において）行われている可能性がある。ＮＢ－ＩｏＴデバイスのデバイス識別子は、使用される様々なＭＮＯサービス（ＳＣＥＦ、Ｐ－ＧＷなど）へのＵＲＬとともに提供され得る。

ステップ６２５において、プロキシサーバ１０８は、プロキシサーバ１０８の設定を、アプリケーションサーバからＮＢ－ＩｏＴデバイス１０１へのデータが今度は新しいモバイルネットワークを介して転送されるように変更し得る。プロキシサーバ１０８はまた、古いモバイルネットワークサービスから登録解除し得る。

図６は、ＳＭＳサービスが提供されておらず、ＮＩＤＤが使用され得るＮＢ－ＩｏＴデバイス１０１の場合に、プロファイル管理サーバのＳＭ－ＳＲ部分とｅＵＩＣＣとの間の通信がどのように実行されるかを示す例示的なフローである。図６は、ＨＴＴＰＳセッションを使用した「ＳＭＳ」配信およびデータ配信がどのようにハンドリングされるかを示す。ＣＡＴ＿ＴＰセッションは、ＨＴＴＰＳと同じ方法でハンドリングされる。同じ技法を用いて、すべてのＧＳＭＡ ＲＳＰ Ｍ２Ｍ版フローを適宜に適合させることができる。

いくつかの実施形態において、プロファイルダウンロードおよびプロファイル管理は、ＧＳＭＡ ＲＳＰ消費者版により実行される。この場合、プロファイル管理サーバ１０７は、ＳＭ－ＤＰ＋として知られている。ＳＭ－ＤＰ＋１０７は、企業が新しい加入プロファイルを申し込んだＭＮＯによって運用され得るか、またはＳＭ－ＤＰ＋１０７は、サードパーティによって運用され得、ＭＮＯに提供されるサービスの一部であり得る。ＳＭ－ＤＰ＋１０７が、ＭＮＯが使用するサードパーティによって提供されるサービスである例では、Ｄ／Ｃ管理サーバ１０９をＳＭ－ＤＰ＋とリンクするプロファイル管理動作用の顧客向けのインターフェースを提供するＭＮＯポータルも、プロファイル管理サーバの一部として含まれる。この例を図７に示す。

Ｄ／Ｃ管理サーバ１０９は、ＮＢ－ＩｏＴデバイス１０１内のローカルプロファイルアシスタント（ＬＰＡｄ）７００を介して、プロファイルダウンロードおよびプロファイル管理動作をリモートで制御し得る。ＬＰＡｄ７０は、識別情報モジュールとの対話およびプロファイル管理サーバ１０７との対話をハンドリングする。ＬＰＡｄ７００と、Ｄ／Ｃ管理サーバ１０９とプロファイル管理サーバ１０７との両方との間でセキュア通信が確立され得る。ＳＭ－ＤＰ＋１０７とＭＮＯポータルとの間の個々の通信は、ＧＳＭＡ ＲＳＰ標準に従うことができ、したがって本明細書では、通信のこの部分の詳細は提供されていない。ＬＰＡｄ７００とＳＭ－ＤＰ＋１０７との間のセキュア通信トンネル内で実行され得る識別情報モジュールとＳＭ－ＤＰ＋１０７との間の通信についても同様である。

ＳＭ－ＤＰ＋１０７とＬＰＡｄ７００との間のセキュア通信は、ＨＴＴＰＳに基づき得、ＬＰＡｄ７００とＤ／Ｃ管理サーバ１０９との間のセキュア通信は、トランスポート層セキュリティ（ＴＬＳ）／データグラムＴＬＳ（ＤＴＬＳ）、または制約付きＲＥＳＴｆｕｌ環境のためのオブジェクトセキュリティ（ＯＳＣＯＲＥ：Ｏｂｊｅｃｔ Ｓｅｃｕｒｉｔｙ ｆｏｒ Ｃｏｎｓｔｒａｉｎｅｄ ＲＥＳＴｆｕｌ Ｅｎｖｉｒｏｎｍｅｎｔｓ）に基づき得る。

図７は、図５に示したフローの一例を示す。具体的には、図７は、ＧＳＭＡ ＲＳＰ消費者版が使用されている例の図５のフローを示す。通信フローは、プロファイルダウンロードトークン情報を取得した後にトリガメッセージがＤ／Ｃ管理サーバ１０９を介してルーティングされるように変更され得る。

ＮＢ－ＩｏＴデバイス１０１（例えば、ｅＵＩＣＣ）の識別情報モジュールは、ＮＢ－ＩｏＴデバイス１０１がセルラネットワークに接続することを可能にするアクティブなセルラ加入（すなわち、有効化されたプロファイル）を有するように設定され得る。これは、動作プロファイルの提供を可能にする目的で製造時にインストールされたプロファイルであり得るか、または以前にＮＢ－ＩｏＴデバイス１０１によってダウンロードされた動作プロファイルであり得る。

ＨＳＳ１０６は、ＮＢ－ＩｏＴデバイス１０１の加入者資格情報を有するように設定され得る。加入者資格情報は、公開機能１０４（例えば、ＳＣＥＦ）を介してデバイスをアドレス指定するために使用される外部識別子を含み得る。プロキシサーバ１０８は、ＮＢ－ＩｏＴデバイス１０１をアドレス指定することが可能な外部識別子を有するように設定され得る。プロファイル管理サーバ１０７は、ダウンロード可能であり得るプロファイルパッケージのセットを含み得る。企業が、１つまたは複数のＮＢ－ＩｏＴデバイスを所有して、プロファイル管理サーバ１０７のＭＮＯポータルを介して企業のデバイスのプロファイルを申し込んだ後に、プロファイル管理サーバによるこれらのプロファイルの準備が続き、企業は、企業のデバイスにデバイス識別を提供している場合がある。次いで、対応するプロファイルダウンロード情報（すなわち、プロファイルパッケージに対するプロファイル識別子）は、ＮＢ－ＩｏＴデバイスを所有する企業に提供され得、Ｄ／Ｃ管理サーバ１０９に提供され得る。所与のプロファイルパッケージについて、プロファイルに対応するモバイルネットワークのＨＳＳ１０６は、プロファイルパッケージの加入者資格情報に対応する加入者資格情報、およびＮＢ－ＩｏＴ１０１の外部識別子を有するように設定される。

ステップ７０１およびステップ７０２は、上記のようにプロファイルダウンロード情報を取得するＤ／Ｃ管理サーバ１０９に関する。ステップ７０１において、Ｄ／Ｃ管理サーバ１０９は、プロファイルダウンロード情報を取得するためのコマンドをプロファイル管理サーバ１０７（ＭＮＯポータル部分）に送信する。ステップ７０１において、Ｄ／Ｃ管理サーバ１０９は、少なくとも、プロファイルがダウンロードされるＮＢ－ＩｏＴデバイス１０１のデバイス識別子を提供し得る。デバイス識別子は、プロファイル管理サーバ１０７によって、プロファイルのダウンロードがトリガされるべきデバイスを識別するために使用される。この例では、デバイス識別子は、ｅＵＩＣＣ ＩＤ（ＥＩＤ）または国際移動体機器識別情報（ＩＭＥＩ：Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｍｏｂｉｌｅ Ｅｑｕｉｐｍｅｎｔ Ｉｄｅｎｔｉｔｙ）を含む。

ステップ７０２において、プロファイル管理サーバ１０７は、ＳＭ－ＤＰ＋１０７のアドレスおよびプロファイルダウンロード識別子を含むメッセージをＤ／Ｃ管理サーバ１０９に送信する。アドレスおよびプロファイルダウンロード識別子は、アクティベーションコードの形式で提供され得る。アクティベーションコードは、企業によって他の方法で取得され、次いでＤ／Ｃ管理サーバ１０９に設定され得ることに留意されたい。その場合、ステップ７０１およびステップ７０２は実行されない可能性がある。

ステップ７０３において、Ｄ／Ｃ管理サーバ１０９は、トリガメッセージをＮＢ－ＩｏＴデバイス１０１に配信するよう求める要求をプロキシサーバ１０８に送信し、要求は、デバイス識別子を含む（ステップ７０３は、図２のステップ２０１に対応し得る）。

ステップ７０４において、プロキシサーバ１０８は、ステップ７０３で受信したデバイス識別子によって識別されるＮＢ－ＩｏＴデバイスにトリガメッセージを配信する。具体的には、プロキシサーバ１０８は、ステップ７０３で受信したデバイス識別子に基づいて外部識別子を決定し得る。デバイス識別子が外部識別子と異なる場合、プロキシサーバ１０８は、提供されたデバイス識別子を使用してデータベース内の外部識別子を検索する。次いで、ステップ７０４は、図４に示すように実施され得る。

ステップ７０５において、ＮＢ－ＩｏＴデバイス１０１内のデバイスアプリケーション（例えば、ＬＰＡｄ７００）は、デバイスとＤ／Ｃ管理サーバとの間のセキュア通信の確立をトリガする。ＮＢ－ＩｏＴデバイスのタイプに応じて、様々なプロトコルが使用され得る。例えばＩＰベースの通信を使用するＮＢ－ＩｏＴデバイスの場合、ステップ７０５は、ＴＬＳ／ＤＴＬＳを使用することができ、ＣｏＡＰを使用するＮＢ－ＩｏＴデバイスの場合、ステップ７０５は、ＯＳＣＯＲＥを利用することができる。ＯＳＣＯＲＥが使用される場合、例えばＥＤＨＯＣを使用して共通のセキュリティコンテキストがすでに確立されている可能性があり、ＯＳＣＯＲＥが直接使用され得ることに留意されたい。代替として、ＯＳＣＯＲＥセキュリティコンテキストの確立に、ＣＯＳＥによる一時的なＤｉｆｆｉｅ－Ｈｅｌｌｍａｎ法（ＥＤＨＯＣ：Ｅｐｈｅｍｅｒａｌ Ｄｉｆｆｉｅ－Ｈｅｌｌｍａｎ Ｏｖｅｒ ＣＯＳＥ）が使用されてもよい。ステップ７０５は、ステップ７０４が実行される場合にのみ実行され得る。

ステップ７０６において、Ｄ／Ｃ管理サーバ１０９は、アクティベーションコードをＬＰＡｄ７００にセキュアに配信する。

ステップ７０７において、ＮＢ－ＩｏＴデバイス１０１（例えば、ＬＰＡｄ７００）は、プロファイル管理サーバ１０７とのセキュア通信（例えば、相互認証を含む）を確立する。例えば、ＬＰＡｄ７００は、アクティベーションコード内のアドレスを利用して、プロファイル管理サーバ１０７との通信を確立し得る。具体的には、ステップ７０７は、ＧＳＭＡ ＲＳＰ消費者版によるＨＴＴＰＳセッションの確立を含み得る。本明細書の実施形態は、２つのエンドポイント、例えばプロファイル管理サーバ（ＳＭ－ＤＰ＋部分）１０７およびＬＰＡｄ７００が修正を必要とせず、それらの間で転送されるＨＴＴＰＳメッセージを交換できることを保証し得る。メッセージの転送方法についての詳細を以下に説明する。

ステップ７０８において、ＮＢ－ＩｏＴデバイス１０１は、プロファイル管理サーバ１０７からプロファイルパッケージをダウンロードする。次いで、ＮＢ－ＩｏＴによって、プロファイルパッケージが識別情報モジュールにインストールされ得る。例えば、ステップ７０８は、プロファイル管理サーバからプロファイルを受信することと、プロファイルを識別情報モジュールにインストールすることとを含み得る。この例では、プロファイル管理サーバ（ＳＭ－ＤＰ＋）とＬＰＡｄとの間のセキュアなトンネル内ですべて交換される一連のメッセージからなる標準ＧＳＭＡ ＲＳＰプロトコル消費者版に従って、プロファイルパッケージがデバイスにダウンロードされ、識別情報モジュールにインストールされ、ＬＰＡｄは、識別情報モジュールとの対話をハンドリングする。この一連のメッセージは、（一致識別子と呼ばれる）プロファイル識別子および／またはＥＩＤをプロファイル管理サーバに提供するＬＰＡｄを含み、これにより、プロファイル管理サーバは、この特定のデバイスについて、準備済みプロファイルパッケージのセット内のどのプロファイルパッケージをダウンロードすべきかを認識する。

ステップ７０９において、ＬＰＡｄ７００は、任意選択として、トリガメッセージの結果について報告する応答をＤ／Ｃ管理サーバ１０９に提供し得る。例えば、ＬＰＡｄ７００は、プロファイルがＮＢ－ＩｏＴデバイス１０１に正常にダウンロードされたか否かをＤ／Ｃ管理サーバ１０９に示し得る。この応答は、プロファイルに関連するプロファイル管理動作で使用するプロファイル識別子ＩＣＣＩＤを含み得る。

この例では、プロファイルは、新しいモバイルネットワークのプロファイルである。したがって、この例では、Ｄ／Ｃ管理サーバ１０９は、ステップ７１０において、ＮＢ－ＩｏＴデバイス１０１について新しいモバイルネットワークに切り替えるよう求める要求をプロキシサーバ１０８に送信し得る。例えば、新しいモバイルネットワークに切り替えるよう求める要求は、プロキシサーバが、新しいモバイルネットワークに属するＰ－ＧＷなどを公開機能に登録することを求める要求を含み得る。要求には、プロキシサーバが登録するよう要求されているＭＮＯサービスのＵＲＬが含まれ得る。要求には、デバイス識別子も含まれ得る。Ｐ－ＧＷの場合、プロキシサーバはプロファイルの申込み／準備フェーズからＮＩＤＤで使用するように事前設定されている可能性があり、その場合このステップは省略され得ることに留意されたい。

ステップ７１０に応答して、プロキシサーバは、ステップ７１１において、新しいモバイルネットワークに登録し得る。例えば、プロキシサーバ１０８は、ＮＢ－ＩｏＴデバイス１０１から送信された任意のデータが新しいモバイルネットワークを介してアプリケーションサーバにルーティングされ得るように、新しいモバイルネットワークに登録し得る。登録が行われると、プロキシサーバ１０８は、古いモバイルネットワークを介してＮＢ－ＩｏＴデバイスにデータを送信するように設定されたまま、新しいプロファイルが有効化されて切り替えが完了した状態が確立されるまで、すなわち、プロキシサーバは、新しいモバイルネットワークを介してＮＢ－ＩｏＴデバイスにデータを送信するように設定されるまで、両方のモバイルネットワークを介してＮＢ－ＩｏＴデバイスからデータを受信することが可能になり得る。

この例では、プロファイルは、ＮＢ－ＩｏＴへのプロファイルのダウンロードとは別に有効化され得る。したがって、この例では、ステップ７０８において、プロファイルがダウンロードされ得、ステップ７１２において、Ｄ／Ｃ管理サーバ１０９が、プロファイルの有効化をトリガするよう求める要求をプロキシサーバ１０８に送信し得る。要求は、デバイス識別子を含み得る。ステップ７１２は、Ｄ／Ｃ管理サーバ１０７とＮＢ－ＩｏＴデバイス１０１との間に確立されたセキュア通信がまだない場合、およびステップ７０３のトリガメッセージが実行されるべきプロファイルダウンロードとダウンロードされたプロファイルの有効化との両方をまだ示していない場合にのみ実行され得る。

ステップ７１３において、プロキシサーバ１０８は、ステップ７１２で受信したデバイス識別子によって識別されるＮＢ－ＩｏＴデバイス１０１に、ダウンロードされたプロファイルの有効化をトリガするためのメッセージを配信する。上記のように、このステップでは、トリガメッセージは、図４で説明されているようにＮＢ－ＩｏＴデバイスに配信され得る。ステップ７１３は任意であり、ステップ７１２が実行されない場合、実行されない可能性がある。

ステップ７１４において、デバイスアプリケーション（例えば、ＬＰＡｄ７００）は、ＮＢ ＩｏＴデバイス１０１とＤ／Ｃ管理サーバ１０７との間のセキュア通信の確立をトリガする。デバイスのタイプに応じて、様々なプロトコルが使用され得る。例えばＩＰベースの通信を使用するＮＢ－ＩｏＴデバイスの場合、ステップ７１４は、ＴＬＳ／ＤＴＬＳを使用することができ、ＣｏＡＰを使用するＮＢ－ＩｏＴデバイスの場合、ステップ７１４は、ＯＳＣＯＲＥを利用することができる。ＯＳＣＯＲＥが使用される場合、例えばＥＤＨＯＣを使用して共通のセキュリティコンテキストがすでに確立されている可能性があり、ＯＳＣＯＲＥが直接使用され得ることに留意されたい。代替として、ＯＳＣＯＲＥセキュリティコンテキストの確立にＥＤＨＯＣが使用されてもよい。ステップ７１４は、ステップ７１３が実行される場合にのみ実行され得る。

ステップ７１５において、Ｄ／Ｃ管理サーバ１０９は、新しいプロファイルの有効化をトリガするためのメッセージをＬＰＡｄ７００に送信する。このメッセージは、ステップ７０３のトリガメッセージが、ダウンロードされたプロファイルの実行されるべき有効化も示した場合、省略され得る。プロファイル識別子ＩＣＣＩＤもメッセージの一部として提供され得る。

ステップ７１６において、ＬＰＡｄ７００は、識別情報モジュールで提供されたプロファイル識別子を用いてプロファイルの有効化をトリガする。

ステップ７１７において、識別情報モジュールは新しいプロファイルを有効化する。

ステップ７１８において、プロファイルの有効化が成功すると、新しいネットワークへの連結が実行される（この例のように、新しいプロファイルは新しいモバイルネットワークを伴う）。

ステップ７１９において、ＬＰＡｄ７００は、プロファイルの有効化が成功したかどうかを示す応答をＤ／Ｃ管理サーバに提供する。

ステップ７１９での応答の配信において、プロキシサーバ１０８は、新しいモバイルネットワークを介してＮＢ－ＩｏＴデバイス１０１からトラフィックを受信する。次いで、プロキシサーバ１０８は、ステップ７２０において、ＮＢ－ＩｏＴデバイス１０１のモバイルネットワークを切り替えることを決定することができ、これから先は、新しいモバイルネットワークを介してＮＢ－ＩｏＴデバイス１０１にデータを送信することができる。

プロファイルの有効化が成功し、プロファイルが新しいモバイルネットワークオペレータにあることに応答して、Ｄ／Ｃ管理サーバ１０９は、ステップ７２１において、新しいモバイルネットワークオペレータからのサービスを使用するように切り替えるようにプロキシサーバ１０８に命令し得る。例えば、プロキシサーバ１０８は、プロファイルが変更された特定のＮＢ－ＩｏＴデバイスの新しいモバイルネットワークで公開機能（例えば、ＳＣＥＦ）および／またはＰ－ＧＷを使用するように切り替えるように命令され得る。新しいモバイルネットワークへの登録は、以前に（例えば、ステップ７１１において）行われている可能性がある。ＮＢ－ＩｏＴデバイスのデバイス識別子は、使用される様々なＭＮＯサービス（ＳＣＥＦ、Ｐ－ＧＷなど）へのＵＲＬとともに提供され得る。

ステップ７２２において、プロキシサーバ１０８は、プロキシサーバ１０８の設定を、アプリケーションサーバからＮＢ－ＩｏＴデバイス１０１へのデータが今度は新しいモバイルネットワークを介して転送されるように変更し得る。プロキシサーバ１０８はまた、古いモバイルネットワークサービスから登録解除し得る。

申込み時にＥＩＤまたは他のデバイス識別子を提供せずに１つまたは複数のデバイスのプロファイルを申し込むことが可能であり、プロファイルダウンロード時に、プロファイルと特定のＮＢ－ＩｏＴデバイスとの結び付けが発生することに留意されたい。Ｄ／Ｃ管理サーバは、例えば、ステップ７０３の前に、１組のＮＢ－ＩｏＴデバイスのためのアクティベーションコードのセットを有するように設定され得、ステップ７０６で使用するために、このセットの中から１つのアクティベーションコードを選択し得る。次いで、どのプロファイルをどのＮＢ－ＩｏＴデバイスに送信するかをＤ／Ｃ管理サーバが決定する。次に、プロファイル識別子およびデバイス識別子とＥＩＤとの間の結び付けは、ＳＭ－ＤＰ＋がデバイスからＥＩＤおよびＩＭＥＩを受信するステップ７０８においてプロファイルダウンロード時に行うことができ、この結び付けは、ＭＮＯに報告され得る。

図７は、ＮＩＤＤを使用できるＮＢ－ＩｏＴデバイスの場合に、ＳＭ－ＤＰ＋とＮＢ－ＩｏＴデバイス（例えば、識別情報モジュール）との間の通信がどのように実行されるかを示すフローの一例を示す。同じ技法を用いて、すべてのＧＳＭＡ ＲＳＰ消費者版フローを適宜に適合させることができる。

いくつかの実施形態において、プロファイルダウンロードおよびプロファイル管理は、ＩｏＴに適合したＧＳＭＡ ＲＳＰ消費者版による。ここで、ＬＰＡｄ７００は２つの部分に分割され、主要部分であるＬＰＡｐｒは、デバイスからＤ／Ｃ管理サーバ１０９に移動され、小部分であるＬＰＡｄｖ８００は、識別情報モジュールとの通信のためにＮＢ－ＩｏＴデバイス１０１内に残る。この場合、ＨＴＴＰＳベースの通信は、Ｄ／Ｃ管理サーバ内のＬＰＡｐｒによってハンドリングされ、これにより、ＮＢ－ＩｏＴデバイス１０１の複雑さが軽減され、プロキシサーバ１０８も簡素化され得る。Ｄ／Ｃ管理サーバとＬＰＡｄｖとの間のメッセージは、ｅＵＩＣＣとの通信に関連するメッセージに対応し得る。

図８は、図５のプロファイルダウンロードおよびプロファイル有効化のフローの一例を示す図であり、フローは、ＧＳＭＡ ＲＳＰの適合された消費者版用に再描画されている。

ＮＢ－ＩｏＴデバイス１０１（例えば、ｅＵＩＣＣ）の識別情報モジュールは、ＮＢ－ＩｏＴデバイス１０１がセルラネットワークに接続することを可能にするアクティブなセルラ加入（すなわち、有効化されたプロファイル）を有するように設定され得る。これは、動作プロファイルの提供を可能にする目的で製造時にインストールされたプロファイルであり得るか、または以前にＮＢ－ＩｏＴデバイス１０１によってダウンロードされた動作プロファイルであり得る。

ＨＳＳ１０６は、ＮＢ－ＩｏＴデバイス１０１の加入者資格情報を有するように設定され得る。加入者資格情報は、公開機能１０４（例えば、ＳＣＥＦ）を介してデバイスをアドレス指定するために使用される外部識別子を含み得る。プロキシサーバ１０８は、ＮＢ－ＩｏＴデバイス１０１をアドレス指定することが可能な外部識別子を有するように設定され得る。プロファイル管理サーバ１０７は、ダウンロード可能であり得るプロファイルパッケージのセットを含み得る。企業が、１つまたは複数のＮＢ－ＩｏＴデバイスを所有して、プロファイル管理サーバ１０７のＭＮＯポータルを介して企業のデバイスのプロファイルを申し込んだ後に、プロファイル管理サーバによるこれらのプロファイルの準備が続き、企業は、企業のデバイスにデバイス識別を提供している場合がある。次いで、対応するプロファイルダウンロード情報（すなわち、プロファイルパッケージに対するプロファイル識別子）は、ＮＢ－ＩｏＴデバイスを所有する企業に提供され得、Ｄ／Ｃ管理サーバ１０９に提供され得る。所与のプロファイルパッケージについて、プロファイルに対応するモバイルネットワークのＨＳＳ１０６は、プロファイルパッケージの加入者資格情報に対応する加入者資格情報、およびＮＢ－ＩｏＴ１０１の外部識別子を有するように設定される。

ステップ８０１およびステップ８０２は、上記のようにプロファイルダウンロード情報を取得するＤ／Ｃ管理サーバ１０９に関する。ステップ８０１において、Ｄ／Ｃ管理サーバ１０９は、プロファイルダウンロード情報（例えば、アクティベーションコード）を取得するためのコマンドをプロファイル管理サーバ１０７（ＭＮＯポータル部分）に送信する。ステップ８０１において、Ｄ／Ｃ管理サーバ１０９は、少なくとも、プロファイルがダウンロードされるＮＢ－ＩｏＴデバイス１０１のデバイス識別子を提供し得る。デバイス識別子は、プロファイル管理サーバ１０７によって、プロファイルのダウンロードがトリガされるべきデバイスを識別するために使用される。この例では、デバイス識別子は、ｅＵＩＣＣ ＩＤ（ＥＩＤ）またはＩＭＥＩを含む。

ステップ８０２において、プロファイル管理サーバ１０７は、ＳＭ－ＤＰ＋１０７のアドレスおよびプロファイルダウンロード識別子を含むメッセージをＤ／Ｃ管理サーバ１０９に送信する。アドレスおよびプロファイルダウンロード識別子は、アクティベーションコードの形式で提供され得る。アクティベーションコードは、企業によって他の方法で取得され、次いでＤ／Ｃ管理サーバ１０９に設定され得ることに留意されたい。その場合、ステップ８０１およびステップ８０２は実行されない可能性がある。

ステップ８０３において、Ｄ／Ｃ管理サーバ１０９は、トリガメッセージをＮＢ－ＩｏＴデバイス１０１に配信するよう求める要求をプロキシサーバ１０８に送信し、要求は、デバイス識別子を含む（ステップ８０３は、図２のステップ２０１に対応し得る）。デバイスがすでにＤ／Ｃ管理サーバに登録されており、デバイスとＤ／Ｃ管理サーバとの間でセキュア通信がすでに確立されている場合、このステップは省略され得る。

ステップ８０４において、プロキシサーバ１０８は、ステップ８０３で受信したデバイス識別子によって識別されるＮＢ－ＩｏＴデバイスにトリガメッセージを配信する。具体的には、プロキシサーバ１０８は、ステップ８０３で受信したデバイス識別子に基づいて外部識別子を決定し得る。デバイス識別子が外部識別子と異なる場合、プロキシサーバ１０８は、提供されたデバイス識別子を使用してデータベース内の外部識別子を検索する。次いで、ステップ８０４は、図４に示すように実施され得る。

ステップ８０５において、ＮＢ－ＩｏＴデバイス１０１内のデバイスアプリケーション（例えば、ＬＰＡｄｖ８００）は、デバイスとＤ／Ｃ管理サーバとの間のセキュア通信の確立をトリガする。ＮＢ－ＩｏＴデバイスのタイプに応じて、様々なプロトコルが使用され得る。例えばＩＰベースの通信を使用するＮＢ－ＩｏＴデバイスの場合、ステップ８０５は、ＴＬＳ／ＤＴＬＳを使用することができ、ＣｏＡＰを使用するＮＢ－ＩｏＴデバイスの場合、ステップ８０５は、ＯＳＣＯＲＥを利用することができる。ＯＳＣＯＲＥが使用される場合、例えばＥＤＨＯＣを使用して共通のセキュリティコンテキストがすでに確立されている可能性があり、ＯＳＣＯＲＥが直接使用され得ることに留意されたい。代替として、ＯＳＣＯＲＥセキュリティコンテキストの確立にＥＤＨＯＣが使用されてもよい。ステップ８０５は、ステップ８０４が実行される場合にのみ実行され得る。

ステップ８０６において、Ｄ／Ｃ管理サーバの一部であるＬＰＡｐｒは、プロファイル管理サーバ１０７とのセキュア通信（相互認証を含む）を確立することによって、プロファイルダウンロードフローを開始する。ＧＳＭＡ ＲＳＰ消費者版によれば、ステップ８０６は、ＨＴＴＰＳセッションの確立を含み得る。

ステップ８０７において、プロファイル管理サーバ（ＳＭ－ＤＰ＋）とＤ／Ｃ管理サーバのＬＰＡｐｒとの間、およびＤ／Ｃ管理サーバとデバイス（ＬＰＡｄｖ）との間のセキュアなトンネル内ですべて交換される一連のメッセージからなる、ＩｏＴ用に適合されたＧＳＭＡ ＲＳＰプロトコル消費者版に従って、プロファイルパッケージがデバイスにダウンロードされ、ｅＵＩＣＣにインストールされ、ＬＰＡｄｖ８００は、識別情報モジュール（例えば、ｅＵＩＣＣ）との対話をハンドリングする。この一連のメッセージは、（一致識別子と呼ばれる）プロファイル識別子および／または識別情報モジュールのＥＩＤをプロファイル管理サーバに提供するＬＰＡｐｒを含み、これにより、プロファイル管理サーバは、この特定のデバイスについて、準備済みプロファイルパッケージのセット内のどのプロファイルパッケージをダウンロードすべきかを認識する。プロファイルダウンロードを成功させる一環として、ＬＰＡｐｒは、プロファイルに関連するプロファイル管理動作で使用するプロファイル識別子ＩＣＣＩＤを取得する。

この例では、プロファイルは、新しいモバイルネットワークのプロファイルである。したがって、この例では、Ｄ／Ｃ管理サーバ１０９は、ステップ８０８において、ＮＢ－ＩｏＴデバイス１０１について新しいモバイルネットワークに切り替えるよう求める要求をプロキシサーバ１０８に送信し得る。例えば、新しいモバイルネットワークに切り替えるよう求める要求は、プロキシサーバが、新しいモバイルネットワークに属するＰ－ＧＷなどを公開機能に登録することを求める要求を含み得る。要求には、プロキシサーバが登録するよう要求されているＭＮＯサービスのＵＲＬが含まれ得る。要求には、デバイス識別子も含まれ得る。Ｐ－ＧＷの場合、プロキシサーバはプロファイルの申込み／準備フェーズからＮＩＤＤで使用するように事前設定されている可能性があり、その場合このステップは省略され得ることに留意されたい。

ステップ８０８に応答して、プロキシサーバは、ステップ８０９において、新しいモバイルネットワークに登録し得る。例えば、プロキシサーバ１０８は、ＮＢ－ＩｏＴデバイス１０１から送信された任意のデータが新しいモバイルネットワークを介してアプリケーションサーバにルーティングされ得るように、新しいモバイルネットワークに登録し得る。登録が行われると、プロキシサーバ１０８は、古いモバイルネットワークを介してＮＢ－ＩｏＴデバイスにデータを送信するように設定されたまま、新しいプロファイルが有効化されて切り替えが完了した状態が確立されるまで、すなわち、プロキシサーバは、新しいモバイルネットワークを介してＮＢ－ＩｏＴデバイスにデータを送信するように設定されるまで、両方のモバイルネットワークを介してＮＢ－ＩｏＴデバイスからデータを受信することが可能になり得る。

この例では、プロファイルは、ＮＢ－ＩｏＴへのプロファイルのダウンロードとは別に有効化され得る。したがって、この例では、ステップ８０７において、プロファイルがダウンロードされ得、ステップ８１０において、Ｄ／Ｃ管理サーバ１０９が、プロファイルの有効化をトリガするよう求める要求をプロキシサーバ１０８に送信し得る。要求は、デバイス識別子を含み得、ＬＰＡｄｖ通信を指示し得る。このステップは、Ｄ／Ｃ管理サーバ１０９とＮＢ－ＩｏＴデバイス１０１との間に確立されたセキュア通信がまだない場合にのみ実行され得る。

ステップ８１１において、プロキシサーバ１０８は、ステップ８１０で受信したデバイス識別子によって識別されるＮＢ－ＩｏＴデバイス１０１に、ダウンロードされたプロファイルの有効化をトリガするためのメッセージを配信する。上記のように、このステップでは、トリガメッセージは、図４で説明されているようにＮＢ－ＩｏＴデバイスに配信され得る。ステップ８１１は任意であり、ステップ８１０が実行されない場合、実行されない可能性がある。

ステップ８１２において、デバイスアプリケーション（例えば、ＬＰＡｄｖ８０１）は、ＮＢ ＩｏＴデバイス１０１とＤ／Ｃ管理サーバ１０７との間のセキュア通信の確立をトリガする。デバイスのタイプに応じて、様々なプロトコルが使用され得る。例えばＩＰベースの通信を使用するＮＢ－ＩｏＴデバイスの場合、ステップ８１２は、ＴＬＳ／ＤＴＬＳを使用することができ、ＣｏＡＰを使用するＮＢ－ＩｏＴデバイスの場合、ステップ８１２は、ＯＳＣＯＲＥを利用することができる。ＯＳＣＯＲＥが使用される場合、例えばＥＤＨＯＣを使用して共通のセキュリティコンテキストがすでに確立されている可能性があり、ＯＳＣＯＲＥが直接使用され得ることに留意されたい。代替として、ＯＳＣＯＲＥセキュリティコンテキストの確立にＥＤＨＯＣが使用されてもよい。ステップ８１２は、ステップ８１１が実行される場合にのみ実行され得る。

ステップ８１３において、Ｄ／Ｃ管理サーバ１０９（例えば、ＬＰＡｐｒ）は、新しいプロファイルの有効化をトリガするためのメッセージをＬＰＡｄｖ８００に送信する。プロファイル識別子ＩＣＣＩＤもメッセージの一部として提供され得る。

ステップ８１４において、ＬＰＡｄｖ８００は、識別情報モジュールで提供されたプロファイル識別子を用いてプロファイルの有効化をトリガし、識別情報モジュールは、プロファイルを有効化する。

ステップ８１５において、プロファイルの有効化が成功すると、新しいネットワークへの連結が実行される（この例のように、新しいプロファイルは新しいモバイルネットワークを伴う）。

ステップ８１６において、ＬＰＡｄｖ８００は、プロファイルの有効化が成功したかどうかを示す応答をＤ／Ｃ管理サーバ１０９に提供する。

ステップ８１６での応答の配信において、プロキシサーバ１０８は、新しいモバイルネットワークを介してＮＢ－ＩｏＴデバイス１０１からトラフィックを受信する。次いで、プロキシサーバ１０８は、ステップ８１７において、ＮＢ－ＩｏＴデバイス１０１のモバイルネットワークを切り替えることを決定することができ、これから先は、新しいモバイルネットワークを介してＮＢ－ＩｏＴデバイス１０１にデータを送信することができる。

プロファイルの有効化が成功し、プロファイルが新しいモバイルネットワークオペレータにあることに応答して、Ｄ／Ｃ管理サーバ１０９は、ステップ８１８において、新しいモバイルネットワークオペレータからのサービスを使用するように切り替えるようにプロキシサーバ１０８に命令し得る。例えば、プロキシサーバ１０８は、プロファイルが変更された特定のＮＢ－ＩｏＴデバイスの新しいモバイルネットワークで公開機能（例えば、ＳＣＥＦ）および／またはＰ－ＧＷを使用するように切り替えるように命令され得る。新しいモバイルネットワークへの登録は、以前に行われている可能性がある。ＮＢ－ＩｏＴデバイスのデバイス識別子は、使用される様々なＭＮＯサービス（ＳＣＥＦ、Ｐ－ＧＷなど）へのＵＲＬとともに提供され得る。

ステップ８１９において、プロキシサーバ１０８は、プロキシサーバ１０８の設定を、アプリケーションサーバからＮＢ－ＩｏＴデバイス１０１へのデータが今度は新しいモバイルネットワークを介して転送されるように変更し得る。プロキシサーバ１０８はまた、古いモバイルネットワークサービスから登録解除し得る。

図８は、ＮＩＤＤを使用できるＮＢ－ＩｏＴデバイスの場合に、ＳＭ－ＤＰ＋とＮＢ ＩｏＴデバイス１０１／識別情報モジュールとの間の通信がどのように実行されるかを示すフローの一例である。同じ技法を用いて、ＩｏＴに適合したすべてのＧＳＭＡ ＲＳＰ消費者版フローを適宜に適合させることができる。

デバイスとの間でデータを送受信する（デバイスタイプ１＆２）
このセクションでは、ＮＢ－ＩｏＴデバイス１０１との間でデータを送受信する方法について説明する。プロキシサーバ１０８は、アプリケーションサーバからＮＢ ＩｏＴデバイスにメッセージを送信するサービスと、ＮＢ－ＩｏＴデバイスからアプリケーションサーバにメッセージを中継し、応答メッセージを返すプロキシサービスとを提供する。これらのサービスは、ＮＩＤＤを使用するＮＢ－ＩｏＴデバイス向けである。ＩＰベースのトラフィックを使用するデバイスの場合、通信は、典型的には、プロキシサーバ１０８を介さない。代わりに、モバイルネットワークによって提供される標準のＩＰベースのトラフィック配信が使用されるが、ここではこれ以上検討しない。

ＮＩＤＤの場合、公開機能１０４またはＰ－ＧＷ１０２のいずれかを介するとき、モバイルネットワークは、ＮＢ－ＩｏＴデバイス１０１と公開機能１０４／Ｐ－ＧＷ１０２との間の高信頼トランスポートを提供しない。これは、高信頼トランスポートを保証するために、ＮＢ－ＩｏＴデバイス１０１内のデバイスアプリケーションとプロキシサーバ１０８との間で使用されるプロトコルが必要になり得ることを意味する。制約付きアプリケーションプロトコル（ＣｏＡＰ）は、アプリケーション関連のメッセージを転送するために制約付きＩｏＴデバイスにおいて一般的に使用されるプロトコルである。ＣｏＡＰは信頼性を提供する。したがって、通信にＣｏＡＰを使用すると、信頼性が確保される。ＣｏＡＰを使用しない場合、モバイルネットワークによって提供される高信頼データサービス（ＲＤＳ）プロトコルを使用して、デバイスと公開機能１０４／Ｐ－ＧＷ１０２との間の高信頼通信を実現することができる。

別の問題は、ＮＩＤＤを実行している各ＮＢ－ＩｏＴデバイスが複数のアプリケーションサーバとどのように通信し得るかである。ＣｏＡＰは、メッセージの対象受取側に関する情報をプロキシサーバに提供するために利用できる、Ｕｒｉ－ＨｏｓｔおよびＵｒｉ－ＰｏｒｔというＣｏＡＰオプションを含む。ＲＤＳは、ＮＢ－ＩｏＴデバイスのどのアプリケーションに対してどのアプリケーションサーバがメッセージを交換するかを示すために使用できるポートの使用をサポートする。ポートの使用を調整するかどうかは、サーバ、およびデバイスのアプリケーション次第である。

重要なことは、提供されるソリューションがＮＢ－ＩｏＴデバイス１０１とアプリケーションサーバとの間のエンドツーエンドのセキュリティを可能にすることである。ＯＳＣＯＲＥは、ＣｏＡＰが使用される通信を確保する際に使用され得るＣｏＡＰメッセージを保護するためのプロトコルである。プロキシサーバ１０８でのルーティング目的でＣｏＡＰを使用するとき、ＤＴＬＳまたはＴＬＳを使用してメッセージをエンドツーエンドで確保することができない場合がある。

ＣｏＡＰを使用した、公開機能を介したＮＩＤＤによるプロキシサーバのハンドリング（デバイスタイプ１）
このセクションでは、公開機能（例えば、ＳＣＥＦ）を介してＮＩＤＤを使用するＮＢ－ＩｏＴデバイスおよびアプリケーションサーバがプロキシサーバ１０８を介して相互にＣｏＡＰメッセージをどのように送信できるかについて説明する。

ＮＢ－ＩｏＴデバイスがＮＩＤＤを使用してアプリケーションサーバにメッセージを送信するとき、アプリケーションサーバに関する情報をプロキシサーバ１０８に提供することが必要とされ得る。ＣｏＡＰは、サーバＵＲＩに関する情報を提供できるＣｏＡＰオプションを使用している。これらは、Ｕｒｉ－Ｈｏｓｔ、Ｕｒｉ－Ｐｏｒｔ、Ｕｒｉ－Ｐａｔｈ、およびＵｒｉ－Ｑｕｅｒｙである。アプリケーションサーバとＮＢ－ＩｏＴデバイスとの間でＯＳＣＯＲＥにより保護されたメッセージを使用する場合、Ｕｒｉ－ＰａｔｈおよびＵｒｉ－Ｑｕｅｒｙは暗号化および完全性保護され、ＣｏＡＰメッセージの受信者（この場合はアプリケーションサーバ）のみが読み取ることができる。Ｕｒｉ－ＨｏｓｔおよびＵｒｉ－Ｐｏｒｔは、保護されたＣｏＡＰメッセージに含まれてもよく、その場合、プロキシサーバ１０８が情報を読み取ることができるように、暗号化も完全性保護もされない場合がある。通常、Ｕｒｉ－ＨｏｓｔおよびＵｒｉ－ＰｏｒｔがＩＰアドレスおよびＵＤＰ／ＴＣＰポートを示す場合、ＵＤＰ層またはＴＣＰ層から情報を推測できるため、これらのオプションは省略される。しかしながら、この場合、プロキシ動作が機能するように、各ＣｏＡＰ要求メッセージ内には、ＮＢ－ＩｏＴデバイスによって、少なくともＵｒｉ－Ｈｏｓｔオプション、場合によってはＵｒｉ－Ｐｏｒｔオプションも含まれ得る。図９にフローを示す。

図９は、公開機能１０４を介して、ＮＩＤＤを使用してＮＢ－ＩｏＴデバイスからアプリケーションサーバにＣｏＡＰ要求を送信することを示す。

ＮＢ－ＩｏＴデバイス１０１内のデバイスアプリケーションは、ＣｏＡＰ要求を準備する。この例では、受取側の情報を提供するために、Ｕｒｉ－Ｈｏｓｔおよび場合によりＵｒｉ－ＰｏｒｔがＣｏＡＰ要求に含まれる。

ステップ９０１において、デバイスアプリケーションは、ＮＩＤＤサービスを使用してＣｏＡＰ要求を送信する。ＣｏＡＰ要求は、ＭＭＥ１０５に配信される。

ステップ９０２において、ＭＭＥ１０５は、ＣｏＡＰ要求を公開機能１０４（この例ではＳＣＥＦ）に送信する。ＭＭＥは、転送されるメッセージにデバイス識別子（例えば、ＩＳＭＩ）を含めることができる。

ステップ９０３において、公開機能は、デバイスの外部識別子を求める要求をＨＳＳ１０６に送信する。要求は、ステップ９０２で受信したデバイス識別子を含む。

ステップ９０４において、ＨＳＳは、受信されたデバイス識別子に基づいて外部識別子を検索し、外部識別子を公開機能１０４に送信する。

ステップ９０５において、公開機能１０４は、外部識別子を含むＣｏＡＰ要求をプロキシサーバに転送する。

ステップ９０６において、プロキシサーバ１０８は、ＣｏＡＰ要求メッセージのＵｒｉ－ＨｏｓｔおよびＵｒｉ－Ｐｏｒｔ番号に基づいて、ＣｏＡＰ要求をどこに送信するかを決定する（送信先のＩＰアドレスおよびＵＤＰ／ＴＣＰポート番号は、場合によってはＤＮＳ検索を介して取得され得る）。プロキシサーバ１０８は、ネットワークアドレス変換（ＮＡＴ：Ｎｅｔｗｏｒｋ Ａｄｄｒｅｓｓ Ｔｒａｎｓｌａｔｉｏｎ）を実行し、要求メッセージを送信する各ＮＢ－ＩｏＴデバイスにＩＰアドレスおよびポート番号を割り当てる。各ＮＢ－ＩｏＴデバイスは、一意のＩＰｖ６アドレスまたはＩＰｖ４アドレス＋ポート番号を取得し得る。これらは、ＣｏＡＰ要求メッセージを転送するときに送信元アドレスとして使用される。プロキシサーバ１０８は、上記で決定された情報を使用して、ＴＣＰ／ＩＰまたはＵＤＰ／ＩＰヘッダをＣｏＡＰ要求に追加することができ、ステップ９０７において、ＣｏＡＰ要求をアプリケーションサーバ９００に転送する。プロキシサーバ１０８は、ＮＢ－ＩｏＴデバイス１０１の割り当てられたＩＰｖ６／ＩＰｖ４アドレス＋ポートおよび外部識別子またはＭＳＩＳＤＮのマッピングを格納する。

ステップ９０８において、アプリケーションサーバ９００は、ＣｏＡＰ要求メッセージを処理し、ステップ９０９において、ＣｏＡＰ応答メッセージを提供する。応答は、使用されるＩＰアドレスおよびポートに基づいてプロキシサーバ１０８に戻るようにルーティングされる。

ステップ９１０において、プロキシサーバ１０８は、応答メッセージの送信先のアドレスおよびポートを使用して、ＮＢ－ＩｏＴデバイス１０１の外部識別子またはＭＳＩＳＤＮを検索し、ＣｏＡＰ応答からＴＣＰ／ＩＰヘッダまたはＵＤＰ／ＩＰヘッダを削除する。ステップ９１１において、プロキシサーバ１０８は、公開機能ＮＩＤＤのデータ送信コマンドを使用して、外部識別子またはＭＳＩＳＤＮを示しながら、ＣｏＡＰ応答メッセージをデータとして送信する。

ステップ９１２において、公開機能は、ＮＢ－ＩｏＴデバイスのデバイス識別子を求める要求をＨＳＳ１０６に送信する。要求は、ステップ９１１で受信した外部識別子を含む。

ステップ９１３において、ＨＳＳは、外部識別子に基づいてデバイス識別子を検索し、デバイス識別子（例えば、ＩＭＳＩ）を公開機能１０４に送信する。

ステップ９１４において、公開機能ＮＩＤＤサービスは、ＣｏＡＰ応答メッセージをＭＭＥに転送し、次いで、ＭＭＥは、ステップ９１５において、ＣｏＡＰ応答を対象ＮＢ－ＩｏＴデバイスに転送し、ＣｏＡＰ応答は、ＣｏＡＰメッセージＩＤおよびＣｏＡＰトークン値に基づいて、ＣｏＡＰ要求に接続され、デバイスで実行されている正しいアプリケーションに転送され得る。

ここでのＣｏＡＰ応答の後に、アプリケーションからデバイスへのＣｏＡＰ要求が続く場合もあり、ＣｏＡＰ要求は、同じＣｏＡＰトークンの使用を通してデバイスからのＣｏＡＰ要求にリンクされる。プロキシサーバは、上記の説明により両方のメッセージを、デバイスへ戻すようにルーティングする。

集中的なデータ交換において各メッセージのために送信されるバイト数を最小限に抑えるために、ＣｏＡＰのＵｒｉ－ＨｏｓｔおよびＵｒｉ－Ｐｏｒｔオプションは、最初のＣｏＡＰ要求で送信され、その後、ＮＢ－ＩｏＴデバイスからの将来のＣｏＡＰ要求メッセージでは省略され得る。プロキシサーバは、Ｕｒｉ－Ｈｏｓｔ、Ｕｒｉ－Ｐｏｒｔ、およびＵｒｉ－ＰａｔｈオプションなしでＣｏＡＰ要求メッセージを受信すると、同じＮＢ－ＩｏＴデバイスからの最後のメッセージが転送されたのと同じアプリケーションサーバにメッセージを転送するように設定され得る。

プロキシサーバ１０８は、ＮＢ－ＩｏＴデバイス１０１に静的ＩＰｖ６アドレスを割り当て得るか、またはプロキシサーバ１０８は、特定のデバイスをアドレス指定するときに使用するアプリケーションサーバのためのＣｏＡＰリソースを提示し得る。後者の場合、プロキシサーバ１０８は、Ｕｒｉ－Ｐａｔｈ ＣｏＡＰオプションを使用して、アプリケーションサーバに認識されているリソース名および／またはデバイス識別子を示し得る（デバイス識別子は、リソースの名前であり得る）。この場合、アドレス指定されているＮＢ－ＩｏＴデバイスの保護されたＵｒｉ－Ｐａｔｈオプション関連のリソースに加えて、保護されていないＵｒｉ－Ｐａｔｈ ＣｏＡＰオプションが含まれ得ることに留意されたい。（保護されていないＣｏＡＰメッセージの場合、パスの最初の部分は、プロキシサーバ１０８のリソース名およびデバイス識別子であり得、その後にＮＢ－ＩｏＴデバイス上の対象リソースパスが続く）。次いで、プロキシサーバは、保護されていないＵｒｉ－Ｐａｔｈオプション（または、保護されていないＣｏＡＰメッセージの場合はパスの最初の部分）を消費し得る（例えば、転送する前に削除する）。プロキシサーバ１０８は、静的ＩＰｖ６アドレスまたはリソース名／デバイス識別子に対する外部識別子のマッピングを格納し得る。プロキシサーバ１０８は、外部識別子、アプリケーションサーバのＩＰアドレスおよびポート、ならびにＣｏＡＰメッセージＩＤおよびＣｏＡＰトークン値のマッピングも格納し得る。

図１０は、公開機能１０４を介して、ＮＩＤＤを使用してアプリケーションサーバ９００からＮＢ－ＩｏＴデバイス１０１にＣｏＡＰ要求を送信することを示す。

アプリケーションサーバは、ＣｏＡＰ要求を準備する。ＩＰアドレスまたはＵｒｉ－Ｐａｔｈオプションは、要求のアドレス指定先であるＮＢ－ＩｏＴデバイスを識別する。

ステップ１００１において、アプリケーションサーバ９００は、ＣｏＡＰ要求をプロキシサーバ１０８に送信する。

ステップ１００２において、プロキシサーバ１０８は、受信したＣｏＡＰ要求のＩＰアドレス、ポート、および場合によっては保護されていないＵｒｉ－Ｐａｔｈを分析して、ＣｏＡＰ要求がプロキシサーバ１０８自体に対するものであるか、ＮＢ－ＩｏＴデバイスに対するものであるかを判定する。ＮＢ－ＩｏＴデバイスの場合、ＮＢ－ＩｏＴデバイスの外部識別子は、データベース検索を使用して取得され、プロキシサーバ１０８は、ステップ１００３において、外部識別子を有するＣｏＡＰ要求を公開機能１０４に送信する。ＣｏＡＰ要求データをＮＢ－ＩｏＴデバイスに送信するために、公開機能ＮＩＤＤのデータ送信コマンドが使用される。

ステップ１００４において、公開機能は、ステップ１００３で受信した外部識別子に関連付けられたデバイス識別子を求める要求をＨＳＳ１０６に送信する。

ステップ１００５において、公開機能は、対応するデバイス識別子を受信し、この識別子は、この例ではＩＳＭＩを含む。

ステップ１００６において、公開機能１０４は、デバイス識別子を有するＣｏＡＰ要求をＭＭＥ１０５に送信する。

ステップ１００７において、ＭＭＥ１０５は、ＣｏＡＰ要求をデバイス１０１に送信する。

ステップ１００８において、ＮＢ－ＩｏＴデバイス１０１は、要求を処理する。アドレス指定されたリソースに基づいて、正しいアプリケーションが呼び出され、応答が準備される。ステップ１００９において、ＮＢ－ＩｏＴデバイス１０１は、ＣｏＡＰ応答をＭＭＥ１０５に送信する。

ステップ１００８において、ＮＢ－ＩｏＴデバイス１０１は、ＣｏＡＰ応答を提供し、ＣｏＡＰ要求からのＣｏＡＰメッセージＩＤおよびＣｏＡＰトークン値は、標準のＣｏＡＰ処理により使用される。次いで、ＣｏＡＰ応答は、ＮＩＤＤを使用して公開機能１０４に送信され得る。

例えば、ステップ１００９において、ＮＢ－ＩｏＴデバイスは、ＣｏＡＰ応答をＭＭＥに転送し、ＭＭＥは、ステップ１０１０において、ＣｏＡＰ応答をデバイス識別子とともに公開機能に転送する。

ステップ１０１１において、公開機能１０４は、ステップ１０１０で受信したデバイス識別子に関連付けられた外部識別子を求める要求をＨＳＳ１０６に送信する。ステップ１０１２において、公開機能１０４は、ＨＳＳ１０６から外部識別子を受信する。ステップ１０１３において、公開機能１０４は、ＣｏＡＰ応答を外部識別子とともにプロキシサーバ１０８に転送する。

ステップ１０１４において、プロキシサーバ１０８は、ＣｏＡＰ応答を処理する。受信した外部識別子ならびにＣｏＡＰメッセージＩＤおよび／またはＣｏＡＰトークンに基づいて、プロキシサーバ１０８は、データベースから、ＣｏＡＰ応答の転送先となるアプリケーションサーバのＩＰアドレスおよびポートを決定し得る。プロキシサーバ１０８は、上記で決定された情報を使用して、ＣｏＡＰ応答にＴＣＰ／ＩＰまたはＵＤＰ／ＩＰヘッダを追加することができ、ステップ１０１５において、ＣｏＡＰ応答をアプリケーションサーバ９００に転送する。送信元ＩＰアドレスおよびポートは、ＣｏＡＰ要求で使用されているものであり得、外部識別子から決定され得る。

ＣｏＡＰを使用した、Ｐ－ＧＷを介したＮＩＤＤによるプロキシサーバのハンドリング（デバイスタイプ２）
このセクションでは、Ｐ－ＧＷを介してＮＩＤＤを使用するデバイスおよびアプリケーションサーバがプロキシサーバを介して相互にＣｏＡＰメッセージをどのように送信できるかについて説明する。

ＮＢ－ＩｏＴデバイスは、図９を参照して説明した方法と同じ方法でＣｏＡＰメッセージを準備し得る。ＣｏＡＰは、代わりに、ＮＩＤＤを使用してＰ－ＧＷ１０２に転送され得る。Ｐ－ＧＷ１０２は、ＵＤＰ／ＩＰヘッダを追加し得、メッセージをプロキシサーバ１０８に転送し得る。送信元ＩＰアドレスおよびＵＤＰポートは、ＣｏＡＰメッセージの発信元であるＮＢ－ＩｏＴデバイスに対してＰ－ＧＷ１０２が割り当てたＩＰアドレスおよびポートであり得る。プロキシサーバ１０８は、アプリケーションサーバ９００のＩＰアドレスおよびポートを決定し得、図９を参照して説明した方法と同じ方法で、ＣｏＡＰメッセージをアプリケーションサーバ９００に転送し得る。プロキシサーバ１０８は、Ｐ－ＧＷ１０２によって割り当てられたようにＮＢ－ＩｏＴデバイス１０１のＩＰアドレスを保持し得るか、またはＮＢ－ＩｏＴデバイス１０１に新しいＩＰアドレスを割り当て、２つのＩＰアドレス間のマッピングをデータベースに格納し得る。後者の選択肢は、Ｐ－ＧＷ１０２で使用されるＮＢ－ＩｏＴデバイス１０１のＩＰアドレスがモバイルオペレータの変更により変更される一方で、静的アドレスがプロキシサーバ１０８によって保持され得る場合に有利である。

次に、アプリケーションサーバ９００は、ＣｏＡＰ要求を処理し、ＣｏＡＰ応答を提供し得る。ＣｏＡＰ応答は、使用されるＩＰアドレスおよびポートに基づいてプロキシサーバ１０８へ戻るようにルーティングされ、プロキシサーバ１０８によって、さらにＰ－ＧＷ１０２に（または、元のＩＰアドレスが保持されている場合は直接Ｐ－ＧＷ１０２に）ルーティングされ得る。Ｐ－ＧＷ１０２は、ＣｏＡＰ応答のＩＰアドレスおよびポートに基づいて、ＣｏＡＰ応答の転送先となるＮＢ－ＩｏＴデバイスを決定し、ＵＤＰ／ＩＰヘッダを削除し、ＣｏＡＰ応答を（Ｓ－ＧＷ１０３およびＭＭＥ１０５を介して）ＮＢ－ＩｏＴデバイスに転送し得る。ＮＢ－ＩｏＴデバイスにおいて、ＣｏＡＰ応答は、ＣｏＡＰメッセージＩＤおよびＣｏＡＰトークン値に基づいてＣｏＡＰ要求に接続され、ＮＢ－ＩｏＴデバイスで実行されている正しいアプリケーションに転送され得る。

いくつかの例において、プロキシサーバ１０８は、アプリケーションサーバがＣｏＡＰ要求を送信するために使用する静的ＩＰｖ６アドレスを、ＮＢ－ＩｏＴデバイスに割り当てていてもよい。プロキシサーバ１０８は、Ｐ－ＧＷ１０２によって割り当てられたようにＮＢ－ＩｏＴデバイスのＩＰアドレスを追跡し得る。これは、外部識別子に基づいてＩＰアドレスを照会することによって行われ得る。プロキシサーバ１０８は、Ｐ－ＧＷ１０２によって割り当てられたようにＩＰアドレスを使用してＣｏＡＰ要求を転送し得る。その場合、非ＩＰトラフィック専用のポートが使用され得る。代替として、プロキシサーバ１０８は、図１０を参照して説明したのと同様に、特定のデバイスをアドレス指定するときに使用するアプリケーションサーバ用のＣｏＡＰリソースを提示し得る。プロキシサーバ１０８は、モバイルコアネットワークサービスを使用して、リソース名に結び付けられた外部識別子に基づいて、ＮＢ－ＩｏＴデバイスの現在のＩＰアドレス（および場合によってはポート）を取得し得る。プロキシサーバ１０８は、（ＮＢ－ＩｏＴデバイスのＩＰアドレスを送信先アドレスとして使用して）ＣｏＡＰ要求をＰ－ＧＷ１０２に転送し得る。次いで、Ｐ－ＧＷは、ＵＤＰ／ＩＰヘッダを削除し、ＮＩＤＤサービスを使用して（Ｓ－ＧＷおよびＭＭＥを介して）メッセージをＮＢ－ＩｏＴデバイスに転送し得る。プロキシサーバ１０８は、デバイスのＩＰアドレスおよびポート、アプリケーションサーバのＩＰアドレスおよびポート、ならびにＣｏＡＰメッセージＩＤおよびＣｏＡＰトークン値のマッピングを格納し得る。

ＮＢ－ＩｏＴデバイスは、ＣｏＡＰ応答を提供することができ、ＣｏＡＰ要求からのＣｏＡＰメッセージＩＤおよびＣｏＡＰトークン値は、標準のＣｏＡＰ処理により使用される。ＣｏＡＰ応答は、ＮＩＤＤを使用してＰ－ＧＷ１０２に送信され、Ｐ－ＧＷ１０２は、ＵＤＰ／ＩＰヘッダを追加し、ＣｏＡＰ応答をプロキシサーバ１０８に転送し得る。プロキシサーバ１０８は、ＣｏＡＰ応答を処理し得る。プロキシサーバ１０８は、送信元ＩＰアドレスおよびポート、ＣｏＡＰメッセージＩＤおよび／またはＣｏＡＰトークンに基づいて、データベースから、ＣｏＡＰ応答の転送先となるアプリケーションサーバのＩＰアドレスおよびポートを決定し得る。

ＲＤＳを使用した、ＳＣＥＦを介したＮＩＤＤによるプロキシサーバのハンドリング（デバイスタイプ１）
このセクションでは、ＳＣＥＦを介してＮＩＤＤを使用するデバイスおよびアプリケーションサーバが、ＲＤＳが利用される場合、プロキシサーバを介して相互にメッセージをどのように送信できるかについて説明する。ＲＤＳは、ＮＢ－ＩｏＴデバイス１０１および公開機能１０４（例えば、ＳＣＥＦ）内に実装される。ここでは、ＮＢ－ＩｏＴデバイス１０１およびプロキシサーバ１０８が、ＮＢ－ＩｏＴデバイス１０１およびアプリケーションサーバ９００のアプリケーションをリンクするＲＤＳポートのセットを有するように設定されていると仮定する。このような設定は、典型的には、ＮＢ－ＩｏＴデバイス１０１およびプロキシサーバ１０８において、各ＮＢ－ＩｏＴデバイス１０１に関連付けられたデバイス管理サーバによって設定され得、実行時に更新され得る。デバイス管理サーバとの通信は、ＮＢ－ＩｏＴデバイスの製造中に設定され、初めてセットアップされるときにプロキシサーバ１０８内に設定される、静的ＲＤＳポートを使用し得る。

図１１は、ＲＤＳが使用される場合、公開機能を介して、ＮＩＤＤを使用してＮＢ－ＩｏＴデバイスからアプリケーションサーバに要求メッセージを送信する方法を示す。

ステップ１１０１において、デバイスアプリケーションは、ＮＩＤＤサービスを使用して要求メッセージを送信する。ＲＤＳプロトコルが使用され、要求メッセージはペイロードであり、ＲＤＳポート番号は、要求メッセージがどのアプリケーションサーバを対象としているかにより設定される。要求メッセージはＭＭＥ１０５に配信される。

ステップ１１０２において、ＭＭＥ１０５は、要求メッセージを公開機能１０４（この例では、ＳＣＥＦ）に送信する。ＭＭＥ１０５は、転送されるメッセージにデバイス識別子（例えば、ＩＳＭＩ）を含めることができる。

ステップ１１０３において、公開機能１０４は、デバイスの外部識別子を求める要求をＨＳＳ１０６に送信する。要求は、ステップ１１０２で受信したデバイス識別子を含む。

ステップ１１０４において、ＨＳＳ１０６は、受信されたデバイス識別子に基づいて外部識別子を検索し、外部識別子を公開機能１０４に送信する。

ステップ１１０５において、公開機能１０４は、外部識別子およびＲＤＳポート番号を含む要求メッセージをプロキシサーバ１０８に転送する。

ステップ１１０６において、プロキシサーバ１０８は、外部識別子およびＲＤＳポートから、送信先のＩＰアドレスおよびポートを決定する。アプリケーションサーバ９００のアドレス、および転送方法、例えば、要求メッセージをペイロードとして有するＴＣＰ／ＩＰを使用することは、データベースから知られる。プロキシサーバは、上記と同様にＮＢ－ＩｏＴデバイスにＩＰアドレスを割り当てており、ＩＰアドレスと外部識別子との間のマッピングは、プロキシサーバ１０８によってアクセス可能なデータベースに格納され得る。

ステップ１１０７において、プロキシサーバは、プロキシサーバ１０８によってアクセス可能なデータベース内のＲＤＳポート番号に関連付けられたアプリケーションサーバ９００に要求メッセージを転送する。

ステップ１１０８において、アプリケーションサーバ９００は、要求メッセージを処理し、ステップ１１０９において、応答メッセージを提供する。応答メッセージは、使用されるＩＰアドレスおよびポートに基づいてプロキシサーバ１０８に戻るようにルーティングされる。

ステップ１１１０において、プロキシサーバ１０８は、応答メッセージの送信先のアドレスおよびポートを使用して、ＮＢ－ＩｏＴデバイス１０１の外部識別子を検索し、応答メッセージからＴＣＰ／ＩＰヘッダまたはＵＤＰ／ＩＰヘッダを削除する。ステップ１１１１において、プロキシサーバ１０８は、公開機能ＮＩＤＤのデータ送信コマンドを使用して、外部識別子およびＲＤＳポートを示しながら、応答メッセージをデータ（ＲＤＳプロトコルペイロード）として送信する。

ステップ１１１２において、公開機能は、ＮＢ－ＩｏＴデバイスのデバイス識別子を求める要求をＨＳＳ１０６に送信する。要求は、ステップ１１１１で受信した外部識別子を含む。

ステップ１１１３において、ＨＳＳは、外部識別子に基づいてデバイス識別子を検索し、デバイス識別子（例えば、ＩＭＳＩ）を公開機能１０４に送信する。

ステップ１１１４において、公開機能ＮＩＤＤサービスは、応答メッセージをＭＭＥ１０５に転送し、次いで、ＭＭＥ１０５は、ステップ１１１５において、応答メッセージを対象ＮＢ－ＩｏＴデバイスに転送し、応答メッセージは、ＲＤＳポートに基づいて、デバイスで実行されている正しいアプリケーションに転送される。

プロキシサーバは、デバイスに静的ＩＰｖ６アドレスを割り当て得るか、またはプロキシサーバは、特定のデバイスをアドレス指定するときに使用するアプリケーションサーバ用のリソースを提示する。後者の場合、アプリケーションサーバはＵＲＩを使用して、アプリケーションサーバに認識されているリソース名および／またはデバイス識別子を示し得る（デバイス識別子はリソースの名前であり得る）。プロキシサーバは、静的ＩＰｖ６アドレスまたはリソース名／デバイス識別子に対する外部識別子またはＭＳＩＳＤＮのマッピングを格納している。プロキシサーバは、ＲＤＳポート番号およびアプリケーションサーバのＩＰアドレスまたはドメイン名のマッピングも格納する。

図１２は、ＲＤＳが使用される場合、公開機能１０４を介して、ＮＩＤＤを使用してアプリケーションサーバ９００からＮＢ－ＩｏＴデバイス１０１に要求メッセージを送信することを示す。

アプリケーションサーバは、要求メッセージを準備する。ＩＰアドレスまたはプロキシサーバリソースは、要求のアドレス指定先であるＮＢ－ＩｏＴデバイスを識別する。

ステップ１２０１において、アプリケーションサーバ９００は、要求メッセージをプロキシサーバ１０８に送信する。

ステップ１２０２において、プロキシサーバ１０８は、受信した要求メッセージのＩＰアドレス、ポート、および場合によってはＵＲＩを分析して、ＲＤＳ要求がプロキシサーバ１０８自体に対するものであるか、ＮＢ－ＩｏＴデバイスに対するものであるかを判定する。ＮＢ－ＩｏＴデバイスの場合、ＮＢ－ＩｏＴデバイスの外部識別子は、データベース検索を使用して取得され、プロキシサーバ１０８は、ステップ１２０３において、外部識別子を有する要求メッセージを公開機能１０４に送信する。要求メッセージをＮＢ－ＩｏＴデバイスに送信するために、公開機能ＮＩＤＤのデータ送信コマンドが使用される。ＲＤＳポートは、プロキシサーバによって送信元ＩＰアドレスの検索に基づいて設定される。

ステップ１２０４において、公開機能は、ステップ１２０３で受信した外部識別子に関連付けられたデバイス識別子を求める要求をＨＳＳ１０６に送信する。

ステップ１２０５において、公開機能は、対応するデバイス識別子を受信し、この識別子は、この例ではＩＳＭＩを含む。

ステップ１２０６において、公開機能１０４は、デバイス識別子を有する要求メッセージをＭＭＥ１０５に送信する。

ステップ１２０７において、ＭＭＥ１０５は、要求メッセージをデバイス１０１に送信する。

ステップ１２０８において、ＮＢ－ＩｏＴデバイス１０１は、要求メッセージを処理する。ＲＤＳポートに基づいて、正しいアプリケーションがＮＢ－ＩｏＴデバイス１０１で呼び出され、応答メッセージが準備される。ステップ１２０９において、ＮＢ－ＩｏＴデバイス１０１は、ＭＭＥ１０５に配信される応答メッセージを送信する。

ステップ１２０８において、ＮＢ－ＩｏＴデバイス１０１は、ＮＩＤＤを使用して公開機能１０４に送信され得る応答メッセージを提供する。

例えば、ステップ１２０９において、ＮＢ－ＩｏＴデバイス１０１は、応答メッセージをＭＭＥ１０５に転送し、ＭＭＥ１０５は、ステップ１２１０において、応答メッセージをデバイス識別子とともに公開機能１０４に転送する。

ステップ１２１１において、公開機能１０４は、ステップ１２１０で受信したデバイス識別子に関連付けられた外部識別子を求める要求をＨＳＳ１０６に送信する。ステップ１２１２において、公開機能１０４は、ＨＳＳ１０６から外部識別子を受信する。ステップ１２１３において、公開機能１０４は、応答メッセージを、外部識別子およびＲＤＳポート番号とともにプロキシサーバ１０８に転送する。

ステップ１２１４において、プロキシサーバ１０８は、応答メッセージを処理する。受信した外部識別子およびＲＤＳポート番号に基づいて、プロキシサーバ１０８は、データベースから、応答メッセージの転送先となるアプリケーションサーバのＩＰアドレスおよびポートを決定し得る。この特定のＲＤＳポートに有効な転送方法、例えばＴＣＰ／ＩＰは、データベースから取得され得る。プロキシサーバ１０８は、ステップ１２１５において、適切な転送方法により、応答メッセージをアプリケーションサーバ９００に転送し得る。送信元ＩＰアドレスおよびポートは、要求メッセージで使用されているものであり得、外部識別子から決定され得る。

ＲＤＳを使用した、Ｐ－ＧＷを介したＮＩＤＤによるプロキシサーバのハンドリング（デバイスタイプ２）
このセクションでは、Ｐ－ＧＷを介してＮＩＤＤを使用するデバイスとアプリケーションサーバが、ＲＤＳが利用される場合、プロキシサーバを介して相互にメッセージをどのように送信できるかについて説明する。ＲＤＳポートをＰ－ＧＷで使用できるかどうか、およびどのように使用できるかは、３ＧＰＰ仕様では明確に指定されていない。本明細書に記載の実施形態では、ある範囲のユーザデータグラムプロトコル（ＵＤＰ）ポートを、Ｐ－ＧＷでの非ＩＰデータ配信モードに使用することができる。各ＵＤＰポートはＲＤＳポートにマッピングされ得る。次いで、ＲＤＳポート番号は、異なるＵＤＰポート番号を使用することによって、Ｐ－ＧＷ１０２とプロキシサーバ１０８との間でシグナリングされ得る。

ＮＢ－ＩｏＴデバイスは、図１１を参照して説明した方法と同じ方法で、要求メッセージを準備することができ、要求メッセージは、ＮＩＤＤを使用してＰ－ＧＷ１０２に転送され得る。Ｐ－ＧＷ１０２は、要求メッセージをプロキシサーバ１０８に転送し得る。送信元ＩＰアドレスは、要求メッセージの発信元であるＮＢ－ＩｏＴデバイス１０１にＰ－ＧＷ１０２が割り当てたＩＰアドレスである。ＵＤＰ送信元ポート番号は、ＲＤＳポートを示す。次いで、プロキシサーバ１０８は、図１１を参照して説明した方法と同じ方法で、要求メッセージを正しいアプリケーションサーバ９００に転送し得る。

アプリケーションサーバ９００は、要求メッセージを処理し、応答メッセージを提供し得る。応答メッセージは、使用されるＩＰアドレスおよびポートに基づいてプロキシサーバ１０８へ戻るようにルーティングされ、図１１を参照して説明したように、さらにＰ－ＧＷ１０２にルーティングされ得、それに加えて、ＲＤＳポートは、上記の内容によりＵＤＰポートに反映される。次いで、Ｐ－ＧＷ１０２は、応答メッセージのＩＰアドレスおよびポートに基づいて、応答メッセージの転送先となるＮＢ－ＩｏＴデバイスを決定し得る。Ｐ－ＧＷ１０２は、ＵＤＰ／ＩＰヘッダを削除し、応答メッセージを転送し得る。使用されるＲＤＳポートは、送信先ＵＤＰポート番号から決定される。ＮＢ－ＩｏＴデバイスにおいて、応答メッセージは、ＲＤＳポートに基づいて、デバイスで実行されている正しいアプリケーションに転送され得る。

いくつかの例において、プロキシサーバ１０８は、アプリケーションサーバがＮＢ－ＩｏＴデバイスに要求メッセージを送信するために使用する静的ＩＰｖ６アドレスをＮＢ－ＩｏＴデバイスに割り当てていてもよい。代替として、プロキシサーバ１０８は、特定のＮＢ－ＩｏＴデバイスをアドレス指定するときに使用するアプリケーションサーバ用のリソースを提示し得る。プロキシサーバは、図１２を参照して説明したように、使用するべきＲＤＳポートを決定する。次いで、プロキシサーバ１０８は、要求メッセージをＰ－ＧＷに転送することができ、ＲＤＳポート番号に基づいて接続された非ＩＰトラフィック用の専用ポートが使用される。Ｐ－ＧＷは、ＵＤＰ／ＩＰヘッダを削除し、ＮＩＤＤサービスを使用して要求メッセージをＮＢ－ＩｏＴデバイスに転送し得る。プロキシサーバ１０８は、デバイスのＩＰアドレスおよびポート、ＲＤＳポート、ならびに場合によってはアプリケーションサーバのＩＰアドレスおよびポートのマッピングを格納し得る。

ＮＢ－ＩｏＴデバイスは、ＮＩＤＤを使用してＰ－ＧＷに送信され得る応答メッセージを提供し得る。Ｐ－ＧＷ１０２は、ＵＤＰ／ＩＰヘッダを追加し、応答メッセージをプロキシサーバ１０８に転送し得る。プロキシサーバ１０８は、応答を処理し得る。プロキシサーバ１０８は、送信元ＩＰアドレスおよびポートに基づいて、データベースから、応答メッセージの転送先となるアプリケーションサーバのＩＰアドレスおよびポートを決定し得る。

圧縮されたＩＰトラフィックによるＮＩＤＤサービスを使用したプロキシサーバのハンドリング（デバイスタイプ１＆２）
ＴＣＰ／ＩＰまたはＵＤＰ／ＩＰヘッダの影響をなくすために、ＮＩＤＤサービスを利用することは可能であるが、非ＩＰデータをペイロードデータとして送信する代わりに、圧縮されたＩＰデータをペイロードとして送信することができる。圧縮されたＩＰデータをペイロードとして送信することにより、ＮＢ－ＩｏＴデバイス、およびプロキシサーバまたはＳＣＥＦ／Ｐ－ＧＷのいずれかは、ＵＤＰ／ＩＰまたはＴＣＰ／ＩＰ圧縮をハンドリングする必要があり得る。使用できる様々な方式、例えば、ロバストヘッダ圧縮（ＲＯＨＣ：Ｒｏｂｕｓｔ Ｈｅａｄｅｒ Ｃｏｍｐｒｅｓｓｉｏｎ）、低電力無線パーソナルエリアネットワークを介したＩＰｖ６（６ＬｏＷＰＡＮ：ＩＰｖ６ ｏｖｅｒ Ｌｏｗ－Ｐｏｗｅｒ Ｗｉｒｅｌｅｓｓ Ｐｅｒｓｏｎａｌ Ａｒｅａ Ｎｅｔｗｏｒｋｓ）のための汎用ヘッダ圧縮（ＧＨＣ：Ｇｅｎｅｒｉｃ Ｈｅａｄｅｒ Ｃｏｍｐｒｅｓｓｉｏｎ）、および低電力無線エリアネットワーク（ＬＰＷＡＮ：Ｌｏｗ－Ｐｏｗｅｒ Ｗｉｒｅｌｅｓｓ Ａｒｅａ Ｎｅｔｗｏｒｋ）静的コンテキストヘッダ圧縮（ＳＣＨＣ：Ｓｔａｔｉｃ Ｃｏｎｔｅｘｔ Ｈｅａｄｅｒ Ｃｏｍｐｒｅｓｓｉｏｎ）が存在する。現在は、ＳＣＥＦもＰ－ＧＷもヘッダ圧縮方式をサポートしていない。ＵＤＰ／ＩＰまたはＴＣＰ／ＩＰヘッダを削除することと比較してこれらの方式がどれだけ効率的かは、デバイスが送信しているデータの量に依存する可能性がある。

圧縮されたＩＰベースのトラフィックを使用するとき、ＣｏＡＰオプションおよびＲＤＳポートを使用せずに、複数のアプリケーションサーバのアドレス指定を解決することができる。ＮＢ－ＩｏＴデバイスとＳＣＥＦ／Ｐ－ＧＷとの間の高信頼転送には、ＲＤＳが引き続き必要になり得る。ヘッダ圧縮が公開機能１０４でサポートされている場合、プロキシサーバ１０８は、アプリケーションサーバと公開機能１０４との間でパケットのみを中継し得る。プロキシサーバ１０８はそれでも、発信パケットの送信元ＩＰアドレスを、応答が戻る途中でプロキシサーバ１０８を介してルーティングされるようにセットすることができる。公開機能１０４がヘッダ圧縮をサポートしない場合、プロキシサーバ１０８は、上記に加えて、この部分も実装することができる。アプリケーションサーバからの着信パケットの場合、ソリューションは、静的ＩＰアドレスまたはデバイスごとのリソースを使用して前述したものと同じであり得る。次いで、プロキシサーバ１０８は、パケットを公開機能１０４に送信する前にパケットを圧縮し得る。

Ｐ－ＧＷ１０２がヘッダ圧縮をサポートする場合、ＮＢ－ＩｏＴデバイスからアプリケーションサーバに送信されるデータをプロキシサーバ１０８なしで管理することが可能である。トリガメッセージのために、また場合によってはアプリケーションサーバからＮＢ－ＩｏＴデバイスへのデータのために、プロキシサーバ１０８が依然として必要とされ得る。プロキシサーバ１０８がヘッダ圧縮を実施する場合、ソリューションは、公開機能の例の場合と同じであるが、上記のように、Ｐ－ＧＷを介したＮＩＤＤに起因する違いがある。

ＣｏＡＰとＲＤＳの両方を使用することができ、信頼性および複数のアプリケーションサーバとの通信を解決するために様々なハイブリッドソリューションが想定されることが理解されよう。

ＮＩＤＤを使用したセキュア通信
ＮＢ－ＩｏＴデバイスとアプリケーションサーバとの間のエンドツーエンドのセキュア通信は、ＲＤＳとＣｏＡＰのどちらを利用するのかに応じて様々な方法で実現され得る。ＲＤＳを使用する場合、ＮＢ－ＩｏＴデバイスとアプリケーションサーバとの間のセキュア通信のために、（プロキシサーバとアプリケーションサーバとの間でＴＣＰとＵＤＰのどちらのトランスポートプロトコルが使用されるかに応じて）ＴＬＳまたはＤＴＬＳを使用することが可能である。ここで、ＴＬＳ／ＤＴＬＳメッセージはＲＤＳ上で直接転送され得ることに留意されたい。ＣｏＡＰを使用する（ＲＤＳを使用しない）とき、ＣｏＡＰヘッダは、プロキシサーバ動作用に平文である可能性がある。その場合、トランスポート層でＴＬＳ／ＤＴＬＳを使用できないことは明らかであり、通信をエンドツーエンドで確保するためにＯＳＣＯＲＥを使用することが推奨され得る。次に、ＥＤＨＯＣを使用して、共有セキュリティコンテキストを確立するために必要な２者間で共有されるＯＳＣＯＲＥマスターシークレットを確立することができる。メッセージを確保するために、例えばＣＯＳＥを利用するアプリケーション固有のソリューションを使用した、追加の代替手段も可能であり得る。

ＧＳＭＡ ＲＳＰ Ｍ２Ｍ版：デバイスとの間でプロファイルダウンロードおよびプロファイル管理データを送受信する
このセクションでは、プロファイル管理サーバとの通信に関連する問題について対応する。

識別情報モジュールとプロファイル管理サーバとの間でＨＴＴＰＳ（またはＣＡＴ＿ＴＰ）セッションが確立される通信と、ＮＢ－ＩｏＴデバイスからプロファイル管理サーバへのＳＭＳ形式のメッセージの配信との２つの異なるケースについて考える。前者はタイプ１およびタイプ２のデバイスに適用され、後者はすべてのタイプのデバイスに適用される。

ＨＴＴＰＳ（またはＣＡＴ＿ＴＰ）セッションを使用した通信
ＧＳＭＡ ＲＳＰ Ｍ２Ｍ版は、識別情報モジュールとＳＭ－ＳＲ（プロファイル管理サーバの一部）との間にＨＴＴＰＳセッション（またはＣＡＴ＿ＴＰセッション）を確立し、これら２つのエンドポイント間でＨＴＴＰＳデータ（またはＣＡＴ＿ＴＰデータ）を送信することを含む。識別情報モジュールとＮＢ－ＩｏＴデバイスとの間の通信のために、ＮＢ－ＩｏＴデバイスにおいて、ベアラ非依存プロトコル（ＢＩＰ：Ｂｅａｒｅｒ Ｉｎｄｅｐｅｎｄｅｎｔ Ｐｒｏｔｏｃｏｌ）を使用することができる。識別情報モジュールは、ＢＩＰプロトコルを用いて、ＳＭ－ＳＲへの通信チャネルを開閉し、データを送受信することができる。図６のステップ６０５でトリガメッセージが受信される前に、ＳＭ－ＳＲがＮＢ－ＩｏＴデバイス／識別情報モジュールに認識されない場合がある。ＩＰベースのトラフィックを介してＳＭ－ＳＲと直接通信するには、ＴＣＰ／ＩＰがＮＢ－ＩｏＴデバイスでサポートされている必要があり得る。ＣｏＡＰ／ＵＤＰ／ＩＰスタックをサポートする制約付きＮＢ－ＩｏＴデバイスは、ＴＣＰをサポートしない場合があり、プロファイル管理サーバと通信するときにＮＩＤＤを介した通信を使用するように設定され得る。

ＲＤＳを使用するとき、図６のステップ６０６でセキュア通信を確立できるように、デバイスおよびプロキシサーバにおいて、ＳＭ－ＳＲとの通信に使用するＲＤＳポート番号が設定されなければならない。ＲＤＳポート番号を設定することは、Ｄ／Ｃ管理サーバ１０９の役割である。ＲＤＳポート番号は、例えば、図６のステップ６０３でＤ／Ｃ管理サーバ１０９から送信されるときに、トリガメッセージの一部として含まれ得る。ステップ６０３の一部として、Ｄ／Ｃ管理サーバ１０９はまた、プロキシサーバ１０８へのＲＤＳポート番号を設定し得る。ＲＤＳポート番号に関連して、プロキシサーバ１０８においてＵＰＤ／ＩＰ通信とＴＣＰ／ＩＰ通信のどちらを使用すべきかに関する情報も提供され得る。

ＣｏＡＰがＮＢ－ＩｏＴデバイスからすべてのアプリケーションサーバへのすべての通信のベアラとして使用され、ＲＤＳが使用されないとき、ＳＭ－ＳＲを使用したＨＴＴＰＳ（またはＣＡＴ＿ＴＰ）ベースのトラフィックなどのアプリケーションサーバとの非ＣｏＡＰベースの通信には、特別なソリューションが必要になる場合がある。非ＣｏＡＰベースのメッセージは、プロキシサーバ１０８とＮＢ－ＩｏＴデバイスとの間でＣｏＡＰペイロードとして運ばれ得る。プロキシサーバ１０８は、メッセージをＮＢ－ＩｏＴデバイスからＳＭ－ＳＲに転送する前にＣｏＡＰヘッダを削除する必要があり得、メッセージをＳＭ－ＳＲからＮＢ－ＩｏＴデバイスに転送する前にＣｏＡＰヘッダを追加し得る。この特定のプロキシサーバの挙動を適用させるために、プロキシサーバ１０８において、ＮＢ－ＩｏＴデバイスが書き込むことができる特別なリソースを使用することができる。例えば、Ｕｒｉ－Ｈｏｓｔオプションを「プロキシ」にセットし、Ｕｒｉ－Ｐｏｒｔオプションを使用せず、Ｕｒｉ－Ｐａｔｈオプションを、このリソース名の後に転送メカニズム（ＵＤＰまたはＴＣＰ）、ホスト名、ポート、および応答を書き込むことができるＮＢ－ＩｏＴデバイスでのリソース名が続くことを示すようにセットすることができる。次いで、プロキシサーバは、ＮＢ－ＩｏＴデバイスからトラフィックを転送するときに「通常の」ＣｏＡＰトラフィックとは異なるＵＤＰ／ＴＣＰポート番号を使用することができ、その結果、プロキシサーバは、アプリケーションサーバからのどのトラフィックに対してＣｏＡＰヘッダを追加するべきかを認識できるようになる。プロキシサーバは、アプリケーションサーバからの応答を、アプリケーションサーバから受信したＣｏＡＰ要求にリンクできるように、ＣｏＡＰメッセージＩＤおよびＣｏＡＰトークン値を保存する必要があり得る。プロキシサーバがアプリケーションサーバからＮＢ－ＩｏＴデバイスにデータを書き込むときに使用するプロファイルダウンロードおよびプロファイル管理データのために、ＮＢ－ＩｏＴデバイスでの特別なリソースが使用され得る。このリソースに書き込む場合、データは、識別情報モジュールを駆動するアプリケーションに送信され、アプリケーションは、ＢＩＰプロトコルを使用してデータを識別情報モジュールに転送する。

上記と同じように、ＨＴＴＰＳメッセージを転送するために複数のＣｏＡＰメッセージがＮＢ－ＩｏＴデバイスからプロキシサーバの特別なリソースに送信されている場合、最初のＣｏＡＰ要求メッセージ内にのみＵｒｉ－ＨｏｓｔおよびＵｒｉ－Ｐａｔｈオプションを含めることができ、プロキシサーバは、これらのオプションなしで次のＣｏＡＰ要求メッセージを同じように処理することができる。

ＳＭＳ形式のメッセージの配信
ＮＢ－ＩｏＴデバイスからプロファイル管理サーバへのＳＭＳ形式のメッセージの配信には、「ＨＴＴＰＳ（またはＣＡＴ＿ＴＰ）セッションを使用した通信」というタイトルのセクションで使用されているものとは異なる専用ＵＲＬを使用することができる。このＵＲＬは、Ｄ／Ｃ管理サーバ１０９によってプロキシサーバ１０８に設定され得る。ＲＤＳを使用するとき、「ＨＴＴＰＳ（またはＣＡＴ＿ＴＰ）セッションを使用した通信」で説明したものと同じタイプのソリューションが適用されるが、専用ＲＤＳポートが使用される。ＮＢ－ＩｏＴデバイスからのメッセージでこのＲＤＳポートを使用すると、プロキシサーバ１０８は、このメッセージ（ＳＭＳ形式のデータ）を、このポートに登録された専用ＵＲＬに書き込むことになる。これは、ＨＴＴＰベースのインターフェースまたは低レベルソケットインターフェースであり得る。プロキシサーバ１０８は、プロファイル管理サーバ１０７で事前登録され、プロファイル管理サーバ１０７は、プロキシサーバ１０８がメッセージを書き込むことを可能にする。ＳＭＳ形式のデータは、ＧＳＭＡ ＲＳＰ Ｍ２Ｍ版で規定されている標準メカニズムに従って保護され得る。ＳＭＳ形式のデータは、メッセージの送信者を決定するための、プロファイル管理サーバ１０７に対する送信者識別子（例えば、ＥＩＤ）を含み得る。

メッセージの配信のためにＣｏＡＰが使用される例では、「ＨＴＴＰＳ（またはＣＡＴ＿ＴＰ）セッションを使用した通信」で説明したものと同じであるが、ＳＭＳ形式のメッセージをハンドリングするために「ＨＴＴＰＳ（またはＣＡＴ＿ＴＰ）セッションを使用した通信」とは異なる専用のリソースを用いる。このリソースへの書き込みは、上記のＲＤＳの場合と同じ方法でプロファイル管理サーバにメッセージを送信するようにプロキシサーバをトリガする。

ＧＳＭＡ ＲＳＰ消費者版：デバイスとの間でプロファイルダウンロードおよびプロファイル管理データを送受信する
このセクションでは、デバイスのＬＰＡｄとプロファイル管理サーバとの間のＨＴＴＰＳベースの通信について検討する。これは、タイプ１およびタイプ２のデバイスに適用される。上で説明したように、ＣｏＡＰ／ＵＤＰ／ＩＰスタックをサポートする制約付きＮＢ－ＩｏＴデバイスは、ＴＣＰをサポートしない可能性があり、プロファイル管理サーバ１０７と通信するときにＮＩＤＤを介した通信を使用するように設定され得る。ここでは、プロキシサーバとデバイスとの間でＨＴＴＰＳメッセージを転送するためにＲＤＳまたはＣｏＡＰのいずれかが使用される場合、およびプロキシサーバがさらにプロファイル管理サーバへメッセージを転送することをハンドリングする場合の２つの場合に、「ＨＴＴＰＳ（またはＣＡＴ＿ＴＰ）セッションを使用した通信」で説明したものと同じソリューションが適用される。

ＩｏＴに適合したＧＳＭＡ ＲＳＰ消費者版の場合、ＨＴＴＰＳは、デバイスの外に移動され、プロキシサーバ１０８による特別なハンドリングを必要としない場合がある。

Ｄ／Ｃ管理サーバ１０９とＮＢ－ＩｏＴデバイスとの間のセキュア通信には、「デバイスとの間でデータを送受信する（デバイスタイプ１＆２）」に記載の技法が適用される。図７のステップ７０３から７０４および７１２から７１３、ならびに図８のステップ８０３から８０４および８１０から８１１においてＤ／Ｃ管理サーバ１０９からＮＢ－ＩｏＴデバイス１０１に送信されるトリガメッセージは、保護される必要がない場合がある。

新しいＭＮＯのサービスを使用するようにプロキシサーバを更新する
図５、図６、図７、および図８に示すように、新しいモバイルネットワークオペレータの新しいプロファイルを有効化するとき、プロキシサーバが使用するＮＩＤＤおよび監視サービスを、現在のモバイルネットワークから新しいモバイルネットワークオペレータに切り替える必要がある。上に示したように、プロキシサーバ１０８は、新しいネットワークへの切り替えが決定されるとすぐに、すなわち、新しいネットワークのプロファイルが無効化されようとしているときに新しいモバイルネットワークのサービスに登録するように、Ｄ／Ｃ管理サーバ１０９によって命令され得る。プロキシサーバ１０８は、一度に２つ以上のモバイルネットワークからＮＩＤＤサービスに登録され得る。ＮＢ－ＩｏＴデバイスからアプリケーションサーバへのデータの場合、プロキシサーバ１０８は、データがどのネットワークから来たのかという情報を格納することができ、データを同じネットワークに戻すようにルーティングすることができる。しかしながら、アプリケーションサーバからＮＢ－ＩｏＴデバイスへのデータの場合、プロキシサーバ１０８は、ＮＢ－ＩｏＴデバイスが現在どのネットワークにあるかを認識する必要があり得る。いくつかの例において、プロキシサーバ１０８は、新しいネットワークからデータを受信するまで現在のネットワークに留まり、その後、すべてのトラフィックを新しいネットワークに切り替える。Ｄ／Ｃ管理サーバ１０９が（例えば、プロファイル管理サーバ１０７から）プロファイルの有効化が成功したとの確認応答を受信すると、これは、前のネットワークのサービスから登録解除することができるプロキシサーバ１０８に通知され得る。

異なるモバイルネットワークを備えた同じＮＢ－ＩｏＴデバイスに対して、異なる外部識別子（例えば、ＭＳＩＳＤＮ）が使用される場合がある。この例では、プロキシサーバ１０８に新しいモバイルネットワークのサービスに登録するように命令するときに、新しい外部識別子は、Ｄ／Ｃ管理サーバ１０９によってプロキシサーバにあるように設定され得る。次いで、プロキシサーバ１０８は、プロファイル間の切り替えが完了するまで２つの外部識別子間を変換することができ、完了した場合、古い外部識別子は無視され得る。

デバイス／コネクティビティ（Ｄ／Ｃ）管理サーバと統合されたプロキシサーバ
いくつかの例において、プロキシサーバ１０８とＤ／Ｃ管理サーバ１０９は、同一のサーバである。したがって、Ｄ／Ｃ管理サーバ１０９は、ＮＢ－ＩｏＴデバイス、およびそれらが通信するアプリケーションサーバ、ならびにこれらのアプリケーションサーバとの通信においてプロキシサーバ１０８がＮＢ－ＩｏＴデバイスを支援していることについての知識を有し得る。

図１３は、処理回路（または論理）１３０１を含むプロキシサーバ１３００を示す。処理回路１３０１は、プロキシサーバ１３００の動作を制御し、プロキシサーバ１３００（例えば、プロキシサーバ１０８）に関連して本明細書に記載されている方法を実施することができる。処理回路１３０１は、本明細書に記載の方式でプロキシサーバ１３００を制御するように設定またはプログラムされた１つまたは複数のプロセッサ、処理ユニット、マルチコアプロセッサまたはモジュールを備えることができる。特定の実装形態において、処理回路１３０１は、プロキシサーバ１３００に関連して本明細書に記載されている方法の個々のまたは複数のステップを実行するように各々設定された、または実行するための複数のソフトウェアおよび／またはハードウェアモジュールを備えることができる。

簡単に言えば、プロキシサーバ１３００の処理回路１３０１は、トリガメッセージをＮＢ－ＩｏＴデバイスに配信するよう求める要求を受信することであって、要求がデバイス識別子を含む、要求を受信することと、受信したデバイス識別子に基づいて外部識別子を決定することと、外部識別子を使用してトリガメッセージをＮＢ－ＩｏＴデバイスに配信することとを行うように設定される。

いくつかの実施形態において、プロキシサーバ１３００は、任意選択として、通信インターフェース１３０２を備え得る。プロキシサーバ１３００の通信インターフェース１３０２は、他の仮想ノードなどの他のノードとの通信に使用することができる。例えば、プロキシサーバ１３００の通信インターフェース１３０２は、要求、リソース、情報、データ、信号、もしくは同様のものを他のノードに送信するように、かつ／または他のノードから受信するように設定され得る。プロキシサーバ１３００の処理回路１３０１は、要求、リソース、情報、データ、信号、もしくは同様のものを他のノードに送信するように、かつ／または他のノードから受信するように、プロキシサーバ１３００の通信インターフェース１３０２を制御するように設定され得る。

任意選択として、プロキシサーバ１３００は、メモリ１３０３を備え得る。いくつかの実施形態において、プロキシサーバ１３００のメモリ１３０３は、プロキシサーバ１３００に関連して本明細書に記載されている方法を実行するためにプロキシサーバ１３００の処理回路１３０１によって実行され得るプログラムコードを記憶するように設定され得る。代替として、または追加として、プロキシサーバ１３００のメモリ１３０３は、本明細書で記載の任意の要求、リソース、情報、データ、信号、または同様のものを記憶するように設定され得る。プロキシサーバ１３００の処理回路１３０１は、本明細書に記載の任意の要求、リソース、情報、データ、信号、または同様のものを記憶するように、プロキシサーバ１３００のメモリ１３０３を制御するように設定され得る。

図１４は、処理回路（または論理）１４０１を備えるデバイスコネクティビティ（Ｄ／Ｃ）管理サーバ１４００を示す。処理回路１４０１は、Ｄ／Ｃ管理サーバ１４００の動作を制御し、Ｄ／Ｃ管理サーバ１４００（例えば、Ｄ／Ｃ管理サーバ１０８）に関連して本明細書に記載されている方法を実施することができる。処理回路１４０１は、本明細書に記載の方式でＤ／Ｃ管理サーバ１４００を制御するように設定またはプログラムされた１つまたは複数のプロセッサ、処理ユニット、マルチコアプロセッサまたはモジュールを備えることができる。特定の実装形態において、処理回路１４０１は、Ｄ／Ｃ管理サーバ１４００に関連して本明細書に記載されている方法の個々のまたは複数のステップを実行するように各々設定された、または実行するための複数のソフトウェアおよび／またはハードウェアモジュールを備えることができる。

簡単に言えば、Ｄ／Ｃ管理サーバ１４００の処理回路１４０１は、トリガメッセージをＮＢ－ＩｏＴデバイスに配信するよう求める要求をプロキシサーバに送信するように設定され、要求は、デバイス識別子およびトリガメッセージを含む。

いくつかの実施形態において、Ｄ／Ｃ管理サーバ１４００は、任意選択として、通信インターフェース１４０２を備え得る。Ｄ／Ｃ管理サーバ１４００の通信インターフェース１４０２は、他の仮想ノードなどの他のノードとの通信に使用することができる。例えば、Ｄ／Ｃ管理サーバ１４００の通信インターフェース１４０２は、要求、リソース、情報、データ、信号、もしくは同様のものを他のノードに送信するように、かつ／または他のノードから受信するように設定され得る。Ｄ／Ｃ管理サーバ１４００の処理回路１４０１は、要求、リソース、情報、データ、信号、もしくは同様のものを他のノードに送信するように、かつ／または他のノードから受信するように、Ｄ／Ｃ管理サーバ１４００の通信インターフェース１４０２を制御するように設定され得る。

任意選択として、Ｄ／Ｃ管理サーバ１４００は、メモリ１４０３を備え得る。いくつかの実施形態において、Ｄ／Ｃ管理サーバ１４００のメモリ１４０３は、Ｄ／Ｃ管理サーバ１４００に関連して本明細書に記載されている方法を実行するためにＤ／Ｃ管理サーバ１４００の処理回路１４０１によって実行され得るプログラムコードを記憶するように設定され得る。代替として、または追加として、Ｄ／Ｃ管理サーバ１４００のメモリ１４０３は、本明細書に記載の任意の要求、リソース、情報、データ、信号、または同様のものを記憶するように設定され得る。Ｄ／Ｃ管理サーバ１４００の処理回路１４０１は、本明細書に記載の任意の要求、リソース、情報、データ、信号、または同様のものを記憶するように、Ｄ／Ｃ管理サーバ１４００のメモリ１４０３を制御するように設定され得る。

図１５は、処理回路（または論理）１５０１を含む狭帯域モノのインターネット（ＮＢ－ＩｏＴ）デバイス１５００を示す。処理回路１５０１は、ＮＢ－ＩｏＴデバイス１５００の動作を制御し、ＮＢ－ＩｏＴデバイス１５００（例えば、ＮＢ－ＩｏＴデバイス１０８）に関連して本明細書に記載されている方法を実施することができる。処理回路１５０１は、本明細書に記載の方式でＮＢ－ＩｏＴデバイス１５００を制御するように設定またはプログラムされた１つまたは複数のプロセッサ、処理ユニット、マルチコアプロセッサまたはモジュールを備えることができる。特定の実装形態において、処理回路１５０１は、ＮＢ－ＩｏＴデバイス１５００に関連して本明細書に記載されている方法の個々のまたは複数のステップを実行するように各々設定された、または実行するための複数のソフトウェアおよび／またはハードウェアモジュールを備えることができる。

簡単に言えば、ＮＢ－ＩｏＴデバイス１５００の処理回路１５０１は、プロキシサーバによって配信されたトリガメッセージを受信するように設定される。

いくつかの実施形態において、ＮＢ－ＩｏＴデバイス１５００は、任意選択として、通信インターフェース１５０２を備え得る。ＮＢ－ＩｏＴデバイス１５００の通信インターフェース１５０２は、他の仮想ノードなどの他のノードとの通信に使用することができる。例えば、ＮＢ－ＩｏＴデバイス１５００の通信インターフェース１５０２は、要求、リソース、情報、データ、信号、もしくは同様のものを他のノードに送信するように、かつ／または他のノードから受信するように設定され得る。ＮＢ－ＩｏＴデバイス１５００の処理回路１５０１は、要求、リソース、情報、データ、信号、もしくは同様のものを他のノードに送信するように、かつ／または他のノードから受信するように、ＮＢ－ＩｏＴデバイス１５００の通信インターフェース１５０２を制御するように設定され得る。

任意選択として、ＮＢ－ＩｏＴデバイス１５００は、メモリ１５０３を備え得る。いくつかの実施形態において、ＮＢ－ＩｏＴデバイス１５００のメモリ１５０３は、ＮＢ－ＩｏＴデバイス１５００に関連して本明細書に記載されている方法を実行するためにＮＢ－ＩｏＴデバイス１５００の処理回路１５０１によって実行され得るプログラムコードを記憶するように設定され得る。代替として、または追加として、ＮＢ－ＩｏＴデバイス１５００のメモリ１５０３は、本明細書に記載の任意の要求、リソース、情報、データ、信号、または同様のものを記憶するように設定され得る。ＮＢ－ＩｏＴデバイス１５００の処理回路１５０１は、本明細書に記載の任意の要求、リソース、情報、データ、信号、または同様のものを記憶するように、ＮＢ－ＩｏＴデバイス１５００のメモリ１５０３を制御するように設定され得る。

上記の実施形態が本発明を限定ではなく例示すること、および当業者であれば、添付の特許請求の範囲から逸脱することなく多くの代替の実施形態を設計できることに留意されたい。「含む（ｃｏｍｐｒｉｓｉｎｇ）」という語は、特許請求の範囲に記載されたもの以外の要素またはステップの存在を排除するものではなく、「１つの（ａまたはａｎ）」は複数を排除するものではなく、単一のプロセッサまたは他のユニットは、特許請求の範囲に記載のいくつかのユニットの機能を果たし得る。特許請求の範囲におけるいずれの参照記号もその範囲を制限するとは解釈しないものとする。

Claims (5)

1. プロキシサーバにおいて、狭帯域モノのインターネット（ＮＢ－ＩｏＴ）デバイス内の識別情報モジュールにおけるプロファイルのリモート管理を可能にするための方法であって、前記プロキシサーバが、各々が１つまたは複数のＮＢ－ＩｏＴデバイスのうちのそれぞれ１つに関連付けられた１つまたは複数の外部識別子のデータベースへのアクセスを有するように設定され、前記１つまたは複数の外部識別子が各々、コアネットワーク内の公開機能を介して前記１つまたは複数のＮＢ－ＩｏＴデバイスのうちの前記それぞれ１つをアドレス指定するために使用され、前記方法が、
   トリガメッセージを前記ＮＢ－ＩｏＴデバイスに配信するよう求める要求を、プロファイル管理サーバから受信することであって、前記要求が前記ＮＢ－ＩｏＴデバイスのデバイス識別子を含み、前記プロキシサーバが前記プロファイル管理サーバと前記公開機能との間で使用される、要求を受信することと、
   受信した前記デバイス識別子に基づいて、前記データベースから前記ＮＢ－ＩｏＴデバイスの外部識別子を決定することと、
   非ＩＰデータ配信（ＮＩＤＤ）サービスを使用して前記ＮＢ－ＩｏＴデバイスに転送するために、前記トリガメッセージを前記外部識別子とともに前記公開機能に送信することであって、前記トリガメッセージが、前記プロファイル管理サーバからプロファイルをダウンロードするよう前記ＮＢ－ＩｏＴデバイスをトリガするように設定されたプロファイルダウンロードトリガメッセージ、またはプロファイル管理動作を実行するよう前記ＮＢ－ＩｏＴデバイス内の識別情報モジュールをトリガするように設定されたプロファイル管理トリガメッセージのいずれかを含む、トリガメッセージを送信することと
   を含む、方法。
2. 前記トリガメッセージが、前記プロファイル管理サーバのユニフォームリソースロケータ（ＵＲＬ）を含む、請求項１に記載の方法。
3. 前記トリガメッセージが、デバイスコネクティビティ管理（Ｄ／Ｃ）サーバの識別を含む、請求項１または２に記載の方法。
4. 狭帯域モノのインターネット（ＮＢ－ＩｏＴ）デバイス内の識別情報モジュールにおけるプロファイルのリモート管理を可能にするためプロキシサーバであって、前記プロキシサーバが、各々が１つまたは複数のＮＢ－ＩｏＴデバイスのうちのそれぞれ１つに関連付けられた１つまたは複数の外部識別子のデータベースへのアクセスを有するように設定され、前記１つまたは複数の外部識別子が各々、コアネットワーク内の公開機能を介して前記１つまたは複数のＮＢ－ＩｏＴデバイスのうちの前記それぞれ１つをアドレス指定するために使用され、前記プロキシサーバが、
   トリガメッセージを前記ＮＢ－ＩｏＴデバイスに配信するよう求める要求を、プロファイル管理サーバから受信することであって、前記要求が前記ＮＢ－ＩｏＴデバイスのデバイス識別子を含み、前記プロキシサーバが前記プロファイル管理サーバと前記公開機能との間で使用される、要求を受信することと、
   受信した前記デバイス識別子に基づいて、前記データベースから前記ＮＢ－ＩｏＴデバイスの外部識別子を決定することと、
   非ＩＰデータ配信（ＮＩＤＤ）サービスを使用して前記ＮＢ－ＩｏＴデバイスに転送するために、前記トリガメッセージを前記外部識別子とともに前記公開機能に送信することであって、前記トリガメッセージが、前記プロファイル管理サーバからプロファイルをダウンロードするよう前記ＮＢ－ＩｏＴデバイスをトリガするように設定されたプロファイルダウンロードトリガメッセージ、またはプロファイル管理動作を実行するよう前記ＮＢ－ＩｏＴデバイス内の識別情報モジュールをトリガするように設定されたプロファイル管理トリガメッセージのいずれかを含む、トリガメッセージを送信することと
   を行うように設定された処理回路を備える、プロキシサーバ。
5. 前記処理回路が、前記プロキシサーバに、請求項２または３に記載の前記方法を実行させるようにさらに設定される、請求項４に記載のプロキシサーバ。

Images