RF Front-End Design Challenge
Multi-band and multi-radio support is a necessity for nearly all cellular mobiles. New spectrum allocations for global wireless communications are being defined, or redefined, by the relevant authorities. Historically, spectrum allocations have been country-specific, and thus globally inconsistent, since they are typically controlled by local governments. Unfortunately, spectrum alignment has been driven by industry economies of scale, rather than foresight and global cooperation among governing bodies. Without spectrum alignment, device standardization is extremely difficult to achieve. With the wireless communications industry a relative newcomer to spectrum allocation, the disparate frequency bands will continue to follow localized needs rather than broader, global opportunities for optimization.
As a result, carriers require support for their selected frequency bands, and some selected roaming bands, while the terminal suppliers prefer to offer a minimum number of different terminal designs in order to maximize volumes and efficiencies. The results in the need to increase the number of bands supported. An additional outcome of this is that the band usage is not necessary Radio Access Technology (RAT) dependent, but it does require that radios need to be able to identify the various RATs used, and to act accordingly.
Carriers also expect that radio performance will constantly be improved, despite these ever-increasing demands. Apart from higher throughput there are demands for improvements in other areas, such as better sensitivity to increase cell coverage and improved interference rejection for better connection quality. Combining multi-RAT and multi–band with ever-increased performance is a serious design challenge. But because it is extremely difficult to provide improvements in all of these areas with existing solutions, radio suppliers have typically resorted to less integrated solutions. Thus this inherent tendency results in less integration, rather than more.
The mobile device industry also is addressing the need for increased performance and functionality by introducing new types of components for use in RF front-ends. Many of these new components represent new technologies, and which may increase the component count in the RF front-end, even though these components support numerous functions. However, these components still require dedicated parallel signals paths, with a commensurate need to control all of these paths separately. For example a power amplifier (PA) module may incorporate multiple PAs and signal chains, and thus may require increased control capabilities.
Another factor driving performance improvements is the need to correct for the imperfections caused by analog components. Previous approaches pre-distorted the signal, but there is a trend towards more complex solutions, incorporating closed loops and real-time tuning. Examples are closed loop polar transmitters and antenna tuners, which introduce completely new components and functions into the RF front-end.
It is evident that the increasing complexity to control the RF front-end will require an expanded intelligence level in order to manage numerous signal chains and increased complexities. The RFFE control bus has been developed to meet these challenges.
Figure 1: Example Architecture for an RFFE Bus-Controlled Front-End
The MIPI Alliance RFFE Specification is designed to be the channel for time-critical information within the RF front end while meeting requirements typical to mobile device applications. One of the major objectives of MIPI RFFE specification is to provide device compatibility ensuring device interoperability devices from any vendor. With the current myriad of arrangements for RF front-end control, it is extremely difficult for systems designers to select the appropriate devices and to utilize a common control scheme. And for device providers, the ability to support all the desired control schemes implies producing either a variety of devices, or a complex multi-interface product.
Another objective of the RFFE specification is to satisfy a demand for low pin count, both at the master (RFIC), and in particular for the slave devices, thus saving costly I/Os at the package level and area for traces on the PCB by using a bus system to which all devices are connected. Real time programming and high-speed, low latency command transfer are an imperative for timing accurate control and the provisioning of all devices in any high dynamic use case. It is also important to provide functions for the cases where acquisition of status from front-end devices is required.
Because RF front-end devices may vary both with regards to their indicated needs, as well as their ability to support control complexity, it was important to provide a range of optional features within RFFE. These features allow for compact silicon implementations ranging from simple devices supporting only a minimum of commands and functionality to more complex devices with efficient command sequences. The specification also supports scalability and power-down modes as an enabler for achieving minimum current consumption in systems. This was another major objective in the development of the RFFE Specification.
The MIPI RFFE specification is designed to replace existing control solutions, such as SPI interfaces (a three-wire bus with proprietary vendor -specific protocol layer), which suffer from a lack of standardization due to the variety of telegram structures despite the commonality afforded by similar signal structure. Dedicated analog or digital control lines also lack common definition, and consume a large number of pins and PCB area for the traces since they typically do not provide for multi-device support, and so must be replicated for each new device. Other potential candidates, such as I2C, have never been an acceptable solution in sensitive wireless applications, since they lack some of the fundamental features desired.