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: It is intended to the following audiences: 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: 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

Functional Requirements

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