Product Engineering Services Customized software development services for diverse domains
Quality Assurance End-to-end quality assurance and testing services
Managed Services Achieve scalability, operational efficiency and business continuity
Technology Consulting & Architecture Leverage the extensive knowledge of our Domain Experts
August 6, 2009
Recent years have seen a phenomenal growth in demand for residential broadband. With the advent of small form-factor high performance integrated SoCs (see, for example, the TI) and short area broadband wireless technologies (Wi-Fi and the upcoming WiMAX/LTE), the broadband access point or Base Station Router (BSR) is becoming a mass-market item. Coupled with the ongoing interest in ‘femto-cells’, it is likely that over the next five years, residential “access point” base-stations will to a significant percentage of the communication requirements. The cBSR can be defined as a base station which has limited capabilities it terms of user data throughput, number of subscribers and is typically based on off-the-shelf hardware. It is more suitable for small scale deployments like wall mount or SOHO networks. There are varied differences between the multiple wireless technologies that currently exist or are developing in terms of protocol procedures, radio resource management the frequencies they operate and the underlying radio access technologies they use. However, all of them are focused on one primary goal of providing high speed broadband access to users, using standardized, low-cost hardware platforms and off-the-shelf software. In all of these products, the engineering challenge is to marry packet processing capabilities of standard desktop class operating systems, to the special requirements of the SoC servicing the wireless interface. If the data path of MAC for all these technologies is analyzed, they have many functions that are in common and the design concepts to implement these functions can be used across any wireless technology like WiMAX or LTE or even older WiFI. Consequently, if we consider the BSR as a generic product (with specialized interfaces for wireless access), then the common core functions can be formulated into a design framework which is suitable multiple wireless technologies.
Generally any data link layer performs the following functions
The logical link control is the function performed by the data link layer to provide services to multiple kinds of network layers. In the wireless context they are termed as a Radio Link Control and typically perform identical operations independent of the MAC below them.
Similarly, the data part of any wireless layer 2 MAC performs the following generic function in addition to the many technology specific functions. Needless to say this makes each technology special in its own way. The wireless MAC functions mainly include
This article proposes an efficient generic design framework for the medium access layer which can be used across wireless data technologies with minimal customizations to ensure high speeds and throughput. The framework proposed here is just a reference design for the cBSR class of products and may not be suitable for large multi sector carrier grade base stations with sophisticated product requirements like high availability
A sample snapshot of the cBSR system architecture is given in Figure 1 which gives the placement of the MAC data path framework in the overall system. It has been shown in yellow color
Figure:1 cBSR System Architecture
Figure 2 shows the architecture of a typical wireless data MAC
The design proposes a de-coupled control and data plane which makes it all the more wireless technology agnostic. This means that it is possible to plug in most of the wireless control stacks with this data path design framework with minimal customizations. The framework enables this by means of a clearly defined interface which can be used by any control stack implementation to populate the database. The parameters and the values to be populated are derived as a result of various control messages exchanges that take place for establishing the connection.
Based on the generic functions which have to be provided by the wireless MAC as mentioned in the earlier, the following key elements have been identified
Figure:2 Design Framework
This database contains the connection setup information. This information is organized in a such a manner that it
The Resource Allocator is responsible for
The method by which its does allocation of the physical radio resources; depends on the access Technique being used by a particular Radio technology. For e.g. If the Access Technique used is OFDM than the Resource Allocator procedures may by similar across all Radio technologies which use OFDM. The proposed design framework provides an API by means of which most kinds of resource allocator can be plugged into the data path stack with minimal changes.
The MAC Data path has the following Components:
Assuming the Network layer currently used is typically IPv4/IPv6 all the operating systems provide a standard well defined interface to plug the Wireless MAC from the existing network Layer. A pseudo network device driver interface can be used for achieving such functionality in case of Linux as well any BSD based Operating System. A standard interface like netfilter, iptables or by creating a pure static routing entry into the kernel routing table is sufficient to make all the IP PDUs travel through the Wireless MAC Layer.
Currently, in the Linux the wi-fi MAC layer is implemented very similarly. A network device is setup for each physical wifi interface available typically named a wifi0 and so on. When an IP packet is routed by the Linux IP stack it checks for the outgoing interface in its forwarding information base ( FIB or the routing table). In case the outgoing interface is a wifi interface it is the packet is handed over to the hard_start_xmit API which is initialized to the MAC processing API of the wireless device. Hence this kind of Ethernet like interface can be extended to any kind of wireless MAC for providing a neat and clearly defined API interface to make an entry into its MAC processing.
However, there could be some differences on how these entry point APIs are invoked. Currently, a transmit routine is invoked whenever an IP packet is available for delivery. However in case of a technology like WiMAX the transmit routine may be invoked as and when the driver indicates that downlink bandwidth is available for a part or the complete IP packet to be transmitted.
Once the IP PDUs reach the MAC layer enqueuing them for further processing based on the flow they belong to and what treatment should be given to each such flow becomes a key functionality to be exhibited by the MAC layer. Each queue may be organized based on per connection basis. This connection will have a unique numeric identifier, which will map to the CID in case of WiMAX, a RABID in case of 3G/LTE or an MS ID in case of GPRS; the data path is agnostic to the original source of the id.
Each flow may belong to a particular connection. The queue depth of each connection shall be based on the QoS parameters agreed for that particular connection, the outstanding bytes on that connection and the kind of flow control that has to be offered on the ingress side.
In the downlink side each SDU that has to be transmitted over the physical media may have to be segmented based on the number of bytes scheduled on the air. In case the number of bytes scheduled on the air is less than size of the next SDU available for transmission it shall do segmentation otherwise the MAC layer shall try to pack as many SDUs as can be accommodated in the number of bytes scheduled for transmission by the resource allocator. In the uplink side the re assembly procedure shall be executed. The segmentation and re-assembly state machines are common across most of the technologies and can be reused with minimal or no changes.
The composition of the SDU’s into an actual wireless data units that his transmitted OTA is the key role played by any wireless MAC and varies across multiple technologies. This components deals with physically constructing the payload and appropriately inserting the information in the form of special headers which indicate the type of fragment, the layer 2 addressing and sequence number in case some flow control or retransmission is supported by the MAC. The illustration in Figure 3 and Figure 4 gives example of composed SDUs for WiMAX and LTE
Figure:4 LTE MAC Data Unit
Across each of the components of the Wireless Data MAC the existing network buffer management of an Operating system can be used to get a buffer chain once the MAC processing is complete which may easily be used by the MAC PHY interface for transmission over the physical media. In case of Linux the socket buffer or skb’s can be used and in case of BSD the mbuf buffer chain can be used. The benefits of using a standard buffer management scheme are
However, there are some limitations in the standard buffer management scheme due to which implementers may chose an internal proprietary buffer management scheme. These limitations are
The PHY handling component of this framework needs to be totally customized or ported for transmission/reception of the data payload and hence varies across wireless technologies. In addition to the normal PHY handling procedures like setting up devices and readying them up for transmission or reception this component may also need to do a unification function. The unification function may include flattening up a network buffer chain supplied by the MAC Layer into a format which is understood by the PHY interface in the downlink direction and converting it into a network buffer chain which can traverse the entire OS in the uplink direction (RX case). Any kind of customization or optimization to make the whole MAC interrupt driven/polling driven or both may be done as a part of this component
Last but not the least an important requirement for any Wireless MAC is the need of a triggering criteria which shall kick off the entire MAC processing. This component shall also supply the timing information to the entire implementation and may be tightly coupled to the control plane for setting up the data path. An example of such a criteria could be the frame interrupt in case of WiMAX which may either be 5ms or 10ms depending upon the specifications the MAC is using
802.16e WiMAX MAC data plane has been chosen to prove this design framework. The entire data path was made to run over the existing Ethernet driver.
The simulation of this design has been done using the Linux Kernel 2.6.21 wherein the entire MAC was running as a kernel Module. The Connection database is populated through a neatly defined NETLINK interface from the user plane. The information is stored in the XML files which can be hooked to any kind of GUI.
The triggering criteria have been established by means of a high resolution timer library which is capable of generating 1ms and above interrupts.
All the components of Wirelss MAC design framework in the following fashion to achieve the functionality of the WiMAX MAC data path
Queue Management & Composition
The Composer of the SDU was made to trigger by means of high resolution timer library which simulated the frame interrupts. This was module was responsible for filling the data burst. And hence in the process of filling data (in PDU format) it does fragmentation and packing if the connection (i.e.CID) allows so. The composer maintains per CID circular queue and provides API for en-queuing of IP packets to the IP stack.
Unification/Phy Handling
The Unification/Phy handling module contained the logic of building downlink frame and the corresponding interface to the physical layer for transmitting the same. The main function include frame planning (identifying zones to be transmitted), DL bandwidth scheduling (bandwidth allocation to each connection), DL burst building (creating two dimensional allocation plan covering the dimensions of each zone) and burst delivery in real time. It took the help of Composition function for filling DL bursts. The composition and Unification/Phy handling modules thus served the functionality of CPS sublayer 802.16e MAC.
Network Interface
A pseudo Network device driver named as WiMAX0 was used to en-queued the IP Packets in per CID queue.
Connection Database
A Provisionary Application was implemented for reading configuration parameters from configuration file and populating the data in Connection database using Netlink interface. It was also apply classifier rules and routing table updates at IP layer. Hence Network Interface and Provisionary application serve the functionality of CS sublayer of 802.16e MAC.
The entire data path was implemented as Linux Loadable Kernel Modules (LKM ) and executed from the context of the softIrd. It is recommended that for implementations that use this framework should execute the entire data path as part of kernel a single kernel context
The provisionary application written to populate the connection database was written as a user space process. To attain throughput data points it was mandatory to establish an end to end data connection and hence there was a need to write a verifier so that it could re-assemble the packets transmitted by this MAC over the Ethernet on the other side. Using a proprietary protocol known as WiMAX over Ethernet or WoE the end to end data connection has been established.
A profiling tool IPerf has been used to establish TCP connection using the WiMAX data path and get throughput data points. The information mainly consists of data rate or bandwidth achieved on the link for a specific interval of time. Additionally it also provides information about the packet loss over that connection.
Extension to LTE
