[Ecrit] draft-ietf-ecall-07

["Drage, Keith (Nokia - GB)" <[e-mail]>]

I did another read through of this document last night, and had the following comments. I have not reviewed the entire document.

Note that this does not supercede any of the comments made in the last few days:

1)	s. 2, 1st para: ecall in 3GPP is a 3GPP emergency call, and while there are some similarities, 3GPP emergency call does not fully comply with either RFC 6443 or RFC 6881. I am also not sure the references are relevant to the purpose of the draft in any case.

2)	s. 2, 3rd and 4th para: These paragraphs seem to be going beyond document scope, and into a wish list. I suggest both these paragraphs are deleted.

3)	s. 3, 4th paragraph:

   An eCall can be either user-initiated or automatically triggered.
   Automatically triggered eCalls indicate a car crash or some other
   serious incident and carry a greater presumption of risk of injury.
   Manually triggered eCalls might be reports of serious hazards and are
   likely to require a different response than an automatically
   triggered eCall.  Manually triggered eCalls are also more likely to
   be false (e.g., accidental) calls and so might be subject to
   different operational handling by the PSAP.

The distinction between seriousness and impact of manual versus automatic is highly subjective, and will depend on the underlying philosophy of the administration in how it handles what it regards as false alerts, which differs substantially from administration to administration.

4)	s. 3, 5th para:

   As part of this work, the European Telecommunications
   Standards Institute (ETSI) [SDO-ETSI] has published a Technical
   Report titled "Mobile Standards Group (MSG); eCall for VoIP" [MSG_TR]
   that presents findings and recommendations regarding support for
   eCall in an all-IP environment.

This somehow implies that the contents of this document are valid for the interpretation of the draft. Vewry little of the work has migrated into the stage 1 in 3GPP, and the other groups in 3GPP are working directly from the stage 1 description, not from the ETSI work.

5)	s. 3 last para:

   A transition period will exist during which time the various entities
   involved in initiating and handling an eCall might support next-
   generation eCall, legacy eCall, or both.  This transition period
   might last several years or longer.  The issue of migration/co-
   existence during the transition period is very important but is
   outside the scope of this document.  The ETSI TR "Mobile Standards
   Group (MSG); eCall for VoIP" [MSG_TR] discusses these issues in
   Clause 7.

I have not found any statements that support the concept of a transition in any of the documents I have read. The 3GPP stage 1 requires both UEs and PSAPs to support both data transfer mechanisms.

6)	s. 3 general

Some statement should be made in this section about the need for the UE and the PSAP to support both mechanisms within SIP, as required by the stage 1, as the 3GPP emergency network does not provide any data interworking, only signalling interworking. Interworking SIP to CS domain, any attached body to a SIP message will be discarded.

7)	s. 4 reference to 22.101, and s. 18.1. This document carries no provisions needed to implement this document, and therefore it should not be a normative reference. Further the reference should be to release 14 and later. The latest version of all releases of 3GPP documents are still valid documents for that release.

8)	s. 4. Is considerably out of data in regard to the current version of 22.101. This appears to be a summary of the CS requirements before the IMS changes were made.

9)	s. 6 last para.

   This document registers new service URN children within the "sos"
   subservice.  These URNs provide the mechanism by which an eCall is
   identified, and differentiate between manually and automatically
   triggered eCalls (which can be subject to different treatment,
   depending on policy).  The two service URNs are:
   urn:service:sos.ecall.automatic and urn:service:sos.ecall.manual

The URN does not identify an ecall. It identifies the resource to which the ecall needs to be directed. To explain further, the sos URN does not identify an emergency call, it identifies the resource needed to answer the emergency call, which is why we have a separate Resource-Priority namespace "esnet".

10)	s.7	

Europe does not use the term ESInet. That term is North America, and possibly USA, specific. It might be more appropriate to use terminology from the ETSI M483 group if this text is needed at all.

11)	s.8

In regard to test calls, I think some statement should be made about what they actually test. Using this URN would certainly not test the emergency call handling capabilities of either the network or the UE. Does it test all data transfer capabilities (including the CS). Why do we need a URN rather than just the same number as is used in the CS domain?

12)	s.9

   Future enhancements are desired to enable the PSAP to send other
   requests to the vehicle, such as locking or unlocking doors, sounding
   the horn, flashing the lights, starting a video stream from on-board
   cameras (such as rear focus or blind-spot), etc.

Do you have a reference for this, or is it speculative thinking?

I do not think the mechanisms proposed in this draft are suitable for transferring a video stream, so even if provided, are they part of ecall, or just part of the standard emergency call. Maybe the only ecall responsibility is to indicate the existence of these?

I'd note that extending beyond the existing CS domain capability is not required at the moment by the 3GPP stage 1. I think we all acknowledge that all and any data available in the car might be candidates for transfer to the PSAP, but it is not clear whether this is part of ecall, or whether it is part of the additional media beyond voice already available as part of 3GPP emergency call. Certainly there is a limit on the amount of data that can be transferred using the mechanisms currently in this draft, beyond which the QoS of the signalling channel will become inappropriate.

13)	s.9 & s.13

It is not clear to me which elements correspond to the existing MSD defined by CEN, and which have been defined over the top. Firstly I think all data that is defined by CEN should carry an appropriate CEN reference, because the UE needs to support both, and it should be the same data that is transferred in this. That should occur either in one of these sections, or in a new separate section.

Further, if information does go over the top of the existing CEN definition, this needs additional review and possibly postponement to a later version, as this is not required by the current 3GPP stage 1.

14)	s.14.3

         A call-back from a PSAP incurs additional risk,
         since the current mechanisms are not ideal for verifying that
         such a call is indeed a call-back from a PSAP in response to an
         emergency call placed by the IVS.  See the discussion in
         Section 11 and the PSAP Callback document [RFC7090].

I do not understand why call-back is being referred to here. Can you explain?



Regards

Keith Drage