1. Emergency Services Demo with Location-based Services, IMS, and WiMAX Emerging Mobile Technologies Group Telcordia Applied Research Mike Loushine (PM)Phiroz Madon Andrei GhetieDan Harasty Melbourne BartonVijay Varma Don LukacsNicholas Linnenkamp May 11, 2010 Copyright © 2010 Telcordia Technologies, Inc. All rights reserved.

2. 2 Outline  Demo Objectives  Technology Standards Supported  Demo Scenario  Demo Architecture  Demo Contributions  On to the Demo…  Lessons Learned

3. 3 Demo Objectives  Explore the potential of ubiquitous location- based services and the IP Multimedia Services (IMS) platform  Demonstrate using IMS location and presence service building-blocks to make an E911 emergency services application

4. 4 Demo Objectives  Provide feedback to Standards Forums based on experiences from the demonstrations

5. 5 Supporting Standards – OMA LOCSIP Technical Specification Implementer: Telcordia Implementation:  Location Client  Location Server  Resource List Server Role in Demo:  Provide ongoing locations, situational awareness for all actors involved in Emergency scenario  Support location-based resource list queries Location Client Location Server LS-1 PRS-4 RLS XDMS XDM-2 -14 LS-2 IP-1 Remote SIP/IP Core SIP/IP Core GPM.PEM-1 Location Policy XDMS PRS-9 Shared List XDMS PRS-10 Home Subscription Agent PRS-17 XDM Enabler XDMC TrustedXDMC XDM-12 Resource List Server

6. 6 Supporting Standards – OMA Presence SIMPLE V2 Specification Implementer: Telcordia Implementation:  Presence Source  Watcher  Presence Server  Resource List Server Role in Demo:  Provide situational awareness of actors in scenario through status publish and notifications Presence Server Watcher Presence Source Resource List Server

7. 7 Supporting Standards – 3GPP IMS Emergency Services Specification (3GPP TS 23.267) Implementer: FOKUS Implementation:  Open Source IMS Core Network  Emergency Services Branch Role in Demo:  Routes IMS SIP-based messages between multiple clients and IMS application servers  Routes 911 call from person in trouble to appropriate PSAP

8. 8 Supporting Standards – IETF HELD Specification Implementer: BBN Implementation:  HELD Client  HELD Location Information Server (LIS) Role in Demo:  Enables IMS Client who makes 911 call to determine its own location  Location is then published over IMS, providing dispatcher with the location Source: Andrew Corporation

9. 9 Supporting Standards – IETF LoST Specification Implementer: Columbia U. Implementation:  Location-to-Service Translation (LoST) Server Role in Demo:  Provides PSAP URI based on terminal location

10. 10 GSMA Rich Communication Suite – Release 1, 2, and 3 Implementer: Telcordia Implementation:  RCS Device  Presence Server Role in Demo:  Publish presence to a Presence Server  Publish location information to the LOCSIP Location Server  Note: not part of any current specification

11. 11 WiMAX (IEEE 802.16e Specification) Implementer: MAXWell Lab Implementation:  WiMAX Network Role in Demo:  Transmit and receive voice, video, and situational awareness data ASN BS ASN GW CPE CSN HA/ Router AAA DHCP/ DNS PF R1 R3 R6 Internet / Application Service Provider (ASP) Network

12. 12 Standards functionality demonstrated…  3GPP IMS to  provide a SIP/IP core network infrastructure  route 911 calls  OMA LOCSIP to  convey terminal locations  provide situational awareness  OMA Presence SIMPLE to  provide situational awareness through status publish and notifications  IETF LoST to  select the PSAP to answer 911 calls  GSMA RCS to  publish locations and presence  perform user-based position determination of terminals  IETF HELD to  perform network-based position determination of terminals  WiMAX to  transmit and receive voice, video, and situational awareness data

13. 13 Demo Scenario – PSAP View

14. 14 Demo Architecture ROVER Server PSAP HELD LIS Google Network Location Service 911 Caller Location Server Presence Server LOST Server Resource List Server HSS IMS Core I-CSCF P-CSCF E-CSCF LRF S-CSCF PGFD Fire Chief UMDP Patrol Car WiMAX Network (Interoperability – Maryland Day) MyVue Clients LOCSIP Servers

15. 15 Demo Contributions  Created prototype of the OMA LOCSIP Architecture  Location Server  Location Client  Resource List Server  Performed interoperability test between Telcordia LOCSIP Location Server and FOKUS Emergency Services IMS Core  LOCSIP Location Server - LRF Interface  Integrated OMA LOCSIP and Presence Services  Presence Server – LOCSIP Location Server  Implemented aspects of GSMA Rich Communication Suite Release 3 approach to location-based services with OMA LOCSIP and Presence Services  RCS Device – LOCSIP Location Server  RCS Device – Presence Server

16. 16 Contact For more information, contact : Mike Loushine Senior Scientist / Program Manager mloushin@telcordia.com Office: +1 (732) 758-5358 Mobile: +1 (732) 762-0242

17. 17 Sit back and enjoy the demos…

18. 18 Demo Presentation…

19. 19 Lessons Learned  IMS location, presence, resource-list building-blocks are quite versatile for constructing a variety of useful services and applications. Some additional ideas for location-based services:  Lost child or pet location  Traffic monitoring over a comprehensive set of roads. Integration of this service with people’s car GPS systems  Social networking with the added dimension of location  Situational awareness applications.  SIP headers, their values and meanings, can be open to interpretation!  For interoperability, following the specs can get you 75% of the way  After that, end-to-end debugging is needed.  PIDF-LO XML format is also open to interpretation  RFC 4479 “A Data Model for Presence” makes a significant departure from earlier RFCs (most notably, 4119) on the PIDF XML format  End-to-end debugging is needed, for interoperability  Performance and scaling are issues that will have to be systematically addressed  We started seeing problems (over a wired Ethernet) at ~20 SIP messages/sec  A NOTIFY message with a RCS-specified XML body is 2 K bytes  Problems are typically due to time-outs caused by long wait times as messages go through the core.