EP1719330A1

EP1719330A1 - Method and apparatus for wireless packet handling using medium access control action tables

Info

Publication number: EP1719330A1
Application number: EP05703014A
Authority: EP
Inventors: Parag Garg; Guido Frederiks; Atul Garg; Satish Damodaran
Original assignee: Koninklijke Philips Electronics NV
Current assignee: NXP BV
Priority date: 2004-02-19
Filing date: 2005-02-19
Publication date: 2006-11-08
Also published as: WO2005081498A1; KR20060127143A; JP2007527167A; CN1922846A

Abstract

The present invention provides a method and a wireless communication device that reduce delay associated with packet transmission. The medium access contol (MAC) functionalities are splitted in a HW (hardware) and a SW (software) part. Selected MAC functions are performed directly in a hardware MAC layer rather than being forwarded to a software MAC layer for processing. There is flexibility in carrying out a function either in the HWMAC or SWMAC based on what actions have been enabled for HWMAC. This can accommodate design changes in the solution and ever changing standard requirements. The allocation of a portion of the MAC functionality to the HWMAC allows reducing the delay when carrying out, in particular, real-time functions.

Description

METHODS AND APPARATUSES FOR WIRELESS PACKET HANDLING USING MEDIUM ACCESS CONTROL ACTION TABLES The present invention relates generally to wireless communication systems and, more particularly, to systems and methods for handling data packets to address time sensitivity and quality of service (QoS). Technologies associated with the communication of information have evolved rapidly over the last several decades. For example, over the last two decades wireless communication technologies have transitioned from providing products that were originally viewed as novelty items to providing products which are the fundamental means for mobile communications. Perhaps the most influential of these wireless technologies were cellular telephone systems and products. Cellular technologies emerged to provide a mobile extension to existing wireline communication systems, providing users with ubiquitous coverage using traditional circuit-switched radio paths. More recently, however, wireless communication technologies have begun to replace wireline connections in almost every area of communications. For example, wireless local area networks (WLANs) are rapidly becoming a popular alternative to the conventional wired networks in both homes and offices. Circa 1990, the IEEE 802 standards committee formed the 802.11 Wireless Local Area Networks Standards Working Group to develop a global standard for radio equipment and networks operating in the 2.4 GHz unlicensed frequency band for data rates of 1 and 2 Mbps. After its introduction, the various versions of the 802.11 standard rapidly formed the basis for standardization of WLAN networks and devices in the United States. Similar efforts in Europe have evolved around the HIPERLAN standard. Consumers will, naturally, compare services available using wireless technologies with services available using wireline service. Wireline services using, e.g., Ethernet or Asynchronous Transfer Mode (ATM) protocols provide, among other things, the capability to deliver audio and video data across networks. These services have different requirements. Audio data, for example, does not require the packet-error reliability required of data services, but cannot tolerate excessive delay. Video data can in general suffer more delay than audio, but is relatively intolerant to delay jitter. These delay and packet-error rate considerations may be best supported by a connection-oriented service, wherein the parameters are negotiated and established at the commencement of each connection. In addition to different types of data, many of today's wireline systems support services which provide differentiated quality of service (QoS) levels. In general, the term QoS refers to set of qualitative and quantitative traffic characteristics (e.g. throughput, service interval, packet size, delay, jitter, priority, type, etc.), which describes a traffic flow in support of a specific application. In wireline systems, QoS issues can be neglected since data rate is very high and the physical layer's error rate is very low. However wireless systems incur very high per-packet overhead with limited bandwidth, so the same does not apply to wireless systems, e.g., 802.11 WLANs. For example, a significant percentage of the available data rate in wireless systems is consumed by packet fragmentation, interframe spacing and MAC- level acknowledgment. In addition heavy traffic load increases collisions and backoffs, so frame delivery time increases further. Frequent retransmissions also cause unpredictable delays on the order of tens to hundreds of milliseconds and transmission of pending frames could be blocked. The quality of most multimedia services involving voice and video transmission deteriorate dramatically if delay increases above certain level. This is a major stumbling block associated with the provision of these types of services in wireless communication systems. Accordingly, it would be desirable to develop wireless communication systems and methods which reduce delay and provide mechanisms which address QoS concerns in order to, for example, provide audio, video and other delay sensitive services Systems and methods according to the present invention address this need and others by providing wireless communication systems that allocate a portion of the MAC functionality to a hardware portion of the MAC layer and a portion of the MAC functionality to a software portion of the MAC layer. For example, responses to received packets having greater QoS-related time sensitivity can be identified and handled entirely within the hardware portion of the MAC layer to reduce delay. By contrast, less time sensitive MAC processing steps can be performed in the software portion of the MAC layer. According to one exemplary embodiment of the present invention, a method for handling data packets in a medium access control (MAC) layer can include receiving a data packet, forwarding the data packet to a hardware portion of the MAC layer in a receive chain, determining, in the hardware portion of the MAC layer in the receive chain, a packet type associated with the received data packet, selectively triggering the hardware portion of the MAC layer in a transmit chain based on the packet type; and otherwise, sending an indication to the software portion of said MAC layer of the receive chain for generation of the response. According to another exemplary embodiment of the present invention, a wireless communication device can include a receiver for receiving a data packet, a medium access controller (MAC) having a hardware portion and a software portion, wherein a packet type associated with the received data packet is determined in the hardware portion of the MAC and a receive action table, in the hardware portion of the MAC, having hardware processing functions stored therein for selected packet types, wherein if the packet type of the received data packet is one of the selected packet types, then an associated hardware processing function is performed and otherwise wherein an indication is given to the software portion of said MAC. The accompanying drawings illustrate exemplary embodiments of the present invention, wherein: FIG. 1 depicts a WLAN system in which the present invention can be implemented; FIG. 2 depicts a frame exchange sequence; FIG. 3 shows an interaction between hardware (HW) medium access layer and a software (SW) medium access layer according to an exemplary embodiment of the present invention; FIG. 4 is a flow diagram illustrating an exemplary method for handling data packets in a medium access layer according to an exemplary embodiment of the present invention; FIG. 5 is a block diagram of an exemplary WLAN SDIO card, which could be inserted into the SDIO slot of the PDA, incorporating an exemplary embodiment of the present invention; and FIG.6 is an exemplary RX Action table according to an exemplary embodiment of the present invention. The following detailed description of the invention refers to the accompanying drawings. The same reference numbers in different drawings identify the same or similar elements. Also, the following detailed description does not limit the invention. Instead, the scope of the invention is defined by the appended claims. In order to provide some context for this discussion, an exemplary WLAN system will first be described with respect to Figure 1. Those skilled in the art will appreciate, however, that the present invention is not restricted to implementation in WLAN systems. Therein, a wireline network 10 (e.g., an Ethernet network) has a file server 12 and workstation 14 connected thereto. Those skilled in the art will appreciate that typical wireline networks will serve numerous fixed workstations 14, however only one is depicted in Figure 1 for simplicity. The wireline network 10 is also connected to a WLAN 16 via router 18. The router 18 interconnects the access points (AP) of the WLAN 16 with the wireline network, through which the access points can, for example, communicate with the file server 12. In the exemplary WLAN system of Figure 1, three cells 20, 22 and 23 (also sometimes referred to as a Basic Service Set (BSS) or Basic Service Area (BSA) are shown each with a respective AP, although those skilled in the art will once again appreciate that more or fewer cells may be provided in WLAN 16. Within each cell, a respective AP serves a number of wireless stations (W) via a wireless connection. According to exemplary embodiments of the present invention, the transmission of signals between APs and respective wireless stations W is performed using wireless communication signals in accordance with one of the 802.11 standards. However, those skilled in the art will appreciate that the present invention is not so limited and may be implemented for communication of signals in accordance with other formats and standards. As mentioned earlier, the introduction of QoS capability into the 802.11 standards will result in additional time sensitive functionality during a frame exchange sequence to be carried out at the MAC layer. To illustrate the time sensitive nature of QoS related frame exchange signaling, consider the exemplary frame exchange sequence shown in Figure 2. Therein, a frame exchange sequence between an AP and a first wireless station W occurs during a first transmission opportunity (TXOP1). The AP transmits QoS data blocks spaced apart from acknowledgements from the wireless station W by short interframe spaces (SIFS). A QoS Null message is transmitted by the wireless station W at the last frame of TXOP 1. In order to grant another transmission opportunity to another wireless station W, the AP uses the message QoS CF-Poll. Then, during TXOP 2, the other wireless station W transmits its QoS data frames to the AP which are likewise acknowledged by the AP. Although this example illustrates all data frame transmissions being acknowledged by the recipient station, 802.1 le permits MAC level acknowledgements to be optional, i.e., a station need not acknowledge a correctly received frame based on the ACK policy field in the incoming frame. This further tightens the time constraints associated with data packet transmission and reception in such systems since this means that a next package needs to be ready for transmission after the SIFS time period has expired. Generally speaking QoS- related changes to wireless protocols have introduced time sensitivity in the MAC layer processing (1) during data packet reception, when fields have to be extracted, further software processing has to be done on the data packet or a time sensitive response has to be sent back and (2) during data packet transmission, when some fields have to be inserted in the data packet or some follow-up action has to be taken. According to exemplary embodiments of the present invention, the time sensitivity associated with these, and other, QoS-related wireless protocols can be achieved by partitioning MAC level functionality between hardware and software. For example, according to exemplary embodiments of the present invention, this partitioning can be achieved by a register interface in the hardware. Due to the varied types of MAC packets currently defined for transmission, some of which are shown in Figure 2, and the expectation that more packet types will be added in the future in the various standards, MAC hardware according to the present invention is designed to deal with the time sensitive nature requirement of each type of packet and cater to it as specified by the software. Note that as used herein the term "packet type" is intended to include packet types, packet sub-types and the combination of packet-types/sub-types. In particular, exemplary embodiments of the present invention provide two tables in the MAC hardware, which tables are referred to herein as the Rx Action table and Tx Action table. An exemplary high-level implementation of these two tables is shown in Figure 3. Therein, an exemplary interaction between the physical layer, hardware (HW)-MAC layer and the software (SW)-MAC layer is illustrated. Both a transmit chain 30 and a receive chain 32 are shown which can be integrated into a single MAC controller. Note that an Rx Action table 34 is included within the HW-MAC layer associated with the receive chain 32 and that a Tx Action table 36 is included within the HW-MAC layer associated with the transmit chain 30. An exemplary processing flow for this MAC architecture will now be described with respect to the flow diagram of Figure 4. Therein a data packet is first received by a receive module 38 of the physical layer at step 50. The data packet is then forwarded to the HW-MAC layer in the receive chain 32 at step 52. The HW-MAC layer verifies the data packet and determines what type of data packet has been received, e.g., from header information, at step 54. The Rx Action table 34 determines what action to take in response to the received data packet based on its packet type at step 56. If the packet type indicates that a faster response is desired, then a trigger can be sent directly from the HW-MAC layer in the receive chain 32 to the HW-MAC layer in the transmit chain 30. Since this path circumvents the software portions of the MAC layer, the resulting response will be faster and less delay will be generated. Examples of data packet types and corresponding actions are provided below. If no fast -track response is indicated by the Rx Action table 32, then an indication is sent on to the software (SW)- MAC layer in the receive chain 32, wherein it is processed and a software (SW)-MAC generated response is forwarded to the transmit chain 30 at step 58. Having described an exemplary embodiment for handling data packets in a MAC layer according to the present invention, some more detailed examples of Rx Action table 34 and Tx Action table 36 will now be provided. The HW-MAC layer in the receive chain 32 includes an address filter which determines the destination address of the incoming packet which, along with the ACK policy (for QOS frames), is a mechanism for determining the set of actions can be taken for this particular packet. The incoming packet can be categorized as, for example, one of the following destination types: (1) a packet having a unicast address for this particular wireless station, (2) a packet having a unicast address for other wireless stations, (3) a packet having a multicast group address of which this particular wireless station is a member, (4) a packet having a multicast group address of which this particular wireless station is not a member and (5) a packet having a broadcast address. Based on their different destination address types, received frames are treated differently. For example, if an incoming frame is intended for this particular wireless station, and if it is meant only for this particular station (i.e., if it has a unicast address), then the receiving wireless station W shall return an ACK frame to the transmitting wireless station W. Alternatively, in case the destination address of the incoming frame is a member of a multicast group for which the frame is intended, then the receiving wireless station W should not respond with an ACK frame, but should instead be indicated to the SW-MAC layer. The same mechanism should be provided to handle incoming frames having a broadcast destination address. On the other hand, if the destination address of an incoming frame is a multicast address of which the wireless station is not a member, then the frame should be filtered out at the HW-MAC layer and should not be indicated to the SW-MAC layer. In addition to considering an incoming frame's destination address type, RX Action tables according to exemplary embodiments of the present invention also can be indexed according to whether an ACK policy field is present in, for example, an incoming QOS frame. Based on this, or other, categorizations of an incoming data packet, the RX Action table 34 can be indexed to output an action associated with the determined packet type. Such actions can be represented as bit fields in the Rx Action table entry word and include, for example, the following actions. 1. Trigger the transmission of a control packet (data packet in the case of an incoming CF-Poll frame) which has been preprogrammed. This action can be performed when, for example, an incoming packet has is one of the following types: CF-Poll +Data, PS-Poll, Data- ACK and RTS-CTS sequence. 2. Trigger an interrupt after a particular number of data packet bytes have been received. This action can, for example, be triggered for cases where a new frame type is introduced into a standard. The SW-MAC layer will need to act on to be able to operate on the new frame type, most likely in a time critical fashion. Thus, when this new frame type is received the SW-MAC can enable this interrupt in the RX Action table after, for example, a configurable number of bytes were received. 3. Trigger the transmission of a packet following the DCF medium access rules. The frames may be queued in the HW-MAC as they are received from the host. The HW- MAC layer takes care of sending the frames after following the DCF protocol. This will reduce the workload of the SW-MAC and reduce the number of processor cycles associated with MAC level processing. 4. Write the incoming packet in memory and generate an interrupt for software to process it. This action can be triggered based on destination address filter results which indicate that the HW-MAC layer will either write the frame to a memory device where the SW-MAC layer can access it. 5. Perform a CRC check on the incoming packet. In some test cases it may be desirable to forego performing a CRC check on incoming packets. Providing the trigger for CRC checking/not checking in the RX Action table provides an efficient mechanism for handling such cases. 6. Update the TXOP holder address. This action can be triggered when, for example, an incoming frame is a CF-Poll frame. 7. Update NAV with the duration id of the incoming packet. This action will be triggered for many types of incoming packets in the RX Action table. However, the virtual carrier sense algorithm associated with the exemplary 802.1 le standard does not need to operate on all packet types, e.g., the PS-Poll frame does not have a Duration Id field defined. For this reason, the HW-MAC layer should not update the NAN with the 3^rd and 4^th byte of the PS-Poll frame, which is generally where the Duration Id is located. The NAN should be updated with a remaining CF duration value, if the field is received in the beacon in the middle of a CF period. 8. For beacon packets, a number of different actions can be indicated in the RX Action table. For example, the beacon can be filtered out beacon based on the BSSID, SSID and/or Capability info, the TSF can be updated per the BSS/IBSS update criteria in the beacon or the ΝAV can be updated if the beacon starts a CFP. Similarly, the TX Action table 36 can be organized by packet type/action. Based on the packet type/subtype, the TX Action table 36 can be indexed to output an action associated with the determined packet type. Such actions can be represented as bit fields in the Tx Action table entry word and can include, for example, those set forth below. 1. Insert CRC for the packet to be transmitted. This action can be performed, for example, for test purposes when it is desirable to validate the receiving wireless station's CRC module by receiving a frame for which the CRC has been intentionally garbled. Using this option the CRC generation module of the HW-MAC for the transmitting wireless station can be disabled. 2. Insert source MAC address/BSSID. Enabling this action in the TX Action table may lead to less overhead in the SW-MAC for outgoing frames. This action can be used both for the auto-response frames triggered by the HW-MAC in the receive chain, as for occasions where the transmitter's and receiver's address needs to be swapped. 3. Fragment the packet based on the fragmentation parameters. The fragmentation related parameters can be provided to the HW-MAC which can then take care of the fragmentation of the packet without any assistance from the SW-MAC layer. 4. Expect specified response in SIFS time after transmitting packet. This may be indicated by the SW-MAC to the HW-MAC when the HWMAC Rx needs to prepare the receive state machine for an incoming frame right after transmitting a frame. 5. Generate interrupt(s) upon transmission of packet. This interrupt action may be enabled in the TX Action table by the SW-MAC in order to know whether a previously programmed packet has been attempted by the HW-MAC and to provide a feedback/result of the attempt. 6. Insert timestamp and/or DTIM count in beacon. This action can be triggered whenever the TX Action table receives a packet for transmission from the SW-MAC layer. Those skilled in the art will appreciate that the foregoing example, which refers to the 802.1 le standard, is purely illustrative and that the present invention can be applied to communication systems which operate in accordance with other standards. Readers who are interested in operations of 802.11 and/or 802.1 le are referred to the IEEE Standard for Information Technology, Part 11 : Wireless LAN/MAC and Physical Layer (PHY) Specifications, ANSI/IEEE 802.11 (1999) and the Draft Supplement to the IEEE Standard for Information Technology, Part 11 : Wireless LAN/MAC and Physical Layer (PHY): MAC enhancements for Quality of Service (QoS), ANSI/IEEE 802.1 le/D4.0, November 1999, both of which are expressly incorporated here by reference. The allocation of MAC functions between hardware and software according to the present invention can be provided in any wireless communication system or device. To further illustrate the present invention, an example is shown in Figure 5 with respect to an embedded wireless LAN chip in a PDA device. Therein, an exemplary MAC controller 60 (ASIC chip) is illustrated which includes a general purpose microprocessor 62, at least one memory unit 64, a HW-MAC unit 66 and an SDIO interface unit 68. Those skilled in the art will appreciate that other functional blocks, e.g., a DMA controller, other I/O ports, a power converter, additional memory devices, etc., can be included however only these four functional blocks are depicted to simplify the discussion. The HW-MAC ASIC unit 66 communicates with a transmitter and receiver (not shown) and includes the RX Action table and TX Action table described above. According to exemplary embodiments of the present invention, those packet types received by the HW-MAC ASIC chip 66, and identified in the RX Action table as designated for expedited response and/or other hardware action, are handled within HW-MAC ASIC chip 66. For example, if HW-MAC ASIC chip 66 receives a CF-Poll packet, its RX Action table may specify that an automatic, prestored response be retrieved from memory 64 and sent to the transmitter for transmission without involving the general purpose microprocessor 62 in this part of the process. Notwithstanding an indication in the RX Action table to perform a certain HW-MAC action on an incoming packet, there may also be payload data to be processed by the general-purpose microprocessor 62 and, for example, output via SDIO interface 68 to the wireless PDA device. A more detailed example of an RX Action Table according to the present invention is provided as Figure 6. Therein, the rows specify the various packet types that can be received by the MAC. The columns represent the actions which the HW-MAC is capable of performing. This table can be translated into a 64-bit register in the HW-MAC where the HW-MAC indexes on, for example, the 02-07 bits of the incoming packet. The HW-MAC uses theses bits to determine what kind of address type is associated with the incoming packet and then takes the corresponding action as specified in the corresponding RX Action table bits. The 64 bit register may be designed in such a way that a group of bits (corresponding to an action required) are allocated to the 'Unicast Self address class, others to the 'Multicast self address class and like wise for the 'Multicast others', broadcast and 'Unicast others' address class of the incoming frame's receiver address. The functionality associated with the Special Action column in Figure 6 according to this exemplary, but purely illustrative, embodiment is described below in Table 1.

Table 1 The above-described exemplary embodiments are intended to be illustrative in all respects, rather than restrictive, of the present invention. Thus the present invention is capable of many variations in detailed implementation that can be derived from the description contained herein by a person skilled in the art. From the exemplary Rx Action table of Figure 6, it can be seen that the SW-MAC layer enables particular feature(s) in the HW-MAC on initialization. Accordingly, in order to suit varying architectures a particular option may be disabled or enabled in the HW-MAC layer. If disabled, then that functionality will either be carried out in the SW-MAC or eliminated. Thus, the present invention's provision of Rx/Tx Action tables provides flexibility in the e.g., ASICs, with respect to frequent changes in communication standards. All such variations and modifications are considered to be within the scope and spirit of the present invention as defined by the following claims. No element, act, or instruction used in the description of the present application should be construed as critical or essential to the invention unless explicitly described as such. Also, as used herein, the article "a" is intended to include one or more items.

Claims

CLAIMS What is claimed is: 1. A method for handling data packets in a medium access control (MAC) layer comprising the steps of: receiving a data packet; forwarding said data packet to a hardware portion of said MAC layer in a receive chain; determining, in said hardware portion of said MAC layer in said receive chain, a packet type associated with said received data packet; selectively sending an indication directly to a hardware portion of said MAC layer in a transmit chain based on said packet type; and otherwise, sending an indication to a software portion of said MAC layer of said receive chain for generation of said response.

2. The method of claim 1, wherein said step of selectively sending said response based on said type-subtype of said data packet further comprises the step of: sending said response to said hardware portion of said MAC layer in said transmit chain if said packet type is one of: CF-Poll, PS-Poll, Data/Management- ACK and RTS-CTS.

3. The method of claim 1 , wherein said step of determining said packet type further comprising the step of: determining a destination address of said data packet using an address filter.

4. The method of claim 1 , wherein said step of selectively sending a response directly to said hardware portion of said MAC layer further comprises the step of: providing a receive action table in said hardware portion of said MAC layer in said receive chain, wherein said receive action table is indexed using said packet type to output said response.

5. The method of claim 1 , wherein said hardware portion of said MAC layer is implemented in an application specific integrated circuit (ASIC).

6. The method of claim 1, wherein said software portion of said MAC layer is implemented in a general purpose microprocessor.

7. The method of claim 1, further comprising the steps of: receiving another data packet, from said software portion of said MAC layer, for transmission; providing a transmit action table in said hardware portion of said MAC layer in said transmit chain, wherein said transmit action table is indexed using said packet type to output a function for said hardware portion of said MAC layer to perform on selected packet types and destination address type; and selectively performing said function based upon a packet type of said another data packet.

8. The method of claim 7, wherein said function further comprises the step of: inserting a cyclic redundancy check (CRC) for said another data packet.

9. The method of claim 1, further comprising the step of: sending, as said response directly to said hardware portion of said MAC, an interrupt after a predetermined number of bytes have been received.

10. A wireless communication device comprising: means for receiving a data packet; a medium access controller (MAC) having a hardware portion and a software portion, wherein a packet type associated with said received data packet is determined in said hardware portion of said MAC; and a receive action table, in said hardware portion of said MAC, having hardware processing functions stored therein for selected packet types; wherein if said packet type of said received data packet is one of said selected packet types, then an associated hardware processing function is performed and otherwise wherein a response indication is forwarded to said software portion of said MAC.

11. The device of claim 10, wherein if said packet type is one of: CF-Poll, PS- Poll, Data/Management- ACK and RTS-CTS, then sending a response directly via said hardware portion of said MAC.

12. The device of claim 10, further comprising: an address filter, in said hardware portion of said MAC, for determining a destination address of said data packet.

13. The device of claim 10, wherein said hardware portion of said MAC is implemented in an application specific integrated circuit (ASIC).

14. The device of claim 10, wherein said software portion of said MAC is implemented in a general purpose microprocessor.

15. The device of claim 10, further comprising the steps of: a transmit action table in said hardware portion of said MAC, wherein said transmit action table is indexed using said packet type to output a function for said hardware portion of said MAC layer to perform on selected packet type-subtype; and wherein said hardware portion of said MAC selectively performs said function based upon a packet type when another data packet is forwarded for transmission by said device.

16. The device of claim 15, wherein said function further comprises: inserting a cyclic redundancy check (CRC) for said another data packet.