The Process of Communications System Design The design approach is direct:

(i)

Get the operations design correct first, taking into account information systems design as the key parameter. It is impossible to design a good communications facility if the purpose, requirements and objectives of the company are not known; Determine the forms of traffic required; Estimate the required bandwidth for each; Aggregate the bandwidth according to carrier type note that it may not be possible to carry (say) voice over ADSL because of restrictions imposed by the telecommunications company; Allow for contingency; Investigate the available products able to supply the necessary services. The minimum selection criterion is the ability to meet the bandwidth requirement, but other factors (value added services, ease of use, added benefits) will need to be taken into account. An exact bandwidth fit is most unlikely take the next highest offered service. Investigate the necessary equipment base; Ensure security, backup, and support equipment, along with maintenance schedules, are in place.

(ii) (iii) (iv)

(v) (vi)

(vii) (viii)

The principles of information system design (indeed, systems analysis in general) do not fall within the scope of this work. It is to be hoped that the client has deployed this expertise before addressing the needs of communications emergent from it. Calculation of Bandwidth Requirement The calculation of bandwidth requires the combination of the voice and data requirements, and the estimation of the total usage of each in the relevant media for transmission. There is no simple combination to derive the total traffic, beyond the estimation of volumes for each and the calculation of the traffic for each carrier medium. Let us then first consider how to estimate traffic requirements from the ways in which business operates. We will later combine this with the carrier methods to derive a basic calculation methodology. The essentials of the calculation rely on the fundamentals of data and voice traffic. Let us start with voice traffic. The bandwidth of a voice signal under normal telephony is 3.4kHz, which with guard bands and Nyquist considerations gives us a total equivalent sampled bandwidth of 8kbps to transmit a voice channel digitally. Transmission of 30 voice channels concurrently will require 240kbps. This simple multiplicative approach is normal for voice traffic.

The approach, therefore, is to calculate the overall bandwidth requirement from the constituent elements of the carried traffic. This yields an overall figure for the required available traffic carrying capability of the system interface. The system might link to a public utility carrier directly, or could interface to an internal backbone system. In terms of traffic loading, there is no difference in the calculation. There is considerable difference in terms of interface equipment. Let us now turn to the basics of a traffic calculation. The question divides quite easily into an aggregation of data, voice and video/audio traffic. In order to estimate the data traffic, the following considerations need to be taken into account: (i) What is the stated data rate of the network link? (ii) What is the algorithm used for medium access control (not all the world is Ethernet - just most of it)? In the voice world, the standard channel size is 300Hz - 3.4kHz for a voice channel. Allowing for guard bands, and the need (as defined by the Nyquist sampling criterion) to sample a signal at a rate at least twice its highest frequency to allow adequate reproduction, the single digital voice channel is of 8kbps (bps = bits per second). In analogue voice transmission (as with conventional telephony) voice channels are stacked in terms of frequency for carriage over a single line. In digital systems, the voice channels may be carried consecutively. If a digital system can deliver 1Mbps, it can carry 1000/8 = 125 voice channels concurrently, without the user noticing any degradation in performance provided the samples are delivered in time to be decoded as a continuous stream. It is prudent to mention that this assumes that the traffic does not include signalling information, but solely data (which is not usual). The basic combinations of data rates used in telecommunications are shown in the table below, along with their CCITT designations and "familiar" names: Table X.1: Telecommunications TDM Channel Bandwidths ITTU-T Designation 1 2 3 4 5 No. of Voice Channels 30 120 480 1920 7680 Data Rate (Mbps) 2.048 8.448 34.368 139.264 565.148

Table X.2: US Carrier TDM Channel Bandwidths Designation DS-1 DS-1C DS-2 DS-3 DS-4 No of Voice Channels 24 48 96 672 4032 Data Rate (Mbps) 1.544 3.152 6.312 44.736 274.176

Table X.3: SDH Signal Hierarchy ITTU-T Designation STM-1 STM-3 STM-4 STM-6 STM-8 STM-12 STM-16 Data Rate (Mbps) 155.52 466.56 622.08 933.12 1244.16 1866.24 2488.32 Payload Rate (Mbps) 150.336 451.008 601.344 902.016 1202.688 1804.032 2405.376

Several carriers supply equipment to support the assorted categories of multiplexed carrier signals. The US suppliers prefix their designations with a T label. A T1 carrier provides a data rate of 1.544Mbps, providing for the needs of the DS-1 multiplex format. The utilisation of bandwidth depends on several factors: the offered load (if the load is less than the available bandwidth, utilisation will be less than 100%); the ability to multiplex traffic in time to build up to the available bandwidth; and the ability to multiplex the data in terms of frequency. The issue of multiplexing is relatively complex, in that the need to use the available bandwidth efficiently can require the combination of traffic from different users and of various types. Techniques such as statistical multiplexing are used with telecommunications switches to allow optimal performance. This is discussed further in Section YYY. The problem now is one of division of the channel bandwidth available into suitably sized facilities for the services required by the various data users. . The bandwidths currently required for the various types of traffic are indicated in the table below. No such list can be exhaustive the rate of change in telecommunications is enormous, and future compression algorithms and improvements in encoding should reduce the given figures.

Table X.4: Traffic Bandwidth Consumption Service kbps) Telephony EPOS Terminals Internet Connection (Analogue) Internet Connection (ISDN) Internet Connection (ADSL) Videoconferencing Video on Demand Data Rate (Per Channel,

8 1.2-9.6 9.6 - 56 64 128 - 2000 XX 2300

Bandwidth calculation is not a simple issue. Very few of the systems in the table above actually consume bandwidth consistently over time - Internet traffic, in particular, is bursty and sporadic. The statistical proportion of time for which the traffic is produced is known as the duty cycle of the system. In effect, a 100kbps data rate system which has a duty cycle of 10% consumes an average bandwidth of 10kbps over time - but to use ten such systems on a 100kbps link is to court disaster (the likelihood of exceeding the available bandwidth at some point is extremely high. In the determination of required data rate on a link, the conventional approach is to attempt an "accurate" calculation, then add an appropriate overhead to allow for unusual conditions. It is unwise to overestimate - utility carriers will factor bandwidth requirement into their charges as a primary determinant of cost. Let us now take a calculation example. We will estimate the likely traffic for a typical office environment. Calculation Example The main office of Business Support Services, a business advice service provided by Regional Government, is to be moved from Stafford to Lichfield. The main satellite office is at Stoke. Staffing changes are proposed as part of the move, which is into a new building, as yet unfurbished. The office space is to be used by three permanent management staff, along with ten support and secretarial. Of the support staff, six are usually engaged in dealing with the client base by telephone on a more or less continuous basis. The other staff make use of communications facilities as normal casual users. The primary support service is provided by home-based consultants, of which there are ten. These are infrequently in the office, and usually "hot desk" on the two places provided for them. Call forwarding between sites is a frequent occurrence, and it is estimated that fifty percent of the telephone traffic is between the two offices.

Data traffic is limited, and occurs principally in the storage and access of database files, stored on the main client database (stored on an AS400 in an Oracle database). This database will be upgraded as part of the move to include a web-based front end. Data accesses by the business advisors are infrequent and relatively short transactions. The office uses an Ethernet LAN for internal data transfer. Pulling out the requirements of such a system is relatively straightforward. There are necessary questions to ask, and obvious additional considerations beyond the traffic carriage requirement. These would include the prospects for future development (we do not want to design in obsolescence), the needs of data security (a client database requires security, if only to meet the data protection act, and sensitive client information can impact on company value), and the performance necessary in terms of response times and the facilities to be made available to off-site staff. Following further investigation, the additional points listed below are identified: (i) (ii) The Government has imposed an arbitrary maximum time limit of 30 seconds between call receipt and speaking to an appropriate advisor; The home-based consultants will require access to the database concurrently with telephone services. The budget will not cover ongoing running costs of the order of those imposed by WAP telephony; The existing PBX is a BT North Star Meridien product, capable of handling up to 30 lines. This will not be replaced as part of the move, but will be kept available for use if required; Little expansion in the workforce is anticipated in the near future; Creation of a web data source for advisors is regarded as an essential improvement in the near future.

(iii)

(iv) (v)

With this information, we can begin to conceptualise a solution. The telephony service requirement is a good place to start. We will need fifteen telephone handsets as a bare minimum. It is a reasonable assumption that the six staff permanently dealing with the client base from the office will be near-permanent users (it would be unusual if even their use exceeded 80% of the available time); and we will put in three lines for the management team, who, although unlikely to use the telephone at a rate higher than that of other normal users, will have sufficient clout to make our lives difficult if not entirely satisfied. The other six users we will regard as typical users, probably not more that 20% time access spent on telephony. In pure calculation terms, we therefore require (9*8k*0.8 + 6*8k*0.2) bps of bandwidth for telephony. To the figure of 67.2kbps we add an overhead to allow for the statistical likelihood of overdraft on our traffic. We will add 20% as an appropriate overhead, yielding a total bandwidth of 80.64kbps. As will be indicated later, we do not purchase bandwidth in quantities specified exactly, but have to pay for the available service nearest in capability to our requirements.

Given that fifty percent of the telephony traffic is between offices, the leasing of a line is likely to be a competitive option. Given the bandwidth (approximately 40kbps), an option such as a Kilostream line will provide more than adequate bandwidth. Indeed, the use of a 64kbps ISDN line with telephone multiplexing would meet the requirement. The data traffic requirement is relatively limited. The introduction of the web front end will require external access to the facility. Given the limited expertise likely to be available within the organisation, and the level of data traffic, it makes little sense to consider self-hosting. Probably the best option is to utilise an ISP, with a leased line link to the office. The hosting of the database at the ISP might be problematical, given the sensitive nature of some of the likely data. If this requires the database to be physically stored at the office, the leased line option becomes essential. In this case, a straight ISDN line at 64kbps is appropriate. Other options include the use of the ADSL service (e.g. BT Business World). However, this is yet to be rolled out in the region in which the example is set. The equipment this will require varies according to the intended user. For external access both to the database from the Internet and from the internal network to the Internet, an ISDN link and modem, an ISDN to Ethernet converter running to an Ethernet switch. The use of a firewall router for security is necessary to avoid data hazard. If access to the database is the only requirement, it makes eminent sense to remove the database server from the internal network and connect is solely to the ISDN link. This avoids problems of system security, other than securing the database itself. There is no point in offering access to the Internet to staff not using it as part of the job; the exposure to external data access (hackers, malicious intrusion) is significant with Government services. The available PBX gives appropriate volume for telephony traffic. Coupled with leased line access to the other site, this will take care of the telephony requirement. The 30 seconds response time is catered for (insofar as it can be handled) by call forwarding from the PBX. The timing problem is a systems issue it can only be met by knowing which staff are available at any given moment. One might require external consultants to log on to the database when available but the telephony costs in always on access over home ISDN are too high for this kind of organisation to contemplate. Diary management and good discipline is the traditional alternative. The resulting design is shown in figure YYY below. Note that this is the low cost version of a solution. It is equally possible to implement the whole system as an ATM configuration, based on integrated data services. Such a solution is unlikely to appeal (purely on grounds of initial cost) at the present time. However, it is exactly this solution that is the proposed alternative for future large company approaches. The economics for small enterprises are unlikely to become attractive in the near future.

Figure YYYA: Non-Integrated Solution

User Stations

Ethernet Switch
User Stations

ISDN Access

ISDN Link To ISP

Internal Telephones

ISDN Link To Other Site

PBX
Link To BT Standard Lines

Figure YYYB: Integrated Solution

User Stations

Ethernet Switch
User Stations

ATM Multiplexer
Internal Telephones

ATM Line

PBX

The integrated solution requires the ATM supplier to offer integration with standard telephony but could also implement the solution via voice over IP. This is particularly attractive for the interoffice link. Indeed, were the purchasing economics less clear cut, such an approach would warrant consideration at this time.