(57)【特許請求の範囲】
【請求項１】
無線センサネットワーク内において他のネットワーク装置と共に使用されるコーディネータであって、
前記ネットワーク装置のうちの少なくとも１つによって生成されたストリーミングに対する要求を受信するべく構成されたトランシーバ手段と、
前記ネットワーク内の状態によって決定される度合いに対するネットワークリソースの割当によって前記要求を認可するべく構成されたスケジューリング手段であって、前記状態は、前記要求を生成した前記ネットワーク装置が非常事態の状態にあるかどうかを含む、スケジューリング手段と、を有すると共に、生体の医学的な監視に関する無線センサネットワーク内において使用され、前記状態は、ネットワークリソースを要求しているネットワーク装置が医療装置であるかどうかを更に含み、
前記スケジューリング手段は、
非常事態の状態にある装置のための最高優先順位を有するストリーミング割当と、
非常事態の状態にはない医療装置のための中程度の優先順位のストリーミング割当と、
非常事態の状態にはない非医療装置のための最低優先順位のストリーミング割当と、
というタイプのうちのいずれかをスケジューリングすることにより、前記要求を認可するべく構成されていて、前記最高優先順位においては、ストリーミング割当において必要とされる遅延およびデータレートに関してそれぞれ最小の遅延時間および最高のデータレートを割当て、前記最低優先順位においては、ストリーミング割当において必要とされる遅延およびデータレートに関してそれぞれ前記最小の遅延時間より大きい遅延時間および最低のデータレートを割当て、前記中程度の優先順位においては、ストリーミング割当において必要とされる遅延およびデータレートに関してそれぞれ前記最小の遅延時間より大きい遅延時間および前記最高および最低のデータレートの間の中程度のデータレートを割当てる、コーディネータ。
【請求項２】
前記スケジューリング手段は、前記要求内において受信された又は他の手段によって独立的に受信された前記非常事態の状態の宣言に応答する請求項１に記載のコーディネータ。
【請求項３】
前記非常事態の状態は、前記要求を生成した前記ネットワーク装置のセンサによって検知される生命パラメータとの関係における医学的な非常事態を伴う請求項１に記載のコーディネータ。
【請求項４】
ストリーミング割当の優先順位は、前記ネットワーク装置との間の送信のための遅延時間と、前記ネットワーク装置との間のデータパイプのサイズと、他のネットワーク装置からの要求との関係における優先権と、のうちの少なくとも１つを決定する請求項１に記載のコーディネータ。
【請求項５】
フレームを単位とした前記ネットワーク装置との無線通信のために構成されており、
前記要求を含むフレームが前記トランシーバ手段によって受信された際に、前記スケジューリング手段は、フレームヘッダに含まれているストリーミング要求に応答する請求項１に記載のコーディネータ。
【請求項６】
前記スケジューリング手段は、要求されているストリーミング割当のタイプを通知するストリームインデックスを設定するべく構成されており、且つ、前記トランシーバ手段は、フレームのフレームヘッダ内に前記ストリーミングインデックスを含む該フレームを送信するべく構成されている請求項１に記載のコーディネータ。
【請求項７】
前記スケジューリング手段は、非常事態にあるネットワーク装置から生成された前記要求を認可するべく必要な場合に前記ネットワーク内の既存のストリームに対して割り当てられているネットワークリソースを取り戻すべく更に構成されている請求項１〜６のいずれか一項に記載のコーディネータ。
【請求項８】
前記スケジューリング手段は、前記ネットワーク装置が非常事態の状態を解除するのに応答して、該ネットワーク装置によって要求されたストリームに割り当てられていたリソースを他のネットワーク装置に対して割り当てし直すべく更に構成されている、請求項１〜７のいずれか一項に記載のコーディネータ。
【請求項９】
請求項１記載のコーディネータを含む無線センサネットワーク内において使用されるネットワーク装置であって、
前記ネットワークによって監視されているエンティティのパラメータを検知するセンサと、
前記パラメータとの関係において非常事態の状態を認識する非常事態認識手段と、
前記認識手段が非常事態の状態を認識するのに応答して、ストリーミングに対する要求を前記ネットワーク内のコーディネータに向かって送信する要求手段と、
を有するネットワーク装置。
【請求項１０】
前記非常事態認識手段は、それ自体で、前記センサによって検知されたデータから前記非常事態の状態の存在を検出し、且つ、ストリーミングの変更のための前記要求は、前記非常事態の状態の通知を含む請求項９に記載のネットワーク装置。
【請求項１１】
前記要求手段は、未割り当てストリームを表す予め規定された値に設定されたストリームインデックスを含むフレームヘッダを有するフレームの送信により、且つ／又は、コマンドフレーム識別子がチャネル時間要求を表しているMACコマンドフレームの送信により、前記要求を送信するべく構成されている請求項１０に記載のネットワーク装置。
【請求項１２】
請求項１に記載の少なくとも１つのコーディネータと、それぞれが請求項９に記載の複数のネットワーク装置と、を含む無線センサネットワーク。
【請求項１３】
無線センサネットワーク内においてリソースを割り当てる方法であって、前記ネットワークは、センサを具備する複数のネットワーク装置を使用する患者の医学的な監視を含む機能を具備する、方法であって、
前記患者の生命パラメータを前記ネットワーク内のネットワーク装置によって検知するステップと、
前記パラメータとの関係における非常事態の状態の存在を認識するステップと、
前記ネットワーク装置がストリーミングに対する要求を前記ネットワークのコーディネータに向かって送信するステップと、
前記コーディネータが、前記要求を前記ネットワーク内の他の装置からの任意の他の要求と共に、受信するステップと、
前記コーディネータが、それぞれ、非常事態の状態にある医療装置のネットワーク装置のための最高優先順位を有するストリーミング割当と、非常事態の状態にはない生命パラメータを検知している医療装置のネットワーク装置のための中程度の優先順位のストリーミング割当と、前記患者の生命パラメータを検知してはおらず、且つ、非常事態の状態にもない非医療装置のネットワーク装置のための最低優先順位のストリーミング割当と、のうちの１つをスケジューリングすることにより、前記要求を認可するステップと、を有し、前記最高優先順位においては、ストリーミング割当において必要とされる遅延およびデータレートに関してそれぞれ最小の遅延時間および最高のデータレートを割当て、前記最低優先順位においては、ストリーミング割当において必要とされる遅延およびデータレートに関してそれぞれ前記最小の遅延時間より大きい遅延時間および最低のデータレートを割当て、前記中程度の優先順位においては、ストリーミング割当において必要とされる遅延およびデータレートに関してそれぞれ前記最小の遅延時間より大きい遅延時間および前記最高および最低のデータレートの間の中程度のデータレートを割当てる、方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、無線センサネットワークに関し、更に詳しくは、但し、限定を伴うことなしに、人間又は動物の身体上に又はその周辺に配設されるか又はその内部に埋植される無線通信センサを含むボディエリアネットワークに関する。
【背景技術】
【０００２】
最近、様々な種類の無線センサネットワークが提案されている。具体的には、所謂ボディエリアネットワーク、即ち、BAN（Body Area Network）は、相対的に短い距離において情報を搬送するべく使用される無線パーソナルエリアネットワーク（Wireless Personal Area Network, WPAN）の一例である。無線ローカルエリアネットワーク（Wireless Local Area Network, WLAN）とは異なり、WPANを介して実現される接続は、インフラストラクチャをほとんど又はまったく必要としない。この特徴により、様々な装置のために、小型で電力効率に優れた廉価なソリューションを実現可能である。特に興味深い点は、センサを使用して患者の状態を監視する医療BAN（Medical BAN, MBAN）の可能性である。検知されたデータをデータシンクに供給するべくセンサを主に利用しているBANが、無線センサネットワーク（Wireless Sensor Network, WSN）の一例である。但し、MBAN内には、アクチュエータなどの更に能動的な装置を包含することも可能である。
【０００３】
IEEE802.15.4規格は、低データレートのWPAN用の物理レイヤ（PHY）及びMAC（Medium Access Control）サブレイヤの仕様を規定している。IEEE802.15.4は、高データレートのWPAN用の規格であるIEEE802.15.3と間にいくつかの類似点を有している。IEEE Std 802.15.4-2006及びIEEE Std 802.15.3-2003は、本引用により、そのすべてが本明細書に包含される。
【０００４】
IEEE802.15.4において想定されているタイプのWPANは、産業用の監視などのアプリケーションには好適であるが、MBANに必要とされるような種類のデータ信頼性を提供しておらず、更には、データを確実にストリーミングするためのメカニズムも提供していない。
【０００５】
医療アプリケーションには、信頼性及びプロセスの自動化を向上させると共にヒューマンエラーを低減しつつ、人間の労働と関連した費用を低減するという要件が存在している。センサは、必要とされるインテリジェンスを提供可能であり、且つ、医療装置内において既に広く利用されている。これには、病院での回復治療、自宅治療、集中治療ユニット、及び高度な手術手技が含まれる。脈拍や体温などのための外部センサ、体液との接触状態となるセンサ、（切れ込みを通じて）カテーテル内において使用されるセンサ、外部アプリケーション用のセンサ、無線センサを有する使い捨て型のスキンパッチ、及び埋植可能なセンサを含む医療用途に利用される多数の異なるタイプのセンサが存在している。
【０００６】
病院又は病室内の患者周辺のセンサのWPANは、患者の移動性、監視の柔軟性、現在監視されていない治療エリアへの監視の拡大、臨床過誤の低減、及び監視費用の全体的な低減を含む多数の臨床的利益を提供可能であろう。身体着用型センサは、一人の患者の身体上において様々なセンサタイプを包含可能である。これらは、患者の身体に迅速に着脱される能力を必要としている。
【０００７】
このようなセンサは、個別には、最低で患者当たりに1〜2kbpsのビットレートを具備可能であり、且つ、集合的には、10kbpsのビットレートを必要としよう。レンジは、わずかに数メートルで十分であろう。但し、医療ＷＳＮアプリケーションは、臨床環境においては、ミッションクリティカルなアプリケーションである。限られたデータ消失及び限られたレイテンシのための安定した無線リンク、患者及びセンサ密度のための能力、その他の無線との共存、数日にもわたる連続動作のための電池寿命、及び身体着用型装置のための小さなフォームファクタは、医療WSN又はMBANにおける要件の例である。これらの要件は、前方誤り訂正（Forward Error Correction, FEC）及び適応再送要求（Adaptive Repeat reQuest, ARQ）、センサ情報レートのための低デューティサイクルのTDMA、及び相対的に効率的な小さなアンテナを含む時間及び周波数ドメインにおけるダイバーシティ及び誤り制御法などの技法を利用して充足可能である。
【０００８】
従って、特に、医療アプリケーション用のボディエリアネットワークの特性を規定することを目的とした更なるIEEE802.15.6規格を規定するための作業が進行中である。IEEE802.15.6の主要な要件の１つは、医療アプリケーションにおける高い信頼性であり、その１つの態様は、信頼性の高い受信を保証するための特定のQoSの保証を伴うセンサデータなどのデータのストリーミングに関するものである。これは、患者の生命が医療ＷＳＮアプリケーションの無線リンクの信頼性によって左右される非常事態の状況においては、特に重要である。IEEE802.15.4などの既存の規格は、商用アプリケーションのために設計されており、このような非常事態の救命シナリオを考慮してはいない。
【発明の概要】
【０００９】
従って、BAN用のストリーミングメカニズムを提供し、且つ、特に、医療アプリケーション用のBANにおけるストリーミングデータのクオリティオブサービス（QoS）を保証するというニーズが存在している。
【００１０】
本発明の第１の態様によれば、無線センサネットワーク内において他のネットワーク装置と共に使用されるコーディネータが提供され、このコーディネータは、ネットワーク装置の少なくとも１つによって生成されたストリーミングに対する要求を受信するべく構成されたトランシーバ手段と、ネットワーク内の状態によって決定される度合いに対するネットワークリソースの割当によって要求を認可するべく構成されたスケジューリング手段と、を含み、状態には、要求を生成したネットワーク装置が非常事態の状態にあるかどうかが含まれる。
【００１１】
この結果、利用可能なリソースに対する競合する需要を生成するおそらくは多数のネットワーク装置のネットワーク内において、コーディネータは、ストリーミング要求を認可する際に、非常事態の状態にあるネットワーク装置に対して優先権を付与可能である。
【００１２】
ここで、「非常事態の状態」とは、通常、無線センサネットワークによって監視されているエンティティのなんらかのパラメータを意味することになる。例えば、無線センサネットワークが医学的な監視のために（部分的に又は排他的に）使用されている場合には、「非常事態」とは、監視されている患者の生命パラメータ（医療パラメータ）のなんらかの危険な状態を意味可能である。
【００１３】
非常事態の状態の存在は、要求を生成した装置自体において判定することも可能であり、或いは、ネットワーク内の別の場所において（例えば、コーディネータにおいて、或いは、おそらくは人間の意思決定を含むなんらかの更に高いレベルにおいて）判定することも可能である。少なくとも前者の場合には、好ましくは、スケジューリング手段は、要求内において受信された非常事態の状態の宣言に応答する。即ち、例えば、要求は、非常事態の状態の存在を通知するための１つ又は複数のビットを包含可能である。或いは、このような１つ又は複数のビットは、検知されているパラメータが、もはや臨界レベルにはない際に、非常事態の状態の解除を通知するべく使用することも可能である。或いは、この代わりに、コーディネータは、別の方法により、非常事態を認知することも可能であり、例えば、コーディネータは、それ自体で、要求を生成しているネットワーク装置との関係における非常事態の存在を判定可能である。
【００１４】
本発明の１つの重要な潜在的な用途は、医学的な監視である。従って、非常事態の状態は、要求を生成したネットワーク装置のセンサによって検知されている患者の生命パラメータとの関係における医学的な非常事態に関するものであってよい。好ましくは、この場合に、コーディネータによって考慮されるその他の状態には、要求を生成しているネットワーク装置が医療装置であるかどうかが含まれる。但し、非常事態の状態は、火災報知器やセキュリティ装置の場合と同様に、他の種類のパラメータに関係したものであってもよい。
【００１５】
コーディネータ内において、好ましくは、スケジューリング手段は、非常事態にある医療装置又は非医療装置のための最高優先順位を有するストリーミング割当と、非常事態の状態にはない医療装置のための中程度の優先順位のストリーミング割当と、非常事態にはない非医療装置のための最低優先順位のストリーミング割当と、というタイプのうちのいずれかをスケジューリングすることにより、要求を認可するべく構成されている。
【００１６】
ここで、ストリーミング割当の「優先順位」は、ネットワーク装置との間の送信についての遅延時間、ネットワーク装置との間のデータパイプのサイズ、及び他のネットワーク装置からの要求との関係における優先権のうちの少なくとも１つの判定を包含可能である。
【００１７】
コーディネータは、IEEE802.15.6などのフレームに基づいたシステム内において使用可能であり、そのため、フレームを単位としたネットワーク装置との間の無線通信のために構成可能である。このようなシステム内においては、通常、帯域幅に対する要求を含むすべての通信は、それぞれがフレームヘッダを具備するフレーム内において実行され、且つ、フレームは、大きなスーパーフレームを時分割したものである。ストリームは、このようなスーパーフレームのコンテンションを伴わない期間内において割り当てられる。要求を含むフレームをトランシーバ手段によって受信した際に、スケジューリング手段は、フレームヘッダ内に含まれているストリーミング要求に応答する。
【００１８】
更に詳しくは、要求は、未割り当てストリームのために予約された値にストリームインデックスを設定することによって通知可能である。要求を認可するために、スケジューリング手段は、要求されているストリーミング割当のタイプを通知するべくストリームインデックスの値を設定可能であり、且つ、トランシーバ手段は、ストリームインデックスをそのフレームヘッダ内に含むフレームを送信可能である。
【００１９】
ネットワーク内に存在している利用可能なリソースが、新しいストリーミング割当を認可するには不十分であり、且つ、非常事態の状態にあるネットワーク装置によって生成された要求を認可するべく必要である場合には、好ましくは、スケジューリング手段は、ネットワーク内において既存のストリームに割り当てられているネットワークリソースを取り戻すべく更に構成されている。このネットワークリソースを取り戻すことは、既存のストリームに対する割当を低減することと、既存のストリームを終了させることと、のうちの少なくとも１つを包含可能である。或いは、これは、例えば、MBANが、安全にそのサービスを低減可能な様々な非医療装置を含む場合には、複数の既存のストリームを同時に低減又は終了させてもよい。
【００２０】
一方、既存の非常事態の状態は、時間の経過に伴って解除される可能性がある。その場合には、好ましくは、スケジューリング手段は、かつて非常事態の状態にあったネットワーク装置から要求されたストリームに対して割り当てられていたリソースを他のネットワーク装置に対して割り当てし直すべく更に構成されている。
【００２１】
本発明の第２の態様によれば、無線センサネットワーク内において使用されるネットワーク装置が提供され、このネットワーク装置は、ネットワークによって監視されているエンティティのパラメータを検知するセンサと、そのパラメータとの関係における非常事態の状態を認識する非常事態認識手段と、その認識手段が非常事態の状態を認識するのに応答して、ストリーミングに対する要求をネットワーク内のコーディネータに向かって送信する要求手段と、を有する。
【００２２】
１つの可能性は、非常事態認識手段が、それ自体で、センサによって検知されたデータから非常事態の状態の存在を検出するというものであり、且つ、少なくともこの場合には、ストリーミングに対する要求は、好ましくは、非常事態の状態の通知を含む。或いは、この代わりに、非常事態認識手段は、非常事態の状態に関する通知をコーディネータから受信する。コーディネータが所与のネットワーク装置に影響を及ぼしている非常事態の状態について既に認知している場合には、要求内において非常事態を明示的に通知する必要はないであろう。
【００２３】
好ましくは、IEEE802.15.4に従って編成されたフレームに基づいたネットワークを仮定した場合には、要求手段は、未割り当てストリームを表す予め規定された値に設定されたストリームインデックスを含むフレームヘッダを有するフレームの送信により、且つ／又は、コマンドフレーム識別子がチャネル時間要求を表しているMACコマンドフレームの送信により、要求を送信するべく構成されている。
【００２４】
ネットワーク装置は、例えば、スタートポロジーを具備するネットワーク内においては、要求をコーディネータに対して直接的に送信可能であり、或いは、この代わりに、ピアツーピア構成において実行されるように、要求は、１つ又は複数の中間のネットワーク装置を介して送付することも可能である。
【００２５】
本発明の第３の態様によれば、前述の少なくとも１つのコーディネータと、それぞれが前述のものである複数のネットワーク装置と、を含む無線センサネットワークが提供される。前述のように、このようなネットワークは、病院などの医療環境において一人又は複数人の患者の医学的な監視に適用可能であろう。
【００２６】
前述のいずれの場合においても、監視されるエンティティは、生体（人間又は動物）であってよく、或いは、工場や設備などの産業的なエンティティであってもよいであろう。無線装置との関係における非常事態の状態は、例えば、MBANの場合には、医療パラメータ、或いは、この代わりに、安全又はセキュリティアプリケーションの場合には、火災や侵入の検出に関係したパラメータなど、装置を使用してそのデータが検知又は記録されているパラメータが、なんらかの臨界レベル又は範囲に到達したことを意味している。
【００２７】
又、前述の内容において、「ストリーミングに対する要求」とは、例えば、ビットレートを増大させることによって既存のストリームを変更するための要求を含む。
【００２８】
本発明の第４の態様によれば、無線センサネットワーク内においてリソースを割り当てる方法が提供され、ネットワークは、センサを具備する複数のネットワーク装置を使用した患者の医学的な監視を含む機能を具備しており、この方法は、患者の生命パラメータをネットワーク内のネットワーク装置によって検知するステップと、パラメータとの関係における非常事態の存在を認識するステップと、ネットワーク装置がストリーミングに対する要求をコーディネータに向かって送信するステップと、コーディネータがその要求をネットワーク内の他の装置からの任意の他の要求と共に受信するステップと、コーディネータが、それぞれ、非常事態の状態にあるネットワーク装置のための最高優先順位を有するストリーミング割当と、非常事態の状態にはない生命パラメータを検知しているネットワーク装置のための中程度の優先順位のストリーミング割当と、患者の任意の生命パラメータを検知しておらず、且つ、非常事態の状態にもないネットワーク装置のための最低優先順位のストリーミング割当と、のうちの１つをスケジューリングすることにより、要求を認可するステップと、を有する。
【００２９】
本発明の更なる態様は、無線センサネットワークのコーディネータ又はネットワーク装置のプロセッサによって実行された際に、それぞれ、前述の第１又は第２の態様によるコーディネータ又はネットワーク装置を提供するソフトウェアを提供する。このようなソフトウェアは、コンピュータ可読媒体上に保存可能である。
【００３０】
本発明を更に十分に理解するべく、且つ、本発明を実施可能な方法を更に明瞭に示すべく、以下、添付図面を参照するが、これは、例示を目的としたものに過ぎない。
【図面の簡単な説明】
【００３１】
【図１】IEEE802.15.4のWPANにおけるプロトコルレイヤを示す。
【図２】IEEE802.15.4のWPANの可能なPHY帯域を示す。
【図３】WPANのスター及びピアツーピアトポロジーを示す。
【図４】ビーコン対応型のIEEE802.15.4のWPANにおけるスーパーフレームの構造を示す。
【図５】IEEE802.15.4のWPANにおけるネットワーク装置とコーディネータの間のデータ転送の可能なモードを示す。
【図６】IEEE802.15.4のWPANにおけるネットワーク装置とコーディネータの間のデータ転送の可能なモードを示す。
【図７】IEEE802.15.4のWPANにおけるネットワーク装置とコーディネータの間のデータ転送の可能なモードを示す。
【図８】IEEE802.15.4のWPANにおけるネットワーク装置とコーディネータの間のデータ転送の可能なモードを示す。
【図９Ａ】IEEE802.15.4のWPANにおけるデータフレームに使用されるフレームフォーマットを示す。
【図９Ｂ】IEEE802.15.4のWPANにおけるMACコマンドフレームに使用されるフレームフォーマットの一部を示す。
【図１０】ストリーミングのQoSをアプリケーションのタイプ及び非常事態又は非−非常事態の状況にマッピングするための表である。
【図１１】本発明の一実施例におけるデータのストリーミングを分類する手順のステップのフローチャートである。
【図１２】BAN内のネットワーク装置間におけるストリームの割当のためのシナリオの概略図である。
【図１３】BAN内のネットワーク装置間におけるストリームの割当のためのシナリオの概略図である。
【図１４】BAN内のネットワーク装置間におけるストリームの割当のためのシナリオの概略図である。
【図１５】BAN内のネットワーク装置間におけるストリームの割当のためのシナリオの概略図である。
【図１６】BAN内のネットワーク装置間におけるストリームの割当のためのシナリオの概略図である。
【図１７】BAN内のネットワーク装置間におけるストリームの割当のためのシナリオの概略図である。
【図１８】BAN内のネットワーク装置間におけるストリームの割当のためのシナリオの概略図である。
【図１９】BAN内のネットワーク装置間におけるストリームの割当のためのシナリオの概略図である。
【図２０Ａ】非常事態又は非−非常事態の状況においてストリームをスケジューリングするための本発明の一実施例による手順のフローチャートである。
【図２０Ｂ】非常事態又は非−非常事態の状況においてストリームをスケジューリングするための本発明の一実施例による手順のフローチャートである。
【図２１】本発明の一実施例におけるIEEE802.15.6のために提案された変更されたフレームフォーマットを示す。
【図２２】本発明の他の実施例に従って変更されたMACコマンドフレームにおけるコマンドフレーム識別子の値の表を示す。
【発明を実施するための形態】
【００３２】
本発明の実施例について説明する前に、現在開発中のIEEE802.15.6規格及び／又はMBANを含むボディエリアネットワークに関連すると予想されるIEEE802.15.4の各部分についてその背景を少し説明しておくこととする。
【００３３】
図１は、無線トランシーバ及びその低レベルコントロールを含むPHYレイヤを介して物理媒体にアクセスする層状のＯＳＩモデルの観点におけるIEEE802.15.4のWPANの概略的なアーキテクチャを示しており、これには、参照符号１００が付与されている。図示のように、PHY用の２つの代替周波数帯域１０１、１０２が存在しており、これらが図２に示されている。低周波数帯域１０１は、868.3MHzを中心とする単一の20kb/sのチャネル及び／又は915MHzを中心とするそれぞれが40kb/sの10個のチャネルを提供する。高い周波数帯域１０２は、それぞれが250kb/sであり、且つ、2.44GHzの周波数を中心とする16個のチャネルを提供する。これらの帯域のうちのいずれが使用されるかは、当該地域の規制要件によって左右されることになる。
【００３４】
このPHYに対するアクセスは、図１に参照符号１０５によって示されているMAC（Medium Access Control）サブレイヤによって提供される。従って、この上位には、且つ、WPAN１００の外部には、他のネットワークからのWPANに対するアクセスを許容するLLC（Link Layer Control）が提供されており、これは、IEEE802.2規格によるものであってもよく、或いは、他のタイプのものであってもよい。最後に、LLCより上方の上位レイヤ１０９は、ネットワークの構成、操作、及びメッセージのルーティングを提供するためのネットワークレイヤと、意図されている全体的な機能を提供するアプリケーションレイヤと、を含む。
【００３５】
MACサブレイヤの１つのタスクは、ネットワークトポロジーを制御することにある。スター及びピアツーピアが、通信ネットワークにおける２つの既知のトポロジーであり、且つ、いずれも、IEEE802.15.4において提供されている。いずれの場合にも、トポロジーは、装置とコーディネータという２つの基本的な種類のネットワークノードを区別している。図３に示されているように、スタートポロジーにおいては、いくつかの装置１１が、中央コーディネータ１０と直接通信しており、ピアツーピア構成においては、装置１１−１によるコミュニケータとの通信は、中継装置として機能する中間の装置１１−２及び１１−３により、１つ又は複数のホップに沿って実行される。コーディネータは、上位レイヤへのアクセスポイントとして機能しており、ＷＳＮの場合には、コーディネータは、センサによって収集されたデータ用のシンクとして機能する。それぞれの装置の通信レンジを相当に限定することができる場合には（数メートル）、ピアツーピアトポロジーによれば、相対的に大きなエリアをカバー可能である。トポロジーは、動的であってよく、装置のネットワークへの追加又は除去に伴って変化する。
【００３６】
MBANの場合には、例えば、コーディネータがそれぞれの患者サイト（病院のベッドなど）に提供され、これにより、一人の患者上の装置と信号を交換する場合には、スターネットワークが適当であろう。ピアツーピアは、複数の患者に対してサービスするべく１つのコーディネータが提供される場合に、より適切なトポロジーであろう（コーディネータは、病室内の固定された地点に配置可能であろう）。従って、装置１１は、一般に、移動型となり、コーディネータは、移動型又は固定型であってよい。又、ピアツーピアネットワークは、ネットワークを迅速にセットアップ又は変更したり、或いは、ネットワークの自己組織化及び自己回復の実現が必要とされる高速で変化する環境に好適であろう。自己回復は、例えば、既存のコーディネータに障害が発生するか又は既存のコーディネータがネットワークを離脱した場合に、新しいコーディネータを確立することを包含可能である。
【００３７】
病院などの同一の場所に、多数のスター及び／又はピアツーピアネットワークをセットアップ可能であり、そのそれぞれが、独自のコーディネータを有する。この場合には、相互干渉を回避すると共にデータの共有又は照合を許容するべく、個々のコーディネータが協働する必要がある。IEEE802.15.4においては、このようなネットワークをクラスタと呼んでおり、且つ、クラスタ用の全体的なコーディネータの確立と、クラスタの分割及びマージとが提供されている。
【００３８】
WPAN内のノードは、様々な能力のユニットによって構成可能である。一般に、コーディネータの役割は、なんらかの処理パワーを有する相対的に高機能な装置と、複数の供給源からの送信を同時に処理する能力を有するトランシーバと、を必要とすることになる。そして、この結果、電力の十分な供給を必要とすることになる（場合によっては、商用電源供給型であってよい）。一方、ネットワーク内の他の装置は、相対的に限られた処理能力と、電池電力のみへのアクセスと、を備え、且つ、場合によっては、リレーホップとして機能することができないほどに単純なものであってもよい。非常にわずかな電力しか利用できない装置は、大部分の時間にわたってシャットダウンし、且つ、例えば、センサデータを別のノードに送信する際にのみ、ときどき、「ウェークアップ」するものでもよい。従って、IEEE802.15.4規格は、「フル機能」装置と「部分的機能」装置を区別している。電力の利用可能性は、センサが、身体内に埋植可能であり、且つ、従って、大きな又は充電式の電池を具備することができないMBANの場合に、特有の課題である。
【００３９】
IEEE802.15.4において想定されている２つのタイプのWPANは、ビーコン対応型及びビーコン非対応型である。
【００４０】
ビーコン対応型のネットワークにおいては、コーディネータが、ビーコンを定期的に送信し、且つ、装置が、そのビーコンを定期的に聴取して、ネットワークに対して同期化すると共にチャネルにアクセスする。チャネルアクセスは、図４に示されているスーパーフレーム構造による「スーパーフレーム」内において順番に送信される「フレーム」を単位としており、これは、コーディネータによって規定される。それぞれのスーパーフレーム３０は、アクティブと非アクティブという２つの部分から構成されている。アクティブ部分は、コンテンションアクセス期間CAP３６と、これに後続する、保証されたアクセスのための任意選択のコンテンションフリー期間CFP３７と、に分割されており、本発明の実施例においては、クオリティオブサービス要件を持つストリームの割当のために、スーパーフレームのこの部分を使用している。
【００４１】
図４の垂直分割によって示されているように、スーパーフレームは、それぞれがコーディネータからの又は装置からのデータのフレームを搬送する能力を有する１６個の等しく離隔したタイムスロットに分割される。従って、１つのコーディネータと関連付けられた装置を考慮すれば、１つの装置のみが、スーパーフレーム内のそれぞれの連続したタイムスロットにおいて１つの時点においてコーディネータとの通信状態にあってよい。まず、コーディネータによって送信されたビーコンフレーム（以下を参照されたい）について、スロット３１が到来する。この後に、いくつかのスロット３２がCAP内において供給され、これにより、既知のCSMA-CAアルゴリズムに準拠して、コンテンション方式により、装置との間のデータ送信が許容される。要すれば、CSMA-CAにおいては、装置は、CAP内において送信を所望するたびに、ランダムな期間にわたって待機する。ランダムなバックオフに続いて、チャネルがアイドル状態にあると判明した場合に、装置は、そのデータを送信する。ランダムなバックオフに続いて、チャネルがビジー状態にあると判明した場合には、装置は、チャネルに再度アクセスするべく試行する前に、別のランダムな期間にわたって待機する。
【００４２】
次に、CFPの保証タイムスロットGTS３３が後続し、且つ、図示のように、これらのそれぞれのものは、複数の基本タイムスロットにわたって延長可能である。非アクティブ期間の満了の後に、コーディネータが別のビーコンフレーム３１を送信することにより、次のスーパーフレームがマーキングされる。装置は、スーパーフレームの非アクティブ期間３４において、スリープ状態に移行可能である。従って、非アクティブ期間３４の長さを拡張することにより、装置の電池電力を可能な限り節約可能である。
【００４３】
ビーコン非対応型のネットワークにおいては、コーディネータは、（例えば、ネットワークディスカバリのために）要求されない限り、同期化のためにビーコンを送信する必要はない。チャネルアクセスは、スーパーフレーム構造によって制限されてはおらず、且つ、装置は、非同期であって、CSMA-CAによってすべてのデータ転送が実行される。これらの装置は、sensor-MACなどの特定のプロトコルに従って、その独自のスリープパターンを踏襲可能である。
【００４４】
MBANアプリケーションの場合には、コーディネータは、監視対象の１つ又は複数の身体の外部に位置している。これは、ＰＤＡ、携帯電話機、ベッドサイドのモニタステーション、或いは、場合によっては、一時的にコーディネータとして機能する十分に高機能なセンサであってよい。前述のように、ビーコン対応型ネットワーク内のコーディネータは、ネットワーク装置に対する同期化及びチャネルアクセスの提供を担当している。又、スーパーフレームの開始及び終了も、コーディネータによって規定される。コーディネータは、他のネットワークに対する潜在的な通信と、例えば、充電済みの電池の容易な交換による十分な電源に対するアクセスと、という２つの主要な機能を具備している。
【００４５】
又、おそらくはいくつかのコーディネータを含むネットワークの全体的な監督のために中央治療及び監視ユニットを提供することも可能である。これは、複数の患者から非常事態データの連続した又は不定期のストリームを受信する能力を有する監視装置を具備した部屋の形態を有することができる。通常、中央ユニットには、患者のデータを継続的に観察及び監視する看護師又は医療専門家が待機することになる。彼らは、患者の状態の変化に応答して処置を講じることになる。中央治療及び監視ユニットは、１つの又はそれぞれのコーディネータに無線接続することも可能であり（この場合には、そのユニットは、MBANの一部と見なされる場合もあり、或いは、見なされない場合もある）、或いは、それぞれのコーディネータに対する有線接続を具備することも可能である（従って、この場合には、そのユニットは、MBANの外部に位置すると見なされることになろう）。
【００４６】
図５〜図８は、IEEE802.15.4ネットワーク内における装置とコーディネータの間のデータ転送を示している。IEEE802.15.4には、以下のような３つの基本的な転送タイプが規定されている。
（ｉ）装置（送信器）がそのデータを送信する先である受信器としてのコーディネータに対するデータ転送−スター及びピアツーピアトポロジーの両方において使用される。
（ｉｉ）装置がデータを受信する、送信器としてのコーディネータからのデータ転送−スター及びピアツーピアトポロジーの両方において使用される。
（ｉｉｉ）２つのピア間におけるデータ転送−ピアツーピアネットワークにおいてのみ使用される。
【００４７】
図５及び図６は、それぞれ、ビーコン対応型及びビーコン非対応型の場合の両方における装置（ネットワーク装置１１）とコーディネータ（コーディネータ１０）からの転送を示す。相違点は、ビーコン対応型の場合には、装置１は、CFPにおいてCSMA-CAを使用して、又はCAPにおいてGTSを使用して、データ（データフレーム４２）を送信する前に、コーディネータからビーコンフレーム４１を受信するべく待機しなければならず、ビーコン非対応型の場合には、通常、ビーコンフレームが存在せず、且つ、装置１１は、CSMA-CAを使用してデータフレーム４２を自由に送信するという点にある。いずれの場合にも、コーディネータは、任意選択のアクノリッジメントフレーム又はＡＣＫ４３を送信することにより、データの正常な受信をアクノリッジする。これらの異なるタイプのフレームについては、更に詳細に後述する。
【００４８】
受信器がなんらかの理由から受信したデータフレームを処理することができない場合には、そのメッセージはアクノリッジされない。送信器が所定の期間の後にアクノリッジメントを受信しない場合には、送信器は、その送信が不成功であったものと仮定し、且つ、フレーム送信を再試行する。何回かの再試行の後に、アクノリッジメントが依然として受信されない場合には、送信器は、そのトランザクションを終了させるか又は再度試行するべく選択可能である。アクノリッジメントが不要である際には、送信器は、送信が成功したものと仮定する。
【００４９】
図７及び図８は、コーディネータ１０から装置１１へのデータ転送を示している。コーディネータがビーコン対応型WPAN（図７）においてデータを装置に転送すべく所望する際には、コーディネータは、データメッセージが保留中であるという旨をビーコンフレーム４１内において通知する。装置は、定期的にビーコンフレームを聴取し、且つ、メッセージが保留中である場合には、データ要求（MACコマンド）４４を送信し、CSMA-CAによってデータを要求する。コーディネータ１０は、アクノリッジメントフレーム４３を送信することにより、データ要求の正常な受信をアクノリッジする。次いで、保留中のデータフレーム４２が、スロット型のCSMA-CAを使用して、或いは、可能な場合には、アクノリッジメントの直後に、送信される。装置１１は、任意選択のアクノリッジメントフレーム４３を送信することにより、データの正常な受信をアクノリッジ可能である。この段階で、トランザクションが完了する。データトランザクションが正常に完了した際に、そのメッセージは、ビーコン内の保留メッセージのリストから除去される。
【００５０】
ビーコン非対応型の場合には、特定の装置１１用の準備が整ったデータを具備するコーディネータ１０は、コンテンションに基づいて送信される関係する装置からのデータ要求４４を待たなければならない。この要求を受信した際に、コーディネータは、アクノリッジメントフレーム４３を送信する（これは、該当する場合には、準備されたデータが存在しないことを通知するべく使用することも可能である）。次いで、データフレーム４２が送信され、これに応答し、装置１１は、返信として別のアクノリッジメントフレーム４３を送信可能である。
【００５１】
わかりやすくするべく、以上の手順においては、装置とコーディネータの間のデータ転送のうちの前述のケース（ｉ）及び（ｉｉ）のみが考慮されているが、ピアツーピアネットワークにおいては、前述のように、データ転送は、一般に、１つ又は複数の中間ノードを伴うメカニズム（ｉｉｉ）を介して実行されることになり、その結果、関係する衝突及び遅延のリスクが増大する。
【００５２】
図５〜図８に示されているように、IEEE802.15.4ネットワーク内における通信は、利用可能なリソースを時分割方式によって分割するフレームを単位として実行されており、これには、以下のように４つの異なるタイプのフレームが関係している。
−ビーコンを送信するべくコーディネータによって使用されるビーコンフレーム４１
−すべてのデータ転送用に使用されるデータフレーム４２
−正常なフレームの受信を確認するべく使用されるアクノリッジメントフレーム４３
−データ要求などのすべてのMACピアエンティティの制御転送を処理するべく使用されるMACコマンドフレーム４４
【００５３】
４つのフレームタイプのそれぞれのものの構造は、非常に類似しており、且つ、例として、データフレーム４２のものが図９Ａに示されている。この図において、２つの水平のバーは、MACサブレイヤと、PHYレイヤと、をそれぞれ表している。時間は左から右に進行し、且つ、フレームのそれぞれの連続したフィールドの時間長が、関係するフィールドの上方に示されている（単位：オクテット）。すべてのフレームは、特定順序のフィールドのシーケンスから構成されており、これらは、左から右に、PHYによって送信される順序において示されており、最も左側のビットが、時間的に最初に送信される。それぞれのフィールド内のビットには、０（最も左側であり、且つ、最下位である）からｋ−１（最も右側であり、且つ、最上位である）までが付番されており、この場合には、フィールドの長さは、ｋビットである。
【００５４】
データフレーム４２を介して送信されるデータは、上位レイヤに由来している。データペイロードは、MACサブレイヤに伝達され、且つ、MACサービスデータユニット（ＭＳＤＵ）と呼称される。MACペイロードには、先頭にMACヘッダＭＨＲが付加され、且つ、末尾にMACフッタＭＦＲが付加される。ＭＨＲは、フレームコントロールフィールド、データ連番（ＤＳＮ）、アドレス指定フィールド、及び任意選択の補助セキュリティヘッダを含む。ＭＦＲは、１６ビットのフレームチェックシーケンスＦＣＳから構成されている。ＭＨＲ、MACペイロード、及びＭＦＲが、１つのMACデータフレーム（即ち、ＭＰＤＵ）を形成する。ＭＰＤＵは、PHYサービスデータユニットＰＳＤＵとしてPHYに伝達され、これが、PHYペイロードになる。PHYペイロードには、先頭に、プリアンブルシーケンス及びフレーム開始デリミタＳＦＤを含む同期化ヘッダＳＨＲと、オクテットを単位とするPHYペイロードの長さを含むPHYヘッダＰＨＲと、が付加される。プリアンブルシーケンス及びデータＳＦＤにより、受信器は、シンボル同期化を実現可能である。ＳＨＲ、ＰＨＲ、及びPHYペイロードが、１つのPHYパケット（PHYプロトコルデータユニットＰＰＤＵ）を形成する。
【００５５】
ビーコンフレーム４１、アクノリッジメントフレーム４３、及びMACコマンドフレーム４４は、MACペイロードがそれぞれのケースにおいて異なる機能を具備し、アクノリッジメントフレームがMACペイロードを具備していないことを除いて、類似の構造を具備している。又、ビーコンフレーム４１、アクノリッジメントフレーム４３、及びMACコマンドフレーム４４は、MACサブレイヤに由来しており、上位レイヤの関与を伴っていない。
【００５６】
MACコマンドフレーム４４は、構造において、MACサブレイヤのみが示されている図９Ｂに示されいるものと非常に類似している。この場合に、ペイロードは、MACコマンドフレームによって表されるコマンドのタイプを識別するべく、コマンドフレーム識別子４４０を含む。
【００５７】
前述のデータ転送モードを使用することにより、ネットワーク装置は、ある種のストリーミングを実現するべく、いくつかのスーパーフレームにわたってデータを送信可能ではあるが、IEEE802.15.4には、特定の保証されたQoSレベルを伴ってデータ転送がいくつかのスーパーフレームにわたって持続するストリーミングのための明示的な仕組みが存在しない。但し、IEEE Std 802.15.3によって規定されている高レートのWPANを含む他の種類の通信ネットワークにおいては、ストリーミングが提供されている。一般に、ストリームは、「等時的（isochronous）」なものであってもよく（定期的に、即ち、スーパーフレームの開始時点などの既知の基準との関係におけるなんらかの既定のタイミングにおいて、送信を実行する）、或いは、非同期式のものであってもよい（任意の時点において送信を実行可能である）。
【００５８】
本発明の背景の概説を以上において終了し、以下、図１０〜図２１を参照して、いくつかの実施例について説明することとする。
【００５９】
図５〜図８に示されているデータの非ストリーミング型の送信は、いくつかのWPANアプリケーションにおいては、十分なものであろうが、先程参照したMBANのシナリオにおいては、医療無線センサが医療データをストリーミングすることができる、換言すれば、そのセンサデータを長期間にわたってそれなりの安定したビットレートにおいて送信（或いは、おそらくは、どこか別のところからデータ／コマンドを受信）することができることが望ましいであろう。これは、特に、MBAN内のそれぞれのネットワーク装置のセンサデータのストレージ容量が限定されていると考えられる場合に当て嵌まる。但し、センサ装置の限られた容量を考慮してMBAN内においてストリーミングデータを搬送するには、既存の規格に対するいくつかの変更が必要である。IEEE802.15.4タイプのスーパーフレーム構造を考えた場合に、ストリーミングに利用可能となるのは、CFP３７のみである。本発明の実施例は、医学的な非常事態のストリーミングデータを他の非−非常事態アプリケーションから弁別するための方法と、この分類を実現するためのプロトコルと、IEEE802.15.6に好適な新しいコントロールフォーマットと、を提供する。更には、本発明の実施例は、関係する複数の装置が存在している際に、医療ストリーミングデータをスケジューリングするための方法をも提供する。
【００６０】
本発明は、例えば、患者の身体の内部に、その上部に、又はその周辺に配設されたセンサのMBANを介して患者が監視されている状況に対処するものである。MBANは、厳密に医学的なもの以外にも、他の使用法を具備することが可能であるが（或いは、そのような使用法を具備したネットワークの一部であってもよいが）、センサの少なくともいくつかのものが、患者の生命を脅かす状態を通知可能な心拍数などの１つ又は複数のパラメータの検知に関与しているものと仮定する。例えば、検知されるパラメータは、臨界閾値を超過した値に到達することもあり、或いは、許容可能な範囲外に逸脱することもある。
【００６１】
少なくとも１つの検知されたパラメータとの関係におけるこのような生命を脅かす状況を認識した際に、MBAN（更に正確には、関係する１つ又は複数のセンサ、そのコーディネータ、又はなんらかの更に高位のコントローラ）は、危険な状態にあるパラメータを監視している１つ又は複数のセンサの「非常事態」の状態を宣言するものと更に仮定する。以下においては、これを、関係するネットワーク装置が「非常事態にある」と表現する。「装置との関係における非常事態の状態」とは、例えば、危険な状態にあるパラメータのセンサであることによって、或いは、そのようなセンサからデータを受信するコーディネータであることによって、装置が関与している非常事態を意味している。
【００６２】
この非常事態の状態を宣言する方法は、本出願の範囲外であるが、これは、本出願人による同時係属中の出願の主題である。BAN内の装置が非常事態にあるかどうかを判定するための仕組みが存在すると仮定すれば、そのような装置に対するストリーミングサービスを優先順位付けすることが望ましいであろう。即ち、非常事態の状態にあるなんらかのパラメータを検知しているBAN内のネットワーク装置の場合には、（それがストリーミング又は非ストリーミング法によってセンサデータを既に送信しているかどうかとは無関係に）その装置がそのセンサデータをコーディネータに対して確実にストリーミングできるようにすることが望ましい。
【００６３】
図１０は、医療装置及び非医療装置との関連におけるストリーミングアプリケーションの分類と、非常事態にあるかどうかという観点におけるその状態と、を示している。ここで、「医療装置」とは、患者の医学的な監視に関与している生命パラメータのためのセンサなどのシステムの構成要素を意味している。非医療装置の一例は、患者によって使用されるエンターテインメントシステムであってよいであろう。
【００６４】
クオリティオブサービス（QoS）という概念は、高帯域幅の無線通信システムにおいては、一般的になっているが、IEEE802.15.6のために提案されているものなどの低レートのWPAN及びボディエリアネットワークには、これまでのところ、適用されてはいない。図１０の分類には、非常事態にある装置からのデータのストリーミングのための最高のQoSレベル（クラス１及び２）と、非常事態にはない医療装置からのデータのストリーミングのための中程度のレベル（クラス３）と、非医療装置からのデータのストリーミングのための最低のレベル（クラス４）と、という３つのQoSレベルを伴う４つのストリーミングクラス１〜４が規定されている。ストリーミングクラス１及び２は、QoS及びビットレートの観点において同等であるが、クラス１（医学的非常事態）は、非医学的非常事態（クラス２）よりも高い優先順位を具備している。クラス２は、いくつかの実装においては、使用されないであろうが、おそらくは、医学的な検知を安全性又は侵入の監視と組み合わせたその他の実装においては、非医療装置も非常事態の状態に移行することができよう。
【００６５】
この分類を使用することにより、図１１は、異なるアプリケーションに異なるストリーミングビットレートを割り当てるべく利用されるスケジューリングメカニズムを示している。説明対象の手順においては、いくつかのネットワーク装置を有するBAN内のコーディネータが、このスケジューリングタスクの責任を担うものと仮定している。但し、コーディネータは、このタスクにおいて、中央監視ユニットなどのBANの内部に提供された又はBANのために提供されたなんらかの形態の更に高位の制御装置から支援又は指示を受けることも可能であろう。
【００６６】
本実施例は、当業者には周知のネットワーク内の２つの地点の間にセットアップされるストリーム用のコンジットとしての「データパイプ」の概念を利用する。
【００６７】
まずは、データパイプに対する要求、又は、換言すれば、データ送信及び／又は受信のための特定のリソース又はスロットの割当に対する要求が、別のネットワーク装置からコーディネータ１０に到来するものと仮定する（ステップＳ１１）。このような要求は、まったく新しいストリームに対する要求であってもよく、或いは、既にセットアップ済みのストリームを変更するための要求であってもよいことに留意されたい。次いで（Ｓ１２）、コーディネータは、要求がストリーミング要求（スーパーフレームごとなどの帯域幅の持続的な割当に対する要求）であるかどうかを判定する。ストリーミング要求ではない場合には（Ｓ１３）、コーディネータは、ネットワーク装置に対してストリーミングを伴うことなしにリソースを割り当てるための手順を実行する。ストリーミング要求の場合には（Ｓ１４）、次いで、コーディネータは、要求が医療装置からのものであるかどうかを判定する。医療装置からのものではない場合には（Ｓ１５）、コーディネータは、図１０に示されている最低のQoSレベルを使用することにより、ストリームをセットアップする。要求が医療装置からのものである場合には（Ｓ１６）、コーディネータは、ネットワーク装置が非常事態にあるかどうかを検討する。コーディネータは、これをいくつかの方法によって認知可能であるが、これは、本発明の範囲外である。例えば、ネットワーク装置から受信したデータパイプに対する要求を含むフレームが、特殊な非常事態フレームタイプを使用することにより、非常事態の状態を通知することができよう。ネットワーク装置が非常事態にない場合には（Ｓ１７）、コーディネータは、図１０に示されている中程度のQoSレベルを設定する。一方、ネットワーク装置が非常事態にある場合には、データパイプのために最高のQoSレベルを設定する（Ｓ１８）。この後に、データがパイプを使用してストリーミングされる。例えば、スーパーフレームごとに、１つのフレーム（CTA）を送信することも可能であり、或いは、スーパーフレームごとに、複数のフレームを割り当てることも可能であり、或いは、ｎ個のスーパーフレームごとに、１つのフレームを実現することも可能であり、それぞれのフレームは、CFP３７内において１つ又は複数のスロットを占有している。
【００６８】
従って、図１１のフローチャートに示されているように、非常事態にあると共にストリーミングデータの送信を所望している医療装置に対して、最高の優先順位が付与される。
【００６９】
以下、図１２〜図１９を参照し、本発明の一実施例によるネットワーク装置との間のストリームをスケジューリングする様々なシナリオにおけるコーディネータ１０の動作について説明することとする。
【００７０】
関連するすべてのネットワーク装置に対してサービスする際にコーディネータが利用可能なリソース（無線帯域幅）は、固定されたサイズの「データパイプ」の全体を提供することであると考えることができる。このデータパイプのサイズは、例えば、図４との関係において前述したように、スーパーフレームごとのCFP３７の持続時間によって決定されることになる。即ち、CFP内においてGTSを使用することにより、等時的なストリームをセットアップ可能である。
【００７１】
この実施例においては、コーディネータが利用可能なストリーミングデータパイプは、医学的な非常事態のためのデータパイプと、非常事態にはない医療のためのデータパイプと、非医療アプリケーションのためのデータタイプと、という３つの主要な部分に分割されるものと仮定する。特定の数の医療ストリーミングアプリケーション装置が非常事態の状態に移行した際には、常に、その他の２つの種類のストリームは、更なる通知の時点まで、制限又は中断される。
【００７２】
図１２は、コーディネータが、様々な装置を、その状態の深刻さに従って、そのストリーミングのニーズの観点において調整する際の代表的なシナリオを示している。即ち、非医療ネットワーク装置１３は、既存のストリーミングデータパイプ（淡いシェードによって示されている）を使用することにより、コーディネータ１０への（又は、これからの）データをストリーミングしており、非常事態にはない医療装置１１Ｄは、（中程度のシェードによって示されている）別の既存のパイプを介してストリーミングしている。所与の医療パラメータを更に詳細に監視できるように、装置１１Ａがそのセンサデータをコーディネータにストリーミングする必要があるという旨を通知する要求を、現在非常事態にある医療装置１１Ａから、コーディネータが受信したと仮定しよう。
【００７３】
コーディネータ１０は、残りのデータパイプについて検討する。十分なデータパイプが利用可能である場合には、コーディネータは、図１３に示されているように（濃いシェード）、非常事態のデータパイプをネットワーク装置１１Ａに対して割り当てることができる。この割り当てられたデータパイプは、その他のデータパイプと比べて、高優先順位のデータパイプであり、且つ、相対的に幅が広く示されており、これは、その他のパイプよりも高いデータレートを有する「太い」データパイプであることを意味している。この結果、装置１１Ａは、このデータパイプを使用することにより、センサデータの送信を開始する。装置１１Ａは、例えば、医療パラメータを詳細に監視することができるように、幅の広いデータパイプを活用して、以前よりも頻繁に読取値を取得し、且つ、読取値をコーディネータにストリーミングすることができる。
【００７４】
但し、非常事態にあるネットワーク装置１１Ａが、常に幅の広いデータパイプを必要とするわけではないことに留意されたい。検知される医療パラメータに応じて、ストリーミングを要するデータが限られた量しか存在していない場合もあり（例えば、患者の脈拍数）、且つ、この場合には、相対的に狭いパイプで十分であろう。この例においては、量よりも、（例えば、スーパーフレームごとに帯域幅が提供されることを保証する）割当の優先順位が重要であろう。
【００７５】
この段階において、更に、別の医療装置１１Ｂが非常事態の状態となった（に移行した）としよう。これは、例えば、医療装置１１Ａによって監視されているパラメータに加えて、患者の状態のなんらかの悪化に起因して、医療装置１１Ｂによって監視されている生命パラメータも危険な状態となった場合に、発生することがある。装置１１Ｂは、図１４に示されているように、ストリーミング要求をコーディネータ１０に送信する。コーディネータ１０は、それまで他の装置によって占有されていない残りの利用可能なストリーミングパイプについて再度評価する。十分なリソースが利用可能である場合には、このストリーミング要求は、図１３におけるものと同様の方法により、単純に認可される。一方、リソースが不十分である場合には、コーディネータは、ストリーミングを停止することによってそのデータパイプを新たに非常事態となった医療装置のために放棄する非医療装置を判定する。
【００７６】
次いで、コーディネータは、図１５に示されているように、そのストリーミングを一時的に停止させるべく、信号（コントロールフレーム）を非医療装置１３のうちの１つ又は複数ものに送信する。図１６に示されているように、非医療装置のうちの１つ又は複数のものが、そのストリーミングを停止し、且つ、パイプが、非常事態にある医療装置に対して割り当てられる。即ち、図１５に示されているコーディネータ１０とネットワーク装置１３の間の淡いシェードの細いパイプが、コーディネータ１０と医療装置１１Ｂの間の幅の広い濃いシェードのパイプによって置換されている。
【００７７】
上述の図は、わかりやすくするべく、データパイプの停止を伴っているが、既存のストリームを制限し、これにより、更に低いビットレートにおいて継続させるようにすることにより、リソースを利用可能な状態にすることも可能であることに留意されたい。
【００７８】
極端なケースにおいて、非常事態のストリーミング医療装置に対して割り当てられておらず、むしろ、非医療装置又は非常事態にはない医療装置に対して割り当てられたスーパーフレーム内のリソースが存在する場合には、コーディネータは、ストリーミングの遅延を低減するべく、それらのリソースを非常事態にある医療装置に対して更に割り当てることができよう。一方、非常事態のストリーミング装置に対する既存の割当が、許容可能なQoS及び遅延プロファイルを既に提供している場合には、非常事態にはないアプリケーションからリソースを取り戻す必要はない。例えば、非常事態のストリーミングアプリケーションが、（例えば、センサの特性に起因して）低ビットレートを持ち、且つ、必要なQoS及び遅延のために、データパイプの２０％しか必要としていない場合には、パイプ全体の５０％をこの装置に対して割り当てる必要はなく、その理由は、これが、非常事態にはない装置における望ましくない遅延及びパケットの破棄に結び付くことになるからである。
【００７９】
次に、図１７に示されているように、更なる医療装置１１Ｃが、非常事態に移行し、且つ、ストリーミングデータパイプを必要とすることになった状況について検討する。
【００８０】
コーディネータは、前述のものに類似した手順を実行する。停止させるべき非医療パイプがもはや存在しない場合には、コーディネータは、非常事態にはない医療装置に注目し、且つ、この新しい非常事態にある装置に対応するべく、そのストリーミングデータパイプを一時的に放棄するようにそれらの装置に対して求める。ここで、「求める」は、コーディネータから関係する装置に対して送信される要求（又は、コマンド）を伴うものであってよい。コーディネータは、許可を必要することなしに、それらの装置に対するストリームを単純に切断することも可能であるが、ネットワーク内における調整された状態を維持すると共にデータの消失を回避するべく、コーディネータは、影響を受ける装置に対して通知することが好ましい。図１８に示されているように、データパイプが、非常事態にある新しい装置に対して割り当てられる。
【００８１】
ネットワークによって検知されている１つ又は複数のパラメータの非常事態の状態は、一時的にしか持続しないと予想可能である。例えば、医学的な監視の場合には、非常事態の状態が通知され、且つ、関連するパラメータが、所定の期間にわたって、ネットワーク装置によって詳細に観察されたら、医療スタッフが、その状態を安定化させるべく、患者を看護可能であろう。或いは、産業設備を監視する場合には、なんらかの処置を講じて非常事態の原因を除去することができよう。非常事態が解除された際には、装置は、図１９に示されているように、なんらかの異なるパイプの構成に復帰可能である。医療装置１１Ｂ及び１１Ｃが非常事態を離脱しており、且つ、利用可能なデータパイプがこれらの間において分割されていることを観察可能である。これらの装置には、直径の観点において小さなパイプ（即ち、小さなビットレート）が付与されている。
【００８２】
図２０Ａ及び図２０Ｂは、提案する非常事態アプリケーション用の詳細なシグナリングプロトコルを示している。このフローチャートは、２つの部分に分かれており、上半分（ステップＳ２１〜ステップＳ２７）は、新しい非常事態の状態に応答して講じられる処置に関係しており、且つ、下半分（Ｓ３１〜Ｓ３６）は、非常事態の解除の際の手順に関係している。
【００８３】
まず最初に、医療ネットワーク装置１１Ｂ（以下においては、単純にセンサとも呼称する）が非常事態に移行したとしよう（Ｓ２１）。これは、前述のように、ネットワーク装置によって検知されているなんらかのパラメータがなんらかの種類の臨界値に到達したことを意味している。以下においては、関係するネットワーク装置が「非常事態にある」と表現する。
【００８４】
ステップＳ２２において、非常事態にあるネットワーク装置１１Ｂが、ストリーミング要求をコーディネータ１０に送信する。この要求は、先程概説したIEEE802.15.4などのフレームに基づいたシステムを仮定した場合には、フレームヘッダ内の１オクテットの長さのサブフィールドの形態を有することができる。
【００８５】
ステップＳ２３において、コーディネータ１０は、十分なリソースが利用可能であるかどうかを検討し、且つ、利用可能である場合には、必要とされている割当を単純に認可する。そうでない場合、即ち、要求を即座に認可するには不十分な未使用リソースしか存在していない場合には、コーディネータ１０は、ストリーミングを停止させるように１つ又は複数の非医療装置１３に対して求める。そして、コーディネータは、更なる処理の前に、１つ又は複数の非医療装置１３からのなんらかの形態のアクノリッジメントを待つことができる。
【００８６】
次いで、ステップＳ２５において、コーディネータ１０は、再度、十分なリソースが利用可能であるかどうかをチェックする。この段階で、回答が「はい」である場合には、ネットワーク装置１１Ｂのためのデータパイプが認可される。回答が依然として「いいえ」である場合、即ち、１つ又は複数の非医療装置の終了によっても十分なリソースが確保されない場合には、コーディネータ１０は、現時点において非常事態にはない１つ又は複数の医療装置１１Ｄへのストリーミングを停止させるための要求／コマンドを送信する（Ｓ２６）。最後に（Ｓ２７）、コーディネータは、要求されたストリーミング割当を装置１１Ｂに対して認可する。
【００８７】
時間の経過に伴って、装置１１Ｂが、自身がもはや非常事態の状態にはない、換言すれば、非常事態を「離脱」したことを見出したと仮定しよう（Ｓ３１）。コーディネータ１０は、なんらかの方法により、この事実を認知する。例えば、自身が非常事態にあるかどうかをそれぞれのネットワーク装置（センサ）が自身で判定するには、それぞれのネットワーク装置があまりにも単純である場合には、これを判定するのは、コーディネータであってよい。或いは、この代わりに、コーディネータ１０は、ネットワーク装置１１Ｂ自体から又は更に高位の制御ユニットから通知を受信することも可能である。次いで（Ｓ３２）、コーディネータは、装置１１Ｂがもはや必要としていないリソースを割り当てし直す方法を算出する。ステップＳ３３において、コーディネータ１０は、更新されたストリーミングパイプサイズに関する通知（例えば、コマンドフレーム）を装置１１Ｂ、１１Ｄ、及び１３のそれぞれのものに対して送信する。これを実行する際には、コーディネータは、図１０の表及び図１１のフローチャートを使用して判定される優先順位レベルを考慮することになる。
【００８８】
ステップＳ３４において、なんらかのその他の非医療装置１３が、ストリーミング割当に対する新しい要求を生成したとしよう。コーディネータ１０は、十分な未使用リソースが利用可能であるかどうかを判定し（Ｓ３５）、且つ、「いいえ」である場合には、データパイプを認可しない（非医療装置は、最低の優先順位を有するものと考えられており、従って、非常事態にある又はない医療装置に対する既存の割当を変更するニーズが存在しないためである）。但し、Ｓ３５において、「はい」である場合には、コーディネータは、要求された割当を認可する（Ｓ３６）。
【００８９】
図２１は、図９に示されているIEEE802.15.4のフレームフォーマット４２に略対応するフレームフォーマット４２’（MACレイヤのみ）を示している。このフォーマットは、様々なタイプのQoSを内蔵すると共にIEEE802.15.6に好適なものにするためのIEEE802.15.4のフレームフォーマットに対する１つの可能な変更である。新しく規定された１オクテットのストリームインデックス５２が、データストリーミングの特性及び必要とされるビットレートと関係したシグナリング情報の搬送の責任を担っている。ストリームインデックス５２は、次の表に示されている値をとることができる。
【００９０】
【表１】
0005472326.tif 000002
【００９１】
この表は、医療装置に加えて、非医療装置も、非常事態になり得るという可能性を認めていることに留意されたい。ここで、ネットワーク装置は、表中の任意の値に設定されたストリームインデックスを有する要求をコーディネータに対して送信する。ストリームインデックスが値0x00に設定されている場合には、これは、装置が新しいストリームを要求していることを意味している。又、コーディネータは、非常事態の状態の通知（即ち、非常事態ビット）をも受信する。次いで、その利用可能なリソースに基づいて、コーディネータは、要求を生成した装置に返送するべく、ストリームインデックスを同一の表中の値のうちのいずれかのものに割り当てる。割り当てられたストリームインデックス値が0x00に設定されている場合には、これは、コーディネータが、要求を生成した装置に対してリソースを割り当てなかったことを意味している。その他の値は、表に従って解釈される。
【００９２】
装置が既にストリームを確立していると仮定すれば、装置は、0x00を除く表中の任意の値に設定されたストリームインデックスを送信することになる。この場合には、装置からコーディネータに対して生成される要求内のストリームインデックスは、装置が、既存のストリームの変更を所望していることを意味している。コーディネータが0x00に設定されたストリームインデックスを送信した場合には、これは、コーディネータがストリームを終了させることを意味している。
【００９３】
換言すれば、それぞれのストリームには、数値（ストリームインデックス）が付与され、且つ、この数値が設定されている範囲により、コーディネータは、ストリームのタイプを判定する。予約済みのフィールドである0x00は、未割り当てストリームのためのものであり、且つ、ネットワーク装置は、これを使用し、新しい等時的なストリームの生成をコーディネータに対して要求することになる。ネットワーク装置は、データストリームのセットアップの際にコーディネータによって動的に割り当てられるように、且つ、上掲の表に示されているように、ストリームインデックスのその他の値を使用する。コーディネータは、BAN内のそれぞれの等時的なストリームごとに、一意のストリームインデックス値を割り当てる。ストリームインデックスを割り当てし直すことにより、コーディネータは、図１２〜図１９との関係において前述した方式により、リソースを割り当てし直すことができる。
【００９４】
本発明の新しい特徴を既に提案済みのフレーム構造に内蔵するための更なる技法として、MACコマンドフレームのコマンドフレーム識別子を使用可能である（図９Ｂを再度参照されたい）。MACコマンドフレームは、コマンドフレーム識別子フィールド４４０を包含していることを思い起こされたい。図２２は、IEEE802.15.4の仕様において予備とされている２つのビット値を使用することによる、チャネル時間要求のための0x0cと、チャネル時間応答のための0x0dと、という新しいフレーム識別子の追加を示している。
【００９５】
装置がコーディネータに対してストリームを要求するために、IEEE802.15.3に提供されているものに類似したチャネル時間要求（CTRq）と呼ばれる追加のMACコマンドをIEEE802.15.4のMACコマンドフレームの表に導入する。コーディネータは、IEEE802.15.3から導入されたMACコマンドフレームとしてのチャネル時間応答を使用することにより、この要求に応答することになる。
【００９６】
以上のプロトコルは、センサ及びコーディネータのみを伴っている。但し、MBANは、前述のように、いくつかのコーディネータがなんらかの形態の中央モニタに対して報告する方式によって実装することも可能であり、これは、自動的なものであってもよく、或いは、人間の監督下におけるものであってもよい。例えば、このような中央モニタは、病院内において何人かの患者を管理している病室担当看護師の机上に配置可能であろう。このシナリオにおいては、中央モニタとの間において転送されると共に非常事態にあるネットワーク装置に属するデータ（例えば、コーディネータが中央モニタに中継する非常事態にあるネットワーク装置からの検知データ）も、同一の方法によってストリーミング可能である。更には、前述のように、このような中央モニタは、コーディネータのスケジューリングタスクを支援（し、或いは、場合によっては、これを代わりに実行）することも可能であろう。
【００９７】
以上の説明においては、中央モニタの包含が可能であるものの、無線センサネットワーク内におけるセンサ及びコーディネータのみを参照しているが、MBANは、これらの種類以外のその他の装置を包含することも可能である。潜在的に、投薬メカニズム又はその他のアクチュエータ装置などの患者の治療に介入するなんからの手段を、コーディネータ及び／又は任意の中央モニタの無線による制御下において、ネットワーク内に配置可能であろう。従って、本発明によって可能になるストリーミングは、センサデータに限定されるものではなく、例えば、薬品を患者に供給して心拍数などの生命パラメータを安定化させるためのコーディネータからそのようなアクチュエータ装置への制御値のストリームであってもよいであろう。
【００９８】
通常、以上において参照された非常事態の状態は、患者の医学的な状態となるが、その理由は、これが、本発明の重要な用途として考えられるためである。但し、これは、唯一の可能な用途ではない。センサを使用し、非医学的な状況において生体を監視可能であろう。例えば、センサのBANを使用することにより、リスクを有する任意の人物（例えば、高齢の又は虚弱な人々や子供、危険な環境にある人々など）を監視可能であろう。この場合には、非常事態の状態は、事故などのなんらかの形態の物理的な脅威を表すことになり、且つ、この場合にも、ストリーミングを利用し、非常事態の監視に関係するセンサとの間の通信の信頼性を改善することができよう。例えば、ストリームは、生体に着用されたカメラからのリアルタイムビデオを包含可能であろう。
【００９９】
更には、本発明は、生体上における使用に限定されるものではない。人間の又はその他の生体上のBAN以外にも、多数の可能性が存在している。１つの可能性は、ミッションクリティな産業環境（例えば、発電所）における多数の潜在的なシナリオなどの産業的な非常事態を検出する能力を有するＷＳＮである。これは、工場の環境における多数の制御点に提供可能である。例えば、本発明者らは、工場の加熱設備内の温度センサ又は食品製造ライン用の圧力閾値を想定可能である。更には、前述のように、非医療装置は、例えば、煙や保護されたエリア内への人物の侵入を検出した際に非常事態を宣言することにより、安全及びセキュリティのために使用することも可能であろう。前述のストリーミング及びQoSの基準は、医学的な非常事態におけると同様に、これらのシステム内における非常事態に対しても適用可能である。従って、請求項中における「エンティティ」という用語は、生物に加えて、このような任意の産業環境をも包含するものと解釈されたい。
【０１００】
従って、本発明の実施例は、以下の特徴のいずれかのものを具備可能である。
・ストリーミングシーケンス及びその割り当てられたデータレート（即ち、データパイプの太さ）のスケジューリングへの非常事態の状態の関連付け
・非医療アプリケーション及び非常事態にはない医療アプリケーションが存在する状況においてストリーミングデータパイプをスケジューリングするべく特別に設計された優先順位に基づいた新しいスケジューリングメカニズム
・非常事態の医療アプリケーションの最高優先順位による処理を可能にするデータストリーミングのための新しい要求メカニズム
・IEEE802.15.4用の新しいストリーミング要求フィールドを導入することによるＩＥＥ８０２．１５．６用の関係する新しいコントロールフレーム構造
・データレート及び遅延の３つのクラスに依存したアプリケーションの特性（医療及び非医療）及び潜在的な非常事態に対するストリーミングのQoSの潜在的なマッピング
・非常事態のストリーミングデータが存在する際の非医療ストリーミングの低速化及び更には停止の概念
【産業上の利用可能性】
【０１０１】
本発明の実施例は、以下の利点のうちの１つ又は複数のものを提供可能である。
【０１０２】
（ａ）多数の新たに登場する無線センサ医療アプリケーションは、データストリーミングの可能性を具備している。特に非常事態における医療データのストリーミングは、困難なタスクである。本特許出願における提案は、非常事態における安全なデータパイプの提供を保証している。提案したストリーミングのスケジューリングメカニズムによれば、利用可能なデータレートを非常事態の医療サービスと非常事態にはない医療サービスの間において公平に分割可能である。
【０１０３】
（ｂ）提案したスケジューリングメカニズムは、動的であり、これは、非常事態の状態の解除に応答して、非−非常事態ストリームのストリーミングを再開するか又は更に高いデータレートに戻すことにより、医学的な状況の深刻さを考慮したリソースの公平な割当を提供可能であることを意味している。
【０１０４】
（ｃ）非常に危険な非常事態アプリケーションにおけるストリーミングデータの品質の劣化が回避され、ヒューマンエラーが低減され、且つ、非常事態の状態に移行可能な患者の生命が潜在的に救われる。
【０１０５】
（ｄ）医療システムにおける非常事態への応答の人件費及び効率が改善される。
【０１０６】
（ｅ）非常事態にあるセンサからのセンサデータの信頼性の高い送信を円滑に実行することによって医療MBANシステムにおける非常事態の認知度が改善される。
【０１０７】
本発明の実施例は、MBANの使用による非常事態管理を円滑に実行する際に極めて重要な役割を果たすことができる。以下のシナリオに留意されたい。
【０１０８】
（ｉ）心臓に問題を有する世界中の数億人の患者を、彼らの身体上においてMBANを形成する無線センサを利用することにより、病院において、又は自宅において、監視可能である。MBANは、このような患者に更なる移動性を提供可能である。但し、心機能の異常や心臓発作などの更に深刻なケースなどの状況にある患者のグループの場合には、信頼性の高い通信チャネルを確保して非常事態又はアラーム信号を見逃さないことを保証することが極めて重要である。本発明は、即時アクノリッジメント又は「非常事態アクノリッジ」を送信することにより、関与しているすべてのエンティティに非常事態について認知させるための信頼性の高い非常事態トリガメカニズムを提供する。
【０１０９】
（ｉｉ）世界中で数億人の人々が糖尿病を患っている。最近、グルコースの測定のための埋植可能な又は非侵襲的な方法が検討されている。MBANを使用し、２４時間にわたって患者のグルコースレベル情報を監視可能である。患者のグルコースレベルがチャートを逸脱し、且つ、患者のための非常ジオロケーション及びその他の必要な緊急的な医学的手順が必要とされる状況が存在する。
【０１１０】
（ｉｉｉ）MBANを使用することにより、データの消失によって生命が脅かされる可能性がある集中治療の状態にある患者を監視しつつ、検知データを収集可能である。
【０１１１】
（ｉｖ）医療システムにおける非常事態への応答の人件費及び効率が改善される。
【０１１２】
（ｖ）医療MBANシステムにおける非常事態の認知度が改善される。
【０１１３】
（ｖｉ）非常事態への応答プロセスを自動化することにより、人件費が低減される。
【０１１４】
（ｖｉｉ）主には、低データレートのアプリケーションが想定されているが、MBANは、個々のパケットの消失が致命的であると共に品質に影響を及ぼすストリーミングビデオ／オーディオデータの転送に適用することも可能であろう。非常事態の状況においては、誤ったデータは、疾病の診断に悪影響を付与するおそれがある。
【０１１５】
（ｖｉｉｉ）医療診断の場合には、ＭＭＲ又はＸ線画像は、医師が患者を適切に診断するべく、非常に明瞭であることを要する。従って、この場合にも、信頼性の高いデータ転送が不可欠である。
【０１１６】
要すれば、本発明は、無線センサネットワーク内においてリソースを割り当てる技法を提供可能であり、ネットワークは、センサを具備する複数のネットワーク装置を使用する患者の医学的な監視を含む機能を具備しており、方法は、患者の生命パラメータをネットワーク内のネットワーク装置によって検知するステップと、パラメータとの関係における非常事態の状態の存在を認識するステップと、ネットワーク装置がストリーミングに対する要求をネットワークのコーディネータに向かって送信するステップと、コーディネータがその要求をネットワーク内の他の装置からの任意の他の要求と共に受信するステップ（Ｓ１２）と、コーディネータが、それぞれ、非常事態の状態にあるネットワーク装置のための最高優先順位を有するストリーミング割当と、非常事態の状態にはない生命パラメータを検知しているネットワーク装置のための中程度の優先順位のストリーミング割当と、患者の生命パラメータを検知してはおらず、且つ、非常事態にもないネットワーク装置のための最低優先順位のストリーミング割当と、のうちの１つをスケジューリングすることにより、要求を認可するステップ（Ｓ１４、Ｓ１６）と、を含む。非常事態の状態は、患者の１つ又は複数の医療パラメータとの関係において規定可能である。この方法は、例えば、IEEE802.15.6に従って稼働するMBANを使用する病院内における患者の監視に適用可能である。
【０１１７】
本発明は、新しいセンサ、コーディネータ、又はこれらのためのハードウェアモジュールの形態をとることが可能であり、且つ、１つ又は複数のセンサ及び／又はコーディネータのプロセッサによって実行されるソフトウェアを置換又は変更することにより、実装可能である。
【０１１８】
従って、本発明の実施例は、ハードウェアにおいて、或いは、１つ又は複数のプロセッサ上において稼働するソフトウェアモジュールとして、或いは、これらの組合せとして、実装可能である。又、本発明は、本明細書に記述されている技法のいずれかのものの一部又はすべてを実行する１つ又は複数の装置又は機器プログラム（例えば、コンピュータプログラム及びコンピュータプログラムプロダクト）として実施可能である。このような本発明を実施するプログラムは、コンピュータ可読媒体上に保存可能であり、或いは、例えば、１つ又は複数の信号の形態を有することも可能であろう。このような信号は、インターネットウェブサイトからダウンロード可能なデータ信号であってよく、或いは、搬送波信号上において、又は任意の他の形態において、提供することも可能である。
【０１１９】
以上の説明においては、一例として、IEEE802.15.4及びIEEE802.15.6を参照しているが、本発明は、IEEE802.15.6に従って動作するかどうかとは無関係に、任意のタイプのフレームに基づいた無線センサネットワーク又はMBANに対して、且つ、医療ボディエリアネットワークではない場合にも、非常事態の状況における通信の信頼性の改善に対する要件を具備するその他のタイプのBANに対して、適用可能である。
【図１】
0005472326.tif 000003
【図２】
0005472326.tif 000004
【図３】
0005472326.tif 000005
【図４】
0005472326.tif 000006
【図５】
0005472326.tif 000007
【図６】
0005472326.tif 000008
【図７】
0005472326.tif 000009
【図８】
0005472326.tif 000010
【図９Ａ】
0005472326.tif 000011
【図９Ｂ】
0005472326.tif 000012
【図１０】
0005472326.tif 000013
【図１１】
0005472326.tif 000014
【図１２】
0005472326.tif 000015
【図１３】
0005472326.tif 000016
【図１４】
0005472326.tif 000017
【図１５】
0005472326.tif 000018
【図１６】
0005472326.tif 000019
【図１７】
0005472326.tif 000020
【図１８】
0005472326.tif 000021
【図１９】
0005472326.tif 000022
【図２０Ａ】
0005472326.tif 000023
【図２０Ｂ】
0005472326.tif 000024
【図２１】
0005472326.tif 000025
【図２２】
0005472326.tif 000026