Subject: [Ecrit] ETSI EMTEL Emergency Requirements

From: "Stastny Richard" <[email-masked]>
Date: Fri, 4 Mar 2005 13:34:02 +0100

Dear all,

we have now quite a collection of requirements together.

To complicate the issue further and complete the global view, 
I want to add the (approved) requirements from Europe
submitted from EMTEL to ETSI TISPAN WG1 this week (05bTD017):

05bTD182r1 DES01019 _Requirements of the NGN network to support 
the emergency service for communication from citizen to authority_

The requirements where also checked against the requirements for 3GPP
IMS as outlined in the draft TR 23 867. IT was then agreed that this
document is approved at the project level ...

Best regards
Richard Stastny

Citations from the document:

1 Scope

The present document contains the requirements of a NGN to support
emergency communications (EMTEL) from the citizen to the authority.  The
requirements are independent of the NGN subsystem and transport layer
unless specifically referred to.

.....

4 Emergency Sessions Requirements

The following is a list of very high level requirements for an emergency
call/session between a user and the PSAP/ECC when an 112 type service is
requested.
 
*Provide a voice link, maintained throughout the call
*Receive immediate priority treatment over other calls
*Must not be subject to restrictive network management practices
*Must be subject to normal call records, charging and accounting (even
though the call is free)
*Must provide a unique ID  to enable a callback (eg CLI) and Network
Operator ID
*Originating geographic location must be automatically provided to
determine 
- correct PSAP operator to route the call to
- appropriate local emergency service centre
- location to accurately despatch assistance.
*Location information must be automatically available at the PSAP centre
*Must be migrated to multi-party calls under the control of the PSAP
operator
*Shall be subject to "last party clear", or other method for handling
false calls
*Shall be restored with priority over normal calls.
*Need IP and PSTN Emergency Call Centre solution

Note by Richard: this seems quite extreme, but is softened in the
further
text

4.1 General Requirements

It shall be possible to establish a session for an emergency speech
call. These Emergency calls shall be routed to the emergency services in
accordance with the national regulations of where the caller is located
which may require that these calls receive a higher level of priority
than a normal communication.. An emergency call may be allowed to be
establish without the need to 'dial' a dedicated number to avoid a
mis-connection in the nomadic case, e.g. the use of entities such as
menu, by use of a 'red button' may be deployed. Emergency Calls may be
supported without a dedicated authentication device or procedure being
present for this session.

Note: It will be left to the national authorities to decide whether the
network should accept emergency calls without the dedicated
authentication device or procedure being present for this session.

It may be possible to initiate emergency calls to different emergency
call centres, depending on the type of emergency. The following types of
emergency calls shall be possible:
-	Police
-	Ambulance
-	Fire Brigade
-	Marine Guard
-	Mountain Rescue
-	Common emergency answering point
-	Spare, at least [three] different types

The Man Machine Interface (MMI) on specific NGN Terminal may be
specified by the regulatory authority in which the customer's service
contract is agreed. This interface is then stored on this NGN Terminal
and this shall be deployed whenever an emergency call/session is
attempted.
 
It maybe possible to tie any emergency call number, specified in the
preferred emergency call MMI(s) above, to any single emergency call type
or to any combination of emergency types.  The association between
emergency numbers and emergency call type maybe able to be programmed on
the NGN Terminal by the regulatory authority where the customer's
service contract is agreed.

Considering the "Directive 2002/21/EC on a common regulatory framework
for electronic communications and services (the "Framework Directive"),
and in particular Article 19". European Law [1] requires that 112
Emergency Voice services are available across the European Union, It is
noted that in some countries (e.g. Germany) this code does not translate
to the Police, where as in other counties (e.g. Italy) this is always
delivered to the Police who include other Emergency services. In other
countries 112 is delivered to a PSAP that offer a number of services.

....

Note:	if the NGN Terminal does not recognise the emergency call number
but the serving network recognises the dialled number as an emergency
call number used in the country. Then a normal call set up takes place
and after the serving network has recognised the emergency number the
call is routed as an emergency call.

A user friendly MMI that specifies the type of emergency directly (e.g.
via a menu) may be supported for use in any (i.e. home or visited)
network to avoid the miss-connection in the nomadic case.  This shall be
allowed both with and without authentication procedures taken place.

The serving network may download additional emergency numbers to the NGN
Terminal in order to ensure that local emergency numbers are known to
the NGN Terminal.  The NGN Terminal shall regard these emergency numbers
as valid in that country only and shall discard them when a new country
is entered.

4.1.1	Identification of emergency numbers

To handle nomadicity, the NGN Terminal shall be able to place calls on a
locally supported Emergency number, it should be able store Emergency
numbers, and in the case of a SIP Terminal, to store Emergency SIP URIs.
When an Emergency call or session is required, the correct Number/URI is
presented to the network on the basis of national knowledge and
information made available at the Access to the network. In Europe, this
shall be 112, and optionally a national possibly service specific
number.)
	
Additional the NGN Terminal may store emergency numbers that may have
been downloaded by the serving network.

4.1.2	Location information derivation and handling.

The location information shall [2] be derived from the known information
available in the network, to the extent technically feasible. Upon
initiating the emergency session any location information shall be sent
with the set-up of the session. 

If all location information is not available at the time of the set-up
of the emergency session then what is available is sent and the network
may use other positioning means to obtain other location information

This location information shall be identified as its to the origin, such
that all the NGN Terminal derived location information is indicated to
the emergency authority. The NGN Terminal provided Location Information
is indicated such that the origin of the information can be verified.

The location information shall be stored until the emergency authority
no longer requires it. This location information is sent to appropriate
emergency authority upon a request from this authority.

The location information shall be treated as private information [3] and
as such it is subject to the privacy regulation of data as specified by
the regulatory authority where the session is initiated. This may
include any authorisation and security procedures and obligations of the
customer, NGN Terminal and emergency authority.

4.1.3	Domains priority and selection for NGN Terminal attempts to
emergency call

A PSTN/ISDN emulation subsystem and IMS subsystem capable NGN Terminal
attempting an emergency call shall give priority to the PSTN/ISDN
emulation subsystem domain. 

In case where the call attempt in the PSTN/ISDN emulation subsystem
domain fails, the NGN Terminal should automatically make a second
attempt in the IMS subsystem domain, where the NGN Terminal is
facilitated and attached to both domains.

In the case where the NGN Terminal cannot support the IMS subsystem
capabilities but is able to support the PSTN/ISDN emulation subsystem
and the emergency call attempt in this domain fails the call is rejected
and an indication to try again given to the caller.

4.2	Requirements for a PSTN/ISDN Emulation Subsystem and Simulation
services in the IMS providing Emergency calls

A PSTN/ISDN emulation subsystem and simulation services in the IMS shall
support the emergency communication service as defined in SR 002 180
[4].
This clause deals with Emergency Voice services as mandated [1] hence
the PSAP/ECC is assumed to be either in the PSTN/ISDN network or at
least inter-worked to by a Media and boarder gateways.

4.3	Requirements for an IMS Subsystem Emergency Sessions

This clause deals with Evolutionary services where Emergency sessions
are established from a SIP Enabled terminal to a SIP enabled Emergency
Control Centre, via a SIP enabled PSAP. Where the SIP enabled PSAP is
viewed as a SIP Application Server in the IMS; the PSAP may select the
appropriate ECC on the bases on the service requested in the Session
Request (e.g. the SDP payload in the SIP INVITE). Where the PSAP is an
enhanced termination Similar-forwarding capabilities may be provided
before any optimally routed streaming media is established.

The solution for emergency sessions in the IMS subsystem shall fulfil
the following capability requirements:

1.	It should be independent from the underlying IP connectivity
network in respect to the detection and routing of emergency sessions.

2.	All emergency contact identifiers, (e.g. emergency numbers, SIP
emergency URIs) and any special indications for emergency sessions
within the SIP signalling must be supported specifically IETF proposals
on addressing should be taken into consideration.

3.	Emergency sessions should have priority access to resources,
when the network resources are under load, over "ordinary" sessions by
the network.

4.	Set-up of IMS emergency sessions shall be possible for users
with a barred public user identity.

5.	The primary solution shall be that the NGN Terminal will detect
an initiation of an emergency session (e.g. by evaluating the SIP-URI or
the dialled number) by itself and then indicates the emergency session
to the network. 

However the NGN shall also support the scenario where the NGN Terminal
cannot detect an initiation of an emergency session, then the NGN shall
be able to detect and indicate an emergency session in progress.

6.	The NGN must be able to support the scenario where the
authorisation of the NGN Terminal to the network is accomplished with
the aid of an ISIM module. In this case the NGN shall be able to set-up
an emergency session if this identification module is not present. 

7.	An Emergency Service shall not be a subscription service and
will therefore be supported in a visited network and provided without
interaction with a "Home" network for the nomadic case.
 
8.	For the nomadicity scenario where an emergency session request
is routed via the home network, the home network shall be able to detect
that the session is for emergency service (whether indicated or not) and
respond to the NGN Terminal indicating that the NGN Terminal should
initiate an emergency session in the visited network.

Alternatively the visited network may be able to detect that the session
request is for an emergency session (whether indicated or not)and route
to session to the appropriate PSAP/ECC.

9.	The Location of the caller to the session establishment shall be
supported according to clause 4.1.2 above in accordance with the EU
Directives [2] and [3].

10.	PSAPs/Emergency control centres shall be connected to the
PSTN/ISDN emulation domain, however the emergency centre may also be
connected to the IMS domain or any other packet network.

11.	PSAPs/Emergency control centres shall be able to call back the
user, if a CLI is provided or ISIM is used to authenticate the user. In
the ISIM-less Simulation Case this may not be possible.

12.	The visited network shall be able to download emergency numbers
to the NGN Terminal using procedures as described in TS 24.008 [5], in
order to ensure that local emergency numbers are known to the NGN
Terminal. 
 
....

4.6	Architecture requirements

The solution for emergency sessions shall also fulfil the following
architectural requirements:

1.	The architecture for Emergency Service should be driven by the
specific capabilities requirements. Specification should minimise the
changes to existing 3GPP IMS architecture and procedures, and re-use
existing 3GPP IMS functional entities. However the specification should
not be constrained by the existing functional entities.

2.	The architecture should take into account that it may be
possible to make emergency calls on other media than voice. It needs to
take account support, for example, the deaf and hearing-impaired using a
text phone that might generate information, for example, using
procedures for Multimedia services or the 3GPP Instant Messaging Service
based on the 3GPP IMS or the F-MMS messaging procedures. There may also
be a need to work with phones that attempt the emergency call as a video
telephony call.

3.	The architecture should support the evolution of PSAPs/Emergency
Control Centres from terminating access to the PSTN/ISDN, to direct
inter-working via Media and boarder gateways, to the case where they are
part of the SIP infrastructure. Allowing the case that not all PSAPs/ECC
will migrate at the same time. Legacy ECC with Enhanced ISDN access only
may persist for some time.

4.	Service Inter-working is an important consideration if a SIP
aware terminal places a multimedia, MMS or Instant message Emergency
session to an PSAP/ECC that only supports ISDN voice. Rejection or
fallback considerations will be serious.

4.7	Protocol & Security requirements

The following issues have been identified as requirements that need a
solution for the support of VoIP Technology. It has been identified that
the following possible limitations for the support of Emergency Voice
Services (e.g. E112 and SOS SIP URIs must be alleviated. These issues
include:
*	Reliability of location information
*	Authentication of caller id and location stored in a NGN
Terminal
*	Monitor and validate (1) terminal syntatical behavoiur (2) and
network behabiour on denial of service attacks and mitigate against the
effects of aforementioned behaviour.
*	VPN access problem:
o	Globally accessible routing
o	Secure routing globally
*	Enterprise DHCP server for location information (private)
*	Residential DHCP issues
*	Overhead of organisations that provide access to public
Emergency Voice Services (e.g. E112)
*	Global/international regulation
*	PSAP reconnect capability

_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: "Marc Linsner" <[email-masked]>
Date: Fri, 4 Mar 2005 09:18:16 -0500

Richard,

Thanks for submitting this....it's great to see other organizations working
on emergency calling issues.

I'll contact EMTEL to see if someone can formalize these into a draft.

-Marc Linsner-

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Stastny Richard
> Sent: Friday, March 04, 2005 7:34 AM
> To: [email-masked]
> Subject: [Ecrit] ETSI EMTEL Emergency Requirements
> 
> Dear all,
>

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 04 Mar 2005 13:20:16 -0600

Richard

Yes, I it good to read ETSI's proposal.

I agree the short list is rather extreme, but when reading the individual 
sections, I am not reading most accounting for the Internet Protocol. There 
is text, for example with respect to priority in 4.1.3, that only 
references ISDN. I'm confused by this and wouldn't know where to go next in 
the IETF to address that (and other) requirements that don't talk (perhaps 
enough) to IP.

Do you have any suggestions or more information?

I'd also be curious to read the list of references within the text.

> > *     PSAP reconnect capability

cheers,
James

                                *******************
                 Truth is not to be argued... it is to be presented