本明細書では、例えば、サービス層内の要求処理のために使用され得る方法、システム、およびデバイスが開示される。鮮度ベースの処理は、サービス層が、それがホストする記憶されたコンテンツ(例えば、リソース表現)の古さを調査し、規定鮮度要件を伴う読み出しまたは発見要求を満たすために、それが十分に新鮮であるかどうかを決定することを伴い得る。
従来のM2M/IoTサービス層技術は、アプリケーションが、アプリケーションのコンテンツ鮮度要件を考慮する様式で、サービス層によってホストされるコンテンツを発見すること、または読み出すことを効果的に可能にしない。従来のM2M/IoTサービス層技術は、アプリケーションが、要求の鮮度を考慮する様式で、1つのアプリケーションから別のアプリケーションに要求を再標的化することも効果的に可能にしない。これらの欠点は、サービス層技術が、とりわけ、本明細書で議論されるユースケースのタイプを効果的にサポートすることを妨げる。このサポートが無いことは、妥協し、古くなったデータを使用すること、またはさらに悪いことに、それらが選好または要求する新鮮なデータなしで済ませることを決定する必要があるIoTアプリケーションをもたらし得る。このサポートが無いことは、増加した数のコンテンツ読み出し、コンテンツ発見、ならびに他のタイプの要求が開始され、またはデバイスに再標的化される場合、IoTデバイスへのオーバーヘッドの追加をもたらし得る。
従来のM2M/IoTサービス層技術に照らして、より効果的にされ得るか、または可能にされ得る分野のより具体的な例が、以下で議論される。第1の例では、コンテンツソーシングアプリケーション(以降ではコンテンツソーシングアプリ)がポイントオブコンタクト情報をサービス層に提供することを可能にするサポートが無いこともある。ポイントオブコンタクト情報は、サービス層が、コンテンツ要求アプリケーション(以降ではコンテンツ要求アプリ)によって発行され入って来るコンテンツ読み出しまたは発見要求にサービス提供するために選好もしくは要求されるコンテンツの新鮮なバージョンを検出する場合において、コンテンツソーシングアプリにコンタクトする目的のために使用され得る。コンテンツソーシングアプリが、サービス層ホスト型リソースを作成することによってコンテンツを提供するアプリケーションである一方、コンテンツ要求アプリは、コンテンツソーシングアプリによって作成されるサービス層ホスト型リソースを読み出すことによってコンテンツを要求するアプリケーションである。
第2の例では、要求受信アプリケーション(以降では要求受信アプリ)が、要求開始アプリケーション(以降では要求開始アプリ)から生じ、サービス層によって新鮮であると決定される要求を要求受信アプリのポイントオブコンタクトに再標的化するために使用されることができる、ポイントオブコンタクト情報をサービス層に提供することを可能にするサポートが無いこともある。そのような特徴がないと、要求受信アプリおよび要求開始アプリは、単一のエンドツーエンド要求および応答交換を実施するために、複数のサービス層サブスクリプションならびに通知を伴う間接通信方式に依拠し得る。要求受信アプリが、サービス層再標的化要求を介して要求開始アプリから要求を間接的に受信し得る、アプリケーションである一方、要求開始アプリは、サービス層リソースを介して要求を再標的化することを介して、別のアプリケーションへの要求を開始するアプリケーションである。
第3の例では、アプリケーション(すなわち、アプリ)が、サービス層リソースにサブスクライブし、サービス層から、コンテンツ読み出し、コンテンツ発見、または通知要求内に埋め込まれた他のタイプの要求を受信することを可能にするサポートが無いこともある。同様に、アプリが、対応するコンテンツ読み出し、コンテンツ発見、または通知要求内に埋め込まれたサービス層に戻る他のタイプの応答を返すことを可能にするサポートが無いこともある。第4の例では、サービス層が、受信されたコンテンツ読み出し、コンテンツ発見、または他のタイプの要求をサービス提供されるべきアプリに再標的化し、次いで、そのアプリから戻る応答を受信すると、結果のローカルコピーを作成して維持し、将来の要求にサービス提供することを支援し、かつ処理される要求の履歴および追跡情報を維持することを可能にするサポートが無いこともある。第5の例では、サービス層が、要求を再標的化する権限を与えられたエンティティ、再標的化されることを可能にされる要求のタイプ、要求が再標的化されることを可能にされるスケジュールされた時間、および再標的化された要求の中に含まれることを可能にされるリソースの属性等の規則を定義する、所与のリソースのための再標的化ポリシをサポートすることを可能にするサポートが無いこともある。
以下は、とりわけ、より効果的なサービス層要求処理を可能にすること、またはそれを提供することを支援し得る機構である。第1の例示的機構は、サービス層が、コンテンツ要求アプリによって発行され入って来るコンテンツ読み出しまたは発見要求にサービス提供するためにコンテンツの新鮮なバージョンが所望されることを検出した場合において、コンテンツソーシングアプリにコンタクトする目的のために使用されることができるポイントオブコンタクト情報を、コンテンツソーシングアプリがサービス層に提供することを可能にし得る。ポイントオブコンタクトは、とりわけ、絶対URI、相対URI、またはoneM2Mリソース識別子等のいくつかの異なるフォーマットでフォーマットされ得る。第2の例示的機構は、サービス層によってホストされるバージョンが古すぎて、コンテンツ要求アプリによって発行されるコンテンツ読み出しまたは発見要求内で定義される規定鮮度を満たすことができない場合、サービス層がコンテンツ読み出し要求をコンテンツソーシングアプリに送信し、コンテンツの新鮮なバージョンを取得する、プロシージャを含み得る。この要求は、コンテンツを直接読み出し得るか、または、要求は、サービス層がリフレッシュされることを所望するサービス層リソースのアドレスを含み、サービス層がリフレッシュされたコンテンツを要求もしくは選好する優先度またはスケジュールされた時間も含み得る。応答して、コンテンツソーシングアプリは、それがサービス層にコンテンツの新鮮なバージョンを提供し、規定アドレスへの更新を実施し得るときを適切にスケジュールし、優先し得る。
より効果的なサービス層要求処理を可能にすること、またはそれを提供することを支援し得る機構を継続して参照すると、第3の例示的機構は、下層ネットワークデバイストリガ機能によって配信されるサービス層デバイストリガ要求の中に対応する情報要素を埋め込むことによって、サービス層がコンテンツ読み出しまたは他のタイプの要求をアプリに送信することを可能にし得る。第4の例示的機構は、アプリが、サービス層リソースにサブスクライブし、サービス層から、コンテンツ読み出し、コンテンツ発見、または通知要求内に埋め込まれた他のタイプの要求を受信することを可能にし得る。同様に、アプリが、対応するコンテンツ読み出し、コンテンツ発見、または通知応答内に埋め込まれたサービス層に戻る他のタイプの応答を返すことを可能にするサポートがあり得る。第5の例示的機構は、要求受信アプリが、要求開始アプリから生じ、サービス層によって新鮮であると決定される要求を要求受信アプリのポイントオブコンタクトに再標的化するために使用され得る、ポイントオブコンタクト情報をサービス層に提供することを可能にし得る。第6の例示的機構は、サービス層が、受信されたコンテンツ読み出し、コンテンツ発見、または他のタイプの要求をサービス提供されるべきアプリに再標的化し、そして、アプリから戻る応答を受信すると、結果のローカルコピーを作成して維持し、将来の要求にサービス提供することを支援し、かつ処理される要求の履歴および追跡情報を維持することを可能にし得る。
より効果的なサービス層要求処理を可能にすること、またはそれを提供することを支援し得る本明細書に開示される機構を継続して参照すると、第7の例示的機構は、サービス層が、サービス層が入って来る要求を処理すべきアプリに再標的化する(例えば、コンテンツの新鮮なバージョンを取得する)必要があるという検出等の非ブロック様式で入って来る要求にサービス提供するためのトリガ条件として使用することを可能にし得る。非ブロック様式で再標的化される要求にサービス提供するとき、サービス層は、新鮮なコンテンツが利用可能であろう推定時間を含む確認応答を要求側に提供し得る。第8の例示的機構は、サービス層が、要求を再標的化する権限を与えられているエンティティ、再標的化されることを可能にされる要求のタイプ、要求が再標的化されることを可能にされるスケジュールされた時間、および再標的化された要求の中に含まれることを可能にされるリソースの属性等の規則を定義する所与のリソースのためのアプリ再標的化ポリシをサポートすることを可能にし得る。
鮮度ベースのコンテンツ発見、コンテンツ読み出し、および再標的化概念等のより効果的なサービス層要求を可能にすること、またはそれを提供することを支援し得るoneM2M例も本明細書に開示される。加えて、鮮度ベースのコンテンツ発見、コンテンツ読み出し、および再標的化概念等のためのCoREミラーサーバ例が本明細書に開示される。
以下は、サービス層に関連付けられる要求処理のための方法、デバイス、またはシステムに関する追加の洞察を与え得る例示的ユースケースの議論である。図6は、鮮度ベースのコンテンツ読み出しのための例示的ネットワークを図示する。図6に示されるように、医師に関連付けられるアプリ121は、患者の家庭内の患者の健康測定値(例えば、血中インスリン、血圧、脈拍酸素、および心拍数)を遠隔で監視している。これらの測定値は、患者に関連付けられる1つ以上の医療デバイス123によって収集される。医療デバイス123は、患者に装着され得、患者の家庭内のゲートウェイに接続し得、ゲートウェイは、種々の患者ゲートウェイおよびそれらの接続されたデバイスから健康測定値を収集するサービス層122(例えば、クラウドベースの健康サービスプラットフォーム)に接続し得る。アプリ121は、サービス層122にアクセスして医師の患者の健康測定値を読み出す、ウェブベースのアプリケーションであり得る。
ゲートウェイならびにクラウドサービスプラットフォームにおいて、IoTソフトウェアサービスがホストされ得る。これらのサービスは、クエリを行い、特定の患者の健康測定値を発見する能力を提供すること、ネットワークを経由して送信中の患者の健康測定値を保護すること、およびネットワークを横断してより効率的に送信されてスケジュールされ得る単一のメッセージに複数の健康測定値を集約し、ネットワーク負荷、輻輳、ならびに費用を最小化すること等の機能性を提供する。
自分の患者を効果的に監視するために、医師は、クエリを行い、規定鮮度を伴う所与の患者の健康測定値にアクセスする能力を選好し得る(例えば、測定値は、規定期間よりも古くてはならない)。測定のタイプおよび特定の患者に応じて、この鮮度期間は、変動し得る。医師は、従来のシステムを使用するとき、デバイスを伴う患者がたまたま測定し、自分のゲートウェイまたはクラウドにアップロードした健康測定値のみにアクセスすることに限定され得る。従来のシステムを使用するとき、医師の鮮度選好に応じて、これらの測定値のうちのいくつかが医師の必要性のためには古すぎ、医師が、取り込まれてアップロードされる次のスケジュールされたセンサ測定を待つ以外の選択肢を有していないこともある可能性がある。これが起こる時間まで、他の患者センサからの他の測定データは、古くなり、全体としての患者データの分析を困難または信頼できないものにし得る。
より良好な介護の質を患者に提供するとともに、自分自身が自分自身の時間をより良好に管理することを可能にするために、医師が選好するであろうことは、このユースケースでは、新しい測定値がアップロードされることを待つ必要なく、自分の鮮度選好を満たす健康測定値へのアクセスを有することである。特定の患者デバイス123、またはゲートウェイ、もしくは両方をトリガし、医師の規定鮮度選好を満たす新鮮な健康測定値が、医師のアプリケーション121がアクセスするためにクラウド内でまだ利用可能ではないとき、それをサービス層122に提供する強化IoTサービスをサポートする機構が、本明細書でさらに議論される。このタイプの機能性を有することは、医師が、拡張可能性、利用可能性、費用等のサービス層122で健康測定値をホストすることの多くの利益を依然として同時に活用しながら、自分の患者の健康測定値への新鮮なオンデマンドアクセスを効果的に有することを可能にする。サービス層122内の既存の測定値が特定の要求の鮮度基準をまだ満たさないとき、新鮮な測定値を提供するようにデバイスまたはゲートウェイをトリガすることによって、ネットワークを経由して送信される必要がある要求の数の節約、ゲートウェイまたはデバイスへのオーバーヘッドの削減をもたらし得る。対照的に、各要求のために測定値を提供する従来のデバイス(例えば、エンドデバイスまたはゲートウェイデバイス)のトリガは、ネットワークを経由してより多くの要求が送信され、デバイへのオーバーヘッドが追加されることをもたらし得る。このオーバーヘッドを最小化することは、本質的にリソース制約もされ得る潜在的に多数のデバイスを伴うIoTタイプ展開において重要であり得る。IoTサービストリガは、新鮮な読み取り値がクラウド内で利用可能ではない場合を検出し、ひいては、後続の要求を用いてデバイスを標的化し、新鮮な読み取り値を読み出すための負担をアプリケーション(例えば、アプリ121)に課さないことによって、あるレベルの効率および最適化を可能にする。
図7は、例示的鮮度ベースのコンテンツ読み出しタイムラインを図示する。図7は、この鮮度ベースのコンテンツ読み出し方式の潜在的節約をより詳細に強調表示する例を提供する。この例では、医療センサデバイス131は、一番上の線に沿って示されるように、3時間毎に1回、センサ読み取り値をパブリッシュする。示されるような丸は、医療センサデバイス131のパブリッシュされたセンサ読み取り値を示す。これらのセンサ読み取り値は、次いで、異なるアプリ(アプリ132、アプリ133、アプリ134)によって読み出される。アプリ132および133は、わずかに異なるオフセットを伴って1時間に1回、センサ読み取り値を周期的に読み出し、センサ読み取り値が30分よりも古くあることができないという鮮度選好を有する。図7の三角は、クラウドにキャッシュされた新鮮なバージョンがないので、医療センサデバイス131自体からセンサ読み取り値を読み出すことを要求する動作を示す。図7の四角は、医療センサデバイス131からセンサ読み取り値を読み出すことを要求しない動作を示すが、代わりに、十分に新鮮であるキャッシュされたセンサ読み取り値が、クラウドから取得され得る。アプリ134は、センサ読み取り値を散発的に読み出し得、センサ読み取り値が10分よりも古くあることができないという鮮度選好を有する。例は、センサ自体へのアクセスを要求するもの(前述の正方形)と対比して、クラウドでホストされるセンサ読み取り値(前述の三角)によってサービス提供され得る、読み出し要求を強調表示する。この例から、26個のうちの17個の読み取り値が、クラウドでホストされるキャッシュされたセンサ読み取り値によってサービス提供され得、26個のうちの9個は、クラウド内のキャッシュされたバージョンが入って来る要求にサービス提供するために十分に新鮮ではないので、アクセスされているセンサによってサービス提供される。これは、ありとあらゆる読み取り値についてセンサに直接アクセスすることに対する鮮度ベースの読み出しの利益を例証する。鮮度ベースの読み出しがないと、この例における要求のうちのいくつかは、入って来る要求の要件を満たした新鮮なセンサ読み取り値が無いことに起因して、サービス(すなわち、クラウド)によって拒否されたであろう。故に、鮮度ベースの読み出しは、それらが選好する新鮮なセンサ読み取り値をアプリに同時に提供しながら、センサおよびネットワークへのオーバーヘッドを削減し得る。
図8は、鮮度ベースの要求再標的化のための例示的ネットワークを図示する。図8に示されるように、制御アプリ141は、サービス層142と通信可能に接続される。サービス層142は、ビル内ネットワーク143と通信可能に接続される。ビル内ネットワーク143は、とりわけ、電子ドア、電子サーモスタット、センサ等のいくつかの異なるデバイスに接続されるゲートウェイ146を有し得る。制御アプリ141は、ビル内ネットワーク143内のデバイスを遠隔で制御する(例えば、明かりを点灯および消灯する、サーモスタットを制御する、ならびにドアを施錠および開錠する)ために使用され得る。サービス層142は、ビル内ネットワーク143のデバイスの遠隔管理および制御を可能にするクラウドベースのビル管理システムであり得る。ゲートウェイ146ならびにサービス層142は、先進IoTソフトウェアサービスをホストし得る。これらのサービスは、クエリを行い、特定のデバイスを発見する能力を提供すること、ネットワークを経由して送信中である間にコマンド(例えば、ドア施錠および開錠コマンド)を保護すること、またはIoTソフトウェアサービスが処理する要求を介して特定のデバイスに発行されるコマンドの意味認識および意味等の機能性を提供し得る。制御アプリ141(例えば、ウェブベースの制御アプリ)を使用して、ビル内ネットワーク143内のデバイスは、アクセスおよび制御され得る。例えば、ビル内ネットワーク143に関連付けられるドアは、制御アプリ141から、サービス層142を通して、ビル内ネットワーク143のゲートウェイまで、最終的には、ドアロックアクチュエータデバイス自体(図示せず)までコマンドを開始することによって、遠隔で施錠および開錠され得る。
図8を継続して参照すると、ネットワークならびにゲートウェイおよびデバイスへのオーバーヘッドを最小化するために、要求がデバイスの意味状態の変化をもたらす(例えば、開錠されたドアを施錠する、または施錠されたドアを開錠する)であろう場合にのみ、制御アプリ141からビル内ネットワーク143のゲートウェイおよびデバイスまで開始される要求を送信することが望ましくあり得る。意味認識能力を有し、入って来るコマンドタイプ要求を処理し、コンテンツ意味論の視点から、それらがデバイスの状態の変化をもたらすであろうように、新鮮である要求を検出することができ、これらのコマンドのみをビル内ネットワーク143のゲートウェイおよびデバイスまで転送する、サービス層142内の強化IoTサービスをサポートすることが望ましくあり得る。本質的に古く、ビル内ネットワーク143のデバイスの状態の変化をもたらすことが予想されない要求は、サービス層142内のIoTサービスによってフィルタ処理され得、ビル内ネットワーク143のゲートウェイおよびデバイスに送信されない。このオーバーヘッドを最小化することは、本質的にリソース制約でもあり得る潜在的に多数のデバイスを伴うIoTタイプ展開で重要であり得る。IoTサービスにおける記憶された状態が、ビル内ネットワーク143の実際のデバイスの状態と同期しなくなる(例えば、ドアが施錠されているが、IoTサービスは、それが開錠されていると言う)場合に対して、次いで、この提案される鮮度ベースのフィルタリング機能性をオーバーライドする機構を有することが可能であることに留意されたい。例えば、サービス層142がドアを開錠するように5つの連続要求を受信した場合、たとえサービス層内の記憶された状態が、コマンドが新鮮ではないことを示したとしても、サービス層142は、要求をデバイスに転送し得る。これは、例えば、サービス層142への特定のタイプの要求の数、特定の要求以降の期間、オーバーライドメッセージ、または前述の組み合わせに基づいて、トリガされ得る。
図9は、例示的鮮度ベースの要求再標的化メッセージフローを図示する。図9は、この鮮度ベースの要求再標的化方式の潜在的節約をより詳細に強調表示する例を提供する。ステップ149では、ビル内ネットワーク143と通信可能に接続されるドアは、施錠状態にある。ローカル要求が、ビル内ネットワーク143のドアを施錠状態にしていることもある。ステップ150では、メッセージが、ビル内ネットワーク143から送信され、ビル内ネットワーク143内のドアの施錠状態を示す。換言すると、ドアロックの状態が、サービス層142(例えば、クラウド)にパブリッシュされ、ドアロックの状態とサービス層142との間の同期化を保つ。ステップ151では、制御アプリ141は、ビル内ネットワーク143のドアを開錠する要求をサービス層142に送信する。ステップ151の要求は、ゲートウェイおよびドアロックに再標的化され、ドアを開錠する。これは、施錠されているドアを開錠するように要求しているので、(ステップ152で)要求が新鮮と見なされるので行われる。ステップ153では、ビル内ネットワーク143のドアは、ステップ151の要求に基づいて施錠される。ステップ154では、メッセージが、サービス層142に送信され、ドアが施錠されていることを示し、ステップ155でサービス層142において保存される。ステップ154では、制御アプリ141は、ステップ151で要求されるようにドアが施錠されているという確認を受信し得る。ステップ155およびステップ157では、制御アプリ144ならびに制御アプリ145は、それぞれ、ビル内ネットワーク143のドアが施錠されることを要求する。ステップ156およびステップ158では、制御アプリ144ならびに制御アプリ145は、それぞれ、すでに開錠されているドアを開錠しようとしているので、ステップ155およびステップ157における要求が古いことを示す応答を受信する。この場合、ドアロックの状態を維持するサービス層142は、これらの要求をフィルタ処理し、それらをビル内ネットワーク143のゲートウェイまたはドアロックに転送しない。ステップ159では、制御アプリ141は、ビル内ネットワーク143のドアを施錠する要求を送信する。ステップ159の要求は、ゲートウェイおよびドアロックに再標的化され、(ステップ160で)要求が新鮮と見なされるので、開錠されたドアを施錠する。ステップ161では、ドアは、施錠され、応答は、(ステップ162で)サービス層142に送信され、サービス層142において保存され、制御アプリ141に転送される。鮮度ベースの標的化は、ビル内ネットワーク143のデバイスと直接通信し、要求をビル内ネットワーク143自体のデバイスまで送信した場合と同一の機能性を制御アプリ141、制御アプリ144、および制御アプリ145に同時に提供しながら、デバイスおよびネットワークへのオーバーヘッドを削減し得る。
図9−図12および図14−図18等の本明細書に図示されるステップを行うエンティティは、論理エンティティであり得ることが理解される。ステップは、図21Cまたは図21Dに図示されるもの等のデバイス、サーバ、もしくはコンピュータシステムのメモリの中に記憶され、そのプロセッサ上で実行し得る。例では、M2Mデバイスの相互作用に関して以下にさらなる詳細を伴うが、図10のコンテンツソーシングアプリ202またはコンテンツ要求アプリが、図21AのM2M端末デバイス18上に常駐し得る一方、図10のサービス層204は、図21AのM2Mゲートウェイデバイス14またはM2Mサービスプラットフォーム22上に常駐し得る。
図10は、例示的鮮度ベースのコンテンツ読み出しメッセージフローを図示する。方法は、サービス層204がそのようなコンテンツをホストしない場合でさえも、コンテンツ要求アプリ206が、コンテンツ要求アプリ206の規定鮮度選好を満たすコンテンツをサービス層204から読み出すことを可能にする。図10のメッセージフローは、オンザフライ機構が、要求されたコンテンツが古いとき、または存在しないときをサービス層204が検出することを可能にし、新鮮なバージョンのために対応するコンテンツソーシングアプリ202にコンタクトすることを可能にする。ステップ210では、コンテンツソーシングアプリ202およびコンテンツ要求アプリ206は、認証し、サービス層204に登録する。コンテンツ要求アプリ206は、次いで、利用可能なコンテンツソーシングアプリ202を発見する。
図10を継続して参照すると、ステップ211では、コンテンツソーシングアプリ202は、ポイントオブコンタクト情報(例えば、URI)をサービス層204にパブリッシュする。コンテンツソーシングアプリ202は、1つ以上のポイントオブコンタクトでサービス層204を構成し得る。コンテンツソーシングアプリ202は、個々のポイントオブコンタクトを、サービス層204によってホストされる1つ以上のリソースに関連付け得る。例えば、サービス層204は、コンテンツソーシングアプリ202が、コンテンツソーシングアプリ202がセンサ読み取り値等の特定のタイプのコンテンツを周期的にパブリッシュするサービス層204のリソース内に(例えば、大気質読み取り値がパブリッシュされるコンテナリソースに)ポイントオブコンタクト属性を構成することを可能にし得る。ステップ212では、ステップ211のポイントオブコンタクト情報は、サービス層204上に記憶される。ポイントオブコンタクト情報は、異なるシナリオ下でコンテンツソーシングアプリ202にコンタクトするために、サービス層204によって使用され得る。例えば、サービス層204は、コンテンツソーシングアプリ202にコンタクトして、コンテンツ要求アプリ206から要求を受信するサービス層204等のシナリオのための新鮮なコンテンツインスタンス(例えば、センサ読み取り値)を取得し、サービス層204が現在、ローカルにホストされたバージョンを有していない、または全てのバージョンが古すぎて、コンテンツ要求アプリ206の鮮度選好を満たすことができないセンサ読み取り値を読み出し得る。そのようなシナリオに対して、サービス層204は、コンテンツソーシングアプリ212によって提供されるポイントオブコンタクト情報を使用し、それに要求を送信し、新鮮なコンテンツを取得し得る。ステップ213では、サービス層204は、ステップ211のメッセージの受信を確認するための応答をコンテンツソーシングアプリ202に送信し得る。
ステップ214では、コンテンツソーシングアプリ202は、1つ以上のコンテンツインスタンスを、標的アドレス(例えば、URI)によって規定されるサービス層204リソースにパブリッシュする。各受信されたコンテンツインスタンスは、サービス層204によって記憶され(例えば、ステップ215)、応答を介して確認され得る(例えば、ステップ216)。コンテンツソーシングアプリ202は、コンテンツインスタンス(例えば、コンテンツ=センサ読み取り値)がコンテンツソーシングアプリ202によって生成または捕捉されたときのタイムスタンプ(例えば、タイムスタンプ=20160104T104017)も提供し得る。サービス層204は、コンテンツがコンテンツソーシングアプリ202によって生成された時間と対比して、コンテンツインスタンスがサービス層204の中に記憶された時間を示すタイムスタンプもコンテンツインスタンスに割り当て得る。両方のタイムスタンプは、異なるタイムスタンプに基づいてコンテンツを検索するコンテンツ要求アプリ206に価値があり得る。
ステップ217では、コンテンツ要求アプリ206は、コンテンツソーシングアプリ202に関連付けられる特定のタイプのコンテンツをフェッチするための要求をサービス層204に発行し得る。コンテンツ要求アプリ206は、標的アドレス(例えば、URI)によってコンテンツソーシングアプリ202を規定し得る。要求の中に、コンテンツ要求アプリ206が、規定時間および日付以後のコンテンツを選好する(または要求する)ことを規定するために使用する時間および日付情報で構成される規定鮮度時間パラメータ(例えば、20160103T112032)が含まれ得る。
ステップ218では、サービス層204は、サービス層204によってホストされ、ステップ217の要求の中で規定される標的アドレスを介してアクセス可能である各適用可能コンテンツインスタンスのタイムスタンプに対して、ステップ217の要求の鮮度時間パラメータ内の規定時間および日付情報を比較する。この比較から、サービス層204は、サービス層204によってホストされる適用可能なコンテンツインスタンスのうちのいずれかが、規定鮮度時間パラメータよりも新しいタイムスタンプを有するかどうかを決定する。何も見出されない場合、サービス層204は、この要求を満たすために、新鮮なコンテンツインスタンスが対応するコンテンツソーシングアプリ202から選好または要求されることをシグナリングするイベントを生成し得る。このイベントは、ひいては、ブロック221のステップで概説されるプロシージャによって定義されるように、コンテンツソーシングアプリ206から新鮮なコンテンツインスタンスを取得しようとするトリガとして、サービス層204によって使用され得る。トリガの生成は、適用可能なポイントオブコンタクトがコンテンツソーシングアプリ202のために構成されているかどうかに基づいて制限されることができる。いかなるポイントオブコンタクトも構成されていない場合、トリガは抑制され得る。
(ブロック220の中の)ステップ219では、サービス層204が規定鮮度時間パラメータよりも新しい(すなわち、許容閾値期間内の)タイムスタンプを伴うコンテンツインスタンスを見出す場合、コンテンツインスタンスを含む応答をコンテンツ要求アプリ206に返し得る。この場合、サービス層204は、そのローカルに記憶されたコンテンツをリフレッシュすることを始める必要がない。要求されたコンテンツがそれほど古くないが、間もなく古くなるであろう場合に対して、サービス層204は依然として、ブロック221内のステップを行うことを選定し、新鮮なコンテンツインスタンスを取得し得ることを留意されたい。「それほど古くない」は、多くの要因に基づき得る。このインスタンスにおいてブロック221のステップを続けるべきかどうかは、過去の応答(例えば、前の期間における「それほど古くない」応答の有無、連続応答等)に基づいて決定され得る。要求されたコンテンツが最近古くなった場合に対しても、サービス層204は依然として、コンテンツソーシングアプリ202が利用可能ではないか、または利用可能なコンテンツの新鮮なバージョンを有していない場合、そのコンテンツをコンテンツ要求アプリ206に返すことを選定し得る。この場合、サービス層204は、コンテンツが規定鮮度選好を満たさなかったが、利用可能な唯一のコンテンツであったという指示をコンテンツ要求アプリ206に提供し得る。
図10のブロック221の中のステップに対して、サービス層204が規定鮮度時間パラメータよりも新しいタイムスタンプを伴うコンテンツインスタンスを見出さない場合、サービス層204は、コンテンツ要求アプリ206がブロックして待機することを要求されないように、確認応答をコンテンツ要求アプリ206に返し得る一方、サービス層204は、コンテンツソーシングアプリ202から新鮮なコンテンツインスタンスを取得しようとする(ステップ222)。ステップ222のこの確認応答メッセージは、要求が受信されたが、サービス層204がコンテンツ要求アプリ206の鮮度選好を満たしたローカルにホストされたコンテンツインスタンスを有していなかったので、依然として処理されていることを示すステータスを含み得る。ステップ222の確認応答メッセージは、読み出し、またはサブスクライブし、利用可能になるときに新鮮なコンテンツインスタンスを受信するためにコンテンツ要求アプリ206によって使用され得るサービス層コールバックアドレス(例えば、URI)も含み得る。この確認応答は、サービス層204が準備ができたコンテンツの新鮮なバージョンを有することを予期するときに関する推定時間または遅延も含み得る(例えば、サービス層204は、所与のコンテンツソーシングアプリ202から新鮮なコンテンツを取得することの過去の履歴に基づいて、期待時間または遅延を計算することが可能であり得る)。例えば、コンテンツ要求アプリ206は、このアドレスに周期的にポーリングまたはサブスクライブし、サービス層204がコンテンツソーシングアプリ202から新鮮なセンサ読み取り値を取得することができるときには新鮮なセンサ読み取り値を受信し得るか、またはサービス層204がコンテンツソーシングアプリ202から新鮮なセンサ読み取り値を取得することに失敗した場合にはエラー状態を受信し得る。確認応答は、随意に、新鮮なコンテンツを待っている間にコンテンツ要求アプリ206にある程度価値があり得るように、コンテンツの古いバージョンも含み得る。コンテンツ要求アプリ206が将来における鮮度時間を規定する場合に対して、サービス層204は、非ブロック様式でこの要求を処理し得る。サービス層204は、規定鮮度時間が経過するまで待機し、次いで、要求にサービス提供するコンテンツをホストしているかどうかをチェックし得る。ホストしている場合、サービス層204は、コンテンツでコンテンツ要求アプリ206に応答し得る。ホストしていない場合、それは、ステップ223および225−232を実施し得る。代替として、サービス層204は、ブロック様式で要求を処理することを選定し得、その場合、このステップでは、確認応答をコンテンツ要求アプリ206に返さないであろう。代わりに、サービス層204は、図10のステップ232まで、コンテンツ要求アプリ206に応答することを控えるであろう。要求がブロック様式で処理されるか、非ブロック様式で処理されるかをサービス層204が決定することを可能にするトリガは、サービス層が要求を処理するために十分に新鮮なデータを有するかどうかに基づき得る。そうではなく、コンテンツソーシングアプリ202への要求を開始する場合において、サービス層204は、非ブロック様式で要求を処理することを選定し得る。そうでなければ、サービス層204は、ブロック様式で要求を処理することを選定し得る。代替として、ステップ124に示されるように、コンテンツ要求アプリ124は、サービス層204がブロックを使用するか、非ブロックを使用するかを要求の中で明示的に規定し得る。
図10を継続して参照すると、ステップ123では、サービス層204が新鮮なコンテンツインスタンスを取得しようとしているとき、コンテンツソーシングアプリ202がサービス層204の要求を介して到達可能ではない場合、サービス層204は、新鮮なコンテンツインスタンスを取得し得るように、コンテンツソーシングアプリ202にサービス層204への接続性を再確立させるためのデバイストリガ動作を開始し得る。サービス層204がこの到達可能性決定を行う方法の詳細は、その全体として参照することによって組み込まれるoneM2M−TS−0001 oneM2M Functional Architecture−V2.6.0によって定義されるように、いつサービス層204に到達可能であるかどうかを示すようにデバイスが更新する、コンテンツソーシングアプリ202のための到達可能性状態情報をサービス層204がサポートすること等のいくつかの異なる方法で行われ得る。サービス層204は、コンテンツ読み出しアプリ206がサービス層204によってサポートされる鮮度サービスを使用する権限を与えられているかどうか等のポリシに基づいて、所与の要求のための鮮度ベースのコンテンツ読み出しを行うかどうかを調整し得る。
図10のステップ225では、コンテンツソーシングアプリ202が到達可能ではない場合、サービス層204は、それがサービス層204から要求を受信し得るように、コンテンツソーシングアプリ202がサービス層204へのその接続を再確立することを開始するためのデバイストリガ要求を生成し得る。サービス層204がデバイストリガをコンテンツソーシングアプリ202に配信する方法の詳細は、複数の方法で生じ得、例えば、1つのそのような配信方法は、3GPP SMSベースのトリガ等の下層ネットワークトリガ機能性を利用することであり得る。トリガ要求ペイロードの一部として、サービス層204は、追加の情報を埋め込み、このトリガの理由が、新しいコンテンツ(例えば、センサ読み取り値)を用いてサービス層204をリフレッシュすることであることをコンテンツソーシングアプリ202に示し得る。この追加の情報は、以下のうちの1つ以上のものを含み得る:トリガタイプパラメータ(例えば、「Content Requested」);リフレッシュすることが選好される(もしくは要求される)特定のコンテンツを示すサービス層コンテンツ識別子またはアドレスパラメータ;サービス層204が要求されたコンテンツを所望する、または別様に必要とする緊急性を示す優先度パラメータ;コンテンツソーシングアプリ202がコンテンツインスタンスのバッファリングをサポートする場合、コンテンツが規定日時より古くあってはならないことを示す鮮度時間パラメータ、または、サービス層204が、コンテンツソーシングアプリ202がコンテンツの新鮮なバージョンを有するそれを提供することを選好するときの日時を示すスケジュールパラメータ。優先度パラメータに対して、サービス層204は、入って来る要求の規定優先度、コンテンツ要求アプリ206のサブスクリプションまたはアカウントと連携する優先度、(例えば、規定鮮度時間を過ぎた時間に対する)コンテンツの古さまたは陳腐化、または、コンテンツにおける人気、レベル、またはそれへの関心(例えば、異なるコンテンツ要求アプリの数およびコンテンツへの要求の頻度パターン)に基づいて、優先度を導出し得る。スケジュールパラメータに対して、サービス層204は、現在の要求の規定鮮度時間に基づいて、スケジュールを導出し得るか(例えば、要求の中の鮮度時間が将来の時間で規定された)、または代替として、導出されたスケジュールは、コンテンツに対する要求の過去の履歴に基づき得る(例えば、過去の要求のパターンを検出し、このパターンを使用して将来の要求のための推定スケジュールを導出する)。ステップ124のメッセージは、以下の情報、すなわち、(type=ContentRequest、addr=URI、priority=high、freshness−time=20160103T112032、schedule=20160103T112132)を含み得る。
ステップ226では、デバイストリガ要求を受信すると、コンテンツソーシングアプリ202は、処理し、規定トリガタイプパラメータを分析することによって、それがコンテンツに対する要求であることを検出し得る。コンテンツソーシングアプリ202が1つ以上のタイプのコンテンツをサポートする場合、コンテンツ識別子またはアドレスパラメータをチェックし、サービス層204によって要求されているコンテンツのタイプを検出し得る。コンテンツソーシングアプリ202は、次いで、優先度またはスケジュールパラメータをチェックし、サービス層204に新鮮なコンテンツを提供しなければならないときを決定し得る。コンテンツソーシングアプリ202は、鮮度時間パラメータをチェックし、規定されるコンテンツの好ましい鮮度日付または時間があるかどうかを確認し得る。1つが規定される場合、コンテンツソーシングアプリ202は、それが提供する任意のコンテンツインスタンスが、この日時の前に生成されなかったことを検証し得る。
図10のステップ227では、サービス層204によって開始されるデバイストリガ要求に応答して、コンテンツソーシングアプリ202は、サービス層204へのその接続を再確立し、その到達可能性状態を更新し、それが現在到達可能であり、サービス層204によって開始される要求を受信することができることをサービス層204に通知し得る。コンテンツソーシングアプリ202は、利用可能である場合、デバイストリガ応答の中にコンテンツの新鮮なバージョン(例えば、センサ読み取り値)、または代替として、新鮮なバージョンが現時点では利用可能ではないことを示すステータスを含み得る。そうすることで、これは、別個の要求を節約することによって、全体的なプロシージャを最適化し得る。代替として、コンテンツソーシングアプリ202は、(デバイストリガ要求および応答に続いて)サービス層204への別個の要求を開始し、利用可能である場合、新鮮なコンテンツ、または代替として、コンテンツの新鮮なバージョンが現時点では利用可能ではないことを示すステータスで、サービス層204を更新し得る。コンテンツソーシングアプリ202は、この新しい要求の標的として、デバイストリガ要求に埋め込まれたアドレス情報を使用し得る。ステップ227のメッセージは、以下の情報、すなわち、(to=URI、content=sensor reading、timestamp=20160105T091434)を含み得る。
図10を継続して参照すると、ステップ228では、コンテンツソーシングアプリ202が到達可能であり、サービス層204が別の機構(本明細書に説明されるデバイストリガベースの機構等)によってコンテンツソーシングアプリ202から新鮮なコンテンツインスタンスを受信していない場合、サービス層204は、代替として、新鮮なコンテンツインスタンスを明示的に要求する、コンテンツソーシングアプリ202への別個の要求をそれ自身で開始し得る。この要求は、いくつかの異なるタイプの要求のうちの1つを使用して、コンテンツソーシングアプリ202に配信され得る。サービス層204は、ステップ211からステップ213でコンテンツソーシングアプリ202によって規定されるポイントオブコンタクトを標的化する読み出し要求を開始し得る。代替として、サービス層204は、事前サブスクリプション要求の中で構成される通知アドレスを標的化するコンテンツソーシングアプリ202への通知要求、またはステップ211からステップ213で規定されるポイントオブコンタクトへの通知要求を開始し得る。この通知内に、サービス層204は、本明細書で議論されるトリガ要求(例えば、ステップ225からステップ227)の中で定義されるような類似タイプの情報を含み得る。ステップ228の通知は、以下のうちの1つ以上のものを含み得る:この通知(例えば、コンテンツリフレッシュ要求)の理由(例えば、トリガイベント);リフレッシュすることが選好される特定のコンテンツを示すサービス層コンテンツ識別子またはアドレスパラメータ;サービス層204が要求されたコンテンツを所望する、または別様に必要とする緊急性を示す優先度パラメータ;コンテンツソーシングアプリ202がコンテンツインスタンスのバッファリングをサポートする場合において、規定絶対日付および時間、またはコンテンツが作成された以降の相対時間以後にコンテンツが作成されていなければならないことを示す鮮度時間パラメータ;または、サービス層204が、コンテンツソーシングアプリ202がそれにコンテンツの新鮮なバージョンを提供することを選好するときの日付および時間を示すスケジュールパラメータ。優先度パラメータに対して、サービス層204は、入って来る要求の規定優先度、コンテンツ要求アプリ206のサブスクリプションまたはアカウントと連携する優先度、コンテンツの古さまたは陳腐化(例えば、規定鮮度時間を過ぎた時間)、または、コンテンツにおける人気もしくはレベルまたはそれへの関心(例えば、異なるコンテンツ要求アプリの数およびコンテンツへの要求の頻度パターン)に基づいて、優先度を導出し得る。スケジュールパラメータに対して、サービス層204は、現在の要求の規定鮮度時間に基づいて、スケジュールを導出し得る(例えば、要求の中の鮮度時間が将来の時間で規定された)、または代替として、導出されたスケジュールは、コンテンツに対する要求の過去の履歴に基づき得る(例えば、過去の要求のパターンを検出し、このパターンを使用して将来の要求のための推定スケジュールを導出する)。ステップ228のメッセージは、以下の情報、すなわち、(type=ContentRefresh、addr=URI、priority=high、freshness−time=20160103T112032、schedule=20160103T112132)を含み得る。
図10のステップ229では、サービス層204からステップ228の要求を受信すると、コンテンツソーシングアプリ202は、要求のタイプ(例えば、読み出しまたは通知)を処理して検出し得る。要求が読み出しである場合、コンテンツソーシングアプリ202は、要求の中の規定アドレスを分析し、要求されているコンテンツを決定し、ひいては、利用可能である場合、それがサービス層204に応答を返すことを所望するコンテンツインスタンス、または代替として、新鮮なバージョンが現時点では利用可能ではないことを示すステータスを準備し得る。要求が通知である場合、コンテンツソーシングアプリ202は、規定通知タイプパラメータを分析することによって、それがコンテンツに対する要求であることを検出し得る。コンテンツソーシングアプリ202が2つ以上のタイプのコンテンツをサポートする場合、コンテンツ識別子またはアドレスパラメータをチェックし、サービス層204によって要求されているコンテンツのタイプを検出し得る。それは、次いで、優先度またはスケジュールパラメータをチェックし、サービス層204に新鮮なコンテンツを提供しなければならないときを決定し得る。それは、鮮度時間パラメータもチェックし、規定されるコンテンツの要求される鮮度日付または時間があるかどうかを確認し得る。1つが規定される場合、コンテンツソーシングアプリ202は、それが提供する任意のコンテンツインスタンスが、この日付および時間の前に生成されなかったことを検証し得る。
ステップ230では、コンテンツソーシングアプリ202は、いくつかの方法のうちの1つにおいて、新鮮なコンテンツインスタンスで、または、新鮮なコンテンツインスタンスが現時点では利用可能ではないことを示すステータスでサービス層204を更新し得る。サービス層204が、新鮮なコンテンツインスタンスを要求する明示的読み出し要求をコンテンツソーシングアプリ202に発行する場合、コンテンツソーシングアプリ202は、読み出し応答の中に新鮮なコンテンツインスタンスを含み得る。サービス層204が、新鮮なコンテンツインスタンスが所望されること、または別様に必要とされることを示す通知をコンテンツソーシングアプリ202に発行する場合、コンテンツソーシングアプリ202は、通知応答の中に新鮮なコンテンツインスタンスを含み得るか、または代替として、コンテンツソーシングアプリ202は、サービス層204内で新鮮なコンテンツインスタンスを作成するための別個の要求(例えば、作成要求)を継続することができる。ステップ230のメッセージは、以下の情報、すなわち、(to=URI、content=sensor reading、timestamp=20160105T091434)を含み得る。
図10を継続して参照すると、ステップ231では、新鮮なコンテンツインスタンスがサービス層204に正常にパブリッシュされた場合、サービス層204は、新鮮なコンテンツインスタンスのローカルバージョンが、将来の要求にサービス提供するために活用され得るか、または課金および分析等の目的のために使用され得るように、それを記憶し得る。サービス層204は、随意に、対応するタイムスタンプを割り当て、コンテンツインスタンスがサービス層204にパブリッシュされたときも記録し得る。ステップ232では、新鮮なコンテンツインスタンスがサービス層204に正常にパブリッシュされた場合、それは、コンテンツ要求アプリ206に返され、そうでなければ、新鮮なコンテンツが利用可能ではない場合、サービス層204は、エラーを返し得るか、または代替として、サービス層204は、その陳腐化の指示(例えば、それが作成された時間)とともに、コンテンツの(古いが)直近のバージョンを返し得る(これが依然としてある程度有用であり得るので)。
図11は、例示的鮮度ベースのリソース発見メッセージフローを図示する。コンテンツ要求アプリ206は、サービス層204がそのようなコンテンツをホストしない場合でさえも、コンテンツ要求アプリ206の鮮度選好を満たすコンテンツをサービス層204から発見する。プロシージャは、サービス層204が、コンテンツが古い、またはサービス層204の中に存在しないときを検出することを可能にする、オンザフライ機構を定義する。これが起こるとき、サービス層204は、次に、対応するコンテンツソーシングアプリ202にコンタクトし、それに、サービス層204がコンテンツ要求アプリ206に返す発見応答の中にこのコンテンツの参照を含み得るように、コンテンツをリフレッシュさせ得る。
図11のブロック241の中のステップは、図10のステップ210からステップ216と同一に機能する。図11のステップ242では、コンテンツ要求アプリ106は、コンテンツソーシングアプリ202に関連付けられる特定のタイプのコンテンツを発見するための要求をサービス層204に発行する。要求の中に、コンテンツ要求アプリ206が、規定時間および日付以後のコンテンツを発見することを所望することを規定するために使用する時間および日付情報で構成される規定鮮度時間パラメータが含まれる。ステップ242の要求は、他の発見フィルタ基準(例えば、コンテンツのタイプ)も含み得る。
ステップ243では、サービス層204は、サービス層204によってホストされる各適用可能コンテンツインスタンスのタイムスタンプに対して、ステップ242のコンテンツ発見要求の鮮度時間パラメータ内の規定時間および日付情報を比較する。この比較から、サービス層204は、サービス層204によってホストされる適用可能なコンテンツインスタンスのうちのいずれかが、規定鮮度時間パラメータよりも新しい(すなわち、許容閾値期間内の)タイムスタンプを有するかどうかを決定する。何も見出されない場合、サービス層204は、新鮮なコンテンツインスタンスが対応するコンテンツソーシングアプリ202から選好されることをシグナリングするイベントを生成し得、サービス層204は、コンテンツ要求アプリ206に送信する発見応答の中に、このコンテンツの参照(例えば、URI)と、コンテンツ要求アプリ206がコンテンツにアクセスする後続の要求を送信するとき、サービス層204が準備完了して利用可能であるコンテンツを有していることとを含み得る。このイベントは、図10のブロック221のフローおよび対応する説明で概説されるように、コンテンツソーシングアプリ202から新鮮なコンテンツインスタンスを取得することを試みるためのトリガとして、サービス層204によって使用され得る。トリガの生成は、適用可能なポイントオブコンタクトがコンテンツソーシングアプリ202のために構成されているかどうかに基づいて制限され得る。いかなるポイントオブコンタクトも構成されていない場合、トリガは、抑制され得る。サービス層204は、ステップ242によって要求され、ステップ243で処理されるように、この鮮度ベースの発見特徴を利用することを可能にされる、コンテンツ要求アプリ206を制限するアクセス制御ポリシをサポートし得る。コンテンツ要求アプリ206が所与の標的コンテンツインスタンスのために定義される鮮度ベースの発見のための特権を有するかどうかは、サービス層204が、続いて、コンテンツソーシングアプリ202への鮮度ベースの読み出し要求を開始するかどうかを制限するために使用され得る。
ブロック245のステップ244では、サービス層204が、規定鮮度時間パラメータよりも新しい(すなわち、許容閾値期間内の)タイムスタンプを伴うコンテンツインスタンスを見出す場合、発見応答の中にこのコンテンツの参照(例えば、URI)を含む応答をコンテンツ要求アプリ206に返し得る。この場合、サービス層204は、そのローカルに記憶されたコンテンツをリフレッシュすることを開始しないこともある。しかしながら、サービス層204は、この場合でさえも、そのコンテンツを依然としてリフレッシュすることを選定し得る。例えば、コンテンツが古くなることが近い場合、サービス層204は、この状態を検出し、コンテンツを積極的にリフレッシュすることを選定し得る。ステップ222からステップ231および図10の付随する説明は、図11のブロック247の中のステップと同一であり得る。ステップ248では、新鮮なコンテンツインスタンスがサービス層204に正常にパブリッシュされた場合、このコンテンツの参照(例えば、URI)は、発見応答の中で返され、そうでなければ、エラーが代わりに返され得る。ステップ249では、コンテンツ要求アプリ206は、発見応答を処理し、続いて、(応答の中の規定参照に基づいて)その鮮度要件を満たす発見コンテンツインスタンスのうちの1つ以上のものを読み出し得る。
図12は、例示的鮮度ベースの要求再標的化メッセージフローを図示する。要求受信アプリ203は、サービス層204が所与のリソースのために受信するある要求を、サービス提供されるべき要求受信アプリ203に再標的化するようにサービス層204を構成し得る。この再標的化機能性は、要求および応答が、要求開始アプリ205と要求受信アプリ203との間でサービス層204を通ってエンドツーエンドでフローすることを可能にする透過性のレベルを有する。そのような特徴がないと、要求受信アプリ203および要求開始アプリ205は、単一のエンドツーエンド要求および応答交換を実施するために、複数のサービス層サブスクリプションならびに通知を伴うあまり効果的ではない、または好ましくない間接通信方式に依拠し得る。
例えば、図12の方法は、サービス層204によって受信される更新要求を要求受信アプリ203に再標的化するために使用され得る。これは、要求受信アプリ203がアクチュエータタイプのデバイス(例えば、明かりのスイッチ)であるシナリオのために有用であり得る。要求受信アプリ203が再標的化されることを所望する要求のタイプは、プログラム可能なサービス層再標的化ポリシによって構成され得る。CREATE(例えば、子リソースの作成)、RETRIEVE、DELETE、およびSUBSCRIBE等の他のタイプの要求も、図12に示されるように、このプロシージャに適用可能であり得るが、プロシージャを簡潔に保つために明示的に示されていない。加えて、他のポリシが、サービス層204が要求を要求受信アプリ203に再標的化するときを制限し得る。例えば、サービス層204は、要求のフィルタリングをサポートし、所与の標的リソースのために要求の一部を要求受信アプリ203に再標的化するのみ(例えば、特定の要求開始アプリ205からの要求を再標的化するのみ)であり得る。サービス層は、鮮度フィルタリングリングおよび再標的化を実施するときにサービス層204が分析するであろう(および分析しないであろう)リソース表現の中の属性を制御するポリシもサポートし得る。この特徴は、要求受信アプリ203が、要求受信アプリ203に重要性を有する属性にその比較の焦点を合わせ、他のものを無視するようにサービス層204を構成することを可能にし得る。さらに別のタイプの再標的化ポリシは、再標的化された要求の中に含まれる属性および含まれないものを定義し得る。さらに別のタイプの再標的化ポリシは、それらの要求をコンテンツソーシングアプリ202に再標的化させる特権を伴う特定のコンテンツ要求アプリ206を定義し得る。
サービス層204が実施し得る再標的化のタイプは、鮮度ベースの再標的化である。標的リソースへのUPDATE要求を受信すると、サービス層204は、更新されるべきリソースの現在の表現を、UPDATE要求の中で提供される表現と比較し得る。それらが同じである場合、サービス層204は、現在のリソースが新鮮かつ最新であることを推測し、要求受信アプリ203上の要求の数および負荷を最小化するために、UPDATE要求を要求受信アプリ203に再標的化しないことを選定し得る。そのような場合において、サービス層204は、ステータスコードを要求開始アプリ205に返し、この状況をそれに通知し得る。逆に、比較された表現が同じではない場合、サービス層204は、要求受信アプリ203が処理するためにUPDATE要求をそれに再標的化し得る。加えて、サービス層204は、リソースのそのローカルバージョンを更新し、要求受信アプリ203の表現との同期化を維持し、潜在的な将来の要求のために更新されたバージョンを活用し得る。図12に(図8−図9にも)示されるようなこの鮮度ベースの再標的化特徴は、経時的に重複要求を受信し得るリソース制約されたIoTデバイスおよびネットワークを伴うもの等のいくつかのユースケースに価値があり得る構成可能オプションとしてサポートされ得ることに留意されたい。重複要求が機能的重要性を有し得る他のユースケースに対して、この特徴は、無効にされ得る。特徴を選択的に有効または無効にする1つの例示的方法は、ポイントオブコンタクトを使用することによるものである(例えば、いかなるポイントオブコンタクトも構成されない場合、その再標的化は無効にされる)。特徴を選択的に有効または無効にする第2の例示的方法は、再標的化ポリシを使用することによるものである。
ステップ261では、要求受信アプリ203および要求開始アプリ205は、認証し、サービス層204に登録する。要求開始アプリ205は、次いで、要求受信アプリ203を発見する。ステップ262では、要求受信アプリ203は、所与のリソースのためのサービス層204内のポイントオブコンタクト構成アドレスおよび再標的化ポリシを備えているメッセージを送信する。ステップ262のメッセージは、以下のうちの1つ以上のものを含み得る:(to=URI、point−of−contact=App Addr Info、retargetPolicies=policies)。ステップ263では、サービス層204は、規定リソースのために要求受信アプリ203に関連付けられるポイントオブコンタクト情報および再標的化ポリシを構成する。ステップ264では、サービス層204は、とりわけ、ステップ262のメッセージの受信を確認し得る応答を送信し得る。図12のステップ262からステップ264は、鮮度ベースのコンテンツ読み出しで定義される図10のステップ211−213に類似するが、しかしながら、加えて、要求受信アプリ203は、所与のリソースのために再標的化ポリシを構成し得る。代替として、再標的化ポリシは、ネットワーク内の管理エンティティ等の他のエンティティによって構成され得る。これらのポリシは、要求を要求受信アプリ203に発行することを可能にされる要求開始アプリ205のリスト、要求受信アプリ203がサービス提供するであろう許容要求タイプのリスト、要求受信アプリ203が利用可能であり、自発的に要求にサービス提供する時間を定義するスケジュール、および要求受信アプリ203に着目される要求関連属性のリスト/マスク等の再標的化規則を含み得る。
ステップ265では、要求開始アプリ205は、標的アドレス(例えば、URI)によって規定されるような特定の要求受信アプリに関連付けられる特定のリソースを更新するためのUPDATE要求をサービス層204に発行する。要求の中に、更新されるべきリソースの完全または部分表現が含まれ得る。この例では、UPDATEは、要求受信アプリ203によってサポートされるスイッチの状態を「ON」の値に変更するために使用される。メッセージは、以下のうちの1つ以上のものを含み得る:(to=URI、content=‘ON’)。
図12を継続して参照すると、ステップ266では、サービス層204は、ステップ165のUPDATE要求を処理する。要約すると、再標的化ポリシに基づいて、要求の中のコンテンツに対して標的リソースの現在の表現を比較し、それらが異なることを決定し、したがって、要求を要求受信アプリ203に再標的化することがあり得る。さらに詳細に、サービス層104は、要求開始アプリ205の要求によって標的化されるリソースの再標的化ポリシを分析し得る。これらのポリシを使用して、サービス層204は、要求開始アプリ205が要求を要求受信アプリ203に発行する権限を与えられているかどうか、要求が要求受信アプリ203によってサポートされるものであるかどうか、規定スケジュールまたは規定条件に基づいて、要求をバッファし、ひいては、要求受信アプリ203に再標的化するときの決定等のチェックを実施し得る。サービス層204は、次いで、UPDATE要求の中に含まれる表現に対して、(該当する場合)サービス層204の中に記憶されたリソースの現在の表現を比較する。この比較は、ある属性のみが互いと比較されるように、比較する(または比較しない)複数のリソース属性のうちの一部を定義するマスクを考慮し得る。比較がいかなる不一致ももたらさない場合、サービス層204は、UPDATE要求を要求受信アプリ203に再標的化しないことを決定し得る。しかしながら、(この例のように)不一致が見出される場合、サービス層204は、UPDATE要求を再標的化することを決定し得る。サービス層204内の記憶された状態が要求受信アプリ203の状態と同期しなくなる(例えば、明かりが「ON」であるが、サービス層状態はそれが「OFF」であることを示す)場合に対して、次いで、この提案される鮮度ベースのフィルタリング機能性をオーバーライドする機構を有することが可能である。例えば、サービス層142が明かりを消灯するように5つの連続要求を受信した場合、たとえ記憶された状態が、UPDATE要求が新鮮ではないことを示したとしても、サービス層142は、要求を要求受信アプリ203に転送し得る。
図12のステップ267では、サービス層204は、UPDATE要求を、サービス提供されるべき要求受信アプリ203に再標的化する。この要求の中に、要求開始アプリ205からのオリジナル要求の中に含まれる更新されるべきリソースの表現が含まれ得る。ステップ267のメッセージは、以下のうちの1つ以上のものを含み得る:(to=point of contact、content=“Switch ON”)。ステップ268では、要求受信アプリ203は、サービス層204からUPDATE要求を受信して処理する。それは、リソースのそのローカルバージョンを更新することによって、これを行い得る。この例では、UPDATEは、要求受信アプリ203によってサポートされるスイッチの状態を「ON」の値に変更するために使用される。ステップ269では、要求受信アプリ203は、サービス層204に応答し、それがリソースのそのローカルバージョンを正常に更新したことを示す。ステップ270では、サービス層204は、ステップ269のメッセージを受信することに応答し得る。ステップ271では、リソースのそのローカルバージョンに同じ更新(例えば、状態を「ON」の値に変更する)を実施し、それは、サービス層204は、UPDATE要求が正常に処理されたことを示すメッセージを要求開始アプリ205に送信する。
図12を継続して参照すると、ステップ272では、異なる要求開始アプリ205(以降では第2の要求開始アプリ205)が、第1の要求開始アプリからの(すなわち、要求265に関連付けられる)UPDATEと意味的に同じである(例えば、要求ペイロードの中に同一のリソース表現を含む)UPDATE要求を発行する。ステップ273では、サービス層204は、ステップ266で説明されるものに類似する処理を実施する。サービス層204は、比較結果が合致する(例えば、「ON」の更新された値が現在の値と同じである)ことを検出し、UPDATE要求を要求受信アプリ203に再標的化しないことを決定する。ステップ274では、サービス層204は、第2の要求開始アプリ205からのUPDATE要求が、たとえ要求受信アプリ203に再標的化されなかったとしても処理されたという事実を追跡するためにそのローカルメタデータを更新し得る。これは、課金、分析、および要求への後続の反応の決定等の目的のために、要求開始アプリ205の要求履歴を追跡するために有用であり得る。ステップ275では、サービス層204は、第2の要求開始アプリ205に応答し、UPDATE要求が正常に処理されたことを示す。
以下は、本明細書で議論される方法、システム、およびデバイスのうちのいくつかのための考慮事項であった。第1の考慮事項は、現在のoneM2Mアーキテクチャが、リソースがAEではなくCSEによってホストされるという原理に基づくと考えられることである。したがって、AEによってホストされるリソースも、AEホスト型リソースにアクセスするメッセージまたはプロシージャも、oneM2Mによって定義されない。AEを標的化することができる、oneM2Mによって定義される要求のタイプは、NOTIFY要求である。AEは、CREATE、RETRIEVE、UPDATE、DELETE、SUBSCRIBE、またはDISCOVER oneM2M要求によって標的化されることができない。したがって、oneM2Mシステムの一部として機能するために、AEは、CSEに登録し、CSEがこれらのリソースをホストし、それらを他のAEに発見可能かつアクセス可能にし得るように、CSE内でそのリソースをパブリッシュまたはミラー化しなければならない。
第2の考慮事項は、oneM2Mが現在、AEが所与のコンテナのためにポイントオブコンタクトを規定するための能力をサポートしないことである。加えて、CSEが要求を処理する代わりに、CSEが、入って来るコンテナ要求を、処理されるべき対応するAEに再標的化するための能力が、サポートされていない。CSEが、標的コンテナの中の<contentInstance>リソースが古すぎて入って来る要求にサービス提供することができないことを検出し、次に、AEから新鮮な<contentInstance>を取得して要求を満たす能力もサポートされない。
第3の考慮事項は、ホスティングCSEが、それがたまたま現在ホストしている最新の<contentInstance>リソースのみを使用して、<latest>への読み出しにサービス提供することに限定されていることである。要求の発信側が、最新の<contentInstance>のcreationTimeよりも遅いタイムスタンプを有するcreatedAfterフィルタ基準条件も規定する場合、これは、いかなる合致ももたらさないであろう。oneM2Mは、現在、このシナリオではAEから新鮮な<contentInstance>リソースを取得する機構およびプロシージャをサポートしていない。
第4の考慮事項は、規定createdAfterフィルタ基準条件がいかなる合致ももたらさない場合、oneM2Mが、現在、規定createdAfterフィルタ基準を満たす新鮮なコンテンツをAEから取得する機構およびプロシージャをサポートしていないことである。第5の考慮事項は、oneM2Mが、現在、AEが作成して使用されることを可能にされる他のリソースタイプ(例えば、<container>、<flexContainer>、<mgmtObj>、<mgmtCmd>等)のためにpointOfAccessを構成することをサポートしていないことである。oneM2Mは、CSEによるpointOfAccess属性の使用を、CSEが通知をAEに送信している場合のみにさらに制限する。oneM2Mが、oneM2Mを介してアドレス指定されることができるAEホスト型リソースをサポートしないので、oneM2Mは、AEがpointOfAccessの中へのURIパス等の他のアドレス情報を構成することを可能にしない。oneM2Mはまた、複数のpointOfAccessエントリがAEによって構成される場合、CSEがそれらを使用する方法も定義しない。第6の考慮事項は、oneM2Mが、現在、CSEが任意の他のタイプの要求を上でリストアップされるもの以外、AEに開始または再標的化することを可能にしないことである。例えば、CSEは、アプリケーションの中に記憶されたリソースを読み出すこと、または更新することができない。第7の考慮事項は、アプリケーションサービス層に対処し得る従来のシステムが、forwardingAddressが要求の鮮度ベースの処理をサポートするために使用される方法を定義しないことである。第8の考慮事項は、CoRE Mirror Server−IETF draft−vial−core−mirror−server−01(2013年4月10日)が、クライアントがミラー化リソースへのそのGET要求の中で鮮度時間(例えば、標的リソースがある日付または時間より古くあることができない)を特定することを可能にする能力をサポートしないことである。加えて、とりわけ、CoRE Mirror Server−IETF draft−vial−core−mirror−server−01(2013年4月10日)は、ミラー化リソースが古い(例えば、ミラーリソース表現がクライアントGET要求で規定される規定日付または時間よりも古い)場合のために、それがミラー化リソースのために受信するGET要求をSEP上でホストされる対応するリソースに条件付きで転送する能力をサポートしない。
本明細書で議論される概念を考慮して適用し得るoneM2M例が以下で開示される。図13は、OneM2Mにおけるサービス層鮮度機構の例示的アーキテクチャを図示する。鮮度能力は、CSEの中のデータ管理およびリポジトリCSF、発見CSF、またはサブスクリプションおよび通知CSFの特徴として実現され得る。鮮度能力は、例えば、データ管理およびリポジトリCSF280、発見CSF281、またはサブスクリプションおよび通知CSF282に追加され得る。
本明細書に開示される鮮度機構およびプロシージャを実現するために、oneM2Mリソースへの強化が本明細書で定義される。
oneM2MリソースがAEのアドレス情報で構成されることを可能にするpointOfContact共通リソース属性が、本明細書に開示される。所与のリソースのためのこの属性の存在は、このリソースと連携するAE(例えば、リソースを作成したAE、すなわち、コンテンツソーシングAE302)が、CSEによってそれに送信される要求にサービス提供する能力をサポートするという、ホスティングCSE(例えば、図10のサービス層204または図14のCSE304)への指示であり得る。これらの要求は、CSEがAEに向けて再標的化し、他のエンティティ(例えば、他のAEまたはCSE)によって開始される要求、またはCSEが(例えば、古いリソース表現をリフレッシュするために)それ自身で開始する要求であり得る。このpointOfContact属性は、種々のタイプのoneM2M定義リソースによってサポートされ得る。例えば、<container>、<flexcontainer>、<mgmtObj>、<mgmtCmd>、<timeSeries>等のリソースタイプ。
提案されるpointOfContact属性は、対応するAEの異なるタイプのアドレス情報をサポートし得る。一例では、pointOfContact属性は、AEがホストするリソースの絶対URI(例えば、http://172.30.0.55:3478/temperature)で構成され得る。この場合、CSEは、要求をAEに送信するための完全アドレスとしてこのpointOfContactを使用し得る。第2の例では、pointOfContact属性は、CSEによってホストされるAEの<AE>リソースのoneM2M定義resourceIDで構成され得る。この場合、CSEは、resourceIDを使用し、サポートされた方式、すなわち、<AE>リソースのoneM2M定義pointOfAccess属性内で構成されるAEのFQDNまたはIPアドレスおよびポートにアクセスし得る。この情報は、次に、CSEによって要求をAEに送信するために使用され得る(例えば、http://172.30.0.55:3478)。第3の例では、pointOfAccess属性は、AEがホストするリソースの相対URI(例えば、/temperature)で構成され得る。この場合、CSEは、部分アドレスとしてこのpointOfAccessを使用し得る。CSEは、次いで、pointOfAccess属性を有するリソースと連携する親<AE>リソースのpointOfAccess属性の中で構成されるFQDNまたはIP/ポートを使用することによって、完全アドレスを形成することをサポートし得る。CSEは、URIのパス部分としてpointOfAccess相対URI(例えば、/temperature)を使用し、方式およびホスト部分(例えば、http://172.30.0.55:3478)としてpointOfAccess情報を使用し、絶対URI(例えば、http://172.30.0.55:3478/temperature)を形成し得る。
表1は、開示されるpointOfContact oneM2M共通属性のさらなる詳細を提供する。
本開示は、新しいoneM2M通知イベントおよびコンテンツタイプを提案する。これらは、CSEが、本明細書に開示される鮮度ベースのコンテンツ読み出し、コンテンツ発見、および要求再標的化機能性をサポートすることを可能にし得る。読み出しに加えて、oneM2M通知コンテンツタイプ特徴は、作成、更新、または削除等のCSEからAEへの他のタイプの要求の再標的化をサポートするために使用され得る。
新しいタイプの通知イベントが、oneM2Mサブスクリプションイベント通知基準のために定義される。新しいイベントは、subscribed−to<container>リソースの最新の<contentInstance>を読み出す試みがあり、<contentInstance>リソースが存在しないか、またはそのcreationTimeが読み出し要求のcreatedAfterfilterCriteria内で規定される時間よりも古いかのいずれかであるとき、トリガされ得る。これは、本明細書の表2に示される。
新しいタイプの通知コンテンツが、oneM2M通知のために定義される。
新しいコンテンツタイプは、subscribed−to−parentリソースを標的化し入って来る要求が通知にカプセル化されることを可能にする。これは、本明細書の表3に示される。
これらの新しい通知イベントおよびコンテンツタイプは、oneM2MサブスクリプションがCSEからAEへの要求の再標的化に使用されることを可能にする。AEは、これらを使用して、CSEが所与のリソースのために受信する要求をサービス提供されるべきAEに再標的化するようにCSEを構成し得る。トリガされると、新しいイベントは、CSEが通知要求を生成し、サブスクリプションのnotificationURI属性によって定義される規定標的(例えば、AE)に通知要求を送信することをもたらし得る。通知のコンテンツは、サブスクリプションの親リソースをもともと標的化する1つ以上の埋め込まれた要求と、CSEが再標的化していることとを含み得る。通知を受信すると、受信側(例えば、AE)は、通知のコンテンツに埋め込まれた再標的化された要求を処理し得、応答は、通知応答のコンテンツ内に埋め込まれたCSEに返され得る。通知応答を受信すると、CSEは、通知応答を処理し、通知応答のコンテンツに埋め込まれた応答を要求の発信側に戻るように再標的化し得る。
別の例では、新しいタイプのイベントが、oneM2MサブスクリプションeventNotificationCriteria条件のために定義される。この新しいタイプのイベントは、oneM2MサブスクリプションがCSEからAEへの要求の再標的化に使用されることを可能にする。AEは、この新しいタイプのイベントを使用し、CSEが所与のリソースのために受信する要求をサービス提供されるべきAEに再標的化するように、CSEを構成し得る。トリガされると、eventNotificationCriteriaは、CSEが通知要求を生成し、サブスクリプションのnotificationURI属性によって定義される規定標的(例えば、AE)に通知要求を送信することをもたらし得る。通知のコンテンツは、サブスクリプションの親リソースをもととも標的化する1つ以上の埋め込まれた要求と、CSEが再標的化していることとを含み得る。通知を受信すると、受信側(例えば、AE)は、通知のコンテンツに埋め込まれた再標的化された要求を処理し得、応答は、通知応答のコンテンツ内に埋め込まれてCSEに返され得る。通知応答を受信すると、CSEは、通知応答を処理し、通知応答のコンテンツに埋め込まれた応答を要求の発信側に戻るように再標的化し得る。
図19に図示されるような<contentInstance>リソースタイプのための新しいoneM2M属性、すなわち、contentTimestampが、本明細書に開示される(表4も参照)。この属性は、AEが、それがCSEにパブリッシュするコンテンツのためのAE定義タイムスタンプを構成することを可能にする。これは、AEが、コンテンツがAEによって実際にパブリッシュされ、CSE上で作成された時間と異なり得るコンテンツがAEによって作成された時間をパブリッシュすることを可能にする。これは、AEがコンテンツをバッファし、以降のある時にそれをCSEにパブリッシュし得るユースケースのために重要であり得る。AEがこの時間をCSEにパブリッシュすることを可能にすることは、コンテンツがCSEにパブリッシュされたときと対比して、それが発信元AEによって実際に生成または収集されたときに関する追加の情報を、このコンテンツへのアクセスを要求する他のAEに提供する。
新しいタイプのRETARGET動作のためのサポートを追加するためのoneM2M<accessControlPolicy>リソースへの強化が本明細書に開示され、RETARGET動作は、<accessControlPolicy>リソースの特権属性のoneM2M定義accessControlOperationsパラメータによってサポートされ得る。表5は、新しいRETARGET動作を捕捉する。このRETARGET動作は、特定の発信側からの要求がCSEによって再標的化されるための特権を有するかどうかを定義するために使用され得る。RETARGET動作がaccessControlOperationsリスト内で定義される場合、再標的化が有効にされ、そうでなければ無効にされる。有効にされた場合、CSEは、要求をAE等の規定エンティティに再標的化し得る。本明細書で議論されるように、再標的化された要求を受信するエンティティを規定するためのいくつかの方法がある。例えば、pointOfContact属性が、1つの方法であり、notificationURIが、別の方法である。
本明細書に開示される提案される鮮度機構を実現することに役立つために、oneM2M要求および応答メッセージへの以下の強化が定義される。oneM2M通知要求の構造は、m2m:notificationデータタイプおよび対応する通知スキーマファイルによって定義され得る。
本開示は、contentRequest、contentReference、freshnessTime、contentPriority、およびcontentSchedule要素を、m2m:notificationデータタイプならびに対応する通知スキーマファイルに追加することと、通知をAEに送信して、AEに、鮮度ベースのプロシージャによって定義されるように新鮮なコンテンツをCSEに提供させることをサポートすることとを議論する。要求されたコンテンツは、通知応答を介して、要求CSEに返され得るか、または代替として、AEは、要求CSE上でコンテンツを更新または作成するための別個の要求を継続し得る。本明細書では、contentScheduleが、コンテンツの鮮度が期待される期待期間を含み得ることが考慮される。例えば、contentScheduleは、周期的スケジュール(例えば、5分の間隔で出現もしくは発生する)、または特定の時間および日付等の非周期的スケジュール(例えば、5月5日の13時、7月7日の10時等)であり得る。CSEは、受信される要求のパターン(例えば、1つ以上のコンテンツ要求アプリケーションから特定のCSEまたは同様に位置するCSEへの要求の中の複数の鮮度期間を分析すること)を介して、スケジュール(例えば、閾値期間)に基づいてコンテンツソースアプリケーションから新鮮な読み取り値を受信する必要があろうことを決定し得る。これは、コンテンツソースアプリケーションがスケジュールに基づいてコンテンツ更新を積極的に送信するであろうため、CSEからの要求の数を削減し得る。スケジュールは、コンテンツソース(例えば、コンテンツソーシング202)からの更新の頻度を増加または減少させ得る。コンテンツソースが議論されるが、これらの原理は、要求受信アプリケーションを伴う状況にも適用され得る(例えば、アクチュエータを伴い得る図12)。
CSEが、oneM2M通知要求を介して、AEへの作成、読み出し、更新、削除、サブスクライブ、および発見要求を開始または再標的化することを可能にするcreateRequest、retrieveRequest、updateRequest、deleteRequest、discoverRequest、および、subscribeRequest要素の追加も本明細書で議論され、AEは、これらの要求にサービス提供し、oneM2M通知応答を介して応答をCSEに返し得る。
oneM2Mは、現在、そのリリース1仕様(その全体として参照することによって組み込まれる、oneM2M−TS−0001 oneM2M Functional Architecture−V2.6.0)でデバイストリガ特徴を定義している。しかしながら、oneM2Mは、CSEから3GPP等の下層ネットワーク機能によってサポートされるデバイストリガ機能に送信されるデバイストリガ要求メッセージのメッセージフォーマットをまだ定義していない。
表6で定義されるものに類似する要素も、新しいデバイストリガ要求要素としても見なされるべきである。そうすることで、oneM2Mデバイストリガ要求は、本開示で定義される鮮度ベースのコンテンツ読み出しおよび発見プロシージャのために読み出しまたは通知要求を使用することの別の代替物として、使用され得る。これは、鮮度ベースのコンテンツ読み出しまたは発見要求が、現在CSEに到達可能ではないデバイス上でホストされるコンテンツソーシングAEに対して開始されるために好ましい(または開始される必要がある)ユースケースに特に適用可能であり得る。この場合、CSEは、コンテンツソーシングAEへのデバイストリガ要求を開始し、同時に、トリガ要求に鮮度ベースのコンテンツ読み出し要素を埋め込み得る。同様に、同一の機能性が、要求を要求受信AEに転送するために使用され得る。
開示される鮮度機構を実現するために、oneM2Mプロシージャへの以下の強化が、図14を参照して定義される。
oneM2M CSE(例えば、CSE304)は、AEが、随意に、所与のリソースのためのpointOfContactアドレスを規定することを可能にする能力をサポートするように強化され得る。例えば、AEは、<container>リソースのpointOfContact属性を構成し得る。pointOfContact属性を構成することによって、AEは、AEが所与のリソースに関連付けられる要求を受信し、サービス提供する能力をサポートすることを、CSE304に示し得る。例えば、AEは、所与の<container>リソースのための新鮮な<contentInstance>を作成する要求を受信し得る。
CSE304は、CSE304が、標的リソースのローカルに記憶された表現を使用して、それ自身で要求にサービス提供するときと対比して、サービス提供すべきコンテンツソーシングAE302に要求を送信するときを決定する異なる方法をサポートし得る。1つのそのような方法は、oneM2M定義createdAfterフィルタパラメータを使用して読み出し要求内で規定される鮮度時間を伴い得る。この要求パラメータを使用して、要求側は、要求の中で鮮度タイムスタンプを規定し得る。CSE304は、このcreatedAfterフィルタパラメータに対して、標的リソースの1つ以上のローカルに記憶された表現のcreationTime(および/または提案されるcontentTimestamp属性)を比較し得る。creationTimeがcreatedAfterタイムスタンプよりも新しい(より最近または適時である)ことが見出された場合、CSE304は、コンテンツソーシングAE302を伴うことなく、それ自身で要求にサービス提供し得る。しかしながら、creationTimeがより古い場合、CSE304は、読み出し要求にサービス提供するリソース表現の新鮮なバージョンを取得し、その規定鮮度選好または要件を満たそうとして、対応するコンテンツソーシングAE202のpointOfContactへの要求を開始し得る。
図14は、例示的oneM2M鮮度ベースのコンテンツ読み出しメッセージフローを図示する。このプロシージャは、oneM2M<container>および<contentInstance>リソースタイプを使用して示されているが、類似プロシージャは、<flexContainers>、mgmtObj、mgmtCmd等の他のoneM2Mリソースタイプにも使用され得る。
ステップ310では、コンテンツソーシングAE302およびコンテンツ要求AE306は、認証し、次いで、CSE304に登録する。コンテンツ要求AE306は、次いで、コンテンツソーシングAE302を発見する。ステップ311−313では、コンテンツソーシングAE302は、<container>リソースを作成し、そのpointOfContac情報(例えば、URI)を構成する。ステップ311では、コンテンツソーシングAE302は、<container>作成を送信し、pointOfContactメッセージを構成し、メッセージは、以下のうちの1つ以上のものを有し得る、:(to=<AE>、pointOfContact=Source AE Addr Info)。ステップ312では、CSE204は、<container>リソースを作成し、ステップ311に基づいて、ソースAEのpointOfContact情報を構成する。ステップ313では、CSE304は、要求の一般的確認応答または要求の完了を含み得る応答メッセージを送信し得る。
図14のステップ314−316では、コンテンツソーシングAE302は、<container>リソース内で1つ以上の<contentInstance>子リソースを作成する。各<contentInstance>は、CSE304によって作成および記憶される(ステップ315)。コンテンツソーシングAE302は、コンテンツインスタンス(例えば、センサ読み取り値)がコンテンツソーシングAE302によって生成または捕捉されたときのcontentTimestampも提供し得る。加えて、CSE304は、コンテンツインスタンスがCSE304の中で作成された時間を示すcreationTimeを<contentInstance>に割り当て得る。
図14を継続して参照すると、ステップ317−319では、コンテンツソーシングAE302は、<container>にサブスクライブすることにより、読み出し要求がsubscribed−to<container>リソースの最新の<contentInstance>を読み出すために試行され、<contentInstance>リソースが存在しないか、またはそのcreationTimeが読み出し要求のcreatedAfterfilterCriteria内で規定される時間よりも古いかのいずれかである度に、CSE304から通知を受信し得る。これを行うために、コンテンツソーシングAE302は、本明細書で定義される新しいフォーマット通りに、サブスクリプションの通知eventTypeおよびコンテンツタイプを構成し得る。ステップ317では、コンテンツソーシングAEは、サブスクリプションを作成するメッセージを送信し、メッセージは、以下の情報、(to=<container>)を有し得る。ステップ318では、CSE304は、(ステップ317に応答して)<subscription>リソースを作成する。ステップ319では、応答が送信され得る。
図14のステップ320では、コンテンツ要求AE306は、コンテンツソーシングAE302の標的<container>の中に記憶された最新の<contentInstance>リソースを読み出すための要求をCSE304に発行する。要求の中に、時間および日付情報を含み得る規定createdAfterパラメータが含まれる。コンテンツ要求AE306は、このパラメータを使用して、それが規定時間および日付以後のコンテンツを要求することを規定し得る。ステップ321では、CSE304は、<container>リソース内に記憶された最新の<contentInstance>(存在する場合)のcreationTime(またはcontentTimestamp)に対して、要求のcreatedAfterパラメータ内の規定時間および日付情報を比較する。この比較から、CSE304は、<contentInstance>が利用可能であるかどうかを決定し、該当する場合、コンテンツ要求AE306の鮮度要件を満たすかどうかを決定する。図のブロック323内のステップ322では、CSE304が規定createdAfter要件を満たす<contentInstance>を見出す場合、<contentInstance>を含む応答をコンテンツ要求AE306に返し得る。この場合、CSE304は、コンテンツソーシングAE302への要求を開始し、新鮮な<contentInstance>を取得する必要がない。
図14を継続して参照すると、記憶されたコンテンツインスタンスが鮮度選好または要件を満たさない場合、ブロック324に進む。ステップ325では、CSE304が規定createdAfter要件(すなわち、閾値期間)を満たす<contentInstance>を見出さない場合、CSE304がコンテンツソーシングAE302から新鮮な<contentInstance>を取得しようとしている間に、コンテンツ要求AE306がブロックして待機することを要求されないように、CSE304は、確認応答(すなわち、非ブロック応答)をコンテンツ要求AE306に返し得る。ステップ325のこの確認応答(すなわち、非ブロック応答)は、要求が受信され、CSE304がコンテンツ要求AE306の鮮度要件を満たしたローカルにホストされた<contentInstance>を有していなかったので、依然として処理されていることを示すステータスを含み得る。ステップ325の確認応答は、CSEコールバックアドレス(例えば、URI)も含み得、それは、新鮮な<contentInstance>を読み出すために、または、新鮮な<contentInstance>が利用可能になったときにそれを受信するためにサブスクライブするために、コンテンツ要求AE306によって使用され得る。例えば、コンテンツ要求AE306は、このアドレスに周期的にポーリングするか、またはこのアドレスにサブスクライブし(ステップ326参照)、CSE304がコンテンツソーシングAE302から新鮮な<contentInstance>を取得することができた場合、新鮮な<contentInstance>を受信するか、または、CSE304がコンテンツソーシングAE302から新鮮な<contentInstance>を取得することに失敗した場合、エラー状態を受信し得る。代替として、CSE304は、ブロック様式で要求を処理することを選定し得、その場合、ステップ325では確認応答をコンテンツ要求AE306に返さないであろう。代わりに、それは、図14で表示されるようなこのプロシージャにおけるステップ331まで、コンテンツ要求AE306に応答することを控えるであろう。
図14のステップ327では、CSE304は、コンテンツソーシングAE302への要求を開始し、新鮮な<contentInstance>を要求する。この要求は、いくつかの異なるタイプの提案される要求のうちの1つを使用して、コンテンツソーシングAE302に配信され得る。第1の提案される要求を参照すると、CSE304は、ステップ311でコンテンツソーシングAE302によって規定されたpointOfContactを標的化する読み出し要求を開始し得る。この要求は、コンテンツ要求AE306からのオリジナル要求の中の1つと同一のタイムスタンプで構成され得るcreatedAfterパラメータを含み得る。代替として、CSE304は、ステップ317で説明されるサブスクリプション要求がコンテンツソーシングAE302によって実施された場合、コンテンツソーシングAE302への通知要求を開始し得る。この通知は、表6に関連付けられる議論等の本明細書に開示されるもの等の要素を含み得る。
図14のステップ328では、CSE304からステップ327の要求を受信すると、コンテンツソーシングAE302は、要求のタイプ(例えば、読み出しまたは通知)を処理して検出し得る。ステップ327の要求が読み出しである場合、コンテンツソーシングAE302は、要求の中に存在する場合、規定アドレスおよびcreatedAfterパラメータを分析し、要求されているコンテンツを決定し、次に、<contentInstance>を準備し、読み出し応答の中でCSE304に返し得る。要求が通知である場合、コンテンツソーシングAE302は、contentRequest要素が存在し、TRUEに構成されているかどうかをチェックすることによって、それがコンテンツに対する要求であることを検出し得る。コンテンツソーシングAE302が、2つ以上のタイプのコンテンツをサポートする場合、contentReference要素をチェックし、CSE304によって要求されているコンテンツのタイプを検出し得る。それは、次いで、contentPriorityまたはcontentSchedule要素をチェックし、CSE304に新鮮な<contentInstance>を提供しなければならないときを決定し得る。コンテンツソーシングAE302は、contentFreshnessパラメータもチェックし、規定されるコンテンツの要求される鮮度日付または時間があるかどうかを確認し得る。1つが規定される場合、コンテンツソーシングAE302は、それが提供する任意の<contentInstance>が、この日付および時間の前に生成されなかったことを確認し得る。
図14のステップ329では、コンテンツソーシングAE302は、いくつかの方法のうちの1つにおいて、新鮮なコンテンツインスタンスでCSE304を更新し得る。CSE304が、新鮮な<contentInstance>を要求する明示的読み出し要求をコンテンツソーシングAE302に発行する場合、コンテンツソーシングAE302は、読み出し応答の中に新鮮な<contentInstance>を含み得る。CSE304が、新鮮な<contentInstance>が必要とされることを示す通知をコンテンツソーシングAE302に発行する場合、コンテンツソーシングAE302は、通知応答の中に新鮮な<contentInstance>を含み得るか、または代替として、コンテンツソーシングAE302は、別個の要求(例えば、作成要求)を継続し、通知要求の中でcontentReferenc要素によって規定される<container>リソースの中で新鮮な<contentInstance>を作成し得る。ステップ330では、新鮮な<contentInstance>が正常に返された場合、または作成された場合、CSE304は、新鮮な<contentInstance>のローカルバージョンが、将来の要求にサービス提供するために活用され得るか、またはとりわけ、課金および分析等の目的のために使用され得るように、それを記憶する。CSE304は、随意に、対応するタイムスタンプを割り当て、<contentInstance>がCSE304の中で作成されたときを記録し得る。ステップ331では、新鮮な<contentInstance>がCSE304に正常にパブリッシュされた場合、コンテンツ要求AE306に返され、そうでなければ、エラーが代わりに返される。
以下は、図15を参照して、開示される鮮度ベースのコンテンツ発見側面を追加することによって、既存のoneM2M定義リソース発見プロシージャを強化する。機構は、CSE304が、コンテンツ要求AE306に着目される<contentInstance>リソースが、古いとき、またはそうではないときを検出し、対応するコンテンツソーシングAE302にコンタクトし、それに新鮮な<contentInstance>を提供させ、そして、CSE304が発見応答の中で新鮮な<contentInstance>を参照し得ることを可能にする。図15は、例示的oneM2M鮮度ベースのリソース発見メッセージフローを図示する。このプロシージャは、oneM2M<container>および<contentInstance>リソースタイプを使用して示されているが、類似プロシージャは、<flexContainers>、mgmtObj、mgmtCmd等の他のoneM2Mリソースタイプにも使用され得る。
図15のブロック340は、図14に関して示され、議論されるものと同一のステップ310−319を有する。図15のステップ341では、コンテンツ要求AE306は、特定の<container>リソースに関連付けられる<contentInstance>リソースを発見するためにCSE304に要求する。要求の中に、コンテンツ要求AE306が規定時間および日付以後のコンテンツを発見することを所望することを規定するために使用する時間および日付情報で構成される規定createdAfterパラメータが含まれ得る。加えて、要求は、他の発見フィルタ基準(例えば、コンテンツのタイプ)も含み得る。ステップ342では、CSE304は、標的<container>リソース内のCSE304によってホストされる各適用可能<contentInstance>リソースのタイムスタンプに対して、コンテンツ発見要求のcreatedAfterパラメータ内の規定時間および日付情報を比較する。この比較から、CSE304は、適用可能な<contentInstance>リソースのうちのいずれかが、規定createdAfterパラメータよりも新しいcreationTimeまたはcontentTimestampを有するかどうかを決定する。何も見出されない場合、CSE304が、コンテンツ要求AE306に送信する発見応答の中にこのコンテンツの参照(例えば、URI)を含み得、CSE304が、コンテンツ要求AE306が<contentInstance>にアクセスする後続の要求を送信するときに準備完了して利用可能であるコンテンツを有するように、CSE304は、新鮮な<contentInstance>が対応するコンテンツソーシングAEから要求されることをシグナリングするイベントを生成し得る。このイベントは、ひいては、図14に関して規定されるoneM2M鮮度ベースのコンテンツ読み出しプロシージャにおけるステップ325−330で概説される提案されるプロシージャによって定義されるように、コンテンツソーシングAE302から新鮮な<contentInstance>を取得することを試みるためのトリガとして、CSE304によって使用され得る。トリガの生成は、適用可能なpointOfContact属性が標的<container>リソースの中で構成されているかどうかに基づいて制限され得る。いかなるpointOfContactも構成されていない場合、トリガは抑制され得る。
図15を継続して参照すると、ブロック344のステップ343では、CSE304がcreatedAfterタイムスタンプを満たす<contentInstance>を見出す場合、発見応答の中にこのコンテンツの参照(例えば、URI)を含む応答をコンテンツ要求AE306に返し得る。この場合、CSE304は、そのローカルに記憶された<contentInstance>リソースをリフレッシュすることを開始する必要がない。
ブロック345は、記憶されたコンテンツインスタンスが、鮮度選好または要件を満たさないときに起こり、これは、オンデマンドリフレッシュを開始し得る。ブロック346は、図14のステップ325−330と同一のステップを含む。ステップ347では、新鮮な<contentInstance>がコンテンツソーシングAE302からCSE304に正常にパブリッシュされた場合、このコンテンツの参照(例えば、URI)は、発見応答の中で返され、そうでなければ、エラーが代わりに返される。ステップ348では、コンテンツ要求AE306は、発見応答を処理し、続いて、(応答の中の規定参照に基づいて)その鮮度選好または要件を満たす発見されたコンテンツインスタンスのうちの1つ以上のものを読み出す。
以下のプロシージャは、図16を参照して、本明細書に開示される鮮度ベースのコンテンツ読み出し側面を追加することによって、既存のoneM2M定義デバイストリガプロシージャを強化する。機構は、CSEが、コンテンツ要求AEに着目される<contentInstance>リソースが、古いとき、またはそうではないときを検出し、ひいては、(デバイストリガを介して)対応するコンテンツソーシングAE302にコンタクトし、CSE304が読み出し要求のその処理を完了し得るように、コンテンツソーシングAE302に新鮮な<contentInstance>を提供させることを可能にする。このプロシージャは、oneM2M<container>および<contentInstance>リソースタイプを使用して示されているが、類似プロシージャは、<flexContainers>、mgmtObj、mgmtCmd等の他のoneM2Mリソースタイプにも使用され得る。図17のブロック350は、図14および図15の非シナリオBブロック351のステップ(例えば、図14のステップ310−322)に類似するステップを含む。
図16を継続して参照すると、ステップ352では、CSE304は、コンテンツソーシングAE302へのデバイストリガ要求を開始し、新鮮な<contentInstance>を要求する。ステップ352のデバイストリガ要求は、CSE304から、下層ネットワーク(例えば、3GPP MTC−IWF)によってサポートされるデバイストリガ機能303に送信され得る。ステップ352のデバイストリガ要求メッセージは、デバイストリガに関して本明細書に開示されるような要素を含み得る。ステップ353では、デバイストリガ要求を受信することに応答して、コンテンツソーシングAE302は、それを処理し得る。コンテンツソーシングAE302は、contentRequest要素が存在し、TRUEに構成されているかどうかをチェックすることによって、それがコンテンツに対する要求であることを検出し得る。コンテンツソーシングAE302が2つ以上のタイプのコンテンツをサポートする場合、contentReference要素をチェックし、CSE304によって要求されているコンテンツのタイプを検出し得る。それは、次いで、contentPriorityまたはcontentSchedule要素をチェックし、CSE304に新鮮な<contentInstance>を提供しなければならないときを決定し得る。それは、contentFreshnessパラメータもチェックし、規定されるコンテンツの要求される鮮度日付または時間があるかどうかを確認し得る。1つが規定される場合、コンテンツソーシングAE302は、それが提供する任意の<contentInstance>が、この日付および時間の前に生成されなかったことを確認し得る。
ステップ355では、コンテンツソーシングAE302は、いくつかの方法のうちの1つにおいて、新鮮なコンテンツインスタンスでCSE304を更新し得る。コンテンツソーシングAE302は、デバイストリガ応答の中に新鮮な<contentInstance>を含み得るか、または代替として、コンテンツソーシングAE302は、CSE304への別個の要求(例えば、作成要求)を継続し、トリガ要求の中でcontentReferenc要素によって規定される<container>リソースの中で新鮮な<contentInstance>を作成し得る。ステップ357では、新鮮な<contentInstance>が正常に返された場合、または作成された場合、CSE304は、新鮮な<contentInstance>のローカルバージョンが、将来の要求にサービス提供するために活用され得るように、それを記憶する。図16のブロック259は、図14のステップ331または図15のステップ247および248で規定される、鮮度ベースのコンテンツ読み出しならびに発見プロシージャで定義されるものと同一のステップを有する。
以下のプロシージャは、図17を参照して、本明細書に開示される、とりわけ、再標的化機能性に基づいて既存のoneM2M定義リソースプロシージャを強化する。機構は、CSE304が、標的リソースが更新されるときを検出し、要求を対応する要求受信AEに再標的化し、要求受信AEにそのローカルバージョンを更新させることを可能にする。このプロシージャは、oneM2M<mgmtObj>リソースタイプを使用して示されているが、類似プロシージャは、<container>、<flexContainers>、<mgmtCmd>等の他のoneM2Mリソースタイプにも使用され得る。
図17を継続して参照すると、ステップ360では、要求受信AE307および要求開始AE309は、認証し、次いで、CSE304に登録する。要求開始AE309は、次いで、要求受信AE307を発見する。ステップ361−363では、要求受信AE307は、ソフトウェア<mgmtObj>リソースを作成し、そのpointOfContact情報(例えば、URI)およびそのaccessControlPoliciesを構成する。これらのポリシは、要求を要求受信AE307に発行することを可能にされる要求開始AE209のリスト、再標的化されることを可能にされる許容要求タイプのリスト、要求が再標的化され得る時間を定義するスケジュール等の再標的化規則を含み得る。ステップ364−366では、要求受信AE307は、<mgmtObj>にサブスクライブすることにより、UPDATE要求が試行され、UPDATEが、(re−targetPoliciesで規定されるように)要求受信AE307が着目する<mgmtObj>リソース属性のうちの1つの状態を変化させる度に、CSE304から通知を受信し得る。これを行うために、要求受信AE307は、本明細書で定義される、新たに提案されるフォーマット通りに、サブスクリプションの通知eventTypeおよびコンテンツタイプを構成し得る。ステップ367では、要求開始AEは、activate属性を<mgmtObj>リソースの中の「TRUE」の値に更新(UPDATE)するための要求をCSE304に発行する。
図17のステップ368では、CSE304は、要求開始AE309の要求によって標的化されるリソースの再標的化ポリシを分析する。これらのポリシを使用して、CSE304は、とりわけ、要求開始AE309が要求を要求受信AE307に発行する権限を与えられているかどうか、要求タイプが再標的化される権限を与えられているものであるかどうか、および規定スケジュールに基づいて要求を要求受信AE307に再標的化するときの決定等のチェックを実施し得る。CSE304は、次いで、UPDATE要求の中に含まれる表現に対して、サービス層の中に記憶された<mgmtObj>リソースの現在の表現を比較する。この比較は、ある属性のみが互いと比較されるように、比較する(または比較しない)複数のリソース属性のうちの一部を定義するマスクを考慮し得る。比較は、activate属性の状態の変化に起因して、不一致をもたらす。故に、CSE304は、UPDATE要求を要求受信AE307に再標的化する必要があることを決定する。
図17のステップ369では、CSE304は、UPDATE要求を、サービス提供されるべき要求受信AE307に再標的化する。この要求は、いくつかの異なるタイプの提案される要求のうちの1つを使用して、要求受信AE307に配信され得る。CSE304は、ステップ361で要求受信AE307によって規定されるpointOfContactを標的化するUPDATE要求を開始し得る。第2に、サービス層(CSE204)は、ステップ364で説明されるサブスクリプション要求が要求受信AE307によって実施された場合、要求受信AE307への通知要求を開始し得る。この通知は、本明細書に開示されるような要素を含み得る。第3に、CSE304は、要求受信AE307が到達可能ではない場合、要求受信AE307へのデバイストリガ要求を開始し得る。このデバイストリガ要求は、本明細書に開示されるもの等の要素を含み得る。ステップ370では、CSE304から要求を受信すると、要求受信AE307は、要求のタイプ(例えば、UPDATEまたはNOTIFYもしくはDEVICE TRIGGER)を処理して検出し得る。例えば、要求がUPDATEである場合、要求受信AE307は、規定アドレスを分析し、AEのローカル<mgmtObj>に対して更新を実施し、UPDATE応答の中で応答をCSE304に返し得る。要求がNOTIFYまたはDEVICE TRIGGERである場合、要求受信AE307は、updateRequest要素が存在し、TRUEに構成されているかどうかをチェックすることによって、それがUPDATEに対する要求であることを検出し得る。要求受信AE307が2つ以上のタイプのコンテンツをサポートする場合、requestReference要素をチェックし、CSE304によって要求されている更新を検出し得る。
図17のステップ371では、要求受信AE307は、いくつかの提案される方法のうちの1つでCSE304に応答し得る。CSE304が明示的UPDATE要求を要求受信AE307に発行する場合、要求受信AE307は、UPDATE応答で応答し得る。CSE304がNOTIFYまたはDEVICE TRIGGERを要求受信AE307に発行する場合、要求受信AE307は、それぞれ、通知またはデバイストリガ応答で応答し得る。ステップ372では、要求受信AE307から応答を受信すると、CSE304は、リソースのそのローカルバージョンに対して同じ更新を実施する(例えば、状態を「ON」の値に変更する)。ステップ373では、CSE304は、要求開始AE309に応答し、UPDATE要求が正常に処理されたことを示す。ステップ374では、要求開始AE309は、第1のUPDATEと同じである第2のUPDATE要求を送信する。ステップ375では、CSEは、ステップ368で説明されるものと類似する処理を実施する。CSEは、比較が合致をもたらす(「ON」の更新された値が現在の値と同一である)ことを検出し、UPDATE要求を要求受信AE307に再標的化しないことを決定する。ステップ376では、CSE304は、要求開始AE309からのUPDATE要求が、たとえ要求受信AE307に再標的化されなかったとしても処理されたという事実を追跡するためにそのローカルメタデータを更新する。これは、課金および分析等の目的のために、要求開始AE309の要求履歴を追跡するために有用であり得る。ステップ377では、CSE304は、要求開始AE309に応答し、UPDATE要求が正常に処理されたことを示す。
図18は、鮮度ベースのコンテンツ発見、コンテンツ読み出し、および要求再標的化の概念が、CoREミラーサーバ(すなわち、ミラーサーバ404)の中に統合される、例示的CoREミラーサーバ鮮度ベースのコンテンツ読み出しメッセージフローを図示する。ミラーサーバ404は、鮮度ベースのコンテンツ発見および読み出し要求をサポートし得、ミラーサーバ404は、ミラー化リソースの表現がGET要求で規定される鮮度要件を満たす限り、ミラーサーバ404が、ミラー化リソース表現を使用して、これらの要求にサービス提供し得る。そうでなければ、ミラーサーバ404は、標的リソースの新鮮な表現を取得するための対応するデバイスへのGET要求を開始し得、次いで、それを、以下の図18で捕捉されるプロシージャに図示されるように、オリジナル要求にサービス提供するために使用し得る。本実施形態のための1つの提案されるプロトコルレベル強化は、GET要求が標的化しているリソース表現の要求される鮮度(例えば、日付および時間値)を特定するように、GET要求内で構成され得る(ステップ416に示されるような)新しい鮮度パラメータの定義を含む。鮮度パラメータは、URIクエリ文字列の中に含まれ得るクエリ文字列パラメータとして実現され得る。代替として、鮮度パラメータは、新しいCoAPヘッダオプション(または代替として、それがミラーサーバ404によって使用されている場合はHTTP)として実現され得る。
図18を継続して参照すると、ステップ410では、SEP402は、ミラーサーバ404に登録し、SEP402がローカルに記憶し、それの代わりにミラーサーバ404がミラー化することを所望するサポートされたリソースのリストを提供する。ステップ411では、ミラーサーバ404は、SEP402のリソースのミラー化バージョンを作成し、SEP402によってローカルにホストされる情報のディレクトリ(例えば、各リソースのURI)も維持する。ステップ412では、ミラーサーバ404は、SEP402に応答し、ミラー化リソースのリストを含む。ステップ413−415では、SEP402は、ミラーサーバ404上の1つ以上のミラー化リソースを更新する。各更新は、ミラーサーバ404によって記憶される。SEP402は、コンテンツ(例えば、センサ読み取り値)がSEP402によって生成または捕捉されたときのcontentTimestampも提供し得る。ミラーサーバ404も、コンテンツインスタンスがミラーサーバ404において更新された時間を示すcreationTimeをミラー化リソースに割り当て得る。ステップ416では、クライアント406は、ミラーサーバ404によってホストされるミラー化リソースを読み出すための要求をミラーサーバ404に発行する。要求の中に、時間および日付情報で構成される規定鮮度パラメータが含まれ得る。クライアント406は、それが規定時間および日付以後のコンテンツを要求することを規定するこのパラメータを含み得る。
図18のステップ417では、ミラーサーバ404は、ミラーサーバ404によってホストされるミラー化リソースA(存在する場合)のcreationTime(またはcontentTimestamp)に対して、要求の鮮度パラメータ内の規定時間および日付情報を比較する。この比較から、ミラーサーバ404は、リソースAが利用可能であるかどうかを決定し、該当する場合、クライアント406の鮮度要件を満たすかどうかを決定する。ブロック419内のステップ418では、ミラーサーバ404が規定鮮度要件を満たすミラー化リソースAを見出す場合、リソースAの表現を含む応答をクライアント406に返し得る。この場合、ミラーサーバ404は、SEP402への要求を開始し、リソースAの新鮮な表現を取得する必要がない。
ブロック420は、ミラー化リソースが鮮度要件を満たさないときに起こり、これは、オンデマンドリフレッシュを開始する。ステップ421では、ミラーサーバ404が規定鮮度要件を満たすミラー化リソースAを見出さない場合、随意に、クライアント406がブロックして待機することを要求されない一方、ミラーサーバ404が、SEP402から新鮮なリソースを取得しようとするように、確認応答をクライアント406に返し得る。この確認応答は、要求が受信され、ミラーサーバ404がクライアント406の鮮度選好または要件を満たしたリソースAのローカルにホストされたミラー化バージョンを有していなかったので、依然として処理されていることを示すステータスを含み得る。確認応答は、利用可能になるとき、新鮮なリソースAを受信するためにクライアント406によって使用され得るミラーサーバ404コールバックアドレス(例えば、URI)を含み得る。例えば、クライアント406は、このアドレスに周期的にポーリングし、またはそれを観察し、ミラーサーバ404がSEP402から新鮮なリソースAを取得することができるとき、新鮮なリソースAを受信し、ミラーサーバ404がSEP402から新鮮なリソースAを取得することに失敗した場合、エラー状態を受信し得る。代替として、ミラーサーバ404は、ブロック様式で要求を処理することを選定し得、その場合、このステップでは確認応答をクライアント406に返さないであろう。代わりに、それは、このプロシージャにおけるステップ426まで、クライアント406に応答することを控えるであろう。
図18を継続して参照すると、ステップ422では、ミラーサーバ404は、SEP402への要求を開始し、新鮮なリソースAを要求する。この要求は、GET要求を使用して、SEP402に配信され得る。ミラーサーバ404は、ステップ410におけるSEP402によって規定されたURIを標的化する読み出し要求を開始し得る。この要求は、クライアント406からのオリジナル要求の中の1つと同一のタイムスタンプで構成され得る随意の鮮度パラメータも含み得る。ステップ423では、ステップ422の要求を受信すると、SEP402は、要求を処理し得る。SEP402は、要求の中に存在する場合、規定アドレスおよび鮮度パラメータを分析し、要求されているコンテンツを決定し、ひいては、リソースAを準備し、読み出し応答の中でミラーサーバ404に返し得る。ステップ424では、SEP402は、読み出し応答の中の新鮮なリソースAでミラーサーバ404を更新し得る。ステップ425では、新鮮なリソースAが正常に返された場合、ミラーサーバ404は、新鮮なリソースAのローカルバージョンが、将来の要求にサービス提供するために活用され得るか、または課金および分析等の目的のためにも使用され得るように、それを記憶する。ミラーサーバ404は、随意に、対応するタイムスタンプを割り当て、リソースAがミラーサーバ404の中で作成されたときを記録し得る。ステップ426では、新鮮なリソースAがミラーサーバ404に正常にパブリッシュされた場合、クライアント406に返され、そうでなければ、エラーが代わりに返される。
同様に、ミラーサーバ404は、ミラーサービスがPUTまたはCREATE要求のペイロードを評価し、意味リソース表現がミラー化リソース表現と同一であるかどうかを決定し得る鮮度ベースの要求再標的化をサポートし得る。同一である場合、ミラーサーバ404は、PUTまたはCREATE動作を古いと見なし、要求をデバイスに再標的化しないこともある。同一ではない場合、ミラーサーバ404は、要求を新鮮と見なし、それをデバイスに再標的化してサービス提供し得る。
本明細書に出現する請求項の範囲、解釈、または用途を過度に限定することなく、以下は、とりわけ、要求がM2M/IoT環境で処理される方法に関連付けられる、本明細書に開示される例のうちの1つ以上のものの例示的な技術的効果である。本明細書に開示される例のうちの1つ以上のものの技術的効果は、IoTデバイスへの低減された負荷であり得る。なぜなら、対応するコンテンツ要求アプリがサービス層の中に記憶されたバージョンよりも新鮮であるリソースのバージョンを選好するであろうとき、または、要求開始アプリが要求を特定のデバイスに再標的化することを選好するであろうとき、コンテンツソーシングアプリもしくは要求受信アプリをホストするデバイスが、通常、トリガまたは通知されるからである。本明細書に開示される例のうちの1つ以上のものの別の技術的効果は、従来の実装と比較して、サービス層が、そうでなければコンテンツ要求アプリがアクセスを有さないであろう新鮮なコンテンツへの増加した利用可能性を提供し得ることである。これは、コンテンツ要求アプリがサービス層の中に記憶されるコンテンツのみにアクセスし得るという制限を除去する。これは、より柔軟かつ強力なサービス層フレームを作成し、新鮮なコンテンツを要求するより多くのユースケースをサポートする。本明細書に開示される例のうちの1つ以上のものの別の技術的効果は、従来の実装と比較して、コンテンツ要求アプリまたは要求開始アプリが、サービス層によって現在ホストされていない新鮮なコンテンツにアクセスすること、もしくはその現在の状態と異なる状態にコンテンツを更新することを所望するまで、コンテンツソーシングアプリまたは要求受信アプリをホストするデバイスが、スリープすることを可能にされ得ることである。新鮮なコンテンツの必要性がないことは、デバイスがスリープした状態のままであることを可能にする。
別の技術的効果は、メッセージの数を削減することによって、ネットワーク帯域幅を節約し、おそらく、不必要な要求(例えば、重複要求)を処理していないので、受信デバイス(例えば、図8の作動または他のエンドデバイス)のためのバッテリ寿命を節約することであり得る。例では、同一のドアを開錠しようとしている複数のユーザがいる場合、それらのうちの1人だけがドアを開錠する必要があり、ドアを開錠しようとする他の要求は、実際には重複と見なされることができ、それらは実際には「新鮮」ではないので、フィルタ処理されることができる。そして、それを行うことによって、サービス層は、付加価値を提供する。過去のコマンドのある比較と、要求をアクチュエータタイプデバイスに転送または再標的化するかどうかの決定とがあり得る。
図20は、鮮度ベースのコンテンツ読み出しサービス等の本明細書で議論される方法およびシステムに基づいて生成され得る例示的ディスプレイ(例えば、グラフィカルユーザインターフェース)を図示する。ディスプレイインターフェース901(例えば、タッチスクリーンディスプレイ)は、結果を含む要求処理に関連付けられるテキストをブロック902の中で提供し得る。ブロック902の部分は、選択されたとき、表1から表6のパラメータ等の追加の情報を与え得る。別の例では、本明細書で議論されるステップのうちのいずれかの進捗(例えば、送信されたメッセージまたはステップの成功)が、ブロック902の中に表示され得る。加えて、グラフィカル出力903が、ディスプレイインターフェース901上に表示され得る。グラフィカル出力903は、要求処理におけるデバイスのトポロジ、本明細書で議論される任意の方法またはシステムの進捗のグラフィカル出力等であり得る。ディスプレイインターフェース901は、本明細書で議論されるデバイスから発見されて読み出されるコンテンツの要求される鮮度を構成またはプログラムするために実装され得る。例えば、図6を参照したユースケースでは、医師は、図20に示されるように、医師が、特定の患者の血中インスリン、血圧、血液酸素、および心拍数読み取り値の選好または要求される鮮度を規定することを可能にするアプリケーション121を介して、ユーザインターフェースを提供され得る。
図21Aは、1つ以上の開示される概念がサービス層のための要求処理(例えば、図6−図20および付随する議論)に関連付けられる例示的マシンツーマシン(M2M)、モノのインターネット(IoT)、もしくはモノのウェブ(WoT)通信システム10の略図である。概して、M2M技術は、IoT/WoTのための構築ブロックを提供し、任意のM2Mデバイス、M2Mゲートウェイ、またはM2Mサービスプラットフォームは、IoT/WoTのコンポーネントならびにIoT/WoTサービス層等であり得る。
図21Aに示されるように、M2M/IoT/WoT通信システム10は、通信ネットワーク12を含む。通信ネットワーク12は、固定ネットワーク(例えば、Ethernet(登録商標)、Fiber、ISDN、PLC等)または無線ネットワーク(例えば、WLAN、セルラー等)、もしくは異種ネットワークのネットワークであり得る。例えば、通信ネットワーク12は、音声、データ、ビデオ、メッセージング、ブロードキャスト等のコンテンツを複数のユーザに提供する複数のアクセスネットワークから成り得る。例えば、通信ネットワーク12は、符号分割多重アクセス(CDMA)、時分割多重アクセス(TDMA)、周波数分割多重アクセス(FDMA)、直交FDMA(OFDMA)、単一キャリアFDMA(SC−FDMA)等の1つ以上のチャネルアクセス方法を採用し得る。さらに、通信ネットワーク12は、例えば、コアネットワーク、インターネット、センサネットワーク、工業制御ネットワーク、パーソナルエリアネットワーク、融合個人ネットワーク、衛星ネットワーク、ホームネットワーク、または企業ネットワーク等の他のネットワークを備え得る。
図21Aに示されるように、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(登録商標))、直接無線リンク、および有線を含む、種々のネットワークを介して通信し得る。
図21Bを参照すると、フィールドドメイン内の図示されるM2Mサービス層22(例えば、サービス層204)は、M2Mアプリケーション20(例えば、要求受信アプリ203またはコンテンツソーシングアプリ202)、M2Mゲートウェイデバイス14、およびM2M端末デバイス18、ならびに通信ネットワーク12のためのサービスを提供する。M2Mサービス層22は、所望に応じて、任意の数のM2Mアプリケーション、M2Mゲートウェイデバイス14、M2M端末デバイス18、および通信ネットワーク12と通信し得ることが理解されるであろう。M2Mサービス層22は、1つ以上のサーバ、コンピュータ等によって実装され得る。M2Mサービス層22は、M2M端末デバイス18、M2Mゲートウェイデバイス14、およびM2Mアプリケーション20に適用されるサービス能力を提供する。M2Mサービス層22の機能は、例えば、ウェブサーバとして、セルラーコアネットワークで、クラウドで等、種々の方法で実装され得る。
図示される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つ以上のサーバ、コンピュータ、仮想マシン(例えば、クラウド/計算/記憶ファーム等)等によって実装され得る。
図21Bをさらに参照すると、M2Mサービス層22および22’は、多様なアプリケーションおよびバーティカルが活用することができるサービス配信能力のコアセットを提供する。これらのサービス能力は、M2Mアプリケーション20および20’がデバイスと相互作用し、データ収集、データ分析、デバイス管理、セキュリティ、請求、サービス/デバイス発見等の機能を果たすことを可能にする。本質的に、これらのサービス能力は、これらの機能性を実装する負担をアプリケーションから取り除き、したがって、アプリケーション開発を単純化し、市場に出す費用および時間を削減する。サービス層22および22’は、M2Mアプリケーション20および20’が、サービス層22および22’が提供するサービスと関連して、種々のネットワーク12および12’を通して通信することも可能にする。
いくつかの例では、M2Mアプリケーション20および20’は、本明細書に議論されるように、とりわけ、要求処理を使用して通信する所望のアプリケーションを含み得る。M2Mアプリケーション20および20’は、限定ではないが、輸送、保健および健康、コネクテッドホーム、エネルギー管理、アセット追跡、ならびにセキュリティおよび監視等の種々の業界でのアプリケーションを含み得る。上記のように、システムのデバイス、ゲートウェイ、および他のサーバを横断して起動するM2Mサービス層は、例えば、データ収集、デバイス管理、セキュリティ、請求、場所追跡/ジオフェンシング、デバイス/サービス発見、およびレガシーシステム統合等の機能をサポートし、サービスとしてこれらの機能をM2Mアプリケーション20および20’に提供する。
本願の要求処理方法およびシステムは、サービス層の一部として実装され得る。サービス層(例えば、サービス層204)は、アプリケーションプログラミングインターフェース(API)および下層ネットワーキングインターフェースの組を通して付加価値サービス能力をサポートするミドルウェア層である。M2Mエンティティ(例えば、デバイス、ゲートウェイ、またはハードウェア上に実装されるサービス/プラットフォーム等のM2M機能エンティティ)は、アプリケーションまたはサービスを提供し得る。ETSI M2MおよびoneM2Mは両方とも、とりわけ、本願の要求処理を含み得るサービス層を使用する。ETSI M2Mのサービス層は、サービス能力層(SCL)と称される。SCLは、M2Mデバイス(デバイスSCL(DSCL)と称される)、ゲートウェイ(ゲートウェイSCL(GSCL)と称される)、および/またはネットワークノード(ネットワークSCL(NSCL)と称される)内で実装され得る。oneM2Mサービス層は、共通サービス機能(CSF)(すなわち、サービス能力)の組をサポートする。1つ以上の特定のタイプのCSFの組のインスタンス化は、異なるタイプのネットワークノード(例えば、インフラストラクチャノード、中間ノード、特定用途向けノード)上にホストされ得る共通サービスエンティティ(CSE)と称される。さらに、本願の要求処理方法およびシステムは、本願の要求処理方法およびシステム等のサービスにアクセスするために、サービス指向アーキテクチャ(SOA)および/またはリソース指向アーキテクチャ(ROA)を使用する、M2Mネットワークの一部として実装されることができる。
本明細書で議論されるように、サービス層は、ネットワークサービスアーキテクチャ内の機能層であり得る。サービス層は、典型的には、HTTP、CoAP、またはMQTT等のアプリケーションプロトコル層の上方に位置し、付加価値サービスをクライアントアプリケーションに提供する。サービス層は、インターフェースも、例えば、制御層およびトランスポート/アクセス層等の下位リソース層におけるコアネットワークに提供する。サービス層は、サービス定義、サービス実行時間有効化、ポリシ管理、アクセス制御、およびサービスクラスタリングを含む(サービス)能力または機能性の複数のカテゴリをサポートする。近年、いくつかの業界規格団体、例えば、oneM2Mが、インターネット/ウェブ、セルラー、企業、およびホームネットワーク等の展開へのM2Mタイプのデバイスならびにアプリケーションの統合に関連付けられる課題に対処するように、M2Mサービス層を開発している。M2Mサービス層は、CSEまたはSCLと称され得る、サービス層によってサポートされる上記能力もしくは機能性の集合または組へのアクセスをアプリケーションまたは種々のデバイスに提供することができる。いくつかの例は、種々のアプリケーションによって一般に使用されることができる、セキュリティ、課金、データ管理、デバイス管理、発見、プロビジョニング、および接続性管理を含むが、それらに限定されない。これらの能力または機能性は、M2Mサービス層によって定義されるメッセージフォーマット、リソース構造、およびリソース表現を利用するAPIを介して、そのような種々のアプリケーションに利用可能にされる。CSEまたはSCLは、ハードウェアおよび/またはソフトウェアによって実装され得、それらがそのような能力もしくは機能を使用するために、種々のアプリケーションまたはデバイス(すなわち、そのような機能エンティティ間の機能インターフェース)にエクスポーズされる(サービス)能力もしくは機能性を提供する、機能エンティティである。
図21Cは、例えば、M2M端末デバイス18またはM2Mゲートウェイデバイス14等の例示的M2Mデバイス30の系統図である。図21Cに示されるように、M2Mデバイス30は、プロセッサ32と、送受信機34と、伝送/受信要素36と、スピーカ/マイクロホン38と、キーパッド40と、ディスプレイ/タッチパッド42と、非取り外し可能メモリ44と、取り外し可能メモリ46と、電源48と、全地球測位システム(GPS)チップセット50と、他の周辺機器52とを含み得る。M2Mデバイス30は、開示される主題と一致したままで、先述の要素の任意の副次的組み合わせを含み得ることが理解されるであろう。M2Mデバイス30は、要求処理のための開示されるシステムおよび方法を実施する例示的実装であり得る。コンテンツソーシングアプリ202、サービス層204、コンテンツ要求アプリ206、要求受信アプリ203、要求開始アプリ205、制御アプリ141等は、M2Mデバイス30のような特徴を伴うデバイス上に常駐し得る。コンテンツソーシングアプリ202、サービス層204、コンテンツ要求アプリ206、要求受信アプリ203、要求開始アプリ205、制御アプリ141は、多くの場合、M2M端末デバイス18上に常駐し得る。ミラーサーバ404、サービス層204、CSE304等は、多くの場合、M2Mゲートウェイデバイス14上に常駐し得る。
プロセッサ32は、汎用プロセッサ、特殊目的プロセッサ、従来のプロセッサ、デジタル信号プロセッサ(DSP)、複数のマイクロプロセッサ、DSPコアと関連する1つ以上のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)回路、任意の他のタイプの集積回路(IC)、状態マシン等であり得る。プロセッサ32は、信号符号化、データ処理、電力制御、入出力処理、および/またはM2Mデバイス30が無線環境で動作することを可能にする任意の他の機能性を果たし得る。プロセッサ32は、伝送/受信要素36に結合され得る送受信機34に結合され得る。図21Cは、プロセッサ32および送受信機34を別個のコンポーネントとして描写するが、プロセッサ32および送受信機34は、電子パッケージまたはチップの中にともに統合され得ることが理解されるであろう。プロセッサ32は、アプリケーション層プログラム(例えば、ブラウザ)および/または無線アクセス層(RAN)プログラムならびに/もしくは通信を実施し得る。プロセッサ32は、例えば、アクセス層および/またはアプリケーション層等で、認証、セキュリティキー一致、ならびに/もしくは暗号化動作等のセキュリティ動作を実施し得る。
伝送/受信要素36は、信号をM2Mサービスプラットフォーム22に伝送し、またはM2Mサービスプラットフォーム22から信号を受信するように構成され得る。例えば、伝送/受信要素36は、RF信号を伝送および/または受信するように構成されるアンテナであり得る。伝送/受信要素36は、WLAN、WPAN、セルラー等の種々のネットワークならびにエアインターフェースをサポートし得る。例では、伝送/受信要素36は、例えば、IR、UV、もしくは可視光信号を伝送および/または受信するように構成されるエミッタ/検出器であり得る。さらに別の例では、伝送/受信要素36は、RFおよび光信号の両方を伝送ならびに受信するように構成され得る。伝送/受信要素36は、無線もしくは有線信号の任意の組み合わせを伝送および/または受信するように構成され得ることが理解されるであろう。
加えて、伝送/受信要素36は、単一の要素として図21Cで描写されているが、M2Mデバイス30は、任意の数の伝送/受信要素36を含み得る。より具体的には、M2Mデバイス30は、MIMO技術を採用し得る。したがって、例では、M2Mデバイス30は、無線信号を伝送および受信するための2つ以上の伝送/受信要素36(例えば、複数のアンテナ)を含み得る。
送受信機34は、伝送/受信要素36によって伝送される信号を変調するように、および伝送/受信要素36によって受信される信号を復調するように構成され得る。上記のように、M2Mデバイス30は、マルチモード能力を有し得る。したがって、送受信機34は、M2Mデバイス30が、例えば、UTRAおよびIEEE 802.11等の複数のRATを介して通信することを可能にするための複数の送受信機を含み得る。
プロセッサ32は、非取り外し可能メモリ44および/または取り外し可能メモリ46等の任意のタイプの好適なメモリから情報にアクセスし、その中にデータを記憶し得る。非取り外し可能メモリ44は、ランダムアクセスメモリ(RAM)、読み取り専用メモリ(ROM)、ハードディスク、または任意の他のタイプのメモリ記憶デバイスを含み得る。取り外し可能メモリ46は、サブスクライバ識別モジュール(SIM)カード、メモリスティック、セキュアデジタル(SD)メモリカード等を含み得る。他の例では、プロセッサ32は、サーバまたはホームコンピュータ上等のM2Mデバイス30上に物理的に位置しないメモリから情報にアクセスし、その中にデータを記憶し得る。プロセッサ32は、本明細書に説明される例のうちのいくつかにおける要求処理方法が成功または不成功であるかどうか(例えば、デバイストリガ、鮮度等)に応答して、ディスプレイまたはインジケータ42上の照明パターン、画像、もしくは色を制御する、または別様に要求処理システムおよび方法ならびに関連付けられるコンポーネントのステータスを示すように構成され得る。ディスプレイまたはインジケータ42上の制御照明パターン、画像、もしくは色は、本明細書に図示または議論される図(例えば、図9から図12および図14から図18等)の方法フローもしくはコンポーネントのうちのいずれかのステータスを反映し得る。サービス層関連要求処理のメッセージおよびプロシージャが、本明細書に開示される。メッセージおよびプロシージャは、ユーザが、入力ソース(例えば、スピーカ/マイクロホン38、キーパッド40、またはディスプレイ/タッチパッド42)を介してリソース関連リソースを要求し、ディスプレイ42上に表示され得るものの中でも、サービス層関連要求処理リソースを要求する、構成する、またはクエリを行うためのインターフェース/APIを提供するように拡張され得る。
プロセッサ32は、電源48から電力を受電し得、M2Mデバイス30内の他のコンポーネントへの電力を分配および/または制御するように構成され得る。電源48は、M2Mデバイス30に給電するための任意の好適なデバイスであり得る。例えば、電源48は、1つ以上の乾電池バッテリ(例えば、ニッケルカドミウム(NiCd)、ニッケル亜鉛(NiZn)、ニッケル水素(NiMH)、リチウムイオン(Li−ion)等)、太陽電池、燃料電池等を含み得る。
プロセッサ32は、M2Mデバイス30の現在の場所に関する場所情報(例えば、経度および緯度)を提供するように構成されるGPSチップセット50にも結合され得る。M2Mデバイス30は、本明細書で開示される情報と一致したままで、任意の好適な場所決定方法を介して場所情報を獲得し得ることが理解されるであろう。
プロセッサ32は、追加の特徴、機能性、または有線もしくは無線接続性を提供する1つ以上のソフトウェアもしくはハードウェアモジュールを含み得る他の周辺機器52にさらに結合され得る。例えば、周辺機器52は、加速度計、バイオメトリック(例えば、指紋)センサ等の種々のセンサ、e−コンパス、衛星送受信機、センサ、デジタルカメラ(写真またはビデオ用)、ユニバーサルシリアルバス(USB)ポートまたは他の相互接続インターフェース、振動デバイス、テレビ送受信機、ハンズフリーヘッドセット、Bluetooth(登録商標)モジュール、周波数変調(FM)無線ユニット、デジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザ等を含み得る。
伝送/受信要素36は、センサ、消費者電子機器、スマートウォッチまたはスマート衣類等のウェアラブルデバイス、医療またはe−ヘルスデバイス、ロボット、産業機器、ドローン、車、トラック、電車、または飛行機等の車両等の他の装置もしくはデバイスで具現化され得る。伝送/受信要素36は、周辺機器52のうちの1つを備え得る相互接続インターフェース等の1つ以上の相互接続インターフェースを介して、そのような装置もしくはデバイスの他のコンポーネント、モジュール、またはシステムに接続し得る。
図21Dは、例えば、図21Aおよび図21BのM2Mサービスプラットフォーム22が実装され得る例示的なコンピューティングシステム90のブロック図である。コンピューティングシステム90(例えば、M2M端末デバイス18またはM2Mゲートウェイデバイス14)は、コンピュータまたはサーバを備え得、主に、そのような命令が記憶またはアクセスされる手段にかかわらず、コンピュータ読み取り可能な命令によって制御され得る。そのようなコンピュータ読み取り可能な命令は、コンピューティングシステム90を稼働させるように、中央処理装置(CPU)91内で実行され得る。多くの公知のワークステーション、サーバ、およびパーソナルコンピュータでは、中央処理装置91は、マイクロプロセッサと呼ばれる単一チップCPUによって実装される。他のマシンでは、中央処理装置91は、複数のプロセッサを備え得る。コプロセッサ81は、追加の機能を果たすか、またはCPU91を支援する、主要CPU91とは異なる随意のプロセッサである。CPU91および/またはコプロセッサ81は、コンテンツの鮮度、再標的化、ならびにトリガ等の要求処理のための開示されるシステムおよび方法に関連するデータを受信、生成、ならびに処理し得る。
動作時、CPU91は、命令をフェッチ、復号、および実行し、コンピュータの主要データ転送パスであるシステムバス80を介して、情報を他のリソースへ、およびそこから転送する。そのようなシステムバスは、コンピューティングシステム90内のコンポーネントを接続し、データ交換のための媒体を定義する。システムバス80は、典型的には、データを送信するためのデータラインと、アドレスを送信するためのアドレスラインと、インタラプトを送信するため、およびシステムバスを動作させるための制御ラインとを含む。そのようなシステムバス80の例は、PCI(周辺コンポーネント相互接続)バスである。
システムバス80に結合されるメモリデバイスは、ランダムアクセスメモリ(RAM)82および読み取り専用メモリ(ROM)93を含む。そのようなメモリは、情報が記憶されて読み出されることを可能にする回路を含む。ROM93は、概して、容易に修正されることができない、記憶されたデータを含む。RAM82内に記憶されたデータは、CPU91または他のハードウェアデバイスによって読み取られること、もしくは変更されることができる。RAM82および/またはROM93へのアクセスは、メモリコントローラ92によって制御され得る。メモリコントローラ92は、命令が実行されると、仮想アドレスを物理的アドレスに変換するアドレス変換機能を提供し得る。メモリコントローラ92は、システム内のプロセスを分離し、ユーザプロセスからシステムプロセスを分離するメモリ保護機能も提供し得る。したがって、第1のモードで起動するプログラムは、それ自身のプロセス仮想アドレス空間によってマップされるメモリのみにアクセスすることができ、プロセス間のメモリ共有が設定されていない限り、別のプロセスの仮想アドレス空間内のメモリにアクセスすることができない。
加えて、コンピューティングシステム90は、CPU91からプリンタ94、キーボード84、マウス95、およびディスクドライブ85等の周辺機器に命令を通信する責任がある、周辺機器コントローラ83を含み得る。
ディスプレイコントローラ96によって制御されるディスプレイ86は、コンピューティングシステム90によって生成される視覚出力を表示するために使用される。そのような視覚出力は、テキスト、グラフィックス、動画グラフィックス、およびビデオを含み得る。ディスプレイ86は、CRTベースのビデオディスプレイ、LCDベースのフラットパネルディスプレイ、ガスプラズマベースのフラットパネルディスプレイ、またはタッチパネルを伴って実装され得る。ディスプレイコントローラ96は、ディスプレイ86に送信されるビデオ信号を生成するために要求される電子コンポーネントを含む。
さらに、コンピューティングシステム90は、図21Aおよび図21Bのネットワーク12等の外部通信ネットワークにコンピューティングシステム90を接続するために使用され得る、ネットワークアダプタ97を含み得る。
本明細書に説明されるシステム、方法、およびプロセスのうちのいずれかまたは全ては、コンピュータ読み取り可能な記憶媒体上に記憶されたコンピュータ実行可能命令(すなわち、プログラムコード)の形態で具現化され得、その命令は、例えば、コンピュータ、サーバ、M2M端末デバイス、M2Mゲートウェイデバイス等のマシンによって実行されると、本明細書に説明されるシステム、方法、およびプロセスを実施ならびに/もしくは実装することが理解される。具体的には、上記で説明されるステップ、動作、または機能のうちのいずれかは、そのようなコンピュータ実行可能命令の形態で実装され得る。コンピュータ読み取り可能な記憶媒体は、情報の記憶のための任意の方法または技術で実装される揮発性および不揮発性媒体、取り外し可能および非取り外し可能媒体の両方を含むが、そのようなコンピュータ読み取り可能な記憶媒体は、それ自体が信号を含まない。本明細書の説明から明白であるように、記憶媒体は、法定主題であると解釈されるべきである。コンピュータ読み取り可能な記憶媒体は、RAM、ROM、EEPROM、フラッシュメモリまたは他のメモリ技術、CD−ROM、デジタル多用途ディスク(DVD)または他の光学ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置もしくは他の磁気記憶デバイス、または所望の情報を記憶するために使用されることができ、かつコンピュータによってアクセスされることができる、任意の他の物理媒体を含む。
図に例証されるように、本開示の主題、すなわち、サービス層内の要求処理の好ましい方法、システム、または装置を説明する際に、具体的用語が、明確にするために採用される。しかしながら、請求される主題は、そのように選択された具体的用語に限定されることを意図せず、各具体的要素は、類似目的を達成するように同様に動作する、全ての技術的均等物を含むことを理解されたい。
本明細書に説明される種々の技法は、ハードウェア、ファームウェア、ソフトウェア、もしくは適切である場合、それらの組み合わせに関連して実装され得る。そのようなハードウェア、ファームウェア、およびソフトウェアは、通信ネットワークの種々のノードに位置する装置の中に常駐し得る。装置は、本明細書に説明される方法を達成するように、単独で、または互いと組み合わせて動作し得る。本明細書で使用されるように、「装置」、「ネットワーク装置」、「ノード」、「デバイス」、および「ネットワークノード」等という用語は、同義的に使用され得る。加えて、「または」という言葉の使用は、概して、本明細書で別様に適用されない限り、包含的に使用される。
新鮮なコンテンツは、とりわけ、時間ベースまたは状態ベースであり得る。例えば、時間ベースの新鮮なコンテンツは、コンテンツ読み出しまたは発見要求の中に含まれる鮮度パラメータで規定される日付および時間よりも新しい作成時間を有するサービス層ホスト型コンテンツに関連付けられ得る。状態ベースの新鮮なコンテンツは、その現在の意味状態と異なる意味状態にサービス層ホスト型コンテンツを更新する要求に関連付けられ得る。
とりわけ、本明細書に説明されるような方法、システム、および装置は、サービス層のためのコンテンツ(サービス層内の要求処理)の鮮度を管理する手段を提供し得る。方法、システム、コンピュータ読み取り可能な記憶媒体、または装置は、要求アプリケーションからメッセージを受信する手段であって、メッセージは、サービスに関連付けられたコンテンツおよびービスに関連付けられるコンテンツのための鮮度期間を取得するための要求を備えている、手段と、メッセージの中の要件に基づいて、コンテンツの鮮度期間が許容閾値期間外であることを決定する手段と、コンテンツの鮮度期間が許容閾値期間外であることを決定するステップに応答して、1)非ブロック応答を要求アプリケーションに送信し、2)ポイントオブコンタクト情報に基づいて、要求メッセージをコンテンツソースアプリケーションに送信し、許容閾値内であるサービスの更新されたコンテンツを取得する手段とを有する。方法、システム、コンピュータ読み取り可能な記憶媒体、または装置は、複数の他のサービスに関連付けられたコンテンツのための鮮度期間と共にサービスに関連付けられたコンテンツのための鮮度期間の分析に基づいて、コンテンツがサービス層デバイスによって更新される必要があるスケジュールを決定する手段を有する。コンテンツソースアプリケーションへの要求メッセージは、コンテンツがサービス層デバイスによって更新される必要があるスケジュールを備え得る。非ブロック応答は、コンテンツが利用可能になったときにサブスクライブして鮮度期間内のコンテンツを受信するために要求アプリケーションによって使用されるコールバックアドレスを備え得る。コンテンツソースアプリケーションへの要求メッセージは、鮮度期間に対応する作成後パラメータを備え得る。方法、システム、コンピュータ読み取り可能な記憶媒体、または装置は、複数の他のメッセージの中で関連付けられるコンテンツのための鮮度期間と共にメッセージの中のコンテンツのための鮮度期間の分析に基づいて、コンテンツが装置によって更新される必要があるスケジュールを決定する手段を有する。ポイントオブコンタクト情報は、ユニフォームリソース識別子を備え得る。この段落内の全ての組み合わせ(ステップの除去または追加を含む)は、発明を実施するための形態の他の部分と一致する様式で考慮される。
本明細書は、最良の様態を含む、本発明を開示するために、また、当業者が、任意のデバイスまたはシステムを作製して使用することと、任意の組み込まれた方法を行うこととを含む、本発明を実践することを可能にするために、例を使用する。本発明の特許性のある範囲は、請求項によって定義され、当業者に想起される他の例を含み得る(例えば、本明細書に開示される例示的方法の間でステップを省略する、ステップを組み合わせる、またはステップを追加する)。そのような他の例は、請求項の文字通りの言葉とは異ならない構造要素を有する場合、または請求項の文字通りの言葉とのごくわずかな差異を伴う同等の構造要素を含む場合、請求項の範囲内であることを意図している。