(57)【特許請求の範囲】
【請求項１】
複数の宛先に対してデータパケットの順序付けられた送信を行う送信デバイスにおいて、
送信手段と、
データパケット順序付け手段と、
宛先マスクビットの設定により示されている各宛先の送信阻止状態を記憶している状態テーブルと、
前記送信手段および前記データパケット順序付け手段に結合され、データパケットを解析する送信管理インターフェースとを具備しており、
前記送信管理インターフェースは、前記状態テーブルからの特定の宛先の送信阻止状態および各データパケットに対応する送信記述子の宛先マスククリアフィールドの設定を検査することにより特定の宛先をターゲットにしてデータパケットを送信するか、あるいは特定の宛先に対するデータパケットの送信を阻止するかを決定する送信デバイス。
【請求項２】
複数の宛先に対してデータパケットの順序付けられた送信を行う送信デバイスにおいて、
送信手段と、
データパケット順序付け手段と、
各宛先の送信阻止状態を記憶している状態テーブルと、
前記送信手段および前記データパケット順序付け手段に結合され、データパケットを解析する送信管理インターフェースとを具備しており、
前記送信管理インターフェースは、状態テーブルからの特定の宛先の送信阻止状態を検査することにより特定の宛先をターゲットにしてデータパケットを送信するか、あるいは特定の宛先に対するデータパケットの送信を阻止するかを決定するように構成され、
各データパケットは、
状態テーブル中の送信阻止状態に対応した固有識別子と、
状態テーブル中の特定の宛先の送信阻止状態が変更されるべきか否かを示す宛先状態変更コードとを含んでいる送信デバイス。
【請求項３】
送信管理インターフェースは、インデックスを含んでいる固有識別子によって送信阻止状態を検査する請求項２記載の送信デバイス。
【請求項４】
送信管理インターフェースは特定の宛先の送信阻止状態を変更し、データパケットの宛先状態変更コードにしたがってデータパケットを送信する請求項２記載の送信デバイス。
【請求項５】
送信管理インターフェースはデータパケットをデータパケット順序付け手段から個々に受信し、そのデータパケットを送信手段に転送するように構成されている請求項１記載の送信デバイス。
【請求項６】
データパケット順序付け手段は、
データパケットを待ち行列に入れ、必要ならば、送信管理インターフェースにしたがってデータパケットを再度待ち行列に入れるデータパケットマニプレータを含んでいる請求項１記載の送信デバイス。
【請求項７】
状態テーブルは宛先マスクビットアレイを含んでいる請求項１記載の送信デバイス。
【請求項８】
送信デバイスは無線通信ネットワーク内のアクセスポイントである請求項１記載の送信デバイス。
【請求項９】
送信デバイスは無線通信ネットワーク内のステーションである請求項１記載の送信デバイス。
【請求項１０】
無線通信ネットワークはアドホックネットワークである請求項９記載の送信デバイス。
【請求項１１】
複数の宛先に対してデータパケットの順序付けられた送信を行う送信デバイスにおいて、
送信手段と、
データパケット順序付け手段と、
宛先マスクビットの設定により示される各宛先の送信阻止状態を記憶している状態テーブルと、
前記送信手段に結合され、状態テーブルからの第１の宛先および第２の宛先の各送信阻止状態および前記第１の宛先および前記第２の宛先に対するデータパケットに対応する送信記述子の宛先マスククリアフィールドの設定にしたがって前記第１の宛先に対するデータパケットの送信を阻止する一方で前記第２の宛先に対するデータパケットの送信を可能にするように構成されている送信管理インターフェースとを具備して送信デバイス。
【請求項１２】
複数の宛先に対してデータパケットの順序付けられた送信を行う方法において、
第１の宛先をターゲットにされた１以上のデータパケットを、１以上の他の宛先をターゲットにされた１以上のデータパケットと共に待ち行列に入れ、
宛先送信阻止状態テーブルおよび宛先状態変更コードにしたがってデータパケットを送信すべきか否かを決定するステップを含んでおり、この宛先送信阻止状態テーブルは特定の宛先が送信阻止しているか否かを示し、宛先状態変更コードはデータパケット中に記憶され、特定の宛先における送信阻止が維持されるべきか否かを示している方法。
【請求項１３】
複数の宛先に対してデータパケットの順序付けられた送信を行う方法において、
１つの宛先をターゲットにしている１以上のデータパケットを、１以上の他の宛先をターゲットにしている１以上のデータパケットと共に待ち行列に入れ、
その１つの宛先をターゲットにしている第１のデータパケットの送信が失敗であった場合には、第１のデータパケットが他の宛先に対するデータパケットの待行列の後に再度入れられ、宛先マスククリアフィールドが再設定され、宛先マスクビットがクリアされ、第１のデータパケットの再送信が行われるまで、その１つの宛先に対するデータパケットのそれ以上の送信を阻止し、
１以上の他の宛先をターゲットにしている１以上の他のデータパケットの送信を許可するステップを含んでいる方法。
【請求項１４】
１以上の他の宛先をターゲットにされた１以上の他のデータパケットの後に、第１のデータパケットを再度待ち行列に入れるステップをさらに含んでいる請求項１３記載の方法。
【請求項１５】
１つの宛先をターゲットにされた他のいずれのデータパケットより先に、第１のデータパケットを再度待ち行列に入れるステップをさらに含んでいる請求項１３記載の方法。
【請求項１６】
宛先マスクビットがクリアされた後、その１つの宛先に対する第１のデータパケットの送信を阻止しないステップをさらに含んでいる請求項１３記載の方法。
【請求項１７】
第１のデータパケットが少なくとも１つの他の宛先をターゲットにしている少なくとも１つの他のデータパケットの後の待ち行列に再度入れられ、宛先マスクビットがクリアされた後、その１つの宛先に対する第１のデータパケットの送信を阻止しないステップをさらに含んでいる請求項１４記載の方法。
【請求項１８】
第１のデータパケットの再送信が成功せず、送信の再試行が行われないとき、第２のデータパケットを、その１つの宛先に送信される次のデータパケットとして指定し、
指定された第２のデータパケットに応答して、その１つの宛先へのデータパケットの送信を阻止しないステップをさらに含んでいる請求項１３記載の方法。
【請求項１９】
第２のデータパケットは、後での処理のために記憶されている第１のデータパケットである請求項１８記載の方法。
【請求項２０】
第２のデータパケットは、廃棄された第１のデータパケットに後続していたデータパケットである請求項１８記載の方法。
【請求項２１】
第２のデータパケットは、第１のデータパケットの修正されたバージョンである請求項１８記載の方法。
【請求項２２】
複数の宛先に対してデータパケットの順序付けられた送信を行う方法において、
最初に１つの宛先をターゲットにしている１以上のデータパケットを１以上の他の宛先をターゲットにしている１以上のデータパケットと共に含んでいる送信待ち行列を設けて、更新し、
その１つの宛先をターゲットにしている第１のデータパケットの送信が失敗であった場合には、第１のデータパケットが再度待行列に入れられ、宛先マスククリアフィールドが再設定され、宛先マスクビットがクリアされ、第１のデータパケットが再送信されるまで、その１つの宛先に対するデータパケットのそれ以上の送信を阻止し、
１以上の他の宛先をターゲットにしている１以上の他のデータパケットの送信を可能にするステップを含んでいる方法。
【請求項２３】
その１つの宛先をターゲットにされた第１のデータパケットおよび他のいずれかのデータパケットを再度送信待ち行列中に位置させるステップをさらに含んでいる請求項２２記載の方法。
【請求項２４】
その１つの宛先をターゲットにされた第１のデータパケットおよび他のいずれのデータパケットを再度送信待ち行列中に位置させるステップをさらに含み、第１のデータパケットはその１つの宛先をターゲットにされた他のいずれかのデータパケットの前に配置される請求項２２記載の方法。
【請求項２５】
第１のデータパケットが再度送信待ち行列中に位置されたことに応答して、その１つの宛先に対する第１のデータパケットの送信を阻止しないステップをさらに含んでいる請求項２２記載の方法。
【請求項２６】
その１つの宛先をターゲットにされた第１のデータパケットおよび他のいずれかのデータパケットの相対的な順序を送信待ち行列内で維持しながら、その１つの宛先をターゲットにされた第１および他のいずれかのデータパケットを再度送信待ち行列中に位置させるステップをさらに含んでいる請求項２２記載の方法。
【請求項２７】
その１つの宛先に対する第１のデータパケットの再送信を成功するまで何回も反復して行うステップをさらに含んでいる請求項２２記載の方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は通信システムおよびネットワークに関し、とくに無線伝送および通信システムにおける逐次パケット送信およびパケットフィルタ処理に関する。
【０００２】
【従来の技術】
通信システムにおいて、データの正しい順序での送信を保証すること、すなわち、発信元ノードから送信されたデータ要素がそのデータ要素が送られた同じ順序で宛先ノードにおいて受信されることを確実にすることが望ましいことが多い。データの送信を待ち行列に入れるメカニズムをサポートするだけでなく、操作および再度待ち行列に入れることにより失敗した送信の再試行もまたサポートする通信システムにおいては、正しい順序での送信は複雑さを増加させるものである。
【０００３】
米国電気電子学会（ＩＥＥＥ）は無線構内ネットワーク（ＬＡＮ）規格８０２．１１を制定している。このＩＥＥＥ８０２．１１規格（ＩＥＥＥ８０２．１１）では無線ＬＡＮに対するメディアアクセス制御（ＭＡＣ）および物理層（ＰＨＹ）仕様が概説されている。ＩＥＥＥ８０２．１１の仕様は無線ＬＡＮにおけるデータの送信を扱っている。ＩＥＥＥ８０２．１１仕様では、データパケットのような重複したデータ要素が所定の宛先ノードで受信されたかどうかを決定するために簡単なメカニズムが使用されるように正しい順序での送信が容器勇される。逐次パケット送信は、ＩＥＥＥ８０２．１１アクセスポイントおよびステーションの重要な特徴である。ＩＥＥＥ８０２．１１仕様は、特定の受信機アドレスに対して意図されたデータパケットだけが一時に１つだけ特定のソースアドレスから待ち行列に入れられることができることを示している。すなわち、特定の宛先に対して一時に２以上のデータパケットを待ち行列に入れないことにより、正しい順序での送信が行われなければならない。これは、データパケットの送信に失敗した場合に誤った順序での送信を防止する。
【０００４】
図１は、一連の宛先Ａ，ＢおよびＣへの送信を予定されたデータパケット102-114の例示的な待ち行列100を示す概略図である。ＩＥＥＥ８０２．１１の制限の背後にある論法の一例として、宛先Ａを予定されたデータパケット102は、宛先Ｂをターゲットにされたデータパケット104,106,114,116、および宛先Ｃをターゲットにされたデータパケット112,116と混合されて待ち行列を形成すると仮定する。さらに、ＩＥＥＥ８０２．１１の制限に反して、宛先Ａに対する２以上のデータパケット102,108,110,116が別の宛先ＢおよびＣに対するデータパケットの間に位置されていると仮定する。宛先Ａに対する多数のデータが待ち行列に入れられた場合、第１のデータパケット102の送信の失敗が発生し、かつデータパケットの送信が後続しているならば、宛先Ａに対するデータパケットの間違った順序での送信が発生する可能性がある。当然ながら、送信が失敗したデータパケットが操作されて再度送信されることができるように、データパケットの送信は送信の失敗後に停止されてもよい。しかしながら、その例によると、宛先Ａへのデータ送信を停止することにより別の宛先ＢおよびＣへの送信もまた停止するため、このような実施は望ましくない。宛先Ａに対する第１のデータパケットの送信が失敗した場合でも、別の宛先に対する、この場合には宛先ＢおよびＣに対するデータパケットの送信を続行することが望ましい。
【０００５】
このＩＥＥＥ８０２．１１仕様の制限、すなわち、待ち行列における宛先当たり１つのデータパケットを満足させることは、システムの性能に対して深刻な影響を与える。たとえば、送信機がデータパケットの送信の成功を認識し、その宛先に対する次のデータパケットを待ち行列に入れるのに要する時間は、送信待ち行列全体を使い切るのに要する時間をしばしば越えるであろう。
【０００６】
図２を参照とすると、アクセスポイントまたはステーションのような典型的なＩＥＥＥ８０２．１１追従デバイス200は、送信機210、メモリ220、局部中央処理装置（ＣＰＵ）230、およびバスインターフェース装置（ＢＩＵ）240を含んでいる。局部ＣＰＵ230はデータパケットをＢＩＵ240からメモリ220に転送する。さらに、ＣＰＵ230は、データパケットが送信される順序をそのＣＰＵ230が制御することができるように送信機210に対するデータパケットの待ち行列を形成する。局部ＣＰＵ230は典型的に低いレイテンシーを有しており、そのことは、性能に対する深刻な影響を回避するために前のパケットがなくなってしまうとＣＰＵ230が特定の宛先に対する次のパケットだけを待ち行列に入れることができることを意味する。ＣＰＵ230が送信のために待ち行列に入れたデータパケットの全てを送信機210が盲目的に送信することを想像されたい。すると、ＣＰＵ230が同じ宛先に対する２以上のパケットを待ち行列に入れ、その宛先に対する第１のパケットの送信が失敗した場合、第１のパケットの送信が失敗したことをデバイス200が通知されることができる前に、送信機はその宛先に第２のパケットを送信する。送信の失敗が発生した場合、およびそれに続いて第２のパケットの送信が成功した場合、宛先ノードは必然的に間違った順序で２つのパケットを受信し、それによってＩＥＥＥ８０２．１１の正しい順序での送信要求を侵害する。
【０００７】
【発明が解決しようとする課題】
したがって、システム性能を犠牲にすることなく同じ宛先に対する正しい順序でのパケット送信を維持するシステムを構成することが望ましい。
【０００８】
【課題を解決するための手段】
本発明の第１の特徴において、本発明は、複数の宛先に対するデータパケットの順序付けられた送信を行う送信デバイスを提供する。その送信デバイスには、送信機と、データパケット順序付け装置と、状態テーブルと、ならびに送信機およびデータパケット順序付け装置に結合された送信管理インターフェースとが含まれている。状態テーブルは、各宛先の送信阻止状態を記憶する。送信管理インターフェースはデータパケットを解析し、状態テーブルからの特定の宛先の送信阻止状態を検査することにより特定の宛先をターゲットにされたデータパケットを送信するか、あるいは特定の宛先に対するデータパケットの送信を阻止するかを決定する。
【０００９】
本発明の第２の特徴において、本発明の好ましい実施形態にしたがって複数の宛先に対するデータパケットの順序付けられた送信を行う送信デバイスが提供される。送信デバイスには、送信機と、データパケット順序付け装置と、状態テーブルと、ならびに送信機に結合された送信管理インターフェースとが含まれている。状態テーブルは各宛先の送信阻止状態を記憶する。送信管理インターフェースは状態テーブルからの第１の宛先および第２の宛先の各送信阻止状態にしたがって第１の宛先へのデータパケットの送信を阻止し、一方第２の宛先にデータパケットを送信することを可能にする。
【００１０】
本発明の第３の特徴において、本発明の好ましい実施形態にしたがって複数の宛先に対してデータパケットの順序付けられた送信を行う方法が提供される。第１の宛先をターゲットにされた１以上のデータパケットは、１以上の他の宛先をターゲットにされた１以上のデータパケットと共に待ち行列に入れられる。宛先送信阻止状態テーブルおよび宛先状態変更コードにしたがってデータパケットを送信するか否かが決定される。宛先送信阻止状態テーブルは、特定の宛先が送信阻止をしているかどうかを示す。宛先状態変更コードがデータパケット中に記憶される。宛先状態変更コードは、特定の宛先において送信阻止が維持されるかどうかを示す。
【００１１】
本発明の第４の特徴において、本発明の好ましい実施形態にしたがって複数の宛先に対してデータパケットの順序付けられた送信を行う別の方法が提供される。第１の宛先をターゲットにされた１以上のデータパケットは、１以上の他の宛先をターゲットにされた１以上のデータパケットと共に待ち行列に入れられる。ある宛先をターゲットにされた第１のデータパケットの送信が失敗した場合、その宛先に対するデータパケットのそれ以上の送信が阻止される。１以上の他の宛先をターゲットにされた１以上の他のデータパケットの送信は可能にされる。
【００１２】
本発明の第５の特徴によれば、複数の宛先に対するデータパケットの順序付けられた送信を行うさらに別の方法が提供される。送信待ち行列が設けられ、更新される。送信待ち行列は最初に、１以上の他の宛先をターゲットにされた１以上のデータパケットと共に１つの宛先をターゲットにされた１以上のデータパケットを含んでいる。ある宛先をターゲットにされた第１のデータパケットの送信が失敗した場合、その宛先に対するデータパケットのそれ以上の送信は阻止される。１以上の他の宛先をターゲットにされた１以上の他のデータパケットの送信は可能にされる。
【００１３】
【発明の実施の形態】
本発明およびその他の特徴ならびに利点は、以下の詳細な説明および添付図面から明らかになるであろう。
本発明の好ましい実施形態は、宛先ノードの特定のセットへの送信をダイナミックに阻止する一方で、阻止されたノードへの送信を再開することが安全なものとなるまで他のノードへの送信が続行することを可能にし続けるシステムおよび方法を提供することにより、同じ宛先に対する多数のデータパケットが待ち行列に入れられることを可能にしながら、ＩＥＥＥ８０２．１１規格の正しい順序での送信要求に関する問題を解決する。
【００１４】
以下、本発明の好ましい実施形態の例として示されている添付図面を参照として本発明を詳細に説明する。
図３は、ここに記載されている本発明の好ましい実施形態を含むことのできる第１の例示的な無線ネットワーク通信システム300の構造の概略図である。このシステム300は、複数のクライアントデバイス、すなわちステーション（ＳＴＡ）ＳＴＡ１ 310，ＳＴＡ２ 312，ＳＴＡ３ 314乃至ＳＴＡＭ 316と、アクセスポイント（ＡＰ）320と、ＡＰ320に接続された、たとえばイーサネットＬＡＮ等の有線ネットワーク318とを含んでいる。ＡＰ320は、ステーション310・・・316の無線ネットワークを、この場合はイーサネットＬＡＮである有線ネットワーク318とインターフェースするように機能するデバイスである。図３に示されているように、多数のステーション310・・・316は同じＡＰ320を介して有線ネットワークに接続されることができる。システム300のような無線通信システムは移動性を可能にし、したがって通常の有線ネットワークとは異なり、ステーション310乃至316のようなユーザまたはステーションは動き回ることができるが、それでも有線ネットワークに接続されたままである。受信機アクセスポイントまたはステーションは、受取った全ての各指示データパケットに対して受領通知を送信機ステーションまたはアクセスポイントに返信することが好ましい。指示データパケットとは、いくつかの宛先にマルチキャストされたデータパケットではなく、特定の宛先に直接送信され、したがってそのパケットを固有に受信したその宛先からの受領通知を必要とするデータパケットのことである。本発明の好ましい実施形態において、送信の失敗は、送信機ステーションまたはアクセスポイントが受信機ステーションまたはアクセスポイントからの指示データパケットを受信したという受領通知を受信しないときに発生する。ユーザまたはステーションがＡＰ320のようなアクセスポイントから物理的に遠ざかるように移動するにつれて、アクセスポイントとの間の信号は弱くなり、データパケットは雑音のためにさらに失われる可能性が高くなる。データパケットの送信が失敗した場合、ステーションまたはアクセスポイントはそのデータパケットを再送信することができる。そのデータパケットが正しく受信される確率を高くするために、ステーションまたはアクセスポイントは低いデータレートでそのデータパケットを再送信する。そのデータパケットがアクセスポイントからステーションに（あるいはステーションからアクセスポイントに）再送信された場合、ＩＥＥＥ８０２．１１の正しい順序での送信要求を満足させるように同じ宛先に送信される他のいずれのデータパケットより先に再送信されなければならない。
【００１５】
図４は、ここに記載されている本発明の好ましい実施形態を含むことのできる第２の例示的な無線ネットワーク通信システム400の構造を示す概略図である。システム400は複数のクライアントデバイス、すなわちステーション（ＳＴＡ）ＳＴＡ１ 310，ＳＴＡ２ 312，ＳＴＡ３ 314乃至ＳＴＡＭ 316を含んでいる。この例示的なシステム400と図３のシステム300を対照させると、システム400にはステーション310・・・316しかなく、アクセスポイントは存在しない。無線通信技術で知られているように、この構造は、アドホック（ad hoc）ネットワークである。この構造において、ステーション310・・・316のようなステーションはお互いに通信することのみ可能にされている。ステーション間の物理的距離が増加するにしたがって、ステーション間における送信が失敗する確率が高くなる。システム300の場合のように、送信の失敗に続いて、データパケットがシステム400の１つのステーションから別の宛先ステーションに再送信された場合、ＩＥＥＥ８０２．１１の正しい順序での送信要求を満足させるように、同じ宛先ステーションに送信される他のいずれのデータパケットより先にそのデータパケットが再送信されなければならない。
【００１６】
図３および図４の例示的な無線通信システム300および400は共に、ここに記載されている本発明の好ましい方法およびシステムの特徴を使用することが好ましい。以下、例示的なシステム300および400を参照としてこの方法およびシステムを説明する。無線システム300および400のステーションのような任意のステーションまたはアクセスポイントは発信元送信機または宛先受信機のポジションを取ることができる。たとえば、図３のシステム300のアクセスポイントＡＰ320は、ここに記載されている本発明の好ましい実施形態にしたがってデータパケットを宛先ノードステーションＳＴＡ１ 310、ＳＴＡ２ 312およびＳＴＡ３ 314に送信する発信元送信機として動作することができる。同様に、図４のシステム400の、たとえばステーションＳＴＡ２ 312は、ここに記載されている本発明の好ましい実施形態にしたがってデータパケットを宛先ノードステーションＳＴＡ１ 310、ＳＴＡ２ 312およびＳＴＡＭ 316に送信する発信元送信機として動作することができる。
【００１７】
図５は、本発明の好ましい実施形態による、アクセスポイントまたはステーションのような例示的な送信デバイス500を示すブロック図である。このデバイス500には、送信機510と、メモリ520と、バスインターフェース装置（ＢＩＵ）540と、結合されたハードウェア/ソフトウェア装置（ＨＳＵ）530が含まれている。ＨＳＵ530は、ＢＩＵ540からメモリ520中にデータパケットを転送する。さらに、ＨＳＵ530は、データパケットが送信される順序を制御することができるように送信機510に対するデータパケットを待ち行列に入れる。ＨＳＵ530は、図２に示されている通常のＩＥＥＥ８０２．１１デバイス200内の局部ＣＰＵ230に取って代わる。このＨＳＵ530は通常の局部ＣＰＵ230の機能および特徴のある部分をハードウェアとソフトウェアとの間で分割する。ＨＳＵ530は、デバイス500上の主ホストプロセッサの機能を含んでいることが好ましい。ＨＳＵ530のソフトウェア部分は、図５のデバイス500上で実行するデバイスドライバを含んでいることが好ましい。ＨＳＵ530のドライバは、データパケットの処理のための送信記述を生成することが好ましい。各データパケットは、１以上の対応した送信記述子を有していることが好ましい。送信記述子は、特定のデータパケットがネットワーク中に送信されるように、送信されるべきそのデータパケットの全てまたは一部を記述する。データパケット送信記述子の動作の記述および説明はこの明細書の技術的範囲外であり、ここに記載されている中心概念を逸脱しないために示さない。
【００１８】
送信阻止メカニズムがないと、ＨＳＵ530は間違った順序でパケットを送信しようとする可能性がある。パケットフィルタ処理メカニズムは、これを防止するためにフィルタ処理が必要とされる可能性のある状況を検出して処理するために設けられている。ＨＳＵ530のハードウェア部分は、このデータパケットフィルタ処理メカニズムを提供することが好ましい。
【００１９】
送信デバイス500がいくつかの宛先ノードに送信されるべき多数のデータパケットを有している場合、そのデータパケットが到着したときにそれらを送信デバイス500の送信待ち行列に追加することが最も効率的である。図６Ａは、たとえば図３または４のＳＴＡ１ 310，ＳＴＡ２ 312およびＳＴＡ３ 314のような宛先への送信を予定されたデータパケットの例示的な待ち行列600を示す概略図である。ＳＴＡ１に対する第１のパケットＳＴＡ１−１の送信が失敗した場合、再送信に関してデータパケットを再度スケジュール化することが望ましいかもしれないが、データの順序付けられた送信を保持するために、デバイス500はＳＴＡ１−１データパケットの前にＳＴＡ１−２を送信してはならない。その代わり、この場合においては、送信待ち行列600を図６Ｂの送信待ち行列700となるようにすることが望ましい。もちろん、図６Ａおよび６Ｂに示されているデータパケットの順序および宛先は説明のための単なる一例に過ぎず、データパケットの別の順序および宛先が使用されることができる。
【００２０】
ＩＥＥＥ８０２．１１の正しい順序での／順序付けられた送信要求を満足させることにより、ＨＳＵ530が同じ宛先に対する多数のデータパケットを待ち行列に入れることが可能となり、そのＨＳＵ530は、宛先ノードの特定のセットに対する送信をダイナミックに阻止しながら、その一方で、その阻止された宛先ノードへの送信を再開することが安全であることをＨＳＵ530が示すまで、別の宛先ノードへの送信が続行することを可能にし続けるメカニズムを提供する。好ましい実施形態において、ＨＳＵ530のソフトウェアデバイスドライバはデータパケットを待ち行列に入れ、ＨＳＵ530のハードウェア部分は、そのデータパケットの送信が可能かどうかを決定するためにデータパケットを解析し、ＨＳＵ530のデバイスドライバは、送信が阻止された場合には、再び送信が可能となるときを示す。
【００２１】
これは、その宛先に対するデータパケット送信が前に失敗したかどうかに関する状態を各宛先アドレスについて維持することによって行われる。失敗したデータパケット送信の後の、その宛先に対する後続のデータパケットは、送信せよという明示的な命令が与えられた場合にのみ送信される。各データパケットは、その宛先を固有に表す、たとえばインデックス等の、固有の識別子を含む対応した１以上の送信記述子を有していることが好ましい。各インデックスに対して宛先マスクビットのような送信阻止ビットが維持されることが好ましい。宛先マスクビットは宛先マスクテーブルのような宛先送信阻止状態テーブルの中のエントリとして記憶されることが好ましいが、別の実施形態では、宛先マスクビットは、たとえばそのデータパケットに対応した送信記述子内に配置されたビットフィールドであってもよいことを認識すべきである。データパケットを特定の宛先に送信する前に、宛先マスクビットはデバイス500によりチェックされ、そのビットがクリアである場合にのみデータパケットが送信される。データパケット送信が失敗した場合、宛先マスクビットが設定され、パケットはそれ以上その宛先に送信されない。宛先マスクビットをクリアしてデータパケットを送信するようにハードウェアに命令する宛先マスククリアフィールドのような別のフィールドを送信記述子内に含ませることによって、宛先マスクビットをクリアするメカニズムのような宛先状態変更コードが設けられることが好ましい。
【００２２】
とくに、宛先マスクビットアレイ550のような宛先送信阻止状態テーブルは、デバイス500のＨＳＵ530のハードウェア部分中のチップ上アレイとして記憶されることが好ましい。もちろん、宛先マスクビットアレイは、デバイス500上のどこか他の場所に記憶されてもよい。アレイ550は、アドレス状態テーブルまたは送信阻止状態テーブルとして機能する。すなわち、テーブル中にエントリとして記憶されたビット値は、各宛先またはその宛先を識別する各アドレスに対して、その特定の宛先へのデータパケット送信が阻止されるべきか否かを示すことが好ましい。宛先マスクビットは、そのビットが設定された場合、すなわち１に等しい場合には送信阻止を示し、一方宛先マスクビットがクリアである場合、すなわち０に等しい場合には送信が可能にされることが好ましい。状態テーブル中の宛先マスクビットはゼロに初期化されることが好ましい。本発明の好ましい実施形態において、アレイ550はＭ個のエントリを記憶し、このＭは、デバイス500がデータパケットを送信することのできる宛先ノードの数に対応する。１実施形態において、Ｍ＝２6＝６４である。もちろん、この値は一例であり、Ｍは別の値をとってもよい。送信デバイス500から見ると、Ｍ個の宛先ノード１，２，・・・，Ｍが存在している場合、個々の宛先ノードはいずれもＮ番目の宛先ノードまたは宛先ノードＮと呼ばれる。たとえば、図３の無線通信システムでは、アクセスポイントＡＰ320を送信デバイス500とし、ステーション310，312，314，・・・，316をＭ個の宛先ノードまたはステーションとする。したがって、ＡＰ320からステーションＳＴＡ２ 312に送信されたデータパケットは、宛先マスクビットＮで与えられることが好ましい宛先ノードＮに送信されたデータパケットであり、ここでＮ＝２である。以下の説明において、宛先ノードＮに対する宛先マスクビットを DestMaskBitN と呼び、宛先ノードＮに対する宛先マスククリアフィールドを ClearDestMaskN と呼ぶ。
【００２３】
以下、図７を参照として送信デバイス500の動作をさらに詳細に説明する。図７は、本発明の好ましい実施形態による、送信デバイス500に関する第１の例示的な送信阻止決定構造800を示すフロー図である。この決定構造800は基本的な送信状態またはデバイス500に対する送信しない状態をカバーしている。送信デバイス500のＨＳＵ530のソフトウェアデバイスドライバは、複数の、好ましくはＭ個の宛先に送付するためにデータパケットの待ち行列を形成することが好ましい。待ち行列の中の第１のデータパケットは宛先ノードＮにアドレスされる。ステップ802において、デバイス500は、宛先ノードＮに対する宛先マスクビットがクリアであるか、あるいは設定されているかを決定する。すなわち、DestMaskBitNは１に等しいか否かが決定される。宛先マスクビットDestMaskBitNがクリアである場合、すなわち１に等しくない場合、処理はステップ804に進み、データパケットが宛先ノードＮに送信される。宛先マスクビットが設定されている（DestMaskBitN＝１）場合、処理はステップ806に進む。ステップ806において、デバイス500は、宛先マスクビットがクリアされるべきかどうかを決定する。データパケットに対応した送信記述子中に配置されたフィールド ClearDestMaskN は、宛先マスクビットがクリアされるべきか否かを示す。ClearDestMaskN がクリアである場合、すなわち１に等しくない場合、マスクビットはクリアされてはならず、処理はステップ808に進む。ステップ808において、宛先マスクビット（DestMaskBitN＝１）によって示されているように、宛先ノードＮに対する送信が阻止され、ビットをクリアせよという命令がない（ClearDestMaskN＝０）ので、デバイス500はデータパケットを宛先ノードＮに送信しない。ステップ806に戻って、ClearDestMaskN が設定されている場合、すなわち１に等しい場合マスクビットはクリアされなければならず、処理はステップ810に進む。ステップ810において、宛先ノードＮに対する宛先マスクビットはクリアされるため（DestMaskBitN＝０）、ステップ804においてデータパケットが宛先ノードＮに送信される。
【００２４】
［図７による例］
図６Ａおよび６Ｂの例示的な待ち行列600および700を図７に適応すると、ステップ802において送信デバイス500はデータパケットＳＴＡ１−１の処理を試みるときに宛先マスクビット DestMaskBit1 （Ｎ＝１）を検査する。デバイス500は DestMaskBit1がたとえばクリアであることを確認し、デバイス500はステップ804においてデータパケットＳＴＡ１−１の送信を試みる。本発明の好ましい実施形態において、デバイス500が宛先にデータパケットの送信した後、それに続いてその宛先から受領通知を受信しなかった場合、そのデータパケットの送信は失敗した送信である。送信が失敗したと仮定すると、デバイス500は宛先マスクビットを設定する（DestMaskBitN＝１）（示されていない）。デバイス500は、データパケットＳＴＡ３−２の後にデータパケットＳＴＡ１−１を再度待ち行列に入れ、その一方でデータパケットＳＴＡ１−１に対して ClearDestMask1 （Ｎ＝１）を設定する。データパケットＳＴＡ１−１は、データパケットＳＴＡ３−２後に待ち行列に入れられることが好ましい。これは、データパケットＳＴＡ３−２がこの例のはじめの例示的な待ち行列600の最後のパケットだからである。ある宛先に対するデータパケットは待ち行列内におけるそれらの順序にしたがって送信されることが好ましく、１つの宛先に対する送信は、別の宛先に対する送信が失敗したデータパケットが再度待ち行列に入れられているあいだ遅延されないことが好ましい。次に、送信デバイス500はＳＴＡ２−１の処理を試みる。デバイス500はステップ802においてDestMaskBit2 （Ｎ＝２）を検査する。デバイス500は DestMaskBit2 がたとえばクリアであることを確認し、デバイス500はステップ804においてデータパケットＳＴＡ２−１の送信を試みる。送信が成功したと仮定すると、デバイス500はデータパケットの待ち行列を進行させてデータパケットＳＴＡ２−２を処理し、送信に成功すると、その後この例によるとデータパケットＳＴＡ３−１を処理する。送信デバイス500は次に待ち行列600中のデータパケットＳＴＡ１−２の処理を試み、デバイス500はステップ802においてDestMaskBit1 （Ｎ＝１）を検査する。デバイス500は、データパケットＳＴＡ１−１の送信の失敗後に DestMaskBit1 が設定されたことを確認し、ＳＴＡ１−２の処理はステップ806に進む。データパケットＳＴＡ１−２に対して ClearDestMask1 はクリアであり、処理はステップ808に進み、ＳＴＡ１−２は送信されない。データパケットＳＴＡ１−２は変更されずに再度待ち行列に入れられる。これは、デバイス500がＳＴＡ１−１の後にデータパケットを送信しようと試みなかったためである。次に、デバイス500はデータパケットの待ち行列の処理を進めて、この例によると、データパケットＳＴＡ３−２を処理し、それは送信に成功する。デバイス500により処理されるべき待ち行列上の次のデータパケットは、はじめに送信が失敗したデータパケットＳＴＡ１−１である。宛先マスクビット DestMaskBit1 は設定されたままである（ステップ802）が、データパケットＳＴＡ１−１に対して ClearDestMask1 が設定されている（ステップ806）ため、処理はステップ810に進む。宛先マスクビットはクリアされ（DestMaskBit1＝０）、データパケットＳＴＡ１−１が送信される。データパケットＳＴＡ１−１が正しく送信された場合、データパ���ットＳＴＡ１−２もまた送信される。これは、 DestMaskBit1 がクリアだからである。このようにして、図６Ｂの送信待ち行列700中に示されている所望の順序が達成される。
【００２５】
以下、図８を参照として送信デバイス500の拡張された動作をさらに詳細に説明する。図８は、本発明の好ましい実施形態による、送信デバイス500に関する第２の例示的な送信阻止決定構造900を示すフロー図である。この決定構造900は図７の決定構造800のものに類似したステップを含んでいるが、この実施形態によるデバイス500のさらに拡張された動作を示すために好ましいさらに詳細な処理ステップを含んでいる。送信のために待ち行列に入れられる全ての各データパケットは、決定構造900にしたがってパケットを処理するときにＨＳＵ530により使用される対応した送信記述子の中にフィールドを含んでいる。この例示的な実施形態において、特定の宛先ノードにそれぞれ対応している宛先マスクビットが状態テーブル中に記憶される。総称宛先マスクビットは DestMaskBitN と呼ばれ、宛先ノードＮに対応する。DestMaskBitN は宛先ノードＮをターゲットにされた全てのデータパケットに全体的に適用される。宛先ノードＮをターゲットにした総称データパケットに対応した送信記述子は、TableIndexNフィールドを含んでいることが好ましい。このTableIndexNフィールドは、宛先マスクビット状態テーブル中においてたとえばインデックス等の固有識別子を指定して特定の宛先マスクビットDestMaskBitNをアドレス指定するために使用される固有識別子の一例である。総称データパケットに対応した送信記述子はさらに IndexNValid フィールドを含んでいることが好ましい。IndexNValid フィールドは、TableIndexNフィールドの内容が有効かどうかを特定し、したがって状態テーブル中に適切にインデックスを付けるために使用されることができる。総称データパケットに対応した送信記述子はさらに ClearDestMaskN フィールドを含んでいることが好ましい。ClearDestMaskN フィールドはビット値から構成されていることが好ましく、それが設定された場合には、状態テーブル中の特定の宛先マスクビット DestMaskBitNの値をクリアするようにＨＳＵ530のハードウェアに命令する。送信記述子フィールド IndexNValid 、TableIndexN および ClearDestMaskN は、それらが含まれている特定のデータパケットだけに適用されることが好ましい。すなわち、同じ宛先ノードＮをターゲットにされて待ち行列に入れられた２つのデータパケットは、異なった IndexNValid 、TableIndexN および ClearDestMaskNフィールド値を有している可能性があるが、しかしその同じ DestMaskBitN はいずれの所定の時点でもその両データパケットに適用可能である。
【００２６】
送信デバイス500のＨＳＵ530のソフトウェアデバイスドライバは、Ｍ個の宛先であることが好ましい複数の宛先に送信するためにデータパケットを待ち行列に入れる。待ち行列の中の第１のデータパケットは、宛先ノードＮにアドレス指定される。図８を参照とすると、ステップ902においてＨＳＵ530のハードウェアがたとえばビット値等の IndexNValid を調べて、 IndexNValid フィールドがクリアであるかどうかを決定する。すなわち、“IndexNValid フィールドはゼロに等しいか” が決定される。IndexNValid フィールドがクリアである場合、すなわち１に等しくない場合、TableIndexN において特定されたインデックスは無効であり、たとえば送信阻止がエネーブルされない。この場合、処理はステップ908に進み、ＨＳＵ530のハードウェアは宛先ノードＮに対するデータパケットの送信を可能にする。IndexNValid フィールドが設定された場合、TableIndexN フィールド値は有効であり、処理はステップ904に進む。このステップ904において、ＨＳＵ530のハードウェアは TableIndexN フィールドを検査する。ＨＳＵ530は TableIndexN フィールドにおいて特定されたインデックスを使用して状態テーブル中にインデックスを付け、Ｍ個の宛先マスクビットに対応した宛先マスクビット DestMaskBitN を、ＨＳＵ530のハードウェア中に記憶されていることが好ましい状態テーブルから選択する。
【００２７】
ＨＳＵ530は宛先マスクビット DestMaskBitN を使用して、宛先ノードＮに対する送信が阻止されるか、あるいは可能にされるかを決定する（IndexNValid フィールドが設定されており、DestMaskBitNが有効であるため）。ステップ906において、ＨＳＵ530のハードウェアは宛先マスクビット DestMaskBitN を検査し、宛先ノードＮに対する宛先マスクビットがクリアである、すなわち設定されているかどうかを決定する。すなわち、“DestMaskBitNは１に等しいか” が決定される。
【００２８】
ステップ906において選択された宛先マスクビットがクリアである（DestMaskBitN＝０）場合、処理はステップ908に進み、このステップにおいて、ＨＳＵ530のハードウェアはデータパケットが宛先ノードＮに送信されることを可能にする。
【００２９】
しかしながら、ステップ906において宛先マスクビットが設定された場合（DestMaskBitN＝１）、処理はステップ910に進む。ステップ910において、ＨＳＵ530のハードウェアはそのデータパケットに対応した送信記述子の中の ClearDestMaskN フィールドを検査し、その宛先マスクビットがクリアされるべきか否かを決定する。
【００３０】
ステップ910において ClearDestMaskN フィールドがクリアである（ClearDestMaskN＝０）場合、その宛先マスクビットはクリアされてはならず、処理はステップ912に進む。ステップ912においてＨＳＵ530のハードウェアはデータパケットを宛先ノードＮに送信しない。それは、宛先マスクビット（DestMaskBitN＝１）によって示されているように、宛先ノードＮに対する送信が阻止され、ビットをクリアせよという命令がない（ClearDestMaskN＝０）ためである。ＨＳＵ530のハードウェアは宛先マスクビットを１に設定されたままにしておく。随意に、ＨＳＵ530のソフトウェアデバイスドライバは、ＨＳＵ530のソフトウェアがそのデータパケットを再度待ち行列に入れるときに ClearDestMaskN が確実にクリアであるようにする。
【００３１】
ステップ910に戻ると、ClearDestMaskN が設定された（ClearDestMaskN＝１）場合、そのマスクビットはクリアされなければならず、処理はステップ914に進む。ステップ914において、ＨＳＵ530のハードウェアは宛先ノードＮに対する宛先マスクビットをクリアし（DestMaskBitN＝０）、ステップ908において宛先ノードＮに対するデータパケットの送信を許可する。
【００３２】
ステップ916において、ＨＳＵ530は、宛先ノードＮに対するデータパケットの送信が成功したか否かを決定する。そのデータパケットの送信が失敗したとＨＳＵ530により決定された場合、処理はステップ920に進み、このステップにおいてＨＳＵ530のハードウェアは対応した宛先マスクビットを１に設定する（DestMaskBitN＝１）。これは、ＨＳＵ530のソフトウェアドライバが送信に失敗したデータパケットをＨＳＵ530のハードウェアによる処理のために再度待ち行列に入れてしまうまで、その同じ宛先ノードＮに対してその後データパケットが送信されないようにする。
【００３３】
ステップ922に進むと、ＨＳＵ530のソフトウェアデバイスドライバは、送信に失敗したデータパケットの送信を再試行するか否かを決定する。データパケットが再送信されることになった場合、ステップ924においてＨＳＵ530のソフトウェアデバイスドライバは ClearDestMaskN を設定する（ClearDestMaskN＝１）。ＨＳＵ530のソフトウェアデバイスドライバは、そのデータパケットをその宛先ノードＮに対する他のいずれのデータパケットより先に再度待ち行列に入れることが好ましい。
【００３４】
データパケットが再送信されない場合には、ステップ918においてＨＳＵ530のソフトウェアデバイスドライバは ClearDestMaskN ビットをクリアする（ClearDestMaskN＝０）。その後、ＨＳＵ530のソフトウェアデバイスドライバは、そのデータパケットを廃棄するか、そのデータパケットに関する操作を行うか、あるいは、たとえば、そのデータパケットを後で処理するために図５のメモリ520のようなメモリ中にそのデータパケットを記憶する。
【００３５】
ＨＳＵ530のソフトウェアドライバは、送信が失敗したデータパケットの再試行時にのみ ClearDestMaskN ビットを１に設定することが好ましい。再試行せず（ステップ922）、あるいは宛先マスクビットにより阻止されたデータパケットの再送（ステップ912）のようなその他全ての送信試行に関しては、ＨＳＵ530のソフトウェアドライバは ClearDestMaskN ビットをクリアする（ClearDestMaskN ビット＝０）。
【００３６】
ステップ916に戻って、たとえば、デバイス500が受領通知を宛先ノードＮから受信した場合のように、データパケットの送信が成功したことがＨＳＵ530により決定された場合、ステップ926においてそのデータパケットに対する処理は終了する。
【００３７】
［図８による例］
図６Ａおよび６Ｂの例示的な待ち行列600、700を図８に適応すると、送信デバイス500のＨＳＵ530のソフトウェアデバイスドライバは、図６Ａの待ち行列600にしたがってデータパケットの待ち行列を形成する。データパケットＳＴＡ１−１を処理しようと試みたとき、ＨＳＵ530のハードウェアはこのデータパケットＳＴＡ１−１に対応した送信記述子のフィールドを解析する。ステップ902において Index1Valid（Ｎ＝１）フィールドが１に等しく、ＨＳＵ530のハードウェアは TableIndex1（Ｎ＝１）フィールドを使用して状態テーブル中にインデックスを付けることによって DestMaskBit1（Ｎ＝１）を選択する。ＨＳＵ530のハードウェアはステップ906において DestMaskBit1 を検査し、この DestMaskBit1 がクリアであることを確認する。ＨＳＵ530のハードウェアはステップ908においてＳＴＡ１−１の送信を試みる。本発明の好ましい実施形態において、デバイス500が宛先に対するデータパケットの送信に続いてその宛先から受領通知を受信しなかった場合、そのデータパケット送信は失敗である。ＨＳＵ530は送信の失敗が発生したことを決定した（ステップ916）と仮定すると、ＨＳＵ530のハードウェアはステップ920において DestMaskBit1＝１を設定する。ＨＳＵ530は割込みを発生させ、ＨＳＵ530のソフトウェアドライバは、ＳＴＡ１−１が再送信されることを決定し（ステップ922において）、ステップ924において ClearDestMask1＝１（Ｎ＝１）を設定し、図６Ｂの待ち行列700に示されているようにデータパケットＳＴＡ３−２に続いてデータパケットＳＴＡ１−１を再度待ち行列に入れる。
【００３８】
宛先ステーションＳＴＡ１ 310に対する第１のデータパケットＳＴＡ１−１の送信が失敗した場合、状態テーブルは、宛先ステーションＳＴＡ１ 310が現在その待ち行列からのパケットトラフィックに対して利用できないことを示すように更新される。宛先ステーションＳＴＡ２ 312 または宛先ステーションＳＴＡ３ 314を予定されたデータパケットは送信のために選択される資格を有し続けるが、ＳＴＡ１ 310をターゲットにされた後続のデータパケットは無視され、再度待ち行列に入れられる。
【００３９】
次に、ＨＳＵ530のハードウェアは、図６Ａの待ち行列600からのデータパケットＳＴＡ２−１を処理しようと試みる。ステップ902においてＳＴＡ２−１に対してIndexNValid＝０と仮定すると、TableIndex2（Ｎ＝２）は無効であり、あるいは図３または４のＳＴＡ２ 312に対して阻止はエネーブルされない。この例においては、処理はステップ908に進み、このステップにおいてＨＳＵ530のハードウェアは、ＳＴＡ２ 312に対するデータパケットの送信を可能にする。ＨＳＵ530はステップ916においてＳＴＡ２−１の送信が成功したことを決定したと仮定すると、ステップ926においてそのＳＴＡ２−１に対する処理は終了する。
【００４０】
次に、ＨＳＵ530のハードウェアは、待ち行列600からのデータパケットＳＴＡ２−２を処理しようと試みる。ＨＳＵ530のハードウェアはデータパケットＳＴＡ２−２に対応した送信記述子のフィールドを解析する。ステップ902において如何なる理由でもＳＴＡ２−２の Index2Valid（Ｎ＝２）フィールドが１に等しいと仮定すると、ＨＳＵ530のハードウェアは TableIndex2（Ｎ＝２）フィールドを使用して状態テーブル中にインデックスを付けることによって DestMaskBit2 （Ｎ＝２）を選択する。ＨＳＵ530のハードウェアはステップ906において DestMaskBit2 を検査し、DestMaskBit2 がクリアであることを確認する。ＨＳＵ530のハードウェアはステップ908においてＳＴＡ２−２の送信を試みる。ＨＳＵ530はステップ916においてＳＴＡ２−２の送信が成功したことを決定したと仮定すると、ステップ926においてそのＳＴＡ２−２に対する処理は終了する。
【００４１】
次に、ＨＳＵ530のハードウェアは、待ち行列600からのデータパケットＳＴＡ３−１を処理しようと試みる。データパケットＳＴＡ３−１の送信が成功したと仮定する。次に、ＨＳＵ530のハードウェアは待ち行列600からのデータパケットＳＴＡ１−２を処理しようと試みる。ＳＴＡ１−２に対して、IndexNValid＝１（ステップ902）であり、TableIndexNは、ＨＳＵ530のハードウェアが DestMaskBit1 （Ｎ＝１）を選択することを可能にする。ＨＳＵ530のハードウェアは、ステップ906において DestMaskBit1 （Ｎ＝１）を検査する。ＨＳＵ530のハードウェアはデータパケットＳＴＡ１−１の送信の失敗に後続した DestMaskBit1＝１を確認し、ＳＴＡ１−２の処理がステップ910に進む。ClearDestMask1 はデータパケットＳＴＡ１−２に対してクリアであり、処理はステップ912に進み、ＨＳＵ530のハードウェアは図３または４のＳＴＡ１ 310に対するデータパケットＳＴＡ１−２の送信を阻止する。ＨＳＵ530は割込みを発生させ、ＨＳＵ530のソフトウェアデバイスドライバによりデータパケットＳＴＡ１−２は変更されずに再度待ち行列に入れられる。これは、図６Ｂの待ち行列700中のようなＳＴＡ１−１の後にＨＳＵ530のハードウェアがデータパケットを送信しようと試みなかったからである。
【００４２】
次に、ＨＳＵ530のハードウェアは、図６Ａの待ち行列600からのデータパケットＳＴＡ３−２を処理しようと試みる。ＨＳＵ530のハードウェアはデータパケットＳＴＡ３−２に対応した送信記述子のフィールドを解析する。ステップ902において Index3Valid（Ｎ＝３）フィールドは１に等しく、ＨＳＵ530のハードウェアは TableIndex3（Ｎ＝３）フィールドを使用して状態テーブルをインデックスすることによって DestMaskBit3 （Ｎ＝３）を選択する。ＨＳＵ530のハードウェアはステップ906において DestMaskBit3 を検査し、DestMaskBit3 がクリアであることを確認する。ＨＳＵ530のハードウェアはステップ908においてＳＴＡ３−２の送信を試みる。送信の失敗が生じたことがＨＳＵ530により決定された（ステップ916）と仮定すると、ＨＳＵ530のハードウェアはステップ920において DestMaskBit3＝１を設定する。ＨＳＵ530は割込みを発生させ、如何なる理由であってもＨＳＵ530のソフトウェアドライバは、データパケットＳＴＡ３−２が再送信されないことを決定し（ステップ922）、ステップ918において ClearDestMask3＝０（Ｎ＝３）を設定し、そのデータパケットＳＴＡ３−２を廃棄する。
【００４３】
次に、デバイス500によって処理される待ち行列600上のデータパケットは、はじめに送信に失敗したデータパケットＳＴＡ１−１となる。宛先マスクビット DestMaskBit1は、設定されたままであるが（ステップ906）、このデータパケットＳＴＡ１−１に対して ClearDestMask1 が設定される（ステップ910）ため、処理はステップ914に進む。このステップ914において宛先マスクビットはクリアされ（DestMaskBit1＝０）、ＨＳＵ530のハードウェアは、データパケットＳＴＡ１−１が送信されることを可能にする。ＳＴＡ１−１が正しく送信された場合、データパケットＳＴＡ１−２もまた送信される。これは、DestMaskBit1 がクリアだからである。このようにして、図６Ｂの送信間待ち行列700中に示されている所望の順序が達成される。
【００４４】
送信デバイス500の動作の説明において、機能はＨＳＵ530のハードウェアおよびソフトウェア部分に属する。コンピュータ組織、通信およびネットワークに関する当業者は、別の構成が可能であることを認識するであろう。たとえば、ここではデバイス500上で動作するＨＳＵ530のソフトウェアまたはデバイスドライバに属している機能は、たとえばハードウェアにより行なわれてもよい。同様に、ここにおいてＨＳＵ530のハードウェアに属している機能は、たとえば、ソフトウェアによって行なわれてもよい。
【００４５】
ここで使用されるように、送信デバイスという用語は、送信の手段ならびにその送信の手段が種々の別の送信関連特徴を含むことのできるネットワークエンティティハウジングを広く示すことを意図して使用されている。ここに記載されている本発明の好ましい実施形態によると、送信デバイスは、たとえば、無線通信ネットワークにおけるアクセスポイントまたはステーションであることができる。さらに広く言うと、送信デバイスにはＩＥＥＥ８０２．１１追従デバイスが含まれる。当然ながら、送信デバイスは無線デバイスならびに無線プロトコルおよび標準追従デバイスに限定されない。
【００４６】
ここで使用されているように、失敗した送信という用語は、第１の送信デバイスから１以上の別の送信デバイスに対するデータパケットの、何等かの理由による許容できないような送信とみなすことのできる送信の試みを最も広い意味で示すものである。本発明の好ましい実施形態において、送信の失敗は、送信デバイスが受信機アクセスポイントまたはステーションからそこに送られたデータパケットを受信したという受領通知を受信しないときに発生する。送られたデータパケットとは、固有の宛先に直接送信され、したがって受領通知を必要とするデータパケットのことである。別の実施形態における別の送信失敗例には、データパケットが第１の送信デバイスから送信されるが、そのターゲットの宛先に到達できない例、あるいはデータパケットがターゲット宛先に到達するが、そのターゲットの宛先においてエラーチェック機能によりエラーを含んでいるか、さもなければ許容不可能であると見なされる例が含まれる。
【００４７】
ここにおいて使用されている送信管理インターフェースという用語は、送信デバイスと共に含まれている送信手段とインターフェースするための結合されたハードウェアおよびソフトウェアの組合せまたは他のものを示すものである。たとえば、１実施形態においては送信管理インターフェースには図５のＨＳＵ530が含まれているが、別のプロセッサ、処理装置またはソフトウェア装置であることが可能である。送信管理インターフェースは、たとえば、図７および８におけるような、ここに記載されている方法にしたがって決定構造を実行することができる。送信管理インターフェースは、本発明の好ましい実施形態による宛先ビットマスクアレイ550のような状態テーブルを含んでいてもよいし、あるいは送信管理インターフェースの外部の状態テーブルからのエントリについてそれにアクセスするか、それを更新するか、あるいはそれを選択してもよい。送信管理インターフェースは、データパケット待ち行列のようなデータパケット順序付け機能あるいは本発明の好ましい実施形態による別のデータパケット操作機能を含んでいてもよいし、あるいはそのインターフェースが送信管理インターフェース外部のデータパケット順序付け機能を使用してもよい。
【００４８】
ここに示されている本発明の好ましい実施形態は、ある特定の宛先に対する多くのデータパケットを待ち行列に入れることを可能にする。記載されている実施形態は、たとえば、何れのＩＥＥＥ８０２．１１アクセスポイントまたはステーションにおいて使用されることが可能であり、一方実施形態ならびにそれに関連した概念および原理はパケットの正しい順序での送信を必要とする任意のネットワーキングデバイスに適用されることができる。送信デバイスが同じ宛先に対する多数のデータパケットを待ち行列に入れ、別の宛先に対する多数のデータパケットを待ち行列に入れることを可能にすることにより、ここに記載されている実施形態において高いネットワークスループットが達成され、性能が改善されると共にプロセッサ使用量が減少し、その一方においてデータパケットの順序付けられた送信を維持される。
【００４９】
本発明はとくに、好ましい実施形態を参照として記載されているが、本発明の技術的範囲を逸脱することなくその形態および詳細の変更および修正が可能であることが当業者に容易に明らかになるだろう。添付された請求の範囲は、このような変更および修正を含むものである。
【図面の簡単な説明】
【図１】  一連の宛先Ａ，ＢおよびＣに対する送信を予定されたデータパケットの例示的な待ち行列を示す概略図。
【図２】  典型的なＩＥＥＥ８０２．１１追従デバイスを示すブロック図。
【図３】  第１の例示的な無線通信ネットワークの構造を示す概略図。
【図４】  第２の例示的な無線通信ネットワークの構造を示す概略図。
【図５】  本発明の好ましい実施形態による送信デバイスを示すブロック図。
【図６Ａ】  一連の宛先ＳＴＡ１，ＳＴＡ２およびＳＴＡ３に対する送信を予定されたデータパケットの例示的な待ち行列を示す概略図。
【図６Ｂ】  データパケットを再度待ち行列に入れた後に続く、一連の宛先ＳＴＡ１，ＳＴＡ２およびＳＴＡ３への送信を予定されたデータパケットの例示的な待ち行列を示す概略図。
【図７】  本発明の好ましい実施形態による第１の例示的な送信阻止決定構造を示すフロー図。
【図８】  本発明の好ましい実施形態による第２の例示的な送信阻止決定構造を示すフロー図。
【図１】
0004836159.tif 000002
【図２】
0004836159.tif 000003
【図３】
0004836159.tif 000004
【図４】
0004836159.tif 000005
【図５】
0004836159.tif 000006
【図６Ａ】
0004836159.tif 000007
【図６Ｂ】
0004836159.tif 000008
【図７】
0004836159.tif 000009
【図８】
0004836159.tif 000010