Subject: Re: [Ecrit] review draft-gellens-ecrit-ecall-03.txt

From: Randall Gellens <[email-masked]>
Date: Thu, 3 Jul 2014 22:06:08 -0700

Hello Roland,

Many thanks for your detailed and helpful review of the eCall
draft.  Please see in-line below.

At 3:39 PM +0200 4/29/14, <[email-masked]>
wrote:

Dear
all,

as discussed at the
last IETF I have reviewed
draft-gellens-ecrit-ecall-03.txt.

Here are my
comments:

General:

1.
ETSI has finalized the Technical Report on eCall and proposes
solutions. Question is if it would be worth to mention onr reference
it. The report is under http://webapp.etsi.org/ewp/copy_file.asp?wki_id=39297  downloadable.

Thank you, I agree and have added a mention of it and reference
to it.

2.
I will point in some parts of the detailed review to backwards
compatibility issues. So we have now implemented a eCall solution for
our GSM. So this is an invest done. And PSAP invests are seen as a
long term invest. These will be used for a long time so a SIP/IMS/NGN
solution is needed where we can built new PSAP understanding the
NG-eCall but also have the possibility to route the call towards the
“old" PSAP getting the inband information type eCall. But also the
case will appear where we have still the old style end device which
have to be interworked towards the new PSAP style.

I completely agree that migration/co-existence (behavior during the
transition period when the UE, network, and PSAP may each support or
not support NG) is extremely important.  I think the issue is
outside the current scope of the draft, which is limited to describing
how eCall is handled in an NG environment.

Question is how this will be
done? My opinion is that each PSAP has to understand the in-band
information.

It's quite reasonable that PSAPs which are upgraded to support
in-band eCall will retain the capability as they are further upgraded
to support NG.  It's possible that some future PSAPs will be
established later which only support NG, and for these cases I believe
the routing decisions can take this into account, or another
possibility would be gateways to convert between NG and in-band.
There are further issues of course.  The ETSI TR 103 140
discusses these issues in clause 7.  I have added mention of this
and a reference to the TR.

By the way, TR 103 140, recommends that NG IVS and NG PSAP be
legacy capable.  A broadcast indicator of network and PSAP
capabilities enables the UE to decide whether to use legacy or NG
eCall (the operator only uses the indicator when it is able to route
to an NG capable PSAP). Alternatively there can be a legacy/NG
protocol conversion at the PSAP.

Detailed comments &
questions:

1.       Section 3 last
paragraph:

...

An
eCall

flag in the call setup marks the call as an eCall, and
further

indicates if the call was automatically or manually
triggered.

...

3GPP has
more flags that only automatic and manual. (we have discussed this in
Berlin)

Do you mean more flags that are specific to eCall, or are you
referring to flags that are not specific to eCall?  I assume the
latter (based on subsequent comments).

the proposal is to add
an sentence like:

"Note that 3GPP
TS22.101 allows to combine the automatic and manual triggered ecall
with the type of emergency guard like police or fire force. This is
also uses in some countries."

3GPP describes the
requirements in TS 22.101 as follows

Possible values in
signalling:

o
Police

o
Ambulance

o
Fire Brigade

o
Marine Guard

o
Mountain Rescue

o
Manually Initiated eCall

o
Automatically Initiated eCall

And
the bind requirement:

It
shall be possible to tie any emergency call number to any
single

emergency call type or to any combination of emergency call
types.

This is not a simple matter (there are a number of additional
factors), and in fact, 3GPP TS 24.229 (Release 12) contains an
Editor's Note:

Editor's Note: [EMC1,
CR#4068]
How to fulfil the requirement in 3GPP TS 22.101 [1A]
that it shall be possible to tie any emergency call number to any
combination of emergency call types is FFS.

So at this point it is not clear that combining types of
emergency calls with eCall is required, nor how best to do so if it is
required.  If you have time, we can meet and talk about this in
Toronto.

2. Section
3.

Also it would be worth
to mention that backward compatibility is an requirement since we have
already millions of cars with GSM Chips which will be in future
interworked with SIP/IMS networks.

Yes, I agree.  I have added text to the Introduction
mentioning the issues but also that it is currently out of
scope.

3.Section
4.

one requirement is the
backwards compatibility. Since mobile networks will not have LTE
coverage  all over and “old" ecall solutions will be
interwokked to IMS there is the need when to have a backwards
compatible solution. (i.e. Inband communication must be traversed to
PSAP understanding in band and/or the PSAP is able to understand in-
and out-band information.

I think this requirement is out of scope of the document.

4.
Section 6. 1st Paragraph :

“In circuit-switched eCall, the IVS places a
special form of a 112

emergency call which carries the eCall flag (indicating that the
call

is
an eCall and also if the call was manually or
automatically

triggered)... “

As mentioned above
there are more possible indications within the “eCall
Flag"

The document is not trying to present a complete picture of
circuit-switched emergency calls, but rather a high-level summary of
eCall.

5. Section 6 2nd
Paragraph: Perhaps mention a option to identify also inband
information when available. Or note that inband information then
should be routed towards an backwards compatible
PSAP.

Migration issues are out of the current scope of the
document.

6. Section 6. last
Paragraph: “...urn:service:sos.ecall.automatic and
urn:service:sos.ecall.manual" >From the discussion we had in the
past (i.e http://tools.ietf.org/html/draft-jesske-ecrit-ecall-urn-extension-01 in Berlin) I had the understanding
that also the extension of the  urn:service:sos.ecall.automatic
is still to long. So that only  urn:service:sos.ecall would be
more ort less acaptable. And we need an further extension to identity
the additional information for routing.

Speaking generally, call handling is free to take action based on
part of the Request-URI, but it is better that the full information be
included so that it is up to the call handling entities how to
proceed.

7. Section 7.
“...   The routing rules for eCalls are likely to differ
from those of other

emergency calls because eCalls are special types of emergency
calls

(with implications for the types of response required) and need to
be

handled by specially designated PSAPs.

What is meant by
“with implications for the types of response required" I do have
slide problems to understand. Is this the fact that there could be
diffrent responses like a call back or SMS back?

What is meant here is that it is possible that different types of
calls have a presumption of different types of responses; for example,
an automatic eCall is more likely to require medical assistance and
possible specialized assistance for motor vehicle accidents.  In
contrast, a manual eCall, depending on the operational procedures of
the agencies involved, might be presumed to require police (e.g.,
report an emergency road safety issue).  This is not about call
back or SMS.

8.
Section 7.1 mentions a interworking new to old. Is there also
the possibility to interwork old to new? Would there be also an
Section 7.2, 7.3 for other networks which are not EENA
based?

The text is only mentioning the possibility of such interworking
in a broader context of ESInets.  It is possible to interwork
between old and new by translating between in-band data and the data
contained in the call signaling.  This is conceptually similar to
interworking between TTY or other legacy text and real-time text.
Such interworking could be done with or without an ESInet.

9.
Section 9. Will the same mechanism used or is this one out of
a several possibilities? Is this mechanism such as open that each
PSAP-operator can define it's own set? Or is it more seen as set to be
aligned within RFC's?

This is a situation where the broadest possible support and
standardization is needed; if individual PSAPs define their own
extensions, there is low likelihood of support by various automotive
IVS.  What I think makes the most sense is for the framework to
be established by RFC, with IANA registries for the specific actions,
which can be populated by SDOs involved in eCall.

10.
Section 10. It would be worth if preconditions and the
reliability of provisional responses will have a effect of the
solution or if they are needed? This question reflects the issue that
in many mobile IMS networks such mechanisms will be
used.

I'm sorry, I'm not understanding; if you have time, we can meet
and talk about this in Toronto.

11.
A IVS provided location could be also manipulated. Independent
on the trustworthiness. I think this should be mentioned explicitly.
Question is what can provide security on such location. Perhaps a hint
would we nice to be mentioned or to mandate the draft
trustwothy-location more as an requirement.

There is already a reference to the trustworthy-location draft in
Section 11.

12.
Section 12. As commented above I would propose an additional
URN parameter or an other SIP extension to point to the possible
indications appearing within a eCall. Such a indication needs to be
considered when routing towards the PSAP.

The draft should not propose such until after 3GPP has decided if
such mechanisms are required and if so how they are to be supported.
If you have time, we can meet and talk about this in Toronto.

13.
Within 3GPP we have the additional indications as mentioned
above

From my (operators)
point of view the most important points needed to be discussed are
backwards compatible solution and the format of the URN and additional
indication for PSAP routeing purposes.

My recommendation is
also that we can start the work and push it towards work item within
ecrit.

Thank you and Best
Regards

Roland

Mit freundlichen
Grüßen; With Best Regards

Roland
Jesske

Deutsche Telekom Technik GmbH

Fixed Mobile Engineering Deutschland

Roland Jesske

Heinrich-Hertz-Straße 3-7, 64295 Darmstadt

+49 6151 58-12766 (Tel.)

+49 6151 58-13395 (Fax)

+49 171 8618-445 (Mobil)

http://www.telekom.com

Erleben, was verbindet.

Deutsche Telekom Technik GmbH

Aufsichtsrat: Dr. Thomas Knoll (Vorsitzender)

Geschäftsführung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert
Matheis, Carsten Müller

Handelsregister: Amtsgericht Bonn HRB
14190

Sitz der Gesellschaft: Bonn

USt-IdNr.: DE 814645262

Große Veränderungen fangen klein
an
- Ressourcen schonen
und nicht jede E-Mail drucken.

_______________________________________________

Ecrit mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/ecrit

--

Randall Gellens

Opinions are personal;    facts are
suspect;    I speak for myself only

-------------- Randomly selected tag: ---------------

I have the simplest tastes.  I am always satisfied with the best.

--Oscar Wilde