(57)【要約】  本発明の実施形態は、無線ローカルエリアネットワークにおいて、複数の局によって、ダウンリンクデータフレームの送信を確認するための方法および装置を開示する。方法は、アクセスポイントによって、対応するダウンリンクデータフレームを複数の局の各局に送信するステップと、アクセスポイントが対応するダウンリンクデータフレームを各局に送信した後、アクセスポイントによって、アクセスポイントによって複数の局に割り当てられたチャネルリソース上で、複数の局によって同時に送信される確認メッセージを受信するステップとを含む。本発明の実施形態で提供される方法および装置によると、確認メッセージをフィードバックするために複数の局によって必要とされる時間は低減されることができる。
2017529774.tif 000002
【特許請求の範囲】
【請求項１】
無線ローカルエリアネットワークにおいて、複数の局によって、ダウンリンクデータフレームの送信を確認するための方法であって、前記方法は、
アクセスポイントによって、対応するダウンリンクデータフレームを前記複数の局の各局に送信するステップと、
前記アクセスポイントが前記対応するダウンリンクデータフレームを各局に送信した後、前記アクセスポイントによって、前記アクセスポイントによって前記複数の局に割り当てられたチャネルリソース上で、前記複数の局によって同時に送信される確認メッセージを受信するステップとを含む方法。
【請求項２】
前記アクセスポイントが前記対応するダウンリンクデータフレームを各局に送信した後、前記アクセスポイントによって、前記複数の局によって同時に送信される確認メッセージを受信する前記ステップの前に、前記方法は、
事前に設定された時間の後、前記アクセスポイントによって、確認要求メッセージを前記複数の局に送信するステップであって、前記確認要求メッセージはチャネルリソース情報を含み、且つ、前記チャネルリソース情報は、前記アクセスポイントによって前記複数の局に割り当てられた前記チャネルリソースを示すために使用される、ステップをさらに含む、請求項１に記載の方法。
【請求項３】
前記アクセスポイントによって、前記アクセスポイントによって前記複数の局に割り当てられたチャネルリソース上で、前記複数の局によって同時に送信される確認メッセージを受信する前記ステップは、具体的には、
前記アクセスポイントによって、前記確認要求メッセージに含まれる前記チャネルリソース情報によって示される前記チャネルリソース上で、前記複数の局によって同時に送信される前記確認メッセージを受信するステップである、請求項２に記載の方法。
【請求項４】
前記確認要求メッセージは、ブロック確認要求メッセージBlockAckReqである、請求項２または３に記載の方法。
【請求項５】
前記BlockAckReqは、サブチャネルインデックス情報およびフレームチェックシーケンス（FCS）情報を含み、且つ、前記サブチャネルインデックス情報の後には、前記FCS情報が続く、請求項４に記載の方法。
【請求項６】
前記ダウンリンクデータフレームは、前記ダウンリンクデータフレームに対応する局に割り当てられたチャネルリソースを識別するために使用される情報を含む、請求項１に記載の方法。
【請求項７】
前記情報は、前記ダウンリンクデータフレームの物理フレーム収束プロシージャヘッダ（PLCP Header）内に配置される、請求項６に記載の方法。
【請求項８】
無線ローカルエリアネットワークにおいて、局によってダウンリンクデータフレームの送信を確認するための方法であって、前記方法は、
前記局によって、アクセスポイントによって送信されるダウンリンクデータフレームを受信するステップと、
前記局が前記アクセスポイントによって送信される前記ダウンリンクデータフレームを受信した後、前記局によって、前記アクセスポイントによって前記局に割り当てられたチャネルリソース上で、前記アクセスポイントに確認メッセージを送信するステップとを含む、方法。
【請求項９】
前記局が前記アクセスポイントによって送信される前記ダウンリンクデータフレームを受信した後、前記局によって、前記アクセスポイントによって前記局に割り当てられたチャネルリソース上で、前記アクセスポイントに確認メッセージを送信する前記ステップの前に、前記方法は、
事前に設定された時間の後、前記局によって、前記アクセスポイントによって送信される確認要求メッセージを受信するステップであって、前記確認要求メッセージはチャネルリソース情報を含み、且つ、前記チャネルリソース情報は、前記アクセスポイントによって前記局に割り当てられた前記チャネルリソースを示すために使用される、ステップをさらに含む、請求項８に記載の方法。
【請求項１０】
前記局によって、前記アクセスポイントによって前記局に割り当てられたチャネルリソース上で、前記アクセスポイントに確認メッセージを送信する前記ステップは、具体的には、
前記局によって、前記確認要求メッセージに含まれる前記チャネルリソース情報によって示される前記チャネルリソース上で、前記確認メッセージを前記アクセスポイントに送信するステップである、請求項９に記載の方法。
【請求項１１】
前記確認要求メッセージは、ブロック確認要求メッセージBlockAckReqである、請求項９または１０に記載の方法。
【請求項１２】
前記BlockAckReqは、サブチャネルインデックス情報およびフレームチェックシーケンス（FCS）情報を含み、且つ、前記サブチャネルインデックス情報の後には、前記FCS情報が続く、請求項１１に記載の方法。
【請求項１３】
前記ダウンリンクデータフレームは、前記アクセスポイントによって前記局に割り当てられた前記チャネルリソースを識別するために使用される情報を含む、請求項８に記載の方法。
【請求項１４】
前記情報は、前記ダウンリンクデータフレームの物理フレーム収束プロシージャヘッダ（PLCP Header）内に配置される、請求項１３に記載の方法。
【請求項１５】
トランシーバ、プロセッサおよびバスを含むアクセスポイントであって、
前記トランシーバおよび前記プロセッサは、前記バスを使用することによって通信を実施し、
前記トランシーバは、前記プロセッサの制御下で、対応するダウンリンクデータフレームを複数の局の各局に送信し、
前記トランシーバは、前記ダウンリンクデータフレームを各局に送信した後、前記アクセスポイントによって前記複数の局に割り当てられたチャネルリソース上で、前記複数の局によって同時に送信される確認メッセージを受信するように構成される、アクセスポイント。
【請求項１６】
前記トランシーバは、前記複数の局に確認要求メッセージを送信するようにさらに構成され、前記確認要求メッセージは、チャネルリソース情報を含み、且つ、前記チャネルリソース情報は、前記アクセスポイントによって前記複数の局に割り当てられた前記チャネルリソースを示すために使用される、請求項１５に記載のアクセスポイント。
【請求項１７】
前記確認要求メッセージは、ブロック確認要求メッセージBlockAckReqである、請求項１６に記載のアクセスポイント。
【請求項１８】
前記BlockAckReqは、サブチャネルインデックス情報およびフレームチェックシーケンス（FCS）情報を含み、且つ、前記サブチャネルインデックス情報の後には、前記FCS情報が続く、請求項１７に記載のアクセスポイント。
【請求項１９】
前記ダウンリンクデータフレームは、前記ダウンリンクデータフレームに対応する局に割り当てられたチャネルリソースを識別するために使用される情報を含む、請求項１５に記載のアクセスポイント。
【請求項２０】
前記情報は、前記ダウンリンクデータフレームの物理フレーム収束プロシージャヘッダ（PLCP Header）内に配置される、請求項１９に記載のアクセスポイント。
【請求項２１】
前記アクセスポイントは、ラップトップコンピュータ、ルータ、セットトップボックスまたは携帯電話のうちの１つである、請求項１５乃至２０のうちのいずれか１項に記載のアクセスポイント。
【請求項２２】
トランシーバ、プロセッサおよびバスを含む局であって、
前記トランシーバおよび前記プロセッサは、前記バスを使用することによって通信を実施し、
前記トランシーバは、アクセスポイントによって送信されるダウンリンクデータフレームを受信し、
前記トランシーバは、前記アクセスポイントによって送信される前記ダウンリンクデータフレームを受信した後、前記プロセッサの制御下で、前記アクセスポイントによって前記局に割り当てられたチャネルリソース上で、前記アクセスポイントに確認メッセージを送信するように構成される、局。
【請求項２３】
前記トランシーバは、前記アクセスポイントによって送信される確認要求メッセージを受信するようにさらに構成され、前記確認要求メッセージはチャネルリソース情報を含み、且つ、前記チャネルリソース情報は、前記アクセスポイントによって前記局に割り当てられた前記チャネルリソースを示すために使用される、請求項２２に記載の局。
【請求項２４】
前記確認要求メッセージは、ブロック確認要求メッセージBlockAckReqである、請求項２３に記載の局。
【請求項２５】
前記BlockAckReqは、サブチャネルインデックス情報およびフレームチェックシーケンス（FCS）情報を含み、且つ、前記サブチャネルインデックス情報の後には、前記FCS情報が続く、請求項２４に記載の局。
【請求項２６】
前記ダウンリンクデータフレームは、前記アクセスポイントによって前記局に割り当てられた前記チャネルリソースを識別するために使用される情報を含む、請求項２２に記載の局。
【請求項２７】
前記情報は、前記ダウンリンクデータフレームの物理フレーム収束プロシージャヘッダ（PLCP Header）内に配置される、請求項２６に記載の局。
【請求項２８】
前記アクセスポイントは、ラップトップコンピュータ、ルータ、セットトップボックスまたは携帯電話のうちの１つである、請求項２２乃至２７のうちのいずれか１項に記載の局。
【発明の詳細な説明】
【技術分野】
【０００１】
本願は、2014年8月25日に中国特許庁に出願され、且つ、「DATA TRANSMISSION METHOD AND APPARATUS USED IN WIRELESS LOCAL AREA NETWORK」と題する、中国特許出願番号201410422580.3に対して優先権を主張し、その全体が参照によって本明細書に組み込まれる。
【０００２】
本発明の実施形態は通信技術の分野に関し、詳細には、無線ローカルエリアネットワークにおいて使用されるデータ送信方法および装置に関する。
【背景技術】
【０００３】
アクセスポイント（Access Point, 略してAP）は、マルチユーザ多入力多出力（Multi-User Multiple-Input Multiple-Output, 略してMU MIMO）技術または直交周波数分割多元接続（Orthogonal Frequency Division Multiple Access, 略してOFDMA）技術を使用することによって、ダウンリンクデータフレームを複数の局（Station, 略してSTA）に同時に送信することができる。ダウンリンクデータフレームを送信する前に、アクセスポイントは、最初に、局のダウンリンクチャネルを測定してよい。アクセスポイントは、電気電子技術者協会（Institute of Electrical and Electronics Engineers, 略してIEEE）802.11標準において定義されるチャネル測定機構を使用することによって、ダウンリンクチャネルを測定してよい。図１に示されるように、局にその後チャネル測定を実行するように命令するために、アクセスポイントは、最初に、ヌルデータパケット通知（Null Data Packet Announce, 略してNDPA）メッセージを複数の局に送信する。次いで、アクセスポイントは、ヌルデータパケット（Null Data Packet, 略してNDP）メッセージを前述の局に送信し、局は、NDPメッセージ内のトレーニングシーケンスを使用することによって、ダウンリンクチャネルを測定するとともに、チャネル測定結果、すなわち、チャネル状態情報（Channel State Information, 略してCSI）をアクセスポイントに順次フィードバックする。アクセスポイントは、局によってフィードバックされるCSIに従って、MU MIMO技術またはOFDMA技術を使用することによって、ダウンリンクデータフレームを複数の局に送信することができる。
【０００４】
ダウンリンクデータフレームを複数の局に送信した後、アクセスポイントは、ダウンリンクデータフレームが成功裏に受信されたかどうかをフィードバックするように局に要求するために、確認要求メッセージを複数の局に短フレーム間間隔（Short Interframe Space, 略してSIFS）で順次送信する。確認要求メッセージは、BlockAckReq（Block Acknowledgement Request, ブロック確認要求；IEEE 802.11標準において、BlockAckReqはまた、略してBARであってもよい）であってよい。確認要求メッセージを受信した後、複数の局は、時分割方式で、確認メッセージをAPに順次返す。確認メッセージは、図２に示されるように、BlockAck（Block Acknowledgement, ブロック確認；IEEE 802.11標準において、BlockAckはまた、略してBAであってもよい）であってよい。確認要求を受信した後、複数のSTAは、確認メッセージをAPに返すために比較的長いフィードバック時間をかける。
【発明の概要】
【課題を解決するための手段】
【０００５】
本発明の実施形態は、無線ローカルエリアネットワークにおいて、複数の局によって、ダウンリンクデータフレームの送信を確認するための方法および装置を提供し、このことは、確認メッセージをフィードバックするために複数の局によって必要とされる時間を低減することができる。
【０００６】
本発明の実施形態の第１の態様は、無線ローカルエリアネットワークにおいて、複数の局によって、ダウンリンクデータフレームの送信を確認するための方法を開示し、ここで、方法は、アクセスポイントによって、対応するダウンリンクデータフレームを複数の局の各局に送信するステップと、アクセスポイントが対応するダウンリンクデータフレームを各局に送信した後、アクセスポイントによって、アクセスポイントによって複数の局に割り当てられたチャネルリソース上で、複数の局によって同時に送信される確認メッセージを受信するステップとを含む。
【０００７】
第１の態様を参照すると、第１の態様の第１の実施方式では、アクセスポイントが対応するダウンリンクデータフレームを各局に送信した後、アクセスポイントによって、複数の局によって同時に送信される確認メッセージを受信するステップの前に、方法は、事前に設定された時間の後、アクセスポイントによって、確認要求メッセージを複数の局に送信するステップであって、ここで、確認要求メッセージはチャネルリソース情報を含み、且つ、チャネルリソース情報は、アクセスポイントによって複数の局に割り当てられたチャネルリソースを示すために使用される、ステップをさらに含む。
【０００８】
第１の態様の第１の実施方式を参照すると、第１の態様の第２の実施方式では、アクセスポイントによって、アクセスポイントによって複数の局に割り当てられたチャネルリソース上で、複数の局によって同時に送信される確認メッセージを受信するステップは、具体的には、アクセスポイントによって、確認要求メッセージに含まれるチャネルリソース情報によって示されるチャネルリソース上で、複数の局によって同時に送信される確認メッセージを受信するステップである。
【０００９】
第１の態様の第１の実施方式または第１の態様の第２の実施方式を参照すると、第１の態様の第３の実施方式では、確認要求メッセージは、ブロック確認要求メッセージBlockAckReqである。
【００１０】
第１の態様の第３の実施方式を参照すると、第１の態様の第４の実施方式では、BlockAckReqは、サブチャネルインデックス情報およびフレームチェックシーケンス（FCS）情報を含み、且つ、サブチャネルインデックス情報の後には、FCS情報が続く。
【００１１】
第１の態様を参照すると、第１の態様の第５の実施方式では、ダウンリンクデータフレームは、ダウンリンクデータフレームに対応する局に割り当てられたチャネルリソースを識別するために使用される情報を含む。
【００１２】
第１の態様の第５の実施方式を参照すると、第１の態様の第６の実施方式では、情報は、ダウンリンクデータフレームの物理フレーム収束プロシージャヘッダ（PLCP Header）内に配置される。
【００１３】
本発明の実施形態の第２の態様は、無線ローカルエリアネットワークにおいて、局によってダウンリンクデータフレームの送信を確認するための方法を開示し、ここで、方法は、局によって、アクセスポイントによって送信されるダウンリンクデータフレームを受信するステップと、局がアクセスポイントによって送信されるダウンリンクデータフレームを受信した後、局によって、アクセスポイントによって局に割り当てられたチャネルリソース上で、アクセスポイントに確認メッセージを送信するステップとを含む。
【００１４】
第２の態様を参照すると、第２の態様の第１の実施方式では、局がアクセスポイントによって送信されるダウンリンクデータフレームを受信した後、局によって、アクセスポイントによって局に割り当てられたチャネルリソース上で、アクセスポイントに確認メッセージを送信するステップの前に、方法は、事前に設定された時間の後、局によって、アクセスポイントによって送信される確認要求メッセージを受信するステップであって、ここで、確認要求メッセージはチャネルリソース情報を含み、且つ、チャネルリソース情報は、アクセスポイントによって局に割り当てられたチャネルリソースを示すために使用される、ステップをさらに含む。
【００１５】
第２の態様の第１の実施方式を参照すると、第２の態様の第２の実施方式では、局によって、アクセスポイントによって局に割り当てられたチャネルリソース上で、アクセスポイントに確認メッセージを送信するステップは、具体的には、局によって、確認要求メッセージに含まれるチャネルリソース情報によって示されるチャネルリソース上で、確認メッセージをアクセスポイントに送信するステップである。
【００１６】
第２の態様の第１の実施方式または第２の態様の第２の実施方式を参照すると、第２の態様の第３の実施方式では、確認要求メッセージは、ブロック確認要求メッセージBlockAckReqである。
【００１７】
第２の態様の第３の実施方式を参照すると、第２の態様の第４の実施方式では、BlockAckReqは、サブチャネルインデックス情報およびフレームチェックシーケンス（FCS）情報を含み、且つ、サブチャネルインデックス情報の後には、FCS情報が続く。
【００１８】
第２の態様を参照すると、第２の態様の第５の実施方式では、ダウンリンクデータフレームは、アクセスポイントによって局に割り当てられたチャネルリソースを識別するために使用される情報を含む。
【００１９】
第２の態様の第５の実施方式を参照すると、第２の態様の第６の実施方式では、情報は、ダウンリンクデータフレームの物理フレーム収束プロシージャヘッダ（PLCP Header）内に配置される。
【００２０】
本発明の実施形態の第３の態様は、トランシーバ、プロセッサおよびバスを含むアクセスポイントを開示し、ここで、トランシーバおよびプロセッサは、バスを使用することによって通信を実施し、トランシーバは、プロセッサの制御下で、対応するダウンリンクデータフレームを複数の局の各局に送信し、トランシーバは、ダウンリンクデータフレームを各局に送信した後、アクセスポイントによって複数の局に割り当てられたチャネルリソース上で、複数の局によって同時に送信される確認メッセージを受信するように構成される。
【００２１】
第３の態様を参照すると、第３の態様の第１の実施方式では、トランシーバは、複数の局に確認要求メッセージを送信するようにさらに構成され、ここで、確認要求メッセージは、チャネルリソース情報を含み、且つ、チャネルリソース情報は、アクセスポイントによって複数の局に割り当てられたチャネルリソースを示すために使用される。
【００２２】
第３の態様の第１の実施方式を参照すると、第３の態様の第２の実施方式では、確認要求メッセージは、ブロック確認要求メッセージBlockAckReqである。
【００２３】
第３の態様の第２の実施方式を参照すると、第３の態様の第３の実施方式では、BlockAckReqは、サブチャネルインデックス情報およびフレームチェックシーケンス（FCS）情報を含み、且つ、サブチャネルインデックス情報の後には、FCS情報が続く。
【００２４】
第３の態様を参照すると、第３の態様の第４の実施方式では、ダウンリンクデータフレームは、ダウンリンクデータフレームに対応する局に割り当てられたチャネルリソースを識別するために使用される情報を含む。
【００２５】
第３の態様の第４の実施方式を参照すると、第３の態様の第５の実施方式では、情報は、ダウンリンクデータフレームの物理フレーム収束プロシージャヘッダ（PLCP Header）内に配置される。
【００２６】
第３の態様または第３の態様の第１の実施方式乃至第３の態様の第５の実施方式のうちのいずれかの実施方式を参照すると、第３の態様の第６の実施方式では、アクセスポイントは、ラップトップコンピュータ、ルータ、セットトップボックスまたは携帯電話のうちの１つである。
【００２７】
本発明の実施形態の第４の態様は、トランシーバ、プロセッサおよびバスを含む局を開示し、ここで、トランシーバおよびプロセッサは、バスを使用することによって通信を実施し、トランシーバは、アクセスポイントによって送信されるダウンリンクデータフレームを受信し、トランシーバは、アクセスポイントによって送信されるダウンリンクデータフレームを受信した後、プロセッサの制御下で、アクセスポイントによって局に割り当てられたチャネルリソース上で、アクセスポイントに確認メッセージを送信するように構成される。
【００２８】
第４の態様を参照すると、第４の態様の第１の実施方式では、トランシーバは、アクセスポイントによって送信される確認要求メッセージを受信するようにさらに構成され、ここで、確認要求メッセージはチャネルリソース情報を含み、且つ、チャネルリソース情報は、アクセスポイントによって局に割り当てられたチャネルリソースを示すために使用される。
【００２９】
第４の態様の第１の実施方式を参照すると、第４の態様の第２の実施方式では、確認要求メッセージは、ブロック確認要求メッセージBlockAckReqである。
【００３０】
第４の態様の第２の実施方式を参照すると、第４の態様の第３の実施方式では、BlockAckReqは、サブチャネルインデックス情報およびフレームチェックシーケンス（FCS）情報を含み、且つ、サブチャネルインデックス情報の後には、FCS情報が続く。
【００３１】
第４の態様を参照すると、第４の態様の第４の実施方式では、ダウンリンクデータフレームは、アクセスポイントによって局に割り当てられたチャネルリソースを識別するために使用される情報を含む。
【００３２】
第４の態様の第４の実施方式を参照すると、第４の態様の第５の実施方式では、情報は、ダウンリンクデータフレームの物理フレーム収束プロシージャヘッダ（PLCP Header）内に配置される。
【００３３】
第４の態様または第４の態様の第１の実施方式乃至第４の態様の第５の実施方式のうちのいずれかの実施方式を参照すると、第４の態様の第６の実施方式では、アクセスポイントは、ラップトップコンピュータ、ルータ、セットトップボックスまたは携帯電話のうちの１つである。
【００３４】
前述の技術的解決手段では、本発明の実施形態で提供される、無線ローカルエリアネットワークにおいて、複数の局によってダウンリンクデータフレームの送信を確認するための方法および装置によると、アクセスポイントは、対応するダウンリンクデータフレームを複数の局の各局に送信し、アクセスポイントが対応するダウンリンクデータフレームを各局に送信した後、アクセスポイントは、アクセスポイントによって複数の局に割り当てられたチャネルリソース上で、複数の局によって同時に送信される確認メッセージを受信し、このことは、確認メッセージをフィードバックするために複数の局によって必要とされる時間を低減することができる。
【図面の簡単な説明】
【００３５】
本発明の実施形態における技術的解決手段をより明確に説明するために、以下では、実施形態を説明するために必要とされる添付図面を簡潔に導入する。明らかに、以下の説明における添付図面は、単に、本発明のいくつかの実施形態を示し、且つ、当業者は、創造的努力無しにこれらの添付図面から他の図面をさらに導出することができる。
【００３６】
【図１】図１は、IEEE 802.11標準において定義されたチャネル測定機構の概略図である。
【図２】図２は、複数の局STAによって、アクセスポイントAPに確認メッセージをフィードバックすることの概略図である。
【図３】図３は、本発明の実施形態に係る、無線ローカルエリアネットワークにおいて、複数の局によって、ダウンリンクデータフレームの送信を確認するための方法の概略図である。
【図４】図４は、本発明の実施形態に係る、無線ローカルエリアネットワークにおいて、複数の局によって、ダウンリンクデータフレームの送信を確認することの別の概略図である。
【図５】図５は、本発明の実施形態に係る、BlockAckReqのフレームフォーマットの概略図である。
【図６】図６は、本発明の実施形態に係る、無線ローカルエリアネットワークにおいて、複数の局によって、ダウンリンクデータフレームの送信を確認することのさらに別の概略図である。
【図７ａ】図７ａは、本発明の実施形態に係る、ダウンリンクデータフレームの物理層フレームフォーマットの概略図である。
【図７ｂ】図７ｂは、本発明の実施形態に係る、ダウンリンクデータフレームの物理層フレームフォーマットのさらに別の概略図である。
【図８】図８は、本発明の実施形態に係る、無線ローカルエリアネットワークにおいて、局によって、ダウンリンクデータフレームの送信を確認するための方法の概略図である。
【図９】図９は、本発明の実施形態に係る、アクセスポイントの概略図である。
【図１０】図１０は、本発明の実施形態に係る、局の概略図である。
【発明を実施するための形態】
【００３７】
本発明の実施形態の目的、技術的解決手段および利点をより明確にするために、以下では、本発明の実施形態における添付図面を参照して、本発明の実施形態における技術的解決手段を明確に説明する。明らかに、説明される実施形態は、本発明の実施形態の全てではなく一部である。創造的努力無しに、本発明の実施形態に基づいて、当業者によって取得される全ての他の実施形態は、本発明の保護範囲に包含されるべきである。
【００３８】
実施形態におけるアクセスポイント（Access Point, 略してAP）は、ルータ、携帯電話、ラップトップコンピュータ、セットトップボックスまたは、無線媒体または有線媒体を使用することによって通信を実行するように構成された任意の他の適切なデバイスであってよく、局（Station, 略してSTA）は、ルータ、携帯電話、ラップトップコンピュータ、セットトップボックスまたは、無線媒体または有線媒体を使用することによって通信を実行するように構成された任意の他の適切なデバイスであってよい。
【００３９】
図３を参照すると、本発明の実施形態は、無線ローカルエリアネットワークにおいて、複数の局によって、ダウンリンクデータフレームの送信を確認するための方法３００を提供する。方法３００を実行するために使用されるデバイスはアクセスポイントであってよい。方法３００は以下のステップを含む：
【００４０】
Ｓ３０２：アクセスポイントは、対応するダウンリンクデータフレームを複数の局の各局に送信する。
【００４１】
アクセスポイントは、マルチユーザ多入力多出力（Multi-User Multiple-Input Multiple-Output, 略してMU MIMO）技術または直交周波数分割多元接続（Orthogonal Frequency Division Multiple Access, 略してOFDMA）技術を使用することによって、ダウンリンクデータフレームを複数の局の各局に同時に送信してよい。あるいは、アクセスポイントは、対応するダウンリンクデータフレームを複数の局の各局に順次送信してよい。
【００４２】
「複数」は「２以上」として理解されることができる。例えば、「複数の局」は、２つの局またはそれより多くの局を含んでよい。
【００４３】
Ｓ３０４：アクセスポイントが対応するダウンリンクデータフレームを各局に送信した後、アクセスポイントは、アクセスポイントによって複数の局に割り当てられたチャネルリソース上で、複数の局によって同時に送信される確認メッセージを受信する。
【００４４】
アクセスポイントが複数の局の各局にチャネルリソースを割り当てることは、異なる方式で実施されてよい。アクセスポイントは、複数の局に送信される確認要求メッセージにチャネルリソース情報を追加してよく、ここで、チャネルリソース情報は、アクセスポイントによって複数の局の各局に割り当てられたチャネルリソースを示すために使用され、または、アクセスポイントは、複数の局の各局に送信される対応するダウンリンクデータフレームにチャネルリソース情報を追加してよく、ここで、チャネルリソース情報は、アクセスポイントによって、対応するダウンリンクデータフレームを受信する局に割り当てられたチャネルリソースを示すために使用される。複数の局は、ダウンリンクデータフレームが成功裏に受信されたかどうかをアクセスポイントに通知するために、OFDMA技術を使用して、アクセスポイントによって割り当てられるとともにチャネルリソース情報によって示されるチャネルリソースを使用することによって、確認メッセージをアクセスポイントに同時に送信してよい。
【００４５】
本発明の本実施形態で提供される方法によると、アクセスポイントは、対応するダウンリンクデータフレームを複数の局の各局に送信し、アクセスポイントは、アクセスポイントが対応するダウンリンクデータフレームを各局に送信した後、アクセスポイントによって複数の局に割り当てられたチャネルリソース上で、複数の局によって同時に送信される確認メッセージを受信し、このことは、確認メッセージをフィードバックするために複数の局によってかかる時間を低減することができる。加えて、アクセスポイントによって複数の局に割り当てられたチャネルリソース上で、複数の局によって、確認メッセージをアクセスポイントに同時に送信する方式はまた、チャネル利用を改善する。
【００４６】
図４は、本発明の実施形態に係る、無線ローカルエリアネットワークにおいて、複数の局によって、ダウンリンクデータフレームの送信を確認することの概略図を示す。アクセスポイントがダウンリンクデータフレームを複数の局に送信した後、アクセスポイントが複数の局によって同時に送信される確認メッセージを受信する前に、方法は、
アクセスポイントによって、事前に設定された時間の後、確認要求メッセージを複数の局に送信するステップであって、ここで、確認要求メッセージはチャネルリソース情報を含み、且つ、チャネルリソース情報は、アクセスポイントによって複数の局に割り当てられたチャネルリソースを示すために使用される、ステップをさらに含む。
【００４７】
事前に設定された時間は、短フレーム間間隔（Short Interframe Space, 略してSIFS）であってよい。SIFSの値は、異なるIEEE 802.11標準において異なってよい。例えば、IEEE 802.11a標準では、SIFSの値は16μsであり、且つ、IEEE 802.11g標準では、SIFSの値は10 μsである。
【００４８】
アクセスポイントは、マルチキャスト（multicast）によって、複数の局に確認要求メッセージを送信してよく、または、ユニキャスト（unicast）によって、対応する局に確認要求メッセージを送信してよい。アクセスポイントがマルチキャストによって複数の局に確認要求メッセージを送信するとき、確認要求メッセージに含まれるチャネルリソース情報は、アクセスポイントによって複数の局に割り当てられたチャネルリソースを示す。アクセスポイントがユニキャストによって複数の局の対応する局に確認要求メッセージを順次送信するとき、確認要求メッセージに含まれるチャネルリソース情報は、アクセスポイントによって対応する局に割り当てられたチャネルリソースを示す。
【００４９】
具体的には、確認要求メッセージは、ブロック確認要求メッセージBlockAckReqであってよい。アクセスポイントがマルチキャストによって複数の局に確認要求メッセージを送信するとき、ブロック確認要求メッセージBlockAckReqは、アクセスポイントによって複数の局に割り当てられたチャネルリソースを示すチャネルリソース情報を含む。アクセスポイントがユニキャストによって複数の局の対応する局に確認要求メッセージを順次送信するとき、確認要求メッセージは、アクセスポイントによって対応する局に割り当てられたチャネルリソースを示すチャネルリソース情報を含む。アクセスポイントが複数の局の各局にダウンリンクデータフレームを送信した後、アクセスポイントは、ブロック確認要求メッセージBlockAckReqに含まれるチャネルリソース情報によって示されるチャネルリソースを使用することによって、複数の局によってアクセスポイントに同時に送信された確認メッセージを受信する。
【００５０】
図５に示されるように、図５は、本発明の実施形態に係る、BlockAckReqのフレームフォーマットの概略図である。BlockAckReqのフレームフォーマットは、2バイトのフレーム制御Frame Controlフィールド（Field；通信標準では、Fieldはフィールドとして解釈されてよく、またはドメインとして解釈されてよく；フレーム制御Frame Controlフィールドはまた、フレーム制御Frame Control情報と呼ばれてもよい）と、2バイトのフレーム持続時間Duration/IDフィールド、6バイトの受信機アドレスRAフィールド、6バイトの送信機アドレスTAフィールド、2バイトのBAR Controlフィールド、可変バイトのBAR Informationフィールド、NバイトのSub-Channel-Index（サブチャネルインデックス）フィールド（Sub-Channel-Indexフィールドはまた、Sub-Channel-Index情報と呼ばれてもよい）および4バイトのFCS（Frame Check Sequence, フレームチェックシーケンス）フィールドを含み、ここで、Nは正の整数である。
【００５１】
Nバイトのサブチャネルインデックスフィールドは、本発明の本実施形態におけるBlockAckReqのフレームフォーマットに追加されたフィールドである。Nは、実際のニーズに従って、バイト数に設定されてよい。例えば、Nは、局の数に従って、バイト数に設定されてよい。サブチャネルインデックスフィールドは、アクセスポイントによって局に割り当てられたチャネルリソースを示すために使用される。具体的には、サブチャネルインデックスフィールドは、アクセスポイントによって局に割り当てられたチャネルリソースを示すために使用されるチャネルリソース情報を搬送してよい。例えば、アクセスポイントは、ユニキャストによって、BlockAckReqを対応する局に送信してよく、ここで、Nは16バイナリビットの合計である2バイトであってよい。2バイトのサブチャネルインデックスフィールドは、0 MHzから40 MHzのチャネルリソースを16個のサブチャネルに分割し、ここで、各サブチャネルは2.5 MHzの幅を有する。16個のサブチャネルは、低周波から高周波へ順次1から16に番号付けされる。アクセスポイントが対応する局に１０番目のサブチャネルを割り当てる場合、16個のバイナリビットの１０番目のビットは1に設定されてよく、且つ、残りのバイナリビットは0に設定され、このことは、１０番目のサブチャネルは対応する局に割り当てられ、且つ、局は１０番目のサブチャネルを使用することによって、確認メッセージをフィードバックすることを示す。類推によって、アクセスポイントは、ダウンリンクデータフレームを受信する全ての局にチャネルリソースを割り当ててよく、その結果、複数の局は、割り当てられたチャネルリソースを使用することによって、確認メッセージをアクセスポイントに同時に返し、ここで、確認メッセージは、BlockAckであってよい。同様に、アクセスポイントは、マルチキャストによって、BlockAckReqを複数の局に送信してよい。アクセスポイントがチャネルリソースをm個の局に同時に割り当てる場合、アクセスポイントによってm個の局に割り当てられたチャネルリソースを示すために、Nは少なくとも2mバイトを含む必要があり、ここで、mは1よりも大きい正の整数である。
【００５２】
具体的には、BlockAckReqのフレームフォーマットに追加されたサブチャネルインデックスSub-Channel-Indexフィールドの後ろには、FCSフィールドが続いてよい。例えば、サブチャネルインデックスフィールドは、BlockAckReq のフレームフォーマットにおいて、FCSフィールドが後ろに続くとともにBAR Informationフィールドの後ろにある位置に配置されてよい。サブチャネルインデックスフィールドはまた、BlockAckReq のフレームフォーマットにおいて、BAR Informationフィールドが後ろに続くとともにBAR Controlフィールドの後ろにある位置に配置されてもよいことは理解されることができる。本発明の本実施形態は、それに限定を課さない。
【００５３】
任意で、サブチャネルインデックスフィールドはまた、インデックス番号を示すために使用されてもよい。局は、インデックス番号に従って、サーバから、または局のローカルデータテーブルから、局に割り当てられたチャネルリソースを見つけてよい。サブチャネルインデックスフィールドは、確認要求メッセージに含まれるチャネルリソース情報であり、ここで、チャネルリソース情報は、インデックス番号を示すために使用され、その結果、局は、インデックス番号に従って、サーバから、または局のローカルデータテーブルから、局に割り当てられたチャネルリソースを見つけることができる。例えば、0 MHzから40 MHzのチャネルリソースは16個のサブチャネルに分割され、ここで、各サブチャネルは2.5 MHzの幅を有する。16個のサブチャネルは、低周波から高周波へ順次1から16に番号付けされる。アクセスポイントは、ユニキャストによって、対応する局にBlockAckReqを送信し、ここで、Nは1バイト、すなわち、8バイナリビットであってよい。8バイナリビットの１番目のビットから４番目のビットは、アクセスポイントによって対応する局に割り当てられたチャネルリソースの開始サブチャネル番号を示し、且つ、５番目のビットから８番目のビットは、アクセスポイントによって対応する局に割り当てられたチャネルリソースの終了サブチャネル番号を示す。例えば、1バイトのサブチャネルインデックスフィールドは01100010である。対応する局は、示されたインデックス番号に従って、データテーブルから、１番目のビットから４番目のビット0010は、アクセスポイントによって対応する局に割り当てられたチャネルリソースの開始サブチャネル番号は2であることを示し、且つ、５番目のビットから８番目のビット0110は、アクセスポイントによって対応する局に割り当てられたチャネルリソースの終了サブチャネル番号は6であることを示すことがわかる。従って、1バイトのサブチャネルインデックスフィールド01100010は、２番目のサブチャネルから６番目のサブチャネルに対応するチャネルリソースが局に割り当てられることを示す。類推によって、アクセスポイントは、ダウンリンクデータフレームを受信する全ての局にチャネルリソースを割り当ててよく、その結果、複数の局は、割り当てられたチャネルリソースを使用することによって、確認メッセージをアクセスポイントに同時に返し、ここで、確認メッセージは、BlockAckであってよい。同様に、アクセスポイントは、マルチキャストによって、BlockAckReqを複数の局に送信する。アクセスポイントがチャネルリソースをm個の局に同時に割り当てる場合、アクセスポイントによってm個の局に割り当てられたチャネルリソースを示すために、Nは少なくともmバイトを含む必要があり、ここで、mは1よりも大きい正の整数である。
【００５４】
本発明の本実施形態で提供される方法によると、アクセスポイントは、対応するダウンリンクデータフレームを複数の局の各局に送信し、アクセスポイントは、アクセスポイントが対応するダウンリンクデータフレームを各局に送信した後、アクセスポイントによって複数の局に割り当てられたチャネルリソース上で、複数の局によって同時に送信される確認メッセージを受信し、このことは、確認メッセージをフィードバックするために複数の局によってかかる時間を低減することができる。加えて、アクセスポイントによって複数の局に割り当てられたチャネルリソース上で、複数の局によって、確認メッセージをアクセスポイントに同時に送信する方式はまた、チャネル利用を改善する。
【００５５】
図６は、本発明の実施形態に係る、無線ローカルエリアネットワークにおいて、複数の局によって、ダウンリンクデータフレームの送信を確認することのさらに別の概略図である。アクセスポイントは、複数の局の各局に、対応するダウンリンクデータフレームを送信し、且つ、ダウンリンクデータフレームに対応する局に割り当てられたチャネルリソースを識別するために使用される情報が、対応するダウンリンクデータフレームに追加される。対応するダウンリンクデータフレームを受信した後、局は、対応するダウンリンクデータフレームに含まれるチャネルリソース情報によって示されるチャネルリソースを解析する。この方式では、アクセスポイントは、複数の局の各局にチャネルリソースを割り当てることができ、且つ、複数の局は、ダウンリンクデータフレームが成功裏に受信されたかどうかをアクセスポイントに通知するために、アクセスポイントによって複数の局に割り当てられたチャネルリソースを使用することによって、確認メッセージをアクセスポイントに同時に送信することができ、ここで、確認メッセージはBlcokAckであってよい。具体的には、ダウンリンクデータフレームに対応する局に割り当てられたチャネルリソースを識別するために使用される情報は、サブチャネルインデックス（Sub-Channel-Index）フィールド（Field）である。
【００５６】
任意で、図７ａは、本発明の実施形態に係る、ダウンリンクデータフレームの物理層フレームフォーマットの概略図である。サブチャネルインデックスフィールドは、ダウンリンクデータフレームのPLCP Header（Physical Layer Convergence Procedure Header, 物理層収束プロシージャヘッダ）内に配置されてよい。ダウンリンクデータフレームの物理層フレームフォーマットは、PLCP Preamble（PLCPプリアンブル）フィールド、PLCP HeaderフィールドおよびData（データ）フィールドを含む。PLCP Preambleは、L-STF（Legacy Short Training Field, レガシーショートトレーニングフィールド）およびL-LTF（Legacy Long Training Field, レガシーロングトレーニングフィールド）を含む。PLCP Headerフィールドは、L-SIG（Legacy Signal, レガシー信号）フィールドを含む。IEEE 802.11ac標準に続く次世代WLAN（Wireless Local Area Network, 無線ローカルエリアネットワーク）技術標準IEEE 802.11axでは、PLCP Headerは、HEW SIG（High Efficiency WLAN Signal, 高効率WLAN信号）フィールドをさらに含んでよい。追加されたサブチャネルインデックスフィールドは、PLCP Headerフィールド内に配置されてよい。例えば、サブチャネルインデックスフィールドは、L-SIGフィールドに続くとともに、後ろにHEW SIGフィールドが続く位置にあってよい。あるいは、サブチャネルインデックスフィールドは、後ろにL-SIGフィールドが続く位置にあってよい。本発明の本実施形態は、それに限定を課さない。
【００５７】
任意で、図７bは、本発明の実施形態に係る、ダウンリンクデータフレームの物理層フレームフォーマットのさらに別の概略図を示す。サブチャネルインデックスフィールドは、PLCP HeaderのL-SIGフィールド内に配置されてよく、且つ、具体的には、サブチャネルインデックスフィールドは、L-SIGフィールドに追加される。あるいは、サブチャネルインデックスフィールドは、PLCPヘッダのHEW SIGフィールド内に配置されてよく、且つ、具体的には、サブチャネルインデックスフィールドは、HEW SIGフィールドに追加される。
【００５８】
図７ａおよび図７ｂは、ダウンリンクデータフレームの物理層フレームフォーマットの概略図であり、HEW SIGフィールドはL-SIGフィールドに続く位置にあってよく、または、HEW SIGフィールドは、後ろにL-SIGフィールドが続く位置にあってよいことは理解されることができる。本発明の本実施形態は、それに限定を課さない。確認メッセージを送信するために使用されるとともに、アクセスポイントによってダウンリンクデータフレームに対応する局に割り当てられるチャネルリソースを識別するために使用される情報は、ダウンリンクデータフレームの物理層フレームフォーマットのヘッダ内で搬送されてよく、または、ダウンリンクデータフレームのメディアアクセス制御（Media Access Control, 略してMAC）層フレームフォーマットのヘッダ内で搬送されてよく、この場合、情報を搬送する具体的な方式は、ダウンリンクデータフレームの物理層フレームフォーマットのヘッダ内に情報を配置する方式と同様であることは留意されるべきである。
【００５９】
具体的には、サブチャネルインデックスフィールドのバイト数はNである。Nは、実際のニーズに従って、バイト数に設定されてよい。例えば、Nは、局の数に従って、バイト数に設定されてよい。サブチャネルインデックスフィールドは、アクセスポイントによって局に割り当てられたチャネルリソースを示すために使用される。任意で、サブチャネルインデックスフィールドは、アクセスポイントによって対応する局に割り当てられたチャネルリソースを示すチャネルリソース情報を搬送してよい。例えば、Nは1バイト、すなわち、8バイナリビットであってよい。1バイトのサブチャネルインデックスフィールドは、0 MHzから20 MHzのチャネルリソースを8個のサブチャネルに分割し、ここで、各サブチャネルは2.5 MHzの幅を有する。8個のサブチャネルは、低周波から高周波へ順次1から8に番号付けされる。アクセスポイントがダウンリンクデータフレームに対応する局に５番目のサブチャネルを割り当てる場合、8個のバイナリビットの５番目のビットは1に設定されてよく、且つ、残りのバイナリビットは0に設定され、このことは、５番目のサブチャネルはダウンリンクデータフレームに対応する局に割り当てられ、且つ、局は５番目のサブチャネルを使用することによって、確認メッセージをフィードバックすることを示す。類推によって、アクセスポイントは、対応するダウンリンクデータフレームを受信する全ての局にチャネルリソースを割り当ててよく、その結果、対応するダウンリンクデータフレームを受信する局の全ては、割り当てられたチャネルリソースを使用することによって、確認メッセージをアクセスポイントに同時に返し、ここで、確認メッセージは、BlockAckであってよい。
【００６０】
任意で、サブチャネルインデックスフィールドはまた、インデックス番号を示すために使用されてもよい。局は、インデックス番号に従って、サーバから、または局のローカルデータテーブルから、局に割り当てられたチャネルリソースを見つけてよい。サブチャネルインデックスフィールドは、ダウンリンクデータフレームに含まれるチャネルリソース情報であり、ここで、チャネルリソース情報は、インデックス番号を示すために使用され、その結果、局は、インデックス番号に従って、サーバから、または局のローカルデータテーブルから、局に割り当てられたチャネルリソースを見つけることができる。例えば、0 MHzから40 MHzのチャネルリソースは16個のサブチャネルに分割され、ここで、各サブチャネルは2.5 MHzの幅を有する。16個のサブチャネルは、低周波から高周波へ順次1から16に番号付けされる。Nは1バイト、すなわち、8バイナリビットであってよい。8バイナリビットの１番目のビットから４番目のビットは、アクセスポイントによって対応する局に割り当てられたチャネルリソースの開始サブチャネル番号を示し、且つ、５番目のビットから８番目のビットは、アクセスポイントによって対応する局に割り当てられたチャネルリソースの終了サブチャネル番号を示す。例えば、1バイトのサブチャネルインデックスフィールドは01100010である。対応する局は、示されたインデックス番号に従って、データテーブルから、１番目のビットから４番目のビット0010は、アクセスポイントによって対応する局に割り当てられたチャネルリソースの開始サブチャネル番号は2であることを示し、且つ、５番目のビットから８番目のビット0110は、アクセスポイントによって対応する局に割り当てられたチャネルリソースの終了サブチャネル番号は6であることを示すことがわかる。従って、1バイトのサブチャネルインデックスフィールド01100010は、２番目のサブチャネルから６番目のサブチャネルに対応するチャネルリソースが局に割り当てられることを示す。類推によって、アクセスポイントは、ダウンリンクデータフレームを受信する全ての局にチャネルリソースを割り当ててよく、その結果、ダウンリンクデータフレームを受信する局は、割り当てられたチャネルリソースを使用することによって、確認メッセージをアクセスポイントに同時に返し、ここで、確認メッセージは、BlockAckであってよい。
【００６１】
本発明の本実施形態で提供される方法によると、アクセスポイントは、対応するダウンリンクデータフレームを複数の局の各局に送信し、アクセスポイントは、アクセスポイントが対応するダウンリンクデータフレームを各局に送信した後、アクセスポイントによって複数の局に割り当てられたチャネルリソース上で、複数の局によって同時に送信される確認メッセージを受信し、このことは、確認メッセージをフィードバックするために複数の局によってかかる時間を低減することができる。加えて、アクセスポイントによって複数の局に割り当てられたチャネルリソース上で、複数の局によって、確認メッセージをアクセスポイントに同時に送信する方式はまた、チャネル利用を改善する。
【００６２】
例えば、IEEE 802.11nでは、IEEE 802.11n内の動作周波数帯範囲は2.4 GHzから2.4835 GHzおよび5.150 GHzから5.850 GHzを含むことは理解されるべきである。0 MHzから20 MHzのチャネルリソースまたは0 MHzから40 MHzのチャネルリソースは、2.4 GHz から始まる、または、5.150 GHz から始まる20 MHzまたは40 MHzの周波数帯域を有するチャネルリソースを参照する。
【００６３】
上述では、アクセスポイントの観点から、本発明の実施形態に係る、無線ローカルエリアネットワークにおいて、複数の局によってダウンリンクデータフレームの送信を確認するための方法を説明した。以下では、局の観点から、本発明の実施形態に係る方法を説明する。
【００６４】
図８は、本発明の実施形態に係る、無線ローカルエリアネットワークにおいて、局によって、ダウンリンクデータフレームの送信を確認するための方法の概略図を示す。方法８００は、局によって実行されてよい。方法８００は以下のステップを含む：
【００６５】
Ｓ８０２：局は、アクセスポイントによって送信されるダウンリンクデータフレームを受信する。
【００６６】
Ｓ８０４：局がアクセスポイントによって送信されるダウンリンクデータフレームを受信した後、局は、アクセスポイントによって局に割り当てられたチャネルリソース上で、アクセスポイントに確認メッセージを送信する。
【００６７】
アクセスポイントが局にチャネルリソースを割り当てることは、異なる方式で実施されてよい。アクセスポイントは、局に送信される確認要求メッセージにチャネルリソース情報を追加してよく、ここで、チャネルリソース情報は、アクセスポイントによって局に割り当てられたチャネルリソースを示すために使用され、または、アクセスポイントは、局に送信されるダウンリンクデータフレームにチャネルリソース情報を追加してよく、ここで、チャネルリソース情報は、アクセスポイントによって、局に割り当てられたチャネルリソースを示すために使用される。局は、ダウンリンクデータフレームが成功裏に受信されたかどうかをアクセスポイントに通知するために、アクセスポイントによって割り当てられるとともにチャネルリソース情報によって示されるチャネルリソースを使用することによって、確認メッセージをアクセスポイントに送信する。
【００６８】
本発明の本実施形態で提供される方法によると、局は、アクセスポイントによって送信されるダウンリンクデータフレームを受信し、局が、アクセスポイントによって送信されたダウンリンクデータフレームを受信した後、局は、アクセスポイントによって局に割り当てられたチャネルリソース上で確認メッセージをアクセスポイントに送信する。この方式では、アクセスポイントと局とがチャネルリソースの使用のために争うのではなく、アクセスポイントが、チャネルリソースを局に割り当て、このことは、チャネル利用を改善することができる。加えて、複数の局がある場合、複数の局は、アクセスポイントによって複数の局に割り当てられたチャネルリソース上で、確認メッセージをアクセスポイントに同時に送信し、且つ、この方式は、確認メッセージをフィードバックするために必要とされる時間を低減することができる。
【００６９】
図４は、本発明の実施形態に係る、無線ローカルエリアネットワークにおいて、複数の局によって、ダウンリンクデータフレームの送信を確認することの概略図を示す。複数の局がアクセスポイントによって送信されるダウンリンクデータフレームを受信した後、複数の局が、アクセスポイントによって複数の局に割り当てられたチャネルリソース上で、アクセスポイントに確認メッセージを同時に送信する前に、方法は、
事前に設定された時間の後、局によって、アクセスポイントによって送信される確認要求メッセージを受信するステップであって、ここで、確認要求メッセージはチャネルリソース情報を含み、且つ、チャネルリソース情報は、アクセスポイントによって局に割り当てられたチャネルリソースを示すために使用される、ステップをさらに含む。
【００７０】
事前に設定された時間は、SIFSであってよい。SIFSの値は、異なるIEEE 802.11標準において異なってよい。例えば、IEEE 802.11a標準では、SIFSの値は16μsであり、且つ、IEEE 802.11g標準では、SIFSの値は10 μsである。
【００７１】
具体的には、確認要求メッセージは、ブロック確認要求メッセージBlockAckReqであってよく、且つ、ブロック確認要求メッセージBlockAckReqは、アクセスポイントによって複数の局に割り当てられたチャネルリソースを示すチャネルリソース情報を含む。アクセスポイントが複数の局の各局にダウンリンクデータフレームを送信した後、アクセスポイントは、複数の局によって同時に送信される確認メッセージを受信し、ここで、複数の局は、ブロック確認要求メッセージBlockAckReqに含まれるチャネルリソース情報によって示されるチャネルリソースを使用することによって、アクセスポイントに確認メッセージを同時に送信する。
【００７２】
図５は、本発明の実施形態に係る、BlockAckReqのフレームフォーマットの概略図を示す。具体的な実施方式については、無線ローカルエリアネットワークにおいて、複数の局によって、ダウンリンクデータフレームの送信を確認するための方法の前述の実施形態における、アクセスポイントの観点からの、BlockAckReqの説明を参照されたい。
【００７３】
図６は、本発明の実施形態に係る、無線ローカルエリアネットワークにおいて、複数の局によって、ダウンリンクデータフレームの送信を確認することのさらに別の概略図である。アクセスポイントは、複数の局の各局に、対応するダウンリンクデータフレームを送信し、且つ、ダウンリンクデータフレームに対応する局に割り当てられたチャネルリソースを識別するために使用される情報が、対応するダウンリンクデータフレームに追加される。対応するダウンリンクデータフレームを受信した後、局は、対応するダウンリンクデータフレームに含まれるチャネルリソース情報によって示されるチャネルリソースを解析する。この方式では、アクセスポイントは、複数の局の各局にチャネルリソースを割り当てることができ、且つ、複数の局は、ダウンリンクデータフレームが成功裏に受信されたかどうかをアクセスポイントに通知するために、アクセスポイントによって複数の局に割り当てられたチャネルリソースを使用することによって、確認メッセージをアクセスポイントに同時に送信することができ、ここで、確認メッセージはBlcokAckであってよい。具体的には、ダウンリンクデータフレームに対応する局に割り当てられたチャネルリソースを識別するために使用される情報は、サブチャネルインデックス（Sub-Channel-Index）フィールドである。
【００７４】
図７ａは、本発明の実施形態に係る、ダウンリンクデータフレームの物理層フレームフォーマットの概略図であり、且つ、図７ｂは、本発明の実施形態に係る、ダウンリンクデータフレームの物理層フレームフォーマットのさらに別の概略図である。具体的な実施方式については、無線ローカルエリアネットワークにおいて、複数の局によって、ダウンリンクデータフレームの送信を確認するための方法の前述の実施形態における、アクセスポイントの観点からの、ダウンリンクデータフレームの物理層フレームフォーマットの説明を参照されたい。
【００７５】
本発明の本実施形態で提供される方法によると、局は、アクセスポイントによって送信されるダウンリンクデータフレームを受信し、局が、アクセスポイントによって送信されたダウンリンクデータフレームを受信した後、局は、アクセスポイントによって局に割り当てられたチャネルリソース上で確認メッセージをアクセスポイントに送信する。この方式では、アクセスポイントと局とがチャネルリソースの使用のために争うのではなく、アクセスポイントが、チャネルリソースを局に割り当て、このことは、チャネル利用を改善することができる。加えて、複数の局がある場合、複数の局は、アクセスポイントによって複数の局に割り当てられたチャネルリソース上で、確認メッセージをアクセスポイントに同時に送信し、且つ、この方式は、確認をフィードバックするために必要とされる時間を低減することができる。
【００７６】
図９は、本発明の実施形態に係る、アクセスポイント９００の概略図を示す。アクセスポイント９００は、トランシーバ９０２、プロセッサ９０４およびバス９０６を含み、ここで、
トランシーバ９０２およびプロセッサ９０４は、バス９０６を使用することによって通信を実施し、
トランシーバ９０２は、プロセッサ９０４の制御下で、対応するダウンリンクデータフレームを複数の局の各局に送信し、
トランシーバ９０２は、ダウンリンクデータフレームを複数の局に送信した後、アクセスポイントによって複数の局に割り当てられたチャネルリソース上で、複数の局によって同時に送信される確認メッセージを受信するように構成される。
【００７７】
アクセスポイントが複数の局の各局にチャネルリソースを割り当てることは、異なる方式で実施されてよい。アクセスポイントは、複数の局に送信される確認要求メッセージにチャネルリソース情報を追加してよく、ここで、チャネルリソース情報は、アクセスポイントによって複数の局の各局に割り当てられたチャネルリソースを示すために使用され、または、アクセスポイントは、複数の局の各局に送信される対応するダウンリンクデータフレームにチャネルリソース情報を追加してよく、ここで、チャネルリソース情報は、アクセスポイントによって、対応するダウンリンクデータフレームを受信する局に割り当てられたチャネルリソースを示すために使用される。複数の局は、ダウンリンクデータフレームが成功裏に受信されたかどうかをアクセスポイントに通知するために、OFDMA技術を使用して、アクセスポイントによって割り当てられるとともにチャネルリソース情報によって示されるチャネルリソースを使用することによって、確認メッセージをアクセスポイントに同時に送信してよい。アクセスポイントは、ラップトップコンピュータ、ルータ、セットトップボックスまたは携帯電話のうちの1つであってよい。
【００７８】
本発明の本実施形態で提供されるアクセスポイントは、トランシーバ９０２、プロセッサ９０４およびバス９０６を含み、トランシーバ９０２およびプロセッサ９０４は、バス９０６を使用することによって通信を実施し、トランシーバ９０２は、プロセッサ９０４の制御下で、対応するダウンリンクデータフレームを複数の局の各局に送信し、トランシーバ９０２は、ダウンリンクデータフレームを複数の局に送信した後、アクセスポイントによって複数の局に割り当てられたチャネルリソース上で、複数の局によって同時に送信される確認メッセージを受信するように構成され、このことは、確認メッセージをフィードバックするために複数の局によってかかる時間を低減することができる。加えて、アクセスポイントによって複数の局に割り当てられたチャネルリソース上で、複数の局によって、確認メッセージをアクセスポイントに同時に送信する方式はまた、チャネル利用を改善する。
【００７９】
図４は、本発明の実施形態に係る、無線ローカルエリアネットワークにおいて、複数の局によって、ダウンリンクデータフレームの送信を確認することの概略図を示す。トランシーバ９０２は、複数の局に確認要求メッセージを送信するように構成され、ここで、確認要求メッセージは、チャネルリソース情報を含み、且つ、チャネルリソース情報は、アクセスポイントによって複数の局に割り当てられたチャネルリソースを示すために使用される。
【００８０】
ダウンリンクデータフレームを複数の局に送信した後、トランシーバ９０２は、事前に設定された時間の後、確認要求メッセージを複数の局に送信してよい。事前に設定された時間は、SIFSであってよい。SIFSの値は、異なるIEEE 802.11標準において異なってよい。例えば、IEEE 802.11a標準では、SIFSの値は16μsであり、且つ、IEEE 802.11g標準では、SIFSの値は10 μsである。
【００８１】
具体的には、確認要求メッセージは、ブロック確認要求メッセージBlockAckReqであってよく、且つ、ブロック確認要求メッセージBlockAckReqは、アクセスポイントによって複数の局に割り当てられたチャネルリソースを示すチャネルリソース情報を含む。アクセスポイントが複数の局の各局にダウンリンクデータフレームを送信した後、アクセスポイントは、複数の局によって同時に送信される確認メッセージを受信し、ここで、複数の局は、ブロック確認要求メッセージBlockAckReqに含まれるチャネルリソース情報によって示されるチャネルリソースを使用することによって、アクセスポイントに確認メッセージを同時に送信する。
【００８２】
図５は、本発明の実施形態に係る、BlockAckReqのフレームフォーマットの概略図を示す。具体的な実施方式については、無線ローカルエリアネットワークにおいて、複数の局によって、ダウンリンクデータフレームの送信を確認するための方法の前述の実施形態における、アクセスポイントの観点からの、BlockAckReqの説明を参照されたい。
【００８３】
図６は、本発明の実施形態に係る、無線ローカルエリアネットワークにおいて、複数の局によって、ダウンリンクデータフレームの送信を確認することのさらに別の概略図である。アクセスポイントは、複数の局の各局に、対応するダウンリンクデータフレームを送信し、且つ、ダウンリンクデータフレームに対応する局に割り当てられたチャネルリソースを識別するために使用される情報が、対応するダウンリンクデータフレームに追加される。対応するダウンリンクデータフレームを受信した後、局は、対応するダウンリンクデータフレームに含まれるチャネルリソース情報によって示されるチャネルリソースを解析する。この方式では、アクセスポイントは、複数の局の各局にチャネルリソースを割り当てることができ、且つ、複数の局は、ダウンリンクデータフレームが成功裏に受信されたかどうかをアクセスポイントに通知するために、アクセスポイントによって複数の局に割り当てられたチャネルリソースを使用することによって、確認メッセージをアクセスポイントに同時に送信することができ、ここで、確認メッセージはBlcokAckであってよい。具体的には、ダウンリンクデータフレームに対応する局に割り当てられたチャネルリソースを識別するために使用される情報は、サブチャネルインデックス（Sub-Channel-Index）フィールドである。
【００８４】
図７ａは、本発明の実施形態に係る、ダウンリンクデータフレームの物理層フレームフォーマットの概略図であり、且つ、図７ｂは、本発明の実施形態に係る、ダウンリンクデータフレームの物理層フレームフォーマットのさらに別の概略図である。具体的な実施方式については、無線ローカルエリアネットワークにおいて、複数の局によって、ダウンリンクデータフレームの送信を確認するための方法の前述の実施形態における、アクセスポイントの観点からの、ダウンリンクデータフレームの物理層フレームフォーマットの説明を参照されたい。
【００８５】
図１０は、本発明の実施形態に係る、局１０００の概略図を示す。局１０００は、トランシーバ１００２、プロセッサ１００４およびバス１００６を含み、ここで、
トランシーバ１００２およびプロセッサ１００４は、バス１００６を使用することによって通信を実施し、
トランシーバ１００２は、アクセスポイントによって送信されるダウンリンクデータフレームを受信し、
トランシーバ１００２は、プロセッサ１００４の制御下で、アクセスポイントによって送信されるダウンリンクデータフレームを受信した後、アクセスポイントによって局に割り当てられたチャネルリソース上で、確認メッセージをアクセスポイントに送信するように構成される。
【００８６】
アクセスポイントが局にチャネルリソースを割り当てることは、異なる方式で実施されてよい。アクセスポイントは、局に送信される確認要求メッセージにチャネルリソース情報を追加してよく、ここで、チャネルリソース情報は、アクセスポイントによって局に割り当てられたチャネルリソースを示すために使用され、または、アクセスポイントは、局に送信されるダウンリンクデータフレームにチャネルリソース情報を追加してよく、ここで、チャネルリソース情報は、アクセスポイントによって、局に割り当てられたチャネルリソースを示すために使用される。局は、ダウンリンクデータフレームが成功裏に受信されたかどうかをアクセスポイントに通知するために、アクセスポイントによって割り当てられるとともにチャネルリソース情報によって示されるチャネルリソースを使用することによって、確認メッセージをアクセスポイントに送信する。局は、ラップトップコンピュータ、ルータ、セットトップボックスまたは携帯電話のうちの1つであってよい。
【００８７】
本発明の本実施形態で提供される局は、トランシーバ１００２、プロセッサ１００４およびバス１００６を含み、トランシーバ１００２およびプロセッサ１００４は、バス１００６を使用することによって通信を実施し、トランシーバ１００２は、アクセスポイントによって送信されるダウンリンクデータフレームを受信し、トランシーバ１００２は、プロセッサ１００４の制御下で、アクセスポイントによって送信されるダウンリンクデータフレームを受信した後、アクセスポイントによって局に割り当てられたチャネルリソース上で、確認メッセージをアクセスポイントに送信するように構成される。この方式では、アクセスポイントと局とがチャネルリソースの使用のために争うのではなく、アクセスポイントが、チャネルリソースを局に割り当て、このことは、チャネル利用を改善することができる。加えて、複数の局がある場合、複数の局は、アクセスポイントによって複数の局に割り当てられたチャネルリソース上で、確認メッセージをアクセスポイントに同時に送信し、且つ、この方式は、確認をフィードバックするために必要とされる時間を低減することができる。
【００８８】
図４は、本発明の実施形態に係る、無線ローカルエリアネットワークにおいて、複数の局によって、ダウンリンクデータフレームの送信を確認することの概略図を示す。トランシーバ１００２は、アクセスポイントによって送信される確認要求メッセージを受信するように構成され、ここで、確認要求メッセージは、チャネルリソース情報を含み、且つ、チャネルリソース情報は、アクセスポイントによって複数の局に割り当てられたチャネルリソースを示すために使用される。
【００８９】
アクセスポイントによって送信されるデータを受信した後、トランシーバ１００２は、事前に設定された時間の後、アクセスポイントによって送信される確認要求メッセージを受信してよい。事前に設定された時間は、SIFSであってよい。SIFSの値は、異なるIEEE 802.11標準において異なってよい。例えば、IEEE 802.11a標準では、SIFSの値は16μsであり、且つ、IEEE 802.11g標準では、SIFSの値は10μsである。
【００９０】
具体的には、確認要求メッセージは、ブロック確認要求メッセージBlockAckReqであってよく、且つ、ブロック確認要求メッセージBlockAckReqは、アクセスポイントによって複数の局に割り当てられたチャネルリソースを示すチャネルリソース情報を含む。アクセスポイントが複数の局の各局にダウンリンクデータフレームを送信した後、アクセスポイントは、複数の局によって同時に送信される確認メッセージを受信し、ここで、複数の局は、ブロック確認要求メッセージBlockAckReqに含まれるチャネルリソース情報によって示されるチャネルリソースを使用することによって、アクセスポイントに確認メッセージを同時に送信する。
【００９１】
図５は、本発明の実施形態に係る、BlockAckReqのフレームフォーマットの概略図を示す。具体的な実施方式については、無線ローカルエリアネットワークにおいて、複数の局によって、ダウンリンクデータフレームの送信を確認するための方法の前述の実施形態における、アクセスポイントの観点からの、BlockAckReqの説明を参照されたい。
【００９２】
図６は、本発明の実施形態に係る、無線ローカルエリアネットワークにおいて、複数の局によって、ダウンリンクデータフレームの送信を確認することのさらに別の概略図である。アクセスポイントは、複数の局の各局に、対応するダウンリンクデータフレームを送信し、且つ、ダウンリンクデータフレームに対応する局に割り当てられたチャネルリソースを識別するために使用される情報が、対応するダウンリンクデータフレームに追加される。対応するダウンリンクデータフレームを受信した後、局は、対応するダウンリンクデータフレームに含まれるチャネルリソース情報によって示されるチャネルリソースを解析する。この方式では、アクセスポイントは、複数の局の各局にチャネルリソースを割り当てることができ、且つ、複数の局は、ダウンリンクデータフレームが成功裏に受信されたかどうかをアクセスポイントに通知するために、アクセスポイントによって複数の局に割り当てられたチャネルリソースを使用することによって、確認メッセージをアクセスポイントに同時に送信することができ、ここで、確認メッセージはBlcokAckであってよい。具体的には、ダウンリンクデータフレームに対応する局に割り当てられたチャネルリソースを識別するために使用される情報は、サブチャネルインデックス（Sub-Channel-Index）フィールドである。
【００９３】
図７ａは、本発明の実施形態に係る、ダウンリンクデータフレームの物理層フレームフォーマットの概略図であり、且つ、図７ｂは、本発明の実施形態に係る、ダウンリンクデータフレームの物理層フレームフォーマットのさらに別の概略図である。具体的な実施方式については、無線ローカルエリアネットワークにおいて、複数の局によって、ダウンリンクデータフレームの送信を確認するための方法の前述の実施形態における、アクセスポイントの観点からの、ダウンリンクデータフレームの物理層フレームフォーマットの説明を参照されたい。
【００９４】
当業者は、前述のプロセッサ（９０４および１００４）は、汎用の中央処理装置（Central Processing Unit, CPU）、マイクロプロセッサ、特定用途向け集積回路（Application Specific Integrated Circuit, ASIC）またはベースバンドプロセッサを使用してよいことを理解することができる。バス（９０６および１００６）は、プロセッサとトランシーバとの間の通信を実施するように構成されたパスを含んでよい。トランシーバはアンテナであってよい。
【００９５】
前述の実施形態におけるアクセスポイントおよび局はまた、スマートフォン等の１つの携帯電話であってもよいことは理解されることができる。スマートフォンは、アクセスポイントの機能を有するだけでなく、局の機能も有する。この場合、スマートフォンは、別の携帯電話等の、別の局と通信するためにアクセスポイントとして役目を果たしてよい。スマートフォンはまた、別の携帯電話などの、アクセスポイントと通信するために局として役目を果たしてもよい。
【００９６】
最後に、前述の実施形態は単に、本発明を限定する他に、本発明の技術的解決手段を例示的に説明するために意図されていることは留意されるべきである。本発明および本発明の利益は、前述の実施形態を参照して詳細に記載されているが、当業者は、彼らが、本発明の請求項の範囲から逸脱することなく、前述の実施形態で説明された技術的解決手段に対して修正をさらに行うことができ、または、それらのいくつかの技術的特徴に対して均等置換をさらに行うことができることを理解するべきである。
【符号の説明】
【００９７】
902  トランシーバ
904  プロセッサ
906  バス
1002  メモリ
1004  プロセッサ
1006  バス
【図１】
2017529774.tif 000003
【図２】
2017529774.tif 000004
【図３】
2017529774.tif 000005
【図４】
2017529774.tif 000006
【図５】
2017529774.tif 000007
【図６】
2017529774.tif 000008
【図７ａ】
2017529774.tif 000009
【図７ｂ】
2017529774.tif 000010
【図８】
2017529774.tif 000011
【図９】
2017529774.tif 000012
【図１０】
2017529774.tif 000013
【手続補正書】
【提出日】平成29年3月7日(2017.3.7)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
無線ローカルエリアネットワークにおいて、複数の局によって、ダウンリンクデータフレームの送信を確認するための方法であって、前記方法は、
アクセスポイントによって、対応するダウンリンクデータフレームを前記複数の局の各局に送信するステップと、
前記アクセスポイントが前記対応するダウンリンクデータフレームを各局に送信した後、前記アクセスポイントによって、前記アクセスポイントによって前記複数の局に割り当てられたチャネルリソース上で、前記複数の局によって同時に送信される確認メッセージを受信するステップとを含む方法。
【請求項２】
前記ダウンリンクデータフレームは、前記ダウンリンクデータフレームに対応する局に割り当てられたチャネルリソースを識別するために使用される情報を含む、請求項１に記載の方法。
【請求項３】
前記情報は、前記ダウンリンクデータフレームの物理フレーム収束プロシージャヘッダ（PLCP Header）内に配置される、請求項２に記載の方法。
【請求項４】
無線ローカルエリアネットワークにおいて、局によってダウンリンクデータフレームの送信を確認するための方法であって、前記方法は、
前記局によって、アクセスポイントによって送信されるダウンリンクデータフレームを受信するステップと、
前記局が前記アクセスポイントによって送信される前記ダウンリンクデータフレームを受信した後、前記局によって、前記アクセスポイントによって前記局に割り当てられたチャネルリソース上で、前記アクセスポイントに確認メッセージを送信するステップとを含む、方法。
【請求項５】
前記ダウンリンクデータフレームは、前記アクセスポイントによって前記局に割り当てられた前記チャネルリソースを識別するために使用される情報を含む、請求項４に記載の方法。
【請求項６】
前記情報は、前記ダウンリンクデータフレームの物理フレーム収束プロシージャヘッダ（PLCP Header）内に配置される、請求項５に記載の方法。
【請求項７】
トランシーバ、プロセッサおよびバスを含むアクセスポイントであって、
前記トランシーバおよび前記プロセッサは、前記バスを使用することによって通信を実施し、
前記トランシーバは、前記プロセッサの制御下で、対応するダウンリンクデータフレームを複数の局の各局に送信し、
前記トランシーバは、前記ダウンリンクデータフレームを各局に送信した後、前記アクセスポイントによって前記複数の局に割り当てられたチャネルリソース上で、前記複数の局によって同時に送信される確認メッセージを受信するように構成される、アクセスポイント。
【請求項８】
前記ダウンリンクデータフレームは、前記ダウンリンクデータフレームに対応する局に割り当てられたチャネルリソースを識別するために使用される情報を含む、請求項７に記載のアクセスポイント。
【請求項９】
前記情報は、前記ダウンリンクデータフレームの物理フレーム収束プロシージャヘッダ（PLCP Header）内に配置される、請求項８に記載のアクセスポイント。
【請求項１０】
前記アクセスポイントは、ラップトップコンピュータ、ルータ、セットトップボックスまたは携帯電話のうちの１つである、請求項７乃至９のうちのいずれか１項に記載のアクセスポイント。
【請求項１１】
トランシーバ、プロセッサおよびバスを含む局であって、
前記トランシーバおよび前記プロセッサは、前記バスを使用することによって通信を実施し、
前記トランシーバは、アクセスポイントによって送信されるダウンリンクデータフレームを受信し、
前記トランシーバは、前記アクセスポイントによって送信される前記ダウンリンクデータフレームを受信した後、前記プロセッサの制御下で、前記アクセスポイントによって前記局に割り当てられたチャネルリソース上で、前記アクセスポイントに確認メッセージを送信するように構成される、局。
【請求項１２】
前記ダウンリンクデータフレームは、前記アクセスポイントによって前記局に割り当てられた前記チャネルリソースを識別するために使用される情報を含む、請求項１１に記載の局。
【請求項１３】
前記情報は、前記ダウンリンクデータフレームの物理フレーム収束プロシージャヘッダ（PLCP Header）内に配置される、請求項１２に記載の局。
【請求項１４】
前記局は、ラップトップコンピュータ、ルータ、セットトップボックスまたは携帯電話のうちの１つである、請求項１１乃至１３のうちのいずれか１項に記載の局。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】００５５
【補正方法】変更
【補正の内容】
【００５５】
図６は、本発明の実施形態に係る、無線ローカルエリアネットワークにおいて、複数の局によって、ダウンリンクデータフレームの送信を確認することのさらに別の概略図である。アクセスポイントは、複数の局の各局に、対応するダウンリンクデータフレームを送信し、且つ、ダウンリンクデータフレームに対応する局に割り当てられたチャネルリソースを識別するために使用される情報が、対応するダウンリンクデータフレームに追加される。対応するダウンリンクデータフレームを受信した後、局は、対応するダウンリンクデータフレームに含まれるチャネルリソース情報によって示されるチャネルリソースを解析する。この方式では、アクセスポイントは、複数の局の各局にチャネルリソースを割り当てることができ、且つ、複数の局は、ダウンリンクデータフレームが成功裏に受信されたかどうかをアクセスポイントに通知するために、アクセスポイントによって複数の局に割り当てられたチャネルリソースを使用することによって、確認メッセージをアクセスポイントに同時に送信することができ、ここで、確認メッセージはBlockAckであってよい。具体的には、ダウンリンクデータフレームに対応する局に割り当てられたチャネルリソースを識別するために使用される情報は、サブチャネルインデックス（Sub-Channel-Index）フィールド（Field）である。
【手続補正３】
【補正対象書類名】明細書
【補正対象項目名】００７３
【補正方法】変更
【補正の内容】
【００７３】
図６は、本発明の実施形態に係る、無線ローカルエリアネットワークにおいて、複数の局によって、ダウンリンクデータフレームの送信を確認することのさらに別の概略図である。アクセスポイントは、複数の局の各局に、対応するダウンリンクデータフレームを送信し、且つ、ダウンリンクデータフレームに対応する局に割り当てられたチャネルリソースを識別するために使用される情報が、対応するダウンリンクデータフレームに追加される。対応するダウンリンクデータフレームを受信した後、局は、対応するダウンリンクデータフレームに含まれるチャネルリソース情報によって示されるチャネルリソースを解析する。この方式では、アクセスポイントは、複数の局の各局にチャネルリソースを割り当てることができ、且つ、複数の局は、ダウンリンクデータフレームが成功裏に受信されたかどうかをアクセスポイントに通知するために、アクセスポイントによって複数の局に割り当てられたチャネルリソースを使用することによって、確認メッセージをアクセスポイントに同時に送信することができ、ここで、確認メッセージはBlockAckであってよい。具体的には、ダウンリンクデータフレームに対応する局に割り当てられたチャネルリソースを識別するために使用される情報は、サブチャネルインデックス（Sub-Channel-Index）フィールドである。
【手続補正４】
【補正対象書類名】明細書
【補正対象項目名】００８３
【補正方法】変更
【補正の内容】
【００８３】
図６は、本発明の実施形態に係る、無線ローカルエリアネットワークにおいて、複数の局によって、ダウンリンクデータフレームの送信を確認することのさらに別の概略図である。アクセスポイントは、複数の局の各局に、対応するダウンリンクデータフレームを送信し、且つ、ダウンリンクデータフレームに対応する局に割り当てられたチャネルリソースを識別するために使用される情報が、対応するダウンリンクデータフレームに追加される。対応するダウンリンクデータフレームを受信した後、局は、対応するダウンリンクデータフレームに含まれるチャネルリソース情報によって示されるチャネルリソースを解析する。この方式では、アクセスポイントは、複数の局の各局にチャネルリソースを割り当てることができ、且つ、複数の局は、ダウンリンクデータフレームが成功裏に受信されたかどうかをアクセスポイントに通知するために、アクセスポイントによって複数の局に割り当てられたチャネルリソースを使用することによって、確認メッセージをアクセスポイントに同時に送信することができ、ここで、確認メッセージはBlockAckであってよい。具体的には、ダウンリンクデータフレームに対応する局に割り当てられたチャネルリソースを識別するために使用される情報は、サブチャネルインデックス（Sub-Channel-Index）フィールドである。
【手続補正５】
【補正対象書類名】明細書
【補正対象項目名】００９２
【補正方法】変更
【補正の内容】
【００９２】
図６は、本発明の実施形態に係る、無線ローカルエリアネットワークにおいて、複数の局によって、ダウンリンクデータフレームの送信を確認することのさらに別の概略図である。アクセスポイントは、複数の局の各局に、対応するダウンリンクデータフレームを送信し、且つ、ダウンリンクデータフレームに対応する局に割り当てられたチャネルリソースを識別するために使用される情報が、対応するダウンリンクデータフレームに追加される。対応するダウンリンクデータフレームを受信した後、局は、対応するダウンリンクデータフレームに含まれるチャネルリソース情報によって示されるチャネルリソースを解析する。この方式では、アクセスポイントは、複数の局の各局にチャネルリソースを割り当てることができ、且つ、複数の局は、ダウンリンクデータフレームが成功裏に受信されたかどうかをアクセスポイントに通知するために、アクセスポイントによって複数の局に割り当てられたチャネルリソースを使用することによって、確認メッセージをアクセスポイントに同時に送信することができ、ここで、確認メッセージはBlockAckであってよい。具体的には、ダウンリンクデータフレームに対応する局に割り当てられたチャネルリソースを識別するために使用される情報は、サブチャネルインデックス（Sub-Channel-Index）フィールドである。
【国際調査報告】
2017529774.tif 000014
2017529774.tif 000015
2017529774.tif 000016
2017529774.tif 000017