160 likes | 293 Views
Emergency Services in PacketCable TM 2.0. Sandeep Sharma Senior Architect, Signaling Protocols SDO Emergency Services Coordination Workshop, Columbia University, New York October 5 and 6, 2006. CableLabs Introduction.
E N D
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
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)
CableLabs’ Mission • Plan, fund and perform R&D 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
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.0&1.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 cable’s existing Internet Protocol service environment to accelerate the convergence of voice, video, data, and mobility technologies
Subscriber Management Applications Application Servers HSS SLF I-CSCF S-CSCF Session Control P-CSCF GPRS/other GSM Handsets 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
Telephony Client WiFi/Cellular Client Soft Client Video Client 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
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
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
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
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 “URN:service:sos” 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-location-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
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
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
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
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/specifications20.html • Residential SIP Telephony • http://www.packetcable.com/specifications/packetcableapps.html
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