MAC header compression for use with frame aggregation
12 claims: 5 independent, 7 dependent
- 11つまたは複数の MAC サブフレームについて集合体 PHY フレームを生成する方法であって、 (a)前記1つまたは複数の MAC サブフレーム のヘ ッダから MAC ヘッダ単位を生成するステップ を含み 、前記 MAC ヘッダ単位 は、前記1つまたは複数のMACサブフレーム の各 MAC サブフレームに適用可能なヘッダ情報を有 し、さらに 、 (b)前記 1つまたは複数のMACサブフレームの 各 MAC サブフレームについて、圧縮ヘッダ部分 と ペイロード・データ部分 と を有する 圧縮ヘッダ データ単位を生成するステップと、 (c)生成された 前記MAC ヘッダ単位 と生成された前記1つまたは複数の圧縮ヘッダ データ単位 と を含 む集 合体 PHY フレームを 形成 するステッ プとを含み、 前記MACヘッダ単位は、(i)フレーム制御フィールド、及び(ii)前記MACヘッダ単位についてのエラー検出/補正情報を有するフレーム・チェック・シーケンス(FCS)、を有し、 前記1つまたは複数の圧縮ヘッダデータ単位の各々は、それぞれ(i)フレーム制御フィールド、及び(ii)前記圧縮ヘッダデータ単位についてのエラー検出/補正情報を有するフレーム・チェック・シーケンス(FCS)、を有する、 方法。
- 2ステップ(b)において各 MAC サブフレームについて、 前記圧縮ヘッダ部分 は 前記 MAC サブフレームに適用可能なヘッダ情報を有し、 そして、 前記ペイロード・データ部分 は 前記 MAC サブフレームのユーザ・データを有 するものであり、さらに、 前記 1つまたは複数のMACサブフレーム のすべ てが単 一 の宛先に送信されており、そして、 前記 1つまたは複数のMACサブフレーム の各 MAC サブフレームについて、 対応する圧縮ヘッダデータ単位の圧縮ヘッダ部分は、対応するMACサブフレームのヘッダ情報のすべてではないヘッダ情報を有し、そして、 前記圧縮ヘッダ部分および前記 MAC ヘッダ単位 は 合わせて、前記 対応するMAC サブフレームの前記ヘッダ情報のすべてを有する、請求項1に記載の方法。
- 3前記 MAC ヘッダ単位を少なくとも1回複製するステップをさらに 含み 、ステップ(c) は 、前記 MAC ヘッダ単位の少なくとも1つのコピー がす べての対応する 圧縮ヘッダ データ単位に先行するように、前記 MAC ヘッダ単位および 前記1つまたは複数の圧縮ヘッダ データ単位の位置を順序付けする ステップを含む 、請求項1に記載の方法。
- 4ステップ(c) は 、 前記 MAC ヘッダ単位 と 前記 1つまたは複数の圧縮ヘッダ データ単位 と からシーケンスを生成する ステップ と、 (i)前記MACヘッダ単位と当該MACヘッダ単位に隣接する圧縮ヘッダデータ単位との間、及び(ii) 隣接 する2つの圧縮ヘッダデータ 単位 の各々の 間 、 に それぞれ デリミタを挿入する ステップ とを 含む 、請求項1に記載の方法。
- 5前記 MAC ヘッダ単位および前記圧縮ヘッダ部分の 各々は 、前記 MAC ヘッダ単位を前記集合体 PHY フレーム の対 応する 圧縮ヘッダ データ単位の1つまたは複数に整合させることを可能にするヘッダ・アイデンティティ(HID)フィールドを有し 、 前 記 MAC ヘッダ単位 はユ ーザ・データを有さず 、そして、 前 記圧縮ヘッダ部分 は 、前記 1つまたは複数のMACサブフレームの 他の MAC サブフレームに 関して対応するMAC サブフレームの位置を示すシーケンス制御フィールドをさらに 含む、請 求項1に記載の方法。
- 6前記MACヘッダ単位のフレーム制御フィールドは、IEEE802.11規格に準拠し、そして前記MACヘッダ単位をMACヘッダ単位として識別するタイプ値及びサブタイプ値を有し、さらに、 前記1つまたは複数の圧縮ヘッダデータ単位の各々について、前記圧縮ヘッダデータ単位のそれぞれのフレーム制御フィールドは、IEEE802.11規格に準拠し、そして前記圧縮ヘッダデータ単位を圧縮ヘッダデータ単位として識別するタイプ値及びサブタイプ値を有する、請求項1に記載の方法。
- 7前記MACヘッダ単位はユーザ・データを有さない、請求項1に記載の方法。
- 8受信デバイスによってパケットを処理する方法であって、 1つまたは複数の MAC サブフレームに対応する集合体 PHY フレームを有する 物理層 パケットを受信する ステップを含み 、 前記集合体 PHY フレーム は 、 MAC ヘッダ単位 と 、 1つまたは複数のMAC サブフレーム の各々 について 、対応する圧縮ヘッダ データ単位 とを含み 、 前記 MAC ヘッダ単位 は 、 前記 1つまたは複数の MAC サブフレーム の各々 に適用可能なヘッダ情報を有し、 そして、 前記 圧縮ヘッダ データ単位 の各々は圧 縮ヘッダ部分 と ペイロード・データ部分 と を有し、 前記方法は さらに、 前記集合体PHYフレームの 前記 MAC ヘッダ単位 と圧縮ヘッダ データ単位 と に基づいて、前記1つまたは複数の MAC サブフレーム の対 応する MAC サブフレームを再構築する ステップを含み、 前記MACヘッダ単位は、(i)フレーム制御フィールド、及び(ii)前記MACヘッダ単位についてのエラー検出/補正情報を有するフレーム・チェック・シーケンス(FCS)、を有し、そして、 前記1つまたは複数の圧縮ヘッダデータ単位の各々は、それぞれ(i)フレーム制御フィールド、及び(ii)前記圧縮ヘッダデータ単位についてのエラー検出/補正情報を有するフレーム・チェック・シーケンス(FCS)、を有する、 方法。
- 9前記圧縮ヘッダデータ単位の 前記圧縮ヘッダ部分 は、対応するMAC サブフレームに特有 のヘ ッダ情報を有し、 前記圧縮ヘッダデータ単位の 前記ペイロード・データ部分 は前記対応するMAC サブフレーム のユ ーザ・データを有し、 前記 MAC ヘッダ単位の前記ヘッダ情報 は前記 1つまたは複数の MAC サブフレームのヘッダに共通の情報である、請求項 8 に記載の方法。
- 10前記 MAC ヘッダ単位および前記圧縮ヘッダ部分の 各々はヘ ッダ・アイデンティティ(HID)フィールドを有し、 前記方法が、 前記HIDフィールド の値 を使用して、前記 MAC ヘッダ単位 を対 応する 圧縮ヘッダ データ 単位 に整合させる ステップと、 前 記 MAC ヘッダ単位および 前記圧縮ヘッダ データ単位のそれぞれについて、前記エラー検出/補正情報に基づいて1つまたは複数のエラーを補正する ステップとを含み 、前記圧縮ヘッダ部分 は 、前記1つまたは複数の MAC サブフレームの他の MAC サブフレームに関して 対 応する MAC サブフレームの位置を示すシーケンス制御フィールドを 含む 、請求項 8 に記載の方法。
- 11前記MACヘッダ単位のフレーム制御フィールドは、IEEE802.11規格に準拠し、そして前記MACヘッダ単位をMACヘッダ単位として識別するタイプ値及びサブタイプ値を有し、さらに、 前記1つまたは複数の圧縮ヘッダデータ単位の各々について、前記圧縮ヘッダデータ単位のそれぞれのフレーム制御フィールドは、IEEE802.11規格に準拠し、そして前記圧縮ヘッダデータ単位を圧縮ヘッダデータ単位として識別するタイプ値及びサブタイプ値を有する、請求項8に記載の方法。
- 12前記MACヘッダ単位はユーザ・データを有さない、請求項8に記載の方法。
Independent claims12
38 paragraphs, as filed
This application claims the priority of US Patent Provisional Application No. 60/569313, filed May 7, 2004, entitled "MAC Header Compression Mechanism That Increases Wireless Medium Effeciency When Combined with Frame Aggregation". The subject matter of this application is (i) U.S. Patent Application No. 10/955947, filed September 30, 2004, named "Frame Aggregation Format", and (ii) U.S. Patent Application No. 10/955943, September 2004. A 30-day filing, relating to the subject matter of the name "Frame Aggregation", both incorporated herein by reference.
The present invention relates to communication devices, and more specifically to wireless local area network (WLAN) devices.
A typical WLAN system can include one or more stations (STA), such as mobile phones, laptop computers, and / or handheld computers, each of which is generally available. Equipped with a good WLAN PC card. With a WLAN PC card, the STA is (i) directly in the same service area and / or (ii) indirectly through the network server when placed in a different service area, within the STA itself. It becomes possible to communicate with. Network servers provide support for communication between STAs in different service areas via access points (APs) located in those service areas. A basic service set (BSS) is formed between STAs or between APs and one or more STAs within the same service area.
An example of a WLAN network is a network that complies with standards developed and proposed by the Institute of Electrical and Electronic Engineers (IEEE) 802.11 Conference (in this specification, according to the IEEE 802.11 family of standards). (Refered as a working network), this standard is incorporated herein by reference. In 802.11WLAN networks, all messages transmitted between different STAs in the same service area are usually transmitted over the AP rather than directly between the STAs. Such centralized wireless communication offers significant advantages in terms of ease of communication links, as well as power savings. However, if necessary or appropriate, 802.11 WLAN networks can also be configured to carry messages directly between two STAs in so-called IBSS (Independent Basic Services Set) mode.
Most WLAN networks are organized as a series of layers (tier network architecture), with each layer built on top of the preceding layer. The purpose of each lower layer is to provide services to the higher layers and at the same time block them from the implementation details of the lower layers. Between each pair of adjacent layers is an interface that establishes their services. The lowest layer is the data link and physical layer. The function of the data link layer is to divide the input data into data frames and sequentially transmit the frames on the physical layer. Each data frame contains a header that contains frame control information and sequence information. The function of the physical layer is to transfer information on a communication medium.
Figure 1 shows a traditional technology framing sequence of user data in a typical 802.11 compliant WLAN. More specifically, six protocol layers are shown in Figure 1: Application Layer 150, Transmission Control Protocol (TCP) Layer 151, Internet Protocol (IP) Layer 152, Logical Link Control (LLC) Layer 153 (Data Data). Link layer sublayer), medium access control (MAC) layer 154 (also a data link layer sublayer), and physical (PHY) layer 155. User data 101 is provided to application layer 150, which generates application data 102 by attaching application layer header 110 to user data. The application data 102 is provided to the TCP layer 151, which attaches a TCP header 111 to the application data 102 to form the TCP segment 103. The IP layer 152 attaches the IP header 112 to the TCP segment 103 to form the IP frame 104. IP frame 104 can be a conventional TCP / IP packet commonly used in many data networking applications, including some that are not necessarily 802.11 compliant. The LLC layer 153 provides a uniform interface between the MAC layer 154 and the higher layers, thereby providing the transparency of the type of WLAN used to transport TCP / IP packets. The LLC layer 153 attaches the interface information to the IP frame 104 as the LLC header 113 in order to form the LLC frame 105.
In 802.11-compliant WLANs, the physical device is the radio and the physical communication medium is free space. The MAC device and the PHY layer signaling control device ensure that the two WLAN terminals are communicating with the appropriate frame format and protocol. The WLAN IEEE 802.11 standard ensures communication between two (or more) peer PHY devices and related peer MAC devices. According to the 802.11 WLAN data communication protocol, each packet frame forwarded between a MAC device and a PHY device has a PHY header, a MAC header, MAC data, and error checking fields.
The traditional format of MAC layer frames in 802.11 compliant WLAN systems attaches MAC header 114 and frame check sequence (FCS) 115 to LLC frame 105 to form MAC frame 106. MAC header 114 includes fields for frame control, duration identification (ID), source and destination addresses, and data sequence control (number). The data sequence control field provides sequence numbering information that allows the receiver to reconstruct the user data stream from the sequence of MAC frames. The PHY layer 155 forms the physical layer packet frame 107 by attaching the PHY header 118 to the MAC frame 106. The PHY header 118 includes a preamble 116 and a physical layer convergence protocol (PLCP) header 117. The PLCP header 117 identifies, for example, the data rate and length at PHY layer 155, and the preamble 116 (i) for detecting and / or synchronizing frames with input, and (ii) transmitters and receivers. It can be used by the receiving device to estimate the channel characteristics between.
The effective data throughput or efficiency of the IEEE802.11 WLAN protocol is affected by several sources of overhead. For example, overhead begins at the PHY layer (eg, preamble 116 and PLCP header 117) and the MAC layer (eg, MAC header 114, FCS115, acknowledgment affirmative (ACK) frames, interframe spacing (IFS), and conflict overhead). Can be done. Some efficiency improvements are about quality of service (QoS) by incorporating frame bursting and block response acknowledgment (block ACK) mechanisms that help reduce ACK frames, IFS, and conflict-related overhead. Achieved in IEEE 802.11e enhancement. However, it may still be desirable to further reduce the overhead by targeting other overhead sources.<patcit num="1"><text>U.S. Patent Application No. 60/569313, filed May 7, 2004, entitled "MAC Header Compression Mechanism That Increases Wireless Medium Effeciency When Combined with Frame Aggregation"</text></patcit><patcit num="2"><text>U.S. Patent Application No. 10/955947, filed September 30, 2004, named "Frame Aggregation Format"</text></patcit><patcit num="3"><text>U.S. Patent Application No. 10/955943, filed September 30, 2004, named "Frame Aggregation"</text></patcit>
<p> The problems of the prior art are addressed by a method of generating an aggregate frame having a header unit, according to the principles of the present invention. The header unit carries MAC header information applicable to one or more data units of the aggregate frame. The overhead associated with MAC headers can be significantly reduced because each data unit in the aggregate frame no longer needs to carry complete MAC header information. In the receiver, the complete MAC header corresponding to a data unit combines (i) matching the appropriate header and data units with each other, and (ii) combining the information present in the compressed header portion of the header and data units. By doing so, it will be rebuilt. Embodiments of the present invention improve data throughput, for example, in an entertainment network having a paired source and destination device (eg, a DVD player and an LCD screen) in which a relatively large amount of data is flowed from the paired source to the destination device. Can be made to.</p>
<p> According to one embodiment, the present invention is a method of generating an aggregate frame for one or more subframes, wherein the method is (a) from the header of the first set of the one or more subframes. Generate a header unit, and the header unit has header information applicable to each subframe of the first set, and (b) has a compressed header part and a payload data part for each subframe of the first set. It comprises generating data units and (c) forming an aggregate frame containing the generated header units and data units. According to another embodiment, the invention is a method of processing a packet by a receiving device, the method comprising receiving a packet having an aggregate frame corresponding to one or more subframes. The body frame comprises a header unit and a data unit for each subframe, the header unit has header information applicable to one or more subframes, and the data unit is a compressed header part and a payload data part. And further comprises reconstructing the corresponding subframes of one or more subframes based on header and data units.</p><p> Other aspects, features, and advantages of the present invention will become more fully apparent from the following detailed description, the accompanying claims, and the accompanying drawings.</p>
As used herein, the reference "one embodiment" or "embodiment" includes specific features, structures, or properties described in connection with an embodiment in at least one embodiment of the invention. Means that you can. The appearance of the phrase "in one embodiment" in various parts of the specification does not necessarily refer to the same embodiment, and separate or alternative embodiments are not exclusive to each other. Absent.
The '947 and '943 applications cited above address the problems of prior art by proposing a frame aggregation mechanism. More specifically, frame aggregation is used to combine several separate higher layer frames with user data into a single PHY level frame, thereby transmitting user data per PHY frame. The amount is increased. Some frames are (A) frames with the same destination address and the same PHY layer data rate, (B) frames with one or more destination addresses and the same PHY layer data rate, and (C) each frame. Can be aggregated for one or more destination addresses that have one of several possible PHY layer data rates. Frame aggregation improves efficiency by reducing both PHY overhead (eg, preamble and PLCP header overhead) and MAC overhead (eg, conflicting overhead).
FIG. 2 shows one exemplary frame aggregation method disclosed in the '947 and '943 applications. More specifically, the frame aggregation of FIG. 2 is performed below MAC layer 205 by forming several MAC frames into dummy MAC frames and then processing the dummy MAC frames by PHY layer 211. To. By aggregating frames below the MAC layer, it is possible to check each LLC frame independently of other frames, because the MAC frame is the FCS field attached to the LLC frame. This is because it has error detection information such as frame inspection total in the error control field such as. In addition, separate MAC frames are sent with their own header and destination address information, allowing MAC frames to be sent to different destinations.
LLC frames 210 (1) to 201 (M) (M is a positive integer) of LLC layer 202 are passed to MAC layer 205. Each LLC frame 201 (n) (1 n M) is formed in the MAC subframe 216 (n) by attaching the MAC header 203 (n) and the MAC FCS 204 (n). The MAC subframes 216 (1) to 216 (M) are then combined with the dummy MAC frame 206. The intermediate aggregation layer 207 then sets the optional (i) dummy header 208 and / or (ii) forward error correction / detection (FEC) field 209 to the dummy MAC frame to form the aggregate MAC frame 210. Attached to 206. The PHY layer 211 forms a PHY packet 212 from the aggregate MAC frame 210 by attaching a preamble 213 and a PLCP header 214.
Dummy header 208 can be used to indicate the number (eg M) and size (ie, length) of MAC subframes 216 (1) to 216 (M) contained in dummy MAC frame 206. is there. FEC field 209 can be used to correct bit errors in the receiver to increase the probability of proper reception of any of the MAC subframes 216 (1) to 216 (M). is there. Alternatively, multiple FEC fields can be attached at one end of the dummy MAC frame 206 or used inside each of the MAC frames 216 (1) to 216 (M). When different MAC subframes have different destinations, a modified acknowledgment method (eg, delayed ACK message exchange) can be used.
FIG. 3 shows other exemplary frame aggregation methods disclosed in the '947 and '943 applications. More specifically, the frame aggregation of FIG. 3 is performed within the PHY layer by concatenating multiple PHY frames without duplicating the preamble. The frame aggregation in Figure 3 makes it possible to transmit individual MAC frames with different data rates. In some embodiments, the included MAC frames are ordered according to the increasing data rate so that the STA with relatively poor channel conditions can properly receive the lower data rate. Is possible.
The LCC frames 301 (1) to 301 (M) of the LLC layer 302 are passed to the MAC layer 305. The MAC layer 305 attaches the MAC header 303 (n) and the MAC FCS 304 (n) to the LLC frame 301 (n) to form the MAC subframe 306 (n). The MAC subframes 306 (1) to 306 (M) are then passed to the PHY layer 307. The PHY layer 307 attaches a PCLP header 309 (n) to each corresponding MAC subframe 306 (n) to form the PHY subframe 310 (n). The PHY subframes 310 (1) to 310 (M) are concatenated and the preamble 308 is attached to the concatenated PHY subframe to form the PHY packet 311.
The aggregation method shown in Figures 2 and 3 can be implemented, for example, in a data network or entertainment network. A data network typically has an AP and several STAs associated with that AP, and each source device (eg, STA or AP) typically has a limited number of MAC frames transmitted to the same destination device. .. As a result, aggregate frames such as aggregate MAC frame 210 (FIG. 2) usually have MAC frames with different destinations, and the destination of each MAC frame is in the MAC header of the frame, such as MAC header 203 (FIG. 2). It is specified. In contrast, entertainment networks typically have paired source and destination devices (eg, DVD players and LCD screens), and relatively large amounts of data are transmitted from a particular source device to the other destination device. As a result, an aggregate frame such as an aggregate MAC frame 210 (FIG. 2) usually has multiple MAC frames, such as frame 216 (n), for the same destination. The aggregation method of FIGS. 2 and 3 improves the efficiency of the entertainment network compared to the efficiency achieved by the conventional method, but for example, the redundant information contained in the MAC header 203 (n) (FIG. 2). It is still possible to further improve the efficiency of entertainment networks by reducing the amount of.
4A-C show an aggregate frame format according to an embodiment of the present invention. More specifically, the aggregate frame format of FIGS. 4A-4C can be used in an aggregation method derived based on the methods shown in FIGS. 2 and 3, which are described in more detail below. It is described in. FIG. 4A shows the PHY packet 418 that can be transmitted in the same manner as the PHY packet 212 (FIG. 2) or PHY packet 311 (FIG. 3), and FIGS. 4B-4C show the MAC header (MHDR) unit of the PHY packet 418. 426 and compressed header data (CHDATA) unit 428 are shown respectively. The MHDR unit 426 carries the MAC header information that applies to CHDATA units 428 (1) to 428 (M), all intended for the same destination. Since each CHDATA unit 428 (n) no longer carries the information that resides in the MHDR unit 426, the MAC header overhead contained in the PHY packet 418 is compared to, for example, the MAC header overhead of the PHY packet 212 (Figure 2). And will be reduced.
Referring to FIG. 4A, the PHY packet 418 has a preamble 420, a PLCP header 422, MHDR units 426, and CHDATA units 428 (1) to 428 (M). The preamble 420 and the PLCP header 422 can be, for example, similar to the preamble 213 and the PLCP header 214 of FIG. 2, respectively. The preamble 420, PLCP header 422, MHDR unit 426, and CHDATA unit 428 are separated by the delimiter 424 as shown in the figure. Generally, the delimiter 424 is any combination of predetermined bits recognized by the system as a signal indicating the end of the preamble 420, PLCP header 422, MHDR unit 426, or non-terminal CHDATA unit 428 (n) (n M). Can have. The MHDR unit 426, CHDATA units 428 (1) to 428 (M), and the corresponding delimiter 424 form the aggregate MAC frame 430.
Referring to FIG. 4B, MHDR unit 426 has MAC header part 436 and FCS404. MAC header part 436 has the following fields: frame control, duration, addresses 1-3, header identity (HID), and QoS control. The number above the field in Figure 4B indicates the length of the field in bytes. Among these fields, the frame control, duration, address 1, address 2, address 3, and QoS control fields are similar to the corresponding fields in the canonical 802.11MAC header described in the standard IEEE 802.11 family. And the HID field is a new optional field. More specifically, the HID field can be used in the receiver to match the MHDR unit 426 with the CHDATA unit 428. FCS404 is a regular MAC similar to FCS204 (Fig. 2), for example. FCS. In a legitimate 802.11MAC frame, such as MAC frame 216 (n) in Figure 2, the FCS protects the MAC header, such as MAC header 203 (n) in Figure 2, along with the payload, such as LLC frame 201 (n) in Figure 2. To do. In contrast, in MHDR units 426 with no payload data, the FCS404 specifically protects the MAC header portion 436. In addition, the frame control field of MAC header portion 436 has MHDR unit 426 as itself, i.e. (i) the corresponding CHDATA unit MAC header information, and (ii) its own payload data. As a non-unit, it has a specific type and subtype value to identify.
Referring to FIG. 4C, CHDATA unit 428 has a compressed header portion 438, a payload data portion 401, and an FCS 404'. The compressed header part 438 has the following fields: frame control, sequence control, and HID. The numbers above the fields in Figure 4C indicate the length of the field in bytes. Among these fields, the frame control and sequence control fields are similar to the corresponding fields in the regular 802.11 MAC headers described in the standard IEEE 802.11 family. The HID field of the compressed header part 438 is similar to the HID field of the MAC header part 436 and is used to align the CHDATA unit 428 with the MHDR unit 426. FCS404'is a regular MAC similar to FCS204 (Fig. 2), for example. FCS. Since CHDATA unit 428 has payload data portion 401, FCS404'protects compressed header portion 438 along with payload data portion. The frame control field of the compressed header portion 438 has a specific type and subtype value that identifies the CHDATA unit 428 as itself, i.e. as the unit having the compressed header portion. The information in the compressed header portion must be complemented with MAC header information from the corresponding MHDR unit in order to properly process the payload data portion.
In the receiver, for example, the full canonical 802.11MAC header of payload data portion 401, similar to LLC frame 201 in FIG. 2, can be reconstructed as follows, for example: The values in the HID fields of the MAC header part 436 of MHDR unit 426 and the compressed header part 438 of CHDATA unit 428 are first used to align the two units with each other. The values of the remaining fields of MAC header part 436 and compressed header part 438 are then used to derive the corresponding field values of the full canonical MAC header. The fully reconstructed legitimate MAC header allows the receiver to continue processing payload data portion 401 in a conventional manner.
FIG. 5 shows a frame aggregation method using the aggregate frame format of FIG. 4 according to an embodiment of the present invention. Similar to the frame aggregation method of FIG. 2, the frame aggregation of the method of FIG. 5 is by processing regular MAC frames to form an aggregate MAC frame with MHDR units and one or more CHDATA units. , Implemented below MAC layer 505. The aggregate MAC frame is then processed by the PHY layer 511 to form the corresponding PHY packet. However, one difference in the frame aggregation method between Figures 2 and 5 is that in the former, different MAC subframes of aggregate MAC frames can be sent to different destinations, while in the latter, all CHDATA units are MHDR. It is intended to be the same destination specified in the unit.
LLC frames 501 (1) to 501 (M) (M is a positive integer) of LLC layer 502 are passed to MAC layer 505. Each LLC frame 501 (n) (1 n M) has a MAC header 503 (n) and a MAC. By attaching FCS504 (n), it is formed in MAC subframe 516 (n), and each of MAC headers 503 (n) specifies the same destination address. MAC subframes 516 (1) to 516 (M) are then processed in intermediate header compression and aggregation layer 507 to generate aggregate MAC frame 530. The aggregate MAC frame 530 is similar to the aggregate MAC frame 430 (FIG. 4A) and has MHDR units 526 and CHDATA units 528 (1) to 528 (M). The MHDR unit 526 is the same as the MHDR unit 426 in FIG. 4, and each CHDATA unit 528 (n) is the same as the CHDATA unit 428 in FIG. Therefore, the MAC header portion of the MHDR unit 526 has the MAC header information applied to each CHDATA unit 528 (n). The compressed header portion of CHDATA unit 528 (n) has MAC header information specific to MAC subframe 516 (n), and when this information is processed with the MAC header information of MHDR unit 526, the receiver, Allows the MAC header 503 (n) to be rebuilt. The payload data portion of CHDATA unit 528 (n) has user data of LLC frame 501 (n). The PHY layer 511 forms a PHY packet 518 from the aggregate MAC frame 530 by attaching the preamble 520 and the PLCP header 522, and the PHY packet 518, the preamble 520, and the PLCP header 522 are the PHY packet 418 of FIG. Similar to the preamble 420 and PLCP header 422, respectively.
In one embodiment, the transmission of the STA or AP of MHDR units 526 to aggregate MAC frame 530 to increase robustness in the event of loss of one or more copies of MHDR units due to transmission errors. It is possible to include multiple copies. An additional copy of MHDR unit 526 can be placed anywhere in the sequence of CHDATA unit 528 (n) subject to some ordering constraint for units with different HID values. This constraint is outlined below in more detail. STA or AP transmissions can perform MAC header compression per destination and per traffic class (TC) separately. Retransmission of CHDATA units 528 lost due to a transmission error can be performed as regular uncompressed MAC frames or again as CHDATA units.
The receiving STA or AP determines if MAC header compression was used based on the type and subtype values of the received MHDR and CHDATA unit frame control fields. The receiver uses the appropriate fields from the compressed header portion of MHDR unit 526 and CHDATA unit 528 (n) to recreate the MAC subframe 516 (n). The MHDR unit 526 does not need to be acknowledged by the receiving STA or AP. The acknowledgment policy of CHDATA unit 528 is established in the corresponding QoS field of MHDR unit 526. The existing 802.11 block ACK scheme can be called when an acknowledgment of CHDATA unit 528 is required. The retransmitted CHDATA unit 528 is processed based on the value of the sequence control field of the compressed header portion, which value indicates the appropriate position of the CHDATA unit in the previously received sequence of the CHDATA unit. If no corresponding MHDR unit is found in the aggregate frame based on the value of the HID field, the CHDATA unit is discarded.
It is preferred that the CHDATA unit 528 with a particular HID value is preceded by at least one MHDR unit 526 with the same HID value. The only MHDR unit 526 of the aggregate MAC frame 530 per HID value is properly received to allow the receiver to reconstruct the sequence of MAC subframe 516 (n) with that HID value. It is necessary to For ease of implementation, it may be preferable that MHDR units with different HID values do not occur between CHDATA unit 528 and its matching MHDR unit 526. Within a single aggregate MAC frame 530, MHDR units that do not carry the same MAC header information are assigned to different HID values.
Compared with the aggregation method of FIG. 2, the aggregation method of FIG. 5 can reduce the total overhead by about 15%, and most of the reduction comes from the reduction of the overhead related to the MAC header. For example, the simulation shows a MAC subframe 516 with a size of 188 bytes and about 10<sup>-6</sup>And 10<sup>-3</sup>For Gaussian communication channels with a bit error rate (BER) between and, the overhead reduction was shown to be between about 4 and 15%.
FIG. 6 shows a frame aggregation method using the aggregate frame format of FIG. 4 according to another embodiment of the present invention. The frame aggregation of the method of FIG. 6 is similar to PHY packet 418 (FIG. 4A), each of which is similar to PHY packet 418 (FIG. 4A), without duplicating the preamble, to form PHY packets 632 transmitted over the communication medium. Is implemented within the aggregate and PHY layer 607 by first forming and then concatenating those subpackets.
In one embodiment, the processing in LLC layer 602 and MAC layer 605 is similar to the processing in LLC layer 502 and MAC layer 505 (FIG. 5), respectively. More specifically, LLC frames 601 (1) to 601 (M) are passed from LLC layer 602 to MAC layer 605, and each LLC frame 601 (n) has a MAC header 603 (n) and a MAC. By attaching FCS604 (n), it is formed in MAC subframe 616 (n). MAC header 603 (n) corresponds to the same destination. MAC subframes 616 (1) to 616 (M) are passed to aggregation and PHY layer 607, where they are first sorted and grouped. MAC subframes 616 within the same group have the same destination. Each group of MAC subframes is then processed to form an aggregate MAC frame 630, similar to, for example, the aggregate MAC frame 530 (FIG. 5). The aggregation and PHY layer 607 then (A) inserts the PLCP header 622 (i) into each aggregate MAC frame 630 (i) (1 i K) to form the corresponding PHY subpacket 618'(i). ), Concatenate the resulting PHY subpacket 618'of (B) K, and add a preamble 620 to form (C) PHY packet 632. The maximum length (duration) of the PHY packet 632 can be limited by the maximum available 802.11 burst size of 3ms.
In the receiver, the MAC header 603 (n) of LLC frame 601 (n) can be reconstructed, for example, as follows. The values in the MHDR and CHDATA HID fields of the received aggregate MAC frame 630 (i) corresponding to LLC frame 601 (n) are first used to align the MHDR and CHDATA units with each other. The MAC header portion in MHDR units and the compressed header portion in CHDATA units are then used to reconstruct the MAC header 603 (n). Finally, using the reconstructed MAC header, the receiver processes the CHDATA-based payload in a customary manner to recover user data.
Although the present invention has been described with reference to exemplary embodiments, this description is not intended to be construed in a limited sense. The described embodiments, as well as various modifications of the other embodiments of the invention, which are apparent to those skilled in the art to which the invention belongs, are said to be within the principles and scope of the invention as set forth in the claims. Be considered.
Method Claimed steps, if any, are listed in a particular sequence with the corresponding naming, but the claim enumeration does not specifically suggest a particular sequence that performs some or all of those steps. As long as those steps are not necessarily intended to be limited to being performed in a particular sequence.
The present invention can be implemented as a circuit-based process, including possible implementation on a single integrated circuit. As will be apparent to those skilled in the art, various functions of circuit elements can also be implemented as a processing process of a software program. Such software can be used, for example, in digital signal processors, microcontrollers, or general purpose computers.
The present invention can be realized in the form of methods and devices that carry out those methods. The present invention can also be implemented in the form of program code implemented on tangible media such as floppy disks, CD-ROMs, hard drives, or any other machine-readable storage medium. When the program code is loaded into a machine such as a computer and executed by the machine, the machine becomes a device that implements the present invention. The present invention can also be realized in the form of program code, eg, stored in a storage medium, loaded on a machine and / or executed by a machine, or optical on an electrical wire or cable. It is transmitted over a transmission medium or carrier, such as through fiber or via electromagnetic radiation. When the program code is loaded into a machine such as a computer and executed by the machine, the machine becomes a device that implements the present invention. When implemented on a general purpose processor, the program code segment, in combination with the processor, provides a unique device that behaves like a particular logic circuit.
<figref num="1">FIG. 5 illustrates a prior art framing sequence of user data according to the 802.11 Wireless Local Area Network (WLAN) standard.</figref><figref num="2">It is a figure which shows one exemplary frame aggregation method.</figref><figref num="3">It is a figure which shows the other exemplary frame aggregation method.</figref><figref num="4">A to C are diagrams showing an aggregate frame format according to an embodiment of the present invention.</figref><figref num="5">It is a figure which shows the frame aggregation method using the aggregate frame format of FIG. 4 by one Embodiment of this invention.</figref><figref num="6">FIG. 5 shows a frame aggregation method using the aggregate frame format of FIG. 4 according to another embodiment of the present invention.</figref>
6 sheets
Sheet 1 Sheet 2 Sheet 3 Sheet 4 Sheet 5 Sheet 6
Every citation, both waysCites: the store holds 2 of 3
| Document | Relation | Office |
|---|---|---|
| JP2003324445A | Cites | Japan |
| US20030169769号明細書A1 | Cites | United States of America |
| Jean Lorchat et al,Energy Saving in IEEE802.11 Communications using Frame Aggregation,GLOBECOM’03.2003 - IEEE GLOBAL TELECOMMUNICATIONS CONFERENCE,2003年12月,pages 1296-1300 | Non-patent | – |
12 members in 6 offices
Priority claims10
| Document | Office | Kind | Date |
|---|---|---|---|
| 56931304 | United States of America | P | |
| 56931304 | United States of America | P | |
| 60569313 | United States of America | – | |
| 11019581 | United States of America | – | |
| 1958104 | United States of America | A | |
| 1958104 | United States of America | A | |
| 2004019581 | – | – | – |
| 2004569313 | – | – | – |
| US20040019581 | – | – | – |
| US20040569313P | – | – | – |
Members12
| Document | Office | Kind | |
|---|---|---|---|
| EP1594284A2 | European Patent Office (EPO) | A2 | |
| US2005249222A1 | United States of America | A1 | |
| JP2005323372A | Japan | A | |
| CN1700677A | China | A | |
| EP1594284A3 | European Patent Office (EPO) | A3 | |
| KR20060071831A | Republic of Korea | A | |
| EP1594284B1 | European Patent Office (EPO) | B1 | |
| DE602005008810D1 | Germany | D1 | |
| US7633970B2 | United States of America | B2 | |
| CN100576820C | China | C | |
| KR101125516B1 | Republic of Korea | B1 | |
| JP5047472B2This record | Japan | B2 |
32 legal events, as the office reported them to INPADOC
Over the term
Point at a mark for the eventEvents
| Event | Code | |
|---|---|---|
| Cancellation because of no payment of annual feesLAPS | LAPS | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Written notification of registration of transferJAPANESE INTERMEDIATE CODE: R350R350 | R350 | |
| Request for change of ownership or part of ownershipJAPANESE INTERMEDIATE CODE: R313111S111 | S111 | |
| Written notification for declining of transfer of rightsJAPANESE INTERMEDIATE CODE: R360R360 | R360 | |
| Transfer withdrawnWithdrawnJAPANESE INTERMEDIATE CODE: R371R371 | R371 | |
| Written notification for declining of transfer of rightsJAPANESE INTERMEDIATE CODE: R360R360 | R360 | |
| Request for change of ownership or part of ownershipJAPANESE INTERMEDIATE CODE: R313111S111 | S111 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Written notification of registration of transferJAPANESE INTERMEDIATE CODE: R350R350 | R350 | |
| Request for change of ownership or part of ownershipJAPANESE INTERMEDIATE CODE: R313113S111 | S111 | |
| Transfer withdrawnWithdrawnJAPANESE INTERMEDIATE CODE: R371R371 | R371 | |
| Request for change of ownership or part of ownershipJAPANESE INTERMEDIATE CODE: R313113S111 | S111 | |
| Transfer withdrawnWithdrawnJAPANESE INTERMEDIATE CODE: R371R371 | R371 | |
| Written notification of registration of transferJAPANESE INTERMEDIATE CODE: R350R350 | R350 | |
| Request for change of ownership or part of ownershipJAPANESE INTERMEDIATE CODE: R313113S111 | S111 | |
| Written request for registration of change of nameJAPANESE INTERMEDIATE CODE: R313533S533 | S533 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Renewal fee payment (event date is renewal date of database)FPAY | FPAY | |
| Certificate of patent or registration of utility modelJAPANESE INTERMEDIATE CODE: R150R150 | R150 | |
| Certificate of patent or registration of utility modelJAPANESE INTERMEDIATE CODE: R150R150 | R150 | |
| First payment of annual fees (during grant procedure)JAPANESE INTERMEDIATE CODE: A61A61 | A61 | |
| Written decision to grant a patent or to grant a registration (utility model)JAPANESE INTERMEDIATE CODE: A01A01 | A01 | |
| Decision of refusalJAPANESE INTERMEDIATE CODE: A02A02 | A02 | |
| Request for written amendment filedJAPANESE INTERMEDIATE CODE: A523A521 | A521 | |
| Notification of reasons for refusalJAPANESE INTERMEDIATE CODE: A131A131 | A131 | |
| Written request for application examinationJAPANESE INTERMEDIATE CODE: A621A621 | A621 |
Numbers
- Publication
- 5047472
- Publication, DOCDB
- 5047472
- Publication, EPODOC
- JP5047472B
- Application
- 134698
- Application, DOCDB
- 2005134698
- Application, EPODOC
- JP20050134698
Titles2
- Japanese
- フレーム集約と共に使用されるMACヘッダ圧縮
- English
- MAC header compression used with frame aggregation
Classification
- CPC, 3
- H04W28/06
- H04L69/04
- H04L12/28
- IPC, 3
- H04L12 56
- H04L29 06
- H04W28 06
