Pinfold at 04:11, March 17, 2022

2022-03-17T04:11:31Z

← Older revision		Revision as of 04:11, March 17, 2022
Line 7:		Line 7:
	\| document = 20170823-GCTC-PWSC-Public-WIFI-Blueprint-FINAL-v2.pdf		\| document = 20170823-GCTC-PWSC-Public-WIFI-Blueprint-FINAL-v2.pdf
	\| chapter = 9102		\| chapter = 9102
	\| image =		\| image = ChapterDeployment.jpg
	\| summary =		\| summary = Perhaps the most fundamental decision government agencies will make regarding IoT networks
	}}
	~~__TOC__~~
	~~=Deployment Considerations=~~
	Perhaps the most fundamental decision government agencies will make regarding IoT networks
	is how the IoT network will be built and what the business model and ownership structure will be.		is how the IoT network will be built and what the business model and ownership structure will be.
	The current consensus is that there will likely be two primary paths for IoT network deployments,		The current consensus is that there will likely be two primary paths for IoT network deployments,
	with a third, less ubiquitous option serving as a “catch-all” classification for anything that does not		with a third, less ubiquitous option serving as a “catch-all” classification for anything that does not
	squarely fit within the first two.		squarely fit within the first two.
			}}
	'''Build and Own Model'''		'''Build and Own Model'''

Pinfold at 04:19, March 15, 2022

2022-03-15T04:19:18Z

← Older revision		Revision as of 04:19, March 15, 2022
Line 7:		Line 7:
	\| document = 20170823-GCTC-PWSC-Public-WIFI-Blueprint-FINAL-v2.pdf		\| document = 20170823-GCTC-PWSC-Public-WIFI-Blueprint-FINAL-v2.pdf
	\| chapter = 9102		\| chapter = 9102
			\| image =
			\| summary =
	}}		}}
	__TOC__		__TOC__

Pinfold: /* Smart Communities Framework */

2022-01-07T21:12:00Z

Smart Communities Framework

← Older revision		Revision as of 21:12, January 7, 2022
Line 225:		Line 225:
	Wrapping everything is Vision & Execution and Knowledge & Insight, which create a cycle so		Wrapping everything is Vision & Execution and Knowledge & Insight, which create a cycle so
	that the entire framework can continuously improve and deliver results.		that the entire framework can continuously improve and deliver results.
	[[File:Smart Community Conceptual Framework.~~jpg~~\|center\|800px\|Smart Community Conceptual Framework]]		[[File:Smart Community Conceptual Framework.png\|center\|800px\|Smart Community Conceptual Framework]]

Pinfold: Created page with "{{Chapter | blueprint = Wireless | sectors = Wireless | authors = David Witkowski, Anton Batalla, Essam El-Beik, Benny Lee, Bill Pugh, Steve Wimsatt | poc = David Witkowski |..."

2022-01-07T21:10:16Z

Created page with "{{Chapter | blueprint = Wireless | sectors = Wireless | authors = David Witkowski, Anton Batalla, Essam El-Beik, Benny Lee, Bill Pugh, Steve Wimsatt | poc = David Witkowski |..."

New page

{{Chapter
| blueprint = Wireless
| sectors = Wireless
| authors = David Witkowski, Anton Batalla, Essam El-Beik, Benny Lee, Bill Pugh, Steve Wimsatt
| poc = David Witkowski
| email = davidw@jointventure.org
| document = 20170823-GCTC-PWSC-Public-WIFI-Blueprint-FINAL-v2.pdf
| chapter = 9102
}}
__TOC__
=Deployment Considerations=
Perhaps the most fundamental decision government agencies will make regarding IoT networks
is how the IoT network will be built and what the business model and ownership structure will be.
The current consensus is that there will likely be two primary paths for IoT network deployments,
with a third, less ubiquitous option serving as a “catch-all” classification for anything that does not
squarely fit within the first two.

'''Build and Own Model'''

This first model would occur when a government agency develops specific requirements for an
IoT network and then enters into a contract with a firm to build a network to those specifications
(likely following some form of competitive bidding process). This generally happens as a capital
improvement/public works project, though it could take on another form. It could be funded by
general funds, reserves, bonds, monies from tax revenues, a loan, or other revenue sources
available to the agency. The key distinguishing factor in this arrangement is that the government
agency would pay for the entire cost of construction and installation of the network and would
then own the whole system once it was completed.

In the Blueprint we refer to this model as “Build and Own Model” – a government would pay to
have a network built and would own the system after it was installed. There are several
advantages to the Build model. Namely, the ongoing operating expense would presumably be
lower, and the government would not be constrained on how it could use the network. For
instance, if it decided to lease access to other providers, it could. On the other hand, if it decided
to deploy a new service on the network, such as a parking application in addition to an existing
street light application, there would be no associated new service costs to do so, beyond the costs
to develop said new application. However, the tradeoffs are the high capital costs, the ongoing
operating costs, and the engineering skills required to maintain and further develop the network
and related services (although in many cases, the operations and maintenance of the network
may end up contracted out).

'''Subscription / 5G Model'''

The next model is more straightforward. Soon, it is widely assumed that regional and national
cellular firms, such as AT&T, Verizon, and T-Mobile, will introduce IoT network services, such as
Cat-M, NB-IoT and LTE-M. In fact, research data from Ericsson in April 2018 suggests that 70%
of cellular providers will focus on “Cellular IoT” [https://www.sdxcentral.com/articles/news/ericsson-70-of-service-providers-will-focus-on-cellular-iot/2018/04/ (i.e., IoT delivered over cellular networks)].

This strategy is closely tied to the rollout of [https://www.ericsson.com/en/about-us/india/authored-articles/5g-and-iot-ushering-in-a-new-era 5G networks, which are believed to deliver many
benefits over traditional 4G networks, including gigabit speed, low latency, and better indoor
coverage]. Furthermore, new capabilities in 5G such as network slicing, automation, and
software-defined networking are presumed to enable the business model for [https://www.networkworld.com/article/3268668/5g-to-become-the-catalyst-for-innovation-in-iot.html cost-effective IoT
subscription plans].

From a deployment standpoint, 5G is widely expected to be deployed using “small cell”
technology; that is, small radios that will provide higher speeds than 4G cell towers, but most be
closer and in greater quantity to achieve the same [https://www.pwc.com/us/en/industries/tmt/library/5g-small-cell-revolution.html coverage levels]. In many cases, cellular
service and infrastructure providers are working with municipalities to develop agreements to
deploy small cell technology. ''(It should also be noted that a 2018 FCC order that limits local control over deployment of small cells within municipalities is, as of July 2019, the subject of a lawsuit in the Ninth Circuit Court of Appeals. Policies for small cell deployments and agreements are outside the scope of this Blueprint.)''

Meanwhile, cable companies such as Comcast as working on their own [https://corporate.comcast.com/press/releases/comcasts-machineq-enterprise-iot-service-announces-next-wave-of-customers IoT network services, such as MachineQ (based on LoRaWAN)]. Hence, it follows that at some point in the near future
government agencies will be able to subscribe to these IoT network services in the same manner
that they do cellular plans for mobile devices today. The cellular companies would construct and
own the IoT networks and government agencies would procure services from whomever they
preferred to on the open market.

In the Blueprint, we refer to this as the “Subscription / 5G Model” – a government would buy IoT
network service from a company and pay a subscription fee on a recurring basis (this is
conceptually identical to how LTE cellular data service is sold today). The advantages of this
model are the sheer ease of deployment, elimination of any upfront capital costs, and lack of need
for ongoing maintenance and engineering teams. However, the trade-offs are that the recurring
subscription costs would presumably continue to increase over time, while subscribers to the
network would be restricted to whatever terms cellular firms allowed under their contracts. For
example, deploying a new service might require an additional contract and/or set of fees, while
collaborating with a local agency or another firm might be barred altogether.

'''Other Models'''

Another model, for lack of a better term, is “Other” – this is a model that does not align well with
the Build and Own or Subscription / 5G models. Although this sounds broad, in practicality, the
form it would likely take on would be some sort of a Public-Private Partnership. One example of
this model would be a private sector firm agreeing to provide some or all of the capital costs to
build the network in exchange for the ability to monetize the network somehow; perhaps the
government agency would become an anchor tenant. However, this would be a hybrid approach
in which the agency would have far greater say over the technical specifications and design of
the network, as well as the engineering and development of new services and applications in the
future. In this way, the agency would have a custom IoT network, but would not own it.

Another model could be where a government agency designs, develops, and has constructed a
network but then develops a revenue model to lease service to local firms in an IoT economy.
Because it is impossible to know, a priori, what models might emerge in the future this model,
which we refer to as the “Exotic Model”, is used as a catchall for anything that does not fit squarely
into the others.

Regardless of which model a government agency decides on, there will be many considerations
that should factor into the decision. There is no right or wrong answer and this Blueprint does not
proclaim to make a determination of superiority; these decisions are fully a matter of local control.
What the Blueprint does stress is the importance of making the decision with clear eyes and a
good grasp of the trade-offs inherent with the decision.

This should in no way be considered an exhaustive list of possible models. There are likely many
other things that municipal leaders will have to contend will face before, during, and after their IoT
networks are deployed. A primary takeaway of this Blueprint is that it is crucial to have the right
mix of staff at the table right from the start to ensure every aspect is covered. Cross-functional
teams, including key decision makers from public works, information technology and innovation,
planning, legal, executive management, technical commissions, citizen’s advisory committees,
and elected officials should be created to manage these deployments to increase the odds of
success.

=Security Considerations=
Security was an afterthought in much of the early IoT system designs. However, recent events
have awakened the industry to the critical need for multiple levels of protection across the entire
IoT value chain. By 2020, it is expected that 25 percent of cyberattacks will target IoT.

IoT devices pose unique security challenges to municipalities (who assume the role of a service
provider in some cases) in order to operate their networks. The low-cost, low-complexity model
of most IoT devices means manufacturers have little incentive to add security functions, and the
devices are unlikely to have sufficient processing capability to support any endpoint security
application. Most IoT devices are intended to minimize human interaction, or are deployed in
remote or inaccessible locations, so they are physically less secure and not under direct
observation. This means that any misbehavior may go unnoticed for some time. With the millions
of lightly secured devices expected, municipality networks are vulnerable to signaling attacks and
other DDoS attacks targeting network elements. Preventing, identifying and remediating
infections of IoT systems and devices has become critical to network availability and the goals of
IoT cost-reduction/service-enhancement.

Fully protecting IoT requires multiple levels of protection across the entire IoT value chain.
Instantly detecting malicious activity and blocking suspicious traffic, as well as enforcing other
safeguards are the fundamental security requirements. Continually monitoring command &
control (CC) traffic traversing the network for device-to-controller conversations is critical;
determining which are permitted and which are outside the allowed or expected. Automatic
containment is a necessity, since an infected device or controller can quickly infect the entire
system. Often the goal of the attack is not the location of the penetration; it just happens to be
the easiest point of entry. Therefore, monitoring and automatically prohibiting any non-sanctioned
lateral movement among IoT systems is paramount to stopping the spread of an attack toward
the intended goal.

Additionally, defining a baseline of IoT expected behavior (protocols, ports, communication
frequency, common endpoints, etc.) is critical to understanding when the IoT infrastructure is not
behaving as expected and has been compromised. Behavioral network analytics are the norm
for the human user, and just as important for IoT devices. As IoT solutions spread and grow,
automated identification and protection against malware, often driven by automated attacks, is
the best defense.

These principles are encompassed within the Zero Trust model of security. Zero Trust promotes
"never trust, always verify" as its guiding principle. With Zero Trust there is no default trust for any
entity — including users, devices, applications, and packets — regardless of what it is and its
location on, or relative to, the service network. By establishing Zero Trust boundaries that
effectively compartmentalize different segments of the network, one can protect critical intellectual
property from unauthorized applications or users, reduce the exposure of vulnerable systems,
and prevent the lateral movement of malware throughout the network.
'''''Editor’s Note: The topic is expanded in the Cybersecurity & Privacy Section'''''
=Regionalization and Interoperability=
Another important consideration, which was touched upon in the Smart City framework discussed
above, is the idea of regionalization. A regional, collaborative approach can be immensely helpful
when first entering the smart technology space. Bringing other municipalities into the conversation
to share resources not only helps lower costs, but also ensures innovation does not stop at city
borders. Housing, traffic, mobility, and environmental issues do not stop at lines on a map.
Regional problems thus require borderless solutions. This approach can also provide an area with
a competitive edge. In many communities, people may work, shop, and live in different cities;
ubiquitous technology access and solutions need to travel with residents and visitors as they
move about throughout their days. Who would not want to shop in the area with a smart parking
app to make parking easier? With smart trashcans that are emptied when needed and will never
overflow? With air quality sensors providing the knowledge needed to prevent a child’s asthma
attack? Municipalities should work together on solving these challenges, if not out of the goodness
of their hearts, then simply to prevent residents and visitors from taking their tax dollars elsewhere.

However, like any multi-jurisdictional approach, such regional efforts could be fraught with
challenge. Some agencies may not buy into the model or may disagree with a technical or
operational decision; procurement and maintenance agreements would need to be drafted among
multiple agencies, requiring significant amounts of staff and legal time. These delicate
negotiations would need to be driven with buy-ins from the very highest levels of local and regional
leadership.

If such an effort failed to materialize, in the very least agencies could develop data-sharing
agreements and interoperability standards. In this approach, agencies might use different vendors
and solutions, but the applications and services operating on the underlying IoT networks could
be developed in such a way that data users and devices could roam seamlessly between the
different networks. This may not be practical, in which case basic data sharing agreements would
allow the data – decoupled from the IoT network itself – to be shared between agencies. Of
course, this would require data frameworks to ensure that unprocessed (i.e., raw) could be
processed and interpreted by other agencies.
=Civic Engagement & Privacy=
As agencies embark on IoT network efforts, there are still yet other factors to consider. For one,
there is the matter of resident reaction and engagement. Residents may have a number of
concerns ranging from privacy, security, and possibly even health concerns over the radio signals
emitting from wireless devices. Agencies must be prepared to deal with these. Related to this is
a matter of aesthetics and neighborhood character. Agencies may want to consider adopting
aesthetics guidelines to ensure that IoT networks and devices are consistent with the look and
feel of their communities and do not contribute to urban blight. For agencies with open data
policies, it will be important to think through how the data generated by IoT networks will be made
available to the public. This is extremely useful for communities where citizen engagement
through technology has become an influencing trend.
=Smart Communities Framework=
While this Blueprint, by and large, focuses on IoT networks, it goes without saying that the
outcomes Smart Communities hope to achieve such as: improved public safety, transportation,
broadband connectivity and bridging the digital divide, economic development, sustainability and
energy management, and delivery more and better digital services to their residents are,
ultimately, what matter most. As such, this Blueprint provides a framework for Smart Communities
in Figure 1 below with the IoT and connectivity networks underpinning it.

This framework starts with upper “horizontal” bands, which sit atop various “vertical” domains,
themselves typically managed by separate divisions and departments within the organization.
These horizontal bands introduce a focus on Regionalization (more fully delineated above) and
the Organization itself, specifically the leadership and management decisions regarding how it
structured and develops the capacities of innovation, resilience, efficiency, and sustainability.

The last upper horizontal band is '''Data and Analysis'''. This is, arguably, the most critical aspect
of the framework. IoT networks will generate data on many elements of civic life previously
unavailable. Thus, how these data are managed are critical to the promise of Smart Communities
being fully realized. Who owns the data? Who can analyze it? Is the data transferable and stored
in industry standard formats? It is proprietary? How is privacy protected and managed? How is
the data secured? These are questions of substance, which carry important policy considerations.

These upper horizontal bands are followed by “vertical” bands; the domains spoken of previously,
such as: '''public safety, transportation, broadband, inclusion, engagement, economic
development, energy and waste management, environmental sustainability, and digital
services'''. These represent the most common domains, though there are doubtless many others.
Software applications typically reside within these vertical bands and it is here that improved
outcomes are achieved; hence, they are the most visible. However, the premise of this framework
is that those outcomes are not possible or, in the very least, are far less probable in a context
where the horizontal elements are not aligned with the goals within the domains.

Finally, underpinning these are the lower horizontal bands, Connectivity Networks themselves,
which must be Secure and Resilient. ''(Connectivity networks can include, but are not limited to: fiber optics, wireless and cellular networks, Ethernet, etc.)'' (This Blueprint is focused on these lower two bands.)
Wrapping everything is Vision & Execution and Knowledge & Insight, which create a cycle so
that the entire framework can continuously improve and deliver results.
[[File:Smart Community Conceptual Framework.jpg|center|800px|Smart Community Conceptual Framework]]

Considerations for Deploying Municipal IoT - Revision history

Pinfold at 04:11, March 17, 2022

Pinfold at 04:19, March 15, 2022

Pinfold: /* Smart Communities Framework */

Pinfold: Created page with "{{Chapter | blueprint = Wireless | sectors = Wireless | authors = David Witkowski, Anton Batalla, Essam El-Beik, Benny Lee, Bill Pugh, Steve Wimsatt | poc = David Witkowski |..."