jtap-023
of 53
Transcript of jtap-023
-
8/8/2019 jtap-023
1/53
JTAPJISC Technology Appl ications Programme
JISC Technology Applications
A Remote Advisory CaseStudy: The NEAT System
Mark Ratcliffe
Tim DaviesUniversity of Wales, Aberystwyth
Report: 023JISC Technology
Applications Programme
Joint I nformation SystemsCommittee
August 1998
-
8/8/2019 jtap-023
2/53
-
8/8/2019 jtap-023
3/53
A Remote Advisory CaseStudy: The NEAT System
Mark RatcliffeTim Davies
University of Wales, Aberystwyth
-
8/8/2019 jtap-023
4/53
The JISC Technology Applications Programme is an initiative of the Joint
Information Systems Committee of the Higher Education Funding Councils.
For more information contact:
Tom Franklin
JTAP Programme Manager
Computer Building
University of Manchester
Manchester
M13 9PL
email: [email protected]
URL: http://www.jtap.ac.uk/
-
8/8/2019 jtap-023
5/53
Abstract
The Computer Science Department at the University of Wales, Aberystwyth has developed, and is
operating, an on-line Remote Advisory Service where students are able to obtain personal assistance
anywhere across the distributed campus without leaving their workstation. This is now being trialed
by the Open Learning Unit at Aberystwyth prior to its introduction as a service to assist in the
teaching of their overseas students in locations as remote as Hong Kong.
The software is part of the NEAT (Networked Expertise, Advice and Tuition) project funded by the
JISC (Joint Information Services Committee). It has brought together expertise in the field of multi-
media applications (Department of Psychology, University of Glasgow), distance learning (Open
Learning Unit at Aberystwyth University) and service providers (Information Services, Aberystwyth
University).
The system provides a framework to support new and potentially far-reaching communication methodsfor both one-to-one and group working including mbone video conferencing technology. In addition to
providing users with a facility to seek assistance from an advisor it also extends the possibilities for
peer group learning, not only to local students but also those connected over the Internet. Group
working might be made available to those for whom costs of communication would have previously
made it prohibitive.
The two-year project began in 1996 and evaluation has been a central focus throughout. Many
different types of users in varying situations have used the software and all have provided feedback on
their experiences.
This case study describes the findings to date and examines the possibilities that this technology opens
up.
-
8/8/2019 jtap-023
6/53
2
-
8/8/2019 jtap-023
7/53
Contents:
1 Acknowledgements.......................................................................................................................... 2
2 Introduction to the Remote Advisory............................................................................................... 3
3 Background ...................................................................................................................................... 4
4 Requirements of the system ............................................................................................................. 55 Stages in the development of the Remote Advisory System............................................................ 6
5.1 Video and audio transmission................................................................................................... 6
5.2 Over the shoulder facilities ....................................................................................................... 6
5.3 Facilitating the connection between User and Advisor ............................................................ 7
5.4 Developing suitable user interfaces ......................................................................................... 7
6 NEAT 0: The original Aberystwyth Remote Advisory Service ...................................................... 9
7 The evaluation process................................................................................................................... 12
7.1 User interviews ....................................................................................................................... 12
7.2 The purpose of evaluation....................................................................................................... 13
7.3 Tour of campus sites ............................................................................................................... 13
7.4 Open Learning Unit ................................................................................................................ 13
7.5 Information Services............................................................................................................... 147.6 Language lab facilities ............................................................................................................ 15
7.7 A demonstration of NEAT 0.................................................................................................. 15
8 NEAT 1: The current implementation ........................................................................................... 17
9 Functionality of IP multicast.......................................................................................................... 19
9.1 Advantages of using IP multicast ........................................................................................... 19
9.2 Disadvantages of using IP multicast ....................................................................................... 20
9.3 IP multicast applications of interest to NEAT ........................................................................ 20
10 How NEAT is using IP multicast ............................................................................................... 23
10.1 Awareness............................................................................................................................... 23
10.2 Typical use of NEAT.............................................................................................................. 24
10.3 Monitoring usage .................................................................................................................... 25
10.4 Overcoming the limitations of IP multicast ............................................................................ 25
10.5 Ready for release .................................................................................................................... 27
11 NEAT 1: The evaluation ............................................................................................................ 28
11.1 NEAT 1: Its use in Information Services................................................................................ 28
11.2 NEAT 1: Its use in the Open Learning Unit ........................................................................... 29
11.3 NEAT 1: The results ............................................................................................................... 30
12 NEAT 2: The latest implementation........................................................................................... 32
13 NEAT: Dissemination and publicity .......................................................................................... 33
14 Conclusion.................................................................................................................................. 35
15 References .................................................................................................................................. 36
Appendix 2: Glasgow evaluation team -- interviews with students ...................................................... 37
1 Computer Science practical session ............................................................................................... 381.1 Students who had used NEAT ................................................................................................ 38
2 Help Desk Students........................................................................................................................ 42
3 Open Learning Unit students ......................................................................................................... 45
-
8/8/2019 jtap-023
8/53
1 Acknowledgements
This report tracks the development of a remote advisory service through various stages of design,
implementation and evaluation. NEAT (Networked Expertise, Advice and Tuition) is a JTAP funded
project (JISC Technology Applications Programme) supported by JISC (Joint Information Systems
Committee)
1
.
The collaborators on the project consist of the Department of Computer Science, Information Services
and the Open Learning Unit of the University of Wales, Aberystwyth, together with the Multi-Media
Group of the Department of Psychology from the University of Glasgow.
Much of the evaluation experience of the collaborators described in this report has been taken from
internal reports produced by the project.
The Aberystwyth development team consisted of Mark Ratcliffe (Project Manager), David Price
(Technical Development), Tim Paul Davies (Implementation Team Leader), Robert Wyn Jones and
Ivan Jensen.
The Glasgow Evaluation Team consisted of Jim Mullin, Anne-Marie Fleming, Lucy Smallwood and
Joyce McLeod.
The Information Services team consisted of Gill Price and John Chattaway.
The Open Learning team involved Clare Thomas, John Nelson and Steve Jones.
The Steering Committee was chaired by Professor Mike Tedd. The committee included Tom Franklin
(JTAP Project Director), Mike Hopkins (Head of Information Services) and John Martin (University
of Cardiff).
1 Funded by the Higher Education Councils of the United Kingdom, JISC is responsible for stimulating and
enabling the cost-effective exploitation of information systems and provides a high quality national networkinfrastructure for UK higher education and research councils.
2
-
8/8/2019 jtap-023
9/53
2 Introduction to the Remote Advisory
In 1995, the Computer Science Department at the University of Wales Aberystwyth began developing
and operating, an on-line Remote Advisory Service where students were able to obtain assistance
without leaving their workstation. Students were able to use two workstation rooms on different parts
of the campus to access an advisor anywhere in the Computer Science Department.
The Remote Advisory Service not only helped the department provide an efficient service to an ever-
increasing body of students, but also opened the possibility of providing expertise from outside the
department, perhaps from other universities or from experts in industry.
The system provided a framework to support new and potentially far reaching communication
methods for group working. It extended the possibility for peer group learning, not only to those
students within computer science, but also to those in other disciplines. Indeed it was thought that
using this technology, group working could be made available to those for whom costs of
communication would have previously made it prohibitive.
The Remote Advisory Service was an adaptation of freely available technology, originally developedfor multicast use (see Section 0), packaged together to provide an integrated facility which provides
full support of a one:many or many:many advisor to student ratio.
3
-
8/8/2019 jtap-023
10/53
3 Background
During the mid 1990s the Computer Science Department at the University of Wales Aberystwyth,
faced a sizeable increase in student numbers, leading to the opening of a second teaching laboratory
remote from the main department buildings. The laboratory is equipped with Sun Classic workstations
running Solaris 2.4, connected to a Sun Sparc 10 as a server. It is fully networked to the rest of thecampus and the JANET network.
The department emphasises the vocational aspects of computer science and offers a high practical
content within the syllabus of most modules. Although these practicals are supervised, the department
has traditionally provided an advisory service, staffed by postgraduate students, to provide assistance
to students outside the timetabled slots.
When the new teaching laboratory was opened to support the increasing student numbers, the cost of
providing a duplicate advisory was prohibitive. It was thus decided to develop a Remote Advisory
Service which would exploit the multimedia capabilities of the newly installed workstations.
4
-
8/8/2019 jtap-023
11/53
4 Requirements of the system
An initial study set out to investigate the requirements of a remote advisory system by first examining
the existing advisory system.
Typically, advisors are called in when a student has a problem in compiling a piece of code,difficulties understanding the operating system or has general problems which arise during a session at
a terminal.
A problem is usually tackled by the student verbally describing the situation that has arisen. To assist
in understanding what is required, the advisor usually examines the contents of the relevant window
(source code, error codes, run time windows, etc.). Once the advisor understands the problem, the
solution is most often described to the client through reference to the screen; placing the cursor to the
start of some erroneous code is a typical response.
It was thought essential that voice communication must be supported and that, to maintain the personal
nature of the session, a video-link, at least from advisor to student, should be provided. Facilities to
grab specific windows, look at complete screens and more importantly the ability to share a commonwindow in order to mimic the over the shoulder aspects, were thought to be vital requirements.
Whiteboard facilities are useful, but are not considered essential.
In addition to providing the desired facilities for a productive advisory session, it was also deemed
necessary for the system to have a mechanism which allows students to be queued whilst awaiting
attention from the advisor. Such an interface would need to give feedback as to the progress of each
request within the queuing mechanisms and, in the case that there is no advisor logged on at the time
of the request, a non-interactive support mechanism should be supplied. Such a mechanism would also
be available to handle less urgent requests for assistance.
5
-
8/8/2019 jtap-023
12/53
5 Stages in the development of the Remote Advisory System
Having established the requirements, the following components were identified as being necessary for
successful development: high quality bi-directional audio communication; uni-directional video
communication (from advisor to student); a robust and automatic calling and queuing mechanism; and,
a facility for remote access to the students display. It would also be necessary to design suitable userinterfaces for both students and advisors.
The communications for a remote advisory service are fundamentally unicast by nature, however,
given the desire to extend the basic facility to allow support for group working, it was decided to use
basic multicast tools; multicast can be narrowed to unicast, but not vice versa. The initial system was
therefore based on: Video Conferencing tool (vic)[1], Video Audio Tool (vat)[2] and WhiteBoard
(wb)[3]. All of these components are freely available in the public domain.
After initial considerations, four distinct areas were to be investigated further:
the effects of differing compression algorithms for video and audio transmission on networktraffic and quality of user service;
the extension of facilities like wb in order to provide over the shoulder interaction; an implementation of a calling and queuing mechanism;
the development of a user interface to fit in with other facilities provided by the department(TIPSE[4]).
5.1 Video and audio transmission
This study looked at the level of service necessary for both video and audio applications within such a
system and the resultant influence on bandwidth. Whilst the video might be considered a luxury, it
was felt to be essential in order to maintain at least some semblance of personal attention on behalf of
the student. Video traffic can use up large amounts of bandwidth; this work therefore needed to
investigate ways of providing suitable video quality whilst keeping bandwidth usage to a minimum.
The implementation of the system would need to consider the fact that it would run not only on thecampus network, but across the Internet in general.
Audio transmission is far more fundamental to the successful operation of such a system and whilst
utilising less bandwidth, break-up from high network traffic is much more apparent with audio than
with video. That is, audio is generally affected by, rather than affects, network loading.
The video aspect of the study concluded that it was adequate to use only a small frame and that given
that the transmission would, in normal service, be of the advisor sitting at his or her console, there
would be comparatively little change between frames. Of the techniques investigated, Cellbs video
encoding format provided the most suitable service.
The audio side of the study suggested that besides the actual algorithm used, factors such as type ofmicrophone used and ambient noise levels were significant factors in the quality of audio service
achieved.
5.2 Over the shoulder facilities
This study set out to investigate ways to allow the advisor and student to interact via the screen and
keyboard as if the advisor was at the students shoulder. Using wb as a starting point, the study
identified two desirable facilities which were developed for the Remote Advisory Service. These were:
-
a screen/window grabber to enable the advisor to "see" what problem the client is discussing;
a shared interactive workspace, with strict protocol procedures enabling the advisor to take charge
of whom has control of the workspace.
6
-
8/8/2019 jtap-023
13/53
The screen/window grabber was introduced as a facility under the advisors control to support screen
capture and display. It was a tailored implementation ofxwd[5] andxwud. This enabled an advisor to
see a copy of the students complete display, or just the view of a particular window (assuming that
the user agreed of course).
The interactive workspace was adapted fromxkibitz[6]. The advisor who then had control over the
command line inputs, and was active on the calling students filestore, initiated the call. By using a
status line in the main window, the student was made aware of who has control of command line
input.
By combining these two facilities, the advisor has the ability to see and demonstrate corrections to any
errors a student may be experiencing.
5.3 Facilitating the connection between User and Advisor
All of the above facilities came into operation once the communication had been established between
the advisor and the student. Prior to this, the main requirement was to provide a queuing mechanism
for users; this would provide general queuing functions together with facilities to support theadvisor(s) contacting users in the queue. Since the advisors and users are sited in differing locations,
then this software too would need to consider the remote requirements of the project.
Initial studies of the requirements of this supporting infrastructure identified the following points:
as students request assistance, they need to be given details as to how many other people are in thequeue and thus approximately how long they may have to wait before their inquiry is serviced.
Should there be no advisor on duty, or if the queue is large, then the student should be given the
option of e-mailing the advisor for future assistance;
though initially accepting to wait for service, a student may decide to leave the queue. If thisoccurs then the queue must be updated accordingly;
as the queues are modified, all users and advisors should be given an accurate picture of the stateof the service;
once an advisor becomes available, the system must inform the student waiting in the queue thatthe advisor is ready to service their request. Facilities must then be provided to make the
appropriate connection;
on completion of the advisory session, either side should be capable of terminating the advisorysystem;
the system must be user friendly; it needs to be implemented in such a manner as to hide systemdetails, for example through the use of default settings for such fields as the name of the machine
used to host the queue.
Having established the requirements, the next stage was to decide on a suitable architecture for
implementation. The need to cater for future enhancements suggested that the best starting point wouldbe to utilise Sun Microsystems Open Network Computing Remote Procedure Calls (RPC) [7].
5.4 Developing suitable user interfaces
The development of a user interface for a facility such as the Remote Advisory Service would have
been a major task in itself. However, in the initial release this task was simplified as the system was
expected to be an integrated tool within the TIPSE[4], a fully integrated environment providing
students with many of the software engineering tools used within the department. This project had
been running for many years and already had a user interface to which new tools were expected to
conform.
The TIPSE was written using Tcl/Tk[8], as were the front ends of the basic starting tools ofvic, vat
and wb, so it followed that the interface for the original remote advisory system would also be written
in Tcl/Tk.
7
-
8/8/2019 jtap-023
14/53
8
-
8/8/2019 jtap-023
15/53
6 NEAT 0: The original Aberystwyth Remote Advisory Service
The original implementation brought together the individual work areas to provide a comprehensive
system of remote advisory. This represented the starting point of the NEAT project. The software, now
referred to as NEAT 0, provided two distinct interfaces.
Figure 1. Students view of the Remote Advisory Service
The student interface required minimal input to facilitate its use. If there was no advisor in session, the
student was then prompted to either enter the mail tool or to exit. On entering the mail tool, the student
only had to type a message or cut/paste output, include a file or a mixture of all three. Addressing the
advisor was automatic; the student only needed to choose the send button, before exiting the system.
If the advisor was logged in, the basic Advisory window was displayed on the students screen (Figure
1). The student then selected the Add to Queue option by clicking the mouse button, and was placed
on the queue. Details of their position on the queue were displayed to them and updated automatically.
When the advisor was ready to take their call, the student was notified by a message on the display and
an unobtrusive audible message via the terminals speaker. Thereafter all audio communication was
via microphone and headphones, with all volume and transmission levels having been pre-set in a
start-up file. Termination of an advisory session was instigated by either the student or the advisor.
The interface to the advisor was rather more detailed (Figure 2) but still retained the same look and
feel.
The system was initialised when the first advisor logged in. Any unanswered mail was presented to the
advisor for response; new mail produced during the session was also directed to this advisor. On start-
up, the service queue was initialised; as students requested the assistance of an advisor, they were
added to the queue. In order to minimise the time that a student spent waiting for service, advisors
were continually informed of the number of students in the queue. Students were also informed of the
average queuing time before they added themselves to the queue. On accepting a call, the advisor was
provided with information such as who the student was and which workstation they were using.
The advisor could invoke any of the window grabbing facilities, shared workspace or whiteboardoptions from their main window. Options for control of input and display variables were made
available as appropriate within each of the tools.
9
-
8/8/2019 jtap-023
16/53
Figure 2. Advisors view of the Remote Advisory Service
The student set (transparently) the authorities necessary for the function of these tools when
connection was made with an advisor. They were then closed when the session was terminated by
either party or by failure of the queuing mechanism, for example in the case of the host machine
failing to respond for some reason.
Figure 3. A typical Sun screen showing the Remote Advisory Service
10
-
8/8/2019 jtap-023
17/53
Figure 3 shows a typical layout of a users workspace when working on a Sun workstation. It includes
a video image of the advisor, shown in the top left corner, the main window (as shown in Figure1), a
shared workspace and a whiteboard. It is clear that such a layout would be too intrusive on a typical
PC screen; the average PC does just not have enough real estate to permit such a large area to be
used by NEAT. Again this was another area to be addressed by NEAT.
11
-
8/8/2019 jtap-023
18/53
7 The evaluation process
NEAT has a very distinct difference from that of the original Remote Advisory; it is specifically not
tailored for Computer Science students. Whilst the original advisory was always intended to be
generally applicable, it was designed, built and assessed by Computer Science personnel. NEAT on
the other hand is aimed at a much more general user. We needed to find out these new requirements.
Evaluation is one of the most important aspects of the NEAT project and is led by the Multi-media
Communications Group at the Department of Psychology, Glasgow University. The main evaluation
collaborators are Information Services who provide computing facilities to all Aberystwyth campus
users and the Open Learning Unit who are the main centre for distance learning courses at
Aberystwyth.
One of the major steps in the evaluation of NEAT began when the Glasgow team visited the various
collaborators in Aberystwyth. This visit took place during the early part of the project and had been
preceeded by specific videoconferencing interviews to establish the context of use for NEAT in each
of the evaluation sites.
The most important aspects of this visit were:
to meet with users and potential users of the Remote Advisory Service;
to hold in depth User Interface feedback and discussion meetings face-to-face;
to promote teamwork between the NEAT project collaborators;
to look at the physical environment in which the NEAT system was to be used.
It was interesting to note that although many videoconferences between the collaborators had already
taken place over the previous few months, the visit seemed to be successful in introducing a more
cohesive and cooperative relationship between the collaborating sites.
7.1 User interviews
During the visit, the Glasgow team interviewed users and potential users from three different groups:
undergraduate students attending a Computer Science practical lab;
students who had just used the Help Desk;
students from the Open Learning Unit who worked at Aberystwyth and therefore could havefrequent access to the Open Learning Unit. They did not consider themselves to be typical of most
Open Learning Unit students. Nevertheless, the information they gave was of considerable
importance since their opinions and attitudes did reflect some distance learning related issues and
could affect the implementation of NEAT within this particular area of education where priorities
differ from that of full time education.
Unfortunately the Computer Science users were first years who were potentially less likely to have
used the remote advisory service (NEAT 0) than other years, and the other two user groups had not yethad a chance to use it. Most of the opinions were therefore from current non-users. The results of these
interviews are shown in Appendix 1.
12
-
8/8/2019 jtap-023
19/53
The main negative issues to come out of these interviews were that the remote advisory service was
not advertised enough, and that some students (in Computer Science) did not know how to open it,
what they were allowed to use it for, or when the advisors were available. On the positive side,
practically everyone interviewed was enthusiastic about potential uses of the tool, although some of
the computer science students did not often feel the need to ask for help, but this is most likely a trait
of computer science students rather than students in general. Even those who could not see a personal
use for the help aspects of the tool thought it would be useful for peer communication. Many thought
that training would be useful, even if it was only an informal introduction to the tool, which was
especially noted in the Open Learning student interviews. Generally, those who came to the help desk
were less computer literate than the Computer Science and Open Learning Unit students. The two
actual users interviewed were very positive about the service they had received so far.
7.2 The purpose of evaluation
For evaluation the aim was to bring every stakeholder into the equation and to ensure that, where
possible, they were considered at all parts of the design and development of the software. Any
reporting carried out would always look for positive as well as negative aspects, and should any parts
of the software be critically reviewed, constructive suggestions for solutions to the problem would beprovided.
During the evaluation, it was noted that the time scale was such that the evaluation of NEAT 1 would
occur after the final Design Spec for the NEAT 2 version was to be drawn up. This led to appropriate
changes being applied to the plan!
The different needs of the Open Learning Unit students compared with full-time on-campus students
were discussed in terms of type of usage of NEAT; the costs of installing NEAT for students not
receiving employer sponsorship; and line charges when using a modem. It was clear that the Open
Learning Unit have a very positive attitude towards the use of computer learning technologies and are
studying the issues involved in implementing NEAT for their students.
To keep students informed of NEAT, it was suggested that when students log on, information on
NEAT should automatically come up. Also, if the NEAT system goes down, users should be told this
on-line.
7.3 Tour of campus sites
The next step in the evaluation process involved visiting the various sites where NEAT was to be
installed.
Information Services were planning to install 40 machines across Aberystwyth. That represents 10%
of the total machines available to students. It was decided that rather than install NEAT on a small
number of machines in each workstation room, it would only be installed in specialised locations.These included:
the Thomas Parry Library, situated on the Llanbadarn campus, approximately 25 minutes walkfrom the main campus;
the Old College, again some 25 minutes walk from the main campus but situated near the centre oftown;
the School of Art, located between the Old College and the main campus;
various libraries on campus.
7.4 Open Learning Unit
The Open Learning Unit is a department located on the Llanbadarn Campus, which is approximately
25 minutes walk from the main Aberystwyth campus.It offers courses in: B.Sc. Econ.. Information and Library Studies
13
-
8/8/2019 jtap-023
20/53
M.Sc. Econ.. Management of Information and Library Services
M.Sc. Econ.. Schools and Young Peoples Librarianship
M.Sc. Econ.. Health Information Management
Undergraduate Certificate in Health Informatics
Currently, there are over 300 students at the Open Learning Unit, but with new courses, this couldincrease to between 500-600 over the next few years. Currently, Distance Learning students are not
only spread throughout the UK, but are also located across Europe and in Iceland and Canada. The
M.Sc. courses are also offered at study centres in Hong Kong.
The Open Learning Unit currently has 24/25 academic members of staff and 10 support staff who give
academic advice and pastoral counselling (respectively) to the students. Academic support is given
through an identifiable academic tutor and through the modular co-ordinator. Students can receive
pastoral support from a personal tutor.
As Distance Learning students are mainly in full-time employment, the course modules are written on
the basis of 15 hours of study per week. The three year course is made up of 23/24 modules (equal to
240 credits) and 4 examination components. Courses can last from 3-5 years.
Ideally, students require co-operation from their employers, however support varies as about a third of
the course are fully sponsored by their employers; a third are partially sponsored; and the remaining
third receive no support from their employers at all. Some students in the latter category do not inform
their employers that they are studying on the course because of the negative attitudes that employers
sometimes have towards employees who are endeavouring to improve their career position through
study. This means that not only are some students disadvantaged financially, but they may also be
disadvantaged in terms of the non-availability of study time during working hours or by difficulties in
study motivation in terms of career development.
All students on the B.Sc. Econ.. Information and Library Studies must have access to PCs and use
Microsoft Works. Since January 97, the latest B.Sc. Econ.. Information and Library Studies course
uses First Class computer conferencing software for extra support. Students are mainly female and
mature students; they would need some technical support.
Distance Learning students visit the Open Learning Unit three times in the course of their study, to
attend a Study School held at the beginning of each new term year. They may also visit the Open
Learning Unit at the beginning of their 3rd
Year for dissertation information. Study School also gives
them the opportunity of meeting with other students on the course and perhaps forming peer support
networks with telephone or email support. Distance Learning students can also set up regional
meetings - currently there are three groups in Scotland.
The Open Learning Unit can obviously make good use of NEAT. Exactly how the evaluation is to becarried out is described insection 0.
7.5 Information Services
Evaluation of NEAT by Information Services was to concentrate mainly on the help desk that serves
all staff and students at Aberystwyth. In time, NEAT might also be used within the library section of
Information Services. The help desk was located within the computing science building at the start of
the project but moved to the Hugh Owen building before the trials began.
The Information Services help desk provides help to anyone who has a problem, either by email or in
person. It covers a variety of different problems, the most common of which are:
loss of password;
HTML queries and finding certain web resources;
UNIX queries - can be setting privileges for web pages;
14
-
8/8/2019 jtap-023
21/53
unusual statistics queries - can be UNIX;
closing user accounts for administration staff (e.g. if a user has not paid fees).
After examining a number of sessions, the evaluators identified the following points:
a lot of the solutions were written down on postit notes and given to the customer to take away
with them; the checking account status is done on a character based terminal;
the problematic package is always opened to recreate the problem and demonstrate how to dealwith it;
sometimes the customer is asked to demonstrate how they would go about the problem task;
the advisor often points to the screen when discussing the subject (it would be useful in the remotesystem for the advisor to be able to point with the mouse and have a pointer show up on the users
machine.);
information is often sent to the customer by email.
All of these points fed into the requirements phases of NEAT 1.
7.6 Language lab facilities
In addition to the main collaborators, there is one further area that had potential attraction to the NEAT
project. The European Language Department has two language labs in operation, each with about
twenty machines. One is slightly older and has 386s, but is open 24 hours. The other room contains
very new PCs and runs Windows NT. This room is only open certain hours. At beginner level,
students would be expected to spend 1 hr per week in the labs, and later about 2 to 6 hours in the lab.
There are taught classes for most of the working day held in the labs. Students can access foreign
programs over satellite or cable. They currently have 100 Mbit connections, which allows them to see
films from the server. They will soon have a Video-on-Demand system so that students can watch
foreign films.
Potential uses of NEAT for the European Languages department were identified as: distance lecturing;
one:one communication;
link with penpals in foreign country;
broadcast locally between the machines in the lab;
group translation of passages using different colours to mark text.
For NEAT to be usable by the language students, sound quality must be good and preferably provide
lip synchronising of the video and audio.
Multimedia does not support all the functions of the language lab and teaching, but it can be useful for
people who are unwilling to talk during a one hour conversation class (the British can be quite shy,
and dont like to expose themselves in front of their peers). It will also be useful for people to log in
from home and get extra support and facilities. Students should come out of the course with the skills
of working together using the equipment, and the skills of using video technology.
7.7 A demonstration of NEAT 0
In order for the evaluation team to fully appreciate NEAT, a demonstration session was set up in the
Computer Science Advisory (advisor) and in the Solarium workstation room (users). Richard Huss (a
post-graduate student working on the advisory desk) gave advice to users that allowed the evaluators
to observe the Advisory system in situ. This was followed by a visit to the Solarium where 2 users of
NEAT were observed.
The following observations were made at the advisor station: the advisor logs on to the system and any email messages appear;
15
-
8/8/2019 jtap-023
22/53
clicked on Connect Next and as it was starting said This takes a long time;
whiteboard - fairly slow to come up and took a while to send data; when it did - no feedback;
Xterm - fairly slow to come up (Xkibitz comes up first); screening down - window goes fromblack to white to black - can be distracting;
status bar did not show any messages at first;
the video took a long time to appear after the status bar said Established audio and video. Whileit may be true that the connection was set up, this message is incorrect from the users perspective
until they can see the evidence of this;
the advisor moved the whiteboard window, and covered up the status bar;
imported text into Xterm OK;
screen dump - status bar message - OK, but took a long time before there was any feedback thatthe screen dump was happening;
clicking on the Xterm button to close it again looked unintuitive (similar to the way that SDRlooks at sessions);
advice was given using both audio and text;
noted that background conversations in the room which is shared with others, seemed to disturbthe advisor even though he was using headphones i.e. sometimes had difficulty in hearing user;
audio level higher so that audience could hear user through headphones;
while the advisor was serving the first user he did not notice that there was another user in thequeue. The information telling him that someone had joined the queue was not clear enough or
obvious enough. Because the advisor didnt disconnect the user immediately after finishing, the
other user was kept waiting longer than necessary, although this may have been due to the
presence of observers;
windows should come in the correct place so that people not confident with managing windowsare not forced into moving things (Experience shows that some people will leave a window hidden
and not use it, even if it is needed, rather than ask what they should do);
disconnecting the users takes away the tools so that the user does not have time to write down orsave the information the advisor has given you (this was commented on by the user). This equates
to someone on the help desk writing some information down on a postit note for you, and thenputting it in the bin and not letting you take it away. It also comes with no warning, as the user has
no control over the disconnection if the advisor decides to send him away. The user would not
know beforehand that the tools would all disappear on disconnection.
The following observations were made at the user station:
a first year student had logged on to the service, however there was a loss of audio at the user end,though not at the Advisors end. This could have been due to the need to adjust the sound level
through the Audio Manager. Possibly a more experienced user could have resolved this
problem. Troubleshooting this sort of problem where the audio would have to be tested would be
very difficult unless a user was very confident. As a result of the one-way loss of audio, both user
and Advisor used the whiteboard. The user did not know how to enter text on the whiteboard;
one of the NEAT team demonstrated the user end on another machine. The audio managersound level was adjusted. Initially, audio came through the speakers rather than the headphones
which seemed to disturb students at the nearby workstations who stopped working to look at the
user.
16
-
8/8/2019 jtap-023
23/53
8 NEAT 1: The current implementation
Having spent two years working on the original version of the Remote Advisory Service, we knew
that there were many areas for improvement, indeed some of these points have already been addressed
in this report. One of the changes thought most important by certain user groups was to maintain
attributes on the abilities/ experiences of advisors; in such cases it was felt that a student should beprovided with enough information about an advisor in order to select the one most appropriate. This
could have been achieved in the prototype by extending the queuing mechanism to support multiple
advisors (many queues each attributed with the advisors and their skills). However, such a system
hosted on a single machine would neither be robust enough nor extensible enough to be of general use.
Not only would the advisory fail if the host machine went down, but extending the service to a number
of different departments would lead to an unmanageable number of queues.
The infrastructure of the original Remote Advisory Service was just not extensible enough to be
practical for wider scale application. It also became clear that the collaborators working on NEAT had
requirements, which although not addressed by NEAT itself, were of such a similar nature that it
would have been foolhardy to have designed a system restricted to the original infrastructure. At the
very least, it was thought that the system should consider the following possibilities: Passive Advisor: a potential advisor might monitor the service and only become active if loads
on the existing active advisors reach an unacceptable level. This does not have to be restricted
solely to advisors on call; it might also, for example, be of particular use to managers of an
advisory service for monitoring usage.
Remote Tutoring: there is no reason why a session should be restricted to one:one. Indeed,students might have been discussing a problem with each other before one of them calls up the
Remote Advisor for assistance; all of these students might be interested in hearing what the
advisor has to say.
Group working: students might like to use the service for contacting members of their group inorder to hold a group meeting. The system might provide support by broadcasting information
about the group meeting. Other members might then elect to join in the remote session.
Two design requirements thus became apparent. Firstly, a single advisory session may contain more
than two individuals. This confirmed our original ideas that it would be best if the media used to
support the session (e.g. video, audio, whiteboard, etc.) were transmitted in a multicast manner.
Secondly, the individuals who might make use of NEAT need a mechanism to gain awareness of
which experts and students are around and whether or not they are free. Figure 4 depicts how such a
network might appear. It shows the various categories of user that might be available and the flow of
communications that might be set up to support them. The diagram shows how Active Advisor 1 has
been connected to Student 2. Group 1 has two students communicating, as does Group 2, and there is a
Passive Advisor monitoring the state of communications over the network. As yet, Active Advisor 2
and Student 1 remain unconnected.
17
-
8/8/2019 jtap-023
24/53
Group 1
Student 1
Group 2
Student 2
Student
1
Passive
Advisor
Group 2
Student 1
Student
2
Group 1Student 2
Active
Advisor
1
LAN/WAN
Flow of
Communications
Key:
Active
Advisor2
Figure 4. Users communicating over the network
In order to address these issues, a new approach was designed based on the group awareness work
undertaken by Ben Anderson [9] now at British Telecom.
The main idea behind this new approach is that packets of information are multicast around the
network using a Group Awareness Protocol (GAP). Packets transmitted from an advisor include
information on their skills, together with attributes such as the length of their queue (which may be
empty). An awareness tool operated by a student wishing to contact an advisor, listens out for advisor
packets in order to build up information on the skills that are currently available. Having chosen the
most promising of the available advisors (both in terms of skills and queue size), the students
awareness tool uses other information broadcast in the advisor packets, to set up a session with the
chosen advisor. This information includes details on the advisors hardware/software configuration as
well as information on the advisors location.
Exactly the same protocols can be used to support group working; in this case a student broadcasts
information equivalent to My name is Fred; I would like a group meeting. Other group members
might be listening in to the network and when the appropriate packets are received, they can set up
their conference. A similar scenario can be used to set up multi-way conversations between groups of
advisors and students. Of course such working arrangements might have a severe impact on network
traffic; this is an area that will be examined carefully during the evaluation of NEAT.
18
-
8/8/2019 jtap-023
25/53
9 Functionality of IP multicast
Having established the requirements of the NEAT system, and produced a design which would
support the necessary infrastructure, the next step was to examine how these ideas might be
implemented to provide the necessary communications. This led to an investigation into various data
communications protocols.
In designing a network-based application we had to decide which communications protocols to use.
TCP/IP (Transmission Control Protocol/ Internet Protocol), which we will go on to discuss, is the most
widely used set of protocols for computer communication. Hence, we decided to use this as it would
open NEAT up to as many users as possible. TCP/IP is a suite of protocols that interconnects the
various different systems and network types on the Internet and allows for communications across
these heterogeneous networks. Three protocols are most commonly used within the TCP/IP scheme:
IP, TCP and UDP (User Datagram Protocol). IP lies at the centre of the TCP/IP protocol suite and all
data on the Internet flows through IP packets. Higher level protocols, such as UDP and TCP are built
upon this. We became interested in IP multicast, an extension of UDP, because it easily allowed for
one-to-one, one-to-many and many-to-many group communications. While TCP is more widely used
in network applications, UDP, and hence IP multicast, is a lower-overhead alternative. UDP is oftencompared to a mail service where individual messages are sent (like letters or postcards), while TCP is
compared to the telephone service, where an actual connection is established between the two
communicating parties.
An investigation into UDP revealed that:
it is unreliable. UDP has no mechanisms for detecting errors or re-transmitting corrupted or lostdata. Moreover, packets may arrive out of sequence. TCP, on the other hand, detects and
retransmits corrupted or lost segments (the unit of TCP transmissions). Although TCP is more
reliable, there is an overhead associated with ensuring its reliability;
it is connection-less. With UDP there is no negotiation of a connection before transmission. TCPsets up a connection before transmission. This means that UDP is often faster;
it is message-orientated. Messages are packaged into individual datagrams (packets) while TCPallows for a seemingly continuous stream of data. UDP is therefore suitable if the information
sent can be seen logically as discrete messages.
While unicast involves sending packets from one host to another and broadcast entails sending a
packet to all hosts on a given subnet, multicast involves the transmission of IP datagram packets to a
host group. The fact that UDP is connection-less and message-orientated makes multicast possible. It
would be impossible with TCP because a connection would have to be established with each group
member. IP multicast involves:
sending a single copy of a message to the group as a whole, not one copy per receiver. Multiplecopies of the message are only created when the paths to group members diverge;
the group is defined as one or more hosts identified by a single IP address (known as IP class Daddresses in the range 224.0.0.0 to 239.255.255.255);
a multicast groups membership is dynamic. Hosts can join and leave at any time. Moreover, thereare no restrictions on the number or location of host group members and a host may be a member
of more than one group.
9.1 Advantages of using IP multicast
TCP is much more widely used than UDP by network applications, so what would be the advantages
of using multicast communications in an application like NEAT? We have identified the following as
important:
it easily allows for one-to-one, one-to-many and many-to-many communications which means that
we can support not only one-to-one advisory but also group working and remote lecturing. NEATis written in Java which allows for easy-to-use platform-independent and cross-platform multicast
communications;
19
-
8/8/2019 jtap-023
26/53
senders do not have to know who the receivers are. This means, for NEAT, that users of the system(both advisors and students) simply multicast their presence. Exactly who receives the information
is unimportant to the sender. Also, at the application level, receivers only have to join the multicast
group to receive and are not required to register or connect with some central server. This allows
for the decentralisation of networked-based applications. Our first prototype Remote Advisory
Service had one central queuing/ administration server through which all communications weremade [10]. The decentralised design allows for a more robust (as there is no reliance on any one
host) and dynamic system;
using multicast leads to reduced bandwidth usage when compared to TCP connection-orientated orbroadcasting modes of communication. As for TCP, a connection is not required with each
receiver, and for broadcasting, uninterested hosts are not sent messages. Moreover, an increase in
the number of receivers is not met by a commensurate increase in bandwidth use. Senders dont
have to send more packets when the number of receivers increases. This means that many more
users of a multicast-based network application could be supported at any one time for the same use
of bandwidth. An implication of this is that multicast is more suitable for bandwidth-intensive
applications, such as real-time video and audio, across the internet. These are the very capabilities
that NEAT requires;
communications can be geographically scoped. The Time To Live (TTL) on a multicast packetrefers to how many mrouter hops the packet can make. Mrouters decrement the TTL value and then
forward the packet until its TTL has reached 0 when the packet is discarded. This geographic
scoping could allow advisory session communications to be constrained to one site (a university
campus LAN for example).
9.2 Disadvantages of using IP multicast
Using IP multicast has its limitations and disadvantages. We have identified the following as
problems:
UDP is, by its very nature, unreliable; a sender cannot be sure whether a packet that was sent wasreceived at all, whether its data was corrupted or, whether packets were received out of order. UDP
places error detection and correction at the application level; address - port space. A multicast session is defined by a multicast address and port number
combination. Clashes of addresses and/ or ports do sometimes cause disruption to multicast
applications;
although most Ethernet LANs support multicast over the same physical network, many systems arenot configured to send and receive multicast traffic. To send multicast over WANs there must be a
system of multicast-enabled routers (mrouters) between remote sender(s) and receiver(s). This
system of mrouters is known as the Multicast BackbONE (MBone).
9.3 IP multicast applications of interest to NEAT
On balance, we felt the advantages of multicast outweighed its disadvantages, particularly as many of
its limitations presented solutions (discussed later). Moreover, there are also a number of public
domain multicast tools for collaborative working that we could make use of. Having established thatmulticast would be the best route to support NEAT, it soon became clear that the number of multicast-
enabled applications that are available is growing rapidly. A decision was made very early on in
NEAT that the project should not attempt to develop individual tools for collaborative work - it would
instead provide the infrastructure necessary to support the communication between users. NEAT has
been designed such that new tools can be plugged into this framework. This section looks at a number
of multicast tools and protocols that are available in the public domain and that have been considered
useful for NEAT, either as plug-ins or in the design of the infrastructure.
9.3.1 Applications
We investigated a number of IP multicast applications and high level protocols for their suitability insupporting the requirements of remote advisory.
20
-
8/8/2019 jtap-023
27/53
The following applications were considered important:
Video: The Video Conference tool (VIC) provides effective real-time video transmission andreception [1]. Advantages of using VIC were that its settings could be configured and its GUI could
be customised as its interface is fairly technical (see Figure 5). Versions of VIC run on UNIX,
Windows 95 and NT4 and are cross-platform compatible.
Figure 5. VIC 2.8 before (left) and after (right) customisation.
Audio: The Video Audio Tool (VAT), is a multicast audio transmitter/ receiver. VAT could also beconfigured and customised (see Figure 6). RAT, Robust Audio Tool, is another audio tool that
allows multiple users to talk over the MBone but is also more adaptive to network and host
conditions [11,13]. However, RAT cannot be easily customised and thus is of less use to NEAT
with its requirement for a simple user interface. Versions of VAT are also multi- and cross-platformcapable.
Figure 6. VAT 4.0 before (left) and after (right) customisation.
21
-
8/8/2019 jtap-023
28/53
Whiteboarding: Whiteboards are shared drawing spaces also used to export, view and annotatepostscript files. A number of whiteboards were investigated, namely: wb, mDesk and TeleDraw
[12,13 and 14].
Shared text editing: NTE is a shared text editor that allows multiple users to edit a single textdocument [15]. Each user may then save copies of the document. Most importantly, versions of
NTE run on UNIX, Windows 95 and Windows NT4 and between these platforms. Shared Applications: Many of the NEAT collaborators felt that some form of generic shared
application tool that allowed multiple users to view and participate in a particular application (word
processing, spreadsheet, database etc.) would provide important functionality to a remote advisory
service. No such tools currently exist that use multicast. For one-to-one advisory sessions, we have
investigated commercial software, in particular Symantecs pcANYWHERE which allows
advisors to view another users screen and to take control of their PC [16]. This is very useful for
the one-to-one advisory scenario. We have successfully plugged this tool into the PC version of
NEAT 1. Another area of our research is concerned with cross-platform application sharing.
9.3.2 Protocols
The following protocols were considered important in building the communications infrastructure to
support remote advisory: Conference creation, scheduling and announcement protocols such as the Session Description
protocol (SDP), Session Announcement Protocol (SAP) and Session Invitation Protocol (SIP)
[17,18 and 19]. The session directory tool (SDR) [20] was investigated as it provided much of the
video conference session description generation, announcement and invitation facilities that NEAT
could use. SDR advertises multicast conferences, and provides a listing of conferences being
advertised. SDR uses SDP to provide sufficient details for other users to elect whether to join a
given advertised session and to facilitate actually joining the session (i.e. to start the right tools
with the correct configurations). SAP is used to publicise session descriptions, usually by
multicasting SAP datagram packets on a well-known address and port. SIP is used to invite
individual hosts to a session on a one-to-one basis. It was considered important that NEAT should
use standard protocols for compatibility reasons as well as to avoid re-inventing the wheel if theycould help meet our requirements.
Group Awareness Protocol (GAP) [9]. Teleport, an awareness tool, allows other users of the tool tosee whos about and what they are doing [21]. GAP is used to multicast information about each
Teleport user to everyone else. From this, Teleport users can initiate conversations with others
using video and audio tools.
22
-
8/8/2019 jtap-023
29/53
10 How NEAT is using IP multicast
NEAT itself provides the infrastructure for remote advisory: the sending and receiving of awareness
information, the capability to call an advisor, a queuing mechanism associated with each advisor, the
creation and joining of sessions and the hiding of the technical details from the user. The first release
of NEAT 1 has the multicast tools VIC, VAT and NT plugged in but also uses pcANYWHERE toenable the advisor to view the students screen and to gain control over that students PC.
NEAT 1 has two classes of user: advisors and students. NEAT users all multicast awareness
information on a configurable address-port combination using the Group Awareness Protocol (GAP).
Advisory services offered by different departments may be provided on other address-port
combinations. For example, Computer Science advisory could be run on address/port
225.2.13.127/20000 while European Languages advisory could be run on 225.7.13.100/22002. This
has the advantage that users of each advisory service (both advisors and students) are unaware of the
existence of the other service and its users.
10.1 Awareness
The periodically multicasted awareness packets provide information on which users are available andwhat they are currently doing. To achieve this, each user sends out information on some, if not all, of
the following areas; some of this information is gained from the NEAT system itself, while the rest is
obtained from the user, either the first time they use the system or while the system is running:
personal details: this includes the users name, position (e.g. lecturer, student, manager etc.),department (e.g. Physics, Personnel etc.), institution (university or business name), subject (course
student is taking) and a students year;
contact details: e-mail address, phone number(s) and URL contact details;
attributes: areas of expertise/ skills for advisors; other attributes could include languages spoken,level of computer literacy (for students) etc.
state information: is the user/ advisor busy, how many people are waiting in an advisors queue,
which advisor has a student that has requested help (if any), what conferencing tools are currentlybeing run on which addresses/ ports and with what other parameters; and what session(s) are they
presently involved in;
host/ site details: this includes the users id, the operating system they are running (e.g. Windows95), the machines domain name and IP address, and the local time and other locale-specific
details;
capabilities: what bandwidth limitations the user faces (e.g. it could be 33.6 kbps for a modemuser), hardware available (i.e. do they have microphone, speakers and/ or a video camera), what
software plug-ins they have for NEAT (e.g. do they have NTE a shared text editor);
and, messages to the whole group: an advisor might want to tell everyone Im off for a coffee,back by 11.20.
By listening in to the awareness packets, every user of NEAT is able to build up a table of all otherNEAT users based on their latest awareness information. This technique provides up-to-date
information to each user on all of the above areas about every other user running NEAT. This table is
used for a number of purposes:
providing each user with awareness about what else is happening reduces the chances of confusionand more easily facilitates the development of new working practices when using the tool. This sort
of information is often lacking in other tools;
it gives students all the information they need to select an advisor most suited to discussing theirproblem;
it provides advisors with detailed information on students seeking their advice. This enablesadvisors to be better prepared to solve users problems;
it is used by the NEAT system itself for error detection, correction and recovery based on the statesof other users;
23
-
8/8/2019 jtap-023
30/53
it enables the NEAT system to create session descriptions based not only on the requirements of theproblem but also on the specifics of each users hardware, software and bandwidth capabilities and
each users personal requirements, preferences or needs;
it contains information on all sessions that are currently running and can therefore be used to enableother students or advisors to request to join a session or be invited into a session already running.
This allows for the dynamic membership of sessions that are more than simply one-to-one.E.g. ifan advisor is in session with a student and they cant solve their problem or answer their request,
they could invite another advisor in to the conversation to help;
this information is used by the Reflector/ Gateway, when non-multicast-enabled hosts are involvedin the advisory service. In this way it is known which media streams need to be turned to and from
multicast and to and from which users IP addresses.
10.2 Typical use of NEAT
Typically, the system will be used as follows: a student experiences a problem or wishes to make a
query while seated at his/ her PC. The student launches the NEAT remote advisory system which then
starts periodically sending awareness information out about the student as well as receiving
information about everyone else (using GAP). In this way it is able to build up a table. Each entry in
the table contains the latest awareness information from each user running NEAT on the samemulticast address and port combination. The student can then select an advisor and, if required, obtain
more information on him/ her.
Figure 7. Students screen while connected showing NEAT (top right), the video image of the advisor
(VIC) and the audio controls (VAT). In this example the student is also working on a document using
Word.
24
-
8/8/2019 jtap-023
31/53
Once a suitable advisor is selected, a message is sent to the advisor and the student is then placed on
their queue. When the advisor is ready to communicate, the advisors NEAT software generates a
session description (using SDP) containing information on which tools to start and with what
parameters. This is sent to the student using the Session Invitation Protocol (SIP) and is then used by
the students NEAT system to join the session and launch the tools specified by the advisor. The
student and advisor are now in communication (see Figs. 7,8). The advisor may invoke the most
appropriate tools based on the nature of the students request. When the advisor has resolved the
students query, the connection is closed and the advisor can go on to deal with the next student in
their queue.
Figure 8. Advisors screen while connected showing NEAT (top right), video controls (VIC), audio
controls (VAT) and pcANYWHERE (left) now controlling the students screen.
10.3 Monitoring usage
Our use of multicast communications and GAP makes it fairly straightforward to develop a monitorfor the system. Such an application simply has to listen on the same multicast group address and port
combination that GAP packets are being sent out on and then build up a detailed log of the systems
usage.
10.4 Overcoming the limitations of IP multicast
There are three main limitations in using IP multicast: communicating with non-multicast-enabled
hosts; unreliability; and group address/ port generation. We have considered the first to be the most
serious concern for NEAT as solving it opens up the system to many more people who for various
reasons (including recent trends toward switched ethernets) are not using multicast. However, we have
also considered the other two, less critical, concerns.
25
-
8/8/2019 jtap-023
32/53
10.4.1 Communicating with non-multicast-enabled hosts
Because not all potential users of NEAT can send and receive multicast, we have built a Gateway/
Reflector (see Figure 9) to convert multicast traffic into unicast and vice-versa (both awareness traffic
and the media traffic such as video and audio). Using the reflector means that non-multicast-enabled
hosts can effectively join multicast groups. Unicast traffic from non-multicast-enabled hosts is
forwarded to other non-multicast-enabled hosts and multicasted. Multicast traffic is turned into unicastand forwarded to each non-multicast-enabled host.
To the users of NEAT these implementation details are hidden. Instead of multicasting their awareness
packets, non-enabled hosts send them using unicast UDP directly to the Reflector/ Gateway. Whether
the user is able to use multicast or not does not affect the functionality of the system itself, these
details are hidden from the user. The Gateway/ Reflector knows whats going on by looking at
awareness packets and builds up a table similar to that of the users of NEAT. From this it can tell what
unicast traffic to multicast and forward and what multicast traffic to forward. This means that non-
multicast-enabled hosts can dynamically join and leave multicast groups as if they were on the
MBone. Obviously this doesnt come with the other advantages of being on the MBone, most
importantly it is not bandwidth efficient. In summary, the Gateway/ Reflector allows for group
communications among any combination of enabled and non-multicast-enabled hosts (includingentirely amongst non-enabled hosts) and gives access to NEAT to sites that would be otherwise off-
limits.
Figure 9. The Reflector/ Gateway converts multicast traffic to unicast and visa versa
10.4.2 Unreliability
While multicast is unreliable in the sense that packets can get lost, can arrive out of sequence or
become corrupted, these factors are not critical to the NEAT infrastructure itself, which is able to
recover from these sorts of errors. It does become more important, however, for the tools that NEAT
uses. We are currently investigating the Reliable Multicast Protocol (RMP) that provides mechanisms
for acknowledgement, resending of lost packets, ordering and repair/ request policies. RMP involves
building reliable mechanisms on top of IP multicast. A RMP could well open the door to a wider
variety of multicast applications that require a high level of reliability; this could include shared
application or remote control-like applications (similar to pcANYWHERE) that currently use TCP.
26
-
8/8/2019 jtap-023
33/53
10.4.3 Multicast address-port conflicts
Finally, multicast address/ port conflicts are another area of unreliability with regards to multicast
applications. It is virtually impossible to guarantee that a tool can generate a unique address/ port for a
session. This is because there are no ways of reserving addresses, and address generation is
decentralised (i.e. addresses are generated by individual applications such as SDR, or NEAT and are
not requested from some form of central server). When tools are launched on the same address, errorscan occur or confusion can arise. We have investigated a number of ways of reducing the chance of
address/ port clashes. These could be used in isolation or combination:
before generating a session description, the NEAT system could examine the table of latestawareness information from each user and see what addresses/ ports are in use. It can then know
not to use any of these addresses. This virtually eliminates chances of a clash with anyone else on
the same NEAT advisory service;
NEAT could listen for a session announcement from tools like SDR that generates multicastannouncements using SAP on a well-known port and address. It could then avoid using any
addresses in each announcements session description. However, there is no guarantee that people
will announce sessions before using multicast tools;
NEAT could listen on an address for a while and after a predefined period clear of any traffic, deem
the address to be unused and make use of it. However, how long should one wait before thinking itunused? There is still no guarantee that someone else will start using it later or that the address was
in use but at the time of listening there was no traffic.
Although the chances of a clash are minimal, the results could prove disastrous to an advisory session,
so while attempts at minimising the risk are costly in terms of effort, they are useful.
10.5 Ready for release
NEAT 1 produced an efficient information-rich system that provided an open and dynamic interaction
framework using MBone technology. Having implemented and fully tested the system, the next stage
was to determine user reaction.
27
-
8/8/2019 jtap-023
34/53
11 NEAT 1: The evaluation
NEAT 1 was released to the project on schedule in mid-July 1997. As each installation was slightly
different due to collaborator requirements and site specifics, the first installation carried out was for
Information Services at Aberystwyth.
11.1 NEAT 1: Its use in Information Services
Information Services began installation of NEAT during the summer of 1997 on to approximately 40
different machines distributed across campus. Prior to the installation it was announced that the whole
campus was being upgraded from Windows 95 to Windows NT. This was a fortunate development
for NEAT since testing of the system had shown that NT was a much more reliable platform than
Windows 95. Testing had consistently shown that the NEAT software, though written for 95, was
running much better on NT.
A few months earlier, Information Services had requested that the NEAT development team add
functionality to the toolset to better meet the needs of their users. Unfortunately although the decision
to concentrate on the infrastructure still looked as though it had been the correct thing to do, by the
summer of 1997 the tools had not progressed as much as expected (though this was to change radicallyby late 1997). A decision was therefore made to incorporate pcANYWHERE into the toolset.
pcANYWHERE is a commercial product that enables an advisor to fully interact with a users PC and
this includes any applications that might be running on the users machine. It costs 17 per user
machine and was purchased by Information Services for all of their trial machines. Minor
modifications were made to NEAT to support this software.
To install NEAT, each machine was upgraded with a sound card (not installed as standard at
Aberystwyth) and a pcANYWHERE licence. The sound cards were to create all sorts of problems for
the project. Early requirement analysis, undertaken by the project as a whole, had shown a need for
full duplex communications. Most sound cards available provided the necessary hardware and many
drivers were now supporting full duplex. Although tests undertaken by the development team had
found a number of satisfactory cards, there were serious problems with common cards such as the
Soundblaster (though later releases of the drivers were to address this problem). As far as Information
Services were concerned, as they were installing new sound cards, the need to install specific sound
cards presented no difficulty.
The development team produced a full installation tool (for NT and 95) based on the Freeman
Installer. It was intended that this tool would provide an automated installer for use by a nave user.
The installation within Information Services proved very successful though they were hampered by
technical problems caused by the cross-campus upgrade to Windows NT.
A workshop on how to use NEAT (from an advisors perspective) was held in early September. It was
directed specifically at the needs of Information Services. Approximately 10 people attended all ofwho were potential advisors within Information Services.
Information Services have provided full NEAT service in the form of Help Desk Live 9 to 5 since
October 1997. Numerous advertising campaigns to promote the service have been undertaken and
although successful, usage has not been as high as expected.
Further discussion on this issue follows in section 0.
28
-
8/8/2019 jtap-023
35/53
Evaluation team at Glasgow
Once the installation had been completed by Information Services at Aberystwyth, work began in
installing NEAT at Glasgow. This work was undertaken by Lucy Smallwood and Joyce McLeod of
the Multimedia Communications Group. The intention was to run through the whole installation
without over-the-shoulder assistance from Aberystwyth. This would enable the evaluation team to
ascertain how easy other users would find the installation process.
Unfortunately the installation did not go well. The biggest problem was that it was to be installed on
Windows95, which the development team knew was more troublesome. Reports from Glasgow
interpreted by the development team, suggested that the sound card drivers were causing the problem.
This turned out to be the case, though there were further problems caused by incompatibility of the
camera drivers.
This delay was disappointing to the project, not least because of the wasted effort by Glasgow, but an
idea of using the Faculty of Art at Glasgow as a trial site also fell through. This was an NT site and
likely to have generated many useful users. The problems that Glasgow had with installing NEAT on
95 was probably detrimental but the requirement for full duplex sound cards provided a major
stumbling block.
Further discussion on this issue follows in section 0.
11.2 NEAT 1: Its use in the Open Learning Unit
Even before the release of NEAT 1, the Open Learning Unit had undertaken an investigation to
establish how the concept of a remote advisory service could be used to support distance learning.
This involved two different threads. On the one hand, experiments were undertaken with modems to
evaluate the performance of NEAT to establish the working limits of the tools. These experiments
involved detailed analysis of bandwidth required by NEAT and its toolset. The results of these
experiments are discussed in section 0. While these experiments were underway, a study by the
Glasgow evaluation team was carried out to interview potential students.
The results of the studies were used to formulate the way in which the Open Learning Unit might use
NEAT. Although the exact format has yet to be finalised, discussions, both internally and with the
Glasgow evaluation team, have led to the following scenarios being considered:
Pastoral tutorials;
Pre-assignment advice;
Essay and assignment feedback;
Dissertation discussions;
Group support sessions.
The experimental trials of NEAT are scheduled to take place between February and the end of the
academic year. It is likely that each student will be offered up to four NEAT sessions during thisperiod. Each session will have to be pre-arranged for a suitably convenient time, and will last for a
probable maximum of 30 minutes. After each session, both the staff and students will fill out a
questionnaire.
The Open Learning Unit is currently contacting their students inviting them to participate in the trials.
They have been given a full specification of the hardware that NEAT requires and are offered all of
the software required for the trials. The Open Learning Unit have also offered to reimburse the cost of
the phone calls made during the trials.
The results of these trials will be published during the summer of 1998.
29
-
8/8/2019 jtap-023
36/53
11.3 NEAT 1: The results
NEAT 1 was a great success; it provided all the functionality that was expected of it and was in use in
a variety of different locations. A large number of presentations were given both on a national and
international forum; the responses were very positive. Unfortunately our experiences with its
application were not so encouraging.
By early December 1997, there had been a number of setbacks, in particular:
the progress report from Glasgow was very negative; they had still not installed NEAT 1 correctlydespite positive experience elsewhere in the project;
the tests with modems using the traditional multicast tools had been discouraging;
Information Services were receiving only a couple of enquiries per day on the NEAT 1 system;
Within Computer Science, the Remote Advisory System (NEAT 0) was hardly being used.
11.3.1 Technical issues
Glasgow is a Windows95 site. This in itself should not have been a problem; a number of trials at
sites remote from Aberystwyth were also on 95 machines and all these tests had been successful. The
sound cards were a definite problem area; we were convinced that the drivers for the sound cards were
still causing problems, particularly when used by vat. It soon became apparent that in all cases, it was
the tools, not the NEAT infrastructure, which was providing the difficulties.
What we needed was a different approach to the tools; vic and vat were causing problems with the
sound cards, pcANYWHERE was causing problems with licensing costs. Fortunately a solution was at
hand; recent investigations into Microsoft NetMeeting (available free to anyone with a Microsoft O/S),
looked very promising. By late December 1997, as a result of work undertaken as a final year project
in Aberystwyth, the development team had ascertained that NetMeeting:
* could be configured so that it would work with NEAT; it could be customised to be initiatedfrom the command line, hiding all details from the user. The user interface could be configured to
be very similar to NEAT 1;
* could replace vic/ vat and pcANYWHERE; tests indicated that vic and vat were not as efficientas commercially developed software. NetMeeting provides all the required functionality of
pcANYWHERE without the additional cost;
* provides better 1:1 audio and video quality;* reduces the sound card problem; the tests carried out with NetMeeting were much more
successful than with other software with which we had experience.
Initial tests demonstrated that NetMeeting would reduce restrictions and increase functionality. After
further experimenting, it was decided that NetMeeting would be customised and plugged into NEAT
as a replacement for vic, vat and pcANYWHERE. The UNIX version would retain vic and vat until a
port of NetMeeting was available for UNIX platforms.
When the move to NetMeeting was first considered, the Glasgow evaluation team expressed concernthat such fundamental changes to the software would affect their evaluation process. They thought that
this would involve lots more work, and the lessons from the previous version could not be carried
forward. In adopting NetMeeting it was decided that although the tools might change, the functionality
must remain the same. There would be no great difference from the users point of view. The NEAT
interface itself would not be significantly changed.
Most important to the project was the fact that NetMeeting had proved successful over modem
connections, with 2-way video and full-duplex audio being achieved over a 33.6kbps modem. This
change meant that full trials would at last be possible for the Open Learning Unit, which until now had
been dogged by bandwidth problems.
30
-
8/8/2019 jtap-023
37/53
11.3.2 Usage
Investigations by the collaborators indicated that the poor usage of NEAT1 was due to the set up
within Information Services and the Department of Computer Science. The Glasgow Evaluation team
had already identified such problems when evaluating NEAT1.
Information Services have NEAT installed on some 40 machines, however this is less than 10% of thetotal. One has to bear in mind that each installation required a sound card (18) and a pcANYWHERE
license (17). In this respect, achieving a total of 40 installations was very encouraging. However, as
there is such a high demand for all machines within Information Services it was not practical to
reserve machines for NEAT usage. In any case, NEAT was not intended to be used in this way. The
student should be able to use NEAT to gain access to an advisor at any point during a session. Without
the student even having to leave the workstation, an advisor should be able to capture the screen or
interact with the application to solve the problem. NEAT was not intended for use as a dedicated
machine to be used only when a problem arises.
This problem cannot be solved overnight but by replacing pcANYWHERE with NetMeeting, the
installation costs of NEAT are reduced quite considerably. Even more promising is that the
management of Information Services has recognised the real potential that NEAT has to offer. It istherefore very likely that Information Services will increase the availability of NEAT quite
dramatically.
Within Computer Science the usage of NEAT 0 by undergraduate students was thought to be low
mainly because of the close proximity of the workstations to the advisors. To visit the advisors in
person involves a walk of less than 50m which has meant that students can just as easily seek the
advisor in person as use NEAT.
31
-
8/8/2019 jtap-023
3
