110 likes | 125 Views
IETF ECRIT SDO Emergency Services Coordination Workshop 5 & 6 Oct 2006 – New York. Alain Van Gaever DG Information Society & Media European Commission. Agenda. (1) Presentation on the EU Regulatory Framework
E N D
IETF ECRIT SDO Emergency Services Coordination Workshop 5 & 6 Oct 2006 – New York Alain Van Gaever DG Information Society & Media European Commission
Agenda • (1) Presentation on the EU Regulatory Framework • (2) Discussion on establishment of document outlining responsabilities of different market players • (3) Discussion on Standardisation: how does IETF architecture compare with 3GPP, ETSI,…
Promote Competition Foster innovation Offer more choice, quality,... Liberalisation of market Simplify Market Entry Promote interest of citizens Protection of Citizens Universal Service Consumer Protection Privacy Dispute Resolution Objectives of the EU Regulatory Framework • Promote Single European Market • + Technology Neutral Regulations
Regulatory Framework governs Electronic Communications Networks & Services In place since 2003 Same Regulatory Framework for all Member States (25 +2) In essence ‘technology neutral’ No specific regulation for satellite, cable, etc. Most “traditional” VoIP provides fall under Framework: Vonage Skype In & Out (Not : Skype Classic) EU Regulatory Framework
Access to Emergency Services Introduction of single EU emergency number “1-1-2” Promoting “1-1-2” Calling Emergency Services Free of Charge Provision of Caller Information – ‘to the extent technically feasible’ Integrity & availability requirements Issues Mobile: Caller location not available in all 25 (+2) MS Cost of passing on caller location to emergency authorities Different organisational setups of Emergency Access across the EU Obligations imposed on “public telephone networks” i.e. a model that assumes “vertically integrated operators” EU Regulatory Framework & access to emergency services
Review of the framework currently ongoing “Window of Opportunity” to make changes is now New rules likely to enter into effect in 2009-2010. Updated framework will cover time period of 2010 till 2015 Proposed changes (emergency access) “Caller Location” = technically feasible Free of charge Improved access for disabled users More clear separation between network and service providers Note: no obligations on phone manufacturers If more changes to the legislative framework are needed >> Now is the time to act Review of the EU Regulatory Framework
Agenda • (1) Presentation on the EU Regulatory Framework • (2) Discussion on establishment of document outlining responsabilities of different market players • (3) Discussion on Standardisation: how does IETF architecture compare with 3GPP, ETSI,…
Responsibilities of Market Players • IETF Architecture requires cooperation from: • Network Providers • provision of location information • . . . • Service Providers • routing of calls • Provision of location-to-appropriate-PSAP systems (?) • . . . • Phone manufacturers • End-user device needs to store location information • . . . • Governments/Local authorities • Provision of information: Which PSAP is responsible for • which location and • which type of emergency response … • . . .
Responsibilities of Market Players • Responsibilities of market players in a PSTN Architecture are pretty clear (for regulators) • Although a lot of obligations are implicitly taken care of without clearly specified obligations on operators and other market players. [ “it has always worked” ] • In an ‘IP-World’ – more explicit requirements are probably needed • Alternatively: • could everything be left to commercial players – and have no regulatory obligations at all?
Agenda • (1) Presentation on the EU Regulatory Framework • (2) Discussion on establishment of document outlining responsabilities of different market players • (3) Discussion on Standardisation: how does IETF architecture compare with 3GPP, ETSI,…
Standardisation • How does IETF architecture compare with 3GPP, ETSI EMTEL,… • EU Regulatory framework needs to be neutral: • Difficult to single out one solution. • Ideally architecture (and hence regulatory obligations) would be similar (or the same) for all emergency access solutions.