Future Emergency Telecommunication Scenarios

over the Internet

Dr. Ken Carlbergk.carlberg@cs.ucl.ac.uk

Emergency Telecommunications Workshop26’th-27’th, February 2002, ETSI,Sophia Antipolis, France

Outline

Background The Challenge:

Emergency Services over the Internet Services & Protocols Operational Scenarios Usage Scenarios Summary

Background: Internet

A network of networks Self autonomy Minimal requirements to be an ISP

May use routing protocols May use non-FIFO queues No traffic engineering requirements

Most congestion occurs at access points Tier-1 ISPs usually have high excess capacity

at exchange points U.S. centric view at times Counter example includes Trans-Atlantic link(s)

Background: Internet (2)

Default service model is Best Effort “send and pray” No minimal level of QoS

TCP is ~90-95% of traffic load Adaptive to congestion, but cost is degraded

service Security is an issue with IP networks

Denial of service: NIMDA, ICMP Echo Request, …

Spoofing

Challenge

Distinguish emergency traffic Provide separate level of service

Policy and/or regulatory issue Value added services

Alternate path routing Interoperation with PSTN

Mapping code points (at a minimum)

Achieving the above with minimal changes to existing IP protocols

Services & Protocols

Past, Current, and/or On-Going (sample set) SIP/Megaco/H.323 MPLS Diff-serv Int-Serv/RSVP Instant Messaging & Presence

Other WFQ RED

Observations

Existence of protocols does Existence of protocols does NOTNOT equate to equate to availability by vendors or service providersavailability by vendors or service providers MPLS

Local domain service Complex and possibly overkill for many ISPs

Int-Serv/RSVP Market rejection of end-to-end model

Diff-serv Local domain service Basic (AF) service can be accomplished with

WFQ/RED

So,….be a pessimist about what exists, and leverage what you can use

VoIP with QoS: Near Term

IP Backbone IP as a private network Single control of

resources

Single-Hop ISPs No Inter-ISP SLAs Single control of

resources

SS7

Signaling

Evolution towards NGN

VoIP (SIP/H.323 over IP)

SS7

ClientClientIP StubIP Stub

ISP ISP CloudCloud

PSTNISP ISP

CloudCloud

WFQ

Diff-Serv (AF)

ClientClientIP StubIP Stub

Telcos

Stub IP Domain

PSTN

InternetInternet

VoIP

PBX

ETS Operation: Near Term

Label calls for ETS SIP Resource Field (draft) H.323 Priority Field (draft)

Policy defines actions (part of SLA) Preemption / non-preemption Traffic engineered paths

SLA’s dictate usage (e.g., diff-serv code points) e.g., #1) AF (Class 1) for Signaling, EF for VoIP e.g., #2) AF (Class 3) for Signaling & VoIP Access control at the edge

ETS Operation: Mid Term

Alternate path routing BGP could not support

Emergency attribute Routers straining to

support number of routes

Convergence time problem

Network View

SIPServer

TRIPView

TRIP Route

Application Layer routing e.g., Telephony Routing

over IP (TRIP)

ETS Operation: Mid Term (2)

Admission Control Performed at edge of diff-

serv domain

Core/Internal congestion AF: use drop precedence EF: requires careful

traffic engineering to avoid congestion

AdmissionControl

Call/Data (1)(emergency)

Call/Data (2)

AdmissionControl

Call/Data (1)(emergency)

Call/Data (2)

Potential augmentation New code point to

distinguish emergency EF from normal EF

ETS Usage

Traveling Authentication & Capability Similar to GETS

Non-ubiquitous service ETS “islands” connected via best effort service Goal is ever increasing wide spread support

Payment and/or regulation are important issues because….

…..“There is no such thing as a free lunch”

ETS Future?

QoS Gateways Forward Error Correction (FEC) Redundant transmission Transcoding

Semi-Active Networking Very leading edge approach E.g., Cisco Intelligence Engine 2100

XML/policy based control of network elements

Negotiated service with user Degraded service if admission control fails

Summary

Autonomous & independent nature of IP networks makes support of ETS difficult

Be pessimistic about available services

“We” probably have 85% of what is needed to supporting ETS

More options will exist for the ETS user