Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
?
EE Times-Asia > T&M
?
?
T&M??

Minimising small cell manufacturing cost

Posted: 09 Dec 2014 ?? ?Print Version ?Bookmark and Share

Keywords:small cell? Multi-DUT testing? PXI? base station? RF verification?

The majority of test plans for base stations will execute each measurement sequentially C performing the entire suite of test steps on a single device before moving on to test the next unit. The problem with this approach is that RF test equipment is used only a fraction of the time to do calibration as well as transmitter and receiver tests. Depending on the complexity of the product and the test plan, RF measurements typically take between 30 and 50 percent of the time; the other 50 to 70 percent the RF equipment remains idle (figure 3).

For large base station equipment that is capable of spanning macro cells, poor test equipment utilization might be acceptable: Such products are made in moderate volumes and typically sell for a lot more than a small cell base station. Small cell base stations more resemble a consumer-grade product in that they are made in larger quantities and come at a lower price than macro equipment. Multi-DUT testing is a cost-efficient approach used by handset manufacturers for some time now. The same technique holds substantial benefits for small cell testing as well.

Multi-DUT testing
Multi-DUT testing (also known as "multi-site") is an advanced test procedure that has the explicit goal of maximizing the utilization of the more valuable test assets such as RF vector signal analyzers. Implementing a multi-DUT test plan requires test engineers to reorganize their test sets and procedures such that they can pipeline the DUTs through the individual test phases (figure 4). From these modifications, they can reap tremendous benefits in utilization of the instrument and, ultimately, in the cost of test.

 Small cells

Figure 4: Parallel testing and auto-scheduling reduce test time and, thus, increase test throughput.

There are several questions one may ask in this process: How many devices should be tested in parallel? How must a test be structured for efficient pipelining of the individual phases? What about software and processing requirements? What is a good switching concept to route all the relevant signals from the multiple DUTs to the test equipment? Let us address each of these questions in a bit more detail.

How many DUTs?
Choosing the ideal number of devices to test in parallel is depends upon the time allocation of the current test plan. As an example, consider a traditional configuration for testing a single device at a time and where the RF instrument is active half of the time. Then, ideally, one can use this instrument during its idle time to test another device. This way, things like the first DUT booting can happen whilst the second device is measured and vice versa. Typical setups handle between two and ten devices. The exact number and how much more test throughput one can achieve may only be evident after careful inspection of the test procedures. For example, one should identify bottlenecks in the setup and software in terms of data bandwidth and the possibility of parallelizing individual test steps. Let us consider this next.

Writing and running multi-DUT tests
In order to efficiently pipeline a manufacturing test plan, one must carefully examine dependencies between individual steps that may use the same instrument. For example, the test procedure may use a vector signal analyzer for calibration as well as for transmitter testing. Then, if the test executive software performs transmitter tests on the first DUT, it must delay calibration procedures for a second DUT until the tests on the first device conclude. Modern test executives such as TestStand can handle such dependencies but rely on test designers to modularize their test code appropriately. The basic structure should be along the broad general test phases identified earlier: DUT loading and start-up, calibration, and RF verification. Within each phase, the designer should break up the code further to identify all instrument calls. Some examples are the steps of signal generation, capturing RF data on an analyzer instrument and subsequent processing on a computation unit. Structured accordingly, the test code consists of several sections that can run in parallel and several sections for which execution C that is, access to the measurement instrument C must be scheduled in sequential order.

?First Page?Previous Page 1???2???3???4?Next Page?Last Page



Article Comments - Minimising small cell manufacturing ...
Comments:??
*? You can enter [0] more charecters.
*Verify code:
?
?
Webinars

Seminars

Visit Asia Webinars to learn about the latest in technology and get practical design tips.

?
?
Back to Top