2011 International Conference on Information and Electronics Engineering
IPCSIT vol.6 (2011) © (2011) IACSIT Press, Singapore
Prioritization of lineare TV sub traffic in the IPTV over IMS session
D.LEGHROUDI1, M.BELFKIH1, N.MOUMKINE2 and M.RAMDANI 2
1
2
Networks Laboratory, Institut National des Postes et Télécommunications, Rabat, Maroc
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 ”Besteffort” 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
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, 2PVR, 3BC.
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
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.
160
140
Latency(ms)
120
BC traffic
100
VoD traffic
80
PVR traffic
60
40
20
0
0
1000
2000
3000
4000
5000
6000
throughput(packets/s)
Figure 7: Latency of BC, PVR and VoD traffics before the change of DSCP values.
140
Loss(Packets)
120
100
BC traffic
80
PVR traffic
60
VoD traffic
40
20
0
0
50
100
150
200
250
Throughput(% of 1Gbps)
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
180
160
Latency(ms)
140
120
BC traffic
100
VoD traffic
80
PVR traffic
60
40
20
0
0
1000
2000
3000
4000
5000
6000
throughput(packets/s)
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.
160
140
Loss(Packets)
120
100
BC traffic
80
PVR traffic
60
VoD traffic
40
20
0
0
50
100
150
200
250
Throughput(% of 1Gbps)
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-toend 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