Reconfiguring Design -> Reconfiguring for broadband access

For example, Radlan undertook a development project in partnership with a company that wanted to manufacture equipment for wireless broadband access to serve places where network infrastructure is not available, such as remote areas and developing countries. Performance goals, as well as special challenges presented by using wireless links from the basestation to terminal stations, required both the addition of an FPGA to the system and software that was reconfigurable.

The plan was to serve local areas by using standard cable connections to a basestation, to go wireless from the basestation to terminal stations o n or near the buildings where the customers are located, and to use cable from the terminal stations to the customers within the buildings. The wireless links had to support both data communications and voice service.

The customer wanted to use this basic design: The access point at the basestation would comprise a chassis containing multiple line cards, each a self-contained subsystem supporting multiple customers through wireless links. Each line card would provide both time-division-multiplexed voice service and data handling, but voice and data traffic would be multiplexed at the physical level only, so data- and voice-handling subsystems would be completely separated from the logical point of view. In addition, all line cards would be connected over a shared backplane to uplink cards and from there to the carrier. System controller cards and software integration would combine all components into a single, logical entity.

With these objectives in mind, the company based its system on Radlan's Marvell GalNet Switched Ethernet Controller, which has a number of capabilities that suited those objectives. Complete switch-on-a-chip support is available for all standard Ethernet switching and Internet Protocol (IP) version 4 routing, including all related standards such as multicasting, class of service and quality-of-service (QoS). In addition, the controller has an external hardware interface, which makes it possible to attach an FPGA for customized functions and to factor in logic that depends on data that is external to the system.

However, our customer faced several significant challenges. One was that a number of users needed to be connected to each port; thus a special means to provide each customer with a logically distinct connection would be required, even though a shared physical port was used.

Another challenge was that wireless links are limited in bandwidth; conserving bandwidth meant using nonstandard frames for the air link, making standard switching impossible.

A third issue was that the quality of radio transmission between the basestation and the terminal stations is dependent on the weather, since rain and wind interfere with radio frequencies. This meant using alternate links when signal quality changed-but there was nothing in the Ethernet frame itself on which to base this decision, so standard switching techniques would not suffice.

At the hardware level, some of these challenges were met by attaching an FPGA to the GalNet's external hardware interface port and programming it to do the things the GalNet could not do. But the FPGA alone was not enough to deal with all the necessary functions.

The company needed to connect a number of customers to each port so that each customer had a logically distinct connection, even though they shared a port with other customers. We attached IEEE standard 801.1Q VLAN tags to each frame to distinguish between customers. But because a customer was distinguished only by the Layer 2 VLAN tag, it was possible for two customers to have the same IP subnet, or group of addresses. This would make it impossible to perform standard IP switching for them.

On the other hand, due to the desire to conserve wireless-link bandwidth, frames over the wireless link did not include the media-access control (MAC) headers, and so IP switching was an absolute must. So, we modified our software to provide a virtual router for each VLAN. That is, from the system's point of view each client had its own private router that was completely separate from any other client's router, even though they were all using the same system. This was accomplished by creating separate IP-forwarding decision tables for each VLAN.

Spoofing, a technique hackers use to break into a system, can also be used for bandwidth savings by stripping fields from the header of a packet and then reconstructing them at the other end. It is possibl e to avoid sending entire frames by having the near end carry out actions on behalf of the far end of the link. The FPGA attached to the external hardware interface port was programmed to remove most of the MAC headers from outgoing frames, to construct missing fields for incoming frames and to make them conform to the Ethernet standard. Then standard Layer 2 processing could be done in the basestation and Layer 3 in the terminal stations, including QoS.

Spoofing frames

The system software was adapted to make each frame pass through the FPGA for the process, and carried out various spoofing operations to remove some whole frames from the traffic stream.

Normally the decision of how and where to send a packet depends on what is in the packet header, but in this case the decision is also affected by external factors like the weather. Each encoder was connected to a different physical port of the switching chip, so switching to a different encoder required looking to the Ethern et switch for a different router. The problem: there's nothing in the packet content itself on which to base a decision of which route is the correct one at any given instant.

Sensors were installed at the basestation antennas to measure bit errors and signal-to-noise ratio, and to send this information to the FPGA attached to the external hardware interface. The FPGA then used this information to intervene in the standard switching process and rerouted the frames to the correct port and toward the correct encoder.