LoRa - the modem killer?

Internet of Things is at the top Gartner's hype curve of the year. But how to get the Things into the Internet? - That is the question.

When designing a IoT system, device connectivity is often among the biggest headaches. In case of consumer products, it is usually possible to rely on existing infrastructure, either Wifi Access point or Bluetooth/Smart connectivity of mobile phone. When considering city-wide installation of wireless sensors network or intending to cover a whole industrial plant, those consumer technologies are simply not feasible.

In practice, individual sensors are Today often having a cellular data modem with them, which is totally overkill. Reading a single sensor value every now and then does not need the bandwidth which is good for streaming video. Modem by itself as a component is usually more expensive than rest of the sensor electronics, and it ruins your power budget. Finally but not least, management of SIM subscriptions in global context is a nightmare.

Why there are so many cellular data modems then? Because there has been no other real options available. Low power 2.4 GHz radios like 802.15.4 can only do about 100 meters in open space. Wifi can be extended to some 500 meters, but then power consumption is over battery budget.

Sub-GHz radios can address the range issues. Narrowband RF like in TI portfolio are proven to have good performance in distance. A interesting new alternative is Semtech Lora.

Freescale FRDM-KL25Z Cortex-M0 evalution board with
ARM mbed-supported LoRa Shield from Semtech.

LoRA is a long range sub-GHz spread spectrum radio technology from Semtech. LoRa uses proprietary chirp spread spectrum  (CSS) modulation, which is rather unusual solution for data communication. CSS is more commonly known in radars and that sort of applications. In sensor node communication, added value of CSS is rather good distance measurement, which is far more accurate than traditional RSSI estimation.

BOM cost of Sub-GHz RF subsystem is less than 5€, which fits into the price range of most IoT sensors. However, having the radio in the sensor node only is not good enough. Also infrastructure is needed. In building-wide installations one can assume a gateway or two to be easily installed and maintained. In case of metropolitan area network the situation is different. Some one must build and operate the network infrastructure.

There are some indications that traditional telecom operators may be interested in introducing IoT networks. It may be considered as direct competitor with existing M2M cellular data business, which may hinder operators interest. However, if operators don't do that by themselves, some one else will do it, and then operators are only loosing.

FastNet in South Africa is the first public reference of a telecom operator investing in LoRa-infrastructure to provide IoT communication services. However, the playground is not reserved for traditional operators only, but new players like energy or transportation companies may invest into network infrastructure of their own and start selling capacity to other players as well.

Is Java dead?

While studying in the university at the turn of the millennium, Java was described as the programming solution to pretty much everything, and Java processors running bytecode in hardware were the future promise of embedded systems. 

Well,  Java processors never really made their way into mainstream, and nowadays you never hear anything of them. In the context of embedded systems, Java by itself is now performing similar act of dissappearance.

Last week I attended Embedded Conference Scandinavia as a speaker and exhibitor. ECS is the leading embedded event in the Nordics. Good for making contacts; compact and very well focused.

This year at ECS, I didn't heard anyone talking about Java or presenting any Java-based solutions. In the context of embedded systems, Java simply doesn't exists anymore - If it ever really existed? Last year I wrote about my toughs on java: Java for embedded - does it really make sense? (Sept. 2013). This year I'm even more convinced it really doesn't make sense, and other people are more and more thinking alike.

Snapshot of Freescale presentation slide at ECS.
MQTT, Node-RED, Node-JS, Bluemix and mbed promoted.

At ECS, I gave presentation about issues like MQTT, Node-RED, Node.js and Bluemix, and how to utilize them when creating embedded solutions. Just like I have done in numerous previous postings in this blog series. I was delighted to see I'm not alone with my message, companies like Freescale and Multitech also openly promoted the very same technologies and gave presentations at ECS.

If not Java, what then? ARM mbed platform is really gaining momentum now, and the ecosystem is growing with increasing acceleration. Freescale, IBM, Multitech, they all promote and support mbed Today. My first experiences with mbed are reported in Internet of Things with help of ARM (Aug. 2013).

Death of Java is not a tragedy. Instead it gives more space for proper programming technologies like mbed, Node.js and Node-RED. Think of world with Java never invented - all the millions of man years of wasted effort used for something useful...

IoT rocks

IBM Insight 2014 in Las Vegas is over now, here are some remarks.

Mobile first, Cloud and Watson are the big things of the day. IoT is a rising trend, but a bit curiosity among IT people. IBM is still refining it's IoT strategy, but the importance is well recognized. Bluemix is one the key enablers of the new era.

In the main session at Tuesday morning, even a live IoT-demo with Bluemix and Node-RED was presented. I felt that so familiar. Some readers may remember my Bluemix-journey starting from the IOTcoop with very much the same technologies.

MQTT plays essential role how devices are connected. Actually, meanwhile IBM people had their event, OASIS organization officially approved new version 3.1.1 of MQTT standard. I'm a member in the Technical Comittee.

Presentation slide of John Thompson.

I had my priviledge to attend a Business and Industry Leadership Executive Luncheon, hosted by the Vice President, Internet of Things Strategy, John Thompson. John gave an awesome speech about Internet of Things. He really knows what he is talking about, and well recognized all the challenges which well known by Embedded Systems and IoT players like my company.

John stated 70% of technology is the same in traditional IT and IoT, but 30% is different and that's why it is hard for traditional IT players to succeed in any IoT project. The snapshot from his attachment highlights the key differentiating factors. It's interesting to notice that it's not only about technology, but people as well. In IoT, your partners are different to tradional IT.

Companies like Espotel are the rising stars of the new IoT era.

Cloud on cloud

Where do you do your cloud development, in the cloud perhaps while flying high?

One important aspect to add in to my previous Bluemix testimonial. As it is a cloud service, it's omnipresent. No matter whether you're in the office, at home, or traveling, you can control and develop your cloud app, at any place any any time.

Wifi is getting more widely available in airplanes nowadays. It was really cool Yesterday when I was flying to Las Vegas for IBM Insight conference. I did literally cloud programming by modifying the Bluemix app while up in the clouds, or above. 

Before I departed, I told to the business partner that I'll be away for couple of weeks in total, but don't worry, I'll keep my commitments and your progress is not endangered at any time. I can do my part of the job while being away, thanks to the decision to select the cloud as the common integration point.

Cheers from Vegas! I'm looking forward for 5 interesting days among IBM technology and people. Watson for Analytics will be my topic of special interest here. I hope I can soon tell more about that.

Watson logo.

Bluemix for real business

Last week at IBM Business Connect I talked about Bluemix accelerating to market. This week I made it reality.

Usually I don't talk about customer projects here, and usually I don't implement software in customer projects by myself either. So this is a double exception.

Recently we started a new project where my company is supposed to deliver an IoT solution for a retail domain, another vendor provides ERP system, and we do integration together. So this is a multi-vendor case. All the vendors - 4 in total - are separate legal entities having separate premises and information infrastructure.

Traditional way of co-development would cause need to cross-install software components into each others development environment, an/or creating VPN-connections or other holes to firewalls and stuff. This time I decided to make it differently: for the duration of development, I created the integration point in Bluemix.

Node-RED screenshot as illustration. Picture taken from nodered.org web site.

There are clear benefits we gained immediately at the beginning of the project:

Rapid development
First of all, thanks to PaaS, the base system with selected components was up and running just in minutes. I decided to use Node-RED to implement my part of the integration. Node-RED is semi-graphical programming language built a top of Node.JS. Roughly within an our from beginning, I had the first application specific functionality implemented and in service.

Shared access
All parties involved in the development have access to the cloud, no-one needs to compromise corporate security by implementing any changes in the existing IT configurations. Connections are encrypted by TLS/SSL, which makes it secure enough especially as no real business data is involved in the system during development time.

Instant deployment
As this is a R&D project for a new innovation, no readily available specifications exists. Documentation is written parallel to the development, in agile manner. Changes occur multiple times per day, and it's crucial to deploy them fast. With Node-RED, the development actually occurs in Bluemix with web user interfaces. Performing deployment only requires single click of Deploy-button, and changes are in production (in developer zone) in a second.

Fail fast
As said, no specs exists a priori. Some ideas are good, some others not so much. The three things mentioned above make it easy to test new ideas quickly - and fail fast. Already during the very first day of joint development, we found some basic assumptions wrong, and changed some design fundamentals immediately. Without all help of this, it would may have taken weeks to recognize the root problem. Think of all the wasted effort by re-writing the code then!

DevOps
I'm not an operator. I can install a Linux desktop by myself, but installing a production server with high security and SLA sounds like a nightmare. With help of Bluemix PaaS, I do not need to care about the platform. I only need to focus on my own code which brings the added value to the customer.

It's not just hype, the benefits are evident, and experienced in real-life commercial business. Someone is paying for all that, and I believe the one is happy for the benefits gained in terms of savings in time to market and development costs.

PaaS security considerations

Security is the first concern which arise when talking about cloud services. Let's take a closer look.

Cloud services are usually categorized as SAAS, PAAS, and IAAS. What comes to security, I personally trust PaaS most.

Infrastructure as a Service (IaaS):
Computing resource, typically a virtual machine or sometimes physical computer, is provided to customer. Customer installs platform, middleware services and application software. Security is more or less up to the customer's competence. Example service providers: Amazon EC2, IBM Softlayer.

Platform as a Service (PaaS):
OS platform, execution environment, data storage and services are provided by service provider. This environment is more limited simultaneously more protected than IaaS. Example service providers: Microsoft Azure, IBM Bluemix.

Software as a Service (SaaS):
Customer pay for use of certain domain specific application and has very limited capability to affect the behavior of the software. Usually SaaS providers do not disclose their security measures, thus one can not evaluate the level of security. Example services: Salesforce, Basecamp.

Summary: IAAS - You're on your own. PAAS - Limited but protected. SAAS - You just got to trust.

PaaS security mechanisms

Let's dig into some details of security mechanisms of PaaS service. I'm using IBM Bluemix as an example here.

Control of external communication
Only HTTP/S and WebSocket/S connections are allowed. All other connection attempts are discarded. All external connections go through external appliance for improved security.

API isolation
Only selected set of application programming interfaces are provided to developer. Even if the application is behaving badly, it can not do much harm. Vulnerabilities like Shellshock are eliminated as the platform does not provide access to such services as command line.

Data protection
Data is proven to be available to given application only. However, several instances may share the same data store, if configured so.

Platform instantiation
Each application runs in its own container that has specific resource limits for processor, memory, and disk.

The week point of a PaaS-based cloud service is the application itself. No security measure can protect the application from it's own stupidity. However, the developer can focus all attention to application design, without need to worry for underlain services. This may eventually reduce the amount of stupidity in application design and leads to better overall security.

Value proposition of PaaS

It's simple: Bring your own code. What makes it so special then?

Have you ever had a new business idea but hesitate to try it out due to the risk related to the initial investment? If your business is related to internet services, maybe PaaS can help you. 

Perhaps the biggest promise of the Platform as a Service (PaaS) is the user's ability to try new things out with minimum risk. Just take an instance, deploy your code, and pay per use. If it's aint working as a business, then just quit it, and you didn't lost much.

Snapshot of Bluemix service configuration panel.

Let's take a closer look to some key aspects:

Pay per use

Do you know how many users you'll have on your new service? Seldom one can predict that, and it makes ROI calculation difficult. How about having your costs proportional to your user count. That means fixed production cost per production volume.

Modern PaaS services like Bluemix offer innovative payment models. The base charging unit of Bluemix is Gigabytehour (GBh), somewhat similar to kiloWatthours (kWh) you're paing for the electricity. The analogy is obvious: pay per use.

Focus on your code

You do not need to care about hardware, connectivity, or the software platform. Just select the necessary middleware services you need, and put all your energy on your application, which is the one who brings all the added value after all. It's the service provided by your application which matters to your customers, not the underlain infrastructure.

In traditional IaaS approach, you need someone capable of putting it all together and setting it up, and someone to maintain it and keep things rolling. With PaaS, it's all taken care on behalf of you. You only need to understand your application details.

Instantly in service

Just a few clicks to select components and services you need, and you're ready to deploy you code to production use. How about development then? Just use the same PaaS, but developed on your own sandbox. Once it's ready to publish, just deploy it to production by simple mouse click.

Maintenance free

If something is advertised as maintenance free, it usually means you can't fix it. In case of PaaS, you do not need to fix it, as someone is already doing that, and without you even notice it. 

IBM wrote about my thoughts in their blog at Sept. 23rd, 2014 (in Finnish):  Playground for developer - Early birds experiences

One can't avoid discussing about internet services without someone asking for security. That will topic for a next postings.