Since October 1993, the project has also been running a series of MICE International Research Seminars. Speakers working at or visiting partner sites gave presentations on recent research work, which were transmitted to MICE partners and up to 20 other sites via the MBONE. Remote participants could attend these presentations from their conference rooms or workstations, and ask questions and engage in a discussion. Most speakers and participants were not members of the project, so we have had a chance to introduce user groups to the technology.
This report is the deliverable of Workpackage 7. The purpose of this WP is to give an overview of facilities, to summarise our experiences from using these facilities and, most importantly, to provide a critical review of the current state of the technology and give an assessment about its use in future.
Our general impression at the end of Phase 1 is overwhelmingly positive. Many aims have been achieved in terms of making facilities available and gaining insight into their use and potential for improvement. The software is widely installed on SPARCstations, We are working with different hardware and software codecs. Other platforms such as DEC, HP and SG are also in use. The software tools that have been developed by the MICE-partners are:
Several of the partners, in particular GMD, NTR, UiO and UCL, have developed Conference Rooms (CR) as local activities. Based on their experience with Conference Rooms a "reference Conference Room" has been defined. The Conference Rooms have been used in the public demonstrations and for seminars.
Another key concept in the MICE project is the Conference Multiplexing and Management Centre. UCL has developed a CMMC which is accessible from various networks such as EUROPANET, EBONE (as part of the Internet) ISDN, and SuperJanet. The CMMC is under development, and all the tools are described in more detail in the following chapters.
ETSI has made a full service description for the ISDN-videotelephony service (ETS 300 264, ETS 300 266 and ETS 300 267). ITU-TSS has also made a stage-1 description for the videoconferencing service. The general part is available in recommendation F.730 while the ISDN- videoconferencing service is described in recommendation F.731. ETSI will in 1993 start the work of a stage-1 description of ISDN-videoconference service.
The definitions in these two ITU-TSS recommendations are collected in an ETSI-standard, ETS 300 144. All definitions are identical. ITU-TSS recommendation H.242 describes the procedures for inband signalling. The equivalent ETSI-standard is ETS 300 143.
By the introduction of videotelephone terminals in Europe it became obvious that the manufacturers had different interpretations of the CCITT-recommendations. As part of the EV project (European Videophone) an activity was started to identify the problems. Results from this work were used when the ETSI standards ETS 300 143 and 300 144 were defined. These standards are therefore more precise than the ITU-TSS recommendations.
Three audio coding algorithms are now available:
There is also work going on within ETSI to define a standard for describing an interface for a low speed data channel based on V.24-connections (DE/TE04114). This solution can be considered as a modem function and all known communication protocols from datacommunication within the analogue telephone network can be used.
This draft is also presented as a proposal for an ITU-TSS recommendation. In addition, ITU-TSS is working with recommendations for a special purpose communication protocol for data communication in multipoint conferencing. This protocol will also offer functions for controlling multipoint conferences.
To allow time for the Internet community to consider and react to standardization proposals, the IAB imposes a minimum delay of 4 months before a proposed standard can be advanced to a draft standard and 6 months before a draft standard can be promoted to standard. It is general IAB practice that no proposed standard can be promoted to draft standard without at least two independent implementations (and the recommendation of the IESG). Promotion from draft standard to standard generally requires operational experience and demonstrated interoperability of two or more implementations (and the recommendation of the IESG)
Advancement of a protocol to proposed standard is an important step since it marks a protocol as a candidate for eventual standardization (it puts the protocol "on the standards track"). Advancement to draft standard is a major step which warns the community that, unless major objections are raised or flaws are discovered, the protocol is likely to be advanced to standard in six months.
The H.261 standard includes descriptions of a coding mechanism and a scheme to organize video data in a hierarchical fashion. The compression techniques used by the coding mechanism include transform coding, quantisation, Huffman encoding and, optionally, motion vector compensation.
In order to allow a single recommendation to cover use between regions employing different television standards, the CCITT has adopted the Common Intermediate Format (CIF) and the Quarter-CIF (QCIF). Pictures are encoded as luminance (Y) and two colour-difference components (CB and CR). Y, CB and CR components are each functions of the standard chrominance components (red, green and blue) and are defined in CCIR Recommendation 601.
CIF has 352 pixels per line and 288 lines per picture. Since each block of four pixels is encoded with four Y, one CB and one CR component, sampling of the two colour-difference component is 176 pixels per line, 144 lines per image all in an orthogonal arrangement. QCIF (Quarter-CIF) has half as many pixels and half as many lines as CIF. All codecs must be able to handle QCIF whereas use of CIF is optional. As a rule, QCIF is used for desktop videophone applications and CIF is more suitable for videoconferencing applications due to its higher resolution.
Coding is done either on the input pictures, or on the difference between successive images, i.e. the prediction error. The first case is referred as intraframe coding (INTRA mode), the second case to interframe coding (INTER mode). Intraframe coding means that the image is encoded without any relation to the older sequences. This kind of encoding removes only the spatial redundancy in a picture whereas interframe coding also removes the temporal redundancy between pictures. With interframe coding, it is the difference between the current and the predicted image which is transformed by discrete cosine transform and then linearly quantized.
Intraframe coding is used for the first image and for later pictures after a change of scene whereas interframe coding is used for sequences of similar pictures with moving objects. H.261 does not determine a specific refreshment rate, but for control and accumulation of inverse transform mismatch error it requires that a macroblock must be forcibly updated at least once per 132 times it is transmitted.
CIF and QCIF pictures are arranged in a hierarchical structure consisting of four layers, namely the Picture layer (P), the Group Of Blocks layer (GOB), the MacroBlock layer (MB) and the Block layer (B). A CIF picture is divided into 12 GOBs. A QCIF picture is divided into 3 GOBs. A GOB is composed of 3*11 MBs and each MB contains six blocks: four 8x8 luminance blocks (Y) and two colour-difference 8x8 chrominance blocks (CB and CR). Chrominance difference samples are sited such that their block boundaries coincide with luminance block boundaries.
Data for each picture consists of a picture header followed by data for GOBs. Picture headers for dropped pictures are not transmitted. The picture header contains a 20-bit Picture Code Start and some additional information including Temporal Reference and video format used (CIF or QCIF).
Data for each GOB consists of a GOB header followed by MB data. The GOB header is transmitted even if no macroblock data is present in that GOB. It includes a 16-bit GOB start code, the group number, and the quantizer to be used until overridden by any subsequent MB quantizer information. Note that the quantizer can be changed at the MB or at the GOB level.
Data for a MB consists of an MB header followed by data for blocks. The MB header includes a variable length codeword (VLC) which indicates the position of the MB inside the GOB. It is followed by a VLC for MB type (type M). This type indicates whether the MB is interframe or intraframe, with or without motion vector estimation and/or loop filter, and with or without a new quantizer. Motion estimation may be used to encode the motion of a MB between two consecutive images. If type M so indicates, a new quantizer, motion vector data and coded block pattern may follow. The latter gives a pattern number signifying those blocks in the MB for which at least one transform coefficient is transmitted. The quantizer is identical for each block in the same macroblock. Note that not every MB in a GOB or not every GOB in an image needs to be transmitted if it does not contain any information for that part of picture.
Data for a block consists of codewords for transform coefficients followed by a fixed length code End of Block (EOB) marker. All of the quantized coefficients are ordered into a zigzag sequence. This order of transmission helps to facilitate entropy coding by placing low frequency coefficients (which are more likely to be non-zero) before high frequency coefficients.
The most commonly occurring combinations of successive zeros and the following value are encoded with a VLC. The other sequences are each encoded with a 20-bit static word. The coefficient with zero frequency in both dimensions is called the DC coefficient and the remaining 63 coefficients are called the AC coefficients. Generally, most of the spatial frequencies have zero and near-zero amplitude and need not be encoded. On the other hand, the DC coefficient frequently contains a significant fraction of the total image energy. So, the DC coefficient is treated with more precision than the 63 AC coefficients, using a linear quantizer.
The H.221 serial line framing protocol consists of 80 byte frames, with synchronisation, H.230, and H.242 protocols occupying bit 8 of the first 16 bytes in each frame. In the rest of a frame, there are policies for which bits in frame contain video data, audio data and user data. The video data itself is contained inside 64 byte frames which contain 18 bits of cyclic redundancy check to protect the video data against bit errors.
If we attempt to transmit H.221 framed video data over a packet network, we find that these three uncorrelated framing schemes (H.261 GOB's, H.261 CRC's and H.221 frames) now give no way to packetise the data and sustain all these framing schemes in the face of packet loss. Thus the H.221 standard (and thus the encapsulated H.230 and H.242 standards) are not well suited for transmission over packet networks.
In fact, we find that, if we have to use codecs which produce H.221 framed H.261 video to communicate over a packet network, it is advisable to utilise a workstation to remove the H.221 protocol and the H.261 CRC at the sending site, and re-insert them at the receiving site. This can be done at rates of up to around 512kbps on today's workstations. In fact, if this is done, the CRC padding frames are also removed, and much of the time the transmitted data rates over the packet network can be considerably less than the same stream with H.221 framing.
There has been a tremendous effort to specify a public broadband network for Europe during the last five years. Also initiatives to develop components and subsystems to make such networks cost effective. Several long term EC projects have been initiated. RACE has been arguably the most influential in the context of telecommunications.
Computer vendors and users seem to have run into a serious problem. Current leading LAN technology does not meet their requirements when it comes to speed and capability to keep up with new generations of workstations (desktop computers) that are doubling their performance every 12 to 18 months. According to a leading computer manufacturer the following three emerging technologies seem to have the power to overcome the LAN bottleneck:
According to workstation users, there are certain requirements to be met. First of all they need a high-speed/low cost LAN i.e. above 100 Mbps. Next is the ability to increase LAN speed without having to change the infrastructure (cabling etc.). They are also very interested in support for multimedia applications such as video multicasting for conferencing. The possibility to expand the LAN for wide area interconnection is also of high priority.
Future workstation and PC's will have the capability to operate at both 10 and 100 Mbps and automatically detect what speed is appropriate for a given situation.
Maintaining compatibility with the existing 10 Mbps by preserving the users investment in cabling etc. is the main emphasis in the standardization task. By doing this the transition from 10 to 100 Mbps is made more convenient.
A Frame Relay network is made up of network nodes and DTE (Data Terminal Equipment). The DTE can be a PC, router, or a host with a Frame Relay interface, and connects the user to the network. Both CCITT and ANSI describe the standard in their respective recommendations. The standard defines link-level data and signal transmission and OSI level 2 in the user equipment - network interface.
When a DTE transmits frames to the network the nodes will read the identifier then look up the tables to find the right outgoing channel and so send the frame to the next node. The use of several identification codes allows several parallel sessions in different directions to coexist on the same physical link. DTE's can therefore communicate with different destinations simultaneously over the same access to the network. This is a prerequisite for LAN users.
Frames indicated as erroneous by the Frame Checking Sequence are discarded. Higher level protocols must secure error-free DTE - DTE transmission. If errors occur and are corrected the data must be retransmitted through the entire network and this takes a longer time than retransmitting only over the link where the error occurred. Therefore the transmission medium quality has an important role for Frame Relay. A limit where Frame Relay is effective is set at Basic Error Rate < 10 - 6 on individual links. Such an error rate can be handled by a speed of several Mbps over most transmission links. A maximum link transmission speed of 2 Mbps is presently defined. Higher speeds, 2 - 34 Mbps, are under consideration, but it may be that other broadband services would be more suitable for this part of the market.
The interest in connectionless service originates from the need to provide cost-effective services with high throughput and low delay for bitrates higher than those provided by Frame Relay. ETSI has specified Connectionless Broadband Data Service. This service offers bitrates of 2 Mbps, 34 Mbps, 139 Mbps and 155 Mbps. These bitrates are compatible with the existing transmission hierarchy in public network.
The connectionless service features make CBDS very suitable for LAN interconnections, particularly in the medium to long term. As FDDI, with its nominal rate of 100 Mbps, is becoming widespread, the bandwidth requirement for LAN interconnection can rise to 30 to 60 Mbps, a rate easily handled by CBDS. The CBDS being used in a MAN can also be offered over ATM. Offered in a MAN it gives regional coverage, offered over ATM promises virtually unlimited coverage, depending on the penetration of ATM.
Figure 1 ATM-cell
There is a high national activity within the area of high speed networks, and ATM is certainly the hottest item on the list. It is predicted that its only barrier will be cost, but, as the industry seems to find the technology most promising, the cost problem could be considerably reduced as the volume of ATM products is rapidly increasing.
An early recommendation is CCITT F.811 "Broadband Connection Oriented Bearer Service". Now, several RACE projects and the ATM Forum are de facto standardisation bodies. In reference [5], Haugen and Mannsåker (at NTR) suggest that there are two possible scenarios for introduction of public broadband networks:
During the MICE project, two partners never had access to the international networks - Nottingham University and ONERA. The Nottingham University problem was that JANET did not permit their access; ONERA had internal difficulties in attaining network access. ULB (Belgium) only achieved access at the end of the project - in November 1993; this had to await the commissioning of the Belgian EUROPANET access. The international network topology and line speeds are changing rapidly. The comments in this section (as in the whole report) represent the situation to the end of1993.
It is important to have powerful enough routers attached to the EUROPANET access point. In the IETF demonstration, the German routers were not adequate, and even 192 kbps MICE traffic wreaked havoc on the DFN international connections (this has been remedied).
France (INRIA), Nordunet (SICS and Oslo U), Germany (GMD-Birlinghoven and RUS), UK (UCL) all have direct access to EBONE; however, there were bandwidth difficulties in GMD-Darmstadt in accessing international facilities in that way. The traffic properties are well matched to MICE needs; the European bandwidth available is not. Currently the Swedish - Geneva link is all at 2 Mbps, though the Geneva- France is now at 2Mbps. The direct UK-France link no longer exist. UK-Swedish links are at 256 kbps; the links are heavily loaded without MICE traffic, and are quite inadequate for MICE usage. However, the traffic between Scandinavia and the UK and Germany can use EBONE to Amsterdam, and then the 512 kbps link to EUROPANET to carry MICE traffic; that link is usually adequate.
France, Germany, Sweden and the UK all have direct links to the US Internet on links which could be classed as EBONE via the US Internet. The German-US link is only at 256 kbps, and has not been used for MICE purposes. The other three are currently at 1.5 Mbps - though the UK-US one is hard-multiplexed (see below). All have been used for MICE traffic, and normally give adequate performance. This mode of us e is permissible for traffic with the US, but is discouraged for inter-European collaboration under MICE auspices. The May JENC demonstration used this mode of access - but it is clearly undesirable politically, and expensive to traverse the Atlantic twice. The route is quite feasible technically - and in fact is the only one with the present topology which allows INRIA to participate in MICE.
The EBONE-EUROPANET link does allow EBONE to be used for those sites that have reasonable connectivity by that route, and EUROPANET for those with better access to that network. At present SICS, Oslo U and RUS gain from connectivity via the EBONE connection and the EUROPANET EBONE link; when the CERN-Paris link is upgraded, we expect INRIA traffic to use the same route.
The MBone is not a production network; it is often emphasised that it is primarily an experiment. However, it is becoming very popular and also rather stable, so many people view it as a regular service. This is due to the tremendous effort put in by volunteers among network providers, researchers and end-users.
Here we will first cover some technical background on the MBone itself, in particular as it operates currently. Then we will list a number of symptoms that have surfaced during operation of MBone and examine the cause and what the cure has been. Last, we will take a broad look onto the problems of multicasting in general and the current technology specifically. The MBone is a virtual network running on top of the Internet. MBone is composed of islands that can directly support multicast, such as ethernet and FDDI. These network are linked by "tunnels". The tunnel end-points are hosts which continuously execute the "mrouted" multicast routing daemon.
Figure 2. MBone topology - islands, tunnels, mrouted
In the figure above there is a simple example of three islands as part of the MBone. Each island consists of a local network connecting a number of clients ("C") and one host running mrouted ("M"). The mrouted-hosts are linked with point-to-point tunnels. There are usually primary tunnels, with other routes acting as a backups. All traffic on MBone uses UDP rather than TCP. One reason is that TCP is a point-to-point connection oriented protocol that does not easily lend itself to multicasting. Another reason is that the reliability and flow control mechanisms are not suitable to live audio casting. Occasional loss of an audio packet (as when using UDP) is usually acceptable whereas the delay for retransmission (when using TCP) is not acceptable in a interactive conference.
Each tunnel has a metric and a threshold. The metric specifies a cost that is used in Distance Vector Multicast Routing Protocol (DVMRP), described in RFC 1075 and RFC 1058. To implement the primary (thick) and backup (thin) tunnels in figure 2, the metrics could have been specified as 1 for the thick tunnels and 3 for the thin tunnel. The threshold is the minimum time-to-live that a multicast datagram needs to be forwarded onto a given tunnel. With that mechanism we can limit the scope for a multicast transmission. Up until recently tunnels were implemented using the IP Loose Source and Record Route option. Mrouted modifies the multicast datagram by appending an IP LSRR option where the multicast address is placed. The IP destination address contains the unicast address of them routed on the other side of the tunnel.
There has been some problems with this approach which prompted the implementation of encapsulation. In this method the original multicast datagram will be encapsulated into the data part of a normal IP datagram that is addressed to the mrouted on the other side of the tunnel. The receiving mrouted will strip off the encapsulation and forward the datagram appropriately. Both these methods are available in the current implementation.
At present there is no pruning of the multicast tree. That is, every multicast datagram is sent to every mrouted in MBone if it passes the threshold limit. The only pruning is done at the leaf subnets, where the local mrouted will only put a datagram onto the local network if there is a client host that has joined a particular multicast group or address.
There is no network provider of MBone. In the spirit of Internet, MBone is loosely coordinated via a mailing list. The intent with this mailing list is to co-ordinate the top levels of the topology. It mainly consists of people who administrate the backbones, such as NSFnet/ANSnet regional networks such as NEARnet, SURAnet, and so on. The current position is that when a regional network wishes to join MBone, they will make a request on the mailing list and some MBone node "nearby" will set-up a tunnel to the new participant. When end-users wants to connect to MBone, they are encouraged to contact their network provider. If that network provider is not participating in MBone and for some reason does not want to, a tunnel can be set-up to another point in MBone. From time to time, there has been major overhauls of the topology as MBone has grown. Usually this has been prompted by an forthcoming IETF meeting which put a big strain on MBone. The IETF multicast traffic has been between 100 and 300 kbps with peaks of up to 500 kbps.
The use of the MBONE has been growing at a staggering rate. A wide variety of users, ranging across many disciplines have started to make use of the network. One of the more widely publicized projects has been the JASON project, from The Woods Hole Oceanographic Institution. In 1993, 600,000 school students took part in remote sensing of the sea bed (the Sea of Cortez mentioned previously), although this application was mainly for the multicasting of data (c.f. imm).
The Mbone FAQ [8] is currently the best source of information and is updated regularly.
These incompatibilities can be overcome in many ways - but we have not done so yet. To have done so during the period of MICE-I would have been possible only by replicating the equipment used for one channel, rather than using the PR interface; this would have been expensive, could not be scaled, and was contrary to the architecture of the rest of the MICE system. We have shown that the ISDN is quite satisfactory for connecting equipment internationally over single channels, and intend to develop our ISDN capability in full; this will require, however, work on several different components to achieve compatibility in the lower levels of data transmission (as distinct from the ISDN signalling) and it has not yet been established that all the systems would operate in any Open Systems way internationally over multiple BR ISDN channels. Clearly the message is that further standardisation of network protocols at the higher levels is still needed - particularly between the worlds represented by the manufacturers of codecs, workstations, and data transmission equipment.
In France, Renater is moving towards a National higher speed infrastructure; more immediately, there is a 100 Mbps extended FDDI infrastructure which includes INRIA at Sophia Antipolis. There are some projects which will provide international connectivity at higher speeds - but these are not yet planned to provide general higher speed working In Germany, both GMD and RUS are part of national higher speed activities. GMD has interconnections between its own sites at higher speeds. GMD-Focus, in Berlin, is part of the BERKOM-II project, and is building an internal ATM infrastructure.
BERKOM-II itself is building an ATM infrastructure - with DFN collaboration. GMD-Darmstadt, the MICE-I partner, will require to deploy multimedia both inside GMD and the DFN. It is currently not assured that the GMD deployment will be based on MICE software, but this is certainly being considered. RUS, in addition to being part of the German ATM field trials, is central to the Baden-Wuerttemberg research network (BelWue) - which is just being upgraded to 34 Mbps ATM.
In Norway, the University of Oslo contains is one of the four main centres of the UNINETT national research network which is currently being upgraded to 34 Mbps. In addition to any work under MICE, UiO is involved in major development projects on electronic classrooms and other distance education tools. In Sweden, SICS is one of the main partners of the Multi-G project, which is providing an ATM infrastructure and also wide-area high-speed education environments.
Figure 3. Schematic of the MICE Conference Management and Multiplexing Centre
In the UK, UCL is one of the original major nodes on SuperJanet - with 155 Mbps access now, and a commitment to provide ATM in early 1994. Like UiO and SICS, UCL are involved in distance education projects. On the international scale, many of the national organisations have discussed participation in other european and intercontinental projects. The French, German, Norwegian, Swedish and UK partners expect to have access to the planned PTO ATM pilot through their national research networks. Independently, the same countries will have access to the same emerging EuroCairn facilities - which is a 34 Mbps infrastructure planned for the RTD community, and is the responsibility of DANTE.
The national network providers must expect a significant increase in traffic as the use of MICE facilities increase. They must prepare for this traffic increase in their forward planning activities right now. It is also of prime importance that a high standard of national network interconnection is provided on a pan-european level.
Most of the projects are developmental in origin, and do not have an emphasis on piloting and operations. Moreover, many of the RACE projects are designed for the circuit-switched, high bandwidth, environment - and would not run over the current research networks. We do not know any which make extensive use of multicast - which is a prerequisite for a large-scale deployment on the current generation of networks; it would also be more efficient on the next generation. The majority of the projects are not open - in the sense that special hardware or software is being developed - but not with the aim of linking outside the project. For example, we know no other European projects which link into US ones.
Many national research network agencies are sponsoring national projects for use over their emerging high speed networks. Some of these are adopting MICE technology in a pilot form, others have sponsored technologies which have contributed to the MICE technology. While we mention a few of these projects in this chapter, it is more because these might be considered relevant in future MICE activities than any attempt to give an exhaustive list.
The video can be sent both over UDP and TCP; the audio uses a different standard. The control information goes over a separate ISDN channel over TCP. The CMU allows a number of mm calls to be input to the CMU and reproduces together - just as the UCL CMMC; the calls are put as individual windows in the workstations. This system is similar in aim to the MICE workstation, but there is no plan to have it developed over multiple platforms, interwork with other systems, or have the open MICE development environment. Nevertheless, the system is very interesting, and future collaboration is being explored.
The main goal of PAGEIN is to improve the productivity of European aerospace research and industry by advanced computer and network supported cooperative working modes especially in the pre-design phase. The technical goal is to integrate heterogeneous distributed supercomputer simulation, visualization and scientific video with multimedia conferencing facilities into an easy-to-use working environment. The network-political goal is to raise the awareness of relevant political and technical parties of the need for a european high-speed infrastructure by demonstrating PAGEIN results on visible international high-speed network links.
PAGEIN provides a distributed shared memory system on top of both massive parallel and vector architectures as an integrated platform for cooperation aware modules such as simulation codes or modules of the visualization pipeline. Due to the high-dimensionality of data, no shared X-techniques can be used as distribution vehicle. A concept for the integration of the INRIA Video System was developed. In a first attempt PAGEIN has tried to realize an UltraNet to UltraNet Gigabit connection from Paris to Stuttgart via an 140 Mbps PDH link. This attempt was unsuccessful, although several demonstrations on a 140 Mbps PDH infrastructure have been carried out within Germany. PAGEIN was demonstrated internationally using a 2 Mbps link between the Stuttgart SMDS/CBDS field trial and an SMDS island at Interop 93 in Paris. PAGEIN is working towards the use of the international ATM field trial. A PAGEIN prototype is operational. Integration of IVS functionality in still under way.
In the CIO (Coordination Implementation and Operation of Multimedia Teleservices) project, which also involves RUS and is multivendor, they are developing both Multimedia Mail (with X.400 and X.500), and also have a joint viewing and TeleOperation mode. It involves many partners - including Dutch and Spanish PTTs, Siemens, Ascom, ETH, GMD, TUB, RUS and Liege U. In this case the media include text, graphics, video and audio. It includes a message store for the multimedia, and uses both ATM and FDDI. It uses a software package (JVTOS) which is available on the SPARCstation, Apple MAC (MacOS 7.1) and IBM (Windows 3.1). Its current four sites can now interwork. The system uses G711 audio and Motion JPEG, running over TCP/IP. The software would be available to all universities if desired, and will be used in the German Pilots BELWUE (Baden-Wurtenberg), DFN BERKOM and RARE. This system is inappropriate for lower speed networks, and hence would not fit into the CMMC concept. EUROBRIDGE has also developed a multimedia mail product, but shared workspace is not such an important feature of that project.
On equipment provision, UCL - and hence the MICE project - has benefited from extensive equipment provision by Sun Microsystems. This has provided some of t he CMMC facility. At the network technology level, there has been close collaboration - particularly in the MBONE engineering. This activity is global in scope, and transcends the narrow needs of MICE. It has become very clear that resource allocation and reservation are vital ingredients for the success of activities such as MICE, and there has been close collaboration between many sites - in particular LBL, Xerox and UCL - in developing fair-share algorithms which should improve future generations of MBONE. It is also likely that the US router manufacturers will put the results of this collaboration into their next generation of equipment - we must hope that the european manufacturers will follow suit.
At the component level, there has been remarkably close collaboration between INRIA, SICS, UCL, LBL and XEROX - in design, implementation, and deployment. The LBL VAT is the voice tool used exclusively in MICE at present - but it has had input from a number of MICE partners in different aspects. The LBL WhiteBoard (WB) is the only shared workspace system used in production on MICE up to November 1993. The INRIA IVS and Xerox S/w video systems have been used on both sides of the Atlantic - and have both profited from the collaboration; it is the INRIA system which is used mainly in MICE, but we have also used the Xerox system in some of the events.
At the System level, the MICE partners have participated closely in the Internet t Engineering Task Force (IETF) working groups in different relevant areas. The most important of these are the following: multicast, resource allocation, multimedia transport and multimedia control. The IETF standards have been influenced strongly by MICE partners - and are often being used in the MICE components and systems.
The MICE partners have participated in many US events - and US partners in MICE ones. At all the European major public events (e.g. JENC 93, IETF July 1993 and INTEROP October 1993) there have been both European and US participants. MICE partners have participated in many US events (e.g. other IETF meetings, US INTEROP meetings and the Global Schoolhouse). Xerox and LBL participate in the MICE Seminar series - and MICE partners have participated in many similar US events.
MICE-I has attracted strong interest in the US; official proposals to the NSF from MCNC have specifically highlighted collaboration with MICE; we have received specific statements that proposals to the NSF for common management standards would be received favourably - and have identified two groups who plan to make such proposals to NSF. There is an ongoing collaboration with ARPA sites at least through 1994. There is a firm commitment from at least one DOE site to collaborate with MICE. At least one site funded by ARPA will be collaborating directly with MICE partners using this technology.
There have been initial contacts with several groups in Australia and Japan. They would like to participate but are not yet clear whether the trans-Pacific network connectivity could support such traffic. This question has been raised in the August 1993 CCIRN meeting, and will be explored further during 1994.
Most of the equipment in a traditional video conference room is designed specifically for video conferencing, under the assumption that one uses only one network, one partner at a time, and the simple metaphor of paper documents and flip-charts or whiteboards. Designers of video conference systems thought only lately about controlling their equipment by computers and using computers or computer controlled devices as input to video conferencing.
Most of the discussion below refers to specifically to the Conference Room at the GMD, but largely similar considerations apply to the other rooms (at UCL, UiO and elsewhere). Certain specific aspects, such as the way ISDN is handled, the use of video projection facilities and the local multiplexing hardware and software differ between installations. The aim here is to make general comments on the requirements of Conference Rooms.
The MICE Project has built up an infrastructure for videoconferencing for the European research community (including access to USA). Participants are either at workstations or in conference rooms (CR), The principal distinction drawn between workstations and conference rooms are the following.
The GMD conference room has been specifically built for teleconferencing, whereas the UCL conference room has been designed to serve both as a regular meeting room and a teleconferencing room. The various NTR and UIO
conference rooms are designed for a special application: distance education. The details of this work can be found in the document entitled Reference Conference Room Specification. The CRs and their inter-operation with other CRs and with workstations were demonstrated at several conferences (references?????). The experiences gained by these demonstrations and tests are described in Section 4 of this report.
Two small studios at USIT and UNIK were established and part of a one semester course was run from UNIK utilizing video conferencing to serve students both there and at the main campus. This experiment demonstrated very clearly the need for additional tools, in particular, one main requirement from the teachers was to have a familiar tool like an ordinary blackboard available. Subsequent work on this issue lead to the development of the present electronic white board which we believe may be unique on the world arena.
We now operate within a framework which we call Distributed Electronic Classrooms, which is further explained below. New equipment and new design is continuously being introduced into this concept.
Unlike most other similar schemes the board is active and enables hand writing on the board in much the same way as it is done on an ordinary blackboard. The present version of the electronic board realizes this by letting the semi-transparent screen also be a large scale digitizing board which can be written on with an electronic pen. The pen movements are conveyed to the controller machine via the ordinary pen coordinate registration facilities contained in such a board. It is of course also possible to erase previously written material on the board using an electronic sponge.
When the lecturer uses the electronic pen on the active part of the board, the coordinates are continuously transmitted to the work station via a 9.6 kbps serial interface. The receiving software in the work station will then initiate the drawing of the corresponding lines in the active board window of the electronic board. In passing, it is worth mentioning that it is considered to be an important presentation issue to make the lines follow the pen in a natural manner.
Persons in all the distributed class rooms can interact via the electronic pens being applied on the active parts of the electronic boards. This means that the lecturer and students, no matter where they are located, get the feeling that they are sharing a common class room, enabling them to write and erase on the electronic white board, as well as to observe and talk to their lecturer(s) and fellow students.
An Xll program has been developed for the electronic white board using the InterViews toolkit. The current program communicates between the classrooms using a simple protocol over TCP/IP.
At the moment, all of the electronic board is active, but in time, we envisage a larger board containing both an active and a passive part, the former allowing hand writing as described above, the other being used primarily as a pure display part showing pictures, animations etc. Furthermore, when there is no more writing space on the active part of the board, it is also possible to move all of the active part to (part of) the passive part in order to keep the previous writing and other material in view while continuing writing in the active part. Thus an effect similar to the well-known sliding blackboards is achieved.
For the white board, communication currently takes place over TCP/IP between dedicated applications on UNIX workstations.
All network communication in the current system is point to point limiting conferences to two classrooms. We are in the process of developing the system further to support multi-party conferencing, and we are using IP Multicast as the base for the communication side of such an extension.
Figure 4. Electronic Whiteboard
Video compression is generally performed by some form of differential coding, i.e. by sending only the differences between two consecutive images. This leads to highly variable transmission rates because the amount of information to code between two images varies a lot, ranging from very low for still scenes to very high for sequences with many scene changes. Packet-switched networks such as the Internet are very well suited for transmitting such variable bit rate traffic.
Many algorithms have been proposed for the coding of video data. Some of them have been standardized such as JPEG, for still images, or MPEG and H.261 for moving images. MPEG coding is suited for high definition video storage and retrieval. Since the H.261 standard is the best suited for videoconferencing applications, we chose to implement in software such a compression scheme in IVS (INRIA Videoconferencing System).
However, this standard was designed for use over the Integrated Services Digital Network (ISDN), i.e. for a network with fixed rate channels and packet-switched networks such as the Internet do not provide such channels. Therefore, it is necessary to adapt H.261 in order to use it over the Internet. We have developed a packetization scheme, an error control scheme and an output rate control scheme that adapts the image coding process based on network conditions. The packetization scheme allows the interoperability with already available hardware codecs.
Our objectives in developing IVS are the following:
Transmitting audio and video data across packet-switched networks offers the well-known benefits of service integration over the circuit-switched approach. However, unlike most other data sent across the network, audio and video data require resource guarantees which are not available yet in the Internet. This requires audio and video conferencing applications to handle packet loss, to maintain synchronization against randomly distributed packet delays and to control their output rate in order to avoid network congestion.
The Workstation workpackage focused on the above problems, in particular adapting to network conditions. In fact, on the Internet, most packet losses are due to congestion rather than transmission errors. Alternately, packets can be delayed or received out of order; this could happen as a result of the routing and flow control in the network. Due to real-time requirements, delayed video packets are considered as lost packets if delay exceeds a maximum delay value.
Using UDP, no mechanism is available at the sender to know if a packet has been successfully received. It is up to the application to handle the packet loss and re-sequencing of out of order packets delivery. In order to adapt to network conditions we proposed to use an end-to-end control mechanism; such a mechanism needs two components, namely a network sensor and a throughput controller. We use feedback mechanisms for video sources in order to adjust the parameters (and hence the output rate) of video encoders based on feedback information about changing capacity in the network.
A camera is needed to film the workstation's user. A camera with a zoom lens is not mandatory but is sometimes useful to scan documents. A different camera can be used to show documents when the first camera is fixed on the workstation. Currently, only one camera can be used at a time, and the selection is made using different video input ports of the framegrabber. PAL or NTSC camera is required using the SUN VideoPix board. A SECAM camera can also be used with the PARALLAX board. Note that a simple camcorder is sufficient for this purpose: for example, we have used a Panasonic wv-GL 350 (PAL).
Several framegrabbers can be used on a SPARCstation. Cheap boards exist, such as the VideoPix board, but performances obtained are limited to 6 frames per second (fps). The PARALLAX board is more expensive and grabbing performance is up to 20 fps. The new SunVideo board allowing 30 fps appeared at the end of 1993.
The SPARCstations can play back and record sound without additional hardware. SPARCstation audio driver characteristics are:
Machine Bits Max sampling rate Output channels
SPARC IPX/IPC U-LAW,8 8 kHz 1
SS 10 U-LAW, 8, 16 48 kHz 1 (stereo)
Microphone
A single microphone is sufficient. The microphone supplied by SUN can be used but its quality is mediocre. Examples for usable microphones are:
A headphone is recommended to avoid echo feedback. When several participants are listening to the conference at the same site, a loudspeaker is preferable. The loudspeaker included with the SS10 workstation is sufficient. An external loudspeaker is recommended when using IPC or IPX workstations.
A combined headphone-microphone is very effective, particularly where there may be other noise and disturbances nearby. Three examples are as follows:
Characteristics of the main software audio/video conferencing systems in frequent use in the Internet are listed in Appendix A.
The LBL Visual Audio Tool (VAT) is a well-established tool for conducting audio conferences over the Internet. For example, it has been used by more than 600 people to listen to the last IETF conference.
Internationally, inside Europe, the infrastructure usually works for a single conference using up to 384 kbps to the countries attempted so far. The links to the US work also. Because of the lack of Quality of Service control, there can be problems in the quality, and the MICE conferences can have impact on other traffic in the networks. Moreover, as traffic always seems to be rising monotonically, as soon as certain links become more loaded, they often become useless from then on for MICE purposes. Examples of these are the EBONE links between London and both Paris and Stockholm; these are both only 256 kbps links, and have been too saturated throughout MICE-I to be usable for MICE purposes. Only the capacity increases in these other networks have made them usable for MICE:
There is a particular problem in Europe due to the conflict between EBONE and Europanet. While the Swedes have ordered a 2 Mbps Europanet link, the French have not; other countries are not increasing their EBONE bandwidth. As a result, all traffic between France and the rest of Europe will have to use the EBONE-Europanet gateway; this is likely to become saturated unless this dispute is resolved soon. In any case, larger scale deployment of MICE technology in Europe depends on the deployment of a higher speed European fabric; we hope this will come from the Framework IV initiatives or in some other form.
The MBONE technology has been shown to work well between Europe and the US; this has been helped by three of the partners (France, Sweden and the UK) having good access to their National links to the US - which have been upgraded to 2 Mbps in each case during the life of MICE. At several stages of the project the US-European links have been so much more robust and lightly loaded, that it has been possible to get better service going twice through the US than adopting a direct European route. Clearly this approach may work - but it is politically unacceptable on both sides of the Atlantic. With current tariffs it is NOT obvious that the approach is uneconomic; a US-European link often costs only 10% more than its equivalent between most European countries (and in its higher bandwidth versions may be more available and even cheaper), so that economies of scale and usage may superficially make upgrade of specific US-European links more attractive than European ones.
The national access networks have given little trouble in most MICE countries. In Belgium the link is direct. In France, since the links to the EBONE node have been improved, there has been little problem. In Germany there have been difficulties in national distribution; they have been localised to problems with specific routers. In Scandinavia there were difficulties between Norway and Sweden on Nordunet until that bandwidth was increased. In the UK, traffic considerations led to a prohibition of the use of JANET for MICE purposes; when SuperJANET became available, there were no further difficulties.
Few of the MICE partners have used the ISDN; only GMD, NTR and UCL have done so. The network itself has been quite satisfactory for international and national access for these sites. The main problems have been the lack of adequate standardisation on the lower levels of protocol (those on the B-channels below transport), the lack of access to these levels in the workstations, and the lack of effort to reprogramme the CMMC primary rate router. This has resulted in the Tandberg videophone (and its badge-engineered equivalents in other countries) being the only device actually used effectively over the ISDN in MICE. This is now changing due to several factors:
We believe that the successful demonstrations at JENC indicate that the project has now more than satisfied the following milestones, as specified in the Technical Annex of the MICE Phase I Project [14]:
MICE demonstrated at the Internet Engineering Task Force (IETF), which was held at the RAI Conference Centre, Amsterdam, July 11-16 1993, which was very successful: the system was extremely stable and ran almost continuously during the entire week. Claudio Topolcic of CNRI is very interested in taking part in any future demonstration, and the President of the Internet Society, Vinton Cerf, professed himself to be "very impressed by the whole thing".
At Interop, Paris, October 27-29, 1993, MICE was invited by the German Telekom, to show MICE Multimedia Conferencing as an application using their DATEX-M service (a DQDB based SMDS service). For this they provided a special 2 Mbit link from Stuttgart to the Interop. As at the ETF, the main goals for the demonstration at the INTEROP were to show, in a four-way demonstration:
These will usually require fairly high quality audio and video. The conference rooms will be fairly costly, making it easier to justify the added cost of codecs and bandwidths of p x 64 kbps, with p of 4, 6, or even 24 (or 30 over SuperJanet, but not for MICE unless international bandwidth is unexpectedly increased by a large factor).
Access to conference rooms may be via Local Area Networks (LANs) to Wide Area Networks (WANs) or directly to WANS. The WANs may be either Packet-Switched Networks (PSN) or multiple channels of the Basic Rate Integrated Services Digital Network (ISDN). Conference rooms will receive/send data either directly via codecs from/to the audio-visual equipment, or use an intermediate computer.
These will usually provide lower quality of audio and video. Mostly they cannot justify full hardware codecs, and will do the codec function in software. Access may be over Packet-switched Nets (PSN) or single/multiple channels of ISDN.
We define a workstation to be of type 1 if it can code/decode at bandwidths of p x 64 kbps; where p will usually be of 1, 2, 4, or 6. We could go to a p of 24 or even 30 over SuperJanet, but not for MICE, unless international bandwidth is unexpectedly increased by a large factor. It is impractical with current workstations to attain the larger p's with software codecs.
We define a type 2 workstation to be complete units which have a low-cost hardware codec tailored to 1 x 64 kbps or 2 x 64 kbps.
The Conference Management and Multiplexing Centre (CMMC) has a number of functions including:
Finally there are also some SPARCstations with the German Diehl card at UCL, these support IP directly over LAPB.
The CMMC supports the following encodings over ISDN:
This is an SBus card which can be fitted to any Sun workstation. It requires some kernel modifications in order for it to work. It requires a Basic Rate ISDN interface, and uses only 1 x 64 Kbps channel. It can be setup to call different addresses on demand. The card takes IP packets and encapsulates them directly in the LAPB protocol. This means it is possible to connect to either the Primary Rate Interface at UCL, or another workstation with the Diehl card. The various connection possibilities are:
This would turn a workstation into an ISDN videophone. As a flavour on this method, just H.261 over LAPB could be implemented, talking to another workstation or an ISDN codec which supports H.261. (1.5) However, it is currently not possible to do this, since the Sun ISDN implementation is not complete enough, and is hard coded to use one channel, and the Diehl card has no documentation regarding this. Also, the processing power needed to achieve this is not known.
Both the Diehl card and the Sun implementation support IP over ISDN, thus it is very easy to send shared workspace data over ISDN. This might be desirable if e.g. the packet-switched network had a very low bandwidth or was busy etc. Thus, instead of multicasting the Shared Workspace data directly from the source site, it would be sent to UCL first, which would then multicast the data normally. It is not clear how easy this would be, or how useful. There would probably be a distinct lack of bandwidth available on a Basic Rate interface if audio and video were already being sent.
Extra:
GMD possess a BINTEC card.
The equipment needed to operate such a workstation is:
The information included in this document originate from our experience in running Multimedia Conferences within the MICE project using the specific facilities and tools. These conferences are run between the MICE partners as weekly project meetings and during 3 major project demonstrations at international conferences (JENC, IETF, INTEROP) and a number of smaller demos. A second source of information is a questionnaire which was sent out to all partners and others using the same set of tools. (see Appendix B)
This part includes information on hardware specific problems of setting up a Multimedia Conference at a Workstation
Not many Multimedia Conference specific problems were noticed. If one knows how to handle a video camera and how to connect it to the video boards in the workstation everything works fine. Just check that your image is in focus and that the lighting in your room is ok, which can easily be done by using a local control image from the videotool (IVS).
This is the most difficult part of a Multimedia Conference. Whereas sometimes a conference can be held without video or bad quality video, it's impossible to run a conference when audio quality is too bad.
Very often its the analog part of the audio transmission (microphones, wrong plugs, cables) which can cause a lot of problems. Even the position of a the standard workstation microphone can cause a very disturbing background noise (hum). We use a lot of different types of microphones and everyone sounds different using it with the audio tools. A sound check at the beginning of a conference is therefore essential to adjust the different audio levels.
Another important part is the loss of audio data during the transmission over the network. A typical loss rate where speech perception is getting impossible is 40% (30% when it's not your mother language).
First it has to be noted that running a multimedia conference has an influence on your working environment. Using the loudspeaker on the workstation or other speakerboxes can only be recommended when working alone in your office, otherwise audio will significantly disturb other people working there. Most of this can be avoided by using a headset. But using a headset cannot help to prevent other people being disturbed, when you are talking to other conference partners. It has to be noted that this disturbance is more than you get when participating in a phone call due to two facts:
MICE conference rooms are equipped with a workstation, a codec, Ethernet connection, and the UCL software needed to control the codec and to set up a connection to either the CMMC or another conference partner.
There is an explanation by Mark Handley on using the UCL software and how to configure a codec [15]. The codec compresses the video and feeds the resulting datastream via a high speed serial interface into the workstation for packetization or via an X.21 board and a terminal adapter into ISDN. Audio needs to be manually switched between the workstation's audio port for packet audio and the codec's audio port for audio over ISDN.
Configuring the codec is not a matter of the casual user; it needs expertise, but normally this should not cause problems because the codec stores the settings and should be in a usable state even after power cycling. After loading the device driver one must configure the driver for the desired baud rate (the manual points out a weakness: if the baud rate is not set here, before the next steps, then you will not succeed in setting device driver and codec to the same rate). To use the system one has to start the codec controller followed by the start-up of the user interface. Codec controller and user interface have to be synchronised with the baud rate selected to configure the driver.
Anyone running a multimedia conference from the conference room has to be familiar with both the codec and the network behaviour. In particular, one has to choose the baud rate according to one's quality requirements and the current network state; this has to be done before starting the conference. Any change of the rate means a restart. Starting the send direction is usually without problems, but the receiving direction often crashes and does not resynchronize automatically, so that it has to be restarted. The conference operator has to select the packet size and the TTL. He should permanently watch the codec user interface in case the codec has to be re-synchronized or sending or receiving have to be restarted.
There is no way to find out whether or not the remote partners are receiving the outgoing video except by some other form of communication. Also, when an expected incoming picture is missing, one is never sure whether or not the remote partner is actually sending.
Proper lighting and camera positioning and adjustment were points of concern. Another point that needs consideration, and is sometimes a cause of confusion, is the obvious asynchronous nature of audio and video data streams. Both audio and video feedback from the other participants are important human needs, which in general are tricky to meet in technical terms.
The audio side of the conference room needs much attention. Often it was felt that the volume of the loudspeaker was too low despite of the VAT control being all the way up; however, straightforward amplification would also amplify noise. There is currently a mismatch in level and impedance between mike and speaker ports of the studio, the audio ports of the Sun workstation, and the audio ports of the codec, which degrades audio quality. Further investigation is required to see if this can be overcome with a few adjustments or if more sophisticated conversion equipment is needed. Speaking into a mike without hearing the output on the other side (and thus not being able to self-adapt) makes some people feel uncomfortable.
Setting up and controlling the equipment in the conference room is currently not well organized. The situation has evolved partly from the transition from a single-network, single-partner video conference room to a multi-network multimedia conference room, and partly because user-friendly interfaces have been missing. For example there are several separate controls:
Then there is the fact that the workstation monitor is usually too small to show all the information and control windows without any overlapping and obscuring. Experience has shown that it would be useful to have two monitors: one for the shared workspace and one for conference control. To a casual user it is not obvious which button he has to press to accomplish a certain function. It would be a big help if there were a single user interface giving the user a consistent view, controlling the conference room equipment, hiding the peculiarities of the different networks, and controlling the shared workspace tools.
The current user interfaces to the codec and control software are developer interfaces, so to speak, and require a certain degree of expertise. On the one hand, much of this will eventually be superseded by remote control from the CMMC. On the other hand there will still remain a need for local control of the equipment, e.g. in case of point-to-point conferences not asking for CMMC services. GMD is trying to contribute to the development of a user interface that is more appropriate for the inexperienced user.
A videorecorder has been installed in the conference room, so there is now a possibility to record video and audio. One may record either the video received or the video transmitted, the received one being the more interesting one. Similarly with audio, but one can also mix both. A problem is that the microphones do not only pick up the local audio but also the remote audio from the loudspeakers. There are currently no provisions for recording the shared workspace.
Arranging a multimedia conference can well be accomplished via e-mail or a similar medium. Essentials are not only the times of start and finish, but also the exchange of multicast addresses, unicast addresses, ports, codec and other parameters, CMMC booking, as well as pre-tests or rehearsals and preparation arrangements (usually underestimated and causing embarrassing delays when not done beforehand with sufficient care).
Workstations exist at the sites of all the partners, and eight of the partners have participated in weekly conferences and the public demonstrations. Several US sites have been linked into multiway conferences with MICE partners in the public demonstrations. Conference Rooms now exist at four sites - they have been used in the public demonstrations and will be used more frequently in future events.
The CMMC functionality is still undergoing testing and further development. Currently, it works with distributed processors on one LAN rather than on a multi- processor system, but will be moved shortly. It supports both software and hardware codecs, does full quad-multiplexing in the analogue regime, and is accessible from SuperJanet, EUROPANET, EBONE, the Internet and the ISDN (via a primary channel so that several workstations can access it simultaneously). The performance of the CMMC still needs to be improved: delays up to several seconds can occur, and there is currently no attempt to synchronise audio and video streams.
Much of the code requires additional work to make it more efficient and fault-tolerant. User interfaces and documentation need to be provided to shrink-wrap it. Furthermore, many of the procedures involved in setting up and monitoring conferences could be made more efficient, easier to use, and automated. Whilst the Deliverables required under the Contract have been achieved, substantial additional effort is required to make the system more rugged and accessible to user groups outside the project.
First we consider the video component. Further work needs to be done on bandwidth back-off on transmission. If there is an indication (e.g. through a congestion control scheme) that the conference is requesting too much bandwidth due to the video, it should be possible to request that the video transmit at a lower frame-rate or some other measure of lower bandwidth. While this activity could be implemented in the CMMC, there should be mechanisms for control also at the workstation; this may be more efficient, and it reduces the transmission load before the video reaches the CMMC.
There needs to be some measure of video quality at reception; this is needed to ensure that the request for video transmission reduction does not cause the video to degrade below a specified acceptable level. Below acceptable levels, specific workstations might have to run without video, and periodic still picture updates could be sent instead. While the measure requires some software in the workstation, the actions would be exercised via the CMMC. At the opposite end of the spectrum, we need the capability to provide higher quality video. This is probably not tolerable on the present networks, but may be required in some applications and could be available shortly on some segments of the international networks.
There needs to be further work on the coding algorithms used. The present set works with H.261 video coding; the potential advantages of using MPEG, and possibly even relays between MPEG and H.261, should be explored. Other coding schemes can be expected to become available on workstations; again the possibility of relaying between such schemes should be investigated.
Next we consider audio. All of the current audio compression schemes are derived from the Telecom world. Other compression schemes may be more appropriate for use over packet-switched networks, by allowing for more graceful recovery from packet loss, either by frequency domain compression allowing interpolation over missing packets, or by increasing redundancy (distributing a sample between a number of packets) so that as loss increases, we simply get a lower sample rate.
A measure of audio quality at reception is required to ensure that there are appropriate mechanisms for realising that the audio quality at specific sites has become unacceptable. Either management levels should then manipulate the bandwidth provided, multicast or audio relay topology, or specific workstations should then be removed from the conference. It is important to liaise with ongoing research both by the MICE partners and in the US under ARPA auspices, on resource allocation which will allow parts of the networks used by MICE to give audio traffic preference over video traffic.
It is worth investing effort into improving the audio system, since our experience has shown that audio quality is the most crucial factor by which users judge the effectiveness of the overall conferencing system. Experience from the weekly project meetings has shown that impaired or variable audio quality is particularly a problem in international conferences, where not all participants are able to use their native language. For some applications, such as remote tutoring of foreign languages, prime audio quality is a prerequisite. Such applications will become easier to realise with the move of such services to higher-speed networks.
Efforts should, however, be made to improve audio quality over existing networks to support users who will not have access to higher-speed networks in the foreseeable future. Alternative coding schemes might be more suitable for use over packet-switched networks, and one should look at the possibility of adapting the audio compression ratio to variable network transmission capacities. Packet-level forward error correction may also enhance audio quality in case of packet loss.
It is important to conduct systematic testing of interworking between peripherals, workstations, software, and networks. This expertise needs to be accumulated and made available to user sites. It is likely that this activity would lead to a more radical look at the audio component: development and shrink-wrapping of a new audio tool would make a significant contribution to the usability of multimedia conferencing systems.
We now consider stream synchronisation: the combination of the audio and video. So far, there have been few attempts to synchronise the audio to the video. Synchronisation is important from a given level of video quality or delay upwards, and therefore becomes an issue with the move to higher-speed networks. Further research is required to determine how to achieve the best effect as far as users' perception of quality is concerned, and what to do if not all participants receive the same quality video. Previous work has shown that users' perception of quality of synchronisation streams for multimedia cannot be predicted from objective measures. Further questions arise of what to do if not all participants receive the same quality of video.
Any future developments may depend on the new transport level format and session controls, including CCCP, the Conference Control Channel Protocol developed at UCL by Mark Handley and Ian Wakeman [16]. The Audio-Visual Transport Working Group (AVT-WG) of the IETF is defining a new transport level format. MICE partners are, and will continue to be, contributing to this group. It is important that European activities reflect this work.
Also, the higher level multimedia management Working Group of the IETF is defining higher level session control and floor control mechanisms. Discussions with this group at the 37th IETF in Amsterdam revealed that the experience of the MICE partners with development and use of conferencing systems is a much-needed contribution, to ensure applicability of the eventual standard in practice. In this area, the emergence of the CCCP will be of great value if it is accepted. The full details can be found it [16].
The final component is a shared drawing tool. Versions of INRIA's MSCRAWL, Van Jacobson's WhiteBoard, and SICS' X-SPY and MultiDraw are all operational by the end of MICE-I. Even though all four are shared whiteboards or drawing tools, they offer complementary functionality rather than replicating it. The ability to transfer data between these, and possibly other shared drawing tools, is a requirement which has not been addressed in MICE-I. It would be desirable to define a common protocol for Shared Workspace applications to address this requirement. In addition, developments in AVT-WG and MMUSIC are likely to require additional facilities to be added to the Shared Workspace tools. Various of these Shared Workspace tools need to be shrink-wrapped; currently they are somewhat fragile. Finally, it is very important to broaden the base of hardware on which the MICE facilities run. It would also be very desirable to be able to accommodate some of the other multimedia systems which are becoming available.
This activity needs to embrace two quite different aspects: fault diagnosis and traffic measurements. The traffic measurements may be required for keeping the system operational; they may be used also to determine differences of behaviour in different applications.
There will be many things which need to be done in the CMMC. As we move to ATM networks, the multiplexing function itself will still remain vital with hardware codecs, but less so with software ones. Moreover, we may be able to distribute even this function. All the other functions will remain equally important, and in any case, even some of the multiplexing should be developed further. Thus the activities identified already are discussed below.
Thus this activity, which is a very big one, is similar to the whole of WP1, and in many cases will do things which are not necessary in the workstation itself.
Prior to the release of any MICE software, the releasing MICE partner would run a series of tests with the NSC to ensure that the software is stable and functions with the intended platforms and networks. Software must be accompanied by appropriate documentation. The releasing partner would act to fix any new problems reported by the users.
NSCs would install and use the software to make sure that the accompanying information is correct and sufficient. It would be up to NSCs to identify the user groups to whom MICE software should be released and who they will support. A general release should, however, be done in consultation with the NSCs and after testing by the NSCs' user groups. Users report any problems with MICE software to their NSC, and NSCs should be able to deal with most reported problems. They would act as the buffer between the Releasing Party and users.
NSCs should maintain National user databases of MICE software and to whom it has been released. They disseminate information on developments and changes to MICE software or documentation. In addition, they maintain information on hardware and connectivity of their National users, and make this information available to other MICE partners if required.
It would be desirable to introduce multimedia recording of seminars and important events. This would allow access to presentations given at times when people are not able to attend seminars, e.g. when it is held in another time zone at an inconvenient time. Experience with storing, indexing and retrieval of digital audio and video data will be a prerequisite for applications such as Distance Education. While such activity should be concentrated into the CMMC, some groups might wish also to introduce such a facility in their workstations.
Another facility which would be desirable is the ability to add minute taking and indexing into the archives. This should include portions of the shared whiteboards, for example. These facilities would also provide an ability to embrace more time zones in collaborations; partners not able to attend a particular meeting would be able to review its proceedings at a later time.
In the case of centrally controlled video use of the CAM would be a part of signing into the CMMC, and the CMMC could reject unauthorised users. In the case of VAT the authentication procedure would have to be done outside of VAT, for example in a dialogue between some software at the user side and the CAM. To authorised users, CAM would distribute a session key which would have to be used when starting VAT. There is no possibility for VAT to reject users.
It would be necessary to provide the normal infrastructure for key management in open systems. For this purpose there might be certification authorities and software in every workstation to communicate with a certification authority - it would be appropriate to consider the procedures adopted within the European PASSWORD project.
It would also be important to use the security infrastructure to provide access control (to limit partially the participants in a conference) and encryption (to ensure confidentiality even if there is unauthorised joining into a conference,
It would be desirable to have a user interface which integrates security functions and application functions (hiding most of the security details from the user).
Due to the project's broad scope, data can be collected under realistic scenarios of every day network usage, and not solely from, for example, an academic institution where most users are computer literate. Specifically, such scenarios reflect: a large number of end-users with a wide variety of technical expertise
Performance studies are important - including the effect of multiplexing various services from each workstation as well as from using dedicated workstations. For example, users could be asked to describe on a scale of 1 to 10 their satisfaction with a particular service and this could be related to the load generated by the various applications. The data collected during this project would be extremely helpful in judging the viability of multimedia services over future IBCs.
In addition to supporting specific applications identified by the MICE partners, we feel it important to identify key user communities. We are less clear, however, to what extent support for such communities should come from any extension project itself. Our present view is that we should commit to making our specifications for hard ware available to such communities, and to provide them with software releases. Most direct support or development should be contracted in some way by the various communities themselves. Communities which have been suggested so far are the following:
On the whole the workstation technology has become adequate for proper deployment. There is a part of the community which finds it difficult to consider any workstations other than PCs with Windows. This is less because of the relative costs of the equipment or its peripherals, than because of the in-house expertise and deployment of that base. It is essential for large scale deployment that one PC platform compatible with MICE be deployed; we are intending to pursue possible collaborations to achieve this aim.
While workstation manufacturers are continually improving the boards available in their PCs, there remains a niche market for high quality voice or video over lower cost networks which will continue to be met by the codec manufacturers for some years. There is always a long and unpredictable timescale before new standards emerge; thus we may expect to have to work with the current H.320 standards for some time. To attach such codecs to workstations require rather better serial interfaces from the workstation vendors - because of the rigid time constraints on the codec interfaces. While we may expect the present systems to become obsolete, this is no reason not to have wider deployment of the technology now.
Of particular importance is the need for a high performance infrastructure in transmission. With the present international networks, we do not believe that we are able to support much more than one mm conference at a time in Europe. Wide deployment really needs at least a 34 Mbps international infrastructure - which is being proposed in the EUROCAIRN proposal, and being considered in various Framework IV initiatives.
Before the higher bandwidth is available, it becomes particularly important to have access to a central reservation facility, which all projects using the international infrastructure can access. We are particularly concerned that there may be different projects attempting to use the European infrastructure at the same time; it is essential that there be a European-wide reservation facility which transcends individual projects and networks.
We need to continue to support a variety of communication subsystems - though these do not need to be located on CMMCs. It is probably desirable to have communications protocol distribution centres in several countries; these would act as relays between the local communications (ISDN, ATM and research networks) and the international infrastructure. The relays should also be able to mediate between different coding algorithms - both for the audio and the video. For the time being, there will continue to be a shortage of network bandwidth. For this reason, we need to install fairness algorithms at the critical routers, at the least those that give international access, to ensure that the MBONE traffic does not exceed a value agreed as supportable by the national funding bodies.
In Workstation providers, there are several needs. First, a number of the organisations which would like to use the MICE technology are constrained by other considerations to use PCs - and often Windows. There are some doing similar work in the European vendors (Teles, Bull and Siemens, for example); we should have further involvement with these vendors to ensure compatibility - and have started discussions with Teles already. Some other vendors e.g. NCR/ATT have agreements with PNOs to provide value added services (e.g. ATT and BT); we should investigate whether such offerings could become more compatible with MICE. Finally, we have already obtained some advantages from using advanced boards from the one vendor we already work closely with; it would be desirable to form closer links with others also.
The communications equipment vendors are producing higher performance codecs than the boards currently in workstations, but some of the interfaces are particularly unfriendly for interfacing to workstations. Inside the codecs, there are better interfaces; they are just not usually available to the customers. We should work more closely with vendor manufacturers to interface to codecs at levels more suitable to the networks we use. This type of supplier also provides the Multiplexing control units (MCUs). Here again we should work with them to provide MCU protocols more appropriate to the MICE architecture.
Service providers already offer many of the services we need. Under RACE auspices, additional value added services - booking, service engineering, network and applications management, are being developed. We should work with the service providers to either furnish MICE with some of their implementations, or discuss with them whether they might like to be involved with MICE not only to provide transmission services, but also possibly some of the Value Added Services. It is this area where it may be possible at least to get some more permanent national distribution in countries where this is still lacking.
The video codec is configurable over a large number of parameters resulting in data rates output from the coder ranging from 10-20 kbps up to 2 Mbps. In our application we generally use 400 to 800 kbps for video and audio.
The card is controlled from software, and most settings can be adjusted at any time (PAL or NTSC is set at start-up). The card can also display overlays, and it's possible to grab images directly from the board or put images onto the board (the display memory consist of one luminance bank (Y) and to colour-difference banks (CB, CR)).
The price is about ECU 6000 for the basic card with G.711 audio, and the optional motion estimation daughter board cost about ECU 2400.
To initiate an audio and video connection between the classrooms, one logs in on the machines with the Bitfield boards on a special account that starts the necessary processes. We also have an X11 application that is used to set different parameters on the Bitfield board while its running.
Coding algorithm: CCITT H.261
Video format: NTSC or PAL
Frame rate: NTSC 7.5, 10, 15, 30 frames/s
PAL 6.25, 8.33, 12.5, 25 frames/s
Resolution: CIF (352x288)
QCIF (176x144)
Data rate: 0 - 2048 kbps
Video inputs: 1. composite or Y/C
2. composite
Video output: composite, Y/C or RGB
Audio: G.711 (PCM), 64 or 56 kbps, 3.5 KHZ
7 KHZ optional daughter board
Address to Bitfield Oy:
Bitfield Oy
Tekniikantie 6
SF-02150 Espoo
Finland
Pho: +358-0-70018660
Fax: +358-0-4552240
Platforms:
Sun SPARCstation + VideoPix or Parallax framegrabber.
HP station + Raster Rops framegrabber.
Silicon Graphics station + Indigo framegrabber.
DEC station + VIDEOTX framegrabber
video: Parallax Videoboard,
Multimedia software:
audio: Sun speaker and microphone, Headset
Software: VAT, ivs, wb, nv
MICE equipment (GMD, Darmstadt) 26.1.94
Space:
Size about 4m/6m, 6 seats each equipped with a microphone, arranged on one side of an oval segment table, facing 4 television screens.
Video/audio:
6 microphones, 1 microphone is assigned to each participant
no speech technical coordination.
2 loudspeakers
4 television screens placed side by side. Used for sent and received pictures. One screen serves for checking and
adjusting pictures to be sent.
4 cameras: 2 person cameras each of which takes 3 persons,
1 camera for the white board and 1 for documents.
1 white board
Video/audio compression:
Workstation:
[2] M. Liou, "Overview of the px64 kbit/s video coding standard", Communication of the ACM, no 4, April 1991, pp. 60-63.
[3] "Description Reference Model 8", Specialists group on coding for visual
telephony, COST 211-bis, Paris, May 89.
[4] Sun Microsystems Computer Company: "LANs of the future"
[5] R. Haugen, B.Mannsåker; Scenarios for Introduction of Broadband Services in Telecommunication Networks, Norwegian Telecom Research.
[6] S. Casner, "Frequently Asked Questions (FAQ) on the Multicast Backbone", May 6, 1993
ftp://venera.isi.edu/mbone/faq.txt and see also http://www.research.att.com/mbone-faq.html
[7] S. Clayman and B. Hestnes (1994), ISDN report. MICE Deliverable ESPRIT 7602.
[8] H. Eriksson (1994), Shared Workspace. MICE Deliverable ESPRIT 7602
[9] M. Handley, T.Turletti, K. Bahr (1993): Detailed Specification of MICE CMMC, Conference Rooms and Workstations. MICE Deliverable ESPRIT 7602.
[10] M. Handley, A. Sasse & P. Kirstein (!993): The MICE demonstration at JENC, 10-14th May, 1993. MICE Deliverable ESPRIT 7602.
[11] M. Handley, A. Sasse, S. Clayman, A. Ghosh, P. Kirstein (1993): The MICE demonstration at the Internet Engineering Task Force (IETF), RAI Conference Centre, Amsterdam, July 11-16 1993. MICE Deliverable ESPRIT 7602.
[12] C.-D. Schulz (1993), The MICE Demonstration at Interop. MICE Deliverable ESPRIT 7602.
[13] M. Handley (1993), The MICE Phase I final demonstration on 14th December 1993. MICE Deliverable ESPRIT 7602.
[14] Technical Annex of the MICE Phase I Project.
[15] Mark J. Handley, (1993), "Using the UCL H261 Codec Controller" UCL CS Research Note
[16] Mark Handley and Ian Wakeman , (1993), "CCCP: Conference Control Channel Protocol - A Scalable base for building conference control applications."