Simon Furber

Abstract

Brunel University has managed one of the first converged networks running data, voice and other services since 1999. This case study outlines some of the key drivers behind and experiences of this implementation and the strategy for IP communications that is going forward. Through example and experience, this highlights for the reader how to approach this type of project, regardless of the technology or vendor chosen.

Introduction

Any change to communication systems is disruptive within an organisation. It can challenge the very assumptions on which those who use and administer these systems rely. This disruption can lead to resistance and often requires comprehensive planning. All key players must be included fully in the development of a strategy for moving forward.

Traditionally the separation in an organisation between the telecommunications team and the IT/data communications team can be a problem. The strategy that Brunel adopted was to recognise their differences and strengths and put these two teams together. However, the management structure was unchanged, so responsibility for the telecoms service remained with the Estates Operations Department, while the Networking and Technology responsibility was managed by the Networks Team with the Computer Centre. The success of this arrangement has been completely down to creating good working relationships and communication.

Brunel has migrated from a traditional TDM (Time Division Multiplexing) system based on Siemens ISDX to a native IP Telephony solution based on the Cisco® Call Manager Architecture.

The implementation can be broken down into the following areas of interest.

Inter-operability and Features

As early adopters of IP Telephony technology, Brunel ran into many of the issues that are commonly faced today. There is already considerable investment, knowledge and comfort in the incumbent system. Introducing any new system is disruptive and requires careful consideration. There are essentially two options: the big bang approach (all change at once) or a migration (the change is gradual). Brunel decided that in green field sites, to ensure that services are maintained at high levels of availability within large organisations, migration is really the best way.

Brunel had piloted IP Telephony for several years and was successfully running in excess of 450 IP phones in addition to 2200 PBX (Private Branch Exchange) extensions. The PBX was used to gain access to the PSTN (Public Switched Telephone Network) and was effectively treated as an external system, in the same way as the PBX viewed IP Telephony. The migration plan first introduced new direct PSTN connectivity to new IP-based router gateways, to establish all the pilot phones on it with their new extension numbers on a new production cluster. Translations were put in place on the PBX to ensure old and new numbers continued to work in parallel.

In the second phase, as phones migrated from the PBX the number of PRI (Primary Rate Interface) lines adopted a shrink-and-grow model where new lines were provided via the IP gateways while being scaled down on the PBX side. The final stage was to move all PRI onto IP router gateways and have the PBX use these for all PSTN access. This was further accelerated by having to maintain two switchboards, so the PBX switchboard was scaled back quicker than expected and the main numbers moved over to the new console.

Brunel opted for no-feature transparency between its PBX and the Call Manager early on, reasoning that costs associated with integration products were wasted as it was not intended to keep the PBX in the medium term and the equipment would eventually become defunct. Instead, the money saved was invested in training and accelerating the actual migration.

An advantage of this scheme was that only the operators had to manage the two systems at once and deal with any feature clashes. Users only saw one system. Early on, difficulties were encountered where people working in groups couldn’t share features, for example group pick or hunt group. The migration plan was modified to ensure groups or functions were migrated together and the situation was resolved.

Brunel’s experience of the integration of the two systems is that it is not easy. There is a common myth associated with IP Telephony that because it is IP, it should be easy. The reality is that integrating any two telephony systems is difficult. A proprietary system is by definition specific to that manufacturer, and any two proprietary systems are always difficult to integrate. For obvious reasons, manufacturers don’t always make this easy. The more features you try to integrate, the more difficult it can be. Fortunately these days there are many more products and integration solutions available. Most PBX manufactures now understand IP (at least in part) and offer the means to integrate, migrate and upgrade. Another consideration is that as standards for communication like QSIG and SIP start to become more widely available, choices become more varied. Where possible, sticking to best practice and standards is highly desirable but every organisation is different.

Integrated Dial Plan

Using free dial plan space, everyone got a new extension number. They were increased to five digits for future proofing. It is easy to forget that any dial plan has a lot of hidden numbers, short dial, pilot points, hunt groups, voicemail etc. Expanding to five digits facilitated the introduction of future services, as well as making it possible to set aside certain numbers for specific purposes.

For a period of time a large translation table was maintained on the PBX, allowing staff/departments to make the necessary changes to stationery, prospectus, web sites etc. and also to allow them to get used to the new numbers. This meant that no number was left unanswered, disruption was low and it was possible to track who was still using the old numbers.

Distributed Architecture and Reliability

Brunel has suffered several times in the past from quite catastrophic failures of its PBX system due to power problems, burst steam pipes, failed air conditioning, flooding and excessive call volumes. Some of these events are simply unavoidable; however, Brunel planned for the future on the basis that if it can happen, it will, and not just once. The solution implemented was designed to ensure that any one single event would not be capable of disrupting the university’s communications systems.

This was achieved by having the call processing systems co-located in two data centres with a 50/50 split. Each data centre is capable of running up to 150% of the current capacity, permitting scaled growth while maintaining high availability. Voice gateways are located in three locations with one third of the capacity in any one location. Each ISDN 30 PRI is hosted on a different router in case of individual device failure. All core systems are backed by UPS for a minimum of two hours, and in most cases are backed by a generator.

Downtime

Brunel decided that during the migration there would be no downtime at all during the working day. This meant that all PCs, IP phones and PBX phones would be guaranteed to be available during core office hours. As a result the migration team had to work some late nights and one or two ‘all nighters’ to ensure that where network infrastructure was replaced, there was no disruption to the university’s business. This was also a good opportunity to do some long overdue maintenance, so communication racks were also upgraded and cabling tidied up at the same time. Thus the end user would not have noticed anything other than a new phone appearing on their desk the next day. This would then be provisioned by the telephony team and they would be ‘live’ on the new phone system. Brunel’s distributed architecture also allows for in-service software upgrades and gateway maintenance to take place with no discernable impact to the user.

However, an important lesson for Brunel’s network team to learn was to ensure that all their colleagues understood they were now running a converged network, which means there are service levels for systems that are owned and operated by others. These can have different priorities and procedures. Consequently routine maintenance and downtimes have to be coordinated more closely across a broader cross section of people. Brunel now has quite tight change control to ensure this is managed without disruption and is about to commission a permit-to-work scheme for all service engineers to guarantee the behaviour of third parties.

Skills and Training

The staff operating the existing switchboard were key in ensuring the success of the project. Initially, they were helped through the early stages of the project by the network team doing some of the administration and gradually handing this over. The challenge for them was moving from no more than one PC running Windows NT®, mainly used for modem access to the PBX, to each having a PC running Windows XP® and using a web browser and office product extensively. This was something that they simply had not needed to do before and the way in which they took to it was remarkable. They wasted little time in taking advantage of the new system and ended up accelerating the pace at which administration was fully managed by their team. Customised off-site training with some on-site training was used later to complete their skills.

The Users of the Phone System

It was realised early on that it would not be possible to train everyone to use their new phone. The strategy used was to work with the Academic Schools and establish ‘admin contacts’ within each. These people were then used as primary contacts and were fully supported and trained, then helped to train and support others through the initial deployment. The ‘train the trainer’ approach worked very well, and was expanded so that the ‘admin contact’ was also involved in the actual placement of the new phones on desks and helping people get logged on for the first time. This model has also been used very successfully during campus relocations and moves as it ensures that the right information is handled by the right people.

Costs

Inevitably, everyone wants to understand how much any solution will cost them. Brunel carried out a Return on Investment exercise. As a standalone strategy the costs of PBX vs IP Telephony were roughly the same. The cost benefits are actually seen more in the recurring costs and TCO (Total Cost of Ownership) of the solution as part of a much larger network strategy. As Brunel has a well established strategy for converging its network and deriving more and more service from it, the TCO has added benefit to the Telephony service. Obvious savings are made but in particular there is now one cabled infrastructure to all buildings. Planning can go into resilience and disaster recovery like never before, and the Telephony team have total control over adds, moves and changes which are now effectively done at no external cost. This means it is very easy to change and adapt to circumstance and emergencies.

There is a lot of discussion about the currently relatively high costs of IP handsets compared to a PBX phone. This is often perceived to be a disadvantage. However, most of the cost of a PBX would traditionally be in the switchboard’s central intelligence. With IP telephony, thoat costs is considerably lower but is offset by the need for more intelligence in the handset and distributing the licensing cost onto the handset away from a central switchboard. The Return on Investment exercise compared the costs for both systems and found they are actually still about the same.

Normally, the university would absorb the cost of new line cards and software upgrades to the PBX. After the initial roll-out which the University fully funded, the new model distributes the full cost to the point at which it is provisioned, making departments more cost accountable for their new telephony requirements. This does not help with the perceived cost of the individual phone but does mean the model is now fully costed.

The big assumption here, of course, is the underlying network. In practical terms, if the network is designed along best practice to ensure convergence can happen, introducing IP telephony can be relatively easy. The critical points are having control of that network, being able to predict its behaviour and have control of what can and cannot be done, and setting security and quality of service parameters. These are things that network managers should already be doing or considering doing.

Having an overall network strategy is key. Implementing a new model without one makes things potentially very difficult and will severely limit what you may ultimately be able to achieve. To put this in context, telephony systems are not traditionally designed to work together as they are by definition proprietary. It should not be assumed that any IP Telephony solution and PBX solution, even by the same manufacturer, will work together or make implementing convergence any easier. IP Telephony is not the magic bullet for making all telephony systems work together. Trying to put solutions onto a network not designed with this in mind is just as difficult and can exacerbate matters.

Summary

The most important factor is to have a strategy for to respond to the usage of voice on your network and an architecture onto which this can be built. There is still a lot of hype around IP Telephony and VoIP, and organisations can be tempted to respond because they feel they should rather than because they understand the impact of doing so, or consider the telephone as part of a larger strategy which can enable much more within the organisation.

It is now accepted that voice communication will move towards IP Telephony or VoIP services and it is worth considering such a solution in the medium to long term. Every organisation is different and will be its own driver in how much it chooses to get out of VoIP. Organisations should never feel pushed or coerced into a course of action without doing a proper survey of all their requirements and considering this as part of a much wider IT/Communications review. The solution can always be scaled back but gives a target architecture to work towards through cumulative investment, should the organisation so choose.