(57)【要約】本願は、６ＴｉＳＣＨネットワーク内でトラックを配分するためのシステムおよび方法を対象とする。方法は、第１のバックボーンルータ上の第１のＰＣＥプロキシからＰＣＥＰにおけるトラック計算要求を受信するステップを含む。方法は、発信元ＬＬＮデバイスと宛先ＬＬＮデバイスとの間の最適トラックを計算するステップも含む。さらに、方法は、トラック割り当てメッセージを最適トラック内の１つ以上のＬＬＮデバイスに送信するステップを含む。本願は、ＴＳＣＨスケジュール情報をＰＣＥに報告するためのシステムおよび方法も対象とする。さらに、本願は、ＬＬＮデバイスを対象とする。
2017528956.tif 000002
【特許請求の範囲】
【請求項１】
コンピュータ実装デバイスであって、
ネットワーク内でトラックを配分するための命令を記憶している不揮発性メモリと、
前記不揮発性メモリに動作可能に結合されているプロセッサと
を備え、
前記プロセッサは、
前記ネットワーク内の第１の経路計算要素プロキシから経路計算クライアント通信プロトコルにおいてトラック計算要求を受信するステップと、
前記ネットワーク内の発信元デバイスから宛先デバイスに延びているトラックを計算するステップと
を行うように構成されている、デバイス。
【請求項２】
前記プロセッサは、トラックメッセージを前記トラック内に位置する１つ以上のデバイスに送信するようにさらに構成されている、請求項１に記載のデバイス。
【請求項３】
前記トラックメッセージは、バックボーンルータ上の前記第１の経路計算要素プロキシに送信されるトラック計算返信メッセージを含む、請求項１に記載のデバイス。
【請求項４】
前記プロセッサは、前記トラック計算返信メッセージに基づいて、前記バックボーンルータ上の前記第１の経路計算要素プロキシを介して、トラック割り当てメッセージを前記１つ以上のデバイスに送信するようにさらに構成されている、請求項３に記載のデバイス。
【請求項５】
前記プロセッサは、トラック上に位置する１つ以上のデバイスを構成するための第２のバックボーンルータを決定するようにさらに構成されている、請求項１に記載のデバイス。
【請求項６】
前記プロセッサは、トラック転送割り当てメッセージを前記第２のバックボーンルータ上の第２の経路計算要素プロキシに送信するようにさらに構成され、前記第２の経路計算要素プロキシは、前記バックボーンルータ上の前記第１の経路計算要素プロキシより前記トラック上の前記１つ以上のデバイスの近くに位置付けられている、請求項５に記載のデバイス。
【請求項７】
前記トラック転送割り当てメッセージは、前記バックプロセッサ上の前記第１の経路計算要素プロキシを介して送信される、請求項６に記載のデバイス。
【請求項８】
前記計算するステップは、セルスケジュールデータベース内の情報の精査を含み、前記情報は、デバイスアドレス、プロキシアドレス、第１のセルおよび以降のスケジュールされたセルのタイムスロットオフセット、前記第１のセルおよび以降のスケジュールされたセルのチャネルオフセット、前記第１のセルおよび以降のスケジュールされたセルのタイプ、およびそれらの組み合わせから成る、請求項１に記載のデバイス。
【請求項９】
ネットワーク内でトラックを配分するためのコンピュータ実装方法であって、
前記ネットワーク内のバックボーンルータ上の第１の経路計算要素プロキシから経路計算クライアント通信プロトコルにおいてトラック計算要求を受信することと、
発信元デバイスから宛先デバイスに延びているトラックを計算することと、
トラックメッセージを前記トラック内に位置する１つ以上のデバイスに送信することと
を含む、方法。
【請求項１０】
前記トラックメッセージは、前記バックボーンルータ上の前記第１の経路計算要素プロキシに送信されるトラック計算返信メッセージを含む、請求項９に記載の方法。
【請求項１１】
前記トラック計算返信メッセージに基づいて、前記バックボーンルータ上の前記経路計算要素プロキシを介して、トラック割り当てメッセージを前記１つ以上のデバイスに送信することをさらに含む、請求項１０に記載の方法。
【請求項１２】
前記トラック上に位置する前記１つ以上のデバイスを構成するための第２のバックボーンルータを決定することをさらに含む、請求項９に記載の方法。
【請求項１３】
トラック転送割り当てメッセージを含む前記トラックメッセージを前記第２のバックボーンルータ上の第２の経路計算要素プロキシに送信することをさらに含み、前記第２の経路計算要素プロキシは、前記バックボーンルータ上の前記第１の経路計算要素プロキシより前記トラック上の１つ以上のデバイスの近くに位置付けられている、請求項１２に記載の方法。
【請求項１４】
前記トラック転送割り当てメッセージに基づいて、前記第２のバックボーンルータ上の第２の経路計算要素プロキシを介して、トラック割り当てメッセージを前記１つ以上のデバイスに送信することをさらに含む、請求項１３に記載の方法。
【請求項１５】
コンピュータ実装デバイスであって、
タイムスロット式チャネルホッピングスケジュール情報を経路計算要素に報告するための命令を記憶している不揮発性メモリと、
前記不揮発性メモリに動作可能に結合されているプロセッサと
を備え、
前記プロセッサは、
前記タイムスロット式チャネルホッピングスケジュール情報を１つ以上のデバイスから受信するステップと、
受信されたタイムスロット式チャネルホッピングスケジュール情報を集約するステップと、
前記集約されたタイムスロット式チャネルホッピングスケジュール情報を前記経路計算要素に送信するステップと
を行うように構成されている、デバイス。
【請求項１６】
前記タイムスロット式チャネルホッピングスケジュール情報は、インターネット制御メッセージングプロトコルメッセージを介して受信され、
前記集約されたタイムスロットチャネルホッピングスケジュール情報は、経路計算クライアント通信プロトコルメッセージを介して送信される、請求項１５に記載のデバイス。
【請求項１７】
タイムスロット式チャネルホッピングスケジュール情報を経路計算要素に報告するためのコンピュータ実装方法であって、
インターネット制御メッセージングプロトコルメッセージを介して、前記タイムスロット式チャネルホッピングスケジュール情報を１つ以上のデバイスから受信することと、
受信されたタイムスロット式チャネルホッピングスケジュール情報を集約することと、
経路計算クライアント通信プロトコルメッセージを介して、前記集約されたタイムスロット式チャネルホッピングスケジュール情報を経路計算要素に送信することと、
を含む、方法。
【請求項１８】
コンピュータ実装デバイスであって、
ネットワーク内でトラックを配分するための命令を記憶している不揮発性メモリと、
前記不揮発性メモリに動作可能に結合されているプロセッサと
を備え、
前記プロセッサは、
インターネット制御メッセージングプロトコルにおいてトラック配分要求メッセージをバックボーンルータに送信するステップと、
トラック配分返信メッセージを前記バックボーンルータから受信するステップと、
確認メッセージを前記バックボーンルータに送信するステップと
を行うように構成されている、デバイス。
【請求項１９】
前記プロセッサによって受信されるトラック配分返信メッセージは、トラックｉｄ、発信元アドレス、宛先アドレス、発信用セル、およびそれらの組み合わせから選択される情報を含む、請求項１８に記載のデバイス。
【請求項２０】
前記プロセッサは、タイムスロット式チャネルホッピングスケジュールを前記バックボーンルータに報告するようにさらに構成されている、請求項１８に記載のデバイス。
【発明の詳細な説明】
【技術分野】
【０００１】
（関連出願の引用）
本願は、米国仮特許出願第６２／０３１，７３７号（２０１４年７月３１日出願）に対する優先権を主張し、上記出願の開示は、その全体が参照により本明細書に引用される。
【背景技術】
【０００２】
ネットワーキングトポロジの分野では、チャネルホッピング方式が、低電力で損失的なネットワーク（ＬＬＮ）のための信頼性を改良するために採用されている。すなわち、タイムスロット式チャネルホッピング（ＴＳＣＨ）では、時間がいくつかのタイムスロットに分割される。これらのタイムスロットは、１つ以上のスロットフレームにグループ化され、各スロットフレームは、経時的に継続して反復する。
【０００３】
ＴＳＣＨアーキテクチャでは、リソースおよびスケジュール管理に関連する問題は、普遍的である。具体的には、発信元ＬＬＮデバイスと宛先ＬＬＮデバイスとの間の下層ネットワーク内のタイムスロットおよびチャネル周波数は、非効率的に管理される。例えば、６ＴｉＳＣＨネットワークにおけるＬＬＮデバイス、例えば、ＴＳＣＨにおけるＩＰｖ６は、リソースが制約され、したがって、セッションベースのトランスポートプロトコルまたはアプリケーションプロトコルをサポートしないこともある。さらに、６ＴｉＳＣＨネットワークにおける既存の制御プロトコルは、経路計算要素（ＰＣＥ）とＬＬＮデバイスとの間の通信プロトコルとして非効率的である。そのようなリソースが提供される場合でも、各層におけるＵＤＰおよびＣｏＡＰ等の既存のプロトコルを処理するために必要なプロトコルヘッダおよび処理時間は、追加のオーバーヘッドおよび有意な遅延を生じさせるであろう。
【０００４】
従来の経路計算クライアント通信プロトコル（ＰＣＥＰ）および他の関連プロトコルも、スケジュール情報を報告するために、ＬＬＮデバイスをサポートすることは可能ではない。さらに、従来のＰＣＥＰおよび他のプロトコルは、６ＴｉＳＣＨネットワークにおけるトラック確保をサポートすることは可能ではない。例えば、ＰＣＥは、経路計算要求を送信する発信元ノードにのみ経路計算応答を送信する。そうすることによって、ＰＣＥＰは、トラックを発信元と宛先ＬＬＮデバイスとの間の経路に沿って存在する全ＬＬＮデバイスにプッシュすることができない。
【発明の概要】
【課題を解決するための手段】
【０００５】
本概要は、発明を実施するための形態において以下でさらに説明される、簡略化された形態における概要の選択を導入するように提供される。本概要は、請求された主題の範囲を限定することを意図していない。前述の必要性は、６ＴｉＳＣＨネットワーク内でトラックを配分／確保するためのプロセスおよびシステムを対象とする本願によって、大いに満たされる。本願はまた、ＴＳＣＨスケジュール情報をＰＣＥに報告する方法およびシステムを対象とする。
【０００６】
本願の一側面は、６ＴｉＳＣＨネットワーク内でトラックを配分する方法を対象とする。ＰＣＥＰにおけるトラック計算要求が、第１のバックボーンルータから受信される。次に、最適トラックまたは経路が、発信元ＬＬＮデバイスから宛先ＬＬＮデバイスまで計算される。好ましくは、セルスケジュールが、考慮に入れられる。トラック割り当てメッセージは、次いで、最適トラック内の１つ以上のＬＬＮデバイスに送信される。一実施形態では、トラック割り当てメッセージは、第１のバックボーンルータ、例えば、ＢＲを介して、最適トラック内に位置するＬＬＮデバイスに送信される。さらに別の実施形態では、トラック割り当てメッセージは、第１のＢＲを介して、ＬＬＮデバイスにより近くに位置する別のバックボーンルータに送信される。なおもさらなる実施形態では、トラック割り当てメッセージは、第１のＢＲよりトラック上のＬＬＮデバイスの近くに位置付けられる別のバックボーンルータに送信される。
【０００７】
本願の別の側面は、ＴＳＣＨスケジュール情報をＰＣＥに報告する方法を対象とする。具体的には、ＴＳＣＨスケジュール情報は、ＰＣＥプロキシを伴うバックボーンルータによって、インターネット制御メッセージングプロトコル（ＩＣＭＰ）を介して、１つ以上のＬＬＮデバイスから受信される。受信に応じて、ＴＳＣＨスケジュール情報は、集約される。集約されたＴＳＣＨスケジュール情報は、次いで、ＰＣＥＰプロトコルを介して、ＰＣＥに送信される。
【０００８】
本願のさらに別の側面は、複数のＬＬＮデバイスを採用する６ＴｉＳＣＨネットワークアーキテクチャ、ＰＣＥプロキシを伴うバックボーンルータ、およびセルスケジュールを伴うＰＣＥを対象とする。一実施形態では、ＬＬＮデバイスからバックボーンルータに報告されるＴＳＣＨスケジュール情報は、以下の情報タイプのうちの１つ以上のものを含み得る：ネットワークアドレス、ソフトセルの数、ならびに複数のソフトセルのタイムスロットオフセットおよびチャネルオフセット。別の実施形態では、バックボーンルータからＰＣＥへの集約されたスケジュール報告メッセージは、以下の情報タイプのうちの１つ以上のものを含み得る：集約されたメッセージおよび複数のＴＳＣＨスケジュール報告メッセージの数。さらに別の実施形態では、ＴＳＣＨスケジュール情報は、ＰＣＥによって、セルスケジュールデータベース内に記憶される。セルスケジュールデータベースは、以下の情報タイプのうちの１つ以上のものを含み得る：ＬＬＮデバイスアドレス、プロキシアドレス、ならびに複数のスケジュールされたセルのタイムスロットオフセット、チャネルオフセット、およびタイプ。
【０００９】
本願のなおもさらなる側面は、コンピュータ実装ＬＬＮデバイスを対象とする。ＬＬＮデバイスは、ネットワーク内でトラックを配分するための命令を記憶している不揮発性メモリを含む。ＬＬＮデバイスはまた、ある命令を行うように構成されている、メモリに動作可能に結合されたプロセッサを含む。すなわち、命令は、（ｉ）ＩＣＭＰにおいてトラック配分要求メッセージをバックボーンルータに送信することと、（ｉｉ）トラック配分返信メッセージをバックボーンルータから受信することと、（ｉｉｉ）確認メッセージをバックボーンルータに送信することとを含む。
【００１０】
その詳細な説明がより深く理解され得るために、かつ当該技術分野への本願の貢献がより深く認識されるために、本発明のある実施形態が、ここまでかなり広義に概略された。
【図面の簡単な説明】
【００１１】
本願のより堅調な理解を促進するために、ここで、同様の要素が同様の数字で参照される、付随の図面を参照する。これらの図は、本願を限定するものと解釈されるべきではなく、例証にすぎないものであることを意図している。
【００１２】
【図１】図１は、本願のある実施形態による、６ＴｉＳＣＨプロトコルスタック内の６ＴｉＳＣＨ動作サブ層を図示する。
【００１３】
【図２】図２は、本願のある実施形態による、６ＴｉＳＣＨネットワークのアーキテクチャを図示する。
【００１４】
【図３】図３は、低電力かつ損失的なネットワーク内の産業オートメーションおよびプロセス制御の実施形態を図示する。
【００１５】
【図４Ａ】図４Ａは、マシンツーマシン（Ｍ２Ｍ）またはＩｏＴ通信システムの実施形態を図示する。
【００１６】
【図４Ｂ】図４Ｂは、Ｍ２Ｍサービスプラットフォームの本願の実施形態を図示する。
【００１７】
【図４Ｃ】図４Ｃは、例示的Ｍ２Ｍデバイスの系統図の本願の実施形態を図示する。
【００１８】
【図４Ｄ】図４Ｄは、例示的コンピューティングシステムのブロック図の本願の実施形態を図示する。
【００１９】
【図５】図５は、本願のある実施形態による、バックボーンルータ支援トラック配分／確保アーキテクチャを図示する。
【００２０】
【図６】図６は、本願のある実施形態による、バックボーンルータ支援トラック確保プロシージャのための技法を図示する。
【００２１】
【図７】図７は、本願の別の実施形態による、バックボーンルータ支援トラック確保プロシージャのための技法を図示する。
【００２２】
【図８】図８は、本願の別の実施形態による、バックボーンルータ支援トラック配分／確保アーキテクチャを図示する。
【００２３】
【図９】図９は、図８による、バックボーンルータ支援トラック確保プロシージャのための技法を図示する。
【００２４】
【図１０】図１０は、本願のさらに別の実施形態による、バックボーンルータ支援トラック配分／確保アーキテクチャを図示する。
【００２５】
【図１１】図１１は、図１０による、バックボーンルータ支援トラック確保プロシージャのための技法を図示する。
【００２６】
【図１２】図１２は、本願のある実施形態による、ＬＬＮデバイスとＰＣＥとの間の通信を拡張させるためのバックボーンルータ支援アーキテクチャを図示する。
【００２７】
【図１３】図１３は、図１２による、バックボーンルータ支援通信インターフェースのための技法を図示する。
【発明を実施するための形態】
【００２８】
例証的実施形態の詳細な説明が、本明細書の種々の図、実施形態、および側面を参照して議論されるであろう。本説明は、可能な実装の詳細な実施例を提供するが、詳細は、実施例であることを意図し、したがって、本開示の範囲を限定しないことを理解されたい。
【００２９】
本明細書における「一実施形態」、「ある実施形態」、「１つ以上の実施形態」、「ある側面」等の言及は、実施形態と関連して説明される特定の特徴、構造、または特性が、本開示の少なくとも１つの実施形態に含まれることを意味する。さらに、本明細書内の種々の場所における「実施形態」という用語は、必ずしも同一の実施形態を指しているわけではない。つまり、いくつかの実施形態によって提示され得るが、他の実施形態によって提示されない、種々の特徴が説明される。
【００３０】
本願によると、新規機能性、例えば、経路計算要素（ＰＣＥ）プロキシが、６ＴｉＳＣＨネットワーク内の１つ以上のバックボーンルータ上で採用される。ＰＣＥプロキシは、ＬＬＮデバイスと経路計算要素（ＰＣＥ）との間の通信を促進することに役立つ。すなわち、バックボーンルータ上のＰＣＥプロキシは、既存の経路通信要素通信プロトコル（ＰＣＥＰ）を利用し、６ＴｉＳＣＨネットワーク内外に位置するＰＣＥとインターフェースをとることができる。さらに、バックボーンルータは、ネットワーク層プロトコル、例えば、インターネット制御メッセージングプロトコル（ＩＣＭＰ）を使用して、ＬＬＮデバイスと通信するように構成される。
【００３１】
一実施形態では、バックボーンルータ上のＰＣＥプロキシは、ＬＬＮデバイスによって発信されるＴＳＣＨスケジュール報告メッセージおよびトラック配分要求メッセージを集約するように構成される。別の実施形態では、バックボーンルータ上のＰＣＥプロキシは、ＰＣＥが発信元と宛先との間のトラックを効率的に確保することに役立つ。さらに別の実施形態では、複数のバックボーンルータの各々上に存在するＰＣＥプロキシは、互いに協働し、発信元と宛先との間のトラックを効率的に構成する。トラックは、マルチホップ経路に沿ったセルの決定されたシーケンスであり得る。概して、これは、確保の結果である。
【００３２】
さらに別の実施形態によると、６ＴｉＳＣＨネットワークは、例えば、ＰＣＥと通信するセルスケジュールデータベース等の追加のアーキテクチャを採用し、１つ以上のＬＬＮデバイスから報告されるＴＳＣＨスケジュールを記憶する。
【００３３】
本願のある実施形態では、６ＴｉＳＣＨネットワーク内で使用される６ＴｉＳＣＨ制御メッセージは、ＩＣＭＰメッセージによって搬送され得る。制御メッセージは、バックボーンルータ上のＰＣＥプロキシとＬＬＮデバイスおよび／またはバックボーンルータ上の他のＰＣＥプロキシとの間にあり得る。バックボーンルータ上のＰＣＥプロキシとＬＬＮデバイスとの間の６ＴｉＳＣＨ制御メッセージは、例えば、ＴＳＣＨスケジュール報告メッセージ、トラック配分要求メッセージ、トラック配分返信メッセージ、トラック割り当てメッセージ、およびトラック割り当て確認メッセージを含み得る。一方、バックボーンルータ上のＰＣＥプロキシ間の６ＴｉＳＣＨ制御メッセージは、例えば、トラック転送要求メッセージ、トラック転送返信メッセージ、トラック転送割り当てメッセージ、およびトラック転送割り当て確認メッセージを含み得る。
【００３４】
概して、６ＴｉＳＣＨ制御メッセージは、タイプ１５９を伴うＩＣＭＰｖ６情報メッセージである。概して、前述の６ＴｉＳＣＨ制御メッセージは、ＩＣＭＰｖ６ヘッダに続いて、メッセージ本文を含む。コードフィールドはさらに、特定のタイプの６ＴｉＳＣＨ制御メッセージを識別し得る。例えば、コードフィールドは、‘０ｘ０１’から‘０ｘ０９’に及び、前述の識別された６ＴｉＳＣＨ制御メッセージの各々に関連付けられ得る。
【００３５】
さらに、ＰＣＥとバックボーンルータ上のＰＣＥプロキシとの間で使用される制御メッセージは、ＰＣＥＰメッセージを介して搬送され得る。これらの制御メッセージは、例えば、集約されたＴＳＣＨスケジュール報告メッセージ、トラック計算要求メッセージ、トラック計算返信メッセージ、トラック転送割り当てメッセージ、およびトラック転送割り当て確認メッセージを含み得る。前述のＰＣＥＰ制御メッセージタイプの各々は、所定の値を有し得る。
【００３６】
（ＩＥＥＥ８２．１５．４ｅのＴＳＣＨモード）
タイムスロット式チャネルホッピング（ＴＳＣＨ）は、ＩＥＥＥ８０２．１５．４ｅに規定された媒体アクセスモードのうちの１つである。以下の特性が、ＩＥＥＥ８０２．１５．４ｅのＴＳＣＨモードに存在する：（ｉ）時間は、いくつかのタイムスロットに分割され、（ｉｉ）タイムスロットは、１つ以上のスロットフレームにグループ化され、（ｉｉｉ）スロットフレームは、経時的に継続して反復する。例えば、表１は、ＴＳＣＨスケジュールを示す。ｘ−軸は、タイムスロットオフセットであり、ｙ−軸は、チャネルオフセットである。故に、ＬＬＮデバイスは、異なるタイムスロット内で異なるチャネルを使用し得る。「セル」と称される、ＴＳＣＨスロットフレーム内の単一要素は、タイムスロットオフセット値およびチャネルオフセット値によって識別される。典型的には、所与のセルは、表１に示されるように、スケジュールされたセル、例えば、Ｔｘ、Ｒｘ、またはＴｘＲｘ、または未スケジュールセルであり得る。さらに、「ハードセル」は、ネットワーク内の中央コントローラによって構成される、スケジュールされたセルであり、セルがＬＬＮデバイス自体によってさらに構成および／または修正されることができないことを意味する。代替として、「ソフトセル」は、ＬＬＮデバイス自体によってのみ構成され、ＬＬＮデバイスまたは中央コントローラのいずれかによってさらに構成されることができるスケジュールされたセルである。しかしながら、ソフトセルが中央コントローラによって構成されると、ハードセルとなるであろう。
【００３７】
パケットを受信または伝送するために、ＬＬＮデバイスは、スケジュールを得る必要がある。主に、ＬＬＮデバイスは、チャネル０を使用して、タイムスロット０においてパケットを伝送し得る。次に、ＬＬＮデバイスは、その無線をオンにし、チャネル１を経由して、タイムスロット１において着信パケットを受信する。ＬＬＮデバイスは、チャネル１５を使用して、タイムスロット２においてパケットを同時に伝送または受信し得る。ＬＬＮデバイスは、タイムスロット９９において、未スケジュールセルでその無線をオフにし得る。
【表１】
2017528956.tif 000003
【００３８】
（６ＴｉＳＣＨネットワークアーキテクチャ）
６ＴｉＳＣＨネットワークアーキテクチャは、概して、８０２．１５．４ｅのＴＳＣＨモードを媒体アクセス制御（ＭＡＣ）プロトコルとして使用する複数の制約のあるデバイスを含む。ＩＥＴＦ  ６ＴｉＳＣＨワーキンググループは、６ＴｉＳＣＨネットワークのネットワーク層問題に対処するためのプロトコルを規定している。ＴＳＣＨスケジュールを管理するために、６ＴｉＳＣＨ動作サブ層（６ｔｏｐ）が、６ＴｉＳＣＨワーキンググループにおいて採用されている。図１に示されるように、６ｔｏｐは、サブ層であり、ＩＥＥＥ８０２．１５．４ｅＴＳＣＨ  ＭＡＣより高い次の層である。６ｔｏｐは、管理およびデータインターフェースの両方を上位層にもたらす。例えば、６ｔｏｐは、そのリソース、例えば、ＴＳＣＨスケジュールを修正するための読み取り／作成／更新／削除等のコマンドをもたらす。
【００３９】
６ＴｉＳＣＨネットワークは、ＰＣＥによって管理され得る。ＰＣＥは、発信元と宛先との間のルーティング経路を計算するだけではなく、経路上の１つ以上のＬＬＮデバイスのためのＴＳＣＨスケジュールを一元的に構成する能力も有する。ＰＣＥは、バックボーンルータ上に位置することができるか、または代替として、６ＴｉＳＣＨネットワーク外に位置することができる。
【００４０】
ＰＣＥＰメッセージは、共通ヘッダに続き、可変長本文を含み得る。ＰＣＥＰメッセージの共通ヘッダは、Ｖｅｒ（バージョン）［０−２］、フラグ［３−７］、メッセージタイプ［８−１５］、およびメッセージ長さ［１６−３１］を含み、数字は、ビットオフセットを表す。したがって、Ｖｅｒは、３ビットを含み、フラグは、５ビットを含み、メッセージタイプは、８ビットを含む。メッセージ長さは、１６ビットを含み、メッセージ長さは、共通ヘッダを含むＰＣＥＰメッセージのバイト単位での全長である。
【００４１】
一実施形態では、バックボーンルータ等の経路計算クライアント（ＰＣＣ）が、経路計算要求を送信し得る前に、以下のプロシージャを完了する必要がある。第１に、ＰＣＣは、ＴＣＰ接続（３ウェイハンドシェイク）をＰＣＥと確立する必要がある。第２に、ＰＣＣは、ＴＣＰ接続を経由してＰＣＥＰセッションを確立する必要がある。第３に、ＰＣＣは、キープアライブメッセージを周期的に送信し、ＰＣＥＰセッションを維持する必要がある。ＰＣＣまたはバックボーンルータは、６ＴｉＳＣＨネットワークの境界に位置する強力なデバイスである。バックボーンルータは、ゲートウェイとして作用し、６ＴｉＳＣＨネットワークをインターネットに接続する。
【００４２】
経路計算要求は、計算されるべき経路に対する制約および属性の組を規定する、種々のオブジェクトを含む。例えば、経路計算要求は、発信元ＩＰアドレス、宛先ＩＰアドレス、および帯域幅等の情報を含み得る。経路計算要求を受信後、ＰＣＥは、ＰＣＣのための経路を見つけようとするであろう。次いで、ＰＣＥは、経路計算応答メッセージを介して返信するであろう。要求が満たされることができる場合、経路計算応答メッセージは、経路上の各ホップを含む計算されたマルチプロトコルラベルスイッチング（ＭＰＬＳ）経路の組を含む。要求が満たされることができない場合、経路計算応答メッセージは、経路が見つけられることができない理由を含む。
【００４３】
ＬＬＮデバイスに関して、それらは、制約のあるリソース、例えば、限定された電力供給源、メモリ、および処理能力を有する。それらは、単一ホップまたはマルチホップ通信を介して、１つ以上のバックボーンルータに接続する。その限定されたリソースに起因して、ＬＬＮデバイスは、伝送制御プロトコル（ＴＣＰ）等の複合プロトコルをサポートすることが可能ではないこともある。
【００４４】
ＬＬＮデバイスは、ＩＣＭＰプロトコル等のネットワーク層プロトコルをサポートすることができる。インターネット制御メッセージプロトコルバージョン６（ＩＣＭＰｖ６）は、ホストおよびルータによって使用され、ネットワーク層情報を互いに通信する。ＩＣＭＰメッセージは、インターネットプロトコル（ＩＰ）データグラムの内側で搬送される。ＩＣＭＰメッセージは、基本ＩＰヘッダを使用して送信される。各ＩＣＭＰメッセージは、その目的を定義する３つのフィールドを含み、チェックサムを提供する。それらは、タイプ、コード、およびチェックサムフィールドである。タイプフィールドは、ＩＣＭＰメッセージを識別する。コードフィールドは、関連付けられたタイプフィールドについてのさらなる情報を提供する。チェックサムは、メッセージの完全性を決定する方法を提供する。「未使用」と標識された任意のフィールドは、後の拡張のために確保され、送信されるとき、ゼロでなければならない。しかしながら、受信機は、これらのフィールドを使用すべきではない（それらをチェックサムに含む以外）。タイプ（１５９−１９９の数字）は、割り当てられない。
【００４５】
さらに、ＬＬＮデバイスは、制約のあるＩＰルータとしても機能し得る。特に、ＬＬＮデバイスは、全ＬＬＮデバイスに対するルーティングテーブルを計算する能力を有していない場合がある。それでもなお、６ＴｉＳＣＨネットワーク内外に位置する他のエンティティによって事前に構成されるルーティングテーブルに基づいて、パケットを転送することができる。
【００４６】
ＬＬＮデバイスのＴＳＣＨスケジュールはまた、図２に示されるように、ルータ上に構成されることができる。図示されるように、スケジュールは、ＬＬＮデバイス１における発信元からＬＬＮデバイス３における宛先にマップされる。ＬＬＮデバイスは、６ＴｉＳＣＨネットワーク内で円形によって示される。トラックは、ＰＣＥによって、発信元と宛先との間のマルチホップ通信を拡張するために確保されることができる。本願によると、トラック上のＬＬＮデバイスは、その前のホップからパケットを受信するために使用すべきセルを把握するだけではなく、その次のホップにパケットを送信するために使用すべきセルも把握する。トラックを使用することによって、発信元と宛先との間の経路のスループットおよび遅延は、合理的に保証されることができる。これは、産業オートメーションおよびプロセス制御のために重要である。
【００４７】
（６ＴｉＳＣＨネットワーク使用例）
図３に図示されるように、産業オートメーションおよびプロセス制御のための６ＴｉＳＣＨネットワークは、マルチホップ通信を用いて提供される。この図では、センサおよびアクチュエータが、ＬＬＮデバイスである。例えば、ネットワーク内の温度センサ１「Ｔ１」が、イベントを感知すると、信号伝達パケットをアクチュエータ４「Ａ４」に送信し、いくつかのアクションをトリガするであろう。さらに、オートメーションアセンブリラインでは、アクチュエータ２「Ａ２」が、タスクを完了すると、信号伝達パケットをアクチュエータ４「Ａ４」に送信し、オートメーションアセンブリラインにおける次のアクションをトリガするであろう。これらのパケットのスループットおよび遅延は、産業オートメーションおよびプロセス制御にとって非常に重要である。したがって、トラックが、これらの重要な信号伝達パケットを時間通り送達するために、発信元と宛先との間で確保される。
【００４８】
（一般的アーキテクチャ）
図４Ａは、１つ以上の開示される実施形態が実装され得る例示的マシンツーマシン（Ｍ２Ｍ）、モノのインターネット（ＩｏＴ）、またはモノのウェブ（ＷｏＴ）通信システム１０の略図である。概して、Ｍ２Ｍ技術は、ＩｏＴ／ＷｏＴのための構成要素を提供し、任意のＭ２Ｍデバイス、ゲートウェイ、またはサービスプラットフォームは、ＩｏＴ／ＷｏＴの構成要素ならびにＩｏＴ／ＷｏＴサービス層等であり得る。
【００４９】
図４Ａに示されるように、Ｍ２Ｍ／ＩｏＴ／ＷｏＴ通信システム１０は、通信ネットワーク１２を含む。通信ネットワーク１２は、固定ネットワーク、例えば、Ｅｔｈｅｒｎｅｔ（登録商標）、Ｆｉｂｅｒ、ＰＬＣ、ＩＳＤＮ等、もしくは無線ネットワーク、例えば、ＷＬＡＮ、セルラー等、もしくは異種ネットワークのネットワークであり得る。例えば、通信ネットワーク１２は、音声、データ、ビデオ、メッセージング、ブロードキャスト等のコンテンツを複数のユーザに提供する複数のアクセスネットワークから成り得る。例えば、通信ネットワーク１２は、符号分割多重アクセス（ＣＤＭＡ）、時分割多重アクセス（ＴＤＭＡ）、周波数分割多重アクセス（ＦＤＭＡ）、直交ＦＤＭＡ（ＯＦＤＭＡ）、単一キャリアＦＤＭＡ（ＳＣ−ＦＤＭＡ）等の１つ以上のチャネルアクセス方法を採用し得る。さらに、通信ネットワーク１２は、例えば、コアネットワーク、インターネット、センサネットワーク、工業制御ネットワーク、パーソナルエリアネットワーク、融合個人ネットワーク、衛星ネットワーク、ホームネットワーク、または企業ネットワーク等の他のネットワークを備え得る。
【００５０】
図４Ａに示されるように、Ｍ２Ｍ／ＩｏＴ／ＷｏＴ通信システム１０は、インフラストラクチャドメインと、フィールドドメインとを含み得る。インフラストラクチャドメインは、エンドツーエンドＭ２Ｍ展開のネットワーク側を指し、フィールドドメインは、通常、Ｍ２Ｍゲートウェイの背後にあるエリアネットワークを指す。フィールドドメインは、プロキシを伴うバックボーンルータ等のＭ２Ｍゲートウェイ１４およびＬＬＮデバイス等の端末デバイス１８を含む。任意の数のＭ２Ｍゲートウェイデバイス１４およびＭ２Ｍ端末デバイス１８が、所望に応じて、Ｍ２Ｍ／ＩｏＴ／ＷｏＴ通信システム１０に含まれ得ることが理解されるであろう。Ｍ２Ｍゲートウェイデバイス１４およびＭ２Ｍ端末デバイス１８の各々は、通信ネットワーク１２または直接無線リンクを介して、信号を伝送および受信するように構成される。Ｍ２Ｍゲートウェイデバイス１４は、無線Ｍ２Ｍデバイス（例えば、セルラーおよび非セルラー）ならびに固定ネットワークＭ２Ｍデバイス（例えば、ＰＬＣ）が、通信ネットワーク１２等のオペレータネットワークを通して、または直接無線リンクを通してのいずれかで、通信することを可能にする。例えば、Ｍ２Ｍデバイス１８は、データを収集し、通信ネットワーク１２または直接無線リンクを介して、データをＭ２Ｍアプリケーション２０またはＭ２Ｍデバイス１８に送信し得る。Ｍ２Ｍデバイス１８はまた、Ｍ２Ｍアプリケーション２０またはＭ２Ｍデバイス１８からデータを受信し得る。さらに、データおよび信号は、以下で説明されるように、Ｍ２Ｍ層２２を介して、Ｍ２Ｍアプリケーション２０に送信され、そこから受信され得る。一実施形態では、サービス層２２は、ＰＣＥであり得る。Ｍ２Ｍデバイス１８およびゲートウェイ１４は、セルラー、ＷＬＡＮ、ＷＰＡＮ、例えば、Ｚｉｇｂｅｅ（登録商標）、６ＬｏＷＰＡＮ、Ｂｌｕｅｔｏｏｔｈ（登録商標）、直接無線リンク、および有線を含む、種々のネットワークを介して通信し得る。
【００５１】
図４Ｂを参照すると、フィールドドメイン内の図示したＭ２Ｍサービス層２２は、Ｍ２Ｍアプリケーション２０、Ｍ２Ｍゲートウェイデバイス１４、Ｍ２Ｍ端末デバイス１８、および通信ネットワーク１２のためのサービスを提供する。Ｍ２Ｍサービス層２２は、所望に応じて、任意の数のＭ２Ｍアプリケーション、Ｍ２Ｍゲートウェイデバイス１４、Ｍ２Ｍ端末デバイス１８、および通信ネットワーク１２と通信し得ることが理解されるであろう。Ｍ２Ｍサービス層２２は、１つ以上のサーバ、コンピュータ等によって実装され得る。Ｍ２Ｍサービス層２２は、Ｍ２Ｍ端末デバイス１８、Ｍ２Ｍゲートウェイデバイス１４、およびＭ２Ｍアプリケーション２０に適用されるサービス能力を提供する。Ｍ２Ｍサービス層２２の機能は、種々の方法で実装され得る。例えば、Ｍ２Ｍサービス層２２は、ウェブサーバとして、セルラーコアネットワークで、クラウド等で、実装されることができる。
【００５２】
図示したＭ２Ｍサービス層２２と同様に、インフラストラクチャドメイン内にＭ２Ｍサービス層２２’が存在する。Ｍ２Ｍサービス層２２’は、インフラストラクチャドメイン内のＭ２Ｍアプリケーション２０’および下層通信ネットワーク１２’のためのサービスを提供する。Ｍ２Ｍサービス層２２’はまた、フィールドドメイン内のＭ２Ｍゲートウェイデバイス１４およびＭ２Ｍ端末デバイス１８のためのサービスも提供する。Ｍ２Ｍサービス層２２’は、任意の数のＭ２Ｍアプリケーション、Ｍ２Ｍゲートウェイデバイス、およびＭ２Ｍ端末デバイスと通信し得ることが理解されるであろう。Ｍ２Ｍサービス層２２’は、異なるサービスプロバイダによるサービス層と相互作用し得る。Ｍ２Ｍサービス層２２’は、１つ以上のサーバ、コンピュータ、仮想マシン（例えば、クラウド／計算／記憶ファーム等）等によって実装され得る。
【００５３】
図４Ｂを参照すると、Ｍ２Ｍサービス層２２および２２’は、多様なアプリケーションならびに垂直線が活用することができるサービス配布能力のコアの組を提供する。これらのサービス能力は、Ｍ２Ｍアプリケーション２０および２０’がデバイスと相互作用し、データ収集、データ分析、デバイス管理、セキュリティ、課金、サービス／デバイス発見等の機能を果たすことを可能にする。本質的に、これらのサービス能力は、これらの機能性を実装する負担をアプリケーションから取り除き、したがって、アプリケーション開発を単純化し、市場に出す費用および時間を削減する。サービス層２２および２２’はまた、Ｍ２Ｍアプリケーション２０および２０’が、サービス層２２および２２’が提供するサービスと関連して、種々のネットワーク１２および１２’を通して通信することも可能にする。
【００５４】
Ｍ２Ｍアプリケーション２０および２０’は、限定ではないが、輸送、健康およびウェルネス、コネクテッドホーム、エネルギー管理、資産追跡、ならびにセキュリティおよび監視等、種々の産業におけるアプリケーションを含み得る。前述のように、デバイス、ゲートウェイ、および他のシステムのサーバを横断して起動するＭ２Ｍサービス層は、例えば、データ収集、デバイス管理、セキュリティ、課金、場所追跡／ジオフェンシング、デバイス／サービスの発見、および従来のシステムの統合等の機能をサポートし、サービスとしてこれらの機能をＭ２Ｍアプリケーション２０および２０’に提供する。さらに、Ｍ２Ｍサービス層はまた、本願で議論され、図に図示されるように、ＬＬＮデバイス、バックボーンルータ、およびＰＣＥ等の他のデバイスと連動するように構成され得る。
【００５５】
本願で議論されるように、トラックを確保する方法は、サービス層の一部として実装され得る。サービス層は、アプリケーションプログラミングインターフェース（ＡＰＩ）および下層ネットワーキングインターフェースの組を通して、付加価値サービス能力をサポートするソフトウェアミドルウェア層である。ＥＴＳＩ  Ｍ２ＭおよびｏｎｅＭ２Ｍは両方とも、トラックを確保する方法を含み得るサービス層を使用する。ＥＴＳＩ  Ｍ２Ｍのサービス層は、サービス能力層（ＳＣＬ）と称される。ＳＣＬは、Ｍ２Ｍデバイス（デバイスＳＣＬ（ＤＳＣＬ）と称される）、ゲートウェイ（ゲートウェイＳＣＬ（ＧＳＣＬ）と称される）、および／またはネットワークノード（ネットワークＳＣＬ（ＮＳＣＬ）と称される）内に実装され得る。ｏｎｅＭ２Ｍサービス層は、共通サービス機能（ＣＳＦ）（例えば、サービス能力）の組をサポートする。１つ以上の特定のタイプのＣＳＦの組のインスタンス化は、共通サービスエンティティ（ＣＳＥ）と称され、異なるタイプのネットワークノード（例えば、インフラストラクチャノード、ミドルノード、特定用途向けノード）上にホストされ得る。さらに、本願で説明されるようなトラックを確保する方法は、本願によるトラックの確保等のサービスにアクセスするためにサービス指向アーキテクチャ（ＳＯＡ）および／またはリソース指向アーキテクチャ（ＲＯＡ）を使用する、Ｍ２Ｍネットワークの一部として実装されることができる。
【００５６】
図４Ｃは、例えば、Ｍ２Ｍ端末デバイス１８またはＭ２Ｍゲートウェイデバイス１４等の例示的Ｍ２Ｍデバイス３０の系統図である。図４Ｃに示されるように、Ｍ２Ｍデバイス３０は、プロセッサ３２と、送受信機３４と、伝送／受信要素３６と、スピーカ／マイクロホン３８と、キーパッド４０と、ディスプレイ／タッチパッド／インジケータ４２と、非取り外し可能なメモリ４４と、取り外し可能なメモリ４６と、電源４８と、全地球測位システム（ＧＰＳ）チップセット５０と、他の周辺機器５２とを含み得る。Ｍ２Ｍデバイス４０は、実施形態と一致したままで、先述の要素の任意の副次的組み合わせを含み得ることが理解されるであろう。このデバイスは、感覚データの組み込み意味論命名のための開示されるシステムおよび方法を使用するデバイスであり得る。Ｍ２Ｍデバイス３０はまた、本願に説明され、図に図示されるように、例えば、ＬＬＮデバイス、バックボーンルータ、およびＰＣＥを含む、他のデバイスとともに採用され得る。
【００５７】
プロセッサ３２は、汎用プロセッサ、特殊用途プロセッサ、従来のプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアと関連する１つ以上のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、任意の他のタイプの集積回路（ＩＣ）、状態マシン等であり得る。プロセッサ３２は、信号符号化、データ処理、電力制御、入出力処理、および／またはＭ２Ｍデバイス３０が無線環境で動作することを可能にする任意の他の機能性を果たし得る。プロセッサ３２は、伝送／受信要素３６に連結され得る、送受信機３４に連結され得る。図４Ｃは、プロセッサ３２および送受信機３４を別個の構成要素として描写するが、プロセッサ３２および送受信機３４は、電子パッケージまたはチップに一緒に組み込まれ得ることが理解されるであろう。プロセッサ３２は、アプリケーション層プログラム（例えば、ブラウザ）および／または無線アクセス層（ＲＡＮ）プログラムならびに／もしくは通信を行い得る。プロセッサ３２は、例えば、アクセス層および／またはアプリケーション層等で、認証、セキュリティキー一致、ならびに／もしくは暗号化動作等のセキュリティ動作を行い得る。
【００５８】
伝送／受信要素３６は、信号をＭ２Ｍサービスプラットフォーム２２に伝送し、またはＭ２Ｍサービスプラットフォーム２２から信号を受信するように構成され得る。例えば、実施形態では、伝送／受信要素３６は、ＲＦ信号を伝送および／または受信するように構成されるアンテナであり得る。伝送／受信要素３６は、ＷＬＡＮ、ＷＰＡＮ、セルラー等の種々のネットワークならびにエアインターフェースをサポートし得る。実施形態では、伝送／受信要素３６は、例えば、ＩＲ、ＵＶ、もしくは可視光信号を伝送および／または受信するように構成されるエミッタ／検出器であり得る。さらに別の実施形態では、伝送／受信要素３６は、ＲＦおよび光信号の両方を伝送ならびに受信するように構成され得る。伝送／受信要素３６は、無線もしくは有線信号の任意の組み合わせを伝送および／または受信するように構成され得ることが理解されるであろう。
【００５９】
加えて、伝送／受信要素３６は、単一の要素として図４Ｃで描写されているが、Ｍ２Ｍデバイス３０は、任意の数の伝送／受信要素３６を含み得る。より具体的には、Ｍ２Ｍデバイス３０は、ＭＩＭＯ技術を採用し得る。したがって、実施形態では、Ｍ２Ｍデバイス３０は、無線信号を伝送および受信するための２つ以上の伝送／受信要素３６（例えば、複数のアンテナ）を含み得る。
【００６０】
送受信機３４は、伝送／受信要素３６によって伝送される信号を変調するように、および伝送／受信要素３６によって受信される信号を復調するように構成され得る。上記のように、Ｍ２Ｍデバイス３０は、マルチモード能力を有し得る。したがって、送受信機３４は、Ｍ２Ｍデバイス３０が、例えば、ＵＴＲＡおよびＩＥＥＥ８０２．１１等の複数のＲＡＴを介して通信することを可能にするための複数の送受信機を含み得る。
【００６１】
プロセッサ３２は、非取り外し可能なメモリ４４および／または取り外し可能なメモリ４６等の任意のタイプの好適なメモリから情報にアクセスし、そこにデータを記憶し得る。非取り外し可能なメモリ４４は、ランダムアクセスメモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、ハードディスク、または任意の他のタイプのメモリ記憶デバイスを含み得る。取り外し可能なメモリ４６は、加入者識別モジュール（ＳＩＭ）カード、メモリスティック、セキュアデジタル（ＳＤ）メモリカード等を含み得る。他の実施形態では、プロセッサ３２は、サーバまたはホームコンピュータ上等のＭ２Ｍデバイス３０上に物理的に位置しないメモリから情報にアクセスし、そこにデータを記憶し得る。
【００６２】
プロセッサ３２は、電源４８から電力を受け取り得、Ｍ２Ｍデバイス３０内の他の構成要素への電力を配布および／または制御するように構成され得る。電源４８は、Ｍ２Ｍデバイス３０に電力供給するための任意の好適なデバイスであり得る。例えば、電源４８は、１つ以上の乾電池バッテリ（例えば、ニッケルカドミウム（ＮｉＣｄ）、ニッケル亜鉛（ＮｉＺｎ）、ニッケル水素（ＮｉＭＨ）、リチウムイオン（Ｌｉ−ｉｏｎ）等）、太陽電池、燃料電池等を含み得る。
【００６３】
プロセッサ３２はまた、Ｍ２Ｍデバイス３０の現在の場所に関する場所情報（例えば、経度および緯度）を提供するように構成されるＧＰＳチップセット５０に連結され得る。Ｍ２Ｍデバイス３０は、実施形態と一致したままで、任意の好適な場所決定方法を介して場所情報を獲得し得ることが理解されるであろう。
【００６４】
プロセッサ３２はさらに、追加の特徴、機能性、および／または有線もしくは無線接続を提供する１つ以上のソフトウェアならびに／もしくはハードウェアモジュールを含み得る他の周辺機器５２に連結され得る。例えば、周辺機器５２は、加速度計、ｅ−コンパス、衛星送受信機、センサ、デジタルカメラ（写真またはビデオ用）、ユニバーサルシリアルバス（ＵＳＢ）ポート、振動デバイス、テレビ送受信機、ハンズフリーヘッドセット、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール、周波数変調（ＦＭ）ラジオユニット、デジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザ等を含み得る。
【００６５】
図４Ｄは、例えば、図４Ａおよび４ＢのＭ２Ｍサービスプラットフォーム２２が実装され得る例示的なコンピュータシステム９０のブロック図である。コンピュータシステム９０は、コンピュータまたはサーバを備え得、主に、ソフトウェアの形態であり得るコンピュータ読み取り可能な命令によって制御され得、どこでも、またはどのような手段を用いても、そのようなソフトウェアが記憶もしくはアクセスされる。そのようなコンピュータ読み取り可能な命令は、コンピュータシステム９０を起動させるように、中央処理装置（ＣＰＵ）９１内で実行され得る。多くの既知のワークステーション、サーバ、および周辺コンピュータでは、中央処理装置９１は、マイクロプロセッサと呼ばれる単一チップＣＰＵによって実装される。他のマシンでは、中央処理装置９１は、複数のプロセッサを備え得る。コプロセッサ８１は、追加の機能を果たすか、またはＣＰＵ９１を支援する、主要ＣＰＵ９１とは異なる随意的なプロセッサである。ＣＰＵ９１および／またはコプロセッサ８１は、組み込み意味論名を伴う感覚データのクエリ等の組み込み意味論命名のための開示されるシステムおよび方法に関連するデータを受信、生成、ならびに処理し得る。
【００６６】
動作時、ＣＰＵ９１は、命令をフェッチ、復号、および実行し、コンピュータの主要データ転送パスであるシステムバス８０を介して、情報を他のリソースへ、およびそこから転送する。そのようなシステムバスは、コンピュータシステム９０内の構成要素を接続し、データ交換のための媒体を定義する。システムバス８０は、典型的には、データを送信するためのデータライン、アドレスを送信するためのアドレスライン、ならびに割り込みを送信するため、およびシステムバスを動作させるための制御ラインを含む。そのようなシステムバス８０の実施例は、ＰＣＩ（周辺構成要素相互接続）バスである。
【００６７】
システムバス８０に連結されるメモリデバイスは、ランダムアクセスメモリ（ＲＡＭ）８２および読み取り専用メモリ（ＲＯＭ）９３を含む。そのようなメモリは、情報が記憶されて取り出されることを可能にする回路を含む。ＲＯＭ９３は、概して、容易に修正することができない記憶されたデータを含む。ＲＡＭ８２に記憶されたデータは、ＣＰＵ９１または他のハードウェアデバイスによって読み取られ、または変更され得る。ＲＡＭ８２および／またはＲＯＭ９３へのアクセスは、メモリコントローラ９２によって制御され得る。メモリコントローラ９２は、命令が実行されると、仮想アドレスを物理的アドレスに変換するアドレス変換機能を提供し得る。メモリコントローラ９２はまた、システム内のプロセスを分離し、ユーザプロセスからシステムプロセスを分離するメモリ保護機能を提供し得る。したがって、第１のモードで作動するプログラムは、独自のプロセス仮想アドレス空間によってマップされるメモリのみにアクセスすることができ、プロセス間のメモリ共有が設定されていない限り、別のプロセスの仮想アドレス空間内のメモリにアクセスすることができない。
【００６８】
加えて、コンピュータシステム９０は、ＣＰＵ９１からプリンタ９４、キーボード８４、マウス９５、およびディスクドライブ８５等の周辺機器に命令を伝達する責任がある周辺機器コントローラ８３を含み得る。
【００６９】
ディスプレイコントローラ９６によって制御されるディスプレイ８６は、コンピュータシステム９０によって生成される視覚出力を表示するために使用される。そのような視覚出力は、テキスト、グラフィックス、動画グラフィックス、およびビデオを含み得る。ディスプレイ８６は、ＣＲＴベースのビデオディスプレイ、ＬＣＤベースのフラットパネルディスプレイ、ガスプラズマベースのフラットパネルディスプレイ、またはタッチパネルを伴って実装され得る。ディスプレイコントローラ９６は、ディスプレイ８６に送信されるビデオ信号を生成するために必要とされる電子構成要素を含む。ディスプレイ８６は、組み込み意味論名を使用して、ファイルまたはフォルダ内の知覚データを表示し得る。さらに、コンピュータシステム９０は、図４Ａおよび４Ｂのネットワーク１２等の外部通信ネットワークにコンピュータシステム９０を接続するために使用され得るネットワークアダプタ９７を含み得る。
【００７０】
本願によると、本明細書で説明されるシステム、方法、およびプロセスのうちのいずれかまたは全ては、命令が、コンピュータ、サーバ、Ｍ２Ｍ端末デバイス、Ｍ２Ｍゲートウェイデバイス等のマシンによって実行されると、本明細書で説明されるシステム、方法、ならびにプロセスを行うおよび／または実装する、コンピュータ読み取り可能な記憶媒体上に記憶されたコンピュータ実行可能命令（例えば、プログラムコード）の形態で具現化され得ることが理解される。具体的には、上で説明されるステップ、動作、または機能のうちのいずれかは、そのようなコンピュータ実行可能命令の形態で実装され得る。コンピュータ読み取り可能な記憶媒体は、情報の記憶のための任意の方法または技術で実装される、揮発性および不揮発性、取り外し可能なおよび非取り外し可能な媒体の両方を含むが、そのようなコンピュータ読み取り可能な記憶媒体は、信号を含まない。コンピュータ読み取り可能な記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）または他の光学ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置または他の磁気記憶デバイス、もしくは所望の情報を記憶するために使用することができ、コンピュータによってアクセスすることができる任意の他の物理的媒体を含むが、それらに限定されない。
【００７１】
（トラックを確保するための技法）
本願の側面によると、ＬＬＮデバイスが６ＴｉＳＣＨネットワーク内でトラックを確保するための技法が、開示される。図５に図示されるように、発信元ＬＬＮデバイスは、バックボーンルータを使用して、宛先までのトラックの配分を要求する。バックボーンルータ上のＰＣＥプロキシは、ＰＣＥがトラック上に位置するＬＬＮデバイスのＴＳＣＨスケジュールを構成することを支援する。ある実施形態によると、ＰＣＥは、発信元と宛先との間のトラックを構成するために、複数のメッセージの代わりに、１つの応答メッセージをバックボーンルータに送信する。例えば、図５におけるＰＣＥは、ＰＣＥＰにおいてトラック要求をＰＣＥＰプロキシを有するバックボーンルータ１から受信する。そして、ＰＣＥは、ＰＣＥＰにおいてトラック応答をＰＣＥＰプロキシを有するバックボーンルータ１に送信する。ＰＣＥによって受信される要求の周波数が限定されるこの技法によると、ＰＣＥの全体的仕事量を低減させ得る。
【００７２】
別の実施形態によると、バックボーンルータの確保プロシージャを詳述するコールフローが、説明される。すなわち、図６に図示されるように、発信元ＬＬＮデバイスは、ＩＣＭＰプロトコルを使用して、トラック配分要求（ＴＡＲｅｑ）をバックボーンルータ１上に位置するＰＣＥプロキシに送信する（ステップ１）。プロシージャの各ステップは、図６では、ローマ数字によって示される。ＴＡＲｅｑは、限定ではないが、以下の表２に列挙されるフィールドを含み得る。
【表２】
2017528956.tif 000004
【００７３】
ステップ２によると、バックボーンルータ１上のＰＣＥプロキシは、ＴＡＲｅｑを抽出し、ＰＣＥＰプロトコルを使用して、ＴＣＲｅｐをＰＣＥに送信する。ＴＣＲｅｐは、限定ではないが、以下の表３に列挙されるフィールドを含み得る。
【表３】
2017528956.tif 000005
【００７４】
次に、ＰＣＥは、遠隔またはその中に位置するセルスケジュールデータベースをチェックするであろう（ステップ３）。ここでは、ＰＣＥは、セルスケジュールデータベースをチェックし、発信元ＬＬＮデバイスから宛先ＬＬＮデバイスまでの最適トラックを計算するであろう。次に、ＰＣＥは、ＰＣＥＰプロトコルを使用して、トラック計算返信（ＴＣＲｅｐ）メッセージをバックボーンルータ１上のＰＣＥプロキシに送信するであろう（ステップ４）。ＴＣＲｅｐは、限定ではないが、以下の表４に列挙されるフィールドを含む。表４によると、「要求の結果」以外のフィールド名は、「要求の結果」の値が真である場合のみ有効である。
【表４】
2017528956.tif 000006
【００７５】
ステップ５によると、バックボーンルータ１上のＰＣＥプロキシは、トラック情報をＴＣＲｅｐから抽出し、トラック上のピアのためのトラック割り当てメッセージを構築する。次に、トラック割り当てメッセージは、指定されたトラック上の全ＬＬＮデバイスに送信される。図６に示されるように、ＬＬＮデバイス２および３は、ＩＣＭＰプロトコルを介して、さらなる命令を待つように通知される（ステップ６および８）。さらに、トラック割り当てメッセージは、他のＬＬＮデバイスによってホップされ得る。例えば、図５は、トラック上に位置するＬＬＮデバイス３に到達するために、バックボーンルータ１からＬＬＮデバイス４（例えば、トラック外）にホップされるメッセージを図示する。トラック割り当てメッセージは、限定ではないが、以下の表５に列挙されるフィールドを含み得る。
【表５】
2017528956.tif 000007
【００７６】
次に、ＬＬＮデバイス２および３は、それぞれ、ＩＣＭＰプロトコルを使用して、トラック割り当て確認メッセージをバックボーンルータ１上のＰＣＥプロキシに送信するであろう（ステップ７および９）。トラック割り当て確認をトラック上の全ＬＬＮデバイスから受信後、トラック配分返信メッセージが、ＩＣＭＰプロトコルを使用して、バックボーンルータ１から発信元ＬＬＮデバイス１に送信される。トラック配分返信メッセージは、限定ではないが、以下の表６に列挙されるフィールドを含む。最後に、発信元ＬＬＮデバイス、例えば、ＬＬＮデバイス１は、ＩＣＭＰプロトコルを使用して、トラック配分確認メッセージをバックボーンルータ１上のＰＣＥプロキシに返信するであろう。
【表６】
2017528956.tif 000008
【００７７】
別の実施形態によると、バックボーンルータが、ＬＬＮデバイスから受信されたＴＡＲｅｑメッセージを待ち行列に入れ、１つ以上のＴＡＲｅｑメッセージを含む集約されたトラック計算要求（ＡＴＣＲｅｐ）を送信する技法が、説明される。そうすることによって、ＰＣＥに送信され、したがって、そこに到着するＴＣＲｅｐパケットの数は、最終的に低減される。特に、図７は、本実施形態のコールフローを図示する。各ステップは、図７では、ローマ数字によって示される。
【００７８】
ステップ１および３によると、ＴＡＲｅｑメッセージは、発信元ＬＬＮデバイス１および２の各々によって、バックボーンルータに送信される。追加のＬＬＮデバイスが、当業者の所望に応じて採用され得る。さらに、待ち行列選択が、各発信元ＬＬＮデバイスに対して提供される。ＴＡＲｅｑメッセージ内の待ち行列選択は、ＴＡＲｅｑメッセージがバックボーンルータ上のＰＣＥプロキシ内の待ち行列に入れられることが許可される場合、「１」に設定される。そうでなければ、「０」に設定される。例えば、図７に示されるように、ＬＬＮデバイス１は、１の選択を有する一方、ＬＬＮデバイス２は、０の選択を有する。
【００７９】
バックボーンルータ１上のＰＣＥプロキシは、次いで、発信元のＬＬＮデバイス１およびＬＬＮデバイス２の各々から受信されるＴＡＲｅｑメッセージおよびその待ち行列選択をチェックする（ステップ２および４）。バックボーンルータ１上のＰＣＥプロキシは、「１」の待ち行列選択を有するＬＬＮデバイスに関連付けられたＴＡＲｅｑメッセージを待ち行列にプッシュインするであろう。これは、ＬＬＮデバイス１からのＴＡＲｅｑメッセージである。ステップ５では、バックボーンルータ１上のＰＣＥプロキシは、ＰＣＥＰプロトコルを使用して、「集約されたトラック計算要求」（ＡＴＣＲｅｐ）メッセージをＰＣＥに送信する。これは、以下の場合に行われ得る：（ｉ）ＬＬＮデバイスから受信されるＴＡＲｅｑが待ち行列に入れられることができない、例えば、ＴＡＲｅｑメッセージ内の待ち行列選択が「０」である、（ｉｉ）待ち行列内のＴＡＲｅｑｓの数が最大限界に到達している、および、（ｉｉｉ）ＴＣＲｅｐメッセージが送信された最後の時間以降にタイムアウトが生じている。別の実施形態では、バックボーンルータ１上のＰＣＥプロキシは、以下の表７に列挙されるような待ち行列内に記憶された全ＴＡＲｅｑメッセージを含むＴＣＲｅｐメッセージをＰＣＥに送信する。
【表７】
2017528956.tif 000009
【００８０】
次に、ＰＣＥがＡＴＣＲｅｐメッセージを受信後、ＰＣＥは、セルスケジュールデータベースをチェックし、ＴＣＲｅｐメッセージ内の全ての要求されるトラックを計算するであろう（ステップ６）。図７に提供されるように、ＰＣＥは、ＰＣＥＰプロトコルを使用して、集約されたトラック計算返信（ＡＴＣＲｅｐ）メッセージをバックボーンルータ１上のＰＣＥプロキシに送信する（ステップ７）。ＡＴＣＲｅｐメッセージは、表４に列挙されるような１つ以上のＴＣＲｅｐメッセージを含む。次に、バックボーンルータ１上のＰＣＥプロキシは、ＡＴＣＲｅｐメッセージから受信される各ＴＣＲｅｐメッセージを抽出する。次いで、同じプロシージャに従って、ＡＴＣＲｅｐメッセージ内の各トラックを構成する（ステップ８）。一実施形態によると、「ブロックＡ」として参照される図６におけるステップ６−１１で論じられるプロトコルは、図７では、バックボーンルータ１と発信元ＬＬＮデバイス１および２の各々との間で採用され得る。
【００８１】
本願のさらに別の実施形態によると、トラック確保を促進するための複数のバックボーンルータ間の協働のための技法が、説明される。図８に図示されるように、バックボーンルータは、ネットワーク内の他のバックボーンルータとネゴシエートおよび協働し、トラック割り当てを促進する。一次バックボーンルータは、ＬＬＮデバイスにより近くに位置する別のバックボーンルータを識別することによって、それを行い得る。そうすることによって、バックボーンルータ、例えば、バックボーンルータ１によってハンドリングされる重い仕事量の一部が、軽減され得る。代わりに、それは、多くのバックボーンルータ間で分散される。好ましくは、トラック内の各ＬＬＮデバイスは、それに最も近くに位置するバックボーンルータによって構成される。これは、トラックが長過ぎるとき、実践的であり得る。直感的に、バックボーンルータがより遠くに位置するＬＬＮデバイスを構成するためには、より長い時間がかかる。これは、トラックを配分するために必要な時間を短縮することに役立つであろう。
【００８２】
別の実施形態によると、例えば、図９に示されるように、ＬＬＮデバイス１、例えば、発信元は、ＩＣＭＰプロトコルを使用して、ＴＡＲｅｑをバックボーンルータ１上に位置するＰＣＥプロキシに送信する（ステップ１）。プロシージャの各ステップは、図９では、ローマ数字によって示される。ステップ２によると、バックボーンルータ１上のＰＣＥプロキシは、ＴＡＲｅｑを抽出し、ＰＣＥＰプロトコルを使用して、ＴＣＲｅｐをＰＣＥに送信する。次に、ＰＣＥは、遠隔またはその中に位置するセルスケジュールデータベースをチェックするであろう（ステップ３）。ここでは、ＰＣＥは、セルスケジュールデータベースをチェックし、発信元ＬＬＮデバイスから宛先ＬＬＮデバイスまでの最適トラックを計算するであろう。次に、ＰＣＥは、ＰＣＥＰプロトコルを使用して、トラック計算返信（ＴＣＲｅｐ）メッセージをバックボーンルータ１上のＰＣＥプロキシに送信するであろう（ステップ４）。
【００８３】
次に、バックボーンルータ１上のＰＣＥプロキシは、トラック情報をＴＣＲｅｐから抽出する（ステップ５）。次いで、バックボーンルータ１上のＰＣＥプロキシは、トラック転送要求をネットワーク内の全ての他のＰＣＥプロキシバックボーンルータに送信する（ステップ６）。概して、ＰＣＥプロキシバックボーンルータは、ＩＣＭＰプロトコルを使用する。トラック転送要求を送信することによって、バックボーンルータ１は、トラック割り当てプロセスをより効率的に完了するために協働し得る他のバックボーンルータを見つけることが可能となる。図９に示されるように、バックボーンルータ１は、ＬＬＮデバイス２および３により近いバックボーンルータ２を見つける。トラック転送要求メッセージは、限定ではないが、表８に列挙されるフィールドを含み得る。
【表８】
2017528956.tif 000010
【００８４】
次に、バックボーンルータのうちの１つ以上のもの、例えば、トラック転送要求を受信するバックボーンルータ２上のＰＣＥプロキシは、ＩＣＭＰプロトコルを使用して、トラック転送返信メッセージをバックボーンルータ１に返信する（ステップ７）。すなわち、バックボーンルータ２は、バックボーンルータ１に、到達され得る、トラック上のＬＬＮデバイス（例えば、ＬＬＮデバイス２および３等）を通知し得る。バックボーンルータ１上のＰＣＥプロキシは、次いで、ＬＬＮデバイス２および３のＴＳＣＨスケジュールをバックボーンルータ２上のＰＣＥプロキシ上に構成すべきかどうかを決定する（ステップ８）。決定が「はい」である場合、バックボーンルータ１上のＰＣＥプロキシは、ＩＣＭＰプロトコルを使用して、トラック転送割り当て要求をバックボーンルータ２上のＰＣＥプロキシに送信するであろう（ステップ９）。トラック転送割り当て要求メッセージは、限定ではないが、表９に列挙されるフィールドを含み得る。
【表９】
2017528956.tif 000011
【００８５】
バックボーンルータ２上のＰＣＥプロキシがトラック転送割り当て要求をバックボーンルータ１上のＰＣＥプロキシから受信した後、バックボーンルータ２上のＰＣＥプロキシは、ＩＣＭＰプロトコルを使用して、トラック割り当てメッセージを、例えば、ＬＬＮデバイス２（トラック上のデバイス）および３（宛先）等のトラック転送割り当て要求内に位置する全ＬＬＮデバイス（ステップ１０および１２）に送信するであろう。トラック割り当てメッセージは、限定ではないが、上記の表５に列挙されるフィールドを含む。
【００８６】
トラック割り当てメッセージを受信する、例えば、ＬＬＮデバイス２および３等のＬＬＮデバイスは、ＩＣＭＰプロトコルを使用して、トラック割り当て確認メッセージをバックボーンルータ２上のＰＣＥプロキシに送信するであろう（ステップ１１および１３）。全てのトラック割り当て確認をトラック上のＬＬＮデバイスから受信した後、バックボーンルータ２上のＰＣＥプロキシは、ＩＣＭＰプロトコルを使用して、トラック転送割り当て確認メッセージをバックボーンルータ１上のＰＣＥプロキシに送信し得る。その後、バックボーンルータ１上のＰＣＥプロキシは、ＩＣＭＰプロトコルを使用して、トラック配分返信メッセージを発信元ＬＬＮデバイスに送信するであろう（ステップ１５）。トラック配分返信メッセージは、限定ではないが、上記の表６に列挙されるフィールドを含み得る。さらに、発信元ＬＬＮデバイスは、ＩＣＭＰプロトコルを使用して、トラック配分確認メッセージをバックボーンルータ１上のＰＣＥプロキシに送信し得る。
【００８７】
さらに別の実施形態によると、ＰＣＥ支援トラック確保プロシージャが、開示される。すなわち、この技法は、例えば、高制御メッセージオーバーヘッドがバックボーンルータ間に存在するときに採用され得る。この技法は、多くのバックボーンルータがネットワーク内に存在する場合においてさらに好ましくあり得る。
【００８８】
図１０に示されるように、ＰＣＥが、セルスケジュールデータベースをチェックし、発信元と宛先との間のトラックを計算すると、ＰＣＥは、トラック上のＬＬＮデバイスのＴＳＣＨスケジュールを転送する、バックボーンルータ上のＰＣＥプロキシのアドレスを決定し得る。したがって、ＰＣＥは、トラック割り当てメッセージを、トラック上のＬＬＮデバイスにより近くに位置するバックボーンルータ上のＰＣＥプロキシに直接送信することができる。そうすることによって、バックボーンルータ間のオーバーヘッドに起因するネゴシエーションは、低減および／またはさらに排除され得る。
【００８９】
図１１に図示されるように、ＰＣＥ支援トラック確保プロシージャのコールフローが、提供される。図１１におけるステップの各々は、ローマ数字によって示される。図１１におけるステップ１−３は、上記の図６で参照されたものに類似する。ここでは、ＰＣＥは、トラック上の各ＬＬＮデバイスのＴＳＣＨスケジュールを報告する、バックボーンルータ上のＰＣＥプロキシを特定する（ステップ４）。例えば、バックボーンルータ２は、ＬＬＮデバイス２およびＴＳＣＨのスケジュールを報告するように構成される。ＰＣＥは、ＰＣＥＰプロトコルを使用して、トラック転送割り当て要求メッセージをバックボーンルータ２上のＰＣＥプロキシに送信するであろう（ステップ５）。トラック転送割り当て要求メッセージは、限定ではないが、上記の表９に列挙されるフィールドを含み得る。バックボーンルータ２上のＰＣＥプロキシは、次いで、トラック転送割り当て要求内に含まれる全ＬＬＮデバイスを抽出し、トラック割り当てメッセージを構築するであろう（ステップ５）。
【００９０】
バックボーンルータ２上のＰＣＥプロキシは、次いで、ＩＣＭＰプロトコルを使用して、トラック割り当てメッセージをＬＬＮデバイス２および３に送信し、その確認を待つであろう（ステップ６および８）。トラック割り当てメッセージは、限定ではないが、上記に開示される表５に列挙されるフィールドを含み得る。ＬＬＮデバイス２および３は、ＩＣＭＰプロトコルを使用して、トラック割り当て確認メッセージをバックボーンルータ２上のＰＣＥプロキシに送信するであろう（ステップ７および９）。全トラック割り当て確認をトラック上のＬＬＮデバイスから受信した後、バックボーンルータ２上のＰＣＥプロキシは、ＰＣＥＰプロトコルを使用して、トラック割り当て確認メッセージをＰＣＥに送信するであろう（ステップ１０）。ＰＣＥは、次いで、ＰＣＥＰプロトコルを使用して、ＴＣＲｅｐメッセージをバックボーンルータ１上のＰＣＥプロキシに送信するであろう（ステップ１１）。ＴＣＲｅｐは、限定ではないが、上記に開示される表４に列挙されるフィールドを含み得る。
【００９１】
バックボーンルータ１上のＰＣＥプロキシは、次いで、ＴＣＲｅｐ内で構成されるべきＬＬＮデバイスを抽出するであろう（ステップ１２）。次に、バックボーンルータ１上のＰＣＥプロキシは、トラック配分返信メッセージを発信元ＬＬＮデバイスに送信するであろう（ステップ１３）。トラック配分返信メッセージは、限定ではないが、上記に開示される表６に列挙されるフィールドを含み得る。さらに、発信元ＬＬＮデバイスは、ＩＣＭＰプロトコルを使用して、トラック配分確認メッセージをバックボーンルータ１上のＰＣＥプロキシに送信するであろう（ステップ１４）。
【００９２】
（情報をＬＬＮデバイスからＰＣＥに報告するための技法）
本願の別の側面によると、情報をＬＬＮデバイスからＰＣＥに報告する方法が、開示される。図１２に図示されるように、ＬＬＮデバイスは、ＰＣＥＰプロトコルを使用して、直接、ＰＣＥに報告する代わりに、ＩＣＭＰプロトコルを使用して、ＴＳＣＨスケジュール報告メッセージ内においてそのＴＳＣＨスケジュールをバックボーンルータ上のその最も近いＰＣＥプロキシに報告し得る。
【００９３】
本願に前述されたように、「ハードセル」は、ネットワークの中央コントローラによって構成される。したがって、ＰＣＥは、新しいリソースを配分すると、この情報を把握する。しかしながら、「ソフトセル」は、各ＬＬＮデバイスによって構成され、したがって、ＰＣＥは、この情報を把握しない。
【００９４】
このプロシージャのためのコールフローが、図１３に示され、各ステップは、ローマ数字、例えば、１によって示される。６ＴｉＳＣＨネットワーク内の各ＬＬＮデバイスは、新しいリソースを効率的に配分し得るように、その「ソフトセル」を周期的にＰＣＥに報告することが要求される（ステップ１）。ＴＳＣＨスケジュール報告メッセージは、限定ではないが、以下の表１０に列挙されるフィールドを含み得る。
【表１０】
2017528956.tif 000012
【００９５】
バックボーンルータ上のＰＣＥプロキシは、ＬＬＮデバイスから受信されるＴＳＣＨスケジュール報告メッセージを集約し、次いで、ＰＣＥＰプロトコルを使用して、これらのＴＳＣＨスケジュールをＰＣＥに報告し得る（ステップ２）。集約されたＴＳＣＨスケジュール報告メッセージのコンテンツは、以下の表１１に示される。
【表１１】
2017528956.tif 000013
【００９６】
さらに、ＰＣＥは、受信されたＴＳＣＨスケジュールをセルスケジュールデータベースに記憶する（ステップ３）。セルスケジュールデータベース内に記憶された各記録は、以下の表１２に示されるようなフィールド／パラメータ／属性を含む。ＰＣＥは、セルスケジュールデータベース内に記憶された情報を利用して、トラックを効率的に計算および構成し得る。
【表１２】
2017528956.tif 000014
【００９７】
本願のさらに別の側面によると、コンピュータ読み取り可能なまたは実行可能記命令を記憶するための非一過性のコンピュータ読み取り可能なもしくは実行可能記憶媒体が開示される。媒体は、図６、７、９、１１、および１３による、複数の呼び出しフローにおいて上記で開示されるような１つ以上のコンピュータ実行可能命令を含み得る。コンピュータ実行可能命令は、上記の図４Ｃおよび４Ｄで開示されるメモリ内に記憶され、プロセッサによって実行され、ＬＬＮデバイス、バックボーンルータ、およびＰＣＥを含むデバイスにおいて採用され得る。一実施形態では、図４Ｃおよび４Ｄに前述のように、不揮発性メモリおよびそこに動作可能に結合されているプロセッサを有するコンピュータ実装ＬＬＮが、開示される。具体的には、不揮発性メモリは、ネットワーク内でトラックを配分するための命令を記憶している。プロセッサは、以下の命令を行うように構成される：（ｉ）ＩＣＭＰにおいてトラック配分要求メッセージをバックボーンルータに送信すること、（ｉｉ）トラック配分返信メッセージをバックボーンルータから受信すること、および（ｉｉｉ）確認メッセージをバックボーンルータに送信すること。
【００９８】
システムおよび方法が、現在、特定の側面と見なされるものに関して説明されているが、本願は、開示される側面に限定される必要はない。請求項の精神および範囲内に含まれる種々の修正および同様の配列を網羅することが意図され、その範囲は、全てのそのような修正および同様の構造を包含するように、最も広い解釈を与えられるべきである。本開示は、以下の請求項のすべての側面を含む。
【図１】
2017528956.tif 000015
【図２】
2017528956.tif 000016
【図３】
2017528956.tif 000017
【図４Ａ】
2017528956.tif 000018
【図４Ｂ】
2017528956.tif 000019
【図４Ｃ】
2017528956.tif 000020
【図４Ｄ】
2017528956.tif 000021
【図５】
2017528956.tif 000022
【図６】
2017528956.tif 000023
【図７】
2017528956.tif 000024
【図８】
2017528956.tif 000025
【図９】
2017528956.tif 000026
【図１０】
2017528956.tif 000027
【図１１】
2017528956.tif 000028
【図１２】
2017528956.tif 000029
【図１３】
2017528956.tif 000030
【国際調査報告】
2017528956.tif 000031
2017528956.tif 000032
2017528956.tif 000033