Archive

Bluetooth has enabled a revolution of any type of cheap Chinese peripheral to talk to any tablet, PC or TV. It allows many uses via its long list of standardized profiles. However its strengths are also its biggest weakness. Bluetooth is a very complex standard and more often than not it gets abstracted away by several software layers that make it somehow manageable for “very motivated” programmers. The reason for these complexities are based on a reality that soon will stop to exist. Bluetooth assumed cheap wireless communication chips need to be designed years in advance and as such any possible use case needs to be supported in silicon not in software. Making a silicon based standard that is future proof for any use case equals adding lots and lots of complexity in the form of GATT, GAP, options, etc.

Cheap software defined radio will change the foundations Bluetooth is build upon

What if you don’t need to define everything upfront but you still have cheap silicon? That is the promise of a new generation of software defined radio [SDR], the cheap version of a technology that used to cost thousands of dollars per device. Cheap SDR will allow the Github generation to define easy to use wireless protocols. Since these protocols don’t need to support any and every use case upfront, we will see an revolution in wireless technologies that was similar to how businesses moved from highly standardized electronic data interchange [EDI] to XML and schemas and more recently to free format JSON and Yaml.

How will the future of wireless technologies look like?

If every appliance at home or in a business would have a cheap SDR then communication will be a matter of downloading apps for the two devices that you want to communicate. Likely there will be a github driven series of standard-by-adoption protocols but they will see rapid evolution and succession just like we are seeing now in programming languages where Java every day gets a new competitor in the form of Ruby, Go, Haskell, Rust, etc. Programming languages no longer have widespread adoption, neither have artists and anything that the masses can define what is hot or not. Bluetooth will be like the Beatles, a memory of a cool thing that had everybody excited back than but the next generation of wireless communication will be more like Justin Bieber, very important to some, safe to ignore for everybody else…

Like this:

GSMA, ETSI, etc. have been defining standards for the telecom world for years. However outside of the telecom industry these standards have found little or no adoption. In a world where telecom operators are fast becoming bit pipes, do we really need telecom standards? Why can’t the telecom industry just use SIP, WebRTC, REST, etc. just like everybody else?

The current systems in telecom are assuming calls and SMS need to be billed for. What would happen if the starting point is: data insights, network apps and connectivity are the only things that are billed? Connectivity is likely going to be unlimited or with very high limits over time. New revenue would have to come from selling data insights, either individually with consent, or aggregated and anonymised. As well as from apps that run inside the network: on CPEs, DSLAMs, mobile base stations, etc. So for the purpose of this blog let’s focus on a world where calls and SMS can no longer be charged for and connectivity is close to unlimited for most normal use cases. To move bits fast through a network, you want the least number of protocol converters. So using many different standards would make things slow and expensive. Additionally telecom operators have overpaid for lots of standards and their software support during years without ever using them. Finally implementing a standard is very costly because often only 20% of the functionality is really used, but the other 80% needs to be there to pass compliance tests.

The nonstandard or empty networking appliance
In a world where software can define networks and any missing functionality is just a networking app away, it would be a lot better to start from an empty networking appliance, i.e. networking hardware without software, and then to buy everything you need. If you need a standard then you might want to buy the minimal/light, equals 20%, implementation and see if you can live with it. Chances are you still have too many functions that are not used. Facebook open sourced its top of the rack networking solution and surprise, surprise, the interface is Thrift based. Thrift is used in all the other Facebook services to have a standard high throughput interface for all its software services. Google probably uses protocol buffers. Apache Avro would be another alternative and the most openly licensed of them all. So instead of focusing on a standard, it would be better to standardise on a highly throughput optimised interface technology instead of public slow standards. Inside a telecom operator this would work very efficient and for those systems that talk to legacy or outside world systems, adding a standard is just a networking app away. This would simplify a telecom network substantially, saving enormous costs and accelerating speed of change because less code needs to be written and maintained making integrations easier. These are all ideas that assume there are actual appliances that are software defined. As soon as general purpose compute becomes fast enough for heavy data plane traffic then the reality will be software defined networking in a virtualized way with autoscaling and all the other cloud goodies. However this reality is still some years off, unfortunately. In the short run virtualization of the control plane and software defined networking appliances [SDNA] for the data plane, is the most realistic option…

If you thought that we were waiting by the phone to get calls from telecom CEOs for the telco innovator’s den then you don’t know us. From the start, we did not think they were going to call. However we were surprised that one of the top 10 telecom CEOs actually got our blog post, read it and considered calling. This is a clear signal that our base message: “The telecom sector needs to innovate or things will get messy” was spot on. There are three things that sell in this world: sex, gossip and controversy. If you want to deliver a message to a large audience that does not want to listen, pick at least one as your theme and build a guerrilla marketing campaign around it.

If you think that we are now organising the Bitpipe Accelerator Den, then you are also wrong. Yes we would be able to assist in supplanting inefficient telecoms with efficient Google Mobile and Fiber. However would that serve a lot of people? Do you really want lawyers to start calling you with offers to help you with your divorce because Google detected that your partner is looking into it but hasn’t told you yet? Do we really want to see large 300.000 employees companies reduced to 3000 because they are now bit pipes? Telecom downsizing is not pleasant. So please if you are working in the telecom industry, or in any industry that is the victim of disruptive innovations, then please keep on reading and become a Dinovator…

Dinovators are people that wake up one morning and find that the company in which they have been working for many years has been converted into an IT dinosaur. Not because the employees have been doing something wrong but because the outside world just went too fast and out innovated them. You now have two options: 1) Jump ship 2) Show dinosaurs how to innovate. If you are a Dinovator you prefer option two.

So how can you innovate in a traditionally minded company? You can go and show slides. You can go and tell everybody that the wolf is coming. However we tried those approaches years ago and you will fail. Majorities and laggards don’t want the status quo to change because they have a vested interest in it and they don’t know if they will have so in the new reality.

What works however is seeing magic with your own eyes. Anybody that has seen and touched the future can’t deny it any more. Now how can you show the future to people? First of all you need to understand their problems. If in the telecom industry the problem is revenue generation, then don’t go and show them a new proposal for a better protocol or faster network. Show them how new revenue can be generated, churn reduced, cost reduced, OTT revenue generated, etc.

So if you are technical then you can use the cheapest X86 server with 6 ports or any other device you can get your hands on and put an open source operating system like Snappy Ubuntu Core and you can create some Snappy Apps to show that there is a better future and can convert it into the smartest switch that solves the 4 biggest telecom industry problems. You can use the open source Juju charms and some cloud to show how complex telecom software can be abstracted and how for instance an open source SMSC can have a rest API with three parameters [to, from & message] and still deliver the same SMS service as that very expensive box that has all types of SMPP and other useless APIs and takes months to integrate with. If you are in financial services, retail, logistics, industrial, energy, etc. then you can probably find some other cheap box that can be Snappyfied or open source software that can be charmed so you can show your magic.

If you are not technical but have access to suppliers then you just ask them to surprise you with what they can come up with if they would apply disruptive innovations like Snappy and Juju. If you promise them that you will arrange a meeting with the boss of your boss if they surprise you, then they will be happy and surprise you for sure.

However to accelerate “dinovation” and to be inspired with what a community of dinovators can do, our proposal is to use Twitter. Just tweet a 1 minute video or a short blog post about your “dinovation” and include #dinovator and @telruptive. If you see tweets with great “dinovations” then you retweet them and share them with colleagues, customers, partners and bosses. This way you can become part of the the Dinovator Movement. The Dinovator Movement is not accepting that companies that have been around for many years are useless and need to be substituted. The Dinovator Movement is about showing that even in the most traditional companies there are Dinovators at work that show how that company needs to adapt to the new reality. The Dinovators explain to management that what is needed is Innovator’s Dens in which partners, customers, suppliers, etc. are invited to participate and innovation can be accelerated without RFPs and wasting everybody’s time. A Dinovator wants their company to embrace the new reality and thrive on it. Open Source has made becoming a Dinovator super easy. Nobody will put a critical system in production without paid support so even business people will be happy with open source Dinovations. However open source has a magical power, it does not get stopped by RFPs. So use its power. Have a Dinovator Day…

Communication experts will say that software defined radio has been around for many years now and is heavily used in mobile base stations. The truth is that until now it was extremely expensive. Only the large network equipment providers were able to use them at scale.

In the next months this is about to change. Software defined radios will become cheap and omnipresent.

Why are cheap SDR boards a revolution?
Easy. Currently all wireless communication standards are defined in large corporations or foundations. These standards are all but easy to use. Before Arduino and Raspberry Pi entered the market, hardware was something only specialised experts backed by large corporations could be working on. Now anybody will be able to make a quick prototype, put a video on Kickstarter and become a multimillion startup.
If radio communication protocols can be made by thousands of small startups and innovators then the future protocols will be easier to use, lighter, and faster than the current generation.What would you build on top of cheap SDR boards?
Obvious things would be amateur radio, drone control, next-generation wireless protocols, IoT sensor communication, etc. However we are looking for some crazy ideas that would surprise lots of people. If you have a crazy but exciting idea, just add a comment to this blog. We want to work with you…

Two weeks before mobile world congress the Canonical offices received from Amazon one of the cheapest Intel servers with 6 Ethernet ports. It contains no hardware acceleration. Two weeks later employees from Ericsson, Cisco, Huawei, ZTE, HP Networking had to admit that they could not take us to see a smarter switch in the whole of MWC. This blog post is about what made this switch the smartest switch. The next blog post explains how this smart switch can solve the four biggest problems in the telecom industry (I.e. new revenue, churn reduction, cost reduction and OTT revenues).

So what made this switch so smart. First of all when we got it, it was an Intel server with an i5 processor and we had to go and buy 8GB of RAM and a 256GB SSD and put Ubuntu Core on it. The next thing our brilliant engineer Loic created was a Snapp App or Snap that made port 1 into WAN and the others into LAN. Now we actually had a switch. He and our equally brilliant head of R&D, Alex, also worked with F5 on a Snap that can boot up a KVM in which you run another operating system. This allowed us to put F5 Linerate in the switch. The end result is that we have the only Switch that very easily can support any exotic operating system to run on top. Via our Docker framework we could also run Docker based networking logic. However if you run the networking logic inside a Snap then this would give bare-metal performance with the flexibility of completely reconfiguring the switch by just deploying a different snap or adding multiple. If the engineers of the companies, that had to admit we had the smartest switch, want to win tomorrow then they just need to take a box with accelerated networking hardware and put a Snappy Framework that mediates between different Snaps that use network hardware acceleration. It would be the most flexible software defined networking appliance or SDNA out there. We also worked with the super engineers from Balabit that delivered a Firewall Snap in three days. So now we can assign Linerate to port 2 till 4 and Zorp to port 5 and 6. Making it a very flexible SDNA and Ubuntu Core the perfect NFV or SDNA operating system.

Zabbix already made one of our best written Juju Charms and they made a Snap of the Zabbix agent for ARM and Intel in no time. This means that our SDNA was now being monitored.

When telling the public that we called Microsoft to ask if they could write some software for our SNDA and open source it, everybody was surprised they said yes. The truth is that Microsoft is one of our best partners for quite some time now. Two days later we had a Snap that worked both on Intel and ARM and put a nice graph of the real-time load of our SDNA onto Azure. They even documented everything hence any programmer can connect Ubuntu Core to Azure super easy. Impressive work and thank you Microsoft because it made for a very surprising element in our story.

Even more surprising was the fact that we had ARM software running on Intel. Thanks to Forgerock and ARM we had an ARM mbed coap snap and mbed device server running in the cloud. Forgerock and ARM helped to put our SDNA inside a complete device management solution with identity and access management being seamlessly resolved.

However none of these solutions made us have the smartest switch of MWC. That was reserved to our amazing IoT partners Dataart and Cybervision. A simple €5 bluetooth low energy dongle integrated our switch with light and temperature sensors. Devicehive made our switch magically into a light controller. What was event more amazing was that via a Snap our switch became AllJoyn compliant and was the first switch to be able to talk to a television, dishwasher or fridge. The open source Devicehive will shortly be extended with Snaps for all possible IoT standards solving one of the biggest IoT problems for IoT developers instantly: interoperability. This will be the easiest way for any industrial gateway to become compliant with all types of standards. Also the cool open source IoT platform Kaa made our switch magical. Imagine how a shop can easily buy a Snap from a Snap Store that would be able to project Tweets onto a large LED display in the shop’s window. If only one Tweet every ten seconds would be randomly selected, it could start a new trend of Tweesplaying. The store that started it could potentially have millions of Tweets competing to be on the display and become an instant social network celebrity.

The last part was my most personal contribution. If you work with the most brilliant engineers you have to be able to ask intelligent questions. Nothing better than actually trying out the technology they just created. Thanks to a discount in Maplin, we were able to buy a robot arm for £35. Three hours later it was build. However there were no Linux drivers. I have been looking for an excuse to learn Golang and build something with Ajax. The end result is on github and you can now control the Maplin robot and make it do amazing demos via a Json script or some buttons.

All this would not have been possible without the contributions of all these amazing partners and colleagues, so thank you very much. So without any delay here is the smartest switch and the first software define network appliance, or SDNA. We hope somebody soon makes a smarter one because the hardware specs was embarrassingly low-end compared to what was available on the show.

Disclaimer

All the contents of the Blog, EXCEPT FOR COMMENTS AND QUOTED MATERIAL, constitute the opinion of the Author, and the Author alone; they do not represent the views and opinions of the Author’s employers, supervisors, nor do they represent the view of organizations, businesses or institutions the Author is a part of.

The Author is not responsible for the content of any comments made by the Commenter(s).

While we have made every attempt to ensure that the information contained in this Blog has been obtained from reliable sources, the Author is not responsible for any errors or omissions, or for the results obtained from the use of this information. All information in this Blog is provided "as is", with no guarantee of completeness, accuracy, timeliness or of the results obtained from the use of this information, and without warranty of any kind.