Prioritization of lineare TV sub traffic in the IPTV over IMS session D.LEGHROUDI1, M.BELFKIH1, N.MOUMKINE2

and M.RAMDANI 2

1 Networks Laboratory, Institut National des Postes et Télécommunications, Rabat, Maroc

2 Department of computer science, Faculté des Sciences et Techniques Mohamedia, Morocco

Abstract. The distribution of real-time ‘linear’ TV, VoD and PvR traffic, on IP infrastructure, requires strict QoS constraints especially low loss and latency of packets transmission. The main challenge to realize these objectives is how to design cross layer architecture which resolve many problems and failures in existing network, and develop a framework intended for control and improve QoS parameters in multimedia service for NGN. Improve these parameters for both wired and wireless network is up to convey these traffics in a convergence platform such as IMS. The aim of this paper is the investigation of the quality of Service (QoS) techniques For IPTV in IMS network by evaluation of video traffic parameters, then we propose a solution which is based on awareness of DiffServ routers to support the new values of the DSCP field assigned to the IPTV also the correct behavior in such a way as to classify BC (Broadcast), VoD (video on demand), PVR (personal video recorder) packets belonging to the same flows and to prioritize the BC ones

Keywords: Next Generation Networks, Fixed-Mobile Convergence, IMS, IPTV services, BC, VoD, PVR,

nPVR, Multimedia Delivery Architecture, QoS, IntServ, DiffServ.

1. Introduction In the most case, like IPTV service delivery, video traffic is the dominant flow, but there are tree sub-flows in video,

namely broadcast (BC), video on demand (VoD), and personal video recorder (PVR). Which also are different on their sensitivity to QoS metrics and service provisioning.

The standards propose two approaches for QoS management: the Differentiated Services (DiffServ) [1] and Integrated Services (IntServ)[2] mechanisms. IntServ integrates services using a Resource Reservation Protocol (RSVP) that signals the network elements in a path to create an end-to-end reserved channel, the channel reserved acts on resource reservation or on admission control of data in the network. DiffServ, on the other hand, defines a marker in a data packet to select the next PHB (Per Hop Behavior) at a network element level. Based on the PHB the edge router, as a scheduler, should queue and transmit the packet, allowing packets to be prioritized according to their Class of Service. This network QoS mechanism is an improvement over the ”Best-effort” mechanisms present in IP networks [1]. IntServ provides QoS on the network level yet DiffServ provides it using a simple mechanism that doesn’t demand explicit resource reservation and network signalling, requiring just the routers configuration and packets marking, which make from it the most used mechanism in the best-effort network [3].

Both projects have assumed that the IPTV stream are of the same priority high compared to other service, however the packets accordingly BC, PVR, and VoD as well video streaming will be treated as best effort among them. In reality there is a major difference between these packages in their sensitivity to delay and other parameters. In this work we propose a mechanism which provides the delivery of IPTV traffic with different service level-based sensitivity to QoS parameters. With an experimental implementation in IMS wired network, we demonstrate the efficacy of mechanism to optimize the quality of service of BC traffic among different other video streaming.

This paper is structured as follows: Section 1 introduces some QoS mechanisms, Section 2 presents the architecture of IPTV. In section 3 we discuss Differentiated Services architecture , in section 4 present the QoS in IMS , our suggestion and framework are detailed in section 5,. The paper closes with a conclusion.

2. IPTV architecture In the IPTV architecture we perceive two types: dedicated IPTV systems and IMS-based systems. The first system features by a dedicated subsystem within an NGN platform which used to provide all required IPTV functionality to all subscribers [4].service control and user profile management are the main functions. The main advantage of these systems is the dedicated resources, resulting in reliability and performance [5]. But they suffer from the complexity of process to connect with other NGN elements in order to provide convergence’s services. The second type that integrates the components of IMS to provide IPTV service. This architecture considers the IPTV client as an

2011 International Conference on Information and Electronics Engineering

IPCSIT vol.6 (2011) © (2011) IACSIT Press, Singapore

273

IMS one; its authentication, authorisation and accounting must be made by the IMS functionality [5].the system provides also the support f mobility, interaction with NGN service enabler, service personalisation, adaptation of media[4].over IMS-based IPTV the IPTV stream can be adapted to suit the available network resources and different user terminals. The most concret framework of this system is the ETSI TISPAN IMS-based IPTV architecture [6] since it is the most widely adopted IMS-based framework in evolving standards and research. Figure 1 shows a simplified IPTV architecture and its operations.

Figure 1: ETSI TISPAN IMS-based IPTV architecture

The figure 2 Figure 3 illustrates an example of the interaction between all the entities involved when the user selects a video/channel (the methodology is the same for live and on demand content)for an IMS-based IPTV session.

Figure 2: IMS-based IPTV session

To stream its traffic, IPTV use several protocols corresponding to the different OSI layers, as in Figure 3.

Figure 3: IPTV protocol stack for user data

3. Differentiated Services [1] DiffServ architecture ensures QoS at the level of the entire Traffic aggregates (not individual flows). To provide it a set of traffic classes is defined. The classes are: Conversational/streaming/Interactive /Background, where the conversational is the most delay sensitive. This model defines certain behaviors a packet may receive at each hop; this is called per-hop behavior (PHB), In the Diffserv model several traffic flows are aggregated to one of a small number of behavior aggregates (BAs). Four defaults PHB are defined:

1. Default PHB. 2. Class-Selector PHB. 3.Expedited Forwarding PHB (EF). 4. Assured Forwarding PHB (AF). The following figure shows a Diffserv domain with a set of core routers and edge ones:

Fig 4: DiffServ architecture

4. QoS EVALUATION in IMS

4.1. Policy-based QoS Control for IMS Quality of Service means the capacity of a network to offer better services for a selected part of the traffic. A policy-based solution is passed by the 3GPP with an objective to satisfy the big challenge by: ensuring that sufficient QoS resources are provided to authorized users in the access network. Before the user can start an IMS session, the UE has to negotiate the media flows for the session with the peering UE according to the service subscription. This is

274

assured with the SIP based signaling in the application-layer signaling plane and the signaling goal is that only those negotiated media flows are allowed to be transmitted in the transport-layer. The policy is applied using a set of policy rules, being each policy rules a set of conditions and a set of actions. The policy rule is stored in the policy repository from which the Policy Decision Point (PDP) retrieves the appropriate policy rules in response to policy events that are triggered by the contracted IP QoS. [14]. In the next paragraph we intend to cover the main aspects about how Policy-based QoS Control Scenario is implemented in IMS: models, protocols and entities involved, just as the mechanisms and procedures performed by these entities in order to guarantee QoS Control.

4.2. QoS Control Scenario for IMS Services Providing service, the IMS should ensure QoS according to acceptable level upon best effort, as traffic generated, the QoS mechanism, using signalization protocol, must be dynamically adaptable to requirements, with this solution IMS can immigrate to ALL-IP architecture. The QoS control scenario for IMS is shown in the figure 5 and described as following[15].

Figure 5 : The QoS control scenario for IMS

Based on SDP (Session Description Protocol)[9] P-CSCF is informed about the service desired by the user, a message INVITE describing the user requirements on Gm interface with SIP protocol[10], is sent to the P-CSCF which must verify that the desired service will pass in best conditions of availability and QoS by using the SLA[11].the sensitive information are passed via Diameter protocol[12] to PCRF(Policy Control and Charging Rules Function)[13],this intelligent entity is capable of delivering the decisions and policy management for all network equipment. After a positive dialogue, the P-CSCF in turn allows the INVITE message pass to the user. Once the service is providing, it is necessary to signal the end of session to all entities to release resources. The PCRF invites the GGSN to release the resources reserved by the user by removing the PCC(Policy and Charging Control) rules, this release step is important for dynamic and reliable QoS management.

5. Our Contribution IPTV has different video traffic (Broadcast, video on demand, PVR, nPVR) wich has variable data rate due to the dynamic nature of the captured scene and the Encoding process. These types of traffic are different in their sensitivity to latency, if we use an EF behavior[1] to video stream in the DiffServ network there will be a problem because Broadcast video can’t support latency compared with VoD/PVR one , and due to the fact that multiple IPTV streams are placed into the same flow aggregate (FA), it is hard to design a maximum limit for traffic policing at the ingress router of a DiffServ domain. if à lot of EF traffic enter into the DiffServ domaine, the core router can cause latency to broadcast packets by serving continuously EF packets at the highest priority, this behavior increases delay. Excessive EF traffic in the core network will therefore lead very fast to full queues and large packet drops [8]. To ovoid this limitation we propose a list of PHBs called IF(IPTV flows) whose classify the packets by priority on based on their sensitivity to latency .we use 3 DSCP bits to recognise the IPTV packets by sensitivity to latency in the same stream. For IPTV traffic, we will set the three first DSCP bits for all packets, to differentiate between BC, VoD, PVR we will change the other three bits (101xxx), mapping these DSCP values to corresponding PHBs can prioritize BC packets for report those of PVR and VoD. Our PHBs is defined for high-priority; low latency/loss and jitter traffic is similar to EF.if the resource become insufficient the DiffServ core router will eliminate a packet with precedence from its queue. This way, important packets (broadcast one) have better chances to survive the end-to-end journey. In the case of saturation of the queue, the router proceeds to eliminate packages in the following order: 1� VoD, 2�PVR, 3�BC. To perform DiffServ Code Point (DSCP) markings on the IP packets sent towards the UE, we have implemented the following scenario: Using a modified Linux crtmpserver, which is capable of h.264 video coding and streaming, we analyse each NALU and we set the S_PR value for the current packet depending on the value of NRI field. In the source node (media server), the generation of DSCP values, by translation of S_PR ones, as their association with the corresponding PHB is done by the DSMARK tool which is a queuing discipline. It Is in charge of packet marking in The Linux implementation. Our test benchmark (Fig 6) consists of the following: 1. Core Router-Linux containing the various components of the IMS (P, I, S-CSCF, HSS) via the solution OpenIMS. 2. One-Edge Linux router that will allow us to connect the application server and the clients to the media Application server. on this router we have installed DSMARK for traffic policing 3. IPTV client. 4. One Linux router that will allow the client to connect to IMS proxy (P-CSCF) 5. Application server that provides services (IPTV_server): BC, PVR, and VoD.

275

0

20

40

60

80

100

120

140

0 50 100 150 200 250

Throughput(% of 1Gbps)

Lo

ss(P

acke

ts)

BC traffic

PVR traffic

VoD traffic

0

20

40

60

80

100

120

140

160

0 1000 2000 3000 4000 5000 6000

throughput(packets/s)

Lat

ency

(ms) BC traffic

VoD traffic

PVR traffic

6. A camera as a source of broadcasting traffic. 7. CrtmpServer for encoding in h.264 the flow coming from the camera and stream it to the IPTV client.

Figure 6: our Testbed

To evaluate the importance of policing based on dropping packet, a DiffServ edge router was configured using Linux QoS mechanisms to police traffic according to the DSCP value of each packet. We set the value of DSCP in the video source these values will be used by the edge router to discard excess packet.

5.1. Scenario: Simulation circumstance: we have set up an IP TV CP (Content Provider) system, its inputs contain a movie stored on the disk of the media server (media_AS), a space dedicated to the storage of video recorded by the client through a PvR session, a camera(which filming a movie projected on another PC with a better quality ) to provide video that represents the raw material for the sessions BC, its output is H.264.using crtmpserver which can encode the A/V (Audio/Video) signal into H.264.media server receives a video stream in flv, this traffic will undergo encoding in H.264 to give a traffic which will be broadcast to the user alice. the users Bob and driss, successively receiving a stream VoD and PVR using as a source a video stored on the media server. To identify the traffic, we implemented a Java agent, hosted on the IPTV server, it detects the port and IP address of the client, it communicates this information to the media server to identify packets affected by our policy of marking. Before starting the streaming, the media server must know the state of the router connected to the IPTV client through an XML file sent by the IPTV server to the media one. The parameters sent by the java agent triggered DSMARK at the media server, and the latter (DSMARK), based on the values sent by the socket S_PR, define the DSCP of the packet stream and therefore a corresponding PHB. The marking done at the media server must be maintained after passing through the Edge router. to do it, DSMARK was installed on this router and it works based on the same filters used by the media server. The following schemes shows the change in latency (Fig 7), Loss(Fig 8) depending on the throughput of the different traffics flow up the IPTV one before applying the new DSCP values. The figure 10 shows the quality of video in this stat.

Figure 7: Latency of BC, PVR and VoD traffics before the change of DSCP values.

Figure 8: Loss of BC, PVR and VoD traffics before the change of DSCP values.

Figure 9: Snapshot of the received video (BC video) before the change of DSCP values

5.2. RESULTS After the implementation of our policy of parts marking, we obtained the results shown in Figures 10, 11, and 12.

276

0

20

40

60

80

100

120

140

160

0 50 100 150 200 250

Throughput(% of 1Gbps)

Loss

(Pac

kets

)

BC traffic

PVR traffic

VoD traffic

0

20

40

60

80

100

120

140

160

180

0 1000 2000 3000 4000 5000 6000

throughput(packets/s)

Lat

ency

(ms) BC traffic

VoD traffic

PVR traffic

Figure 10: Latency of BC, PVR and VoD traffics after the change of DSCP values.

The application of the new DSCP values and the corresponding PHB has allowed us to prioritize BC traffic compared to other Sub-traffic (PVR, VoD), such a change has allowed us to improve the quality of service of traffic which is sensitive to delay.

Figure 11: Loss of BC, PVR and VoD traffics after the change of DSCP values.

Figure12: Snapshot of the received video (BC video) after the change of DSCP values

6. Conclusion In this paper, we discuss the Quality of Service (QoS) techniques for IPTV transmissions over IMS. In particular, we address a main problem: non differentiation between the BC, VoD, PVR packets. using the new values of DSCP we define new PHB that classifies IPTV packets by their sensitivity to delay, with this solution we improved the QoS of BC traffic in the IMS session, and this improvement can be applied to other traffic based on the charging system. Reducing the switching time, between the different IPTV sub traffics, is a critical problem to resolve. In general, traffic change times depend on several traffic: command time, network delay time, and MPEG decoder time. For a future work, we focus on optimizing the switching time between broadcast TV, VoD and PVR.

7. References [1] D. Grossman, RFC 3260 - New Terminology and Clarifications for DiffServ, IETF, April 2002.

[2] R. Braden, D. Clark, and S. Shenker, Integrated Services in the Internet Architecture: an Overview, IETF, June 1994

[3] A. Ponnappan, L. Yang, R. Pillai, and P. Braun, “A policy based QoS management system for the IntServ/DiffServ based

Internet,” Policies for Distributed Systems and Networks, 2002.Proceedings. Third International Workshop on, pp. 159–168, 2002.

[4] E. Mikoczy et al., “IPTV Services over IMS: Architecture and Standardization,” IEEE Comm. Mag., vol. 46, pp. 128-135,May 2008.

[5] I. Más et al., “IMS-TV: An IMS-Based Architecture for Interactive, Personalized IPTV,” IEEE Commvol. 52,pp. 156-163, Nov. 2008.

[6] ETSI, “NGN Functional Architecture Release 1,” ES 282 001 V1.1.1, TISPAN, December 2005.

[7] ***, “Aptixia IxLoad: Video- IGMP, MPEG, RTSP and RTP”,Ixia 2007.

[8] G.Armitage, Quality of Service in IP Networks, New Riders Publishing, 2000.

[9] IETF, "SDP: Session Description Protocol", RFC 4566,July 2006. Available: http://www.ietf.org/rfc/rfc2327.txt.

[10] IETF, “SIP: Session Initiation Protocol”, RFC 3261, June 2002. Available: http://www.ietf.org/rfc/rfc3621.txt.

[11] SLA Management Handbook – Volume 4: Enterprise Perspective, ISBN: 1-931624-51-8, Document Number: G045, TMF reference

GB917. October 2004.

[12] RFC 3588 “Diameter Base Protocol”, September 2003.Available: http://www.ietf.org/rfc/rfc2748.txt.

[13] Policy and charging control over Rx reference point (Release 9) 3GPP TS 29.214 V9.0.0 (2009-09). Available:http://www.3gpp.org

[14] R.Ferrus,A.Gelonch,F.Casadevall,J.Pérez,O.Sallent,R.Agusti,N.Nafisi,L.Wang,M.Dohler,H.Aghvami,and P.Karlsson. End-to-

end QoS architecture for multi-domain and wireless Heterogeneous Access Network: the EVEREST approach, March 2004

[15] J.Kim, S.Kim, B. Lee, and J.choi.policy-based-control QoS Control for open Service in BcN, February 2005.

[16] http://lartc.org/howto/lartc.adv-qdisc.dsmark.html.

277