(57)【要約】  複数のデバイス間に確立されたメッシュネットワークを通じて通信する方法が開示される。各デバイスは無線ラジオを有し、かつ、当該方法は、各デバイス上でメッシュサービスを開始させることを伴い、デバイスのプロセッサー回路が、メッシュネットワークを通じたデバイス間の通信のために無線ラジオを制御するための機能を提供することを引き起こすように、メッシュサービスは作動可能である。各デバイスは、該デバイス上で実行される少なくとも１つのアプリケーションを有し、該少なくとも１つのアプリケーションはメッシュポートに関連付けられ、該メッシュポートは、データ送信を、複数のデバイスのうちの少なくともいくつかのデバイス上で実行される特定のアプリケーションのインスタンスに関連付けられたものとして指定するのに用いられ、該少なくとも１つのアプリケーションと各デバイス上のメッシュサービスは、データ通信している。当該方法はまた、特定のメッシュポートを介した通信のためにメッシュネットワークへのアクセスを提供することを、１つのデバイス上で実行される特定のアプリケーションがメッシュサービスにリクエストすること、に応答して、特定のアプリケーションが特定のメッシュポートを介した通信の権限を与えられている否かを、メッシュサービスに判定させることを伴い、かつ、特定のアプリケーションが権限を与えられている場合には、特定のメッシュポートでメッシュネットワークを通じて通信するための、アプリケーションからのリクエストを処理し、かつ、特定のメッシュポートに関連付けられたデータ送信を特定のアプリケーションへと転送することを伴い、かつ、特定のアプリケーションが権限を与えられていない場合には、特定のメッシュポートでメッシュネットワークを通じて通信するための、アプリケーションからのリクエストを拒否し、かつ、特定のメッシュポートに関連付けられたデータ送信への特定のアプリケーションによるアクセスを防止することを伴う。【選択図】図７
2020532251.tif 000002
【特許請求の範囲】
【請求項１】
複数のデバイス間に確立されたメッシュネットワークを通じて通信するための方法であって、各デバイスは無線ラジオを有し、当該方法は：
各デバイス上でメッシュサービスを開始させることを有し、前記デバイスのプロセッサー回路が、前記メッシュネットワークを通じたデバイス間の通信のために前記無線ラジオを制御するための機能を提供することを引き起こすように、前記メッシュサービスは作動可能であり；
各デバイスは、該デバイス上で実行される少なくとも１つのアプリケーションを有し、該少なくとも１つのアプリケーションはメッシュポートに関連付けられ、該メッシュポートは、データ送信を、前記の複数のデバイスのうちの少なくともいくつかのデバイス上で実行される特定のアプリケーションのインスタンスに関連付けられたものとして指定するのに用いられ、該少なくとも１つのアプリケーションと各デバイス上の前記メッシュサービスは、データ通信しており；
特定のメッシュポートを介した通信のために前記メッシュネットワークへのアクセスを提供することを、１つのデバイス上で実行される特定のアプリケーションが前記メッシュサービスにリクエストすること、に応答して：
前記の特定のアプリケーションが前記の特定のメッシュポートを介した通信の権限を与えられているか否かを、前記メッシュサービスに判定させることを有し；
前記の特定のアプリケーションが権限を与えられている場合には、前記の特定のメッシュポートで前記メッシュネットワークを通じて通信するための、前記アプリケーションからのリクエストを処理し、かつ、前記の特定のメッシュポートに関連付けられたデータ送信を前記の特定のアプリケーションへと転送することを有し；
前記の特定のアプリケーションが権限を与えられていない場合には、前記の特定のメッシュポートで前記メッシュネットワークを通じて通信するための、前記アプリケーションからのリクエストを拒否し、かつ、前記の特定のメッシュポートに関連付けられたデータ送信への前記の特定のアプリケーションによるアクセスを防止することを有する、
前記方法。
【請求項２】
前記メッシュサービスを開始させることが、前記デバイス上でオペレーティングシステムを起動させるときに前記メッシュサービスを開始させることを有する、請求項１に記載の方法。
【請求項３】
メッシュサービスを開始させることが：
前記の特定のアプリケーションがデバイス上で開始されることに応答して、前記メッシュサービスが前記デバイス上で現在実行されているか否かを判定することを有し；かつ、
前記メッシュサービスが現在実行されていない場合には、前記デバイス上で前記メッシュサービスを開始させることを有する、
請求項１に記載の方法。
【請求項４】
さらに、前記メッシュサービスが前記デバイス上で現在実行されている場合には、メッシュサービスバージョンが現行のものであるか否かを判定することを有し、かつ、現行のものでない場合には、前記の実行されているメッシュサービスを停止させること、および、アップデートされたメッシュサービスを再び開始させること有する、請求項３に記載の方法。
【請求項５】
さらに：
前記メッシュサービスをアップデートするためのプログラムコードを受け取ることを有し；かつ、
前記メッシュサービスをアップデートする前に、前記プログラムコード内の暗号コード
を読み取り、かつ、該暗号コードが先行して前記デバイス上に格納された暗号コードと一致するか否かを判定することを有する、
請求項４に記載の方法。
【請求項５】
前記の特定のアプリケーションを開始させるために、前記デバイスの前記プロセッサー回路によって実行される、コンピューター読取り可能な命令のアプリケーションセット内に含まれるコンピューター読取り可能な命令のメッシュサービスセットを、前記プロセッサー回路に実行させることによって、前記メッシュサービスが開始される、請求項３に記載の方法。
【請求項６】
各デバイスの前記プロセッサー回路によって実行されるオペレーティングシステムが、前記デバイス上でサービスを実行するための別個の機能を提供するように作動可能に構成され、かつ、当該方法が、サービスを実行するための前記の別個の機能を用いて前記メッシュサービスを実行し、かつ、アプリケーションによる、前記デバイス上でサービスを実行するための前記の別個の機能へのアクセスを制限することを有する、請求項１に記載の方法。
【請求項７】
各メッシュポートが、固有のメッシュポート識別子に関連付けられる、請求項１に記載の方法。
【請求項８】
特定のアプリケーションがそれぞれ、固有のアプリケーション識別子に関連付けられ、かつ、前記の特定のアプリケーションが前記の特定のメッシュポートを介した通信の権限を与えられているか否かを、前記メッシュサービスに判定させることが：
前記の特定のアプリケーションから前記アプリケーション識別子を受け取ることを有し；
前記アプリケーション識別子と、権限を与えられたアプリケーション識別子の格納されたリスト中のアプリケーション識別子とが、一致するか否かを判定し、かつ、メモリーロケーションにおける関連するメッシュポートが前記の特定のアプリケーションによってアクセスできないか否かを判定することを有する、
請求項１に記載の方法。
【請求項９】
前記アプリケーション識別子がデジタル署名を有する、請求項８に記載の方法。
【請求項１０】
特定のデバイス上で現在実行されていないアプリケーションのためのメッシュポートに関連付けられている該デバイス上で実行されているメッシュサービスにおいてデータ送信を受け取ることに応答して、該デバイス上で実行されているその他のアプリケーションによる前記データ通信へのアクセスを防止しながら、前記メッシュサービスに、前記メッシュネットワークを通じて前記データ送信を転送させる、請求項１に記載の方法。
【請求項１１】
特定のデバイス上で現在実行されているアプリケーションのためのメッシュポートに関連付けられている該デバイス上で実行されているメッシュサービスにおいてデータ送信を受け取ることに応答して、前記メッシュサービスに：
前記アプリケーションへと前記データ送信を転送させ；
その他のデバイスへと前記メッシュネットワークを通じて前記データ送信を転送させる、
請求項１に記載の方法。
【請求項１２】
各デバイス上の前記無線ラジオが、複数の無線送信リンクのうちのいずれかを用いて前記メッシュネットワークを通じて通信するように作動可能であり、かつ、メッシュネットワーク通信のための前記の複数の無線送信リンクのうちの少なくともいくつかへのアクセ
スを可能または不能にするためにユーザープリファレンスを受け取るためのアクセスを、前記メッシュサービスに提供させることをさらに有する、請求項１に記載の方法。
【請求項１３】
各デバイス上の前記メッシュサービスにおいてデータ送信を受け取ることに応答して、前記データ送信がメッシュネットワーク通信を制御することに関するデータを含むか否かを判定することを有し、かつ、前記データ送信がメッシュネットワーク通信を制御することに関するデータを含むと判定することに応答して、前記データ送信にその他のデータ送信より高い送信優先順位を割り当てることを有する、請求項１に記載の方法。
【請求項１４】
前記データ送信により高い送信優先順位を割り当てることが、前記の複数のデバイスのうちのいずれかによる先行する送信の受け取りを確認するデータ、アプリケーションが前記メッシュネットワークにアクセスするためにデバイス上で開始されていることに関連付けられたデータ、アプリケーションがデバイス上で停止されていることに関連付けられたデータに、最も高い送信優先順位を割り当てることを有する、請求項１３に記載の方法。
【請求項１５】
特定のアプリケーションがそれぞれ、前記アプリケーションと前記メッシュサービスとの間のデータの送信のために前記メッシュサービスとインターフェースするように、前記デバイス上の前記プロセッサー回路に指示するためのアプリケーションインターフェースコードのセットを有する、請求項１に記載の方法。
【請求項１６】
前記メッシュサービスが、前記メッシュネットワークを用いてアプリケーションを開発するアプリケーションデベロッパーのためにデバッグ機能を提供するように作動可能であり、かつ、有効なデベロッパーキーシグネチャーを提供するアプリケーションデベロッパーに前記デバッグ機能を制限することを、前記メッシュサービスに行わせることをさらに有する、請求項１に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
背景
１．分野
本開示は概して、複数のネットワーク化されたデバイス間に確立されたメッシュネットワークを通じて通信することに関する。
【背景技術】
【０００２】
２．関連技術の説明
メッシュネットワークは、デバイスが協働してデバイス間でデータを中継してネットワークインフラ（ｎｅｔｗｏｒｋ  ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）を作り出すネットワークである。デバイスは、有線でネットワーク化されていてもよく、無線でネットワーク化されていてもよい。メッシュネットワークは、継続的にデバイスが該ネットワークに参加し、かつ、該ネットワークを去る点において、典型的には動的であり、したがって、該ネットワークを通じたデータの送信は、物理的なネットワークインフラが提供されてジェネラルローカリティ（ｇｅｎｅｒａｌ  ｌｏｃａｌｉｔｙ）に在るデバイスによる接続を促進する従来のネットワークでは直面しない困難を呈する。
【発明の概要】
【０００３】
概要
１つの開示される態様によれば、複数のデバイス間に確立されたメッシュネットワークを通じて通信するための方法が提供され、各デバイスは無線ラジオを有する。当該方法は、各デバイス上でメッシュサービスを開始させることを伴い、デバイスのプロセッサー回路が、メッシュネットワークを通じたデバイス間の通信のために無線ラジオを制御するための機能を提供することを引き起こすように、メッシュサービスは作動可能である。各デバイスは、該デバイス上で実行される少なくとも１つのアプリケーションを有し、該少なくとも１つのアプリケーションはメッシュポートに関連付けられ、該メッシュポートは、データ送信を、複数のデバイスのうちの少なくともいくつかのデバイス上で実行される特定のアプリケーションのインスタンスに関連付けられたものとして指定するのに用いられ、該少なくとも１つのアプリケーションと各デバイス上のメッシュサービスは、データ通信している。当該方法はまた、特定のメッシュポートを介した通信のためにメッシュネットワークへのアクセスを提供することを、１つのデバイス上で実行される特定のアプリケーションがメッシュサービスにリクエストすること、に応答して、特定のアプリケーションが特定のメッシュポートを介した通信の権限を与えられているか否かを、メッシュサービスに判定させることを伴い、かつ、特定のアプリケーションが権限を与えられている場合には、特定のメッシュポートでメッシュネットワークを通じて通信するための、アプリケーションからのリクエストを処理し、かつ、特定のメッシュポートに関連付けられたデータ送信を特定のアプリケーションへと転送することを伴い、かつ、特定のアプリケーションが権限を与えられていない場合には、特定のメッシュポートでメッシュネットワークを通じて通信するための、アプリケーションからのリクエストを拒否し、かつ、特定のメッシュポートに関連付けられたデータ送信への特定のアプリケーションによるアクセスを防止することを伴う。
【０００４】
メッシュサービスを開始させることは、デバイス上でオペレーティングシステムを起動させるときにメッシュサービスを開始させることを伴ってもよい。
【０００５】
メッシュサービスを開始させることは、特定のアプリケーションがデバイス上で開始されることに応答して、メッシュサービスがデバイス上で現在実行されているか否かを判定
することを伴ってもよく、かつ、メッシュサービスが現在実行されていない場合には、デバイス上でメッシュサービスを開始させることを伴ってもよい。
【０００６】
当該方法は、メッシュサービスがデバイス上で現在実行されている場合には、メッシュサービスバージョンが現行のものであるか否かを判定することを伴ってもよく、かつ、現行のものでない場合には、実行されているメッシュサービスを停止させ、かつ、アップデートされたメッシュサービスを再び開始させることを伴ってもよい。
【０００７】
当該方法は、メッシュサービスをアップデートするためのプログラムコードを受け取ることを伴ってもよく、かつ、メッシュサービスをアップデートする前に、プログラムコード内の暗号コードを読み取り、かつ、該暗号コードが先行してデバイス上に格納された暗号コードと一致するか否かを判定することを伴ってもよい。
【０００８】
特定のアプリケーションを開始させるために、デバイスのプロセッサー回路によって実行される、コンピューター読取り可能な命令（ｃｏｍｐｕｔｅｒ  ｒｅａｄａｂｌｅ  ｉｎｓｔｒｕｃｔｉｏｎ）のアプリケーションセット内に含まれるコンピューター読取り可能な命令のメッシュサービスセットを、前記プロセッサー回路に実行させることによって、メッシュサービスが開始されてもよい。
【０００９】
各デバイスのプロセッサー回路によって実行されるオペレーティングシステムは、デバイス上でサービスを実行するための別個の機能を提供するように作動可能に構成されてもよく、かつ、当該方法は、サービスを実行するための別個の機能を用いてメッシュサービスを実行し、かつ、アプリケーションによる、デバイス上でサービスを実行するための別個の機能へのアクセスを制限することを伴ってもよい。
【００１０】
各メッシュポートは、固有のメッシュポート識別子に関連付けられてもよい。
【００１１】
特定のアプリケーションはそれぞれ、固有のアプリケーション識別子に関連付けられてもよく、かつ、特定のアプリケーションが特定のメッシュポートを介した通信の権限を与えられているか否かを、メッシュサービスに判定させることは、特定のアプリケーションからアプリケーション識別子を受け取り、該アプリケーション識別子と、権限を与えられたアプリケーション識別子の格納されたリスト中のアプリケーション識別子とが、一致するか否かを判定し、かつ、メモリーロケーションにおける関連するメッシュポートが特定のアプリケーションによってアクセスできないか否かを判定することを伴ってもよい。
【００１２】
アプリケーション識別子は、デジタル署名を含んでもよい。
【００１３】
特定のデバイス上で現在実行されていないアプリケーションのためのメッシュポートに関連付けられている該デバイス上で実行されているメッシュサービスにおいてデータ送信を受け取ることに応答して、該デバイス上で実行されているその他のアプリケーションによるデータ通信へのアクセスを防止しながら、メッシュサービスに、メッシュネットワークを通じてデータ送信を転送させる。
【００１４】
特定のデバイス上で現在実行されているアプリケーションのためのメッシュポートに関連付けられている該デバイス上で実行されているメッシュサービスにおいてデータ送信を受け取ることに応答して、メッシュサービスに、アプリケーションへとデータ送信を転送させ、その他のデバイスへとメッシュネットワークを通じてデータ送信を転送させる。
【００１５】
各デバイス上の無線ラジオは、複数の無線送信リンクのうちのいずれかを用いてメッシュネットワークを通じて通信するように作動可能であってもよく、かつ、メッシュネット
ワーク通信のための複数の無線送信リンクのうちの少なくともいくつかへのアクセスを有効または無効にするためにユーザープリファレンス（ｕｓｅｒ  ｐｒｅｆｅｒｅｎｃｅ；ユーザーの嗜好）を受け取るためのアクセスを、メッシュサービスに提供させることをさらに伴ってもよい。
【００１６】
当該方法は、各デバイス上のメッシュサービスにおいてデータ送信を受け取ることに応答して、データ送信がメッシュネットワーク通信を制御することに関するデータを含むか否かを判定することを伴ってもよく、かつ、データ送信がメッシュネットワーク通信を制御することに関するデータを含むと判定することに応答して、該データ送信にその他のデータ送信より高い送信優先順位を割り当てることを伴ってもよい。
【００１７】
データ送信により高い送信優先順位を割り当てることは、複数のデバイスのうちのいずれかによる先行する送信の受け取りを確認するデータ、アプリケーションがメッシュネットワークにアクセスするためにデバイス上で開始されていることに関連付けられたデータ、アプリケーションがデバイス上で停止されていることに関連付けられたデータに、最も高い送信優先順位を割り当てることを伴ってもよい。
【００１８】
特定のアプリケーションはそれぞれ、アプリケーションとメッシュサービスとの間のデータの送信のためにメッシュサービスとインターフェースする（ｉｎｔｅｒｆａｃｅ；相互接続する）ように、デバイス上のプロセッサー回路に指示するためのアプリケーションインターフェースコードのセットを含んでもよい。
【００１９】
メッシュサービスは、メッシュネットワークを用いてアプリケーションを開発するアプリケーションデベロッパーのためにデバッグ機能を提供するように作動可能であってもよく、かつ、有効なデベロッパーキーシグネチャー（ｖａｌｉｄ  ｄｅｖｅｌｏｐｅｒ  ｋｅｙ  ｓｉｇｎａｔｕｒｅ）を提供するアプリケーションデベロッパーにデバッグ機能を制限することを、メッシュサービスに行わせることをさらに伴ってもよい。
【００２０】
その他の態様および特徴は、添付の図面とともに特定の開示される実施形態の以下の説明を検討する際に、当業者に明らかになるであろう。
【図面の簡単な説明】
【００２１】
開示される実施形態を説明する図面において
【００２２】
【図１】図１は、複数のデバイス間に確立されたメッシュネットワークの概略図である。
【図２】図２は、図１に示されているデバイスを実施するためのプロセッサー回路のブロック図である。
【図３】図３は、図１に示されているデバイス上で実施される機能的ブロックの概略図である。
【図４】図４は、図２のプロセッサー回路に、図３に示されている機能的ブロックを開始させ、かつ、設定するように指示するためのコードのブロックを描いたフローチャートである。
【図５】図５は、図１に示されている複数のデバイスのうちのいずれかの上に表示されたユーザーインターフェースのスクリーンショットである。
【図６】図６は、図２のプロセッサー回路に、図１に示されているデバイス上でメッシュサービスを開始させるように指示するためのコードのブロックを描いたフローチャートである。
【図７】図７は、図１に示されているメッシュネットワークの一部の概略図である。
【図８Ａ】図８Ａ，Ｂは、図２のプロセッサー回路に、アプリケーションイベントハンドリングプロセスを実施するように指示するためのコードのブロックを描いたフローチャートである。
【図８Ｂ】図８Ａ，Ｂは、図２のプロセッサー回路に、アプリケーションイベントハンドリングプロセスを実施するように指示するためのコードのブロックを描いたフローチャートである。
【図９】図９は、コンテンツデータ送信を描いた概略図である。
【図１０Ａ】図１０Ａ，Ｂは、図２のプロセッサー回路に、メッシュサービスイベントハンドラーを実施するように指示するためのコードのブロックを描いたフローチャートである。
【図１０Ｂ】図１０Ａ，Ｂは、図２のプロセッサー回路に、メッシュサービスイベントハンドラーを実施するように指示するためのコードのブロックを描いたフローチャートである。
【図１１Ａ】図１１Ａ〜Ｅは、図２のプロセッサー回路に、図１に示されているデバイス上で信頼性の高い送信プロトコルを実施するように指示するためのコードのブロックを描いたフローチャートである。
【図１１Ｂ】図１１Ａ〜Ｅは、図２のプロセッサー回路に、図１に示されているデバイス上で信頼性の高い送信プロトコルを実施するように指示するためのコードのブロックを描いたフローチャートである。
【図１１Ｃ】図１１Ａ〜Ｅは、図２のプロセッサー回路に、図１に示されているデバイス上で信頼性の高い送信プロトコルを実施するように指示するためのコードのブロックを描いたフローチャートである。
【図１１Ｄ】図１１Ａ〜Ｅは、図２のプロセッサー回路に、図１に示されているデバイス上で信頼性の高い送信プロトコルを実施するように指示するためのコードのブロックを描いたフローチャートである。
【図１１Ｅ】図１１Ａ〜Ｅは、図２のプロセッサー回路に、図１に示されているデバイス上で信頼性の高い送信プロトコルを実施するように指示するためのコードのブロックを描いたフローチャートである。
【図１２】図１２は、図１に示されているメッシュネットワークを通じて送信されるデータパケットの例を描いた概略図である。
【図１３Ａ】図１３は、図２のプロセッサー回路に、図１に示されているデバイス上でマルチキャスト送信プロトコルを実施するように指示するためのコードのブロックを描いたフローチャートである。
【図１３Ｂ】図１３は、図２のプロセッサー回路に、図１に示されているデバイス上でマルチキャスト送信プロトコルを実施するように指示するためのコードのブロックを描いたフローチャートである。
【図１３Ｃ】図１３は、図２のプロセッサー回路に、図１に示されているデバイス上でマルチキャスト送信プロトコルを実施するように指示するためのコードのブロックを描いたフローチャートである。
【発明を実施するための形態】
【００２３】
詳細な説明
図１を参照すると、１００において、複数のデバイス間に確立されたメッシュネットワークが概して示されている。図１に示されている実施形態では、メッシュネットワークは、第１のデバイス１０２、第２のデバイス１０４、第３のデバイス１０６および第４のデバイス１１２を含む。図示されている実施形態では、デバイス１０２、１０４、１０６および１０８は、スマートフォンデバイスであり、かつ、カリフォルニア州マウンテンビューのＧｏｏｇｌｅ社によって利用可能とされているＡｎｄｒｏｉｄ商標のようなスマートフォンオペレーティングシステムまたは任意のその他の適切なオペレーティングシステムを実行していてもよい。この実施形態では、第１のデバイス１０２は、ユーザー１１４によって操作されている。メッシュネットワーク１００には、追加のデバイスもまた参加しており、該追加のデバイスは、ユーザー１１６によって操作されているタブレットコンピ
ューター１１０およびラップトップコンピューター１１２を含み、それぞれ無線ラジオを有する。その他の実施形態では、デバイス１０２〜１１２は、例えば、スマートフォン、タブレットもしくはラップトップコンピューター、デスクトップコンピューター、ルーターもしくはアクセスポイントのような独立型のネットワーク化デバイス、プリンターのようなコンピューター周辺機器、および／または、ネットワーク化された機器のような物理的実体のような、複数のネットワーク化されたデバイスのいずれかであってもよい。有線接続を有するその他のデバイス（図示せず）もまた、メッシュネットワークに参加してもよい。しかしながら、かかるデバイスは、図１に示されているデバイスとは異なるネットワークロール（ｎｅｔｗｏｒｋ  ｒｏｌｅ；ネットワークにおける役割）を引き受けてもよい。概して、デバイス１０２〜１１２はそれぞれ、各々のデバイスにメッシュネットワークを確立するための機能を提供させる、コンピューター読取り可能な命令の形式でローディングされたアプリケーションを有する。メッシュネットワーク１００では、デバイス１０２は、デバイス１０４、１０６、１１０および１１２のそれぞれと無線通信している。さらに、デバイス１０４および１１０は、デバイス１０８を通して無線で接続される。メッシュネットワーク１００内には、デバイス１０２〜１１２の性能および互いに対するそれらの地理的位置に基づいて、種々のその他の無線リンクが確立されてもよい。
【００２４】
図２には、２００において、デバイス１０２〜１１２のうちのいずれかを実施するためのプロセッサー回路のブロック図が示されている。図２を参照すると、プロセッサー回路２００は、多数の処理コアを含んでいてもよいマイクロプロセッサー２０２を含む。プロセッサー回路２００はまた、ディスプレイ２０４と、ユーザー入力を受け取るための入力デバイス２０６を含む。いくつかの実施形態では、入力デバイス２０６は、ディスプレイ２０４上のタッチスクリーンとして提供されてもよい。この実施形態では、プロセッサー回路２００は、デバイス上で実行されているアプリケーションに関連付けられたデータを格納するためのメモリー２１０を含む。メモリー２１０は、ランダムアクセスメモリー、不揮発性フラッシュメモリー、ハードドライブ、または、これらのメモリータイプおよびその他のメモリータイプの組み合わせを用いて実施されてもよい。メモリー２１０は、プログラムコードおよび／またはデータを格納するのに用いられ、かつ、図示されている実施形態では、オペレーティングシステム格納ロケーション２４０、メッシュサービスプログラムコードを格納するためのメッシュサービス格納ロケーション２８０、アプリケーションプログラムコードを格納するためのアプリケーション格納ロケーション２４４、ユーザープリファレンスロケーション２４６、ユーザー識別子（ｕｕｉｄ）ファイルロケーション２４８、メッシュポートテーブルロケーション２５０、暗号キー格納ロケーション２５２、メッシュサービスアプリケーションデータバッファーロケーション２５６、メッシュサービス送信データバッファーロケーション２５８、メッシュサービス送信キューロケーション２６０、無線リンクキューロケーション２６２、ルーティングテーブルロケーション２６４、カウンター内ロケーション２６６および転送バッファーロケーション２６８を含む。
【００２５】
プロセッサー回路２００はさらに、ＲＦベースバンドラジオ２１２と、モバイル通信ネットワークに接続するためのアンテナ２１４とを含む。ＲＦベースバンドラジオ２１２は、２Ｇ、３Ｇ、４Ｇまたはその他の通信基準を含む種々の通信基準のうちのいずれかを用いてデータ通信を提供するように構成されてもよい。
【００２６】
プロセッサー回路２００はまた、無線ラジオ２１６と、ＩＥＥＥ  ８０２．１１  ＷＬＡＮローカルネットワークのようなローカルネットワークに接続するためのアンテナ２１８とを含む。無線ラジオ２１６はまた、Ｂｌｕｅｔｏｏｔｈ、Ｗｉ−Ｆｉダイレクトまたは近距離無線通信のようなその他の無線リンクまたはプロトコルを介して接続を提供してもよい。
【００２７】
プロセッサー回路２００はさらに、任意選択的には、位置受信機２３０を含む。位置受信機２３０は、グローバルポジショニングシステム（ＧＰＳ）信号を受け取るためのアンテナ２１８を含み、かつ、位置受信機２３０は、特定のローカルネットワークアクセスポイントの既知の位置またはセルラーサービスプロバイダーによって提供されるセルラー信号三角測量情報のようなその他の位置情報と組み合わせてＧＰＳ情報を用い、ネットワーク化されたデバイスの位置を判定してもよい。
【００２８】
プロセッサー回路２００はさらに、オーディオプロセッサー２２０と、マイクロフォン２２２と、スピーカー２２４とを含む。オーディオプロセッサー２２０は、マイクロフォン２２２からの音声入力信号を受け取り、かつ、処理し、かつ、スピーカー２２４において音声出力を生成する。プロセッサー回路２００はまた、映像／画像プロセッサー２２６と、カメラ２２８とを含む。映像／画像プロセッサー２２６は、カメラ２２８からの画像および／または映像信号を受け取り、かつ、処理する。
【００２９】
ディスプレイ２０４と、入力デバイス２０６と、メモリー２１０と、ＲＦベースバンドラジオ２１２と、無線ラジオ２１６と、オーディオプロセッサー２２０と、映像／画像プロセッサー２２６とは、すべてマイクロプロセッサー２０２と通信している。
【００３０】
オペレーティングシステム格納ロケーション２４０はコードを格納し、該コードは、マイクロプロセッサー２０２に、スマートフォンデバイス１０２〜１０６についてはＡｎｄｒｏｉｄ商標ベースのオペレーティングシステム、ｉＯＳベースのオペレーティングシステムまたは任意のその他のオペレーティングシステムであってもよいオペレーティングシステムを実施するように指示するためのものである。タブレットコンピューター１１０とラップトップコンピューター１１２は、Ａｎｄｒｏｉｄ、ｉＯＳ、Ｗｉｎｄｏｗｓ登録商標、Ｌｉｎｕｘ、または、その他の適切なオペレーティングシステムを実行していてもよい。本明細書における残りの開示は概して、Ａｎｄｒｏｉｄベースのオペレーティングシステムの下での種々の開示される態様の実施に関するが、同一の原則はまた、いくつかの実施の相違点を有するその他のオペレーティングシステムにも適用される。
【００３１】
デバイス１０２〜１０８はそれぞれ、図２に示されているものに非常に類似するプロセッサー回路２００を用いて実施されてもよい。ラップトップコンピューターデバイス１１２は、図２に示されているコンポーネントの多くを含んでもよいが、位置受信機２３０およびＲＦベースバンドラジオ２１２のようないくつかのコンポーネントは、ラップトップコンピューター中に含まれてもよいが省略される場合がある。実施形態について図２におけるプロセッサー回路２００の構造を参照して本明細書に記載される一方で、記載されるシステムの実施形態および／またはプロセスの実施形態はまた、その他のタイプのデバイス間の通信にも適用可能である。概して、デバイス１０２〜１１２はそれぞれ、フラッシュメモリー２１０（または、その他のメモリータイプ）の中にローディングされた、コンピューターで読み取り可能なコードを有し、該コードは、各々のデバイスにメッシュネットワーク１００を確立するために必要な機能を提供させる。いくつかの実施形態では、メッシュネットワーク１００に参加しているデバイスは、図２に示されているコンポーネントのうちのいくつかを省略してもよい。例えば、あるデバイスが、接続済みのデバイスとしてスマートアプライアンス、車両、または、その他の物理的物体内に組み込まれてもよく、かつ、ディスプレイ２０４、入力デバイス２０６、または、その他の図２に描かれているコンポーネントのような要素を含まなくてもよい。接続済みのデバイスは、例えば、ｊａｖａ、ｃまたはｃ＋＋コードを実行することが可能であってもよく、かつ、無線リンクを確立するために、ＩＥＥＥ  ８０２．１１、Ｂｌｕｅｔｏｏｔｈ、Ｗｉ−Ｆｉダイレクトまたは近距離無線通信プロトコルを実施する無線ラジオ２１６を含んでもよい。
【００３２】
１つの実施形態では、メッシュネットワーク１００は、「ＭＥＴＨＯＤ  ＦＯＲ  ＥＳ
ＴＡＢＬＩＳＨＩＮＧ  ＮＥＴＷＯＲＫ  ＣＬＵＳＴＥＲＳ  ＢＥＴＷＥＥＮ ＮＥＴＷＯＲＫＥＤ  ＤＥＶＩＣＥＳ（ネットワーク化されたデバイス間のネットワーククラスターを確立するための方法）」と題する、２０１６年５月３０日付けで出願の、共有に係る特許である米国仮特許出願第６２／３４３，０５６号（参照によって、その全体が本明細書に組み込まれる）に開示されているように概して確立されてもよい。そのようであるので、メッシュネットワーク１００中のデバイスは、アクセスポイント、クライアントまたはルーターのいずれかとして作用するように構成されてもよい。アクセスポイントデバイス（本明細書では「マスターモード」ともいう）は、クライアントとして設定されたその他のデバイス（本明細書では「クライアントモード」ともいう）が、アクセスポイントに接続してデータを受け取り、かつ、アクセスポイントを介してメッシュネットワーク１００中のその他のクライアントへとデータを送信することを許可する。いくつかのクライアントデバイスはさらに、ルーターとして設定され（本明細書では「ルーティングモード」ともいう）、かつ、各アクセスポイントに接続することを交互に繰り返すことによって、アクセスポイントモードに設定された２つのデバイス間にリンクを提供するように作動可能である。
【００３３】
図３を参照すると、３００において、メッシュネットワークとの相互作用のために図１に示されているデバイスのうちのいずれかの上で実施される機能的ブロックの概略図が示されている。デバイス３００についての機能的ブロック図におけるブロックは、プロセッサー回路２００のマイクロプロセッサー２０２に、各々の機能を実施するためにデバイス上に必要な機能を実施するように指示する、コンピューターで読み取り可能なコードを表す。図示されている実施形態では、第１のアプリケーション３０２と第２のアプリケーション３０４がデバイス上で実行されているものとして示されており、かつ、コンテンツ、チャット、緊急サービス連絡先などを共有することのような種々のタスクを実行するためにデバイス上で機能を実施してもよい。図示されている実施形態では、第１のアプリケーション３０２はチャットアプリケーションであり、かつ、第２のアプリケーション３０４は緊急アプリケーションである。アプリケーション３０２は、デバイス上で実行されているメッシュサービス３１０と通信しているアプリケーションインターフェース３０６を有する。同様に、アプリケーション３０４は、デバイス上で実行されているメッシュサービス３１０と通信しているアプリケーションインターフェース３０８を有する。メッシュサービス３１０は、プロセッサー回路２００のマイクロプロセッサー２０２が、メッシュネットワーク１００を通じたデバイス間の通信のために無線ラジオ２１６を制御することを引き起こす。デバイス上で実行されており、かつ、両方のアプリケーション３０２および３０４（ならびに、デバイス上で実行されている任意の追加のアプリケーション）と通信している、単一のメッシュサービス３１０のみが存在する。 
【００３４】
図４を参照すると、４００において、デバイスのプロセッサー回路２０２に、図３に示されている機能的ブロックを開始させ、かつ、設定するように指示するためのコードのブロックを描いたフローチャートが概して示されている。図４におけるブロックは概して、マイクロプロセッサー２０２に、図３に示されている機能的ブロックを実施するように指示するためにメモリー２１０から読み取られてもよいコードを表す。各ブロックを実施するための実際のコードは、例えば、Ｊａｖａ、Ｃ、Ｏｂｊｅｃｔｉｖｅ−Ｃ、Ｃ＋＋、Ｃ＃および／またはアセンブリーコードのような任意の適切なプログラム言語で書かれてもよい。プロセスはブロック４０２において始まり、該ブロック４０２は、マイクロプロセッサー２０２に、アプリケーション（この場合、第１のアプリケーション３０２）を開始させるように指示し、該開始は、アプリケーション格納ロケーション２４４に格納された第１のアプリケーションについてのコンピューターで読み取り可能なコードを実行することによって行われる。アプリケーションが開始されるとき、第１のアプリケーション３０２についてのアプリケーションインターフェース３０６は、アプリケーション格納ロケーション２４４中のコンピューターで読み取り可能なコードに格納された、暗号コードまた
は署名を読み取る。暗号コードは、アプリケーションについてのメッシュサービス機能を実施するのに用いられ得る機能のライブラリーを含むソフトウェアデベロッパーツールのセットを受け取るときに第１のアプリケーションのデベロッパーによって取得されてもよい。そのようであるので、暗号コードは、デバイス３００上でアプリケーションを実行するのに用いられるアプリケーション格納ロケーション２４４から読み取られるコンピューターで読み取り可能なコードの一部として含まれてもよい。
【００３５】
ブロック４０４はその後、マイクロプロセッサー２０２に、メッシュサービス３１０がデバイス上で既に実行されているか否かを判定するように指示する。メッシュサービス３１０が既に実行されている場合、ブロック４０４はマイクロプロセッサー２０２にブロック４０６へと向かうように指示し、該ブロック４０６はマイクロプロセッサーにイベントを待つように指示する。
【００３６】
ブロック４０４においてメッシュサービス３１０がまだデバイス上で実行されていない場合、ブロック４０４はマイクロプロセッサー２０２にブロック４０８へと向かうように指示し、該ブロック４０８は、マイクロプロセッサーに、メッシュサービスがデバイス上で有効となっているか否かを判定するように指示する。図５を参照すると、５００において、ユーザープリファレンスを制御するためにユーザーインターフェースのデバイス上に表示されたスクリーンショットが示されている。ユーザープリファレンスインターフェース５００は、デバイスのユーザーが、メッシュサービスが有効であるか無効であるかについてのプリファレンスを設定することを許可する「メッシュサービス」制御５０２を含む（「メッシュサービス」制御は、図５では有効なものとして示されている）。ユーザープリファレンスインターフェース５００はまた、「Ｗｉ−Ｆｉメッシュ」制御５０４、「Ｂｌｕｅｔｏｏｔｈメッシュ」制御５０６、ならびに、「マスターモード」、「クライアントモード」、「ルーターモード」および「自動モード」の間で選択するためのラジオボタンを含むネットワークロールセレクター５０８を含む、その他のユーザープリファレンス制御を含む。ユーザープリファレンスインターフェース５００はまた、ユーザーがインターネットへの接続の共有を希望するか否かを示すためのインターネット共有制御５１０を含む。例えば、デバイスのうちの１つの上のＲＦベースバンドラジオ２１２、または、その他のインターフェースは、データネットワークを通じたインターネットへのアクセスを提供してもよく、かつ、ユーザーは、このアクセスをメッシュネットワーク１００上のその他のデバイスと共有することを選択してもよい。
【００３７】
ユーザープリファレンスは、ユーザープリファレンスインターフェース５００において受け取られ、かつ、メモリー２１０のユーザープリファレンスロケーション２４６に格納される。図４に戻ると、ブロック４０８はしたがって、マイクロプロセッサーに、ユーザープリファレンスロケーション２４６に格納された「メッシュサービス」制御の状態を読み取り、かつ、有効である場合にはマイクロプロセッサーにブロック４１０へと向かうように指示する。ブロック４１０は、マイクロプロセッサー２０２に、メッシュサービス格納ロケーション２８０に格納されたメッシュサービスプログラムコードを実行することによってメッシュサービス３１０を開始させるように指示する。ブロック４０５はまた、マイクロプロセッサー２０２に、メッシュサービス３１０に接続し、かつ、署名を交換するように指示する。プロセスはその後ブロック４０６において続き、該ブロック４０６はマイクロプロセッサー２０２に次のイベントを待つように指示する。
【００３８】
図示されている実施形態では、メッシュサービス３１０は、デバイス上のサービスとして開始され、１つより多いアプリケーションによって用いられ得るソフトウェア機能を参照する。プロセッサー回路２００は、アプリケーションによるアクセスから保護されるモードでサービスを実行して、変造およびサービスへの禁じられたアクセスを防止してもよい。サービスは、アプリケーションによる使用のためにサービスによって提供される機能
を陳列するアプリケーションプログラミングインターフェース（ＡＰＩ）を介してアプリケーションに機能を提供してもよい。
【００３９】
ブロック４０８において、ユーザープリファレンスロケーション２４６に格納された「メッシュサービス」制御の状態が無効である場合、マイクロプロセッサーは、ブロック４１２へと向かい、サービスがユーザーによって有効とされるのを待つように指示される。メッシュネットワーク１００への接続はしたがって、ユーザーが「メッシュサービス」制御５０２の状態を有効へと変更するまで延期される。アプリケーションはしかしながら、オフライン機能を実行し続けてもよい。マイクロプロセッサー２０２が、「メッシュサービス」制御５０２が有効となったことを検出するとき、マイクロプロセッサーはブロック４０４へと戻るように指示される。
【００４０】
ブロック４０６は、マイクロプロセッサー２０２に、イベントが受け取られたか否かを判定するように指示する。いかなるイベントも受け取られない場合、マイクロプロセッサー２０２はブロック４０６を繰り返すように指示される。ブロック４０６においてイベントが検出される場合、ブロック４０６は、マイクロプロセッサー２０２に、図８に示されているアプリケーションイベントハンドリングプロセス８００のブロック８０２へと向かうように指示する。
【００４１】
図４に示されている実施形態では、メッシュサービス３１０の開始はしたがって、特定のアプリケーション（この場合、第１のアプリケーション３０２）がデバイス上で開始されることに応答する。メッシュサービス３１０が現在実行されていない場合、メッシュサービスは、ユーザープリファレンスが、メッシュサービスが実行されることを可能にするように設定された場合にデバイス上で開始される。別の実施形態では、メッシュサービス３１０は、デバイスのオペレーティングシステムを起動させるときに開始されてもよい（すなわち、メモリー２１０中のオペレーティングシステム格納ロケーション２４０から）。
【００４２】
１つの実施形態では、メッシュサービス格納ロケーション２８０に格納されたメッシュサービスプログラムコードは、アプリケーション３０２および３０４のいずれか、もしくは、両方に関連付けられたアプリケーションコードとともに、または、該アプリケーションコードの一部として提供されてもよい。メッシュサービス３１０がブロック４０４においてデバイス上で現在実行されていることが見出される場合、プロセス４００はさらに、実行されているメッシュサービスバージョンが現行のものであるか否かを判定することを伴ってもよい。バージョンが現行のものでない場合、メッシュサービス３１０の実行されているバージョンは停止されてもよく、かつ、アップデートされたメッシュサービスが再び開始されるようにブロック４１０が繰り返されてもよい。例として、第２のアプリケーション３０４は、第１のアプリケーション３０２の前にメモリー２１０へとダウンロードされていてもよく、かつ、第１のアプリケーションはしたがって、メッシュサービス３１０のアップデートされたバージョンとともにパッケージ化されてもよい。代替的には、デバイス３００上で、第１のアプリケーション３０２のアップデートされたバージョンについてのプログラムコードが受け取られ、かつ、インストールされてもよく、かつ、アップデートされたプログラムコードは、アップデートされたメッシュサービスプログラムコードを含んでもよい。したがって、メッシュサービスへのアップデートが新しいアプリケーションをローディングしているデバイスへと自動的に広げられてもよいという利点は、アプリケーションコードとともにメッシュサービスプログラムを広めることに関連付けられる。
【００４３】
図３に戻ると、アプリケーションインターフェース３０６および３０８とメッシュサービス３１０との間のプロセス間通信が、矢印３１２および３１４によって表されている。
これらのプロセス間通信３１２は、デバイス上で実行されているオペレーティングシステムに依拠し、かつ、デバイスに関連付けられた１つ以上のプロトコルを用いて実施されてもよい。例えば、Ａｎｄｒｏｉｄオペレーティングシステムの下では、メッシュサービス３１０とアプリケーションインターフェース３０６および３０８との間のプロセス間通信に用いられてもよい４つの異なるプロトコルが存在する。Ａｎｄｒｏｉｄベースのデバイス上では、プロセスが、別のプロセスに配分されたメモリーに直接アクセスし得ず、かつ、プロセス間の通信は、オペレーティングシステムが提供する機能およびプロトコルを用いて実行されなければならない。
【００４４】
例えば、ユーザーがＷｉ−Ｆｉを無効にし、もしくは、Ｂｌｕｅｔｏｏｔｈを有効にし、または、ユーザープリファレンスインターフェース５００上のその他の許可を変更したとき、アプリケーションインターフェース３０６および３０８とメッシュサービス３１０との間で少量のデータを送信するのに、ブロードキャストインテント（Ａｎｄｒｏｉｄプラットフォームに特有）として知られる第１のプロトコルが用いられてもよい。その他のオペレーティングシステムプラットフォームも同様に、機能化プロトコル（例えば、ＬｉｎｕｘオペレーティングシステムについてのＰＯＳＩＸメッセージキュー、スレッドメッセージまたはＷｉｎｄｏｗｓオペレーティングシステムについてのＭｉｃｒｏｓｏｆｔメッセージキューイング）を提供する。
【００４５】
アプリケーションインターフェース３０６および３０８とメッシュサービス３１０との間でデータを交換するための第２の通信プロトコルが、同一のアプリケーションを実行していてもよいその他のデバイスのリストのような、いっそう大きいデータ交換に用いられるメッセンジャー送信/受信機能を通る。送信／受信機能はまた、メッシュサービス３１０によって送信されるコンテンツデータを交換するために、または、メッシュサービスからアプリケーションインターフェース３０６および３０８において受け取られるデータのために用いられてもよい。メッセンジャー送信／受信機能を用いたデータ移送のサイズは概して制限され、かつ、コンテンツデータのいっそう大きい交換は、複数のメッセージを用いて分割および送信される必要がある（すなわち、パケット化）。
【００４６】
第３の通信プロトコルは、データを交換するのに共通のＳＱＬｉｔｅ（ＳＱＬ）データベースまたはファイルを用い、いっそう速いデータ送信を可能にする。なぜなら、データベースまたはファイルが、メモリー２１０中の共通してアクセス可能なロケーションに格納され、かつ、メッシュサービス３１０またはアプリケーションインターフェース３０６もしくは３０８のいずれかによって読み取られてもよいからである。ＳＱＬｉｔｅプロトコルは、いっそう大きいファイルサイズを有するコンテンツデータ（例えば、映像、または、いっそう大きい画像コンテンツデータ）を交換するのに効果的であろう。ＳＱＬまたはファイルを用いてデータを交換することはまた、データの持続的な格納を提供するという利点を有し、このことは、メッシュサービス３１０がシャットダウンされる場合に有利である。上記のメッセンジャー送信／受信プロトコルの下では、メッシュサービス３１０によってまだ送信されていないデータは、サービスが何らかの理由でシャットダウンされる場合には、失われるであろう。
【００４７】
１つの実施形態では、送信／受信プロトコルは、メッシュネットワーク１００を通じた通信速度が、アプリケーションインターフェース３０６および３０８とメッシュサービス３１０との間でデータを移送するためのこのプロトコルの使用が送信ボトルネックを引き起こす程度に十分高くなるまで用いられてもよい。かかる場合、第３の通信プロトコルは、送信ボトルネックを除去するのに用いられてもよい。
【００４８】
例えば、同一のアプリケーションまたは送信すべきファイルのリストを実行していてもよいその他のデバイスのリストのようなデータ交換のためのメッセンジャー送信／受信機
能の代替物として、Ａｎｄｒｏｉｄインターフェース定義言語（ＡＩＤＬ）として知られる第４のプロトコルが用いられてもよい。
【００４９】
図６を参照すると、６００において、第１のアプリケーション３０２が、マイクロプロセッサー２０２に、プロセス４００のブロック４１０においてメッシュサービスを開始させるように指示した後でメッシュサービス３１０によって実行されるプロセスが示されている。プロセスはブロック６０２において始まり、該ブロック６０２は、デバイスのマイクロプロセッサー２０２に、メッシュネットワーク識別子（ｕｕｉｄ）ファイルがメモリー２１０中のｕｕｉｄ格納ロケーション２４８上にあるデバイス上に格納されて存在するか否かを判定するように指示する。いかなるｕｕｉｄファイルも存在しない場合、ブロック６０２はマイクロプロセッサー２０２にブロック６０４へと向かうように指示し、該ブロック６０４はマイクロプロセッサーにデバイスについてのメッシュネットワーク識別子を生成するように指示する。１つの実施形態では、ｕｕｉｄは、結果として生じる識別子が固有である非常に高い可能性を提供する、ブロックチェーン互換性ｕｕｉｄ生成器を用いて生成されてもよい。ブロック６０６はその後、マイクロプロセッサー２０２に、メモリー２１０のｕｕｉｄ格納ロケーション２４８の中にｕｕｉｄファイルを書き込むためのアクセスを与えるようユーザーにリクエストするように指示する。ブロック６０６においてユーザーによる許可が与えられない場合、マイクロプロセッサー２０２はブロック６１２へと向かうように指示され、かつ、セッションは生成されたｕｕｉｄを用いて続く。しかしながら、許可が与えられない場合、デバイスのユーザーによって始められる次のセッションが、現在アクティブであるｕｕｉｄとは異なるｕｕｉｄの生成を再び必要とする。
【００５０】
ブロック６０６においてｕｕｉｄ格納ロケーション２４８にｕｕｉｄを書き込むことについてユーザーによる許可が与えられる場合、マイクロプロセッサー２０２はブロック６０８へと向かうように指示され、かつ、ｕｕｉｄはメモリー２１０に保存される。ユーザーがｕｕｉｄファイルを削除しない限り、格納済みのｕｕｉｄは、たとえアプリケーション３０２および３０４が除去されても、使用のために利用可能なままであろう。ユーザーが続いてメッシュネットワーク１００とともに使用するための新しいアプリケーションをインストールする場合、ｕｕｉｄは使用のために利用可能なままである。１つの実施形態では、ｕｕｉｄは、Ｅｔｈｅｒｅｕｍ互換性暗号化ウォレットとしてｕｕｉｄ格納ロケーション２４８に格納されてもよい。ブロック６０８はその後、マイクロプロセッサー２０２にブロック６１２へと向かうように指示する。
【００５１】
ブロック６１２は、マイクロプロセッサー２０２に、デバイス上で設定された位置許可がＷｉ−Ｆｉ、Ｗｉ−ＦｉダイレクトおよびＢｌｕｅｔｏｏｔｈ無線プロトコルを介したメッシュネットワーク１００へのアクセスを許可するか否かを判定するように指示する。アクセスが許可されない場合、ブロック６１２はマイクロプロセッサー２０２にブロック６１４へと向かうように指示し、かつ、Ｗｉ−Ｆｉ、Ｗｉ−ＦｉダイレクトおよびＢｌｕｅｔｏｏｔｈユーザープリファレンスは、メモリー２１０のユーザープリファレンスロケーション２４６に保存される。図５に戻ると、このことは、ユーザープリファレンスインターフェース５００において、「Ｗｉ−Ｆｉメッシュ」制御５０４を無効に設定し、かつ、「Ｂｌｕｅｔｏｏｔｈメッシュ」制御５０６を無効に設定することに相当する。ブロック６１２においてアクセスが許可される場合、ブロック６１２はマイクロプロセッサー２０２にブロック６１６へと向かうように指示する。
【００５２】
ブロック６１６は、マイクロプロセッサー２０２に、デバイスがＷｉ−Ｆｉ通信設定の変更を許可するオペレーティングシステムバージョンを有する否か、および、ユーザーがデバイス上のこれらの設定の変更を許可したか否かを判定するように指示をする。例えば、Ａｎｄｒｏｉｄバージョン５．ｘ以上は、Ｗｉ−Ｆｉ設定の変更を許可するが、ユーザーがかかる変更を行うことに許可を与えることが必要である。メッシュネットワーク１０
０の確立は、デバイスおよび無線ラジオ２１６の特定の設定の操作を必要とするので、これらの設定へのアクセスが無効であるときには、デバイスは、Ｂｌｕｅｔｏｏｔｈを介したメッシュネットワークとの接続のみに制限されてもよい。ブロック６１６においてＷｉ−Ｆｉ設定の変更が許可されない場合、プロセスはブロック６１８において続き、該ブロック６１８では、マイクロプロセッサー２０２は、無線ラジオ２１６を介したＷｉ−ＦｉおよびＷｉ−Ｆｉダイレクト通信を無効にするように指示される。このことは、図５に示されているユーザープリファレンスインターフェース５００において、「Ｗｉ−Ｆｉメッシュ」制御５０４を無効に設定することに相当する。
【００５３】
ブロック６１６においてＷｉ−Ｆｉ設定の変更が許可される場合、プロセスはブロック６２０において続き、該ブロック６２０は、マイクロプロセッサー２０２に、無線ラジオ２１６を介してアプリケーションインターフェース３０６もしくは３０８（図３）のいずれかから、または、メッシュネットワーク１００からイベントが受け取られたか否かを判定するように指示する。いかなるイベントも受け取られない場合、マイクロプロセッサー２０２はブロック６２０を繰り返すように指示される。イベントが受け取られる場合、ブロック６２０はマイクロプロセッサー２０２に図１０のブロック１００２へと向かうように指示する。
【００５４】
図３に示されているデバイス構成の１つの利点は、特定のアプリケーションに関連付けられたデータトラフィックの分離を許可するために特定のアプリケーションに関連付けられたデータフローをさらに固有に識別することによって提供される（例えば、図３に示されているデバイス３００についての機能的ブロック図における第１のアプリケーション３０２および第２のアプリケーション３０４）。図３に示されているデバイス３００は、図７ではメッシュネットワーク１００を通じてその他のデバイスと通信している状態で示されている。図７を参照すると、デバイス３００はデバイス７００と無線通信しており、該デバイス７００はデバイス７０２と通信している。デバイス３００は、第１のアプリケーション３０２と第２のアプリケーション３０４の両方を実行しているが、デバイス７０２は、第２のアプリケーションのインスタンス７１０を実行しているのみである。デバイス７００は、メッシュネットワーク１００を通じてネットワーク化されたデバイスによってプレーされるゲームに関する第３のアプリケーション７０４を実行している。図７では、デバイス３００および７００は、無線通信範囲７１６内にあり、デバイス７００および７０２は無線通信範囲７１８内にある。しかしながら、図示されている実施形態では、デバイス３００および７０２は無線通信範囲外にある。無線通信範囲７１６および７１８はしたがって、メッシュネットワーク１００（この例では、３つのデバイスを有する）を定める。
【００５５】
図７に示されている実施形態では、デバイス３００のメッシュサービス３１０およびデバイス７０２上で実行されているメッシュサービス７１４はしたがって、メッシュサービス７１４を介して第２のアプリケーション３０４および７１０の間の送信を意図したデータを通信しなければならない。この実施形態では、各データフローは、データ送信がどの特定のアプリケーションに関連付けられるかを識別するための手段を提供する識別子に関連付けられる。本開示では、識別子のことを「メッシュポート」といい、かつ、第１のアプリケーションにはメッシュポート６０００が割り当てられ、第２のアプリケーションにはメッシュポート５０００が割り当てられ、かつ、第３のアプリケーションにはメッシュポート７０００が割り当てられる。割り当て済みのメッシュポートは、デバイス３００上で実行されている第２のアプリケーション３０４のインスタンスに関連付けられたデータフローがデバイス７０２上で実行されている第２のアプリケーション７１０のインスタンスにのみ転送されることを可能にする。メッシュポート５０００を有するデータを受け取るデバイス７００上で実行されているメッシュサービス７０８は、まだデバイス７０２へとデータを転送するが、デバイス７００上で実行されている第３のアプリケーション７０
０へはデータを転送しない。デバイス７００はしたがって、メッシュネットワーク１００に参加するが、第３のアプリケーション７０４は、第３のアプリケーション７０４のインスタンスを実行している別のデバイスがメッシュネットワーク１００に参加するか、または、デバイス３００もしくは７０２のうちの１つが第３のアプリケーションのインスタンスを開始させるかのいずれかの場合以外は、いかなるデータも受け取らないであろう。このことは、メッシュネットワーク１００を通じて第１、第２および第３のアプリケーションに関連するデータを提供するのみであるという利点を有する。さらに、第３のアプリケーション７０４がメッシュポート５０００または６０００のうちの１つの上で待機することを試みる場合、デバイス７００上で実行されているメッシュサービス７０８は、かかるアクセスを禁止するであろう。
【００５６】
図８中の８００には概して、プロセス４００のブロック４０６において受け取られたハンドリングイベントにおいてプロセッサー回路２００によって実行されるアプリケーションイベントハンドリングプロセスが示されている。アプリケーションイベントハンドリングプロセス８００については、デバイス３００を参照して記載されるが、同一のプロセスは、デバイス７００および７０２のそれぞれの上でも実行される。アプリケーションイベントハンドリングプロセス８００は、デバイス３００のアプリケーションインターフェース３０６および３０８を、イベントをハンドリングするための機能を提供するように設定する。種々のイベントは、メッシュサービス３１０、または、第１もしくは第２アプリケーション３０２および３０４のいずれかから、アプリケーションインターフェース３０６および３０８によって受け取られてもよい。図８Ａを参照すると、アプリケーションイベントハンドリングプロセス８００はブロック８０２において始まり、該ブロック８０２は、マイクロプロセッサー２０２に、ユーザーが、デバイスが作動するモードに関連付けられたユーザープリファレンスロケーション２４６に格納されたユーザープリファレンスを変更したか否かを判定するように指示する。図５に戻ると、ユーザープリファレンスインターフェース５００は、ユーザーがメッシュワーク１００中のデバイスについてのネットワークロールを選択することを許可する複数のボタン制御５０８を含む。ユーザーは、マスターモードで作動させること（すなわち、Ｗｉ−Ｆｉアクセスポイントとして）、クライアントモードで作動させること、ルーティングモードで作動させること、または、自動モードで作動させることの間で選択してもよい。ブロック８０２においてマイクロプロセッサー２０２によってネットワークロールの変更が検出される場合、マイクロプロセッサーはブロック８０４へと向かうように指示される。ブロック８０４は、マイクロプロセッサー２０２に、メッシュネットワーク１００におけるネットワークロールについての変更済みのユーザープリファレンスをメモリー２１０中のユーザープリファレンスロケーション２４６に保存するように指示する。ブロック８０４はまた、マイクロプロセッサー２０２に、ブロードキャストインテントプロトコルを介してメッシュサービス３１０へとネットワークロールの変更を通信するように指示する。プロセスはその後、プロセス４００のブロック４０６へと戻り、該ブロック４０６では、マイクロプロセッサー２０２が次のイベントを待つように指示される。
【００５７】
ブロック８０２においていかなるネットワークロールの変更も検出されない場合、プロセスはブロック８０６において続き、該ブロック８０６は、マイクロプロセッサー２０２に、ユーザーがメッシュサービス３１０を無効としたか否かを判定するように指示する。ブロック８０６においてメッシュサービス３１０がユーザーによって無効とされた場合、マイクロプロセッサー２０２はブロック８０４へと戻るように指示され、該ブロック８０４では、ユーザープリファレンスロケーション２４６に格納されたユーザープリファレンスがアップデートされ、かつ、メッシュサービス３１０がブロードキャストインテントプロトコルメッセージを介して変更について通知される。プロセスはその後、プロセス４００のブロック４０６へと戻り、該ブロック４０６では、マイクロプロセッサー２０２が次のイベントを待つように指示される。
【００５８】
ブロック８０６においてメッシュサービス３１０が無効とされない場合、プロセスはブロック８０８において続き、該ブロック８０８は、マイクロプロセッサー２０２に、アプリケーションがメッシュポートのバインディングまたはアンバインディングをリクエストしたか否かを判定するように指示する。上記で注目されたように、第１のアプリケーション３０２は、メッシュポート６０００上での通信のために構成され、第２のアプリケーション３０４は、メッシュポート５０００上での通信のために構成される。例えば、第１のアプリケーション３０２がメッシュポート６０００へのバインディングをリクエストする場合、ブロック８０８はマイクロプロセッサー２０２にブロック８１０へと向かうように指示する。ブロック８１０はその後、マイクロプロセッサー２０２に、メッシュサービス３１０によって提供されるメッシュポートバインディングＡＰＩ機能を呼び出して、メッシュポート６０００上でバインディングをリクエストするように指示する。
【００５９】
アプリケーション３０２、３０４および７０４のようなアプリケーションは、種々の異なるアプリケーションデベロッパーによって生成され、かつ、メッシュネットワーク１００のユーザーに利用可能とされてもよい。１つの実施形態では、各アプリケーションデベロッパーは、メッシュネットワーク１００上での使用のためにアプリケーションを提供することが許可される前に、登録プロセスを経験することが必要とされる。登録するとき、この実施形態におけるアプリケーションデベロッパーはデベロッパーキーシグネチャーを発行され、該デベロッパーキーシグネチャーはその後でアプリケーションについてのプログラムコードに埋め込まれる。この実施形態では、ブロック８１０はさらに、マイクロプロセッサー２０２に、メモリー２１０のアプリケーション格納ロケーション２４４におけるアプリケーションについてのプログラムコードにおけるデベロッパーキーシグネチャーを読み取り、かつ、メッシュサービス３１０によって提供されるメッシュポートバインディングＡＰＩ機能への呼び出しにデベロッパーキーシグネチャーを含むように指示する。３１０によるメッシュポートバインディングＡＰＩ機能への呼び出しの処理は、図１０Ｂ中のブロック１０３４〜１０４０を参照して本明細書中で以下に説明される。
【００６０】
アプリケーションイベントハンドリングプロセス８００はその後ブロック８１２において続き、該ブロック８１２は、マイクロプロセッサー２０２に、アプリケーションがメッシュネットワーク１００を通じたデータの安全な送信のために暗号キー交換をリクエストしたか否か判定するように指示する。ブロック８１２において暗号キー交換がリクエストされた場合、マイクロプロセッサーはブロック８１４へと向かうように指示され、該ブロック８１４では、暗号キー交換を開始するメッシュサービスＡＰＩ機能への呼び出しが行われる。メッシュサービス３１０は、暗号キーを交換するために呼び出されたＡＰＩ機能を実施し、該ＡＰＩ機能は、呼び出されたときに、特定されたｕｕｉｄを有する標的デバイスへとその暗号キーを送信する。デバイスが暗号キーを受け取るとき、それはローカル暗号キー格納ロケーション２５２に格納され、かつ、キー交換を開始したデバイスへと戻るようにそれ自体の暗号キーを送信することによって応答する。開始デバイスによって受け取られるとき、暗号キーは、ローカル暗号キー格納ロケーション２５２に格納される。
【００６１】
ブロック８１２において暗号キー交換がリクエストされなかった場合、アプリケーションイベントハンドリングプロセス８００はブロック８１６において続き、該ブロック８１６は、マイクロプロセッサー２０２に、関連アプリケーションがメッシュネットワーク１００を通じてデータをメッシュサービス３１０へと送信することを希望するか否かを判定するように指示する。例として、チャットアプリケーション３０２について、データは、テキストおよび／または音声コンテンツ、画像もしくは映像コンテンツを含む、チャットメッセージであってもよい。メッシュアプリケーション３０２および３０４からメッシュサービス３１０へのコンテンツデータの送信は、アプリケーションインターフェース３０６および３０８によって管理される。ブロック８１６は、マイクロプロセッサー２０２に
、メッシュサービス３１０へとコンテンツデータを移送するためのメッシュサービス機能を呼び出すように指示する。メッシュサービスへの呼び出しは、呼び出し中にｕｕｉｄを含むことによって、データの意図された行先（図７におけるデバイス７００または７０２のうちの１つ以上）を識別する。
【００６２】
上記で注目されたように、画像またはチャットメッセージのようないっそう小さいサイズのコンテンツデータについては、メッセンジャー送信／受信機能は、メッシュサービス３１０への送信に用いられてもよい。ブロック８１８は、マイクロプロセッサー２０２に、メッセンジャー送信／受信機能を介してメッシュサービス３１０へと送達するためにデータを複数のデータチャンクに分割するように指示する。図９中の９００において、デバイス３００上の第２のアプリケーション３０４からのコンテンツデータ送信の例が概略的に示されている。図９を参照すると、５Ｍバイトの画像９０２が９０４において示されているｎ個のチャンクに分割されて示されている。１つの実施形態では、アプリケーションインターフェース３０６および３０８は、データチャンクについての最大データサイズを定める、データチャンクサイズ制限最大＿チャンクを実施してもよい。
【００６３】
図８に戻ると、この実施形態では、ブロック８１８はまた、マイクロプロセッサー２０２に、「チャンク１」の第１のフィールドとして画像９０２のデータ全長を書き込むように指示する。第１の「チャンク１」はしたがって、メッシュサービス３１０に移送のデータ長を通知するのに役立ち、かつ、残りのデータチャンク２〜ｎはデータを含むのみであろう。ブロック８１８はその後、マイクロプロセッサー２０２に、メッセンジャー送信／受信機能を用いてチャンク１をメッシュサービス３１０へと送信するように指示する。
【００６４】
ブロック８２０はその後、マイクロプロセッサー２０２に、メッシュサービス３１０が次のチャンクを受け取る準備ができているか否かを判定するように指示する。コンテンツデータを送信するようにとのアプリケーション３０２または３０４からの呼び出しが受け取られるとき、メッシュサービス３１０は、データフローについてアプリケーションバッファー３２０（図９に示されている）を配分する。アプリケーションバッファー３２０は、メモリー２１０中のメッシュサービスアプリケーションバッファーロケーション２５６において保持される。以下、本明細書においていっそう詳細に記載されるように、チャンク１を受け取る際、メッシュサービス３１０は、メッシュネットワーク１００を介したさらなるデータの送信のために、適用可能なアプリケーションバッファー３２０中に残された余地が存在するか否かを判定し、かつ、適用可能なアプリケーションインターフェース３０６または３０８に適宜知らせる。ブロック８２０においてメッシュサービス３１０がまだいっそう多くのデータを受け取る準備ができていない場合、ブロック８２０はマイクロプロセッサー２０２にブロック８２０を繰り返すように指示する。
【００６５】
ブロック８２０においてメッシュサービス３１０がいっそう多くのデータを受け取る準備ができている場合、プロセスはブロック８２２において続き、かつ、次のチャンク（この場合、チャンク２）が送信される。ブロック８２４はその後、マイクロプロセッサー２０２に、さらなるチャンクが送信されるべきままである（この場合、マイクロプロセッサーはブロック８２０へと戻るように指示される）か否かを判定するように指示する。ブロック８２４においてさらなるチャンクが送信されるべきままでない場合、マイクロプロセッサーは４０６へと戻って次のイベントを待つように指示される。
【００６６】
ブロック８１６においてメッシュネットワーク１００を通じてデータを送信するようにとのアプリケーションからのいかなるリクエストも存在しない場合、プロセスは図８Ｂにおけるブロック８２６において続く。図８を参照すると、ブロック８２６はその後、マイクロプロセッサー２０２に、メッシュサービス３１０がピア変更（ｐｅｅｒＣｈａｎｇｅｄ）イベントを発行したか否かを判定するように指示する。ピア変更イベントは、メッシ
ュサービス３１０が、メッシュネットワーク１００上のデバイス１０２〜１１２のうちの１つのステータスが変わったことを検出するときはいつでも生成される。
【００６７】
ブロック８２６においていかなるピア変更イベントも受け取られない場合、アプリケーションイベントハンドリングプロセス８００はブロック８２８において続き、該ブロック８２８では、マイクロプロセッサー２０２は、メッシュサービス３１０がデバイス上で実行されているアプリケーションのうちの１つに関連付けられたデータ受信（ｄａｔａＲｅｃｅｉｖｅｄ）イベントを発行したか否かを判定するように指示される。例えば、メッシュポート６０００に関連付けられたデータがメッシュネットワーク１００を通じて受け取られるとき、メッシュサービス３１０によってアプリケーションインターフェース３０６へとデータ受信イベントが送信される。
【００６８】
ブロック８２６においてピア変更イベントが受け取られるか、または、ブロック８２８においてデータ受信イベントが受け取られるかのいずれかの場合、プロセスはブロック８３０において続き、該ブロック８３０は、マイクロプロセッサー２０２がイベントを処理することを引き起こす。各アプリケーションは概して、メモリー２１０の格納ロケーション２４４に格納されたアプリケーションについてのコードによって定められた設定済みの挙動にしたがって、データおよびその他のイベントを処理ならびに表示するであろう。例えば、チャットアプリケーション３０２が、デバイス１０２〜１１２のうちの１つのユーザーがチャットアプリケーションを停止させたことを示すピア変更通知を受け取る場合、デバイス３００上のディスプレイが、アップデートされてかかるユーザーに関連付けられたリストを除去してもよく、代替的には、ユーザーにアクティブでないことを示してもよい。コンテンツデータが受け取られる場合、デバイス３００のディスプレイは、アップデートされて、メッシュネットワーク１００の別のユーザーによって送信されるチャットメッセージまたはその他のコンテンツを表示してもよい。ブロック８３０はその後、マイクロプロセッサー２０２にプロセス４００のブロック４０６へと戻って次のイベントを待つように指示する。
【００６９】
ブロック８２８においてデータ受信イベントが受け取られない場合、プロセスはブロック８３２において続く。上記で注目されたように、アプリケーションデベロッパーは、メッシュネットワーク１００上での使用のためにアプリケーションを提供することを許可される前に登録プロセスを経験することを必要とされてもよい。１つの実施形態では、追加の機能が登録済みのアプリケーションデベロッパーへと陳列されて、試験および性能評価のためにプログラム的にデバイスのネットワークロールの設定を可能にしてもよい。必要な機能は、メモリー２１０のアプリケーション格納ロケーション２４４における格納についてのコードのデベロッパーバージョンを通して提供されてもよい。１つの実施形態では、デベロッパーコードは、デバイスがライブメッシュネットワーク１００に参加することを制限してもよい。なぜなら、そのときは、アプリケーションが、ネットワークを確立するためのそれ自体のリソースのいずれも共有することなくメッシュネットワークに参加するようにプログラムされ得るからである。メッシュネットワーク１００の成功裡の確立は、デバイスがメッシュネットワークに参加することに依拠し、無線通信範囲内にないその他のデバイス間のメッセージの送信を可能にする。
【００７０】
ブロック８３２はしたがって、有効なデベロッパーキーシグネチャーを有する登録済みのアプリケーションデベロッパーに提供されるコードのバージョンを実行しているデバイス上でアクセス可能であるのみである（上記のように）。ブロック８３２は、マイクロプロセッサー２０２に、関連アプリケーションがメッシュネットワーク１００についての状態情報をリクエストしたか否かを判定するように指示する。かかる状態情報は、デバイスおよびネットワークロール（ルーティングモード、クライアントモード、アクセスポイントモードなど）のリスト、特定のデバイスに関する接続情報、ならびに、その他の性能評
価メトリックを含んでもよい。ブロック８３２において状態情報がリクエストされた場合、ブロック８３４は、マイクロプロセッサー２０２に、メッシュサービス３１０から状態情報データをリクエストするように指示する。状態情報データは、上記のタイプの情報のうちのいずれか、または、すべてを含む構造化されたデータメッセージの形式で提供されてもよい。ブロック８３４はその後、マイクロプロセッサー２０２にプロセス４００のブロック４０６へと戻って次のイベントを待つように指示する。
【００７１】
ブロック８３２において状態情報についてのいかなるリクエストも受け取られない場合、プロセスはブロック８３６において続き、該ブロック８３６もまた、有効なデベロッパーキーシグネチャーを有する登録済みのアプリケーションデベロッパーに提供されるコードのバージョンを実行しているデバイス上でアクセス可能であるのみである。ブロック８３６は、マイクロプロセッサー２０２に、関連アプリケーションが特定のメッシュネットワーク通信パラメーターを設定するためのアクセスをリクエストしたか否かを判定するように指示する。例えば、アプリケーションは、試験ネットワークを確立することに伴う多数のデバイスについてのネットワークロール、無線ＳＳＩＤまたはＢｌｕｅｔｏｏｔｈ識別子をプログラム的に操作することを希望してもよい。ブロック８３６においてアプリケーションによってかかるリクエストが行われた場合、ブロック８３８は、マイクロプロセッサー２０２に、かかる機能を提供するサービス機能への呼び出しを送信するように指示する。ブロック８３８はその後、マイクロプロセッサー２０２にプロセス４００のブロック４０６へと戻って次のイベントを待つように指示する。
【００７２】
ブロック８３６において特定のメッシュネットワーク通信パラメーターを設定するためのいかなるリクエストも受け取られない場合、プロセスはブロック８４０において続く。ブロック８４０は、マイクロプロセッサー２０２に、アプリケーションのユーザーが図５に示されているユーザープリファレンスインターフェース５００の表示をリクエストした（この場合、マイクロプロセッサーはブロック８４２へと向かうように指示される）か否かを判定するように指示する。ブロック８４２は、マイクロプロセッサー２０２に、ユーザープリファレンスインターフェース５００が表示されて例えばメッシュネットワーク１００上のデバイスのネットワークロールの変更のようなユーザー入力を受け取ることを引き起こすように指示する。ブロック８４４はその後、マイクロプロセッサー２０２に、ユーザーがユーザープリファレンスのいずれかを変更した（この場合、プロセスはブロック８４６において続く）か否かを判定するように指示する。ブロック８４６は、マイクロプロセッサー２０２に、ブロードキャストインテントプロトコルを用いてメッシュサービス３１０にユーザープリファレンスインターフェース５００において受け取られた変更済みのユーザープリファレンスを通知するように指示する。ブロック８４６はその後、マイクロプロセッサー２０２にプロセス４００のブロック４０６へと戻って次のイベントを待つように指示する。
【００７３】
ブロック８４４においていかなるユーザープリファレンスも受け取られない場合、マイクロプロセッサー２０２は、ユーザープリファレンスインターフェース５００を閉じるように指示され、かつ、その後、プロセス４００のブロック４０６へと戻って次のイベントを待つように指示される。ブロック８４０においてユーザープリファレンスインターフェース５００の表示がリクエストされなかった場合、ブロック８４０はマイクロプロセッサー２０２にプロセス４００のブロック４０６へと戻って次のイベントを待つように指示する。
【００７４】
アプリケーションイベントハンドリングプロセス８００はしたがって、デバイス１０２〜１１２の各々のマイクロプロセッサーに、アプリケーションインターフェース３０６、３０８、７００および７１２について必要な機能を実施して、各々のアプリケーションならびに各デバイス上で実行されているメッシュサービス３１０、７０８および７１４から
生じるイベント、ならびに、メッシュポート識別に基づいてアプリケーションインターフェースへと転送されるその他のデバイスにおいて生じるイベントをハンドリングするように指示する。
【００７５】
図１０中の１０００において、プロセッサー回路２００によって実行されて、メッシュサービス３１０（ならびにメッシュサービス７０８および７１４）についてのメッシュサービス機能を実施して図６に示されているプロセス６００のブロック６２０において受け取られるイベントをハンドリングするためのメッシュサービスプロセスが示されている。図１０Ａを参照すると、メッシュサービスプロセス１０００はブロック１００２において始まり、該ブロック１００２は、マイクロプロセッサー２０２に、メッシュネットワーク１００を通じて別のデバイスからピア変更イベントが受け取られたか否かを判定するように指示する。ブロック１００２においてピア変更イベントが受け取られた場合、プロセスはブロック１００４において続き、該ブロック１００４は、マイクロプロセッサー２０２に、ピア変更イベントに関連付けられるメッシュポートを判定し、かつ、対応メッシュポートを有するアプリケーションがピア変更イベントについて通知されることを引き起こすように指示する。例えば、メッシュサービス３１０においてデバイス７０２からピア変更イベントが受け取られる場合、メッシュポート識別子は５０００であり、かつ、ピア変更イベントは第２のアプリケーション３０４のアプリケーションインターフェース３０８へと送信されるであろう。上記で開示されたように、アプリケーションインターフェース３０８は、図８に示されているアプリケーションイベントハンドリングプロセス８００のブロック８２６にしたがってピア変更イベントを処理する。ブロック１００４はその後、マイクロプロセッサー２０２にプロセス６００のブロック６２０へと戻ってさらなるイベントを待つように指示する。
【００７６】
ブロック１００２においていかなるピア変更イベントも受け取られない場合、マイクロプロセッサー２０２はブロック１００６へと向かうように指示され、かつ、メッシュネットワーク１００を通じて別のデバイスからコンテンツデータが受け取られたか否かを判定するように指示される。ブロック１００６においてコンテンツデータが受け取られた場合、マイクロプロセッサー２０２はブロック１００８へと向かうように指示され、該ブロック１００８は、マイクロプロセッサーに、コンテンツデータに関連付けられるメッシュポートを判定するように指示する。ブロック１０１０はその後、マイクロプロセッサー２０２に、判定済みのメッシュポートに対応するアプリケーションがデバイス上で実行されている（この場合、プロセスはブロック１０１２において続く）か否かを判定するように指示する。ブロック１０１２は、マイクロプロセッサー２０２に、上記で開示されたプロセス間通信プロトコルのうちの１つを用いて、メッシュネットワーク１００を通じてデータを受け取り、かつ、適用可能なアプリケーションへとデータを送達するように指示する。１つの実施形態では、データは、メモリー２１０のアプリケーションバッファーロケーション２５４においてデータバッファーを受け取るように書き込まれてもよい。受信データバッファーは、適用可能なアプリケーションインターフェース３０６または３０８によって管理される。ブロック１０１２はまた、マイクロプロセッサー２０２に、メッシュネットワーク１００を通じたデータ移送が完了するまで待機し、かつ、その後、送信が完了したことを適用可能なアプリケーションに通知するように指示する。適用可能なアプリケーションはその後、アプリケーションバッファーロケーション２５４の受信データバッファーにおいてデータを処理し得る。その他の実施形態では、受信データバッファーが送信の完了前にデータ移送によって満たされる場合、ブロック１０１２はまた、マイクロプロセッサー２０２に、まだ受け取られるべきさらなる量のデータについて適用可能なアプリケーションに通知するように指示してもよい。大きいデータ移送はしたがって、アプリケーション受信データバッファーを圧倒することが防止される。ブロック１００６、１００８、１０１０および１０１２はしたがって、マイクロプロセッサー２０２に、メッシュポートに対応するアプリケーションについてのアプリケーションインターフェースへとデータ
を送達するように指示する。例えば、デバイス７０２上で実行されている第２のアプリケーション７１０からコンテンツデータが受け取られる場合、メッシュポートは５０００であり、かつ、データコンテンツは、第２のアプリケーション３０４に関連付けられるアプリケーションインターフェース３０８へと送達されるであろう。ブロック１０１２はその後、マイクロプロセッサー２０２にプロセス６００のブロック６２０へと戻ってさらなるイベントを待つように指示する。
【００７７】
ブロック１０１０において判定済みのメッシュポートに対応するアプリケーションがデバイス上で実行されていない場合、マイクロプロセッサー２０２はブロック１０１４へと向かうように指示され、該ブロック１０１４では、マイクロプロセッサーは、以下で本明細書に記載されるルーティングプロトコルにしたがってメッシュネットワーク１００を通じてコンテンツを転送するように指示される。ブロック１０１４はその後、マイクロプロセッサー２０２にプロセス６００のブロック６２０へと戻ってさらなるイベントを待つように指示する。
【００７８】
ブロック１００６においていかなるコンテンツデータも受け取られない場合、メッシュサービスプロセス１０００はブロック１０１６において続き、該ブロック１０１６は、マイクロプロセッサー２０２に、別のデバイスからメッシュネットワーク１００を通じて暗号キー交換リクエストが受け取られたか否かを判定するように指示する。暗号キー交換リクエストが受け取られた場合、ブロック１０１６はマイクロプロセッサー２０２にブロック１０１８へと向かうように指示する。暗号キーリクエストは、リクエストデバイスの公開キーを含んでいてもよく、この場合、ブロック１０１８は、マイクロプロセッサー２０２に、メモリー２１０中の暗号キー格納ロケーション２５２に公開暗号キーを追加するように指示する。ブロック８１８はまた、マイクロプロセッサー２０２に、暗号キー交換リクエストを発行したデバイスへとメッシュネットワーク１００を通じてデバイス公開暗号キーを送信するように指示する。最後に、ブロック８１８は、マイクロプロセッサー２０２に、デバイスが暗号化された通信をリクエストしたことを適用可能なアプリケーション３０２または３０４に通知するように指示する。暗号化された通信は、暗号キー交換が開始デバイスとメッシュネットワーク１００上の標的デバイスとの間でブロック８１２においてアプリケーションによってリクエストされたことに依拠する。一旦キー交換が完了し、かつ、キーがローカル暗号キー格納ロケーション２５２に格納されると、キーは、アプリケーション間を共通のメッシュポートを有する標的デバイス上のアプリケーションへと送信されるデータを暗号化するのに用いられてもよい。データは、そうでなければ、送信されるデータが、データが暗号化されたことを示すように設定されたバイト値を有すること（図１２には、データパケット１３００の暗号化（ｉｓＥｎｃｒｙｐｔｅｄ）フィールド１３２６が示されている）を除いて、以下で本明細書に記載されるように送信されてもよい。受信側では、標的デバイスは暗号化フィールド１３２６を読み取り、かつ、そのローカル暗号キー格納ロケーション２５２において関連暗号キーを探す。暗号キーは、見出される場合には、データを復号するのに用いられる。
【００７９】
ブロック１０１６において暗号キー交換リクエストが受け取られなかった場合、メッシュサービスプロセス１０００はブロック１０２０において続き、該ブロック１０２０は、マイクロプロセッサー２０２に、アプリケーション３０２または３０４のうちの１つが図５に示されているユーザープリファレンスインターフェース５００上のネットワークロールセレクターボタン制御５０８を介してデバイス３００についてのネットワークロールを変更したか否かを判定するように指示する。ブロック１０２０においてネットワークロールのいかなる変更も受け取られなかった場合、プロセスはブロック１０２２において続き、該ブロック１０２２は、マイクロプロセッサー２０２に、アプリケーション３０２または３０４のうちの１つがをユーザープリファレンスインターフェース５００上で「Ｗｉ−Ｆｉメッシュ」制御５０４もしくは「Ｂｌｕｅｔｏｏｔｈメッシュ」制御５０６を介して
Ｗｉ−ＦｉもしくはＢｌｕｅｔｏｏｔｈ通信を無効にしたか、または、有効にしたかを判定するように指示する。
【００８０】
ブロック１０２０および１０２２についてネットワークロールまたは通信設定のいずれの変更も存在しなかった場合、プロセスはブロック１０２４において続き、該ブロック１０２４は、マイクロプロセッサーに、適用可能なメッシュ通信設定をアップデートするように指示する。メッシュ通信設定は、メッシュサービス３１０がメッシュネットワーク１００とどのように相互作用するかを判定する（例えば、図２に示されている無線ラジオ２１６のＷｉ−ＦｉもしくはＢｌｕｅｔｏｏｔｈ性能のいずれかを有効または無効にする）。デバイス３００のユーザーはしたがって、ネットワークロールおよび無線ラジオ２１６の使用を選択する能力を有する。例えばデバイス３００のバッテリー残量が少ない場合、ユーザーは、まだＢｌｕｅｔｏｏｔｈ通信が進行することを許可しながら、Ｗｉ−Ｆｉ通信を無効にしてバッテリーパワーを節約してもよい。ブロック１０２４はその後、マイクロプロセッサー２０２にプロセス６００のブロック６２０へと戻ってさらなるイベントを待つように指示する。
【００８１】
ブロック１０２２において通信設定のいかなる変更も存在しない場合、プロセスはブロック１０２６において続く。ブロック１０２６は、マイクロプロセッサー２０２に、アプリケーションが図５におけるユーザープリファレンス５００上の「メッシュサービス」制御５０２を介してメッシュサービス３１０を無効にしたか否かを判定するように指示する。メッシュサービス３１０が無効にされた場合、ブロック１０２６はマイクロプロセッサー２０２にブロック１０２８へと向かうように指示し、該ブロック１０２８は、マイクロプロセッサーに、メッシュネットワーク１００を通じて「除去済」の状態を有するピア変更通知を生成および送信するように指示し、メッシュネットワーク１００上のその他のデバイスが、デバイス３００がネットワーク上でもはや利用可能ではないことをアップデートされ得るようにする。ブロック１０２８はさらに、マイクロプロセッサー２０２に、すべてのバインディングされたメッシュポート（すなわち、ポート５０００および６０００）を解放し、かつ、メッシュサービス３１０をシャットダウンするように指示する。一旦メッシュサービスがシャットダウンされると、デバイス３００は、もはやメッシュネットワーク１００に参加し得ない。１つの実施形態では、アプリケーション３０２および３０４は、ユーザーがメッシュサービス３１０を再び有効にすることを判定する場合に、実行されたままであってもよい。代替的には、アプリケーション３０２および３０４は、メッシュサービス３１０と同時にシャットダウンされてもよい。ブロック１０２６においてメッシュサービス３１０が無効にされなかった場合、メッシュサービスプロセス１０００は、図１０Ｂ上のブロック１０３０において続く。
【００８２】
図１０Ｂを参照すると、ブロック１０３０は、上記のようにコードのデベロッパーバージョンに実施されるのみであり、かつ、マイクロプロセッサー２０２に、アプリケーション３０２または３０４のうちのいずれかが状態情報をリクエストしたか否かを判定するように指示する。状態情報のリクエストは、アプリケーションイベントハンドリングプロセス８００のブロック８３２に関して先行して記載された。ブロック１０３０においてアプリケーションインターフェース３０６および３０８のうちのいずれかによって状態情報のリクエストが発行された場合、プロセスはブロック１０３２において続き、該ブロック１０３２は、マイクロプロセッサー２０２に、アプリケーションインターフェースへとリクエスト済みの状態情報を定める構造化されたデータを送信するように指示する。ブロック１０３２はその後、マイクロプロセッサー２０２にプロセス６００のブロック６２０へと戻ってさらなるイベントを待つように指示する。
【００８３】
ブロック１０３０において状態情報のいかなるリクエストも受け取られなかった場合、プロセスはブロック１０３４において続き、該ブロック１０３４は、マイクロプロセッサ
ー２０２に、アプリケーションインターフェース３０６および３０８のうちの１つからメッシュポートをバインディングするようにとのリクエストが受け取られたか否かを判定するように指示する。メッシュポートをバインディングするようにとのリクエストが受け取られた場合、プロセスはブロック１０３６において続き、該ブロック１０３６は、マイクロプロセッサー２０２に、アプリケーションインターフェース３０６または３０８によって提供されるデベロッパーキーシグネチャーがバインディングリクエストにおいて特定のメッシュポートにバインディングするために認証されるか否かを判定するように指示する。メッシュサービス３１０は、デベロッパーキーシグネチャーに対応するキーシグネチャーデータとともに種々のアプリケーションに割り当てられたメッシュポートのテーブルを維持する。テーブルは、メモリー２１０のメッシュポートテーブルロケーション２５０に維持される。ブロック１０３６においてデベロッパーキーシグネチャーが認証される場合、メッシュポートバインディングをリクエストするアプリケーションは、リクエスト済みのメッシュポートへとバインディングすることが許可され、かつ、メッシュポートテーブルはアップデートされて、特定のメッシュポートの成功裡のバインディングを反映する。例として、メッシュポート６０００が割り当てられたアプリケーション３０２は、メッシュサービス３１０が、デベロッパーキーシグネチャーがこの特定のポート（６０００）へとバインディングすることを許可されることを示す、対応キーシグネチャーを有する場合に、このメッシュポートへとバインディングすることを許可されるのみである。アプリケーション３０２は、たとえデバイス３００がアプリケーション３０４をメッシュポート５０００へと成功裡にバインディングし得るとしても、メッシュポート５０００へとバインディングすることを許可されない。このことは、トラフィックを分離し、かつ、アプリケーションがその他のアプリケーションのために意図されたデータトラフィック上で悪意で待機することを防止するという利点を有する。ブロック１０３８はまた、マイクロプロセッサー２０２に、メッシュポートバインディングリクエストを始めたアプリケーションインターフェースへと通知を送信するように指示し、かつ、その後、マイクロプロセッサーにプロセス６００のブロック６２０へと戻ってさらなるイベントを待つように指示する。
【００８４】
ブロック１０３６においてデベロッパーキーシグネチャーが認証されない場合、ブロック１０４０は、マイクロプロセッサーに、メッシュポートバインディングリクエストを始めたアプリケーションインターフェースへとこの旨の通知を送信するように指示し、かつ、その後、マイクロプロセッサーにプロセス６００のブロック６２０へと戻ってさらなるイベントを待つように指示する。
【００８５】
ブロック１０３４においてメッシュポートをバインディングするようにとのリクエストが受け取られなかった場合、ブロック１０４２は、マイクロプロセッサー２０２に、メッシュポートをアンバインディングするようにとのリクエストが受け取られたか否かを判定するように指示する。メッシュポートをアンバインディングするようにとのリクエストが受け取られた場合、ブロック１０４２は、マイクロプロセッサー２０２に、バインディングされたメッシュポートを解放し、かつ、メモリー２１０のメッシュポートテーブルロケーション２５０に格納されたメッシュポートテーブルをアップデートするように指示する。ブロック１０４４はその後、マイクロプロセッサー２０２にプロセス６００のブロック６２０へと戻ってさらなるイベントを待つように指示する。
【００８６】
ブロック１０４２においてメッシュポートをアンバインディングするようにとのリクエストが受け取られなかった場合、メッシュサービスプロセス１０００はブロック１０４６において続く。ブロック１０４６は、マイクロプロセッサー２０２に、コンテンツデータチャンクが、各々のアプリケーション３０２および３０４のアプリケーションインターフェース３０６および３０８のうちの１つからのメッシュサービス３１０による送信のために受け取られたか否かを判定するように指示する。コンテンツデータチャンクが受け取られた場合、ブロック１０４６は、マイクロプロセッサー２０２に、アプリケーションとｕ
ｕｉｄによって識別される行先との間のデータフローについてメッシュサービスアプリケーションデータバッファーロケーション２５６におけるアプリケーションデータバッファー（すなわち、図９に示されているアプリケーションバッファー３２０）を割り当てるように指示する。ブロック１０４６はまた、マイクロプロセッサー２０２に、アプリケーションバッファー３２０へとデータを書き込むように指示する。
【００８７】
上記で開示されたように、特定のアプリケーションおよびメッシュネットワーク１００上の特定の行先であって、それに対してアプリケーションがコンテンツを送信することを希望する前記の特定の行先について、アプリケーションバッファーが割り当てられる。そのようであるので、デバイス７０２上の第２のアプリケーション７１０へとデータを送信するデバイス３００上の第２のアプリケーション３０４について、固有のアプリケーションバッファーが配分される。第２のアプリケーション３０４が別のデバイスにもデータを送信していた場合、メッシュサービスアプリケーションバッファーロケーション２５６内でさらなるアプリケーションバッファーが配分される。各アプリケーションバッファーはしたがって、開始アプリケーション、開始アプリケーションのメッシュポートおよび行先デバイスに関連付けられる。換言すれば、各アプリケーションバッファーは、ソースデバイス（例えば、デバイス３００）から行先デバイス（例えば、デバイス７０２）への特定のデータフローに関連付けられ、かつ、特定のメッシュポートとも関連付けられる。
【００８８】
ブロック１０４６はその後、マイクロプロセッサー２０２にブロック１０４８へと向かうように指示し、該ブロック１０４８は、マイクロプロセッサーに、さらなるデータチャンクが送信されるべきままであるか否かを判定するように指示する。アプリケーションイベントハンドリングプロセス８００のブロック８１８に関して上記で開示されたように、第１のデータチャンクは、データ送信の全長を定める第１のフィールドとしてデータ長を含む。ブロック１０４８において送信について単一のデータチャンクのみが存在する場合（すなわち、データ長が最大＿チャンクパラメーターより短い）、マイクロプロセッサーはブロック１０５０へと向かうように指示される。ブロック１０５０は、マイクロプロセッサー２０２に、データフローに関連付けられるアプリケーションバッファー３２０へとデータチャンクを追加するように指示する。ブロック１０５０はその後、マイクロプロセッサー２０２にプロセス６００のブロック６２０へと戻ってさらなるイベントを待つように指示する。
【００８９】
ブロック１０４８において送信について１つより多いデータチャンクが存在する場合（すなわち、データ長が最大＿チャンクパラメーターより長い）、マイクロプロセッサーはブロック１０５２へと向かうように指示される。ブロック１０５２は、マイクロプロセッサー２０２に、特定のデータ長を有するコンテンツデータについてアプリケーションバッファー３２０に余地が存在するか否かを判定するように指示する。デバイス３００は概して制限されたメモリーサイズを有するので、メッシュサービスアプリケーションバッファーロケーション２５６におけるアプリケーションバッファーは、合理的なサイズで維持されて、デバイスのリソースのオーバーローディングを回避する必要がある。アプリケーションバッファーにおける残りの余地が最大＿チャンクパラメーターの２倍より小さい場合、ブロック１０５２はマイクロプロセッサー２０２にブロック１０５４へと向かうように指示し、かつ、マイクロプロセッサーは、アプリケーションバッファー３２０にデータチャンクを格納し、かつ、コンテンツデータ送信リクエストを始めたアプリケーションインターフェースに、メッシュサービス３１０がいっそう多くのデータチャンクを受け取る準備ができていないことを通知するように指示される。ブロック１０５０はその後、マイクロプロセッサー２０２にプロセス６００のブロック６２０へと戻ってさらなるイベントを待つように指示する。
【００９０】
ブロック１０５２においてアプリケーションバッファーにおける残りの余地が最大＿チ
ャンクパラメーターの２倍より大きい場合、マイクロプロセッサー２０２はブロック１０５６へと向かうように指示され、該ブロック１０５６では、マイクロプロセッサーは、アプリケーションバッファー３２０にデータチャンクを格納し、かつ、コンテンツデータ送信リクエストを始めたアプリケーションインターフェースに、メッシュサービス３１０がいっそう多くのデータチャンクを受け取る準備ができていることを通知するように指示される。ブロック１０５６はその後、マイクロプロセッサー２０２にプロセス６００のブロック６２０へと戻ってさらなるイベントを待つように指示する。ブロック１０４６〜１０５６はしたがって、各データチャンクがアプリケーション３０２および３０４のアプリケーションインターフェース３０６または３０８からメッシュサービス３１０において受け取られるので、繰り返される。
【００９１】
図８に関して上記で開示されたように、アプリケーションイベントハンドリングプロセス８００のブロック８１８〜８２４は、マイクロプロセッサー２０２に、データがメッシュネットワーク１００を通じた送信のためにアプリケーション３０２および３０４からメッシュサービス３１０へとどれくらい早く押されるかを管理するように指示する。メッシュサービスプロセス１０００のブロック１０５４および１０５６は、アプリケーションインターフェース３０６および３０８へと信号を提供して、アプリケーションインターフェース３０６および３０８からメッシュサービスへのデータチャンクの送信速度を制御する。
【００９２】
図９に戻ると、上記で開示されたように、画像９０２はしたがって、第２のアプリケーション３０４のアプリケーションインターフェース３０８によって９０４において示されているようにｎ個のデータチャンクへと分割される。メッセンジャー送信／受信プロセス間通信プロトコル３１２は、アプリケーションイベントハンドリングプロセス８００のブロック８１６〜８２４およびメッシュサービスプロセス１０００のブロック１０４６〜１０５６に関して上記されたように、アプリケーションインターフェース３０８とメッシュサービス３１０との間でチャンク９０４を送信するのに用いられる。これらのブロックはしたがって、一致協力してアプリケーション３０４とメッシュサービス３１０との間でコンテンツデータを移送し、かつ、メッシュサービスがメッシュネットワーク１００を通じた送信のためのデータで溢れることを防止する。
【００９３】
メッシュサービス３１０はしたがって、メモリー２１０のメッシュサービスアプリケーションバッファーロケーション２５６における複数のアプリケーションおよび行先特有のデータバッファーに、メッシュネットワーク１００を通じた送信のためのデータを蓄積する。データはデータチャンクにて受け取られるが、連続した一連のデータバイトとしてアプリケーションバッファーに格納される。メッシュサービスプロセス１０００のブロック１０４６において、送信のためのコンテンツデータチャンクが適用可能なアプリケーションから受け取られ、かつ、特定のデータフローについてメッシュサービスアプリケーションバッファーロケーション２５６におけるアプリケーションバッファー２５６のうちの１つに書き込まれたとき、メッシュサービス３１０は送信のためにデータを処理する。 
【００９４】
信頼性の高いデータ送信
図１１には、信頼性の高いデータ送信プロセスの実施形態が示されている。信頼性の高いデータ送信プロセスは、ソースデバイス（図７に示されているデバイス３００のような）と行先デバイス（デバイス７０２のような）を少なくとも伴い、かつ、１つ以上のルーティングデバイス（デバイス７００のような）をさらに伴ってもよい。信頼性の高いデータ送信は概して、ソースデバイス３００によるメッシュネットワーク１００を通じたデータフローのモニタリングを伴って、データが行先デバイス７０２によって受け取られたことを確認する。その他の実施形態では、信頼性の高くない送信プロトコルもまた、以下で本明細書に記載されるように、用いられてもよい場合がある。信頼性の高いデータ送信プ
ロセスは概して、ユニキャストデータ（すなわち、ソースデバイス３００から単一の行先デバイス７０２へと送信されるデータ）について用いられる。
【００９５】
ソースデバイス送信
メッシュサービス３１０は、それぞれの配分されたアプリケーションバッファー３２０、３２２および３２４について、メッシュサービス送信データバッファーロケーション２５８において送信データバッファー（図９中、３２６、３２８または３３０において示されている）を配分する。そのようであるので、アプリケーションから特定のメッシュポートに関連付けられる行先デバイスへの各データフローについて、送信バッファーが配分される。ソースデバイス３００と行先デバイスとの間には、１つより多いデータフローが存在してもよい。例えば、図７に示されているメッシュネットワーク１００が、別のデバイスであって、その上で第１および第２のアプリケーション３０２および３０４のインスタンスが両方とも実行されている前記の別のデバイスを含む場合、デバイス３００のメッシュサービス３１０は、アプリケーション３０２と行先との間のデータフローについて第１のアプリケーションバッファーを配分し、かつ、アプリケーション３０４と行先との間のデータフローについて第２のアプリケーションバッファーを配分する。これらの第１および第２のアプリケーションバッファーは、同一のソースｕｕｉｄおよび行先ｕｕｉｄを有するが、異なるメッシュポート（すなわち、６０００および５０００）を有する。
【００９６】
図１１Ａを参照すると、信頼性の高いデータ送信プロセスは、各データフローについて（すなわち、デバイス３００のようなデバイス上の各アプリケーションバッファー２５６について）実行されるプロセススレッド１１００を含み、かつ、１１０２において始まる。ブロック１１０４は、ソースデバイス３００のマイクロプロセッサー２０２に、データフローについての配分済みの対応送信バッファー（すなわち、送信バッファー３２６）が３分の１未満だけ満たされているか否かを判定するように指示する。ブロック１１０４において送信バッファー３２６が３分の１より多く満たされている場合、マイクロプロセッサー２０２は、スレッド１１００の最初へと戻るように指示される。ブロック１１０４において送信バッファー３２６が３分の１未満だけ満たされていれば、マイクロプロセッサー２０２はブロック１１０６へと向かうように指示され、該ブロック１１０６は、マイクロプロセッサーに、アプリケーションバッファー３２０からのデータを読み取り、かつ、パケット化し、かつ、データを送信バッファー３２６に書き込むように指示する。１つの実施形態では、メッシュサービス３１０は、メッシュネットワーク１００を通じた送信のためのデータを、メッシュネットワーク１００を通じた送信を促進するように構成されたデータパケットへとエンコードする。以下で本明細書に記載されるように、メッシュネットワーク１００上の行先デバイスのネットワークアドレスが、メッシュサービス３１０がネットワークを通じてデータパケットをルーティングすることを試みるときに解決されるのみであるので、今回は行先が行先デバイスのｕｕｉｄを通して識別可能であるのみであるが、データパケットは概して、ユーザーデータグラムプロトコル（ＵＤＰ）に適合してもよい。概して、送信バッファー３２６に書き込まれるデータパケットのサイズは、デバイスの無線ラジオ２１６によって実施される種々の無線リンクによって送信され得る最大送信単位（ＭＴＵ）の制約の範囲内でできるだけ大きいであろう。１つの実施形態では、送信バッファー３２６は、約３００データパケットを保持するようにサイズ決めされてもよく、したがって、ブロック１１０６は、送信バッファー中に存在するデータパケットが１００未満であると判定されるときはいつでも実行される。スレッド１１００は、メッシュネットワーク１００を通じたデータ送信速度に見合った時間間隔で繰り返されてもよい。
【００９７】
この実施形態では、メッシュネットワーク１００を通じたデータ送信のために送信制御プロトコル（ＴＣＰ）は用いられない。なぜなら、ＴＣＰはインターネットプロトコル（ＩＰ）アドレス指定を自然にサポートするのみである一方で、メッシュネットワーク１０
０は収容されるべき種々の異なるアドレスに依拠するからである。ＴＣＰはまた、プロトコルに基づく接続であり、かつ、ルーティングモードに設定されたメッシュネットワーク１００を構成するデバイスが、マスターモードで異なるデバイスに接続されることの間で周期的に切り替わるので、各スイッチはＴＣＰ接続を切断し、かつ、再確立するのに追加のオーバーヘッドを必要とする。さらに、Ａｎｄｒｏｉｄオペレーティングシステム下ではサポートされないＴＣＰの改良版が用いられるのでなければ、ＴＣＰはマルチパスルートをサポートしない。
【００９８】
さらに図１１Ａを参照すると、信頼性の高いデータ送信プロセスはまた、プロセススレッド１１１０を含み、該プロセススレッド１１１０は各データフローについて実行され、かつ、１１１２において始まる。各データフローについて、メッシュサービス３１０は、各々のアプリケーションバッファー３２６、３２８および３３０に対応する送信キュー（３３２、３３４または３３６）を配分する。送信キュー３３２、３３４および３３６は、メモリー２１０中のメッシュサービス送信キューロケーション２６０に格納される。この実施形態では、プロセス１１１０は、可変輻輳ウインドウ（ｃｏｎｇｅｓｔｉｏｎ  ｗｉｎｄｏｗ）とともに送信キューを用いて、メッシュネットワーク１００上の送信輻輳を回避するための機能を提供する。メッシュネットワーク１００上の各デバイス（３００，７００，７０２）ができるだけ速くデータを送信する場合、深刻な輻輳が、メッシュネットワーク１００が作動不能になることをもたらすであろう。送信デバイスが、送信済みのパケットが行先デバイスによって受け取られたことを確認し得る前に、輻輳ウインドウのサイズが、メッシュネットワーク１００を通じて送信されるデータパケットの最大数を判定する。１つの実施形態では、輻輳ウインドウのサイズは最初は１に設定され、その後、以下で本明細書に記載されるように、行先による送信済みのパケットの受け取りの成功裡の確認に基づいて増大する。
【００９９】
プロセス１１１０はそれぞれの特定のデータフローについて実施され、かつ、ブロック１１１２において始まる。ブロック１１１４は、ソースデバイス３００のマイクロプロセッサー２０２に、データフローについての送信キュー（例えば、送信キュー３３２）におけるデータパケットの数が現在の輻輳ウインドウ（ＣＷ）のサイズより少ないか否かを判定するように指示する。例として、送信キュー３３２に関連付けられたデータフローについて送信が始まったばかりの場合、送信キューは空であり、かつ、ブロック１１１４はマイクロプロセッサー２０２にブロック１１１６へと向かうように指示する。ブロック１１１６は、マイクロプロセッサー２０２に、送信バッファー３２６からの輻輳ウインドウのサイズに対応するデータパケットの数を読み取り、かつ、データパケットを送信キュー３３２に加えるように指示する。ブロック１１１６はまた、マイクロプロセッサー２０２に、送信バッファー３２６からデータパケットを除去するように指示する。上記で開示されたように、最初は輻輳ウインドウのキューサイズは１に設定されてもよく、したがって、単一のデータパケットが送信キュー３３２に追加されてもよい。ブロック１１１４においてデータフローについての送信キュー３３２におけるデータパケットの数が現在の輻輳ウインドウ（ＣＷ）のサイズより少ない場合、マイクロプロセッサー２０２はブロック１１１８へと向かうように指示される。
【０１００】
プロセス１１１０はその後、ブロック１１１８において続き、該ブロック１１１８は、マイクロプロセッサー２０２に、行先デバイスへのルーティング情報が存在するか否かを判定するように指示する。メッシュサービス３１０は、米国仮特許出願第６２／３４３，０５６号（上記で参照され、かつ、参照によってその全体が本明細書に組み込まれる）に概して記載されるように、メモリー２１０のルーティングテーブルロケーション２６４においてルーティングテーブルを維持する。ルーティングテーブルは、メッシュネットワーク１００上で先行して発見された行先デバイスを、それらのメッシュネットワークアドレスによって列挙する。
【０１０１】
各デバイスはメッシュネットワーク１００において少なくとも１つのロールを有し、該ロールは、クライアント、ルーティングデバイスおよびアクセスポイントとしてのものであり得る。クライアントは「ｈｅｌｌｏ」メッセージをアクセスポイントデバイスへと送信して、アクセスポイントへの関連付けをリクエストする。アクセスポイントデバイスは、関連付けリクエストを許可する、確認（「Ｈｅｌｌｏ  ＡＣＫ」）を送信してもよい。クライアントは、アクセスポイントデバイスによって現在サポートされている無線プロトコルに基づいてＷｉＦｉ、ＷｉＦｉまたはＢｌｕｅｔｏｏｔｈを介して接続してもよい。ルーティングのためのメッシュネットワークのトポロジーは、クラスターを用いて構築され、該クラスターは、マスターピアを中心とし、かつ、マスター上で、または、ルーターを介して、二重のロールを有するメッシュへと接続される。我々は、ルーティングを確立する目的で先行するパターンに導入された基本的なシグナリングパケットを有する。
【０１０２】
各行先デバイスは、関連ネクスト−ホップアドレスを有し、該関連ネクスト−ホップアドレスは、行先デバイスが送信デバイスと直接接続する場合には、行先デバイスのアドレスであり、ホップカウンターはしたがって、１に設定される。行先デバイスが直接通信せず、むしろメッシュネットワーク１００上の１つ以上のその他のルーティングデバイスを介して接続される場合、ネクスト−ホップアドレスはルーティングデバイスのアドレスである。行先が１つのルーティングデバイスによって分離されるのみである場合、ホップカウンターは２に設定される。３以上のネクスト−ホップカウンターは、送信デバイスと行先デバイスとの間に２つ以上のルーティングデバイスが存在することを示す。送信デバイスはしたがって、ネクスト−ホップデバイスと接続されるのみであり、かつ、メッシュネットワーク１００上のデバイスのアドレスおよび利用可能である適用可能なホップカウントのみを有するブラックボックスとしてのネクスト−ホップデバイスの後ろに、残りのメッシュネットワーク１００を見る。１つの実施形態では、行先デバイスへと繋がる１つより多いネクスト−ホップデバイスが存在し、かつ、１つより多いパケットが送信されている場合、パケットは異なるパスを通じて同時に送信されてネットワーク待ち時間を減少させてもよい。
【０１０３】
プロセス１１１０のブロック１１１８はしたがって、マイクロプロセッサー２０２に、行先デバイスがルーティングテーブル２６４に列挙されるか否かを判定するように指示し、さらにマイクロプロセッサー２０２に、ネクスト−ホップが現在接続されているか否かを判定するように指示する。上記で注目されたように、ルーティングモードのデバイスは、異なるアクセスポイントに接続することを交互に行い、したがって潜在的なネクスト−ホップデバイスとしてルーティングテーブル２６４に現れるが、現在はデータをルーティングするのに利用可能ではないであろう。ブロック１１１８において行先デバイスがルーティングテーブル２６４に列挙されないか、または、ルーティングテーブルにおけるネクスト−ホップが現在切断されているかのいずれかの場合、マイクロプロセッサー２０２はブロック１１１２へと戻るように指示される。ブロック１１１８において行先デバイスがルーティングテーブル２６４において列挙され、かつ、現在接続されている場合、マイクロプロセッサー２０２はブロック１１２０へと向かうように指示される。
【０１０４】
ブロック１１２０は、マイクロプロセッサー２０２に、無線ラジオ２１６の無線リンク（すなわち、Ｗｉ−Ｆｉ、Ｗｉ−ＦｉダイレクトまたはＢｌｕｅｔｏｏｔｈ）が送信のために利用可能である（この場合、プロセスはブロック１１２２において続く）か否かを判定するように指示する。ブロック１１２２は、マイクロプロセッサー２０２に、送信キュー３３２が空である（この場合、マイクロプロセッサー２０２はブロック１１１２へと戻るように指示され、かつ、ブロック１１１１４〜１１２０が、送信キューに送信するべきデータが存在するまで繰り返される）か否かを判定するように指示する。ブロック１１２２において送信キュー３３２が空でない場合、マイクロプロセッサー２０２はブロック１
１２４へと向かうように指示される。
【０１０５】
上記で開示されたように、各デバイスの無線ラジオ２１６は、Ｗｉ−Ｆｉ、Ｗｉ−Ｆｉダイレクト、Ｂｌｕｅｔｏｏｔｈなどのようないくつかの異なる無線リンクまたはプロトコルを介した接続を提供してもよい。メッシュサービス３１０は、各無線リンクについてリンクキューを配分する。リンクキューは、メモリー２１０の無線リンクキューロケーション２６２内に保持される。例えば、メッシュサービス３１０は、Ｗｉ−Ｆｉキュー３３８、Ｗｉ−Ｆｉダイレクトキュー３４０およびＢｌｕｅｔｏｏｔｈキュー３４２を配分および維持してもよい。上記で開示されたように、いくつかのデバイス上では、無線リンクのうちの１つ以上が一時的または永久に利用不能であり、そのようであるので、キューは利用可能な無線リンクについて配分されるのみである。
【０１０６】
ブロック１１２４はその後、マイクロプロセッサー２０２に、送信のためにデータパケットを生成するように指示する。図１２には１３００において、データパケットの例が示されている。図１２を参照すると、データパケット１３００は、最大＿サイズの全体サイズを有し、かつ、シーケンシャルなブロックとして描かれている複数のデータフィールドを含む。データパケット１３００がＵＤＰデータパケットとして送信される場合、パケットはＵＤＰヘッダー１３０２で始まる。ＵＤＰヘッダーは、Ｗｉ−ＦｉおよびＷｉ−Ｆｉダイレクト送信に用いられるが、異なるプロトコルにしたがうＢｌｕｅｔｏｏｔｈ送信には用いられない。
【０１０７】
データパケット１３００は、送信が信頼性の高い送信であるか信頼性の高くない送信であるかを示す、１バイトのリクエスト＿タイプフィールド１３０４で始まる。データパケット１３００はまた、ソース＿ｕｕｉｄ＿タイプフィールド１３０６およびソース＿ｕｕｉｄフィールド１３０８を含む。ソース＿ｕｕｉｄフィールド１３０８は、リクエストを行っているデバイスについての（ソース＿ｕｕｉｄ＿タイプの）アドレスを保持するのに用いられる。同様に、データパケット１３００はまた、行先＿ｕｕｉｄ＿タイプフィールド１３１０および行先＿ｕｕｉｄフィールド１３１２を含み、行先＿ｕｕｉｄフィールドは、デバイスであって、それにリクエストが送信されている前記デバイスについての行先＿ｕｕｉｄ＿タイプのｕｕｉｄを保持するのに用いられる。１つの実施形態では、リクエスト＿タイプフィールド１３０４、ソース＿ｕｕｉｄ＿タイプフィールド１３０６および行先＿ｕｕｉｄ＿タイプフィールド１３１０は、Ａｎｄｒｏｉｄオペレーティングシステムにおいて提供されるＶａｒｉｎｔデータタイプを用いて１バイトの目録として格納されてもよい。この実施形態におけるソース＿ｕｕｉｄフィールド１３０８および行先＿ｕｕｉｄフィールド１３１２は、データパケット１３００の２０バイトを占める。データパケット１３００はまた、例えばＵＤＰプロトコルへの後の改訂との適合性を提供するのに用いられてもよいプロトコルバージョンを示す１バイト値を保持する、プロトコル＿バージョンフィールド１３１４を含む。
【０１０８】
Ｂｌｕｅｔｏｏｔｈプロトコルを介して送信するとき、ＵＤＰヘッダー１３０２は用いられない。むしろ、来るべきバイトの数を有する整数が送信される。受け取りＢｌｕｅｔｏｏｔｈデバイスは、特定の数のバイトが受け取られるまでデータバイトを読み取る。データパケットがＢｌｕｅｔｏｏｔｈを介して転送されるとき、適切なＢｌｕｅｔｏｏｔｈ無線リンクが選択され、かつ、データが、ルーティングテーブルからの行先ＭＡＣアドレスに基づいて正しいキューにエンキューされる。Ｗｉ−ＦｉおよびＷｉ−Ｆｉダイレクトを通じたインターネットプロトコル送信については、行先アドレスは、データパケットが単一のホップキューにエンキューされるときに付加される。
【０１０９】
データパケット１３００はまた、シングル−ホップを通してメッシュネットワーク１００を通じて無線リンクによって送信される一連のデータパケットを追跡するためのシング
ル＿ホップ＿ｓｅｑ＃フィールド１３１６を含む。ブロック１１２４における無線リンクのレベルでＵＤＰデータパケット１３００を生成するとき、以下に記載されるように、フィールド１３１６にはシーケンシャルなシングル−ホップ＿ｓｅｑ＃値が書き込まれて、どのデータパケットが成功裡に送信されるかの識別を許可する。データパケット１３００はまた、上記されたように、リクエストを生成するアプリケーションについてのメッシュポート識別子を保持するためのメッシュ＿ポートフィールド１３１８を含む。これらのフィールドはそれぞれ、Ｖａｒｉｎｔデータタイプを用いてエンコードされ、該Ｖａｒｉｎｔデータタイプは１〜４バイトを用いて整数をシリアル化し、かつ、該Ｖａｒｉｎｔデータタイプでは、通信の効率のために、いっそう小さい数字がいっそう小さい数のバイトをとる。
【０１１０】
データ１３００はまた、データペイロードのバイト長を特定する値を保持するデータ＿長さフィールド１３２０を含む、データパケットにおいて実行されるべきペイロードに関する多数のフィールドを含む。この実施形態では、データパケットのシーケンスにおける第１のデータパケットのみが、データ＿長さフィールド１３２０を含むであろう。メッシュネットワーク１００を介したデータ通信の整合性を確証するために、任意選択的なチェックサムフィールド１３２２が含まれてもよい。データパケット１３００はまた、送信されるデータパケットのシーケンスにおける各データパケットの順番を識別する、マルチ−ホップ＿ｓｅｑフィールド１３２４を含む。マルチ−ホップ＿ｓｅｑフィールド１３２４については、固有の連続する整数が用いられてもよい。１つの実施形態では、マルチ−ホップ＿ｓｅｑは、最も大きい考え得るシーケンス数が十分に大きい限り、曖昧さを伴わずに循環的な様式で数字のシーケンスを再び用いてもよい。
【０１１１】
データ＿ペイロードフィールド１３２８は、データパケットの残りのフィールドにおけるヘッダーバイトの数より少ないデータ＿最大のサイズを有する。この実施形態では、データパケット１３００はまた、データパケット１３００中のデータペイロードが暗号化されたか否かの指標を保持するための暗号化フィールド１３２６を含む。
【０１１２】
データパケット１３００はまた、データパケットに関連付けられる送信時間を保持するためのタイムスタンプフィールド１３３０を含む。タイムスタンプフィールド１３３０は図１２に示されているデータパケットの一部として示されている一方で、タイプスタンプはその他のデバイスへと送信されず、むしろ、デバイス上の送信のためにエンキューされるデータパケットにおいて保持されるのみである。
【０１１３】
ブロック１１２４はまた、マイクロプロセッサー２０２に、データパケット１３００のタイムスタンプフィールド１３３０に現在の時間を書き込むように指示する（上記で開示されたように、このタイムスタンプはメッシュネットワーク１００を通じて送信されず、むしろ、以下で本明細書に記載されるように追跡目的でソースデバイスによって用いられるが）。プロセススレッド１１１０はその後、ブロック１１２６において続き、該ブロック１１２６は、マイクロプロセッサー２０２に、リンクキュー３３２のコンテンツ（すなわち、データパケット（単数）またはデータパケット（複数））を適用可能な無線リンクキュー（例えば、Ｗｉ−Ｆｉキュー３３８）へと書き込むように指示する。
【０１１４】
ブロック１１２８はその後、マイクロプロセッサー２０２に、データフローについてエンド−トゥー−エンド（ｅｎｄ−ｔｏ−ｅｎｄ；端末相互間）タイムアウトタイマーが起動されたか否かを判定するように指示する。エンド−トゥー−エンドタイムアウトタイマーは、データフローにおける先に送信されたデータパケットがＷｉ−Ｆｉリンクによる送信のためにキュー３３８に既に書き込まれていた場合には、起動されていたであろう。エンド−トゥー−エンドタイムアウトタイマーがまだ起動されていない場合、キュー３３８に書き込まれるデータパケットはデータフローにおける第１のデータパケットであり、か
つ、マイクロプロセッサー２０２はブロック１１３０へと向かうように指示され、該ブロック１１３０においてエンド−トゥー−エンドタイムアウトタイマーが起動される。ブロック１１３０はその後、マイクロプロセッサー２０２にブロック１１１２へと戻るように指示し、かつ、スレッド１１１０は、データフローにおけるさらなるデータパケットについて繰り返される。
【０１１５】
図１１Ｂを参照すると、信頼性の高いデータ送信プロセスはまた、１１４２において始まるシングル−ホップ送信プロセススレッド１１４０を含む。シングル−ホップ送信プロセススレッド１１４０は、無線ラジオ２１６に、各リンクキュー３３８、３４０および３４２上で作動し、かつ、データフローについてデータパケットを送信するように指示する。ブロック１１４４は、ソースデバイス３００のマイクロプロセッサー２０２に、リンクキュー（例えば、Ｗｉ−Ｆｉキュー３３８）が空である（この場合、マイクロプロセッサーは、ブロック１１４６において次のリンクキューを処理するように指示され、かつ、プロセスはその後１１４２において再開する）か否かを判定するように指示する。ブロック１１４４においてリンクキューが空ではない場合、マイクロプロセッサー２０２はブロック１１４８へと向かうように指示され、該ブロック１１４８では、送信リトライカウンターＸｒが値１に初期化される。送信リトライカウンターは、メモリー２１０中のカウンターロケーション２６６において保持され、かつ、無線リンクによる特定のデータパケットの送信のための送信試行をモニタリングするのに用いられる。
【０１１６】
ブロック１１５０はその後、マイクロプロセッサー２０２に、送信のためにリンクキュー３３８のヘッドにおけるデータパケットを処理するように指示する。各無線リンクは、特定の送信プロトコルおよび送信フォーマットを有し、かつ、無線リンクは、それ自体の特定の送信フォーマット内でデータパケット１３００の必要なカプセル化を実行するであろう。例えば、インターネットプロトコル（ＩＰ）を用いてデータを移送するＷｉ−ＦｉおよびＷｉ−Ｆｉダイレクトリンクは、図１２に示されているＵＤＰヘッダー１３０２とともにデータパケット１３００をカプセル化する。いくつかの実施形態では、データパケット１３００は、データパケットを送信のためにいっそう小さいデータパケットへと細分化しなければならない無線リンクによって送信され得るものより大きくてもよい。図１２中の１３００において示されているデータパケット１３００が細分化される場合、シングル−ホップ＿ｓｅｑ＃フィールド１３１６は、シングル−ホップ確認に用いられて、データパケットがネクストホップに対してそれを行うことを確実にし、パケットが行先に到達することも確実にする。無線リンクは、シングル−ホップキュー上で作動して、それが可能であるすべてのパケットを送信し、かつ、各シングル−ホップパケットは、送信に関連付けられる時間を有する。シングル−ホップＡＣＫを受け取る前にタイムアウトが存在する場合、送信デバイスは、それが無線リンクについて設定された最大＿リトライ（この時点でパケットは破棄される）に到達するまで、データを再び送るであろう。無線リンクは、シングル−ホップ＿ｓｅｑ＃フィールド１３１６を設定および維持する。
【０１１７】
ブロック１１５０はその後、マイクロプロセッサー２０２に、無線ラジオ２１６が無線リンク（この場合、Ｗｉ−Ｆｉ無線リンク）を通じてネクスト−ホップデバイスへとデータパケットを送信することを引き起こすように指示する。シングル−ホップ送信プロセススレッド１１４０はその後、ブロック１１５２において続き、該ブロック１１５２は、マイクロプロセッサー２０２に、シングル−ホップ確認（シングル−ホップＡＣＫ）が期間内にネクスト−ホップデバイスから折り返し受け取られるか否かをモニタリングするように指示する。期間は予め決められた最大時間として実施されるが、送信デバイスは、再送信の前に最大時間までのランダム化された時間の間待機する。ランダム化された時間は、周期的に１つのアクセスポイントデバイスから切断して別のアクセスポイントデバイスに接続するルーターモードでデバイスとリンクすることを失敗する機会を減少させるのに用いられる。各再送信に続いて、いっそう長い待機時間が、最大＿リトライ閾値が到達され
るときにパケットを破棄する前に経過することが可能とされる。
【０１１８】
シングル−ホップＡＣＫは、受け取られるデータパケットのフィールド１３１６から読み取られるシングル−ホップ＿ｓｅｑ＃を含み、かつ、送信デバイスに、識別されるデータがその意図した行先に到達した旨の確認を提供する。ブロック１１５２はまた、マイクロプロセッサー２０２に、送信リトライカウンターＸｒが最大リトライ閾値ｒｍａｘに到達したか否かを判定するように指示する。１つの実施形態では、ｒｍａｘの値は、各データパケット送信についての３回のリトライ試行に対応して３に設定される。ブロック１１５２において、シングル−ホップＡＣＫが受け取られるか、または、送信リトライカウンターＸｒが最大リトライ閾値ｒｍａｘに到達した場合、シングル−ホップ送信プロセススレッド１１４０はブロック１１５４において続き、該ブロック１１５４は、マイクロプロセッサー２０２に、リンクキュー３３８からデータパケットを除去するように指示する。そのようであるので、無線リンクによる送信が成功しないとき、データパケットはキューから除去され、かつ、送信のためのさらなる試行は行われない。信頼性の高い送信プロセスはしたがって、以下で本明細書に記載されるエンド−トゥー−エンド確認プロセスに頼る。シングル−ホップ確認プロセスの１つの利点は、偽の送信失敗が、プロセスに、妨害されたシングル−ホップリンクを介して再送信を終わりなく試みさせることを伴わずに、制限されたリトライメカニズムを通して防止されることである。メッシュネットワーク１００全体にマルチプルホップを通じてデータパケットを送信するとき、ホップのうちの１つにおいて送信失敗が存在する可能性がかなり高い。シングル−ホップ送信プロセススレッド１１４０はしたがって、メッシュネットワーク１００が再送信を試みることによって失敗から復帰し、したがって、以下でいっそう詳細に記載されるエンド−トゥー−エンド再送信の数を減少させることを可能にする。ブロック１１５４はその後、マイクロプロセッサー２０２にブロック１１４４へと戻るように指示し、かつ、ブロック１１４４〜１１５６が上記のように繰り返される。
【０１１９】
ネクストホップｕｕｉｄは、行先デバイスのルーティングが見出されるときに判定される。無線リンクがＷｉ−Ｆｉリンクであるか、または、Ｂｌｕｅｔｏｏｔｈリンクであるかに基づいて、ＭＡＣアドレスまたはＩＰアドレスがネクストホップについて必要とされるであろう。それがＭＡＣアドレスである場合、Ｂｌｕｅｔｏｏｔｈリンクの実施は、１：１のＢｌｕｅｔｏｏｔｈリンクのすべてのＭＡＣアドレスを判定したであろうし、かつ、データパケットは、正しいＢｌｕｅｔｏｏｔｈリンクキューにエンキューされる。Ｗｉ−ＦｉまたはＷｉ−Ｆｉダイレクト無線リンクを通じたＩＰ送信については、ネクスト−ホップＩＰアドレスは、ルーティングテーブルロケーション２６４におけるネクスト−ホップデバイスの検索に基づいてＵＤＰデータパケットに追加される。このＩＰアドレスは、ネクストホップデバイスへの送信のためにＵＤＰヘッダー１３０２に入れられる。データパケット中の行先＿ｕｕｉｄフィールド１３１２はしたがって、データパケット１３００についての最終行先デバイスを識別し、メッシュネットワーク１００上のネクスト−ホップＩＰアドレスは、次のデバイスであって、それへとデータパケットが行先デバイスにやがては到達するように送信される前記の次のデバイスを識別する。
【０１２０】
ブロック１１５２においてシングル−ホップＡＣＫがまだ受け取られず、かつ、送信リトライカウンターＸｒがまだ最大リトライ閾値ｒｍａｘに到達していない場合、マイクロプロセッサー２０２はブロック１１５６へと向かうように指示され、該ブロック１１５６では、送信リトライカウンターＸｒが増大する。ブロック１１５６はその後、マイクロプロセッサー２０２にブロック１１５０へと戻るように指示し、無線リンクを通じてデータパケットを送信するためにさらなる試行が行われる。
【０１２１】
シングル−ホッププロセススレッド１１４０は、各無線リンクキューについて、かつ、メッシュネットワーク１００における各デバイス上で実施され、データが、連続的なシン
グル−ホップ送信を通じてメッシュネットワーク１００を通って意図した行先へと伝播するようになっている。
【０１２２】
行先／ルーティング
図１１Ｃを参照すると、信頼性の高いデータ送信プロセスはまた、メッシュネットワーク１００上の受け取りデバイス上のメッシュサービスによって実施される、エンド−トゥー−エンド確認プロセススレッド１１６０を含む。エンド−トゥー−エンド確認プロセススレッド１１６０は、メッシュネットワーク１００上の任意のデバイスにおいてデータパケットが受け取られるときに、１１６２において始まる。ブロック１１６４は、受け取りデバイス（すなわち、ルーティングデバイスまたは行先デバイス７０２のいずれか）のマイクロプロセッサー２０２に、データパケットが受け取られたことを確認するデータパケットを送信したデバイスへと戻るようにシングル−ホップＡＣＫを送信するように指示する。シングル−ホップ送信プロセススレッド１１４０のブロック１１５２に関して上記されたように、シングル−ホップＡＣＫは、ソースデバイス３００（または、送信のためにメッシュネットワーク１００全体にマルチプルホップが存在する場合には、その他のルーティングデバイス）によって用いられ、各デバイスにおいて無線リンクキュー２６２が管理される。
【０１２３】
ブロック１１６４はその後、マイクロプロセッサー２０２に、データパケットの行先＿ｕｕｉｄフィールド１３１２を読み取るように指示し、かつ、ブロック１１６６は、マイクロプロセッサーに、行先＿ｕｕｉｄフィールドのコンテンツをメッシュネットワーク１００上のデバイス自体のアドレスと比較することによって、受け取りデバイスがデータパケットの最終行先であるか否かを判定するように指示する。デバイスがデータパケットについての最終行先ではなく、むしろルーティングデバイスとして作用している場合、プロセススレッドはブロック１１６８において続き、該ブロック１１６８では、マイクロプロセッサー２０２が、データパケットをメモリー２１０中の転送バッファー２６８へと書き込むように指示される。ルーティングデバイスに転送バッファー２６８を管理するように指示するためのスレッドが、図１１Ｄを参照して以下で本明細書に記載される。プロセス１１６０はその後、ブロック１１６８において続き、該ブロック１１６８は、マイクロプロセッサー２０２に、１１６２へと戻って無線リンクを通じた次のデータパケットの受け取りを待つように指示する。したがって、デバイスがデータフローについてルーティングデバイスとして作用している場合、データパケットを転送するときにプロセス１１１６０のブロック１１６２〜１１６８のみが実行されるであろう。
【０１２４】
ブロック１１６６において受け取りデバイスがデータパケットについての最終行先である（すなわち、行先＿ｕｕｉｄフィールド１３１２が、メッシュネットワーク１００上のデバイス自体のアドレスと一致する）場合、マイクロプロセッサー２０２はブロック１１７０へと向かうように指示される。ブロック１１７０は、マイクロプロセッサー２０２に、マルチ−ホップ＿ｓｅｑフィールド１３２４を読み取ることによって、受け取られるデータパケットが進行中のデータフローに関連付けられる順番通りのデータパケットであるか否かを判定するように指示する。デバイスにおいて受け取られる各データパケットは、ソース＿ｕｕｉｄフィールド１３０８、行先＿ｕｕｉｄフィールド１３１２およびメッシュ＿ポートフィールド１３１８に基づいて特定のデータフローに関連付けられると判定されてもよい。進行中のデータフローに関連付けられる１つ以上のデータパケットがデバイスによって既に受け取られている場合、次のデータパケットは、データフローについて最後に受け取られたパケットを通じて１だけ増大したマルチ−ホップ＿ｓｅｑフィールド１３２４を有することが予測されるであろう。ブロック１１７０において、マイクロプロセッサー２０２はしたがって、受け取られるデータパケットが進行中のデータフローについて次に予測されるマルチ−ホップ＿ｓｅｑと一致するか、または、データフローにおける第１のパケットである（マルチ−ホップ＿ｓｅｑ＝１）かを判定するように指示される。
いずれの場合も、プロセスはブロック１１７２において続き、該ブロック１１７２は、マイクロプロセッサー２０２に、閾値カウンターＸ０を増大させるように指示する。閾値カウンターＸ０は、メモリー２１０のカウンターロケーション２６６に格納され、かつ、シーケンシャルに受け取られる順番通りのデータパケットのカウントを維持するのに用いられる。ブロック１１７４はその後、マイクロプロセッサー２０２に、閾値カウンターＸ０が閾値Ｘ０ｍａｘに到達したか否かを判定するように指示する。
【０１２５】
プロセススレッド１１６０はその後、ブロック１１７６において続き、該ブロック１１７６では、マイクロプロセッサー２０２が、閾値カウンターＸ０を０に再設定するように指示される。ブロック１１７６はまた、マイクロプロセッサー２０２に、データフローにおいて受け取られた最後の順番通りのデータパケットのシーケンス番号を判定するように指示する。ブロック１１７８はその後、マイクロプロセッサー２０２に、エンド−トゥー−エンドＡＣＫを生成し、かつ、データパケット中のソース＿ｕｕｉｄフィールド１３０８によるデータフローのソースとして識別されるデバイスへと戻るように送信するように指示する。エンド−トゥー−エンドＡＣＫは、最後に受け取られた順番通りのデータパケットのシーケンス番号を増大させることによって判定される、次に予測されるデータパケットのシーケンス番号を含む。この実施形態では、エンド−トゥー−エンドＡＣＫは、成功裡に受け取られた最後のパケットを識別するよりはむしろ、シーケンス番号によって次に予測されるデータパケットを識別する。その他の実施形態では、エンド−トゥー−エンドＡＣＫは、成功裡に受け取られた最後のパケットを識別し得る。ブロック１１７８はその後、マイクロプロセッサー２０２にブロック１１６２へと戻ってさらなるデータパケットの受け取りを待つように指示する。
【０１２６】
閾値Ｘ０ｍａｘは典型的には、少なくとも２または３の値に設定されて、エンド−トゥー−エンドＡＣＫが、データフローに関連付けられる１つより多いデータパケットが受け取られた後にメッシュネットワーク１００を通じて送信されるのみであることを引き起こす。エンド−トゥー−エンド確認プロセススレッド１１６０はしたがって、ＡＣＫメッセージを生成してそれぞれの単一のパケットよりはむしろいくつかのデータパケットの受け取りを確認することのみによって、メッシュネットワーク１００をエンド−トゥー−エンドＡＣＫメッセージで溢れさせることを回避する。
【０１２７】
ブロック１１７４において閾値カウンターＸ０がまだ閾値Ｘ０ｍａｘに到達していない場合、プロセスはブロック１１８２において続き、該ブロック１１８２は、マイクロプロセッサー２０２に、エンド−トゥー−エンド確認タイマー（ＡＣＫタイマー）がデータフローについて起動されたか否かを判定するように指示する。データパケットがデータフローにおける第１のパケットであった場合、エンド−トゥー−エンドＡＣＫタイマーは起動されていないであろうし、かつ、ブロック１１８４においてタイマーがデータフローに関連付けられ、かつ、ゼロに初期化される。ブロック１１８２においてエンド−トゥー−エンドＡＣＫタイマーが先行して起動された場合、マイクロプロセッサー２０２はブロック１１８６へと向かうように指示され、かつ、エンド−トゥー−エンドＡＣＫタイマーはゼロに再設定される。エンド−トゥー−エンドＡＣＫタイマーは、エンド−トゥー−エンドＡＣＫタイマー満了閾値とともに用いられて、期間であって、その最中にデバイスがデータフローに関連付けられるいっそう多くのデータを受け取るために待機する前記期間を確立する。
【０１２８】
エンド−トゥー−エンド確認プロセススレッド１１６０に関する別のスレッド１１９０では、ブロック１１９２はエンド−トゥー−エンドＡＣＫタイマーをモニタリングし、かつ、タイマーが満了閾値に到達する場合、受け取りデバイスのマイクロプロセッサー２０２はブロック１１９４へと向かうように指示される。ブロック１１９４はその後、マイクロプロセッサー２０２に、受け取られる最後の順番通りのデータパケットのマルチ−ホッ
プ＿ｓｅｑフィールド１３２４からの値を判定するように指示する。ブロック１１９４はまた、マイクロプロセッサー２０２にブロック１１７８へと向かうように指示し、該ブロック１１７８では、次に予測されるデータパケットを識別するエンド−トゥー−エンドＡＣＫが、ソースデバイスへと戻るようにメッシュネットワーク１００を通じて送信される。エンド−トゥー−エンド確認プロセススレッド１１６０はしたがって、タイムアウトであって、Ｘ０ｍａｘの値によって設定されるデータパケットの数がその時間内に受け取られなければならない前記タイムアウトをさらに実施する。タイムアウトが到達される場合、行先デバイスはもはや、さらなるデータパケットを待たず、かつ、次に予測されるパケットを識別するソースデバイスへと戻るようにエンド−トゥー−エンドＡＣＫを送信しない。
【０１２９】
ブロック１１７０において順不同なデータパケットが受け取られる場合、マイクロプロセッサー２０２はブロック１１８０へと向かうように指示され、該ブロック１１８０では、マイクロプロセッサーは、最後に受け取られた順番通りのデータパケット中のマルチ−ホップ＿ｓｅｑフィールド１３２４の値を判定するように指示される。ブロック１１８０はその後、マイクロプロセッサー２０２にブロック１１７８へと向かうように指示し、該ブロック１１７８では、マイクロプロセッサーは、データフローにおける次に予測されるパケットについてエンド−トゥー−エンドＡＣＫを送信するように指示される（すなわち、マルチ−ホップ＿ｓｅｑ＋１）。このことは、マルチ−ホップ＿ｓｅｑのソースデバイスにデータフローにおける１つ以上の行方不明のデータパケットの第１のパケットについて通知する効果を有し、データパケットが再送信され得るようになっている。
【０１３０】
上記で開示されたように、ブロック１１６８においてデータパケットが受け取りデバイス以外の行先を有すると判定される場合、デバイスはルーティングデバイス（例えば、図３におけるデバイス７００）として作用し、かつ、データパケットをその転送バッファー２６８に書き込む。図１１Ｄを参照すると、転送バッファー２６８を処理するためのルーティングデバイス７００上で実行される転送プロセススレッドが１２００において示されており、かつ、１２０２において始まる。転送プロセススレッド１２００は、デバイス上の各転送バッファー２６８上で実行される。ブロック１２０４は、ルーティングデバイスのマイクロプロセッサー２０２に、転送バッファー２６８に任意のデータパケットが存在するか否かを判定するように指示する。転送バッファー２６８にいかなるパケットも存在しない場合、マイクロプロセッサー２０２はブロック１２０６へと向かうように指示され、該ブロック１２０６は、マイクロプロセッサーに、ロケーション２６８における次の転送バッファーを処理するように指示する。
【０１３１】
ブロック１２０４において転送バッファーに１つ以上のデータパケットが存在する場合、マイクロプロセッサー２０２はブロック１２０８へと向かうように指示され、該ブロック１２０８は、マイクロプロセッサーに、データパケット中の行先＿ｕｕｉｄフィールド１３１２を読み取るように指示する。転送プロセススレッド１２００はその後、ブロック１２１０において続き、該ブロック１２１０は、マイクロプロセッサー２０２に、行先デバイスがデバイスルーティングテーブル２６４に列挙されているか否かを判定することによって、行先デバイスへのルーティング情報が存在するか否かを判定するように指示する。ブロック１２１０はさらに、マイクロプロセッサー２０２に、ネクスト−ホップが現在接続されているか否かを判定するように指示する。ブロック１２１０において行先デバイスがルーティングテーブル２６４に列挙されており、かつ、現在接続されている場合、マイクロプロセッサー２０２はブロック１２１２へと向かうように指示される。
【０１３２】
ブロック１２１２は、マイクロプロセッサー２０２に、無線ラジオ２１６に関連付けられる無線リンクインターフェースが利用可能である（この場合、プロセスはブロック１２１４において続く）か否か判定するように指示する。ブロック１２１４は、マイクロプロ
セッサー２０２に、データパケットを送信のために選択される無線リンクについてのリンクキューに書き込むように指示する。ブロック１２１４はまた、マイクロプロセッサー２０２に、転送バッファーからデータパケットを除去するように指示する。転送されるデータパケットの送信は、図１１Ｂに示されているシングル−ホップ送信プロセススレッド１１４０にしたがい、かつ、無線リンクは、データパケットを転送するために数回の（ｒｍａｘ）試行を行うであろう。転送送信が失敗する場合、パケットはリンクキューから除去され、かつ、信頼性の高い送信のためのさらなる処理が、以下で本明細書に記載されるようにソースデバイスへと戻る。
【０１３３】
図１１Ｃに戻ると、ブロック１１７８において、信頼性の高いデータ送信プロセスのエンド−トゥー−エンド確認プロセススレッド１１６０は、データフローにおいて次に予測されるパケットを識別するエンド−トゥー−エンドＡＣＫを送信する。この実施形態では、エンド−トゥー−エンドＡＣＫはＵＤＰデータパケット１３００のフォーマットに適合するが、空のデータペイロードフィールドを有し、かつ、マルチ−ホップ＿ｓｅｑフィールド１３２４におけるフローについての次に予測されるデータパケットのシーケンス番号を含む。行先デバイスは、上記されたように、ＡＣＫデータパケットについてのエンド−トゥー−エンド確認プロセスを実施しないが、エンド−トゥー−エンドＡＣＫは、上記されたように、１つ以上のシングル−ホップ送信を介してメッシュネットワーク１００を通じて送信される。
【０１３４】
ソース確認処理
図１１Ｅを参照すると、信頼性の高いデータ送信プロセスはまた、ソース確認処理スレッド１２２０を含み、該ソース確認処理スレッド１２２０は、各データフローについて実行され、かつ、エンド−トゥー−エンドＡＣＫが受け取られるときに１２２２において始まる。ブロック１２２４は、ソースデバイス３００のマイクロプロセッサー２０２に、エンド−トゥー−エンドＡＣＫにおける行先＿ｕｕｉｄフィールド１３１２を読み取り、かつ、ＡＣＫがソースデバイスへとアドレス指定されるか否かを判定するように指示する。エンド−トゥー−エンドＡＣＫがメッシュネットワーク１００上の別のデバイスへとアドレス指定される場合、ブロック１２２６は、マイクロプロセッサー２０２に、エンド−トゥー−エンドＡＣＫを転送バッファー２６８に書き込むように指示する。転送プロセススレッド１２００はその後、メッシュネットワーク１００を通じてＡＣＫを転送するであろう。
【０１３５】
ブロック１２２４においてエンド−トゥー−エンドＡＣＫがソースデバイスへとアドレス指定される場合、マイクロプロセッサー２０２はブロック１２２８へと向かうように指示される。ブロック１２２８は、マイクロプロセッサー２０２に、ＡＣＫデータパケットのマルチ−ホップ＿ｓｅｑフィールド１３２４におけるＡＣＫシーケンス番号が先行して受け取られたか否かを判定するように指示する。ソースデバイスが同一の次に予測されるデータパケットを示すＡＣＫを先行して受け取っていた場合、プロセスはブロック１２３０において続き、該ブロック１２３０は、マイクロプロセッサー２０２に、同一のエンド−トゥー−エンドＡＣＫが受け取られた回数をカウントするのに用いられるカウンターＸＡＣＣを増大させるように指示する。同一のエンド−トゥー−エンドＡＣＫシーケンス番号が数回受け取られることは、データパケットが行先デバイスに到達していないので、メッシュネットワークを通じた行先へのリンクがもはや利用可能ではないかも知れないことを示す。ブロック１２３０はその後、マイクロプロセッサー２０２にブロック１２４２へと向かうように指示する。
【０１３６】
ブロック１２２８においてソースデバイスが同一の次に予測されるデータパケットを示すＡＣＫを先行して受け取っていない場合、エンド−トゥー−エンドＡＣＫは、データフローにおけるすべての先行するデータパケットが受け取られたことを確認し、かつ、ブロ
ック１２３２は、マイクロプロセッサー２０２に、カウンターＸＡＣＣをゼロに再設定するように指示する。ブロック１２３２はまた、マイクロプロセッサー２０２に、上記で開示されたようにプロセススレッド１１１０のブロック１１３０において起動された、データフローに関連付けられるエンド−トゥー−エンドタイムアウトカウンターを停止させるように指示する。 
【０１３７】
ブロック１２３４はその後、マイクロプロセッサー２０２に、データパケットであって、それについての受け取りが送信キュー３３２から確認された前記データパケットを除去するように指示する。図１１Ａに戻ると、ブロック１１２６において、配分済みの送信キュー２５８からのデータパケットが、選択済みのリンクキュー３３８、３４０または３４２に書き込まれるが、ブロック１２３４がマイクロプロセッサー２０２にエンド−トゥー−エンドＡＣＫを処理した後でデータパケットを除去するように指示するまで送信キューから除去されない。したがって、確認が保留中である、送信キュー３３２のヘッドにシーケンシャルな順番で保持されるいくつかのデータパケットが存在してもよい。エンド−トゥー−エンド確認プロセススレッド１１６０に関して記載されたように、エンド−トゥー−エンドＡＣＫが、行先デバイス７０２において受け取られるすべてのデータパケットについて送信されなくてもよく、むしろ、Ｘ０ｍａｘ個の順番通りのパケットが受け取られたか、または、エンド−トゥー−エンドＡＣＫタイマーが満了するときに送信される。ソースにおいて受け取られるエンド−トゥー−エンドＡＣＫはしたがって、送信キュー３３２のヘッドまたは送信キューのヘッドからの数個のパケットのいずれかにおいて保持されているデータパケットに対応するマルチ−ホップ＿ｓｅｑフィールド１３２４におけるシーケンス番号を有してもよい。いずれの場合も、ソース確認処理スレッド１２２０のブロック１２３４は、マイクロプロセッサー２０２に、エンド−トゥー−エンドＡＣＫにおけるシーケンス番号より小さいシーケンス番号を有する送信キュー３３２からすべてのデータパケットを除去するように指示するであろう。
【０１３８】
ブロック１２３４の実行に続いて、受け取られるエンド−トゥー−エンドＡＣＫにおけるシーケンス番号に対応するデータパケットが存在する場合（すなわち、次のデータパケット保留中確認）、データパケットは適用可能な送信キュー２６０のヘッドへと移動し、残りのデータパケット（これらが存在する場合）が後に続く。ブロック１２３６はその後、マイクロプロセッサー２０２に、さらなるパケットが送信キュー３３２に残っているか否かを判定することによって、行先デバイスによってまだ確認されるべきデータフローにおけるさらなるデータパケットが存在するか否かを判定するように指示する。ブロック１２３６において少なくとも１つのデータパケット保留中確認が送信キュー３３２に残っている場合、ブロック１２４はマイクロプロセッサー２０２にブロック１２３８へと向かうように指示する。ブロック１２３８は、マイクロプロセッサー２０２に、データパケットからタイムスタンプフィールド１３３０を読み取り、かつ、タイムスタンプ値に基づいてエンド−トゥー−エンドタイムアウトタイマーを再設定するように指示する。エンド−トゥー−エンドタイムアウトはしたがって、次のデータパケット保留中確認の送信の実際の時間に基づいてアップデートされる。ブロック１２３８はその後、マイクロプロセッサー２０２にブロック１２５０へと向かうように指示する。ブロック１２３６において送信されるべき適用可能な送信キュー２６０におけるいかなる残りのデータパケットも存在しない場合、マイクロプロセッサーはまた、ブロック１２５０へと向かうように指示される。
【０１３９】
送信輻輳
エンド−トゥー−エンドＡＣＫを処理したソース確認処理スレッド１２２０のブロック１２３０、１２３６および１２３８において、マイクロプロセッサー２０２はその後、ネットワーク輻輳プロセススレッド１２４０を実行するように指示される。ネットワーク輻輳プロセススレッド１２４０は、メッシュネットワーク１００を通じてデータフローによって経験される輻輳をモニタリングし、かつ、ソースデバイス３００からの送信を適宜適
合させる。ブロック１２５０において、マイクロプロセッサー２０２は、メッシュネットワーク１００の送信状態を判定するように指示される。この実施形態では、メッシュネットワーク１００全体のデータフローについての３つの考え得る送信状態が、ソースデバイスにおいて実施される。ソースデバイス３００においてデータフローを開始させるときには、スロースタート送信状態が実施される。スロースタート送信状態下では、信頼性の高い送信プロセスは、輻輳ウインドウサイズＣＷ＝１（データパケット）を有して始まる。以下に記載されるように、輻輳回避状態およびファストリカバリー（ｆａｓｔ  ｒｅｃｏｖｅｒｙ；高速復帰）状態もまた実施される。ブロック１２５０は、マイクロプロセッサー２０２に、現在の送信状態がスロースタートに設定されている（この場合、マイクロプロセッサーはブロック１２５２へと向かうように指示される）か否かを判定するように指示する。ブロック１２５２は、マイクロプロセッサー２０２に、行先デバイスからの受け取られるエンド−トゥー−エンドＡＣＫにおいて確認されるデータパケットの数（すなわち、＃ＡＣＫ）だけ輻輳ウインドウＣＷを増大させるように指示する。この控えめな増大は、ソースデバイス３００が、メッシュネットワーク１００が渋滞しているか否かを判定する機会が存在する前に多数のデータパケットを送信することを防止する。輻輳ウインドウは、プロセススレッド１１１０に関して上記されたように送信キュー３３２内に維持され、かつ、メッシュサービス送信キューロケーション２６０内に十分なストレージが配分されて、メッシュネットワーク１００が渋滞していない場合に輻輳ウインドウのサイズを増大させることを可能にする。
【０１４０】
プロセススレッド１２４０はその後、ブロック１２５４において続き、該ブロック１２５４では、マイクロプロセッサー２０２は、輻輳ウインドウＣＷの現在のサイズが輻輳ウインドウ閾値サイズＣＷＴＨより大きいか否かを判定するように指示される。輻輳ウインドウ閾値サイズＣＷＴＨは信頼性の高いデータ送信プロセスの最中に変更されてもよいが、予め定められた最小サイズで、または、予め定められた最小サイズより上で維持されるであろう。ブロック１２５４において輻輳ウインドウＣＷのサイズがＣＷＴＨより下のままである場合、マイクロプロセッサー２０２はブロック１２２２へと戻って次のエンド−トゥー−エンドＡＣＫを待つように指示される。
【０１４１】
ブロック１２５４において輻輳ウインドウサイズがＣＷＴＨに到達した場合、マイクロプロセッサー２０２はブロック１２５６へと向かうように指示され、該ブロック１２５６では、送信状態は輻輳回避に設定される。マイクロプロセッサー２０２はその後、ブロック１２２２へと戻って次のエンド−トゥー−エンドＡＣＫを待つように指示される。信頼性の高い送信プロセスはしたがって、控えめな速度で送信を開始し、かつ、輻輳ウインドウのサイズを閾値ＣＷＴＨまで増大させることによって送信速度を増大させるであろう。
【０１４２】
ブロック１２５０において送信状態がスロースタートに設定されていない場合、マイクロプロセッサー２０２はブロック１２５８へと向かうように指示され、該ブロック１２５８では、マイクロプロセッサーは、送信状態が輻輳回避に設定されているか否かを判定するように指示される。送信状態が輻輳回避に設定されている場合、ブロック１２５８はマイクロプロセッサー２０２にブロック１２６０へと向かうように指示する。ブロック１２６０において、マイクロプロセッサー２０２は、それぞれの確認されるデータパケットについて分数ｋ／ＣＷ（式中、ｋは、１、２、３などである整数値を有してもよい）だけ輻輳ウインドウＣＷのサイズを増大させるように指示される。用語ｋ／ＣＷは概して、十進法の値と同等であり、かつ、輻輳ウインドウＣＷのサイズのいっそうゆっくりとした増加をもたらすであろう。輻輳ウインドウのサイズはデータパケットの整数として表されるので、輻輳ウインドウのサイズは、連続するわずかな増大が、別のデータパケットが輻輳ウインドウのサイズに追加されることを引き起こすまで増えるときに増大するのみであろう。輻輳回避状態下では、輻輳ウインドウはしたがって、ゆっくりとした速度でサイズを増大させるのみである。マイクロプロセッサー２０２はその後、ブロック１２２２へと戻っ
て次のエンド−トゥー−エンドＡＣＫを待つように指示される。
【０１４３】
ブロック１２５８において送信状態が輻輳回避に設定されていない場合、現在の送信状態はファストリカバリーであり、かつ、マイクロプロセッサー２０２はブロック１２６２へと向かうように指示され、該ブロック１２６２では、輻輳ウインドウは輻輳ウインドウ閾値サイズＣＷＴＨに設定される。マイクロプロセッサー２０２はその後、ブロック１２２２へと戻って次のエンド−トゥー−エンドＡＣＫを待つように指示される。ブロック１２５０〜１２５６はしたがって、行先デバイス７０において受け取られているデータパケットの成功裡の確認が存在するときに輻輳ウインドウのサイズを増大させ、このことは、メッシュネットワーク１００がエンド−トゥー−エンド送信リンクを確立させ、かつ、まだ渋滞していないことを示す。
【０１４４】
ブロック１２２８において、同一のシーケンス番号を有する１つより多いエンド−トゥー−エンドＡＣＫがソースデバイス３００において受け取られるとき、ＸＡＣＫカウンターは上記されたように増大し、かつ、マイクロプロセッサー２０２は、ネットワーク輻輳プロセススレッド１２４０のブロック１２４２へと向かうように指示される。ブロック１２４２は、マイクロプロセッサー２０２に、現在の送信状態がスロースタートまたは輻輳回避である（この場合、プロセスは１２４４において続く）か否かを判定するように指示する。ブロック１２４４は、マイクロプロセッサーに、ＸＡＣＫカウンターがＡＣＫＭＡＸ閾値（１つの実施形態では、３に設定されてもよい）に到達したか否かを判定するように指示する。ブロック１２４６はその後、マイクロプロセッサー２０２に、送信状態をファストリカバリーに設定するように指示する。スロースタートまたは輻輳回避送信状態にあるとき、ソースデバイスはしたがって、行先デバイス７０２によって予測されるデータパケットを再送信する前に待機する。ブロック１２４２においてＸＡＣＫカウンターがまだＡＣＫＭＡＸ閾値に到達していない場合、マイクロプロセッサー２０２はブロック１２２２へと戻って次のエンド−トゥー−エンドＡＣＫを待つように指示される。
【０１４５】
ブロック１２４２においてマイクロプロセッサー２０２が、送信状態が既にファストリカバリーに設定されていると判定する場合、マイクロプロセッサーはブロック１２４８へと向かうように指示され、該ブロック１２４８では、輻輳ウインドウＣＷのサイズは単一のデータパケットだけ増大する。この場合、送信が失敗したいくつかのデータパケットが存在する一方で、概してデータパケットは行先デバイスにまだ到達しており、かつ、輻輳ウインドウに対するこの控えめな増加は問題となるべきではないことが想定される。
【０１４６】
ソースデバイス３００はまた、再送信プロセススレッド１２７０を実行し、該再送信プロセススレッド１２７０は、エンド−トゥー−エンドタイマーをモニタリングして、送信キュー３３２のヘッドに現在あるデータパケットについてタイムアウトが生じたか否かを判定するためのものである。ブロック１２７２においてデータパケット中のタイムスタンプフィールド１３３０が予め決められた閾値時間を越える場合、マイクロプロセッサー２０２はブロック１２７２へと向かうように指示され、該ブロック１２７２では、エンド−トゥー−エンドＡＣＫシーケンス番号に対応するデータパケットが再送信される。エンド−トゥー−エンドタイムアウトタイマーはまた、再送の時間に基づいて再起動され、かつ、データパケット中のタイムスタンプフィールド１３３０は適宜アップデートされる。
【０１４７】
ブロック１２７４はその後、マイクロプロセッサー２０２に、輻輳ウインドウＣＷのサイズを単一のデータパケットに再設定するように指示する。輻輳ウインドウ閾値サイズＣＷＴＨはまた、輻輳ウインドウの現在の半分に設定され、かつ、ＸＡＣＫカウンターはゼロに再設定される。なぜなら、エンド−トゥー−エンドＡＣＫにおける予測されるパケットが再送信されたからである。 
【０１４８】
送信優先順位
図１１Ｂに戻ると、１つの実施形態において、優先順位送信がシングル−ホップ送信プロセススレッド１１４０に実施されてもよい。ブロック１１５０において、リンクキュー３３８のヘッドからのデータパケットを単に処理するよりはむしろ、マイクロプロセッサー２０２は、特定のタイプのデータパケットの送信を優先させるように指示されてもよい。大量のコンテンツデータが渋滞したメッシュネットワーク１００を通じて送信されているとき、通常送信シーケンスでハンドリングされるコンテンツは、エンド−トゥー−エンドＡＣＫおよびシングル−ホップＡＣＫパケットが遅延することを引き起こすであろう。これらの確認データパケットの遅延は、パケットが行先において実際に受け取られ、かつ、エンド−トゥー−エンドＡＣＫにおいて確認されたときにソースデバイスによるデータパケットの再送信をもたらすか、または、シングル−ホップＡＣＫが遅延するときに無線リンクによる再送信試行をもたらすであろう。上記で参照した米国仮特許出願第６２／３４３，０５６号（参照によってその全体が本明細書に組み込まれる）に記載のその他の制御メッセージ（ＨＥＬＬＯ、ＪＯＩＮ、ＬＥＡＶＥなど）がメッシュネットワーク１００の確立に関し、かつ、これらのメッセージの遅延がネットワークの効率的な拡張を妨げ、したがって輻輳をさらに増大させる。１つの実施形態では、ブロック１１５０は、マイクロプロセッサー２０２に、優先度順に各無線リンクキュー２６２におけるデータパケットを処理するように指示してもよい。例えば、最も高い優先順位が制御パケットの確認に割り当てられ、かつ、次の優先順位が制御パケット自体に割り当てられてもよい。いっそう低い優先順位がエンド−トゥー−エンドおよびシングル−ホップＡＣＫデータパケットに割り当てられてもよい。最も低い優先順位が、コンテンツデータパケットに割り当てられてもよい。この代替的な実施形態では、ブロック１１５０はしたがって、マイクロプロセッサー２０２に、割り当てられた優先順位にしたがってリンク送信キューを空にするように指示する。その他の実施形態では、異なるタイプのコンテンツデータフローが異なる優先順位を割り当てられ得る。
【０１４９】
マルチキャスト送信
図１３には、マルチキャストデータ送信プロセスの実施形態が示されている。マルチキャストデータ送信プロセスは、ソースデバイス（図７におけるデバイス３００のような）から多数の行先デバイスへの送信を伴い、かつ、１つ以上のルーティングデバイス（デバイス７００のような）をさらに伴ってもよい。
【０１５０】
図１３Ａを参照すると、マルチキャストグループに登録するためにデバイスによって実行される登録プロセスが１３４０において示されており、かつ、デバイスのユーザーがマルチキャストグループに参加するためのリクエストを開始するときにブロック１３４２において始まる。１つの実施形態では、マルチキャストグループは、アプリケーション３０２、３０４、７０４および７１０のうちの１つに関連付けられてもよく、かつ、マルチキャストグループに参加するためのユーザーからのリクエストは、アプリケーション内で受け取られ、かつ、登録リクエストをハンドリングするＡＰＩへの呼び出しとしてメッシュサービス３１０へと送信されてもよい。各グループは、グループＩＤによって識別される。ブロック１３４４はその後、ソースデバイスのマイクロプロセッサー２０２に、グループが既に登録されていたか否かを判定するように指示する。デバイスがメッシュネットワーク１００上で発見されるので、これらはルーティングテーブルロケーション２６４へと追加され、かつ、これらのデバイスが登録されているグループＩＤがルーティングテーブルにおけるデバイスに関連付けられる。グループが既に登録されていた場合、ユーザーが登録を希望するグループＩＤと一致するグループＩＤを有するデバイスについて、ルーティングテーブル２６４に少なくとも１つのエントリーが存在する。一致するグループＩＤがルーティングテーブルロケーション２６４に既に存在する場合、マイクロプロセッサーはブロック１３４６へと向かうように指示され、該ブロック１３４６では、マイクロプロセッサーは、グループが先行して登録されていることについてユーザーに警告を発するよ
うに指示する。
【０１５１】
一致するグループＩＤがブロック１３４４においてルーティングテーブルロケーション２６４に未だに存在しない場合、マイクロプロセッサーはブロック１３４８へと向かうように指示される。ブロック１３４８は、マイクロプロセッサー２０２に、デバイス上で登録されているマルチキャストグループのリストにグループＩＤを追加するように指示する。ブロック１３５０はその後、マイクロプロセッサー２０２に、メッシュネットワーク１００上の標的デバイスであって、それに対してマルチキャストにも登録されているメッシュネットワーク上のデバイスのリストを受け取るようにとのリクエストが送られる前記標的デバイスを判定するように指示する。標的デバイスは典型的には、ネットワークを通じたシングルホップによってソースデバイスから分離される、メッシュネットワーク１００上のデバイスであり、該標的デバイスは、ソースデバイスが接続される、マスターモードにあるアクセスポイントデバイスのようなものである。
【０１５２】
ブロック１３５２はその後、マイクロプロセッサー２０２に、適用可能なグループＩＤとともにデバイスのリストを含むリクエストを生成するように指示する。リストは、ソースデバイスおよび登録されているグループＩＤ、ならびに、ソースデバイスによってメッシュネットワーク１００を通じて到達可能であるが、標的デバイスを介さないその他のデバイスのリストを含むべきである。リクエストは、各デバイスについての登録済みのグループＩＤの追加を伴うＨＥＬＬＯまたはＪＯＩＮリクエスト（概して上記されたような）の形式をとってもよい。ブロック１３５４はその後、マイクロプロセッサー２０２に、リクエストを標的デバイスへと送信するように指示する。プロセス１３４０はブロック１３５６において続き、該ブロック１３５６は、ソースデバイス３００のマイクロプロセッサー２０２に、標的デバイスから確認（ＡＣＫ）が受け取られたか否かを判定するように指示する。いかなるＡＣＫも受け取られていない場合、マイクロプロセッサー２０２はブロック１３５６へと戻るように指示され、かつ、プロセス１３４０は、効果的に一時停止してＡＣＫを待つ。
【０１５３】
１３７０において、標的デバイスによって実行される登録応答プロセスが示されており、かつ、リクエストがメッシュネットワーク１００上の別のデバイスから標的デバイスにおいて受け取られるときに、ブロック１３７２において開始される。ブロック１３７４は、標的デバイスのマイクロプロセッサー２０２に、リクエストメッセージにおけるリストを読み取り、かつ、ルーティングテーブルロケーション２６４をアップデートしてリクエストメッセージに含まれるソースデバイスおよびその他のデバイスについてグループＩＤを追加するように指示する。標的デバイスはしたがって、リクエストメッセージが受け取られる度に、ルーティングテーブルロケーション２６４におけるそのルーティングテーブルをアップデートする。
【０１５４】
ブロック１３７８はその後、マイクロプロセッサー２０２に、標的デバイスから到達可能なデバイスのリストを、それらの各々の登録済みグループＩＤとともに生成するように指示する。リクエストを発したソースデバイスは、リストから除外される。ブロック１３７６はまた、マイクロプロセッサー２０２に、到達可能なデバイスのリストを含む確認（ＨＥＬＬＯ／ＪＯＩＮ  ＡＣＫ）を生成するように指示する。プロセス１３７０はその後、ブロック１３７８において続き、該ブロック１３７８は、標的デバイスのマイクロプロセッサー２０２に、リクエストを発したソースデバイスへと戻るように確認を送信するように指示する。
【０１５５】
プロセス１３４０は、ＡＣＫが標的デバイスから受け取られるときにブロック１３５６において続き、かつ、ソースデバイスのマイクロプロセッサー２０２はブロック１３５８へと向かうように指示される。ブロック１３５８は、マイクロプロセッサー２０２に、ソ
ースデバイス上のルーティングテーブルロケーション２６４におけるルーティングテーブルをアップデートして、メッシュネットワーク１００上のデバイスによって登録されているマルチキャストグループを識別するグループＩＤを含むように指示する。
【０１５６】
図１３には１３８０において、ソースデバイス３００のようなデバイス上で実行される登録解除プロセスもまた示されている。登録解除プロセス１３８０は、ソースデバイス３００のユーザーがマルチキャストグループの登録を解除するためのリクエストを行うときに開始される。ブロック１３８４はその後、ソースデバイスのマイクロプロセッサー２０２に、グループが登録されている（この場合、ブロック１３８６は、マイクロプロセッサーに、デバイスによって登録されているグループＩＤのリストからマルチキャストグループを除去するように指示する）か否かを判定するように指示する。いかなる一致するグループＩＤもルーティングテーブルロケーション２６４に存在しない場合、マイクロプロセッサーはブロック１３４８へと向かうように指示され、該ブロック１３４８では、マイクロプロセッサーは、グループが現在登録されていないことについてユーザーに警告を発するように指示される。
【０１５７】
ネットワークを構築するのに用いられるサーバーまたはルーターインフラストラクチャーによって維持される従来のマルチキャストグループとは対照的に、メッシュネットワーク１００は、マルチキャストグループ情報についての中央リポジトリーを必ずしも有さない。マルチキャストグループ情報は、したがって、図１３に示されているマルチキャストデータ送信プロセスにしたがってメッシュネットワーク１００全体にばらまかれ、かつ、共有されなければならない。
【０１５８】
図１３Ｂには１４００において、マルチキャスト送信プロセスが示されており、アプリケーション３０２、３０４、７０４および７１０のうちの１つが、特定のグループＩＤに対応するマルチキャストグループへのコンテンツデータの送信をリクエストするときにブロック１４０２において始まる。アプリケーションとメッシュサービス３１０との間のコンテンツデータの送信は概して、ｕｕｉｄによってコンテンツデータについての行先を識別するよりはむしろ、行先がグループＩＤによって識別されることを除いて、図４に示されているアプリケーションイベントハンドリングプロセス８００のブロック８１６〜８２４にしたがって進行する。グループＩＤは、ｅマルチキャストグループ送信に関連付けられているものとしてメッシュサービス３１０によって識別可能な特有のフォーマットを有する数字であってもよい。コンテンツデータは、メッシュサービス３１０によって受け取られ、かつ、図１０Ａに示されているメッシュサービスプロセス１０００のブロック１０４６〜１０５６にしたがって処理される。
【０１５９】
ブロック１４０４は、マイクロプロセッサー２０２に、メモリー２１０のルーティングテーブルロケーション２６４におけるデバイスおよび関連グループｉｄのリストを読み取り、メッシュネットワーク１００上のどのデバイスがグループＩＤに対応するマルチキャストグループに登録されているかを判定するように指示する。これらのデバイスは、マルチキャスト標的デバイスとして言及されるであろう。ブロック１４０４はまた、マイクロプロセッサー２０２に、リストが空である（すなわち、いかなるマルチキャスト標的デバイスもデバイスに接続されたままではない）（この場合、マイクロプロセッサーは、ブロック１４０２へと戻ってマルチキャスト送信についての次のリクエストを待つように指示される）か否かを判定するように指示する。
【０１６０】
ブロック１４０６はその後、マイクロプロセッサー２０２に、グループＩＤに対応するマルチキャストメッシュアドレスを検索するように指示する。この実施形態では、メッシュネットワーク１００上の一群のアドレスが、ネットワーク上のいかなる物理的デバイスにも割り当てられず、かつ、マルチキャストメッシュ送信に用いられるのみである。マル
チキャストメッシュアドレスはしたがって、特定のアドレスパターンを有してもよく、かつ、マルチキャストグループ送信のために手配済みである広範なネットワークアドレスから配分されてもよい。ブロック１４０６はまた、マイクロプロセッサー２０２に、メッシュネットワーク１００を通じた送信のためにデータをデータパケットへと書き込むように指示する。データパケットは概して、図１３に示されているＵＤＰデータパケット１３００に対応してもよく、ここで、送信デバイスのアドレスがソース＿ｕｕｉｄフィールド１３０８に書き込まれ、かつ、マルチキャストメッシュアドレスが行先＿ｕｕｉｄフィールド１３１２に書き込まれる。
【０１６１】
マルチキャスト送信プロセス１４００はその後、ブロック１４０８において続き、該ブロック１４０８では、マイクロプロセッサー２０２は、ブロック１４０４において識別された各マルチキャスト標的デバイスについてネクスト−ホップを判定するように指示される。各マルチキャスト標的デバイスは、ルーティングテーブルロケーション２６４にネクスト−ホップエントリーを有するべきであり、該ネクストホップエントリーは、ネットワーク上の転送デバイスであって、それを通してマルチキャスト標的デバイスが到達され得る前記転送デバイスを識別するか、または、マルチキャスト標的デバイスがネクスト−ホップである場合にはデバイス自体を識別するかのいずれかである。転送デバイスはマルチキャスト標的デバイスでなくてもよく、したがって、マルチキャストパケットをマルチキャスト標的デバイスへと転送することに関係があるのみであってもよい。いくつかの場合には、マルチキャスト標的デバイスへの転送デバイスとして識別される多数のデバイスが存在してもよい。ブロック１４０８はしたがって、マイクロプロセッサー２０２に、マルチキャスト標的デバイスへのマルチキャスト送信のためのマルチキャスト転送デバイスとして作用し得るネクスト−ホップデバイスのセットを生成するように指示する。 
【０１６２】
ブロック１４１０はその後、マイクロプロセッサー２０２に、インターネットプロトコル（ＩＰ）マルチキャスト転送によって到達可能なマルチキャスト転送デバイスのセットに２つ以上の転送デバイスが存在するか否かを判定するように指示する。各マルチキャスト標的デバイスについてのネクスト−ホップ転送デバイスはソースデバイスに隣接するデバイスであるので、ルーティングテーブルは、送信に利用可能である適用可能な無線リンク（単数）またはリンク（複数）を識別するエントリーを含有するであろう。送信デバイスがアクセスポイントまたはマスターモードにあるＷｉ−ＦｉまたはＷｉ−Ｆｉダイレクトデバイスである場合であって、かつ、ブロック１４１０においてマイクロプロセッサー２０２が、メッシュネットワーク１００を通じてアクセス可能な２つ以上のＷｉ−ＦｉまたはＷｉ−Ｆｉダイレクトクライアントモード転送デバイスが存在すると判定する場合、プロセスはブロック１４１２において続く。これらの条件下では、２つ以上のクライアントモード転送デバイスは、データパケットのＩＰマルチキャスト転送を通して到達可能であろう。
【０１６３】
ブロック１４１２はその後、マイクロプロセッサー２０２に、データパケットをＩＰマルチキャストパケットへとカプセル化するように指示する。ＩＰマルチキャストパケットはその後、無線リンクキューロケーション２６２における適用可能なキュー３３８または３４０に書き込まれ、かつ、送信は、データパケットがＩＰマルチキャストプロトコルパケットとして送信されることを除いて、図１１Ｂに示されているシングル−ホップ送信プロセススレッド１１４０のブロック１１４２〜１１５４に概して記載されたように続く。しかしながら、マルチキャスト送信は、いかなる形式ののエンド−トゥー−エンド確認も実施しなくてもよい。なぜなら、このことは、メッシュネットワーク１００上のさらなる輻輳に繋がるからである。むしろ、マルチキャスト送信は、ベストエフォート送信にしたがってもよい。
【０１６４】
ブロック１４１４はその後、マイクロプロセッサー２０２に、マルチキャスト転送デバ
イスのセットからインターネットプロトコル（ＩＰ）マルチキャスト転送によって到達可能なデバイスを除去するように指示する。なぜなら、それらのデバイスへの送信が完了したと考えられるからである。ブロック１４１４はその後、マイクロプロセッサー２０２にブロック１４１６へと戻るように指示し、該ブロック１４１６は、マイクロプロセッサー２０２に、任意のマルチキャスト転送デバイスがセットに残っているか否かを判定するように指示する。いかなるマルチキャスト転送デバイスもセットに残っていない場合、ブロック１４１６は、マイクロプロセッサー２０２にブロック１４０２へと戻って次のマルチキャスト送信を待つように指示する。
【０１６５】
ブロック１４１６においてマルチキャスト転送デバイスセットにさらなるデバイスが残っている場合、これらはユニキャスト送信によってアクセス可能であるのみであろうし、かつ、マイクロプロセッサーはブロック１４１８へと向かうように指示される。ブロック１４１８は、マイクロプロセッサー２０２に、セットにおける残りのマルチキャスト転送デバイスについてデータパケットのユニキャスト送信を実行するように指示する。データパケットはしたがって、無線リンクキューロケーション２６２におけるリンクキュー（すなわち、Ｂｌｕｅｔｏｏｔｈリンクキュー３４２）に書き込まれ、かつ、送信は、図１１Ｂに示されているプロセスシングル−ホップ送信プロセススレッド１１４０にしたがって進行する。ブロック１４１８はその後、マイクロプロセッサー２０２にブロック１４０２へと戻って次のマルチキャスト送信を待つように指示する。
【０１６６】
ブロック１４１０において、インターネットプロトコル（ＩＰ）マルチキャスト転送によって到達可能なマルチキャスト転送デバイスのセットに単一もしくは転送デバイスが存在するか、いかなる転送デバイスも存在しないかのいずれかの場合、マイクロプロセッサーはブロック１４１８へと向かうように指示され、該ブロック１４１８では、マイクロプロセッサー２０２は、残りのマルチキャスト転送デバイスについてデータパケットのユニキャスト送信を実行するように指示される。
【０１６７】
メッシュネットワーク１００上のマルチキャストグループへのデータパケットの送信はしたがって、ソースデバイスにおいて利用可能である最も効率的なプロトコルにしたがって実行される。ＩＰマルチキャストプロトコルの使用は、このプロトコルをサポートする無線リンクのための処理を簡略化する。
【０１６８】
図１３Ｃには１４４０においてマルチキャスト転送プロセスが示されており、かつ、図１１Ｃに示されているエンド−トゥー−エンド確認プロセススレッド１１６０のブロック１１６４および１１６６の間に挿入されてもよい。プロセスはしたがって、メッシュネットワーク１００上の任意のデバイスにおいてデータパケットが受け取られるときにブロック１１６２（図１１Ｃ）において始まる。ブロック１１６４は、上記のように、受け取りデバイスのマイクロプロセッサー２０２に、データパケットが受け取られたことを確認するデータパケットを送信したデバイスへと戻るようにシングル−ホップＡＣＫを送信するように指示する。ブロック１１６４はまた、マイクロプロセッサー２０２に、データパケットの行先＿ｕｕｉｄフィールド１３１２を読み取るように指示する。
【０１６９】
マルチキャスト転送プロセス１４４０のブロック１４４２はその後、マイクロプロセッサー２０２に、データパケットの行先＿ｕｕｉｄフィールド１３１２におけるアドレスが、メッシュネットワーク１００を通じたマルチキャスト送信のために手配済みである広範なアドレスに対応するか否かを判定するように指示する。データパケット中のアドレスがマルチキャストアドレスではない場合、ブロック１１４２は、マイクロプロセッサー２０２にエンド−トゥ−エンド確認プロセススレッド１１６０のブロック１１６６へと戻るように指示し、かつ、データパケットのユニキャスト処理が上記のように進行する。データパケット中のアドレスがマルチキャストアドレスである場合、ブロック１１４２は、マイ
クロプロセッサー２０２にブロック１１４４へと向かうように指示し、該ブロック１１４４は、マイクロプロセッサーに、特定のマルチキャストデータパケットが先行して受け取られていたか否かを判定するように指示する。マルチキャスト送信については、同一のデータパケットが２つの異なるマルチキャスト転送デバイスから受け取られる可能性が存在し、かつ、この場合、ブロック１１４４は、マイクロプロセッサー２０２にエンド−トゥ−エンド確認プロセススレッド１１６０のブロック１１６２へと戻って次のデータパケットの受け取りを待つように指示する。
【０１７０】
ブロック１４４４においてマルチキャストデータパケットがマルチキャスト転送デバイスにおいて先行して受け取られていない場合、プロセスはブロック１４４６において続く。ブロック１４４６は、マイクロプロセッサー２０２に、マルチキャストメッシュアドレスを用いてルーティングテーブルロケーション２６４における対応するグループＩＤを検索するように指示する。ブロック１４４８はその後、マイクロプロセッサー２０２に、デバイスがブロック１４４６において判定されたグループＩＤに対応するマルチキャストグループに登録されているか否かを判定するように指示する。デバイスがマルチキャストグループに登録されている場合、ブロック１１４８は、マイクロプロセッサー２０２に、ブロック１４４８へと戻って、概して図１０Ａに示されているメッシュサービスプロセス１０００のブロック１００６〜１０１２にしたがってコンテンツデータを処理し、かつ、適用可能なアプリケーションへとデータを送達するように指示する。
【０１７１】
ブロック１４４８においてデバイスがマルチキャストグループに登録されていない場合、マイクロプロセッサー２０２はブロック１４５２へと向かうように指示される。ブロック１４５２〜１４６４は、図１３Ｂに示されているマルチキャスト送信プロセス１４００のブロック１４０４および１４０８〜１４１８と同一であり、かつ、マルチキャストデータパケットが、メッシュネットワーク１００を通じてマルチキャスト標的デバイスへとさらに伝播されることを引き起こす。ブロック１１６４の実行に続いて、マイクロプロセッサー２０２は、エンド−トゥ−エンド確認プロセススレッド１１６０のブロック１１６２へと戻って次のデータパケットの受け取りを待つように指示される。
【０１７２】
マルチキャスト転送プロセス１４４０はしたがって、マルチキャストメッシュアドレスに関連付けられるマルチキャストに登録されている場合に、マルチキャストデータパケットがデバイスへと送達されることを引き起こす。マルチキャスト転送プロセス１４４０はまた、ブロック１４５２において登録されているデバイスのリストに見出される任意のエントリーが存在する場合に、マルチキャストデータパケットがネクスト−ホップデバイス上へと転送されることを引き起こす。デバイスがメッシュネットワーク１００の特定の分岐上の最後のマルチキャスト標的デバイスである場合、いかなる転送も必要ではない。図１３に示されているマルチキャストプロセスはしたがって、データパケットの不要な送信を回避しながら、多数のデバイスへのデータコンテンツの伝播を促進する。隣接するデバイスの間の無線リンクについてのシングル−ホップ送信スレッド１１４０を実施することとは別に、プロセスは信頼性の高くないデータ移送に基づいて実行される。
【０１７３】
ブロードキャスト送信
ブロードキャスト送信は、メッシュネットワーク１００上のすべてのデバイスがブロードキャスト標的デバイスであると考えられることを除いて、マルチキャスト送信と同様である。ブロードキャスト送信データパケットはまた、広範な手配済みのマルチキャストアドレスにおける１つよりはむしろ、単一のブロードキャストメッシュアドレスに標的が定められる。１つの実施形態では、かかるアドレスは、「１」に設定されるアドレスのすべてのビットを有して設定されてもよい。循環するブロードキャストデータパケットでメッシュネットワーク１００を溢れさせることを回避するために、図１２に示されているパケットデータパケット１３００は、生存時間（ＴＴＬ）フィールドを含むように適合しても
よい。ＴＴＬ時間が到達されるときはしたがって、デバイスによるデータパケットのさらなる転送は存在しない。メッシュネットワーク１００上のすべてのデバイスがブロードキャストに「登録」されているので、図１３Ａに示されているプロセス１３４０および１３７０は関連がなく、したがって、ブロードキャストトラフィックのために省略される。プロセス１４００および１４４０は、マルチキャスト送信の場合のようにグループＩＤに基づいて転送デバイスを判定するよりはむしろ、すべての既知のデバイスが転送デバイスとして考慮されるように修正される。ソースデバイスはしたがって、すべての既知のデバイスを見出し、かつ、すべてのこれらのデバイスに繋がるネクストホップについてルーティングテーブルロケーション２６４の中を見る。これらの転送デバイスへの送信は、図１３Ｂに示されているプロセス１４００のブロック１４１０〜１４１８と同様の様式で進行する。
【０１７４】
各ブロードキャスト転送デバイスは、ブロードキャストデータパケットが先行して受け取られていたか否かを判定し、かつ、受け取られていない場合、デバイス上の関連アプリケーションへの送達のために、または、メッシュネットワーク１００を通じてその他のブロードキャスト標的デバイスへと転送するために、データコンテンツを処理する。ブロードキャスト送信は、ソースアドレスおよびメッシュポートｉｄを含む、ブロードキャストフローＩＤによって識別されてもよい。図１１に示されている信頼性の高いデータ送信プロセスの場合のように、ブロードキャスト送信におけるデータパケットの順番を識別するのに、固有のシーケンス番号が用いられてもよい。デバイスは、各ブロードキャスト送信について最後に受け取られたシーケンス番号を追跡して、データパケットが二重に受け取られるか否かを判定し、かつ、同一のデータパケットの二重の転送を回避する。
【０１７５】
特定の実施形態が記載され、かつ、示された一方で、かかる実施形態は、本発明の実例としてのみ考慮されるべきであり、かつ、添付の請求の範囲にしたがって解釈される本発明を限定するものとして考慮されるべきではない。
【図１】
2020532251.tif 000003
【図２】
2020532251.tif 000004
【図３】
2020532251.tif 000005
【図４】
2020532251.tif 000006
【図５】
2020532251.tif 000007
【図６】
2020532251.tif 000008
【図７】
2020532251.tif 000009
【図８Ａ】
2020532251.tif 000010
【図８Ｂ】
2020532251.tif 000011
【図９】
2020532251.tif 000012
【図１０Ａ】
2020532251.tif 000013
【図１０Ｂ】
2020532251.tif 000014
【図１１Ａ】
2020532251.tif 000015
【図１１Ｂ】
2020532251.tif 000016
【図１１Ｃ】
2020532251.tif 000017
【図１１Ｄ】
2020532251.tif 000018
【図１１Ｅ】
2020532251.tif 000019
【図１２】
2020532251.tif 000020
【図１３Ａ】
2020532251.tif 000021
【図１３Ｂ】
2020532251.tif 000022
【図１３Ｃ】
2020532251.tif 000023
【国際調査報告】
2020532251.tif 000024
2020532251.tif 000025