A Course in Interventional Uro-Radiology and Endourology demonstrating novel, minimal invasive surgery techniques was held at the Middlesex Hospital in London on February 20, 1997. The workshop, consisting of lectures and a number of live operations, was multicast over the MERCI project’s 1 Mbps JAMES ATM links to surgeons in Glasgow, Gothenburg, Stockholm and Stuttgart. Two operations from the Sahlgrenska Hospital in Gothenburg were also multicast.

This event, demonstrating improved technical quality over a similar event multicast by the MICE project in November 1994, used increased bandwidth, encryption and digital recording on the UCL multimedia server.

A videotape cassette of the event is provided as part of this deliverable.

The event described in this paper was presented as part of a demonstrator workpackage of the Multimedia European Research Conferencing Integration project (MERCI) [1], funded by the European Community under the Telematics for Research initiative of the Telematics Application Programme. The objective of this workpackage is to stress those aspects of the system which are particularly appropriate to a demanding application such as a surgical workshops: high quality multimedia tools, multimedia servers, security and conference control.

In November 1994, as part of the MICE project [2], UCL held a two-day surgical workshop involving Sweden and the US. Live operations, carried out in London, Gothenburg and San Francisco were multicast to audiences at the other sites. All the participants were impressed by that event, but recognised that substantial improvements were required for the future.

To enable such improvements, MERCI used the ATM network connections provided to the project by another Telematics for Research project, JAMES (Joint ATM Experiment on European Services) [3]. The operations were part of a training workshop, so that both an oral presentation of the procedure, a visual demonstration and an interactive discussion were integral parts of the event. The highest quality audio and video available through MERCI was provided in both workstation and conference room environments. The video consisted of standard images generated by a camera of the operating theatre and the lecture room, as appropriate, and real-time instrument data, both X-ray and Ultrasonic. The primary source of multicast traffic was UCL which was receiving composite audio and video from the Middlesex Hospital via the analogue Livenet [4] network, then separating, digitising and packetising the feed for transmission over the multicast network. Other participants joined in asking questions and in discussion following the transmission of individual sessions. The proceedings were encrypted using the encrypting versions of the conferencing tools developed in MERCI so confidentiality of the transmission was maintained and only approved users, previously given the key, could view the transmissions.

The JAMES ATM infrastructure provides permanent ATM VPs between the MERCI sites at UCL, RUS, GMD, KTH and UiO as shown in Figure 1. Each VP carries an Mbone tunnel which, when not in use for special experiments, carries normal Mbone traffic. The bandwidth of the ATM VPs is 1 Mbps which reduces significantly at the IP level. For higher quality video, a minimum 512 Kbps is required with additional bandwidth required for the audio.

Problems of isolation

To conduct high-speed trials the MERCI Mbone must be isolated from the world Mbone so that it neither carries non-MERCI traffic nor allows the high-speed MERCI traffic to get out. Sealing the outgoing traffic is achieved by appropriate administrative scoping on the boundary routers of the MERCI network; preventing incoming traffic is more difficult.

We tried to achieve this by use of increased thresholds and metrics on the tunnels, but this was not effective. Input packet filtering was also considered, but would have had an adverse effect on general multicast streams since surrounding multicast routers would have continued to route traffic to the filtering multicast router causing such traffic to be lost in a so-called black-hole. The use of such techniques requires features in multicast routing programs which are not currently available.

In Glasgow, KTH, Sahlgrenska and UCL special provision was taken to limit global Mbone traffic from reaching the subnets involved, this was achieved by packet filtering at KTH and by the use of stub subnets at the other sites. These stub subnets were created by isolating the subnets from tunnels carrying traffic unrelated to the event, by taking tunnels down in the local multicast router or by reconfiguring tunnels in other multicast routers.

Topology

The network infrastructure consisted mainly of the Mbone tunnels running over the JAMES IP/ATM links between the MERCI partners UCL, KTH and RUS. This part of the MERCI Mbone infrastructure was augmented for the duration of the workshop to include tunnels over temporary ATM links from KTH in Stockholm to Sahlgrenska Hospital and from RUS in Stuttgart, via Berlin, to CRC in Ottawa. Additionally, a temporary tunnel was set up over the UK SuperJANET network to the Multimedia Communications Group (MCG) at the University of Glasgow. The full topology is shown in Figure 1.

For the transmission of the workshop proceedings we used the MBONE audio and video tools, RAT and VIC. For coordination between the technical staff at each site we used the shared text editor NTE. Images from the workstation screen are shown in Figure 2.

Robust audio Tool (RAT)

RAT [5], developed at UCL with the specific objective of maintaining audio performance in the face of network loss, is a multicast audio conferencing tool. The strategy is to pursue the twin approaches of Rate control and Loss control. Rate control aims at avoiding losses by adjusting sending rate to the network’s capacity to carry it whilst loss control aims to reconstruct lost packets at the destination using redundant, low bandwidth, information sent by the source. When, as described above, our best efforts to isolate the MERCI Mbone network were unsuccessful, the robust nature of the redundant audio in RAT maintained full intelligibility at all times, even when there was considerable extraneous traffic. We also used the RAT encryption feature so that, by input of a simple pass phrase, we ensured that only those in possession of the phrase were able to hear the transmission.

Video Conferencing (VIC)

VIC [6], developed at Lawrence Berkeley Laboratories by Steve McCanne and Van Jacobson, was used to transmit the video. The image size transmitted was CIF to give higher quality on the workstations whilst not compromising too much on the increased size needed for display in remote lecture rooms. The highest bandwidth video component was the source of the lectures and operations and this we sent at rates of up to 600 Kbps with maximum frame rates of some 15 fps. Other sites sent only very low bandwidth video to the

sources to establish the remote presence. Using the encryption facility developed at UCL within the MERCI project, similar in application to that used in RAT, we restricted viewing to authorised sites in possession of the pass phrase.

NetNetwork Text Editor (NTE)

NTE [7] allows multiple users to share a common text window which all may read and edit. It was used to convey feedback and control information between the technical staff at each of the participating sites. This related to network conditions (loss rates, the leaking of ordinary Mbone traffic into the MERCI net), audio level setting, and Conference control of the event (who speaks when, for example).

The Computer Science department received an analogue composite video and audio feed from the Middlesex Hospital via the Livenet teaching network of the University of London. The feed from the analogue network terminates at a local switch within the Computer Science building. From this switch, we were able to direct the feed to an audio/video multiplexer/de-multiplexer (AVM) to separate the analogue audio and video. These separated streams were then input to a Sun Ultra 2 workstation for encoding, encryption, packetisation and transmission across the Mbone.

Video and audio traffic from the Mbone, received on the Ultra, was fed, via the AVM and Livenet, back to the Middlesex. In the case of the video, this feed went via a scan converter prior to the AVM. This interface is shown in Figure 3.

Since the whole activity was as a controlling interface between the hospital and the Mbone, the action took place solely within a laboratory. The computer science department is some 15 minutes walk from the hospital.

The setup in the lab worked exactly as planned.

There were no users at this site.

The lack of access to the Mbone at the Middlesex Hospital meant that the control channel between them and the Mbone was via the telephone between UCL Computer Science Dept. and the control room at the hospital. In the future this control channel should be more directly between those responsible for the two sites’ operations, ideally using a mobile device. Whilst this would be a mobile phone in the immediate future, later it could be a laptop computer with a wireless network connection.

UCL Middlesex Hospital, London

All feeds were within the analogue domain inside the hospital; such feeds are used routinely for local teaching purposes.

The local audience was in a seminar room. There was a camera in the front corner of the room, facing the audience and the speaker. The audience feed was sent to the network audience during question times between the sites. An overhead video projection facility was used to show video from the operating theatres or from the network; this feed was also displayed on a large screen monitor on one side of the room. Lecturers in the seminar room wore clip-on radio microphones and a hand-held radio microphone was available for audience questions. The operating theatre staff also wore clip-on radio microphones.

The technical quality of the audio and video emanating from the hospital was generally excellent. The problem with audio level control was occasionally apparent as individual participant surgeons varied their voice input and put their microphones closer to or further from their faces. The return audio was also a problem at times, especially from Sahlgrenska. This was caused by input audio gain being too high and causing distortion which persisted despite the local technical staff reducing the playout level.

The reaction of the local workshop members was that the quality was not yet good enough for the fluoroscopic and ultrasound transmissions, but they were impressed with what had been achieved. The organiser, Dr Mike Kellett, was very impressed with the improved video quality in particular, but less so with the audio. This was partly a reflection of the above-mentioned problem of distortion during the transmission from Sahlgrenska.

The main problem was the audio distortion described in the technical evaluation. Since there was no echo cancellation available at the Sahlgrenska site, they could not be contacted via the audio channel while their transmission was underway. Since the Middlesex hospital was unable to indicate the problem on the control channel since they were not able to use NTE, there was no way to correct the problem at source. None of this was caused by the network or the tools, but was a reflection on the perennial problems of the analogue domain at the either end of the transmission.

The video quality from the Sahlgrenska was good enough to be remarkable to those who had seen the previous experiment and can be counted a success.

Sahlgrenska Hospital, Gothenburg

The Sahlgrenska Hospital participated in the original experiment in November 1994. As on that occasion, the site was both a transmitter of surgical procedures performed in real-time and a receiver of the procedures transmitted from UCL. The surgeons performing the procedures were Professor Silas Pettersson and Dr Krister Dahlstrand. The local audience was about 30 people in total, with 20 present at any given time. It consisted of a mixture of people - doctors, nurses and even patients.

The Mbone was extended from KTH by the addition of a new tunnel directly to part of the Swedish university network at Sahlgrenska University Hospital not previously on the Mbone. It was then linked to the operating theatre and lecture room by extending the local ethernet from a secretary's room. The connection to KTH went via the normal SUNET backbone (10 Mbps locally, 34 Mbps intercity with no congestion on that part).

During the event, staff in Gothenburg were able to monitor traffic between UCL and KTH by accessing the KTH router connecting UCL to KTH and thence to Gothenburg.

There was a camera in operating theatre and connections from the endoscope and ultrasound viewer. These three video signals were mixed locally in the theatre. The surgeon used a wireless microphone. In the lecture room there was a room camera and a document camera. Microphones were attached to the speaker's stand and a hand-held radio microphone was provided for questions. An audio mixer was used for all audio; the camera operators were linked by an intercom system. Incoming sound was sent to a loudspeaker. The digital equipment used in lecture room consisted of three Sun Ultras used for:

1. video encoding and as a technical console
2. Mbone routing, video display and audio
3. room display at moderate quality via an overhead LCD and backup

In addition there were miscellaneous items: Network hubs, etc.

Using RAT instead of vat for audio was a real success, showing none of the characteristic vat voice chopping, despite occasionally high video loss rates due to the overloaded links. Audio reception was less than acceptable only during the questions from UCL after the Gothenburg session, due to an analogue problem at the UCL end. The remote echo problem was countered by manually switching between net mutes mike and mike mutes net settings on RAT.

When UCL was transmitting the workshop from the Middlesex, the data rate rose from 300 Kbps to 6-700 Kbps causing video to suffer from the resultant packet loss. When the rate was reduced again, video improved. At this stage in the proceedings the main load on the network was from the transmission from the Middlesex, with Gothenburg transmitting an image of the local conference room at only 30 Kbps. Since audio worked well at all times, the video loss was not in any way a disaster, but still caused annoyance and some confusion.

During the transmission of the procedures from Sahlgrenska, Gothenburg generated some 3-400 Kbps with little from UCL or other sites. However, the 300 Kbps coming from UCL to KTH was clearly not generated by UCL or anybody else in the MERCI network, but originated elsewhere. This was ordinary Mbone traffic that leaked into the MERCI links at the RUS site. One example of this traffic is given in the trace of Active IP Multicast Sources - sending >= 4 Kbps, shown in the Appendix.

Adding the 400 Kbps of video traffic of the workshop to the 300 Kbps background load from RUS via UCL to KTH caused occasional losses of up to 25%. The problem was further exacerbated by the IP packet to ATM cell mapping for these rather short packets which can cause 1 Mbps ATM links to provide as little as 700 Kbps of IP capacity.

Those attending were very interested in the whole project, but most were short of time to spend observing. The surgeons, in particular, were very enthusiastic. Some doctors were impressed by the relative simplicity of the network setup.

The greatest problem was the overloading of the MERCI Multicast links due to inbound Mbone traffic leakage. Dealing with this took a lot of time which could otherwise have been used to test audio and polish interactions between sites. The Audio configuration for question sessions worked only with manual intervention.

The greatest success was the image quality, which, despite the problems, was generally very good. The exceptions occurred at times of rapid movement on the screen, particularly in the image from the endoscope. It was unfortunate that we were only able to send at 400 Kbps for most of the time; even so, the frame rate was up to 20 fps at times before falling to 2-3 fps during sustained image movements. The surgeons commented positively on the image quality, especially compared to that during the previous event in 1994.

KTH, Stockholm

One doctor attended the centre in Stockholm, and watched from a local workstation.

KTH uses a separate part of its local department network for multicast directed from/to the MERCI JAMES links. In this event KTH was mainly a relay station to connect the JAMES link to the small Mbone island created at the Sahlgrenska Hospital just for this workshop.

Since only one doctor (a professor) showed up, he simply sat with the technician in the control room and watched parts of the event. A lecture hall, with video projection and interactive audio, had been made available, but was not needed.

The multicast router configuration to isolate traffic on separate parts of the Mbone is very obviously a non-trivial problem, which was actually solved using brute force by simply disconnecting the MERCI Mbone part of the local network from the standard global Mbone.

Although KTH was acting as a relay to Sahlgrenska Hospital for this workshop, since the traffic was going through anyway, we invited medical staff from the Karolinska Hospital in Stockholm to attend. The attending doctor showed great interest in the technology itself since it was new to him.

The main problem was the Mbone setup since it requires a cooperative isolation of all the partners involved to avoid leakage of standard Mbone traffic into the experimental JAMES Mbone. The relay to Gothenburg was a complete success.

RUS, Stuttgart

For most of the time, audio and video quality was not acceptable at RUS because the local Mbone router was completely overloaded. Unfortunately, there were a lot of other Mbone transmissions taking place simultaneously and, unlike the situation at UCL, it was not possible to cut off the normal Mbone traffic at RUS. With the many new settings used together for the first time and the changed network setup, it might have been better had more time been available for set-up.

The local network configuration is shown in Figure 4 below.

The conference room was set up with an SGI Indy R4000 running IRIX 5.3. The video was taken, via an RGB amplifier, to a video projection device for local viewing and, via a scan converter, to a Video Tape Recorder. The audio was fed, via an amplifier, to a loudspeaker for the local audience and, via the Scan Converter, to the tape recorder. Most of the transmission was videotaped as S-VHS.

The quality was poor due to high packet loss (at times it was above 50% for video). This was due to a completely overloaded Mbone router (generating "mrinfo" timeouts) caused by the inability to separate the ATM links (JAMES and the CRC VP) in the time available. The traffic came in "waves" of periodically increasing packet rates culminating in the complete cessation of audio/video reception until the packet rates had dropped again. The transmission from the Sahlgrenska hospital was of a more acceptable quality, possibly as a result of lower traffic on the normal Mbone during the lunch period.

The following monitoring statistics were noted.

• mtrace RTTs from "Mbone-atm.rus.uni-stuttgart.de" to "lea-c.cs.ucl.ac.uk" were between 255ms and 811ms
• Mean router packet rates were:

• There were millions of output errors on the ATM interface, which is used for IP over ATM.
• Packet rates for Mbone-ATM (virtual interface, IP over ATM) were: In: from 3/sec to 111/sec Out: from 157/sec to 356/sec

There were no surgeons or other medical staff for this event as there had been no interest shown by the staff in the local hospital. Three members of the MERCI technical team were in attendance to monitor quality and identify problems. Some of the video produced will be shown to local surgeons to try to elicit interest prior to any further event.

The Mbone router could not be separated from the "normal" Mbone and there were a number of other Mbone sessions going on at the same time as the surgical workshop. The consequence was a complete overload of the Mbone router. When the video rate from UCL was reduced from 600 Kbps to 400 Kbps the quality of the reception in Stuttgart was greatly improved.

Also the transmission from Sahlgrenska hospital was acceptable almost all the time. As it was between 13:00 and 14:00 UTC, it may have been the result of the other Mbone transmissions shutting down for lunch.

While specifying the administrative scoping on the routers, RUS accidentally cut off CRC by specifying their tunnel as the boundary. This was not recognised at the time it was implemented and it was not realised until after the event that this was the problem.

Encryption worked well and caused no problems.

Almost everything received has been recorded on S-VHS and will be used to construct the video of the event.

The Multimedia Communications Group, University of Glasgow

The Multimedia Communications Group (MCG) [8], University of Glasgow, hosted three registrars from Gartnavel Hospital in Glasgow. They were David Hendry, Mark Underwood and Chris Hagan. The problems of providing the high-bandwidth links required to the hospital itself meant that it was easier, in this first instance, to hold the event at a well-connected and experienced multicast-capable site. MCG shares with the Computing Services department of the University of Edinburgh the work of the Multimedia National Support Centre (MNSC) for Scotland. The event in general went really well. Apart from a few short periods of time, high quality audio and video was received throughout the session.

A direct tunnel was configured to the UCL multicast router. This was run as a temporary point-to-point link over the SuperJANET SMDS. The local network topology is shown in figure 5.

One of the computer laboratory rooms was used and this was relatively quiet due to the absence of other equipment or people. The computer used was a SUN SPARC 20 running Solaris 2.5.1 with a JVC camera, Roland amplifying speakers and a standard SUN microphone.

Technical quality was good by normal Mbone standards, though not considered good enough for diagnosis by the surgeons attending. Apart from some audio echo generated at source during the session from Gothenburg, the audio and video was maintained at high quality and was stable throughout.

The surgeons were very impressed with the event. Initially, they were more interested in the technology and proceeded to ignore the surgery to avidly read the debugging dialogues on NT. After approximately 30 minutes, when the novelty factor had worn off, they became engrossed in the operations to the extent that they seemed to become less aware of the technology.

All three were experienced in this field and one of their more interesting observations related to the reality of the videoconferencing situation. A comparison was made to medical videos where the footage is obviously edited to present the perfect flawless operation whereas, in this case, they were witnessing experts in a live situation encountering real problems. Although the surgeons appeared to be able to distinguish certain details from the remote x-ray images, it was felt that image quality would have to improve a lot further before it could be considered reliable for diagnosis.

The local surgeons were extremely reluctant to interact with the surgeons on screen; this appeared to be the result of shyness induced by the technology.

There were no major problems in the reception of the multicast and the overall impact was good on the surgeons who attended.

CRC, Ottawa, Canada

Reception at CRC was never really satisfactory. Things were working well until around 22:00 CET on the Wednesday evening when admin scoped addresses began to be used.

Because of the insecure nature of the link, we did not invite many people to the event. On the Thursday morning the link was down so the event was cancelled.

The strategy of separating the MERCI Mbone from the global Mbone was broadly a success. The need to guarantee the availability of adequate bandwidth for the workshop prompted this separation of the MERCI JAMES links into a high bandwidth multicast island, separate from the global Mbone. The implementation of the strategy failed due to problems at RUS in isolating the router used for the surgical multicast from the normal Mbone. This will be the way we can guarantee the necessary network resources for high-quality multicast sessions in the period before the ubiquitous deployment of RSVP.

Successes

The transmission from Gothenburg was a particular success which resulted from the hard work and technical excellence displayed by the Swedish team at KTH and at Sahlgrenska.

Failures

The fact that ordinary Mbone leaked into our private MERCI Mbone network..

Work needed for the future

The major need is for some means of guaranteeing the bandwidth needed for high quality multimedia transmissions. The effort required to set up a MERCI Mbone for the transmission of this event cannot be provided on a routine basis; we need to be able to guarantee QoS.

The Mbone "flood-and-prune" paradigm doesn't really hold. It may be that Cisco DVMRP prune implementation is very slow before it starts pruning, but in any case KTH received Mbone data that nobody had asked for, it was then pruned, came back, was pruned, etc, etc.

Institute of Urology, Middlesex Hospital: Dr M Kellett, Mr H N Whitfield.

UCL Multimedia Centre: Chris Macnab, Ronald Bartholomew and Gordon Jameson.

UCL Department of Computer Science: Dennis Timm

KTH, Stockholm: Ulf Bilting,

Sahlgrenska Hospital, Gothenburg: Professor Silas Pettersson and Dr Krister Dahlstrand.

Chalmers University of Technology, Gothenburg: The Networking Group

RUS, Stuttgart: Andreas Rozek,

[1] Multimedia European Research Conferencing Integration (MERCI)

http://www-mice.cs.ucl.ac.uk/merci/

[2] Multimedia Integrated Conferencing for European researchers (MICE)

http://www-mice.cs.ucl.ac.uk/mice/mice_home.html

[3] Joint ATM Experiment on European Services (JAMES)

http://btlabs1.labs.bt.com/profsoc/james/

[4] LIVENET

[5] The RAT (Robust-Audio Tool) Home Page

http://www-mice.cs.ucl.ac.uk/mice/rat/

[7] Handley, M J: Network Text Editor (NTE), manual pages, University College London (UCL), 1995.

ftp://cs.ucl.ac.uk/mice/videoconference/nte/

[8] Multimedia Communications Group (MCG), University of Glasgow

http://www.mcg.gla.ac.uk/

This is a snapshot of the multicast sources seen by magda-gw at KTH.

The inclusion of mmsun1.ira.uka.de->224.2.182.227/154kbps shows the problem of leakage of normal Mbone traffic into the MERCI ATM setup.

Date: Thu, 20 Feb 1997 14:49:47 +0100 (MET)

magda-gw>sho ip mroute act

Active IP Multicast Sources - sending >= 4 kbps

Group: 224.2.211.167, (?)

Source: 203.251.135.22 (?)

Rate: 10 pps/16 kbps(1sec), 25 kbps(last 22 secs), 4 kbps(life avg)

Group: 224.2.182.227, (?)

Source: 129.13.34.2 (mmsun1.ira.uka.de)

Rate: 26 pps/154 kbps(1sec), 172 kbps(last 45 secs), 171 kbps(life avg)

Group: 239.2.17.8, (?)

Source: 128.16.64.36 (mickey.cs.ucl.ac.uk)

Rate: 10 pps/6 kbps(1sec), 6 kbps(last 55 secs), 2 kbps(life avg)

Source: 130.209.192.21 (harrier.mcg.gla.ac.uk)

Rate: 9 pps/5 kbps(1sec), 6 kbps(last 10 secs), 4 kbps(life avg)

Source: 130.237.15.130 (skutt.it.kth.se)

Rate: 15 pps/5 kbps(1sec), 4 kbps(last 21 secs), 0 kbps(life avg)

Source: 130.241.83.22 (Mbone2.rontgen.gu.se)

Rate: 10 pps/6 kbps(1sec), 6 kbps(last 11 secs), 3 kbps(life avg)

Group: 224.2.138.145, (?)

Source: 203.240.251.149 (?)

Rate: 2 pps/9 kbps(1sec), 2 kbps(last 52 secs), 3 kbps(life avg)

Group: 239.2.17.6, (?)

Source: 128.16.64.45 (eucharisto.cs.ucl.ac.uk)

Rate: 0 pps/0 kbps(1sec), 54 kbps(last 30 secs), 175 kbps(life avg)

Source: 130.241.83.22 (Mbone2.rontgen.gu.se)

Rate: 55 pps/384 kbps(1sec), 321 kbps(last 26 secs), 55 kbps(life avg)

Group: 239.2.17.7, (?)

Source: 128.16.64.45 (eucharisto.cs.ucl.ac.uk)

Rate: 4 pps/19 kbps(1sec), 53 kbps(last 44 secs), 43 kbps(life avg)

Source: 130.241.83.22 (Mbone2.rontgen.gu.se)

Rate: 5 pps/25 kbps(1sec), 53 kbps(last 37 secs), 2 kbps(life avg)

RUS

1 193.196.152.11 (193.196.152.11) 5 ms 3 ms 2 ms

2 193.196.152.225 (193.196.152.225) 139 ms 17 ms 3 ms

3 BelWue-GW.Uni-Stuttgart.DE (129.143.70.9) 2 ms 5 ms 4 ms

4 cisco4-fddi (129.69.18.20) 3 ms 3 ms 4 ms