Emergency Services in PacketCableTM 2.0

1
Emergency Services in PacketCableTM 2.0

• Sandeep Sharma
• Senior Architect, Signaling Protocols
• SDO Emergency Services Coordination Workshop,
  Columbia University, New York
• October 5 and 6, 2006

2
CableLabs Introduction

• Established in 1988, CableLabs is a non-profit,
  research and development organization for the
  cable industry
• Members are exclusively cable system operators
• Board of Directors is made up of member company
  CEOs
• Technical leadership is provided by member
  company CTOs
• There are currently 52 member cable companies
  representing 82 million cable subscribers in
  North America, Latin America, Europe, and Japan
• US (62M)
• Canada (7M)
• Europe (10M)
• Japan (1.5M)
• Latin America (1.5M)

3
CableLabs Mission

• Plan, fund and perform RD projects
• CableLabs works with the manufacturing community
  to develop technology to meet the business and
  strategic initiatives of its members
• Funnel relevant research to member companies
• Serve as a clearinghouse to provide information
  on current and prospective technological advances
  through strategic and technical assessments
• Develop technology for new businesses
• Foster equipment development
• Interoperability specifications and certification
  activities
• Coordination with relevant industry fora
• ITU, 3GPP, ETSI, SCTE, IETF, UPnP, DLNA

4
What is PacketCableTM?

• The PacketCableTM project was founded in 1997 to
  develop an architecture for real-time IP
  communication services over cable
• PacketCable 1.0 and 1.5
• An end-to-end architecture for providing IP-based
  digital telephony services
• Signaling based on MGCP to the endpoints and SIP
  between call management servers, provisioning,
  QoS, management, PSTN interconnect, accounting,
  security, codecs
• Leveraging DOCSIS 1.1 and 2.0 access network
  technologies
• PacketCable Multimedia
• A QoS architecture that support a wide range of
  QoS-enabled, beyond-voice services
• Leverages existing mechanisms defined in
  PacketCable 1.01.5 and DOCSIS 1.1 2.0
• PacketCable 2.0
• Defines an end-to-end architecture for providing
  real-time IP communication services based
  entirely on SIP and 3GPP IMS
• Extend cables existing Internet Protocol service
  environment to accelerate the convergence of
  voice, video, data, and mobility technologies

5
IMS in PacketCable 2.0
PacketCable 2.0 integrated an IMS core into the
cable architecture
Cable-based provisioning, management, and
accounting
PSTN Interconnect via PacketCable 1.5
Client-managed NAT Firewall Traversal
Interconnect with PacketCable 1.5 digital
telephony networks and clients (E-MTAs)
IP connectivity via DOCSIS Access Network
Policy Control via PacketCable Multimedia
Enhancements based upon cable requirements
Cable clients
6
Application Agnostic Architecture
Cable Application Servers
Residential SIP Telephony
Wireless Cellular Integration
Video Application
XYZ Application
OSS
BGCF
HSS
PacketCable 2.0 Network (IMS based)
I-CSCF
S-CSCF
P-CSCF
Cable Clients
7
PacketCable 2.0 Residential SIP Telephony (RST)

• Application that makes use of PacketCable 2.0
  architecture
• 5 published documents http//www.packetcable.com
  /specifications/packetcableapps.html
• Provides traditional North American residential
  digital telephony features
• Examples of supported features
• Caller ID / Calling name delivery
• Call Forwarding (multiple variants)
• Call Blocking (inbound, outbound)
• Multi party features (Call Waiting, Hold,
  Transfer, Three Way calling)
• Call History (Auto recall, Auto callback)
• Operator Services
• Emergency Services
• Do Not Disturb, Distinctive Alerting, Message
  Waiting, Speed Dialing, Call Trace
• Rest of the presentation references PacketCable
  2.0 RST Feature Specification

8
RST Emergency Services Scope

• Identification and storage of location
  information by UE
• Identification of emergency calls at UE and/or
  CSCF servers
• Conveyance of UE location information in SIP
  signaling for emergency calls
• Special handling (establishing QoS and priority
  treatment) for emergency calls post I01
• Handling of emergency calls at SIP Proxies and
  PacketCable 2.0 routing server functions

9
RST Emergency Services Assumptions

• Applicability of NENA i1, i2 and i3
• Use of IETF protocols and methodologies for
  location determination and conveyance
• Location information is provided to UE via
  DHCPv6/v4
• UE supports DHCP protocol and associated options
  for geographical location (RFC 3825) and civic
  location (draft-ietf-geopriv-dhcp-civil-09)
• UE supports SIP multipart MIME (RFC 3261) and
  SIPPING location conveyance I-D with PIDF-LO
  object(s) to convey location information in SIP
  message bodies

10
RST Emergency Call Handling

• At UE boot time
• UE request its location from the access network
  using DHCP
• UE is provisioned by its home network backoffice
  systems with the digit map that identifies the
  emergency dial string
• When an emergency call is initiated, UE sends an
  INVITE with the universal emergency service URN
  URNservicesos as Request-URI and To header
• INVITE request also includes the location
  obtained from DHCP in its message body in the
  form of PIDF-LO as defined in draft-ietf-sip-locat
  ion-conveyance-04
• The P-CSCF detects the emergency call and
  forwards the call to E-CSCF
• E-CSCF follows the procedures outlined in RST
  specification for the various NENA phases to
  forward the call to PSAP

11
RST Emergency Services UE Requirements

• Minimum UE state (registered and authenticated)
• Emergency calling configuration (e.g. digit map)
• Obtain location using DHCP
• Recognition of an emergency call
• Basic call modifications while on an emergency
  call
• PSAP Operator Ringback
• PSAP Callback (PSAP originated emergency call)
• Feature Interactions
• Signaling Identification of an emergency call
• Priority emergency
• Media QOS for emergency call
• Mark media packets with special DSCP values

12
RST Emergency Services P-CSCF Requirements

• Recognition of UE-originated emergency call
• Forwarding the call to an E-CSCF
• Handling of Network-initiated de-registration
  during emergency calls

13
RST Emergency Services E-CSCF requirements

• Call routing in NENA i3 architecture
• Use location in INVITE to determine Request URI
  of PSAP (using draft-ietf-ecrit-lost-01 for
  example), currently left FFS as IETF documents
  mature
• Forward INVITE to PSAP URI
• Call routing in NENA i2
• Use location in INVITE to determine ESRN and ESQK
  (from a VoIP Positioning Center VPC)
• Route INVITE to ESGW (on to PSAP)
• Call routing in NENA Pre-i2
• E-CSCF routes to dedicated selective router
• Selective router routes to PSAP based on
  telephone number of caller
• Location in INVITE not used
• Call routing in NENA i1
• Call is routed to telephone number associated
  with PSAP
• Does not make use of dedicated selective router
• Route INVITE to MGC
• Call treated as normal PSTN call

14
References

• CableLabs
• http//www.cablelabs.com
• DOCSIS Specifications
• http//www.cablemodem.com/specifications/
• Overall PacketCableTM project
• http//www.packetcable.com
• PacketCable 2.0 project
• http//www.packetcable.com/specifications/specific
  ations20.html
• Residential SIP Telephony
• http//www.packetcable.com/specifications/packetca
  bleapps.html

15
Thank You

• Feedback is welcome
• CableLabs specifications are intended to be
  revised as IETF and other standard requirements
  mature
• For further information, email to s dot sharma at
  cablelabs dot com

16
Backup slide 1 (Emergency call)