1 Introduction

Large-scale surveillance systems are becoming essential part of today civil defense systems. Such systems are widely deployed in our cities and urban communities. Currently, wireless-based video surveillance approach is commonly used to insure a real-time objects monitoring. Using wireless-based surveillance system is showing a momentum for its low overhead and affordable deployment cost [5, 26, 33–35, 48]. Wireless-based large-scale video surveillance systems require the deployment of huge number of cameras in geographically distributed areas to achieve its objectives. This system of connected cameras is usually connected through the Internet to one or more video data aggregation centers.

Wireless-based video surveillance systems characteristics are similar to what it is known today as the Internet of Things (IoT), where the things in the video surveillance system are the cameras. The video surveillance system can exploit the existing Internet infrastructure which offers a low cost and ubiquitous connectivity. The video data collected by the set of deployed cameras are transferred to a centralized point or set of points that will complete the surveillance process by performing an automatic video analysis in real time.

The main challenge of such system is related to the amount of video data generated by the things (i.e., the cameras) which requires a very high channel bandwidth at the wireless link side (i.e., the Internet) and a huge computing and storage capacity at the processing side (i.e., the centralized data aggregation point).

In this paper, we utilize two new technologies to handle the aforementioned challenges, namely, the cloud and the Mobile Edge Computing (MEC) [21, 22]. The MEC system will help in managing data collection and bandwidth management to insure efficient data transfer to the processing side of the system, while the cloud system will offer virtually unlimited resources capacity to perform video storage and analysis in real time. Specifically, we propose an IoT-based framework that provides an automated video surveillance solution. The framework supports a set of camera sensor groups. Each group is connected to an MEC server that is colocated with the base station that this group of cameras is connected to. This group of cameras can use the communication technology supported by the base station. A set of these groups are connected through the Internet to a central cloud server. The cameras capture and stream videos to the MEC servers. Each MEC server stores the video locally and then forwards it to the central cloud server. The MEC server may keep the video locally until it guarantees the reception of the video by the cloud and it then can delete it.

The framework provides a reliable surveillance video storage, on the central cloud server, with an optimal quality that fully utilizes the total central cloud provided bandwidth. Bandwidth management and allocation are done in two parts. Within the cell, and among the cameras in the group connected to the same base station, the bandwidth management and allocation are done by the MEC server colocated with that base station. Globally, among the MEC servers, the cloud server distributes the available bandwidth among the cells.

We evaluate our framework using NS-3 simulation. We stream real MJPEG video from the cameras over a simulated network and evaluate the system by measuring the video quality at the cloud server. The results show that the framework is highly scalable and fully utilizes the cloud available bandwidth.

2 Background and related work

2.1 IoT

Internet of Things (IoT) is a network that connects objects of any types. Objects can be any electronic or mechanical devises, persons, animals, or any thing else with a unique identifier. The network can be of any type as well. The development of IPv6 make the implementation of IoT more possible as it can identify very large number of object uniquely. IoT has many applications in the fields of agriculture [16, 37], building management [4], health [18–20, 25, 46, 47], energy saving [15, 29, 32], security [27, 38, 43] and surveillance [3, 10, 28, 41], transportation [8], and many many more.

The most related work to the framework proposed in this paper is the work done in [3]. The authors proposes the skeleton of a face recognition-based video surveillance system. In the framework, they did not provide much details other then that they say that integrating a cloud server with a set of camera sensors to perform the required video processing solves all the problems of the system which are the high bandwidth and processing demands.

2.2 MEC

The number of mobile users and mobile applications is increasing dramatically. In traditional mobile systems that are integrated with cloud computing systems, this increase in users and applications produces high load on the core cloud servers as well. And because these cloud dependent applications rely heavily on services hosted by or performed by the cloud servers, a huge amount of data are uploaded from the mobile devices and downloaded from the core cloud servers. Consequently, network bandwidth consumption in these systems is continuously increasing. Adding to that the bandwidth demands introduced by the introduction of the Internet of Things (IoT). To deal with the growing bandwidth demands, network resources utilization needs to be improved. Moreover, enhancing network resources is needed. Furthermore, new advanced technologies should be adopted to enhance the QoS provided to end users. Long-term evolution (LET) one of the technologies that are proposed to increase the network bandwidth. However, employing new technologies requires further investments which causes higher operational cost. Recently, Mobile Edge Computing (MEC), described for the first time by Akamai et al. [13] when they described their content delivery network topology, has been proposed to overcome this issue in certain scenarios.

MEC has been proposed to ease the application development and data communications in mobile networks. The main services offered by MEC are data caching and/or providing the required processing power for the relevant data at the edge of the mobile network. Despite the fact that MEC is not yet utilized in real systems, many researchers studied and analyzed many MEC technical details and concepts. In MEC, a distributed services platform is employed instead of using a centralized platform to serve all mobile users and applications. This platform can be built by providing cloud servers on the edge of the mobile network. Initially, MEC was used to cache some of the frequently requested contents at the network edge [13]. Recent studies [2, 7, 14, 44] propose the use of MEC with cloud computing to provide more complex services at the edge of the network. Traditionally, devices at the mobile network edge are only mobile access points, also known as base stations (BS). The BS rule is to forward traffic coming from mobile devices to a connected network and in the opposite direction. BS does not provide any processing or storage capabilities. MEC introduces new network elements at the network edge that provides computational power and storage capabilities. Therefore, these new devices can service user request locally instead of just forward these requests. In the rest of this paper, these devices are referred to as MEC servers.

2.2.1 MEC characterization

Typically, MEC-based systems can be characterized by the following:

  • Self-owned: since the edge is local, this means that it can run in isolation from the rest of the overall network, while having the ability to access local resources. This is important for machine-to-machine scenarios. For example, when users need to deal with high level of security or safety systems.

  • Nearer service: as the users are close to the information source, edge computing is specifically useful to gather important information for analytics and big data, to be able to provide more enhanced services to end users. Edge servers may also have the ability to directly access connected devices, which can easily be leveraged by business specific applications. since edge services run as near as possible to end users, it significantly reduces latency. And can be utilized to respond faster, to enhance QoE, or to reduce congestion in the rest of the network.

  • Network environment information: real-time network data can be used by applications to offer context-related services that can differentiate the experience of mobile broadband and be monetized. Several new applications can be implemented (which will benefit from this real-time network data) to link mobile users with local points-of-interest, events and businesses.

2.2.2 MEC deployment scenarios

According to the Industry Specification Group (ISG),Footnote 1 MEC servers are usually deployed at the base station site of a cell. The cell internal network can be 3G, LTE, or WIFI. The cell site can be indoor within an enterprise (e.g., hospital, university campus, or any large building), or outdoor for a special public coverage scenario such as sport stadiums and shopping malls.

2.2.3 MEC similar platforms

Mobile Edge Computing (MEC), Fog Computing (FC), and Mist Computing (MC) are all terms that have been introduced in the field of mobile cloud computing (MCC). They all refer to a platform, in which a set of devices with limited capabilities can use some nearby resources within nearby devices to accomplish their work.

MCC [12, 24, 45] refers to a platform that provides computation, storage, and applications, as services to mobile users. These services are usually provided by a set of centralized servers that are managed and controlled by the centralized service provider. MCC represents the incorporation between the cloud computing and the mobile devices. MCC provides many benefits, (1) it overcomes the limited mobile devices capabilities, such as the limited battery life, small memory, and the limited bandwidth, (2) it handles some environment difficulties such as heterogeneity and availability, and (3) it improves mobile security, privacy, and reliability. FC is considered as a middle solution between MCC and MEC and is defined as a virtualized platform which is not exclusively placed at the network edge and it can provide cloud services between end users and cloud computing servers [9]. MEC and FC can help reduce service latency and increase execution speed. Even that both MEC and FC seem very similar to grid computing, they defer in that the work distribution logic is implicitly handled by an underlying infrastructure layer, and not explicitly assigned into the applications. Mist Computing is another similar concept to MEC. Mis Computing is something that mix FC and MEC. It extends the traditional client–server approach to a more peer-to-peer based approach. In the rest of this paper, we will use MEC to refer to all of the above concepts.

2.2.4 MEC and Fog computing in the literature

In [2], the authors analyze a system called volley. It addresses the challenges arise from the rapidly growing cloud services across distributed datacenters. These challenges include (1) the need for automated mechanisms for placing application data among different datacenters, taking into account, the WAN bandwidth cost as well as the datacenters capacity limitations, and (2) reducing end user latency considering, shared data, data inter-dependencies, and application changes. Volley is used to automate the process of data placement among geographically distributed datacenters. The authors in [2] claimed that Volley reduces the oblique in datacenters load by more than two times. In addition, it reduces inter-datacenters traffic by more than 1.8 times. Moreover, it reduces latency.

Dsouza et al. [14] proposed a policy-based management framework for fog computing resources, and extended the current fog computing system to make it possible for the users to have a secure communication and resource sharing across distributed environment when requesting resources. The proposed policy includes five modules: (1) Policy Decision Engine which is implemented to make decisions upon data received from all connected components. Based on the requested services and the end user. It also analyzes the rules specified in the Policy Repository and makes a decision which is then enforced, (2) Application Administrator which is responsible for defining policies that provide a specific application to a particular user and ensure secure communication among multiple fog nodes, (3) Policy Resolver which follow attribute-based security procedure in which users are authenticated and identified by a set of attributes which they present, and then these attributes are analyzed by attribute finder scheme and forwarded to the policy resolver for further accumulation, after that the user access is identified based on a set of attributes defined and stored in an attribute repository, (4) Policy Repository which contains a set of rules needed by the Policy Decision Engine when making policy decisions, and (5) Policy Enforcer which resides either within a virtual instance such as fog node, fog instance or cloud datacenter, or within physical devices such as connected vehicle or mobile device.

In [1], the authors propose a communication architecture called smart gateway and its integration with fog computing. The smart gateway refers to the scheme which is responsible for preprocessing and aggregating data before it can be transferred to the cloud to reduce the load on the core cloud. The authors then test their architecture in terms of different delay aspects, including upload and bulk-data upload, synchronization and bulk-data synchronization, and jitter delays. They showed that using smart gateway-based communication with fog computing helps cloud to provide improved services and make it easier and faster to deliver services to applications that require low latency.

In [40], the authors discuss the main advantages that can be achieved when deploying fog computing platform. They also provide an analysis of some application scenarios that can benefit from deploying such a platform. These scenarios include smart grid, smart traffic lights in vehicular networks, and software-defined networks. Then, the authors discuss some security issues within fog computing and provide a case study to illustrate these issues. They studied the man-in-the-middle attack and how it can affects the performance of fog devices such as CPU utilization and memory consumption. Experiments show that man-in-the-middle attack can be very stealthy within fog computing, since it has just a little increase in the CPU utilization and the memory consumption.

3 Proposed framework

In this paper, we propose an IoT-based framework that provides an automated video surveillance solution. As shown in Fig. 1, the framework supports a set of camera sensor groups. Each group is connected to an MEC server that is colocated with the base station that this group of cameras are connected to. This group of cameras can use the communication technology supported by the base station. A set of these groups are connected through the Internet to a central cloud server. The cameras capture and stream videos to the MEC servers. Each MEC server stores the video locally and then forwards it to the central cloud server. The MEC server may keep the video locally until it guarantees the reception of the video by the cloud and it then can delete it.

Fig. 1
figure 1

The proposed framework

Full size image

The framework provides a reliable surveillance video storage, on the central cloud server, with an optimal quality that fully utilizes the total central cloud provided bandwidth. Bandwidth management and allocation is done in two parts. Within the cell, and among the cameras in the group connected to the same base station, the bandwidth management and allocation are done by the MEC server colocated with that base station. Globally, among the MEC servers, the cloud server distributes the available bandwidth among the cells.

3.1 Global bandwidth distribution

The global bandwidth distribution is done periodically by the cloud. Assume that B represents the total bandwidth budget, provided by a cloud service provider, to be used by a surveillance system. Assume also that \(M_i\) represents the ith MEC connected to the cloud, where \(i = 1, 2,\ldots , N\) and N is the total number of MECs connected to the cloud. Moreover, assume that \(c_i\) is the number of cameras connected to the MEC \(M_i\).

The simplest way to calculate the bandwidth for the ith MEC, \(B_i\), is to divide the total bandwidth provided by cloud (B) by the number of connected MECs to the cloud (N) as shown in:

$$\begin{aligned} B_i = \frac{B}{N}. \end{aligned}$$
(1)

This distribution achieves fairness among the areas monitored by different cells. We call this distribution, simple global distribution (SD). As we can see, the only information needed for this distribution is N which is the number of connected MECs. This calculation can be done by the cloud server and a message is then sent broadcasted to all the MEC servers with the total bandwidth that they should use locally.

Another option for bandwidth distribution is to divide the total bandwidth among the MECs, taking into consideration the number of cameras connected to each MEC. Equation 2 shows this calculation:

$$\begin{aligned} B_i = \frac{B}{\sum _{i}^{N} c_i}\times c_i. \end{aligned}$$
(2)

We call this the weighted global distribution (WD). The term \(\frac{B}{\sum _{i}^{N} c_i}\) calculates the bandwidth share of each camera in the system. This term can be calculated by the cloud server after receiving the number of connected cameras \(c_i\) form each \(M_i\). The value is then broadcasted to all participating MECs. Each MEC then can calculate its share form the total bandwidth by multiplying the received term value by the number of cameras connected to the it.

3.2 Local bandwidth distribution

Once each MEC identifies its bandwidth share \(B_i\), it distributes \(B_i\) among the connected cameras in the MEC cell. One can say that the distribution here is very simple. It can be just dividing the MEC bandwidth by the number of cameras connected to the MEC. The problem here is much more complicated than that because of many issues that should be taken into consideration. These issues are as follows:

  • The cell physical bit rate. This is the maximum bit rate (bandwidth) supported by the cell. This bit-rate depends on the communication technology used in the cell.

  • The effective bandwidth in the cell. It is the bandwidth that can be used to deliver the surveillance video streams to the MEC server. In the network, a fraction of the physical bandwidth is consumed by communication protocol overhead. Also another fraction is consumed by communication errors. Moreover, another fraction is consumed by cross traffic in the network. Obviously, the effective bandwidth is much smaller than the physical bandwidth in any network. The effective bandwidth should be always larger then the bandwidth share of the MEC, so that the MEC can utilize all its bandwidth share.

  • Number of cameras connected. This number may change over time because some cameras may become defective or out of battery life.

  • Type of video compression used by the camera. Most surveillance cameras support three compression algorithms: MJPEG, MPEG4, and H.264.Footnote 2 MJPEG takes a quality factor as an input and usually produces better quality video steam with higher rate than the other two compression. The higher the quality factor, the higher the video quality and bit rate. MPEG4 and H.264 takes a bit-rate as an input and produces a video stream with that bit-rate. H.264 provide more compression rate than that of MPEG4.

  • How to force the bandwidth distribution at the cameras.

The work in [5] proposes an optimal solution that can be used to distribute the available bandwidth in a wifi-based cell over a set of cameras to minimize the received video distortion at a central station. In this paper, we consider this as a case study. The central station can be replaced by the MEC server. The solution proposed in [5] is summarized in the following section.

3.2.1 Case study: wifi-based local bandwidth distribution

The study in [5] introduces enhanced distortion optimization (EDO) that manages multiple video sources that stream live videos to a central station. EDO provides a dynamic cross-layer optimization solution that distribute and allocate the network bandwidth among the multiple video sources to minimize the overall distortion of the video streams received by the central station. EDO achieves the bandwidth allocation by dynamically controls the application rate and the link layer parameters in the streaming sources. In building EDO, the bandwidth distribution problem is formulated as a cross-layer optimization problem based the sum of the distortion of all video streams received by the proxy station. In this formulation, the solution is the set of the video sources airtime fractions. The mathematical formulation of the problem was as shown in the following equations:

$$\begin{aligned} F^* = \hbox {arg min} \sum _{s=1}^{S} \hbox {Distortion} (r_s) \end{aligned}$$
(3a)

such that:

$$\begin{aligned} \sum _{s=1}^{S} f_s= & {} A_{\mathrm{eff}} \end{aligned}$$
(3b)
$$\begin{aligned} r_s= & {} f_s \times y_s \end{aligned}$$
(3c)
$$\begin{aligned} 0\le & {} f_s \le 1 \end{aligned}$$
(3d)
$$\begin{aligned} s= & {} 1,2,3, \ldots , S, \end{aligned}$$
(3e)

where \(F^*\) is the set of optimal airtime fractions (\(f_s\)) of all video sources, \(A_{\mathrm{eff}}\) is the total effective airtime which is an estimation of the effective bandwidth in the network, and \(r_s\) and \(y_s\) are the optimal application rate and the physical rate of each source (s), respectively.

To find a solution for the previous formulation, a model is needed for the relationship between the video distortion and the video bit rate. In addition, an estimation is needed for the effective airtime in the network. The work in [5] characterizes the relationship between the distortion and the video bit rate as shown in:

$$\begin{aligned} \hbox {Distortion (RMSE)} = a \times (Z)^b + c, \end{aligned}$$
(4)

where Z is the average video frame size and a, b,  and c are constants. Since the framework uses MJPEG video streams, Z is calculated as \(Z = \frac{R}{\tau }\), where R is the video playback rate and \(\tau \) is the video frame rate.

The work in [5] also uses an online estimation algorithm to estimate the network effective airtime, as shown in Algorithm 1. The algorithm is run on the central proxy station and measure the sum of the ratios of the data dropping to the physical rate of each node. All information needed by the central proxy station about the video sources are sent periodically by the sources to the central proxy station. This value, \(A_\delta \), gives an indication on the performance of the network, and the algorithm adapts the estimated effective airtime \(A_{\mathrm{eff}}\) to get \(A_{\delta }\) very close to pre-specified threshold \(A_{\mathrm{thresh}}\). The algorithm is stopped when the difference between \(A_{\delta }\) and \(A_{\mathrm{thresh}}\) becomes very small.

figure a

The problem formulated in (3) was solved using the Lagrangian relaxation technique [31]. The Lagrangian-relaxed formulation for this problem was formulated as follows:

$$\begin{aligned} L (F^*, \lambda ) = \sum _{s=1}^{S} (a_s({f_s}{y_s}/\tau )^b_s + c_s)+\lambda \left( \sum _{s=1}^{S} f_s - A_{\mathrm{eff}}\right) . \end{aligned}$$
(5)

Then, the Lagrangian conditions were formulated and solved to obtain the equations for both \(\lambda \) and \(f_s\) as shown in the following equations:

$$\begin{aligned} \lambda= & {} \left( \frac{A_{\mathrm{eff}}}{\sum _{s=1}^{S} (\frac{-\tau _s}{{a_s}{b_s}{y_s}(y_s/\tau _s)^{(b_s-1)}})^{(1/(b_s-1))}}\right) ^{(b_s-1)} \end{aligned}$$
(6)
$$\begin{aligned} f_s= & {} \left( \frac{-\lambda \times \tau _s}{{a_s}{b_s}{y_s}(y_s/\tau _s)^(b_s-1)}\right) ^{(1/(b_s-1))}. \end{aligned}$$
(7)

\(A_{\mathrm{eff}}\) in the formulation in Eq. 3, and that is estimated by Algorithm 1, represents the effective bandwidth fraction of the physical bit rate in the cell network. It follows that to calculate the effective bandwidth in the cell network, we can use:

$$\begin{aligned} B_{\mathrm{eff}} = Y \times A_{\mathrm{eff}}, \end{aligned}$$
(8)

where Y is the physical bit rate in the cell network. \(B_{\mathrm{eff}}\) should be compared to the bandwidth assigned to the MEC, \(B_{i}\). If \(B_{\mathrm{eff}}\) is larger than \(B_i\), we should force the cell network to use only \(B_i\). This can be achieved by applying Eq. 9 after finishing the estimation in Algorithm 1:

$$\begin{aligned} A_{\mathrm{eff}} = \left\{ \begin{array}{ll} \frac{B_i}{Y} &{} \quad \hbox { if } B_i < B_{\mathrm{eff}} \\ A_{\mathrm{eff}} &{} \quad \hbox { if } B_i \ge B_{\mathrm{eff}} \end{array} \right\} . \end{aligned}$$
(9)

\(\lambda \) is then calculated at the MEC server using Eq. 6 and broadcasted to all video sources. All information needed to calculate \(\lambda \) are sent periodically by the sources to the MEC server. Once a video source receives \(\lambda \), it calculates its \(f_s\) using Eq. 7 and then it uses Eq. 3c to calculate its application rate. Moreover, to ensure that each video source does not internally drop packets, the link layer parameter is also managed dynamically in such a way that the data received from the application layer is transmitted accordingly, once a channel access is gained.

3.3 Possible enhancements

As we can see in Eq. 9 that if \(B_i\) is greater than \(B_{\mathrm{eff}}\), nothing is being done and the bandwidth difference between \(B_i\) and \(B_{\mathrm{eff}}\) is a cloud bandwidth is waisted without being utilized. The cloud bandwidth can also be waisted if the cloud-MEC link bandwidth is smaller than \(B_i\). In the later case, many data would be lost or a huge delay can happen in communicated the video stream from the MEC to the cloud.

The first problem can be solved by making the MEC that has a smaller \(B_{\mathrm{eff}}\) to inform the cloud with the maximum bandwidth that it can support, so that the cloud will not assign more bandwidth to it.

The second problem can be solved by making the cloud estimate the cloud-MEC link bandwidth during a period of time. The cloud should use this estimation into consideration when it distributes the available bandwidth over the participating MECs for the next period. This assures that the bandwidth is always fully utilized. The estimation should be done while the video stream is being sent from the MEC to the cloud without sending any extra data.

4 Evaluation

Several experiments were conducted using NS-3 [42] simulator version 3.22. We have extended the simulation framework that have been built in [6] and [30] to simulate the proposed framework.

We construct and stream real MJPEG videos from the video sources to the MEC and then to the cloud over the simulated network. We use the approach used in [5] to achieve that. The MJPEG video stream are sent as Real-time Transport Protocol (RTP) Packets. The MJPEG streams are constructed using the CMU/MIT [11] and the Georgia Tech [17] image databases. The frames in each video stream are randomly selected from those image databases and packetized as RTP packets and are sent over cell network to the MEC server. The MEC server then forwards those packets to the cloud server. The application layer at the cloud server, upon receiving all the RTP packets of a video frame, reassemble the RTP packets a to form the video frame. An error concealment algorithm [39] is used to reconstruct the video frames with lost RTP packets.

The network topologies used in our experiments are constructed using 5, 10, 15, and 20 cells. Each cell uses 802.11g wifi standard. Each cell has an MEC server that manages several video sources.

Two scenarios regarding the cloud-MEC link bandwidth are considered in this paper. We call the first one The Relaxed Scenario, and the second one The Limited Scenario. In The Relaxed Scenario, the number of video sources in each cell is chosen randomly, between 5 and 25 video sources, and the bandwidth of the links that exist between the MECs and the cloud, is randomly selected between 4 and 100 Mbps. The Limited Scenario is used to represent a more congested topology in which the bandwidth of the Cloud-MEC link is limited. In this scenario, the number of video sources in each cell is chosen randomly between 5 and 30 video sources and Cloud-MEC link bandwidth is randomly generated between 4 and 24 Mbps.

The random selection of Cloud-MEC link bandwidth is to represent different link types.

In our experiments, we tested four variations of our framework for both scenarios (Relaxed and Limited).

  • Local management (LM). In this variation, the framework only performs bandwidth management within the cell. Each MEC server send as much data as it wishes to the cloud. The cloud will only receives data according to its budget which causes many data to be lost. This variation shows the importance of the global bandwidth management.

  • Local management with global simple distribution (LM-SD). In this variation, we use local management with the global simple bandwidth distribution (SD) described in Sect. 3.1.

  • Local management with global weighted distribution (LM-WD). In this variation, we use local management with the global weighted bandwidth distribution (WD) described in Sect. 3.1.

  • Local management with an enhanced global weighted Distribution (LM-WD-Enhanced). In this variation, we use local management with the global weighted bandwidth distribution (WD) described in Sect. 3.1. We further enhanced this variation by incorporating the enhancements descried in Sect. 3.3. To achieve the proposed enhancements, the MECs send a control message to the cloud informing it about its \(B_{\mathrm{eff}}\). Also, the cloud estimates the link bandwidth between the MEC and the cloud. The control messages and the bandwidth estimation should be executed periodically. We choose period length to be 5 min.

Table 1 summarizes the main simulation parameters.

Table 1 Main simulation parameters used in the AVS simulation framework
Full size table

4.1 Performance metrics

In this paper, we use the following performance metrics:

  • Peak signal-to-noise ratio (PSNR) is one of the most used metrics to assess the video transmission QoS at the application level. PSNR is described by the International Telecommunication Union [36] as:

    $$\begin{aligned} \hbox {PSNR}(n)_{\mathrm{db}} = 20 \ \log {\left[ \frac{V_{\mathrm{peak}}}{ \root \of {\hbox {MSE}(n)}}\right] }, \end{aligned}$$
    (10)

    where \(V_{\mathrm{peak}} = 2^{k}-1\), k represent the number of bits used to represent the pixel. Mean square error (MSE) is the error variance estimation, and MSE value is calculated as:

    $$\begin{aligned} \hbox {MSE}(n) = \frac{\sum _{i=1}^{N_{\mathrm{col}}} \sum _{j=1}^{N_{\mathrm{row}}} [Y_\mathrm{S} (n,i,j) - Y_\mathrm{D} (n,i,j)]^2 }{N_{\mathrm{col}} N_{\mathrm{row}}}, \end{aligned}$$
    (11)

    where \(N_{\mathrm{row}}\) and \(N_{\mathrm{col}}\) are the number of rows and columns in the image, i and j are the current position of column and row, n is the number of the current frame, \(Y_\mathrm{S}\) is the luminous component of the source image, and \(Y_\mathrm{D}\) is the luminous component of the destination image as defined in [23].

  • The overall received data rate it is the total amount of data received at the cloud server during a specific period time from all cameras averaged over time. It is calculated as the total size of the packets received from all cameras divided by the time in which the data is collected. In our experiments, the overall received data rate is calculated for each second. Eventually, these values are averaged to calculate the overall average.

  • Packet delay the amount of time needed for a packet to be transmitted along its entire path in the network. Packet delay is caused by (a) processing delay, which is the time required to analyze, process, and decide where the packet will be sent, (b) buffer delay, which is the time that a specific packet stay in the queue until it is dequeued to be transmitted, (c) transmission delay, which is the total time in which all the packet bits are pushed to the desired transmission medium, and (d) propagation delay, which is the time duration for the bit to propagate across the network until it reaches the end of its physical trajectory. In calculating the average delay, in each experiment, we use the time difference between the time at which the packet is received at the cloud server application layer and the time when the packet was sent from the camera application layer. At the end of each second, the average delay of all packets received within that second is calculated and then the average of these averages is calculated.

  • Overall network load it is the total traffic (data) rate generated by all video sources in the network. The sending rate of each video source is calculated in the application layer as the total size of data packets sent to the AP divided by the time in which the data is collected. In our experiments, the sending rate is calculated each second and then it is stored. Then, the average sending rate is calculated for each video source as the average of the stored sending rate values. Eventually, the overall network load was calculated as sum of the average sending rates of all video sources participating in the experiment.

  • Overall retransmission dropping rate it is the total rate of data dropped in the MAC layer due to exceeding the maximum retransmission tries. Each packet maintain a number of sending tries counter. Whenever an acknowledgment of a data packet is not received within a specific time period, the packet is considered to be lost and should be retransmitted, and the sending tries counter is increased by one. If this counter, however, exceeds a specific retries number, the packet is not retransmitted and considered as a dropped packet. The retransmission dropping rate is calculated in each video source, as the total size of data in the packets that are dropped because it exceeded retransmission tries, divided by the time in which the data is collected. In our experiments, the retransmission dropping rate is calculated each second and then it is stored. Then, the average retransmission dropping rate is calculated as the average of the stored values. Eventually, the overall retransmission dropping rate is calculated as sum of the average retransmission dropping Rate of all video sources participating in the experiment.

  • Overall buffer dropping rate it is the total rate of the data dropped in the MAC layer due to overflow in the MAC queues. Each MAC queue has a limit on the size of data that it can store. Whenever the MAC queue is full, any data that arrives from the upper layers is dropped immediately. The buffer dropping rate is calculated in each video source, as the total size of data in the packets that were dropped (because the buffer was full) divided by the time in which the data are collected. In our experiments, the buffer dropping rate is calculated each second and then it is stored. Then, the average buffer dropping rate is calculated as the average of the stored values. Eventually, the overall buffer dropping rate is calculated as the sum of the average buffer dropping rate of all video sources in the network.

Fig. 2
figure 2

Comparison of the variations of the proposed IoT-based framework (G-T image set, relaxed scenario)

Full size image
Fig. 3
figure 3

Comparison of the variations of the proposed IoT-based framework (CMU-MIT image set, relaxed scenario)

Full size image
Fig. 4
figure 4

Comparison of the variations of the proposed IoT-based framework (CMU-MIT image set, limited scenario)

Full size image

5 Results

In this section, we compare the results of simulating all the variations of the proposed IoT-based video surveillance system in NS-3 for both the relaxed and the limited scenarios. The results have been compared using the performance metrics described in Sect. 4.1. The used metrics are perceptual video quality, the overall received data rate at the cloud application layer from the all of the video sources, average packet delay of the video, complete received video frames percentage, incomplete received video frames percentage, missed video frames percentage, overall network load, total buffer dropping, and total retransmission dropping rate.

Figure 2 shows the results obtained by running the simulation of the relaxed scenario with streaming videos that are constructed using the G-T image database.

Figures 3 and 4 show the results obtained by running the simulation in the Relaxed and the Limited scenarios, respectively, with streaming videos that are constructed using the CMU–MIT image database.

These results show that the LM-SD outperforms the LM variation in terms of the important video performance metrics which are PSNR, Packet Delay, and the percentages of complete, incomplete, and missed video frames while, at the same time, requiring a lower amount of data received at the cloud. These results proofs that global management is very important to the performance of the system. In addition, the results show that the LM-WD approach provide slightly better performance when compared to the LM-SD variation. This means that taking the number of cameras into consideration in the global bandwidth solution is important to enhance the performance of the system. Furthermore, the results show that LM-WD-Enhanced outperforms all of the previous approaches since it utilizes the cooperation of the cloud and MEC server. Those results have the same trend in both the Relaxed and the Limited Scenarios. The results of the limited scenario with the G-T image set follow the same trnd and thus not shown.

Those results show the effectiveness of the proposed IoT-based surveillance framework in its capabilities to include a large number of MECs with while maintaining high quality and lower bandwidth/storage cost at the clouds side.

6 Conclusion

In this paper, we presented a reliable IoT-based wireless video surveillance system. The system provides an optimal bandwidth distribution and allocation to minimize the overall surveillance video distortion. We exploited two new emerging technologies to provide a reliable data transfer medium using mobile edge technology and sufficient capacity for data processing and storage using cloud. The proposed surveillance system is evaluated using NS-3 simulation. The results show that the proposed framework fully utilizes the available cloud bandwidth budget and achieves high scalability. Results can be summarized as follows.

  • Global management that is conducted by the cloud is very important to the performance of the system.

  • Taking the number of cameras, connected to each MEC, into consideration in the global bandwidth management is important to enhance the performance of the system.

  • The cooperation of the MEC and the cloud server can enhance the system performance further.

As a future work, we plan to study the system using different video streaming technology. We also plan to propose and study an extension of our framework to secure the video stream communication.