Qos in Internet for Media Streaming by UDP

7/26/2019 Qos in Internet for Media Streaming by UDP

1/4

Computer Networks 15129145

1

BJTU

BEIJING JIAOTONG

UNIVERSITY

Qos in Internet for Media

Streaming by UDP

Submitted To:

Professor: Zhang Jinyu

Submitted By:

Name: Muhammad Waqas Moin Sheikh

Student Id: 15129145

University: Beijing Jiaotong University

Department: ComputerApplicationTechnology


2/4


2

BJTU

1. Abstracts

Delivering real-time video over the Internet is an important issue for many Internet multimedia

applications. Transmission of real-time video has bandwidth, delay, and loss requirements. The

application-level quality for video streaming relies on continuous playback, which means that

neither buffer underflow nor buffer overflow should occur. Since the Best Effort network such as the

Internet does not provide any Quality of Service (QoS) guarantees to video transmission over the

Internet. Thus, mapping the application-level QoS requirements into network-level requirements,

namely, limited delay jitters. End-to-end application level QoS has to be achieved through

adaptation. Since the QoS of video streams over IP networks depends on several factors such as

video transmission rate, packet loss rate, and end-to-end transmission delay. The objectives is to

simulate an adaptation scheme to include the effect of User Datagram Protocol (UDP) parameters

on delay jitter and datagram loss values to increase the efficiency of UDP protocol to prevent the

network congestion and increase the adaptively.

2. Introduction

Multimedia is any combination of text, graphics, audio, video, animation and data. Multimedia

applications over the Internet include Video on Demand (VoD), interactive video, and

videoconferencing. However there are limitations to these applications, as it is often required that a

multimedia file be completely downloaded before it can be played or viewed. Streaming is the ability

to start processing data before all of it has arrived, thus making delivery in real-time or near real-

time possible. Streaming technologies are designed to overcome the problem of limited bandwidth.

The implication of this is that multimedia files of any size can be played/displayed over the Internet

in real-time or near real-time. To date, there has been no definitive way to transmit streamed

MPEG-4 files across the Internet with an associated Quality of Service. One possibility is to write a

control protocol on top of TCP/IP, which manages the flow of multimedia data [1]. In this report, an

alternative approach using a protocol stack comprising a Real-time Transport Protocol (RTP) layer

over a User Datagram Protocol (UDP)/Internet Protocol (IP) layer is described. Providing QoS

guarantees is difficult or impossible in networks that offer "best effort" service, such as the

Internet's IP layer. Therefore a lot of work has been carried out recently on how to add QoS supportto the Internet service model. Examples of this include the intserv (Integrated Services) and diffserv

(Differentiated Services) approaches. The RTP/RTCP approach is an attempt to add QoS support

mechanisms above the Transport layer (TCP or UDP). However the use of RTCP messages to provide

and maintain QoS guarantees to multimedia streams.


3/4


3

BJTU

3. RTP/RTCP(RealtimeTransportProtocol/ RTPControlProtocol)

Usually RTP (Real time transport protocol)runs on top of another transport layer protocol - most

often the User Datagram Protocol (UDP). RTP is used in conjunction with the Real-time TransportControl Protocol (RTCP). While RTP carries the media streams (audio or video), RTCP monitor

transmission statistics and quality of service information, that is Real-Time Control Protocol (RTCP)

provides feedback on the transmission and reception quality of data carried by RTP.

4. ExtensiontotheRTP/RTCPpayloadformattypeenablingQos.

The main objective to adapt RTP is to lower delay requirements for streaming applications by making

RTP more reliable, in a sense emulating TCP through selective re-transmissions. In order to realise

the existing RTP/RTCP payload format must be modified slightly. The underlying transport protocol

chosen is UDP/IP (user datagram protocol/internet protocol) which is extremely unreliable and is

susceptible to severe packet loss when transmitting compressed MPEG video streams in congested

networks. One simple solution is to use increased redundancy by sending multiple copies of data

packets; however this adds an extra load on the network. Another solution using retransmission of

all lost packets is unsuitable for real-time or near real-time streams, as retransmitting causes

additional propagation delays and also increases the load on the network.

5. UsingRTPasatransportmechanismforMPEG-4FlexMuxstream

MPEG-4 applications can involve a large number of ESs and thus a large number of RTP sessions.

Allowing a selective bundling scheme or multiplexing of ESs may be necessary for certainMPEG-4

applications. MPEG-4 FlexMux streams can be synchronised with other RTP payloads. MPEG-4

FlexMux streams and other real-time data streams can be combined into a set of consolidated

streams through the use of RTP mixers and translators. The delivery performance of the MPEG-4

stream can be monitored via the RTCP control channel. An MPEG-4 FlexMux stream is mappeddirectly to the RTP payload without any addition of extra header fields or the removal of any

FlexMux packet header. Each RTP packet contains a sender clock reference timestamp that is used to

synchronise the FlexMux clock. On the client side, the Flex DE multiplexor does not make use of the

RTP timestamp. The purpose of the RTP timestamp is to determine the network jitter, and

propagation delay between server and client. An RTP packet should begin with an integer number of

FlexMux packets.


4/4


4

BJTU

6. Conclusion

The current version of the system is capable of creating and transmitting the MPEG-4 stream file

using a RTP/UDP/IP transport stack to a client. The next stage is to harness and exploit the

characteristics of both the transport media and MPEG-4 so as to implement QoS parameters. The

extensions to the RTP and RTCP packets have yet to be implemented with the intended purpose of

implementing selective retransmission into the system [9]. The extended RTP and RTCP packets are

to be used to monitor that the client receives all essential packets i.e. the PR bit is set to one.

Currently, the server assumes that the marker bit and the priority bits are equal. The server can

transmit according to different transmission profiles as defined by the status variable; however it is

unable to dynamically change the transmission profile dynamically within the session. Also, research

must be done to identify what characterises and constitutes a change in transmission profile. For

example, when should the server resort to prioritised transmission of high priority packets, or when

should it adopt transmission redundancy to send high priority packets? Ideally, prioritised encodingtransmission (PET) should be adopted when the MPEG-4 file is encoded in real-time; however, in the

system implemented, encoding of the MPEG-4 file is offline.

7. References

[1] Nicola Cranley*, Ludovic Fiard, Liam, Quality of Service for Streamed Multimedia the Internet

[2] G. Muntean and L. Murphy, An Object-Oriented Prototype System for Feedback

Controlled Multimedia Networking, submitted to ISSC 2000

[3] http://datatracker.ietf.org/wg/payload/documents/

[4] RFC 1889: RTP: A transport protocol for Real Time Applications

[5] RFC 1890: RTP profile for Audio and Video Conference with Minimal Control

[6] Internet draft: draft-podolsky-avt-rtprx-00.txt

A RTCP based Retransmission Protocol for Unicast RTP Streaming Multimedia

Documents

Qos in Internet for Media Streaming by UDP