JP5204115B2 - ピアの協調ネットワーキングを使用する異種ネットワーク内のデータ回復 - Google Patents

Description

本発明は、ネットワーキングに関し、特にマルチキャストデータの損失（ロス）の回復に関する。

インフラストラクチャベース／セルラワイヤレスネットワーク（たとえば、３Ｇセルラネットワーク、ＷｉＭａｘ、ＷＬＡＮ、またはＤｉｇｉｔａｌ Ｖｉｄｅｏ Ｂｒｏａｄｃａｓｔｉｎｇ（ＤＶＢ））上のマルチキャスト／ブロードキャストでは、データは、基地局／アクセスポイント／中央局／ホスト／サーバから複数のレシーバ／ワイヤレスデバイスに送信される。本明細書では、「／」が使用される場合に、その「／」は、同一のコンポーネントまたはデバイスの代替の名前または説明を与えることが意図されている。すなわち、「／」は、単語「または」として意図されている。各レシーバへの個別の同一データの複数のユニキャストセッションと比較して、マルチキャストは、特にワイヤレスメディアの共有される性質（データを、送信側の通信範囲内の全てのレシーバによって同時に受信できる）のおかげで、ワイヤレスネットワーク内で複数のデバイスにデータを配布するためのネットワーク能力を大幅に高める。しかし、ワイヤレスリンクは信頼できず、複数のレシーバが異種のチャネル条件を経験するので、複数のマルチキャスト／ブロードキャストレシーバの受信信頼性を保証することは難しい。ＤＶＢおよび３Ｇマルチメディアブロードキャスト／マルチキャストサービス（ＭＢＭＳ）などの多数のネットワーク内のマルチキャスト／ブロードキャストサービスは、レシーバが失われたデータパケットの再送信をリクエストするための逆通信チャネルを提供しない。さらに、ラジオリソース／帯域幅は、一般に、配備が高コストでありスペクトルが免許制である場合があるので、インフラストラクチャベースのネットワークでは一般に高価である。したがって、ラジオリソースを効率的に利用しながら複数のレシーバに関するマルチキャストサービスの良い品質をサポートし、インフラストラクチャベース／セルラワイヤレスネットワークのスループットおよびカバレージを改善することが、主要で難易度の高いタスクである。

多くのワイヤレスマルチキャスト／ブロードキャストシステムでは、フォワードエラーコレクションコード（ＦＥＣ）が、物理レイヤでパケット内で使用されて、マルチパスフェージングおよび干渉に対して保護し、パケットエラーを減らす。ワイヤレスネットワーク内で失われたパケットを回復するために、ＦＥＣコードは、トランスポートレイヤおよびアプリケーションレイヤでも複数のパケットにまたがって適用される。しかし、ワイヤレスチャネル条件は、時間変動し、マルチキャスト環境内の複数のレシーバは、異種のチャネル条件を経験する。従来技術では、ＦＥＣコードは、ワーストチャネル条件に従って、所望のサービスエリア内の全レシーバの受信品質を保証するのに使用される。これは、大きいオーバーヘッドをもたらし、インフラストラクチャベースのマルチキャストネットワーク内で大量のラジオリソースを必要とする。信頼性およびスループットを改善するもう１つの従来技術の技法は、複数のアンテナを使用することである。しかし、この手法は、基地局およびワイヤレスデバイスを含むワイヤレスシステムへの高いコストおよび複雑さをこうむる。

最近、アドホックネットワークの助けを得てセルラネットワークの品質、スループット、およびカバレージを改善する取り組みがあった。最近報告されたシステムでは、基地局との良好なリンク品質を有する移動局が、基地局との悪いリンク品質を有する局のリレーとして働く。このシステムでは、単一のワイヤレスインターフェースが、リレーモードとインフラストラクチャモードとの両方に使用される。したがって、このハイブリッドモードネットワークで達成されるトータルセルスループットは、使用可能なセルラ帯域幅によって上限を定められる。最近報告されたもう１つのシステムでは、２タイプのワイヤレスインターフェースが、セルラネットワークおよびアドホックネットワークを一体化するのに使用され、ここで、アドホックモードの高帯域幅ワイヤレスチャネル（ＩＥＥＥ ８０２．１１）は、セルラスループットおよびカバレージエリアを改善するためにセルラネットワーク（３Ｇ）のユニキャストトラフィックをリレーする。最近報告されたもう１つのシステムでは、マルチキャストデータが、短い範囲にわたってセルラネットワーク（３Ｇ）内でリレーノードに送信され、次に、リレーノードによって高速アドホックネットワーク（ＩＥＥＥ ８０２．１１）を介して残りのサブスクライブするノードに転送される。上の手法の全ては、セルラネットワークおよびアドホックネットワークが単一のワイヤレスインターフェースまたは２種類のワイヤレスインターフェースのいずれを使用する場合であっても、アドホックネットワークを介してデスティネーションノードにセルラトラフィックを転送するのにリレーノードを使用する。ダウンリンクデータは、基地局からリレーノードに送信され、その後、アドホックネットワーク内で単一ホップパスまたはマルチホップパスを介してデスティネーションノードに転送される。アップリンクデータ（存在する場合に）は、逆のパスを通って進む。すなわち、デスティネーションノードは、必ず、アドホックネットワークパス内のリレーノードを介してデータを受信し、または送信する。上の手法では、リレーノードは、必ずデスティネーションノードを助ける。ノード／ワイヤレスデバイスの間の協調はない。これは、リレーノードにとって公平ではない。リレーノードは、はるかにより多くのＣＰＵパワーおよびバッテリエネルギ（リレーノードがバッテリ動作する場合）を消費する。リレーノード周辺の帯域幅などのアドホックネットワークリソースの要件も高いが、アドホックネットワークの他の部分のネットワークリソースがアイドルのままである可能性がある。

本発明によって解決される問題は、ワイヤレスネットワーク上の高品質マルチキャスト／ブロードキャストサービスについてパケットロスに対する回復力があり、インフラストラクチャベースのワイヤレスネットワークのスループット、品質、およびカバレージ範囲を改善するシステムを設計する方法である。したがって、本発明は、上記の問題を解決する。

本発明は、アシスタント／セカンダリ／コンプリメンタリ／アドホックネットワークを使用するマルチキャストデータの回復の方法である。ワイヤレスデバイスは、マルチキャストデータを受信するためにプリンシパルネットワーク（たとえば、セルラネットワーク）に接続される。これらのワイヤレスデバイスの一部（ピア）は、セカンダリリカバリネットワークを形成する。一部のマルチキャストデータは、ワイヤレスデバイスまでに失われる場合がある。すなわち、１つまたは複数のマルチキャストデバイスが、マルチキャストデータの一部を受信しない場合がある。データが失われるかエラーを有する場合があり、あるいは、ワイヤレスデバイスが、マルチキャストデータが送信された時に良好な信号を有していなかった場合がある。一部のワイヤレスデバイスが、その空間ダイバーシティおよびチャネル不均一性に起因して、プリンシパルネットワークから同一のマルチキャストデータ（パケット）を正しく受信している場合がある。ワイヤレスデバイスは、セカンダリネットワークを介して協調的に、そのピア（マルチキャストデータを正しく受信したワイヤレスデバイス）から、その失われたマルチキャストデータを回復する。したがって、本発明の方法は、失われたマルチキャストパケットを回復するために空間ダイバーシティおよびピア（ワイヤレスデバイス／ワイヤレスレシーバ）の協調を利用することによって、かかわる全てのピアについて、マルチキャスト信頼性およびサービス品質を改善する。本発明の方法はまた、プリンシパルネットワークのカバレージを広げる。

少なくとも１つのデバイスを用いてセカンダリリカバリネットワークを確立することと、データロスを検出することと、セカンダリリカバリネットワークを介して少なくとも１つのデバイスから失われたデータを回復することであって、少なくとも１つのデバイスは、データを正しく受信済みである、回復することとを含む、データを回復する方法および装置を説明する。この場合に、ワイヤレスデバイスは、データを失っている。データを受信することと、少なくとも１つのデバイスを用いてセカンダリリカバリネットワークを確立することと、前記セカンダリリカバリネットワークを介して失われたデータを回復することとを含む、データを回復する方法および装置も説明する。この場合に、ワイヤレスデバイスは、データを正しく受信しており、失われたデータを回復するために、失われたデータを有するワイヤレスデバイスを協調的に助けている。

本発明は、添付図面と共に読まれるときに次の詳細な説明から最もよく理解される。図面は、下で簡潔に説明する次の図を含む。

本発明の原理によるプリンシパルネットワークおよびセカンダリネットワークのシステムレベルアーキテクチャを示す概略図である。 本発明の原理によるプリンシパルネットワークおよびフラットリカバリネットワークの代替のシステムレベルアーキテクチャ実施形態を示す概略図である。 本発明の原理によるプリンシパルネットワークおよび階層リカバリネットワークの代替のシステムレベルアーキテクチャ実施形態を示す概略図である。 本発明によるパートナーシップ形成方法を示すラダー図である。 本発明によるパートナーシップを形成するリクエストを送信する方法を示す流れ図である。 本発明によるパートナーシップリクエストメッセージを処理する方法を示す流れ図である。 本発明によるパートナーシップ応答メッセージを処理する方法を示す流れ図である。 本発明によるパートナーシップアクノリッジメントメッセージを処理する方法を示す流れ図である。 本発明によるパートナーシップ維持方法を示すラダー図である。 本発明による失われたパケットの回復方法を示すラダー図である。 本発明による代替実施形態の失われたパケットの回復方法を示すラダー図である。 本発明によるワイヤレスデバイスを示すブロック図である。

図１を参照すると、図１は、本発明の原理によるプリンシパルネットワークおよびセカンダリネットワークのシステムレベルアーキテクチャの概略図である。２つのワイヤレスネットワークすなわち、プリンシパル／プライマリ／メイン／バックホール（ｂａｃｋｈａｕｌ）ネットワーク１１０と、アドホック／アシスタント／セカンダリ／サプリメンタリ／／リカバリ／コンプリメンタリネットワーク１１５とがある。この２つのネットワークは、同時に存在する。プリンシパルネットワークは、基地局／アクセスポイント１０５を有するインフラストラクチャベース／セルラワイヤレスネットワーク、たとえば３Ｇセルラネットワーク、ＷｉＭａｘ、ＷｉＦｉ、またはＤＶＢネットワークである。セル／携帯電話１２０、ラップトップ機１２５、ＰＤＡ １３０、および他のモバイルデバイス１３５などのワイヤレスデバイスは、プリンシパルネットワーク１１０を介して基地局／アクセスポイント／サーバ１０５からマルチキャストデータを受信する。ワイヤレスデバイスはまた、セカンダリネットワーク１１５を形成する。セカンダリネットワーク１１５は、ピアツーピアアーキテクチャのデバイスによって形成されるアドホック／メッシュ／セカンダリ／協調ネットワークとすることができる。一例として、セカンダリネットワーク１１５のラジオインターフェースを、ＩＥＥＥ ８０２．１１ ＷｉＦｉおよびＷｉＭａｘとすることができる。プリンシパルネットワーク１１０は、ダウンリンクマルチキャスト／ブロードキャストサービス、たとえば、ビデオ／オーディオストリーミング、ビデオ／オーディオオンデマンド、および他のマルチメディアサービスを基地局／アクセスポイント／ホスト／サーバ１０５からデバイスに供給する。セカンダリネットワーク１１５は、失われたパケットを回復することによって、プリンシパルネットワーク１１０によって提供されるマルチキャストサービスの品質および伝送信頼性を改善する。

ワイヤレス／モバイルデバイス（たとえば、ラップトップ機、携帯情報端末（ＰＤＡ）、デュアルモード電話機）は、両方のネットワークのコンポーネント／メンバである。本発明では、ワイヤレスデバイスは、２つの物理ラジオインターフェースを備える。一方のインターフェースは、バックホール／プリンシパルネットワークに接続され、基地局／アクセスポイントからダウンストリームマルチキャストデータを受信する責任を負う。他方のインターフェースは、セカンダリネットワークに接続され、セカンダリネットワークを介してピアから協調的にプリンシパルネットワークの失われたデータパケットを回復するのに使用される。

プリンシパルネットワークおよびセカンダリネットワークが同一のラジオテクノロジ、たとえばＩＥＥＥ ８０２．１１を使用する場合に、ワイヤレスデバイスは、単一の物理インターフェースを使用することができる。この単一の物理インターフェースは、２つの論理インターフェースに分割／分離することができ、その一方は、プリンシパルネットワークにアクセスし、他方はセカンダリネットワークにアクセスする。

ワイヤレスデバイスは、そのバックホールインターフェース（プリンシパルネットワークへのインターフェース）を介してマルチキャストデータを受信する。ワイヤレスデバイスは、そのセカンダリインターフェースを介してアドホック／メッシュ／協調／セカンダリネットワークを形成し、協調して、セカンダリネットワークを介してピアから失われたマルチキャストデータパケットを回復する。マルチキャストデータパケットは、ワイヤレスデバイスまでに失われるが、他のワイヤレスデバイスによって、その空間ダイバーシティおよびチャネル不均一性に起因して正しく受信される場合がある。あるワイヤレスデバイスが、そのバックホールインターフェースを介していくつかのマルチキャストデータパケットを失った場合に、そのワイヤレスデバイスは、それらの失われたパケットをそのセカンダリインターフェースを介してピアから回復する。１つまたは複数のピアが、他のピアに失われたパケットを提供するリカバリプロキシとして働く。このようにして、全てのピアのマルチキャストサービスの受信品質が、協調して改善される。

ワイヤレスデバイスは、パケットヘッダ内のパケットシーケンス番号に従って、プリンシパルネットワークから受信したセッションのマルチキャストデータパケットロスを検出することができる。あるワイヤレスデバイスが、そのプリンシパルインターフェースからのセッションのあるマルチキャストデータパケットを受信しない場合に、そのワイヤレスデバイスは、本発明の原理に従って、同一のプリンシパルネットワーク内のピアから形成されるセカンダリネットワークを介してそのパートナー（ピア）からこのセッションの失われたデータパケットを回復しようとする。

代替実施形態では、専用リカバリサーバ／プロキシが配備される。これらのリカバリサーバ／プロキシは、一方はプリンシパルネットワーク用、他方はアシスタント／サプリメンタリネットワークへの参加に使用される、２つの物理／論理ラジオインターフェースをも備える。専用プロキシは、プリンシパルネットワークからマルチキャストデータパケットを受信し、失われたパケットをセカンダリネットワークを介して他のピアに供給する。専用プロキシが、プリンシパルネットワークから全ての必要なデータパケットを受信しない場合がある。図２を参照すると、２つのワイヤレスネットワークすなわち、プリンシパル／プライマリ／メイン／バックホールネットワーク２１０およびフラットリカバリネットワーク２１５がある。フラットリカバリネットワークは、セカンダリリカバリネットワーク内のレシーバであり、それ自体のどの種類のネットワークにおいてもより高いレベルにはない、リカバリサーバ／プロキシを使用するセカンダリリカバリネットワークの形態である。すなわち、リカバリサーバ／プロキシは、ティアも階層も有しない。セカンダリリカバリネットワークの階層ネットワーク形式については、以下で図３に関して説明する。この２つのネットワークは、同時に存在する。プリンシパルネットワークは、基地局／アクセスポイント２０５を有するインフラストラクチャベース／セルラワイヤレスネットワーク、たとえば３Ｇセルラネットワーク、ＷｉＭａｘ、ＷｉＦｉ、またはＤＶＢネットワークである。セル／携帯電話２２０、ラップトップ機２２５、ＰＤＡ ２３０、専用リカバリプロキシ／サーバ２４０、および他のモバイルデバイス２３５などのワイヤレスデバイスは、プリンシパルネットワーク２１０を介して基地局／アクセスポイント／サーバ２０５からマルチキャストデータを受信する。ワイヤレスデバイスはまた、セカンダリネットワーク２１５を形成する。セカンダリネットワーク２１５は、ピアツーピアアーキテクチャのデバイスによって形成されるフラットリカバリネットワークである。図２に示されているように、専用プロキシは、ワイヤレスクライアントデバイスを有するフラットリカバリ／サプリメンタリネットワークを形成する。フラットサプリメンタリネットワーク内では、プロキシまたはワイヤレスクライアントデバイスは、プロキシを介してまたはフラットサプリメンタリネットワーク内の他のワイヤレスデバイスを介して、それ自体の失われたパケットを回復する。

代替実施形態では、階層サプリメンタリネットワークを、プロキシおよびワイヤレスデバイスによって形成することも可能である。図３を参照すると、２つのワイヤレスネットワークすなわち、プリンシパル／プライマリ／メイン／バックホールネットワーク３１０および階層リカバリネットワーク３１５がある。この２つのネットワークは、同時に存在する。プリンシパルネットワークは、基地局／アクセスポイント３０５を有するインフラストラクチャベース／セルラワイヤレスネットワーク、たとえば３Ｇセルラネットワーク、ＷｉＭａｘ、ＷｉＦｉ、またはＤＶＢネットワークである。セル／携帯電話３２０、ラップトップ機２２５、ＰＤＡ ３３０、専用リカバリプロキシ３４０、および他のモバイルデバイス３３５などのワイヤレスデバイスは、プリンシパルネットワーク３１０を介して基地局／アクセスポイント／サーバ３０５からマルチキャストデータを受信する。ワイヤレスデバイスはまた、セカンダリネットワーク３１５を形成する。セカンダリネットワーク３１５は、ピアツーピアアーキテクチャのデバイスによって形成される階層リカバリネットワークである。階層サプリメンタリネットワークでは、プロキシ３４０は、それ自体の失われたパケットを他のプロキシを介して回復する。ワイヤレスクライアントデバイスは、１つまたは複数のリカバリプロキシからその失われたパケットを回復する。

失われたパケットをそのピアから回復するために、ワイヤレスデバイスは、セカンダリネットワークを介してピアとの協調パートナーシップを発見し、確立し、維持する必要がある。パケットを失ったか受信しなかったワイヤレスデバイスは、失われたパケットを検出し、リクエストし、さらに、ピアから失われたパケットを回復する必要もある。

本発明では、パートナーシップの発見、確立、および維持のためのコントロールの機構およびプロシージャを説明する。失われたパケットを検出し、リクエストし、回復する方法およびプロシージャも説明する。

図４を参照すると、ワイヤレスデバイスは、他のピアとのパートナーシップを発見し確立することを必要とすると判定した場合に、そのセカンダリネットワークインターフェースを介してマルチキャスト／ブロードキャストでパートナーシップ／ピアリクエストメッセージ（ＰＲＥＱ）を送信する。一例として、ＰＲＥＱメッセージは、ソースアドレス、デスティネーションアドレス、ＰＲＥＱメッセージＩＤ、協調回復のセッションＩＤ、有効期限（ＴＴＬ）などを含む。ソースアドレスは、ＰＲＥＱオリジネータの、そのセカンダリネットワークインターフェースのＩＰ（レイヤ３）アドレスまたはＭＡＣ（レイヤ２）アドレスである。デスティネーションアドレスは、セカンダリネットワークでのこのメッセージのＩＰまたはＭＡＣマルチキャスト／ブロードキャストデスティネーションアドレスである。タイムトゥリブフィールドは、このＰＲＥＱメッセージがセカンダリネットワーク内で伝搬するホップ数を示す。協調回復のセッションＩＤは、ＰＲＥＱオリジネータがセカンダリネットワーク上でピア（またはリカバリプロキシ）の協調を介して、その失われたパケットを回復することを望む、プリンシパルネットワーク内のマルチキャストセッションを識別する。一例として、これを、そのパケットが属するセッションを識別する、プリンシパルネットワーク内のセッションのマルチキャストデータパケットのソースおよびデスティネーションのＩＰアドレスおよびＵＤＰ／ＴＣＰポートとすることができる。プリンシパルネットワーク内のセッションのマルチキャストデータパケットのＭＡＣ（レイヤ２）アドレスを使用することもできる。これを、パケットがプリンシパルネットワーク内で属するセッションを識別する、マルチキャストデータパケット内で搬送される他のＩＤ（たとえば、Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ Ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ Ｓｏｕｒｃｅ ＩＤ）とすることができる。

ワイヤレスデバイスは、そのセカンダリネットワークインターフェース上でＰＲＥＱメッセージを受信するときに、リクエストされたセッションのＰＲＥＱオリジネータのパートナー候補になる。この判断は、ＰＲＥＱレシーバのポリシに基づいてＰＲＥＱレシーバによって行うことができる。たとえば、このポリシは、ＰＲＥＱレシーバが十分な処理能力、バッテリ電力、およびセカンダリネットワーク内の帯域幅を有するかどうか、ＰＲＥＱレシーバがそれ自体の使用のためにプリンシパルネットワークから同一セッションを受信しつつあるかどうか、あるいは単に、失われたパケットを他のピアに供給するためのリカバリプロキシとして働くために、プリンシパルネットワークからリクエストされたセッションを受信するのに十分な処理能力、バッテリ電力、良好なチャネル品質、および帯域幅を有するかどうかに依存するものとすることができる。ＰＲＥＱレシーバは、ＰＲＥＱメッセージ内のＴＴＬフィールドを、その値を１つ減らすことによって更新する。ＴＴＬフィールドの更新された値が０より大きい場合には、ＰＲＥＱレシーバは、そのＰＲＥＱメッセージをセカンダリネットワーク内の隣接物に転送／ブロードキャストする。ＴＴＬフィールドの更新された値が０になる場合には、ＰＲＥＱレシーバは、そのＰＲＥＱメッセージを破棄する。

さらに、ＰＲＥＱレシーバは、ＰＲＥＱメッセージ内で指定されるセッションの失われたパケットの回復に関してＰＲＥＱオリジネータのパートナー候補になることを望む場合に、パートナーシップ／ピア応答（ＰＲＥＰ）メッセージをユニキャストでＰＲＥＱオリジネータに送信する。ＰＲＥＱレシーバは、パートナになることを望まない場合にはＰＲＥＰを送信しない。一例として、ＰＲＥＰメッセージは、ソースアドレス、デスティネーションアドレス、オリジナルＰＲＥＱメッセージＩＤ、ＰＲＥＰメッセージＩＤ、セッションＩＤなどを含む。ソースアドレスは、ＰＲＥＱに応答するデバイスのアドレスであり、デスティネーションアドレスは、ＰＲＥＱオリジネータのアドレス、すなわちＰＲＥＰメッセージが宛てられたアドレスである。ＰＲＥＱレシーバは、ＰＲＥＱメッセージ内で指定されるセッションの失われたパケットの回復に関するＰＲＥＱオリジネータとのパートナーシップを既に確立している場合に、このＰＲＥＱメッセージを無視する。

ＰＲＥＱオリジネータ、すなわちＰＲＥＰデスティネーションデバイスが、ＰＲＥＰオリジネータが潜在的なパートナーシップ候補であることのＰＲＥＰメッセージをＰＲＥＰオリジネータから受信した後に、ＰＲＥＱオリジネータは、このＰＲＥＰオリジネータとのパートナーシップを形成するかどうかを判断する。ＰＲＥＱオリジネータは、このパートナーシップを承認しまたは拒否するために、パートナーシップ／ピアアクノリッジメント（ＰＡＣＫ）メッセージをユニキャストでＰＲＥＰオリジネータに送信する。一例として、ＰＡＣＫメッセージは、レイヤ２またはレイヤ３のソースアドレスおよびデスティネーションアドレス、オリジナルＰＲＥＰメッセージＩＤ、ＰＡＣＫメッセージＩＤ、セッションＩＤ、アクノリッジフラグおよび確認フラグなどを含むことができる。アクノリッジフラグは、このＰＡＣＫが肯定のアクノリッジ（ＰＡＣＫデスティネーション、すなわちＰＲＥＰオリジネータがＰＡＣＫ（ＰＲＥＱ）オリジネータによってパートナとして選択される）または否定のアクノリッジ（ＰＡＣＫデスティネーションはパートナとして選択されない）のどちらであるのかを示す。確認フラグは、ＰＡＣＫデスティネーションがパートナーシップ／ピア確認（ＰＣＯＭ）メッセージを送り返すことを要求されるかどうかを示す。

ＰＲＥＰデスティネーションがＰＲＥＰオリジネータからＰＲＥＰメッセージを受信した後に、ＰＲＥＰデスティネーションは、このＰＲＥＰオリジネータとのパートナーシップを形成することを望む場合に、肯定のアクノリッジメントフラグを伴うＰＡＣＫをこのＰＲＥＰオリジネータに送信する。ＰＲＥＰは、このＰＲＥＰオリジネータとのパートナーシップを形成することを望まない場合に、否定のアクノリッジフラグを伴うＰＡＣＫをこのＰＲＥＰオリジネータに送信することができ、あるいは、このＰＲＥＰオリジネータにＰＡＣＫメッセージを送信しないものとすることができる。

ＰＡＣＫデスティネーションデバイスは、ＰＡＣＫメッセージを受信した後に、確認フラグがＰＡＣＫメッセージ内でセットされている場合にはパートナーシップ／ピア確認（ＰＣＯＭ）メッセージをユニキャストでＰＡＣＫオリジネータに送信する。一例として、ＰＣＯＭメッセージは、ＰＣＯＭメッセージのレイヤ２またはレイヤ３のソースアドレスおよびデスティネーションアドレス、オリジナルＰＡＣＫメッセージＩＤ、ＰＣＯＭメッセージＩＤ、セッションＩＤなどを含む。このＰＣＯＭメッセージは、下位レイヤトランスポートプロトコルが信頼できるエンドツーエンドトランスポート機構を有しない（たとえば、ＵＤＰ）場合に使用される。下位レイヤがトランスポート信頼性を提供しない場合に、ＰＡＣＫオリジネータは、それが送信する肯定ＰＡＣＫメッセージ内の確認フラグをセットすることができる。下位レイヤが信頼できるトランスポート機構を提供する（たとえば、ＴＣＰ）場合には、下位レイヤに頼ってＰＡＣＫメッセージを成功裏に配送することができる。ＰＡＣＫ内の確認フラグをセットしないものとすることができる。ＰＣＯＭメッセージは、確認フラグがＰＡＣＫ内でセットされていない場合には送信されない。これらのメッセージが成功裏に交換された後に、ＰＡＣＫのオリジネータとＰＡＣＫのデスティネーションとの間のパートナーシップが確立される。パートナーシップが確立された後に、セカンダリネットワーク上でピアからセッションの失われたパケットを回復するために、両方のピアが、プリンシパルインターフェースから受信される指定されたセッションのデータパケットをキャッシングする。

上で説明したコントロールメッセージの全てが、リカバリ／セカンダリネットワーク内で送信される。ワイヤレスデバイスが、セカンダリネットワーク内の異なるパスを介してマルチキャスト／ブロードキャストで伝搬される同一のＰＲＥＱメッセージの複数のコピーを受信する場合があることに留意されたい。デバイスは、ＰＲＥＱメッセージの最初のコピーを伝搬させるだけである。デバイスは、特定のセッションについてＰＲＥＱオリジネータのパートナ候補になると判断する場合に、ＰＲＥＰメッセージを用いてＰＲＥＱメッセージの最初のコピーに応答する。

上記のコントロールメッセージが失われる場合がある。ＰＲＥＱを送信した後に、ワイヤレスデバイスは、ＰＲＥＰを待つ。ＰＲＥＰが、ＰＲＥＱ＿ＲＥＴＲＩＥＳ＿ＩＮＴＥＲＶＡＬ以内に受信されない場合、または受信されたＰＲＥＰオリジネータの個数（すなわち、パートナ候補の個数）が所望のパートナ数より少ない場合に、ワイヤレスデバイスは、１つまたは複数のパートナを発見するためにセカンダリネットワーク内でもう１つのＰＲＥＱを送信することをもう一度トライすることができる。ワイヤレスデバイスは、リトライごとにＰＲＥＱメッセージＩＤをインクリメントし、更新する。ワイヤレスデバイスは、最初のＰＲＥＱメッセージでＴＴＬ＿ＳＴＡＲＴの値を用いて開始し、ＴＴＬ値がＴＴＬ＿ＭＡＸＩＭＵＭに達するまで、リトライごとにＰＲＥＱメッセージ内のＴＴＬ値をＴＴＬ＿ＩＮＣＲＥＭＥＮＴだけ増やすことができる。ＰＲＥＱメッセージ内の最大のＴＴＬ値を、ＴＴＬ＿ＭＡＸＩＭＵＭとすることができ、これは、セカンダリネットワークサイズの推定された値である。ワイヤレスデバイスは、ＴＴＬ値がＰＲＥＱメッセージ内でＴＴＬ＿ＭＡＸＩＭＵＭに達した後に最大でＰＲＥＱ＿ＲＥＴＲＩＥＳ＿ＬＩＭＩＴ回までトライすることができる。

ＰＡＣＫオリジネータは、確認フラグをセットされたＰＡＣＫメッセージを送信した後に、ＰＣＯＭを待つ。ＰＡＣＫオリジネータは、ＰＣＯＭがＰＡＣＫ＿ＲＥＴＲＩＥＳ＿ＩＮＴＥＲＶＡＬ以内に受信されない場合に、セカンダリネットワーク内で新しいＰＡＣＫメッセージＩＤを有するＰＡＣＫメッセージを再送信することができる。メッセージＩＤは、リトライごとにＰＡＣＫメッセージ内でインクリメントされ、更新される。ＰＡＣＫオリジネータは、期待されるＰＣＯＭメッセージが受信されない場合に、最大でＰＡＣＫ＿ＲＥＴＲＩＥＳ＿ＬＩＭＩＴ回までＰＡＣＫメッセージを再送信することができる。

ＰＲＥＱ＿ＲＥＴＲＩＥＳ＿ＩＮＴＥＲＶＡＬ、ＰＲＥＱ＿ＲＥＴＲＩＥＳ＿ＬＩＭＩＴ、ＴＴＬ＿ＳＴＡＲＴ、ＴＴＬ＿ＩＮＣＲＥＭＥＮＴ、ＴＴＬ＿ＭＡＸＩＭＵＭ、ＰＡＣＫ＿ＲＥＴＲＩＥＳ＿ＩＮＴＥＲＶＡＬ、およびＰＡＣＫ＿ＲＥＴＲＩＥＳ＿ＬＩＭＩＴは、ワイヤレスデバイス側で構成される。

ワイヤレスデバイスは、１つのセッションを回復するために１つまたは複数のパートナーとの協調パートナーシップを確立することができる。パートナの個数が、所望のパートナ数より少ない場合には、ワイヤレスデバイスは、上記の方法を周期的に使用することによってより多くのパートナを発見し、確立することをトライすることができる。パートナの所望の個数は、ワイヤレスデバイス側で構成することができる。新しいパートナを発見する周期も、ワイヤレスデバイス側で構成される。パートナーシップ内の全てのピアは、他方のピアにパートナーシップ終了（ＰＴＥＲ）メッセージを送信することによってパートナーシップを終了することができる。

流れ図４つの図は、図４のラダー図によるＰＲＥＱ／ＰＡＣＫオリジネータおよびＰＲＥＰ／ＰＣＯＭＭオリジネータでの動作を詳細に示す。各ケースで、流れ図は、「停止」で終了する。これは、動作の完全な終了ではなく、プロセス全体のうちの特定の部分の完了を示すことを意図されたものである。プロセスの特定の部分の完了は、サスペンド状態またはウェイト状態が実施されていることを示す場合がある。

図５は、パートナーシップを形成するリクエストを送信する方法の流れ図である。５０５で、パートナーシップリクエストメッセージを生成し、ピア／リカバリサーバ／リカバリプロキシに送信して、セカンダリネットワークを形成し、その結果、ワイヤレスデバイス／リクエスタが、失われたまたは誤って受信されたデータ／パケットを回復できるようにする。５１０で、ＴＴＬに初期値（ＴＴＬ＿ＳＴＡＲＴ）をセットし、ＰＲＥＱを生成し、送信する。５１５で、リトライカウントを初期化する。５１８で、ウェイトタイマ（ＰＲＥＱ＿ｗａｉｔ−ｔｉｍｅｒ）をセットする。５２０でテストを実行して、パートナーシップを形成するリクエストのウェイトタイマ（ＰＲＥＱ＿ｗａｉｔ−ｔｉｍｅｒ）が満了したかどうかを判定する。ＰＲＥＱ＿ｗａｉｔ＿ｔｉｍｅｒが満了していない場合には、５２０でのテストが、ＰＲＥＱ＿ｗａｉｔ＿ｔｉｍｅｒが満了するまで実行され続ける。ＰＲＥＱ＿ｗａｉｔ＿ｔｉｍｅｒが満了した場合には、５２５でテストを実行して、応答（ＰＲＥＰ）が受信されていないか否か、または所望の個数未満の潜在的パートナー（ピア／リカバリサーバ／リカバリプロキシ）候補が応答したか否かを判定する。所望の個数のパートナが応答した（ＰＲＥＰが受信された）場合には、このプロセスは５６０に進み、リカバリプロセスは進行することができる。所望の個数の潜在的パートナが応答していない場合には、５３０でテストを実行して、ＴＴＬ（ＰＲＥＱ＿ＴＴＬ）が最大ＴＴＬ（ＴＴＬ＿ＭＡＸＩＭＵＭ）未満であるかどうかを判定する。ＰＲＥＱ＿ＴＴＬが最大ＴＴＬ未満ではない場合には、５３５でテストを実行して、ＰＲＥＱリトライカウント（ＰＲＥＱ＿ｒｅｔｒｙ＿ｃｏｕｎｔ）がＰＲＥＱリトライリミット（ＰＲＥＱ＿ＲＥＴＲＹ＿ＬＩＭＩＴ）を超えるかどうかを判定する。ＰＲＥＱリトライカウントがＰＲＥＱ＿ＲＥＴＲＹ＿ＬＩＭＩＴを超える場合には、リトライカウントを超えているので、このプロセスは５６０に進み、このプロセスは終了する。ＰＲＥＱリトライカウントがＰＲＥＱ＿ＲＥＴＲＹ＿ＬＩＭＩＴ未満である場合には、ＰＲＥＱリトライカウント（ＰＲＥＱ＿ｒｅｔｒｙ＿ｃｏｕｎｔ）を、ＰＲＥＱ＿ＩＤと同様に（１つ）インクリメントする。次に、このプロセスは５５０に進み、ここで、パートナーシップリクエスト（ＰＲＥＱ）を再送信する。ＰＲＥＱ ＴＴＬがＴＴＬ最大値未満である場合には、５４５で、ＰＲＥＱ ＴＴＬをＴＴＬ＿ＩＮＣＲＥＭＥＮＴだけインクリメントし、ＰＲＥＱ＿ＩＤを１つ増やす。次に、このプロセスは５５０に進み、ここで、パートナーシップリクエスト（ＰＲＥＱ）を再送信する。

図６は、パートナーシップリクエストメッセージを処理する方法の流れ図である。図６の流れ図によってカバーされる機能性は、パートナーシップを形成するリクエストに応答する潜在的なパートナー／ピア／リカバリサーバ／リカバリプロキシによって実行される。潜在的なパートナーは、まず、６０５でテストを行って、このパートナーシップリクエスト（ＰＲＥＱ）を前に受信したかどうかを判定する。潜在的パートナーは、このＰＲＥＱを前に受信していない場合に、６１０で、ワイヤレスデバイス／リクエスタのパートナーになりたいまたはなることができるかどうかと、パートナーシップが指定されたセッションについてまだ存在しないこととを判定する。潜在的パートナーが、ワイヤレスデバイス／リクエスタとのパートナーシップを形成することを望み、形成することができ、指定されたセッションがまだ存在しない場合には、潜在的パートナーは、６１５で、パートナーシップリクエスト応答（ＰＲＥＰ）を生成し、ＰＲＥＱオリジネータに送信する。次に、このプロセスは６２０に進み、ここで、ＰＲＥＱ ＴＴＬを（１つ）デクリメントする。潜在的パートナーが、ワイヤレスデバイス／リクエスタとのパートナーシップを形成することを望まないか、または形成することができず、あるいは指定されたセッションが既に存在する場合には、６２０でＰＲＥＱ ＴＴＬを（１つ）デクリメントする。ＰＲＥＱは、他の潜在的パートナに転送される。次に、このプロセスは、パートナーシップ確立プロセスを継続させるために、６４０に進む。潜在的パートナがこのＰＲＥＱを前に受信したことがある場合には、６３５でＰＲＥＱを破棄する。処理はその後、６４０に進む。

図７は、本発明によるパートナーシップ応答メッセージを処理する方法の流れ図である。図７の流れ図によってカバーされる機能性は、ワイヤレスデバイス／リクエスタ（ＰＲＥＱオリジネータ）によって実行される。この処理は、パートナーシップリクエスト応答（ＰＲＥＰ）の受信に応答するものである。７０５でテストを行って、ＰＲＥＱオリジネータが、ＰＲＥＱリクエスタとのパートナーシップを形成するためのリクエストに対してＰＲＥＰを応答した潜在的パートナーとのパートナーシップを形成することを望むかどうかを判定する。ＰＲＥＱリクエスタが、潜在的パートナーとのパートナーシップを形成することを望む場合には、７１０で、パートナーシップ肯定アクノリッジメントフラグ（ＰＡＣＫ＿ｐｏｓｉｔｉｖｅ＿ａｃｋ＿ｆｌａｇ）を肯定的にセットする。次に、７１５でテストを実行して、パートナーシップ確認が必要であるかどうかを判定する。パートナーシップ確認が必要である場合には、７２０でパートナーシップ確認フラグをセットする（ＰＡＣＫ．ｃｏｎｆｉｒｍａｔｉｏｎ＿ｆｌａｇ）。次に、ＰＲＥＱオリジネータは、７２５で、肯定パートナーシップアクノリッジメント（ＰＡＣＫ）を生成し、ユニキャストで潜在的パートナ（ＰＲＥＰオリジネータ）に送信する。次に、７３０で、パートナーシップリトライカウント（ＰＡＣＫ＿ｒｅｔｒｙ＿ｃｏｕｎｔ）を初期化する。次に、７３５で、パートナーシップアクノリッジメント待ち時間（ＰＡＣＫ＿ｗａｉｔ＿ｔｉｍｅｒ）をセットする。次に、７４０でテストを実行して、パートナーシップ確認（ＰＣＯＭ）が受信されたかどうかを判定する。パートナーシップ確認が受信されていない場合には、７４５でテストを実行して、パートナーシップアクノリッジメント待ち時間（ＰＡＣＫ＿ｗａｉｔ ｔｉｍｅｒ）が満了しているかどうかを判定する。ＰＡＣＫ＿ｗａｉｔ＿ｔｉｍｅｒが満了している場合には、７５０でテストを実行して、パートナーシップリトライカウント（ＰＡＣＫ＿ｒｅｔｒｙ＿ｃｏｕｎｔ）がパートナーシップリトライリミット（ＰＡＣＫ＿ＲＥＴＲＹ＿ＬＩＭＩＴ）より大きいかどうかを判定する。ＰＡＣＫ＿ｒｅｔｒｙ＿ｃｏｕｎｔがＰＡＣＫ＿ＲＥＴＲＹ＿ＬＩＭＩＴより小さい場合には、７５５で、パートナーシップアクノリッジメントｉｄ（ＰＡＣＫ＿ＩＤ）およびＰＡＣＫ＿ｒｅｔｒｙ＿ｃｏｕｎｔを（１つ）インクリメントする。次に、７６０で、パートナーシップアクノリッジメント（ＰＡＣＫ）を再送信する。

ＰＲＥＱリクエスタが、潜在的パートナーとのパートナーシップを形成することを望まない場合には、７６５で、パートナーシップ肯定アクノリッジメントフラグ（ＰＡＣＫ＿ｐｏｓｉｔｉｖｅ＿ａｃｋ＿ｆｌａｇ）をクリアし、パートナーシップ確認フラグ（ＰＡＣＫ＿ｃｏｎｆｉｒｍａｔｉｏｎ＿ｆｌａｇ）をクリアする。次に、ＰＲＥＱリクエスタが、７７０で、否定パートナーシップアクノリッジメントを生成し、ユニキャストで潜在的パートナー／ＰＲＥＰオリジネータに送信する。これは、７９０で、パートナーシップが確立されないことをもたらす。その後、このプロセスは７９５に進む。

パートナーシップ確認が必要でない場合（７１５）には、７７５で、パートナーシップアクノリッジメント確認フラグ（ＰＡＣＫ＿ｃｏｎｆｉｒｍａｔｉｏｎ＿ｆｌａｇ）をクリアする。次に、ＰＲＥＱオリジネータが、７８０で、パートナーシップ肯定アクノリッジメントを生成し、潜在的パートナ（ＰＲＥＰオリジネータ）に送信する。その後、７８５でパートナーシップが確立される。その後、このプロセスは７９５に進む。

パートナーシップアクノリッジメントリトライカウント（ＰＡＣＫ＿ｒｅｔｒｙ＿ｃｏｕｎｔ）が、パートナーシップアクノリッジメントリトライリミット（ＰＡＣＫ＿ＲＥＴＲＹ＿ＬＩＭＩＴ）より大きい場合には、７９０で、パートナーシップが確立されない。

図８は、本発明によるパートナーシップアクノリッジメントメッセージを処理する方法の流れ図である。図８の流れ図によってカバーされる機能性は、潜在的パートナ／ＰＲＥＰオリジネータによって実行される。８０５でテストを実行して、パートナーシップ確認フラグ（ＰＡＣＫ＿ｃｏｎｆｉｒｍａｔｉｏｎ＿ｆｌａｇ）がセットされているかどうかを判定する。ＰＡＣＫ＿ｃｏｎｆｉｒｍａｔｉｏｎ＿ｆｌａｇがセットされている場合には、８１０で、潜在的パートナー／ＰＲＥＰオリジネータが、パートナーシップ確認を生成し、ＰＲＥＱリクエスタ／ＰＡＣＫオリジネータに送信する。その後、８１５で、パートナーシップが確立される。ＰＡＣＫ＿ｃｏｎｆｉｒｍａｔｉｏｎ＿ｆｌａｇがセットされていない場合には、その後、８１５で、パートナーシップが確立される。その後、このプロセスは８２０に進み、ここで、失われたまたは誤って受信されたデータ／パケットの回復が進行する。

図９を参照すると、２つのデバイスの間でパートナーシップが確立された後に、キープアライブ（ＫＡ）メッセージが、パートナーシップを維持するために、ＰＲＥＱオリジネータからピアへユニキャストで、ＫＡ＿ＩＮＴＥＲＶＡＬのインターバルで周期的に送信される。一例として、キープアライブメッセージは、ＫＡメッセージのレイヤ２またはレイヤ３のソースアドレスおよびデスティネーションアドレス、キープアライブメッセージＩＤ、セッションＩＤ、タイムトゥリブ（ＴＴＬ）などを含む。ピアは、ＫＡメッセージが受信された後に、ユニキャストでＫＡ／ＰＲＥＱオリジネータにキープアライブ応答（ＫＡＲ）メッセージを応答する。一例として、ＫＡＲメッセージは、このＫＡＲメッセージのソースおよびデスティネーションのレイヤ２またはレイヤ３のアドレス、オリジナルＫＡメッセージＩＤ、ＫＡＲメッセージＩＤ、セッションＩＤなどを含む。ＫＡＲメッセージが、ＫＡメッセージが送信されてからＫＡＲ＿ＴＩＭＥＯＵＴ以内に受信されない場合。ＰＲＥＱ／ＫＡオリジネータは、新しいＫＡメッセージＩＤを用いてＫＡメッセージを再送信する。ＰＲＥＱ／ＫＡオリジネータは、ＫＡＲメッセージがピアから受信されない場合に、最大でＫＥＥＰ＿ＡＬＩＶＥ＿ＲＥＴＲＩＥＳ＿ＬＩＭＩＴ回だけキープアライブメッセージを再送信することができる。ＫＡＲメッセージが、それでも、再送信の最大回数に達した後にピアから受信されない場合には、ＫＥＥＰ＿ＡＬＩＶＥオリジネータ（すなわち、ＰＲＥＱオリジネータ）は、このピアとのパートナーシップが終了されたと仮定する。ＫＥＥＰ＿ＡＬＩＶＥオリジネータは、上で説明したパートナーシップディスカバリおよび確立プロシージャを使用して置換パートナーを見つけることができる。ＰＲＥＱ／ＫＡオリジネータとの確立されたパートナーシップを有するピアが、ＫＥＥＰ＿ＡＬＩＶＥ＿ＬＩＭＩＴのタイムインターバルの間にＰＲＥＱ／ＫＡオリジネータからキープアライブメッセージを受信しなかった場合には、そのピアは、そのＰＲＥＱ／ＫＡオリジネータとのパートナーシップが終了されたと仮定する。ＫＡ＿ＩＮＴＥＲＶＡＬ、ＫＡＲ＿ＴＩＭＥＯＵＴ、ＫＥＥＰ＿ＡＬＩＶＥ＿ＲＥＴＲＩＥＳ＿ＬＩＭＩＴ、およびＫＥＥＰ＿ＡＬＩＶＥ＿ＬＩＭＩＴは、ワイヤレスデバイス側で構成することができる。

図１０を参照すると、失われたパケットの回復方法が示されている。モバイルデバイスは、リカバリリクエスト（ＲＥＣＲ）メッセージをユニキャストで自分のパートナのうちの１つまたは複数に自分のセカンダリ／アシスタント／サプリメンタリネットワークを介して送信する。パートナは、他のワイヤレスデバイス（ピア）または専用リカバリプロキシ／サーバとすることができる。セカンダリネットワークは、サプリメンタリネットワーク、フラットリカバリネットワーク、または階層リカバリネットワークとすることができる。一例として、ＲＥＣＲメッセージは、レイヤ２またはレイヤ３のソースアドレス、レイヤ２またはレイヤ３のデスティネーションアドレス、セッションＩＤ、ＲＥＣＲメッセージＩＤ、リクエストされたパケットのマップまたはリストを含む。リクエストされたパケットのマップまたはリストは、ＲＥＣＲオリジネータがパートナ（１つまたは複数）にリクエストするパケットを識別する。ＲＥＣＲメッセージを受信した後に、パートナは、リクエストされたパケットのどれを提供できるかを判定する。パートナは、回復応答（ＲＥＣＰ）メッセージをＲＥＣＲオリジネータに送信する。一例として、ＲＥＣＰメッセージは、レイヤ２またはレイヤ３のソースアドレスおよびデスティネーションアドレス、セッションＩＤ、オリジナルＲＥＣＲメッセージＩＤ、および提供されるパケットのマップまたはリストを含む。提供されるパケットのマップまたはリストは、このパートナが提供できるパケットを識別する。パートナは、提供されるパケットをもＲＥＣＲオリジネータに提供する。パートナが、リクエストされたパケットの全ては提供することができない場合には、ＲＥＣＲオリジネータは、更新されたパケットリクエストマップまたはリストを伴うＲＥＣＲを１つまたは複数の他のパートナに送信することができる。

図１１を参照すると、代替の回復方法が示されている。あるワイヤレスデバイスが、あるセッションのいくつかのマルチキャストデータパケットをそのプリンシパルインターフェースから受信しない場合に、そのワイヤレスデバイスは、このセッションの失われたデータパケットをそのパートナからそのセカンダリ／アシスタント／サプリメンタリネットワークを介して回復することをトライする。ワイヤレスデバイスは、リカバリリクエスト（ＲＥＣＲ）メッセージをそのパートナのうちの１つまたは複数に送信する。パートナは、他のワイヤレスデバイス（ピア）または専用リカバリプロキシ／サーバとすることができる。セカンダリネットワークは、サプリメンタリネットワーク、フラットリカバリネットワーク、または階層リカバリネットワークとすることができる。一例として、ＲＥＣＲメッセージは、レイヤ２またはレイヤ３のソースアドレス、レイヤ２またはレイヤ３のデスティネーションアドレス、セッションＩＤ、ＲＥＣＲメッセージＩＤ、リクエストされたパケットのマップまたはリストを含む。リクエストされたパケットのマップまたはリストは、ＲＥＣＲオリジネータがパートナ（１つまたは複数）にリクエストするパケットを識別する。ＲＥＣＲメッセージを受信した後に、パートナは、リクエストされたパケットのどれを提供できるかを判定する。パートナは、回復応答（ＲＥＣＰ）メッセージをＲＥＣＲオリジネータに送信する。一例として、ＲＥＣＰメッセージは、レイヤ２またはレイヤ３のソースアドレスおよびデスティネーションアドレス、セッションＩＤ、オリジナルＲＥＣＲメッセージＩＤ、および提供されるパケットのマップまたはリストを含む。提供されるパケットのマップまたはリストは、このパートナが提供できるパケットを識別する。ＲＥＣＲオリジネータは、特定のパートナからのＲＥＣＰメッセージ内の提供されるパケットのマップまたはリストに従って、どの失われたパケットがこのパートナから回復されるかを判定する。複数のパートナが同一パケットを提供できる場合に、ＲＥＣＲオリジネータは、セカンダリネットワーク内のパートナからのパス品質などの他の判断基準に基づいて、このパケットを入手すべきパートナを判定することができる。次に、ＲＥＣＲオリジネータは、ＲＥＣＲオリジネータが失われたパケットまたは失われたパケットのサブセットをそれから受信することを望むパートナに、リカバリアクノリッジメント（ＲＥＣＡ）メッセージを送信する。一例として、ＲＥＣＡメッセージは、レイヤ２またはレイヤ３のソースアドレス、レイヤ２またはレイヤ３のデスティネーションアドレス、セッションＩＤ、ＲＥＣＡメッセージＩＤ、パケットマップまたはリストを含む。パケットマップまたはリストは、このパートナにリクエストされるパケットを識別する。パートナは、リクエストされたパケットをＲＥＣＲオリジネータに送信する。パートナが、リクエストされたパケットの全ては提供できない場合に、ＲＥＣＲオリジネータは、更新されたパケットリクエストマップまたはリストを伴うＲＥＣＲを他のパートナに送信することができる。

図１２を参照すると、ブロック図に、本発明によるワイヤレスデバイス１２００が示されている。ワイヤレスデバイス１２００は、２つの物理／論理インターフェースを有する。プリンシパルインターフェース１２０５は、セッションのマルチキャストデータパケットを基地局／アクセスポイント１２１５から受信するためにプリンシパルネットワーク１２１０と通信する。セカンダリインターフェース１２２０は、セカンダリネットワーク（フラットリカバリネットワーク／階層リカバリネットワーク）１２３０を形成するためにピア／リカバリサーバ／リカバリプロキシ１２２５と通信し、マルチキャストセッションの失われたデータパケットをピア／リカバリサーバ／リカバリプロキシ１２２５からセカンダリネットワーク１２３０を介して回復する。失われたパケット検出モジュール１２３５は、プリンシパルネットワークから受信されたマルチキャストパケットのロスを検出する。キャッシングモジュール１２４０は、データパケットをキャッシングする。パートナーシップコントロールモジュール１２４５は、セカンダリネットワーク１２３０内でピア／リカバリサーバ／リカバリプロキシ１２２５とのパートナーシップを形成する。リカバリモジュール１２５０は、失われたデータパケットをピア／リカバリサーバ／リカバリプロキシ１２２５からセカンダリネットワーク１２３０を介して回復し、回復されたパケットをキャッシュに挿入する。アプリケーション１２５５は、マルチキャストデータパケットを使用するアプリケーションである。

セッションコントローラ１２６０は、モジュールを調整し、したがって、アプリケーション１２５５、キャッシングモジュール１２４０、パートナーシップコントロールモジュール１２４５、リカバリモジュール１２５０、失われたパケット検出モジュール１２３５、セカンダリインターフェースモジュール１２２０、およびプリンシパルインターフェースモジュール１２０５とコントロール通信している。したがって、セカンダリインターフェースは、セカンダリネットワーク１２３０のピア／リカバリサーバ／リカバリプロキシ１２２５、リカバリモジュール１２５０、パートナーシップモジュール１２４５、およびセッションコントローラ１２６０と通信する。プリンシパルインターフェースモジュール１２０５は、プリンシパルネットワーク１２１０の基地局／アクセスポイント１２１５、失われたパケット検出モジュール１２３５、およびセッションコントローラ１２６０と通信する。失われたパケット検出モジュール１２３５は、プリンシパルインターフェースモジュール１２０５、リカバリコントロールモジュール１２５０、キャッシングモジュール１２４０、およびセッションコントローラ１２６０と通信する。リカバリコントロールモジュール１２５０は、セカンダリインターフェースモジュール１２２０、失われたパケット検出モジュール１２３５、パートナーシップコントロールモジュール１２４５、キャッシングモジュール１２４０、およびセッションコントローラ１２６０と通信する。パートナーシップコントロールモジュール１２４５は、リカバリコントロールモジュール１２５０、セカンダリインターフェースモジュール１２２０、およびセッションコントローラ１２６０と通信する。キャッシングモジュール１２４０は、リカバリモジュール１２５０、失われたパケット検出モジュール１２３５、アプリケーション１２５５、およびセッションコントローラ１２６０と通信する。アプリケーションは、キャッシングモジュール１２４０およびセッションコントローラ１２６０と通信する。

もう１つの代替実施形態では、本発明の方法を、プリンシパルネットワーク内のユニキャストセッションのデータパケットを回復するのに使用することもできる。ワイヤレスメディアは、共有されるメディアである。ユニキャストセッションのデータ／パケットが、基地局／アクセスポイントからワイヤレスデバイスへまたはワイヤレスデバイスから基地局／アクセスポイントへプリンシパルネットワーク内で送信される場合に、そのパケット／データは、送信側の通信範囲内の他のデバイスによって立ち聞きされ得る。あるパケットが、ワイヤレスデバイスまでに失われるが、他のワイヤレスデバイスによって、その空間ダイバーシティおよびチャネル不均一性に起因して正しく受信される場合がある。ワイヤレスデバイスは、本発明の方法を使用して、パートナーシップを形成し、セカンダリネットワークを介してお互いからプリンシパルネットワークユニキャストセッションの失われたパケットを協調的に回復することができる。もう１つの実施形態では、基地局／アクセスポイントが、本発明の方法を使用して、セカンダリネットワークの一部になり、ワイヤレスデバイスとのパートナーシップを形成し、セカンダリネットワークを介してプリンシパルネットワークユニキャストセッションの失われたパケットを回復することができる。

本発明を、ハードウェア、ソフトウェア、ファームウェア、特殊目的プロセッサ、またはその組合せで実施できることを理解されたい。好ましくは、本発明は、ハードウェアおよびソフトウェアの組合せとして実施される。さらに、ソフトウェアは、好ましくは、プログラムストレージデバイス上で実体的に実施されるアプリケーションプログラムとして実施される。アプリケーションプログラムを、任意の適切なアーキテクチャを含む機械にアップロードし、その機械によって実行することができる。好ましくは、その機械は、１つまたは複数の中央演算処理装置（ＣＰＵ）、ランダムアクセスメモリ（ＲＡＭ）、および入出力（Ｉ／Ｏ）インターフェース（１つまたは複数）などのハードウェアを有するコンピュータプラットフォーム上で実施される。コンピュータプラットフォームは、オペレーティングシステムおよびマイクロ命令コードも含む。本明細書で説明したさまざまなプロセスおよび機能を、マイクロ命令コードの一部またはオペレーティングシステムを介して実行されるアプリケーションプログラムの一部のいずれか（あるいはその組合せ）とすることができる。さらに、追加のデータストレージデバイスおよび印刷デバイスなど、さまざまな他の周辺デバイスをコンピュータプラットフォームに接続することができる。

さらに、添付図面に示された構成システムコンポーネントおよび方法ステップの一部が、好ましくはソフトウェアで実施されるので、システムコンポーネント（またはプロセスステップ）の間の実際の接続が、本発明がプログラムされる形に応じて異なる場合があることを理解されたい。本明細書の教示を与えられれば、当業者は、本発明のこれらおよび類似する実施例または構成を企図することもできる。

Claims (25)

1. プライマリネットワークでマルチキャストデータまたはブロードキャストデータを回復する方法であって、装置によって実行される前記方法は、
   セカンダリリカバリネットワークのリカバリデバイスとパートナーシップを確立することであって、
   前記セカンダリリカバリネットワークを作成し確立するために、前記リカバリデバイスとの前記パートナーシップを形成するためのリクエストを生成し送信することと、
   前記パートナーシップを形成するために前記リクエストに対するユニキャスト応答を受信することと、
   前記リカバリデバイスとの前記パートナーシップを形成すべきかどうかを判定することと、
   前記パートナーシップを形成すべきである場合に、肯定パートナーシップアクノリッジメントを生成しユニキャストで送信し、前記リカバリデバイスと前記セカンダリリカバリネットワークを作成し確立することと、
   前記パートナーシップを形成すべきでない場合に、否定パートナーシップアクノリッジメントを生成しユニキャストで送信することと、
   をさらに含む、確立することと、
   データ損失を検出することと、
   前記セカンダリリカバリネットワークを介して前記リカバリデバイスから前記損失したデータを回復することと、
   を含む、前記方法。
2. 前記パートナーシップを形成するための前記リクエストは、データがセッション内で損失される場合に回復が行われる前記セッションの表示を含む、請求項１に記載の方法。
3. 前記回復する活動は、
   前記セカンダリリカバリネットワークを形成する前記リカバリデバイスに、データ回復をリクエストするメッセージをユニキャストで送信することと、
   前記リカバリデバイスからデータ回復をリクエストする前記メッセージに対するユニキャスト応答であって、前記リカバリデバイスから入手可能なパケットのリストおよび前記入手可能なパケットを含む応答を受信することと、
   をさらに含む、請求項１に記載の方法。
4. 前記回復する活動は、
   データ回復をリクエストするメッセージを生成し前記セカンダリリカバリネットワークを形成する前記リカバリデバイスにユニキャストで送信することと、
   前記リカバリデバイスからデータ回復をリクエストする前記メッセージに対するユニキャスト応答であって、前記リカバリデバイスから入手可能なパケットのリストを含む応答を受信することと、
   前記応答に対するアクノリッジメントを生成しユニキャストで送信することと、
   前記入手可能なパケットをユニキャストで受信することと、
   をさらに含む、請求項１に記載の方法。
5. 前記セカンダリリカバリネットワーク内の前記リカバリデバイスとの前記パートナーシップを維持することをさらに含み、さらに、前記維持する活動は、
   前記リカバリデバイスとの前記パートナーシップを維持するように設計されたメッセージを周期的に生成しユニキャストで送信することと、
   前記維持メッセージに対するユニキャスト応答を受信することと、
   をさらに含む、請求項１に記載の方法。
6. プライマリネットワークでマルチキャストデータまたはブロードキャストデータを回復させる方法であって、装置によって実行される前記方法は、
   データを受信することと、
   セカンダリリカバリネットワークのワイヤレスデバイスとパートナーシップを確立することであって、
   前記セカンダリリカバリネットワークを作成し確立するために、前記ワイヤレスデバイスとの前記パートナーシップを形成するためのリクエストであって、有効期限が設定されたリクエストを受信することと、
   前記リクエストが以前に受信されたかどうかを判定することと、
   前記リクエストが以前に受信された場合に前記リクエストを破棄することと、
   前記パートナーシップを形成しなければならないかどうかを判定することと、
   前記パートナーシップを形成しなければならない場合に、前記パートナーシップを形成するための前記リクエストに対するパートナーシップ応答を生成しユニキャストで送信することと、
   パートナーシップアクノリッジメントをユニキャストで受信すると、前記ワイヤレスデバイスと前記セカンダリリカバリネットワークを確立することと、
   パートナーシップを形成するための前記リクエストの有効期限が満了していない場合に、パートナーシップを形成するための前記リクエストを隣接するデバイスに転送することと、
   パートナーシップを形成するための前記リクエストの有効期限が満了している場合に、パートナーシップを形成するための前記リクエストを破棄することと、
   をさらに含む、確立することと、
   前記セカンダリリカバリネットワークを介して前記ワイヤレスデバイスによって損失したデータを回復させることと、
   を含む、前記方法。
7. 前記パートナーシップを形成するための前記リクエストは、セッションからの前記損失したデータの表示を含む、請求項６に記載の方法。
8. 前記回復させる活動は、
   データ回復をリクエストするユニキャストメッセージであって、損失したパケットのリストを含むメッセージを前記セカンダリリカバリネットワークを介して前記ワイヤレスデバイスから受信することと、
   データ回復をリクエストする前記メッセージに対するユニキャスト応答であって、前記損失したパケットのうち、提供可能なもののリストを含む応答を生成し前記ワイヤレスデバイスに送信することと、
   前記提供可能なパケットを前記リカバリデバイスに送信することと、
   をさらに含む、請求項６に記載の方法。
9. 前記回復させる活動は、
   データ回復をリクエストするメッセージであって、損失したパケットのリストを含むメッセージをユニキャストで前記セカンダリリカバリネットワークを介して受信することと、
   データ回復をリクエストする前記メッセージに対するユニキャスト応答であって、前記損失したパケットのうち、提供可能なもののリストを含む応答を生成し送信することと、
   前記応答に対するアクノリッジメントであって、損失したパケットのリストを含むアクノリッジメントをユニキャストで受信することと、
   前記提供可能なパケットをユニキャストで送信することと、
   をさらに含む、請求項６に記載の方法。
10. 前記セカンダリリカバリネットワーク内の前記ワイヤレスデバイスとの前記パートナーシップを維持することをさらに含み、前記維持する活動は、
    前記ワイヤレスデバイスとの前記パートナーシップを維持するように設計されたユニキャストメッセージを周期的に受信することと、
    前記維持メッセージに対する応答を生成しユニキャストで送信することと、
    をさらに含む、請求項６に記載の方法。
11. プライマリネットワークでマルチキャストデータまたはブロードキャストデータを回復する装置であって、
    セカンダリリカバリネットワークのリカバリデバイスとパートナーシップを確立する手段であって、前記セカンダリリカバリネットワークの前記リカバリデバイスとのパートナーシップ形成をコントロールするパートナーシップコントロールモジュールをさらに含む、確立する手段と、
    データ損失を検出すると、前記セカンダリリカバリネットワークを介して前記リカバリデバイスから損失したデータを回復する手段と、
    を含み、
    前記パートナーシップコントロールモジュールは、
    前記セカンダリリカバリネットワークを作成し確立するために、前記リカバリデバイスとのパートナーシップを形成するためのリクエストを生成し送信する手段と、
    前記パートナーシップを形成するための前記リクエストに対するユニキャスト応答を受信する手段と、
    前記リカバリデバイスとの前記パートナーシップの形成を形成すべきかどうかを判定する手段と、
    前記パートナーシップを形成すべきである場合に、肯定パートナーシップアクノリッジメントを生成しユニキャストで送信し、前記リカバリデバイスと前記セカンダリリカバリネットワークを作成し確立する手段と、
    前記パートナーシップを形成すべきでない場合に、否定パートナーシップアクノリッジメントを生成しユニキャストで送信する手段と、
    をさらに含み、
    前記装置はワイヤレスデバイスであり、前記リカバリデバイスはプロキシ、リカバリサーバおよびリカバリプロキシのうちの１つである、前記装置。
12. 確立する前記手段および回復する前記手段は、２つの物理ラジオインターフェースを含む前記セカンダリリカバリネットワークの前記リカバリデバイスと通信する、請求項１１に記載の装置。
13. 確立する前記手段および回復する前記手段は、２つの論理ラジオインターフェースを含む前記セカンダリリカバリネットワークの前記リカバリデバイスと通信する、請求項１１に記載の装置。
14. 前記パートナーシップを形成するための前記リクエストは、データがセッション内で損失される場合に回復が行われる前記セッションの表示を含む、請求項１１に記載の装置。
15. 前記回復する手段は、リカバリコントロールモジュールをさらに含み、さらに、前記リカバリコントロールモジュールは、
    前記セカンダリリカバリネットワークを形成する前記リカバリデバイスに、データ回復をリクエストするメッセージをユニキャストで送信する手段と、
    前記リカバリデバイスからデータ回復をリクエストする前記メッセージに対するユニキャスト応答であって、前記リカバリデバイスから入手可能なパケットのリストおよび前記入手可能なパケットを含む応答を受信する手段と、
    を含む、請求項１１に記載の装置。
16. 前記回復する手段は、リカバリコントロールモジュールをさらに含み、さらに、前記リカバリコントロールモジュールは、
    データ回復をリクエストするメッセージを生成し前記セカンダリリカバリネットワークを形成する前記リカバリデバイスにユニキャストで送信する手段と、
    前記リカバリデバイスからデータ回復をリクエストする前記メッセージに対するユニキャスト応答であって、前記リカバリデバイスから入手可能なパケットのリストを含む応答を受信する手段と、
    前記応答に対するアクノリッジメントを生成しユニキャストで送信する手段と、
    前記入手可能なパケットをユニキャストで受信する手段と、
    をさらに含む、請求項１１に記載の装置。
17. 前記セカンダリリカバリネットワーク内の前記リカバリデバイスとの前記パートナーシップを維持する手段をさらに含み、維持する前記手段は、
    前記リカバリデバイスとの前記パートナーシップを維持するように設計されたメッセージを周期的に生成しユニキャストで送信する手段と、
    前記維持メッセージに対するユニキャスト応答を受信する手段と、
    をさらに含む、請求項１１に記載の装置。
18. プライマリネットワークでマルチキャストデータまたはブロードキャストデータを回復させる装置であって、
    セカンダリリカバリネットワークのリカバリデバイスとパートナーシップを確立する手段であって、前記セカンダリリカバリネットワークの前記リカバリデバイスとのパートナーシップ形成をコントロールするパートナーシップコントロールモジュールをさらに含む、確立する手段と、
    前記セカンダリリカバリネットワークを介して前記リカバリデバイスにおいて損失したデータを回復させる手段と、
    を含み、
    前記パートナーシップコントロールモジュールは、さらに、
    前記セカンダリリカバリネットワークを作成し確立するために、前記リカバリデバイスとのパートナーシップを形成するためのリクエストであって、有効期限が設定されたリクエストを受信する手段と、
    前記リクエストが以前に受信されたかどうかを判定する手段と、
    前記リクエストが以前に受信された場合に前記リクエストを破棄する手段と、
    パートナーシップを形成しなければならないかどうかを判定する手段と、
    前記パートナーシップを形成しなければならない場合に、前記パートナーシップを形成するための前記リクエストに対するパートナーシップ応答を生成しユニキャストで送信する手段と、
    パートナーシップアクノリッジメントをユニキャストで受信すると、前記ワイヤレスデバイスと前記セカンダリリカバリネットワークを確立する手段と、
    パートナーシップを形成するための前記リクエストの有効期限が満了していない場合に、パートナーシップを形成するための前記リクエストを隣接するリカバリデバイスに転送する手段と、
    パートナーシップを形成するための前記リクエストの有効期限が満了している場合に、パートナーシップを形成するための前記リクエストを破棄する手段と、
    を含む、前記装置。
19. 前記回復させる手段は、リカバリコントロールモジュールをさらに含み、前記リカバリコントロールモジュールは、
    データ回復をリクエストするユニキャストメッセージであって、損失したパケットのリストを含むメッセージを前記セカンダリリカバリネットワークを形成する前記リカバリデバイスから受信する手段と、
    データ回復をリクエストする前記メッセージに対するユニキャスト応答であって、損失したパケットのうち、提供可能なもののリストを含む応答を生成し送信する手段と、
    前記提供可能なパケットを送信する手段と、
    をさらに含む、請求項１８に記載の装置。
20. 前記回復させる手段は、リカバリコントロールモジュールをさらに含み、前記リカバリコントロールモジュールは、
    データ回復をリクエストするメッセージであって、損失したパケットのリストを含むメッセージをユニキャストで前記セカンダリリカバリネットワークを介して受信する手段と、
    データ回復をリクエストする前記メッセージに対するユニキャスト応答であって、前記損失したパケットのうち、提供可能なもののリストを含む応答を生成し送信する手段と、
    前記応答に対するアクノリッジメントであって、リクエストされる損失したパケットのリストを含むアクノリッジメントをユニキャストで受信する手段と、
    前記提供可能なパケットをユニキャストで送信する手段と、
    をさらに含む、請求項１８に記載の装置。
21. 肯定のユニキャスト確認を送信する手段をさらに含む、請求項１８に記載の装置。
22. 前記セカンダリリカバリネットワーク内の前記リカバリデバイスとの前記パートナーシップを維持する手段をさらに含み、維持する前記手段は、
    前記リカバリデバイスとの前記パートナーシップを維持するように設計されたユニキャストメッセージを周期的に受信する手段と、
    前記維持メッセージに対する応答を生成しユニキャストで送信する手段と、
    をさらに含む、請求項１８に記載の装置。
23. 前記データ損失はプライマリワイヤレスマルチキャストネットワーク内で検出される、請求項１に記載の方法。
24. データを回復させる方法であって、装置によって実行される前記方法は、
    プライマリワイヤレスマルチキャストネットワーク内でデータを受信することと、
    セカンダリリカバリネットワークのリカバリデバイスとパートナーシップを確立することであって、
    前記セカンダリリカバリネットワークを作成し確立するために、前記リカバリデバイスとの前記パートナーシップを形成するためのリクエストを生成し送信することと、
    前記パートナーシップを形成するために前記リクエストに対するユニキャスト応答を受信することと、
    前記リカバリデバイスとの前記パートナーシップを形成すべきかどうかを判定することと、
    前記パートナーシップを形成すべきである場合に、肯定パートナーシップアクノリッジメントを生成しユニキャストで送信し、前記リカバリデバイスと前記セカンダリリカバリネットワークを作成し確立することと、
    前記パートナーシップを形成すべきでない場合に、否定パートナーシップアクノリッジメントを生成しユニキャストで送信することと、
    をさらに含む、確立することと、
    前記セカンダリリカバリネットワークを介して前記リカバリデバイスによって損失したデータを回復させることと、
    を含む、前記方法。
25. データを回復させる装置であって、
    セカンダリリカバリネットワークのリカバリデバイスとパートナーシップを確立する手段であって、前記セカンダリリカバリネットワークの前記リカバリデバイスとのパートナーシップ形成をコントロールするパートナーシップコントロールモジュールを含む、手段と、
    前記セカンダリリカバリネットワークを介してプライマリワイヤレスマルチキャストネットワークから損失したデータを前記リカバリデバイスにおいて回復させる手段と、
    を含み、
    前記パートナーシップコントロールモジュールは、
    前記セカンダリリカバリネットワークを作成し確立するために、前記リカバリデバイスとのパートナーシップを形成するためのリクエストを生成し送信する手段と、
    前記パートナーシップを形成するための前記リクエストに対するユニキャスト応答を受信する手段と、
    前記リカバリデバイスとの前記パートナーシップの形成を形成すべきかどうかを判定する手段と、
    前記パートナーシップを形成すべきである場合に、肯定パートナーシップアクノリッジメントを生成しユニキャストで送信し、前記リカバリデバイスと前記セカンダリリカバリネットワークを作成し確立する手段と、
    前記パートナーシップを形成すべきでない場合に、否定パートナーシップアクノリッジメントを生成しユニキャストで送信する手段と、
    をさらに含み、
    前記装置はワイヤレスデバイスであり、前記リカバリデバイスはプロキシ、リカバリサーバおよびリカバリプロキシのうちの１つである、前記装置。

Images