Tele-service Creation with ISABEL in Heterogeneous Network Environments

Transcription

1 Tele-service Creation with ISABEL in Heterogeneous Network Environments Juan Quemada Tomas de Miguel Arturo Azcorra Santiago Pavón Joaquin Salvachua Manuel Petit David Larrabeiti Tomas Robles Gabriel Huecas Daniel Rodriguez Fernando Echevarrieta Eva Castro Department of Telematic Engineering (DIT) Technical University of Madrid (UPM) SPAIN ABSTRACT This paper describes the use of ISABEL in an heterogeneous network context where different QoSs are used to connect different participants in a real-time interactive collaboration based on videoconferencing. As ISABEL uses TCP-UDP/IP to interconnect different network technologies and no QoS control exists, a QoS adaptation function has been added: the ISABEL flow server. This approach has been successfully used in large scale trials such as Global 360 (Connected to 3rd Interworking Symposium in Madeira), the Big Technical Trial and others. The flow server is one of the latest developments made in one of the leading CSCW applications (ISABEL), which has been validated in real service conditions during broadband trials with worldwide coverage, including real distributed conferences where up to 15 interactive sites have participated. KEYWORDS: TELE-SERVICE CREATION, HETEREOGENEOUS NETWORK INTERCONNECTION, MULTICAST, QUALITY OF SERVICE ADAPTATION, FLOW SERVER, IROUTER, ISABEL, DISTRIBUTED EVENT, CSCW.

2 1. INTRODUCTION The creation of real-time interactive collaboration services including audio and video conferencing needs a controlled QoS (Quality of Service) in order to achieve a collaboration with the required degree of quality in the interaction. On the other hand a large variety of networking technologies with very different QoSs are in operation and have to be used to create collaboration services. It is therefore crucial to develop applications, which are capable to manage and use network technologies with various QoS before a widespread accessibility to those services can be achieved. ISABEL [1, 8, 9, 11, 12] is a customizable CSCW application, which has been designed to create remote collaboration services in the areas of Teleeducation, Telework, Telemeeting, Teleconference,... ISABEL has been extensively used in real service trials [10, 7, 1], especially in the European Broadband Programs. ISABEL has been used to distribute events with a large geographical coverage, such as the RACE/ACTS Summer Schools or Global 360, where due to the large geographical coverage and due to the variety of infrastructures and network technologies available, heterogeneous network interconnection has been necessary. This paper describes the approach taken in the ISABEL CSCW application to adapt different QoS in order to support connection of interactive participants through links with different QoS in the same collaboration. 1.1 The ISABEL Application ISABEL is a CSCW application designed within the European broadband programs RACE and ACTS to support the creation of innovative remote collaboration services in the area of real-time interactive interconnection of audiences. By audience interconnection we mean interconnection of groups of people located in auditoriums or various kinds of rooms using a workstation based CSCW application whose display is projected on a large screen in each of the endpoints. The service platforms created using ISABEL have supported the realization of distributed conferences, distributed workshops, distributed meetings or tele-work sessions. ISABEL is based on TCP-UDP/IP and has been designed to support heterogeneous network integration, such us terrestrial ATM, ATM over satellite, the internet, point to point links, ISDN,... ISABEL has been validated in large-scale trials with intercontinental coverage and up to twenty interactive sites participating, i.e. ABC 96, Global 360, the Big Technical Trial,... Those large trials constitute probably the largest broadband distributed trials made worldwide over heterogeneous networks containing, terrestrial ATM connections, the internet, ATM over satellite, ISDN, terrestrial and/or satellite point to point links. The ISABEL based services have a couple of distinguishing features which makes them good candidates for supporting global interconnection in areas where international cooperation is necessary: 1) A scalable architecture, which supports a large geographical coverage and large number of participating sites or access points. The large events performed with ISABEL have connected about 20 interactive sites and have had a coverage ranging from Ottawa in Canada, all over Europe and ending in Novosibirsk in Siberia in a single trial. 2) An integrated event management function, which supports the design of effective collaboration management strategies, and which are specific to each service. For example, a distributed conference is managed using the distributed implementation of the central control room of an auditorium. 3) The ability to define new services or adapt and tune the existing ones to meet user requirements. This is achieved by means of a programmable interface, which permits an "easy" definition of services. 4) The capability to use heterogeneous networks in the event with different QoSs, which are adapted

3 in order to achieve interoperability by means of a network adaptation agent, which is called Flow Server. All that features together make ISABEL based events very effective remote collaboration sessions The ISABEL service concept ISABEL has been conceived as a tool for generating distributed service platforms in the areas of Teleeducation, Telework, Telemeeting, Teleconference,... Each distributed service is defined by a set of interaction modes plus a service specific management function. An interaction mode is a particular set-up of the audio-video conferencing and of the shared workspace which has been configured to properly support a particular type of remote collaboration or interaction. Examples of interaction modes are: a lecture mode, a panel/debate mode,... of a teleconference service; a discussion/brainstorming mode, a co-editing mode,... of a telemeeting service. Interaction modes assign specific roles and rights to each participating site. For example, in a lecture mode the speaker role has the right for managing slides and pointer/pencil. The rest of sites have only the right to pose questions to the speaker. A management function is a service specific way of controlling the interaction modes. A management function has one (or more) control panels, which are used to change the interaction modes used by the participants of the distributed event. ISABEL separates the collaboration from event management, because each service usually requires a different management scheme. management panel of the control center has the right of changing interaction modes. The management of a telemeeting connecting small groups of people in distant meeting rooms can not be script driven. The interactions during the meeting are usually not planned and must be under control of the chairs of the meeting. Therefore, the management of the telemeeting is simpler and has a poorer functionality. It has been conceived for operation by one or several attendees. Figure 1 shows two examples of interaction modes of the telemeeting service. This includes the slides based lecture mode and the discussion mode. In this service only one workstation is used in each endpoint. This workstation contains the media presented and the control panel. The control panel is usually operated by one of the attendees in each site, usually the secretary or the chairmen of the room. 1.2 Architectural Requirements The service concept of ISABEL imposes very exigent requirements on the architecture of the application. The architectural model of ISABEL is a set of media components, which are controlled by a management agent, as shown in figure 2. The management agent implements the management policy of a given service. The media components manage the media flows and the media presentation at the connected sites. The media components are dynamically configurable in order to allow the change of interaction modes required by service operation. Depending on the role assigned by the management agent to a media components in a given interaction mode, the components can be a traffic source, traffic sink or both. For example, in a distributed conference service the management is centralized. The operation of a distributed conference follows the usual scheme of TV program production, where the event production is script driven and managed by a professional team. This implies the existence of a unique center of control which manages the conference program. This service has therefore a centralized management scheme, where only the

4 lecture mode Discussion mode Figure 1. Examples of interaction modes Manager control protocol c3 slides c1 video c1 audio flow server media flows components Figure 2. Architecture of ISABEL

5 The data traffic generated by ISABEL is therefore generated by many independent and variable rate sources. The overall traffic send to the network by an ISABEL workstation is the aggregation off all the individual sources. The overall traffic generated has a complex pattern and shape, and is not well suited for transmission across existing networks. Therefore, a special network interface agent has been added to ISABEL, which aggregates the traffic coming from the various sources and which tries to adapt the traffic shape and rate to the requirements of the network service available. This network agent is called the ISABEL Flow Server. The roles and functions are very similar to the roles and functions performed by the multicast server needed by ISABEL and the flow server has been extended to support also multicast server functions. Therefore the flow server is a key element, which has three fundamental roles in ISABEL: 1) Creation of gateways for interconnecting heterogeneous networks. 2) Adaptation of the multimedia flows to the quality of service provided by the network. 3) Creation of multicast server which connect a large number of endpoints. 2. THE FLOW SERVER The Flow Server is located at the application layer of ISABEL because the functions assigned can only be properly performed at this layer. The communication service given by the actual internet protocols do not allow doing it at a lower layer. ISABEL uses the reliable connection oriented TCP service to send control information and the less reliable UDP connectionless service to send the media streams ---video, audio, real time data, etc. The media streams generate the largest amount of traffic. The UDP traffic can use unicast or multicast depending of it s availability in the underlying network. The first network agents of ISABEL were called IROUTERS [4, 5] and performed only traffic aggregation of the media flows. IROUTERS produced a variable rate traffic, which can not be properly send via some of the existing network services, for example ATM-CBR, ISDN, etc. Therefore new functionality had to be added which has led to the actual conception of the flow server. The flow server is tan application layer network interface agent, which decouples and adapts the rest of the application from the network and performs a variety of functions. The list of functions supported by an ISABEL flow server is: To decouple the rest of the application from the different network services available, for example unicast, multicast, etc. To aggregate the traffic of the different media streams into a unique flow. To shape the outgoing traffic according to the network needs. To create an application level multicast server, which supports N to N communication with efficient bandwidth usage. To route the incoming packets to the appropriate output connections of the flow server. To perform an "intelligent" QoS (quality of service) adaptation to reduce the bandwidth of a given flow by applying least cost transformations to the media streams of the flow. One of the most difficult features is the adaptation of the QoS needed for heterogeneous network interconnection. A proper QoS adaptation can only be performed at the application layer where the flow server knows the nature and characteristics of the media flows. The flow server tries to minimize the degradation of the quality of the user interaction according to the usage evaluations made with ISABEL. The result of such evaluations indicate that each media needs an individualized treatment, which is dependant to the nature of the information and the impact this media in the quality of the collaboration. The algorithm is as follows: video is usually the less critical component and is therefore the first

6 candidate to be downgraded by reducing the frame rate. The display sharing is treated as the video. Data are send at a lower rate. Audio is preserved always with the best quality possible, given the available bandwidth. Transcoding into an audio format with less bandwidth consumption (and less quality also) is made when needed. This algorithm has worked properly with bandwidth reductions by a factor from 1 to USAGES OF THE FLOW SERVER The flow server is now the basic element for setting up distributed events with a large number of endpoints in an heterogeneous environment. The main advantages of flow server based network platforms as compared to IROUTER based ones [4,5,6,7,10], is that they need only unicast connections which are always available and that they can make quality of service adaptations. The flow server plays three basic roles in distributed event organization: Interfacing ISABEL workstations and the network with the purpose of shaping the traffic as required by the network. Creating application layer multicast network nodes, where the endpoints connect with unicast connections only. Creating gateways to interconnect networks with different QoS, where the gateway downgrades the quality of the higher bandwidth flows to the rate required by the lower bandwidth network. The first trial where heterogeneous networks were connected with the ISABEL flow server is Global 360. Global 360 was a distributed event, hold in June 1997, where up to 16 interactive sites in Europe and North America participated during 3 days. Global 360 included windows into 4 conferences --- Network Interoperability in Madeira - Portugal, Global Networking '97 in Calgary Canada, Broadband for Education & Research in Moscow, 21st Century - the Communications Age in Brussels - Belgium --- and where professional TV production techniques were used to design the content of the event. The role of the flow server in Global 360 was the connection of an ATM multicast network at 6 Mb/s and a 2 Mb/s Satellite connection to Moscow. This first version of the Flow server did only QoS by downgrading the video stream. In succeeding events the flow server has been used more and more in more heterogeneous environments. It has been successfully used to create event networks which connect ISDN lines from 128Kb/s (2*N) to 512Kb/s (8*N), ATM VPs with rates from 1-3Mb/s, satellite connections at 2 Mb/s and less, and variable QoS connections over the internet. QoS adaptation factors of up to 8 have been achieved, but it seems that higher factors may be possible in the future with more sophisticated algorithms. 3. CONCLUSIONS The current communication services provided by the internet are not sufficient for the realization of good quality synchronous real time collaboration event. Two basic lacks exist: No QoS can be assured and the available bandwidth is usually rather small. The internet multicast service is difficult to access because it is available only in a limited number of points. Until a proven technology exists were both problems are solved, solutions are needed which work sufficiently well over existing network technologies and assure a reasonable quality in the collaboration. This is the approach taken in ISABEL, where the flow server is the agent, which adapts the traffic generated by the application to the available network service. It assumes that a variety of network technologies exist, some assure some QoS (ATM-CBR, ISDN, point to point lines), some not (internet), and all provide some kind of point to point or unicast communication.

7 ACKNOWLEDGEMENTS This work describes the approach taken in ISABEL to support service creation in a heterogeneous network framework. This approach is the result of many trials and experiments performed within all the projects where ISABEL has been developed and/or assessed. A large part of the trials have been performed within the European Broadband Research Programs ACTS and RACE. In the trials many institutions and persons have participated, have contributed to set up the platforms and have given useful suggestions. The list is extremely long due to the number and scale of the trials performed, which started in 1993 with the first Summer School on Advanced Broadband Communications and which had Iberic coverage (Spain and Portugal). Since then the coverage and scale of the events has grown continuously to reach world wide coverage and dozens of interactive sites. The authors would like to thank all those, which have participated, usually with a great enthusiasm, since the beginning. Most of them were participants of the projects ISABEL, BRAIN, IBER, NICE, TECODIS, BONAPARTE and EXPERT or were closely linked to this projects. Without all of them the ISABEL design team would not have been able to get the feedback, which has allowed the evolution of this application generation framework, guided by real service provision requirements, to his present state. REFERENCES [1] J. Quemada, T.P. de Miguel, A. Azcorra, S. Pavón, J. Salvachua, M. Petit, D. Larrabeiti T. Robles, G. Huecas: ISABEL: A CSCW application for the distribution of events. Multimedia Telecommunications and Applications, Ed: G. Ventre, J. Domingo, A. Danthine. Springer- Verlag, - LNCS 1185, ISSN , [2] Michael E. Luckacs, David G. Boyer: "A Universal Broadband Multipoint Teleconferencing Service for the 21st Century", IEEE Communications Magazine, November 1995, Vol. 33, No 11, pp [3] D. Larrabeiti and M.C. Agúndez and A. Azcorra and C. Garcia and J. Quemada and T. De Miguel and M. Petit: Towards the integrated configuration and management of multicast teleconferences based on IP over ATM. HP Openview University Association Workshop, Madrid, Apri1997. [4] M. Petit, T.P. de Miguel: Distribution of Multimedia Information Experiences over Broadband Networks. EUNICE '96 Summer School, Lausane, September 1996 [5] M. Petit, T.P. de Miguel: Flexible Support for Advanced CSCW Conferences: the ISABEL irouter. PROMS'96: Protocols for Multimedia Systems, Madrid, Oct [6] T.P. de Miguel, M. Petit, L. Rodriguez, C. Acuña, P.L. Chas, V. Lagarto, J. Bastos: Multicast IP support for distributed conferencing over ATM. A. Azcorra, Networld+Interop 95, pp. 9, March [7] Distribution of ABC'95 over the European ATM Pilot Network with the ISABEL application. J. Quemada, T.P. de Miguel, A. Azcorra, S. Pavón, J. Salvachua, M. Petit, J.I. Moreno, P.L. Chas, C. Acu\~na, L. Rodrigues, V. Lagarto, J. Bastos, F. Fontes, J. Domingues. Broadband Islands '95. September 1995.

8 [8] "ABC'95: A Tele-education Case Study". J. Quemada, T.P. de Miguel, A. Azcorra, S. Pavón, J. Salvachua, M. Petit, J.I. Moreno, P.L. Chas, C. Acuña, L. Rodrigues, V. Lagarto, J. Bastos, F. Fontes, J. Domingues. High Performance Networking for Teleteaching - IDC'95, Madeira, November [9] ISABEL - Experimental Distributed Cooperative Work Application over broadband Networks. T.P. de Miguel, S. Pavón J. Salvachua, J. Quemada, P.L. Chas, J. Fernandez-Amigo, C. Acuña, L. Rodriguez, V. Lagarto, J. Bastos. In "Multimedia: Advanced Teleservices and High-Speed Communication Architectures" Ed. Ralf Steinmetz, Springer-Verlag, vol. LNCS 868, pp , September [10] Distance Learning: Networks and Applications for RACE Summer School 94. A. Azcorra, T.P. de Miguel, J. Quemada, S. Pavón, P.L. Chas, C. Acuña, P. Aranda, V. Lagarto, J. Bastos, J. Domingues. The ATM Forum Journal, pp. 11, September [11] ISABEL Aplicación Multimedia Distribuida Experimental sobre banda ancha. T.P. de Miguel, S. Pavón, J. Salvachua, J. Quemada, P.L. Chas, J. Fernandez-Amigo, C. Acuña, V. Lagarto, J. Bastos. Jornadas Telecom 93, Noviembre [12] The ISABEL Application home page: