MSA-SDMN: multicast source authentication scheme for multi-domain software defined mobile networks

ABSTRACT

Multicast services provide an efficient way of conserving resources and reducing network traffic for multicast senders. However, ensuring security, particularly source authentication, is crucial for applications such as online news, IPTV, video streaming, and stock quote distribution. Previous research efforts have attempted to provide source authentication for multicast applications, but they often struggle to handle the dynamic nature of multicast mobile receivers and multi-domain networks. This paper provides an analysis of research conducted over 22 years on source authentication mechanisms with non-repudiation. Most of these mechanisms fail to address the dynamic nature of mobile users and multi-domain networks. To address this issue, a new multicast source authentication scheme for multi-domain Software Defined Mobile Networks (SDMN) is proposed. This approach uses the global view of the controller in SDMN to operate in dynamic environments, provide non-repudiation, and tolerate packet loss. Simulation results indicate that the proposed mechanism uses resources efficiently, reduces communication and delay overhead, and performs well in multi-domain and dynamic networks.

KEYWORDS:

• Group communication
• source authentication
• software defined mobile network
• multi-domain network

1. Introduction

Group communication is an essential component of modern communication networks like 4G and 5G. It facilitates the distribution of data such as online news, IPTV, video streaming, stock quote distribution, and video-on-demand. These applications usually implicate a large number of Mobile users that require low latency and increased bandwidth (Araniti et al., 2017; Islam et al., 2018). So, using Multicast for group communication improves throughput and reduces network traffic (Rose & Holland, 2022; Thakur & Khatua, 2020). Moreover, such applications typically implicate multiple devices sharing the same content. However, users may frequently join sessions, leave sessions or move to a new position due to the dynamic nature of both mobile users and networks. In group communication, malicious users can participate by dropping, delaying, or modifying intercepted packets, or injecting new packets into the transmitted stream. So, to mitigate such risks, security measures such as authentication, confidentiality, integrity, and non-repudiation are employed. Therefore, authentication is a crucial requirement for many multicast applications (Hardjono & Tsudik, 2000; Shirey, 2007). There are two categories of authentication in multicast: Group authentication, which verifies that multicast messages received by group members originate from a valid group member. the second is source authentication, which ensures that the messages originate from a specific source. Group authentication is generally addressed by group key management techniques (Han et al., 2021; Hendaoui et al., 2018; Judge & Ammar, 2003; Kandi & Challal, 2020). However, source authentication is more difficult because the group key can't be used to verify a specific multicast source, as the group members know it. data origin authentication approaches for multicast communication employ MACs (Adrian et al., 2005; Kang, 2021) and hash/digital signatures. the first methods are used for source authentication without ensuring non-repudiation, while hash/digital signature-based methods are used when ensuring non-repudiation is necessary. To verify the source authentication of a multicast stream with non-repudiation, two categories have been presented: performed signature schemes (Annessi et al., 2018; Jung et al., 2002; Namhi, 1997; Perrig et al., 2000; Wong & Lam, 1999) and signature amortization cost over multiple packets (Challal & Bouabdallah, 2005; Eltaief, 2022; Eltaief & Youssef, 2009, 2018; Jeong et al., 2013; Jian-Bing & Qing, 2015; Liu et al., 2012; Seo & Youn, 2018; Vikrant & Tyagi, 2019). The former uses the sender's private key to sign each hash code of transferred messages but suffers from high communication and computation overheads. The latter relies on signature amortization approaches, which use hash-based schemes. As hash operations are relatively inexpensive in terms of computation, this approach significantly reduces the overheads associated with the computation and communication of digital signatures. Software-Defined Mobile Networking (SDMN) technology was introduced to address the challenges of network control and management by separating the control plane from the forwarding plane (Kyung & Kim, 2020; ONF, 2015; Prados-Garzon et al., 2016; Xia & Xie, 2015). The centralized controller manages the network, and communication between the controller and switches is enabled by protocols such as OpenFlow (ONF, 2015). SDN's global view of the network state can be advantageous in group communication applications by providing better routing decisions and helping to avoid congestion. In addition, SDN makes IP multicast more flexible to deploy (Blair et al., 2019; Li-Hsing et al., 2018). Based on these advantages, we propose using the global view of SDMN to develop a multicast source authentication scheme for multi-domain SDMN that can deal with multi-domain SDMN in dynamic environments. The estimation of network packet loss probability can be computed by using the global view of the control plane (SDN-C controller), which can be used to develop control algorithms and make multicast source decisions accordingly for constructing the hash-chain mechanism. The most existing signature amortization solutions for multicast source authentication are designed to work in traditional networks, which may not be suitable for modern networks that use SDMN technology. We classify these solutions into two categories. Solutions that take into account the fact that users and networks are dynamic (Challal & Bouabdallah, 2005; Eltaief, 2022) and solutions that do not consider the dynamism of the users and networks (Eltaief & Youssef, 2009, 2018; Jeong et al., 2013; Jian-Bing & Qing, 2015; Perrig et al., 2000; Seo & Youn, 2018; Vikrant & Tyagi, 2019).

This paper presents the Selective Hash-Based scheme, named Select_hash_chain, as an innovative approach for multicast source authentication. This scheme is tailored to ensure non-repudiation and resilience against packet loss within multi-domain Software Defined Mobile Networks (SDMN) and dynamic settings. Specifically designed for SDMN, Select_hash_chain employs a dynamic hash-chain structure, adjusting redundancy based on the estimated network packet loss probability from the SDN controller (SDN-C). By leveraging SDN's comprehensive network perspective, the multicast source constructs a hash-chain structure that serves all recipients, minimizing authentication information overhead. The proposed scheme effectively addresses challenges posed by multi-domain SDMN and dynamic environments, characterized by fluctuating network conditions, changing multicast group memberships, and mobile receiver positions.

Our work makes several significant contributions to the solutions of multicast source authentication in multi-domain SDMN and dynamic environments:

• We propose a new multicast source authentication mechanism, called the Selective Hash-Based scheme, that addresses the challenges (not yet considered in the literature review) of multi-domain SDMN and dynamic environments.

• We present a controller network management algorithm that is used by the controller. The SDN-c computes the estimated probability of packet loss in the network. The multicast source uses this estimation to choose the adequate redundancy degree to satisfy all multicast receiver SmartPhones.

• We propose hash-based structures robust against packet loss. The selective hash-based scheme uses one of them according to the efficiency (overhead and delay) and the estimated packet loss probability in the network (received from the controller).

• We develop algorithms for the source and receivers multicast that select the used structure based on the estimated packet loss probability as determined by the controller.

• We conduct a simulation analysis comparing the Selective hash-based scheme to well-known and recently reported mechanisms and demonstrate that the Selective hash-based approach performs efficiently with reduced communication and delay overhead in multi-domain SDMN and dynamic scenarios. The results also show that the proposed approach uses more buffer size at the multicast receiver SmartPhones.

The paper is structured as follows. Section 2 provides a review of previous works ensuring source authentication and using hash-chaining techniques for signature amortization. Section 3 presents the selective hash-based approach. Simulations and experimental results are presented in Section 4, where we compare and evaluate the performance of the Selective hahs-based approach with existing schemes. Finally, we conclude the paper in Section 5.

2. Related work

Amortization of the signature over several packets is the main type of hash-based approach for multicast source authentication that ensures data origin authentication with non-repudiation.

Authors of this study (Challal & Bouabdallah, 2005; Eltaief, 2022; Eltaief & Youssef, 2009, 2018; Jeong et al., 2013; Jian-Bing & Qing, 2015; Mohan et al., 2018; Perrig et al., 2000; Seo & Youn, 2018; Vikrant & Tyagi, 2019) offer an alternative to the practice of signing each packet individually, as suggested in the literature, one packet can be designated as the signature packet. To amortize the signature through all packets while minimizing computational costs, hashes of non-signature packets are embedded in others. So, a hash chain is generated in which each packet contains the hash of other packets. As a result of the hash code's low computational cost, the calculation cost of signature creation is amortized. We classify these articles into two categories. The first one is the mechanisms that support that users and networks are dynamic (Challal & Bouabdallah, 2005; Eltaief, 2022). The second categories the mechanisms that do not consider the dynamism of the users and networks (Eltaief & Youssef, 2009, 2018; Jeong et al., 2013; Jian-Bing & Qing, 2015; Perrig et al., 2000; Seo & Youn, 2018).

2.1. Schemes that support users and networks dynamism

Challal et al. proposed a signature amortization approach RLH (Challal & Bouabdallah, 2005), to minimize the computation cost. This approach is based in creating a chain of packets with each packet carrying the hash of the other packets so that the signature propagates along all packets. The RLH mechanism involves constructing different authentication layer, which are sent to the multicast group by the source multicast and utilizing the timeouts of received packets, the multicast receivers report missed packets. In the RLH mechanism, each receiver periodically decides to join another layer based on the packet loss ratio calculated during the last period of time, which helps improve the verification probability. The high bandwidth usage and additional overhead calculation at the multicast source are two disadvantages of this approach.

The Flex_hash_chain approach, proposed by Eltaief (2022) utilizes a hash-chain approach, which uses redundancy degrees during data transmission. This approach aims to exploit the feedback from the controller according to the packet loss in the network. This approach allows for the use of only the needed authentication information to achieve the needed verification probability for all receivers multicast. For each block, the multicast source uses SDN controller feedback to determine the optimal redundancy degree to tolerate the packet loss rate in the network. However, this approach does not support the multi-domain SDMN.

2.2. Schemes that do not support users and networks dynamism

A Trapdoor Hash Function-based Authentication Mechanism for Streaming Applications (TIM) was presented by Seo and Youn (2018) to decrease verification costs at the receiver and reduce signature costs at the sender. Calculating trapdoor hash collisions in this approach employs the Merkle Hash-based Tree's root hash. But in order to do so, the sender must first buffer k data messages before signing them, which causes a k data message delay at the multicast source.

Jian-Bing and Qing (2015) propose a threshold-based chain multicast source authentication technique to address authentication issues for multicast sources. The security assumptions and model for this method are established based on the security requirements for multicast source authentication. The proposed technique employs threshold secret sharing to design a multicast source authentication approach. the obtained results indicate that it has good packet loss resilience while ensuring optimal communication performance. However, the multicast source necessitates that data packets be buffered before being signed. So, this method causes a delay in data blocks at the multicast source.

Perrig et al. proposed EMSS (Perrig et al., 2000), which employs redundant hash-chaining to ensure packet stream authenticity. In this approach, even if some packets are lost we can verify the authenticity of the received packets by using a hash-link path. To maintain stream authenticity, the sender periodically send signature packets containing hashes that enable the verification of several packets. So, Verified packets carry hashes that are used to verify other packets. A drawback of this approach is that receivers may experience delays waiting for the corresponding signature packet to verify the authenticity of received packets.

Eltaief and Youssef (2018) proposed the Multi-Layer Connected Chains (MLCC) approach to reduce the cost of computational signatures, while also minimizing communication overhead and providing strong resistance against packet loss. The packet stream is split into multi-layer blocks using this method, with each layer being a two-dimensional vector. To resist packet loss, the hash of a packet is embedded in both a forward chain of packets within the same layer and a downward chain of packets across multiple layers. At the end of each block, the sender sends the signature packet. However, a significant drawback of this approach is that it requires buffering a large number of packets on both the sender and receiver sides.

Jeong Yoon-su et al. have introduced a novel data origin authentication method (Jeong et al., 2013). This method utilizes Merkle chains and hash functions to create hash chains carrying authentication information. This process ensures the authenticity of the multicast source of data. This method is able to minimize overhead by sending signatures in the first and last packets of a block to the multicast receivers. However, this approach still suffers from a high computation overhead at both the source and receiver multicast sides. To address this issue, V. Vikrant et al. proposed an improved approach using Hash Tree (Vikrant & Tyagi, 2019).

3. The selective hash-based approach

This paper uses the notation presented in Table 1.

Table 1. Notation.

Variables	Designation
Tmes	nb streamed messages.
nline*ncol	nb of messages in a block.
nhb	nb of Messages $M(i^{\prime },j^{\prime })$ that contain
	$H(M(i,j))$.
Tnh	Tnh = nhb+1.
BLS	Burst Loss Size.
$\mathrm{RV}(i,j)$	recovery mechanism
tr	time for sending the message (MSDN-C)
	to the multicast source.
SDN-InSW	Ingswitch attached to the source S).
SDN-EgSW [k]	Egswitch k attached to Receiver MR[k]).
InPacket_Count($t_i$)	packet counter value at time $t_i$ ($i\in$ N)
	at SDN-InSW switch.
EgPacket_Count( $t_i$)	packet counter value at time $t_i$ ($i\in$ N)
	at SDN-EgSW switches.
SDN-C_EPL	packet loss estimated by controller
H ()	Hash Function
Select_Parm	Select_parm = Structure ∥ nhb ∥ r
IDMR	the id of the mobile receivers
MJL	MJL = ProHandOver or MJL = Join or MJL = Leave

3.1. The proposed controller network management algorithm

The Algorithm 1 introduces how the controller proceeds to compute the packet Loss in the subnetwork (SDN-C_EPL) (used for the selection of the efficient hash chain structure according to redundancy degree and the authentication delay) and how it can manage the mobility and the dynamism of Multicast Receivers SmartPhone. Statistics maintained by Packet switches are typically collected by counters that count specific packet-type arrival or record specific events, such as packet drops. In software-defined mobile networking (SDMN), the counters in SDN-SWs must be communicated to the SDN-C controller. At each interval [$t_{i-1}$, $t_i$], the switch k sends a message (MesSDN-egSW-EPL[k]) to the controller SDN-C, containing the number of packets (EgPacket_Count). In their study, Hark et al. (2017) investigated techniques for measuring packet loss. Based on the properties of traffic, they proposed using the Legacy packet Counters technique, which demonstrated reasonable performance. In this work, the authors focused on bursty traffic profiles with transient duration, where the system experiences dynamics for a short period, followed by a long static period. The links that connect two switches (SDN-SW) is referred to as used link. These links are essential in establishing communication between the source multicast and the receiver multicast. An example of such a link is depicted in red in Figure 1, which connects the border SDN-SW of the source multicast to the receiver multicast.

Figure 1. Software defined mobile network scheme.

Equation (1(1) $\begin{array}{rll}\mathrm{NbLP}(t_i)& =(\mathrm{InPacket}\mathrm{\_}\mathrm{Counter}(t_i)-\mathrm{InPacket}\mathrm{\_}\mathrm{Counter}(t_{i-1}))& \\ & -(\mathrm{EgPacket}\mathrm{\_}\mathrm{Counter}(t_i)-\mathrm{EgPacket}\mathrm{\_}\mathrm{Counter}(t_{i-1}))\end{array}$(1) ) present how to calculate the number of lost packets NLP($t_i$) in the time interval [$t_{i-1}$, $t_i$]. (1) $\begin{array}{rll}\mathrm{NbLP}(t_i)& =(\mathrm{InPacket}\mathrm{\_}\mathrm{Counter}(t_i)-\mathrm{InPacket}\mathrm{\_}\mathrm{Counter}(t_{i-1}))& \\ & -(\mathrm{EgPacket}\mathrm{\_}\mathrm{Counter}(t_i)-\mathrm{EgPacket}\mathrm{\_}\mathrm{Counter}(t_{i-1}))\end{array}$(1) So, as it is presented in Equation (2(2) $\begin{array}{rll}\mathrm{EPL}(t_i)& =\frac{\mathrm{NLP}(t_i)}{\mathrm{InPacket}\mathrm{\_}\mathrm{Count}(t_i)-\mathrm{InPacket}\mathrm{\_}\mathrm{Count}(t_{i-1})}& \\ & =1-\frac{\mathrm{EgPacket}\mathrm{\_}\mathrm{Count}(t_i)-\mathrm{EgPacket}\mathrm{\_}\mathrm{Count}(t_{i-1})}{\mathrm{InPacket}\mathrm{\_}\mathrm{Count}(t_i)-\mathrm{InPacket}\mathrm{\_}\mathrm{Count}(t_{i-1})}\end{array}$(2) ) the estimated packet loss (EPL($t_i$)) for the $i^{\mathrm{th}}$ time interval can be calculated as follows: (2) $\begin{array}{rll}\mathrm{EPL}(t_i)& =\frac{\mathrm{NLP}(t_i)}{\mathrm{InPacket}\mathrm{\_}\mathrm{Count}(t_i)-\mathrm{InPacket}\mathrm{\_}\mathrm{Count}(t_{i-1})}& \\ & =1-\frac{\mathrm{EgPacket}\mathrm{\_}\mathrm{Count}(t_i)-\mathrm{EgPacket}\mathrm{\_}\mathrm{Count}(t_{i-1})}{\mathrm{InPacket}\mathrm{\_}\mathrm{Count}(t_i)-\mathrm{InPacket}\mathrm{\_}\mathrm{Count}(t_{i-1})}\end{array}$(2) The dynamic nature of mobile networks in SDMN requires frequent variations in both packet loss and multicast group membership. Moreover, the mobility of devices adds an additional layer of complexity to the network, which requires careful management. So, to manage the network, the SDN controller (SDN-C) receives the differents messages from the SDN switches (SDN-SWs) as it is described in Table 2.

Table 2. Messages description.

Messages	Description
MesSW[k]	Messages send by SDN-SW[k] at regular intervals tr,it can be
	Mes_inSW_EPL or Mes_egSW_EPL[k] or Mes_egSW_Event[k]
Mes_inSW_EPL	It contains IDFlow, SDN-inSW, and InPacket_count values.
Mes_egSW_EPL[K]	It contains IDFlow, SDN-egSW[K],and EgPacket_Count values.
Mes_egSW_Event[k]	message sent by SDN-EgSW[K] egress switch after each
	event MJL received from $\mathrm{MRS}{P}_i$.this message contains
	IDFlow, IDMR, SDN-egSW[K], IDGroupM and MJL.
MSDN-C	MSDN-C = SDN-C_EPL ∥ IDMR ∥ MJL

3.2. Description of the openflow-based handOver (HO) process

The HO process consists of several steps (Prados-Garzon et al., 2016), as described in Figure 2. Firstly, the Multicast Receiver SmartPhone 1 (MRSP1) sends a Measurement Report to the SDN-Base Station1(SDN-BS1) when the signal level from SDN-Base Station 2 (SDN-BS2) exceeds a certain threshold. Then, the SDN-BS1 forwards a Handover (HO) Request message to the SDN-BS2, which executes an admission control procedure to determine whether it can support the incoming MRSP1. If the SDN-BS2 accepts the MRSP1, it sends a HO ACK message to the SDN-BS1, which begins a redirection procedure for the MRSP1 Data Traffic to the SDN-BS2. During this time, the MRSP1 undergoes a synchronization process with the SDN-BS2, during which it cannot transmit or receive any data. Once the synchronization is complete, the MRSP1 sends a HO Confirmation message to the SDN-BS2, which can now send MRSP1 Control Traffic directly to the Source Multicast. The SDN-BS2 then sends a Path Switch Request message to the SDN-C to inform it of the Base Station change. After the SDN-C processes a Path modification it sends an Update Information message to the Source Multicast. Finally, the SDN-C notifies the SDN-BS2 that the new path has been established with a Path Switch Request ACK message. The SDN-BS2 sends an MRSP1 message to the source SDN-BS1, which can conclude the HO process.

Figure 2. SDMN HandOver process.

Algorithm 1 Controller Network Management Algorithm

Require: k=nbegSW

Ensure: MSDN-C, SDN-C_EPL[ti]

1: AfterEach interval [$t_{i-1}$, $t_i$] do

2:  ForEach received messages 'Mes_egSW_EPL[k],Mes_inSW_EPL from SDN-egSW[k] and SDN-inSW at time $t_i$ do

3:   /*InPacket_Counter($t_i$)Extracted from Mes_inSW_EPL($t_i$)*/

4:   /* EgPacket_Counter($t_i$) Extracted from Mes_egSW_EPL($t_i$,k)*/

5:   SDN-C_EPL[$t_i$,k]= 1- (EgPacket_Counter ($t_i$,k) - EgPacket_Counter ($t_{i-1}$,k)) / (InPacket_Counter ($t_i$)- InPacket_Counter ($t_{i-1}$))

6:  EndFor

7: EndAfterEach

8: SDN-C_EPL[ti]= Max ( SDN-C_EPL[ti,k] )

9: sends message MSDN-C to the multicast source

10: AfterEach received message Mes_egSW_Event[k] From SDN-egSW [k] do

11: if Mes_egSW_Event[k]) = ProHandOver then

12:   update_SDN-egSW( SDN-egSW[k])

13:   /*update the Egress switch which attached the Multicast Receiver IDMR (new position)*/

14:   update_Multicast_Tree(IDFlow, IDGroupM,SDN-egSW[], MR[ ], S )

15:   /*SDN-C use the Multicast tree construction algorithm (Bijur et al., 2017)*/

16:   Pro_HandOver( SDN-egSW[k] )

17:   /*Proceed to the process of Handover as it is described in subsection 3.2*/

18: else

19:   update_members_GroupM(Mes_egSW_Event[k], MR[ ])

20:   /* update members MR[ ] of the group IDGroupM according to the Event = Join or Leave sent by IDMR*/

21:   update_Multicast_Tree(IDFlow, IDGroupM,SDN-egSW[], MR[ ], S )

22:   /*SDN-C use the Multicast tree construction algorithm (Bijur et al., 2017)*/

23: end if

24: EndAfterEach

3.3. Description of the based hash-chain schemes

Figure 3 shows an example of the appended $H(M(i,j))$ to the Tnh Messages (Structure 1 (Black colour), Structure 2 (Black and Blue colour), Structure 3 (Black, Blue and Red colour), Structure 4 Eltaief, 2022) used by the proposed Selective hash-based approach. After d Messages, a signature Message Msig is generated and sent. This approach generates a signature Message Msig after d Messages, which is composed of the concatenation of the last BLS hashes computed and signed with the sender's private key before the message of signature. The sender of a message attaches the necessary authentication information and sends it as a Message denoted as $M(i,j)$. Each message $M(i,j)$ contains data $D(i,j)$, and is assigned a unique identifier based on its position in the original stream of messages. The equation can be written as $M(i,j)=M_{i+(j\ast \mathrm{nline}\ast \mathrm{ncol})}$, where $1\le i\le \mathrm{nline}\ast \mathrm{ncol}$ and $0\le j\le 1$. To provide resistance against packet loss, the hash $H(M(i,j))$ of each message is attached to Tnh messages, where the Tnh packets are $(M(i+1,j),M(i+\mathrm{nline},j),M(i+2\ast \mathrm{nline},j),\dots ,M(i+(\mathrm{nhb}-1)\ast \mathrm{nline},j),M(i,j+1))$. The replication of hash values ensures that if one packet is lost, the hash value can be retrieved from the replicated copies. Each message $M(i,j)$ is computed as follows: $M(i,j)=D(i,j)\parallel H(M(i-1,j))\parallel H(M(i-\mathrm{nline}),j)\parallel \cdots \parallel$ $H(M(i-(\mathrm{nhb}-1)\ast \mathrm{nline}),j))\parallel$ Select_Parm $\parallel H(M(i,j-1))\parallel \mathrm{RV}(i,j)$. To elaborate further, the recovery process is used to retrieve lost data in case some of the messages are not received by the receiver. This is achieved by utilizing the recovery vector, which is generated by XOR-ing the previous r hashes of the current message. In other words, the recovery vector $\mathrm{RV}(i,j)$ for the message $M(i,j)$ is computed by bit-XOR operation. In order to generate the recovery vector, a total of r previous hashes are utilized $(\mathrm{RV}(i,j)=H(M(i-1,j))⨁\cdots ⨁H(M(i-r),j))$

Figure 3. Description of the based hash-chain Scheme.

.

3.4. The selective hash-based process

The global view of the network state provided by the controller SDN-C in SDMN can be leveraged to great effect. SDMN switches flow enables the SDN-C controller to have an overview of the network topology. Since networks and mobile users are dynamic, packet loss probability can fluctuate. In our proposed approach, a Selective Hash-Based Process is employed, and the needed redundancy degree is selected based on the packet loss (EPL) obtained from the controller. The controller can use the packet forwarding statistics of SDN switches to estimate the packet loss probability, which is detailed in Subsection 3.1. To fulfill the multicast receivers within the network, we propose to use the feedback received from SDN-C according to EPL in the network and transmit only the needed authentication information to achieve the selected authentication probability. The source multicast selects the hash-chain scheme and decides the optimal degree to use in each block based on the feedback received from the controller to resist the packet loss rate.

Figure 4 depicts the messages that are sent and received between various entities involved in a check authentication stream for multicast transmission, including the source multicast, the controller (SDN-c), switches (SDN-SWs), SDN-Base Stations, and the receivers multicast (SmartPhones). The Data Stream Source authentication process is described in detail through Algorithm 2 for the source multicast, Algorithm 3 for the SmartPhone receivers, and Algorithm 1 for the controller SDN-c.

Figure 4. Sequence diagram.

Algorithm 2 is the source multicast algorithm that enables the construction and transmission of Messages according to the selected parameters (Selec_Parm, after each received message MSDN-C). Specifically, to create Message $M(i,j)$, the source concatenates the appended hashes (PHashes and RV) with Data $D(i,j)$, computes $H(M(i,j))$, and transmits the resulting Message. To guarantee the data origin authentication with non-repudiation of the Data stream, the source generates signature Message Msig by concatenating the last BLS hash values and signing them once every d data Message. Moreover, after receiving the message MSDN-C from the controller SDN-C, the source multicast makes the following actions: First, it adjusts redundancy degree nhb to ensure the needed verification probability. This is achieved by the Change_hash_chain_structure function (Algorithm 6), which takes into account the expected packet loss rate in the network (EPL) to determine the best redundancy degree (nhb) that will achieve the desired verification ratio (dvr). Second, it updates the list of members in the multicast group to ensure accurate transmission.

At each Multicast Receiver SmartPhone, the authenticity of a transmitted Message Mi is verified using Algorithm 3. The receiver first checks the signature Message $M_{\mathrm{sig}}$ and considers its appended hashes secure if the signature is verified. Then, the multicast receiver smartPhone computes the hash code of each Message in reverse order and compares it to the retrieved hash code from $M_{\mathrm{sig}}$. If the two match, Message Mi is considered authentic. Algorithm 4 provides details on the Check authentication procedure. Moreover, If ((structure = 4 and nhb+1 ≥ 4) or (Structure = 3)), the recovery authentication function (Recov_Auth) in Algorithm 5 can be used to retrieve the hash-code of an unauthenticated Message and verify its authenticity.

Algorithm 2 Source Multicast Algorithm

Require: Di, MSDN-C, Select_Parm

Ensure: transmission of Mi

1: ForEach Di do

2:  Append Select_Parm and Di in the current Message Mi

3:  /* $h_{i-1}$=H($M_{i-1}$); */

4:  Extract Structure, nhb and r from Select_Parm

5:  If Structure in {1,2,3,4} Then

6:   Append $h_{i-1}$ in Message $M_i$

7:   For k=1 to nhb-1 do

8:    Append $h_{i-k\ast \mathrm{nline}}$ in the Message $M_i$

9:   EndFor

10:  EndIf

11:  If Structure in {2,3,4} Then

12:   Append $h_{i-(\mathrm{nline}\ast \mathrm{ncol})}$ in Message $M_i$

13:  EndIf

14:  If Structure in {3,4} Then

15:   If nhb+1 ≥ 4 Then

16:    Compute $R{V}_i$ /* $R_i$= $h_{i-1}$ xor …xor $h_{i-r}$*/

17:    Append $R{V}_i$ in the current packet $M_i$

18:   Else

19:    If Structure=3 Then

20:     Compute $R{V}_i$ /* $R_i$= $h_{i-1}$ xor …xor $h_{i-r}$*/

21:     Append $R{V}_i$ in the current packet $M_i$

22:    EndIf

23:   EndIf

24:  EndIf

25:  Buffer $h_i$

26:  Send $M_i$

27: EndForeach

28: AfterEach d Message do

29:  Compute then send the signature Message $M_{\mathrm{sig}}$

30: EndAfterEach

31: AfterEach received message MSDN-C do

32: Extract SDN-C_EPL From MSDN-C

33:  Change_hash_chain_structure(SDN-C_EPL)/* Algorithm 6*/

34:  Update_MulticastGroup(MesSDN-C)

35: EndAfterEach

Algorithm 3 Multicast Receivers SmartPhone Algorithm

Require: Mi

Ensure: Authentication of Mi

1: While received Message Mi do

2:  If Mi is not a signature packet Then

3:   buffer Mi

4:   buffer hashes attached in Mi

5:  Else

6:   Check_Auth(Mi)

7:  EndIf

8: EndWhile

Algorithm 4 Check_Auth Algorithm

Require: Mi

Ensure: Authentication of Mi

1: If M is a Msig Message then

2:  authenticate the signature message M

3: if M is validated Then

4:   M is authenticated

5:   delete M from SetM

6:   /* SetM is a set of Messages not yet authenticated*/

7:   ForEach hash $h_i$ included in M do

8:    Check_Auth ($M_i$)

9:   EndFor

10: EndIf

11: Else

12:  Extract Select_Parm From M

13:  Extract Structure, nhb, r From Slect_Paerm

14:  /*authenticate M against its appended h according to the used structure, nbh and r */

15:  If H(M) = h Then

16:   M is authentic

17:   delete M from SetM

18:   ForEach hash $h_i$ included in M do

19:    Check_Auth($M_i$)

20:   EndFor

21:  Else

22:   M is not authentic

23:   add M in SetM

24:  EndIf

25: EndIf

26: ForEch M in SetM do

27:  Extract Select_Parm From M

28:  Extract structure, nhb and r From Select_Parm

29:  If structure =3 Then

30:   Recov_auth (M,r)

31:  EndIf

32:  If structure =4 and nhb+1 ≥ 4 Then

33:   Recov_auth(M,r)

34:  EndIf

35: EndFor

4. Simulations and results

We performed three simulation scenarios to evaluate the performance of our selective Hash-Based process for multicast data origin authentication for multi-domain SDMN. The first aimed to study the performance of each used structure (structures 1,2,3 and 4) in our hash-based structure and to determine the function Change_hash_chain_structure, the second scenario has the object to evaluate the proposed selective hash_chain approach when we consider the dynamicity of the Multicast receivers SmartPhones (when MRSP1 and MRSP2 leave or join the multicast group). While the third scenario is used to evaluate the performance of the proposed approach when we consider the mobility of the multicast receiver Smartphone (when the MRSP1 moves from position 1(domain 1) to position 2 (domain 2)). These evaluations are performed using robustness and authentication overhead as performance metrics. The robustness of the approach is measured in terms of authentication probability, which is the ratio of authenticated Messages to the total number of received Messages. Considerations for measuring the authentication overhead include delay, communication overhead computation, and buffer size. Specifically, we measured the delay at the receiver side, which is the time that elapsed between the Messages arrival and Message authentication. We also measured the communication overhead by calculating the average number of hashes added per Message. Furthermore, we determined the average buffer size at the receiver side during the process of authentication. Finally, we evaluated the computation overhead at the source multicast by calculating the number of hash and digital signature operations required to authenticate all Messages of the Data stream.

Algorithm 5 Recov_Auth Algorithm

Require: Mi, r

Ensure: Authentication of Mi

1: Recov(Mi,r)

2: /*return true if we can recover H(Mi) as it is described in Subsection 3.3 */

3: If Recov(Mi,r) = true Then

4:  Check_Auth(Mi)

5: EndIf

4.1. Change structure process

The proposed Selective Hash-Based scheme changes the hash chain structure after each message MSDN-C received from the controller SDN-c by the source multicast using the function change_hash_chain_structure (Algorithm 6). Extensive simulations were performed to specify the function of the four hash-chaining structures (structure 1, 2, 3, and structure 4 described in Subsection 3.3). In these simulations, we varied the packet loss ratio (PLR) from 1% to 30%. For each PLR, we noted the minimum redundancy degree required and the authentication delay to achieve a 99% verification probability for the received Messages by the receivers.

The first simulation scenario (Figure 5) involved reducing the number of multicast receivers to one and examining the multicasting of signed Data Streaming on the Internet, as described in the studies by Perrig et al. (2000). The simulation involves sending a data rate of 2 Mbyte/s, with 512 packets of 512 bytes sent every second, and the delay of verification is less than 1 second. The Datastream is comprised of 10,000 Messages, with a signature message sent every d = 100 Messages and a burst loss of 10 (BPL = 10). Message loss was introduced on the link between SDN-SWs and SDN-SWMRSP1, representing the SubNetwork of MRSP1, with a defined parameter PLR. To simulate real-world Internet conditions, VBR (Variable Bit Rate) sources were added that sent Messages to the receiver VBR using variable periods. The Messages sent by the VBR source were transmitted on the same link between SDN-SWs and SDN-SWMRSP1 as the messages of the source multicast. The simulation results are presented in Figure 6.

Figure 5. The simulation scenario 1.

Figure 6. The results of simulation scenario 1.

For an average loss ratio SDN-C_EPL, the change_hash_chain_structure function (Algorithm 6) selects the structure (degree nhb), which guarantees 99% of verification probability. According to the results obtained in Figure 6(a), we can notice that for many values of PLR, the redundancy degree values used by the four hash chain structures are roughly the same. However, the used structures in our approach generate different authentication delays (see Figure 6(b)). Therefore, to select the used structure to achieve 99% of the verification probability, we select the one that has the minimum redundancy degree nhb. if there is more than one structure that has the same redundancy degree nhb then we select one of them that has the minimum delay. So this process is used by the Function described in (Algorithm 6).

Algorithm 6 The change_hash_chain_structure Function

Require: Degree[ ][ ], Delay [ ][ ], SDN-C_EPL

Ensure: Select_Parm

1: /* Degree[i][j], where i in [1..4] and j in [1..30] (values in Figure 6(a))

2: Delay [i][j], where i in [1..4] and j in [1..30] (values in Figure 6(b))*/

3: min_degree = Degree[1][SDN-C_EPL]

4: For i=1 to 4 do

5:  If Degree[i][SDN-C_EPL] ≤ min_degree Then

6:   min_degree = Degree[i][SDN-C_EPL]

7:   struct[K]=i

8:  EndIf

9: EndFor

10: min_delay = Delay [struct[1]][SDN-C_EPL]

11: For m=1 to k do

12:  If Delay[struct[m]][SDN-C_EPL] ≤ min_delay Then

13:   min_delay = Delay [struct[m]][SDN-C_EPL]

14:   Structure= m

15:  EndIf

16: EndFor

17: nbh=min_degree

18: If (Structure=4 and nhb+1 $\ge 4$) or( Structure=3) Then

19:  r=4

20: EndIf

21: Select_Parm = Structure ∥ nhb ∥ r

In order to assess the effectiveness of the proposed approach, simulations were conducted using several existing mechanisms, namely Flex_hash_chain (Eltaief, 2022), TIM (Seo & Youn, 2018), RLH (Challal & Bouabdallah, 2005), EMSS (Perrig et al., 2000), and MLCC Eltaief Youssef (2018). The simulations aimed to find the required redundancy degree for each mechanism in order to achieve a verification probability of 99% when subjected to packet loss rates (PLR) of 30%, 20%, and 10%. The results of these simulations are presented in Table 3 and are discussed in detail in Section 4.2.

Table 3. Evaluation results of the simulation scenario 2.

	Select	Flex	TIM	TCBC	MLCC	EMSS	RLH
Avg Communication	3,81	3,94	5,1	5,2	5,08	6,08	7,08
Overhead(hash/message)
Avg Delay	126,13	167,26	183,25	167,1	173,56	171,15	181,33
at receivers side(ms)
Avg buffer size	37325	37051	27770	22367	24934	56124	47734
at receivers side (bytes)
Storage at	50	50	8	5	100	<100	100
the source side (hash)			+ 8 messages	+ 5 messages
Computation at	100 sig	100 sig	1250 sig	2000 sig	100 sig	100 sig	100 sig
the source side(sig+hash)	+ ${10}^3$ hash	+ ${10}^3$ hash	+ ${10}^3$ hash		+ ${10}^3$ hash	+ ${10}^3$ hash	+ ${10}^3$ hash
Delay at	No Delay	No Delay	8 messages	5 messages	No Delay	No Delay	No Delay
the source side (Message)

To evaluate the performance of the proposed approach we run simulations of Flex_hash_chain (Eltaief, 2022), TIM (Seo & Youn, 2018), RLH (Challal & Bouabdallah, 2005), EMSS (Perrig et al., 2000), MLCC (Eltaief & Youssef, 2018), to determine the needed redundancy degree by each mechanism using PLR equals to 30%, 20% and 10%( to achieve the verification probability 99% ). The results of this simulation are used for evaluation in Subsection 4.2 (Table 3).

4.2. Performance evaluation results

In this paper, Figure 7 illustrates the second and third simulation scenario. The communication between network devices is carried out through Floodlight controller (SDN-C), and the OpenFlow 1.3 protocol is used for this communication with Open vSwitches (SDN-SWs) (ONF, 2015) running on the network devices to send UDP traffic. The simulation involves sending a data rate of 2 Mbyte/s, with 512 packets of 512 bytes sent every second, and the delay of verification is less than 1 second. The Datastream is comprised of 10,000 Messages, with a signature message sent every d = 100 Messages and a burst loss of 10 (BPL = 10). The message loss occurs on link 1 between SDN-SWs1 and SDN-SWMRSP1 and also on link 2 between SDN-SWs2 and SDN-SWMRSP2, which represent the SubNetwork of MRSP1 and the SubNetwork of MRSP2, respectively. The simulation conditions aim to resemble those used in the Internet, with a VBR (Variable Bit Rate) source that sends messages to the VBR receiver with variable periods. The messages sent by the source VBR will be transmitted on the same link 1 and link 2 as the messages of the source multicast. The controller SDN-C executes the process of Algorithm 1. It sends the message MSDN-C to the source multicast every one second(tr = 1 s). After each tr second, the controller receives Messages from both SDN-inSW and SDN-egSW[k] switches (MesSDN-EgSW-EPL[k], MesSDN-InSW-EPL and MesEgSDN-SW-Event[k]). So, the SDN-C starts to extract the number Packet_Counts and then calculates the EPL using Equation (2(2) $\begin{array}{rll}\mathrm{EPL}(t_i)& =\frac{\mathrm{NLP}(t_i)}{\mathrm{InPacket}\mathrm{\_}\mathrm{Count}(t_i)-\mathrm{InPacket}\mathrm{\_}\mathrm{Count}(t_{i-1})}& \\ & =1-\frac{\mathrm{EgPacket}\mathrm{\_}\mathrm{Count}(t_i)-\mathrm{EgPacket}\mathrm{\_}\mathrm{Count}(t_{i-1})}{\mathrm{InPacket}\mathrm{\_}\mathrm{Count}(t_i)-\mathrm{InPacket}\mathrm{\_}\mathrm{Count}(t_{i-1})}\end{array}$(2) ). Also, it determines from the message MesEgSDN-SW-Event[k] idFlow, EgSW, idMR, idGroupM, and events. According to the value of Event, the SDN-c executes the process of the HandOver Process and updates the multicast_tree.

Figure 7. The simulation scenario 2 and 3.

For the second simulation scenario (Figure 7), we consider that the Multicast receiver SmartPhone 1 Leaves the group multicast after 10 seconds and Joins the group multicast after 20 seconds.

The results of the Estimation Packets Loss (SDN-C_EPL) for the Multicast receiver SmartPhone SubNets (SDN-C_EPLMRSP1 and SDN-C_EPLMRSP2) are shown over time in Figure 8. The SDN-C computes these SDN-C_EPL values and determines the maximum value SDN-C_EPL_Max. SDN-C_EPL_Max value is transmitted to the source multicast each one second (tr = 1 second) by the controller. To compute the SDN-C_EPL, the controller employs the algorithm shown in Algorithm 1. Initially, We assume that all SubNetworks of the multicast receivers SmartPhone have an SDN-C_EPL of 30% at time zero.

Figure 8. The SDN-C Estimation Packets Loss (SDN-C_EPL) for the simulation scenario 2.

Figure 9(a) shows that SDN-C_EPL_Max varies over time, while TIM, TCBC, MLCC, EMSS, and RLH lack information on PLR values in the network. So, it must choose a redundancy degree that enables multicast receiver SmartPhone to authenticate received Messages with a 99% probability.

Figure 9. Required redundancy degree in terms of time (simulation scenario 2).

Figure 9(b) shows that if the source multicast uses the maximum packet loss ratio (30%), it will use higher redundancy degrees (7, 6, and 5) for RLH, EMSS, and (TIM, TCBC, MLCC), respectively, resulting in unnecessary authentication information overhead.

Figure 9(c) shows that if the source multicast uses the average packet loss ratio 20%, it will use intermediate redundancy degrees (3, 5, 6) for respectively (TIM, TCBC, MLCC), EMSS and RLH, but several receivers still not achieve 99% of the verification probability.

Figure 9(d) shows that if the source multicast uses the minimum packet loss ratio (10%), it will use lower redundancy degrees equal to 2 for TIM, TCBC, MLCC, EMSS, and RLH, but most Multicast receivers will not achieve the 99% verification probability.

In comparison, RLH, EMSS, TCBC, MLCC, and TIM use the maximum packet loss ratio (30%) to ensure that every multicast receiver achieves the requested 99% verification probability, at the cost of higher authentication information overhead.

Also, Figure 9(b–d) despite that the used degree for the proposed Selective hash-based scheme and the Flex_hash_chain are variable.

After performing simulations: Firstly using Select_hash_chain it was found that multicast receivers SmartPhone1 and SmartPhone2 achieved authentication probabilities of 98.82% and 99.22%, respectively. Secondly using Flex_hash_chain, it was found that multicast receivers SmartPhone1 and SmartPhone2 achieved authentication probabilities of 98.62% and 99.04%, respectively. So, these results prove that the obtained authentication probabilities at the multicast receiver SmartPhones are in close to the desired authentication probability (99%).

Table 3 shows that the proposed select_hash_chain and Flex_hash_chain schemes clearly outperform the other schemes (TIM, TCBC, MLCC, EMSS, and RLH). Effectively, select_hash_chain and Flex_hash_chain take into consideration the dynamicity of the network (PLR viable and multicast receiver SmarPhones can Join or Leaves the group Multicast). The select_hash_ chain and Flex_hash_chain scheme allow saving at a minimum of 1,16 hashes per message compared to the other schemes.

Comparing the proposed Select_hash_chain with Flex_hash_chain scheme we found that the first one used 3,81 hashes per message and the second one used 3,94 hashes per message. Therefore, the select_hash_chain approach allows saving up to 0,13 hashes per message compared to the Flex_hash_chain scheme. Assuming the use of a 16-byte hash code, such as SHA-128 (Gilbert & Handschuh, 2004), and sends a stream of 10,000 Messages, this means that the Select_hash_chain approach can save up to 20.8 Kbytes of authentication information compared to Flex_hash_chain. In addition, the proposed approach generates low average delay at the receiver SmartPhone side compared to Felex_hash_chain. The select_hash_chain generates an average delay equal to 126,13 ms, and the average delay generated by the Felex_hash_chain equal to 167,26 ms. However, the proposed select_hash_chain approach generates more average buffer size at the receiver SmartPhones side, which is 37325 bytes. This value is 274 bytes more than that used by Flex_hash_chain.

In Multi-domain SDMN environments, a multicast receiver's Smartphone can change position (domain) at any time. So, we present in the third simulation scenario (Figure 7 that the multicast receiver SmartPhone1 (MRSP1) moves from position 1 (domain 1) to position 2 (domain 2) after 20 seconds.

The results of the Estimation Packets Loss (SDN-C_EPL) for the Multicast receiver SmartPhone SubNets (SDN-C_EPLMRSP1 and SDN-C_EPLMRSP2) are shown over time in Figure 10. To compute the SDN-C_EPL, the SDN-C employs the algorithm shown in Algorithm 1. Initially, We assume that all SubNetworks of the multicast receivers SmartPhone have an SDN-C_EPL of 30% at time zero. Figure 10 shows that after 20 seconds the SDN-C_EPL_MRSP1 has the same value as SDN-C_EPL_MRSP2. Effectively, the multicast receiver SmartPhone1 (MRSP1) is located at position 2 after 20 seconds. So, the MRSP1 has the same SubNetworks as the MRSP2.

Figure 10. The SDN-C Estimation Packets Loss (SDN-C_EPL) for the simulation scenario 3.

Figure 11(a) shows that using the Select_hash_chain approach, the multicast receiver SmartPhone1 (at position 2) continues to receive data from the source multicast after 20 seconds (Begin HandOver process). However, using the Flex_hash_chain approach the multicast receiver SmartPhone1, at position 2, stops receiving data stream after 20 seconds (Flex_hash_chain approach does not support mobility).

Figure 11. Required redundancy degree in terms of time (Simulation scenario 3).

Figure 11(b) shows that using the Select_hash_chain approach and the Flex_hash_chain, the multicast receiver SmartPhone2 continues to receive data from the source multicast.

Table 4 presents the evaluation of MRSP2 to reach 99% of the authentication probability according to Simulation scenario 3 (Figure 7). Comparing the proposed Select_hash_chain with the Flex_hash_chain scheme we found that the first one used 3,56 hashes per message and the second one used 3,73 hashes per message. Therefore, the select_hash_chain approach allows saving up to 0,17 hashes per message compared to the Flex_hash_chain scheme. In addition, the proposed approach generates a low average delay at the receiver SmartPhone2 side (equal to 112,76) compared to the Felex_hash_chain (equal to 159,34 ms). However, the proposed select_hash_chain approach generates more average buffer size at the receiver SmartPhone2 side. These results validate those obtained in the first simulation scenario (The MRSP2 has the same behaviour, it stood in the same position).

Table 4. Evaluation results of MRSP2 of the simulation scenario 3.

	Select_hash_chain	Flex_hash_chain
Avg Communication	3,56	3,73
Overhead(hash/message)
Avg Delay	112,76	159,34
at receivers side(ms)
Avg buffer size	36568	36323
at receivers side (bytes)
Storage	50	50
at the source side (hash)
Computation at the source	100 sig + ${10}^3$	100 sig + ${10}^3$
side (signature + hash)
Delay at the source	No Delay	No Delay
side (Message)

Table 5 presents the evaluation of MRSP1 to reach 99% of the authentication probability according to Simulation scenario 3 (Figure 7). The proposed approach used an average communication overhead equal to 3,56 hashes per message and an average delay at the MRSP1 equal to 151,12. As it is shown in Figure 11(a) using the Select_hash_chain approach, the multicast receiver SmartPhone1 (at position 2) continues to receive data from the source multicast after 20 seconds (Begin HandOver process). However, using the Flex_hash_chain approach the MRSP1(at position 2) stops receiving data stream after 20 seconds (Flex_hash_chain approach does not support mobility). According to these simulation results, the Selective Hash-based Approach supports the dynamicity of modern networks and the mobility of Mobile Nodes. So, this approach is adapted for the multi-domain Software Defined Mobile Network and The obtained results of simulation scenarios show that our proposed approach reduces delay and bandwidth overhead by saving authentication information redundancy while maintaining high robustness to packet loss.

Table 5. Evaluation results of MRSP1 of the simulation scenario 3.

	Select_hash_chain	Flex_hash_chain
	(for all simulation time)	(only the first 20 s)
Avg Communication	3,56	4,31
Overhead(hash/message)
Avg Delay	151,12	184,24
at receivers side(ms)
Avg buffer size	38354	40346
at receivers side (bytes)
Storage	50	50
at the source side (hash)
Computation at the source	100 sig + ${10}^3$	100 sig + ${10}^3$
side (signature + hash)
Delay at the source	No Delay	No Delay
side (Message)

5. Conclusion

In group communication, Multicast communication is an efficient way of reducing network traffic. However, it is important to ensure data origin authentication with non-repudiation in the multicast security architecture. The proposed mechanism is designed to operate in multi-domain SDMN and dynamic environments, where network conditions, multicast group membership and position of the multicast Mobile receivers can change over time. Using the advantages of the global view of the controller in Software Defined Mobile Network, we develop a control algorithm. This algorithm estimates network packet loss probability to assist the multicast source in selecting the adequate hash-chain scheme. The obtained results of simulation scenarios show that our proposed approach reduces delay and bandwidth overhead by saving authentication information redundancy while maintaining high robustness to packet loss. The proposed approach incurs more storage overheads at both the sender and receiver sides compared to other approaches. However, these storage overheads are considered manageable and can be accommodated by current storage mobile devices.

Disclosure statement

No potential conflict of interest was reported by the author(s).

Additional information

Notes on contributors

Hamdi Eltaief

Dr. Hamdi Eltaief obtained his Master’s degree in Computer Sciencefrom Faculte des Sciences de Monastir (FSM), University of Monastir, Tunisiain 2001 and both his DEA and Ph.D. degrees in Computer Science respectively, fromFaculte des Sciences de Tunis (FST), University of El-Manar, Tunisia, in January2005 and from Ecole Nationale des Sciences de l’Informatique (ENSI), University of Manouba, Tunisia, in January 2012. He is currently serving as Assistant Professorof computer science at the Institut Superieur d’Informatique et des Technologies deCommunication, Hammam Sousse, University of Sousse, Tunisia. Dr. Hamdi Eltaief has over 16 publications to his credit in the form of journal and conference papers. His research interests include Network Security, the Internet of Things, wireless sensornetworks, and Software-Defined Networking (SDN) with a focus on Security.

Ali El Kamel

Dr. Ali El Kamel received a Diplôme d'Ingénieur en informatique from the ENIT, University of El-Manar, Tunisia in June 2003 and a Ph.D degrees in Computer Science from Ecole Nationale des Sciences de l’Informatique (ENSI), University of Manouba, Tunisia, 2013. He is currently serving as an Assistant Professor of computer science at the Institut Supérieur d’Informatique et des Technologies de Communication, Hammam Sousse, University of Sousse, Tunisia. Dr. Ali El Kamel has over 10 publications to his credit in the form of journal and conference papers. His research interests include Computer Networks, wireless sensor networks, and Software-Defined Networking (SDN) with a focus on QoS.

Habib Youssef

Dr. Habib Youssef received a Diplôme d'Ingénieur en informatique from the Faculté des Sciences de Tunis, University of El-Manar, Tunisia in June 1982 and a Ph.D. in computer science from the University of Minnesota, USA, in January 1990. From September 1990 to January 2001 he was a Faculty member of the computer engineering department of King Fahd University of Petroleum & Minerals (KFUPM), Saudi Arabia (Assistant Professor from 1990 to 1995 and Associate Professor from September 1995 to January 2001). From February 2001 to June 2002, he was a Maitre de Conférences en informatique at the Faculté des Sciences de Monastir (FSM), University of Monastir, Tunisia. From July 2002 to August 2005, he served as the Director of the Institut Supérieur d’Informatique et Mathematiques of the University of Monastir. He is currently serving as a Professor of computer science and Director of the Institut Supérieur d’Informatique et des Technologies de Communication, Hammam Sousse, University of Sousse, Tunisia. Dr. Habib Youssef has over 110 publications to his credit in the form of books, book chapters, and journal and conference papers. His main research interests are computer networks, performance evaluation of computer systems, and algorithms for the design automation of electronic systems.