QoS negotiation for IPTV service using SIP

H. J. Park 1 J. H. Yang' J. K. Choi' H.S. Kim2Information and Communications University'

National Information Society Agency2

Abstract -This paper addresses QoS negotiation algorithm forIPTV services by using SIP. IPTV is be defined as multimediaservices such as television/video/audio/text/graphics/datadelivered over IP based networks managed to provide therequired level of QoS/QoE, security, interactivity and reliabilityby the ITU-T IPTV FG. As stated in its definition, IPTV providesthe required level of QoS/QoE. To achieve this, IPTV serviceframeworks should be able to negotiate QoS/QoE with users orcustomers and SIP is one of the most proper methods for the SLAnegotiation.

Keywords- SIP, IPTV, QoS/QoE negotiation, SLA

1. Introduction

According to the development of Internet access techniquesthrough both wired line and wireless access, the number ofcustomers using Internet has greatly increased. This incrementcaused active communication activities done by exchangingtexts, audios, and videos, so called multimedia through the IPnetworks. With the increment of multimedia communicationsvia IP networks, many network applications and services hasbeen developed to encourage those activities. The IPTV(Internet Protocol based Television) service is one of thesenetwork applications. The IPTV service has the advantage ofoffering lower cost broadcasting service via a high speed andlow-cost internet access line. This high speed network makesit possible to support real-time services like voice and videocommunication, in addition to best-effort data delivery [4].Best-effort service has been traditionally used to provide

Internet access services such as Web browsing. Current IPnetworks work well in this context at the end users. However,the new set of multimedia services requires end-to-endquality-of-service (QoS) or quality-of-experience (QoE)guarantees. Since customers are used to viewing televisionprograms and using their telephones without noticing any jitteror delay, QoS/QoE guarantees are a must in IPTV servicedeployment over the IP networks. This becomes criticalbecause, as the available bandwidth per customer increases,emerging suite of services will demand even more bandwidth,generating bottlenecks that can only be handled well via trafficmanagement features [5].To deal with this service requirement of the IPTV services,

new mechanisms for ensuring QoS need to be developed,requiring fundamental changes to the Internet's existingconnectionless best effort architecture. It is envisioned that inIPTV, users will enjoy different levels of service for theirtraffic by executing contracts with their service providers. Animportant characteristic of IPTV is to allow users to

dynamically adjust their desired service levels along withacceptable prices for the service. This feature is necessitatednot only by the requirement to provide flexibility for users, butalso by the heterogeneity in the both wired line and wirelesssubsystems and end device capabilities [8]. This dynamicQoS/QoE level negotiation can be referred as Service LevelAgreement (SLA) negotiation, where the SLA is defined asfollowing: A SLA is a service contract between a customerand a service provider that specifies the forwarding service acustomer should receive (IETF RFC 2475).Session Initiation Protocol (SIP) is a signaling protocol for

controlling various multi-media sessions. In other words, itprovides a way to establish voice, video and messagingcommunication between devices [5]. Therefore, in this paper,we present the the QoS/QoE SLA negotiation scheme forIPTV services using SIP. We explain the QoS/QoE parametersand classifications of its quality levels for the IPTV services inthe following chapter. With this quality parameter definitionsand quality level classifications, we introduce our suggestingSIP message scheme for the efficient SLA negotiation on thechapter 3. In the chapter 4, we present the procedure ofQoS/QoE SLA negotiation with our suggested SIP messageformat. Finally, we conclude this paper with the advantages ofthe suggested negotiation scheme and a discussion of futureresearch directions in this area.

2. The QoS/QoE Classification for SLA

For the examination of the quality of IPTV service, we canutilize some relevant parameters with respect to the nature ofthe service such as, bandwidth required, packet delay, jitter,and loss rates. These parameters are indicating specific state ofdata transfer through IP network. It can be properly applied todetermine the quality ofIPTV services by defining their valuesmapping for each quality levels regarding for thecharacteristics of provisioned, that is being able to required,sub-services of the IPTV service by the service or networkproviders.However, users do not know what the parameters are and

more importantly, how the specific parameters effect to theirservices. In other words, even though the parameters are reallyused to examine the quality of services for the serviceproviders and network providers to guarantee the quality ofservice and to charge for that service, it is not a good way touse the exact parameters to negotiate with users for setting theSLA between providers and users. Therefore, we need othermethod to effectively negotiate the SLA.

ISBN 978-89-5519-131-8 93560 - 945 - Feb. 12-14, 2007 ICACT2007

One good way of utilizing the original quality examiningparameters for the SLA negotiation without disturbing users todeal with them is classifying the quality levels by assigningproper values for the parameters with regarding for thecharacteristics of sub-services. By classifying the quality ofservice with assigning relevant values to the parameters,service providers and users can easily understand andnegotiate their SLA and also can make the chargingmechanism simple.For the clear, efficient, feasible, and widely adaptable

classification, there is the QoS class guidance from the ITU-TY. 1541. QoS classes quantify user application needs in termsof IP network performance. Table 1 shows the guidance for IPQoS Classes by the ITU-T Y.1541 [3].

Table 1. ITU-T Y.1541 Guidance for IP QoS ClassesQoS Applications Node NetworkClass (Examples) Mechanisms Techniques

Real-Time, Jitter

0 Sensitive, High Separate ConstrainedInteraction Queue with Routing/Distance(VoIP, VTC) PreferentialReal-Time, Jitter Servicing, Less

1 Sensitive, Traffic ConstrainedInteractive (VoIP, Grooming Routing/VTC) DistanceTransaction Data, Constrained

2 Highly Interactive Routing/Distance(Signalling) Separate

Queue, Drop Less

3 Transaction Data, Priority ConstrainedInteractive Routing/

DistanceLow Loss Only(Short LnQueue,

4 Transactions, Bulk Drop Priority Any Route/PathData, VideoDrpPiitStreaming)Traditional Separate

5 Applications of Queue Any Route/PathDefault IP (LowestNetworks Priority)

Since IPTV includes various sub-services, not only for thetelevision broadcasting service, but also voice or audioservices and interactive data communication services, in thispaper, we adopt this QoS classification for the SLAnegotiation.

3. SIP Message Formats for QoS Negotiation

The base SIP standard contains no mechanisms forcontrolling network bandwidth and latency availability, andmost current IP networks do not provide this either. However,with the rise of MPLS-based networks, and the use of SIP tocontrol media flows over QoS networks, guaranteed qualitycan be provided [6].As de-facto member of the SIP stack, the Session

Description Protocol (SDP) which is being used as a body

message of SIP, appears as a suitable supporting protocol toplace QoS-related connection parameters in. An alternative ofadding the information to the SIP header would, albeit feasible,in contrast not fit the ISO/OSI 7 layer model paradigm ofplacing protocol information at the most appropriate layer,besides not being central enough to SIP for augmenting itsheader. The session-layer SDP, in turn, is a suitable bearer forQoS information in the form of SDP attributes [7]. Thisapproach is also being applied in the RFC 3312, that deals withsessions that use SIP as a signaling protocol and SDP todescribe the parameters of the session. It chose to include thequality of service preconditions in the SDP description ratherthan in the SIP header because preconditions are streamspecific.Table 2 shows the SIP header message formats that are

suggested in this paper. There are several methods in SIP,however, since we are focusing on the SLA negotiation, weconcentrate only on the INVITE, OK, and BYE methods.Because SIP is for the application layer protocol for sessioninitiation, we suggest to use some of the fields to indicate thatthis is for the IPTV service. We apply the SIP URIs with theIPTV service channel URIs to indicate the relevant IPTVservice servers and also use the IPTV channel IDs for theIPTV service provider side session ID.

Table 2. SIP header message formats for QoS/QoE negotiation

With the indication ofthe IPTV session from the SIP header,now we apply our QoS level classification information in theSDP description to specify the QoS level for SLA negotiation.As other SDP session descriptions are being used as

specified in RFC 4566 [2], we also adopt the specification for

ISBN 978-89-5519-131-8 93560

[INVITE message]INVITE sip:<IPTV Service Channel URI> SIP/2.0Via: SIP/2.0/UDP <local IP address>:<port number>From: User-id<sip:User-id@<local IP address>:<port number>>To: <IPTV Channel ID> <sip:< IPTV Channel URI>>Call-ID: <randomly generated Call-ID>@<local IP address>CSeq: 1 INVITEMax-Forwards: 70Contact: <sip: User-id@<local IP address>:<port number>>Content-Length: <length of the body message>

[OK message]SIP/2.0 200 OKVia: SIP/2.0/UDP <local IP address>:<port number>From: User-id<sip:User-id@<local IP address>:<port number>>To: <IPTV Service ID> <sip:<IPTV Service URI>>Call-ID: <randomly generated Call-ID>@<local IP address>CSeq: 1 INVITEContact: <sip: User-id@<local IP address>:<port number>>Content-Length: <length of the body message>

[BYE message]BYE sip:<IPTV Service Channel URI> SIP/2.0Via: SIP/2.0/UDP <local IP address>:<port number>From: User-id<sip:User-id@<local IP address>:<port number>>To: <IPTV Service ID><sip:<IPTV Service URI>>Call-ID: <randomly generated Call-ID>@<local IP address>CSeq: 3 BYEMax-Forwards: 70Content-Length: <length of the body message>

- 946 - Feb. 12-14, 2007 ICACT2007

the session descriptions except one field. One ofthe importantand optionally used descriptions is "a" - Attribute field.Attributes are the primary means for extending SDP.

Table 3. SIP body message formats by SDP

It has number of attributes that are defined by RFC 4566,and one of the attributes is quality. This quality attribute isoriginally defined to give a suggestion for the quality of theencoding as an integer value. However, to negotiate theQoS/QoE of IPTV, the quality of encoding is not enough todecide the quality of IPTV service. Therefore, we suggest the"a=quality: <quality>" description to indicate the QoS classvalue to be used for the SLA negotiation based on the ITU-TY.1541 QoS classification guidance. Table 3 shows the SIPheader message formats

4. The SLA negotiation procedure

In the previous chapters, we have discussed the QoS levelclassification and the message format to negotiate the relevantSLA for IPTV service. In this chapter we explain theprocedure of the SLA negotiation using the SIP messages.

As depicted in the figure 1, firstly, user sends the INVITEmessage to request one of the IPTV service to the IPTVservice provider with preferred service quality level. Then themessage is received by the IPTV server through the IPTVproxy and is examined by the server whether the request isproper or not and also available or not.

IPTV user IPTV proxy

INVITE with SLA request INVITE with SLA rc

OK with SLA agree

OK with SLA agreement

BYE with SLA release BYE with SLA rel

ACK for the BYE r,ACK for the BYE request

Figure 1. The SLA negotiation procedure us]

When the server finishes the examination, it will send eitherSIP OK message to notify that the service request is beingaccepted and so does the quality level of the service, or SIPreject response with relevant information. If user receives thenegative response message from the server, then the user can

chose to try again with lower service quality or can chose touse another service based on the reason for the rejection.However, assuming that the commonly used IPTV services are

reliable enough that the service is tangible in the real world,we can also assume that most of the service requests are

acceptable and the SIP 180 OK response will be returned andthen the IPTV service session is set up with the SLA.After enjoying the IPTV service, user wants to finish the

service and then it sends SIP BYE message to the IPTV server.

With the users releasing request, server releases the session,finishes the service, and sends the SIP 180 OK message tonotify that the service is successfully finished from the server.

5. Conclusion

In this paper, we have proposed the scheme for QoS SLAnegotiation for IPTV service using SIP. The IPTV service isbasically provides television broadcasting service and othervarious services through IP network. Since users are familiarwith clear video and audio streams that have been provided bythe traditional televisions, IPTV needs to guarantee the qualityof the service. However, most of the current IP networks are

not ready to guarantee that quality with abundant networkresources for the IPTV service. Hence, we need to negotiatethe level of service qualities with relevant chargingmechanisms.To help with the efficient and feasible service quality

negotiation, we have proposed to adopt the QoS classificationguidance form the ITU-T Y. 1541. Then we discussed themessage schemes for the IPTV service session SLA by usingthe SIP header and the SIP body that is SDP. Finally, we

described the procedure for the QoS SLA negotiation usingSIP for IPTV service.

ACKNOWLEDGEMENT

IPTV server This work was supported in part by MIC, Korea under the

ITRC program (ITAC 1090060300350001000100100)supervised by IITA. And it was also supported in part by the

equest Korea Science and Engineering Foundation (KOSEF) under

the ERC.ement

REFERENCES

[1] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R.Sparks, M. Handley, and E. Schooler, "Sip: Session initiation protocol",

lease RFC 3261, IETF, June 2002.

[2] M. Handley, V. Jacobson, C. Perkins, "SDP: Session DescriptionProtocol", RFC 4566, IETF, July 2006.

request [3] ITU T Recommendation Y.1541, Network performance objectives forIP-based services

[4] Yongsun Ryu, Eunjin Ko, Hyuncul Kang, Gilheang Lee, YoungSun Kim,"The Web based SLA System for Customer Quality Assurance in

ing SIP Providing IPTV Services", IEEE, 2006.

ISBN 978-89-5519-131-8 93560

[Body of the INVITE message]v=Oo=<username> <IPTV session-id> IN IP4 <Origin IP address>s=<IPTV service session name>u=<IPTV service URI>c=IN IP4 <connection address>b=<bwtype>:<bandwidth>t=<start-time> <stop-time>m=<media> <port> <proto> <fmt> ...a=<attribute> II a: Media-specific attributesa=<attribute>:<value>a=<attribute>:<value>a=quality:<quality> 110 to 10. Use Y.1541 class from 0 to 5

- 947 - Feb. 12-14, 2007 ICACT2007

[5] Sundar Vedantham, Seong-Hwan Kim, and Deepak Kataria,"Carrier-Grade Ethernet Challenges for IPTV Deployment", IEEECommunications Magazine, July 2006.

[6] Jonathan Cumming, "SIP MARKET OVERVIEW - An analysis of SIPtechnology and the state of the SIP market", Data Connection, U.K.,September 2003.

[7] Michael Alexander and Peter Suppan, "An Architecture for SDPBasedBandwidth Resource Allocation with QoS for SIP in IEEE 802.16Networks", Q2SWinet'06, October 2, 2006, Torremolinos, Malaga,Spain.

[8] Venkatesh Sarangan, Jyh-Cheng Chen, "Comparative Study of Protocolsfor Dynamic Service Negotiation in the Next-Generation Internet", IEEECommunications Magazine, March 2006.

[9] G. Camarillo and P. Kyzivat, "Update to the session initiation protocol(sip) preconditions framework", RFC 4032, IETF, October 2005.

ISBN 978-89-5519-131-8 93560 - 948 - Feb. 12-14, 2007 ICACT2007