New Service Architecture For Iptv Over Internet

Published Date: 02 Nov 2017

In recent years multimedia applications over internet and Internet Protocol Television (IPTV), has become to gain much more attention. IPTV has some specific requirements such as; high bandwidth, scalability, minimum delay, jitter and channel switch time. IP multicast and IMS Protocol is capable of these features but all the routers in the core network have to possess multicast property and IMS has some scalability issues. Because of these reasons using P2P communication in IPTV context is becoming more popular. However, to support IPTV bandwidth and delay/jitter requirements, the network has to own more intelligence in the sense of using network resources. In our solution, application layer multicast, scalable video coding and probing techniques are combined to get more effective result. We generate new application layer multicast protocol (PALMTV) and evaluated its performance in the aspect of IPTV. We also verified our solution’s performance by the simulation results taken from ns-2

In recent years with the help of successful compression techniques and new broadband access networks, popularity of video transmission over internet has grown enormously. Internet Protocol Television (IPTV),which consists of these modern technologies and delivers media content through network, began to gain more attraction by end users. Currently, IPTV market continues to grow in the sense of both customer size and investments [28]. According to Inforesearch Group predictions, U.S. IPTV market will grow to 15.5 million in 2013 [1]. ABI Research has reported that IPTV will expand and is expected to have 79 million subscribers by the year 2014 [28]. ABI research shows IPTV is evolving not only in the countries which has high-speed network internet but also in developing countries, too. The improvements in the network technology and scalable video coding techniques make IPTV to next killer application next generation internet [32].

1.2 IPTV Service Requirements

IPTV has some specific service requirements in order to race against the cable and satellite TV. Transmission delay, channel zapping time, scalability and high-bandwidth are basic service requirements for IPTV.

It has been proved that low transmission delay without reducing the system throughput is crucial in IPTV systems [49], [15]. Transmission delay should be under 2 seconds[49] in order to avoid freezes in an alive broadcast.

1

Channel zapping is another key issue in the aspect of more than one video transmission. When end users change the active channel, they want to watch next channel immediately. Agilent Technologies has reported that the channel zapping time should be under 0.5 seconds to ensure end user requirements.

Scalability is another critical issues in IPTV context. Because of highly dynamic network state and subscribers expectations about the broadcast, overall scalability of the architecture becomes very important.

The other main requirement for IPTV is high-bandwidth to carry related media data source to destination. Video transmission data is huge compared to other network services such as mail, surfing; and demands huge bandwidth. For an HD video practically 6 Mbps should be supported [49].

1.3 Previous Work On IPTV Network Structure

In literature, there are plenty of different proposals for IPTV Network structure. Main proposals are listed below:

• IP Multicast: IP multicast infrastructure [54] sends a packet to multiple receivers. It sends packets to a group of receivers only once. Since it uses router multicast capabili- ties, it has deployment problems.

• Peer-To-Peer Streaming : In a P2P IPTV system, peers supply their bandwidth in or- der to send the live video. It has extreme advantages on scalability,development and deployment. However, it has some unsolved problems about delay, jitter guarantee.

• IP Multimedia Subsystem (IMS) : IMS is a standardized infrastructure and stands on a horizontal control layer which isolates service from access network. In IMS-based IPTV structures, there is high bandwidth consumption problem.

2

1.4 Proposed IPTV Network Design

The proposed IPTV network structure (PALMTV) is basically a hybrid solution, it combines the ideas; probing (bandwidth estimation), ALM (Application Layer Multicast), P2P (Peer- to-Peer), and Scalable Video Coding (Scalable Video Coding).

The novel features of our structure are as follows:

• Different than the previous works, we combined probing, ALM and SVC ideas.

• We proposed a new "ALM Clustering Algorithm" and a new "Video Compression Con- trol Algorithm" in order to ensure IPTV service requirements.

• Our solution based on available bandwidth estimation on network, so there is not a necessity to learn network topology or leased line information.

The remainder of this paper is organized as follows. Chapter 2 expresses IPTV overview in the sense of QoS requirements, previous proposals, and related technologies. Chapter 3 presents our proposal for IPTV. In this chapter we try to explain every part of our software blocks, their usage and necessity in detail . In chapter 4 overall performance evaluation can be found as well as our assumptions and traffic models. Chapter 5 states our conclusions and the future direction of our research.

3

CHAPTER 2

LITERATURE OVERVIEW

Internet Protocol Television (IPTV) represents the delivery of television content to end users over Internet technology. Differs from normal broadcast TV, IPTV can provide different con- tent to different users. The two main functions of IPTV are; live TV support and video-on- demand service support. It makes it possible to log user behaviours and provides different commercials for different users. In the recent years, the media services over the Internet and IPTV grow rapidly and this trend continues as seen in Fig.2.1.

Figure 2.1: IPTV Progression [1]

However it is not an easy task to manage IPTV. Because the Internet was not designed to provide and support multimedia applications; it represents a shared medium and in order

4

to deliver media applications, it offers a best effort traffic. However, multimedia services require different demands from the Internet. For example, these kind of services are more sensitive in the sense of delay, jitter,but they are more tolerable to packet loss. They need stable bandwidth, low latency-jitter in order to meet the user desires. To meet with these requirements, there are plenty of different IPTV architectures and solutions in the literature.

Quality of Service (QoS) is basically about metrics: packet delay, loss and jitter. Certainly packet delay, packet loss, and jitter are critical issues; but QoS is just the first step. Quality of Experience (QoE) is more about what happens in the customer’s side. Good utilization of network sources mean nothing if a customer to a service is having a problem. QoE is relevant to but differs from QoS, it is a subjective measure of a customer’s experiences with a service. In IPTV context, zapping time and experienced video quality are considered to be the most important parameters of QoE metrics.

2.1 IPTV Architecture

Internal Telecommunication Union (ITU) specifies and introduces the basic specifications for IPTV [32]. According to their report in the first stage of IPTV, providers have to support four main service types. These types are live TV, Video On Demand (VoD), TSTV (time-shifted TV) and Personal Video Recording (PVR). For the second stage of IPTV, some other extended services/applications may be requested in the future.

Four different kinds of basic functions have to be assigned to achieve IPTV structure, these functions are Customer, Service Provider (SP), Network Operator, and Content Provider (CP). These functions can act separately and independently to satisfy the requirements of IPTV, so the overall structure has to permit the decomposition of the function parts. Because there is broadband multicast, security is another key issue about IPTV, service security has to be provided to ensure the interests of CPs and SPs .

To satisfy all the requirements above, an IPTV architecture can be divided into five main func- tion sets which are Customer, Service Operation - Management, Content Operation, Media Distribution - Delivery, and System Management - Security. Each function set can be divided into subsets, their relation can be seen on 2.2.

5

Figure 2.2: IPTV Schema [32]

On the right side of 2.2 there are the end-user functions. These include the hardware and software components such as home gateways, set-top boxes , PC clients, and mobile devices. They allow the subscribers to receive and consume the transmitted video content.

In the middle part of 2.2 content provider operations can be found. In this part there are provider functions such as, TV channel, music data, encode/decode operations.

In left side of 2.2 system management operations take place. It is system management’s re- sponsibility to handle all delivery process, multicast operations to deliver video content. Uni- cast operations have to be handled here, too. This service functions are designed to manage QoS, network sources, packet loss errors.

There are plenty of different solutions to realize IPTV. Some of them are based on next- generation networks. Next-generation networks use a single transportation link to carry whole information and services (data, voice, video,... etc) via encapsulating these packets. To achieve NGN structure, some architectural changes in the core and access network must be made by service providers. Basic three options to provide IPTV service suggested by ITU-T [53] are listed below:

6

• Non-NGN based IPTV solutions: It is possible to make some inter working with NGN but generally a separate service control and application layer were developed specially for IPTV services (IPTV middle ware).

• NGN based IPTV architecture: It enables interaction and inter working over specified reference points between IPTV applications and some existing common NGN com- ponents. This approach uses a dedicated IPTV subsystem within NGN to provide all necessary IPTV required functionalities.

• IMS based IPTV architecture: The IP Multimedia Subsystem (IMS) is an architec- tural framework to deliver multimedia services over Internet. Recently, some studies showed that it can used to provide IPTV service. The details of IMS architecture will be discussed in 2.3.3. It specifies IPTV functions supported by the IMS subsystem and employs these functions to allow the reuse of IMS functions and make service initiation and control based on SIP (Session Initiation Protocol).

To realize the second and third solutions, all network components have to operate on NGN mode. So, second choice becomes unusable in close future, because of its implementation issues. To achieve first and second proposals there are certain methods in literature, which are explained and discussed in 2.3 in detail.

2.2 IPTV Challenges and Performance Metrics

To propose a solid IPTV architecture, IPTV requirements have to be found out. In this section challenges and performance metrics to provide IPTV is discussed in detail.

2.2.1 Network Bandwidth

The bandwidth provided over the access network limits the size of transmitted video stream- ing data. When subscribers change their preferences about the video quality, the bandwidth demand raises. If that demand exceeds the maximum capacity of the transmission link then there are packet losses which cause screen impairment and result in subscriber complains.

Scalable Video Coding (SVC) is a widely used video compression standard. With SVC a

7

video can be encoded into 2 Mbps standard definition (SD) stream or 6 Mbps high definition (HD) video stream [49, 16]. Hence, to broadcast any video-stream for three hundred sub- scribers, 10-15 Gbits of traffic has to handled in core network per second. According to these results, some kind of multicast algorithm has to be implemented in the network in order to provide IPTV service.

2.2.2 Packet Loss

IP packet loss can trigger screen impairments, wrong image sequences, or unwanted low reso- lution and unavailable images. It takes place when some data packets fail to reach destination along the transmission path. Because of the real-time nature of IPTV, undelivered packets are not supposed to be retransmitted.

To understand the packet loss effects on subscriber side we will examine an example. Assume that IPTV delivery uses Scalable-Video-Coding. If missing packets have some information about the reconstruction of the frames then there is a strong possibility that video signal may be lost for a short period of time. If the lost packets are related to only video data, the impact is less intense but still video quality is reduced.

IPTV is very sensitive to packet loss. According to [16, 18], when packet loss ratio (PLR) goes beyond 0.1 percent, it can result in unacceptable video quality. So, error resiliency is very important in this context. Especially SVC and the other video compression techniques makes IPTV much more sensitive to packet loss as the packets of the compressed video carry more information compared to the uncompressed video. When PLR exceeds 0.5 percent, continuous picture problems occur, after that point pictures broke up and freezes become unavoidable.

2.2.3 Jitter

Jitter represents the undesired deviations in the frequency of coming video signal. In other way, jitter is a change in end-to-end latency with respect to time. Eventually, this triggers the packet delay, zapping time and packet loss problem. It has a direct outcome on the decoding processes.

8

According to [19], the jitter for an IPTV architecture should not exceed 40 ms in order to achieve requested video quality. [16, 18], investigates the video-transmission performance for interactive video or video conference. Their results show that the jitter value should not be greater than 30 ms to achieve the demanded video signal quality.

2.2.4 Packet Delay

IPTV is a real-time process, and it works with the Real-Time Transport Protocol (RTP) which adds time-stamp to the transmitted packets in order to synchronize the whole process. In IP networks, the transmission route for packets may not be same. It causes different inter-arrival times, accordingly packets arrive with a different order than the order they are generated. RTP puts every packet into the right place as long as the packet delay does not exceed the size of decoded buffer. If the delay exceeds the buffer’s limits, then the intermediary packets are considered as lost and dropped eventually. This causes lost video service for a period of time.

To compete with the cable or satellite TV, IPTV has to support comparable or better perfor- mance for customers. For example, an HD video has a transmission delay requirement below

2 seconds [49].

2.2.5 Zap Delay

The channel zapping time is the time required to switch channels. It is defined as, the time between leaving a channel and receiving the first data stream from just joined channel is zapping time.

Researchers in [21, 20] suggest that for good QoE channel switching time should under 0.43 seconds.

2.2.6 Scalability

IPTV has very dynamic subscriber size, the architecture has to handle variations of network size very well [49].

9

2.2.7 Error Resilience

IPTV networks are very sensitive to packet loss and errors. Retransmission may be unavoid- able for sometimes, so error resilience become a key component for any IPTV architecture.

2.2.8 Other Performance Metrics

Security, Digital Right Management (DRM) control, and scheduling data packets are some other critical QoE parameters about IPTV, but they are not in the scope this thesis.

2.3 IPTV Proposals

According to section 2.1, there are three main options to provide IPTV. To construct an IPTV architecture, we examined two of the three options. We did not take into consideration NGN- based solutions due to their implementation difficulties. IP Multicast and P2P Streaming are basic non-NGN based solutions in literature. Also, there are plenty of studies about IMS- based IPTV solution, we examined these solutions, too.

2.3.1 IP Multicast

The Internet Protocol (IP) is designed with embedded support for multicast delivery (IP Mul- ticast). IP Multicast lowers the network load by canceling the redundant data transfers, it only replicates data in routers only when necessary [25, 26].

In IP Multicast, the source node sends an IP datagram to a group address which is a unique address in the IP address range that is reserved only for multicast purposes. The datagram is transmitted to receivers, which are interested in receiving related data. So, all the receiving hosts have to subscribe to the multicast group address. In the multicast process, an IP packet is forwarded to all subscribers for the group. To achieve this, IP routers must know that this forwarded data is multicast group data, this information is shared through all routers which have a role in this process.

Routing for a multicast group can be demonstrated as a multicast tree. The root of this tree is

10

the sender for multicast packets. Receivers are the leaves and routers are the non-leaf nodes in the multicast tree.

In multicast, routers replicate IP Multicast packets to their children nodes. As a result of that, IP routers reduce total traffic compared to unicast where sender sends the exactly same packets for every subscriber.

In Fig.2.3 the schema of IP Multicast tree can be found. The datagram is replicated at all the routers on the path of transmission.

Figure 2.3: IP Multicast Tree / Replication of Datagram.

The source only sends information once and routers take care of the rest. The redundancy is minimized by this way. However, IP multicast has not been widely used in network because of following issues:

• IP Multicast has to be supported by all the routers on the path source to subscriber.

• Security concerns

11

When we look at how IP multicast responds to the QoS demands for IPTV:

• Bandwidth: Actually IP Multicast can realize the IPTV requirement for bandwidth discussed in 2.2.2. Because IP multicast uses the bandwidth more efficiently in the core network, it can carry easily hundreds of channels. One of the successful examples of IP multicast is AT-T U-Verse. AT-T U-Verse [27] can support for four channels bit rate of 24 Mbps for HD broadcast.

• Packet Loss Ratio: For a payload of 1024 bytes, the PLR starts just below 0.2 percent than decreases and approaches to 0 percent [24]. That result accomplishes the IPTV PLR requirement in 2.2.2.

• Packet Delay: It is reported that AT-T U-Verse [27] can achieve video transmission delay less than 2 seconds.

• Jitter: According to the researchers the jitter can be eliminated by IP multicast via a playback buffer capable to hold 15 ms of video-stream data [22].

• Zapping Time: Channel switching time can be manageable with IP multicast. It can be decreased to 0.3 sec with some control algorithms [23]

• Error Resilience: If some error occurs in the network like packet loss, then retrans- mission is needed. Most of the time, IP multicast structures solve this problem by using redundancy servers (Buffered information is hold in these servers in case of er- ror). However, these servers have limited capacity and they can recover up to 1 percent packet loss [27, 49] . According to researchers in [14], error cases are not rare in IP multicast. They claim that, there has to be some error protection and management protocols in IP Multicast.

• Scalability: Scalability is the major problem for IP multicast [49]. Redundancy servers are used against possible errors in IPTV. Because their capacity is limited, more retrans- mission requests come, then these become overloaded adversely affecting the network resiliency. Moreover, IP multicast uses IGMP (Internet Group Management Protocol) to handle multicast operations. To provide IPTV service with IP Multicast, all the routers in the network have to support IP multicast and IGMP. In today’s internet, there are a few routers which can manage IP multicast. So, it means there has no chance

12

to provide IPTV using IP multicast in the near future, unless there is a big alteration in core network. As a result, IP multicast is an unrealistic proposal when considering underlying structure.

2.3.1.1 IP Multicast Overall Summary

IP multicast is a very powerful technique to deal with the delay, jitter, network bandwidth utilization problems of IPTV. Moreover, it has a very good response to zapping time demands. However, in case of error it becomes very impractical and scalability is major drawback. To accomplish an IP Multicast solution for IPTV, the underlying network structure has to change and it is the bottleneck of IP Multicast.

2.3.2 P2P Streaming

In IPTV context P2P streaming means delivering live over the Internet. It involves media data, an encoder to digitize the content, a media publisher, and a content delivery network to distribute and deliver the content. We will be interested in distribution and delivery part.

A peer-to-peer (P2P) network is a network in which each computer can behave like a provider or subscriber for others. This structure enables various of different data sharing like files, video, audio. P2P networks can be established in home, business or in the Internet.

In P2P systems the peers can change dynamically and hence, in a P2P IPTV system, network size constantly varies. This causes the establishment of new peer relations or some alterations between peers. Peer churn is a collective effect created by departures and arrivals of new peers. Characterizing peer churn is very challenging in practice, because of large size and dynamic nature of the P2P systems. Hence, in large scale P2P systems, characteristics of peer churn are not well understood. There are models for peer churn and some measurement studies show that the effect of the churn is unsteady [8, 9].

In P2P systems peers offer their bandwidth in order to send the live video. It has significant ad- vantages for scalability, development and deployment. However, its disadvantages for IPTV are transmission delay, jitter and bandwidth. PPLive [41], CoolStreaming [40], PPStream [43] , UUSee [42] are the successful P2P streaming applications.

13

Now let’s analyse the properties of P2P networks in relation to IPTV:

• Bandwidth: To meet the bandwidth demands of IPTV P2P architectures has to reach certain uplink bandwidth which is limited by the access network bandwidth [49]. In most of the cases access network bandwidth is lower than 5 Mbps. It limits the P2P performance.

• Packet Loss Ratio (PLR): According to researchers, pure P2P network performance is worse than IP multicast in the sense of PLR. In P2P networks PLR can be increase up to 2 percentage [52].

• Packet Delay: Theoretically P2P architectures can achieve transmission delay under 2 seconds [49], whereas in real life transmission delays are higher than 2 seconds. There are some cases that delay range changes between 30 seconds to minutes [52].

• Jitter: With some load balance operations and conscious connections between pairs P2P

jitter is manageable which is under 50 ms.

• Zapping Time: When a new channel selected, a starting delay occurs in P2P systems.

According to studies in [50] switch to a popular channel takes 10 to 20 second, a less popular channel switching time may grow up to 2 minutes. This behaviour can be downfall of P2P IPTV systems .

• Error Resilience: To cope with the dynamic subscriber behavior P2P systems have some built in functions to support resilience [49].

• Scalability: Because in P2P networks peers supply their bandwidth into system, growth in network size is not a big issue. Actually any increase in the network is a good thing for P2P networks. However, Peer-Churn has some effects on the performance of P2P systems like, old routing tables, inconsistency in stored resources, and inconsistency in overlay topologies [51].

With pure P2P, IPTV can not be managed. Because there can be thousands of subscribers, to allocate each of them 5 Mbps bandwidth is impossible. There has to be some kind of multicast to solve bandwidth issue. In literature, there are solid multicast solutions using application layer. Basic two of them is Application Layer Multicast and Overlay Multicast. Now we analyse these proposals.

14

2.3.2.1 Application Layer Multicast

In IP multicast data transmissions, the source sends to a special destination IP address which indicates a certain receiver group of hosts. The routers are configured accordingly. The main gain is very efficient transmission to preserve bandwidth. However, IP Multicast has a big disadvantage about changing underlying network structure discussed in 2.3.1. One of the proposed solutions to overcome this drawback of IP multicast is Application Layer Multicast (ALM). In ALM the IP datagrams are replicated at the end users different from IP multicast where datagrams are replicated at the routers. The end users build an overlay network for data transmission. Because ALM replicates packets over same link (based on overlay topology), it is less efficient than pure IP multicast. In contrast ALM has no restriction in the sense of service availability and there is no necessity to change underlying network structure.

In Fig.2.4 the schema of ALM structure can be found. The datagram is replicated at end hosts.

Figure 2.4: ALM over end hosts.

ALM has some major advantages over IP Multicast which can be listed as:

severe grammar problems again

15

• The most important advantage is there is no need for alterations in the network layer in- frastructure or allocation of special IP addresses which is the drawback in IP multicast.

• ALM provides multicast services via IP unicast. Thus, it can use all services unicast presents, flow control, congestion control, reliability.

• ALM is scalable because it uses P2P streaming to deliver data. As mentioned in sec

2.3.2 in P2P networks, peers supply their bandwidth into system. Hence, growth in network size is not a big issue for ALM, too.

• ALM uses end users to replicate datagram. At first, it seems to be a disadvantage. How- ever, it uses unloaded links to send multicast data. For example in Fig 2.4, assume there is a transmission between sender and receiver 1. To achieve this transmission, normal unicast IP protocol uses the links between 2.Router - 3.Router and 3.Router - 1.Router. Assume that, there is not enough bandwidth to allocate on the link between 1.Router and 3.Router. So Receiver 1 does not get the datagram in the requested time resulting in not meeting the delay and jitter requirements of IPTV. If ALM is implemented, the sender can transmit the related information to Receiver-3 rather than forwarding the packets from Receiver-3 to Receiver-1, provided that the other links are not heavily loaded. So, uninterrupted video data can be seen in Receiver-1. Consequently, ALM can transmit data efficiently and it can balance network load. Moreover, because it uses all the advantages of IP unicast, it is very flexible and scalable.

The significant disadvantages of ALM compared to IP multicast can be listed as follows:

• There is control overhead and some extra traffic because end users control multicast.

Overlay nodes may have to replicate some identical packets on same link which in- cleases the load on the network.

• This increased load may lead to extra transmission delays and increased jitter.

2.3.2.2 Overlay Networks

An overlay network consists of a number of participating nodes which organize themselves to an overlay topology on the actual IP network. When overlay networks are used for IPTV

16

delivery, some special nodes are introduced to the system. These nodes called as multicast service nodes which can be interpreted as proxies to end user. These proxies take routing information from underlying network structure.

In today’s network conditions due to deployment and applicability problems of IP multicast, it is not considered to be the most feasible way to provide IPTV service. On the one hand, overlay networks do not change the underlying network structure. On the other hand, they require some kind of special nodes to realize hardware.

The mechanism can see on Fig 2.5 the overlay network above the actual IP network and the proxies are clearly indicated.

Figure 2.5: Overlay Network Structure.

Overlay networks bring many advantages in the sense of providing IPTV which are;

17

• Because it uses underlying network as unicast, deployment will not be a problem. How- ever some external proxies have to be deployed.

• Overlay multicast can reduce redundant data transfer compared to pure P2P technology.

• Unlike ALM it has all the route information, so it does not need to apply some probing algorithm to find out network conditions.

• It is less efficient than IP multicast in terms of utilization network conditions.

• The performance of the network is highly dependent on number of proxies and place- ment of proxies is crucial.

• Similar to ALM, it has control overheads.

2.3.3 IMS

IP Multimedia System (IMS) [30] is proposed to succeed IPTV to provision more flexible service, subscriber control and mobility management. It uses Signal Initiation Protocol (SIP) like VoIP. It is suggested that most of the IPTV demands can be achieved by using IMS’s intelligence, such as; user subscription, better QoS control, and session management [?].

IMS protocol can be defined more specifically as: "IMS is a global, access-independent and standard-based IP connectivity and service control architecture that enables various types of multimedia services to end-users using common Internet-based protocols." [6]. In other words, it is like a framework to deliver IP multimedia services. To achieve that instead of using standardized infrastructure, IMS stands on a horizontal control layer which isolates service from access network. IMS can be defined as a medium for Fixed Mobile Convergence (FMC) as it integrated services.

In Fig 2.6 the basic structure of IMS based IPTV solution can be seen.

IMS uses Session Initiation Protocol (SIP) for communication. SIP is a signalling protocol which enables to control multimedia services like, VoIP, video among other services. It is a TCP/IP based Application Layer protocol. It does not depend on transport layer.

To provide IPTV with IMS architecture the following requirements have to be satisfied in the network [7]:

18

Figure 2.6: IMS Structure [2]

• Interworking support has to be supplied. Subscribers have to reach other subscribers regardless of terminal properties.

• Roaming support

• Security controls should be done in IMS architecture. IMS takes security into account by including its own authentication and authorization mechanisms among other proce- dures

Alcatel-Lucent Bell Labs analysed the IMS-based IPTV. The results indicated that IMS-based resource control mechanism generates 50 percent more signalling messages compared with non-IMS based approaches. By control messages of services on demand it is a three to four increase in the control messages. By linear services (broadcast) this increase is seven to eight times. Network congestion probability with messages by customer Personal Video Recorder (PVR) activities is within IMS-based approach very high. PVR customer sessions will begin simultaneously during most watched period. Messages of control sources can be in IMS- based approach the reason of increased signalling load during most watched period of up to

66 percent [17].

2.4 Technologies for IPTV

To achieve IPTV services, there are some helper technologies. In this section, the related technologies, Probing and Video Compression are examined.

19

2.4.1 Probing

For IPTV architectures, available bandwidth in the network is one of the critical parameters. The effects of available bandwidth are discussed 2.2.1, in detail. For ALM applications, if the available bandwidth on the links is known, more intelligent routing mechanisms can be carried out in application layer. In order to find the available bandwidth some basic techniques are used, one of which is probing. Probing provides a means for end points to make inferences about the properties of a network path. One such property is available bandwidth.

The simplest and the most successful probing technique is active probing. In active probing, a few test packets are sent through the path and estimates network load by looking end to end delay. End to end estimation has received notable attention and in literature there are plenty of different active probing tools. Looking at the big picture, these systems infer the available bandwidth of a network path by sending a few packets and analysing the effects on the probe frames of intermediate nodes and cross-traffic. Examples of probing tools are Pathload[36], IGI/PTR [37], PathChirp [38], and ASSOLO [39]. These tools differ in the size and temporal structure of probe streams, and in the way the available bandwidth is derived from the received packets.

IGI/PTR [37] uses a sequence of about 60 irregularly spaced packets to probe the network and the gap between two consecutive packets is increased until the average output and initial gaps match. Pathload[36] uses constant bit-rate streams and alters sending rate in each lap. PathChirp[38] uses bit-rate stream packets which exponentially spaced. ASSOLO [39] is a tool based on the same principle with PathChirp, but it provides a different probing traffic and utilizes a filter to improve the accuracy and stability of results.

In IPTV case, there are plenty cases which have problems of network impairment, packet losses, significant jitter and delay. Moreover IP networks have no guarantee on QoS. The popularity of ALM and overlay networks began to rise in the context of IPTV [55], which generates an option that service providers can transmit data packets over several network paths to receiver [56]. Such kind of path variability gives one more adaptation option, dy- namically switch transmit path according to the observed-estimated network load conditions. This variability can be performed using the probing algorithms mentioned earlier typically using dummy probing packets.

20

2.4.2 Coding and compression

The most challenging part of IPTV is to meet the requirement for high bandwidth so, band- width reducing techniques become substantially important. Among this techniques, coding and compression technology is the most remarkable and effective one. The main purpose of it is to decrease the number of the bits that are required to transmit a video image. As a result of that, bandwidth is used more efficiently, and end users meet with desired service quality. Current coding and compression techniques will be discussed in this subsection.

An uncompressed video bandwidth requirement can be calculated. Suppose that, we have an HD video which has frame size of 1280*720 and frame rate of 24 fps. Assuming that the colour depth is 24 bits and no compression is used, the required bandwidth is 1,59 Gbps [29]. According to that conspicuous result, some compression is essential to transmit a video over a broadband network. Moving Picture Experts Group (MPEG)[31], International Telecom- munication Standard Sector (ITU-T)[32] , and Microsoft Media [33] are very commonly used compression technique for IPTV. The main advantage of this coding and compression technol- ogy is it reduced the required bandwidth for encoded content quite significantly. For example MPEG-2[34] encoded broadcast TV in standard definition has dropped the bandwidth around

2 Mbps, which is approximately 270 Mbps when no compression done, and MPEG-4[35] can provide similar quality at 1 Mbps. This coding and compression have not only resulted in lower bandwidth but also advanced functionality which is very important for IPTV service. Such as MPEG-4 includes media object function, where the part of a video content displayed simultaneously on the screen can be changed.

The following part is about Scalable Video Coding (SVC)/Layered Video Coding [58], which is one of the key parts of this thesis. More specifically, we used SVC to change transmitted data size in order to meet the requirements of IPTV. In H264/SVC standard there different layers of video data namely, spatial, quality, temporal and a new protocol called Interlayer prediction which improves the overall network efficiency. The basic idea is to split the content into two basic part, base layer and enhancement layers 2.7. The subscribers can decode the content according to their desires, terminal capabilities and received parts of the content.

The main gain from SVC is its adaptation to network conditions and heterogeneous peers very well. In IPTV concept, there are multiple resolutions of the same video is requested.

21

Figure 2.7: Principle of SVC .

Without the SVC, for each resolution there has to be different data packets, different routes, much more bandwidth demand. SVC makes the IPTV delivery is less complicated.

2.5 Summary of Literature Search

There are plenty of different solutions in literature to provide IPTV service among whole network elements, namely, NGN-based structures, IP Multicast solutions, P2P structures, IMS-based IPTV architectures. IP Multicast, NGN-based structures and IMS-based IPTV architectures have big advantages about fulfilling IPTV requirements. However, some alter- ations have to be done in underlying network infrastructure to achieve these solutions.

We observe that in P2P structures, there is no need to do any change in the core network. Hence, we decide to use P2P Streaming to fulfill IPTV requirements. In the scope of this thesis work we designed some control algorithms to alleviate the issues in P2P architectures that are discussed in Section 2.3.2.

A TABLE THAT YOU COMPARE PALMTV WITH OTHER OPTV ARCHITECTURES ACCORDING TO THE PERFORMANCE METRICS THAT YOU DEFINE

22

CHAPTER 3

PALMTV: P2P ALM (Application Layer Multicast) IPTV Architecture

IP Multicast and IMS are not easy to implement we need a more scientific way of saying it. Is it because of hardware requirements? scalability?Consequently, we decided to design and implement our IPTV architecture with P2P streaming. To handle IPTV requirements, an ALM structure is designed on top of P2P streaming. In addition to ALM, we incorporate probing for measuring delays and scalable video coding (SVC) in pur architecture. Furthermore, we propose an algorithm for the conrol of ALM. To this end, we name our architecture "P2P ALM IPTV Architecture" (PALMTV). Block diagram of PALMTV can be seen on Fig 3.1.

in fig 3.1 what are arrivals and departures? Peers? clearly indicate.

Our design consists of four main sub-blocks namely; clustering/error management, probing, video compression control and data transmission. Clustering Block is responsible for han- dling new arrivals and departures in the P2P system. Data Transmission Block is in charge of forwarding video streaming data. Clustering Block and Video Compression Blocks are work- ing together in order to stabilize the system quickly, in case of any error. Probing Block is used like a toolbox and serves other blocks when some estimation is required from underlying network. Through this chapter all of these blocks and their relationships will be analysed.

3.1 Clustering Block

This block is responsible for controlling arrivals and departures in the network. It divides the

ALM tree into clusters and assigns a leader to each group. do you define ALM tree somewhere

23

Figure 3.1: Block Diagram for PALMTV.

before? The clustering block admits new comers to a cluster according to the locations of the subscribers, which is estimated by probing.

Clustering Block has three main parts. The first part accepts new arrivals and locates the nearest clusters to corresponding arrival. Moreover, it deals with departures. The second part serves the error management block. If the error sensation mechanism detects an error, it may demand some rebuild in clusters. The third part consists of inter-cluster messaging which runs in the background. We designed one control algorithm for each part. In the next sections 3.1.1, 3.1.2, 3.1.3; control algorithms and their logic are explained. Moreover this block uses Probing Block whenever it demands some information from underlying network. In addition to this, it uses buffering technique for error correction purposes. The detailed schema of Clustering Block can be seen on Fig 3.2.

24

Figure 3.2: Clustering Block Main Structure

3.1.1 Handling Peer Arrivals and Departures

A P2P IPTV network is very dynamic. There can be multiples of arrivals and departures of peers in a short period of time. Moreover, multicast tree has to be controlled why? how?. We propose a Location/Heart Beat Algorithm to solve these problems.

When a new peer arrives, first the nearest cluster is found by Location Algorithm. The main reason behind is that; if video data comes as multicast through the edge network, then there will be a few replication of same data. For example, imagine opposite of this situation. As- sume that, two adjacent end users are fed by a distant cluster leader, than leader has to transmit same data to each of the subscribers. It will cause unnecessary replication of the same data and it reduces network utilization. In our solution, the nearest cluster will work like a IP multicast router. Each cluster only transmits one video channel.

When a new subscriber comes, at first it has to send an "Attend Request" message to a random cluster leader. After that, "Clustering Process" begins. This random cluster leader publishes this new arrival information to other leaders. Each leader finds its distance from the new comer by the help of probing. For distance comparison end-to-end delay is used. When probing is completed, results are shared and "Cluster Leader Election Protocol" is initiated. As a result of that protocol, the most appropriate cluster is selected for subscriber. If there are more than one cluster found by the election protocol then the assignment is done randomly. Pseudo code of Cluster Leader Election Algorithm can be seen on Alg 1. If a new comer is

25

accepted by a cluster than cluster leader updates the related subscriber-list information.

For each algorithm, clearly indicate the inputs. For ths algorithm the input is the probing result. Is Estimated Distance (Probing) the same thing as ProbingResult

Algorithm 1 Pseudo-code for Cluster Leader Election Algorithm

1: CurrentDistance = In f inite

2: for All Cluster Leaders do

3: if LeaderHasRequestedChannelInfo() then

4: if CurrentDistance <Estimated Distance (Probing) then

5: CurrentDistance =ProbingResult

6: T agCurrentLeaderT em porarily

7: end if

8: end if

9: end for

In steady state all subscribers receive their demanded video data, provided by clusters. If there is a demand for switching channels, the subscriber has to leave one cluster and join another one. Moreover, clusters should not send any information to the peers that left. To this end, a Heart Beat mechanism is created.

Heart Beat mechanism uses the basic ping idea. During the subscription period, all the sub- scribers send "Still Alive" message to cluster leader. If the "Still Alive" message is not re- ceived by cluster leader in a certain period of time, the subscriber is deleted from the list of what. This message does three jobs at once. First, it makes sure that the related subscriber still wants the video data. Second, it carries a time stamp. It controls whether it takes to long to deliver the packets. In addition to time stamp information, it carries the last delivered video packet ID. This last feature is very useful for error correction and retransmission cases. When a Heart-Beat message is received by a cluster leader than it sends Heart-Beat message back to the subscriber with time stamp.

If there is a channel switch demand than with the help of "Cluster Leader Election Protocol", new cluster leader is chosen. After that the same procedure is executed. To leave a cluster there is no special protocol. Heart-Beat algorithm takes care of it.

26

3.1.2 Error Management - Cluster Rebuild

In a P2P video transmission network, errors may happen. In this section we analyse the cluster errors. We call this error type subscriber sensed errors. If a subscriber node does not get any answer from Heart-Beat message after a certain period of time,I did not undertsand this if part at allit concludes that there may be some error in the links or in related cluster leader. To solve this, subscriber sends another "Attend Request" in order to receive data and the election process repeated. After that, if there is another cluster leader with the same channel information with minimum distance, that cluster leader is selected. To get the video data subscriber node just sends last "Still Alive" message to the new leader.

However, there is another issue here. Because subscriber node had not got the video data during the new cluster election, there was a time difference between broadcast video and subscriber sensed video. To overcome it, we introduce buffering in cluster nodes. Buffering is very important to watch a whole video, it helps to handle variations in delay (jitter). Cluster nodes have the responsibility of buffering their channel for at least 10 minutes. Buffering may take place in sender, but that means if there is a retransmission or some error, this wish has to be sent all all what the to sender. So cluster nodes keep buffered video data not to create any extra traffic. The re-election algorithm has two parts subscriber side and cluster leaders side. Pseudo code can be seen on Alg 2 with subscriber perspective. Besides, on Alg 3 the re-election algorithm can be seen from the cluster leaders view.

Algorithm 2 Pseudo-code for Re-Election - Subscriber View

1: T hresholdT ime = V ariable

2: if LastS tillAliveMessageInterval >ThresholdTime then

3: Error Occured

4: Execute Alg − 1ClusterLeaderElectionAlgorithm

5: Send LastStillAliveMessage

6: end if

27

Algorithm 3 Pseudo-code for Error Correction In New Cluster Leader

1: Get StillAliveMessage

2: if RelatedDataIsBuffered() then

3: Start SendingBufferedData

4: else

5: Start NormalBroadcast

6: end if

it is worth to mention that according to our experiments if more than one cluster is constituted for one channel, it is beneficial for error cases as we discuss in the next chapter.

3.1.3 Inter Cluster Messaging

There is a messaging system between cluster leaders to deal with errors and cluster election process. In this system, cluster leaders exchange their subscriber lists and probing results for the execution of "Cluster Election Protocol". Moreover, when there is an error, leaders must communicate among themselves. This messaging system is achieved by a mesh-based interconnection which is explained in next section 3.2 .

3.2 Data Transmission Block

In order to forward the video data and send inter cluster messages efficiently, we investigated ALM node connection algorithms. In literature, there are two basic mechanisms for these purposes; mesh-first and tree-first approach.

3.2.1 Mesh-First Signalling

In mesh-first applications, a mesh topology is created among the cluster members. In general, the sender is chosen as the root. After that, a routing algorithm is executed to build the routing tree. At beginning, mesh topology created, so the topology is known. However, resulting tree topology is unknown. So the quality of the tree depends on the quality of the mesh chosen.

The advantage of the mesh-first becomes apparent here as it gives more freedom to refine the

28

tree. It is possible to manipulate the tree topology to a significant extent by selecting mesh neighbours and changing the metrics. A mesh-first approach is therefore more robust and responsive to tree partitions and is more suitable for multi-source applications, at the cost of higher control overhead.

3.2.2 Tree-First Signalling

By contrast, in the tree-first approach, the tree is built directly without any mesh. The mem- bers explicitly select their parent from the known members in the tree. This may require running an algorithm to detect and avoid loops, and to ensure that the structure is indeed a tree. There is no intervening mesh topology here. The reason for using the tree-first approach over the mesh-first approach is that the tree-first approach gives direct control over the tree. This control is valuable for different aspects such as maintaining strict control over the fan- out, selecting a best parent neighbour that has enough resources, or responding to the failed members with a minimum impact to the tree. Another advantage of the tree first approach is independent actions from each member. It makes the protocol simple as it has a lower communication overhead. But when a member changes a parent, it drags all of its descen- dants with it. This is desirable in the sense that the descendants do not need to change their neighbours; in fact, they are indeed unaware of the incident.

3.2.3 Demand From ALM Messaging Algorithm

We examined some ALM algorithms from the perspective of inter connections. These al- gorithms are tree-first algorithms, ALMI [11], OMNI [12]; and mesh-first algorithms, NICE [13], NARADA[10]. First we listed our expectations from an ALM inter communication al- gorithm and we investigated whether these ALM algorithms fulfill our requirements or not in the sense of inter messaging.

• Low Latency: Our first desire is to select a messaging algorithm which has the min- imum delay. Experiments show that average streaming delay (network delay + node delay) changes with used mesh/tree structures [4]. Among four algorithms, ALMI has minimum delay because of its tree structure. However, it is worth to mention that if the number of nodes increase than tree-based protocols’ delay will increase. NARADA

29

has the smallest delay when the network size is not big, if network size is growing than its performance will not be definite [3]. Fig 3.3 shows delay variations with respect to

network size.

Figure 3.3: Average Delay from Source to End Node [3]

• Low Bandwidth Usage: Bandwidth utilization is another critical factor when doing multicast. Mesh topologies have some advantages when network size tend to grow. On the other hand, tree topologies have some drawbacks, if errors occur. Bandwidth usage of selected algorithms can be seen in Fig 3.4.

• Low Relative Delay Penalty: Relative Delay Penalty (RDP) means that the ratio of the delay from centre to other nodes in the topology with unicast delay [3]. It can be said that if RDP value is less than a certain threshold value, our algorithm becomes efficient [3]. According to our research with the increase in the number of the nodes, ALMI and NARADA have larger RDP values. OMNI has larger RDP values, too. However, NICE has the best resulting RDP for the large networks. Behaviour of the algorithms in the sense of RDP can be seen on Fig 3.5.

30

Figure 3.4: Average Bandwidth Usage [3]

According to our investigation although mesh-based protocols have larger delay variations (jitter), their higher scalability is a very big advantage for our case. So, we decided to choose and implement mesh-based messaging structure.

3.3 Video Compression Block

what are your assumptions for the hardware capability of the nodes related to the video cod- ingThis block is responsible for determining which video layer will be downloaded by the subscriber. It is a very critical issue when traffic overloaded or there is an error in trans- mission process. We assume that all the base and enhancement video layers are distributed among cluster nodes. Itwho?mainly uses probing results to decide whether there is a necessity to change layer what the user sees.

First, it is discussed that all cluster leaders gets for the "Still Alive" messages from their subscribers. They are not only get these messages for departure, but also they uses it to

31

Figure 3.5: Average RDP values [3]

calculate time intervals. Cluster leaders watch message arrival interval trends and tag the interval as growth or decay. If there is an increase in delay results, leader compares this delay with a threshold value which is set before. If it is above the threshold value it starts the "Layer Switch Algorithm". This algorithm has two main steps. First, it sends a message to other cluster leaders if there is any other cluster with the same channel information and delay is under than a threshold value set before. If there is such a leader than subscriber is registered to new leader. If there is not such a cluster, then we change channel quality in order to avoid any service loss. Our algorithm’s pseudo code can be seen on Alg 4.

32

Algorithm 4 Pseudo-code for Video Compression Control

1: Set ThresholdTime = MaxEndToEndDelay

2: if S tillAliveMessageInterval ¿ T hresholdT ime than then

3: for All Clusters do

4: if LeaderHasRequestedChannelInfo() then

5: if ProbingResult ¡ ThresholdValue then

6: RegisterNodeintoCurrentCluster

7: end if

8: end if

9: end for

10: if ThereIsNotSuchACluster then

11: Change Distributed Layer (Enhancement/Base)

12: end if

13: end if

3.4 Probing Block

The main purpose of this block is to provide the bandwidth estimation to other blocks, whenever its necessary. To select a probing algorithm, the existing algorithms have been researched. Their advantages and disadvantages are investigated in the context of IPTV.

Basically, our expectations from a probing algorithm are high estimation accuracy, low band- width overhead, and low response time. Let’s examine these requirements further.

• High Estimation Accuracy :

High estimation accuracy is very important for our design because all the other blocks use the output of this block. If the estimations have high errors, then we can not iden- tify correctly the low loaded and the high loaded links in the network. As a result of that, error sensation fails, cluster election protocol fails, as well. So, high estimation accuracy is crucial for PALMTV.

• Low Bandwidth Overhead :

Because cluster handling, data transmission and error sensation have high loads already,

33

we do not want some other cause to create extra traffic in the network. So, to not com- plicate the overall structure, selected probing algorithm has to have small bandwidth overhead.

• Low Convergence/Response time :

Because our design implements a real time application, reaction times are very im- portant. To get instantaneous results from this block, our probing algorithm needs to have low convergence time. However, if the bandwidth overhead is small, we can run probing algorithm in background all the time. So, low convergence time may not be indispensable.

In the literature there are plenty of different probing algorithms. Each of these has standing out capabilities in terms of bandwidth utilization, high estimation accuracy and low convergence time. Our main goal is to select the one which satisfies our demands best.

We investigated the performances of Spruce [48], IGI [37] and Pathload [36] algorithms.

From the perspective of estimation accuracy, researches show that Pathload has the most accurate estimation results among them. It has less than 20 percent error rate in any scenario [46] . However, sometimes it overestimates the network load and calculates for the worst case. Both Spruce and IGI have some accuracy issues. Their error rates are far above than Pathload [46]. Moreover, their predictions are 30 percent wrong in most cases. They present some problem while predicting in highly loaded system, they underestimates network load. Figure 3.6 shows estimation results of the algorithms.

Figure 3.6: Estimation Accuracies [46]

From the aspect of bandwidth overhead, Pathload has respectively small overhead [46]. Its

34

overhead never exceeds 10 percent in tight links. When we look at Spruce’s performance, spruce has the smallest estimation overhead [46]. It utilizes bandwidth usage, too. On the other hand, IGI’s overhead can grow up to 30 percent and it can be very problematic in our case. Their load overheads can be seen on Fig 3.7.

Figure 3.7: Estimation Overheads [46]

Lastly, their convergence time is varied by link capacities and traffic loads. IGI has the small- est convergence time, it almost never exceeds 10 seconds. Spruce has relatively high conver- gence time around 10 seconds constantly [46]. On the other hand, Pathload has to have much time to converge [46]. This is not surprising because it uses lower bandwidth and it brings more accurate results than others, it has to do more iterations to get it. Their convergence time comparisons can be seen on Fig 3.8.

Figure 3.8: Convergence Times [46]

According to our investigation, despite of its large convergence time; Pathload’s estimation accuracy and low bandwidth overhead assure that Pathload can handle our requirements. We decided to eliminate Spruce and IGI due to their low accuracy,high bandwidth overhead. So, based on all of these we decided to pick Pathload.

35

Pathload uses Self-Loading Periodic Streams (SLoPS) to estimate bandwidth [47]. Its main principle is to transmit a periodic stream with one way delay. When probing traffic is larger than available traffic, then it increases the delay of periodic data streams. A fixed number of packets are sent and one way delay of each stream are classified as growth or decay in at receiver. Pathload sends these streams by UDP, while receiver sends trend results back to the sender. If stream rate is R, then Pathload picks an inter-departure time T. After that, it calculates the necessary packet size to make sure R = L/T.

3.5 Novel Features of PALMTV

Our contribution and novel features can be listed as below:

• ALM communication algorithm, probing, and SVC ideas are combined in order to get more effective results.

• New cluster handling algorithm upon the ALM mesh-based inter connection protocol is designed.

• A new video layer control algorithm is designed.

36

CHAPTER 4

Performance Evaluation of PALMTV

4.1 Simulation Environment

To test our algorithm, we used ns-2.29 [45] to conduct experiments. For Probing Block 3.4 and Data Transmission Block 3.2.3, open source codes are used. For Cluster Block 3.1 and Video Control Block 3.3, we implemented our algorithms in ns-2.29.

4.2 Traffic Models

We used Georgia Tech Internetwork Topology Model (GT-ITM) [44] for topology generation, our simulations can cover up to 10000 node-networks. (GT-ITM) is a C program which allows defining transit-stub model topologies. The variables which variablesare read from the configuration file, then output topology graph is generated. For more information about the configuration file format and mechanism, please check appendix A.1. Our sample topologies can be seen in Appendix A.2

We modelled arrival-departure rate as a Poisson distribution with the rate of 100 nodes joining per second. Moreover, the subscribe duration is modelled with exponential distribution with

0.01 parameterunit?.

4.3 Assumptions

Our basic assumptions are:

37

• We used for arrival-departure rate of 1 arrival/100 msec and 1 departure/100 msec. In subsection 4.5.7, we increase this rate in order to stress the underlying structure.

• In section 3.1.2, it is explained that buffering is very important to provide non-stop service. We assume that, these buffers have infinite capacities. Otherwise, managing memory consumption issues may be very problematic.

4.4 Performance Metrics

We evaluated PALMTV with the following aspects, in order to compare its performance with other IPTV services in the literature.relate this to your performance metrics in the related work section

• Packet Loss : We counted the packet losses, in high/low traffic conditions.

• Error Resilience : We created basic error cases to appraise this property. We observed

PALMTV’s performance under different stress conditions.

• Channel Switching Time : Subscriber sensed zapping times were calculated.

• Delay/Jitter : Delay variability (jitter) and end to end delays were measured.

• Delay / Protocol Overheads : We measured our algorithm blocks’ bandwidth overheads to see their actual benefit.

• Scalability : We measured end to end delay under high arrival/departure rates to look from the scalability point of the view.

4.5 Scenarios and Experiment Results

you have to investigate how video compression helped you. This is one of the new things you do in this thesis. How did SVC improve your metrics?

We executed plenty of scenarios with different topologies and different network sizes. More- over, we created some error cases which include cluster leader errors, broken links.

38

4.5.1 Protocol Overheads

First of all, we analysed our protocols’ bandwidth usage to see whether our protocols serve the purpose or not. For all your graphs where you compare your results to some other algorithm such as NICE provide the results of that algorithm. If possible plot on the same graph. If not, then extract values from both (yours and NICE) and put them in a table

for all your plots you need to comment on the graph. you need to explain WHY you have a curve like this rather than verbally repeating what the curve looks like

4.5.1.1 Probing Overheads

We calculated Pathload’s performance in the sense of bandwidth overhead. Because Pathload use SLoPS and bandwidth stabilization as discussed in 3.4, we evaluated its performance with the ratio of available bandwidth. Our experimental results can be seen on Fig 4.1. Although ratios a little bit higher how highthan expected, the results are consistent with literature.

Figure 4.1: Probing Overhead

I did not undertsand fig 4.1. How can you have a link capacity of 0.18Kbps on y axis?? What is x axis? Same comments are valid for all graphs with the same axis

39

4.5.1.2 Cluster Messaging Overheads

In the beginning phase, bandwidth usage increases very fast due to mesh and tree learning state discussed in section 3.2.1. After that its performance is stable and is shown in Fig

4.2. When we compare this result with NICE and our ALM algorithms performance about

bandwidth usage, it is a little better than other algorithms.

Figure 4.2: Cluster Inter Messaging Overhead

4.5.1.3 Total Protocol Overhead

Finally, we combined probing and mesh-based messaging overheads to see the overall results. Overall bandwidth usage is stable and consistent with the literature search in Fig 4.3. If we compare these findin