May 11, 2010
Emerging Mobile Technologies Group
Telcordia Applied Research
Mike Loushine (PM) Phiroz Madon
Andrei Ghetie Dan Harasty
Melbourne Barton
Don Lukacs
Vijay Varma
Nicholas Linnenkamp
Copyright © 2010 Telcordia Technologies, Inc.
All rights reserved.

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

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

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

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

DM
Client
Supporting Standards –
OMA Presence SIMPLE V2 Specification
DM
Server
DM-1
PRS-17
Watcher
Agent
XDM-10
Watcher
Information
Subscriber
PRS-16
SIP/IP
Core
PRS-4
Resource
Resource
List
List Server
PRS-11
XDM-2
PRS-10
PRS-9
PRS-2
PRS-14
PRS-15
Content
Server
PRS-13
PRS-1 PRS-6
Presence
XDMS
RLS
XDMS
PRS-8
PRS-19
PRS-12
PRS-3
Server
Server
PRS-5
PRS-20
Presence
Content
XDMS
PRS-21
PRS-7
Subscription Proxy
Shared
List
XDMS
XDM-4
PRS-18
XDM-1
XDMC
IP-1
XDM-3
SIP/IP Core
Aggregation Proxy
XDM-8
Cross-Network Proxy
NNI-1
Cross-Network Proxy
Remote Network
6
NOTE: Bold boxes identify Presence SIMPLE functional entities that are defined by this document.
Bold arrows identify Presence SIMPLE reference points that are defined by this document.
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

Supporting Standards –
3GPP IMS Emergency Services Specification
(3GPP TS 23.267)
Implementer: FOKUS
UE
Gm
LRF
P-CSCF
Mw
E-CSCF
Mw
MI
I4
EATF
Le (e.g. E2) from PSAP
Mm to PSAP or ECS via IP multimedia
Network
Mi/Mg to PSAP
(via PSTN via BGCF/
MGCF)
Implementation:
 Open Source IMS Core
Network
 Emergency Services Branch
S-CSCF
Mm/Mw from PSAP
7
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

Supporting Standards –
IETF HELD Specification
Implementer: BBN
<MJL: FInd a picture or else center text.>
Implementation:
 HELD Client
 HELD Location Information
Server (LIS)
Source: Andrew Corporation
8
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

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
9

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
10

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

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
12
 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

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

 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
15

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

17

18

 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.
19