Migration/Consolidation Planning

Transcription

1 NN

2 Document status: Standard Document version: 0101 Document date: 28 October 2008 All Rights Reserved Sourced in Canada LEGAL NOTICE While the information in this document is believed to be accurate and reliable, except as otherwise expressly agreed to in writing NORTEL PROVIDES THIS DOCUMENT "AS IS" WITHOUT WARRANTY OR CONDITION OF ANY KIND, EITHER EXPRESS OR IMPLIED The information and/or products described in this document are subject to change without notice Nortel, the Nortel Logo, and the Globemark are trademarks of Nortel Networks All other trademarks are the property of their respective owners

3 3 Contents Revision history 5 How to get help 7 Getting help from the Nortel Web site 7 Getting help over the telephone from a Nortel Solutions Center 7 Getting help from a specialist by using an Express Routing Code 7 Getting help through a Nortel distributor or reseller 8 Introduction 9 Subject 9 Note on legacy products and releases 9 Applicable systems 9 Intended audience 10 Conventions Related information Overview 13 Release 5x 14 Discovery 19 Introduction 19 Documenting discovery items 19 Presentation software 19 Reminders 19 Execution 20 Collecting system information 20 Tools 21 Case Studies 29 Case study 1 29 Overview 29 Case Study 2 37 Phase 1: Establish CS 1000E core 39 Phase 2: Split CS 1000E core 40 Phase 3: Water Works site conversion 41 NN Standard Release October 2008

4 4 Contents Phase 4: Library conversion 42 Phase 5: Fire Station conversion 43 Phase 6: Police conversion 44 Phase 7: Town Hall CS 1000M conversion to MG 1000E 45 Quoting 47 Introduction 47 Quote generation 47 CS 1000E new quote generation 48 EC configuration considerations 48 Application upgrade and change quote generation 49 Database migration 51 Planning the migration 51 NN Standard Release October 2008

5 5 Revision history Standard 0101 This document is created to support multi-system migration and consolidation for Release 50 NN Standard Release October 2008

6 6 Revision history NN Standard Release October 2008

7 7 How to get help This chapter explains how to get help for Nortel products and services Getting help from the Nortel Web site The best way to get technical support for Nortel products is from the Nortel Technical Support Web site: wwwnortelcom/support This site provides quick access to software, documentation, bulletins, and tools to address issues with Nortel products From this site, you can: download software, documentation, and product bulletins search the Technical Support Web site and the Nortel Knowledge Base for answers to technical issues sign up for automatic notification of new software and documentation for Nortel equipment open and manage technical support cases Getting help over the telephone from a Nortel Solutions Center If you do not find the information you require on the Nortel Technical Support Web site, and you have a Nortel support contract, you can also get help over the telephone from a Nortel Solutions Center In North America, call NORTEL ( ) Outside North America, go to the following Web site to obtain the telephone number for your region: wwwnortelcom/callus Getting help from a specialist by using an Express Routing Code To access some Nortel Technical Solutions Centers, you can use an Express Routing Code (ERC) to quickly route your call to a specialist in your Nortel product or service To locate the ERC for your product or service, go to: NN Standard Release October 2008

8 8 How to get help wwwnortelcom/erc Getting help through a Nortel distributor or reseller If you purchased a service contract for your Nortel product from a distributor or authorized reseller, contact the technical support staff for that distributor or reseller NN Standard Release October 2008

9 9 Introduction This document is a global document Contact your system supplier or your Nortel representative to verify that the hardware and software described are supported in your area Subject This document provides information about migrating and consolidating a multi Meridian 1 system to a single CS 1000E High Availability (HA) system Note on legacy products and releases This NTP contains information about systems, components, and features that are compatible with Release 45 software For more information on legacy products and releases, click the Technical Documentation link under Support on the Nortel home page at wwwnortelcom/support Applicable systems This document applies to the following systems: Communication Server 1000S (CS 1000S) Communication Server 1000M Chassis (CS 1000M Chassis) Communication Server 1000M Cabinet (CS 1000M Cabinet) Communication Server 1000M Half Group (CS 1000M HG) Communication Server 1000M Single Group (CS 1000M SG) Communication Server 1000M Multi Group (CS 1000M MG) Communication Server 1000E (CS 1000E) Meridian 1 PBX 11C Chassis Meridian 1 PBX 11C Cabinet Meridian 1 PBX 51C Meridian 1 PBX 61C Meridian 1 PBX 81 NN Standard Release October 2008

10 10 Introduction Meridian 1 PBX 81C Note: When upgrading software, memory upgrades may be required on the Signaling Server, the Call Server, or both Intended audience This document provides guidelines for individuals planning the migration of multiple CS 1000 systems to a single centrally managed consolidated system with geographically distributed survivable Media Gateways For detailed information or procedures for installing and configuring CS 1000, including dialing plans, emergency services, Survivable Media Gateways or other components, refer to the appropriate Nortel documentation Conventions Terminology In this document, the following systems are referred to generically as "system": Communication Server 1000M (CS 1000M) Communication Server 1000E (CS 1000E) Meridian 1 The following systems are referred to generically as "Small System": Communication Server 1000M Chassis (CS 1000M Chassis) Communication Server 1000M Cabinet (CS 1000M Cabinet) Communication Server 1000S (CS 1000S) Meridian 1 PBX 11C Chassis Meridian 1 PBX 11C Cabinet The following systems are referred to generically as "Large System": Communication Server 1000M Half Group (CS 1000M HG) Communication Server 1000M Single Group (CS 1000M SG) Communication Server 1000M Multi Group (CS 1000M MG) Meridian 1 PBX 51C Meridian 1 PBX 61C Meridian 1 PBX 81 Meridian 1 PBX 81C Related information This section lists information sources that relate to this document NN Standard Release October 2008

11 Related information 11 NTPs The following NTPs are referenced in this document: Spares Planning (NN ) Equipment Identification Reference (NN ) Circuit Card Reference (NN ) Features and Services Fundamentals-Six Books (NN _B1-B6) Software Input Output Administration (NN ) Software Input Output Reference - System Messages (NN ) Software Input Output Reference - Maintenance (NN ) Communication Server 1000M and Meridian 1 Large System Upgrade NTPs (NN NN ) Communication Server 1000M and Meridian 1 Small System Software Upgrade (NN ) Communication Server 1000E Software Upgrades (NN ) Communication Server 1000E Planning and Engineering (NN ) Communication Server 1000E Installation and Commissioning (NN ) Communication Server 1000M and Meridian 1 Large System Maintenance (NN ) Communication Server 1000M and Meridian 1 Large System Installation and Commissioning (NN ) Element Manager System Administration (NN ) Signaling Server Installation and Commissioning (NN ) IP Peer Networking Installation and Commissioning (NN ) For information on IP Phones, refer to IP Phones Fundamentals (NN ) NN Standard Release October 2008

12 12 Introduction NN Standard Release October 2008

13 13 Overview A number of factors are driving significant change in customer expectations for communications systems, including: an increasingly mobile workforce the general acceptance of Voice over IP (VOIP) and Unified Communications fueled by new applications and enabling technologies such as SIP an increasing need to reduce cost the need to ensure continuity of communications in the event of a disaster a desire to make employees more productive the maximization of existing capital investment benefits The changes delivered with CS 1000 Release 5x allow a customer to migrate a network of separately managed systems to a single, centrally managed and geographically distributed system Existing Meridian 1 Option 11 cabinet or chassis, CS 1000M cabinet or chassis, CS 1000S and CS 1000E systems can be migrated to Media Gateways, geographically distributed but functioning as a single consolidated Communication Server Any Media Gateway in this new consolidated system can be provisioned to be fully survivable using the Survivable Media Gateway feature providing services to both IP and TDM devices alike The CS 1000 Release 5x architecture enhancements, coupled with business requirements including disaster recovery, enhanced applications, Unified Communications and reduction in infrastructure costs, are allowing customers to both migrate and consolidate their systems The ability to leverage the CS 1000E Release 5x architecture to provide geographic redundancy to both digital and IP clients, and reduce capital costs with centralization, are the major contributors to customer migration and consolidation NN Standard Release October 2008

14 14 Overview Release 5x With the introduction of (CS 1000) Release 5x an enhancement to the CS 1000E architecture enables a number of new options for redundancy and form factor for Media Gateway and servers Customers now have options for single and redundant processors for systems of any line size, a choice for chassis or cabinet form factor for the Media Gateway and options for signaling server form factor Figure 1 CS 1000E SA non-redundant Figure 1 "CS 1000E SA non-redundant" (page 14) shows a CS 1000E Standard Availability (SA) system With release CS 1000 Release 5x a customer may deploy existing or new cabinets or chassis as Media Gateway 1000 (MG 1000) A new Call Processor platform (CP PM) is available which occupies a slot in a MG 1000 cabinet or chassis This new processor may be deployed as a single call NN Standard Release October 2008

15 Release 5x 15 Figure 2 CS 1000E HA redundant SA CS 1000E processor configuration or in a redundant HA CS 1000E processor configuration The redundant CP PIV processor configuration is also still available as an HA CS 1000E system Figure 2 "CS 1000E HA redundant" (page 15) shows a CS 1000E HA system The Release 5x CS 1000E system will support up to 50 media gateways and 22,500 IP Phones Each media gateway is controlled by a new Media Gateway Controller (MGC) that can support up to 128 DSP channels installed as daughter cards on the MGC With the enhancements delivered by the MGC, PRI cards are now supported in an MG 1000E NN Standard Release October 2008

16 16 Overview Figure 3 CS 1000E Cabinet Option The CS 1000S, CS 1000M Chassis and CS 1000M Cabinet system types will now be migrated to a CS 1000E SA upon upgrade to current release The SA system may optionally be upgraded to an HA system with the addition of a second CP PM processor and by enabling the HA software package Figure 3 "CS 1000E Cabinet Option" (page 16) shows the CS 1000E Cabinet system option One of the features enabled with CS 1000 Release 5x is N-WAY Redundancy This feature enables a Media Gateway to connect to Alternate Call Servers in the event of a Primary Call Server failure This provides survivability of both the IP and TDM resources in a CS 1000E system In Release 5x, a CS 1000E system consists of a Call Server in an SA or HA configuration and up to 50 Media Gateways (some or all of which may be geographically distributed) Alternate Call Servers may be configured at any of the Media Gateway sites Enhancements introduced into the new Media Gateway Controller cards provide the Media Gateway with the ability to connect to three Call Servers in a defined order of preference In the event of a Primary System failure, the Media Gateways will re-register with an Alternate Call Server The configuration of the system is performed at the Primary Call Server and back up routines will replicate the database of NN Standard Release October 2008

17 Release 5x 17 the Primary Call server to all of the alternate Call Servers This allows any Alternate Call Server to accept registration from any or all of the TDM or IP resources configured on the Primary Call Server A typical scenario may consist of a Primary Call Server placed in a Primary Data Center, an Alternate Call Server located in Secondary Data Center and multiple Alternate call Servers located at remote Media Gateway sites In normal operation, the Media Gateways are controlled by the Primary Call Server at the Primary Data Center In the event of a Primary Call Server failure the Media Gateways and clients would re-register to the Alternate Call Server at the Secondary Data Center In the event of a WAN failure where remote sites lose all network connectivity the Media Gateways would connect to their local Alternate Call Server This document provides an overview of a process for migration of multiple CS 1000 systems to a single centrally managed consolidated system with geographically distributed survivable Media Gateways Ensure you have a hardware, software and database back out strategy should problems arise For detailed information, refer to the appropriate system documentation NN Standard Release October 2008

18 18 Overview NN Standard Release October 2008

19 19 Discovery Introduction When migrating or consolidating single or multiple systems into a CS 1000E system, pre-sales discovery is a critical step in the process During discovery the primary goal is to collect and document all pertinent information on customer requirements, existing systems and applications This information will be used to create a customer project road map and to develop an appropriate architecture The following section discusses various components in discovery that can be used to collect the required information Documenting discovery items Presentation software During the Discovery Phase the creation of diagrams, assumptions and other pertinent information is crucial for developing a customer road map and architecture The use of presentation software is one medium that can serve multiple purposes in any project It can provide documentation that can be used later as a customer proposal and provides other team members with a simple method of gaining insight into a project Reminders The following are important reminders when assessing any migration/consolidation: Careful consideration and planning are essential since systems and applications are to be decommissioned after migration/consolidation and no further expansions or upgrades are allowed after this occurs If a customer s migration/consolidation project time line is scheduled over a long period of time, they run the risk of having their migrating systems running older software or hardware This can cause failures requiring hard to obtain replacement parts Customers should be encouraged to consider such implications as they are planning their migration/consolidation Note: In older systems, acquisition of spare components and/or support may be limited NN Standard Release October 2008

20 20 Discovery There may be unforeseen events during migration/consolidation consolidation where systems designated for consolidation or migration must be expanded If these systems have been decommissioned to allow license transfers expansion is not possible Customers should phase the decommissioning of their existing systems in the migration plan to remove this risk For example; a municipality is consolidating multiple systems Fire and Police are considered high risk and therefore should not be part of the initial stages of the consolidation They should be consolidated in later phases to allow for expansion at anytime An end state may be used to provide pricing to a customer, however the project can be sold in phases Selling in phases allows customers to mitigate risks and concerns such as in the example above Customers with Call Center environments will require special planning for migration and consolidation This must be discussed in detail before quoting the consolidation to ensure all functions, applications and components are covered Execution Collecting system information The first step in assessing a customer s needs is to have the Pre-Sales Engineer collect system information from the Network as it currently exists in order to determine customer requirements for a consolidated environment Note: The table below provides a list of possible systems and corresponding tools available to the Pre-Sales Engineer for existing architecture evaluation The tools in the table provide architecture information including hardware and software configuration The discovery of other components such as dial plan use other methods including Telephony Manager, Command Line or other administration tools System/Application CS 1000/Meridian CallPilot Meridian Mail Call Center OrderPro KRS Manual Site Surveys KRS Manual Site Surveys KRS KRS Tools NN Standard Release October 2008

21 Execution 21 Miscellaneous applications MIXX, AG1000,NRAO (vintage compatibility using compatibility table) OrderPro KRS Manual Site Surveys OrderPro KRS Manual Site Surveys Determines options for application s (move or new) Tools OrderPro OrderPro is an ordering tool that provides two reports, Summary and Detail, that can provide a view of existing systems from both a hardware and software perspective OrderPro provides the following functionality: OrderPro provides useful information in conjunction with a site survey for identifying existing hardware A Manual Site Survey should also be conducted to compliment the OrderPro report In some systems older hardware may not be reflected in the OrderPro reports OrderPro provides useful information as to installed software licenses Summary reports These reports give a summary of Existing Licenses and system software levels that can be used to plan and build a system consolidation Detail reports These reports provide hardware details on installed cards and cabinets/shelves They can be used to determine what cards exist and can be re-used in a migration Figure 4 "OrderPro summary report system A" (page 22) shows an example of an OrderPro summary report for system A NN Standard Release October 2008

22 22 Discovery Figure 4 OrderPro summary report system A Key Retrieval System (KRS) KRS is a database used to store and display customer system information which can be viewed on line and exported as required KRS can be used to provide information required for system migrations/consolidations including core system and application licensing information KRS can be used to view Software Release Subscription (SRS) contracts that exist on systems and applications: Vendors of Record can display details Non-vendor of Record will not see an SRS Contract exists When accessing the Keycode Retrieval System users can display multiple product information assigned to a specific Serial/CLLI number Figure 5 "KRS Component selection" (page 23) shows the pull down selection with specific customer products available NN Standard Release October 2008

23 Execution 23 Figure 5 KRS Component selection Figure 6 KRS Core System View Figure 6 "KRS Core System View" (page 23) shows the information available for a CS 1000M Single Group System If the user is the Vendor of Record an envelope can be downloaded which will allow the user to download a consolidated view of all customer products The download envelope button is located at the bottom of a selected product screen (see Figure 7 "KRS SRS View" (page 24)) NN Standard Release October 2008

24 24 Discovery Figure 7 "KRS SRS View" (page 24) demonstrates the additional actions that can be executed by a user after viewing any selected product The download envelope and SRS buttons are only usable if the logged in user is the vendor of record For download envelope the user must be the system vendor of record and for SRS the user must be the vendor holding the SRS contract Figure 7 "KRS SRS View" (page 24) shows the result of a vendor of record display for an SRS contract If the user is not the vendor of record, after selecting view SRS, a window appears telling the user there is no SRS contract In both cases a user can ask a Nortel representative to search both records if required Figure 7 KRS SRS View Figure 8 "KRS CallPilot View" (page 25) displays a product Keycode view for a CallPilot system The user selected CallPilot from the pulldown menu NN Standard Release October 2008

25 Execution 25 Figure 8 KRS CallPilot View Figure 9 KRS Meridian Mail View Figure 9 "KRS Meridian Mail View" (page 25) represents a product Keycode view for a MMAIL system The user selected MMAIL from the pulldown menu Additional Discovery Items In addition to gathering Existing infrastructure information, other information must also be obtained to enable a solution design to be completed The depth of discovery will vary with each customer opportunity The table below provides a sample customer information checklist Note: This checklist is meant to serve as a guide only There may be other scenarios and configurations that need to be assessed individually NN Standard Release October 2008

26 26 Discovery Question What modifications to the existing dial-plan (extension re-numbering, DID impacts, etc) are required? What Hardware will be re-used in the new CS 1000E? How many user licenses will be brought forward? How many will convert from TDM to IP? How many system licenses will be brought forward? Will one of the existing CallPilot systems be used as the go forward platform, or will a new one be configured? How many Licenses will be brought forward? Will Networking be required during migration? Will IP or PRI trunks be used to provide voic services? What can be added to the existing systems to allow this? What other applications exist? What is the strategy for those? Do application(s) meet the required vintage, can they be upgraded? Don t forget application cards, MIXX, etc What redundancy and survivability is required? What is required in data infrastructure to support? What is the migration timeline strategy? What risks are present in decommissioning existing systems? How will the customer database be converted for multiple systems into a single system? What will be the impact? How is RAN provided today? CS 1000E systems do not support daisy chained XUT RAN trunk ports or Contact Center based Controlled Broadcast RAN RAN Broadcast ISM s must be used instead to play RAN to multiple callers at the same time A minimum of 4 RAN Broadcast ISM s must be assigned to each RAN route (individual announcement) Answer NN Standard Release October 2008

27 Execution 27 How is Music on Hold/Delay provided today? CS 1000E systems do not support conference based Broadcast Music and must use Music Broadcast ISM s instead to play Music to multiple callers at the same time Ensure you have a hardware, software and database back out strategy should problems arise For detailed information, refer to the appropriate system documentation NN Standard Release October 2008

28 28 Discovery NN Standard Release October 2008

29 29 Case Studies Case study 1 Overview The following case study example represents the various discovery items required to consolidate two systems into a single CS 1000E system The discovery detail and information will vary by customer based on requirements and installed architecture In general the this example can act as a guideline for other multiple system consolidations The case study is based on a health care provider who currently has two installed systems, a CS 1000M SG and a CS 1000M MG The customer would like to consolidate the two existing systems to leverage Geographic Redundancy features of a CS 1000E Release 5x architecture while also laying a foundation for future enhanced Unified Communication Applications and leveraging potential TCO savings with a single system The customer has decided to replace their existing CallPilot s with a 1005R platform to further the resiliency in their design In migrating some digital and analog users to IP clients, the customer anticipates their existing hardware and software investment will be leveraged to its fullest with a new CS 1000E solution To design a viable solution a pre-sales engineer must gather and document information on the existing Architecture, along with documenting customer requirements In Figure 10 "Case study 1 existing system" (page 30), the pre-sales engineer has used the various tools documented in the discovery section of this NTP and provided a detailed graphical overview of the existing system NN Standard Release October 2008

30 30 Case Studies Figure 10 Case study 1 existing system Questions and answers (collecting information) In addition to exploring existing infrastructure, the pre-sales engineer must also consider and document pertinent design information For example, in any multiple system consolidation, dial plan design is the major driving element It is normally the first item to be discussed as it typically has the largest impact to users Impact decisions by a customer can drive specific design criteria Other elements include, but are not limited to, migration timeline, migration phases, expansion, Data infrastructure, application usage, application design, conversion of existing TDM to IP users, and Unified Communications strategy All are important elements that impact any proposed solution Ensure you have a hardware, software and database back out strategy should problems arise For detailed information, refer to the appropriate system documentation The following table represents some key elements that were discussed during the discovery phase of this case study Discovery depth varies by customers and may become more complex where more sites and/or applications are involved with the consolidation NN Standard Release October 2008

31 Case study 1 31 Question What modifications are required to the existing dial-plan? What Hardware will be re-used in the new CS 1000E? How many user licenses will be brought Forward? How many will convert from TDM to IP? How many system Licenses will be brought forward? Answer Dial Plan will be unified using a DN Expansion from 4 digit to 5 digit Evaluation showed this would fit into existing DID ranges by using the last digit of the NXX as these were Unique between the two sites Tools used to discover this information could consist of Command Line, Telephony Manager, Element Manager and other system management systems The information required is retrieved from the Electronic Switched Network (ESN) database System A User Licenses 544 Digital to move to new CS 1000E Re-use Existing DLCs (34) 32 Digital to Convert to IP 324 Analog to move to new CS 1000E Re-use Existing Analog cards (21) 604 Analog to convert to IP 512 Patients that will go to IP Bedside + 92 spare 128 DECT to IP 56 IP to transfer System Licenses 30 ACD, 60 AST, 8 SIP Miscellaneous Hardware 8 UTCs System B User Licenses 808 Digital to move to new CS 1000E Re-use Existing DLCs (51) 16 Digital to Convert to IP 308 Analog to move to new CS 1000E Re-use Existing Analog cards (20) 516 Analog to convert to IP 500 Patients that will go to IP Bedside + 16 spare 176 DECT to IP 56 IP to transfer NN Standard Release October 2008

32 32 Case Studies Will one of the existing CallPilot Systems be used as the go forward platform or will a new one be configured? System Licenses 27 ACD, 60 AST, 8 SIP Miscellaneous Hardware 3 UTCs Tools used to compile this information are KRS, OrderPro and Manual Site Surveys A New CallPilot 1005R will be used as the move forward platform This information is gathered during customer discovery sessions after the existing system information has been gathered from KRS How many Licenses will be brought forward? System A 1120 Voice, 70 Desktop, 50 FAX, 50 Mobile System B 1120 Voice, 20 Desktop, 20 FAX, 20 Mobile This information is gathered during customer discovery sessions after the existing system information has been gathered from KRS and/or OrderPro Will Networking be required during migration? Will IP or PRI trunks be used to provide voic services? What can be added to the existing systems to allow this? Auto-attendant Services will be duplicated in the 1005R ready for PSTN transition Users will only be able to send voice mails between systems using VPIM Networking This information is gathered during customer discovery sessions after the existing system information discussed earlier in this NTP has been obtained This information is defined by customer migration strategy discussions Not Applicable as above If any calling between systems is required it will be determined during detailed planning and PRIs will be added if required This information is gathered during customer discovery sessions after the existing system information discussed earlier in this NTP has been obtained This information is defined by customer migration strategy discussions Not Applicable as above This information is gathered during customer discovery sessions after the existing system information discussed earlier in this NTP has been obtained This information is defined by customer migration strategy discussions NN Standard Release October 2008

33 Case study 1 33 What other applications exist? What is the strategy for those? Do Application(s) meet the required vintage, can they be upgraded? What redundancy and survivability is required? Companion This information is gathered during customer discovery sessions after the existing system information discussed earlier in this NTP has been obtained In addition to KRS reports a discussion with the customer is imperative as some third party applications may exist that utilize interfaces such as Digital Set Emulation These will not be identified by the tools discussed Customer transitions to a VOIP Wireless system This information is obtained in detailed customer discovery sessions Don t forget Application Cards MIXX etc Companion to be replaced as above, no other application cards exist, RAN is provided through a UTC with a third party unit Ran Broadcast Licenses are being added as customer uses Conference based RAN and Music today This information is gathered utilizing the KRS system and by completing manual site surveys Older Applications may not appear in the KRS system and must be validated for compatibility CS 1000E will be HA split between the two providers data centers New sites will be added in the future with Survivable Media Gateways This information is gathered in detailed design sessions with the customer What is required in data infrastructure to support? HSP - 20 mbps dedicated bandwidth with 30ms roundtrip has been discussed and customer believes there existing infrastructure will support this requirement ELAN traffic will be determined once configurations are finalized Additional Data port requirements will also be calculated when configurations are finalized Customer does want to use Dual Homing feature from all MGC s which will require Data Network Redundancy and Design to facilitate This information is critical to success and customers must fully be aware of infrastructure requirements This information is gathered NN Standard Release October 2008

34 34 Case Studies through discovery of existing network architecture, Enterprise Configurator (EC) reports for ELAN signaling bandwidth, Bandwidth calculator outputs, voice traffic studies and specific customer requirements What is the migration timeline/strategy? Migration Timeline is approx 18 months to move and convert users as specified Patient phones may exceed this timeline do to Bedside IP Terminal deployment What risks maybe present in decommissioning existing systems Discussions have been had clarifying that these systems will be open ended decommissioned How will database be converted for multiple systems into a single system; what will be the impact? Hardware could fail and replacements may not be available, therefore the customer is planning to migrate all critical users first to minimize any risk The customer is also considering migrating one system first and then the other so both systems are not in a decommissioned state at the same time This information is imperative to ensure alignment of customer deployment expectations and equipment ordering and configuration This information is gathered in detailed design sessions with the customer In this case the channel partner has elected to consolidate the databases in their lab In a system consolidation or migration there are various ways to migrate databases In a single site example of an Option 11C to Cs1000E migration the database is automatically converted In a an example of an Option 61C to Cs1000E there is no automated database migration today Therefore database migrations and consolidations must be examined in detail during customer discovery sessions and design activities Nortel Professional Services can assist in database migrations to minimize project risk NN Standard Release October 2008

35 Case study 1 35 Proposed architecture for combined systems In this case study example it was determined through customer requirements, discovery sessions and architecture analysis that it was feasible for this customer to move to a centralized CS 1000E system This migration would consist of migrating existing Capital Investment in hardware and software to a new CS 1000E system Figure 11 "Case Study 1 proposed architecture part 1" (page 36) depicts the proposed solution and demonstrates the total license count in the new CS 1000E for both the core system and CallPilot In Figure 12 "Case Study 1 proposed architecture part 2" (page 36) the CS 1000E distributed HA system is shown The proposed solution allows the customer to split the Primary Call Servers between their two existing Data Center locations while providing gateway services to TDM clients and PSTN within each location The architecture also provides the customer with the ability to provide High Risk users redundancy through the conversion of TDM clients to IP allowing flexibility and mobility as their work environment dictates in normal or emergency situations The architecture also provides the ability for the health care provider to extend the system reach utilizing Survivable Media Gateways in other clinics and offices outside the core campuses The solution is based on the establishment of a new CS 1000E system with a complete load of transferred licenses, allowing the customer to migrate single or multiple users during their migration The CS 1000E system has been provisioned with the total of required licenses under the agreement that the existing systems will remain active for the negotiated transition period only This offering allows complete flexibility in the customers migration plans and allows crucial business elements to remain in service during the transition NN Standard Release October 2008

36 36 Case Studies Figure 11 Case Study 1 proposed architecture part 1 Figure 12 Case Study 1 proposed architecture part 2 NN Standard Release October 2008

37 Case Study 2 37 Case Study 2 The following case study represents an example of a multiple site location In this solution a town is requesting the consolidation of multiple PBX s into a centralized geographic redundant CS 1000E system The customer currently has an Option 81C system and multiple Option 11C systems in their network In planning this type of multiple system consolidation and migration it is imperative that the discovery steps discussed previously in this document are followed and discovery items are clearly documented Dial plan is typically the highest impact item in developing a feasible solution for this type of network due to the high probability that conflicting directory numbers exist Modification of the existing directory numbers takes careful planning in order to ensure a successful migration Another major item is planning the phases of the migration The phases should be planned to minimize disruption in user services for any length of time and should be logically staged The example below focuses on Phase planning, as discovery has been covered in earlier chapters and Case Study 1 Figure 13 "Existing architecture" (page 38) provides an overview of the existing architecture Figure 14 "Proposed Architecture" (page 39) provides an overview of the proposed architecture, which consists of a centralized CS 1000E HA system The two primary Call Servers are located at The Public Works Yard and Town Hall They are connected via the High Speed Pipe (HSP) and ELAN over the Town s Network Each remote site is provisioned with a Survivable Media Gateway ensuring standalone redundancy in the event of a network failure The two primary Call Servers are used to provide core processing redundancy, employing Survivable Media Gateways to maintain service in the event of any site connectivity loss or network failure NN Standard Release October 2008

38 38 Case Studies Figure 13 Existing architecture NN Standard Release October 2008

39 Case Study 2 39 Figure 14 Proposed architecture The Town s existing architecture consists of a single Option 81C system and 5 Option 11C systems These sites are not presently inter-connected with a private network but are configured to communicate with each other over the PSTN The high priority sites are City Hall, Public Works, Fire Station and Police In any proposal interruption to service should be limited to these locations There is a layer 2 connection between the Public Works site and City Hall as the Town currently uses this configuration to provide redundancy to crucial applications The remainder of the sites are connected using Layer 2 and Layer 3 network connections Phase 1: Establish CS 1000E core In assessing the customer architecture it has been determined that the migration to a CS 1000E system would start with the Public Works location Establishing the core CS 1000E system in this location ensures that all testing and functionality can be validated The Option 11C system will be migrated to an HA CS 1000E system and both processors will be initially installed in this location The existing Option 11C cabinets will be reused with new gateways added if required NN Standard Release October 2008

40 40 Case Studies Figure 15 Establish CS 1000E core Phase 1 includes the following steps: Migrate Public Works Option 11C to a CS 1000E Processors in standalone gateways as they will be re-deployed in the network 1 Processor to remain at Public Works 1 Processor to be redeployed to Town Hall Premium Software Re-use Digital, Analog line cards Maintain Existing PSTN connections and cards Processors initially installed side by side Figure 15 "Establish CS 1000E Core" (page 40) provides a graphic overview of Phase 1 Phase 2: Split CS 1000E core In Phase 1 the customer planned to distribute one of the Primary Call Servers to the Town Hall location after having installed a CS 1000E HA system at Public Works Phase 2 allows connectivity testing of the LAN and establishes a distributed Call Server configuration NN Standard Release October 2008

41 Case Study 2 41 Figure 16 Split CS 1000E core Phase 2 includes the following steps: Establish Network requirements for splitting CS 1000E Call Servers Move one call Server to Town Hall HSP (High Speed Pipe) between CS 1000E Call Servers Requires 20 mbps of Dedicated Bandwidth Less than 30ms roundtrip delay Less than 5% packet loss Phase 3: Water Works site conversion After having installed a CS 1000E HA system and distributing the Primary Call Servers, the customer can now deploy a Survivable Media Gateway to one of the non-critical sites This deployment again validates network connectivity and allows Town staff to become familiar with the redundancy and fail over mechanisms through failure simulation testing This phase is crucial in ensuring other more critical sites can be easily deployed and all components are fully understood by the IT department Phase 3 includes the following steps: Convert Water Works Site to a Survivable MG 1000E (SMG 1000E) Re-use line cards and PSTN NN Standard Release October 2008

42 42 Case Studies Figure 17 Water Works site conversion Establish Network Connectivity to support SMG 1000E Bandwidth to be calculated subject to voice traffic Less than 80ms roundtrip delay between Core and SMG 1000E Less than 5% packet loss Figure 17 "BMC Site Conversion" (page 42) provides a graphic overview of Phase 3 Phase 4: Library conversion With the primary Call Servers deployed and Survivable Media Gateway deployment understood the Town will next begin deploying the remaining sites In this phase the Library will be converted to an SMG Phase 4 includes the following steps: Convert Library to a Survivable MG 1000E Re-use line cards and PSTN Establish Network Connectivity to support MG 1000E Bandwidth to be calculated subject to voice traffic Less than 80ms roundtrip delay between Core and SMG 1000E NN Standard Release October 2008

43 Case Study 2 43 Figure 18 Library conversion Less than 5% packet loss Figure 18 "Library Conversion" (page 43) provides a graphic overview of Phase 4 Phase 5: Fire Station conversion With the Primary call servers deployed and several Survivable Media Gateway deployments completed the Town will now begin to convert their critical sites By installing the Primary Cores and several no critical locations the LAN functionality and system operation is fully understood by the IT department The Phasing of the critical sites also has ensured that emergency additions or changes to the critical sites has not been compromised based on de-commissioning rules involving migrations Phase 5 includes the following steps: Convert Fire Station to a Survivable MG 1000E Re-use line cards and PSTN Establish Network Connectivity to support MG 1000E Bandwidth to be calculated subject to voice traffic Less than 80ms roundtrip delay between Core and SMG 1000E NN Standard Release October 2008

44 44 Case Studies Figure 19 Fire Station conversion Less than 5% packet loss Figure 19 "Fire Station Conversion" (page 44) provides a graphic overview of Phase 5 Phase 6: Police conversion With the Fire Department SMG now deployed the Police department conversion can be executed A contingency plan to have Police calls go to the Fire Station during the cutover period was deployed to ensure critical services are maintained To accommodate the Police locations several IP sets were deployed in the Police Station to allow employees to remain at their location Several sets were also deployed at the Fire Station in case of a LAN failure during the outage period Phase 6 includes the following steps: Convert Main Police Site to a Survivable MG 1000E Re-use line cards and PSTN Convert Carrier Remote Site to an MG 1000E NN Standard Release October 2008

45 Case Study 2 45 Figure 20 Police conversion Establish network connectivity to support MG 1000E Bandwidth to be calculated subject to voice traffic Less than 80ms roundtrip delay between Core and SMG 1000E Less than 5% packet loss Figure 20 "Police Conversion" (page 45) provides a graphic overview of Phase 6 Phase 7: Town Hall CS 1000M conversion to MG 1000E With all remote sites now deployed the largest site Town Hall can be migrated into the CS 1000E architecture Cutover planning is crucial during this phase to limit the disruption to employees The Town planned several migrations moving separate departments in a series of cutovers The flexibility in moving these depended on inter-department communication requirements Move phases were also planned in conjunction with the various business groups NN Standard Release October 2008

46 46 Case Studies Figure 21 Proposed architecture Phase 7 includes the following steps: Convert Town Hall to MG 1000Es Maintain line and trunk cards Transfer CallPilot to CS 1000E Figure 21 "Proposed architecture" (page 46) provides a graphic overview of the migrated system architecture NN Standard Release October 2008

47 47 Quoting Introduction Quote Generation is completed after all discovery and design concepts are completed and agreed to by the customer Access to configuration tools is crucial in this step of a consolidation exercise The engineer must understand what quotes are required as in some cases normal EC practices may not cover specific ordering requirements The engineer will require various reports as discussed in earlier sections of this NTP to complete any quote activity Assistance for consolidation quotes can be obtained from the users designated Nortel Sales Engineer The following section outlines various steps in quoting which may vary based on specific customer requirements Quote generation Quote generation requires the completion of the following tasks: Generation of a New/Migration CS 1000E quote in EC Generation of Application Upgrade and expansion quotes in EC as required Before a quote can be generated, the following items are required: Access to EC to complete appropriate quotes New CS 1000E Application Upgrades or Expansions when using existing Applications OrderPro Summary and Detail reports KRS KRS Reports Miscellaneous NN Standard Release October 2008

48 48 Quoting Consolidated System information, diagrams etc for use during EC quote building CS 1000E new quote generation In order to generate a new/migration CS 1000E quote in EC: A new CS 1000E quote is configured using wired for to represent any re-usable cards if required All system or user licenses are quoted as upgrades or new If a New CallPilot is required for the consolidation it should be added to this quote Any new applications, Phones or any other items should also be added to this quote EC configuration considerations Use the following If/Then table for EC configuration considerations Building Locations according to the customer requirements If Then Consider Conference Services by Location or Regional Area Consider Local Music and RAN Provisioning for use by Location or Regional Geographic Area Equip Broadcast Licenses if none exist Equip Universal Trunk Ports if not equipped Configure network Music Components if Required Identify any existing RAN sources and ensure components are equipped accordingly Adding Telephony Manager current Consider Total Number of Users Consider billing Requirements including RTUs NN Standard Release October 2008

49 Quote generation 49 Configuring CallPilot Ensure Auto Attendants and Menus are considered for each site Local PSTN is being equipped Consider Local D Channel requirements Consider Clock Controller requirements Consider PRI Gateways in High density area s Consider Zone Based PSTN Access if required Ensure appropriate cards are Identified as Blocking or Non Blocking ACD Agents (IP or TDM), Trunking etc Data Switches for Component connection Nortel data switches can be quoted in EC as required Application upgrade and change quote generation Any applications that require expansion or upgrade must also be completed in EC Use the following If/Then table for any applications that require expansion or upgrade An existing CallPilot is being used for the target system If An existing OTM/TM is being used for the target system An existing AG1000/2000 is being used for the target system An existing HMS400 is being used for the target system An existing SCCS/CC6/SWCP is being used for the target system Then Upgrade to release 5 (or Leave at Supported Release) Add users and ports for Donor systems Application Upgrade to Telephony Manager current Add users and options for Donor systems An Application Upgrade quote will be required to add users for Donar systems An Application Upgrade quote will be required to add users and ports for Donor systems An Application Upgrade quote will be required to add users If CC6 corporate is required an SCCS Consolidation quote is necessary Note: Existing Application Compatibility to CS 1000 Release 5x must be validated NN Standard Release October 2008

50 50 Quoting NN Standard Release October 2008

51 51 Database migration Planning the migration Planning a multi-system database migration/consolidation involves careful planning around a number of system elements The following table provides a list of database migration tasks which must be considered and planned for Configuration Because there are no database migration tools available for multi-system database migration/consolidation, each task must be planned for and completed manually The table below provides examples of possible tasks/functions to consider when migrating a database Task/Function Impact Suggestions Customer Data Block Routes Serial ports/locations for maintenance, CDR, Traffic, etc devices, quantity/locations of Media Gateway Conferences packs Listed directory number(s), SPRE codes, options such as Call Park, etc Total re-design required as Common route numbers will exist at all sites - Broadcast MUS/RAN licenses will be required Minimize maintenance and service change ports, consider CDR at Survivable gateways - Zone based MGCONF to minimize WAN consumption Map to most common in consolidated systems - Add new routes as required for main system and gateways - Consider Survivability - Consider Zone based resources for RAN, Music, etc ESN Total re-design required - Consider Free-Calling Areas and routes at gateways in design - Consider access during survivability events - Consider Zone Based resources in design NN Standard Release October 2008