JP2019506024A - ボディエリアネットワークのためのＱｏＳを考慮したアドミッション制御 - Google Patents

Abstract

異種データトラフィックタイプを含むネットワークに対するQoSを考慮したアドミッション制御のシステムおよび方法が提供される。本開示の実施形態では、トラフィックタイプが異種であるということから生じる異なるサービス品質(QoS)要件を考慮して、新しいフローにネットワーク内へのアドミッションを与えるために十分なリソースが利用可能であるかどうかを決定する際にネットワーク内のいくつかのデータフローに対する1つまたは複数の接続パラメータを考慮する。さらに、様々な実施形態では接続パラメータに対する異なる調整オプション、終了オプション、またはその両方の組合せをトラバースしてフローおよび接続パラメータの最適な集合を識別し、より高いランクのフローと引き換えにより低いランクのデータフローにアドミッションを与えられないことを確実にしながら帯域幅効率を達成する。

Description

開示されている技術は、主にボディエリアネットワーク(BAN)に関し、より具体的には、サービス品質(QoS)パラメータを考慮した異種データトラフィックタイプ(heterogeneous data traffic type)およびアドミッション制御(admission control)に関するいくつかの実施形態である。

ワイヤレスBANは、出現したばかりの新しいタイプのワイヤレスネットワークであり、日常的に使用するユーザ向けの健康維持および健康増進に利用されることから大きな注目を集めている。BANの主要ターゲットは、身体に取り付けられるか、または植え込まれ得るセンサを含む、医療用身体センサ(medical body sensor)、さらには薬物伝送デバイス、またはペースメーカーなどの、医学的介入を行うデバイス(「アクチュエータ」と称される)である。

BANは、トポロジー(たとえば、ハブおよび1つまたは複数の身体センサを有するスター型トポロジー)、アプリケーション要件、および消費電力に関する特定の特性を有し、これにより、より広いワイヤレスパーソナルエリアネットワーク(PAN)と区別される。BANデバイスは、典型的には小さく、電池寿命も限られ、消費電力が大きな問題となる。

米国特許出願公開第2014-0292537号明細書

開示されている技術の様々な実施形態によれば、ボディエリアネットワークなどの、ネットワークのためのアドミッション制御の方法が提供される。いくつかの実施形態における方法は、ハブデバイスがフレーム周期の非予約周期(unreserved period)において参加要求メッセージ(join request message)を受信するように構成されていることを含み、ここで、参加要求メッセージは、接続ネットワークデバイスに関連付けられている要求データフローから受信される。参加要求メッセージは、接続ネットワークデバイスがネットワークに参加しようとする際に使用するメッセージである。参加要求メッセージを受信した後、ハブデバイスは、要求データフローに対する1つまたは複数の接続パラメータの利用可能な範囲を決定し、要求データフローに対するこれらの1つまたは複数の接続パラメータを、他の実施形態において利用可能な範囲の最大値のうちの最大値として定義され得る既定の接続パラメータに設定する。

次いで、ハブは、要求データフローに対する接続パラメータの決定された利用可能な範囲に基づき(たとえば、既定の接続パラメータに基づき)要求データフローにアドミッションを与える十分なリソースがネットワーク内で利用可能であるかどうかを決定する。ハブが十分なリソースが利用可能であると決定した場合、ハブは要求データフローにアドミッションを与える。それに加えて、いくつかの実施形態において、ハブは、調整オプション、終了オプション、またはこれらのオプションの組合せを識別するように設計されたアドミッション制御方式を実施するようにさらに構成されるものとしてよく、これらのオプションは要求フローにアドミッションを与えられるように結果としてネットワーク内で十分なリソースを利用可能にし得る。

開示されている技術の他の特徴および態様は、たとえば開示されている技術の実施形態による特徴を例示する添付図面と併せて取りあげられる次の詳細な説明から明白になるであろう。概要は、付属の請求項によってのみ定められる、本明細書で説明されている発明の範囲を制限することを意図しない。

1つまたは複数の様々な実施形態による、本明細書で開示されている技術は、次の図を参照しつつ詳細に説明される。図面は、例示のみを目的として用意されており、開示されている技術の典型的なまたは例示的な実施形態を示すだけである。これらの図面は、開示されている技術の読者の理解を円滑にするために用意されており、その広さ、範囲、または適用可能性の制限とみなされないものとする。明確に、容易に例示できるように、これらの図面は、必ずしも縮尺通りでないことに留意されたい。

本開示の技術の実施形態による例示的なワイヤレスボディエリアネットワーク(BAN)を示す図である。 本開示の技術の実施形態によるBAN動作時にBANデバイスがとり得る様々な状態を示す図である。 本開示の技術の実施形態によるBAN動作に対する例示的なフレーム構造を示す図である。 本開示の技術の実施形態によるBAN動作時のBANデバイス対する例示的な接続を示す図である。 本開示の技術の実施形態による例示的な帯域内シグナリングを示す図である。 本開示の技術の実施形態による例示的な接続パラメータ生成プロセスを示す図である。 本開示の技術の実施形態による例示的な接続プロセスを示す図である。 本開示の技術の実施形態による例示的な接続プロセスを示す図である。 本開示の技術の実施形態による例示的な接続プロセスを示す図である。 本開示の実施形態による利用可能な調整オプションの短い一覧に対する例示的な更新手順を示す図である。 本開示の技術の実施形態による、新しい参加要求を受信する前にネットワーク内に置かれている要求フローの集合が空集合でない例示的な接続プロセスを示す図である。 本開示の技術の実施形態による、新しいフローのアドミッションがさらなるアドミッションを引き起こす例示的な更新手順を示す図である。 開示されている技術の実施形態の様々な特徴を実装する際に使用され得る例示的なコンピューティングコンポーネントを示す図である。

図は、網羅的であることも、本発明を開示されている正確な形態に制限することも意図されていない。本発明は、修正および改変により実施され得ること、および開示されている技術は、請求項およびその等価内容によってのみ制限されることは理解されるべきである。

本明細書で開示されているシステムおよび方法は、通信ネットワークへの新しいフローの追加を協調させるように構成され、アドミッション決定におけるQoS要件を考慮するように構成され得る。いくつかの実施形態において、システムおよび方法は、要求フローの接続パラメータを、スレーブノードのそのQoS要件および物理的制約条件から決定するように構成され得る。新しい参加要求が受信されたときに、ネットワークハブは、既存のフローを取り除くことなくネットワーク内への要求フローにアドミッションを与えることができるかどうかを決定し得る。そうするために、ハブは、最初に、その要求が既定の設定で遂行され得るかどうかを考慮し得る。既定の設定で遂行され得ない場合、ハブは、既存のフローを再スケジュールするように構成され得る・これは、余分な、それでも最小の、エネルギー消費と引き換えであり得る。様々な実施形態における再スケジューリングは、既存のフローの接続パラメータを調整すること(連続する予約の間のスリープ期間を短縮することなど)によって達成され得る。好ましくは、再スケジューリングは、調整されたフローのQoS要件を損なわないように実行される。

いくつかのアプリケーションでは、再スケジューリングは、接続が進行中である間に帯域内シグナリングを通じて実行され得る。ハブは、また、ネットワークに入るアドミッションを要求フローに与えるために要求フローの接続パラメータを調整するように構成され得る。フロー調整オプションをトラバースするためのアルゴリズムは、スレーブノード上のエネルギー消費量を結果として最小限度に抑えるフロー調整オプションを探すときに無数の候補の全数検索を行うのを回避するように実装され構成され得る。したがって、そのようなアルゴリズムは、計算効率が高くなり得る。

調整が新しいフローのアドミッションを許さない状況において、新しいフローにアドミッションを与えられる十分な帯域幅を解放するために帯域幅効率が高くその上優先度を考慮したフロー終了アルゴリズムが呼び出され得る。さらなる実施形態において、AC問題への解決方法を識別するためにフローの集合の調整および終了の組合せが実装され得る。

本明細書で開示されているシステムおよび方法の実施形態は、多数の異なる通信ネットワークのうちのどれかを用いて実装され得る。そのようなネットワークの1つは、ワイヤレスボディエリアネットワーク、すなわちBANである。BANは、日常的に使用するユーザ向けの健康維持および健康増進に利用されることから大きな注目を集めている。BANは、トポロジー、アプリケーション要件、および消費電力に関する特定の特性を有し、これにより、より広いワイヤレスパーソナルエリアネットワーク(PAN)と区別される。一例として、BANは、通常、「ハブ」が中心ノードとして働く単純なスター型トポロジーを有する。リモートデータ処理/コマンドセンターは、感知および作動コマンドを、ハブを介して、身体内および身体の周りの複数の感知および作動「スレーブ」ノードに送信することができる。次いで、ハブは、センサデータを収集して、リモートデータ処理センターに送り返し、そこで、患者の健康状態を評価するためにセンサデータが処理され、マイニングされる。

開示されている発明の実施形態をより詳しく説明する前に、これらの実施形態のうちの様々な実施形態を実装する際に使用される例示的なネットワークが最初に説明され得る。この例示的なネットワークは、BANのネットワークである。この説明を読んだ後、本明細書で開示されているシステムおよび方法が他のネットワークを用いて、また他のネットワーキング環境内で、どのように実装され得るかが当業者に明らかになるであろう。

例示的なBAN環境は、図1に示されている。図1に示されている例示的なBAN104は、スター型トポロジー単一ホップネットワークにおいてハブ107にワイヤレス方式で結合される(108)デバイス109(身体センサおよびアクチュエータなどの、「スレーブ」デバイス)を備える。ハブ107は、ワイヤレスルーターまたはセルラータワーなどの、ワイヤレスアクセスポイント105、およびインターネットなどのネットワーク103を介して信頼できるサーバ102との、仮想プライベートネットワーク接続(VPN)などの接続101を形成する。たとえば、ハブ107は、スマートフォンまたは他のパーソナルワイヤレスデバイスを含むものとしてよく、Wi-Fiまたはセルラーデータプロトコルなどのネットワーキングプロトコルを介してアクセスポイント105に接続し得る。いくつかの実装形態において、ハブ107は、パーソナルコンピュータまたは他のパーソナルデバイス106との第2の接続110を--たとえば、Bluetooth接続などの直接接続を通じて、またはアクセスポイント105によって提供されるワイヤレスローカルエリアネットワークなどの間接接続を通じて--形成し得る。

BAN内のデバイス109は、典型的には着用可能または植え込み可能となるように設計されているので、デバイス(109)は、一般的にはその重量およびサイズによって極端に制限され、したがって一般的に制限された電源を有する。その一方で、ハブ107は、典型的には移動性が低く、アクセスしやすく、サイズも大きく、したがって、典型的には、電力消費要件もあまり厳しくない(たとえば、より大きい電源を有し得る)。

信頼できるサーバ102は、リモートデータ処理センター--たとえば病院に配置されている--を含むものとしてよく、そこでは、センサ109によって収集されたデータが処理されるかまたは記憶される。サーバ102は、ハブ107を介していくつかのコマンドをデバイス109に発行し得る。しかしながら、典型的な実装形態において、パーソナルデバイス106は、身体データにアクセスするためにのみ使用され、コマンドをデバイス109に発行することを許されない。

デバイス109は、通常、比較的低いデータ転送速度(100kbps程度)、低いデューティサイクル(1日の数分間の活動状態)、および比較的一定した接続持続時間(接続毎に数分)を有する。しかしながら、バースト性トラフィックがサポートされ得る。それに加えて、ネットワーク104は、通常、比較的安定しており、デバイス109はネットワーク104に参加するかまたはネットワーク104から離脱することは希である。

BANアプリケーションも、様々なQoS関連要件を課す。BAN内のトラフィックフローのデータ転送速度は、医療行為更新の低速間欠伝送(たとえば、数分に1回の体温レポート)からビデオフレームの高速伝送(たとえば、カプセル内視鏡からのビデオ)まで広い範囲にわたる。データ転送速度のほかに、様々なトラフィックパターンが各々、信頼性、遅延、および優先度などの自QoS要件を有し得る。たとえば、心拍数の急激な変化を報告するアラームメッセージは、患者の通常の日常的監視に関係するトラフィックフローに比べて高い優先度を有するものとしてよい。別の例として、ECGデバイスからのリアルタイムトラフィックは、血糖読み取り値など、あまり頻繁でないトラフィックほどには少数の時折生じるパケットドロップに対して敏感でないことがあるが、前者は後者よりも遅延に対して特に敏感である。したがって、BAN媒体アクセス制御(MAC)およびアドミッション制御(AC)ポリシーは、BANデバイスの消費電力を最低に抑えながら広範なQoS要件を充足することができるべきである。

BANおよび他の通信システムにおけるアドミッション制御では、デバイスがネットワークに接続することを可能にするために利用可能な十分なリソースがあるかどうかをチェックして決定する。上で指摘されているように、ACポリシーは、ネットワークデバイスの消費電力を低減するかまたは最低に抑えながら、広範なQoS要件を充足するように実装され得る。これは、デバイスが身体センサ(たとえば、図1のデバイス109)などの低消費電力を重視するデバイスである場合、またはたとえばネットワークデバイスとネットワークハブとの間の電力制限の非対称的な性質を考慮するために特に重要であり得る。ACは、特定のトラフィックタイプに対するQoS要件が伝送期間中に満たされることを確実にするために使用され得る。ACは、リソースが特定の伝送期間中に伝送されるすべてのデータに対して利用可能であることを確実にする。上で説明されているように、BAN通信の固有の特性のせいで、Wi-Fiおよびワイヤレス電気通信ネットワークに対する多くの現在のAC方式がBANに対して不適切なものになるか、またはBANに対して適用可能でないものにすらなる。たとえば、いくつかのネットワークシステムにおいて、ユーザ間に優先度はなく、ACは、早い者勝ち方式で取り扱われる。BANでは、異種トラフィックタイプにより、優先度方式が維持されることを確実にすることが重要になる。

実施形態は、接続パラメータおよびアドミッション制御方式の決定を使用して異種トラフィックタイプの異なるQoS要件を取り扱うように構成され得る。様々なQoS要件のいくつかの非制限的な例は、優先度指定、許容遅延、データ転送速度、および信頼性を含む。従来のAC方式では、これらを扱うことができない場合がある。たとえば、多くの従来のネットワークで使用される「早い者勝ち」方式では、より高い優先度要件を有する後に到着するフローを考慮することができない。BAN(または様々なQoS要件を有する他の類似のネットワーク)で「早い者勝ち」が利用された場合、高い重要度の後に到着するデータフローは、単純にハブによって受信された相対的時刻のせいでBANへのアドミッションを拒否され得る。さらに、データ転送速度要件(および場合によっては信頼性)の差は、WiFiネットワークのアドミッション方式--すべてのトラフィックにアドミッションを与えるが、利用者が過剰になったときにスループットを低下させる--も、BANには適用可能でないことを意味する。スループットが低下した場合、いくつかのフローは、データ転送速度のQoS要件を満たせないことがあり、BANへのアドミッションが役立たなくなる。

本明細書で開示されている技術の実施形態は、BANなどのネットワーク内でリソースを割り振るための方法を対象とするものである。より具体的には、本明細書で開示されている技術の様々な実施形態は、ACプロセスにおける異種トラフィックタイプの様々なQoS要件を考慮しながら、BAN内でデータを伝送することを要求するデータフローに対する接続パラメータを与える。それぞれのフローに対する接続パラメータは、たとえば、フローのQoS要件、さらには関連付けられているBANデバイスのバッファサイズおよび電力制約条件に基づきいくつかのパラメータ(たとえば、アロケーションスロットギャップ、アロケーションスロットサイズ、接続持続時間)に対する利用可能な範囲を識別することによって決定され得る。さらに、様々な実施形態は、異種フローに対する接続パラメータの識別された範囲を利用するように設計されているAC方式に関係する。新しい参加要求がBANデバイスから受信された後、ハブは、既存のフローを取り除くことなくBAN内への要求フローにアドミッションを与えることを試みる。既存のフローは、データを伝送するためにBAN内へのアドミッションをすでに与えられている別のBANデバイスに関連付けられているデータフローである。ハブは、余分な、その上小さいか、または最小であるエネルギー消費と引き換えに、既存のフローを再スケジュールすることによって参加要求に応じようとする。様々な実施形態における再スケジューリングは、既存のフローの接続パラメータを調整すること(たとえば、連続する予約の間のBANデバイスに対するスリープ期間を短縮すること)によって達成され得る。

さらなる実施形態において、再スケジューリング単独では新しい接続を使用可能にするのに不十分である場合に、優先度を考慮したフロー終了が適用され得る。優先度を考慮したフロー終了は、より低い優先度の1つまたは複数のフローを終了させてより高い優先度のフローにアドミッションを与えられるように構成され得る。同様に、この技術は、より低いランクのフローにアドミッションを与えるためにより高いランクのフローが終了させられることのないように構成され得る。いくつかのアプリケーションでは、AC方式への最適な解決方法を見つけるために接続パラメータ調整およびフロー終了の組合せが利用されてよく、それにより、優先度を考慮した方式で最大数の接続が維持される。

本明細書で開示されている技術の様々な実施形態について説明する際に、Table 1(表1)内の表記が参照される。

図2は、本明細書で開示されている技術の実施形態によるネットワーク動作時にBANデバイス(たとえば、デバイス109)がとり得る様々な状態を示す。例示されているように、各BANデバイスは、非関連付け状態201から始まる。非関連付け状態201において、BANデバイスは、ネットワークの一部でない(たとえば、ハブまたはサーバとの信頼関係を構築していない)。BANに参加するために、BANデバイスは関連付けプロセス202を完了させ、そこで、ハブとBANデバイスとの間の信頼関係が確立される。関連付けプロセス202は、デバイスからハブに関連付け要求メッセージを伝送するステップを含む。それに加えて、関連付けプロセス202においてネットワークへのBANデバイスの接続を初期化するために必要なサーバからのシグナリングが発生し得る。それに加えて、緊急要求期間(緊急対応デバイス)にアクセスすることができるデバイスは、関連付けプロセス202においてハブに登録することができる。

BANデバイスがネットワークに関連付けられた202後、BANデバイスは非接続状態204にある。非接続状態204において、BANデバイスは、ハブとの信頼関係を含む、ネットワークとの関連付けを保持する。たとえば、デバイスが非接続状態204に入った後、サーバからのシグナリングなしでセッション鍵が生成され、交換され得る。非接続状態204にあるデバイスは、典型的にはスリープ状態にある。しかしながら、いくつかの場合において、デバイスは、非予約通信期間(以下で説明される)を使用して、非接続状態204である間にハブと通信し得る。ハブでは、非接続状態204にあるデバイスがスリープしていると仮定し、非接続デバイスに対するダウンリンクパケットをスケジュールしない。その代わりに、保留中のダウンリンクパケットがある場合、ハブは、デバイスのIDをウェイクアップクリスト(以下で説明される)にポストする。

ハブに伝送すべきデータがデバイスにあるときに、デバイスは接続プロセス206を実行して接続済み状態205に入る。たとえば、デバイスは、接続済み状態205に入って、ハブを介してセンサレポートをサーバに伝送するか、またはハブを介してサーバからバケットを受信し得る。別の例として、デバイスは、接続済み状態205に入って緊急メッセージを伝送し得る。接続済み状態205は、ハブによってスケジュールされた伝送および受信がデバイスにある状態である。スケジュールされたトラフィックが完了した後、接続は終了し(203)、デバイスは非接続状態に再入する。例示的な接続において、図7A、図7B、および図7Cに関して以下でさらに詳しくプロセスが説明される。

図3は、本開示の技術の実施形態によるBANにおける使用に対する例示的なフレーム構造を示す。いくつかの実装形態における通信では、BANにおけるチャネルアクセスに対して時分割多元接続(TDMA)を利用する。BAN時間リソースは、タイムスロット318に分割され、これらはフレーム301にグループ化される。フレーム301における伝送は、少なくとも1つの短フレーム間間隔(SIFS)期間322によって分離される。

フレーム301は、ハブがビーコン310をブロードキャストするビーコン期間304から始まる。ビーコン310は、たとえば、(a)フレーム同期およびタイミング情報、(b)BAN IDなどのBAN情報、(c)チャネル情報、および(d)フレームの長さなどの、様々な情報を含み得る。

図3の図示されている例において、スケジューリング期間302は、ビーコン期間304の後に生じる。ハブは、スケジュール期間302においてアロケーションスケジュールメッセージ311をブロードキャストする。アロケーションスケジュールメッセージ311は、予約済み期間305と非予約期間306との間の分割を設定する。予約済み期間305は、接続済み状態にあるデバイスと通信するために使用される。非予約期間306は、非接続状態にあるデバイスと通信し、非関連付け状態にあるデバイスと通信するために使用される。

アロケーションスケジュールメッセージ311は、予約済み期間305においてBANデバイスがアロケーションスロット309を予約したスケジュールを含み得る。いくつかの実装形態において、アロケーションスケジュールメッセージ311は、すべての予約済みアロケーションスロット309の開始時刻を含む。これは、予約済みアロケーションスロット309の長さを決定するためにBANデバイスによって使用され得る。他の実装形態において、アロケーションスケジュールメッセージ311は、予約済みアロケーションスロット309の長さを含む。なおもさらなる実装形態において、アロケーションスロット309は固定長を有し、アロケーションスケジュールメッセージ311はBANデバイスの順序付きリストを含み得る。いくつかの実装形態において、アロケーションスケジュールメッセージ311は、非予約期間306の開始時刻をさらに含み得る。たとえば、アロケーションスケジュールメッセージ311は、アロケーションスケジュールメッセージ311内の他の情報から算出可能でない場合に非予約期間306の開始時刻を含み得る。

アロケーションスケジュールメッセージ311は、ウェイクアップリスト320をさらに含み得る。ウェイクアップリスト320は、待ちダウンリンクパケットを有する非接続BANデバイスのリストを含む。たとえば、非接続BANデバイスは、そのBANデバイスが接続を構築するまで連続するフレーム301でウェイクアップリスト320内にリストされるものとしてよい。いくつかの実装形態において、ハブは有効期限タイマーを備えるものとしてよく、非接続BANは、有効期限タイマーの期限が切れたときに(たとえば、所定のフレーム数の後に)ウェイクアップリスト320から削除されるものとしてよい。ウェイクアップリスト320は、BANデバイスを長期間にわたって非接続状態でスリープしたままにすることができる。BANデバイスが予測不能なダウンリンクトラフィックを受け入れ得る場合であっても、デバイスがダウンリンクトラフィックをフレーム毎にチェックする必要はない。むしろ、デバイスは、接続を構築するまでウェイクアップリスト320上に残るので、ウェイクアップリスト320を定期的にチェックするのみであるように構成され得る。

図3に例示されているように、緊急期間303は、様々な実施形態においてスケジューリング期間302の後に含まれ得る。関連付けプロセス202(図2に関して上で説明されている)において緊急対応機能を有するものとして登録されていたBANデバイスは、緊急期間303を使用し得る。緊急期間303における通信のさらに詳しい説明は、参照により全体が本明細書に組み込まれている2013年3月29日に出願した関係する米国特許出願公開第2014-0292537(A1)号に載っている。

様々な実施形態において、予約済み期間305は、緊急期間303の後に出現し得る。予約済み期間305は、1つまたは複数のアロケーションスロット309を含み得る。予約済み期間305におけるアロケーションスロット309のうちの1つまたは複数は、異なる接続済みデバイスに対して予約され得る。それに加えて、いくつかの実装形態において、ハブは、ハブデバイスがスリープできるように1つまたは複数のアロケーションスロット309を非存在(ダミー)デバイスに対して予約し得る。いくつかの実装形態において、各アロケーションスロット309は、設定サイズを有する。他の実装形態では、アロケーションスロット309は、異なるサイズを--たとえば、接続要件に応じて--有し得る。

アロケーションスロット309は、ハブによって伝送されたポーリング要求メッセージ312によって開始される。BANデバイスは、スケジュールされたアロケーションスロット309の開始時刻まで(または開始時刻の直前まで)アロケーションスケジュールメッセージ311を受信した後スリープし得る。何らかの脱同期化がこのスリープ期間において生じ得る。したがって、BANデバイスは、スケジュールされたアロケーションスロット309よりも少なくとも1つのガード時間間隔だけ前にウェイクアップするようにプログラムされ得る。このガード時間では、起こりそうな同期外れを考慮し、デバイスをアロケーションスロット309よりも時間的に十分前に目覚めさせポーリング要求メッセージ312を受信させるように構成され得る。

各ポーリング要求312は、アロケーションスロット309において伝送することを許されるデバイスに対するデバイスアドレスを含み得る。いくつかの場合において、ポーリング要求312におけるデバイスアドレスは、アロケーションスケジュールメッセージ311で示されているようにアロケーションスロット309を使用するようにスケジュールされたデバイスとマッチし得ない。たとえば、これは、BANデバイスのアロケーションスロット309が緊急アロケーションスロットについて先取りされている場合に生じ得る。

BANデバイスは、このデバイスにアドレス指定されているポーリング要求メッセージ312を受信した後にハブに伝送する。したがって、デバイスは、アロケーションスロット309と整合されるように正確なネットワーク同期を維持する必要はない。したがって、いくつかの実施形態において、デバイスは、正確なネットワーク同期を維持することなく、また目覚めたときに再同期を必要とすることなく、アロケーションスケジュールメッセージ311とアロケーションスロット309との間でスリープすることができる。

ポーリング要求メッセージ312は、相対的時間オフセット情報をさらに含むものとしてよく、たとえば、相対的時間オフセット情報は、アロケーションスロット309の現在のタイムスロット318の位置を含み得る。接続を構築するためにウェイクアップして非予約期間306を使用する非接続デバイスなどの他のBANデバイスは、ポーリング要求メッセージ312に含まれる時間オフセット情報を使用してネットワークタイミングに整合し得る。この整合は、ビーコン310を探索するために非接続デバイスによって費やされる時間を短縮するために使用され得る。たとえば、非接続デバイスが予約済み期間305においてウェイクアップする場合に、非接続デバイスは、次のポーリング要求メッセージ312の到来をリッスンし、フレーム301の現在のタイムスロットを決定することができる。非接続デバイスは、この情報を使用して現在のフレーム301における残存時間を決定することができる。次いで、非接続デバイスは、フレーム301の残り部分についてスリープ状態に再入し、時間内にウェイクアップして次のビーコン310を聴くことができる。したがって、ポーリング要求メッセージ312は、非接続デバイスが次のビーコン310まで目覚めていなければならない事態を回避できるようにすることによって非接続デバイスに節電させるために使用され得る。

ポーリング要求メッセージ312は、アロケーションスロット309の持続時間(たとえば、持続時間がネットワーク動作時に固定されない場合)、およびアロケーションスロット309を使用することができるデバイスのBANデバイスIDをさらに含み得る。アロケーションスロット309が緊急要求307によって先取りされた場合、ポーリング要求メッセージ312内のBANデバイスIDは、アロケーションスケジュールメッセージ311でスケジュールされたBANデバイスIDと異なるように構成され得る。

短フレーム間間隔(SIFS)322の後、ポーリング要求メッセージ312で識別されるデバイス(ポーリングされたデバイス)は、アップリンクデータバケットまたはアップリンクデータがないことを指示するポーリング応答メッセージを含む、アップリンク応答313を伝送する。応答313の後に、ハブは、ダウンリンク応答314を伝送する。ダウンリンク応答314は、アップリンクデータパケット(伝送される場合)の肯定応答(ACK)およびダウンリンクデータパケット(ハブがダウンリンクデータを有する場合)を含む。いくつかの実装形態において、各アロケーションスロット309は、複数のパケット交換313、314を有し得る。その後のアップリンクパケット313は、前のダウンリンクデータパケット314に対するACKを含む。

様々な実施形態において、アロケーションスロット309においてアップリンクトラフィック313とダウンリンクトラフィック314との間に設定された分割はない。これは、複雑度を下げ、デバイスをより頻繁にスリープさせることができる。むしろ、アロケーションスケジュールメッセージ311は、アロケーションスロット309の開始時刻(および場合によっては、長さ)を単純にスケジュールする。

ポーリングされたデバイスは、最後のダウンリンク応答314の後にスリープ状態に再入し得る。メッセージ313、314がアロケーションスロット309全体を占有しない場合、ハブは、アロケーションスロット309の残り部分についてもスリープし得る。それに加えて、ポーリングされたデバイスが応答313を伝送しない場合、ハブは、アロケーションスロット309を使用してスリープすることができる。

予約済み期間305は、最後にスケジュールされたアロケーションスロット309の後に終了する。したがって、予約済み期間305の長さは、連続するフレーム301の間で変化するように構成され得る。それに加えて、いくつかの実施形態において、予約済み期間305は、フレーム301についてスケジュールされたアロケーションスロット309がない場合にフレーム301内に出現し得ない。

非予約期間306は、予約済み期間305の後(または予約済み期間305がない場合には、様々な実施形態における緊急期間303の後)に出現する。いくつかの実施形態において、予約済み期間305は、非予約期間306について所定の最小長があることを確実にする最大長を有する。

BANデバイスは、非予約期間306を使用して、ハブとの接続を構築するか、またはバースト性アップリンクデータをハブに伝送するものとしてよい。それに加えて、新しいネットワークデバイスは、非予約期間306において関連付けプロセス202(たとえば、図2を参照しつつ説明されているような)を開始または実行し得る。デバイスは、非予約期間306を使用して、切断された接続を再構築するか、または接続パラメータを変更することもできる。さらに、緊急対応デバイスは、非予約期間306を緊急期間303と同じようにして使用し得る。

図3に関して上で説明されているように、BANのフレーム内で通信するようにスケジュールされているデータフローは、予約済み期間における割り当てられたアロケーションスロット(たとえば、アロケーションスロット309)においてデータを伝送する。BANデバイスが図2に関して上で説明されている関連付けおよび接続プロセスを完了するのは、フレームの非予約期間においてである。関連付けの後に、BANデバイスがハブとのデータ交換のセッションを開始するために、BANデバイスは、ハブとのデータフローに対する接続を確立する。要求フローにアドミッションを与えられるのは十分なリソースが利用可能である場合に限ることを確実にするためにBANのアドミッション制御方式(その一例は図7A、図7B、および図7Cに関して説明されている)が利用されるのはこの時点である。

図4は、本明細書で説明されている技術の実施形態によるハブと接続済みデバイスとの間の接続401の寿命の一例を示している。この例における接続は、接続が構築される第1のフレーム406と、対応するアロケーションスロット402、403において通信が行われるその後のフレーム407、408とを含む。いくつかの実装形態において、フレーム407、408の間のフレームの数は、接続に応じて変化し得る。たとえば、監視デバイス用の緊急接続などの接続は、アロケーションスロット402、403をフレーム毎にスケジュールさせ得る。別の接続は、アロケーションスロット402、403を1フレームおきに、2フレームおきに、またはn-1フレームおきにスケジュールさせ得る。

例示的な接続401は、第1のフレーム(フレーム0)406の非予約期間409の間に開始する。接続を構築するデバイスは、ビーコン期間404(または、たとえば、図3に関して説明されているようにポーリングメッセージ312、315)を使用してネットワークタイミングを同期させる。フレーム406の非予約期間409の間に、デバイスは、ポーリングブロードキャスト410をリッスンし、ハブによる接続要求411および応答412を交換する。いくつかの実施形態において、接続要求411および応答412は、接続401に対する接続パラメータを設定するために使用される。接続パラメータは、限定はしないが、接続401の持続時間、アロケーションスロット402、403の間のフレームの数、接続時に使用されるデータ転送速度、優先度、トラフィック方向、アロケーションスロット402、403、持続時間、暗号化が使用されるかどうか、および他の接続パラメータを含み得る。接続パラメータは、図6に関してより詳しく説明される。

接続401のその後のフレーム407、408において、デバイスは、アロケーションスロット402、403をそれに対してスケジュールさせるものとしてよい。上で説明されているように、アロケーションスロット402、403は、ポーリング要求413、417、アップリンクデータもしくはポーリング応答メッセージ414、416、およびACKもしくはダウンリンクメッセージ415、405を含み得る。

それに加えて、最後のダウンリンクメッセージ405は、接続終了指示を含み得る。いくつかの実装形態において、接続401の長さは、いくつかの状況において拡張され得る。たとえば、接続401は、接続時に予期しないアップリンクまたはダウンリンクトラフィックが生成される場合、または1つまたは複数のアロケーションスロット402、403が緊急接続によって先取りされる場合に拡張され得る。これらの実装形態において、デバイスは、接続終了指示を含むダウンリンクメッセージ405が受信されるまでスケジュールをリッスンし続ける。

いくつかの実施形態において、BANは、アドミッションプロセスに基づき接続パラメータのオンザフライ更新をもたらすために帯域内シグナリングを利用し得る。たとえば、追加のトラフィックソースが既存の予約内に挿入されるときに(たとえば、ダウンリンクトラフィック(DL)がアップリンクトラフィック(UL)に追加される)、すでにアドミッションを与えられている接続に対する接続パラメータは更新される必要がある。さらに、BANに参加する新しい要求が受信されたときに類似の更新が行われるものとしてよく、ハブは、新しいフローの余地を作るために既存のフローの接続パラメータが調整されるべきであると決定する。そのような更新は、帯域内シグナリングを通じて遂行され得る。

図5は、本明細書で開示されている技術の様々な実施形態による帯域内シグナリングの一例を示している。様々な実施形態における帯域内シグナリングの1つの目標は、1つのBANデバイスに関係するすべてのトラフィックを単一のアロケーションスロット(たとえば、図3のアロケーションスロット309)に統合することである。様々な実施形態において、トラフィックは、データまたは管理/シグナリングトラフィックであってよい。特定のBANデバイスのすべてのトラフィックを単一のアロケーションスロットに統合することによって、より長いスリープ時間およびより低い電力消費を達成することが可能である。図4に示されている帯域内シグナリングの例は、図4に関して説明されている例示的なフレーム構造に関して構成される。非予約期間509、ビーコンメッセージ504、第1のフレーム506、ポーリングブロードキャスト510、接続要求511、および接続応答512は、図4の接続401の対応する要素に類似するものとしてよい。

本開示の実施形態による帯域内シグナリング更新を行うために、ハブは、データパケット514を受信した後にフレームJ507に接続更新要求515を挿入し得る。接続更新要求515を受信した後、アドレス指定されたBANデバイスは、データ伝送をサスペンドし、接続更新応答516で応答し得る。フレームJ+1から始めて、ハブは新しい接続パラメータを使用して、BANデバイスに対して予約を割り当てる。接続更新応答516は、様々な実施形態において、ダウンロード(DL)トラフィック追加を承認し得る。様々な実施形態において、進行中の伝送の中断を回避するために、挿入されたシグナリングメッセージは伝送/肯定応答がまだ進行しているかのように確認されたシーケンス番号を続け得る。様々な実施形態において、帯域内シグナリングメッセージはシグナリングメッセージ交換の双方向の性質を考慮して自シーケンス番号を伝える。トラフィックが一方向から双方向に変化したときに、シーケンス番号と確認されたシーケンス番号の両方が、帯域内シグナリングメッセージ内にあるものとして、MACヘッダ内に含まれ得る。

図2に関して上で説明されているように、ハブとBANデバイスとの間の通信は、接続済み状態205において行われる。BANデバイスは関連付けプロセス202の後にネットワークに関連付けられ得るが、BANデバイスからハブへのデータトラフィックは、それでも、データをハブに伝送するためにBAN「の中への」アドミッションを与えられなければならない。図3に関して上で説明されている例示的なフレーム構造などの、BANフレームの予約済み期間にハブと通信し得るBANデバイスからのデータトラフィックの「フロー」の数は、BANの帯域幅によって制限される。すべてのトラフィックタイプが同じか、類似しているネットワークでは、通信フレーム内への新しいフローのアドミッションは、すべてのフローが同じように処理され得るのでより単純である。そのようなネットワークにおいて、たとえば、これらのフローは、粗い「早い者勝ち」アドミッション制御プロセスの使用を通じて取り扱われ得る。

図2の接続プロセス206において、接続パラメータの集合がBANデバイスに対して決定される。接続パラメータは、BAN内でフロー通信が行われ得るようにハブによってフローに割り当てられた1つまたは複数の動作パラメータを表す。接続パラメータは、限定はしないが、接続の持続時間、アロケーションスロットの間のフレームの数、接続時に使用されるデータ転送速度、フローの優先度、フローのトラフィック方向、アロケーションスロットおよびフローに割り当てられた持続時間、暗号化が使用されるかどうか、および他の接続パラメータを含み得る。

図6は、本開示の技術の実施形態による例示的な接続パラメータ生成プロセスを示す図である。特に、この図は、着信フロー602に対する接続パラメータ610がどのように作成され得るかを示す一例を示している。BANの例を続けると、着信フロー602は、接続済みBANデバイス(すなわち、すでに伝送のアドミッションを与えられているBANデバイス)とは反対に、接続BANデバイス(すなわち、BANにおいてデータを伝送しようとしているBANデバイス)から出て来る。上で説明されているように、BANなどのネットワークは、たとえばすべてのトラフィックを同じ優先度レベルを有するものとして処理し得る他のネットワークとは異なり、データを伝送することを要求する複数の異種トラフィックタイプを有し得る。したがって、異種トラフィックタイプの各々は、様々な実施形態において、伝送のフローにアドミッションを与える際に考慮される、トラフィックタイプの性質に基づき、固有のQoS要件を有し得る。

図6に示されているように、着信フロー602は、図4に関して上で説明されている接続要求に類似する、接続要求をハブに送信したBANデバイスからの新しいトラフィックフローを表す。様々な実施形態において、QoS要件604は、限定はしないが、他にもあるがとりわけ、トラフィック生成速度、優先度、感知持続時間、信頼性要件、および/または遅延要件を含み得る。

ハブは、着信フロー602から接続要求を受信し、接続パラメータ610を生成する際に接続要求を出したBANデバイスの1つまたは複数の動作特性も利用し得る。ハブによって利用される動作特性の数およびタイプは、実装形態に基づき異なり得る。図示されている例において、関連するBANデバイスに関連付けられている動作特性は、BANデバイスの電力制約条件606およびバッファサイズ608を含む。このようにして、ハブは、着信フロー602の接続パラメータ610に対してどのような範囲が可能であるかを決定する際にQoS要件に加えてBANデバイスの動作制限を考慮し得る。

フローf_iに対するQoSベクトル(接続パラメータを決定する際に利用される)は、

で表されるものとしてよく、
ここで、

および

は、Table 1(表1)で識別されているフロー属性を表す。

接続パラメータの利用可能な範囲を決定するために、フレーム長Lの値が決定される必要がある。様々な実施形態において、Lは、BAN内のすべてのフローの間で最も厳しい遅延要件を充足する最大長であり得る。値Lは、たとえば

によって決定されるものとしてよく、
ここで、

(およびしたがってL)の単位はミリ秒であり、βは予約済み期間(図3および図4に関して上で説明されている)とは異なるすべての期間を含むフレームの一部または数分の1を表す。Lの値は、BANのパラメータなので、BAN内にフローが入るか、または出るかのいずれかがあっても変化すべきでない。したがって、式(2)における最小化は、BANのすべての予見可能なフローにわたって取ってよく、その中に現在存在しているものだけでない。

Lを決定した後、特定のフローの接続パラメータに対する利用可能な範囲は、決定され得る。図2に関して上で説明されているように、BANデバイスは、接続プロセスにおいて、上記のQoSベクトル(1)内の変数を識別する、接続要求メッセージをハブに送信する。いくつかの実施形態において、接続要求は、BANデバイスの電力およびバッファサイズ制約条件も含み得る。様々な実施形態において、電力およびバッファサイズ制約条件は、接続要求を出したBANデバイスの関連付けフェーズにおいて解決されるものとしてよく、ハブは、電力およびバッファ制約条件に関する知識を維持し得る。ハブは、着信フロー602に関係する情報を利用して、1つまたは複数の接続パラメータに対する最小値および最大値を決定し得る。図7〜図10に関して以下でより詳しく説明されているように、各利用可能な範囲の最大値は、ハブによって、アドミッション制御を適用するための接続プロセスにおける既定の接続パラメータとして使用され得る。

様々な実施形態において、ハブは、着信フロー602に関連する情報を利用して、最小アロケーションスロットキャップと最大アロケーションスロットギャップ(フローの接続のその後のアロケーションスロットの間のフレームの数)を計算し、次いでこれは特定のフローに対するアロケーションスロットサイズ(ミニスロット内のアロケーションスロットのサイズ)および接続持続時間を導出するために使用され得る。アロケーションスロットギャップ

に対する利用可能な範囲を算出する際に、

が成り立つことを示すことができ、
ここで、

である。

様々な実施形態において、その後のアロケーションスロットの間のギャップが小さければ小さいほど、対応するBANデバイスの使用電力は大きくなる。これは、余分なビーコン、スケジュール、およびポーリングパケットの受信にリンクする追加のオーバーヘッドに関連付けられる余分な電力消費があるせいである。したがって、関連付けられているBANデバイスの電力制約条件が、許容可能なギャップ上の下限

を定め、

であり、
ここで、

は、実際のデータを伝送するためにフローf_iのBANデバイスによって消費される全エネルギーであり、追加のオーバーヘッドに対する全エネルギー消費量は

未満であるべきである。したがって、

は、ビーコンおよびスケジュールメッセージをリッスンする際に消費されるエネルギーであり、ここで、

であり、パケット毎の伝送時間は

として算出される。

トラフィック生成速度

は、ギャップに別の下限

を課すが、それは、リソースが十分なデータがパケット化され、伝送できる状態になる前に割り振られるべきでないからである。下限

は、

として示されるものとしてよく、
ここで、

の単位はビットである。

最大許容可能ギャップ

は、フローの遅延制約条件

に違反すべきでない。それに加えて、その後のアロケーションスロットの間でBANデバイスのバッファにオーバーフローを引き起こすほど大きくてはいけない。したがって、

となり、
ここで、

の単位はビットである。式(11)に対する負の結果は、対応するバッファサイズが小さすぎて実現可能な解を得られないことを意味する。

アロケーションスロットギャップ

を使用することで、ハブはアロケーションスロットサイズおよび接続持続時間を導出する。アロケーションスロットサイズ

は、

のように算出されるものとしてよく、
ここで、パケットパーアロケーションスロット(Packets per Allocation Slot)(PpAS)は

のように計算される。
上の式(8)において、

(データパケットサイズ)およびACKsizeは、MACおよびPHYヘッダを含むそれらのパケットの合計サイズを表す。他のすべての式において、式(9)および(13)と同様に、

はデータパケットのアプリケーション層サイズのみを表す。接続持続時間

は、

のように算出され得る。

各それぞれの着信フロー602の接続パラメータに対する最小値および最大値を識別することによって、ハブには、BANのフレームにおいてデータ伝送をスケジュールするときに特定のフローに接続パラメータのどの特定の組合せを割り当てるかを決定する自由度がある。さらに、これらの許容可能な範囲の接続パラメータは、帯域幅効率を維持しながら各フローの優先度を考慮して高度なAC方式で利用され得る。

本開示の様々な実施形態による帯域幅効率の高いQoSを考慮したAC方式は、BANにおいてどのフローにアドミッションを与えるか、またはどのフローを維持するかを決定するために競合するフローの識別された範囲の利用可能な接続パラメータを利用するように構成され得る。接続パラメータに対する利用可能な範囲は、結果として要求フローにアドミッションを与えることになる各それぞれのフローにハブが割り当てることができる接続パラメータに対する可能な値を示す。様々な実施形態において、AC方式は、新しいフローにアドミッションが与えられる場合に、そのフローの接続パラメータが許容可能な範囲の内側にあることを確実にしながらアドミッションを与えられたフローの数を最大にする(式(15))ように構成される。

次のTable 2(表2)は、アドミッション制御の定式化の実施形態を記述するために使用されるような追加の表記を含む。

各フローは、フローの特定のQoS要件に基づくランク

を与えられる。様々な実施形態において、QoS要件のカテゴリは、AC方式における異なる重要度レベルを与えられ得る。たとえば、フローf_iおよびf_jが両方ともBANへのアドミッションを求めていると仮定する。この例では、ランクを決定するために最初にフローの優先度が見られ、その後、フローに対する許容遅延、次いで、フローのアロケーションスロットの長さが続く。言い換えれば、フローf_iおよびf_jについて、

となる。様々な実施形態において、2つのフローが等しいランクを有し、フローのどれもが、BAN内に存在しないときに、1つのフローがアドミッションを与えられるようにランダムに選ばれる。いくつかの実施形態において、同じランクを有する異なるフローのアドミッションを可能にするために、フローはBANから終了しない。

新しいフローf_nがBANへの参加を要求するときに、これは、フローの2つの集合、すなわち、BAN内にすでに存在するフローの集合(F_e)と、BAN内へのアドミッションを現在与えられていないが、BANに参加する候補であるフローの集合(F_r)に直面している。様々な実施形態において、2種類のデータフロー、すなわち、拒否されたフローおよび終了したフローが、F_r内に含まれ得る。拒否されたフローは、現在のフレームにおいて接続要求をハブに送信したが、BAN内へのアドミッションを拒否されたフローである。いくつかの実施形態において、拒否されたフローは、現在のフレームの終わりまでF_rに留まり、次のフレームのためにF_rから除去され得る。他の実施形態において、拒否されたフローは、現在のフレームにおいてF_rから取り除かれ得る。

終了したフローは、最初に何らかの時点でBAN内へのアドミッションを与えられたが、その後却下されたフローである。いくつかの実施形態において、終了したフローは、アドミッションを再度受けるために「有効な」候補フローとしてF_r内に留まるが、それは、終了したフローは終了したフローの次のアロケーションスロットまで終了を意識していないからである。いくつかの実施形態において、次のロケーションスロットは、現在のフレームまたは将来のフレーム内にあり得る。したがって、終了したフローは、次のアロケーションスロットの前にBANに再参加することができ得る。F_aの定義に基づき、次の新しい要求に対してF_eとして使用される。

説明を簡単にするために、本開示のAC方式は、最初にF_r=φという仮定の下で説明されるが、これは、拒否されたフローまたは終了したフローがアドミッションについて再考されず、再アドミッションを求めるために後のフレームで接続要求メッセージを再送する必要があることを意味する。

図7A、図7B、図7Cは、本開示の技術の実施形態によるアドミッション制御方式750を実装する例示的な接続プロセス700を示している。上で指摘されているように、アドミッション制御方式の実施形態は、優先度(ランク)を考慮したものであってよく、アドミッションプロセスにおいてフローのQoS要件が考慮され得る。すなわち、より高いランクのフローのQoS要件は、より低いランクのフローが処理される前に完全に遂行され得る。異なるトラフィックタイプに対するQoS要件は、限定はしないが、優先度、遅延、およびデータ転送速度を含み得る。たとえば、アラームフローは、通常の監視に対するデータフローに比べて高い優先度を有し得る。別の例として、ビデオフローは、間欠的更新(たとえば、1日n回行われる必要のある測定)と比較してより高いデータ転送速度を必要とすることがあり、したがって、ビデオフローは、あまり多くのバッファリングを行うことなく表示され得る。様々な実施形態において、QoS要件は、信頼性を含むこともあり得る。単一のBANデバイスは、様々な実施形態において1つまたは複数の異種トラフィックタイプを含み得る。

次に図7Aを参照すると、702において、要求フローが参加要求メッセージ(すなわち、接続要求)をハブに送信する。図4に関して上で説明されているように、BANデバイスは、参加要求メッセージを送信し、これはいくつかの実施形態において着信データフローのQoS要件を含み得る。様々な実施形態において、QoS要件は、限定はしないが、トラフィック生成速度、優先度、感知持続時間、信頼性要件、および遅延要件を含み得る。

各フローの接続パラメータに対する識別された利用可能な範囲によってもたらされる自由度は、QoS要件(式(16))およびランク要件(式(17))を充足しながらより多くのフロー(式(15))にアドミッションを与えようとする優先度を考慮したAC方式をハブに提供することを可能にする。

704において、ハブは、要求フローの接続パラメータに対する許容可能範囲を決定する。様々な実施形態において、接続パラメータは、限定はしないが、アロケーションスロットサイズ、アロケーションサイズキャップ、および接続持続時間を含み得る。接続パラメータに対する許容可能範囲は、たとえば、図6に関して上で説明されているような類似の方式で、決定され得る。

様々な実施形態において、接続パラメータの解決方法は、一意的ではあり得ない。これは、それぞれのフローf_iに対するアロケーションスロットギャップの許容可能範囲を示す式(3)で見ることができる。本明細書で開示されている技術の実施形態によるアドミッション制御方式は、従来のアドミッション制御方式の下だと受け入れられないフローを受け入れるために式(3)によってもたされる自由度を利用する。704において、アロケーションスロットギャップ

は、最初に、既定値

に暫定的に設定され、それにより、要求フローf_nのQoS要件をそれでも満たしながら最小電力量を使用し得る。アロケーションスロットギャップを最大値に設定することによって、BANデバイスによる余分な電力消費と引き換えに新しいフローを受け入れるためにアロケーションスロットギャップが調整され得る。これは、

が成り立つ限り可能である。したがって、

である場合に決定された接続パラメータの集合は、ハブが評価のため704において要求フローf_nに暫定的に割り当て得る既定の接続パラメータと称され得る。

704の後に、ハブでは、アドミッション制御方式を適用することによって要求フローf_nにアドミッションを与えるかどうかを決定する。

図7Bは、本開示の技術の実施形態による例示的なアドミッション制御方式750を示している。アドミッション制御方式750は、次のように設計され得る。
1)次のようなフローの集合および対応する接続パラメータを見つける。

2)ステップ1)で見つかった解のうちで、ノードの全エネルギー消費量が最小であるものを見つける。

式(17)は、BANから抜けたフローよりも低いランクを有するフローにアドミッションを与えることは、後者を除去しても前者がBANに参加することが実現可能にならない場合にのみ可能であることを述べたものである。様々な実施形態において、アドミッション制御方式750は、関連するフローのすべてのQoS要件を満たしながら要求フローf_nにアドミッションを与える十分なリソースを解放する調整オプションφ_Bが見つかるまで複数回の反復を含み得る。ハブが関連付けられているフローのQoS要件すべてをまだ満たしているすべての可能な調整オプションをチェックし、要求フローf_nにアドミッションを与える十分なリソースを利用可能にするオプションがない場合、ハブは、アドミッション制御方式750において識別される最良の調整/終了オプションペア(Φ_U、Ψ_U)を適用し得る。

例示的なアドミッション制御方式750は、705から始まり、そこで、ハブは、調整オプションΦ_Bに対する初期値を設定し得る。調整オプションΦ_Bは、調整について考慮されているBANに関連付けられているデータフローの集合を表し、各データフローはハブが割り当て得る1つまたは複数の接続パラメータを有する。たとえば、

と

(すなわち、

)との間の中間値を有するアロケーションスロットギャップがある第1のフローf_firstに対するデータフローである。調整オプションΦ_Bは、フロー

、さらにはBANに関連付けられている他のデータフローに関連付けられている1つまたは複数のフローを含み得る。

705において、ハブは、調整オプションをΦ_B=φに設定し得る。既定の接続パラメータを新しいフローf_nに割り当てることによって(すなわち、図6に関して説明されているようにアロケーションスロットギャップに対する最大値ならびにアロケーションスロットサイズおよび持続時間に対する対応する値)、および既存のフローF_eに割り当てられた現在の接続パラメータにより、フローにアドミッションを与える十分なリソースが確保されている場合、調整オプションΦ_Bはデータフローを含む必要はない。これは、BANが、フローを調整するかまたは終了させることなく、フローにアドミッションを与える十分なリソースを含んでいるからである。

706において、ハブは、要求フローf_nにアドミッションを与えるのに十分なリソースが利用可能であるかどうかを決定する。十分なリソースが利用可能である(704で識別された要求フローf_nに対する既定の接続パラメータ、および既存のフローF_eに対する現在の割り当てられている接続パラメータに基づき)場合、ハブは、BAN内へのアドミッションを要求フローf_nに与え、既定の接続パラメータを要求フローf_nに対して割り当てる。ハブは、708において割り当てられた接続パラメータを含む接続応答メッセージを要求フローf_nに送信し得る。

十分なリソースが存在しているかどうかをハブがどのように決定するかについて説明する前に、Table 2(表2)で識別されているX[t]についてより詳しく説明することは有益である。X[t]は、結果として既存のフローF_eから生じる、フレームtにおける全アロケーションスロットサイズを示す離散的時系列である。アドミッション制御方式750での反復において、X[t]を計算する際に既存のフローの予想される調整および/または終了(以下でより詳しく説明されるような)が考慮され得る。702においてハブによって新しい参加要求が受信された直後のフレームの時間インデックスはt=0に設定される。X[t]について、遷移点γ₀、...、γ_N、は、接続が終了するか、または調整が行われるフレームインデックス(γ₀=0および

)である。集合F₀⊆F_eは、t=0におけるアクティブフローの集合を表し、F_s⊆F_e、s=1、...、Nは、γ_s-1<t≦γ_sに対するアクティブフローの集合を表す。各そのような間隔について、X[t]は、周期

で周期的であり、ここで

はf_iのアロケーション周期である。

例示的なアドミッション制御方式750によりハブによってフローへのアドミッションを与えられるために、異種データフローの様々なQoS要件がそれでもなお充足されるように利用可能なリソースが十分になければならない。706において、

である場合に十分なリソースが利用可能であり得、
ここで、εは、帯域内シグナリングを介して調整が行われる必要がある場合に予約済み期間内に管理メッセージのために空けられる追加の余地を表す。式(17)に示されているように、ハブは、式(18)が1)新しいフローの接続の持続時間

、または2)既存のフローの間で終わる最後のフローの残り持続時間

のうちの小さい方について充足されるかどうかをチェックして決定する。式(17)が充足されないすべてのフレームについて、「ヒット」状況が生じる。ヒット状況とは、対応するフレーム内のチャネル利用度が予約済み期間(1-β)Lの最大容量よりも大きいことを意味する。

いくつかの実施形態において、ハブは、期間全体tにわたって式(18)をチェックするものとしてよい。様々な実施形態において、X[t]の周期的性質は、適用可能な期間tにわたって式(18)をチェックするハブに対する計算量の影響を最小限度に抑えるために利用され得る。すべてのフレームについて、特定のフローに割り当てられるアロケーションスロットは、フローに関連付けられているアロケーションスロットギャップに基づき決定される。いくつかの実施形態において、特定の数のフレームの後に、各フローに割り当てられたアロケーションスロットのパターン全体がそれ自体繰り返され得る。

X[t]の周期的性質は、

を定義することによって利用され得、これは

を計算する際に利用され得る。

a^*が存在しない場合、(18)の計算の複雑度を低減するためにハブによって利用できるX[t]の周期性はない。a^*が存在する場合、ヒット状況は、すべての

についてチェックされ得る。次いで、

が成り立つ場合、X[.]の周期的部分

は

で表され得る。

式(22)を考慮すると、X[t]の周期的性質は、ヒット状況を検出するための探索空間が低減され得るときに利用され得る。探索では、

が成り立つかチェックするだけでよい。

式(18)が適用可能な期間の間充足されている場合、ハブは、調整オプションΦ_BをBANに関連付けられているフローに適用するものとしてよく、要求フローf_nは、708においてアドミッションを与えられ得る。調整オプションΦ_B=φである場合、要求フローf_nは、既定のパラメータを使用してアドミッションを与えられるものとしてよい(空集合の適用の結果としてフロー調整がないので)。そのような状況において、帯域幅効率は、最大数のフローにBAN内へのアドミッションを与えられるときに達成される(すなわち、要求フローf_nに対する利用可能なエネルギー効率の高い接続パラメータからの変更を必要とすることなく新しいフローにアドミッションを与える十分なリソースがあった)。

式(18)が充足されない(すなわち、フレーム内でヒット状況が発生する)場合、ハブは、706において候補フローの集合Ψを決定し得る。ヒット状況は、BANに関連付けられているフロー(F_eおよびf_n)に対する現在の接続パラメータが、要求フローf_nにアドミッションを与えられた場合にすべてのフローのすべてのQoS要件が満たされ得るように十分なリソースを利用可能にすることを許さないこと示す。しかしながら、1つまたは複数の既存のフローF_eの終了が、「ヒットなし」状況を引き起こす可能性がある(すなわち、式(18)が充足される)。候補フローの集合Ψは、既存のフローの集合F_e-f_nより低いランクである-のうちからハブによって識別された1つまたは複数のフローを含み、これは終了した場合にf_nのアドミッションの後に残っているすべてのフローについてすべてのQoS要件が満たされることを確実にしながら要求フローf_nにアドミッションを与えられることを可能にする。

したがって、1つまたは複数の既存のフローF_eが、要求フローf_nにアドミッションの与える十分なリソースを解放するために終了する必要がある場合がある。様々な実施形態において、ヒット状況のある各フレームについて、そのフレーム内にアロケーションを有し、要求フローf_nよりも低いランクを有するフローがハブによってΨに追加される。

ハブが、706において、十分なリソースが利用可能でないと決定した場合、710において、ハブは、式(18)が充足されるような終了オプションΨ_Bを計算する。すなわち、アルゴリズムは、終了について、可能な最も低い優先度を有する最小数のフローをノミネートする。上で説明されているように、従来の終了アプローチは、最低優先度を有する既存のフローを取り除くステップを開始することを提案し、新しいフローにアドミッションを与えるために十分なリソースが利用可能にされるまで次に低い優先度のフローを取り除くステップを続ける。

しかしながら、このアプローチでは、いくつかのフローを取り除く必要もないのに取り除くので帯域幅が無駄になることがある。710において、ハブは、BANからランクの低いフローの最小部分集合を取り除こうとするより帯域幅効率の高いそれでもなお優先度を考慮した終了アプローチを採用し得る。たとえば、Ψ={f₁,f₂,f₃}を仮定するが、ただし、

である。従来の終了アプローチでは、システムは、f₁の終了が新しいフローにアドミッションを与えるのに十分なリソースを解放するかどうかを決定する。そうでなければ、システムは、f₁およびf₂の両方を終了させるかどうかを確認しようとし、それら2つのフローを終了させても十分なリソースを利用可能にできなかった場合、システムは、3つのすべての既存のフローが終了したら何が起きるかを確認する。この結果、潜在的に、終了するフローが多すぎるので未使用の帯域幅が残る。

様々な実施形態において、710においてハブによって使用される終了オプション識別アプローチでは、終了オプションΨ_Bを決定する際に既存の候補フローの集合Ψに関連付けられているランクの差を考慮する。次のTable 3(表4)は、終了オプションの計算を記述するために使用されるような追加の表記を含む。

上の例を続けると、ハブは、f₁;f₂;{f₁,f₂};f₃;{f₁,f₃};{f₂,f₃};{f₁,f₂,f₃}の順序で集合を取り除くことを710において順次チェックする。これからわかるように、710で使用される終了アプローチでは、リスト内の次のフローを終了させることによって十分なリソースが利用可能になるかをただ確認する代わりに順序が最低ランクであるフローの最小部分集合を考える。710では実際に終了するフローはなく、ハブは最良のフロー終了オプションΨ_Bを識別することのみを行っていることに留意されたい。

710において、候補フローの集合Ψで識別されているフローは、ランクの昇順に基づきソートされ得る。様々な実施形態において、候補フローの集合は、多数の部分集合Π_iに分割されるものとしてよく、含まれる各フローは、等しいランクである。一般的な場合において、終了オプションΨ_Bは、アルゴリズム2に基づき決定される。

上記の例において、フローf₁およびf₂は、f₃よりもランクが低い。したがって、ハブは、より低いランクを、個別に最初に、取り除くと結果として、要求フローf_nにアドミッションを与えるために十分なリソースが利用可能になるかを確認しようとする。ランクに基づき既存のフローの可能な部分集合を順序正しくトラバースすることによって、ハブは、新しいフローにアドミッションを与えるために最小数のフローを終了させ、その結果BAN帯域幅を効率よく使用することを確実にすることができる。たとえば、十分なリソースが利用可能である場合、{f₁,f₂}が終了させられると、フロー終了オプションΨ_Bは{f₁,f₂}として設定される。潜在的なフローの組合せのどれかを終了させても結果として、十分なリソースが利用可能にならない場合、ハブは、フロー終了オプションΨ_B=φを設定し得る。

710において決定されたフロー終了オプションΨ_Bは、アドミッション制御方式750の所与の反復の調整オプションΦ_Bに関連付けられる。したがって、ハブは、「現在の最良の」調整/終了オプションペア(Φ_U、Ψ_U)の一覧を維持し得る。このようにして、調整だけでは十分なリソースを利用可能にするのに不十分である場合に、それでもアドミッション制御方式750を使用した結果、アドミッション制御方式750のすべての反復を通じて識別された現在の最良の調整/終了オプションペア(Φ_U、Ψ_U)の適用を通じて要求フローf_nにアドミッションが与えられ得る。現在の最良の調整/終了オプションペア(Φ_U、Ψ_U)の使用は、図7Cに関して説明される。

712において、ハブが710で終了オプションを識別しなかった場合(すなわち、Ψ_B=φ)、ハブは714に続き得る。ハブが、710で有効な終了オプションΨ_Bを識別する場合(すなわち、Ψ_B≠φ)、ハブは、潜在的な調整/終了オプションペア(Φ_B、Ψ_B)を現在の最良の調整/終了オプションペア(Φ_U、Ψ_U)と突き合わせて比較し得る。(Φ_B、Ψ_B)が、(Φ_U、Ψ_U)よりもよいオプションであると決定された場合、ハブは、Φ_U=Φ_BおよびΨ_U=Ψ_Bとなるように現在の最良の調整終了オプションを更新する。

Ψ_B=φである場合、ハブは、現在の最良の調整/終了オプションペアの更新を行わないが、それは、調整オプションΨ_Bがすでに不十分であると決定されており、ヒット状況に是正する終了オプションがないからである。様々な実施形態において、最初にΨ_B≠φであり、現在の最良の調整/終了オプションペア(Φ_U、Ψ_U)は、値(Φ_B、Ψ_B)によって即座に更新され得るが、それは最初にΨ_B≠φであることは第1の調整/終了オプションペア(Φ_B、Ψ_B)が結果として「ヒットなし」状況を作り出す可能性があることを示すからである。最初のΨ_B≠φに続くアドミッション制御方式750の各反復について、ハブは、調整/終了オプションペア(Φ_B、Ψ_B)がBAN内により高い優先度のフローを維持するときのみ現在の最良の調整/終了オプションペア(Φ_U、Ψ_U)を更新する。

更新が行われるべきかどうかを決定する際に、ハブはΨ_BおよびΨ_Uを、フローの優先度に基づき降順でソートする。ハブは、各ベクトルΨ_BおよびΨ_Uの優先度の対毎の比較を実行する。様々な実施形態において、ハブは、2つのベクトルのうちの短い方の終わりまで対毎の比較を実行する。任意の比較において、Ψ_UにおけるフローがΨ_Bにおけるその片割れよりも高い優先度を有する場合、ハブは、現在の最良の調整/終了オプションペア(Φ_U、Ψ_U)を値(Φ_B、Φ_B)によって更新するが、それは、フローの後者の集合は終了するよりよいオプションとなるからである。対毎の比較が、Ψ_UにおけるフローがΨ_Bにおける片割れよりも低い優先度を有することを示す場合、ハブは、712で更新手順を停止し、アドミッション制御方式750を続けることができる。比較の持続時間に対するすべての比較の結果、2つのベクトル内の対をなす片方のエントリの間に結び付きを生じる場合、ハブは、Ψ_BがΨ_Uよりもサイズが小さい場合に現在の最良の調整/終了オプションペア(Φ_U、Ψ_U)を更新し得る。この解決方法は、BAN内で最大数のフローを維持するよう努力することである。両方のベクトルが同じ数のエントリを含む(すなわち、両方とも同じサイズである)場合、ハブは、フローの許容遅延を、それでもまだ結ばれている場合に、フローのアロケーションスロットサイズを比較し得るか、または様々な実施形態において、ハブは、フローのアロケーションスロットサイズを、それでもまだ結ばれている場合に、フローの許容遅延を比較し得る。

上で説明されているように、アドミッション制御方式750は、複数回の反復を受け、調整オプションΦ_Bが要求フローf_nにアドミッションを与えるために十分なリソースを利用可能にするかどうかを識別し得る。図7Bを参照すると、AC方式の各反復は714から始まる。最初に、ハブが706、710、712の動作を実行したときに、これらの動作は、アドミッション制御方式750の最初の反復の前に生じると考えられ得る。

各反復は、ハブが評価することができる次に利用可能な調整オプションを識別することから始まる。714において、利用可能な調整オプションの一覧

はハブによって更新され得る。フロー調整は、ハブが要求フローに対する既定の接続パラメータ(すなわち、

)および既存のフローに対する現在の接続パラメータを使用して要求フローにアドミッションを与えることができない場合に考慮されるものとしてよい。フロー調整を通じて、利用可能な範囲内でアロケーションスロットギャップを変更することによってヒット状況を解決し、追加のリソースを要求フローf_nに利用可能にすることが可能であり得る。ハブは、すべてのフローf_i∈F_eであり、f_nは各BANデバイスが目覚めて伝送する必要がある延長された時間の長さに関連する最小総エネルギー消費量を有するというQoS要件をそれでも満たす調整オプションを選択し得る。調整が実現可能であるときに、持続可能でない量だけ総エネルギー消費量を増やすことなく最大数のフローにアドミッションを与えることは有益である(それによって、利用可能な帯域幅をより効率的に使用する)。

いくつかの実施形態において、利用可能な調整オプションの一覧

は、アドミッション制御方式750の第1の反復の際にハブによって714において作成され得る。利用可能な調整オプションの一覧

は、アドミッション制御方式750のその後の反復の際に後で使用するためにメモリに記憶され得る。いくつかの実施形態において、利用可能な調整オプションの一覧

は、特定の要求に対して可能な調整オプションΦ_Bのすべてを維持し、リスト全体を昇順でソートし(すなわち、エネルギー消費量に対して影響の最も少ないオプションが

で最初にリストされる)、各その後の調整オプションは

にリストされる。

しかしながら、可能なすべての調整オプションの一覧を算出し、維持することは過剰すぎて、いくつかのBANアプリケーションに向かないことがある。特に、チェックされる第1のオプションのうちの1つがあれば要求フローにアドミッションを与えるのに十分であるとした場合に、可能なすべてのオプションを算出するとひどく時間がかかることがあり、リスト全体を生成するのに必要な処理時間およびリソースが無駄になる。さらに、この「強引な」アプローチは、結果として、エネルギー消費量を増大させることになる。様々な実施形態において、強引な方法の計算コストを低減するために計算効率の高いプロセスが利用され得る。

図8は、本開示の技術の様々な実施形態に従ってハブによって実装される例示的な初期化および更新プロセス800を示している。図8は、図7Bの714でハブの動作を説明するのを助けるために参照されるものとする。図8の例示的なプロセスを参照しつつ説明されているが、本開示の内容はどれも、本明細書で説明されている技術の実施形態の範囲をそのような初期化および更新プロセスのみに制限するものと解釈されるべきでない。実際、この説明を読んだ後、当業者であれば、他の初期化および更新プロセスがどのように使用され得るかを理解するであろう。

次に、図8を参照すると、F_e∪F_n={f₁,f₂,f₃}は、BANに関連付けられている調整済みの接続パラメータを有するように利用可能なすべてのフローを表す。図8の例について、これらのフローは、図7Bを説明する際に使用されるものと同じフローではない。さらに、図8に図示されている例は、本開示の技術を説明することを円滑にするだけのために用意されており、請求項の範囲を制限するものとして解釈されるべきでない。

図8の第1の反復810において、利用可能な調整オプションの一覧

が開始されるが、Φ_B=φが要求フローf_nにアドミッションを与えるのに十分であるかどうかを評価する前に一覧が必要でなかったことによる。いくつかの実施形態において、利用可能な調整オプションの一覧

は

によって初期化されるものとしてよく、
ここで、

は、アロケーションスロットギャップ

に対する特定の値を持つ各フローf_iを表す。

図8の例において、エントリ

は、フローf₁、f₂、f₃に対応し、そのアロケーションスロットギャップ

は最大値から1フレームだけ減じられる。様々な実施形態において、エントリ

は、各フローf_iに対して

である限り任意の値を含む、アロケーションスロットギャップに対する異なる値を有するフローを含み得る。フローのアロケーションスロットギャップが変更されたときに、ビーコン、スケジュール、およびポーリングメッセージを受信するために余分なウェイクアップ期間から追加のエネルギー使用が生じる。様々な実施形態において、エントリ

は、エネルギー消費量の昇順でソートされるものとしてよく、

それにより、第1のエントリ

は、他のオプションと比較して最低のエネルギー消費量を有する調整オプションを表す。識別されている例において、第1の反復810の利用可能な調整オプションのソートされた一覧

は、調整オプション802

を最低のエネルギー消費量を有する調整オプションとして識別する。

調整オプション802が、要求フローf_nにアドミッションは与えるのに十分なリソースを解放しない場合、ハブは、各その後の反復において別の利用可能な調整オプションをチェックし得る。上で説明されているように、第1の反復810で決定された利用可能な調整オプションの一覧

は、各フローの最大よりも1フレームだけ小さいアロケーションスロットギャップに対応する調整オプションを含み、これは行われる最も単純な調整であり得る、しかしながら、いくつかの場合において、より複雑な調整オプションは、実際には、調整オプション803および/または804のうちの1つよりもエネルギー効率が高いものとしてよい。図7Bのアドミッション制御方式750の更新プロセス714において、ハブは、追加調整オプションを利用可能な調整オプションの一覧

に追加し得る。

第1の反復810において、第1のエントリ

は、ソートした後に、調整オプション802であると決定された。調整オプション802は、フローf₁の調整に対応する。いくつかの実施形態において、前の反復からの第1のエントリ

が、単一のフローf_iに関連付けられている調整を含む場合に、ハブは、追加の調整オプション

を追加することを決定するものとしてよく、
ただし、

である。図8の図示されている例において、第1の反復810からの第1のエントリ

は単一のフローf₁のみを含んでいた。式(26)によれば、ハブは、調整オプション805を追加する(図8のオプション805の上に「プラス」記号を付けて示す)。すべての新しい調整オプションが追加された後、ハブは、第1の反復に関して上で説明されているように、現在のエントリのエネルギー消費量に基づき調整の一覧

を再ソートし得る。調整オプション805は、調整オプション804よりもエネルギー消費量が低いが、調整オプション803よりもエネルギー消費量が高い。次いで、ハブは、前の第1のエントリ

を削除し得る(オプション802の上に「マイナス」記号を付けて示す)が、そのオプションがすでに考慮されており、結果として十分なリソースをもたらせなかったからである。したがって、第2の反復820の利用可能な調整オプション

の一覧の第1のエントリ

は調整オプション803である。

いくつかの状況において、前の反復からの第1のエントリ

は、複数の潜在的なフローを含むものとしてよく、そのようなすべての潜在的なフローはアロケーションスロットギャップ

を有する。たとえば、1つ前の反復において、第1のエントリは

となると仮定する。そのような場合、ハブは、

の追加の調整オプションを追加し得る。

新しい調整オプションの各々は、すべての

を含み、新しいエントリは一緒に

のすべての可能な組合せを包含し、ここで、

であるが、ただし、第1のエントリ

ですでに表されているものを除く。所与の例について、ハブは、エントリ

を追加するものとしてよく、
ここで、各エントリは、調整オプションの一覧

に追加される。

ハブは、様々な実施形態においてどのような種類の調整オプションをいくつ、利用可能な調整オプションの一覧

に追加するかを、直前の第1のエントリ

に含まれる潜在的フローが過去の反復において前の第1のエントリ

のうちのどれかに含まれていなかったかどうかに基づき決定し得る。そのような実施形態において、ハブは、前のフロー情報860を維持するものとしてよく、これはΩとして表される

内に含まれる前のすべてのフロー、さらには前の調整されたフローの部分集合の集合

を識別する。前のフローの集合Ωは、ハブが何らかの前の反復においてすでに評価したフローを含む。このようにして、ハブは、どの調整オプションがチェックされたかという知識を維持し得る。前の反復の第1のエントリ

が、Ω内にすでにあるフローを含む場合に、上で説明されている更新アルゴリズムは、反復820において実施された更新で示されているように、適用され得る。

前の反復の第1のエントリ

がΩにおいて識別されていない新しいフローを含む場合に、図8に関して上で説明されている更新アルゴリズムの組合せが、

に加えて、適用され得る。図8の反復830は、(28)と上記のアルゴリズムのうちの少なくとも1つとの組合せを示している。図示されている例に示されているように、反復830は、(26)の結果から得られる調整オプション807と、(28)の結果から得られる調整オプション806とを含む。

再び図7Bを参照すると、716において、ハブは、利用可能な調整オプションの一覧

の第1のエントリ

として利用可能である有効な調整オプションΦ_Bがあるかどうかを決定する。言い換えると、ハブは

かどうかを決定する。

である場合、ハブは、718において調整オプションΦ_Bを第1のエントリ

に設定し得る。調整オプション

を設定することによって、ハブは、706において十分なリソースが利用可能かどうかを評価することができる。

である場合、接続プロセス700は、アドミッション制御方式750を通じて反復動作を停止し、続いて、図7Cに示されている720で利用可能な識別された最良の終了オプションΨ_Uがあるかどうかを識別するものとしてよい。上で説明されているように、アドミッション制御方式750では、710で調整オプションΦ_Bだけに基づき要求フローf_nにアドミッションを与えるために十分なリソースが利用可能でない場合に終了オプションΨ_Bが利用可能であるかどうかを識別し、(必要ならば)712で現在の最良の調整/終了オプションペア(Φ_U、Ψ_U)を更新する。

である場合、アドミッション制御方式750のさらなる反復が生じないので、現在の最良の調整/終了オプションペア(Φ_U、Ψ_U)は、識別された最良の調整/終了オプションペア(Φ_U、Ψ_U)となる。

様々な実施形態において、ハブは、720において識別された最良の終了オプションΨ_Uが空集合であるかどうかをチェックして確認する。Ψ_U=φである場合、それは、要求フローf_nにアドミッションを与えるために十分なリソースを解放する利用可能な調整オプションΦ_Bに対する終了オプションΨ_Bがないことを意味する。したがって、ハブは、722において要求フローf_nを拒絶し得る。Ψ_U≠φである場合、それは、それでもすべてのフローf_i∈F_eおよびf_nというQoS要件を満たしながら要求フローf_nにアドミッションを与えるために十分なリソースを解放する最良の調整/終了オプションペア(Φ_U、Ψ_U)があることを意味する。したがって、ハブは、724において最良の調整オプションΦ_Uおよび最良の終了オプションΨ_Uを適用し、要求フローf_nにアドミッションを与えるものとしてよい。これにより結果として、すべてのフローのQoS要件に悪影響を及ぼすことなく最大数のフローにアドミッションを与えることができるので、単なる終了だけに比べて帯域幅効率が高くなる。

上で説明されているように、図7A、図7B、および図7Cの接続プロセス700は、F_γ=φである状況に関して説明された。すなわち、アドミッションの却下される新しいフロー、または終了させられる既存のフローは、アドミッションについて自動的に考慮し直されないが、BANに参加することを求めるため後のフレームで接続要求を再送しなければならない。しかしながら、帯域内シグナリングを利用する実施形態では、新しいが、却下されたフローの接続要求は、現在のフレームの非予約期間の終わりまで有効であり、既存のフローは、アロケーションスロットを有する次のフレームまで終了を意識させられない。そのような場合、F_γ≠φであり、却下された要求フローおよび/または終了した既存のフローは、別の新しい要求が到来してより高いランクのフローが終了したときにBAN内へのアドミッションを潜在的に与えられ得る。したがって、初期アドミッション決定は、必ずしも最終的ではあり得ない。すなわち、単一のフレームにおいて、後から到来する要求が、潜在的に、先に来ている要求についてなされた前のアドミッション決定を覆す可能性がある。そのような状況は、各々様々なQoS要件を有する、異種トラフィックタイプであるため、BANにおいて関連する。

このような状況に対処するため、接続プロセスは、ハブがフレーム全体を通してフローの最適な集合および接続パラメータを識別することを可能にする複数の段階を含み得る。図9は、本明細書で開示されている技術の実施形態による例示的な接続プロセス900を示している。902において、ハブは、新しいフローからBANに参加する要求を受信し、許容可能接続パラメータを決定する。いくつかの実施形態において、902において要求を受信し許容可能接続パラメータを決定するステップは、図7Aに関して説明されている例示的な接続プロセス700における702および704でのハブの決定に類似しているものとしてよい。

904において、ハブは、要求フローにアドミッションを与えるのに十分なリソースがあるかどうかの初期決定を実行し得る。上で説明されているように、F_γ≠φである場合、フローの最適な集合および接続パラメータの前の決定が、その後のフローからBANに参加する後から到来した要求により変更され得る可能性がある。いくつかの場合において、アドミッションプロセスの反復を実行するステップは、長すぎて、タイミングよく(すなわち、要求を受信するSIFS以内に)結果をBANデバイスに戻せないことがある。さらに、アドミッションプロセスの結果は、後で受信された参加要求によって無効にされ得る。したがって、図2に関して上で説明されている接続応答メッセージなどの、複数の接続応答メッセージを送信すると、その結果、BAN内のデバイスの消費電力が増大し、システムの効率を低下させる。したがって、いくつかの実施形態において、ハブは、904で初期決定を実行し、BANデバイスに送信する一時的応答のタイプを決定し得る。一時的メッセージの使用により、ハブは、適切な場合に、アドミッションプロセスを実行しながら要求の受信を確認することができる。

ハブが要求フローにアドミッションを与えるのに十分なリソースがあると決定した場合、接続応答メッセージを含む一時的応答は、906において送信され得る。一時的応答は、要求フローに対する1つまたは複数の接続パラメータを含む、図2に関して説明されている接続応答メッセージに含まれる情報を収め得る。908において、アドミッションを与えられたフローの集合F_aが更新され得る。アドミッションを与えられたフローの集合F_aは更新され、F_a←F_e∪f_nとなるように要求フローf_nのアドミッションを反映する。このようにして、ハブは、同じ非予約期間においてその後の参加要求についてBAN内へのアドミッションを現在暫定的に与えられているフローを維持し得る。

ハブが要求フローにアドミッションを与えるのに十分なリソースがないと決定した場合、肯定応答(ACK)メッセージを含む一時的応答は、910において送信され得る。様々な実施形態において、ACKメッセージは、ハブが要求メッセージを受信したことを単純に指示し得る。いくつかの実施形態において、ACKメッセージは、たとえば、限定はしないが、他にもあるがとりわけ、応答までの推定時間、受信時刻、他のフローからの要求の数を含む、1つまたは複数の追加のインジケータを含み得る。

ACKを含む一時的メッセージが送信された後、ハブは、912において、アドミッション制御方式を実行し得る。ACKは、ハブが要求BANデバイスを要求メッセージのステータスに関して中途半端な状態に残すことなくアドミッション制御方式を実行する十分な時間を有するようにできる。いくつかの実施形態において、アドミッション制御方式は、図7Bに関して上で説明されているアドミッション制御方式750に類似するものとしてよい。

912においてアドミッション制御方式の結果に基づき、要求フローf_nは、BAN内へのアドミッションを与えられるものとしてよく、既存のフローの集合F_eからの1つまたは複数のフローが終了させられ、および/またはアドミッションを与えられたフローの集合F_a内の1つまたは複数フローの接続パラメータが調整され得る。したがって、ハブは、912において、アドミッション制御方式の結果に基づき、914において、f_nの参加要求F_γの前にアドミッションを与えられたフローの集合F_aおよびBAN内に常駐する要求フローの集合を更新し得る。更新は、ハブが、フレームの非予約期間内に受信された各その後のフローにアドミッションを与えるかどうかを決定するときに受信された要求に基づきBANの現在状態を意識することを確実にする。したがって、ハブは、異種フローのQoS要件をそれでも満たしているフローの最適な集合が、次のフレームにおいてBAN内へのアドミッションを与えられ、帯域幅効率を高めることを確実にし得る。

1つまたは複数の更新手順が、914において、アドミッション制御方式の結果に応じて行われ得る。いくつかの場合において、アドミッション制御方式は、1つまたは複数のフローの接続パラメータを調整することだけで、要求フローにアドミッションを与えられ得ると決定し得る。そのような場合において、914における更新手順は、908における更新手順と同様に、アドミッションを与えられたフローの集合F_aに要求フローf_nをただ単に追加し得る。

他の場合には、ハブは、要求フローが調整と終了との組合せを通じてアドミッションを与えられ得ると決定し得る。そのような実施形態において、終了フローの集合Ψ_Uが

を充足する場合、ハブは、次の式によって集合を更新するものとしてよく、
F_γ←F_γ∪Ψ_UおよびF_a←F_e∪f_n-Ψ_U (29)
ここで、

は、f_nが参加する結果としてBANからΨ_U内のフローが終了してもF_γ内のフローがBANに参加する助けにならない(すなわち、すべての異種QoS要件を満たしながらBANに参加するアドミッションをF_γ内のフローに与えるのに十分なリソースを解放しない)ことを意味する。これは、フローがF_γ内に常駐する結果生じ得るが、それは、BAN内にあるランクの高いフローが、F_γ内のフローが参加するのを控えさせるからであり、より低いランクのフローの終了が何ら助けにならないことを意味する。

いくつかの状況において、フローを単純に追加および削除したのでは、Ψ_Uで識別されているフローの終了の結果さらなるアドミッションおよび終了をもたらし得るので、この状況に対処するのに十分ではあり得ない。したがって、ハブは、この状況に対処するため914におけるより関わりの大きい更新手順を実装し得る。図10は、本明細書で開示されている技術の実施形態による例示的な関わっている更新手順1000を示している。例示的な関わっている更新手順1000は、いくつかの実施形態において、

である場合に実装され得る。1002において、ハブは、(28)に関して上で説明されているアドミッションを与えられたフローの集合の更新に類似する仕方でアドミッションを与えられたフローの集合F_aを更新し得る。

1004において、ハブは、再考慮するフローを識別し、再考慮のためのフローの一覧F_tempに初期値を入れるものとしてよい。一覧F_tempは、

のフローの最大ランクよりも低いランクを有するF_γ∪Ψ_U内のすべてのフローを含み得る。言い換えると、f_i∈(F_γ∪Ψ_U)および

について、ハブは、フローf_iを一覧F_tempに追加し得る。いくつかの実施形態において、ハブは、一覧F_temp内のすべてのフローをトラバースして、ハブが現在それらのフローにアドミッションを与えることができるかどうかを決定し得る。効率を高めるために、ハブは、いくつかの実施形態において、一覧F_temp内のフローの部分集合のみを考慮し得る。たとえば、様々な実施形態において、ハブは、相対的ランク、1つまたは複数の接続パラメータの値、またはいくつかの他の特性などの、フローの特性に基づきどのフローf_iを再考慮すべきかを識別し得る。いくつかの実施形態において、ハブは、考慮すべき特性を決定し得るが、他の実施形態では、ユーザは、考慮すべき特性を設定することができるものとしてよい。

様々な実施形態において、再考慮対象のフローが識別され得る。たとえば、いくつかの実施形態において、ハブは、if句

の検証結果に基づきどのフローを再考慮すべきかを決定するものとしてよく、
ここで、

はアドミッションを再度与えることについてフローがチェックされるべきかどうかを示すブール変数を表し、

はフローがチェックされるべきであることを示し、

は再考慮が行われるべきでないことを示す。式(30)を見るとわかるように、いくつかの実施形態において、Ψ_U内の終了したフローは、BAN内へのアドミッションを再度与えるためにすぐに考慮され得ない。言い換えれば、ハブは、Ψ_U内のすべてのフローf_iを

としてマークし得る。F_tempを決定した後に、ハブは、1006でF_γを更新し、F_γ←F_γ∪Ψ_Uとなるようにし得る。いくつかの実施形態において、ハブは、減少するフローランクに基づき一覧F_tempをソートし、一覧F_temp内の第1のエントリが最高ランキングを有するフローを表すようにできる。そのような仕方で一覧F_tempをソートすることによって、ハブは、最高ランクのフローに最初にアドミッションを与え、それによって、帯域幅効率を高め、低いランクのフローよりも前により高いランクのフローにアドミッションを与えることを確実にし得る。いくつかの実施形態において、一覧F_tempのソートは、1004において行われ得る。

1008において、ハブは、一覧F_temp内の第1のエントリF_temp[0]を選択し、1010において、フローが再考慮されるべきかどうかを決定する。たとえば、ハブが、(30)に基づきフローを再考慮すべきかどうかを決定する場合、ハブは、

であるかどうかを決定し得る。フローが、再考慮されるべきとマークされない場合(たとえば、

)、ハブは、1012において第1のエントリF_temp[0]を削除し得る。ハブは、1020においてF_temp[0]≠0かどうかを決定し、F_temp内に、アドミッションについて再考慮され得るフローがまだあることを示し得る。ハブが1020においてF_temp[0]=0と決定した場合、ハブは、1022で更新手順を終了し得る。いくつかの実施形態において、考慮されるべき参加する追加の要求がある場合に、ハブは、その後の要求に対するアドミッションプロセス、たとえば、図7A、図7B、および図7Cに関して説明されているアドミッションプロセス700、または図9に関して説明されているアドミッションプロセス900の先頭に戻り得る。

である場合に、ハブは、1014においてBAN内へのアドミッションが第1のエントリF_temp[0]に与えられ得るかどうかを決定し得る。いくつかの実施形態において、ハブは、図7A、図7B、および図7Cに関して説明されているアドミッション制御方式750を実行するものとしてよい。ハブが、フローにアドミッションを与えることができないと決定した場合、ハブは、1012において第1のエントリF_temp[0]を削除し得る。

ハブが1014において第1のエントリF_temp[0]にアドミッションが与えられ得ると決定した場合に、ハブは、1018において、アドミッションを与えられたフローの集合F_a、要求フローの集合F_γ、および一覧F_tempを更新し得る。いくつかの実施形態において、ハブは、異なる一覧を

のように更新するものとしてよく、
ここで、

は、第1のエントリF_temp[0]がアドミッションを与えられたときの終了したフローの集合を表す。(31)および(32)において、第1のエントリF_temp[0]はF_aに追加され、F_γから取り除かれる。(33)、(34)、および(35)を見るとわかるように、ハブは、その後の反復において使用するために一覧F_tempを更新し得る。ハブは、再考慮のために

におけるフローよりも低いランクを持つF_temp内のフローをマークし(たとえば、

)、

内のフローを一覧F_tempに追加し(および1004に関して上で説明されているΨ_U内の終了したフローと同様に再考慮されないものとしてそれらをマークし)得る。アドミッションを与えられたフローの集合F_a、要求フローの集合F_γ、および1016における一覧F_tempを更新した後に、ハブは、F_temp[0]を削除し、次いで、一覧F_tempを再ソートして、第1のエントリF_temp[0]を1018における一覧F_temp内で最高のランクを有するフローに対応させ得る。次いで、ハブは、上で説明されているように、1020においてF_temp[0]≠0であるかどうかを決定し得る。

本明細書で使用されているように、集合という用語は、有限または無限に関わらず、要素の集まりを指すものとしてよい。部分集合という用語は、要素が親集合から取られる要素の集まりを指すものとしてよく、部分集合は、親全集合であってもよい。真部分集合という用語は、親集合よりも少ない要素を含む部分集合を指す。シーケンスという用語は、順序付き集合または部分集合を指すものとしてよい。より小さい、以下である、より大きい、および以上である、という言い回しは、本明細書では、順序付き集合またはシーケンスの様々な対象もしくは元の間の関係を記述するために使用されるものとしてよく、これらの言い回しは、順序付けられる対象に適用可能な適切な順序付け関係を指すものとして理解される。

本明細書で使用されているように、コンポーネントという用語は、本明細書で開示されている技術の1つまたは複数の実施形態に従って実行され得る所与の機能単位を記述するものとしてよい。本明細書で使用されているように、コンポーネントは、ハードウェア、ソフトウェア、またはこれらの組合せの任意の形態を利用して実装され得る。たとえば、1つまたは複数のプロセッサ、コントローラ、ASIC、PLA、PAL、CPLD、FPGA、論理コンポーネント、ソフトウェアルーチン、または他のメカニズムは、1つのコンポーネントを構成するように実装され得る。実装の際に、本明細書で説明されている様々なコンポーネントは、ディスクリートコンポーネントとして実装されてよいか、または説明されている機能および特徴は、1つまたは複数のコンポーネントの間で一部または全部共有され得る。言い換えれば、本明細書の説明を読んだ後であれば当業者には明白であるように、本明細書で説明されている様々な特徴および機能は、所与のアプリケーションにおいて実装されてよく、様々な順列および組合せで1つまたは複数の別個のもしくは共有されるコンポーネントで実装することができる。機能の様々な特徴または要素は、別個のコンポーネントとして個別に説明されるか、または請求され得るとしても、当業者であれば、これらの特徴および機能は1つまたは複数の共通のソフトウェアおよびハードウェア要素の間で共有することができ、そのような説明は、別個のハードウェアまたはソフトウェアコンポーネントがそのような特徴または機能を実装するために使用されることを必要とするか、または暗示することがないものとすることを理解するであろう。

コンポーネントまたは技術のコンポーネントが全部または一部ソフトウェアを使用して実装される場合に、一実施形態では、これらのソフトウェア要素は、それに関して説明されている機能を実行することができるコンピューティングまたは処理コンポーネントで動作するように実装され得る。1つのそのような例示的なコンピューティングコンポーネントは、図11に示されている。様々な実施形態は、この例示的なコンピューティングコンポーネント1100に関して説明されている。この説明を読んだ後であれば、他のコンピューティングコンポーネントまたはアーキテクチャを使用して技術をどのように実装するかは当業者に明らかになるであろう。

次に図11を参照すると、コンピューティングコンポーネント1100は、たとえば、デスクトップ、ラップトップ、およびノートブックコンピュータ、ハンドヘルドコンピューティングデバイス(PDA、スマートフォン、携帯電話、パームトップなど)、メインフレーム、スーパーコンピュータ、ワークステーション、もしくはサーバ、または所与のアプリケーションもしくは環境に望ましいか、もしくは適切であり得るような他のタイプの専用もしくは汎用コンピューティングデバイス内に見つかるコンピューティングまたは処理機能を表すものとしてよい。コンピューティングコンポーネント1100は、所与のデバイス内に組み込まれるか、または所与のデバイスに何らかの形で利用可能であるコンピューティング機能も表し得る。たとえば、コンピューティングコンポーネントは、たとえば、デジタルカメラ、ナビゲーションシステム、携帯電話、携帯コンピューティングデバイス、モデム、ルーター、WAP、端末、および何らかの形態の処理機能を備え得る他の電子デバイスなどの、他の電子デバイスに見つかるものであってよい。

コンピューティングコンポーネント1100は、たとえば、1つまたは複数のプロセッサ、コントローラ、制御コンポーネント、またはプロセッサ1104などの他の処理デバイスを含むことも可能である。プロセッサ1104は、たとえば、マイクロプロセッサ、コントローラ、または他の制御論理回路などの、汎用または専用処理エンジンを使用して実装されてもよい。図示されている例では、プロセッサ1104は、バス1102に接続されているが、コンピューティングコンポーネント1100の他のコンポーネントとのインタラクティブなやり取りを円滑にするため、または外部と通信するためにどのような通信媒体でも使用できる。

コンピューティングコンポーネント1100は、本明細書において単にメインメモリ1108と称される、1つまたは複数のメモリコンポーネントも含むことが可能である。たとえば、好ましくは、ランダムアクセスメモリ(RAM)または他のダイナミックメモリが、情報とプロセッサ1104によって実行される命令とを記憶するために使用され得る。メインメモリ1108は、プロセッサ1104によって実行されるべき命令の実行時に一時変数または他の中間情報を記憶するためにも使用されてもよい。コンピューティングコンポーネント1100は、同様に、静的情報とプロセッサ1104に対する命令とを記憶するためにバス1102に結合されているリードオンリーメモリ(ROM)または他の静的記憶デバイスを備えてもよい。

コンピューティングコンポーネント1100は、たとえば、媒体ドライブ1112および記憶装置インターフェース1120を含み得る、1つまたは複数の様々な形態の情報記憶メカニズム1110も備えることが可能である。媒体ドライブ1112は、固定もしくは取り外し可能記憶媒体1114をサポートするドライブまたは他のメカニズムを含み得る。たとえば、ハードディスクドライブ、フロッピィディスクドライブ、磁気テープドライブ、光ディスクドライブ、CDもしくはDVDドライブ(RもしくはRW)、または他の取り外し可能もしくは固定媒体ドライブが備えられてもよい。したがって、記憶媒体1114は、たとえば、ハードディスク、フロッピィディスク、磁気テープ、カートリッジ、光ディスク、CDもしくはDVD、または媒体ドライブ1112によって読み出されるか、書き込まれるか、またはアクセスされる他の固定もしくは取り外し可能媒体を含み得る。これらの例からわかるように、記憶媒体1114は、中にコンピュータソフトウェアまたはデータを記憶しているコンピュータ使用可能記憶媒体を含むことができる。

代替的実施形態において、情報記憶メカニズム1110は、コンピュータプログラムまたは他の命令もしくはデータをコンピューティングコンポーネント1100にロードすることを可能にする他の類似の手段を含むことも可能である。そのような手段は、たとえば、固定もしくは取り外し可能記憶装置1122およびインターフェース1120を含み得る。そのような記憶装置1122およびインターフェース1120の例は、プログラムカートリッジおよびカートリッジインターフェース、取り外し可能メモリ(たとえば、フラッシュメモリもしくは他の取り外し可能メモリコンポーネント)およびメモリスロット、PCMCIAスロットおよびカード、ならびに他の固定もしくは取り外し可能記憶装置1122およびインターフェース1120を含むことができ、これらはソフトウェアおよびデータを記憶装置1122からコンピューティングコンポーネント1100に転送することを可能にする。

コンピューティングコンポーネント1100は、通信インターフェース1124も備え得る。通信インターフェース1124は、コンピューティングコンポーネント1100と外部デバイスとの間でソフトウェアおよびデータを転送することを可能にするために使用され得る。通信インターフェース1124の例は、モデムもしくはソフトモデム、ネットワークインターフェース(Ethernet、ネットワークインターフェースカード、WiMedia、IEEE 802.XX、もしくは他のインターフェース)、通信ポート(たとえば、USBポート、IRポート、RS232ポートBluetooth(登録商標)インターフェース、もしくは他のポート)、または他の通信インターフェースを含み得る。通信インターフェース1124を介して転送されるソフトウェアおよびデータは、典型的には信号で搬送されるものとしてよく、これは電気信号、電磁気(光を含む)信号、または所与の通信インターフェース1124によって交換することができる他の信号であり得る。これらの信号は、チャネル1128を介して通信インターフェース1124に供給され得る。このチャネル1128は、信号を搬送し、有線またはワイヤレス通信媒体を使用して実装され得る。チャネルのいくつかの例は、電話回線、セルラーリンク、RFリンク、光リンク、ネットワークインターフェース、ローカルもしくはワイドエリアネットワーク、および他の有線もしくはワイヤレス通信チャネルを含み得る。

本明細書では、「コンピュータプログラム媒体」および「コンピュータ使用可能媒体」という用語は、一般的に、たとえば、メモリ1108、記憶装置1120、媒体1114、およびチャネル1128などの、媒体を指すために使用される。これらおよび他の様々な形態のコンピュータプログラム媒体またはコンピュータ使用可能媒体は、実行のために1つまたは複数の命令の1つまたは複数のシーケンスを処理デバイスに搬送することに関与し得る。媒体上に具現化されるそのような命令は、一般的に、「コンピュータプログラムコード」または「コンピュータプログラム製品」(コンピュータプログラムまたは他のグルーピングの形態でグループ化され得る)と称される。実行されたときに、そのような命令は、コンピュータコンポーネント1100が本明細書で説明されているような開示されている技術の特徴または機能を実行することを可能にし得る。

開示されている技術の様々な実施形態が上で説明されたが、例を用いて提示されており、限定するものでないことは理解されるであろう。同様に、様々な図は、開示されている技術に対する例示的なアーキテクチャまたは他の構成を示すものとしてよく、これは開示されている技術に含まれ得る特徴および機能を理解するのを助けるために示されている。開示されている技術は、図示されている例示的なアーキテクチャまたは構成に制限されていないが、所望の特徴は、様々な代替的アーキテクチャおよび構成を使用して実装され得る。実際、当業者には、本明細書で開示されている技術の所望の特徴を実装するために代替的機能、論理的または物理的パーティション分割および構成がどのように実装され得るかは明らかであろう。また、本明細書に図示されているもの以外の多数の異なる構成コンポーネントの名称は、様々なパーティションに適用され得る。それに加えて、流れ図、動作説明、および方法の請求項に関して、本明細書においてステップが提示される順序は、文脈上そうでないことが記載されていない限り同じ順序で引用されている機能を実行するように様々な実施形態が実装されることを必須にするものではない。

開示されている技術は、様々は例示的な実施形態および実装形態に関して上で説明されているが、個別の実施形態の1つまたは複数において説明されている様々な特徴、態様、および機能は説明している特定の実施形態への適用性に限定されないが、その代わりに、単独で、もしくは様々な組合せで、開示されている技術の他の実施形態のうちの1つまたは複数に、そのような実施形態が説明されていようといまいと、またそのような特徴が説明されている実施形態の一部であるとして提示されていようといまいと、適用され得ることは理解されるべきである。したがって、本明細書で開示されている技術の広さおよび範囲は、上で説明されている例示的な実施形態のどれによっても制限されるべきでない。

本明細書で使用されている用語および語句、ならびにその変形は、別に明確に規定されていない限り、制限することとは反対に、無制約であると解釈されるべきである。前述の例として、「含む」という語は、「限定することなく、含む」または同様の言い回しを意味すると読まれるべきであり、「例」という語は、説明の中の項目の、網羅的なまたは限定するリストではなく、その事例を与えるために使用され、「a」または「an」という語は、「少なくとも1つ」、「1つまたは複数」、または同様の言い回しを意味するものとして読まれるべきであり、「従来の」、「伝統的な」、「通常の」、「標準的な」、「知られている」、および類似の意味の語などの形容詞は、説明されている項目を与えられた時間期間に、または与えられた時間現在利用可能な項目に制限するものとして解釈されるべきでないが、その代わりに、利用可能であり得る、または現在もしくは将来の任意の時点において知られている可能性のある、従来の、伝統的な、通常の、または標準的な技術を包含すると読まれるべきである。同様に、本明細書が当業者に明らかになる、または知られる技術を参照する場合、そのような技術は、現在または将来の任意の時点において当業者に明らかになる、または知られるものを包含する。

「1つまたは複数の」、「少なくとも」、「限定はしないが」、または他の同様の語句などの広げる語句がいくつかの事例中に存在している場合、これは、より狭い場合が意図されているか、またはそのような広げる語句が存在しないこともあり得る事例において必要とされることを意味すると読まれないものとする。「コンポーネント」という用語の使用は、コンポーネントの一部として説明または請求されているコンポーネントまたは機能がすべて、共通のパッケージ内に構成されることを意味しない。実際、コンポーネントの様々なコンポーネントのどれかまたはすべては、制御論理回路または他のコンポーネントであろうと、単一パッケージに組み合わされるか、または別々に維持され、複数のグルーピングまたはパッケージ内に、または複数の場所にまたがってさらに分散され得る。

それに加えて、本明細書で規定されている様々な実施形態は、例示的なブロック図、フローチャート、および他のイラストに関して説明されている。本明細書を読んだ後に当業者に明白なものとなるように、例示されている実施形態および様々な代替的形態は、図示されている例に限定することなく実装され得る。たとえば、ブロック図およびその付属する説明は、特定のアーキテクチャまたは構成を強制するものとして解釈されるべきでない。

101 接続
102 信頼できるサーバ
103 ネットワーク
104 BAN
105 ワイヤレスアクセスポイント
106 パーソナルデバイス
107 ハブデバイス
108 ワイヤレス方式の接続
109 デバイス（接続ネットワークデバイス）
110 第2の接続
201 非関連付け状態
202 関連付けプロセス
203 接続の終了
204 非接続状態
205 接続済み状態
206 接続プロセス
301 フレーム
302 スケジューリング期間
303 緊急期間
304 ビーコン期間
305 予約済み期間
306 非予約期間
307 緊急要求
309 予約済みアロケーションスロット
310 ビーコン
311 アロケーションスケジュールメッセージ
312 ポーリング要求メッセージ
313 アップリンク応答、アップリンクパケット
313、314 パケット交換
314 ダウンリンク応答、ダウンリンクデータパケット
315 ポーリングメッセージ
318 タイムスロット
320 ウェイクアップリスト
322 短フレーム間間隔(SIFS)期間
401 接続
402、403 対応するアロケーションスロット
406 第1のフレーム
407、408 フレーム
409 非予約期間
410 ポーリングブロードキャスト
411 接続要求
412 応答
413 ポーリング要求
414 ポーリング応答メッセージ
415 ダウンリンクメッセージ
416 ポーリング応答メッセージ
417 ポーリング要求
504 ビーコンメッセージ
506 第1のフレーム
507 フレームJ
509 非予約期間
510 ポーリングブロードキャスト
511 接続要求
512 接続応答
514 データパケット
515 接続更新要求
516 接続更新応答
602 着信フロー
604 QoS要件
606 電力制約条件
608 バッファサイズ
610 接続パラメータ
700 接続プロセス
750 アドミッション制御方式
800 更新プロセス
802〜807 調整オプション
810 第1の反復
820 第2の反復
830 反復
860 前のフロー情報
900 接続プロセス
1000 更新手順
1100 コンピューティングコンポーネント
1102 バス
1104 プロセッサ
1108 メインメモリ
1110 情報記憶メカニズム
1112 媒体ドライブ
1114 固定もしくは取り外し可能記憶媒体
1120 記憶装置インターフェース
1122 固定もしくは取り外し可能記憶装置
1124 通信インターフェース
1128 チャネル

Claims (33)

1. ハブデバイスが接続ネットワークデバイスに関連付けられている要求データフローからフレーム期間の非予約期間において参加要求メッセージを受信しネットワークに参加するステップと、
   前記ハブデバイスが前記要求データフローに対する1つまたは複数の接続パラメータの利用可能な範囲を決定するステップと、
   前記ハブデバイスが前記要求データフローに対する前記1つまたは複数の接続パラメータを既定の接続パラメータの集合に設定するステップと、
   前記ハブデバイスが前記要求データフローに対する前記既定の接続パラメータに基づき前記要求データフローにアドミッションを与える十分なリソースが前記ネットワーク内で利用可能であるかどうかを決定するステップと、
   十分なリソースが利用可能であると決定した場合に前記ハブデバイスが前記要求データフローにアドミッションを与えるステップ、あるいは前記ハブデバイスが調整オプション、終了オプション、またはこれらのオプションの組合せを識別するように設計されたアドミッション制御方式を実施し結果として前記要求データフローにアドミッションを与える十分なリソースを前記ネットワーク内で利用可能にするステップと、
   を含む方法。
2. 前記ハブデバイスが前記要求データフローに対する1つまたは複数の接続パラメータの利用可能な範囲を決定する前記ステップは、前記ハブデバイスが前記要求データフローに関連付けられている1つまたは複数のQoS要件と、接続BANデバイスに関連付けられている電力制約条件およびバッファサイズ制約条件とを取得するステップを含む請求項1に記載の方法。
3. 前記1つまたは複数のQoS要件、前記電力制約条件、および前記バッファサイズ制約条件は、前記要求データフローに対する前記ハブデバイスによって受信された前記参加要求メッセージ内に含まれる請求項2に記載の方法。
4. 前記1つまたは複数のQoS要件は、前記参加要求メッセージ内に含まれ、前記接続BANデバイスに関連付けられている前記電力制約条件および前記バッファサイズ制約条件は、関連付けプロセスにおいて前記ハブデバイスによって識別される請求項2に記載の方法。
5. 前記要求データフローに対する前記QoS要件は、前記要求データフローのトラフィック生成速度、前記要求データフローの許容遅延、前記要求データフローの優先度、前記要求データフローの信頼性要件、または前記要求データフローの感知持続時間のうちの1つまたは複数を含み得る請求項2に記載の方法。
6. 前記ハブデバイスが十分なリソースが利用可能かどうかを決定する前記ステップは、条件
   

   

   が充足されているかどうかを決定するステップを含む請求項1に記載の方法。
7. 前記ハブデバイスが
   各フローに割り当てられたアロケーションスロットの全体的パターンが周期的であるフレームの数をチェックして決定するステップと、
   フレームの前記述べた数が所与の閾値よりも大きい場合に、前記条件が充足されているかどうかを決定するステップの計算の影響を最小にするステップと、
   をさらに含む請求項6に記載の方法。
8. 前記周期性条件が存在する場合、前記ハブデバイスが
   

   

   が
   

   

   について成り立つかどうかをチェックするステップを含む請求項7に記載の方法。
9. 前記ハブデバイスが前記条件が充足されているかどうかを決定する前記ステップは、前記条件が前記要求データフローの接続の持続時間
   

   

   または最後のフローから既存のフローの間の終わりまでの残りの持続時間
   

   

   のうちの小さい方について充足されているかどうかを決定するステップを含む請求項6に記載の方法。
10. 前記ネットワークは既存のデータフローの集合を含み、
    既存のデータフローの前記集合の各データフローは、接続済みネットワークデバイスに関連付けられ、1つまたは複数の異種データフロータイプを含み、
    各前記データフロータイプはQoS要件の固有の集合を有し、
    前記ハブデバイスは既存のデータフローの前記集合の各データフローに対する1つまたは複数の接続パラメータの利用可能な範囲の一覧を維持する
    請求項1に記載の方法。
11. 前記調整オプションは、既存のデータフローの前記集合の少なくとも1つのデータフローに対する1つまたは複数の潜在的フロー、前記要求データフロー、またはそれらの組合せを含み、
    前記アドミッション制御方式は、
    前記ハブデバイスが1つまたは複数の既存のデータフローを含む終了オプションを決定するステップと、
    前記ハブデバイスが前記調整オプションおよび前記終了オプションに基づき現在の最良の調整オプション/終了オプションペアを更新するかどうかを決定するステップと、
    前記ハブデバイスが利用可能な調整オプションの一覧を更新するステップと、
    前記ハブデバイスが前記調整オプションとして利用可能な調整オプションの前記一覧内の第1のエントリとして前記調整オプションを設定するステップと、
    前記ハブデバイスが前記調整オプションに基づき前記要求データフローにアドミッションを与える十分なリソースが前記ネットワーク内で利用可能であるかどうかを再評価するステップと、
    を含む請求項10に記載の方法。
12. 前記ハブデバイスが前記要求データフローおよび既存のデータフローの前記集合の前記データフローの各々に対するランクを決定するステップをさらに含み、
    前記ハブデバイスが終了オプションを決定する前記ステップは
    前記ハブデバイスが既存のフローの前記集合から候補フローの集合を識別するステップと、
    前記ハブデバイスが候補フローの前記集合に基づき潜在的終了オプションの一覧を決定するステップであって、各潜在的終了オプションは1つまたは複数の候補フローを含む、ステップと、
    前記ハブデバイスが各潜在的終了オプションに関連付けられている定義済みランク測定基準に基づき潜在的終了オプションの前記一覧を昇順でソートするステップと、
    前記ハブデバイスが潜在的終了オプションの前記一覧の第1のエントリを選択するステップであって、前記潜在的終了オプションの前記一覧の前記第1のエントリは1つまたは複数の既存のデータフローを含み、前記1つまたは複数の既存のデータフローの各々は前記要求データフローの前記ランクよりも低いランクを有する、ステップと、
    を含む請求項11に記載の方法。
13. 前記要求データフローおよび既存のデータフローの前記集合の各データフローに対する前記ランクは、
    第1のデータフローの優先度要件が第2のデータフローの優先度要件よりも高い場合に、より高いランクを前記第1のデータフローに、より低いランクを前記第2のデータフローに割り当てるステップ、または
    前記第1のデータフローの前記優先度要件が第2のデータフローの前記優先度要件と同じである場合に、前記第1のデータフローの許容遅延が前記第2のデータフローの許容遅延よりも小さければ、より高いランクを前記第1のデータフローに、より低いランクを前記第2のデータフローに割り当てるステップ、または
    前記第1のデータフローの前記優先度要件および許容遅延が第2のデータフローの前記優先度要件および前記許容遅延と同じである場合に、前記第1のデータフローに対するアロケーションスロットサイズが前記第2のデータフローに対するアロケーションスロットサイズよりも大きければ、より高いランクを前記第1のデータフローに、より低いランクを前記第2のデータフローに割り当てるステップ
    によって決定される請求項12に記載の方法。
14. 前記ハブデバイスは、前記現在の最良の調整オプション/終了オプションペアを更新することを決定し、前記調整オプションおよび前記終了オプションを適用することで、前記要求データフローよりも高いランクを有する前記既存のデータフローのデータフローの終了を防ぐ請求項11に記載の方法。
15. 前記調整オプションが空集合である場合に、前記ハブデバイスが利用可能な調整オプションの一覧を更新する前記ステップは、
    前記ハブデバイスが、以下の式に従って前記要求データフローおよび既存のデータフローの前記集合の各データフローに対する初期潜在的フローを算出するステップ、
    

    

    、ここで、
    

    

    であり、
    

    

    は利用可能な調整オプションの前記一覧である、ステップと、
    前記ハブデバイスが各初期利用可能な調整オプションのエネルギー消費量に基づき利用可能な調整オプションの前記一覧を昇順でソートするステップと、
    前記ハブデバイスが利用可能な調整オプションの前記ソートされた一覧内の第1のエントリとして前記調整オプションを設定するステップと、
    を含む請求項11に記載の方法。
16. 前記ハブデバイスが利用可能な調整オプションの一覧を更新するステップであって、前記調整オプションは空集合でない、ステップは、
    前記ハブデバイスが前の調整オプションに含まれる1つまたは複数の潜在的フローを識別するステップと、
    前記ハブデバイスが利用可能な調整オプションの前記一覧に追加する1つまたは複数の追加の潜在的フローを算出するステップと、
    を含む請求項11に記載の方法。
17. 前記1つまたは複数の追加の潜在的フローは
    

    

    であるが、ただし、アロケーションスロットギャップ
    

    

    が最小アロケーションスロットギャップよりも大きく、最大アロケーションスロットギャップよりも小さい場合に限り、前記ハブデバイスは前記前の調整オプションが単一のデータフローを含むと決定する請求項16に記載の方法。
18. 前記前の調整オプションに含まれるすべての潜在的フローについて、追加フローの量が
    

    

    によって与えられ、前記前の調整オプション内の各潜在的フローについて、アロケーションスロットギャップ
    

    

    が最大アロケーションスロットギャップから単一のフレームを引いた値に等しい限り、前記ハブデバイスは、前記前の調整オプションが2つ以上の潜在的フローを含むと決定する、請求項16に記載の方法。
19. 前記前の調整オプションは、前記1つまたは複数の前の調整オプションのうちのどれにも含まれない潜在的フローを含み、
    前記ハブデバイスは新しい潜在的フローを、前記1つまたは複数の前の調整オプションのどれにも含まれない前記潜在的フローを含む利用可能な調整オプションの前記一覧に追加し、
    前記1つまたは複数の前の調整オプションで識別された可能なすべての部分集合(X)について
    

    

    である
    請求項16に記載の方法。
20. 利用可能な調整オプションの前記一覧が空集合である場合に、前記ハブデバイスが前記終了オプションを適用し、前記終了オプションが空集合に等しくない場合に、対応する調整オプションが前記アドミッション制御方式において決定されるステップをさらに含む請求項16に記載の方法。
21. 前記ハブデバイスが接続応答メッセージを帯域内シグナリングを介して前記要求データフローに関連付けられている接続BANデバイスに送信するステップをさらに含む請求項1に記載の方法。
22. 前記要求データフローに適用された前記アドミッション制御方式の結果が、現在のフレームの非予約期間の持続時間内に変更され得る請求項1に記載の方法。
23. 前記ハブデバイスが前記複数の接続パラメータを含む一時的応答メッセージを前記要求データフローに関連付けられている接続BANデバイスに送信するステップをさらに含み、
    前記ハブデバイスは、前記既定の接続パラメータに基づき十分なリソースが前記ネットワーク内で利用可能であると決定する
    請求項1に記載の方法。
24. 前記ハブデバイスが肯定応答メッセージを含む一時的応答メッセージを前記要求データフローに関連付けられている接続BANデバイスに送信するステップをさらに含み、
    前記ハブデバイスは、前記既定の接続パラメータに基づき前記要求データフローにアドミッションを与えるのに十分なリソースが利用可能でないと決定する
    請求項1に記載の方法。
25. 通信ネットワークであって、
    予約済み期間と非予約期間とを含むフレーム期間であって、前記予約済み期間はアロケーションスロットを含む、フレーム期間と、
    前記通信ネットワークに関連付けられている接続済みネットワークデバイスであって、前記接続済みネットワークデバイスは前記アロケーションスロットを割り振られる、接続済みネットワークデバイスと、
    前記通信ネットワークとの関連付けを求め、要求データフローを含む接続ネットワークデバイスと、
    前記ネットワーク内のハブデバイスと、
    を備え、前記ハブデバイスは
    前記接続ネットワークデバイスから接続要求を受信するステップであって、前記接続要求は前記要求データフローに関連付けられているQoS要件を含む、ステップと、
    前記アロケーションスロットを前記接続ネットワークデバイスに再割り振りするかどうかを、前記要求データフローに関連付けられている前記QoS要件に基づき決定するステップと、
    前記ハブデバイスが前記アロケーションスロットを前記接続ネットワークデバイスに再割り振りすることができると決定した場合に接続パラメータを前記接続デバイスに伝送するステップと、
    を実行するように構成されているプロセッサを備える通信ネットワーク。
26. 前記アロケーションスロットを前記接続ネットワークデバイスに割り振るかどうかを決定するステップは、
    前記要求データフローに対する接続パラメータの利用可能な範囲を、前記要求データフローに関連付けられている前記QoS要件に基づき決定するステップと、
    既定の接続パラメータの集合を前記要求データフローに暫定的に割り振るステップと、
    前記接続ネットワークデバイスと、データを伝送するために前記接続デバイスの前記要求データフローに前記ネットワークへのアドミッションが与えられたときに前記ネットワーク内の最小エネルギー消費量を有する1つまたは複数の接続済みネットワークデバイスを識別するステップと、
    前記接続ネットワークデバイスの前記要求データフローの割り当てられた接続パラメータの集合と、前記1つまたは複数の接続済みネットワークデバイスの割り当てられた接続パラメータの集合とを、前記識別に基づき更新するステップと、
    前記要求データフローの割り当てられた接続パラメータの前記更新された集合を前記接続ネットワークデバイスに、前記1つまたは複数の接続済みネットワークデバイスの割り当てられた接続パラメータの前記集合を前記1つまたは複数の接続済みネットワークデバイスに、それぞれ、伝送するステップと、
    を含み、
    前記アロケーションスロットは、前記ハブデバイスと前記1つまたは複数の接続済みネットワークデバイスとの間のアップリンク通信およびダウンリンク通信に対するスロットであり、
    前記アロケーションスロットは1つまたは複数のミニスロットを含み、割り当てられた接続パラメータの前記集合は前記アロケーションスロットに対するミニスロット番号、前記アロケーションスロットに対するアロケーションスロットギャップ、および前記接続ネットワークデバイスと前記1つまたは複数の接続済みネットワークデバイスとによるアップリンク通信に関連付けられている前記エネルギー消費量を含む
    請求項25に記載のシステム。
27. 前記要求データフローに対する前記QoS要件は、前記要求データフローのトラフィック生成速度、前記要求データフローの許容遅延、前記要求データフローの優先度、前記要求データフローの信頼性要件、または前記要求データフローの感知持続時間のうちの1つまたは複数を含み得る請求項26に記載のシステム。
28. 前記要求データフローに対する接続パラメータの利用可能な範囲を決定するステップは前記接続ネットワークデバイスに関連付けられている電力制約条件およびバッファ制約条件にさらに基づく請求項26に記載のシステム。
29. 前記ハブデバイスの前記プロセッサは前記1つまたは複数の接続済みネットワークデバイスの各々に対する接続パラメータの利用可能な範囲を決定し、前記1つまたは複数の接続済みネットワークデバイスの各々に対する接続パラメータの前記決定された利用可能な範囲をメモリ内に記憶するように構成される請求項26に記載のシステム。
30. 前記ハブデバイスの前記プロセッサは、
    前記既定の接続パラメータに基づき前記要求データフローにアドミッションを与えるために十分なリソースが前記ネットワーク内で利用可能でない場合に、調整オプションを識別するステップであって、前記調整オプションは前記要求データフローおよび前記1つまたは複数の接続済みネットワークデバイスの各々について決定された接続パラメータの前記利用可能な範囲に基づく1つまたは複数の潜在的フローを含む、ステップと、
    前記調整オプションに従って前記接続ネットワークデバイスと、データを伝送するために前記接続デバイスの前記要求データフローに前記ネットワークへのアドミッションが与えられたときに前記ネットワーク内の最小エネルギー消費量を有する1つまたは複数の接続済みネットワークデバイスを識別するステップと、
    をさらに実行するように構成される請求項29に記載のシステム。
31. 前記ハブデバイスの前記プロセッサは利用可能な調整オプションが利用可能な調整オプションの一覧内に存在することを前記ハブデバイスが識別する限り調整オプションの前記識別を繰り返すように構成される請求項30に記載のシステム。
32. 前記ハブデバイスの前記プロセッサは、
    利用可能な調整オプションが存在しない場合、利用可能な終了オプションが存在しているかどうかを決定するステップであって、前記利用可能な終了オプションは、前記ネットワークから終了したときに、前記要求データフローにアドミッションを与えることを許す1つまたは複数の接続済みネットワークデバイスを含む、ステップと、
    接続更新メッセージを前記利用可能な終了オプション内の前記1つまたは複数の接続済みデバイスに伝送するステップであって、前記接続更新メッセージは前記利用可能な終了オプション内の前記1つまたは複数の接続済みデバイスへの前記アロケーションスロットの前の割り当てを終了させる、ステップと、
    をさらに実行するように構成される請求項30に記載のシステム。
33. 前記利用可能な終了オプションに含まれる前記1つまたは複数の接続済みネットワークデバイスは各々、前記要求データフローの優先度ランクよりも低い優先度ランクを有する請求項32に記載のシステム。

Images