Opening Base Station Architectures Part 1: An Inside Look at OBSAI

In this two part series, we'll take a look at the standardization efforts of both the OBSAI and CPRI organizations. Part 1 will focus on OBSAI while Part 2 will look at CPRI.

Skeleton of a BTS
OBSAI is an open forum that was started by Hyundai Syscomm, LG Electronics, Nokia, Samsung Electronics and ZTE Corporation in 2002. Its goal is to create an open market for cellular base stations (BTS). Let's take a look at the key elements that make OBSAI work.

A base station transceiver system (BTS) is composed of four main components. As shown in Figure 1 below, the radio module receives signals coming from portable devices and down converts it to digital data. A processing module then takes the encoded signal and brings it back to baseband before it is transmitted to the terrestrial network via the transport module. Coordination between these three functions is maintained by a control module.

The key objective of OBSAI is to create an open market for BTS components by defining standard interfaces used to connect the four modules described above. In the OBSAI specification, interfaces between modules are known as reference points (RPs). From Figure 1, we see that RP1 is the interface that allows communication between a control module and the other three modules. RP2 provides a link between the transport and baseband modules, while RP3 connects the baseband and radio frequency (RF) modules.

Currently, most of the focus in the industry revolves around providing lower RF modules and power amplifiers (PAs). Those two components usually account for close to 50 percent of the cost of a BTS. Thus, OBSAI's primary effort has been to define reference point 3 (RP3) before defining RP1 and RP2. Let's look at RP3 in more detail

RP3: Linking Baseband and RF
The OBSAI RP3 specification defines the interface between the baseband module and the RF module which includes a maximum number of nine pairs of unidirectional links for every baseband and RF module. For a typical BTS, those links can be connected with either a mesh or a centralized combiner and distributor (C/D) topology.

The C/D topology is more suitable for a large BTS as it is easier to manage than the mesh topology. In this case, a switch card acting as the C/D with a high-performance FPGA and serializer/deserializer (serdes) solution is a very desirable. For very large configurations, a mesh, bridge or C/D topology can be used, although an inter-cabinet connection may be required. OBSAI also includes a special specification (RP3-01) for remote RF heads. Figure 2 illustrates how the RP3 connection for different topologies could be implemented.

RP3 uses a four layer protocol stack: physical, data link, transport, and application layers. The application layer provides mapping of packets to the payload. Currently, W-CDMA, cdma2000, and GSM/EDGE packet types are supported. However, the application layer can be expanded to accommodate future packet types.

The transport layer provides end-to-end message routing. The data-link layer frames and synchronizes the messages, while the physical layer sends out the messages on the electrical interfaces that include serializing and coding the data. Let's look at the physical and data-link layers in more detail, starting with the physical layer.

Defining the PHY
The physical layer of the RP3 bus interface is based on differential signaling technology. Differential signaling with clock data recovery circuitry eliminates the need for a wide data bus between the RF and baseband modules. It also helps reduce power consumption and increases system reliability.

In the OBSAI PHY spec, high-speed serial data allows the transmission through a backplane and/or cable at much greater distance than the traditional parallel bus while avoiding any of the skew and timing problems normally associated with it.

The RP3 electrical specifications defined for the OBSAI PHY architecture are based on the XAUI electrical specification and customized to the need of a BTS. The XAUI electrical interface is specified in Clause 47 of IEEE 802.3ae-2002.

RP3 electrical line rates are defined as 768 and 1536 Mbit/s but there is no mandatory rate specified. Also, there is no auto-negotiation specified to handle potential line rate mismatch between baseband and RF modules.

The RP3 electrical specification defines a receiver compliance mask and provides a sample transmitter output mask. The bit error ratio (BER) requirement is 1 x 10^-15, which is more stringent than the XAUI requirement of 1 x 10^-12.

The electrical spec's unit interval (UI) also differs from the XAUI specification. A difference of +/- 100 ppm is allowed in the XAUI specification. This ppm difference does not apply to OBSAI-based systems since BTSes are fully synchronous systems.

Programmable devices that include high-speed transceivers can be used to support RP3. A typical implementation requires a transceiver that provides clock data recovery, serdes, 8B/10B encoder/decoder, pattern detector, and word aligner, which form the base of the physical-layer implementation of the OBSAI specification. Additionally, an architecture that embeds the complete OBSAI RP3 processing engine and the high-speed transceivers reduces the complexity of the printed circuit board (PCB). One can, therefore, use a chip that requires fewer I/Os than what is necessary to interface to external independent serdes drivers.

Worst-Case Conditions
OBSAI used two worst-case channel models to define its physical-layer device requirements. One was based on very long FR-4 trace, and the other was based on very long cable. To investigate the serdes requirement driving the two worst-case channels, the channel model shown in Figure 3 was built combining both worst-case channels of OBSAI.

Signal integrity is imperative at higher data edge rates as losses across transmission media such as FR-4 PCB fabric cause a deterioration of high-frequency signals. Optimal performance is obtained by using a transceiver that includes dynamically controllable pre-emphasis and receiver equalization, which are used to compensate for signal losses, and maintain signal integrity. By employing these techniques, we were able to run a bit error rate (BER) test of 10^-15 without any errors on the channel conditions illustrated in Figure 3 above.

Data Link Layer Issues
OBSAI employs a fixed-length message format of 19 bytes in the data-link layer, as shown in Table 1.

A message group contains M_MG number of data messages, one control message, and K_MG number of IDLE bytes. N_MG number of message group forms a master frame. Idle codes K28.5 are used to mark the end of each message group while idle codes K28.7 are used to mark the end of a master frame. OBSAI recommends using the following parameters, shown in Table 2, for different wireless air interface standards.

Since a BTS is a synchronous system, it is imperative to measure and collaborate the delay across any bus. OBSAI has carefully considered this and, as a result, come up with a method for synchronizing the master frame across the RP3 link. Delay calibration takes into account all factors, including processing, and buffer delay, in the transmit and receive module, as well as the latency across the link.

Another major item in the data-link layer is the synchronization between the transmitter and receiver. Synchronization ensures the actual data can be decoded successfully over the link. The frequency of errors as well as the synchronization status is constantly monitored.

There are, however, separate transmitter and receiver state machines for each transceiver. The transmit state machine is responsible for establishing the link and ensuring successful data transfer between the transport layer and the physical layer once the data is correctly framed. The receiver state machine is responsible for establishing the link with the transmitter and ensuring the data are being received properly. The receiver state machine monitors the error counts and determines whether valid frames are received.

Extending RP3
The latest work by OBSAI on RP3 is a RP3-01 extension. It specifies the RP3 interface protocol for remote RF head use. Figure 4 shows the reference architecture of a BTS with remote RF units.

Line rates that are integer multiples of 768 Mbit/s, up to 3840 Mbit/s, are considered OBSAI-compatible line rates. Due to the number of line rates available, auto-negotiation between the remote RF units and the local units are defined. The specification also defines Ethernet transmission between two RP3-01 nodes.

Due to the lack of a physical RP1 link on a remote unit, RP1 information must be mapped into the RP3 link. Other items in the data link layer specification include delay measurement, synchronization between RP3-01 units, and data multiplexing across the RP3-01 link.

RP1 and RP2
As stated above, RP1 is the interface to the control and clock for the baseband/RF block for exchange of control, signalling, OAM&P and clock data. RP2, on the other hand, interfaces with the transport block on behalf of the baseband block in exchange for user data. The management plane of the RP1/2 interface is finished whereas the control plane is yet to be defined by OBSAI.

OBSAI selected the simple object access protocol (SOAP) for message passing in the management plane of RP1/2 (Figure 5). Using XML, SOAP is a protocol used in web services for application to application communication. The common SOAP software stacks are gSOAP, targeted for large platforms, and eSOAP, which is better suited for embedded systems.

In addition to HTTP and TCP transport services, OBSAI introduced the UDP-based communication protocol (UDPCP) transport service in the RP1 specification. UDP is a connectionless transport protocol. A BTS requires a connectionless transport protocol that provides both reliable and unreliable transport service. Essentially, it adds the missing features over UDP to create the UDPCP protocol.

Implementation of SOAP can be done using external processors or embedded soft processors. Using an embedded soft processor can be a very cost effective and convenient solution for many base station modules. It makes the most sense when no existing processor is available to serve the SOAP function. The SOAP processing can be integrated in the same FPGA with other functions of the base station module to achieve the maximum cost saving.

Editor's Notes: Additional information on OBSAI can be found at www.obsai.org. To view Part 2, click here.

About the Authors
Jason Wong is a technical account manager at Altera Corp. Jason holds a bachelor's degree in electrical engineering from Chinese University of Hong Kong and an MS of Engineering Management from University of Southern California. He can be reached at jwong@altera.com

Christian Plante is a wireless development manager at Altera Corp. Christian holds a bachelor's degree in electrical engineering from Université Laval, Quebec and an MBA from Queen's University, Kingston. He can be reached at cplante@altera.com.