JP2002540643A - コンピュータ・ネットワークのための動的通信チャネル切替え - Google Patents

Abstract

(57)【要約】 コンピュータ・ネットワーク内の通信は、コンピュータ・ネットワークの構成要素を通信可能に結合する第１通信チャネル内の状態が、その通信チャネルの継続利用にとって容認できなくなりつつあることを判定し、次いで、そのコンピュータ・ネットワーク内の通信を第２通信チャネルに切り替えることによって制御される。ここでの干渉状態は、第１の通信チャネル内の干渉状態よりも厳しくないことが好ましい。切替えは、ネットワーク構成要素の１つによって開始されることができ、一般に、使用可能な通信チャネルの探索中に、第１通信チャネル内の通信を待機状態に置くことを含む。これは、構成要素の１つが、例えば、第２通信チャネルについてリスンするように、関連付けられた無線機の同調をとることによって、使用可能な通信チャネルを探索している間、コンピュータ・ネットワークの構成要素に静穏なままであるようにと指示することによって、達成することができる。最終的に、第２通信チャネルにおいて、ネットワーク通信を確立することができる。これは、コンピュータ・ネットワークの各構成要素との帯域幅接続同意をセットアップすること、および／または第２通信チャネルのコンピュータ・ネットワークの各構成要素のポーリングを含むことができる。

Description

【発明の詳細な説明】

【０００１】 （発明の分野） 本発明は一般に、コンピュータ・ネットワーク内の通信のための方式、詳細に
は無線リンクを介して中央サーバと複数のクライアント・ユニットとの間で行わ
れる通信に関する。

【０００２】 （背景） 現代のコンピュータ・ネットワークは、パーソナル・コンピュータ、ワークス
テーション、周辺機器など複数のノード間の相互通信を可能にする。ネットワー
ク・リンクはこれらノード間に情報を伝搬するが、このようなノードは時に互い
に遠く離れていることがある。だが現在のところ、大半のコンピュータ・ネット
ワークは、有線リンクに依存してこの情報を伝搬してきた。無線リンクが使用さ
れる場合、通常それらは広域ネットワークなど非常に大規模なネットワークの構
成要素であり、非常に距離が離れているネットワーク・ノードを相互接続するた
めに衛星通信リンクを使用することもある。このような場合、無線リンク間で使
用される送信プロトコルは一般に、例えば電話会社および他のサービス提供者な
ど、送信されているデータを伝搬するサービス・エンティティにより確立されて
いる。

【０００３】 家庭環境においては、コンピュータは従来スタンドアロン装置として使用され
てきた。だが近年になって、ホーム・コンピュータを他の電気器具と統合するた
めの手段がいくつか講じられている。例えばいわゆる「スマート・ホーム」では
、コンピュータを使用してさまざまな電気器具のスイッチを入れたり切ったり、
およびその操作設定を制御することができる。このようなシステムでは、有線通
信リンクを使用して、コンピュータとそれが制御する器具とを相互接続している
。こうした有線リンクは、特に最初に家屋を建造した後に追加する場合には設置
に高費用がかかる。

【０００４】 有線通信リンクに関連する問題および費用を低減する目的で、電気器具とコン
ピュータを相互接続するためのシステムには、アナログ無線リンクを利用してこ
れらのユニット間に情報を伝送しているものもある。こうしたアナログ無線リン
クは、普通無線電話が利用している周波数で動作する。従来の有線通信リンクに
比べて設置は容易だが、アナログ無線通信リンクには複数の欠点がある。例えば
そのようなリンクにおいては、複数経路混信のために信号が劣化することが予測
される。さらにテレビ、携帯電話、無線電話など現存の電気器具からの混信が起
こるかもしれない。したがってアナログ無線通信リンクは、家庭環境に関して最
適な機能を提供するとは言えず、そのような地域内の無線ネットワーク通信のた
めに改良された方式を有することが望まれる。

【０００５】 無線電話のような装置は、基礎的な周波数ホッピング技術を使用することによ
って、いくつかの通信の問題の回避を試みてきた。例えば、アナログ無線電話に
よっては、現行伝送チャネルに過度のノイズがある場合、ユーザが、基地局とハ
ンドセットとの間で使用するための新しい送信周波数に切り替えることができる
ものがある。しかし、ユーザは、その無線電話ユニットが切り替わる可能性のあ
る次のチャネルに対する制御権をほとんど、あるいはまったく有することがなく
、新しい送信周波数がさらに悪い通信特性を有し、したがってハンドセットと基
地局との間の最後の通信が失われる可能性がある。さらに、基地局とハンドセッ
トとの間に通信の低下が生じた場合に、明瞭な伝送チャネルを自動的に探索する
無線電話ユニットはなさそうである。

【０００６】 無線電話とは別に、周波数ホッピング無線機も通信目的で使用されてきた。こ
のような無線機は、絶えずその送信周波数を変更し、したがって、無線機は、短
いタイム・ユニット中に、ある周波数帯域で情報を伝送し、次いで次のタイム・
ユニットの伝送用に別の周波数帯域に切り替え、以下同断に行う。一般に、多く
のそのような周波数が使用可能であり、その後、無線機は既に使用した第１周波
数帯域に戻ってくる。また、多くの無線機が同じ周波数帯域を使用することがで
きるが、干渉を回避するために様々なパターンでこれを行う。しかし、重要なの
は、そのような方式におけるチャネル切替えが、チャネルの挙動と独立に行われ
ることである。チャネル・ノイズや他の干渉によるデータ損失は、ネットワーク
上層でデータ・インタリービングとエラー訂正技術を使用して、補正されなけれ
ばならない。したがって、旧来のアナログ無線通信リンクと周波数ホッピング方
式は、住宅環境に対して決して最適なパフォーマンスを提供しておらず、そのよ
うな区域では、無線ネットワーク通信に対する改善型の方式を有することが望ま
しい。

【０００７】 （発明の概要） コンピュータ・ネットワークにおける通信は、コンピュータ・ネットワークの
構成要素を通信可能に結合する第１通信チャネル内の状態が、その通信チャネル
の継続利用にとって容認できなくなりつつあることを第１ネットワーク装置にお
いて判定し、次いで、コンピュータ・ネットワーク内の通信を第２通信チャネル
に切り替えることによって制御することができる。第２通信チャネル内の干渉状
態は、第１通信チャネル内の干渉状態よりも厳しくないことが好ましい。切り替
えは、第１ネットワーク装置または別のネットワーク構成要素によって開始する
ことができ、一般に、使用可能な通信チャネルの探索中に、第１通信チャネル内
の通信を待機状態に置くことを含む。これは、第１ネットワーク装置が、例えば
、第２通信チャネルについて受信待機（リスン）するように、関連付けられた無
線機の同調をとることによって、使用可能な通信チャネルを探索している間に、
コンピュータ・ネットワークの構成要素に静止のままであるよう命令することに
よって達成することができる。場合によっては、コンピュータ・ネットワークの
各構成要素が、静止しているようにとの命令の受信に肯定応答する。

【０００８】 したがって、無線電話によって使用される周波数ホッピング方式と異なり、本
発明による方法は、低下した通信チャネルの自動検出を可能にし、さらに古いチ
ャネルよりも優れた通信特性を示す新しい通信チャネルへのチャネル切替えを提
供する。さらに、一実施態様では、このチャネル・ホップは、第１ネットワーク
装置がネットワーク通信を新しいチャネルに変更するよう決定する前に、いくつ
かの通信チャネルを自由に探索できるということに関しては、事前定義されてい
ない。このようなチャネル変更の動作は、ユーザによる介入が必要になる前に、
自動的に実行されることが好ましい。

【０００９】 切替えの前に、第１ネットワーク装置は、第２通信チャネルを確認するチャネ
ル変更メッセージをコンピュータ・ネットワークの構成要素にブロードキャスト
することができ、またコンピュータ・ネットワークの各構成要素はチャネル変更
メッセージに応答して、第１ネットワーク装置に肯定応答を送信することができ
る。場合によっては、第１ネットワーク装置は、コンピュータ・ネットワークの
各構成要素からの肯定応答メッセージがない場合でも、第２通信チャネルに切り
替わる。最終的に、ネットワーク通信を、第２通信チャネルに確立することがで
きる。これは、第２通信チャネルについてコンピュータ・ネットワークの各構成
要素との帯域幅接続同意をセットアップすること、および／または第２通信チャ
ネルにおいてコンピュータ・ネットワークの各構成要素をポーリングすることを
含む。

【００１０】 別の実施態様では、第１通信チャネルから第２通信チャネルへのコンピュータ
・ネットワークにおける通信の切替えは、第１通信チャネル内のチャネル干渉状
態が容認できないとの指示に応答して実行される。少なくとも第１通信チャネル
または第２通信チャネルの一方が無線通信チャネルであり、場合によっては、第
１通信チャネルと第２通信チャネルの両方がスペクトラム拡散無線通信チャネル
であることが好ましい。一般に、切替えは、静止しているようにとの指示に応答
して、第１通信チャネル内の通信を接続解除することを含む。この指示は、肯定
応答が返される場合と返されない場合とがある。返されない場合、切替えは、切
り替えるようにとの要求がない場合でも、任意で第２通信チャネルに切替わるこ
とを含むことができる。第２通信チャネルに切り替わった後、通信は、チャネル
切替え肯定応答への要求に応答して、第２通信チャネルにおいて再開することが
できる。通信を再開することは、第２通信チャネルにおける帯域幅についてネゴ
シエートすることを含み、および／または第２通信チャネルへのアクセス要求を
それの静止時間スロットにおいて送信することによって達成することができる。

【００１１】 本発明のこれらまたは他の特徴および利点は、詳細な説明とその添付図面を参
照することによって明らかになろう。

【００１２】 本発明は添付の図面の形で、制限としてではなく例として図示される。

【００１３】 （詳細な説明） ここで説明するのは、（ａ）サーバと関連するネットワーク・クライアント、
および（ｂ）サーバとそれに関連するホスト・コンピュータの間で使用される、
ネットワーク・アーキテクチャおよび関連するプロトコルである。本技術は一般
に、さまざまな無線ネットワーク環境に応用することができるが、特に家庭環境
内に置かれるコンピュータ・ネットワーク内で使用すると有用である。したがっ
て本技術は、家庭環境の特定の状況を参照しながら説明される。ただしこの説明
は決して本発明を他のネットワーク環境に応用することを制限するものではなく
、本発明のより広い精神および範囲はこの説明に続く請求項で列挙される。

【００１４】 ここで使用される「サブネット」とは、サーバおよびそれに関連づけられたい
くつかのクライアント（例えば無線通信リンクで結合された）を含むネットワー
ク構成要素のクラスタを表す。説明の文脈によっては、サブネットは、クライア
ントおよびそれに関連づけられた１つまたはそれ以上のサブクライアントを含む
ネットワークを指すこともある。場合によっては、「サブネット」という用語は
「セル」と置き換え可能な意味で使用される。本技術では、「クライアント」は
無線リンクを通じてサーバにリンクされたネットワーク・ノードである。クライ
アントの例は、テレビ、ステレオ・コンポーネント、衛星テレビ受信機、ケーブ
ルテレビ配布ノード、他の家庭用電気器具などのオーディオ／ビデオ機器を含む
。サーバは通信リンクを制御する別のコンピュータでよいが、他の場合にはサー
バはアドオン・カードまたはホスト・コンピュータに接続された構成要素（例え
ばパーソナル・コンピュータ）でもよい。サブクライアントは、キーボード、ジ
ョイスティック、遠隔制御装置、多次元入力装置、カーソル制御装置、表示装置
および／または特定のクライアントに関連付けられた他の入力および／または出
力装置を含む。

【００１５】 以下の説明を通じて使用されるもう１つの用語は「チャネル」である。チャネ
ルは、スペクトラム拡散通信方式で使用される送信周波数（より適切には、送信
周波数帯域）と擬似ランダム（ＰＮ）コードとの組み合わせとして定義される。
一般に複数の使用可能な周波数およびＰＮコードは、サブネット内で使用可能な
複数のチャネルを提供する。下記でより詳細に説明するように、サーバおよびク
ライアントは使用可能なチャネル内を検索して、相互に通信するための望ましい
チャネルを見つけることができる。下の表１は、この方式による例示的チャネル
計画を示す。

【００１６】

【表１】 一実施形態では、２つの周波数帯域を使用したチャネル計画を採用し、そのよう
な技法におけるチャネル選択の詳細は下記でより詳細に説明する。

【００１７】 以上の用語を念頭に置き、第１に無線通信リンクおよび関連する通信プロトコ
ルを使用する例示的ネットワーク・トポロジを参照して、本技術を論じる。第２
に、無線リンク上でサポートされる通信チャネル内で送信されるデータについて
の階層構造を使用するネットワーク動作を説明する。第３に、無線通信リンク・
プロトコルに従って使用される例示的パケット構造について論じる。第４に、オ
ーバヘッド、エラーの符号化および訂正、データの暗号化、ネットワークの初期
化および管理などのネットワークに関するさまざまな事項について説明する。

【００１８】 Ａ．ネットワーク・トポロジ 本技術がサポートするネットワーク・アーキテクチャの概括を図１に示す。サ
ブネット１０はサーバ１２を含む。先に指摘したように、サーバ１２はスタンド
アロン・ユニット、またはより高い可能性としては、サーバに対しホスト１３と
して機能するパーソナル・コンピュータ用のアタッチメント・カードである。サ
ーバ１２は関連づけられた無線装置１４を有し、それはサーバ１２をサブネット
１０の他のノードに無線的に結合するために使用される。無線リンクは一般に、
高帯域および低帯域両方のデータ・チャネルとコマンド・チャネルをサポートす
る。

【００１９】 サブネット１０には複数のクライアント１６も含まれ、そのうちのいくつかは
それと関連付けられたシャドー・クライアント１８を有する。シャドー・クライ
アント１８は、関連付けられたクライアント１６と同一のデータ入力を受信する
（サーバ１２または別のクライアント１６から）が、それと関連するクライアン
ト１６とは無関係にサーバ１２とコマンドを交換するクライアントとして定義さ
れる。各クライアント１６は、サーバ１２と通信するために使用される関連付け
られた無線装置１４を有し、いくつかのクライアント１６は関連するサブクライ
アント２０を有することもある。クライアント１６とそれに関連付けられたサブ
クライアント２０は、通信リンク２２を介して互いに通信するが、そのリンクは
無線（例えば赤外線、超音波、拡散スペクトラムなど）通信リンクでよい。

【００２０】 各サブネット１０は、ネットワーク内の構成要素の通信が生じるレベルに応じ
た階層のさまざななレベルにより、階層的に配置されたネットワークと見ること
ができる。階層の最上レベルにあるのは、無線通信チャネルを介してさまざまな
クライアント１６と通信するサーバ１２（および／またはそれに関連するホスト
１３）である。階層の一方の低レベルでは、クライアント１６が、例えば有線通
信リンクまたは赤外線リンクなどの無線通信リンクを使用して、さまざまなサブ
クライアント２０と通信する。この階層は、下の表２に示すような３層構造で説
明することもできる。指摘したように、装置はネットワーク・オンラインの任意
のレベルに追加することができる（例えば他のネットワーク動作中のホット・イ
ンサーションなど）。

【００２１】

【表２】

【００２２】 一般に、サブネット１０は単一のサーバ１２および事実上任意の数のクライア
ント１６を含むことができる。ただし同時にサポートされるクライアント１６の
数は、フォワードおよびバックワードの帯域要件による。一実施形態では、サー
バ１２とクライアント１６を結合する（例えば無線装置１４を介して）無線リン
クは、全二重の１０Ｍｂｐｓのリンクである。他の実施形態では、無線リンクは
半二重で４Ｍｂｐｓのリンクである。さらに他の実施形態では、異なる帯域での
半二重または全二重のリンクを可能にする。

【００２３】 無線装置１４は、典型的な家庭環境内でのサブネット内通信を可能にするよう
に構成されることが好ましい。一実施形態では、これは無線装置１４が特定のセ
ル・エリア内で通信を確立および管理することができることを意味する。一実施
形態では、典型的セル・エリアはおよそ１００’×８０’×３０’であり、典型
的家庭環境中での通信を可能にしている。無線装置１４によりサポートされる無
線リンクは、少なくとも２つの別々の周波数空間を提供し、重なり合っている２
つのセル２２をサポートすることが好ましい。すなわち無線装置１４は、使用可
能な周波数帯域のうち１つで作動することができる。同一の周波数帯域内では、
個々のサブネット（サーバ１２、複数のクライアント１６、および任意選択でシ
ャドー・クライアント１８、サブクライアント２０からなる）は、コード分割多
重アクセス（ＣＤＭＡ）通信技術を利用してサブネット内で情報を交換すること
が好ましい。半二重の動作については、同一の周波数帯域のフォワード通信路お
よびリバース通信路（同一のＣＤＭＡ擬似ランダム（ＰＮ）コードを使用する）
は、動的に調整可能な時間分割多重アクセス（ＴＤＭＡ）を利用して、サーバ１
２からの送信とクライアント１６からの送信を区別することができる。エラー訂
正（例えばリード−ソロモン（Ｒｅｅｄ−Ｓｏｌｏｍｏｎ）エンコーダ／デコー
ダを使用する）およびデータ暗号化技術を使用して、盗聴に対する頑強性および
安全性を増してもよい。

【００２４】 個々のサブネット間で高干渉を生じさせないために、複数のサブネット２２ａ
、２２ｂ、２２ｃ、２２ｄの環境内での配置は、図２ａに示すように互いに重な
り合わないことが好ましい。ただしこのような理想的なモデルを保証するのは難
しいことが認識される。例えば重なり合っているサブネットは、２つの近接する
家／アパート内に２つの異なるサブネットがある場合に生じる（実際には予測さ
れる）ことがある。図２ｂに図示するような、重なり合うサブネット範囲エリア
２４ａおよび２４ｂ（それぞれ異なる送信ユニットＴ₁およびＴ₂を有する）は、
盗聴、サブネット内の干渉の増大、頻繁なチャネル変更などを招きうる。生じる
可能性のあるこうした問題に対する防御については下記で述べる。

【００２５】 当プロトコル方式は、図３に示すように、よく知られている開放型システム間
相互接続（ＯＳＩ）モデル上にオーバーレイしてもよい。ＯＳＩモデルの最上層
からの３つのレイヤ、すなわちアプリケーション・レイヤ３０、プレゼンテーシ
ョン・レイヤ３１、セッション・レイヤ３２は、ホスト・コンピュータ１３（す
なわちサーバ１２をサポートしているコンピュータ、またはサーバがスタンド・
アロン・ユニットである場合はサーバ１２自体）で実施されることが好ましい。
低層のレイヤ、すなわち伝送レイヤ３３、ネットワーク・レイヤ３４、データ・
リンク・レイヤ３５、物理レイヤ３６は、サーバ１２およびクライアント１６（
ホスト１３の動作と重複があるかもしれないが）で実施されることが好ましい。

【００２６】 上記で述べたように、物理レイヤ３６は無線装置１４を使用する無線リンクと
して実施されることが好ましい。したがって、サーバ１２またはクライアント１
６（適切に応じて）は、データ・フレーム・パラメータの初期化、無線パラメー
タ、およびデータ・フレーム送信の開始を処理することができるが、データ・フ
レームの構成、送信、受信などの他のサービスおよび拡散動作は、無線装置１４
により直接処理される。

【００２７】 一実施形態について、例えば半二重の無線通信が使用される場合、データ・リ
ンク・レイヤ３５は、動的なスロット割り当てとともに、スロット化されたリン
ク構造（下記でより詳細に説明する）を使用することがある。そのような構造は
サブネット１０内での二地点間接続をサポートし、スロット・サイズはセッショ
ン中に再ネゴシエーション可能でありうる。したがってデータ・リンク・レイヤ
３５はデータ・パケットの処理、パケット送信についての時間管理、スロット同
期化、エラー修正コーディング（ＥＣＣ）、チャネル・パラメータの測定、チャ
ネル切り替えを受け入れることができる。伝送レイヤ３３は、サービスに関連す
るすべての必要な接続、帯域幅利用の監視、低帯域幅データの処理、データのブ
ロードキャスト、および任意選択でデータの暗号化を提供する。伝送レイヤ３３
は帯域幅を各クライアント１６に割り当て、常にその帯域幅を下回るまたは上回
る利用を監視する。伝送レイヤ３３は、新しいクライアント１６がオンラインに
入ってくるか、またはクライアント１６の１つ（または関連するサブクライアン
ト２０）がより大きな帯域幅を要求する時には必ず必要となる、いずれの帯域幅
の再ネゴシエーションも受け入れる。プレゼンテーション・レイヤ３１は、ビデ
オ／ボイス・データの圧縮／解凍をサーバ１６（および／またはそのホスト・コ
ンピュータ１３）およびクライアント１６で提供する。さらに表示サービスがク
ライアント１６で提供される。

【００２８】 下記でより詳細に説明するように、このネットワーク・アーキテクチャは、複
数のネットワーク構成要素（例えばサーバ１２、クライアント１６、シャドー・
クライアント１８、サブクライアント２０）を階層的に配置することができる。
階層の１つのレベルにおいて、サーバ１２およびクライアント１６は、マルチメ
ディア・データなどの情報を交換するために動作する。階層の別のレベルでは、
クライアント１６はその個々のサブクライアント２０と通信して、サーバ１２で
発する／終端するコマンドなどの情報を交換することができる。このネットワー
ク階層の各レベルにおいて、個々のネットワーク構成要素は、階層のそのレベル
で動作する通信リンクを通じて互いに通信上結合される。例えば次項で述べるの
は、階層の最上レベル（すなわちサーバ１２とクライアント１６との間）で動作
するプロトコルであり、それは階層の最上レベルで使用される通信チャネルに関
するその帯域幅要件に従って、新しいネットワーク構成要素の動的な追加を階層
のどのレベルにおいてもサポートする。階層の低レベル（例えばクライアント１
６とそれに関連するサブクライアント２０の間）における通信は、クライアント
およびそのサブクライアントにより実行される操作に従って、同様のプロトコル
または他の任意の適切な通信プロトコルを使用することができる。例えば、サブ
クライアントとその関連するクライアントとの間の無線（例えば赤外線）または
有線通信リンク内で情報を交換するための現存の通信プロトコルをサポートして
、その情報がクライアント１６とサーバ１２の間で送信されようとする時に、下
記で述べるプロトコルに従って交換されるべきデータ・パケット内で、任意のそ
のようなデータが続いてカプセル化される（および／または必要であれば再フォ
ーマットされる）。

【００２９】 Ｂ．ネットワーク動作 以上のように本技術をサポートするネットワークの基本的トポロジを説明した
ので、次いでネットワークについての例示的動作（例えば半二重動作）を説明す
る。図４に示すように、こうした動作は、サブネット１０内でリアル・タイムの
マルチメディア・データ（例えばフレームとして）を送信するために、階層的配
置を利用する。チャネル内の最上レベルで、固定の（だが交渉可能な）継続時間
のフォワード（Ｆ）およびバックワードまたはリバース（Ｂ）スロットが、各フ
レーム送信期間中に設けられる。フォワード時間スロットＦ中に、サーバ１２は
ビデオおよび／または音声データおよび／またはコマンドをクライアント１６に
送信し、クライアント１６は聴取モードに置かれる。リバース時間スロットＢ中
に、サーバ１２はクライアント１６からの送信を受信待機する。こうした送信は
、クライアント１６または関連付けられたサブクライアント２０からの音声、ビ
デオ、または他のデータおよび／またはコマンドを含むことができる。階層の２
番目のレベルでは、各送信スロット（フォワードまたはリバース）は、可変長の
１つまたは複数の無線データ・フレーム４０から構成される。最後に階層の最低
レベルでは、各無線データ・フレーム４０は、可変長のサーバ／クライアント・
データ・パケット４２を含む。

【００３０】 各無線データ・フレーム４０は、１つのサーバ／クライアント・データ・パケ
ット４２およびそれに関連するＥＣＣビットから構成される。ＥＣＣビットは、
受信側でデータ・パケットの開始および終了を検出するのを単純化するために使
用することができる。深刻なチャネル状況中により小さなフレーム長を容認する
目的で、一定の長さのフレーミングより可変長のフレーミングが好ましく、また
その逆でもよい。これにより、チャネルの頑強性および帯域幅節約が増加される
。ただし、可変長のフレームが使用されるものの、ＥＣＣのブロック長は固定で
あることが好ましい。したがって、データ・パケット長がＥＣＣのブロック長よ
りも小さい場合はいつでも、ＥＣＣブロックは切捨てられる（例えば従来の仮想
ゼロ技術を使用して）。データ・パケットがより大きい時は、同様の手順をＥＣ
Ｃビットの最後のブロックについて採用することができる。

【００３１】 図に示すように、各無線データ・フレーム４０はプリアンブル４４を含み、そ
れは送信機および受信機のＰＮ生成装置を同期するために使用される。リンクＩ
Ｄ４６は固定長のフィールドであり（例えば一実施形態では長さ１６ビット）、
リンクに固有であり、したがって特定のサブネット１０を識別する。サーバ１２
／クライアント１６からのデータは、長さフィールド４８により指定される可変
長である。周期冗長検査（ＣＲＣ）ビット５０は、従来の方式でエラーを検出／
訂正するために使用される。

【００３２】 次に図示された実施形態について、各フレーム４４（例えば一実施形態では３
３．３３ｍｓｅｃの継続時間）は、フォワード・スロットＦ、バックワード・ス
ロットＢ、静止スロットＱ、複数の無線ターン・アラウンド・スロットＴに分割
される。スロットＦは、サーバ１２からクライアント１６への通信用である。ス
ロットＢは、複数のミニスロットＢ₁、Ｂ₂などの間で共有される時間であり、ミ
ニスロットはそれぞれのサーバ１２への送信のために、サーバ１２によって個々
のクライアント１６に割り振られる。各ミニスロットＢ₁、Ｂ₂などは、音声、ビ
デオ、ボイス、損失のあるデータ（すなわち損失のある技術を使用してコード化
／コード解除されたデータ、または送信／受信中のいくらかのパケットの損失を
容認できるデータ）、損失のないデータ（すなわち損失のない技術を使用してコ
ード化／コード解除されるデータ、または送信／受信中のいかなるパケットの損
失をも容認できないデータ）、低帯域幅データおよび／またはコマンド（Ｃｍｄ
．）パケットを送信するための時間を含む。新しいクライアントがサブネット１
０にログインしようとする際に新しいクライアントが要求パケットを挿入できる
ように、スロットＱは静止の状態に置かれる。スロットＴは、送信から受信への
変更、またはその逆の場合の変更の間に現れ、個々の無線のターン・アラウンド
時間（すなわち半二重無線装置１４が送信から受信動作へ、またはその逆に切り
替わる時間）を受け入れるものである。これらの各スロットおよびミニスロット
の継続時間は、チャネルにとって最上の可能性のある帯域幅の使用を実現するた
めに、サーバ１２とクライアント１６間の再ネゴシエーションを通じて動的に変
えられる。全二重無線が使用される場合、各方向スロット（すなわちＦおよびＢ
）は１つの方向においてフルタイムであり、無線ターン・アラウンド・スロット
は必要とされない。したがって通信プロトコルは、コンピュータ・ネットワーク
の２つまたはそれ以上のユニット（例えばサーバおよび複数のクライアント、サ
ブクライアントおよび／またはシャドー・クライアント）を、ＴＤＭＡ直接拡散
スペクトラム方式（ＤＳ−ＳＳ）通信リンクと通信上結合することができる。示
すように、ＴＤＭＡ ＤＳ−ＳＳ通信リンクは、コンピュータ・ネットワークの
ユニットに対して動的に配分できる通信時間スロットを含む。

【００３３】 フォワード帯域幅およびバックワード帯域幅の配分は、クライアント１６によ
って扱われるデータによって決まる。クライアント１６が例えばテレビのような
ビデオ消費者である場合、そのクライアントに対しては大きなフォワード帯域幅
が割り当てられる。同様にクライアント１６が例えばビデオカムコーダのような
ビデオ生成装置である場合は、大きな逆方向の帯域幅がその特定のクライアント
に割り当てられる。サーバ１２は動的テーブル（例えばサーバ１２またはホスト
１３のメモリ内の）を保持し、それにはすべてのオンライン・クライアント１６
のフォワードおよびバックワードの帯域幅要件が含まれている。この情報は、新
しい接続が新しいクライアントに対して許可されるかどうかを決定する時に使用
することができる。例えば新しいクライアント１６がいずれかの方向で使用可能
な帯域幅以上を要求する場合、サーバ１２は接続要求を拒否することができる。
帯域幅要件（または割り当て）情報は、特定のクライアント１６がそのパケット
をサーバ１２に送信するのを開始する前に、いくつの無線パケットを待つ必要が
あるのかを決定する際にも使用することができる。さらにチャネル状態が変化し
た場合はいつでも、エラー訂正コーディング（ＥＣＣ）を増加／減少して新しい
チャネル状態に対処することが可能である。したがってソースにおける情報速度
が変更されたかどうかによって、それはフォワードおよびバックワードの帯域幅
割り当てに対する動的な変更を必要とする。これはＣｏｎｎｅｃｔｉｏｎ Ａｇ
ｒｅｅｍｅｎｔ（接続同意）コマンド（下記でさらに説明する）を通じて実現す
ることができる。

【００３４】 サーバ１２とクライアント１６の間の時間スロットの同期化は、４つのネット
ワーク動作状況について検討される。すなわち、クライアントがウェイク・アッ
プする時、新しいクライアントがオンラインに入る時、チャネルが変更される時
、クライアントが不在になるかまたはシャットダウンする時の動作状況である。
これらの状況は、クライアント１６およびサーバ１２についてのさまざまな有限
状態図を参照して説明する。図中、ネットワーク構成要素の動作状態は円内に書
かれる。状態遷移は、現在の状態および／または入ってくるメッセージの受信お
よび内容に関連する処理の出力によって行われる。受信または送信されたメッセ
ージ（すなわちコマンド）は、状態遷移の線の隣に示す。例えば状態遷移線上の
「Ａ／Ｂ」は、メッセージ「Ａ」が受信され、それに対し次の状態に遷移しなが
らメッセージ「Ｂ」が応答として送信されたことを意味する。他の場合では、「
Ａ」は進行中の処理の出力であり、「Ｂ」は有限状態マシンによりとられるアク
ションであることもある。「ＸＸ」は、入力または出力のドント・ケア・アクシ
ョンを表す。この図で参照するさまざまなコマンドの完全な説明は下記で行われ
る。

【００３５】 図５に示すように、クライアント１６がウェイク・アップする時、それは受信
モード（状態６０）で起動し、チャネルを受信する。クライアント１６がチャネ
ル上のアクティビティを検出する場合、クライアントは受信してサーバ１２がチ
ャネルを変更中である（状態６２）かどうかを判定する（下記でさらに説明する
）。チャネル変更プロセスが認識される場合、クライアント１６は残りのサブネ
ット１０とともにチャネルを変更する（状態６４）。言うまでもなく、チャネル
変更が進行中でなければ、クライアント１６は通常のチャネル通信だけを検出す
る。クライアント１６がチャネルを変更する必要がある場合もない場合も、クラ
イアント１６はスロットＱを待機し（状態６６）、そのスロット中にＣｏｎｎｅ
ｃｔｉｏｎ Ｒｅｑｕｅｓｔ（接続要求）（ＣＲＱ）パケットをサーバ１２に送
信する。それに応答してサーバ１２は、入ってくる要求の整合性をチェックする
（例えば送信元のクライアントを行先とする同一の要求を周期的に、おそらくビ
デオ・フレームごとに１回、応答が受信されるまで送信することにより）。

【００３６】 クライアントの要求が確認されると（例えば、確認パケットをクライアントか
ら受信することにより。その後クライアントは待機状態６８に入る）、サーバ１
２はＣｏｎｎｅｃｔｉｏｎ Ａｇｒｅｅｍｅｎｔ（接続同意）（ＣＡＧ）パッケ
ージをクライアント１６に送信する。このパッケージは特に、新しいクライアン
ト１６に与えられるフォワードおよびバックワードの帯域幅（例えばチャネルの
スロット）に関する情報を含む。さらに、新しいクライアント１６が各データ・
パケット内に送信／予期することができるバイトの最大数が、各タイプのパケッ
ト（例えば映像データ、音声データなど）について設定される。Ｃｏｎｎｅｃｔ
ｉｏｎ Ａｇｒｅｅｍｅｎｔパッケージは、新しいクライアント１６がサーバの
送信から、および先行するクライアント（すなわち先行するリバースの送信スロ
ットを持つクライアント）の識別の開始から待たなければならない、データ・フ
レームの総数に関する情報も含むことができる。全クライアントは、サーバの送
信の開始から受信するデータ・フレームの数を数えることにより、その個々の接
続同意を容認し、先行するクライアントから受信した最後のデータ・フレームの
終了後にそれぞれの送信を開始する。計算中にクライアントが先行するクライア
ントにより送信されたＴｏｋｅｎ Ｐａｓｓコマンドに遭遇した場合、そのクラ
イアントは計算を停止しそれ自体の送信を即時に開始する。

【００３７】 Ｃｏｎｎｅｃｔｉｏｎ Ａｇｒｅｅｍｅｎｔパケットを受信した後に、クライ
アント１６はそのデータをそれに割り当てられた時間スロット（例えばＢ１、Ｂ
２など）中に送信するようにそれ自体を構成し、スロットが回ってくるのを待機
する（状態７０）。指定された時間スロットに、クライアント１６はサーバ１２
と通常の通信を開始し（状態７２）、それが持っているであろう任意のデータま
たはコマンドを送信する。

【００３８】 上記の説明は、クライアント１６がアウェイクして使用中のチャネルを検出す
ることを想定している。だがクライアント１６がウェイク・アップした際にチャ
ネルがビジーでない可能性もある。そのような場合、クライアント１６はサーバ
１２が応答することを見込んでＣｏｎｎｅｃｔｉｏｎ Ｒｅｑｕｅｓｔパケット
を送信し、任意の期間待機する（状態７４）。応答が受信されない場合、クライ
アントはチャネルを変更する。新しいチャネル内で受信モードにある間に（状態
７６）、クライアント１６がアクティビティを検出した場合、それは続行して上
記で説明したように帯域幅の割り当てについてサーバ１２とネゴシエートする。
そうではなく、チャネル・アクティビティが検出されない場合、クライアント１
６は再びＣｏｎｎｅｃｔ Ｒｅｑｕｅｓｔパケットを送信し、応答を待機する（
状態７８）。このプロセスは、サーバ１２が見つかるまですべての使用可能なチ
ャネルについて繰り返される。応答が受信されない場合、クライアントは使用可
能なサーバがないことをユーザに通知し、パワー・ダウンする（状態８０）。た
だし、チャネルの１つでサーバ１２から応答が受信される場合は、クライアント
は接続についてネゴシエートし（状態８２）、それから上記で説明したように通
常の通信を開始する（状態８４）。

【００３９】 図６に示すように、サーバから見ると、クライアント１６はオンラインで挿入
してよい。例えばクライアント１６は、サーバ１２がすでに動作した後にウェイ
ク・アップするかもしれない。サーバ１２は接続を求めている新しいクライアン
トによって送信されたＣｏｎｎｅｃｔｉｏｎ Ｒｅｑｕｅｓｔパケットを求めて
、スロットＱを受信待機するように構成される。上記で説明したように、Ｃｏｎ
ｎｅｃｔｉｏｎ Ｒｅｑｕｅｓｔパケットをさらに交換することにより新しいク
ライアント１６と同期した後で、サーバ１２は、有効なクライアントＩＤを格納
するホスト・コンピュータ１３にそのような認証を要求して、クライアントの信
頼性を確かめる（状態９２）。認証テストがパスした場合、サーバ１２は新しい
セッション識別子（ＩＤ）をクライアントに割り当て（状態９３）、チャネルに
ついて帯域幅を再割り当てする（状態９４）。帯域幅の再割り当ては、新しいク
ライアントを受け入れるために必要とされる。その後サーバ１２はＣｏｎｎｅｃ
ｔｉｏｎ Ａｇｒｅｅｍｅｎｔパケットを新しいクライアント１６に送信し、そ
れにより通常の通信を開始する。図示するように、各状態９２、９３、９４は、
関連付けられたタイム−アウト・パラメータ（例えば搭載されたタイマーを使用
して維持される）を有することもある。いずれの時間にも、クライアント応答が
タイム・アウト期間内に受信されない場合、サーバ１２はクライアント１６がオ
フライン状態になったと想定し、Ｑスロット内で受信待機に戻る（状態９０）。

【００４０】 図７に示すように、オンラインのクライアント１６がない場合、サーバ１２は
空いたチャネル内で待機し、クライアント・パケットが検出されるまで受信モー
ドの状態を保つ（状態９５）。チャネルが空いているかどうかを判定するために
、各チャネルについて受信した信号の強度（無線装置１４により提供される）を
チェックし、最低のエネルギーの信号を選択する。次いで有効なデータ・パケッ
トが存在するか、Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｑｕｅｓｔパケット以外の受信し
たいずれのデータを分析する。任意の他のパケット、特にサーバ生成であるとマ
ークされているパケットが受信される場合、チャネルはビジーであると宣言され
る。一方、チャネル上で受信されたパケットが、接続を待機しているクライアン
トにより生成されたＣｏｎｎｅｃｔｉｏｎ Ｒｅｑｕｅｓｔパケット以外に有効
なデータを何も含んでいない場合、チャネルは空いていると宣言される。データ
・パケットが全く受信されない場合、サーバ１２はそのチャネル内で受信モード
（状態９５）のままであり、クライアントのＣｏｎｎｅｃｔｉｏｎ Ｒｅｑｕｅ
ｓｔパケットを待つ。その間に、チャネルが現在のサーバの無線に近接する別の
サブネットにより占有される場合、そのサーバは別のチャネルに切り替わり、ク
ライアントの要求を待機する。すべてのチャネルが占有される場合、サーバ１２
は空いたチャネルが見つかるまでチャネルの周期的な変更を続ける。クライアン
ト１６が２つのサーバ１２からのパケットを一貫して検出する場合、クライアン
ト１６はチャネル上に干渉状態があることを認識し、無線リンク内で接続を確立
しない。同様に、サーバ１２が別のサーバからのパケットを一貫して検出する場
合、そのサーバはチャネル上でのいかなるクライアント接続の確立も試みない。
これら２つの対策は、１つのサブネットからのサーバが、近接のサブネットから
のクライアントを占有しないことを保証する。さらに、隣接するサブネットの別
のサーバが１つのサーバのクライアントを占有することを防ぐために、固有のリ
ンク識別子（ＩＤ）を各サブネット１０について使用してもよい。

【００４１】 クライアント１６は、例えばＣｏｎｎｅｃｔｉｏｎ Ｒｅｑｕｅｓｔパケット
を送信することによりサーバ１２を動作状態にさせることができる。その後クラ
イアント１６はスレーブ・モードに戻る（例えばタイム・アウト・オプションで
）。クライアントの要求が受信されると、サーバ１２はＣｏｎｎｅｃｔｉｏｎ
Ｒｅｑｕｅｓｔパケットを周期的に送信し、クライアント１６が上記で説明した
ようにそれに従うのを待機する（状態９６）。その送信によりクライアントがス
レーブ・モードにあることを確認した後、サーバ１２はクライアントの信頼性を
テストし（状態９７）、それがパスした場合は、クライアント１６にＣｏｎｎｅ
ｃｔｉｏｎ Ａｇｒｅｅｍｅｎｔを提供する。認証過程中の任意の時間中にホス
ト・コンピュータ１３が、クライアント１６が応答するのに必要な時間よりも長
い時間をとってしまった場合、サーバ１２はＣｏｎｎｅｃｔｉｏｎ Ａｇｒｅｅ
ｍｅｎｔパケットを再送信することによりクライアント１６を遅らせるが、クラ
イアント１６からの確認通知は実際上予期していない。Ｃｏｎｎｅｃｔｉｏｎ
Ａｇｒｅｅｍｅｎｔを送信した後、サーバ１２は新しいセッションＩＤを割り当
て（状態９８）、そしてクライアント１６が送信を認識通知するのを待機する（
状態９９）。通常の通信はその後開始することができる（状態１００）。

【００４２】 まずクライアントをマスタにし、次いでサーバ１２がアウェイクした後でそれ
をスレーブにすることにより、サブネット１０が動作していない際の、空いたチ
ャネルにおける低干渉が保証される。言うまでもないが、他の実施形態では、サ
ーバ１２はチャネル内の規則的な間隔でクライアント１６についてポーリングす
る。ただしこうした方式は、サブネット１０が動作していない時でもチャネルを
ビジーな状態にし、したがって近接するサブネットへのチャネルを否定すること
がある。

【００４３】 いくつかの実施形態では、複数のクライアント１６（またはシャドー・クライ
アント１８）が、サーバ１２からの同一の入力でサポートされる。そのような場
合、送信する必要があるのはフォワード・データ・パケットの１つのコピー（ク
ライアントＩＤが第１のクライアントのＩＤになっている）だけである。残りの
クライアントは、それぞれについてサーバ１２からの別々のコマンド・パケット
で、シャドー・クライアントとして扱われる。

【００４４】 複数クライアントのモデルでは、クライアント１６の１つが遅れてウェイクア
ップすると、それは静止（Ｑ）スロットを待機し、そのスロット中にそのコマン
ド・パケットの送信を開始する。ただし複数のクライアントがサーバ１２の後に
ウェイク・アップする可能性もあり、その場合本技術は、２つまたはそれ以上の
クライアント１６がそれぞれＱスロット中に送信を試みる場合に、生じる可能性
のある衝突を解決する手段を用意している。そのような衝突を回避するために、
クライアント１６はそれぞれの要求をＱスロット内に挿入する（またはしない）
ことを任意に選択することができる。サーバ１２により最初に認識されるクライ
アント１６は最初にサブネット１０に追加される、などである。

【００４５】 下の表３（Ｔｘは送信状態の無線装置１４を、Ｒｘは受信状態の無線装置１４
を表す）は、複数クライアントのモデルおよび新しいクライアントをオンライン
に挿入するための一般な状態図を詳述する。

【表３】

【００４６】 指定された時間スロット配列であるので、１つのクライアントが何らかの理由
で遅れて応答する場合、他のクライアントはその指定された時間スロットを把握
することができない。これにより貴重な帯域幅を無駄にしてしまうことがある。
したがって、本技術はこの問題に対して２つの要素からなる解決法を提供する。

【００４７】 第１に、各クライアント１６はチャネルを占有している現在のクライアントを
追跡するよう要求され、それによりライン中でそのすぐ直前にあるクライアント
の検出を試みる。チャネルが静止である場合、現在のクライアントはそれ自体の
送信を開始する前に所定の長さの時間待機する。待機時間は、２つのクライアン
ト間で許される静止時間のしきい値、および現在のクライアントの前にこれから
送信するクライアントの数によって決まる。これは接続セット・アップ中に確立
される送信の順序を用いる。静止時間にとって唯一の例外は、すべてのオンライ
ン・クライアント１６が送信を抑制しなければならないＱスロットである。

【００４８】 第２に、サーバ１２は任意のチャネルのテークオーバを監視し、一貫して遅延
しているクライアントを接続／切断するために適切な処置をとる。そのような応
答内の遅延が生じた時は、ビデオ生成クライアント／サーバはそれに応じて次の
ビデオ・スロット内の出力データのサイズを縮小する。これにより適切なスロッ
ト時間の同期化を維持することができる。映像生成クライアント／サーバは、使
用されていないチャネル長を把握し、現在の／次のビデオ・スロット中にその出
力を適切に縮小する。

【００４９】 新しいクライアントを接続するために、スロットＱのサイズは、少なくともＣ
ｏｎｎｅｃｔｉｏｎ Ｒｅｑｕｅｓｔパケットを伝搬する１つの無線データフレ
ーム４０と同じくらいの長さであるべきである。すなわち、新しいクライアント
１６はすべてのデータ・フレームを受信し、現在のセッション中のデータ・フレ
ーム構造を学習し、最後のオンライン・クライアントとサーバ１２の送信の間の
スロットＱ内に接続に対するその要求を挿入する。その要求は、いくつかのトラ
ンザクション（すなわちサーバ送信の間）についてのその一貫性についてチェッ
クした後で確認される。無線ターン・アラウンド時間を念頭に置き、Ｑスロット
と混同しないように注意されたい。これはタイマーを使用して検証してもよい。

【００５０】 サーバ１２がその接続要求を認識したことを新しいクライアントに通知するた
めに、サーバ１２はパケットを新しいクライアントに送信する必要がある。すな
わちサーバ１２は、サーバに続いてその送信を開始することになっている最初の
クライアント（すなわちスロットＢ₁を割り当てられているクライアント）が、
Ｆスロットの最後にサーバ１２により新しいクライアントに対して送信される最
後のパケットと重ならないようにする必要がある。したがって、サーバはＴｏｋ
ｅｎ Ｐａｓｓをその送信の最後にブロードキャストすることができる。そして
ライン中の最初のクライアントは、サーバ１２からＴｏｋｅｎ Ｐａｓｓを受信
した後に（および必要であれば、無線ターン・アラウンド時間を許可後で）、ま
たは使用されていないチャネルをタイム・アウトした後にその送信を開始する。

【００５１】 上記で説明したように、チャネルが変更されると、すべてのクライアント１６
はサーバ１２に対して再同期する必要がある。チャネルの切換えは、サーバ１２
またはクライアント１６の１つが深刻なチャネル障害（例えばアンテナの多様性
および／または高程度のＥＣＣにもかかわらず）を体験した際に起こることがあ
る。このようなモデルでは、サーバ１２は干渉がそれより深刻でないチャネルを
検出しようと試みて、別のチャネルを探す。新しいチャネルが通信動作のために
よりよい見込みを与えると判定した場合、サーバ１２はチャネル変更またはスイ
ッチ動作を開始する。

【００５２】 図８はサーバ１２から見た、２チャネルのサブネットについてのチャネル変更
の手順を示す。通常の通信中（状態１０１）に、チャネル状況が容認不可能であ
るまたは容認不可能になりつつあるとサーバ１２が判定する場合、新しいチャネ
ルの探索を開始する前に、サーバ１２はすべてのそのクライアント１６に一時的
に静止の状態でいるように通知する。この手順は複数回数繰り返され（状態１０
２）（例えば５回）、メッセージがすべてのクライアント１６によって受信され
ることを確実にする。クライアントはそれに応答して確認通知を送信することを
求められるが、確認通知がオンラインのすべてのクライアント１６から受信され
ない場合でも、サーバ１２のタイマーはタイム・アウトし、サーバ１２がその無
線１４を調整して他のチャネルを検査できるようにする（状態１０４）。新しい
チャネルが空いている場合、サーバ１２は本来のチャネルにスイッチ・バックし
（例えば一実施形態については４ミリ秒の所定の受信待機期間の後で）、Ｃｈａ
ｎｇｅ Ｃｈａｎｅｌメッセージを（おそらくは５回ほど繰り返し）すべてのオ
ンライン・クライアント１６にブロードキャストし、クライアント１６について
個々のチャネルＣｈａｎｇｅ Ｃｈａｎｎｅｌ Ａｃｋｎｏｅｌｅｄｇｅ（Ａｃ
ｋ．）メッセージの受信を待機する（状態１０６）。各クライアント１６は、そ
のＣｈａｎｇｅ Ｃｈａｎｎｅｌ Ａｃｋ．メッセージを送信した後にのみチャ
ネルを変更する。所定の長さの時間待機した後で、サーバ１２がなお１つまたは
複数のオンライン・クライアント１６から応答を受信していない場合、サーバ１
２はクライアントは到達不能であると判断する。同様にクライアント１６は、所
定の期間待機してもサーバからメッセージを受信しない場合サーバ１２は連絡不
可能であると判定し、任意でチャネルを変更することができる。すべてのオンラ
イン・クライアント１６が応答した後かまたはタイム・アウト状況の後に、サー
バ１２は新しいチャネルに切り替わる。

【００５３】 新しいチャネルに入ると、クライアント１６はサーバ１２が通信を開始するの
を待機する。サーバ１２は、Ｃｈａｎｇｅ Ｃｈａｎｎｅｌ Ａｃｋ．メッセー
ジをブロードキャストし（状態１０８）、それが新しいチャネルにあることを知
らせ、各クライアント１６からのＣｈａｎｇｅ Ｃｈａｎｎｅｌ Ａｃｋ．を待
つ。１つまたは複数のクライアント１６が所定の試行回数内に応答しない場合、
サーバ１２はクライアント１６は一時的に不在であると判定する。それに応じて
、サーバ１２はクライアント１６の応答シーケンスを変更して（例えば新しいＣ
ｏｎｎｅｃｔｉｏｎ Ａｇｒｅｅｍｅｎｔを送信することにより）、不在のクラ
イアントを締め出すようにする。すべてのクライアント１６がそれらが新しいチ
ャネル内にあることを確認する（またはタイム・アウト期間が切れる）のを待機
（状態１１０）した後、サーバ１２は新しいチャネルに対してコール−応答スロ
ット・シーケンスを更新し、新しい接続同意をすべてのクライアント１６に送信
する。通常の通信はその後に再開することができる（状態１１２）。

【００５４】 クライアント１６が新しいチャネルに遅れて到達する場合、クライアントはサ
ーバの呼が応答するのを待機する必要がある。サーバ１２がクライアント１６は
不在であるとすでに判断している場合、クライアント１６は通常の通信が再開す
るまで待機し、そしてＣｈａｎｇｅ Ｃｈａｎｎｅｌ Ａｃｋ．メッセージを静
止（Ｑ）スロット内で送信する。そのようなメッセージを受信するとサーバ１２
は接続同意を送信し、ネットワーク内の新しいクライアントを含む。

【００５５】 この時間中、新しいクライアントに関連するどのユーザにも影響を及ぼさない
でおくために、２つの措置がとられる。第１に、すべてのクライアント１６はユ
ーザ・レベルで円滑なセッションをシミュレートするために、ビデオ・フレーム
・フリーズおよび／または音声の反復を行う。第２にサーバ１２は、再接続を容
易にするのに十分な長さの所定期間、セッションの詳細を維持する。所定の待機
期間が満了した後にのみ、不在のクライアント１６はサーバのオンライン・クラ
イアント・リストから最終的に削除される（状態１１４）。

【００５６】 サーバ１２が、非常に新しいクライアント１６からそれがオンライン・リスト
から削除された後にＣｈａｎｇｅ Ｃｈａｎｎｅｌ Ａｃｋ．メッセージを受信
する場合、クライアント１６はＣｏｎｎｅｃｔｉｏｎ Ｒｅｑｕｅｓｔを送信す
ることにより新たに接続するように通知を受ける。このような場合、クライアン
ト１６はユーザにリンクが失われたことを通知することができる。これはユーザ
・レベルではパワー障害に類似のものに見え、ユーザにサーバ１２とのリンクを
再確立するよう指示をすることがある。

【００５７】 チャネル選択中に（例えば最初に、またはチャネル変更動作の一部としての）
、サーバ１２は現在のチャネル上ですでに動作しているサブネット１０、および
同一のＰＮコードおよび／またはリンクＩＤを持つリンクの潜在的な存在を検出
する必要がある。そのような事例が発生する可能性は非常に低いと予想されるが
、ゼロではない。リンクＩＤは、リンク／サブネット／セルに固有であると想定
されている。この固有性を保証するために、ユーザはサブネットのインストール
中に固有のパスワード（例えば社会保障番号または同様の長さの他の固有の英数
文字列）を入力するよう指示されることがある。このパスワードは、サーバ１２
（および／またはそのホスト・コンピュータ１３）により構文解析されて固有の
ＩＤおよびＰＮコードを確定するために使用してもよい。これらの値は、ユーザ
がそれを変更する（例えばサブネット１０を再インストールすることにより）と
決定しない限り、すべてのセッションについて同一のままである。

【００５８】 一実施形態では、より長いビット長を使用して固有性を保証しそれによりさら
なる安全性を提供することもできるが、１１ビットのＰＮコード（バーカー・コ
ード）を使用することもできる。使用可能なＰＮコードのテーブルがサーバ１４
／ホスト・コンピュータ１３により維持され、ユーザが入力するパスワードに基
づいてそのコードの１つが選択される。隣接するサブネット１０内で同一のＰＮ
コードが使用されたために干渉が増大した際はいつでも、ＰＮコードを変更して
よい。

【００５９】 両方のチャネルが占有されるかまたは大きな干渉がある場合、サーバ１２は２
つの動作のうち１つをとることができる。そこへのまたはそこからのチャネル干
渉が深刻であるクライアント１６の数が少ない場合、サーバ１２はそれらを切断
することを決定する。一方、関係するクライアント１６の数が多い場合、サーバ
１２はしばらく待機し、ある程度の時間が経ってからチャネルを試行することを
決定する。いずれの場合もサーバ１２は、影響を受けるクライアント１６それぞ
れからＤｉｓｃｏｎｎｅｃｔ Ａｃｋ．メッセージを受信するまで、Ｒｅｔｒｙ
Ｌａｔｅｒコマンドを関係するクライアント１６それぞれに送信する必要があ
る。

【００６０】 次に図９に、例示的な２チャネルのサブネットについて、クライアント・サイ
ドからのチャネル切換え動作を図示する。通常の通信中（状態１２０）にクライ
アント１６が静止でいるように指示を受けた場合、そのクライアント１６は確認
通知（例えばＤｉｓｃｏｎｎｅｃｔ Ａｃｋ．）を送信し、そしてサーバ１２か
らのさらなる指示を待つ（状態１２２）。サーバ１２がＣｈａｎｇｅ Ｃｈａｎ
ｎｅｌメッセージをブロードキャストする場合、クライアント１６はそれを確認
しそれからチャネルを変更する。別の方法として、所定の時間待機してもサーバ
１２からメッセージを受信しない場合、クライアント１６はサーバ１２は到達不
可能であると判定し、自発的にチャネルを変更してもよい。

【００６１】 新しいチャネルに入ると、クライアント１６はサーバ１２が通信を開始するの
を待機する（状態１２６）。サーバ１２はＣｈａｎｇｅ Ｃｈａｎｎｅｌ Ａｃ
ｋ．メッセージをブロードキャストして新しいチャネル内にそれがあることを通
知し、各クライアント１６からＣｈａｎｇｅ Ｃｈａｎｎｅｌ Ａｃｋ．を求め
る。それに応じてクライアント１６はサーバが新しいチャネル内にあることを確
認し、サーバ１２からの新規接続同意を待つ（状態１２８）。その接続同意をサ
ーバ１２とネゴシエートすると、クライアント１６は通常の通信が再開するのを
待機する（状態１３０）。

【００６２】 クライアント１６が新しいチャネルに到達するのが遅い場合、クライアントは
サーバのコールが応答するのを待機する必要がある。サーバ１２がクライアント
１６は不在であるとすでに判定している場合、クライアント１６は通常の通信が
再開するまで待機し、それからＣｈａｎｇｅ Ｃｈａｎｎｅｌ Ａｃｋ．メッセ
ージを静止（Ｑ）スロット内で送信する（状態１３２）。そのようなメッセージ
を受信するとサーバ１２は接続同意を送信し、新しいクライアントをネットワー
ク内に含む。この時間中、新しいクライアントに関連するいずれのユーザにも影
響を及ぼさないでおくために、クライアント１６はビデオ・フレーム・フリーズ
および／または音声反復を行い、ユーザ・レベルで円滑なセッションをシミュレ
ートすることができる。

【００６３】 サーバ１２が非常に新しいクライアント１６からそれがオンライン・リストか
ら削除された後にＣｈａｎｇｅ Ｃｈａｎｎｅｌ Ａｃｋ．メッセージを受信す
る場合、クライアント１６はＣｏｎｎｅｃｔｉｏｎ Ｒｅｑｕｅｓｔを送信する
ことにより新たに接続するよう通知を受ける。このような場合、クライアント１
６はユーザにリンクが失われたことを通知することがある（状態１３４）。これ
はユーザ・レベルではパワー障害に類似のものに見え、ユーザにサーバ１２との
リンクを再確立するように指示をすることがある。チャネル選択中に、クライア
ント１６がサーバ１２とのコンタクトを長時間失った場合、クライアントはユー
ザに状況を通知しターン・オフすることがある（状態１３６）。

【００６４】 クライアント１６と同様に、サブクライアント２０もオンラインで動作中のサ
ブネットに加えることができる（すなわちホット・インサーションとも呼ばれる
）。図１８に示すように、サブクライアント２０はウェイク・アップすると、そ
れに関連するクライアントに通信リンク２１を介して登録パケットを送信する（
状態２２０）。いくつかの場合、通信リンク２１は無線リンク（例えば赤外線通
信リンク）であり、他の場合では有線リンクであることもある。クライアント１
６はサブクライアント２０からの送信を受信すると、例えばその登録識別情報を
知られている／認証済みのサブクライアントのリストに照らしてチェックするこ
とにより、サブクライアントを認証する（状態２２２）。場合によっては、これ
はサーバ１２との通信を必要とすることもある。サブクライアント２０が承認さ
れる場合、クライアント１６は、新しいサブクライアントをネットワーク上でク
ライアントと動作している他のサブクライアントから独自に識別する、サブクラ
イアント・セッション識別子を構成する。次いでクライアント１６は、Ａｄｄ
Ｓｕｂｃｌｉｅｎｔコマンド（下記をさらに参照のこと）をサーバ１２に送信す
る（状態２２４）。Ａｄｄ Ｓｕｂｃｌｉｅｎｔコマンドは、サブクライアント
・セッション識別子、および下記でさらに詳しく説明されるサブクライアントの
特徴を含む。

【００６５】 サーバ１２はＡｄｄ Ｓｕｂｃｌｉｅｎｔコマンドを受信すると、サブクライ
アント・セッションＩＤを記録することにより、およびサブネットが新サブクラ
イアントの追加を受け入れられるか（例えば、新サブクライアントからまたはそ
れに送信されるコマンドを受け入れるために、無線リンク上で十分な帯域幅が使
用できるか）どうかを判定することにより、サブクライアント認証プロセスを完
了する（状態２２６）。認証プロセスがうまく行く場合、サーバは、新サブクラ
イアントをオンラインのサービス・テーブルに挿入することにより、および関連
するクライアントにＳｕｂｃｌｉｅｎｔ Ａｄｄｅｄコマンドを送信することに
より、新サブクライアントをサブネットに追加する。新サブクライアントを受け
入れることができない場合、あるいは新サブクライアントが別の形で拒否される
場合、サーバはＳｕｂｃｌｉｅｎｔ Ｎｏｔ Ａｄｄｅｄコマンドを送信する。

【００６６】 サーバがどのような判断を行っても、認証プロセスの結果はクライアントから
サブクライアントに送信される（状態２２８）。サブクライアントが承認された
場合、それは通常の動作を開始しそのクライアントおよびサーバ１２と通信を行
う（状態２３０）。サブクライアントが拒否された場合は、切断される（状態２
３２）。いずれの場合も、ユーザには、表示装置に表示される適切な状態メッセ
ージを通してサブクライアントの追加または拒否が通知される。

【００６７】 ネットワーク動作中に、サブクライアント２０はサーバ１２または関連するク
ライアント１６のいずれかにより切断されることがある。例えばサブクライアン
ト２０が所定の長さ以上の時間にわたって非アクティブである場合、クライアン
ト１６はサブクライアント２０との接続を解除することがある。そのような場合
クライアント１６はサーバ１２に状況を通知し、切断されたサブクライアントを
オンライン装置のサーバのリストから除去するよう要求しなければならない（下
記のＤｅｌｅｔｅ ＳｕｂｃｌｉｅｎｔおよびＳｕｂｃｌｉｅｎｔ Ｄｅｌｅｔ
ｅｄコマンドについての説明を参照されたい）。

【００６８】 他の場合では、例えばホスト１３上で動作中のアプリケーションが特定のサブ
クライアント（または、さらに言えばクライアント）をサポートしない場合、サ
ーバ１２はサブクライアント２０を直接除去することを決定してもよい。またネ
ットワーク維持およびシャットダウン動作も、サブクライアント（およびクライ
アント）を自動的に削除されることを要求することがある。

【００６９】 Ｃ．ネットワーク・パケット構造 図１０に示すように、無線リンク内を送信されたパケット４２には３つの主要
な部分がある：ヘッダ１４０、可変長ペイロード１４２、ＥＣＣブロック１４４
である。図１１に詳細を示すようにヘッダ１４０は、クライアントＩＤについて
のフィールド１４６、タイム・スタンプ１４８、ＳＴＰ１５０、パケット長１５
２を含んでいる。いくつかのパケット（例えばオーディオ・パケットおよびいく
つかのコマンド）４２は、ホスト・コンピュータ１３で発信し、したがってサー
バ１２に対する入力である。ただしサーバ１２は、関連する無線装置１４にパケ
ット４２を書き込む前に、タイム・スタンプ１４８をこれらのパケット４２に加
える（例えば受信側における適切な同期化を可能にするために）。

【００７０】 １つの例示的実施形態では、ヘッダ１４０はダブル・ワード（ＤＷＯＲＤ、例
えば一実施形態では３２ビット）であり、パケット４２へのまたはパケット４２
からのデータの書き込みおよび読み出しが、どの８／１６／３２ビットのハード
ウェア構造においてもより少ないプロセッサ時間の消費で処理されるように位置
合わせされる。クライアントＩＤフィールド１４６は１バイトの長さであり、サ
ブネット１０内のクライアント１６に対して固有のものである。これにより、サ
ーバ１２ごとに２５５の異なるクライアント１６をサポートすることができる。
特別なクライアントＩＤ（例えばすべての「１」）はブロードキャストのために
確保しておくことができ、他のクライアントＩＤ（例えばすべての「０」）はサ
ーバ１２のために確保しておくことができる。タイム・スタンプ１４８は、オー
ディオおよびビデオ・パケットをいずれ同期するために加えられる。タイム・ス
タンプ１４８は、サーバ１２で維持される時間カウンタの出力として与えられる
。クライアント１６およびホスト・コンピュータ１３は、入ってくるパケット内
で提供されるタイム・スタンプ１４８を使用して、それぞれの時間カウンタを同
期することができる。

【００７１】 ＳＴＰフィールド１５０は、パケットのソース（Ｓｏｕｒｃｅ）、パケット内
に含まれているデータのタイプ（Ｔｙｐｅ）、現在の時間スロット内でのパケッ
トの位置（Ｐｏｓｉｔｉｏｎ）についての情報を提供する。このフィールドは３
つのサブフィールド（図示していない）に分割される。上部のサブフィールド（
一実施形態では３ビットの長さ）は、パケットのオリジンを表すために使用され
る（例えばサーバ１２についてはすべての１、クライアント１６についてはすべ
ての０）。ただし、このフィールドは、サーバ１２とそのホスト・コンピュータ
１３の間で交換される通信パケットについては無視される。パケット４２が受信
されると、パケット４２のオリジンを決定するために、このフィールド内のデー
タを使用して多数決論理ヴォーティングが実行される。

【００７２】 ＳＴＰフィールド１５０の中間サブフィールド（この実施形態についても３ビ
ットの長さでよい）は、パケット・タイプを表す。サポートされるタイプには：
オーディオ・パケット、ビデオ・パケット、データ・パケット（例えばキーボー
ド、マウス、ジョイスティックなどの出入力装置からの）、クライアント１６か
らまたはクライアント１６へのコマンド・パケット、サーバ１２からまたはサー
バ１２へのコマンド・パケットが含まれる。プロトコル方式は、ビデオ、音声、
サーバ１２とクライアント１６との間のコマンド、またサブネット１０内のサブ
クライアント２０からの低帯域幅データの転送を可能にする。低帯域幅データの
例には、キーボード入力、マウス入力、アナログ・ジョイスティック入力などが
含まれる。オーディオおよびビデオは別々のパケットで通信され、無線装置１４
により別々のデータ・フレーム４０として送信される。ただし低帯域幅データ・
パケットはコマンド・パケットと組み合わせて、１つのデータ・フレーム４０と
して送信してもよい。

【００７３】 ＳＴＰフィールド１５０の最後のサブフィールド（サブフィールドのＰｏｓｉ
ｔｉｏｎ）は２ビットの長さであり、どこでパケットがパケットのグループ内に
入るかを指定する。このフィールドは、下記（１つの値はＤＯＮ’Ｔ ＣＡＲＥ
でよい）のように表される値を有する。

【００７４】 Ｆｉｒｓｔ Ｐａｃｋｅｔ：これは現在のパケットがソースから送信される最
初のパケットであり、その後にまだパケットがあることを示す。 Ｃｏｎｔｉｎｕａｔｉｏｎ Ｐａｃｋｅｔ：これは、現在のパケットの後に、
同一のソースからのパケットが少なくとも２つあることを示す。 Ｏｎｅ Ｂｅｆｏｒｅ ｔｈｅ Ｌａｓｔ Ｐａｃｋｅｔ：これは、現在のパ
ケットの後には、同一のクライアント１６（またはスロットＦ中のサーバ１２）
からのパケットが１つだけあることを示す。 Ｌａｓｔ Ｐａｃｋｅｔ：これは現在のパケットが現在のクライアント１６（
またはスロットＦではサーバ１２）からの最後のパケットであることを示す。

【００７５】 このフィールド内の情報を使用することにより、ライン中の次に送信をするク
ライアント１６は、先行するクライアント１６による送信の終了を少なくとも１
パケット早く検出することができる。最後のパケット４２の受信中に、それはそ
の関連する無線装置１４に、そのパケットの後で送信モードに切り替わるよう指
示を出す。

【００７６】 パケット・フィールド１５２の長さは、現在のパケット４２中にあるＤＷＯＲ
Ｄの数を示す。長さゼロのパケットは使用されないことが好ましいので、ＤＷＯ
ＲＤの実際の数は、長さフィールド１５２で示される長さより１つ多くてよい。

【００７７】 ペイロード・フィールド１４２はパケット４２の本体である。オーディオ・パ
ケットおよびビデオ・パケットに関しては、このフィールドはそれぞれのソース
からの圧縮されたオーディオ・データまたはビデオ・データ（適切に応じて）を
含む。データ・パケットについては、ペイロード・フィールドはキーボードまた
はマウスなどの出入力装置によって生成されたデータを含む。

【００７８】 図１２にデータ・パケット１５４のペイロード構造を示す。好ましくはサブク
ライアント・タイプ（ＳＣＴ）１５６、サブクライアントＩＤ（ＳＣＩＤ）１５
８、データ長１６０は実際のデータ１６２より前に現れ、受信側がデータ生成装
置のソースを学習するのを援助するとよい。１つ以上のデータのセット１６２を
単一のデータ・パケット１５４内に含んでもよく、その場合各データ・セットは
それ自体のＳＣＴ、ＳＣＩＤおよび長さパラメータを必ず有する。

【００７９】 ＳＣＴフィールド１５６は、受信側にキーボード、マウス、アナログ・ジョイ
スティックなど情報ソースのタイプを備え、ＳＣＩＤフィールド１５８はその特
定のサブクライアント・タイプの個々のサブクライアントを識別する。例えば、
キーボードおよびマウスは同様のサブクライアントＩＤを有しうるが、それらの
異なるサブクライアント・タイプをそれぞれのＩＤと関連付けることにより区別
することができる。この種のプロトコル・サポートにより、実行中のセッション
の最中またはその前の任意の時間に、異なる種類の低帯域幅のサブクライアント
２０を、同一のクライアント１６に追加することが容易になる。ＳＣＴフィール
ド１５６およびＳＣＩＤフィールド１５８はともに８ビットの幅でよく、それに
より２５６の異なるタイプのサブクライアント２０をサポートし、各タイプにつ
き２５６までのサブクライアントが各クライアント１６に接続可能である。

【００８０】 データ要求は長さフィールド１６０を含まない。ただしデータ送信は長さフィ
ールド１６０を含み、その長さフィールド１６０は１バイトの長さでよく、後に
続くデータの長さを指定する。実際の低帯域幅データ１６２自体は長さフィール
ドの後に続く。一実施形態については、これらのパケット１５４の全長は各ビデ
オ・フレームにつき１２０バイトを超えてはならない。

【００８１】 コマンド・パケットについては、ペイロード・フィールド１４２は一連のコマ
ンドを含み、各コマンドの後には関連するデータ・バイト、および／またはサブ
クライアント２０からの低帯域幅データが続く。すなわちこの実施形態では、サ
ーバ１２は、無線リンクを介してクライアント１６に次々に送信される必要のあ
るすべてのコマンドを、１つのデータ・パケット４２内にまとめている。したが
って、サーバ１２が送信するコマンド・パケットの最大数は、サーバ１２が現在
サポートしているオンライン・クライアント１６の数と等しくなる。それとは反
対に、各フレーム中にサーバ１２に送信される必要のある、コマンドのシーケン
スおよび／またはその関連するサブクライアント２０からの低帯域幅データを含
むコマンド・パケットは、どのクライアント１６からも最大で１つだけしかない
。

【００８２】 以下では無線リンク間の通信の各方向でサポートされるコマンドについて説明
する。別に指摘しない限り、この実施形態ではサーバ１２／クライアント１６か
ら送信されるどのパケットについても確認通知（Ａｃｋ．）は求められない。任
意の数のコマンドをともに並べてデータ・パケット４２を形成することができ、
その場合唯一の制限はオーバーオール・パケット４２のサイズである。この実施
形態については、パケット４２の合計サイズは、各ビデオ・フィールド継続期間
につき８０バイトを超えてはならない。他のパケット・サイズは、多様な入力装
置（例えばキーボード、マウス、ジョイスティックなど）の帯域幅要件の考慮に
基づいて選択することができる。図１３にはコマンド・パケット１６４について
の一般的なペイロード構造を示す。各コマンド・パケット１６４は、ヘッダ１６
６、および「ｎ」コマンド・フィールド１６８を含む。コマンド・フィールド１
６８はコマンド１７０、およびあれば関連するいずれのペイロード１７２を含む
こともある。関連するペイロード１７２がない場合、コマンド・フィールド１６
８は単一バイトの長さである。いくつかのコマンド１７０については、関連する
ペイロード１７２は所定のサイズである。さらに他のコマンド１７０は、可変長
のペイロード１７２を有することがある。そのような場合、ペイロード長はペイ
ロード・フィールド１７２の前に（またはその中で）明確に指示される。

【００８３】 １．クライアント１６へのまたはクライアント１６からのコマンド サーバ１２からクライアント１６へのコマンドのセット、およびクライアント
１６からサーバ１２へのコマンドのセットは本技術によりサポートされる。サー
バ１２は、そのホスト・コンピュータ１３とは無関係にコマンドの大半を処理す
るように構成される。大きなテーブル（例えばサーバ１２によってローカルに格
納することができないもの）へのアクセスおよびユーザ入力に伴う決定だけは、
ホスト・コンピュータ１３に渡す（およびホスト・コンピュータ１３から発する
）必要がある。サーバ１２が各コマンド・パケット１６４を読み出す／コンパイ
ルする際、そうした情報が有用でありうる場合には（例えば、サーバ１２が特定
の各クライアント１６について同一の同意された制約を固守する必要がある、Ｃ
ｏｎｎｅｃｔｉｏｎ Ａｇｒｅｅｍｅｎｔのようなコマンドについて）、パケッ
トのコピーをそれ自体のために保存しておくよう決定することがある。一実施形
態では、サポートされるコマンドは下記のものを含むことがある。

【００８４】 Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｑｕｅｓｔ：これはペイロードがないパケットで
ある。各クライアント１６はこのコマンドを使用して、サーバ１２にそれが始動
中でありサービスを必要としていることを知らせる。サーバ１２は同一のコマン
ドを使用して応答する。クライアント１６およびサーバ１２は、適当な時間同期
が実現されるまでこのコマンドを互いに繰り返し送信する。同期化が実現される
と、サーバ１２はマスタになり、クライアント１６の信頼性をチェックする。認
証手順がうまく行かない場合、サーバ１２はＤｉｓｃｏｎｎｅｃｔ Ｒｅｑｕｅ
ｓｔ（Ｒｅｑ．）コマンドを送信することによりクライアント１６を拒否する。
クライアント１６はＤｉｓｃｏｎｎｅｃｔ Ａｃｋ．を送信することにより応答
することが求められる。一方、クライアント１６の認証がうまく行った場合、ホ
スト・コンピュータ１３はＣｌｉｅｎｔ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｐａ
ｓｓメッセージをサーバ１２に送信する。サーバ１２は、クライアント１６のス
ループット要求を受け入れることが可能であるかどうかをチェックする。可能で
ない場合、サーバはＲｅｔｒｙ Ｌａｔｅｒコマンドをクライアント１６に送信
することにより、クライアントに後で接続を再試行するように通知する。このよ
うな場合、クライアント１６はＤｉｓｃｏｎｎｅｃｔ Ａｃｋ．を送信すること
により応答するように求められる。サーバ１２はクライアント１６の受け入れを
決定すると、Ｃｏｎｎｅｃｔｉｏｎ Ａｇｒｅｅｍｅｎｔｓパケットをクライア
ント１６に送信することにより接続許可を暗に示す。

【００８５】 図１７に、例示的Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｑｕｅｓｔパケット２１０の構
造を図示する。Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｑｕｅｓｔパケット２１０は、接続
要求コマンド・フィールド２１２、クライアント連続番号フィールド２１４、ク
ライアント特性フィールド２１６を含む。連続番号フィールド２１４およびクラ
イアント特性フィールド２１６中に含まれている情報は、サーバ１２に対する個
々のクライアントを識別するために機能する。こうした情報は製造時にクライア
ント内のメモリ（例えば読み出し専用メモリ）中に格納することができ、クライ
アントのタイプ、製造者、ドライバ情報、他のクライアント識別情報を含むこと
ができる。クライアントがサブネットへのアクセスを許可されようとする場合、
サーバ１２は、パケットをクライアント１６に送信する最中に、クライアント・
セッションＩＤ２１８をパケットに加えることができる。その後、クライアント
はサーバ１２へのその送信の際に、セッションＩＤ情報を利用することができ、
冗長な連続番号および特性フィールドを毎回再送信せずにすむ。したがって、ク
ライアント・セッションＩＤ２１８は、クライアント１６をサーバ１２に対して
識別する際の簡略な方法として機能し、また必要であればサーバ１２が特定のク
ライアント１６を行先とするデータおよびコマンドをアドレス指定できるように
もする。これにより全体の帯域幅が節約できる。

【００８６】 Ｃｏｎｎｅｃｔｉｏｎ Ａｇｒｅｅｍｅｎｔｓ：サーバ１２はこのコマンドを
３つの目的で使用する。第１に、接続認可を新しいクライアント１６に暗示する
ため、および接続の条件を指定するため（例えば、サーバ−クライアントおよび
クライアント−サーバの帯域幅に関しては、ＥＣＣタイプ、オーディオ／ビデオ
情報の圧縮タイプなど）。第２に、クライアント１６がこのコマンドをセッショ
ン中に受信すると、そのコマンドは以前にネゴシエートされた接続同意内の強制
的変更を暗示する（例えば、チャネル状態の不良、新しいクライアントがサブネ
ット１０に追加されたなどの理由で）。第３に、特定のクライアント１６が所定
の時間（比較的長い）静止していることにサーバ１２が気付くと、サーバ１２は
、以前にネゴシエートされた接続を事実上変更することなく、Ｃｏｎｎｅｃｔｉ
ｏｎ Ａｇｒｅｅｍｅｎｔｓパケットを送信し、それと引き換えに確認通知を求
める。クライアント１６と接触するために所定の回数の試行を行っても確認通知
が受信されない場合、クライアント１６は切断されていると宣言される。いくつ
かの場合では、例えばクライアント１６がサーバのデータ転送速度に対処できな
い場合には、これと同一のコマンドはクライアント側から発することもあること
に注意されたい。

【００８７】 一実施形態では、Ｃｏｎｎｅｃｔｉｏｎ Ａｇｒｅｅｍｅｎｔコマンドについ
ての合計のペイロード・サイズは５バイトであり、パケット構造１７４に含まれ
るネゴシエーションの項を図１４に示す。Ｃｏｎｎｅｃｔｉｏｎ Ａｇｒｅｅｍ
ｅｎｔパケット１７４は、パケットを識別する接続同意コマンド１７６で始まる
。フォワード帯域幅フィールド１７８は、クライアントがサーバから受信するこ
とを期待できるパケットの数を指定するために使用される。リバース帯域幅フィ
ールド１８０は、クライアントがそのリバース・スロット中にサーバに送信しう
るパケットの数を指定するために使用される。これらのフィールドは、各方向の
ビデオ、オーディオ、データ帯域幅も定義する。ＰＣＬ−ＩＤフィールド１８６
は、先行するクライアント（８ビット）のＩＤを指定する。サーバ１２の後に送
信を許可される最初のクライアントは、ゼロ（０）をそのＰＣＬ−ＩＤとして受
信する。ＣＮＵＭ１８８は、クライアント・オンライン番号であり、クライアン
ト１６に現在のオンライン・サービス・リストにおいてそれに先行するクライア
ントの数を知らせる。

【００８８】 ＳＣＡ（送信クライアント属性）１９０は、クライアント１６にそのプロパテ
ィまたは属性が必要とされているかいないかを知らせるために、サーバ１２によ
って使用される制御フィールドである。例えばＳＣＡ１９０がすべて１にセット
される場合、これはクライアント１６がそのプロパティをサーバ１２に送信する
必要があることを示す（例えばクライアントのプロファイルが間違って消された
場合、または新しいクライアントの設置である場合）。サーバ１２はパケットを
繰り返して（タイム・スタンプの変更とともに）これらのプロパティを受信した
ことを確認通知し、その後でクライアント１６はＣｏｎｎｅｃｔｉｏｎ Ａｇｒ
ｅｅｍｅｎｔ Ａｃｋ．を送信する。一方、ＳＣＡフィールド１９０がすべて０
にセットされる場合、これは以前に定義されたプロパティをクライアント１６が
固守するか、またはログ・アウトすることをサーバ１２が要求していることの指
示として使用される。ＳＣＡ１９０中の任意のビットが、無線リンクを送信され
ている間に破壊されてしまった場合は、反復中の固有の冗長がサーバ１２／クラ
イアント１６で使用されて（例えば多数決論理ヴォーティングにより）、その実
際の内容を判定する。

【００８９】 Ｃｏｎｎｅｃｔｉｏｎ Ａｇｒｅｅｍｅｎｔ Ａｃｋ．：このパケットはクラ
イアント１６を発信元とし、Ｃｏｎｎｅｃｔｉｏｎ Ａｇｒｅｅｍｅｎｔｓコマ
ンドに応答して送信される。これはペイロードのないパケットである。

【００９０】 Ａｄｄ Ｓｕｂｃｌｉｅｎｔ：各クライアント１６は、それがサポートする必
要があるサブクライアント２０を決定することについて責任を負い、このコマン
ドを使用してサーバ１２に同一の内容を報告する。これによりサーバ１２は、必
要とされている帯域幅を割り振ることができる。帯域幅要件が満たされる場合、
サーバ１２はホスト・コンピュータ１３にサブクライアント２０について通知し
、ホスト・コンピュータ１３が関連するドライバをロードできるようにする。図
１５に示すように、サブクライアント追加パケット１９２は、コマンドＩＤ１９
４、ならびにサブクライアント・セッションＩＤ（ＳＳ−ＩＤ）１９６、サブク
ライアント・タイプ（ＳＣＴ）１９７、サブクライアントＩＤ（ＳＣＩＤ）１９
８を含むことができる。ＳＳ−ＩＤ１９６は上記で説明したクライアント・セッ
ションＩＤと同様の目的をサービスし、ＳＳ−ＩＤ１９６およびＳＣＩＤ１９８
は、サブクライアント２０がウェイク・アップする限り、サーバ１２および対応
するクライアント１６により動的に割り振られることができることに注意された
い。

【００９１】 Ｓｕｂｃｌｉｅｎｔ Ｎｏｔ Ａｄｄｅｄ：このコマンドはサーバ１２により
クライアント１６に送信され、新しいサブクライアント２０を含むことに成功し
たことを示す。コマンド・タイプ以外にも、関連づけられたＡｄｄ Ｓｕｂｃｌ
ｉｅｎｔコマンド内にあるフィールドに類似するＳＣＴおよびＳＣＩＤフィール
ドを使用してもよい。

【００９２】 Ｓｕｂｃｌｉｅｎｔ Ｎｏｔ Ａｄｄｅｄ：このコマンドはサーバ１２により
クライアント１６に送信されて、新しいサブクライアントを追加することが不可
能であることを示す。コマンド構造はＡｄｄ Ｓｕｂｃｌｉｅｎｔコマンドと同
じでよい。

【００９３】 Ｄｅｌｅｔｅ Ｓｕｂｃｌｉｅｎｔ：クライアント１６は応答しないサブクラ
イアント２０はどれもタイム・アウトしてよく、それをサーバ１２に報告する。
いくつかの場合では、サブクライアント２０のうち選択されたセットだけをタイ
ム・アウトすることができる。もはや利用されていないサブクライアント２０を
削除することで、サーバ１２は以前に割り振られた帯域幅を再使用することがで
き、またホスト・コンピュータ１３は関連する任意のドライバをアンロードする
ことができる。パケットはサブクライアント・タイプおよびサブクライアントＩ
Ｄを含み、そのコマンド構造はＡｄｄ Ｓｕｂｃｌｉｅｎｔコマンドと同じであ
ってよい。

【００９４】 Ｓｕｂｃｌｉｅｎｔ Ｄｅｌｅｔｅｄ：このパケットはＤｅｌｅｔｅ Ｓｕｂ
ｃｌｉｅｎｔコマンドに応答して、サーバ１２からクライアント１６に送信され
る。そのコマンド構造はＡｄｄ Ｓｕｂｃｌｉｅｎｔコマンドについての構造と
同じでよい。

【００９５】 Ｒｅｓｅｔ Ｃｌｉｅｎｔ：このコマンドはサーバ１２を発信元とし、受信す
るクライアント１６がそれ自体をリセットしてＣｏｎｎｅｃｔｉｏｎ Ｒｅｑｕ
ｅｓｔ段階から再び開始するよう要求する。これはペイロードのないパケットで
ある。

【００９６】 Ｒｅｓｅｔ Ａｃｋ．：これはＲｅｓｅｔ Ｃｌｉｅｎｔコマンドに対する確
認通知である。これはペイロードのないパケットである。

【００９７】 Ｄｉｓｃｏｎｎｅｃｔ Ｒｅｑｕｅｓｔ：このコマンドは、サーバ１２がクラ
イアント１６を除くか、あるいはクライアント１６がターンオフされるかに応じ
て、サーバ１２またはクライアント１６のいずれかを発信元とする。これはペイ
ロードのないパケットである。

【００９８】 Ｒｅｔｒｙ Ｌａｔｅｒ：このコマンドはサーバ１２を発信元とし、深刻なチ
ャネル状況または帯域幅制限のいずれかの理由で、現在クライアント１６にはサ
ービスすることができないことをクライアント１６に通知する。こうしたコマン
ドを受信すると、クライアント１６は同一の情報を関連するユーザに渡し、それ
によりユーザに後で接続を試みるように指示を出す。このパケットにはペイロー
ドはない。

【００９９】 Ｄｉｓｃｏｎｎｅｃｔｉｏｎ Ａｃｋ．：これはＤｉｓｃｏｎｎｅｃｔ Ｒｅ
ｑｕｅｓｔおよびＲｅｔｒｙ Ｌａｔｅｒコマンドに対する確認通知である。こ
れはペイロードのないパケットである。

【０１００】 Ｋｅｙ Ｆｒａｍｅ Ｒｅｑｕｅｓｔ：このコマンドはビデオ送信の受信側を
発信元とし、受信側でフレームの損失がある場合はいつでも送信される。このコ
マンドに対する確認通知は、送信側から再送信されたキー・フレームの形をとる
ことがある。これはペイロードのないパケットである。

【０１０１】 Ｃｈａｎｎｅｌ Ｓｔａｔｕｓ：このコマンドは、規則的な間隔でクライアン
ト１６により自発的に提供されて、サーバ１２にそのチャネル・ステータスを通
知する。チャネル・ステータス・バイトはパケットのペイロードを形成し、それ
は１バイトの長さでよい。

【０１０２】 Ｔｏｋｅｎ Ｐａｓｓ：これはペイロードのないコマンドであり、送信者から
の送信の終了を信号で知らせる。このコマンドは次のクライアント１６（または
サーバ１２）に、送信を開始するよう指示を出す。サーバ１２はその送信を開始
するために、最後のクライアント１６からのこのコマンドを待機する。サーバ１
２がこのパケットを送信すると、クライアントＩＤはすべて０にセットされ、ス
トリング中の最初のクライアント１６にその送信を開始するよう指示する。これ
はダミーの確認通知または「クライアントが生きている」という信号と見ること
もでき、その場合サーバ１２は最初にサーバ１２に通知しないでシャット・オフ
するいずれのクライアント１６を追跡する。同一のコマンドを使用してチャネル
変更の完了を指示することもできる。

【０１０３】 Ｒｅｍａｉｎ Ｑｕｉｅｔ：これはペイロードのないコマンドであり、サーバ
１２を発信元とする。サーバ１２はチャネル切換えの前にこのコマンドを使用し
て、サーバが他のチャネルをチェックして戻るまで静止の状態でいるようにすべ
てのクライアント１６に通知する。各クライアント１６は、コマンドを確認通知
する（例えばＤｉｓｃｏｎｎｅｃｔ Ａｃｋ．を送信することにより）よう求め
られる。

【０１０４】 Ｃｈａｎｇｅ Ｃｈａｎｎｅｌ：これはペイロードのないコマンドであり、サ
ーバ１２を発信元とする。サーバ１２が他のチャネルが現在のチャネルより良好
であると判定する場合、サーバはすべてのクライアント１６にチャネルを変更す
るよう通知する。

【０１０５】 Ｃｈａｎｇｅ Ｃｈａｎｎｅｌ Ａｃｋ．：これはＣｈａｎｇｅ Ｃｈａｎｎ
ｅｌコマンドに応答して、各クライアント１６によりサーバ１２に送信される確
認通知である。これはペイロードのないパケットである。同一のコマンドはサー
バ１２およびクライアント１６の双方によって使用することができ、チャネル変
更の完了／打切りを確認する。

【０１０６】 Ｎｅｗ ＰＮ Ｃｏｄｅ：このコマンドはサーバ１２を発信元とし、新しいＰ
Ｎコード・ビットおよび変更が実施される時間マークを含んだペイロードを含む
。

【０１０７】 Ｎｅｗ ＰＮ Ｃｏｄｅ Ａｃｋ．：これは受信したＮｅｗ ＰＮ Ｃｏｄｅ
コマンドに応答して、各クライアント１６からサーバ１２に送信される確認通知
である。各クライアント１６は、新しいＰＮコードを反復して、サーバ１２が適
切な受信を確認できるようにする。２つのコードが一致しない場合、サーバ１２
はＮｅｗ ＰＮ Ｃｏｄｅコマンドを再送信することがある。

【０１０８】 ２．ホスト・コンピュータ１３からの、またはホスト・コンピュータ１３への
コマンド サーバ１２とのホスト・コンピュータの通信は無線リンク上では行われず、２
つのレベルで見ることができる。第１のレベルは、従来のハードウェア・ポート
および低レベルのシグナリングを使用して、「ｔｒａｎｓｍｉｓｓｉｏｎ ｃｏ
ｍｐｌｅｔｅ」「ｒｅｃｅｉｖｅｒ ｂｕｆｆｅｒ ｆｕｌｌ」など、一般にコ
ンピュータ・アプリケーションで使用されている低レベル・メッセージを通信す
る。第２のレベルは、第１のレベル上に確立され、上記で説明したネットワーク
・プロトコル、パケット・フォーマットなどを使用して、クライアントの接続お
よび切断などより高位レベルの情報を伝搬する。通信の第１のレベルは事実上従
来式のものであり、これ以上は説明しない。通信の第２のレベルは以下のコマン
ドを利用する。

【０１０９】 Ｄａｔａ Ｒｅｑｕｅｓｔ：このコマンドはサーバのメモリの内容に対する要
求として、ホスト・コンピュータ１３を発信元とする。サーバ１２は、Ｄａｔａ
Ｓｅｎｄコマンドを使用してデータを提供することにより応答する。同一のコ
マンドは、ホスト・コンピュータ１３からのデータで特定のメモリのブロックを
満たすためにサーバ１２により使用される。コマンド構造は、データがないとい
う点を除いてはデータ送信パケットと同じである。

【０１１０】 Ｄａｔａ Ｓｅｎｄ：このコマンドはホスト・コンピュータ１３またはサーバ
１２を発信元とする。ホスト・コンピュータ１３はこのコマンドを使用して、サ
ーバ１２に格納されているデータの内容を変更する。サーバ１２は、ホスト・コ
ンピュータ１３から要求がある際に、このコマンドを使用してそのデータを供給
する。

【０１１１】 データ送信パケット２００のフォーマットを図１６に図示する。示すように、
パケットは、コマンド・タイプを識別するコマンドＩＤ２０２を含む。アクセス
中のメモリ位置を識別するために、高バイトおよび低バイトのアドレス・フィー
ルド２４０、２０６が含まれる。最終的に、データ・ペイロード２０８自体が提
供される。

【０１１２】 低レベルの通信で通常使用されるメールボックス登録がサーバのメモリ位置の
内容を格納するには十分でないかもしれないという事実により、データ要求／送
信コマンドはここでサポートされる（それは他の実施形態では低レベルのコマン
ドかもしれないが）。

【０１１３】 Ｃｌｉｅｎｔ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｐａｓｓ：このコマンドは、
ホスト・コンピュータ１３からサーバ１２に送信され、クライアント１６を受け
入れられることを示す。これはペイロードのないコマンドでよい。

【０１１４】 Ｓｈｕｔｄｏｗｎ：ホスト・コンピュータ１３は、シャット・ダウンする前に
このコマンドをサーバ１２に送信する。同一のコマンドは、ホスト・コンピュー
タ１３が何らかの理由（例えば保護者による規制）でクライアント１６をサポー
トすることを望まない時間中に使用されることがある。サーバ１２はすべてのク
ライアント１６との接続を切断し、Ｓｈｕｔｄｏｗｎ Ａｃｋ．を通じてホスト
のコマンドに確認通知する。これはペイロードのないコマンドである。

【０１１５】 Ｓｈｕｔｄｏｗｎ Ａｃｋ．：これはサーバ１２を発信元とする、ペイロード
のないコマンドである。このコマンドがパスされた後、サーバ１２はタイム・ア
ウトしシャット・ダウンする。ホスト・コンピュータ１３はシャット・ダウンす
る前に、この確認通知を待つ（またはタイム・アウトする）。

【０１１６】 Ｄ．ネットワーク事項 ネットワークは、最初のスタート・アップの際にインストールしなければなら
ない。これはサブネット１０間でのＰＮコードの配布を必要とし（例えば２つの
隣接するサブネットによる、同一のＰＮコードの使用を最小限にするために）、
ホスト・コンピュータ１３においてクライアント１６のリストを開始し（例えば
、プロパティおよび帯域幅要件がホスト・コンピュータ１３に知られていない、
未インストールのいずれかのクライアントからの接続要求をサーバ１２が拒否す
ることができるように）、クライアントＩＤをクライアント１６間に配布し（例
えば、サーバ１２からの予測されるデータ、およびそれぞれの送信スロットに関
して、クライアント１６間での混乱を防ぐために）、各クライアント１６につい
て推定される帯域幅要件のテーブルを形成する（例えば、接続がどの特定のクラ
イアント１６に対しても許可される前に、サーバ１２が帯域幅要件をオンライン
で事前に計算できるように）。

【０１１７】 任意の新しいクライアント１６をサブネット１０に導入する前に、ホスト・コ
ンピュータ１３で認識されるクライアントのリストを更新しなければならない。
これはホスト・コンピュータ１３でユーザにより直接行ってもよく、他の実施形
態では、クライアントＩＤがサーバ１２および新しいクライアント１６の両方に
提供される限り、遠隔から行ってもよい。

【０１１８】 通常の動作中に、クライアント１６が応答を中断することがありうる。不在に
なったクライアントの後のクライアント１６がチャネルを使用できないことがあ
るので、これは惨事につながりかねない。この問題を軽減するために２方向から
の解決法が実施される。第１に、クライアント１６がラインにおいて先行するク
ライアントからパケットを受信しない場合、クライアント１６はタイマを呼び出
し、チャネルを捕捉する前に所定の時間待機する。第２に、無線装置１４からの
受信信号強度指示（ＲＳＳＩ）を使用して空いているチャネルをチェックし、関
連する無線装置１４が真のパケットを認識できない（例えば深刻なチャネル状態
が原因で）場合の、間違った捕捉を回避することもできる。

【０１１９】 １つ以上のクライアントが不在になるという問題を解決するために、空いてい
るチャネル中の待機時間は事前定義される。すべてのクライアントは使用されて
いない時間を追跡し、適切な事前定義された複数の待機時間待機した後でチャネ
ルを捕捉する。Ｋ個の連続するクライアント１６が不在である場合、（Ｋ＋１）
番目のクライアント１６が、Ｋ個の事前定義された時間の後にそれを引き継ぐ。
さらにサーバ１２は応答のないクライアント１６を追跡し、応答のあるクライア
ント１６を移動して（例えばそのＣｏｎｎｅｃｔｉｏｎ Ａｇｒｅｅｍｅｎｔを
修正することにより）適切にチャネル中のギャップを埋める。

【０１２０】 先に指摘したように、サーバ１２がすでに動作した後にクライアント１６がウ
ェイクアップする場合、クライアント１６はチャネルをチェックし、それから静
止（Ｑ）スロット中で応答する必要がある。この理由のために、サーバ１２は、
クライアントがサーバ１２に適切な通信をせずにシャット・ダウンされる場合で
も、オンライン・クライアントのリストから削除する前に、すべてのオンライン
・クライアント１６を所定の時間記憶している。シャット・ダウン・コマンド・
シーケンスまたはタイム・アウトにより、クライアントがオンライン・リストか
ら消去される場合、出て行くクライアントが手放した帯域幅はそれを必要とする
クライアントに再割り当てされる。

【０１２１】 クライアント１６が接続を切断したい場合、Ｄｉｓｃｏｎｎｅｃｔ Ｒｅｑｕ
ｅｓｔがサーバ１２に送信され、クライアント１６はＤｉｓｃｏｎｎｅｃｔ Ａ
ｃｋ．を受信した後にシャット・オフする。サーバ１２は、確認通知を送信した
後にオンライン・クライアントのリストからそのクライアントを削除する。確認
通知が損失する場合、クライアント１６は別のＤｉｓｃｏｎｎｅｃｔ Ｒｅｑｕ
ｅｓｔパケットを送信し、サーバ１２はクライアント１６はすでに削除されたこ
とを記憶しているので、別のＤｉｓｃｏｎｎｅｃｔ Ａｃｋ．パケットを送信し
てクライアント１６をシャット・ダウンさせることができる。

【０１２２】 クライアントのアプリケーションがシャット・ダウンされる際、クライアント
１６は電源が入った状態のままであることがある。ただし、サーバ１２はそのア
プリケーションをシャット・ダウンさせているので、所定の長さの時間待機し、
Ｃｏｎｎｅｃｔｉｏｉｎ Ｔｅｒｍｉｎａｔｅコマンドをクライアント１６に送
信し、Ｄｉｓｃｏｎｎｅｃｔ Ａｃｋ．パケットを待機する。Ｃｏｎｎｅｃｔｉ
ｏｎ Ｔｅｒｍｉｎａｔｅコマンドに応答して、クライアント１６は電源が切れ
、サーバ１２はクライアント１６をオンライン・クライアントのリストから削除
する。ただし、クライアントの以前の確認通知が失われた場合サーバ１２は別の
Ｃｏｎｎｅｃｔｉｏｎ Ｔｅｒｍｉｎａｔｅパケットを送信することがあるので
、クライアント１６は実際に電源オフする前にしばらく待機する。

【０１２３】 上記で説明したプロトコルを実施するために、数個のネットワーク・ファクタ
を考慮しなければならない。例えば、何らかの形のエラー認識およびエラー訂正
を採用して、サブネット１０をサポートする無線リンクが雑音が多く損失の多い
性質であることによる障害に対して防御しなければならない。またネットワーク
が変化するチャネル状況（例えば雑音の増加など）に応答できるように、通信チ
ャネルを監視しなければならない。これにより上記で述べたチャネル切り替え動
作が可能になる。さらに、データの暗号化を使用して、盗聴に対して防御し、外
部者によるデータの操作および／またはサブネットの設定を防ぐことができる。
これらの事項または他の事項は下記で詳細に述べる。

【０１２４】 上記で述べたように、エラー認識および訂正を導入するために、エラー訂正コ
ーディング（ＥＣＣ）を使用することができる。一実施形態では、ＥＣＣコード
化は、リード−ソロモン・エンコーダを使用して実現される。各データ・パケッ
ト４２（ヘッダを含む）は、２３９バイトのブロックに分割され、ＥＣＣは２５
５バイトのブロックを形成するように実行される。データ・パケット４２中のバ
イト数が２３９の整数の倍数でない場合、仮想ゼロ・コード化技術を使用して、
最後のブロックが切り捨てられたＥＣＣとともに送信される。この技術では、Ｅ
ＣＣのバイトは、データはブロックを完成させるように埋め込まれたゼロである
ものとして計算されるが、埋め込みバイトは送信されない。その代わりに、受信
装置において埋め込みバイトが追加され、データはデコードされる。いくつかの
実施形態については、すべてのパケットは等しく扱われるが、他の実施形態では
、オーディオおよびコマンド・パケットは高程度のＥＣＣにより送信されるのに
対し、パケットに含まれるビデオ・データの重要性に応じてビデオ・パケットは
それとは異なる等しさで保護されることがある。

【０１２５】 チャネル状態を継続して監視できるように、各クライアント１６はサーバ１２
により送信される全てのパケットを追跡し、各パケットにタイム・スタンプを使
用していずれかのパケット損失を検出することができる。パケット損失計算の数
は、およそ１秒（あるいは他の期間）に１回、サーバ１２に自動的に中継され、
サーバ１２はこの情報を使用してチャネル状態を判断することができる。このよ
うなチャネル監視は、チャネル変更決定、および変化するエラー防御を提供する
ために有用である。チャネル変更は、現在のチャネル中の雑音／干渉が容認不能
になった時はいつでも実行することができる。増大された（または低減された）
エラー防御は、チャネル状態に応じて、より好適な帯域幅利用および頑強性を提
供するために使用される。

【０１２６】 本技術は著しいオーバヘッド（すなわち真のデータ以外の情報を転送するため
にかかる時間）の使用を回避する。例示的サブネット１０では、オーバヘッドは
さまざまな形態で存在し、無線ターン・アラウンド時間（たとえば４Ｍｂｐｓま
たは５バイトで、１０μｓｅｃまた４０ビット）、無線データ・フレーム・プリ
アンブル４４（例えばダイバーシチのない８０ビット、またはダイバーシチのあ
る１２８ビット）、無線データ・フレーム・ヘッダ（例えば１６ビットのＬｉｎ
ｋ−ＩＤ、１６ビットの長さ情報、１６ビットのＣＲＣの４８ビット）、パケッ
ト・ヘッダ１４０（例えば８ビットのＣｌｉｅｎｔＩＤ、８ビットのＴｉｍｅ
Ｓｔａｍｐ、８ビットのＳＴＰ、８ビットの長さフィールドの３２ビット）、お
よび各ビデオフレーム時間（例えば１６バイト）ごとに１つの接続要求パケット
を伝播するために、新しいクライアントについて提供され、また必要な場合には
提供されなければならないスロットＱを含む。オーバヘッドを最小限に保つため
に、サーバ１２はチャネル使用統計を継続的に監視し、それに応じてクライアン
ト１６間の帯域幅割り当てを変更する。したがってチャネルは延長した時間、不
使用の状態でいることは許されない。

【０１２７】 所定のチャネルについてのオーバヘッドは、一実施形態については下記のよう
に推定される。各無線データ・フレーム４０が単一のパケット４２を伝搬するよ
うに制限される場合、各データ・フレーム４０のオーバヘッドは１２８＋４８＋
３２＝２０８ビット＝２６バイトになる。Ｎ個のオンライン・クライアント１６
があるサブネット１０については、任意のビデオ・フィールド継続期間内に２Ｎ
のコマンド・パケットがある。これらのパケットの最大ペイロードは、１００バ
イトに制限される。この制限は、マウス、キーボード、アナログ・ジョイスティ
ック・インタフェースで予測される典型的なトラフィックを満たし、また他のコ
マンドを提供するように選択される。例えば、キーボード・インタフェースは１
分につき最大で１００ワード、すなわち１秒につきおよそ１０キーストロークを
要すると予想される。この結果０．３２バイト／フィールドとなる。しかし各キ
ーストロークは１６ビットのワードであり、２バイトのペイロードになる。オー
ディオ（４４．１Ｋサンプル／秒、ステレオ、２：１圧縮）は、ビデオ・フィー
ルド４４につきおよそ８００バイトを割り当てられる。これは１つのデータ・フ
レーム４０に適合することを意味する。言うまでもなく上記のパラメータについ
ては、特定のチャネル／サブネットに応じて適切な他の値を使用することもでき
る。

【０１２８】 上記の値を使用すると、ビデオ・フィールド４４で使用可能な総帯域幅は、４
＊１０⁶＊１６．６８３３５＊１０^-3＝６６７３３．４＝８３４１バイトとなる
。オーディオ情報には、（８００＋２６）＝各フィールド４４の８２６バイト：
コマンド情報は（１００＋２６）＊２Ｎバイト（２つのクライアント１６では、
これは６１６バイト）；無線ターン・アラウンド時間は（Ｎ＋１）＊５バイト（
２つのクライアントに関してはこれは１５バイト）でセットされ；そして静止（
Ｑ）スロットは１６バイトにセットされる。ビデオ情報には残っているいずれか
の帯域幅が割り当てられ、すなわち上記の実施形態については、ビデオ情報には
およそ８３４１−（８２６＋６１６＋１５＋１６）＝６８８０バイト（オーバヘ
ッドを含む）が割り当てられる。したがってビデオ情報を伝搬する各無線データ
・フレームは、（１０２４＋２６）＝１０５０バイトを必要とする。したがって
ビデオ情報は合計７つのパケットを占め、その７つのパケットのうち６つは満た
され１つのパケットは部分的に満たされる。したがってビデオ・フィールド４４
内のそのようなフレームの総数は、２Ｎのコマンド、１つのオーディオ、７つの
ビデオになる。２つのクライアントについては、これは１２のデータ・フレーム
になる。したがってオーバヘッドは１５＋１２＊２６＝３２７バイトのオーバヘ
ッドになる。

【０１２９】 これは１つのビデオ・フィールド継続期間で使用可能な総帯域幅（８３４１バ
イト）の３．９２％のオーバヘッドに相当する。無線プログラミングなどに伴う
いずれかの遅延が原因の余分のオーバヘッドの２５％を提供すると、これは４．
９％のオーバヘッドになる。ＥＣＣについて別に６．２７５％のオーバヘッドを
追加した後でも、本技術が含むのは総オーバヘッドの１２％未満である。

【０１３０】 上記の説明により、サーバ１２がすべての動的なネットワーク管理を実行し、
それに対してホスト・コンピュータ１３が静的なネットワーク管理を行うことが
明瞭になろう。動的ネットワーク管理は、帯域幅の割り当て、帯域幅の利用に関
するネットワーク監視（ｐｏｌｉｃｉｎｇ）（ホスト・コンピュータ１３にも報
告される）および再ネゴシエーション；オンライン・クライアントのリスト維持
；チャネル選択／変更を含む。静的ネットワーク管理は、インストールに関する
全ての詳細事項（例えばリンクＩＤ、ＰＮコードなどの決定）；クライアントＩ
Ｄの維持；チャネル・ステータスおよび変動の維持、およびＰＮコード変更の決
定（例えば両方の方向の各クライアント１６について維持されるテーブルまたは
他のリストが必要であり、それはチャネル・ステータスがサーバ１２により受信
される際は必ず更新される必要があり、エントリは例えば１週間／１カ月など長
期間にわたって累積され、チャネルの性質の累積統計に基づいて、各方向の各ク
ライアント１６について決定が行われることが好ましい）；帯域幅利用統計テー
ブルの維持、特に新しいクライアントをインストールする間には、ユーザにその
むねを通告する。

【０１３１】 以上のように、リアル・タイム・マルチメディア無線ネットワーク・プロトコ
ルについて説明した。図示された特定の実施形態を参照して説明をしたが、本発
明はそれにより制限されるべきではない。その代わり、本発明は下記の請求項に
よってのみ評価されるべきである。

【図面の簡単な説明】

【図１】 本発明の一実施形態である無線プロトコルによりサポートされる、一般化した
ネットワーク・アーキテクチャを示す図である。

【図２】 環境内での重なり合わない複数のサブネットの好ましい配布を示す図（ａ）と
サブネットが重なり合っている例示的環境を示す図（ｂ）である。

【図３】 本発明の一実施形態に従って構成されたネットワーク体系への、開放型システ
ム間相互接続（ＯＳＩ）の適合を示す図である。

【図４】 本発明の一実施形態に従ったサブネット内での、データの送信についての階層
的配列を示す図である。

【図５】 本発明の一実施形態によるサブネットに、クライアントを追加するプロセスを
示す状態図である。

【図６】 本発明の一実施形態による、サーバから見たクライアントをサブネットに挿入
するプロセスを示す状態図である。

【図７】 本発明の一実施形態による、サーバが新しいクライアントについてセッション
を開始するプロセスを示す状態図である。

【図８】 本発明の一実施形態による、サーバから見たサブネット内でのチャネルの変更
のプロセスを示す状態図である。

【図９】 本発明の一実施形態による、クライアントから見たサブネットについてのチャ
ネル変更シーケンスのプロセスを示す状態図である。

【図１０】 本発明の一実施形態によるクライアント／サーバのデータ・パケットについて
のフォーマットを示す図である。

【図１１】 本発明の一実施形態によるクライアント／サーバのデータ・パケットについて
のフォーマットをより詳細に示す図である。

【図１２】 本発明の一実施形態によるデータ・パケットについてのペイロード構造を示す
図である。

【図１３】 本発明の一実施形態によるコマンド・パケットについてのペイロード構造を示
す図である。

【図１４】 本発明の一実施形態によるコマンド・パケットについてのＣｏｎｎｅｃｔｉｏ
ｎ Ａｇｒｅｅｍｅｎｔの例示的ペイロード構造を示す図である。

【図１５】 本発明の一実施形態によるコマンド・パケットについてのＡｄｄ Ｓｕｂｃｌ
ｉｅｎｔの例示的構造を示す図である。

【図１６】 本発明の一実施形態によるデータ送信パケットのフォーマットを示す図である
。

【図１７】 本発明の一実施形態によるＣｏｎｎｅｃｔｉｏｎ Ｒｅｑｕｅｓｔコマンド・
パケットの例示的構造を示す図である。

【図１８】 本発明の一実施形態による、サブクライアントをオンラインでサブネットに挿
入するプロセスを示す状態図である。

【手続補正書】特許協力条約第３４条補正の翻訳文提出書

【提出日】平成１２年９月２６日（２０００．９．２６）

【手続補正１】

【補正対象書類名】明細書

【補正対象項目名】特許請求の範囲

【補正方法】変更

【補正の内容】

【特許請求の範囲】

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ， ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，Ｉ Ｔ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＧＷ，ＭＬ， ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，Ｋ Ｅ，ＬＳ，ＭＷ，ＳＤ，ＳＬ，ＳＺ，ＵＧ，ＺＷ)，Ｅ Ａ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ，ＴＪ ，ＴＭ)，ＡＥ，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ，ＢＡ ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，ＣＵ， ＣＺ，ＤＥ，ＤＫ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＤ，Ｇ Ｅ，ＧＨ，ＧＭ，ＨＲ，ＨＵ，ＩＤ，ＩＬ，ＩＮ，ＩＳ ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＣ，ＬＫ， ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＤ，ＭＧ，ＭＫ，Ｍ Ｎ，ＭＷ，ＭＸ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＳＬ，ＴＪ，ＴＭ， ＴＲ，ＴＴ，ＵＡ，ＵＧ，ＵＺ，ＶＮ，ＹＵ，ＺＡ，Ｚ Ｗ (72)発明者 エカムバラム，ナタラジャン アメリカ合衆国・95670・カリフォルニア 州・ランチョ コルドバ・ナンバー197・ ビークル ドライブ・2330 Ｆターム(参考） 5K033 AA09 BA04 CB06 CC01 DA01 DA17 EA02 5K067 BB21 DD24 DD34 EE02 EE12 EE71 JJ38 JJ41 【要約の続き】 をセットアップすること、および／または第２通信チャ ネルのコンピュータ・ネットワークの各構成要素のポー リングを含むことができる。

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. 【請求項２５】 通信を再開することが、第２通信チャネルへのアクセス要
    求をそれの静止時間スロットにおいて送信することを含む、請求項２３に記載の
    方法。