One document matched: draft-jesske-ecrit-ecall-urn-extension-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC5031 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5031.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc inline="yes"?>
<?rfc toc="yes" ?>
<?rfc tocdepth="2" ?>
<?rfc symrefs="no" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<?rfc compact="no" ?>
<?rfc sortrefs="yes" ?>
<!-- <?rfc colonspace='yes' ?> -->
<rfc category="info" ipr="trust200902" docName="draft-jesske-ecrit-ecall-urn-extension-01"
>
<front>
<title >Uniform Resource Name (URN) extension for automatic and manual Emergency
Services
</title>
<author fullname="Roland Jesske" initials="R.J." surname="Jesske">
<organization abbrev="Deutsche Telekom">Deutsche Telekom</organization>
<address>
<postal>
<street>Heinrich-Hertz-Strasse 3-7</street>
<city>Darmstadt</city>
<region></region>
<code>64307</code>
<country>Germany</country>
</postal>
<phone>+4961515812766</phone>
<email>r.jesske@telekom.de</email>
</address>
</author>
<date day="15" month="July" year="2013" />
<area>RAI</area>
<abstract>
<t> This document describes and discusses a mechanism for extending
sos URN's to fulfill the emergency call requirements of carriers.</t>
</abstract>
</front>
<middle>
<section title="Overall Applicability">
<t> Uniform Resource Name (URN) for emergency and other Well-Known
Services are well defined within RFC5031 <xref target="RFC5031"></xref>. There are also
existing proposals for automatic and manual ecall IN-Vehicles which
defines their own URN's and additional procedures for vehicle
specific eCalls. Due to the existing telecommunication world and
their implementations a combination of both is needed. Due to the
fact that only one URN can be used within the request line of a SIP
Message a new approach is needed. Therefore this document proposes
to extend the existing URN's with an extension to reflect this.
</t>
<t> This draft should be seen as proposal which could be incoperated into draft-rosen-ecrit-ecall-10 <xref target="draft-rosen-ecrit-ecall-10"></xref> after discussing this approach </t>
</section>
<section title="Conventions">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 <xref
target="RFC2119"></xref>.</t>
</section>
<section title="Overview">
<t>RFC5031 <xref target="RFC5031"></xref> defines URN values for emergency calls. The values
for the SOS subtree are sos.ambulance, sos.animal-control, sos.fire,
sos.gas, sos.marine, sos.mountain , sos.physician, sos.poison and
sos.police draft-rosen-ecrit-ecall-10 <xref target="draft-rosen-ecrit-ecall-10"></xref> proposes two additional
URN for ecall. automatic and ecall.manual the sub-services 'sos' as
specified in Section 4.2 of RFC5031 <xref target="RFC5031"></xref>.
</t>
<t> Within the existing implementation in GSM networks for emergency call
as specified in 3GPP TS 22.101 <xref target="TS22101"></xref> the following requirements
and code points are described:
</t>
<t> ---------------------------------------------------------------------
---
</t>
<t> It shall be possible to initiate emergency calls to different
emergency call centers, depending on the type of emergency. The
following types of emergency calls shall be possible:
</t>
<t> o Police</t>
<t> o Ambulance </t>
<t> o Fire Brigade </t>
<t> o Marine Guard </t>
<t> o Mountain Rescue </t>
<t>o Manually Initiated eCall </t>
<t>o Automatically Initiated eCall </t>
<t> .... </t>
<t> It shall be possible to tie any emergency call number to any single
emergency call type or to any combination of emergency call types.
</t>
<t> --------------------------------------------------------------------</t>
<t> This means in practice that a emergency Call Center from police must
differentiate between automatic and manual eCalls. Same belongs to
the other types like fire brigade Marine Guard ect.
</t>
<t> Requirement: </t>
<t> Req-1: It shall be possible to tie a manually initiated eCall with
different type of emergency type i.e. Police, Ambulance, Fire
Brigade, Marine Guard and Mountain Rescue.
</t>
<t> Req-2:It shall be possible to tie a automatically initiated eCallC
with different type of emergency type i.e. Police, Ambulance, Fire
Brigade, Marine Guard and Mountain Rescue.
</t>
<t> These requirements will not allow a second different URN
Format as described in draft-rosen-ecrit-ecall-10 <xref target="draft-rosen-ecrit-ecall-10"></xref>. This draft adds two additional URN urn:service:sos.ecall.manual and urn:service:sos.ecall.automatic
Which allows to address the ecall itself. But the requirement in 3GPP TS 22.101 <xref target="TS22101"></xref> described will not be satisfied. Therefor this document proposes an other format of the URN
</t>
</section>
<section title="IANA Consideration">
<t> IANA is requested to register the URNs described below under
the sub-services 'sos' registry defined in Section 4.2 of RFC5031<xref target="RFC5031"></xref>
</t>
<section title="sublabel for sos service and the related subservices">
<t>An additional sublabel for sos and the 5 base values of police, ambulance, fire, mountain are defined.</t>
<t>.ecall</t>
<t>This sublevel indicated that an ecall has been triggered.</t>
<t>.automatic</t>
<t>This sublevel indicates that an eCall had been triggered
automatically. This could be a sensor-controlled measuring of heat
or pressure in case of car accidents or fire situations.</t>
<t>.manual</t>
<t>This sublevel indicates that an eCall had been triggered based on the
manual interaction of a person.</t>
<figure>
<artwork align="left"><![CDATA[
Service Reference Description
-----------------------------------------------------------------------------------
sos.ecall RFC xxxx Emergency services, automatic eCall
sos.ecall.automatic RFC xxxx Emergency services, automatic eCall
sos.ecall.manual RFC xxxx Emergency services, manual eCall
sos.police.ecall.automatic RFC xxxx Police, law enforcement, automatic eCall
sos.police.ecall.manual RFC xxxx Police, law enforcement, manual eCall
sos.ambulance.ecall.automatic RFC xxxx Ambulance service, automatic eCall
sos.ambulance.ecall.manual RFC xxxx Ambulance service, manual eCall
sos.fire.ecall.automatic RFC xxxx Fire service, automatic eCall
sos.fire.ecall.manual RFC xxxx Fire service, manual eCall
sos.marine.ecall.automatic RFC xxxx Maritime search and rescue, automatic eCall
sos.marine.ecall.manual RFC xxxx Maritime search and rescue, manual eCall
sos.mountain.ecall.automatic RFC xxxx Mountain rescue, automatic eCall
sos.mountain.ecall.manual RFC xxxx Mountain rescue, manual eCall
]]></artwork>
</figure>
</section>
</section>
<section title="Security Considerations">
<t>This document does not raise security considerations beyond those
described in RFC5031 <xref target="RFC5031"></xref>.</t>
</section>
<section title="Contributors and Acknowledgements">
<t> The author would like to thank Dieter Jacobsohn, Maik Kirsch and
Thomas Dennert for clarifying the requirements on automatic and manual
eCall in the existing GSM world.
</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC5031;
<reference anchor="draft-rosen-ecrit-ecall-10">
<front>
<title>"Internet Protocol-based In-Vehicle Emergency Call"</title>
<author initials="B." surname="Rosen" fullname="Brian Rosen">
<organization />
</author>
<author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">
<organization />
</author>
<author initials="R." surname="Gellens" fullname="Randall Gellens">
<organization />
</author>
<date month="July" day="14" year="2013" />
</front>
</reference>
<reference anchor="TS22101">
<front>
<title>3rd Generation Partnership Project; Technical
Specification Group Services and System Aspects; Service
aspects; Service principles (Release 11)",
</title>
<author>
<organization>3GPP</organization>
</author>
<date day="28" month="September" year="2012" />
</front>
<seriesInfo name="3GPP TS" value="22.101 10.7.0" />
<format target="http://www.3gpp.org/ftp/Specs/html-info/22101.htm"
type="HTML" />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:52:36 |