Jun 23, 2017 - Carolina Fortuna, Adnan Bekan, Tomaz Javornik, Gregor Cerar and Mihael. Mohorcic. Jozef Stefan Institute, Jamova 39, 1000 Ljubljana, ...
Software interfaces for control, optimization and update of 5G machine type communication networksI Carolina Fortuna, Adnan Bekan, Tomaz Javornik, Gregor Cerar and Mihael Mohorcic Jozef Stefan Institute, Jamova 39, 1000 Ljubljana, Slovenia
Abstract 5G machine type communication (MTC) networks will be formed of dense, heterogeneous clusters of wireless devices serving different application verticals, such as urban service enablers, body area networks, industrial and home automation and entertainment. They will use a large number of existing and emerging wireless technologies served by advanced 5G gateways or Internet of Things eNodeBs and controlled through software interfaces by control and application programs, reducing the need for on-site, manual reconfigurations. In this paper, we focus on the software interfaces that enable the control of 5G MTC networks and propose a functional split of upstream and downstream functions. We show similarities with application programming interface (API) development in object-oriented (OO) languages and with representation state transfer (RESTful) principles. We provide a reference implementation using RESTful functionality and an example control application that performs localization. Keywords: software interface, network application programming interface, machine type communication, 5G, IoT, dense, heterogeneous, control application
I An edited and improved version of this paper has been accepted and is going to be published in Elsevier Computer Networks special issue on 5G.
Preprint submitted to Elsevier
June 23, 2017
1. Introduction 5G systems will deeply transform the existing communication infrastructure by 1) increased softwarization through the adoption of software-defined networking (SDN) and network function virtualization (NFV) principles, 2) 5
the introduction of new wireless technologies, such as massive multiple-input, multiple-output (MIMO) and millimetre wave technology, and 3) the integration of heterogeneous 3GPP compatible and non-compatible technologies [1]. As a result, both edge and core networks will go through profound transformations, finally delivering a system that will enable different businesses from all economic
10
sectors to improve and scale their processes better. The 5G infrastructure will abstract all technological complexities and offer network and processing as a service to specific application verticals.
Figure 1: Segments of 5G machine type communication networks.
On the access side of the network, the existing human type communication (HTC) generated by voice calls and applications will be further complemented, 15
and surpassed in traffic volume, by machine type communication (MTC) using
2
an increasing set of existing and emerging wireless technologies, such as IEEE 802.11, 15.4, 15.1 and LoRa, as depicted in Figure 1. All these technologies were designed and optimized for specific applications/verticals and some will have to spatially and temporally co-exist in future dense networks. We refer to this 20
system as a heterogeneous access system, where the end devices feature a 3GPP or non-3GPP technology while the network edge is formed of possibly multitechnology access points. Given that the technologies used by MTC devices are incompatible at the physical, medium access control (MAC) and sometimes even higher layers, 5G systems will introduce new access equipment, referred to in the
25
figure as 5G gateways or Internet of Things (IoT) eNodeB’s, featuring multiple radio access technologies (RATs)[2]. The RATs will be connected to virtual machines or containers running on the gateway and providing the upper layers of the stack. Alternatively, this can be provided in an entirely virtualized fashion at a micro-data centre located in the vicinity of the gateway and having a high
30
speed fibre connection to it. The 5G gateway/IoT eNodeB could already include some built-in network optimization technology to coordinate inter-technology transmissions, such as LTE-U and Wi-Fi in 5 GHz and Wi-Fi, Bluetooth and ZigBee in the 2.4 GHz ISM band. Another possible placement for network optimization technology for het-
35
erogeneous MTC networks is in a data centre close to the RATs/radio heads, which would allow implementation of the network stack functionality and optimizations through the edge/fog computing paradigm [3]. Network-wide optimizations are usually performed in a more centralized data centre [4]. This placement enables a broader scope of optimization including technologies that
40
currently provide their own base stations and a cloud infrastructure that is optimized, such as SigFox. The network control and optimization technology running in a data centre is implemented using a set of software components and algorithms that must be able to interact with the 5G gateway/eNodeB and/or with the MTC wireless
45
nodes. The only means of enabling this interaction is through software interfaces. While there are existing papers in which new interfaces were proposed [5] 3
or significant attention was dedicated to interface structure [6, 7], a structured approach to the functional analysis of an interface is missing. To this end, two contributions are included in this paper. The first and 50
main contribution is the analysis and functional split of the software interface that enables the control and optimization of 5G MTC networks. We propose a split of the network interface towards control applications, also referred to as northbound application programming interface (API) in SDN terms [8, 9], in upstream and downstream functions. These are conceptually similar to concepts
55
existing in object-oriented (OO) programming languages [10] and can also be mapped to representation state transfer (RESTful) principles [11]. The second contribution is represented by the complete prototype implementation of the entire system using the control interface. We provide a reference implementation of the functionality using RESTful principles and illustrate it using state
60
diagrams and an example application performing localization. The paper is organized as follows. Section 2 summarizes related work, Section 3 discusses the proposed functional split of the northbound software interface, Section 4 provides the reference implementation. Section 5 provides the example control application, while Section 6 concludes the paper.
65
2. Related work With the adoption of the SDN paradigm also in mobile and wireless networks, resulting in the softwarization of wireless network functionalities, software interfaces and their architectural match to the structure and scope of network segments have recently become the subject of investigation also in the
70
wireless networking community. With the OpenFlow protocol being practically a standard solution for the southbound interface between the control and data plane [9, 12], our main interest is in the northbound interface enabling the exchange of information between the control plane and the control application, where an implementation needs to be adapted to the application using the net-
75
work. In this section, we therefore restrict our discussion to related work on
4
northbound software interfaces. In [4], the authors proposed a centralized controller that enables a very fine-grained topology-, traffic- and channel-aware spectrum allocation. This controller runs in the cloud and uses an interface inspired by the northbound 80
interface in SDN, that is, an interface between the device and the control application. The API used by the control program enables 1) the management of the configurations by using functions such as setSpectrumAllocation(set of subchannels), 2) the reporting of statistics through functions such as getNeighborInfo(), getClientInfo() and 3) the use of flow matching rules of the form (packet in
85
operation). In [6], a framework was proposed that exploits datapath programmability to enable service differentiation and fine-grained transmission control, facilitating the prioritization of critical applications. The control application using this framework provides a northbound API that has three regions: 1) the north-
90
bound API for radio control with functions such as getClients(), getAgents(), 2) a participatory interface with functions such as get/set InterfaceToMonitor(), uninstall/install Service() and 3) a virtual middle-box API with functions such as migrate vMB(), add vMB(). In [13], the authors proposed a software-defined centralized control plane for
95
radio access networks, called SoftRAN, in which distributed base stations in a given geographical area are abstracted as a virtual large base station with a central controller. Having a global view of the network, the controller can employ different control algorithms for optimization of radio resource management, particularly focusing on interference and mobility management, load balancing
100
and throughput maximization. The SoftRAN framework was proposed to utilize the open FemtoAPI industry standard interface, subsequently extended to nFAPI1 (the network functional application platform interface). In [7], an SDN architecture for WiFi networks was proposed defining an 1 Small
Cell Forum: nFAPI and FAPI specifications, http://scf.io/en/documents/082 -
nFAPI and FAPI specifications.php
5
API that is functionally split according to the controlled entity, resulting in 105
six regions for access point, link, virtual access point, network, station, and flow entities. In [5], the authors proposed a single API, referred to as unified programming interface radio (UPI R), for controlling the radio properties of a set of multi-technology transceivers. Further work focused mostly on different control applications for software-defined wireless sensor networks and not on
110
software interfaces was reviewed in [12].
3. Functional split of the software interface In this paper, we propose a software interface, also referred to as a network application programming interface (nAPI), structured according to two functional parts: upstream and downstream. We also refer to the upstream functions 115
as getter functions and the downstream functions as setter functions to make an analogy with accepted terms from OO concepts [10]. The getter functions read a property of the underlying system (individual node, set of nodes, gateway, etc.) while the setter functions set the property of the underlying system. In Web services, particularly representation state transfer (REST) APIs [11], the
120
form of the functions is more hierarchical. More specifically, the implementation takes into account the structure of the device, the transceiver, and the individual building elements, as can be seen in Figure 2. The OO functions, however, usually do not reflect such a hierarchy explicitly, being devised to support the generalization of functions through abstraction. In this case, the hierarchy is
125
implemented through classes, from which the objects are instantiated, and their naming. 3.1. Upstream software interface functions The upstream functions of the nAPI enable data acquisition from the networks by monitoring various parameters, such as the received signal strength
130
(RSSI), link quality indicator (LQI) and packet reception ratio (PRR), but also by extracting configurations, such as the contention window size. We refer to these functions also as monitoring and diagnosis functions. 6
Figure 2: 5G machine type communication (MTC) network application programming interface (API) and its functions: object-oriented-like functions and RESTful representation. The control application uses the network API to monitor, optimize, and configure the network using controlled MTC devices that implement the API.
3.1.1. Remote monitoring and diagnosis The nAPI has to allow remote monitoring of the radio and network param135
eters, as well as the diagnosis of the overall network. The machines forming the MTC network have to be able to provide information about their status, health and current configuration. For instance, ping times and round-trip times may be requested every few minutes from the remote monitoring application that assesses the overall performance of the network. Based on these statistics, the
140
network performance can be later improved manually or automatically. The micro controller and the surrounding temperature may be important parameters to monitor, especially in industrial production environments, as these affect the performance and lifetime of the nodes. An overall network configuration, such as routing or neighbourhood tables, as well as current protocol configurations,
145
should be provided on demand for performing remote diagnosis.
7
3.2. Downstream software interface functions The downstream functions of the nAPI enable network control and management by enabling parameter tuning, protocol stack reconfiguration and upgrades, as well as driver or operating system (OS) updates. 150
3.2.1. Remote parameter tuning The parameters of MTC devices can be grouped into (i) transceiver parameters, such as transmit power, operating frequency and operating bandwidth, and (ii) protocol parameters, such as contention window size for carrier sense multiple access (CSMA), time to live value for the Internet protocol (IP) or the
155
ceiling of the exponential back-off in the transmission control protocol (TCP). These are all important for the remote configuration and tuning of the wireless technology used. Remote parameter tuning can be performed in runtime or by rebooting the corresponding node so that the changes take effect. Runtime reconfiguration is more convenient for advanced algorithms, where dynamic inter-
160
ference mitigation or power allocation settings are chosen automatically, because the system can perform timely and agile changes. For instance, using advanced power control algorithms such as that proposed in [14], a runtime reconfigurable system can adapt the transmit power and thus maintain good links in dynamic environments where transmitters and obstacles appear and disappear.
165
3.2.2. Protocol stack reconfiguration For cases where a device can be reconfigured to support various versions of a protocol stack or devices on which modular implementations of protocol stacks exist, the entire protocol stack can be reconfigured on the node, provided all the required modules have been pre-installed. Examples of such modular pro-
170
tocol stacks include the standards-based IPv4/6 implementations in PicoMESH 2
, TAISC [15] or the clean-slate CRime [16]. For instance, it is easy to switch
between IPv4 and IPv6 by just changing the layer-three protocol implemen2 https://github.com/tass-belgium/picotcp/wiki
8
tation module, while the MAC and transport layer protocols may remain the same. This functionality supports the development of efficient communication 175
protocols and algorithms that are generic and independent of the underlying OS. 3.2.3. Over the air software updates and upgrades Occasionally, the network and devices require more significant software updates and upgrades. Such updates are useful for debugging, upgrading an exist-
180
ing functionality, such as a protocol setup, or adding a new functionality [17]. In [18], the authors identified three types of required updates: OS/firmware upgrades, driver updates and application updates. OS/firmware upgrades are expected to occur when new versions of software are released or when a major flaw is discovered and needs to be fixed immediately. However, for experimental
185
setups that require software modification, the need for over-the-air programming (OTAP) may be more frequent. In many cases, these upgrades can be achieved using dynamic linking, thus avoiding the need for realizing a full OS/firmware upgrade. In such cases, the file sent to the nodes of the testbed is small as compared to the full OS/firmware image. The performance of a full OS/firmware
190
upload for each application tends to be time consuming and uneconomical, particularly in the low throughput networks typical of the MTC environment.
4. Reference implementation of the network application programming interface In this section, we describe a reference implementation of the nAPI with the 195
proposed functional split that enables network monitoring and control using REST principles. The upstream and downstream operations identified in the previous section are illustrated on concrete examples using UML sequence diagrams. The RESTful requests and responses are sent using Web protocols such as HTTP or CoAP. Appropriate handler functions have to be implemented on
200
the receiving side to recognize the API call and execute the request. After the execution, a response is usually sent to the requester using the same mechanism. 9
4.1. Machine type communication device architecture In our implementation, we used the VESNA embedded device
3
having an
architecture as illustrated in Figure 3. The hardware configuration of the device 205
consists of an ARM Cortex M3 micro controller (on the SNC board in Figure 3(b), two transceivers operating in different license-exempt frequency bands at 868 MHz and 2.4 GHz to avoid interference between them (on the SNE board in Figure 3(b), one is IEEE 802.15.4 compliant and the other not) and an SD card for storage. The software configuration of the device consists of a
210
Contiki OS [19], which was modified to support simultaneous operation with two network stacks, as described in detail in [18]. One stack uses the standard IPv6/6LoWPAN that was designed for IEEE 802.15.4 compliant transceivers and performs the network monitoring, configuration, etc. The second uses the CRime modular network stack [16] for designing clean-slate protocols and is
215
used with a transceiver that is not IEEE 802.15.4 compatible. The nAPI proposed in this paper was implemented using CoAP handlers in the Contiki OS and supports requests from a controller, as discussed in the remainder of the section. 4.2. Upstream software interface functions
220
4.2.1. Monitoring and Diagnosis Figure 4 presents a sequence diagram that enables remote monitoring and diagnosis to perform device hardware and transmission monitoring. First, the /hardware/status request is sent from the network application (also referred to as the user or HTTP/CoAP client) to the MTC device (also referred to as the
225
node or HTTP/CoAP server) to receive the transceiver configuration setup, such as the current channel, transmit power and sampling rate. The MTC device responds by sending an acknowledgement and the settings to the control application. 3 http://sensorlab.ijs.si/hardware.html
10
(a) Dual transceiver - dual stack machine type communication device architecture
(b) Implementation using the VESNA hardware Figure 3: Device architecture and implementation.
After the node starts operating, the /crime/stack request is used to re230
ceive periodic status messages containing the LQI and RSSI values of the most recently received packet. The periodicity can be hard coded or set using additional parameters in the API call. Additionally, the /crime/get prr request can be used to retrieve the PRR, and corresponding functions exist also for other parameters, such as the LQI. These are used when the periodic push does not
235
suffice for the purpose of the control application.
11
Figure 4: Remote monitoring.
For off-line or slow loop control and optimization, the /crime/get results function enables retrieval of the logged results (RSSI, LQI), stored on the SD card. The node sends the data to the user in chunks, if the size of the data exceeds the maximum size of a packet payload. 240
4.3. Downstream software interface functions 4.3.1. Remote parameter tuning For remote parameter tuning, a large variety of setter functions can be implemented. Figure 5 presents a sequence diagram that uses two such functions to adjust the channel and transmission power of the transceivers (examples in
245
the following are given for the Texas Instruments CC transceiver). First, the /ti cc/set power function is used with the desired power level as a parameter. The controller (script) sends the request to the target node, which acknowledges it. Then, the /ti cc/set chn request is sent with a numeric value specifying the desired channel. The node acknowledges also this request. Third and finally, the
250
/ti cc/restart handler triggers the reboot of the transceiver. After the reboot, the new values, which have been written in the appropriate registries by the routines called by the local HTTP/CoAP handlers, take effect, thus appropriately configuring the transceiver. As part of our implementation, several parameter tuning handlers were
255
developed enabling the control of a non-IEEE 802.15.4 transceiver that can be used for clean-slate protocol design (TI CC1101), as well as of an IEEE 802.15.4 transceiver (Atmel AT86RF231). As a result, the interface enables 12
Figure 5: Remote configuration of channel and transmission power.
multi-technology control of MTC networks. Additionally, it can be seen that the RESTful calls are semantically meaningful and relatively easy to under260
stand. In our example, by changing /ti/ into /atmel/ in the CoAP request, we are able to address the transceiver to be controlled. 4.3.2. Protocol stack reconfiguration Figure 6 presents a sequence diagram illustrating the reconfiguration of the protocol stack developed using the CRime modular architecture [16]. The recon-
265
figuration is done at runtime using JSON configuration messages that specify the configuration and composition of the new stack. First, the /crime/upload request is used to upload the JSON stack configuration message. The node acknowledges a successful upload. Second, the /crime/init function is used to initialize the stack. The node acknowledges the request after the stack is ini-
270
tialized. Third, the crime/start handler is used to trigger the start of the transmission with the desired sample rate and the number of packets that should be transmitted. The node also acknowledges this request. Fourth and finally, the /crime/stop handler is used to stop the transmission while the transmission can be observed in runtime using the CoAP OBS functionality.
275
4.3.3. Over-the-air software updates and upgrades Figure 7 presents a sequence diagram of handlers for over-the-air software updates and upgrades to perform a full OS update and Figure 8 presents a sequence diagram that uses the same handlers for driver and application updates
13
Figure 6: Runtime stack reconfiguration.
enabled by an executable and linkable format (ELF). 280
First, as shown in Figure 7, the /firmware/card format request is used when users want to wipe any existing data from the SD card. The node acknowledges this request. Second, the /firmware/header request is used to upload a new OS images metadata, such as the size and CRC32 of the image and the slot ID where the image will be stored on the card. The node also acknowledges this
285
request. Third, the /firmware/upload function is used to upload the new OS image. The node acknowledges each transferred chunk of data.
Figure 7: Full operating system/firmware upgrade.
Fourth, the /firmware/card/[slotID] slot is used to select the memory slot of the SD card from which the new OS image has to be loaded. The node also acknowledges this request. Fifth, the firmware/reboot handler is used to reboot
14
290
the device and start the loading process of the OS image from the SD card into flash memory. Similarly to the above, the first operation in Figure 8 uses the /elf/header handler, which uploads the application meta-data, such as file size, CRC32 and application name. The node acknowledges this request. Second, the /elf/upload
295
request is used to upload the application file. The node acknowledges each transferred chunk of data. After the relocation is complete, the node sends the application ID. Third and fourth, the /elf/start and /elf/stop requests are used with the application ID as a parameter to start and stop the application. The node acknowledges also these requests.
Figure 8: Application or drivers update.
300
5. Example control application In this section, we present an example control application that implements localization using a simple algorithm, namely the rings overlap localization algorithm (ROL) [20], which relies on RSSI measurements obtained through the nAPI. The ROL algorithm uses overlapping rings to reduce the possible area in
305
which a transmitter/receiver is located, as depicted in Figure 9. This example is used to show the manner in which the nAPI enables the retrieval of relevant
15
data from a set of MTC devices to be used as standalone data or to complement existing simulation or network planning and optimization tools.
Figure 9: Transmitter localization using rings overlap localization algorithm.
Our example application is able to use only empirical data in the form of 310
RSSI values retrieved through the nAPI or a combination of empirical and analytical data for improving the precision of the localization task. 5.1. Experimental setup For the example control application performing localization, we instantiated the system illustrated in Figure 2. The empirical data were collected from the
315
dense LOG-a-TEC outdoor setup [21], which consists of VESNA nodes with the architecture and implementation described in Section 4. We configured the CRime protocol stack as a simple broadcast transmitter on device N 10, depicted in red in Figures 11(a) and (b), acting as a wireless node with unknown location. We also configured devices N 6, N 7, N 11 and N 13, depicted in green in Figures
320
11(a) and (b), with the CRime broadcast stack. These four devices acted as receivers (or anchors in localization terminology), estimating the RSSI values and providing them to the control application. The control application was developed using Python and MATLAB scripts running in the edge according to Figure 1. The Python script uses the nAPI by sending requests to the
325
devices and receiving their responses. The MATLAB script implements the ROL algorithm and uses the RSSI measurement data retrieved by the Python script. The ROL algorithm can also be implemented in Python. The nAPI can be used by any programming language that allows HTTP and/or CoAP 16
requests to be issued. 330
The analytical data are based on a channel model computed using the GRASS-RaPlaT tool [22], which includes several empirical radio propagation channel models, which need to be calibrated in order to model the RSSI levels accurately. In this respect, each anchor node in turn is set to operate as a transmitter, while the others remain in the role of receivers, estimating RSSI
335
values and sending them via nAPI to the control application. These RSSI values and known locations of the anchor nodes are used to update the channel model coefficients and antenna patterns. Such improved knowledge about the radio environment is subsequently used in combination with empirical data to improve the localization precision. The described calibration procedure of the
340
channel model has to be repeated periodically in order to handle the channel variations due to the changes in dynamic propagation environment. 5.2. Realization Using the proposed nAPI and its reference implementation from Section 4, three approaches for realizing the control application exist, as illustrated in
345
Figure 10: the push, pull single and pull group approaches. The first, the push approach, is based on the control application subscribing to a measurement report service provided by the device through the observable OBS method offered by the CoAP protocol. After the application subscribes using the OBS/crime/stack/ method, it receives RSSI measurement reports
350
from each of the four active devices for as long as it maintains an active subscription (e.g., until resetting it with an RST message). These measurement reports can be sent periodically or/and they can be triggered by an event on the device side, for instance when a given preset threshold value is exceeded, depending on the configuration of each device hosting the CoAP server. Since
355
the transmission times are controlled by the device, devices can utilize sleep mode and thus save their energy. This approach is illustrated in Figure 10(a). Our Python control program subscribes to the observable handlers of the nodes N 6, N 7, N 11 and N 13 and logs the RSSI measurements of each received packet. 17
This approach is suitable for control applications that need frequent updates, 360
such as continuous monitoring of the device location in a dynamically changing indoor or outdoor environment. Depending on the application requirements, the measurement reports can be sent in confirmable or non-confirmable notifications.
Figure 10: Three approaches for realization of the control application using network application programming interface.
In the second, the pull single approach, the control application pulls an 365
RSSI measurement from the device using the GET /crime/getRSSI method, as illustrated in Figure 10(b). Upon receiving the pull request the device responds with the most recent available measurement. The frequency of measurement retrieval is configured in the control application and can be periodic (i.e., each minute or tens of minutes) or/and triggered by an event or a user’s request on
370
the application side. This approach is again suitable for control applications that need frequent, but not necessarily continuous, updates. In the case of periodic pulling, the device needs to be roughly synchronized with the application server to go from sleep to receive mode, whereas with application-triggered pulling the device should not enter sleep mode at all.
375
In the third, the pull group approach, the control application pulls a set of raw or preprocessed RSSI measurements from the device using the GET /crime/get results method, as illustrated in Figure 10(c). This approach is suitable for control applications that work with historic or preprocessed (e.g., smoothed or windowed) data and when occasional retrieval of measurements in a batch is sufficient. 18
380
Measurements are sent in single or multiple response packets depending on the amount of data to be transferred. This realization is most suitable for periodic pulling of data from devices in relatively static operating environments, so that the devices can enter sleep mode between successive transmissions; however, they require at least coarse synchronization with the application server.
385
5.3. Communication load and energy consumption analysis Table 1 summarizes the theoretical calculation of the number of exchanged CoAP requests and messages associated with the three approaches introduced in Section 5.2. For a generalized and fair comparison, we assume N fixed nodes collecting RSSI measurements on the link with the observed device. Each node
390
takes I measurements and in the push and pull single approach it reports each measurement individually. The minimum CoAP header equals 4 Bytes as defined by RFC 7252, expressed in the following as len(header). Both ends have implemented at least a CoAP-18 revision of the protocol to support appropriate block-wise transfer and resource observation. Measurement reports using
395
the OBS method are sent as non-confirmable notifications and when using the pull group approach raw historical measurements are sent in a batch of approximately M measurements. The most important variable affecting the estimation of the communication overhead is the size of the payload. It represents the raw amount of data, ex-
400
pressed in bytes, that will be sent to the receiver. In the case of the CoAP protocol, requests and responses can be encoded as ASCII or UTF-8 characters, or represented in a selected data structure format, such as BJSON (binary JSON) or CBOR (RFC 7049). For the purpose of this analysis, we assume a uniform length of OBS, GET and RST requests expressed as len(mssg), a shorter
405
ACK response equal to len(ack) and a length of each RSSI measurement equal to len(RSSI). In CoAP, the maximum size of payload, maxP ayload, is defined by the underlying protocol. For 6LoWPAN used in our realization the recommended value for maxP ayload is 60-80 Bytes to prevent further fragmentation (RFC 7959). For the number of CoAP requests and messages in the push and 19
410
pull single approaches, we assume that individual requests and responses are smaller than maxP ayload in 6LoWPAN, whereas a response in the pull group approach may need to be split into several subsequent response messages. The amount of data to be transferred between the application server and the devices for the three approaches is summarized in Table 2. Taking these
415
expressions into account, we can perform an example calculation using assumptions that correspond to the described control application for localization, as follows. We assume four devices (N = 4) collecting RSSI measurements each 10 sec for the duration of 1 hr (I = 360). The pull group approach pulls a batch of data each 20 min (M = 120). The length of messages, RSSI measurement and
420
acknowledgement message equal 20 Bytes, 8 Bytes and 4 Bytes, respectively. With these assumptions the amount of transferred data for the three approaches is approximately equal to 17,472 Bytes, 633,600 Bytes and 12,672 Bytes for the push, pull single and pull group approach respectively. Table 1: Comparison of the three approaches in terms of the number of application requests and device messages
Approach
App requests to devices
Device messages to app
Push
N ·2
N ·I
Pull single
N ·I
N ·I
Pull group
N·
I M
N·
I M
·len(RSSI) · d len(ack)+M e maxP ayload
Table 2: Comparison of the three approaches in terms of transferred data
Approach
Data transfer
Push
N · (2 · (len(header) + len(mssg))+ I · (len(header) + len(RSSI)))
Pull single
N · I · (2 · len(header) + len(mssg) + len(ack) + len(RSSI))
Pull group
N·
I M
·len(RSSI) · (len(header) · (1 + d len(ack)+M e)+ maxP ayload
len(mssg) + len(ack) + M · len(RSSI)) A comparison of the three approaches reveals that for the considered frequent 20
425
and periodic monitoring the push approach generates 36 times less data transfer than the pull single approach, while the pull group approach saves a further 27.5% of transfer data under the considered assumptions; however, it does not provide current data values and with the increased frequency of pulling smaller batches it converges towards the pull single approach.
430
The most suitable approach for the device-side triggered and frequent measurement collection is the push approach. Its efficiency drops when the payload is small as compared to the size of the header. Unless used in combination with a confirmable message, it does not provide any acknowledgement of successful data delivery. One of its drawbacks is that each device has to store and maintain
435
the list of subscribed observers. The pull single approach is very costly in the case of periodic requests at short intervals, but it inherently provides request acknowledgements by attaching the requested data to the ACK message. This approach is better suited for applications requiring current data values infrequently upon request.
440
The pull group approach is the most efficient in terms of data overhead, but at the expense of a larger required storage and possibly processing capabilities on the device side and the provision of non-current data. Finally, the energy consumption of the three approaches is largely correlated with the number of transferred messages and the amount of data in both di-
445
rections, and therefore, it can be calculated in relative terms using the same expressions as for data transfer. Clearly, assuming battery-powered constrained capability devices the transmission from devices to the application server is more costly in terms of energy consumption. In this direction, however, the amount of messages and data is more similar in the three approaches than in
450
the opposite direction. The main difference is thus that devices can enter sleep mode and thereby save their energy. For the assumed periodic messaging example, this does not represent a significant difference for the push and pull single approaches, while in the pull group approach devices can enter sleep mode for longer periods. The main advantage in terms of energy consumption can
455
therefore be gained with the push approach with applications requiring device21
triggered messaging, if necessary combined with infrequent periodic pushing, where devices can be in sleep mode most of the time and no synchronization is needed with the application server, assuming the potential gateway device is always active. More detailed calculations of the energy consumption depend on 460
the design and implementation specific choices of the hardware and lower layer protocols, and are beyond the scope of this study. 5.4. Results The results of the control application described in Section 5.1 are presented in Figure 11(a) for the case where only the empirical RSSI retrieved through
465
the nAPI is used by the algorithm and in Figure 11(b) for the case where radio environment data retrieved through another API from a radio planning tool complement the empirical measurements. In the first case, the localization error is approximately 5 m while in the second it is reduced to approximately 1 m.
(a) Localization of transmitter using only RSSI (b) Transmitter localization using RSSI with data with no knowledge about radio environ- some knowledge of radio environment ment Figure 11: Example localization results provided by the application that interacts with the devices through the proposed nAPI.
470
As shown in Figure 11(a), the application of only RSSI measurements for localization does not provide satisfactory results in terms of achieved error. This
22
can be attributed to several factors. First, RSSI measurements include noise, interference and received signals from the anchor nodes combined, resulting in the overestimation of the distance between the anchors and the transmitter. 475
Second, the precise antenna pattern, its azimuth and elevation are unknown. Third, the geometry of obstacles/reflectors close to the antennas is also unknown, and yet the obstacles between the transmitter and the anchors may significantly decrease the RSSI value. Fourth, the path loss exponent varies depending on the height of the anchors and the transmitters above the ground
480
level. The uncertainties of RSSI measurements, represented as a ring width in Figure 9, linearly increase with the distance, i.e., the ring width will be twice the size if the distance between the anchor node and the transmitter is twice longer. Consequently, the anchors at a large distance from the transmitter do
485
not contribute significantly to the localization precision. Furthermore, the ROL algorithm is very prone to errors caused by the geometry and the number of nodes. For instance, the anchor nodes located along a straight line will result in huge localization uncertainty. In general, a higher number of anchor nodes will average the estimated locations and this will lead to lower localization errors.
490
However, the number of anchor nodes is typically limited and their locations in a particular system are predetermined, and thus, other solutions have to be found that may improve the precision. For instance, if the measured RSSI is complemented with the radio environment data, i.e., precise antenna pattern, its azimuth and elevation, calibrated path loss model from each anchor, level of
495
the expected interference and the noise value, the accuracy of the transmitter localization is significantly increased, as depicted in Figure 11(b). In this case, the RSSI value conversion to the range is the main source of errors in the ROL algorithm. The conversion is based on empirical path loss models, transmitter and receiver antenna patterns and their gains. In order
500
to calibrate the empirical path loss model and antenna pattern of a particular anchor node, the particular anchor is configured as a broadcaster, while the remaining anchors sense the RSSI. By applying the algorithm proposed in [23], 23
the anchor node antenna pattern and calibrated path loss model are obtained. A lower uncertainty of the measured range is achieved as a result of the more 505
precise path loss model, which results in the ring having a narrower width. In other words, the supplemented radio environment data decrease the width of the ring shown in Figure 9 and lead to more precise transmitter localization. 5.5. Discussion In this section, we showed the manner in which the proposed nAPI can be
510
applied in a control application that performs relatively simple localization of a single device. The same nAPI, however, is directly applicable to any centralized data processing application, including centralized multi-target and centralized cooperative localization [24], where several nodes have to be configured as broadcasters. In order to prevent interference between nodes, the mechanism
515
to prevent simultaneous transmissions has to be implemented in the network and an algorithm for centralized multi-target or cooperative localization has to be implemented on the application server. The proposed nAPI, extended with the appropriate functions to access application-specific resources if needed, can also be used for collection and subsequent inference on sensed data in any
520
IoT-enabled sensor network using centralized or distributed algorithms; similar observations can be made with respect to alternative approaches for collecting data, as described in Section 5.2.
6. Conclusions In this paper, we proposed a functional split of the software interface that 525
enables the control and optimization of 5G MTC networks. The network interface towards control applications, also referred to as the northbound API in SDN terms, is split into upstream and downstream functions. These are conceptually similar to concepts in existing OO programming languages and can also be mapped to RESTful principles. To prove the concept, we provided a
530
complete prototype implementation of the system using the proposed control
24
interface. The reference implementation of the functionality using RESTful principles was illustrated using state diagrams and an example application performing unknown transmitter localization. The example application shows the manner in which different network APIs for retrieving empirical data can be 535
used in combination with existing simulation and optimization tools to improve the performance of the selected control application.
Acknowledgements This work was partially funded by the Slovenian Research Agency (Grant Nos. P2-0016 and L2-7664) and by the European Community under the H2020 540
eWINE - elastic WIreless Networking Experimentation project (Grant No. 688116).
References [1] I. F. Akyildiz, S. Nie, S.-C. Lin, M. Chandrasekaran, 5G roadmap: 10 key enabling technologies, Computer Networks 106 (2016) 17–48. [2] P. Xing, L. Yang, C. Qian Li, P. Demestichas, A. Georgakopoulos, Multi545
rat network architecture, Wireless World Forum, Working Group C White paper. [3] L. M. Vaquero, L. Rodero-Merino, Finding your way in the fog: Towards a comprehensive definition of fog computing, ACM SIGCOMM Computer Communication Review 44 (5) (2014) 27–32.
550
[4] A. Zubow, M. D¨ o, M. Chwalisz, A. Wolisz, A SDN approach to spectrum brokerage in infrastructure-based cognitive radio networks, in: Dynamic Spectrum Access Networks (DySPAN), 2015 IEEE International Symposium on, IEEE, 2015, pp. 375–384. [5] P. Ruckebusch, S. Giannoulis, E. De Poorter, I. Moerman, I. Tinnirello,
555
D. Garlisi, P. Gallo, N. Kaminski, L. DaSilva, P. Gawlowicz, et al., A unified radio control architecture for prototyping adaptive wireless protocols, in:
25
Networks and Communications (EuCNC), 2016 European Conference on, IEEE, 2016, pp. 58–63. [6] J. Schulz-Zander, C. Mayer, B. Ciobotaru, S. Schmid, A. Feldmann, OpenS560
DWN: programmatic control over home and enterprise WiFi, in: Proceedings of the 1st ACM SIGCOMM Symposium on Software Defined Networking Research, ACM, 2015, p. 16. [7] H. Moura, G. V. Bessa, M. A. Vieira, D. F. Macedo, Ethanol: Software defined networking for 802.11 wireless networks, in: 2015 IFIP/IEEE In-
565
ternational Symposium on Integrated Network Management (IM), IEEE, 2015, pp. 388–396. [8] B. A. A. Nunes, M. Mendonca, X.-N. Nguyen, K. Obraczka, T. Turletti, A survey of software-defined networking: Past, present, and future of programmable networks, IEEE Communications Surveys & Tutorials 16 (3)
570
(2014) 1617–1634. [9] M. Jarschel, T. Zinner, T. Hossfeld, P. Tran-Gia, W. Kellerer, Interfaces, attributes, and use cases: A compass for SDN, IEEE Communications Magazine 52 (6) (2014) 210–217. [10] D. Barry, T. Stanienda, Solving the java object storage problem, Computer
575
31 (11) (1998) 33–40. [11] R. Fielding, Representational state transfer, Architectural Styles and the Design of Netowork-based Software Architecture (2000) 76–85. [12] K. M. Modieginyane, B. B. Letswamotse, R. Malekian, A. M. AbuMahfouz, Software defined wireless sensor networks application opportu-
580
nities for efficient network management: A survey, Computers & Electrical Engineering (in press). [13] A. Gudipati, D. Perry, L. E. Li, S. Katti, Softran: Software defined radio access network, in: Proceedings of the Second ACM SIGCOMM Workshop
26
on Hot Topics in Software Defined Networking, HotSDN ’13, ACM, 2013, 585
pp. 25–30. [14] C. Anton, A. Toma, L. Cremene, M. Mohorcic, C. Fortuna, Power allocation game for interference mitigation in a real-world experimental testbed, in: 2014 IEEE International Conference on Communications (ICC), IEEE, 2014, pp. 1495–1501.
590
[15] B. Jooris, J. Bauwens, P. Ruckebusch, P. De Valck, C. Van Praet, I. Moerman, E. De Poorter, Taisc: a cross-platform MAC protocol compiler and execution engine, Computer Networks. [16] C. Fortuna, M. Mohorcic, A framework for dynamic composition of communication services, ACM Transactions on Sensor Networks (TOSN) 11 (2)
595
(2015) 32. [17] P. Ruckebusch, E. De Poorter, C. Fortuna, I. Moerman, Gitar: Generic extension for internet-of-things architectures enabling dynamic updates of network and application modules, Ad Hoc Networks 36 (2016) 127–151. [18] J. Cinkelj, M. Sterk, A. Bekan, M. Mohorcic, C. Fortuna, Design trade-offs
600
for the wireless management networks of constrained device testbeds, in: 2014 11th International Symposium on Wireless Communications Systems (ISWCS), IEEE, 2014, pp. 245–250. ¨ [19] A. Dunkels, O. Schmidt, N. Finne, J. Eriksson, F. Osterlind, N. T. M. Durvy, The Contiki OS: The operating system for the Internet of Things,
605
Online], at http://www. contikios. org. [20] C. Liu, K. Wu, T. He, Sensor localization with ring overlapping based on comparison of received signal strength indicator, in: 2004 IEEE International Conference on Mobile Ad-hoc and Sensor Systems, IEEE, 2004, pp. 516–518.
27
610
ˇ [21] T. Solc, C. Fortuna, M. Mohorˇciˇc, Low-cost testbed development and its applications in cognitive radio prototyping, in: Cognitive radio and networking for heterogeneous wireless networks, Springer, 2015, pp. 361–405. ˇ [22] D. Sekuljica, A. Vilhar, M. Depolli, A. Hrovat, I. Ozimek, T. Javornik, Mobile networks optimization using open-source GRASS-RaPlaT tool and
615
evolutionary algorithm, in: 2015 9th European Conference on Antennas and Propagation (EuCAP), IEEE, 2015, pp. 1–5. ˇ [23] M. Pesko, T. Javornik, L. Vidmar, A. Koˇsir, M. Stular, M. Mohorˇciˇc, The indirect self-tuning method for constructing radio environment map using omnidirectional or directional transmitter antenna, EURASIP Journal on
620
Wireless Communications and Networking 2015 (1) (2015) 50. [24] C. Soares, J. Xavier, J. Gomes, Simple and fast convex relaxation method for cooperative localization in sensor networks using range measurements, IEEE Transactions on Signal Processing 63 (17) (2015) 4532–4543.
28
