IEEE TRANSACTIONS ON MULTIMEDIA, VOL. 3, NO. 2, JUNE 2001 219Quality-of-Service Mapping Mechanism for PacketVideo in Differentiated Services NetworkJitae Shin, JongWon Kim, Senior Member, IEEE, and C.-C. Jay Kuo, Fellow, IEEEAbstract—This research presents a futuristic framework forquality-of-service (QoS) mapping between practically categorizedpacket video and relative differentiated service (DiffServ or DS)network employing unified priority index and adaptive packetforwarding mechanism under a given pricing model (e.g., DiffServlevel differentiated price/packet). Video categorization is basedon the relative priority index (RPI), which represents the relativepreference per each packet in terms of loss and delay. We proposean adaptive packet forwarding mechanism for a DiffServ networkto provide persistent service differentiation. Effective QoS map-ping is then performed by mapping video packets onto differentDiffServ levels based on RPI. To verify the efficiency of proposedstrategy, the end-to-end performance is evaluated through anerror resilient packet video transmission using ITU-T H.263+codec over a simulated DiffServ network. Results show that theproposed QoS mapping mechanism can exploit the relative Diff-Serv advantage and result in the persistent service differentiationamong DiffServ levels and the enhanced end-to-end video qualitywith the same pricing constraint.Index Terms—Differentiated services (DiffServ), network pric-ing, packet video, quality-of-service (QoS), relative priority index(RPI), relative service differentiation.I. INTRODUCTIONINTERNET applications have very diverse requirementson the network service, thus making the current best-effortInternet model less than sufficient. The emerging continuousmedia (CM) application demands more stringent quality-of-ser-vice (QoS) requirements than traditional TCP-based appli-cations. Under the best-effort model, video applications atend-systems may adjust their rates through spatial/temporalquality adjustment in response to packet loss and delay feed-back under TCP-friendly congestion control [1], [2]. However,maintaining the end-to-end video quality is too challenging tobe accommodated by the best-effort Internet, since the videostream is inherently variable bit rate (VBR) and the Internetis an unpredictable time-varying channel. An alternative is tolet the network provide a different level of assurance in termsof network QoS parameters within its resource capacity. Tworepresentative approaches in the Internet engineering task force(IETF) are the integrated services (IntServ) with the resourcereservation protocol (RSVP) and the differentiated servicesManuscript received March 6. 2001. This paper was presented in part atPacket Video Workshop 2000, Sardinia Italy, May 2000. The associate editorcoordinating the review of this paper and approving it for publication was Dr.John Aa. Sorensen.The authors are with the Integrated Media Systems Center and Departmentof Electrical Engineering-Systems, University of Southern California, Los An-geles, CA 90089-2564 USA (e-mail: [email protected]; [email protected]; [email protected]).Publisher Item Identifier S 1520-9210(01)04323-1.(DiffServ or DS) [3], [4]. These Internet protocol (IP)-QoSmethods are more suitable in accommodating various QoSrequirements of different applications than the best-effortmodel. Between the two main IP-QoS approaches, the DiffServscheme provides a less complicated and scalable solution sinceIntServ requires to maintain per-flow state across the wholepath for resource reservation. In the DiffServ model, resourcesare allocated differently for various aggregated traffic flowsbased on a set of bits (i.e., DS byte). Consequently, the DiffServapproach allows different QoS grades to different classes ofaggregated traffic flows. DiffServ working group in IETF havedefined two services: 1) a premium service (PS) [5], whichexpects the virtual leased line service to support low loss anddelay/jitter, and 2) an assured service (AS) [6], which providesbetter than best-effort but without guarantee.While it is relatively clear how to build a predictable applica-tion by using protocols and mechanisms of RSVP and IntServ,the way to establish DiffServ-aware application in fine-granu-larity is still an open issue. Since the DiffServ specifies onlylocal forwarding behaviors, the biggest challenge is to identifythe way to best utilize the DiffServ for emerging applications.Ongoing research efforts in service differentiation can be di-vided into two directions based on absolute [7], [8] and rela-tive [9], [10] concepts. In absolute service differentiation forguaranteed service, Stoica et al. propose a state-less core ar-chitecture that uses QoS parameter carried by packet header toprovide fair-queuing [7] or guaranteed delay [8]. With per-flowstate only at boundary nodes, the absolute differentiation seeksto providean end-to-end absolute performance without per-flowstate in the network core. In contrast, Dovrolis et al. [9], [10]promote the relative differentiation that provides a proportionalservice gap with their own proprietary scheduling. That is, ahigher DS level1provides better (or at least not worse) queuingdelays and packet losses.The absolute service differentiation causes more complexitydue to QoS provisioning overhead. It also trades off the flexi-bility for more guarantees. If we can limit the absolute portion ofDiffServ as much as possible, it will enhance the flexibility andscalability of whole DiffServ architecture. Regardless of abso-lute or relative differentiation, the DiffServ already assumes in-telligence at the boundary nodes of the DiffServ domain. As theInternet evolves toward the QoS model and as networked CMapplications becomes more adaptive to QoS parameters, it ap-pears that relative service differentiation can be a more attractivechoice. Except for several conversational CM applications (e.g.,Internettelephonyincludingvideoconferencing),themajorityof1DS Level can be interpreted as the grade of quality provided to a group ofpackets having an identical DS codepoint in the IP header.1520–9210/01$10.00 © 2001 IEEE220 IEEE TRANSACTIONS ON MULTIMEDIA, VOL. 3, NO. 2, JUNE 2001networked CM applications are tolerant to occasional delay/lossviolations. Hence, they do not require tight delay/loss bounds,which can be better provided by DiffServ PS2. For