Initial phases of indoleacetic acid induced growth in coleoptile segments of Avena sativa L.

IEEE TRANSACTIONS ON FUZZY SYSTEMS, VOL. 17, NO. 5, OCTOBER 2009

1123

Interval Type-2 Fuzzy Logic Congestion Control for Video Streaming Across IP Networks Emmanuel A. Jammeh, Martin Fleury, Member, IEEE, Christian Wagner, Member, IEEE, Hani Hagras, Senior Member, IEEE, and Mohammed Ghanbari, Fellow, IEEE

Abstract—Intelligent congestion control is vital for encoded video streaming of a clip or film, as network traffic volatility and the associated uncertainties require constant adjustment of the bit rate. Existing solutions, including the standard Transmission Control Protocol (TCP) friendly rate control equation-based congestion controller, are prone to fluctuations in their sending rate and may respond only when packet loss has already occurred. This is a major problem, because both fluctuations and packet loss affect the end-user’s perception of the delivered video. A type-1 (T1) fuzzy logic congestion controller (FLC) can operate at video display rates and can reduce packet loss and rate fluctuations, despite uncertainties in measurements of delay arising from congestion and network traffic volatility. However, a T1 FLC employing precise T1 fuzzy sets cannot fully cope with the uncertainties associated with such dynamic network environments. A type-2 FLC using type2 fuzzy sets can handle such uncertainties to produce improved performance. This paper proposes an interval type-2 FLC that achieves a superior delivered video quality compared with existing traditional controllers and a T1 FLC. To show the response in different network scenarios, tests demonstrate the response both in the presence of typical Internet cross-traffic as well as when other video streams occupy a bottleneck on an All-internet protocol (IP) network. As All-IP networks are intended for multimedia traffic, it is important to develop a form of congestion control that can transfer to them from the mixed traffic environment of the Internet. It was found that the proposed type-2 FLC, although it is specifically designed for Internet conditions, can also successfully react to the network conditions of an All-IP network. When the control inputs were subject to noise, the type-2 FLC resulted in an order of magnitude performance improvement in comparison with the T1 FLC. The type-2 FLC also showed reduced packet loss when compared with the other controllers, again resulting in superior delivered video quality. When judged by established criteria, such as TCP-friendliness and delayed feedback, fuzzy logic congestion control offers a flexible solution to network bottlenecks. These findings offer the type-2 FLC as a way forward for congestion control of video streaming across packet-switched IP networks. Index Terms—All-internet protocol (IP) network, congestion control, interval type-2 (IT2) fuzzy logic control, video streaming.

Manuscript received November 5, 2008; revised February 10, 2009; accepted April 30, 2009. First published May 19, 2009; current version published October 8, 2009. This work was supported in part by the U.K. Engineering and Physical Sciences Research Council under Grant EP/C538692/1. E. A. Jammeh is with the School of Computing, Communications and Electronics, University of Plymouth, Plymouth PL4 8AA, U.K. (e-mail: emmanuel. [email protected]). M. Fleury, C. Wagner, H. Hagras, and M. Ghanbari are with the School of Computer Science and Electronic Engineering, University of Essex, Colchester CO4 3SQ, U.K. (e-mail: [email protected]; [email protected]; [email protected]; [email protected]). Color versions of one or more of the figures in this paper are available online at http://ieeexplore.ieee.org. Digital Object Identifier 10.1109/TFUZZ.2009.2023325

I. INTRODUCTION EAL-TIME video applications, such as internet protocol (IP) networked TV (IPTV), video-on-demand (VoD), and the network-based video recorder, interest telecommunication companies, because of their high bit rates, although they also risk overwhelming existing networks if it is not possible to control their flows. In video streaming, the compressed video bit stream is transmitted across a network to the end-user’s decoder (prior to display) without the need for storage other than temporary buffering. The unicast variety of IPTV is very attractive because it allows streaming of individual TV programs at a time chosen by the end user. Broadly speaking, two types of heterogeneous delivery networks exist: 1) the familiar Internet, with best-effort IP routing, i.e., an unmanaged IP network and 2) All-IP networks, which retain IP packet framing, but, particularly, in the network core, switch packets (across Clos switches) rather than employing packet routers, i.e., a managed IP network. On the Internet, video streams must coexist with other data traffic, while in emerging All-IP networks, multimedia traffic may predominate. In an All-IP network, as on the Internet, a capacity restriction may still exist at the connection between the network core and the access network, the technology of which can be cable [1], broadband wireless [2], or connections to the video serving office [3] from which video is typically distributed over asymmetric digital subscriber line (ADSL) connections. Also note that Internet traffic may be directed through an All-IP network by means of the common agency of IP framing. On the Internet, a tight link (or more loosely a bottleneck), which commonly exists at the network edge before a corporate or campus network [4], is the link of minimum available bandwidth on a network path. Strictly, the term “bottleneck” defines the bandwidth capacity of a network path, which, as long as the path exists, is a constant, though the term may also be loosely applied to a tight link. A tight link is a dynamic concept, as its location will vary first over time according to background traffic patterns and second according to the network path’s route, which is not fixed because of dynamic routing on the Internet. These two factors can create uncertainty in any video streaming response. Available bandwidth is restricted by coexisting crosstraffic, which is most likely carried by the Transmission Control Protocol (TCP) and, predominantly, originates from Web servers or peer-to-peer file transfer [5]. Transport-layer protocols like TCP, sitting above IP, are responsible for end-to-end negotiation of delivery between applications. On All-IP networks, coexisting traffic across a network subchannel or pipe is more likely to arise from other proprietary video servers and to be carried

R

1063-6706/$26.00 © 2009 IEEE

1124

by the minimal User Datagram Protocol (UDP), as directed by congestion controllers. A pipe is a virtual bandwidth restriction imposed by quality-of-service requirements that must balance the requirements of other types of traffic and the capacity of the access network. As on the Internet, All-IP congestion controllers should be end-to-end over the network path, thus allowing a general solution in the sense that the nature of the access network bottleneck may not be known in advance. In an All-IP network, statistical multiplexing of variable bit rate (VBR) video sources within a video pipe may increase its efficiency, but there is no spare capacity for greedy acquisition of bandwidth by independently controlled video servers. Congestion control is vital to avoid undue packet loss from the fragile compressed video stream. At the subframe level, because variable-length coding (VLC) prior to outputting the bit stream introduces a dependency between each encoded symbol, there is fragility that error resilience techniques such as decoder synchronization markers and reversible VLC only partially address. Because successive video frames are broadly similar (except at scene cuts and changes of camera shots), only the difference between successive frames is encoded in order to increase coding efficiency. Consequently, at the frame level, removing temporal redundancy introduces a dependency on previously transmitted data that implies lost packets from reference frames will have an impact on future frames. Although congestion control is vital, there are various sources of uncertainties facing the congestion controller, some of which are listed as follows. r The measurements employed to estimate the amount of congestion are not accurate as they are based on partial information from a small set of packets. r If packet-delay-based estimation is used, the resolution of time measurements may be limited, and clock synchronization at the endpoints of the network path may well be periodic, thus resulting in clock drift between synchronization times. r In time-varying paths, path measurement systems, which rely on feedback of measurements, will produce results lagging the variation in traffic conditions creating uncertainty. r The available bandwidth is restricted by coexisting crosstraffic arising from short- and long-term flows that share the tight link. The extent of these competing flows is difficult to predict in advance in any precise way. r Mathematical modeling is difficult to accomplish, especially in real time, resulting in uncertainty. Mathematical modeling is normally most robust within a linear system. However, in the fixed Internet (where the TCP protocol remains dominant), TCP control is essentially nonlinear, with its two-phase start-up, dynamic sliding window, congestion avoidance, and so on, which suggests that observed “bursty” or even fractal traffic patterns are due to the congestion control algorithms themselves. r Certainly, Web-server-sourced cross-traffic is marked by the occasional presence of large files, which are subsequently broken up into packets forming packet bursts. Statistically, file size is long-tailed, which is commonly mod-


eled by a Pareto probability distribution. Video sources may also be “bursty” due to the propensity of encoding software to release packets at process rescheduling points. Aggregated flows can also create packet bursts. These bursts create uncertainty in the background traffic, even over intervals shorter than the duration of a video frame. r As mentioned previously, the tight link or bottleneck is a dynamic concept as its location will vary over time according to background traffic patterns and the network path’s route, wherein both factors create uncertainty in the streaming response. r The very heterogeneity of the underlying networks, due to the evolving nature of telecommunication networks, especially wireless networks, creates uncertainty in the network behavior. As the Internet is overlaid across a variety of underlying networks, a form of congestion control is required that is resilient to differences in the response of any type of network through which a video stream may be routed. Existing congestion controllers are specialized to the Internet (hence, the term “TCPfriendly”) and have not generally been tested for All-IP networks. In addition to the uncertainties mentioned before, there is also a short-term variation in the video input rate due to the pattern of purely spatially encoded frames and those employing some form of temporal prediction. This creates problems in buffering (either under- or overflow) the video unless some means of regulating the flow are available. The video’s encoded bit stream, if encoded at a VBR to preserve its quality [rather than at a constant bit rate (CBR)], changes its statistical characteristics over time, because of varying scene complexity and because of the motion of objects both within the scene and relative to the camera. Existing congestion controllers (such as TCP-friendly rate control (TFRC) [6], TCP emulation at receivers (TEAR) [7], the loss-delay-based adjustment algorithm (LDA+) [8], and quality-oriented adaption scheme (QOAS) [9]) are analytically based systems and in the case of TFRC are precisely formulated by a complex equation specifying the sending rate. Hence, the congestion controller can react to congestion by varying the sending rate. Traffic volatility (due to its observed “bursty” or fractal nature) requires constant adjustment of the sending rate so that TFRC responds to every packet round-trip time (RTT). The equation governing TFRC is parameterized by mean RTT and packet loss rate, with, as for TCP, the latter being more prominent. Most existing congestion controllers are TCP emulators [10] in the sense that their long-term sending rate aims to be that of an equivalent TCP stream. This is because TCP employs a cooperative form of congestion control that historically may have prevented congestion collapse in the public Internet [11]. Direct adoption of TCP’s congestion control is not recommended, as it results in a “sawtooth” sending pattern, which can produce a subjectively disconcerting variation in video quality. Consequently, the TCP emulators tend to be less aggressive but slower in their response to congestion. TCP also accepts unbounded delay as it offers a completely reliable form of data delivery, whereas video streams must meet frame display

JAMMEH et al.: INTERVAL TYPE-2 FUZZY LOGIC CONGESTION CONTROL FOR VIDEO STREAMING ACROSS IP NETWORKS

deadlines without the need to guarantee completely consistent data delivery. In a congested network, a key problem for video is the delicate nature of the compressed stream (as mentioned earlier in this section), which means that the loss of particular packets and, more generally, particular pictures or frames has a knockon effect at the decoder. A group of pictures (GOPs) commonly consists of 12 or 15 pictures with the first intracoded picture forming a decoding anchor for the others in the GOP. Intracoded pictures1 are those that are coded without reference to other pictures, except to themselves, usually by blockwise backward reference. They are introduced to prevent temporal error propagation and to act as a resynchronization point in the event of packet loss. Consequently, loss of packets from an intracoded or spatially coded packet is especially harmful, although predictively coded pictures (ones employing motion compensation to reduce temporal redundancy) that also act as reference pictures should also be protected. As frames are normally displayed at a constant frame rate of 25 or 30 frames/sec, video streaming is a delay-intolerant application, implying that it is better to deliver a lower quality video clip or film than to resend packets. A measurement of available bandwidth is generally performed because of the unpredictable nature of cross-traffic. This is accomplished by observing in real time the packet arrival statistics of the video stream packets. Available bandwidth volatility means that an analytically based congestion controller, especially one that relies on packet loss feedback, may be unsuitable for efficient video stream congestion control. However, when considering the industry standard TFRC [6], this has the advantage that at least, in principle, its basis is a mathematical formula, thus giving confidence in the ability to understand its response in different network conditions. Unfortunately, its equation, which was derived under simplified circumstances, is specialized for the New Reno variant of TCP, whereas other variants have since emerged, some of which, including TCP Selective Acknowledgment (SACK) or the newer binary increase congestion control (BIC) TCP, behave more aggressively.2 TFRC’s TCP friendliness has even been challenged [12]. Therefore, arriving at a precise mathematical formulation is difficult. This paper presents a novel and alternative approach for congestion control based on fuzzy logic. In general, fuzzy logic control is a methodology for the design of robust systems that can contend with the uncertainty, measurement noise, and imprecision attributable to real-world settings. In addition, fuzzy logic provides a way of constructing controller algorithms by means of linguistic labels and linguistically interpretable rules in a user-friendly way closer to human thinking and perception. Moreover, the fuzzy logic controller in this paper has the advantage over congestion controllers, which are essentially TCP 1 The terms “picture” and “frame” are interchangeable for progressively scanned video (as herein) as there is a one-to-one correspondence between them, whereas a “picture” is constructed from the two fields of a frame in interlaced broadcast TV. 2 TCP-SACK outputs more than one packet when multiple packets are lost, while TCP New Reno is confined to one per RTT. BIC-TCP, which was installed on all Linux kernels, increases its congestion window independently of RTT, which can result in unfairness to other TCP flows when there is a short RTT.

1125

emulators, as it can employ packet delay without the need for packet loss as a feedback. This allows queue buildup at intermediate buffers to be anticipated, hopefully before packet loss occurs. The paper will show that a fuzzy logic congestion controller (FLC) is not only suitable for Internet video streaming (it is TCP-friendly) but readily applicable to All-IP networks as well. In fact, the paper will present the benefits of FLCs that are based not only on type-1 (T1) but on type-2 fuzzy logic [13]. A T1 FLC cannot fully handle the uncertainties associated with video streaming across IP networks, as the boundaries of its membership functions (MFs) are fixed. This implies that there may be unforeseen traffic scenarios for which the existing crisp T1 MFs do not suffice to model the uncertainties in the congestion control task at hand. Employing an interval type-2 (IT2) FLC significantly improves robustness to measurement noise and background traffic volatility compared with a classical T1 FLC. With an IT2 FLC solution, it is possible to build in a response to unforeseen network conditions, because the uncertainty in the boundaries of its MFs provide the scope for an additional flexibility in the controller’s response compared with the crisp boundaries of the MFs of T1 controllers. The IT2 FLC in this paper was designed with background traffic in mind, but also applied to an All-IP network with video-only background traffic. Thus, to the authors’ knowledge, this is the first paper that applies IT2 fuzzy logic control to video streaming across IP networks. We hope that this paper will provide a way forward to a more robust and efficient form of video streaming, which is badly needed as the demand grows for better and more unicast video services. The remainder of this paper is constructed as follows. Section II presents some background information. Section III provides a brief overview of T2 fuzzy logic control. Section IV provides details of the FLC system in its application to Internet and All-IP networks. Section V evaluates T1 and IT2 FLCs in both types of networks and in comparison with traditional controllers. Finally, Section VI draws conclusions. II. BACKGROUND Most networks will not support the transport of very high bit rates of raw video, and consequently, video streams are compressed as a bit stream, which is subsequently packetized. A bit-rate transcoder [14] takes the arriving compressed bit stream and transforms it to a different bit rate. In congestion control, this rate is usually lower to accommodate the rate restrictions of a bottleneck link. The bit rate may be adapted either by changing the compression quantization parameter at a live-video encoder or at an intermediate bit-rate transcoder after partial decoding. However, nonspecialized controllers will alter a sending parameter, such as increasing the interpacket gap, to reduce the sending rate, which is the solution of the industry standard TFRC. This has the implication that large buffers with large passive power consumption should be available at the end-user device prior to decoding to absorb fluctuations in delay. It is also possible to take the suggested rate of TFRC or another traditional encoder and use that rate to drive a transcoder or select from a set of

1126

different rates (22 rates in [15]) for the same video (simulcast). Although the end-user’s buffer size is significant, it is at intermediate buffers that the effect of congestion is felt because it is there that packets are enqueued waiting for links to become free after packets from other traffic sources have been cleared. In heavy congestion regimes, a buffer immediately preceding a tight link or the access network will fill up and begin to drop packets. For TFRC and others, this is the initial spur to cut back the sending rate, which has an important implication, as congestion can be addressed only when packets are dropped. In our application, an FLC is used as a sender-based system for unicast video streams. The receiver returns a feedback message indicating changes to the delay experienced by video stream packets crossing the Internet. This allows the sender to compute the network congestion level, and from this, the FLC estimates the response. A fuzzy logic controller, including an IT2 fuzzy logic controller [16], can be efficiently implemented directly in hardware. The need for a hardware congestion controller implies that, once developed, the FLC models should have wide applicability whatever the traffic conditions at a bottleneck or tight link. The same controller should also be able to cope with a range of Internet path delays and with video streams with differing characteristics in terms of scene complexity, motion, and scene cuts. The use of T1 fuzzy logic for video applications has gained ground [17], [18]. However, a T1 FLC might need its MFs to be frequently tuned to handle the uncertainties associated with the network. The findings of this paper suggest that an IT2 FLC can provide much better performance in face of the uncertain conditions in IP networks. As was found in other applications [19], the IT2 FLC brings confidence that retuning will not be frequently needed when the arriving traffic displays uncertain or unanticipated behavior. This paper extends our previous work on T1 FLC for video streaming [17], [20] to an IT2 FLC and compares the performance in the presence of measurement noise, which is injected to test the relative robustness. Encouragingly, the delivered video quality is better than traditional controllers and equivalent to the successful T1 FLC when the measurement noise is limited. However, the IT2 FLC outperforms the T1 FLC and traditional controllers when the uncertainty levels increase. The next section introduces related work in the applications of fuzzy logic in telecommunications and video communication; the following section will present the concepts of measuring delay and delay-based congestion control. A. Fuzzy Logic for Congestion Control and Video Communication In surveys investigating the applications of computational intelligence to congestion control, it was noted that not much work has been reported on deploying computational intelligence algorithms to congestion control within the Internet [21], [22]. Asynchronous transfer mode (ATM) networks, which employ access control to virtual circuits, are one domain to which fuzzy logic has been more extensively applied [22], [23]. In fact, a T2 fuzzy logic controller used for this purpose is reported in [24], although it should be noted that there is a strong trend among


manufacturers to replace ATM networks with Ethernet and IP framing. Because of Bluetooth’s (IEEE 802.15.1) centralized scheduling, which resembles ATM admission control, fuzzy logic video bit-rate control was applied in a similar manner to a Bluetooth wireless link [25]. For the same reason, in a number of papers, the authors of [26] have explored fuzzy logic to improve the performance of the random early discard (RED) router queue algorithm, and [27] improves the performance of DiffServ buffer occupancy for each class of layered video packets. Within the field of video encoding, fuzzy logic has found an application [28], [29] in maintaining a constant video rate by varying the encoder quantization parameter according to the output buffer state, which is also a complex control problem without an analytical solution. T2 fuzzy logic was used in [30] to determine the size of different video-frame-type sizes and classify the video genre. The intention was to allow modeling of VBR video traffic without the need for video sources. T2 classification and modeling were found to be superior to using T1 fuzzy logic [30]. Wireless networks represent a promising application of fuzzy logic [31], as not only are their uncertainties inherent in network traffic, but the wireless channel is also noisier and takes a wider variety of forms than a wired link. Additionally, the need to conserve battery power brings into play another resource to balance in the fuzzy logic model. T2 fuzzy logic in [32] was indeed applied to model the lifetime of a wireless sensor network.

B. Measuring Delay and Delay-Based Congestion Control The input to our T1 FLC [17], [20] is based on packet delay measurements. Several measurement schemes have investigated delay as a way of determining available network bandwidth, although for real-time operation in video streaming control, the method of measurement should work within the application rather than outside it. Direct probing [33] allows packet pair techniques [34] to be employed. Because direct probing assumes that the tight link is also the same as the link with minimum capacity (the thin link), this and other restrictions reduce its generality. Therefore, iterative probing with packet trains is preferable. Train of packet pairs (TOPPs) [35] is an active probing scheme that injects multiple trains of packet pairs with differing intrapair separations into the network path under test. The sending rate of each train is linearly increased by reducing the interpair separations. The one-way packet pair dispersions are measured as an indication of delay experienced in queues along the network path. The Pathload method [36] applies periodic packet trains, which, it is said, overcomes a weakness of TOPP: It is affected by the order of queues and their sizes. Pathload measures the trend of one-way delay (OWD) for each packet within a long packet train to determine a self-induced loading effect, which is induced as the earlier part of a train occupies buffers. Pathload itself has long convergence times (10–30 s). The PathChirp method [37] reduces the convergence rate by varying the probing rate within each packet train. Both Pathload and PathChirp measure OWD, but because these methods induce congestion, they are not suitable for streaming applications.


Fig. 1. (a) T1 fuzzy set. (b) Type-2 fuzzy set—primary MF. (c) IT2 fuzzy set—secondary MF (drawn with dotted lines)—and a general type-2 MF (solid line) at a specific point x . (d) 3-D view of a general type-2 fuzzy set.

As an example of probing directly applied to streaming, the LDA [38] sends periodic pairs of video packets to estimate available bandwidth through packet dispersion at the tight link. However, LDA actively increases the video sending rate according to the available bandwidth until packet losses occur, rather than setting the rate from the estimated delay. The main intention of delay-based control is to avoid the need to rely on detrimental packet losses, and therefore, delay-based control is a form of congestion avoidance [39]. In [40], delay-based congestion avoidance, which utilizes the delay gradient [41], was applied to interactive applications, such as video conferencing, to find the minimum possible delay without overly restricting throughput. In the process, it was found that output oscillations were reduced along with delay variance. The method also avoided the “phase effect” [42], whereby probe-based congestion control introduces unfairness between streams across the same link, as the same stream may repeatedly suffer packet loss at the congested link, due to an ordering effect. Finally, one should add that recent measurements of packet loss and delay across a typical tight link indicate that packet loss may be a weak indicator of congestion level because, when cross-traffic across the link is “bursty,” losses may not be evenly distributed between the competing flows. III. OVERVIEW OF TYPE-2 FUZZY SYSTEMS A. Definition of a Type-2 Fuzzy Set and Its Associated Terminology T1 fuzzy logic controllers employ crisp and precise T1 fuzzy sets. For example, consider a T1 fuzzy set representing the linguistic label of “low” temperature in Fig. 1(a): If the input temperature x is 15 ◦ C, then the membership of this input to the “low” set will be the certain and crisp membership value of 0.4. However, the center and endpoints of this T1 fuzzy set can vary due to uncertainties (which could arise, for example, from noise) in the measurement of temperature (numerical uncertainty) and in the situations in which 15 ◦ C could be called low (linguistic uncertainty) (in the Arctic, 15 ◦ C might be considered “high,” while in the Caribbean, it would be considered “low”). If this linguistic label was employed with a fuzzy logic controller, then the T1 fuzzy logic controller would need to be frequently tuned to handle such uncertainties. Alternatively, one would need to have a group of separate T1 sets and T1 fuzzy logic controllers, where each fuzzy logic controller will handle a certain situation.

1127

On the other hand, a T2 fuzzy set is characterized by a fuzzy MF, i.e., the membership value (or membership grade) for each element of this set is itself a fuzzy set in [0, 1]. For example, if the linguistic label of “low” temperature is represented by a T2 fuzzy set, as shown in Fig. 1(b), then the input x of 15 ◦ C will no longer have a single value for the MF. Instead, the MF takes on values wherever the vertical line intersects the area shaded in gray. Hence, 15 ◦ C will have primary membership values that lie in the interval [0.15, 0.65]. Each point of this interval will also have a weight associated with it. Consequently, this will create an amplitude distribution in the third dimension to form what is called a secondary MF, which can be a triangle, as shown in Fig. 1(c). If the secondary MF is equal to 1 for all the points in the primary membership and if this is true for ∀x ∈ X, we have the case of an IT2 fuzzy set. The input x of 15 ◦ C will now have a primary membership and an associated secondary MF. Repeating this for all x ∈ X creates a 3-D MF [as shown in Fig. 1(d)]—a T2 MF—that characterizes a T2 fuzzy set. The MFs of type-2 fuzzy sets are 3-D and include a footprint of uncertainty (FOU) [shaded in gray in Fig. 1(b)]. It is the new third dimension of T2 fuzzy sets and the FOU that provide additional degrees of freedom and that make it possible to directly model and handle the numerical uncertainties (for example, uncertainty in video packet delay measurements) and linguistic uncertainties (for example, uncertainty in modeling cross-traffic characteristics). A T2 fuzzy set A˜ is characterized by a T2 MF µA˜ (x, u) [43], where x ∈ X, and u ∈ Jx ⊆ [0, 1], i.e., A˜ = {((x, u), µA˜ (x, u))| ∀x ∈ X, ∀u ∈ Jx ⊆ [0, 1]}

(1)

in which 0 ≤ µA˜ (x, u) ≤ 1. A˜ can also be expressed as follows [43]: A˜ = µA˜ (x, u)/(x, u), Jx ⊆ [0, 1] (2)

x∈X

u ∈J x

where denotes union over x and u. For dis all admissible crete universes of discourse, is replaced by [43]. A suitable way to describe a T2 MF is in relationship to its secondary MFs. For example, when fx (u) = 1 ∀u ∈ Jx ⊆ [0, 1], then the secondary MFs are interval sets, and if this is true for ∀x ∈ X, we have the case of an IT2 MF [43], which characterizes the IT2 fuzzy sets that will be used in this paper. Interval secondary MFs reflect a uniform uncertainty at the primary memberships of x [43]. Since all the memberships in an interval set are unity, an interval set is represented just by its domain interval, which can be represented by its left and right endpoints as [l, r] [13]. The two endpoints are associated with two T1 MFs that are referred to as upper MF (UMF)and lower MF (LMF) [43]. The UMF and LMF are bounds for the ˜ of an IT2 fuzzy set A˜ [43]. The UMF is associated with FOU(A) ˜ and is denoted by µ the upper bound of FOU(A) ¯A˜ (x) ∀x ∈ X. ˜ and is The LMF is associated with the lower bound of FOU(A) denoted by µA˜ ∀x ∈ X. The IT2 fuzzy set A˜ can be represented in terms of upper and LMFs as follows: ˜ A= 1/u x. (3) x∈X u ∈[µ ˜ (x), µ ¯ A˜ (x) ] A

1128


This paper’s input and output variables will be represented by IT2 fuzzy sets as they are simpler to work with [44] than general T2 fuzzy sets and distribute the uncertainty evenly among all admissible primary memberships [44]. General T2 fuzzy logic control is computationally intensive, whereas the computation simplifies considerably with an IT2 controller [43], [45] (using IT2 fuzzy sets). This will enable us to design a T2 FLC that operates in real time. For discrete universes of discourse X and U, Mendel and John [13] have shown that an IT2 fuzzy set A˜ can be represented as follows: n A˜je (4) A˜ = j =1

where A˜je is an embedded type-2 fuzzy set, which can be written as follows [13]: A˜je =

N

1/ujd

xd ,

ujd ∈ Jx d ⊆ U = [0, 1].

(5)

d=1

A˜je has N elements, as it contains exactly one element from Jx1 , Jx2 , . . . , JxN , namely u1, u2 ,. . . , uN , each with its associ˜ ated secondary grade of 1 for IT2 sets. A˜je is embedded in A, N j ˜ and there is a total of n = d=1 Md Ae [13], where Md are the discretization levels of ujd at each xd . For discrete universes of discourse X and U, an embedded T1 set Aje has N elements, as it contains exactly one element from Jx1 , Jx2 , . . . , JxN , namely u1 , u2 ,. . . , uN [13], i.e., Aje =

N d=1

ujd /xd ,

ujd ∈ Jxd ⊆ U = [0, 1].

(6)

There is a total of N d=1 Md Ae [13]. For continuous universes of discourse X and U , there is an uncountable number of Aje and A˜je embedded within a given type-2 fuzzy set A˜ [13], [43]. Employing T2 fuzzy sets to represent the inputs and outputs of a fuzzy logic controller has many advantages in comparison to the T1 fuzzy set. Some of these advantages are summarized as follows. r As the T2 fuzzy sets’ MFs are themselves fuzzy and contain an FOU, they can model and handle the numerical and linguistic uncertainties associated with the inputs and outputs of a fuzzy logic controller. Therefore, fuzzy logic controllers that are based on T2 fuzzy sets have the potential to produce a better performance than T1 controllers, as shown in previous applications [16], [19], [24], [30], [32], [43], [45]–[50]. r Representation of a fuzzy logic controller’s inputs and outputs by T2 fuzzy sets rather than T1 sets will result in a reduction in the rule base size. This is because the uncertainty represented in the FOU in T2 fuzzy sets allows coverage of the same range as T1 fuzzy sets with a smaller number of labels. The relative rule reduction will be greater when the number of the fuzzy logic controller’s inputs increases [43], [45]. r Each input and output will be represented by a large number of T1 fuzzy sets, which are embedded in the T2 fuzzy

Fig. 2.

Overview of the IT2 fuzzy logic controller.

sets [13]. The use of such a large number of T1 fuzzy sets to describe the input and output variables allows for a detailed description of the analytical control surface as the addition of the extra levels of classification gives a much smoother control surface and response [45]. r It has been shown in [51] that the extra degrees of freedom provided by the FOU enable a T2 FLC to produce outputs that cannot be achieved by T1 FLCs with the same number of MFs. A T2 fuzzy set may give rise to an equivalent T1 membership grade that is negative or larger than unity. Thus, a T2 fuzzy logic controller is able to model more complex input–output relationships than its T1 counterpart and, thus, can give a better control response. B. Overview of the IT2 Fuzzy Controller This section presents a brief overview of the IT2 fuzzy logic controller employed in this paper. The IT2 fuzzy logic controller is depicted in Fig. 2. It consists of a fuzzifier, inference engine, rule base, type reducer, and defuzzifier. The IT2 fuzzy logic controller works as follows: the crisp inputs from the input sensors are first fuzzified into input T2 fuzzy sets; singleton fuzzification is usually applied in IT2 fuzzy logic control applications due to its simplicity and suitability for embedded processors and real-time applications. The input T2 fuzzy sets then activate the inference engine and the rule base to produce output T2 fuzzy sets. The T2 fuzzy logic control rules will remain the same as in T1 fuzzy logic control, but the antecedents and/or the consequents will be represented by IT2 fuzzy sets. The inference engine combines the fired rules (by employing the T2 fuzzy join and meet operations) and gives a mapping from input T2 fuzzy sets to output T2 fuzzy sets. The T2 fuzzy outputs of the inference engine are then processed by the type reducer, which combines the output sets and performs a centroid calculation that leads to T1 fuzzy sets called the type-reduced sets. As shown in Fig. 2, in the IT2 fuzzy logic controllers deployed so far, there are two ways to perform type reduction: the first way is through the iterative Karnik–Mendel (KM) procedure to calculate the type-reduced fuzzy sets [43], while the second way is the Wu–Mendel uncertainty bounds method that has been employed to approximate the type-reduced set [52]. In addition, most recently, the collapsing method of


Fig. 3.

Fuzzy-logic delay-based congestion controller.

defuzzification was introduced to provide an alternative way to perform type-reduction calculation [53], and we intend to explore the potential of this method in our future work. This paper uses the “center-of-sets” type reduction, as it has reasonable computational complexity, this being a compromise between the computationally expensive centroid type reduction and the simple height and modified height methods of type reduction, which encounter problems when only one rule fires [43]. After the type-reduction process, the type-reduced sets (or approximate type-reduced sets) are then defuzzified (by taking the average of the type-reduced/approximated type-reduced set) to obtain crisp outputs that determine the change in the video rate in our case. Type-2 FLCs have been applied to various fields with great success, as reported in [16], [19], [45]–[49], and [50]. IV. FLC AND ITS APPLICATION TO THE INTERNET AND ALL-IP NETWORKS A. Generic FLC System Fig. 3 depicts a block diagram of an FLC, with two inputs, which are a delay factor df and the delay trend (TPCT ), which is obtained from the trend analysis block, the inputs to which are the delay samples. Section IV-E describes the formation of these inputs. Fig. 3 applies to a T1 FLC and an IT2 FLC, where the fuzzifier and inference perform either T1 or T2 operations according to whether a T1 or IT2 FLC is employed. In a T1 FLC, the output processing block performs only the defuzzification operation, whereas in an IT2 FLC, first the output processing block performs type reduction to convert the inferred T2 output sets to type-reduced T1 fuzzy sets, and then, the defuzzification block converts the type-reduced T1 fuzzy sets into a crisp control output. B. Video Streaming Architecture With an FLC Fig. 4 shows the video streaming architecture in which a fuzzy logic controller determines the sending bit rate over some form of IP Internet (heterogeneous network), including the public Internet. The congestion level determination unit finds the congestion state of the network from the delay measurements made by the timer module. The congestion state data are relayed to the sender and combined with knowledge of sent packet lengths and sending times. The FLC employs this delay information to compute a new sending rate that reflects the current sending rate and the level of network congestion.

Fig. 4.

Video streaming architecture with FLC.

Fig. 5.

IPTV video delivery architecture.

1129

The transcoder adapts the bit rate of the preencoded video. In a more general model, a video rate adaptation unit can act either through a transcoder or an encoder that adapts the bit rate of live video by directly altering the quantization parameter. The current implementation changes the quantization level of a frequency-domain transcoder [54] (to reduce delay otherwise present when decoding and reencoding video). Other ways exist to change the bit rate, which could be by either applying a video layering technique, such as fine-grained scalability, or even through semantic filtering (changing the rate by altering the emphasis given to regions of interest or objects). The inhouse frequency-domain video transcoder obtains a new quantizer scale through a linear rate-quantization dependency. For online video clip streaming, it is the video encoder’s rate that is adapted. For the standard codecs, such as the MPEG and H.26x series, Sun et al. [14] document algorithms for rate adaptation in the spatial domain, and the standards documents themselves give further descriptions. C. Setup of Control of Live and Preencoded Video Streams Across an All-IP Network Fig. 5 represents fuzzy logic control of live and preencoded video streams across an All-IP network with final access links, which currently may be (see Section I) cable, ADSL, or broadband wireless. The issue of channel error control for the latter two technologies is outside the scope of this paper, and indeed, another candidate technology is a passive optical network, in which the channel is virtually error free. Whether the presumed bottleneck is at the network distribution point (this is our term to describe the distribution point for the various candidate access or “last mile” technologies) or an intermediate tight link in the case of the Internet (refer back to the discussion in Section I),

1130


Fig. 7. Fig. 6.

Relationship between input rate and OWD.

Example dumbbell topology representation of tight link or bottleneck.

a convenient and widely employed abstraction is a “dumbbell” topology network; Fig. 6 is an example. In Fig. 6, one or more video sources stream across the bottleneck link, which may represent a real or virtual capacity bottleneck in the case of the access network in Fig. 5. Alternatively, there may be one video source and a number of typical cross-traffic sources, as may occur at an Internet tight link. Normally, results are reported for the video source in reaction to the cross-traffic. Critical network behavior is focused at the tight link, though the identity of that tight link in an Internet may change over time. All side-link bandwidth capacities are configured as such that congestion will only occur at the tight link. The OWD of the tight link in Fig. 6 is set to 5 ms (representing a total delay across a network path), and the side-link delays are set to a nominal 1 ms. A value of 5 ms represents a local feedback loop, whereas the value of 40 ms used in other tests reported is the OWD over a typical European national network. Transcontinental networks will impose greater delays of 100 ms and beyond, especially if a satellite is involved. The router heading the tight link is configured with a buffer with its maximum queue size set to twice the delay–bandwidth product, as is normal in such experiments to avoid packet loss from simply setting too small a buffer size. The default first-in–first-out (FIFO) or drop-tail queuing policy is set at the buffer. Other queuing disciplines are possible, but these are either only implemented on high-end routers or, in practice, are not widely deployed. D. Concept of Delay-Based Control Assume an application with input sending rate Ri and tight link bandwidth capacity Cb . For duration δt, the total incoming traffic Ti into a tight link is given by Ti = (Ri + Rc ) × δt

(7)

where Rc is the cross-traffic rate. The achievable outgoing rate To across a bottleneck link during the same period is given by To = Cb × δt .

(8)

Clearly, there will be no backlog of data on this link if the capacity is greater than the total incoming traffic. However, excess data will be buffered by the tight link router when the incoming rate is greater than the outgoing rate. When the input rate exceeds the output capacity, buffering results in a queuing

delay qd , which is then given by a function of the difference between the input and output rates of the tight link qd =

Ti − To . Cb

(9)

The queuing delay qd , which adds to the OWD of a packet, is an indicator of network congestion. (Note that if Ti < To , then qd is set to zero.) In Fig. 7, once the rate Ri exceeds the available bandwidth, then the delay begins to increase. However, qd cannot be measured directly, whereas a calculation of OWD can be made at a receiver. In practice, OWD cannot be measured accurately without clock synchronization due to the problem of clock drift. However, as finding qd is the objective, approximate cancellation of the offset by subtraction of two OWDs is possible. There are various sources of measurement uncertainties that the system faces. For first-order clocks, the drift will be linear over time (and for second order, the drift will be nonlinear), which is one source of measurement uncertainty over the range of timing averages. Minimum OWD (minOWD) occurs when there is no queuing delay on the network path, with propagation delay being the only contributor. Because minimum delay may never be achieved or may take time to occur, this is another source of uncertainty in congestion estimation. In an Internet, due to dynamic packet routing, it is also possible that minOWD will vary over time, as the network path changes. There will normally be some buffering delay included in the OWD calculation, but qd at a tight link will change as the link becomes congested. Increase in OWD is a function of an increase in buffer fullness, which, in turn, is a function of the level of network congestion. Maximum queuing delay occurs when the buffer at the tight link becomes full and packets begin to be dropped, as is the case in full-blown congestion, which video transport seeks to avoid. The queuing delay of packets with respect to the minimum calculated OWD is an indication of the tight link’s buffer fullness, which we call multibit information, as it has a level that ranges between the minimum measured and maximum possible delay, whereas traditional congestion controllers may primarily rely on the binary information given by the packet loss. To estimate congestion level from delay samples, we employ the FLC. In summary, from Fig. 7, we have the following. r OWD is at minimum when only propagation delay is present and input sending rate (Ri ) is low.


1131

r Queuing delay (qd ) starts when available bandwidth is used up. qd increases as buffers are filled—reaches a maximum when packets begin to be lost. r Measurement uncertainties include a) minOWD and maxOWD; b) delay measurement due to clock drift over time; c) clock resolution; d) feedback delay of OWD timings. E. Delay-Based Control for the FLCs The FLC determines incipient congestion from one-way queuing delay in intermediate router buffers. The queuing delay is a measure of network congestion, and the ratio of the average queuing delay to the maximum queuing delay is a measure of bottleneck link buffer fullness. For each received packet indexed by i OW Di = Tr − Ts

(10)

where Tr is the receive time of the current packet and Ts is the time the packet was sent. When it is appropriate, the computed OWDi updates the minimum and maximum OWDs, i.e., minOW D and maxOW D, on a packet-by-packet basis. Subsequently, the maximum queuing delay is found as maxqd = maxOW D − minOW D. The queuing delay over the network path qdi is computed from the measured delay and the minimum delay qdi = OW Di − minOW D

Fig. 8.

(a) Input T2 MFs for df. (b) Input T2 MFs for the delay trend (T P C T ).

Fig. 9.

Output MFs.

(11)

and an exponentially weighted average of the queuing delay for the ith received packet is formed by avgqdi = (1 − α) × avgqdi−1 + α × qdi

(12)

where α is the forgetting constant. Exponential weighting follows the practice of the tried and tested TCP sliding window protocol calculation of averaged RTT. The practice avoids overreacting to transient changes allowing past averages to be “forgotten” over time. The forgetting constant α was set to 0.1. This value for α was confirmed as reasonable by prior tests, which are reported in Section V-D. A delay factor df is computed from the average queuing delay and the maximum queuing delay avgqdi (13) df = maxqd where df ranges between [0, 1], with 0 indicating no incipient congestion and 1 indicating full-blown congestion, with shades of incipient congestion between 0 and 1. df is an early notification of congestion and is the first input to the FLC. A trend analysis method is used to determine the general trend of the average delay. In each measurement epoch, a number √ k of queue delay samples are grouped into τ groups, where τ = k. We use the pairwise comparison test (PCT) [36] to determine the overall trend of the queuing delay, which is shown as τ I(M i > M i−1 ) (14) TPCT = i=2 τ −1 where M i is the median of group i and I(X) is 1 if X holds and 0 otherwise. The value of TPCT is sent back to the sender,

where the fuzzifier determines whether the level was increasing or not according to an MF. F. T1 and IT2 FLC Design For both T1 and IT2 FLCs triangular MFs were employed as they provide reduced computation time, which is suitable for the video domain. Choosing the number of MFs is important, as it determines the smoothness of the bit-rate granularity. However, the number of MFs is directly proportional to the computation time, and hence, for this critical control application, a simplified representation is preferable. In the choice of the number of linguistic labels (or MFs) for both the FLCs input and outputs, the number of linguistic labels were tuned to be the maximum number of labels the system can afford to give a good control precision while still enabling the system to achieve real-time performance. Fig. 8(a) describes the MFs for df, which partition its range into four regions that are low (L), medium (M),high (H), and very high (VH). Fig. 8(b) describes the MF for the delay trend (TPCT ) that has two linguistic labels, which are increasing trend (I) and decreasing trend (D). The controller output, S, which drives the video rate adaptation unit, is represented by 11 linguistic labels, as shown in Fig. 9, which are negative extremely

1132


TABLE I FUZZY-LOGIC INFERENCE RULES

high (NEH), negative very high (NVH), negative high (NH), negative medium (NM), negative low (NL), zero (Z), positive low (PL), positive medium (PM), positive high (PH), positive very high (PVH), and positive extremely high (PEH). The rule base for both the T1 and IT2 FLC is shown in Table I. The T1 version of this controller employs the center-of-sets defuzzification method. The IT2 FLC employs center-of-sets type reduction by using the iterative KM procedure [43]. We have employed the iterative KM procedure as the number of used rules is quite small (four rules). It is given that the KM procedure is proven to converge in no more than M (number of fired rules, maximum four in our case, if all rules fired) iterations to find the left endpoint of the type-reduced set and no more than M iterations to find the right endpoint of the type-reduced sets [43]. Hence, the FLC will take a maximum of eight iterations (which is a very acceptable number) to finish the type-reduction step. Thus, it has been feasible to employ the KM procedure and calculate correct values of the type-reduced sets rather than approximate the type-reduced sets using the Wu–Mendel uncertainty bounds method. The IT2 MFs in Fig. 8 are related to those for the T1 controller developed in our previous work in [20] (except for a minor variation in the form of the trend test) in the sense that the T1 triangular MFs act as principal MFs for the T2 MFs FOUs. For the IT2 FLC, the T2 MFs FOUs were constructed by distributing the empirically anticipated uncertainty of the domains of df and TPCT equally around the principal T1 MFs that were optimally designed in our previous work [20]. There was no uncertainty associated with the output: S; hence, we have used T1 MFs for both the T1 and IT2 FLCs. G. Comments on the Employed FLCs’ Stability When a system becomes unstable, the output of the system approaches infinity (or negative infinity), which often poses a security problem for the controlled system as such instability can often incur a certain amount of physical damage and can become costly [55]. Bounded-input–bounded-output (BIBO) stability often means that for any bounded input over any amount of time, the output will also be bounded [55]. A bounded signal is any signal where there exists a value such that the absolute value of the signal is never greater than some value; hence, at no point can the signal tend to infinity [55]. A system is defined to be uniformly BIBO stable if there exists a positive constant k such that for all bounded input conditions, the output absolute value never exceeds k. That is to say that as long as a stable signal is input, a stable output is guaranteed. If a system is BIBO stable, then the output cannot “blow up” (i.e., become infinite) if the input remains finite [55].

The fuzzy logic controller was initially introduced as a modelfree control design technique. However, some current research is moving toward model-based fuzzy control methods that can guarantee stability and robustness of the closed-loop system [56]. This approach assumes that a fuzzy model describing the process/plant to be controlled is available. A fuzzy controller is then designed whose structure matches the structure of the fuzzy plant model [56]. The T1 Takagi–Sugeno–Kang (TSK) fuzzy model offers a general framework for controller synthesis [57]. Basic stability conditions for T1 fuzzy controllers were derived in [58] in terms of linear matrix inequalities (LMIs) based on Lyapunov stability theory to guarantee system stability. Relaxed stability conditions were reported in [59]. As hinted in [57], due to the uncertainties present in nonlinear plants, the properties leading to relaxed stability conditions in T1 fuzzy controllers will vanish and the Lyapunov-based stability analysis will lead to conservative stability conditions. As T2 FLCs were proposed to deal with the uncertainties present in real environments, work is starting to explore the stability analysis of T2 FLCs, as reported in [57], [60], and [61]. However, the techniques developed in [57] are for model-based closed-loop TSK T2 fuzzy controllers, which is not the case in this paper. Additionally, in the video transmission domain, there is no precise knowledge of the plant and its mathematical descriptions. Consequently, other techniques employed for closed-loop systems with knowledge of the plant mathematical model will not be applicable to our research in this paper. However, some methods like those proposed in [60] and [61] could be used for our future work for the design of the rule base of stable Mamdani T2 FLC. However, as the rule base presented in Table I represents the agreed rule base among the various domain experts, in this paper, we needed to employ this rule base anyway. Although a theoretical stability analysis of the FLCs is far beyond the scope of this paper, informal visual comments could be drawn from the FLCs control surfaces, as shown in Fig. 10. The control surfaces graphically present the mathematical function articulated by the FLCs [62]. As was shown in Fig. 8, the inputs df and TPCT are bounded between 0 and 1, and as shown in Fig. 10, the FLCs output is also bounded between a minimum finite value and a maximum finite value. As a result, it could be assumed from the control surfaces shown in Fig. 10 that the FLCs satisfy the BIBO stability requirements, since for any bounded input over any amount of time, the output will also be bounded. In addition, it could be seen that small changes in the inputs correspond to small output changes (i.e., the surface gradients are not steep). However, it should be stressed that these are only informal comments based on the observation of the control surfaces and that a full theoretical analysis is needed in future work to establish the BIBO stability of the developed FLCs. From Fig. 10, it can be noted that, as has been shown in other work such as that reported in [19] and [45], the T2 FLC control surface in Fig. 10(b) is smoother than the T1 FLC control surface in Fig. 10(a). The smooth control surface of the T2 FLC will map to a smoother and better control response when facing high levels of uncertainty, as will be shown in the experiments reported in Section V.


1133

sists of N = 12 or 15 pictures with the first intracoded—without motion compensation—picture forming a decoding anchor for the others in the GOP. A value of M = 3 indicates two bipredictively (B-) encoded pictures before every predictively (P-) encoded picture. The GOP structure of video stream encoding was introduced in Section I. The anchor frame at the start resets the decoder at approximately half second intervals, thus allowing decoder resynchronization in the event of lost packet or channel errors. In MPEG-2, a P-picture relies on a single reference to a previous I- or P-picture for the removal of motion-induced redundancy, whereas the B-picture is predicted from up to two adjacent I- and P-pictures. B-pictures have no predictive value themselves, and therefore, the impact if they are corrupted or lost is low. For error resilience purposes, there was one slice per packet, thus resulting in 18 packets per frame. A slice consists of a row of macroblocks, which is the unit of motion estimation in block-based hybrid encoders such as MPEG-2. Video quality is calculated as the luminance PSNR measured in decibels, i.e., PSNR = 10 log10 (MAX2 / MSE), where MSE is mean-squared-error summation of the pixelwise difference between transmitted and received video frames relative to the peak luminance value (MAX). V. EXPERIMENTS AND RESULTS Performance evaluation of the FLCs consisted of emulations using models within the well-known and widely applied ns-2 network emulator (v. 2.31 used) [64], with the FLCs being implemented as new protocols within ns-2. The network emulator ns-2 was designed specifically to model the network and transport layers of the protocol stack, which are the focus in this paper. As is usual in such experiments, sufficient simulations were repeated to ensure convergence of mean values reported, i.e., at least ten simulations and often 50 repeated simulations, according to the variance. A. T1 FLC and TFRC Comparison Fig. 10. (a) Control surface of the employed T1 FLC. (b) Control surface of the employed type-2 FLC.

H. Emulations With a Video Source In emulations with a video source, two 40-s video clips acted as inputs. The video clips are 1) a news reader and changing backdrop with moderate motion, which we designate “news”; and, as a way of comparison, 2) an extract from a “football” match, with considerable motion. The clips were MPEG-2 encoded [63] at a VBR with a mean rate of 1 Mb/s over 40 s. The MPEG-2 codec was selected, as major industrial users and providers, including the Digital Video Broadcasting consortium, apply it to the delivery of multimedia-based services. The rate was changed through a transcoder, and the peak SNR (PSNR) was found by reconstructing with a reference MPEG-2 decoder. The display rate was 25 frames/s, which results in 1000 frames (pictures) in each simulation. The source video clips’ format was common intermediate format (CIF) sized (352 × 288 pixel resolution) with a GOP structure of N = 12 and M = 3, where a GOP commonly con-

This section presents preliminary results and comparison made between a T1 FLC and the TFRC protocol—the subject of a Request for Comment (RFC)3 [6] and a prominent method of congestion control from the originators of the “TCPfriendly” concept [11]. An IT2 FLC is compared with TFRC in Section V-D. As mentioned in Section I, direct adoption of TCP’s congestion control is not recommended, as it results in a sawtooth sending pattern, which can produce a subjectively disconcerting variation in video quality. To ensure fairness, the publicly available TFRC ns-2 simulator model (in the form of object tcl scripts to drive the simulator) was availed from http://www.icir.org/tfrc/. In TFRC, the sending rate is made a function of the measured packet loss rate during a single RTT duration measured at the receiver. Unfortunately, if the TFRC feedback frequency is reduced, TFRC tends to dominate coexisting flows [7]. The sender then calculates the sending rate according to the TCP throughput equation given 3 An RFC is the Internet community’s way of standardizing protocols and other innovations.

1134

Fig. 11. Tracking a changing available bandwidth with T1 FLC VBR video or TFRC sending rates.

in [6]. In TFRC, as with all other congestion controllers tested in this paper, UDP transport is employed to avoid unbounded delays, which are possible with TCP transport. A stepped available bandwidth can be generated by a background or cross-traffic CBR that switches its rate at times configured in the simulator. Though extreme switches of this kind are unlikely to occur in real-world networks, this type of test highlights the tracking ability of the congestion controllers. Fig. 11 reports experiments with the T1 FLC of [17]. The relative smoothness of T1 FLC is demonstrated in comparison to the traditional TFRC [6] with the VBR “news” video under control across the stepped available bandwidth. A delay-based FLC was employed in [17], but its input was based on packet dispersion across the network path rather than the more direct application of packet delay in this paper, which was introduced in T1 form by us in [20]. The details of that T1 FLC are thoroughly documented in [17] and, hence, are not repeated here. The smoothness of the transmission rate is important in video transport as a fluctuating compressed bit rate implies a fluctuation in video quality, which is more disturbing to a viewer than a stream of consistent quality [66], even if that average quality was lower than that of a fluctuating stream. What is apparent from Fig. 11 is that TFRC frequently overshoots the available bandwidth. While this could be compensated for by an offset to place the level below the available bandwidth, there would be uncertainty as to what the offset should be, and in any case, the bandwidth adaptation would be inefficient in comparison to the T1 FLC solution. Fig. 11 and related results support the view that probing congestion controllers such as TFRC [6] do not entirely avoid oscillations as they emulate the TCP mechanism, although with adjustments for the multimedia payload. Fig. 12 gives the mean video quality of the received news clip. In each run, we carried out ten experiments across a dumbbell topology network with a 500 kb/s capacity; a New Reno variant of TCP source was present as background traffic in each experiment, when in the second experiment two TCP sources acted as background traffic, and so on, and all ten TCP sources were on as background traffic for the tenth experiment. All experiments were repeated ten times with different seeds, and the mean result was taken. The plots for the sets of independent tests confirm the improvement in video quality that can arise from using a T1


Fig. 12. Delivered PSNR for the “news” VBR video stream with an increasing background traffic load for a 500 kb/s bottleneck bandwidth using either a T1 FLC or TFRC.

Fig. 13. Multiple competing flows with T1 FLC and TFRC controllers across a range of bottlenecks, compared with an ideal per flow allocation of bandwidth. (a) Employing three T1 FLCs (F1, F2, and F3) and two TFRC (T1 and T2) flows. (b) Employing three T1 FLCs (F1, F2, and F3) and three TFRC (T1, T2, and T3) flows.

FLC. Given the logarithmic scale of the vertical axis, a gain of several decibels certainly will be perceptible to the viewer. The T1 FLC also maintains a “good” quality above 30 dB for the range of background loads. When multiple video flows coexist across a bottleneck link, as might occur in an All-IP network, Fig. 13 shows that the T1 FLC results in flows that do not exceed an ideal share of the bottleneck bandwidth. Conversely, the average bandwidth of the TFRC flows is above that of the FLC flows and above the ideal or


1135

equally shared bottleneck bandwidth. This behavior of TFRC, when exposed to a tight link without TCP traffic, would work to the disadvantage of other traffic. If replicated in a network, it is likely that this behavior would result in increased packet loss for the TFRC flows. B. T1 FLC and IT2 FLC Evaluations As described in Section IV-C, a T1 and IT2 version of the same FLC was set up to compare their performance. Comparison tests aimed to measure the ability of FLCs to track traffic across a tight link, as well as a stepped available bandwidth. The T1 and IT2 FLCs employ delay and its trend to gauge the state of the network. However, as outlined in Section I, there is inherent noise in the measurement of delay, including packet time stamps with limited resolution, unresolved clock drift between sender and receiver, estimates of minimum and maximum delay across the network path that take time to reach steady state, and for long streaming sessions time-varying behavior. These uncertainties in the input to an FLC will potentially impact its performance. We used a normal distribution to generate a random noise value with zero mean and a specified standard deviation (s.d.), which is determined by the level of noise required. The s.d. value was dynamically adjusted relative to the measured value. Thus, with the value for a packet’s delay, a random variation was added to that value so that in the long term, that additional value would form a given percentage of the delay value. For each test, the level of additional noise was incrementally increased, and the performances of the T1 FLC and the IT2 FLC were compared in terms of the sending rate, s.d. of the sending rate, packet loss rate, and delivered video quality. The smoothness of the transmission rate was measured by a reduction in the s.d. of the delay on a per packet basis. Results are gathered in Fig. 14 and Table II. Fig. 14(a) shows the comparisons between the T1 and IT2 FLCs in terms of the sending rate (in megabits per second) when increasing the noise level, and Fig. 14(b) shows the comparisons between the T1 and IT2 FLCs in terms of the packet loss percentage when increasing the noise level. An interesting and important feature of Fig. 14(a) is that IT2 performance gracefully degrades, but T1 performance is subject to rapid deterioration. Fig. 14(c) shows the comparisons between the T1 and IT2 FLCs in terms of the average video quality (in decibels) when increasing the noise level. Table II shows the comparisons in s.d. between the T1 and IT2 FLCs; it is shown that below 30% additional noise, the two controllers (T1 and IT2 FLCs) do not deviate significantly. However, beyond 30% of additional noise (but see later remarks on confidence intervals), the T1 FLC quality significantly degrades while the IT2 FLC shows much better performance than the T1 FLC in terms of reduced fluctuation (s.d.) in the sending rate and a reduced packet loss rate, both of which will be reflected in better average video quality. In fact, Fig. 14(c) confirms that delivered average video quality is much improved (where around 30 dB represents good quality) by using IT2 FLC as compared with T1 FLC when increasing the noise level, where the IT2 FLC handles the uncertainties up to high noise levels of 70% while still producing resilient performance and

Fig. 14. Performance of T1 and IT2 FLCs for an increasing noise level. Average against (a) sending rate, (b) packet loss rate, and (c) video quality.

TABLE II STANDARD DEVIATIONS AND CONFIDENCE INTERVALS OF T1 AND T2 FLC SENDING RATES (IN KILOBITS PER SECOND)

delivering good video quality in spite of the high noise levels faced. In view of the higher than usual variances in sending rate for these simulations reported in Table II, the 90% confidence intervals were calculated for the sending rates. With 50 simulations for each data point to gain convergence of the mean values that they represent, from Table II, there is no overlap in the intervals for added noise level percentages beyond 40%, but at 40%,

1136


Fig. 15. Response of T1 and IT2 FLCs at a stepped edge after a 40% noise level addition to delay measurements.

there is a partial overlap. These results formally confirm that for high noise levels in Fig. 14(a), there is a statistically significant difference between T1 and IT2 in sending rates. A paired observations test [65] using Student’s small sample t-distribution of the differences for the same set of results also confirms the statistical significance, as the 90% confidence interval does not cross zero. A two-tailed, paired observations test also confirms that for a noise level of 40% and above, the results are statistically significant for the packet loss rates in Fig. 14(b), with t(6) = 6.633, with the p-value = 0.001, which is a probability of 0.001 that the difference in the means does arise by chance. We do not report on the significance of results involving PSNR, for example, Fig. 13(c), as PSNR values are logarithmic quantities, and consequently, the interpretation is not clear. Turning to Fig. 15, it is obvious that at stepped edges, with a 40% noise level addition to delay measurements, the IT2 FLC is able, more directly, to follow the change in available bandwidth, thus resulting in less packet loss and, consequently, in higher video quality. As a visual comparison, the same video frame is taken from the delivered video stream after decoding and shown in Fig. 16(a) and (b) when the video stream was under the control of the T1 FLC and the IT2 FLC, respectively. Note that had the visual snapshot comparison been made with the football clip mentioned in Section IV-H, the video frames of the uncontrolled sequence after the introduction of 40% noise would be even more severely degraded than in Fig. 16(b), and the sequence as a whole would not be watchable as its level would be below 10 dB [refer to Fig. 14(c)], which is already very poor quality. The degradation would occur through the greater coding complexity of football, which, because of its higher spatial and temporal activity levels, implies that the effect of packet loss is compounded. The relative effect of packet loss on high-activity video, such as football, compared with low-activity video, such as news, is referred to in Section V-C. The improvement from employing the IT2 FLC, when there is 40% on average added noise, is self-evident where the T1 FLC results in poor picture quality, while the IT2 FLC maintains the quality of the video, in spite of the added 40% noise. The lossy stripes displayed are typically the result of the loss of packets containing information from several macroblocks. C. Testing the Response to Internet Traffic The heavy-tailed nature of Internet file sizes and the synchronization of TCP connections are two factors that give rise to

Fig. 16. Received video frame after a 40% noise level addition to delay measurements with (a) a T1 FLC and (b) an IT2 FLC.

traffic source on the Internet with a Pareto probability distribution function (pdf) [67] for sending rates, thus resulting in the observable “bursty” traffic patterns. We have performed experiments with a number of long-tailed sources with Pareto pdf (shape factor of 1.3). Each 500 kb/s source was set with 500 ms for both idle and burst time. In Fig. 17(a) and (b), an IT2 FLC tracks with a CBR source just one and then two of these sources, respectively, with good tracking considering the burstyness of the Pareto sources. The CBR’s rate was adapted according to feedback to the IT2 FLC. Thus, the IT2 FLC is able to track available bandwidth when typical Internet traffic sources are present across a bottleneck link. As the number of Pareto sources increases, as shown in Fig. 18, it is obvious that the IT2 FLC produces much better performance (in terms of a lower percentage packet loss) than the T1 FLC. A paired-observations test [65] for all results for four streams and beyond in Fig. 18 reveals that the 90% confidence interval does not cross zero and that, therefore, the difference in packet loss rates reported in these results is statistically significant. In fact, t(6) = 3.622, with a p-value of 0.011, thus quantitatively confirming that the difference in the means for the T1 and IT2 results is unlikely to have arisen by chance. Fig. 19 shows the resulting PSNR when tracking against


1137

Fig. 18. T1 and IT2 FLC loss rates for a 1.5 Mb/s link capacity with an increasing number of Pareto sources.

Fig. 17.

IT2 tracking of (a) one Pareto source and (b) two Pareto sources.

an increasing number of Pareto sources for the news video clip [see Fig. 19(a)] and the football video clip [see Fig. 19(b)]. The news and football VBR sources are controlled against the same cross-traffic. The resulting video quality again shows how the IT2 FLC outperforms the T1 FLC performance as the number of sources sharing the tight link (or as the number of crosstraffic sources) increases. This again shows the power of the IT2 FLC in handling the encountered uncertainties. For “football,” at lower background traffic intensities, the T1 FLC at a few data points gives a slightly better quality due to the pattern of losses’ impact on the compressed stream. However, as the number of cross-traffic sources increases, the relative gain from the IT2 FLC becomes apparent. Note that in Fig. 19(b), the vertical axis for the football sequence reflects a lower range of PSNR values compared with that of Fig. 16(a), which as mentioned in Section V-B is due to the greater coding complexity of this video sequence. For wireless communication, levels of 30 dB and above are good—around 30 dB is acceptable—while for values below 25 dB, the quality is becoming poor but may be watchable.

Fig. 19. T1 and IT2 FLCs showing resulting PSNR when tracking against an increasing number of Pareto sources for (a) news and (b) football video clips (note differing vertical scales).

D. Testing the Response to All-IP Traffic Simulation of TFRC was introduced in Section V-A. The congestion controller TEAR [7] is based directly on the arithmetic increase multiplicative decrease (AIMD) algorithm of TCP. Unlike TCP, TEAR avoids the oscillatory behavior of TCP by averaging its sending rate over a round, based on the time to send

1138

a congestion window’s packets. Consequently, TEAR’s sending rate approximates that of an equivalent TCP source. The default settings for TEAR were used with publicly available ns-2 models. Both TFRC and TEAR rely on measurements of the RTT, while TFRC is also adversely affected by inaccurate loss rate estimates [64]. As noted in Section II, without a transcoder, both TFRC and TEAR require playout buffers to smooth out network delay. Therefore, PSNR is affected by the loss rate only, assuming a large enough buffer to avoid overflow. The FLC causes a reduction in video quality to occur through bit-rate transcoding if there is insufficient bandwidth, but this action avoids the need for long start-up delays and allows smaller buffers on mobile devices. In these comparison tests, the standard “dumbbell” network topology (see Fig. 6) was again assumed but with a bottleneck of 25 Mb/s, which is similar to what might occur at an AllIP bottleneck. The OWD, which models the latency across the complete network path, was set to 40 ms, which is the same as the maximum delay across a country such as the U.K. or France, as already mentioned in Section IV-C. Side-link delay was set to 1 ms, and the side link capacity was set to easily cope with the input video rate. The mean encoded video rate was 1 Mb/s. The buffer sizes were set to be twice the delay–bandwidth product. The intention of these tests was to see how many video streams could be accommodated across the bottleneck link, and consequently, the channel was assumed to be error free. In Table III, the number of controlled video sources (replicating the news source described in Section IV-H) was incrementally increased. The starting time of streaming the “news clip” to each client was staggered, and then, each clip was repeatedly sent over 200 s. The first 40 s of results were discarded as representing transient results. As can be seen from Table III, when there is no control, there is no packet loss until the capacity of the link is reached. Thereafter, the link utilization grows, and as might be expected, the packet loss rate rapidly climbs. Failure to estimate the available bandwidth causes both TFRC’s and TEAR’s mean link use to exceed the capacity of the bottleneck link. As the number of flows increases, it becomes increasingly difficult to control the flows, and there is a steady upward trend in the overshoot. With respect to TEAR, this leads to considerable packet loss. The packet loss patterns are reflected in the resulting PSNRs, although there is no direct relationship because of the effect of motion estimation in the codec. This is surprising in that TEAR was developed after TFRC and in part as a reaction to it [68]. However, subsequent to the development of TEAR, TFRC has undergone some refinements, such as TCP’s self-clocking. However, from Table III, it is apparent that the IT2 FLC does not suffer from the difficulties that TFRC and TEAR encounter. There is a very small loss rate due to moments when the time-varying nature of VBR video results in the FLC overestimating the available bandwidth, but this is significantly below the loss rates of the traditional controllers. This again shows the potential of the IT2 FLC, as opposed to traditional congestion controllers, in that the IT2 FLC can lead to a small loss rate in the face of the uncertainties and noise encountered.


TABLE III PERFORMANCE COMPARISON OF CONGESTION CONTROLLERS

Fig. 20. TCP-friendliness of FLC for multiple competing TCP flows and two, four, and eight times the bandwidth–delay product size queues.

E. Further Properties of an FLC For the tests reported in this section, the delay-based FLC of [17] was employed with its input based on packet dispersion across the network path, rather than the more direct application of packet delay elsewhere in this paper. To ensure that an FLC could be TCP-friendly, a set of tests very similar to those in [69] was conducted. As in [69], link delay was set to 50 ms, and the tight link capacity was initially set to 2.5 Mb/s. Also, as


Fig. 21.

1139

Tracking a changing available bandwidth with FLC VBR video for differing values of link delay with buffer size set to the delay–bandwidth product.

Fig. 22. Tracking a changing available bandwidth with FLC VBR video for differing of link delay with buffer size set to the delay–bandwidth product for a fixed 1-ms delay.

in [69], tracking experiments revealed that for delays below 100 ms, the results did not vary widely. The same number of flows, i.e., FLC of VBR video and FTP TCP (New Reno variant) sessions, shared the tight link. Because of a lower bound on the transcoder’s bit rate, for experiments with 40 and 80 flows, the tight link capacity was increased to 4 Mb/s. The router buffer queue size was set to two, four, and eight times the bandwidth– delay product. This allows assessment of the impact of queuing delay over the network path on feedback messages. Fig. 20 reports the experiments for drop-tail routers, averaged over ten runs, thus showing that the TCP-friendliness actually increases as more flows are introduced. TCP-friendliness is in the same margins as for [69] and confirmed to be close to an ideal figure of one. Another question that might occur to the reader follows: What is the effect of feedback delay? This issue has been extensively considered, and as with TCP-friendliness, an FLC, in general, is certainly equivalent to a conventional controller. In Fig. 21, the link delay is set to a range of different values. The buffer size is set to the appropriate delay–bandwidth product. For link delays over 75 ms, there is a loss in responsiveness caused by the delayed feedback. This will affect the positioning of servers.

If a buffer’s size is not set to catch all possible burst sizes (by reducing their size below the delay–bandwidth product), then increased packet loss will occur. This will affect the averaging ability of the congestion-estimation mechanism. In Fig. 22, there is a further loss in responsiveness, though this appears more serious for delays over 75 ms. Putting these results in perspective, congestion controllers are not normally tested with such large values of path delay, which beyond 40 ms probably already exceeds the OWD in a moderately sized nation’s network. The impact of parameter α, which appears in (12), has also been tested. The application was somewhat different, because in the FLC system reported in [17], α determines the congestion level input rather than the estimated queuing delay. However, both inputs serve a similar function. The value of α then determines the percentage of the current network congestion level sample employed in the determination of the running average. Considering too little of the current sample results in the FLC becoming unresponsive to network congestion-level fluctuations while considering too much amplifies the risk of ‘’bursty” sending rates. Fig. 23 shows this and the fact that the default value of α = 0.1 achieves responsive tracking. Large values of α, especially 0.9, do not result in smooth tracking.

1140


is video traffic carried by UDP rather than the TCP transport protocol. This is gratifying as it demonstrates the twin advantages of type-2 logic: the ability both to counter measurement uncertainty as well as perturbations to the conditions for which the fuzzy models were not originally designed. These findings offer the type-2 FLC as a way forward for congestion control of video streaming across packet-switched IP networks. REFERENCES

Fig. 23. Tracking a changing available bandwidth with FLC VBR video for different values of parameter α.

VI. CONCLUSION Intelligent control of network traffic flows has hardly been explored, though intelligent policing of networks that have an access control mechanism has received some attention. However, the streaming of encoded video clips is taking an increasing share of bandwidth on the Internet (YouTube video searches are now4 the most frequent search queries on the Internet in the U.S. after Google), where there is no access control and video streams must be delivered by IPs best-effort mechanism. All-IP networks are an emerging solution to the growth in multimedia traffic, but although traffic is managed, bottlenecks will still exist as video streams share a channel to the end users. Video streams are brittle flows in the sense that they are sensitive both to packet loss and packet queuing delay. Loss of packets from reference frames is particularly harmful. TCP transport is unsuitable as a means of controlling these flows because its guaranteed reliability results in delay variation unless large buffers are deployed at the receiver. Therefore, UDP transport with an application layer congestion controller is the normal solution. Even though precise modeling of TCP by UDP control at the application layer as a way of preserving its average behavior has found favor, this emulation still results in fluctuations in the sending rate and larger packet losses than necessary. On the other hand, fuzzy logic has been applied to congestion control with very satisfactory results. However, the lack of a convenient way to demonstrate the robustness of this solution is an impediment to wider adoption. In this paper, we have shown that an IT2 fuzzy logic controller preserves all the qualities of a classical fuzzy logic controller and is also able to respond to uncertainty in the packet delay measurements that form the principle feedback to the controller. In fact, the ability to cope with considerable corruption of the input was quite dramatic in our results. It was also found that the IT2 FLC was able to achieve minimal packet loss (which is highly desirable for delivered video quality and consequently for user satisfaction) in comparison with the existing congestion controllers and T1 fuzzy controllers. Existing controllers are specialized to typical Internet traffic, which is TCP dominated, whereas tests for an All-IP network bottleneck have demonstrated the potential of a type-2 controller to outperform such controllers. In these situations, the IT2 controller responds to a type of traffic for which it was not originally intended, which 4 According

to http://www.comscore.com/press/release.asp?press=2476

[1] S. V. Vasudevan, X. Liu, and K. Kollmansberger, “IPTV architectures for cable systems: An evolutionary approach,” IEEE Commun. Mag., vol. 46, no. 5, pp. 102–109, May 2008. [2] IEEE Standard for Local and Metropolitan Area Networks Part 16: Air Interface for Fixed Broadband Wireless Access Systems, IEEE Std. 802.162004, Oct. 1, 2004. [3] S. Han, S. Lisle, and G. Nehib, “IPTV transport architecture alternatives and economic considerations,” IEEE Commun. Mag., vol. 46, no. 2, pp. 70–77, Feb. 2008. [4] LAN Design Guide for the Midmarket, Cisco Systems, Inc., San Jose, CA, 2000. [5] G. Xie, G. Zhang, J. Yang, Y. Min, V. Issarny, and A. Conte, “Survey on traffic of metro area network with measurement on-line,” in Proc. Int. Teletraffic Congr., 2007, pp. 666–677. [6] M. Handley, S. Floyd, J. Padyhe, and J. Widmer, “TCP friendly rate control (TFRC): Protocol specification,” Internet Eng. Task Force (IETF), IETF RFC 3448, 2003. [7] I. Rhee, V. Ozdemir, and Y. Yi, “TEAR: TCP emulation at receivers—Flow control for multimedia streaming,” North Carolina State Univ., Raleigh, NC, Tech. Rep., Apr. 2000. [8] D. Sisalem and H. Schulzrinne, “The loss-delay based adjustment algorithm: A TCP-friendly adaptation scheme,” in Proc. Netw. Oper. Syst. Support Digit. Audio Video, Jul. 1998, pp. 215–226. [9] G.-M. Muntean, “Efficient delivery of multimedia streams over broadband networks using QOAS,” IEEE Trans. Broadcast., vol. 52, no. 2, pp. 230– 235, Jun. 2005. [10] J. Widmer, R. Denda, and M. Mauve, “A survey on TCP-friendly congestion control,” IEEE Netw., vol. 15, no. 3, pp. 28–37, May 2001. [11] S. Floyd and K. Fall, “Promoting the use of end-to-end congestion control in the Internet,” IEEE/ACM Trans. Netw., vol. 7, no. 4, pp. 458–472, Aug. 1999. [12] M. Voljnovic and J.-Y. Boudec, “On the long-run behavior of equationbased rate control,” IEEE/ACM Trans. Netw., vol. 13, no. 3, pp. 568–581, Jun. 2005. [13] J. M. Mendel and R. I. B. John, “Type-2 fuzzy sets made simple,” IEEE Trans. Fuzzy Syst., vol. 16, no. 2, pp. 117–127, Apr. 2002. [14] H. Sun, T. Chiang, and X. Cheng, Digital Video Transcoding for Transmission and Storage. Boca Raton, FL: CRC, 2004. [15] Z. Zhao, D. T. Nguyen, and J. Osterman, “Variable bit-rate streaming with TCP-friendly rate control,” in Proc. IEEE Int. Conf. Multimedia Expo., 2008, pp. 453–455. [16] C. Lynch, H. Hagras, and V. Callaghan, “Parallel type-2 fuzzy logic coprocessors for engine management,” in Proc. IEEE Int. Conf. Fuzzy Syst., London, U.K., Jul. 2007, pp. 907–912. [17] E. A. Jammeh, M. Fleury, and M. Ghanbari, “Fuzzy logic congestion control of transcoded video streaming without packet loss feedback,” IEEE Trans. Circuits Syst. Video Technol., vol. 18, no. 3, pp. 387–393, Mar. 2008. [18] M. Rezaei, M. H. Hanukse, and M. Gabbouj, “Semi-fuzzy rate controller for variable bit rate video,” IEEE Trans. Circuits Syst. Video Technol., vol. 18, no. 5, pp. 633–645, May. 2008. [19] H. Hagras, “Type-2 FLCs: A new generation of fuzzy controllers,,” IEEE Comput. Intell., vol. 2, no. 1, pp. 30–43, Feb. 2007. [20] E. A. Jammeh, M. Fleury, and M. Ghanbari, “Delay-based congestion avoidance for video streaming over IP networks,” in Proc. IEEE Packet Video, Lausanne, Switzerland, Nov. 2007, pp. 8–17. [21] A. Pitsillides and A. Sekercioglu, “Congestion control,” in Computational Intelligence in Telecommunications Networks, W. Pedrycz and A. Vasiliakos, Eds. Boca Raton, FL: CRC, Sep. 2000, pp. 109–158. [22] S. Ghosh, Q. Razouki, H. J. Schumacher, and A. Celmins, “A survey of recent advances in fuzzy logic in telecommunications networks and new challenges,” IEEE Trans. Fuzzy Syst., vol. 6, no. 3, pp. 443–447, Aug. 1998.


[23] A. Sekercioglu, A. Pitsillides, and A. Vasilakos, “Computational intelligence in management of ATM networks: A survey of current state of research,” Soft Comput., vol. 5, no. 4, pp. 257–263, 2001. [24] Q. Liang, N. Karnik, and J. M. Mendel, “Connection admission control in ATM networks using survey-based type-2 fuzzy logic systems,” IEEE Trans. Syst., Man, Cybern. C, Appl. Rev., vol. 30, no. 3, pp. 329–339, Aug. 2000. [25] H. B. Kazemian and L. Meng, “An adaptive control for video transmission over Bluetooth,” IEEE Trans. Fuzzy Syst., vol. 14, no. 2, pp. 263–274, Apr. 2006. [26] L. Rossides, C. Chrysostemou, A. Pitsillides, and A. Sekercioglu, “Overview of fuzzy-RED in Diff-Serv networks,” in Proc. Soft-Ware (Lecture Notes in Computer Science 2311), D. W. Bustard, W. Liu, and R. Sterritt, Eds., Apr. 2002, pp. 2–14. [27] X. Wang, D. Ye, and Q. Wu, “Using fuzzy logic controller to implement scalable quality adaptation for stored video in DiffServ networks,” presented at the 12th Int. PacketVideo Workshop, Pittsburgh, PA, Apr. 2002. [28] A. Leone, A. Bellini, and R. Guerrieri, “An H.261 fuzzy-controlled coder for videophone sequences,” in Proc. IEEE World Conf. Comput. Intell., Jun. 1994, pp. 244–248. [29] P. M. Grant, Y.-S. Saw, and J. M. Hannah, “Fuzzy rule based MPEG video rate prediction and control,” in Proc. Eurasip ECASP Conf., Jun. 1997, pp. 211–214. [30] Q. Liang and J. M. Mendel, “MPEG VBR video traffic modeling and classification using fuzzy technique,” IEEE Trans. Fuzzy Syst., vol. 9, no. 1, pp. 183–193, Feb. 2001. [31] R. Razavi, M. Fleury, and M. Ghanbari. (2007). Fuzzy logic control of adaptive ARQ for video distribution over a Bluetooth wireless link. Advances in Multimedia, DOI: 10.1155/2007/45798. [Online]. Available: http://www.hindawi.com/getarticle.aspx? [32] H. Shu, Q. Liang, and J. Gao, “Wireless sensor network lifetime analysis using interval type-2 fuzzy logic systems,” IEEE Trans. Fuzzy Syst., vol. 16, no. 2, pp. 416–427, Apr. 2008. [33] M. Jain and C. Dovrolis, “Ten fallacies and pitfalls in end-to-end available bandwidth estimation,” in Proc. 4th ACM/USENIX Internet Meas. Conf., Oct. 2005, pp. 272–277. [34] R. S. Prasad, M. Murray, C. Dovrolis, and K. Claffy, “Bandwidth estimation: Metrics, measurement techniques, and tools,” IEEE Netw., vol. 17, no. 6, pp. 27–35, Nov. 2003. [35] B. Melander, M. Bjorkman, and P. Gunningberg, “A new end-to-end probing and analysis method for estimating bandwidth bottlenecks,” in Proc. Global Internet Symp., Nov. 2000, vol. 1, pp. 415–420. [36] M. Jain and C. Dovrolis, “Pathload: A measurement tool for end-to-end available bandwidth,” in Proc. Passive Active Meas. Workshop, Mar. 2002, pp. 14–25. [37] V. Ribeiro, R. Riedi, R. Baraniuk, J. Navratil, and L. Cottrell, “pathChirp: Efficient available bandwidth estimation for network paths,” presented at the Passive Active Meas. Workshop, San Diego, CA, Apr. 2003. [38] D. Sisalem and H. Schulzrinne, “The loss-delay based adjustment algorithm: A TCP-friendly adaptation scheme,” in Proc. Netw. Oper. Syst. Support Digit. Audio Video, Jul. 1998, pp. 215–226. [39] R. Jain, “A delay-based approach for congestion avoidance in interconnected heterogeneous computer networks,” Comput. Commun. Rev., vol. 19, no. 5, pp. 56–71, 1989. [40] W. Dabbous, “Analysis of delay based congestion avoidance algorithm,” in Proc. High-Perform. Netw. IV, 1992, pp. 283–298. [41] Z. Wang and J. Crowcroft, “Eliminating periodic packet losses in the 4.3Tahoe BSD TCP congestion control algorithm,” Comput. Commun. Rev., vol. 22, no. 2, pp. 9–16, 1992. [42] S. Floyd and V. Jacobsen, “Traffic phase effects in packet-switched gateways,” Comput. Commun. Rev., vol. 22, no. 2, pp. 26–42, 1991. [43] J. M. Mendel, Uncertain Rule-Based Fuzzy Logic Systems: Introduction and New Directions. Upper Saddle River, NJ: Prentice–Hall, 2001. [44] Q. Liang and J. M. Mendel, “Interval type-2 fuzzy logic systems: Theory and design,” IEEE Trans. Fuzzy Syst., vol. 8, no. 5, pp. 535–550, Oct. 2000. [45] H. Hagras, “A hierarchical type-2 fuzzy logic control architecture for autonomous mobile robots,” IEEE Trans. Fuzzy Syst., vol. 12, no. 4, pp. 524–539, Aug. 2004. [46] J. Cao, H. Liu, P. Li, and D. Brown, “An interval type-2 fuzzy logic controller for quarter-vehicle active suspensions,” J. Automobile Eng., vol. 222, no. 8, pp. 1361–1374, 2008. [47] R. Sepulveda, O. Castillo, P. Melin, and A. Rodr´ıguez-D´ıaz, O. Montiel, “Experimental study of intelligent controllers under uncertainty using

[48] [49] [50] [51] [52] [53]

[54] [55] [56] [57] [58] [59] [60] [61]

[62] [63] [64] [65] [66] [67] [68] [69]

1141

type-1 and type-2 fuzzy logic,” Inf. Sci., vol. 10, no. 10, pp. 2023–2048, May 2007. P. Lin, C. Hsu, and T. Lee, “Type-2 fuzzy logic controller design for buck DC–DC converters,” in Proc. IEEE Int. Conf. Fuzzy Syst., Reno, NV, May 2005, pp. 365–2370. P. Melin and O. Castillo, “A new method for adaptive control of non-linear plants using type-2 fuzzy logic and neural networks,” Int. J. Gen. Syst., vol. 33, no. 2, pp. 289–304, 2004. D. Wu and W. Tan, “Type-2 fuzzy logic controller for the liquid-level process,” in Proc. IEEE Int. Conf. Fuzzy Syst., Budapest, Hungary, Jul. 2004, pp. 248–253. D. Wu and W. Tan, “Type-2 FLS modeling capability analysis,” in Proc. IEEE Int. Conf. Fuzzy Syst., Reno, NV, Apr. 2005, pp. 242–247. H. Wu and J. M. Mendel, “Uncertainty bounds and their use in the design of interval type-2 fuzzy logic systems,” IEEE Trans. Fuzzy Syst., vol. 10, no. 5, pp. 622–639, Oct. 2002. S. Greenfield, F. Chiclana, S. Coupland, and R. John, “The collapsing method of defuzzification for discretised interval type-2 fuzzy sets,” Inf. Sci., vol. 179, no. 13, pp. 2055–2069, 2009. DOI: 10.1016/j.ins.2008.07.011. P. A. A. Assunc¸a˜ o and M. Ghanbari, “A frequency domain video transcoder for dynamic bit-rate reduction of MPEG-2 bit streams,” IEEE Trans. Circuits Syst. Video Technol., vol. 8, no. 8, pp. 953–967, Dec. 1998. C. Kilian, Modern Control Technology. Boston, MA: Thompson Delmar, 2005. R. Babuska, Fuzzy Modeling for Control. Boston, MA: Kluwer, 1998. H. Lam and L. Senevirante, “Stability analysis of interval type-2 fuzzy model-based control systems,” IEEE Trans. Syst., Man, Cybern. B, Cybern., vol. 38, no. 3, pp. 617–628, Jun. 2008. K. Tanaka and H. Wang, Fuzzy Control Systems Design and Analysis. A Linear Matrix Inequality Approach. New York: Wiley, 2001. A. Sala and C. Arino, “Asymptotically necessary and sufficient conditions for stability and performance of fuzzy control: Applications of Polya’s theorem,” Fuzzy Sets Syst., vol. 158, no. 24, pp. 2671–2686, Dec. 2007. O. Castillo, L. Aguilar, N. Cazarez-Castro, and S. Cardenas, “Systematic design of a stable type-2 fuzzy logic controller,” J. Appl. Soft Comput., vol. 8, no. 3, pp. 1274–1279, Jun. 2008. N. Cazarez, O. Castillo, L. Aguilar, and S. Cardenas, “From type-1 to type-2 fuzzy logic control: A stability and robustness study,” in Hybrid Intelligent Systems (Studies in Fuzziness and Soft Computing), O. Castillo, P. Melin, J. Kacprzyk, and W. Pedrycz, Eds. Berlin, Germany: SpringerVerlag, Jul. 2007, pp. 134–149. B. Kosko, Fuzzy Engineering. Upper Saddle River, NJ: Prentice–Hall, 1996. M. Ghanbari, Standard Codecs: Image Compression to Advanced Video Coding. London, U.K.: IET Press, 2003. L. Breaslu, K. Estrin, D. Fall, S. Floyd, J. Heidemann, A. Helmy, P. Huang, S. McCanne, K. Varadhan, X. Ya, and H. Yu, “Advances in network simulation,” IEEE Comput., vol. 33, no. 5, pp. 59–67, May 2000. R. Jain, The Art of Computer Systems Performance Analysis. New York: Wiley, 1991. G. Ghinea and J. P. Thomas, “QoS impact on user perception and understanding of multimedia video clips,” in Proc. ACM Multimedia, Bristol, U.K., 1998, pp. 49–54. H. I. Ma, “Accelerated of power-law traffic in packet network,” Ph.D. dissertation, Queen Mary College, Univ. London, London, U.K., 2003. I. Rhee and L. Xu, “Limitations of equation-based congestion control,” IEEE/ACM Trans. Netw., vol. 15, no. 4, pp. 852–865, Aug. 2007. Y.-G. Kim, J. W. Kim, and C.-C. J. Kuo, “TCP-friendly Internet video with smooth and fast rate adaptation and network-aware error control,” IEEE Trans. Circuits Syst. Video Technol., vol. 14, no. 2, pp. 256–268, Feb. 2004. Emmanuel A. Jammeh graduated from the University of Essex, Colchester, U.K., in 2000, and received the Ph.D. degree from the University of Essex, Colchester, U.K., in 2005. He received a prestigious Commonwealth scholarship. He was a Senior Research Officer at the University of Essex. In 2008, he joined the University of Plymouth, Plymouth, U.K. His current research interests include network congestion control, video networking performance and measurement, and voice quality prediction and control for voice over internet

protocol services.

1142

Martin Fleury (M’08) received the B.A. degree in modern history from Oxford University, Oxford, U.K., the B.A. degree in mathematics/physics from the Open University, Milton Keynes, U.K., the M.Sc. degree in astrophysics from Queen Mary and Westfield College, University of London, London, U.K., in 1990, and the M.Sc. degree in parallel computing systems from the University of the West of England, Bristol, U.K., in 1991. He is currently with the School of Computer Science and Electronic Engineering, University of Essex, Colchester, U.K. He has authored or coauthored more than 130 articles and a book in the area of low-level image and signal processing algorithms (including document and image compression algorithms), performance prediction of parallel systems, software engineering, and vision systems.

Christian Wagner (M’06) was born in Luxembourg in December 1981. He received the B.Sc. degree in computer science and the M.Sc. degree in robotics and embedded systems from the University of Essex, Colchester, U.K., where he is currently working toward the Ph.D. degree with the School of Computer Science and Electronic Engineering. He was an intern and worked in summer jobs for SES-ASTRA, GE Fanuc Automation, Sun Microsystems, and Insearch Ltd. His current research interests include type-2 fuzzy logic, control applications, computational intelligence in general, embedded agents, robotics, and pervasive computing.

Hani Hagras (M’03–SM’05) received the B.Sc. and M.Sc. degrees in electric engineering from Alexandria University, Alexandria, Egypt, and the Ph.D. degree in computer science from the University of Essex, Colchester, U.K. He is currently a Professor with the School of Computer Science and Electronic Engineering, University of Essex, Colchester, U.K., where he is also the Director of the Computational Intelligence Center and the Head of the Fuzzy Systems Research Group. His current research interests include computational intelligence, notably type-2 fuzzy systems, fuzzy logic, neural networks, genetic algorithms, and evolutionary computation. He has authored or coauthored more than 150 papers in international journals, conferences, and books. Prof. Hagras has won numerous prestigious international awards, including the IEEE Computational Intelligence Society IEEE TRANSACTIONS ON FUZZY SYSTEMS Outstanding Paper Award for his work on type-2 fuzzy controllers.


Mohammed Ghanbari (M’78–SM’97–F’01) received the B.Sc. degree in electrical engineering from Sharif (Aryamehr) University of Technology, Tehran, Iran, and the M.Sc. degree in telecommunications and the Ph.D. degree in electronics from the University of Essex, Colchester, U.K. He is currently with the School of Computer Science and Electronic Engineering, University of Essex, Colchester, U.K. He is best known for his pioneering work on two-layer video coding for asynchronous transfer mode networks, now known as SNR scalability in the standard video codecs. He has authored or coauthored about 450 journal and conference papers. He is the coauthor of the book Principles of Performance Engineering (IET Press, 1997) and the author of the books Video Coding: An Introduction to Standard Codecs (IET Press, 1999) and Standard Codecs: Image Compression to Advanced Video Coding (IET Press, 2003). He has registered for 11 international patents on various aspects of video networking. Mr. Ghanbari was an Associate Editor of the IEEE TRANSACTIONS ON MULTIMEDIA from 1998 to 2004. He received the 2000 Best Book Award from the Institution of Electrical Engineers (IEE). He was the corecipient of the A. H. Reeves Prize for the best paper published in the Proceedings of the IEE on the theme of digital coding for 1995.

Effect of indoleacetic acid, abscisic acid, root tips and coleoptile tips on growth and curvature of maize roots.

Sterols in seeds and leaves of oats (Avena sativa L.).

Role of chloride ions in the promotion of auxin-induced growth of maize coleoptile segments.

Spectrophotometric phytochrome measurements in light-grown Avena sativa L.

The limit dextrinases from ungerminated oats (Avena sativa L.) and ungerminated rice (Oryza sativa L.).

[The influence of high pressure on the 3-indoleacetic-acid-induced curvature of Avena coleoptiles in the Went-test].

Ethylene-induced inhibition of root growth requires abscisic acid function in rice (Oryza sativa L.) seedlings.

Comparison of calcium and lanthanon Ions in the Avena-coleoptile growth test.

Protein synthesis and wall extensibility in the Avena coleoptile.

Totipotency of coleoptile tissue in indica rice (Oryza sativa L. cv. ch 1039).

Some observations on coleoptile cell ultrastructure in ungerminated grains of rice (Oryza sativa L).

Genome-Wide Association Mapping of Barley Yellow Dwarf Virus Tolerance in Spring Oat (Avena sativa L.).

Ecogeographical distribution and differential adaptedness of multilocus allelic associations in Spanish Avena sativa L.

Geotropic curvature of decapitated Avena coleoptiles after application of tips of maize roots, tips of Avena coleoptiles, indoleacetic acid, or abscisic acid.

The role of separate molecular domains in the structure of phytochrome from etiolated Avena sativa L.

Tissue-distribution of secondary phenolic biosynthesis in developing primary leaves of Avena sativa L.

Immunolocalization of avenin and globulin storage proteins in developing endosperm of Avena sativa L.

Polymorphism analysis in advanced mutant population of oat (Avena sativa L.) using ISSR markers.

Effects of magnesium, calcium and lanthanum ions on stomatal oscillations in Avena sativa L.

Spatial distribution of three phytochromes in dark- and light-grown Avena sativa L.

Analysis of genetic changes in radiated and non-radiated bulk oat (Avena sativa L.) populations.

Lateral diffusion of polarly transported indoleacetic acid and its role in the growth of Lupinus albus L. hypocotyls.

Efficient callus formation and plant regeneration from leaves of oats (Avena sativa L.).

Callus formation and plant regeneration from somatic embryos of oat (Avena sativa L.).