Tag: LTE

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 Products from Mobilestack Inc

Mobilestack 5G Products using future-proof Hardware

Introduction

Future Proof 5G products are needed to reduce network cost with faster upgradability.  Hardware-Software separation provides cost efficient 4G/5G Network Equipment cost model that is desperately needed to reduce “total cost of ownership” for deploying 4G / 5G service. Mobilestack Inc provide 5G RAN software running on future-proof radio-network hardware.

RAN Hardware – Software separation

Given that MNOs margins are getting squeezed, Mobilestack wants to give complete ownership and independence to MNOs for RAN Hardware that is based on open hardware standards similar to “Open Compute Project” from facebook which help reduce cost of datacenter hardware by 50%. As of now, XRAN is considered to be the main focus for OPEN-RAN strategy.  However, I doubt that XRAN option is a good one because same vendor solution at BBU (RAN Base-Band Unit)  and RRU (RAN Remote UNIT) will always perform better.  No incumbent RAN vendors (such as Ericsson, Nokia, Huawei and other) want to give-up control on RAN-HW. If MNOs want to change the direction of this industry then they need to spend in new RAN startups like Mobilestack who are committed to support this architecture as part of their core mission and product strategy.

In my view, it is time to place bets on RAN Hardware Neutrality.  If we fail to adopt this strategy in 5G then it may be too late to do it in the future.  Mobilestack is not a hardware company, but we are willing to work with MNOs as a consultant to help them define this future and build open RAN HW ecosystem.

Small Cell 

Small cell is a major part of Network densification.  50% to 70% of small cell CAPEX is in “installation”. As number of small cells grows to millions in a network deployment, small cell hardware replacement is simply not an option.  This is the problem that we need to solve. The solution is to use future proof small cell “commodity” hardware that allows in-field upgrade from 4G to 5G. Commodity HW is the key differentiator here to create a very low cost small cell solution.

Use of future-proof hardware for small cell is business critical. Given that small cell is going to be deployed in millions of locations, hardware replacement cost will be huge and roll-out of new features requiring hardware upgrade will be extremely slow.

Relay Cell

5G relay cells are going to be deployed much like Verizon 5G service today which provide WiFi / 4G LTE inside the building or as local network and use 5G link to the macro / micro / small cell as backhaul.

Use of commodity RAN HW is business critical for this use-case as well. Today, Verizon has used “proprietary HW” with a critical need to upgrade when 3GPP compliant 5G Relay cell is available. Now, consider huge cost of this hardware replacement for Verizon which can be avoided if future-proof Relay-Cell hardware is used with customer replaceable parts for custom hardware if required.

Private LTE Network

Private LTE network create local private LTE network which can be used in many different vertical market use-cases in which “network delay and network coverage” is a huge consideration such as Hospitals, Hotels, Convention centers, Airports, Ports, Industrial complex or Oil & Gas markets.

Again, in these markets, use of commodity hardware and being able to use same hardware for future wireless upgrades will reduce “total cost of ownership” and encourage adoption. Mobilestack Inc is targeting these markets and invite customers to engage with us for trial / PoC demos.

Critical LTE Network

In recent CA fires and other natural disasters such as Puerto Rico,  restoration of Wireless Network is “mission critical” for public safety services and rescue operations.  Every second counts in these restoration efforts to provide help where it is needed and identify / locate people that need help.

This best option in these situations is to provide a portable LTE-solution that can be mounted on public safety vehicles / backpacks (such as fire trucks, Ambulances, FEMA resources) that can be connected to serve any operator's mobile phone / SIM-card.

Mobilestack Inc has developed a portable 3G/LTE-network solution (future upgradable to support 5G as well) to serve these critical needs. We invite customers to contact us for a trial / PoC demo.

Mobilestack Products

MobileStack Product Chart

Mobilestack Inc is creating 5G Products with focus on Hardware-Software separation and use commodity hardware to build 5G products and services. With main focus on Hardware-Software separation is the core differentiation for Mobilestack 5G products.

Customers from many vertical markets can leverage Mobilestack Inc products. We invite customer to contact us for details of our products and services with a trial, PoC as a start.

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:

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.

 

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.

DEMO – Low cost LTE solution and vEPC solution

With a demo of LTE-in-a-box solution, Mobilestack Inc announces the availability of a low cost LTE-in-a-box solution and vEPC Solution. Please contact us for product details and customer trials.

Initial LTE release supports 4G LTE network solution with upgrade path available to 5G.

Possible applications include but are not limited to

  • Public Safety markets – Public Safety requires dedicated LTE-network used exclusively by public safety people. Our LTE-solution can be deployed in emergency vehicles using PC based HW platform to create a dedicated LTE-network on demand to connect emergency staff with each other.  In disaster affected areas, when MNO wireless network is not functional, public safety teams need to setup a wireless network to effectively communicate with other and provide relief where needed. Mobilestack LTE-solution is a good fit for these requirements.
  • Rural markets –  Rural markets have unique requirements and ROI challenges. In such markets, our LTE-network can be installed to provide voice and data services in capital efficient manner.
  • Small Cell markets – This solution can be deployed as a small-cell LTE-network serving in-building LTE-network requirements.
  • IoT / IIoT markets – Our low cost LTE-network solution can be used in several IoT market verticals and test-solution for development. For example – Private IoT network for smart city solution, parking lots, industrial IoT application, private LTE-network for Utilities
  • Test Solution market – Chip developers, device developers and compliance test centers can use our LTE-in-a-box solution as test platform.

Our vEPC Solution can be installed on a GPP hardware (such as PC) or public / private cloud as container-based solution. We are looking for customer trial projects for this product. Please contact us for more details.

Examples of Target applications are

  • vMME, vHSS or vSP-GW Solution in MNO network
  • MVNO vEPC solution on demand deployed in  private cloud or public cloud based on customer requiremets
  • vEPC Test Solution as part of lab LTE-network or Mobile Edge Solution testing

DEMO Details:

LTE demo (video below) explains the demo configuration. As part of virtual-eNB implementation, this demo is using software-based 4G LTE PHY, MAC, RRC and PDCP implementation. SDR-card in the demo is used for LTE-frame modulation / demodulation using digital I/Q stream generated by LTE-PHY running on a PC.

This demo also includes a vEPC solution running on a GPP HW (PC). Our vEPC solution is also available for public / private cloud based deployment using docker / LXD container implementation.

In this live demo, we show LTE-in-a-box network connected over LTE air-interface to two commercial UEs simultaneously with both UEs running a speed test.

PC is running software eNB,  vMME, vHSS and vSP-GW  on top of Ubuntu linux. LTE-stack of this demo supports following features:

  • LTE Release 9 Compliance
  • LTE running in FDD configuration
  • Tested bandwidths: 1.4, 3, 5, 10, 15 and 20 MHz
  • Support for 4×2 MIMO
  • Evolved multimedia broadcast and multicast service (eMBMS)
  • Modular support for MAC, RLC, PDCP, RRC, NAS, S1AP and GW layers
  • Detailed log system with per-layer log levels and hex dumps

Please contact for any questions / feedback that you may have. Your feedback is highly appreciated and helpful in improving our products.