Subject: [Ecrit] Car crash, ecall, etc

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 24 Jul 2014 16:11:02 +0000

I ready through the various drafts on this, and I have some general comments.

1)	I think the reservation of new URNs to support this should be moved out into a single separate draft, along with any associated session level requirements. That requires some harmonisation, as we have proposals in two separate drafts that are different.

As it is envisaged that this would exist on cellular devices, I think such a document needs to reference 3GPP TS 23.167 and 3GPP TS 24.229, and talk about what is expected to occur when the vehicle call is activated in a cellular network either does not support emergency call, or does not support PS mode emergency call, or there is only CS mode access.

Further it needs to talk about whether SRVCC should be allowed on such calls or not, and whether the data is expected to continue or not after SRVCC has occurred.

2)	The test URN needs some study. It is not a sos URN so in cellular networks it currently would not test the emergency bearer capabilities, or the local network capabilities for a roaming user.

3)	In regard to the multiple data mechanisms, these are apparently regional, i.e. North America versus Europe. Given that vehicles more and more move between countries, there needs to be some discussion in each solution about detecting the appropriate solution to use.

Regards

Keith

---

From: Randall Gellens <[email-masked]>
Date: Thu, 24 Jul 2014 13:24:42 -0700

Hi Keith,

Thanks very much for your reviews.

The eCall draft does reference 3GPP and TS22.101 for eCall.  I can 
add references to 23.167 and 24.229 to both for cellular packet 
switched emergency calling, although the documents try to avoid 
getting into cellular-specific details, leaving those to 3GPP and 
other organizations.  Similarly, I think discussion of domain 
selection (e.g., CS or PS), SRVCC, and similar cellular-specific 
issues should be left to 3GPP.  I can add text to this effect to the 
documents to make this more clear.

The test URN pre-exists this draft, and I believe the current eCall 
test call facility is a non-emergency number so does not get treated 
as an emergency call.  There is the possibility of operators treating 
a vehicle call in the test URN in a way that tests as much 
functionality as desired, but that would be best left to 3GPP or 
another cellular-specific body, I think.  I could add some text to 
mention some of this if you think it would be helpful.

I could add an informative mention of a vehicle being able to operate 
in more than one region and hence use either eCall or the more 
generic which uses VEDS.  It's possible that additional regions will 
adopt one of these, but of course we don't know.

Thanks again for your comments.

At 4:11 PM +0000 7/24/14, Keith (Keith) DRAGE wrote:

>  1)	I think the reservation of new URNs to support this should be 
> moved out into a single separate draft, along with any associated 
> session level requirements. That requires some harmonisation, as we 
> have proposals in two separate drafts that are different.
>
>  As it is envisaged that this would exist on cellular devices, I 
> think such a document needs to reference 3GPP TS 23.167 and 3GPP TS 
> 24.229, and talk about what is expected to occur when the vehicle 
> call is activated in a cellular network either does not support 
> emergency call, or does not support PS mode emergency call, or 
> there is only CS mode access.
>
>  Further it needs to talk about whether SRVCC should be allowed on 
> such calls or not, and whether the data is expected to continue or 
> not after SRVCC has occurred.
>
>  2)	The test URN needs some study. It is not a sos URN so in 
> cellular networks it currently would not test the emergency bearer 
> capabilities, or the local network capabilities for a roaming user.
>
>  3)	In regard to the multiple data mechanisms, these are 
> apparently regional, i.e. North America versus Europe. Given that 
> vehicles more and more move between countries, there needs to be 
> some discussion in each solution about detecting the appropriate 
> solution to use.
>
>  Regards
>
>  Keith
>  _______________________________________________
>  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: ---------------
The chance of forgetting something is directly proportional
to.....to........uh..............