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

[Randall Gellens <[e-mail]>]

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

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, <[e-mail]> 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" rel="nofollow">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" rel="nofollow">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
[phone] (Tel.)
[phone] (Fax)
[phone] (Mobil)
http://www.telekom.com" rel="nofollow">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
[e-mail]
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