Method and apparatus to control TX/RX AMSDU size based on the negotiated maximum transmission unit in the tunnel between a controller and an access point

A method includes selecting upstream and downstream aggregated MAC service data unit (AMSDU) sizes for communications between a client device, an access point, and an controller in a network system. The upstream and downstream AMSDU sizes may be separately selected based on the maximum transmission unit (MTU) size for communications in a secure tunnel between the controller and the access point to avoid fragmentation and reassembly of AMSDUs transmitted in a single MTU. The upstream and downstream AMSDU sizes may be selected to be less or equal to the MTU size.

TECHNICAL FIELD

The present disclosure relates to selecting aggregated MAC service data unit (AMSDU) sizes for communications between a client device, an access point, and a controller based on a maximum transmission unit (MTU) size for communications in a secure tunnel between the controller and the access point.

BACKGROUND

Over the last decade, there has been a substantial increase in the use and deployment of wireless client devices, from dual-mode smartphones to tablets capable of operating in accordance with a particular Institute of Electrical and Electronics Engineers (IEEE) standard. With “wireless” becoming the de-facto medium for connectivity among users, it has become increasingly important for network systems to intelligently manage connections.

In some systems, wireless client devices may connect with an access point over a wireless connection to transfer and receive data. In upstream communications, the wireless client devices aggregate packets into aggregated MAC service data units (AMSDUs) for transmission to the access point. Similarly, in downstream communications the wireless client devices deaggregate packets transmitted in AMSDUs from the access point.

In some systems, the access point may establish a tunnel with a controller to enable centralized security, thereby eliminating packet tampering in intermediate devices. In transmissions through the tunnel, AMSDUs may be fragmented such that they may be transmitted in maximum transmission units (MTUs). This fragmentation may lead to a reduction of performance for a datapath between the client device, the controller, and the access point as a result of significant processing and delay overhead.

DETAILED DESCRIPTION

Herein, certain terminology is used to describe features for embodiments of the disclosure. For example, the term “digital device” generally refers to any hardware device that includes processing circuitry running at least one process adapted to control the flow of traffic into the device. Examples of digital devices include a computer, a tablet, a laptop, a desktop, a netbook, a server, a web server, authentication server, an authentication-authorization-accounting (AAA) server, a Domain Name System (DNS) server, a Dynamic Host Configuration Protocol (DHCP) server, an Internet Protocol (IP) server, a Virtual Private Network (VPN) server, a network policy server, a mainframe, a television, a content receiver, a set-top box, a video gaming console, a television peripheral, a printer, a mobile handset, a smartphone, a personal digital assistant “PDA”, a wireless receiver and/or transmitter, an access point, a base station, a communication management device, a router, a switch, and/or a controller.

It is contemplated that a digital device may include hardware logic such as one or more of the following: (i) processing circuitry; (ii) one or more communication interfaces such as a radio (e.g., component that handles the wireless data transmission/reception) and/or a physical connector to support wired connectivity; and/or (iii) a non-transitory computer-readable storage medium (e.g., a programmable circuit; a semiconductor memory such as a volatile memory and/or random access memory “RAM,” or non-volatile memory such as read-only memory, power-backed RAM, flash memory, phase-change memory or the like; a hard disk drive; an optical disc drive; etc.) or any connector for receiving a portable memory device such as a Universal Serial Bus “USB” flash drive, portable hard disk drive, or the like.

Herein, the terms “logic” (or “logic unit”) are generally defined as hardware and/or software. For example, as hardware, logic may include a processor (e.g., a microcontroller, a microprocessor, a CPU core, a programmable gate array, an application specific integrated circuit, etc.), semiconductor memory, combinatorial logic, or the like. As software, logic may be one or more software modules, such as executable code in the form of an executable application, an application programming interface (API), a subroutine, a function, a procedure, an object method/implementation, an applet, a servlet, a routine, source code, object code, a shared library/dynamic load library, or one or more instructions. These software modules may be stored in any type of a suitable non-transitory storage medium, or transitory computer-readable transmission medium (e.g., electrical, optical, acoustical or other form of propagated signals such as carrier waves, infrared signals, or digital signals).

FIG. 1shows a block diagram example of a network system1in accordance with one or more embodiments. The network system1, as illustrated inFIG. 1, is a digital system that may include a plurality of digital devices such as one or more client devices2A and2B, an access point3, a controller4, and one or more remote devices5A and5B. In one or more embodiments, the network system1may include more or less devices than the devices illustrated inFIG. 1, which may be connected to other devices within the network system1via wired and/or wireless mediums. For example, although shown as two client devices2A and2B connected to the access point3, in other embodiments more than two client devices2may be connected to the access point3.

In one embodiment, as shown inFIG. 2, the client device2A may be a network device that comprises one or more of: a hardware processor21, data storage22, an input/output (I/O) interface23, and device configuration logic24. Other client devices2within system1may be configured similarly or differently than the client device2A shown inFIG. 2.

The data storage22of the client device2A may include a fast read-write memory for storing programs and data during client device2A's operations and a hierarchy of persistent memory, such as Read Only Memory (ROM), Erasable Programmable Read Only Memory (EPROM), and/or Flash memory for example, for storing instructions and data needed for the startup and/or operations of the client device2A. The data storage22may store data that is to be transmitted from the client device2A or data that is received by the client device2A. In an embodiment, the data storage22is a distributed set of data storage components.

In one embodiment, the I/O interface23corresponds to one or more components used for communicating with other devices (e.g., the access point3) via wired or wireless signals. The I/O interface23may include a wired network interface such as an IEEE 802.3 Ethernet interface and/or a wireless interface such as an IEEE 802.11 WiFi interface. The I/O interface23may communicate with the access point3over corresponding wireless channels6in the system1. The I/O interface23may include one or more antennas25for communicating with the access point3and other wireless devices in the network system1. For example, multiple antennas25may be used for forming transmission beams to the access point3through adjustment of gain and phase values for corresponding antenna25transmissions. The generated beams may avoid objects and create an unobstructed path to the access point3.

In one embodiment, the hardware processor21is coupled to the data storage22and the I/O interface23. The hardware processor21may be any processing device including, but not limited to a MIPS/ARM-class processor, a microprocessor, a digital signal processor, an application specific integrated circuit, a microcontroller, a state machine, or any type of programmable logic array.

In one embodiment, the device configuration logic24includes one or more functional units implemented using firmware, hardware, software, or a combination thereof for configuring parameters associated with the access point3and the client device2A. In one embodiment, the device configuration logic24may be configured to adjust the size of aggregated MAC service data units (AMSDUs) transmitted between the client device2A and the access point3based on the maximum transmission unit (MTU) size for communications in a secure tunnel between the controller4and the access point3as will be described in further detail below.

The access point3may be any device that can associate with the client devices2to transmit and receive data over the wireless channels6. For example, the access point3may facilitate the transfer of data (1) from the client devices2to the remote devices5and/or (2) to the client devices2from the remote devices5. In one embodiment, the access point3may correspond to a network device such as a wireless access point, a switch, a router, or any combination thereof. For example, the access point3may be a router or any device that may be configured as a hotspot (e.g., a cell phone, a tablet, a laptop, etc.). The access point3may be communicatively coupled to other networks, such as network7to send and receive data to the remote devices5. The data may include, for example, web data, video data and/or voice data. In one embodiment, the access point3is a digital device that includes a hardware processor, memory hierarchy, and input/output (I/O) interfaces including a wireless interface, such as an IEEE 802.11 wireless interface. In one embodiment, the configuration of the components within the access point3may be similar to those discussed above in relation to the client device2A.

In one embodiment, the controller4is coupled to the network7through a wireless or wired connection that facilitates the transfer of data between the access point3and the controller4. In one embodiment, the controller4and the access point3may establish a tunnel for enabling centralized security, thereby eliminating any packet tampering in intermediate devices. The tunnel may be implemented using any protocol suite for securing the transmission of packets through the use of authentication and encryption operations.

In one embodiment, the controller4may correspond to a network device such as a switch, a router, or any combination thereof. In one embodiment, the controller4is a digital device that includes a hardware processor, memory hierarchy, and input/output (I/O) interfaces including a wired interface, such as an IEEE 802.3 interface, and/or wireless interface, such as an IEEE 802.11 interface. In one embodiment, the configuration of the components within the controller4may be similar to those discussed above in relation to the client device2A.

In one embodiment, the access point3, the controller4, and the remote devices5are coupled to the network7. The network7may be any network capable of transferring data between the access point3, the controller4, and the remote devices5. For example, the network7may include one or more wired or wireless routers, switches, and other digital networking devices that operate using one or more protocols (e.g., IEEE 802.3 and IEEE 802.11).

The remote devices5may be any wireless or wired electronic devices capable of receiving and transmitting video or other data streams, such as personal computers, laptop computers, netbook computers, wireless music players, portable telephone communication devices, smart phones, tablets, and digital televisions. In one embodiment, the remote devices5are digital devices that include a hardware processor, memory hierarchy, and input/output (I/O) interfaces including a wired and/or wireless interface such as an IEEE 802.3 interface. In one embodiment, the configuration of the components within the remote devices5may be similar to those discussed above in relation to the client device2A.

FIG. 3Ashows upstream data flow from the client device2A to the remote device5A. In this embodiment, one or more data packets are generated on the client device2A. The data packets may correspond to any type of data, including web data, video data, and/or voice data. In one embodiment, the data packets are IEEE 802.3 compliant data packets generated by the hardware processor21and stored in the data storage22.

The client device2A may aggregate two or more data packets into an upstream aggregated MAC service data unit (AMSDU). The size of the upstream AMSDU may be negotiated by the client device2and the access point3. For example, the upstream AMSDU size may be set to one of 3895 bytes, 7991 bytes, and 11454 bytes. In one embodiment, the upstream AMSDU size is determined based on the maximum transmission unit (MTU) size between the access point3and the controller4. In one embodiment, the upstream AMSDU size may be set to be less than or equal to the MTU size for the secure tunnel between the access point3and the controller4. For example, when the MTU size between the access point3and the controller4is 9000 bytes, the upstream AMSDU size may be set to either 3895 bytes or 7991 bytes.

The client device2may thereafter perform authentication and encryption operations on the AMSDU frame using shared authentication and security information with the controller4. Authentication and encryption operations ensure that the AMSDU is not compromised while being transferred over the wireless channels6to the access point3. Any form of authentication and encryption may be used by the client device2.

Following the aggregation of packets into an AMSDU frame and possible encryption of the AMSDU, the client device2A may aggregate two or more AMSDUs into an aggregated MAC protocol data unit (AMPDU). The AMPDU may be transmitted over the wireless channels6to the access point3. The access point3deaggregates the AMPDU into the original AMSDUs and transmits the AMSDUs to the controller4. In one embodiment described above, the upstream AMSDU size is set to be less than or equal to the MTU size of the tunnel between the access point3and the controller4. In this embodiment, a single AMSDU may be transmitted through the tunnel without fragmentation of the AMSDU since the size of the AMSDU is less than or equal to the size of the MTU for the tunnel between the access point3and the controller4. By eliminating fragmentation of AMSDUs during transmission between the access point3and the controller4, performance of the upstream datapath is improved through the elimination of fragmentation processing delays. In one embodiment, the upstream AMSDU size is determined through negotiations between the client device2A and the access point3. The upstream AMSDU size may be periodically updated upon the detection of a changed MTU size.

Upon receipt, the controller4may decrypt the AMSDU using the authentication and security information shared with the client device2A. The controller4may thereafter deaggregate the AMSDU into two or more data packets. The data packets may thereafter be transmitted to the remote device5A through the external network7. The transmission may use any suitable protocol, including the Transmission Control Protocol/Internet Protocol standards.

FIG. 3Bshows downstream data flow from the remote device5A to the client device2A. In this embodiment, one or more data packets are generated on the remote device5A. The data packets may correspond to any type of data, including web pages, video data, and/or voice data. In one embodiment, the data packets are IEEE 802.3 compliant data packets generated by a hardware processor and/or stored within data storage within the remote device5A.

The remote device5A transmits the data packets to the controller4through the external network7. The transmission may use any suitable protocol, including the Transmission Control Protocol/Internet Protocol standards.

The controller4may aggregate two or more encrypted data packets into a downstream AMSDU. The size of the downstream AMSDUs may be negotiated by the client device2and the access point3in a similar fashion as described above in relation to the upstream AMSDUs. For example, the downstream AMSDU size may be set to one of 3895 bytes, 7991 bytes, and 11454 bytes. In one embodiment, the downstream AMSDU size is determined based on the MTU size between the access point3and the controller4. In one embodiment, the downstream AMSDU size may be set to be less than or equal to the MTU size for the secure tunnel between the access point3and the controller4. For example, when the MTU size between the access point3and the controller4is 9000 bytes, the downstream AMSDU size may be set to either 3895 bytes or 7991 bytes. Although both the upstream and downstream AMSDU sizes may be set based on the MTU size, in some embodiments the upstream and downstream AMSDU sizes are distinct and different. For example, when the MTU size between the access point3and the controller4is 9000 bytes, the upstream AMSDU size may be set to 3895 bytes and the downstream AMSDU size may be set to 7991 bytes.

In one embodiment, the controller4may perform authentication and encryption operations on each AMSDU using authentication and security information shared with the client device2A. Authentication and encryption operations ensure that the data packets are not compromised while being transferred over the wireless channels6to the client device2A. Any form of authentication and encryption may be used by the controller4.

Following the aggregation of data packets and possible encryption of the AMSDU, each downstream AMSDU may be transmitted to the access point3through the secure tunnel. Since, the size of the downstream AMSDU is less than or equal to the size of the MTU, fragmentation of the AMSDUs does not occur. By eliminating fragmentation of AMSDUs during transmission between the controller4and the access point3, performance of the downstream datapath is improved through the elimination of fragmentation processing delays.

Upon receipt, the access point3may aggregate two or more AMSDUs into an AMPDU and transmit the AMPDU over the wireless channels6to the client device2A. Following receipt, the client device2A may deaggregate the AMPDU into the original two or more AMSDUs. Each AMSDU may be decrypted using the authentication and security information shared between the controller4and the client device2A. The decrypted AMSDU may be deaggregated into two or more data packets. The data packets may thereafter be processed by one or more applications running on the hardware processor21and/or stored in the data storage22of the client device2A.

As described above, the upstream and downstream AMSDUs sizes are determined based on the MTU size for the secure tunnel between the access point3and the controller4.FIG. 4shows a method9for determining the upstream and downstream AMSDUs sizes for communications between the client devices2, the access point3, and the controller4according to one embodiment. The method9may be performed by one or more elements of the network system1. For example, in one embodiment each of the client devices2perform the operation of the method9in conjunction with the access point3.

In one embodiment, the method9begins at operation10with the controller4and the access point3negotiating an MTU size for the secure tunnel between the access point3and the controller4. In one embodiment, the MTU size may be negotiated to be one of 6000 bytes and 9000 bytes. The MTU size may be determined based on the capabilities and configuration of the networking devices within the network7.

Upon determining/negotiating a MTU size, operations11and12select upstream and downstream AMSDU sizes, respectively. In one embodiment, the upstream and downstream AMSDU sizes are selected based on the MTU size between the access point3and the controller4, which was determined at operation10. In one embodiment, the upstream and downstream AMSDU sizes may be each selected to be less than or equal to the MTU size for the secure tunnel between the access point3and the controller4. For example, when the MTU size between the access point3and the controller4is 9000 bytes, the upstream and downstream AMSDU sizes may be set to either 3895 bytes or 7991 bytes. Although both the upstream and downstream AMSDU sizes may be set based on the MTU size, in some embodiments the upstream and downstream AMSDU sizes are distinct and different. For example, when the MTU size between the access point3and the controller4is 9000 bytes, the upstream AMSDU size may be set to 3895 bytes and the downstream AMSDU size may be set to 7991 bytes.

The selected AMSDU sizes may be utilized for upstream and downstream communications between the client devices2and the remote devices5. At operation13, the method9determines/detects if a new MTU size has been set between the access point3and the controller4. If a new MTU size is detected, the method9moves back to operations11and12to select new upstream and downstream AMSDU sizes, respectively. As described above, the upstream and downstream AMSDU sizes are selected based on the MTU size between the access point3and the controller4. In one embodiment, the upstream and downstream AMSDU sizes may be set to be less than or equal to the MTU size for the secure tunnel between the access point3and the controller4. By setting the upstream and downstream AMSDU sizes to be less than or equal to the MTU size, each AMSDU may be transported in a single MTU without fragmentation. By eliminating fragmentation of AMSDUs during transmission between the access point3and the controller4, performance of the upstream and downstream datapaths are improved through the elimination of fragmentation processing delays.

An embodiment of the invention may be an article of manufacture in which a machine-readable medium (such as microelectronic memory) has stored thereon instructions which program one or more data processing components (generically referred to here as a “processor”) to perform the operations described above. In other embodiments, some of these operations might be performed by specific hardware components that contain hardwired logic (e.g., dedicated digital filter blocks and state machines). Those operations might alternatively be performed by any combination of programmed data processing components and fixed hardwired circuit components. Also, although the discussion focuses on uplink medium control with respect to frame aggregation, it is contemplated that control of other types of messages are applicable.