1. Can you provide a brief overview of Rohde & Schwarz? What products/services do you offer?

On the T&M side, Rohde & Schwarz provides test solutions for all RF and data center test requirements, including the RF front-end for mobile phones. We also provide a lot of test and measurement equipment for evolving Beyond 5G technologies, RAN infrastructure, such as O-RAN, and also for other wireless technologies, including WiFi, Bluetooth or UWB .  Moreover, we offer dedicated products and solutions for Automotive and Aerospace & Defense applications such as a radar target simulator for automotive radars.

2. Why did Rohde & Schwarz join the OpenRF Association? What are the main benefits and advantages for member companies?

The OpenRF initiative is interesting, and an important push forward. Joining OpenRF provides companies with many benefits and advantages. For us, it’s understanding the test requirements, and making sure our roadmap meets the requirements of our customers. OpenRF makes the process more streamlined and faster and helps us to support the overall ecosystem.

For OEMs who are also among our customers, it can be a challenge trying to integrate different RF front-end modules. OpenRF is trying to simplify everything. Standardization of front-end modules is a major benefit to them., as front-end manufacturers offer drop-in replacements and an ecosystem of products that are easily deployable for the device manufacturers.

3. What specific expertise does Rohde & Schwarz bring to the OpenRF Association? How does your company plan to participate?

We want to have a quick and easy test solution in order to be compliant with the standard, to support our customers on the RF front-end manufacturing side.

Rohde & Schwarz has a long track record in interoperability and certification testing for cellular technologies. We can leverage this expertise in our work for the Open RF Association. And we are not only a part of OpenRF, but other standardization efforts as well, so we have a deep understanding the different standardization processes. We plan to participate by actively joining various working groups and are active in the Compliance Working Group.

4. What do you see as OpenRF’s impact within the industry? What is the importance of an open 5G ecosystem of interoperable hardware and software across RF front-end and chipset platforms?

We see interoperability is the most important piece. The goal of standardization is to make it really easy for OEMs to choose from an ecosystem of best-in-class products and decide what fits best inside their environment rather than being limited as they are going down one particular path. Right now, if they switch to a product from to a different vendor, they have to essentially reinvent the wheel to ensure that new product fully integrates with their solution. Now, with OpenRF providing the standards, it makes everything much easier for them to have options that have been tested and that they know are interoperable.

The post Open RF Association Member Spotlight: Rohde & Schwarz appeared first on OpenRF.

With the introduction of 5G, there have been a lot of significant changes in the industry in terms of complexity and getting the products right. 5G use cases are very different now and the challenges have grown – from the vast amount of data used in 5G, to uplink streaming and operation in dense urban areas. 5G has also introduced a lot of new bands, like the C-band that’s operating at 3.5 gigahertz. While the standards and architectures are being established, real-world data on how phones perform in a growing number of use cases are needed.

In the mid-2000s, the industry began using a standard called the CDG curve, published by the CDMA Development Group, to better understand how much data and power an average user was consuming for a variety of different use cases. These curves were a probability distribution of the average user. We found that, in real-world environments, the average user doesn’t use max power for a variety of reasons, such as distance from the base station or how much data they were consuming.

The CDG curve played a vital role in helping the industry adapt to and ultimately thrive on the changes that came with 3G and 4G. Using this information, the industry was better able to reconfigure the front end, fundamentally changing the architecture of the amplifiers and the radio controls to optimize performance. The benefit of these probability curves helped improve operators’ OPEX as well as improved talk time for the end-user.

Unfortunately, there has never been a replication of the CDG curve for 5G. OpenRF believes a new study of 5G user’s power profiles can deliver the same type of value the original CDG curves supplied.

Last quarter, OpenRF released phase one of the user curve study to our members. We want to start the study and, over time, build upon the data as more members and operators are willing to share their information. The goal is to provide this power curve information to our members so they can optimize their devices for 5G just like they did for 4G.

If your company is interested in helping the OpenRF association and its members add to this power profile study and share real-world baseline transmitter performance, please contact us to learn more about how you can contribute data.

The post OpenRF Working Group Investigating 5G User Power Profiles to Improve Handset Battery Life appeared first on OpenRF.

1. Can you provide a brief overview of NI? What products/services do you offer?
NI is the leading test and measurement vendor for RF front-end validation and production testing. NI’s best-in-class RF performance with industry leading test time has helped leading RF Integrated Chip (RFIC) and RF front end vendors to achieve faster time-to-market and higher revenue growth.

2. Why did NI join the OpenRF Association? What are the main benefits and advantages for member companies?
Many of NI’s customers are also founding members of OpenRF. The mission of OpenRF is advancing open architecture at the chipset level to drive interoperability. This aligns with NI’s direction around validation and production to drive growth. The wireless communication industry has been going through big changes in the last few years. With vertical integration in the 5G ecosystem and using a different type of chipset, the demand is to be more open, interchangeable and interoperable, which all give the consumer more choices and options. All these are major challenges for the industry – how can we get to interoperability and power efficiency to benefit the end customer? OpenRF is trying to solve a critical piece of that by getting the individual vendors to work together.

The main benefits for member companies are the following:

• Faster time to market when using open standards that can interoperate across RFIC chipset to RFFE from different vendors.
• Streamlined qualification process with lower test cost to validate RFFE components with RFIC chipset
• For OEM phone makers, wider range of quality component selections that provide know functionality and interoperability

3. What specific expertise does NI bring to the OpenRF Association? How does your company plan to participate?
NI will participate in OpenRF at the compliance level. The goal of Working Group 5 is to provide compliance certification that allows interoperability of RF front end components and 5G chipsets. OpenRF compliance will provide self-certification test procedures to avoid time-consuming third-party certification lab process, especially for level-1 SW HAL API compliance.
The OpenRF Compliance Test Specification includes two levels: Level 1, targeted for mid-2022, involves software API, Hardware Abstraction Layer (HAL) and register mapping. Level 2, targeted for late 2022, goes beyond register mapping to include RF capability, performance levels, and it will do some of the 5G usage scenarios, RF front end, chipset and modem.

4. What do you see as OpenRF’s impact within the industry?
The wireless industry is at the crossroads of several key challenges, including vertical integration versus open standards and the challenges of a global semiconductor ecosystem. OpenRF provides a potential answer to break the vertical integration monopoly on the wireless chipset supply chain.

5. What is the importance of an open 5G ecosystem of interoperable hardware and software across RF front-end and chipset platforms?
OpenRF is very analogous to the Open RAN movement at the chipset level. There are a lot of open hardware and software vendors on the Open RAN infrastructure side. Competition enables innovation and enables the market, and the growing number of Open RAN vendors is opening up competition and lowering costs. But in an open ecosystem, interoperability is very important. By establishing standards and compliance testing, OpenRF is ensuring that its members are able to give better service, innovation and products to the end customer.

The post Open RF Association Member Spotlight: NI appeared first on OpenRF.

Working Group 2’s mission is to develop a common hardware abstraction layer – or HAL. What is the HAL and what are you doing to accomplish this?

Working Group 2 is working on establishing a standardized version of interoperable software interfaces that can be extended to any product and any future product. Our goal is to design the software so that it can be integrated pretty easily with minimal effort onto a platform. Our main deliverable is a re-usable/portable software interface to the lower layer driver. What that means is that anybody who uses this software package specific to a particular front-end device will be able to easily integrate it into the system.

From a chipset point of view, the process is fairly difficult as there is no standard. Front-end devices are very diverse and there’s no regular pattern that we can apply to easily integrate them. There are a lot of exceptions, and thus there are a lot of workarounds. With this particular working group charter, we are trying to standardize in the sense that all the functionalities are still there, but in a way that there is a regular pattern, a regular way of integrating it without losing the competitiveness of the front-end device itself.

Before we started working on the OpenRF specification, the front-end module vendors found it challenging to work around the different programming models of the different RFICs. So, what we are striving towards is for all the chipset vendors that are part of OpenRF, our programming model will provide an abstraction of the chipset so that when we develop the driver for one of our front-end modules, it is highly portable because of the programming model being standardized by Working Group 2.

From an industry point of view, what will a standardized HAL help accomplish?

The OEMs have their choices of putting whichever components they need to put on their SKU. For example, Japan, North America, Latin America, and the EU can contain very different sets of front-end devices. The problem is that without standardization, each one of them has its own unique characteristics. This means that the integration efforts (time and resources) required to put a product together is actually quite large and usually very complex, especially when it comes to customization. So, the need, at least from the chipset and the OEM point of view, is to lower the risk of making mistakes and also create a faster turnaround time to get the device all the way to where we can actually test and deploy it. The key benefit of the HAL is a standardization that allows faster deployment, and lower error rates without compromising all of the functionalities needed by each market.

From a front-end perspective, when we have the same front-end component for different chipsets, we have to develop different drivers. This means that front-end vendors have to consider the different programming models and interfaces provided by these chipsets. If you develop a driver for one chipset and it’s not in the current model you are developing a driver for, it is going to have to be replicated across all the chipsets that are used by the OEMs. It is a very repetitive process. The reusability portion of the HAL is actually quite significant in the sense that now this particular driver can be used by whomever uses this particular front-end device, and they will be able to reuse the software. For example, if it’s a mid-high band device, the driver can be used across all the SKUs or even across projects. This is quite a tremendous savings in terms of the efforts that need to be put into developing the product.

By striving to standardize this product programming model and also having this HAL as a deliverable, we can help reduce the driver development and integration time from a front-end perspective. The maintenance ability, integration effort reduction in errors, and portability are the driving factors for Working Group 2 right now.

Is this included in the Phase 1.0.0 specification or is this going to be included in a different version?

For the Phase 1.0.0 specification, we have been working to publish the initial architecture and set up the framework for source code and header files. We also are setting up the initial programming guide. Phase 1.0.0 is not really in a deployable state, however, because it is laying the groundwork, getting everybody to be on the same page, and recognizing all the potential benefits.

In future releases, we are working towards bringing the HAL into a deployable state. When we release the next phase of the specification, that release of the HAL will be in a deployable state in the sense that the front-end vendors can take the templates and develop drivers. They will be able to start working with chipsets to integrate with the new paradigm.

How will testing impact the HAL framework?

We are also planning a new unit and integration test suite on our expectation that once the HAL is in a deployable state, all the members of OpenRF will use the HAL programming model to develop drivers. Once they develop the drivers, the idea behind the unit and integration test suite is that they will be able to test the drivers before releasing them to the chipset reference design or OEMs. This will help increase the confidence level in the driver that is being delivered to the OEMs or the reference design projects.

The testing aspect is really important in the industry. For example, if you take the android or iOS frameworks there are device driver developers in those frameworks for cameras or sensors. Those frameworks have these kinds of test suites that allow new device drivers to be tested before being pushed into the cloud. There is the same need with the HAL. The HAL is a software framework, so it goes without saying that there has to be a test suite accompanying any activity that takes place in a software framework environment. These unit and integration tests are something very similar, but of course, the scope is very restricted in the sense that it is meant for the OEMs and reference design and then these will be exercised by the front-end module driver developers.

What’s next for the group after the release of the Phase 1.0.0 specification?

We are working with other OpenRF Working Groups to come up with a reference design – a mock front-end device. It basically goes through a process of how we define, then goes from a definition to how we actually implement the lower layer driver. When we exercise this whole process, we give the front-end and also the RFIC folks a visualization of how these codes are realized. So, this is one thing that we’re planning to be able to deliver next time. The goal is to base the mock front-end device on a well-designed reference design that’s very close to a real product and then they can take it as a baseline.

We are also looking at the unit test itself to save time when the front-end folks have a specific design that they need to realize. They also have to go through a process of unit testing and integration. We are looking at whether or not they need to actually go ahead and define their own unit and test process or whether we can actually do something to save them more time by providing a basic framework that they can build on.

In the near term, the focus of Working Group 2 will be centered around operation optimization and developing a unit & test integration suite. As the ecosystem grows, there will be many other things that come along that we will begin to address.

The post OpenRF Working Group 2 Overview: Developing a Hardware Abstraction Layer (HAL) appeared first on OpenRF.

As we approach 2022, I wanted to reflect on the past year, which has been a busy but successful one for the Open RF Association. Since our launch in October of 2020, we have made progress on our goal to create a 5G ecosystem of interoperable hardware and software across multi-mode radio frequency (RF) front-end and chipset platforms to improve time-to-market, improve supply chain, and reduce overall costs across the breadth of OEM consumer mobile products. I am proud to announce that we ended the year on a strong note with the release of our inaugural OpenRF specification! Read on for some highlights from the 2021 Year in Review.

1. 1. In December, we announced the release of the OpenRF Version 1.0.0 Specification. This specification provides the industry with a path to compliant RF front-end devices that are capable of seamless integration with 5G chipsets. It introduces the first OpenRF standardized register maps, OpenRF hardware abstraction layer (HAL) and an established hardware port naming convention. The release of our initial specification is the culmination of the efforts of our working groups since OpenRF’s launch in October 2020. Read the press release for details
   2. In January, we signed a liaison agreement with the MIPI Alliance. The MIPI Alliance is an international organization serving industries that develop mobile and mobile-influenced devices focused on the design and promotion of hardware and software interfaces that simplify the integration of components built into a device, from the antenna and modem to peripherals and the application processor. The agreement allows the two organizations to engage in joint collaborative projects relating to RF front-end architecture, design, and technology. As there is some crossover between OpenRF and the MIPI Alliance regarding register map templates, the agreement outlines a framework for discussion and collaboration that will benefit the industry. Read the press release to learn more.
   3. It was a big year for membership growth, as we welcomed six new member companies to the Open RF Association. NI (formerly National Instruments) is a leading developer of automated test and measurement systems that help engineers solve some of the world’s toughest challenges. NI chairs the OpenRF Compliance Working Group and will work with OpenRF to address the interoperability challenges facing the 5G ecosystem. Read the press release for details.
      MixComm is the leading mmWave Antennas to Algorithms™ company developing transformative solutions for emerging wireless applications and markets. Read MixComm’s press release regarding their membership.
      UNISOC is a leading global supplier of core chipsets for mobile communications and IoT, and brings its RF Integrated Circuit (RFIC) expertise to the association. Learn more in the press release. Other new Associate Members include Rohde & Schwarz, TMYTEK, and SmartDV Technologies.
   4. We hosted a Microwave Journal webinar: “An Introduction to OpenRF: A New Approach to 5G Multi-Mode RF Front-End Device Challenges” in September. The talk was presented by OpenRF Association President Kevin Schoenrock and Working Group 1: Register Map co-chair David Southcombe. Working Group 2: Software API co-chair Surya Pappu and Working Group 3: Hardware RF front end/RFIC co-chair Peter Bacon joined for Q&A. The webinar covered a variety of topics, including the OpenRF Phase 1.0.0 Specification, Working Group overviews, OpenRF’s unique approach to meeting 5G multi-mode RF front-end challenges, and the benefits of an open 5G ecosystem. We had a great turnout, and the webinar was an excellent opportunity for the industry to learn more about what we’re doing. If you weren’t able to attend, the talk is available to view on-demand on the Microwave Journal website.

Overall, 2021 was a great year for the Open RF Association, despite the challenges of the global pandemic and travel restrictions. We look forward to continuing our progress on the next phase of the OpenRF specification. If your company is interested in contributing to the OpenRF ecosystem or accessing the final specification, consider joining OpenRF as a general or associate member. You can learn more about the membership benefits on our website.

The post OpenRF in 2021: The Year in Review appeared first on OpenRF.

Just over one year ago, we established the Open RF Association to support 5G Original Equipment Manufacturers (OEMs) by creating an open and interoperable ecosystem between chipset and Radio Frequency Front End (RF front-end) vendors. OpenRF™ was formed to reduce the complexity and fragmentation of the 5G ecosystem and encourage collaboration between Radio Frequency Integrated Circuit (RFIC) and RF front-end vendors to support the ecosystem. Our goal was to meet the market’s growing demand for open interfaces, enabling RF front-end to scale across platforms.

Today, we’re proud to announce the release of the OpenRF Version 1.0.0 Specification. This is our first major specification release, and it provides a path for vendors to develop open, compliant RF front-end devices that interoperate seamlessly with 5G chipsets.

The OpenRF Version 1.0.0 Specification optimizes configurations, enabling interchangeable RF front-end to RFIC solutions. This improved supply chain across the breadth of consumer mobile products provides 5G wireless device OEMs with the maximum choice in RF front-end solutions, increasing innovation while lowering design risk, and leading to reduced time-to-market as more vendors are able to join the open ecosystem.

Version 1.0.0 Specification helps standardize several key functions to reduce complexity so that vendors can focus on the performance and KPIs that are important for innovation. Here are some of the key highlights:

• Open, interoperable, and optimized configurations enabling interchangeable RF front-end to RFIC solutions.
• OpenRF standardized register maps to establish a common language and register map configuration that will enable faster digital implementations and increased interface optimizations in future generations.
• An established hardware port naming convention.
• A hardware abstraction layer (HAL) architecture document and the initial implementation of the HAL framework with a programming guide.

Of course, the Version 1.0.0 Specification is only the beginning of our efforts. We still have a lot of good work ahead of us. The release of the specification opens the door to initial OpenRF products entering the market in late 2022, and we expect to see RF front-end components first, followed by the first RFICs leveraging some of the OpenRF requirements. We are excited to see the extent of innovation by companies building products based on the OpenRF standard.

Join OpenRF today and help shape the future of RF front-end / RFIC solutions

If you’re interested in contributing to the development of the OpenRF specification and the future of an open RF front-end ecosystem now is a perfect time and there are plenty of ways to get involved. OpenRF has five established working groups: Register Map, Software API, Hardware RF Front-End/RFIC, RF Power Management, and Compliance. Each working group has its own set of specific goals and tasks for each phased release to meet the overall organizational roadmap.

Joining the Open RF Association is easy and there are three different levels of membership: Strategic, General and Associate. Strategic members are part of the Board of Directors and can lead our working groups and receive voting rights and access to final specifications. General members can contribute to working groups and also get access to all the specifications. Associate Membership is meant for startups, industry-adjacent organizations, or public or government institutions that want to keep abreast of what’s going on in the industry. Visit the “Join” section of our website for additional details.

Visit our website for additional membership information and to download the membership application. You can also reach out to admin@members.openrf.com with any questions.

The post Announcing the OpenRF Version 1.0.0 Specification: The first step toward creating an open, interoperable ecosystem between 5G chipsets and RF front-end appeared first on OpenRF.

What are the goals and mission of Working Group 1? What are you working to accomplish?

The primary effort of Working Group 1 is to minimize the software customization front-end, which will reduce the time to market and reduce the R&D cost for the OEMs. OEMs won’t have to make adjustments just to get the common features to work between the different vendors. The register map is a template that defines where these features will go and what registers are going to control what feature. Establishing the register map in this way allows the software to be more compatible because the registry maps will be more predictable.

What is the need for an OpenRF Register Map?

There are register maps for products that are in the market today, and each vendor has a slightly different register map. As a result, OEMs have to navigate that and they have to provide software approaches, different software rights, and different numbers of rights to achieve the same response from these different vendor modules. That stems from the industry standard for the interface defines the required registers for the protocol control.

RF front-end defines what registers it needs to control the protocol, but leaves the module control registers to the user, and calls those “user-defined registers.” That’s the space where OpenRF is coming in — to define those “user-defined registers” in a structured template format. In today’s market, there’s not a lot of guidance and the guidance that does come is often late in the development cycle of these products, meaning RF vendors have to spin new wafers, which is both time and money, just to make the updates try to achieve a little bit more compatibility for a given OEM.

Within the OpenRF Register Map, is there a way for vendors to implement specific features for a particular OEM, or is everything defined by the Register Map?

The OpenRF register maps create device classes, and within each device class is a template. That template defines a list of functions and how we’re grouping those functions. There’s a set of registers defined for each of those functions, as well as registers to define differentiating features. So, if a vendor has something that’s unique to their part and is a key differentiator, there are areas of the register map that are allocated for control of those type of features. This provides a common structure and allows the balance between structure and differentiation. That type of approach is going to be present in the register maps, in the hardware extraction layer, and then the front-end modules as well.

 What are some other ways OpenRF is helping manage front-end complexity?

The approach has been to allow the one-time loading of supplier-specific software, sometimes called the static configuration. This would occur at power-up when the parts are first being turned on, and it allows for a large number of rights to be sent to each of the front-end modules if the supplier chooses to implement it that way. This approach allows for more differentiating features without putting a burden on the timing that actually has to go on within the slots or frames or symbols as you’re trying to control the complexity of this front-end.

 How does OpenRF determine which features are going to be included in the Register Map?

Working Group 1 is accommodating the latest industry features; these features are determined by our members. They have provided a lot of input via Working Groups 2 and 3. They are working with our members to identify certain approaches or features; members are saying, “This is what we’re seeing and this is what we want to work together to standardize.” And our member chipset vendors are saying, “These are the features we’re going to need; let’s identify how we want to control them.” So it’s truly a collaborative effort to work within the industry and identify the features.

As a result, we have a template that says if you have a feature, here’s where you control it within the register map. And if you have something that is unique toward that function, the template can show you where in the register map your allocated area is to control that. This minimizes the number of software frameworks across all the tiers of products, and it’s in Release 1.0.0 for the OEMs and manufacturers.

The post OpenRF Working Group 1 Overview: Defining a Register Map Framework appeared first on OpenRF.

The Open RF Association is dedicated to expanding the functional interoperability of hardware and software across RF front-end and chipset platforms. OpenRF is delivering an open framework that standardizes interfaces without limiting innovation. The initial OpenRF specification is on track for release later this year and provides a path to compliant RF front end devices that are capable of being seamlessly integrated across 5G chipsets.

The Introduction to OpenRF webinar covered a number of topics, including:

• The highlights of the upcoming OpenRF Phase 1.0.0 specification
• Overviews of the OpenRF working groups and their goals
• The organization’s unique approach to meeting 5G multi-mode RF front-end device challenges
• The benefits of an open ecosystem for 5G device OEMs, chipset vendors and RF integrated circuit/RF front-end vendors including faster time-to-market, lower cost, improved performance, and expanded supply chain

If you couldn’t make it to the live webinar, you can view the recording on demand on the Microwave Journal website.

The post View the Webinar On Demand: An Introduction to OpenRF: A New Approach to 5G Multi-Mode RF Front-End Device Challenges appeared first on OpenRF.

As Director of Corporate Strategy & Planning at Qorvo, Kevin drives the long-range business plans and strategic objectives for the Mobile division while aligning technology and investment initiatives across the corporation. Prior to this, he led the Product Marketing Team for the Mobile product portfolio. He earned his MSEE and MBA degrees from the University of South Florida.

We recently sat down with Kevin to discuss his goals as President of the Open RF Association and his vision for the future of an open, interoperable RF front-end and RF integrated circuit (RFIC) ecosystem.

How did you first become involved in the OpenRF Association? What are your immediate goals as president of the association? 

OpenRF came about as an organization through a combination of customer requests and open discussion with others in the industry. Many of us in the mobile industry were seeing increased consistent customer demand for this type of organization, and so through informal conversations we began to see others in the industry saw the same type of requests.

It started with asking, do we have enough critical mass of other companies with the same type of vision who want to join and invest in such an organization? Obviously, the answer was yes, so then the second step was trying to formulate a structure and organization of the consortium. The third step was getting the consortium off the ground, electing the officers, articulating the vision, and forming the working groups to define and execute the goals.

Once the board of directors was formed, we sat down and looked at it from a broad industry perspective of how the consortium can properly serve our industry, and then we created the working groups aligned to what we’re trying to deliver to the market. Those working groups work with our customers and our partners to create specifications. We plan to release our first specification later this month. Those are essentially the immediate goals along with continued recruitment and marketing efforts.

From a broader perspective, our goal remains to support the interests of 5G original equipment manufacturers (OEMS) by establishing and maintaining an open and interoperable ecosystem between chipsets and RF front-end. We are meeting the market’s demand for open interfaces and enabling RF front-end to scale across platforms.

What are some of the biggest industry challenges that led to the need for a new and open, interoperable 5G ecosystem standard across RF front-end and chipset platforms?

One of the biggest industry challenges that led to the need for a new standard was complexity. What we saw was that 5G was becoming very complex and there needed to be tighter collaboration between RFIC and RF front-end vendors to support the ecosystem.

The second was the need to emulate an industry reference design that would work across chipsets. There is a lack of standards between chipsets and the RF front-end, with the number of 5G chips coming, fragmentation in RF front-end requirements and architectures was preventing economies of scale to be realized across platforms by OEMs. This lack of standards along with greater complexity increases the cost, risk and time-to-market of wireless products, OpenRF is an attempt to solve these challenges.

5G is entrenched across not only smartphones but in other new market segments such as industry 4.0, IoT, and automotive. As it proliferates and there continues to be more evolution of the 5G standard, there will be additional players – both RFIC and RF front-end – who continue to innovate and deliver new solutions. Our goal is to position OpenRF as that interoperability standard that will enable competition across segments, not only just market segments but RFIC and RF front-end segments.

Last, as an open 5G ecosystem continues to grow, the industry needs to have a compliance program in place to test and validate. That’s our goal for 2022, to ensure that customers are receiving the interoperability benefits that OpenRF stands for. More importantly that our partners and members are enjoying the ease of use and common interoperability we are delivering and their customers are recognizing that.

Where do you see the industry evolving in the next three years, and how do you see OpenRF meeting industry needs?

Similar to 4G, the 5G standard will continue to evolve in capability while expanding across many more markets. This expected pace of change, coupled with complexity, is where OpenRF can support the industry. Creating standard register maps and interface requirements really helps not only the customers but all of the RFIC and RF front-end vendors. Standardization along with architectural planning prevents unexpected design requirements from impacting OEM development cycles.

As an organization, we want to improve time-to-market, reduce design risk, and lower R&D investments throughout the value chain as best as we can, as well as try to create some sort of greatest common denominator across platforms to scale in either features or interoperability that makes sense without impacting the ability to innovate. That is important with any standards body or organization – if we have advisors and partners, we can better understand our customers or our customers’ KPIs to ensure that what we’re doing in terms of standards and specifications is meeting their requests.

OpenRF will enable 5G cellular device OEMs to select compliant RF front-end devices to operate seamlessly with member 5G chipsets. This gives OEMs maximum choice in RF front-end solutions and provides lower development costs, reduced time-to-market and design risk, highest performance utilizing a platform for future innovations, and improved supply chain implemented across the breadth of OEM consumer mobile products. Really, we saw that between the RFIC vendors, the RF front-end vendors, and the OEM manufacturers, it’s a win-win-win.

What are the near-term goals for OpenRF? Can you talk about the Phase 1.0.0 specification and what it covers?

Less than one year from formation, the consortium is right on pace getting ready to release our first specification this summer. Phase 1.0.0 is our first specification release. What it delivers is, first and foremost, an introduction to the organization and what we’re going to do for the ecosystem. We’re creating a document that establishes our initial goals of interoperability and cohesiveness amongst RFIC and RF front-end members. We have a liaison agreement with the MIPI alliance, so we’re issuing our first OpenRF standardized register maps. That’s the first key building block for interoperability. All the front-end components have a common language and register map configuration that will enable configurability in future generations.

Phase 1.0.0 will also establish a hardware naming convention, which is important as you try to test or link certain register maps and compatibility with transceivers – you have to know what to name them.

It will also have our first hardware abstraction layer (HAL) architecture document including a programming guide. The HAL standardizes the software interface between RFIC and RF front-end by creating an RFIC and RF front-end agnostic software interface, enhancing the transceiver to RF front-end interface capability and flexibility. This allows for another way to cloak the specific hardware features of RF front-end and RFIC vendors to work at a higher level in the physical layer so you can do special functions and features between the RFIC and RF front-end. I like to look at it as we’re creating a future roadway between RFICs and RF front-ends to transport specific information any way you want without the need to tell everyone how you’re doing it. The goal of Phase 1.0.0 is to ensure interoperability, optimize configurations and standardize certain specifications enabling interchangeable RF front-end to RFIC solutions.

Our next major release, Phase 2.0.0, will take place sometime toward the end of the year, and we’ll add our first elements of compliance along with incremental additions to Phase 1.0.0 elements. We expect to have initial OpenRF products hit the market toward the middle of next year. They will be RF front-end components because they’re a little faster turn time, then toward the end of 2022, we’ll see our first RFICs leveraging some of the OpenRF requirements, as they have a longer development cycle.

Why should companies join the OpenRF Association? What does involvement look like, especially in working groups?

We started with seven members, and we’ve almost doubled in membership since launch and are signing up key strategic advisors and initiating plans for industry benchmark studies. I think if your company is going to create a 5G device, whether it’s a smartphone or the internet of things, OpenRF is going to provide that framework from a hardware perspective, along with the software elements, to get the best solution in terms of time-to-market, cost competitiveness and performance. We’re trying to create the kind of standard that everyone can benefit from, not only from a hardware perspective but the things we’re doing within the software to evolve the standard and provide enhancements needed to meet the ecosystem demands. It’ll give OEMs the best amount of choices to deliver their products with the most flexibility in terms of optimizing or configuring what they’re trying to deliver.

There are three different levels of membership: Strategic, General and Affiliate. Strategic Members are part of the Board of Directors and can lead our working groups and receive voting rights and access to final specifications. General Members can contribute to working groups and get access to all the specifications. More importantly, they can engage and shape the future of the association through involvement in working groups. Affiliate Membership is maybe for startups that don’t have a lot of resources but need to know what’s going on, industry-adjacent organizations that are trying to learn, or public or government institutions.

Membership is open to any company involved in the manufacturing of smartphone chipsets, RF front-end products, OEM vendors or any related industry companies, and you can learn about the benefits and download the membership application on our website. OpenRF is committed to expanding functional hardware and software interoperability for RF front-end and chipset platforms, so if a company is interested in contributing to the development of an open framework for any 5G baseband, we would welcome their participation.

We have five working groups: Register Map, Software_API, Hardware RF front-end and RFIC, RF_Power Management IC (PMIC), and Compliance. Each of those working groups is led by a chair or co-chairs, and they have very specific goals and tasks to achieve for each phased release to meet the overall consortia roadmap.

Another thing we’re trying to do as an organization is working to get OEMs and operators to be strategic advisors. We’re just starting to have initial success in those two areas, so it’s a way to get a deeper reach into the requirements of our customers to make sure what we’re doing as an organization is meeting their needs. So, if you are an operator or OEM and want to contribute, please reach out, because as a strategic advisor to the board or general member, you can help influence the goals and the direction of the organization. If you are interested, please reach out to admin@members.openrf.com

The post A conversation with Kevin Schoenrock, President of the Open RF Association appeared first on OpenRF.