The importance of Baseband unit (BBU) emulation
The importance of Baseband unit (BBU) emulation
Previously published on Light Reading
Please visit our website for more information on this topic.
Lately, we&#;ve focused on steps needed for operators to get their RAN ready for their next mobile technology evolutions -- including advanced 4G standards and, ultimately, 5G. (See Beyond CPRI: Planning for 5G Fronthaul and Preparing the Transport Network for 5G: The Future Is Fiber.)
While the industry continues to debate the pros and cons of technologies (Ethernet vs. CPRI) and architectures (distributed RAN vs. centralized RAN), they must not lose track of the basic, practical steps that should also be taken along the way. In this blog, we discuss the importance of BBU emulation as part of the overall test process for turning up cell sites.
In today's mobile networks, the base transceiver station (BTS) has been separated into two components -- the remote radio head (RRH) located at the top of the cell tower next to the antennas and the baseband unit (BBU) below. In most 4G networks, the BBUs typically sit at the base of the tower. The newest trend in 4G -- and certainly with 5G -- is to centralize BBUs in central offices, several kilometers away from the cell towers. This is called centralized RAN, or C-RAN.
Significantly, whether building out distributed RANs or new centralized RANs, BBU emulation is an important part of the turn-up process, along with connector inspection and fiber characterization. In cell site construction (whether distributed RAN or C-RAN), BBUs may not be installed or commissioned until after the cell tower is handed over to the mobile network operator. At this point, the mobile operator may find that cell tower transmissions aren't working properly -- or at all -- and a time-consuming and costly process ensues to find the cause of the transmission degradation or failure.
Ideally, cell tower installers would have the tools available at the time of installation to ensure that, when the mobile operators deploy their BBUs, all cell tower components and connections will be in working order. BBU emulation accomplishes this goal by imitating BBU transmission and RRH communication without requiring an actual BBU in the network. Here are some important tests that installers can perform by adding this relatively simple testing step:
- Identify RF interference source: Installers/technicians will learn if there is any RF signal interference associated with the cellular transmission. If the RF interference occurs across multiple antennas on the tower, it is mostly likely an external source -- which could include anything from nearby Sonet equipment to old cable amplifiers or even baby monitors in the area. A single antenna interference indicates an internal source, such as a coax cable defect or a faulty antenna.
- Passive intermodulation (PIM) testing: PIM is mixing of sub-carriers caused by defects in the mechanical components of a wireless system, comprised of antennas, transmission lines and related components. Similar to RF interference, PIM sources can be internal -- such as rusted elements or bad connectors -- or external -- such as nearby metal pipes or roofing. The BBU emulator can identify PIM as well as help determine whether that source is internal or external.
- Fiber cable installation validation: Mixing up fiber connections to the RRH is a common cell tower installation error. BBU emulation can be used to assure that all fibers are connected to the correct RRHs and the correct antennas/direction (sectors).
- Antenna and coax cabling validation: While fibers connect the BBU to the RRHs, coax connects the RRH to the antennas. BBU emulation can be used to ensure that the coax cabling is wired correctly and performing to the mobile operator's specifications. Using BBU emulation, mobile operators can instruct the RRH to perform a return loss measurement and related voltage standing wave ratio (VSWR) measurement which will provide an assessment of the quality of the coax and antenna connections.
To be clear, each of the problems detected by BBU emulation could also be diagnosed by the mobile operator once the BBU is commissioned at the tower. The value in BBU emulation lies in detecting faults during installation and prior to commissioning to avoid lengthy and costly delays in service turn-up and help them generate new revenue streams faster.
Battery Backup Unit (BBU/BBM) Maintenance for RAID ...
This page is no longer updated and is purely for reference purposes still here in the archive available.
Modern RAID controllers have integrated caches for increasing performance. With corresponding protective mechanisms, the content of these caches would be lost when a power failure occurs. For that reason, the cache content is often protected by a BBU or BBM (depending on the manufacturer, either the term Battery Backup Unit (BBU) or Battery Backup Module (BBM) is used). However, proper maintenance is required so that the BBU will actually work properly during a power failure. With such maintenance, complete data loss may be a risk during a power failure in the worst case.
Note: RAID controllers, which do not use a BBU to protect the cache (but instead copy the content of the cache to flash memory in the event of a power failure), do not require special cache protection maintenance (e.g. Adaptec ZMCP or LSI CacheVault).
BBU & BBM Maintenance Basics
BBUs always consist of two components:
- electronics for controlling and communicating with RAID controllers
- a rechargeable battery
The battery will be completed charged when it is first placed in service. Through the self-discharging process, however, the battery will lose part of its stored energy. For that reason, it will be periodically re-charged.
Loss of Capacity
Over the course of time, the battery will lose some capacity (thus, the maximum storable amount of energy will decrease). This behavior is also well known from notebook batteries. For a new notebook with a new battery, the potential battery operational time might amount to three hours, for example. After three years of use, a fully charged notebook battery might last only 40 minutes, for example.
RAID controller manufacturers generally indicate a useful period of up to five years for BBU batteries. The actual life will depend upon several factors (environmental temperature, number of charge/discharge cycles and so forth). If a battery has only a minimal capacity after several years, it will only be able to protect the cache content for a few minutes during a power failure (even if the battery has been fully charged). Thus, the battery is an expendable component. It status should be periodically checked. If its capacity has reached a minimal state, either the battery or the BBU should be replaced, to avoid data loss during a power failure. (Note: The battery itself can be replaced in 3ware controllers; for Adaptec and Areca controllers, the battery is soldered to the electronics, which forces replacement of the entire BBU.)
Backup Duration
Even a new battery with high capacity can only retain the cache content for a limited interval (typically 72 hours). If the power failure were to last several days, the cache content might be lost despite a new battery.
Examples
3ware RAID Controllers
3ware provides the ability to perform a so-called "battery test" with their RAID controllers[1]. This test serves to determine the precise capacity of the battery and thereby determine an estimated value for the potential backup duration during a power failure.
The objective of this test is the determination of the most precise estimated value possible. For this, the battery will first be fully charged. After that, a complete discharge cycle will be started. At the end of this test, the battery will automatically be completely re-charged. The entire process typically takes eight to twelve hours. 3ware recommends performing this test every four weeks.
Important note: During the entire test and the subsequent re-charging of the battery, the RAID controller&#;s cache will be deactivated. Because it might lead to a limitation on performance, this test should only be performed at times, when there will be a minimal load.
For example, the status of the BBU can be requested through the 3ware command line interface (CLI).
HUAXUN are exported all over the world and different industries with quality first. Our belief is to provide our customers with more and better high value-added products. Let's create a better future together.
root@testserver:~# tw_cli /c0 show Unit UnitType Status %RCmpl %V/I/M Stripe Size(GB) Cache AVrfy ------------------------------------------------------------------------------ u0 RAID-1 OK - - - 34. ON OFF u1 SPARE OK - - - 34. - OFF Port Status Unit Size Blocks Serial --------------------------------------------------------------- p0 OK u0 34.47 GB WD-WMANT p1 OK u0 34.47 GB WD-WMANT p2 OK u1 34.47 GB WD-WMAKH p3 NOT-PRESENT - - - - Name OnlineState BBUReady Status Volt Temp Hours LastCapTest --------------------------------------------------------------------------- bbu On Yes OK OK OK 255 06-Apr- root@testserver:~#
You will find additional information about the potential BBU status of 3ware RAID controllers in the 3ware BBU States and Their Effects on Cache Settings article.
Adaptec RAID Controllers
With Adaptec, the battery state can also be queried. For this, the following options are available:
- Request through the Adaptec CLI,
arcconf - Request through the Adaptec Storage Manager (ASM)
- Request through the RAID controller&#;s BIOS
As long as the battery capacity can retain the cache content for at least 24 hours during a power failure, the RAID controller&#;s cache will remain in write-back mode (thus, active). At lower capacity levels, the cache will be placed in write-through mode (to the extent that the cache has not been permanently (meaning without regard for the BBU state) reset to write-back mode).
Ideal State Status
Requesting Status through the Adaptec CLI
The final lines (in the section below controller battery information) are relevant in the report from arcconf GETCONFIG 1 AD.
linux-k3oa:~ # /usr/StorMan/arcconf GETCONFIG 1 AD Controllers found: 1 ---------------------------------------------------------------------- Controller information ---------------------------------------------------------------------- Controller Status : Optimal Channel description : SAS/SATA Controller Model : Adaptec Controller Serial Number : 8CF Physical Slot : 6 Temperature : 70 C/ 158 F (Normal) Installed memory : 512 MB Copyback : Disabled Background consistency check : Disabled Automatic Failover : Enabled Global task priority : High Performance Mode : Default/Dynamic Stayawake period : Disabled Spinup limit internal drives : 0 Spinup limit external drives : 0 Defunct disk drive count : 0 Logical devices/Failed/Degraded : 2/0/0 -------------------------------------------------------- Controller Version Information -------------------------------------------------------- BIOS : 5.2-0 () Firmware : 5.2-0 () Driver : 1.1-5 () Boot Flash : 5.2-0 () -------------------------------------------------------- Controller Battery Information -------------------------------------------------------- Status : Optimal Over temperature : No Capacity remaining : 99 percent Time remaining (at current draw) : 3 days, 7 hours, 16 minutes Command completed successfully. linux-k3oa:~ #
Request through the Adaptec Storage Manager (ASM)
Request through the RAID controller&#;s BIOS
Charging State Status
In comparison with the system above, the time remaining is less, because the battery will not be completely charged.
linux-kfqr:~ # /usr/StorMan/arcconf GETCONFIG 1 AD Controllers found: 1 ---------------------------------------------------------------------- Controller information ---------------------------------------------------------------------- Controller Status : Optimal Channel description : SAS/SATA Controller Model : Adaptec Controller Serial Number : 8CC9 Physical Slot : 6 Temperature : 71 C/ 159 F (Normal) Installed memory : 512 MB Copyback : Disabled Background consistency check : Disabled Automatic Failover : Enabled Global task priority : High Performance Mode : Default/Dynamic Stayawake period : Disabled Spinup limit internal drives : 0 Spinup limit external drives : 0 Defunct disk drive count : 0 Logical devices/Failed/Degraded : 2/0/0 -------------------------------------------------------- Controller Version Information -------------------------------------------------------- BIOS : 5.2-0 () Firmware : 5.2-0 () Driver : 1.1-5 () Boot Flash : 5.2-0 () -------------------------------------------------------- Controller Battery Information -------------------------------------------------------- Status : Charging Over temperature : No Capacity remaining : 73 percent Time remaining (at current draw) : 2 days, 10 hours, 57 minutes Command completed successfully. linux-kfqr:~ #
Other Status States
Additional potential status states include:
- Not Installed
- Failed
Areca RAID Controllers
Areca also offers the ability to request the state through the CLI.
[root@testserver ~]# ./cli64 hw info Physical Hardware Information The Hardware Monitor Information =========================================== Fan#1 Speed (RPM) : Battery Status : 100% HDD #1 Temp. : 0 HDD #2 Temp. : 0 HDD #3 Temp. : 0 HDD #4 Temp. : 0 =========================================== GuiErrMsg<0x00>: Success. [root@testserver ~]#
Areca describes the following approach to checking the proper functionality of the BBM in their documentation[2] (however, we recommend this approach only for test systems. For production system, we really recommend replacing the battery in case of doubt).
- Write a large file, 5 gigabytes for example
- Once the write process has completed, pull the plug immediately.
- Check the BBM status. It should beep every couple of seconds.
- Re-start the system and open the controller&#;s BIOS using the Tab or F6 keys.
- Check the controller&#;s event log from the controller&#;s BIOS. An entry indicated controller boot up with power recovered should appear in the log.
As noted above, we recommend against this method of testing for production systems.
References
Author: Werner Fischer
Werner Fischer, working in the Knowledge Transfer team at Thomas-Krenn, completed his studies of Computer and Media Security at FH Hagenberg in Austria. He is a regular speaker at many conferences like LinuxTag, OSMC, OSDC, LinuxCon, and author for various IT magazines. In his spare time he enjoys playing the piano and training for a good result at the annual Linz marathon relay.
If you are looking for more details, kindly visit NEW AND USED BBU.
Comments
0