This regular paper was presented as part of the main technical program at IFIP WMNC'2011

978-1-4577-1193-0/11/$26.00 ©2011 IEEE

Using PR-SCTP for IPTV QoS Adaptation over IMS Network

Sinda Boussen, Nabil Tabbane Research Unit MEDIATRON

Higher School of Communication of Tunis (SUP’COM) Tunisia

{sinda.boussen, nabil.tabbane}@supcom.rnu.tn

Julien Arnaud, Francine Krief CNRS-LaBRI Laboratory

University of Bordeaux, IPB France

{arnaud, krief}@labri.fr

Abstract—In recent years, we have seen the emergence of real-time applications that have delay and reliability constraints. The challenge of the transport protocol is to provide a reliable service while reducing the delay. SCTP is a reliable transport protocol that have inherited the best characteristics of TCP and UDP and provided new attractive features such as multi-homing and multi-streaming. In this paper, we suggest the use of SCTP with the partial reliability extension as a transport protocol for the IPTV services in the IMS network, in order to improve the network performance and maximize the user satisfaction. Moreover, we have proposed an mSCTP based mobility scheme to guarantee service continuity during handover to IPTV users over IMS.

Keywords— PR-SCTP; QoS; IMS; IPTV; mSCTP

I. INTRODUCTION Although SCTP (Stream Control Transmission Protocol)

[1] was originally designed to carry telephony signaling over IP networks, in recent years it has evolved to become a general purpose transport protocol like TCP (Transmission Control Protocol) and UDP (User Datagram Protocol). Later, SCTP was extended to support partially reliable and partially ordered services for applications. The Partial Reliable SCTP (PR-SCTP) [2] allows the user to select the partial reliable service for each stream, so both the reliable and the unreliable data traffic can be multiplexed into the same SCTP association.

With the partial reliability extension, SCTP is able to ignore lost streams which are no longer useful, instead of waiting until they are retransmitted. This would be very interesting for real time multimedia applications like video streaming or VoIP.

In the PR-SCTP scheme, the SCTP client can inform the server that it supports the Partial Reliable extension by setting a flag in the INIT chunk. Then, the FORWARD-TSN control chunk will be used to inform the server about the expiration of the data chunks for real time applications. When a FORWARD-TSN is received, the server will advance the cumulative TSN point according to the received value. PR-SCTP can also provide “timed reliability” service to transport real time IPTV traffic. The timed reliability service is an extension of the lifetime concept in SCTP. This service allows

the user to specify the time period limit that the sender attempts to transport the message. When this lifetime expires, the message is discarded by the transport layer.

Several research studies have evaluated the performance of SCTP and PR-SCTP as a transport protocol for real-time multimedia services. In [3], authors show the advantage of using SCTP over SIP (Session Initiation Protocol) to transport multimedia data packets, by comparing the quality of video frame received via UDP and SCTP. Simulation’s result confirms that the SCTP image is better than the UDP image in terms of quality of service. Other research presented in [4] [5] [6] discussed the interest of using SCTP to transport SIP traffic, based on a comparison of the three transport protocols under different network conditions. Through experimental result, authors note that SCTP becomes more performing when the network conditions degrade.

Other works such as [7] [8] have been done to evaluate the performance of the PR-SCTP for the transmission of real time multimedia streams. Also in [9], authors show that using PR-SCTP as a transport protocol for IPTV application provides better performance than TCP in terms of delay and UDP in terms of quality of service. In [10], authors compared the benefits and the drawbacks of using PR-SCTP instead of TCP or UDP to transport SIP traffic. This work shows that the use of PR-SCTP as the transport protocol between the IMS entities improves the network performance. In [11] authors proposed a differentiated partial reliability per frame type method to transport MPEG-4 multimedia traffic. This work show that according a high reliability level to the I frames allows improving the quality of the decoded video stream, since the P and B frames depend on the I frame. The work presented in [12] investigated the impact of the retransmission-based reliability on the transport of real time video application, by developing a probabilistic model to determine the best limited retransmission number per frame type. In presence of high delay and important packet loss ratio, the proposed model provides the best trade-off between reliability and delay for video streaming applications.

This related work showed the advantages of using PR-SCTP instead of UDP to transport SIP signaling messages and

IPTV session parameters Renegotiation

multimedia traffic with real-time constraint across heterogeneous networks. Therefore, we recommend the use of PR-SCTP as a transport protocol for IPTV service over IMS in order to improve the performance of the PQoS aware management solution [13], developed under the ADAMANTIUM project. In fact, we have updated the IMS client architecture to support the multi-homing feature, and proposed an updated architecture of the QoS adaptation process using PR-SCTP. Additionally, we have proposed a mobility solution based on SCTP DAR extension [14] and SIP re-invite mechanism to provide a satisfactory QoS without service interruption to the mobile IPTV users over IMS network.

The rest of the paper is organized as follows. Section II presents the cross layer QoS adaptation solution for IPTV services. Section III describes the characteristics and the extensions of SCTP that will be considered to enhance the solution presented in the previous section. Section IV presents the updated architecture of the QoS adaptation process and the proposed mobility approach based on mSCTP. Finally, Section VI concludes the paper and points out future work.

II. IMS BASED ARCHITECTURE WITH PQOS MECHANISM In this section, we will describe the cross layer QoS

adaptation solution for IPTV services through IMS network [13] which is developed in the ADAMANTIUM project context in order to maximize the end user satisfaction and optimize the utilization of the network resources. Authors in [13] combine User profile modeling and adaptive techniques according to user’s environment evolution.

The novelty of the IMS-based architecture was mainly located at the IMS Application Server (AS) layer with the integration of a Multimedia Content Management System (MCMS), at the end user which employs a user profile model, and at the Media Server and Resource Function (MSRF).

• MCMS

Located at the Application Server (AS) layer of the IMS architecture, the Multimedia Content Management System (MCMS) is used to perform dynamic cross layer adaptation of the IPTV stream based on Perceived Quality of Service (PQoS) measurements at the end-user side. In fact, when PQoS degradation occurs at the end-user terminal, a PQoS alarm is sent to the MCMS by the user equipment (UE). Then the MCMS triggers monitoring actions and gathers the monitoring information (network statistics, service delivery information) in order to define a cross layer adaptation action.

• PQoS aware IMS client

In the architecture proposed in [13], the PQoS enabled user terminal integrates a monitoring module and a UP (User Profile) management. The UP management is responsible for gathering the user’s environment information and sending them to the MCMS.

• MSRF

The Multimedia Server and Resource Function (MSRF) is a Media Resource Function (MRF) module with additional functionality. The MSRF function is to terminate the SIP session initiated by the user, create and manage IPTV media

sessions. When the MCMS receives a PQoS alarm, it sends a monitoring request to the MSRF which has to send back the information collected to the MCMS. Then, the MSRF receives the adaptation request from the MCMS and renegotiates the IPTV stream parameters with the end-user in order to adapt the service provided to the network condition evolution.

Monitoring Actions

Monitoring Report

Figure 1. IMS based architecture with PQoS mechanism

Figure 1 summarizes the actions employed to adapt the IPTV session to the new network conditions in order to provide a satisfactory quality of service to the user.

III. OVERVIEW OF SCTP AND ITS EXTENSIONS In IMS environment, the real time multimedia traffic is

generally transported over UDP because of delay constraints; however UDP raises the reliability issue since it hasn’t congestion control mechanism. Thanks to the SCTP new interesting features and the partial reliability extension, SCTP (PR-SCTP) represents the appropriate candidate to replace UDP by providing both latency requirement and partial reliable transport of real time applications.

In what follows, we will present the attractive characteristics of SCTP (multi-homing and multi-streaming) and the SCTP extensions which will improve the network performance. In fact, the partial reliability extension allows improving the user’s perceived quality of service (PQoS) for the IPTV service in IMS network; while the DAR extension ensures service continuity during handover over different access networks.

Adaptation Action

PQoS

Alarm

Access Network • Monitoring

interface

Core Network • Monitoring

interface

User Terminal • UP Management

• PQoS monitoring

MCMS • Monitoring interface

• Adaptation interface

Application Server

2

3

1

MSRF • QoS Monitoring

• Adaptation interface

4

5

A. User Profile management in multi-homed IPTV client architecture In SCTP terminology, a connection between two endpoints

is called association. With the support of multi-homing, SCTP is able to implement an end to end communication session transparently over multiple physical paths, where each path is identified by an IP address. At the set up of an SCTP association, each endpoint provides a list of IP addresses of the endpoint and an SCTP port. One of the IP addresses from the returned list is selected as the primary path. Data packets are transmitted over this primary path. The other paths, called secondary path, are used for data retransmission. Thus, the multi-homing feature will enable SCTP to increase the network reliability by providing a certain degree of network stability to critical transmission paths. For these reasons, we will consider a multi-homed IPTV Client in our proposal.

The multi-homed IPTV client architecture is based on a user profile model. The user profile is defined in an XML document [13] containing information about the general user profile (basic user information), the device profile (device user description), the network profile (networks that the user can access), the service profile (service information), and the context profile (user environment information).

We will first focus on the context profile which represents the dynamic component of the user profile. In fact, it includes information about the user information which is dynamically updated such as time, location, device and network used, the set of running applications and the PQoS parameters (primary path PQoS, secondary paths PQoS). To support the multi-homing feature of SCTP, the context profile must be able to save information about the active interface and the other interfaces which are in stand-by mode. PQoS of secondary paths can be estimated using the path monitoring information. Path monitoring is performed using HEARTBEAT chunks which are sent periodically to know which addresses defined in the association are reachable.

Figure 2. Multi-homed IMS client architecture

In the PQoS aware IMS client architecture shown in Figure 2, we distinguish the UP management module, the IPTV application interface, the SIP Agent, the monitoring module and the viewer. The IMS client architecture modification to support multi-homing property, concerns mainly the component Context Manager (CM) of the UP management module. The CM is responsible for the update of the dynamic part of the user profile and includes a set of functions such as listening to media session monitoring in order to detect PQoS degradation.

To determine the PQoS of the secondary paths we add a new component called “secondary path monitoring” that provides information about the alternate paths state to the CM. As no data chunks are sent on these paths, SCTP uses a HEARTBEAT mechanism to detect any changes in the reachable state of a destination address, and also to update the Round Trip Time (RTT) measurement for each of these secondary addresses. Each heartbeat packet contains a timestamp of when it was sent. When the heartbeat ACK packet is received, the time delay difference can be used to estimate the Round Trip Round (RTT) for secondary paths.

Since the CM interacts with the media session monitoring module and the secondary path monitoring module, it will be able to compare the PQoS of the different paths and then take path switchover decision.

B. Multi-streaming and IPTV service With the multi-streaming support, SCTP is able to transmit

multiple independent multimedia sessions within the same association by using different stream identifiers. As shown in Figure 3, when SCTP is utilized by IPTV application, only one connection is established through which all the channel threads are transferred independently.

Figure 3. Multi-streaming for IPTV service

Thanks to the multi-streaming feature, SCTP overcomes the Head of Line Blocking Problem occurring in TCP connection, since only one stream is affected if there is a loss. According to [9], multi-streaming allows SCTP to improve the PQoS, by minimizing the gap of time perceived by the user when it switches to another channel during the IPTV session.

C. The Partial Reliability extension: PR-SCTP The partial reliability extension is negotiated during

association setup by specifying the Fwd TSN flag in the INIT chunk. If the endpoint supports the extension, it will send back an INIT-ACK with the Fwd TSN flag. Then, the FORWARD-

IMS Client

IPTV Client IPTV Application Server

Service Manager

Channel Manager

Viewer

Service Manager

Channel 1

Channel N

S1

S2 S1

S3

One SCTP association

UP User Profile API

SIP Agent

Media Session Monitoring on primary path

Secondary Path Monitoring

Context Manager

IPTV Application

Viewer

User Profile Manager

User Profile Data

Query Manager

TSN control chunk will be used to inform the endpoint about the expiration of the data chunks for real time applications.

Host A Host B

Figure 4. PR-SCTP association setup

With the partial reliability extension, PR-SCTP protocol provides a more flexible transport service to multimedia signaling and real time traffic, which are sent with either partial reliable, reliable or unreliable services according to their types and requirements. For IPTV traffic, PR-SCTP improves network resources utilization by retransmitting efficiently lost messages with high reliability level. For example, when we attribute a high reliability level to the I frames it will improve the quality of the decoded video stream, since the P and B frames depend on the I frame.

D. The DAR extension: mSCTP Mobile Stream Control Transmission Protocol (mSCTP)

[14] is an extension of SCTP with the addition of the Dynamic Address Reconfiguration (DAR) extension which enables endpoints to dynamically add, delete IP addresses and request the primary path change without interruption of the existing SCTP association. The multi-homing support and the DAR extension make mSCTP a mobility enabled transport protocol. To perform a seamless transport layer handover, DAR defines two new chunks Address Configuration Change (ASCONF) and Address Configuration Acknowledgment (ASCONF-ACK) and new parameters: Add IP Address, Delete IP Address, and Set Primary Address. Figure 5 illustrates the mSCTP mechanism to provide seamless handover for mobile users and the exchanged messages during the handover execution.

Figure 5. mSCTP mechanism for mobility management

During communication (1), the Mobile Node (MN) moves to another network and gets a new IP address (2). The MN is now accessible via the home and the foreign network. Then, the MN adds the new IP address to the SCTP association by sending SCTP ASCONF chunk with the “add IP” parameter to the Correspondent Node (CN) through the home network (3). The CN replies with an acknowledgment. When the MN leaves the coverage area of its home network, it notifies the CN to assign the new IP address as the primary IP address (4). The CN and the MN are now communicating via the new primary path (5). Finally, the MN deletes the old IP address from the SCTP association by sending SCTP ASCONF chunk with “delete IP” parameter to the CN that replies with an acknowledgment message.

IV. PROPOSED ARCHITECTURE FOR IPTV QOS ADAPTATION

A. PQoS Management using PR-SCTP In this paper, we propose to use PR-SCTP for the IPTV

service transmission in the IMS network. For that, we have to update the architecture of the adaptive QoS solution proposed in [13] to take advantage of the valuable properties of SCTP such as multi-homing, multi-streaming and the Partial Reliability extension allowing the transmission of both reliable and unreliable streams in the same PR-SCTP association.

In the updated architecture, the IMS client is multi-homed which means that it is reachable via several IP addresses. The primary path will be used to exchange data of the IPTV service; the other paths are monitored but will be used only in case of the primary path failure. So we have one active IPTV session per user which is via the primary path.

When the terminal perceives a PQoS degradation on the primary path, the Context Manager (CM) component will compare the different PQoS available, and decide whether the PQoS degradation will be treated locally by switching to a secondary path offering a better quality of service; or transmitted to the server application in order to initiate the standard QoS adaptation process.

If the primary path offers the best PQoS, the terminal will transmit the alert to the IPTV server, who will initiate the adaptation process. Otherwise, the terminal will switch to the interface that has the best PQoS. Then, it will renegotiate the IPTV session parameters by sending the SIP Re-invite command to change its IP address.

Figure 6 describes a sequence diagram of the messages that are exchanged to initiate an IPTV session, to execute the adaptation process and to terminate the session between the multi-homed end-user and the MSRF.

At the IPTV session initialization phase, the user terminal sends a SIP INVITE request with two bodies (SDP and XML body) to the IPTV Application Server (IPTV AS). While the XML body contains information about the user’s environment, the SDP body includes the IPTV session characteristics such as codec, video to play, frame size and bit rate. Then the User Equipment (UE) receives as response a 200 Ok message with the final negotiated SDP body.

INIT (Fwd TSN)

INIT – ACK (Fwd TSN)

The Context Manager (CM), which is a module of the User Profile Management, interacts with the monitoring modules and has access to the PQoS values of the different available paths. So, when it detects QoS variation indicating network condition deterioration, it will able to compare the Primary path’s PQoS with the secondary path’s PQoS in order to take a path switchover decision.

When the terminal user perceives a degradation of the quality of service initially negotiated, two scenarios are possible:

- Scenario 1: If no secondary path allows a better quality of service than that offered by the primary path, the UE

triggers a PQoS alert, which will be treated by the MCMS component in the IPTV AS.

- Scenario 2: if it exists, among the secondary paths, a path which offers a better quality of service than that offered by the primary path; the CM will initiate the Path Switchover. Then, the SIP agent sends a SIP RE-INVITE request with a new SDP body to modify the parameters of the IPTV session and inform the IPTV AS of the IP primary address change. The MSRF sends back 200 Ok message with the new SDP body.

Finally, to terminate the IPTV session, the UE sends a SIP BYE request, and the MSRF sends back a 200 Ok message.

Primary Path Monitoring UPM

SIP Agent CM

Secondary Path

Monitoring

Primary Path PQoS degradation

PQoS comparison Path Switchover decision

Scenario1

Scenario2

OR

CSCF IPTV AS/ MCMS

MSRF

PR-SCTP : INIT (Fwd TSN)

PR-SCTP: INIT- ACK (Fwd TSN)PR-SCTP

Association Setup

IPTV Session Initiation on primary path SIP : Ack SIP : Ack

DATA

SIP : Invite + SDP1& XML

SIP : Invite + SDP1& XML

SIP : Invite + SDP1& XML

SIP : Ack

SIP : 200 OK + SDP1 SIP : 200 OK + SDP1 SIP : 200 OK + SDP1

PQoS Alarm IPTV session SDP renegotiation

SIP : Ack SIP : Ack

Adaptation Action

DATA

Path Switchover

PQoS Alarm

DATA (in buffer)

Primary Adress change in PR-SCTP association

SIP : Re-Invite + SDP2& XML

SIP : Re-Invite + SDP2& XML

SIP : Re-Invite + SDP2& XML

SIP : 200 OK + SDP2 SIP : 200 OK + SDP2 SIP : 200 OK + SDP2

SIP : Ack

DATA (on new primary path)

QoS Adaptation Process

IPTV Session Ending

SIP : BYE SIP : BYE SIP : BYE

SIP : 200 OK SIP : 200 OK SIP : 200 OK

PR-SCTP Association Shutdown

PR-SCTP : Shutdown

PR-SCTP : Shutdown- ACK

PR-SCTP : Shutdown- complete

Multi-homed User Equipement

Figure 6. PQoS adapatation process for multi-homed IPTV client

IP 1 IP 2

The advantage of this solution is that the degradation of the quality of service perceived by the user can be treated locally at the UE side. This will allow us to: gain in terms of delay since we do not need to send the alert to the application server to be processed; increase throughput, since our proposal consists on switching to the path that offers the best performances; and avoid the overload of the application server (MCMS scalability problem) as all PQoS alerts are not automatically forwarded to MCMS.

B. Mobility Management using the DAR extension of SCTP Mobility management can be performed at different layers

in the TCP/IP stack to benefit from the advantages of different layers. In this work, we will focus on transport and application layer handovers. The SIP is the protocol used to achieve application layer handover, while mSCTP is the most representative protocol of the transport layer handover. Thanks to multi-homing and the DAR function, mSCTP is currently receiving a lot of attention to perform seamless handover over heterogeneous networks. However, a key problem with mSCTP is that does not provide location management of the mobile node. For that reason, we propose to combine the DAR extension of SCTP and Re-invite mechanism of SIP to perform a seamless handover over IMS.

• SIP Based Mobility management The standard SIP handover over IMS is mainly based on

the re-invite concept. In fact, when a mobile node (MN) moves into the coverage area of a new network, and after acquiring a new IP address, it will send a re-invite request to inform the correspondent node of its new IP address. During handover period, there is an interruption of service due to registration and IP configuration time. The induced delay is critical especially for time-sensitive multimedia applications, since long delay can be perceived by the user as a cut in the communication.

There have been many studies that proposed extensions to SIP protocol in order to reduce long delay and high loss of the SIP handover. For instance, in the mSIP extension [15], authors proposed to send duplicated data on both old and new addresses (bi-casting scheme) during the handover period. .

• Proposed SIP and mSCTP based approach In order to provide a satisfactory QoS without service

interruption to the mobile IPTV over IMS network, we propose an mSCTP based mobility solution supporting location management. The proposed solution represents a complete mobility management solution as it includes location and handover management. We assume that the IPTV client is moving during an active session to another access network. The corresponding signaling flow diagram is shown in figure 7 and the handover steps are as follow:

1. When the mobile node (MN) moves into the coverage area of a new wireless access network, it obtains an IP address via DHCP mechanism.

2. Then, the MN have to add the new IP address to the existing association by sending an ASCONF message

with the option “add IP address”. The Correspondent Node (CN) replies with an ASCONF-ACK message.

3. When the PQoS provided by the new network becomes better than the PQoS of the used network, a handover is initiated. The MN sends an ASCONF message with the option “Set Primary Address, IP2” to the CN through IP1. After receiving the ASCONF message, the CN starts transferring data through the new primary address (IP2).

4. In order to update its location information, The MN sends a “SIP REGISTER” request to the SIP server that replies with a “SIP 200 OK” message.

5. Then, the MN sends a “SIP RE-INVITE” request with an updated SDP specifying the address through which data and signaling flow should be transmitted. Then, the CN will respond with “SIP 200 OK” message.

6. Finally, the MN sends an “ASCONF” message to the CN with the “Delete IP” parameter to remove the old primary address from the association.

Figure 7. SIP and mSCTP based mobility management

Access Network

1

Access Network

2

SIP Proxy Server

IPTV Server

Data

Multi-homed UE

IP Address configuration

mSCTP: ASCONF (Add IP address, IP 2)

mSCTP: ASCONF - Ack

mSCTP: ASCONF (Set primary address, IP 2)

Data Data

SIP : REGISTER

SIP : 200 OK

SIP: RE-INVITE (Address IP update)

SIP : 200 OK

mSCTP: ASCONF (Delete IP address, IP 1)

mSCTP: ASCONF - Ack

UE Moving

mSCTP: ASCONF - Ack

Location Update

IPTV Session change

Remove IP address from association

Add IP address

Handover Decision based on PQoS measurements

Data

In our approach, we considered the perceived QoS of IPTV service to take handover decision which enables us to optimize the handover decision. Moreover, the “make before break” concept provided by the DAR function allows to reduce long delay and high loss of the SIP handover and ensures service continuity during handover execution. Therefore, we notice that the proposed solution performs a seamless transport layer handover by exploiting multi-homing feature and the DAR function, and a user location update after handover thanks to the SIP re-invite mechanism.

Conceptually, the proposed mobility solution provides seamless mobility as well as a location update of the MN when the primary IP address changes. Nevertheless, we are assuming that the MN has the time to get a new IP address and add it to the SCTP association as primary IP address before losing the connection via the old access network. This hypothesis depends mainly on the size of the overlapping area and the movement speed of the MN.

V. CONCLUSION In this paper, we proposed an enhancement of the QoS

adaptation process for the IPTV applications by initiating a path switchover when the IPTV client has a secondary path offering better performance than the primary path. This will allow us to overcome the PQoS degradation in an optimized and more effective way. We have also proposed a mobility management solution based on the DAR extension of SCTP and the Re-invite mechanism of SIP to guarantee service continuity to the mobile user in IMS network. In future works, we will evaluate the performance of the proposed solution by implementing a prototype. Then we will try to improve our proposed mobility management by using a cross layer approach based on MIH and mSCTP in order to optimize handover’s decision and execution.

REFERENCES [1] R. Stewart, et al. “Stream Control Transmission Protocol”, RFC4960,

September 2007.

[2] R. Stewart et al. “Stream Control Transmission Protocol (SCTP) Partial Reliability Extension”, RFC 3758, May 2004

[3] Fang-Yie Leu, “a novel network mobility handoff scheme using SIP and SCTP for multimedia applications”, Journal of Network and Computer Applications (JNCA 2009), Volume 3, Issue 5, September 2009

[4] J. Rosenberg et al. « The Stream Control Transmission Protocol (SCTP) as a transport for the Session Initiation Protocol (SIP) » RFC 4168, October 2005

[5] G.Camarillo; R. Kantola; H. Schulzrinne; « Evaluation of transport protocols for the session initiation protocol», IEEE Network, October 2003

[6] G. De Marco, D. De vito, M. Longo and S. Loreto« SCTP as a transport for SIP: a case study », The 7th World Multiconference on Systemics, Cybernetics and Informatics (SCI 2003), July 2003

[7] T. Maeda, M. Kozuka and Y. Okabe, “Reliable Streaming Transmission Using PR-SCTP”. In Proceedings of the Annual International Symposium on Applications and the Internet (SAINT’09), pp.278-279, 2009.

[8] Ch. Xu, E. Fallon, Y. Qiao, G. Muntean, X. Li, A. Hanley, "Analysis of Real-time Multimedia Transmission over PR-SCTP with Failover Detection Delay and Reliability Level Differential", the International Conference on Communication Software and Networks (ICCSN 2009), pp.768-772, 2009.

[9] S.T. Kim, S. J. Koh, Y. J. Kim, "Performance of SCTP for IPTV Applications", The 9th International Conference on Advanced Communication Technology (ICACT 2007), pp. 2176-2180, Feb. 2007

[10] E. Lopes Filho, G. T. Hashimoto, P. F. Rosa PhD, «An IMS Control and Access Layer PR-SCTP Based Network », The 4th International Conference on Networking and Services (ICNS), pp. 61-66, Mars 2008.

[11] M. Molteni and M. Villari, “Using SCTP with Partial Reliability for MPEG-4 Multimedia Streaming”, In Proc. Of BSDCon Europe 2002. October 2002

[12] H. Sanson, A. Neira, L. Loyola, M. Matsumoto, ”PR-SCTP for real time H.264/AVC video streaming”, The 12th International Conference on Advanced Communication Technology, (ICACT 2010), pp. 59-63, February 2010.

[13] J. Arnaud, D. Negru, M. Sidibé, J. Pauty, H. Koumaras, “Adaptive IPTV services based on a novel IP Multimedia Subsystem”, Journal of Multimedia Tools and Applications, Springer, 2010.

[14] R. Stewart, et al. “Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration”, RFC5061, September 2007.

[15] S. J. Koh, W. Hyun, “mSIP: Extension of SIP for soft handover with bicasting”, IEEE Communications Letters, Volume 12, Issue 7, July 2008.