CC BY
47
Хашковский Валерий Валерьевич - Южный федеральный университет; e-mail: vkhashkovsky@sfedu.ru; 347928, г. Таганрог, пер. Некрасовский, 44; тел.: 88634371746; кафедра математического обеспечения и применения ЭВМ; к.т.н.; доцент.
Шкурко Алексей Николаевич - e-mail: anshkurko@sfedu.ru; кафедра математического обеспечения и применения ЭВМ; к.т.н.; доцент.
Khashkovsky Valery Valer'evich - Southern Federal University; e-mail: vkhashkovsky@sfedu.ru; 44, Nekrasovskiy, Taganrog, 347928, Russia; phone: +78634371746; the department of software engineering; cand. of eng. sc.; associate professor.
Shkurko Alexey Nikolaevich - e-mail: anshkurko@sfedu.ru; the department of software engineering; cand. of eng. sc.; associate professor.
УДК 004.4, 004.7
Е.А. Пакулова
РАСПРЕДЕЛЕНИЕ МУЛЬТИМЕДИА-ТРАФИКА В ГЕТЕРОГЕННОЙ
СЕТИ
Целью работы являлась разработка алгоритма распределения трафика мультимедиа в гетерогенной сети. В основу предлагаемого алгоритма легла идея распределения отправленных бит по нескольким потокам с максимально возможной пропускной способностью, что позволяет агрегировать пропускную способность нескольких сетей доступа и снизить потери. Предложенное решение позволяет использовать несколько беспроводных технологий связи в условиях недостаточной пропускной способности. Кроме того, в статье проведен анализ существующих решений, выделены их недостатки. В заключении описан прототип системы, основанный на использовании WLAN (IEEE 802.11g) и LAN, и даны результаты экспериментального исследования алгоритма.
Распределение трафика; агрегация пропускной способности; снижение потерь.
Е.А. Pakulova
MULTIMEDIA-TRAFFIC ALLOCATION OVER MULTIPLE PATHS IN HETEROGENEOUS NETWORK
The main purpose of a project was development of Sender-Side Path Scheduling (SSPS) algorithm. The main idea of proposed algorithm is sending bit rate allocation through several paths with maximum available bandwidth. Thus it allows to aggregate bandwidth of several access networks and reduces losses. The proposed algorithm can be used with several wireless technologies and under throughput restrictions. Also the survey of existing method was done. At the current stage of an investigation the prototype of a simple system for transmission multimedia traffic was build (on the basis of WLAN (IEEE 802.11g) and LAN).
Traffic allocation; bandwidth aggregation; losses reduction.
Introduction. The use of a wide range of sophisticated personal wireless devices is becoming commonplace in society. According to the paradigm "Always Best connected" [1] users of such devices demand to be able to use their full capabilities anywhere and anytime in everyday life. At the same time providers of wireless networks offer us various technologies for data transmission. These technologies differ in terms of services: QoS characteristics (throughput, packet loss rate and latency), pricing, coverage and etc. One of the most common service is transmission of high quality video content. According to the "Cisco Visual Networking Index: Forecast and Methodology" video transmis-
sion will compose 80%-90% of total consumer traffic in 2017 [2]. However wireless networks still can't offer high throughput and low losses on paths [3]. So the task of transmission of high video quality content (which requires high QoS characteristics) through wireless networks is still actual issue.
One of key approaches to achieve better characteristic for transmission of high video quality content is the integration of different access technologies (including wireless) to form a heterogeneous network. In a heterogeneous network, consumers with multi-interfaces(multimode) terminals can toggle between different technologies and select the technology that best suits the characteristics and requirements of their applications. If there is no single technology that offers suitable characteristics to meet the application's requirements, two or more access technologies can be selected [3].
The use of multiple technologies simultaneously opens new way of addressing some of the limitations of wireless media and can enable other new possibilities [4].
♦ Bandwidth Aggregation. Bandwidth offered by the multiple technologies can be aggregated to improve quality or support demanding applications that need high bandwidth.
♦ Mobility Support. The delay associated with handover, e.g., between IEEE 802.11 access points, between IEEE 802.11 access points and mobile network base station and etc., can be significantly reduced when an alternate communication path is always kept alive.
♦ Reliability. For applications requiring strict reliability guarantees, some or all packets can be duplicated/encoded and sent on the multiple paths.
♦ Load balancing. The ability to use more than one access technology simultaneously helps to ease load on the one particular link by dispersing traffic over several links. The load can be distributed among available paths [3].
We propose the Sender-Side Path Scheduling algorithm (SSPS), which considers the issues of bandwidth aggregation and reduction of packet losses. The main task of SSPS is video rate allocation to the appropriate paths. It is enabled by simultaneous usage of multiple interfaces. It means that all paths consider various interfaces. SSPS should allocate to each path no more traffic than it can transmit. It prevents packets losses on a path using spare capacity on all paths.
For realization of such services we need architecture to support multiple communication paths. The proposed architecture is presented in section 2.
We analyze performance difference between SSPS and simple Round Robin algorithm in terms of several metrics: number of late (discarded) frames, number of lost frames (Frame Loss Rate) and bandwidth utilization. The experimental results are presented in section 5.
It is supposed that SSPS shows less frame loss than simple Round Robin algorithm.
1. Related works. A number of schemes have been proposed for path scheduling in heterogeneous network in recent years. Most of them are dedicated to the problem of bandwidth aggregation. This task can be addressed at different layers of network protocol stack: application, transport, network and link layer [3].
The most notable bandwidth aggregation solution is the earliest delivery path first (EDPF) scheduling proposed by Chebrolu and Rao [4]. They proposed to estimate arrival time at a client using network metrics of available bandwidth and delay on each path and the size of each packet. EDPF sends a packet always on a path with the earliest arrival time, thus reducing out of sequence delivery. However EDPF doesn't consider packet loss rate and it uses only one interface at time to transmit packets.
D. Jurca and P. Frossard at [5] proposed the heuristic load balancing algorithm (LBA) which performs packets transmission on a path only in case if arrival time of a packet less than it's decoding deadline. If a packet cannot be decoded it is dropped. Ad-
ditionally they suggested packets prioritization scheme which gives higher weights to I-frames over B or P frames. The LBA scheduler sorts packets according to priority weighting, and sacrifices lower priority packets to ensure the delivery of those with a higher priority. However their solution doesn't consider SVC full scalability and it is target at wired networks and doesn't address mobility issues.
V. Singh, A. Ahsan and J. Ott in [6] proposed multipath solution for real-time media. For implementation of their solution they use Multipath transport protocol for realtime applications (MPRTP) [7]. Using RTCP RR packets and obtaining PLR on each path they distinguish congested, mildly-congested and non-congested paths. Based on this division and available bandwidth values of paths the solution calculates sending bit rate for each path starting from congested paths. Additionally they also proposed algorithm for control of dejittering buffer on a receiver side so that the algorithm can tune to alter paths characteristics and reduce playout delay. However this solution doesn't consider video adaptation techniques.
The best survey of bandwidth aggregation techniques was proposed by Ramboly, Falowo and Chan [3]. They gave a classification of bandwidth aggregation solution in heterogeneous wireless network and made comparison analysis of many proposed solutions for bandwidth aggregation.
There are also a lot of other issues of transmission data quality improvement in wireless networks. Security issues, for one. However it is the big field of investigations and it is discussed in other papers [8]. This topic is out of a scope of this article.
2. Architecture. We proposed solution for video streaming in heterogeneous network. Figure 1 shows a high-level overview of the proposed architecture. It is supposed that streaming video applications with low-delay and no possibility for packet retransmission is used. So we use UDP streaming strategy.
Fig. 1. Structure of the system
At the proposed architecture sender and receiver can be connected through several various paths which are differ in access technology. The collaboration of different technologies is supported by MPRTP [7].
MPRTP is similar to Transport protocol for Real-Time Applications (RTP) [9], which is suitable for delivery of real-time traffic. MPRTP allows to split a single RTP stream into multiple sub-flows, which are transmitted over different paths. MPRTP as well as RTP provides timing information, identification of a source and the payload type of an application with the help of RTP control protocol (RTCP). RTCP is based on the periodic transmission of control packets to all participants in the session, using the same distribution mechanism as the data packets. The primary function of RTCP is to provide feedback on the quality of the data distribution. The specification of RTCP defines several RTCP packet types to carry a variety of control information [9]. But we distinguish only two of them:
♦ SR: Sender report, for transmission and reception statistics from participants that are active senders;
♦ RR: Receiver report, for reception statistics from participants that are not active senders. They are receivers.
MPRTP extends RTP and allows to use multiple paths providing RTCP monitoring functions for each separated path. The RTCP packets are sent periodically by each endpoint in multicast fashion to the other participants. The more there are participants the more RTCP messages should be exchanged. However according to [7] the total RTCP rate between the participants must not exceed 5% of the media rate. The strategy of RCTP interval calculation should be taken into consideration. We implemented the strategy from [7]. MPRTP provides convenient mechanism for paths collaboration; however it doesn't make decisions about suitable for data transmission paths.
3. Sender-Side Path Scheduling algorithm (SSPS)
3.1. Paths characterization. Based on RTCP RR packets SSPS obtains the following information about a path on the sender side:
♦ Fraction Loss Rate (FLR)
♦ Packet Loss Rate (PLR);
♦ Delay since last RTCP SR packet.
Considering FLR values for a path we can distinguish congested and non-congested paths. A path that reports losses can be considered as congested. A path without losses is considered as non-congested path.
Using this information and information from sender side we can calculate bandwidth for each path.
Let us provide some details of FLR and bandwidth per path.
Fraction Loss Rate
The Fraction Loss Rate provides a short term measurement since the previous SR or RR RTCP packet was sent.
The sender calculates FLR as
FL R = J^, (1)
where NE - number of packets expected, NL - number of packets lost.
Number of packets expected can be computed by the end point as the difference between the last sequence number received and the first sequence number received. The number of packets received is simply the count of packets as they arrive, including any late or duplicate packets. The number of packets lost is defined to be the number of packets expected less the number of packets actually received [9]:
Nl = exp e c te d — re ce ive d. (2)
Packet Loss Rate
The Packet Loss Rate provides a long term measurement. It is the ratio between the cumulative number of packets lost and the cumulative number packet sent. It is calculated by the sender side and characterize the path by the end of the session.
Bandwidth
The bandwidth per the path calculates by the sender using information from two consecutive RTCP RR. The bandwidth of path j when receiving the i RR is
g _ payload-( 1 -FLR) J = t i -t i _ ! , ( ) where p ay I o a d is number of bits sent between two consecutive RRs; t t t _ 1 are the reception times of the two RRs at the sender.
3.2. Path scheduling. The main task of path scheduling is sending bit rate allocation through paths which show no or minimum losses. Thus we can achieve reduction of packet losses. Since packets can be spread between several paths SSPS allows to aggregate bandwidth from various technologies. It can be rather essential for high throughput required video streaming applications.
We suggested the following scheme for path scheduling. Every time new frame arrives to a scheduler its packets offers the suitable paths according to the relative traffic allocation. Using RTCP packets a scheduler can monitor the condition of paths. It also saves all information about paths into a sliding window. This sliding window renews for every path after scheduling interval (the question of path scheduling interval calculation is considered below). Based on information in sliding window scheduler determines maximum available bandwidth for each path. Based on information about available bandwidth for each path SSPS allocates to them as much packets as possible.
It is important to note that SSPS allocates packets on paths and not frames since it is more flexible for scheduling and fairness from load balancing point of view.
3.2.1. Initial phase. Since scheduler knows nothing about characteristics of paths initially it allocates the same traffic to each path. As soon as it gets enough information about the paths characteristics, it should recalculate the fraction distribution for paths.
At initial phase SSPS hasn't any RTCP RR packets. After receiving the first RTCP RR packet the algorithm calculates bandwidth for a path in a following way:
g _ payload ■ ( 1 -PLR) i = t^tl , ( ) where is initial time of RTP packet transmission and is time of receiving the first RTCP RR packet.
3.2.2. Scheduling phases. The SSPS algorithm is represented on Figure 2. After receiving RTCP RR packet SSPS distinguishes congested and non-congested paths. After that it remembers bandwidth values for each path into a sliding window ( ). Then it calculates values of average bandwidth for appropriate paths based on the values from sliding window (see line 9 in Algorithm 2). It calculates average bandwidth only for paths that show losses or for non-congested paths whose bandwidth values are higher than the average bandwidth from sliding window for these paths.
Then SSPS sorts values of average bandwidth of all paths (see line 12 in Algorithm 2) and defines the Sending bit rate for paths starts from paths with minimum average bandwidth. Sending Bit rate for a path calculates as a ratio of average bandwidth of this path to aggregated average bandwidth from all paths multiples by remaining video rate. Thus we calculate sending bit rate for all possible paths.
So SSPS allocates video information to the paths starting from the paths with minimum sending bit rate. We do that because we want to get information from all paths including congested.
If SSPS has defined bandwidth for all possible path but it is still not enough for allocation of all Video rate scheduler allocates additional bit rate to non-congested paths until all video rate won't be allocated (lines 21-29 in Algorithm 2). However if all paths are congested SSPS allocates packets also to those paths.
Path scheduling interval
Based on the calculation of RTCP interval and idea from [7] we calculate path scheduling interval as:
hch = . 5< 1 . 5 , (5)
where /3 is a coefficient which prevents synchronization of several senders with common network paths. is RTCP interval.
Require: RTCP_BR i- information from RTCP RR packets about bandwidth. IB,), packet loss rate (PLR,) for
4: AvB A wt of vaines of Average bandwidth, for all
{where Mi is a number of bandwidth values fur path
12: S AvB — Sorti AvB) for AvB values (from min to max) {each element of S AvB characterizes by average band-
Fig. 2. Sender Side Path Scheduling algorithm
Sliding window renewal interval
Since network condition is always changing it is important to consider network characteristics in some period of time and smooth them in time. For that reason we propose to use sliding window for storage of characteristics of paths. This window should reflect the current conditions of a network. Thus we should renew information in a sliding window after every n RTCP RR packets.
Currently we suggest to use only 5 receiver reports in a sliding window. If a number of packets in this window is more than 5 the first packet in a window is deleted.
4. Experiment evaluation
4.1. Implementation details. We implemented a prototype of set-up. The Sender and the Receiver are connected through two interfaces: WLAn (IEEE 802.11g) and LAN (Ethernet). Collaboration of both sides is provided by MPRTP implementation using different IP addresses for RTP and RTCP streams. For the experiment we used Big Buck Bunny MPEG 4 video (H.264, 1024*576, 24fps, 460kbps) and rtpdump tool [10].
The SSPS algorithm has been implemented as user-mode program. It uses MPRTP implementation as a framework. The results of the program are transmitted rtpdump file and log files which store information about paths characteristics (bandwidth, payload, PLR) from each RTCP RR packet and information about packets allocation to paths. We also convert rtpdump file to MPEG4 using rtp tools and VCL.
4.2. Metrics evaluation. For performance evaluation of the developed algorithm we use the following characteristics:
♦ number of late (discarded) frames;
♦ number of lost frames (Frame Loss Rate).
We made comparison with Round Robin algorithm. Now we are in the process of comparison evaluation of proposed algorithm with [4] and [6].
5. Experimental results. We compare SSPS algorithm with Round Robin algorithm. Proposed algorithm allows to avoid any losses if there is only one access technology (fig.2) while Round Robin shows 50\% of losses (fig.3). We can see that bitrate with SSPS is about 500 kbit/s while it is 250 kbit/s with Round Robin. However it shows losses in case of reduction (up to 100 bkit/s) of throughput on the one of interfaces (fig.4). But these losses are lower by one third than losses of Round Robin. It is shown on fig.5 that SSPS adapts bitrate to throughput.
So SSPS allows to adapt bitrate to network condition, however it is necessary to compare proposed technique with [4] and [6].
Conclusions. In this paper we proposed Sensed-Side Path Scheduling algorithm for transmission multimedia traffic through network with throughput constrains. Our algorithm provides bandwidth aggregation, sending bit-rate adaptation to network conditions and packet losses reduction. We built 2 interfaces set-up and made a set of experiment. We show that proposed algorithm allows to adapt sending bit-rate to traffic limitation reducing losses. Further, we plan to develop Sender-Side Adaptation algorithm which will allow to dynamically adapt video bit rate to network conditions.
SOCOOO
800000
700000
£ 500000
J 500000
~ +00000 E
g 300000 200000 100000 o
O 4 a 12 IS 20 24 2S 32 35 40 44 4S 52 Time of receiving RTCP FlR packets, sec
Fig. 2. Result of SSPS. Bandwidth on the path in case of absent of one interface
600030,00
500000,00
S 400000,00 fi
J 300000,00
Щ '
£
g 200000,00 100000,00 0,00
О 4 В 12 16 20 24 28 32 36 40 44 4Я 52 Time of receiving RTCP RR packets, sec
Fig. 3. Result of Round Robin. Bandwidth on the path in case of absent of one interface
bandwidth, pathl bandwidth, path2
BO DO 00,00 a 400000,00
CJ <
a 300000,00 | 200000,00
S _
100000,00 ——■■ .....-¡77 - ..........
0,00 ...........................
1 3 5 7 B 11 13 15 17 19 21 23 25 27 Time of receiving RTCP RR packets, sec
Fig. 4. Result of SSPS algorithm. Bandwidth on the path in case of400 kbit/sec (path 1) and 100 kbit/sec (path 2) throughput reduction
Fig. 5. Result of Round Robin. Bandwidth on the path in case of400 kbit/sec (path 1) and 100 kbit/sec (path 2) throughput reduction
Acknowledgments
This work was supported by the German Academic Exchange Service.
БИБЛИОГРАФИЧЕСКИЙ СПИСОК
1. Gustafsson E., Jonsson A. Always Best connected // IEEE Wireless Communications. - 2003.
- Vol. 10, Issue 1, February. - P. 49-55.
2. Cisco Visual Networking Index: Forecast and Methodology, 2012-2017. May 2013.
3. Ramboli A.L., Falowo O.E., Chan A.H. Bandwidth aggregation in heterogeneous wireless networks: A survey of current approaches and issues // Journal of Network and Computer Applications. - 2012. - No. 35, May. - P. 1674-1690.
4. Chebrolu K. and Rao R.R. Bandwidth Aggregation for Real-Time Applications in Heterogeneous Wireless Networks // IEEE Mobile Transactions on Mobile Computing. - April 2006.
- Vol. 5, No.4. - P. 388-403.
5. Jurca D. and Frossard P. Video Packet Selection and Scheduling for Multipath Streaming // IEEE Transactions on Multimedia. - April 2007. - Vol. 9, No. 3. - P. 629-641.
6. Singh V., Ahsan A. and Ott J. MPRTP: Multipath Considerations for Real-time Media // MMSys '13, Proceedings of the 4th ACM Multimedia Systems Conference, February 26-March 1, 2013.
- P. 190-201.
7. Singh V., Karkkainen T, Ott J. and Ahsan S. Multipath RTP (MPRTP), 2012. IETF Draft, draft-singh-avtcore-mprtp.
8. Абрамов Е.С., Басан Е.С. Разработка модели защищенной кластерной беспроводной сенсорной сети // Известия ЮФУ. Технические науки. - 2013. - № 12 (149). - C. 48-56.
9. Schulzrinne H., Casner S., Frederick R. and Jacobson V. RTP: A Transport Protocol for RealTime Applications., RFC 3550, 2003.
10. Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF), RFC 4585.
REFERENCES
1. Gustafsson E., Jonsson A. Always Best connected, IEEE Wireless Communications, 2003, Vol. 10, Issue 1, February, pp. 49-55.
2. Cisco Visual Networking Index: Forecast and Methodology, 2012-2017. May 2013.
3. Ramboli A.L., Falowo O.E., Chan A.H. Bandwidth aggregation in heterogeneous wireless networks: A survey of current approaches and issues, Journal of Network and Computer Applications, 2012, No. 35, May, pp. 1674-1690.
4. Chebrolu K. and Rao R.R. Bandwidth Aggregation for Real-Time Applications in Heterogeneous Wireless Networks, IEEE Mobile Transactions on Mobile Computing, April 2006, Vol. 5, No. 4, pp. 388-403.
5. Jurca D. and Frossard P. Video Packet Selection and Scheduling for Multipath Streaming, IEEE Transactions on Multimedia, April 2007, Vol. 9, No. 3, pp. 629-641.
6. Singh V., Ahsan A. and Ott J. MPRTP: Multipath Considerations for Real-time Media, MMSys '13, Proceedings of the 4th ACM Multimedia Systems Conference, February 26-March 1, 2013, pp. 190-201.
7. Singh V., Karkkainen T., Ott J. and Ahsan S. Multipath RTP (MPRTP), 2012. IETF Draft, draft-singh-avtcore-mprtp.
8. Abramov E.S., Basan E.S. Razrabotka modeli zashchishchennoy klasternoy besprovodnoy sen-sornoy seti [Development of the model is protected clustered wireless sensor networks], Izvestiya YuFU. Tekhnicheskie nauki [Izvestiya SFedU. Engineering Sciences], 2013, No. 12 (149), pp. 48-56.
9. Schulzrinne H., Casner S., Frederick R. and Jacobson V. RTP: A Transport Protocol for RealTime Applications., RFC 3550, 2003.
10. Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF), RFC 4585.
Статью рекомендовал к опубликованию д.т.н., профессор Я.Е. Ромм.
Пакулова Екатерина Анатольевна - Южный федеральный университет; e-mail: epakulova@sfedu.ru; 347928, г. Таганрог, ул. Чехова, 2; тел.: +78634371905; кафедра безопасности информационных технологий; инженер.
Pakulova Ekaterina Anatol'evna - Southern Federal University; e-mail: epakulova@sfedu.ru; 2, Chekhova street, Taganrog, 347928, Russia; phone: +78634371905; the department of security in data processing technologies; engineer.
