Carrying MTC Service in 5G - A Network
Management Perspective
(Invited Paper)
Xu Li, Jaya Rao, Hang Zhang, and Sophie Vrzic
Huawei Technologies Canada Inc., Ottawa, Ontario CANADA
Email: {xu.lica, jaya.rao, hang.zhang, sophie.vrzic}@huawei.com
Abstract—MTC services are undergoing rapid increase; billions
of MTC connections can be anticipated in a few years. When
supporting MTC services in telecommunications networks, MTC
traffic characteristics and its unique service requirements should
be exploited in order to optimize resource utilization and offer
satisfactory service quality for all devices. In this paper, we
present an Information-Centric Virtual Network Architecture
(IC-VNA) that allows to meticulously combine both the customer
and operator specific virtual functions along with their require-
ments to construct an augmented virtual network topology. It is
shown that through the IC-VNA it is feasible to rapidly roll-out
highly programmable and flexible services while providing high
degree of scalability and cost effectiveness for both MTC service
providers and network operators.
I. I NTRODUCTION
Machine type communications (MTC) is a technology that
realizes a system of networks for collecting data from ma-
chines such as sensors and smart meters which are often
massively and densely deployed [1]. MTC applications are re-
sponsible for translating received raw machine data into mean-
ingful information to support decision making, e.g. earthquake
prediction, or automation, e.g. defense mechanism activation.
Unlike current world-wide human-centric networks, MTC net-
works are featured with absence of direct human intervention
and rapid increase in connections. It is anticipated that MTC
will expand to 2.1 billion connections by the year 2021 [2].
When supporting MTC services, network resources are shared
between machines and hand-held devices. In order to optimize
resource utilization and deliver the best quality of service
(QoS) to all devices and users, MTC traffic characteristics and
varied service requirements should be taken into account when
performing network management and traffic control.
Software defined networking (SDN), among other emerging
technologies, holds the promise of 5G telecommunications
networks [3], [4]. It separates traffic management (the con-
trol plane) from traffic forwarding (the data plane), enabling
centralized control and maximized agility [5]. In the control
plane, SDN manages network resources and controls network
traffic globally through one or a few SDN controllers. Based
on the status information from individual network elements
and the overall traffic requirements, the SDN controllers make
traffic control decisions by solving a traffic engineering (TE)
problem; according to the TE solution, they provide control
978-1-5090-1701-0/16/$31.00 ©2016 IEEE
instructions to data plane hardware for optimizing the opera-
tion of the entire network. TE is to jointly determine for each
traffic flow the communication paths (i.e. routing) and resource
allocation along the paths (i.e. traffic splitting), with respect
to individual flows’ QoS requirements, and network resource
constraints so that a network utility is maximized [6]. Flows
are split among their routing paths in the data plane, following
control plane instructions.
While SDN provides the framework for achieving central-
ized control of the network and as a consequence, poten-
tially globally optimal network performance, another degree
of freedom for facilitating MTC services within the context of
5G networks is realized via the concept of network function
virtualization (NFV) [7]. In this regard, NFV which is a
technology complementary to the SDN, allows implementing
various network functions such as deep packet inspection (DPI)
and network address translation (NAT) as virtual software
entities on commercial off-the-shelf (COTS) hardware. This
capability effectively decouples the network functions from
the physical equipment. The SDN controller itself can be
instantiated as a virtualized network function in any high-
capacity processor residing within either a data center, server
or a network node. From the context of MTC, it is imperative
for the network to support multitudes of services, each possibly
distinguished by a sequence of application specific functions.
As such, the combined SDN and NFV technologies provide
a compelling solution for facilitating the rapid roll-out of
highly programmable and flexible services while providing
high degree of scalability and cost effectiveness for both MTC
service providers and network operators.
In the sequel, we give an overview of MTC services, share
our solution to MTC services in 5G, which leverages SDN
and NFV, and discuss relevant research challenges from a
network management perspective. Throughout the paper the
terms applications, services, customers, sinks are used inter-
changeably for ease of presentation.
II. MTC SERVICE IN A NUTSHELL
A. Traffic characteristics
MTC traffic is characterized as low-rate, small-packet,
delay-tolerant traffic [8], [9]. In many MTC applications, a ma-
chine transmits at a low frequency, e.g. one transmission every
a few minutes or even hours in smart metering applications,

and a small amount of data per transmission, e.g. tens of bytes
for meter reading. Frequent or delay-sensitive transmission
happens only in emergency situations, for instance, upon
detection of voltage surge in the electric power grid. MTC
traffic often may arrive in batches because of high machine
density and correlated transmission. Correlated transmission
is normally due to machines detecting the same or correlated
events or responding to the same data query, which also leads
to traffic content correlation.
In low-rate, small-packet MTC communications, a session
no longer presents itself as a thick flow of packets, albeit
possibly with a long time span. Instead, it is a series of single
or few packets per sessions, i.e. thin flows, scattered far apart
in time. Under this condition, TE’s per session traffic splitting
decision is meaningless since splitting does not happen at the
packet level, and simple path routing may very likely perform
as well as multi-path TE. While individual machines have
low transmission rate (leading to a very small, less than 1%,
volume share [10]), the total MTC packet count present in
the network can be huge. It is anticipated that MTC traffic
accounts for approximately 10% of the total volume in terms
of packets per second. Because every packet in transportation
occupies some network resources, e.g. CPU cycle at routers,
for packet header processing, it is more costly to convey data
via small-sized packets than through large-sized ones.
B. Need for in-network processing
MTC services may involve downlink communication to
configure machine operation for the purpose of business logic
enforcement, machine maintenance, and/or event response.
When responding to an event, downlink MTC traffic may
possibly have a strict delay requirement, depending on the
nature of the event. To reduce response delay in traditional
MTC networks, in-network processing and local reaction capa-
bility have been introduced [11]. While the machines are inter-
connected in an ad-hoc manner, the network is connected to
the outside world through a few gateway (or sink) nodes. Raw
machine data on its way to the sink nodes is aggregated and
processed at some internal aggregation points, which are either
fixed or dynamically selected according to the temporal and
spatial correlation of nearby machines traffic. Data forwarding
paths are planned through the aggregation nodes points with
respect to traffic correlation for improving data processing
efficiency and effectiveness. The data processing functionality
is fixed for each data aggregation point.
When carrying MTC traffic, current telecommunications
networks treat machine reports as independent messages and
deliver them to MTC application servers [8]. The application
servers extract and analyze the information carried by the
messages and, when necessary, respond to machines and/or to
detected events. In other words, application-layer in-network
processing is not offered. As the application servers sit on the
other side of the network, the reporting-response cycle can
experience large or unacceptable delay especially in loaded
network scenarios, which may cause huge economical and/or
social loss in critical applications. For instance, the August
2003 electrical blackout in North America was, among other
Service request
(including VCSF-FG) MTC service
customer
VOSF-FG templates
Selecting VOSF-FG
VOSF information
Generating VNF-FG
(augmenting VCSF-FG with VOSF-FG)
VNF-FG
NFVI information
Creating IC-VNA
(deciding FE-Comp, FE-PoP and FE-LL)
IC-VNA
Traffic information
SDT
Fig. 1. A logical view of SDT functionality
factors, due to cascading failures attributed to the lack of
efficient real-time diagnosis of loading in the electric power
grid [12]; and it led to a $10 billion social cost. To avoid
network congestion and reduce response time, in-network
processing should be enabled, as close to the radio edge as
possible. On the other hand, it should not be too close to the
radio edge such that it can be fed with a sufficiently diverse and
wide range of information for making effective application-
layer decisions.
III. I NFORMATION -C ENTRIC V IRTUAL N ETWORK
In response to massive machine deployment, traffic corre-
lation and in-network processing desirability, we propose a
service-customized, information-centric virtual network archi-
tecture (IC-VNA). The architecture provides a TE framework
that allows the network operator to define an on-demand and
service-specific data plane to enable more efficient use of
network resources and to satisfy QoS the QoS requirements
of the MTC service customers.
An IC-VNA is a logical data plane topology customized for
an MTC service. It includes service traffic sources, service
traffic sinks and functional elements (FEs) as nodes and
directed logical links between the nodes. A service traffic
source can be an MTC device, an MTC device proxy, or a
base station serving MTC devices (proxies). A FE is a logical
node used to host virtual functions. A virtual network function
(VNF) is either a virtual customer-specific function (VCSF)
or a virtual operator-specific function (VOSF) and can be
duplicated at multiple FEs. A VCSF is service-dependent and
reflects service business logic, while a VGNF is offered by the
network operator to all or some MTC services for empowering
the networking process. One such VOSF that is necessary for
all MTC services is serving gateway function (SGW). The FEs
hosting a virtual SGW function for a specific service are called
virtual service-specific serving gateways (v-s-SGWs) [4]; they
are connected with the service traffic sources through logical
links. Another optional VOSF is traffic trunking function which
can be used to mitigate the small-packet-count and large-
packet-count problems. The primary mechanism used to create
an IC-VNA is software defined topology (SDT) [4] whose
specifics are given in the following.
A. Software defined topology (SDT)
In the ETSI NFV management and orchestration (MANO)
framework [13], VCSF and VOSF are not differentiated, and it

is assumed that for each virtual network service a pre-defined
VNF forwarding graph (VNF-FG) is required. The VNF-FG,
which describes a topology of all necessary VNFs, is supplied
to the NFV-MANO for determining the points of presence
(PoPs) that hosts each of these VNFs. As illustrated in Fig. 1,
the SDT technology may leverage this framework to augment
a partial forwarding graph of VCSFs, denoted as VCSF-FG,
with appropriate VOSF-FG templates to generate a complete
VNF-FG. VOSF-FG templates are pre-defined and maintained
by the network operator and can be updated on demand, as
the network evolves.
SDT further converts the VNF-FG to an IC-VNA, which
comprises defining function composition of FE nodes, place-
ment of FE nodes in the network, and logical links (including
respective QoS requirements). We refer to these SDT decisions
as FE composition (FE-Comp) decision, FE point of presence
(FE-PoP) decision, and FE logical link (FE-LL) decision,
respectively. An FE can only be placed at an NFV-capable
node, known as network function virtualization infrastructure
point of presence (NFVI-PoP) and referred to as NFVI node
in this paper. In the presence of multiple MTC services, SDT
jointly creates IC-VNAs for all services by taking into account
of the service requirements, NFVI information and traffic
information. When cross-service function sharing is allowed,
node overlapping may appear between the IC-VNAs.
1) VNF-FG generation: A forwarding graph (FG) defines
graphical constraints among virtual functions, namely, how
they are inter-connected. Note that a single VOSF added by the
network operator can be viewed as a single-function VOSF-
FG. Then, VNF-FG generation generally comprises selecting
VOSF-FG templates according to service request and augment-
ing the VCSF-FG with the selected VOSF-FG templates such
that the overall graphical constraints are all satisfied. In some
cases, template selection is done by classifying services and
pre-defining a template for each service class. For example,
a VOSF-FG template containing virtual mobility management
entity (MME) function can only be used for mobile services.
In some other cases, the VOSF-FG has to be decided on the fly
with respect to some network dynamics. Further elaborations
are provided in subsequent sections after introducing concepts
related to load-oriented VGNF graphical policies.
The graphical constraints defined by a FG can be broken
into primitive VOSF graphical policies. SDT relies on these
policies during VCSF-FG augmentation. A VOSF graphical
policy regulates how a VOSF can be connected with other
virtual functions in the resultant VNF-FG. A given VNF
may be subject to multiple such policies. Primitive VNF
graphical policies may include linkage policies and ordering
policies. A linkage policy defines whether a first VNF should
be linked with a second VNF, directly or indirectly, and in
what direction. It may force both VNFs to be selected. For
example, a linkage policy for a virtual MME function and a
virtual SGW function says they must be directly linked in both
directions. An ordering policy specifies the appearance order
of a VOSF with respect to the other VNFs along a function
chain in a VNF-FG. For example, a virtual SGW function must
appear between a virtual eNodeB function and a virtual PGW
function. Other polices are possible and are not discussed here.
Service request Service request
MTC service Other input MTC service Other input
customer customer
SDT-1 SDT
IC-VNA VNF-FG (update) FE-LL
VNF-FG
FE-Comp & FE-PoP
SDT-2 (as part of NFVO)
NFV-MANO
FE-LL NFV-MANO
FE-LL FE-LL
SDN (TE) SDN (TE)
Provision FE-LL Instantiate FE Provision FE-LL Instantiate FE
Data plane Data plane
(a) (b)
Fig. 2. IC-VNA creation and instantiation. (a) SDT partially residing in
NFV-MANO; (b) SDT residing outside NFV-MANO.
VNF-FG generation may be intertwined with IC-VNA cre-
ation. If VNF-FG generation and IC-VNA creation are two
separate processes, the later needs to feed back its result to
the former for potential VNF-FG adjustment; otherwise, they
need to be carried out jointly, for example, through a single
optimization process.
2) IC-VNA creation and instantiation: Once a VNF-FG is
generated, it can be input to the NFV-MANO. In this case SDT
is partially residing inside the NFV-MANO, for example, as
part of the NFV-Orchestrator component, to fulfill functionality
of creating IC-VNA. Then, the NFV-MANO instantiates FEs at
selected NFVI nodes and interacts with the SDN (TE) for pro-
visioning FE-LLs. Alternatively, SDT may reside completely
outside the NFV-MANO. In this case, VNF-FG is an internal
result of SDT; SDT outputs its result to a simplified NFV-
MANO, which may be the full IC-VNA or a partial IC-VNA.
The NFV-MANO still takes the responsibility to instantiate
FEs. But, it may or may not need to interact with the SDN
(TE), depending on if it receives FE-LL information from the
SDT. If the SDT does not provide FE-LL information to NFV,
it will interact with SDN for FE-LL provisioning. Figure 2
shows the two cases of IC-VNA creation and instantiation.
B. Engaging customer
IC-VNA decision is made on a per-service basis. The
decision making is triggered by service requests submitted
by MTC service customers. A service request includes two
parts namely, service description and service requirement. The
first part depicts service traffic and service function. Service
traffic description includes, for example, how the machines and
traffic sinks are distributed and what their traffic looks like
(mean rate, maximum rate, transmission interval or schedule,
etc.); service function description covers, for example, impact
on traffic rate, VNF-FG, function instantiation constraints, etc.
The second part of a service request describes desired service
traffic quality (e.g. minimum data rate, maximum delay, etc.),
desired service function quality (effectiveness and efficiency)
and how service function quality should be measured. Service
function quality measure is function-dependent. For instance,
an event detection function quality can be measured by false
alarm rate, while a local reaction function can be evaluated by
 MTC service Service request (update) SDT performance Service quality NFVI & traffic
customer Service information
measurement measurement information

SDT
IC-VNA FE node information,

NFV-MANO
estimated service quality, etc.

VCS
Fcontro
IC-VNAs Per-service IC-VNA link
SDN (TE) provisioning config
l and SDT Coordinator SDN (TE)
SDT configuration
Control plane
config

Per-service SDT checkpoints

- location, configuration
uratio

Per-service traffic control mechanisms

Control instructions
Devic

- location, configuration
n
e tra

NFV-MANO
nsmis

VNF1 VNF3
sion

VNF2
Control plane
sche

Control instructions
NFVI node
(including commands of instantiating SDT checkpoints and traffic control mechanisms)
du

Data plane
le (u
pdat

VNF 1 Traffic shaping

Wireless connections
e)

VNF 2 Traffic prioritization

Other traffic control
VNF 3
SDT mechanisams
Device domain checkpoint
NFVI node 1 NFVI node 2
Data plane

Fig. 3. Engaging customer Fig. 4. Adaptive IC-VNA realization

response delay.The procedure of IC-VNA creation is illustrated needs and to configure the application functions on the IC-
in Fig. 3. VNA FE nodes to reflect its latest business logic. When a
As shown in the figure, the network operator handles an service requirement changes, the customer issues a service
MTC service request through an SDT controller component, request update to the network operator, which then adjusts the
which customizes an IC-VNA for the service based on the current IC-VNA or re-creates a new one for the service. It is
service information and the information on network status up to the customer to decide whether and how to apply the
and NFVI node resource status. The SDT controller may also recommended transmission schedule. The customer may up-
decide for the service a recommended machine transmission date its service requirement based on application performance.
schedule that can result in achieving best network performance. For example, when the customer finds that in certain areas
Afterward, the network operator (SDT controller) updates the some urgent events cannot be effectively handled through in-
service customer with the IC-VNA node information (loca- network processing, it specifies the related areas as critical in
tion or network address, and respective functions), estimated a service request update. The SDT controller may then add a
service quality, and the recommended transmission schedule v-s-SGW, associating all the machines in those areas to the v-
(if one exists). Meanwhile, SDT controller also informs the s-SGW and instantiate an event detection function within the
NFV component about the IC-VNA FE node information v-s-SGW. Because the new v-s-SGW gathers a wider range
and the SDN component about the IC-VNA link information. of information related to the corresponding areas, it is able to
Following this, the NVF component instantiates the logical detect local events promptly. This closed-loop feedback allows
nodes while the SDN component provisions each logical link an adaptive IC-VNA from application perspective by engaging
with physical resources through TE, as elaborated below. the customer, enabling an elastic virtual edge to MTC services
Each FE node sends processed data to the next FE node that scales in and/or out according to the services’ need.
in the IC-VNA along a directed logical link. Traffic volume In conjunction with the customer-driven IC-VNA adaptation
and correspondingly, the rate may change after traffic passing described above, network-driven adaptation may be carried
through an FE node, depending on the virtual functions hosted out to enhance network system performance. As illustrated
at the node. For statistical functions such as computing the in Fig. 4, it involves an SDT checkpoint component and a
average or maximum temperature in environmental monitoring coordinator component. The SDT checkpoint is distributively
applications, traffic rate drops, and for functions like encryp- deployed at some, or all IC-VNA nodes to monitor SDT
tion, traffic rate often goes up. When multiple virtual functions performance, i.e. IC-VNA link quality (delay, delay jitter,
are called upon the traffic, they may balance out their effect throughput, etc) and stores the performance measurement in a
on the traffic rate. With SDT being engaged, SDN-TE does database. The coordinator reads per-service SDT performance,
not provision end-to-end service traffic flows but on IC-VNA service (traffic) quality (available from an end-to-end traffic
links, each being viewed as an individual flow. An IC-VNA monitoring component), service information, and network and
link is provisioned according to the link’s QoS requirements, NFVI node status (provided by a network monitoring compo-
the outgoing traffic characteristics measured or estimated at nent). Based on the information, it adapts the service-specific
the source end of the link, and the provisioning configuration SDT configuration (e.g. SDT optimization input parameters)
(e.g. number of physical paths per logical link). and IC-VNA provisioning configuration (e.g. link weight, link
capacity, number of implementation paths per link, etc).
The coordinator informs the new configuration information
C. Adapting to dynamics
to the SDT controller and the SDN component. Then, the SDT
The MTC service customer receives from the network controller updates or re-creates the IC-VNA for respective
operator IC-VNA FE node information, estimated service services accordingly, and the SDN component applies the
quality,and possibly a machine transmission schedule recom- adjusted configurations in subsequent TE optimization. The
mendation. This enables the customer to adjust its service coordinator component also determines whether to instantiate
an SDT checkpoints at some additional locations (if possible,
to gain more performance insight for better coordination), or
remove some existing ones (to reduce monitoring overhead
when SDT performs well). It enforces the decision through the
NFV component. When necessary, through the NVF it installs
or removes traffic control mechanisms such as traffic shaping
and traffic prioritization on selected IC-VNA nodes for each
MTC service, to offer fine-tuned service performance.
IV. D EPLOYMENT AND CHALLENGES
In real-world deployment, a geographic division (e.g. squar-
ization) agreement is generally made between the network
operator and MTC service customers. An MTC customer
specifies in its service request the machine deployment at-
tributes which may include specifications such as squares and
per square machine count, machine traffic distribution, and
per square data rate. As machines automatically associate to
base stations according to their location, the network operator
calculates for each base station service traffic characteristics
and considers the base station as a virtual machine. It then
creates an IC-VNA for the service according to the virtual
machines. The virtual machines’ traffic characteristics can be
updated over time through service traffic measurement done at
respective base stations. When necessary, the SDT decision can
be updated or re-generated using the new information. When
an IC-VNA logical node wants to communicate with machines
as a result of in-network processing, it generates traffic through
the service function and the traffic is transported in downlink
to the machines.
As an IC-VNA FE node will have large processing load
(gathering and/or processing machines traffic), the hosting
NFVI node needs to have sufficient resources (bandwidth,
storage, CPU power). Normally, in a high network utilization
scenario only a subset of the NFVI nodes are capable of
hosting the IC-VNA nodes of a given MTC service. While this
may reduce the solution search space in identifying the host
candidates for the particular MTC service and hence, enabling
swift establishment of the IC-VNA, it may not result in the
global optimality of network resource utilization. This scenario
can be more pronounced especially in the case when the NFVI
nodes are concurrently serving multiple MTC services, where
optimality may only be achievable through global reordering
of all the services and their corresponding IC-VNA FE nodes.
For a particular MTC service such as vital signs monitor-
ing in an e-health application which requires ultra reliable
communications, it may be necessary to introduce a certain
level of redundancy in the network by duplicating the same
application functions in different NFVI nodes. In this regard,
determining sufficient level of redundancy for satisfying the
service reliability while minimally impacting the performance
of other services is of paramount importance.
Our solutions require the research and development of SDT
technology for creating and provisioning service-customized
IC-VNAs. Given a set of NFVI nodes, a daunting challenge is
to select a minimum subset of nodes and optimally associate
the machines to them. This is followed by jointly defining
the data processing functionalities and creating the logical
connections among the selected subset of nodes such as to
guarantee service traffic quality (statistically) through subse-
quent IC-VNA provisioning with best resource utilization. The
separation of architecture creation and provisioning also con-
tributes to the problem difficulty, while service traffic quality
guarantee is required. It involves additional research effort
to formulate the problem (objective function and constraints)
such that performance guarantee is achievable. The underlying
problem becomes even more challenging when considering
multiple services and cross-service optimization.
In addition to the IC-VNA creation problem, the coordina-
tion problem for IC-VNA provisioning is a clear challenge.
The challenge exists in that TE provisions individual IC-VNA
links while lacking a complete picture of end-to-end service
traffic quality. When the network is loaded, coordinating IC-
VNA link provisioning within the same service and across all
services is crucial to providing service traffic quality guarantee.
Traffic prioritization may take place at different levels, i.e.
service level, IC-VNA link level, and physical link level. It
is an important traffic control technique to tune service traffic
quality. As part of IC-VNA provisioning, it is also a challenge
to coordinate IC-VNA link level traffic prioritization with the
traffic prioritization at other levels. Combining traffic shaping
at different places with traffic prioritization may offer improved
overall performance, however this comes at the expense higher
complexity in the coordination problem.
R EFERENCES
[1] R. Lu, X. Li, X. Liang, X. Lin, and X. Shen, “GRS: The Green, Reliability, and Se-
curity of Emerging Machine to Machine Communications,” IEEE Communications
Magazine, vol. 49, no. 4, pp. 28-35, 2011.
[2] 2.1 billion M2M devices in 2021, http://www.analysysmason.com/About-Us/News/
Press-releases1/M2M-forecast-2012-PR-Jun2012/
[3] 5G: A Technology Vision, Huawei Technologies, April 2013. http://www.huawei.
com/ilink/en/download/HW 314849
[4] H. Zhang, S. Vrzic, G. Senarath, N.-D. Dao, H. Farmanbar, J. Rao, C. Peng, and
H. Zhuang, “5G Wireless Network: MyNET and SONAC”, IEEE Network, vol.
29, no. 4, pp. 14-23, 2015.
[5] S. Sezer, S. Scott-Hayward, P.-K. Chouhan, B. Fraser, D. Lake, J. Finnegan,
N. Viljoen, M. Miller, and N. Rao, “Are We Ready for SDN? Implementation
Challenges for Software-Defined Networks,” IEEE Communications Magazine, vol.
51, no. 7, pp. 36-43, 2013.
[6] W.-C. Liao, M. Hong, H. Farmanbar, X. Li, Z.-Q. Luo, and H. Zhang, “Min Flow
Rate Maximization for Software Defined Radio Access Networks,” IEEE J. Selected
Areas in Communications, vol. 32, no. 6, pp. 1282-1294, 2014.
[7] H. Hawilo, A. Shami, M. Mirahmadi, and R. Asal, “NFV: State of the Art,
Challenges and Implementation in Next Generation Mobile Networks (vEPC),”
IEEE Network, vol. 28, no. 6, pp. 18-26, 2014.
[8] T. Taleb and A. Kunz, “Machine Type Communications in 3GPP Networks:
Potential, Challenges, and Solutions”, IEEE Communications Magazine, vol. 50,
no. 3, pp. 178-184, 2012.
[9] M. Zubair Shafiq, L. Ji, A.X. Liu, J. Pang, and J. Wang, “A First Look at Cellular
Machine-to-Machine Traffic Large Scale Measurement and Characterization,” Proc.
SIGMETRICS, 2012.
[10] M2M application characteristics and their implications for spectrum, Machina
Research, 2014
[11] I. Stojmenovic, “Machine-to-Machine Communications With In-Network Data
Aggregation, Processing, and Actuation for Large-Scale Cyber-Physical Systems”,
IEEE Internet of Things Journal, vol. 1, no. 2, pp. 122-128, 2014.
[12] Final Report on the Implementation of Task Force Recommendations,
U.S.-Canada Power System Outage Task Force. http://energy.gov/oe/downloads/
us-canada-power-system-outage-task-force-final-report-implementation-task-force.
[13] Network Function Virtualization: Architectural Framework, ETSI, 2013.
http://www.etsi.org/deliver/etsi gs/NFV/001 099/002/01.01.01 60/gs
NFV002v010101p.pdf.