1 / 14

Future Emergency Telecommunication Scenarios over the Internet

Future Emergency Telecommunication Scenarios over the Internet. Dr. Ken Carlberg k.carlberg@cs.ucl.ac.uk. Emergency Telecommunications Workshop 26’th-27’th, February 2002, ETSI, Sophia Antipolis, France. Outline. Background The Challenge: Emergency Services over the Internet

pegeen
Télécharger la présentation

Future Emergency Telecommunication Scenarios over the Internet

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Future Emergency Telecommunication Scenarios over the Internet Dr. Ken Carlberg k.carlberg@cs.ucl.ac.uk Emergency Telecommunications Workshop 26’th-27’th, February 2002, ETSI, Sophia Antipolis, France

  2. Outline • Background • The Challenge: • Emergency Services over the Internet • Services & Protocols • Operational Scenarios • Usage Scenarios • Summary

  3. 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)

  4. 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

  5. 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

  6. 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

  7. Observations • Existence of protocols does NOT equate to availability 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

  8. IP Backbone IP as a private network Single control of resources Single-Hop ISPs No Inter-ISP SLAs Single control of resources Stub IP Domain Internet VoIP PSTN PBX VoIP with QoS: Near Term Telcos SS7 Evolution towards NGN SS7 Signaling VoIP (SIP/H.323 over IP) WFQ ISP Cloud Client IP Stub PSTN ISP Cloud Client IP Stub Diff-Serv (AF)

  9. 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

  10. Network View SIP Server TRIP View TRIP Route ETS Operation: Mid Term • Alternate path routing • BGP could not support Emergency attribute • Routers straining to support number of routes • Convergence time problem • Application Layer routing • e.g., Telephony Routing over IP (TRIP)

  11. Admission Control Call/Data (1) (emergency) Call/Data (2) • Potential augmentation • New code point to distinguish emergency EF from normal EF Admission Control Call/Data (1) (emergency) Call/Data (2) 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

  12. 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”

  13. 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

  14. 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

More Related