JP2008509622A - Ackフレーム伝送方法及び装置 - Google Patents

Ackフレーム伝送方法及び装置 Download PDF

Info

Publication number
JP2008509622A
JP2008509622A JP2007525531A JP2007525531A JP2008509622A JP 2008509622 A JP2008509622 A JP 2008509622A JP 2007525531 A JP2007525531 A JP 2007525531A JP 2007525531 A JP2007525531 A JP 2007525531A JP 2008509622 A JP2008509622 A JP 2008509622A
Authority
JP
Japan
Prior art keywords
frame
bit
ack
ack frame
received
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
JP2007525531A
Other languages
English (en)
Inventor
ホン,ジン−ウ
シン,セ−ヨン
ベー,デ−ギュ
ソン,ヒョン−ア
グォン,チャン−ヨル
チョウ,ギョン−イク
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Samsung Electronics Co Ltd
Original Assignee
Samsung Electronics Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from KR1020040063599A external-priority patent/KR100631736B1/ko
Priority claimed from KR1020040094099A external-priority patent/KR100631742B1/ko
Application filed by Samsung Electronics Co Ltd filed Critical Samsung Electronics Co Ltd
Publication of JP2008509622A publication Critical patent/JP2008509622A/ja
Withdrawn legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/1607Details of the supervisory signal
    • H04L1/1614Details of the supervisory signal using bitmaps
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/1607Details of the supervisory signal
    • H04L1/1635Cumulative acknowledgement, i.e. the acknowledgement message applying to all previous messages

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Communication Control (AREA)
  • Detection And Prevention Of Errors In Transmission (AREA)
  • Small-Scale Networks (AREA)

Abstract

本発明は、無線環境での通信でより効率的なバーストACK方法及び装置に関する。
本発明によるACKフレーム伝送方法は、送信デバイスからフレームを受信し、該受信されたフレームの識別情報を保存する段階と、前記保存された識別情報を用いて前記受信された各フレームに対するビット対の集合を記録して第1フィールドを生成させる段階と、生成された第1フィールドを含んでACKフレームを生成させる段階と、生成されたACKフレームを送信デバイスに伝送する段階とを含み、前記ビット対は、該当フレームが正常的に受信されたか否かを確認する第1ビットと、第1ビットが該当フレーム一つに対する受信確認を表わすものなのか、該当フレーム以後のすべてのフラグメントに対する受信確認を表わすものなのかを区別する第2ビットとで構成される。

Description

本発明は、無線通信方法に係り、より詳細には、より効率的なバーストACK(burst ACK)を利用した無線通信方法に関する。
ネットワークが無線化されていて大容量のマルチメディアデータ伝送要求の増大によって無線ネットワーク環境での効果的な伝送法についての研究が要求されている。与えられた無線資源を多くのデバイスが共有して使う無線ネットワークの特性上、競争が増加すれば通信中に衝突によって貴重な無線資源を浪費する可能性が大きい。このような衝突を減らして安定的にデータを送受信させるために、無線LAN(wireless Local Area Network)環境では競争基盤のDCF(Distributed Coordination Function)または無競争方式のPCF(Point Coordination Function)を使っており、無線PAN(wireless Personal Area Network)環境ではチャンネル時間割当て(channel time allocation)という時分割方式を使っている。
このような方法にして、無線環境で衝突なしに安定的にデータを送受信できるが、一つのデバイスが通信する間には同じ電波範囲内に存在する他のデバイスは待機するしかないので、デバイスの数が増えれば伝送率は相当減少する。したがって、無線ネットワーク環境で安定的な通信を保障しながらも同時にデータ伝送率を向上させることが重要な争点になっている。
伝送率を向上させるためには、主に伝送するデータから不要なオーバーヘッドを減らす方法、またはデバイスの間に時間割当てをより効率的にする方法などがある。本発明はこの中でも、無線ネットワーク環境(無線LAN、無線PANなど)で頻繁に使われるACKフレーム(ACKnowledgement frame)の構造をより効率的に簡略化してACKフレームによるトラフィック(traffic)を減少させるためのことである。
一般的に、データを伝送するデバイス(以下、送信デバイスと言う)がデータを受信するデバイス(以下、受信者デバイス)にデータフレームを伝送すれば、受信デバイスが前記データフレームを正しく受信した場合には、これを知らせるACKフレームを前記送信デバイスに伝送する。
このようなACKフレームには一つのフレームを受信する度に、正しく受信したという事実を直ちに知らせるACKフレームと、一定回数の間に複数のフレームを受信し、その複数のフレーム全体に対して一度に受信如何を知らせるACKフレームがある。前者のACK フレームを即時ACKフレーム(Immediate ACK frame)に、後者のACKフレームをバーストACKフレーム(Burst ACK frame)に定義できるが、本発明はこの中でもバーストACKフレームの構造改善に主眼点を置いている。
一般的なバーストACKフレームは、図1に表わす方式のように伝送される。送信デバイスは、n個のデータフレームを受信デバイスに伝送すれば、受信デバイスはn個のデータフレームに対するACKフレームを一度に送ることで、その度にACKフレームをいちいち送ることに比べてトラフィックを減少させうる。
実際に、このようなバーストACKフレームの概念として、IEEE(Institute of Electrical and Electronics Engineers)802.15.3無線PAN標準では遅延ACKフレーム(Delayed ACK frame)を使い、IEEE802.11e無線LAN標準ではブロックACKフレーム(Block ACK frame)を使う。
図2は、IEEE802.15.3標準による遅延ACKフレーム10の構成を表わしたものである。IEEE802.15.3でフレームフォーマットは、右側から表示することが一般的なので右側端にMAC header11が表示されている。遅延ACKフレーム10は、MAC header11と、遅延ACKを待機しているフレームのうち最大MACフレームサイズを有するフレームの数を表わすMax burstフィールド12と、遅延ACKで一度に処理できる最大フレーム数を表わすMax framesフィールド130と、n個のMPDU(MAC Protocol Data Unit)ID blockフィールド15、16などと、エラーチェックサム(checksum)を計算するためのFCSフィールド17とで構成されうる。
MPDU ID blockフィールド15、16、などのそれぞれは、また送信デバイスのMAC端で上位層(例えば、LLC(Logical Link Control)層)からMSDU(MAC Service Data Unit)を受信する度に一つずつ増加するMSDU番号(すなわち、MSDUの識別番号)が記録されるMSDU numberフィールド18と、MSDUがフラグメント化されて送信される時、フラグメント化順序が記録されるFragment numberフィールド19とで構成される。受信デバイスは、自身が受信したデータに対してMSDU numberと、Fragment numberを記録して送信デバイスに伝送することによって、送信デバイスは伝送したデータのうちどのデータ(MSDU自体、またはMSDUの一部フラグメント)が正しく伝送されなかったのかが分かる。以後送信デバイスは、正しく伝送されていないデータのみを受信デバイスに再伝送する。
図2に表わしたように、IEEE802.15.3標準ではMSDU numberフィールド18には9ビットが割り当てられ、Fragment numberフィールド19には7ビットが割り当てられるので、一つのMPDU ID blockフィールド15、16、などは2バイト(2octet)が割り当てられる。
図3は、IEEE802.11e標準によるブロックACKフレーム20の構成を表わしたものである。ブロックACKフレーム20は、MAC header21と、ブロックACKフレームの動作を制御するためのBA Controlフィールド22と、最初のMPDUのfragment numberとsequence numberが記録されるBlock ACK Starting Sequence Controlフィールド23と、以後のMPDUに対する‘受信確認情報’(特定データを正しく受信したのかを表わす情報)が順に記録されるBlock ACK Bitmapフィールド24と、エラーチェックサムを計算するためのFCSフィールド25とで構成されうる。
Block ACK Bitmapフィールド24には、128バイトが割り当てられるので、一つのMSDUに対して2バイトずつ割り当てれば、最大、64個のMSDUに対する受信確認情報が記録されうる。このように、一つのMSDUに対して2バイトが割り当てられるのは、IEEE802.11eで一つのMSDUは、最大16個まで断片化(fragmentation)されうるので、最大フラグメント化個数ほどのビット数(16×1ビット)、すなわち、2バイトが割り当てられたものである。したがって、実際に断片化されないか、16より小さな数ほど断片化がなされた場合にも、2バイトが一律的に割り当てられるので、このように一つのビットで受信確認情報を表わすことは効率的ではない。
図2または図3に表わしたように、一つのMSDUを表現するが、2バイトを使うとすれば、バーストACKフレームの大きさが必要以上に大きくなる問題がある。もし、n個のデータを伝送し、これに対するバーストACKフレームを受信するとすれば、バーストACKフレームのペイロード(payload)は2nバイト以上になる。したがって、データの伝送回数が増加するにつれて、バーストACKフレームサイズも大きくなって無線ネットワーク環境に不要なトラフィックを誘発する。
したがって、既存のバーストACKフレームの機能をそのまま実行しながら、より小さな大きさを有するバーストACKフレームを開発してACKフレームによるトラフィックを減少させる必要がある。
本発明は、前記問題点を考慮して創案されたものであって、ACKフレームのオーバーヘッド(overhead)を減少させる方法を提供することを目的とする。
また、本発明は、一つのMSDUに対して2ビットで受信確認情報を表示できる方法を提供することを目的とする。
前記目的を果たすために、送信デバイスから複数のフレームを受信し、これに対して一つのACKフレームとして確認応答を行うACKフレーム伝送方法であって、(a)前記送信デバイスからフレームを受信し、前記受信されたフレームの識別情報を保存する段階と、(b)前記保存された識別情報を用いて、前記受信された各フレームに対するビット対の集合を記録して第1フィールドを生成させる段階と、(c)前記生成されたフィールドを含んでACKフレームを生成させる段階と、(d)前記生成されたACKフレームを前記送信デバイスに伝送する段階と、を含み、前記ビット対は、該当フレームが正常的に受信されたか否かを確認する第1ビットと、前記第1ビットが該当フレーム一つに対する受信確認を表わすものなのか、該当フレーム以後のすべてのフラグメントに対する受信確認を表わすものなのかを区別する第2ビットとで構成される。
前記目的を果たすために、送信ステーションから少なくとも一つ以上のデータフレームを受信し、これに対して一つのACKフレームとして確認応答を行うACKフレーム伝送方法であって、(a)前記送信ステーションからフレームを受信して少なくとも前記受信されたデータフレームの識別番号と、前記データフレームが断片化されたフレームである場合には、前記データフレームのフラグメント番号及び最終フラグメント番号を保存する段階と、(b)前記保存された情報を用いて前記受信されたデータフレームそれぞれに対するビット対の集合を記録する段階であって、前記ビット対は、該当フレームが正常的に伝送されたか否かを確認する第1ビットと、前記第1ビットが表わすデータフレームの範囲を表わす第2ビットとで構成される、前記段階と、(c)前記記録されたビット対の集合を含むACKフレームを生成させる段階と、(d)前記生成されたACKフレームを前記送信ステーションに伝送する段階と、を含む。
前記目的を果たすために、送信ステーションから少なくとも一つ以上のデータフレームを受信し、これに対して一つのACKフレームとして確認応答を行うACKフレーム伝送方法であって、(a)前記送信ステーションからフレームを受信して少なくとも前記受信されたデータフレームの識別番号と、前記データフレームが断片化されたフレームである場合には、前記データフレームのフラグメント番号及び最終フラグメント番号を保存する段階と、(b)前記保存された情報を用いて前記受信されたデータフレームそれぞれが正常的に伝送されたか否かを確認するビットを連続して記録する段階と、(c)前記記録されたビットを含むACKフレームを生成させる段階と(d)前記生成されたACKフレームを前記送信ステーションに伝送する段階と、を含む。
前記目的を果たすために、送信デバイスから複数のフレームを受信し、これに対して一つのACKフレームとして確認応答を行うACKフレーム伝送装置であって、前記送信デバイスからフレームを受信する第1手段と、前記受信されたフレームの識別情報を保存する第2手段と、前記保存された識別情報を用いて、前記受信された各フレームに対するビット対の集合を記録して第1フィールドを生成させ、前記生成されたフィールドを含んでACKフレームを生成させる第3手段と、前記生成されたACKフレームを前記送信デバイスに伝送する第4手段と、を含み、前記ビット対は、該当フレームが正常的に受信されたか否かを確認する第1ビットと、前記第1ビットが該当フレーム一つに対する受信確認を表わすものなのか、該当フレーム以後のすべてのフラグメントに対する受信確認を表わすものなのかを区別する第2ビットとで構成される。
前記目的を果たすために、送信ステーションから少なくとも一つ以上のフレームを受信し、これに対して一つのACKフレームとして確認応答を行うACKフレーム伝送装置であって、前記送信ステーションからフレームを受信して少なくとも前記受信されたデータフレームの識別番号と、前記データフレームが断片化されたフレームである場合には、前記データフレームのフラグメント番号及び最終フラグメント番号を保存する手段と、前記保存された情報を用いて前記受信されたデータフレームそれぞれに対するビット対の集合を記録する手段であって、前記ビット対は、該当フレームが正常的に伝送されたか否かを確認する第1ビットと、前記第1ビットが表わすデータフレームの範囲を表わす第2ビットとで構成される、前記手段と、前記記録されたビット対の集合を含むACKフレームを生成させる手段と、前記生成されたACKフレームを前記送信ステーションに伝送する手段と、を含む。
前記目的を果たすために、送信ステーションから少なくとも一つ以上のデータフレームを受信し、これに対して一つのACKフレームとして確認応答を行うACKフレーム伝送装置であって、前記送信ステーションからフレームを受信して少なくとも前記受信されたデータフレームの識別番号と、前記データフレームが断片化されたフレームである場合には、前記データフレームのフラグメント番号及び最終フラグメント番号を保存する手段と、前記保存された情報を用いて前記受信されたデータフレームそれぞれが正常的に伝送されたか否かを確認するビットを連続して記録する手段と、前記記録されたビットを含むACKフレームを生成させる手段と、前記生成されたACKフレームを前記送信ステーションに伝送する手段と、を含む。
本発明によれば、バーストACKフレームまたはブロックACKフレームを伝送するにおいてオーバーヘッドを節減する。
また、本発明によれば、前記ACKフレームのオーバーヘッド節減によって無線ネットワーク全体で総データ伝送率を向上させる。
以下、添付された図面を参照して、本発明の望ましい実施形態を詳しく説明する。本発明の利点及び特徴、そしてそれらの達成方法は、添付図面と共に詳細に後述されている実施形態を参照すれば、明確になる。しかし、本発明は、以下で開示される実施形態に限定されず、相異なる多様な形態で具現でき、単に本実施形態は本発明の開示を完全にし、当業者に発明の範ちゅうを完全に知らせるために提供され、本発明は特許請求の範囲によってのみ定義される。明細書全体にわたって同一参照符号は、同一構成要素を指称する。
本発明で提案するバーストACKフレームに関する実施形態は、大きくIEEE802.15.3標準による遅延ACKフレームを改善した実施形態(以下、第1実施形態と言う)と、IEEE802.11系列標準によるブロックACKフレームを改善した実施形態(以下、第2実施形態と言う)に分けられうる。
図4は、本発明の一実施形態によるバーストACKフレーム100の構成を表わした図面である。バーストACKフレーム100は、MAC header110とペイロード領域120、130、140とで構成されうる。MAC header110は、図5のように従来のIEEE802.15.3標準のMAC headerと同一の構成を有しうる。
ペイロード領域は、MPDU IDフィールド120と、Bitmapフィールド130と、Padフィールド140を含んで構成されうる。MPDU IDフィールド120は、ACK応答を行う対象になるフレーム(以下‘対象フレーム’と定義する)のうち最初のフレームの識別情報が記録されるが、これはまたMSDU numberフィールド121と、Fragment numberフィールド122とに分けられうる。本発明によるバーストACKフレーム100は、受信されたフレームだけではなく、受信されていないフレームを含んだ全体伝送フレームに受信如何を応答するので、前記対象フレームとは、一定期間内の全体伝送フレーム(ACKを要する伝送フレームに限定される)を意味する。
MSDU numberフィールド121には、対象フレームのうち最初のフレームのMSDU numberが記録され、Fragment numberフィールド122には、対象フレームのうち最初のフレームのFragment numberが記録される。MSDU numberと、Fragment numberは受信される対象フレームのMACヘッダを見れば分かる。
Bitmapフィールド130には、対象フレームに対するACKビットとTypeビットの対(以下、ビット対と言う)が順に記録されるが、前記ビット対の個数(m)は最小である場合、総MSDUの個数と同じであり、最大である場合、総フラグメントの個数と同じである。
周知の如く、対象フレームは断片化がなされていない場合には、一つのMSDUからなり、断片化がなされた場合には、MSDUのうち一部フラグメントからなりうる。
Bitmapフィールド(130)の中で、ACKビットには該当フレームが正常的に受信されたか否かを確認するビットが記録されるが、正常的に受信された場合には1と、そうではない場合には0と記録されうる。そして、Typeビットには、前記ACKビットが該当フレーム(MSDUまたはフラグメント)に対する受信確認を表わすものか(前者)、MSDU内で現在フラグメント以後のすべてのフラグメントに対する受信確認を表わすものか(後者)を区別するビット情報が記録される。Typeビットは、前者の場合0と、後者の場合1と記録されうる。
Padフィールド140は、可変ビットとしてすべてダミービット(例:0)で満たされる。このフィールド140は、Bitmapフィールド130がビット単位なので所定個数のダミービット(dummy bits)、例えば、所定個数の0を満たしてバイトないしオクテット(octet)単位に作るために使われる。したがって、Bitmapフィールド130とPadフィールド140との大きさを合わせれば、いつもバイト単位になる。しかし、Padフィールド140は、本発明によるプロトコルを定義するための必須項目ではないので省略されることもある。
以下、図6ないし図10は、さまざまな実施形態によってバーストACKフレーム100が如何に決定されるかを説明するための図面である。ここで、[A:B]は、フレームを識別する表示であって、Aは送信デバイスが伝送したMSDU numberに付与した順番(以下、MSDU順番と言う)を、BはFragment number(0から開始)を意味する。例として、送信デバイスが、MSDU numberが1234から123であるフレームを伝送したとすれば、それぞれ順に1から4までMSDU順番が与えられる。このようなMSDU順番は、送信デバイスが伝送したMSDU numberを基準とすることであり、受信デバイスが受信して保存したMSDU numberを基準とすることではない。もし、送信デバイスは、MSDU numberが1234から1237であるフレームを伝送したが、受信デバイスは1235、及び1237であるフレームのみを受信したとしても、MSDU順番は1234から1237まで全体に対して順次に与えられる。
図6は、[1:0]、[2:0]、[3:0]、[4:0]をすべて正常的に受信した場合にバーストACKフレーム100の構造を表したもので断片化が全然生じない場合である。MPDU IDフィールド120には、[1:0]のMSDU number(=1)及びFragment number(=0)が記録される。そして、Bitmapフィールド130には、対象フレームに対するACKビットとTypeビットとからなるビット対が順に記録される。ところが、Bitmapフィールド130のみでバイト単位になるので、別途のPadフィールドは不要である。ここで、順序と言うことは、MSDU number及びFragment numberによる順序であり、フレームを受信した順序ではないことを明確に明らかにする。なぜならば、先に伝送したフレームが如何なる理由で後に受信されることもあるためである。
[1:0]、[2:0]、[3:0]、[4:0]は、すべて正常的に受信されたので、ビット対の最初のビットは1で満される。二番目のビット対(Xに表示される)は0または1のうちいずれの値で満たしても良い。そのフレームで該当MSDUが完結されるために1と表示することもでき、一方、一つのフレームに対するACK如何表示でもあるために0と表示することもできる。さらに、いずれのMSDUが断片化されたのかは送信デバイスと受信デバイスとがそれに関する情報を共有することで互いに分かっているために混同を誘発する可能性はない。しかし、一応一つのMSDUで完結されたという意味を明確にする側面で1で満たすことがより望ましい。以下、Xは本実施形態と同じ意味に解釈される。
図7は、[1:0]、[2:0]、[2:1]、[3:0]、[4:0]をすべて正常的に受信した場合にバーストACKフレーム100の構造を表したもので二番目のMSDUで断片化が生じた場合である。図6と同様に、MPDU IDフィールド120には、[1:0]のMSDU number(=1)及びFragment number(=0)が記録される。そして、Bitmapフィールド130には、対象フレームに対するACKビットとTypeビットとからなるビット対が順に記録される。
[1:0]、[2:0]、[2:1]、[3:0]、[4:0]は、すべて正常的に受信されたのでビット対の最初のビットは1で満たされて、このうち[1:0]、[3:0]、[4:0]は、完結されたフレームなので二番目のビットはXで満たされる。但し、[2:0]以後に同じMSDU number及び他のFragment numberを有する[2:1]が存在するので、[2:0]に対するビット対のうち二番目のビットは1と表示して[2:0]以後のすべてのフラグメントが正常的に受信されることを表示する。
このようにフラグメントになったMSDUに対して一度に表示することが望ましいが、同一の状況でバーストACKフレーム100を図8のようにMSDUがフラグメントになった場合には、各フラグメント別に表示する方法も考えられる。
図9は、送信デバイスが、[1:0]、[2:0]、[2:1]、[2:2]、[3:0]を伝送したが、受信デバイスでは[1:0]、[2:0]、[3:0]のみを正常的に受信した場合にバーストACKフレーム100の構造を表わしたものである。ここで、二番目のMSDUは、3個のフラグメントに分けられたことが分かる。MPDU IDフィールド120には、[1:0]のMSDU number(=1)及びFragment number(=0)が記録される。そして、Bitmapフィールド130には、送信デバイスが伝送したすべての対象フレームに対してACKビットとTypeビットとからなるビット対が順に記録される。
[1:0]、[3:0]は、すべて正常的に受信されたのでビット対の最初のビットは1で満たされ、完結されたフレームなので二番目のビットはXで満たされる。ところが、[2:0]は正常的に受信されたが、その後のフラグメントが存在するので該当フレーム、すなわち、該当フラグメントに対する受信確認のみを行うために該当位置に‘10’が記録される。しかし、[2:1]及び[2:2]は正常的に受信されることができなかったので、この二つのフレームを代表して[2:1]の位置に該当するビット対の最初のビットは0と表示される。そして、二番目のビットは1として表示されるが、これは最初のビットが該当位置の以後、すなわち、[2:1]及び[2:2]に対するACKビットであることを意味する。
ところが、受信デバイスが[2:0]のみを受信したが、[2:1]及び[2:2]の存否が如何に分かるかが問題になる。しかし、これは[2:0]のMACヘッダを見れば分かる。これについてのより詳しい説明は、図13の説明で後述する。
図10は、送信デバイスが、[1:0]、[2:0]、[2:1]、[2:2]、[3:0]を伝送したが、受信デバイスでは[1:0]、[3:0]のみを正常的に受信した場合に、バーストACKフレーム100の構造を表わしたものである。ここで、受信デバイスは、二番目のMSDUに関するデータを一つも受信することができなかったので、それが3個のフラグメントからなされていることは分からない。しかし、[1:0]、及び[3:0]を受信したので、2番目のMSDUに対するフレームが伝送されなかったということが分かる。
MPDU IDフィールド120には、[1:0]のMSDU number(=1)及びFragment number(=0)が記録される。そして、Bitmapフィールド130には、送信デバイスが伝送したすべての対象フレームに対してACKビットとTypeビットとからなるビット対が順に記録される。
[1:0]、[3:0]は、すべて正常的に受信されたので、ビット対の最初のビットは1で満たされ、完結されたフレームなので二番目のビットはXで満たされる。ところが、MSDUが1であるフレームと3であるフレームとが受信されたことを見れば、MSDUが2であるフレームも送信されたがエラーによって受信されることができなかったことが分かる。このように、二番目のMSDUに対するフレームは全然受信することができなかったが、[2:0]の位置に最初のビットを0で満たし、二番目のビットを1で満たすことによって、[2:0]以後のすべてのフラグメントは受信されることができなかったことを表示できる。
図11は、以上のようなバーストACKフレーム100を伝送する、本発明の一実施形態による無線デバイス200の構成を表わしたブロック図である。無線デバイス200は、バーストACK生成モジュール210と、MACモジュール220と、上位層モジュール230と、PHYモジュール240と、メモリ250と、制御ユニット260とを含んで構成されうる。
バーストACK生成モジュール210は、受信されるデータフレームのヘッダ情報から該当フレームの識別情報として、MPDU ID情報を判読し、この情報を用いて本発明によるバーストACKフレーム100のペイロードを生成させる。バーストACK生成モジュール210は、また図12のような詳細構造を有する。すなわち、バーストACK生成モジュール210は、生成制御モジュール211と、MPDU ID生成モジュール212と、ビットマップ生成モジュール213と、パッド生成モジュール214とを含んで構成されうる。
生成制御モジュール211は、特定送信デバイスから受信された所定個数のフレームに対するバーストACKフレーム100を生成させるための条件(以下、‘ACK生成条件’と言う)をチェックして、条件が完成されていない間には前記特定送信デバイスから受信されるフレームのMACヘッダに含まれるMPDU ID情報をMACモジュール220から受信してメモリ250に保存しておく。そして、条件が完成されれば、MPDU ID生成モジュール212、ビットマップ生成モジュール213、及びパッド生成モジュール214をして前記保存されたMPDU ID情報を用いてバーストACKフレーム100のペイロードを生成させる。
ここで、MPDU ID情報は、受信されたフレームのMSDUに対する固有一連番号を表わす‘MSDU number’とフラグメントになった順序を表わす‘Fragment number’とを含む。MPDU ID情報は、図1のようなIEEE802.15.3標準によるMAC Header110にも表われている。
図13のMAC Header110でFragmentation Controlフィールド112は、MSDU numberフィールド117と、Fragment numberフィールド118と、Last fragment numberフィールド119とに分けられる。したがって、Fragmentation Controlフィールド112を読取ることでMSDU ID情報が分かる。但し、図12とは異なって、フラグメントになったすべてのフレームには、Last fragment numberフィールド119に最後のフラグメントの番号が記録されるので、図9のような場合に[2:0]のみを受信しても[2:1]及び[2:2]が存在することが分かる。
再び図12に戻って、生成制御モジュール211がチェックする条件は、送信デバイスが受信デバイスに対象フレームを伝送する時、MACヘッダのうちバーストACKフレームを要請する一部ビット(以下、‘要請ビット’と言う)がONになっているか否かを基準としてできる。すなわち、対象フレームを受信する度に該当フレームの‘要請ビット’の値を判読して、その値がOFFを表わすビット(=0)であれば、ACK生成条件が満足していないと、その値がONを表わすビット(=1)であれば、ACK生成条件が満足したと判断することである。
もし、送信デバイスが[1:0]、[2:0]、[3:0]を伝送し、[3:0]に要請ビットがONに設定された場合に、受信デバイスが[1:0]、[2:0]のみを受信したとすれば、受信デバイスはACK生成条件が満足していないので、バーストACKフレームを生成しない。その後、送信デバイスは、一定時間内にバーストACKフレームが受信されなければ、伝送エラーがあると見てまた要請ビットをONに設定して[3:0]を伝送する。
以上では、ACK生成条件を送信デバイスが決定するとしたが、これに限らず一定個数以上の対象フレームが受信されれば、ACK生成条件が満足されることにする方法も可能である。
MPDU ID生成モジュール212は、メモリ250に保存されたMSDU ID情報を用いて、MPDU IDフィールド120、すなわち、対象フレームのうち最初のフレームのMSDU numberフィールド121と、対象フレームのうち最初のフレームのfragment numberフィールド122を記録する。
ビットマップ生成モジュール213は、前記MPDU IDフィールド120に付け加えて対象フレームに対するビット対を順次に記録する。最初のビット(ACKビット)には、現在ビット対が表わすフレームが正常的に受信されたか否か(正常に受信されれば1、それとも0)を確認するビットが記録され、二番目のビット(Typeビット)には前記最初のビットが該当フレームに対する受信確認を表わすもの(0に記録)なのか、一つのMSDU内で現在フラグメント以後のすべてのフラグメントに対する受信確認を表わすもの(1に記録)なのかを区別するビット情報が記録される。
パッド生成モジュール214は、ビットマップの大きさがバイト単位にならない場合に、残りのビットを0で満たしてバイト単位にする。
また図11を参照すれば、MACモジュール220は、MAC層(Media Access Control Layer)での動作を管掌する。すなわち、上位層モジュール230からMSDUを伝達されてここに図13のようなMACヘッダを付着し、その結果をPHYモジュール240に伝達する。また、MACモジュール220は、バーストACK生成モジュール210からバーストACKフレームのペイロードを伝達され、同様にここにMACヘッダを付着してPHYモジュール240に伝達する。
また、PHYモジュール240から他のデバイスから伝送されたフレームを受信すれば、ここでMACヘッダを判読した後、MACヘッダを除去してその結果を上位層モジュール230に伝達する。そして、MACヘッダのうち判読されるMPDU ID情報をバーストACK生成モジュール210に伝達する。
上位層モジュール230は、MSDUを生成させてMACモジュール220に伝達し、MACモジュール220からMACヘッダが除去されたデータを伝達される。このような上位層モジュール230は、LLC階(Logical Link Layer)以上のネットワーク層を管掌する。
PHYモジュール240は、物理層(Physical Layer)での動作を管掌する。すなわち、MACモジュール220からMPDUを伝達されてPPDU(PACKet Protocol Data Unit)を生成させ、これを含む無線信号を生成させて伝送する。また、無線媒体を通じて伝達される信号を受信して加工した後、これをMACモジュール220に伝達する。PHYモジュール240は、また細分化してベースバンドプロセッサ(base band processor)とRF(radio frequency)モジュールとに細分化されうる。
メモリ250は、受信されたフレームに対するMPDU ID情報を保存してからバーストACK生成モジュール210の要請があれば、この情報を提供する。
制御ユニット260は、無線デバイス200内の他のモジュールの動作を制御するが、中央処理ユニット(CPU)、マイコン(Microcomputer)などによって具現されうる。
図14は、本発明の一実施形態によるバーストACKフレーム100生成過程を表わしたフローチャートである。
まず、ACK生成条件が完成される前まで(S20のいいえ)、PHYモジュール240を通じて‘対象フレーム’を受信し(S10)、生成制御モジュールは、前記受信される対象フレームのMPDU ID情報を保存する過程(S25)を反復する。MPDU ID情報には、該当対象フレームのMSDU number及びFragment numberを含む。
もし、生成制御モジュール211は、 ACK生成条件が完成されたか否かを判断して完成されれば(S20のはい)、初めてバーストACKフレーム100のペイロードを生成させるように制御する。前記ペイロードを生成させる過程は、S30ないしS69段階からなる。
まず、MPDU ID生成モジュール212は、メモリ250に保存された対象フレームのうち最初フレームのMSDU numberフィールド121とfragment numberフィールド122とを記録することでMPDU IDフィールド120を生成させる(S40)。
ビットマップ生成モジュール213は、前記MPDU IDフィールド120に付け加えて対象フレームに対するビット対を順次に記録することでBitmapフィールド130を生成させる(S50)。S50段階についてより詳しい過程は、図15の説明から後述する。
前記生成されたBitmapフィールド130の大きさがバイト単位である場合には(S68のはい)、Padフィールド140を生成させる必要がないが、そうではない場合には、所定のビットの連続された0値を有するPadフィールド140を前記Bitmapフィールド130に連続して付け加える。前記連続された0値を有するビット数は、Bitmapフィールド130とPadフィールド140とを合わせてバイト単位にする個数である。
MACモジュール120は、S50またはS69で生成されたバーストACKフレーム100のペイロードにMACヘッダを付着してバーストACKフレーム100を生成させる(S70)。そして、PHYモジュール140は、対象フレームを伝送したデバイスに生成されたバーストACKフレーム100を無線媒体を通じて伝送する(S80)。
図15は、図14のS50段階をより詳しく表わしたフローチャートである。
まず、メモリ250に保存されたMSDU numberに‘MSDU順番’を付与する(S51)。例えば、保存されたMSDU numberが1234から1237までとすれば、MSDU numberのMSDU順番(k)は順に1から4になる。もし、保存されたMSDU numberが連続的ではない場合、例えば、1234、1236、1237である場合にも存在していない1235に対しても、すべて正しく受信された場合と同様に、MSDU順番(k=3)が与えられる。
次に、初期値としてkを1に置いて最後のMSDU順番をNに置く(S52)。
受信エラーがあり得るので、よってすべてのMSDU順番(k)に対してメモリ250に保存されたMSDU numberが存在するものではない。したがって、k番目のMSDU順番に対してMSDU numberが存在するかどうかを判断して(S53)、存在しなければ(S53のいいえ)、Bitmapフィールド130にビット対を‘01’と記録する(S59)。
もし、存在する場合には、k番目のMSDUがフラグメントされたか否かを判断して(S54)、フラグメントされていなければ(S54のいいえ)、Bitmapフィールド130にビット対を‘1X’に記録する。ここで、Xは、1または0のいずれの値を記録しても良いという意味である。
フラグメントされていれば(S54のはい)、k番目のMSDUに該当する保存されたすべてのフラグメントのFragment numberを読取る(S55)。そして、保存されたFragment numberのうち最大Fragment numberより小さな‘Fragment順番’それぞれに対してBitmapフィールド130に順次にビット対を記録する(S56)。前記Fragment順番もMSDU順番と同様に送信デバイスが伝送したフレームを基準として順次に与えられる。
例えば、[2:0]、[2:1]、[2:2]、及び[2:3]が伝送されたが、[2:1]と[2:3]のみが受信された場合を考えれば、保存されたフラグメントのFragment numberは1、3なので最大Fragment numberは3になる。3より小さな‘Fragment順番’は0、1、2を意味するので、これに対してBitmapフィールド130に順次にビット対を記録すれば、‘00’、‘10’、‘00’になる。
次に、最大Fragment numberが最終Fragment numberと同じであれば(S57のはい)、Bitmapフィールド130にビット対を‘1X’と記録する。ここで、最大Fragment numberは、前述したようにメモリ250に保存されたFragment numberのうち最大値を意味し、最終Fragment numberは、送信デバイスが伝送した対象フレームの最終Fragment numberを意味する。最大Fragment numberが最終Fragment numberであるか否かは、図13でLast fragment numberフィールド119を参照すれば分かる。
S57段階で、‘いいえ’である場合には、Bitmapフィールド130に最大Fragment numberを有するフラグメントに対するビット対、すなわち、‘10’を記録し(S61)、以後のすべてのFragment numberに対するビット対は‘01’に総括して記録する(S62)。
S58段階、S59段階、S60段階、またはS66段階を実行した以後には、kがNと同じであれば、Bitmapフィールド130の記録は完了したので終了し、そうではなければkを1増加させた後、再びS53段階に戻る。
IEEE802.11nタスクグループ(Task Group)では、大容量マルチメディア伝送要求に応じようと100Mbps以上の帯域幅を有する新しい形式の無線LAN標準化作業を施行している。IEEE802.11nは、IEEE802.11e基盤のQoS向上技術を基盤にしてMIMO(Multi Input Multi Output)技術を適用した無線LAN標準の一つである。IEEE802.11nは、既存の無線LANと共存が可能で必要な場合、通信も可能である。また多様な機能が付加されたが、そのうち一つがブロック伝送(Block Transmission;ACK受信なしに連続して送信されるデータフレームの伝送を意味する)である。
無線LANの特性上、チャンネルを信頼することができないためにデータ伝送結果を確認するために一般的にACKフレームが使われる。ところが、IEEE802.11nでは、ブロック伝送の結果としてブロックACK要請フレーム(Block ACK Request Frame)とブロックACKフレームとが使われる。ここで、ブロックACKフレームは、最大64個のMSDU、最大1024個の断片化されたフレーム(fragmented frame)に対する伝送確認結果を含みうる。しかし、前記ブロックACKフレームは、伝送されるブロック伝送の個数とは無関係に152バイトの固定大きさを有しているために非効率的である。
ブロックACK方式では、ブロックACK要請フレームとブロックACKフレームとが使われる。従来のブロックACK要請フレーム310は、図16で図示した構成を有する。前記フレーム310のtypeはcontrolであり、subtypeは‘1000’であり、BA controlフィールド311及びBlock ACK Starting Sequenceフィールド312を含む。BA controlフィールド311は、またReservedフィールド311aとTIDフィールド311bとに細分化され、Block ACK Starting Sequenceフィールド312は、またFragment Numberフィールド312a及びStarting Sequence Numberフィールド312bに細分化される。
一方、図17は、従来のブロックACKフレーム320の構成を表わしたもので、図3をより詳しく表わした図面である。前記フレーム320のtypeは controlであり、subtypeは1001である。ブロックACKフレーム320は、ブロックACK要請フレーム310で要求するBA controlフィールド321、Block ACK Starting Sequenceフィールド322、及び先立ってブロック伝送されたデータの伝送確認結果を含むBlock ACK Bitmapフィールド323を含む。
受信者(Recipient)は、伝送者(originator)によって伝送されたブロックACK要請フレームを成功的に受信した後、先立って受信したブロック伝送によるデータ伝送確認結果をブロックACKフレーム320にあるBlock ACK Bitmapフィールド323に記録して伝送者に伝送する。一般的に、伝送者は、データを伝送するステーション(station)を意味し、受信者は、データを受信するステーションを意味することで使われる。
Block ACK Bitmapフィールド323は、固定長128bytesであり、64個のMSDUを表現できるように構成される。すなわち、一つのMSDU当り2bytesが割り当てられ、これは16個のフラグメント(fragment)を表現できる。このように最大64MSDU、最大1024個のフラグメントの伝送確認結果は、1024ビットのビットマップ(B0ないしB1023)に表現されうる。
このように、従来のブロックACKフレーム320を使えば、いつも固定長のビットマップを使って伝送確認がなされるのでフレームの記録及び判読の簡単な側面があることはある。しかし、無線チャンネル資源が十分ではない無線ネットワーク環境では、チャンネルの効率的使用を阻害する要素と作用できる。
実際に、一つのMSDUは、最大16個のフラグメントで構成されうるが、ほとんどの場合、データは断片化(fragmentation)されないで単一MSDUからなり伝送される。しかし、従来のBlock ACKフレーム320は、いつも64のMSDU、すなわち、1024個のフラグメントを記録できるように構成されているために、大部分前記フレーム320には無駄使いになる領域が多数発生する。そして、小さな大きさのブロック伝送が発生してもいつも固定大きさのビットマップを含んで伝送されるために、チャンネル占有時間が増えるようになって、これによってチャンネル使用の非効率をもたらす。
もし、断片化が全然なされていない64個のMSDUを受信した受信者が、これに対する従来のブロックACKフレーム320を伝送するとすれば、前記フレーム320には(024−64)ビットほどの意味のない情報を含むために、前記フレーム320に含まれるビットマップの効率のみを考えれば、約94%の無駄使いをもたらすわけになる。したがって、従来の機能をそのまま実行しながらより小さな大きさを有するブロックACKフレームの構成を開発して、無線通信のトラフィックを減少させる必要がある。
ブロックACKメカニズムは、SIFS(Short Interframe Space)ほどの時間間隔を有するデータのブロック(ACK受信なしに連続して伝送されるデータフレームの集合)を伝送可能にする。前記メカニズムは、複数のACKを一つのフレーム(ブロックACKフレーム)に代えることでチャンネル効率を向上させる。このようなブロックACKメカニズムには、‘immediate’タイプと‘delayed’タイプとがある。ImmediateタイプのブロックACKは、高帯域幅(high−bandwidth)及び低いトラフィックレイテンシー(traffic latency)を要する環境に適し、delayedタイプのブロックACKは、或る程度のレイテンシーを勘耐できる環境に適している。
ブロックACKメカニズムは、図18のようにADDBA要請(ADDBA request)フレームの伝送によって始まる。以後、データのブロックは、伝送者から受信者に伝送される。QoSデータの間の時間間隔は、SIFSで維持される。以後、伝送者が受信者にBlock ACK要請(Block ACK Req)を行うによって受信者が伝送者にBlock ACKフレームを伝送する。
最後に、伝送者が受信者にDELBA要請(DELBA request)を送ることで全体過程が終了されうる。図18の例では、セットアップ過程及び解除過程を含んでいるが、これは一例に過ぎず、本発明を実行するためにセットアップ過程及び解除過程が必ずしも要求されるものではない。
図19は、本発明の一実施形態によるデータフレーム350の構成を図示した図面である。データフレーム350は、従来のIEEE802.11aのようにFrame Controlフィールドと、Duration/IDフィールドと、4個のAddressフィールドAddress1、Address2、Address3、Address4、及びSequence Controlフィールドを含むMACヘッダと、Frame bodyと、FCSフィールドを含んで構成されうる。このうちFCSフィールドは、32bit CRC(cyclic redundancy checking)エラーチェックのためのフィールドで本発明を実施するための必須的な構成要素ではない。
Frame Controlフィールド351は、少なくともTypeフィールド352と、Subtypeフィールド353を含む。本発明で後述するビット対で構成されたビットマップ方式またはACKビットで構成されたビットマップ方式を利用するために、伝送者が断片化されたMPDUで構成されたMSDUが伝送する場合には、これと共に受信者に最終フラグメント番号(Last Fragment Number)を伝達することとする。ここで、最終フラグメント番号は、現在伝送するMSDUの全体フラグメント数、すなわち、全体フラグメントのうち最後のフラグメントの一連番号を意味する。
このような最終フラグメント番号は、多様な方法で伝達されうるが、本発明ではその一例として前記Typeフィールド352とSubtypeフィールド353とを利用することとする。
従来のTypeフィールドには、フレームのタイプ値(type value)が記録されるが、その値は‘00’、‘01’、‘10’を有することができ、順にそれぞれ‘Management’フレームタイプ、‘Data’フレームタイプ、‘Control’フレームタイプを示す。そして、‘11’値は予備(reserved)されている。本発明は、従来の標準と互換性とをそのまま維持させるため、前記予備された値を利用する。本発明で、Typeフィールド352に‘11’が記録されたらデータフレームが断片化されて伝送されることを意味する。Typeフィールド352が‘11’である場合、Subtypeフィールド353には最終フラグメント番号が記録される。従来のTypeフィールドが‘11’である場合、Subtypeフィールドは、‘0000’から‘521’まで予備されているので、これを利用することで従来標準と互換性とを図る。但し、これは一つの実施形態に過ぎず、最終フラグメント番号を伝達するためにはいくらでも他の方式を使うことができるということは当業者には自明な事実である。
Frame Controlフィールド351は、Typeフィールド352とSubtypeフィールド353との以外に、従来のようにProtocol Versionフィールド、To DSフィールド、From DSフィールド、Retryフィールド、Pwr Mgtフィールド、More Dataフィールド、WEPフィールド、及びOtherフィールドとをさらに含みうる。
Sequence Controlフィールド354は、現在データフレーム(ないし現在フラグメント)のフラグメント番号が記録されるFragment numberフィールド355と、現在フレームが属するMSDUの識別番号(IEEE802.11系列の標準では、シーケンス番号がこれに該当する)が記録されるSequence Numberフィールド356に分けられる。例えば、3個に断片化されたデータが伝送される時、[シーケンス番号:フラグメント番号]は、それぞれ[1:0]、[1:1]、[1:2]に表わすことができる。
図20は、本発明の一実施形態によるブロックACKフレーム3100の構成を図示した図面である。本発明でブロックACK要請フレーム310は、従来と同一の形態をそのまま使うことができるので別途に定義しない。
ブロックACKフレーム3100は、MACヘッダ領域3190とペイロード領域3150、3160、3170とで構成されうる。そして、図19で説明したようなFCSフィールド3180をさらに含みうる。MACヘッダ領域は、Frame Controlフィールド3110と、Durationフィールド3120と、RAフィールド3130と、TAフィールド3140とを含むことができ、ペイロード領域は、BA Controlフィールド3150と、Block ACK Starting Sequence Controlフィールド3160と、Block ACK Bitmapフィールド3170とを含みうる。
Frame Controlフィールド3110は、図19で表われた形式と同一である。ブロックACKフレーム3100の場合、Typeフィールド352は、controlフレームを表わす値が記録され、Subtypeフィールド353には、ACKフレーム3100のsubtype値が記録される。前記subtype値は、予備されている値のうち一つを指定して使うことができる。
Durationフィールド3120には、ブロックACKフレーム3100の伝送時間及びSIFS間隔を加えた値以上の値が記録される。そして、RAフィールド3130には、ブロックACKを要請してブロックACKを受信するステーションのアドレスが記録され、TAフィールド3140には、ブロックACKを伝送するステーションのアドレスが記録される。
BA Controlフィールド3150は、ビット対のビットマップ方式のうち‘一般モード(Normal Mode)’と‘圧縮モード(Compression Mode)’と‘1ビットモード’(31bit Mode)とを区分するビット値(以下、“モードビット”と言う)が記録されるMode Selectionフィールド3152とトラフィック識別子(traffic identifier;以下、TIDと言う)が記録されるTIDフィールド3153とを含む。ここで、一般モード及び圧縮モードは、ビット対を用いて表現する方法である一方、1ビットモードは一つのフラグメントに対する伝送確認を行うが1個のビットを使う方法である。それぞれのモードに関する実施形態は後述する。
そして、Block ACK Bitmapフィールド3170に含まれるビット対の個数(m)が記録されるBitmap Lengthフィールド3151をさらに含みうる。
Block ACK Starting Sequence Controlフィールド3160は、ビット対の集合によって伝送確認を始めようとするフレームが属するMSDUの識別番号、すなわち、開始シーケンス番号(Sequence Number)が記録されるStarting Sequence Numberフィールド3162と伝送確認を始めようとするフレームのフラグメント番号が記録されるFragment Numberフィールド3161とで構成されている。
Block ACK Bitmapフィールド3170には、少なくとも一つ以上のビット対3171など(以下、ビット対の集合と言う)で構成されたビットマップが記録される。このようなビット対(Bit Pair)は、既存のBlock ACK Bitmapフィールドの記録方式を改善してより効率的に伝送確認結果を記録するために本発明で提案された形式である。一般的に、ビット対の大きさ総合がOctet単位にならない場合があり得るので、ビット対に引き継いでPaddingフィールド3174を付け加えることもできる。Paddingフィールド3174は、Block ACK Bitmapフィールド3170に記録されるビット対と大きさとを合わせてOctet単位にする最小ビット数のdummyビット(例:0)が記録される。もし、ビット対大きさの総合が26ビットとする時、パッディングフィールド3174の大きさを6ビットに取ると、全体的に32ビット、すなわち、4バイトを合わせることができる。但し、パッディングフィールド3140は、本発明によるプロトコルを定義するための必須項目ではないので省略されることもできる。
ビット対3171、3172、3173などは、ACKビット3171aと、MSDUビット3171bからなる。ACKビット3171aには、該当フレームが正常的に伝送されたか否かを確認するビットが記録されるが、正常的に受信された場合には1と、そうではない場合には0と記録されうる。
そして、MSDUビット3171bには、前記第1ビットが表わすデータフレームの“範囲”を表わすビットが記録される。本発明の一実施形態によれば、前記範囲は、MSDUビット3171bには、前記ACKビットが一つのフラグメント(一つのMSDUが断片化されていない場合は、一つのMSDU)に対する伝送確認を表わすものなのか(前者)、一つのMSDUに属する現在フラグメント以後のすべてのフラグメントに対する伝送確認を表わすものなのか(後者)を区別する意味に理解されうる。MSDUビット3171bは、前者の場合は0と、後者の場合は1と記録されうる。
以下、図21ないし図26は、さまざまな実施形態によってブロックACKフレーム3100が如何に構成されるかを説明するための図面である。本発明で、ビット対を用いてビットマップを構成する方法では、一般モードで表現する方法と、圧縮モードで表現する方法がある。以下で、[A:B]はフレームを識別する表示であって、Aは伝送者が伝送したフラグメントが属するMSDUに付与された識別番号、すなわち、シーケンス番号(Sequence Number)を、Bはフラグメントの順番、すなわち、フラグメント番号(0から開始)を意味することとする。
図21は、[1:0]、[2:0]、[3:0]、[4:0]をすべて正常的に受信した場合に、ブロックACKフレーム3100の構造を表わしたもので断片化が全然生じない場合である。この場合には、一般モードである場合と圧縮モードである場合とが同様に表われる。この場合、Block ACK Starting Sequence Controlフィールド3160には、フレーム[1:0]の開始シーケンス番号(Starting Sequence Number=1)及びフラグメント番号(Fragment number=0)が記録される。そして、Block ACK Bitmapフィールド3170には、対象フレームに対するACKビットとMSDUビットとからなるビット対が順に記録される。ところが、この場合、ビット対だけでもバイト単位になるので、別途のPaddingフィールドは不要である。
[1:0]、[2:0]、[3:0]、[4:0]は、すべて正常的に受信されたのでビット対の最初のビットは1で満たされる。二番目のビット対(Xに表示される)は、0または1のうちいずれの値で満たしても良い。該当フレームでMSDUが完結されるために1と表示することもできる一方、一つのフレームに対するACK如何表示でもあるために0と表示することもできるためである。しかし、一応一つのMSDUで完結されたという意味を明確にする側面で1で満たすことがより望ましいことである。以下、Xは、本実施形態のような意味に解釈される。
図22は、[1:0]、[2:0]、[2:1]、[3:0]、[4:0]をすべて正常的に受信した場合にブロックACKフレーム3100の構造を圧縮モードで表わしたものである。ここで、二番目のMSDU(シーケンス番号=2)が断片化されている。図21と同様にBlock ACK Starting Sequence Controlフィールド3160には、[1:0]の開始シーケンス番号(=1)及びフラグメント番号(=0)が記録される。そして、Block ACK Bitmapフィールド3170には、対象フレームに対するACKビット3171aとMSDUビット3172bとからなるビット対が順に記録される。
[1:0]、[2:0]、[2:1]、[3:0]、[4:0]は、すべて正常的に受信されたのでビット対の最初のビット(ACKビット)は1で満たされ、このうち[1:0]、[3:0]、[4:0]は完結されたフレームであるので二番目のビット(MSDUビット)はXで満たされる。但し、[2:0]以後にこのようなシーケンス番号及び他のフラグメント番号を有する[2:1]が存在するので、[2:0]に対するビット対のうち二番目のビットは1と表示して[2:0]以後のすべてのフラグメントが正常的に受信されることを表示する。
このようにフラグメントになったMSDUに対して一度に表示することが望ましいが、同一の状況でブロックACKフレーム3100を図23のようにMSDUがフラグメントになった場合には、各フラグメント別に表示する方法も考えられる。図22のように一つのMSDUに対して一度に表示する方式を“圧縮モード”と定義し、図23にように各フラグメント別にそれぞれ表示する方式を“一般モード”と定義する。
図24は、伝送者が[1:0]、[2:0]、[2:1]、[2:2]、[3:0]を伝送したが、受信者は[1:0]、[2:0]、[3:0]のみを正常的に受信した場合のブロックACKフレーム3100の構造を表わしたものである。ここで、二番目のMSDUは、3個のフラグメントに分けられたことが分かる。Block ACK Starting Sequence Controlフィールド3160には、フレーム[1:0]の開始シーケンス番号(=1)及びフラグメント番号(=0)が記録される。
[1:0]、[3:0]は、すべて正常的に受信されたのでビット対の最初のビットは1で満たされ、完結されたフレームなので二番目のビットはXで満たされる。ところが、[2:0]は正常的に受信されたが、その後のフラグメントが存在するので該当フレーム、すなわち、該当フラグメントに対する伝送確認のみを行うために該当位置に‘10’が記録される。しかし、[2:1]及び[2:2]は、正常的に受信できなかったのでこの二つのフレームを代表して[2:1]の位置に該当するビット対の最初のビットは0と表示される。そして、二番目のビットは1として表示されるが、これは最初のビットが該当位置以後、すなわち、[2:1]及び[2:2]に対するACKビットであることを意味する。このように、受信者が複数のフラグメントのうち一部のみ受信してからも残りのフラグメントを受信することができなかったということが分かることは、伝送確認の対象となるデータフレーム350のLast Frame Numberフィールド353に全体フラグメント数が記録されているためである。
図21ないし図24までの実施形態のうち、図21の実施形態は圧縮モード及び一般モードで表現される例であり、図23の実施形態は一般モードで表現した例であり、図22、及び図24の実施形態は圧縮モードで表現した例である。実施形態のうち両方とも表現可能な場合には、一般モードに比べて圧縮モードがより効率的であると考えられる。しかし、すべての場合に対して一般モード及び圧縮モードで表現可能なことではなく、一般モードでのみまたは圧縮モードでのみ表現可能な場合もあり得る。
図25の実施形態のように連続されたフラグメントのうちから中間の一部が抜け落ちされた場合には、一般モードでのみ表現可能であり、圧縮モードでは表現可能ではない。伝送者が[1:0]、[2:0]、[2:1]、[2:2]、[3:0]を伝送したが、受信者ではこの中で[2:1]のみを受信することができなかった場合にブロックACKフレーム3100を一般モードで表現すれば、図25のようである。
図26の実施形態は、伝送者が[1:0]、[2:0]、[2:1]、[2:2]、[3:0]を伝送したが、受信者側では[1:0]、[3:0]のみを正常的に受信した場合、ブロックACKフレーム3100を圧縮モードで表現したものである。この場合には、圧縮モードでのみ表現可能である。なぜならば、受信者がMSDUが2であるフレームは一つも受けることができなかったので、全体フラグメント数が3ということが分からないためである。
この場合、[1:0]、[3:0]は、すべて正常的に受信されたのでビット対の最初のビットは1で満たされ、完結されたフレームなので二番目のビットはXで満たされる。ところが、MSDUが1であるフレームと3であるフレームが受信されたことを見ればMSDUが2であるフレームも伝送されたが正常的に受信されることはできなかったことが分かる。このように、二番目のMSDUに対するフレームは一つも受信することができなかったが、[2:0]の位置に最初のビットを0で満たし、二番目のビットを1で満たすことで、[2:0]及びその以後のすべてのフラグメントは受信されることができなかったことを表示することができるのである。
以上のように実施形態によって一般モード及び圧縮モードのうち一つのモードでのみ表現のみが可能な場合もあり、二つのモードにすべて表現可能な場合もある。両方とも表現可能な場合ならより効率的な圧縮モードを使うことが望ましい。
一方、前記一般モードで表現可能な場合には、より改善した方式で伝送確認ができる。前述した一般モードと圧縮モードは、すべてビット対を用いて表現した実施形態である。しかし、一般モードである場合には、それぞれのフラグメント別に伝送確認を行うので、MSDUビット3171bはすべて0であると表現できる。したがって、一般モードで表現可能な場合には、ACKビット3171a一つのみ使って伝送確認ができるが、このように1ビットに表現するモードを“1ビットモード”と定義する。
図27は、1ビットモードを使う場合にBlock ACK Bitmapフィールド3170の構成を表わしたものである。この場合、前記フィールド3170は、ビット対の代わりに1ビットのACKビット3175、176、177のみで構成され、やっぱりOctetを合わせるためにPaddingフィールド3174が使われうる。図25のように、一般モードで表現された場合を1ビットモードで表現すれば、図28のようになる。この結果は、一般モードでのビット対でMSDUビット3171bを省略したことと同一である。
従来のBlock ACK Bitmapフィールド(図17の23)も伝送確認のためのビットの集合でなされているという側面では同一である。しかし、本発明での1ビットモードは従来とは異なって、可変大きさのBlock ACK Bitmapフィールド3170を使う。また、従来のBlock ACK Bitmapフィールド(図17の23)は、断片化されていない一つのフレームまたは16個以下に断片化されたフレーム(フラグメント)に対する伝送確認でも一律的に16ビットを割り当てしたが、1ビットモードは一つのフレームまたはフラグメントにはそれぞれ1ビットずつ割り当てすることで確かなビット節減効果がある。これにより1ビットモードによってBlock ACK Bitmapフィールド3170にACKビット3175などを記録する時には従来とは異なって、連続して記録する。本発明では伝送者は、データフレームを通じて受信者にフラグメント数(最終フラグメント番号)を知らせることによって、伝送者及び受信者間にフラグメント情報を明確に分かるので、このように連続して記録しても混同の恐れがない。
一方、どのモードを使ってビットマップを構成したのかは、図20のMode Selectionフィールド3152に記録されうる。例えば、‘00’は一般モードを、‘01’は圧縮モードを、そして、‘10’は1ビットモードを表わすことでできる。
Block ACK Bitmapフィールド3170に含まれるビット対(圧縮モード及び一般モードの場合)またはビット(ACK bit;1ビットモードの場合)の個数(m)は、Bitmap Lengthフィールド3151に記録されうる。例えば、図22のような場合でBitmap Lengthフィールド3151には4が記録され、図23の場合でBitmap Lengthフィールド3151には5が記録される。但し、受信者で各モードの規則によってビット対(3171など)またはACKビット3175などが記録される時、その大きさは一義的に決まることができる。したがって、ビット対またはACKビットを順次に記録して伝送者に伝送するだけでも、複数のデータフレームに対する伝送確認が十分に可能である。したがって、Bitmap Lengthフィールド3151は、本発明を実行するために必ずしも必要なものではなく、Bitmap Lengthフィールド3151部分を予備フィールドに代置することもできることを明らかにしておく。
図29は、以上のようなブロックACKフレーム3100を伝送する、本発明の一実施形態による無線ステーション3200の構成を表わしたブロック図である。無線ステーション3200は、ブロックACK生成モジュール3210と、MACヘッダ判読モジュール3220と、送受信モジュール3230と、制御モジュール3240と、メモリ3250とを含んで構成されうる。
MACヘッダ判読モジュール3220は、受信されるデータフレームのMACヘッダから該当フレームが属するMSDUのシーケンス番号と、該当フレームのフラグメント番号、及び該当フレームが属するMSDUのフラグメント数を判読する。MSDUのシーケンス番号は、前記MACヘッダのSequence numberフィールド356から分かって、フラグメント番号はMACヘッダのFragment numberフィールド355から分かる。そして、MSDUのフラグメント数(ないし最終フラグメント番号)は、MACヘッダのSubtypeフィールド353から分かる。これは、MSDUが断片化されて伝送される場合、各フラグメントからなるデータフレームのTypeフィールド352は‘11’で満たされ、このとき、Subtypeフィールド353には、最終フラグメント番号が記録されるためである。
このように、MACヘッダから判読された情報は、メモリ3250に保存される。
ブロックACK生成モジュール3210は、メモリ3250に保存された前記MACヘッダから判読された情報を用いて本発明によるブロックACKフレーム3100のペイロードを生成させる。前記ペイロードは、BA Controlフィールド3150と、Block ACK Starting Sequence Controlフィールド3160と、Block ACK Bitmapフィールド3170とを含んで構成されうる。
BA Controlフィールド3150は、ビットマップを構成する方式のうち一般モード、圧縮モード、及び1ビットモードを区分するビット値が記録されるMode Selectionフィールド3152と、トラフィック識別子が記録されるTIDフィールド3153とを含み、Block ACK Bitmapフィールド3170に含まれるビット対の個数(m)、または1ビットモードの場合には、ACKビットの個数(k)が記録されるBitmap Lengthフィールド3151をさらに含みうる。
Block ACK Starting Sequence Controlフィールド3160は、ビットマップによって伝送確認を始めようとするフレームが属するMSDUの識別番号、すなわち、シーケンス番号が記録されるStarting Sequence Numberフィールド3162と伝送確認を始めようとするフレームのフラグメント番号が記録されるFragment Numberフィールド3161とで構成される。
Block ACK Bitmapフィールド3170は、少なくとも一つ以上のビット対3171などまたは少なくとも一つ以上のACKビット3175などで構成される。そして、ビット対またはACKビットに引き継いで全体Block ACK Bitmapフィールド3170をOctet単位に合わせるためのPaddingフィールド3174をさらに含みうる。
一般モード及び圧縮モードの場合に、Bitmapフィールド3170を構成するビット対3171などは、ACKビット3171aと、MSDUビット3171bからなる。ACKビット3171aには、該当フレームが正常的に伝送されたか否かを確認するビットが記録される。そして、MSDUビット3171bには、前記ACKビットが一つのフラグメント(または、MSDU)に対する伝送確認を表わすものなのか、一つのMSDUに属する現在フラグメント以後のすべてのフラグメントに対する伝送確認を表わすものなのかを区別するビット情報が記録される。
一方、1ビットモードである場合に、Bitmapフィールド3170を構成するACKビット3175などには、該当フレームが正常的に伝送されたか否かを確認するビットが記録される。
また、ブロックACK生成モジュール3210は、BA Controlフィールド3150、Block ACK Starting Sequence Controlフィールド3160、及びBlock ACK Bitmapフィールド3170からなる、ブロックACKフレーム3100のペイロードを生成させた以後には、前記ペイロード伝送のために必要なMACヘッダ3190を生成させて付け加えることによって、ブロックACKフレーム3100を生成させる。
制御モジュール3240は、無線ステーション3100内の他のモジュールの動作を制御するが、中央処理ユニット(CPU)、マイコン(Microcomputer)などによって具現されうる。
送受信モジュール3230は、他の無線ステーション、すなわち、伝送者からデータフレーム及びブロックACK要請フレーム310を受信し、ブロックACK生成モジュール3210によって生成されたブロックACKフレーム3100を前記伝送者に伝送する。このような送受信モジュール3230は、受信された無線信号を復調して二進データを復元し、伝送する二進データを無線信号に変調して空間上に伝送する。
今までの説明で、“モジュール(module)”という用語は、ソフトウェア構成要素(Software component)またはFPGA(field−programmable gate array)またはASIC(application−specific integrated circuit)のようなハードウェア構成要素(hardware component)を意味し、モジュールは所定の役割を実行する。しかし、モジュールは、ソフトウェアまたはハードウェアに限定される意味ではない。モジュールは、アドレッシング(addressing)できる記録媒体にあるように構成することもでき、一つまたはそれ以上のプロセッサを実行させるように構成することもできる。したがって、一例としてモジュールは、ソフトウェア構成要素、客体志向ソフトウェア構成要素、クラス(class)構成要素及びタスク(task)構成要素のような構成要素と、プロセス(processes)、関数(functions)、属性(properties)、プロシージャ(procedures)、サブルーチン(Sub−routines)、プログラムコード(program code)のセグメント(Segments)、ドライバー(drivers)、ファームウェア(firmwares)、マイクロコード(micro−codes)、回路(circuits)、データ(data)、データベース(databases)、データ構造(data structures)、テーブル(tables)、アレイ(arrays)、及び変数(variables)を含む。構成要素とモジュール内で提供される機能は、さらに小さな数の構成要素及びモジュールに結合されるか追加的な構成要素とモジュールとにさらに分離されうる。それだけでなく、構成要素及びモジュールは、通信システム内の一つまたはそれ以上のコンピューターを実行させるように具現されることもできる。
図30は、本発明の一実施形態による全体動作を表わしたフローチャートである。
まず、無線ステーション3200は、データフレームを他の無線ステーションから受信する(S310)。そして、前記データフレームのMACヘッダを判読する(S320)。MACヘッダ判読過程で、少なくとも前記データフレームが属するMSDUのシーケンス番号と、該当フレームのフラグメント番号とを判読する。そして、もし、前記データフレームが断片化されたMSDU中の一部フラグメントを含むとすれば、前記MSDUのフラグメント数も判読する。前記データフレームが断片化されたか否かはTypeフィールド352が‘11’であるかをチェックすれば分かり、そのときのフラグメント数はSubtypeフィールド353を判読することで分かる。そして、無線ステーション3200は、シーケンス番号、フラグメント番号、及び最終フラグメント番号(存在すれば)をメモリ3250に保存する(S330)。
前記S10ないしS30の過程は、無線ステーション3200が伝送者からブロックACK要請フレーム310を受信するまで反復される。もし、ブロックACK要請フレームを無線ステーション3200が受信したとすれば(S340のはい)、以後にはブロックACKフレームを生成させて伝送する過程(S350ないしS390)が実行される。
無線ステーション3200は、まず、Block ACK Starting Sequence Controlフィールド3160に伝送確認を始めようとするフレームが属するMSDUのシーケンス番号及び伝送確認を始めようとするフレームのフラグメント番号を記録する(S350)。
もし、ビットマップに記録されるビット対を圧縮モードで表現する場合には、圧縮モードによってBlock ACK Bitmapフィールド3170にビット対を記録し(S360)、一般モードで表現する場合には、一般モードによってBlock ACK Bitmapフィールド3170にビット対を記録する(S365)。そして、1ビットモードで表現しようとする場合には、1ビットモードによってBlock ACK Bitmapフィールド3170にACKビット3175などを記録する(S369)。このように、モードを選択する例として、圧縮モードと1ビットモードとにすべて表現可能な場合には、実際の各モードに対して構成したビットマップの大きさが小さな方のモードを選択できる。一般モードで表現可能な場合には、いつも1ビットモードでも表現可能なのでより効率的な1ビットモードを使うことが望ましい。
次に、各モードに該当するモードビットをBA Controlフィールド3150に記録する(S370)。
無線ステーション3200は、前記BA Controlフィールド3150と、Block ACK Starting Sequence Controlフィールド3160と、Block ACK Bitmapフィールド3170からなるペイロードにMACヘッダ3190を付け加えてブロックACKフレーム3100を生成させる(S380)。そして、生成されたブロックACKフレーム3100を前記他の無線ステーションに伝送する。
以上、添付された図面を参照して本発明の実施形態を説明したが、当業者ならば本発明がその技術的思想や必須的な特徴を変更せずとも、他の具体的な形態に実施できるということを理解できるであろう。したがって、前述した実施形態は、あらゆる面で例示的なものであり、限定的ではないと理解せねばならない。
一般的なバーストACKフレーム伝送方式を説明する図である。 IEEE802.15.3標準による遅延ACKフレームの構成を表わした図である。 IEEE802.11e標準によるブロックACKフレームの構成を表わした図である。 本発明の一実施形態によるバーストACKフレームの構成を表わした図である。 従来のIEEE802.11系列標準のMAC header及びIEEE802.15.3標準のMAC headerの構造を表わした図である。 さまざまな実施形態によってバーストACKフレームが如何に決定されるかを説明するための図である。 さまざまな実施形態によってバーストACKフレームが如何に決定されるかを説明するための図である。 さまざまな実施形態によってバーストACKフレームが如何に決定されるかを説明するための図である。 さまざまな実施形態によってバーストACKフレームが如何に決定されるかを説明するための図である。 さまざまな実施形態によってバーストACKフレームが如何に決定されるかを説明するための図である。 本発明の一実施形態による無線デバイスの構成を表わしたブロック図である。 バーストACK生成モジュールの詳細構成を表わしたブロック図である。 従来のIEEE802.15.3標準によるMAC Headerの構成を詳しく図示した図である。 本発明の一実施形態によるバーストACKフレーム生成過程を表わしたフローチャートである。 図14のS50段階に対するより詳しい過程を表わしたフローチャートである。 従来のブロックACK要請フレームの構成を表わした図である。 従来のブロックACKフレームの構成を表わした図である。 ブロックACKメカニズムを簡略に表わす図である。 本発明の一実施形態によるデータフレームの構成を図示した図である。 本発明の一実施形態によるブロックACKフレームの構成を図示した図である。 さまざまな実施形態によってブロックACKフレームが如何に構成されるかを説明するための図である。 さまざまな実施形態によってブロックACKフレームが如何に構成されるかを説明するための図である。 さまざまな実施形態によってブロックACKフレームが如何に構成されるかを説明するための図である。 さまざまな実施形態によってブロックACKフレームが如何に構成されるかを説明するための図である。 さまざまな実施形態によってブロックACKフレームが如何に構成されるかを説明するための図である。 さまざまな実施形態によってブロックACKフレームが如何に構成されるかを説明するための図である。 1ビットモードを使う場合にBlock ACK Bitmapフィールドの構成を表わした図である。 図25の場合を1ビットモードで表現した例を表わした図である。 本発明の一実施形態による無線ステーションの構成を表わしたブロック図である。 本発明の一実施形態による全体動作を表わしたフローチャートである。

Claims (33)

  1. 送信デバイスから複数のフレームを受信し、これに対して一つのACKフレームとして確認応答を行うACKフレーム伝送方法であって、
    (a)前記送信デバイスからフレームを受信し、前記受信されたフレームの識別情報を保存する段階と、
    (b)前記保存された識別情報を用いて、前記受信された各フレームに対するビット対の集合を記録することで第1フィールドを生成させる段階と、
    (c)前記生成された第1フィールドを含んでACKフレームを生成させる段階と、
    (d)前記生成されたACKフレームを前記送信デバイスに伝送する段階と、を含み、
    前記ビット対は、該当フレームが正常的に受信されたか否かを確認する第1ビットと、
    前記第1ビットが、該当フレーム一つに対する受信確認を表わすものなのか、該当フレーム以後のすべてのフラグメントに対する受信確認を表わすものなのかを区別する第2ビットで構成されることを特徴とするACKフレーム伝送方法。
  2. 前記(c)段階は、
    (c1)前記識別情報のうち最初の識別情報を記録する第2フィールドを生成させる段階を含むことを特徴とする請求項1に記載のACKフレーム伝送方法。
  3. 前記(c)段階は、
    (c2)前記第1フィールドがバイト単位にならない場合には、所定のダミービットを追加してバイト単位に作る段階をさらに含むことを特徴とする請求項2に記載のACKフレーム伝送方法。
  4. 前記識別情報は、
    前記受信されたフレームのMSDU number及びFragment numberを含むことを特徴とする請求項3に記載のACKフレーム伝送方法。
  5. 前記最初の識別情報は、前記MSDU numberの最も先立つ識別情報のうちFragment numberの最も先立つ識別情報であることを特徴とする請求項4に記載のACKフレーム伝送方法。
  6. 前記第1ビットは、該当フレームが正常的に受信された場合に1と、それ以外には0と記録され、
    前記第2ビットは、前記第1ビットが該当フレーム一つに対する受信確認を表わすものであれば1と、それ以外には0と記録されると仮定する時、前記(b)段階は、
    (b1)特定MSDU順番に対してMSDU numberが存在しなければ、ビット対を‘01’と記録し、存在すれば、前記順番のMSDUがフラグメントされたか否かを判断する段階と、
    (b2)前記MSDUがフラグメントされていない場合には、ビット対を‘1X’と記録する段階を含み、
    前記Xは、1または0のうち何れか一つの値であることを特徴とする請求項1に記載のACKフレーム伝送方法。
  7. 前記MSDUがフラグメントされた場合に前記(b)段階は、
    (b3)最大Fragment numberより小さなFragment順番のそれぞれに対して順次にビット対を記録する段階と、
    (b4)最大Fragment numberが最終Fragment numberと同じであれば、ビット対を‘1X’と記録する段階と、をさらに含むことを特徴とする請求項6に記載のACKフレーム伝送方法。
  8. 前記最大Fragment numberが最終Fragment numberと同じではなければ、ビット対を‘10’と記録し、相次ぐビット対を‘01’と記録する段階をさらに含むことを特徴とする請求項7に記載のACKフレーム伝送方法。
  9. 前記(b)段階は、
    前記送信デバイスからACKフレーム伝送要請を受けた場合に実行されることを特徴とする請求項1に記載のACKフレーム伝送方法。
  10. 送信ステーションから少なくとも一つ以上のデータフレームを受信し、これに対して一つのACKフレームとして確認応答を行うACKフレーム伝送方法であって、
    (a)前記送信ステーションからフレームを受信して少なくとも前記受信されたデータフレームの識別番号と、前記データフレームが断片化されたフレームである場合には、前記データフレームのフラグメント番号及び最終フラグメント番号を保存する段階と、
    (b)前記保存された情報を用いて前記受信されたデータフレームのそれぞれに対するビット対の集合を記録する段階であって、前記ビット対は該当フレームが正常的に伝送されたか否かを確認する第1ビットと、前記第1ビットが表わすデータフレームの範囲を表わす第2ビットとで構成される、段階と、
    (c)前記記録されたビット対の集合を含むACKフレームを生成させる段階と、
    (d)前記生成されたACKフレームを前記送信ステーションに伝送する段階と、を含むことを特徴とするACKフレーム伝送方法。
  11. 前記ビット対の集合は、可変大きさを有することを特徴とする請求項10に記載のACKフレーム伝送方法。
  12. 前記データフレームの範囲は、
    一つのフラグメントを表わす範囲と、または一つのMSDUに属する現在フラグメント以後のすべてのフラグメントを表わす範囲のうち一つであることを特徴とする請求項10に記載のACKフレーム伝送方法。
  13. 前記(c)段階は、
    前記ビット対の集合で伝送確認を始めようとするフレームの識別番号と、伝送確認を始めようとするフレームのフラグメント番号とを記録する段階を含むことを特徴とする請求項10に記載のACKフレーム伝送方法。
  14. 前記(c)段階は、
    前記ビット対の集合がOctet単位にならない場合には、Octet単位になるようにダミービットを追加する段階をさらに含むことを特徴とする請求項13に記載のACKフレーム伝送方法。
  15. 前記識別番号は、
    前記受信されたデータフレームが属するMSDUのシーケンス番号であることを特徴とする請求項10に記載のACKフレーム伝送方法。
  16. 前記最終フラグメント番号は、前記受信されたデータフレームのSubtypeフィールドに記録されることを特徴とする請求項10に記載のACKフレーム伝送方法。
  17. 前記第1ビットは、
    該当フレームが正常的に受信された場合に1と、それ以外には0と記録されることを特徴とする請求項10に記載のACKフレーム伝送方法。
  18. 前記第2ビットは、
    前記第1ビットが該当フレーム一つに対する伝送確認を表わすものであれば1と、それ以外には0と記録されることを特徴とする請求項10に記載のACKフレーム伝送方法。
  19. 前記(b)段階は、
    前記送信ステーションからACKフレーム伝送要請を受けた場合に実行されることを特徴とする請求項10に記載のACKフレーム伝送方法。
  20. 送信ステーションから少なくとも一つ以上のデータフレームを受信し、これに対して一つのACKフレームとして確認応答を行うACKフレーム伝送方法であって、
    (a)前記送信ステーションからフレームを受信して少なくとも前記受信されたデータフレームの識別番号と、前記データフレームが断片化されたフレームである場合には、前記データフレームのフラグメント番号及び最終フラグメント番号を保存する段階と、
    (b)前記保存された情報を用いて前記受信されたデータフレームそれぞれが正常的に伝送されたか否かを確認するビットを連続して記録する段階と、
    (c)前記記録されたビットを含むACKフレームを生成させる段階と、
    (d)前記生成されたACKフレームを前記送信ステーションに伝送する段階と、を含むことを特徴とするACKフレーム伝送方法。
  21. 前記ビットの集合は、可変大きさを有することを特徴とする請求項20に記載のACKフレーム伝送方法。
  22. 前記(c)段階は、
    前記ビット対の集合で伝送確認を始めようとするフレームの識別番号と、伝送確認を始めようとするフレームのフラグメント番号とを記録する段階を含むことを特徴とする請求項20に記載のACKフレーム伝送方法。
  23. 前記識別番号は、
    前記受信されたデータフレームのシーケンス番号であることを特徴とする請求項20に記載のACKフレーム伝送方法。
  24. 前記ビットは、
    該当フレームが正常的に受信された場合に1と、それ以外には0と記録されることを特徴とする請求項20に記載のACKフレーム伝送方法。
  25. 前記(b)段階は、
    前記送信ステーションからACKフレーム伝送要請を受けた場合に実行されることを特徴とする請求項20に記載のACKフレーム伝送方法。
  26. 送信デバイスから複数のフレームを受信し、これに対して一つのACKフレームとして確認応答を行うACKフレーム伝送装置であって、
    前記送信デバイスからフレームを受信する第1手段と、
    前記受信されたフレームの識別情報を保存する第2手段と、
    前記保存された識別情報を用いて、前記受信された各フレームに対するビット対の集合を記録することで第1フィールドを生成させ、前記生成された第1フィールドを含んでACKフレームを生成させる第3手段と、
    前記生成されたACKフレームを前記送信デバイスに伝送する第4手段と、を含み、
    前記ビット対は、該当フレームが正常的に受信されたか否かを確認する第1ビットと、
    前記第1ビットが該当フレーム一つに対する受信確認を表わすものなのか、該当フレーム以後のすべてのフラグメントに対する受信確認を表わすものなのかを区別する第2ビットで構成されることを特徴とするACKフレーム伝送装置。
  27. 前記第3手段は、
    前記識別情報のうち最初の識別情報を記録する第2フィールドを生成させることを特徴とする請求項26に記載のACKフレーム伝送装置。
  28. 前記第3手段は、
    前記第1フィールドがバイト単位にならない場合には、所定のダミービットを追加してバイト単位に作ることを特徴とする請求項27に記載のACKフレーム伝送装置。
  29. 前記識別情報は、
    前記受信されたフレームのMSDU number及びFragment numberを含むことを特徴とする請求項28に記載のACKフレーム伝送装置。
  30. 前記最初の識別情報は、前記MSDU numberの最も先立つ識別情報のうちFragment numberの最も先立つ識別情報であることを特徴とする請求項29に記載のACKフレーム伝送装置。
  31. 前記第3手段は、
    前記送信デバイスからACKフレーム伝送要請を受けることによって動作することを特徴とする請求項26に記載のACKフレーム伝送装置。
  32. 送信ステーションから少なくとも一つ以上のフレームを受信し、これに対して一つのACKフレームとして確認応答を行うACKフレーム伝送装置であって、
    前記送信ステーションからフレームを受信して少なくとも前記受信されたデータフレームの識別番号と、前記データフレームが断片化されたフレームである場合には、前記データフレームのフラグメント番号及び最終フラグメント番号を保存する手段と、
    前記保存された情報を用いて前記受信されたデータフレームそれぞれに対するビット対の集合を記録する手段であって、前記ビット対は該当フレームが正常的に伝送されたか否かを確認する第1ビットと、前記第1ビットが表わすデータフレームの範囲を表わす第2ビットで構成される、手段と、
    前記記録されたビット対の集合を含むACKフレームを生成させる手段と、
    前記生成されたACKフレームを前記送信ステーションに伝送する手段と、を含むことを特徴とするACKフレーム伝送装置。
  33. 送信ステーションから少なくとも一つ以上のデータフレームを受信し、これに対して一つのACKフレームとして確認応答を行うACKフレーム伝送装置であって、
    前記送信ステーションからフレームを受信して少なくとも前記受信されたデータフレームの識別番号と、前記データフレームが断片化されたフレームである場合には、前記データフレームのフラグメント番号及び最終フラグメント番号を保存する手段と、
    前記保存された情報を用いて前記受信されたデータフレームそれぞれが正常的に伝送されたか否かを確認するビットを連続して記録する手段と、
    前記記録されたビットを含むACKフレームを生成させる手段と、
    前記生成されたACKフレームを前記送信ステーションに伝送する手段と、を含むことを特徴とするACKフレーム伝送装置。
JP2007525531A 2004-08-12 2005-07-26 Ackフレーム伝送方法及び装置 Withdrawn JP2008509622A (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
KR1020040063599A KR100631736B1 (ko) 2004-08-12 2004-08-12 Ack 프레임 전송 방법 및 장치
KR1020040094099A KR100631742B1 (ko) 2004-11-17 2004-11-17 Ack 프레임 전송 방법 및 장치
PCT/KR2005/002420 WO2006016745A1 (en) 2004-08-12 2005-07-26 Method and apparatus for transmitting ack frame

Publications (1)

Publication Number Publication Date
JP2008509622A true JP2008509622A (ja) 2008-03-27

Family

ID=35276236

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2007525531A Withdrawn JP2008509622A (ja) 2004-08-12 2005-07-26 Ackフレーム伝送方法及び装置

Country Status (6)

Country Link
US (1) US20060034317A1 (ja)
EP (1) EP1626520A1 (ja)
JP (1) JP2008509622A (ja)
BR (1) BRPI0514128A (ja)
MX (1) MX2007001682A (ja)
WO (1) WO2006016745A1 (ja)

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2013542632A (ja) * 2010-09-03 2013-11-21 クゥアルコム・インコーポレイテッド アグリゲートmpdu(a−mpdu)数秘学およびmpduグループ化
JP2014525720A (ja) * 2011-09-02 2014-09-29 クゥアルコム・インコーポレイテッド 複数のデバイスからの通信を確認応答するためのシステムおよび方法
JP2015508981A (ja) * 2012-02-29 2015-03-23 クゥアルコム・インコーポレイテッドQualcomm Incorporated ブロック確認応答圧縮のための装置および方法
US9781627B2 (en) 2013-04-08 2017-10-03 Qualcomm Incorporated Systems and methods for generating and decoding short control frames in wireless communications
JP2019514283A (ja) * 2016-04-04 2019-05-30 ウィルス インスティテュート オブ スタンダーズ アンド テクノロジー インコーポレイティド フラグメンテーションを利用する無線通信方法及びそれを使用する無線通信端末
JP2019518365A (ja) * 2016-04-22 2019-06-27 クゥアルコム・インコーポレイテッドQualcomm Incorporated ブロック肯定応答の生成および選択ルール
JP2020061749A (ja) * 2015-09-25 2020-04-16 クゥアルコム・インコーポレイテッドQualcomm Incorporated ワイヤレスネットワークにおいて可変長ブロック確認応答フィールドをシグナリングおよび生成するためのシステムおよび方法
US10750403B2 (en) 2016-03-10 2020-08-18 Wilus Institute Of Standards And Technology Inc. Multi-user wireless communication method and wireless communication terminal using same
WO2024142901A1 (ja) * 2022-12-26 2024-07-04 ソニーグループ株式会社 無線通信装置、及び無線通信方法

Families Citing this family (67)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4319654B2 (ja) 2004-08-13 2009-08-26 三星電子株式会社 移動通信システムにおけるパケット受信結果報告方法
US7599363B2 (en) 2004-08-13 2009-10-06 Samsung Electronics Co. Ltd Method for reporting reception result of packets in mobile communication system
US7746866B2 (en) * 2005-05-13 2010-06-29 Intel Corporation Ordered and duplicate-free delivery of wireless data frames
US7561599B2 (en) * 2005-09-19 2009-07-14 Motorola, Inc. Method of reliable multicasting
US8363675B2 (en) * 2006-03-24 2013-01-29 Samsung Electronics Co., Ltd. Method and system for transmission of uncompressed video over wireless communication channels
US7979784B2 (en) * 2006-03-29 2011-07-12 Samsung Electronics Co., Ltd. Method and system for enhancing transmission reliability of video information over wireless channels
WO2007120090A1 (en) * 2006-04-19 2007-10-25 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for selective acknowledgement
ES2380787T3 (es) * 2006-05-16 2012-05-18 Nokia Siemens Networks Gmbh & Co. Kg Método para transmitir de manera segura mapas de bits ACK/NACK cortos en un proceso ARQ dentro de sistemas compatibles con EDGE
US20080002650A1 (en) * 2006-06-28 2008-01-03 Pengfei Xia Partially delayed acknowledgment mechanism for reducing decoding delay in WiHD
KR100773579B1 (ko) * 2006-07-14 2007-11-08 강릉대학교산학협력단 무선 데이터를 전송하기 위한 방법 및 이를 위한프로그램이 기록된 기록매체
US8111654B2 (en) * 2006-08-09 2012-02-07 Samsung Electronics Co., Ltd. System and method for wireless communication of uncompressed video having acknowledgement (ACK) frames
US8031691B2 (en) * 2006-08-09 2011-10-04 Samsung Electronics Co., Ltd. System and method for wireless communication of uncompressed video having acknowledgment (ACK) frames
JP4799396B2 (ja) * 2006-12-25 2011-10-26 株式会社東芝 無線通信装置
JP2008227642A (ja) * 2007-03-09 2008-09-25 Hitachi Ltd 再送制御方法、および無線通信システム
KR100984811B1 (ko) * 2007-03-27 2010-10-01 삼성전자주식회사 데이터를 송수신하는 장치 및 방법
US20080259891A1 (en) * 2007-04-17 2008-10-23 Telefonaktiebolaget Lm Ericsson (Publ) Multiple packet source acknowledgement
WO2009020288A1 (en) 2007-08-09 2009-02-12 Samsung Electronics Co., Ltd. Apparatus and method for searching for erroneous data
US8127206B2 (en) * 2007-09-13 2012-02-28 Samsung Electronics Co., Ltd. System and method for wireless communication of uncompressed video having reed-solomon code error concealment
US7826436B2 (en) * 2007-10-01 2010-11-02 Samsung Electronics Co., Ltd. Method and system for wireless communication of data with a fragmentation pattern and low-density parity-check codes
JP5280781B2 (ja) * 2007-10-30 2013-09-04 三星電子株式会社 受信確認フレームの生成方法及びその装置
US8681755B2 (en) 2007-10-30 2014-03-25 Samsung Electronics Co., Ltd. Method and apparatus for generating data frame in wireless personal area network
US8205126B2 (en) * 2007-11-27 2012-06-19 Samsung Electronics Co., Ltd. System and method for wireless communication of uncompressed video using selective retransmission
US20110069669A1 (en) * 2009-09-11 2011-03-24 Research In Motion Limited System and methods for sending and receiving pan (piggy-backed ack/nack) so as to avoid decoding confusion
US10225047B2 (en) 2009-12-08 2019-03-05 Qualcomm Incorporated Method and apparatus for multicast block acknowledgement
KR101758909B1 (ko) * 2010-02-18 2017-07-18 엘지전자 주식회사 무선 랜에서 수신 확인 전송 방법 및 장치
WO2013037322A1 (zh) 2011-09-16 2013-03-21 华为技术有限公司 分片接收和发送的方法以及分片接收和发送的装置
US9363707B2 (en) 2011-12-29 2016-06-07 Qualcomm Incorporated Systems and methods for generating and decoding short control frames in wireless communications
US8832515B2 (en) 2012-02-29 2014-09-09 Qualcomm Incorporated Block acknowledgement mechanism including sequence number acknowledgement and retry bit
US9253290B2 (en) * 2012-02-29 2016-02-02 Qualcomm Incorporated Apparatus and methods for block acknowledgment compression
TWI532352B (zh) * 2012-05-04 2016-05-01 財團法人資訊工業策進會 無演進封包核心直接通訊系統及其通訊連接方法
US9525520B2 (en) * 2012-12-21 2016-12-20 Qualcomm Incorporated Block acknowledgement selection rules
US20150036673A1 (en) * 2013-07-30 2015-02-05 Qualcomm Incorporated Systems and methods for communicating multi-destination traffic in a wireless network
US10432529B2 (en) 2013-09-19 2019-10-01 Connectivity Systems Incorporated Enhanced large data transmissions and catastrophic congestion avoidance over IPv6 TCP/IP networks
KR102233358B1 (ko) * 2014-10-22 2021-03-29 삼성전자주식회사 멀티 레이트 전송을 위한 블록 애크 기법과 링크 어댑테이션을 지원하는 코디네이터 및 노드의 동작 방법
US9929847B2 (en) 2014-12-23 2018-03-27 Qualcomm Incorporated Shortened block acknowledgement with fragmentation acknowledgement signaling
BR112017016232A2 (pt) * 2015-01-28 2018-03-27 Qualcomm Inc ?método e aparelho para confirmação de bloco multicast
US10305638B2 (en) 2015-03-04 2019-05-28 Wilus Institute Of Standards And Technology Inc. Wireless communication terminal and wireless communication method for multi-user concurrent transmission
CN106161583B (zh) * 2015-05-12 2020-02-21 华为技术有限公司 一种块确认帧的传输方法及设备
US10469210B2 (en) 2015-11-24 2019-11-05 Marvell World Trade Ltd. Acknowledgment data unit for data unit fragment
WO2017091725A1 (en) * 2015-11-24 2017-06-01 Marvell Semiconductor, Inc. Acknowledgment data unit for data unit fragment
WO2017094331A1 (ja) * 2015-11-30 2017-06-08 ソニー株式会社 情報処理装置、通信システム、情報処理方法およびプログラム
US11177908B2 (en) 2016-03-03 2021-11-16 Panasonic intellectual property Management co., Ltd Communication method and communication apparatus for block acknowledgment transmission
US10993145B2 (en) * 2016-04-18 2021-04-27 Sony Corporation Communication device, communication method, and program
US11032257B1 (en) 2017-12-08 2021-06-08 Rankin Labs, Llc Method for covertly delivering a packet of data over a network
US11861025B1 (en) 2018-01-08 2024-01-02 Rankin Labs, Llc System and method for receiving and processing a signal within a TCP/IP protocol stack
US10725743B2 (en) 2018-01-22 2020-07-28 John Rankin System and method for generating random numbers
WO2019152573A1 (en) 2018-01-31 2019-08-08 John Rankin System and method for secure communication using random blocks or random numbers
WO2019168978A1 (en) 2018-02-28 2019-09-06 John Rankin System and method for expanding a set of random values
WO2019183543A1 (en) 2018-03-23 2019-09-26 John Rankin System and method for identifying a speaker's community of origin from a sound sample
US11341985B2 (en) 2018-07-10 2022-05-24 Rankin Labs, Llc System and method for indexing sound fragments containing speech
US11689543B2 (en) 2018-08-10 2023-06-27 Rankin Labs, Llc System and method for detecting transmission of a covert payload of data
WO2020033540A1 (en) 2018-08-10 2020-02-13 John Rankin System and method for covertly transmitting a payload of data
WO2020041390A1 (en) 2018-08-21 2020-02-27 John Rankin System and method for scattering network traffic across a number of disparate hosts
WO2020132173A1 (en) 2018-12-19 2020-06-25 John Rankin Hidden electronic file systems
US11989320B2 (en) 2018-12-19 2024-05-21 Rankin Labs, Llc Hidden electronic file system within non-hidden electronic file system
US11526357B2 (en) 2019-01-21 2022-12-13 Rankin Labs, Llc Systems and methods for controlling machine operations within a multi-dimensional memory space
US10901739B2 (en) 2019-01-21 2021-01-26 Rankin Labs, Llc Systems and methods for controlling machine operations using stack entries comprising instruction configuration parameters
WO2020154223A1 (en) 2019-01-21 2020-07-30 John Rankin Systems and methods for processing network traffic using dynamic memory
US10908133B2 (en) 2019-04-17 2021-02-02 Rankin Labs, Llc System and method for detecting hidden chemicals within objects in a non-invasive manner
US11487674B2 (en) 2019-04-17 2022-11-01 Rankin Labs, Llc Virtual memory pool within a network which is accessible from multiple platforms
US11729184B2 (en) 2019-05-28 2023-08-15 Rankin Labs, Llc Detecting covertly stored payloads of data within a network
WO2020243249A1 (en) 2019-05-28 2020-12-03 John Rankin Covertly storing a payload of data within a network
WO2020243244A1 (en) 2019-05-28 2020-12-03 John Rankin Supporting a virtual memory area at a remote computing machine
WO2021025729A1 (en) 2019-08-07 2021-02-11 John Rankin Determining proximity and attraction of objects within a coordinate system
WO2021025728A1 (en) 2019-08-07 2021-02-11 John Rankin System and method for indirect advertising
US11665588B2 (en) * 2020-01-07 2023-05-30 Mediatek Singapore Pte. Ltd Extended sequence control for fragmented frames in WLAN
US11699037B2 (en) 2020-03-09 2023-07-11 Rankin Labs, Llc Systems and methods for morpheme reflective engagement response for revision and transmission of a recording to a target individual

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA1220830A (en) * 1984-12-28 1987-04-21 David S. Drynan Transmitting sequence numbers of information in a packet data transmission system
GB9915593D0 (en) * 1999-07-02 1999-09-01 Nokia Telecommunications Oy Data acknowledgement
US6658619B1 (en) * 2000-10-06 2003-12-02 Ericsson Inc. Systems and methods for implementing hierarchical acknowledgement bitmaps in an ARQ protocol
FR2818844B1 (fr) * 2000-12-22 2003-03-07 Mitsubishi Electricite Procede de transmission de donnees entre au moins un emetteur et au moins un recepteur, emetteur, recepteur et systeme de transmission correspondants
US20030135640A1 (en) * 2002-01-14 2003-07-17 Texas Instruments Incorporated Method and system for group transmission and acknowledgment
US7420921B2 (en) * 2002-05-17 2008-09-02 Broadcom Corporation Aggregated fragment acknowledgement in local area network
KR100614638B1 (ko) * 2003-02-26 2006-08-23 삼성전자주식회사 고속의 무선 통신에 적합한 하이브리드형 직렬 주변 장치 인터페이스 회로 및 그 방법
US20050111416A1 (en) * 2003-11-24 2005-05-26 Boris Ginzburg Method, system and device of fragmentation with group acknowledgement in wireless networks
US7161909B2 (en) * 2004-04-23 2007-01-09 Samsung Electronics Co., Ltd. Method and system for acknowledging the receipt of a transmitted data stream in a wireless communication system
US8223647B2 (en) * 2004-07-21 2012-07-17 Nokia Corporation System and method for increasing data throughout using a block acknowledgement

Cited By (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2013542632A (ja) * 2010-09-03 2013-11-21 クゥアルコム・インコーポレイテッド アグリゲートmpdu(a−mpdu)数秘学およびmpduグループ化
JP2014525720A (ja) * 2011-09-02 2014-09-29 クゥアルコム・インコーポレイテッド 複数のデバイスからの通信を確認応答するためのシステムおよび方法
US9100177B2 (en) 2011-09-02 2015-08-04 Qualcomm Incorporated Systems and methods for acknowledging communications from a plurality of devices
JP2016027727A (ja) * 2011-09-02 2016-02-18 クゥアルコム・インコーポレイテッドQualcomm Incorporated 複数のデバイスからの通信を確認応答するためのシステムおよび方法
JP2015508981A (ja) * 2012-02-29 2015-03-23 クゥアルコム・インコーポレイテッドQualcomm Incorporated ブロック確認応答圧縮のための装置および方法
US9781627B2 (en) 2013-04-08 2017-10-03 Qualcomm Incorporated Systems and methods for generating and decoding short control frames in wireless communications
JP7023918B2 (ja) 2015-09-25 2022-02-22 クゥアルコム・インコーポレイテッド ワイヤレスネットワークにおいて可変長ブロック確認応答フィールドをシグナリングおよび生成するためのシステムおよび方法
JP2020061749A (ja) * 2015-09-25 2020-04-16 クゥアルコム・インコーポレイテッドQualcomm Incorporated ワイヤレスネットワークにおいて可変長ブロック確認応答フィールドをシグナリングおよび生成するためのシステムおよび方法
US11700546B2 (en) 2016-03-10 2023-07-11 Wilus Institute Of Standards And Technology Inc. Multi-user wireless communication method and wireless communication terminal using same
US11304094B2 (en) 2016-03-10 2022-04-12 Wilus Institute Of Standards And Technology Inc. Multi-user wireless communication method and wireless communication terminal using same
US10750403B2 (en) 2016-03-10 2020-08-18 Wilus Institute Of Standards And Technology Inc. Multi-user wireless communication method and wireless communication terminal using same
JP2020195163A (ja) * 2016-04-04 2020-12-03 ウィルス インスティテュート オブ スタンダーズ アンド テクノロジー インコーポレイティド フラグメンテーションを利用する無線通信方法及びそれを使用する無線通信端末
JP6991290B2 (ja) 2016-04-04 2022-01-12 ウィルス インスティテュート オブ スタンダーズ アンド テクノロジー インコーポレイティド フラグメンテーションを利用する無線通信方法及びそれを使用する無線通信端末
JP6992138B2 (ja) 2016-04-04 2022-01-13 ウィルス インスティテュート オブ スタンダーズ アンド テクノロジー インコーポレイティド フラグメンテーションを利用する無線通信方法及びそれを使用する無線通信端末
US11240705B2 (en) 2016-04-04 2022-02-01 Wilus Institute Of Standards And Technology Inc. Wireless communication method using fragmentation and wireless communication terminal using same
JP2022022338A (ja) * 2016-04-04 2022-02-03 ウィルス インスティテュート オブ スタンダーズ アンド テクノロジー インコーポレイティド フラグメンテーションを利用する無線通信方法及びそれを使用する無線通信端末
JP2020198641A (ja) * 2016-04-04 2020-12-10 ウィルス インスティテュート オブ スタンダーズ アンド テクノロジー インコーポレイティド フラグメンテーションを利用する無線通信方法及びそれを使用する無線通信端末
US11683718B2 (en) 2016-04-04 2023-06-20 Wilus Institute Of Standards And Technology Inc. Wireless communication method using fragmentation and wireless communication terminal using same
US11683719B2 (en) 2016-04-04 2023-06-20 Wilus Institute Of Standards And Technology Inc. Wireless communication method using fragmentation and wireless communication terminal using same
JP2019514283A (ja) * 2016-04-04 2019-05-30 ウィルス インスティテュート オブ スタンダーズ アンド テクノロジー インコーポレイティド フラグメンテーションを利用する無線通信方法及びそれを使用する無線通信端末
JP7358442B2 (ja) 2016-04-04 2023-10-10 ウィルス インスティテュート オブ スタンダーズ アンド テクノロジー インコーポレイティド フラグメンテーションを利用する無線通信方法及びそれを使用する無線通信端末
JP2019518365A (ja) * 2016-04-22 2019-06-27 クゥアルコム・インコーポレイテッドQualcomm Incorporated ブロック肯定応答の生成および選択ルール
WO2024142901A1 (ja) * 2022-12-26 2024-07-04 ソニーグループ株式会社 無線通信装置、及び無線通信方法

Also Published As

Publication number Publication date
BRPI0514128A (pt) 2008-05-27
MX2007001682A (es) 2007-04-23
US20060034317A1 (en) 2006-02-16
WO2006016745A1 (en) 2006-02-16
EP1626520A1 (en) 2006-02-15

Similar Documents

Publication Publication Date Title
JP2008509622A (ja) Ackフレーム伝送方法及び装置
US8054813B2 (en) Method of transmitting aggregated MAC MPDUs in WLAN system and system therefor
JP4440037B2 (ja) 通信装置及び通信方法
JP4331088B2 (ja) 通信装置および通信方法
US10004069B2 (en) Wireless Terminal
KR100678943B1 (ko) 블록 ack 프레임 전송방법 및 장치
US7924805B2 (en) Communication apparatus, communication system, and communication control program
CN104244324B (zh) 无线链路传输方法和系统
JP4374001B2 (ja) 通信装置、通信方法、および通信システム
JP2005312060A (ja) 無線近距離通信網での伝送されたデータストリームの受信通知方法及びシステム
US20060013256A1 (en) Wireless communication device and method for aggregating MAC service data units
CN101010913A (zh) 在无线个域网中应答发送的数据流的接收的方法和系统
JP6416256B2 (ja) チャネルアクセス延期メカニズム
JP2017502564A (ja) 拡張ブロック確認応答プロトコル
US20220416946A1 (en) Communication method and apparatus
KR100631742B1 (ko) Ack 프레임 전송 방법 및 장치
KR100631736B1 (ko) Ack 프레임 전송 방법 및 장치
JP7521607B2 (ja) 送信局及び受信局
CN116711408A (zh) 发送站以及接收站

Legal Events

Date Code Title Description
A761 Written withdrawal of application

Free format text: JAPANESE INTERMEDIATE CODE: A761

Effective date: 20090126