Ten steps of adding LTE to a Wearable?

Adding LTE to a Wearable is not as easy as adding Bluetooth to a Wearable. Mobilestack Inc has deep experience in adding cellular technology to a Wearable and launching it in a carrier network. In this article, I want to outline steps for adding LTE / CAT-M / NB-IoT or legacy 2G / 3G wireless technology to a Wearable.

Adding a cellular modem to a wearable is a very different wireless design lifecycle Vs Bluetooth integration into Wearable. In a way, Cellular Modem enabled Wearable is a completely separate category of device Vs Bluetooth enabled device. Bluetooth enabled Wearable design is limited to hardware and software engineering effort to make it work with smartphone application that is optimized to reduce battery consumption as much as possible without compromising on user experience. WiFi connectivity solution is little more complex Vs Bluetooth because of new WiFi-6 design for IoT devices or WiFi AP-setting for wearable device. Still, this is not as complex as adding cellular connectivity solution to a wearable.

Adding LTE to Wearable has many product dimensions and life-cycle steps. Steps involved from idea to launch for adding LTE to a Wearable device are as follows:

Step-1: Product Requirements Definition:

Requirements definition needs to capture answer of following questions:

What is the main business objective of adding LTE to Wearables? What if LTE / CAT-M / NB-IoT coverage is not available at a given location – Is there a need to support 3G/2G as fallback option? Target market? Engage with mobile operators in target market for Wearable support and develop business case for operator support and technical requirements. New device features such as device management requirements, SIM Vs eSIM, Firmware update, Device security, Supply chain impacts, Number sharing, Voice Support, Text Message support are good examples of device requirements that must be considered.

Mobilestack Inc is very familiar with details of device requirements and pros/cons of different features that must be planned for IoT device development.

Step-2: Wireless Technology Choices

Based on device requirements, Wireless Technology choices must be made.

Band support:- Which RF bands are supported by target device. It is not feasible to add all RF bands and device OEM may be required to pick and choose. This choice will define the global footprint in which OEM device will potentially work. In other areas (not supported by RF-bands of Wearable), only Bluetooth or WiFi will work and Cellular modem has to be disabled.

Wireless Technology Choice – There are few options to be considered: LTE-Only, LTE/3G/2G, CAT-M Only, CAT-M / NB-IoT, CAT-M / 3G, NB-IOT/3G, CAT-M/NB-IoT/3G etc.

SIM technology and form-factor choice – One major decision is SIM Vs eSIM. How about SIM-Swap support? What SIM form-factor is best suited – such as Industrial grade embedded, Commercial-grade Embedded SIM or Removable SIM?

Mobilestack Inc has deep expertise in wireless technology choices and we can help customers in this step.

Step-3: Planning

Detailed planning is needed including discussion with all stakeholders- Sales, Supply Chain, Vendors, Mobile Operators as Partners, Engineering, Product Management and Operational teams that will be involved in any new wireless device development, launch, sales and operational processes. New testing and device activation work-flows have to be worked out to create expectation alignment of all stakeholders.

Mobilestack Inc can help customers in planning this project to ensure the success and eliminate cost-overrun due to bad planning.

Step-4: Supply Chain impact and Vendor Selection

By adding Cellular Wireless connectivity, new vendors for wireless module and SIM-card are added as part of supply chain. Also, operator certified Wireless Module + SIM-card must be tested (on operator network or stand-alone) before it is added to a target device. Since most of this supply chain process is done off-shore, there are challenges in achieving smooth process for this step.

There are ways to solve this issue and Mobilestack Inc can help.

Step-5: Product Design

This has two components i.e. Hardware design and software design

Hardware design – Main design considerations are: Antenna Placement, Battery Power Management, Wireless Module integration, SIM-card placement, Battery capacity augmentation

Software design – Power management, always best connected Solution switching between Bluetooth and Cellular, One number solution for Voice, messaging services, Firmware update (FOTA), Device Activation / change in ownership aspects, eSIM / SIM-Management aspects, future-proofing of solution to enable eSIM later-on, User Interface impacts.

Customer experience should be painless and simple for using and activating wearable device. Usability factor will drive customer adoption. Bad usability or complex device activation process will create customer returns of a good working device. This should be considered as key performance indicator of device success among others.

Mobilestack Inc has deep expertise in Wireless Design and Engineering services.

Step-6: Development

Execute on Wireless design identified in step-5 above. Development should use agile development process with measurable progress and DevOps development model for frequent integration testing.

Mobilestack Inc offers cost-effective Wireless Connectivity Design and Development Services to achieve faster time-to-market for our customers.

Step-7: Testing

System level testing must be done after development is completed with focus on automation as much as possible. Also, field testing must be included as part of this testing in which device is tested at multiple different locations with specific focus on edge cases such as roaming (specially new device activation in roaming), coverage edge of 4G and 3G etc. Mobile Operator resources can be used for field device testing.

Mobilestack Inc has expertise in creating test-plans (or advice customers on test-planning) and actual testing of wireless devices.

Step-8: Device Certification

In this step, device is submitted to different device certification centers that are approved by Mobile Operators including any in-house device testing by Mobile Operator. Not all operators require in-house device certification testing. So, as part of device planning step, Device certification plan must be developed and executed as part of this step. Before device launch, as part of pre-launch testing, Mobile Operator requires test-devices in large number for internal testing by different stakeholders including network operation team and regional / nation-side device sales and marketing channels.

Step-9: Device On-boarding process

For launch, Operator defined device on-boarding process must be followed. This includes submission of millions of manufactured devices identity (IMEI) and SIM-card identity (ICCID) details of devices (going on future sale) to Operator for proper provisioning or device on-boarding. It is best to integrate this process as part of supply chain of Device Manufacturing process. In the case of e-SIM based development, this process will be slightly different.

Mobilestack Inc can help navigate this process for our customers.

Step-10: Launch

Congratulations for reaching on the finish-line. First few days of launch should be spent in a device launch war room to help operators and all different sales channel trouble-shooting and support. This is the most rewarding phase of project and smooth launch will help elevate device OEMs image in the marketplace.

After a month of launch, Device OEM can do a project post-mortem analysis to identify lessons learnt during this journey for future improvements. Smooth device launch and good customer reviews help in building Device OEM’s brand equity. All efforts must be made to make launch successful in a timely manner specially around Nov-Dec timeframe when alot of OEMs are trying to launch their device and Mobile Operators are always very busy.

Contact us

Please reach out to contact at Mobilestack.com for any feedback, comments or questions. Fill up the contact form.

5G Infrastructure Pillers for Network Densification

5G race has already started. There is talk of USA vs Pacific (China / Japan / S. Korea) competition for this race. What is needed to deploy 5G quickly to win the race?

Until now, Mobile Operators have grown their network independently. All USA Mobile Operators have their own assets for end-to-end solution with very little network sharing or roaming using other MNO’s network within USA. Given the Network densification requirements, this deployment model is not scale-able.

Cost of network densification is huge and not supported by business case of new revenue generation potential as of now. Given this situation, what are the best 5G Infrastructure Pillers for Densification? I have presented my ideas in this article to start a public debate / discussion for public-private partnership that will help in 5G network densification at a reasonable cost.

Pubic Private Partnership

Several key Public Private Partnership (PPP) 5G infrastructure initiatives can be created to help in 5G network densification. Examples are:

Fiber in the ground

In my view, this is a national strategic asset in which US federal / state governments invest to create digital highways much like physical highways system. This digital asset should be available at very reasonable cost to all stakeholders as part of OPEN Digital Highway Access mechanisms.

Fiber infrastructure is a “shared” strategic asset which can be offered to private partners and operators at very low cost with equal, fair, easy access rules without much bureaucracy involved in getting access. This can be called as “building strategic national asset initiative”. Some of this nation-wide IP-network capacity can also be used for defense, public-safety, rural, Smart City and Government IP-network requirements.

Street Furniture access

It is not feasible to develop separate street furniture locations for each operators with independent fiber infrastructure for each of them. One operator with leadership in Street Furniture access or bigger fiber infrastructure will create “unfair long-term advantage” for that specific Operator and erode revenue opportunities for other operators or smaller ISPs.

There is a need to create fair and equal access rule to Government and street assets that encourage network sharing. Creating separate street furniture access for each operator is not a scale-able and economically feasible option. So, fair and equitable rules for shared site access of street furniture managed by Govt / state / city administration at break-even cost is needed.

Three Pillers of 5G

Create regulatory policy and private-public partnership for deployment of following three pillers of 5G infrastructure building blocks:

  • Smart Building

Every building can have multi-MNO neutral-host and private 5G network deployment build on 5G network architecture principles of virtualization, Hardware-software separation, Network-slicing to ensure low cost in-building solution development and operational models.

  • Smart City

5G plays a key role in building Smart City Infrastructure. Develop new regulatory policies with new investments in Retail, Roads, Utiliities, Public-safety and city-level applications that can be replicated across many cities in a consistent manner.

  • Smart Transport

    Smart Transport 5G deployment and operational models must be developed with an objective of 5-year execution plan using Public-Private Partnership investment models. Every car, truck and public vehicle can deploy a 5G hotspot or relay devices for public / private network access, connected car applications and eventually autonomous applications as a long term plan.

Conclusion

These three 5G deployment pillers with Public Private Partnership will create GDP growth that is projected from 5G investments. Without concrete action plan for 5G investments to create GDP growth, this potential will not be achieved.

Private ownership should be encourages where-ever possible. However, fair and equitable Physical Resources access policy is needed to make sure that unfair advantage is not created for a specific operator via long-term agreements of exclusive use for any public physical resource.

5G business opportunity for Cable Industry

After Verizon launch of 5G Home Connect product, Cable Industry has come under direct competition in their monopolistic ISP market of providing internet services to Home and small businesses. Cable industry needs to create their own 5G product roadmap to counter MNO threat of taking over in-building internet services business.

Mobile Operator’s interest in Home Connect solution is not new. Back in 2G days, Mobile Operators has deployed wireless local loop solution to offer in-building telephony services. Now, with access to mid-band and high-band frequencies and new technology of MIMO and beam-forming, Mobile Operators have the opportunity to offer in-building ISP services and integrate in-building wireless solution as part of their broader out-door network and grow their network coverage in-building. Value-added edge services can be created after substantial foot-print of in-door home-connect customer base is created. With Cable industry investments, Mobile Operators are all set to eat Cable industry’s lunch and make them disappear or redundant. It is kind of do or die situation for Cable Industry.

5G is a wake-up call and golden opportunity for Cable Industry to “finally” create a business growth opportunity which is much more than acting as a simple ISP with flat ARPU. 5G is a transformation technology for in-building services and applications.

Smart Building

Every building can have multi-MNO neutral-host and private 5G network deployment build on 5G network architecture principles of virtualization, Hardware-software separation, Network-slicing to ensure low cost in-building solution development and operational models.

Smart In-building structures is one of three main pillers of 5G infrastructure (refer my article on 5G). Cable Industry needs to take proactive and bold steps to invest in this opportunity.

In-Building Network Standardization

In-door Wireless coverage is becoming critical services much like electricity and water. Without good wireless network coverage, it is hard to building owner to find tenants. Wireless Network availability inside building requires consideration planning and deployment in the same way as plumbing or electrical design planning is done for in-building services. There is a need for “network design” engineers to create in-building wireless and network implementation plan and this needs to become part of building code and green building initiatives.

Conclusion

Mobilestack Inc has the expertise to help Cable Industry in development of 5G product roadmap and development of in-building network standardization efforts. We invite industry stakeholders to connect with Mobilestack Inc and make in-bulding 5G deployment work for Cable Industry advantage and offer new revenue-generating services that are much needed for in-bulding 5G network deployment. Failure to execute on this opportunity is not an option.

5G in India – Need to create new Public Private Partnership Projects

5G race has already started. There is talk of USA vs Pacific (China / Japan / S. Korea) competition for this race. Where does India stand in this race?

India wants to lead in 5G race and created a regulatory policy framework to encourage investments. Is this enough to lead in 5G race? What other initiatives can be started to help lead in 5G race? In recent budget, 5G research funding was approved. This funding is used to buy 5G equipment as “import” vs self-reliance initiatives to build 5G infrastructure. In this article, I present few ideas to help India in 5G race outlined below:

R&D effort

Research and Development (including 240 Crores available) should be used to make India self-reliant. This money should be used as “seed capital” of IITs working closely with industry (or startups via open proposal mechanisms) to create sel-reliance in 5G infrastructure equipment development. Focus should be in development of new research and development initiative that can be commertialized in 2-3 years max with large private operator sponsorship and interest to deploy Indian 5G Equipment. Actively participate in ensuring that projects are successful.

Pubic Private Partnership

Several key Public Private Partnership (PPP) 5G infrastructure initiatives can be created to help in Indian 5G race. Examples are:

Fiber in the ground

Indian Government invest in building national-wide fiber and IP-network which can be offered to private partners and operators at very low cost with equal, fair, easy access rules without much bureaucracy involved in getting access. This can be called as “building strategic national asset initiative”. Some of this nation-wide IP-network capacity can also be used for defense, public-safety, rural, Smart City and Government IP-network requirements.

Street Furniture access

Create fair and equal access rule to Government and street assets that encourage network sharing. Creating separate street furniture access for each operator is not a scale-able and economically feasible option. So, fair and equitable rules for shared site access of street furniture managed by Govt / state / city administration at break-even cost is needed.

Three pillers of 5G

Create regulatory policy and private-public partnership for deployment of following three pillers of 5G infrastructure building blocks:

  • Smart Building

    Every building can have multi-MNO neutral-host and private 5G network deployment build on 5G network architecture principles of virtualization, Hardware-software separation, Network-slicing to ensure low cost in-building solution development and operational models.

  • Smart City

    – 5G plays a key role in building Smart City Infrastructure. Develop new regulatory policies with new investments in Retail, Roads, Utiliities, Public-safety and city-level applications that can be replicated across many cities in a consistent manner.

  • Smart Transport

    Railways and Roads 5G deployment and operational models must be developed with an objective of 5-year execution plan using Public-Private Partnership investment models. Every car and public vehicle can deploy a 5G hotspot or relay devices for public / private network access, connected car applications and eventually autonomous applications as a long term plan.

Conclusion

These three 5G deployment pillers with Public Private Partnership will create $1.4 trillian dollar GDP growth that is projected from 5G investments. Without concrete action plan for 5G investments to create GDP growth, this potential will not be achieved.

Indian policy makers have a choice today. Create an execution plan for 5G growth and investment OR miss out on the 5G race.

Mobilestack Inc can help build these policy initiatives for broader public good. Please contact us if needed to help develop 5G execution strategy for India.

OpenRAN based 5G Products development from Mobilestack Inc

OpenRAN-based LTE-Network Development

Introduction

With the rapid growth of the demands for mobile data, wireless network faces several challenges, such as lack of efficient interconnection among heterogeneous wireless networks, and shortage of customized QoS between services. The fundamental reason for these challenges is that the radio access network (RAN) is closed and inflexible. In this white-paper, we propose development of LTE-network based on OpenRAN, architecture for software-defined RAN via virtualization. It provides open, controllable, flexible and evolvable wireless networks.

OpenRAN-based LTE-network uses an industry defined Common Public Radio Interface (CPRI) to create split-baseband architecture. Mobilestack Inc has developed a quickly installable, portable LTE-network running on a PC or laptop. To prove feasibility, We have a demo of this LTE-Network tested for inter-operability with two commercial LTE devices connected simultaneously.

This low cost LTE-network can be deployed very easily on demand. This solution can be used in Small Cell, Enterprise, public-safety and disaster-relief use-cases.

New LTE Architecture

It is an exciting time for wireless industry as radio-network is becoming software products running on future-proof radio network hardware.  This new openRAN architecture is using software programmable RRU (Radio Remote Units) connected via CPRI-interface to Base Band Units (BBUs) to create LTE RAN-network.

Figure – OpenRAN Architecture

Low cost General Purpose Processing (GPP) hardware can be used to run BBU as native-software or as virtualized software (vBBU). Similarly, software EPC solution can be created as software-only MME, HSS and SP-GW software. This software can be developed as virtualized-EPC (vEPC) solution to create a scalable and flexible EPC-solution.

vBBU and vEPC software can be installed in a flexible manner to solve different use-cases. For example, vBBU and vEPC software can be installed on the same virtualized platform running on a PC to create a portable LTE-in-a-box solution. Mobilestack Inc has created a demo of LTE-in-a-box to demonstrate feasibility of this approach. Refer demo section below for details.

CPRI Interface

The CPRI specification enables flexible and efficient product differentiation for radio base stations and independent technology evolution for RRU and BBU. CPRI-interface focus has been put on hardware dependent layers (layer 1 and layer 2). This ensures independent technology evolution (on both sides of the interface), with a limited need for hardware adaptation. With a clear focus on layer 1 and layer 2 the scope of the CPRI specification is restricted to the link interface only, which is basically a point to point interface. More details of CPRI interface is available as CPRI Specification V7.0.

RRU–BBU split options

LTE baseband processing split between RRU and BBU is being discussed heavily in wireless industry today and this interface split is not settled. Different interface split options are being considered. Refer figure (below) for different options considered for interface split. Different interface split options require different bandwidth, delay and jitter requirement that must be met by CPRI interface. For DoD applications, best CPRI interface split option needs to be defined.

Fig – Interface split options for LTE baseband processing

Demo Architecture

Our demo setup architecture is described in a diagram below:

Figure – Demo-Setup

Current Mobilestack Inc effort and prototype demo is available on YouTube at:

<iframe src=”https://www.youtube.com/watch?v=ZyGyreFG5wI” width=”970” height=”546” frameborder=”0” scrolling=”auto” allowfullscreen> LTE in a Box running on a PC </iframe>

This demo proves feasibility of creating a future-proof radio-network solution. Instead of PC, for higher capacity requirements, Open Compute Platform (OCP) hardware can be used to run multiple instances of BBU. Intel is also creating Network Edge Virtualization (NEV) platform which is also a candidate hardware platform of higher capacity vBBU solution.

Mobilestack Products

 

MobileStack Product Chart

Mobilestack Inc is creating solutions using OpenRAN and vEPC technology. Our focus is to develop multi-radio eNB, EPC and simulated-UE products as shown in product chart above. For more information, Please contact Mobilestack Inc.

Collaborative Mobile Edge Computing in 5G Networks

Mobile applications are adopted and growing for every industry and market segment such as entertainment, business, education, health care, social networking, etc. Increased wireless application adoption is creating growth in mobile data traffic. As a result, Mobile data traffic is predicted to continue doubling each year. To keep up with these surging demands, network operators have to spend enormous efforts to improve users’ experience, while keeping a healthy revenue growth. To overcome the limitations of current Radio Access Networks (RANs), the two emerging paradigms have been proposed:

(i) Cloud Radio Access Network (C-RAN), which aims at the centralization of Base Station (BS) functions via virtualization

(ii) Mobile Edge Computing (MEC), which proposes to empower the network edge.

While the two technologies propose to move computing capabilities to different direction (to the cloud versus to the edge), they are complementary and each has a unique position in the 5G ecosystem.

Fig-1 Mobile Edge Computing

As depicted in Fig. 1, MEC servers are implemented directly at the BSs using generic-computing platform, allowing the execution of applications in close proximity to end users. With this position, MEC can help fulfill the stringent low-latency requirement of 5G networks. Additionally, MEC offers various network improvements, including: (i) optimization of mobile resources by hosting compute-intensive applications at the network edge, (ii) pre-processing of large data before sending it (or some extracted features) to the cloud, and (iii) context-aware services with the help of RAN information such as cell load, user location, and allocated bandwidth. Although MEC principle also aligns with the concept of fog computing and the two are often referred to interchangeably, they slightly differ from each other. While fog computing is a general term that opposes with cloud computing in bringing the processing and storage resources to the lower layers, MEC specifically aims at extending these capabilities to the edge of the RAN with a new function splitting and a new interface between the BSs and upper layer. Fog computing is most commonly seen in enterprise-owned gateway devices whereas MEC infrastructure is implemented and owned by the network operators.
Fueled with the potential capabilities of MEC, we propose a real-time context-aware collaboration framework that lies at the edge of the cellular network and works side-by-side with the underlying communication network. In particular, we aim at exploring the synergies among connected entities in the MEC network to form a heterogeneous computing and storage resource pool. To illustrate the benefits and applicability of MEC collaboration in 5G networks, we present three usecases including mobile-edge orchestration, collaborative video caching and processing, and multi-layer interference cancellation. These initial target scenarios can be used as the basis for the formulation of a number of specific applications.

CASE STUDY: COLLABORATIVE VIDEO CACHING AND PROCESSING

Mobile video streaming traffic is predicted to account for 72% of the overall mobile data traffic by 2019, posing immense pressure on network operators. To overcome this challenge, edge caching has been recognized as a promising solution, by which popular videos are cached in the BSs or access points so that demands from users to the same content can be accommodated easily without duplicate transmission from remote servers. This approach helps substantially reduce backhaul usage and content access delay. While content caching and delivery techniques in wireless networks have been deployed extensively, existing approaches rarely exploit the synergy of caching and computing at the cache nodes. Due to the limited cache storage at individual BSs, the cache hit rate is still moderate.

With the emergence of MEC, it is possible to not only perform edge caching but also edge processing with artificial intelligence. Our approach will leverage edge processing capability to improve caching performance/efficiency. Such joint caching, processing and artificial intelligence solution will trade off  storage and computing resources with backhaul bandwidth consumption, which directly translates into sizable network cost saving. See figure

Figure – MEC-processing for Video Optimization

Due to the heterogeneity of user-device processing capabilities and the varying of network connections, user preference and demand towards a specific video might be different. For example – Based on terrain information of area based on anonymously-coded location of the user-device and history of data-performance in a certain location, optimum data-rate options for a video streaming to a user can be estimated. AI-enabled MEC Solution can help create a highly differentiated user video experience by an operator instead of simply acting as a bit-pipe. Video content distribution can become integral part of operator network with value-added or localized services based on the location of MEC-server on which video content distribution is running. Example of localized video content at MEC is – Educational content, Local News, Local business information & reviews etc.

Case Study – Mobile Edge Collaboration

In spite of the limited resources (e.g., battery, CPU, memory) on mobile devices, many computation-intensive applications from various domains such as computer vision, machine learning, and artificial intelligence are expected to work seamlessly with real-time responses. However, the traditional way of offloading computation to the remote cloud often leads to unacceptable delay and heavy backhaul usage. Owing to its distributed computing environment, MEC can be leveraged to deploy applications and services as well as to store and process content in close proximity to mobile users. This would enable applications to be split into small tasks with some of the tasks performed at the local or regional clouds as long as the latency and accuracy are preserved. In this case study, we envision a collaborative distributed computing framework where resource-constrained end-user devices outsource their computation to the upper-layer computing resources at the edge and cloud layers. Our framework extends the standard MEC originally formulated by ETSI, which only focuses on individual MEC entities and on the vertical interaction between end-users and a single MEC node. Conversely, our proposed collaborative framework will bring many individual entities and infrastructures to collaborate with each other in a distributed system. In particular, our framework oversees a hierarchical architecture consisting of:

  1. end-user, which implies both mobile—and static—end-user devices such as smart phones, sensors, actuators,
  2. edge nodes, which are the MEC servers co-located with the BSs, and
  • cloud node, which is the traditional cloud-computing server in a remote datacenter.

Our novel resource-management framework lies at the intermediate edge layer and orchestrates both the horizontal collaboration at the end-user layer and the MEC layer as well as the vertical collaboration between end-users, edge nodes, and cloud nodes. The framework will make dynamic decisions on “what” and “where” the tasks in an application should be executed based on the execution deadline, network conditions, and device battery capacity. See figure below for the example of Mobile-edge collaboration use-cases in which AI-enabled MEC can be used.

Figure – (a) Computer Vision Use-Case (b) Health-Care use-case collaboration

In contrast, AI-enabled MEC introduces a new stage of intelligent processing such that the edge nodes can analyze the data from nearby user-devices and notify cloud node for further processing only when there is a significant change in data or accuracy of results. In addition, sending raw-sensor values from end-users to the edge layer can overwhelm the fronthaul links, hence, depending on the storage and compute capabilities of user devices, information processing of other near-by devices and the network conditions, the AI-enabled MEC can direct the user devices to extract features from the raw-data before sending to the edge nodes.

Three software stacks for IoT Solutions

A typical IoT solution is characterized by many devices (i.e. things) that may use some form of gateway to communicate through a network to an enterprise back-end server that is running an IoT platform that helps integrate the IoT information into the existing enterprise. The roles of the devices, gateways, and cloud platform are well defined, and each of them provides specific features and functionality required by any robust IoT solution.

Stack for Constrained Devices: Sensors and Actuators

The “Thing” in the IoT is the starting point for an IoT solution. It is typically the originator of the data, and it interacts with the physical world. Things are often very constrained in terms of size or power supply; therefore, they are often programmed using microcontrollers (MCU) that have very limited capabilities. The microcontrollers powering IoT devices are specialized for a specific task and are designed for mass production and low cost.

The software running on MCU-based devices aims at supporting specific tasks. The key features of the software stack running on a device may include

  1. IoT operating system – many devices will run with ‘bare metal’, but some will have embedded or real-time operating systems that are particularly suited for small constrained devices, and that can provide IoT-specific capabilities.
  2. Hardware abstraction – a software layer that enables access to the hardware features of the MCU, such as flash memory, GPIOs, serial interfaces, etc.
  3. Communication support – drivers and protocols allowing to connect the device to a wired or wireless protocol like Bluetooth, Z-Wave, Thread, CAN bus, MQTT, CoAP, etc., and enabling device communication.
  4. Remote management – the ability to remotely control the device to configure rules or commands, to upgrade its firmware or to monitor its battery level.
  5. Rule based Intelligence – Device can be configured with rules (Intelligence) and thresholds to trigger or act based on parameters monitored by device

 

Fig – IoT Sensor Software Stack

Stack for Gateways: Connected and Smart Things

The IoT gateway acts as the aggregation point for a group of sensors and actuators to coordinate the connectivity of these devices to each other and to an external network. An IoT gateway can be a physical piece of hardware or functionality that is incorporated into a larger “Thing” that is connected to the network. For example, an industrial machine might act like a gateway, and so might a connected automobile or a home automation appliance.

An IoT gateway will often offer processing of the data at the ‘edge’ and storage capabilities to deal with network latency and reliability.

IoT gateways are becoming increasingly dependent on software to implement the core functionality. The key features of a gateway software stack include:

  1. Operating system – typically a general purpose operating system such as Linux.
  2. Application container or run-time environment – IoT gateways will often have the ability to run application code, and to allow the applications to be dynamically updated. For example, a gateway may have support for Java, Python, or Node.js.
  3. Communication and Connectivity – IoT gateways need to support different connectivity protocols to connect with different devices (e.g. Bluetooth, Wi-Fi, Z-Wave, ZigBee). IoT Gateways also need to connect to different types of networks (e.g. Ethernet, cellular, Wi-Fi, satellite, etc.…) and ensure the reliability, security, and confidentiality of the communications.
  4. Data management & Messaging – local persistence to support network latency, offline mode, and real-time analytics at the edge, as well as the ability to forward device data in a consistent manner to an IoT Platform.
  5. Remote management – the ability to remotely provision, configure, startup/shutdown gateways as well as the applications running on the gateways.
  6. Rule Based Intelligence – provides rules on data-processing events and acting on events/data based on threshold based rules configured and running on gateways.

Fig – IoT Gateway Stack

IoT Gateway satck can be combined with NB-IoT or CAT-M or LoRA wireless access-point to create an IoT-network solution.

Stack for IoT Cloud Platforms

The IoT Cloud Platform represents the software infrastructure and services required to enable an IoT solution. An IoT Cloud Platform typically operates on top of Openstack or Container Cloud platform running on Server-HW and is expected to scale both horizontally, to support the large number of devices connected, as well as vertically to address the variety of IoT solutions. The IoT Cloud Platform will facilitate the interoperability of the IoT solution with existing enterprise applications and other IoT solutions.

The core features of an IoT Cloud Platform include

  1. Connectivity and Message Routing – IoT platforms need to be able to interact with very large numbers of devices and gateways using different protocols and data formats, but then normalize it to allow for easy integration into the rest of the enterprise.
  2. Device Management and Device Registry – a central registry to identify the devices/gateways running in an IoT solution and the ability to provision new software updates and manage the devices.
  3. Data Management and Storage – a scalable data store that supports the volume and variety of IoT data.
  4. Event Management, Analytics & UI – scalable event processing capabilities, ability to consolidate and analyze data, and to create reports, graphs, and dashboards.
  5. Intelligence based on Data Analytics – Rules based intelligence based on analyzed / consolidated data
  6. Application Enablement – ability to create reports, graphs, dashboards, … and to use API for application integration.

Fig – IoT Cloud Platform

Cross-Stack Functionality

 

Across the different stacks of an IoT solution are a number of features that need to be considered for any IoT architecture, including:

  1. Security – Security needs to be implemented from the devices to the cloud. Features such as authentication, encryption, and authorization need be part of each stack.
  2. Ontologies – The format and description of device data is an important feature to enable data analytics and data interoperability. The ability to define ontologies and metadata across heterogeneous domains is a key area for IoT.
  3. Development Tools and SDKs – IoT Developers will require development tools that support the different hardware and software platforms involved.

Key characteristics for IoT Stacks

There are some common characteristics that each IoT stack should embrace, including

  1. Loosely coupled – Three IoT stacks have been defined but it is important that each stack can be used independently of the other stacks. It should be possible to use an IoT Cloud Platform from one supplier with an IoT Gateway from another supplier and a third supplier for the device stack.
  2. Modular – Each stack should allow for the features to be sourced from different suppliers.
  3. Platform-independent – Each stack should be independent of the host hardware and cloud infrastructure. For instance, the device stack should be available on multiple MCUs and the IoT Cloud Platform should run on different Cloud PaaS.
  4. Based on open standards – Communication between the stacks should be based on open standards to ensure interoperability.
  5. Defined APIs – Each stack should have defined APIs that allow for easy integration with existing applications and integration with other IoT solutions

Conclusion

IoT Solution is an integration and system development project using COTS HW as much as possible and different IoT software pieces to create a vertical end-to-end solution for deployment or trial.

SDN TEST LEAD

Required skills

Proven automation using scripting languages like PERL/Python, test plans.

Cloud infrastructure and software-defined networking (SDN) domain, Linux layer 2 and 3 networking internals.

Experience in testing of High Availability SDN Controllers Should have worked on KVM/QEMU hypervisor environment, L2/L3 networking concepts like VLAN, MPLS/BGP/L3VPN, Routing Protocols.

Experience in performance and scale testing of routing protocols, IXIA/Spirent gears or other open source testing tools, defining complex network topologies, replicating customer network, Open vSwitch, OpenFlow protocol.

Send your resume to

contact@mobilestack.com

SDN TEST LEAD VIEW

Required skills

Proven automation using scripting languages like PERL/Python, test plans.

Cloud infrastructure and software-defined networking (SDN) domain, Linux layer 2 and 3 networking internals.

Experience in testing of High Availability SDN Controllers Should have worked on KVM/QEMU hypervisor environment, L2/L3 networking concepts like VLAN, MPLS/BGP/L3VPN, Routing Protocols.

Experience in performance and scale testing of routing protocols, IXIA/Spirent gears or other open source testing tools, defining complex network topologies, replicating customer network, Open vSwitch, OpenFlow protocol.

Send your resume to

contact@mobilestack.com