Category: Case Studies

In-Building Coverage

Executive Summary

Less than 5% of commercial buildings have In-Building Wireless (IBW) solution installation.  Without In-Building wireless installation, property managers, owners, and builders are missing an opportunity to increase profits through attracting modern, mobility-favoring tenants. The easiest way for a property to miss out on revenue is to lose tenants to turnover, or worse, not to get them in the first place. To get them in the door, your property must be well-maintained in your tenants’ eyes, and your operations staff must be able to work efficiently throughout your property to make this happen. These needs hinge on mobile connectivity, an area in which many properties are lacking. You already provide utilities (water, energy) and amenities (parking, workout facilities), but you may not be aware of In-Building Wireless, a compelling way to attract and retain tenants in our technology-centric era.

With 5G for IBW, new forward looking architecture and solutions are getting developed which will integrate/support emerging IoT applications and smart solutions better. So, IBW solution options must be evaluated with forward looking requirements and proper lifecycle management & tenant support that improves property values with improved customer experience.

Why In-Building wireless?

Poor cellular reception affects everyone. With the growing demand for faster speeds, degraded voice and media quality, increased demand IoT (Internet of Things) devices, having quality cellular service at all times is an absolute requirement for work efficiency and satisfaction:

  • Are people complaining about poor cellular coverage indoors?
  • Does it hamper workflow & productivity?
  • Are people getting near a window or going outside to make a call?
  • Are these liability issues (such as no signal in an elevator or stairwell)?
  • Use of cell-phone in poor indoor coverage has higher health affects as cell-phone has to work harder to transmit its signal to cell-tower

In a survey of business tenants, two-thirds claimed it would be a major challenge to survive without wireless connectivity. If a business is lacking coverage and can’t survive in their current workspace, they have two options: find a new space to lease or pressure the owner to fix the problem.

Market studies have exposed a driving need for improving In-Building Wireless(IBW) communications, noting that:

  • Mobile traffic has increased massively and will continue to grow
  • 80% of all data funneled to mobile devices is being consumed indoors, and
  • more than half of large U.S. offices have noticeably poor indoor cellular reception

Most properties are not exempt from the problem of poor IBW coverage. Three out of four enterprise tenants reported that employees had to move around the building or go outside to find good reception. With an IBW system, your tenants can be more productive (voice calls & email), more engaged (video collaboration & instant messaging), more efficient (building automation), more entertained (Netflix & Facebook), and safer (911 & public safety).

Poor wireless coverage can be extremely inefficient for building operations staff when they need to work in traditionally poor coverage spaces, like a basement, stairwell, or interior room.

Benefits of In-Building Wireless solution:

In-Building wireless (IBW) system is a growing solution for many businesses to improve their wireless communication infrastructure. It provides augmented & ubiquitous network coverage for all mobile devices. It remedies the causes & problems of poor In-Building cellular service. Whether in an urban or rural area, getting poor signal because of cell tower distance or building material, IBW systems provide constant, reliable network coverage with no interruption to work, entertainment, and/or emergencies.

IBW systems are scalable, able to serve small commercial buildings & SMBs (small medium businesses) to large venues such as stadiums, airports, and convention centers.

  • Better property values
  • Better reputation by customers (Starbucks-WiFi is known to attract more business) and competitors
  • Better efficiency – real-time control and monitoring. Enabled real-time smart building control and monitoring. Changes in building construction standards including more green building technology. AR/VR applications, better shopping experience, improved office work-flows, Real-time applications
  • More federal & local public safety requirements
  • BYOD & Multi-Tenant solution
  • Better Security & Surveillance – smart security cameras (face recognition)
  • Improved Voice and Media experience – better quality video & voice

Who is responsible for In-Building coverage?

Unfortunately, it is often unclear who exactly is responsible for improving indoor connectivity. Most building professionals place the responsibility on the mobile network operators to solve the problem, but in most cases, it is the property owner’s responsibility to deal with this issue.

For property owners, there are several common roadblocks to implementing an IBW system (1):

  • The cost of the network,
  • The complexity of the technology, and
  • A lack of skilled workers to manage the system

The Mobile Network Operator (MNO)

Mobile Network Operators, also known as wireless carriers (think Verizon, AT&T, Sprint, T-Mobile) have all paid substantial FCC license fees for exclusive access to and control of specific radio spectrum in a given geography. Because of this ownership, carriers require any IBW system to be approved and retransmission of their spectrum authorized prior to connection to their mobile network.

Obtaining this approval involves knowing the right carrier personnel and processes; therefore, when pursuing the implementation of a carrier-involved IBW system, it’s best to engage an experienced supplier with established MNO relationships.

One-MNO IBW Vs multi-MNO IBW installation is an important cost and strategic factor that needs to be decided by building owners. Multi-tenant buildings requiring BYOD (Bring Your Own Device) device support should consider multi-MNO indoor coverage solutions. Shopping malls, Airports, Stadiums, Hotels, Office buildings are good examples of such installations.

Whom to contact for IBW efforts?

There are multiple factors to consider in deciding whom to contact for IBW efforts. There is no one-size fits all IBW solution unfortunately.  Also IBW-solution should not be considered in isolation. It needs to be considered in broader context on “5G in Enterprise” strategy and planning.  With 5G, Enterprise is going to deal with Wireless in three broad dimensions:

  • Enterprise Mobility Strategy – Is it BYOD (bring your own device) or single carrier
  • Enterprise-IoT strategy – What IoT, AR/VR and real-time monitoring and control requirements do you have?
  • In-Building Wireless coverage – First step is to study relative signal strength of each Mobile Network in building and evaluate “gaps” based on what is needed Vs current status

Based on overall smart-building & 5G strategy for Enterprise/building-owner, IBW-solution must be developed. One-MNO or Multi-MNO IBW-solution is another consideration. Whenever BYOD needs to be supported, it is important to choose multi-MNO solution for IBW. Also, city regulatory requirements, especially public-safety requirements, must also be considered.

Based on vertical segments, considerations for IBW could be different:

  Vertical Vendor Relationship & Funding Model
1 Industrial Neutral-Host  / MNO / Private-LTE Vendor MNO-funding can be explored if MNO option is used as a vendor. Need to look at comprehensive IIoT solution with IBW as one component.

Enterprise-funded Neutral-Host for Multi-MNO solution or private-LTE vendor for CBRS or Multifire based Private-LTE+WiFi can be considered.
2 Ports, Airports, Sports & Convention Center MNO MNO may be interested in signing agreement in deploying MNO-paid IBW solution. Building owner must consider future IoT applications and IBW solution requirements as well.
3 Retail Neutral-Host Neutral-Host vendor should be asked to do assessment and then contact all MNOs for IBW solution support, relationship and funding.  Deployment can be best achieved as Managed-IBW Services agreement with Neutral-Host vendor. Must consider Smart IoT Apps, AR/VR together with IBW. Tenant Services and rules for additional wireless capability must be managed
4 Office-Building Neutral-Host One-MNO or Multi-MNO depending on single-tenant Vs multi-tenant criteria and Building Owner ROI can be considered; Rental value improvement with better IBW, Tenant Services and rules to manage RF-interference must be managed. Comprehensive plan of IoT applications requirements and IBW solution requirements must be considered.
5 Health-Care & Hospitals Neutral-Host Multi-MNO preferably. Funded by Enterprise with minimal expectation of funding by MNO. Deploy as managed-IBW services with multi-year contract and performance definitions.  Comprehensive plan for IoT-application requirements and IBW solution requirements must be considered.
6 Oil & Gas MNO + Neutral-Host Oil & Gas assets are typically geographically dispersed. Given this situation, MNO partnership is desirable for geographically distributed assets. For In-Building assets, it may be desirable to use private-LTE network or Neutral-Host solution. Comprehensive plan with proper consideration for IoT applications must be considered together with IBW solution effort.
7 Education Neutral-Host Large Universities (like NYU or Stanford) want to have good In-Building Wireless coverage along with good WiFi solution. Multi-MNO solution is desirable. Interest of MNO in these opportunities could vary. They may be interested in partial funding. Managed-IBW service model is desirable. Comprehensive plan for IoT applications and IBW solution must be considered instead of separate efforts.
8 Government Neutral-Host or MNOs For public safety, AT&T (FirstNet) will be used. It is likely that other MNOs may offer lucrative terms for IBW solution.  Some Govt business may consider Neutral-Host companies for managed services. Comprehensive plan must be created for IoT-applications, Mobility requirements and IBW solution
9 Defense Private-LTE and Neutral-Host A lot of defense bases are much like cities and require multi-MNO solution for personal traffic and private-LTE for official traffic. Comprehensive plan of IoT-applications and IBW solution requirements must be considered.
10 Transport, Logistics, Automobiles Multi-MNO, Relay, Neutral-Host Connected-Car is a very large business opportunity for every MNO. Each MNO wants “exclusive” relationship. However best option is to develop multi-MNO capability, preferably via Neutral-Host type services company

 IBW Coverage

 It’s important to understand where connectivity is needed within your property, since the entire building may not require coverage from all carriers. A simple assessment survey performed by a reputable integrator can give you an idea of the current baseline coverage your property receives from surrounding outdoor cell sites and what it would take to fill in any holes in coverage.

For Wi-Fi services, installation of equipment is relatively simple because the building owner has complete control of the system, meaning no outside approvals are necessary. However, complexity enters the equation when:

  • Each tenant provides their own Wi-Fi coverage— bringing poor signal quality due to RF interference, or
  • The property owner installs one shared Wi-Fi system—bringing complexity in creating secure, segmented, and controlled connections for each tenant.

Wireless Coverage Rating system (WCRS)

A standard way to rating indoor wireless coverage will help a lot in marketing and monetization of IBW investments.  As an example – WCRS-rating will help hotels in marketing the quality of their wireless coverage and attract more customers with potentially higher room rents.

 Steps for IBW deployment

Step-1:  IBW requirements assessment

How do you know if In-Building Wireless is a good fit for your building needs and what is needed to get this implemented?

As a first step of improving In-Building wireless coverage, building owner needs to perform “professional” In-Building Wireless coverage assessment.

New Building – For new-buildings, this step can be skipped and go directly to IBW planning effort.

Existing Buildings – First step is to hire a professional firm for In-Building assessment. There is no one-size fits all type of solution for In-Building Wireless services even in same vertical market.  A lot depends on location of building as well. In our view, every commercial building should be rated for In-Building coverage through some sort of a color-scheme per MNO. We provide this service to our customers at a very competitive price.  If Enterprise has multiple building in many cities, city-level planning for IBW-solution assessment is recommended. In-Building assessment should, also, cover recommendation for achieving good In-Building Coverage and cost estimate for different options.

Mobilestack offers IBW assessment services to building owners. Contact us for more details.

Step-2: IBW Solution Planning

New Building – For new buildings, this needs to be done as part of construction planning much like electricity plan is developed even if In-Building wireless solution is deployed much later. By doing it as part of construction planning, re-work after construction for In-Building wiring, power and cable installation cost is minimized making IBW-solution cheaper to deploy or/and scale.  Installation of In-Building data/optical fiber wiring after building construction is costly.  Comprehensive smart- building,  IoT application requirements, data cabling plan, Edge Solution requirements and IBW solution requirements must be considered as a roadmap. This will avoid any significant future re-work which may be costly to implement.

Existing Building – Detailed planning of IBW solution is needed including funding options, role of MNOs, performance expectations after deployed solution and pricing options for building owner. Also, planning proposal should include life-cycle management, rules for tenants to avoid RF-interference, upgrade options as new IoT applications are added by building owner.  MNO partial funding options and support must also be considered as part of this IBW solution planning.

Mobilestack offers IBW planning services to building owners. Contact us for more details.

Step-3:  IBW Build Phase

In this phase, In-Building Wireless solution is deployed as per approved IBW-plan in step-2 above.  Before Vs after IBW-deployment wireless coverage and customer experience impacts must be measured to ensure that IBW solution is meeting its objectives.  One important benefit of In-Building solution deployment is improvement in real-time application such as voice calls, video calls and, in future, AR/VR solution experience instead of just data-throughput benefit which is often used for measurements. Another important experience improvement parameter is better support for cellular connection density.  More device or people at one location or room should be able to use cellular services simultaneously. Again this KPI is often ignored by many vendors and must be counted.

Mobilestack offers IBW deployment and managed services to building owners. Contact us for more details.

Step-4: IBW Monitoring and Control

IBW solution is not build & forgets type of solution deployment.  Continuous monitoring and control of In-Building coverage & network-security must be followed.

Ongoing IBW network monitoring and management can come in several different ways. To gain MNO’s trust and confidence will be hard for building owner or its technical staff. Best option is to use managed services to continuously monitor and manage IBW solution. Alternatively, monitoring can be done by building owner and out-source control & management function as managed services preferably to same company who has deployed IBW solution.

Mobilestack offers IBW monitoring and managed services to building owners. Contact us for more details.

Step-5: IBW solution lifecycle management

IBW solution must be deployed in a way that it is easy to update, scale and modify. Future looking deployments that are compliant to newer technology and industry interfaces is better instead of adopting older IBW technology which will become obsolete quickly and affect future growth or value improvements. In Wireless industry, technology obsolescence rate is very high and new technology is developed every 6 to 8 years. Rate of evolution is going to become faster as IBW-solution becomes software-only solution using re-configurable future-proof hardware.

Upgrade path to adoption new technology faster should be important and provide better TCO in long-term. TCO considerations Vs future upgrade requirements must be in proper balance.

New innovative business models for lifecycle management and upgrades are developing for IBW-solution using newer technologies. This will make IBW-managed services offered at predictable monthly cost for a long period of time possible instead of cost + services pricing model.

Mobilestack offers IBW lifecycle and managed services to building owners. We take care of all hardware and software changes without any change in monthly cost. Contact us for more details.

IBW Solution Options

In-building wireless comes in a few different flavors, but the goal remains the same: wirelessly connect tenants, guests, and other building occupants to the network services and software applications that they want and need. Whether it’s in an apartment building, commercial office building, hotel, healthcare facility, school, mall, or public building, everyone now depends on reliable mobile connectivity where they work, live, learn, shop, and play.

Active DAS

Active DAS provides boosted 4G LTE cellular coverage for buildings. Active DAS works by directly connecting to carrier networks. Digital signal feed from operator is carried through fiber optic to maintain signal integrity regardless of cable run and coverage area.

Active DAS is best-in-class in terms of signal boosting and coverage range. Mobilestack can facilitate this connection management between operator and building owner. Since Mobile Operator wants control on digital feed that is provided for In-Building coverage instead of giving up control to building owner, Operators prefer a relationship with neutral host managed service provider.  Given Mobilestack’s domain expertise in RAN products and trusted relationship with Mobile Operator, we can offer IBW managed services to building owners and partner with Mobile Operator (MNO) for digital feed and its management by working closely with MNO’s RAN operational management team.

New digital feed interface standards are getting developed as part of industry-forum efforts. It is likely that Active-DAS could become cheaper in future as solution migrates to commodity future-proof hardware supporting Active-DAS as software-only solution working closely with MNO’s Base-Band processing unit (RAN-BBUs).

Passive DAS

Passive DAS is a signal amplifier or booster which picks-up weak signal from outside the building (preferably best location outside building) to amplify and distribute indoors as-is. This is a simple device and cost-effective option. For small buildings, this may be a reasonable option to consider. This solution is a single-MNO solution suitable for smaller capacity buildings.

However, for large buildings with future requirements of smart-building and IoT-applications or AR/VR support, this solution will not be a good fit.

Public Safety requirements can also be addressed using this kind of solution.

Cell Relay

Cell relay node (RN) concept was introduced in 3GPP release 10 to solve performance issues like the reduced data rate, the weaker signal and the higher interference encountered on the radio coverage edges by expending the covered zone and increasing the capacities of the radio coverage both indoor and outdoor at a lower cost. RN is connected to a macro eNodeB (basestation in LTE) called Donor eNodeB (DeNB) using a radio interface.  For a Donor eNB, the relay node appears as a UE. By creating its own coverage zone, the RN appears as a eNB to the UEs. LTE-A relay node, are designed to be low cost and lower power nodes which can be easily and quickly deployed when needed. If Mobile Operator supports RN-technology then this is a good choice to improve indoor coverage rapidly at lower cost.

This solution may work for boosting operator’s signal for public-safety applications and portable MNO-signal booster inside buildings.

New innovative solutions using cell-relay technology are getting developed for future use & installation in transport system, railways & autos to boost / convert MNO-signal and provide better coverage to passengers.

Small Cell

Enterprise small cell can be deployed to achieve high capacity as well as expand coverage, enabling the voice and data solutions that businesses rely on. The enterprise cell is LTE-enabled and ideal for mid-sized locations. It is effective in hotspots with crowds of people such as shopping malls and especially enterprise. Indoor coverage and capacity expansions are simplified by our Small Cells’ ‘plug & play’ design.

Small cell technology is evolving rapidly with 5G. If carriers can agree on sharing a common base station and/or neutral spectrum, there’s potential for massive growth.

IBW for Public Safety

In an emergency event, fire fighters, police, and paramedics require access to a public safety wireless network and this access requirement does not stop at your building’s front door.

Through adoption or amendments of national or international Fire Codes, many jurisdictions require public safety IBW assessments and/or mandate that In-Building emergency responder Radio Enhancement Systems (RES) be installed in select new or renovated buildings as a prequalification to a certificate of occupancy.

Commercial real estate professionals need to make sure their architect or general contractor considers the need for RES. The building owner is responsible for the RES cost and can contact a wireless systems integrator to guide them through the process.

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 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.

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.

Mobile-Edge Computing

Network Operators’ networks are populated with a large and increasing variety of proprietary hardware appliances. To launch a new network service often requires yet another variety and finding the space and power to accommodate these boxes is becoming increasingly difficult; compounded by the increasing costs of energy, capital investment challenges and the rarity of skills necessary to design, integrate and operate increasingly complex hardware-based appliances.

Moreover, hardware-based appliances rapidly reach end of life, requiring much of the procure- design-integrate-deploy cycle to be repeated with little or no revenue benefit. Worse, hardware lifecycles are becoming shorter as technology and services innovation accelerates, inhibiting the roll out of new revenue earning network services and constraining innovation in an increasingly network-centric connected world.

Network Functions Virtualisation aims to address these problems by leveraging standard IT virtualisation technology to consolidate many network equipment types onto industry standard high volume servers, switches and storage, which could be located in Datacentres, Network Nodes and in the end user premises. We believe Network Functions Virtualisation is applicable to any data plane packet processing and control plane function in fixed and mobile network infrastructures.

We would like to emphasise that we see Network Functions Virtualisation as highly complementary to Software Defined Networking (SDN). These topics are mutually beneficial but are not dependent on each other. Network Functions can be virtualised and deployed without an SDN being required and vice-versa.

Virtualising Network Functions could potentially offer many benefits including, but not limited to:

  • Reduced equipment costs and reduced power consumption through consolidating equipment and exploiting the economies of scale of the IT
  • Increased speed of Time to Market by minimising the typical network operator cycle of innovation. Economies of scale required to cover investments in hardware-based functionalities are no longer applicable for software-based development, making feasible other modes of feature evolution. Network Functions Virtualisation should enable network operators to significantly reduce the maturation
  • Availability of network appliance multi-version and multi-tenancy, which allows use of a single platform for different applications, users and tenants. This allows network operators to share resources across services and across different customer
  • Targeted service introduction based on geography or customer sets is possible. Services can be rapidly scaled up/down as
  • Enables a wide variety of eco-systems and encourages openness. It opens the virtual appliance market to pure software entrants, small players and academia, encouraging more innovation to bring new services and new revenue streams quickly at much lower

To leverage these benefits, there are a number of technical challenges which need to be addressed:

  • Achieving high performance virtualised network appliances which are portable between different hardware vendors, and with different
  • Achieving co-existence with bespoke hardware based network platforms whilst enabling an efficient migration path to fully virtualised network platforms which re-use network operator OSS/BSS. OSS/BSS development needs to move to a model in-line with Network Functions Virtualisation and this is where SDN can play a
  • Managing and orchestrating many virtual network appliances (particularly alongside legacy management systems) while ensuring security from attack and
  • Network Functions Virtualisation will only scale if all of the functions can be
  • Ensuring the appropriate level of resilience to hardware and software
  • Integrating multiple virtual appliances from different vendors. Network operators need to be able to “mix & match” hardware from different vendors, hypervisors from different vendors and virtual appliances from different vendors without incurring significant integration costs and avoiding lock-in.

The authors of this white paper believe (and have in some cases demonstrated) that solutions to these technical challenges are available, or could be made available, and recommend that the IT and Networks industries combine their complementary expertise and resources in a joint collaborative effort to reach broad agreement on standardised approaches and common architectures which address these technical challenges, and which are interoperable and have economies of scale.

To accelerate progress, a new network operator-led Industry Specification Group (ISG) with open membership is being setup under the auspices of ETSI to work through the technical challenges for Network Functions Virtualisation as outlined in this white paper. The formal creation process of this ETSI ISG has been started and is expected to be completed by mid-November 2012.

In order to chart the way forward for Network Functions Virtualisation the wider industry is asked to provide feedback as detailed in this white paper.