(58)【調査した分野】(Int.Cl.,DB名)
【背景技術】
【0001】
oneM2Mサービス層は、共通機能(またはサービス能力)の組として編成され、そのインスタンス化は、共通サービスエンティティ(CSE)と称される。
図1は、
図1に示されるようなMca、Mcc、およびMcn参照点を介してエクスポージャされる、oneM2Mサービス層の共通機能を図示する略図である。
【0002】
Mca参照点は、アプリケーションエンティティ(AE)102とCSE104との間の通信フローを指定する一方、Mcc参照点は、同一M2Mサービスプロバイダドメイン内のCSE104と106との間の通信フローを指定する。McaおよびMccを横断する通信は、ペアにされた要求/応答メッセージを介して生じ、各要求は、標的CSE上にホストされたリソースに特定のRESTful動作(例えば、作成、読み出し、更新、削除)を行う。
【0003】
Mcc’は、異なるM2M SPのインフラストラクチャドメイン内に位置するCSE間で使用される。Mcnは、トランスポートおよび接続以外のサービスのために、CSE104と下層ネットワークサービスエンティティ(NSE)108との間で使用される。
【0004】
oneM2Mサービス層では、CSEは、「ノード」と称されるアーキテクチャエンティティ上にホストされる。ノードは、a)1つのCSEおよびゼロ以上のAE、または、b)1つ以上のAEを含む、機能エンティティである。
【0005】
図2は、種々のタイプのノード構成をサポートするoneM2Mアーキテクチャの略図である。
図2は、簡略化された表現であり、エンティティ間の全ての可能である構成または関係を反映するわけではない。
【0006】
図3は、oneM2M CSE 302によって行われる共通サービス機能(CSF)の初期の組を図示する略図である。特定のCSE実装は、全ての機能をサポートしない場合があるが、完全実装は、例証における全機能を含むことができる。
【0007】
ユニフォームリソース識別子共通構文は、5つのコンポーネント(スキーム、オーソリティ、パス、クエリ、およびフラグメント)の階層シーケンスから成る、インターネット構造である。
図4は、oneM2Mアドレスにおいて有意である、ユニフォームリソース識別子共通構文のスキーム、オーソリティ、およびパスコンポーネントを図示する略図である。
【0008】
oneM2Mサービス層内の全てのエンティティは、ROAアーキテクチャにおいてリソースとして表される。サービス層ノード上のAEまたはCSEの各インスタンス化は、固有の識別子を有することが要求される。この固有の識別子は、絶対ユニフォームリソース識別子(URI)を導出するために使用され、絶対URIは、そのホストCSE上のそのエンティティのためのリソース構造のルート(またはベース)アドレスを表す。その構造内の全てのリソースも、階層または非階層方式のいずれかにおいて標的リソースを個別的に識別するパスコンポーネントを有する完全修飾ドメイン名(FQDN)URIを介して、固有にアドレス可能でなければならない。FQDNは、リソースをホストするCSEを含むノードのネットワークアドレスを提供し、パスは、そのノード上の標的リソースの精密な場所を提供する。
【0009】
以下の2つの例示的URI値は、同一のリソースをアドレスし、最初に、階層パス構造を用いて、次いで、非階層構造を用いて、前述の原理を図示する。
1) //CSE04.M2MSPabc.com/CSEBase01/alpha/container02/instance01
2) //CSE04.M2MSPabc.com/CSEBase01/resource12345678
URI#2の下線部分は、この例示的CSEのためのベースリソース構造のアドレスを表し、さらに、対応するCSE識別子を具現化する。URI#1の下線部分は、「alpha」と命名されたアプリケーションのためのリソース構造のアドレスを表し、さらに、対応するAE識別子を具現化する。
【0010】
CSEまたはAEに関連付けられたリソース構造は、PoA(pointOfAccess)として知られる属性を含み、PoAは、CSEまたはAEをホストするノードとの通信を確立するために使用されるルーティング情報(概して、1つ以上のIPアドレス)を保持する。AEを標的化するために(例えば、通知を用いて)、最初に、AEが登録されているCSEに到達し、次いで、AE−PoA属性における情報を使用して、要求を標的AEにアドレスすることが必要である。
【0011】
サービス層要求/応答メッセージは、APIを含み、APIは、サービス層エンティティ間のメッセージ移動を促進するために、アプリケーションプロトコルを経由して搬送される。サービス層は、それがサービス提供するアプリケーションと下位ネットワーク層との間に位置するため、多くの場合、
図5に図示されるように、「ミドルウェア」と称される。
【0012】
アプリケーションプロトコル層においてバインディングするために、多数の選択肢が存在するが、ETSI M2MおよびoneM2Mは両方とも、最初に、HTTPおよびCoAPに合意している。oneM2Mは、メッセージ待ち行列テレメトリトランスポート(MQTT)プロトコルバインディングも同様にサポートすることを約束しており、それは、サービス層のRESTful要求/応答(1対1)メッセージペアとイベント駆動型パブリッシュ/サブスクライブ(1対多)MQTTプロトコルとの間の対比によって興味深いものとなっている選択肢である。これらの差異にもかかわらず、MQTTは、その非常に低いプロトコルオーバーヘッドおよび単純な効率的設計に起因して、M2Mアプリケーションのための魅力的な選択肢のままである。
【0013】
MQTTプロトコルは、最初に、IBMおよびEurotechによって、1990年代後半に開発された。それは、正式な採択(プロセスは継続中)およびさらなる開発のために、2013年にOASIS標準化団体に提出された。MQTTは、制約のあるデバイスおよび低帯域幅ネットワークのために調整された低オーバーヘッドメッセージ待ち行列およびトランスポートプロトコルであり、それは、最も有名なものとして、Facebook Messengerモバイルアプリにおいて展開されている。
【0014】
図6は、MQTTのパブリッシュ/サブスクライブ(またはクライアント/サーバ)モデルを図示する略図である。MQTTのコア要素は、クライアント(パブリッシャ602および加入者604の両方であり得る)、サーバ(ブローカとも称される)、セッション、サブスクリプション、およびトピックである。
【0015】
図7は、MQTTの要素を図示する略図である。HTTPのように、MQTTプロトコルは、2つの異なる役割(すなわち、クライアント702およびサーバ704)を区別するという点において非対称である。
【0016】
MQTT用語では、クライアント702は、MQTTを使用するプログラムまたはデバイスである。それは、常時、サーバへのネットワーク接続を確立する。クライアント702は、以下を行うことができる:
・他のクライアントが関心を持ち得るアプリケーションメッセージをパブリッシュすること
・それが受信することに関心があるアプリケーションメッセージを要求するためにサブスクライブすること
・アプリケーションメッセージのための要求を除去するためにサブスクリプションを解除すること
・サーバを切断すること
MQTTサーバ704は、接続をクライアントから受け取る、エンティティである。HTTPと異なり、概して、任意のアプリケーション論理を起動せず、代わりに、MQTTサーバ704は、アプリケーションメッセージをパブリッシュするクライアントと、それらをサブスクライブし、受信する、クライアントとの間の中間体としてアクションする。
【0017】
トピックは、MQTT内の「Q」であり、それは、メッセージ待ち行列と命名され、パブリッシャを加入者とリンクするために、サーバによって維持される。MQTTクライアント702は、PUBLISHメッセージ(すなわち、供給されたトピック名にサブスクライブされた任意のクライアントに不透明メッセージペイロードを配信するための命令)をMQTTサーバ704に発行する場合、パブリッシャの役割を担い、SUBSCRIBEメッセージ(すなわち、供給されたトピックフィルタに一致する任意のPUBLISHメッセージを受信するための命令)をMQTTサーバ704に発行する場合、加入者の役割を担う。トピックフィルタは、1つ以上のトピックへの関心を示すためにサブスクリプション内に含まれる表現である。トピックフィルタは、ワイルドカード文字を含み得る。PUBLISHメッセージは、3つのQoS保証レベル(最高1回、少なくとも1回、正確に1回)のうちの1つを用いて配信される。
【0018】
図8は、MQTTにおけるクライアントとサーバとの間のアタッチメントの2つのレベルを表す、セッションおよびサブスクリプションを図示する略図である。セッション801および802は、クライアントとサーバとの間のステートフル相互作用(すなわち、アクティブTCP/IPネットワーク接続)であり、固有のクライアント識別子によって識別される。セッション801および802は、クライアントがCONNECTメッセージをサーバに送信することによってのみ確立されることができる。CONNECT、PUBLISH、およびSUBSCRIBEメッセージ内のフラグは、セッションが切断される場合、セッション状態が維持される方法を決定する。
【0019】
サブスクリプション804および806は、サーバによって維持される1つ以上のトピック(すなわち、メッセージ待ち行列)へのクライアントの論理的なアタッチメントである。サブスクリプション806は、単一セッション801のみに関連付けられているが、セッションの切断の場合、保存され、後続セッションが同一クライアントによって確立されると、記憶されたサブスクライブされたメッセージの配信をトリガするようにセッション状態を構成することも可能である。したがって、サブスクリプションは、「一時的」(サブスクリプション806)または「持続的」(サブスクリプション804)であり得る。
【0020】
最高QoSレベルで動作する持続的サブスクリプション804は、サーバが関連付けられたクライアントのためにストアアンドフォワードモードで動作する結果をもたらす(サーバ上の利用可能な記憶容量の限界内で)一方、最低QoSレベルとペアにされる一時的サブスクリプション806は、サーバが関連付けられたクライアントのためにパススルーモードで動作する結果をもたらす。
【0021】
MQTTネットワーク接続は、クライアント702とサーバ704との間のみに存在する。MQTTクライアント702の観点から、全ての着信アプリケーションメッセージは、サーバ704から発信され、サーバ704とのサブスクリプションから生じるアプリケーションメッセージを受信するMQTTクライアント702は、ネットワーク層(例えば、IP)においてそのメッセージを発信したクライアントに到達することさえできないこともあり得る。この点から、サーバ704が、アプリケーションメッセージを転送するべきかどうかを決定する(トピック名をサブスクリプションのそのリストに対して照合する(すなわち、トピックフィルタ))機構は、トピック名フィールドをネットワークアドレスの形態のように取り扱う。
【0022】
但し、サーバ704は、サブスクリプションを直接ネットワーク接続(例えば、IPアドレス)に関連付けないので、考えるべき中間ステップがある。サブスクリプションが、セッションに関連付けられ、セッションが、サーバに接続する全てのクライアントに対して固有でなければならないクライアント識別子(クライアントID)に関連付けられる。クライアントIDは、最大65,535バイトのUTF−8エンコードストリングである。しかしながら、サーバは、長さを23UTF−8エンコードバイト以下に制限し得る。クライアントID機構はセッション状態の保存を可能にし、ストアアンドフォワード能力を有効にする(所望に応じて)。
【0023】
したがって、MQTTアドレス関連付けの組は、以下のようになる。
【0024】
【表1】
【0025】
「/」は、トピック名を階層レベルに分割するために使用されるトピックレベルセパレータである。「#」は、続く任意のレベルにおいて一致するマルチレベルワイルドカード文字である。さらに、1つのみのレベルにおいて一致する単一レベルワイルドカード文字「+」も存在する(図示せず)。
【0026】
この例では、Acme Alarm Co.が、MQTTサーバに接続し、「Acme−Alarm−xyz」のそのクライアントID値を使用して、セッションを確立している。その所在地住所(1234 Elm St.,Anytown)に一致する任意のものに対応するトピック名を伴うアプリケーションメッセージをサブスクライブしている。Acme Alarmは、センサおよびネットワークコントローラをこの場所にインストールし、コントローラは、トピック名「/Anytown/ElmSt./1234/<sensorX>/<info>」を用いてアプリケーションメッセージをパブリッシュしている。サーバは、着信アプリケーションメッセージをAcmeに属するこのサブスクリプションと比較し、トピック一致を伴う任意のメッセージを対応するネットワーク接続アドレスに転送する。
【0027】
MQTT V3.1.1仕様書は、以下の宣言を含む。
「単一エンティティが、MQTTクライアントおよびMQTTサーバ実装の両方として適合し得る。例えば、インバウンド接続を受け入れ、他のサーバへのアウトバンド接続を確立するサーバは、MQTTクライアントおよびMQTTサーバの両方として適合しなければならない」。
【0028】
MQTT仕様書(上記)からの適合性宣言は、確保されたプロトコルフィールドを利用する実装に対処する(概して、サーバ−サーバ接続をクライアント−サーバ接続から区別するために必要とされる)。しかしながら、以下のように、サーバ−サーバ接続を区別することを必要とせず、かつ仕様書に違反することなく、MQTTサーバを相互接続することが可能である。
【0029】
サーバのうちの1つのみがこのように構成される場合、それらの間には、内蔵されたクライアント機能性を有するサーバに向かう一方向のトラフィックフローのみが存在し得る。これは、
図9に示されるように、それが他のサーバにサブスクライブし、トラフィックをそれ自身に向けて操縦することを可能にする。
【0030】
図9は、MQTTサーバ間のメッセージの一方向フローを図示する略図である。
図9では、「S1/C1」として識別されたMQTTクライアント902は、SUBSCRIBEメッセージをサーバS1に事前に送信しており、サーバS1に、トピックフィルタ「S1/C1/#」を有するトピック待ち行列を確立させている。続いて、最初の5文字が「S1/C1」に等しいトピック名フィールドを伴う、サーバS1に到着した任意のパブリッシュメッセージは、クライアントS1/C1 902に転送されるであろう。
【0031】
独立型クライアントに示される「パブリッシュ」および「サブスクライブ」機能は、フローに示されるメッセージをハンドリングするときにクライアントが有する役割(パブリッシャまたは加入者)を示す。
【0032】
サーバS1における内蔵されたクライアント機能904によってサーバS2に送信されるSUBSCRIBEメッセージは、サーバS2に、トピックフィルタ「S1/#」を有するトピック待ち行列を確立させる。これは、2つのサーバ間に(一方向)接続を形成するアクションである。続いて、最初の2文字「S1」に等しいトピック名フィールドを伴う、サーバS2に到着する任意のPUBLISHメッセージは、サーバS1に転送されるであろう。このように、サーバS1に接続されるクライアントは、サーバS1またはサーバS2のいずれか(またはサーバS1が接続を確立する任意の他のサーバ)に接続されるクライアントによって到達されることができる。
【0033】
接続は、サーバS1内のクライアント902がDISCONNECTメッセージをサーバS2に送信することによって、随時、分断されることができる。対応するCONNECTメッセージ(SUBSCRIBEに先立って)は、示されないが、仮定されている。サーバS2は、サーバS1内のクライアント902からの接続が別のサーバに関連付けられる、インジケーションを有していないことに留意されたい。サーバS1は、サーバS2に対して任意の他のクライアントのように見える(プロトコルレベルにおいて)。
【0034】
図10は、MQTTサーバといずれかのサーバに接続されるクライアントとの間の双方向トラフィックフローを図示する略図である。この場合、両クライアントS1/C1およびS2/C1は、SUBSCRIBEメッセージをそれらのそれぞれのサーバに事前に送信し、それらのサーバに、示されるトピックフィルタを有するトピック待ち行列を確立させている。各サーバ内に内蔵されたクライアント機能によって送信されるSUBSCRIBEメッセージは、受信サーバに、発信側サーバ+クライアント組み合わせに指し示すトピックフィルタを有するトピック待ち行列を確立させる。一緒に、このペアのアクションは、2つのサーバ間に双方向接続を形成し、一方のサーバに接続されるクライアントは、他方のサーバに接続されるクライアントに到達することができ、逆も同様である。要求/応答メッセージングが、したがって、異なるサーバに接続されるクライアント間で可能にされる。
【0035】
サーバ間で送信されるSUBSCRIBEメッセージが互いに独立する(すなわち、プロトコルレベルにおいて他方をトリガしない)ことに留意することは、重要である。SUBSCRIBEメッセージを受信するサーバは、メッセージが純粋なクライアントではなくクライアント対応サーバに関連付けられているということをプロトコルにおいて信号伝達される方法を有しない(少なくとも、実装が標準準拠のままである場合)。このシナリオにおける最も単純なアプローチは、システム初期化の一部としてサーバ間の静的接続を確立することであり、各サーバは、起動時にその接続を確立するために必要とされる情報で事前に構成されることができるであろう。
【0036】
代替として、独立型サーバ実装内に内蔵された論理が、SUBSCRIBEメッセージのトピックフィルタフィールド内の特定のパターンをサーバ発信メッセージのためのマーカとして取り扱い、そのマーカを戻り方向のコンパニオンSUBSCRIBEメッセージを開始するための信号として使用し得る。統合されたサーバ機能性を伴う上位層論理も、必要に応じて、接続を動的にトリガおよび開始し得る。
【0037】
管理対象の階層(またはURI様)構造がトピック名空間内で管理され、トピック名フィールドにデータ投入するために使用される値/アドレスの大域的な唯一性が維持される限り、協働するサーバに接続されるクライアント間の継続的双方向通信は、可能である。
【0038】
oneM2Mは、MQTTプロトコルバインディングのための技術仕様書を開発している。いくつかの構成代替が、oneM2Mアーキテクチャ内のMQTTサーバの設置に関して技術仕様書に示されるが、これらの構成は全て、MQTTサーバが、MQTTクライアントとのみ通信し、oneM2Mサービス層内の他のMQTTサーバとは通信しない、機能的および論理的に別個のエンティティであるという特性を共有する。
【0039】
図11は、全てのAE1104、CSE1106および1108への接続を維持するサービスプロバイダドメイン内の単一のMQTTサーバ1102を図示する略図である。これは、最も簡単な構成である。
【0040】
図12Aおよび12Bは、oneM2M実施形態における複数のMQTTサーバの使用を図示する。インフラストラクチャドメイン内の単一のモノリシックMQTTサーバの代替は、複数のMQTTサーバを中間ノードに展開し、ネットワークエッジのより近くで(Mca参照点のみを経由して)MQTTをサポートすることである。別の代替は、Mcaトラフィックをフィールドドメイン内で搬送する1つ(またはおそらくそれを上回る)MQTTネットワークと、インフラストラクチャドメインに戻るMccトラフィックを搬送する別個のMQTTネットワークとを有することであろう。このシナリオでは、独立したMQTTネットワーク間のインターワーキングは、oneM2Mサービス層によって行われるであろう。
【0041】
図13は、MQTTサーバ1302を伴うoneM2M実施形態を図示する。単一MQTTサーバ(
図11)の概念をoneM2Mアーキテクチャ構成(
図2)に適用することによって、
図13における例証が生じる。任意の2つのサービス層エンティティ間のトラフィックは、MQTTサーバ1302を通してフローしなければならず、任意の2つのサービス層エンティティ間の通信は、両方がそのMQTTサーバ1302に接続されない限り(またはサービス層がトラフィックをMQTT接続エンティティから非MQTT接続エンティティにパスするための追加の論理を提供しない限り)、可能ではない。
【0042】
図13に示される構成は、現在の開発研究の焦点である。MQTTサーバを追加し、サービス層エンティティをそれらの間に再分配する(例えば、
図12に提案されるように、MQTTサーバをフィールドドメイン内に設置する)ことが可能であるが、特定のMQTTクライアントが接続するMQTTサーバの任意の変更は、新しいサーバのネットワークアドレスをそのクライアントに事前に提供することを要求するであろう。これは、クライアントがサーバを発見するための機構をMQTTが欠いているが、クライアントが、常に、サーバへの接続を開始するからである(したがって、ネットワークアドレスは、ネットワーク接続が行われることが可能な前に、クライアントに利用可能でなければならない)。
【発明を実施するための形態】
【0050】
図14は、oneM2Mのための例示的MQTTメッセージフローを示す、略図である。
図14に示されるMQTTのためのメッセージフローは、実行可能であるが、そのMQTTサブスクリプションを確立する目的のために、固有のトピックフィルタ値を関連付けられたMQTTクライアント1406および1408に提供するサービス層エンティティ(AE1402またはCSE1404)に依拠する。この「自己サブスクリプション」は、応答(および通知)トラフィックをサブスクライブ側エンティティに戻るように向かわせる。
図14では、MQTT接続およびサブスクリプションステップは、成功したと仮定され、AE1402およびCSE1404は、それらのそれぞれのサービス層IDをMQTTサーバ1414の内側に示されるトピック待ち行列のためのトピックフィルタ値として使用していることに留意されたい。この目的のために、AE−IDおよびCSE−ID以外の値を使用することも可能であり得るが、これらのIDは、エンティティをすでに固有に識別しており、サービス層API内で搬送されており、かつMQTTトピック名構造と良好に関連するという利点を有する。
【0051】
しかしながら、oneM2M AEに関する特定の問題が存在する。AE1402は(その関連付けられたMQTTクライアントを通して)、初期サービス層登録に先立って、送信される第1のSUBSCRIBEメッセージのトピックフィルタフィールドにおいて固有の識別子をMQTTサーバ1414にパスすることが可能でなければならない。これは、サーバに、AEに向かって戻る応答メッセージをルーティングするための固有のトピックを提供する。AE−IDは、ここでは使用されることができない。なぜなら、AE−IDは、AEが登録するまでレジストラCSEによって割り当てられておらず、そもそも、登録要求に対する応答がAE−ID値をAEに返送するものだからである。全体として、MQTTトピック名の動的プロビジョニングに利用可能な汎用機構は存在せず、まして、oneM2M識別子(例えば、AE ID、CSE ID)と整合されるものはない。
【0052】
第2のより一般的問題は、サーバ周囲のMQTTネットワークの固有の集中化にある。
図14に図示されるように、MQTTクライアントは、直接、互いに通信することができず、それらの間の通信をブローカするためのサーバに依拠しなければならない。しかし、本来のMQTTプロトコルは、MQTTサーバ間の通信をサポートしない。すなわち、サーバXに接続されるMQTTクライアントはメッセージをサーバYに接続されるMQTTクライアントと交換することができない。したがって、2つ以上のMQTTサーバが、M2M SPドメイン内に存在することになる場合(例えば、ネットワーク拡張の結果として)、MQTTサーバ間のインターワーキングは、サービス層レベルで管理されるか(追加のオーバーヘッドを伴う)、または回避されるかのいずれでなければならない。
【0053】
図14に図示される機能性は、以下に説明される
図22Cまたは22Dに図示されるもののうちの1つ等、M2Mネットワークのノード(例えば、サーバ、ゲートウェイ、デバイス、または他のコンピュータシステム)のメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア(すなわち、コンピュータ実行可能命令)の形態で実装され得ることを理解されたい。
【0054】
図15は、インフラストラクチャドメイン内に位置する単一の標準的MQTTサーバを伴う、例示的メッセージフローを図示する略図である。このフローは、oneM2Mシステムが、McaおよびMcc参照点の両方に適用されるようなoneM2M TS−0010に規定されたMQTTプロトコルバインディング(完成すると)に従うことによって動作するであろう方法を表す。それは、以下に説明される
図19の動作ステップにおいて行われる同一サービスレベル動作と比較したこのアプローチの非効率性を図示する。
【0055】
以下のステップは、
図13に示される構成と整合した単一のMQTTサーバへの全MQTTクライアントの接続およびサブスクリプション(対応するAE−IDまたはCSE−IDに基づく)を前提とする。
【0056】
図15のステップ1では、ADN−AE(「発信側AE」)1502は、サービス層読み出し要求プリミティブをADN MQTTクライアント1504に送信する。プリミティブの「to」パラメータは、<INCSEBase>下に位置するリソースのためのURIである。「from」パラメータは、AE−IDである。
【0057】
図15のステップ2では、ADN MQTTクライアント1504は、PUBLISHメッセージを(グローバル)MQTTサーバ1506に発行する。トピック名ストリングは、レジストラCSE−ID(AEが登録したMN−CSE)に設定される。
【0058】
図15のステップ3では、MQTTサーバは、受信されたトピック名ストリングをそのサブスクリプションリストと比較し、MN−CSE−IDに対する一致を見つける。MQTTサーバ1506は、PUBLISHメッセージを対応するMQTTクライアント1504に転送する。
【0059】
図15のステップ4では、MN MQTTクライアント1504は、受信されたペイロード(すなわち、読み出し要求プリミティブ)をMN−CSE1508(レジストラCSE)に配信する。
【0060】
図15のステップ5では、MN−CSE1508は、読み出し要求の「to」パラメータを調べ、プリミティブが異なるCSEにアドレスされていることを決定する。
【0061】
図15のステップ6では、MN−CSE1508は、「from」パラメータをそれ自身のCSE−IDに更新し、更新されたプリミティブをMN MQTTクライアント1510に転送する。
【0062】
図15のステップ7では、MN MQTTクライアント1510は、PUBLISHメッセージをMQTTサーバ1506に発行する。トピック名ストリングは、標的CSE−ID1512(リソースが位置するIN−CSE)に設定される。
【0063】
図15のステップ8では、MQTTサーバ1506は、受信されたトピック名ストリングをそのサブスクリプションリストと比較し、IN−CSE−IDに対する一致を見つける。MQTTサーバ1506は、PUBLISHメッセージを対応するMQTTクライアントに転送する。
【0064】
図15のステップ9では、IN MQTTクライアントは、受信されたペイロード(すなわち、読み出し要求プリミティブ)をIN−CSE1512(標的CSE)に配信する。
【0065】
図15のステップ10では、規定されたリソースコンテンツが、読み出される(発信側AE1502がアクセス権を有する場合)。
【0066】
図15のステップ11では、IN−CSE1512は、読み出し応答プリミティブをIN MQTTクライアント1514に送信し、動作の成功または失敗を示す。発信プリミティブの「to」パラメータは、受信された「from」パラメータ(MN−CSE−ID)に設定される。「cn」パラメータは、適切なコンテンツに設定される。すなわち、成功の場合(示される)、読み出されるリソースの要求されるコンテンツに設定される。
【0067】
図15のステップ12では、IN MQTTクライアント1514は、PUBLISHメッセージをMQTTサーバに発行する。トピック名ストリングは、受信側CSE−ID(「from」パラメータ内で識別されたMN−CSE1508)に設定される。
【0068】
図15のステップ15では、MQTTサーバ1506は、受信されたトピック名ストリングをそのサブスクリプションリストと比較し、MN−CSE−IDに対する一致を見つける。MQTTサーバ1506は、PUBLISHメッセージを対応するMQTTクライアントに転送する。
【0069】
図15のステップ14では、MN MQTTクライアント1510は、受信されたペイロード(すなわち、読み出し応答プリミティブ)をMN−CSE1508に配信する。
【0070】
図15のステップ15では、MN−CSE1508は、読み出し応答を調べ、それを対応する読み出し要求に関連させる。
【0071】
図15のステップ16では、MN−CSE1508は、「to」パラメータを発信側AE−IDに更新し、更新された読み出し応答プリミティブをMN MQTTクライアント1510に転送する。
【0072】
図15のステップ17では、MN MQTTクライアント1510は、PUBLISHメッセージをMQTTサーバ1506に発行する。トピック名ストリングは、発信側AE−ID(要求を発信した)に設定される。
【0073】
図15のステップ18では、MQTTサーバ1506は、受信されたトピック名ストリングをそのサブスクリプションリストと比較し、AE−IDに対する一致を見つける。MQTTサーバ1506は、PUBLISHメッセージを対応するMQTTクライアントに転送する。
【0074】
図15のステップ19では、ADN MQTTクライアント1504は、受信されたペイロード(すなわち、読み出し応答プリミティブ)をAE1502に配信する。
【0075】
MQTT V3.1.1仕様書[2]は、以下の宣言を含む。
【0076】
サーバ実装は、他の目的のために、前置$文字から始まるトピック名を使用し得る。
「$SYS/は、サーバ特定の情報または制御APIを含むトピックに対するプリフィックスとして広く採用されている」。
【0077】
MQTTのこの特性は、本明細書では、AE登録プロシージャを行うのに先立ってAE−ID値をAEに割り当てる目的のために、oneM2M実施形態に特有のトピック空間を作成するために利用される。特に、トピック名ストリング「$SYS/oneM2M/AE ID/」は、MQTTサーバ+実装によって、ヌルクライアント識別子(ClientId)を使用してMQTTサーバ+への接続を試みるMQTTクライアントを識別するためのフラグとして使用される。このフラグは、接続するエンティティへのAE ID値の事前割り当てをもたらす、
図18に概略される一連のアクションをトリガする。そして、このAE ID値は、接続するエンティティによって、そのサーバ+に関連付けられたCSEからの応答を受信する目的のために、MQTTサーバ+とのサブスクリプションを確立するために使用される。この機構のさらなる詳細は、以下に提供される。
【0078】
図15に図示されるステップを行うエンティティは、
図22Cまたは
図22Dに図示されるもの等、ネットワークノードまたはコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア(すなわち、コンピュータ実行可能命令)の形態で実装され得る論理エンティティであることを理解されたい。すなわち、
図15に図示される方法は、
図22Cまたは
図22Dに図示されるノードもしくはコンピュータシステム等のネットワークノードのメモリ内に記憶されるソフトウェア(すなわち、コンピュータ実行可能命令)の形態で実装され得、そのコンピュータ実行可能命令は、ノードのプロセッサによって実行されると、
図15に図示されるステップを行う。
図15に図示される任意の伝送および受信ステップは、ノードのプロセッサおよびそれが実行するコンピュータ実行可能命令(例えば、ソフトウェア)の制御下、ノードの通信回路によって行われ得ることも理解されたい。
【0079】
図16は、3つのトピックフィルタの使用を図示する略図である。MQTTワイルドカード文字は、要求を送信するエンティティが、そのリソースアドレスに基づくサブスクリプションの組を介して、応答トラフィックを受信することを可能にするために利用される。
図16における3つのトピックフィルタストリングは、CSEBase下の第1のレベルに後置スラッシュを伴うトピック名ストリングを除き、MN−CSE−IDを含むトピック名を伴う全メッセージがMN上のMQTTクライアントに転送されることをもたらす。したがって、AEは、CSEに登録され、「/」が付加されたそのAE識別子(AE−ID)に対応するURIにおいて着信メッセージを受信することができる(そのCSEBaseの周囲に形成されるトピック名を伴う全ての他のメッセージは、CSE自体にルーティングされるであろう)。このように、AEリソース上のCRUD動作は、アクションのためにCSEに配信されるであろうが、依然として、メッセージがAE自体に到達するためのパスが存在する。
【0080】
MQTTストリングは、大文字・小文字を区別するが、RFC 3968 URIのスキームおよびホストコンポーネントは、大文字・小文字を区別しない。したがって、大文字・小文字を区別するMQTTトピック名およびトピックフィルタストリングが、ルーティング目的のために使用されるURI値(例えば、ホストコンポーネント)と適切に関連することを確実にするために配慮されなければならない。
【0081】
oneM2M機能アーキテクチャは、CSEの各発生とともに生じるMQTTサーバ+機能エンティティの存在を反映するように更新される。そのような実施形態は、以下に説明される双方向インターワーキング能力を利用して、図に示されるように、協働サーバ間のトラフィックフローを有効にするであろう。
図13は、oneM2Mにおける現在のアプローチを表す、MQTTサーバの設置に関する代替図を示す。
【0082】
次の2つの図は、ADN−AE1802、MN−CSE1804、およびIN−CSE1806を伴い、CSE1804および1806がMQTTサーバ+機能性で拡張されているサンプル通信フローを図示する。サービス層作成および読み出し動作のみが示されるが、本明細書に図示される方法は、CRUD−SN動作、すなわち、作成、読み出し、更新、削除、サブスクライブ、および通知の全体に等しくて適用される。これらの動作(または「プリミティブ」)は、MQTT PUBLISHメッセージのペイロードパラメータ内で全体的に搬送される。これは、図の「動作」部分に示される。
【0083】
図18は、サービス層作成動作の例を図示するフロー図である。
【0084】
(
図18の前提条件調整ステップ)
これらのステップは、システム初期化の一部として、またはノード間のネットワーク接続が(再)確立されなければならないときは常に行われる。QoSレベルが、
図18に示されるが、例証の目的のために、レベル0に設定される。実際は、説明される技法は、使用されるQoSレベルから独立している。
図18の前提条件調整ステップ1では、MN−CSE1804は、中間ノード(MN)1810上のMQTTクライアント1808に、CONNECTメッセージをそのMNに関連付けられたMQTTサーバ+1812に発行するように命令する。M2Mサービスプロバイダドメインにわたり固有である、MN CSE識別子が、CONNECTメッセージ内のClientIDパラメータとして使用される(ClientIDは、そのMQTTサーバ+への全接続にわたり固有でなければならない)。
【0085】
図18の前提条件調整ステップ2では、MQTTサーバ+1812は、CONNACKメッセージで応答し、接続が承認されたことを示す。
【0086】
図18の前提条件調整ステップ3では、MN−CSE1804は、MN MQTTクライアント1808に、SUBSCRIBEメッセージをMN MQTTサーバ+1812に発行するように命令する。MN−CSE−IDは、SUBSCRIBEメッセージ内にトピックフィルタパラメータを形成するために使用される。4つの別個のトピックフィルタストリングが、このパラメータ内に含まれる。最初の3つのストリングは、MN−CSE1804にアドレスされたトラフィックがそれに向かってルーティングされることをもたらす。第4のストリングは、システム特定の値「$SYS/oneM2M/AE−ID/+」である。このトピックにパブリッシュするクライアントは、サーバ+/レジストラCSEに、<AE>リソース名値(そして、クライアントは、レジストラCSEとのコンタクト開始に先立って、<AE>リソース名値を「自己サブスクライブ」するために使用することができる)の事前割り当に対する要求を信号伝達する。セクションを参照されたい。
【0087】
図18の前提条件調整ステップ4では、MQTTサーバ+1812は、SUBACKメッセージで応答し、4つのサブスクリプション要求の各々が受信および処理されたことを示す。
【0088】
(AEヌル接続)
図18の前提条件調整ステップ5では、アプリケーション専用ノード(ADN)1816上のMQTTクライアント1814は、ADN−AE1802(「発信側AE」)によって、CONNECTメッセージをそのレジストラCSE1804に関連付けられたMQTTサーバ+1812に発行するように命令すされる(このMQTTサーバ+1812のアドレスは、事前構成される)。クライアント識別子(ClientID)パラメータは、ヌル(ゼロバイトの長さ)である。
【0089】
図18の前提条件調整ステップ6では、MQTTサーバ+1812は、ヌルClientIDの受信の結果として、このセッションのための固有のClientID値を割り当て、CONNACKメッセージで応答し、接続が承認されたことを示す。
【0090】
図18の前提条件調整ステップ7では、ADN−AE1802は、ADN MQTTクライアント1814に、SUBSCRIBEメッセージをレジストラCSE1804のMQTTサーバ+1812に発行するように命令する。トピックフィルタパラメータは、システム特定のストリング「$SYS/oneM2M/AE−ID」であり、それは、<AE>リソース名の事前割り当に対する要求に関連付けられたサブスクリプションを表す。
【0091】
図18の前提条件調整ステップ8では、MQTTサーバ+1812は、SUBACKメッセージで応答し、サブスクリプション要求が受信および処理されたことを示す。MQTTサーバ+1812は、特殊文字「/」およびこのセッションのためのClientID値を受信されたトピックフィルタストリング「$SYS/oneM2M/AE−ID」に付加することによって、クライアントのためのサブスクリプションフィルタを作成する。
【0092】
(AE−ID割り当て)
図18の前提条件調整ステップ9では、ADN−AE1802は、ADN MQTTクライアント1814に、PUBLISHメッセージをレジストラCSE1804のMQTTサーバ+1812に発行するように命令する。トピック名パラメータは、システム特定のストリング「$SYS/oneM2M/AE−ID」であり、それは、レジストラCSE1804による<AE>リソース名の事前割り当てのためのフラグを表す。ペイロードパラメータは、ヌル(ゼロバイトの長さ)である。
【0093】
図18の前提条件調整ステップ10では、MN−CSE1804(レジストラCSE)のMQTTサーバ+1812は、システム特定のトピック名ストリング「$SYS/oneM2M/AE−ID」を伴うPUBLISHメッセージを受信すると、特殊文字「/」およびこのセッションのためのClientID値をそれに付加する。修正されたトピック名ストリングは、
図18の前提条件調整ステップ3からのMN MQTTクライアント1808のためのサブスクリプションフィルタに一致し、したがって、MQTTサーバ+1812は、修正されたPUBLISHメッセージをMN MQTTクライアントに転送する。
【0094】
修正されたトピック名ストリングは、
図18の前提条件調整ステップ7からのADN MQTTクライアントのためのサブスクリプションフィルタにも一致するが、サーバ+1812は、この場合、パブリッシャおよび加入者が同一であるので、メッセージを転送しない
図18の前提条件調整ステップ11では、MN−CSE1804は、MN MQTTクライアント1808からの修正されたシステム特定のストリングを伴うPUBLISHメッセージを受信すると、要求を処理し、<AE>リソース名値を割り当てる。
【0095】
図18の前提条件調整ステップ12では、MN−CSE1804は、MN MQTTクライアント1808に、PUBLISHメッセージを関連付けられたMQTTサーバ+に発行するように命令する。トピック名パラメータは、
図18の前提条件調整ステップ10で受信された同じシステム特定のストリングに設定される。ペイロードは、(事前に)割り当てられた<AE>リソース名である。
【0096】
図18の前提条件調整ステップ13では、MQTTサーバ+1812は、修正されたシステム特定のトピック名ストリングを伴うPUBLISHメッセージを受信すると、ストリングが
図18の前提条件調整ステップ8からのADN MQTTクライアント1814のためのサブスクリプションフィルタに一致することを決定する。MQTTサーバ+1812は、PUBLISHメッセージをADN MQTTクライアント1814に転送する。
【0097】
図18の前提条件調整ステップ14では、ADN−AE1802は、ペイロードパラメータをその新しい<AE>リソース名として記憶する。
【0098】
(AEヌル解放)
図18の前提条件調整ステップ15では、ADN−AE1802は、ADN MQTTクライアントに、UNSCRIBE解除メッセージをレジストラCSE1804のMQTTサーバ+1812に発行するように命令する。使用されるトピックフィルタパラメータ値は、
図18の前提条件調整ステップ14に記憶されたものと同一である。
【0099】
図18の前提条件調整ステップ16では、MQTTサーバ+1812は、UNSUBACKメッセージで応答する。
【0100】
図18の前提条件調整ステップ17では、ADN−AE1802は、ADN MQTTクライアント1814に、DISCONNECTメッセージをレジストラCSEのMQTTサーバ+1812に発行するように命令する。ADN MQTTクライアントは、次いで、ネットワーク接続を閉鎖する。
【0101】
図18の前提条件調整ステップ18では、ADN−AE1802は、ADN MQTTクライアント1814に、CONNECTメッセージをそのレジストラCSE1804に関連付けられたMQTTサーバ+1812機能に発行するように命令する。AE識別子(AE−ID)または
図18の前提条件調整ステップ14で記憶された<AE>リソース名に基づくローカルに固有の相対的バージョンが、CONNECTメッセージ内のClientIDパラメータとして使用される。
【0102】
図18の前提条件調整ステップ19では、MQTTサーバ+1812は、CONNACKメッセージで応答し、接続が承認されたことを示す。
【0103】
図18の前提条件調整ステップ20では、ADN MQTTクライアント1814は、SUBSCRIBEメッセージをレジストラCSE1804のMQTTサーバ+1812に発行するように命令される。<AE>URIは、SUBSCRIBEメッセージ内にトピックフィルタパラメータを形成するために使用される。具体的には、特殊文字「/」が、<AE>URIに付加され、トピックフィルタストリングを生成する。
【0104】
図18の前提条件調整ステップ21では、MQTTサーバ+182は、SUBACKメッセージで応答し、サブスクリプション要求が受信および処理されたことを示す。
【0105】
(
図18の動作ステップ)
図18の動作ステップ1では、ADN−AE1802(「発信側AE」)は、サービス層要求プリミティブをADN MQTTクライアント1814に発行する。op(動作)パラメータは、「C」(作成)に設定される。プリミティブのtoパラメータは、<MN−CSEBase>URI(MQTTトピック名ストリングとしても使用される)である。tyパラメータは、<AE>リソースタイプを示し、それは、レジストラCSEに、ADN−AEのための<AE>リソースを作成する(すなわち、アプリケーション登録を行う)ように命令する。nmパラメータは、
図18の前提条件調整ステップ14で受信された<AE>リソース名値に設定される。
【0106】
図18の動作ステップ2では、ADN MQTTクライアント1814は、PUBLISHメッセージをMN MQTTサーバ+1812(それが接続を確立した)に発行する。
【0107】
図18の動作ステップ3では、MN MQTTサーバ+1812は、受信されたトピック名(<MN−CSEBase>URI)をそのサブスクリプションリストと比較し、MN MQTTクライアント1808に対応する一致を見つける(
図18の前提条件調整ステップ3の上記例を参照)。MN MQTTサーバ+1812は、PUBLISHメッセージをMN MQTTクライアント1808に転送する。
【0108】
図18の動作ステップ4では、MN MQTTクライアント1808は、受信されたペイロード(すなわち、サービス層作成要求プリミティブ)をMN−CSE1804(レジストラCSE)に配信する。
【0109】
図18の動作ステップ5では、<AE>リソースが、MN−CSEBase下に作成される(AEが、認証に成功し、十分なアクセス権を有する場合)。
【0110】
図18の動作ステップ6では、MN−CSE1804は、応答プリミティブをMN MQTTクライアント1808に送信し、rsパラメータ内に作成動作の成功または失敗を示す。発信応答プリミティブのtoパラメータは、作成されたばかりの<AE>リソースのURIに設定される。cnパラメータは、適切なコンテンツに設定される。すなわち、成功の場合(示される)、作成された<AE>リソースのURIに設定される。
【0111】
図18の動作ステップ7では、MN MQTTクライアント1808は、PUBLISHメッセージを関連付けられたMN MQTTサーバ+1812に発行する。
【0112】
図18の動作ステップ8では、MN MQTTサーバ+1812は、受信されたトピック名(<AE>URI)をそのサブスクリプションリストと比較し、ADN MQTTクライアント1814に対応する一致を見つける。MN MQTTサーバ+1812は、PUBLISHメッセージをADN MQTTクライアント1814に転送する。
【0113】
図18の動作ステップ9では、ADN MQTTクライアント1814は、受信されたペイロード(すなわち、作成応答プリミティブ)をADN−AE1802に配信する。
【0114】
一実施形態は、MQTTサーバ+1812等のMQTTサーバにおける方法である。パブリッシュ要求が、ADN1816等のアプリケーションから受信され、それは、
図18の前提条件調整ステップ9におけるように、アプリケーション識別子に対する要求に関連する所定のトピックフィルタパラメータを使用する。所定のトピックフィルタパラメータに応答して、
図18の前提条件調整ステップ10におけるように、一時的クライアントIDを含むメッセージが、レジストラCSE1804のためにパブリッシュされる。
図18の前提条件調整ステップ12におけるように、割り当てられたアプリケーション名をペイロードとして含むメッセージが、レジストラCSE1804から受信される。割り当てられたアプリケーション名は、
図18の前提条件調整ステップ13におけるように、アプリケーションに提供される。サブスクリプション要求が、
図18の前提条件調整ステップ20におけるように、割り当てられたアプリケーション名をトピックフィルタの一部として含むアプリケーションから受信される。
【0115】
別の実施形態は、ADN1802等のアプリケーションにおける方法である。
図18の前提条件調整ステップ9におけるように、パブリッシュ要求がMQTTサーバ+1812等のMQTTサーバに送信され、それは、アプリケーション識別子に対する要求に関連する所定のトピックフィルタパラメータを使用する。割り当てられたアプリケーション名をペイロードとして含むメッセージが、MQTTサーバ+1812から受信される。
図18の前提条件調整ステップ20におけるように、割り当てられたアプリケーション名をトピックフィルタの一部として含むサブスクリプション要求が、MQTTサーバ1812に送信される。
【0116】
図18に図示されるステップを行うエンティティは、
図22Cまたは
図22Dに図示されるもの等のネットワークノードまたはコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア(すなわち、コンピュータ実行可能命令)の形態で実装され得る論理エンティティであることを理解されたい。すなわち、
図18に図示される方法は、コンピュータ実行可能命令が、ノードのプロセッサによって実行されると、
図18に図示されるステップを行う、
図22Cまたは
図22Dに図示されるノードまたはコンピュータシステム等のネットワークノードのメモリ内に記憶されるソフトウェア(すなわち、コンピュータ実行可能命令)の形態で実装され得る。さらに、
図18に図示される任意の伝送および受信ステップは、ノードのプロセッサおよびそれが実行するコンピュータ実行可能命令(例えば、ソフトウェア)の制御下、ノードの通信回路によって行われ得ることも理解されたい。
【0117】
図19は、サービス層読み出し動作の実施例を図示するフロー図である。
【0118】
(
図19の前提条件調整ステップ)
これらのステップは、ノード間のネットワーク接続が(再)確立されなければならないときは常に行われることができる。AE1802は、すでに登録され、AE−IDが割り当てられている。
【0119】
図19の前提条件調整ステップ1では、ADN−AE1802は、ADN MQTTクライアント1814に、CONNECTメッセージをそのレジストラCSE1804に関連付けられたMQTTサーバ+1812に発行するように命令する。AE識別子(AE−ID)または<AE>リソース名に基づくローカルに固有の相対的バージョンが、CONNECTメッセージ内のClientIDパラメータとして使用される。
【0120】
図19の前提条件調整ステップ2では、MQTTサーバ+1812は、CONNACKメッセージで応答し、接続が承認されたことを示す。
【0121】
図19の前提条件調整ステップ3では、ADN−AE1802は、ADN MQTTクライアントに、SUBSCRIBEメッセージをレジストラCSE1804のMQTTサーバ+1812に発行するように命令する。<AE>URIは、SUBSCRIBEメッセージ内にトピックフィルタパラメータを形成するために使用される。具体的には、MQTT特殊文字「/」が、<AE>URIに付加され、トピックフィルタストリングを構成する。
【0122】
図19の前提条件調整ステップ4では、MQTTサーバ+1812は、SUBACKメッセージで応答し、サブスクリプション要求が受信および処理されたことを示す。
【0123】
図19の前提条件調整ステップ5では、IN−CSE1806は、IN MQTTクライアント1820に、CONNECTメッセージをそのIN1824に関連付けられたMQTTサーバ+1822に発行するように命令する。INのCSE識別子(M2Mサービスプロバイダドメインにわたり固有であるIN−CSE−ID)が、CONNECTメッセージ内のClientIDパラメータとして使用される。
【0124】
図19の前提条件調整ステップ6では、MQTTサーバ+1812は、CONNACKメッセージで応答し、接続が承認されたことを示す。
【0125】
図19の前提条件調整ステップ7では、IN−CSE1806は、IN MQTTクライアント1820に、SUBSCRIBEメッセージをIN MQTTサーバ+1822に発行するように命令する。IN−CSE−IDが、SUBSCRIBEメッセージ内のトピックフィルタパラメータを構成するために使用される3つの別個のトピックフィルタストリングが、このパラメータ内に含まれる:‘<IN−CSE−ID>’、および、MQTT単一レベルおよびマルチレベルワイルドカード文字を‘<IN−CSE−ID>’に付加することによって形成される2つの追加のストリング。
【0126】
図19の前提条件調整ステップ8では、MQTTサーバ+1822は、SUBACKメッセージで応答し、3つのサブスクリプション要求の各々が受信および処理されたことを示す。
【0127】
ステップ9−16では、MQTTサーバ+1822は、CONNECTまたはSUBSCRIBEを発行するとき、MQTTクライアントとしての役割を果たす。
【0128】
図19の前提条件調整ステップ9では、MN−CSE1804は、MN MQTTサーバ+1812に、CONNECTメッセージをIN MQTTサーバ+1822に発行するように命令する(IN MQTTサーバ+1822のアドレスは、事前構成される)。MN−CSE−IDは、ClientIDパラメータとして使用される。
【0129】
図19の前提条件調整ステップ10では、IN MQTTサーバ+1822は、CONNACKメッセージで応答し、接続が承認されたことを示す。
【0130】
図19の前提条件調整ステップ11では、MN−CSE1804は、MN MQTTサーバ+1812に、SUBSCRIBEメッセージをIN MQTTサーバ+1822に発行するように命令する。<MN−CSE−ID>URIは、SUBSCRIBEメッセージ内にトピックフィルタパラメータストリングを形成するために使用される。具体的には、MQTT特殊文字「/#」が、<MN−CSE−ID>URIに付加され、トピックフィルタストリングを構成する。このストリングは、IN MQTTサーバ+1822に、MN−CSEBaseの第1のレベルまたはその下方における任意の受信されたトピック名をMN MQTTサーバ+1812に転送するように命令する。
【0131】
図19の前提条件調整ステップ12では、IN MQTTサーバ+1822は、SUBACKメッセージで応答し、サブスクリプション要求が受信および処理されたことを示す。
【0132】
図19の前提条件調整ステップ13では、IN−CSE1806は、IN MQTTサーバ+1822に、CONNECTメッセージをMN MQTTサーバ+1822に発行するように命令する(MN MQTTサーバ+1812のアドレスは、事前構成される)。IN−CSE−IDは、ClientIDパラメータとして使用される。
【0133】
図19の前提条件調整ステップ14では、MN MQTTサーバ+1812は、CONNACKメッセージで応答し、接続が承認されたことを示す。
【0134】
図19の前提条件調整ステップ15では、IN−CSE1806は、IN MQTTサーバ+1822に、SUBSCRIBEメッセージをMN MQTTサーバ+1822に発行するように命令する。<IN−CSE−ID>URIは、SUBSCRIBEメッセージ内にトピックフィルタパラメータストリングを形成するために使用される。具体的には、MQTT特殊文字「/#」が、<IN−CSE−ID>URIに付加され、トピックフィルタストリングを構成する。このストリングは、MN MQTTサーバ+1812に、IN−CSEBaseの第1のレベルまたはその下方における任意の受信されたトピック名をIN MQTTサーバ+1822に転送するように命令する。
【0135】
図19の前提条件調整ステップ16では、MN MQTTサーバ+1812は、SUBACKメッセージで応答し、サブスクリプション要求が受信および処理されたことを示す。
【0136】
(
図19の動作ステップ)
以下のステップは、前述の前提条件調整ステップが生じたことを前提とする。
【0137】
図19の動作ステップ1では、ADN−AE1802(「発信側AE」)は、サービス層読み出し要求プリミティブをADN MQTTクライアント1814に発行する。プリミティブのtoパラメータは、<IN−CSEBase>下に位置するリソースのためのURIである(MQTTトピック名ストリングとしても使用される)。frパラメータは、<AE−ID>URIである(標的CSEによって応答をアドレスするために使用される)。
【0138】
図19の動作ステップ2では、ADN MQTTクライアント1814は、要求プリミティブをそのペイロードとして有するPUBLISHメッセージをMN MQTTサーバ+1812(それが
図19の前提条件調整ステップ1において接続を確立した)に発行する。
【0139】
図19の動作ステップ3では、MN MQTTサーバ+1812は、受信されたトピック名(<IN−CSEBase>下のリソースURI)をそのサブスクリプションリストと比較し、IN MQTTサーバ+1822に対応する一致を見つける(上記の
図19の前提条件調整ステップ14を参照)。MN MQTTサーバ+1812は、PUBLISHメッセージをIN MQTTサーバ+1822に転送する。
【0140】
図19の動作ステップ4では、IN MQTTサーバ+1822は、受信されたトピック名(<IN−CSEBase>下のリソースURI)をそのサブスクリプションリストと比較し、IN MQTTクライアントに対応する一致を見つける(上記の
図19の前提条件調整ステップ6を参照)。IN MQTTサーバ+は、PUBLISHメッセージをIN MQTTクライアント1820に転送する。
【0141】
図19の動作ステップ5では、IN MQTTクライアントは、受信されたペイロード(すなわち、読み出し要求プリミティブ)をIN−CSE1806(標的CSE)に配信する。
【0142】
図19の動作ステップ6では、規定されたリソースコンテンツが、読み出される(発信側AE1802がアクセス権を有する場合)。
【0143】
図19の動作ステップ7では、IN−CSE1806は、読み出し応答プリミティブをIN MQTTクライアント1820に発行する。発信プリミティブのtoパラメータは、受信されたfrパラメータ(「/」が付加された<AE>URI)に設定される。cnパラメータは、適切なコンテンツに設定される。すなわち成功の場合(示される)、読み出されるリソースの要求されるコンテンツに設定される。
【0144】
図19の動作ステップ8では、IN MQTTクライアント1820は、応答プリミティブをそのペイロードとして有するPUBLISHメッセージをIN MQTTサーバ+1822に発行する。
【0145】
図19の動作ステップ9では、IN MQTTサーバ+1822は、受信されたトピック名(「/」が付加されたr<MN−CSEBase>下の<AE>のURI)をそのサブスクリプションリストと比較し、MN MQTTサーバ+1812に対応する一致を見つける(上記の前提条件調整ステップ14を参照)。IN MQTTサーバ+1822は、PUBLISHメッセージをMN MQTTサーバ+1812に転送する。
【0146】
図19の動作ステップ10では、MN MQTTサーバ+1812は、受信されたトピック名(「/」が付加された<MN−CSEBase>下の<AE>のURI)を比較し、ADN−AEに対応する一致を見つける。MN MQTTサーバ+1812は、PUBLISHメッセージをADN MQTTクライアント1814に転送する。さらに、
図16におけるトピック名一致実施例も参照されたい。
【0147】
図19の動作ステップ11では、ADN MQTTクライアント1814は、読み出し応答(すなわち、PUBLISHメッセージのペイロード)を発信側AE1802に配信する。
【0148】
一実施形態は、中間ノードのMQTTサーバ+1812における方法である。
図19の前提条件調整ステップ3に示されるように、サブスクライブ要求が、中間ノード1810およびアプリケーション1816を示すトピックフィルタを伴ってアプリケーションから受信される。
図19の前提条件調整ステップ11に示されるように、サブスクライブ要求が、インフラストラクチャノード1824を示すトピックフィルタを伴うトピックに対して、インフラストラクチャノード1824におけるMQTTサーバ1822に送信される。
図19の前提条件調整ステップ15に示されるように、サブスクライブ要求が、インフラストラクチャノード1824を示すトピックフィルタを伴うトピックに対して、インフラストラクチャノード1824におけるMQTTサーバ1822から受信される。メッセージが、中間ノードおよびインフラストラクチャノードに作成されたトピックを使用して、アプリケーションとインフラストラクチャノードとの間で、中間ノードを通して転送されることができる。
【0149】
図19に図示されるステップを行うエンティティは、
図22Cまたは
図22Dに図示されるもの等のネットワークノードまたはコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア(すなわち、コンピュータ実行可能命令)の形態で実装され得る論理エンティティであることを理解されたい。すなわち、
図19に図示される方法は、コンピュータ実行可能命令が、ノードのプロセッサによって実行されると、
図19に図示されるステップを行う、
図22Cまたは
図22Dに図示されるノードまたはコンピュータシステム等のネットワークノードのメモリ内に記憶されるソフトウェア(すなわち、コンピュータ実行可能命令)の形態で実装され得る。さらに、
図19に図示される任意の伝送および受信ステップは、ノードのプロセッサおよびそれが実行するコンピュータ実行可能命令(例えば、ソフトウェア)の制御下、ノードの通信回路によって行われ得ることも理解されたい。
【0150】
図20は、拡張oneM2M ROA実施形態におけるMQTT CSFを図示する略図である。前述のMQTTサーバ+機能は、アドオンソフトウェアライブラリとして実装されることができる。すなわち、それは、機能するために、CSEの中に統合される必要はない。しかしながら、
図20に示されるように、MQTTパブリケーションおよび配信機能性が他のサービス機能とより密に結合される場合、さらなる最適化が可能である。
【0151】
例えば、接続の動的確立および分断は、MQTTサーバ+2004およびCSE2002が別個である場合、煩雑である。なぜなら、CSE2002が、それらを管理するために、常時、MQTTサーバ+2004によって維持される接続を把握する必要があるだろうからである(おそらく、別個のエンティティである場合、照会機構を介して)。CSE2002の中への統合は、この問題を軽減する。さらに、AE−ID事前割り当ては、統合されたMQTTサーバ2004が、AE−ID事前割り当てを要求するトリガストリングを処理のために直接CSE2002にパスし、結果を直接要求側AEに返すことができるので、はるかに少ないプロトコルオーバーヘッドを要求するであろう。
【0152】
図20に図示される機能性は、以下に説明される
図22Cまたは22Dに図示されるもの等のM2Mネットワークのノード(例えば、サーバ、ゲートウェイ、デバイス、または他のコンピュータシステム)のメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア(すなわち、コンピュータ実行可能命令)の形態で実装され得ることを理解されたい。
【0153】
グラフィカルユーザインターフェース(GUI)等のインターフェースは、MQTTを使用して、サービス層ROAインターネットワーキングに関係付けられる機能性を制御および/または構成するようにユーザを支援するために使用されることができる。
図21は、ユーザが、識別子番号を決定し、デバイスを登録および登録解除することを可能にする、インターフェース2102を図示する略図である。インターフェース2102は、以下で説明される
図22C−Dに示されるもの等のディスプレイを使用して生成されることができることを理解されたい。
【0154】
(例示的M2M/IoT/WoT通信システム)
図22Aは、1つ以上の開示される実施形態が実装され得る、例示的マシンツーマシン(M2M)、モノのインターネット(IoT)、またはモノのウェブ(WoT)通信システム10の略図である。概して、M2M技術は、IoT/WoTのための基礎的要素を提供し、任意のM2Mデバイス、M2Mゲートウェイ、M2Mサーバ、またはM2Mサービスプラットフォームは、IoT/WOTだけではなく、IoT/WoTサービス層等のコンポーネントまたはノードであり得る。通信システム10は、開示される実施形態の機能性を実装するために使用されることができ、発信側AE1802、MQTTサーバ+1812、1822、および2004、CSE1804、1806、および2002、ならびにGUI2102を作成するための論理エンティティ等の機能性および論理エンティティを含むことができる。
【0155】
図22Aに示されるように、M2M/IoT/WoT通信システム10は、通信ネットワーク12を含む。通信ネットワーク12は、固定ネットワーク(例えば、イーサネット(登録商標)、ファイバ、ISDN、PLC等)もしくは無線ネットワーク(例えば、WLAN、セルラー等)もしくは異種ネットワークのネットワークであり得る。例えば、通信ネットワーク12は、音声、データ、ビデオ、メッセージング、ブロードキャスト等のコンテンツを複数のユーザに提供する多重アクセスネットワークから成り得る。例えば、通信ネットワーク12は、符号分割多重アクセス(CDMA)、時分割多重アクセス(TDMA)、周波数分割多重アクセス(FDMA)、直交FDMA(OFDMA)、単一キャリアFDMA(SC−FDMA)等の1つ以上のチャネルアクセス方法を採用し得る。さらに、通信ネットワーク12は、例えば、コアネットワーク、インターネット、センサネットワーク、工業制御ネットワーク、パーソナルエリアネットワーク、融合個人ネットワーク、衛星ネットワーク、ホームネットワーク、または企業ネットワーク等の他のネットワークを備え得る。
【0156】
図22Aに示されるように、M2M/IoT/WoT通信システム10は、インフラストラクチャドメインおよびフィールドドメインを含み得る。インフラストラクチャドメインは、エンドツーエンドM2M展開のネットワーク側を指し、フィールドドメインは、通常、M2Mゲートウェイの背後にあるエリアネットワークを指す。フィールドドメインおよびインフラストラクチャドメインは両方とも、種々の異なるネットワークノード(例えば、サーバ、ゲートウェイ、デバイス等)を備え得る。例えば、フィールドドメインは、M2Mゲートウェイ14と、端末デバイス18とを含み得る。任意の数のM2Mゲートウェイデバイス14およびM2M端末デバイス18が、所望に応じて、M2M/IoT/WoT通信システム10に含まれ得ることが理解されるであろう。M2Mゲートウェイデバイス14およびM2M端末デバイス18の各々は、通信回路を使用して、通信ネットワーク12または直接無線リンクを介して、信号を伝送および受信するように構成される。M2Mゲートウェイ14は、無線M2Mデバイス(例えば、セルラーおよび非セルラー)ならびに固定ネットワークM2Mデバイス(例えば、PLC)が、通信ネットワーク12等のオペレータネットワークを通して、または直接無線リンクを通してのいずれかで、通信することを可能にする。例えば、M2M端末デバイス18は、データを収集し、通信ネットワーク12または直接無線リンクを介して、データをM2Mアプリケーション20または他のM2M端末デバイス18に送信し得る。M2M端末デバイス18はまた、M2Mアプリケーション20またはM2M端末デバイス18からデータを受信し得る。さらに、データおよび信号は、以下で説明されるように、M2Mサービス層22を介して、M2Mアプリケーション20に送信され、そこから受信され得る。M2M端末デバイス18およびゲートウェイ14は、例えば、セルラー、WLAN、WPAN(例えば、Zigbee(登録商標)、6LoWPAN、Bluetooth(登録商標))、直接無線リンク、および有線を含む、種々のネットワークを介して通信し得る。
【0157】
例示的M2M端末デバイス18は、タブレット、スマートフォン、医療デバイス、温度および天候モニタ、コネクテッドカー、スマートメータ、ゲームコンソール、携帯情報端末、健康およびフィットネスモニタ、照明、サーモスタット、電気器具、車庫のドアおよび他のアクチュエータベースのデバイス、セキュリティデバイス、ならびにスマートコンセントを含むが、それらに限定されない。
【0158】
図22Bを参照すると、フィールドドメイン内の図示されるM2Mサービス層22は、M2Mアプリケーション20、M2Mゲートウェイデバイス14、およびM2M端末デバイス18、ならびに通信ネットワーク12のためのサービスを提供する。通信システムネットワーク12は、開示される実施形態の機能性を実装するために使用されることができ、発信側AE1802、MQTTサーバ+1812、1822、および2004、ならびにCSE1804、1806、および2002等の機能性および論理エンティティを含むことができる。M2Mサービス層22は、例えば、以下で説明される
図22Cおよび22Dで図示されるデバイスを含む、1つ以上のサーバ、コンピュータ、デバイス、仮想マシン(例えば、クラウド/記憶ファーム等)等によって実装され得る。M2Mサービス層22は、所望に応じて、任意の数のM2Mアプリケーション、M2Mゲートウェイ14、M2M端末デバイス18、および通信ネットワーク12と通信し得ることが理解されるであろう。M2Mサービス層22は、サーバ、コンピュータ、デバイス等を備え得る、ネットワークの1つ以上のノードによって実装され得る。M2Mサービス層22は、M2M端末デバイス18、M2Mゲートウェイデバイス14、およびM2Mアプリケーション20に適用されるサービス能力を提供する。M2Mサービス層22の機能は、例えば、ウェブサーバとして、セルラーコアネットワーク内で、クラウド内で等、種々の方法で実装され得る。
【0159】
図示されるM2Mサービス層22と同様に、インフラストラクチャドメイン内にM2Mサービス層22’が、存在する。M2Mサービス層22’は、インフラストラクチャドメイン内のM2Mアプリケーション20’および下層通信ネットワーク12’のためのサービスを提供する。M2Mサービス層22’はまた、フィールドドメイン内のM2Mゲートウェイデバイス14およびM2Mデバイス18のためのサービスも提供する。M2Mサービス層22’は、任意の数のM2Mアプリケーション、M2Mゲートウェイ、およびM2Mデバイスと通信し得ることが理解されるであろう。M2Mサービス層22’は、異なるサービスプロバイダによるサービス層と相互作用し得る。M2Mサービス層22’は、サーバ、コンピュータ、デバイス、仮想マシン(例えば、クラウドコンピューティング/記憶ファーム等)等を備え得る、ネットワークの1つ以上のノードによって実装され得る。
【0160】
図22Bも参照すると、M2Mサービス層22および22’は、多様なアプリケーションおよびバーティカルが活用することができる、サービス配信能力のコアの組を提供する。これらのサービス能力は、M2Mアプリケーション20および20’がデバイスと相互作用し、データ収集、データ分析、デバイス管理、セキュリティ、課金、サービス/デバイス発見等の機能を果たすことを可能にする。本質的に、これらのサービス能力は、これらの機能性を実装する負担をアプリケーションから取り除き、したがって、アプリケーション開発を単純化し、市場に出すコストおよび時間を削減する。サービス層22および22’はまた、M2Mアプリケーション20および20’が、サービス層22および22’が提供するサービスと関連して、種々のネットワーク12および12’を通して通信することも可能にする。
【0161】
本願の方法は、サービス層22および22’の一部として実装され得る。サービス層22および22’は、アプリケーションプログラミングインターフェース(API)および下層ネットワーキングインターフェースの組を通して付加価値サービス能力をサポートするソフトウェアミドルウェア層である。ETSI M2MおよびoneM2Mの両方は、本願の接続方法を含み得るサービス層を使用する。ETSI M2Mのサービス層は、サービス能力層(SCL)と称される。SCLは、M2Mデバイス(デバイスSCL(DSCL)と称される)、ゲートウェイ(ゲートウェイSCL(GSCL)と称される)、および/またはネットワークノード(ネットワークSCL(NSCL)と称される)内に実装され得る。oneM2Mサービス層は、共通サービス機能(CSF)(すなわち、サービス能力)の組をサポートする。1つ以上の特定のタイプのCSFの組のインスタンス化は、異なるタイプのネットワークノード(例えば、インフラストラクチャノード、中間ノード、特定用途向けノード)上にホストされ得る共通サービスエンティティ(CSE)と称される。さらに、本願の接続方法は、本願の接続方法等のサービスにアクセスするために、サービス指向アーキテクチャ(SOA)および/またはリソース指向アーキテクチャ(ROA)を使用する、M2Mネットワークの一部として実装されることができる。
【0162】
いくつかの実施形態では、M2Mアプリケーション20および20’は、開示されるシステムおよび方法と併せて使用され得る。M2Mアプリケーション20および20’は、UEまたはゲートウェイと相互作用するアプリケーションを含み得、さらに、他の開示されるシステムおよび方法と併せて使用され得る。
【0163】
一実施形態では、発信側AE1802、MQTTサーバ+1812、1822、および2004、CSE1804、1806、および2002、ならびにGUI2102を作成するための論理エンティティ等の論理エンティティは、
図22Bに示されるように、M2Mサーバ、M2Mゲートウェイ、またはM2Mデバイス等のM2Mノードによってホストされる、M2Mサービス層インスタンス内にホストされ得る。例えば、発信側AE1802、MQTTサーバ+1812、1822、および2004、CSE1804、1806、および2002、ならびにGUI2102を作成するための論理エンティティ等の論理エンティティは、M2Mサービス層インスタンス内で、または既存のサービス能力内のサブ機能として、個々のサービス能力を備え得る。
【0164】
M2Mアプリケーション20および20’は、限定ではないが、輸送、保健および健康、コネクテッドホーム、エネルギー管理、アセット追跡、ならびにセキュリティおよび監視等の種々の業界でのアプリケーションを含み得る。前述のように、システムのデバイス、ゲートウェイ、サーバ、および他のノードにわたって作動するM2Mサービス層は、例えば、データ収集、デバイス管理、セキュリティ、課金、場所追跡/ジオフェンシング、デバイス/サービス発見、およびレガシーシステム統合等の機能をサポートし、サービスとしてこれらの機能をM2Mアプリケーション20および20’に提供する。
【0165】
概して、サービス層22および22’は、アプリケーションプログラミングインターフェース(API)および下層ネットワーキングインターフェースの組を通して付加価値サービス能力をサポートするソフトウェアミドルウェア層を定義する。ETSI M2MおよびoneM2Mアーキテクチャの両方は、サービス層を定義する。ETSI M2Mのサービス層は、サービス能力層(SCL)と称される。SCLは、ETSI M2Mアーキテクチャの種々の異なるノード内に実装され得る。例えば、サービス層のインスタンスは、M2Mデバイス(デバイスSCL(DSCL)と称される)、ゲートウェイ(ゲートウェイSCL(GSCL)と称される)、および/またはネットワークノード(ネットワークSCL(NSCL)と称される)内で実装され得る。oneM2Mサービス層は、共通サービス機能(CSF)(すなわち、サービス能力)の組をサポートする。1つ以上の特定のタイプのCSFの組のインスタンス化は、異なるタイプのネットワークノード(例えば、インフラストラクチャノード、中間ノード、特定用途向けノード)上にホストされ得る共通サービスエンティティ(CSE)と称される。第3世代パートナーシッププロジェクト(3GPP)はまた、マシンタイプ通信(MTC)のためのアーキテクチャも定義している。そのアーキテクチャでは、サービス層、およびそれが提供するサービス能力は、サービス能力サーバ(SCS)の一部として実装される。ETSI M2MアーキテクチャのDSCL、GSCL、またはNSCLで具現化されようと、3GPP MTCアーキテクチャのサービス能力サーバ(SCS)で具現化されようと、oneM2MアーキテクチャのCSFまたはCSEで具現化されようと、もしくはネットワークのある他のノードとして具現化されようと、サービス層のインスタンスは、サーバ、コンピュータ、および他のコンピュータデバイスまたはノードを含む、ネットワーク内の1つ以上の独立型ノード上で実行される論理エンティティ(例えば、ソフトウェア、コンピュータ実行可能命令等)として、もしくは1つ以上の既存のノードの一部としてのいずれかで実装され得る。実施例として、サービス層またはそのコンポーネントのインスタンスは、以下で説明される
図22Cまたは
図22Dで図示される一般アーキテクチャを有する、ネットワークノード(例えば、サーバ、コンピュータ、ゲートウェイ、デバイス等)上で作動するソフトウェアの形態において実装され得る。
【0166】
さらに、発信側AE1802、MQTTサーバ+1812、1822、および2004、CSE1804、1806、および2002、ならびにGUI2102を作成するための論理エンティティ等の本願の論理エンティティは、本願のサービスにアクセスするために、サービス指向アーキテクチャ(SOA)および/またはリソース指向アーキテクチャ(ROA)を使用する、M2Mネットワークの一部として実装されることができる。
【0167】
図22Cは、M2Mデバイス18、M2Mゲートウェイ14、M2Mサーバ等のM2Mネットワークノード30の例示的ハードウェア/ソフトウェアアーキテクチャのブロック図である。ノード30は、発信側AE1802、MQTTサーバ+1812、1822、および2004、CSE1804、1806、および2002、ならびにGUI2102を作成するための論理エンティティ等の論理エンティティを実行すること、または含むことができる。デバイス30は、
図22A−Bに示されるようなM2Mネットワーク、もしくは非M2Mネットワークの一部であり得る。
図22Cに示されるように、M2Mノード30は、プロセッサ32と、非取り外し可能なメモリ44と、取り外し可能なメモリ46と、スピーカ/マイクロホン38と、キーパッド40と、ディスプレイ、タッチパッド、および/またはインジケータ42と、電源48と、全地球測位システム(GPS)チップセット50と、他の周辺機器52とを含み得る。ノード30はまた、送受信機34および伝送/受信要素36等の通信回路を含み得る。M2Mノード30は、実施形態と一致したままで、先述の要素の任意の副次的組み合わせを含み得ることが理解されるであろう。このノードは、本明細書に説明されるSMSF機能性を実装するノードであり得る。
【0168】
プロセッサ32は、汎用プロセッサ、特殊目的プロセッサ、従来のプロセッサ、デジタル信号プロセッサ(DSP)、複数のマイクロプロセッサ、DSPコアと関連する1つ以上のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)回路、任意の他のタイプの集積回路(IC)、状態マシン等であり得る。一般に、プロセッサ32は、ノードの種々の要求される機能を果たすために、ノードのメモリ(例えば、メモリ44および/またはメモリ46)内に記憶されているコンピュータ実行可能命令を実行し得る。例えば、プロセッサ32は、信号符号化、データ処理、電力制御、入出力処理、および/またはM2Mノード30が無線もしくは有線環境内で動作することを可能にする任意の他の機能性を行い得る。プロセッサ32は、アプリケーション層プログラム(例えば、ブラウザ)および/または無線アクセス層(RAN)プログラムならびに/もしくは他の通信プログラムを起動させ得る。プロセッサ32はまた、例えば、アクセス層および/またはアプリケーション層等で、認証、セキュリティキー一致、ならびに/もしくは暗号化動作等のセキュリティ動作を行い得る。
【0169】
図22Cに示されるように、プロセッサ32は、その通信回路(例えば、送受信機34および伝送/受信要素36)に連結される。プロセッサ32は、ノード30に、それが接続されるネットワークを介して他のノードと通信させるために、コンピュータ実行可能命令の実行を通して、通信回路を制御し得る。特に、プロセッサ32は、本明細書および請求項に説明される伝送および受信ステップを行うために、通信回路を制御し得る。
図22Cは、プロセッサ32および送受信機34を別個のコンポーネントとして描写するが、プロセッサ32および送受信機34は、電子パッケージまたはチップ内に一緒に統合され得ることが理解されるであろう。
【0170】
伝送/受信要素36は、M2Mサーバ、ゲートウェイ、デバイス等を含む、他のM2Mノードに信号を伝送し、またはそこから信号を受信するように構成され得る。例えば、ある実施形態では、伝送/受信要素36は、RF信号を伝送および/または受信するように構成されるアンテナであり得る。伝送/受信要素36は、WLAN、WPAN、セルラー等の種々のネットワークならびにエアインターフェースをサポートし得る。ある実施形態では、伝送/受信要素36は、例えば、IR、UV、または可視光信号を伝送ならびに/もしくは受信するように構成されるエミッタ/検出器であり得る。さらに別の実施形態では、伝送/受信要素36は、RFおよび光信号の両方を伝送ならびに受信するように構成され得る。伝送/受信要素36は、無線または有線信号の任意の組み合わせを伝送ならびに/もしくは受信するように構成され得ることが理解されるであろう。
【0171】
加えて、伝送/受信要素36は、単一の要素として
図22Cに描写されているが、M2Mノード30は、任意の数の伝送/受信要素36を含み得る。より具体的には、M2Mノード30は、MIMO技術を採用し得る。したがって、ある実施形態では、M2Mノード30は、無線信号を伝送および受信するための2つ以上の伝送/受信要素36(例えば、複数のアンテナ)を含み得る。
【0172】
送受信機34は、伝送/受信要素36によって伝送される信号を変調するように、および伝送/受信要素36によって受信される信号を復調するように構成され得る。上記のように、M2Mノード30は、マルチモード能力を有し得る。したがって、送受信機34は、M2Mノード30が、例えば、UTRAおよびIEEE802.11等の複数のRATを介して通信することを可能にするための複数の送受信機を含み得る。
【0173】
プロセッサ32は、非取り外し可能なメモリ44および/または取り外し可能なメモリ46等の任意のタイプの好適なメモリから情報にアクセスし、その中にデータを記憶し得る。例えば、プロセッサ32は、前述のように、セッションコンテキストをそのメモリ内に記憶し得る。非取り外し可能なメモリ44は、ランダムアクセスメモリ(RAM)、読み取り専用メモリ(ROM)、ハードディスク、または任意の他のタイプのメモリ記憶デバイスを含み得る。取り外し可能なメモリ46は、加入者識別モジュール(SIM)カード、メモリスティック、セキュアデジタル(SD)メモリカード等を含み得る。他の実施形態では、プロセッサ32は、サーバまたはホームコンピュータ上等、M2Mノード30上に物理に位置しないメモリから情報にアクセスし、その中にデータを記憶し得る。プロセッサ32は、ディスプレイまたはインジケータ42上の照明パターン、画像、または色を制御し、M2Mサービス層セッション移行または共有のステータスを反映させるか、またはノードのセッション移行または共有能力もしくは設定についての入力をユーザから得るか、または情報をユーザに表示するように構成され得る。別の実施例では、ディスプレイは、セッション状態に関する情報を示し得る。本開示は、oneM2M実施形態においてRESTfulユーザ/アプリケーションAPIを定義する。ディスプレイ上に示され得るグラフィカルユーザインターフェースは、APIの上部に層化され、ユーザが、本明細書に説明される下層サービス層セッション機能性を介して、E2Eセッションまたはその移行もしくは共有を双方向に確立および管理することを可能にし得る。
【0174】
プロセッサ32は、電源48から電力を受け取り得、M2Mノード30内の他のコンポーネントへの電力を分配および/または制御するように構成され得る。電源48は、M2Mノード30に給電するための任意の好適なデバイスであり得る。例えば、電源48は、1つ以上の乾電池バッテリ(例えば、ニッケルカドミウム(NiCd)、ニッケル亜鉛(NiZn)、ニッケル水素(NiMH)、リチウムイオン(Li−ion)等)、太陽電池、燃料電池等を含み得る。
【0175】
プロセッサ32はまた、M2Mノード30の現在の場所に関する場所情報(例えば、経度および緯度)を提供するように構成され得るGPSチップセット50に連結され得る。M2Mノード30は、実施形態と一致したままで、任意の好適な場所決定方法を介して場所情報を獲得し得ることが理解されるであろう。
【0176】
プロセッサ32はさらに、追加の特徴、機能性、および/または有線もしくは無線接続を提供する1つ以上のソフトウェアならびに/もしくはハードウェアモジュールを含み得る他の周辺機器52に連結され得る。例えば、周辺機器52は、加速度計、e−コンパス、衛星送受信機、センサ、デジタルカメラ(写真またはビデオ用)、ユニバーサルシリアルバス(USB)ポート、振動デバイス、テレビ送受信機、ハンズフリーヘッドセット、Bluetooth(登録商標)モジュール、周波数変調(FM)無線ユニット、デジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザ等を含み得る。
【0177】
図22Dは、M2Mサーバ、ゲートウェイ、デバイス、または他のノード等、M2Mネットワークの1つ以上のノードを実装するためにも使用され得る例示的コンピューティングシステム90のブロック図である。コンピューティングシステム90は、コンピュータまたはサーバを備え得、主に、ソフトウェアの形態であり得るコンピュータ読み取り可能な命令によって制御され得、どこでもまたはどのような手段を用いても、そのようなソフトウェアが記憶またはアクセスされる。コンピューティングシステム90は、発信側AE1802、MQTTサーバ+1812、1822、および2004、CSE1804、1806、および2002、ならびにGUI2102を作成するための論理エンティティ等の論理エンティティを実行すること、または含むことができる。コンピューティングシステム90は、M2Mデバイス、ユーザ機器、ゲートウェイ、UE/GW、または、例えば、モバイルコアネットワーク、サービス層ネットワークアプリケーションプロバイダ、端末デバイス18、もしくはM2Mゲートウェイデバイス14のノードを含む、任意の他のノードであり得る。そのようなコンピュータ読み取り可能な命令は、コンピューティングシステム90を稼働させるように、中央処理装置(CPU)91等のプロセッサ内で実行され得る。多くの既知のワークステーション、サーバ、およびパーソナルコンピュータでは、中央処理装置91は、マイクロプロセッサと呼ばれる単一チップCPUによって実装される。他の機械では、中央処理装置91は、複数のプロセッサを備え得る。コプロセッサ81は、追加の機能を果たすか、またはCPU91を支援する、主要CPU91とは異なる随意的なプロセッサである。CPU91および/またはコプロセッサ81は、セッション証明書の受信またはセッション証明書に基づく認証等、E2E M2Mサービス層セッションのための開示されるシステムおよび方法に関連するデータを受信、生成、および処理し得る。
【0178】
動作時、CPU91は、命令をフェッチ、復号、および実行し、コンピュータの主要データ転送パスであるシステムバス80を介して、情報を他のリソースへ、およびそこから転送する。そのようなシステムバスは、コンピューティングシステム90内のコンポーネントを接続し、データ交換のための媒体を定義する。システムバス80は、典型的には、データを送信するためのデータラインと、アドレスを送信するためのアドレスラインと、割り込みを送信するため、およびシステムバスを動作させるための制御ラインとを含む。そのようなシステムバス80の実施例は、PCI(周辺コンポーネント相互接続)バスである。
【0179】
システムバス80に連結されるメモリは、ランダムアクセスメモリ(RAM)82と、読み取り専用メモリ(ROM)93とを含む。そのようなメモリは、情報が記憶され、読み出されることを可能にする回路を含む。ROM93は、概して、容易に修正されることができない記憶されたデータを含む。RAM82内に記憶されたデータは、CPU91または他のハードウェアデバイスによって読み取られるか、もしくは変更され得る。RAM82および/またはROM93へのアクセスは、メモリコントローラ92によって制御され得る。メモリコントローラ92は、命令が実行されると、仮想アドレスを物理アドレスに変換するアドレス変換機能を提供し得る。メモリコントローラ92はまた、システム内のプロセスを隔離し、ユーザプロセスからシステムプロセスを隔離するメモリ保護機能を提供し得る。したがって、第1のモードで作動するプログラムは、それ自身のプロセス仮想アドレス空間によってマップされるメモリのみにアクセスすることができ、プロセス間のメモリ共有が設定されていない限り、別のプロセスの仮想アドレス空間内のメモリにアクセスすることはできない。
【0180】
加えて、コンピューティングシステム90は、CPU91からプリンタ94、キーボード84、マウス95、およびディスクドライブ85等の周辺機器に命令を伝達する責任がある周辺機器コントローラ83を含み得る。
【0181】
ディスプレイコントローラ96によって制御されるディスプレイ86は、コンピューティングシステム90によって生成される視覚出力を表示するために使用される。そのような視覚出力は、テキスト、グラフィックス、動画グラフィックス、およびビデオを含み得る。ディスプレイ86は、CRTベースのビデオディスプレイ、LCDベースのフラットパネルディスプレイ、ガスプラズマベースのフラットパネルディスプレイ、またはタッチパネルを伴って実装され得る。ディスプレイコントローラ96は、ディスプレイ86に送信されるビデオ信号を生成するために要求される電子コンポーネントを含む。
【0182】
さらに、コンピューティングシステム90は、例えば、
図22Aおよび
図22Bのネットワーク12等の外部通信ネットワークにコンピューティングシステム90を接続するために使用され得るネットワークアダプタ97等の通信回路を含み、コンピューティングシステム90が、ネットワークの他のノードと通信することを可能にし得る。
【0183】
本明細書で説明されるシステム、方法、およびプロセスのうちのいずれかまたは全ては、コンピュータ読み取り可能な記憶媒体上に記憶されたコンピュータ実行可能命令(すなわち、プログラムコード)の形態で具現化され得、その命令は、例えば、M2Mサーバ、ゲートウェイ、デバイス等を含む、M2Mネットワークのノード等の機械によって実行されると、本明細書に説明されるシステム、方法、およびプロセスを行うならびに/もしくは実装することが理解される。具体的には、ゲートウェイ、UE、UE/GW、またはモバイルコアネットワーク、サービス層、もしくはネットワークアプリケーションプロバイダのノードのうちのいずれかの動作を含む、前述の説明されるステップ、動作、または機能のうちのいずれかは、そのようなコンピュータ実行可能命令の形態において実装され得る。発信側AE1802、MQTTサーバ+1812、1822、および2004、CSE1804、1806、および2002、ならびにGUI2102を作成するための論理エンティティ等の論理エンティティは、コンピュータ読み取り可能な記憶媒体上に記憶されているコンピュータ実行可能命令の形態において具現化され得る。コンピュータ読み取り可能な記憶媒体は、情報の記憶のための任意の非一過性(すなわち、有形または物理)方法もしくは技術で実装される、揮発性および不揮発性、取り外し可能なおよび非取り外し可能な媒体の両方を含むが、そのようなコンピュータ読み取り可能な記憶媒体は、信号を含まない。コンピュータ読み取り可能な記憶媒体は、RAM、ROM、EEPROM、フラッシュメモリもしくは他のメモリ技術、CD−ROM、デジタル特定用途ディスク(DVD)もしくは他の光学ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置もしくは他の磁気記憶デバイス、または所望の情報を記憶するために使用され得、コンピュータによってアクセスされ得る任意の他の有形または物理媒体を含むが、それらに限定されない。
【0184】
図に図示されるような本開示の主題の好ましい実施形態を説明する上で、明確にするために、特定の用語が採用される。しかしながら、請求される主題は、そのように選択された特定の用語に限定されることを意図しておらず、各特定の要素は、同様の目的を達成するように同様に動作する全ての技術的均等物を含むことを理解されたい。
【0185】
本明細書は、最良の様態を含む、本発明を開示するために、さらに、当業者が、任意のデバイスまたはシステムを作製して使用することと、任意の組み込まれた方法を行うこととを含む、本発明を実践することを可能にするために、実施例を使用する。本発明の特許性のある範囲は、請求項によって定義され、当業者に想起される他の実施例を含み得る。そのような他の実施例は、請求項の文字通りの言葉とは異ならない要素を有する場合、または請求項の文字通りの言葉とのごくわずかな差異を伴う同等の要素を含む場合、請求項の範囲内であることを意図している。