Development Process Overview
Getting Started with the Devicescape Wireless Infrastructure Platform
The Devicescape Wireless Infrastructure Platform requires at least two systems:
- Development host with the Devicescape Wireless Infrastructure Platform installed. (The development host is used to create or edit source packages and build the binary image for the target.)
- Target device which will be a working access point (AP) once you have configured the device and loaded the target image. (You can have more than one target device in any environment.)
In a nutshell, the development process consists of creating binary RPMs from modified source files, bundling the binary RPMs (packages) needed for the runtime system into a root file system (RFS) image with JFFS support (a jffs2.image file), and then loading that image along with a specialized Linux kernel into the flash on the target system. A binary kernel image is provided with the platform, or you can modify the kernel and re-build your own.
Figure 1 Development Workflow Overview
You can develop applications fully with the command line utilities and toolchains provided, or you can use your own tools. (For a more detailed view of this process, see Figure 1: Workflow for Modifying a Package in Modifying and Building the Packages.)
To get familiar with the platform, we suggest that you follow the walk-throughs in this guide of creating a root file system (RFS) image with one of the reference designs first and load it onto the target device. Then as a next step in getting up to speed, experiment with extracting a source package and modifying the source, re-building it into a binary package, re-creating the RFS image, and redeploy to the target. When you are familiar with the built-in capabilities of the reference designs, you can start adding your own functionality via new packages or modifications of existing ones. Detailed walk-throughs of these tasks and more are provided in this guide.
Architecture Overview
The Devicescape Wireless Infrastructure Platform uses a modular, package-based architecture. This architecture facilitates customization, as you can easily add or remove support for features by adding or deleting the required packages. (The Devicescape Wireless Infrastructure Platform uses ipkg, the Itsy Package Manager, a lightweight system for installing, uninstalling and upgrading package.) The package-based architecture also allows you to update firmware without having to replace the entire firmware image.
The Devicescape Wireless Infrastructure Platform is made up of the following major functional areas:
- The Linux Kernel, configured for embedded devices. Source is provided as well as a binary image, so you can recompile the kernel to add or remove kernel features.
- The Wireless Subsystem, which includes the 801.11 access point, the 802.11 protocol stack, as well as traditional (monolithic) drivers.
- The Clustering Mechanism, which manages cluster-wide status, configuration sharing, channel planning, and provides an internal Radius server.
Additionally, the Devicescape Wireless Infrastructure Platform includes the following utilities:
- Busybox, a set of lightweight versions of the most common Unix utilities.
- Button and LED support.
- Mini-httpd, a lightweight web server.
- ntpclient, a network time protocol client.
The following diagram shows the major components and systems that make up the Devicescape Wireless Infrastructure Platform.
Figure 2 Devicescape Wireless Infrastructure Platform Architecture
For detailed walk-throughs of how to build the reference designs, see "Creating Root File System Images for the Reference Design AP" on page 10.
The Linux Kernel
The kernel consists of a Linux core, configured for embedded devices. It contains and the modules required to use the processors and boards that the Devicescape Wireless Infrastructure Platform supports. The kernel, additionally, has ethernet support, TCP/IP network stacks, and network bridging. The kernel supports the JFFS2 and cramFS file systems, used for the device's flash memory.
The Wireless Subsystem
Operating partially in userspace and partially in the kernel, the wireless subsystem is the second major component in the Devicescape Wireless Infrastructure Platform architecture. It consists of the following elements:
- The wireless chipset drivers
- The DataPath driver, a 802.11 stack
- The host access point, which provides higher-level API to 802.11 features such as authentication, association and disassociation.
The wireless chipset drivers support the Atheros and Broadcom radios.
Drivers
The Atheros driver is a kernel module. It separates radio-dependent support from the support for radio-independent features (that is, features common to the 802.11 specification.) This radio driver uses the DataPath driver for radio-independent functions.
The Broadcom driver does not use the DataPath driver. The Broadcom driver is monolithic and contains its own 802.11 stack.
The drivers for all supported chipsets and the DataPath driver operate in kernel space.
The Host Access Point
The host access point operates in user space. It manages higher-level 802.11 services, such as authentication and encryption, that are not time-critical (and therefore do not have to operate in kernel space.)
The Wireless Subsystem supports a large number of advanced wireless network features, including the following:
- Wi-Fi Multimedia (WMM)
- Dynamic VLANs
- Atheros Extended Range (XR) (a proprietary method for implementing low rate traffic over longer distances.)
- 80211h: spectrum and transmit power management for European 5GHz band including DCS (dynamic channel selection)
- Multi-BSSID's, which are virtual access points (that is, a single piece of hardware with multiple logical MAC addresses and multiple logical access points.).
The next level of the Devicescape Wireless Infrastructure Platform, the Device Management Agent, uses a plugin (dot11.dman) to communicate with the wireless subsystem.
The Device Management Agent
The Device Management Agent is the third major component in the Devicescape Wireless Infrastructure Platform. It provides an abstract model of the device configuration and status and maintains a central repository of device configuration data. Additionally, the Device Management Agent is responsible for initializing provider services.
To enhance the extensibility of the Devicescape Wireless Infrastructure Platform, the Device Management Agent uses a plugin architecture. You can add new services at runtime, as plugins; you do not have to recompile the platform. You provide the plugin and the required configuration data (or use an interface to allow the user to supply configuration data) and the Device Management Agent then starts up and configures the new device or service.
The Device Management Agent is part of the Device Management Agent framework, which consists of the following components.
- Class definitions, tools, and schema definitions
- Device Management Agent providers. The provider is responsible for querying the wireless subsystem for configuration data and defining the configuration data model.
- Device Management Agent consumers, such as the web interface the SNMP interface. Typically consumers not only display data; they are also used to set configuration data. (For example, the web interface, a Device Management Agent consumer, might be used to set a SSID.)
This framework allows you to abstract configuration data so that only one component, the Device Management Agent provider, has to understand the particularities of how a service or device makes it configuration available and how that devices or service receives updates to its configuration data.
The provider abstracts a device's configuration data as a metamodel, and it registers this metamodel with the Device Management Agent at each start up. This metamodel is then made available to all Device Management Agent consumers, and the consumers use this metamodel for all configuration data. Configuration data consumers, therefore, do not have to include logic for managing the configuration data of each supported device.
The language used to manipulate configuration data is called LSQL, or "light SQL." You can use a variety of means to access and manipulate configuration data, including the following:
- A C API
- HTTP, via the Administrative Interfaces
- TCP
- Unix Pipes
The Device Management Agent exports the configuration data to the wireless subsystem using the dot11 plugin (dot11.cpd). This plugin writes configuration data hostapd.conf file, used by the wireless subsystem.
For more information about the Device Management Agent, please see Development Process Overview i this guide.
The Administrative Interfaces
The Devicescape Wireless Infrastructure Platform provides support for a number of administrative interfaces, including the following:
- An extensible, templatized web interface
- SNMP
- A command line interface (CLI)
You can customize any of these interfaces and also remove the interfaces that you do not use.
The Web Interface
The Devicescape Wireless Infrastructure Platform provides a framework for building Web applications. The framework is based on a Model View Controller design architecture. CGI is used to get and set data, and ClearSilver Web page templating system is used for dynamic presentation of HTML based on the runtime back-end data interactions with the system to which the Web application is communicating.
Although the Web application framework can be used to develop any kind of Web-based application regardless of the back-end data sources and system, the framework has built-in support for data retrieval and configuration of a target AP device built with the Devicescape Reference Design AP.
Web-based monitoring and configuration of the AP is accomplished through interaction with key components of the AP runtime software such as the configuration subsystem and clustering mechanisms (clustering and clustering-ap-schema).
The Devicescape Reference Design AP that ships with the platform includes a fully operational Web UI that leverages the Web UI framework and models dynamic interaction with most of the features and components supported in the reference design. For example, the Web UI provides has tabs for configuring and managing the following (and more):
For more information on the Web interface, see Using the Web UI Framework to Develop and Customize AP UIs in this guide.
Simple Network Management Protocol (SNMP) Interface
The SNMP interface allows you to configure devices and services using SNMP. SNMP is used primarily between binary components. The SNMP interfaces uses the libsql package translate between SNMP and the LSQL syntax required to access and manipulate configuration data.
The Devicescape Reference AP supports the following standard SNMP MIBs:
- Bridge MIB 802.1d (RFC 1493)
- SNMPv2 MIB (RFC 3418)
- IEEE Std 802.11 MIB (base)
- Interfaces Group MIB (RFC 2233)
Two Devicescape proprietary MIBs (Wireless MIB and System MIB) based on the upcoming IEEE 802.11k MIB. They provide information about the Devicescape Reference AP client association list and AP detection table, respectively. The Devicescape System MIB provides maintenance functionality such as system reboot or firmware upgrade.
The Command Line Interface (CLI)
The command line interface connects to the Device Management Agent using a serial, telnet, or ssh connection. It uses the liblsqlquery component to execute LSQL statements. It supports most, but not all, administrative functions. (You cannot, for example, perform a firmware update or access live cluster data.)
The Clustering Mechanism
A key feature provided by the Devicescape Wireless Infrastructure Platform is the ability to incorporate clustering behavior into your Access Point (AP) target devices. Clustering allows multiple AP devices on a network to recognize each other and dynamically share configuration information, thereby participating in a "self-managed" wireless local area network (WLAN).
Clustering is the ability of AP devices to form a dynamic, configuration-aware group (called a cluster) with other similarly designed APs in a network in the same subnet. Access points can participate in a self-organizing cluster which makes it easier for you to deploy, administer, and secure your wireless network. The cluster provides a single point of administration and lets you view the deployment of access points as a single wireless network rather than a series of separate wireless devices.
The schema controls what configuration data is shared among clusters. You can edit this schema to control what data is propagated.
For more information about the clustering mechanism, see Understanding Clustering Behavior on the Target AP in this guide.
Detailed Architecture Diagram
The following figure shows a more detailed view of the Devicescape Wireless Infrastructure Platform, including the packages that make up the various components.
Figure 3 Detailed Architecture Overview, with Packages
What's Next?
- See Creating Root File System Images for the Reference AP for information on how to build each of the reference designs. The process will familiarize you with basic tasks such as creating a project, adding binary RPM packages for the device you want to build, and bundling up the packages into an RFS image which can be programmed onto the flash for the target device. You will get an understanding of which packages are required for the Reference Design AP and how to build for the target hardware.
- See Modifying and Building the Packages for an overview of a typical development workflow and information on how to extract a source RPM, build a userspace package from a source RPM, and how to build a pre-packaged or custom kernel.
- See The Device Management Agent for an introduction to the Device Management Agent data model and plugins, and a tutorial on plugin development using the Device Management Agent Schema and Subsystem API.
- See Implementing Clustering for information on how to include clustering on the target device. (Clustering allows multiple AP devices on a network to recognize each other and dynamically share configuration information.)
- See Board Porting for information on how to port the software to a board other than the supported reference boards.
