Practical Guide: Deploying an IoT Network
| Wireless | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||
| Sectors | Wireless | ||||||||||
| Contact | David Witkowski | ||||||||||
| Topics |
| ||||||||||
Activities
| |||||||||||
- Authors
Today’s IoT market is already crowded; there is a confusing multitude of IoT connectivity options. However, there are some important ways to distinguish them.
Introduction
For example, some connectivity options operate in the licensed (or regulated) frequency bands, while others operate in the unlicensed or unregulated spectrum. Some options are capable of supporting large amounts of data such as video traffic while others can only transmit very small amounts of data. Meanwhile, some are capable of transmitting over several miles while others are good for a few dozen feet. While many options in the market today will narrow to a more manageable few in the future (as winner and loser inevitably emerge), the reality remains that there is no “one size fits all” or universal connectivity option that will work for all the different use cases a municipal government will face. In many cases, you will need to have multiple connectivity options operating concurrently.
The purpose of this section of the Blueprint is to provide decision-makers with an understanding of the consideration parameters and a roadmap to guide them through the IoT selection process.
Decision Process
Process overview
Figure Eight shows the high-level view of the key decision steps involved in determining the most appropriate IoT connectivity options. The selection of the connectivity option is based on a number of parameters and considerations, which will differ across municipalities. What may be a feasible option for one may not be appropriate or available for another. As an example, urban centers have more options to work with than in rural areas - mostly due to geographic and topographic reasons. At the same time, rural areas have very specific requirements and applications that require a connectivity option that may not be appropriate for most urban areas.
Key assumptions
The IoT connectivity selection process is based on a number of assumptions. These include:
- Each case is unique: There is no “one size fits all” connectivity option that works across all different use cases and municipalities. In many cases, the “best fit” option may be two or three options operating concurrently;
- The “best fit” options are a point in time decision: What works today may not work tomorrow and, as connectivity options come and go, and the underlying technologies improve, the decision considerations may change;
- There is no perfect option for any one situation: The selection process is an exercise in trading off multiple pros and cons of the various considerations; and
- Not all selection choices are available to all decision-makers: Sometimes those decisions are made for you. For example, a telecommunications provider may not serve your geographic area, leaving the “Lease Model” described above as a non-starter.
Key outcomes
The connectivity selection process helps planners and decision-makers navigate a complex set of considerations and options. Some key outcomes include:
- Simplifying options: One major goal of the process is to filter out quickly the unfeasible or unrealistic options immediately. This helps to efficiently focus resources and attention on the few remaining options;
- Holistic decision-making: Even after the filtering process, there may still be multiple options available. The best-fit option is not always about technology and performance. Factors such as ownership, availability, financial, operations, risk, and obsolescence are major considerations that affect which option is selected;
- Decision-making consistency: While the IoT drivers, technology, and management considerations will vary, this process provides a fundamental framework that is relevant today and in the future; and
Supports the business case: No matter what option is ultimately decided upon, a justification or business value case is needed. This process provides the inputs and support that can be used in the development of a business case.
Important Considerations
Use case
The IoT use cases, or applications, drive the initial selection of compatible connectivity options. This initial selection is based on four parameters:
- Indoor use, outdoor use, or both? Different connectivity technologies are required for indoor and outdoor applications. There is some overlap in which indoor technology, such as Wi-Fi, can be used for outdoor applications, but only in very limited situations.
- How much data is being transmitted and how frequently? Continuous video feeds required the most bandwidth while messaging data require the least. Device firmware updates fall somewhere in the middle.
- How far is the data transmitted? This can range from a few feet to tens of miles. As an example, air quality sensors in remote locations send data to a base station miles away, while an indoor thermostat only needs to send data to a wireless access point <20 feet away.
- Do the devices have continuous access to power? The more data being transmitted, the more power is required for the device. Devices without access to continuous power, or lacking the ability to recharge internal batteries, are limited to the type of data they can transmit and connectivity options they support.
Connectivity Coverage
Once a candidate set of connectivity options are determined, municipal planners are faced with a couple of questions. These include:
- Which of these connectivity services are available in the areas or concern?
- Should I buy these services from a third party telecommunications services provider (i.e., Subscription / 5G Model) or should I build my own (i.e., Build and Own Model) or is there some other option available to me altogether (i.e., Exotic Model)?
In the current IoT market, the geographic coverage offered by service providers is limited at best. While telecommunications service providers are actively rolling out IoT connectivity, they often prioritize highly density, metropolitan cores over less populated rural areas. This is unfortunate, but a reality with which we must content. In addition, not all metropolitan areas are served with the full set of IoT connectivity options. Some areas will only have one option, while other markets may have multiple options, such as NB-IoT and LoRaWAN. Finally, even if IoT connectivity service is available in those areas, there may still be coverage gaps within the service area, as service providers may choose for operational or economic reasons not to cover certain areas.
Although the Subscription / 5G Model of utilizing telecommunications operator services will likely be the expedient option for many municipalities, there are situations where the Build and Own Model of designing, procuring, building, and maintaining their own connectivity network may ultimately be a better long-term option. These situations include:
- The desired IoT connectivity service is not provided by any service provider, or the use case devices (or “things”) are not compatible with the service;
- Telecommunications service provider offers partial coverage over the geographic area of interest. A municipality will likely want or require full coverage for the areas not served by the operator;
- Or, a municipality may want indoor coverage for IoT application and find that building a network is better for that purpose;
- Municipal connectivity requirements such as mission critical infrastructure, service levels, resiliency requirements, etc. may not met by a telecommunications operator;
- A municipality may wish to own and operate its own IoT connectivity network for strategic, policy, or economic reasons (e.g., mission critical infrastructure, reduced or eliminated ongoing subscription costs, ability to deploy new services without friction, privacy requirement in place by the municipality, the desire to own and control their own data, etc.);
A very important aspect of the consideration to “subscribe or buy” network coverage, mentioned above, is financial. Municipal leaders and decision-makers must look at the total costs over the lifetime of the network. The total costs comprise the initial equipment and capital costs, the maintenance and operational costs (including people), as well as the projected connectivity costs (associated with provisioning devices onto the network) and in some cases, even the decommissioning costs. Often times, while the capital costs will be much higher, the lifetime costs of building and owning a network can be much lower than leasing service from a provider.
Technology
When deciding between connectivity options, there are a number of technical considerations that must be reviewed. These considerations have alignment to the desired use case, frequency spectrum, security, device support and open versus proprietary networks.
Alignment to Use Case. For every use case or application, there are multiple connectivity options available. Take the example of selecting IoT connectivity for a municipal outdoor air quality sensor network deployed around the community. The amount of information that is transmitted is small (bits) and relatively infrequent (every 15 minutes). There are several feasible connectivity options for this application - NB-IoT, LoRaWAN, and SigFox. However, these options are not the same and have different implications for other (and future) applications that want to use this same connectivity network. These options have different data throughputs, upload/download speeds, range or distance coverage in urban environments, and so on. For example, SigFox has a different throughput up from and down to the device. This asymmetric throughput means that it is not ideal for those cases where the device requires a signal, nor is it possible to update firmware on a device. While the other options have higher data throughputs, they suffer from other constraints. The point here is that there is no “right” or “wrong”, and no “one size fits all” option. The main consideration here is to look deeper at a few of the parameters that matter to understand what the performance capabilities are between the different connectivity options, even if they are initially feasible for a particular set of use cases.
Licensed and unlicensed spectrum operation
IoT connectivity options operate in either the licensed or unlicensed frequency bands. Federal agencies, such as the FCC and NTIA in the United States, specify what frequency spectrums licensed and unlicensed connectivity options in which to operate. Telecommunications companies offering connectivity in the licensed bands must apply and pay to use part of the frequency spectrum over a specific geographic area. In contrast, the unlicensed frequency bands are open to everyone, and no application and no payment is required to operate. For example, if a municipality wishes to operate their own network, they can do so in the unlicensed spectrum without having to apply to the FCC and pay for the right to operate in this spectrum. Note that service providers (including municipal operators) and equipment designed for use in the unlicensed bands must still adhere to government regulations on frequency and transmission power. Table 1 lists some of connectivity options that operate in the licensed and unlicensed bands.
| IoT connectivity options in the licensed and licensed spectrums | |
|---|---|
| Licensed Spectrum Unlicensed Spectrum | Unlicensed Spectrum |
|
Cellular 2G/3G/4G Cellular 5G CBRS (Priority Access Licenses - PAL) LTE Cat M1 NB-IoT |
Wi-Fi Bluetooth ZigBee Z-Wave LoRaWAN SigFox CBRS (General Authorized Access - GAA) 6LoWPAN |
The main advantage licensed band connectivity has over unlicensed band connectivity is that potential interference is greatly minimized, and in cases where interference occurs the licensee has the ability to assert claims against the sources of interference. As licensed operators in the same coverage area are operating on different frequencies, there is little likelihood of their networks interfering with one another. This is important for applications that are mission critical, latency or time sensitive, as well as those requiring high uptime or availability, such a broadband network service being sold in subscription models (i.e., retail cellular plans). However, in order to have such reliability, the licensed band carries a steep cost in fees to the FCC for the right to order to operate in these bands. For example, a Federal Communications Commission auction raised nearly $20 billion from commercial entities seeking leases of licensed spectrum.
In contrast, the unlicensed band is open to anyone and everyone, with no consideration for aligning frequency occupancy, and future interference is a possibility. For example, Wi-Fi, microwave ovens, Bluetooth headsets, baby monitors, and smart meters all operate in the same 2.4 GHz spectrum. Each new device added increases the likelihood of interference, which could cause signal degradation and possibly result in some devices failing to connect altogether. This interference, then, can clearly impact the operation of the applications utilizing the connectivity service and require more network tuning and controls to operate together.
Thus, despite the higher risk of interference and greater need for network maintenance, municipalities wishing to operate their own IoT connectivity networks are more likely to look at unlicensed options, solely because of the financial viability of them over licensed spectrum.
Security
All connectivity options incorporate security measures in one form or another, such as encryption, key management and authentication. The specific approaches to security may vary. For example, some IoT connectivity options build on top of the open standards (e.g. LoRaWAN) their own protocols to create their own “proprietary” version with security that is more robust. While it is beyond the scope of this section to compare and contrast the security approaches of each connectivity option, the security consideration is one that must be examined at both the connectivity level, as well as “end to end” (device to gateway to cloud). This is particularly important for mission critical and other applications where availability of services is important. One common approach is to have multiple IoT networks with mission critical applications on a more secure connectivity option, while general purpose and non-critical applications are transmitted through another option.
Editor’s Note: This Blueprint goes into far more detail on this topic in the Cybersecurity & Privacy section.
Device support
While there are multitudes of IoT connectivity options in the marketplace, not all devices can support these options. Some devices have been designed to support a specific connectivity option, while others are more agnostic and support multiple options through changeable radio modules or availability in a number of different connectivity models.
IoT based controllers for the remote monitoring and management of streetlights are examples of devices that are designed with a single connectivity option. While different controller manufacturers use different connectivity options, most of these solutions do not yet offer multi- connectivity options. In this case, buying from one manufacturer locks you into a particular connectivity option.
In the ideal situation, the connectivity option selected should support as many different devices and use cases as possible (and reasonable) in order to maximize the use of the network. However, it is not always practical to do so. There will be instances when you have a specific connectivity option and limit access to that network. These instances include:
- Municipal IoT applications (parking sensors, air quality, etc.)
- Mission critical municipal IoT applications
- Pilot and experimental, non-production ready IoT applications
Open versus proprietary connectivity
Connectivity options can be based on open standards or proprietary technology. Open standards are those defined by key participants within the industry. Each has its own set of advantages and disadvantages. The needs of each municipality are different and will determine what is most appropriate (and available) at that particular point in time. Planners should not look at open versus proprietary consideration as a “right” or “wrong,” but rather from a “more right” or “less right” perspective.
Options based on industry standards provide a measure of flexibility, ensure maximum interoperability with compatible devices, and do not lock you into a particular solution vendor for service and hardware. Often, community-based development structure, such as open source software, provides continuous updates, innovative capabilities and enhancements faster than any one vendor can do on its own. In addition, free access to the technology increases the pool of experts, developers and support resources that you can potentially tap into when the need arises. However, open standard based options may not work in every situation. You may have IoT applications that have very specific or unique requirements, such as security, that are or have not been incorporated into the standard. You may have mission critical applications in which require robust and dedicated engineering support that you cannot get from a consortium. There may be a proprietary technology that comes packaged with vendor or third-party support, giving you lower risk and liability. At the same time, your municipality may not have the expertise to support an open standard and thus may prefer a proprietary, vendor-backed alternative.
Proprietary connectivity may incorporate approaches that may work better than the current open standard based technologies for security, latency and throughput. Solution creators of these technologies may provide a more robust level of customer and technical support. Depending on the technology, some proprietary connectivity solutions have an ecosystem of third-party devices and applications that support their technology. In other cases, municipalities may have limited options if they want to use a particular device (e.g. smart water meters) that only works with a particular connectivity technology.
Maturity
There is a wide variety of IoT connectivity options in the marketplace today; however, they are evolving, with some more mature than others. The technology will continue to evolve as IoT evolves, new use cases and applications emerge, and more and more devices connect to IoT networks. While there is not a single “one size fits all” connectivity option, there is likely to be some consolidation around a smaller set of connectivity options in the future. For example, LoRaWAN may gain widespread adoption in the future, pushing aside other IoT connectivity protocols. IoT connectivity options will lose out due to a lack of market adoption, while some will be regulated to niche use cases and applications, while still others will be superseded or consumed into others through mergers and acquisitions. Given how early on we are in the marketplace today, it is not in the scope of this document to predict winners or losers. Rather, this document advises decision makers to consider the technology maturity of these options, as well as to devise a future-proofing strategy to mitigate the risks associated with incorporating some of these IoT connectivity networks into municipal operations.
Management and Operations
Network management is an important consideration for municipalities. This consideration is somewhat simplified for municipalities that elect to use the Subscription / 5G Model (i.e., connectivity services provided by telecommunications operators).
For municipalities that are deploying all or part of their own network in some form of the Build Model, the management and operation of this network will be an important consideration. There are three emerging management models:
- Network is owned and managed by the county, or by a regional agency, with connectivity services are provided to the municipality
- Network is owned and managed by municipality
- Network is owned by the municipality, but management is outsourced to a third-party operator on behalf of the municipality
Many municipalities own and manage their own public safety communications networks. They own communications infrastructure, including radio towers, fiber optics, wireless and antenna infrastructure. They have an internal organization and resources to manage this infrastructure. Municipalities that have this capability should assess the feasibility of incorporating IoT connectivity management into their organization, which may mean training existing Information Technology Staff on new IoT systems, thus adding IoT support to the existing IT Department’s roles and responsibilities.
Many smaller municipalities do not own much infrastructure. In this case, their options are to either develop this capability internally, which may pose a difficult challenge, or to contract with a third party (private or public) to manage and operate their network. In some cases, such municipalities may be able to contract with their county or other regional agencies who have this existing capability.
Other Considerations
Beyond the considerations listed, municipal decision-makers need to examine a variety of contributing factors.
Risk
There are a variety of risk factors that should be considered when evaluating IoT connectivity options. These risks include the following:
- Technology maturity risk: IoT connectivity technologies are still evolving, and there is a risk that the technology may not evolve, or not be able to adequately overcome technical challenges
- Market adoption risk: There is a multitude of connectivity options in the market today. Some of these technologies may not be in the market a few years from now because the technology may not be able to adapt to new use cases, or the market has shifted to other adoptions.
- Lock in risk: The IoT applications and devices are locked into a specific connectivity method. This prevents migration to other options in the future, as well as binds the municipality to higher costs and operational risks
- Financial risk: Whether you build or buy the IoT network, there is a risk where the costs have not been fully quantified and could exceed initial projections. In addition, there are potential costs associated with switching connectivity options in the future.
- Operational risk: Are the right structures, processes and skills in place to support and manage the connectivity option?
Due to the nascent nature of the IoT market, the level of risk undertaken by municipalities today is necessarily higher than the risks will be five years from now when the IoT market is more mature. Municipalities must understand the risks associated with today’s IoT connectivity technologies, as well as take an inward look at how much, and where risk can be taken. Once that is known, then one can incorporate this into the final selection.
Financial
There are different costs associated not only with each connectivity option, but also with each of the various management/ownership models. These are detailed in Table 2.
| Management Model | Cost areas |
|---|---|
| “Subscription Model” (Use telecom operator provided connectivity services) |
|
| “Build Model” (Own and manage IoT network) |
|
| “Exotic Model” (Own network, outsource management, etc.) |
|
Skills and resources
If using an IoT connectivity service provider (Subscriber / 5G model) is not an option, one major consideration to study is what skills and resources are needed to construct an IoT network on your own. For example, IoT connectivity management requires a variety of skill sets, including; networking, wireless communications, systems and device administration, and security. These skills are not necessarily within the scope and capabilities of existing Information Technology Departments, who are responsible for infrastructure within the city or internal use. However, it is not a far leap to imagine a well-run IT Department with adequate staffing levels successfully absorbing these duties into their current responsibilities. However, additional budget allocations may be required for training, external support, and vendor maintenance to complement IT staff.
For municipalities without a strong or adequately staffed IT department, outsourcing to IoT connectivity management vendors or systems integrators for deployment, testing and management of the network is an option.
A third option, in line with the recommendation of this Blueprint to focus on regional solutions, is to collaborate with either the county, neighboring cities, or other regional agencies to create a multi-agency function that is responsible for managing IoT networks. This shared services center model can be deployed to support multiple jurisdictions. In some cases, the county and regional agencies may have some existing capability that this additional role can be added and funded.
It must also be mentioned that the burden of IoT network management will not fall solely on existing IT Departments. In fact, there will need to be thought given to the Operational Technology (OT) teams and how they collaborate with IT. In many cases, OT will be handled in Public Works Departments, by technicians and engineers responsible for functions such as streetlights, electricity, transportation and traffic, and roads. For public safety systems, there may be OT staff working within the Public Safety Units. For example, OT teams may be responsible for connectivity and performance of edge devices, while IT manages gateways and servers. This relationship between IT and OT will be critical for the success of IoT networks and should be expressed in formal operational guidelines.
Connectivity Option Selection Process
Step One: Initial connectivity selection A major part of the connectivity selection occurs in the initial use case classification. By properly identifying and classifying the use cases against four parameters, a majority of the connectivity options can be eliminated immediately from consideration. This allows a majority of the effort to be spent on evaluating the remaining options.
This is a straightforward four-step process. You start with the full set of available connectivity options. After each step, the candidate list of potential connectivity options narrows. The list that remains is discussed in the next section.
- Step 1: Determine if applications are indoor, outdoor, or both (Table 3)
- Step 2: Determine whether the applications require high bandwidth or not (Table 4)
- Step 3: Determine how far the devices must communicate are from the transmitter (Table 3)
| IoT network connectivity options for indoor and outdoor applications. | ||
|---|---|---|
| Range | Indoor | Outdoor |
| Short (30 ft.) | BT, BTLE | |
| Medium (300 ft.) | Wi-Fi, ZWave, ZigBee | Wi-Fi, ZigBee, AMI |
| Long (miles) |
Cellular - 2G, 3G, 4G LTE Cellular LPWAN - NB-IoT, Cat M1 Unlicensed LPWAN - LoRaWAN, SigFox, etc. | |
| Suitability of IoT network connectivity options for IoT applications. | ||||
|---|---|---|---|---|
| Application | Examples | Characteristics/bandwidth | Indoor | Outdoor |
| High bandwidth | Video | Wi-Fi | 2G, 3G, 4G LTE
Wi-Fi | |
| Medium bandwidth | Audio/Voice | Wi-Fi, ZigBee, ZWave, BT | Wi-Fi
ZigBee | |
| Low Bandwidth | Sensors | BT, BLE | NB-IoT
LTE Cat M1 SigFox LoRaWAN | |
Step Two: Verify Available Connectivity Services
With the list of options generated from Step One, we now proceed to the next set of decisions. This step is concerned with making a decision on whether to use the Subscription Model (i.e., third party telecommunications operator provider IoT connectivity services), or the Build Model (i.e., provide your own network). For this, we refer the reader to earlier sections that discussed the pros and cons of each model.
Table 5 (below) is used to determine what service is available from a commercial service provider. While this is more applicable to outdoor use cases, in some cases IoT connectivity services can cover indoor uses. Contact the service providers to see what providers are operating in your area. Service can be offered by the traditional telecommunications carriers, broadband internet service providers, and a new generation of IoT connectivity providers. Complete the following.
| Template table for documenting availability third party IoT connectivity in your area | |||
|---|---|---|---|
| Provider name | IoT connectivity service provided | How much of your service area is currently covered (view coverage map) | If no or limited coverage, when will coverage be available? |
| _ | |||
| _ | |||
| _ | |||
Note that in your area, you may have one or more service providers offering coverage. Conversely, you may have none. However, based on the information collected, this will allow you to begin to answer the following questions:
- Of the list of the IoT connectivity options pared down from Step One, which ones do a third-party service provider offer?
- How much of the connectivity service is covered in the areas that you are concerned with?
- If not covered, or fully covered, what are their plans to provide the coverage that you need to operationalize your use cases?
- Will the IoT connectivity solution and the service provider meet your use case requirements (see considerations in the Connectivity Coverage considerations?
If the questions are answered satisfactorily, then the option to use telecommunications operator provided services is available to you. While the decision is made to use operator provided services may further simplify the choice of connectivity options, you may still be left with some additional choices to make. In some areas, you may only have one operator for IoT service, and if that is the choice you have, then you have just selected your connectivity option. In other markets, you may have two or three different operators, each providing a different connectivity option. In this case, while you have narrowed down your options from Step One, you must still look at the next steps, including the technical considerations to further narrow down your options.
If the option of using carrier provided services is not available, you still have to have to provide your own coverage and service. However, you will have to continue to select your options based on other parameters in the following steps.
Step Three: Management Considerations In arriving at this step, we know the following:
- The list of compatible connectivity options based on classifying the use cases to be considered
- Whether the option of using third party provided connectivity services is available to you or not
This step is concerned with:
- If the option to use connectivity services are available to you - should you use it?
- If the option to use connectivity services is not available, how should you deploy and operate this network? In-house or outsource?
If the option to use third party connectivity services is a possibility, planners should answer the following questions:
- Is the connectivity coverage provided sufficient for my use cases now and in the near future?
- If there are gaps in the coverage area in the areas that concern me; does the operator have plans to close those gaps? Are they willing to close those gaps?
- Can the operator provide the level of service, availability, performance and security that I need for my use cases and applications?
- Do my applications or use cases have any special considerations that keep me from using a third-party connectivity network or doing business with these providers? This includes municipal policies, regulations, privacy, etc.
- If I were to not use a third-party network, do I have the budget, capability, resources and management commitment to build my own?
If there is no option (or desire) to use third party connectivity services, or the option is not available A publication of the Wireless SuperCluster of Global City Teams Challenge. July 2019. this case, planners must determine whether the city will do this themselves internally, or to outsource some or all of this to a network systems integrator.
- Does the municipality have the skills and resources to deploy the network?
- If this skill set and resource exists, which department/agency is it in? Is it within their charter to take this on? Are they willing to take it on?
- If the skillset and resources do not exist, or the agency is not willing to take it on, are there network systems integrators that can be contracted to do this work?
- Of the design, build, deploy, operate and maintain, which parts does the municipality want to outsource, and which parts it wants to do itself?
- Does the city have the budget commitment for maintenance and operations moving forward to keep this network going?
Step Four: Technology Considerations
In arriving at this step, we know the following:
- The list of compatible connectivity options based on classifying the use cases to be considered.
- Whether the option of using third party provided connectivity services is available to you or not. If the decision was made to use the connectivity services of a third party such as a telecommunications operator, the list of the original compatible connectivity options from step three is narrowed down even more.
- If the option is not available, we still have the list of options from Step Two.
Not all remaining connectivity options are the same. There are now a number of technical considerations to examine in order to narrow this list down more (in the case that there are still multiple compatible options remaining). This is done by examining a few technical parameters and mapping the fit of the connectivity options against it.
First, complete Table 6 below (leave the weighting column blank for now). A description of the parameters was discussed earlier in a previous section. Some of the parameters are easily determined (e.g. licensed or unlicensed, open standard or proprietary, alignment to use case, device support) by looking at the specifications, while others need a deeper analysis (e.g. security, maturity).
| Table Template - Scoring of IoT connectivity options | ||||
|---|---|---|---|---|
| Parameter | Weight (0 to 10) | Connectivity Option One | Connectivity Option Two | Connectivity Option Three |
| Alignment to Use Case (Throughput/Directionality) | ||||
| Licensed or Unlicensed | ||||
| Open or proprietary | ||||
| Device Support | ||||
| Security | ||||
| Maturity | ||||
| Ranking | ||||
With the table just completed, now examine and analyze this table as a whole. This step is about understanding the tradeoffs between the remaining options to see what works best for your individual municipality. One option may have certain parameters that align with your preferences or use cases better than others do, but the remaining parameters may not align as well. For example, you may like the idea of using a connectivity based on open standards, but it operates on the unlicensed spectrum and its security capabilities may not meet your needs as you have a mission critical application. In contrast, another option may operate on the licensed spectrum, but the technology is relatively immature and unproven at scale.
Once the table is completed, the next step is to assign a value to the considerations and to the connectivity options that correspond to each consideration. This is to quantify the differentiation between the options. The underlying principle is that not all considerations are equal. For example, the alignment to the use case may be more important than the licensed or unlicensed consideration, which is more important that the open vs proprietary consideration. Each of these considerations must be assigned a weighting from 0 to 100% with 0 being the least important. The sum of all the weightings (across all the technology considerations) must equal 100%.
Once the considerations are given a weighting, the connectivity options (considerations) must now be given a value. Starting with the “Alignment to use case” consideration row, review each connectivity option against it. Assign a value of between 1 and 5 (with 5 being the best) to each option, taking into consideration how well that option meets your needs for “Alignment to use case.”
| Weighting and scoring for IoT connectivity options | ||||
|---|---|---|---|---|
| Parameter | Weight (0 to 10) | Connectivity Option One | Connectivity Option Two | Connectivity Option Three |
| Alignment to Use Case (Throughput/Directionality) | W1 | C1W1 | C2W1 | C3W1 |
| Licensed or Unlicensed | W2 | C1W2 | C2W2 | C3W2 |
| Open or proprietary | W3 | C1W3 | C2W3 | C3W3 |
| Device Support | W4 | C1W4 | C2W4 | C3W4 |
| Security | W5 | C1W5 | C2W5 | C3W5 |
| Maturity | W6 | C1W6 | C2W6 | C3W6 |
| Ranking | ||||
Once each consideration is assigned a weighting (between 0 and 100%), and each connectivity option corresponding to each consideration is assigned a value (between 1 and 5, with 5 being the best), it is now time to score and rank the options. The score of Connectivity options are can be calculated as follows:
- Connectivity Option One Score = W1*C1W1 + W2*C1W2 + W3*C1W3 + W4*C1W4 + W5*C1W5 + W6*C1W6
- Connectivity Option Two Score = W1*C2W1 + W2*C2W2 + W3*C2W3 + W4*C2W4 + W5*C2W5 + W6*C2W6
- Connectivity Option Three Score = W1*C3W1 + W2*C3W2 + W3*C3W3 + W4*C3W4 + W5*C3W5 + W6*C3W6
The Connectivity Option with the highest score then becomes the highest-ranking option, and the one with the lowest is the lowest-ranking option. Note that this is just a score to differentiate between the connectivity options and is used to generate discussion and inform on a preferred option. The final selection is still based on the discretion of the municipality.
Note in evaluating and scoring each consideration and option that there is no one “right” answer - this step is more of an iterative process and making tradeoffs among the remaining options in whole. Each municipality will weigh these parameters differently based on their individual situations, use cases and preferences. What is right for one municipality may not be appropriate for another.
Step Five: Other considerations
In arriving at this stage, you now have an understanding of the various options from a use case fit and technology perspective. You would have ranked the remaining options and may have a preference that will work for your municipality.
This step is to further refine that ranking by examining non-technical parameters, which will create some separation in your rankings.
These other considerations were discussed previously in another section. Similar to the exercise with step four, complete Table 8 below, and update your rankings based on that.
For best results, this exercise should be completed with feedback from various municipal organizations. Unlike the technical considerations in Step Four, these parameters cut across organizational boundaries.
| Weighting and scoring of management considerations | ||||
|---|---|---|---|---|
| Parameter | Weight (0 to 100%) | Connectivity Option One | Connectivity Option Two | Connectivity Option Three |
| Risk | ||||
| Financial | ||||
| Skills and Resources | ||||
| Procurement | ||||
| Ranking | ||||
The ranking and scoring of these options for this table is similar to what was discussed in Step Four.
Step Six: Documentation
Upon completion of Step Five, you would have a ranked list of compatible connectivity options. Some municipalities will be ready to take action, while other municipalities may not yet be ready. Given the very dynamic state of the current IoT connectivity market, some of the decisions made through this exercise may be invalidated over time.
Therefore, it is important that each of the steps will be documented. This includes the key drivers, assumptions, requirements, context be documented so that these can be revisited at a later point in time, when the municipality is ready to act.
If things have changed, it is important to understand the original thinking and context for a particular set of choices, and to confirm those are still valid. If things have changed, on either the connectivity side, or the municipality side, the planner does not have to start all over again.
Examples
Example: IoT sensor network to be deployed in a Large Metropolitan Area
A county is planning to deploy a network of low bandwidth non-mission critical IoT sensors, from air quality, flood monitoring, and asset tracking, in order to increase responsiveness and provide better service to its residents, businesses, agencies and visitors. The county comprises both an urban center, as well as a large rural area. The county is serviced by several network connectivity providers, which offer NB-IoT, LoRaWAN and SigFox.
Step One. Initial Classification
- Indoor/Outdoor Category - The sensor network will be deployed outdoors.
- Bandwidth - sensors use very little bandwidth with each sensor transmitting a very small amount of data every hour.
- Range - The sensors are placed throughout the county, from urban areas to remote rural areas. The location of the sensor can be far away from a gateway or base station.
- Power - some of the sensors are placed out in the field and are remote with no power while others may be connected to a power source. The sensors are that are battery powered and in remote locations that require a relatively long service life of 5 to 10 years.
In this initial classification, using Table 3, we can narrow down the initial connectivity options to those that are long range and outdoor use. This yields cellular connectivity options (2G, 3G, 4G/LTE) as well as LPWAN options (both licensed and unlicensed such as NB-IoT, LoRaWAN, etc.).
Most IoT sensors, such as air quality, asset tracking, etc. are low bandwidth as they are only transmitting a very small set of data. With this understanding, we further narrow the connectivity options down to the low bandwidth options. This yields the LPWAN options such as NB-IoT, LTE Cat M1, LoRaWAN, SigFox, etc.
Step Two Verify connectivity services.
In this step, we want to find out what third party services providers have set up networks that cover this area and document the results in Table 5. If these network services are available, and if it makes sense for the county to use these services instead of setting up a county owned/managed connectivity network, then the connectivity selection process is greatly simplified.
In this example, we know that a few service providers already provide coverage in the county. The example states that NB-IoT, LoRaWAN and SigFox cover the county. A different provider supplies each type of service.
Step Three. Management considerations.
In this step, since connectivity service is available, the planner has to decide whether to use a third party or to build their own.
In this case, while the IoT sensor network is used for county operations, it is not mission critical (on the same level as disaster management or public safety), nor does it contain any sensitive data. In addition, because the sensors are dispersed over wide areas within the county, it would require the county to deploy many gateways to fully cover the areas in which the sensors operate. The services providers already have coverage in the area the county sensors will be. In this case, it makes sense to use telecommunication operator provided services.
Step Four. Technology considerations.
There are still three options available - NB-IoT, LoRaWAN, and SigFox. Now we need to look a little closer and rank the choices. Each of the options will have their own pros and cons, and ranking is a method to normalize between the various options.
We start with completing Table 6 as follows. The security and maturity fields are left blank in this example, as it is left to the reader to investigate and complete. Security is a complex topic, and each option has a different approach to security. Each approach was designed to work specifically with the connectivity service. It is not the intention of this document to appear to endorse one approach over another.
| Example of Technology Considerations table completed | ||||
|---|---|---|---|---|
| Parameter | Weight (0 to 100) | Connectivity Option One - NB-IoT from service provider | Connectivity Option Two - SigFox connectivity service | Connectivity Option Three - LoRaWAN service from service provider |
| Alignment to Use Case (Throughput/Directionality) |
|
|
| |
| Licensed or Unlicensed | Licensed | Unlicensed | Unlicensed | |
| Open or proprietary | Based on 3GPP | Proprietary | Open | |
| Device Support | Verify ability to support | Verify ability to support | Verify ability to support | |
| Security | ||||
| Maturity | ||||
| Ranking | ||||
Upon completion of this table (and the subsequent investigation to complete the boxes), it is time to review and create some separation in the connectivity choices.
The first thing to look at is the alignment to the use case in a deeper level of detail. In this case, we start with the data rates offered by each option, as that is relevant parameter here. IoT sensors are simple devices sending back a very small amount of data on a regular basis (e.g. once or twice an hour). All three connectivity options can certainly support the operation of these sensors, but there are some differences. The SigFox option allows for a very small amount of data to be uploaded and a max number message uploaded per day (140). However, it only allows for a very small downlink. This means that if there is any embedded firmware that needs to be updated via Over the Air (OTA) methods, it would be difficult to do it this way and firmware updates may not be feasible.
For the other two options, the data transmission rate is a couple of orders of magnitude higher than SigFox. This higher data rate may be a bit of an overkill for some sensors, but these other connectivity options provide future proofing and flexibility for other use cases.
The next option to consider is the licensed or unlicensed spectrum operation. The licensed option is designed to mitigate any effects of interference. In a dense urban environment, interference is a major issue than in a rural area. In contrast, the other two options operate in the unlicensed ISM band, and over time as more and more IoT devices go to market, the potential for interference increases.
Finally, we consider the case of open versus proprietary. The real issue in this case is vendor lock in and you can only use vendors that have connectivity that supports this option. This may preclude the deployment of other types of use cases or devices in the future. Finally, one important thing to consider is whether the devices can support the three options. Some devices will support multiple options, while others will support only one. Look at the sensors and see what networks they can support. If they only support one option, it may be possible to find another vendor that may support the other two options. If not, and if this application is critical, you may have to choose a network option based on this sensor. Beyond the initial set of sensors, what other sensors and things are planned in the future? This ability to support future sensors and applications are an important consideration for selecting a network option.
Note that not all considerations are equal. In this example, the county planner decides (in collaboration with other appropriate county personnel) that alignment to use case is most important and assigns it a value of 10. The team also decides that device support and licensed/unlicensed spectrum operation are critical and assigns it a value of 9 and 8 respectively. (Note: the weighting in this example are just assumptions the authors made up. In actuality, the planner can assign it whatever number they wish based on internal conversations of what is most important).
Based on the brief discussion, we arrive at the following weightings and rankings below. The score for each option was then calculated
- Option One = 0.35*4 + 0.15*3 + 0.05*2 + 0.20*3 + 0.20*3 + 0.05*4 = 3.30
- Option Two = 0.35*2 + 0.15*1 + 0.05*2 + 0.20*2 + 0.20*3 + 0.05*3 = 2.10
- Option Three = 0.35*3 + 0.15*1 + 0.05*4 + 0.20*4 + 0.20*2 + 0.05*3 = 2.75
| Example of technology considerations scoring | ||||
|---|---|---|---|---|
| Parameter | Weight (0 to 100%) | Connectivity Option One - NB-IoT from service provider | Connectivity Option Two - SigFox connectivity service | Connectivity Option Three - LoRaWAN service from service provider |
| Alignment to Use Case (Throughput/Directionality) | 35% | 4 | 2 | 3 |
| Licensed or Unlicensed | 15% | 3 | 1 | 1 |
| Open or proprietary | 5% | 2 | 2 | 4 |
| Device Support | 20% | 3 | 2 | 4 |
| Security | 20% | 3 | 3 | 2 |
| Maturity | 5% | 4 | 3 | 3 |
| Ranking | 3.30(#1) | 2.10(#3) | 2.75(#2) | |
In going through this exercise, the goal is to identify which of the technology considerations are most important in the selection of the connectivity option, then use to create separation in the remaining connectivity options so that you can rank them, and then pick the best one based on that. Based on this, we have the rankings of each option through Step Four.
We did not look at the management considerations for the purposes of this example. These are very subjective, based on needs, experiences, etc. We leave that to the reader. However, this example should give the reader a walkthrough of the connectivity selection process.
Template - Connectivity Selection
Step One: Initial connectivity selection
- Step 1: Determine if applications are indoor, outdoor, or both (Table 3)
- Step 2: Determine whether the applications use a lot of bandwidth or not (Table 4)
- Step 3: Determine how far the devices are from the transmitter (Table 3)
List all connectivity options that are applicable after answering the questions.
Step Two: Verify Available Connectivity Services
With the list of options generated from Step One, we now proceed to the next set of decisions. This step is concerned with making a decision on whether to use third-party telecommunications operator for IoT connectivity services or provide your own.
Complete the form below by contacting telecommunications providers.
| Contacting telecommunications providers | |||
|---|---|---|---|
| Provider name | IoT connectivity service provided | How much of your service area is currently covered (view coverage map) | If no or limited coverage, when will coverage be available? |
| _ | |||
| _ | |||
| _ | |||
Step Three: Management Considerations
If the option to use third party connectivity services is a possibility, planners should answer the following questions:
- Is the connectivity coverage provided sufficient for my use cases now and in the near future?
- If there are gaps in the coverage area in the areas that concern me, does the operator have plans to close those gaps? Are they willing to close those gaps?
- Can the operator provide the level of service, availability, performance and security that I need for my use cases and applications?
- Do my applications or use cases have any special considerations that keep me from using a third-party connectivity network or doing business with these providers? This includes municipal policies, regulations, privacy, etc.
- If I do not use a third-party network, do I have the budget, capability, resources and management commitment to build my own?
If there is no option to use third party connectivity services, or the option is not available (see Step 2), then the municipality will need to build, deploy and manage their own network. Please answer the following questions:
- Does the municipality have the skills and resources to deploy the network?
- If this skill set and resource exists, which department/agency is it in? Is it within their charter to take this on? Are they willing to take it on?
- If the skill set and resources do not exist, or the agency is not willing to take it on; then are there network systems integrators that can be contracted to do this work?
- Of the design, build, deploy, operate and maintain, which parts does the municipality want to outsource, and which parts it wants to do itself?
- Does the city have the budget commitment for maintenance and operations moving forward to keep this network going?
Step Four. Technology considerations.
The four main tasks are:
- Complete the table
- Establish a weighting for each consideration (row)
- Establish a relative rank for each connectivity option
- Calculate the weighted score of each option
| IoT Technology Considerations | ||||
|---|---|---|---|---|
| Parameter | Weight (0 to 100) | Connectivity Option One | Connectivity Option Two | Connectivity Option Three |
| Alignment to Use Case (Throughput/Directionality) | ||||
| Licensed or Unlicensed | ||||
| Open or proprietary | ||||
| Device Support | ||||
| Security | ||||
| Maturity | ||||
| Ranking | ||||
Step Five: Other considerations The four steps:
- Complete the table
- Establish a weighting for each consideration (row)
- Establish a relative rank for each connectivity option
- Calculate the weighted score of each option
| Ranking other considerations | ||||
|---|---|---|---|---|
| Parameter | Weight (0 to 100%) | Connectivity Option One | Connectivity Option Two | Connectivity Option Three |
| Risk | ||||
| Financial | ||||
| Skills and Resources | ||||
| Procurement | ||||
| Ranking | ||||