"STA端末を用いたULMUMIMOUpLinkMulti-UserMultipleInputMultipleOutput通信の方法であって:ネットワーク内でフレームを送信するために競うステップ;前記端末におけるバッファされたデータを示すフレームを送信するステップ;TXOPTransmissionOpportunityの間に第一のポーリングフレームを受信するステップであり、前記第一のポーリングフレームは競争プロセスを通じて受信され、前記第一のポーリングフレームは、前記TXOPの間、ULMUMIMO通信のため複数の端末を識別する、ところのステップ;及び前記TXOPの間にMPDUMACProtocolDataUnitを送信するステップ;を有する方法。請求項1に記載の方法であって、前記端末が複数の端末を有するBSSBasicServiceSetの一部であり、前記MPDUがA-MPDUAggregateMPDUである方法。請求項2に記載の方法であって:前記TXOPの間に受信端末によって受信された第二のMPDUに応じた第一のBABlockAcknowledgementを受信するステップ;第二のポーリングフレームを受信するステップ;前記MPDUを再送信するステップ;及び前記MPDUに応じて第二のBAを受信するステップ;をさらに有する方法。請求項1に記載の方法であって、前記MPDUの中にバッファされたデータを挿入するステップ;をさらに含む方法。請求項4に記載の方法であって、前記第一のポーリングフレームがEDCAEnhancedDistributedChannelAccessを用いて送信される方法。請求項3に記載の方法であって、平均媒体ビジー時間の閾値を越えた後、前記受信端末から前記第一のポーリングフレームが送信される前記方法。ネットワーク内におけるULMUMIMO通信のための受信端末であって:複数の端末からバッファされたトラフィック情報を受信するための受信手段;ポーリングフレームを送信するためネットワーク内で競うための処理手段;TXOPの間に前記ポーリングフレームを送信するための送信手段であり、前記ポーリングフレームはULMUMIMO通信のための端末を識別する、送信手段;前記ポーリングフレームに応じて前記端末からMPDUを受信する受信手段であり、前記MPDUは前記TXOPの間に同時に送信される、受信手段;及び前記ポーリングフレームに応じて受信されたMPDUのため、前記TXOPの間に多数のBAを送信する送信手段;を有する受信端末。請求項7に記載の受信端末であって、前記複数の端末は、ネットワーク内でデータフレームを送信するために競うBSSの一部である受信端末。請求項8に記載の受信端末であって、前記受信端末はEDCAを用いてネットワーク内で競い、さらに前記MPDUはA-MPDUである受信端末。請求項7に記載の受信端末であって、前記ポーリングフレームで識別された端末からMPDUが受信されないとき、前記TXOPの間、第二のポーリングフレームを送信することを特徴とする受信端末。請求項10に記載の受信端末であって、前記第二のポーリングフレームに応じて前記MPDUを受信することを特徴とする受信端末。請求項11に記載の受信端末であって、受信している前記MPDUに応じて他のBAを送信することを特徴とする受信端末。端末であって:データを受信し、MPDUを生成するためのMACMediaAccessControllerと;前記MPDUを受信し、プレアンブルと物理ヘッダを生成するためのPHYPHYsicallayer:物理レイヤと;アレイトランシーバであり;競争プロセスを通じて受信端末へフレームを送信し、前記フレームは前記端末におけるバッファされたデータを示し;TXOPの間に第一のポーリングフレームを受信し、前記第一のポーリングフレームは競争プロセスを通じて受信され、前記第一のポーリングフレームは前記TXOPの間にULMUMIMO通信のために複数の端末を識別し;前記TXOPの間に前記MPDUを送信するよう構成されたアレイトランシーバと;を有する端末。請求項13に記載の端末であって、前記MACはソフトウェアルーチンにより具体化されている端末。請求項13に記載の端末であって、前記端末は複数の端末を有するBSSの一部である端末。請求項13に記載の端末であって、前記端末は:前記TXOPの間に第一のBAを受信し、前記BAは受信端末によって受信された第二のMPDUに応じたものであり;前記TXOPの間に前記受信端末から第二のポーリングフレームを受信し;前記TXOPの間に前記MPDUを再送し;及び前記MPDUに応じて第二のBAを受信するようさらに構成された;端末。請求項13に記載の端末であって、送信される前記MPDUの中に前記バッファされたデータを挿入することをさらに含む端末。請求項13に記載の端末であって、前記第一のポーリングフレームが、EDCAにより受信端末から送信されたものである端末。請求項13に記載の端末であって、平均媒体ビジー時間の閾値を越えた後、受信端末から前記第一のポーリングフレームが送信される端末。請求項14に記載の端末であって、前記物理レイヤがソフトウェアルーチンにより具体化されている端末。本発明の主題は、本明細書の最後に添付されている請求の範囲に定義されている。なお、構成および作動方法は、目的、特徴、および有利な効果とともに、図面を参照しながら、以下の詳細な説明を理解することができる。いうまでもなく、説明の分かりやすさおよび明瞭さのために、図において例示される要素が、一定の比率で必ずしも描かれているというわけではない。例えば、いくつかの要素の大きさは、明確にするために、他の要素と比較して誇張されている場合もある。参照番号は、対応あるいは類似した要素を示すために、必要に応じて図の中で繰り返されて付される場合もある。上述した課題を解決し目的を達成するため、本発明にかかる方法は、STA端末を用いたULMUMIMOUpLinkMulti-UserMultipleInputMultipleOutput通信の方法であって:ネットワーク内でフレームを送信するために競うステップ;前記端末におけるバッファされたデータを示すフレームを送信するステップ;TXOPTransmissionOpportunityの間に第一のポーリングフレームを受信するステップであり、前記第一のポーリングフレームは競争プロセスを通じて受信され、前記第一のポーリングフレームは、前記TXOPの間、ULMUMIMO通信のため複数の端末を識別する、ところのステップ;及び前記TXOPの間にMPDUMACProtocolDataUnitを送信するステップ;を有する。また、上述した課題を解決し目的を達成するため、本発明にかかる受信端末は、ネットワーク内におけるULMUMIMO通信のための受信端末であって:複数の端末からバッファされたトラフィック情報を受信するための受信手段;ポーリングフレームを送信するためネットワーク内で競うための処理手段;TXOPの間に前記ポーリングフレームを送信するための送信手段であり、前記ポーリングフレームはULMUMIMO通信のための端末を識別する、送信手段;前記ポーリングフレームに応じて前記端末からMPDUを受信する受信手段であり、前記MPDUは前記TXOPの間に同時に送信される、受信手段;及び前記ポーリングフレームに応じて受信されたMPDUのため、前記TXOPの間に多数のBAを送信する送信手段;を有する。さらに、上述した課題を解決し目的を達成するため、本発明にかかる端末は、端末であって:データを受信し、MPDUを生成するためのMACMediaAccessControllerと;前記MPDUを受信し、プレアンブルと物理ヘッダを生成するためのPHYPHYsicallayer:物理レイヤと;アレイトランシーバであり;競争プロセスを通じて受信端末へフレームを送信し、前記フレームは前記端末におけるバッファされたデータを示し;TXOPの間に第一のポーリングフレームを受信し、前記第一のポーリングフレームは競争プロセスを通じて受信され、前記第一のポーリングフレームは前記TXOPの間にULMUMIMO通信のために複数の端末を識別し;前記TXOPの間に前記MPDUを送信するよう構成されたアレイトランシーバと;を有する。以下の説明では、本発明の徹底的な理解に資するために、公平な媒体共有を通じた無線通信ネットワーク内の通信の改善及びネットワーク内でエラーリカバリを有効化することなど、数多くの具体的な詳細を記載している。しかし、本発明を実施するためには、前述の具体的な詳細を使用しなくてもよいことが当業者には明らかであろう。一方、周知の方法や手順、構成要素及び回路は本発明を不必要に不明瞭にすることを避けるために詳細に記載していない。無線通信ネットワークのBSSのネットワーク容量を増やすための一つのアプローチは、ポーリングPolledTXOPをサポートし、ULMUMIMOに対応できる端末と、ULMUMIMO通信向けに構成されていない端末との間で公平な媒体共有を有効にすることである。ULMUMIMO通信のためにエラーリカバリを提供することにより、なお一層技術的に向上する。ULMUMIMO通信に対応するいくつかの端末は、パケット及びデータを転送するための無線通信ネットワークまたは媒体内で、競うように構成されていなくてもよい。媒体の中で競わないULMUMIMO端末に対応するため、APAccessPoint:アクセスポイントへ送信するパケットがあるとき、端末によってTXRTXOPRequest:TXOPリクエストが送信される。複数のTXRを受信して、APは、ULMUMIMO通信のため、無線通信ネットワーク内で端末をポーリングするためにTXSTXSendを送信する。本実施形態において、TXSは、端末がポーリングされていることを確認し、TXOPのためのNAVNetworkAllocationVectorを設定する。しかし、本実施形態において、もしネットワーク内でパケットを送信するために競うよう構成されている無線通信ネットワーク内においても端末が存在するとき、競うよう構成されていないそれらの端末は、パケットを送信する前に、APがそれらの端末をポーリングするのを待つ必要があるだろう。ポーリングPolledTXOPをサポートし、ULMUMIMOに対応できる端末と、ネットワーク内でULMUMIMO通信のために競うよう構成されていない端末との間で、公平な媒体共有を有効にすることは有用である。それらの実施形態において、ULMUMIMO通信のためエラーリカバリを提供することもまた有用である。図について検討すると、図1は例えば無線ネットワーク100などのネットワーク内の端末又はプラットフォームのブロック図を示している。本発明のいくつかの実施形態は、無線通信端末、モバイル端末、拡張端末、クライアント端末、プラットフォーム、無線通信デバイス、無線アクセスポイント、モデム、無線モデム、パーソナルコンピュータ、デスクトップコンピュータ、モバイルコンピュータ、ラップトップコンピュータ、ノートブックコンピュータ、タブレットコンピュータ、サーバー、セットトップボックス、ハンドヘルドコンピュータ、ハンドヘルドデバイス、PDAPersonalDigitalAssitant、ハンドヘルドPDA及び/又はネットブックを通じて実施されてもよい。端末又はプラットフォームは、交互にあるいは組み合わせて、例えばLAN、無線LAN、MANMetropolitanAreaNetwork:メトロポリタンネットワーク、WMANWirelessMAN:無線MAN、WANWideAreaNetwork:ワイドエリアネットワーク、WWANWirelessWAN:無線WANのような無線ネットワークを使ってもよい。又は、現行の次世代mmWaveNGmS-D02/r0、November28,2008、WGAWirelessGigabitAlliance、IEEE802.11、802.11a、802.11b、802.11e、802.11g、802.11h、802.11i、802.11n、802.11ac、802.16、802.16d、802.16e規格及び/又は将来のバージョン及び/又はそれらの派生及び/又は上記規格のLTELongTermEvolution、PANPersonalAreaNetwork、WPANWirelessPAN:無線PANにしたがって動作するデバイス及び/又はネットワークを使ってもよい。又は、上記WLAN及び/又はPAN及び/又はWPANネットワークの一部の設備及び/又はデバイス、一方向及び/又は双方向の無線通信システム、携帯電話の無線電話通信システム、携帯電話、無線電話、PCSPersonalCommunicationSystemsデバイス、無線通信デバイスを組み込んだPDFデバイス、MIMOトランシーバー又はデバイス、SIMOSingleInputMultipleOutputトランシーバー又はデバイス、MRCMaximumRatioCombiningトランシーバー又はデバイス、スマートアンテナ技術又はマルチアンテナ技術を有するトランシーバー又はデバイスを使ってもよい。又は、同類のものを使ってもよい。本発明のいくつかの実施形態は、一つかそれ以上の種類の無線通信信号及び/又はシステムとともに用いられてもよい。例えば、RFRatioFrequency:無線周波数、IRInfraRed、FDMFrequency-DivisionMultiplexing:周波数分割多重化、OFDMOrthogonalFDM:直交波周波数分割多重化、OFDMA、TDMTime-DivisionMultiplexing:時分割多重化、TDMATime-DivisionMultipleAccess:時分割多元接続、E-TDMAExtendedTDMA、GPRSGeneralPacketRadioService、CDMA2000、MDMMulti-CarrierModulation:多重搬送波変調、DMTDescreteMulti-Tone:離散マルチトーン、Bluetooth登録商標、ZigBee商標又は同様のものがある。本発明の実施形態において、様々な他の装置、デバイス、システム及び/又はネットワークが用いられてもよい。一つの実施形態においては、無線ネットワーク100上の端末又はプラットフォームは、例えば802.11TGacなどの関連したタスクグループによって開発中である、一つかそれ以上のIEEE802.11規格及び/又はプロトコルにしたがって運用してもよい。前記プロトコル及び/又は前記規格に従った端末の運用においては、少なくとも2つのレイヤの実装を必要としてもよい。一つのレイヤが、OSI802.11MACレイヤ、言い換えればOSIOpenSystemsInterconnectionモデルにおけるデータリンク層第二層である。一般的に、MACレイヤは一つの共有無線チャネルへのアクセスを調整することにより、802.11デバイス間の通信を管理し保持する。例えばMACレイヤは、他の処理の中で、802.11デバイスのスキャニング、802.11デバイスの認証、第一の端末と第二の端末の関連付け、例えばWEPWirelessEncryptionProtocolなどのセキュリティ技術の機能、RTSRequesttosend及びCTSCleartosend操作の要求、省電力機能、分割フラグメンテーション処理、データの受信及びMPDUMACProtocolDataUnitの生成又はMPDUの連結のような操作を実行してもよい。もう一つのレイヤは802.11物理レイヤ、言い換えればOSIモデルにおける物理層第一層である。物理レイヤは、他の処理の中で、キャリア搬送波検知並びに802.11フレームの送信及び受信を実行してもよい。例えば物理レイヤは、他の処理の中で、変調、復調、エンコーディング符号化、デコーディング復号化、ADAnalog-To-Digital変換、DADigital-To-Analog変換、フィルタリング、MPDU又はA-MPDUAggregation-MPDU:多重化MPDUの受信及びプレアンブルと物理ヘッダの生成のような操作を統合してもよい。物理レイヤは、専用のハードウェア又はソフトウェアのエミュレーションを用いて実装され得る。MAC層は、専用のハードウェア及び専用のソフトウェアどちらか一方又はその両方を用いて実装されてもよい。図1は、無線ネットワーク100が受信端末STA102及び一つか一つ以上の複数の送信端末104とを有することを示している。受信端末102は、関連する送信端末104間の通信を提供してもよい。さらに、関連する送信端末104が、一つかそれ以上の例えばインターネットなどの外部のネットワークとの通信を可能にしてもよい。いくつかの実施形態において、受信端末102は例えばWiFiWirelessFidelity、WiMaxWorldwideInteroperabilityforMicrowaveAccess又は広帯域通信端末などの無線アクセスポイントであってもよい。しかし、受信端末102がほとんどあらゆる通信端末であって良く、その点について本発明の範囲は限定されない。いくつかの実施形態において、送信端末104は例えばWiFi、WiMax、広帯域通信端末などの通信端末又はモバイル端末であってもよい。しかし、その点について本発明の範囲は限定されない。本明細書において受信端末102及び送信端末104は、ULMUMIMOの動作に関連して指定されている。しかしながら、各受信端末102及び送信端末104は、無線ネットワーク100において送信信号及び受信信号の、受信手段及び送信手段として構成されているものと認識される。本発明のいくつかの実施形態によると、受信端末102は、関連する送信端末104の一つ以上のマルチユーザのアップリンクを利用する。これらの実施形態において、選ばれた関連する送信端末104上で動作するアプリケーションにおいてレイテンシが小さくなってもよい。アプリケーションとは、時間的制約のあるパケットの送信要求を有する、例えばVoIPVoiceOverIP、ビデオストリーミングなどの時間的制約のあるアプリケーションを含んでもよい。いくつかの実施形態において、アプリケーションは、QoSQuality-Of-Serviceレベルの要件を有するアプリケーションを含んでもよい。QoSレベルの要件とは、データ転送速度、エラー率及び/又はパケット優先度の要件を含んでもよい。いくつかの実施形態において、QoSレベルの要件は通信の情報コンテンツに基づくものであってもよい。アプリケーションは、バックグラウンドトラフィックと同様にベストエフォートの通信を行う、時間的制約の弱いアプリケーションを含んでもよい。本発明のいくつかの実施形態は、時間的制約のあるアプリケーションにおいてレイテンシを小さくすると記載されているが、いくつかの実施形態は送信端末104上のほぼ全ての通信アプリケーションについても等しく適用できるように、この点について発明の範囲を限定するものではない。いくつかの実施形態において、時間的制約のあるアプリケーションは、パケットのレイテンシ要件を有するあらゆる通信アプリケーションについて言及してもよい。いくつかの実施形態において、関連する通信端末の電力消費もまた小さくなり得る。いくつかの実施形態において受信端末102は、マルチキャリアの通信チャネルの同一周波数のサブキャリア副搬送波上で、2つ以上の関連する送信端末104から、2つ以上の受信アンテナによりアップリンクのデータを実質的に同時又は並列に受信してもよい。これらの実施形態において受信端末102は、送信信号が受信された関連する各送信端末に対しチャネル推定値を用いて、2以上の関連する送信端末104によって送信されたアップリンクのデータを内部で区別してもよい。いくつかの実施形態において、受信端末102は関連する送信端末の位置的な差異により、アンテナダイバーシティを利用しても良い。本発明のいくつかの実施形態によれば、受信端末102は、送信端末104から同時に送信された周波数インターリーブが行われた直交するロングトレーニング信号及びショートトレーニング信号を受信する。トレーニング信号は、受信端末102の各受信アンテナ103により受信される。受信端末102は、反復デコーディングのプロセスを実行して、受信されたトレーニング信号から各送信端末104のキャリア推定値及びCFOCarrierFrequencyOffset:キャリア周波数オフセット推定値を生成する。反復デコーディングのプロセスには、CFOによって誘発された直交性の損失の結果、受信された現在のトレーニング信号からICIIntercarrierInterference:キャリア間干渉を相殺するため、前回生成されたチャネル推定値及びCFO推定値が使用される。いくつかの実施形態において、送信端末104は同時又は並列に応答するためポーリングされる。各送信端末104は、同時に仮想的なMIMOシステムを形成できるよう、標準のプレアンブルの一部を使用してもよい。受信端末102は、信号を受信及び送信するよう構成されるアレイトランシーバにおいて、各送信端末によって送信された空間ストリームを分解するため、選ばれた送信端末104の数と同じか、それ以上の数のアンテナ103を有してもよいこれらの実施形態のうちいくつかにおいては、最初のCFO推定がSTFShortTrainingField:ショートトレーニングフィールドの受信中に実行され、チャネル推定とともにCFO訂正がLTFLongTrainingField:ロングトレーニングフィールド又はプレアンブルの受信中に実行される。これらの実施形態の一例では、各パケットがSTF、LTF、データフィールド及びサイクリックプレフィックスを含んでもよい。しかし、その点について本発明の範囲は限定されない。図2は本発明のいくつかの実施形態に従った受信端末200のブロック図である。受信端末200は図1の受信端末102に対応してもよい。しかし、他の設定もまた適切であり得る。図1の送信端末102は同様に構成されてもよい。しかし、その点について本発明の範囲は限定されない。受信端末200は、例えばOFDM信号又はOFDMA信号などのマルチキャリア通信を受信してもよい。そしてMACMediaAccessControl:メディアアクセス制御レイヤ220のために物理レイヤ出力データ219を生成してもよい。受信端末200は、図1の関連する送信端末104から通信を受信するため、アレイトランシーバにおいて複数の受信アンテナ202を有していてもよい。及び、ベースバンド信号205を生成するための各アンテナ202に付随するRFRadio-Frequency:高周波受信回路204を有していてもよい。及び、各受信アンテナ202に関連付けられたデジタル信号207を生成するためのADCAnalog-To-DigitalConversion:アナログデジタル変換回路206を有していてもよい。受信端末200は復調信号209を生成するため復調機208も有していてもよい。いくつかの実施形態においては、復調機208はOFDM又はOFDM変調機を有していてもよい。しかし、その点について本発明の範囲は限定されない。信号処理部210は等化処理も行い、図1の各送信端末104と関連付けられたデータストリーム211を生成するため、各サブキャリアのために周波数領域シンボルへのコンステレーションのデマップ化を行ってもよい。いくつかの実施形態においては、信号処理部210は、受信したトレーニング信号から図1の各送信端末104のためのチャネル推定値及びCFO推定値を生成してもよい。いくつかの実施形態において信号処理部210は、CFOによって誘発された直交性の損失の結果現在受信されたトレーニング信号からICIを相殺するため、前回生成されたチャネル推定値及びCFO推定値を用いて反復デコーディングプロレスを実行してもよい。受信端末200は、ビット211においてデインターリーブ処理を実行するためのデインターリーバ212も有していてもよい。さらに、受信端末200は、ビットクロック230又はフレームクロック228によって得られる境界情報に基づいてフレーム215を生成するため、デインターリーバからのビットを多重化するマルチプレクサ214も有していてもよい。さらに、受信端末200はフレーム215をデコードするためのデコーダ216と、物理レイヤ出力データ219を生成するためにデコードされたフレームをアンスクランブルするためのアンスクランブラー218も有していてもよい。しかし、その点について本発明の範囲は限定されない。受信端末200は、MACレイヤ220を含むことができるデータ処理回路222を含む。データ処理回路222は、マルチユーザのアップリンクにおいて送信端末から通信信号を受信することができる受信アンテナ202の番号に基づいて、送信端末の既定の番号を選択してもよい。いくつかの実施形態において受信端末200は、最大4つの関連する送信端末から通信信号201を受信するために、最大4つの受信アンテナ202を用いてもよい。いくつかの実施形態において受信端末200は、最大10以上の関連する送信端末から通信信号201を受信するために最大10以上の受信アンテナ202を用いてもよい。いくつかの実施形態において、受信端末102はマルチキャリア通信チャネルを通じてOFDM又はOFDMA通信信号を送信及び/又は受信してもよい。これらのマルチキャリア通信信号は所定の周波数スペクトルに含まれてよく、直交する多数のサブキャリアを有してもよい。いくつかの実施形態において、直交するサブキャリアは狭い間隔のサブキャリアであってもよい。狭い間隔のサブキャリア間で直交性を実現するため、各サブキャリアは他のサブキャリアの事実上の中心周波数においてヌル点を有しても良い。いくつかの実施形態において、狭い間隔のサブキャリア間で直交性を実現するために、各サブキャリアはシンボル期間内に周期的な整数を有してもよい。しかし、その点について本発明の範囲は限定されない。いくつかの実施形態において、図1の受信端末102及び関連する送信端末104との間で通信される、マルチキャリア通信信号のための周波数スペクトルは、5GHzの周波数スペクトルか、2.4GHzの周波数スペクトルかいずれかを有していてもよい。これらの実施形態において5GHzの周波数スペクトルは、正確には4.9から5.9GHzに分布する周波数を含んでもよい。そして、2.4GHzの周波数スペクトルは、正確には2.3から2.5GHzに分布する周波数を含んでもよい。しかし、他の周波数スペクトルもまた同様に適応できるように、その点について本発明の範囲は限定されない。いくつかのブロードバンド及びWiMaxを用いた実施形態において、通信のための周波数スペクトルは2からIIGHzの間の周波数を有してもよい。しかし、その点について本発明の範囲は限定されない。アンテナ202は指向性又は無指向性のアンテナを有していてもよい。例えば、ダイポールアンテナ、モノポールアンテナ、パッチアンテナ、ループアンテナ、マイクロストリップアンテナ及び他の種類の受信及び/又は送信の無線信号に適したアンテナを含んでもよい。図2において受信端末200は4つのアンテナ202及び4つの関連する受信信号経路を有するよう示されているが、その点について本発明の範囲は限定されない。いくつかの実施形態において、受信端末200はアレイトランシーバにおいてわずか2つの受信アンテナを有していてもよいし、10以上のアンテナを有していてもよい。ある実施例において、信号処理回路210が図1における1つの関連する送信端末104から受信したデータを生成するとき、ビットクロック230はビット境界をマルチプレクサ214に与えてもよい。スイッチエレメント232は選択的にビットクロック230又はフレームクロック228をマルチプレクサ214と結び付けてもよい。アップリンクのデータが実質的に同時に2以上の送信端末104から受信されている時は、フレームクロック228が結び付けられてもよい。しかし一方、アップリンクのデータが異なる送信端末104から異なる時に受信されている時、言い換えれば標準モードで通信しているとき、ビットクロック230が結び付けられてもよい。受信端末102及び多数の送信端末104はULMUMIMO技術を用いて無線ネットワーク100上で稼動してもよい。図3は本発明のいくつかの実施形態にしたがってオポチュニスティックOpportunisticポーリング機構を用いたULMUMIMOの動作のブロック図である。この実施形態において、2つの送信端末104及び受信端末102が使用されている。しかしながら、無線ネットワーク100においては追加の送信端末104及び/又は受信端末102も存在していてもよい。受信端末102及び多数の送信端末104は、当業者に知られたBSS基本サービスセットを形成し、そこで端末例えば102及び104が、データフレーム又はパケットを送信しようと競う。BSS内の送信端末104は全てULMUMIMO通信のために構成されていてもよい。あるいは、BSS内の一つかそれ以上の送信端末のサブセットがULMUMIMO通信のために構成されていてもよい。データフレームのためのフレームのタイプ又はサブタイプの一実施形態を表1に示す。表1が示すように、ULMUMIMO通信向けに構成された送信端末104は、フレームのMACヘッダのQoS制御フィールド中に、バッファされたトラフィック情報を含んでもよい。表1に示された、例えば送信端末104などのアクセスポイントでない端末によって送られたQoSデータフレームの、8~15ビットのキューサイズフィールドは、送信端末104によって送られたA-MPDUAggregateMPDU:多重化MPDUの送信後に残った、バッファされた残りのトラフィックの量を示している。キューサイズはTXRメッセージの中か、あるいはQoSデータメッセージのMACヘッダの中のいずれかで示される。一実施形態において、受信端末102及び送信端末104を含む、無線ネットワーク100内の端末は、例えばEDCAEnhancedDistributedChannelAccess並びに/又はコンテンション期間及びコンテンションフリー期間両方において端末をポーリングする機能を含むHCCAHCFHybridCoordinationFunctionControlledChannelAccessなどの競争コンテンションプロセスを用いて、媒体にアクセスしフレームを送信してもよい。EDCAを用いて、各端末はフレームを送信するために競ってもよい。受信端末102はバッファしたトラフィックを有する送信端末104を見つけ出すために送信端末104をポーリングする。一実施形態において、ポーリングPollingフレーム310を受信した後、ポーリングされた送信端末104のみが送信することができる。受信端末102又はAPは、第一の端末STA1のデータフレームDATA302及び第二の端末STA2のデータフレーム306を含む多数の送信端末104からA-MPDUを受信する。そして、第一の端末のBABlockAcknowledgement304及び第二の端末のBA308を各々送信する。短いインターフレームスペース303はデータフレーム302及び306に続く。さらに、バックオフ時間305がBA304及び308に続く。受信端末102は、データフレーム302及び306内のA-MPDUの受信に応じて、TXOP311を与えるためにポーリングフレーム310を送信する。例えば、一つ以上の送信端末104がA-MPDUを送信してバッファされたトラフィックが残っていることを示した場合、受信端末102はポーリングフレーム310を送信してもよい。一実施形態において、受信端末102は、EDCA競争contention:コンテンションに勝った後、ポーリングフレーム310を送信してもよい。他の実施形態において、受信端末102は、平均媒体ビジー時間が設定された閾値より長い場合にはポーリングフレーム310を送信してもよい。ポーリングフレーム310は後のULMUMIMO通信のために送信端末104を識別する。ポーリングフレーム310を受信すると、ポーリングフレーム310によって識別された送信端末104は、第一の端末のバッファされたデータフレーム312及び第二の端末のバッファされたデータフレーム314においてA-MPDUを、第一の端末のBAR313BARequest及び第二の端末のBAR315を伴って各々送信する。受信端末102は一つのTXOP311のうちに複数の送信端末104をポーリングしても良い。一実施形態において、受信端末102は各ULMUMIMO通信のためポーリングフレーム310を送信している。他の実施形態においては、追加のポーリングフレーム310が送信されてもよい。第一の端末のバッファされたデータフレーム312の受信に応じて、受信端末102はBA304を送信する。そして第二の端末のバッファされたデータフレーム314の受信に応じて、受信端末102はBA308を送信する。縮小されたインターフレームスペース307は第一のBA304と次のBA308とを分離する。受信端末102は、ポーリングフレーム310を送信した後、無線ネットワーク100の媒体がPIFSPriorityInterFrameSpaceを経過しアイドル状態であると検知したとき、受信端末102はエクスポネンシャルバックオフを開始でき、ポーリングフレーム310を送信して再度競う。一実施形態において、受信端末102は、データフレームを待つ間に用いられるACAccessCategoryと同様、AC優先度を用いてバックオフを開始し再度競うことにより、EDCAの規則に従ってもよい。図4は本発明のいくつかの実施形態に従ったULMUMIMOのTXOP動作のブロック図である。この実施形態において、TXOP311はポーリングフレーム310から開始され、そのときにポーリングフレーム310は送信端末104にフレームを送信するための機会を与える。二つの送信端末104は、2つのポーリングフレーム310に応じて、TXOP311の間にフレームを送信する。TXOP311中に受信端末102は、無線ネットワーク100内のどの端末も自由にポーリングできる。本実施形態においては、無線ネットワーク100内のほかの端末は、ポーリングフレームを受け取らずに、TXOPの間に先に送信してはならない。フレーム中にA-MPDUを送信する2つの送信端末104が図4において示されているが、TXOP311の間に追加の送信端末104がポーリングされ、送信端末104が例えばMPDUなどの様々なタイプのフレームを送信してもよい。図5は本発明のいくつかの実施形態に従ったTXOP311中のエラーリカバリのブロック図である。エラーリカバリとは、正しくデコードされなかった可能性のある一つのフレーム又は複数のフレームに対処するために用いられる仕組みである。受信端末102は、送信端末104にフレームの送信を促すポーリングフレーム310を送信する。フレームには、第一の端末のデータフレーム302及び不完全な第二の端末のデータフレーム402が含まれる。そこで不完全な第二の端末のデータフレーム402は受信端末102によって適切に受信されていない。受信端末102は、第一の端末のデータフレーム302に応じて、第一の端末のBA304を送信する。そして、第二の端末のデータフレーム306を促すため、ポーリングフレーム310を送信する。第二の端末のデータフレーム306の受信を通して、正常なエラーリカバリが行われたことが、第二の端末のBA308によって確認される。図6は本発明の他の実施形態に従ったTXOP311中のエラーリカバリのブロック図である。図6が示すように、受信端末102は、TXOP311中に、送信端末104にフレームの送信を促すポーリングフレーム310を送信する。第一の端末のBA304が、第一の端末のデータフレーム302に応じて送信されるが、第二の端末のBA308は、不完全な第二の端末のデータフレーム402に応じて送信されていない。送信端末104又は不完全な第二の端末のデータフレーム402を送った第二の端末は、第一の端末のBA304を受信するが、第二の端末のBA308は受信しない。本実施形態において、第二の端末はCWContentionWindow:コンテンションウィンドウをCWminCWminimumに設定し、CW=CWminとして成功バックオフを開始する。受信端末102がULMUMIMO通信において送信端末104から正常にフレームを受信してデコードし、少なくとも1つのBA、例えば第一の端末のBA304を返送したとき、第二の端末は受信端末102において衝突は発生しなかったと決定してもよい。他の要因として、第二の端末によって送信されたフレームの破損や、例えば障害、チャネル変動及び/又はノイズなどによる第二の端末のデータフレーム402が不完全であることが原因となり得る。図6に示されるように、第二の端末はバックオフ時間305と調停インターフレームスペース602を用いてエクスポネンシャルバックオフを開始する。他の実施形態において、端末がさらに送信すべきトラフィック又はフレームを有しており、受信端末102から少なくとも1つのBAを受信したとき、たとえBAが端末へ直接向けられていなくても、端末は成功バックオフを開始してもよい。受信端末102からBAが全く受信されないとき、第二の端末はエクスポネンシャルバックオフを開始する。受信端末102は、少なくとも1つのデータパケットが正しく受信されたとき、成功バックオフを開始することができる。図7は本発明のいくつかの実施形態に従ったTXOP311の設定のブロック図である。例えば本実施形態における第一の端末などの送信端末104はRTXRequestToTransmitフレーム702を送信する。RTXフレーム702は受信端末102に、CTXClearToTransmitフレーム704を送信するよう促す。CTXフレーム704は、バッファされたトラフィック又はデータを送信するために送信端末104をポーリングする。RTXフレーム702は、受信端末102からのCTXフレーム704の送信を明らかにするための、例えばMAC待ち時間などの情報を有する。例えば、第一のNAVNetworkAllocationVector706によって示されるRTXTXOP時間は以下のように表されてもよい。RTXTXOP時間:SIFSCTX_durationRTXフレーム702を受信したとき、受信端末102は多数の送信端末104をポーリングするためにCTXフレーム704を送信する。そのとき、第二のNAV708によって示されるCTXTXOP時間は以下のように表されてもよい。CTXTXOP時間:Max_data_durationSIFSBA_duration送信端末104は、CTXフレーム704内で指定された最大データ送信時間に至るまで、ULデータフレームを送信する。本実施形態においてULデータフレームは、第一の端末データフレーム302、第二の端末のデータフレーム306及び第三の端末STA3のデータフレーム710を含む。受信端末102は、ULデータフレームの受信に応じて、第三のNAV714の間に、BA712を送信する。図8は本発明のいくつかの実施形態に従ったTXOP311におけるエラーリカバリのブロック図である。例えば第一の端末などの送信端末104がRTXフレーム702を送信する。RTXフレーム702は、バッファされたトラフィック又はデータを送信するため、送信端末104をポーリングするCTXフレーム704を送信するよう受信端末102を促す。RTXフレーム702を送信した第一の端末がCTXフレームの受信に失敗したとき、第一の端末は送信失敗として取り扱い、エクスポネンシャルバックオフを開始しなければならない。CTXフレーム704を受信した後、送信端末104はデータフレームにおいてMPDU及び/又はA-MPDUを送信する。受信端末102は、ポーリングして送信端末104にデータフレームを送信するよう促すため、CTXフレーム704を送信する。前記データフレームには、第一の端末のデータフレーム302、第三の端末のデータフレーム310及び不完全な第二の端末のデータフレーム402が含まれる。そこで、不完全な第二の端末のデータフレーム402は受信端末102により正しく受信されない。送信端末104又は不完全な第二の端末のデータフレーム402を送信した端末は、BA712の中で第二の端末のためのBAを受信しない。しかし、受信端末102から他の送信端末104のためのBAは受信する。本実施例において、第二の端末は、CWをCWminに設定し、第二の端末はCWContentionWindow:コンテンションウィンドウをCWminCWminimumに設定し、CW=CWminとして成功バックオフを開始する。受信端末102がULMUMIMO通信において送信端末104から正常にフレームを受信してデコードし、少なくとも1つのBA、例えばBA712を返送したとき、第二の端末は受信端末102において衝突は発生しなかったと決定してもよい。他の要因として、第二の端末によって送信されたフレームの破損や、例えば障害、チャネル変動及び/又はノイズなどによる第二の端末のデータフレーム402が不完全であることが原因となり得る。しかしながら、BA712が受信端末102から受信されなかったとき、第二の端末はエクスポネンシャルバックオフを開始してもよい。図9は本発明のいくつかの実施形態に従ったULMUMIMO通信のフロー図である。ブロック900において、ネットワーク内でフレームが供給され競争プロセスがフレームの送信のために用いられる。ブロック910において、前記フレームは受信端末102又はAPに送信される。ブロック920において、TXOPの間に第一のポーリングフレームが受信され、そこで第一のポーリングフレームがULMUMIMO通信のために端末を識別する。ブロック930において、TXOPの間にMPDUが送信され、ブロック940において、受信端末102から第一のBAを受信する。ブロック950において、受信端末又はAPから送信された第二のポーリングフレームが受信され、ブロック960において、TXOPの間に前記MPDUが再送される。ブロック970において、前記MPDUに応じて第二のBAが受信される。図10は本発明のいくつかの実施形態に従ったULMUMIMO通信の他のフロー図である。ブロック1000において、無線ネットワーク100内で受信端末102は複数の送信端末104からバッファされたトラフィック情報を受信する。ブロック1010において、ポーリングフレームを送信するため、受信端末102は無線ネットワーク100内で競う。ブロック1020において、TXOPの間、ポーリングフレームは送信手段を用いて送信される。そして、ブロック1030において、ポーリングフレームに応じて、ULMUMIMO通信により送信端末104から多数のMPDUが受信される。ブロック1040において、ポーリングフレームに応じて受信されたMPDUのため、多数のBAが送信される。本明細書において実施形態は、例えば命令、関数、手続き、データ構造、アプリケーションプログラム、設定などのデータへの言及とともに記載されていてもよい。本発明の目的において、プログラムという用語は、アプリケーション、ドライバー、プロセス、ルーチン、メソッド、モジュール及びサブプログラムを含む、幅広いソフトウェアコンポーネント及びソフトウェア構成を含める。プログラムという用語は、完全なコンパイル単位、言い換えれば独立してコンパイルされる命令の組、コンパイル単位の集まり又はコンパイル単位の一部分に言及するために用いられ得る。従って、プログラムという用語は、受信端末102又は送信端末104によって実行されるとき、ULMUMIMO通信を提供する命令の任意の集合について言及するために用いられ得る。本明細書において議論した動作は、一般的に、有形の媒体の上にコード命令として規定通りに具体化されたファームウェア又はソフトウェアの実行を用いて容易にされる。したがって、本発明の実施形態は、なんらかの形の中央処理手段上で実行される命令又はコンピュータが読み取り可能な媒体上別の方法で実装あるいは実現されている命令の組を含んでもよい。コンピュータが読み取り可能な媒体とは、例えばコンピュータなどの機械によって読み取れるように情報を保存又は送信するための任意の仕組みを含む。例えば、コンピュータが読み取り可能な媒体とは、例えばROMReadOnlyMemory、RAMRandomAccessMemory、磁気ディスクストレージメディア、光学ストレージメディア及びフラッシュメモリデバイスなどの製品を含むことができる。加えて、コンピュータが読み取り可能な媒体は、例えば電気、光、音響又は他の伝播信号などを含んでもよい。例えば、キャリア波、赤外線信号、デジタル信号などがある。本明細書において、特定の本発明の特徴が例示されたが、多くの変更、置換、変形及び均等物についても、当業者であれば構成できるであろう。したがって、特許請求の範囲は、それら全ての変更及び変形を含むことを意図している。"