Video Applications Quality Improvement in Wireless Systems: QoS Negotiation and Rate Control Zeina Jrad LIPN Laboratory, University of Paris13 99 Avenue J-B Clément, 93430 Villetaneuse, France
[email protected]
Rim Hammi Institut Galillée, University of Paris13 99 Avenue J-B Clément, 93430 Villetaneuse, France
[email protected]
Abstract Internet was based on simple principles, providing only one best-effort service, i.e. without any delay or packet loss guarantee. This service is sufficient for applications such as electronic mail which have no real time constraints. However, video communication needs to be monitored and adapted when it traverses best-effort environment. The transmission of a continuous flow, like streaming video, witness very strict time constraints. That’s why we need services adapted to specific application needs with a guaranteed QoS (Quality of Service). This paper presents a context-aware mechanism for the improvement of the wireless video applications quality. This can be done by negotiating the desired QoS between the user terminal and the network entities and by adapting the video communication's rate to the channel's current situation. The decision regarding the needed QoS parameters and the rate control is based on context information (user’s profile, applications needs and network monitoring).
1. Introduction In recent years, the development and the apparition of real time applications as well as multimedia applications have witnessed an exponential increase. The real time constraints of these applications present a big challenge for their integration. That’s why we need services adapted to specific application needs with a guaranteed QoS [18]. However, most applications cannot dynamically express their QoS requirements to obtain the adapted level of service. There are some protocols that allow the dynamic negotiation [3], [5] and [17] of the required level of service and the needed quality between the user and the network entities. However, this negotiation seems to be complex because the user has to indicate
Francine Krief LaBRI Laboratory, UMR CNRS 5800 University of Bordeaux I, cours de la Libération, 33400 Talence, France
[email protected]
himself the technical parameters that reflect the required quality of service. The difficulty of the process can be reduced by replacing the user in finding applications needs in terms of QoS parameters according to the context of use. On the other hand, real time constraints of applications like video-phone, videoconference, audio and video cause many problems for their integration into networks using the IP protocol. One major point is the lack of an acceptable quality when the video communication goes across the wireless Network. The problem could be solved by adapting the video communication rate to the channel current situation with an adequate and responsive regulation mechanism. This paper presents a context-aware mechanism for the improvement of the wireless video applications quality. This can be accomplished by studying the context of a user. This includes i) his preferences on quality and price, ii) his profile (indicating whether he is mobile or not), iii) the needs and the requirements of video applications, iv) feedback information on the network capacities and the effective perceived quality of the video data. These information of context will be used in: -
-
Negotiating dynamically the needed level of quality of service between the user terminal and the network entities. Providing a responsive control of wireless video communication. The mechanism is based on a couple of java agents that supervise the state of the link and propose an adequate regulation of the video flow. They calculate the critical parameters of transmission including the loss rate, delay, jitters, as well as bandwidth and video throughput, needed for the negotiation.
0-7695-2650-0/06/$20.00 (c) IEEE
Both of these issues are central to the success of realtime applications and indicative of the need for closer cooperation between the application and the network, cooperation that needs to be further promoted. Good end-to-end application performance should become a task shared by the network and the application. The paper is organized as follows. Section 2 and 3 give an overview of video communications over the wireless network as well as the control of the quality. Section 4 presents the various components of the proposed framework. Finally, section 5 concludes this paper.
2. Real-time video Communication
applications:
The handling of video communications is still a focus of investigation with today's cellular networking infrastructure, like GSM-GPRS, UMTS [2], [7], or CDMA-2000 [10]. This is because video traffics are real-time, burst and (selectively) sensitive to loss, and so need to be handled with a minimum of QoS control. The generic architecture for multimedia traffic in mobile terminals has been standardized in H.324 [19] and [15], the key element for traffic handling is the use of RTP/RTCP [24], H.245 control [21] and H.223 multiplex [20]. H.324 was primarily established by the ITU-T for low bit-rate circuitswitched modem links [15]. Error prone extensions for mobile circuit switched low bit-rate conversational services have been later added. For IP-based packet-switched communication, 3GPP has chosen to use SIP and SDP for call control [25] and RTP for media transport [23]. Future wireless multimedia applications will likely work over an open, layered, Internet-style network with a wired backbone and wireless extensions. The protocol RTP is mainly designed to deliver the video bitstreams with synchronized audio from a server to a terminal. It provides end-to-end transport functions and insures the integrity of the video stream. This is achieved through some fields in the RTP-header: •
The field Sequence Number (NS) is used to detect packet loss or out-of-order packets, in order to re-build, at the receiver side, the original order.
•
The field Timestamp (TS) temporal position of the communication, it can be packet belong to the same the same timestamp).
is used to give the data. For video used to identify a image (which share
One of the central problems of video traffic handling is to achieve QoS control. The RTCP, the companion protocol of RTP, is mainly designed to yield QoS feedback. This is done through information (called report) exchange among sender
and receiver(s). Sender gives the current characteristics of the traffic (number of packets sent identity of the last packet, etc.). Receivers maintain and return to sender statistics such as packet loss ratio since the last report, packet inter-arrival jitters, etc. The sender gets and diffuses all of these reports, so that every entity has an updated vision of the network performances. In practice, the overall bandwidth consumption of RTCP is limited to 5%, this limits also the dynamic of the information feedback and dispatch. The paradigm RTP/RTCP is generic for all multimedia traffic. Each type of traffic is identified by a (range of) Payload Identifier and has its own profile. The latter defines a kind of specialised secondary header to be put between the RTP header and the data, it defines also the specific fragmentation and transmission rules.
3. Real-time video applications: control of the quality of a video transmission Generally speaking, the control of the quality of a video communication has to be defined by the application, which follows the so-called end-to-end paradigm. A number of generic issues have been identified (cf. for instance [6]). The central problem is to achieve QoS control by minimizing congestion problem as well as error (loss) problems. The congestion control can be achieved through traffic filtering. The goal of traffic filtering is to adapt a video traffic to a given link capability, this can be done, in the MPEG2 case for example, by dropping B-frames and/or P-frames. Another possible way to achieve traffic filtering is the transcoding, either from one format to another or by modifying DCT quantification coefficients; this approach can be however very processing resource demanding and thus is not efficient with today's technology. Yet another approach is the layered (hierarchical) coding, which provides a video stream via one base stream, and several enhancing substreams. This is provided for instance by the H.263+ [22] option "O" which is capable of providing scalable video streams depending on temporal and/or spatial resolution, or even in function of SNR (Signal/Noise Ratio). A more recent technique is the use of so-called FGS (Fine Granularity Scalability) [14] in the MPEG4 context [11], which consists of a judicious organisation of DCT coefficients into bitplans, thus a single video-stream suitable for various link capabilities (each bit-plan leads to a sub-stream). The congestion control can also be done by ratecontrol. The generic approach is a dialog between the network and the encoder, for the choice of a bandwidth used for video-stream generation. Rate control attempts to minimize the possibility of
0-7695-2650-0/06/$20.00 (c) IEEE
network congestion by matching the rate of the video stream to the available network bandwidth [6]. The rate control mechanism is generally based on the throughput model of TCP. Specially the TCPfriendly model [16]. Under this model, the video connection could avoid congestion in a similar way to that of TCP and it can complete fairly with TCP flow. The advantage of a TCP-friendly rate control is that the video traffic will not be too aggressive against other true TCP traffics (such as WEB traffic). The main drawback is that the available bandwidth, and thus the video quality can be timely varying, the main technical difficulty is that the parameters RTT and p must be continuously monitored.
4. The proposed framework The mechanism for improvement of the wireless video applications quality proposed in this paper is to be placed on a terminal between a client and a network (figure1).
User
Interfaces
Messages
Analysis Layer
Control Layer
User identification Profile determination
User/Application Profiles
Feedback information treatment Parameters determination Feedback Information
QoS Parameters
Negotiation Layer
Mobile agents
4.2. Control Layer The second layer is dedicated to the control. Once the user’s needs and preferences are identified, the next step consists in verifying that these preferences are converted into the appropriate parameters values.
Context Information
Terminal Quality Level
according to these categories and to the requirements of the user. The input data for this layer can be distributed in three categories: - Information collected through a communication with the user via graphical interfaces or messages. - Information collected through an observation of the user’s behavior. Once the information is analyzed, the result is a user profile that represents the user’s preferences in terms of quality and an application profile that describes the needs of each application. So this layer plays the role of intermediary between the user and the system. It defines the graphical interfaces needed for the communication with the user. It may send him messages or questions and help him choosing the answers that best match with his profile or needs;
QoS negotiation Rate adaptation
Responsive agents
Network
Figure 1. The layers of the proposed framework
As shown in figure 1, the proposed model contains different layers.
4.1. Analysis Layer The first one is the analysis layer [12]. This layer is introduced to identify the user and to analyze his work along with the applications he uses. User preferences and application requirements are saved in the knowledge base of the system. These data are modified systematically according to any change in the user choices and actions. Applications can be classified in many categories according to the type of the supported information (data, voice, image…) or the need for communication (delay, jitter…). The profile of the application will then be determined
The control made in this layer should also guarantee a good adaptation of the attributed quality with the real-time user’s work independently of the user’s mobility or even the user’s profile variation. The reasoning mechanism needed at this level is a permanent comparison of input data from the profile manager layer (profiles, characteristics) and those from the negotiation layer (degradation or modification of quality, cancellation of contract between the two sides, new propositions of services). The output from this layer will be QoS parameters values sent to the negotiation layer. These values represent the users and applications requirements. The control layer accomplishes these functionalities: - It determines the values that should be attributed to all of the negotiation parameters depending on the constraints of the system, the service providers and the profile of negotiation. - It establishes the link between the user and the service provider. It verifies that both of the two parts respect the negotiated services. The satisfaction of the user is deduced from the analysis of his behavior. - It analyses the feedback information collected by the responsive agents in order to take decisions concerning the renegotiation and to evaluate the state of the link and the video packet transmission.
4.3. Negotiation Layer
0-7695-2650-0/06/$20.00 (c) IEEE
The third layer is the Negotiation layer [13] responsible for the negotiation of the QoS parameters received from the control layer and for the dynamic regulation of wireless video communications. It sends the QoS parameters to the network entities and starts the process of negotiation. It may also ask for a change in the required services according to the needs of the user and the applications. This corresponds to a request of renegotiation between the two parts. Mobile agents, [4] and [1], are sent to the service providers in order to bring new offers. In this layer, there is a contextaware mechanism for reactive control and dynamic regulation of wireless video communications. The context-awareness is made possible with a couple of java agents. Basically, our response agents can be loaded dynamically on various equipments (terminals as well as routers), depending on the context. They supervise, in real time, the state of the link and the video packets transmission and propose an adequate regulation of the video flow. The main roles of our agents are i) to take information about the local link state, including particularly bandwidth, loss ratio and loss pattern, as well as the delay jitters, this can be done by using the sequence number of every RTP packet as well as its timestamp as described in [8] and [9]; ii) to make a decide on the rate-control to be taken, according to the current link state. The mechanism allows the use of any adequate algorithm for rate-determination (asservissement algorithm, for example, presented in [8]). The java agent calculates, by means of this algorithm, the value of the bandwidth available for video traffic. A feedback packet ensures the transfer of the adequate rate of the video communication and the QoS parameters (loss ratio, delay, jitters and bandwidth) to the control layer. They bring in the requirements of the network as well as those of the video data.
5. Conclusion and future work In this paper, we have proposed a mechanism for the video applications quality improvement in wireless systems. The context-awareness of our framework lies in the fact that it takes, in real-time, into account: i) the situation of the link, ii) the preferences of the user on quality and price as well as his profile (indicating whether he is mobile or not), iii) the needs and the requirements of video applications. Our approach offers a responsive mechanism for the negotiation of the desired QoS between the user terminal and the network entities and a reactive video rate control. We believe that it is a good candidate for handling video-communications over wireless links.
6. References
[1] N. Agoulmine, M. Fonseca, A. Marshall, “Multidomain Policy Based Management Using Mobile Agents, Lecture Notes in Computer Science, 2000. [2] B. Berruto, M. Gudmundson, R. Menolascino, W.Mohr, and M. Pizarroso, Research activities on UMTS radio interface, network architectures, and planning. IEEE Commun. Mag. vol. 36, pp. 82-95, Feb. 1998. [3] J. Boyle, R. Cohen, D. Durham, S. Herzog, R. Raja, A. Sastry, "The COPS (Common Open Policy Service) Protocol", RFC 2748, January 2000. [4] J.-P. Briot, Y. Demazeau, "principles and architecture of MAS", 2002. [5] K. Chan, J. Seligson, D. Durham, S. Gai, K. McCloghrie, S. Herzog, F. Reichmeyer, R. Yavatkar, A. Smith, " COPS Usage for Policy Provisioning", March 2001. [6] WU. Dapeng, Yiwei Th. HOU, WenwuZhu, Ya-Qin Zhang & Jon M. Peha, "Streaming Video over the Internet: Approaches and Directions", IEEE Trans. On Circuits and Systems for Video Technology, Vol. 11, Num. 3, March 2001, pp. 282-300. [7] D. Grillo, Special section on third-generation mobile systems in Europe, IEEE Personal Commun. Mag., vol 5, pp. 5-38, Apr. 1998. [8] R. Hammi, Controle actif de transmission de flux vidéo par régulation du débit, Phd thesis, Université Paris13, 16 décember 2002. [9] R. Hammi, Chen K, Blin JP, Loras F (2002) A framework for responsive control of video communication using active networks. 18th World Telecommunication Congress. [10] J. Huang, R. Yuqi Yao, Y. Bai and S-W. Wang, Performance of a Mixed-Traffic CDMA2000 Wireless Network With Scalable Streaming Video, IEEE Transactions On Circuits And Systems For Video Technology. Vol. 13, NO. 10, October 2003. [11] ISO/IEC Standards 14496-x, "Generic Coding of Moving Pictures and Associated Audio (MPEG-4 Final DIS)", November 1998. (x=2 concerns the video part). [12] Z. Jrad., B. Benmammar, J. Correa, F. Krief , N. Mbarek. A user assistant for QoS negotiation in a dynamic environment using agent technology. Second IFIP International Conference on Wireless and Optical Communications Networks WOCN 2005. Dubai, United Arab Emirates UAE, March 2005. [13] Z. Jrad. And F. Krief. An Intelligent Interface for the Dynamic Negotiation of QoS in ARCADE. ACS/IEEE International Conference on Pervasive Services. ICPS’2004. Beirut, Liban. Juillet 2004. [14] Weiping Li, "Overview of Fi ne Granularity Scalability in MPEG-4 Video Standard", IEEE Trans. On Circuits and Systems for Video Technology, Vol. 11, Num. 3, March 2001, pp. 301-317.
0-7695-2650-0/06/$20.00 (c) IEEE
[15] D. Lindberg, The H.324 multimedia communication standard}, IEEE Commun. Mag., vol. 34, pp. 46-51, Dec. 1996.
[21] Recommendation H.245, Control Protocol for Multimedia Communication, ITU-T Recommendation H.245, 1996.
[16] J. Mahdavi and S. Floyd, TCP-Friendly Unicast Rate Based Flow Control, Technical note sent to the end2endinterest mailing list, 8 January 1997.
[22] Recommendation H.263 Version 2, Video Coding for low Bitrate Communications, February 1998.
[17] T.M.T. Nguyen, , N. Boukhatem, Y. El Mghazli, N. Charton, Louis-Louis Hamer, G. Pujolle, "COPS-PR usage for SLS negotiation (COPS-SLS)", draft nguyen-rap-copssls-03.txt, Internet Draft, July 2002.
[23] G. Roth, R. Sjoberg, G. Liebl, T. Stockhammer, V. Varsa, and M. Karczewicz, Common Test Conditions for RTP/IP over 3GPP/3GPP2, Austin, TX, ITU-T SG16 Doc. VCEG-M77, 2001.
[18] QoSforum, "QoS protocols & architectures", White Paper, July 1999.
[24] H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson, RTP: A Transport Protocol for Real-Time Applications, Request For Comment 1889, IETF, January 1996.
[19] Recommendation H.324, Terminal for Low Bitrate Multimedia Communication, ITU-T Recommendation H.324, 1995. [20] Recommendation H.223, Multiplexing Protocol for Low Bitrate Multimedia Communication, ITU-T Recommendation H.223, 1996.
[25] 3rd GPP; Technical Specification Group Core Network; IP Multimedia Call Control Protocol Based on SIP and SDP, 3GPP Technical Specification TS 24.229.
0-7695-2650-0/06/$20.00 (c) IEEE
