Automated wireless video surveillance: an evaluation ...

J Real-Time Image Proc DOI 10.1007/s11554-016-0631-x

SPECIAL ISSUE PAPER

Automated wireless video surveillance: an evaluation framework Mohammad A. Alsmirat1 • Yaser Jararweh1 • Islam Obaidat1 • Brij B. Gupta2

Received: 5 May 2016 / Accepted: 12 August 2016 Springer-Verlag Berlin Heidelberg 2016

Abstract In the past years, surveillance systems have attracted both industries and researchers due to its importance for security. Automated Video Surveillance (AVS) systems are established to automatically monitor objects in real-time. Employing wireless communication in an AVS system is an attractive solution due to its convenient installation and configuration. Unfortunately, wireless communication, in general, has limited bandwidth, not to mention the intrinsic dynamic conditions of the network (e.g., collision and congestion). Many solutions have been proposed in the literature to solve the bandwidth allocation problem in wireless networks, but much less work is done to design evaluation frameworks for such solutions. This paper targets the demand for a realistic wireless AVS system simulation framework that models and simulates most of the details in a typical wireless AVS framework. The proposed simulation framework is built over the wellknown NS-3 network simulator. This framework also supports the testing and the evaluation of cross-layer solutions that manages many factors over different layers of AVS systems in the wireless 802.11 infrastructure network. Moreover, the simulation framework supports the collection of many used performance metrics that are usually used in AVS system performance evaluation.

& Mohammad A. Alsmirat [email protected] 1

Department of Computer Science, Jordan University of Science and Technology, Irbid, Jordan

2

National Institute of Technology Kurukshetra, Kurukshetra, India

Keywords Automated Video Surveillance Bandwidth optimization Online bandwidth estimation Simulation framework Video distortion

1 Introduction Traditional surveillance systems, such as the closed circuit television (CCTV) system, have served vast security applications in everyday life. The deployment of video surveillance systems has manifold reasons. Commonly stated, these reasons are preventing crimes and vandalism, ensuring public safety, as well as investigating illegal felonies [1]. Surveillance systems consist, in general, of several video sources (cameras) that can be analog or digital. These cameras stream video over a connection (wired or wireless) to a storage system, a processing system, and/or to a set of monitors. Usually, surveillance cameras are installed in public sites, such as buses or train stations, highways and roads, shopping malls, and in sports stadiums. Nevertheless, video surveillance is not only deployed in public, but also, in many cases, it is deployed in private sites such as private companies and buildings [2]. Modern video surveillance systems have moved to use digital equipments to utilize the benefits of the digital video representation and communication [3–5]. The digital video sources, in these systems, gather live video streams from the monitored zone. These video sources are usually set up with an encoding (compression) system to reduce the captured video stream size while maintaining an acceptable video quality. Most of the transmission media have limited bandwidth, and the video storage system also has limited storing capabilities. Thus, there is a need to better utilize these resources. The encoding systems come to meet

123

J Real-Time Image Proc

this need. Several video coding standards exist to reduce the size of the video data in order to be able to transmit and/or store this data. The encoded multimedia data are then transmitted to a server to be processed or stored for surveillance purposes. In the traditional surveillance systems, lots of monitoring risks exist. The constant video flow renders a large amount of data with no useful information. For monitoring purposes, a human is assigned for monitoring the system. This operation model does not always provide an accurate detection of threats and requires significant labor. Therefore, the monitoring process must be automated. Automated Video Surveillance (AVS) systems attempt to mitigate the burden on humans by applying computer vision algorithms on the captured videos to detect motions or objects [6–11]. These algorithms can be used to trigger an alarm in case of a specific scenario. Employing wireless communication in AVS systems has several advantages. Wireless communication requires very little infrastructure construction. With the advance of modern technology, wireless communication systems have become more affordable and reliable. Accordingly, many camera monitoring systems employ wireless technology nowadays. However, employing wireless communication in an AVS system faces several challenges. Wireless communication in general has a limited bandwidth, not to mention the intrinsic dynamic conditions of the network (e.g., collision and congestion). Thus, this platform must be dynamically adjusted to yield reliable and high quality AVS system. These problems have attracted the attention of many researches. The work in [12] builts a framework that optimizes the network bandwidth available in a wireless AVS system. The wireless AVS system considered consists of multiple video sources that stream videos to a central proxy station. The framework in [12] provides a cross-layer optimization solution that distributes and allocates the network bandwidth among the video sources. This framework manages the application rates and the Transmission Opportunities (TXOP) of the various video sources based on the dynamic network conditions in such a way that minimizes the overall video distortion of the video streams received at the proxy station. This framework was evaluated using the OPNET simulator [13]. OPNET is well known for its accuracy in modeling the different components of different types of networks. Unfortunately, OPNET is a commercial simulator, which requires a license to be used. Academic users can acquire a free license for only 6 months. Because of this limitation in OPNET, NS-3 [14] is a great alternative with high flexibility and portability. NS-3 is an open source network simulator licensed under the GNU GPLv2 license. NS-3

123

development started initially in 2006 in order to be used for educational and network research purposes. Moreover, NS3 provides a vast set of models for different network components and protocols. Furthermore, lots of effort are invested in NS-3 to enhance the current network modules and to implement new ones. In this paper, we aim to extend NS-3 to be able to simulate AVS related components. Specifically, we aim to port the framework proposed in [12] to the NS-3 simulator. Three parts should be done to complete this work: •

•

1

Make sure that the underlying wireless network is simulated properly in NS-3 The IEEE 802.11 standard [15] is one of the most widely adopted wireless communication standards. It is commonly used for wireless local area networks (WLAN) in infrastructure mode due to its easy deployment and use. However, due to the characteristics of the wireless connections, wireless communication sustains performance drawbacks. The IEEE 802.11 thus, should provide appropriate wireless services to overcome these drawbacks, especially for time sensitive applications. The wireless network connection should guarantee quality of service (QoS) levels for real-time applications such as multimedia applications. The IEEE 802.11 1999 standard [15] defines the medium access control (MAC) and a set of physical layer specifications that can go with it. The MAC, in the standard, utilizes a Distributed Coordination Function (DCF) as one of its channel access method. DCF is a contention-based mechanism that does not provide QoS for time sensitive applications. The IEEE 802.11e [16] came out to address this need. As the aim of this paper is to simulate AVS in NS-3 in infrastructure mode, it is required to have IEEE 802.11e EDCA fully implemented. NS-3 provides most of the required network platforms. However, not all EDCA components are implemented in NS-3. NS-3 supports only the use of CWmin , CWmax , and AIFS to prioritize traffic, but it does not implement TXOP.1 In this work, we complete the NS-3 EDCA implementation by implementing the TXOP full functionalities. According to our knowledge, there are no researches in the literature that present any results of using a fully implemented EDCA in a hardware testbed. For this reason, the modified NS-3 EDCA implementation is verified against the OPNET simulator implementation. Provide an application layer that streams real video over a simulated network The cross-layer framework in [12] used real video streaming over a simulated network. Thus, this work also creates a realistic

https://www.nsnam.org/docs/models/html/wifi-design.html#scopeand-limitations.


•

application layer for the NS-3 simulator. This application layer constructs a real Motion JPEG (MJPEG) video stream from a set of standard image sets. Implement the cross-layer solution proposed in [12] to NS-3 Eventually, the cross-layer solution is completely ported to the NS-3 simulator. In this framework, network physical rate, packet dropping rate, throughput, and number of nodes in the network are collected from different layers and each nodes adapt its application rate and link layer parameters dynamically.

access to the medium by giving them a specific slice of time to do that. 2.2 EDCA To support QoS in the 802.11 standards, an amendment came out in 2005 [16]. The amendment defines two new medium coordination functions that overwrite DCF and PCF, respectively: Enhanced Distributed Channel Access (EDCA) and Hybrid coordination functions Controlled Channel Access (HCCA). EDCA mechanism prioritizes data traffic to achieve QoS. Four main components implement EDCA and work together to provide QoS: Arbitration Inter Frame Space (AIFS), Transmission Opportunity (TXOP), Contention Window Min (CWmin ), and Contention Window Max (CWmax ). In order for a node to gain access to the medium, the medium should be sensed idle for AIFS time. This determines the time to wait before an Access Category (AC) starts transmitting data. When an AC gains the medium it keeps transmitting data for a duration known as Transmission Opportunities (TXOP) time limit. If a collision occurs or if the medium is found busy when sensed, the AC backs off for a random time between 0 and the value of a variable called Contention Window (CW). CW is initialized to CWmin and then at each transmission failure, it is incremented until it reaches CWmax . When it reaches CWmax , it is reset to CWmin in case of a successful transmission. If the medium is sensed idle for at least AIFS time, the backoff timer is decremented and a transmission retry occurs when the timer reaches 0. The values of a QoS-Parameter depend on the underlying physical layer used. Table 1 shows the standard QoSParameter values for different ACs in 802.11b and 802.11g standards. Note that the values of CWmin , CWmax and AIFSN are in time slots. Two acknowledgment modes are supported in EDCA. The first mode is known as intermediate acknowledgment. In this mode, upon sending a packet, the sender waits for an acknowledgment in order to process the sending of the next packet. When the acknowledgment is received, the next packet is sent directly after Shot Frame Inter Space (SIFS) time within the same TXOP duration. The second mode is block acknowledgment (BA). With BA, all the packets that

The main contributions of this work can be summarized as follows. (1) Complete the EDCA implementation in the NS-3 simulator by implementing the TXOP component. (2) Create a realistic MJPEG application layer that streams a video data over NS-3. (3) Port the framework in [12] accurately to the NS-3 simulator.

2 Background information and related work 2.1 IEEE 802.11 IEEE 802.11 standard was introduced by the IEEE committee for wireless communication standardization in 1999 [15]. IEEE 802.11 is used and supported widely by numerous number of currently used wireless communication devices. IEEE 802.11 is a set of standards where it describes the physical and the medium access control (MAC) layers in wireless local area networks (WLAN). Within the first release of the 802.11, there were two options for the MAC layer to be used for managing the device access to the wireless channel [15]. The first one is the centralized control approach which is known as the Point Coordination Function (PCF). The second one is a contention-based scheme called Distributed Coordination Function (DCF). DCF is based on Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA) mechanism. It is a method for medium access that utilizes multiple contentions to reduce collisions. It also ensures that only one radio transmitter is sending at any specific time. The DCF allows only best effort facility without QoS guarantee [15]. PCF is optional and only works in infrastructure mode in which there is an access point that coordinates the nodes Table 1 Default EDCA parameter set

AC

CWmax

CWmin 802.11b

802.11g

AC_BK

31

15

1023

AC_BE

31

15

1023

AC_VI

15

7

AC_VO

7

3

AIFSN

TXOP 802.11b

802.11g

7

0

0

3

0

0

31

2

6.016 ls

3.008 ls

15

2

3.264 ls

1.504 ls

123


are sent within a single TXOP are separated only by SIFS time, and they are acknowledged using only one block acknowledgment. In this work, we use the first mode as it is more common. 2.3 NS-3 NS-3 is an open source event-driven network simulator licensed under the GNU GPLv2 license. Started initially in 2006 in order to be used in education and network researches, NS-3 was developed mainly to replace NS-2 [17]. However, NS-3 is not considered to be a refinement of the aforementioned NS-2 simulator. NS-2 uses OTcl as scripting environment. On the other hand, python scripts and C?? programs are used to define simulations in NS-3 and hence NS-3 is not backward compatible with NS-2. The basic 802.11 DCF implementation in NS-3 is clarified in Fig. 1. This figure shows the components that a packet passes through when being received by the MAC from the upper layers. When a packet is sent down from the upper layers, it is added to the DCF queue (implemented as DcaTxop in Fig. 1). The DCFManager keeps on sensing both Physical (represent the medium physically) and MAC low (represent the medium virtually) until they become idle. Physical medium is sensed using Clear Channel Assessment (CCA), and virtual sensing occurs in the MAC low using Network Allocation Vector (NAV) counter. As soon as an idle state is sensed, the first available packet in the DCF queue is dequeued and sent down to the MAC low. MAC low adds MAC header and trailer to the packet in order to form a MAC Protocol Data Unit (MPDU) or a MAC Service Data Unit (MSDU). Then the MSDU or MPDU is sent to the Fig. 1 DCF MAC and physical implementation in NS-3

123

physical layer to be processed and sent over the medium. When the packet sending is done, the medium is released to be used by another node to send its data. If the queue still has packets to be sent, the previous process (sensing, gaining medium and then send.) must be done again. Figure 2 shows the current NS-3 implementation of EDCA. The implementation is done on top of the DCF implementation with some modifications. Note that instead of one DCF queue, multiple EDCA queues exist (four queues to represent the four Access categories). Each queue has its own DCFState object that holds its own values of CWmin , CWmax , and AIFS. Those four queues perform access to the medium separately as if they are four different DCF nodes. The current NS-3 implementation of EDCA only sends one packet when gaining a channel access and then releases the medium. The node has to contend for the medium again in order to send another packet. TXOP, in contrast, is a time limit (named usually as TXOP limit) during which the node should be able to send as much data as it can, while the TXOP time duration is not expired. 2.4 Performance metrics In this paper, we use the following performance metrics. •

Average throughput it is the total amount of data received at the access point (AP) during a specific time period from all nodes that are connected to this AP averaged over time. The average throughput is calculated in the AP application layer as the total size of the packets received from all stations divided by the time in which the data is collected. In our experiments, the

J Real-Time Image Proc Fig. 2 EDCA MAC and physical implementation in NS3

•

•

throughput is calculated each second and then it is stored. Eventually, the Average Throughput is calculated as the average of the stored throughput values. Average Throughput is also termed as the overall received data rate in some experiments. Average 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 stays in the queue until it is dequeued to be transmitted, (c) transmission delay, which is the total time during 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 AP application layer and the time when the packet was sent from the sender 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. 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 [18]: V peak PSNRðnÞdb ¼ 20 log pffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffi ð1Þ MSE(n)

•

•

where Vpeak ¼ 2k 1 and k represents the number of bits used to represent the pixel. Mean Square Error (MSE) is the error variance estimation. It is calculated as: PN col PN row MSEðnÞ ¼

i¼1

j¼1

½Y Sðn; i; jÞ Y Dðn; i; jÞ2 Ncol Nrow

ð2Þ

where Nrow and Ncol 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, YS is the luminous component of the source image YD is the luminous component of the destination image as defined in [19]. 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 are 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 is 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 maintains 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

123


MAC queues. Each MAC queue has a limit on the size of data it can store. Whenever the MAC queue is full, any data that arrives from the upper layers are dropped immediately. The buffer dropping rate is calculated in each video source, as the total size of data in the packets that got 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 and stored for each second. 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.

3 TXOP implementation As discussed before, the NS-3 implementation of EDCA lacks TXOP implementation. In this section, we follow the details of completing the EDCA NS-3 implementation by implementing TXOP as it should be. With the complete implementation, the node that gains a channel access should be able to send as much data as it can during the TXOP duration. Let us start by discussing the current NS-3 EDCA implementation that is depicted in Fig. 2. When a packet arrives from the upper layers of the node, it is enqueued in one of the EdacaTxopN queues based on the packet traffic type using EdcaTxopN :: Queue function. The EdcaTxopN :: Queue function, then invokes the EdcaTxopN :: StartAccessIfNeeded function. EdcaTxopN :: StartAccessIfNeeded uses the DcfManager class to call the DcfManager :: RequestAccess function in order to check if the medium is idle. If the medium is not idle, the backoff mechanism is performed. If the DcfManager detects an idle medium, DcfManager :: DoGrantAccess function is called. This function checks for any internal Fig. 3 UML diagram of TXOP amendments in NS-3

123

collision that may occur between the EDCA queues. If no internal collision is detected, then the EdcaTxopN :: NotifyAccessGranted function is called. This function then extracts a packet from the queue and call MacLow :: StartTransmission function. As MacLow :: StartTransmission function is called, it creates an acknowledgment event and forms the MAC Service Data Unit (MSDU) or MAC Protocol Data Unit (MPDU). The processed frame is then sent to the physical layer to be processed and sent over the transmission medium. The node then waits for an acknowledgment. If an acknowledgment is received before the acknowledgment time is expired, the acknowledgment event is canceled and then EdcaTxopN :: GotAck function is called. This function calls the EdcaTxopN :: RestartAccessIfNeeded function to check if there is still any packet in the queue to re-contend for the medium again. If no acknowledgment is received, the acknowledgment event time expires. As soon as this event expires, the EdcaTxopN :: MissedAck function is called. This function stores the packet that has not been sent to try to send it again. This function also increases the packet retry count. If the packet exceeds the retry limit, it will be dropped. After that the EdcaTxopN :: RestartAccessIfNeeded is called to re-contend for the medium. If any collision is detected in the previous process, the node immediately releases the medium and call EdcaTxopN :: RestartAccessIfNeeded function. In NS-3, each EDCA queue is an object of the EdcaTxopN class. Each queue has its own object of the DCFState class which stores different values of CWmin , CWmax and AIFS. Since each queue should also have its own value of TXOP limit according to the standard, we find it convenient to add our TXOP implementation attributes and functions to the DCFState class. The proposed changes are shown in Fig. 3. The proposed implementation changes can be summarized as follows.

J Real-Time Image Proc Fig. 4 TXOP burst transmission procedure

•

•

Support enabling or disabling TXOP Because both the EdcaTxop class and the DcaTxop class share the DCFState class, it is necessary to add a mechanism that prevents the DcaTxop class from using the TXOP implementation. For this purpose, qos_s, which is a flag that indicates the enabling of using the TXOP implementation, is added to the DCaTxop class along with the function setQoS to set qos_s to true for the EdcaTxop class and false for the DcaTxop class. Initializing and tracking TXOP duration The attribute txop_limit, defined of Type ns3 :: Time, is assigned a value using the DcfState :: SetTXOP function and its value can be obtained using the DcfState :: GetTXOP function. txop_limit stores the value of the default TXOP limit stated in the standard. The value of txop_limit for each EdcaTxopN is assigned based on its Access Category and the physical standard. The values of CWmin , CWmax , AIFS, and txop limit are assigned in the wifi-mac class. The SetTXOP function is added to the abstract Dcf class as an abstract function. Since the Dcf class is the base class of both DcaTxop and EdcaTxopN, they both have SetTXOP function implementation. The SetTXOP function in the wifi-mac class calls the DcfState :: SetTXOP to set its value. The value of txop_limit is set to zero in case of DcaTxop class and to its default value in each of the EdcaTxopN classes.The attribute txop_limit stores the AC default TXOP duration time. Another local variable, m_txop_l, is used to keep track of the remaining time that an AC has in its TXOP limit to expire once it gained the medium. When the first packet in the TXOP duration is added to the queue using EdcaTxopN :: Queue function, the local TXOP value (m_txop_l) takes the value stored in the attribute txop_limit. This is done in the EdcaTxopN :: StartAccessIfNeeded function using DcfState :: StartTXOP function. For example, the TXOP limit in the IEEE 802.11g for video traffic is 3008 ls. In this case, the attribute txop_limit is set to the value 3008 and the variable m_txop_l starts with the

•

•

value 3008 and is decreased while sending packets during a TXOP duration. Contending for the medium When a packet arrives from the upper layers to EdcaTxop using the EdcaTxopN :: Queue function, a flag (m_accessRequested) is set to true. This happens in order to prevent other packets from trying to contend for the medium which may cause a collision. The DcfManager object is then notified to start contending for the medium. The m_accessRequested is set to false, when the current packet is sent, to let other packets start the contending process for the medium process. The same thing should be done when a node tries to send the first packet in the TXOP limit. The node should contend for the medium only with the first packet in each TXOP limit. It also should directly send the subsequent packets as long as the TXOP limit is not expired. This means that a flag should be added to prevent contending for the medium, while TXOP limit is not expired. The flag inTXOP is used for this purpose and DcfState :: IsInTXOP function is used to obtain the value of this flag. Sending of multiple packets Once the channel access is gained, the TXOP burst transmission procedure begins as shown in Fig. 4. Initially, the inTXOP flag is set to true and the start time of the current TXOP is stored. The attribute start_txop of type Time is used for this purpose. Next, after each packet in the current TXOP is sent and its acknowledgment is received, the EdcaTxopN :: GotAck function is called. Within this function, the function DcfState :: CheckTXOP is called to subtract the time needed to send the last packet and the receiving of its acknowledgment from the TXOP remaining time (tracked by m_txop_l) and check if the remaining time in the current TXOP is enough to send the next packet and receive its h changed to be public. If the current TXOP limit has enough time for the next packet, the sending of the next packet is scheduled after SIFS time period. If not, the current TXOP limit is considered expired and the medium is released.

123


•

Collision handling In case of a packet collision, all flags and local variables must be reset to their default values. For this purpose, the function DcfState :: ResetTXOP is used. This function is also called in the EdcaTxopN :: GotAck function, when the TXOP time is not expired, but the EDCA queue has no packets to send.

4 AVS framework simulation The limited channel resources in wireless surveillance communication systems have motivated many bandwidth management solutions that adjust different parameters of different layers in the network architecture. Such solutions include the adaptation of the parameters of the following. (a) error detection and correction and video coding in the application layer, (b) transmission reliability and congestion control in the transport layer, and (c) modulation and coding schemes in the physical layer [20]. To cooperatively perform the adaptation process to achieve the required bandwidth management, cross-layer control schemes have emerged [21]. With the recruitment of information from the channel state and different network layers, a cross-layer bandwidth manager is capable to assort decision making at multiple layers to maximize video quality in the surveillance system. The work in [12] provided a cross-layer solution that takes care of great system details. In this work, we choose to use the framework in [12] in our simulation platform. In order to be able to explain our simulation for the framework proposed in [12] and to keep

Fig. 5 A single-hop wireless video surveillance system

123

the paper self-contained, a detailed description of the framework is provided in the following subsection. 4.1 Distortion-based cross-layer solution The study in [12] introduced a cross-layer optimization framework that is called Enhanced Distortion Optimization (EDO). EDO manages multiple video sources that stream video to a central station in a single-hop network as shown in Fig. 5. EDO provides a dynamic cross-layer optimization solution that distributes and allocates 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 controlling the application rate and the link layer parameters (TXOP) in the streaming sources. In building EDO, the bandwidth distribution problem is formulated as a cross-layer optimization problem based the sum of all video streams distortion received by the proxy station. In this formulation, the bandwidth allocation determines the airtime fraction for each video source in the system. The mathematical formulation of the problem was proposed as follows: F ¼ arg min

S X

Distortionðrs Þ

ð3Þ

s¼1

such that: S X

fs ¼ Aeff

ð4Þ

s¼1

rs ¼ f s y s

ð5Þ


0 fs 1

ð6Þ

s ¼ 1; 2; 3; . . .; S

ð7Þ

where F is the total optimal fractions (fs ) of all video sources airtime and Aeff is the total effective airtime which is an estimation of the available shared bandwidth of the network, rs and ys 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 video distortion and video bit rate relationship and an estimation is needed for the effective airtime in the network. The work in [12] characterized the relationship between the distortion and the video bit rate as follows. Distortion (RMSE) ¼ a ðZÞb þ c

ð8Þ

where Z is the average video frame size and a, b, c are constants. Since the framework uses MJPEG video streams, Z is calculated as Z ¼ Rs , where R is the video playback rate and s is the video frame rate. The work in [12] also used an online estimation algorithm to estimate the network effective airtime as shown in Fig. 6. The algorithm is run on the proxy station and measures the sum of the ratios of the data dropping to the physical rate of each node. This value, Ad , gives an

indication on the performance of the network and the algorithm adapts the estimated effective airtime Aeff to get Ad very close to pre-specified threshold Athresh . The algorithm is stopped when the difference between Ad and Athresh becomes very small. Based on the work in [12], the algorithm parameter should be set to: Ithresh ¼ 0:0005, estimation period = 5 s, and Athresh ¼ 0:0075 The problem formulated in (3) was solved using the Lagrangian relaxation technique [22]. The Lagrangian-relaxed formulation for this problem was formulated as follows. ! S S X X LðF ; kÞ ¼ as ðfs ys =sÞbs þcs þ k fs Aeff s¼1

s¼1

ð9Þ Then the Lagrangian conditions were formulated and solved to obtain the equations for both k and fs as shown in Eqs. (10) and (11), respectively. 1ðbs 1Þ 0 B k¼@

PS

EA

ss s¼1 as bs ys ðys =ss Þðbs 1Þ

C ð1=ðbs 1ÞÞ A

ð10Þ

Fig. 6 Simplified dynamic effective airtime estimation algorithm

123


fs ¼

k ss

!ð1=ðbs 1ÞÞ

as bs ys ðys =ss Þð bs 1Þ

ð11Þ

Equation (5) is used at each source 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 are transmitted accordingly, once a channel access is gained. Thus, the TXOP is adapted dynamically in each source using the following equation. Fs Os Ns TXOPs ¼ ð12Þ þ þ ½ð2Ns 1ÞIs þ ½Ns Ia ys ys In this equation, Fyss is the time required to transmit a single video frame data, where Fs is the maximum video frame data size. Oys Ns s is the time required to transmit the MAC and physical layers overhead. Also, ð2Ns 1ÞIs is total SIFS durations required to transmit the whole packets where Is is the SIFS time and Ns Ia is the time required to receive all acknowledgment packets for all of the video frame packets, where Ia is the time required for an acknowledgment to be sent. This framework was tested using OPNET simulator by streaming real video frames over a simulated network with an error concealment algorithm that reduces the impact of packet loss. 4.2 Simulation implementation All devices that can be connected to a network are simulated using the node module (class) in NS-3. This module contains all the protocol stacks. Each object of the Node class can include multiple Applications and multiple NetDevices. In this representation, a NetDevice is attached to a specific communication channel over which all packet transmission occurs. The node architecture is demonstrated in Fig. 7.

Fig. 7 Node architecture in NS-3

123

Mainly, the simulation of EDO is constructed into two network layers in video sources: the application layer and the MAC layer. 4.2.1 Application layer Several application classes are already implemented in NS3 to simulate sending and receiving data packets of different types of traffic. Also, a custom application can be implemented if desired. For EDO, two types of applications are required to be built, one that resides on the video sources (Source Application) and another that resides on the server side (Sink Application). The source application represents a camera that continuously captures a live video stream. The captured video is processed (encoded, compressed, and packetized) in order to meet the transmission medium bandwidth. EDO assumes the use of Motion JPEG (MJPEG). MJPEG video stream is a set of individually compressed video frames. MJPEG has an advantage in surveillance applications because its video frames has no data dependencies on each other which means that if a frame is lost, it will not affect the rest of the video. The sink application (the server side application) groups the packets into video frames, tries to conceal incomplete video frames, and measures the studied video statistics. Figure 8 shows the UML diagram of the required applications to simulate EDO in NS-3. Each source application maintains a pointer to the associated socket (m_socket), and the address of the destination (tx_peer). The pksize variable is reserved to set the application layer packet size. Also, each source has a unique ID stored in the nodeid variable. start_time of type ns3 :: Time holds the start time of the application execution. The no_stations variable stores the total number of the streaming sources connected with AP. The source application gets a frame rate (FramRate), a bit rate (appRate), and an image set, and generates a MJPEG video stream, where each selected image data are stored in the object ids which is of type myImageStructure that is defined in a library that we implement to perform functions related to video compression and RTP paketization. Nodes start sending video data after some specific time form the beginning of the simulation. This time can be determined by the main simulation scenario code in NS-3. When this simulation time is reached, the function Source :: StatrApplication() is invoked. This function initializes the application state and assigns the node starting time to the start_time variable. This function also starts the first functional phases of the source node. The source node runs into two phases. The first phase starts at start_time until the simulation time reaches the value of EAestimationTime (EAestimationTime = 20 s). During this phase,

J Real-Time Image Proc Fig. 8 AVS source and sink applications UML diagram

appRate is set using Eq. (13) which saturates the network [23]. appRate ¼ PhyRate=no stations

ð13Þ

where PhyRate is the physical rate of the node. This phase is used to calculate the initial value of the effective airtime. During this phase only, a raw bit stream is sent. This is done because the only required output of this phase is the throughput and to speed up the simulation. In this phase, the function Source :: SendRawData() is scheduled each second to perform this work.

As soon as the first phase is completed, the function Source :: FlushQueues() is called to flush the MAC queues. This will initialize the simulator and makes it ready for statistics collection. After the queues are flushed, the second phase begins. This phase lasts for transitionTime time period . In this phase, the function Source :: SelectImg() is scheduled periodically to select an image to be send. The number of calls per second should be equal to the frame rate. In this function, the value of appRate is adapted by EDO (the calculation method is discussed later). After calculating the appRate, the frameSize is calculated as:

123


frameSize ¼ appRate=frameRate

ð14Þ

The calculated frameSize determines the size of the frame that is selected to be sent. The frame is selected randomly from the image database, and JPEG compression quality of the selected image is determined based on the needed size. The selected frame data are store in an ids object. The ids object packetizes the selected image into RTP packets of size pksize. The total number of RTP packets needed is stored it in the FrameInPackets variable. Also, the last packet size which is usually smaller than pksize is calculated for stored in lastPacketSize variable. At last, the function Source :: SelectImg() calls the Source :: SendImage() function to schedule the sending of the frame RTP packets to the lower layers. The Source :: SendImage() function is also responsible for updating the values of FrameCounter which is used as frame sequence number, and PacketCounter that is used to assign packets within a frame, sequence numbers. When phase two is done, this is when the system is fully active and the main statistics are collected to monitor its performance. The sink application simulates the application layer at the server side. Since the AP is connected to the server using a high-speed link, this application is treated as if it is running on the access point. The sink application starts at the beginning of the simulation. When the sink application starts execution, the Sink :: StatrApplication() function is called. This function is responsible for the initialization of the application attributes. A pointer to the associated socket (m_socket) is maintained in the sink application, and it is used to receive data from the lower layers. Most of the attributes of this class are defined as arrays of size n, where n is the total number of video sources associated with the AP. This is done to maintain information for each video source. The Sink :: HandleRead() function is called upon receiving packets from the m_socket. Most of the Sink class processing occurs in this function. It is responsible for updating the counters of the total received frames (totalFrames), missed frame (missedFrames), complete received frames (completeFrames), incomplete frame that was partially exposed to packet loss (incompleteFrames), and the frame that was concealed (concealedFrames) from the incomplete received frames. The lostPacketsCounter is used to keep track of the lost packet count in each incomplete frame. While the lostPackets is an array that stores the position of the lost packets in the frame. Both lostPackets and lostPacketsCounter are used for frame concealment purposes. The lastFrameN, lastPacketN, and lastFrameSizeInPackets variables store the frame count, packet count, and the original packet count of the previously received frame, respectively, to keep track of the lost packets and/or lost frames. The packetCounter maintains the current packet count for each video source. Both timers,

123

EAestimationTime and transitionTime (have the same values as in the source application), are used to determine when to start collecting statistics required from the application layer to monitor the framework performance. Finally, the Sink :: faceDetection() function, which is a computer vision algorithm (face detection algorithm), is applied to the concealed and successfully received frames. 4.2.2 MAC layer Two types of MAC high classes are available for infrastructure configuration in NS-3. Namely, AP class (ns3 :: ApWifiMac) and non-AP Station (STA) class (ns3 :: StaWifiMac). Figure 9 shows the main changes that we have done to those classes. It also shows the StateReport class which is developed to represent the required information that each video source sends to the AP periodically to perform the bandwidth optimization. Each state report contains the sender node ID (peer_id) and the distortion curve constants a, b, and c (peer_a, peer_b, and peer_c). It also contains the frame rate (peer_frameRate), the sender physical rate (peer_physicalRate), and the total dropping rate (peer_Dropping) measured by the sender. The peer_Dropping contains the total dropping rate that occurs because of both the MAC buffer and because of the retransmission dropping. The ns3 :: ApWifiMac class implements the MAC of the AP that is responsible for the beacon generation, and the acceptance of the association attempts. Since the effective airtime algorithm requires information from the MAC and the upper and lower layers, we find it convenient to implement the effective airtime estimation algorithm in the ns3 :: ApWifiMac class. The exchange of information between the different layers is accomplished using the NS3 Tracing System. The ns3 :: ApWifiMac class includes the following attributes: (1) no_stations variable which contains the number of the associated video sources with the AP, (2) peer_info_ptr object array, of type StateReport that holds the information received from each video source state report, (3) start_times which is an array that contains the start times of each video source, (4) totalPeerStreamData which is an array that stores the total data size received from each video source by the sever application layer, (5) EACalculationPeriod that contains the designated duration period for the effective airtime estimation, (6) EA which stores the calculated effective airtime of the network, (7) lastOperation variable is used as a flag to determine the last operation in the effective airtime algorithm (0 value to indicate a decrement operation and 1 to indicate an increment operation), (8) lastIncement and lastDecrement variables contain the last calculated value in the EACalculationPeriod whether it was an increment (lastIncement) or a decrement (lastDecrement),


Fig. 9 MAC high UML diagram

and (9) EAestimationTime and transitionTime have the same values as in the application layer classes. The effective airtime estimation algorithm begins execution after EAestimationTime. During this time, the video sources transmit data to the proxy station, the size of this data (as received in the application layer) is stored in the totalPeerStreamData. totalPeerStreamData is used to

calculate the initial effective airtime. The EAestimationFlag is initially set to true. This implies that the effective airtime calculation process is still in the first phase. The EAcalculatedFlag flag (initially set to false) indicates that the initial EA value is not calculated yet. After EAestimationTime, the EA calculation process starts to calculate the initial EA value. As soon as the initial EA

123


value is calculated, the EAcalculatedFlag flag is set to true to indicate that the initial EA value is calculated. Also, the EAestimationFlag is set to false to indicate the completion of the first phase in the effective airtime calculation. After that, the second phase begins and the estimation period of the EA algorithm shown in Fig. 6 starts. As the effective airtime algorithm iterations should be scheduled every EACalculationPeriod, the EAcalculationLastTime variable, which is of type ns3 :: time, stores the time of the last iteration calculation, and it is used to determine the next iteration time. The next iteration time is due when the value of Simulator :: NowðÞ EAcalculationLastTime is greater than or equal to EACalculationPeriod. In each EACalculationPeriod, the average dropping rate is calculated as: sumsumD/sumDCounter, where sumsumD is the sum of the total dropping rate received from each video source (s) divided by the physical rate of that video source. Each time sumsumD is calculated, the sumDCounter variable is incremented by one, to calculate the average dropping rate. Then, the effective airtime estimation algorithm runs as discussed earlier until the calculation process terminates. Upon the algorithm termination, the EAdone flag (initially set to false) is set to true to stop the algorithm execution. The second phase terminates after the transitionTime time period. The calculation algorithm is placed in the ApWifiMac :: SendOneBeacon() function to ensure the periodic check for the timers. Also, the ApWifiMac :: ReceiveðPtr\Packet [ packet, WifiMacHeader hdr) function is used to accept the state report received from each video source and populate its data to the peer_info_ptr object array. Whenever EA is calculated, it is used to calculate k value, which is sent in each beacon to the video sources associated with this AP. k value is calculated as described in Eq. (10). The ns3 :: StaWifiMac class represents the video source MAC layer. It implements the association state machine and medium active probing process. The ns3ZStaWifiMac class includes the attribute staterep that represents the data to be transmitted in a beacon to the proxy station. Also, the application rate, the physical rate, and the frame rate for each video source are stored in the attributes appRate, phyRate, and frameRate, respectively. The attributes EAestimationTime and transitionTime have the same values as in the application classes. The function StaWifiMac :: stateReport sendðÞ is used to schedule and send a periodic packet (beacon) loaded with the video source information to the AP. The last_sent_loadRate variable contains the last sent data load rate coming from the upper layers to the MAC in each video source. It is calculated as the total size of packets received in the MAC (from the upper layer) divided by the time duration in which the size of the packets is collected. The last_sent_sentRate is calculated the same as last_sent_loadRate, except that the size of

123

packets contains the physical layer overhead. The last_sent_droppedBRate and last_sent_droppedRRate store the buffer dropping rate (data packet dropping rate due to buffer overflow in the MAC) and the retransmission dropping rate (data packet dropping rate due to exceeding retransmission tries), respectively. The last_sent_droppedBRate and last_sent_droppedRRate are calculated by dividing the data size of the dropped packets (buffer or retransmission dropping) by the time duration in which the sizes are collected. The peer_Dropping variable in the staterep object is calculated as the sum of last_sent_droppedBRate and last_sent_droppedRRate. The function StaWifiMac :: Receive(Ptr; Packet [ packet, WifiMacHeader hdr) is called upon receiving a packet from the lower layers. It obtains the k value from the packet if it is a beacon. k value is used in each video source s to calculate its fs (its fee value) from the total calculated effective airtime. fs value is calculated as described in Eq. (11). After that, the application layer sending rate is calculated as described in Eq. (5). The rest of the attributes in the class is used to calculate the TXOP time limit. Each video source calculates its own TXOP limit such that it will be enough to transmit all packets of a single video frame with all of its overhead. The TXOP time limit for a specific video source s is calculated as described in Eq. (12). The maxLoad variable is used to store the maximum value of last_sent_loadRate. Ls variable stores the average data load in each MAC data frame. Os variable stores the average overhead of the MAC and physical layers. The variable txop_limit stores the calculated TXOP limit value. Since this framework uses a cross-layer approach, all information required to do this is available. Fs is calculated as maxLoad/frameRate. Ns is calculated as Fs =Ls .

5 Evaluation methodology 5.1 The evaluation methodology of the TXOP implementation Various experiments are conducted to test the correctness of our TXOP implementation in NS-3 simulator version 3.22. The same experiments are also conducted using OPNET simulators for verification purposes. In all experiments, Wi-Fi networks in infrastructure mode are used. In these networks, several stations are sending data packets to a central Access Point (AP). The network traffic is generated as voice traffic with IEEE 802.11b and IEEE 802.11g standards. In all experiments, stations always have packets to send (saturated traffic). To create saturated traffic, the application rate (R) is calculated as in [12]:


R¼

P S

where P is the physical rate of the selected NetDevice for each station and S is the total number of stations participating in the experiment. Moreover, since NS-3 and OPNET simulators implement their own propagation delay and path loss models, we try to eliminate their impact by placing the sources and the AP in the same location in the network. The only delay that we could not eliminate is the queuing delay in the simulators. Table 2 summarizes the main simulation parameters. 5.2 The evaluation methodology of the AVS framework Several experiments are conducted using NS-3 simulator version 3.22. A Motion JPEG (MJPEG) library (developed in [12]) is used to create real MJPEG video streams. This Table 2 Main simulation parameters Parameter

Model/value(s)

Number of sources

2, 4, 6, 8, 10, 12

Source start time

Random (1–5) s

Simulation time

4 min

Application packet size

1024 Bytes

Application rate

Physical rate / S

Physical characteristics

IEEE 802.11 (b & g)

Physical data rate

(11 & 54) Mbps

Buffer size

256 packets

Traffic type

Voice

Beacon interval

0.02 s

TXOP limit CWmin , CWmax , and AIFS

0 & As described in Table 1 Default as described in the standard

Table 3 Main simulation parameters used in the AVS simulation framework

library is used to stream MJPEG videos as Real-time Transport Protocol (RTP) Packets. The CMU/MIT [24] and Georgia Tech [25] image databases are used to produce gray-scale video streams. The frames in each video stream are randomly selected from those image databases. The MJPEG library provides the required RTP Packets for the streaming source application. At the application layer of the server, upon receiving the RTP packets of a video frame, the RTP packets are reassembled to form the original frame. Furthermore, an error concealment algorithm [26] is used to reduce the packet loss impact on the quality of the frames. Table 3 summarizes the main simulation parameters.

6 Result discussion 6.1 NS-3 TXOP implementation verification results The results for both simulators NS-3 and OPNET are compared using the performance metrics described in Sect. 2: The average throughput and the Average Delay. Figures 10 and 11 show the average delay and the average throughput for voice traffic over IEEE 802.11b and IEEE 802.11g standards, respectively. These experiments are performed when TXOP = 0 (i.e., sending one packet at each TXOP duration) in both NS-3 and OPNET simulators. Note that these figures compare the OPNET performance with the unmodified version of the NS-3. These figures show that there are not many differences in the results between OPENT and NS-3 in both 802.11b and 802.11g standards. We can see that with OPNET, there is slightly more packet delay because OPNET keeps the packets in its queues more than that in the case of NS-3. However, as we can see, the difference is very acceptable.

Parameter

Model/value(s)

Number of streaming sources

5, 10, 15, 20, 25, 30

Source start time

Random (1–5) s

Simulation time

10 min

Application packet size

1024 bytes

Application rate

Optimized, default = network physical rate/S

Physical characteristics

IEEE 802.11g

Physical data rate

54 Mbps

Buffer size Beacon interval

256 packets 0.02 s

State report interval

2s

Long retry limit

4

Short retry limit

7

CWmin , CWmax , AIFS

Default, described in the standard

Video TXOP limit

Optimized, default = 3008 ls

123


(a)

8

(b)

6

10

x 10

Average Throughput (bps)

Average Delay (sec)

7 6 5 4 3 2 1

OPNET NS−3

0

2

4

6 8 Network Size

10

8

4 2 0

12

OPNET NS−3

6

2

4

6 8 Network Size

10

12

Fig. 10 Performance metrics when sending one packet at each TXOP limit using 802.11b standard. a Average delay. b Average throughput

(b)

2.5


Average Delay (sec)

(a)

2 1.5 1 0.5 0

OPNET NS−3

2

4

6 8 Network Size

10

7

5

x 10

4.5 4 3.5 OPNET NS−3

3 2.5 2 1.5 1 0.5

12

2

4

6 8 Network Size

10

12

Fig. 11 Performance metrics when sending one packet during each TXOP limit using 802.11g standard. a Average delay. b Average throughput

Figures 12 and 13 show the average delay and the average throughput for voice traffic over the IEEE 802.11b and IEEE 802.11g standards, respectively. These experiments are performed with the default TXOP values in both NS-3 (the modified version) and OPNET. Results show the impact of having the complete EDCA implementation. With the TXOP implementation, due to the sending of more data packets with each medium access, the average throughput is increased, and the packet delay is decreased. Furthermore, both simulators have almost the same curves for both average delay and average throughput with almost the same slight difference in the case of the average delay before the modification. These results indicate the correctness of the NS-3 TXOP implementation.

123

6.2 AVS framework results discussion In this section, we compare the results of simulating EDO in NS-3 with the OPNET simulation results presented in [12]. The results of both simulators have been compared using the performance metrics described in Sect. 2. The used metrics are perceptual video quality, the overall received data rate at the proxy application layer from the associated 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.


(a)

(b)

8


Average Delay (sec)

7 6 5 4 3 2 1

OPNET NS−3

0

2

4

6 8 Network Size

10

6

10

x 10

9 8 7 OPNET NS−3

6 5 4 3 2 1

12

2

4

6 8 Network Size

10

12

Fig. 12 Performance metrics with defult TXOP value using 802.11b standard. a Average delay. b Average throughput

(b)

2.5


Average Delay (sec)

(a)

2 OPNET NS−3

1.5 1 0.5 0

7

5

x 10

4.5 4 3.5 OPNET NS−3

3 2.5 2 1.5 1 0.5

2

4

6

8

10

12

2

Network Size

4

6

8

10

12

Network Size

Fig. 13 Performance metrics with defult TXOP value using 802.11g standard. a Average delay. b Average throughput

Figure 14 shows the results obtained by running the simulation with streaming videos that are constructed using the CMU/MIT [24] gray-scale image database. Those results show that the NS-3 and the OPNET EDO simulations are very close. There is an acceptable deference in the results. This difference is due to how the different simulators deal with the physical layer rate in the video sources. In OPNET, the physical layer rate was set randomly between 18 and 54 Mbps, while in NS-3, the physical layer rate is set to 54 Mbps in the AP and in all of the streaming sources because there is no direct way to set the physical rate in NS-3 as it is the case in OPNET. Those results show that the NS-3 EDO implementation is accurate.

7 Conclusion The main contributions of this work can be summarized as follows. (1) Complete the EDCA implementation in the NS-3 simulator by incorporating the TXOP component implementation. (2) Create a realistic MJPEG application layer that streams real video data in a simulated network. (3) Model and simulate a wireless AVS framework accurately to the NS-3 simulator. The completion of the IEEE 802.11e implementation in NS-3 provides a testbed environment, to study and analyze the complete IEEE 802.11e EDCA implementation. A realistic video streaming application can be used over a simulated NS-3 framework. The experimental AVS system framework also provides a

123


(b)

40 30 20 10 0

5

10

15 20 Network Size

25

3

90% 80% 70% 60% 50% 40%

NS3−EDO OPNET−EDO

30% 20% 10% 0%

5

10

15 20 Network Size

25

2 1.5 1

5

10

15 20 Network Size

25


80% 70% 60% 50% 40% 30% 20% 10% 5

10

15 20 Network Size

25

Overall Buffer Dropping Rate (bps)

4 3 2 1 5

10

15 20 Network Size

25

30

10

90%

15 20 Network Size

25

30

25

30


80% 70% 60% 50% 40% 30% 20% 10% 0%

30

5

10

15 20 Network Size

(i) 7


5

100%

90%

(h)

5

0

30

(f)

0%

x 10

1 0.5

100%

7

6

1.5

0.5

30

(g)


2

2.5

0

Percentage of Incomplete Frames

Percentage of Complete Frames


(e)

100%

Overall Network Load Rate (bps)

2.5

3.5

30

(d)

x 10

Percentage of Missed Frames

PSNR (dB)

Overall Received Data Rate (bps)


(c)

7

4

Packet Delay (sec)

50

3

x 10


2.5 2 1.5 1 0.5 0

5

10

15 20 Network Size

25

30

Overall Retransmission Dropping Rate(bps)

(a)

6

5

x 10


4 3 2 1 0

5

10

15 20 Network Size

25

30

Fig. 14 Bandwidth Allocation Solutions Comparison for CMU/MIT Database. a Perceptual Video Quality. b Overall Received Data Rate. c Packet Delay. d Complete Video Frames. e Incomplete Video

Frames. f Missed Video Frames. g Overall Network Load. h Overall Buffer Dropping Rate. i Overall Retransmission Dropping Rate

testbed environment, to validate a specific cross-layer AVS framework. Furthermore, with some amendments, the AVS framework can be tested and validated under different wireless environments such as IEEE 802.16 (WiMAX).

Department C Citizens’ Rights and Constitutional Affairs, PE 419, (2009) Fleck, S., Strasser, W.: Smart camera based monitoring system and its application to assisted living. Proc. IEEE 96(10), 1698–1714 (2008). doi:10.1109/JPROC.2008.928765 Ben Hamida, A., Koubaa, M., Nicolas, H., Amar, C.B.: Video surveillance system based on a scalable application-oriented architecture. Multimed. Tools Appl. pp. 1–27 (2015). doi:10. 1007/s11042-015-2987-5 Xu, Z., Hu, C., Mei, L.: Video structured description technology based intelligence analysis of surveillance videos for public security applications. Multimed. Tools Appl. (2015). doi:10. 1007/s11042-015-3112-5 Zhizhuo, S., Yu-An, T., Yuanzhang, L.: An energy-efficient storage for video surveillance. Multimed. Tools Appl. 73(1), 151–167 (2014). doi:10.1007/s11042-012-1262-2

2.

3. Acknowledgments This work is funded in part by the Jordan University of Science and Technology Deanship of Research Grant Number 20140245. 4.

References 5. 1. Norris, C.: A review of the increased use of cctv and videosurveillance for crime prevention purposes in europe. EU Policy

123

J Real-Time Image Proc 6. Kim, D., Hwang, E., Rho, S.: Multi-camera-based security log management scheme for smart surveillance. Secur. Commun. Netw. 7(10), 1517–1527 (2014) 7. Mehmood, I., Sajjad, M., Rho, S., Baik, S.W.: Divide-and-conquer based summarization framework for extracting affective video content. Neurocomputing 174(Part A), 393– 403 (2016). doi:10.1016/j.neucom.2015.05.126. http://www.sciencedirect. com/science/article/pii/S0925231215012527 8. Park, Jh, Rho, S., Jeong, Cs: Real-time robust 3d object tracking and estimation for surveillance system. Secur. Commun. Netw. 7(10), 1599–1611 (2014) 9. Subudhi, B.N., Ghosh, S., Nanda, P.K., Ghosh, A.: Moving object detection using spatio-temporal multilayer compound markov random field and histogram thresholding based change detection. Multimed. Tools Appl. (2016). doi:10.1007/s11042-016-3698-2 10. Xu, X., Mu, N., Chen, L., Zhang, X.: Hierarchical salient object detection model using contrast-based saliency and color spatial distribution. Multimed. Tools Appl. 75(5), 2667–2679 (2016). doi:10.1007/s11042-015-2570-0 11. Zhang, Y., Jiang, F., Rho, S., Liu, S., Zhao, D., Ji, R.: 3d object retrieval with multi-feature collaboration and bipartite graph matching. Neurocomputing 195, 40–49 (2016). doi:10.1016/j. neucom.2015.09.118, http://www.sciencedirect.com/science/arti cle/pii/S0925231216000990. (Learning for Medical Imaging) 12. Alsmirat, M., Sarhan, N.: Cross-layer optimization and effective airtime estimation for wireless video streaming. In: 2012 21st International Conference on Computer Communications and Networks (ICCCN), pp. 1–7 (2012). doi:10.1109/ICCCN.2012. 6289275 13. Opnet modeler web page. http://www.opnet.com/solutions/net workrd/modeler.html 14. The network simulator ns-3. http://www.nsnam.org/ 15. IEEE standard for information technology—telecommunications and information exchange between systems—local and metropolitan area networks—specific requirements—part 11: wireless lan medium access control (mac) and physical layer (phy) specifications. ANSI/IEEE Std 802.11, 1999 Edition (R2003) pp. i–513 (2003). doi:10.1109/IEEESTD.2003.95617 16. Ieee 802.11 amendment to support quality of service. IEEE 802.11e-2005 (2005) 17. The network simulator ns-2. http://www.isi.edu/nsnam/ns/ 18. Recommendation 500-10: Methodology for the subjective assessment of the quality of television pictures. ITU-R Recommendation BT.500-10 (2000) 19. Ke, C.H., Shieh, C.K., Hwang, W.S., Ziviani, A., et al.: An evaluation framework for more realistic simulations of mpeg video transmission. J. Inf. Sci. Eng. 24(2), 425–440 (2008) 20. Misra, S., Reisslein, M., Xue, G.: A survey of multimedia streaming in wireless sensor networks. IEEE Commun. Surv. Tutor. 10(4), 18–39 (2008) 21. van Der Schaar, M., Sai, S.N.: Cross-layer wireless multimedia transmission: challenges, principles, and new paradigms. IEEE Wirel. Commun. 12(4), 50–58 (2005) 22. Ortega, A., Ramchandran, K.: Rate-distortion methods for image and video compression. IEEE Signal Process. Mag. 15(6), 23–50 (1998) 23. Symington, A., Kritzinger, P.: A hardware test bed for measuring ieee 802.11 g distribution coordination function performance. In: IEEE International Symposium on Modeling, Analysis and Simulation of Computer and Telecommunication Systems, 2009. MASCOTS’09., pp. 1–7. IEEE (2009) 24. Cmu/mit image set. http://vasc.ri.cmu.edu/idb/html/face/frontal_ images/. Accessed Nov 2015 25. Georgia tech face database. http://www.anefian.com/research/ face_reco.htm. Accessed Nov 2015

26. Shirani, S., Kossentini, F., Ward, R.: Reconstruction of baseline jpeg coded images in error prone environments. IEEE Trans. Image Process. 9(7), 1292–1299 (2000). doi:10.1109/83.847842

Mohammad Alsmirat received his Ph.D. Degree in computer engineering from Wayne State University in 2013, his Master Degree in Computer Science from New York Institute of Technology in 2003, and his Bachelor Degree in Computer Science from Jordan University of Science and Technology in 2002. He was a full-time lecturer in the Department of Computer Science at Jordan University of Science and Technology from October, 2003 until December, 2006. He then joined the Department of Electrical and Computer Engineering (ECE) at Wayne State University as a Graduate Research Assistant in January, 2007 to pursue his Ph.D. degree in Computer Engineering. He served as a Graduate Teaching Assistant in the ECE Department between August, 2007 and December, 2012. After that, Dr. Alsmirat worked as a Research and Development Engineer for General Motors for 9 months until he moved to Jordan to join the department of computer science in Jordan University of Science and Technology as an assistant professor and he is presently working there. Yaser Jararweh received his Ph.D. in Computer Engineering from University of Arizona in 2010. He is currently an associate professor of computer sciences at Jordan University of Science and Technology, Jordan. He has co-authored about hundred technical papers in established journals and conferences in fields related to cloud computing, HPC, SDN and Big Data. He was one of the General chair and the TPC Co-Chair, IEEE Globecom 2015, 2014 and 2013 International Workshop on Cloud Computing Systems, and Networks, and Applications (CCSNA). He is a steering committee member for CCSNA 2014 and CCSNA 2015 with ICC. He is the General Co-Chair in IEEE International Workshop on Software Defined Systems SDS-2014 and SDS 2015. He is also chairing many IEEE events such as ICICS, SNAMS, BDSN, IoTSMS, and many others. Dr. Jararweh served as a guest editor for many special issues in different established journals. Also, he is the steering committee chair of the IBM Cloud Academy Conference. He is associate editor in the Cluster Computing Journal (Springer), Information Processing and Management (Elsevier) and others.

123

J Real-Time Image Proc Islam Obaidat Received his M.Sc. of Computer Science from Jordan University of Science and Technology (JUST) in 2016. Thesis title is ‘‘A Realistic NS3-Based Automated Wireless Video Surveillance Simulation Framework’’. He also received his B.Sc. in computer science from Al-Balqa’ Applied University (BAU) in 2013.

Brij B. Gupta received Ph.D. degree from Indian Institute of Technology Roorkee, India, in the area of Information and Cyber Security. In 2009, he was selected for Canadian Commonwealth Scholarship and awarded by Government of Canada Award ($10,000). He spent more than six months in University of Saskatchewan (UofS), Canada to complete a portion of his research work. Dr. Gupta has excellent academic record throughout his carrier, was among the college toppers, during Bachelor’s degree and

123

awarded merit scholarship for his excellent performance. In addition, he was also awarded Fellowship from Ministry of Human Resource Development (MHRD), Government of India to carry his Doctoral research work. He has published more than 70 research papers (including 01 book and 08 chapters) in International Journals and Conferences of high repute including IEEE, Elsevier, ACM, Springer, Wiley Inderscience, etc. He has visited several countries, i.e., Canada, Japan, Malaysia, and Hong-Kong to present his research work. His biography was selected and publishes in the 30th Edition of Marquis Who’s Who in the World, 2012. He is also working principal investigator of various R&D projects. He is also serving as reviewer for Journals of IEEE, Springer, Wiley, Taylor & Francis, etc. Currently, he is guiding eight students for their Master’s and Doctoral research work in the area of Information and Cyber Security. He also served as Organizing Chair of Special Session on Recent Advancements in Cyber Security (SS-CBS) in IEEE Global Conference on Consumer Electronics (GCCE), Japan in 2014 and 2015. Earlier, he served as co-convener of National Conference on Emerging Trends in Engineering, Science Technology and Management (ETESTM-12), India, April, 2012. In addition, Dr Gupta received Best Poster presentation award and People choice award for Poster presentation in CSPC-2014, Aug, 2014, Malaysia. He served as Jury in All IEEE-R10 Young Engineers’ Humanitarian Challenge (AIYEHUM-2014), 2014. He has also served as founder and organizing chair of International Workshop on Future Information Security, Privacy and Forensics for Complex Systems (FISP-2015) in conjunction with ACM International Conference on Computing Frontiers (CF-2015), Ischia, Italy in May 2015. He is also serving as guest editor of various Journals.