1. HIDE THIS SLIDE - INSTRUCTIONS
There is a small ICON in the TOP LEFT CORNER of each slide that looks like this: This ICON is set to appear automatically after the LAST build in the slide and is designed to to indicate to the presenter the END of the slide builds for that slide. If you add animations, make sure you move this to the END of the animation list for the slide. If there are NO animations on the slide, like this slide, the graphic will appear immediately.

2. Enterprise NG911 Now Using an Over the Top Architecture
Tim Kenyon, ENP Mark J. Fletcher, ENP
President / CEO Chief Architect – Worldwide
Conveyant Systems, Inc. Public Safety Solutions - AVAYA

3. Who I am . . . and why you should care
Tim Kenyon, ENP President / CEO Conveyant Systems, Inc.
Nortel / Avaya OEM Partner
PC Attendant Consoles
Embedded WLAN 8100 E911
Avaya Internal E911 Solution
Our Public Safety Industry Firsts:
1st Avaya E911 Select Product
1st Avaya IP Office SNMP Compliant
1st Avaya Internal Solution
1st HTML Based Alert Content
Mark J. Fletcher, ENP Chief Architect AVAYA Public Safety Solutions
FCC Disability Advisory Committee
APCO Standards Definition Committee
NENA Institute Board Member
7 US Patents for Public Safety related technology
The Reality of the ‘Over The Top’ Model
NOT about ALI Database Management
Today’s ALI has useless additional data
NG 911 replaces PS-ALI with Additional Data
Reality is PSAPs rarely view or consider the information beyond the street address as valid
REAL-TIME data is possible NOW via OTT

4. 1968
The Problem
What’s the number for 911?

5. The solution was to build an Emergency Telephone Network - BUT
Public Safety
Agency
“A”
It was based on 1970’s assumptions
Phone Numbers were identities:
They were UNIQUE
They were SINGLE APPEARANCES
They were FIXED LOCATIONS
The network knew 3 important things:
WHO you were
WHERE you were located
WHAT agency provided service to you.
Citizen
SRDB*
= Agcy A
= Agcy B
= Acgy C
Telecom Provider
Citizen
Public Safety
Agency
“B”
SRDB*
= Agcy A
= Agcy B
= Acgy C
Citizen
Public Safety
Agency
“C”
*Selective Router
Data Base

6. 2000
The Problem
IP networks introduced MOBILITY

7. Device Location Discovery (IP Devices)
Layer 2 – Switch Port
Layer 3 – IP Subnet/Mask
Very precise – Zone or Station
Requires a valid wire map
MAC work must be controlled
Less granular – Zone only
Easily managed with VLANs
Very flexible for user MAC work
/24
911 ZONE 1
/12
911 ZONE 2
/24
911 ZONE 3
/12
911 ZONE 4
/24
911 ZONE 5

8. 2016
Today’s NEW Problem
Internal and External Public Safety Situational Awareness

9. SITUATIONAL AWARENESS and the ADR
ADR – Additional Data Repository
When user endpoints make an emergency call, the location as well as other ‘BIG DATA’ about the incident is relevant and needs to be conveyed to 1st responders and internal staff.

10. ROUTING – Not difficult if you know the LOCATION
Accomplished LOCALLY or via CLOUD
Emergency call routing is geographically specific
UC Mobility creates additional challenges
Wired IP sets moving
Virtual Office / Touchdown cubes
Work at Home users
Nomadic users on Public Networks
Routing can be simplified by isolating to a location and dispatchable address
Consolidate response to BUILDING
Minimizes monthly OPEX
Maximizes INTERNAL awareness

11. Emergency Calling - AWARENESS
AVAYA
4655 Great American Parkway
Santa Clara, California
What PUBLIC SAFETY Responders Need
Dispatchable Address What they need to get to the building
What INTERNAL Responders Need
Everything you can possibly give them
Explicit location information
Building environmental information heat/sprinklers
Floor plans
Links to video feeds in the affected area
Event indications like an AED removal
MSDS and Hazmat information
Big Data from the Internet of Things
UNFORTUNATELY –
NONE OF THIS has ANYTHING to do with the phone system
It’s about building an Emergency Response Solution using data already in your network and providing it to Public Safety
BIG DATA

12. THE PBX CANT SEND LOCATION DATA TO THE 911 PSAP
What ?

13. The problem – The Wrong Solution
Public Safety
Agency
“A”
Managing the ANI/ALI database is costly and difficult.
This becomes the largest expense for MLTS 9-1-1
Unclear additional info (Cube 2C-231?!)
Often not populated
Often incorrect information
9-1-1 Telecommunicators have told us that the data found in this 30 character field is simply not reliable or relevant.
With the amount of other information coming in, this becomes superfluous and is often ‘lost in translation’.
MLTS User
BUSINESS – MLTS
AVAYA, Inc.
4655 Great American Pkwy
2nd FL Cube 2C-231
Telecom Provider
SRDB
= Agcy A
= Agcy B
= Acgy C
CLocDB*
= Addr A
= Addr B
= Addr C
*Caller Location
Data Base

14. What most people are afraid to admit . . .
“Common communications we use every day have eclipsed the capabilities of E UC and mobility allow devices to be anywhere, the phone number is no longer a relevant indicator of location and presence. Using phone numbers for routing is archaic and unreliable, and additionally, there is no way to attach multimedia to the call. We cannot wait for NG Over The Top NG9-1-1 will save lives today.”
Mark J. Fletcher, ENP
Chief Architect – Avaya Worldwide Public Safety Solutions

15. Why Most Enterprise E911 Deployments Fail
Mass Confusion – What’s needed/required
Too Complex – Trying to boil the ocean
No Plan – Poor measurement of success
The three primary reasons why most enterprising 911 deployments fail are:
MASS CONFUSION - administrators simply just don’t understand what is required to solve the problem, or what capabilities the PSAP actually has to determine the location of the caller.
TOO COMPLEX - many vendors utilize this lack of understanding at the IT administrator level, to make enterprise E 911 sound complex and difficult to solve. This allows them to extract large budgets for the and implementation, when in reality simple constructs can be put in place that can easily solve the problem at hand
NO PLAN - because enterprise IT administrators don’t understand 911, it becomes difficult for them to communicate their requirements for solution. The thinking behind public safety is very specific and driven to a particular solution. IT administrators have a completely different agenda, and have very little exposure to public safety and their requirements.
Because all of these, E911 solutions are deployed in a very haphazard manner, without proper design, potentially increasing risk to employees instead of minimizing it.

16. SENTRY – A New Approach to an Old Problem
What is Sentry™?
It’s NOT a box. It’s a modular framework designed to provide the functions that are needed to resolve Enterprise E9-1-1 location and notification issues
Affordable
Only buy the modules you need
Simple
Deployment costs are low compared to current solutions – yet more functionality
VM Based – Flexibility of deployment and resiliency means easy licensing
No proprietary hardware or Single Point of Failure appliances
Efficient
Enhances E9-1-1 capabilities of the PBX
Reduce or eliminate PS-ALI / monthly recurring OpEx charges from the LEC
Flexible for in building, branch and remote workers
This is why we developed SENTRY, the new standard in enterprise E911.
SENTRY is a modular framework purpose built to provide the functions that are needed to solve the enterprise E911 location and notification issues.
By modularizing the solution, administrators only need to pay for and deploy the specific modules they need in their environment.
This keeps the solution simple, and by utilizing virtual machine instances and no proprietary hardware, full resiliency and redundancy becomes part of the deployment, and there’s no reliance on proprietary hardware or single point of failure that are found in many other appliances on the market today.
This operational model enhances the capabilities already built into the PBX, and eliminates the use of private switch ALI accounts which create monthly OpEx charges from the LEC. This solution and construct has the flexibility that allows it to provide either building, branch, or support for remote workers within a single solution.

17. Enterprise Requirements
NOW
Enterprise Requirements
Delivering what is needed NOW

18. Basic System Requirements - KARI’S LAW
Direct access to Emergency Services Eliminating the ‘Trunk Access Code’ (TAC)
Alerting to devices that an emergency call has occurred
No Interception of calls internally to untrained staff PD
Direct access to Emergency Services Eliminating the ‘Trunk Access Code’ (TAC)
Alerting to devices that an emergency call has occurred
No Interception of calls internally to untrained staff

19. Capturing Data & Providing Access
LDAP
Smart Building
Enviro
Info
Cable
Mgmt
ADR
Additional Data
Repository
Active
Directory
Opt In
Info
WLAN
User Data
PBX
User Data
Data is packaged ready for pick-up by Public Safety or Designated 1st Responders

20. Notification to INTERNAL 1st Responders
AVAYA
4655 Great American Parkway
Santa Clara, California
Screen Pop Alert Clients can be anywhere
Detailed Floor Plans / Video
Zone based Routing and Escalation
Correlation of all information available
Integration with 3rd Party Smart Buildings
Mobile apps, Web based or Reader boards
By empowering the Enterprise with information about the incident they can contribute additional data simplifying the call for help.

21. Workflow for Delivering the Data to Public Safety
Direct to 911 unimpeded
Device registers on network
Location Discovery Initiated
Relevant Info Collected
Fixed URL:
Web DMZ
Emergency event or trigger occurs
Resources are Correlated
Context Store
Created
Bldg Security
Fire / EMS

22. Migration of the Services
TOMORROW
Ready for tomorrows architecture

23. THE FUTURE FOR ENTERPRISE PUBLIC SAFETY
Breeze™
Dynamic Team Formation
Current VM
Deployment
Future Breeze™
Deployment
WebRTC
100% RTU Migration
TRACKER
LAYER 2
RT Speech
SCOUT
LAYER 3
BEACON
WLAN
WebText
Mobile Video

24. Conveyant Sentry Presentation
Thank You for your Time Q & A ?