GAT: ACTS Telework Chain
Guideline GAT-G5
Telework: Implementation of Telework for Multi-site Software Development
This Guideline was drafted and is edited by TECODIS
with contributions by ACTS Telework Chain (GAT) participants and other
interested parties, and has been endorsed by the GAT Chain at the European
Telework Congress in Stockholm on 24th September 1997 and by participants
in the ACTS Concertation meeting in Brussels on 30th September 1997.
The Guideline is still open for comments, which should please be made
by email to etd-gat-g5@eto.org.uk;
earlier comments can be seen on the www at http://www.eto.org.uk/gat/guides/g5-mail
and your comments will be added there.
The current version is online at http://www.eto.org.uk/gat/guides/gat-g5.htm.
A general note on terminology explaining
the GAT Chain use of the word "teleworking" is provided at the end of this
Provisional Guideline, along with a brief description of the
GAT Chain's approach to the development of Guidelines.
Contents List
Executive Summary: Implementation of Telework for Multi-site Software Development
This Guideline provides some advice on how to implement telework for multi-site
software development. All other possible areas of application should
extrapolate the results taken from TECODIS project making the necessary
adaptations.
It will concentrate mainly on technical aspects related with network
and terminals, giving recommendations in the following areas:
Return to contents list
Guideline Objectives and Intended Audiences
The main objective of this Provisional Guideline is:
-
To describe the different solutions available for multi-site software development,
either in a multi-site corporation or in multiple distributed companies
collaborating in a same development effort.
It is intended to the following audiences:
-
Actors in the industrial area, ranging from technical support elements
to project managers, designers and testers.
-
Fora, expert groups and standardisation groups with activities in area,
either in development or application areas.
Return to contents list
Discussion and Recommendations
When setting up an environment intended to support telework, there are
many aspects that have to be taken under consideration. These span from
network and terminal aspects to social, economic and cultural implications
which, in turn, depend on the environment where teleworking will be set.
This Guideline will concentrate mainly in the technical area, explaining
TECODIS experiences and conclusions when supporting Telework for multi-site
software development inside one organisation spread in Europe.
The following sub-chapters will explained this in more detail.
Return to contents list
Available solutions
For the type of synchronous interactions, needed for software development,
there are different available CSCW tools in the market (asynchronous interactions,
like e-mail interchange, shared databases, etc., are normally in place).
These could be grouped in the following sections:
Video Conference Rooms
Normally H.320 terminals, with big screens, different cameras (one document
camera) and audio equipment.
The network solution is normally ISDN.
They are normally used for management meetings, using audio and video
streams only, although some application sharing facilities can be found.
They only cover some of the main scenarios needed for software development.
The H.320 systems require a dedicated device (MCU, Multipoint Control
Unit) for multipoint connections.
Desktop Video Conferencing
There are a considerable number of H.320 compliant applications, normally
based on a PC platform, that provide videoconferencing on the desktop.
Till recently the generally adopted network solution was again ISDN.
Some vendors are actually starting to make available the same services
over LAN.
The level of interaction that can be reached with these solutions is
higher compared with the one achieved with video conference rooms, but
they also need and MCU for multipoint conferences.
IP based solutions
These are the most flexible solutions, because they are independent from
the infrastructure network. Both types of scenarios (desktop and meeting
rooms) can be covered, and the same WAN access can be used, over a common
LAN to connect a group of terminals.
IP based solutions are scalable, in terms of bandwidth usage, and flexible,
being possible to have, in one same conference, different parties on different
WAN technologies (ISDN, ATM, leased lines, xDSL).
These are the ones with an easier migration path towards H.323, the
new ITU standard for video conferencing on non QoS guaranteed LANs.
Recommendation
To use IP based solutions due to their flexibility (number
of users, LAN or WAN infrastructure...), scalability (depending
on the available bandwidth in the WAN mainly) and possibility of migration
towards H.323 (the infrastructure equipment and network). Make sure
that the chosen application is really capable to adapt to different bandwidth
scenarios.
Return to contents list
Network Set-up Procedures
The following are the reasonable steps to follow when introducing
such a telework solution:
-
Define the network topology (taking into account multicast usage)
-
Define the infrastructure network in each segment (ISDN, ATM, xDSL,...)
based on usage prospects
-
Allocate all needed resources (routers, switches, communication lines)
-
Assign IP addresses and configure the IP network
-
Test connectivity among all nodes
-
Test the application, in different usage scenarios, among different combinations
of sites
Return to contents list
Application requirements
Actors in the industrial process use several tools to perform their tasks
and communicate with others. The Teleworking Platform need to substitute
the traditional actions, like travelling to meet other persons, incorporating
tools that will emulate, as far as possible, the environment needed to
perform such actions. This way of working must present advantages when
compared with previous ones, like costs reduction, increased quality of
life or lead time reduction.
Some application characteristics and functional requirements were identified
by the consortium in order to satisfy the needs for Teleworking in the
Industrial environment.
Characteristics
-
Independence in infrastructure network, capable of running on both LAN
environment and over WAN connections.
-
Flexibility. It should be possible to easily add or drop users on demand.
-
It should be possible to have users using different WAN technologies in
one same conference.
-
Bandwidth scalability. It should be possible to tune the application to
fully exploit the bandwidth provided by the infrastructure network. For
multipoint connections, multicast solutions should be used, to save bandwidth.
-
Traffic Shaping/Flow Control. The burstiness of the different data flows
(audio, video...) has to be reduced (by packet scheduling mechanisms) in
order to avoid over dimensioning the infrastructure network. The audio
stream should always be prioritised.
-
Teleworking applications, as any other real time packet based one, require
a certain QoS guarantee from the supporting network. This guarantee can
be provided by devoting specific network resources (ISDN lines, ATM VCs,
etc.) to the application or by relaying on a resource reservation solution,
like the one RSVP will be providing in the near future. In both cases,
a certain traffic scheduling capabilities will be required from the application.
-
Security. It should be possible to authenticate, both the entities in a
conference, as well as the information being interchanged (mostly documents).
It should also be possible to encrypt the information to secure confidentiality.
Functional Requirements
-
The platform shall support integrated multi-party audio communication.
-
It shall be possible to configure the required quality of the audio communication
(and therefore, the bandwidth needs).
-
That platform shall support integrated multi-party video communication.
-
The platform shall support integrated multi-party high-definition video
communication.
-
It shall be possible to configure the required quality of the video communication
(and therefore the bandwidth needs).
-
It shall be possible to have unidirectional multi-point video communication.
This is, for a multi-party communication it shall be possible to only display
the image of the speaking party.
-
The platform shall provide an integrated shared whiteboard. The drawing
device should be an electronic pencil or any other device that supports
a more natural drawing mechanism than a mouse.
-
The platform shall support the shared display of applications, for applications
not demanding quick updates of the display, like for instance, document
display.
-
The platform shall support the communication of snapshots of displayed
applications. This to allow to share just some relevant parts of the available
information, without compromising confidentiality of other parts, or reducing
the bandwidth needs that the continuous sharing of the display would imply.
-
The platform shall support the shared display of applications, for applications
demanding quick updates of the display, like for instance, shared display
of simulations.
-
The platform shall support the shared editing of documents and spreadsheets.
-
The platform shall provide an integrated electronic mail system that supports
text and simple graphs.
-
It shall be possible to check the status of the mails sent over the mail
system (received/read/deleted, date and time).
-
The mail system provided by the platform should support voice communication
(OPTIONAL).
-
The mail system provided by the platform should support video files transmission
(OPTIONAL).
-
The platform shall support shared application. This means that, although
the application is running only in one machine, the user interface shall
be displayed in the remote sites and the remote users will be able to interact
with the application.
-
It shall be possible to print the information displayed in any of the components,
regardless of whether it is an application running locally or just a remote
shared display, shared snapshot, shared application, shared editing session
or shared whiteboard.
-
It shall be possible to enter new images to be shared, by integrating in
the platform a scanner controlling component.
Return to contents list
Comparative cost analysis
For remote sites interconnection two main technologies were considered:
ISDN (public network) and ATM (services provided by the JAMES
project for international connections). ISDN has, for the moment,
a bigger geographic implantation in Europe than ATM. Additionally it presents
a higher reliability and lower installation costs (fixed costs).
The experimental international ATM service provided by JAMES, even if providing
higher bandwidths, proved, during early experiments carried out by TECODIS,
that it is lacking in flexibility, for connection set-up, and reliability
and is, therefore, convenient for Teleworking Platform tests rather than
for service trials. This way, for sporadic or for short duration
events, in which it is not foreseen to have more than three sites connected
at the same time in the same event, ISDN presents the best solution to
be adopted at the moment, depending on the number of used B channels
in the session desired quality and in the capacity to use it efficiently.
An early conclusion is that for short duration meetings, or meetings
involving more than two persons there is a cost reduction if Telework is
used.
Just to conclude it is worth mentioning that travelling costs only
represent around 2% of total project costs. This way, making one
cost analysis only based on travel costs is very superficial. Other
costs and benefits must be taken into consideration like lead-time, final
product quality, social costs for workers, etc., just to mention some.
TECODIS is studying this areas, evaluating the Platform with the inclusion
of that areas, expecting to give a more complete result with the inclusion
of as many measurable factors as possible.
Return to contents list
Attachments
State of the Art
Internet and related protocols and mechanisms are in constant evolution.
After the identification that IP is only able to provide a "best-effort"
provision of Quality of Service, what is not sufficient for the services
demanded by real-time traffic flow across the network, like audio and video,
the Internet community proposed a new architecture, which is documented
in RFC 1633 [3], based in the principles of access control and resources
reservation (namely IETF Resource Reservation Protocol RSVP [4]).
In the situations where ATM or ISDN technologies are used for transport,
network bandwidth is automatically reserved. But the same is not applicable
to the processing capacity in the network nodes, routers or ATM switches.
For that the new RSVP Internet standard, that is about to appear in commercial
equipment like Cisco routers, will enable resources reservation through
the routers and hosts along the routing path between receiver and sender.
Also ITU-T is developing new standards that TECODIS must keep an eye
on, and released products supporting the standards the standards. This
is the case of the specification H.323, "Visual Telephone Systems and Equipment
for Local Area Networks which Provide a Non-Guaranteed Quality of Service".
This standard incorporates some previously existing standards (H.261, etc.),
makes use of some others (T.120, etc.) and establishes inter operation
with others (H.320, etc.) . Also, it is based on the Real-Time Protocol/Control
Protocol (RTP/RTCP) and Internet RFC 1889.
The RTP/RTCP is expected to be incorporated in the Isabel application
in the near future.
Return to contents list
Supporting References