LPWA (Low Power Wide Area)
LPWA is a generic term for a group of wireless communication technologies with the following key characteristics:
- Low power consumption:
- end devices (e.g.: sensors) are usually powered by batteries with 15+ years of battery life time
- Wide area connectivity characteristics:
- the maximum distance between the ends of the wireless links is more than 15 km
- the infrastructure can easily scale at a size of a country
- Low cost of network components and cheap end-devices
- Data communications throughput capacity is usually less than 10 kbps.
LoRa (Long Range Radio)
LoRa™ is a wireless spread spectrum data modulation technique developed by Semtech for LPWA communication. LoRa™ has the following key characteristics:
- Applies CSS (Chirp Spread Spectrum) modulation in 125 kHz channels.
The modulated signal can be generated by Semtech LoRa parts, including the SX1272 and SX1276 transceiver chips.
- Operates in unlicensed sub GHz frequencies that are available worldwide. The most widely used frequencies / bands are:
- 868 MHz for Europe
- 915 MHz for North America
- 920 and 433 MHz band for Asia
- Provides long range coverage
The LoRa modulation allows coverage over a range of 2 to 5 km in dense city areas and up to 15 km for countryside applications.
LoRaWAN (LoRa Wide Area Network)
LoRaWAN™ is an open global standard for secure, carrier-grade IoT LPWA connectivity defined by the LoRa Alliance. The LoRa Alliance is the fastest growing alliance in the IoT industry having 400+ members. The founding members were Semtech, IBM and Actility.
The LoRaWAN™ infrastructure has the following key characteristics:
- Star Topology
LoRaWAN™ network architecture is typically laid out in a star-of-stars topology in which gateways is a transparent bridge relaying messages between end-devices and a central network server in the backend. Gateways are connected to the network server via standard IP connections while end-devices use single-hop wireless communication to one or many gateways.
- LoRa RF modulation
The LoRa™ RF modulation is used as the physical layer of the connectivity between devices and gateways.
- Bi-directional communication
The radio technology used by our sensors is fully bi-directional. It supports both monitoring and remote triggering of sensors and therefore covers a wider range of innovative IoT applications.
- Adaptive Data Rate (ADR)
ADR is the procedure by which the network instructs a end device to perform a rate adaptation by using a requested Data Rate and TX Power. One of the major purposes of this feature is to reduce the device battery draining while ensuring satisfactory quality and boosting the link budget.
- Low Device Energy Consumption
The LoRaWAN infrastructure supports low-power sensors requiring less than 15mA which cannot be covered using traditional short range wireless networks or traditional ISM technologies.
- Three different types of device classes
LoRaWAN defines 3 different classes of end-point devices to address the different needs reflected in the wide range of applications:
- Bi-directional end-devices (Class A):
End-devices of Class A allow for bi-directional communications whereby each end-device's uplink transmission is followed by two short downlink receive windows. The transmission slot scheduled by the end-device is based on its own communication needs with a small variation based on a random time basis. This Class A operation is the lowest power end-device system for applications that only require downlink communication from the server shortly after the end-device has sent an uplink transmission. Downlink communications from the server at any other time will have to wait until the next scheduled uplink.
- Bi-directional end-devices with scheduled receive slots (Class B):
In addition to the Class A random receive windows, Class B devices open extra receive windows at scheduled times. In order for the End-device to open its receive window at the scheduled time it receives a time synchronized beacon from the gateway. This allows the server to know when the end-device is listening.
- Bi-directional end-devices with maximal receive slots (Class C):
End-devices of Class C have nearly continuously open receive windows, only closed when transmitting.
- Bi-directional end-devices (Class A):
- Security at application and network levels
LoRaWAN network architecture offers end-to-end network security. Message payloads between end-devices and the network server are encrypted by Application Session Keys while the integrity of protocol commands and signalling are ensured by a hash mechanism based on Network Session Keys. This security is applicable even in a multi-vendor environment assuming that every component have passed the LoRaWAN/Thinkpark certification tests.
- Location based services
Time difference of arrival (TDOA) based localization is based on precise measurements of packet arrival time differences on different base stations. It does not require specific capabilities in the mobile node, such as a GPS, dramatically reducing its cost and power consumption.
LoRaWAN base stations are GPS synchronized and support TDOA localization with ~50m accuracy for 125kHz spread-spectrum nodes even in urban multipath environments for fixed or mobile objects.
- Open standard (ensuring Device Interoperability)
ThingPark Wireless is based on the LoRaWAN™ standard which provides seamless interoperability among smart things without the need of complex local installations and gives back the freedom to users, developers and businesses to roll out IoT solutions.
Does cloud mean a bright future for a Communication Service Provider?
Cloud computing is going to have significant impact on both IT and telecommunication architecture and its operations. This document reviews the parallel development of cloud and network technologies and discusses the opportunities and threats the gathering clouds on the sky bring to Communication Service Providers (CSP).
The term “Cloud” comes from telecommunications where the “Cloud” symbol was used on network diagrams to hide the details of the network architecture. In the IT world, cloud refers to the concept of delivering IT systems to users as a service through a telecommunications network. The “Cloud” symbol represents here the hardware and software installed in the data center and not the telecommunications network anymore. It means in practice that all popular services offered over the Internet (like Google App’s, Skype, Facebook...) are cloud services. Access to the cloud is provided by Communication Service Providers (CSP), and cloud users can usually select among a couple of independent network services to access a cloud. This results in a competition of CSPs for connecting users to cloud services. The biggest problem CSPs are facing here is that they tend to become a simple access point (“bit-pipe”) to cloud services, operating at a very low level of the value chain.
The path from mainframe to smart phone
Before defining the real term Cloud Computing let’s briefly review how cloud services developed. The idea of concentrating all hardware and software components of a system in a central location and access their services through thin clients is not new. Both dumb terminals connected to mainframes and Android smart phones using Google services apply this concept. The 50 years long path from mainframe to smart phone is described in the next chapters below.
Mainframes are big powerful computers that were deployed in large scale in the 1960s and 70s mainly for big corporate organizations to support their mission critical applications. A mainframe could serve hundreds of users simultaneously applying batch processing and time sharing techniques. Users were provided access to computer resources through dumb terminals. At that time the public telecommunications network was not designed for connecting dumb terminals from remote locations to a central mainframe system in a large volume and in a cost-effective way. This prevented mainframes to be used by smaller companies who couldn’t afford deploying their own systems.
From the beginning of 1980s small and medium enterprises as well as domestic users started using a radically new type of computer, which changed the IT world: The IBM Personal Computer (PC). The PC’s price and operational cost was far more practical and affordable for both home and small business users. The IBM PC and its clones grew to dominate the market extremely quickly.
Parallel to the birth of the new PC world the TCP/IP protocol suite was standardized as the basis of a new world-wide network concept called Internet. The internet technology allowed interconnecting millions of PCs in a cost-effective way. Dumb terminals were rapidly replaced by PCs that allowed accessing legacy mainframes via the Internet. Enterprises soon started building their own PC cluster-based servers to provide support for their PC clients, quickly reducing the need for mainframes.
To increase cost efficiency, big server farms and data centers have been created to provide support to remote offices. Since data connections are usually provided by CSPs, server farms and data centers are ideally co-located with the equipment of CSPs. As a consequence many CSPs offer co-location services for data centers. Data centers can be operated either by the enterprise itself or can be outsourced as a managed service, which led to the evolution of the private cloud service.
Applications on the Internet
Web 2.0 is a term that refers to applications that are offered by web servers on the Internet for information sharing, collaboration, social networking or other similar purposes. Examples include Gmail, Hotmail, Facebook, Twitter, LinkedIn, etc. While Web 2.0 services are accessed through a web browser there are several other services - like Skype or Google Talk - that require a special client application rather then relying on the web browser. These applications together with Web 2.0 services represent a special type of cloud service called public or community cloud.
Smart-phones like the IPhone and others running the Android OS are new types of terminals that are ideal thin clients of cloud services. They are usually sold by CSPs bundled with their network services. However CSPs were not successful in binding smart-phones to their own clouds because they cannot compete with the popularity of community clouds such like Google and Facebook, who offer their own IPhone or Android applications as cloud clients. These client applications can be freely downloaded and installed on a smart-phone by the user without the involvement of the CSP. Smart-phones can also be clients of private clouds. It is a great opportunity for a company to leverage the fact that their employees may already have their own smart-phones that are able to run client applications enabling the company’s private cloud service (e.g., Microsoft Exchange ActiveSync client). However, employees do not want to stop using their favorite community app’s like Facebook, Linkedin, etc. This can cause headaches for IT security managers since they have to make sure that the same security policy is applied on employee-owned devices as well as on company equipment.
The term “Cloud computing” is different from the term “Cloud”. While a cloud is a service provided over the network, Cloud computing is an architecture that allows provisioning cloud services in a scalable way to support a pay-as-you-grow business model. There were lots of technologies used to achieve the required scalability, most of which are still used. A few worth mentioning include clustering, load balancing, distributed computing and virtualization. Using these technologies in an intelligent way to enable the packaging of computing resources such as CPU, memory and storage as a metered service is called utility computing.
Utility computing allows cloud providers to offer Infrastructure as a Service (IaaS). Users of IaaS can install their own software including operating systems, development environments and applications on virtual machines. An example of IaaS service is Amazon Elastic Computing Cloud (Amazon EC2).
There are also cloud providers who offer services at a platform level that include a pre-defined development environment. This model is called Platform as a Service (PaaS) and supports applications appropriate for the selected development environment. Two examples of PaaS are Google AppEngine (using Python) and Facebook plug-in App’s. Another more trivial example is a simple web-hosting provider that offers Apache/PHP/MySQL platforms for creating dynamic web pages, which is often included as part of a CSPs’ service portfolio.
Cloud applications represent the highest level of the cloud computing architecture. Services offered at this level are called Software as a Service (SaaS) that refers to the fact that cloud providers are asking service fees instead of selling licenses.
Cloud computing architectures can be grouped in three main categories: Private, Public and Hybrid clouds (community cloud, mentioned earlier, is a special sub-class of the public cloud). The entire architecture of a private cloud is dedicated for the same organization while a public cloud serves multiple organizations using the same platform or infrastructure. Due to security considerations, an enterprise may not want to deploy all of their applications on a public cloud. In this case a hybrid cloud model can be employed that combines the best aspects of public and private cloud services.
Cloud computing for CSPs
Cloud computing is a disruptive technology since it significantly changes the way IT systems will be operated. This applies to both enterprises as well as Communication Service Providers. CSPs can use cloud services for their own systems, provide cloud services to their customers, support other cloud providers’ services or find smart ways to tap into the revenue stream of those cloud providers that use their network to connect users. Each of these scenarios is described in details in the following paragraphs.
Using cloud services
CSPs can use utility computing to form a more flexible and scalable common infrastructure for different components of their heterogeneous service provider platforms, even across different vendors’ systems. This does require that the different vendors have developed cloud-aware applications that are certified to run on virtual machines. This results in a private infrastructure cloud that can host applications like Voice mail, SMSC, MMSC, OSS, BSS, etc. There are, however, some systems that cannot be optimized for cloud services. Network components that handle direct traffic (e.g., routers) are not recommended for operation in a virtualized infrastructure. These systems are designed by vendors as bundled hardware + software solutions sometimes referred to as appliances. In most cases appliances require proprietary hardware. The conflicting industry trend of emerging IT appliances is pushing the IT industry to the opposite direction of clouds. Beyond private clouds, CSPs may prefer not to buy systems from vendors but rather use them as managed services provided by equipment vendors. A vendor can offer these types of cloud services either as a hosted private cloud or as a public cloud.
Providing cloud services
CSPs provide network connections that allow their customers access to cloud services. These services are sometimes called Network as a Service (NaaS), with a similar naming convention what is used for the different levels of cloud services. NaaS, however, is not a cloud service by itself, but is rather an enabler of other cloud services. There are also value added services that have been provided by CSPs for quite some time that can be considered cloud services, although they are not applied on real cloud computing architectures yet. A few examples include Voice mail, SMS, MMS, or IP-Centrex that offers hosted PBX services. Cloud computing opens a great opportunity for CSPs to become significant players in the cloud market and reposition themselves further up the value chain. They have a number of significant competitive advantages, including:
- CSPs operate their private clouds for hosting certain network systems and have experience in cloud operations.
- CSPs can co-locate their cloud architecture with their network architecture to enable high-speed access to the service.
- CSPs sell smart-phones to their subscribers bundled with their mobile data service and - as was mentioned earlier - smart-phones are ideal clients of cloud services. Smart-phones can be sold with pre-installed and pre-configured cloud applications customized according to CSPs needs.
- CSPs can control the quality of service (QoS) of the network connection between the user and the cloud. For example they can assure special QoS parameters for a video streaming service.
- CSPs can authenticate their customers based on SIM cards in mobile devices or line IDs of the physical connections that increase the level of IT security.
Admittedly some of the competitive advantages described are valid only in case cloud services for enterprises. CSPs are facing serious challenges when they try to get market share with community clouds and compete with services like YouTube, Gmail, Facebook, Skype, MSN, etc.
Supporting cloud services
This chapter presents two different technologies that help CSPs to support or complete cloud services: Content Delivery Network (CDN), and Policy and Charging Control (PCC) system.
Content Delivery Network
Cloud providers who offer high data volume content to their users (e.g., movie streams) need serious network capacity for content delivery. A Content Delivery System (CDN) helps optimizing the usage of network resources by storing the content on different network nodes as close to the users as possible. CSPs providing their CDN service to content providers’ cloud service can significantly increase the quality of user experience and reduce network load and costs.
Policy and Charging Control
Another way for CSPs to generate revenue from cloud services is by offering special network service packages or data plans for either cloud providers or cloud users. A data plan can be tailored to special features of a certain cloud service. For example a video sharing portal requires constant bit rate, a voice over IP application requires low latency, etc. Beyond the QoS parameters CSPs can also customize charging schemes. This would allow, as an example, free unlimited Facebook access for mobile users if they subscribe to the “Facebook data plan”. The system that allows CSPs defining customized data plans is called Policy and Charging Control (PCC). The PCC architecture is defined by 3GPP standards that also define an interface (Rx) for connecting the PCC to cloud applications. This interface enables applying always the right QoS and charging policies for certain cloud applications.
To tap into the revenue stream of cloud providers
There is a serious issue with 3GPP’s Rx interface. None of the most popular public cloud providers have deployed it yet, and have no business motivation to do so. Popular community clouds like Google, Facebook and Skype already recognize that CSPs are not able to compete with them using their own in-house cloud services. Additionally, CSPs compete against each other to provide access to the popular community clouds. CSPs do, however, have a potential way to tap into the revenue stream of popular cloud providers without having a commercial agreement with them, using a technology called Deep Packet Inspection (DPI). DPI is an appliance that analyzes and classifies all Internet traffic handled by the CSP. DPI detects which cloud application a certain subscriber is using and reports it to the Policy and Charging Control Rules Function (PCRF) which is the central element of PCC. The PCRF checks which data plan the user is subscribed to and applies the relevant QoS and charging rules that are also aware of the used cloud application. Please note that keeping the application signatures of DPI up to date may not be easy. For example, if Skype issues a new protocol version it may bypass the DPI detection algorithm until the DPI vendor recognizes the change and develops the necessary signature update. In an ideal world there is no need for DPI since cloud providers are co-operating with CSPs and use the standard interfaces for the interworking.
The background technologies of cloud computing and telecommunication have been developing symbiotically for the past 50 years. Each sector had to adapt to the needs and capabilities of the other’s. These days cloud become a disruptive technology and is expected to cause significant change in the IT and telecommunication industries. This will mean a variety of challenges for Communication Service Providers. They will need to adapt cloud technology for their internal systems and utilize their unique capabilities for getting strong positions on the cloud providers’ market. CSPs cannot compete with popular community clouds but can easily become significant cloud providers of enterprises.
- Unisys - Exploiting the Cloud for Mission - Critical Workloads via the Hybrid Enterprise - http://www.disruptiveittrends.com/trends/cloud
- Michael Armbrust, Armando Fox, Rean Griffith, Anthony D. Joseph, Randy Katz, Andy Konwinski, Gunho Lee, David Patterson, Ariel Rabkin, Ion Stoica, Matei Zaharia - Above the Clouds: A Berkeley View of Cloud Computing - http://radlab.cs.berkeley.edu/
- Comverse - Comverse Data Management & Monetization: Accelerate Data Profitability and Market Innovation! - http://www.comverse.com/mobile_internet_hub_white_papers_reports_and_ articles
- Accenture - Six Questions Every Telecommunications Senior Executive Should Ask About Cloud Computing - http://www.accenture.com/SiteCollectionDocuments/PDF/Accenture_Six_ Questions_Telecommunications_Cloud_Computing.pdf
- Michael Hugos - Cloud Computing is the Future of Telecom - http://blogs.cio.com/cloud-computing/16501/cloud-computing-future-telecom
- Dave Michels - Cloud Computing for Telecom? Why Now? - http://www.ucstrategies.com/unified-communications-strategies-views/ cloud-computing-for-telecom-why-now.aspx
- Sun CTO - Cloud computing is like the mainframe - http://itknowledgeexchange.techtarget.com/mainframe-blog/sun-cto-cloud-computing-is-like-the-mainframe
What is M2M?
M2M stands for Machine to Machine communication which is more or less self-explanatory however for a more formal definition we can say that M2M means solutions that allow communication of geographically distributed autonomous systems that use the communication channels automatically.
M2M solutions are usually using dedicated platforms built for special purposes: For example a typical M2M solution is a home alarm system that automatically calls a phone number when unauthorized entry is detected. Another example is an application server collecting information from a group of sensors that are installed just for supporting that particular application that is running on that particular server.
What is IoT?
IoT stands for Internet of Things and means the interconnection of any kind of devices for any kind of application. Let’s imagine a world-wide public network of machines like the world-wide public network of personal computers, smart phones and web servers that currently form the Internet. In a global network of things like this a sensor could be accessed by several application servers while an application server could control different types of sensors owned and operated by different organizations forming a fully meshed architecture.
For example, sensors could be different types of utility meters (water, gas, electricity etc.) owned by different utility companies, condominiums or property owners: My water meter can be accessed by the water supply company, the condominium my apartment belongs to and by me with different access rights through different applications.
There are several initiatives trying to define platforms/protocols/standards for IoT, and at this point of time we cannot say yet which one will grow to be the winning standard accepted and followed by the majority of manufacturers and developers.
What will next generation IoT devices look like?
Are current smart phones real IoT devices? Based on what I wrote above you may say no, because
mobile phones are used by individuals to support their communication with other individuals (phone/video calls, chat, e-mail etc.) or with applications (Google Maps, Waze, Web services). However mobile phones are doing a lot of things in the background the user is not aware of. E.g.: A mobile phone may continuously report its position to a Map application in the background even if those reports are not needed for serving the user/owner of the phone. The information is used by machines for serving other users. Taking this into consideration too, a mobile phone should be considered as a real IoT device.
There are studies forecasting the number of IoT devices to grow up to 50 billion by year 2020. Most of these devices are going to be cheap battery powered sensors with very special communication needs that differ from what current service provider networks (like mobile 3G) are designed for.
The key challenges of IoT solutions are - addressing of billions of devices, - routing between billions of nodes, - distributed cloud computing for billions of devices, - offering Low Power Wireless Access for data communication, - providing security on constrained devices.
Will IoT be a public infrastructure?
If IoT becomes a global standard defining all communication layers of the OSI model (from the physical layer up to the application layer) communities will interconnect their systems and form a world-wide network like what we call now Internet. Even if a sensor network is private it will have to be connected to that public IoT network since that will be the cheapest way for interconnecting different segments of the private network. Privacy can be kept by means of tunneling protocols and firewalls.
Who will operate the public IoT infrastructure?
After having a public interconnected community based IoT infrastructure, there is only one step ahead to reach a point, when Communication Service Providers (CSPs) start offering new IoT access services to the mass market.
Like in case of Internet that is divided into Autonomous Systems (AS) operated by Network Service Providers (NSP) who interconnect their network at certain Internet eXchange points (IX) and where the access to that global network is offered to end users by Internet Service Providers (ISP), IoT will have its own hierarchy.
The appropriate entities could be called NoTP, IoTX and IoTSP. I let you guess what the acronyms stand for. :-)