Case 5:16-cv-00179-RWS Document 292-31 Filed 08/28/18 Page 1 of 9 PageID #: 19141
`Case 5:16-cv-00179—RWS Document 292-31 Filed 08/28/18 Page 1 of 9 PageID #: 19141
`
`EXHIBIT 30
`
`EXHIBIT 30
`
`

`

`Case 5:16-cv-00179-RWS Document 292-31 Filed 08/28/18 Page 2 of 9 PageID #: 19142
`Case 5:16-cv-00179—RWS Document 292-31 Filed 08/28/18 Page 2 of 9 PageID #: 19142
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`EXHIBIT 10
`
`EXHIBIT 10
`
`
`Maxell v. ZTE
`
`5: 16-cv-00179-RWS
`
`DX-0260
`
`ZTE Exhibit
`
`

`

`Case 5:16-cv-00179-RWS Document 292-31 Filed 08/28/18 Page 3 of 9 PageID #: 19143
`
`Version 1.10 26-Jul-2011
`
`MIPI Alliance Specification for RFFE
`
`MIPI® Alliance Specification for
`RF Front-End Control Interface
`
`Version 1.10 – 26 July 2011
`MIPI Board Approved 2-Nov-2011
`
`Further technical changes to this document are expected as work continues in the RF Front-End Control
`Working Group
`
`Copyright © 2009-2011 MIPI Alliance, Inc. All rights reserved.
`MIPI Alliance Member Confidential
`
`

`

`Case 5:16-cv-00179-RWS Document 292-31 Filed 08/28/18 Page 4 of 9 PageID #: 19144
`
`Version 1.10 26-Jul-2011
`
`MIPI Alliance Specification for RFFE
`
`NOTICE OF DISCLAIMER
`The material contained herein is not a license, either expressly or impliedly, to any IPR owned or controlled
`by any of the authors or developers of this material or MIPI®. The material contained herein is provided on
`an “AS IS” basis and to the maximum extent permitted by applicable law, this material is provided AS IS
`AND WITH ALL FAULTS, and the authors and developers of this material and MIPI hereby disclaim all
`other warranties and conditions, either express, implied or statutory, including, but not limited to, any (if
`any) implied warranties, duties or conditions of merchantability, of fitness for a particular purpose, of
`accuracy or completeness of responses, of results, of workmanlike effort, of lack of viruses, and of lack of
`negligence.
`All materials contained herein are protected by copyright laws, and may not be reproduced, republished,
`distributed, transmitted, displayed, broadcast or otherwise exploited in any manner without the express prior
`written permission of MIPI Alliance. MIPI, MIPI Alliance and the dotted rainbow arch and all related
`trademarks, tradenames, and other intellectual property are the exclusive property of MIPI Alliance and
`cannot be used without its express prior written permission.
`ALSO, THERE IS NO WARRANTY OF CONDITION OF TITLE, QUIET ENJOYMENT, QUIET
`POSSESSION, CORRESPONDENCE TO DESCRIPTION OR NON-INFRINGEMENT WITH REGARD
`TO THIS MATERIAL OR THE CONTENTS OF THIS DOCUMENT. IN NO EVENT WILL ANY
`AUTHOR OR DEVELOPER OF THIS MATERIAL OR THE CONTENTS OF THIS DOCUMENT OR
`MIPI BE LIABLE TO ANY OTHER PARTY FOR THE COST OF PROCURING SUBSTITUTE GOODS
`OR SERVICES, LOST PROFITS, LOSS OF USE, LOSS OF DATA, OR ANY INCIDENTAL,
`CONSEQUENTIAL, DIRECT, INDIRECT, OR SPECIAL DAMAGES WHETHER UNDER
`CONTRACT, TORT, WARRANTY, OR OTHERWISE, ARISING IN ANY WAY OUT OF THIS OR ANY
`OTHER AGREEMENT, SPECIFICATION OR DOCUMENT RELATING TO THIS MATERIAL,
`WHETHER OR NOT SUCH PARTY HAD ADVANCE NOTICE OF THE POSSIBILITY OF SUCH
`DAMAGES.
`Without limiting the generality of this Disclaimer stated above, the user of the contents of this Document is
`further notified that MIPI: (a) does not evaluate, test or verify the accuracy, soundness or credibility of the
`contents of this Document; (b) does not monitor or enforce compliance with the contents of this Document;
`and (c) does not certify, test, or in any manner investigate products or services or any claims of compliance
`with the contents of this Document. The use or implementation of the contents of this Document may
`involve or require the use of intellectual property rights (“IPR”) including (but not limited to) patents, patent
`applications, or copyrights owned by one or more parties, whether or not Members of MIPI. MIPI does not
`make any search or investigation for IPR, nor does MIPI require or request the disclosure of any IPR or
`claims of IPR as respects the contents of this Document or otherwise.
`Questions pertaining to this document, or the terms or conditions of its provision, should be addressed to:
`MIPI Alliance, Inc.
`c/o IEEE-ISTO
`445 Hoes Lane
`Piscataway, NJ 08854
`Attn: Board Secretary
`
`Copyright © 2009-2011 MIPI Alliance, Inc. All rights reserved.
`MIPI Alliance Member Confidential
`ii
`
`

`

`Case 5:16-cv-00179-RWS Document 292-31 Filed 08/28/18 Page 5 of 9 PageID #: 19145
`
`Version 1.10 26-Jul-2011
`
`MIPI Alliance Specification for RFFE
`
`Architecture and Operations Overview
`4
`85 This section is intended to convey an overview of the architecture and operational details of the RFFE
`interface.
`
`Overview
`4.1
`86 RFFE is a two-wire, serial interface intended to be used to connect Radio Frequency ICs (RFIC) of a mobile
`terminal to their related Front-End Modules (FEM). The RFFE interface enables systems to efficiently
`control various FEMs in next generation mobile terminals with increased complexity of performance
`supporting multi-mode, multi-band and multiple antennas, all with a minimum number of wires and pins
`using a single RFFE bus. It is designed to support existing 3GPP standards such as LTE, EGPRS, UMTS,
`HSPA, etc. and also other, non-3GPP air interfaces. The RFFE interface is based on MIPI Alliance
`Specification for System Power Management Interface (SPMI) [MIPI03]. The RFFE interface is intended to
`be efficient, flexible, and extensible, accommodating many variations in the overlying system design, while
`providing interoperability at the interface level between compliant RFICs and FEMs. The ability to design
`one common control interface which may be reused for all of these modules helps reduce front-end
`complexity, and hence speed up the time-to-market for these terminals.
`87 Within the mobile terminal, the RFIC is the Master and the FEMs are the Slaves on the RFFE bus. Command
`Sequences on the bus may only be initiated by the Master. A Slave shall not initiate Command Sequences on
`the bus. This specification defines the operating states, the Command Sequence set, the physical interface,
`and the protocol for data communication between RFFE devices on an RFFE bus to insure the compatibility
`of control and data transfers. The RFFE Command Sequence set includes Slave addressing, control of the
`Slave operating state, register read from and register write to Slaves, as well as Command Sequences
`supporting the use of Device Descriptor Block [MIPI05].
`88 The key pillars of the RFFE design include the following considerations:
`89 • Minimize the wiring effort in the front-end of a mobile terminal
`90 • Minimize pin count
`91 •
`Ease and optimize control flow
`92 •
`Ensure minimal EMI contributions due to RFFE bus
`93 • Minimize complexity for the Slave
`94 •
`Add flexibility and scalability, allowing use of multiple receivers and transmitters simultaneously
`95 The basic configuration of the RFFE interface and its bus structure are shown in Figure 1. As RFFE is based
`on the SPMI interface it shall have two signals, one serial bidirectional data signal (SDATA) and one clock
`signal (SCLK) controlled by the Master. Any additional signals present on an RFFE device shall not change
`the behavior of the RFFE interface protocol or prevent the operation of the RFFE bus described in this
`specification.
`
`Copyright © 2009-2011 MIPI Alliance, Inc. All rights reserved.
`MIPI Alliance Member Confidential
`19
`
`

`

`Case 5:16-cv-00179-RWS Document 292-31 Filed 08/28/18 Page 6 of 9 PageID #: 19146
`
`Version 1.10 26-Jul-2011
`
`MIPI Alliance Specification for RFFE
`
`RFIC
`
`RFFE
`Master
`Interface
`
`SCLK
`
`SDATA
`
`FEM 1
`
`RFFE
`Slave
`Interface
`
`FEM 2
`
`RFFE
`Slave
`Interface
`
`FEM n
`
`RFFE
`Slave
`Interface
`
`Figure 1 RFFE Interface and Bus Structure
`
`4.1.1
`
`Topology
`
`Basic
`4.1.1.1
`96 Figure 2 shows a Basic Configuration of an RFFE bus implementation based on a minimal topology
`consisting of a RFIC with one RX and one TX path connected to one antenna. The main characteristic of the
`Basic Configuration is that there is only one RFFE bus where all front-end components are connected. The
`RFIC is the Master on the RFFE bus and all front-end components act as Slaves. The TX signal path starts at
`the RFIC and may comprise various outputs for different radio standards or frequency bands. Depending on
`the detailed architecture these analog outputs may be connected to a set of different gain or power amplifiers,
`which usually need to be controlled. These gain or power amplifiers may be separate for each output or may
`also be shared for several outputs. Following the TX direction towards the antenna there are bandlimiting
`filters, which may be configurable for different scenarios, the antenna switch used to select RX and TX
`directions as well as different bands, and finally the antenna tuning-module. In addition, these components
`may be accompanied by various sensors for temperature, power, voltage, etc. and adjustable power supplies
`for the front-end components like LDOs or DC/DC converters for PAs.
`97 Complexity in terms of control functionality of these various front-end component types may be different as
`well as process technology and manufacturing requirements of such components. Therefore, the RFFE bus
`needs to cover a wide range of configurations and application complexity while simultaneously enabling a
`small implementation in low density process technologies. The various front-end components also may have
`very different requirements regarding real time control performance, number of parameters to be controlled,
`amount and frequency of data to be read back, etc.
`98 Furthermore, depending on the topology of the system and the use cases to be supported several front-end
`components may need to receive control information at almost the same time. The absolute number of front-
`
`Copyright © 2009-2011 MIPI Alliance, Inc. All rights reserved.
`MIPI Alliance Member Confidential
`20
`
`

`

`Case 5:16-cv-00179-RWS Document 292-31 Filed 08/28/18 Page 7 of 9 PageID #: 19147
`
`Version 1.10 26-Jul-2011
`
`MIPI Alliance Specification for RFFE
`
`end components in the overall system is a very important boundary condition since each component needs to
`be individually addressable.
`
`RFIC
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`Sensors
`
`Signal Path
`
`RFFE Bus
`
`Figure 2 Basic Configuration
`
`Diversity
`4.1.1.2
`99 Figure 3 shows a topology supporting receive diversity (RxDiv). The primary difference from the basic
`configuration shown in Figure 2 is the additional receive path with a separate antenna connected to one RFIC.
`The additional front-end components are connected to the same RFFE bus. This scenario might have
`increased requirements regarding bandwidth and addressable components for the RFFE bus.
`
`Copyright © 2009-2011 MIPI Alliance, Inc. All rights reserved.
`MIPI Alliance Member Confidential
`21
`
`

`

`Case 5:16-cv-00179-RWS Document 292-31 Filed 08/28/18 Page 8 of 9 PageID #: 19148
`
`Version 1.10 26-Jul-2011
`
`MIPI Alliance Specification for RFFE
`
`RFIC
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`Sensors
`
`Signal Path
`
`RFFE Bus
`
`Figure 3 Diversity Configuration
`
`MIMO
`4.1.1.3
`100 The MIMO configuration shown in Figure 4, as compared to the diversity configuration shown in Figure 3,
`represents a further step in terms of complexity for the RFFE bus. Now there are two complete and
`independent RX and two complete and independent TX paths, which allows MIMO operation. Therefore, the
`number of front-end components increases again. Higher traffic on the RFFE bus is expected and a higher
`number of front-end components need to be addressed.
`
`Copyright © 2009-2011 MIPI Alliance, Inc. All rights reserved.
`MIPI Alliance Member Confidential
`22
`
`

`

`Case 5:16-cv-00179-RWS Document 292-31 Filed 08/28/18 Page 9 of 9 PageID #: 19149
`
`Version 1.10 26-Jul-2011
`
`MIPI Alliance Specification for RFFE
`
`RFIC
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`Sensors
`
`Signal Path
`
`RFFE Bus
`
`Figure 4 MIMO Configuration
`
`Dual-Bus Basic
`4.1.1.4
`101 Figure 5 shows a topology employing two RFFE busses for receive and transmit front-end devices. The
`primary difference to the topology in the basic configuration shown in Figure 2 is that there are two RFFE
`busses connected to one RFIC. This configuration supports a higher number of front-end devices and keeps
`the capacitive load on a single bus low. The dual bus topology also allows reduction of crosstalk from the TX
`
`Copyright © 2009-2011 MIPI Alliance, Inc. All rights reserved.
`MIPI Alliance Member Confidential
`23
`
`