AIAA 2002-1920

IP Based Multimedia Conference over Satellite Z. Sun, H. Cruickshank and Lei Liang University of Surrey, Guildford, Surrey, United Kingdom; Surrey GU2 7XH, UK, Tel: +44 (0)1483 68 9493, Fax: +44 (0)1483 68 6011, [email protected] Antonio Sánchez, Telefonica R&D. Parque Tecnológico de Castilla y León 47151 Boecillo (Valladolid). SPAIN, [email protected] Carlos Miguel, ETSIT Universidad Politécnica de Madrid, Spain, [email protected]

This paper presents the results from two closely related projects - Validation of IPTelephony over EuroSkyWay Network (VIPTEN) within the European Trans European Networks (TEN) TELECOM programme that focused on issues on IP telephony over satellites; and the follow on project - IP Conferencing with Broadband multimedia over Geostationary Satellites (ICEBERGS). ICEBERGS project focuses on multimedia conference over satellite. It has been conducted within the European IST 5th Framework programme. The work in these projects is based on Geostationary Earth Orbit (GEO) satellites due to the availability of satellites in operations and the recent failure of the Iridium LEO satellite constellation.

ABSTRACT1 Significant research and development have been carried out recently in Voice over IP (VoIP) to integrate Internet data services and telephony services based on Public Switched Telephone Network (PSTN). Satellites have been used for many years to provide long distance telephone services and have today an increasing portion of their capacities used to carry IP packets for Internet services. Therefore, convergence of voice and data is happening not only in terrestrial communication links, but also in satellite networks. With their global coverage and reach to remote areas, satellites are well positioned to enable growth of VoIP services. In addition to telephone and Internet services, satellite can also be used for multimedia conference services due to the broadcasting capability. This paper presents the studies of these topics as results of the VIP-TEN project on IP telephony and the ICEBERGS projects on multimedia conference over satellite.

The VIP-TEN project developed a test-bed for Voice over IP (VoIP) via satellite networks based on the International Telecommunication Union (ITU) H.323 Recommendation. H.323 Architecture is composed of an underlying networking architecture and telephony-specific protocols. The networking architecture is based on Internet standard protocols for both the lower protocol layers and multimedia transport protocols including Internet Protocol (IP), User Datagram protocol (UDP), Realtime Transport Protocol (RTP) and Real-timeControl Protocol (RTCP). The telephonyspecific protocols are based on ITU-T standards; that include protocols for audio/video coding and transmission (G.700 series, MPEG series, H.261 and H.263) and protocols for call management.

1 Introduction The recent development in IP-based multimedia applications has generated great interest in research topics related to satellite networks such as performance and quality of service (QoS) of IP applications over satellite. Research has been conducted to study how satellite networks can support efficiently these multimedia applications, including voice, video and data, and to assess the impact of satellite networks on these applications.

The test-bed was set up to validate the VIPTEN concept for VoIP via satellite. It consists of LANs interconnected by a satellite link through IP routers and VoIP gateways, which provide an interface between PABX or PSTN and the IP networks. Measurements were

1

Copyright ©2002 by University of Surrey. Published by the American Institute of Aeronautics and Astronautics, Inc., with permission. 1

American Institute of Aeronautics and Astronautics

potential to revolutionise telephone communications within the modern enterprise, and to provide new integrated services by integrating telephony services and Internet services together. The dominant standard for transmitting multimedia in packet-switched networks is the International Telecommunication Union (ITU) H.323 Recommendation [1]. Research has also been carried out recently to tackle the problems relating to IP telephony on terrestrial networks and mobile networks. Many papers have addressed the technical challenges in adapting the Internet from its original design for computer and data communication to be capable of supporting telephony services [2]. The major issues include Quality of Service and interoperability between IP telephony and other networks [3].

carried out to monitor the QoS parameters including Round Trip Time (RTT), packet loss rate, packet delay and delay variation. Comparisons were made between the end-toend QoS with and affecting factor of the satellite links. Analysis was also carried out based on the ITU-T E-model to calculate the Quality Rate Factor (R), which has been used to describe the voice quality experienced by a user. The project also evaluated measured QoS parameters against the QoS classes defined within the TIPHON - "Telecommunications and Internet Protocol Harmonisation Over Networks" supported by the European Telecommunications Standards Institute (ETSI). The ICEBERGS project extends the scope of VIP-TEN to multimedia conference, including voice, video and data services. Key issues on support of multimedia conference have been investigated including connection management, traffic management, routing algorithm, and QoS support. A similar test-bed to the VIP-TEN project has also been planned so that quality of service and performance of the multimedia conference application and performance of satellite links can be to evaluated.

It is expected that satellite networks will soon be used to support VoIP services. Experiments have been carried out to test Internet services by satellite companies including Intelsat and Comsat (now also Lockheed Martin), and to study the effects of satellite links on VoIP [6]. However, due to complexity and availability of broadband satellite systems, demonstrations often have to be based on satellite simulators. Within the VIP-TEN project, experiments were also set-up to demonstrate the VoIP over satellite and to evaluate the performance under different link and traffic conditions (long delay, random and burst errors, and traffic loading), and different coders and decoders (codecs).

The results from these two projects can be used as a reference for further study of IP based multimedia applications over satellite links in terms of protocol architecture, satellite network configuration, QoS monitoring and performance evaluation and set up of the testbed for possible deployment of the networks to provide services.

An engineering approach is taken. First, we investigate the internetworking between satellite links and the Internet, and define internetworking scenarios. Then we investigate how IP packets are used to carry voice traffic, how to transport the IP packets over broadband satellite links, and how to establish satellite signalling procedures for IP telephony connection set up and clearing. A demonstrator is developed (Ka-band satellite) to obtain VoIP real measurements. Measurements of the QoS parameters are carried out including delay and packet loss. Finally, analysis is conducted based on the ITU-T E-model, which is used to evaluate the subjective quality of VoIP conversations over satellites. All these works were supported by

The paper is organised as the following: Section 2 discusses the VoIP based on the VIP-TEN project, section 3 discusses the current ongoing work in the ICEBERGS project and presents issues such as IP based conferencing over satellites and conferencing security model. Finally section 4 summarises the works and further research.

2 VoIP over satellites Many companies today maintain a data and telephony networks. Voice over IP (VoIP) is a technology for providing voice services over data networks based on Internet protocols (IP). It has been recognised that there is a great 2

American Institute of Aeronautics and Astronautics

ATM Adaptation Layers (AAL) type 5 (AAL 5) was developed based on ATM standards for IP over ATM as the transport mechanism.

the VIP-TEN project to Validate IP-Telephony over satellite network, within the European Trans-European Networks -TELECOM (TENTelecom) programme.

The H.323 architecture was selected for the VIP-TEN project, due to its maturity and commercial availability. It can also co-exist with the IETF Session Initiation Protocol (SIP) [4]. Adaptations to satellite network protocol stack (connection oriented) are carried to interwork with IP (connectionless). Figure 1 shows the system architecture and Figure 2 shows the VIP-TEN demonstrator configuration.

2.1

Satellite system and network protocols Many broadband satellite systems have been developed recently based on on-board ATMalike fast packet switching technology. Therefore, implementation of broadband satellite demonstrator for VoIP was based in IP over ATM via satellite. The EuroSkyWay (ESW) broadband satellite system [5] is an example and was used for the VIP-TEN demonstrator, but the demonstrator and relevant results are still applicable to general broadband satellite systems based on fast packet switch technology. The satellite system provides end-to-end connectivity as either an access link or a transit link with on-demand and QoS Guaranteed connections.

In order to maximize utilisation of satellite bandwidth, some fields of the IP and User Datagram protocol (UDP) headers can be compressed so that one voice packet can fit into one ESW cell (53 bytes payload). This will be indicated to the data link layer functions. Further improvement can be achieved by compression of RTP header in addition to the IP/UDP header compression to allow more than one voice frame to fit into in one cell of 53 bytes. Both techniques must be applied on both ground earth station gateways of satellite network, at the data link layer. The implementation of RTP header compression implies memory of the status of each RTP flow in the Network Interface Units (NIUs). This can have two problems: single errors may produce a burst of errors because of this memory (for VoIP frames, satellite network uses unacknowledged link service in order to reduce delay. If error recovery procedure is not implemented, it is possible that some datagrams can be corrupted during transmissions). However, forward error correction mechanisms are implemented in all broadband satellite system to recover from single bit errors and some degree of burst errors.

The on-board switch has the capability of traffic resource management that allows the terminals to change dynamically the bandwidth usage of each connection, without the need of tearing-down and setting-up the connection itself. Bandwidth can be allocated on demand in steps of 16 Kbps. The satellite network service is cell-based similar to ATM technology. Actually, it was developed originally to carry ATM cells. Each transports cells consists of a header of 11 bytes plus a 53byte payload. Services and applications supported by the satellite network connectivity can be grouped into four different categories as the ATM services classes. These categories are characterized by the typology of traffic and by the quality of service requirements, according to the following broadband service parameters: •

Constant bit rate (CBR) or variable bit rate (VBR)

•

The timing relationship requirements (maximum Cell Transfer Delay and peak-to-peak Cell Delay Variation).

•

The type of connection necessary to satisfy the above requirement (connection oriented or connectionless).

2.2 Voice quality Rating The ITU-T E-model [9] is used as a guideline for the QoS analysis in this project. It is a reference model to evaluate the subjective quality of conversations, as a user would perceive it. The E-model defines each degradation factor on voice quality as an impairment factor. The impairment factors are processed by the E-Model to produce the overall transmission quality rating R, which 3

American Institute of Aeronautics and Astronautics

describes the voice quality experienced by a user, for a typical situation using a standard telephony handset. The relation between R and the user perception of quality is defined by ITU-T recommendation G.109.

Therefore, we get the resulting quality factor for G.723.1 as:

To estimate the Quality Rating, the following simple expression for R can be used:

R0 - Basic signal-to-noise (without quantisation noise);

•

Is - Quantisation noise, loud speech level;

•

Id - Delay and echo Impairments;

•

Ie - Equipment Impairment factor (it includes codec characteristics and packet loss ratio);

•

A - Advantage factor: To take into account the fact that customers may accept some degradation in quality for access advantage. For example, users expect to have a relative low quality voice for a long distance telephone calls but not for local calls.

R ≈ 55.3 + A (for 0 % packet loss ratio)

•

R ≈ 50.3 + A (for 1 % packet loss ratio)

But the same loss ratio with G.711 codec, Ie = 5. For G.711 and considering the same Id we have values of 74.3 and 69.3 respectively.

R = R0 – Is – Id - Ie + A; where •

•

ratio

Similarly we can fix the value of R, to get the maximum delay admissible for each codec (with no packet loss). To achieve a value of R=72 (which is considered as the limit for traditional quality) [8], for G.723.1 with 5.3 kbps rate, delay is 203 ms and for G.711, 379 ms. It can be seen that end to end delay is a very important factor particularly for satellite network.

2.3 Factor affecting end-to-end delay In comparison to terrestrial networks, satellite links can achieve most of the performance objectives, except the end-to-end delay. Therefore, delay is the most important parameter, which makes a significant difference between satellite links and terrestrial links. An analysis has between conducted to estimate the end-to-end delay for a PC-to-PC scenario, and G.723.1 codecs in the VIP-TEN demonstrator. Figure 3 illustrates the different contributions to the overall end-to-end delay, where T0 is the start time of the transmission and T1 is the end time of the transmission. The total delay is given by T1 – T0, and consists of the following contributions:

High values of R (in a range of up to R = 100) can be interpreted as excellent quality, and vice versa. For G.711 with no delay and no echo, impairment parameter Ie is 0, taking the advantage factor A = 0, yields a quality rating of R = 94.3. This is our reference value without much of delay impairment. For VoIP over satellite network, we have to consider the delay and echo impairments, Id and Ie, the codec characterization and loss ratio, and the advantage factor. Therefore, we get R = 94.3 - Id - Ie + A.

•

Access delay refers to the time needed for communication between the Source or Destination PCs and the ESW stations under the control of the Traffic Resource Manager (TRM).

•

Propagation delay is around 125.5 ms, which is derived from the latitude and longitude, relative to the satellite, of the demonstrator earth station.

•

Uplink transmission time (Dtx) is the delay experienced in transmission through the ESW network.

It can be seen that the acoustic-to-acoustic quality experienced by a user is affected by performance of codecs and network connections. For high delay value, impairment factor can be very large, for example, Id ≈ 20 for 348.55 ms delay [7]. Considering a G.723.1 codec with 5.3 Kbps rate, the values for the impairment Ie are as the following: •

Ie = 19 for packet loss ratio = 0 %

•

Ie ≈ 24 for packet loss ratio = 1 %. 4

American Institute of Aeronautics and Astronautics

the characteristics of the particular terrestrial connections and on the traffic load of links involved at the specific time tests were carried out.

An estimation of the mean Dtx value can be calculated, where we make the assumption that no silence packets are generated, and that Nf voice frames are carried on each IP packet. Each voice frame has a duration of 30 ms. All the voice from different conversations will share the satellite link bandwidth. There is a trade-off between bandwidth and delay. Other delay contributions are: •

Algorithmic delay includes (codec + packetizing + processing delay) + 7.5 ms look ahead delay for G.723.1. It can be estimated based on the time required to process an input frame.

•

On board processing time includes all delays that packets experience on board the satellite.

•

Dejittering (buffering) delay: It is introduced at the receiver, in order to eliminate delay variations introduced in the audio flow in the whole end-toend path.

The main results that were obtained in the measurement campaign focused on jitter, packet loss rate and delay - Round Trip Time (RTT). The test results show that very low jitter values are achieved with satellite links. Packet loss measurements appear to be lower than 1% when ESW satellite link is used, which can be tolerable in a conversation. This QoS figure is much worse when terrestrial Internet is used. Finally the delay imposed by the geostationary satellite link is quite high. Delay is the only limitation of the system, as it is expected due to the geostationary position. More detailed are shown in [10]. For scenarios involving PCs, the choice of end user application may highly influence the endto–end delay. Additional delay can also be very large due to the large dejittering buffer it handles. This parameter cannot be changed for most commercial software. The dejittering delay introduced by audio conferencing applications can be very significant, in addition to the satellite delay. In these cases, the dejittering buffer introduced in the receiver should be adjusted to the range of values that fit the jitter provided in the satellite environment. Different codecs also influence the delay, as already discussed in the previous section.

The access delays, the downlink transmission time and the on board processing delay are very small, hence can be neglected. In summary, the major factors for the end-to-end delay are: Propagation delay, Algorithmic delay, and dejittering delay.

2.4

VIP-TEN measurements discussion The demonstrator architecture measurement is composed of a Terrestrial/Satellite network integrated system, as illustrated in Figure 2. The scenarios comprise PC-PC, PC-to-Phone and Phone-to-Phone calls. Phone calls include PSTN and PABX.

3 IP based multimedia conferencing over satellites Satellites are ideally suited for multicast. To explore potential advantages of satellites, the ICEBERGS project has extended research works from VIP-TEN on IP-telephony to IP multimedia conferencing over Geostationary Satellites. ICEBEREGS project aims to design and validate an integrated broadband communication infrastructure for IP-based multiparty, QoS-sensitive, conversational services, for fixed, mobile and portable terminals typologies.

IP packets are sent using the FIFO discipline. If the IP packets have the same QoS requirements, they share the same virtual connections. The tests were carried out for voice conversation with different traffic load conditions. Emphasis was given to connections with satellite link. Other tests included integrated satellite-terrestrial segments (with IP tunnels to force traffic to travel through the satellite link). Terrestrial tests are included as a reference, since they are highly dependent on

In contrast to the VIP-TEN model which was based on the H.323 architecture, the ICEBERGS model is based on the IETF IP telephony architecture, where the conferencing 5

American Institute of Aeronautics and Astronautics

efficiently supports this type of transmission by enabling sources to transmit a single copy of a message to a group of interested receivers.

signalling protocol is the Session Initiation Protocol (SIP). SIP is a signalling protocol used to establish sessions over an IP network. It is emerging as the protocol of choice for setting up conferencing, telephony, multimedia and other new types of communication sessions such as instant messaging. SIP is designed to be a part of the overall Internet Engineering Task Force (IETF) multimedia data and control architecture and was originally developed in the MMUSIC (Multiparty Multimedia Session Control) working group of the IETF. A complementary protocol to SIP is the Session Announcement Protocol (SAP). SAP is an experimental announcement protocol for multicast conference sessions and it was developed by the MMUSIC working group as well. The Session Description Protocol (SDP) can be used in SIP and SAP by providing a format for describing session information to potential session participants. Basically, a session consists of a number of media streams and the description of a session involves the specification of a number of parameters related to each of the media streams. It is expected that Internet based conferencing applications and tools (such as the MBONE tools) will be used in ICEBERGS . The MBONE tools include the Session Directory Revised (SDR), which assists the user in setting up and joining conferences. Other MBONE tools are Robust Audio Tool (RAT), Video Conference Tool (VIC) and Whiteboard (WB/WBD). This set of applications is considered in our satellite system since it provides a distributed model of signalling and media, i.e. it is only needed one satellite hop (if IP Multicast is provided with one hop).

This mode of transmission scales well with increasing number of receivers, unlike in the unicast case (one-to-one), where the source has to send an individual copy of a message to each interested receiver (limited by bandwidth from sender). IP multicast is also more efficient than IP broadcasting (one-to-many), since in broadcasting a copy of a message is sent to all receivers, including receivers who may not want to receive the message. More so, in the broadcast case messages are limited to a single subnet (to avoid flooding the entire Internet) compared to the multicast case (where receivers choose to join/leave different groups as they wish). IP multicast can be described as “the transmission of an IP datagram to a group, which is a set of hosts identified by Class D IP destination address. A multicast datagram is delivered to all members of the group with the same best-effort service as regular unicast IP datagrams. The membership of a group is dynamic; that is, hosts may join and leave groups at any time using the Internet Group Management Protocol (IGMP). There is no restriction on the location or number of members in a host group. A host may be a member of more than one group at a time.” In addition, a single group address may have more than one data stream on different port numbers. Users can have group memberships by joining particular multicast groups. The membership and other information of each group is processed and maintained across the entire network. Multicast tree is introduced to establish and maintain the fabric of the multicast internetworking. Traffic flows from root of the tree to all the leaves along its branches, as illustrated in Figure 4.

3.1 IP multicast over satellites Satellites have been widely used for broadcasting services. Multicast is between the broadcasting and point-to-point connection services.

In order to support native IP multicast, both sending and receiving nodes and network infrastructure between them must be multicast enabled, including intermediate routers. Native IP multicast at an end host requires support for IP multicast and delivery of data packets at the IP protocol stack (see Figure 5).

IP Multicast is an Internet protocol that enables transmission of data packets to a group of receivers. This is well suited for one-tomany or many-to-many bulk data transfer or multimedia (audio/video) streaming transmission to a large number of heterogeneous receivers. IP Multicast 6

American Institute of Aeronautics and Astronautics

applications. FEC can be performed at the physical or data link layers. Both of them can benefit the scalability issue by eliminating the need for feedbacks.

Most of multicast routing protocols are designed to allow multicast communication over the IP based network without reliable delivery. For many multicast applications, the reliability of transportation is necessary. But reliable multicasting brings with it a series of unique problems such as feedback implosion, transmission isolation and loss reduction. The IETF Reliable Multicast Transport (RMT) working group provides three main methods to solve these problems: •

TRee-based ACK (TRACK)

•

Negative ACK (NACK)

•

Forward Error Correction (FEC)

•

3.2 Control multicast over satellites Satellites are usually employed to provide services over a wide area. That means the sources and receivers of a multicast group may be widely distributed and the group may has thousands of members. Therefore, scalability of the GEO satellite multicast system is a very important issue because the overhead to improve scalability may need a large bandwidth. At the same time, a satellite network is asymmetrical system. It’s expensive to provide return link where feedback should be carried. To solve this problem, the following can be considered: •

•

Minimizing packet duplication over satellite: Satellites work as routers in multicast systems. They have to duplicate packets from sources to spot beams that have receivers. A good practice is avoiding flooding packets via satellite. Multimedia data streams are very bandwidth consuming. Satellites should only duplicate media packets to spot beams that have group members.

Although there are some algorithms that are helpful to minimize feedbacks from receivers as discussed above, return links are still unavoidable for a multicast system. Repair request and packet retransmission for reliable multicast transport and other feedbacks used for congestion control and traffic management are crucial for a reliable and stable multicast system. Obviously, a terrestrial return link is an economic way to solve this problem. The Internet can be a very good return channel. However, for the areas that have no terrestrial links, a low-cost (shared) satellite return link can be employed. Therefore, different solution can be used in a system for different areas.

Minimizing/avoiding control message via satellite: Using techniques such as pruning multicast tree branches whenever there are no members downstream. Also using receiverdriven tree to explicitly join/leave group rather than flooding and using terrestrial link for control message.

For the area having ground return links, all receivers can send their feedbacks using unicast to corresponding sources through terrestrial network. The satellite links are only used for forwarding packets from sources. Hierarchy architecture can used for both satellite links and return links in order to minimize feedback traffic.

Minimizing the repair requests and packet retransmissions: With techniques such as aggregating repair requests for each “area” and subgroup retransmission employing hierarchy architecture. Also negative acknowledgement (NACK) type protocols can be used instead of positive acknowledge to minimize repair requests, together with using FEC to minimize repair requests and retransmissions in high reliabilitydemanding and latency-sensitive

3.3

Satellite bandwidth resource management All media components will share the satellite bandwidth resources. For voice traffic, various voice inputs can be mixed together into the same connection using same bandwidth as the single voice traffic. Also various data packets can also be multiplexed together to share a similar connection to voice. But individual video traffic has to be allocated the bandwidth resourced. Different video streams cannot be 7

American Institute of Aeronautics and Astronautics

mechanisms inbuilt in SIP such as HTTP Digest authentication for authentication purposes [12].

mixed or multiplexed due to the real-time and streaming characteristics of video traffic. Controlling mechanisms include that members wishing to be active contributors and active contributors wishes to terminate their contribution to the video stream. Of course, one can make all the contributors visible during the conference that this cannot be scalable due to the possible limitation of network resources and user terminal capability. In a conferencing example and in order to save the bandwidth utilisation, only one video traffic stream is multicasted belonging to an active contributor. The chairperson selects the active contributor during the conference session or it could be voice activated.

SIP provides a stateless, challenge-based mechanism for authentication that is based on authentication in HTTP. Any time that a proxy server or user agents receives a request; it may challenge the initiator of the request to provide evidence of its identity. Once the originator has been identified, the recipient of the request should ascertain whether or not this user is authorized to make the request in question. There are two methods used by a SIP client to authenticate itself to a server: Basic and Digest. The basic authentication sends passwords in clear text and its use is not recommended. Digest authentication as used by SIP and it implements a cryptographic hash of a number of elements including the request method and optionally the body of the message. The digest authentication mechanism provides message authentication and replay protection only, without message integrity or confidentiality. Protective measures above and beyond those provided by this method need to be taken to prevent active attackers from modifying SIP requests and responses.

3.4 IP conferencing security model IP telephony and conferencing applications require the security services such as: •

Authentication: The client has to be authenticated to the IP multicast group through the conference server, ISP, or VoIP gateway.

•

Confidentiality: The media data as well as control (signalling data) have to be secured against unauthorised access using techniques such as encipherment.

•

Integrity: the data can be protected by mechanisms such as digital signatures, so that it becomes difficult to modify the data in transit.

•

Access control: to restrict levels of access to unauthorised users.

Data exchange phase The data protection can be provided in the signalling and content level. In the signalling level, since SIP protocol is used for signalling the data has to be secured. SIP runs over any transport protocol so we could either use application, transport level or network level security in order to encrypt SIP traffic. SIP has a number of security mechanisms for hop-byhop and end-to-end protection. It has some security functionality built-in such as some variants of HTTP authentication, secure mail attachments, and can also use underlying security protocols such as IPSec, Internet Key Exchange (IKE) and Transport Layer security (TLS) [12].

The conferencing security model can be divided into various phases such as: Registration / authentication phase In this phase, a client is authenticated to the conference server using either public key based systems or secret key systems (pre configured secrets). This authentication can be performed either at the application, session, transport or network levels.

Regarding content protection, the media data that flows between end users, use the RTP/RTCP protocol for data transmission. Thus for end-to-end security, secure RTP as described [12], can be used to secure the RTP sessions. Thus encryption of data is performed at RTP payload level. The Secure Real Time Transport Protocol (SRTP) is a profile of the

Since SIP protocol is used for signalling and setting up the call control in ICEBERGS project, we could use the authentication 8

American Institute of Aeronautics and Astronautics

selection. In addition, the delay value can further be increased if an application with large de-jittering buffers (like NetMeeting) is used.

Real Time Transport Protocol (RTP), which can provide confidentiality, message authentication, and replay protection. SRTP can achieve high throughput and low packet expansion. SRTP proves to be a suitable protection for heterogeneous environments, i.e. environments including both wired and wireless links. To get such features, default transforms are described, based on an additive stream cipher for encryption, a keyed-hash based function for message authentication, and an ’implicit’ index for sequencing based on the RTP sequence number.

Also this paper has presented an overview of the ICEBERGS project architecture for IP conferencing over satellites. The early research in the ICEBERGS project shows that it is possible to select some IP conferencing applications, routing protocols and a security model that are most suited for satellite environment. The careful adaptation of such applications and protocols into the satellite environment can provide a scalable solution for wide area IP multiparty multimedia conferencing service.

However, a security protocol needs a key management solution to exchange keys. There are some fundamental properties that such a key management scheme has to fulfil with respect to the kind of real-time applications (streaming, unicast, or multicast). This key management protocol could either be an application level or could be integrated into signalling protocol such as SIP protocol for key distribution. The SIP protocol uses Session Description protocol (SDP) protocol for session descriptions. The key management protocol could embed security parameters like session keys and algorithm types in the SDP, which could then be carried over in SIP. There are some protocols in the MSEC group in the IETF [12] that could be used to provide multicast key management by integrating it into SDP protocol and used by the SIP protocol.

5 Acknowledgements The authors gratefully acknowledge the support from the European Union IST Programme [11], the ICEBERGS project (IST2000-31110), and Ten-Telecom program and the VIP-TEN 26410 project.

6 References [1] ITU-T Recommendations. H.323, ‘Packet based multimedia communications systems’ Nov 2000. [2] Mahbub Hassan et al, ‘Internet Telephony: Services, Technical Challenges, and Products’, IEEE Communications Magazine, April 2000. [3] Maher Hamdi et al, ‘Voice Service Interworking for PSTN and IP Networks’, IEEE Communications Magazine, May 1999. [4] Hong Liu, et al, ‘Voice over IP Signaling: H.323 and Beyond’, IEEE Communications Magazine, October 2000. [5] R. Mura, G. Losquadro, ‘A satellite network bringing broadband communications to the user’, Sixth Kaband Utilization Conference, Cleveland, Ohio (USA), 31 May-2 June 2000. [6] Thuan Nguyen et al, Voice over IP Service and Performance in Satellite Networks. IEEE Communications Magazine, March 2001. [7] ETSI Guide 201 050 V1.2.2 (1999-02). Overall Transmission Plan Aspects for Telephony in a Private Network.

4 Conclusions Voice over IP is a new technology for providing voice and video services over traditional data networks. It has the potential to revolutionise telephony communications and promises new integrated services and lower cost long-distance communications. This paper has presented an overview of the VIP-TEN project and its measurement campaign. The results show that the usage of geostationary satellite to carry VoIP traffic can offer a good quality service in terms of packet loss and jitter, and a medium to poor quality in terms of packet delay. This is expected due to the satellite position. Selecting a codec with lower delays could increase the bandwidth usage of VoIP traffic, so a compromise must be reached when dealing with a codec 9

American Institute of Aeronautics and Astronautics

[8]

J. Janssen, et al, ‘Maximum Delay Bounds for Voice Transported over Satellite Internet Access Networks’, Proceedings of the 4th IEEE International Workshop on Satellite-Based Information Services (WOSBIS ’99), pp. 48-55, Rio de Janeiro, Brazil, 8 December 1999. [9] D. De Vleeschauwer et al, Quality Bounds for Packetized Voice Transport. Alcatel Telecommunications Review. 1st Quarter 2000. [10] Cruickshank H, Sun Z., Sanchez A. and Carducci F. Validation of IPTelephony and conferencing over EuroSkyWay Network. 19th AIAA conference in Toulouse. April 2001. [11] “Information Society Technologies Programme”, http://www.cordis.lu/ist/ [12] IETF web page, http://www.ietf.org/

Src PC

EsW

TRM

EsW

Dst PC

To Algorithmic delay

Access delay

Prop. Delay = 125 ms Prop. Delay = 125 ms

time

Downlink transmission time

Uplink transmission time On board processing delay

Access delay Dejittering

T1

Figure 3 VoIP over satellite delay diagram

LAN G /W PB X

R

R

IP n e t w o r k

R

G /W G /W

PST N

LA N

LAN

PB X

PB X

PST N

PST N

Figure 4 Basic Multicast transmission module

Figure 1. VIP-TEN System architecture

Figure 5 IP Multicast protocol stack

Figure 2. VIP-TEN System demonstrator configuration 10 American Institute of Aeronautics and Astronautics