Scalable Architecture and Evaluation for Multiparty ... - CiteSeerX

IEEE JOURNAL SPECIAL ISSUE ON BROADBAND IP NETWORKS VIA SATELLITE, VOL. X, NO. XX, 2004

1

Scalable Architecture and Evaluation for Multiparty Conferencing over Satellite Links Zhili Sun, Member, IEEE, Dan He, Haitham Cruickshank, Lei Liang, Antonio Sánchez, Carlos Miguel, Vincenzo Schena, Clementina Tocci and Belén Carro

Abstract — This paper describes the architecture of a proposed multiparty conferencing system for satellites. Different conferencing models are discussed and compared. A Session Initiation Protocol (SIP) based conference signalling model and an extension to PIM-SM that supports quality of service (QoS) in DiffServ networks are proposed, as particularly suitable for multiparty conferencing applications over satellite links. The paper also presents key issues and potential solutions of scalable QoS multicast services for multiparty conferences over satellite. End-to-End QoS parameters for voice and video are measured and analysed on a prototype.

Index Terms — multiparty conferencing, Scalability, Multicast, Quality of Service, SIP..

I. INTRODUCTION ommunication networks have grown tremendously in the last few years. The culmination of satellites, optical fibre, mobile

C

wireless technology, and the advent of the World Wide Web have made the Internet accessible to the population at large. As

a result, a set of emerging applications such as Voice over IP (VoIP), multiparty conferencing, distributed simulation and games demand higher bandwidth, QoS, and multicast availability. However, the complexities of deploying and operating a large scale of terrestrial multicast networks can hinder such applications, at least for the near future. On the other hand, satellites can be ideally suited for multicast real-time traffic. In order to provide efficient multicast for wide area coverage, next-generation satellite systems are required. These emerging satellites with multiple spot beams and On-Board Processing (OBP) have new capabilities for dynamically routing between various spot beams. OBP can improve support for real-time applications such as IP telephony and multiparty conference services. Geostationary Earth Orbit (GEO) satellites are the most suitable for multicast and large scale conferencing, due to their global coverage and simple network management compared to Medium Earth Orbit (MEO) satellites and Low Earth Orbit (LEO) satellites. Integrated with terrestrial networks, the GEO system can be optimised for multicasting real-time traffic by providing a single satellite hop using only a small number of multicast-enable routers [1]. Moreover, next generation satellite communication systems have very flexible bandwidth-on-demand capabilities with onboard

. Manuscript received December 15, 2002; revised June 30, 2003. This work was supported by the EU IST project ICEBERGS (IST-2000-31110). Zhili Sun, Dan He, Haitham Cruickshank, and L. Liang are with University of Surrey, Guildford, GU2 7XH, UK. (email: [email protected]; [email protected]; [email protected]) Antonio Sachez is with Telefonica R+D. Carlos Miguel is with SIRE, Spain. Vincenzo Schena and Clementina Tocci are with Alenia Spazio, Italy; and Belen Carro is with University of Volladolid, Spain.


2

processing and switching [2], which are capable of meeting QoS requirements of multimedia services. However, integration of satellite links into the existing Internet infrastructure, providing end-to-end QoS support, is a challenge due to satellite propagation delay and high bit-error-rate in satellite links. At the present, among the above-mentioned emerging applications, IP multiparty conferencing is a challenging application in the terrestrial Internet [3], as this introduces the need for QoS and high data rate to achieve bandwidth efficiency. Nevertheless, multiparty conferences need usually to use multicast communication modes for data transmission. These applications also need complicated signalling support to create, invite, and terminate conference sessions. Designing and implementing such satellite terrestrial integrated systems have been carried out in the ICEBERGS (IP ConferEncing with Broadband multimedia over GEO Satellites) project of the European Commission IST programme [4]. Previous research to this work considered only terrestrial multiparty conferencing issues to some degree in terms of signalling, multicast routing and resource management. From signalling point of view, Singh [5] proposed SIPCONF, a centralized conferencing scheme based on Session Initiation Protocol (SIP) [6]. Their work explores issues related to a centralized conference server design. SIPCONF maintains the state of a conference at the conference server. Each conference user requires a point-to-point signalling connection with the conference server. It also takes part in processing both media stream and signalling. Therefore, SIPCONF suffers from not only single point failure but also scalability problems [3]. From routing point of view, extensive work has been done in intra-domain multicast routing protocols such as Multicast Open Shortest Path First (MOSPF), Protocol-Independent Multicast Dense Mode (PIM-DM), Protocol-Independent Multicast Sparse Mode (PIM-SM) [7], and Core Based Tree (CBT). However, little has been done in inter-domain multicast routing to take full advantages of satellite global coverage. For satellites, inter-domain multicast routing must minimise the bandwidth requirements. In addition and regarding QoS, two major approaches have been proposed by the Internet Engineering Task Force (IETF) to provide IP QoS: integrated services (IntServ) with Resource ReSerVation Protocol (RSVP) [8] and differentiated services (DiffServ) [7]. Neither of them is suited directly for multiparty conferencing for satellite due to scalability and complexity of these mechanisms. This paper presents the architecture of integrated satellite and terrestrial networks with particular focus on signalling, interdomain multicast routing architecture and scalable QoS mechanisms. In particular, we design a scalable SIP signalling scheme for multiparty conferencing over satellite links. We discuss and compare different conferencing models over satellite and propose a centralized signalling optimised for distributed media conference model. We also propose the architecture with multiple multipoint control units (MCU) to aggregate media traffic over satellite links. Furthermore, we propose an extension to PIM-SM to provide QoS support for multiparty conferences. Based on measurement and analysis on a prototype, we evaluate major QoS parameters for voice and video over the proposed scheme.


3

The rest of the paper is organized as follows. In Section II, we provide an overview of multiparty conferencing over satellite. In Section III, we describe a scalable strategy for multicast routing. In Section IV, scalable QoS support for multicast is discussed. In Section V, we validate the proposed architecture on a prototype. We present measure and analyse results on QoS for voice and videoconferences based on the prototype of the proposed architecture, and in Section VI, we conclude the paper and discuss directions of future work.

II. MULTIPARTY CONFERENCE OVER SATELLITE In this section, we present briefly the main components of multiparty conference over satellite, multiple MCU architecture, and design of SIP signalling for multiparty conferencing. Different conferencing models and their effects on satellite links are discussed and compared. A. Overview of Satellite System The objective of our work is to deliver multiparty conference services over the next-generation GEO satellite. It can be a regional satellite-based communications system, forming a continental network supporting a wide range of user data rates and applications. It is capable of supporting both burst traffic and continuous bit rate traffic. In particular, it offers OBP that provides end-to-end, single hop, meshed connectivity together with on-demand, QoS-guaranteed connections. The equivalent connectivity concepts to the terrestrial networks enable to maintain the advantages of satellite transmission in terms of user data distribution and service deployment. The innovative OBP adopted by the satellite network provides an ideal communication infrastructure for advanced Internet-based services.

Fig. 1. Prototype Scenario of Multi-party Conference Over Satellite


4

A typical satellite network can serve many service providers, each of which maintains a separate administrative domain. For reliability and security reasons, the control of the satellite network is centralized into a Network Operations Centre (NOC). This centralized control structure integrates satellite with terrestrial networks into the one hop satellite inter-working system as illustrated in Fig. 1. This figure presents our architecture where the satellite is an autonomous system (AS) linked with terrestrial networks that may be managed by different Internet Service Providers (ISPs) and private networks. For instance, Federated ISP 1 (F-ISP.1) presents an ISP service provider. Sub-network1 represents a private network. This network architecture supports the current Internet architecture and provides end-to-end connectivity. The satellite network provides all basic modes of connectivity including unidirectional point-to-point, bi-directional point-to-point, and unidirectional point-to-multipoint connectivity in order to satisfy different customer needs. By combining these modes, it is possible to support other complicated communication modes such as bi-directional and multipoint-to-multipoint connectivity. The use of OBP allows GEO satellites to provide effective bandwidth allocation to support multimedia services. The bandwidth allocation includes a minimum set of protocols and signalling procedures to control resource allocation on-demand. A resource demand mechanism called Dynamic Bandwidth Allocation Capabilities (DBAC) [9] is used for this function. DBAC is a priority-based scheme for bandwidth allocation on request. It allows allocating as much as available resource to provide QoSguaranteed connections for high priority traffic sources. DBAC then redistributes the unused traffic resources for low priority, and finally for best effort traffic sources. The choice of DBAC as a resource management mechanism is motivated by its costeffectiveness and scalability. This mechanism can support a low-latency resource allocation service, and QoS signalling can be therefore efficiently implemented via DBAC. We choose these facilities for QoS support to multiparty conferences. The important issues are how to make IP inter-work with the lower layer satellite system and how satellite system inter-networks with the terrestrial networks. The key device called inter-working unit (IWU) supports such functions. It plays the role like an IP router, has addressing and routing functions, and supports the Internet routing protocols [2]. B. Multiple MCU Architecture An important concept in multiparty conference is to use Multipoint Control Unit (MCU) for handling scalability of multiparty conferencing. A router can be co-located with the MCU. The router can support PIM-SM protocol to enable multicast. It can also act as an aggregator to handle media exchange as shown in Fig. 2.


5

Fig. 2. Multiple MCU Reference Model The MCUs provide the following benefits that: •

Concerning QoS, each MCU can balance the high bandwidth requirements of the real-time multimedia conference and the high cost of satellite bandwidth;

•

Concerning security, each MCU can be a proxy accessing the satellite links rather than allowing each end user to directly access the satellite; and

•

Concerning expensive end media mixing equipment, aggregating a group of users’ data in the middle between the end users and the satellite is a better choice.

In our model, several MCUs allow to co-exist in the same network. Each MCUs can collect unicast multimedia streams from different terminals, then manipulate them and generate multicast flows. This model minimizes the bandwidth usage as compared to a unicast conference and simplifies the terminal requirements. The mixed satellite-terrestrial network and the relatively high satellite delay imply that it is not desirable to send unicast audio/video from one terminal to a remote MCU through a satellite and then receive the composite signal again through the satellite link. The multiple MCU model can overcome this drawback by aggregation of media streams before multicasting. In this model, the needs end users do not need to have media mixing functions. C. Models of Multiparty Conference Signalling and media are two different aspects of multiparty conferences [10]. Four models have been proposed for scalable media distribution [5]. •

Centralized server: In this model, a single conference server receives all traffic from all participants, and mixes if needed and redistributes media stream back to participants.


•

6

Full mesh: In this model, each participant logically has a unicast communication channel with other endpoint hosts. Endpoint hosts sum and mix audio streams. With satellite links, this model results in longer latency because each active participant has to connect with remote participants via satellite links.

•

Multicast: In this model, every participant can communicate using the network multicast function. This model is well suited for large conference. In such a case, all participants have to share a set of common codecs.

•

Unicast receive and multicast send: This model combines the benefits of the central server model and the multicast model.

From a media distribution perspective, the first three models are not suitable for satellite because these models either require each active user’s traffic to pass through the satellite without aggregation or they lack of flexibility in some aspects such as codecs. With respect to the MCU architecture, the fourth model is the best choice for satellites. In such model, the media distribution is first aggregated at the senders’ MCU before sending to the destination over satellite. The aggregation process reduces the overhead of individual media streams through satellite links. The other important aspect of multiparty conferences is signalling. Signalling for multiparty conference concerns creation, invitation and termination of conference sessions. Mbone tools such as Session Directory Revised (SDR), Robust Audio Tool (RAT) and Video Conference tool (VIC) do not address signalling issues, such as how conference entities can manage and control sessions and how to inform third party users to join a conference. SIP [6] has recently used for conference signalling [5] [12]. SIP is a signalling protocol that defines how to establish, maintain and terminate Internet sessions including multiparty conferences. In particular, SIP can be used to introduce control services for a multiparty conference in terms of: •

Member Management: inviting users to participate in and leave a running conference without disturbance;

•

Management of the set of application/media sessions: the main function of this service is the negotiation and change of the application session configuration;

• •

Floor control: implementing access control rules for multi-users accessing to a conference; and

_

Billing: accounting resource usage.

One important concept in SIP is to make use of Uniform Resource Identifier (URI) that identifies a user, expressed in the form of [email protected]. SIP URI is used as a conference user’s destination. Control and management of sessions needs the SIP URI to perform user identification. These services are taken by SIP location servers and by registrars to manage and search SIP URI. The core SIP specification supports a variety of conferencing models. A SIP conference model addresses how user can be invited or join a conference via the SIP text-based command INVITE and REFER. Rosenberg and Schulzrine [12] have summarized the current conference models based on SIP.


7

D. SIP Signalling models for Multiparty Conference From Fig. 1, it can be seen that the network forms a star topology. There is one conference server and N participants. The conference server is located in the domain F-ISP.2. Let us analyse the uplink cost, as it is more sophisticated and more critical than downlink, for different signalling models as the following: •

End mixing: each end user invites one other user to join the conference at the cost of one INVITE message over satellite. In the case of N participants, the uplink cost is O(N).

•

Multicast: the signalling employs network multicast. One user invites N other users to join the conference. This user sends a single INVITE message to a signalling channel that is multicast-enabled. Therefore, the uplink cost is only O(1).

•

Dial-in: users who want to join a conference call a conference server. The server acts as a normal SIP User Agent (UA) and

_

maintains point-to-point SIP relationships for each user. A user is invited to join using the SIP REFER message. For example, user A wishes to ask user B to join. User A would send user B a REFER message that includes the conference server’ s SIP URI. User B would send an INVITE message to the server. All of these messages go through the satellite. Therefore, the cost is O(2N). •

Dial-out: the model is a variation of a dial-in conference server. Instead of the user sending an INVITE message to the conference server, the conference server chooses the users to join a conference and sends them an INVITE message. The cost is the same as the Dial-in model, i.e. O(2N).

•

Ad-hoc: this model deals with third party calls. Users start with a normal SIP call. The third party user is invited to join using REFER message. The signalling structure is star. Wherever the conference server is, there will be twice as many INVITE and REFER messages as the number of users going through the satellite. Therefore, the signalling cost is O(2N).

•

Centralized Signalling Distributed Media (CSDM): The conference server sends re-INVITE messages to the users when a new user joins a conference. Only one message broadcasts through the satellite. With the satellite multicast, this INVITE message can be sent to all users via multicast. Thus it increases scalability. On the other hand, because of the multiple MCU model in the architecture, the media is still sent directly between participants. The signalling cost is O(1).

Table I summarizes the signalling cost of these models impact on satellite uplink. Based on the above analysis, we can see a centralized signalling and multiple MCU based media distribution model is the most scalable model. This model is better than SIPCONF mentioned earlier because we use distributed MCUs for media mixing though signalling is centralised.


8

TABLE I COMPARISON OF CONFERENCE MODELS Model Name

Signalling Structure

Uplink Cost

Scalable

End-Mixing

Tree

O(N)

Small

Multicast Dial-In Ad Hoc Dial-Out Central

Pairs Star Star Star Star

O(1) O(2N) O(2N) O(N) O(1)

Large Medium Medium Medium Large

E. Optimised Centralized SIP Signalling for Multiparty Conference According to the SIP specification [6], a user can invite another user to join a conference in end-to-end signalling mode. SIP proxy servers and redirection servers process all the signals for setting up the conference. A SIP proxy server manages location service and call processing. A redirection server deals with call forwarding function. The SIP proxy server and redirection server both take part in location service and call redirection, e.g. SIP location registrar in the domain F-ISP.1 and SIP proxy Server 2 in the domain F-ISP.2 shown in Fig. 1. The registration servers manage user locations. When a user makes a call to another user, the means of binding the callee is similar to the use of DNS. There are two strategies for registering user locations in a satellite context. One is to use distributed location servers. Each AS can have one or more registration servers. Once a user makes a call, the INVITE message that contains the destination user’ s URI is sent to those servers. However, for a satellite context, a distributed location service is not a good choice because in that case, each call will incur many response messages through the satellite. Thus it results in uplink bandwidth waste and incurs scalability problems. The second strategy is an optimised centralized SIP signalling. The basic idea is to use two levels of signalling: local signalling and global signalling. A SIP registration server in the NOC possesses the state of the conference when global signalling is used and each local SIP proxy deals with the local domain state of the conference. Each local SIP proxy plays a role of local signalling process. The registrar in the NOC records the state of all MCUs of the domains. Once a call is made from one domain, e.g. user B1 wants to join a conference, it only sends an INVITE message to user B1’ s SIP proxy, i.e. SIP proxy server 2. The SIP proxy server 2 knows where the conference server is. Therefore, it sends a REFER message to invite MCU2 to join the conference. It will also contact the NOC’ s SIP registrar for billing and security purpose. A similar idea to optimise signalling traffic can be found in [13].


9

Fig. 3. An Example of ICEBERGS Signalling In order to increase scalability, a SIP registration server in the NOC only stores the location of MCUs while the other SIP location servers remember the location of their own local users. Fig. 3 shows an instance of signalling processing where user D invites user A to join a conference in the scenario shown in Fig. 1. In this figure user D sends an INVITE message with conference multicast group address using Session Announce Protocol (SAP) [14] to its local SIP proxy. The SIP proxy passes this message to a register in the NOC. The NOC registrar sends an INVITE message with the conference group address to its MCU and also forwards its INVITE message to SIP proxies in the domains: F-ISP.1 and F-ISP.2. When the SIP proxy server responds with its INVITE message, it indicates user D has joined the conference. At the same time, the MCU in user D domain can receive and send stream data. When user B1 is invited to join the same conference, it first contacts SIP proxy server 2 with a conference address. The SIP proxy server2 sends an REFER message with MCU2 to a registrar in the NOC. The registrar sends an INVITE message to user B1’ s MCU2 to join the conference. Once user B1 receives the “200 OK” message, it has joined the conference. Now user A and user B1 can talk. In our architecture, we separate signalling and media in order to increase scalability. We use multiple MCUs to handle media data. Each user in one AS can unicast media data to its MCU, while there are multicast communications among multiple MCUs so as to leverage satellite multicast functionality.


10

III. SCALABLE STRATEGY FOR MULTICAST ROUTING This section explains how a proposed inter-domain multicast routing framework helps scalability of multipart conferencing. As described in [15], two solutions have been proposed for the inter-domain multicast routing: One is Border Gateway Multicast Protocol (BGMP) /Multicast Address-Set Claim (MASC) [16]. This solution tackles the multicast address allocation issue. The other is PIM-SM/MSDP [17]/MBGP [11]. In our architecture, we have chosen PIM-SM/Multicast Source Discovery Protocol (MSDP)/Multi-protocol Border Gateway Protocol (MBGP) as a practical multicast routing framework because it has been already deployed. PIM-SM is an intra-domain multicast routing protocol. It provides rendezvous points (RPs) for receivers to record new sources. Senders use RPs to announce their existence. Routers explicitly send a join message to RPs when their local or downstream hosts want to join a multicast group. Within a PIM-SM domain, receivers send join messages toward one RP and sources send register messages to the same RP. However, there is no way for a RP in one domain to find out the sources in other domains that use different RPs. No mechanism is provided to allow RPs to communicate with each other when one receives a source register message. Consequently, a protocol named Multicast Source Discovery Protocol (MSDP) was developed to solve this problem. MSDP learns about active sources in one domain and sends its IP address and group address to all MSDP peers in the other domain. One of the key concerns of ISPs is to minimize the learning curve for dealing with the additional operational burden to multicast peering. In addition, they would have a set of highly flexible peering controls for multicast routing. A solution for this concern consists of using defined extensions to BGP4 [11] to carry multicast routing information that is used for Reverse Path Forwarding (RPF) calculations between ASs. One problem is how to reduce MSDP messages for scalability in satellites. To tackle the MSDP deployment shown in Fig. 4, two schemes are proposed. In the first scheme, each Multicast router (MR), which plays the role of both RP and MSDP/MBGP peer, should peer with the Satellite Rendezvous Point (SRP) residing in the NOC. In turn, the SRP should peer with all MRs belonging to a conference. Thus, Source Announce (SA) messages are firstly sent to the SRP of the NOC by the RP of the ISP domain where the multicast source is, and then after RPF check forwarded to all the RPs of the conference that are directly reachable through satellite links. Such traffic may be carried out over the same pointto-point bi-directional satellite traffic channel used to carry out MBGP sessions.


11

Fig. 4. Inter-domain Multicast Routing An alternative scheme is to deploy MSDP mesh groups, but in this case satellite traffic channels introduce a large latency. As such, if N is the number of RPs to be peered, then the former scheme requires N point-to-point bi-directional satellite traffic channels for both MBGP and MSDP sessions execution, while the latter requires point-to-point bi-directional satellite traffic channels for the MSDP mesh group, and N for MBGP peering with a NOC BGP peer. Obviously the former scheme has the drawback of requiring two satellite hops, but since this MSDP does not carry multicast traffic, then this is a minor drawback compared to the high demand for satellite resources required by the second scheme.

IV. SCALABLE QOS SUPPORT FOR MULTIPARTY CONFERENCE In this section, we present QoS mechanisms for multiparty conference, particularly explain how to extend PIM-SM to support QoS multicast routing and how to design multicast QoS forwarding scheme for DiffServ QoS multicasting [7]. Though the QoS scheme in this section was proposed originally for terrestrial core routers, it can be integrated with satellite part well to provide an integrated satellite terrestrial QoS enabled network. Conference applications require quality of service with respect to delay, jitter and packet loss. However, existing multicast protocols have been devised for best-effort traffic. Per-flow resource reservation protocol has scalability issues [13]. The other solution, DiffServ [7], doesn’ t provide end-to-end QoS. In our architecture, we employ a hybrid QoS reservation scheme [18]. That is, the endpoint uses RSVP and the satellite core uses DiffServ. Such a scheme provides scalable QoS multicast support over DiffServ networks.


12

To provide QoS multicast over DiffServ, two important issues need to be considered. The first issue is how to differentiate the service level supported on different paths inside the multicast distribution tree. The second one is how to provide an admission control function in order to support dynamic joins from QoS-enabled users. In both cases, recall that no per-flow reservation state can be employed in the DiffServ routers, whose role is simply to apply different aggregated forwarding disciplines to packets based on their Differentiated Services Code Point (DSCP) values. To solve the first issue, Bless and Wherle [19] suggest adding an additional field in the Multicast Routing Table (MRT), which specify the DSCP(s) for each output link. It is thus possible to specify whether the next hop is QoS-enabled, or best-effort DSCP. This solution allows heterogeneous users to share the same multicast distribution tree as well as allowing deployment of several different QoS levels in the network. Our solution is an enhancement of [19] by adding a marking strategy. In addition to providing QoS-aware and differentiated services in a multicast environment, admission control mechanisms are used to meet following requirements [19]: •

“There must be a mechanism for DiffServ nodes to inform a management entity about the join request of a new subtree”;

•

“A mechanism must be supplied for instructing a router to suitably change (and update) the DSCP value in the related multicast routing table entry. This mechanism may be also incorporated into an existing multicast routing protocol as an extension.”

In our architecture, the marking strategy is similar to the strategy in [19] with a data plane DiffServ compliant admission control function, called Multicast Gauge & Gate Reservation with Independent Probing (Multi-GRIP) [18]. We also extend QoS for PIM-SM protocol. A. QoS Multicast Forwarding In this section we explain the basic protocol operations and the QoS multicast issue, using an example illustrated in Fig. 5. Assume PIM-SM as the multicast protocol of reference, particularly we can use Source-Specific Multicast (SSM). In the basic operation of PIM-SM, a Rendezvous Point (RP) is used for all traffic sources S as the root of the distribution tree for the multicast group. Destination hosts Hi where i = 1,2,3,4 avail themselves of Designated Routers (DRi) where i = 1,2,3,4 on their LAN, which act on behalf of those hosts as far as the PIM-SM protocol is concerned. In other words, each DR manages, on one side, all local group management information (e.g., via the IGMP protocol), and, on the other side, it emits PIM join/prune messages towards the RP. We assume that all routers are DiffServ capable. In addition, assume that while routers A, B and C in Fig. 5 support PIM, intermediate DiffServ routers, indicated with the label ”R”, are transparent to the PIM-SM multicast protocol.


13

Fig. 5. Routing Table for QoS Multicast Forwarding Multicast packets are replicated at each multicast router (these routers are the nodes of the multicast tree), and are delivered to the multicast destinations according to the routing information provided by the PIM protocol operation and stored in the MRT. Obviously, multicast routers are stateful, while DiffServ routers are stateless. In this scenario, scalability derives from the fact that only a fraction of the network routers should be multicast capable. Note that the tunnelling solution adopted in [20] has the effect of pushing all the handling of multicast states at the border of the domains. In this sense, [20] improves scalability by limiting the number of stateful routers. For the sake of simplicity, we assume the network provides a single QoS level, in addition to the best-effort service. Following [19], we also assume that each MRT stores an additional entry for each router output interface (OIF). This entry represents the Differentiated Services Code Point (DSCP) value, which is used to mark replicated packets that are forwarded along the considered interface shown in Fig.5. In the leftmost column, labelled ” Only H1+H2” , the MRT states for routers A, B, and C. We assume that only hosts H1 (QoS enabled) and H2 (Best-Effort) are members of the multicast group. In Fig.5, the label ” BE” denotes a best-effort service, (i.e., DSCP000000) and the label ” QoS” denotes a service with pre-defined QoS requirements. Let us examine 3 cases for joining the multicast group: First hosts H1 (QoS enabled) and H2 (Best-Effort), second host H3 (BestEffort) and finally host H4 (QoS enabled). Case 1: hosts H1 (QoS enabled) and H2 (Best-Effort):


14

By looking at Fig.5, the MRT of router A marks packets directed to host H1 (interface 2) with a QoS marking, while it labels packets forwarded to interface 1 as BE (for host H2). In the MRT of router B, clearly, only the interface 1 is active, while router C has no multicast state at the moment. Let us now discuss what happens in cases 2 and 3, when first the Best-Effort host H3, and then the QoS host H4, join the multicast group. Case 2: host H2 (Best-Effort): In the case of H3, we adopt a standard PIM Join operation. The Designated Router of H3, DR3, sends a PIM Join (*, G) message towards the RP. When a multicast router receives this message, it adds a new entry to its MRT, with a BE value, for the associated DSCP marking field. This state will indicate that future datagrams destined for group G must be marked as BE, and forwarded on the interface where the join message came from. The Join(*, G) message is regenerated upstream along the Branching Path. This is, the path from the requesting DR to the first router that already has a Join(*, G) state for that group, which is called the Branching Router. Eventually the Branching Router could coincide with the RP itself. In the specific case of Fig.5, the Branching Path goes from DR3 to router B, which is the Branching Router, since it already has a (*, G) state created by the Join message coming from host H2, by way of DR2. The second column of Fig.5, labelled ” H3 joins” , shows the modified multicast routing tables in routers A, B and C after a successful join of the BE host H3. Case 3: host H4 (QoS enable): In the case of QoS-host H4, a fundamental difference is the extent of the Branching Path. If the Designated Router DR4 were to send a standard Join(*, G) message, the Branching Router would have been router C, since it already has a (*, G) state. However, when a QoS host wants to join the group, it needs to send a modified join message, hereafter referred to as Join(*, G, QoS) message, which explicitly carries the QoS level the host is requesting. This Join(*, G, QoS) message travels upstream until it either reaches the RP, or a router with a (*, G, QoS) state. We define ” QoS Branching Path” the path from the Designated Router to the first router that already has a Join(*, G, QoS) state for that group. We call such a router a QoS Branching Router. In Fig.5, the QoS Branching Router for host H4 is router A. The rightmost column of Fig.5, labelled ” H4 joins” , shows the modified multicast routing tables in routers A, B and C after a successful joining of the QoS host H4. The distribution tree has a QoS path from the RP to DR4. Therefore, hosts H2 and H3 will receive a BE service only on the last hop of their path. In other words, the fact that some members of the multicast groups require QoS, indirectly brings benefits also to best-effort users, even if they are not paying for such benefits. Finally, note that a given host may upgrade its service level. For example, a host may first send a Join (*, G) message to preview the multicast group, and then upgrade to QoS by sending a Join(*, G, QoS). This second message is regenerated upstream along the QoS Branching Path, and, along its way, it modifies the


15

state of the crossed multicast router(s). It remains to show, in the following section, how resource availability along the QoS Branching Path is checked and reserved during a Join(*, G, QoS) procedure. B. Admission control with QoS for multicast Our admission control procedure is based on the idea of using ” implicit signalling” , for example, Gauge & Gate Reservation with Independent Probing (GRIP) [21][22]. GRIP uses pure data-plane operation by packet dropping/forwarding to convey, at the network borders, the information that the network is congested and a new flow cannot be accepted. A GRIP router is a plain DiffServ router, which handles a number of aggregate classes. A packet belongs to a class on the basis of its DSCP value. A GRIP router supports at least three different DSCP values: Best Effort (BE) packets, QoS information packets, and QoS probing packets. The following description will assume that only one QoS level and one traffic class is supported (i.e., only one information and one probing DSCP label in addition to BE), although we remark that the GRIP router operation can be extended to support several levels of QoS and different traffic classes. A measurement module in each GRIP module is in charge of taking a smoothed and filtered measure of the load offered by information packets. It will soon be clear that this is a measure of the aggregate accepted traffic. On the basis of these traffic measurements, and according to a suitable Decision Criterion, the measurement module drives an Accept/Reject switch. Let us look back at Fig.5, remembering that we want to establish QoS, considering the network router A as a starting point and the designated router DR4 as a destination point. When the QoS Branching Router A first receives a Join(*, G, QoS) message, it sends a GRIP Probe down on the multicast tree. As reviewed above, the probe is a normal packet, which is distinguished from information packets via a special DSCP marking. Specifically, if QoS packets are marked with DSCP value, say X1, GRIP Probes are marked with a different DSCP value, say X2, which is logically associated to X1. For each QoS level, different pairs of DSCPs have to be reserved. All network routers (i.e., both multicast-enabled routers and non-multicast routers) support a DiffServ Per-Hop-Behaviour which consists in letting packets marked as X2 go through only, for instance, if the load run-time measured on X1-marked packets is lower than a given threshold. The result of this operation is that a GRIP Probe is received at the destination DR4 only if all the routers along the path are found in a non-congested state, defined with a suitable criterion. When the GRIP Probe arrives at DR4, a Confirm(*, G, QoS) message is sent back as a feedback packet, to notify the sender node A that all the routers along the QoS Branching Path can accept a QoS connection. When the Confirm(*, G, QoS) message is finally received at router A, the multicast data can be forwarded on the new path. As discussed in the previous section, subsequent replicated packets are marked according to the DSCP value specified in the Multicast Routing Table.


16

C. State handling in Multicast Routers While this basic operation appears a straightforward extension of GRIP, there are several details need to be clarified. A first problem is that, although the aim of the GRIP Probe is to check whether the ” point-to-point” communication from A to DR4 can support QoS, in practice it is necessary to route the GRIP Probe as a Multicast packet. In fact, the GRIP Probe needs to follow the same path of the multicast data packets. We have solved this problem by using a multicast packet type, for the GRIP Probe, and by updating the Multicast State within each multicast node so as to route the GRIP Probe down to the appropriate output interfaces only. This is accomplished by extending the PIM-SM state machine associated to each multicast router interface, to manage two additional states per QoS class: •

Probing State (PRB state): when a multicast router output interface is in the PRB state, it means that a Join(*, G, QoS) message has been received, but no Confirm(*, G, QoS) message has been received yet.

•

Join-QoS state: this state is activated after a confirmation message, and it implies that the router output interface is QoSenabled. When in the Join-QoS state, the multicast routing table is set as described in the previous section.

When in the PRB state, packets are forwarded according to the following rules: •

Packets labelled as information packets are replicated and forwarded according to the existing Multicast Routing Table. With reference to the example of Fig.5, while host H4 is joining the multicast group (i.e., before a Confirm(*, G, QoS) has arrived), routers A and B continue to operate according to the previous MRT (central column in Fig.5), i.e., they replicate and forward packets labelled as BE, while router C does not replicate multicast data packets on the output interface 2.

Probes are recognized based on their special DSCP value. They are forwarded only toward interfaces whose state is PRB. With reference to the considered example, a Probe packet is generated at router A and forwarded only on interface 1, while the same Probe packet is forwarded only on interface 2 at both routers B and C.

V. QOS MEASUREMENT AND ANALYSIS To validate the proposed architecture and understand the impact of the proposed architecture on QoS parameters, we have implemented the models presented in the previous sections and performed some experiments on the prototype shown in Fig. 1. The experiments use the European Space Agency (ESA) satellite called SESAT with two channels of bandwidth 384 kbps each. In order to emulate on-board switch satellite behaviours, we use a satellite emulator [2] in sub-network1. We have measured QoS parameters based on the prototype on both the network layer QoS and the user perceptual quality for voice and video conferencing applications.


17

A. User Perceptual Quality One method for determining multimedia quality is known as Mean Opinion Score (MOS) testing, by which a large group of people evaluate subjectively the quality to yield a mean score. This is quite impractical because of the repetitive tests. Therefore other standard methods are used to map subjective results to a MOS value: •

E-Model: ITU-T E-model [23] provides guidelines for evaluating the subjective quality of conversations over a telephone, as a user would perceive it. E-mode uses the transmission factor R to reflect a MOS value, which lies in the range from 0 to 100, where R=0 represents an extremely low quality and R=100 represents a very high quality.

•

PESQ: Perceptual Evaluation of Speech Quality (PESQ) [24] is an enhanced perceptual quality measurement for voice quality in telecommunications. PESQ is a new ITU-T recommendation, P.862, using some mathematical calculations to compare an original input signal with the output signal after being transmitted in order to produce a MOS value. This is the current standardized perceptual method for audio. But there is no standard for evaluating perceptual quality of video.

Both methods are relevant as we can relate PESQ and R to the MOS of real users as show in Table II. However, real time IP multimedia quality is affected by network parameters in terms of delay, delay variation (or jitter) and packet loss. Jitter is the variation in the delay of the packets, introduced by the network. Jitter does not directly impact the user perceptual quality but does indirectly impact on the other quality parameters: packet loss and delay. To this end, user cannot tolerate jitter and therefore a jitter buffer is proposed to absorb jitter but this increases the delay or the packet loss [25]. TABLE II RELATION AMONG MOS VALUE, R FACTOR AND PESQ

R value

PESQ

MOS value

90 80 70

4.34 4.03 3.6

60

3.10

50

2.58

VERY SATISFIED SATISFIED SOME USERS DISSATISFIED MANY USERS DISSATISFIED NEARLY ALL USERS DISSATISFIED

In our perceptual quality evaluation, both the real users and the commercial software Opticom’ s Opera are applied for evaluation of perceptual quality under different scenarios. The experiments evaluated by the real users investigate perceptual quality of audio, video, and an interactive conference on the satellite link. However, in order to compare the impact of a satellite link on multiparty conferencing with that of a terrestrial link, we introduce a reference conferencing on a terrestrial link. Therefore, the experiments are designed to use MSN Messenger that joins two multicast conferences in the scenario Fig. 1 from user D to user B1. One of the conferences goes over the satellite link. The other


18

conference goes over the Internet from user D to user B1 as a reference conference. 17 persons were involved in these tests and MOS scores were defined in 5 levels in the range of 1 to 5, where 5 means the two conference have the same quality. A lower value indicates poorer quality over the satellite link. Table III presents the mean opinion value. This experiment shows that the proposed architecture does not degrade the perceptual quality of multimedia. It gives strong evidence that multimedia conferencing over satellite within our prototype is good enough, compared to the same service provided by a terrestrial network despite the longer satellite delay. TABLE III MOS VALUE OF HUMAN BEING EVALUATION

Audio 4.06

Video

Interactive Media

4.82

3.65

Another experiment was carried out on our emulator. We use Opera PESQ software [26] to measure how perceptual quality is affected by network parameters. The experiments use G.711, u-law, and Speex 5,95 and Speex 18,2 as codecs and the end-to-end network delay is 293.5ms. We tested jitter buffers ranging from 10 to 40 ms. Table IV shows measured results of the MOS values by using the Opera software. TABLE IV IMPACT OF DEJITTER BUFFER IN MOS VALUE Dejitter Buffer 10ms 20ms 30ms 40ms unlimited

Speex5,95

Speex18,2

G.711 u-law

1.93 3.11 3.31 3.31 2.52

2.46 3.03 3.38 3.65 3.98

2.99 3.16 3.55 3.75 3.79

Nevertheless, a larger dejitter buffer incurs extra delay in the end-to-end path. In geostationary satellites, delay is the main constraint and it must be minimized if possible. A compromise value for the dejitter buffer must be carefully selected. One solution is to use adaptive jitter buffers. B. Signalling Delay The signalling architecture described in section II.D. Some limited signalling measurements are presented in this section. Signalling delay is an important factor that affects the performance of our architecture and its scalability. They affect conference call set-up time. Therefore, we perform extensive experiments to investigate SIP registration delay and SIP INVITE delay. The results presented here are measurements from our prototype. We consider two instances of signalling. One is user D who sends a


19

register message to the NOC. We measure the delay of the registration. The other is User D who invites User B1 to join a conference under two scenarios: one requires SIP proxy servers to redirect the call message. We call this scenario “ indirect” signalling. In “ direct” signalling, calls can be set up without any SIP proxy servers. The tests continuously generate registration messages and INVITE other users up to 992 times. Fig.6 shows the measured results. Fig.6 (a) shows the registration delay distribution. It can be seen that the “ indirect” signalling delay is longer than the “ direct” signalling, the average “ indirect” signalling delay is 51.16 ms, and the direct signalling average delay is 45.39 ms. Fig.6 (b) is the delay distribution of INVITE signalling. It can be seen that the “ indirect” INVITE signalling delay is 158.7 ms and the direct signalling average delay is 152.6 ms. These results show that the proposed architecture has good scalability for INVITE message because there is no significant extra delay introduced by the SIP proxy servers dealing with signalling. Therefore, the delay with or without SIP proxy may not be noticeable by users trying to use the multi-party conferencing. 600

Indirect Signalling Direct Signalling

No. of Packets

500 400 300 200 100 0 20

30

40

50

60

70

80

90

(a) Delay (ms) of SIP Registration 700

No. of Packets

600

Indirect Signalling Direct Signalling

500 400 300 200 100 0 100 120 140 160 180 200 220 240 260 280 300 (b) Delay (ms) of SIP INVITE command

Fig. 6. Delay distributions for SIP Registration and Invitation signalling C. Transmission Delay and Jitter This section presents some measurements regarding to scalable QoS architecture described in section IV. In addition to signalling delay, end-to-end transmission delay and jitter are also important performance parameters. A video camera from user D was set up to capture a video stream in H.263 format and send it to user B1. Network analyse devices at D keep a time record of each packet sent and at B1 each packet received. There are two scenarios on background traffic experimented. In the first scenario, the background traffic is set as 75% of the satellite link bandwidth. This scenario represents a near congestion situation. We firstly start to send the video as best-effort


20

traffic. After the video runs for a short period, we activate our QoS mechanism to serve the video stream with guaranteed QoS. The change of end-to-end delay is noted at packet 41811 as shown in Fig.7. In the other scenario, the background traffic is set as 25% of the satellite link. This scenario represents a lightweight network load situation. We perform the same experiment. The

end-to-end one way delay(ms)

change occurs at the packet 13833, when we activate the QoS mechanism shown also in Fig. 7.

800

Video Traffic at 25% of Background Traffic Video Traffic at 75% of Background Traffic

700 600 500 400 300 200 100 0

13823

41811

69799

Sequence Number

Fig. 7. End-to-end delay It can be seen from Fig. 7 that end-to-end delay is affected by traffic load conditions if the QoS mechanisms are not activated and is not affected when QoS mechanisms are activated. The delay of QoS at 75% load of background traffic is longer than that of 25% before activating the QoS mechanisms. But an interesting result is observed that even under different background traffic, once the QoS mechanism is activated, the delay stays the same. The results also indicate that our QoS mechanism is stable under different load conditions. We also measure jitter for both scenarios. After the QoS mechanism is activated, the average jitter for QoS at 75% load of background traffic is 1.96 ms. This average jitter value is quite smaller and can be neglected.

VI. CONCLUSION AND FUTURE WORK This paper has presented an architectural design and a multicast solution to support multiparty multicast multimedia IP conferencing over GEO satellites. Regarding deployment of a multicast solution for conferencing, the PIM-SM protocol is used to enable multicast in the satellite domain and in each ISP domain. In addition, the MBGP router decides the shortest route to carry the MSDP ” source active” messages between ISP domains and satellite domain to enable inter-domain multicast. The star topology of the conference system centred on the GEO satellite determines the important role of the satellite NOC to be the centre of all of the MBGP and MSDP peers. In addition, we have also proposed an extension to PIM-SM that supports QoS in DiffServ networks to make multicast scalable. To minimize the expensive satellite bandwidth requirement and the cost of end user equipment, MCUs can be deployed to handle multimedia streams between end users and the satellite network. The multiple MCU model is introduced to support efficient


21

multiparty multicast multimedia IP conference over GEO satellite. The model is compatible with multicast-enabled end users as well. The SIP signalling models have been studied. They can be deployed to enable users to join and leave a conference. After analysis of these models, we proposed a centralized signalling and distributed media scheme optimised for multiparty conference. A QoS provisioning mechanism has demonstrated its stability and performance even in an overloaded network. The results of the perceptual quality measurements confirm that the proposed architecture is scalable to suit for different scenarios. The effects of QoS parameters have also been measured and analysed. The future possible work has been considered to extend the solutions in the ICEBERGS to support mobile IPv6 and Ad Hoc network scenarios in terms of mobility, QoS multicast and handover, and LEO satellite constellation networks.

ACKNOWLEDGEMENT The authors gratefully acknowledge the support from European Union 5th framework programme, the ICEBERGS project (IST 2000-31110).

REFERENCES [1]

H. Cruickshank, Z. Sun, L. Liang, A. Sanchez, C. Miguel, C. Tocci, and B. Carro, “ IP conference routing optimisation over GEO satellites,” in IST-Mobile and Wireless Communications Summit, Jun. 2003.

[2]

C. Tocci, L. Secondiani, and N. B. et al, “ EuroSkyWay network design description-deliverable D2-2,” Project IST 2000 31110-ICEBERGS, Tech. Rep., 2002.

[3]

I. Miladinovic and J. Stadler, “ Optimization of signaling traffic in centralized conferences using SIP,” in WSEAS ICOMIV 2002, 2nd WSEAS International Conference on Multimedia, Internet, and Video, Skiathos Island, Greece, Sep. 2002, pp. 2931–2936.

[4]

http://vip ten.tid.es/icebergs, IST project: IP ConferEncing with Broadband multimedia over Geostationary Satellites.

[5]

K. Singh, G. Nair, and H. Schulzrinne, “ Centralized conferencing using SIP,” in Proceedings of the 2nd IP-Telephony Workshop (IPTel’2001), New York City, USA, April 2001.

[6]

M. Handley, H. Schulzrine, E. Schooler, and J. Rosenberg, “ SIP: session initiation protocol,” RFC 2543, Internet Engineering Task Force, Mar 1999.

[7]

S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, and W. Weiss, “ An architecture for differentiated services,” RFC 2475, Internet Engineering Task Force, Dec 1998.

[8]

R. Braden, L. Zhang, S. Berson, S. Herzog, and S. Jamin, “ Resource ReSerVation Protocol (RSVP) - version 1 functional specification,” RFC 2205, Internet Engineering Task Force, Sep 1997.

[9]

N. Blefari-Melazzi and G. Reali, “ A resource management scheme for satellite networks with dynamic bandwidth allocation capabilities,” IEEE Multimedia, Special Issues on Satellite Systems for Mobile Multimedia Services, vol. 6, no. 4, pp. 54–63, Oct-Dec 1999.

[10] M. Handley, J. Crowcroft, C. Bormann, and J. Ott, “ The internet multimedia conferencing architecture,” Internet Draft, Internet Engineering Task Force, Jul 2000, work in Progress. [11] T. Bates, Y. Rekhter, R. Chandra, and D. Katz, “ Multiprotocol extensions for BGP-4,” RFC 2858, Internet Engineering Task Force, Jun 2000.


22

[12] [13] J. Rosenberg and H. Schulzrine, “ Models for multi-party conferencing in SIP,” Internet Draft, Internet Engineering Task Force, Nov 2000, work in progress. [13] M. Welzl and L. Franzens, “ Scalability and quality of service: A tradeoff?” IEEE Communications Magazine, vol. 41, no. 6, pp. 32–36, Jun. 2003. [14] M. Handley, C. Perkins, and E. Whelan, “ Session announcement protocol,” RFC 2974, Internet Engineering Task Force, Oct 2000. [15] K. Almeroth, “ From the Mbone to inter-domain multicast to internet2 deployment,” IEEE Network, vol. 14, pp. 10–20, Jan-Feb 2000. [16] S. Kumar, P. Radoslavov, D. Thaler, and et. al., “ The MASC/BGMP architecture for inter-domain multicast routing,” in ACM SIGCOMM 1998. Vancouver, British Columbia: ACM, Sep 1998, pp. 93–104. [17] B. Fenner and D. Meyer, “ Multicast source discovery protocol (msdp),” Internet-draft, Internet Engineering Task Force, draft-ietf-msdp-spec-20.txt, May 2003, work in progress. [18] G. Bianchi, N. Blefari-Melazzi, G. Bonafede, and E. Tintinelli, “ QUASIMODO: QUAlity of Service-aware Multicasting Over Diffserv and Overlay networks,” IEEE Network, Special issue on Multicasting: An enabling Technology, Jan-Feb 2003. [19] R. Bless and K. Wehrle, “ IP multicast in differentiated services networks,” Internet-Draft, draft-bless-diffserv-multicast-06.txt, Jan 2003, work in progress. [20] A. Striegel and G. Manimaran, “ A scalable protocol for member join/leave in DiffServ multicast,” in Proc. of Local Computer Network (LCN) 2001, Tampa, Florida, Nov 2001. [21] G. Bianchi and N. Blefari-Melazzi, “ Admission control over assured forwarding PHBs: a way to provide service accuracy in a DiffServ framework,” in IEEE Globecom 2001, San Antonio, Texas, USA, Nov 2001. [22] G. Bianchi, N. Blefari-Melazzi, and M. Femminella, “ Per-flow QoS support over a stateless DiffServ domain,” Computer Networks, Elsevier, special issue on Towards a New Internet Architecture, vol. 40, pp. 73–87, sep 2002. [23] ITU-T, “ Definition of categories of speech transmission quality,” ITU-T recommendation G.109, Tech. Rep., 1999. [24] ITU-T, “ Perceptual evaluation of speech quality (PESQ), an objective method for end-to-end speech quality assessment of narrowband telephone networks and speech codecs,” ITU-T recommendation P.862, Tech. Rep., 2001. [25] B. Li, M. Hamdi, D. Jiang, X. Cao, and Y. T. Hou, “ QoS-enabled voice support in the next-generation internet: Issues, existing approaches and challenges,” in IEEE Communications Magazine, no. 4, 2000, pp. 54–61. [26] http://www.opticom.de, OPERA v3.5, PESQ measurement software.


23

Dr. Zhili Sun is a Reader with the Centre for Communication Systems Research (CCSR), University of Surrey, UK. He received his BSc in Mathematics from Nanjing University, China, in 1982 and his MPhil and PhD from the Department of Computing, Lancaster University, UK. He did Postdoctoral Research from 1989 to 1993, in the Telecom Group, Department of Electronic Engineering, Queen Mary University of London. He has been principal investigator and technical co-ordinator in a number of European R&D projects including the ESPRIT BISANTE project on evaluation of broadband traffic over satellite using simulation approach, the TEN-telecom VIP-TEN project on Quality of Service (QoS) of IP telephony over satellite, GEOCAST project on IP Multicast over satellites and ICEBERGS project on IP based Multimedia Conference over Satellite of IST within 5th Framework Programme. He is leader of satellite networking group of PhDs and research fellows and contributes to the FP Network of Excellence (NoE) and Special targeted Research Project (STREP) related to satellite networks started from 2004. He also teaches MSc, undergraduate and industrial courses on satellite networking, computer and data networks, IP networking and Internet traffic engineering.

Dan He received the Ph.D. and M.Sc. degrees both in distributed computing from Nanjing University, China, in 2000 and in 1997 respectively, and the B.Sc. degree in computer science from Chongqing University, China, in 1989. He is currently a research fellow with the centre of communication systems research, University of Surrey, United Kingdom. He was a post doctor in INRIA (INSTITUT NATIONAL DE RECHERCHE EN INFORMATIQUE ET EN AUTOMATIQUE) in France from 2000 to 2002. His research interest includes active network, QoS, Internet security, and traffic engineering.

Dr. Haitham Cruickshank has been a Senior Research Fellow at the Centre for Communication Systems Research (CCSR), University of Surrey, UK since January 1996. He gained his BSc in Electrical Engineering at the University of Baghdad, Iraq, 1980, MSc in telecommunications, University of Surrey, UK and PhD in control systems, Cranfield Institute of Technology, UK 1995. He has worked on several European research projects: BISANTE, VIP-TEN and GEOCAST. His current research interests are IP multimedia over satellites and IP multicast network security. He also supervises PhD and MSc students and teaches MSc and undergraduate courses in University of Surrey.