Open source software has completely transformed the opportunities for software development. Now, Canonical is launching a new effort to bring these principles to programmable software defined radios and industrial equipment. Developers will be able to experiment with different wireless protocols for efficiency, security, or new architectures. It also threatens to disrupt the business model of wireless carrier providers. TheServerSide caught up with Maarten Ectors, VP of IoT for Canonical to find out what this revolution means for developers.

Download this free guide

Download now: Java EE moves to the Eclipse Foundation

What are application developers and market analysts saying about Oracles decision to move Java EE to the Eclipse Foundation? What will this change? Find out here.

By submitting my Email address I confirm that I have read and accepted the Terms of Use and Declaration of Consent.

By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.

You also agree that your personal information may be transferred and processed in the United States, and that you have read and agree to the Terms of Use and the Privacy Policy.

TSS:Noticing the way that startups like Uber, Netflix, and Airbnb, are disrupting legacy business models, it is fascinating to what the birth of a new dramatic shift like this might mean to traditional telco service and hardware business models. What makes it possible to build a better base station compared to legacy offerings?

Maarten Ectors: The magic lies in commoditization of software defined radios and IT infrastructure in general. Via the LimeSDR any type of wireless protocol can be used to receive and transmit data. The end result is that open source hardware based on standard Intel CPUs and programmable components like FPGAs becomes “good enough”. You no longer need specialized chips which are extremely expensive to develop. It is this “good enough” for service which is changing the economics.

The other element is “software defined” via app stores. If you can move away from a model whereby only one company can program a base station to a world where anybody can, then innovation is multiplied. Base station designers aren’t normally skilled in cloud, content distribution networks, games, and so on. By opening up the base station and simplifying how to deliver software for it, people with completely different skill-sets can help lower costs, reduce time to market and generate new revenues.

TSS: It looks like the initial crowdfunding is sort of experimental and relatively simple compared to larger wireless switches in terms of capacity and throughput. Is it the case that this is better suited for smaller scale deployments and experimentation, and that companies might innovate on top of this to build more cost-efficient carrier grade implementations?

Maarten Ectors: The LimeSDR was a crowdfunding campaign aimed towards developers. The LimeNet crowdfunding campaign is aimed towards anybody who wants to run or experiment with production-ready base stations. The target group is different. We first needed developers to make apps before we can launch a product with an app store. The LimeNet campaign is focused on carrier grade and creating a market for the developers that made apps in round one.

TSS: How might this kind of system make it easier to prototype out different wireless configurations?

Maarten Ectors: We have created two cloud backend stores for apps for base stations. The LimeSDR app store is an open store for developers to show whatever they have prototyped. Any new protocol, any new use case, new idea, new approach, can be easily shared with others even before it is a complete product. This allows Lime Micro to understand what is hot. Afterwards the best community initiatives will be offered to make a production ready version for the by invitation only app store: LimeNet. LimeNet is connected to the production-ready equipment and both best of community and commercial vendors can offer their solutions on it. The aim is to allow telecom operators to quickly launch new solutions and test them in field trials. If they work, they can be scaled out. If they don’t then they get removed. Both approaches will allow many different ideas to go very fast from idea to prototype to potentially production.

TSS: What do you see as some of the best tools and frameworks to simplify the development of this new style of wireless apps?

Maarten Ectors: Lime Microsystems is working with the open source community on packaging tools and frameworks that simplify the development of wireless apps. They have created their own tools to make apps with the LimeSuite and are working with PhotosWare, GNU Radio and many others. The tools we see today are just the beginning. We expect many more tools to emerge from the community.

TSS: What are some of the testing challenges in building these wireless apps and some of the best tools and practices to reduce defects and bugs?

Maarten Ectors: The app format, snaps (see snapcraft.io), allows for DevOps for Devices in which you can easily upload new code to the source repository, get it automatically tested via your CI and have a new version of the snap automatically uploaded to the store on what is called the “Edge Channel”. The channel approach allows developers to create nightly builds and have automated tools test their correct working from a unit test perspective. Afterwards a nightly build can be promoted to a beta channel and go through more thorough automated testing. Finally, it can pass via the release candidate to the stable channel. Telecom operators can have equipment in their R&D centers that pick up release candidates and test them automatically. If these versions work, they can get blessed and as soon as they become available on the stable channel, the production systems can automatically upgrade in a safe time window. If this upgrade goes wrong, then a rollback is always possible thanks to the transactional rollback capabilities of Ubuntu Core (ubuntu.com/core).

TSS: What kind of FCC and other regulatory concerns to buyers of these programmable devices need to address? In other words, how can you allow programmer flexibility while addressing concerns that developers/users will not accidentally or purposefully interfere with license holders?

Maarten Ectors: Lime Micro will be working on solutions for developers of protocols, holders of license spectrum and developers of apps that use both to be more easily managed. If an app uses a protocol for which you don’t have spectrum license, then in the future this SDR will not allow it. At the same time, we have partners looking into models whereby you can buy spectrum as a service. You just pay for the minutes and the type and location you need.

TSS: How do you expect open source SDR hardware and the ecosystem to evolve over the next 2-3 years, and what does this mean for developers?

Maarten Ectors: We are launching step 2 of a three-step process. Step 1 was about building an ecosystem of developers. Step 2 is about giving the developers a market to sell their apps. Step 3 will be about reducing the cost of an SDR to as close to zero as possible. This will be done by putting the SDR on a chip and even in the future include this inside other chips. With this approach, we will go from a $285-$500 SDR to a below $10 SDR which will open the possibilities to have an SDR in any wireless device, including smartphones. The future will likely be about each mobile app having the possibility to use their own protocol by negotiating this with the software defined radio in the base station. Imagine a world whereby Netflix and YouTube use a custom protocol. This world whereby wireless protocols are built to solve end-user’s and developer’s problems and are no longer a closed committee slow moving paywall exercise will be the real innovation SDR will bring. Wireless Innovation at Internet speeds, driven by GitHub and App Stores.

TSS: What is the state of adopting similar principles to bring innovation to other value chains like MRI-scanning, car engines, and industrial robotics?

Maarten Ectors: We are starting to App Store define IoT gateways, PLCs (called ALC or App Logic Controller, which controls anything from traffic lights, elevators, industrial machinery and robots, etc.), vending machines, other types of telecom and network equipment (e.g. Facebook Wedge Top of the Rack Switch), etc. At Mobile World Congress, we will show several other devices with app stores. If they are successful open source hardware will follow soon after.

Start the conversation

0 comments

Send me notifications when other members comment.

Register

Login

Forgot your password?

Your password has been sent to:

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy