Multipoint Video Conferencing Over A Unidirectional Satellite Link

Sivavenayakam.VNetwork Research Group

School of Computer ScienceUniversiti Sains Malaysia11800 Penang, Malaysia.

siva@nrg.cs.usm.my

Saravanan.KNetwork Research Group

School of Computer ScienceUniversiti Sains Malaysia11800 Penang, Malaysia.

svanan@nrg.cs.usm.my

Sureswaran.RNetwork Research Group

School of Computer ScienceUniversiti Sains Malaysia11800 Penang, Malaysia.

sures@cs.usm.my

ABSTRACTWith the availability of UDLR (UniDirectional Link Routing) which provides a way to forward multicast packets over a physical unidirectional interface such as a satellite link to a stub network that have a back channel, the number of commercial multicast applications have started receiving growing acceptance in the software market. When used in a multicast mode, these links provide substantial economies and become rapidly cheaper than terrestrial links especially when the number of receivers interested in the same content increases.

In this paper, we propose a method for MCS (Multimedia Conferencing System) to support multicast via unidirectional satellite link. Multipoint video conferencing solution such as MCS via satellite provides an economical and scalable method in participating in interest group meetings.

The proposed method for MCS over UDLR satellite network would cater many broadcast satellite systems which ensure low-receiver costs by providing high speed uplink delivery from a central hub transmitter integrated with a low cost (shared) satellite return link. The choice of the return link, which in this case the terrestrial link do not directly support multicast. Therefore, the design would also comprise of a redesigned version of MLIC (Multiple Internet Protocol Converter), which would use IP-tunneling to interconnect the MCS client at the receivers end to the MCS server which would be located at the transmitters also called as feed.

KeywordsUniDirectional Link Routing (UDLR), Multicast, Multimedia Conferencing System (MCS), Multiple Internet Protocol Converter (MLIC).

1. INTRODUCTION

The global market for digital direct-to-home (DTH) satellite delivery of broadcast television and radio has seen a phenomenal growth since its introduction in the mid-‘90s. Most of the media used to broadcast television and radio are unidirectional. Recently, the service providers of these satellite systems expended their service to include data due to the higher data bandwidth requirement to the Internet. Such unidirectional digital links that operate in broadcast mode are principally suitable infrastructure to transport multicast data as multicast can be considered as subset of broadcast. When applied in a multicast mode, these links become substantially economical then terrestrial links especially when the number of receivers interested in the same content increases. The UDL network infrastructure model provides a seamless multicast environment for any IP based multicast application especially wide area video conferencing. This mainly due to the high bandwidth capacity that will permit continuous stream of multimedia data and its ability to broadcast or multicast over a large geographical region. Moreover, the issues which are faced in the terrestrial deployment of multicast can be easily countered in a satellite network, as it offers a self contained which avoids multiple router hops as which a terrestrial network. As a result, UDL network may in future be favored to become the primary delivery network for most Internet multicast traffic.

This paper proposes a method of achieving multipoint-to-multipoint multicast based video conferencing over UDL network by modification of the current MCS model. The proposed design will adapt to the UDL network without much changes in the network infrastructure. The main objective is to make use of the high bandwidth capacity provided by the UDL infrastructure to create a global mesh of multicast network, which allows unlimited participants to join any ongoing video conferencing simultaneously.

2. The MCS ModelMultimedia Conferencing System (MCS) [1,2,3,4,5] developed by Network Research Group, Universiti Sains Malaysia has also undergo such evolution where today it stands as one of the more highly developed multicast multimedia conferencing system. Multipoint conferencing with full duplex audio and video via LAN and WAN is possible.

Figure 1:MCS System LAN Setup

The MCS system consists of four entities: -

Server entity

MLIC entity

Client entity

PC entity

2.1 The server entityServer acts as the brain of MCS as it controls the creation and deletion of a conference. It coordinates various sessions of ongoing multimedia conferences, and arbitrates between different clients wishing to obtain the right to speak using well-defined control criteria [14]. User authorization also secured by the server. The server is transparent to the user.

2.2 The PC entity (client)The client’s job is to provide the user interface. The capturing, receiving, compression and decompression of audio and video streams are part of the client’s responsibilities. Client are individual participants equipped with PCs configured with suitable video capture and playback equipment involved in a given multimedia conference.

2.3 The MLIC entityUpon creation of a conference by an active site, server will assign a multicast address for the conference and the clients involved in the conference will join the particular address and receive audio and video streams. This setup only works for LAN as the router will drop the multicast packets and any sites outside the LAN will not receive the audio and video streams. See Figure (1).

Figure 2: Multi LAN conferencing with MCS

In a WAN setup, each server in each LAN knows about the existence of site servers, in order to initiate and coordinate inter-site multimedia conferences. In addition, the server object knows about the MLIC object attached to its site. The task of the MLIC is to capture the multicast audio and video streams and tunnel it through the router to the other LANs with clients involved in the conference. Each site acts as an island of multicast activity, which is then interconnected to other islands using MLICs to bridge the multicast information for a given multimedia conference to provide a seamless multicasting

environment for the wide-area multimedia conference. See Figure (2).

2.4 Remote ClientThe remote client was developed with the idea to allow MCS to run even if the other network or point over a WAN network does not have an MLIC and server. This is particularly useful if the other user is just a single PC client that wishes to be part of a conference. The idea of having a server just for small number of clients is not cost effective.

Remote clients are basically are the same as the normal MCS clients with the capability of receiving and sending unicast streams instead of multicast streams. This way, they will be able to transmit and receive over WAN with the help of MLIC entity to convert the unicast streams to multicast streams and vice versa. The diagram below explains further. See Figure (3).

Figure 3: Remote client integration with MCS

3. The Proposed MCS ModelThe distributed network architecture of MCS conferencing model made the changes needed on the current design is possible. The entities of MCS that has been identified to undergo changes are: -

MLICo To stop sending unicast streams to the

remote clients.

o To stop capturing multicast streams from the network

Remote Cliento To be able to receive multicast streams from

the receiver instead of unicast.

The proposed model would be as below:

Figure 4 :MCS System Over UDL Satellite network

In the normal scenario (Figure5), remote clients will receive unicast streams from the MLIC and will send unicast streams to MLIC. Local clients will just receive and receive multicast streams from the network.

MLIC, on the other hand, will

Receive unicast streams from remote client and multicast it out to the network, in order to allow the local clients to be able to receive them. Will also reflect the unicast streams to other remote clients

Receive multicast streams from the network and send it as unicast stream to the remote clients.

Figure 5:MLIC operations in normal scenario

In the proposed model, it is assumed that the multicast data transmitted to the UDL network, which is called the feed

network, will be automatically transmitted through the sender station to receiving stations.

As described in Figure 4, the MCS server and MLIC would be placed at the feed network. All the clients involved in the conference will have to be only remote clients that have undergo the changes explained earlier.

When a remote client creates a conference, server would assign a unique multicast address for the conference, which would be used as the conference ID. When other invited participants join in the conference, the active participants will transmit their multimedia streams to the MLIC using UDP unicast via terrestrial network. MLIC receives the unicast streams and converts it to multicast using the unique multicast address assigned for the conference. The multicast packet would then be send through the feed to the entire receiver sites. As multiple unicast streams comes in from various active sites, the MLIC will be able to multicast all the streams to the receiving site using UDL as the link is able to transmit down high bandwidth. As a result, multipoint-to-multipoint conferences can be conducted the UDL network without any infrastructure restructuring.

Figure 5:MLIC operations in UDL network

4. Conclusion

The proposed changes on MLIC and Client entity represent a mean of implementing multimedia conferencing using off-the-shelf components and equipments on a UDL satellite network. MCS running on a satellite service may benefit from a more simple topology then terrestrial networks since there is no need for intermediate multicast routers which will minimizes allot of congestions and delays. The multicast delivery also makes more efficient use of the satellite bandwidth capacity.

5. REFERENCES

[1] R. Sureswaran, TC Wan and K. Saravanan, Implementing the MLIC (Multicast Internet Protocol Converter) On A Linux Platform, NCCT ’99 Universiti Putra Malaysia

[2] R. Sureswaran, TC. Wan and O. Aboudallah, A Multimedia Conferencing System to Support the APAN Network ( Asia Pasific Advance Network)

[3] R.Sureswaran & S. Madria “A method to Support Multimedia Conferencing Using satellite Links” IWTS98, Shah Alam, Malaysia. May 1998. [4] R.Sureswaran “Using the RSW Control Criteria to Support Desktop Video Conferencing Using Satellite Links”, Nasonet, Malaysia. Aug 1997

[5] R.Sureswaran “Using the RSW Control Criteria to Support Ethernet Based Multimedia Conferencing” SEACOMM'96, Malaysia. Aug 1996

[6] K. Almeroth, Managing IP Multicast Traffic: A First Look at the Issue, tools and Challenges’, IP Multicast Initiative (IPMI), California, USA, White Paper, February 1999.

[7] R. Sureswaran and R.K. Subramaniam. "A control Criteria to optimize Collaborative Document and Multimedia Conferencing Bandwidth Requirements". IEEE SICON, Singapore, Aug 1995.

[8] R. Sureswaran. "A Control Criteria for Document and Multimedia Conferencing". Proceedings of IASTED conference on Multimedia and Distributed Systems, Honalulu, Aug. 1994.

[9] Intel. "Intel Proshare Personal Conferencing, Product Information". Intel Corporation.

[10] R.Sureswaran & S. Madria “A method to Support Multimedia Conferencing Using satellite Links” IWTS98, Shah Alam, Malaysia. May 1998.

[11] R.Sureswaran “Using the RSW Control Criteria to Support Desktop Video Conferencing Using Satellite Links”, Nasonet, Malaysia. Aug 1997

[12] R.Sureswaran “Using the RSW Control Criteria to Support Ethernet Based Multimedia Conferencing” SEACOMM'96, Malaysia. Aug 1996