Enterprise 112 Services in the EU

430 views

Published on

Emergency Services are a global concern. Understanding how they work, and what level of reporting will provide an appropriate response is critical. This presentation shows how Enterprise MLTS/PBX users can deploy NG112 services TODAY that are Over the Top of the legacy network, and ready for the network deployment that is underway.

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
430
On SlideShare
0
From Embeds
0
Number of Embeds
9
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • 1
  • The problem today is that emergency call routing is based on a few basic principals. The first is the telephone number being presented to the network for routing.
    It assumes that each address has a unique telephone number, therefore making the phone number the database key for the emergency call routing entity in the network.
    The database manages the proper mapping of telephone number to the proper agency for called delivery.
  • Once the call is delivered to the PSAP or control room, computer aided dispatch software either queries the telecom provider caller location database, or uses the location data that has been pushed to it over a separate data channel delivering it to the call taker that has the call. Typically the information that’s displayed is the registered name, based on billing, and the registered address for service based on the telecom provider service records.

    Prior to mobility, this process worked quite well, a, fpr the most part, each number was directly related to an address.
  • While this is typically sufficient for residential citizens, individuals within a corporate enterprise have additional challenges due to large campuses with multiple buildings.
    These may have no, or unclear, street addresses as they are on private property, and secure buildings may have access control requirements and multiple floors serviced by various entrances.
    Enterprise users are typically not afforded the same level of location granularity, and while technology is available, it is often too confusing or expensive to deploy.

    Because of this, Enterprise Public Safety issues are often pushed to the side or forgotten about, until a tragedy happens.
  • When deploying a commercial enterprise class system, the very first decision that must be made is what level of granularity of detail is the system going to provide both internally and to public safety control rooms.
    Since many of us are accustomed to the residential model the initial inclination is to build a public automatic location identification record for each individual.
    Unfortunately, this becomes difficult to manage as the database can become quite large, due to user mobility around the campus, and the lack of real time access to the database, moves adds and changes can be difficult and complex to manage, often requiring expensive “middleware” to collect the move data, and batch process changes in the evening.

    In addition to incurring a monthly cost per record, there is historically no real-time access to the database. Therefore changes are not immediately populated, which is when they most likely would be needed the most since a user would be new to their surroundings and may not be able to describe their location.

  • As you can see, 50 phones across 10 floors across three different buildings quickly scales out of control

    Services that manage location data for a few dollars a month per station can get expensive very quickly.
    Imagine 10 floors in each building,
    Three buildings in a campus.

    That works out to 1500 telephone numbers that need to be individually managed monthly.
    At a seemingly minimal cost of two dollars per month per record, that’s $3000 in operational overhead, every single month, and we haven’t even started with the solution yet.
  • By segmenting each building into a zone-based approach, we can provide an appropriate response address for each individual building, while providing responders with floor level details.
    In addition to this information being passed to public safety, local internal first responders can get explicit detail about the exact location of the station that made the emergency call.
    This enables an immediate on-site response, and allows first responders to meet public safety at the appropriate building entrance, ensuring quick and unobstructed passageway to the employee in need of assistance.

    Operationally, we still have the same level of detail, however financially we’ve reduced the requirement for 1500 ALI records( $3000 a month at two dollars per entry) to 30 records( $60 a month at two dollars per entry).
    that works out to be a savings of ~$33,000 annually.
  • First responders need a dispatchable address.
    Providing them detailed information such as cube 2C–231, is simply not relevant while there en route to the location.
    It’s very critical however to internal first responders so that it can be immediately provided once public safety arrives on scene.
  • This is where enterprise locations can provide station level granularity internally by utilizing the additional information from the network.
  • Specific and detailed information can be provided to designated first response teams, campus police officers and EMS, or any other authorize group or individual through smart phone applications text messaging or just about any other medium that’s appropriate to deliver emergency call information. Once the event is created . . .
  • it is easily monitored by centralized security personnel and correlated with other information such as floor plans hazardous material information or even IP video feeds that could then be provided to internal first responders over the wireless network.

    While there is no mechanism in place today to be able to transmit this information to public safety, that is on the near horizon with next-generation emergency services.
    The more that enterprises can prepare today, the better situated they’ll be in the immediate future. Education on how they can be a partner with next-generation emergency services is critical as are expected to ramp up quickly, and at a global scale.
  • When we look at enterprise PBX systems, there are three basic system requirements that can be utilized for emergency calls within the enterprise network.
    EENA’s message needs to be clear on these simple, and vendor agnostic points.

    When emergencies happen, normally panic strikes. And even the most seasoned employee can become confused.
    Quite often, since we don’t dial access codes on our cell phones or in our homes, we find that many people will forget to dial the access code when calling emergency services from a PBX or ML TS telephone.
    Fortunately, this is a simple programming or dial plan fix in the system that will allow emergency codes and short codes to be dialed both with and without an access code.
    When provisioning, system administrators should take special care to also program the system to prevent a high number of accidental mis-dials in the system.
  • Understanding that an emergency call has taken place is also critical for internal first responders.
    When someone dials an emergency number, the system should provide alerting to designated stations that an emergency call has occurred.

    This allows internal staff to establish and follow specific procedures for assisting with the emergency, or at the least, ready to receive public safety when they arrive at the building.
  • The third basic system requirement is one that’s more policy.

    The interception or termination of emergency calls internally should be prohibited unless trained staff have been assigned to this function.
    Public safety call takers and dispatchers have received specialized training in handling emergency calls, and by answering or intercepting the call locally, MLTS users are delaying what could be lifesaving assistance.
  • VoIP devices on the network are entities that can be discovered using a variety of common protocols, however, coordination and cooperation with the IT network staff is critical. Areas within a building can be serviced by an IP subnet, or range of IP addresses, so that a simple examination and comparison can easily be made. Think of it this way, you already know that I live on Main Street. When I call for help, you just need the house number. In the same manner, a device will report that it’s at 72.148.150.97. You know that 72.148.150.XX refers to the 15th floor of the building. Based on this, you have the general area of where the emergency is. As long as this space is reasonably searchable, help can be immediately dispatched.

    Prior to VLANs, network segmentation was not always possible or easy. With the latest series of data switching equipment available, VLAN segmentation is a simple administrative task.
  • if more granular location information is required, again, common network protocols allow the network administrator to scan the data switches on the network, retrieving what is known as the “Bridge MIB” through standard SNMP queries. This Bridge MIB is basically a listing of Mac addresses that are attached to specific data switch ports. While this does provide very specific location information, it must be coupled with what is commonly referred to as a wire map database. This wire map correlates what specific jacks are wired to specific switch ports. Users that deploy this strategy must maintain accurate cable records and control moves, adds an change work diligently. Will t
  • while this level of information certainly adds relevant data to the question of location, it by itself is not typically enough to provide discrete information to specifically locate an individual. Fortunately corporate enterprise networks contain additional data resources that can be utilized and queried. Information from LDAP and active directory can provide details on the individual. The user themselves may even contribute additional personal or medical information that they have opted in for. Relevant data points from the wireless LAN infrastructure or the ML TS PBX itself can provide visibility into the device that was used to place an emergency call. That information, correlated with cable management records can be utilized to fine tune the location. And finally, critical environmental information from smart buildings or HVAC systems can provide important clues such is ambient temperature or smoke conditions in the origination area of the emergency call. When looking at an emergency call hangups, this additional information can be critical in determining real calls from hoax calls.

    This model also will neatly packages this information for retrieval or transmission to public safety entities, once a next generation emergency services network infrastructure is put in place.
  • Inexpensive, yet highly functional software modules are that provide verbose notification to emergency call events on the network.
    1st Responder clients can be anywhere on the network that has connectivity to the enterprise will. This would include remote branch offices or VPN users.
    In addition to providing local on-site responders with critical information the server also acts as an integration point for the conveyance of rich location data to public safety.
  • Because we are delivering detailed location information via SIP with the call . . . .

    ANI and ALI databases are NO LONGER relevant when the originating endpoint or the PBX they are attached too
    is capable of sending contextual information and references to additional data like:

    Floorplans
    Environmental Data
    Video Feeds
    HazMat Material Safety Data Sheets
    Personal Medical Information (if the user allows)
  • Nomadic behavior can be seen in almost any device today. Any device can be nomadic

    TDM devices, although static most of the time, may provide users with virtual office login capabilities. This effectively changes the service parameters about the device based on who is using it.
    Voice over IP devices become problematic because of the ability for users to move themselves without administrative intervention.
    Wireless LAN devices are constantly on the move as an inherent function of their technology.
    The most problematic scenarios today, remote VPN teleworkers.

    Not only is their location nomadic in nature, in many cases it is difficult if not impossible to achieve any level of forensics on the remote network they are attached to.
    Fortunately, the enterprise MLTS PBX can provide functionality such as on-site notification, proper call routing to VPC carriers which can terminate calls to remote control rooms.
    This functionality, while widely available in the US and North America, is quickly expanding across the EU member states. Utilizing these services, applications exist where remote teleworkers
    can manage their location information through the use of dynamic web-based location dashboard that was specifically designed for emergency call mobility from devices that are external to the enterprise network.

  • Enterprise 112 Services in the EU

    1. 1. Enterprise Location Addressing the problem of location reporting from callers within corporate networks Presented by: Mark J. Fletcher, ENP (Fletch) Chief Architect – Worldwide Public Safety Solutions FletcherM@Avaya.com +1 908 848-2602
    2. 2. © 2014 Avaya Inc. All rights reserved. 22 The problem  Emergency calling today is based on: – TN presentation to the network for routing Citizen 555-1234 Public Safety Agency “A” Public Safety Agency “B” Public Safety Agency “C” SRDB* 555-1234 = Agcy A 555-4567 = Agcy B 555-6789 = Acgy C *Selective Router Data Base Citizen 555-4567 Citizen 555-6789 Telecom Provider
    3. 3. © 2014 Avaya Inc. All rights reserved. 33 CLocDB* 555-1234 = Addr A 555-4567 = Addr B 555-6789 = Addr C The problem  Emergency calling today is based on: – TN presentation to the network for routing – TN Presentation to the Control Room for response location reference – Registered name – Registered address Citizen 555-1234 Public Safety Agency “A” SRDB 555-1234 = Agcy A 555-4567 = Agcy B 555-6789 = Acgy C *Caller Location Data Base Telecom Provider 555-1234 David Smith 3324 Arch St
    4. 4. © 2014 Avaya Inc. All rights reserved. 44 CLocDB* 555-1234 = Addr A 555-4567 = Addr B 555-6789 = Addr C The problem  Emergency calling today is based on: – TN presentation to the network for routing – TN Presentation to the Control Room for response location reference – Registered name – Registered address – While this is typically sufficient for a residential citizen, individuals at work have additional challenges due to: – Large Campuses with multiple buildings – Unclear street addresses or no address – Buildings with access control and multiple floors Citizen 555-1234 Public Safety Agency “A” SRDB 555-1234 = Agcy A 555-4567 = Agcy B 555-6789 = Acgy C *Caller Location Data Base Telecom Provider 555-1234 David Smith 3324 Arch St
    5. 5. © 2014 Avaya Inc. All rights reserved. 55 The primary confusion is the granularity of detail needed Since we are used to the ‘residential model’, the initial inclination is to have a Public ALI record for each individual. – Large Database – Complex to manage – Incurs monthly costs There are 50 phones on this floor, imagine 10 floors in the building and 3 buildings in a campus. That becomes 1500 TN’s to be managed monthly.
    6. 6. © 2014 Avaya Inc. All rights reserved. 66 The problem scales out of control quickly 1,500 Records $3,000 Monthly $36,000 Annually
    7. 7. © 2014 Avaya Inc. All rights reserved. 77 Zones reduces the number of Managed TNs required ZONE ZONE ZONE ZONE ZONE ZONE ZONE ZONE ZONE ZONE ZONE ZONE ZONE ZONE ZONE ZONE ZONE ZONE ZONE ZONE ZONE ZONE ZONE ZONE ZONE ZONE ZONE ZONE ZONE ZONE Response Address A Response Address B Response Address C 30 Records $60 Monthly $1,800 Annually
    8. 8. © 2014 Avaya Inc. All rights reserved. 8 Emergency at Cube 2C-231 – Where is that!? Responders on scene need to be ready and know help is coming. ? ? ?
    9. 9. © 2014 Avaya Inc. All rights reserved. 99 Enterprise Location granularity INTERNALLY  Enterprise environments can utilize additional call handling technology to aid in response:
    10. 10. © 2014 Avaya Inc. All rights reserved. 1010 Enterprise Location granularity INTERNALLY  Enterprise environments can utilize additional call handling technology to aid in response: – Designated 1st Response Teams – Campus Police Officers and EMS – Any other authorized group or individual EMERGENCY
    11. 11. © 2014 Avaya Inc. All rights reserved. 1111 Enterprise Location granularity INTERNALLY  Enterprise environments can utilize additional call handling technology to aid in response: – Designated 1st Response Teams – Campus Police Officers and EMS – Any other authorized group or individual  Data that can be provided includes – Floor Plan – HazMat – IP Video Feeds EMERGENCY
    12. 12. © 2014 Avaya Inc. All rights reserved. 1212 Basic System Requirements  Direct access to Emergency Services Eliminating the ‘Trunk Access Code’ (TAC)
    13. 13. © 2014 Avaya Inc. All rights reserved. 1313 Basic System Requirements  Direct access to Emergency Services Eliminating the ‘Trunk Access Code’ (TAC)  On Site Notification Alerting to devices that an emergency call has occurred
    14. 14. © 2014 Avaya Inc. All rights reserved. 1414 Basic System Requirements  Direct access to Emergency Services Eliminating the ‘Trunk Access Code’ (TAC)  On Site Notification Alerting to devices that an emergency call has occurred  Interception or termination of calls internally prohibited to untrained internal staff PD
    15. 15. © 2014 Avaya Inc. All rights reserved. 15 Location Discovery Understanding where the emergency is occurring is the key piece of information required to provide assistance. However the problem can be tackled – with cooperation from the network staff. What is perceived as the biggest Enterprise challenge?
    16. 16. © 2014 Avaya Inc. All rights reserved. 16 Common VoIP Location Discovery Mechanisms Subnet (Zone Level reporting) IP Subnet maps to floor plan Instantaneous discovery ADLR Additional Data Location Repository
    17. 17. © 2014 Avaya Inc. All rights reserved. 17 Common VoIP Location Discovery Mechanisms Subnet (Zone Level reporting) IP Subnet maps to floor plan Instantaneous discovery Switchport (Station Level reporting) Maps to jack via wiremap Near real-time discovery ADLR Additional Data Location Repository
    18. 18. © 2014 Avaya Inc. All rights reserved. 18 Cable Mgmt PBX User Data WLAN User Data Enviro Info LDAP Active Directory Opt In Info Smart Building Common VoIP Location Discovery Mechanisms Subnet (Zone Level reporting) IP Subnet maps to floor plan Instantaneous discovery Switchport (Station Level reporting) Maps to jack via wiremap Near real-time discovery ADLR Additional Data Location Repository Data is packaged ready for pick-up by the Control Room or 1st Responder
    19. 19. © 2014 Avaya Inc. All rights reserved. 1919 Enhanced On Site Notification with ADDITIONAL DATA Correlation of Information • Screen Pop Alert Clients can be anywhere • Detailed Floor Plans / Video • Integrations with Smart Building Data • 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. A hang up call now becomes a hang up with high temperature readings in the area.
    20. 20. © 2014 Avaya Inc. All rights reserved. 20 Deliver detailed location information ‘by reference’ today and ‘by value’ using SIP in the future . . . . SRDB and ALI databases will NO LONGER BE REQUIRED Nor will their management and monthly fees. Next Generation Emergency Services: Today: OVER The TOP NG Emergency Services Tomorrow: URI/URL sent VIA the SIP header NG Emergency Services Data Aggregator ANI/ or Location Data Over the Top NG Emergency Services Getting the network ready TODAY = No Migration
    21. 21. © 2014 Avaya Inc. All rights reserved. 2121 Remote and Home based Devices  Almost any device can be nomadic – TDM (Virtual Office at remote location) – VoIP (User Moves without notice) – WLAN (Inherent Mobility built in device) – Remote Workers (Nomadic VPN off premesis)  Enterprise MLTS / PBX can provide tracking – On Site Notification – Proper call routing – Caller ID (ANI) Manipulation  VPC Provider will be required for REMOTE users
    22. 22. © 2014 Avaya Inc. All rights reserved. 22 CONCLUSION: While challenges do exist, enterprise networks can provide valuable and relevant information to public safety control rooms that can significantly increase both location accuracy and on-site situational awareness of emergency calls from within enterprise networks. The most significant challenges are public awareness, and published best practices/legislation requiring commercial entities to implement a solution.
    23. 23. © 2014 Avaya Inc. All rights reserved. 2323

    ×