# Intelligent Municipal Heritage Management Service in a Smart City: Telecommunication Traffic Characterization and Quality of Service

Authors: Miguel A. Rodriguez-Hernandez; Zhuhan Jiang; Angel Gomez-Sacristan; Vicent Pla
Journal: Wireless Communications and Mobile Computing
 (2019)

---

## Abstract

The monitoring of cultural heritage is becoming common in cities to provide heritage preservation and prevent vandalism. Using sensors and video cameras for this task implies the need to transmit information. In this paper, the teletraffic that cameras and sensors generate is characterized and the transmissions’ influence on the municipal communications network is evaluated. Then, we propose models for telecommunication traffic sources in an intelligent municipal heritage management service inside a smart sustainable city. The sources were simulated in a smart city scenario to find the proper quality of service (QoS) parameters for the communication network, using Valencia City as background. Specific sensors for intelligent municipal heritage management were selected and four telecommunication traffic sources were modelled according to real-life requirements and sensors datasheet. Different simulations were performed to find the proper CIR (Committed Information Rate) and PIR (Peak Information Rate) values and to study the effects of limited bandwidth networks. Packet loss, throughput, delay, and jitter were used to evaluate the network’s performance. Consequently, the result was the selection of the minimum values for PIR and CIR that ensured QoS and thus optimized the traffic telecommunication costs associated with an intelligent municipal heritage management service.


---

## Body

## 1. Introduction

The rapid growth of population in cities is generating new challenges in the management of resources and infrastructures. The deployment of sensors and communication devices at key points provides intelligence to smart cities and facilities their management [1]. A smart city is a city that uses information and communication technologies (ICTs), especially the ones related with the Internet of Thing (IoT) [2], to supervise and manage existing infrastructures and resources [3]. By using ICTs, a smart city can centralize the IoT sensors information of the whole city in a unique city platform [4], where information can be processed and actions can be performed to the optimization of resources and infrastructures [5]. Therefore, the government can provide better services to citizens and obtain cost savings, resulting in a sustainable city [6].A fundamental aspect in smart cities is the municipal communication network that allows the transmission of the information from different devices. Several kinds of devices are transmitting information in a smart city, from small sensors of noise, pollution, temperature, parking, etc. to video cameras, apart from voice communications systems. The mathematical characterization of the aggregate traffic, generated by these numerous and different sources, is complex and simulation techniques are useful to perform the evaluation [7]. This work is based on an existing municipal network architecture and evaluates the communications needs for the deployment of a new service [8]. The new service evaluated is the intelligent management of the city cultural heritage [9].Cultural heritages are important treasures for cities from the touristic point of view. Besides, citizens are also willing to preserve the symbols of their own history. The intelligent heritage management is a service protecting heritages from deterioration causes that damage the durability of heritage [9]. Cultural heritage preservation is necessary due to two types of dangerous agents: environmental agents and vandalism. Environmental agents are factors such as temperature, humidity, ultraviolet, and chemical agents (SO2, O3, NO, etc.) [10]. Thus, to preserve heritage, a smart system must include several kinds of sensors and video cameras to implement real-time monitoring and recording of historical data [11].The objective of this work is to evaluate the impact on the municipal communications network of deploying an intelligent heritage management system. The simulation of a municipal communications network with OMNET ++ [12] was performed, including a heritage monitoring system composed of different types of sensors and video cameras. The results of the simulation allowed determining parameters associated with the communications of the heritage monitoring service such as bandwidth, delay, jitter, and packet loss. The goal is to ensure an adequate quality of service (QoS) for a heritage management service in a network with heterogeneous devices.All parameters used in the simulation were obtained from real sensors and cameras that met the heritage monitoring project’s specification included within the Valencia smart city. The simulated municipal communications network was inspired by the Valencia municipal communications network. Therefore, the work presented in this paper is an initial evaluation of the impact on the Valencia municipal communications network due to deploying the cultural heritage monitoring service. This evaluation includes the bandwidth use, delay, jitter, and packet loss under different simulation conditions.This paper contains five sections. Section2 introduces the simulation tool OMNET++ and the simulated scenario. Section 3 describes the intelligent municipal heritage service and the models for video camera and sensors. Section 4 shows the results of simulations with different parameters and the effects in QoS. Finally, Section 5 presents the conclusions and future work.


## 2. Scenario Definition in OMNET++

OMNET++ is a discrete event simulator which is extensible, modular, component-based C++ [12]. Many other simulators have been used to simulate smart city scenarios such as DEUS (Discrete-Event Universal Simulator) and Siafu based on Java, Sim-Diasca implemented in Erlang [7], or OPNET [13]; but OMNET++ was chosen due to its scalability, usability, and extensibility [7]. It allows, in a very flexible way, the description of a network in a high-level language or programming in C ++ and has a huge number of libraries that can be extended. Besides, OMNET++ is free use and has an Eclipse-based [14] graphic interface and the authors have previous working experience with it [15, 16].The definition of a simulation in OMNET++ consists of five main files: network description file (.ned, which describes the network), network definition file (.cc, which defines the communication mode), message definition file (.msg), simulation kernel library and user interface library (.lib/.a), and profile (.ini). Among them, the “.ned” and “.ini” files specify the main parts of the simulation. The “.ned” file describes the structure of the network including modules and connections, and “.ini” file defines the communication rules and matches sources with destinations.Figure1 shows the communications architecture of the smart city simulated with OMNET++. The scenario is composed of a city council internal network and the city platform servers in the cloud connected through an MPLS [17] network. The city council internal network includes all traffic sources (sensors and cameras), an output router and the communications systems among the sources and the output router. The sources are those of the municipal heritage intelligent management service, which are heterogeneous; no other sources are taken into account. The output router is responsible for collecting all generated traffic flows and transferring them forward to the city platform servers through the MPLS network. The MPLS network is a multiprotocol packet label switching network used between the city council internal network and the corresponding remote city platform servers in the cloud. The city platform servers receive information and monitor services. Figure 2 shows the graphic interface of the “.ned” OMNET++ file that implements the described scenario including the heritage center, the MPLS cloud, the router connected with the city servers, and the cloud that contains city servers.Figure 1
Scenario of a smart city in functional view.Figure 2
“.ned” file of the scenario of the smart city communication network implemented in OMNET++.The MPLS network implements QoS mechanisms to prioritize traffic, ensuring that the network works with high efficiency and quality. A QoS mechanism includes five steps: classification, marking, policing, queueing, and scheduling [18]. The QoS classes used are multimedia (maximum priority), gold, and silver (minimum priority). The definition of the latter is based on the Macrolan service of the Spanish operator Telefonica [19]. The policer used is the Two Rate Three Colour Marker (trTCM) [20].


## 3. Municipal Heritage Management

The intelligent municipal heritage management system includes three kinds of sensors and a video surveillance system. The three kinds of sensors are temperature and humidity sensors, lighting and ultraviolet sensors, and gas sensors. These sensors are used to measure physical agents inside and outside heritage and send real-time information to city platform servers. The video surveillance system monitors the monument environment and serves for quick detection of vandalism actions.Teletraffic sources can be divided into three main classes: voice, video, and data sources. Furthermore, the traffic pattern of each source class is different and depends on other factors such as use or applied codec. The characterization of the sources traffic pattern is an open problem with a difficult solution. Some traffic behaviour approximations came from measurements of traffic in real networks. However, these measures were aggregated traffics coming from a high number of similar devices [21]. In smart cities, a high number of sources belonging to many different types are generating information. Thus, it is necessary to characterize each individual source to evaluate the aggregated traffic coming from different sources. In the next section, the telecommunication traffics generated by video cameras and sensors are characterised and modelled previously to the simulation.


### 3.1. General Characterization of Video and Data Sources

There are four important attributes in the characterization of telecommunication traffic sources: start time, required QoS, data size, and profile. The start time is the time when a source begins to transmit information; this time can be constant or random. The QoS is related to the priority of the sources assigned by the communications network; there are three quality classes in this work: multimedia, gold, and silver. The data size attribute defines the number of bits sent in each transmission. The profile stores the source configuration; each source is characterised by specific profile parameters. The start time and QoS are defined in a similar way for both data and video, but the data size and profiles are defined with different parameters. Tables1 and 2 show the parameters associated with data size and profile of data [21] and video sources [22].Table 1
General characterization of a data source.
Parameter Type Description Packet sizes Data size Size of each packet (in bytes) Number of resources Number of resources in the file  Number of packets Profile Number of packets in one session Send interval Time between two packets Number of bursts Number of sessions in total Burst interval Time between two sessionsTable 2
General characterization of a video source.
Parameter Type Description Res X Data size (video quality) Frame width (in pixels) Res Y Frame height (in pixels)  Duration Profile Duration of a video (minutes) Time inactive Time without video generation (minutes) Movement Level of movement in a video (1 to 4) Frames per second (fps) Number of frames in one second


### 3.2. Video Sources Definition

In order to define specific video sources of the heritage surveillance system, several cameras were compared according to requirements for this service. Table3 shows the comparison among four different cameras: IP2M-846EB [23] and IP2M-850E [24] from Amcrest company, and TV-IP450P [25] and TV-IP450PI [26] from TRENDnet company.Table 3
Comparison of IP2M-846EB, IP2M-850E, TV-IP450P, and TV-IP450PI cameras.
Parameter IP2M-846EB IP2M-850E TV-IP450P TV-IP450PI Minimum illumination (Lux) Color: 0.05B/W: 0.005 Color: 0.05B/W: 0.005 Color: 0.05B/W: 0.01 Color: 0.05B/W: 0.01 Shutter speed (s) 1/1–1/30000 1/3–1/30000 1/1–1/10000 1/1–1/10000 Zoom Digital: 16xOptical: 4x Digital: 16xOptical: 20x Digital: 16xOptical: 20x Digital: 16xOptical: 20x Viewing angle H:116.5-34.5°V: N/A H: 54.1-3.2°V: N/A H: 54°V: N/A H: 54°V: N/A Focal length(mm) 2.7– 11 4.7– 94 4.7– 94 4.7 – 94mm Max. aperture F 1.6 – 2.8 F 1.4 – 2.6 F1.4 – 3.5 F1.4 – 3.5 Rotation angle/inclination Pan: 0 – 360°Tilt: 0 – 90° Pan: 0 – 360°Tilt: -15–90° Pan: 0–360°Tilt: -5– 90° Pan: 0 – 360°Tilt: -5 – 90° Day/night Yes Yes Yes Yes Resolution 1280x720 1280x720 1280x960 1280x960 Video encoding H.264/MJPEG H.264/MJPEG H.264/MJPEG H.264/MJPEG Max. frame rate 30fps 30fps 30fps 30fps Motion detection N/A Yes Yes N/A Alarm handling 2/1 channel in/out 2/1 channel in/out External alarm External alarm Audio detection Yes Yes Yes Yes Microphone input N/A N/A External External Network port RJ-45 RJ-45 100Base-T 100Base-TAs can be seen in Table3, each type of video camera has pros and cons, but camera TV-IP450P was selected as the most proper one. The two main reasons for the selection were as follows: (1) Motion detection is one of the most important functions for surveillance. Only cameras IP2M-850E and TV-IP450P include it. (2) The requirements for shutter speed in Valencia city heritage project specifications are between 1/1 and 1/1,000s. Both IP2M-850E and TV-IP450P cameras are valid but TV-IP450P shutter speed is lower and therefore the camera cost is cheaper.The traffic behaviour of the TV-IP450P camera working in a heritage management service was defined for the OMNeT++ simulator. The specific values selected to simulate this camera are shown in Table4. Frames per second and video quality are related to the camera, whereas the rest of values depend on the degree of activities around the monument. Video information is transmitted only when a motion is detected; thus video duration and inactivity time were modelled with two exponential random variables.Table 4
Simulated traffic pattern of a video source.
Number 10 Start time Uniform (0s, 900s) QoS Gold  Video profile Duration Random: exponential Min.: 3 Max.: 7 Time inactive Random: exponential Min.: 10 Max.: 20 Movement 2 fps 25  Video quality 1280 x 720 (H.264)


### 3.3. Data Sources Definition

In a similar way as in video sources, three different sensors were selected previously to traffic behaviour characterization. Several real sensors were analysed and the selected ones met the requirements of the Valencia city heritage project specifications. The tables with the comparison of sensors parameters are not included in the paper.The selected sensor for temperature and humidity was Humidity and Temperature Transmitter EE33-M [27] because this sensor meets the requirements in accuracy and measuring range. Besides, it has short response times, quick recovery after condensing conditions, precise measurement at permanent high humidity, outstanding temperature compensation, and sensor protection against pollution and corrosion. The lighting and ultraviolet sensor should be able to detect ambient brightness and sunlight strength on the surface. The selected sensor was UVB+UVA Sensor PMA1107 [28] because it provides an accurate measurement of non-weighted UVA+B ultraviolet radiation from sunlight and artificial light sources, it has an angular response very close to an ideal cosine function making it suitable for measurements of diffuse radiation, and it is weatherproof and waterproof. The gas sensor should be able to measure NO2, O3, CO, and SO2, and the particles PM2.5 and PM10. The selected gas sensor was Vaisala Air Quality Transmitter AQT420 [29] because it enables parts per billion measurements, compensates for the impact of ambient conditions and aging on the sensor elements, has low power consumption, has a maintenance and calibration interval of 24 months, and can be used indoors.Table5 shows the traffic behaviour characterizations for the simulation in OMNET++ of gas sensors. The traffic behaviours of the temperature and lighting sensors were modelled in a similar way.Table 5
Characterization of a gas sensor.
Number 8 Start time Uniform (0s, 180s) QoS Silver  Data profile Number of packets 1 Send interval 1s Number of bursts 1s Burst interval 3600s  Data size Packet size 20 Bytes Number of resources 4The four kinds of teletraffic sources (3 types of sensors and video) involved in the intelligent municipal heritage management service were modelled. The next section shows the simulations results of the heritage management communication network using these four models of traffic sources.


## 3.1. General Characterization of Video and Data Sources

There are four important attributes in the characterization of telecommunication traffic sources: start time, required QoS, data size, and profile. The start time is the time when a source begins to transmit information; this time can be constant or random. The QoS is related to the priority of the sources assigned by the communications network; there are three quality classes in this work: multimedia, gold, and silver. The data size attribute defines the number of bits sent in each transmission. The profile stores the source configuration; each source is characterised by specific profile parameters. The start time and QoS are defined in a similar way for both data and video, but the data size and profiles are defined with different parameters. Tables1 and 2 show the parameters associated with data size and profile of data [21] and video sources [22].Table 1
General characterization of a data source.
Parameter Type Description Packet sizes Data size Size of each packet (in bytes) Number of resources Number of resources in the file  Number of packets Profile Number of packets in one session Send interval Time between two packets Number of bursts Number of sessions in total Burst interval Time between two sessionsTable 2
General characterization of a video source.
Parameter Type Description Res X Data size (video quality) Frame width (in pixels) Res Y Frame height (in pixels)  Duration Profile Duration of a video (minutes) Time inactive Time without video generation (minutes) Movement Level of movement in a video (1 to 4) Frames per second (fps) Number of frames in one second


## 3.2. Video Sources Definition

In order to define specific video sources of the heritage surveillance system, several cameras were compared according to requirements for this service. Table3 shows the comparison among four different cameras: IP2M-846EB [23] and IP2M-850E [24] from Amcrest company, and TV-IP450P [25] and TV-IP450PI [26] from TRENDnet company.Table 3
Comparison of IP2M-846EB, IP2M-850E, TV-IP450P, and TV-IP450PI cameras.
Parameter IP2M-846EB IP2M-850E TV-IP450P TV-IP450PI Minimum illumination (Lux) Color: 0.05B/W: 0.005 Color: 0.05B/W: 0.005 Color: 0.05B/W: 0.01 Color: 0.05B/W: 0.01 Shutter speed (s) 1/1–1/30000 1/3–1/30000 1/1–1/10000 1/1–1/10000 Zoom Digital: 16xOptical: 4x Digital: 16xOptical: 20x Digital: 16xOptical: 20x Digital: 16xOptical: 20x Viewing angle H:116.5-34.5°V: N/A H: 54.1-3.2°V: N/A H: 54°V: N/A H: 54°V: N/A Focal length(mm) 2.7– 11 4.7– 94 4.7– 94 4.7 – 94mm Max. aperture F 1.6 – 2.8 F 1.4 – 2.6 F1.4 – 3.5 F1.4 – 3.5 Rotation angle/inclination Pan: 0 – 360°Tilt: 0 – 90° Pan: 0 – 360°Tilt: -15–90° Pan: 0–360°Tilt: -5– 90° Pan: 0 – 360°Tilt: -5 – 90° Day/night Yes Yes Yes Yes Resolution 1280x720 1280x720 1280x960 1280x960 Video encoding H.264/MJPEG H.264/MJPEG H.264/MJPEG H.264/MJPEG Max. frame rate 30fps 30fps 30fps 30fps Motion detection N/A Yes Yes N/A Alarm handling 2/1 channel in/out 2/1 channel in/out External alarm External alarm Audio detection Yes Yes Yes Yes Microphone input N/A N/A External External Network port RJ-45 RJ-45 100Base-T 100Base-TAs can be seen in Table3, each type of video camera has pros and cons, but camera TV-IP450P was selected as the most proper one. The two main reasons for the selection were as follows: (1) Motion detection is one of the most important functions for surveillance. Only cameras IP2M-850E and TV-IP450P include it. (2) The requirements for shutter speed in Valencia city heritage project specifications are between 1/1 and 1/1,000s. Both IP2M-850E and TV-IP450P cameras are valid but TV-IP450P shutter speed is lower and therefore the camera cost is cheaper.The traffic behaviour of the TV-IP450P camera working in a heritage management service was defined for the OMNeT++ simulator. The specific values selected to simulate this camera are shown in Table4. Frames per second and video quality are related to the camera, whereas the rest of values depend on the degree of activities around the monument. Video information is transmitted only when a motion is detected; thus video duration and inactivity time were modelled with two exponential random variables.Table 4
Simulated traffic pattern of a video source.
Number 10 Start time Uniform (0s, 900s) QoS Gold  Video profile Duration Random: exponential Min.: 3 Max.: 7 Time inactive Random: exponential Min.: 10 Max.: 20 Movement 2 fps 25  Video quality 1280 x 720 (H.264)


## 3.3. Data Sources Definition

In a similar way as in video sources, three different sensors were selected previously to traffic behaviour characterization. Several real sensors were analysed and the selected ones met the requirements of the Valencia city heritage project specifications. The tables with the comparison of sensors parameters are not included in the paper.The selected sensor for temperature and humidity was Humidity and Temperature Transmitter EE33-M [27] because this sensor meets the requirements in accuracy and measuring range. Besides, it has short response times, quick recovery after condensing conditions, precise measurement at permanent high humidity, outstanding temperature compensation, and sensor protection against pollution and corrosion. The lighting and ultraviolet sensor should be able to detect ambient brightness and sunlight strength on the surface. The selected sensor was UVB+UVA Sensor PMA1107 [28] because it provides an accurate measurement of non-weighted UVA+B ultraviolet radiation from sunlight and artificial light sources, it has an angular response very close to an ideal cosine function making it suitable for measurements of diffuse radiation, and it is weatherproof and waterproof. The gas sensor should be able to measure NO2, O3, CO, and SO2, and the particles PM2.5 and PM10. The selected gas sensor was Vaisala Air Quality Transmitter AQT420 [29] because it enables parts per billion measurements, compensates for the impact of ambient conditions and aging on the sensor elements, has low power consumption, has a maintenance and calibration interval of 24 months, and can be used indoors.Table5 shows the traffic behaviour characterizations for the simulation in OMNET++ of gas sensors. The traffic behaviours of the temperature and lighting sensors were modelled in a similar way.Table 5
Characterization of a gas sensor.
Number 8 Start time Uniform (0s, 180s) QoS Silver  Data profile Number of packets 1 Send interval 1s Number of bursts 1s Burst interval 3600s  Data size Packet size 20 Bytes Number of resources 4The four kinds of teletraffic sources (3 types of sensors and video) involved in the intelligent municipal heritage management service were modelled. The next section shows the simulations results of the heritage management communication network using these four models of traffic sources.


## 4. Simulations and Results

The evaluation of the network associated with the intelligent municipal heritage management service was done by using OMNeT++. To perform the simulations, the selected number of cameras and sensors involved in the network was as follows: 10 cameras of video surveillance, 21 temperature and humidity sensors, 8 lighting and ultraviolet sensors, and 8 gas sensors.The simulation was divided into two steps. In the first step each type of traffic sources was simulated in an individual way; subsequently all the sources were simulated together. The first step aimed to get the bandwidth needed by the sources and verify their behaviors. This step served to obtain the optimum values of QoS parameters CIR (Committed Information Rate) and PIR (Peak Information Rate). The second step was to evaluate the influence of a limited bandwidth network over the QoS.


### 4.1. CIR and PIR Evaluation

Iterative simulations allowed adjusting the optimum CIR and PIR parameters associated with each type of sources. Each of the four sources included in this intelligent municipal heritage management service was assigned to a class of service. The video source was classified into gold class for its sensibility to delays. On the other hand, the three data sources were classified into silver class for its lower delay sensibility. After several simulations to estimate CIR, PIR, and maximum throughput, some results were obtained for video and sensors.Three types of evaluations for video and sensors are presented in function of the relation among CIR, PIR, and maximum throughput. The results illustrate the influence of the selection of CIR and PIR values on the QoS. Results are classified by three conditions:(1)
CIR < PIR < maximum throughput(2)
CIR < maximum throughput < PIR(3)
Maximum throughput < CIR < PIRTable6 shows the values of video sources, whereas Table 7 shows the results related to sensors. In both tables it can be appreciated that condition (1) generates packet loss, whereas conditions (2) and (3) have no packet loss.Table 6
QoS mechanism parameters and packet loss for video cameras (gold class).
No. Condition CIR (Mbps) PIR (Mbps) Packet loss 1 CIR<PIR<max. throughput 10 20 140520 2 CIR<max. throughput<PIR 20 30 0 3 Max. throughput<CIR<PIR 50 60 0Table 7
QoS mechanism parameters and packet loss for sensors (silver class).
No. Condition CIR (kbps) PIR (kbps) Packet loss 1 CIR<PIR<max. throughput 0.4 0.8 90 2 CIR<max. throughput<PIR 0.8 2 0 3 Max. throughput<CIR<PIR 2 4 0In addition to tables with QoS parameters and packet loss, some graphics with throughput, delay, and jitter were generated. Figures3, 4, and 5 show the results for a simulation time of 1 hour for video cameras and sensors. Several results were analysed with aggregate traffic flows and individual traffic flows for each source. Figures 3(a) and 4 show results using video cameras; Figure 3(b) displays the throughput of all sensors, whereas Figure 5 shows the delay and jitter corresponding to temperature and humidity sensors.Figure 3
Throughput of (a) 10 cameras and (b) 37 sensors (21 temperature and humidity sensors, 8 lighting and ultraviolet sensors, 8 gas sensors).
(a) (b)Figure 4
(a) Delay and (b) jitter of 10 video sources.
(a) (b)Figure 5
(a) Delay and (b) jitter of 21 temperature and humidity data sources.
(a) (b)Figure3 shows the maximum throughput of 10 video sources is about 27 Mbps and the maximum throughput of 37 sensors is about 1.4 kbps. The throughput with condition (1) is limited by PIR, 20 Mbps in video case and 0.8 kbps in sensor case. A PIR less than maximum throughput implies packet loss, whereas a PIR greater than maximum throughput ensures transmission without losses but with higher costs. Conditions (2) and (3) yield identical results in terms of throughput (in Figure 3 it is impossible to see the blue line because it is under the red line), but condition (3) is more expensive than condition (2). Thus, the best option is to select QoS parameters with condition (2).On the other hand, Figures3(a) and 3(b) show two important differences between traffics from video cameras and sensors. First, the amount of traffic generated by cameras and sensors is very different: video cameras generated throughputs of several Mbps, whereas the sensors traffic was about 1 kbps. Second, the traffic from video sources varies more slowly than sensors traffic, which is spiky. Figure 3(b) represents only 180 seconds to detail the sensors spiky traffic. In any case, the traffic volume due to sensors can be considered negligible compared with the one from video cameras.Figure4 shows the delay and jitter for video traffic. Although there are some small differences in the graphics for the different cases, the absolute values obtained in all cases are much less than the critical values. Figure 5 shows the delay and jitter for the 21 temperature and humidity sensors. In this figure, the values of conditions (2) and (3) are coincident and the blue line is again under the red one; also the values are negligible.


### 4.2. QoS with Limited Bandwidth

After obtaining appropriate CIR and PIR values for each source, the following objective was studying the effects of a network with limited bandwidth on QoS. New simulations were performed with 10 video cameras and 37 sensors transmitting over a network with limited bandwidth. Two bandwidths were tested: 10 Mbps and 100 Mbps. The simulation time was two hours.Figure6 shows the aggregated traffic generated by 10 cameras and 37 sensors. The behaviour of this aggregated traffic is similar to the video traffic displayed in Figure 3(a), because the traffic sent by cameras is much greater than the one sent from sensors. Packet loss was very large in the case of 10 Mbps bandwidth, whereas there was no packet loss with 100Mbps bandwidth.Figure 6
Throughput using 10 cameras and 37 sensors.The delay and jitter results shown in Figure7 confirm the results of Figure 6. The delay and jitter are negligible in the case of 100 Mbps, but the delay and jitter are very high in some congestion periods in the case of 10Mbps, influencing QoS. The best option in this case is 100 Mbps because 10 Mbps is definitely not large enough. The necessary bandwidth to satisfy the desired QoS must be about 30 Mbps, because the 100 Mbps bandwidth is too much and in consequence expensive. An optimum bandwidth value for this intelligent municipal heritage management service with 10 cameras and 37 sensors must be around 25 Mbps.Figure 7
(a) Delay and (b) jitter using 10 cameras and 37 sensors.
(a) (b)


## 4.1. CIR and PIR Evaluation

Iterative simulations allowed adjusting the optimum CIR and PIR parameters associated with each type of sources. Each of the four sources included in this intelligent municipal heritage management service was assigned to a class of service. The video source was classified into gold class for its sensibility to delays. On the other hand, the three data sources were classified into silver class for its lower delay sensibility. After several simulations to estimate CIR, PIR, and maximum throughput, some results were obtained for video and sensors.Three types of evaluations for video and sensors are presented in function of the relation among CIR, PIR, and maximum throughput. The results illustrate the influence of the selection of CIR and PIR values on the QoS. Results are classified by three conditions:(1)
CIR < PIR < maximum throughput(2)
CIR < maximum throughput < PIR(3)
Maximum throughput < CIR < PIRTable6 shows the values of video sources, whereas Table 7 shows the results related to sensors. In both tables it can be appreciated that condition (1) generates packet loss, whereas conditions (2) and (3) have no packet loss.Table 6
QoS mechanism parameters and packet loss for video cameras (gold class).
No. Condition CIR (Mbps) PIR (Mbps) Packet loss 1 CIR<PIR<max. throughput 10 20 140520 2 CIR<max. throughput<PIR 20 30 0 3 Max. throughput<CIR<PIR 50 60 0Table 7
QoS mechanism parameters and packet loss for sensors (silver class).
No. Condition CIR (kbps) PIR (kbps) Packet loss 1 CIR<PIR<max. throughput 0.4 0.8 90 2 CIR<max. throughput<PIR 0.8 2 0 3 Max. throughput<CIR<PIR 2 4 0In addition to tables with QoS parameters and packet loss, some graphics with throughput, delay, and jitter were generated. Figures3, 4, and 5 show the results for a simulation time of 1 hour for video cameras and sensors. Several results were analysed with aggregate traffic flows and individual traffic flows for each source. Figures 3(a) and 4 show results using video cameras; Figure 3(b) displays the throughput of all sensors, whereas Figure 5 shows the delay and jitter corresponding to temperature and humidity sensors.Figure 3
Throughput of (a) 10 cameras and (b) 37 sensors (21 temperature and humidity sensors, 8 lighting and ultraviolet sensors, 8 gas sensors).
(a) (b)Figure 4
(a) Delay and (b) jitter of 10 video sources.
(a) (b)Figure 5
(a) Delay and (b) jitter of 21 temperature and humidity data sources.
(a) (b)Figure3 shows the maximum throughput of 10 video sources is about 27 Mbps and the maximum throughput of 37 sensors is about 1.4 kbps. The throughput with condition (1) is limited by PIR, 20 Mbps in video case and 0.8 kbps in sensor case. A PIR less than maximum throughput implies packet loss, whereas a PIR greater than maximum throughput ensures transmission without losses but with higher costs. Conditions (2) and (3) yield identical results in terms of throughput (in Figure 3 it is impossible to see the blue line because it is under the red line), but condition (3) is more expensive than condition (2). Thus, the best option is to select QoS parameters with condition (2).On the other hand, Figures3(a) and 3(b) show two important differences between traffics from video cameras and sensors. First, the amount of traffic generated by cameras and sensors is very different: video cameras generated throughputs of several Mbps, whereas the sensors traffic was about 1 kbps. Second, the traffic from video sources varies more slowly than sensors traffic, which is spiky. Figure 3(b) represents only 180 seconds to detail the sensors spiky traffic. In any case, the traffic volume due to sensors can be considered negligible compared with the one from video cameras.Figure4 shows the delay and jitter for video traffic. Although there are some small differences in the graphics for the different cases, the absolute values obtained in all cases are much less than the critical values. Figure 5 shows the delay and jitter for the 21 temperature and humidity sensors. In this figure, the values of conditions (2) and (3) are coincident and the blue line is again under the red one; also the values are negligible.


## 4.2. QoS with Limited Bandwidth

After obtaining appropriate CIR and PIR values for each source, the following objective was studying the effects of a network with limited bandwidth on QoS. New simulations were performed with 10 video cameras and 37 sensors transmitting over a network with limited bandwidth. Two bandwidths were tested: 10 Mbps and 100 Mbps. The simulation time was two hours.Figure6 shows the aggregated traffic generated by 10 cameras and 37 sensors. The behaviour of this aggregated traffic is similar to the video traffic displayed in Figure 3(a), because the traffic sent by cameras is much greater than the one sent from sensors. Packet loss was very large in the case of 10 Mbps bandwidth, whereas there was no packet loss with 100Mbps bandwidth.Figure 6
Throughput using 10 cameras and 37 sensors.The delay and jitter results shown in Figure7 confirm the results of Figure 6. The delay and jitter are negligible in the case of 100 Mbps, but the delay and jitter are very high in some congestion periods in the case of 10Mbps, influencing QoS. The best option in this case is 100 Mbps because 10 Mbps is definitely not large enough. The necessary bandwidth to satisfy the desired QoS must be about 30 Mbps, because the 100 Mbps bandwidth is too much and in consequence expensive. An optimum bandwidth value for this intelligent municipal heritage management service with 10 cameras and 37 sensors must be around 25 Mbps.Figure 7
(a) Delay and (b) jitter using 10 cameras and 37 sensors.
(a) (b)


## 5. Conclusions and Future Work

This work has allowed a first evaluation of the communications associated with an intelligent heritage management system meeting the specifications of the smart city of Valencia. For this, several types of traffic sources working in a heritage management environment were characterized. These sources were video cameras and three types of sensors (temperature and humidity sensors, lighting and ultraviolet sensors, and gas sensors). Specific models of video camera and sensors were selected, modelled, and simulated in OMNET++. The selected sensor and camera models met the specifications of the intelligent cultural heritage management project of the Valencia smart city.Two sets of simulations were performed. First, each type of source was simulated individually to determine the optimal QoS parameters associated with each source. Minimum values of CIR and PIR were determined to avoid packet loss in each type of source. The second simulation including all the traffic sources evaluated the effects of a limited bandwidth over the QoS.From the evaluation of intelligent municipal heritage management service, the following conclusions about QoS mechanism and bandwidth have been achieved:(1)
The predominant traffic in heritage management service comes from video cameras. The traffic from sensors is negligible compared with the cameras one.(2)
The simulation tools provide a flexible and economical mechanism to evaluate the impact on the municipal network of projects that generate heterogeneous traffic with finite sources.(3)
Low CIR and PIR limit the throughput and cause delay, jitter, and packet loss. But high CIR and PIR increase the cost; thus it is necessary to ensure the QoS with minimum CIR and PIR.(4)
The optimization by simulation of the CIR and PIR needs to perform an iterative process divided into two steps. The first step is to obtain CIR and PIR necessaries for sources and the second step to adjust CIR and PIR of the whole communications network.The simulation of the telecommunication network allows selecting minimum values for PIR and CIR and to optimize teletraffic costs associated with intelligent municipal heritage management service. By this way, it is possible to have a correct estimation of communication needs and costs before service deployment.As future lines of work, it would be interesting to evaluate the influence on the municipal network of new projects sharing the available bandwidth with an intelligent municipal heritage management system. In addition, after the deployment of the intelligent municipal heritage management system, the goodness of the evaluation performed in this work will be verified with real traffic data.



---

*Source: 8412542-2019-02-07.xml*