特許 7486424 ＢＬＵＥＴＯＯＴＨ（登録商標）ベースのＩＰＶ６低電力ネットワーキング

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-05-09

(45)【発行日】2024-05-17

(54)【発明の名称】ＢＬＵＥＴＯＯＴＨ（登録商標）ベースのＩＰＶ６低電力ネットワーキング

(51)【国際特許分類】

   H04W 28/06 20090101AFI20240510BHJP

   H04W 88/04 20090101ALI20240510BHJP

   H04W 52/02 20090101ALI20240510BHJP

   H04W 84/10 20090101ALI20240510BHJP

【ＦＩ】

H04W28/06 110

H04W88/04

H04W52/02

H04W84/10 110

【請求項の数】 16

(21)【出願番号】P 2020540626

(86)(22)【出願日】2019-01-24

(65)【公表番号】

(43)【公表日】2021-05-13

(86)【国際出願番号】 EP2019051673

(87)【国際公開番号】W WO2019145379

(87)【国際公開日】2019-08-01

【審査請求日】2022-01-21

(31)【優先権主張番号】62/622,982

(32)【優先日】2018-01-29

(33)【優先権主張国・地域又は機関】US

(73)【特許権者】

【識別番号】590000248

【氏名又は名称】コーニンクレッカ フィリップス エヌ ヴェ

【氏名又は名称原語表記】Ｋｏｎｉｎｋｌｉｊｋｅ Ｐｈｉｌｉｐｓ Ｎ．Ｖ．

【住所又は居所原語表記】Ｈｉｇｈ Ｔｅｃｈ Ｃａｍｐｕｓ ５２， ５６５６ ＡＧ Ｅｉｎｄｈｏｖｅｎ，Ｎｅｔｈｅｒｌａｎｄｓ

(74)【代理人】

【識別番号】110001690

【氏名又は名称】弁理士法人Ｍ＆Ｓパートナーズ

(72)【発明者】

【氏名】ディーズ ウォルター

(72)【発明者】

【氏名】ヴァン デ ラール フランシスカス アントニウス マリア

【審査官】青木 健

(56)【参考文献】

【文献】特表２０１７－５２１０１６（ＪＰ，Ａ）

【文献】特開２０１３－０１７１６４（ＪＰ，Ａ）

【文献】特開２０１７－１６３１８６（ＪＰ，Ａ）

【文献】特開２０１５－１１５７９４（ＪＰ，Ａ）

【文献】特開２０１５－０１２５７０（ＪＰ，Ａ）

【文献】特表２００５－５０９３８１（ＪＰ，Ａ）

【文献】特開２００６－０８６６０５（ＪＰ，Ａ）

【文献】特表２００４－５１７５１４（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｈ０４Ｗ ４／００ － ９９／００

Ｈ０４Ｂ ７／２４ － ７／２６

(57)【特許請求の範囲】

【請求項1】

レイヤ２ＭＡＣヘッダとペイロードとを各々含むレイヤ２ＭＡＣフレームとして構築されたメッセージを採用するワイヤレス通信プロトコルを介して通信するための無線機と、
電子回路とを備える、ワイヤレスデバイスであって、
前記電子回路は、
（ｉ）前記ワイヤレスデバイスが、前記無線機を介してリレーデバイスに、ＩＰｖ６パケットヘッダとレイヤ２ＭＡＣフレームの前記ペイロード内にカプセル化された上位レイヤプロトコルデータユニットとを各々含むメッセージを送信する第１のモード、及び（ｉｉ）前記ワイヤレスデバイスが、前記無線機を介して前記リレーデバイスに、ＩＰｖ６ヘッダを含むことなしにレイヤ２ＭＡＣフレームの前記ペイロード内にカプセル化された上位レイヤプロトコルデータユニットを各々含むメッセージを送信する第２のモードで動作することと、
ヘッダ挿入サービスを提供する前記リレーデバイスに前記無線機を介してヘッダ情報メッセージを送信することを含む動作によって、前記第１のモードから前記第２のモードに遷移することであって、前記ヘッダ情報メッセージが、少なくとも、ＩＰｖ６ソースアドレスを構築するために使用されるべき前記ワイヤレスデバイスのアドレス又はＩＰｖ６宛先アドレスを構築するために使用されるべきホストデバイスのアドレスを含み、前記第１のモードから前記第２のモードに遷移することは、前記第１のモードから前記第２のモードへの前記遷移をトリガするメッセージを前記リレーデバイスから受信することをさらに含む動作による、遷移することと
を前記ワイヤレスデバイスが行うようにプログラムされた、ワイヤレスデバイス。

【請求項2】

前記ワイヤレスデバイスが前記リレーデバイスから前記リレーデバイスとは異なる他のリレーデバイスにローミングすることに応答して、前記第２のモードから前記第１のモードに遷移することをさらに行う、請求項１に記載のワイヤレスデバイス。

【請求項3】

前記他のリレーデバイスにローミングすると、前記遷移中に前記ワイヤレスデバイスのためのメッセージを前記リレーデバイスが受信したかどうかを、前記他のリレーデバイスを介して質問することをさらに行う、請求項２に記載のワイヤレスデバイス。

【請求項4】

前記他のリレーデバイスにローミングすると、前記ワイヤレスデバイスのためのメッセージを前記他のリレーデバイスを介して再送するようにサーバに依頼することをさらに行う、請求項２に記載のワイヤレスデバイス。

【請求項5】

リレーデバイス間でローミングすることと、前記ワイヤレスデバイスが接続されるリレーデバイスが前記ヘッダ挿入サービスを提供するかどうかに応じて、前記第１のモードと前記第２のモードとの間で切り替わることとをさらに行う、請求項１から４のいずれか一項に記載のワイヤレスデバイス。

【請求項6】

前記無線機を介して前記リレーデバイスと証明書を交換することと、交換された前記証明書に基づいて前記リレーデバイスが共有秘密の知識を有すると前記ワイヤレスデバイスが決定した場合、前記第１のモードから前記第２のモードに遷移することとをさらに行う、請求項１から５のいずれか一項に記載のワイヤレスデバイス。

【請求項7】

レイヤ２ＭＡＣヘッダとペイロードとを各々含むレイヤ２ＭＡＣフレームとして構築されたメッセージを採用するワイヤレス通信プロトコルを介して通信するための無線機と、
電子回路とを備える、リレーデバイスであって、
前記電子回路は、
ヘッダ挿入サービスを実行することであって、前記ヘッダ挿入サービスでは、前記リレーデバイスが、前記無線機を介してワイヤレスデバイスから、ＩＰｖ６ヘッダを含むことなしにレイヤ２ＭＡＣフレームの前記ペイロード内にカプセル化された上位レイヤプロトコルデータユニットを各々含むメッセージ（Ｍ０、．．．、Ｍｎ）を受信し、前記ワイヤレスデバイスから受信された前記メッセージ中にヘッダ情報を挿入し、完全なヘッダをもつ前記メッセージをメッセージ（Ｍ０’、．．．、Ｍｎ’）として再送信する、実行することと、
前記ワイヤレスデバイスからヘッダ情報メッセージを受信し、前記リレーデバイスにおいて前記ヘッダ情報メッセージ中に含まれているヘッダ情報を前記ヘッダ情報として使用することと
を前記リレーデバイスが行うようにプログラムされ、
前記リレーデバイスが、さらに、前記ワイヤレスデバイスに対して前記ヘッダ挿入サービスを実行する前記リレーデバイスの利用可能性を、前記ワイヤレスデバイスに通知するためのメッセージであって、前記ワイヤレスデバイスが、前記リレーデバイスに対して、ＩＰｖ６パケットヘッダとレイヤ２ＭＡＣフレームの前記ペイロード内にカプセル化された上位レイヤプロトコルデータユニットとを各々含むメッセージを送信する第１のモードから、前記リレーデバイスに対して、ＩＰｖ６ヘッダを含むことなしにレイヤ２ＭＡＣフレームの前記ペイロード内にカプセル化された上位レイヤプロトコルデータユニットを各々含むメッセージを送信する第２のモードに遷移することをトリガするメッセージを、前記ワイヤレスデバイスに送信する、リレーデバイス。

【請求項8】

請求項１から６のいずれか一項に記載のワイヤレスデバイスと、
請求項７に記載のリレーデバイスと
を備える、システム。

【請求項9】

前記メッセージ（Ｍ０、．．．、Ｍｎ）が、前記ワイヤレスデバイスによって暗号化され、前記リレーデバイスが、前記メッセージ（Ｍ０、．．．、Ｍｎ）とまったく同じコンテンツを復号／再暗号化なしに前記メッセージ（Ｍ０’、．．．、Ｍｎ’）内に含める、請求項７に記載のリレーデバイス。

【請求項10】

前記メッセージ（Ｍ０、．．．、Ｍｎ）が、前記ワイヤレスデバイスによって暗号化され、前記リレーデバイスが、前記メッセージ（Ｍ０、．．．、Ｍｎ）とまったく同じコンテンツを復号／再暗号化なしに前記メッセージ（Ｍ０’、．．．、Ｍｎ’）内に含める、請求項８に記載のシステム。

【請求項11】

前記電子回路は、さらに、
前記ワイヤレスデバイスからサーバへのメッセージを中継し、前記サーバから前記ワイヤレスデバイスへのメッセージを中継することと、
前記ワイヤレスデバイスからメッセージを受信することであって、前記メッセージは、前記サーバから前記リレーデバイスにおいて受信されたあるメッセージタイプのメッセージが、低減されたレートで前記ワイヤレスデバイスに送られるべきであるという要求を含み、前記メッセージが、前記あるメッセージタイプのメッセージを検出するための検出基準をさらに含む、受信することと、
前記サーバから受信された前記あるメッセージタイプのメッセージをフィルタ処理するために、前記検出基準を適用することと、
前記低減されたレートで前記無線機を介して前記ワイヤレスデバイスに、前記あるメッセージタイプのフィルタ処理された前記メッセージをフォワーディングすることとを前記リレーデバイスが行うようにプログラムされた、請求項７に記載のリレーデバイス。

【請求項12】

前記検出基準が、メッセージサイズ基準と、ハッシュ若しくはビットパターン基準とのうち、少なくとも一方を備える、請求項１１に記載のリレーデバイス。

【請求項13】

前記あるメッセージタイプが肯定応答メッセージタイプであり、前記検出基準が肯定応答検出基準を備え、
オプションで、肯定応答が、前記サーバによって送られたエンドツーエンド暗号化アプリケーションレベルトランスポート肯定応答である、請求項１１又は１２に記載のリレーデバイス。

【請求項14】

前記メッセージ中に含まれる前記低減されたレートは、前記リレーデバイスが、前記肯定応答検出基準に適合するサーバから受信された肯定応答を廃棄するレート又は最大時間を備え、
前記リレーデバイスが、廃棄された肯定応答を前記ワイヤレスデバイスにフォワーディングしないことによって、前記低減されたレートで前記ワイヤレスデバイスに、フィルタ処理された前記肯定応答をフォワーディングする、請求項１３に記載のリレーデバイス。

【請求項15】

レイヤ２ＭＡＣヘッダとペイロードとを各々含むレイヤ２ＭＡＣフレームとして構築されたメッセージを採用するワイヤレス通信プロトコルを介して通信するように、ワイヤレスデバイスの無線機を動作させるステップであって、前記動作させるステップが第１のモードでのものであり、前記第１のモードでは、前記ワイヤレスデバイスが、前記無線機を介してリレーデバイスに、ＩＰｖ６パケットヘッダとレイヤ２ＭＡＣフレームの前記ペイロード内にカプセル化された上位レイヤプロトコルデータユニットとを各々含むメッセージを送信する、動作させるステップと、
ヘッダ挿入サービスを提供するリレーデバイスに前記無線機を介してヘッダ情報メッセージを送信するステップであって、前記ヘッダ情報メッセージが、少なくとも、ＩＰｖ６ソースアドレスを構築するために使用されるべき前記ワイヤレスデバイスのアドレス又はＩＰｖ６宛先アドレスを構築するために使用されるべきホストデバイスのアドレスを含む、送信するステップと、
前記ヘッダ情報メッセージを送信するステップの後に、前記第１のモードから第２のモードに前記ワイヤレスデバイスを遷移させるステップであって、前記第２のモードでは、前記ワイヤレスデバイスが、前記無線機を介して前記リレーデバイスに、ＩＰｖ６ヘッダを含むことなしにレイヤ２ＭＡＣフレームの前記ペイロード内にカプセル化された上位レイヤプロトコルデータユニットを各々含むメッセージ（Ｍ０、．．．、Ｍｎ）を送信する、遷移させるステップと
を有する、方法であって、
前記ヘッダ情報メッセージを送信するステップと、前記第１のモードから前記第２のモードに遷移させるステップとをトリガするメッセージを前記ワイヤレスデバイスにおいて前記リレーデバイスから受信するステップ
をさらに有する、方法。

【請求項16】

前記リレーデバイスにおいて、前記ワイヤレスデバイスから前記ヘッダ情報メッセージを受信するステップであって、前記ヘッダ情報メッセージがヘッダ情報を含む、受信するステップと、
前記リレーデバイスにおいて、ヘッダ挿入サービスを実行するステップであって、前記ヘッダ挿入サービスでは、前記リレーデバイスが、前記無線機を介して前記ワイヤレスデバイスから前記メッセージ（Ｍ０、．．．、Ｍｎ）を受信し、前記メッセージが、レイヤ２ＭＡＣヘッダとペイロードとを各々含むレイヤ２ＭＡＣフレームとして構築され、各メッセージが、ＩＰｖ６ヘッダを含むことなしにレイヤ２ＭＡＣフレームの前記ペイロード内にカプセル化された上位レイヤプロトコルデータユニットをさらに含む、実行するステップと、
前記リレーデバイスによって、前記ワイヤレスデバイスから受信された前記メッセージ中に前記ヘッダ情報を挿入するステップと、
完全なヘッダをもつ前記メッセージをメッセージ（Ｍ０’、．．．、Ｍｎ’）としてサーバに再送信するステップと
をさらに有する、請求項１５に記載の方法。

【発明の詳細な説明】

【技術分野】

【0001】

[0001] 本出願は、２０１８年１月２９日に出願された「ＢＬＵＥＴＯＯＴＨ（登録商標） ＩＰＶ６ ＬＯＷ ＰＯＷＥＲ」と題する米国仮出願第６２／６２２，９８２号の利益を主張する。２０１８年１月２９日に出願された米国仮出願第６２／６２２，９８２号は、その全体が参照により本明細書に組み込まれる。

【0002】

[0002] 以下は、一般に、ワイヤレス医療センサー、低電力ワイヤレスセンサー、モバイルセンサー、及び他の同様の適用例に関する。

【背景技術】

【0003】

[0003] Ｂｌｕｅｔｏｏｔｈ（登録商標）低エネルギー（ＢＬＥ）通信プロトコルは、低電力適用例を対象とするＢｌｕｅｔｏｏｔｈ（登録商標）規格のサブセットである。ＢＬＥについてオプションの範囲及びデータ長の拡張をもつ最新のＢｌｕｅｔｏｏｔｈ（登録商標）－５規格により、ＢＬＥは、ホームオートメーション及びヘルスケアなどの適用領域におけるモノのインターネット（ＩｏＴ）デバイス及び健康のインターネット（ＩｏＨ）デバイスのより好適な候補になる。また、Ｂｌｕｅｔｏｏｔｈ（登録商標）低エネルギートランスポート上でデバイス間でＩＰｖ６パケットを交換することのサポートを可能にするために、ＩＥＴＦ仕様ＲＦＣ７６６８とともに、インターネットプロトコルサポートプロファイル（ＩＰＳＰ）仕様が公開された。これにより、ＢＬＥデバイスは、デバイスが利用可能な新しいデータを有するときはいつでもデータを送ること（及びその起動スケジュールを相応に調整すること）を自律的に決めるので、デバイス上でサポートされるために特定の一般的な属性（ＧＡＴＴ）プロファイルに依拠することなしに、及び、ＧＡＴＴサーバとして働くデバイスからデータをフェッチするためにＧＡＴＴクライアントに依拠する必要なしに、ＵＤＰ／ＩＰ上の制約付きアプリケーションプロトコル（ＣｏＡＰ）、ＴＣＰ／ＩＰ上のメッセージキューイングテレメトリトランスポート（ＭＱＴＴ）、又はＴＣＰ／ＩＰ上のハイパーテキスト転送プロトコル（ＨＴＴＰ）など、一般的なＩＰレイヤ通信プロトコルを実現することが可能になる。また、それにより、各デバイスは、ＢＬＥパーソナルエリアネットワークがワイドエリアネットワークに拡張することを可能にする、一般的なアドレス指定方式を有することが可能になる。

【発明の概要】

【発明が解決しようとする課題】

【0004】

[0004] モバイル医療デバイスの領域では、デバイスが１回のデバイスバッテリー充電で動作することができる時間を延長するように、したがって、蓄積された電力の消耗によるデバイス障害の可能性を低減するように、そのようなデバイスが低電力消費で動作することに、特に関心がある。ＢＬＥなどの技術は、この点について有利であるが、いくつかのモバイル医療デバイスにおける目的は、１回のバッテリー充電で、拡張された期間、例えば数週間又はより長い期間にわたって動作することである。

【0005】

[0005] 以下は、いくつかの改善を開示する。

【課題を解決するための手段】

【0006】

[0006] 本明細書で開示されるいくつかの例示的な実施形態では、ワイヤレスデバイスが、レイヤ２ＭＡＣヘッダとペイロードとを各々含むレイヤ２ＭＡＣフレームとして構築されたメッセージを採用するワイヤレス通信プロトコルを介して通信するための無線機を備える。ワイヤレスデバイスは、（ｉ）ワイヤレスデバイスが、無線機を介して、ＩＰｖ６パケットヘッダとレイヤ２ＭＡＣフレームのペイロード内にカプセル化された上位レイヤプロトコルデータユニットとを各々含むメッセージ（Ｎ０、．．．、Ｎｎ）を送信する、第１のモード、及び（ｉｉ）ワイヤレスデバイスが、無線機を介して、ＩＰｖ６ヘッダを含むことなしにレイヤ２ＭＡＣフレームのペイロード内にカプセル化された上位レイヤプロトコルデータユニットを各々含むメッセージ（Ｍ０、．．．、Ｍｎ）を送信する、第２のモードで動作するように構成される。ワイヤレスデバイスは、ヘッダ挿入サービス（Ｉ）を提供するリレーデバイス（Ｔ）に無線機（Ｒ）を介してヘッダ情報メッセージ（Ｘ）を送信することを含む動作によって、第１のモードから第２のモードに遷移することであって、ヘッダ情報メッセージが、少なくとも、ＩＰｖ６ソースアドレスを構築するために使用されるべきワイヤレスデバイスのアドレス（Ａ）又はＩＰｖ６宛先アドレスを構築するために使用されるべきホストデバイスのアドレス（Ｄ）を含む、遷移することを行うようにさらに構成される。いくつかの実施形態では、ワイヤレスデバイスは、リレーデバイスから、第１のモードから第２のモードへの遷移をトリガするメッセージを受信することをさらに含む動作によって、第１のモードから第２のモードに遷移するようにさらに構成される。

【0007】

[0007] 本明細書で開示されるいくつかの例示的な実施形態では、リレーデバイスが、レイヤ２ＭＡＣヘッダとペイロードとを各々含むレイヤ２ＭＡＣフレームとして構築されたメッセージを採用するワイヤレス通信プロトコルを介して通信するための無線機を備える。リレーデバイスは、ヘッダ挿入サービスを実行することであって、ヘッダ挿入サービスでは、リレーデバイスが、無線機を介してワイヤレスデバイスから、ＩＰｖ６ヘッダを含むことなしにレイヤ２ＭＡＣフレームのペイロード内にカプセル化された上位レイヤプロトコルデータユニットを各々含むメッセージ（Ｍ０、．．．、Ｍｎ）を受信し、ワイヤレスデバイスから受信されたメッセージ中にヘッダ情報（Ａ’）を挿入し、完全なヘッダをもつメッセージをメッセージ（Ｍ０’、．．．、Ｍｎ’）として再送信する、実行することを行うように構成される。リレーデバイスは、ワイヤレスデバイスからヘッダ情報メッセージを受信し、リレーデバイスにおいてヘッダ情報メッセージ中に含まれているヘッダ情報をヘッダ情報として記憶するようにさらに構成される。リレーデバイスは、リレーデバイスの、ワイヤレスデバイスに対してヘッダ挿入サービスを実行する利用可能性を、ワイヤレスデバイスに通知するためのメッセージを、ワイヤレスデバイスに送信するようにさらに構成される。

【0008】

[0008] 本明細書で開示されるいくつかの例示的な実施形態では、システムが、２つの直前の段落に記載されているワイヤレスデバイスとリレーデバイスとを備える。

【0009】

[0009] 本発明は、様々な構成要素及び構成要素の配置の形態、並びに様々なステップ及びステップの配置の形態をとる。図面は、好ましい実施形態を示すためのものにすぎず、本発明を限定するものと解釈されるべきではない。

【図面の簡単な説明】

【0010】

【図1】[0010] ワイヤレス医療デバイスの電力消費を低減するためにヘッダ挿入デバイスとともに動作する低電力ワイヤレス医療デバイスの一実施形態を概略的に示す図である。

【図2】[0011] 本明細書で説明される通信方法を概略的にフローチャートに描く図である。

【図3】本明細書で説明される通信方法を概略的にフローチャートに描く図である。

【図4】本明細書で説明される通信方法を概略的にフローチャートに描く図である。

【図5】本明細書で説明される通信方法を概略的にフローチャートに描く図である。

【図6】本明細書で説明される通信方法を概略的にフローチャートに描く図である。

【図7】本明細書で説明される通信方法を概略的にフローチャートに描く図である。

【図8】[0012]ワイヤレス医療デバイスの電力消費を低減するためにヘッダ挿入デバイスとともに動作する低電力ワイヤレス医療デバイスの一実施形態を概略的に示す図である。医療デバイスは、ＢＬＥ無線機と、ＩＰＳＳのサポートをもつＧＡＰ周辺（ＧＡＰ ｐｅｒｉｐｈｅｒａｌ）として動作する機能とを搭載し、ヘッダ挿入デバイスは、ＢＬＥ無線機と、ＩＰＳＰのサポートをもつＧＡＰ中央（ＧＡＰ ｃｅｎｔｒａｌ）として動作する機能とを搭載したゲートウェイデバイスである。

【発明を実施するための形態】

【0011】

[0013] ＩＰｖ６アドレスは、１２８ビット長である。あらゆるＩＰｖ６フレームのヘッダが、ペイロード長、バージョン及びホップ限界など、いくつかの他のヘッダ属性とともに、ソースアドレス及び宛先アドレスを含むので、各ヘッダは、最小で４０バイト長である。さらに、ＵＤＰ又はＴＣＰトランスポートプロトコルヘッダが同様に含まれる必要がある場合、これは、それぞれさらなる追加の８バイト、２０バイトを意味する。これは、特に、データペイロードが通常極めて小さい（例えば、摂氏／華氏での温度読み、毎分脈拍での心拍数）ＢＬＥセンサーデバイスの場合、ＢＬＥパケットデータユニット（ＰＤＵ）のペイロードにおいて大きいオーバーヘッドを生じる。したがって、ＲＦＣ７６６８は、すべてのヘッダが、ＲＦＣ６２８２文献で説明される符号化フォーマットに従って圧縮されなければならないことを必要とする。境界ルータ（或いは、スマートフォン、タブレット、又はベッドサイドモニタなどの他の好適なデバイス）が、その宛先にフレームをフォワーディングする前に、圧縮されたヘッダを完全なヘッダに拡張する。これは、ＩＰヘッダ圧縮（ＩＰＨＣ）フォーマットとして知られており、ＩＰｖ６ヘッダサイズを著しく低減する。ＩＰｖ６アドレスは、６４ビットネットワークアドレス（プレフィックス）と６４ビットインターフェースアドレス（ＩＩＤ）とからなる。一般に、ＩＰｖ６アドレス空間はグローバルに（順に）、レジストリ、ＩＳＰプレフィックス、サイトプレフィックス、サブネットプレフィックス、及びインターフェースＩＤに分割される。一般に、単一のサブネットは、多数のデバイスをカバーするために十分なアドレス空間を有し（例えば２^６４）、任意の大きい企業又は組織をカバーし、任意のデバイスに一意のグローバルアドレスを割り当てるのに十分であり、増大する余地があるべきである。大きい病院は、単一のサブネットによって容易にカバーされ得るが、２つ又はそれ以上のサブネット、例えば、内部臨床デバイスネットワークのためのサブネットと、ゲスト及び／又は患者へのインターネットアクセスを与えるためのサブネットとを展開することを望む。

【0012】

[0014] グローバルアドレスに加えて、あらゆるデバイスは、（例えば、小規模ネットワークにおける）１ホップ通信のために使用され得る、リンクローカルアドレスをも有する。ＩＰｖ６ヘッダ圧縮の場合、グローバルアドレスとリンクローカルアドレスとが区別される。ＩＰｖ６リンクローカルアドレスがソース及び宛先のために使用され得、ローカルインターフェースアドレスがデバイスアドレスから導出され得る（すなわちステートレスアドレス構成）場合、圧縮されたＩＰｖ６ヘッダサイズは、ちょうど２バイトに低減される。ソースアドレスと宛先アドレスとが同じＩＰｖ６サブネットに属し、このサブネットのプレフィックスがコンテキストテーブルから利用可能である場合、プレフィックスは省かれ、ヘッダサイズは、４０から１９バイトに（或いは、ＩＩＤが圧縮され得る場合、例えば、ソースアドレス又は宛先アドレスがリンクローカルアドレスである場合、より小さいバイトに）低減される。非リンクローカルＩＰｖ６アドレスの場合、ネイバー（隣）発見（ＮＤ）が必要とされ、コンテキストテーブル又はルーティングテーブルが維持されなければならない。これらのコンテキストテーブルは、ソースアドレスプレフィックスと宛先アドレスプレフィックスとについて異なる。

【0013】

[0015] アプリケーションのためのトランスポートプロトコルとしてユーザデータグラムプロトコル（ＵＤＰ）が使用される場合、ＵＤＰヘッダも、８バイトから最小の２バイトに圧縮される。ＩＰｖ６上のＵＤＰのためのＩＰＨＣ圧縮ヘッダのいくつかの例では、ＩＰＨＣ圧縮ヘッダは、６バイト、８バイト、又は１３バイトである。

【0014】

[0016] デバイスは、一般に、動的ホスト構成プロトコル、例えばＤＨＣＰｖ６を使用してネットワークによって割り当てられたグローバルアドレスを有する。しかしながら、デバイスがモバイルである場合、デバイスは別のサブネット又はサイト、又は場合によっては別のインターネットサービスプロバイダ（ＩＳＰ）にさえ切り替わる必要があり、例えば、モバイルデバイスが病院を離れる場合、モバイルデバイスは、病院内のＢＬＥ無線機からセルラーネットワークに切り替わる。そのような場合、通信中に使用されるべきＩＰｖ６ソースアドレスは、サブネット、サイト、又はＩＳＰの変化とともに変わる。ＩＰｖ６デバイスのモビリティを容易にするために、モバイルＩＰｖ６、プロキシモバイルＩＰｖ６、及び階層型モバイルＩＰｖ６（ＨＭＩＰｖ６）モビリティ管理など、いくつかの規格が作成された。また、ＮＰＴｖ６などの技術は、ここでは、ＩＰｖ６アドレスのネットワークプレフィックス部分から別のもの、例えばグローバルネットワークプレフィックスへのステートレス変換を与える助けになる。２つのネットワーク内の２つのプレフィックス変換器が、同等に構成され得るか、又は、２つのネットワークからのトラフィックが、包含するエッジルータにおいて集合し、ＮＰＴｖ６又はＮＡＴ６４変換を実行し、外界にとって同じＩＰアドレスを生じる。ＮＰＴｖ６は、ＮＡＴ４４（ＩＰｖ４からＩＰｖ４へのネットワークアドレス変換）の後継と見なされ、ＮＡＴ４４は、あるＩＰｖ４アドレス空間から別のＩＰｖ４アドレス空間にＩＰアドレスを変換し、主に、限られたＩＰｖ４アドレス空間により必要とされた。ＩＰｖ６の場合、ネットワークアドレス変換は、したがって、一般に、莫大なアドレス空間により、もはや必要とされなくなるが、しばらくの間、ＩＰｖ６からＩＰｖ４に及びその逆に変換するために使用されるという考えである。

【0015】

[0017] モビリティをサポートすることは、モバイル医療デバイスにおいて重要である。例えば、ＢＬＥヘルスケアセンサーの場合、一般的シナリオでは、センサーは最初にベッドサイドモニタに接続するが、患者が移動されるか又は病院を歩き回るとき、センサーは、接続をベッドサイドモニタから、ホールにわたるＢＬＥアクセスポイント（ＡＰ）に切り替え、場合によっては途中でいくつかの他のＡＰに切り替える。同じセンサーが、患者が病院を離れるときにも使用され、この場合、センサーは、患者が自宅に到着すると、ＢＬＥホームゲートウェイに接続する。ＢＬＥヘルスケアセンサーがその寿命中に接続するすべてのこれらのデバイスは、高度ルーティング特徴のサポートに関して及び信用に関して、異なる特徴を与える（例えば、同じ製造業者からのものであるか、又は競合製造企業からのものであるかなど）。特に、Ｂｌｕｅｔｏｏｔｈ（登録商標）及びいくつかの他のワイヤレスプロトコルの場合、ＢＬＥヘルスケアセンサーが接続するデバイスは、常に信用できるとは限らない。

【0016】

[0018] ＲＦＣ７６６８文献では、及びＢｌｕｅｔｏｏｔｈ（登録商標） Ｗｈｉｔｅ Ｐａｐｅｒ、２０１７の「Ｉｎｔｅｒｎｅｔ Ｇａｔｅｗａｙｓ」では、Ｂｌｕｅｔｏｏｔｈ（登録商標） ＩＰネイティブ６ＬｏＢＴＬＥノードとともにＢＬＥゲートウェイが説明されている。ＩＰｖ６は、どこでもどのデバイスにも一般的なアドレス指定機構を与え、ＩＰＨＣヘッダ圧縮フォーマットは、引用された文献において標準化されたが、これらの方法は不要な電力消費につながる。これは、上記で説明されたすべての方法（ＩＰｖ６ヘッダ圧縮、モバイルＩＰｖ６（通常及び階層型）、プロキシモバイルＩＰｖ６）の場合、ＩＰスタックが６ＬｏＢＴＬＥノード上でアクティブであることが予想されるからであり、以下で説明されるように圧縮されたＩＰｖ６ヘッダを送るために送信電力が必要とされるからである。これは、デバイスが、様々な宛先に達することが可能である（例えば、ウェブをブラウズするためにモバイルフォンが使用される）ために一般的なＩＰサポートを有することを希望するという仮定に部分的に基づく。しかしながら、これは、例えば所定の宛先サーバにそのデータを送るにすぎないセンサーデバイスの場合、当てはまらない。

【0017】

[0019] さらに、ＩＰｖ６ヘッダは、圧縮されたソース及び宛先アドレスの場合でさえ、特に小さいペイロードをもつメッセージの場合、依然として大幅なメッセージオーバーヘッドをもたらす。例えば、ＢＬＥセンサーデバイスが、そのセンサーデータを（リンクローカル１ホップ範囲外の）ルーティング可能なアドレス、例えば集中型センサーアグリゲーションデバイス、又はインターネット上のクラウドサーバに送ることを希望する場合、ＩＰｖ６ヘッダは、境界ルータがそのコンテキストテーブルに登録された宛先アドレスのプレフィックスを有するとすれば、少なくとも１０バイト長（順に：ディスパッチヘッダフィールドのための１バイト、ＩＰＨＣヘッダフィールドのための２バイト、コンテキストＩＤヘッダフィールドのための１バイト、Ｄｓｔ Ｃｏｍｐ ＩＩＤヘッダフィールドのための２バイト、ＮＨＣ＿ＵＤＰヘッダフィールドのための１バイト、ＵＤＰポートヘッダフィールドのための１バイト、及びチェックサムヘッダフィールドのための２バイト）である。低エネルギー動作では、このオーバーヘッドがさらに低減されれば有益である。

【0018】

[0020] 二方向通信の場合、グローバルソースアドレスは、リンクローカルアドレスの代わりに使用される必要があり、少なくとも２つの追加のバイトにつながる。モバイルＩＰｖ６（標準及び階層型モバイルＩＰ）の場合、ＢＬＥセンサーデバイスは、センサーデバイス自体においてＩＰｖ６パケットカプセル化を行う必要さえあり、それにより、センサーデバイスは、パケットをカプセル化することを可能にするために、そのケアオブアドレス、ホームエージェント（ＨＡ）又はモビリティアンカーポイント（ＭＡＰ）のアドレスに気づいている必要がある。これは、複数のＩＰｖ６アドレスが各パケット中に含まれることにつながり、非モバイルＩＰｖ６ソリューションの上のより大きいパケット、したがって追加のオーバーヘッドにつながる。

【0019】

[0021] 本明細書で開示される実施形態では、ＢＬＥデバイスは、通信オーバーヘッドを低減し、ＩＰパケット処理及び圧縮のオーバーヘッド、したがって電力消費を低減しながら、ペイロードのエンドツーエンド暗号化を含む、その通信のためのＩＰｖ６とＣｏＡＰなどの上位レイヤプロトコルとを使用することが可能になる。これは、ＢＬＥデバイスが、別のＢＬＥデバイス（例えばＢＬＥアクセスポイント又はゲートウェイ）がＢＬＥデバイスに代わってＩＰｖ６ヘッダ挿入を実行することができることを動的に発見した後、必要でないとき、ＩＰｖ６ヘッダ及びＵＤＰ／ＴＣＰヘッダの送信を省略することによって行われる。これを動的に行うことによって、開示される手法は、適切な場合はいつでも、提案された電力最適化を適用しながら、モビリティをサポートし、あるアクセスポイントからローカルネットワークの内部又は外部の別のアクセスポイントからへのローミングを可能にする。

【0020】

[0022] エンドツーエンド暗号化及び／又は相互認証が、医療データの通信にとって重要である。エンドツーエンド暗号化では、パスワード、パスコード、又は他の秘密が、ＢＬＥセンサーと宛先サーバとの間で共有され、秘密は、データを暗号化するための鍵を導出するために使用される。相互認証では、データを暗号化するための鍵を導出するために使用される、ＢＬＥセンサーと宛先サーバとの間の共有秘密の知識が、検証される。しかしながら、ＢＬＥでは、デバイス間の実施されるセキュリティは、例えば「ジャストワークス（Ｊｕｓｔ－ｗｏｒｋｓ）」ペアリングが使用されるとき、欠如している。このことは、医療コンテキストにおいて問題であり、なぜなら、ヘルスケア環境では、患者医療データが、間違った人の手にわたるべきでなく、信頼できる様式で適切な宛先（例えば、電子的医療又は健康記録をホストする病院サーバコンピュータ、ナースステーションコンピュータなど）に配信されるべきであるからである。十分なセキュリティレベルを与えるために、（例えば、ＩＰレイヤフィールドが改ざんされていないことを確実にするために、サーバに／からの通信においてＩＰＳｅｃ認証ヘッダを使用して、又は、例えば共有秘密の知識を証明することによって、中間ノードが信用できることを検証するための他の機構を使用して）センサーからサーバへのネットワーク経路全体がセキュアと見なされるべきである。好ましくは、センサーは、データが正確に受信されるかどうかを、エンドツーエンド暗号化肯定応答を使用して（例えば、暗号化されたＣＯＡＰ肯定応答又はＨＴＴＰ２００ ＯＫメッセージを使用して）検証することができ、このようにして、センサーは、そのデータをサーバに安全に送るか、さもなければ接続を切ることができる。患者に医療療法を実施するＢＬＥアクチュエータデバイスの場合、アクチュエータデバイスとアクチュエータデバイスを制御するサーバデバイスとの間のセキュアな通信は、患者の安全を保証するために信用できなければならない。

【0021】

[0023] 本明細書で開示される実施形態は、ＢＬＥアクセスポイント／ゲートウェイに、エンドツーエンド暗号化メッセージを復号する必要なしにそれらをフィルタアウトさせることによって、ＢＬＥ搭載医療デバイス（例えばバイタルサインセンサーデバイス、アクチュエータデバイスなど）の電力消費を低減するための追加の機構を与え、これは、ＢＬＥセンサー／アクチュエータとＢＬＥアクセスポイント／ゲートウェイとの間の通信量の低減をもたらし、リッスン間隔の間のスリープ時間の増加を可能にし、したがって、通信をセキュアに及び信頼できるように保ちながら、電力消費を低減する。また、これらの利益は、ＢＬＥデバイスが、途中で異なるデバイス、例えば、病院における別のＢＬＥアクセスポイント、モバイルフォン、ベッドサイドモニタ、又は、患者が同じセンサーを装着しながら自宅に到着するときはホームゲートウェイにフレキシブルに接続することができるように、ローミングをもサポートしながら達成される。

【0022】

[0024] 図１及び図２を参照すると、例示的な実施形態が、医療機能Ｆを実行するために搭載されたワイヤレス医療デバイスＳ（例えば医療センサー又はアクチュエータ）を含む。デバイスＳは、無線通信ネットワーク（例えばＢｌｕｅｔｏｏｔｈ（登録商標）ネットワーク）におけるデバイスＳを一意に識別するＩＰｖ６アドレス及び／又は他のヘッダ情報Ａを記憶するための記憶域を搭載し、それにより、デバイスＳは、デバイスＴとの通信リンクＬを形成するために使用されるＢｌｕｅｔｏｏｔｈ（登録商標）低エネルギー（ＢＬＥ）無線機Ｒをさらに搭載する。図２に示されているように、１０において、通信リンクＬを介してデバイスＴから、デバイスＴがワイヤレス医療デバイスＳに代わってＩＰｖ６ヘッダ挿入を行うことが可能であるというメッセージＷを受信すると、デバイスＳは、１２において、ヘッダ情報メッセージＸを使用してデバイスＴにヘッダ情報Ａを送り、デバイスＳは、１４において、あるモードに切り替わり、このモードでは、デバイスＳが、デバイスＳのデータをメッセージＭ０．．．Ｍｎの一部として含めることによって、ＢＬＥ通信リンクＬを介してそのデータを送り、メッセージＭ０．．．Ｍｎは、ＩＰｖ６ヘッダをこれらのメッセージの一部として含まない（ただし、メッセージＭ０．．．Ｍｎは、ＰＨＹ／ＭＡＣヘッダなどの他のヘッダ情報を含む）。デバイスＴは、ヘッダ情報メッセージＸを受信し、デバイスＳの受信されたヘッダ情報Ａ’のコピーを記憶し、その後、メッセージＭ０．．．Ｍｎを受信すると、デバイスＴは、１６において、ヘッダ挿入機能Ｉを実行して、メッセージＭ０．．．Ｍｎ中にヘッダ情報Ａ’を挿入し、ヘッダを完成し、対応する有効なＩＰｖ６メッセージを、受信されたヘッダ情報Ａ’（のコピー）がこれらのメッセージのＩＰｖ６メッセージヘッダ中に挿入された状態で作成し、ＢＬＥを介して、挿入されたヘッダ情報をもつメッセージを、有効なＩＰｖ６ヘッダを各々もつメッセージＭ０’．．．Ｍｎ’として再送信する。メッセージＸは、メッセージＭ０’．．．Ｍｎ’の有効なＩＰｖ６ヘッダを構築するためにデバイスＴによって使用され得る、ソースＩＰｖ６アドレス（又はそれらの一部）、宛先ＩＰｖ６アドレス（又はそれらの一部）、トラフィッククラスについての値及び／又は拡張ヘッダを含む。ペイロード長など、メッセージＭ０’．．．Ｍｎ’のためにデバイスＴによって構築されるべきＩＰｖ６ヘッダ中の他のフィールドは、メッセージＭ０．．．Ｍｎ内のレイヤ２ヘッダにおいて示されるペイロード長から導出され得る。バージョン及びホップ限界フィールドなど、他のフィールドは、デフォルト値、すなわち、バージョンについて値６、及びホップ限界についての値２５５で埋められ得る。

【0023】

[0025] 逆に、図３に示されているように、２０において、通信リンクを介してデバイスＴから、デバイスＴがデバイスＳに代わってヘッダ挿入を行うことが可能であるというメッセージを受信しないと（又は、デバイスＴから、それがヘッダ情報挿入サービスＩをもはや実行しないことを示すメッセージを受信すると）、ワイヤレス医療デバイスＳは、２４において、あるモードに切り替わり（又は再び切り替わり）、それにより、デバイスＳは、ＢＬＥ通信リンクを介して、完全なヘッダ又はヘッダ圧縮されたＩＰｖ６ヘッダを含むデバイスＳのデータを、ＩＰｖ６メッセージＮ１．．．Ｎｎとして送る。

【0024】

[0026] したがって、デバイスＴがリレーデバイスＴ、又はヘッダ挿入デバイスＴ、又は同様の名称で呼ばれることがあることがわかる。デバイスＴが、好ましくは、ワイヤレス医療デバイスＳと比較して、電力消費があまり重要でないデバイスであることを理解されよう。ヘッダを追加及び送信する、電力を消費するプロセスは、低電力消費デバイスであることが望まれるワイヤレス医療デバイスＳによって、もはや実行されず、代わりに、電力消費が同程度に低いものである必要がないヘッダ挿入デバイスＴによって実行される。この目的で、デバイスＳは、デバイスＳがもはやＩＰｖ６ヘッダ情報を送る必要がないこの低電力動作モードへの遷移を開始するために、リレーデバイスＴによって使用されるべきソースＩＰｖ６アドレス又は宛先ＩＰｖ６アドレスなどのヘッダ情報を含んでいるメッセージＸを１回送る必要があるにすぎない。

【0025】

[0027] ワイヤレス医療デバイスＳは、本明細書で開示されるように医療機能Ｆを実施することに関係する機能を実行し、ＢＬＥ無線機Ｒとともにワイヤレス通信を実施するために、マイクロプロセッサ、マイクロコントローラ、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、グラフィック処理ユニット（ＧＰＵ）、又は他のプログラマブル電子チップ（オプションで、マルチコア、数値演算コプロセッサを含む、又はさもなければ拡張されたもの）、及びプログラマブル電子チップによって読取り可能及び実行可能な命令を記憶する非一時的記憶媒体など、構成要素（図示せず）を備える。非一時的記憶媒体は、（非限定的な例示的な例として）フラッシュメモリ、読取り専用メモリ（ＲＯＭ）、電子的消去可能プログラマブルＲＯＭ（ＥＥＰＲＯＭ）又はそれの変形態、及び／又は磁気記憶媒体（例えばハードディスク）、光記憶媒体（例えば光ディスク）、それらの様々な組合せなどを備える。モバイル医療デバイスＳによって実行される医療機能Ｆは、デバイスのタイプによって決まり、デバイスＳは、医療リソース又は機能Ｆを実行するために適宜に追加の構成要素を備える。例えば、注入ポンプを含んでいる医療デバイスＳの場合、デバイスＳは、好適なポンプハードウェア及びフローセンサーなどを含み、医療リソース又は機能Ｆは、静脈内（ＩＶ）流体フローを制御すること、ＩＶ流体フローを測定すること、ＩＶ流体の温度を測定することなどの機能を含み、プログラマブル電子チップは、ＩＶ流体の制御されたフローを送出するために流量計からのフローフィードバックに基づいてポンプを動作させることを含む医療リソース又は機能Ｆを実施するように、及びオプションでＩＶ流体温度をモニタすることなどの他の関係する機能などを実行するようにプログラムされる。別の例として、ワイヤレス医療デバイスＳがバイタルサインセンサーを備える場合、デバイスＳは、好適には、センサーハードウェア（例えばＥＧＣ、ＥＥＧ、又はＨＲモニタ電極、血圧カフ、及び膨張ポンプハードウェアなど）をさらに含み、プログラマブル電子チップは、バイタルサインデータを取得するようにセンサーハードウェアを動作させることを含む医療リソース又は機能Ｆを実施するようにプログラムされる。これらは非限定的な例示的な例にすぎず、より一般的には、ワイヤレス医療デバイスＳは、場合によっては所望の（１つ又は複数の）医療機能Ｆを与えるように構成される。その上、デバイスＳが非医療適用例のコンテキストにおいて非医療タスクを実行するためのデバイスであることが、企図される。

【0026】

[0028] デバイスＴは、ヘッダ挿入サービスＩ並びにデバイスＴが通常実行する他の機能を実行するために、デバイスＳの無線機Ｒに類似するＢＬＥ無線機、マイクロプロセッサ、マイクロコントローラ、ＦＰＧＡ、ＧＰＵ、又は他のプログラマブル電子チップ（オプションで、マルチコア、数値演算コプロセッサを含む、又はさもなければ拡張されたもの）、及びデバイスＴのプログラマブル電子チップによって読取り可能及び実行可能な命令を記憶する非一時的記憶媒体など、構成要素（図示せず）を備える。例えば、デバイスＴは、ワイヤレスアクセスポイント（ＡＰ）であり、したがって、その目的のためのプログラミングを含み、或いは、セルラー電話、タブレットコンピュータ、又は汎用オペレーティングシステム（例えばＡｎｄｒｏｉｄ又はｉＯＳオペレーティングシステム）及びモバイルデバイス上にロードされた様々なアプリケーションプログラム（「アプリ」）などをもつ他のモバイルデバイスである。デバイスＴの非一時的記憶媒体は同じく、（非限定的な例示的な例として）フラッシュメモリ、読取り専用メモリ（ＲＯＭ）、電子的消去可能プログラマブルＲＯＭ（ＥＥＰＲＯＭ）又はそれの変形態、及び／又は磁気記憶媒体（例えばハードディスク）、光記憶媒体（例えば光ディスク）、それらの様々な組合せなどを備える。

【0027】

[0029] サーバＣは、単一のサーバコンピュータ、動作可能に相互接続された、サーバコンピュータのクラスタ、コンピュータがアドホック様式で相互接続されたクラウドコンピューティングリソースなどである。

【0028】

[0030] さらなるオプションの態様では、メッセージＭｘのペイロードＰｘ（０≦ｘ≦ｎ）は、ワイヤレス医療デバイスＳによって暗号化され、デバイスＴによって実行されるヘッダ挿入サービスＩは、まったく同じペイロードＰｘを復号／再暗号化なしにメッセージＭｘ’の一部として含める。

【0029】

[0031] さらなるオプションの実施形態では、メッセージＸが、ＩＰｖ６アドレス及びＵＤＰ／ＴＣＰなどのネットワークトランスポートプロトコルに関係するパラメータ（例えば宛先ポート）を含み、それによりアドレスは、サーバＣ（オプションでクラウドサーバ）のグローバルユニキャストＩＰｖ６アドレスであり、それに応じてデバイスＴが、受信されたパラメータに基づいてサーバＣへのＵＤＰ／ＴＣＰ接続をセットアップし、それによりデバイスＴは、そのアドレスを宛先アドレスとして、デバイスＴのＩＰｖ６メッセージ中の挿入されたヘッダ情報Ａ’の一部として含め、それによりデバイスＳは、ＩＰｖ６ヘッダをもＵＤＰ／ＴＣＰヘッダをもメッセージＭ０．．．Ｍｎの一部として含めない。

【0030】

[0032] 図１を参照し、さらに図４を参照すると、（デバイスＴがヘッダ挿入サービスを提供するか否かとは無関係に実行され得る）さらなるオプションの態様では、デバイスＳは、３０において、（オプションでメッセージＸの一部である）メッセージＹを使用して、（例えば、第１の正しいエンドツーエンド暗号化アプリケーションレベルトランスポート肯定応答自体を受信した後に）アプリケーションレベルトランスポート肯定応答を受信するレートを低減するようにとの要求をデバイスＴに送り、それにより、メッセージＹは、エンドツーエンド暗号化アプリケーションレベルトランスポート肯定応答をどのように検出するかに関する基準を含み、すなわち、メッセージＹは、肯定応答検出基準、例えば、一般的なメッセージサイズ、使用されている通信プロトコル、メッセージタイプ又は他のパケットヘッダ情報、或いは他の実施形態では、肯定応答を示すハッシュ、ビットパターン、ＣＲＣ、キーワード、正規表現、又はディープパケット検査ルールセットなど、及び／又は肯定応答を暗号化するために使用されているセキュリティアルゴリズム／プロトコルのタイプを含んでおり（オプションで、鍵、或いは暗号化されたメッセージを部分的に又は全体的に復号するためのシード、カウンタ、準同型鍵情報などの他の知識で拡張され）、その後に、デバイスＴは、３２において、サーバＣから受信されたこれらのメッセージをフィルタアウトするためにこの基準を適用し、３４において、デバイスＳが、そのスリープ／起動サイクルを、リレーデバイスＴがワイヤレスデバイスＳにフィルタアウトされた肯定応答をフォワーディングする、低減されたレートと同期させることによって、デバイスＳにおけるさらなる電力低減を可能にするために（例えばメッセージの半分を廃棄することによって）低減されたレートで、デバイスＳにこれらの暗号化された肯定応答メッセージをフォワーディングする。概して、アプリケーションレベルトランスポート肯定応答は、ＩＰレイヤ（ＯＳＩレイヤ３）の上のプロトコルについて任意のタイプの肯定応答であると見なされ、したがって、ＴＣＰレベル肯定応答、ＣｏＡＰメッセージ肯定応答、ＨＴＴＰメッセージ肯定応答（例えばＨＴＴＰ２００ ＯＫ成功ステータス応答）、アプリケーション固有の肯定応答などである。肯定応答メッセージは、暗号化され、ＯＳＣｏＡＰ、ＤＴＬＳ、ＨＴＴＰ ＳＳＬ／ＴＬＳ、ＭＱＴＴ ＳＳＬ／ＴＬＳ、いくつかのＩＰＳｅｃオプション、公開鍵暗号化／ディフィーヘルマン、ＡＥＳ／ＤＥＳ暗号化、準同型鍵暗号化、ディープパケット検査暗号化などである。したがって、デバイスＴは、（例えばヒューリスティックに基づいて）ディープパケット検査技法を採用する必要があり、例えば、ビットパターン又は正規表現適合技法を採用し、暗号化ハッシュと非暗号化ハッシュとを計算及び比較し、使用されている通信プロトコル及びそれらの一般的な通信パターンに関する知識（例えば、サーバに送られたどのタイプのメッセージが、返信メッセージとして肯定応答が送られることにつながるか）を使用し、好ましくはメッセージを復号することに関係する復号鍵に関する知識をリレーデバイスＴが有することなしに、使用されているセキュリティ／暗号化技法に関する知識を使用する。デバイスＳから受信された基準情報に加えて、デバイスＴは、オプションで、肯定応答の検出及びフィルタ処理をさらに助けるための情報をもサーバから受信する。デバイスＴは、肯定応答が送られたときはいつでも通知されることを要求するために、サーバとの別個の通信チャネルをセットアップし、例えば、メッセージカウンタ又はヘッダ情報を受信し、デバイスＴは、それを使用して肯定応答メッセージを識別し、肯定応答メッセージを他のメッセージと区別することができる。いくつかの実施形態では、メッセージＹ中に含まれる低減されたレートは、リレーデバイスが、肯定応答検出基準に適合するサーバから受信された肯定応答を廃棄するレートとして指定される。いくつかの実施形態では、メッセージＹ中に含まれる低減されたレートは、リレーデバイスが、肯定応答検出基準に適合するサーバから受信された肯定応答を廃棄する最大時間として指定される。例えば、低減されたレートは、次の肯定応答がワイヤレスデバイスＳにフォワーディングされる前に廃棄すべき肯定応答の数を示す割合又は整数として指定されるか、或いは、低減されたレートは、時間単位当たりの肯定応答の数として指定される。概して、リレーデバイスは、廃棄された肯定応答をワイヤレスデバイスＳにフォワーディングしないことによって、低減されたレートでワイヤレスデバイスＳに、フィルタアウトされた肯定応答をフォワーディングする。

【0031】

[0033] さらなるオプションの態様では、ワイヤレス医療デバイスＳが、ある量の時間の間、アプリケーションレベルトランスポート肯定応答を受信しない場合、デバイスＳは、デバイスＳがバックエンドサーバＣへの接続に関する問題を有するというオーディオ／ビジュアルフィードバックをトリガする。一般に、デバイスＳが、これらの肯定応答を受信しない場合、これは、宛先との通信経路が切断されたからであるか、又はデバイスＴが、医療デバイスＳからのメッセージを故意に廃棄する悪意のあるデバイスであるからであるかのいずれかである。この機構によって、悪意のあるデバイスは、デバイスＳが何かが間違っていることを検出することが可能であることなしに、メッセージを単に廃棄することができない。

【0032】

[0034] しかしながら、医療デバイスＳがアクチュエータである場合、デバイスＳは、どの着信メッセージを予想すべきかを確実には知らないので、デバイスＳは、それを制御するサーバからのメッセージが悪意のあるデバイスＴによって故意に廃棄されていないことを確信することができないことに留意されたい。これに対処するために、アクチュエータデバイスは、好ましくは、デバイスＴがデバイスＳに代わってヘッダ挿入（及びオプションのＵＤＰ／ＴＣＰトランスポート）サービスＩを実行することを可能にする前に、（例えば、デバイスＴが、特定の事前共有秘密の知識を有するかどうか、それを証明するデバイスＴが、公開鍵に属する秘密鍵の所有を有するかどうか、又はデバイスＴが、信用できる認証局によって署名された公共鍵証明書を送ったかどうかを検証することによって）デバイスＴにおける追加の信頼レベルを有する。代替的に、アプリケーションレベルプロトコルは、ある機構を提供し、それによって、デバイスＳは、サーバＣが所与の時間期間においてデバイスＳにメッセージを送ったかどうかを決定するために定期的にサーバＣに確認することができる（それにより、サーバＣは、それがデバイスＳに送ったメッセージを繰り返すことができる）。

【0033】

[0035] さらなるオプションの態様では、デバイスＴは、サーバＣの宛先アドレスまでのメッセージＭｘ’（０≦ｘ≦ｎ）についてのラウンドトリップ時間を測定し、さらなるメッセージを使用してこの情報をデバイスＳに送り、その後に、デバイスＳは、受信されたラウンドトリップ時間に基づいて、デバイスＳのスリープ／起動スケジュール及び／又はメッセージＭ０．．．Ｍｎを送るレートを調整する。

【0034】

[0036] さらなるオプションの態様では、デバイスＴは、サーバＣからの着信メッセージを受信するために、デバイスＴがデバイスＴ上に開いたポートのＵＤＰ／ＴＣＰポート情報をデバイスＳに送り、デバイスＳはこの情報を記憶する。デバイスＳがあるデバイスＵ（図示せず）に接続する場合、デバイスＳは、このＵＤＰ／ＴＣＰポート情報を、デバイスＵへのソースＩＰｖ６アドレス及び宛先ＩＰｖ６アドレスと宛先ＵＤＰ／ＴＣＰポートとともにデバイスＵに送り、デバイスＵは、このＵＤＰ／ＴＣＰポート情報を使用して、サーバＣから来る着信ＵＤＰ／ＴＣＰトラフィックのためのソースポートをセットアップする。

【0035】

[0037] さらなるオプションの態様では、デバイスＳのヘッダ情報Ａ（及びリレーデバイスＴにおけるそれのコピーＡ’）は、セキュアにハッシング／暗号化されたセンサーＩＤを含む。これにより、センサーの識別がソースアドレスから直接行われ得るので、送られるべきアプリケーションレイヤデータの量が低減する。センサーＩＤをセキュアにハッシング又は暗号化することの、得られた出力は、ＩＰｖ６アドレスの６４ビットＩＩＤ部分内で使用され得る（ＩＰｖ６アドレスのより大きい部分を使用し得るが、これは、例えば１２８ビットＯＲＣＨＩＤ ＩＰｖ６識別子の場合と同様に、ルータビリティ問題につながる）。この手法は、サーバに接続することが可能であるデバイスのエコシステムが、６４ビットよりも少ないか又はそれに等しいセンサーＩＤアドレス空間で動作することを仮定する。

【0036】

[0038] 図４の実施形態では、ワイヤレスデバイスＳにフォワーディングされる肯定応答のレートを低減することによって、ワイヤレスデバイスＳにおける電力節約が達成される。これは、ワイヤレスデバイスＳからメッセージＹを受信することであって、メッセージＹが、サーバからリレーデバイスＴにおいて受信された肯定応答が、低減されたレートでワイヤレスデバイスＳに送られるべきであるという要求を含み、メッセージＹが、肯定応答検出基準をさらに含む、受信することと、サーバから受信された肯定応答をフィルタアウトするために、肯定応答検出基準を適用することと、低減されたレートで無線機を介してワイヤレスデバイス（Ｓ）に、フィルタアウトされた肯定応答をフォワーディングすることとによって、行われる。より一般的には、低減されたレートで他のタイプのメッセージをフォワーディングするためにこの処理を採用することが、企図される。例えば、開示される手法は、低減されたレートで肯定応答以外の応答メッセージ又はサーバ開始型メッセージをフォワーディングするために使用される。一般化された場合では、リレーデバイスＴは、ワイヤレスデバイスＳからメッセージＹを受信し、メッセージＹは、サーバからリレーデバイスＴにおいて受信されたメッセージタイプのメッセージが、低減されたレートでワイヤレスデバイスＳに送られるべきであるという要求を含む。メッセージＹは、そのメッセージタイプのメッセージを検出するための検出基準をさらに含む。リレーデバイスＴは、サーバから受信されたメッセージタイプのメッセージをフィルタアウトするために、検出基準を適用し、低減されたレートで無線機を介してワイヤレスデバイスＳに、そのメッセージタイプのフィルタアウトされたメッセージをフォワーディングする。同じく、検出基準は、そのメッセージタイプのメッセージについての一般的なメッセージサイズ、使用されている通信プロトコル、メッセージタイプ又は他のパケットヘッダ情報、そのメッセージタイプのメッセージを示すハッシュ又はビットパターン、ＣＲＣ、キーワード、正規表現又はディープパケット検査ルールセットなど、並びに／或いはそのメッセージタイプのメッセージを暗号化するために使用されるセキュリティアルゴリズム／プロトコルのタイプ（オプションで、鍵、又は暗号化されたメッセージを部分的に又は全体的に復号するためのシード、カウンタ、準同型鍵情報などの他の知識で拡張されたもの）などである。

【0037】

[0039] 図１を参照し、さらに図５を参照すると、さらなるオプションの態様では、ワイヤレス医療デバイスＳが、４０において、（例えばディフィーヘルマン交換を使用して）証明書をデバイスＴと交換して、４２において、デバイスＴが（例えばある製造業者のデバイスについて共通の）特定の事前共有秘密の知識を有するかどうかを決定し、デバイスＴがその知識を有する場合、デバイスＳは、４４において、デバイスＴにメッセージＺ（図示せず。オプションで、メッセージＸ又はＹ）を送り、そのメッセージは、デバイスＴが、サーバＣと通信するために使用するべきである（ＨＴＴＰ、ＣｏＡＰ、ＭＱＴＴなどの）上位レイヤトランスポートプロトコルに関係する（サーバリソースの宛先ＵＲＩ、ＧＥＴ、ＰＯＳＴをとるべきＲＥＳＴアクションなどの）パラメータを含み、４６において、デバイスＴがこの上位レイヤトランスポートプロトコルをサポートする場合、デバイスＳは、４８において、あるモードに切り替わり、それにより、デバイスＳは、Ｂｌｕｅｔｏｏｔｈ（登録商標）低エネルギー通信リンクを介してメッセージＭ１．．．Ｍｎ内でデバイスＳのデータを送り、メッセージＭ１．．．Ｍｎは、デバイスＳにおけるさらなる電力低減を可能にするために、ＩＰｖ６ヘッダと、ＵＤＰ／ＴＣＰポート情報と、（ＨＴＴＰ、ＣｏＡＰ、ＭＱＴＴヘッダなどの）上位レイヤトランスポートヘッダとを含まない。

【0038】

[0040] さらなるオプションの態様では、デバイスＴは、どのプロトコルがサーバＣによってサポートされると宣言されているかに基づいて、動的にトランスポートプロトコルを選択する。

【0039】

[0041] さらなるオプションの態様では、デバイスＳは、デバイスＴから、上位レイヤトランスポートプロトコルからの誤りを示すメッセージを受信する。このデバイスは、デバイスＳがバックエンドサーバＣへの接続に関する問題を有しているというオーディオ／ビジュアルフィードバックのために、この情報を使用する。

【0040】

[0042] 図１を参照し、さらに図６を参照すると、さらなるオプションの態様では、デバイスＳ及び／又はデバイスＴが、５０において、（例えば、ＲＳＳＩを測定することに基づいて）２つのデバイス間のリンクの品質が劣化していること、又は別のデバイスＵが、デバイスＳのはるかにより近い近傍にあり、デバイスＳとの接続を引き継ぐこと（すなわち、デバイスＳは、デバイスＴからデバイスＵにローミングすること）を決定し、その後に、デバイスＳは、５２において、デバイスＳがデバイスＵを介してサーバＣにすでに接続されている間、残りのメッセージ（例えばサーバＣからの再試行メッセージ又は着信メッセージ）がデバイスＴによって依然として能動的に処理された場合の混乱を回避するために、デバイスＳに代わってメッセージを送ることを停止するためのメッセージをデバイスＴに送る。デバイスＳは、５４において、新しいデバイスＵを介して接続される（すなわち、デバイスＳが、新しいデバイスＵにローミングした）とき、デバイスＳは、５６において、その間にメッセージが到着したかどうかを（デバイスＵを介して）デバイスＴに質問するか、又は代替的に、最新の少数のメッセージを再送するようにサーバＣに依頼する。

【0041】

[0043] 図１を参照し、さらに図７を参照すると、さらなるオプションの態様では、ワイヤレス医療デバイスＳが、６０において、（例えばディフィーヘルマン交換を使用して）デバイスＴと証明書を交換し、６２において、デバイスＴが、デバイスＳとサーバＣとの間のエンドツーエンド暗号化の基礎を形成する事前共有秘密の知識を有するかどうか（例えば、ＳとＴとＣとが、同じ製造業者又は認証局によって認証されたのと同じセキュリティドメイン中にあるかどうか）を決定し、デバイスＴがその知識を有する場合、デバイスＳは、６４において、デバイスＴがメッセージＭｘ’（０≦ｘ≦ｎ）内のペイロードＰｘのエンドツーエンド暗号化を実行することになるときのトリガを示す、メッセージＱ（又はメッセージＸ、Ｙ、Ｚの一部）をデバイスＴに送り、６６において、デバイスＴによってサポートされる場合、デバイスＳは、あるモードに切り替わり、それにより、デバイスＳは、メッセージＭｘ（０≦ｘ≦ｎ）中に含まれるペイロードＰｘに対してエンドツーエンド暗号化を実行しない。

【0042】

[0044] 図８を参照すると、特定の例示的な実施形態では、ワイヤレス医療デバイスＳは、ＢＬＥ無線機と、ＩＰサポートサービス（ＩＰＳＳ）のサポートをもつＧＡＰ周辺として動作するための機能とを搭載する。デバイスＳは、ＢＬＥのための６ＬｏｗＰＡＮ（６ＬｏＢＴＬＥ）ノードとして動作する機能をさらに搭載する。デバイスＴは、ＢＬＥ無線機と、ＩＰサポートプロファイル（ＩＰＳＰ）のサポートをもつＧＡＰ中央として動作するための機能とを搭載したゲートウェイデバイスである。デバイスＴは、ＢＬＥのための６ＬｏｗＰＡＮ（６ＬｏＢＴＬＥ）境界ルータとして動作する機能をさらに搭載する。医療デバイスＳは、一般に、極めて電力制限され、ボタン電池で動作するが、リレーデバイスＴは、一般に、電源給電デバイスである（とはいえ、セルフォン又はタブレットコンピュータなどの別のタイプのデバイスも企図される）。このアーキテクチャは、ＢＬＥのための６ＬｏｗＰＡＮアーキテクチャが一般に、センサーが送られるべき新しいデータを有する場合のみ、センサーがその無線機を起動することが可能になるように、ＢＬＥセンサーデバイスにおける長いスリープ期間を可能にするので、古典的なＧＡＴＴベースのアーキテクチャに勝るいくつかの利益を有する。

【0043】

[0045] デバイスＳとデバイスＴとの間の接続を確立するために、デバイスＳ上のＧＡＰ周辺機能が、その存在を近くのＢＬＥデバイスに広告するために使用される。デバイスＴ上のＧＡＰ中央機能は、これらの広告パケットを検出し、ＢＬＥ無線機を介してＣＯＮＮＥＣＴ＿ＩＮＤ ＰＤＵを送ることによって２つのＢＬＥデバイス間のリンクレイヤ接続セットアップを開始する。リンクが確立された後に、デバイスはペアリングプロシージャを実行し、デバイスＳとデバイスＴとの間にデータ通信接続が確立され、それにより、両方のデバイスは、ＩＰＳＰのための追加の要件を伴って論理リンク制御及び適応プロトコル（Ｌ２ＣＡＰ）を使用してＢＬＥトランスポートレイヤを動作させる。また、代替的に、これらの役割は入れ替えられ、それにより、デバイスＳは、ＩＰＳＰサポートをもつＧＡＰ中央として動作し、デバイスＴは、ＩＰＳＳサポートをもつＧＡＰ周辺として動作し、同様の様式でＬ２ＣＡＰ接続をセットアップする。

【0044】

[0046] ここで提示される説明では、開放型システム間相互接続（ＯＳＩ）モデルが採用され、それは、物理レイヤ（レイヤ１）と、データリンクレイヤ（レイヤ２）と、ネットワークレイヤ（レイヤ３）と、トランスポートレイヤ（レイヤ４）と、セッションレイヤ（レイヤ５）と、プレゼンテーションレイヤ（レイヤ６）と、アプリケーションレイヤ（レイヤ７）とを含む。ＩＥＥＥ８０２規格では、物理レイヤは、物理レイヤコンバージェンスプロシージャ（ＰＬＣＰ）サブレイヤと物理媒体依存（ＰＭＤ）サブレイヤとを含むが、データリンクレイヤ（レイヤ２）は、論理リンク制御（ＬＬＣ）レイヤとレイヤ２媒体アクセス制御（ＭＡＣ）レイヤとを含む。ネットワークレイヤ（レイヤ３）はＩＰレイヤと見なされ、それにより、各ＩＰパケットは、レイヤ２ＭＡＣフレーム中にカプセル化される。Ｂｌｕｅｔｏｏｔｈ（登録商標）では、ＰＨＹレイヤは、ＲＦ及びベースバンド構成要素を含むが、レイヤ２ＭＡＣは、Ｌ２ＣＡＰレイヤとリンクマネージャレイヤとを含む。ＢＬＥパケットデータ構造は、（順に）プリアンブル（１バイト）と、アクセスアドレス（４バイト）と、２～２５７バイトのプロトコルデータユニット（ＰＤＵ）と、ＣＲＣ（３バイト）とを含む。ＰＤＵは、（順に）ＰＤＵヘッダ（２バイト）と、データペイロードと、ＭＩＣ（４バイト）とを含むデータチャネルＰＤＵ、又は（順に）ＰＤＵヘッダ（２バイト）と広告ペイロードとを含む広告チャネルＰＤＵを備える。データペイロードは、一般に、（順に）Ｌ２ヘッダ（４バイト）とＬ２ペイロード（最高２４７バイト）とを含むＬ２キャップパケットからなる。Ｂｌｕｅｔｏｏｔｈ（登録商標）では、ＩＰレイヤ（レイヤ３）は、一般に、Ｌ２キャップパケットのＬ２ペイロード内にカプセル化される。ＩＰレイヤ内のＩＰパケットは、（順に）ＩＰｖ６ヘッダと、（順に）拡張ヘッダ及び上位レイヤＰＤＵを含むペイロードとを含む、ＩＰｖ６パケット構造を有する。ロングタームエボリューション（ＬＴＥ）では、その低電力変形態、狭帯域モノのインターネット（ＮＢ－ＩｏＴ）及びマシンのためのＬＴＥ（ＬＴＥ－Ｍ）を含めて、データリンクレイヤ（レイヤ２）は、パケットデータコンバージェンスプロトコル（ＰＤＣＰ）レイヤと、無線リンク制御（ＲＬＣ）レイヤと、ＭＡＣレイヤとを含む。ＩＰレイヤ（レイヤ３）は、一般に、ユーザプレーンＰＣＤＰデータプロトコルデータユニット（ＰＤＵ）のペイロード内にカプセル化される。

【0045】

[0047] 上記で説明されたＯＳＩ／ＢＬＥパケット／ＩＰｖ６アーキテクチャを採用するさらなる例示的な実施形態として、ワイヤレスデバイスＳは、レイヤ２ＭＡＣヘッダとペイロードとを各々含むレイヤ２ＭＡＣフレームとして構築されたメッセージを採用するワイヤレス通信プロトコルを介して通信するための無線機Ｒを備える。ワイヤレスデバイスは、（ｉ）ワイヤレスデバイスが、無線機Ｒを介して、ＩＰｖ６パケットヘッダとレイヤ２ＭＡＣフレームのペイロード内にカプセル化された上位レイヤプロトコルデータユニットとを各々含むメッセージＮ０、．．．、Ｎｎを送信する、第１のモード、及び（ｉｉ）ワイヤレスデバイスが、無線機Ｒを介して、ＩＰｖ６ヘッダを含むことなしにレイヤ２ＭＡＣフレームのペイロード内にカプセル化された上位レイヤプロトコルデータユニットを各々含むメッセージＭ０、．．．、Ｍｎを送信する、第２のモードで動作するように構成される。好適な手法では、ワイヤレスデバイスは、ヘッダ挿入サービスＩを提供するリレーデバイスＴにヘッダ情報メッセージＸを送信することを含む動作によって、第１のモードから第２のモードに遷移するように構成される。ヘッダ情報メッセージは、少なくとも、ＩＰｖ６ソースアドレスを構築するために使用されるべきワイヤレスデバイスのアドレス（Ａ）又はＩＰｖ６宛先アドレスを構築するために使用されるべきホストデバイスのアドレス（Ｄ）を含む。ワイヤレスデバイスは、好適には、リレーデバイスＴから、第１のモードから第２のモードへの遷移をトリガするメッセージＷを受信することをさらに含む動作によって、第１のモードから第２のモードに遷移するように構成される。メッセージＷは、異なる宛先サーバ、例えば、病院内サーバ対クラウドサーバを選択するためにデバイスＳによって使用され得る、サブネット又はルーティングプレフィックスに関する情報をも含んでいることに留意されたい。宛先サーバのＩＰアドレスが時間とともに変わるとすれば、デバイスＳは、時々、例えば、完全修飾ドメインネームをもつドメインネームサーバ（ＤＮＳ）に接触することによって、宛先サーバのＩＰアドレスを解決するか、又はＮｅｔＢｉｏｓ名とともにｐｉｎｇを使用する必要がある。

【0046】

[0048] リレーデバイスＴは、レイヤ２ＭＡＣヘッダとペイロードとを各々含むレイヤ２ＭＡＣフレームとして構築されたメッセージを採用するワイヤレス通信プロトコルを介して通信するための無線機を備える。リレーデバイスＴは、ヘッダ挿入サービスＩを実行するように構成され、ヘッダ挿入サービスＩでは、リレーデバイスが、その無線機を介してワイヤレスデバイスＳから、ＩＰｖ６ヘッダを含むことなしにレイヤ２ＭＡＣフレームのペイロード内にカプセル化された上位レイヤプロトコルデータユニットを各々含むメッセージＭ０、．．．、Ｍｎを受信する。ヘッダ挿入サービスＩは、ワイヤレスデバイスＳから受信されたメッセージＭ０、．．．、Ｍｎ中にヘッダ情報Ａ’を挿入し、完全なヘッダをもつメッセージをメッセージＭ０’、．．．、Ｍｎ’として再送信する。リレーデバイスＴは、ワイヤレスデバイスＳからヘッダ情報メッセージＸを受信し、リレーデバイスにおいてヘッダ情報メッセージ中に含まれているヘッダ情報をヘッダ情報Ａ’として記憶するように構成される。リレーデバイスＴは、リレーデバイスＴの、ワイヤレスデバイスＳに対してヘッダ挿入サービスＩを実行する利用可能性を、ワイヤレスデバイスＳに通知するためのメッセージＷを、ワイヤレスデバイスＳに送信するようにさらに構成される。

【0047】

[0049] システムが、好適には、直前の２つの段落に記載されているワイヤレスデバイスＳとリレーデバイスＴとを備える。そのようなワイヤレスデバイスＳ、リレーデバイスＴ、又はデバイスＳとデバイスＴの両方を含むシステムでは、ワイヤレス通信プロトコルは、好適には、Ｂｌｕｅｔｏｏｔｈ（登録商標）低エネルギー（ＢＬＥ）であるが、他のワイヤレス通信プロトコルも企図される。オプションで、メッセージＭ０、．．．、Ｍｎは、ワイヤレスデバイスＳによって暗号化され、リレーデバイスＴは、メッセージＭ０、．．．、Ｍｎのまったく同じコンテンツを復号／再暗号化なしにメッセージＭ０’、．．．、Ｍｎ’内に含める。

【0048】

[0050] ＩＰｖ６ヘッダ挿入特徴及び／又は肯定応答低減特徴の動的発見及び構成を可能にするために、デバイスＳ及びデバイスＴの両方が、この特徴のサポートを示す必要がある。ＩＰｖ６ヘッダ挿入特徴及び／又は肯定応答低減特徴の能力の指示は、ＢＬＥ広告メッセージ及び／又は走査要求／応答中の広告データの一部（例えばさらなるフィールド又は広告ペイロードのさらなる一部）として送られ得る。これらのメッセージはまた、デバイスＴによってソース及び／又は宛先として使用されるべきデバイスＳにおいて記憶された（１つ又は複数の）ＩＰｖ６アドレスを含めるために、並びに／或いは、デバイスＴによって宛先サーバからの肯定応答メッセージの検出のために使用されるメッセージサイズ、ハッシュ又はビットパターン、及びデバイスＴがデバイスＳに肯定応答を送るべきであるか否かについてのレートインジケータを含めるために、デバイスＴによって使用され得る。この情報はまた、別個のＬ２ＣＡＰ又はＧＡＴＴメッセージを使用して通信される。代替的に、ＲＦＣ６７７５及び７６６８において指定されたＩＰｖ６ネイバー発見プロトコルは、例えば、ゲートウェイデバイスにおいてソースＩＰアドレスを送信及び登録するためにアドレス登録オプション（ＡＲＯ）を使用する拡張されたネイバー要請メッセージを使用することによって活用され得、これは、ゲートウェイデバイスに、それが、ＩＰヘッダ圧縮（その場合、デバイスＳがメッセージＮ０．．．Ｎｎ内に圧縮されたＩＰｖ６ヘッダを含める）又は透過的な中継（その場合、デバイスＳがメッセージＮ０．．．Ｎｎ内に完全なＩＰｖ６ヘッダを含める）の代わりにＩＰヘッダ挿入特徴を使用するべきであることを示すための追加のフィールド／パラメータで拡張される。これらのメッセージは、次いで、デバイスＴにおいて、（１つ又は複数の）受信されたＩＰｖ６アドレスを発信メッセージＭ０’．．．Ｍｎ’の一部として挿入するように、及び／又は肯定応答をフィルタアウトし始めるように、モードを切り替えるためのトリガとして使用される。上述のメッセージのうちの１つをデバイスＴに送ることの結果としてデバイスＳによって受信された応答メッセージは、デバイスＳにおいて、ＩＰｖ６ヘッダをメッセージＭ０．．．Ｍｎの一部として送らないように、及び／又はデバイスＳがデバイスＴを介して中継されたサーバからの肯定応答を受信することを予想することができるレートに基づいて、デバイスＳのスリープパターンを適応させるように、モードを切り替えるためのトリガとして使用され得る。

【0049】

[0051] デバイスＳは、（ＤＨＣＰｖ６サーバから来たか、又はデバイスＴから受信されたサブネット情報に基づいて局所的に生成されたかのいずれかである）ＩＰｖ６ソースアドレス、又はＩＰｖ６宛先アドレス（例えば、ＮＦＣを介して構成されたバックエンドサーバのＩＰアドレス）など、１つ又は複数のＩＰｖ６アドレスを記憶するための何らかの非一時的記憶域を有する。デバイスＳが、デバイスＴのサブネットが、記憶されたＩＰｖ６ソースアドレスのサブネットとは異なることを検出した場合、デバイスＳは一般に、そのＩＰｖ６ソースアドレスを新しくすることに留意されたい。これらのＩＰアドレスは、センサーに対する１つ又は複数の追加のインターフェース機能又は設定を使用して設定されるか又は取り出され、デバイスＳにローカルに記憶され得る。ローカルに記憶されたＩＰアドレスは、完全なｉｐｖ６アドレスに基づいてｉｐｖ６ヘッダ挿入を行うことによってデバイスＳをＩＰネットワークにさらすデバイスＴに通知するか又はそれを更新するために使用され得る。センサーノードへのＩＰアドレス又はセンサーノードからのＩＰアドレスを更新することは、センサーネットワークのアドレスコンテキストが変わる場合にのみ必要とされ、これは、まれなイベントであることが予想され、したがって最小オーバーヘッドを課する。

【0050】

[0052] 上位レイヤトランスポートプロトコルは、ＣｏＡＰ、ＭＱＴＴ、ＨＴＴＰなどの規格を含むが、そのようなものとして制限されない。それは、ＴＣＰ、ＦＴＰ、ＲＴＳＰ、ＸＭＰＰ、ＭＬＬＰなどを直接介するＩＥＥＥ１１０７３－２０６０１など、他のプロトコルをも含む。本明細書の残りの部分では、これらのプロトコル、すなわち、ＩＰｖ６レイヤの上で動作するプロトコルについて、アプリケーションレイヤプロトコルと呼ぶ。しかしながら、低電力センサーの場合、アプリケーションレイヤトランスポートプロトコルは、ＣｏＡＰ、ＭＱＴＴ及びＨＴＴＰ ＲＥＳＴに収束するように思われ、これは、多くのデータフォーマット（例えば、ＦＨＩＲ／ＨＬ７データモデル、ＯＣＦデータモデル、ＩＥＥＥ１１０７３ベースのデータモデル、カスタムＪＳＯＮベースのデータモデル）が、トランスポートについてこれらのアプリケーショントランスポートプロトコル上でマッピングされているからである。

【0051】

[0053] たいていのアプリケーションレイヤプロトコルは、応答メッセージ／肯定応答を受信するために二方向通信をサポートするための通信チャネルを必要とする。通常、これは、要求／応答機構であり、したがって短い時間間隔のみをカバーする。また、いくつかのアプリケーションプロトコルは、二方向非同期通信、例えばＭＱＴＴサブスクライバ又はＣｏＡＰ観測者を可能にする。同様に、ＴＣＰを直接介するＩＥＥＥ１１０７３－２０６０１などのプロトコルを使用することは、走査要求など、マネージャ開始型測定データ送信を実現するためにニ方向通信を必要とする。これは、ＢＬＥセンサーが、デバイス上でＵＤＰ又はＴＣＰポートを開いているように保つ必要があることを意味する。提案されるソリューションでは、これは、今やデバイスＴによって対処され、デバイスＴは、デバイスＳに代わってサーバからメッセージを受信し、メッセージをバッファし、デバイスＳに、その次の起動スケジュールにおいてメッセージを送ることができる。これにより、デバイスＳは、着信メッセージをリッスンする時間を低減することができるので、デバイスＳの電力効率が増加する。これを可能にするために、デバイスＴは、各接続されたデバイスＳについてＵＤＰ又はＴＣＰポートを開いているように保つ。デバイスＴは、各接続されたデバイスＳの各ＩＰｖ６アドレスのための仮想ＮＩＣを維持することによって（すなわち、マルチホーミングソフトウェアを使用して）、これらのＵＤＰポートの各々についてのトラフィックを区別することができる。

【0052】

[0054] ＭＱＴＴブローカー又はＣｏＡＰサーバにサブスクライブするためにＢＬＥセンサーが使用したＩＰアドレスは、ローミング間に変わるべきでないか、又は少なくとも、頻繁に変わるべきでなく、これは、それにより、再起動される必要がある現在のサブスクリプション又は通信セッションが中断されるからである。ＩＰｖ６の場合、ＩＰアドレスは変わる必要がめったにない。したがって、デバイスＳがアクセスポイントＴからアクセスポイントＵにローミングし、アクセスポイントＵへの接続の後に、デバイスＳがその記憶されたＩＰｖ６ソース及び宛先アドレスをデバイスＵに送った場合、デバイスＵは、宛先アドレスへのＵＤＰ／ＴＣＰ接続をセットアップし、着信メッセージを受信するためにそのＵＤＰ／ＴＣＰポートをセットアップすることができる。実施形態のうちの１つに従って、デバイスＳが、デバイスＴからＵＤＰ／ＴＣＰ着信ポート情報を受信し、この情報をデバイスＵに渡した場合、デバイスＵは、まったく同じＩＰアドレス及び着信ＵＤＰ／ＴＣＰポートを伴ってデバイスＳの代わりを務め、メッセージを送るのを開始することができる。サーバＣにとっては、何も変わらなかったように見え、したがって、進行中のＭＱＴＴサブスクリプション又はＣＯＡＰ観測者登録は動作し続ける。デバイスＵは、メッセージを送って、ネットワークにおけるルーティングテーブルを更新し、今や、それ自体を参照しており、（例えばネイバー発見プロトコルを使用することによって）もはやデバイスＴを参照する必要はない。デバイスＵがデバイスＴと通信するか、又は、デバイスＳ自体がデバイスＵを介してデバイスＴと通信して、例えばその間にデバイスＳのためにメッセージが来たかどうかを質問する。代替的に、何らかのアプリケーションレベル再試行機構が、（例えば、最新の少数のメッセージを再送するようにサーバに依頼することによって）デバイスＳによって使用される。デバイスＴが、（ある量の時間の間、又はデバイスＵからメッセージを受信した後に）デバイスＳが切断されたことを発見した後に、デバイスＴは、デバイスＳのためにデバイスＴのリソースをクリーンアップすることができる。

【0053】

[0055] ＢＬＥアクチュエータデバイスは、それらが、ＢＬＥアクチュエータデバイスを制御するサーバにとって到達可能であり、到達可能なままであるべきであるので、同様の問題を有する。デバイスが到達可能なままであることを保証するために、アクチュエータデバイスは、サーバへの経路上の中間ノード中のルーティングテーブルとサーバにおけるデバイスＳのＩＰアドレス／ポート情報とを最新に保つために、サーバに何らかのメッセージ（例えばキープアライブメッセージ）を定期的に送る。代替的に、サーバからのアドレス指定能力を解決するために、モバイルＩＰホームエージェント又はモビリティアンカーポイント（ＭＡＰ）へのホームアドレスが登録される。同様に、ＩＰｖ６アドレスがグローバルにアドレス指定可能である場合、中間ルータ又はホームエージェント／モバイルアンカーポイントは、それが別のアクセスポイントに接続した後に、新しいルートに気づかされる必要がある。アクセスポイントＴからアクセスポイントＵにローミングした後にホームアドレスを登録することは、ＢＬＥアクチュエータに代わってアクセスポイントＵによって行われ得る。

【0054】

[0056] デバイスＴが要求された能力をサポートし、デバイスＳがモード切替えを行ったことがわかった後に、デバイスＳは、Ｌ２ＣＡＰ接続を直接介してメッセージＭ０．．．Ｍ１を送り、それにより、デバイスＳは、例えば、ＯＳＣｏＡＰ、ＤＴＬＳ、ＨＴＴＰ ＳＳＬ／ＴＬＳ、ＭＱＴＴ ＳＳＬ／ＴＬＳ、いくつかのＩＰＳｅｃオプション、公開鍵暗号化／ディフィーヘルマン、ＡＥＳ／ＤＥＳ暗号化などを使用して達成される、アプリケーションレベル認証及び／又はエンドツーエンド暗号化を使用して、アプリケーションレベルトランスポートをセキュアにする。

【0055】

[0057] ＩＰｖ６パケットとして構築されたメッセージのＢｌｕｅｔｏｏｔｈ（登録商標）低エネルギー（ＢＬＥ）通信を採用する低電力ワイヤレス医療デバイスのコンテキストにおいて説明されるが、デバイスＳにおける電力消費を低減するためにデバイスＳにヘッダ挿入サービスＩを提供するリレーデバイスＴとともに低電力ワイヤレス医療デバイスＳを動作させるための開示される手法は、ＷｉＦｉ、狭帯域モノのインターネット（ＮＢ－ＩｏＴ）、ロングタームエボリューション（ＬＴＥ）、ＬＴＥ－Ｍ、５Ｇ新無線など、ヘッダとペイロードとを各々含むパケットとして構築されるメッセージを採用する他のワイヤレス通信プロトコルのコンテキストにおいても行われることが理解されよう。その上、ゲートウェイデバイスは、アクセスポイント、セルラー基地局、クラウド中のサーバ、仮想ネットワーク機能などであり得る。

【0056】

[0058] 第３世代パートナーシッププロジェクト（３ＧＰＰ）によって定義されたＮＢ－ＩｏＴ及びＬＴＥ－Ｍの場合、同様の手法が達成され得、それにより、デバイスＳは、（ＮＢ－ＩｏＴの場合は）ＬＴＥカテゴリーＮＢ１／ＮＢ２無線機又は（ＬＴＥ－Ｍの場合は）ＬＴＥカテゴリーＭ１／Ｍ２無線機を搭載した（３ＧＰＰ用語ではユーザ機器又はＵＥとも呼ばれる）デバイスである。パケットゲートウェイ（Ｐ－ＧＷ）は、一般に、（例えばＤＨＣＰを通して）接続されたＵＥのＩＰアドレスを割り当て、インターネットへのインターフェースを提供するので、リレーデバイスＴは、好ましくは、Ｐ－ＧＷをホストするデバイスである。代替的に、リレーデバイスＴは、サービングゲートウェイ（Ｓ－ＧＷ）、モビリティ管理エンティティ（ＭＭＥ）、サービス能力公開機能（ＳＣＥＦ）、又はｅノードＢをホストする、４Ｇ発展型パケットコア（ＥＰＣ）ネットワーク内のデバイスである。デバイスＴがＰ－ＧＷ又はＳ－ＧＷとして機能している実施形態では、デバイスＳから送られたものとしての（ＩＰｖ６ヘッダ挿入サービスのための）メッセージＸ及び／又は（肯定応答低減サービスのための）メッセージＹは、好ましくは、（３ＧＰＰ ＴＳ２４．３０１において定義されている発展型パケットシステム（ＥＰＳ）セッション管理メッセージコンテナ内にカプセル化された）パケットデータネットワーク（ＰＤＮ）接続性要求メッセージあり、デバイスＴのヘッダ挿入サービスによって使用されるべきヘッダ情報（例えばソースアドレス又は宛先アドレス）、及び／或いは宛先サーバからの肯定応答メッセージの検出のためにデバイスＴによって使用されるメッセージサイズ、ハッシュ又はビットパターン、並びにデバイスＴがデバイスＳに肯定応答を送るべきであるか否かについてのレートインジケータを搬送するために、いくつかの追加のフィールドで拡張される。ＰＤＮ接続性要求メッセージは、オプションで、デバイスＴがヘッダ圧縮又は透過的な中継の代わりにヘッダ挿入を開始するべきであることを示すためのブールフラグ、及び／或いはデバイスＴが肯定応答低減を開始するべきであることを示すためのブールフラグを含んでいる、追加の情報要素を有する。代替的に、ＩＰｖ６ヘッダ挿入の場合、ＰＤＮタイプ情報要素は、デバイスＴがヘッダ挿入を開始するためのトリガとして、値「非ＩＰ」に設定される（注：一般には、値「非ＩＰ」の場合、デバイスＴは、デバイスＳに代わってアドレスを割り振るか、又はソースアドレスとしてそれ自体のアドレスを使用するが、本発明では、デバイスＴは、デバイスＴから宛先サーバに送られるべきＩＰｖ６ヘッダ中にＩＰｖ６ソースアドレスフィールドを構築するためにデバイスＳから受信したソースアドレスを使用する。宛先アドレスについても、同様である）。

【0057】

[0059] 代替的に、メッセージＸ又はＹは、デバイスＳからＰ－ＧＷ又はＳ－ＧＷとして働くデバイスＴに送られた別個のＥＰＳセッション管理（ＥＳＭ）メッセージである。ＭＭＥとして機能するデバイスＴの場合、メッセージＸ又はＹは、（アタッチ要求メッセージなどの）ＥＰＳモビリティ管理（ＥＭＭ）又は任意の他のネットワークアクセス層（ＮＡＳ）メッセージであり、デバイスＴによって使用されるべきヘッダ情報及び／又は肯定応答フィルタ処理情報／基準を搬送するためのいくつかの追加のフィールドで拡張される。ｅノードＢとして機能するデバイスＴの場合、メッセージＸは、無線リソース制御（ＲＲＣ）接続要求メッセージなど、ＲＲＣメッセージであり、デバイスＴによって使用されるべきヘッダ情報及び／又は肯定応答フィルタ処理情報／基準を搬送するためのいくつかの追加のフィールドで拡張される。

【0058】

[0060] デバイスＴによってメッセージＸへの応答としてデバイスＳに送られる返信メッセージ（例えば、ＰＤＮアドレス情報要素内のＰＤＮタイプ値などの「デフォルトＥＰＳベアラコンテキストアクティブ化要求（Ａｃｔｉｖａｔｅ Ｄｅｆａｕｌｔ ＥＰＳ Ｂｅａｒｅｒ Ｃｏｎｔｅｘｔ Ｒｅｑｕｅｓｔ）」内の既存の情報要素、又は、例えばブールフラグをもつ、追加の情報要素のいずれかを再使用する、ＰＤＮ接続性要求メッセージへの応答としてのアタッチ受付メッセージ内の「デフォルトＥＰＳベアラコンテキストアクティブ化要求」）は、モードを切り替えるようにデバイスＳをトリガするメッセージＷとして使用され得る。ＩＰｖ６ヘッダ挿入特徴の場合、デバイスＳがＰＤＮタイプ「非ＩＰ」を要求し、「原因＃５７－ＰＤＮタイプＩＰｖ４ｖ６のみ可能」をもつＥＳＭ原因情報要素を含む応答メッセージを受信した場合、デバイスＳは、モードを切り替えず、ＩＰｖ６メッセージＮ１．．．Ｎｎの一部として完全なヘッダ又はヘッダ圧縮されたＩＰｖ６ヘッダを含めることによって動作する。デバイスＴが肯定応答低減をサポートすることができない場合、原因情報要素についての同様の値が定義される。

【0059】

[0061] ＮＢ－ＩｏＴ及びＬＴＥ－Ｍの場合、ＩＰメッセージ（Ｎ０．．．Ｎｎ）及び非ＩＰメッセージ（Ｍ０．．．Ｍｎ）が、ユーザプレーンＰＣＤＰデータプロトコルデータユニットのペイロードとして、又は、ユーザプレーンの代わりに制御プレーンを介してトランスポートが行われる場合、ＥＳＭデータトランスポート（ＥＳＭ ＤＡＴＡ ＴＲＡＮＳＰＯＲＴ）メッセージのペイロードとして送られ得る。

【0060】

[0062] ＩＰｖ６ヘッダ挿入特徴及び／又は肯定応答低減特徴の動的発見を可能にするために、デバイスＳとデバイスＴの両方が、この特徴のサポートを示す必要がある。デバイスＳによるＩＰｖ６ヘッダ挿入の能力の指示は、追加のインジケータ、重要でない拡張、又はＵＥ－ＥＵＴＲＡ－能力フィールドで拡張されたＵＥＣａｐａｂｉｌｉｔｙＩｎｆｏｒｍａｔｉｏｎ ＲＲＣメッセージの一部として、或いは、ＲＲＣ接続要求、アタッチ要求、ＰＤＮ接続性要求、又はＥＳＭ情報応答メッセージ中の追加のフィールドとして送られ得る。リレーデバイスＴによるＩＰｖ６ヘッダ挿入又は肯定応答低減の能力の指示は、追加のフィールドで既存のシステム情報ブロックタイプを拡張することによって、又は追加のシステム情報ブロックタイプを定義することによって、システム情報メッセージ内のシステム情報ブロックの一部として送られ得る。代替的に、その指示は、「デフォルトＥＰＳベアラコンテキストアクティブ化要求」又はＥＳＭ情報要求メッセージの一部として、例えばプロトコル構成オプション内の追加のフィールドとして、又は別個の追加の情報要素として送られる。

【0061】

[0063] 本発明は、好ましい実施形態に関して説明された。上記の詳細な説明を読み、理解した他者は、変更及び改変に想到する。例示的な実施形態は、すべてのそのような変更及び改変が、添付の特許請求の範囲又はそれの均等物の範囲内に入る限りにおいて、それらの変更及び改変を含むものと解釈されるものである。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】