Mobile phone radios have developed into highly complex, multi-band and multi-standard designs that often have multiple RF signal chains. Every component in the RF signal chain has to be in the desired configuration at any given time, or the system will fail. Therefore, accurate timing, triggers and speed are all necessary.
The majority of today’s methods are proprietary or de-facto standards that are not utilized industry-wide. Control of front-end components may be done in many different ways; however, none offer the scalability, economy and compatibility of MIPI RFFE. The RFFE Specification was developed to address current and future market needs.
Complete specifications are available to MIPI members only. For more information on joining MIPI, please go to Join MIPI.
The MIPI Alliance Specification for RF Front-End Control Interface (RFFE) was developed to offer a common and widespread method for controlling RF front-end devices. There are a variety of front-end devices, including Power Amplifiers (PA), Low-Noise Amplifiers (LNA), filters, switches, power management modules, antenna tuners and sensors. These functions may be located either in separate devices or integrated into a single device, depending on the application.
RFFE should not be confused with the MIPI Alliance DigRFSM v4 and 3G Specifications. DigRFSM specifies the interface between the baseband and RF ICs whereas RFFE is mainly an RF front-end-dedicated control interface. The key driver for DigRFSM is to offer a very high-speed interface for carrying digital RF IQ data and RF control information. RFFE, on the other hand, is a pure control interface that does not target the signal paths associated with the front-end devices being controlled. DigRFSM provides only a point-to-point configuration, and thus requires multiple instantiations for complex configurations. In contrast to DigRFSM, RFFE supports point-to-multipoint connectivity for control of the RF front-end.
The trend in mobile radio communications is towards complex multi-radio systems comprised of several parallel transceivers. This implies a leap in complexity of the RF front-end design. Thus, the RFFE bus must be able to operate efficiently in configurations from the simplest one Master and one Slave configuration to, potentially, multi-Master configurations with tens of Slaves. The emphasis of the current version of the specification is on configurations with only one Master, while also providing for future expansion to multiple Master configurations. Future versions of this specification may allow more complex configurations that provide for multiple Masters in addition to multiple Slaves.
RF front-end modules are sometimes developed in process technologies unlike bulk digital CMOS. Diverse technology choices are necessary to meet the functional and performance requirements of the application. The downside is that suitability for digital design might be quite low. In some of these technologies the implementation of digital logic might be costly, so a prerequisite of the RFFE design was to offer options to reduce Slave control complexity to a minimum (approximately 300 to 500 gates). Simplicity has been a core driver in RFFE development. The RFFE Specification, positioned at the low complexity end of all interfaces, is optimized for Master and Slave implementation simplicity without sacrificing a broad set of features.
One challenge for RFFE is presented by the need in many radio applications for time-accurate control. This is addressed in RFFE by utilizing a relatively high bus clock frequency of 26 MHz and by the introduction of time-accurate triggering mechanisms to allow control of timing-critical functions in multiple devices. This is predicated on the expectation that a simple Slave lacks the required timing accuracy, and thus is command driven.
The scope of the MIPI Alliance Specification for RF Front-End Control Interface (RFFE) is to specify the control interface for RF front-end devices. Analog signal paths required between front-end devices and other elements that control and utilize the devices, are outside the scope of this document.
A voltage reference is introduced as part of the control interface. The implementation of this voltage source is not specified, although a set of electrical characteristics are defined. This document also defines interface-specific procedures, and provides alternative means to perform certain actions. Implementers may determine which optional procedures and alternative means are supported by a device. Since a Master implementation supports all options, the functional implementation choices are intended primarily for Slave implementations.
RFFE provides a low-complexity solution to meet the cost and performance targets of RF front-end components. It offers extensibility from simple configurations with one Slave on a single bus, all the way to complex configurations with many Slaves on a single bus, or distributed on multiple buses. This eases both the RF and front-end module design by requiring a mobile terminal to support only a single control interface. Ideally, this leads to a broader range of control-compatible components, and to larger markets for front-end devices.
The MIPI Alliance Application Note for RF Front-End Control Interface v1.10 is a companion document to the actual RFFE Specification. This document defines and explains issues that are informative or implementation-related and thus excluded from the RFFE Specification. Detailed information is provided in the RFFE Application Note for additional RFFE features, FAQs and hints to solve issues left to the implementer.
The RFFE Protocol Implementation Conformance Statement (PICS) for MIPI Alliance Specification for RF Front-End Control Interface v1.10 is an updated document asset for implementers of RFFE. The RFFE PICS is not a specification–rather, it supports the RFFE Specification. A PICS can be used for a variety of purposes by various parties, including as a conformance checklist by the implementer, or as a detailed indication of the implementation's capabilities.
|MIPI at IWPC June 2011 (Wietfeldt; Carlson) final.pdf||318.48 KB|