(57)【特許請求の範囲】
【請求項１】
コンピュータ・ネットワーク内の通信を制御する方法であって、
コンピュータ・ネットワークの構成要素を通信可能に結合する第１通信チャネル内の状態が、その通信チャネルの継続利用にとって容認できなくなりつつあることを第１ネットワーク・デバイスにおいて判定すること、
第１ネットワーク・デバイスが使用可能な第２通信チャネルを探索している間に、コンピュータ・ネットワークの構成要素に静止したままであるように命令すること、
第１ネットワーク・デバイスからの、切り替えるようにとの命令に応答して、コンピュータ・ネットワーク内の通信を第２通信チャネルに切り替えること、および
切替えの後で、第２通信チャネルにおいてネットワーク通信を確立することを含み、さらにこのネットワーク通信を確立することが、第２通信チャネルについてコンピュータ・ネットワークの各構成要素との帯域幅接続同意をセットアップすることを含む方法。
【請求項２】
第２通信チャネル内の干渉状態が、第１通信チャネル内の干渉状態よりも厳しくない、請求項１に記載の方法。
【請求項３】
第１ネットワーク・デバイスが使用可能な第２通信チャネルを探索している間中に静止したままであるようにとの命令に応答して、前記第１通信チャネル内の通信を待機状態に置くことを含む、請求項１に記載の方法。
【請求項４】
コンピュータ・ネットワークの各構成要素が、静止したままであるようにとの命令の受信に肯定応答する、請求項１に記載の方法。
【請求項５】
第１ネットワーク装置が、第１ネットワーク装置に関連付けられた無線機の同調をとることによって、使用可能な通信チャネルを探索する、請求項１に記載の方法。
【請求項６】
切替えの前に、第１ネットワーク装置が、第２通信チャネルを確認するチャネル変更メッセージをコンピュータ・ネットワークの構成要素にブロードキャストする、請求項１に記載の方法。
【請求項７】
コンピュータ・ネットワークの各構成要素がチャネル変更メッセージに応答して、第１ネットワーク装置に肯定応答を送信する、請求項６に記載の方法。
【請求項８】
第１ネットワーク装置は、コンピュータ・ネットワークの各構成要素からの肯定応答メッセージがない場合でも、第２通信チャネルに切り替わる、請求項６に記載の方法。
【請求項９】
切替えの前に、第１ネットワーク装置が、第２通信チャネルの他のコンピュータ・ネットワークを示すチャネル活動状態についてリスンする、請求項１に記載の方法。
【請求項１０】
第１通信チャネルから第２通信チャネルへのコンピュータ・ネットワークの要素間の通信切り替えを含み、その切換が（１）第１通信チャネル内のチャネル干渉状態が容認できないとの指示および（２）第２通信チャネルへ切り換えよという第１の要素からの命令に応答して行われる方法であって、
チャネル切替え肯定応答への要求に応答して、第２通信チャネルの要素の間で通信を再開することを含み、さらにこの通信を再開することが、第２通信チャネルにおける帯域幅についてネゴシエートすることを含む方法。
【請求項１１】
第１通信チャネルまたは第２通信チャネルの少なくとも一方が、無線通信チャネルを含む、請求項１０に記載の方法。
【請求項１２】
第１通信チャネルおよび第２通信チャネルの各々が、スペクトラム拡散無線通信チャネルを含む、請求項１０に記載の方法。
【請求項１３】
前記コンピュータ・ネットワークの要素間の通信切り替えが、第１の要素から静止したままであるようにとの命令に応答して、第１通信チャネル内の通信を接続解除することを含む、請求項１０に記載の方法。
【請求項１４】
前記コンピュータ・ネットワークの要素間の通信切り替えが、第１通信チャネル内の通信を接続解除することの前に、静止したままであるようにとの命令に肯定応答することをさらに含む、請求項１３に記載の方法。
【請求項１５】
第１通信チャネルから第２通信チャネルへのコンピュータ・ネットワークの要素間の通信切り替えを含み、その切換が（１）第１通信チャネル内のチャネル干渉状態が容認できないとの指示および（２）第２チャネルへ切り換えよという第１の要素からの命令に応答して行われる方法であって、
チャネル切替え肯定応答への要求に応答して、第２通信チャネルの要素の間で通信を再開することを含み、さらにこの通信を再開することが、第２通信チャネルへのアクセス要求をそれの静止時間スロットにおいて送信することを含む方法。
【発明の詳細な説明】
【０００１】
（発明の分野）
本発明は一般に、コンピュータ・ネットワーク内の通信のための方式、詳細には無線リンクを介して中央サーバと複数のクライアント・ユニットとの間で行われる通信に関する。
【０００２】
（背景）
現代のコンピュータ・ネットワークは、パーソナル・コンピュータ、ワークステーション、周辺機器など複数のノード間の相互通信を可能にする。ネットワーク・リンクはこれらノード間に情報を伝搬するが、このようなノードは時に互いに遠く離れていることがある。だが現在のところ、大半のコンピュータ・ネットワークは、有線リンクに依存してこの情報を伝搬してきた。無線リンクが使用される場合、通常それらは広域ネットワークなど非常に大規模なネットワークの構成要素であり、非常に距離が離れているネットワーク・ノードを相互接続するために衛星通信リンクを使用することもある。このような場合、無線リンク間で使用される送信プロトコルは一般に、例えば電話会社および他のサービス提供者など、送信されているデータを伝搬するサービス・エンティティにより確立されている。
【０００３】
家庭環境においては、コンピュータは従来スタンドアロン装置として使用されてきた。だが近年になって、ホーム・コンピュータを他の電気器具と統合するための手段がいくつか講じられている。例えばいわゆる「スマート・ホーム」では、コンピュータを使用してさまざまな電気器具のスイッチを入れたり切ったり、およびその操作設定を制御することができる。このようなシステムでは、有線通信リンクを使用して、コンピュータとそれが制御する器具とを相互接続している。こうした有線リンクは、特に最初に家屋を建造した後に追加する場合には設置に高費用がかかる。
【０００４】
有線通信リンクに関連する問題および費用を低減する目的で、電気器具とコンピュータを相互接続するためのシステムには、アナログ無線リンクを利用してこれらのユニット間に情報を伝送しているものもある。こうしたアナログ無線リンクは、普通無線電話が利用している周波数で動作する。従来の有線通信リンクに比べて設置は容易だが、アナログ無線通信リンクには複数の欠点がある。例えばそのようなリンクにおいては、複数経路混信のために信号が劣化することが予測される。さらにテレビ、携帯電話、無線電話など現存の電気器具からの混信が起こるかもしれない。したがってアナログ無線通信リンクは、家庭環境に関して最適な機能を提供するとは言えず、そのような地域内の無線ネットワーク通信のために改良された方式を有することが望まれる。
【０００５】
無線電話のような装置は、基礎的な周波数ホッピング技術を使用することによって、いくつかの通信の問題の回避を試みてきた。例えば、アナログ無線電話によっては、現行伝送チャネルに過度のノイズがある場合、ユーザが、基地局とハンドセットとの間で使用するための新しい送信周波数に切り替えることができるものがある。しかし、ユーザは、その無線電話ユニットが切り替わる可能性のある次のチャネルに対する制御権をほとんど、あるいはまったく有することがなく、新しい送信周波数がさらに悪い通信特性を有し、したがってハンドセットと基地局との間の最後の通信が失われる可能性がある。さらに、基地局とハンドセットとの間に通信の低下が生じた場合に、明瞭な伝送チャネルを自動的に探索する無線電話ユニットはなさそうである。
【０００６】
無線電話とは別に、周波数ホッピング無線機も通信目的で使用されてきた。このような無線機は、絶えずその送信周波数を変更し、したがって、無線機は、短いタイム・ユニット中に、ある周波数帯域で情報を伝送し、次いで次のタイム・ユニットの伝送用に別の周波数帯域に切り替え、以下同断に行う。一般に、多くのそのような周波数が使用可能であり、その後、無線機は既に使用した第１周波数帯域に戻ってくる。また、多くの無線機が同じ周波数帯域を使用することができるが、干渉を回避するために様々なパターンでこれを行う。しかし、重要なのは、そのような方式におけるチャネル切替えが、チャネルの挙動と独立に行われることである。チャネル・ノイズや他の干渉によるデータ損失は、ネットワーク上層でデータ・インタリービングとエラー訂正技術を使用して、補正されなければならない。したがって、旧来のアナログ無線通信リンクと周波数ホッピング方式は、住宅環境に対して決して最適なパフォーマンスを提供しておらず、そのような区域では、無線ネットワーク通信に対する改善型の方式を有することが望ましい。
【０００７】
（発明の概要）
コンピュータ・ネットワークにおける通信は、コンピュータ・ネットワークの構成要素を通信可能に結合する第１通信チャネル内の状態が、その通信チャネルの継続利用にとって容認できなくなりつつあることを第１ネットワーク装置において判定し、次いで、コンピュータ・ネットワーク内の通信を第２通信チャネルに切り替えることによって制御することができる。第２通信チャネル内の干渉状態は、第１通信チャネル内の干渉状態よりも厳しくないことが好ましい。切り替えは、第１ネットワーク装置または別のネットワーク構成要素によって開始することができ、一般に、使用可能な通信チャネルの探索中に、第１通信チャネル内の通信を待機状態に置くことを含む。これは、第１ネットワーク装置が、例えば、第２通信チャネルについて受信待機（リスン）するように、関連付けられた無線機の同調をとることによって、使用可能な通信チャネルを探索している間に、コンピュータ・ネットワークの構成要素に静止のままであるよう命令することによって達成することができる。場合によっては、コンピュータ・ネットワークの各構成要素が、静止しているようにとの命令の受信に肯定応答する。
【０００８】
したがって、無線電話によって使用される周波数ホッピング方式と異なり、本発明による方法は、低下した通信チャネルの自動検出を可能にし、さらに古いチャネルよりも優れた通信特性を示す新しい通信チャネルへのチャネル切替えを提供する。さらに、一実施態様では、このチャネル・ホップは、第１ネットワーク装置がネットワーク通信を新しいチャネルに変更するよう決定する前に、いくつかの通信チャネルを自由に探索できるということに関しては、事前定義されていない。このようなチャネル変更の動作は、ユーザによる介入が必要になる前に、自動的に実行されることが好ましい。
【０００９】
切替えの前に、第１ネットワーク装置は、第２通信チャネルを確認するチャネル変更メッセージをコンピュータ・ネットワークの構成要素にブロードキャストすることができ、またコンピュータ・ネットワークの各構成要素はチャネル変更メッセージに応答して、第１ネットワーク装置に肯定応答を送信することができる。場合によっては、第１ネットワーク装置は、コンピュータ・ネットワークの各構成要素からの肯定応答メッセージがない場合でも、第２通信チャネルに切り替わる。最終的に、ネットワーク通信を、第２通信チャネルに確立することができる。これは、第２通信チャネルについてコンピュータ・ネットワークの各構成要素との帯域幅接続同意をセットアップすること、および／または第２通信チャネルにおいてコンピュータ・ネットワークの各構成要素をポーリングすることを含む。
【００１０】
別の実施態様では、第１通信チャネルから第２通信チャネルへのコンピュータ・ネットワークにおける通信の切替えは、第１通信チャネル内のチャネル干渉状態が容認できないとの指示に応答して実行される。少なくとも第１通信チャネルまたは第２通信チャネルの一方が無線通信チャネルであり、場合によっては、第１通信チャネルと第２通信チャネルの両方がスペクトラム拡散無線通信チャネルであることが好ましい。一般に、切替えは、静止しているようにとの指示に応答して、第１通信チャネル内の通信を接続解除することを含む。この指示は、肯定応答が返される場合と返されない場合とがある。返されない場合、切替えは、切り替えるようにとの要求がない場合でも、任意で第２通信チャネルに切替わることを含むことができる。第２通信チャネルに切り替わった後、通信は、チャネル切替え肯定応答への要求に応答して、第２通信チャネルにおいて再開することができる。通信を再開することは、第２通信チャネルにおける帯域幅についてネゴシエートすることを含み、および／または第２通信チャネルへのアクセス要求をそれの静止時間スロットにおいて送信することによって達成することができる。
【００１１】
本発明のこれらまたは他の特徴および利点は、詳細な説明とその添付図面を参照することによって明らかになろう。
【００１２】
本発明は添付の図面の形で、制限としてではなく例として図示される。
【００１３】
（詳細な説明）
ここで説明するのは、（ａ）サーバと関連するネットワーク・クライアント、および（ｂ）サーバとそれに関連するホスト・コンピュータの間で使用される、ネットワーク・アーキテクチャおよび関連するプロトコルである。本技術は一般に、さまざまな無線ネットワーク環境に応用することができるが、特に家庭環境内に置かれるコンピュータ・ネットワーク内で使用すると有用である。したがって本技術は、家庭環境の特定の状況を参照しながら説明される。ただしこの説明は決して本発明を他のネットワーク環境に応用することを制限するものではなく、本発明のより広い精神および範囲はこの説明に続く請求項で列挙される。
【００１４】
ここで使用される「サブネット」とは、サーバおよびそれに関連づけられたいくつかのクライアント（例えば無線通信リンクで結合された）を含むネットワーク構成要素のクラスタを表す。説明の文脈によっては、サブネットは、クライアントおよびそれに関連づけられた１つまたはそれ以上のサブクライアントを含むネットワークを指すこともある。場合によっては、「サブネット」という用語は「セル」と置き換え可能な意味で使用される。本技術では、「クライアント」は無線リンクを通じてサーバにリンクされたネットワーク・ノードである。クライアントの例は、テレビ、ステレオ・コンポーネント、衛星テレビ受信機、ケーブルテレビ配布ノード、他の家庭用電気器具などのオーディオ／ビデオ機器を含む。サーバは通信リンクを制御する別のコンピュータでよいが、他の場合にはサーバはアドオン・カードまたはホスト・コンピュータに接続された構成要素（例えばパーソナル・コンピュータ）でもよい。サブクライアントは、キーボード、ジョイスティック、遠隔制御装置、多次元入力装置、カーソル制御装置、表示装置および／または特定のクライアントに関連付けられた他の入力および／または出力装置を含む。
【００１５】
以下の説明を通じて使用されるもう１つの用語は「チャネル」である。チャネルは、スペクトラム拡散通信方式で使用される送信周波数（より適切には、送信周波数帯域）と擬似ランダム（ＰＮ）コードとの組み合わせとして定義される。一般に複数の使用可能な周波数およびＰＮコードは、サブネット内で使用可能な複数のチャネルを提供する。下記でより詳細に説明するように、サーバおよびクライアントは使用可能なチャネル内を検索して、相互に通信するための望ましいチャネルを見つけることができる。下の表１は、この方式による例示的チャネル計画を示す。
【００１６】
【表１】
0003821424.tif 000002
一実施形態では、２つの周波数帯域を使用したチャネル計画を採用し、そのような技法におけるチャネル選択の詳細は下記でより詳細に説明する。
【００１７】
以上の用語を念頭に置き、第１に無線通信リンクおよび関連する通信プロトコルを使用する例示的ネットワーク・トポロジを参照して、本技術を論じる。第２に、無線リンク上でサポートされる通信チャネル内で送信されるデータについての階層構造を使用するネットワーク動作を説明する。第３に、無線通信リンク・プロトコルに従って使用される例示的パケット構造について論じる。第４に、オーバヘッド、エラーの符号化および訂正、データの暗号化、ネットワークの初期化および管理などのネットワークに関するさまざまな事項について説明する。
【００１８】
Ａ．ネットワーク・トポロジ
本技術がサポートするネットワーク・アーキテクチャの概括を図１に示す。サブネット１０はサーバ１２を含む。先に指摘したように、サーバ１２はスタンドアロン・ユニット、またはより高い可能性としては、サーバに対しホスト１３として機能するパーソナル・コンピュータ用のアタッチメント・カードである。サーバ１２は関連づけられた無線装置１４を有し、それはサーバ１２をサブネット１０の他のノードに無線的に結合するために使用される。無線リンクは一般に、高帯域および低帯域両方のデータ・チャネルとコマンド・チャネルをサポートする。
【００１９】
サブネット１０には複数のクライアント１６も含まれ、そのうちのいくつかはそれと関連付けられたシャドー・クライアント１８を有する。シャドー・クライアント１８は、関連付けられたクライアント１６と同一のデータ入力を受信する（サーバ１２または別のクライアント１６から）が、それと関連するクライアント１６とは無関係にサーバ１２とコマンドを交換するクライアントとして定義される。各クライアント１６は、サーバ１２と通信するために使用される関連付けられた無線装置１４を有し、いくつかのクライアント１６は関連するサブクライアント２０を有することもある。クライアント１６とそれに関連付けられたサブクライアント２０は、通信リンク２２を介して互いに通信するが、そのリンクは無線（例えば赤外線、超音波、拡散スペクトラムなど）通信リンクでよい。
【００２０】
各サブネット１０は、ネットワーク内の構成要素の通信が生じるレベルに応じた階層のさまざななレベルにより、階層的に配置されたネットワークと見ることができる。階層の最上レベルにあるのは、無線通信チャネルを介してさまざまなクライアント１６と通信するサーバ１２（および／またはそれに関連するホスト１３）である。階層の一方の低レベルでは、クライアント１６が、例えば有線通信リンクまたは赤外線リンクなどの無線通信リンクを使用して、さまざまなサブクライアント２０と通信する。この階層は、下の表２に示すような３層構造で説明することもできる。指摘したように、装置はネットワーク・オンラインの任意のレベルに追加することができる（例えば他のネットワーク動作中のホット・インサーションなど）。
【００２１】
【表２】
0003821424.tif 000003
【００２２】
一般に、サブネット１０は単一のサーバ１２および事実上任意の数のクライアント１６を含むことができる。ただし同時にサポートされるクライアント１６の数は、フォワードおよびバックワードの帯域要件による。一実施形態では、サーバ１２とクライアント１６を結合する（例えば無線装置１４を介して）無線リンクは、全二重の１０Ｍｂｐｓのリンクである。他の実施形態では、無線リンクは半二重で４Ｍｂｐｓのリンクである。さらに他の実施形態では、異なる帯域での半二重または全二重のリンクを可能にする。
【００２３】
無線装置１４は、典型的な家庭環境内でのサブネット内通信を可能にするように構成されることが好ましい。一実施形態では、これは無線装置１４が特定のセル・エリア内で通信を確立および管理することができることを意味する。一実施形態では、典型的セル・エリアはおよそ１００’×８０’×３０’であり、典型的家庭環境中での通信を可能にしている。無線装置１４によりサポートされる無線リンクは、少なくとも２つの別々の周波数空間を提供し、重なり合っている２つのセル２２をサポートすることが好ましい。すなわち無線装置１４は、使用可能な周波数帯域のうち１つで作動することができる。同一の周波数帯域内では、個々のサブネット（サーバ１２、複数のクライアント１６、および任意選択でシャドー・クライアント１８、サブクライアント２０からなる）は、コード分割多重アクセス（ＣＤＭＡ）通信技術を利用してサブネット内で情報を交換することが好ましい。半二重の動作については、同一の周波数帯域のフォワード通信路およびリバース通信路（同一のＣＤＭＡ擬似ランダム（ＰＮ）コードを使用する）は、動的に調整可能な時間分割多重アクセス（ＴＤＭＡ）を利用して、サーバ１２からの送信とクライアント１６からの送信を区別することができる。エラー訂正（例えばリード−ソロモン（Ｒｅｅｄ−Ｓｏｌｏｍｏｎ）エンコーダ／デコーダを使用する）およびデータ暗号化技術を使用して、盗聴に対する頑強性および安全性を増してもよい。
【００２４】
個々のサブネット間で高干渉を生じさせないために、複数のサブネット２２ａ、２２ｂ、２２ｃ、２２ｄの環境内での配置は、図２ａに示すように互いに重なり合わないことが好ましい。ただしこのような理想的なモデルを保証するのは難しいことが認識される。例えば重なり合っているサブネットは、２つの近接する家／アパート内に２つの異なるサブネットがある場合に生じる（実際には予測される）ことがある。図２ｂに図示するような、重なり合うサブネット範囲エリア２４ａおよび２４ｂ（それぞれ異なる送信ユニットＴ1およびＴ2を有する）は、盗聴、サブネット内の干渉の増大、頻繁なチャネル変更などを招きうる。生じる可能性のあるこうした問題に対する防御については下記で述べる。
【００２５】
当プロトコル方式は、図３に示すように、よく知られている開放型システム間相互接続（ＯＳＩ）モデル上にオーバーレイしてもよい。ＯＳＩモデルの最上層からの３つのレイヤ、すなわちアプリケーション・レイヤ３０、プレゼンテーション・レイヤ３１、セッション・レイヤ３２は、ホスト・コンピュータ１３（すなわちサーバ１２をサポートしているコンピュータ、またはサーバがスタンド・アロン・ユニットである場合はサーバ１２自体）で実施されることが好ましい。低層のレイヤ、すなわち伝送レイヤ３３、ネットワーク・レイヤ３４、データ・リンク・レイヤ３５、物理レイヤ３６は、サーバ１２およびクライアント１６（ホスト１３の動作と重複があるかもしれないが）で実施されることが好ましい。
【００２６】
上記で述べたように、物理レイヤ３６は無線装置１４を使用する無線リンクとして実施されることが好ましい。したがって、サーバ１２またはクライアント１６（適切に応じて）は、データ・フレーム・パラメータの初期化、無線パラメータ、およびデータ・フレーム送信の開始を処理することができるが、データ・フレームの構成、送信、受信などの他のサービスおよび拡散動作は、無線装置１４により直接処理される。
【００２７】
一実施形態について、例えば半二重の無線通信が使用される場合、データ・リンク・レイヤ３５は、動的なスロット割り当てとともに、スロット化されたリンク構造（下記でより詳細に説明する）を使用することがある。そのような構造はサブネット１０内での二地点間接続をサポートし、スロット・サイズはセッション中に再ネゴシエーション可能でありうる。したがってデータ・リンク・レイヤ３５はデータ・パケットの処理、パケット送信についての時間管理、スロット同期化、エラー修正コーディング（ＥＣＣ）、チャネル・パラメータの測定、チャネル切り替えを受け入れることができる。伝送レイヤ３３は、サービスに関連するすべての必要な接続、帯域幅利用の監視、低帯域幅データの処理、データのブロードキャスト、および任意選択でデータの暗号化を提供する。伝送レイヤ３３は帯域幅を各クライアント１６に割り当て、常にその帯域幅を下回るまたは上回る利用を監視する。伝送レイヤ３３は、新しいクライアント１６がオンラインに入ってくるか、またはクライアント１６の１つ（または関連するサブクライアント２０）がより大きな帯域幅を要求する時には必ず必要となる、いずれの帯域幅の再ネゴシエーションも受け入れる。プレゼンテーション・レイヤ３１は、ビデオ／ボイス・データの圧縮／解凍をサーバ１６（および／またはそのホスト・コンピュータ１３）およびクライアント１６で提供する。さらに表示サービスがクライアント１６で提供される。
【００２８】
下記でより詳細に説明するように、このネットワーク・アーキテクチャは、複数のネットワーク構成要素（例えばサーバ１２、クライアント１６、シャドー・クライアント１８、サブクライアント２０）を階層的に配置することができる。階層の１つのレベルにおいて、サーバ１２およびクライアント１６は、マルチメディア・データなどの情報を交換するために動作する。階層の別のレベルでは、クライアント１６はその個々のサブクライアント２０と通信して、サーバ１２で発する／終端するコマンドなどの情報を交換することができる。このネットワーク階層の各レベルにおいて、個々のネットワーク構成要素は、階層のそのレベルで動作する通信リンクを通じて互いに通信上結合される。例えば次項で述べるのは、階層の最上レベル（すなわちサーバ１２とクライアント１６との間）で動作するプロトコルであり、それは階層の最上レベルで使用される通信チャネルに関するその帯域幅要件に従って、新しいネットワーク構成要素の動的な追加を階層のどのレベルにおいてもサポートする。階層の低レベル（例えばクライアント１６とそれに関連するサブクライアント２０の間）における通信は、クライアントおよびそのサブクライアントにより実行される操作に従って、同様のプロトコルまたは他の任意の適切な通信プロトコルを使用することができる。例えば、サブクライアントとその関連するクライアントとの間の無線（例えば赤外線）または有線通信リンク内で情報を交換するための現存の通信プロトコルをサポートして、その情報がクライアント１６とサーバ１２の間で送信されようとする時に、下記で述べるプロトコルに従って交換されるべきデータ・パケット内で、任意のそのようなデータが続いてカプセル化される（および／または必要であれば再フォーマットされる）。
【００２９】
Ｂ．ネットワーク動作
以上のように本技術をサポートするネットワークの基本的トポロジを説明したので、次いでネットワークについての例示的動作（例えば半二重動作）を説明する。図４に示すように、こうした動作は、サブネット１０内でリアル・タイムのマルチメディア・データ（例えばフレームとして）を送信するために、階層的配置を利用する。チャネル内の最上レベルで、固定の（だが交渉可能な）継続時間のフォワード（Ｆ）およびバックワードまたはリバース（Ｂ）スロットが、各フレーム送信期間中に設けられる。フォワード時間スロットＦ中に、サーバ１２はビデオおよび／または音声データおよび／またはコマンドをクライアント１６に送信し、クライアント１６は聴取モードに置かれる。リバース時間スロットＢ中に、サーバ１２はクライアント１６からの送信を受信待機する。こうした送信は、クライアント１６または関連付けられたサブクライアント２０からの音声、ビデオ、または他のデータおよび／またはコマンドを含むことができる。階層の２番目のレベルでは、各送信スロット（フォワードまたはリバース）は、可変長の１つまたは複数の無線データ・フレーム４０から構成される。最後に階層の最低レベルでは、各無線データ・フレーム４０は、可変長のサーバ／クライアント・データ・パケット４２を含む。
【００３０】
各無線データ・フレーム４０は、１つのサーバ／クライアント・データ・パケット４２およびそれに関連するＥＣＣビットから構成される。ＥＣＣビットは、受信側でデータ・パケットの開始および終了を検出するのを単純化するために使用することができる。深刻なチャネル状況中により小さなフレーム長を容認する目的で、一定の長さのフレーミングより可変長のフレーミングが好ましく、またその逆でもよい。これにより、チャネルの頑強性および帯域幅節約が増加される。ただし、可変長のフレームが使用されるものの、ＥＣＣのブロック長は固定であることが好ましい。したがって、データ・パケット長がＥＣＣのブロック長よりも小さい場合はいつでも、ＥＣＣブロックは切捨てられる（例えば従来の仮想ゼロ技術を使用して）。データ・パケットがより大きい時は、同様の手順をＥＣＣビットの最後のブロックについて採用することができる。
【００３１】
図に示すように、各無線データ・フレーム４０はプリアンブル４４を含み、それは送信機および受信機のＰＮ生成装置を同期するために使用される。リンクＩＤ４６は固定長のフィールドであり（例えば一実施形態では長さ１６ビット）、リンクに固有であり、したがって特定のサブネット１０を識別する。サーバ１２／クライアント１６からのデータは、長さフィールド４８により指定される可変長である。周期冗長検査（ＣＲＣ）ビット５０は、従来の方式でエラーを検出／訂正するために使用される。
【００３２】
次に図示された実施形態について、各フレーム４４（例えば一実施形態では３３．３３ｍｓｅｃの継続時間）は、フォワード・スロットＦ、バックワード・スロットＢ、静止スロットＱ、複数の無線ターン・アラウンド・スロットＴに分割される。スロットＦは、サーバ１２からクライアント１６への通信用である。スロットＢは、複数のミニスロットＢ1、Ｂ2などの間で共有される時間であり、ミニスロットはそれぞれのサーバ１２への送信のために、サーバ１２によって個々のクライアント１６に割り振られる。各ミニスロットＢ1、Ｂ2などは、音声、ビデオ、ボイス、損失のあるデータ（すなわち損失のある技術を使用してコード化／コード解除されたデータ、または送信／受信中のいくらかのパケットの損失を容認できるデータ）、損失のないデータ（すなわち損失のない技術を使用してコード化／コード解除されるデータ、または送信／受信中のいかなるパケットの損失をも容認できないデータ）、低帯域幅データおよび／またはコマンド（Ｃｍｄ．）パケットを送信するための時間を含む。新しいクライアントがサブネット１０にログインしようとする際に新しいクライアントが要求パケットを挿入できるように、スロットＱは静止の状態に置かれる。スロットＴは、送信から受信への変更、またはその逆の場合の変更の間に現れ、個々の無線のターン・アラウンド時間（すなわち半二重無線装置１４が送信から受信動作へ、またはその逆に切り替わる時間）を受け入れるものである。これらの各スロットおよびミニスロットの継続時間は、チャネルにとって最上の可能性のある帯域幅の使用を実現するために、サーバ１２とクライアント１６間の再ネゴシエーションを通じて動的に変えられる。全二重無線が使用される場合、各方向スロット（すなわちＦおよびＢ）は１つの方向においてフルタイムであり、無線ターン・アラウンド・スロットは必要とされない。したがって通信プロトコルは、コンピュータ・ネットワークの２つまたはそれ以上のユニット（例えばサーバおよび複数のクライアント、サブクライアントおよび／またはシャドー・クライアント）を、ＴＤＭＡ直接拡散スペクトラム方式（ＤＳ−ＳＳ）通信リンクと通信上結合することができる。示すように、ＴＤＭＡ  ＤＳ−ＳＳ通信リンクは、コンピュータ・ネットワークのユニットに対して動的に配分できる通信時間スロットを含む。
【００３３】
フォワード帯域幅およびバックワード帯域幅の配分は、クライアント１６によって扱われるデータによって決まる。クライアント１６が例えばテレビのようなビデオ消費者である場合、そのクライアントに対しては大きなフォワード帯域幅が割り当てられる。同様にクライアント１６が例えばビデオカムコーダのようなビデオ生成装置である場合は、大きな逆方向の帯域幅がその特定のクライアントに割り当てられる。サーバ１２は動的テーブル（例えばサーバ１２またはホスト１３のメモリ内の）を保持し、それにはすべてのオンライン・クライアント１６のフォワードおよびバックワードの帯域幅要件が含まれている。この情報は、新しい接続が新しいクライアントに対して許可されるかどうかを決定する時に使用することができる。例えば新しいクライアント１６がいずれかの方向で使用可能な帯域幅以上を要求する場合、サーバ１２は接続要求を拒否することができる。帯域幅要件（または割り当て）情報は、特定のクライアント１６がそのパケットをサーバ１２に送信するのを開始する前に、いくつの無線パケットを待つ必要があるのかを決定する際にも使用することができる。さらにチャネル状態が変化した場合はいつでも、エラー訂正コーディング（ＥＣＣ）を増加／減少して新しいチャネル状態に対処することが可能である。したがってソースにおける情報速度が変更されたかどうかによって、それはフォワードおよびバックワードの帯域幅割り当てに対する動的な変更を必要とする。これはＣｏｎｎｅｃｔｉｏｎ  Ａｇｒｅｅｍｅｎｔ（接続同意）コマンド（下記でさらに説明する）を通じて実現することができる。
【００３４】
サーバ１２とクライアント１６の間の時間スロットの同期化は、４つのネットワーク動作状況について検討される。すなわち、クライアントがウェイク・アップする時、新しいクライアントがオンラインに入る時、チャネルが変更される時、クライアントが不在になるかまたはシャットダウンする時の動作状況である。これらの状況は、クライアント１６およびサーバ１２についてのさまざまな有限状態図を参照して説明する。図中、ネットワーク構成要素の動作状態は円内に書かれる。状態遷移は、現在の状態および／または入ってくるメッセージの受信および内容に関連する処理の出力によって行われる。受信または送信されたメッセージ（すなわちコマンド）は、状態遷移の線の隣に示す。例えば状態遷移線上の「Ａ／Ｂ」は、メッセージ「Ａ」が受信され、それに対し次の状態に遷移しながらメッセージ「Ｂ」が応答として送信されたことを意味する。他の場合では、「Ａ」は進行中の処理の出力であり、「Ｂ」は有限状態マシンによりとられるアクションであることもある。「ＸＸ」は、入力または出力のドント・ケア・アクションを表す。この図で参照するさまざまなコマンドの完全な説明は下記で行われる。
【００３５】
図５に示すように、クライアント１６がウェイク・アップする時、それは受信モード（状態６０）で起動し、チャネルを受信する。クライアント１６がチャネル上のアクティビティを検出する場合、クライアントは受信してサーバ１２がチャネルを変更中である（状態６２）かどうかを判定する（下記でさらに説明する）。チャネル変更プロセスが認識される場合、クライアント１６は残りのサブネット１０とともにチャネルを変更する（状態６４）。言うまでもなく、チャネル変更が進行中でなければ、クライアント１６は通常のチャネル通信だけを検出する。クライアント１６がチャネルを変更する必要がある場合もない場合も、クライアント１６はスロットＱを待機し（状態６６）、そのスロット中にＣｏｎｎｅｃｔｉｏｎ  Ｒｅｑｕｅｓｔ（接続要求）（ＣＲＱ）パケットをサーバ１２に送信する。それに応答してサーバ１２は、入ってくる要求の整合性をチェックする（例えば送信元のクライアントを行先とする同一の要求を周期的に、おそらくビデオ・フレームごとに１回、応答が受信されるまで送信することにより）。
【００３６】
クライアントの要求が確認されると（例えば、確認パケットをクライアントから受信することにより。その後クライアントは待機状態６８に入る）、サーバ１２はＣｏｎｎｅｃｔｉｏｎ  Ａｇｒｅｅｍｅｎｔ（接続同意）（ＣＡＧ）パッケージをクライアント１６に送信する。このパッケージは特に、新しいクライアント１６に与えられるフォワードおよびバックワードの帯域幅（例えばチャネルのスロット）に関する情報を含む。さらに、新しいクライアント１６が各データ・パケット内に送信／予期することができるバイトの最大数が、各タイプのパケット（例えば映像データ、音声データなど）について設定される。Ｃｏｎｎｅｃｔｉｏｎ  Ａｇｒｅｅｍｅｎｔパッケージは、新しいクライアント１６がサーバの送信から、および先行するクライアント（すなわち先行するリバースの送信スロットを持つクライアント）の識別の開始から待たなければならない、データ・フレームの総数に関する情報も含むことができる。全クライアントは、サーバの送信の開始から受信するデータ・フレームの数を数えることにより、その個々の接続同意を容認し、先行するクライアントから受信した最後のデータ・フレームの終了後にそれぞれの送信を開始する。計算中にクライアントが先行するクライアントにより送信されたＴｏｋｅｎ  Ｐａｓｓコマンドに遭遇した場合、そのクライアントは計算を停止しそれ自体の送信を即時に開始する。
【００３７】
Ｃｏｎｎｅｃｔｉｏｎ  Ａｇｒｅｅｍｅｎｔパケットを受信した後に、クライアント１６はそのデータをそれに割り当てられた時間スロット（例えばＢ１、Ｂ２など）中に送信するようにそれ自体を構成し、スロットが回ってくるのを待機する（状態７０）。指定された時間スロットに、クライアント１６はサーバ１２と通常の通信を開始し（状態７２）、それが持っているであろう任意のデータまたはコマンドを送信する。
【００３８】
上記の説明は、クライアント１６がアウェイクして使用中のチャネルを検出することを想定している。だがクライアント１６がウェイク・アップした際にチャネルがビジーでない可能性もある。そのような場合、クライアント１６はサーバ１２が応答することを見込んでＣｏｎｎｅｃｔｉｏｎ  Ｒｅｑｕｅｓｔパケットを送信し、任意の期間待機する（状態７４）。応答が受信されない場合、クライアントはチャネルを変更する。新しいチャネル内で受信モードにある間に（状態７６）、クライアント１６がアクティビティを検出した場合、それは続行して上記で説明したように帯域幅の割り当てについてサーバ１２とネゴシエートする。そうではなく、チャネル・アクティビティが検出されない場合、クライアント１６は再びＣｏｎｎｅｃｔ  Ｒｅｑｕｅｓｔパケットを送信し、応答を待機する（状態７８）。このプロセスは、サーバ１２が見つかるまですべての使用可能なチャネルについて繰り返される。応答が受信されない場合、クライアントは使用可能なサーバがないことをユーザに通知し、パワー・ダウンする（状態８０）。ただし、チャネルの１つでサーバ１２から応答が受信される場合は、クライアントは接続についてネゴシエートし（状態８２）、それから上記で説明したように通常の通信を開始する（状態８４）。
【００３９】
図６に示すように、サーバから見ると、クライアント１６はオンラインで挿入してよい。例えばクライアント１６は、サーバ１２がすでに動作した後にウェイク・アップするかもしれない。サーバ１２は接続を求めている新しいクライアントによって送信されたＣｏｎｎｅｃｔｉｏｎ  Ｒｅｑｕｅｓｔパケットを求めて、スロットＱを受信待機するように構成される。上記で説明したように、Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｑｕｅｓｔパケットをさらに交換することにより新しいクライアント１６と同期した後で、サーバ１２は、有効なクライアントＩＤを格納するホスト・コンピュータ１３にそのような認証を要求して、クライアントの信頼性を確かめる（状態９２）。認証テストがパスした場合、サーバ１２は新しいセッション識別子（ＩＤ）をクライアントに割り当て（状態９３）、チャネルについて帯域幅を再割り当てする（状態９４）。帯域幅の再割り当ては、新しいクライアントを受け入れるために必要とされる。その後サーバ１２はＣｏｎｎｅｃｔｉｏｎ  Ａｇｒｅｅｍｅｎｔパケットを新しいクライアント１６に送信し、それにより通常の通信を開始する。図示するように、各状態９２、９３、９４は、関連付けられたタイム−アウト・パラメータ（例えば搭載されたタイマーを使用して維持される）を有することもある。いずれの時間にも、クライアント応答がタイム・アウト期間内に受信されない場合、サーバ１２はクライアント１６がオフライン状態になったと想定し、Ｑスロット内で受信待機に戻る（状態９０）。
【００４０】
図７に示すように、オンラインのクライアント１６がない場合、サーバ１２は空いたチャネル内で待機し、クライアント・パケットが検出されるまで受信モードの状態を保つ（状態９５）。チャネルが空いているかどうかを判定するために、各チャネルについて受信した信号の強度（無線装置１４により提供される）をチェックし、最低のエネルギーの信号を選択する。次いで有効なデータ・パケットが存在するか、Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｑｕｅｓｔパケット以外の受信したいずれのデータを分析する。任意の他のパケット、特にサーバ生成であるとマークされているパケットが受信される場合、チャネルはビジーであると宣言される。一方、チャネル上で受信されたパケットが、接続を待機しているクライアントにより生成されたＣｏｎｎｅｃｔｉｏｎ  Ｒｅｑｕｅｓｔパケット以外に有効なデータを何も含んでいない場合、チャネルは空いていると宣言される。データ・パケットが全く受信されない場合、サーバ１２はそのチャネル内で受信モード（状態９５）のままであり、クライアントのＣｏｎｎｅｃｔｉｏｎ  Ｒｅｑｕｅｓｔパケットを待つ。その間に、チャネルが現在のサーバの無線に近接する別のサブネットにより占有される場合、そのサーバは別のチャネルに切り替わり、クライアントの要求を待機する。すべてのチャネルが占有される場合、サーバ１２は空いたチャネルが見つかるまでチャネルの周期的な変更を続ける。クライアント１６が２つのサーバ１２からのパケットを一貫して検出する場合、クライアント１６はチャネル上に干渉状態があることを認識し、無線リンク内で接続を確立しない。同様に、サーバ１２が別のサーバからのパケットを一貫して検出する場合、そのサーバはチャネル上でのいかなるクライアント接続の確立も試みない。これら２つの対策は、１つのサブネットからのサーバが、近接のサブネットからのクライアントを占有しないことを保証する。さらに、隣接するサブネットの別のサーバが１つのサーバのクライアントを占有することを防ぐために、固有のリンク識別子（ＩＤ）を各サブネット１０について使用してもよい。
【００４１】
クライアント１６は、例えばＣｏｎｎｅｃｔｉｏｎ  Ｒｅｑｕｅｓｔパケットを送信することによりサーバ１２を動作状態にさせることができる。その後クライアント１６はスレーブ・モードに戻る（例えばタイム・アウト・オプションで）。クライアントの要求が受信されると、サーバ１２はＣｏｎｎｅｃｔｉｏｎ  Ｒｅｑｕｅｓｔパケットを周期的に送信し、クライアント１６が上記で説明したようにそれに従うのを待機する（状態９６）。その送信によりクライアントがスレーブ・モードにあることを確認した後、サーバ１２はクライアントの信頼性をテストし（状態９７）、それがパスした場合は、クライアント１６にＣｏｎｎｅｃｔｉｏｎ  Ａｇｒｅｅｍｅｎｔを提供する。認証過程中の任意の時間中にホスト・コンピュータ１３が、クライアント１６が応答するのに必要な時間よりも長い時間をとってしまった場合、サーバ１２はＣｏｎｎｅｃｔｉｏｎ  Ａｇｒｅｅｍｅｎｔパケットを再送信することによりクライアント１６を遅らせるが、クライアント１６からの確認通知は実際上予期していない。Ｃｏｎｎｅｃｔｉｏｎ  Ａｇｒｅｅｍｅｎｔを送信した後、サーバ１２は新しいセッションＩＤを割り当て（状態９８）、そしてクライアント１６が送信を認識通知するのを待機する（状態９９）。通常の通信はその後開始することができる（状態１００）。
【００４２】
まずクライアントをマスタにし、次いでサーバ１２がアウェイクした後でそれをスレーブにすることにより、サブネット１０が動作していない際の、空いたチャネルにおける低干渉が保証される。言うまでもないが、他の実施形態では、サーバ１２はチャネル内の規則的な間隔でクライアント１６についてポーリングする。ただしこうした方式は、サブネット１０が動作していない時でもチャネルをビジーな状態にし、したがって近接するサブネットへのチャネルを否定することがある。
【００４３】
いくつかの実施形態では、複数のクライアント１６（またはシャドー・クライアント１８）が、サーバ１２からの同一の入力でサポートされる。そのような場合、送信する必要があるのはフォワード・データ・パケットの１つのコピー（クライアントＩＤが第１のクライアントのＩＤになっている）だけである。残りのクライアントは、それぞれについてサーバ１２からの別々のコマンド・パケットで、シャドー・クライアントとして扱われる。
【００４４】
複数クライアントのモデルでは、クライアント１６の１つが遅れてウェイクアップすると、それは静止（Ｑ）スロットを待機し、そのスロット中にそのコマンド・パケットの送信を開始する。ただし複数のクライアントがサーバ１２の後にウェイク・アップする可能性もあり、その場合本技術は、２つまたはそれ以上のクライアント１６がそれぞれＱスロット中に送信を試みる場合に、生じる可能性のある衝突を解決する手段を用意している。そのような衝突を回避するために、クライアント１６はそれぞれの要求をＱスロット内に挿入する（またはしない）ことを任意に選択することができる。サーバ１２により最初に認識されるクライアント１６は最初にサブネット１０に追加される、などである。
【００４５】
下の表３（Ｔｘは送信状態の無線装置１４を、Ｒｘは受信状態の無線装置１４を表す）は、複数クライアントのモデルおよび新しいクライアントをオンラインに挿入するための一般な状態図を詳述する。
【表３】
0003821424.tif 000004
【００４６】
指定された時間スロット配列であるので、１つのクライアントが何らかの理由で遅れて応答する場合、他のクライアントはその指定された時間スロットを把握することができない。これにより貴重な帯域幅を無駄にしてしまうことがある。したがって、本技術はこの問題に対して２つの要素からなる解決法を提供する。
【００４７】
第１に、各クライアント１６はチャネルを占有している現在のクライアントを追跡するよう要求され、それによりライン中でそのすぐ直前にあるクライアントの検出を試みる。チャネルが静止である場合、現在のクライアントはそれ自体の送信を開始する前に所定の長さの時間待機する。待機時間は、２つのクライアント間で許される静止時間のしきい値、および現在のクライアントの前にこれから送信するクライアントの数によって決まる。これは接続セット・アップ中に確立される送信の順序を用いる。静止時間にとって唯一の例外は、すべてのオンライン・クライアント１６が送信を抑制しなければならないＱスロットである。
【００４８】
第２に、サーバ１２は任意のチャネルのテークオーバを監視し、一貫して遅延しているクライアントを接続／切断するために適切な処置をとる。そのような応答内の遅延が生じた時は、ビデオ生成クライアント／サーバはそれに応じて次のビデオ・スロット内の出力データのサイズを縮小する。これにより適切なスロット時間の同期化を維持することができる。映像生成クライアント／サーバは、使用されていないチャネル長を把握し、現在の／次のビデオ・スロット中にその出力を適切に縮小する。
【００４９】
新しいクライアントを接続するために、スロットＱのサイズは、少なくともＣｏｎｎｅｃｔｉｏｎ  Ｒｅｑｕｅｓｔパケットを伝搬する１つの無線データフレーム４０と同じくらいの長さであるべきである。すなわち、新しいクライアント１６はすべてのデータ・フレームを受信し、現在のセッション中のデータ・フレーム構造を学習し、最後のオンライン・クライアントとサーバ１２の送信の間のスロットＱ内に接続に対するその要求を挿入する。その要求は、いくつかのトランザクション（すなわちサーバ送信の間）についてのその一貫性についてチェックした後で確認される。無線ターン・アラウンド時間を念頭に置き、Ｑスロットと混同しないように注意されたい。これはタイマーを使用して検証してもよい。
【００５０】
サーバ１２がその接続要求を認識したことを新しいクライアントに通知するために、サーバ１２はパケットを新しいクライアントに送信する必要がある。すなわちサーバ１２は、サーバに続いてその送信を開始することになっている最初のクライアント（すなわちスロットＢ1を割り当てられているクライアント）が、Ｆスロットの最後にサーバ１２により新しいクライアントに対して送信される最後のパケットと重ならないようにする必要がある。したがって、サーバはＴｏｋｅｎ  Ｐａｓｓをその送信の最後にブロードキャストすることができる。そしてライン中の最初のクライアントは、サーバ１２からＴｏｋｅｎ  Ｐａｓｓを受信した後に（および必要であれば、無線ターン・アラウンド時間を許可後で）、または使用されていないチャネルをタイム・アウトした後にその送信を開始する。
【００５１】
上記で説明したように、チャネルが変更されると、すべてのクライアント１６はサーバ１２に対して再同期する必要がある。チャネルの切換えは、サーバ１２またはクライアント１６の１つが深刻なチャネル障害（例えばアンテナの多様性および／または高程度のＥＣＣにもかかわらず）を体験した際に起こることがある。このようなモデルでは、サーバ１２は干渉がそれより深刻でないチャネルを検出しようと試みて、別のチャネルを探す。新しいチャネルが通信動作のためによりよい見込みを与えると判定した場合、サーバ１２はチャネル変更またはスイッチ動作を開始する。
【００５２】
図８はサーバ１２から見た、２チャネルのサブネットについてのチャネル変更の手順を示す。通常の通信中（状態１０１）に、チャネル状況が容認不可能であるまたは容認不可能になりつつあるとサーバ１２が判定する場合、新しいチャネルの探索を開始する前に、サーバ１２はすべてのそのクライアント１６に一時的に静止の状態でいるように通知する。この手順は複数回数繰り返され（状態１０２）（例えば５回）、メッセージがすべてのクライアント１６によって受信されることを確実にする。クライアントはそれに応答して確認通知を送信することを求められるが、確認通知がオンラインのすべてのクライアント１６から受信されない場合でも、サーバ１２のタイマーはタイム・アウトし、サーバ１２がその無線１４を調整して他のチャネルを検査できるようにする（状態１０４）。新しいチャネルが空いている場合、サーバ１２は本来のチャネルにスイッチ・バックし（例えば一実施形態については４ミリ秒の所定の受信待機期間の後で）、Ｃｈａｎｇｅ  Ｃｈａｎｅｌメッセージを（おそらくは５回ほど繰り返し）すべてのオンライン・クライアント１６にブロードキャストし、クライアント１６について個々のチャネルＣｈａｎｇｅ  Ｃｈａｎｎｅｌ  Ａｃｋｎｏｅｌｅｄｇｅ（Ａｃｋ．）メッセージの受信を待機する（状態１０６）。各クライアント１６は、そのＣｈａｎｇｅ  Ｃｈａｎｎｅｌ  Ａｃｋ．メッセージを送信した後にのみチャネルを変更する。所定の長さの時間待機した後で、サーバ１２がなお１つまたは複数のオンライン・クライアント１６から応答を受信していない場合、サーバ１２はクライアントは到達不能であると判断する。同様にクライアント１６は、所定の期間待機してもサーバからメッセージを受信しない場合サーバ１２は連絡不可能であると判定し、任意でチャネルを変更することができる。すべてのオンライン・クライアント１６が応答した後かまたはタイム・アウト状況の後に、サーバ１２は新しいチャネルに切り替わる。
【００５３】
新しいチャネルに入ると、クライアント１６はサーバ１２が通信を開始するのを待機する。サーバ１２は、Ｃｈａｎｇｅ  Ｃｈａｎｎｅｌ  Ａｃｋ．メッセージをブロードキャストし（状態１０８）、それが新しいチャネルにあることを知らせ、各クライアント１６からのＣｈａｎｇｅ  Ｃｈａｎｎｅｌ  Ａｃｋ．を待つ。１つまたは複数のクライアント１６が所定の試行回数内に応答しない場合、サーバ１２はクライアント１６は一時的に不在であると判定する。それに応じて、サーバ１２はクライアント１６の応答シーケンスを変更して（例えば新しいＣｏｎｎｅｃｔｉｏｎ  Ａｇｒｅｅｍｅｎｔを送信することにより）、不在のクライアントを締め出すようにする。すべてのクライアント１６がそれらが新しいチャネル内にあることを確認する（またはタイム・アウト期間が切れる）のを待機（状態１１０）した後、サーバ１２は新しいチャネルに対してコール−応答スロット・シーケンスを更新し、新しい接続同意をすべてのクライアント１６に送信する。通常の通信はその後に再開することができる（状態１１２）。
【００５４】
クライアント１６が新しいチャネルに遅れて到達する場合、クライアントはサーバの呼が応答するのを待機する必要がある。サーバ１２がクライアント１６は不在であるとすでに判断している場合、クライアント１６は通常の通信が再開するまで待機し、そしてＣｈａｎｇｅ  Ｃｈａｎｎｅｌ  Ａｃｋ．メッセージを静止（Ｑ）スロット内で送信する。そのようなメッセージを受信するとサーバ１２は接続同意を送信し、ネットワーク内の新しいクライアントを含む。
【００５５】
この時間中、新しいクライアントに関連するどのユーザにも影響を及ぼさないでおくために、２つの措置がとられる。第１に、すべてのクライアント１６はユーザ・レベルで円滑なセッションをシミュレートするために、ビデオ・フレーム・フリーズおよび／または音声の反復を行う。第２にサーバ１２は、再接続を容易にするのに十分な長さの所定期間、セッションの詳細を維持する。所定の待機期間が満了した後にのみ、不在のクライアント１６はサーバのオンライン・クライアント・リストから最終的に削除される（状態１１４）。
【００５６】
サーバ１２が、非常に新しいクライアント１６からそれがオンライン・リストから削除された後にＣｈａｎｇｅ  Ｃｈａｎｎｅｌ  Ａｃｋ．メッセージを受信する場合、クライアント１６はＣｏｎｎｅｃｔｉｏｎ  Ｒｅｑｕｅｓｔを送信することにより新たに接続するように通知を受ける。このような場合、クライアント１６はユーザにリンクが失われたことを通知することができる。これはユーザ・レベルではパワー障害に類似のものに見え、ユーザにサーバ１２とのリンクを再確立するよう指示をすることがある。
【００５７】
チャネル選択中に（例えば最初に、またはチャネル変更動作の一部としての）、サーバ１２は現在のチャネル上ですでに動作しているサブネット１０、および同一のＰＮコードおよび／またはリンクＩＤを持つリンクの潜在的な存在を検出する必要がある。そのような事例が発生する可能性は非常に低いと予想されるが、ゼロではない。リンクＩＤは、リンク／サブネット／セルに固有であると想定されている。この固有性を保証するために、ユーザはサブネットのインストール中に固有のパスワード（例えば社会保障番号または同様の長さの他の固有の英数文字列）を入力するよう指示されることがある。このパスワードは、サーバ１２（および／またはそのホスト・コンピュータ１３）により構文解析されて固有のＩＤおよびＰＮコードを確定するために使用してもよい。これらの値は、ユーザがそれを変更する（例えばサブネット１０を再インストールすることにより）と決定しない限り、すべてのセッションについて同一のままである。
【００５８】
一実施形態では、より長いビット長を使用して固有性を保証しそれによりさらなる安全性を提供することもできるが、１１ビットのＰＮコード（バーカー・コード）を使用することもできる。使用可能なＰＮコードのテーブルがサーバ１４／ホスト・コンピュータ１３により維持され、ユーザが入力するパスワードに基づいてそのコードの１つが選択される。隣接するサブネット１０内で同一のＰＮコードが使用されたために干渉が増大した際はいつでも、ＰＮコードを変更してよい。
【００５９】
両方のチャネルが占有されるかまたは大きな干渉がある場合、サーバ１２は２つの動作のうち１つをとることができる。そこへのまたはそこからのチャネル干渉が深刻であるクライアント１６の数が少ない場合、サーバ１２はそれらを切断することを決定する。一方、関係するクライアント１６の数が多い場合、サーバ１２はしばらく待機し、ある程度の時間が経ってからチャネルを試行することを決定する。いずれの場合もサーバ１２は、影響を受けるクライアント１６それぞれからＤｉｓｃｏｎｎｅｃｔ  Ａｃｋ．メッセージを受信するまで、Ｒｅｔｒｙ  Ｌａｔｅｒコマンドを関係するクライアント１６それぞれに送信する必要がある。
【００６０】
次に図９に、例示的な２チャネルのサブネットについて、クライアント・サイドからのチャネル切換え動作を図示する。通常の通信中（状態１２０）にクライアント１６が静止でいるように指示を受けた場合、そのクライアント１６は確認通知（例えばＤｉｓｃｏｎｎｅｃｔ  Ａｃｋ．）を送信し、そしてサーバ１２からのさらなる指示を待つ（状態１２２）。サーバ１２がＣｈａｎｇｅ  Ｃｈａｎｎｅｌメッセージをブロードキャストする場合、クライアント１６はそれを確認しそれからチャネルを変更する。別の方法として、所定の時間待機してもサーバ１２からメッセージを受信しない場合、クライアント１６はサーバ１２は到達不可能であると判定し、自発的にチャネルを変更してもよい。
【００６１】
新しいチャネルに入ると、クライアント１６はサーバ１２が通信を開始するのを待機する（状態１２６）。サーバ１２はＣｈａｎｇｅ  Ｃｈａｎｎｅｌ  Ａｃｋ．メッセージをブロードキャストして新しいチャネル内にそれがあることを通知し、各クライアント１６からＣｈａｎｇｅ  Ｃｈａｎｎｅｌ  Ａｃｋ．を求める。それに応じてクライアント１６はサーバが新しいチャネル内にあることを確認し、サーバ１２からの新規接続同意を待つ（状態１２８）。その接続同意をサーバ１２とネゴシエートすると、クライアント１６は通常の通信が再開するのを待機する（状態１３０）。
【００６２】
クライアント１６が新しいチャネルに到達するのが遅い場合、クライアントはサーバのコールが応答するのを待機する必要がある。サーバ１２がクライアント１６は不在であるとすでに判定している場合、クライアント１６は通常の通信が再開するまで待機し、それからＣｈａｎｇｅ  Ｃｈａｎｎｅｌ  Ａｃｋ．メッセージを静止（Ｑ）スロット内で送信する（状態１３２）。そのようなメッセージを受信するとサーバ１２は接続同意を送信し、新しいクライアントをネットワーク内に含む。この時間中、新しいクライアントに関連するいずれのユーザにも影響を及ぼさないでおくために、クライアント１６はビデオ・フレーム・フリーズおよび／または音声反復を行い、ユーザ・レベルで円滑なセッションをシミュレートすることができる。
【００６３】
サーバ１２が非常に新しいクライアント１６からそれがオンライン・リストから削除された後にＣｈａｎｇｅ  Ｃｈａｎｎｅｌ  Ａｃｋ．メッセージを受信する場合、クライアント１６はＣｏｎｎｅｃｔｉｏｎ  Ｒｅｑｕｅｓｔを送信することにより新たに接続するよう通知を受ける。このような場合、クライアント１６はユーザにリンクが失われたことを通知することがある（状態１３４）。これはユーザ・レベルではパワー障害に類似のものに見え、ユーザにサーバ１２とのリンクを再確立するように指示をすることがある。チャネル選択中に、クライアント１６がサーバ１２とのコンタクトを長時間失った場合、クライアントはユーザに状況を通知しターン・オフすることがある（状態１３６）。
【００６４】
クライアント１６と同様に、サブクライアント２０もオンラインで動作中のサブネットに加えることができる（すなわちホット・インサーションとも呼ばれる）。図１８に示すように、サブクライアント２０はウェイク・アップすると、それに関連するクライアントに通信リンク２１を介して登録パケットを送信する（状態２２０）。いくつかの場合、通信リンク２１は無線リンク（例えば赤外線通信リンク）であり、他の場合では有線リンクであることもある。クライアント１６はサブクライアント２０からの送信を受信すると、例えばその登録識別情報を知られている／認証済みのサブクライアントのリストに照らしてチェックすることにより、サブクライアントを認証する（状態２２２）。場合によっては、これはサーバ１２との通信を必要とすることもある。サブクライアント２０が承認される場合、クライアント１６は、新しいサブクライアントをネットワーク上でクライアントと動作している他のサブクライアントから独自に識別する、サブクライアント・セッション識別子を構成する。次いでクライアント１６は、Ａｄｄ  Ｓｕｂｃｌｉｅｎｔコマンド（下記をさらに参照のこと）をサーバ１２に送信する（状態２２４）。Ａｄｄ  Ｓｕｂｃｌｉｅｎｔコマンドは、サブクライアント・セッション識別子、および下記でさらに詳しく説明されるサブクライアントの特徴を含む。
【００６５】
サーバ１２はＡｄｄ  Ｓｕｂｃｌｉｅｎｔコマンドを受信すると、サブクライアント・セッションＩＤを記録することにより、およびサブネットが新サブクライアントの追加を受け入れられるか（例えば、新サブクライアントからまたはそれに送信されるコマンドを受け入れるために、無線リンク上で十分な帯域幅が使用できるか）どうかを判定することにより、サブクライアント認証プロセスを完了する（状態２２６）。認証プロセスがうまく行く場合、サーバは、新サブクライアントをオンラインのサービス・テーブルに挿入することにより、および関連するクライアントにＳｕｂｃｌｉｅｎｔ  Ａｄｄｅｄコマンドを送信することにより、新サブクライアントをサブネットに追加する。新サブクライアントを受け入れることができない場合、あるいは新サブクライアントが別の形で拒否される場合、サーバはＳｕｂｃｌｉｅｎｔ  Ｎｏｔ  Ａｄｄｅｄコマンドを送信する。
【００６６】
サーバがどのような判断を行っても、認証プロセスの結果はクライアントからサブクライアントに送信される（状態２２８）。サブクライアントが承認された場合、それは通常の動作を開始しそのクライアントおよびサーバ１２と通信を行う（状態２３０）。サブクライアントが拒否された場合は、切断される（状態２３２）。いずれの場合も、ユーザには、表示装置に表示される適切な状態メッセージを通してサブクライアントの追加または拒否が通知される。
【００６７】
ネットワーク動作中に、サブクライアント２０はサーバ１２または関連するクライアント１６のいずれかにより切断されることがある。例えばサブクライアント２０が所定の長さ以上の時間にわたって非アクティブである場合、クライアント１６はサブクライアント２０との接続を解除することがある。そのような場合クライアント１６はサーバ１２に状況を通知し、切断されたサブクライアントをオンライン装置のサーバのリストから除去するよう要求しなければならない（下記のＤｅｌｅｔｅ  ＳｕｂｃｌｉｅｎｔおよびＳｕｂｃｌｉｅｎｔ  Ｄｅｌｅｔｅｄコマンドについての説明を参照されたい）。
【００６８】
他の場合では、例えばホスト１３上で動作中のアプリケーションが特定のサブクライアント（または、さらに言えばクライアント）をサポートしない場合、サーバ１２はサブクライアント２０を直接除去することを決定してもよい。またネットワーク維持およびシャットダウン動作も、サブクライアント（およびクライアント）を自動的に削除されることを要求することがある。
【００６９】
Ｃ．ネットワーク・パケット構造
図１０に示すように、無線リンク内を送信されたパケット４２には３つの主要な部分がある：ヘッダ１４０、可変長ペイロード１４２、ＥＣＣブロック１４４である。図１１に詳細を示すようにヘッダ１４０は、クライアントＩＤについてのフィールド１４６、タイム・スタンプ１４８、ＳＴＰ１５０、パケット長１５２を含んでいる。いくつかのパケット（例えばオーディオ・パケットおよびいくつかのコマンド）４２は、ホスト・コンピュータ１３で発信し、したがってサーバ１２に対する入力である。ただしサーバ１２は、関連する無線装置１４にパケット４２を書き込む前に、タイム・スタンプ１４８をこれらのパケット４２に加える（例えば受信側における適切な同期化を可能にするために）。
【００７０】
１つの例示的実施形態では、ヘッダ１４０はダブル・ワード（ＤＷＯＲＤ、例えば一実施形態では３２ビット）であり、パケット４２へのまたはパケット４２からのデータの書き込みおよび読み出しが、どの８／１６／３２ビットのハードウェア構造においてもより少ないプロセッサ時間の消費で処理されるように位置合わせされる。クライアントＩＤフィールド１４６は１バイトの長さであり、サブネット１０内のクライアント１６に対して固有のものである。これにより、サーバ１２ごとに２５５の異なるクライアント１６をサポートすることができる。特別なクライアントＩＤ（例えばすべての「１」）はブロードキャストのために確保しておくことができ、他のクライアントＩＤ（例えばすべての「０」）はサーバ１２のために確保しておくことができる。タイム・スタンプ１４８は、オーディオおよびビデオ・パケットをいずれ同期するために加えられる。タイム・スタンプ１４８は、サーバ１２で維持される時間カウンタの出力として与えられる。クライアント１６およびホスト・コンピュータ１３は、入ってくるパケット内で提供されるタイム・スタンプ１４８を使用して、それぞれの時間カウンタを同期することができる。
【００７１】
ＳＴＰフィールド１５０は、パケットのソース（Ｓｏｕｒｃｅ）、パケット内に含まれているデータのタイプ（Ｔｙｐｅ）、現在の時間スロット内でのパケットの位置（Ｐｏｓｉｔｉｏｎ）についての情報を提供する。このフィールドは３つのサブフィールド（図示していない）に分割される。上部のサブフィールド（一実施形態では３ビットの長さ）は、パケットのオリジンを表すために使用される（例えばサーバ１２についてはすべての１、クライアント１６についてはすべての０）。ただし、このフィールドは、サーバ１２とそのホスト・コンピュータ１３の間で交換される通信パケットについては無視される。パケット４２が受信されると、パケット４２のオリジンを決定するために、このフィールド内のデータを使用して多数決論理ヴォーティングが実行される。
【００７２】
ＳＴＰフィールド１５０の中間サブフィールド（この実施形態についても３ビットの長さでよい）は、パケット・タイプを表す。サポートされるタイプには：オーディオ・パケット、ビデオ・パケット、データ・パケット（例えばキーボード、マウス、ジョイスティックなどの出入力装置からの）、クライアント１６からまたはクライアント１６へのコマンド・パケット、サーバ１２からまたはサーバ１２へのコマンド・パケットが含まれる。プロトコル方式は、ビデオ、音声、サーバ１２とクライアント１６との間のコマンド、またサブネット１０内のサブクライアント２０からの低帯域幅データの転送を可能にする。低帯域幅データの例には、キーボード入力、マウス入力、アナログ・ジョイスティック入力などが含まれる。オーディオおよびビデオは別々のパケットで通信され、無線装置１４により別々のデータ・フレーム４０として送信される。ただし低帯域幅データ・パケットはコマンド・パケットと組み合わせて、１つのデータ・フレーム４０として送信してもよい。
【００７３】
ＳＴＰフィールド１５０の最後のサブフィールド（サブフィールドのＰｏｓｉｔｉｏｎ）は２ビットの長さであり、どこでパケットがパケットのグループ内に入るかを指定する。このフィールドは、下記（１つの値はＤＯＮ’Ｔ  ＣＡＲＥでよい）のように表される値を有する。
【００７４】
Ｆｉｒｓｔ  Ｐａｃｋｅｔ：これは現在のパケットがソースから送信される最初のパケットであり、その後にまだパケットがあることを示す。
Ｃｏｎｔｉｎｕａｔｉｏｎ  Ｐａｃｋｅｔ：これは、現在のパケットの後に、同一のソースからのパケットが少なくとも２つあることを示す。
Ｏｎｅ  Ｂｅｆｏｒｅ  ｔｈｅ  Ｌａｓｔ  Ｐａｃｋｅｔ：これは、現在のパケットの後には、同一のクライアント１６（またはスロットＦ中のサーバ１２）からのパケットが１つだけあることを示す。
Ｌａｓｔ  Ｐａｃｋｅｔ：これは現在のパケットが現在のクライアント１６（またはスロットＦではサーバ１２）からの最後のパケットであることを示す。
【００７５】
このフィールド内の情報を使用することにより、ライン中の次に送信をするクライアント１６は、先行するクライアント１６による送信の終了を少なくとも１パケット早く検出することができる。最後のパケット４２の受信中に、それはその関連する無線装置１４に、そのパケットの後で送信モードに切り替わるよう指示を出す。
【００７６】
パケット・フィールド１５２の長さは、現在のパケット４２中にあるＤＷＯＲＤの数を示す。長さゼロのパケットは使用されないことが好ましいので、ＤＷＯＲＤの実際の数は、長さフィールド１５２で示される長さより１つ多くてよい。
【００７７】
ペイロード・フィールド１４２はパケット４２の本体である。オーディオ・パケットおよびビデオ・パケットに関しては、このフィールドはそれぞれのソースからの圧縮されたオーディオ・データまたはビデオ・データ（適切に応じて）を含む。データ・パケットについては、ペイロード・フィールドはキーボードまたはマウスなどの出入力装置によって生成されたデータを含む。
【００７８】
図１２にデータ・パケット１５４のペイロード構造を示す。好ましくはサブクライアント・タイプ（ＳＣＴ）１５６、サブクライアントＩＤ（ＳＣＩＤ）１５８、データ長１６０は実際のデータ１６２より前に現れ、受信側がデータ生成装置のソースを学習するのを援助するとよい。１つ以上のデータのセット１６２を単一のデータ・パケット１５４内に含んでもよく、その場合各データ・セットはそれ自体のＳＣＴ、ＳＣＩＤおよび長さパラメータを必ず有する。
【００７９】
ＳＣＴフィールド１５６は、受信側にキーボード、マウス、アナログ・ジョイスティックなど情報ソースのタイプを備え、ＳＣＩＤフィールド１５８はその特定のサブクライアント・タイプの個々のサブクライアントを識別する。例えば、キーボードおよびマウスは同様のサブクライアントＩＤを有しうるが、それらの異なるサブクライアント・タイプをそれぞれのＩＤと関連付けることにより区別することができる。この種のプロトコル・サポートにより、実行中のセッションの最中またはその前の任意の時間に、異なる種類の低帯域幅のサブクライアント２０を、同一のクライアント１６に追加することが容易になる。ＳＣＴフィールド１５６およびＳＣＩＤフィールド１５８はともに８ビットの幅でよく、それにより２５６の異なるタイプのサブクライアント２０をサポートし、各タイプにつき２５６までのサブクライアントが各クライアント１６に接続可能である。
【００８０】
データ要求は長さフィールド１６０を含まない。ただしデータ送信は長さフィールド１６０を含み、その長さフィールド１６０は１バイトの長さでよく、後に続くデータの長さを指定する。実際の低帯域幅データ１６２自体は長さフィールドの後に続く。一実施形態については、これらのパケット１５４の全長は各ビデオ・フレームにつき１２０バイトを超えてはならない。
【００８１】
コマンド・パケットについては、ペイロード・フィールド１４２は一連のコマンドを含み、各コマンドの後には関連するデータ・バイト、および／またはサブクライアント２０からの低帯域幅データが続く。すなわちこの実施形態では、サーバ１２は、無線リンクを介してクライアント１６に次々に送信される必要のあるすべてのコマンドを、１つのデータ・パケット４２内にまとめている。したがって、サーバ１２が送信するコマンド・パケットの最大数は、サーバ１２が現在サポートしているオンライン・クライアント１６の数と等しくなる。それとは反対に、各フレーム中にサーバ１２に送信される必要のある、コマンドのシーケンスおよび／またはその関連するサブクライアント２０からの低帯域幅データを含むコマンド・パケットは、どのクライアント１６からも最大で１つだけしかない。
【００８２】
以下では無線リンク間の通信の各方向でサポートされるコマンドについて説明する。別に指摘しない限り、この実施形態ではサーバ１２／クライアント１６から送信されるどのパケットについても確認通知（Ａｃｋ．）は求められない。任意の数のコマンドをともに並べてデータ・パケット４２を形成することができ、その場合唯一の制限はオーバーオール・パケット４２のサイズである。この実施形態については、パケット４２の合計サイズは、各ビデオ・フィールド継続期間につき８０バイトを超えてはならない。他のパケット・サイズは、多様な入力装置（例えばキーボード、マウス、ジョイスティックなど）の帯域幅要件の考慮に基づいて選択することができる。図１３にはコマンド・パケット１６４についての一般的なペイロード構造を示す。各コマンド・パケット１６４は、ヘッダ１６６、および「ｎ」コマンド・フィールド１６８を含む。コマンド・フィールド１６８はコマンド１７０、およびあれば関連するいずれのペイロード１７２を含むこともある。関連するペイロード１７２がない場合、コマンド・フィールド１６８は単一バイトの長さである。いくつかのコマンド１７０については、関連するペイロード１７２は所定のサイズである。さらに他のコマンド１７０は、可変長のペイロード１７２を有することがある。そのような場合、ペイロード長はペイロード・フィールド１７２の前に（またはその中で）明確に指示される。
【００８３】
１．クライアント１６へのまたはクライアント１６からのコマンド
サーバ１２からクライアント１６へのコマンドのセット、およびクライアント１６からサーバ１２へのコマンドのセットは本技術によりサポートされる。サーバ１２は、そのホスト・コンピュータ１３とは無関係にコマンドの大半を処理するように構成される。大きなテーブル（例えばサーバ１２によってローカルに格納することができないもの）へのアクセスおよびユーザ入力に伴う決定だけは、ホスト・コンピュータ１３に渡す（およびホスト・コンピュータ１３から発する）必要がある。サーバ１２が各コマンド・パケット１６４を読み出す／コンパイルする際、そうした情報が有用でありうる場合には（例えば、サーバ１２が特定の各クライアント１６について同一の同意された制約を固守する必要がある、Ｃｏｎｎｅｃｔｉｏｎ  Ａｇｒｅｅｍｅｎｔのようなコマンドについて）、パケットのコピーをそれ自体のために保存しておくよう決定することがある。一実施形態では、サポートされるコマンドは下記のものを含むことがある。
【００８４】
Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｑｕｅｓｔ：これはペイロードがないパケットである。各クライアント１６はこのコマンドを使用して、サーバ１２にそれが始動中でありサービスを必要としていることを知らせる。サーバ１２は同一のコマンドを使用して応答する。クライアント１６およびサーバ１２は、適当な時間同期が実現されるまでこのコマンドを互いに繰り返し送信する。同期化が実現されると、サーバ１２はマスタになり、クライアント１６の信頼性をチェックする。認証手順がうまく行かない場合、サーバ１２はＤｉｓｃｏｎｎｅｃｔ  Ｒｅｑｕｅｓｔ（Ｒｅｑ．）コマンドを送信することによりクライアント１６を拒否する。クライアント１６はＤｉｓｃｏｎｎｅｃｔ  Ａｃｋ．を送信することにより応答することが求められる。一方、クライアント１６の認証がうまく行った場合、ホスト・コンピュータ１３はＣｌｉｅｎｔ  Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  Ｐａｓｓメッセージをサーバ１２に送信する。サーバ１２は、クライアント１６のスループット要求を受け入れることが可能であるかどうかをチェックする。可能でない場合、サーバはＲｅｔｒｙ  Ｌａｔｅｒコマンドをクライアント１６に送信することにより、クライアントに後で接続を再試行するように通知する。このような場合、クライアント１６はＤｉｓｃｏｎｎｅｃｔ  Ａｃｋ．を送信することにより応答するように求められる。サーバ１２はクライアント１６の受け入れを決定すると、Ｃｏｎｎｅｃｔｉｏｎ  Ａｇｒｅｅｍｅｎｔｓパケットをクライアント１６に送信することにより接続許可を暗に示す。
【００８５】
図１７に、例示的Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｑｕｅｓｔパケット２１０の構造を図示する。Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｑｕｅｓｔパケット２１０は、接続要求コマンド・フィールド２１２、クライアント連続番号フィールド２１４、クライアント特性フィールド２１６を含む。連続番号フィールド２１４およびクライアント特性フィールド２１６中に含まれている情報は、サーバ１２に対する個々のクライアントを識別するために機能する。こうした情報は製造時にクライアント内のメモリ（例えば読み出し専用メモリ）中に格納することができ、クライアントのタイプ、製造者、ドライバ情報、他のクライアント識別情報を含むことができる。クライアントがサブネットへのアクセスを許可されようとする場合、サーバ１２は、パケットをクライアント１６に送信する最中に、クライアント・セッションＩＤ２１８をパケットに加えることができる。その後、クライアントはサーバ１２へのその送信の際に、セッションＩＤ情報を利用することができ、冗長な連続番号および特性フィールドを毎回再送信せずにすむ。したがって、クライアント・セッションＩＤ２１８は、クライアント１６をサーバ１２に対して識別する際の簡略な方法として機能し、また必要であればサーバ１２が特定のクライアント１６を行先とするデータおよびコマンドをアドレス指定できるようにもする。これにより全体の帯域幅が節約できる。
【００８６】
Ｃｏｎｎｅｃｔｉｏｎ  Ａｇｒｅｅｍｅｎｔｓ：サーバ１２はこのコマンドを３つの目的で使用する。第１に、接続認可を新しいクライアント１６に暗示するため、および接続の条件を指定するため（例えば、サーバ−クライアントおよびクライアント−サーバの帯域幅に関しては、ＥＣＣタイプ、オーディオ／ビデオ情報の圧縮タイプなど）。第２に、クライアント１６がこのコマンドをセッション中に受信すると、そのコマンドは以前にネゴシエートされた接続同意内の強制的変更を暗示する（例えば、チャネル状態の不良、新しいクライアントがサブネット１０に追加されたなどの理由で）。第３に、特定のクライアント１６が所定の時間（比較的長い）静止していることにサーバ１２が気付くと、サーバ１２は、以前にネゴシエートされた接続を事実上変更することなく、Ｃｏｎｎｅｃｔｉｏｎ  Ａｇｒｅｅｍｅｎｔｓパケットを送信し、それと引き換えに確認通知を求める。クライアント１６と接触するために所定の回数の試行を行っても確認通知が受信されない場合、クライアント１６は切断されていると宣言される。いくつかの場合では、例えばクライアント１６がサーバのデータ転送速度に対処できない場合には、これと同一のコマンドはクライアント側から発することもあることに注意されたい。
【００８７】
一実施形態では、Ｃｏｎｎｅｃｔｉｏｎ  Ａｇｒｅｅｍｅｎｔコマンドについての合計のペイロード・サイズは５バイトであり、パケット構造１７４に含まれるネゴシエーションの項を図１４に示す。Ｃｏｎｎｅｃｔｉｏｎ  Ａｇｒｅｅｍｅｎｔパケット１７４は、パケットを識別する接続同意コマンド１７６で始まる。フォワード帯域幅フィールド１７８は、クライアントがサーバから受信することを期待できるパケットの数を指定するために使用される。リバース帯域幅フィールド１８０は、クライアントがそのリバース・スロット中にサーバに送信しうるパケットの数を指定するために使用される。これらのフィールドは、各方向のビデオ、オーディオ、データ帯域幅も定義する。ＰＣＬ−ＩＤフィールド１８６は、先行するクライアント（８ビット）のＩＤを指定する。サーバ１２の後に送信を許可される最初のクライアントは、ゼロ（０）をそのＰＣＬ−ＩＤとして受信する。ＣＮＵＭ１８８は、クライアント・オンライン番号であり、クライアント１６に現在のオンライン・サービス・リストにおいてそれに先行するクライアントの数を知らせる。
【００８８】
ＳＣＡ（送信クライアント属性）１９０は、クライアント１６にそのプロパティまたは属性が必要とされているかいないかを知らせるために、サーバ１２によって使用される制御フィールドである。例えばＳＣＡ１９０がすべて１にセットされる場合、これはクライアント１６がそのプロパティをサーバ１２に送信する必要があることを示す（例えばクライアントのプロファイルが間違って消された場合、または新しいクライアントの設置である場合）。サーバ１２はパケットを繰り返して（タイム・スタンプの変更とともに）これらのプロパティを受信したことを確認通知し、その後でクライアント１６はＣｏｎｎｅｃｔｉｏｎ  Ａｇｒｅｅｍｅｎｔ  Ａｃｋ．を送信する。一方、ＳＣＡフィールド１９０がすべて０にセットされる場合、これは以前に定義されたプロパティをクライアント１６が固守するか、またはログ・アウトすることをサーバ１２が要求していることの指示として使用される。ＳＣＡ１９０中の任意のビットが、無線リンクを送信されている間に破壊されてしまった場合は、反復中の固有の冗長がサーバ１２／クライアント１６で使用されて（例えば多数決論理ヴォーティングにより）、その実際の内容を判定する。
【００８９】
Ｃｏｎｎｅｃｔｉｏｎ  Ａｇｒｅｅｍｅｎｔ  Ａｃｋ．：このパケットはクライアント１６を発信元とし、Ｃｏｎｎｅｃｔｉｏｎ  Ａｇｒｅｅｍｅｎｔｓコマンドに応答して送信される。これはペイロードのないパケットである。
【００９０】
Ａｄｄ  Ｓｕｂｃｌｉｅｎｔ：各クライアント１６は、それがサポートする必要があるサブクライアント２０を決定することについて責任を負い、このコマンドを使用してサーバ１２に同一の内容を報告する。これによりサーバ１２は、必要とされている帯域幅を割り振ることができる。帯域幅要件が満たされる場合、サーバ１２はホスト・コンピュータ１３にサブクライアント２０について通知し、ホスト・コンピュータ１３が関連するドライバをロードできるようにする。図１５に示すように、サブクライアント追加パケット１９２は、コマンドＩＤ１９４、ならびにサブクライアント・セッションＩＤ（ＳＳ−ＩＤ）１９６、サブクライアント・タイプ（ＳＣＴ）１９７、サブクライアントＩＤ（ＳＣＩＤ）１９８を含むことができる。ＳＳ−ＩＤ１９６は上記で説明したクライアント・セッションＩＤと同様の目的をサービスし、ＳＳ−ＩＤ１９６およびＳＣＩＤ１９８は、サブクライアント２０がウェイク・アップする限り、サーバ１２および対応するクライアント１６により動的に割り振られることができることに注意されたい。
【００９１】
Ｓｕｂｃｌｉｅｎｔ  Ｎｏｔ  Ａｄｄｅｄ：このコマンドはサーバ１２によりクライアント１６に送信され、新しいサブクライアント２０を含むことに成功したことを示す。コマンド・タイプ以外にも、関連づけられたＡｄｄ  Ｓｕｂｃｌｉｅｎｔコマンド内にあるフィールドに類似するＳＣＴおよびＳＣＩＤフィールドを使用してもよい。
【００９２】
Ｓｕｂｃｌｉｅｎｔ  Ｎｏｔ  Ａｄｄｅｄ：このコマンドはサーバ１２によりクライアント１６に送信されて、新しいサブクライアントを追加することが不可能であることを示す。コマンド構造はＡｄｄ  Ｓｕｂｃｌｉｅｎｔコマンドと同じでよい。
【００９３】
Ｄｅｌｅｔｅ  Ｓｕｂｃｌｉｅｎｔ：クライアント１６は応答しないサブクライアント２０はどれもタイム・アウトしてよく、それをサーバ１２に報告する。いくつかの場合では、サブクライアント２０のうち選択されたセットだけをタイム・アウトすることができる。もはや利用されていないサブクライアント２０を削除することで、サーバ１２は以前に割り振られた帯域幅を再使用することができ、またホスト・コンピュータ１３は関連する任意のドライバをアンロードすることができる。パケットはサブクライアント・タイプおよびサブクライアントＩＤを含み、そのコマンド構造はＡｄｄ  Ｓｕｂｃｌｉｅｎｔコマンドと同じであってよい。
【００９４】
Ｓｕｂｃｌｉｅｎｔ  Ｄｅｌｅｔｅｄ：このパケットはＤｅｌｅｔｅ  Ｓｕｂｃｌｉｅｎｔコマンドに応答して、サーバ１２からクライアント１６に送信される。そのコマンド構造はＡｄｄ  Ｓｕｂｃｌｉｅｎｔコマンドについての構造と同じでよい。
【００９５】
Ｒｅｓｅｔ  Ｃｌｉｅｎｔ：このコマンドはサーバ１２を発信元とし、受信するクライアント１６がそれ自体をリセットしてＣｏｎｎｅｃｔｉｏｎ  Ｒｅｑｕｅｓｔ段階から再び開始するよう要求する。これはペイロードのないパケットである。
【００９６】
Ｒｅｓｅｔ  Ａｃｋ．：これはＲｅｓｅｔ  Ｃｌｉｅｎｔコマンドに対する確認通知である。これはペイロードのないパケットである。
【００９７】
Ｄｉｓｃｏｎｎｅｃｔ  Ｒｅｑｕｅｓｔ：このコマンドは、サーバ１２がクライアント１６を除くか、あるいはクライアント１６がターンオフされるかに応じて、サーバ１２またはクライアント１６のいずれかを発信元とする。これはペイロードのないパケットである。
【００９８】
Ｒｅｔｒｙ  Ｌａｔｅｒ：このコマンドはサーバ１２を発信元とし、深刻なチャネル状況または帯域幅制限のいずれかの理由で、現在クライアント１６にはサービスすることができないことをクライアント１６に通知する。こうしたコマンドを受信すると、クライアント１６は同一の情報を関連するユーザに渡し、それによりユーザに後で接続を試みるように指示を出す。このパケットにはペイロードはない。
【００９９】
Ｄｉｓｃｏｎｎｅｃｔｉｏｎ  Ａｃｋ．：これはＤｉｓｃｏｎｎｅｃｔ  ＲｅｑｕｅｓｔおよびＲｅｔｒｙ  Ｌａｔｅｒコマンドに対する確認通知である。これはペイロードのないパケットである。
【０１００】
Ｋｅｙ  Ｆｒａｍｅ  Ｒｅｑｕｅｓｔ：このコマンドはビデオ送信の受信側を発信元とし、受信側でフレームの損失がある場合はいつでも送信される。このコマンドに対する確認通知は、送信側から再送信されたキー・フレームの形をとることがある。これはペイロードのないパケットである。
【０１０１】
Ｃｈａｎｎｅｌ  Ｓｔａｔｕｓ：このコマンドは、規則的な間隔でクライアント１６により自発的に提供されて、サーバ１２にそのチャネル・ステータスを通知する。チャネル・ステータス・バイトはパケットのペイロードを形成し、それは１バイトの長さでよい。
【０１０２】
Ｔｏｋｅｎ  Ｐａｓｓ：これはペイロードのないコマンドであり、送信者からの送信の終了を信号で知らせる。このコマンドは次のクライアント１６（またはサーバ１２）に、送信を開始するよう指示を出す。サーバ１２はその送信を開始するために、最後のクライアント１６からのこのコマンドを待機する。サーバ１２がこのパケットを送信すると、クライアントＩＤはすべて０にセットされ、ストリング中の最初のクライアント１６にその送信を開始するよう指示する。これはダミーの確認通知または「クライアントが生きている」という信号と見ることもでき、その場合サーバ１２は最初にサーバ１２に通知しないでシャット・オフするいずれのクライアント１６を追跡する。同一のコマンドを使用してチャネル変更の完了を指示することもできる。
【０１０３】
Ｒｅｍａｉｎ  Ｑｕｉｅｔ：これはペイロードのないコマンドであり、サーバ１２を発信元とする。サーバ１２はチャネル切換えの前にこのコマンドを使用して、サーバが他のチャネルをチェックして戻るまで静止の状態でいるようにすべてのクライアント１６に通知する。各クライアント１６は、コマンドを確認通知する（例えばＤｉｓｃｏｎｎｅｃｔ  Ａｃｋ．を送信することにより）よう求められる。
【０１０４】
Ｃｈａｎｇｅ  Ｃｈａｎｎｅｌ：これはペイロードのないコマンドであり、サーバ１２を発信元とする。サーバ１２が他のチャネルが現在のチャネルより良好であると判定する場合、サーバはすべてのクライアント１６にチャネルを変更するよう通知する。
【０１０５】
Ｃｈａｎｇｅ  Ｃｈａｎｎｅｌ  Ａｃｋ．：これはＣｈａｎｇｅ  Ｃｈａｎｎｅｌコマンドに応答して、各クライアント１６によりサーバ１２に送信される確認通知である。これはペイロードのないパケットである。同一のコマンドはサーバ１２およびクライアント１６の双方によって使用することができ、チャネル変更の完了／打切りを確認する。
【０１０６】
Ｎｅｗ  ＰＮ  Ｃｏｄｅ：このコマンドはサーバ１２を発信元とし、新しいＰＮコード・ビットおよび変更が実施される時間マークを含んだペイロードを含む。
【０１０７】
Ｎｅｗ  ＰＮ  Ｃｏｄｅ  Ａｃｋ．：これは受信したＮｅｗ  ＰＮ  Ｃｏｄｅコマンドに応答して、各クライアント１６からサーバ１２に送信される確認通知である。各クライアント１６は、新しいＰＮコードを反復して、サーバ１２が適切な受信を確認できるようにする。２つのコードが一致しない場合、サーバ１２はＮｅｗ  ＰＮ  Ｃｏｄｅコマンドを再送信することがある。
【０１０８】
２．ホスト・コンピュータ１３からの、またはホスト・コンピュータ１３へのコマンド
サーバ１２とのホスト・コンピュータの通信は無線リンク上では行われず、２つのレベルで見ることができる。第１のレベルは、従来のハードウェア・ポートおよび低レベルのシグナリングを使用して、「ｔｒａｎｓｍｉｓｓｉｏｎ  ｃｏｍｐｌｅｔｅ」「ｒｅｃｅｉｖｅｒ  ｂｕｆｆｅｒ  ｆｕｌｌ」など、一般にコンピュータ・アプリケーションで使用されている低レベル・メッセージを通信する。第２のレベルは、第１のレベル上に確立され、上記で説明したネットワーク・プロトコル、パケット・フォーマットなどを使用して、クライアントの接続および切断などより高位レベルの情報を伝搬する。通信の第１のレベルは事実上従来式のものであり、これ以上は説明しない。通信の第２のレベルは以下のコマンドを利用する。
【０１０９】
Ｄａｔａ  Ｒｅｑｕｅｓｔ：このコマンドはサーバのメモリの内容に対する要求として、ホスト・コンピュータ１３を発信元とする。サーバ１２は、Ｄａｔａ  Ｓｅｎｄコマンドを使用してデータを提供することにより応答する。同一のコマンドは、ホスト・コンピュータ１３からのデータで特定のメモリのブロックを満たすためにサーバ１２により使用される。コマンド構造は、データがないという点を除いてはデータ送信パケットと同じである。
【０１１０】
Ｄａｔａ  Ｓｅｎｄ：このコマンドはホスト・コンピュータ１３またはサーバ１２を発信元とする。ホスト・コンピュータ１３はこのコマンドを使用して、サーバ１２に格納されているデータの内容を変更する。サーバ１２は、ホスト・コンピュータ１３から要求がある際に、このコマンドを使用してそのデータを供給する。
【０１１１】
データ送信パケット２００のフォーマットを図１６に図示する。示すように、パケットは、コマンド・タイプを識別するコマンドＩＤ２０２を含む。アクセス中のメモリ位置を識別するために、高バイトおよび低バイトのアドレス・フィールド２４０、２０６が含まれる。最終的に、データ・ペイロード２０８自体が提供される。
【０１１２】
低レベルの通信で通常使用されるメールボックス登録がサーバのメモリ位置の内容を格納するには十分でないかもしれないという事実により、データ要求／送信コマンドはここでサポートされる（それは他の実施形態では低レベルのコマンドかもしれないが）。
【０１１３】
Ｃｌｉｅｎｔ  Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  Ｐａｓｓ：このコマンドは、ホスト・コンピュータ１３からサーバ１２に送信され、クライアント１６を受け入れられることを示す。これはペイロードのないコマンドでよい。
【０１１４】
Ｓｈｕｔｄｏｗｎ：ホスト・コンピュータ１３は、シャット・ダウンする前にこのコマンドをサーバ１２に送信する。同一のコマンドは、ホスト・コンピュータ１３が何らかの理由（例えば保護者による規制）でクライアント１６をサポートすることを望まない時間中に使用されることがある。サーバ１２はすべてのクライアント１６との接続を切断し、Ｓｈｕｔｄｏｗｎ  Ａｃｋ．を通じてホストのコマンドに確認通知する。これはペイロードのないコマンドである。
【０１１５】
Ｓｈｕｔｄｏｗｎ  Ａｃｋ．：これはサーバ１２を発信元とする、ペイロードのないコマンドである。このコマンドがパスされた後、サーバ１２はタイム・アウトしシャット・ダウンする。ホスト・コンピュータ１３はシャット・ダウンする前に、この確認通知を待つ（またはタイム・アウトする）。
【０１１６】
Ｄ．ネットワーク事項
ネットワークは、最初のスタート・アップの際にインストールしなければならない。これはサブネット１０間でのＰＮコードの配布を必要とし（例えば２つの隣接するサブネットによる、同一のＰＮコードの使用を最小限にするために）、ホスト・コンピュータ１３においてクライアント１６のリストを開始し（例えば、プロパティおよび帯域幅要件がホスト・コンピュータ１３に知られていない、未インストールのいずれかのクライアントからの接続要求をサーバ１２が拒否することができるように）、クライアントＩＤをクライアント１６間に配布し（例えば、サーバ１２からの予測されるデータ、およびそれぞれの送信スロットに関して、クライアント１６間での混乱を防ぐために）、各クライアント１６について推定される帯域幅要件のテーブルを形成する（例えば、接続がどの特定のクライアント１６に対しても許可される前に、サーバ１２が帯域幅要件をオンラインで事前に計算できるように）。
【０１１７】
任意の新しいクライアント１６をサブネット１０に導入する前に、ホスト・コンピュータ１３で認識されるクライアントのリストを更新しなければならない。これはホスト・コンピュータ１３でユーザにより直接行ってもよく、他の実施形態では、クライアントＩＤがサーバ１２および新しいクライアント１６の両方に提供される限り、遠隔から行ってもよい。
【０１１８】
通常の動作中に、クライアント１６が応答を中断することがありうる。不在になったクライアントの後のクライアント１６がチャネルを使用できないことがあるので、これは惨事につながりかねない。この問題を軽減するために２方向からの解決法が実施される。第１に、クライアント１６がラインにおいて先行するクライアントからパケットを受信しない場合、クライアント１６はタイマを呼び出し、チャネルを捕捉する前に所定の時間待機する。第２に、無線装置１４からの受信信号強度指示（ＲＳＳＩ）を使用して空いているチャネルをチェックし、関連する無線装置１４が真のパケットを認識できない（例えば深刻なチャネル状態が原因で）場合の、間違った捕捉を回避することもできる。
【０１１９】
１つ以上のクライアントが不在になるという問題を解決するために、空いているチャネル中の待機時間は事前定義される。すべてのクライアントは使用されていない時間を追跡し、適切な事前定義された複数の待機時間待機した後でチャネルを捕捉する。Ｋ個の連続するクライアント１６が不在である場合、（Ｋ＋１）番目のクライアント１６が、Ｋ個の事前定義された時間の後にそれを引き継ぐ。さらにサーバ１２は応答のないクライアント１６を追跡し、応答のあるクライアント１６を移動して（例えばそのＣｏｎｎｅｃｔｉｏｎ  Ａｇｒｅｅｍｅｎｔを修正することにより）適切にチャネル中のギャップを埋める。
【０１２０】
先に指摘したように、サーバ１２がすでに動作した後にクライアント１６がウェイクアップする場合、クライアント１６はチャネルをチェックし、それから静止（Ｑ）スロット中で応答する必要がある。この理由のために、サーバ１２は、クライアントがサーバ１２に適切な通信をせずにシャット・ダウンされる場合でも、オンライン・クライアントのリストから削除する前に、すべてのオンライン・クライアント１６を所定の時間記憶している。シャット・ダウン・コマンド・シーケンスまたはタイム・アウトにより、クライアントがオンライン・リストから消去される場合、出て行くクライアントが手放した帯域幅はそれを必要とするクライアントに再割り当てされる。
【０１２１】
クライアント１６が接続を切断したい場合、Ｄｉｓｃｏｎｎｅｃｔ  Ｒｅｑｕｅｓｔがサーバ１２に送信され、クライアント１６はＤｉｓｃｏｎｎｅｃｔ  Ａｃｋ．を受信した後にシャット・オフする。サーバ１２は、確認通知を送信した後にオンライン・クライアントのリストからそのクライアントを削除する。確認通知が損失する場合、クライアント１６は別のＤｉｓｃｏｎｎｅｃｔ  Ｒｅｑｕｅｓｔパケットを送信し、サーバ１２はクライアント１６はすでに削除されたことを記憶しているので、別のＤｉｓｃｏｎｎｅｃｔ  Ａｃｋ．パケットを送信してクライアント１６をシャット・ダウンさせることができる。
【０１２２】
クライアントのアプリケーションがシャット・ダウンされる際、クライアント１６は電源が入った状態のままであることがある。ただし、サーバ１２はそのアプリケーションをシャット・ダウンさせているので、所定の長さの時間待機し、Ｃｏｎｎｅｃｔｉｏｉｎ  Ｔｅｒｍｉｎａｔｅコマンドをクライアント１６に送信し、Ｄｉｓｃｏｎｎｅｃｔ  Ａｃｋ．パケットを待機する。Ｃｏｎｎｅｃｔｉｏｎ  Ｔｅｒｍｉｎａｔｅコマンドに応答して、クライアント１６は電源が切れ、サーバ１２はクライアント１６をオンライン・クライアントのリストから削除する。ただし、クライアントの以前の確認通知が失われた場合サーバ１２は別のＣｏｎｎｅｃｔｉｏｎ  Ｔｅｒｍｉｎａｔｅパケットを送信することがあるので、クライアント１６は実際に電源オフする前にしばらく待機する。
【０１２３】
上記で説明したプロトコルを実施するために、数個のネットワーク・ファクタを考慮しなければならない。例えば、何らかの形のエラー認識およびエラー訂正を採用して、サブネット１０をサポートする無線リンクが雑音が多く損失の多い性質であることによる障害に対して防御しなければならない。またネットワークが変化するチャネル状況（例えば雑音の増加など）に応答できるように、通信チャネルを監視しなければならない。これにより上記で述べたチャネル切り替え動作が可能になる。さらに、データの暗号化を使用して、盗聴に対して防御し、外部者によるデータの操作および／またはサブネットの設定を防ぐことができる。これらの事項または他の事項は下記で詳細に述べる。
【０１２４】
上記で述べたように、エラー認識および訂正を導入するために、エラー訂正コーディング（ＥＣＣ）を使用することができる。一実施形態では、ＥＣＣコード化は、リード−ソロモン・エンコーダを使用して実現される。各データ・パケット４２（ヘッダを含む）は、２３９バイトのブロックに分割され、ＥＣＣは２５５バイトのブロックを形成するように実行される。データ・パケット４２中のバイト数が２３９の整数の倍数でない場合、仮想ゼロ・コード化技術を使用して、最後のブロックが切り捨てられたＥＣＣとともに送信される。この技術では、ＥＣＣのバイトは、データはブロックを完成させるように埋め込まれたゼロであるものとして計算されるが、埋め込みバイトは送信されない。その代わりに、受信装置において埋め込みバイトが追加され、データはデコードされる。いくつかの実施形態については、すべてのパケットは等しく扱われるが、他の実施形態では、オーディオおよびコマンド・パケットは高程度のＥＣＣにより送信されるのに対し、パケットに含まれるビデオ・データの重要性に応じてビデオ・パケットはそれとは異なる等しさで保護されることがある。
【０１２５】
チャネル状態を継続して監視できるように、各クライアント１６はサーバ１２により送信される全てのパケットを追跡し、各パケットにタイム・スタンプを使用していずれかのパケット損失を検出することができる。パケット損失計算の数は、およそ１秒（あるいは他の期間）に１回、サーバ１２に自動的に中継され、サーバ１２はこの情報を使用してチャネル状態を判断することができる。このようなチャネル監視は、チャネル変更決定、および変化するエラー防御を提供するために有用である。チャネル変更は、現在のチャネル中の雑音／干渉が容認不能になった時はいつでも実行することができる。増大された（または低減された）エラー防御は、チャネル状態に応じて、より好適な帯域幅利用および頑強性を提供するために使用される。
【０１２６】
本技術は著しいオーバヘッド（すなわち真のデータ以外の情報を転送するためにかかる時間）の使用を回避する。例示的サブネット１０では、オーバヘッドはさまざまな形態で存在し、無線ターン・アラウンド時間（たとえば４Ｍｂｐｓまたは５バイトで、１０μｓｅｃまた４０ビット）、無線データ・フレーム・プリアンブル４４（例えばダイバーシチのない８０ビット、またはダイバーシチのある１２８ビット）、無線データ・フレーム・ヘッダ（例えば１６ビットのＬｉｎｋ−ＩＤ、１６ビットの長さ情報、１６ビットのＣＲＣの４８ビット）、パケット・ヘッダ１４０（例えば８ビットのＣｌｉｅｎｔＩＤ、８ビットのＴｉｍｅ  Ｓｔａｍｐ、８ビットのＳＴＰ、８ビットの長さフィールドの３２ビット）、および各ビデオフレーム時間（例えば１６バイト）ごとに１つの接続要求パケットを伝播するために、新しいクライアントについて提供され、また必要な場合には提供されなければならないスロットＱを含む。オーバヘッドを最小限に保つために、サーバ１２はチャネル使用統計を継続的に監視し、それに応じてクライアント１６間の帯域幅割り当てを変更する。したがってチャネルは延長した時間、不使用の状態でいることは許されない。
【０１２７】
所定のチャネルについてのオーバヘッドは、一実施形態については下記のように推定される。各無線データ・フレーム４０が単一のパケット４２を伝搬するように制限される場合、各データ・フレーム４０のオーバヘッドは１２８＋４８＋３２＝２０８ビット＝２６バイトになる。Ｎ個のオンライン・クライアント１６があるサブネット１０については、任意のビデオ・フィールド継続期間内に２Ｎのコマンド・パケットがある。これらのパケットの最大ペイロードは、１００バイトに制限される。この制限は、マウス、キーボード、アナログ・ジョイスティック・インタフェースで予測される典型的なトラフィックを満たし、また他のコマンドを提供するように選択される。例えば、キーボード・インタフェースは１分につき最大で１００ワード、すなわち１秒につきおよそ１０キーストロークを要すると予想される。この結果０．３２バイト／フィールドとなる。しかし各キーストロークは１６ビットのワードであり、２バイトのペイロードになる。オーディオ（４４．１Ｋサンプル／秒、ステレオ、２：１圧縮）は、ビデオ・フィールド４４につきおよそ８００バイトを割り当てられる。これは１つのデータ・フレーム４０に適合することを意味する。言うまでもなく上記のパラメータについては、特定のチャネル／サブネットに応じて適切な他の値を使用することもできる。
【０１２８】
上記の値を使用すると、ビデオ・フィールド４４で使用可能な総帯域幅は、４＊１０6＊１６．６８３３５＊１０-3＝６６７３３．４＝８３４１バイトとなる。オーディオ情報には、（８００＋２６）＝各フィールド４４の８２６バイト：コマンド情報は（１００＋２６）＊２Ｎバイト（２つのクライアント１６では、これは６１６バイト）；無線ターン・アラウンド時間は（Ｎ＋１）＊５バイト（２つのクライアントに関してはこれは１５バイト）でセットされ；そして静止（Ｑ）スロットは１６バイトにセットされる。ビデオ情報には残っているいずれかの帯域幅が割り当てられ、すなわち上記の実施形態については、ビデオ情報にはおよそ８３４１−（８２６＋６１６＋１５＋１６）＝６８８０バイト（オーバヘッドを含む）が割り当てられる。したがってビデオ情報を伝搬する各無線データ・フレームは、（１０２４＋２６）＝１０５０バイトを必要とする。したがってビデオ情報は合計７つのパケットを占め、その７つのパケットのうち６つは満たされ１つのパケットは部分的に満たされる。したがってビデオ・フィールド４４内のそのようなフレームの総数は、２Ｎのコマンド、１つのオーディオ、７つのビデオになる。２つのクライアントについては、これは１２のデータ・フレームになる。したがってオーバヘッドは１５＋１２＊２６＝３２７バイトのオーバヘッドになる。
【０１２９】
これは１つのビデオ・フィールド継続期間で使用可能な総帯域幅（８３４１バイト）の３．９２％のオーバヘッドに相当する。無線プログラミングなどに伴ういずれかの遅延が原因の余分のオーバヘッドの２５％を提供すると、これは４．９％のオーバヘッドになる。ＥＣＣについて別に６．２７５％のオーバヘッドを追加した後でも、本技術が含むのは総オーバヘッドの１２％未満である。
【０１３０】
上記の説明により、サーバ１２がすべての動的なネットワーク管理を実行し、それに対してホスト・コンピュータ１３が静的なネットワーク管理を行うことが明瞭になろう。動的ネットワーク管理は、帯域幅の割り当て、帯域幅の利用に関するネットワーク監視（ｐｏｌｉｃｉｎｇ）（ホスト・コンピュータ１３にも報告される）および再ネゴシエーション；オンライン・クライアントのリスト維持；チャネル選択／変更を含む。静的ネットワーク管理は、インストールに関する全ての詳細事項（例えばリンクＩＤ、ＰＮコードなどの決定）；クライアントＩＤの維持；チャネル・ステータスおよび変動の維持、およびＰＮコード変更の決定（例えば両方の方向の各クライアント１６について維持されるテーブルまたは他のリストが必要であり、それはチャネル・ステータスがサーバ１２により受信される際は必ず更新される必要があり、エントリは例えば１週間／１カ月など長期間にわたって累積され、チャネルの性質の累積統計に基づいて、各方向の各クライアント１６について決定が行われることが好ましい）；帯域幅利用統計テーブルの維持、特に新しいクライアントをインストールする間には、ユーザにそのむねを通告する。
【０１３１】
以上のように、リアル・タイム・マルチメディア無線ネットワーク・プロトコルについて説明した。図示された特定の実施形態を参照して説明をしたが、本発明はそれにより制限されるべきではない。その代わり、本発明は下記の請求項によってのみ評価されるべきである。
【図面の簡単な説明】
【図１】  本発明の一実施形態である無線プロトコルによりサポートされる、一般化したネットワーク・アーキテクチャを示す図である。
【図２】  環境内での重なり合わない複数のサブネットの好ましい配布を示す図（ａ）とサブネットが重なり合っている例示的環境を示す図（ｂ）である。
【図３】  本発明の一実施形態に従って構成されたネットワーク体系への、開放型システム間相互接続（ＯＳＩ）の適合を示す図である。
【図４】  本発明の一実施形態に従ったサブネット内での、データの送信についての階層的配列を示す図である。
【図５】  本発明の一実施形態によるサブネットに、クライアントを追加するプロセスを示す状態図である。
【図６】  本発明の一実施形態による、サーバから見たクライアントをサブネットに挿入するプロセスを示す状態図である。
【図７】  本発明の一実施形態による、サーバが新しいクライアントについてセッションを開始するプロセスを示す状態図である。
【図８】  本発明の一実施形態による、サーバから見たサブネット内でのチャネルの変更のプロセスを示す状態図である。
【図９】  本発明の一実施形態による、クライアントから見たサブネットについてのチャネル変更シーケンスのプロセスを示す状態図である。
【図１０】  本発明の一実施形態によるクライアント／サーバのデータ・パケットについてのフォーマットを示す図である。
【図１１】  本発明の一実施形態によるクライアント／サーバのデータ・パケットについてのフォーマットをより詳細に示す図である。
【図１２】  本発明の一実施形態によるデータ・パケットについてのペイロード構造を示す図である。
【図１３】  本発明の一実施形態によるコマンド・パケットについてのペイロード構造を示す図である。
【図１４】  本発明の一実施形態によるコマンド・パケットについてのＣｏｎｎｅｃｔｉｏｎ  Ａｇｒｅｅｍｅｎｔの例示的ペイロード構造を示す図である。
【図１５】  本発明の一実施形態によるコマンド・パケットについてのＡｄｄ  Ｓｕｂｃｌｉｅｎｔの例示的構造を示す図である。
【図１６】  本発明の一実施形態によるデータ送信パケットのフォーマットを示す図である。
【図１７】  本発明の一実施形態によるＣｏｎｎｅｃｔｉｏｎ  Ｒｅｑｕｅｓｔコマンド・パケットの例示的構造を示す図である。
【図１８】  本発明の一実施形態による、サブクライアントをオンラインでサブネットに挿入するプロセスを示す状態図である。
【図１】
0003821424.tif 000005
【図２】
0003821424.tif 000006
【図３】
0003821424.tif 000007
【図４】
0003821424.tif 000008
【図５】
0003821424.tif 000009
【図６】
0003821424.tif 000010
【図７】
0003821424.tif 000011
【図８】
0003821424.tif 000012
【図９】
0003821424.tif 000013
【図１０】
0003821424.tif 000014
【図１１】
0003821424.tif 000015
【図１２】
0003821424.tif 000016
【図１３】
0003821424.tif 000017
【図１４】
0003821424.tif 000018
【図１５】
0003821424.tif 000019
【図１６】
0003821424.tif 000020
【図１７】
0003821424.tif 000021
【図１８】
0003821424.tif 000022