本明細書に記載の実施形態は、狭帯域モノのインターネット(NB-IoT:narrow band Internet of Things)デバイス内の識別情報モジュールへのプロファイルのリモート管理を可能にするための方法および装置に関する。プロファイルのリモート管理は、プロファイルをNB-IoTデバイスにプロビジョニングすること、および/または既存のプロファイルを更新もしくは調整することを含み得る。
加入者識別情報モジュール(SIM:Subscriber Identity Module)カードは、1991年に商業的に展開され、それ以来、モバイルネットワークへのセキュアで識別可能な認証済みのアクセスを保証してきた。消費者にとってのSIMフォームファクタの別の利点は、連絡先がSIMカード上のメモリに記憶されているため、SIMカードをデバイス間で入れ替えて、名前および番号を失うことなくハードウェアをアップグレードできることであった。SIMカードを使用すると、消費者は自分のデバイスを別のモバイルオペレータに容易に切り替えられることにもなる。
SIMは、導入以来、新世代のセルラ技術ごとにサイズが縮小され、能力が向上している。しかしながら、新興のマシンツーマシン(M2M:machine-to-machine)およびモノのインターネット(IoT:Internet of Things)市場では、異なるサービスパラダイムがあり、時として非常に離れた場所にある大規模なIoTデバイスフリートのSIMを物理的に取り外すことおよび入れ替えることは、コストがかかり、煩雑になる。
ほとんどの企業にとっての課題は、長くてしばしば複雑なサプライチェーンにおける様々な地点で、SIMカードとデバイスとの組合せが発生することである。企業は、様々な市場の様々な(モバイル)オペレータを使用しており、可能な場合には、オペレータは、他のオペレータとの契約を利用してシームレスなグローバルコネクティビティを提供する。しかしながら、製品を異なる市場に販売する、または異なるオペレータネットワーク上で運用するフリートで使用する必要がある場合、新しいモバイルネットワークオペレータ(MNO)によって発行されたすべてのSIMカードについて、新しいコストのかかるロジスティクス管理およびライフサイクル管理の問題が生じる可能性がある。さらに、過去にデバイスの耐用期間中にモバイルオペレータを変更する必要があった場合、これは、履歴的には常に、SIMカードを変更していることを意味し、追加のロジスティクスおよびコストの問題が生じていた。
このますます厳しくなる市場のニーズにより、リモートでプログラムされた識別情報モジュール、例えば、組込みSIM(eSIM:embedded SIM)または組込みユニバーサル集積回路カード(eUICC:Embedded Universal Integrated Circuit Card)というソリューションが生まれた。eUICCは、小型の電子チップであり、製造時にデバイスの回路基板に挿入およびはんだ付けされる。eUICCのこの設定は、MFF2というフォームファクタとして知られており、MFF2では、SIMカードホルダーが不要であり、その結果、SIMに必要なスペースの量が削減される。
eUICCは、モバイルオペレータによって提供される初期のブートストラッププロファイルを用いて製造中にプログラムされ得る。初期のブートストラッププロファイルは、eUICCに運用プロファイルをリモートでプロビジョニングできるように初期のコネクティビティを提供し得る。これは、SIMに接続されている初期のネットワークオペレータを変更および再割り当てすることが可能であることを意味する。代替として、初期のコネクティビティは、動作プロファイルをリモートでプロビジョニングできる何らかの他の無線インターフェースを介して(例えば、コンピュータなどの別のデバイスを介して)実現され得る。この再プログラミングおよびプロビジョニングは、物理的な変更を必要とせずにオーバージエアで実行することができ、これは、企業に大きな利益をもたらす可能性がある。
eUICCの標準は、モバイルネットワークオペレータの国際協会である汎欧州デジタル移動電話方式協会(GSMA:Global System for Mobile Communications Association)によって、最初はマシンツーマシン(M2M)用途向けに、さらに最近ではスマートフォンおよびウェアラブル機器などの消費者用途向けに確立された。
相手先商標製品製造業者(OEM:Original Equipment Manufacturer)にとってこのeUICC技術の唯一最大の利点は、このeUICC技術がSIMを単一SKU(Stock Keeping Unit:在庫管理単位)に変換することである。言い換えると、製造中にeUICCを他の構成要素と同様にデバイスに挿入し、その後、デバイスを世界のどこに出荷するかによって、後で適切なネットワークオペレータプロファイルを用いてeUICCをプロビジョニングすることができる。この技術は、生産プロセスを合理化し、デバイスのライフサイクル全体のコストを削減するとともに、IoTデバイスでのセルラコネクティビティのより広範な使用を妨げる障害を軽減する。リモートでプロビジョニングされた識別情報モジュールを使用する単一SKUビジネスモデルにより、企業は、自社のグローバル製品に共通のeUICCを1つだけ使用して、コネクテッド製品のロジスティクス管理およびライフサイクル管理を簡素化することができる。
eUICCはまた、デバイスの耐用期間の間、任意の単一のオペレータによる「コネクティビティランサム」に拘束されることに対する保証ポリシーを提供する。eUICCプロセスのロジスティクスは単純であり、例えば、企業は、契約期間の終了時に必要に応じてオペレータを変更できる権利を含む初期契約をモバイルオペレータと締結する。その後、企業は、契約期間の終了時に、サービスおよび価格の観点から代替のコネクティビティの提案を柔軟に探し求めることができ、場合によってはオペレータを変更する保証オプションを利用することができる。
自動車市場は最も先進的なIoT市場の1つであり、自動車産業にとっての現在の要件は、すべてのコネクテッドカーにeUICCを搭載しなければならないことである。例えば、欧州では、eCall法の施行により、すべての新車にeUICCを採用することが義務化されている。しかしながら、例えば、ユーティリティ産業、スマート製造、エネルギー産業、輸送&ロジスティクスなど、グローバル産業全体においても、eUICCの利点が見られ、急速に採用されている。eUICCリモートSIMプロビジョニングは、IoTのユースケース、デバイスメーカー、サービスプロバイダ、およびモバイルネットワークオペレータにとってますます重要になっている。
狭帯域IoT(NB-IoT)は、モノのインターネット(IoT)の要件に対応する新しい3GPP無線技術標準である。この技術は、屋内カバレッジの向上、多数の低スループットデバイスのサポート、低遅延感度、超低デバイスコスト、低デバイス消費電力、および最適化されたネットワークアーキテクチャを提供する。NB-IoTは、低電力ワイドエリアコネクティビティ市場の急速な拡大に対応するために、3GPPによってリリース13で指定された、新しいセルラ無線アクセス技術(現在は公式の5G技術の一部)である。モバイル産業は現在、アプリケーションサービスプロバイダ、デバイスメーカーなどの顧客が自社のサービスを世界中に展開して運用できるようにするグローバルカバレッジソリューションとしてNB-IoTを確立している。
いくつかの実施形態によれば、プロキシサーバにおいて、NB-IoTデバイス内の識別情報モジュールにおけるプロファイルのリモート管理を可能にするための方法が提供され、プロキシサーバは、1つまたは複数のそれぞれのNB-IoTデバイスに関連付けられた1つまたは複数の外部識別子のデータベースへのアクセスを有するように設定され、1つまたは複数の外部識別子は、コアネットワーク内の公開機能を介してそれぞれの1つまたは複数のNB-IoTデバイスをアドレス指定するために使用される。方法は、トリガメッセージをNB-IoTデバイスに配信するよう求める要求を受信することであって、要求がデバイス識別子を含む、要求を受信することと、受信したデバイス識別子に基づいて外部識別子を決定することと、外部識別子を使用してトリガメッセージをNB-IoTデバイスに配信することとを含む。
いくつかの実施形態によれば、デバイスコネクティビティ管理(D/C)サーバにおいて、狭帯域モノのインターネット(NB-IoT)デバイス内の識別情報モジュールにおけるプロファイルのリモート管理を可能にするための方法が提供される。方法は、トリガメッセージをNB-IoTデバイスに配信するよう求める要求をプロキシサーバに送信することを含み、要求は、デバイス識別子およびトリガメッセージを含む。
いくつかの実施形態によれば、狭帯域モノのインターネット(NB-IoT)デバイスにおいて、NB-IoTデバイス内の識別情報モジュールにおけるプロファイルのリモート管理を可能にするための方法が提供される。方法は、プロキシサーバによって配信されたトリガメッセージを受信することを含む。
いくつかの実施形態によれば、NB-IoTデバイス内の識別情報モジュールにおけるプロファイルのリモート管理を可能にするためのプロキシサーバが提供され、プロキシサーバは、1つまたは複数のそれぞれのNB-IoTデバイスに関連付けられた1つまたは複数の外部識別子のデータベースへのアクセスを有するように設定され、1つまたは複数の外部識別子は、コアネットワーク内の公開機能を介してそれぞれの1つまたは複数のNB-IoTデバイスをアドレス指定するために使用される。プロキシサーバは、トリガメッセージをNB-IoTデバイスに配信するよう求める要求を受信することであって、要求がデバイス識別子を含む、要求を受信することと、受信したデバイス識別子に基づいて外部識別子を決定することと、外部識別子を使用してトリガメッセージをNB-IoTデバイスに配信することとを行うように設定された処理回路を備える。
いくつかの実施形態によれば、狭帯域モノのインターネット(NB-IoT)デバイス内の識別情報モジュールにおけるプロファイルのリモート管理を可能にするための、デバイスコネクティビティ(D/C)管理サーバが提供される。D/C管理サーバは、トリガメッセージをNB-IoTデバイスに配信するよう求める要求をプロキシサーバ(108)に送信するように設定された処理回路を備え、要求はデバイス識別子およびトリガメッセージを含む。
いくつかの実施形態によれば、狭帯域モノのインターネット(NB-IoT)デバイス内の識別情報モジュールにおけるプロファイルのリモート管理を可能にするためのNB-IoTデバイスが提供される。NB-IoTデバイスは、プロキシサーバによって配信されたトリガメッセージを受信するように設定された処理回路を備える。
次に、本開示の実施形態をよりよく理解し、その実施形態がどのように実行され得るかを示すために、添付の図面をほんの一例として参照する。
1つまたは複数の異なるタイプのNB-IoTデバイス内の識別情報モジュールにおいてプロファイルを管理するために使用され得る複数のノードを示す、ネットワーク100のブロック図である。
プロキシサーバにおいて、NB-IoTデバイス内の識別情報モジュールのためにプロファイルのリモート管理を可能にするための方法を示す図である。
狭帯域モノのインターネット(NB-IoT)デバイスにおいて、NB-IoTデバイス内の識別情報モジュールにおけるプロファイルのリモート管理を可能にするための方法を示す図である。
図1および図2の方法の例をより詳細に示すシグナリング図である。
図1および図2の方法の例をより詳細に示すシグナリング図である。
いくつかの実施形態によるプロファイルプロビジョニングプロセスの一例を示す図である。
いくつかの実施形態によるプロファイルプロビジョニングプロセスの一例を示す図である。
図5に示すシグナリング図の一例を示す図である。
図5に示すシグナリング図の一例を示す図である。
図5に示すシグナリング図の一例を示す図である。
図5に示すシグナリング図の一例を示す図である。
図5のプロファイルダウンロードおよびプロファイル有効化のフローの一例を示す図であり、フローは、GSMA RSPの適合された消費者版用に再描画されている。
図5のプロファイルダウンロードおよびプロファイル有効化のフローの一例を示す図であり、フローは、GSMA RSPの適合された消費者版用に再描画されている。
公開機能を介して、NIDDを使用してNB-IoTデバイスからアプリケーションサーバにCoAP要求を送信することを示す図である。
公開機能を介して、NIDDを使用してNB-IoTデバイスからアプリケーションサーバにCoAP要求を送信することを示す図である。
公開機能を介して、NIDDを使用してアプリケーションサーバ900からNB-IoTデバイス101にCoAP要求を送信することを示す図である。
公開機能を介して、NIDDを使用してアプリケーションサーバ900からNB-IoTデバイス101にCoAP要求を送信することを示す図である。
RDSが使用される場合、公開機能を介して、NIDDを使用してNB-IoTデバイスからアプリケーションサーバに要求メッセージを送信することを示す図である。
RDSが使用される場合、公開機能を介して、NIDDを使用してNB-IoTデバイスからアプリケーションサーバに要求メッセージを送信することを示す図である。
RDSが使用される場合、公開機能104を介して、NIDDを使用してアプリケーションサーバからNB-IoTデバイスに要求メッセージを送信することを示す図である。
RDSが使用される場合、公開機能104を介して、NIDDを使用してアプリケーションサーバからNB-IoTデバイスに要求メッセージを送信することを示す図である。
処理回路(または論理)を備えるプロキシサーバを示す図である。
処理回路(または論理)を備えるデバイスコネクティビティ(D/C)管理サーバを示す図である。
処理回路(または論理)を備える狭帯域モノのインターネット(NB-IoT)デバイスを示す図である。
全体として、本明細書で使用される用語はすべて、異なる意味が明確に与えられている、かつ/またはその用語が使用される文脈から暗示されない限り、関連する技術分野におけるその用語の通常の意味に従って解釈されるべきである。要素、装置、構成要素、手段、ステップなどについての言及はすべて、特に明記しない限り、要素、装置、構成要素、手段、ステップなどの少なくとも1つの事例について言及するものとして公然と解釈されるべきである。本明細書に開示する任意の方法のステップは、ステップが別のステップに後行もしくは先行するものとして明示的に記載されている、かつ/またはステップが別のステップに後行もしくは先行しなければならないことが暗黙的に示されている場合を除き、開示された通りの順序で実行される必要はない。本明細書に開示する実施形態の特徴はいずれも、必要に応じて任意の他の実施形態に適用され得る。同様に、実施形態の利点はいずれも、任意の他の実施形態に適用することができ、逆もまた同様である。添付した実施形態の他の目的、特徴、および利点は、以下の説明から明らかになろう。
限定ではなく説明を目的とした具体的な実施形態または例などの具体的な詳細を以下に示す。当業者には、これらの具体的な詳細とは別に他の例が採用され得ることが理解されよう。いくつかの事例では、不要な詳細によって説明が不明瞭にならいように、よく知られた方法、ノード、インターフェース、回路、およびデバイスの詳細な説明は省略されている。当業者は、記載された機能が、ハードウェア回路(例えば、特殊な機能を実行するために相互接続されたアナログおよび/もしくはディスクリート論理ゲート、ASIC、PLAなど)を使用して、かつ/または1つまたは複数のデジタルマイクロプロセッサもしくは汎用コンピュータと組み合わせたソフトウェアプログラムおよびデータを使用して、1つまたは複数のノードに実装され得ることを理解するであろう。エアインターフェースを使用して通信するノードは、適切な無線通信回路も有する。また必要に応じて、当技術はさらに、本明細書に記載の技法をプロセッサに実行させる適切なコンピュータ命令セットを含むソリッドステートメモリ、磁気ディスク、または光ディスクなどの任意の形式のコンピュータ可読メモリ内で完全に具現化されると見なされ得る。
ハードウェア実装は、限定されないが、デジタル信号プロセッサ(DSP)ハードウェアと、縮小命令セットプロセッサと、特定用途向け集積回路(ASIC:application specific integrated circuit)および/またはフィールドプログラマブルゲートアレイ(FPGA)を含むがこれらに限定されないハードウェア(例えば、デジタルもしくはアナログ)回路と、(必要に応じて)そのような機能を実行できるステートマシンとを含み得るか、または包含し得る。
eUICCなどの識別情報モジュールへのプロファイルのリモートプロビジョニングは、GSMA技術の成熟度に依存し得るが、これは利点でもあり制限でもある。リモートプロビジョニングアクションのトリガは、数十年前から存在しているショートメッセージサービス(SMS)およびハイパーテキスト転送プロトコル(HTTP)技術に基づいているが、常に信頼できるとは限らず、特にローミング中の場合、顧客は通常、リモートプロビジョニングをトリガして、新しいローカルMNOプロファイルをeUICC上でダウンロードおよび有効化する必要があり、トリガの配信能力が制限される。例えば、ローミングSMSの商用問題またはIoTコンテキスト内の技術的な問題に起因して、最初のSMSトリガが配信に失敗する場合である。
その結果として、eUICCが、新しいプロファイルのダウンロードを開始すること、および/またはあるプロファイルから別のプロファイルに切り替えることが可能になるには最初のSMSトリガを受信する必要があるため、eUICCリモートプロビジョニングが失敗する。SMSの技術的な制限に加えて、すべてのSMSに追加コストがかかり、現在は各eUICCリモートプロビジョニングフローに合計4つのSMSが必要であるので、SMSの使用には商業上の問題もある。したがって、SMSを使用する場合、現在のeUICCリモートプロビジョニングソリューションを多数のIoTデバイスに合わせてスケーリングすることが困難になる。
ほとんどのNB-IoTデバイスは、小さいデータパケットを送受信するようにのみ設定され得る。例えば、NB-IoTデバイスは、データパケットがインターネットプロトコル(IP)ベースのプロトコルを介して送信される場合に、IPプロトコルのオーバーヘッドが、交換される実際のデータをはるかに上回り得るほどに、小さいデータパケットを送信するように設定され得る。このようなNB-IoTデバイスは、非IPコントロールプレーンベースのデータ配信方法、すなわちNASベースの非IPデータ配信(NIDD:Non-IP Data Delivery)を使用してサーバとデータを交換するように設定され得る。
制約付きNB-IoTデバイスに対してSMSおよびHTTPがサポートされていない可能性があるため、既存のeUICCリモートプロビジョニング方法は大半のNB-IoTデバイスに適していない可能性があり、したがって、プロファイルのダウンロードおよびプロファイルの切り替えが正常に実行されない可能性がある。
しかしながら、世界のIoT市場では、所有するNB-IoTデバイスにeUICC技術を組み合わせて、低コストでグローバルな広域コネクティビティを実現しようと模索している大口顧客が多い。したがって、現在NB-IoTに対してSMS、HTTP、およびローミングがサポートされていなくてもNB-IoTネットワーク内で機能するとともにNB-IoTデバイスによって機能することができる、新しいeUICCリモートプロビジョニングソリューションが求められている。
したがって、本明細書に記載の実施形態は、プロキシサーバを利用して、NB-IoTデバイス内の識別情報モジュール(例えば、eUICC)へのプロファイルのリモート管理を可能にする。
本明細書に記載の実施形態は、GSMAリモートSIMプロビジョニング(RSP:remote SIM provisioning)標準に依存する制約付きNB-IoTデバイスのためのeUICCリモートプロビジョニングを可能にすることを提案する。このソリューションは、コアネットワーク内の公開機能(例えば、サービス能力公開機能(SCEF:Service Capability Exposure Function)またはネットワーク公開機能(NEF:Network Exposure Function))によって提供される非IPデータ配信(NIDD)サービスを使用して、プロファイル管理サーバとIoTデバイスとの間で、プロファイルダウンロードメッセージおよびプロファイル管理メッセージを配信する。NIDDサービスを使用すると、デバイスでのプロファイル管理動作をトリガすることが効果的に可能になり、制約付きIoTデバイスによって送受信されるビット数を低減することもできる。
プロファイル管理サーバとNB-IoTネットワークの公開機能の間でプロキシサーバを使用して、プロファイル管理サーバでの3GPP固有のネットワーク関連機能の知識を省くとともに、IoTデバイスが複数のアプリケーションサーバと同時に通信できるようにすることができる。デバイス/コネクティビティ(D/C)管理サーバは、ビジネスプロセスを制御し、企業顧客とモバイルネットワークオペレータとの両方と対話し、エンドツーエンド通信フロー/設定を可能にし、eUICCリモートプロビジョニング手順を開始および管理し得る。
本明細書に記載の実施形態は、NB-IoTデバイスが、ローカルモバイルネットワークオペレータから新しいプロファイルをダウンロードして有効化するために、eUICCで(グローバルモバイルネットワークオペレータからの)事前にプロビジョニングされたプロファイルを使用する訪問ネットワークを介してプロファイル管理サーバに接続できるようなNB-IoTに対してサポートされているローミングに依存し得る。現在、オペレータによって、NB-IoTローミングのビジネスセットアップについての合意を試みる取り組みが進行中であり、ここではそのようなセットアップが合意されているものと仮定する。
本明細書に記載の実施形態は、配信技術およびデバイスタイプの様々なセットアップに対処し、ソリューションの詳細は本質的に異なるが共通の手法を共有している様々な例について検討する。セットアップにおける違いにより、目標を達成するためにソリューションが非自明な方法で作成される場合がある。一実施形態では、GSMA RSP M2M版によるリモートプロビジョニングが使用される。この場合、NB-IoTネットワークの公開機能NIDDサービスを使用して、現在はプロファイル管理サーバとIoTデバイスのeUICCとの間でSMSとして送信される、プロファイルダウンロードメッセージおよびプロファイル管理メッセージを配信することができる。NIDDソリューションは、制約付きIoTデバイスとプロファイル管理サーバとの間で他の(SMS以外の)プロファイルダウンロードおよびプロファイル管理関連のメッセージを転送する場合にも使用することができ、これにより、制約付きIoTデバイスによって送受信されるビット数が削減される。NIDDサービスを制約付きアプリケーションプロトコル(CoAP:Constrained Application Protocol)または高信頼データサービス(RDS:Reliable Data Service)プロトコルと組み合わせて使用すると、デバイスがHTTP/TCP/IPスタックをサポートしていない場合でも、デバイスとプロファイル管理サーバとの間でプロキシサーバを介してHTTPSメッセージを信頼できる方法で交換することができる。
いくつかの実施形態において、GSMA RSP消費者版によるリモートプロビジョニングが使用される。ここでは、D/C管理サーバは、NB-IoTデバイス内のローカルプロファイルアシスタント(LPAd)を介して、プロファイルダウンロードおよびプロファイル管理動作をリモートで制御し得る。この場合、公開機能NIDDサービスを使用して、LPAdでのプロファイルダウンロードおよびプロファイル管理動作のトリガ、ならびにNB-IoTデバイスとプロファイル管理サーバおよびD/C管理サーバとの間でのプロファイルダウンロードおよびプロファイル管理に関連するメッセージの転送を行うことができ、これにより、NB-IoTデバイスによって送受信されるビット数が削減される。いくつかの例では、IoTに適合したGSMA RSP消費者版によるリモートプロビジョニングが検討され、公開機能NIDDサービスは、同様の方法でソリューションを提供する。
本明細書に記載の実施形態は、デバイスがGSMAリモートSIMプロビジョニング標準をサポートする統合UICC(iUICC:integrated UICC)を備えた統合SIM(iSIM)ソリューションにも適用される。本明細書に記載の実施形態は、GSMAリモートSIMプロビジョニング標準をサポートする(取り外し可能な)UICCまたはETSIスマートセキュアプラットフォーム(SSP)にも適用され得る。
本明細書に記載の実施形態は、既存のGSMA RSP標準、具体的にはM2M版を、GSMA RSP準拠のSM-SRで必要とされる最小限の変更のみで、標準M2M準拠のeUICCを備えたNB-IoTデバイスにも使用できるようにする。SMSがNB-IoTネットワークによってサポートされていないという問題は、公開機能NIDDサービスを使用したデバイスとの通信によって回避される。公開機能およびプロキシサーバを使用すると、制約付きIoTデバイスがHTTP/TCP/IPスタックをサポートしていない場合の問題も解決される。NIDD技術を使用すると、送信されるビット数を最小限に抑えることができ、したがって、制約付きデバイスの消費電力も削減することができる。
図1は、1つまたは複数の異なるタイプのNB-IoTデバイス内の識別情報モジュールにおいてプロファイルを管理するために使用され得る複数のノードを示す、ネットワーク100のブロック図である。
NB-IoTデバイスは、セルラNB-IoTモデムおよび識別情報モジュール(例えば、eUICC)を備えると見なされ得る。識別情報モジュールは、GSMAによるリモートSIMプロビジョニングをサポートするように設定され得、リモートでのプロファイルダウンロードおよびプロファイル管理のための資格情報を備え得る。
NB-IoTネットワークは、NB-IoTデバイスが、ローカルモバイルネットワークオペレータから新しいプロファイルをダウンロードして有効化するために、eUICCで(グローバルモバイルネットワークオペレータからの)事前にプロビジョニングされたプロファイルを使用して訪問ネットワークを介して接続できるように、ローミングをサポートし得る。
具体的には、図1は、第1のNB-IoTデバイス101aを示す。NB-IoTデバイス101aは、第1のタイプのNB-IoTデバイスを含む。第1のタイプのNB-IoTデバイスは、アプリケーションサーバとの通信のために公開機能104(例えば、4Gの場合はSCEF、または5Gの場合はNEF)を介して3GPP非IPデータ配信(NIDD)メカニズムを使用するデバイスを含む。この第1のタイプのNB-IoTデバイスは、非IPデバイス(例えば、伝送制御プロトコル/インターネットプロトコル(TCP/IP:Transmission Control Protocol/Internet Protocol)もしくはユーザデータグラムプロトコル/IP UDP/IPプロトコルスタックをサポートしないデバイス)、またはIPベースのデバイス(例えば、TCP/IPもしくはUDP/IPプロトコルスタックのいずれかをサポートしているが、例えば、送信されるビット数を最小限に抑える(したがって、デバイスの電力消費を削減し得る)ためであるかどうかに関わらず、NIDDを使用しているデバイス)のいずれかを含み得る。
ネットワーク100は、第2のNB-IoTデバイス101bをさらに含む。NB-IoTデバイス101bは、第2のタイプのNB-IoTデバイスを含む。第2のタイプのNB-IoTデバイスは、アプリケーションサーバとの通信のためにパケットゲートウェイ(P-GW)102を介して3GPP非IPデータ配信(NIDD)メカニズムを使用するデバイスを含む。この第2のタイプのNB-IoTデバイスは、非IPデバイス(例えば、伝送制御プロトコル/インターネットプロトコル(TCP/IP)もしくはユーザデータグラムプロトコル/IP UDP/IPプロトコルスタックをサポートしないデバイス)、またはIPベースのデバイス(例えば、TCP/IPもしくはUDP/IPプロトコルスタックのいずれかをサポートしているが、例えば、送信されるビット数を最小限に抑える(したがって、デバイスの電力消費を削減し得る)ためであるかどうかに関わらず、NIDDを使用しているデバイス)のいずれかを含み得る。
ネットワーク100は、第3のNB-IoTデバイス101cをさらに含む。第3のNB-IoTデバイス101cは、第3のタイプのNB-IoTデバイスを含む。第3のタイプのNB-IoTデバイスは、NB-IoT IPベースのサービスを使用してアプリケーションサーバと通信するように設定されたIPベースのデバイスを含む。IPベースのトラフィックは、例えば、コントロールプレーンシグナリングを介して、例えば、モビリティ管理エンティティ(MME:mobility management entity)に、さらにサービングゲートウェイ(S-GW)103に送信されるか、または専用のユーザプレーンベアラを介して直接S-GWに、その後さらにP-GW102に送信され得る。
ネットワーク100は、公開機能104をさらに含む。この例では、公開機能104は、アプリケーションサーバによって使用するためのRESTful APIを使用して3GPPセルラネットワークのサービスおよび能力を公開するように設定され得るサービス能力公開機能(SCEF)を含む。しかしながら、公開機能104が、同様に5Gコアネットワークアーキテクチャによるネットワーク公開機能(NEF:Network Exposure Function)も含み得ることが理解されよう。公開機能104によって公開されるサービスは、非IPデータ配信(NIDD)サービスおよび監視サービスを含み得る。アプリケーションサーバは、例えば、上記の第1のタイプのNB-IoTデバイスと通信するためにNIDDサービスを利用し得る。
例えば、アプリケーションサーバは、NIDDサービスを使用して第1のNB-IoTデバイス101aと通信し得る。NIDDを使用するとき、第1のNB-IoT 101aデバイスは、(IPを使用せずに)メッセージを送受信することができ、これらのメッセージは、非アクセス階層(NAS)シグナリングプロトコルでシグナリングデータとして伝達される。NASシグナリングは、第1のNB-IoTデバイス101aとモビリティ管理エンティティ(MME)105との間で行われ得る。次いで、メッセージは、MME105から公開機能104に中継され得る。公開機能104のサービスを使用するために、アプリケーションサーバは、最初に公開機能104に登録するよう要求され得、使用したいサービスおよび対象となるデバイスを示し得る。各NB-IoTデバイスには、外部識別子またはMSISDNが割り当てられ、これらは、IMSIなどの他の加入詳細とともにホーム加入者サービス(HSS:Home Subscriber Service)106に登録され得る。今後数年間でMTCデバイスの数が増加すると、電話番号(すなわち、MSISDN)が不足することになる。3GPPソリューションは、新しい識別子を加入データの一部として規定し、MSISDNが割り当てられていない動作を、代わりに新しい識別子を使用することによって可能にする。この新しい識別子の名称は「外部識別子」である。しかしながら、簡単にするために、本明細書では、「外部識別子」という用語は、MSISDNを包含すると理解されるべきである。次いで、外部識別子をアプリケーションサーバが使用して、ターゲットとするデバイスにインデックス付けすることができる。外部識別子の他の例には、車両登録/VIN番号、スマートメータのシリアル番号、QRコードなどが含まれる。
セルラネットワークは、P-GW102を介したポイントツーポイントトンネルを使用したNIDDトランスポートモードも提供する。例えば、第2のNB-IoTデバイス101bは、(IPを使用せずに)メッセージを送受信するように設定され得、これらのメッセージは、デバイスとMME105との間のNASシグナリングプロトコルでシグナリングデータとして伝達される。次いで、メッセージはさらに、MME105からS-GW103に、さらにP-GW102へ中継され得る。P-GW102は、透過的な転送ノードとして作用し得る。NB-IoTデバイスごとに、P-GWは、NB-IoTデバイスによって使用されるPDN接続のAPNに基づいて、パケットの転送先および転送元となるアプリケーションサーバに関する知識を有し得る。P-GW102は、NB-IoTデバイスから受信したパケットをアプリケーションサーバに転送する前に、そのパケットにUDP/IPヘッダを追加し得、アプリケーションサーバから受信したパケットをNB-IoTデバイスに転送する前に、そのパケットからUDP/IPヘッダを除去し得る。P-GW102はまた、アプリケーションサーバとの通信で使用するために、各NB-IoTデバイスにIPアドレスおよびポートを割り当て得る。
ネットワーク100は、プロファイル管理サーバ107をさらに含む。プロファイル管理サーバは、プロファイルプロビジョニングおよびプロファイル管理動作(プロファイルの有効化、無効化、削除など)のために使用され得る。プロファイル管理サーバのタスクは、プロファイルのダウンロードをハンドリングするプロビジョニングサーバおよびプロファイル管理動作をハンドリングする管理サーバなどの別々のサーバによって実行される異なるタスクに分割され得るが、簡単にするために、単一のプロファイル管理サーバ107が示されている。
NIDDを使用してNB-IoTデバイスと通信する例では、プロファイル管理サーバ107は、公開機能104またはP-GW102に登録/設定され得、したがって、NIDDを使用してこれらのノードを介してNB-IoTデバイスと通信し得る。しかしながら、これらのNB-IoTデバイスは、プロファイル管理サーバ107との通信と並行して、他の(アプリケーション)サーバと通信する必要があり得る。この並列通信を可能にするために、プロキシサーバ108が間で使用される。プロキシサーバ108は、公開機能104またはP-GW102に登録/設定され得るか、またはNB-IoTデバイスとの間のトラフィックがプロキシサーバ108に送信され得、次いで、プロキシサーバ108は、異なるNB-IoTデバイスによって生成されたメッセージを、必要に応じて別のアプリケーションサーバに転送し得る。
通常、デバイスで生成されたメッセージを正しいアプリケーションサーバへ方向付けるために、プロキシサーバによって、送信先のIPアドレスおよびポートが使用される。しかしながら、ここでは(IPエンドツーエンドなしで)、プロキシサーバがNB-IoTデバイスの1つのアプリケーションからのトラフィックを適切なアプリケーションサーバに接続できるように調整するかどうかは、プロキシサーバ、およびNB-IoTデバイスのアプリケーション次第であり得る。プロキシサービスに加えて、プロキシサーバは、監視および通知サービスなど(SCEFサービスおよび他のコアネットワークサービスに基づく)他のサービスを、プロファイル管理サーバを含むアプリケーションサーバに提供し得る。したがって、NB-IoTデバイス101aから101cのいずれかにおける識別情報モジュールのためのプロファイルのリモート管理は、プロキシサーバ108を介して管理され得る。
IoTデバイス(またはNB-IoTデバイス)を所有する企業は、モバイルネットワークオペレータ(MNO)で自社のIoTデバイスのための新しいセルラ加入(プロファイルと呼ばれ得る)を申し込むことができる。プロファイルは、プロファイル管理サーバ107において準備され、ダウンロードに使用できるようにされ得る。企業は、準備されたプロファイルを識別するプロファイル識別子のセットをMNOから受信し得る。プロファイル識別子の例は、集積回路カード識別子(ICCID:Integrated Circuit Card Identifier)、国際移動体加入者識別情報(IMSI:International Mobile Subscriber Identity)、アクティベーションコード(AC)、およびマッチングIDである。次いで、企業は、デバイスコネクティビティ(D/C)管理サーバ109を利用して、企業が所有するIoTデバイスのうちの1つの識別情報モジュールでプロファイルダウンロードをトリガし、かつ/またはすでにダウンロードされたプロファイルでのプロファイル管理動作をトリガし得る。D/C管理サーバ109は、デバイス管理サーバを含み得るが、コネクティビティ管理をハンドリングするサーバでもあり得る。
図2は、プロキシサーバにおいて、NB-IoTデバイス内の識別情報モジュールのためにプロファイルのリモート管理を可能にするための方法を示す。例えば、図2の方法は、図1に示すプロキシサーバ108によって実行され得る。プロキシサーバは、1つまたは複数のそれぞれのNB-IoTデバイスに関連付けられた1つまたは複数の外部識別子のデータベースにアクセスするように設定される。例えば、プロキシサーバ108は、NB-IoTデバイス101aから101cの各々の外部識別子に関連する情報を含むデータベースにアクセスすることが可能であり得る。1つまたは複数の外部識別子は、コアネットワーク内の公開機能を介してそれぞれの1つまたは複数のNB-IoTデバイスをアドレス指定するために使用される。上記のように、公開機能は、SCEFまたはNEFを含み得る。プロファイルの管理は、例えば、識別情報モジュールへの新しいプロファイルのプロビジョニング、プロファイルの有効化もしくは無効化、またはプロファイルの削除を含み得る。
外部識別子は、加入識別子を含み得る。例えば、外部識別子は、モバイルステーション国際加入者電話番号(MSISDN:Mobile Station International Subscriber Directory Number)を含み得る。
ステップ201において、プロキシサーバは、トリガメッセージをNB-IoTデバイスに配信するよう求める要求を受信し、要求は、デバイス識別子を含む。トリガメッセージは、プロファイルダウンロードトリガメッセージを含み得る。プロファイルダウンロードトリガメッセージは、プロファイル管理サーバからプロファイルをダウンロードするようNB-IoTデバイスをトリガすることを目的とし得る。トリガメッセージは、プロファイル管理トリガメッセージを含み得る。プロファイル管理トリガメッセージは、プロファイル管理動作を実行するようNB-IoTデバイス内の識別情報モジュールをトリガするように設定され得る。例えば、プロファイル管理動作は、識別情報モジュール内の既存のプロファイルを更新、有効化、無効化、または削除することであり得る。
ステップ202において、プロキシサーバは、受信したデバイス識別子に基づいて外部識別子を決定する。
ステップ203において、プロキシサーバは、外部識別子を使用して、トリガメッセージをNB-IoTデバイスに配信する。
図3は、狭帯域モノのインターネット(NB-IoT)デバイスにおいて、NB-IoTデバイス内の識別情報モジュールにおけるプロファイルのリモート管理を可能にするための方法を示す。プロファイルの管理は、NB-IoTデバイス内の識別情報モジュールにおける、新しいプロファイルのリモートプロビジョニングまたは既存のプロファイルの管理を含み得る。
ステップ301において、NB-IoTデバイスは、プロキシサーバによって配信されたトリガメッセージを受信する。例えば、NB-IoTデバイスは、図2によるプロキシサーバによって配信されたようなトリガメッセージを受信し得る。
図4は、図1および図2の方法の例をより詳細に示すシグナリング図である。具体的には、図4は、トリガメッセージがプロキシサーバ(例えば、図1のプロキシサーバ108)から配信され得る方法の例を示す。
401に示すように、プロキシサーバ108は、1つまたは複数のそれぞれのNB-IoTデバイスに関連付けられた1つまたは複数の外部識別子のデータベースにアクセスするように設定される。プロキシサーバはまた、公開機能104のためにユニフォームリソースロケータを有するように設定され得る。
ステップ402aに示す一例では、プロキシサーバ108は、1組のNB-IoTデバイスと通信するNIDDサービスのために、公開機能104に登録される。この例では、(図2のステップ201に対応する)ステップ403において、プロキシサーバ108は、トリガメッセージをNB-IoTデバイスに配信するよう求める要求を受信し、(図2のステップ202に対応する)ステップ404において、プロキシサーバは、受信したデバイス識別子に基づいて外部識別子を決定し、その後、方法はステップ405に進む。
ステップ405は、図2のステップ203が実行され得る方法の例を示す。ステップ405において、公開機能104によって提供されるNIDDサービスを使用して、トリガメッセージを配信する。プロキシサーバ108は、公開機能104に登録され得、NIDDサービスのデータ送信コマンドを使用して、トリガメッセージをNB-IoTデバイス101に送信し得る。公開機能104は、トリガメッセージをバッファリングし得、NB-IoTデバイス101が電源投入されてネットワークに登録されるとき、トリガメッセージをNB-IoTデバイス101に送信し得る。公開機能104のNIDDサービスを使用することは、公開機能のNIDDサービスがデバイスとアプリケーションサーバとの間のデータ転送に使用される第1のタイプのNB-IoTデバイスにとって自然なことであり得る。しかしながら、この実施形態は、他の場合NB-IoTデバイスとアプリケーションサーバとの間のデータ転送に公開機能のNIDDサービスを使用できないタイプ2およびタイプ3のデバイスにも使用できることが理解されよう。
別の例では、ステップ401に続いて、方法はステップ402bに進む。ステップ402bにおいて、プロキシサーバ108は、1組のNB-IoTデバイスの監視サービスのために、公開機能104に登録される。監視サービスは、1組のNB-IoTデバイスのうちの1つがいつネットワークに登録するかをプロキシサーバ108に示し得る。この例では、ステップ404に続いて、方法はステップ406に進む。具体的には、この例におけるステップ406から409は、図2のステップ203が実行され得る方法を示す。ステップ406において、プロキシサーバ108は、1組のNB-IoTデバイスのうちの1つがネットワークに登録したことを示す通知を公開機能104から受信する。ステップ406は、ステップ403およびステップ404の前に行われ得ることが理解されよう。
ステップ407において、プロキシサーバは、公開機能104、P-GW102、またはネットワーク内の第3のノードのいずれかを使用して、外部識別子またはMS
ISDNに基づいて、NB-IoTデバイスの現在のIPアドレス(場合によってはポート)を取得する。したがって、プロキシサーバ108は、このサービスを使用して、公開機能104監視サービスと組み合わせて現在のIPアドレスを取得する。言い換えれば、ステップ407は、アドレス要求を第3のネットワークノードに送信することを含み得、アドレス要求は、外部識別子を含む。
ステップ408において、プロキシサーバ108は、NB-IoTデバイス101の現在のIPアドレスを受信し得、ステップ409において、受信したIPアドレスを使用してトリガメッセージをNB-IoTデバイスに送信する。言い換えれば、プロキシサーバ108は、アドレス要求を送信したことに応答して、NB-IoTデバイスのIPアドレスを受信する。
具体的には、ステップ409は、IPアドレスを利用してトリガメッセージを送信することを含む。例えば、プロキシサーバは、(例えば、タイプ2のデバイスの場合)P-GW102を介してしてNIDDを利用してトリガメッセージを送信し得る。いくつかの例において、ステップ409は、(例えば、タイプ3のデバイスの場合)デバイスのIPアドレスを使用して、UDP/IPまたはTCP/IPを介してトリガメッセージをNB-IoTデバイスに送信することを含む。したがって、トリガメッセージは、P-GW102およびS-GW103を介して、NB-IoTデバイス101にルーティングされ得る。
プロキシサーバ108の(上記の図4に示す)トリガメッセージ配信サービスは、様々な方法で実装され得る。選択肢の1つは、プロキシサーバ108が、制約付きアプリケーションプロトコル(CoAP)またはハイパーテキスト転送プロトコル(HTTP)サーバとして作用し、NB-IoTデバイスに送られるべきトリガメッセージをプロキシサーバ108に送信することによって、トリガメッセージ配信サービスを、アプリケーションサーバが使用するリソースとして提供することである。プロキシサービスにおけるこのサービスに対する各CoAP/HTTP要求には、トリガメッセージおよびデバイス識別子が含まれ得る。次いで、プロキシサーバ108は、外部識別子がデバイス識別子としてまだ使用されていない場合、データベース検索を利用して、受信したデバイス識別子を外部識別子に変換し得る。プロキシサーバ108のトリガメッセージ配信サービスは、プロキシサーバ108に事前登録されているか、またはトリガメッセージ配信サービス使用するためにオンライン認証サーバ(例えば、OAuth2サーバもしくはACE認証サーバ)からアクセストークンを取得したアプリケーションサーバに限定され得る。
図5は、いくつかの実施形態によるプロファイルプロビジョニングプロセスの一例を示す。
NB-IoTデバイス101(例えば、eUICC)の識別情報モジュールは、NB-IoTデバイス101がセルラネットワークに接続することを可能にするアクティブなセルラ加入(すなわち、有効化されたプロファイル)を有するように設定され得る。これは、動作プロファイルの提供を可能にする目的で製造時にインストールされたプロファイルであり得るか、または以前にNB-IoTデバイス101によってダウンロードされた動作プロファイルであり得る。
HSS106は、NB-IoTデバイス101の加入者資格情報を有するように設定され得る。加入者資格情報は、公開機能104(例えば、SCEF)を介してデバイスをアドレス指定するために使用される外部識別子を含み得る。プロキシサーバ108は、NB-IoTデバイス101をアドレス指定することが可能な外部識別子を有するように設定され得る。プロファイル管理サーバ107は、ダウンロード可能であり得るプロファイルパッケージのセットを含み得る。プロファイルパッケージに対する対応するプロファイル識別子は、NB-IoTデバイスを所有する企業に提供され得、D/C管理サーバ109に提供され得る。所与のプロファイルパッケージについて、プロファイルに対応するモバイルネットワークのHSS106は、プロファイルパッケージの加入者資格情報に対応する加入者資格情報、およびNB-IoT101の外部識別子を有するように設定される。
簡単にするために、ここでは両方のモバイルネットワーク内で同じ外部識別子またはMSISDNが使用されていると仮定する。それ以外の場合、2つの間で変換を実行する必要がある(例えば、変換が発生するプロキシサーバに新しい外部識別子が設定される)。
ステップ501において、D/C管理サーバ109は、プロファイルのダウンロードをトリガするためのコマンドをプロファイル管理サーバ107に送信する。ステップ501において、D/C管理サーバ109は、少なくとも、プロファイルがダウンロードされるNB-IoTデバイス101のデバイス識別子、ダウンロードされるプロファイルに対応するプロファイル識別子、およびプロキシサーバ108のURLを提供し得る。デバイス識別子は、プロファイル管理サーバによって、プロファイルダウンロードがトリガされるべきデバイスを識別するために使用され、プロファイル識別子は、ダウンロードされるプロファイルを識別する。デバイス識別子の例は、IMEI、外部識別子、MSISDN、モデムモジュール識別子、およびeUICC ID(EID)である。
ステップ502において、プロファイル管理サーバ107は、トリガメッセージをNB-IoTデバイス101に配信するよう求める要求をプロキシサーバ108に送信し、要求は、デバイス識別子を含む(ステップ502は、図2のステップ201に対応し得る)。このトリガメッセージは、プロファイル管理サーバ107のURLを含み得る。プロファイル管理サーバ107はまた、トリガメッセージが適用されるNB-IoTデバイス101のデバイス識別子を示し得る。いくつかの例において、NB-IoTデバイス101は、プロファイル管理サーバ107のURLを有するように事前設定され得、NB-IoTデバイス101の最初の起動時にステップ504を実行するように設定され得る。
ステップ503において、プロキシサーバ108は、ステップ502で受信したデバイス識別子によって識別されるNB-IoTデバイスにトリガメッセージを配信する。具体的には、プロキシサーバは、ステップ502で受信したデバイス識別子に基づいて外部識別子を決定し得る。デバイス識別子が外部識別子と異なる場合、プロキシサーバは、提供されたデバイス識別子を使用してデータベース内の外部識別子を検索する。次いで、ステップ503は、図4に示すように実施され得る。いくつかの例において、ステップ503は任意選択であり、NB-IoTデバイス101がプロファイル管理サーバ107のURLを有するように事前設定され、デバイスの最初の起動時にステップ504を実行するように設定されている場合、実行されない。
ステップ504において、NB-IoTデバイス101は、NB-IoTデバイス101の識別情報モジュールとプロファイル管理サーバ107との間のセキュア通信を確立し得る。
ステップ505において、NB-IoTデバイス101およびプロファイル管理サーバ107は、例えば、相互認証を含むセキュア通信を確立するためにメッセージを交換する。
ステップ506において、NB-IoTデバイス101は、プロファイル管理サーバ107からプロファイルパッケージをダウンロードする。プロファイル管理サーバ107は、ステップ501で受信したデバイス識別子およびプロファイル識別子に基づいて、どのプロファイルパッケージをNB-IoTデバイス101にダウンロードするかを認識する。次いで、NB-IoTによって、プロファイルパッケージが識別情報モジュールにインストールされ得る。例えば、ステップ506は、プロファイル管理サーバからプロファイルを受信することと、プロファイルを識別情報モジュールにインストールすることとを含み得る。
ステップ507において、プロファイル管理サーバ107は、任意選択として、トリガメッセージの結果について報告する応答をD/C管理サーバ109に提供し得る。例えば、プロファイル管理サーバ107は、プロファイルがNB-IoT101に正常にダウンロードされたか否かをD/C管理サーバ109に示し得る。
いくつかの例において、プロファイルは、新しいモバイルネットワークのプロファイルであり得る。これらの例では、D/C管理サーバ109は、ステップ508において、NB-IoTデバイス101について新しいモバイルネットワークに切り替えるよう求める要求をプロキシサーバ108に送信し得る。例えば、新しいモバイルネットワークに切り替えるよう求める要求は、プロキシサーバが、新しいモバイルネットワークに属するP-GWなどを公開機能に登録することを求める要求を含み得る。P-GWの場合、プロキシサーバはプロファイルの申込み/準備フェーズからNIDDで使用するように事前設定されている可能性があり、その場合このステップは省略され得ることに留意されたい。
ステップ508が実行される場合、プロキシサーバは、ステップ509において、新しいモバイルネットワークに登録し得る。例えば、プロキシサーバ108は、NB-IoTデバイス101から送信された任意のデータが新しいモバイルネットワークを介してアプリケーションサーバにルーティングされ得るように、新しいモバイルネットワークに登録し得る。登録が行われると、プロキシサーバ108は、古いモバイルネットワークを介してNB-IoTデバイスにデータを送信するように設定されたまま、プロファイルが有効化されて切り替えが完了した状態が確立されるまで、両方のモバイルネットワークを介してNB-IoTデバイスからデータを受信することが可能になり得、すなわち、プロキシサーバは、新しいモバイルネットワークを介してNB-IoTデバイスにデータを送信するように設定される。
いくつかの例において、プロファイルは、NB-IoTへのプロファイルのダウンロードとは別に有効化され得る。これらの例では、ステップ506において、プロファイルがダウンロードされ得、ステップ510において、D/C管理サーバ109が、プロファイルの有効化をトリガするよう求める要求をプロファイル管理サーバ107に送信し得る。プロファイルの有効化をトリガするよう求める要求は、デバイス識別子、プロファイル識別子、およびプロキシサーバ108のURLを含み得る。このステップは任意選択であり、プロファイルの有効化は、D/C管理サーバがプロファイルダウンロードのためにプロファイル管理サーバをトリガするステップ501の一部であり得る。
ステップ510においてプロファイルの有効化をトリガするよう求める要求を受信したことに応答して、プロファイル管理サーバ107は、ステップ511において、ダウンロードされたプロファイルの有効化をトリガする情報を含むメッセージをプロキシサーバ108に送信し得る。このメッセージは、プロファイル管理サーバ107のURLを含み得る。プロファイル管理サーバ107はまた、メッセージが適用されるNB-IoTデバイス101のデバイス識別子を示し得る。このステップは、NB-IoTデバイス101が依然としてアクティブである間にプロファイルダウンロードの直後にプロファイルの有効化が行われる場合は任意選択であり得、その場合、ステップ515が直ちに実行され得る。
ステップ512において、プロキシサーバ108は、ステップ511で受信したデバイス識別子によって識別されるNB-IoTデバイス101に、ダウンロードされたプロファイルの有効化をトリガするためのメッセージを配信する。上記のように、このステップでは、トリガメッセージは、図4で説明されているようにNB-IoTデバイスに配信され得る。ステップ512は任意選択であり、ステップ511が実行されない場合、実行されない可能性がある。また、以下に説明するステップ515のプロファイル有効化要求メッセージが、プロファイルの有効化をトリガするよう求める要求の一部として含まれ、すでに確立されたセキュリティアソシエーションを使用してプロファイル管理サーバ107からNB-IoTデバイス101にエンドツーエンドで保護される場合もあり、この場合、プロファイル管理サーバ間のセキュア通信のさらなる確立(例えば、ステップ514)は必要とされない場合がある。
ステップ514において、NB-IoTデバイス101は、NB-IoTデバイス101の識別情報モジュールとプロファイル管理サーバ107との間のセキュア通信を確立し得る。このステップは任意選択であり、プロキシサーバ108からプロファイルの有効化をトリガするよう求める要求がない場合(例えば、ステップ512がない場合)、実行されない可能性がある。また、ステップ515のプロファイル有効化要求メッセージが、プロファイルの有効化をトリガするよう求める要求の一部として含まれ、プロファイル管理サーバからエンドツーエンドで保護されている場合、ステップ514は実行されない可能性がある。次いで、NB-IoTデバイスおよびプロファイル管理サーバ107は、メッセージを交換して、相互認証を含むセキュア通信を確立し得る。
ステップ515において、プロファイル管理サーバ107は、プロファイルを有効化するよう求める要求メッセージをデバイスに送信する。上記のように、このような小さいメッセージの場合、またプロファイルの有効化をトリガするよう求める要求が以前に送信されている場合、要求メッセージは、プロファイルの有効化をトリガするよう求める要求の一部として含まれる場合があり、その場合、ステップ513~515は実行されないことに留意されたい。NB-IoTデバイス101内の識別情報モジュールは、要求メッセージを処理し、プロファイルを有効化し得る。NB-IoTデバイス101からプロファイル管理サーバ107に返送される応答メッセージが準備され得る。ステップ514でセキュア通信が確立されていない場合、応答メッセージは、すでに確立されたセキュリティアソシエーションを使用して保護され得る。
ステップ516において、プロファイル管理サーバ107は、任意選択として、動作の結果について報告する応答をD/C管理サーバ109に提供する。例えば、プロファイル管理サーバ107は、プロファイルが有効化されたか否かを報告し得る。
プロファイルの有効化が成功し、プロファイルが新しいモバイルネットワークオペレータにあることに応答して、D/C管理サーバ109は、ステップ517において、新しいモバイルネットワークオペレータからのサービスを使用するように切り替えるようにプロキシサーバ108に命令し得る。例えば、プロキシサーバ108は、プロファイルが変更された特定のNB-IoTデバイスの新しいモバイルネットワークで公開機能(例えば、SCEF)および/またはP-GWを使用するように切り替えるように命令され得る。新しいモバイルネットワークへの登録は、以前に(例えば、ステップ509において)行われている可能性がある。NB-IoTデバイスのデバイス識別子は、使用される様々なMNOサービス(SCEF、P-GWなど)へのURLとともに提供され得る。
ステップ518において、プロキシサーバ108は、プロキシサーバ108の設定を、アプリケーションサーバからNB-IoTデバイス101へのデータが今度は新しいモバイルネットワークを介して転送されるように変更し得る。プロキシサーバ108はまた、古いモバイルネットワークサービスから登録解除し得る。
フローの後半部分、例えばステップ508~518は、プロファイルの有効化、プロファイルの無効化、およびプロファイルの削除などの任意のスタンドアロンのプロファイル管理動作に適用され得る。ステップ508、509、517、および518は、プロファイルが有効化されている場合にのみ関連する可能性があり、これは、あるMNOから別のMNOへの切り替えも意味する。
制約付きアプリケーションプロトコル(CoAP)は、アプリケーション関連のメッセージを転送するために制約付きIoTデバイスで使用するためのプロトコルである。いくつかの実施形態において、CoAPは、プロファイルダウンロードおよびプロファイル管理関連のメッセージを転送するために、NB-IoTデバイス101とプロファイル管理サーバ107との間で使用される。
いくつかの実施形態において、プロファイル管理(新しいプロファイルの管理およびプロビジョニングを含む)は、GSMA RSP M2M版による。この例では、プロファイル管理サーバ107は、SM-SRおよびSM-DPと呼ばれる2つのサーバによって表され得る。SM-SRおよびSM-DPは、企業が新しい加入プロファイルを申し込んだMNOによって運用され得るか、または、SM-SRおよびSM-DPは、サードパーティによって運用され得、MNOに提供されるサービスの一部であり得る。SM-SRおよびSM-DPは、同じ場所に配置されて同一のエンティティによって管理され得るか、または離れた場所にあり、異なる当事者によって運営され得る。SM-SRおよびSM-DPが、MNOが使用するサードパーティのサービスである場合、D/C管理サーバ109をSM-DPおよびSM-SRとリンクするプロファイル管理動作用の顧客向けのインターフェースを提供するMNOポータルも、プロファイル管理サーバの一部として含まれる。
リモートでのプロファイルダウンロードおよびプロファイル管理に関連するNB-IoT101内の識別情報モジュールとのオーバージエアでのセキュア通信は、SM-SRによって排他的にハンドリングされ得る。セキュア通信は、SM-SRと識別情報モジュールとの間で共有される資格情報に基づき得る。SM-DPは、SM-SRと識別情報モジュールとの間に確立されたセキュア通信トンネルを介してプロファイルダウンロードをハンドリングするエンティティであり得る。また、SM-SRは、プロファイル管理動作(プロファイルの有効化、無効化、および削除)を制御するエンティティであり得る。SM-SRとSM-DPとMNOポータルとの間の個々の通信はGSMA RSP標準に従い得ると仮定することができ、したがって、この通信の詳細は本明細書に含まれていない。しかしながら、SM-SRとSM-DPとMNOポータルとの間のこの通信は、任意の適切な通信方法を含み得ることが理解されよう。セキュア通信トンネル内で実行される識別情報モジュールとMNOポータル/SM-DP/SM-SRとの間の通信についても同様である。
SM-SR107間のセキュア通信は、(保護された)SMS、HTTPS、およびカードアプリケーションツールキットトランスポートプロトコル(CAT_TP)に基づき得る。SMSは、HTTPSおよびCAT_TPセッションをトリガするために、また1つまたはいくつかのSMSに適合する単純なコマンドのために使用され得る。HTTPSまたはCAT_TPは、データ集約型の転送、例えば、プロファイルダウンロードに関連する転送のために使用され得る。
図6は、図5に示したシグナリング図の一例を示す。この例は、GSMA RSP M2M版の使用に関連し得る。標準GSMA RSPの構成要素(例えば、SM-SR)およびM2M版をサポートする識別情報モジュールへの変更の数を最小限に抑え、プロファイル管理サーバ107におけるプロキシサーバ108、デバイスIDなどの知識を最小限に抑えるために、通信フローは、プロファイルの有効化をトリガするためのトリガメッセージおよび要求がD/C管理サーバ109を介してルーティングされるように修正される。
上記で示したように、NB-IoTデバイス101はSMSをサポートしていないので、トリガメッセージは、図4を参照して説明したように送信され得る。この例では、トリガメッセージは、GSMA RSPで使用されるSMS形式と同じ形式であり得る。例えば、SMS形式は、ETSIによって規定された拡張リモートAPDUコマンド構造を含み得る。したがって、識別情報モジュールの観点からは、識別情報モジュールは、SMSサービスをサポートするデバイスで使用されるときと同一のメッセージをNB-IoTデバイスから受信することになる。同様に、SM-SRおよびSM-DPの場合、これらは、標準によるSMS形式のトリガメッセージを作成し得るが、SMSサービスを使用してSMSメッセージを送信することはない。代わりに、NB-IoTデバイス101への配信のために、SMSトリガメッセージがD/C管理サーバ109に提供される。
NB-IoTデバイス101(例えば、eUICC)の識別情報モジュールは、NB-IoTデバイス101がセルラネットワークに接続することを可能にするアクティブなセルラ加入(すなわち、有効化されたプロファイル)を有するように設定され得る。これは、動作プロファイルの提供を可能にする目的で製造時にインストールされたプロファイルであり得るか、または以前にNB-IoTデバイス101によってダウンロードされた動作プロファイルであり得る。
HSS106は、NB-IoTデバイス101の加入者資格情報を有するように設定され得る。加入者資格情報は、公開機能104(例えば、SCEF)を介してデバイスをアドレス指定するために使用される外部識別子を含み得る。プロキシサーバ108は、NB-IoTデバイス101をアドレス指定することが可能な外部識別子を有するように設定され得る。プロファイル管理サーバ107は、ダウンロード可能であり得るプロファイルパッケージのセットを含み得る。プロファイルパッケージに対する対応するプロファイル識別子は、NB-IoTデバイスを所有する企業に提供されていることがあり、D/C管理サーバ109に提供され得る。所与のプロファイルパッケージについて、プロファイルに対応するモバイルネットワークのHSS106は、プロファイルパッケージの加入者資格情報に対応する加入者資格情報、およびNB-IoT101の外部識別子を有するように設定される。
ステップ601において、D/C管理サーバ109は、プロファイルのダウンロードをトリガするためのコマンドをプロファイル管理サーバ107に送信する。ステップ501において、D/C管理サーバ109は、少なくとも、プロファイルがダウンロードされるNB-IoTデバイス101のデバイス識別子、ダウンロードされるプロファイルに対応するプロファイル識別子、およびプロキシサーバ108のURLを提供し得る。デバイス識別子は、プロファイル管理サーバ107によって、プロファイルダウンロードがトリガされるべきデバイスを識別するために使用され、プロファイル識別子は、ダウンロードされるプロファイルを識別する。この例では、デバイス識別子はeUICC ID(EID)を含む。この例では、プロファイル識別子はICCIDを含む。
ステップ602において、プロファイル管理サーバ107は、GSMA RSP M2M版「HTTPSセッショントリガのためのSMS」によるフォーマットされたデータを含むメッセージ(例えば、GSMA RSP M2M版によるフォーマットされたトリガメッセージ)をD/C管理サーバ109に送信する。具体的には、メッセージは、EID、およびトリガメッセージのための情報を含み得る。
したがって、この例では、ステップ603において、D/C管理サーバ209は、トリガメッセージをNB-IoTデバイス101に配信するよう求める要求をプロキシサーバ108に送信し、要求は、デバイス識別子を含む(ステップ603は、図2のステップ201に対応し得る)。この例では、D/C管理サーバは、EIDに対応するデバイス識別子を検索し得る
ステップ604において、プロキシサーバ108は、ステップ603で受信したデバイス識別子によって識別されるNB-IoTデバイスにトリガメッセージを配信する。具体的には、プロキシサーバ108は、ステップ603で受信したデバイス識別子に基づいて外部識別子を決定し得る。デバイス識別子が外部識別子と異なる場合、プロキシサーバ108は、提供されたデバイス識別子を使用してデータベース内の外部識別子を検索する。次いで、ステップ604は、図4に示すように実施され得る。
ステップ605において、NB-IoTデバイス101内のデバイスアプリケーションは、「HTTPSセッショントリガのためのSMS」をNB-IoT101内の識別情報モジュールに送信し得る。
ステップ606において、NB-IoTデバイス101およびプロファイル管理サーバ107は、例えば、相互認証を含むセキュア通信を確立するためにメッセージを交換する。この例では、ステップ606は、GSMA RSP M2M版によるHTTPSセッションの確立を含む。ここでのソリューションは、プロファイル管理サーバ(SM-SR部分)107とNB-IoT101の識別情報モジュールの2つのエンドポイントが修正を必要とせず、それらの間で転送されるHTTPSメッセージを交換できることを保証する。メッセージの転送方法についての詳細を以下に説明する。
ステップ607において、NB-IoTデバイス101は、プロファイル管理サーバ107からプロファイルパッケージをダウンロードする。プロファイル管理サーバ107は、ステップ601で受信したデバイス識別子およびプロファイル識別子に基づいて、どのプロファイルパッケージをNB-IoTデバイス101にダウンロードするかを認識する。次いで、NB-IoTによって、プロファイルパッケージが識別情報モジュールにインストールされ得る。例えば、ステップ607は、プロファイル管理サーバからプロファイルを受信することと、プロファイルを識別情報モジュールにインストールすることとを含み得る。この例では、プロファイル管理サーバ(SM-SR部分)107と識別情報モジュールとの間のセキュアなトンネル内ですべて交換される一連のメッセージからなる標準GSMA RSP M2Mプロトコルによる、プロファイルパッケージがNB-IoTデバイスにダウンロードされ、識別情報モジュールにインストールされる。
ステップ608において、プロファイル管理サーバ107は、任意選択として、トリガメッセージの結果について報告する応答をD/C管理サーバ109に提供し得る。例えば、プロファイル管理サーバ107は、プロファイルがNB-IoT101に正常にダウンロードされたか否かをD/C管理サーバ109に示し得る。
この例では、プロファイルは、新しいモバイルネットワークのプロファイルである。したがって、この例では、D/C管理サーバ109は、ステップ609において、NB-IoTデバイス101について新しいモバイルネットワークに切り替えるよう求める要求をプロキシサーバ108に送信し得る。例えば、新しいモバイルネットワークに切り替えるよう求める要求は、プロキシサーバが、新しいモバイルネットワークに属するP-GWなどを公開機能に登録することを求める要求を含み得る。要求には、プロキシサーバが登録するよう要求されているMNOサービスのURLが含まれ得る。P-GWの場合、プロキシサーバはプロファイルの申込み/準備フェーズからNIDDで使用するように事前設定されている可能性があり、その場合このステップは省略され得ることに留意されたい。
ステップ609に応答して、プロキシサーバは、ステップ610において、新しいモバイルネットワークに登録し得る。例えば、プロキシサーバ108は、NB-IoTデバイス101から送信された任意のデータが新しいモバイルネットワークを介してアプリケーションサーバにルーティングされ得るように、新しいモバイルネットワークに登録し得る。登録が行われると、プロキシサーバ108は、古いモバイルネットワークを介してNB-IoTデバイスにデータを送信するように設定されたまま、新しいプロファイルが有効化されて切り替えが完了した状態が確立されるまで、すなわち、プロキシサーバが、新しいモバイルネットワークを介してNB-IoTデバイスにデータを送信するように設定されるまで、両方のモバイルネットワークを介してNB-IoTデバイスからデータを受信することが可能になり得る。
この例では、プロファイルは、NB-IoTへのプロファイルのダウンロードとは別に有効化され得る。したがって、この例では、ステップ607において、プロファイルがダウンロードされ得、ステップ611において、D/C管理サーバ109が、プロファイルの有効化をトリガするよう求める要求をプロファイル管理サーバ107に送信し得る。この例では、ステップ611で送信される要求は、EIDおよびICCIDを含む。このステップは任意選択であり、プロファイルの有効化は、D/C管理サーバがプロファイルダウンロードのためにプロファイル管理サーバをトリガするステップ601の一部であり得る。
ステップ612において、プロファイル管理サーバ107は、EIDおよびGSMA RSP M2M版「プロファイル有効化のためのSMS」によるフォーマットされたデータを含むメッセージをD/C管理サーバに送信する。さらに、メッセージには、プロファイル管理サーバのURLが含まれ得る。ステップ611が実行されない場合、「プロファイル有効化のためのSMS」を提供するためのトリガは、プロファイルが正常にダウンロードされたことであることに留意されたい。その場合、メッセージは、プロファイル管理サーバ107によって、ステップ608の一部としてD/C管理サーバ109に提供され得る。
ステップ612でメッセージを受信したことに応答して、D/C管理サーバ109は、ステップ613において、ダウンロードされたプロファイルの有効化をトリガするための情報を含むメッセージをプロキシサーバ108に送信し得る。具体的には、D/C管理サーバは、ステップ612で提供されたEIDに対応するデバイス識別子を検索し、NB-IoTデバイス101へのメッセージの配信のために、メッセージ(「プロファイル有効化のためのSMS」)およびデバイス識別子をプロキシサーバ108に送信し得る。このメッセージは、プロファイル管理サーバ107のURLを含み得る。
ステップ614において、プロキシサーバ108は、ステップ613で受信したデバイス識別子によって識別されるNB-IoTデバイス101に、ダウンロードされたプロファイルの有効化をトリガするためのメッセージを配信する。上記のように、このステップでは、トリガメッセージは、図4で説明されているようにNB-IoTデバイスに配信され得る。
ステップ615において、NB-IoTデバイス101内のデバイスアプリケーションは、メッセージ(「プロファイル有効化のためのSMS」)を識別情報モジュールに配信する。
ステップ616において、識別情報モジュールは、プロファイルを有効化し、「SMS」としてフォーマットされたプロファイル有効化動作の結果を有するメッセージを準備する。
ステップ617において、ステップ616で準備されたメッセージは、NB-IoTデバイス101内のデバイスアプリケーションに配信される。
ステップ618において、ステップ616およびステップ617のメッセージは、NB-IoTデバイス101内のデバイスアプリケーションからプロファイル管理サーバ107に配信される。プロファイル管理サーバ107のURLは、デバイスアプリケーション/識別情報モジュールに認識されているか、ステップ614で受信したメッセージ「プロファイル有効化のためのSMS」の一部であるか、またはステップ614において「プロファイル有効化のためのSMS」とともに配信され得るかである。
ステップ619において、プロファイルの有効化が成功すると、新しいネットワークへの連結が実行される(この例のように、新しいプロファイルは新しいモバイルネットワークを伴う)。
ステップ620において、識別情報モジュールは、デバイスアプリケーションに配信される「SMS」としてフォーマットされた通知メッセージを準備する。
ステップ621において、メッセージ(「SMS通知」)が、デバイスアプリケーションからプロファイル管理サーバ107に配信される。プロファイル管理サーバのURLは、以前からNB-IoTデバイス101に知られている可能性がある。
ステップ621でのメッセージの配信において、プロキシサーバ108は、ステップ610で登録された新しいモバイルネットワークを介して、NB-IoTデバイス101からトラフィックを受信する。次いで、プロキシサーバ108は、NB-IoTデバイス101のモバイルネットワークを切り替えることを決定することができ、ステップ622において、新しいモバイルネットワークを介してNB-IoTデバイス101にデータを送信し得る。
ステップ623において、プロファイル管理サーバ107は、任意選択として、動作の結果について報告する応答をD/C管理サーバ109に提供する。例えば、プロファイル管理サーバ107は、プロファイルが有効化されたか否かを報告し得る。
プロファイルの有効化が成功し、プロファイルが新しいモバイルネットワークオペレータにあることに応答して、D/C管理サーバ109は、ステップ624において、新しいモバイルネットワークオペレータからのサービスを使用するように切り替えるようにプロキシサーバ108に命令し得る。例えば、プロキシサーバ108は、プロファイルが変更された特定のNB-IoTデバイスの新しいモバイルネットワークで公開機能(例えば、SCEF)および/またはP-GWを使用するように切り替えるように命令され得る。新しいモバイルネットワークへの登録は、以前に(例えば、ステップ610において)行われている可能性がある。NB-IoTデバイスのデバイス識別子は、使用される様々なMNOサービス(SCEF、P-GWなど)へのURLとともに提供され得る。
ステップ625において、プロキシサーバ108は、プロキシサーバ108の設定を、アプリケーションサーバからNB-IoTデバイス101へのデータが今度は新しいモバイルネットワークを介して転送されるように変更し得る。プロキシサーバ108はまた、古いモバイルネットワークサービスから登録解除し得る。
図6は、SMSサービスが提供されておらず、NIDDが使用され得るNB-IoTデバイス101の場合に、プロファイル管理サーバのSM-SR部分とeUICCとの間の通信がどのように実行されるかを示す例示的なフローである。図6は、HTTPSセッションを使用した「SMS」配信およびデータ配信がどのようにハンドリングされるかを示す。CAT_TPセッションは、HTTPSと同じ方法でハンドリングされる。同じ技法を用いて、すべてのGSMA RSP M2M版フローを適宜に適合させることができる。
いくつかの実施形態において、プロファイルダウンロードおよびプロファイル管理は、GSMA RSP消費者版により実行される。この場合、プロファイル管理サーバ107は、SM-DP+として知られている。SM-DP+107は、企業が新しい加入プロファイルを申し込んだMNOによって運用され得るか、またはSM-DP+107は、サードパーティによって運用され得、MNOに提供されるサービスの一部であり得る。SM-DP+107が、MNOが使用するサードパーティによって提供されるサービスである例では、D/C管理サーバ109をSM-DP+とリンクするプロファイル管理動作用の顧客向けのインターフェースを提供するMNOポータルも、プロファイル管理サーバの一部として含まれる。この例を図7に示す。
D/C管理サーバ109は、NB-IoTデバイス101内のローカルプロファイルアシスタント(LPAd)700を介して、プロファイルダウンロードおよびプロファイル管理動作をリモートで制御し得る。LPAd70は、識別情報モジュールとの対話およびプロファイル管理サーバ107との対話をハンドリングする。LPAd700と、D/C管理サーバ109とプロファイル管理サーバ107との両方との間でセキュア通信が確立され得る。SM-DP+107とMNOポータルとの間の個々の通信は、GSMA RSP標準に従うことができ、したがって本明細書では、通信のこの部分の詳細は提供されていない。LPAd700とSM-DP+107との間のセキュア通信トンネル内で実行され得る識別情報モジュールとSM-DP+107との間の通信についても同様である。
SM-DP+107とLPAd700との間のセキュア通信は、HTTPSに基づき得、LPAd700とD/C管理サーバ109との間のセキュア通信は、トランスポート層セキュリティ(TLS)/データグラムTLS(DTLS)、または制約付きRESTful環境のためのオブジェクトセキュリティ(OSCORE:Object Security for Constrained RESTful Environments)に基づき得る。
図7は、図5に示したフローの一例を示す。具体的には、図7は、GSMA RSP消費者版が使用されている例の図5のフローを示す。通信フローは、プロファイルダウンロードトークン情報を取得した後にトリガメッセージがD/C管理サーバ109を介してルーティングされるように変更され得る。
NB-IoTデバイス101(例えば、eUICC)の識別情報モジュールは、NB-IoTデバイス101がセルラネットワークに接続することを可能にするアクティブなセルラ加入(すなわち、有効化されたプロファイル)を有するように設定され得る。これは、動作プロファイルの提供を可能にする目的で製造時にインストールされたプロファイルであり得るか、または以前にNB-IoTデバイス101によってダウンロードされた動作プロファイルであり得る。
HSS106は、NB-IoTデバイス101の加入者資格情報を有するように設定され得る。加入者資格情報は、公開機能104(例えば、SCEF)を介してデバイスをアドレス指定するために使用される外部識別子を含み得る。プロキシサーバ108は、NB-IoTデバイス101をアドレス指定することが可能な外部識別子を有するように設定され得る。プロファイル管理サーバ107は、ダウンロード可能であり得るプロファイルパッケージのセットを含み得る。企業が、1つまたは複数のNB-IoTデバイスを所有して、プロファイル管理サーバ107のMNOポータルを介して企業のデバイスのプロファイルを申し込んだ後に、プロファイル管理サーバによるこれらのプロファイルの準備が続き、企業は、企業のデバイスにデバイス識別を提供している場合がある。次いで、対応するプロファイルダウンロード情報(すなわち、プロファイルパッケージに対するプロファイル識別子)は、NB-IoTデバイスを所有する企業に提供され得、D/C管理サーバ109に提供され得る。所与のプロファイルパッケージについて、プロファイルに対応するモバイルネットワークのHSS106は、プロファイルパッケージの加入者資格情報に対応する加入者資格情報、およびNB-IoT101の外部識別子を有するように設定される。
ステップ701およびステップ702は、上記のようにプロファイルダウンロード情報を取得するD/C管理サーバ109に関する。ステップ701において、D/C管理サーバ109は、プロファイルダウンロード情報を取得するためのコマンドをプロファイル管理サーバ107(MNOポータル部分)に送信する。ステップ701において、D/C管理サーバ109は、少なくとも、プロファイルがダウンロードされるNB-IoTデバイス101のデバイス識別子を提供し得る。デバイス識別子は、プロファイル管理サーバ107によって、プロファイルのダウンロードがトリガされるべきデバイスを識別するために使用される。この例では、デバイス識別子は、eUICC ID(EID)または国際移動体機器識別情報(IMEI:International Mobile Equipment Identity)を含む。
ステップ702において、プロファイル管理サーバ107は、SM-DP+107のアドレスおよびプロファイルダウンロード識別子を含むメッセージをD/C管理サーバ109に送信する。アドレスおよびプロファイルダウンロード識別子は、アクティベーションコードの形式で提供され得る。アクティベーションコードは、企業によって他の方法で取得され、次いでD/C管理サーバ109に設定され得ることに留意されたい。その場合、ステップ701およびステップ702は実行されない可能性がある。
ステップ703において、D/C管理サーバ109は、トリガメッセージをNB-IoTデバイス101に配信するよう求める要求をプロキシサーバ108に送信し、要求は、デバイス識別子を含む(ステップ703は、図2のステップ201に対応し得る)。
ステップ704において、プロキシサーバ108は、ステップ703で受信したデバイス識別子によって識別されるNB-IoTデバイスにトリガメッセージを配信する。具体的には、プロキシサーバ108は、ステップ703で受信したデバイス識別子に基づいて外部識別子を決定し得る。デバイス識別子が外部識別子と異なる場合、プロキシサーバ108は、提供されたデバイス識別子を使用してデータベース内の外部識別子を検索する。次いで、ステップ704は、図4に示すように実施され得る。
ステップ705において、NB-IoTデバイス101内のデバイスアプリケーション(例えば、LPAd700)は、デバイスとD/C管理サーバとの間のセキュア通信の確立をトリガする。NB-IoTデバイスのタイプに応じて、様々なプロトコルが使用され得る。例えばIPベースの通信を使用するNB-IoTデバイスの場合、ステップ705は、TLS/DTLSを使用することができ、CoAPを使用するNB-IoTデバイスの場合、ステップ705は、OSCOREを利用することができる。OSCOREが使用される場合、例えばEDHOCを使用して共通のセキュリティコンテキストがすでに確立されている可能性があり、OSCOREが直接使用され得ることに留意されたい。代替として、OSCOREセキュリティコンテキストの確立に、COSEによる一時的なDiffie-Hellman法(EDHOC:Ephemeral Diffie-Hellman Over COSE)が使用されてもよい。ステップ705は、ステップ704が実行される場合にのみ実行され得る。
ステップ706において、D/C管理サーバ109は、アクティベーションコードをLPAd700にセキュアに配信する。
ステップ707において、NB-IoTデバイス101(例えば、LPAd700)は、プロファイル管理サーバ107とのセキュア通信(例えば、相互認証を含む)を確立する。例えば、LPAd700は、アクティベーションコード内のアドレスを利用して、プロファイル管理サーバ107との通信を確立し得る。具体的には、ステップ707は、GSMA RSP消費者版によるHTTPSセッションの確立を含み得る。本明細書の実施形態は、2つのエンドポイント、例えばプロファイル管理サーバ(SM-DP+部分)107およびLPAd700が修正を必要とせず、それらの間で転送されるHTTPSメッセージを交換できることを保証し得る。メッセージの転送方法についての詳細を以下に説明する。
ステップ708において、NB-IoTデバイス101は、プロファイル管理サーバ107からプロファイルパッケージをダウンロードする。次いで、NB-IoTによって、プロファイルパッケージが識別情報モジュールにインストールされ得る。例えば、ステップ708は、プロファイル管理サーバからプロファイルを受信することと、プロファイルを識別情報モジュールにインストールすることとを含み得る。この例では、プロファイル管理サーバ(SM-DP+)とLPAdとの間のセキュアなトンネル内ですべて交換される一連のメッセージからなる標準GSMA RSPプロトコル消費者版に従って、プロファイルパッケージがデバイスにダウンロードされ、識別情報モジュールにインストールされ、LPAdは、識別情報モジュールとの対話をハンドリングする。この一連のメッセージは、(一致識別子と呼ばれる)プロファイル識別子および/またはEIDをプロファイル管理サーバに提供するLPAdを含み、これにより、プロファイル管理サーバは、この特定のデバイスについて、準備済みプロファイルパッケージのセット内のどのプロファイルパッケージをダウンロードすべきかを認識する。
ステップ709において、LPAd700は、任意選択として、トリガメッセージの結果について報告する応答をD/C管理サーバ109に提供し得る。例えば、LPAd700は、プロファイルがNB-IoTデバイス101に正常にダウンロードされたか否かをD/C管理サーバ109に示し得る。この応答は、プロファイルに関連するプロファイル管理動作で使用するプロファイル識別子ICCIDを含み得る。
この例では、プロファイルは、新しいモバイルネットワークのプロファイルである。したがって、この例では、D/C管理サーバ109は、ステップ710において、NB-IoTデバイス101について新しいモバイルネットワークに切り替えるよう求める要求をプロキシサーバ108に送信し得る。例えば、新しいモバイルネットワークに切り替えるよう求める要求は、プロキシサーバが、新しいモバイルネットワークに属するP-GWなどを公開機能に登録することを求める要求を含み得る。要求には、プロキシサーバが登録するよう要求されているMNOサービスのURLが含まれ得る。要求には、デバイス識別子も含まれ得る。P-GWの場合、プロキシサーバはプロファイルの申込み/準備フェーズからNIDDで使用するように事前設定されている可能性があり、その場合このステップは省略され得ることに留意されたい。
ステップ710に応答して、プロキシサーバは、ステップ711において、新しいモバイルネットワークに登録し得る。例えば、プロキシサーバ108は、NB-IoTデバイス101から送信された任意のデータが新しいモバイルネットワークを介してアプリケーションサーバにルーティングされ得るように、新しいモバイルネットワークに登録し得る。登録が行われると、プロキシサーバ108は、古いモバイルネットワークを介してNB-IoTデバイスにデータを送信するように設定されたまま、新しいプロファイルが有効化されて切り替えが完了した状態が確立されるまで、すなわち、プロキシサーバは、新しいモバイルネットワークを介してNB-IoTデバイスにデータを送信するように設定されるまで、両方のモバイルネットワークを介してNB-IoTデバイスからデータを受信することが可能になり得る。
この例では、プロファイルは、NB-IoTへのプロファイルのダウンロードとは別に有効化され得る。したがって、この例では、ステップ708において、プロファイルがダウンロードされ得、ステップ712において、D/C管理サーバ109が、プロファイルの有効化をトリガするよう求める要求をプロキシサーバ108に送信し得る。要求は、デバイス識別子を含み得る。ステップ712は、D/C管理サーバ107とNB-IoTデバイス101との間に確立されたセキュア通信がまだない場合、およびステップ703のトリガメッセージが実行されるべきプロファイルダウンロードとダウンロードされたプロファイルの有効化との両方をまだ示していない場合にのみ実行され得る。
ステップ713において、プロキシサーバ108は、ステップ712で受信したデバイス識別子によって識別されるNB-IoTデバイス101に、ダウンロードされたプロファイルの有効化をトリガするためのメッセージを配信する。上記のように、このステップでは、トリガメッセージは、図4で説明されているようにNB-IoTデバイスに配信され得る。ステップ713は任意であり、ステップ712が実行されない場合、実行されない可能性がある。
ステップ714において、デバイスアプリケーション(例えば、LPAd700)は、NB IoTデバイス101とD/C管理サーバ107との間のセキュア通信の確立をトリガする。デバイスのタイプに応じて、様々なプロトコルが使用され得る。例えばIPベースの通信を使用するNB-IoTデバイスの場合、ステップ714は、TLS/DTLSを使用することができ、CoAPを使用するNB-IoTデバイスの場合、ステップ714は、OSCOREを利用することができる。OSCOREが使用される場合、例えばEDHOCを使用して共通のセキュリティコンテキストがすでに確立されている可能性があり、OSCOREが直接使用され得ることに留意されたい。代替として、OSCOREセキュリティコンテキストの確立にEDHOCが使用されてもよい。ステップ714は、ステップ713が実行される場合にのみ実行され得る。
ステップ715において、D/C管理サーバ109は、新しいプロファイルの有効化をトリガするためのメッセージをLPAd700に送信する。このメッセージは、ステップ703のトリガメッセージが、ダウンロードされたプロファイルの実行されるべき有効化も示した場合、省略され得る。プロファイル識別子ICCIDもメッセージの一部として提供され得る。
ステップ716において、LPAd700は、識別情報モジュールで提供されたプロファイル識別子を用いてプロファイルの有効化をトリガする。
ステップ717において、識別情報モジュールは新しいプロファイルを有効化する。
ステップ718において、プロファイルの有効化が成功すると、新しいネットワークへの連結が実行される(この例のように、新しいプロファイルは新しいモバイルネットワークを伴う)。
ステップ719において、LPAd700は、プロファイルの有効化が成功したかどうかを示す応答をD/C管理サーバに提供する。
ステップ719での応答の配信において、プロキシサーバ108は、新しいモバイルネットワークを介してNB-IoTデバイス101からトラフィックを受信する。次いで、プロキシサーバ108は、ステップ720において、NB-IoTデバイス101のモバイルネットワークを切り替えることを決定することができ、これから先は、新しいモバイルネットワークを介してNB-IoTデバイス101にデータを送信することができる。
プロファイルの有効化が成功し、プロファイルが新しいモバイルネットワークオペレータにあることに応答して、D/C管理サーバ109は、ステップ721において、新しいモバイルネットワークオペレータからのサービスを使用するように切り替えるようにプロキシサーバ108に命令し得る。例えば、プロキシサーバ108は、プロファイルが変更された特定のNB-IoTデバイスの新しいモバイルネットワークで公開機能(例えば、SCEF)および/またはP-GWを使用するように切り替えるように命令され得る。新しいモバイルネットワークへの登録は、以前に(例えば、ステップ711において)行われている可能性がある。NB-IoTデバイスのデバイス識別子は、使用される様々なMNOサービス(SCEF、P-GWなど)へのURLとともに提供され得る。
ステップ722において、プロキシサーバ108は、プロキシサーバ108の設定を、アプリケーションサーバからNB-IoTデバイス101へのデータが今度は新しいモバイルネットワークを介して転送されるように変更し得る。プロキシサーバ108はまた、古いモバイルネットワークサービスから登録解除し得る。
申込み時にEIDまたは他のデバイス識別子を提供せずに1つまたは複数のデバイスのプロファイルを申し込むことが可能であり、プロファイルダウンロード時に、プロファイルと特定のNB-IoTデバイスとの結び付けが発生することに留意されたい。D/C管理サーバは、例えば、ステップ703の前に、1組のNB-IoTデバイスのためのアクティベーションコードのセットを有するように設定され得、ステップ706で使用するために、このセットの中から1つのアクティベーションコードを選択し得る。次いで、どのプロファイルをどのNB-IoTデバイスに送信するかをD/C管理サーバが決定する。次に、プロファイル識別子およびデバイス識別子とEIDとの間の結び付けは、SM-DP+がデバイスからEIDおよびIMEIを受信するステップ708においてプロファイルダウンロード時に行うことができ、この結び付けは、MNOに報告され得る。
図7は、NIDDを使用できるNB-IoTデバイスの場合に、SM-DP+とNB-IoTデバイス(例えば、識別情報モジュール)との間の通信がどのように実行されるかを示すフローの一例を示す。同じ技法を用いて、すべてのGSMA RSP消費者版フローを適宜に適合させることができる。
いくつかの実施形態において、プロファイルダウンロードおよびプロファイル管理は、IoTに適合したGSMA RSP消費者版による。ここで、LPAd700は2つの部分に分割され、主要部分であるLPAprは、デバイスからD/C管理サーバ109に移動され、小部分であるLPAdv800は、識別情報モジュールとの通信のためにNB-IoTデバイス101内に残る。この場合、HTTPSベースの通信は、D/C管理サーバ内のLPAprによってハンドリングされ、これにより、NB-IoTデバイス101の複雑さが軽減され、プロキシサーバ108も簡素化され得る。D/C管理サーバとLPAdvとの間のメッセージは、eUICCとの通信に関連するメッセージに対応し得る。
図8は、図5のプロファイルダウンロードおよびプロファイル有効化のフローの一例を示す図であり、フローは、GSMA RSPの適合された消費者版用に再描画されている。
NB-IoTデバイス101(例えば、eUICC)の識別情報モジュールは、NB-IoTデバイス101がセルラネットワークに接続することを可能にするアクティブなセルラ加入(すなわち、有効化されたプロファイル)を有するように設定され得る。これは、動作プロファイルの提供を可能にする目的で製造時にインストールされたプロファイルであり得るか、または以前にNB-IoTデバイス101によってダウンロードされた動作プロファイルであり得る。
HSS106は、NB-IoTデバイス101の加入者資格情報を有するように設定され得る。加入者資格情報は、公開機能104(例えば、SCEF)を介してデバイスをアドレス指定するために使用される外部識別子を含み得る。プロキシサーバ108は、NB-IoTデバイス101をアドレス指定することが可能な外部識別子を有するように設定され得る。プロファイル管理サーバ107は、ダウンロード可能であり得るプロファイルパッケージのセットを含み得る。企業が、1つまたは複数のNB-IoTデバイスを所有して、プロファイル管理サーバ107のMNOポータルを介して企業のデバイスのプロファイルを申し込んだ後に、プロファイル管理サーバによるこれらのプロファイルの準備が続き、企業は、企業のデバイスにデバイス識別を提供している場合がある。次いで、対応するプロファイルダウンロード情報(すなわち、プロファイルパッケージに対するプロファイル識別子)は、NB-IoTデバイスを所有する企業に提供され得、D/C管理サーバ109に提供され得る。所与のプロファイルパッケージについて、プロファイルに対応するモバイルネットワークのHSS106は、プロファイルパッケージの加入者資格情報に対応する加入者資格情報、およびNB-IoT101の外部識別子を有するように設定される。
ステップ801およびステップ802は、上記のようにプロファイルダウンロード情報を取得するD/C管理サーバ109に関する。ステップ801において、D/C管理サーバ109は、プロファイルダウンロード情報(例えば、アクティベーションコード)を取得するためのコマンドをプロファイル管理サーバ107(MNOポータル部分)に送信する。ステップ801において、D/C管理サーバ109は、少なくとも、プロファイルがダウンロードされるNB-IoTデバイス101のデバイス識別子を提供し得る。デバイス識別子は、プロファイル管理サーバ107によって、プロファイルのダウンロードがトリガされるべきデバイスを識別するために使用される。この例では、デバイス識別子は、eUICC ID(EID)またはIMEIを含む。
ステップ802において、プロファイル管理サーバ107は、SM-DP+107のアドレスおよびプロファイルダウンロード識別子を含むメッセージをD/C管理サーバ109に送信する。アドレスおよびプロファイルダウンロード識別子は、アクティベーションコードの形式で提供され得る。アクティベーションコードは、企業によって他の方法で取得され、次いでD/C管理サーバ109に設定され得ることに留意されたい。その場合、ステップ801およびステップ802は実行されない可能性がある。
ステップ803において、D/C管理サーバ109は、トリガメッセージをNB-IoTデバイス101に配信するよう求める要求をプロキシサーバ108に送信し、要求は、デバイス識別子を含む(ステップ803は、図2のステップ201に対応し得る)。デバイスがすでにD/C管理サーバに登録されており、デバイスとD/C管理サーバとの間でセキュア通信がすでに確立されている場合、このステップは省略され得る。
ステップ804において、プロキシサーバ108は、ステップ803で受信したデバイス識別子によって識別されるNB-IoTデバイスにトリガメッセージを配信する。具体的には、プロキシサーバ108は、ステップ803で受信したデバイス識別子に基づいて外部識別子を決定し得る。デバイス識別子が外部識別子と異なる場合、プロキシサーバ108は、提供されたデバイス識別子を使用してデータベース内の外部識別子を検索する。次いで、ステップ804は、図4に示すように実施され得る。
ステップ805において、NB-IoTデバイス101内のデバイスアプリケーション(例えば、LPAdv800)は、デバイスとD/C管理サーバとの間のセキュア通信の確立をトリガする。NB-IoTデバイスのタイプに応じて、様々なプロトコルが使用され得る。例えばIPベースの通信を使用するNB-IoTデバイスの場合、ステップ805は、TLS/DTLSを使用することができ、CoAPを使用するNB-IoTデバイスの場合、ステップ805は、OSCOREを利用することができる。OSCOREが使用される場合、例えばEDHOCを使用して共通のセキュリティコンテキストがすでに確立されている可能性があり、OSCOREが直接使用され得ることに留意されたい。代替として、OSCOREセキュリティコンテキストの確立にEDHOCが使用されてもよい。ステップ805は、ステップ804が実行される場合にのみ実行され得る。
ステップ806において、D/C管理サーバの一部であるLPAprは、プロファイル管理サーバ107とのセキュア通信(相互認証を含む)を確立することによって、プロファイルダウンロードフローを開始する。GSMA RSP消費者版によれば、ステップ806は、HTTPSセッションの確立を含み得る。
ステップ807において、プロファイル管理サーバ(SM-DP+)とD/C管理サーバのLPAprとの間、およびD/C管理サーバとデバイス(LPAdv)との間のセキュアなトンネル内ですべて交換される一連のメッセージからなる、IoT用に適合されたGSMA RSPプロトコル消費者版に従って、プロファイルパッケージがデバイスにダウンロードされ、eUICCにインストールされ、LPAdv800は、識別情報モジュール(例えば、eUICC)との対話をハンドリングする。この一連のメッセージは、(一致識別子と呼ばれる)プロファイル識別子および/または識別情報モジュールのEIDをプロファイル管理サーバに提供するLPAprを含み、これにより、プロファイル管理サーバは、この特定のデバイスについて、準備済みプロファイルパッケージのセット内のどのプロファイルパッケージをダウンロードすべきかを認識する。プロファイルダウンロードを成功させる一環として、LPAprは、プロファイルに関連するプロファイル管理動作で使用するプロファイル識別子ICCIDを取得する。
この例では、プロファイルは、新しいモバイルネットワークのプロファイルである。したがって、この例では、D/C管理サーバ109は、ステップ808において、NB-IoTデバイス101について新しいモバイルネットワークに切り替えるよう求める要求をプロキシサーバ108に送信し得る。例えば、新しいモバイルネットワークに切り替えるよう求める要求は、プロキシサーバが、新しいモバイルネットワークに属するP-GWなどを公開機能に登録することを求める要求を含み得る。要求には、プロキシサーバが登録するよう要求されているMNOサービスのURLが含まれ得る。要求には、デバイス識別子も含まれ得る。P-GWの場合、プロキシサーバはプロファイルの申込み/準備フェーズからNIDDで使用するように事前設定されている可能性があり、その場合このステップは省略され得ることに留意されたい。
ステップ808に応答して、プロキシサーバは、ステップ809において、新しいモバイルネットワークに登録し得る。例えば、プロキシサーバ108は、NB-IoTデバイス101から送信された任意のデータが新しいモバイルネットワークを介してアプリケーションサーバにルーティングされ得るように、新しいモバイルネットワークに登録し得る。登録が行われると、プロキシサーバ108は、古いモバイルネットワークを介してNB-IoTデバイスにデータを送信するように設定されたまま、新しいプロファイルが有効化されて切り替えが完了した状態が確立されるまで、すなわち、プロキシサーバは、新しいモバイルネットワークを介してNB-IoTデバイスにデータを送信するように設定されるまで、両方のモバイルネットワークを介してNB-IoTデバイスからデータを受信することが可能になり得る。
この例では、プロファイルは、NB-IoTへのプロファイルのダウンロードとは別に有効化され得る。したがって、この例では、ステップ807において、プロファイルがダウンロードされ得、ステップ810において、D/C管理サーバ109が、プロファイルの有効化をトリガするよう求める要求をプロキシサーバ108に送信し得る。要求は、デバイス識別子を含み得、LPAdv通信を指示し得る。このステップは、D/C管理サーバ109とNB-IoTデバイス101との間に確立されたセキュア通信がまだない場合にのみ実行され得る。
ステップ811において、プロキシサーバ108は、ステップ810で受信したデバイス識別子によって識別されるNB-IoTデバイス101に、ダウンロードされたプロファイルの有効化をトリガするためのメッセージを配信する。上記のように、このステップでは、トリガメッセージは、図4で説明されているようにNB-IoTデバイスに配信され得る。ステップ811は任意であり、ステップ810が実行されない場合、実行されない可能性がある。
ステップ812において、デバイスアプリケーション(例えば、LPAdv801)は、NB IoTデバイス101とD/C管理サーバ107との間のセキュア通信の確立をトリガする。デバイスのタイプに応じて、様々なプロトコルが使用され得る。例えばIPベースの通信を使用するNB-IoTデバイスの場合、ステップ812は、TLS/DTLSを使用することができ、CoAPを使用するNB-IoTデバイスの場合、ステップ812は、OSCOREを利用することができる。OSCOREが使用される場合、例えばEDHOCを使用して共通のセキュリティコンテキストがすでに確立されている可能性があり、OSCOREが直接使用され得ることに留意されたい。代替として、OSCOREセキュリティコンテキストの確立にEDHOCが使用されてもよい。ステップ812は、ステップ811が実行される場合にのみ実行され得る。
ステップ813において、D/C管理サーバ109(例えば、LPApr)は、新しいプロファイルの有効化をトリガするためのメッセージをLPAdv800に送信する。プロファイル識別子ICCIDもメッセージの一部として提供され得る。
ステップ814において、LPAdv800は、識別情報モジュールで提供されたプロファイル識別子を用いてプロファイルの有効化をトリガし、識別情報モジュールは、プロファイルを有効化する。
ステップ815において、プロファイルの有効化が成功すると、新しいネットワークへの連結が実行される(この例のように、新しいプロファイルは新しいモバイルネットワークを伴う)。
ステップ816において、LPAdv800は、プロファイルの有効化が成功したかどうかを示す応答をD/C管理サーバ109に提供する。
ステップ816での応答の配信において、プロキシサーバ108は、新しいモバイルネットワークを介してNB-IoTデバイス101からトラフィックを受信する。次いで、プロキシサーバ108は、ステップ817において、NB-IoTデバイス101のモバイルネットワークを切り替えることを決定することができ、これから先は、新しいモバイルネットワークを介してNB-IoTデバイス101にデータを送信することができる。
プロファイルの有効化が成功し、プロファイルが新しいモバイルネットワークオペレータにあることに応答して、D/C管理サーバ109は、ステップ818において、新しいモバイルネットワークオペレータからのサービスを使用するように切り替えるようにプロキシサーバ108に命令し得る。例えば、プロキシサーバ108は、プロファイルが変更された特定のNB-IoTデバイスの新しいモバイルネットワークで公開機能(例えば、SCEF)および/またはP-GWを使用するように切り替えるように命令され得る。新しいモバイルネットワークへの登録は、以前に行われている可能性がある。NB-IoTデバイスのデバイス識別子は、使用される様々なMNOサービス(SCEF、P-GWなど)へのURLとともに提供され得る。
ステップ819において、プロキシサーバ108は、プロキシサーバ108の設定を、アプリケーションサーバからNB-IoTデバイス101へのデータが今度は新しいモバイルネットワークを介して転送されるように変更し得る。プロキシサーバ108はまた、古いモバイルネットワークサービスから登録解除し得る。
図8は、NIDDを使用できるNB-IoTデバイスの場合に、SM-DP+とNB IoTデバイス101/識別情報モジュールとの間の通信がどのように実行されるかを示すフローの一例である。同じ技法を用いて、IoTに適合したすべてのGSMA RSP消費者版フローを適宜に適合させることができる。
デバイスとの間でデータを送受信する(デバイスタイプ1&2)
このセクションでは、NB-IoTデバイス101との間でデータを送受信する方法について説明する。プロキシサーバ108は、アプリケーションサーバからNB IoTデバイスにメッセージを送信するサービスと、NB-IoTデバイスからアプリケーションサーバにメッセージを中継し、応答メッセージを返すプロキシサービスとを提供する。これらのサービスは、NIDDを使用するNB-IoTデバイス向けである。IPベースのトラフィックを使用するデバイスの場合、通信は、典型的には、プロキシサーバ108を介さない。代わりに、モバイルネットワークによって提供される標準のIPベースのトラフィック配信が使用されるが、ここではこれ以上検討しない。
NIDDの場合、公開機能104またはP-GW102のいずれかを介するとき、モバイルネットワークは、NB-IoTデバイス101と公開機能104/P-GW102との間の高信頼トランスポートを提供しない。これは、高信頼トランスポートを保証するために、NB-IoTデバイス101内のデバイスアプリケーションとプロキシサーバ108との間で使用されるプロトコルが必要になり得ることを意味する。制約付きアプリケーションプロトコル(CoAP)は、アプリケーション関連のメッセージを転送するために制約付きIoTデバイスにおいて一般的に使用されるプロトコルである。CoAPは信頼性を提供する。したがって、通信にCoAPを使用すると、信頼性が確保される。CoAPを使用しない場合、モバイルネットワークによって提供される高信頼データサービス(RDS)プロトコルを使用して、デバイスと公開機能104/P-GW102との間の高信頼通信を実現することができる。
別の問題は、NIDDを実行している各NB-IoTデバイスが複数のアプリケーションサーバとどのように通信し得るかである。CoAPは、メッセージの対象受取側に関する情報をプロキシサーバに提供するために利用できる、Uri-HostおよびUri-PortというCoAPオプションを含む。RDSは、NB-IoTデバイスのどのアプリケーションに対してどのアプリケーションサーバがメッセージを交換するかを示すために使用できるポートの使用をサポートする。ポートの使用を調整するかどうかは、サーバ、およびデバイスのアプリケーション次第である。
重要なことは、提供されるソリューションがNB-IoTデバイス101とアプリケーションサーバとの間のエンドツーエンドのセキュリティを可能にすることである。OSCOREは、CoAPが使用される通信を確保する際に使用され得るCoAPメッセージを保護するためのプロトコルである。プロキシサーバ108でのルーティング目的でCoAPを使用するとき、DTLSまたはTLSを使用してメッセージをエンドツーエンドで確保することができない場合がある。
CoAPを使用した、公開機能を介したNIDDによるプロキシサーバのハンドリング(デバイスタイプ1)
このセクションでは、公開機能(例えば、SCEF)を介してNIDDを使用するNB-IoTデバイスおよびアプリケーションサーバがプロキシサーバ108を介して相互にCoAPメッセージをどのように送信できるかについて説明する。
NB-IoTデバイスがNIDDを使用してアプリケーションサーバにメッセージを送信するとき、アプリケーションサーバに関する情報をプロキシサーバ108に提供することが必要とされ得る。CoAPは、サーバURIに関する情報を提供できるCoAPオプションを使用している。これらは、Uri-Host、Uri-Port、Uri-Path、およびUri-Queryである。アプリケーションサーバとNB-IoTデバイスとの間でOSCOREにより保護されたメッセージを使用する場合、Uri-PathおよびUri-Queryは暗号化および完全性保護され、CoAPメッセージの受信者(この場合はアプリケーションサーバ)のみが読み取ることができる。Uri-HostおよびUri-Portは、保護されたCoAPメッセージに含まれてもよく、その場合、プロキシサーバ108が情報を読み取ることができるように、暗号化も完全性保護もされない場合がある。通常、Uri-HostおよびUri-PortがIPアドレスおよびUDP/TCPポートを示す場合、UDP層またはTCP層から情報を推測できるため、これらのオプションは省略される。しかしながら、この場合、プロキシ動作が機能するように、各CoAP要求メッセージ内には、NB-IoTデバイスによって、少なくともUri-Hostオプション、場合によってはUri-Portオプションも含まれ得る。図9にフローを示す。
図9は、公開機能104を介して、NIDDを使用してNB-IoTデバイスからアプリケーションサーバにCoAP要求を送信することを示す。
NB-IoTデバイス101内のデバイスアプリケーションは、CoAP要求を準備する。この例では、受取側の情報を提供するために、Uri-Hostおよび場合によりUri-PortがCoAP要求に含まれる。
ステップ901において、デバイスアプリケーションは、NIDDサービスを使用してCoAP要求を送信する。CoAP要求は、MME105に配信される。
ステップ902において、MME105は、CoAP要求を公開機能104(この例ではSCEF)に送信する。MMEは、転送されるメッセージにデバイス識別子(例えば、ISMI)を含めることができる。
ステップ903において、公開機能は、デバイスの外部識別子を求める要求をHSS106に送信する。要求は、ステップ902で受信したデバイス識別子を含む。
ステップ904において、HSSは、受信されたデバイス識別子に基づいて外部識別子を検索し、外部識別子を公開機能104に送信する。
ステップ905において、公開機能104は、外部識別子を含むCoAP要求をプロキシサーバに転送する。
ステップ906において、プロキシサーバ108は、CoAP要求メッセージのUri-HostおよびUri-Port番号に基づいて、CoAP要求をどこに送信するかを決定する(送信先のIPアドレスおよびUDP/TCPポート番号は、場合によってはDNS検索を介して取得され得る)。プロキシサーバ108は、ネットワークアドレス変換(NAT:Network Address Translation)を実行し、要求メッセージを送信する各NB-IoTデバイスにIPアドレスおよびポート番号を割り当てる。各NB-IoTデバイスは、一意のIPv6アドレスまたはIPv4アドレス+ポート番号を取得し得る。これらは、CoAP要求メッセージを転送するときに送信元アドレスとして使用される。プロキシサーバ108は、上記で決定された情報を使用して、TCP/IPまたはUDP/IPヘッダをCoAP要求に追加することができ、ステップ907において、CoAP要求をアプリケーションサーバ900に転送する。プロキシサーバ108は、NB-IoTデバイス101の割り当てられたIPv6/IPv4アドレス+ポートおよび外部識別子またはMSISDNのマッピングを格納する。
ステップ908において、アプリケーションサーバ900は、CoAP要求メッセージを処理し、ステップ909において、CoAP応答メッセージを提供する。応答は、使用されるIPアドレスおよびポートに基づいてプロキシサーバ108に戻るようにルーティングされる。
ステップ910において、プロキシサーバ108は、応答メッセージの送信先のアドレスおよびポートを使用して、NB-IoTデバイス101の外部識別子またはMSISDNを検索し、CoAP応答からTCP/IPヘッダまたはUDP/IPヘッダを削除する。ステップ911において、プロキシサーバ108は、公開機能NIDDのデータ送信コマンドを使用して、外部識別子またはMSISDNを示しながら、CoAP応答メッセージをデータとして送信する。
ステップ912において、公開機能は、NB-IoTデバイスのデバイス識別子を求める要求をHSS106に送信する。要求は、ステップ911で受信した外部識別子を含む。
ステップ913において、HSSは、外部識別子に基づいてデバイス識別子を検索し、デバイス識別子(例えば、IMSI)を公開機能104に送信する。
ステップ914において、公開機能NIDDサービスは、CoAP応答メッセージをMMEに転送し、次いで、MMEは、ステップ915において、CoAP応答を対象NB-IoTデバイスに転送し、CoAP応答は、CoAPメッセージIDおよびCoAPトークン値に基づいて、CoAP要求に接続され、デバイスで実行されている正しいアプリケーションに転送され得る。
ここでのCoAP応答の後に、アプリケーションからデバイスへのCoAP要求が続く場合もあり、CoAP要求は、同じCoAPトークンの使用を通してデバイスからのCoAP要求にリンクされる。プロキシサーバは、上記の説明により両方のメッセージを、デバイスへ戻すようにルーティングする。
集中的なデータ交換において各メッセージのために送信されるバイト数を最小限に抑えるために、CoAPのUri-HostおよびUri-Portオプションは、最初のCoAP要求で送信され、その後、NB-IoTデバイスからの将来のCoAP要求メッセージでは省略され得る。プロキシサーバは、Uri-Host、Uri-Port、およびUri-PathオプションなしでCoAP要求メッセージを受信すると、同じNB-IoTデバイスからの最後のメッセージが転送されたのと同じアプリケーションサーバにメッセージを転送するように設定され得る。
プロキシサーバ108は、NB-IoTデバイス101に静的IPv6アドレスを割り当て得るか、またはプロキシサーバ108は、特定のデバイスをアドレス指定するときに使用するアプリケーションサーバのためのCoAPリソースを提示し得る。後者の場合、プロキシサーバ108は、Uri-Path CoAPオプションを使用して、アプリケーションサーバに認識されているリソース名および/またはデバイス識別子を示し得る(デバイス識別子は、リソースの名前であり得る)。この場合、アドレス指定されているNB-IoTデバイスの保護されたUri-Pathオプション関連のリソースに加えて、保護されていないUri-Path CoAPオプションが含まれ得ることに留意されたい。(保護されていないCoAPメッセージの場合、パスの最初の部分は、プロキシサーバ108のリソース名およびデバイス識別子であり得、その後にNB-IoTデバイス上の対象リソースパスが続く)。次いで、プロキシサーバは、保護されていないUri-Pathオプション(または、保護されていないCoAPメッセージの場合はパスの最初の部分)を消費し得る(例えば、転送する前に削除する)。プロキシサーバ108は、静的IPv6アドレスまたはリソース名/デバイス識別子に対する外部識別子のマッピングを格納し得る。プロキシサーバ108は、外部識別子、アプリケーションサーバのIPアドレスおよびポート、ならびにCoAPメッセージIDおよびCoAPトークン値のマッピングも格納し得る。
図10は、公開機能104を介して、NIDDを使用してアプリケーションサーバ900からNB-IoTデバイス101にCoAP要求を送信することを示す。
アプリケーションサーバは、CoAP要求を準備する。IPアドレスまたはUri-Pathオプションは、要求のアドレス指定先であるNB-IoTデバイスを識別する。
ステップ1001において、アプリケーションサーバ900は、CoAP要求をプロキシサーバ108に送信する。
ステップ1002において、プロキシサーバ108は、受信したCoAP要求のIPアドレス、ポート、および場合によっては保護されていないUri-Pathを分析して、CoAP要求がプロキシサーバ108自体に対するものであるか、NB-IoTデバイスに対するものであるかを判定する。NB-IoTデバイスの場合、NB-IoTデバイスの外部識別子は、データベース検索を使用して取得され、プロキシサーバ108は、ステップ1003において、外部識別子を有するCoAP要求を公開機能104に送信する。CoAP要求データをNB-IoTデバイスに送信するために、公開機能NIDDのデータ送信コマンドが使用される。
ステップ1004において、公開機能は、ステップ1003で受信した外部識別子に関連付けられたデバイス識別子を求める要求をHSS106に送信する。
ステップ1005において、公開機能は、対応するデバイス識別子を受信し、この識別子は、この例ではISMIを含む。
ステップ1006において、公開機能104は、デバイス識別子を有するCoAP要求をMME105に送信する。
ステップ1007において、MME105は、CoAP要求をデバイス101に送信する。
ステップ1008において、NB-IoTデバイス101は、要求を処理する。アドレス指定されたリソースに基づいて、正しいアプリケーションが呼び出され、応答が準備される。ステップ1009において、NB-IoTデバイス101は、CoAP応答をMME105に送信する。
ステップ1008において、NB-IoTデバイス101は、CoAP応答を提供し、CoAP要求からのCoAPメッセージIDおよびCoAPトークン値は、標準のCoAP処理により使用される。次いで、CoAP応答は、NIDDを使用して公開機能104に送信され得る。
例えば、ステップ1009において、NB-IoTデバイスは、CoAP応答をMMEに転送し、MMEは、ステップ1010において、CoAP応答をデバイス識別子とともに公開機能に転送する。
ステップ1011において、公開機能104は、ステップ1010で受信したデバイス識別子に関連付けられた外部識別子を求める要求をHSS106に送信する。ステップ1012において、公開機能104は、HSS106から外部識別子を受信する。ステップ1013において、公開機能104は、CoAP応答を外部識別子とともにプロキシサーバ108に転送する。
ステップ1014において、プロキシサーバ108は、CoAP応答を処理する。受信した外部識別子ならびにCoAPメッセージIDおよび/またはCoAPトークンに基づいて、プロキシサーバ108は、データベースから、CoAP応答の転送先となるアプリケーションサーバのIPアドレスおよびポートを決定し得る。プロキシサーバ108は、上記で決定された情報を使用して、CoAP応答にTCP/IPまたはUDP/IPヘッダを追加することができ、ステップ1015において、CoAP応答をアプリケーションサーバ900に転送する。送信元IPアドレスおよびポートは、CoAP要求で使用されているものであり得、外部識別子から決定され得る。
CoAPを使用した、P-GWを介したNIDDによるプロキシサーバのハンドリング(デバイスタイプ2)
このセクションでは、P-GWを介してNIDDを使用するデバイスおよびアプリケーションサーバがプロキシサーバを介して相互にCoAPメッセージをどのように送信できるかについて説明する。
NB-IoTデバイスは、図9を参照して説明した方法と同じ方法でCoAPメッセージを準備し得る。CoAPは、代わりに、NIDDを使用してP-GW102に転送され得る。P-GW102は、UDP/IPヘッダを追加し得、メッセージをプロキシサーバ108に転送し得る。送信元IPアドレスおよびUDPポートは、CoAPメッセージの発信元であるNB-IoTデバイスに対してP-GW102が割り当てたIPアドレスおよびポートであり得る。プロキシサーバ108は、アプリケーションサーバ900のIPアドレスおよびポートを決定し得、図9を参照して説明した方法と同じ方法で、CoAPメッセージをアプリケーションサーバ900に転送し得る。プロキシサーバ108は、P-GW102によって割り当てられたようにNB-IoTデバイス101のIPアドレスを保持し得るか、またはNB-IoTデバイス101に新しいIPアドレスを割り当て、2つのIPアドレス間のマッピングをデータベースに格納し得る。後者の選択肢は、P-GW102で使用されるNB-IoTデバイス101のIPアドレスがモバイルオペレータの変更により変更される一方で、静的アドレスがプロキシサーバ108によって保持され得る場合に有利である。
次に、アプリケーションサーバ900は、CoAP要求を処理し、CoAP応答を提供し得る。CoAP応答は、使用されるIPアドレスおよびポートに基づいてプロキシサーバ108へ戻るようにルーティングされ、プロキシサーバ108によって、さらにP-GW102に(または、元のIPアドレスが保持されている場合は直接P-GW102に)ルーティングされ得る。P-GW102は、CoAP応答のIPアドレスおよびポートに基づいて、CoAP応答の転送先となるNB-IoTデバイスを決定し、UDP/IPヘッダを削除し、CoAP応答を(S-GW103およびMME105を介して)NB-IoTデバイスに転送し得る。NB-IoTデバイスにおいて、CoAP応答は、CoAPメッセージIDおよびCoAPトークン値に基づいてCoAP要求に接続され、NB-IoTデバイスで実行されている正しいアプリケーションに転送され得る。
いくつかの例において、プロキシサーバ108は、アプリケーションサーバがCoAP要求を送信するために使用する静的IPv6アドレスを、NB-IoTデバイスに割り当てていてもよい。プロキシサーバ108は、P-GW102によって割り当てられたようにNB-IoTデバイスのIPアドレスを追跡し得る。これは、外部識別子に基づいてIPアドレスを照会することによって行われ得る。プロキシサーバ108は、P-GW102によって割り当てられたようにIPアドレスを使用してCoAP要求を転送し得る。その場合、非IPトラフィック専用のポートが使用され得る。代替として、プロキシサーバ108は、図10を参照して説明したのと同様に、特定のデバイスをアドレス指定するときに使用するアプリケーションサーバ用のCoAPリソースを提示し得る。プロキシサーバ108は、モバイルコアネットワークサービスを使用して、リソース名に結び付けられた外部識別子に基づいて、NB-IoTデバイスの現在のIPアドレス(および場合によってはポート)を取得し得る。プロキシサーバ108は、(NB-IoTデバイスのIPアドレスを送信先アドレスとして使用して)CoAP要求をP-GW102に転送し得る。次いで、P-GWは、UDP/IPヘッダを削除し、NIDDサービスを使用して(S-GWおよびMMEを介して)メッセージをNB-IoTデバイスに転送し得る。プロキシサーバ108は、デバイスのIPアドレスおよびポート、アプリケーションサーバのIPアドレスおよびポート、ならびにCoAPメッセージIDおよびCoAPトークン値のマッピングを格納し得る。
NB-IoTデバイスは、CoAP応答を提供することができ、CoAP要求からのCoAPメッセージIDおよびCoAPトークン値は、標準のCoAP処理により使用される。CoAP応答は、NIDDを使用してP-GW102に送信され、P-GW102は、UDP/IPヘッダを追加し、CoAP応答をプロキシサーバ108に転送し得る。プロキシサーバ108は、CoAP応答を処理し得る。プロキシサーバ108は、送信元IPアドレスおよびポート、CoAPメッセージIDおよび/またはCoAPトークンに基づいて、データベースから、CoAP応答の転送先となるアプリケーションサーバのIPアドレスおよびポートを決定し得る。
RDSを使用した、SCEFを介したNIDDによるプロキシサーバのハンドリング(デバイスタイプ1)
このセクションでは、SCEFを介してNIDDを使用するデバイスおよびアプリケーションサーバが、RDSが利用される場合、プロキシサーバを介して相互にメッセージをどのように送信できるかについて説明する。RDSは、NB-IoTデバイス101および公開機能104(例えば、SCEF)内に実装される。ここでは、NB-IoTデバイス101およびプロキシサーバ108が、NB-IoTデバイス101およびアプリケーションサーバ900のアプリケーションをリンクするRDSポートのセットを有するように設定されていると仮定する。このような設定は、典型的には、NB-IoTデバイス101およびプロキシサーバ108において、各NB-IoTデバイス101に関連付けられたデバイス管理サーバによって設定され得、実行時に更新され得る。デバイス管理サーバとの通信は、NB-IoTデバイスの製造中に設定され、初めてセットアップされるときにプロキシサーバ108内に設定される、静的RDSポートを使用し得る。
図11は、RDSが使用される場合、公開機能を介して、NIDDを使用してNB-IoTデバイスからアプリケーションサーバに要求メッセージを送信する方法を示す。
ステップ1101において、デバイスアプリケーションは、NIDDサービスを使用して要求メッセージを送信する。RDSプロトコルが使用され、要求メッセージはペイロードであり、RDSポート番号は、要求メッセージがどのアプリケーションサーバを対象としているかにより設定される。要求メッセージはMME105に配信される。
ステップ1102において、MME105は、要求メッセージを公開機能104(この例では、SCEF)に送信する。MME105は、転送されるメッセージにデバイス識別子(例えば、ISMI)を含めることができる。
ステップ1103において、公開機能104は、デバイスの外部識別子を求める要求をHSS106に送信する。要求は、ステップ1102で受信したデバイス識別子を含む。
ステップ1104において、HSS106は、受信されたデバイス識別子に基づいて外部識別子を検索し、外部識別子を公開機能104に送信する。
ステップ1105において、公開機能104は、外部識別子およびRDSポート番号を含む要求メッセージをプロキシサーバ108に転送する。
ステップ1106において、プロキシサーバ108は、外部識別子およびRDSポートから、送信先のIPアドレスおよびポートを決定する。アプリケーションサーバ900のアドレス、および転送方法、例えば、要求メッセージをペイロードとして有するTCP/IPを使用することは、データベースから知られる。プロキシサーバは、上記と同様にNB-IoTデバイスにIPアドレスを割り当てており、IPアドレスと外部識別子との間のマッピングは、プロキシサーバ108によってアクセス可能なデータベースに格納され得る。
ステップ1107において、プロキシサーバは、プロキシサーバ108によってアクセス可能なデータベース内のRDSポート番号に関連付けられたアプリケーションサーバ900に要求メッセージを転送する。
ステップ1108において、アプリケーションサーバ900は、要求メッセージを処理し、ステップ1109において、応答メッセージを提供する。応答メッセージは、使用されるIPアドレスおよびポートに基づいてプロキシサーバ108に戻るようにルーティングされる。
ステップ1110において、プロキシサーバ108は、応答メッセージの送信先のアドレスおよびポートを使用して、NB-IoTデバイス101の外部識別子を検索し、応答メッセージからTCP/IPヘッダまたはUDP/IPヘッダを削除する。ステップ1111において、プロキシサーバ108は、公開機能NIDDのデータ送信コマンドを使用して、外部識別子およびRDSポートを示しながら、応答メッセージをデータ(RDSプロトコルペイロード)として送信する。
ステップ1112において、公開機能は、NB-IoTデバイスのデバイス識別子を求める要求をHSS106に送信する。要求は、ステップ1111で受信した外部識別子を含む。
ステップ1113において、HSSは、外部識別子に基づいてデバイス識別子を検索し、デバイス識別子(例えば、IMSI)を公開機能104に送信する。
ステップ1114において、公開機能NIDDサービスは、応答メッセージをMME105に転送し、次いで、MME105は、ステップ1115において、応答メッセージを対象NB-IoTデバイスに転送し、応答メッセージは、RDSポートに基づいて、デバイスで実行されている正しいアプリケーションに転送される。
プロキシサーバは、デバイスに静的IPv6アドレスを割り当て得るか、またはプロキシサーバは、特定のデバイスをアドレス指定するときに使用するアプリケーションサーバ用のリソースを提示する。後者の場合、アプリケーションサーバはURIを使用して、アプリケーションサーバに認識されているリソース名および/またはデバイス識別子を示し得る(デバイス識別子はリソースの名前であり得る)。プロキシサーバは、静的IPv6アドレスまたはリソース名/デバイス識別子に対する外部識別子またはMSISDNのマッピングを格納している。プロキシサーバは、RDSポート番号およびアプリケーションサーバのIPアドレスまたはドメイン名のマッピングも格納する。
図12は、RDSが使用される場合、公開機能104を介して、NIDDを使用してアプリケーションサーバ900からNB-IoTデバイス101に要求メッセージを送信することを示す。
アプリケーションサーバは、要求メッセージを準備する。IPアドレスまたはプロキシサーバリソースは、要求のアドレス指定先であるNB-IoTデバイスを識別する。
ステップ1201において、アプリケーションサーバ900は、要求メッセージをプロキシサーバ108に送信する。
ステップ1202において、プロキシサーバ108は、受信した要求メッセージのIPアドレス、ポート、および場合によってはURIを分析して、RDS要求がプロキシサーバ108自体に対するものであるか、NB-IoTデバイスに対するものであるかを判定する。NB-IoTデバイスの場合、NB-IoTデバイスの外部識別子は、データベース検索を使用して取得され、プロキシサーバ108は、ステップ1203において、外部識別子を有する要求メッセージを公開機能104に送信する。要求メッセージをNB-IoTデバイスに送信するために、公開機能NIDDのデータ送信コマンドが使用される。RDSポートは、プロキシサーバによって送信元IPアドレスの検索に基づいて設定される。
ステップ1204において、公開機能は、ステップ1203で受信した外部識別子に関連付けられたデバイス識別子を求める要求をHSS106に送信する。
ステップ1205において、公開機能は、対応するデバイス識別子を受信し、この識別子は、この例ではISMIを含む。
ステップ1206において、公開機能104は、デバイス識別子を有する要求メッセージをMME105に送信する。
ステップ1207において、MME105は、要求メッセージをデバイス101に送信する。
ステップ1208において、NB-IoTデバイス101は、要求メッセージを処理する。RDSポートに基づいて、正しいアプリケーションがNB-IoTデバイス101で呼び出され、応答メッセージが準備される。ステップ1209において、NB-IoTデバイス101は、MME105に配信される応答メッセージを送信する。
ステップ1208において、NB-IoTデバイス101は、NIDDを使用して公開機能104に送信され得る応答メッセージを提供する。
例えば、ステップ1209において、NB-IoTデバイス101は、応答メッセージをMME105に転送し、MME105は、ステップ1210において、応答メッセージをデバイス識別子とともに公開機能104に転送する。
ステップ1211において、公開機能104は、ステップ1210で受信したデバイス識別子に関連付けられた外部識別子を求める要求をHSS106に送信する。ステップ1212において、公開機能104は、HSS106から外部識別子を受信する。ステップ1213において、公開機能104は、応答メッセージを、外部識別子およびRDSポート番号とともにプロキシサーバ108に転送する。
ステップ1214において、プロキシサーバ108は、応答メッセージを処理する。受信した外部識別子およびRDSポート番号に基づいて、プロキシサーバ108は、データベースから、応答メッセージの転送先となるアプリケーションサーバのIPアドレスおよびポートを決定し得る。この特定のRDSポートに有効な転送方法、例えばTCP/IPは、データベースから取得され得る。プロキシサーバ108は、ステップ1215において、適切な転送方法により、応答メッセージをアプリケーションサーバ900に転送し得る。送信元IPアドレスおよびポートは、要求メッセージで使用されているものであり得、外部識別子から決定され得る。
RDSを使用した、P-GWを介したNIDDによるプロキシサーバのハンドリング(デバイスタイプ2)
このセクションでは、P-GWを介してNIDDを使用するデバイスとアプリケーションサーバが、RDSが利用される場合、プロキシサーバを介して相互にメッセージをどのように送信できるかについて説明する。RDSポートをP-GWで使用できるかどうか、およびどのように使用できるかは、3GPP仕様では明確に指定されていない。本明細書に記載の実施形態では、ある範囲のユーザデータグラムプロトコル(UDP)ポートを、P-GWでの非IPデータ配信モードに使用することができる。各UDPポートはRDSポートにマッピングされ得る。次いで、RDSポート番号は、異なるUDPポート番号を使用することによって、P-GW102とプロキシサーバ108との間でシグナリングされ得る。
NB-IoTデバイスは、図11を参照して説明した方法と同じ方法で、要求メッセージを準備することができ、要求メッセージは、NIDDを使用してP-GW102に転送され得る。P-GW102は、要求メッセージをプロキシサーバ108に転送し得る。送信元IPアドレスは、要求メッセージの発信元であるNB-IoTデバイス101にP-GW102が割り当てたIPアドレスである。UDP送信元ポート番号は、RDSポートを示す。次いで、プロキシサーバ108は、図11を参照して説明した方法と同じ方法で、要求メッセージを正しいアプリケーションサーバ900に転送し得る。
アプリケーションサーバ900は、要求メッセージを処理し、応答メッセージを提供し得る。応答メッセージは、使用されるIPアドレスおよびポートに基づいてプロキシサーバ108へ戻るようにルーティングされ、図11を参照して説明したように、さらにP-GW102にルーティングされ得、それに加えて、RDSポートは、上記の内容によりUDPポートに反映される。次いで、P-GW102は、応答メッセージのIPアドレスおよびポートに基づいて、応答メッセージの転送先となるNB-IoTデバイスを決定し得る。P-GW102は、UDP/IPヘッダを削除し、応答メッセージを転送し得る。使用されるRDSポートは、送信先UDPポート番号から決定される。NB-IoTデバイスにおいて、応答メッセージは、RDSポートに基づいて、デバイスで実行されている正しいアプリケーションに転送され得る。
いくつかの例において、プロキシサーバ108は、アプリケーションサーバがNB-IoTデバイスに要求メッセージを送信するために使用する静的IPv6アドレスをNB-IoTデバイスに割り当てていてもよい。代替として、プロキシサーバ108は、特定のNB-IoTデバイスをアドレス指定するときに使用するアプリケーションサーバ用のリソースを提示し得る。プロキシサーバは、図12を参照して説明したように、使用するべきRDSポートを決定する。次いで、プロキシサーバ108は、要求メッセージをP-GWに転送することができ、RDSポート番号に基づいて接続された非IPトラフィック用の専用ポートが使用される。P-GWは、UDP/IPヘッダを削除し、NIDDサービスを使用して要求メッセージをNB-IoTデバイスに転送し得る。プロキシサーバ108は、デバイスのIPアドレスおよびポート、RDSポート、ならびに場合によってはアプリケーションサーバのIPアドレスおよびポートのマッピングを格納し得る。
NB-IoTデバイスは、NIDDを使用してP-GWに送信され得る応答メッセージを提供し得る。P-GW102は、UDP/IPヘッダを追加し、応答メッセージをプロキシサーバ108に転送し得る。プロキシサーバ108は、応答を処理し得る。プロキシサーバ108は、送信元IPアドレスおよびポートに基づいて、データベースから、応答メッセージの転送先となるアプリケーションサーバのIPアドレスおよびポートを決定し得る。
圧縮されたIPトラフィックによるNIDDサービスを使用したプロキシサーバのハンドリング(デバイスタイプ1&2)
TCP/IPまたはUDP/IPヘッダの影響をなくすために、NIDDサービスを利用することは可能であるが、非IPデータをペイロードデータとして送信する代わりに、圧縮されたIPデータをペイロードとして送信することができる。圧縮されたIPデータをペイロードとして送信することにより、NB-IoTデバイス、およびプロキシサーバまたはSCEF/P-GWのいずれかは、UDP/IPまたはTCP/IP圧縮をハンドリングする必要があり得る。使用できる様々な方式、例えば、ロバストヘッダ圧縮(ROHC:Robust Header Compression)、低電力無線パーソナルエリアネットワークを介したIPv6(6LoWPAN:IPv6 over Low-Power Wireless Personal Area Networks)のための汎用ヘッダ圧縮(GHC:Generic Header Compression)、および低電力無線エリアネットワーク(LPWAN:Low-Power Wireless Area Network)静的コンテキストヘッダ圧縮(SCHC:Static Context Header Compression)が存在する。現在は、SCEFもP-GWもヘッダ圧縮方式をサポートしていない。UDP/IPまたはTCP/IPヘッダを削除することと比較してこれらの方式がどれだけ効率的かは、デバイスが送信しているデータの量に依存する可能性がある。
圧縮されたIPベースのトラフィックを使用するとき、CoAPオプションおよびRDSポートを使用せずに、複数のアプリケーションサーバのアドレス指定を解決することができる。NB-IoTデバイスとSCEF/P-GWとの間の高信頼転送には、RDSが引き続き必要になり得る。ヘッダ圧縮が公開機能104でサポートされている場合、プロキシサーバ108は、アプリケーションサーバと公開機能104との間でパケットのみを中継し得る。プロキシサーバ108はそれでも、発信パケットの送信元IPアドレスを、応答が戻る途中でプロキシサーバ108を介してルーティングされるようにセットすることができる。公開機能104がヘッダ圧縮をサポートしない場合、プロキシサーバ108は、上記に加えて、この部分も実装することができる。アプリケーションサーバからの着信パケットの場合、ソリューションは、静的IPアドレスまたはデバイスごとのリソースを使用して前述したものと同じであり得る。次いで、プロキシサーバ108は、パケットを公開機能104に送信する前にパケットを圧縮し得る。
P-GW102がヘッダ圧縮をサポートする場合、NB-IoTデバイスからアプリケーションサーバに送信されるデータをプロキシサーバ108なしで管理することが可能である。トリガメッセージのために、また場合によってはアプリケーションサーバからNB-IoTデバイスへのデータのために、プロキシサーバ108が依然として必要とされ得る。プロキシサーバ108がヘッダ圧縮を実施する場合、ソリューションは、公開機能の例の場合と同じであるが、上記のように、P-GWを介したNIDDに起因する違いがある。
CoAPとRDSの両方を使用することができ、信頼性および複数のアプリケーションサーバとの通信を解決するために様々なハイブリッドソリューションが想定されることが理解されよう。
NIDDを使用したセキュア通信
NB-IoTデバイスとアプリケーションサーバとの間のエンドツーエンドのセキュア通信は、RDSとCoAPのどちらを利用するのかに応じて様々な方法で実現され得る。RDSを使用する場合、NB-IoTデバイスとアプリケーションサーバとの間のセキュア通信のために、(プロキシサーバとアプリケーションサーバとの間でTCPとUDPのどちらのトランスポートプロトコルが使用されるかに応じて)TLSまたはDTLSを使用することが可能である。ここで、TLS/DTLSメッセージはRDS上で直接転送され得ることに留意されたい。CoAPを使用する(RDSを使用しない)とき、CoAPヘッダは、プロキシサーバ動作用に平文である可能性がある。その場合、トランスポート層でTLS/DTLSを使用できないことは明らかであり、通信をエンドツーエンドで確保するためにOSCOREを使用することが推奨され得る。次に、EDHOCを使用して、共有セキュリティコンテキストを確立するために必要な2者間で共有されるOSCOREマスターシークレットを確立することができる。メッセージを確保するために、例えばCOSEを利用するアプリケーション固有のソリューションを使用した、追加の代替手段も可能であり得る。
GSMA RSP M2M版:デバイスとの間でプロファイルダウンロードおよびプロファイル管理データを送受信する
このセクションでは、プロファイル管理サーバとの通信に関連する問題について対応する。
識別情報モジュールとプロファイル管理サーバとの間でHTTPS(またはCAT_TP)セッションが確立される通信と、NB-IoTデバイスからプロファイル管理サーバへのSMS形式のメッセージの配信との2つの異なるケースについて考える。前者はタイプ1およびタイプ2のデバイスに適用され、後者はすべてのタイプのデバイスに適用される。
HTTPS(またはCAT_TP)セッションを使用した通信
GSMA RSP M2M版は、識別情報モジュールとSM-SR(プロファイル管理サーバの一部)との間にHTTPSセッション(またはCAT_TPセッション)を確立し、これら2つのエンドポイント間でHTTPSデータ(またはCAT_TPデータ)を送信することを含む。識別情報モジュールとNB-IoTデバイスとの間の通信のために、NB-IoTデバイスにおいて、ベアラ非依存プロトコル(BIP:Bearer Independent Protocol)を使用することができる。識別情報モジュールは、BIPプロトコルを用いて、SM-SRへの通信チャネルを開閉し、データを送受信することができる。図6のステップ605でトリガメッセージが受信される前に、SM-SRがNB-IoTデバイス/識別情報モジュールに認識されない場合がある。IPベースのトラフィックを介してSM-SRと直接通信するには、TCP/IPがNB-IoTデバイスでサポートされている必要があり得る。CoAP/UDP/IPスタックをサポートする制約付きNB-IoTデバイスは、TCPをサポートしない場合があり、プロファイル管理サーバと通信するときにNIDDを介した通信を使用するように設定され得る。
RDSを使用するとき、図6のステップ606でセキュア通信を確立できるように、デバイスおよびプロキシサーバにおいて、SM-SRとの通信に使用するRDSポート番号が設定されなければならない。RDSポート番号を設定することは、D/C管理サーバ109の役割である。RDSポート番号は、例えば、図6のステップ603でD/C管理サーバ109から送信されるときに、トリガメッセージの一部として含まれ得る。ステップ603の一部として、D/C管理サーバ109はまた、プロキシサーバ108へのRDSポート番号を設定し得る。RDSポート番号に関連して、プロキシサーバ108においてUPD/IP通信とTCP/IP通信のどちらを使用すべきかに関する情報も提供され得る。
CoAPがNB-IoTデバイスからすべてのアプリケーションサーバへのすべての通信のベアラとして使用され、RDSが使用されないとき、SM-SRを使用したHTTPS(またはCAT_TP)ベースのトラフィックなどのアプリケーションサーバとの非CoAPベースの通信には、特別なソリューションが必要になる場合がある。非CoAPベースのメッセージは、プロキシサーバ108とNB-IoTデバイスとの間でCoAPペイロードとして運ばれ得る。プロキシサーバ108は、メッセージをNB-IoTデバイスからSM-SRに転送する前にCoAPヘッダを削除する必要があり得、メッセージをSM-SRからNB-IoTデバイスに転送する前にCoAPヘッダを追加し得る。この特定のプロキシサーバの挙動を適用させるために、プロキシサーバ108において、NB-IoTデバイスが書き込むことができる特別なリソースを使用することができる。例えば、Uri-Hostオプションを「プロキシ」にセットし、Uri-Portオプションを使用せず、Uri-Pathオプションを、このリソース名の後に転送メカニズム(UDPまたはTCP)、ホスト名、ポート、および応答を書き込むことができるNB-IoTデバイスでのリソース名が続くことを示すようにセットすることができる。次いで、プロキシサーバは、NB-IoTデバイスからトラフィックを転送するときに「通常の」CoAPトラフィックとは異なるUDP/TCPポート番号を使用することができ、その結果、プロキシサーバは、アプリケーションサーバからのどのトラフィックに対してCoAPヘッダを追加するべきかを認識できるようになる。プロキシサーバは、アプリケーションサーバからの応答を、アプリケーションサーバから受信したCoAP要求にリンクできるように、CoAPメッセージIDおよびCoAPトークン値を保存する必要があり得る。プロキシサーバがアプリケーションサーバからNB-IoTデバイスにデータを書き込むときに使用するプロファイルダウンロードおよびプロファイル管理データのために、NB-IoTデバイスでの特別なリソースが使用され得る。このリソースに書き込む場合、データは、識別情報モジュールを駆動するアプリケーションに送信され、アプリケーションは、BIPプロトコルを使用してデータを識別情報モジュールに転送する。
上記と同じように、HTTPSメッセージを転送するために複数のCoAPメッセージがNB-IoTデバイスからプロキシサーバの特別なリソースに送信されている場合、最初のCoAP要求メッセージ内にのみUri-HostおよびUri-Pathオプションを含めることができ、プロキシサーバは、これらのオプションなしで次のCoAP要求メッセージを同じように処理することができる。
SMS形式のメッセージの配信
NB-IoTデバイスからプロファイル管理サーバへのSMS形式のメッセージの配信には、「HTTPS(またはCAT_TP)セッションを使用した通信」というタイトルのセクションで使用されているものとは異なる専用URLを使用することができる。このURLは、D/C管理サーバ109によってプロキシサーバ108に設定され得る。RDSを使用するとき、「HTTPS(またはCAT_TP)セッションを使用した通信」で説明したものと同じタイプのソリューションが適用されるが、専用RDSポートが使用される。NB-IoTデバイスからのメッセージでこのRDSポートを使用すると、プロキシサーバ108は、このメッセージ(SMS形式のデータ)を、このポートに登録された専用URLに書き込むことになる。これは、HTTPベースのインターフェースまたは低レベルソケットインターフェースであり得る。プロキシサーバ108は、プロファイル管理サーバ107で事前登録され、プロファイル管理サーバ107は、プロキシサーバ108がメッセージを書き込むことを可能にする。SMS形式のデータは、GSMA RSP M2M版で規定されている標準メカニズムに従って保護され得る。SMS形式のデータは、メッセージの送信者を決定するための、プロファイル管理サーバ107に対する送信者識別子(例えば、EID)を含み得る。
メッセージの配信のためにCoAPが使用される例では、「HTTPS(またはCAT_TP)セッションを使用した通信」で説明したものと同じであるが、SMS形式のメッセージをハンドリングするために「HTTPS(またはCAT_TP)セッションを使用した通信」とは異なる専用のリソースを用いる。このリソースへの書き込みは、上記のRDSの場合と同じ方法でプロファイル管理サーバにメッセージを送信するようにプロキシサーバをトリガする。
GSMA RSP消費者版:デバイスとの間でプロファイルダウンロードおよびプロファイル管理データを送受信する
このセクションでは、デバイスのLPAdとプロファイル管理サーバとの間のHTTPSベースの通信について検討する。これは、タイプ1およびタイプ2のデバイスに適用される。上で説明したように、CoAP/UDP/IPスタックをサポートする制約付きNB-IoTデバイスは、TCPをサポートしない可能性があり、プロファイル管理サーバ107と通信するときにNIDDを介した通信を使用するように設定され得る。ここでは、プロキシサーバとデバイスとの間でHTTPSメッセージを転送するためにRDSまたはCoAPのいずれかが使用される場合、およびプロキシサーバがさらにプロファイル管理サーバへメッセージを転送することをハンドリングする場合の2つの場合に、「HTTPS(またはCAT_TP)セッションを使用した通信」で説明したものと同じソリューションが適用される。
IoTに適合したGSMA RSP消費者版の場合、HTTPSは、デバイスの外に移動され、プロキシサーバ108による特別なハンドリングを必要としない場合がある。
D/C管理サーバ109とNB-IoTデバイスとの間のセキュア通信には、「デバイスとの間でデータを送受信する(デバイスタイプ1&2)」に記載の技法が適用される。図7のステップ703から704および712から713、ならびに図8のステップ803から804および810から811においてD/C管理サーバ109からNB-IoTデバイス101に送信されるトリガメッセージは、保護される必要がない場合がある。
新しいMNOのサービスを使用するようにプロキシサーバを更新する
図5、図6、図7、および図8に示すように、新しいモバイルネットワークオペレータの新しいプロファイルを有効化するとき、プロキシサーバが使用するNIDDおよび監視サービスを、現在のモバイルネットワークから新しいモバイルネットワークオペレータに切り替える必要がある。上に示したように、プロキシサーバ108は、新しいネットワークへの切り替えが決定されるとすぐに、すなわち、新しいネットワークのプロファイルが無効化されようとしているときに新しいモバイルネットワークのサービスに登録するように、D/C管理サーバ109によって命令され得る。プロキシサーバ108は、一度に2つ以上のモバイルネットワークからNIDDサービスに登録され得る。NB-IoTデバイスからアプリケーションサーバへのデータの場合、プロキシサーバ108は、データがどのネットワークから来たのかという情報を格納することができ、データを同じネットワークに戻すようにルーティングすることができる。しかしながら、アプリケーションサーバからNB-IoTデバイスへのデータの場合、プロキシサーバ108は、NB-IoTデバイスが現在どのネットワークにあるかを認識する必要があり得る。いくつかの例において、プロキシサーバ108は、新しいネットワークからデータを受信するまで現在のネットワークに留まり、その後、すべてのトラフィックを新しいネットワークに切り替える。D/C管理サーバ109が(例えば、プロファイル管理サーバ107から)プロファイルの有効化が成功したとの確認応答を受信すると、これは、前のネットワークのサービスから登録解除することができるプロキシサーバ108に通知され得る。
異なるモバイルネットワークを備えた同じNB-IoTデバイスに対して、異なる外部識別子(例えば、MSISDN)が使用される場合がある。この例では、プロキシサーバ108に新しいモバイルネットワークのサービスに登録するように命令するときに、新しい外部識別子は、D/C管理サーバ109によってプロキシサーバにあるように設定され得る。次いで、プロキシサーバ108は、プロファイル間の切り替えが完了するまで2つの外部識別子間を変換することができ、完了した場合、古い外部識別子は無視され得る。
デバイス/コネクティビティ(D/C)管理サーバと統合されたプロキシサーバ
いくつかの例において、プロキシサーバ108とD/C管理サーバ109は、同一のサーバである。したがって、D/C管理サーバ109は、NB-IoTデバイス、およびそれらが通信するアプリケーションサーバ、ならびにこれらのアプリケーションサーバとの通信においてプロキシサーバ108がNB-IoTデバイスを支援していることについての知識を有し得る。
図13は、処理回路(または論理)1301を含むプロキシサーバ1300を示す。処理回路1301は、プロキシサーバ1300の動作を制御し、プロキシサーバ1300(例えば、プロキシサーバ108)に関連して本明細書に記載されている方法を実施することができる。処理回路1301は、本明細書に記載の方式でプロキシサーバ1300を制御するように設定またはプログラムされた1つまたは複数のプロセッサ、処理ユニット、マルチコアプロセッサまたはモジュールを備えることができる。特定の実装形態において、処理回路1301は、プロキシサーバ1300に関連して本明細書に記載されている方法の個々のまたは複数のステップを実行するように各々設定された、または実行するための複数のソフトウェアおよび/またはハードウェアモジュールを備えることができる。
簡単に言えば、プロキシサーバ1300の処理回路1301は、トリガメッセージをNB-IoTデバイスに配信するよう求める要求を受信することであって、要求がデバイス識別子を含む、要求を受信することと、受信したデバイス識別子に基づいて外部識別子を決定することと、外部識別子を使用してトリガメッセージをNB-IoTデバイスに配信することとを行うように設定される。
いくつかの実施形態において、プロキシサーバ1300は、任意選択として、通信インターフェース1302を備え得る。プロキシサーバ1300の通信インターフェース1302は、他の仮想ノードなどの他のノードとの通信に使用することができる。例えば、プロキシサーバ1300の通信インターフェース1302は、要求、リソース、情報、データ、信号、もしくは同様のものを他のノードに送信するように、かつ/または他のノードから受信するように設定され得る。プロキシサーバ1300の処理回路1301は、要求、リソース、情報、データ、信号、もしくは同様のものを他のノードに送信するように、かつ/または他のノードから受信するように、プロキシサーバ1300の通信インターフェース1302を制御するように設定され得る。
任意選択として、プロキシサーバ1300は、メモリ1303を備え得る。いくつかの実施形態において、プロキシサーバ1300のメモリ1303は、プロキシサーバ1300に関連して本明細書に記載されている方法を実行するためにプロキシサーバ1300の処理回路1301によって実行され得るプログラムコードを記憶するように設定され得る。代替として、または追加として、プロキシサーバ1300のメモリ1303は、本明細書で記載の任意の要求、リソース、情報、データ、信号、または同様のものを記憶するように設定され得る。プロキシサーバ1300の処理回路1301は、本明細書に記載の任意の要求、リソース、情報、データ、信号、または同様のものを記憶するように、プロキシサーバ1300のメモリ1303を制御するように設定され得る。
図14は、処理回路(または論理)1401を備えるデバイスコネクティビティ(D/C)管理サーバ1400を示す。処理回路1401は、D/C管理サーバ1400の動作を制御し、D/C管理サーバ1400(例えば、D/C管理サーバ108)に関連して本明細書に記載されている方法を実施することができる。処理回路1401は、本明細書に記載の方式でD/C管理サーバ1400を制御するように設定またはプログラムされた1つまたは複数のプロセッサ、処理ユニット、マルチコアプロセッサまたはモジュールを備えることができる。特定の実装形態において、処理回路1401は、D/C管理サーバ1400に関連して本明細書に記載されている方法の個々のまたは複数のステップを実行するように各々設定された、または実行するための複数のソフトウェアおよび/またはハードウェアモジュールを備えることができる。
簡単に言えば、D/C管理サーバ1400の処理回路1401は、トリガメッセージをNB-IoTデバイスに配信するよう求める要求をプロキシサーバに送信するように設定され、要求は、デバイス識別子およびトリガメッセージを含む。
いくつかの実施形態において、D/C管理サーバ1400は、任意選択として、通信インターフェース1402を備え得る。D/C管理サーバ1400の通信インターフェース1402は、他の仮想ノードなどの他のノードとの通信に使用することができる。例えば、D/C管理サーバ1400の通信インターフェース1402は、要求、リソース、情報、データ、信号、もしくは同様のものを他のノードに送信するように、かつ/または他のノードから受信するように設定され得る。D/C管理サーバ1400の処理回路1401は、要求、リソース、情報、データ、信号、もしくは同様のものを他のノードに送信するように、かつ/または他のノードから受信するように、D/C管理サーバ1400の通信インターフェース1402を制御するように設定され得る。
任意選択として、D/C管理サーバ1400は、メモリ1403を備え得る。いくつかの実施形態において、D/C管理サーバ1400のメモリ1403は、D/C管理サーバ1400に関連して本明細書に記載されている方法を実行するためにD/C管理サーバ1400の処理回路1401によって実行され得るプログラムコードを記憶するように設定され得る。代替として、または追加として、D/C管理サーバ1400のメモリ1403は、本明細書に記載の任意の要求、リソース、情報、データ、信号、または同様のものを記憶するように設定され得る。D/C管理サーバ1400の処理回路1401は、本明細書に記載の任意の要求、リソース、情報、データ、信号、または同様のものを記憶するように、D/C管理サーバ1400のメモリ1403を制御するように設定され得る。
図15は、処理回路(または論理)1501を含む狭帯域モノのインターネット(NB-IoT)デバイス1500を示す。処理回路1501は、NB-IoTデバイス1500の動作を制御し、NB-IoTデバイス1500(例えば、NB-IoTデバイス108)に関連して本明細書に記載されている方法を実施することができる。処理回路1501は、本明細書に記載の方式でNB-IoTデバイス1500を制御するように設定またはプログラムされた1つまたは複数のプロセッサ、処理ユニット、マルチコアプロセッサまたはモジュールを備えることができる。特定の実装形態において、処理回路1501は、NB-IoTデバイス1500に関連して本明細書に記載されている方法の個々のまたは複数のステップを実行するように各々設定された、または実行するための複数のソフトウェアおよび/またはハードウェアモジュールを備えることができる。
簡単に言えば、NB-IoTデバイス1500の処理回路1501は、プロキシサーバによって配信されたトリガメッセージを受信するように設定される。
いくつかの実施形態において、NB-IoTデバイス1500は、任意選択として、通信インターフェース1502を備え得る。NB-IoTデバイス1500の通信インターフェース1502は、他の仮想ノードなどの他のノードとの通信に使用することができる。例えば、NB-IoTデバイス1500の通信インターフェース1502は、要求、リソース、情報、データ、信号、もしくは同様のものを他のノードに送信するように、かつ/または他のノードから受信するように設定され得る。NB-IoTデバイス1500の処理回路1501は、要求、リソース、情報、データ、信号、もしくは同様のものを他のノードに送信するように、かつ/または他のノードから受信するように、NB-IoTデバイス1500の通信インターフェース1502を制御するように設定され得る。
任意選択として、NB-IoTデバイス1500は、メモリ1503を備え得る。いくつかの実施形態において、NB-IoTデバイス1500のメモリ1503は、NB-IoTデバイス1500に関連して本明細書に記載されている方法を実行するためにNB-IoTデバイス1500の処理回路1501によって実行され得るプログラムコードを記憶するように設定され得る。代替として、または追加として、NB-IoTデバイス1500のメモリ1503は、本明細書に記載の任意の要求、リソース、情報、データ、信号、または同様のものを記憶するように設定され得る。NB-IoTデバイス1500の処理回路1501は、本明細書に記載の任意の要求、リソース、情報、データ、信号、または同様のものを記憶するように、NB-IoTデバイス1500のメモリ1503を制御するように設定され得る。
上記の実施形態が本発明を限定ではなく例示すること、および当業者であれば、添付の特許請求の範囲から逸脱することなく多くの代替の実施形態を設計できることに留意されたい。「含む(comprising)」という語は、特許請求の範囲に記載されたもの以外の要素またはステップの存在を排除するものではなく、「1つの(aまたはan)」は複数を排除するものではなく、単一のプロセッサまたは他のユニットは、特許請求の範囲に記載のいくつかのユニットの機能を果たし得る。特許請求の範囲におけるいずれの参照記号もその範囲を制限するとは解釈しないものとする。
本明細書に記載の実施形態は、狭帯域モノのインターネット(NB-IoT:narrow band Internet of Things)デバイス内の識別情報モジュールへのプロファイルのリモート管理を可能にするための方法および装置に関する。プロファイルのリモート管理は、プロファイルをNB-IoTデバイスにプロビジョニングすること、および/または既存のプロファイルを更新もしくは調整することを含み得る。
加入者識別情報モジュール(SIM:Subscriber Identity Module)カードは、1991年に商業的に展開され、それ以来、モバイルネットワークへのセキュアで識別可能な認証済みのアクセスを保証してきた。消費者にとってのSIMフォームファクタの別の利点は、連絡先がSIMカード上のメモリに記憶されているため、SIMカードをデバイス間で入れ替えて、名前および番号を失うことなくハードウェアをアップグレードできることであった。SIMカードを使用すると、消費者は自分のデバイスを別のモバイルオペレータに容易に切り替えられることにもなる。
SIMは、導入以来、新世代のセルラ技術ごとにサイズが縮小され、能力が向上している。しかしながら、新興のマシンツーマシン(M2M:machine-to-machine)およびモノのインターネット(IoT:Internet of Things)市場では、異なるサービスパラダイムがあり、時として非常に離れた場所にある大規模なIoTデバイスフリートのSIMを物理的に取り外すことおよび入れ替えることは、コストがかかり、煩雑になる。
ほとんどの企業にとっての課題は、長くてしばしば複雑なサプライチェーンにおける様々な地点で、SIMカードとデバイスとの組合せが発生することである。企業は、様々な市場の様々な(モバイル)オペレータを使用しており、可能な場合には、オペレータは、他のオペレータとの契約を利用してシームレスなグローバルコネクティビティを提供する。しかしながら、製品を異なる市場に販売する、または異なるオペレータネットワーク上で運用するフリートで使用する必要がある場合、新しいモバイルネットワークオペレータ(MNO)によって発行されたすべてのSIMカードについて、新しいコストのかかるロジスティクス管理およびライフサイクル管理の問題が生じる可能性がある。さらに、過去にデバイスの耐用期間中にモバイルオペレータを変更する必要があった場合、これは、履歴的には常に、SIMカードを変更していることを意味し、追加のロジスティクスおよびコストの問題が生じていた。
このますます厳しくなる市場のニーズにより、リモートでプログラムされた識別情報モジュール、例えば、組込みSIM(eSIM:embedded SIM)または組込みユニバーサル集積回路カード(eUICC:Embedded Universal Integrated Circuit Card)というソリューションが生まれた。eUICCは、小型の電子チップであり、製造時にデバイスの回路基板に挿入およびはんだ付けされる。eUICCのこの設定は、MFF2というフォームファクタとして知られており、MFF2では、SIMカードホルダーが不要であり、その結果、SIMに必要なスペースの量が削減される。
eUICCは、モバイルオペレータによって提供される初期のブートストラッププロファイルを用いて製造中にプログラムされ得る。初期のブートストラッププロファイルは、eUICCに運用プロファイルをリモートでプロビジョニングできるように初期のコネクティビティを提供し得る。これは、SIMに接続されている初期のネットワークオペレータを変更および再割り当てすることが可能であることを意味する。代替として、初期のコネクティビティは、動作プロファイルをリモートでプロビジョニングできる何らかの他の無線インターフェースを介して(例えば、コンピュータなどの別のデバイスを介して)実現され得る。この再プログラミングおよびプロビジョニングは、物理的な変更を必要とせずにオーバージエアで実行することができ、これは、企業に大きな利益をもたらす可能性がある。
eUICCの標準は、モバイルネットワークオペレータの国際協会である汎欧州デジタル移動電話方式協会(GSMA:Global System for Mobile Communications Association)によって、最初はマシンツーマシン(M2M)用途向けに、さらに最近ではスマートフォンおよびウェアラブル機器などの消費者用途向けに確立された。
相手先商標製品製造業者(OEM:Original Equipment Manufacturer)にとってこのeUICC技術の唯一最大の利点は、このeUICC技術がSIMを単一SKU(Stock Keeping Unit:在庫管理単位)に変換することである。言い換えると、製造中にeUICCを他の構成要素と同様にデバイスに挿入し、その後、デバイスを世界のどこに出荷するかによって、後で適切なネットワークオペレータプロファイルを用いてeUICCをプロビジョニングすることができる。この技術は、生産プロセスを合理化し、デバイスのライフサイクル全体のコストを削減するとともに、IoTデバイスでのセルラコネクティビティのより広範な使用を妨げる障害を軽減する。リモートでプロビジョニングされた識別情報モジュールを使用する単一SKUビジネスモデルにより、企業は、自社のグローバル製品に共通のeUICCを1つだけ使用して、コネクテッド製品のロジスティクス管理およびライフサイクル管理を簡素化することができる。
eUICCはまた、デバイスの耐用期間の間、任意の単一のオペレータによる「コネクティビティランサム」に拘束されることに対する保証ポリシーを提供する。eUICCプロセスのロジスティクスは単純であり、例えば、企業は、契約期間の終了時に必要に応じてオペレータを変更できる権利を含む初期契約をモバイルオペレータと締結する。その後、企業は、契約期間の終了時に、サービスおよび価格の観点から代替のコネクティビティの提案を柔軟に探し求めることができ、場合によってはオペレータを変更する保証オプションを利用することができる。
自動車市場は最も先進的なIoT市場の1つであり、自動車産業にとっての現在の要件は、すべてのコネクテッドカーにeUICCを搭載しなければならないことである。例えば、欧州では、eCall法の施行により、すべての新車にeUICCを採用することが義務化されている。しかしながら、例えば、ユーティリティ産業、スマート製造、エネルギー産業、輸送&ロジスティクスなど、グローバル産業全体においても、eUICCの利点が見られ、急速に採用されている。eUICCリモートSIMプロビジョニングは、IoTのユースケース、デバイスメーカー、サービスプロバイダ、およびモバイルネットワークオペレータにとってますます重要になっている。
狭帯域IoT(NB-IoT)は、モノのインターネット(IoT)の要件に対応する新しい3GPP無線技術標準である。この技術は、屋内カバレッジの向上、多数の低スループットデバイスのサポート、低遅延感度、超低デバイスコスト、低デバイス消費電力、および最適化されたネットワークアーキテクチャを提供する。NB-IoTは、低電力ワイドエリアコネクティビティ市場の急速な拡大に対応するために、3GPPによってリリース13で指定された、新しいセルラ無線アクセス技術(現在は公式の5G技術の一部)である。モバイル産業は現在、アプリケーションサービスプロバイダ、デバイスメーカーなどの顧客が自社のサービスを世界中に展開して運用できるようにするグローバルカバレッジソリューションとしてNB-IoTを確立している。
国際特許第2019/136044号は、加入者識別情報モジュールおよび公衆陸上移動体ネットワーク情報の交換を通じて管理されるモノのインターネットおよび同様のデバイスのネットワーク登録を開示している。
いくつかの実施形態によれば、プロキシサーバにおいて、3GPPによる狭帯域モノのインターネット(NB-IoT)デバイス内の識別情報モジュールにおけるプロファイルのリモート管理を可能にするための方法が提供され、プロキシサーバは、各々が1つまたは複数のそれぞれのNB-IoTデバイスのうちのそれぞれ1つに関連付けられた1つまたは複数の外部識別子のデータベースへのアクセスを有するように設定され、1つまたは複数の外部識別子は各々、コアネットワーク内の公開機能を介して1つまたは複数のNB-IoTデバイスのうちのそれぞれ1つをアドレス指定するために使用される。方法は、トリガメッセージをNB-IoTデバイスに配信するよう求める要求を受信することであって、要求がNB-IoTデバイスのデバイス識別子を含む、要求を受信することと、受信したデバイス識別子に基づいて、データベースからNB-IoTデバイスの外部識別子を決定することと、非IPデータ配信(NIDD)サービスを使用してNB-IoTデバイスに転送するために、トリガメッセージを外部識別子とともに公開機能に送信することであって、トリガメッセージが、プロファイル管理サーバからプロファイルをダウンロードするようNB-IoTデバイスをトリガするように設定されたプロファイルダウンロードトリガメッセージ、またはプロファイル管理動作を実行するようNB-IoTデバイス内の識別情報モジュールをトリガするように設定されたプロファイル管理トリガメッセージのいずれかを含む、トリガメッセージを送信することとを含む。
いくつかの実施形態によれば、3GPPによる狭帯域モノのインターネット(NB-IoT)デバイス内の識別情報モジュールにおけるプロファイルのリモート管理を可能にするためプロキシサーバが提供され、プロキシサーバは、各々が1つまたは複数のそれぞれのNB-IoTデバイスのうちのそれぞれ1つに関連付けられた1つまたは複数の外部識別子のデータベースへのアクセスを有するように設定され、1つまたは複数の外部識別子は各々、コアネットワーク内の公開機能を介して1つまたは複数のNB-IoTデバイスのうちのそれぞれ1つをアドレス指定するために使用される。プロキシサーバは、トリガメッセージをNB-IoTデバイスに配信するよう求める要求を受信することであって、要求がNB-IoTデバイスのデバイス識別子を含む、要求を受信することと、受信したデバイス識別子に基づいて、データベースからNB-IoTの外部識別子を決定することと、非IPデータ配信(NIDD)サービスを使用してNB-IoTデバイスに転送するために、トリガメッセージを外部識別子とともに公開機能に送信することであって、トリガメッセージが、プロファイル管理サーバからプロファイルをダウンロードするようNB-IoTデバイスをトリガするように設定されたプロファイルダウンロードトリガメッセージ、またはプロファイル管理動作を実行するようNB-IoTデバイス内の識別情報モジュールをトリガするように設定されたプロファイル管理トリガメッセージのいずれかを含む、トリガメッセージを送信することとを行うように設定された処理回路を備える。
いくつかの実施形態によれば、狭帯域モノのインターネット(NB-IoT)デバイス内の識別情報モジュールにおけるプロファイルのリモート管理を可能にするための、デバイスコネクティビティ(D/C)管理サーバが提供される。D/C管理サーバは、トリガメッセージをNB-IoTデバイスに配信するよう求める要求をプロキシサーバ(108)に送信するように設定された処理回路を備え、要求はデバイス識別子およびトリガメッセージを含む。
いくつかの実施形態によれば、狭帯域モノのインターネット(NB-IoT)デバイス内の識別情報モジュールにおけるプロファイルのリモート管理を可能にするためのNB-IoTデバイスが提供される。NB-IoTデバイスは、プロキシサーバによって配信されたトリガメッセージを受信するように設定された処理回路を備える。
次に、本開示の実施形態をよりよく理解し、その実施形態がどのように実行され得るかを示すために、添付の図面をほんの一例として参照する。
1つまたは複数の異なるタイプのNB-IoTデバイス内の識別情報モジュールにおいてプロファイルを管理するために使用され得る複数のノードを示す、ネットワーク100のブロック図である。
プロキシサーバにおいて、NB-IoTデバイス内の識別情報モジュールのためにプロファイルのリモート管理を可能にするための方法を示す図である。
狭帯域モノのインターネット(NB-IoT)デバイスにおいて、NB-IoTデバイス内の識別情報モジュールにおけるプロファイルのリモート管理を可能にするための方法を示す図である。
図1および図2の方法の例をより詳細に示すシグナリング図である。
図1および図2の方法の例をより詳細に示すシグナリング図である。
いくつかの実施形態によるプロファイルプロビジョニングプロセスの一例を示す図である。
いくつかの実施形態によるプロファイルプロビジョニングプロセスの一例を示す図である。
図5に示すシグナリング図の一例を示す図である。
図5に示すシグナリング図の一例を示す図である。
図5に示すシグナリング図の一例を示す図である。
図5に示すシグナリング図の一例を示す図である。
図5のプロファイルダウンロードおよびプロファイル有効化のフローの一例を示す図であり、フローは、GSMA RSPの適合された消費者版用に再描画されている。
図5のプロファイルダウンロードおよびプロファイル有効化のフローの一例を示す図であり、フローは、GSMA RSPの適合された消費者版用に再描画されている。
公開機能を介して、NIDDを使用してNB-IoTデバイスからアプリケーションサーバにCoAP要求を送信することを示す図である。
公開機能を介して、NIDDを使用してNB-IoTデバイスからアプリケーションサーバにCoAP要求を送信することを示す図である。
公開機能を介して、NIDDを使用してアプリケーションサーバ900からNB-IoTデバイス101にCoAP要求を送信することを示す図である。
公開機能を介して、NIDDを使用してアプリケーションサーバ900からNB-IoTデバイス101にCoAP要求を送信することを示す図である。
RDSが使用される場合、公開機能を介して、NIDDを使用してNB-IoTデバイスからアプリケーションサーバに要求メッセージを送信することを示す図である。
RDSが使用される場合、公開機能を介して、NIDDを使用してNB-IoTデバイスからアプリケーションサーバに要求メッセージを送信することを示す図である。
RDSが使用される場合、公開機能104を介して、NIDDを使用してアプリケーションサーバからNB-IoTデバイスに要求メッセージを送信することを示す図である。
RDSが使用される場合、公開機能104を介して、NIDDを使用してアプリケーションサーバからNB-IoTデバイスに要求メッセージを送信することを示す図である。
処理回路(または論理)を備えるプロキシサーバを示す図である。
処理回路(または論理)を備えるデバイスコネクティビティ(D/C)管理サーバを示す図である。
処理回路(または論理)を備える狭帯域モノのインターネット(NB-IoT)デバイスを示す図である。
全体として、本明細書で使用される用語はすべて、異なる意味が明確に与えられている、かつ/またはその用語が使用される文脈から暗示されない限り、関連する技術分野におけるその用語の通常の意味に従って解釈されるべきである。要素、装置、構成要素、手段、ステップなどについての言及はすべて、特に明記しない限り、要素、装置、構成要素、手段、ステップなどの少なくとも1つの事例について言及するものとして公然と解釈されるべきである。本明細書に開示する任意の方法のステップは、ステップが別のステップに後行もしくは先行するものとして明示的に記載されている、かつ/またはステップが別のステップに後行もしくは先行しなければならないことが暗黙的に示されている場合を除き、開示された通りの順序で実行される必要はない。本明細書に開示する実施形態の特徴はいずれも、必要に応じて任意の他の実施形態に適用され得る。同様に、実施形態の利点はいずれも、任意の他の実施形態に適用することができ、逆もまた同様である。添付した実施形態の他の目的、特徴、および利点は、以下の説明から明らかになろう。
限定ではなく説明を目的とした具体的な実施形態または例などの具体的な詳細を以下に示す。当業者には、これらの具体的な詳細とは別に他の例が採用され得ることが理解されよう。いくつかの事例では、不要な詳細によって説明が不明瞭にならいように、よく知られた方法、ノード、インターフェース、回路、およびデバイスの詳細な説明は省略されている。当業者は、記載された機能が、ハードウェア回路(例えば、特殊な機能を実行するために相互接続されたアナログおよび/もしくはディスクリート論理ゲート、ASIC、PLAなど)を使用して、かつ/または1つまたは複数のデジタルマイクロプロセッサもしくは汎用コンピュータと組み合わせたソフトウェアプログラムおよびデータを使用して、1つまたは複数のノードに実装され得ることを理解するであろう。エアインターフェースを使用して通信するノードは、適切な無線通信回路も有する。また必要に応じて、当技術はさらに、本明細書に記載の技法をプロセッサに実行させる適切なコンピュータ命令セットを含むソリッドステートメモリ、磁気ディスク、または光ディスクなどの任意の形式のコンピュータ可読メモリ内で完全に具現化されると見なされ得る。
ハードウェア実装は、限定されないが、デジタル信号プロセッサ(DSP)ハードウェアと、縮小命令セットプロセッサと、特定用途向け集積回路(ASIC:application specific integrated circuit)および/またはフィールドプログラマブルゲートアレイ(FPGA)を含むがこれらに限定されないハードウェア(例えば、デジタルもしくはアナログ)回路と、(必要に応じて)そのような機能を実行できるステートマシンとを含み得るか、または包含し得る。
eUICCなどの識別情報モジュールへのプロファイルのリモートプロビジョニングは、GSMA技術の成熟度に依存し得るが、これは利点でもあり制限でもある。リモートプロビジョニングアクションのトリガは、数十年前から存在しているショートメッセージサービス(SMS)およびハイパーテキスト転送プロトコル(HTTP)技術に基づいているが、常に信頼できるとは限らず、特にローミング中の場合、顧客は通常、リモートプロビジョニングをトリガして、新しいローカルMNOプロファイルをeUICC上でダウンロードおよび有効化する必要があり、トリガの配信能力が制限される。例えば、ローミングSMSの商用問題またはIoTコンテキスト内の技術的な問題に起因して、最初のSMSトリガが配信に失敗する場合である。
その結果として、eUICCが、新しいプロファイルのダウンロードを開始すること、および/またはあるプロファイルから別のプロファイルに切り替えることが可能になるには最初のSMSトリガを受信する必要があるため、eUICCリモートプロビジョニングが失敗する。SMSの技術的な制限に加えて、すべてのSMSに追加コストがかかり、現在は各eUICCリモートプロビジョニングフローに合計4つのSMSが必要であるので、SMSの使用には商業上の問題もある。したがって、SMSを使用する場合、現在のeUICCリモートプロビジョニングソリューションを多数のIoTデバイスに合わせてスケーリングすることが困難になる。
ほとんどのNB-IoTデバイスは、小さいデータパケットを送受信するようにのみ設定され得る。例えば、NB-IoTデバイスは、データパケットがインターネットプロトコル(IP)ベースのプロトコルを介して送信される場合に、IPプロトコルのオーバーヘッドが、交換される実際のデータをはるかに上回り得るほどに、小さいデータパケットを送信するように設定され得る。このようなNB-IoTデバイスは、非IPコントロールプレーンベースのデータ配信方法、すなわちNASベースの非IPデータ配信(NIDD:Non-IP Data Delivery)を使用してサーバとデータを交換するように設定され得る。
制約付きNB-IoTデバイスに対してSMSおよびHTTPがサポートされていない可能性があるため、既存のeUICCリモートプロビジョニング方法は大半のNB-IoTデバイスに適していない可能性があり、したがって、プロファイルのダウンロードおよびプロファイルの切り替えが正常に実行されない可能性がある。
しかしながら、世界のIoT市場では、所有するNB-IoTデバイスにeUICC技術を組み合わせて、低コストでグローバルな広域コネクティビティを実現しようと模索している大口顧客が多い。したがって、現在NB-IoTに対してSMS、HTTP、およびローミングがサポートされていなくてもNB-IoTネットワーク内で機能するとともにNB-IoTデバイスによって機能することができる、新しいeUICCリモートプロビジョニングソリューションが求められている。
したがって、本明細書に記載の実施形態は、プロキシサーバを利用して、NB-IoTデバイス内の識別情報モジュール(例えば、eUICC)へのプロファイルのリモート管理を可能にする。
本明細書に記載の実施形態は、GSMAリモートSIMプロビジョニング(RSP:remote SIM provisioning)標準に依存する制約付きNB-IoTデバイスのためのeUICCリモートプロビジョニングを可能にすることを提案する。このソリューションは、コアネットワーク内の公開機能(例えば、サービス能力公開機能(SCEF:Service Capability Exposure Function)またはネットワーク公開機能(NEF:Network Exposure Function))によって提供される非IPデータ配信(NIDD)サービスを使用して、プロファイル管理サーバとIoTデバイスとの間で、プロファイルダウンロードメッセージおよびプロファイル管理メッセージを配信する。NIDDサービスを使用すると、デバイスでのプロファイル管理動作をトリガすることが効果的に可能になり、制約付きIoTデバイスによって送受信されるビット数を低減することもできる。
プロファイル管理サーバとNB-IoTネットワークの公開機能の間でプロキシサーバを使用して、プロファイル管理サーバでの3GPP固有のネットワーク関連機能の知識を省くとともに、IoTデバイスが複数のアプリケーションサーバと同時に通信できるようにすることができる。デバイス/コネクティビティ(D/C)管理サーバは、ビジネスプロセスを制御し、企業顧客とモバイルネットワークオペレータとの両方と対話し、エンドツーエンド通信フロー/設定を可能にし、eUICCリモートプロビジョニング手順を開始および管理し得る。
本明細書に記載の実施形態は、NB-IoTデバイスが、ローカルモバイルネットワークオペレータから新しいプロファイルをダウンロードして有効化するために、eUICCで(グローバルモバイルネットワークオペレータからの)事前にプロビジョニングされたプロファイルを使用する訪問ネットワークを介してプロファイル管理サーバに接続できるようなNB-IoTに対してサポートされているローミングに依存し得る。現在、オペレータによって、NB-IoTローミングのビジネスセットアップについての合意を試みる取り組みが進行中であり、ここではそのようなセットアップが合意されているものと仮定する。
本明細書に記載の実施形態は、配信技術およびデバイスタイプの様々なセットアップに対処し、ソリューションの詳細は本質的に異なるが共通の手法を共有している様々な例について検討する。セットアップにおける違いにより、目標を達成するためにソリューションが非自明な方法で作成される場合がある。一実施形態では、GSMA RSP M2M版によるリモートプロビジョニングが使用される。この場合、NB-IoTネットワークの公開機能NIDDサービスを使用して、現在はプロファイル管理サーバとIoTデバイスのeUICCとの間でSMSとして送信される、プロファイルダウンロードメッセージおよびプロファイル管理メッセージを配信することができる。NIDDソリューションは、制約付きIoTデバイスとプロファイル管理サーバとの間で他の(SMS以外の)プロファイルダウンロードおよびプロファイル管理関連のメッセージを転送する場合にも使用することができ、これにより、制約付きIoTデバイスによって送受信されるビット数が削減される。NIDDサービスを制約付きアプリケーションプロトコル(CoAP:Constrained Application Protocol)または高信頼データサービス(RDS:Reliable Data Service)プロトコルと組み合わせて使用すると、デバイスがHTTP/TCP/IPスタックをサポートしていない場合でも、デバイスとプロファイル管理サーバとの間でプロキシサーバを介してHTTPSメッセージを信頼できる方法で交換することができる。
いくつかの実施形態において、GSMA RSP消費者版によるリモートプロビジョニングが使用される。ここでは、D/C管理サーバは、NB-IoTデバイス内のローカルプロファイルアシスタント(LPAd)を介して、プロファイルダウンロードおよびプロファイル管理動作をリモートで制御し得る。この場合、公開機能NIDDサービスを使用して、LPAdでのプロファイルダウンロードおよびプロファイル管理動作のトリガ、ならびにNB-IoTデバイスとプロファイル管理サーバおよびD/C管理サーバとの間でのプロファイルダウンロードおよびプロファイル管理に関連するメッセージの転送を行うことができ、これにより、NB-IoTデバイスによって送受信されるビット数が削減される。いくつかの例では、IoTに適合したGSMA RSP消費者版によるリモートプロビジョニングが検討され、公開機能NIDDサービスは、同様の方法でソリューションを提供する。
本明細書に記載の実施形態は、デバイスがGSMAリモートSIMプロビジョニング標準をサポートする統合UICC(iUICC:integrated UICC)を備えた統合SIM(iSIM)ソリューションにも適用される。本明細書に記載の実施形態は、GSMAリモートSIMプロビジョニング標準をサポートする(取り外し可能な)UICCまたはETSIスマートセキュアプラットフォーム(SSP)にも適用され得る。
本明細書に記載の実施形態は、既存のGSMA RSP標準、具体的にはM2M版を、GSMA RSP準拠のSM-SRで必要とされる最小限の変更のみで、標準M2M準拠のeUICCを備えたNB-IoTデバイスにも使用できるようにする。SMSがNB-IoTネットワークによってサポートされていないという問題は、公開機能NIDDサービスを使用したデバイスとの通信によって回避される。公開機能およびプロキシサーバを使用すると、制約付きIoTデバイスがHTTP/TCP/IPスタックをサポートしていない場合の問題も解決される。NIDD技術を使用すると、送信されるビット数を最小限に抑えることができ、したがって、制約付きデバイスの消費電力も削減することができる。
図1は、1つまたは複数の異なるタイプのNB-IoTデバイス内の識別情報モジュールにおいてプロファイルを管理するために使用され得る複数のノードを示す、ネットワーク100のブロック図である。
NB-IoTデバイスは、セルラNB-IoTモデムおよび識別情報モジュール(例えば、eUICC)を備えると見なされ得る。識別情報モジュールは、GSMAによるリモートSIMプロビジョニングをサポートするように設定され得、リモートでのプロファイルダウンロードおよびプロファイル管理のための資格情報を備え得る。
NB-IoTネットワークは、NB-IoTデバイスが、ローカルモバイルネットワークオペレータから新しいプロファイルをダウンロードして有効化するために、eUICCで(グローバルモバイルネットワークオペレータからの)事前にプロビジョニングされたプロファイルを使用して訪問ネットワークを介して接続できるように、ローミングをサポートし得る。
具体的には、図1は、第1のNB-IoTデバイス101aを示す。NB-IoTデバイス101aは、第1のタイプのNB-IoTデバイスを含む。第1のタイプのNB-IoTデバイスは、アプリケーションサーバとの通信のために公開機能104(例えば、4Gの場合はSCEF、または5Gの場合はNEF)を介して3GPP非IPデータ配信(NIDD)メカニズムを使用するデバイスを含む。この第1のタイプのNB-IoTデバイスは、非IPデバイス(例えば、伝送制御プロトコル/インターネットプロトコル(TCP/IP:Transmission Control Protocol/Internet Protocol)もしくはユーザデータグラムプロトコル/IP UDP/IPプロトコルスタックをサポートしないデバイス)、またはIPベースのデバイス(例えば、TCP/IPもしくはUDP/IPプロトコルスタックのいずれかをサポートしているが、例えば、送信されるビット数を最小限に抑える(したがって、デバイスの電力消費を削減し得る)ためであるかどうかに関わらず、NIDDを使用しているデバイス)のいずれかを含み得る。
ネットワーク100は、第2のNB-IoTデバイス101bをさらに含む。NB-IoTデバイス101bは、第2のタイプのNB-IoTデバイスを含む。第2のタイプのNB-IoTデバイスは、アプリケーションサーバとの通信のためにパケットゲートウェイ(P-GW)102を介して3GPP非IPデータ配信(NIDD)メカニズムを使用するデバイスを含む。この第2のタイプのNB-IoTデバイスは、非IPデバイス(例えば、伝送制御プロトコル/インターネットプロトコル(TCP/IP)もしくはユーザデータグラムプロトコル/IP UDP/IPプロトコルスタックをサポートしないデバイス)、またはIPベースのデバイス(例えば、TCP/IPもしくはUDP/IPプロトコルスタックのいずれかをサポートしているが、例えば、送信されるビット数を最小限に抑える(したがって、デバイスの電力消費を削減し得る)ためであるかどうかに関わらず、NIDDを使用しているデバイス)のいずれかを含み得る。
ネットワーク100は、第3のNB-IoTデバイス101cをさらに含む。第3のNB-IoTデバイス101cは、第3のタイプのNB-IoTデバイスを含む。第3のタイプのNB-IoTデバイスは、NB-IoT IPベースのサービスを使用してアプリケーションサーバと通信するように設定されたIPベースのデバイスを含む。IPベースのトラフィックは、例えば、コントロールプレーンシグナリングを介して、例えば、モビリティ管理エンティティ(MME:mobility management entity)に、さらにサービングゲートウェイ(S-GW)103に送信されるか、または専用のユーザプレーンベアラを介して直接S-GWに、その後さらにP-GW102に送信され得る。
ネットワーク100は、公開機能104をさらに含む。この例では、公開機能104は、アプリケーションサーバによって使用するためのRESTful APIを使用して3GPPセルラネットワークのサービスおよび能力を公開するように設定され得るサービス能力公開機能(SCEF)を含む。しかしながら、公開機能104が、同様に5Gコアネットワークアーキテクチャによるネットワーク公開機能(NEF:Network Exposure Function)も含み得ることが理解されよう。公開機能104によって公開されるサービスは、非IPデータ配信(NIDD)サービスおよび監視サービスを含み得る。アプリケーションサーバは、例えば、上記の第1のタイプのNB-IoTデバイスと通信するためにNIDDサービスを利用し得る。
例えば、アプリケーションサーバは、NIDDサービスを使用して第1のNB-IoTデバイス101aと通信し得る。NIDDを使用するとき、第1のNB-IoT 101aデバイスは、(IPを使用せずに)メッセージを送受信することができ、これらのメッセージは、非アクセス階層(NAS)シグナリングプロトコルでシグナリングデータとして伝達される。NASシグナリングは、第1のNB-IoTデバイス101aとモビリティ管理エンティティ(MME)105との間で行われ得る。次いで、メッセージは、MME105から公開機能104に中継され得る。公開機能104のサービスを使用するために、アプリケーションサーバは、最初に公開機能104に登録するよう要求され得、使用したいサービスおよび対象となるデバイスを示し得る。各NB-IoTデバイスには、外部識別子またはMSISDNが割り当てられ、これらは、IMSIなどの他の加入詳細とともにホーム加入者サービス(HSS:Home Subscriber Service)106に登録され得る。今後数年間でMTCデバイスの数が増加すると、電話番号(すなわち、MSISDN)が不足することになる。3GPPソリューションは、新しい識別子を加入データの一部として規定し、MSISDNが割り当てられていない動作を、代わりに新しい識別子を使用することによって可能にする。この新しい識別子の名称は「外部識別子」である。しかしながら、簡単にするために、本明細書では、「外部識別子」という用語は、MSISDNを包含すると理解されるべきである。次いで、外部識別子をアプリケーションサーバが使用して、ターゲットとするデバイスにインデックス付けすることができる。外部識別子の他の例には、車両登録/VIN番号、スマートメータのシリアル番号、QRコードなどが含まれる。
セルラネットワークは、P-GW102を介したポイントツーポイントトンネルを使用したNIDDトランスポートモードも提供する。例えば、第2のNB-IoTデバイス101bは、(IPを使用せずに)メッセージを送受信するように設定され得、これらのメッセージは、デバイスとMME105との間のNASシグナリングプロトコルでシグナリングデータとして伝達される。次いで、メッセージはさらに、MME105からS-GW103に、さらにP-GW102へ中継され得る。P-GW102は、透過的な転送ノードとして作用し得る。NB-IoTデバイスごとに、P-GWは、NB-IoTデバイスによって使用されるPDN接続のAPNに基づいて、パケットの転送先および転送元となるアプリケーションサーバに関する知識を有し得る。P-GW102は、NB-IoTデバイスから受信したパケットをアプリケーションサーバに転送する前に、そのパケットにUDP/IPヘッダを追加し得、アプリケーションサーバから受信したパケットをNB-IoTデバイスに転送する前に、そのパケットからUDP/IPヘッダを除去し得る。P-GW102はまた、アプリケーションサーバとの通信で使用するために、各NB-IoTデバイスにIPアドレスおよびポートを割り当て得る。
ネットワーク100は、プロファイル管理サーバ107をさらに含む。プロファイル管理サーバは、プロファイルプロビジョニングおよびプロファイル管理動作(プロファイルの有効化、無効化、削除など)のために使用され得る。プロファイル管理サーバのタスクは、プロファイルのダウンロードをハンドリングするプロビジョニングサーバおよびプロファイル管理動作をハンドリングする管理サーバなどの別々のサーバによって実行される異なるタスクに分割され得るが、簡単にするために、単一のプロファイル管理サーバ107が示されている。
NIDDを使用してNB-IoTデバイスと通信する例では、プロファイル管理サーバ107は、公開機能104またはP-GW102に登録/設定され得、したがって、NIDDを使用してこれらのノードを介してNB-IoTデバイスと通信し得る。しかしながら、これらのNB-IoTデバイスは、プロファイル管理サーバ107との通信と並行して、他の(アプリケーション)サーバと通信する必要があり得る。この並列通信を可能にするために、プロキシサーバ108が間で使用される。プロキシサーバ108は、公開機能104またはP-GW102に登録/設定され得るか、またはNB-IoTデバイスとの間のトラフィックがプロキシサーバ108に送信され得、次いで、プロキシサーバ108は、異なるNB-IoTデバイスによって生成されたメッセージを、必要に応じて別のアプリケーションサーバに転送し得る。
通常、デバイスで生成されたメッセージを正しいアプリケーションサーバへ方向付けるために、プロキシサーバによって、送信先のIPアドレスおよびポートが使用される。しかしながら、ここでは(IPエンドツーエンドなしで)、プロキシサーバがNB-IoTデバイスの1つのアプリケーションからのトラフィックを適切なアプリケーションサーバに接続できるように調整するかどうかは、プロキシサーバ、およびNB-IoTデバイスのアプリケーション次第であり得る。プロキシサービスに加えて、プロキシサーバは、監視および通知サービスなど(SCEFサービスおよび他のコアネットワークサービスに基づく)他のサービスを、プロファイル管理サーバを含むアプリケーションサーバに提供し得る。したがって、NB-IoTデバイス101aから101cのいずれかにおける識別情報モジュールのためのプロファイルのリモート管理は、プロキシサーバ108を介して管理され得る。
IoTデバイス(またはNB-IoTデバイス)を所有する企業は、モバイルネットワークオペレータ(MNO)で自社のIoTデバイスのための新しいセルラ加入(プロファイルと呼ばれ得る)を申し込むことができる。プロファイルは、プロファイル管理サーバ107において準備され、ダウンロードに使用できるようにされ得る。企業は、準備されたプロファイルを識別するプロファイル識別子のセットをMNOから受信し得る。プロファイル識別子の例は、集積回路カード識別子(ICCID:Integrated Circuit Card Identifier)、国際移動体加入者識別情報(IMSI:International Mobile Subscriber Identity)、アクティベーションコード(AC)、およびマッチングIDである。次いで、企業は、デバイスコネクティビティ(D/C)管理サーバ109を利用して、企業が所有するIoTデバイスのうちの1つの識別情報モジュールでプロファイルダウンロードをトリガし、かつ/またはすでにダウンロードされたプロファイルでのプロファイル管理動作をトリガし得る。D/C管理サーバ109は、デバイス管理サーバを含み得るが、コネクティビティ管理をハンドリングするサーバでもあり得る。
図2は、プロキシサーバにおいて、NB-IoTデバイス内の識別情報モジュールのためにプロファイルのリモート管理を可能にするための方法を示す。例えば、図2の方法は、図1に示すプロキシサーバ108によって実行され得る。プロキシサーバは、1つまたは複数のそれぞれのNB-IoTデバイスに関連付けられた1つまたは複数の外部識別子のデータベースにアクセスするように設定される。例えば、プロキシサーバ108は、NB-IoTデバイス101aから101cの各々の外部識別子に関連する情報を含むデータベースにアクセスすることが可能であり得る。1つまたは複数の外部識別子は、コアネットワーク内の公開機能を介してそれぞれの1つまたは複数のNB-IoTデバイスをアドレス指定するために使用される。上記のように、公開機能は、SCEFまたはNEFを含み得る。プロファイルの管理は、例えば、識別情報モジュールへの新しいプロファイルのプロビジョニング、プロファイルの有効化もしくは無効化、またはプロファイルの削除を含み得る。
外部識別子は、加入識別子を含み得る。例えば、外部識別子は、モバイルステーション国際加入者電話番号(MSISDN:Mobile Station International Subscriber Directory Number)を含み得る。
ステップ201において、プロキシサーバは、トリガメッセージをNB-IoTデバイスに配信するよう求める要求を受信し、要求は、デバイス識別子を含む。トリガメッセージは、プロファイルダウンロードトリガメッセージを含み得る。プロファイルダウンロードトリガメッセージは、プロファイル管理サーバからプロファイルをダウンロードするようNB-IoTデバイスをトリガすることを目的とし得る。トリガメッセージは、プロファイル管理トリガメッセージを含み得る。プロファイル管理トリガメッセージは、プロファイル管理動作を実行するようNB-IoTデバイス内の識別情報モジュールをトリガするように設定され得る。例えば、プロファイル管理動作は、識別情報モジュール内の既存のプロファイルを更新、有効化、無効化、または削除することであり得る。
ステップ202において、プロキシサーバは、受信したデバイス識別子に基づいて外部識別子を決定する。
ステップ203において、プロキシサーバは、外部識別子を使用して、トリガメッセージをNB-IoTデバイスに配信する。
図3は、狭帯域モノのインターネット(NB-IoT)デバイスにおいて、NB-IoTデバイス内の識別情報モジュールにおけるプロファイルのリモート管理を可能にするための方法を示す。プロファイルの管理は、NB-IoTデバイス内の識別情報モジュールにおける、新しいプロファイルのリモートプロビジョニングまたは既存のプロファイルの管理を含み得る。
ステップ301において、NB-IoTデバイスは、プロキシサーバによって配信されたトリガメッセージを受信する。例えば、NB-IoTデバイスは、図2によるプロキシサーバによって配信されたようなトリガメッセージを受信し得る。
図4は、図1および図2の方法の例をより詳細に示すシグナリング図である。具体的には、図4は、トリガメッセージがプロキシサーバ(例えば、図1のプロキシサーバ108)から配信され得る方法の例を示す。
401に示すように、プロキシサーバ108は、1つまたは複数のそれぞれのNB-IoTデバイスに関連付けられた1つまたは複数の外部識別子のデータベースにアクセスするように設定される。プロキシサーバはまた、公開機能104のためにユニフォームリソースロケータを有するように設定され得る。
ステップ402aに示す一例では、プロキシサーバ108は、1組のNB-IoTデバイスと通信するNIDDサービスのために、公開機能104に登録される。この例では、(図2のステップ201に対応する)ステップ403において、プロキシサーバ108は、トリガメッセージをNB-IoTデバイスに配信するよう求める要求を受信し、(図2のステップ202に対応する)ステップ404において、プロキシサーバは、受信したデバイス識別子に基づいて外部識別子を決定し、その後、方法はステップ405に進む。
ステップ405は、図2のステップ203が実行され得る方法の例を示す。ステップ405において、公開機能104によって提供されるNIDDサービスを使用して、トリガメッセージを配信する。プロキシサーバ108は、公開機能104に登録され得、NIDDサービスのデータ送信コマンドを使用して、トリガメッセージをNB-IoTデバイス101に送信し得る。公開機能104は、トリガメッセージをバッファリングし得、NB-IoTデバイス101が電源投入されてネットワークに登録されるとき、トリガメッセージをNB-IoTデバイス101に送信し得る。公開機能104のNIDDサービスを使用することは、公開機能のNIDDサービスがデバイスとアプリケーションサーバとの間のデータ転送に使用される第1のタイプのNB-IoTデバイスにとって自然なことであり得る。しかしながら、この実施形態は、他の場合NB-IoTデバイスとアプリケーションサーバとの間のデータ転送に公開機能のNIDDサービスを使用できないタイプ2およびタイプ3のデバイスにも使用できることが理解されよう。
別の例では、ステップ401に続いて、方法はステップ402bに進む。ステップ402bにおいて、プロキシサーバ108は、1組のNB-IoTデバイスの監視サービスのために、公開機能104に登録される。監視サービスは、1組のNB-IoTデバイスのうちの1つがいつネットワークに登録するかをプロキシサーバ108に示し得る。この例では、ステップ404に続いて、方法はステップ406に進む。具体的には、この例におけるステップ406から409は、図2のステップ203が実行され得る方法を示す。ステップ406において、プロキシサーバ108は、1組のNB-IoTデバイスのうちの1つがネットワークに登録したことを示す通知を公開機能104から受信する。ステップ406は、ステップ403およびステップ404の前に行われ得ることが理解されよう。
ステップ407において、プロキシサーバは、公開機能104、P-GW102、またはネットワーク内の第3のノードのいずれかを使用して、外部識別子またはMS
ISDNに基づいて、NB-IoTデバイスの現在のIPアドレス(場合によってはポート)を取得する。したがって、プロキシサーバ108は、このサービスを使用して、公開機能104監視サービスと組み合わせて現在のIPアドレスを取得する。言い換えれば、ステップ407は、アドレス要求を第3のネットワークノードに送信することを含み得、アドレス要求は、外部識別子を含む。
ステップ408において、プロキシサーバ108は、NB-IoTデバイス101の現在のIPアドレスを受信し得、ステップ409において、受信したIPアドレスを使用してトリガメッセージをNB-IoTデバイスに送信する。言い換えれば、プロキシサーバ108は、アドレス要求を送信したことに応答して、NB-IoTデバイスのIPアドレスを受信する。
具体的には、ステップ409は、IPアドレスを利用してトリガメッセージを送信することを含む。例えば、プロキシサーバは、(例えば、タイプ2のデバイスの場合)P-GW102を介してしてNIDDを利用してトリガメッセージを送信し得る。いくつかの例において、ステップ409は、(例えば、タイプ3のデバイスの場合)デバイスのIPアドレスを使用して、UDP/IPまたはTCP/IPを介してトリガメッセージをNB-IoTデバイスに送信することを含む。したがって、トリガメッセージは、P-GW102およびS-GW103を介して、NB-IoTデバイス101にルーティングされ得る。
プロキシサーバ108の(上記の図4に示す)トリガメッセージ配信サービスは、様々な方法で実装され得る。選択肢の1つは、プロキシサーバ108が、制約付きアプリケーションプロトコル(CoAP)またはハイパーテキスト転送プロトコル(HTTP)サーバとして作用し、NB-IoTデバイスに送られるべきトリガメッセージをプロキシサーバ108に送信することによって、トリガメッセージ配信サービスを、アプリケーションサーバが使用するリソースとして提供することである。プロキシサービスにおけるこのサービスに対する各CoAP/HTTP要求には、トリガメッセージおよびデバイス識別子が含まれ得る。次いで、プロキシサーバ108は、外部識別子がデバイス識別子としてまだ使用されていない場合、データベース検索を利用して、受信したデバイス識別子を外部識別子に変換し得る。プロキシサーバ108のトリガメッセージ配信サービスは、プロキシサーバ108に事前登録されているか、またはトリガメッセージ配信サービス使用するためにオンライン認証サーバ(例えば、OAuth2サーバもしくはACE認証サーバ)からアクセストークンを取得したアプリケーションサーバに限定され得る。
図5は、いくつかの実施形態によるプロファイルプロビジョニングプロセスの一例を示す。
NB-IoTデバイス101(例えば、eUICC)の識別情報モジュールは、NB-IoTデバイス101がセルラネットワークに接続することを可能にするアクティブなセルラ加入(すなわち、有効化されたプロファイル)を有するように設定され得る。これは、動作プロファイルの提供を可能にする目的で製造時にインストールされたプロファイルであり得るか、または以前にNB-IoTデバイス101によってダウンロードされた動作プロファイルであり得る。
HSS106は、NB-IoTデバイス101の加入者資格情報を有するように設定され得る。加入者資格情報は、公開機能104(例えば、SCEF)を介してデバイスをアドレス指定するために使用される外部識別子を含み得る。プロキシサーバ108は、NB-IoTデバイス101をアドレス指定することが可能な外部識別子を有するように設定され得る。プロファイル管理サーバ107は、ダウンロード可能であり得るプロファイルパッケージのセットを含み得る。プロファイルパッケージに対する対応するプロファイル識別子は、NB-IoTデバイスを所有する企業に提供され得、D/C管理サーバ109に提供され得る。所与のプロファイルパッケージについて、プロファイルに対応するモバイルネットワークのHSS106は、プロファイルパッケージの加入者資格情報に対応する加入者資格情報、およびNB-IoT101の外部識別子を有するように設定される。
簡単にするために、ここでは両方のモバイルネットワーク内で同じ外部識別子またはMSISDNが使用されていると仮定する。それ以外の場合、2つの間で変換を実行する必要がある(例えば、変換が発生するプロキシサーバに新しい外部識別子が設定される)。
ステップ501において、D/C管理サーバ109は、プロファイルのダウンロードをトリガするためのコマンドをプロファイル管理サーバ107に送信する。ステップ501において、D/C管理サーバ109は、少なくとも、プロファイルがダウンロードされるNB-IoTデバイス101のデバイス識別子、ダウンロードされるプロファイルに対応するプロファイル識別子、およびプロキシサーバ108のURLを提供し得る。デバイス識別子は、プロファイル管理サーバによって、プロファイルダウンロードがトリガされるべきデバイスを識別するために使用され、プロファイル識別子は、ダウンロードされるプロファイルを識別する。デバイス識別子の例は、IMEI、外部識別子、MSISDN、モデムモジュール識別子、およびeUICC ID(EID)である。
ステップ502において、プロファイル管理サーバ107は、トリガメッセージをNB-IoTデバイス101に配信するよう求める要求をプロキシサーバ108に送信し、要求は、デバイス識別子を含む(ステップ502は、図2のステップ201に対応し得る)。このトリガメッセージは、プロファイル管理サーバ107のURLを含み得る。プロファイル管理サーバ107はまた、トリガメッセージが適用されるNB-IoTデバイス101のデバイス識別子を示し得る。いくつかの例において、NB-IoTデバイス101は、プロファイル管理サーバ107のURLを有するように事前設定され得、NB-IoTデバイス101の最初の起動時にステップ504を実行するように設定され得る。
ステップ503において、プロキシサーバ108は、ステップ502で受信したデバイス識別子によって識別されるNB-IoTデバイスにトリガメッセージを配信する。具体的には、プロキシサーバは、ステップ502で受信したデバイス識別子に基づいて外部識別子を決定し得る。デバイス識別子が外部識別子と異なる場合、プロキシサーバは、提供されたデバイス識別子を使用してデータベース内の外部識別子を検索する。次いで、ステップ503は、図4に示すように実施され得る。いくつかの例において、ステップ503は任意選択であり、NB-IoTデバイス101がプロファイル管理サーバ107のURLを有するように事前設定され、デバイスの最初の起動時にステップ504を実行するように設定されている場合、実行されない。
ステップ504において、NB-IoTデバイス101は、NB-IoTデバイス101の識別情報モジュールとプロファイル管理サーバ107との間のセキュア通信を確立し得る。
ステップ505において、NB-IoTデバイス101およびプロファイル管理サーバ107は、例えば、相互認証を含むセキュア通信を確立するためにメッセージを交換する。
ステップ506において、NB-IoTデバイス101は、プロファイル管理サーバ107からプロファイルパッケージをダウンロードする。プロファイル管理サーバ107は、ステップ501で受信したデバイス識別子およびプロファイル識別子に基づいて、どのプロファイルパッケージをNB-IoTデバイス101にダウンロードするかを認識する。次いで、NB-IoTによって、プロファイルパッケージが識別情報モジュールにインストールされ得る。例えば、ステップ506は、プロファイル管理サーバからプロファイルを受信することと、プロファイルを識別情報モジュールにインストールすることとを含み得る。
ステップ507において、プロファイル管理サーバ107は、任意選択として、トリガメッセージの結果について報告する応答をD/C管理サーバ109に提供し得る。例えば、プロファイル管理サーバ107は、プロファイルがNB-IoT101に正常にダウンロードされたか否かをD/C管理サーバ109に示し得る。
いくつかの例において、プロファイルは、新しいモバイルネットワークのプロファイルであり得る。これらの例では、D/C管理サーバ109は、ステップ508において、NB-IoTデバイス101について新しいモバイルネットワークに切り替えるよう求める要求をプロキシサーバ108に送信し得る。例えば、新しいモバイルネットワークに切り替えるよう求める要求は、プロキシサーバが、新しいモバイルネットワークに属するP-GWなどを公開機能に登録することを求める要求を含み得る。P-GWの場合、プロキシサーバはプロファイルの申込み/準備フェーズからNIDDで使用するように事前設定されている可能性があり、その場合このステップは省略され得ることに留意されたい。
ステップ508が実行される場合、プロキシサーバは、ステップ509において、新しいモバイルネットワークに登録し得る。例えば、プロキシサーバ108は、NB-IoTデバイス101から送信された任意のデータが新しいモバイルネットワークを介してアプリケーションサーバにルーティングされ得るように、新しいモバイルネットワークに登録し得る。登録が行われると、プロキシサーバ108は、古いモバイルネットワークを介してNB-IoTデバイスにデータを送信するように設定されたまま、プロファイルが有効化されて切り替えが完了した状態が確立されるまで、両方のモバイルネットワークを介してNB-IoTデバイスからデータを受信することが可能になり得、すなわち、プロキシサーバは、新しいモバイルネットワークを介してNB-IoTデバイスにデータを送信するように設定される。
いくつかの例において、プロファイルは、NB-IoTへのプロファイルのダウンロードとは別に有効化され得る。これらの例では、ステップ506において、プロファイルがダウンロードされ得、ステップ510において、D/C管理サーバ109が、プロファイルの有効化をトリガするよう求める要求をプロファイル管理サーバ107に送信し得る。プロファイルの有効化をトリガするよう求める要求は、デバイス識別子、プロファイル識別子、およびプロキシサーバ108のURLを含み得る。このステップは任意選択であり、プロファイルの有効化は、D/C管理サーバがプロファイルダウンロードのためにプロファイル管理サーバをトリガするステップ501の一部であり得る。
ステップ510においてプロファイルの有効化をトリガするよう求める要求を受信したことに応答して、プロファイル管理サーバ107は、ステップ511において、ダウンロードされたプロファイルの有効化をトリガする情報を含むメッセージをプロキシサーバ108に送信し得る。このメッセージは、プロファイル管理サーバ107のURLを含み得る。プロファイル管理サーバ107はまた、メッセージが適用されるNB-IoTデバイス101のデバイス識別子を示し得る。このステップは、NB-IoTデバイス101が依然としてアクティブである間にプロファイルダウンロードの直後にプロファイルの有効化が行われる場合は任意選択であり得、その場合、ステップ515が直ちに実行され得る。
ステップ512において、プロキシサーバ108は、ステップ511で受信したデバイス識別子によって識別されるNB-IoTデバイス101に、ダウンロードされたプロファイルの有効化をトリガするためのメッセージを配信する。上記のように、このステップでは、トリガメッセージは、図4で説明されているようにNB-IoTデバイスに配信され得る。ステップ512は任意選択であり、ステップ511が実行されない場合、実行されない可能性がある。また、以下に説明するステップ515のプロファイル有効化要求メッセージが、プロファイルの有効化をトリガするよう求める要求の一部として含まれ、すでに確立されたセキュリティアソシエーションを使用してプロファイル管理サーバ107からNB-IoTデバイス101にエンドツーエンドで保護される場合もあり、この場合、プロファイル管理サーバ間のセキュア通信のさらなる確立(例えば、ステップ514)は必要とされない場合がある。
ステップ514において、NB-IoTデバイス101は、NB-IoTデバイス101の識別情報モジュールとプロファイル管理サーバ107との間のセキュア通信を確立し得る。このステップは任意選択であり、プロキシサーバ108からプロファイルの有効化をトリガするよう求める要求がない場合(例えば、ステップ512がない場合)、実行されない可能性がある。また、ステップ515のプロファイル有効化要求メッセージが、プロファイルの有効化をトリガするよう求める要求の一部として含まれ、プロファイル管理サーバからエンドツーエンドで保護されている場合、ステップ514は実行されない可能性がある。次いで、NB-IoTデバイスおよびプロファイル管理サーバ107は、メッセージを交換して、相互認証を含むセキュア通信を確立し得る。
ステップ515において、プロファイル管理サーバ107は、プロファイルを有効化するよう求める要求メッセージをデバイスに送信する。上記のように、このような小さいメッセージの場合、またプロファイルの有効化をトリガするよう求める要求が以前に送信されている場合、要求メッセージは、プロファイルの有効化をトリガするよう求める要求の一部として含まれる場合があり、その場合、ステップ513~515は実行されないことに留意されたい。NB-IoTデバイス101内の識別情報モジュールは、要求メッセージを処理し、プロファイルを有効化し得る。NB-IoTデバイス101からプロファイル管理サーバ107に返送される応答メッセージが準備され得る。ステップ514でセキュア通信が確立されていない場合、応答メッセージは、すでに確立されたセキュリティアソシエーションを使用して保護され得る。
ステップ516において、プロファイル管理サーバ107は、任意選択として、動作の結果について報告する応答をD/C管理サーバ109に提供する。例えば、プロファイル管理サーバ107は、プロファイルが有効化されたか否かを報告し得る。
プロファイルの有効化が成功し、プロファイルが新しいモバイルネットワークオペレータにあることに応答して、D/C管理サーバ109は、ステップ517において、新しいモバイルネットワークオペレータからのサービスを使用するように切り替えるようにプロキシサーバ108に命令し得る。例えば、プロキシサーバ108は、プロファイルが変更された特定のNB-IoTデバイスの新しいモバイルネットワークで公開機能(例えば、SCEF)および/またはP-GWを使用するように切り替えるように命令され得る。新しいモバイルネットワークへの登録は、以前に(例えば、ステップ509において)行われている可能性がある。NB-IoTデバイスのデバイス識別子は、使用される様々なMNOサービス(SCEF、P-GWなど)へのURLとともに提供され得る。
ステップ518において、プロキシサーバ108は、プロキシサーバ108の設定を、アプリケーションサーバからNB-IoTデバイス101へのデータが今度は新しいモバイルネットワークを介して転送されるように変更し得る。プロキシサーバ108はまた、古いモバイルネットワークサービスから登録解除し得る。
フローの後半部分、例えばステップ508~518は、プロファイルの有効化、プロファイルの無効化、およびプロファイルの削除などの任意のスタンドアロンのプロファイル管理動作に適用され得る。ステップ508、509、517、および518は、プロファイルが有効化されている場合にのみ関連する可能性があり、これは、あるMNOから別のMNOへの切り替えも意味する。
制約付きアプリケーションプロトコル(CoAP)は、アプリケーション関連のメッセージを転送するために制約付きIoTデバイスで使用するためのプロトコルである。いくつかの実施形態において、CoAPは、プロファイルダウンロードおよびプロファイル管理関連のメッセージを転送するために、NB-IoTデバイス101とプロファイル管理サーバ107との間で使用される。
いくつかの実施形態において、プロファイル管理(新しいプロファイルの管理およびプロビジョニングを含む)は、GSMA RSP M2M版による。この例では、プロファイル管理サーバ107は、SM-SRおよびSM-DPと呼ばれる2つのサーバによって表され得る。SM-SRおよびSM-DPは、企業が新しい加入プロファイルを申し込んだMNOによって運用され得るか、または、SM-SRおよびSM-DPは、サードパーティによって運用され得、MNOに提供されるサービスの一部であり得る。SM-SRおよびSM-DPは、同じ場所に配置されて同一のエンティティによって管理され得るか、または離れた場所にあり、異なる当事者によって運営され得る。SM-SRおよびSM-DPが、MNOが使用するサードパーティのサービスである場合、D/C管理サーバ109をSM-DPおよびSM-SRとリンクするプロファイル管理動作用の顧客向けのインターフェースを提供するMNOポータルも、プロファイル管理サーバの一部として含まれる。
リモートでのプロファイルダウンロードおよびプロファイル管理に関連するNB-IoT101内の識別情報モジュールとのオーバージエアでのセキュア通信は、SM-SRによって排他的にハンドリングされ得る。セキュア通信は、SM-SRと識別情報モジュールとの間で共有される資格情報に基づき得る。SM-DPは、SM-SRと識別情報モジュールとの間に確立されたセキュア通信トンネルを介してプロファイルダウンロードをハンドリングするエンティティであり得る。また、SM-SRは、プロファイル管理動作(プロファイルの有効化、無効化、および削除)を制御するエンティティであり得る。SM-SRとSM-DPとMNOポータルとの間の個々の通信はGSMA RSP標準に従い得ると仮定することができ、したがって、この通信の詳細は本明細書に含まれていない。しかしながら、SM-SRとSM-DPとMNOポータルとの間のこの通信は、任意の適切な通信方法を含み得ることが理解されよう。セキュア通信トンネル内で実行される識別情報モジュールとMNOポータル/SM-DP/SM-SRとの間の通信についても同様である。
SM-SR107間のセキュア通信は、(保護された)SMS、HTTPS、およびカードアプリケーションツールキットトランスポートプロトコル(CAT_TP)に基づき得る。SMSは、HTTPSおよびCAT_TPセッションをトリガするために、また1つまたはいくつかのSMSに適合する単純なコマンドのために使用され得る。HTTPSまたはCAT_TPは、データ集約型の転送、例えば、プロファイルダウンロードに関連する転送のために使用され得る。
図6は、図5に示したシグナリング図の一例を示す。この例は、GSMA RSP M2M版の使用に関連し得る。標準GSMA RSPの構成要素(例えば、SM-SR)およびM2M版をサポートする識別情報モジュールへの変更の数を最小限に抑え、プロファイル管理サーバ107におけるプロキシサーバ108、デバイスIDなどの知識を最小限に抑えるために、通信フローは、プロファイルの有効化をトリガするためのトリガメッセージおよび要求がD/C管理サーバ109を介してルーティングされるように修正される。
上記で示したように、NB-IoTデバイス101はSMSをサポートしていないので、トリガメッセージは、図4を参照して説明したように送信され得る。この例では、トリガメッセージは、GSMA RSPで使用されるSMS形式と同じ形式であり得る。例えば、SMS形式は、ETSIによって規定された拡張リモートAPDUコマンド構造を含み得る。したがって、識別情報モジュールの観点からは、識別情報モジュールは、SMSサービスをサポートするデバイスで使用されるときと同一のメッセージをNB-IoTデバイスから受信することになる。同様に、SM-SRおよびSM-DPの場合、これらは、標準によるSMS形式のトリガメッセージを作成し得るが、SMSサービスを使用してSMSメッセージを送信することはない。代わりに、NB-IoTデバイス101への配信のために、SMSトリガメッセージがD/C管理サーバ109に提供される。
NB-IoTデバイス101(例えば、eUICC)の識別情報モジュールは、NB-IoTデバイス101がセルラネットワークに接続することを可能にするアクティブなセルラ加入(すなわち、有効化されたプロファイル)を有するように設定され得る。これは、動作プロファイルの提供を可能にする目的で製造時にインストールされたプロファイルであり得るか、または以前にNB-IoTデバイス101によってダウンロードされた動作プロファイルであり得る。
HSS106は、NB-IoTデバイス101の加入者資格情報を有するように設定され得る。加入者資格情報は、公開機能104(例えば、SCEF)を介してデバイスをアドレス指定するために使用される外部識別子を含み得る。プロキシサーバ108は、NB-IoTデバイス101をアドレス指定することが可能な外部識別子を有するように設定され得る。プロファイル管理サーバ107は、ダウンロード可能であり得るプロファイルパッケージのセットを含み得る。プロファイルパッケージに対する対応するプロファイル識別子は、NB-IoTデバイスを所有する企業に提供されていることがあり、D/C管理サーバ109に提供され得る。所与のプロファイルパッケージについて、プロファイルに対応するモバイルネットワークのHSS106は、プロファイルパッケージの加入者資格情報に対応する加入者資格情報、およびNB-IoT101の外部識別子を有するように設定される。
ステップ601において、D/C管理サーバ109は、プロファイルのダウンロードをトリガするためのコマンドをプロファイル管理サーバ107に送信する。ステップ501において、D/C管理サーバ109は、少なくとも、プロファイルがダウンロードされるNB-IoTデバイス101のデバイス識別子、ダウンロードされるプロファイルに対応するプロファイル識別子、およびプロキシサーバ108のURLを提供し得る。デバイス識別子は、プロファイル管理サーバ107によって、プロファイルダウンロードがトリガされるべきデバイスを識別するために使用され、プロファイル識別子は、ダウンロードされるプロファイルを識別する。この例では、デバイス識別子はeUICC ID(EID)を含む。この例では、プロファイル識別子はICCIDを含む。
ステップ602において、プロファイル管理サーバ107は、GSMA RSP M2M版「HTTPSセッショントリガのためのSMS」によるフォーマットされたデータを含むメッセージ(例えば、GSMA RSP M2M版によるフォーマットされたトリガメッセージ)をD/C管理サーバ109に送信する。具体的には、メッセージは、EID、およびトリガメッセージのための情報を含み得る。
したがって、この例では、ステップ603において、D/C管理サーバ209は、トリガメッセージをNB-IoTデバイス101に配信するよう求める要求をプロキシサーバ108に送信し、要求は、デバイス識別子を含む(ステップ603は、図2のステップ201に対応し得る)。この例では、D/C管理サーバは、EIDに対応するデバイス識別子を検索し得る
ステップ604において、プロキシサーバ108は、ステップ603で受信したデバイス識別子によって識別されるNB-IoTデバイスにトリガメッセージを配信する。具体的には、プロキシサーバ108は、ステップ603で受信したデバイス識別子に基づいて外部識別子を決定し得る。デバイス識別子が外部識別子と異なる場合、プロキシサーバ108は、提供されたデバイス識別子を使用してデータベース内の外部識別子を検索する。次いで、ステップ604は、図4に示すように実施され得る。
ステップ605において、NB-IoTデバイス101内のデバイスアプリケーションは、「HTTPSセッショントリガのためのSMS」をNB-IoT101内の識別情報モジュールに送信し得る。
ステップ606において、NB-IoTデバイス101およびプロファイル管理サーバ107は、例えば、相互認証を含むセキュア通信を確立するためにメッセージを交換する。この例では、ステップ606は、GSMA RSP M2M版によるHTTPSセッションの確立を含む。ここでのソリューションは、プロファイル管理サーバ(SM-SR部分)107とNB-IoT101の識別情報モジュールの2つのエンドポイントが修正を必要とせず、それらの間で転送されるHTTPSメッセージを交換できることを保証する。メッセージの転送方法についての詳細を以下に説明する。
ステップ607において、NB-IoTデバイス101は、プロファイル管理サーバ107からプロファイルパッケージをダウンロードする。プロファイル管理サーバ107は、ステップ601で受信したデバイス識別子およびプロファイル識別子に基づいて、どのプロファイルパッケージをNB-IoTデバイス101にダウンロードするかを認識する。次いで、NB-IoTによって、プロファイルパッケージが識別情報モジュールにインストールされ得る。例えば、ステップ607は、プロファイル管理サーバからプロファイルを受信することと、プロファイルを識別情報モジュールにインストールすることとを含み得る。この例では、プロファイル管理サーバ(SM-SR部分)107と識別情報モジュールとの間のセキュアなトンネル内ですべて交換される一連のメッセージからなる標準GSMA RSP M2Mプロトコルによる、プロファイルパッケージがNB-IoTデバイスにダウンロードされ、識別情報モジュールにインストールされる。
ステップ608において、プロファイル管理サーバ107は、任意選択として、トリガメッセージの結果について報告する応答をD/C管理サーバ109に提供し得る。例えば、プロファイル管理サーバ107は、プロファイルがNB-IoT101に正常にダウンロードされたか否かをD/C管理サーバ109に示し得る。
この例では、プロファイルは、新しいモバイルネットワークのプロファイルである。したがって、この例では、D/C管理サーバ109は、ステップ609において、NB-IoTデバイス101について新しいモバイルネットワークに切り替えるよう求める要求をプロキシサーバ108に送信し得る。例えば、新しいモバイルネットワークに切り替えるよう求める要求は、プロキシサーバが、新しいモバイルネットワークに属するP-GWなどを公開機能に登録することを求める要求を含み得る。要求には、プロキシサーバが登録するよう要求されているMNOサービスのURLが含まれ得る。P-GWの場合、プロキシサーバはプロファイルの申込み/準備フェーズからNIDDで使用するように事前設定されている可能性があり、その場合このステップは省略され得ることに留意されたい。
ステップ609に応答して、プロキシサーバは、ステップ610において、新しいモバイルネットワークに登録し得る。例えば、プロキシサーバ108は、NB-IoTデバイス101から送信された任意のデータが新しいモバイルネットワークを介してアプリケーションサーバにルーティングされ得るように、新しいモバイルネットワークに登録し得る。登録が行われると、プロキシサーバ108は、古いモバイルネットワークを介してNB-IoTデバイスにデータを送信するように設定されたまま、新しいプロファイルが有効化されて切り替えが完了した状態が確立されるまで、すなわち、プロキシサーバが、新しいモバイルネットワークを介してNB-IoTデバイスにデータを送信するように設定されるまで、両方のモバイルネットワークを介してNB-IoTデバイスからデータを受信することが可能になり得る。
この例では、プロファイルは、NB-IoTへのプロファイルのダウンロードとは別に有効化され得る。したがって、この例では、ステップ607において、プロファイルがダウンロードされ得、ステップ611において、D/C管理サーバ109が、プロファイルの有効化をトリガするよう求める要求をプロファイル管理サーバ107に送信し得る。この例では、ステップ611で送信される要求は、EIDおよびICCIDを含む。このステップは任意選択であり、プロファイルの有効化は、D/C管理サーバがプロファイルダウンロードのためにプロファイル管理サーバをトリガするステップ601の一部であり得る。
ステップ612において、プロファイル管理サーバ107は、EIDおよびGSMA RSP M2M版「プロファイル有効化のためのSMS」によるフォーマットされたデータを含むメッセージをD/C管理サーバに送信する。さらに、メッセージには、プロファイル管理サーバのURLが含まれ得る。ステップ611が実行されない場合、「プロファイル有効化のためのSMS」を提供するためのトリガは、プロファイルが正常にダウンロードされたことであることに留意されたい。その場合、メッセージは、プロファイル管理サーバ107によって、ステップ608の一部としてD/C管理サーバ109に提供され得る。
ステップ612でメッセージを受信したことに応答して、D/C管理サーバ109は、ステップ613において、ダウンロードされたプロファイルの有効化をトリガするための情報を含むメッセージをプロキシサーバ108に送信し得る。具体的には、D/C管理サーバは、ステップ612で提供されたEIDに対応するデバイス識別子を検索し、NB-IoTデバイス101へのメッセージの配信のために、メッセージ(「プロファイル有効化のためのSMS」)およびデバイス識別子をプロキシサーバ108に送信し得る。このメッセージは、プロファイル管理サーバ107のURLを含み得る。
ステップ614において、プロキシサーバ108は、ステップ613で受信したデバイス識別子によって識別されるNB-IoTデバイス101に、ダウンロードされたプロファイルの有効化をトリガするためのメッセージを配信する。上記のように、このステップでは、トリガメッセージは、図4で説明されているようにNB-IoTデバイスに配信され得る。
ステップ615において、NB-IoTデバイス101内のデバイスアプリケーションは、メッセージ(「プロファイル有効化のためのSMS」)を識別情報モジュールに配信する。
ステップ616において、識別情報モジュールは、プロファイルを有効化し、「SMS」としてフォーマットされたプロファイル有効化動作の結果を有するメッセージを準備する。
ステップ617において、ステップ616で準備されたメッセージは、NB-IoTデバイス101内のデバイスアプリケーションに配信される。
ステップ618において、ステップ616およびステップ617のメッセージは、NB-IoTデバイス101内のデバイスアプリケーションからプロファイル管理サーバ107に配信される。プロファイル管理サーバ107のURLは、デバイスアプリケーション/識別情報モジュールに認識されているか、ステップ614で受信したメッセージ「プロファイル有効化のためのSMS」の一部であるか、またはステップ614において「プロファイル有効化のためのSMS」とともに配信され得るかである。
ステップ619において、プロファイルの有効化が成功すると、新しいネットワークへの連結が実行される(この例のように、新しいプロファイルは新しいモバイルネットワークを伴う)。
ステップ620において、識別情報モジュールは、デバイスアプリケーションに配信される「SMS」としてフォーマットされた通知メッセージを準備する。
ステップ621において、メッセージ(「SMS通知」)が、デバイスアプリケーションからプロファイル管理サーバ107に配信される。プロファイル管理サーバのURLは、以前からNB-IoTデバイス101に知られている可能性がある。
ステップ621でのメッセージの配信において、プロキシサーバ108は、ステップ610で登録された新しいモバイルネットワークを介して、NB-IoTデバイス101からトラフィックを受信する。次いで、プロキシサーバ108は、NB-IoTデバイス101のモバイルネットワークを切り替えることを決定することができ、ステップ622において、新しいモバイルネットワークを介してNB-IoTデバイス101にデータを送信し得る。
ステップ623において、プロファイル管理サーバ107は、任意選択として、動作の結果について報告する応答をD/C管理サーバ109に提供する。例えば、プロファイル管理サーバ107は、プロファイルが有効化されたか否かを報告し得る。
プロファイルの有効化が成功し、プロファイルが新しいモバイルネットワークオペレータにあることに応答して、D/C管理サーバ109は、ステップ624において、新しいモバイルネットワークオペレータからのサービスを使用するように切り替えるようにプロキシサーバ108に命令し得る。例えば、プロキシサーバ108は、プロファイルが変更された特定のNB-IoTデバイスの新しいモバイルネットワークで公開機能(例えば、SCEF)および/またはP-GWを使用するように切り替えるように命令され得る。新しいモバイルネットワークへの登録は、以前に(例えば、ステップ610において)行われている可能性がある。NB-IoTデバイスのデバイス識別子は、使用される様々なMNOサービス(SCEF、P-GWなど)へのURLとともに提供され得る。
ステップ625において、プロキシサーバ108は、プロキシサーバ108の設定を、アプリケーションサーバからNB-IoTデバイス101へのデータが今度は新しいモバイルネットワークを介して転送されるように変更し得る。プロキシサーバ108はまた、古いモバイルネットワークサービスから登録解除し得る。
図6は、SMSサービスが提供されておらず、NIDDが使用され得るNB-IoTデバイス101の場合に、プロファイル管理サーバのSM-SR部分とeUICCとの間の通信がどのように実行されるかを示す例示的なフローである。図6は、HTTPSセッションを使用した「SMS」配信およびデータ配信がどのようにハンドリングされるかを示す。CAT_TPセッションは、HTTPSと同じ方法でハンドリングされる。同じ技法を用いて、すべてのGSMA RSP M2M版フローを適宜に適合させることができる。
いくつかの実施形態において、プロファイルダウンロードおよびプロファイル管理は、GSMA RSP消費者版により実行される。この場合、プロファイル管理サーバ107は、SM-DP+として知られている。SM-DP+107は、企業が新しい加入プロファイルを申し込んだMNOによって運用され得るか、またはSM-DP+107は、サードパーティによって運用され得、MNOに提供されるサービスの一部であり得る。SM-DP+107が、MNOが使用するサードパーティによって提供されるサービスである例では、D/C管理サーバ109をSM-DP+とリンクするプロファイル管理動作用の顧客向けのインターフェースを提供するMNOポータルも、プロファイル管理サーバの一部として含まれる。この例を図7に示す。
D/C管理サーバ109は、NB-IoTデバイス101内のローカルプロファイルアシスタント(LPAd)700を介して、プロファイルダウンロードおよびプロファイル管理動作をリモートで制御し得る。LPAd70は、識別情報モジュールとの対話およびプロファイル管理サーバ107との対話をハンドリングする。LPAd700と、D/C管理サーバ109とプロファイル管理サーバ107との両方との間でセキュア通信が確立され得る。SM-DP+107とMNOポータルとの間の個々の通信は、GSMA RSP標準に従うことができ、したがって本明細書では、通信のこの部分の詳細は提供されていない。LPAd700とSM-DP+107との間のセキュア通信トンネル内で実行され得る識別情報モジュールとSM-DP+107との間の通信についても同様である。
SM-DP+107とLPAd700との間のセキュア通信は、HTTPSに基づき得、LPAd700とD/C管理サーバ109との間のセキュア通信は、トランスポート層セキュリティ(TLS)/データグラムTLS(DTLS)、または制約付きRESTful環境のためのオブジェクトセキュリティ(OSCORE:Object Security for Constrained RESTful Environments)に基づき得る。
図7は、図5に示したフローの一例を示す。具体的には、図7は、GSMA RSP消費者版が使用されている例の図5のフローを示す。通信フローは、プロファイルダウンロードトークン情報を取得した後にトリガメッセージがD/C管理サーバ109を介してルーティングされるように変更され得る。
NB-IoTデバイス101(例えば、eUICC)の識別情報モジュールは、NB-IoTデバイス101がセルラネットワークに接続することを可能にするアクティブなセルラ加入(すなわち、有効化されたプロファイル)を有するように設定され得る。これは、動作プロファイルの提供を可能にする目的で製造時にインストールされたプロファイルであり得るか、または以前にNB-IoTデバイス101によってダウンロードされた動作プロファイルであり得る。
HSS106は、NB-IoTデバイス101の加入者資格情報を有するように設定され得る。加入者資格情報は、公開機能104(例えば、SCEF)を介してデバイスをアドレス指定するために使用される外部識別子を含み得る。プロキシサーバ108は、NB-IoTデバイス101をアドレス指定することが可能な外部識別子を有するように設定され得る。プロファイル管理サーバ107は、ダウンロード可能であり得るプロファイルパッケージのセットを含み得る。企業が、1つまたは複数のNB-IoTデバイスを所有して、プロファイル管理サーバ107のMNOポータルを介して企業のデバイスのプロファイルを申し込んだ後に、プロファイル管理サーバによるこれらのプロファイルの準備が続き、企業は、企業のデバイスにデバイス識別を提供している場合がある。次いで、対応するプロファイルダウンロード情報(すなわち、プロファイルパッケージに対するプロファイル識別子)は、NB-IoTデバイスを所有する企業に提供され得、D/C管理サーバ109に提供され得る。所与のプロファイルパッケージについて、プロファイルに対応するモバイルネットワークのHSS106は、プロファイルパッケージの加入者資格情報に対応する加入者資格情報、およびNB-IoT101の外部識別子を有するように設定される。
ステップ701およびステップ702は、上記のようにプロファイルダウンロード情報を取得するD/C管理サーバ109に関する。ステップ701において、D/C管理サーバ109は、プロファイルダウンロード情報を取得するためのコマンドをプロファイル管理サーバ107(MNOポータル部分)に送信する。ステップ701において、D/C管理サーバ109は、少なくとも、プロファイルがダウンロードされるNB-IoTデバイス101のデバイス識別子を提供し得る。デバイス識別子は、プロファイル管理サーバ107によって、プロファイルのダウンロードがトリガされるべきデバイスを識別するために使用される。この例では、デバイス識別子は、eUICC ID(EID)または国際移動体機器識別情報(IMEI:International Mobile Equipment Identity)を含む。
ステップ702において、プロファイル管理サーバ107は、SM-DP+107のアドレスおよびプロファイルダウンロード識別子を含むメッセージをD/C管理サーバ109に送信する。アドレスおよびプロファイルダウンロード識別子は、アクティベーションコードの形式で提供され得る。アクティベーションコードは、企業によって他の方法で取得され、次いでD/C管理サーバ109に設定され得ることに留意されたい。その場合、ステップ701およびステップ702は実行されない可能性がある。
ステップ703において、D/C管理サーバ109は、トリガメッセージをNB-IoTデバイス101に配信するよう求める要求をプロキシサーバ108に送信し、要求は、デバイス識別子を含む(ステップ703は、図2のステップ201に対応し得る)。
ステップ704において、プロキシサーバ108は、ステップ703で受信したデバイス識別子によって識別されるNB-IoTデバイスにトリガメッセージを配信する。具体的には、プロキシサーバ108は、ステップ703で受信したデバイス識別子に基づいて外部識別子を決定し得る。デバイス識別子が外部識別子と異なる場合、プロキシサーバ108は、提供されたデバイス識別子を使用してデータベース内の外部識別子を検索する。次いで、ステップ704は、図4に示すように実施され得る。
ステップ705において、NB-IoTデバイス101内のデバイスアプリケーション(例えば、LPAd700)は、デバイスとD/C管理サーバとの間のセキュア通信の確立をトリガする。NB-IoTデバイスのタイプに応じて、様々なプロトコルが使用され得る。例えばIPベースの通信を使用するNB-IoTデバイスの場合、ステップ705は、TLS/DTLSを使用することができ、CoAPを使用するNB-IoTデバイスの場合、ステップ705は、OSCOREを利用することができる。OSCOREが使用される場合、例えばEDHOCを使用して共通のセキュリティコンテキストがすでに確立されている可能性があり、OSCOREが直接使用され得ることに留意されたい。代替として、OSCOREセキュリティコンテキストの確立に、COSEによる一時的なDiffie-Hellman法(EDHOC:Ephemeral Diffie-Hellman Over COSE)が使用されてもよい。ステップ705は、ステップ704が実行される場合にのみ実行され得る。
ステップ706において、D/C管理サーバ109は、アクティベーションコードをLPAd700にセキュアに配信する。
ステップ707において、NB-IoTデバイス101(例えば、LPAd700)は、プロファイル管理サーバ107とのセキュア通信(例えば、相互認証を含む)を確立する。例えば、LPAd700は、アクティベーションコード内のアドレスを利用して、プロファイル管理サーバ107との通信を確立し得る。具体的には、ステップ707は、GSMA RSP消費者版によるHTTPSセッションの確立を含み得る。本明細書の実施形態は、2つのエンドポイント、例えばプロファイル管理サーバ(SM-DP+部分)107およびLPAd700が修正を必要とせず、それらの間で転送されるHTTPSメッセージを交換できることを保証し得る。メッセージの転送方法についての詳細を以下に説明する。
ステップ708において、NB-IoTデバイス101は、プロファイル管理サーバ107からプロファイルパッケージをダウンロードする。次いで、NB-IoTによって、プロファイルパッケージが識別情報モジュールにインストールされ得る。例えば、ステップ708は、プロファイル管理サーバからプロファイルを受信することと、プロファイルを識別情報モジュールにインストールすることとを含み得る。この例では、プロファイル管理サーバ(SM-DP+)とLPAdとの間のセキュアなトンネル内ですべて交換される一連のメッセージからなる標準GSMA RSPプロトコル消費者版に従って、プロファイルパッケージがデバイスにダウンロードされ、識別情報モジュールにインストールされ、LPAdは、識別情報モジュールとの対話をハンドリングする。この一連のメッセージは、(一致識別子と呼ばれる)プロファイル識別子および/またはEIDをプロファイル管理サーバに提供するLPAdを含み、これにより、プロファイル管理サーバは、この特定のデバイスについて、準備済みプロファイルパッケージのセット内のどのプロファイルパッケージをダウンロードすべきかを認識する。
ステップ709において、LPAd700は、任意選択として、トリガメッセージの結果について報告する応答をD/C管理サーバ109に提供し得る。例えば、LPAd700は、プロファイルがNB-IoTデバイス101に正常にダウンロードされたか否かをD/C管理サーバ109に示し得る。この応答は、プロファイルに関連するプロファイル管理動作で使用するプロファイル識別子ICCIDを含み得る。
この例では、プロファイルは、新しいモバイルネットワークのプロファイルである。したがって、この例では、D/C管理サーバ109は、ステップ710において、NB-IoTデバイス101について新しいモバイルネットワークに切り替えるよう求める要求をプロキシサーバ108に送信し得る。例えば、新しいモバイルネットワークに切り替えるよう求める要求は、プロキシサーバが、新しいモバイルネットワークに属するP-GWなどを公開機能に登録することを求める要求を含み得る。要求には、プロキシサーバが登録するよう要求されているMNOサービスのURLが含まれ得る。要求には、デバイス識別子も含まれ得る。P-GWの場合、プロキシサーバはプロファイルの申込み/準備フェーズからNIDDで使用するように事前設定されている可能性があり、その場合このステップは省略され得ることに留意されたい。
ステップ710に応答して、プロキシサーバは、ステップ711において、新しいモバイルネットワークに登録し得る。例えば、プロキシサーバ108は、NB-IoTデバイス101から送信された任意のデータが新しいモバイルネットワークを介してアプリケーションサーバにルーティングされ得るように、新しいモバイルネットワークに登録し得る。登録が行われると、プロキシサーバ108は、古いモバイルネットワークを介してNB-IoTデバイスにデータを送信するように設定されたまま、新しいプロファイルが有効化されて切り替えが完了した状態が確立されるまで、すなわち、プロキシサーバは、新しいモバイルネットワークを介してNB-IoTデバイスにデータを送信するように設定されるまで、両方のモバイルネットワークを介してNB-IoTデバイスからデータを受信することが可能になり得る。
この例では、プロファイルは、NB-IoTへのプロファイルのダウンロードとは別に有効化され得る。したがって、この例では、ステップ708において、プロファイルがダウンロードされ得、ステップ712において、D/C管理サーバ109が、プロファイルの有効化をトリガするよう求める要求をプロキシサーバ108に送信し得る。要求は、デバイス識別子を含み得る。ステップ712は、D/C管理サーバ107とNB-IoTデバイス101との間に確立されたセキュア通信がまだない場合、およびステップ703のトリガメッセージが実行されるべきプロファイルダウンロードとダウンロードされたプロファイルの有効化との両方をまだ示していない場合にのみ実行され得る。
ステップ713において、プロキシサーバ108は、ステップ712で受信したデバイス識別子によって識別されるNB-IoTデバイス101に、ダウンロードされたプロファイルの有効化をトリガするためのメッセージを配信する。上記のように、このステップでは、トリガメッセージは、図4で説明されているようにNB-IoTデバイスに配信され得る。ステップ713は任意であり、ステップ712が実行されない場合、実行されない可能性がある。
ステップ714において、デバイスアプリケーション(例えば、LPAd700)は、NB IoTデバイス101とD/C管理サーバ107との間のセキュア通信の確立をトリガする。デバイスのタイプに応じて、様々なプロトコルが使用され得る。例えばIPベースの通信を使用するNB-IoTデバイスの場合、ステップ714は、TLS/DTLSを使用することができ、CoAPを使用するNB-IoTデバイスの場合、ステップ714は、OSCOREを利用することができる。OSCOREが使用される場合、例えばEDHOCを使用して共通のセキュリティコンテキストがすでに確立されている可能性があり、OSCOREが直接使用され得ることに留意されたい。代替として、OSCOREセキュリティコンテキストの確立にEDHOCが使用されてもよい。ステップ714は、ステップ713が実行される場合にのみ実行され得る。
ステップ715において、D/C管理サーバ109は、新しいプロファイルの有効化をトリガするためのメッセージをLPAd700に送信する。このメッセージは、ステップ703のトリガメッセージが、ダウンロードされたプロファイルの実行されるべき有効化も示した場合、省略され得る。プロファイル識別子ICCIDもメッセージの一部として提供され得る。
ステップ716において、LPAd700は、識別情報モジュールで提供されたプロファイル識別子を用いてプロファイルの有効化をトリガする。
ステップ717において、識別情報モジュールは新しいプロファイルを有効化する。
ステップ718において、プロファイルの有効化が成功すると、新しいネットワークへの連結が実行される(この例のように、新しいプロファイルは新しいモバイルネットワークを伴う)。
ステップ719において、LPAd700は、プロファイルの有効化が成功したかどうかを示す応答をD/C管理サーバに提供する。
ステップ719での応答の配信において、プロキシサーバ108は、新しいモバイルネットワークを介してNB-IoTデバイス101からトラフィックを受信する。次いで、プロキシサーバ108は、ステップ720において、NB-IoTデバイス101のモバイルネットワークを切り替えることを決定することができ、これから先は、新しいモバイルネットワークを介してNB-IoTデバイス101にデータを送信することができる。
プロファイルの有効化が成功し、プロファイルが新しいモバイルネットワークオペレータにあることに応答して、D/C管理サーバ109は、ステップ721において、新しいモバイルネットワークオペレータからのサービスを使用するように切り替えるようにプロキシサーバ108に命令し得る。例えば、プロキシサーバ108は、プロファイルが変更された特定のNB-IoTデバイスの新しいモバイルネットワークで公開機能(例えば、SCEF)および/またはP-GWを使用するように切り替えるように命令され得る。新しいモバイルネットワークへの登録は、以前に(例えば、ステップ711において)行われている可能性がある。NB-IoTデバイスのデバイス識別子は、使用される様々なMNOサービス(SCEF、P-GWなど)へのURLとともに提供され得る。
ステップ722において、プロキシサーバ108は、プロキシサーバ108の設定を、アプリケーションサーバからNB-IoTデバイス101へのデータが今度は新しいモバイルネットワークを介して転送されるように変更し得る。プロキシサーバ108はまた、古いモバイルネットワークサービスから登録解除し得る。
申込み時にEIDまたは他のデバイス識別子を提供せずに1つまたは複数のデバイスのプロファイルを申し込むことが可能であり、プロファイルダウンロード時に、プロファイルと特定のNB-IoTデバイスとの結び付けが発生することに留意されたい。D/C管理サーバは、例えば、ステップ703の前に、1組のNB-IoTデバイスのためのアクティベーションコードのセットを有するように設定され得、ステップ706で使用するために、このセットの中から1つのアクティベーションコードを選択し得る。次いで、どのプロファイルをどのNB-IoTデバイスに送信するかをD/C管理サーバが決定する。次に、プロファイル識別子およびデバイス識別子とEIDとの間の結び付けは、SM-DP+がデバイスからEIDおよびIMEIを受信するステップ708においてプロファイルダウンロード時に行うことができ、この結び付けは、MNOに報告され得る。
図7は、NIDDを使用できるNB-IoTデバイスの場合に、SM-DP+とNB-IoTデバイス(例えば、識別情報モジュール)との間の通信がどのように実行されるかを示すフローの一例を示す。同じ技法を用いて、すべてのGSMA RSP消費者版フローを適宜に適合させることができる。
いくつかの実施形態において、プロファイルダウンロードおよびプロファイル管理は、IoTに適合したGSMA RSP消費者版による。ここで、LPAd700は2つの部分に分割され、主要部分であるLPAprは、デバイスからD/C管理サーバ109に移動され、小部分であるLPAdv800は、識別情報モジュールとの通信のためにNB-IoTデバイス101内に残る。この場合、HTTPSベースの通信は、D/C管理サーバ内のLPAprによってハンドリングされ、これにより、NB-IoTデバイス101の複雑さが軽減され、プロキシサーバ108も簡素化され得る。D/C管理サーバとLPAdvとの間のメッセージは、eUICCとの通信に関連するメッセージに対応し得る。
図8は、図5のプロファイルダウンロードおよびプロファイル有効化のフローの一例を示す図であり、フローは、GSMA RSPの適合された消費者版用に再描画されている。
NB-IoTデバイス101(例えば、eUICC)の識別情報モジュールは、NB-IoTデバイス101がセルラネットワークに接続することを可能にするアクティブなセルラ加入(すなわち、有効化されたプロファイル)を有するように設定され得る。これは、動作プロファイルの提供を可能にする目的で製造時にインストールされたプロファイルであり得るか、または以前にNB-IoTデバイス101によってダウンロードされた動作プロファイルであり得る。
HSS106は、NB-IoTデバイス101の加入者資格情報を有するように設定され得る。加入者資格情報は、公開機能104(例えば、SCEF)を介してデバイスをアドレス指定するために使用される外部識別子を含み得る。プロキシサーバ108は、NB-IoTデバイス101をアドレス指定することが可能な外部識別子を有するように設定され得る。プロファイル管理サーバ107は、ダウンロード可能であり得るプロファイルパッケージのセットを含み得る。企業が、1つまたは複数のNB-IoTデバイスを所有して、プロファイル管理サーバ107のMNOポータルを介して企業のデバイスのプロファイルを申し込んだ後に、プロファイル管理サーバによるこれらのプロファイルの準備が続き、企業は、企業のデバイスにデバイス識別を提供している場合がある。次いで、対応するプロファイルダウンロード情報(すなわち、プロファイルパッケージに対するプロファイル識別子)は、NB-IoTデバイスを所有する企業に提供され得、D/C管理サーバ109に提供され得る。所与のプロファイルパッケージについて、プロファイルに対応するモバイルネットワークのHSS106は、プロファイルパッケージの加入者資格情報に対応する加入者資格情報、およびNB-IoT101の外部識別子を有するように設定される。
ステップ801およびステップ802は、上記のようにプロファイルダウンロード情報を取得するD/C管理サーバ109に関する。ステップ801において、D/C管理サーバ109は、プロファイルダウンロード情報(例えば、アクティベーションコード)を取得するためのコマンドをプロファイル管理サーバ107(MNOポータル部分)に送信する。ステップ801において、D/C管理サーバ109は、少なくとも、プロファイルがダウンロードされるNB-IoTデバイス101のデバイス識別子を提供し得る。デバイス識別子は、プロファイル管理サーバ107によって、プロファイルのダウンロードがトリガされるべきデバイスを識別するために使用される。この例では、デバイス識別子は、eUICC ID(EID)またはIMEIを含む。
ステップ802において、プロファイル管理サーバ107は、SM-DP+107のアドレスおよびプロファイルダウンロード識別子を含むメッセージをD/C管理サーバ109に送信する。アドレスおよびプロファイルダウンロード識別子は、アクティベーションコードの形式で提供され得る。アクティベーションコードは、企業によって他の方法で取得され、次いでD/C管理サーバ109に設定され得ることに留意されたい。その場合、ステップ801およびステップ802は実行されない可能性がある。
ステップ803において、D/C管理サーバ109は、トリガメッセージをNB-IoTデバイス101に配信するよう求める要求をプロキシサーバ108に送信し、要求は、デバイス識別子を含む(ステップ803は、図2のステップ201に対応し得る)。デバイスがすでにD/C管理サーバに登録されており、デバイスとD/C管理サーバとの間でセキュア通信がすでに確立されている場合、このステップは省略され得る。
ステップ804において、プロキシサーバ108は、ステップ803で受信したデバイス識別子によって識別されるNB-IoTデバイスにトリガメッセージを配信する。具体的には、プロキシサーバ108は、ステップ803で受信したデバイス識別子に基づいて外部識別子を決定し得る。デバイス識別子が外部識別子と異なる場合、プロキシサーバ108は、提供されたデバイス識別子を使用してデータベース内の外部識別子を検索する。次いで、ステップ804は、図4に示すように実施され得る。
ステップ805において、NB-IoTデバイス101内のデバイスアプリケーション(例えば、LPAdv800)は、デバイスとD/C管理サーバとの間のセキュア通信の確立をトリガする。NB-IoTデバイスのタイプに応じて、様々なプロトコルが使用され得る。例えばIPベースの通信を使用するNB-IoTデバイスの場合、ステップ805は、TLS/DTLSを使用することができ、CoAPを使用するNB-IoTデバイスの場合、ステップ805は、OSCOREを利用することができる。OSCOREが使用される場合、例えばEDHOCを使用して共通のセキュリティコンテキストがすでに確立されている可能性があり、OSCOREが直接使用され得ることに留意されたい。代替として、OSCOREセキュリティコンテキストの確立にEDHOCが使用されてもよい。ステップ805は、ステップ804が実行される場合にのみ実行され得る。
ステップ806において、D/C管理サーバの一部であるLPAprは、プロファイル管理サーバ107とのセキュア通信(相互認証を含む)を確立することによって、プロファイルダウンロードフローを開始する。GSMA RSP消費者版によれば、ステップ806は、HTTPSセッションの確立を含み得る。
ステップ807において、プロファイル管理サーバ(SM-DP+)とD/C管理サーバのLPAprとの間、およびD/C管理サーバとデバイス(LPAdv)との間のセキュアなトンネル内ですべて交換される一連のメッセージからなる、IoT用に適合されたGSMA RSPプロトコル消費者版に従って、プロファイルパッケージがデバイスにダウンロードされ、eUICCにインストールされ、LPAdv800は、識別情報モジュール(例えば、eUICC)との対話をハンドリングする。この一連のメッセージは、(一致識別子と呼ばれる)プロファイル識別子および/または識別情報モジュールのEIDをプロファイル管理サーバに提供するLPAprを含み、これにより、プロファイル管理サーバは、この特定のデバイスについて、準備済みプロファイルパッケージのセット内のどのプロファイルパッケージをダウンロードすべきかを認識する。プロファイルダウンロードを成功させる一環として、LPAprは、プロファイルに関連するプロファイル管理動作で使用するプロファイル識別子ICCIDを取得する。
この例では、プロファイルは、新しいモバイルネットワークのプロファイルである。したがって、この例では、D/C管理サーバ109は、ステップ808において、NB-IoTデバイス101について新しいモバイルネットワークに切り替えるよう求める要求をプロキシサーバ108に送信し得る。例えば、新しいモバイルネットワークに切り替えるよう求める要求は、プロキシサーバが、新しいモバイルネットワークに属するP-GWなどを公開機能に登録することを求める要求を含み得る。要求には、プロキシサーバが登録するよう要求されているMNOサービスのURLが含まれ得る。要求には、デバイス識別子も含まれ得る。P-GWの場合、プロキシサーバはプロファイルの申込み/準備フェーズからNIDDで使用するように事前設定されている可能性があり、その場合このステップは省略され得ることに留意されたい。
ステップ808に応答して、プロキシサーバは、ステップ809において、新しいモバイルネットワークに登録し得る。例えば、プロキシサーバ108は、NB-IoTデバイス101から送信された任意のデータが新しいモバイルネットワークを介してアプリケーションサーバにルーティングされ得るように、新しいモバイルネットワークに登録し得る。登録が行われると、プロキシサーバ108は、古いモバイルネットワークを介してNB-IoTデバイスにデータを送信するように設定されたまま、新しいプロファイルが有効化されて切り替えが完了した状態が確立されるまで、すなわち、プロキシサーバは、新しいモバイルネットワークを介してNB-IoTデバイスにデータを送信するように設定されるまで、両方のモバイルネットワークを介してNB-IoTデバイスからデータを受信することが可能になり得る。
この例では、プロファイルは、NB-IoTへのプロファイルのダウンロードとは別に有効化され得る。したがって、この例では、ステップ807において、プロファイルがダウンロードされ得、ステップ810において、D/C管理サーバ109が、プロファイルの有効化をトリガするよう求める要求をプロキシサーバ108に送信し得る。要求は、デバイス識別子を含み得、LPAdv通信を指示し得る。このステップは、D/C管理サーバ109とNB-IoTデバイス101との間に確立されたセキュア通信がまだない場合にのみ実行され得る。
ステップ811において、プロキシサーバ108は、ステップ810で受信したデバイス識別子によって識別されるNB-IoTデバイス101に、ダウンロードされたプロファイルの有効化をトリガするためのメッセージを配信する。上記のように、このステップでは、トリガメッセージは、図4で説明されているようにNB-IoTデバイスに配信され得る。ステップ811は任意であり、ステップ810が実行されない場合、実行されない可能性がある。
ステップ812において、デバイスアプリケーション(例えば、LPAdv801)は、NB IoTデバイス101とD/C管理サーバ107との間のセキュア通信の確立をトリガする。デバイスのタイプに応じて、様々なプロトコルが使用され得る。例えばIPベースの通信を使用するNB-IoTデバイスの場合、ステップ812は、TLS/DTLSを使用することができ、CoAPを使用するNB-IoTデバイスの場合、ステップ812は、OSCOREを利用することができる。OSCOREが使用される場合、例えばEDHOCを使用して共通のセキュリティコンテキストがすでに確立されている可能性があり、OSCOREが直接使用され得ることに留意されたい。代替として、OSCOREセキュリティコンテキストの確立にEDHOCが使用されてもよい。ステップ812は、ステップ811が実行される場合にのみ実行され得る。
ステップ813において、D/C管理サーバ109(例えば、LPApr)は、新しいプロファイルの有効化をトリガするためのメッセージをLPAdv800に送信する。プロファイル識別子ICCIDもメッセージの一部として提供され得る。
ステップ814において、LPAdv800は、識別情報モジュールで提供されたプロファイル識別子を用いてプロファイルの有効化をトリガし、識別情報モジュールは、プロファイルを有効化する。
ステップ815において、プロファイルの有効化が成功すると、新しいネットワークへの連結が実行される(この例のように、新しいプロファイルは新しいモバイルネットワークを伴う)。
ステップ816において、LPAdv800は、プロファイルの有効化が成功したかどうかを示す応答をD/C管理サーバ109に提供する。
ステップ816での応答の配信において、プロキシサーバ108は、新しいモバイルネットワークを介してNB-IoTデバイス101からトラフィックを受信する。次いで、プロキシサーバ108は、ステップ817において、NB-IoTデバイス101のモバイルネットワークを切り替えることを決定することができ、これから先は、新しいモバイルネットワークを介してNB-IoTデバイス101にデータを送信することができる。
プロファイルの有効化が成功し、プロファイルが新しいモバイルネットワークオペレータにあることに応答して、D/C管理サーバ109は、ステップ818において、新しいモバイルネットワークオペレータからのサービスを使用するように切り替えるようにプロキシサーバ108に命令し得る。例えば、プロキシサーバ108は、プロファイルが変更された特定のNB-IoTデバイスの新しいモバイルネットワークで公開機能(例えば、SCEF)および/またはP-GWを使用するように切り替えるように命令され得る。新しいモバイルネットワークへの登録は、以前に行われている可能性がある。NB-IoTデバイスのデバイス識別子は、使用される様々なMNOサービス(SCEF、P-GWなど)へのURLとともに提供され得る。
ステップ819において、プロキシサーバ108は、プロキシサーバ108の設定を、アプリケーションサーバからNB-IoTデバイス101へのデータが今度は新しいモバイルネットワークを介して転送されるように変更し得る。プロキシサーバ108はまた、古いモバイルネットワークサービスから登録解除し得る。
図8は、NIDDを使用できるNB-IoTデバイスの場合に、SM-DP+とNB IoTデバイス101/識別情報モジュールとの間の通信がどのように実行されるかを示すフローの一例である。同じ技法を用いて、IoTに適合したすべてのGSMA RSP消費者版フローを適宜に適合させることができる。
デバイスとの間でデータを送受信する(デバイスタイプ1&2)
このセクションでは、NB-IoTデバイス101との間でデータを送受信する方法について説明する。プロキシサーバ108は、アプリケーションサーバからNB IoTデバイスにメッセージを送信するサービスと、NB-IoTデバイスからアプリケーションサーバにメッセージを中継し、応答メッセージを返すプロキシサービスとを提供する。これらのサービスは、NIDDを使用するNB-IoTデバイス向けである。IPベースのトラフィックを使用するデバイスの場合、通信は、典型的には、プロキシサーバ108を介さない。代わりに、モバイルネットワークによって提供される標準のIPベースのトラフィック配信が使用されるが、ここではこれ以上検討しない。
NIDDの場合、公開機能104またはP-GW102のいずれかを介するとき、モバイルネットワークは、NB-IoTデバイス101と公開機能104/P-GW102との間の高信頼トランスポートを提供しない。これは、高信頼トランスポートを保証するために、NB-IoTデバイス101内のデバイスアプリケーションとプロキシサーバ108との間で使用されるプロトコルが必要になり得ることを意味する。制約付きアプリケーションプロトコル(CoAP)は、アプリケーション関連のメッセージを転送するために制約付きIoTデバイスにおいて一般的に使用されるプロトコルである。CoAPは信頼性を提供する。したがって、通信にCoAPを使用すると、信頼性が確保される。CoAPを使用しない場合、モバイルネットワークによって提供される高信頼データサービス(RDS)プロトコルを使用して、デバイスと公開機能104/P-GW102との間の高信頼通信を実現することができる。
別の問題は、NIDDを実行している各NB-IoTデバイスが複数のアプリケーションサーバとどのように通信し得るかである。CoAPは、メッセージの対象受取側に関する情報をプロキシサーバに提供するために利用できる、Uri-HostおよびUri-PortというCoAPオプションを含む。RDSは、NB-IoTデバイスのどのアプリケーションに対してどのアプリケーションサーバがメッセージを交換するかを示すために使用できるポートの使用をサポートする。ポートの使用を調整するかどうかは、サーバ、およびデバイスのアプリケーション次第である。
重要なことは、提供されるソリューションがNB-IoTデバイス101とアプリケーションサーバとの間のエンドツーエンドのセキュリティを可能にすることである。OSCOREは、CoAPが使用される通信を確保する際に使用され得るCoAPメッセージを保護するためのプロトコルである。プロキシサーバ108でのルーティング目的でCoAPを使用するとき、DTLSまたはTLSを使用してメッセージをエンドツーエンドで確保することができない場合がある。
CoAPを使用した、公開機能を介したNIDDによるプロキシサーバのハンドリング(デバイスタイプ1)
このセクションでは、公開機能(例えば、SCEF)を介してNIDDを使用するNB-IoTデバイスおよびアプリケーションサーバがプロキシサーバ108を介して相互にCoAPメッセージをどのように送信できるかについて説明する。
NB-IoTデバイスがNIDDを使用してアプリケーションサーバにメッセージを送信するとき、アプリケーションサーバに関する情報をプロキシサーバ108に提供することが必要とされ得る。CoAPは、サーバURIに関する情報を提供できるCoAPオプションを使用している。これらは、Uri-Host、Uri-Port、Uri-Path、およびUri-Queryである。アプリケーションサーバとNB-IoTデバイスとの間でOSCOREにより保護されたメッセージを使用する場合、Uri-PathおよびUri-Queryは暗号化および完全性保護され、CoAPメッセージの受信者(この場合はアプリケーションサーバ)のみが読み取ることができる。Uri-HostおよびUri-Portは、保護されたCoAPメッセージに含まれてもよく、その場合、プロキシサーバ108が情報を読み取ることができるように、暗号化も完全性保護もされない場合がある。通常、Uri-HostおよびUri-PortがIPアドレスおよびUDP/TCPポートを示す場合、UDP層またはTCP層から情報を推測できるため、これらのオプションは省略される。しかしながら、この場合、プロキシ動作が機能するように、各CoAP要求メッセージ内には、NB-IoTデバイスによって、少なくともUri-Hostオプション、場合によってはUri-Portオプションも含まれ得る。図9にフローを示す。
図9は、公開機能104を介して、NIDDを使用してNB-IoTデバイスからアプリケーションサーバにCoAP要求を送信することを示す。
NB-IoTデバイス101内のデバイスアプリケーションは、CoAP要求を準備する。この例では、受取側の情報を提供するために、Uri-Hostおよび場合によりUri-PortがCoAP要求に含まれる。
ステップ901において、デバイスアプリケーションは、NIDDサービスを使用してCoAP要求を送信する。CoAP要求は、MME105に配信される。
ステップ902において、MME105は、CoAP要求を公開機能104(この例ではSCEF)に送信する。MMEは、転送されるメッセージにデバイス識別子(例えば、ISMI)を含めることができる。
ステップ903において、公開機能は、デバイスの外部識別子を求める要求をHSS106に送信する。要求は、ステップ902で受信したデバイス識別子を含む。
ステップ904において、HSSは、受信されたデバイス識別子に基づいて外部識別子を検索し、外部識別子を公開機能104に送信する。
ステップ905において、公開機能104は、外部識別子を含むCoAP要求をプロキシサーバに転送する。
ステップ906において、プロキシサーバ108は、CoAP要求メッセージのUri-HostおよびUri-Port番号に基づいて、CoAP要求をどこに送信するかを決定する(送信先のIPアドレスおよびUDP/TCPポート番号は、場合によってはDNS検索を介して取得され得る)。プロキシサーバ108は、ネットワークアドレス変換(NAT:Network Address Translation)を実行し、要求メッセージを送信する各NB-IoTデバイスにIPアドレスおよびポート番号を割り当てる。各NB-IoTデバイスは、一意のIPv6アドレスまたはIPv4アドレス+ポート番号を取得し得る。これらは、CoAP要求メッセージを転送するときに送信元アドレスとして使用される。プロキシサーバ108は、上記で決定された情報を使用して、TCP/IPまたはUDP/IPヘッダをCoAP要求に追加することができ、ステップ907において、CoAP要求をアプリケーションサーバ900に転送する。プロキシサーバ108は、NB-IoTデバイス101の割り当てられたIPv6/IPv4アドレス+ポートおよび外部識別子またはMSISDNのマッピングを格納する。
ステップ908において、アプリケーションサーバ900は、CoAP要求メッセージを処理し、ステップ909において、CoAP応答メッセージを提供する。応答は、使用されるIPアドレスおよびポートに基づいてプロキシサーバ108に戻るようにルーティングされる。
ステップ910において、プロキシサーバ108は、応答メッセージの送信先のアドレスおよびポートを使用して、NB-IoTデバイス101の外部識別子またはMSISDNを検索し、CoAP応答からTCP/IPヘッダまたはUDP/IPヘッダを削除する。ステップ911において、プロキシサーバ108は、公開機能NIDDのデータ送信コマンドを使用して、外部識別子またはMSISDNを示しながら、CoAP応答メッセージをデータとして送信する。
ステップ912において、公開機能は、NB-IoTデバイスのデバイス識別子を求める要求をHSS106に送信する。要求は、ステップ911で受信した外部識別子を含む。
ステップ913において、HSSは、外部識別子に基づいてデバイス識別子を検索し、デバイス識別子(例えば、IMSI)を公開機能104に送信する。
ステップ914において、公開機能NIDDサービスは、CoAP応答メッセージをMMEに転送し、次いで、MMEは、ステップ915において、CoAP応答を対象NB-IoTデバイスに転送し、CoAP応答は、CoAPメッセージIDおよびCoAPトークン値に基づいて、CoAP要求に接続され、デバイスで実行されている正しいアプリケーションに転送され得る。
ここでのCoAP応答の後に、アプリケーションからデバイスへのCoAP要求が続く場合もあり、CoAP要求は、同じCoAPトークンの使用を通してデバイスからのCoAP要求にリンクされる。プロキシサーバは、上記の説明により両方のメッセージを、デバイスへ戻すようにルーティングする。
集中的なデータ交換において各メッセージのために送信されるバイト数を最小限に抑えるために、CoAPのUri-HostおよびUri-Portオプションは、最初のCoAP要求で送信され、その後、NB-IoTデバイスからの将来のCoAP要求メッセージでは省略され得る。プロキシサーバは、Uri-Host、Uri-Port、およびUri-PathオプションなしでCoAP要求メッセージを受信すると、同じNB-IoTデバイスからの最後のメッセージが転送されたのと同じアプリケーションサーバにメッセージを転送するように設定され得る。
プロキシサーバ108は、NB-IoTデバイス101に静的IPv6アドレスを割り当て得るか、またはプロキシサーバ108は、特定のデバイスをアドレス指定するときに使用するアプリケーションサーバのためのCoAPリソースを提示し得る。後者の場合、プロキシサーバ108は、Uri-Path CoAPオプションを使用して、アプリケーションサーバに認識されているリソース名および/またはデバイス識別子を示し得る(デバイス識別子は、リソースの名前であり得る)。この場合、アドレス指定されているNB-IoTデバイスの保護されたUri-Pathオプション関連のリソースに加えて、保護されていないUri-Path CoAPオプションが含まれ得ることに留意されたい。(保護されていないCoAPメッセージの場合、パスの最初の部分は、プロキシサーバ108のリソース名およびデバイス識別子であり得、その後にNB-IoTデバイス上の対象リソースパスが続く)。次いで、プロキシサーバは、保護されていないUri-Pathオプション(または、保護されていないCoAPメッセージの場合はパスの最初の部分)を消費し得る(例えば、転送する前に削除する)。プロキシサーバ108は、静的IPv6アドレスまたはリソース名/デバイス識別子に対する外部識別子のマッピングを格納し得る。プロキシサーバ108は、外部識別子、アプリケーションサーバのIPアドレスおよびポート、ならびにCoAPメッセージIDおよびCoAPトークン値のマッピングも格納し得る。
図10は、公開機能104を介して、NIDDを使用してアプリケーションサーバ900からNB-IoTデバイス101にCoAP要求を送信することを示す。
アプリケーションサーバは、CoAP要求を準備する。IPアドレスまたはUri-Pathオプションは、要求のアドレス指定先であるNB-IoTデバイスを識別する。
ステップ1001において、アプリケーションサーバ900は、CoAP要求をプロキシサーバ108に送信する。
ステップ1002において、プロキシサーバ108は、受信したCoAP要求のIPアドレス、ポート、および場合によっては保護されていないUri-Pathを分析して、CoAP要求がプロキシサーバ108自体に対するものであるか、NB-IoTデバイスに対するものであるかを判定する。NB-IoTデバイスの場合、NB-IoTデバイスの外部識別子は、データベース検索を使用して取得され、プロキシサーバ108は、ステップ1003において、外部識別子を有するCoAP要求を公開機能104に送信する。CoAP要求データをNB-IoTデバイスに送信するために、公開機能NIDDのデータ送信コマンドが使用される。
ステップ1004において、公開機能は、ステップ1003で受信した外部識別子に関連付けられたデバイス識別子を求める要求をHSS106に送信する。
ステップ1005において、公開機能は、対応するデバイス識別子を受信し、この識別子は、この例ではISMIを含む。
ステップ1006において、公開機能104は、デバイス識別子を有するCoAP要求をMME105に送信する。
ステップ1007において、MME105は、CoAP要求をデバイス101に送信する。
ステップ1008において、NB-IoTデバイス101は、要求を処理する。アドレス指定されたリソースに基づいて、正しいアプリケーションが呼び出され、応答が準備される。ステップ1009において、NB-IoTデバイス101は、CoAP応答をMME105に送信する。
ステップ1008において、NB-IoTデバイス101は、CoAP応答を提供し、CoAP要求からのCoAPメッセージIDおよびCoAPトークン値は、標準のCoAP処理により使用される。次いで、CoAP応答は、NIDDを使用して公開機能104に送信され得る。
例えば、ステップ1009において、NB-IoTデバイスは、CoAP応答をMMEに転送し、MMEは、ステップ1010において、CoAP応答をデバイス識別子とともに公開機能に転送する。
ステップ1011において、公開機能104は、ステップ1010で受信したデバイス識別子に関連付けられた外部識別子を求める要求をHSS106に送信する。ステップ1012において、公開機能104は、HSS106から外部識別子を受信する。ステップ1013において、公開機能104は、CoAP応答を外部識別子とともにプロキシサーバ108に転送する。
ステップ1014において、プロキシサーバ108は、CoAP応答を処理する。受信した外部識別子ならびにCoAPメッセージIDおよび/またはCoAPトークンに基づいて、プロキシサーバ108は、データベースから、CoAP応答の転送先となるアプリケーションサーバのIPアドレスおよびポートを決定し得る。プロキシサーバ108は、上記で決定された情報を使用して、CoAP応答にTCP/IPまたはUDP/IPヘッダを追加することができ、ステップ1015において、CoAP応答をアプリケーションサーバ900に転送する。送信元IPアドレスおよびポートは、CoAP要求で使用されているものであり得、外部識別子から決定され得る。
CoAPを使用した、P-GWを介したNIDDによるプロキシサーバのハンドリング(デバイスタイプ2)
このセクションでは、P-GWを介してNIDDを使用するデバイスおよびアプリケーションサーバがプロキシサーバを介して相互にCoAPメッセージをどのように送信できるかについて説明する。
NB-IoTデバイスは、図9を参照して説明した方法と同じ方法でCoAPメッセージを準備し得る。CoAPは、代わりに、NIDDを使用してP-GW102に転送され得る。P-GW102は、UDP/IPヘッダを追加し得、メッセージをプロキシサーバ108に転送し得る。送信元IPアドレスおよびUDPポートは、CoAPメッセージの発信元であるNB-IoTデバイスに対してP-GW102が割り当てたIPアドレスおよびポートであり得る。プロキシサーバ108は、アプリケーションサーバ900のIPアドレスおよびポートを決定し得、図9を参照して説明した方法と同じ方法で、CoAPメッセージをアプリケーションサーバ900に転送し得る。プロキシサーバ108は、P-GW102によって割り当てられたようにNB-IoTデバイス101のIPアドレスを保持し得るか、またはNB-IoTデバイス101に新しいIPアドレスを割り当て、2つのIPアドレス間のマッピングをデータベースに格納し得る。後者の選択肢は、P-GW102で使用されるNB-IoTデバイス101のIPアドレスがモバイルオペレータの変更により変更される一方で、静的アドレスがプロキシサーバ108によって保持され得る場合に有利である。
次に、アプリケーションサーバ900は、CoAP要求を処理し、CoAP応答を提供し得る。CoAP応答は、使用されるIPアドレスおよびポートに基づいてプロキシサーバ108へ戻るようにルーティングされ、プロキシサーバ108によって、さらにP-GW102に(または、元のIPアドレスが保持されている場合は直接P-GW102に)ルーティングされ得る。P-GW102は、CoAP応答のIPアドレスおよびポートに基づいて、CoAP応答の転送先となるNB-IoTデバイスを決定し、UDP/IPヘッダを削除し、CoAP応答を(S-GW103およびMME105を介して)NB-IoTデバイスに転送し得る。NB-IoTデバイスにおいて、CoAP応答は、CoAPメッセージIDおよびCoAPトークン値に基づいてCoAP要求に接続され、NB-IoTデバイスで実行されている正しいアプリケーションに転送され得る。
いくつかの例において、プロキシサーバ108は、アプリケーションサーバがCoAP要求を送信するために使用する静的IPv6アドレスを、NB-IoTデバイスに割り当てていてもよい。プロキシサーバ108は、P-GW102によって割り当てられたようにNB-IoTデバイスのIPアドレスを追跡し得る。これは、外部識別子に基づいてIPアドレスを照会することによって行われ得る。プロキシサーバ108は、P-GW102によって割り当てられたようにIPアドレスを使用してCoAP要求を転送し得る。その場合、非IPトラフィック専用のポートが使用され得る。代替として、プロキシサーバ108は、図10を参照して説明したのと同様に、特定のデバイスをアドレス指定するときに使用するアプリケーションサーバ用のCoAPリソースを提示し得る。プロキシサーバ108は、モバイルコアネットワークサービスを使用して、リソース名に結び付けられた外部識別子に基づいて、NB-IoTデバイスの現在のIPアドレス(および場合によってはポート)を取得し得る。プロキシサーバ108は、(NB-IoTデバイスのIPアドレスを送信先アドレスとして使用して)CoAP要求をP-GW102に転送し得る。次いで、P-GWは、UDP/IPヘッダを削除し、NIDDサービスを使用して(S-GWおよびMMEを介して)メッセージをNB-IoTデバイスに転送し得る。プロキシサーバ108は、デバイスのIPアドレスおよびポート、アプリケーションサーバのIPアドレスおよびポート、ならびにCoAPメッセージIDおよびCoAPトークン値のマッピングを格納し得る。
NB-IoTデバイスは、CoAP応答を提供することができ、CoAP要求からのCoAPメッセージIDおよびCoAPトークン値は、標準のCoAP処理により使用される。CoAP応答は、NIDDを使用してP-GW102に送信され、P-GW102は、UDP/IPヘッダを追加し、CoAP応答をプロキシサーバ108に転送し得る。プロキシサーバ108は、CoAP応答を処理し得る。プロキシサーバ108は、送信元IPアドレスおよびポート、CoAPメッセージIDおよび/またはCoAPトークンに基づいて、データベースから、CoAP応答の転送先となるアプリケーションサーバのIPアドレスおよびポートを決定し得る。
RDSを使用した、SCEFを介したNIDDによるプロキシサーバのハンドリング(デバイスタイプ1)
このセクションでは、SCEFを介してNIDDを使用するデバイスおよびアプリケーションサーバが、RDSが利用される場合、プロキシサーバを介して相互にメッセージをどのように送信できるかについて説明する。RDSは、NB-IoTデバイス101および公開機能104(例えば、SCEF)内に実装される。ここでは、NB-IoTデバイス101およびプロキシサーバ108が、NB-IoTデバイス101およびアプリケーションサーバ900のアプリケーションをリンクするRDSポートのセットを有するように設定されていると仮定する。このような設定は、典型的には、NB-IoTデバイス101およびプロキシサーバ108において、各NB-IoTデバイス101に関連付けられたデバイス管理サーバによって設定され得、実行時に更新され得る。デバイス管理サーバとの通信は、NB-IoTデバイスの製造中に設定され、初めてセットアップされるときにプロキシサーバ108内に設定される、静的RDSポートを使用し得る。
図11は、RDSが使用される場合、公開機能を介して、NIDDを使用してNB-IoTデバイスからアプリケーションサーバに要求メッセージを送信する方法を示す。
ステップ1101において、デバイスアプリケーションは、NIDDサービスを使用して要求メッセージを送信する。RDSプロトコルが使用され、要求メッセージはペイロードであり、RDSポート番号は、要求メッセージがどのアプリケーションサーバを対象としているかにより設定される。要求メッセージはMME105に配信される。
ステップ1102において、MME105は、要求メッセージを公開機能104(この例では、SCEF)に送信する。MME105は、転送されるメッセージにデバイス識別子(例えば、ISMI)を含めることができる。
ステップ1103において、公開機能104は、デバイスの外部識別子を求める要求をHSS106に送信する。要求は、ステップ1102で受信したデバイス識別子を含む。
ステップ1104において、HSS106は、受信されたデバイス識別子に基づいて外部識別子を検索し、外部識別子を公開機能104に送信する。
ステップ1105において、公開機能104は、外部識別子およびRDSポート番号を含む要求メッセージをプロキシサーバ108に転送する。
ステップ1106において、プロキシサーバ108は、外部識別子およびRDSポートから、送信先のIPアドレスおよびポートを決定する。アプリケーションサーバ900のアドレス、および転送方法、例えば、要求メッセージをペイロードとして有するTCP/IPを使用することは、データベースから知られる。プロキシサーバは、上記と同様にNB-IoTデバイスにIPアドレスを割り当てており、IPアドレスと外部識別子との間のマッピングは、プロキシサーバ108によってアクセス可能なデータベースに格納され得る。
ステップ1107において、プロキシサーバは、プロキシサーバ108によってアクセス可能なデータベース内のRDSポート番号に関連付けられたアプリケーションサーバ900に要求メッセージを転送する。
ステップ1108において、アプリケーションサーバ900は、要求メッセージを処理し、ステップ1109において、応答メッセージを提供する。応答メッセージは、使用されるIPアドレスおよびポートに基づいてプロキシサーバ108に戻るようにルーティングされる。
ステップ1110において、プロキシサーバ108は、応答メッセージの送信先のアドレスおよびポートを使用して、NB-IoTデバイス101の外部識別子を検索し、応答メッセージからTCP/IPヘッダまたはUDP/IPヘッダを削除する。ステップ1111において、プロキシサーバ108は、公開機能NIDDのデータ送信コマンドを使用して、外部識別子およびRDSポートを示しながら、応答メッセージをデータ(RDSプロトコルペイロード)として送信する。
ステップ1112において、公開機能は、NB-IoTデバイスのデバイス識別子を求める要求をHSS106に送信する。要求は、ステップ1111で受信した外部識別子を含む。
ステップ1113において、HSSは、外部識別子に基づいてデバイス識別子を検索し、デバイス識別子(例えば、IMSI)を公開機能104に送信する。
ステップ1114において、公開機能NIDDサービスは、応答メッセージをMME105に転送し、次いで、MME105は、ステップ1115において、応答メッセージを対象NB-IoTデバイスに転送し、応答メッセージは、RDSポートに基づいて、デバイスで実行されている正しいアプリケーションに転送される。
プロキシサーバは、デバイスに静的IPv6アドレスを割り当て得るか、またはプロキシサーバは、特定のデバイスをアドレス指定するときに使用するアプリケーションサーバ用のリソースを提示する。後者の場合、アプリケーションサーバはURIを使用して、アプリケーションサーバに認識されているリソース名および/またはデバイス識別子を示し得る(デバイス識別子はリソースの名前であり得る)。プロキシサーバは、静的IPv6アドレスまたはリソース名/デバイス識別子に対する外部識別子またはMSISDNのマッピングを格納している。プロキシサーバは、RDSポート番号およびアプリケーションサーバのIPアドレスまたはドメイン名のマッピングも格納する。
図12は、RDSが使用される場合、公開機能104を介して、NIDDを使用してアプリケーションサーバ900からNB-IoTデバイス101に要求メッセージを送信することを示す。
アプリケーションサーバは、要求メッセージを準備する。IPアドレスまたはプロキシサーバリソースは、要求のアドレス指定先であるNB-IoTデバイスを識別する。
ステップ1201において、アプリケーションサーバ900は、要求メッセージをプロキシサーバ108に送信する。
ステップ1202において、プロキシサーバ108は、受信した要求メッセージのIPアドレス、ポート、および場合によってはURIを分析して、RDS要求がプロキシサーバ108自体に対するものであるか、NB-IoTデバイスに対するものであるかを判定する。NB-IoTデバイスの場合、NB-IoTデバイスの外部識別子は、データベース検索を使用して取得され、プロキシサーバ108は、ステップ1203において、外部識別子を有する要求メッセージを公開機能104に送信する。要求メッセージをNB-IoTデバイスに送信するために、公開機能NIDDのデータ送信コマンドが使用される。RDSポートは、プロキシサーバによって送信元IPアドレスの検索に基づいて設定される。
ステップ1204において、公開機能は、ステップ1203で受信した外部識別子に関連付けられたデバイス識別子を求める要求をHSS106に送信する。
ステップ1205において、公開機能は、対応するデバイス識別子を受信し、この識別子は、この例ではISMIを含む。
ステップ1206において、公開機能104は、デバイス識別子を有する要求メッセージをMME105に送信する。
ステップ1207において、MME105は、要求メッセージをデバイス101に送信する。
ステップ1208において、NB-IoTデバイス101は、要求メッセージを処理する。RDSポートに基づいて、正しいアプリケーションがNB-IoTデバイス101で呼び出され、応答メッセージが準備される。ステップ1209において、NB-IoTデバイス101は、MME105に配信される応答メッセージを送信する。
ステップ1208において、NB-IoTデバイス101は、NIDDを使用して公開機能104に送信され得る応答メッセージを提供する。
例えば、ステップ1209において、NB-IoTデバイス101は、応答メッセージをMME105に転送し、MME105は、ステップ1210において、応答メッセージをデバイス識別子とともに公開機能104に転送する。
ステップ1211において、公開機能104は、ステップ1210で受信したデバイス識別子に関連付けられた外部識別子を求める要求をHSS106に送信する。ステップ1212において、公開機能104は、HSS106から外部識別子を受信する。ステップ1213において、公開機能104は、応答メッセージを、外部識別子およびRDSポート番号とともにプロキシサーバ108に転送する。
ステップ1214において、プロキシサーバ108は、応答メッセージを処理する。受信した外部識別子およびRDSポート番号に基づいて、プロキシサーバ108は、データベースから、応答メッセージの転送先となるアプリケーションサーバのIPアドレスおよびポートを決定し得る。この特定のRDSポートに有効な転送方法、例えばTCP/IPは、データベースから取得され得る。プロキシサーバ108は、ステップ1215において、適切な転送方法により、応答メッセージをアプリケーションサーバ900に転送し得る。送信元IPアドレスおよびポートは、要求メッセージで使用されているものであり得、外部識別子から決定され得る。
RDSを使用した、P-GWを介したNIDDによるプロキシサーバのハンドリング(デバイスタイプ2)
このセクションでは、P-GWを介してNIDDを使用するデバイスとアプリケーションサーバが、RDSが利用される場合、プロキシサーバを介して相互にメッセージをどのように送信できるかについて説明する。RDSポートをP-GWで使用できるかどうか、およびどのように使用できるかは、3GPP仕様では明確に指定されていない。本明細書に記載の実施形態では、ある範囲のユーザデータグラムプロトコル(UDP)ポートを、P-GWでの非IPデータ配信モードに使用することができる。各UDPポートはRDSポートにマッピングされ得る。次いで、RDSポート番号は、異なるUDPポート番号を使用することによって、P-GW102とプロキシサーバ108との間でシグナリングされ得る。
NB-IoTデバイスは、図11を参照して説明した方法と同じ方法で、要求メッセージを準備することができ、要求メッセージは、NIDDを使用してP-GW102に転送され得る。P-GW102は、要求メッセージをプロキシサーバ108に転送し得る。送信元IPアドレスは、要求メッセージの発信元であるNB-IoTデバイス101にP-GW102が割り当てたIPアドレスである。UDP送信元ポート番号は、RDSポートを示す。次いで、プロキシサーバ108は、図11を参照して説明した方法と同じ方法で、要求メッセージを正しいアプリケーションサーバ900に転送し得る。
アプリケーションサーバ900は、要求メッセージを処理し、応答メッセージを提供し得る。応答メッセージは、使用されるIPアドレスおよびポートに基づいてプロキシサーバ108へ戻るようにルーティングされ、図11を参照して説明したように、さらにP-GW102にルーティングされ得、それに加えて、RDSポートは、上記の内容によりUDPポートに反映される。次いで、P-GW102は、応答メッセージのIPアドレスおよびポートに基づいて、応答メッセージの転送先となるNB-IoTデバイスを決定し得る。P-GW102は、UDP/IPヘッダを削除し、応答メッセージを転送し得る。使用されるRDSポートは、送信先UDPポート番号から決定される。NB-IoTデバイスにおいて、応答メッセージは、RDSポートに基づいて、デバイスで実行されている正しいアプリケーションに転送され得る。
いくつかの例において、プロキシサーバ108は、アプリケーションサーバがNB-IoTデバイスに要求メッセージを送信するために使用する静的IPv6アドレスをNB-IoTデバイスに割り当てていてもよい。代替として、プロキシサーバ108は、特定のNB-IoTデバイスをアドレス指定するときに使用するアプリケーションサーバ用のリソースを提示し得る。プロキシサーバは、図12を参照して説明したように、使用するべきRDSポートを決定する。次いで、プロキシサーバ108は、要求メッセージをP-GWに転送することができ、RDSポート番号に基づいて接続された非IPトラフィック用の専用ポートが使用される。P-GWは、UDP/IPヘッダを削除し、NIDDサービスを使用して要求メッセージをNB-IoTデバイスに転送し得る。プロキシサーバ108は、デバイスのIPアドレスおよびポート、RDSポート、ならびに場合によってはアプリケーションサーバのIPアドレスおよびポートのマッピングを格納し得る。
NB-IoTデバイスは、NIDDを使用してP-GWに送信され得る応答メッセージを提供し得る。P-GW102は、UDP/IPヘッダを追加し、応答メッセージをプロキシサーバ108に転送し得る。プロキシサーバ108は、応答を処理し得る。プロキシサーバ108は、送信元IPアドレスおよびポートに基づいて、データベースから、応答メッセージの転送先となるアプリケーションサーバのIPアドレスおよびポートを決定し得る。
圧縮されたIPトラフィックによるNIDDサービスを使用したプロキシサーバのハンドリング(デバイスタイプ1&2)
TCP/IPまたはUDP/IPヘッダの影響をなくすために、NIDDサービスを利用することは可能であるが、非IPデータをペイロードデータとして送信する代わりに、圧縮されたIPデータをペイロードとして送信することができる。圧縮されたIPデータをペイロードとして送信することにより、NB-IoTデバイス、およびプロキシサーバまたはSCEF/P-GWのいずれかは、UDP/IPまたはTCP/IP圧縮をハンドリングする必要があり得る。使用できる様々な方式、例えば、ロバストヘッダ圧縮(ROHC:Robust Header Compression)、低電力無線パーソナルエリアネットワークを介したIPv6(6LoWPAN:IPv6 over Low-Power Wireless Personal Area Networks)のための汎用ヘッダ圧縮(GHC:Generic Header Compression)、および低電力無線エリアネットワーク(LPWAN:Low-Power Wireless Area Network)静的コンテキストヘッダ圧縮(SCHC:Static Context Header Compression)が存在する。現在は、SCEFもP-GWもヘッダ圧縮方式をサポートしていない。UDP/IPまたはTCP/IPヘッダを削除することと比較してこれらの方式がどれだけ効率的かは、デバイスが送信しているデータの量に依存する可能性がある。
圧縮されたIPベースのトラフィックを使用するとき、CoAPオプションおよびRDSポートを使用せずに、複数のアプリケーションサーバのアドレス指定を解決することができる。NB-IoTデバイスとSCEF/P-GWとの間の高信頼転送には、RDSが引き続き必要になり得る。ヘッダ圧縮が公開機能104でサポートされている場合、プロキシサーバ108は、アプリケーションサーバと公開機能104との間でパケットのみを中継し得る。プロキシサーバ108はそれでも、発信パケットの送信元IPアドレスを、応答が戻る途中でプロキシサーバ108を介してルーティングされるようにセットすることができる。公開機能104がヘッダ圧縮をサポートしない場合、プロキシサーバ108は、上記に加えて、この部分も実装することができる。アプリケーションサーバからの着信パケットの場合、ソリューションは、静的IPアドレスまたはデバイスごとのリソースを使用して前述したものと同じであり得る。次いで、プロキシサーバ108は、パケットを公開機能104に送信する前にパケットを圧縮し得る。
P-GW102がヘッダ圧縮をサポートする場合、NB-IoTデバイスからアプリケーションサーバに送信されるデータをプロキシサーバ108なしで管理することが可能である。トリガメッセージのために、また場合によってはアプリケーションサーバからNB-IoTデバイスへのデータのために、プロキシサーバ108が依然として必要とされ得る。プロキシサーバ108がヘッダ圧縮を実施する場合、ソリューションは、公開機能の例の場合と同じであるが、上記のように、P-GWを介したNIDDに起因する違いがある。
CoAPとRDSの両方を使用することができ、信頼性および複数のアプリケーションサーバとの通信を解決するために様々なハイブリッドソリューションが想定されることが理解されよう。
NIDDを使用したセキュア通信
NB-IoTデバイスとアプリケーションサーバとの間のエンドツーエンドのセキュア通信は、RDSとCoAPのどちらを利用するのかに応じて様々な方法で実現され得る。RDSを使用する場合、NB-IoTデバイスとアプリケーションサーバとの間のセキュア通信のために、(プロキシサーバとアプリケーションサーバとの間でTCPとUDPのどちらのトランスポートプロトコルが使用されるかに応じて)TLSまたはDTLSを使用することが可能である。ここで、TLS/DTLSメッセージはRDS上で直接転送され得ることに留意されたい。CoAPを使用する(RDSを使用しない)とき、CoAPヘッダは、プロキシサーバ動作用に平文である可能性がある。その場合、トランスポート層でTLS/DTLSを使用できないことは明らかであり、通信をエンドツーエンドで確保するためにOSCOREを使用することが推奨され得る。次に、EDHOCを使用して、共有セキュリティコンテキストを確立するために必要な2者間で共有されるOSCOREマスターシークレットを確立することができる。メッセージを確保するために、例えばCOSEを利用するアプリケーション固有のソリューションを使用した、追加の代替手段も可能であり得る。
GSMA RSP M2M版:デバイスとの間でプロファイルダウンロードおよびプロファイル管理データを送受信する
このセクションでは、プロファイル管理サーバとの通信に関連する問題について対応する。
識別情報モジュールとプロファイル管理サーバとの間でHTTPS(またはCAT_TP)セッションが確立される通信と、NB-IoTデバイスからプロファイル管理サーバへのSMS形式のメッセージの配信との2つの異なるケースについて考える。前者はタイプ1およびタイプ2のデバイスに適用され、後者はすべてのタイプのデバイスに適用される。
HTTPS(またはCAT_TP)セッションを使用した通信
GSMA RSP M2M版は、識別情報モジュールとSM-SR(プロファイル管理サーバの一部)との間にHTTPSセッション(またはCAT_TPセッション)を確立し、これら2つのエンドポイント間でHTTPSデータ(またはCAT_TPデータ)を送信することを含む。識別情報モジュールとNB-IoTデバイスとの間の通信のために、NB-IoTデバイスにおいて、ベアラ非依存プロトコル(BIP:Bearer Independent Protocol)を使用することができる。識別情報モジュールは、BIPプロトコルを用いて、SM-SRへの通信チャネルを開閉し、データを送受信することができる。図6のステップ605でトリガメッセージが受信される前に、SM-SRがNB-IoTデバイス/識別情報モジュールに認識されない場合がある。IPベースのトラフィックを介してSM-SRと直接通信するには、TCP/IPがNB-IoTデバイスでサポートされている必要があり得る。CoAP/UDP/IPスタックをサポートする制約付きNB-IoTデバイスは、TCPをサポートしない場合があり、プロファイル管理サーバと通信するときにNIDDを介した通信を使用するように設定され得る。
RDSを使用するとき、図6のステップ606でセキュア通信を確立できるように、デバイスおよびプロキシサーバにおいて、SM-SRとの通信に使用するRDSポート番号が設定されなければならない。RDSポート番号を設定することは、D/C管理サーバ109の役割である。RDSポート番号は、例えば、図6のステップ603でD/C管理サーバ109から送信されるときに、トリガメッセージの一部として含まれ得る。ステップ603の一部として、D/C管理サーバ109はまた、プロキシサーバ108へのRDSポート番号を設定し得る。RDSポート番号に関連して、プロキシサーバ108においてUPD/IP通信とTCP/IP通信のどちらを使用すべきかに関する情報も提供され得る。
CoAPがNB-IoTデバイスからすべてのアプリケーションサーバへのすべての通信のベアラとして使用され、RDSが使用されないとき、SM-SRを使用したHTTPS(またはCAT_TP)ベースのトラフィックなどのアプリケーションサーバとの非CoAPベースの通信には、特別なソリューションが必要になる場合がある。非CoAPベースのメッセージは、プロキシサーバ108とNB-IoTデバイスとの間でCoAPペイロードとして運ばれ得る。プロキシサーバ108は、メッセージをNB-IoTデバイスからSM-SRに転送する前にCoAPヘッダを削除する必要があり得、メッセージをSM-SRからNB-IoTデバイスに転送する前にCoAPヘッダを追加し得る。この特定のプロキシサーバの挙動を適用させるために、プロキシサーバ108において、NB-IoTデバイスが書き込むことができる特別なリソースを使用することができる。例えば、Uri-Hostオプションを「プロキシ」にセットし、Uri-Portオプションを使用せず、Uri-Pathオプションを、このリソース名の後に転送メカニズム(UDPまたはTCP)、ホスト名、ポート、および応答を書き込むことができるNB-IoTデバイスでのリソース名が続くことを示すようにセットすることができる。次いで、プロキシサーバは、NB-IoTデバイスからトラフィックを転送するときに「通常の」CoAPトラフィックとは異なるUDP/TCPポート番号を使用することができ、その結果、プロキシサーバは、アプリケーションサーバからのどのトラフィックに対してCoAPヘッダを追加するべきかを認識できるようになる。プロキシサーバは、アプリケーションサーバからの応答を、アプリケーションサーバから受信したCoAP要求にリンクできるように、CoAPメッセージIDおよびCoAPトークン値を保存する必要があり得る。プロキシサーバがアプリケーションサーバからNB-IoTデバイスにデータを書き込むときに使用するプロファイルダウンロードおよびプロファイル管理データのために、NB-IoTデバイスでの特別なリソースが使用され得る。このリソースに書き込む場合、データは、識別情報モジュールを駆動するアプリケーションに送信され、アプリケーションは、BIPプロトコルを使用してデータを識別情報モジュールに転送する。
上記と同じように、HTTPSメッセージを転送するために複数のCoAPメッセージがNB-IoTデバイスからプロキシサーバの特別なリソースに送信されている場合、最初のCoAP要求メッセージ内にのみUri-HostおよびUri-Pathオプションを含めることができ、プロキシサーバは、これらのオプションなしで次のCoAP要求メッセージを同じように処理することができる。
SMS形式のメッセージの配信
NB-IoTデバイスからプロファイル管理サーバへのSMS形式のメッセージの配信には、「HTTPS(またはCAT_TP)セッションを使用した通信」というタイトルのセクションで使用されているものとは異なる専用URLを使用することができる。このURLは、D/C管理サーバ109によってプロキシサーバ108に設定され得る。RDSを使用するとき、「HTTPS(またはCAT_TP)セッションを使用した通信」で説明したものと同じタイプのソリューションが適用されるが、専用RDSポートが使用される。NB-IoTデバイスからのメッセージでこのRDSポートを使用すると、プロキシサーバ108は、このメッセージ(SMS形式のデータ)を、このポートに登録された専用URLに書き込むことになる。これは、HTTPベースのインターフェースまたは低レベルソケットインターフェースであり得る。プロキシサーバ108は、プロファイル管理サーバ107で事前登録され、プロファイル管理サーバ107は、プロキシサーバ108がメッセージを書き込むことを可能にする。SMS形式のデータは、GSMA RSP M2M版で規定されている標準メカニズムに従って保護され得る。SMS形式のデータは、メッセージの送信者を決定するための、プロファイル管理サーバ107に対する送信者識別子(例えば、EID)を含み得る。
メッセージの配信のためにCoAPが使用される例では、「HTTPS(またはCAT_TP)セッションを使用した通信」で説明したものと同じであるが、SMS形式のメッセージをハンドリングするために「HTTPS(またはCAT_TP)セッションを使用した通信」とは異なる専用のリソースを用いる。このリソースへの書き込みは、上記のRDSの場合と同じ方法でプロファイル管理サーバにメッセージを送信するようにプロキシサーバをトリガする。
GSMA RSP消費者版:デバイスとの間でプロファイルダウンロードおよびプロファイル管理データを送受信する
このセクションでは、デバイスのLPAdとプロファイル管理サーバとの間のHTTPSベースの通信について検討する。これは、タイプ1およびタイプ2のデバイスに適用される。上で説明したように、CoAP/UDP/IPスタックをサポートする制約付きNB-IoTデバイスは、TCPをサポートしない可能性があり、プロファイル管理サーバ107と通信するときにNIDDを介した通信を使用するように設定され得る。ここでは、プロキシサーバとデバイスとの間でHTTPSメッセージを転送するためにRDSまたはCoAPのいずれかが使用される場合、およびプロキシサーバがさらにプロファイル管理サーバへメッセージを転送することをハンドリングする場合の2つの場合に、「HTTPS(またはCAT_TP)セッションを使用した通信」で説明したものと同じソリューションが適用される。
IoTに適合したGSMA RSP消費者版の場合、HTTPSは、デバイスの外に移動され、プロキシサーバ108による特別なハンドリングを必要としない場合がある。
D/C管理サーバ109とNB-IoTデバイスとの間のセキュア通信には、「デバイスとの間でデータを送受信する(デバイスタイプ1&2)」に記載の技法が適用される。図7のステップ703から704および712から713、ならびに図8のステップ803から804および810から811においてD/C管理サーバ109からNB-IoTデバイス101に送信されるトリガメッセージは、保護される必要がない場合がある。
新しいMNOのサービスを使用するようにプロキシサーバを更新する
図5、図6、図7、および図8に示すように、新しいモバイルネットワークオペレータの新しいプロファイルを有効化するとき、プロキシサーバが使用するNIDDおよび監視サービスを、現在のモバイルネットワークから新しいモバイルネットワークオペレータに切り替える必要がある。上に示したように、プロキシサーバ108は、新しいネットワークへの切り替えが決定されるとすぐに、すなわち、新しいネットワークのプロファイルが無効化されようとしているときに新しいモバイルネットワークのサービスに登録するように、D/C管理サーバ109によって命令され得る。プロキシサーバ108は、一度に2つ以上のモバイルネットワークからNIDDサービスに登録され得る。NB-IoTデバイスからアプリケーションサーバへのデータの場合、プロキシサーバ108は、データがどのネットワークから来たのかという情報を格納することができ、データを同じネットワークに戻すようにルーティングすることができる。しかしながら、アプリケーションサーバからNB-IoTデバイスへのデータの場合、プロキシサーバ108は、NB-IoTデバイスが現在どのネットワークにあるかを認識する必要があり得る。いくつかの例において、プロキシサーバ108は、新しいネットワークからデータを受信するまで現在のネットワークに留まり、その後、すべてのトラフィックを新しいネットワークに切り替える。D/C管理サーバ109が(例えば、プロファイル管理サーバ107から)プロファイルの有効化が成功したとの確認応答を受信すると、これは、前のネットワークのサービスから登録解除することができるプロキシサーバ108に通知され得る。
異なるモバイルネットワークを備えた同じNB-IoTデバイスに対して、異なる外部識別子(例えば、MSISDN)が使用される場合がある。この例では、プロキシサーバ108に新しいモバイルネットワークのサービスに登録するように命令するときに、新しい外部識別子は、D/C管理サーバ109によってプロキシサーバにあるように設定され得る。次いで、プロキシサーバ108は、プロファイル間の切り替えが完了するまで2つの外部識別子間を変換することができ、完了した場合、古い外部識別子は無視され得る。
デバイス/コネクティビティ(D/C)管理サーバと統合されたプロキシサーバ
いくつかの例において、プロキシサーバ108とD/C管理サーバ109は、同一のサーバである。したがって、D/C管理サーバ109は、NB-IoTデバイス、およびそれらが通信するアプリケーションサーバ、ならびにこれらのアプリケーションサーバとの通信においてプロキシサーバ108がNB-IoTデバイスを支援していることについての知識を有し得る。
図13は、処理回路(または論理)1301を含むプロキシサーバ1300を示す。処理回路1301は、プロキシサーバ1300の動作を制御し、プロキシサーバ1300(例えば、プロキシサーバ108)に関連して本明細書に記載されている方法を実施することができる。処理回路1301は、本明細書に記載の方式でプロキシサーバ1300を制御するように設定またはプログラムされた1つまたは複数のプロセッサ、処理ユニット、マルチコアプロセッサまたはモジュールを備えることができる。特定の実装形態において、処理回路1301は、プロキシサーバ1300に関連して本明細書に記載されている方法の個々のまたは複数のステップを実行するように各々設定された、または実行するための複数のソフトウェアおよび/またはハードウェアモジュールを備えることができる。
簡単に言えば、プロキシサーバ1300の処理回路1301は、トリガメッセージをNB-IoTデバイスに配信するよう求める要求を受信することであって、要求がデバイス識別子を含む、要求を受信することと、受信したデバイス識別子に基づいて外部識別子を決定することと、外部識別子を使用してトリガメッセージをNB-IoTデバイスに配信することとを行うように設定される。
いくつかの実施形態において、プロキシサーバ1300は、任意選択として、通信インターフェース1302を備え得る。プロキシサーバ1300の通信インターフェース1302は、他の仮想ノードなどの他のノードとの通信に使用することができる。例えば、プロキシサーバ1300の通信インターフェース1302は、要求、リソース、情報、データ、信号、もしくは同様のものを他のノードに送信するように、かつ/または他のノードから受信するように設定され得る。プロキシサーバ1300の処理回路1301は、要求、リソース、情報、データ、信号、もしくは同様のものを他のノードに送信するように、かつ/または他のノードから受信するように、プロキシサーバ1300の通信インターフェース1302を制御するように設定され得る。
任意選択として、プロキシサーバ1300は、メモリ1303を備え得る。いくつかの実施形態において、プロキシサーバ1300のメモリ1303は、プロキシサーバ1300に関連して本明細書に記載されている方法を実行するためにプロキシサーバ1300の処理回路1301によって実行され得るプログラムコードを記憶するように設定され得る。代替として、または追加として、プロキシサーバ1300のメモリ1303は、本明細書で記載の任意の要求、リソース、情報、データ、信号、または同様のものを記憶するように設定され得る。プロキシサーバ1300の処理回路1301は、本明細書に記載の任意の要求、リソース、情報、データ、信号、または同様のものを記憶するように、プロキシサーバ1300のメモリ1303を制御するように設定され得る。
図14は、処理回路(または論理)1401を備えるデバイスコネクティビティ(D/C)管理サーバ1400を示す。処理回路1401は、D/C管理サーバ1400の動作を制御し、D/C管理サーバ1400(例えば、D/C管理サーバ108)に関連して本明細書に記載されている方法を実施することができる。処理回路1401は、本明細書に記載の方式でD/C管理サーバ1400を制御するように設定またはプログラムされた1つまたは複数のプロセッサ、処理ユニット、マルチコアプロセッサまたはモジュールを備えることができる。特定の実装形態において、処理回路1401は、D/C管理サーバ1400に関連して本明細書に記載されている方法の個々のまたは複数のステップを実行するように各々設定された、または実行するための複数のソフトウェアおよび/またはハードウェアモジュールを備えることができる。
簡単に言えば、D/C管理サーバ1400の処理回路1401は、トリガメッセージをNB-IoTデバイスに配信するよう求める要求をプロキシサーバに送信するように設定され、要求は、デバイス識別子およびトリガメッセージを含む。
いくつかの実施形態において、D/C管理サーバ1400は、任意選択として、通信インターフェース1402を備え得る。D/C管理サーバ1400の通信インターフェース1402は、他の仮想ノードなどの他のノードとの通信に使用することができる。例えば、D/C管理サーバ1400の通信インターフェース1402は、要求、リソース、情報、データ、信号、もしくは同様のものを他のノードに送信するように、かつ/または他のノードから受信するように設定され得る。D/C管理サーバ1400の処理回路1401は、要求、リソース、情報、データ、信号、もしくは同様のものを他のノードに送信するように、かつ/または他のノードから受信するように、D/C管理サーバ1400の通信インターフェース1402を制御するように設定され得る。
任意選択として、D/C管理サーバ1400は、メモリ1403を備え得る。いくつかの実施形態において、D/C管理サーバ1400のメモリ1403は、D/C管理サーバ1400に関連して本明細書に記載されている方法を実行するためにD/C管理サーバ1400の処理回路1401によって実行され得るプログラムコードを記憶するように設定され得る。代替として、または追加として、D/C管理サーバ1400のメモリ1403は、本明細書に記載の任意の要求、リソース、情報、データ、信号、または同様のものを記憶するように設定され得る。D/C管理サーバ1400の処理回路1401は、本明細書に記載の任意の要求、リソース、情報、データ、信号、または同様のものを記憶するように、D/C管理サーバ1400のメモリ1403を制御するように設定され得る。
図15は、処理回路(または論理)1501を含む狭帯域モノのインターネット(NB-IoT)デバイス1500を示す。処理回路1501は、NB-IoTデバイス1500の動作を制御し、NB-IoTデバイス1500(例えば、NB-IoTデバイス108)に関連して本明細書に記載されている方法を実施することができる。処理回路1501は、本明細書に記載の方式でNB-IoTデバイス1500を制御するように設定またはプログラムされた1つまたは複数のプロセッサ、処理ユニット、マルチコアプロセッサまたはモジュールを備えることができる。特定の実装形態において、処理回路1501は、NB-IoTデバイス1500に関連して本明細書に記載されている方法の個々のまたは複数のステップを実行するように各々設定された、または実行するための複数のソフトウェアおよび/またはハードウェアモジュールを備えることができる。
簡単に言えば、NB-IoTデバイス1500の処理回路1501は、プロキシサーバによって配信されたトリガメッセージを受信するように設定される。
いくつかの実施形態において、NB-IoTデバイス1500は、任意選択として、通信インターフェース1502を備え得る。NB-IoTデバイス1500の通信インターフェース1502は、他の仮想ノードなどの他のノードとの通信に使用することができる。例えば、NB-IoTデバイス1500の通信インターフェース1502は、要求、リソース、情報、データ、信号、もしくは同様のものを他のノードに送信するように、かつ/または他のノードから受信するように設定され得る。NB-IoTデバイス1500の処理回路1501は、要求、リソース、情報、データ、信号、もしくは同様のものを他のノードに送信するように、かつ/または他のノードから受信するように、NB-IoTデバイス1500の通信インターフェース1502を制御するように設定され得る。
任意選択として、NB-IoTデバイス1500は、メモリ1503を備え得る。いくつかの実施形態において、NB-IoTデバイス1500のメモリ1503は、NB-IoTデバイス1500に関連して本明細書に記載されている方法を実行するためにNB-IoTデバイス1500の処理回路1501によって実行され得るプログラムコードを記憶するように設定され得る。代替として、または追加として、NB-IoTデバイス1500のメモリ1503は、本明細書に記載の任意の要求、リソース、情報、データ、信号、または同様のものを記憶するように設定され得る。NB-IoTデバイス1500の処理回路1501は、本明細書に記載の任意の要求、リソース、情報、データ、信号、または同様のものを記憶するように、NB-IoTデバイス1500のメモリ1503を制御するように設定され得る。
上記の実施形態が本発明を限定ではなく例示すること、および当業者であれば、添付の特許請求の範囲から逸脱することなく多くの代替の実施形態を設計できることに留意されたい。「含む(comprising)」という語は、特許請求の範囲に記載されたもの以外の要素またはステップの存在を排除するものではなく、「1つの(aまたはan)」は複数を排除するものではなく、単一のプロセッサまたは他のユニットは、特許請求の範囲に記載のいくつかのユニットの機能を果たし得る。特許請求の範囲におけるいずれの参照記号もその範囲を制限するとは解釈しないものとする。