IEEE JOURNAL SPECIAL ISSUE ON BROADBAND IP NETWORKS VIA SATELLITE, VOL. X, NO. XX, 2004 1
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
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.
Scalable Architecture and Evaluation for Multiparty Conferencing over Satellite Links
C
IEEE JOURNAL SPECIAL ISSUE ON BROADBAND IP NETWORKS VIA SATELLITE, VOL. X, NO. XX, 2004 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, inter-
domain 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.
IEEE JOURNAL SPECIAL ISSUE ON BROADBAND IP NETWORKS VIA SATELLITE, VOL. X, NO. XX, 2004 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
IEEE JOURNAL SPECIAL ISSUE ON BROADBAND IP NETWORKS VIA SATELLITE, VOL. X, NO. XX, 2004 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 QoS-
guaranteed 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 cost-
effectiveness 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.
IEEE JOURNAL SPECIAL ISSUE ON BROADBAND IP NETWORKS VIA SATELLITE, VOL. X, NO. XX, 2004 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.
IEEE JOURNAL SPECIAL ISSUE ON BROADBAND IP NETWORKS VIA SATELLITE, VOL. X, NO. XX, 2004 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.
IEEE JOURNAL SPECIAL ISSUE ON BROADBAND IP NETWORKS VIA SATELLITE, VOL. X, NO. XX, 2004 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.
IEEE JOURNAL SPECIAL ISSUE ON BROADBAND IP NETWORKS VIA SATELLITE, VOL. X, NO. XX, 2004 8
TABLE I
COMPARISON OF CONFERENCE MODELS
Model Name
Signalling Structure
Uplink Cost Scalable
End-Mixing Tree O(N) Small
Multicast Pairs O(1) Large Dial-In Star O(2N) Medium Ad Hoc Star O(2N) Medium Dial-Out Star O(N) Medium Central Star O(1) 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].
IEEE JOURNAL SPECIAL ISSUE ON BROADBAND IP NETWORKS VIA SATELLITE, VOL. X, NO. XX, 2004 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.
IEEE JOURNAL SPECIAL ISSUE ON BROADBAND IP NETWORKS VIA SATELLITE, VOL. X, NO. XX, 2004 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 point-
to-point bi-directional satellite traffic channel used to carry out MBGP sessions.
IEEE JOURNAL SPECIAL ISSUE ON BROADBAND IP NETWORKS VIA SATELLITE, VOL. X, NO. XX, 2004 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.
IEEE JOURNAL SPECIAL ISSUE ON BROADBAND IP NETWORKS VIA SATELLITE, VOL. X, NO. XX, 2004 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.
IEEE JOURNAL SPECIAL ISSUE ON BROADBAND IP NETWORKS VIA SATELLITE, VOL. X, NO. XX, 2004 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 (Best-
Effort) and finally host H4 (QoS enabled).
Case 1: hosts H1 (QoS enabled) and H2 (Best-Effort):
IEEE JOURNAL SPECIAL ISSUE ON BROADBAND IP NETWORKS VIA SATELLITE, VOL. X, NO. XX, 2004 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
IEEE JOURNAL SPECIAL ISSUE ON BROADBAND IP NETWORKS VIA SATELLITE, VOL. X, NO. XX, 2004 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.
IEEE JOURNAL SPECIAL ISSUE ON BROADBAND IP NETWORKS VIA SATELLITE, VOL. X, NO. XX, 2004 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 QoS-
enabled. 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.
IEEE JOURNAL SPECIAL ISSUE ON BROADBAND IP NETWORKS VIA SATELLITE, VOL. X, NO. XX, 2004 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 4.34 VERY SATISFIED 80 4.03 SATISFIED 70 3.6 SOME USERS
DISSATISFIED 60 3.10 MANY USERS
DISSATISFIED 50 2.58 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
IEEE JOURNAL SPECIAL ISSUE ON BROADBAND IP NETWORKS VIA SATELLITE, VOL. X, NO. XX, 2004 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 Video Interactive Media
4.06 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
Speex5,95 Speex18,2 G.711 u-law
10ms 1.93 2.46 2.99 20ms 3.11 3.03 3.16 30ms 3.31 3.38 3.55 40ms 3.31 3.65 3.75
unlimited 2.52 3.98 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
IEEE JOURNAL SPECIAL ISSUE ON BROADBAND IP NETWORKS VIA SATELLITE, VOL. X, NO. XX, 2004 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.
0
100
200
300
400
500
600
20 30 40 50 60 70 80 90
No.
of P
acke
ts
(a) Delay (ms) of SIP Registration
Indirect SignallingDirect Signalling
0
100
200
300
400
500
600
700
100 120 140 160 180 200 220 240 260 280 300
No.
of P
acke
ts
(b) Delay (ms) of SIP INVITE command
Indirect SignallingDirect Signalling
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
IEEE JOURNAL SPECIAL ISSUE ON BROADBAND IP NETWORKS VIA SATELLITE, VOL. X, NO. XX, 2004 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
change occurs at the packet 13833, when we activate the QoS mechanism shown also in Fig. 7.
0
100
200
300
400
500
600
700
800
13823 41811 69799
end-
to-e
nd o
ne w
ay d
elay
(ms)
Sequence Number
Video Traffic at 25% of Background TrafficVideo Traffic at 75% of Background Traffic
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
IEEE JOURNAL SPECIAL ISSUE ON BROADBAND IP NETWORKS VIA SATELLITE, VOL. X, NO. XX, 2004 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.
IEEE JOURNAL SPECIAL ISSUE ON BROADBAND IP NETWORKS VIA SATELLITE, VOL. X, NO. XX, 2004 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.
IEEE JOURNAL SPECIAL ISSUE ON BROADBAND IP NETWORKS VIA SATELLITE, VOL. X, NO. XX, 2004 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.