QoS

negotiation

for

IPTV

service using

SIP

H. J. Park 1 J. H. Yang' J. K. Choi' H.S. Kim2 Information and Communications University' National Information Society Agency2

Abstract -This paper addresses QoS negotiation algorithm for IPTV services by using SIP. IPTV is be defined as multimedia services such as television/video/audio/text/graphics/data delivered over IP based networks managed to provide the required level of QoS/QoE, security, interactivity and reliability by the ITU-T IPTV FG. As stated in its definition, IPTV provides the required level of QoS/QoE. To achieve this, IPTV service frameworks should be able to negotiate QoS/QoE with users or customers and SIP is one of the most proper methods for the SLA negotiation.

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

1. Introduction
According to the development of Internet access techniques through both wired line and wireless access, the number of customers using Internet has greatly increased. This increment caused active communication activities done by exchanging texts, audios, and videos, so called multimedia through the IP networks. With the increment of multimedia communications via IP networks, many network applications and services has been developed to encourage those activities. The IPTV (Internet Protocol based Television) service is one of these network applications. The IPTV service has the advantage of offering lower cost broadcasting service via a high speed and low-cost internet access line. This high speed network makes it possible to support real-time services like voice and video communication, 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 IP networks work well in this context at the end users. However, the new set of multimedia services requires end-to-end quality-of-service (QoS) or quality-of-experience (QoE) guarantees. Since customers are used to viewing television programs and using their telephones without noticing any jitter or delay, QoS/QoE guarantees are a must in IPTV service deployment over the IP networks. This becomes critical because, 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 traffic management 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 existing connectionless best effort architecture. It is envisioned that in IPTV, users will enjoy different levels of service for their traffic by executing contracts with their service providers. An important characteristic of IPTV is to allow users to

dynamically adjust their desired service levels along with acceptable prices for the service. This feature is necessitated not only by the requirement to provide flexibility for users, but also by the heterogeneity in the both wired line and wireless subsystems and end device capabilities [8]. This dynamic QoS/QoE level negotiation can be referred as Service Level Agreement (SLA) negotiation, where the SLA is defined as following: A SLA is a service contract between a customer and a service provider that specifies the forwarding service a customer should receive (IETF RFC 2475). Session Initiation Protocol (SIP) is a signaling protocol for controlling various multi-media sessions. In other words, it provides a way to establish voice, video and messaging communication between devices [5]. Therefore, in this paper, we present the the QoS/QoE SLA negotiation scheme for IPTV services using SIP. We explain the QoS/QoE parameters and classifications of its quality levels for the IPTV services in the following chapter. With this quality parameter definitions and quality level classifications, we introduce our suggesting SIP message scheme for the efficient SLA negotiation on the chapter 3. In the chapter 4, we present the procedure of QoS/QoE SLA negotiation with our suggested SIP message format. Finally, we conclude this paper with the advantages of the suggested negotiation scheme and a discussion of future research directions in this area.

2. The QoS/QoE Classification for SLA

For the examination of the quality of IPTV service, we can utilize some relevant parameters with respect to the nature of the service such as, bandwidth required, packet delay, jitter, and loss rates. These parameters are indicating specific state of data transfer through IP network. It can be properly applied to determine the quality of IPTV services by defining their values mapping for each quality levels regarding for the characteristics of provisioned, that is being able to required, sub-services of the IPTV service by the service or network providers. However, users do not know what the parameters are and more importantly, how the specific parameters effect to their services. In other words, even though the parameters are really used to examine the quality of services for the service providers and network providers to guarantee the quality of service and to charge for that service, it is not a good way to use the exact parameters to negotiate with users for setting the SLA between providers and users. Therefore, we need other method 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 examining parameters for the SLA negotiation without disturbing users to deal with them is classifying the quality levels by assigning proper values for the parameters with regarding for the characteristics of sub-services. By classifying the quality of service with assigning relevant values to the parameters, service providers and users can easily understand and negotiate their SLA and also can make the charging mechanism simple. For the clear, efficient, feasible, and widely adaptable classification, there is the QoS class guidance from the ITU-T Y. 1541. QoS classes quantify user application needs in terms of IP network performance. Table 1 shows the guidance for IP QoS Classes by the ITU-T Y.1541 [3].
Table 1. ITU-T Y.1541 Guidance for IP QoS Classes

message of SIP, appears as a suitable supporting protocol to place QoS-related connection parameters in. An alternative of adding the information to the SIP header would, albeit feasible, in contrast not fit the ISO/OSI 7 layer model paradigm of placing protocol information at the most appropriate layer, besides not being central enough to SIP for augmenting its header. The session-layer SDP, in turn, is a suitable bearer for QoS information in the form of SDP attributes [7]. This approach is also being applied in the RFC 3312, that deals with sessions that use SIP as a signaling protocol and SDP to describe the parameters of the session. It chose to include the quality of service preconditions in the SDP description rather than in the SIP header because preconditions are stream

QoS Class
0

Applications (Examples) Real-Time, Jitter Sensitive, High Interaction (VoIP, VTC) Real-Time, Jitter Sensitive, Interactive (VoIP, VTC) Transaction Data, Highly Interactive (Signalling)
Transaction Data,

Node Mechanisms

Network Techniques

Separate Queue with Preferential

Constrained Routing/Distance
Less Constrained Routing/ Distance Constrained Routing/Distance
Less Constrained

Servicing,
Traffic Grooming

specific. 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, we concentrate only on the INVITE, OK, and BYE methods. Because SIP is for the application layer protocol for session initiation, we suggest to use some of the fields to indicate that this is for the IPTV service. We apply the SIP URIs with the IPTV service channel URIs to indicate the relevant IPTV service servers and also use the IPTV channel IDs for the IPTV service provider side session ID.
Table 2. SIP header message formats for QoS/QoE negotiation

[INVITE message]
INVITE sip:<IPTV Service Channel URI> SIP/2.0 Via: 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 INVITE Max-Forwards: 70 Contact: <sip: User-id@<local IP address>:<port number>> Content-Length: <length of the body message>

Separate Queue, Drop

Interactive

Priority

Routing/
Distance

(Short
4

Low Loss Only

Transactions, Bulk
Traditional Applications of Default IP Networks

LnQueue,

Data, VideoDrpPiit Streaming)

Separate Queue (Lowest Priority)

Drop Priority

Any Route/Path

[OK message]
Any Route/Path SIP/2.0 200 OK Via: 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 INVITE Contact: <sip: User-id@<local IP address>:<port number>> Content-Length: <length of the body message>

Since IPTV includes various sub-services, not only for the television broadcasting service, but also voice or audio services and interactive data communication services, in this paper, we adopt this QoS classification for the SLA negotiation.

3. SIP Message Formats for QoS Negotiation

The base SIP standard contains no mechanisms for controlling network bandwidth and latency availability, and most current IP networks do not provide this either. However, with the rise of MPLS-based networks, and the use of SIP to control media flows over QoS networks, guaranteed quality can be provided [6]. As de-facto member of the SIP stack, the Session Description Protocol (SDP) which is being used as a body

Via: 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 BYE Max-Forwards: 70 Content-Length: <length of the body message>

[BYE message] BYE sip:<IPTV Service Channel URI> SIP/2.0

now we

With the indication ofthe IPTV session from the SIP header, apply our QoS level classification information in the SDP 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

946

Feb. 12-14, 2007 ICACT2007

the session descriptions except one field. One of the important and optionally used descriptions is "a" - Attribute field. Attributes are the primary means for extending SDP.
[Body of the INVITE message]
Table 3. SIP body message formats by SDP

v=O o=<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 attributes

a=<attribute>:<value> a=<attribute>:<value> a=quality:<quality> 110 to 10. Use Y.1541 class from 0 to 5

When the server finishes the examination, it will send either SIP OK message to notify that the service request is being accepted and so does the quality level of the service, or SIP reject response with relevant information. If user receives the negative response message from the server, then the user can chose to try again with lower service quality or can chose to use 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 and then 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 to notify that the service is successfully finished from the server.

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

5. Conclusion
In this paper, we have proposed the scheme for QoS SLA negotiation for IPTV service using SIP. The IPTV service is basically provides television broadcasting service and other various services through IP network. Since users are familiar with clear video and audio streams that have been provided by the traditional televisions, IPTV needs to guarantee the quality of the service. However, most of the current IP networks are not ready to guarantee that quality with abundant network resources for the IPTV service. Hence, we need to negotiate the level of service qualities with relevant charging mechanisms. To help with the efficient and feasible service quality negotiation, we have proposed to adopt the QoS classification guidance form the ITU-T Y. 1541. Then we discussed the message schemes for the IPTV service session SLA by using the SIP header and the SIP body that is SDP. Finally, we described the procedure for the QoS SLA negotiation using SIP for IPTV service. ACKNOWLEDGEMENT
This work was

4. The SLA negotiation procedure

In the previous chapters, we have discussed the QoS level classification and the message format to negotiate the relevant SLA for IPTV service. In this chapter we explain the procedure of the SLA negotiation using the SIP messages. As depicted in the figure 1, firstly, user sends the INVITE message to request one of the IPTV service to the IPTV service provider with preferred service quality level. Then the message is received by the IPTV server through the IPTV proxy and is examined by the server whether the request is proper or not and also available or not.
IPTV user IPTV proxy

IPTV server

INVITE with SLA request

INVITE with SLA rcequest

Korea Science and Engineering Foundation (KOSEF) under

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

supported

in

part by MIC,

Korea under the

OK with SLA agreeement OK with SLA agreement

the ERC.

REFERENCES
BYE with SLA rellease

BYE with SLA release

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

ACK for the BYE request

ACK for the BYE r,request

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

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

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

Figure 1. The SLA negotiation procedure us]ing SIP

ISBN 978-89-5519-131-8 93560

947 -

Feb. 12-14, 2007 ICACT2007

[5] Sundar Vedantham, Seong-Hwan Kim, and Deepak Kataria, "Carrier-Grade Ethernet Challenges for IPTV Deployment", IEEE Communications Magazine, July 2006. [6] Jonathan Cumming, "SIP MARKET OVERVIEW - An analysis of SIP technology and the state of the SIP market", Data Connection, U.K., September 2003. [7] Michael Alexander and Peter Suppan, "An Architecture for SDPBased Bandwidth Resource Allocation with QoS for SIP in IEEE 802.16 Networks", Q2SWinet'06, October 2, 2006, Torremolinos, Malaga, Spain. [8] Venkatesh Sarangan, Jyh-Cheng Chen, "Comparative Study of Protocols for Dynamic Service Negotiation in the Next-Generation Internet", IEEE Communications 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