Vii 2

Staff Report #2
March 2, 2016
To All Commissioners
Re:
Technology Plan
Recommendation
The Commission APPROVE the Technology Plan as set out in Enclosure I, noting the Technology Plan is
congruent with the approved 2015-2018 Business Plan and associated 2015-2018 Financial Plan.
Background
The draft Technology Plan was approved in principle by the Commission at the January 25, 2016 meeting.
Subsequent to approval in principle, Task 3 of the plan was completed. Task 3 expanded upon the list of
priority items included in the draft plan. The technologies and activities that have been identified to be
addressed in the short to medium term include:
Addressing staff resource issues
Fixed route CAD/AVL enhancements
Specialized Scheduling and Dispatch System
Development of IT policies
Refresher training
Disaster recovery plan
Telephony system replacement business case
Interactive Voice Response system replacement business case
Radio way-forward business case
Server and storage infrastructure update
The tasks associated with the completion of each of the items set out above have been identified in the final
plan as well as the estimated costs and timelines associated with each task.
Steps are underway with respect to addressing the staff resource issues, it is anticipated that an additional IT
resource will be added to the complement by mid to late March.
The request for proposal for the replacement of the Specialized Scheduling and Dispatch system has closed
and bids are being assessed. Recommendation for contract award will be tabled at the March Commission
meeting. Subsequent to contract award, the project will begin, noting the implementation is anticipated to
take three to five months.
Given the pressing current storage and server needs associated with the Specialized Scheduling and
Dispatch system implementation as well as other upcoming needs, it should be noted that several of the initial
steps in Project D IT are already underway. Pilot VM/SAN platforms have already been researched and will
be installed in the near future.
Depending on the nature of the work involved with the remaining activities, they have either been included in
the final 2016 Work Program as set out in Staff Report #1, dated March 2, 2016, or will be addressed as part
of the day to day operation and implementation of the Technology Plan. Updates on progress will be
provided to the Commission via quarterly update reports or as specific reports depending on the nature and
extent of the update.
Enclosure
I Technology Plan
Recommended by:
Patrick Cormier
Manager of Information Services
Concurred in by:
Kelly S. Paleczny
General Manager
London Transit Commission

Technology Plan
Task 3: Technology Plan
Prepared for London Transit Commission

by IBI Group
February 24, 2016
IBI GROUP
LONDON TRANSIT COMMISSION TECHNOLOGY PLAN
Document Control Page

CLIENT:
PROJECT NAME:
London Transit Commission Technology Plan
REPORT TITLE:
London Transit Commission Technology Plan
IBI REFERENCE:
36814
VERSION:
ORIGINATOR:
2.0
J:\36814_LTC_Technolo\5.0 Design (Work) Phase\3.0 Technology
Plan\STR_TechnologyPlan_All_v2_2015-02-24.docx
D. Duong, M. Mandelzys; G. De Santis; M. Sawaf; S. McDermott
REVIEWER:
D. Parker; A. Leslie
AUTHORIZATION:
D. Parker
DIGITAL MASTER:
CIRCULATION LIST:
HISTORY:
February 24, 2016
0.1 Report Outline to Client............................................. 2016-01-21

0.9 Internal Draft ............................................................. 2016-02-19
1.0 Draft for Client Review .............................................. 2016-02-19
2.0 Final Consolidated Report ........................................ 2016-02-24
IBI GROUP
TASK 3 TECHNOLOGY PLAN (OUTLINE)
Table of Contents
1
Introduction ......................................................................................................................... 1
LTC Technology Vision ...................................................................................................... 2
Technology Plan ................................................................................................................. 5

3.1
Project A Fixed Route CAD/AVL Enhancements ................................................. 6
3.2
Project B Paratransit Scheduling and Dispatch .................................................... 7
3.3
Project C Strategies .............................................................................................. 7

3.3.1
Social Media Policy ..................................................................................... 8
3.3.2
Refresher Training ...................................................................................... 9
3.3.3
Open Data Policy ........................................................................................ 9
3.3.4
Security Plan ............................................................................................. 10
3.3.5
Disaster Recovery Plan ............................................................................ 11
3.4
Project D IT ......................................................................................................... 12
3.5
Project E Telephony............................................................................................ 15
3.6
3.5.1
VoIP Telephony System Upgrade ............................................................. 15
3.5.2
Interactive Voice Response (IVR) System ................................................ 16
3.5.3
Initial Actions ............................................................................................. 16
Project F Radio ................................................................................................... 17

3.6.1
3.7
Plan Summary ....................................................................................................... 18

3.7.1
Initial Deployment Actions ......................................................................... 18
3.7.2
Overall Future Vision................................................................................. 18
3.7.3
Project C Social Media ........................................................................... 20
3.7.4
Project C Open Data .............................................................................. 21
3.7.5
Project C Security Plan .......................................................................... 22
3.7.6
Project C Disaster Recovery Plan .......................................................... 22
Staffing............................................................................................................................... 23
Deployment Considerations ............................................................................................ 24

5.1
Deployment Steps and Actions .............................................................................. 24

5.1.1
February 24, 2016
Initial Actions ............................................................................................. 17
Concept of Operations and Business Case Stage ................................... 24

i
IBI GROUP
Table of Contents (continued)
5.2
5.1.2
Plans Stage ............................................................................................... 24
5.1.3
System Specifications Stage .................................................................... 24
5.1.4
Procurement Stage ................................................................................... 24
5.1.5
Implementation Stage ............................................................................... 25
Projects Costing ..................................................................................................... 26

5.2.1
Alternate Cost Scenarios .......................................................................... 27
5.3
Timelines and Capital Program Budgets ............................................................... 27
5.4
Staffing Phasing ..................................................................................................... 29
5.5
Regular Review of Technology Plan ...................................................................... 29
Appendix A Task 1: Existing Conditions and Needs Assessment

Appendix B Task 2: Technology Analysis
Appendix C Radio Technology Comparison
February 24, 2016
ii
IBI GROUP
Introduction
The London Transit Commission (LTC) has retained IBI Group to develop a Technology Plan
(herein known as the Plan). Various technologies deployed at LTC are approaching end-of-life
and LTC will need to decide whether to re-invest or migrate to newer systems. Additionally, the
Transit Technology and Information Technology landscape has seen significant advancements.
Hence, the Plan will assess how well current and available technology addresses LTC needs.
The work consists of the following three tasks:
Task 1: Existing Conditions and Needs Assessment documents existing technology

conditions and identifies LTC technology needs (Appendix A).
Task 2: Technology Analysis considers what gaps need to be addressed to enhance

technology relative to the identified needs, and available technologies that could be
deployed to do so (Appendix B).
Task 3: Technology Plan structures the selected technologies and activities into a
sequence of projects detailing timelines, capital/ancillary/operational costs, and
dependencies (present report).
This Task 3 report combines the findings from the Task 1 and Task 2 documents to establish a
framework for executing six project packages to improve LTC internal operations and delivery of
service to customers.
This report is divided as follows:
February 24, 2016
Section 2 presents a system concept that captures all technologies and activities
identified in the plan;
Section 3 describes each project package including key functionality and initial
deployment actions;
Section 4 highlights staffing considerations for supporting current and future

technologies. In particular, it looks at suggestions related to new hires and/or
outsourcing support models; and
Section 5 outlines the typical project deployment methodology and provides a proposed
implementation schedule for the next 5 years, with corresponding capital and operating
cost estimates for each year.
IBI GROUP
LTC Technology Vision
In Task 2, technologies and activities to address LTC needs were evaluated. The technologies
and activities were classified into categories based on priorities and costs, for (1) short to
medium term and (2) longer term.
Technologies and activities for short to medium term deployment include:
New Hires and/or Outsourcing;
Fixed Route CAD/AVL Enhancements;
Paratransit Scheduling and Dispatch Management Procurement;
Social Media Policies;
Refresher Training;
Regular Review of the IT Infrastructure and Strategic Plan;
Disaster Recovery Plan;
Telephony System Business Case;
IVR Business Case;
Radio Way Forward Business Case; and
Server and Storage Infrastructure Update.
Technologies and activities for longer term deployment include:
Centralized Data Warehouse & Business Intelligence; and
Yard Management System
Only technologies and activities for short to medium term deployment are evaluated in this
report.
Exhibit 1 and Exhibit 2 show the existing system vision diagram and short to medium term
deployment system vision diagram, respectively. The existing system vision diagram shows a
high level overview of all ITS, IT, telephony and communication systems currently existing or
being deployed at LTC. The future system vision diagram illustrates all new systems and also
shows where there will be change to existing systems, if applicable.
February 24, 2016
IBI GROUP
Exhibit 1 Existing System Vision
Traveller Information System
Central System (Highbury)
Paratransit On-board Systems
Voice
(Spectrum)
Online
Information
(WebWatch)
LTC Website
(WebWatch)
Crystal
Reporting
System
CAD/AVL
(Trapeze)
Central Video
Software
Radio
Console
Radio
(Spectrum)
GTFS Data
Feed
Scheduling and
Dispatch
Paratransit
(TransView)
Cellular
(Rogers)
Wayside
Dynamic
Signs
Maintenance
Management
System (Enrich)
Phone System
(Siemens HiPath)
Central System (Wonderland)
Fibre
(Bell)
CAD/AVL
(Trapeze)
On-Board
Cameras
(Seon)
Fare Collection
(GFI)
Security
Cameras (dvtel)
Phone System
(Avaya)
IVR (Ontira)
Radio
Workstations (Highbury)
Conventional Bus On-board Systems
LEGEND
** Deployed on new buses as purchased

CAD/AVL
(Trapeze)
APC**
On-board
Cameras
(Seon)
Smart Card
System (S&B)
TSP Emitters
(Opticom)
Routers (Digi)
Farebox
System (GFI
CENTSaBILL)
Radio Console
Existing
Existing, Requires
Reconfiguration or
Replacement
Being Deployed
Existing
Outsourced
February 24, 2016
Smart Card
System Oracle
Database (S&B)
Radio
Scheduling
and Dispatch
Back-up
Radio
Console
IBI GROUP
Exhibit 2 - Future Systems Vision
Voice
(Spectrum)
Online
Information
(WebWatch)
LTC Website
(WebWatch)
Crystal
Reporting
System
CAD/AVL
(Trapeze)
Central Video
Software
Radio
Console
On-Board
Computer
Radio
(Spectrum)
GTFS Data
Feed
Wayside
Dynamic Signs
Cellular
(Rogers)
Scheduling
Paratransit
IVR (Ontira)
GTFS Real
Time Data
Feed
Dispatch
Paratransit
Maintenance
Management
System (Enrich)
Phone System
(Siemens HiPath)
Fibre
(Bell)
Radio
CAD/AVL
(Trapeze)
On-Board
Cameras
(Seon)
Fare Collection
(GFI)
Security
Cameras (dvtel)
Phone System
(Avaya)
Smart Card
System Oracle
Database (S&B)
Alerts Data
Feed
LEGEND
Existing
Upgraded
CAD/AVL
(Trapeze)
TSP Emitters
(Opticom)
APC
On-Board
Cameras
(Seon)
Smart Card
System (S&B)
Routers (Digi)
Farebox
System (GFI
CENTSaBILL)
Radio Console
New
Existing
Outsourced
February 24, 2016
Radio
Scheduling
and Dispatch
Back-up
Field Systems
Portable
Smart Card
Readers
Radio
Console
Radio
or
WiFi
IBI GROUP
Technology Plan
The technologies and activities identified as for short to medium term deployment have been
grouped into six (6) project packages. Each is described in the following sections with specific
focus on:
Goals;
Technologies and Capabilities;
Benefits; and
Initial Deployment Actions.
For deploying most of the IT and transit technology projects, IBI Group recommends following
the System Engineering V model as illustrated in Exhibit 3.This methodology flows from
initiation of a project (i.e. business case derived from the Concept of Operations and High-level
Requirements), through establishing detailed system specifications, and on into deployment,
testing, and final close out.
Exhibit 3 System Engineering Life Cycle
Assessment
Business Case
Concept of Operations
Operations & Maintenance
High-Level Requirements
System Verification
Detailed Requirements
Definition
and
Decomposition
Subsystem Verification
High-Level Design
Detailed Design
Integration & Testing
Integration,
Verification,
and
Validation
Implementation
Time
The System Engineering V model supports traceability to business needs and system
requirements through all stages of project implementation and testing. For example, test plans
are reviewed against system specifications to verify that testing will demonstrate the deployed
system meets all requirements. The ultimate goal is to ensure that the system being deployed
meets the business needs as laid out in the business case.
The core underlying concept is that the upward steps in the integration, verification and
validation leg involve assessment that traces back to the system requirements (at the same
vertical level in the downward leg for definition and decomposition). So the initial integration
and testing assessment level traces back to the detailed design requirements, to assess that
the system was implemented in accordance with the design. But then a subsequent verification
assessment should assess whether the system addresses the business needs (as represented
by the higher level requirements).
February 24, 2016
IBI GROUP
By the time a project has progressed through to operations and maintenance the assessment
should be considering whether to update the original concept of operations to reflect the
evolution in business needs and the overall operational environment. An updated concept of
operations could then be used to reconsider the higher-level requirements, to determine whether
changes to the system implementation are warranted.
3.1
Project A Fixed Route CAD/AVL Enhancements
LTCs existing Trapeze TransitMaster Computer Aided Dispatch/Automatic Vehicle Location

(CAD/AVL) system was implemented in the late 2000s, with subsequent changes limited to
adding custom report functionality. The CAD/AVL system has improved operational control for
dispatchers. However, the large volume of real-time information creates challenges related to
prioritizing issues and also to responding consistently and optimally to the variety of events that
occur during transit operations.
Replacement of LTCs CAD/AVL system is not necessary at this time, and this project looks at
enhancing the existing system to more effectively utilize it. For example, the Trapeze Intelligent
Decision Support (IDS) system module includes newer functionality that incorporates real-time
and archived data to prioritize issues for dispatchers and
indicate predefined action plan steps for dispatchers to
follow in various situations.
Key Functionality
Prioritize information presented to dispatchers so

that high impact items are acted on first;
Recommend dispatch actions (e.g. short turns,

additional trips, detours) based on real-time data
and pre-defined business rules, to improve
service delivery;
Provide recommendations on actions to recover

from emergency situations; and
Document dispatcher actions and demonstrate

impacts (audit trails)
Initial Deployment Actions

Since the CAD/AVL system will not be replaced, initial actions would focus on investigating the
feasibility of acquiring this functionality from Trapeze via their IDS module.
More detailed fact finding (including a request for information and demonstrations from Trapeze)
would be undertaken to better understand the functionality available in the IDS module and
clarify pricing. Based on this, a business case would be developed to determine if projected
benefits justified the costs.
If yes, Trapeze could be contracted to provide, configure, and train LTC on the IDS module. The
contract would identify specific functionality required to be delivered so that Trapeze would be
accountable. A key IDS characteristic is providing a toolkit that enables an agency-specific
configuration to support a specifically selected set of situations. There will be key decisions on
which situations IDS should cover (at least initially) and on what configuration Trapeze would do
relative to in-house configuration by LTC or its consultants (which IDS also enables).
If no, the feasibility of other options for providing the functionality requested by LTC could be
investigated, such as integration with third party software using APIs.
February 24, 2016
IBI GROUP
3.2
Project B Paratransit Scheduling and Dispatch
LTC is currently deploying a paratransit scheduling and dispatch system to replace their existing
Enghouse Transportation TransView software. The scheduling and dispatch system will enable
LTC and its contracted service provider(s) to manage, schedule, and dispatch specialized transit
services with high efficiency (in light of the continuous growth in demand for these services).
This project is currently in the procurement stage.
The new system will address a number of existing software limitations, in particular related to
minimizing manual effort in trip booking, scheduling and auditing, as well as for enabling easier
customer booking and improved vendor support.
Key Functionality
Track clients during the registration process through to acceptance;
Real-time trip booking;
Phone and internet trip management;
Integration with conventional transit to support multi-modal trip booking;
Automated manifest creation, with physical and electronic distribution;
Predefined and ad-hoc report capabilities;
Vehicle tracking; and
Live manifest updates and text communications to/from vehicles

Requirements for this system have already been defined and the procurement is underway.
Next steps for this project are to select and contract with a preferred vendor, followed by moving
forward with implementation.
3.3
Project C Strategies
This project packages together developing organizational policies and plans including:
Social Media Policies;
Refresher Training;
Open Data Policies;
Security Plan; and
Disaster Recovery Plan.
Developing and implementing these plans and policies will directly affect the use of certain IT
and transit technologies that support LTC operations, and user responsibilities. Specific systems
affected by each policy are identified in each section below, and illustrated in the diagrams of
Section 3.7.
February 24, 2016
IBI GROUP
3.3.1
Social Media Policy
The objective of Social Media Policy is to provide another channel where LTC can reach out to
to keep riders better informed. Social media also helps target a younger demographic.
Key Functionality
As part of Social Media Policy development, the following areas should be considered:
What is the overarching goal for use of social media?
Who is the target audience?
Which social media channels will LTC use?
What is the purpose of the communications?

o
Will communications be made for service announcements?
Will route-specific delays over a certain threshold be communicated? And what

would the appropriate threshold be?
Will communications be made for general information?
What will the communication schedule be?
How will LTC promote its social media channels?
Who will generate the communications for LTC social media channels?
How will communication format and content be standardized? Both for all
communications on a single channel, and with communications disseminated through
other means.
Affected Technologies and User Groups

The list of technologies and user groups affected by Social Media Policies will be addressed in
the final definition of policies. Technologies and user groups potentially affected are illustrated in
Exhibit 7 and listed below:
February 24, 2016
CAD/AVL System;
Real time customer information feeds;
Dispatchers; and
Customer service personnel.
IBI GROUP
3.3.2
Refresher Training
This sub-project will formalize the lunch-n-learns that LTC is already undertaking to maintain
user proficiency. We recommend that LTC consider including Training Voucher options as part
of future technology deployment projects. Training Vouchers will allow LTC to bring in their
vendors to perform additional training as required. Additionally many vendors offer online
webinars and host user conferences for customers, which can be leveraged as part of the
refresher training plan.
Key Functionality
What would be the format, frequency and duration of the lunch-and-learns?
How would staff proficiency be gauged before and after?

o
Currently Survey Monkey is used for self-assessment
What types of systems would LTC train their staff on using the lunch-n-learn approach?
Will lunch-n-learns be open to all? Or will enrollment eligibility be governed by a list for
each topic/subject area?
Which vendors provide online webinars? Which LTC staff should attend these
sessions? How frequently should they attend?
Should LTC be attending product user conferences? If yes which staff should be
attending the conferences, of which vendors and at what frequency?

Refresher Training would be essential for all systems existing at LTC and hence all systems
would be affected by the strategy.
3.3.3
Open Data Policy
Open Data can be freely used, re-used and redistributed by anyone without restrictions.
Generally this information is made available in a consistent documented structure and is
machine readable to facilitate open use.
For transit agencies open data most commonly refers to schedule data, system usage data (e.g.
ridership), and real time data (e.g., vehicle location, predicted stop arrival times, service alerts).
Not all agency data should or can be shared openly (e.g. employee personal information).
Many government organizations and transit agencies have published open data polices that
could be used as a starting point for LTC to develop their own.
Key Functionality
The following areas need to be considered in creating LTCs Open Data policy:
Who is the target audience (e.g. app developers)?
What data will be provided?
What are the data sources?
Conventional CAD/AVL (GTFS-realtime feed)?
Conventional Scheduling (GTFS export)?
In what format will the public get this information (e.g., XML, GTFS-realtime)?
o
February 24, 2016
How will LTC create the feed from its multiple data sources?
How frequently is each type of data updated?
IBI GROUP
Do users have to agree on an open licence agreement? Do users have to be

registered? This is especially important for frequently updated (real time) data, since it
allows LTC to limit data usage to limit abusive data requests that can interfere with use
by others.

The list of technologies and user groups affected by Open Data Policies will depend on their final
definition. Technologies and user groups potentially affected are illustrated in Exhibit 8 and
listed below:
CAD/AVL System;
Real time customer information feeds;
GTFS static data feed; and
Customer service personnel.
3.3.4
Security Plan
A security plan will define a minimum set of security controls to protect information systems. The
plan will allow LTC to understand its security vulnerabilities, system owners, and mitigation
strategies.
Key Functionality
The following areas should be considered when drafting the security plan:
What are LTCs IT assets? This can be initially derived from the three Technology Plan
deliverables
Perform an IT security risk assessment. This should include a table top exercise on
scenarios (e.g. virus, hacking, physical damage, mistakes by personnel that affect the
system).
Prioritize IT systems. Which systems are critical to LTC operations?
Who is the system owner? Who will be responsible for managing issue resolution?
Develop the appropriate precautions. How will LTC protect its assets from the identified
risks (e.g. access controls)?
Possible remedial steps:

o
Changing passwords where default passwords are used
Eliminating shared User IDs each person should login with their own
Implementing User Access Control and logging of system access
Tightening security policies implemented on firewalls
Implement change management discipline to prevent unauthorized system

changes

A Security Plan for all IT systems would be adopted during this project, which in turn would
affect all systems in the vision diagram.
February 24, 2016
10
IBI GROUP
3.3.5
Disaster Recovery Plan
The Disaster Recovery Plan (DRP) would encapsulate all the necessary information to help LTC
maintain operations after a disaster event, in some capacity. The DRP should be written to
enable LTC to restore critical systems even without an IT user on hand.
Key Functionality
The following are areas that need to be considered during development of the DRP:
Define the scope of the DRP.
Define the Disaster Recovery Teams and Responsibilities, including but not limited to:
o
Disaster Recovery Lead, responsible for all decisions related to the DR efforts;
Disaster Recovery Management Team, responsible for overseeing the DR

process;
Facilities Team, responsible for the physical facilities that house IT systems;
Applications Team, responsible for ensuring that all critical enterprise

applications operate during a disaster; and
Communications Team, responsible for all communications during a disaster.
Organizational processes for dealing with a disaster (i.e., steps to be followed).
List and rank all IT system, to identify which are mission critical and may need to be
supported by a Disaster Recovery (back-up) site
Describe steps to achieve active back-up sites for all critical systems
Describe steps to achieve the ability to restore all IT functionality for all systems
Distinguishing between redundancy and high availability.
Encompassing Disaster Recovery as a system solution for high availability, and also as
processes to work-around system unavailability.
Defining the RTO and RPO for each critical application:

o
RTO Restore Time Objective how long can pass before application recovers
RPO Restore Point Objective how much data can be lost while app recovers

The Disaster Recovery Plan will need to encompass all IT systems. Though only critical
systems may require mirroring in a Disaster Recovery site, all systems need to be evaluated
through plan development to establish which require this and which do not.
February 24, 2016
11
IBI GROUP
3.4
Project D IT
In the pursuit of delivering safer and more efficient service to customers, LTC has or is
continuing to deploy additional supportive technologies. These include scheduling, dispatching,
automatic passenger counting, automated announcements, and maintenance systems. In the
current generation IT and transit technology deployments the central system for each application
and database is generally tied to distinct hardware (see Exhibit 4).
Exhibit 4 Example of an older CAD/AVL IT deployment model
Clients
Admin
LTC Network
APP
Real-time
CAD/AVL
server
OS
APP
Public
Info
Server
APP
OS
Reporting
server
OS
LTC Network
Real-time Database
Reporting Database
The older model for IT and transit ITS deployments is generally referred to as 3-tier
(workstations, applications, databases). This is not an optimal use of support personnel and
physical IT resources. Server infrastructure is often underutilized and the ability to change the
database resource configuration quickly is limited. Many agencies spend a large portion of their
IT resources maintaining such legacy systems.
Virtualization technology allows multiple servers or databases to be consolidated as multiple
virtual machines (VM) on each physical server. This model allows the same number of systems
to be deployed on fewer physical servers. Storage Area Networks (SAN) similarly allowed a pool
of storage on the network to used in a flexible manner by multiple servers. Exhibit 5 shows an
example of a CAD/AVL system deployment using a VM/SAN model.
VM technology will allow LTCs IT department to optimize the utilization of physical IT resources
by applications servers and databases, based on the real-time needs of each individual
application. CPU, memory, storage, and I/O devices can be dynamically shared between
different VM application servers and databases. Database sizes can be easily adjusted as
needs grow. There will also be an overall reduction of physical hardware, since when each
application server or database has dedicated physical hardware each much have dedicated
spare capacity while in a VM/SAN model access to the spare capacity can be shared. Such
VM/SAN infrastructure can also be designed for redundancy (i.e., with cold back-ups or mirrored
VMs/storage on distinct physical hardware).
February 24, 2016
12
IBI GROUP
Key Requirements
Define and deploy the physical and software infrastructure going forward (e.g.,
enterprise servers and storage hardware, VM and VM/SAN software) to support LTCs
shift towards virtualization;
Put-in place mechanisms to specify virtualization requirements for each future LTC
project; and
Consider vendor hosted VM/SAN solutions for future projects, where it makes sense.
Exhibit 5 Example of a CAD/AVL VM deployment model
Clients
Admin
LTC Network
Reporting server
Real-time
CAD/AVL
server
APP
APP
APP
OS
OS
OS
Public
Info
Server
Virtualization SW
LTC Network
Real-time
Database
Reporting
Database
VM/SAN
February 24, 2016
13
IBI GROUP

LTC should develop a Concept of Operations (ConOps) and business case, to define high-level
requirements for the VM/SAN infrastructure and justify funding this endeavor. Some
considerations that will need to be reflected in requirements for future projects include:
Application virtualization software environment requirements: Primary vendors for

application virtualization software are VMware vSphere, Microsoft Hyper-V, and Citrix
XenServer.
Virtualized storage environment requirements: Solutions for storage virtualization

include VMwares Virtual SAN and Microsofts Clustered Storage Spaces.
Enterprise (host) VM-aware server and storage hardware requirements.
Virtual Machine monitoring and management tools requirements, based on identifying

LTC monitoring and management requirements.
The first step for developing the ConOps would be a detailed inventory for the current state of
the IT system. This would include reviewing all system documentation and interviewing LTC
stakeholders. The primary purpose of the review will be to identify gaps in the current system
and stakeholder needs. Gaps would be used to identify and quantify potential benefits that can
be achieved through an IT system upgrade.
The second step for developing the ConOps would be a technology review. Each of the
technologies and technical considerations identified above would be evaluated based on
estimated costs and ability to meet stakeholder needs. The technology review would also
provide an opportunity to refine benefit estimates based on the capabilities of each technology.
High level system specifications would be created based on the needs and gaps identified
through these preparatory steps. These specifications would constitute the core of the ConOps,
and enable developing preliminary implementation and migration plans.
The ConOps will feed into the later stages of the IT infrastructure deployment, as shown in
Exhibit 3.
Costs and benefits identified in developing the ConOps would be used to create a benefit cost
analysis for the business case backbone. The business case would help establish if the benefits
justify the costs.
With a positive business case, LTC could continue with procuring an updated IT system based
on the implementation plan identified in the ConOps.
Without a positive business case, the feasibility of other projects identified in this plan should still
be evaluated through developing their business case and ConOps. The business case for this
particular project would be periodically revisited when the Technology Plan is being updated,
Evolving needs and technology options may make the project feasible in the future.
February 24, 2016
14
IBI GROUP
3.5
Project E Telephony
This project includes steps towards evaluating and possible implementing a Telephony System
Replacement, and an IVR Replacement.
3.5.1
VoIP Telephony System Upgrade
A ConOps and business case for upgrading the LTC telephony system to a Voice over Internet
Protocol (VoIP) based system will provide information needed for deciding whether to proceed
with the procurement. VoIP systems provide several benefits over traditional telephony systems
including but not limited to:
IP based multimedia applications to improve the user experience;
Integration with multiple messaging systems (e.g. e-mail, SMS, voicemail) through a
unified interface to improve productivity;
Lower phone service costs;
Easier maintenance;
Built-in disaster recovery and business continuity capabilities; and
Feature rich functionality, such as caller ID and taking calls using workstations.
The ConOps should consider Private Branch Exchange (PBX) and Session Initiation Protocol
(SIP) Trunking systems. All VoIP technologies enable communication among multiple physical
offices/sites connected over the internet, making telephony reliant on sufficient and reliable
internet connectivity for each site.
PBX systems can be deployed on premise or hosted remotely, and provide dedicated hardware
maintained by the agency or service provider. Generally Hosted PBX solutions have
considerably lower capital costs, and provide built in disaster recovery and business continuity
capabilities.
SIP systems offer the features available from PBX systems with the added ability to channel
multiple forms of media (e.g., voice, text, video), through a single connection. These systems
provide for more flexible configuration and greater bandwidth efficiency.
February 24, 2016
15
IBI GROUP
3.5.2
Interactive Voice Response (IVR) System
Currently the LTC IVR server provides a single point of failure, a concern for the reliability of this
customer facing system. Additionally LTC generally has difficulty receiving responses from the
current IVR vendor. Improving the reliability and redundancy of the IVR system would be the
primary point of evaluation for a new IVR system. However, this would also provide an
opportunity to evaluate expanded IVR functionality.
Three IVR architectures should be considered as part of the ConOps:
On premise solution;
Hosted solution; and
Incorporated into new VoIP telephony system.
3.5.3
Initial Actions
The first step for developing the ConOps would be a detailed inventory of the current state of the
telephony system. This would include reviewing all system documentation and interviewing LTC
stakeholders. The primary purpose of this review will be to identify gaps in the current system
and stakeholder needs. Gaps would be used to identify and quantify potential benefits that can
be achieved through a telephony system upgrade.
The second step for developing the ConOps would be a technology review. Each technology
discussed above would be evaluated based on estimated costs and ability to meet the identified
needs. The technology review would also provide an opportunity to refine benefit estimates
based on the capabilities of each technologies. Evaluation of VoIP technologies should be
coordinated with developing business continuity and disaster recovery plans, as the telephony
system will be integral to these plans.
High level system specifications would be created using the needs and gaps identified in the
current state inventory and information gathered in the technology review. These specifications
would constitute the core of the ConOps, and enable developing preliminary implementation and
migration plans.
The ConOps will feed into the later stages of IT infrastructure deployment, as shown in Exhibit
3.
Costs and benefits identified during ConOps development would be used to create a benefit cost
analysis providing the business case backbone. The business case would be used to determine
if benefits justify the costs.
If yes, LTC could continue with procuring an updated Telephony and IVR systems based on the
implementation plan identified in the ConOps.
If no, the feasibility of other projects identified in this plan could be evaluated through developing
a business case and ConOps. The business case for this project would be periodically revisited
when the Technology Plan is updated, as evolving needs and technology options may make the
project feasible in the future.
February 24, 2016
16
IBI GROUP
3.6
Project F Radio
This project looks at possible replacement of the radio system and the general way forward. The
current Tait 400MHz radio system is meeting LTC needs, and with excess voice traffic capacity.
Immediate action is not required. However, the radio system will be nearing end of life within five
years and a way forward plan is required. This report outlines the steps for evaluating the way
forward through developing a ConOps and business case as the radio system nears its end of
life. The ConOps would consider future data/voice needs, and other actions such as moving to a
trunked system and adding a second antenna site to address minor coverage issues.
Additionally it should consider the feasibility of moving to a newer radio technology such as:
P-25;
DMR; and
TETRA.
3.6.1
Initial Actions
The first step for developing the ConOps would be a detailed inventory of the current state of the
radio system. This would include reviewing all system documentation and interviewing LTC
stakeholders. The primary purpose of this review will be to identify gaps in the current system
and stakeholder needs. Gaps identified through this process will be used to identify and quantify
potential benefits that can be achieved through a radio system upgrade.
The second step for developing the ConOps would be a technology review. A preliminary
technology review has been conducted (included as Appendix C). Further work would be
required to expand this analysis to include cost estimates, and to refine benefit estimates.
High level system specifications would be created using the needs and gaps identified in the
current state inventory and the information gathered in the technology review. These
specifications would constitute the core of the ConOps and enable developing preliminary
implementation and migration plans.
The ConOps feeds into the later stages of the IT infrastructure deployment, as shown in Exhibit
3.
Costs and benefits identified developing the ConOps would be used to create a benefit cost
analysis providing the business case backbone. The business case would be used to determine
if benefits justify the costs.
If yes, LTC could continue with procuring an updated radio system based on the implementation
plan identified in the ConOps.
If no, the feasibility of other projects identified in this plan could be evaluated through the
development of a business case and ConOps. The business case for this project would be
revisited periodically when the Technology Plan is updated, as evolving needs and technology
options may make the project feasible in the future.
February 24, 2016
17
IBI GROUP
3.7
Plan Summary
This section summarizes the projects described in sections 3.1 to 3.6 using updated system
vision diagrams. The summary is presented from two perspectives: (1) summary of all future
hardware systems, and (2) summary of systems affected by implementing the strategies in
Project C.
Separate vision diagrams have not been provided for the following strategies, which would need
to consider and would likely affect all systems identified within the vision diagrams:
Refresher Training;
Security; and
Disaster Recovery.
3.7.1
The initial actions needed will serve to start developing the strategies, which would include:
Confirm the initial scope of strategies to be addressed (e.g., social media policies,
refresher training, open data, security plan, and disaster recovery plan).
o
Would LTC like to pursue addressing more policy and strategy related areas?
Consider combining this with an analysis of what peer agencies have in-place
(i.e., best practices).
Interview key internal stakeholders for high-level needs

o
Due to interconnections between strategies (e.g., Security Plan and Disaster

Recovery; Open Data and Social Media Policies) these interviews can be
structured in a consolidated manner to reduce the total time needed (versus
interviewing separately for developing every individual policy/strategy)
Develop each policy/strategy
Adjust the Technology Plan, if needed, to account for needed supporting IT or transit
technology updates or new projects, if needed to implement policies or strategies
During the scoping of this project package, development for some of these policies/strategies
could be deferred at LTC discretion.
3.7.2
Overall Future Vision
Exhibit 6 below illustrates LTCs future system vision that will be reached after implementing
Project A, Project B and Project C. Project D will not affect the system vision diagram. Projects E
and F were not included as part of the future vision diagrams as they currently are in the process
of evaluation and a decision to proceed with the projects in the future has not been made yet.
February 24, 2016
18
IBI GROUP
Exhibit 6 - Hardware Future System Vision
Voice
(Spectrum)
Online
Information
(WebWatch)
LTC Website
(WebWatch)
Crystal
Reporting
System
CAD/AVL
(Trapeze)
Central Video
Software
Radio
Console
On-Board
Computer
Radio
(Spectrum)
GTFS Data
Feed
Wayside
Dynamic Signs
Cellular
(Rogers)
Scheduling
Paratransit
IVR (Ontira)
GTFS Real
Time Data
Feed
Maintenance
Management
System (Enrich)
Dispatch
Paratransit
Phone System
(Siemens HiPath)
Fibre
(Bell)
Radio
CAD/AVL
(Trapeze)
On-Board
Cameras
(Seon)
Fare Collection
(GFI)
Security
Cameras (dvtel)
Phone System
(Avaya)
Smart Card
System Oracle
Database (S&B)
Alerts Data
Feed
LEGEND
Existing
Upgraded
CAD/AVL
(Trapeze)
TSP Emitters
(Opticom)
APC
On-Board
Cameras
(Seon)
Routers (Digi)
Farebox
System (GFI
CENTSaBILL)
New
Existing
Outsourced
February 24, 2016
19
Smart Card
System (S&B)
Radio
Scheduling
and Dispatch
Back-up
Field Systems
Radio Console
Portable
Smart Card
Readers
Radio
Console
Radio
or
WiFi
IBI GROUP
3.7.3
Project C Social Media
Exhibit 7 below identifies all systems to be affected by implementing the Social Media policy.
Exhibit 7 - Social Media Policy Future System Vision
Voice
(Spectrum)
Online
Information
(WebWatch)
LTC Website
(WebWatch)
Crystal
Reporting
System
CAD/AVL
(Trapeze)
Central Video
Software

Radio
Console
Radio
(Spectrum)
On-Board
Computer
GTFS Data
Feed
Wayside
Dynamic Signs
Cellular
(Rogers)
Scheduling
Paratransit
IVR (Ontira)
GTFS Real
Time Data
Feed
Dispatch
Paratransit
Maintenance
Management
System (Enrich)
Phone System
(Siemens HiPath)
Fibre
(Bell)
CAD/AVL
(Trapeze)
On-Board
Cameras
(Seon)
Fare Collection
(GFI)
Security
Cameras (dvtel)
Radio
Phone System
(Avaya)
Smart Card
System Oracle
Database (S&B)
Alerts Data
Feed
LEGEND
Existing
CAD/AVL
(Trapeze)
TSP Emitters
(Opticom)
Radio
APC
On-Board
Cameras
(Seon)
Smart Card
System (S&B)
Routers (Digi)
Farebox
System (GFI
CENTSaBILL)
Radio Console
Scheduling
and Dispatch
Back-up
Upgraded
New
Affected by
Policy
Existing
Outsourced
February 24, 2016
20
Field Systems
Portable
Smart Card
Readers
Radio
Console
Radio
or
WiFi
IBI GROUP
3.7.4
Project C Open Data
Exhibit 8 below identifies all systems to be affected by implementing the Open Data policy.
Exhibit 8 - Open Data Policy Future System Vision
Voice
(Spectrum)
Online
Information
(WebWatch)
LTC Website
(WebWatch)
Crystal
Reporting
System
CAD/AVL
(Trapeze)
Central Video
Software
GTFS Data
Feed
Wayside
Dynamic Signs
On-Board
Computer
Radio
(Spectrum)
Cellular
(Rogers)
Scheduling
Paratransit
IVR (Ontira)
GTFS Real
Time Data
Feed
Radio
Console
Dispatch
Paratransit
Maintenance
Management
System (Enrich)
Phone System
(Siemens HiPath)
Fibre
(Bell)
CAD/AVL
(Trapeze)
On-Board
Cameras
(Seon)
Fare Collection
(GFI)
Security
Cameras (dvtel)
Radio
Phone System
(Avaya)
Smart Card
System Oracle
Database (S&B)
Alerts Data
Feed
LEGEND
Existing
CAD/AVL
(Trapeze)
APC
On-Board
Cameras
(Seon)
Routers (Digi)
Farebox
System (GFI
CENTSaBILL)
Smart Card
System (S&B)
Radio
Scheduling
and Dispatch
Back-up
Upgraded
TSP Emitters
(Opticom)
New
Affected by
Policy
Existing
Outsourced
February 24, 2016
21
Field Systems
Radio Console
Portable
Smart Card
Readers
Radio
Console
Radio
or
WiFi
IBI GROUP
3.7.5
Project C Security Plan
A Security Plan for all IT system will be adopted during this project and will in turn affect all systems in the vision diagram.
3.7.6
Project C Disaster Recovery Plan
The Disaster Recovery Plan is critical to the operation of the agency during disaster times. The systems affected by the policy are identified in Exhibit 9.
Exhibit 9 - Disaster Recovery Plan Future System Vision
Online
Information
(WebWatch)
LTC Website
(WebWatch)
CAD/AVL
(Trapeze)
Crystal
Reporting
System
Voice
(Spectrum)
Central Video
Software
GTFS Data
Feed
Wayside
Dynamic
Signs
On-Board
Computer
Radio
(Spectrum)
Cellular
(Rogers)
Scheduling
Paratransit
IVR (Ontira)
GTFS Real
Time Data
Feed
Radio
Console
Dispatch
Paratransit
Maintenance
Management
System (Enrich)
Phone System
(Siemens HiPath)
Fibre
(Bell)
Radio
CAD/AVL
(Trapeze)
Security
Cameras
(dvtel)
Fare Collection
(GFI)
On-Board
Cameras (Seon)
Phone System
(Avaya)
Smart Card
System Oracle
Database (S&B)
Alerts Data
Feed
LEGEND
Existing
CAD/AVL
(Trapeze)
APC
On-Board
Cameras
(Seon)
Routers (Digi)
Farebox
System (GFI
CENTSaBILL)
Radio
Scheduling
and Dispatch
Back-up
Smart Card
System (S&B)
Upgraded
TSP Emitters
(Opticom)
New
Affected by
Policy
Existing
Outsourced
February 24, 2016
22
Field Systems
Radio Console
Portable
Smart Card
Readers
Radio
Console
Radio
or
WiFi
IBI GROUP
Staffing
This section reviews LTC staffing needs, currently and associated with future projects
implementation. In particular, it looks at suggestions related to a new hire and/or outsourcing to
support LTC. Currently LTC has one full-time management employee and one full-time
supporting IT employee, for operations and project deployments. As the number of systems has
increased; including the current deployment of Smart Card and Paratransit Scheduling and
Dispatch systems, it is no longer possible to support systems at the desired level with existing
resources.
Shortfalls in system support include the lack of a hardware replacement schedule, the lack of a
complete system architecture representation, and the inability to keep up with regular server
maintenance. Increased resourcing would allow LTC to improve in these areas. Maintaining a
hardware lifecycle replacement schedule would reduce unplanned downtime. Maintaining a
system architecture representation would reduce the required effort for integrating new systems.
Performing regular server maintenance would generally improve system performance.
An initial step has been made to address the resource gap by hiring for a new full time position.
This position is expected to be filled by the end of the first quarter 2016. As the technologies
identified in the Plan are implemented additional full time support may be required.
In addition to ongoing maintenance considerations, there are one-time costs associated with
implementing new systems and developing additional plans. Examples of the work associated
with these efforts includes: developing detailed system specifications, drafting requests for
proposals, bid assessment; and implementation assistance. One-time effort is more difficult to
address with a full time position and we recommend this type of work continue to be outsourced
as required.
February 24, 2016
23
IBI GROUP
Deployment Considerations
5.1
Deployment Steps and Actions
This section provides an overview of a typical methodology for technology deployments. Actual
tasks required during each stage will vary based on the technology involved. This methodology
is divided into four stages: ConOps and Business Case; Planning; Procurement; and
Deployment. Specific tasks associated with each stage are discussed in further detail below.
5.1.1
Concept of Operations and Business Case Stage
The ConOps and business case stage will determine if the benefits of a potential project justify
costs, and facilitate budget approval for each justified technology project. Generally this stage
will involve detailed review of LTCs current state (e.g. processes and systems) and an
assessment of needs and gaps. This information will be used to develop a benefit-cost analysis
of technology options, a system ConOps (e.g. changes to the current process) and a high-level
implementation plan. Each business case will be assessed as to whether it is justifiable to move
forward with system procurement.
5.1.2
Plans Stage
Some projects are actually to develop new plans (see Section 3.3: Project C Strategies) or
update existing plans (see Section 5: Regular Review of Technology Plan). These plans may
eventually feed back into the ConOps and Business Case Stages since new projects could arise
from their development.
5.1.3
System Specifications Stage
Thorough planning will ensure LTC procures systems that meet the needs of all stakeholders.
Tasks will include: specifications development and RFP packaging.
Detailed functional/performance and deployment process specifications will form the core of
each contract between LTC and a vendor. It is essential these specifications be comprehensive
and concise. Specifications development will require input from all LTC stakeholders to use or
maintain the new system. Specifications should be functional/performance oriented to facilitate
testing during the implementation stage.
Front end and contractual material will be combined with the specifications as part of this task to
create the overall RFP package for release to the vendor community, working in collaboration
with LTC Procurement. We recommend the best value procurement approach for deploying
technology systems, as the state of the practice approach among transit agencies.
5.1.4
Procurement Stage
The procurement stage will facilitate selecting the most appropriate commercially available
solution for LTC needs. This stage may include a pre-proposal conference to discuss the project
with potential proposers, as well as to address questions about the RFP and procurement
process.
Proposals once received will be evaluated against criteria defined in the RFP. This initial
evaluation stage may be supplemented using shortlist interviews with top ranked proposers, and
the evaluation process will ultimately conclude with selection of a preferred proposer. Once a
preferred proposer is selected, contract negotiations will begin to finalize all aspects of the
contract including specifications, costs, and the terms and conditions.
February 24, 2016
24
IBI GROUP
5.1.5
Implementation Stage
The implementation stage will commence after the contract is signed and conclude with final
system acceptance. Primary tasks include design review, testing, and installation.
During the design review the contractor will finalize documentation that explains how the system
will operate and meet the contract requirements. System configuration and required
development will also be defined as part of this task.
Testing will involve the contractor demonstrating that the installed system meets contract
requirements. There will be multiple testing stages throughout the implementation period. The
specific testing stages required will vary with the nature of the system. Typically systems with
equipment installed on the vehicle will have a Factory Acceptance Test (pre-installation
integrated testing), a Mini-Fleet Test (small scale post-installation integrated testing), and a
System Acceptance Test (full scale integrated testing). All testing stages use test procedures
agreed in advance that are also mapped to which contract requirements they serve to
demonstrate.
Factory Acceptance Tests are performed (usually at a contractor facility since this step occurs
pre-installation) to provide LTC with confidence the system is ready for installation.
Mini-Fleet Tests are performed on LTC premises after some initial small scale portion of the
system is installed, intended as a microcosm of the full scale system. In practice this usually
means that the central system is installed as well as a representative portion of wayside and
onboard equipment. The purpose of this testing stage is to provide LTC with confidence that the
rest of the installation seems ready to proceed.
System Acceptance Tests are performed after the system has been fully installed, to
demonstrate that the full required functionality is in place. Once System Acceptance Testing is
complete and all other key contract requirements have been demonstrated or delivered, the
Final System Acceptance is granted and the system contractual warranty period and other
ongoing vendor technical support begins.
February 24, 2016
25
IBI GROUP
5.2
Projects Costing
This section summarizes estimated costs for each project package. Some project packages could be terminated after the business
case, concluded as no-go based on the assessment. Project C may lead to new projects based on the plans developed, outside the
scope of this current plan development. No-go projects periodic reassessment and proceeding with additional projects resulting from
developing Project C plans would be revisited during the regular reviews of this Plan (see Section 5.5).
Exhibit 10 Estimated Costs
PROJECT
PLANS/BUSINESS
CASE COSTS
SYSTEM
SPECIFICATIONS
PROCUREMENT
IMPLEMENTATION
CLIENT-REP
COSTS
IMPLEMENTATION
CAPITAL COSTS
ANNUAL
OPERATING
COSTS
Project A: Fixed
Route CAD/AVL
Enhancement
$7,000
$10,000
$3,000
$21,000
$410,000
$20,0001
Project B:
Paratransit
Scheduling and
Dispatch
$25,000
$23,500
$14,500
$61,000
$480,000
$30,000
Project C:
Strategies
$68,500
N/A
N/A
N/A
N/A
N/A
Project D: IT
$11,500
$14,500
$8,000
$22,500
$260,0002
N/A
Project E:
Telephony/IVR
$11,000
$12,000
N/A
N/A
$200,0003
$12,000
Project F: Radio
$29,000
$23,000
$17,000
57,000
Regular Review
of Technology
Plan
$60,0006
N/A
N/A
N/A
N/A
N/A
Additional cost beyond existing warranty with Trapeze
Annual operating costs are factored into the hardware/software capital costs
The assumption is that this is hosted at LTC with the addition of the IVR option.
4,5
The deployment of the radio system falls outside of the 5-year horizon. The capital and annual costs for this project will be determined during the planning stages of
Project F
6
The Regular Review of the Tech Plan costs is over the course of the 5-year horizon (i.e. two [2] updates at $30,000 each)
February 24, 2016
26
IBI GROUP
5.2.1
Alternate Cost Scenarios
For Exhibit 10, it was assumed that deployments for Project D IT and Project E Telephony/IVR
are agency-hosted solutions. Generally, agency-hosted solutions have higher upfront capital
costs since infrastructure have to be installed. Projects D and E can both be vendor-hosted
solutions with little upfront capital cost, but will have recurring monthly costs. Exhibit 11 shows
the general recurring monthly costs range for vendor-hosted solutions.
Exhibit 11 Recurrent Monthly Costs for Projects D and E
PROJECT
Project D IT
Project E Telephony/IVR
MONTLY COSTS
$15,000 to $45,000
$40 $80 per line (user)
The recurring monthly costs for offsite hosted VM/SAN solutions (Project D) depends on the
complexity of the systems being hosted (e.g. how many application and database servers),
along with availability (uptime) and system performance requirements stipulated by LTC. A more
complex system and higher (stricter) thresholds for availability and system performance will both
increase the costs. Recurring costs for vendor-hosted Telephony/IVR systems depend on the
number of lines that LTC wants to open for its employees and the IVR subsystem.
Note, for Projects D and E, vendor-hosted solutions will be explored as options. This will feed
into the business cases that LTC will develop with consultant assistance.
5.3
Timelines and Capital Program Budgets
As discussed in Section 5.1 transit technology project deployment schedules are generally
divided into four stages: Concept of Operations and Business Case; Planning; Procurement; and
Implementation.
Exhibit 12 shows the projected project schedule and associated capital and maintenance costs
for the recommended deployment plan. The program has been designed to distribute the project
deployments in a relatively even manner over the 5 year duration, as summarized in the table
below. At no point are there more than 3 simultaneous projects in progress, with most years
having no more than 1-2 simultaneous projects. The Plan estimates average annual capital
expenditures of $375,000 (min $325,000 [Year 5]/max $443,750 [Year 1]), with ongoing
operational costs projected as approximately $56,000 per annum once all project packages
have been completed.
February 24, 2016
27
IBI GROUP
Exhibit 12: Project Implementation Schedule and Budgetary Plan
Project
Project A - Fixed Route CAD/AVL Enhancements
Project B - Paratransit Scheduling and Dispatch
Project C - Strategies
Project D - IT
Project E - Telephony/IVR
Project F - Radio
Regular Review of Technology Plan
Plans/Business Case
Costs
$7,000
$25,000
$68,500
$11,500
$11,000
$29,000
$60,000
System
Specifications
$10,000
$23,500
$14,500
$12,000
$23,000
Procurement
$3,000
$14,500
Implementation Project Capital Costs

Client-Rep Costs
(Implementation)
$21,000
$410,000
$61,000
$480,000
$8,000
$22,500
$17,000
$260,000
$200,000
$57,000
Total 5 Year Expenditure

$127,000.00
$125,500.00
$1,454,500.00
$168,500.00
$1,875,500.00
Capital Budget (Business Case or Plans)

Captial Budget (System Specification/Procurement)
Capital Budget (Implementation)
Operations and Maintenance
Total Budget
Stage
Business Case or Plans
System Specification Stage
Procurement Stage
Implementation Stage
Total Projects Underway
February 24, 2016
28
Operations and
Maintenance
$20,000
$30,000
$12,000
Year 1
Year 2
Year 3
Year 4
Year 5
Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4
4 1 2 3 3 3 0 0 0 0 0 0 0 0 0 0
2 3 3 3 3 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
4 4 4 4
0 0 0 0 0 0 0 0
4 4 1 1 2 2 3 3 3 3
0 0
4 4 1 2 3 3 0 0
4 1 1 2
4 4
4 4
Year 1
$0.00
$38,000.00
$405,750.00
$0.00
$443,750.00
0
0
1
0
1
Year 1
0 0
0 0
0 0
1 1
1 1
Year 2
$87,000.00
$13,000.00
$278,917.00
$22,500.00
$401,417.00
0
0
0
1
1
2
0
0
1
3
Year 2
1 2
1 0
0 1
0 0
2 3
Year 3
$0.00
$22,500.00
$287,333.00
$40,000.00
$349,833.00
2
0
0
1
3
0
1
0
1
2
Year 3
0 0
1 0
0 1
1 0
2 1
Year 4
$11,000.00
$12,000.00
$282,500.00
$50,000.00
$355,500.00
0
0
1
0
1
1
0
0
1
2
Year 4
1 0
0 1
0 0
1 1
2 2
Year 5
$29,000.00
$40,000.00
$200,000.00
$56,000.00
$325,000.00
0
0
1
1
2
1
0
0
1
2
Year 5
0 0
1 1
0 0
1 0
2 1
0
0
1
0
1
IBI GROUP
5.4
Staffing Phasing
As time progresses and projects identified in this Plan become implemented, the support
demands on IT personnel will continue to grow. Over the course of the 5 year period, one
additional full time IT support position should be required if all technologies are implemented.
We recommend this new position be filled, as IT support responsibilities increase and once
adequate funding is available.
In addition to the full time support needed, there will continue to be spikes in demand for
resources; in particular during project implementation. As these spikes would not necessitate the
hiring of a full time employee it is recommended that LTC continue to outsource additional
support as required. This support can come from the City of London, or through third-party
organizations.
5.5
Regular Review of Technology Plan
This Plan proposes to prepare several business case and deploy various technologies over the
next 5 years. Based on a current snapshot of LTC needs and technologies commercially
available. As time progresses, business cases will be developed, projects will be completed, and
the state of needs/technologies will evolve.
It is recommended that LTC revisit this report approximately once every two years to update the
report based on changing conditions. This update should:
Review agency stakeholder needs and identify which have been addressed by
completed project implementations;
Identify new stakeholder needs and relevant technologies and actions to address them;
Update the system vision diagram to account for deployed technologies and any new
technologies that become intended;
Identify and prioritize technologies for the next 5 years;
Re-evaluate projects currently classified as long term priorities; and
Review past business cases that did not justify technology deployment and evaluate if
these should be reviewed within the next 5 year period; and
Reflect upcoming expected funding availability; and consider technology advancements

that have recently become mature enough to consider deploying.
Reviewing the Plan every two years will ensure that it remains up-to-date and serves effectively
to track project status and support budgeting activities.
February 24, 2016
29
IBI GROUP
Appendix A Task 1: Existing Conditions

and Needs Assessment
February 24, 2016
IBI GROUP
5th Floor 230 Richmond Street West
Toronto ON M5V 1V6 Canada
tel 416 596 1930 fax 416 596 0644
ibigroup.com
Memorandum
To/Attention
Date
January 2, 2015
From
IBI Group
Project No
36814
cc
Kelly Paleczny, LTC

Patrick Cormier, LTC
Pavel Stoev, IBI Group
Tibi Gherghel, IBI Group
John George, IBI Group
Michael Mandelzys, IBI Group
Doug Parker, IBI Group
Subject
LTC Technology Plan

Task 1: Existing Conditions and Needs Assessment
Introduction
The London Transit Commission has engaged IBI Group to develop a Technology Plan. Various
technologies are approaching end of life and LTC will need to decide whether to re-invest or
migrate. Additionally, the plan will assess how well current and available technology addresses
LTC needs. The plan will serve as an Appendix to LTCs Asset Management Plan.
The work consists of:
Task 1: Existing Conditions and Needs Assessment (present memo) document

existing technology conditions and identify LTC technology needs.
Task 2: Technology Analysis consider what gaps need to be addressed to

enhance technology relative to the identified needs, and available technologies that
could be deployed to do so.
Task 3: Technology Plan structure the selected technologies into a sequence of

projects.
This Task 1 document combines the findings from onsite interviews conducted with Kelly
Paleczny and Patrick Cormier on July 30 with IBI Groups knowledge of LTC systems based on
past experience.
The work focuses on the following four areas:
Transit ITS
IT Infrastructure
Phone Systems
Data Communications
IBI Group is a group of firms providing professional services and is affiliated with IBI Group Architects
IBI GROUP MEMORANDUM
London Transit Commission January 2, 2015
Transit ITS
Existing Transit ITS
LTC has a significant amount of deployed transit ITS, centrally at its facilities and across its fleet
of 197 buses (152 in service at peak):
Trapeze CAD/AVL system The system has had minimal changes since its
implementation in the late 2000s, mainly limited to adding some custom reporting
functionality.
Enghouse TransView paratransit scheduling and dispatch software.
Passenger information LTC WebWatch (online), LTC IVR, wayside dynamic signage,
and GTFS schedule data feed to support the Google Maps transit trip planner.
Automatic passenger counters Currently approximately 40-50 vehicles are equipped.
Seon camera system There are 4 cameras on 40 buses and 6 cameras on 60 buses,
with the capacity to store two weeks of data on the DVR. Video segments are uploaded
via the shared garage WLAN when triggered by a request using the central video
software (e.g. on demand, G-force trigger events, covert alarm switch events). Uploaded
video segments are stored on servers for 90 days (video segments needed for longer
are burned to disc).
GFI CENTSaBILL fareboxes The fareboxes were fully refurbished 10 years ago.
Opticom Transit Signal Priority TSP receiver hardware is currently in place at the
intersection of Richmond Street and Central Avenue. The entire fleet is equipped with
TSP emitter hardware (some configuration and testing remains to be done).
Enrich Maintenance Management System This system has been in use for the past
ten years.
In addition, the following transit ITS projects are being deployed:
Scheidt and Bachmann smart card fare system.
Digi Routers These are being installed as part of the smart card project, and support
multiple methods of mobile data communications for the onboard smart card system
equipment (including cellular).
Expansion of automatic passenger counter coverage to entire fleet This is being done
as part of the vehicle replacement project, which is expected to be completed over the
next 5-6 years.
Expansion of Transit Signal Priority TSP is planned to by the end of 2014 cover every
intersection in the portion of the Richmond Street corridor where the express bus will
run. Further TSP coverage across the remaining Richmond Street Corridor and the
Oxford/Dundas Corridor is planned by the end of 2015.
Finally, the following future projects are expected but not currently in progress:
Replace existing TransView paratransit scheduling and dispatch software, expected in

2015.
Replace or refurbish GFI CENTSaBILL fareboxes There is budget in 2016 to replace

or refurbish the fareboxes depending on smart card customer uptake from the ongoing
smart card program, cash only fareboxes may be sufficient going forward.
Future BRT with onboard fare collection in a mixed use corridor.
Transit ITS Issues and User Needs

The following table summarizes issues raised during transit ITS discussions at the onsite
interviews, and maps them to specific needs and priority levels.
Need
Issue
Priority
Item
Issue
A.1
As the amount of technology has

increased, it is a challenge to support
technology systems at the desired
level.
Resources to support technology

systems.
High
A.2
CAD/AVL system provides a huge

source of data; but data and reports
are underutilized.
More effective use of data.
High
A.3
There has been a significant overturn

in management personnel since the
CAD/AVL system was implemented.
As a result new managers are not
always aware of the
features/functionality of the system,
and there is an impression that it is
being underutilized.
More complete use of software

capabilities.
High
A.4
Replacement cycle for systems and

hardware is not planned; tendency is
to be reactive rather than proactive.
Resources to support technology

systems.
Medium
A.5
Would like to incorporate facilities

management into maintenance
management software.
More streamlined facility

maintenance management
process.
Medium
A.6
Trapeze CAD/AVL software is

outdated and doesnt include the
Trapeze IDS decision support
module.
Support dispatchers in responding

to system issues
Medium
Increase dispatcher consistency
A.7
Batch reports are sent out daily, but it

is unclear how they are being used.
Medium
A.8
IT creates one or two new reports a

year. In addition, there are various
one-off requests for which IT mines
data. Institutionally, there is a
tendency to ask IT for reports rather
than individuals self-serving using the
available tools.
High
Need
Issue
Priority
Item
Issue
A.9
There is limited integration between

systems. An overarching SQL
structure that makes it easier to tie in
new applications would be beneficial.
Improved integration between

systems.
Low
A.10
Locating buses and managing bus

location is a challenge for
maintenance staff.
More efficient physical system

maintenance.
Low
A.11
Maintenance is increasingly relying

on technology to diagnose vehicles.
Instead of one support laptop for
diagnosing each onboard system,
could maintenance staff each have
their own laptop loaded with
necessary software, similar to with
other tools?
More efficient physical system

maintenance.
Low
A.12
Monitoring paratransit hours of

service (for payment purposes) is
currently a manual effort.
Automation of paratransit service

monitoring tasks.
Low
A.13
Currently no social media presence.

However, deployment needs to be
done correctly and consistently.
Correct and consistent social

media.
Low
IT Infrastructure
Existing IT Infrastructure
Central servers are located at the Highbury Facility. These servers host the following
applications:
LTC Website;
Trapeze CAD/AVL;
TransView for paratransit services; and
Enrich MMS
Generally application servers are set up by vendors. LTC is responsible for maintaining them
after installation. Servers are stand-alone with the following system features:
300 GB RAID array file server;
Dual power supplies; and
Tape backup.
The Wonderland facility is connected to the Highbury facility with a point to point fibre connection
leased from Bell. It houses some servers necessary to AVL, Seon (bus cameras), GFI farebox,
dvtel Security Cameras, etc at the remote location. The Satellite facility may present an
opportunity for remote backup / disaster recovery plans.Internet access uses a 20 MB

upload/download shared connection with 5-7 available IP addresses, provided by AllStream.
Currently only this single Internet Service Provider is being used, and this is currently the only
network access point. Third party vendors, mobile inspectors, and POS terminals all connect to
the network using Virtual Private Network over this internet connection.
Network infrastructure is predominantly Cisco catalyst gear, which is well distributed. Data drops
are performed using Power Over Ethernet. Network traffic is monitored by a Trend Micro
module, for network flow, security and misuse.
Email accounts are maintained by the City of London, which is responsible for hosting the
Exchange server. Apart from this Exchange server LTC hosts all applications on their own
servers.
The smart card system data resides on a vendor controlled Oracle Database. All other
Databases are internal MS SQL.
Crystal Reports as used for reporting is supported in house with 1-2 custom reports requested
each year. The Business Intelligence Initiative using MicroStrategy is intended to automate and
provide self service capabilities.
Patrick and Ryan Telford are responsible for the IT Environment, with occasional help from
Bosko Djuric (TLT Networks) for a wide variety of network/server configuration tasks. TLT
Networks is the primary resource for any and all Cisco / firewall / routing / switch configuration.
SmartNet information for Cisco and HP Warranties for servers are maintained mainly by the
vendors. Typically when hardware fails the vendor is contacted with s/n and they then advise
whether system is under warranty. Most often the 3 year warranty that comes with new
purchases is the only one LTC has for servers, while SMARTnet technical support contracts are
maintained on critical Cisco equipment and renewed through TLT Networks. Warranty
information is not currently being recorded or stored for reference by LTC. SMARTnet contracts
are kept on paper file, but are not well organized.
Additional details of LTCs IT infrastructure are included in the appendix.
IT Infrastructure Issues and User Needs
Item
Issue
B.1
Variance among the servers,

resulting from unplanned evolutions.
B.2
Servers have little redundancy.
Need
Consistent IT Infrastructure
Improve reliability/redundancy of
IT infrastructure.
Issue
Priority
Low
Medium
More efficient backup processes.

B.3
B.4
No complete system architecture

representation.
Unable to keep up with regular server
maintenance.
Inventory of current IT
infrastructure.
Low
Resources to support IT systems.

Resources to support IT systems.
High
Need
Issue
Priority
Item
Issue
B.5
There are many different workstations

(primarily Windows), which makes
managing updates difficult.
Consistent IT infrastructure.
B.6
No official business continuity or

disaster recovery plans.
IT infrastructure.
Medium
B.7
In some instances a single server is

responsible for multiple functions.
This creates a significant impact in
case of failure.
IT infrastructure.
Medium
B.8
Data from all applications are

currently siloed (used only within the
organization unit that generated the
data).
Improve integration between

systems.
B.9
Backup file save storage through

standalone PC with 3 USB ports can
be very slow.
IT infrastructure.
B.10
Duplication of video data storage.
Low
B.11
Servers and other IT infrastructure

are at or approaching end of life
Replace infrastructure as needed,

with up to date long term service
agreements
High
B.12
Mobile terminals (laptops) required

for garage maintenance activities
often require various different
operating systems
Deploy standard approach to

service maintenance interface
software via maintenance laptops
Medium
Low
Low
Medium
Phone Systems
Existing Phone Systems
The Highbury facility uses a Siemens HiPath 3700/3750 system, provided by Telus
approximately 13 years ago. The Wonderland facility uses an Avaya IP500 system. The ticket
office is connected as an off-premises extension (OPx) to the Highbury system.
Standalone lines are being used for fax, fire panels, hydro meter reads, etc.
The Siemens HiPath system is configured to support 2 main numbers for Highbury Office using
a Bell Megalink connection and approx 82 sets.A single Automated Call Distribution queue feeds
up to three full time Customer Service Representative (CSR) positions during the core business
day, and two additional temporary/part time positions. Call traffic is primarily inbound, with CSRs
providing route planning services and fielding customer complaints. Maintenance is on a monthto-month basis with Telus. The current phone system does not support Voice over IP (VoIP).
However, there is network switching in place which could support this transition. While the
existing voice cabling is old, the IP network cabling has recently been updated and has capacity
to support IP phones.
Overall, the system works well and is not experiencing high levels of failure. Voice
communications is no longer viewed to be as critical as the website for engaging with customers,
as the website has a higher impact. However, the system is now at or beyond end of life, and as
such, presents a risk to current operations. As the system will need to be replaced over the next
few years, there is an expressed desire to replace it with current technology.
The Ontira IVRs from Enghouse for the TransitMaster (BusLine) and TransView (HandyLine)
systems are running on a single server. Each system uses an AudioCodes gateway device with
8 ports.
The paratransit office uses eight Centrex lines.
Phone and other critical systems have UPS capable of supplying at minimum 15 seconds of
power, to provide continuity from outage to the start of generator power.
A traffic study was provided that shows significantly more trunks than required (over trunking).
Configuration information for each location (number of sets/consoles, number of lines/trunks,
number of supported phone numbers) is as follows: Highbury approx. 82 sets, 3 main dial-in
numbers, one of which is not in active use; Wonderland 33 sets, single main number. Both
locations have several standalone lines for FAX, fire panels, hydro meter reads, etc.
Phone Systems Issues and User Needs
Item
Issue
Need
Issue
Priority
C.1
Server running the IVRs is a point of

failure concern
phone systems infrastructure.
Medium
C.2
Hardware maintenance can be

difficult as the system is no longer in
production.
Updated hardware maintenance

and evolution plan.
Medium
C.3
User mobility is not possible.
Business case for phone

extensions that follow staff.
Low
C.4
Enghouse is not very responsive to

issues with the Ontira IVRs.
Low
C.5
There is no redundancy for

paratransit phone systems.
High
C.6
Traffic study shows potential over

trunking
Reduce number of trunks
Medium
C.7
HiPath Private Branch eXchange at

end of life
Replace with current technology

to maximize investment value
Medium
C.8
No disaster recovery plan in effect
Define and implement full disaster

recovery plan
High
Wide Area Communications

Existing Wide Area Communications
LTC uses a 400 MHz Tait radio system, which was originally deployed and integrated as part of
the CAD/AVL system project. The radio system uses one base station with the antennas located
at 1 London Place, configured with 3 voice channels and one data channel. A backup base
station is located at dispatch. Two dispatch positions are live, with a third used for training and
on a part time basis. As the two primary dispatch positions are next to each other and both use
speakers as opposed to headsets, both dispatchers operate on the same voice channel. The
second voice channel is used at the third temporary dispatch position, and the third voice
channel is primarily unused.
Radio coverage is generally good across the City, with a few dead spots such as near White
Oaks Mall, on Wellington south of Bradley.
Emergency coordination with other first responder agencies is handled via a ring-down wired
phone in the dispatch office.
The CAD/AVL system polls for vehicle updates over the data radio channel, with the vehicle
polling rate currently set to once a minute. Only one channel is used for data, with no additional
channels available.
In additional to the three radio consoles at dispatch, there are portables on 197 revenue service
vehicles (152 in service during peak periods), plus 6 mobile units and 8-10 handhelds used by
inspectors and maintenance staff.
Eight wayside information signs are controlled wirelessly. Seven communicate via the Rogers
cellular data network, with one using the data radio channel. Generally the data load for these
signs is low, and more could be added to the data radio channel if deemed necessary.
Paratransit uses a separate UHF voice radio system leased from Spectrum Communications.
Trapeze ITS responded to LTCs request for traffic/utilization tests with a radio narrative
(included in the appendix) rather than any real traffic numbers. Any study was done before AVL
implementation and use at current levels. It is likely that this is all the information that LTC will
have available. Industry Canada licence info is also in the appendix.
Wide Area Communications Issues and User Needs
Item
Issue
Need
Issue
Priority
D.1
Radio system may be approaching

end of life.
Radio system way forward plan.
Medium
D.2
Paratransit operators have difficulties

and experience delays getting access
to voice channels on the Spectrum
Communications system.
Further investigation required to

determine root cause and
potential need for additional
capacity.
Medium
D.3
BRT data requirements are unknown.
Low
D.4
There are some small radio

deadspots within the coverage area.

Improved radio system coverage.
Low
Needs Summary
Based on the interviews conducted on July 30, the following summarizes the LTC needs
identified:
Transit ITS
o
Resources to support technology systems
More effective use of data
More complete use of software system capabilities
More streamlined facility maintenance management process
Support dispatchers in responding to system issues
Increase dispatcher consistency
Improved integration between systems
More efficient physical system maintenance
Automation of paratransit service monitoring tasks
Create consistent social media policies.
IT Infrastructure
o
Consistent IT Infrastructure.
Improve reliability/redundancy of IT infrastructure.
Inventory of current IT infrastructure.
Resources to support IT systems
Improve integration between systems
Phone Systems
o
Improve reliability/redundancy of phone systems infrastructure.
Updated hardware maintenance and evolution plan.
Business case for phone extensions that follow staff.
Data Communications
o
Improve paratransit communications.
Next Steps
This memo will serve as an input to the Task 2: Technology Analysis deliverable, which will
consider what gaps need to be addressed to enhance technology relative to the identified needs,
and available technologies that could be deployed to do so. The technology analysis will for
each solution include a description, how it would work in LTCs operational context, general
10
benefits, a state of the market and industry best practices assessment, and rough estimates of
capital and operating costs.
Appendix
LTC IT Infrastructure
Radio Narrative (Provided by Trapeze)
Industry Canada Radio License
Internet
Basic Network Layout - London Transit

multiple vpns, both point-to-point
and Cisco software clients
Cisco ASA 5510 - firewall w/ SSM CSC module

Cisco 3602I APs
450 Office WiFi

planned, not yet
implemented
Cisco 3602E APs
450 Garage WiFi

multiple SSIDs for
traffic prioritization
Allstream 20MB Fibre Internet cxn

Bell 90/10 MB (2 channels) point-to-point fibre
450 Highbury Main Office
Bell 90/10 MB (2 channels) point-to-point fibre
3508 Wonderland Satellite Facilty
2 X Cisco 2900 Routers

2X Cisco Catalyst 3560E Core Switches
13X Cisco 2960S Access Layer Switches POE all ports
Cisco 2500 Wireless Network Controller - Office
Cisco 2500 Wireless Network Controller - Garage
2 X Cisco 2900 Routers

2X Cisco Catalyst 4506E Core Switches
3X Cisco 2960S Access Layer Switches POE all ports
Access layer switches connected to Core switches on

redundant fibre runs
Access layer switches connected to Core switches on

redundant fibre runs
Cisco 2500 Wireless Network Controller - Garage
Satellite uses Highbury's Internet connection
Cisco 3602E APs

3508 Garage WiFi
multiple SSIDs for
traffic prioritization
Server Inventory - London Transit

Approx
OS
Capacity (GB)
100
ws 2003
160
ws 2003
140
Windows 7
1250
ws 2008
800
ws 2003 x64
500
xp sp2
180
Windows 7
180
Windows 7
180
Highbury Main Office Building

Main Office Servers
subnet 192.168.1.x
IBM iSeries/AS400
ltc_server
ltc-server2
LTCStorage
LTCSERVER4
ltcsql1
GFI 1
SiPass Server
Insight Server
Enrich (Fleet Management / Inventory) Server - to be moved Remote App Server (Cloud) November 2014
File Storage, DHCP, Domain Controller, DNS, Parklane (HR), Trapeze scheduling app
Kronos Timekeeper App Server
PC with large USB Drives attached to address unmet storage needs
Platinum Accounting (pervasive db), TimeTracker (Operators), BI dbs - SQL
SQL DB Server: Transched (paratransit),Kronos db, Ceridian Insync (payroll) db, Trapeze db
PC for GFI farebox comms and reporting - Highbury
PC for Door Access Control
PC for Siemens BAS
ws 2003
ws 2003
ws 2003
ws 2003
ws 2003
ws 2003
ws 2008
Windows 7
TransitMaster AVL + Seon

subnet 192.168.10.x
TMDC
TMAPP
TMDB
TMINFO
TMCITRIX
TMFTP
TMOntira
SEON-SERVER
Domain Controller
Application Server
Database Server
Reporting Server
Remote Access Server
Bus Downloads/Uploads
IVR - for both AVL and Paratransit
PC for Bus Cameras
DMZ - Web Server

192.168.15.10
TMWebWatch
Web Server - also hosts LTC's main web site
450
2750
Security Cameras dvTel

subnet 192.168.30.x
CAMERAS-DIR
cameras-archive
Building Security Cams - Directory Server

Building Security Cams - Archiver Highbury
930
2000
SmartCard Servers
subnet 192.168.75.x
FGAPP
FGDB
FareGo (smartcard) App Server

FareGo (smartcard) DB Server
70
70
480
620
70
410
280
2000
ws 2003
70
xp sp2
ws 2003
ws 2008
ws 2008
OS
Approx
Capacity GB
xp sp3
xp
Windows 7
no longer in use
2000
180
2000
Wonderand Satellite Facility

Main subnet 192.168.100.x
other subnets in use depending on system, 130.x, 170.x
sat-archive
GFI 2
SAT-SEON
TMFTPWonderland
Building Security Cams - Archiver Satellite dvtel

PC for GFI farebox comms and reporting - Satellite
PC for SEON bus cams - Satellite
Bus Downloads/Uploads
TransitMaster Data Operation

Siemens will provide LTC the patented TransitMaster Gaussian Minimum Shift Keying (GMSK) Time
Division Multiple Access (TDMA) modem protocol, which has been designed for very fast and efficient
transmission of very large numbers of short messages - the type used in transit applications. This
protocol allows the use of standard off-the-shelf land mobile FM radios for transit data applications. The
modem allows for the polling of large fleets of vehicles at short time intervals with the utilization of a
minimum number of radio data channels. The base station operates in full duplex mode both
transmitting to the mobile units and receiving from them at the same time on a duplex channel pair for
maximum utilization of the frequencies. Conventional channels are used for the TransitMaster data.
The highly efficient nature of the Siemens data protocol will allow the LTC system to meet or exceed all
the polling requirements for the maximum number of vehicles in the current and proposed future fleet
using a data rate of 9600 baud, operating on a single wideband radio channel.
TransitMaster data loading was calculated to be less than 25% on the outbound (base to mobile)
channel, and less than 20% on the inbound (mobile to base) data channel. These numbers are based on
typical transit operational loading, and were made with the following LTC system parameters:
1 data channel at 1 radio tower site operating at 9600 Baud on a 25 KHZ channel
148 mobile maximum fleet size
60 second polling rate
Siemens system can support up to 500 vehicles with the above parameters.
If LTC migrates to a 12.5 KHZ narrow band data channel, the Baud rate will be reduced to 4800 Baud.
With the same polling rate and fleet size as noted above, the data loading was calculated to be less than
30% on the outbound (base to mobile) channel, and less than 30% on the inbound (mobile to base) data
channel. With the narrowband channel, Siemens data system could support up to 275 vehicles with a
60 second polling rate.
For demonstration purposes only, Siemens will reprogram one Bus In a Box, along with the primary data
station and RNC for narrow band (12.5 kHz) 4800 Baud operation for a short duration test during the
factory demonstration. This is only to prove compatibility with the system operating at narrowband
should Industry Canada force LTC to re-program all their radio equipment for 12.5 KHZ data operation at
some time in the future.
The polling rate for the entire system may be changed through a setting on the Radio Network
Controller. The polling rate for a vehicle with an emergency is typically increased. However, in systems
designed with only one radio on each of the vehicles, such as for LTC, the vehicle cannot respond to a
poll if it is in voice mode or covert voice mode. If for some reason the polling rate cannot be maintained
due to system loading, the system will gracefully reduce the polling rate automatically. For example, if
the system were polling every 30 seconds and during a peak demand there are not enough reporting
slots available, the system would back off to 31 or more seconds as necessary to service all the vehicles.
When the demand is reduced the polling rate will automatically increase until it returns to the set value.
IBI GROUP
Appendix B Task 2: Technology Analysis
February 24, 2016
Technology Plan
Task 2: Technology Analysis

by IBI Group
January 21, 2016
IBI GROUP
TECHNOLOGY PLAN: TASK 2 TECHNOLOGY ASSESSMENT
Document Control Page

CLIENT:
PROJECT NAME:
Technology Plan
REPORT TITLE:
Technology Plan
IBI REFERENCE:
36814
VERSION:
REVIEWER:
3.0
J:\36814_LTC_Technolo\5.0 Design (Work) Phase\2.0 Technology
Analysis\STR_LTC_Task2_technology_analysis_2016-01-21.docx
D. Duong; M. Mandelzys; M. Sawaf; T. Gherghel; J. George; P.
Stoev; D. Parker
M. Mandelzys/D. Parker
AUTHORIZATION:
D. Parker
CIRCULATION LIST:
K. Paleczny, P. Cormier
1.0 Submitted to the client on January 22, 2015
2.0 Revised January 2016, based on client feedback
3.0 Final Task 2 Report
DIGITAL MASTER:
ORIGINATOR:
HISTORY:
January 21, 2016
IBI GROUP
TECHNOLOGY PLAN
Table of Contents
Glossary ......................................................................................................................................... 1
1
Introduction ......................................................................................................................... 2
Overview of Existing Conditions ...................................................................................... 3
Potential Solutions ............................................................................................................. 4

3.1
3.2
3.3
3.4
3.5
Additional Resources for IT and ITS Systems ......................................................... 4

3.1.1
New Hire ..................................................................................................... 4
3.1.2
Outsourcing ................................................................................................. 4
3.1.3
Combined .................................................................................................... 5
Transit ITS Systems................................................................................................. 5

3.2.1
Improved Reporting/Data Use .................................................................... 5
3.2.2
Strategy Options ......................................................................................... 6
3.2.3
Upgrade Transit ITS .................................................................................... 8
IT Infrastructure ........................................................................................................ 8
3.3.1
Server and Storage Infrastructure ............................................................... 9
3.3.2
Regular Review of the IT Infrastructure and Strategic Plan........................ 9
3.3.3
Disaster Recovery Plan .............................................................................. 9
Telephony Systems ................................................................................................. 9

3.4.1
VoIP Telephony Systems .......................................................................... 10
3.4.2
Interactive Voice Response systems ........................................................ 10
Data Communications ............................................................................................ 10

3.5.1
January 21, 2016
Radio Communications ............................................................................. 10
Potential Approaches and Solutions .............................................................................. 12
Estimated Costs for Technology/Strategy Options ...................................................... 13
Project Classification ....................................................................................................... 15

6.1
Short-Medium Term ............................................................................................... 15
6.2
Long Term Priority ................................................................................................. 15
6.3
Next Steps ............................................................................................................. 15
IBI GROUP
TECHNOLOGY PLAN
Table of Contents (continued)

Exhibit 1 LTCs Existing/In-Progress Conditions ......................................................................... 3
Exhibit 2 Gaps Mapped to Technology Options ........................................................................ 12
Exhibit 3 Dentitions for Capital and Ongoing Costs ................................................................... 14
Exhibit 4 Gaps Mapped to Technology Options ........................................................................ 14
January 21, 2016
ii
IBI GROUP
TECHNOLOGY PLAN
Glossary
A glossary of abbreviations and terminology in included below.
TERM
January 21, 2016
DEFINITION
AVL
Automatic Vehicle Location
BCP
Business Continuity Plan
BI
Business Intelligence
CAD
Computer Aided Dispatch
ConOps
Concept of Operations
DRP
ETL
Extract Transform Load
GRT
Grand River Transit
IDS
Intelligent Decision Support
IP
Internet Protocol
IT
Information Technology
ITS
Intelligent Transportation Systems
IVR
Interactive Voice Response
KPI
Key Performance Indicator
LTC
MBTA
Massachusetts Bay Transit Authority
MMS
Maintenance Management Software
PBX
Private Branch eXchange
RTD
Regional Transportation District (Denver)
SaaS
Software as a Service
SAN
Storage Area Network
SIP
Session Initiation Protocol
VM
Virtual Machine
VoIP
Voice over Internet Protocol
YRT
York Region Transit
IBI GROUP
TECHNOLOGY PLAN
Introduction
The London Transit Commission (LTC) has engaged IBI Group to develop a Technology Plan
(herein known as the Plan). Various technologies deployed at LTC are approaching end-of-life
and LTC will need to decide whether to re-invest or migrate to newer systems. Additionally, the
Transit Technology and Information Technology landscape has seen significant advancements.
Hence, the Plan will assess how well current and available technology addresses LTCs needs.
The work consists of the following three tasks:
Task 1: Existing Conditions and Needs Assessment documents existing technology

conditions and identifies LTCs technology needs.
Task 2: Technology Analysis considers what gaps need to be addressed to enhance

technology relative to the identified needs, and available technologies that could be
deployed to do so (present report).
Task 3: Technology Plan structures the selected technologies and activities into a
sequence of projects detailing timelines, capital/ancillary/operational costs, and
dependencies.
This Task 2 report combines the findings from the Task 1 document with IBI Groups previous
experience in the subject areas to provide an overview of available and applicable technology
solutions or activities to address the identified needs. The work focuses on the following
elements:
January 21, 2016
Transit Intelligent Transportation Systems (ITS);
Information Technology (IT) Infrastructure;
Telephony Systems; and
Data Communication.
IBI GROUP
TECHNOLOGY PLAN
Overview of Existing Conditions
Exhibit 1 shows a high-level overview of LTCs existing and in-progress status for Transit
Intelligent Transportation System (ITS), Information Technology (IT), Telephony, and
Communications.
Exhibit 1 LTCs Existing/In-Progress Conditions
Conventional Bus
Mobile Radio Units

and Handhelds
1 London Place
1x Wayside
Sign
400 Mhz Tait

3x Radio Radio System
Consoles
Trapeze CAD/AVL
APC (40-50 out of 197 buses)
GFI CENTSaBILL fareboxes
Seon Cameras (4 for 40'/6 for 60')
TSP emitters
Digi Routers
Scheidt&Bachmann Smart Card
System
Siemens HiPath 3700/3750

(conventional telephony)
Servers
2x Dispatchers
1x Backup
Dispatch (backup)
Highbury
LTC
Website
TransView
S&B
Smart Fare (paratransit)
7x Wayside
Sign
Trapeze
CAD/AVL
Enrich
MMS
Avaya IP500
Cellular
(Rogers)
Fibre
(Bell)
Servers
LEGEND
Wonderland
In-place
In-place, but requires
reconfiguration or
replacement
In-place (outsourced/
leased)
January 21, 2016
UHF voice
radio
(Spectrum
Comm.)
Mobility Vehicle
Trapeze
CAD/AVL
SEON
(onboard
cameras)
GFI
(fare)
dvte
(security
Cameras)
IBI GROUP
TECHNOLOGY PLAN
Potential Solutions
This section describes various solutions or activities that may assist the LTC in improving or
finding improvements for their organization. Note, in this section all possible solutions are
described and explored. No filtering criteria have been applied. The subsequent sections of this
report will categorize and link the solutions to gaps found in the Previous Task 1: Existing
Conditions and Needs Assessment. The final section will provide a ranked list that will feed into
the final Task 3 Technology Plan report.
3.1
Additional Resources for IT and ITS Systems
Currently, there is no dedicated Project Manager to oversee IT and transit ITS projects. This task
is taken on by both the General Manager (GM) and Manager of Information Services (IS) in
addition to their regular full-time responsibilities. Both the GM and Manager of IS are heavily
loaded by their current responsibilities, and as LTC continues towards a future with more
systems to automate delivery of services the current status quo becomes untenable. Hence,
additional resources are required to alleviate this burden. The additional resources will provide
assistance to manage delivery of new systems and maintain current/future IT and transit ITS
systems. The primary options for obtaining these additional resources include (1) hiring
additional staff, (2) outsourcing, or (3) some combination of the two.
3.1.1
New Hire
In a new hire scenario, a new position would be created to maintain IT and ITS systems and
equipment. The position hire(s) would supplement the existing IT and ITS support team and be
under the supervision of the Manager of Information Services. With new hire(s), LTC mitigates
the risk that resources will not be available for support. However, new positions will entail ongoing operating costs. This new position would be:
1. IT Network Administrator/Engineer: The person(s) in this position would help maintain
the health of hardware such as servers, or storage area networks (SANs), as well as
assist in resolving internal customer facing problems. He/she would be knowledgeable
in all LTC systems to undertake first-line troubleshooting. If issues cannot be resolved
internally, then she/he could forward the issue to the respective system vendor. This
position is estimated at one to two Full Time Equivalents (FTEs).
Through enabling the Manager of Information Services to pass many network administration
duties to new staff, he would have more time to act as LTCs main IT project manager. As IT
Project Manager he would be responsible for leading LTC in the deployment and upgrades of IT
and ITS systems. He would also manage and coordinate day to day activities related to
operation of the IT and ITS systems, including supervision of the network administrator(s).
A key benefit of the new hire approach is that the knowledge base of the LTC system is kept
within LTC; however, the new position would entail ongoing operating costs.
3.1.2
Outsourcing
In an outsourcing scenario, outside resources will be used to support maintenance of IT and ITS
systems. Outsourcing by LTC can be via the hiring of independent contractors and/or partnering
with City of London to service the IT and Transit ITS systems.
1. Hiring independent contractors could be accomplished with separate procurements for
individual tasks, through an on-call arrangement, or through a combination of both
methods. Another outsourcing approach is to actually procure newer systems as
Software-as-a-Service (SaaS) where the hardware/software system health is maintained
January 21, 2016
IBI GROUP
TECHNOLOGY PLAN
by the vendor. These options limit costs associated with full-time staff (salary and
benefits). However, usually the upfront cost (i.e. charge rate) is higher than a regular
staff rate, reflecting the need for outside firms to cover their non-salary costs and profit
in addition to salary. This is mitigated by the fact that services would be used only as
needed.
Many transit agencies, such as York Region Transit (YRT), Grand River Transit (GRT),
and Metrolinx, use longer-term on-call arrangements or individual RFPs to acquire
contracted services. The success of which requires clearly delineating the scope of the
services to be provided.
2. Partnering with City of London to service the IT and Transit ITS systems could be
completed in a similar manner to the existing LTC contract with the City for email
hosting. Adopting this option does not necessarily mean a less costly option for
outsourcing. LTC would need to work with the City and negotiate available alternatives
for this approach.
Use of independent contractors and City of London support could be combined, with the choice
varying between various systems and support positions.
3.1.3
Combined
An alternative solution is to combine outsourcing with the creation of new positions. In this
combined solution, one IT Network Admin position would be created and the Manager of
Information Services would take on the role of IT Project Manager as well as Manager of
Information Systems. Additional support needed beyond the one additional FTE would be
provided on an as needed basis via outsourcing (whether through an on-call arrangement, the
city, or supported Software-as-a-Service (SaaS)). This combined solution would lower the
upfront costs associated with outsourcing and ensure support would be available at all times to
LTC.
This solution is the approach taken by Guelph Transit and GRT, with there being some internal
IT staff but supplementary IT services available through the City of Guelph/Region of Waterloo
(respectively) or third-party contractors. The disbenefit is that some knowledge is not retained
internally across projects as would be the case with agency IT staff.
3.2
Transit ITS Systems
3.2.1
Improved Reporting/Data Use
Access to data for reports and the ability to see trends are both powerful tools to help LTC
improve service. Providing stakeholders with access to such tools would allow for better
utilization of data generated from the existing transit ITS systems. This would reduce the current
load on LTC staff that enter data and generate some reports manually.
Two interdependent technology options to address this are considered here: (1) implementing a
centralized data warehouse; and (2) expanding on or deploying a new business intelligence
system. An essential aspect of such endeavours would be developing policies to ensure
effective use of such tools going forward.
A centralized Data Warehouse would be of limited usefulness without including effective
reporting tools, while Business Intelligence tools require good data. Hence, both are treated here
as a single project.
January 21, 2016
IBI GROUP
TECHNOLOGY PLAN
3.2.1.1
Centralized Data Warehouse
Centralized Data Warehouse systems unify data from various systems, for easy access from a
single repository. Collecting all data into a central data repository would allow for more powerful
analysis and reporting that links previously isolated data sources. Additionally, this would ensure
using a single version of the truth for all reporting.
Implementing this technology would involve consolidating existing LTC data sources. This would
require an inventory of existing data systems, and developing internal policies and procedures
for data consolidation. The internal policies and procedures would be necessary to ensure
consistency in importing, processing, storing and exporting data (e.g., Extract Transform Load
[ETL]). Tackling this incrementally is recommended, as its completion through a single project
could be overwhelming.
An initial task would develop the aforementioned policies and a concept-of-operations (ConOps)
for such a centralized Data Warehouse system, in conjunction with a ConOps for the Business
Intelligence tool. The ConOps would establish the high-level requirements and vision on the
system high level configuration/capabilities and how it would be used to benefit LTC, as well as
providing a more detailed cost assessment. Since it helps better define both the benefits and
costs, the ConOps can feed into LTCs business case preparation process.
Centralized Data Warehouse systems are relatively new for use by transit agencies, since many
are still in various phases of deploying the CAD/AVL, Scheduling, and Fare System data
sources.
3.2.1.2
Business Intelligence Tools
Enhanced Business Intelligence (BI) would provide better real-time information and trend
reporting tools using the consolidated data from multiple sources available via the centralized
Data Warehouse. BI tools would include real-time status dashboards that allow LTC staff to view
overall system operational performance status in an easy to read way. This would enable staff to
identify and respond to issues as they occur. The recent BI pilot LTC conducted showed that it
was important that the dashboard Key Performance Indicators (KPIs) be actionable. The BI
system could include establishing KPIs that are actionable, such as to identify route/stop
overloads.
Other BI tools would allow LTC staff to use data imported from the Data Warehouse to conduct
analysis, identify patterns and generate reports. Those tools would allow LTC staff to enhance
its operational performance and better plan for its future. The initial tasks would be to develop
more useful KPIs, which would feed into a ConOps report. This ConOps for the BI system would
detail the high-level vision (requirements), as well as any considerations for benefits and costs,.
This would be done in tandem with the centralized Data Warehouse ConOps. LTC can then use
this to gauge whether a business case is needed to deploy such a system.
Full scale BI systems are relatively new for transit agencies, since many are in various phases of
deploying CAD/AVL, Scheduling, and Fare Systems (i.e. data sources) and have not acquired
the necessary centralized Data Warehouse system.
3.2.2
Strategy Options
In addition to procuring new technology, there are a number of potential opportunities for LTC to
improve their use of current systems through procedural and policy updates.
January 21, 2016
IBI GROUP
TECHNOLOGY PLAN
3.2.2.1
Refresher Training
In conjunction with policy updates, LTC could conduct refresher training to foster optimal use of
their systems. This could be done internally for users familiar with the system, or may require
outsourcing of training to system providers.
1. Internally-hosted training: LTC currently hosts informal lunch-and-learns where staff
show others in the organization ways to improve their efficiency (e.g. new ways to better
use Excel). These lunch-and-learns could be formalized with a set schedule. A part of
the process involves using web-based surveys (using SurveyMonkey) to ask staff for
self-assessment of their interest in such sessions about the various systems LTC has inplace. Then IT staff or the relevant system super-user (i.e. someone very proficient in
the system) could host a refresher lunch-and-learn session.
2. Vendor-hosted refresher training: For future upgrades or new system contracts, LTC
could include contract requirements and pricing options for refresher training. This would
be to supplement the initial training required during deployment (i.e. does not replace
that). Optional pricing would allow LTC to budget for vendor-hosted refresher training as
needed.
The internal training method is usually undertaken by agencies with dedicated staff to provide
this service. However, formalizing the lunch-and-learns would provide LTC a method to have
internally-hosted training without the need for dedicated staff. The first step would be to scope
out the following via a plan:
How would staff proficiency be gauged before and after?
What would be the format, frequency and duration of the lunch-and-learns?
The latter solution of having vendor-delivered refresher training is a concept other transit
agencies are sometimes including in deployment contracts.
3.2.2.2
Social Media Policies
Policies could be developed to effectively disseminate real-time information into social media
channels. Real-time information could include service alerts, vehicle locations and arrival
predictions. The real-time data would be provided in a uniform format through GTFS real-time
feeds and API web-services. LTC staff would enter, manage and control service alerts from a
Graphical User Interface (GUI) allowing for control over where and when each service alert is
disseminated. The system would also automatically disseminate appropriate messages across
all channels (e.g. Facebook, Twitter). The system would tag alerts with GTFS-consistent
identifiers that allow riders to receive only selected alert messages. API web services would be
made available to third party application developers registered for accounts and API-keys on a
developer portal. The initial task would be to develop the ConOps for this system so that LTC
can prepare a Business Case for funding. This ConOps would detail the process changes that
might be needed at LTC to facilitate quick dissemination of alerts via social media (e.g. what
alerts, thresholds, which social media sites, response times).
The Massachusetts Bay Transit Authority (MBTA) uses a system called MBTA-realtime to create
alerts for dissemination to riders via its T-Alerts service and social media. Customer experience
is improved by quickly providing informing through streams they are already using (e.g. Twitter,
Facebook), which in turn improves the utility of transit as a mode choice.
January 21, 2016
IBI GROUP
TECHNOLOGY PLAN
3.2.3
Upgrade Transit ITS

3.2.3.1
Fixed Route Service
The CAD/AVL system could be enhanced by adding the now available TransitMaster Intelligent
Decision Support (IDS) modules. This would provide decision support to dispatchers by
identifying potential service issues and presenting recommended responses/procedures to
dispatchers. This implementation would need to be supplemented by developing consistent
procedures for dispatcher use. This is a quick win method available to improve service delivery
to customers. The initial task would be to scope the requirements for the upgrade, usually
starting with the base functions offered by the IDS module and then adding LTC-specific
functionality. Training and maintenance requirements would need to be considered.
3.2.3.2
Paratransit Service
LTC is anticipated to continue its current efforts to procure a paratransit scheduling and dispatch
management software. Currently, reservations calls are taken from clients and one FTE is
needed each day to schedule the next days trips into individual manifests for drivers. Due to the
inefficiencies of manual scheduling, it is expected that more trips could be served. Also,
operators manually log pick-up, no-show, fare, and other data, with two FTE needed each day to
log this information after the manually completed manifests re turned in. With these
enhancements, LTE should be able to assign a minimum of three FTE to other duties. These
procurements would also enable the procurement of ancillary systems such as a paratransit
website and IVR. Both of these could help paratransit users get information and possibly also
book trips, which would improve customer service and lighten the load on LTCs reservationists.
Other added benefits are: the scheduling system will allow LTC to evaluate different schedule
scenarios for the next day to minimize costs, while serving the maximum amount of users; and
the dispatch management will provide LTC better data about in-service operations for use in
reporting.
3.2.3.3
Transit Yard Manager
LTCs current CAD/AVL system has a coach placer option in order to assist with the location of
parked vehicles. A Yard Management system is a more in depth solution that would enable
vehicles to be directed at pull-in to parking locations according to maintenance planning and the
upcoming (intended) pull-out order. Transit yard management systems generally include
software to track and update vehicle locations, create parking plans, and facilitate dispatching
block to vehicle assignments. Most vendors also have experience transferring location
information to third party software packages, including that of established CAD/AVL software
vendors such as Trapeze.
A first step would involve preparing a ConOps and business plan to assess the high-level vision
and feasibility of deploying a yard management system. This plan would look at the payback
period of such a deployment in terms of added benefits, and FTE savings.
3.3
IT Infrastructure
A viable strategy for LTC to minimize the level of software and hardware maintenance support
from internal staff is to structure future projects to include some combination of virtualized
servers, virtualized SAN, and (vendor) hosting. Using virtualization will reduce the amount of
physical hardware that LTC has to support. Hosted solutions would offload the maintenance to
the third-party vendor. The appropriate strategy would be decided on a project by project basis.
However, LTC can support in-house virtualization by procuring the infrastructure needed, such
as server and storage hardware, and management applications.
January 21, 2016
IBI GROUP
TECHNOLOGY PLAN
3.3.1
Server and Storage Infrastructure
A ConOps should be developed that details the high-level specifications required for the servers
and storage infrastructure in order to support virtual servers and SANs. The following are some
considerations that the ConOps will look at:
Enterprise servers hardware requirements;
Enterprise storage hardware requirements;
Hypervisor software requirements (e.g. VMware, Hyper-V);
Virtual datacenter software requirements (e.g. VMware Virtual SAN); and
VM Application/SAN management and monitoring requirements.
This will assist LTC to procure the necessary hardware and software that fits their needs for a
virtualized servers/storage approach. By consolidating virtualized applications and data storage
for multiple applications onto physical servers and SAN hardware, this will reduce FTE required
to maintain physical hardware (i.e. amount of hardware is reduced). Virtualization will allow LTC
to easily adapt to their changing system needs, by adjusting the numbers of virtual servers and
their allocated configuration of processor, memory and storage resources on the same physical
server and SAN hardware.
3.3.2
Regular Review of the IT Infrastructure and Strategic Plan
LTC should regularly update the Technology Plan. It should be a living document that evolves
with changes in the LTC needs/environment (e.g. new systems are in place) or other factors
(e.g. advances in technology). Such reviews should explore:
SaaS requirements (e.g. which future systems are suitable for a SaaS approach, or
which existing systems should be migrated);
Off-site Server Hosting, including use of Virtual Servers;
Storage Area Network (SAN) upgrades or hosting;
Remote access communication system upgrades (Citrix Servers); and
Priority for adding new system or upgrade packages.
Other agencies, such as the Regional Transportation District (RTD) (Denver, CO), have started
to undertake such reviews annually. They have deemed a proactive approach better than always
playing catch-up. The initial activity would be to develop a process for this regular review. In the
RTD example, they have an internal Wiki that details the existing system and future system plan,
with this information updated as part of the regular review process.
3.3.3
Develop a Disaster Recovery Plan (DRP) to establish requirements for sustained availability of
all the hardware, software and operational functions needed to meet covered operational
requirements, during and after an emergency event. Many agencies are pursuing DRPs as part
of their overall Business Continuity Plans (BCPs) (e.g. Metrolinx, RTD), since transit is an
essential service to the function of a city. By having a DRP and BCP, the steps become detailed
to quickly recover service for predictable scenarios.
3.4
Telephony Systems
This subsection reviews Telephony-related solutions to close gaps in this area of LTCs existing
systems.
January 21, 2016
IBI GROUP
TECHNOLOGY PLAN
3.4.1
VoIP Telephony Systems
Building the business case to replace the current phone system with a Voice over Internet
Protocol (VoIP) based system should be assessed. This should be coordinated with the
DRP/BCP and IT strategic plan. Several benefits of an IP-based telephony system are:
IP based multimedia applications to improve the customer experience,
Supporting unified messaging for productivity gains (unified messaging refers to

systems that integrate different carious messaging systems (e.g., e-mail, SMS, fax,
voicemail, video messaging) via a single interface accessible using a variety of different
customer devices),
Lower phone services costs,
Easier maintenance.
This will also offer LTC more feature rich functions, such as caller ID and taking calls using their
workstations. Agencies such as Metrolinx are trialing such a system (e.g., Jabber).
One aspect that should be considered when planning the replacement of the existing telephony
system is whether the new system should be a Hosted PBX or deployed on premise. Hosted
PBX refers to a VoIP solution where the hardware of a private branch exchange (PBX) is hosted
remotely, typically at a dedicated data center and maintained by the service provider.
Connection between the site and the Hosted PBX is made over an internet connection, using
dedicated routers/switches and secure protocols. The service provider can maintain and
upgrade the system more easily than with on-site equipment, and there are fewer physical
components overall. A Hosted PBX phone system has built-in DRP/BCP capabilities as it does
not reside on site. The main benefit of a Hosted PBX is cost, being much less to set-up than an
on-premise PBX. In many cases, there are no set-up fees for a hosted VoIP system. Hosted
PBX phone systems fall under operational expenditure rather than capital expenditure, which
also make hosted VoIP systems attractive to businesses.
Session Initiation Protocol (SIP) Trunking is a VoIP protocol that replaces a traditional PBX, with
the ability to connect a greater variety of devices and capabilities (voice, video, and text) within
the same session. It also offers more flexibility than a PBX for reconfiguring the network, since
the configuration on the hosted equipment is virtual. Both Hosted Telephony and SIP Trunking
enable communication among multiple physical offices/sites connected to the system over the
internet. This of course will make the telephony reliant on sufficient and reliable internet
connectivity for each connected site.
3.4.2
Interactive Voice Response systems
Evaluating the business case for options to upgrade or replace the Interactive Voice Response
system (IVR) to improve reliability and redundancy. This would also be an opportunity to expand
IVR functionality if desired. LTC should evaluate three IVR architecture models: (1) on premise
solution; (2) hosted solution; and (3) incorporated into the new IP-based telephony system.
3.5
Data Communications
This subsection looks at data communication related solutions to help resolve deficiencies in
LTC radio-related communications.
3.5.1
Radio Communications
LTC currently operates a Tait 400MHz radio system for fixed route bus operations, using three
voice channels and one data channel. The system currently operates with few issues and meets
January 21, 2016
10
IBI GROUP
TECHNOLOGY PLAN
LTC needs with excess voice traffic capacity, so little immediate action is required. The system
will be nearing end of life within five years, and should be assessed for replacement at that time.
3.5.1.1
Radio Way Forward Plan
Within the next five years, prepare a plan to upgrade/replace the fixed route 400MHz radio
system. This plan should consider future voice/data needs, and also actions such as moving to a
trunked system and adding a second antenna site to address minor coverage issues. Further
consideration should be given to newer radio technologies, such as those discussed in
Appendix A.
3.5.1.2
Replace/Upgrade Radio System
Replace or update the radio system based on the way forward plan, to improve reliability and
coverage.
January 21, 2016
11
IBI GROUP
TECHNOLOGY PLAN
Potential Approaches and Solutions
Exhibit 2 maps the gaps derived from user needs (Task 1) to various technology/strategy
options described in Section 3. Some options are complementary while others are mutually
exclusive. The sections following this table provide additional technical, relevance and benefit
details for each option. Priority levels indicated in Exhibit 2 are related to the gaps as evaluated
in the Task 1 report.
Exhibit 2 Gaps Mapped to Technology Options
Gaps
Transit ITS
More resources to support Information
Technology (IT) & technology systems
and proactively plan systems
development strategy
More ability for users to effectively
access and use the full range of
available data in a self service manner
More complete awareness and use of
existing software system capabilities
Improved facility maintenance
management reporting
Better support dispatchers in
responding consistently to operational
issues
Improved flexibility to integrate and
share data between systems
Improved ability to optimize and
manage parked bus locations
Better ability to automatically track the
amount of paratransit service delivered
Establish social media policies.
Priority
Technology/Strategy Options
High
New Hire(s)
Outsourcing
High
Centralized Data Warehouse &

Low
Refresher Training
Medium
High
Low
Low
Low
Medium

Enhance Computer Aided Dispatch /
Automatic Vehicle Location (CAD/AVL)
to include Intelligent Decision Support
(IDS) functionality
Upgrade Paratransit Dispatch and
Scheduling Management Software
Develop Policy for Social Media
IT Infrastructure
Consistent IT Infrastructure.
Low
Improve reliability/redundancy of IT
infrastructure.
High
High
January 21, 2016
Technology Plan (Task 3 of this

project)
Regular Review of Existing IT
Infrastructure and Strategic Plan
project)
Server/Storage Infrastructure
project)
12
IBI GROUP
TECHNOLOGY PLAN
Gaps
Priority
Technology/Strategy Options
project)
New Hire(s)
Outsourcing
project)
Inventory of current IT infrastructure.
Low
Resources to support IT systems
High
Improve integration between systems
Low
Replace infrastructure as needed, with

up-to-date long term service
agreements
High
Telephony Systems
Replace current HiPath 3700/3750
phone system with current technology
to maximize investment value
Reduce number of trunks
Medium
Telephony System Business Case
Medium
Low
Business case for phone extensions

that follow staff.
Improve reliability / redundancy of the
Interactive Voice Response (IVR)
systems.
Define and implement full Disaster
Recovery (DR) plan
Updated hardware maintenance and
evolution plan.
Medium
IVR Business Case
High
Develop Disaster Recovery Plan
Medium

project)
Data Communications
Improve paratransit communications.
Medium
Medium
Low

project)
Radio way forward business case
project)
project)
Estimated Costs for Technology/Strategy

Options
The costs for each proposed technology/strategy were estimated. These were classified as
High, Medium or Low, for capital and incremental ongoing costs. Incremental ongoing cost
estimates assume additional support staff and licensing costs for new systems. However, many
January 21, 2016
13
IBI GROUP
TECHNOLOGY PLAN
of these systems would result in reduced workloads for existing staff which could reduce or
eliminate the ongoing costs based on LTC staffing decisions. More detailed cost estimates, with
breakdowns for the various stages (e.g. ConOps, Specifications, Procurement, Deployment), will
be developed as part of Task 3 report. The approximate ranges used to categorize each type of
cost and priority level are indicated in Exhibit 3. These priorities are distinct from but related to
those assigned to the gaps, which were more related to the timelines (i.e. urgency) for
implementing the solution.
Exhibit 3 Definitions for Capital/Ongoing Costs and Priority
Cost Category
Capital
Low
Under $10,000
Medium
Between $10,000 and $100,000
High
Over $100,000
Incremental Ongoing
Under $1,000
Between $1,000 and $10,000
Over $10,000
Priority
Long-Term Need
Medium-term Need
Short-Term Need
Exhibit 4 provides cost classifications for each technology/strategy option identified in this
report.
Exhibit 4 Gaps Mapped to Technology Options
Capital Cost
Incremental
Ongoing Cost
Priority
New Hire
None-Low
High
High
Outsourcing
None-Low
High
High
Low
Low
Medium
Medium
High
High
High
High
Medium
Low
Medium
Low
Medium
Low
Medium
Medium
High
Medium-High
High
None
Medium-High
Medium
None
Medium
None
Technology/Strategy
1
1.a
1.b
2
2.a
3
3.a
3.b
3.c
4
Additional Resources for IT and ITS Systems

High
Improved Reporting/Data Use
Upgrade Transit ITS
Fixed Route CAD/AVL Enhancement
Paratransit Scheduling and Dispatch
Management Deployment
Other
4.a
4.b
Refresher Training
5
5.a
IT Infrastructure
5.c

Telephony System
5.b
6.a
January 21, 2016
High
High
Medium
Medium
14
IBI GROUP
TECHNOLOGY PLAN
Technology/Strategy
6.b
IVR Business Case
Radio Communications
7.a
Radio Way Forward Business Case
Medium
Incremental
Ongoing Cost
Medium
Medium
Med
None
Medium
Capital Cost
Priority
Project Classification
Through combining the priorities with estimated costs, the full list of technology/strategy options
were classified as either a short-medium term or long term. The short-medium term options are
recommended for inclusion in the Task 3 Technology Plan. We recommend the long term
options be reconsidered in the future for inclusion in the technology plan five-year horizon.
6.1
Short-Medium Term
The following technologies or activities will be evaluated in the Technology Plan under Task 3:
New Hire and/or Outsourcing
Fixed Route CAD/AVL Enhancements
Paratransit Scheduling and Dispatch Management Procurement
Refresher Training
Regular Review of the IT Infrastructure and Strategic Plan
IVR Business Case
Radio Way Forward Business Case
6.2
Long Term Priority
Options with higher estimated costs and meeting lower priority issues were classified as long
term. These should be noted for longer term planning but do not present a priority for the near
term deployment objectives addressed by this plan. These projects include:
Centralized Data Warehouse & Business Intelligence
6.3
Next Steps
This report will serve as an input to the Task 3: Technology Plan, which will rationalize and
define the preferred technology deployment sequence over a five-year horizon. The
strategies/technologies will be arranged into a sequence of actionable project initiatives for
deployment based on short- and mid-term priorities. The plan will include capital program
budgets as well as procurement/deployment strategies, interdependencies and
staffing/organizational impacts.
January 21, 2016
15
IBI GROUP
TECHNOLOGY PLAN
The Technology Plan will provide a detailed schedule breakdown for deploying particular
technologies. For IVR as an example, the Task 3 report will detail the projected timelines and
costs for business case development, ConOps, specification, procurement, and deployment
phases. This will provide LTC with information to plan for the 5-year horizon. LTC could of
course stop after the business case phase if this was not found to have enough merit to
proceed.
January 21, 2016
16
IBI GROUP
Appendix C Radio Technology

Comparison
February 24, 2016
Radio Technology Comparison

The following sections provide a comparison of three land mobile radio technologies available to LTC: P-25,
TETRA and DMR.
P-25
P-25 was initiated as project number 25 by APCO (Association of Public Safety Officials International).
Essentially it was a North American response to the development of TETRA and was intended to be in alignment
with the approach to North American spectrum management principles which were encouraging spectral
efficiency by the reduction in occupied bandwidth by radio signals first to 12.5 kHz and then to 6.25 kHz per
voice channel. Project 25 was initialed in October 1989
P-25 is suite of standards for digital radio communications developed in North America, providing interoperable
communications between first responder organizations. At the equipment end, while some multi-vendor
interoperability is available, it is our understanding that full interoperability of all features between vendors is still
lacking.
A number of open interface standards are ratified and generally supported between the vendors. i.e. Common
Air, Subscriber Data Peripheral, Console Subsystem, and others which allow some interoperability between
vendors. Interoperability is proven via the Compliance Assessment Program (CAP). The Project 25 CAP is a
voluntary program that allows P25 equipment suppliers to formally demonstrate their products compliance with
a select group of requirements within the P25 suite of standards. The purpose of the P25 CAP is to provide
emergency response agencies with evidence that the communications equipment they are purchasing meets
P25 standards for performance, conformance, and interoperability. The P25 CAP was mandated by Congress in
legislation.
Phase 1 (current) uses standards based digitally modulated Frequency Division Multiple Access (FDMA)
supporting digital voice and data applications. P-25 uses a proprietary voice coder (MBE) by Digital Voice
Systems. Phase II will introduce 2 Time Division Multiple Access (TDMA) time slots per channel and the
Advanced Multi-Band Excitation (AMBE)+2 proprietary voice coder. The first few P-25 Phase II systems are just
now in the process of being deployed. Phase III will likely see a merger with the European Telecommunications
Standards Institute (ETSI) Advanced TETRA standard through project MESA.
Pros and Cons
Pros
Cons
Good spectral efficiency 12.5 kHz/voice

channel in Phase 1 and 6.25 kHz/voice
channel in Phase II
Unique to North American Market
Open Standard drives prices down, enables

interoperability
Not suited to transit data applications without the

addition of unique data channel features which do not
comply with the P-25 Standard generally known as
Transit 25 or Enhanced 25.
Can operate in 12.5 kHz channels
Mobile and Portable Radios are expensive.
Marketed as Mission Critical grade radio
State of the Market
The market in North America is mature. There are approximately 36 firms manufacturing radios or other
ancillary equipment which comply with the P-25 standard. Uptake of this technology has been sluggish due to
funding limitations for these systems and now in the public safety sector, LTE is garnering attention in the public
safety market due to the availability for these agencies to spectrum in the 700 MHz band and the ability to
migrate smart phone like applications to the first responder workforce. This is likely to continue to slow the
adoption of P-25 in the long term.
TETRA
The TETRA standard was developed and first released in 1995 by European Telecommunications Standards
Institute (ETSI) as a digital alternative to analogue trunked systems. It was intended to serve dense urban
markets and to provide voice and data services to mission critical first responder end users.
It has primarily been used by Government Agencies including: First Responders, Transit Operations and Military.
With enhanced encryption capabilities, it is ideal for higher tier public safety users.
In recent years, it has gained strong global momentum and is recently available in North America.
The channel is scheme based on 4 traffic channels (TDMA) per radio carrier with 25 kHz spacing between
carriers.
It is now FCC Part 90 and Industry Canada RSS 119 approved so that it can be deployed where the spectrum is
available to support the 25 KHz wide channel assignments.
Key features include:
Good spectral efficiency
Fast call set-up
Point to point and point to multipoint capabilities
Full duplex voice to other TETRA users or the Public Switched Telephone Network (PSTN)
Data carriage to 115.2 Kbps in 25KHz
Easily expandable
Interoperability between manufacturers
Large pool of TETRA standards compliant manufacturers
Pros and Cons
Pros
Cons
Good spectral efficiency 6.25 kHz/voice channel
New to the North American Market
Open Standard drives prices down, enables

interoperability
Requires wideband 25 kHz channels
Rich global multi-vendor market
Operates at lower system power levels so may

require more sites that competing technologies for
equivalent coverage
Will support transit data applications directly
Does not support simulcast operation
Mature technology with a known technology

roadmap
Supports conventional, single site trunking as
well as multi-site, multicast trunked
configurations
State of the Market
A number of TETRA manufactures including Sepura and PowerTrunk have been instrumental in leading the
TETRA charge on the North American market. There have been a few major TETRA deployments in North
America over the past couple of years. BC Hydro, a large Electrical Power Utility in the Province of British
Columbia is in the process of rolling out a Province wide TETRA system. On the Transit side, New Jersey
Transit has completed a trial and is in the process of rolling out a TETRA system. MTA in New York City we
understand is also trialing TETRA, and the Toronto Transit Commission is deploying a new TETRA Land Mobile
Radio (LMR) system.
Major TETRA systems have been deployed in over 100 countries and a number of the deployments have been
for transit. A typical larger transit example would include SL in Stockholm, Sweden which is supporting
approximately 50 dispatchers operating from 20 dispatch locations. The system comprises 52 Base Station
sites, 3500 mobiles, 1500 portables, and tunnel radio systems all over a Motorola DIMETRA TETRA radio
system.
The market is mature globally however is new to the North American market.
DMR
Digital Mobile Radio (DMR) started as a Standard developed in 2005 by ETSI using TDMA. TDMA is a
multiplexing technique that divides a single radio channel into time slots. In the case of DMR, each 12.5 kHz
radio channel is multiplexed into two time slots. Each radio device on the TDMA network connects using one or
more time slices during which it can transmit or receive data and/or digitized voice. DMR is divided in to three
tiers as follows.
DMR Tier I
DMR Tier I products are for license-free use in the European 446 MHz band.
This part of the standard provides for consumer applications and low-power commercial applications, using a
maximum of 0.5 watt RF power. There have been no commercial launches of DMR Tier 1 products to date.
DMR Tier II
DMR Tier II covers licensed conventional radio systems, mobiles and hand portables operating in land mobile
radio frequency bands from 66-960 MHz. The ETSI DMR Tier II standard is targeted at those users who need
spectral efficiency, advanced voice features and integrated IP data services in licensed bands for high-power
communications. ETSI DMR Tier II specifies two slot TDMA in 12.5 kHz channels. A number of manufacturers
have DMR Tier II compliant products on the market.
DMR Tier III
DMR Tier III covers trunking operation in frequency bands 66-960 MHz. The Tier III standard specifies two slot
TDMA in 12.5 kHz channels. Tier III supports voice and short messaging handling similar to MPT-1327 with
built-in 128 character status messaging and short messaging with up to 288 bits of data in a variety of formats. It
also supports packet data service in a variety of formats, including support for IPv4 and IPv6. Tier III compliant
products were launched in 2012.
Several vendors with proprietary implementations especially of Tier II technology, including:
Motorola
Harris
ICOM
Kenwood
At present, we are aware of only two vendors currently in market with interoperable Tier III compliant
implementations:
Tait Communications
Motorola
Pros and Cons
Pros
Cons
Good spectral efficiency 6.25 kHz/voice

channel
Uptake has been limited. Seems to be a lack of

support for full interoperability between the
vendors.
Operates at higher system power levels so

may require the same number of sites as
technologies with equivalent coverage
making it suitable as a drop-in replacement
for analog systems
Newer technology with a relatively unknown

technology roadmap
At Tier III can support simulcast
Limited number of interoperable Tier III vendors

Marketed as Business Critical and not Mission
Critical
State of the Market
In 2005, a Memorandum of Understanding (MOU) was formed with potential DMR suppliers including Tait Radio
Communications, Fylde Micro, Selex, Motorola, Vertex Standard, Kenwood and Icom to establish common
standards and interoperability. While the DMR standard does not specify the vocoder, MOU members agreed to
use the half rate DVSI AMBE vocoder to ensure interoperability. In 2009, the MOU members set up the DMR
Association to work on interoperability between vendor equipment and to provide information about the DMR
standard. Formal interoperability testing has been taking place since 2010. Results are published on the DMR
Association web site. There are approximately 40 members of the DMR Association. With that said,
interoperable versions of Tier III have been slow to market and in the face of competing technologies, DMR does
seem to have modest risks associated with long term ownership.
This technology is also being marketed as a business critical and generally not as mission critical, so the
ruggedness of the subscriber sets may not be adequate for the transit environment.
Potential Technology Solutions

A qualitative assessment of the relative suitability of three suitable radio technologies for LTC is presented in the
radio technology comparison table below. From the table, it can be seen that DMR provides the lowest cost
option, based on one-time costs to acquire and implement the system, followed closely by TETRA.
From a pure functional suitability perspective, the table shows that TETRA would provide the best technical
solution. It is able to provide full-duplex voice communications while its data carriage capabilities make it ideal
for transit applications. These data capabilities include both its superior throughput due to its ability to bond
multiple channels; and its ability to handle sub-minute polling rates with short packets. Conversely, both DMR
and P-25 radio systems, while well suited to voice communications, are less well suited to transit-related data
carriage.
It is recommended that should LTC decide to acquire and implement either a DMR or P-25 radio system, that it
should also implement a dedicated 3G or 4G solution for the transmission of data to and from its vehicles. The
use of a data network from a public service provider does, however, introduce an ongoing monthly charge
associated with data transmission.
Radio Technology Comparison Table

Vii 2

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Vii 2

Uploaded by

Copyright:

Available Formats

Staff Report #2

Addressing staff resource issues

Fixed route CAD/AVL enhancements

Specialized Scheduling and Dispatch System

Disaster recovery plan

Telephony system replacement business case

Interactive Voice Response system replacement business case

Radio way-forward business case

Server and storage infrastructure update

London Transit Commission

Prepared for London Transit Commission

Document Control Page

London Transit Commission

London Transit Commission Technology Plan

London Transit Commission Technology Plan

February 24, 2016

0.1 Report Outline to Client............................................. 2016-01-21

LTC Technology Vision ...................................................................................................... 2

Technology Plan ................................................................................................................. 5

Project A Fixed Route CAD/AVL Enhancements ................................................. 6

Project B Paratransit Scheduling and Dispatch .................................................... 7

Project C Strategies .............................................................................................. 7

Social Media Policy ..................................................................................... 8

Refresher Training ...................................................................................... 9

Open Data Policy ........................................................................................ 9

Security Plan ............................................................................................. 10

Disaster Recovery Plan ............................................................................ 11

VoIP Telephony System Upgrade ............................................................. 15

Interactive Voice Response (IVR) System ................................................ 16

Initial Actions ............................................................................................. 16

Project F Radio ................................................................................................... 17

Plan Summary ....................................................................................................... 18

Initial Deployment Actions ......................................................................... 18

Overall Future Vision................................................................................. 18

Project C Social Media ........................................................................... 20

Project C Open Data .............................................................................. 21

Project C Security Plan .......................................................................... 22

Project C Disaster Recovery Plan .......................................................... 22

Deployment Considerations ............................................................................................ 24

Deployment Steps and Actions .............................................................................. 24

February 24, 2016

Initial Actions ............................................................................................. 17

Concept of Operations and Business Case Stage ................................... 24

Table of Contents (continued)

Plans Stage ............................................................................................... 24

System Specifications Stage .................................................................... 24

Procurement Stage ................................................................................... 24

Implementation Stage ............................................................................... 25

Projects Costing ..................................................................................................... 26

Alternate Cost Scenarios .......................................................................... 27

Timelines and Capital Program Budgets ............................................................... 27

Staffing Phasing ..................................................................................................... 29

Regular Review of Technology Plan ...................................................................... 29

Appendix A Task 1: Existing Conditions and Needs Assessment

February 24, 2016

Task 1: Existing Conditions and Needs Assessment documents existing technology

Task 2: Technology Analysis considers what gaps need to be addressed to enhance

February 24, 2016

Section 4 highlights staffing considerations for supporting current and future

LTC Technology Vision

New Hires and/or Outsourcing;

Fixed Route CAD/AVL Enhancements;

Paratransit Scheduling and Dispatch Management Procurement;