Subject: RE: [Ecrit] Open Issues from the 3GPP CT/IETF ECRIT Joint Session on Emergency Services

From: "Roger Marshall" <[email-masked]>
Date: Mon, 21 Aug 2006 17:04:21 -0700

In reference to the identifier issue, below:

If 3GPP was amenable to defining the following mappings in the
requirements set for UE and P-CSCF behaviour, then we would have
alignment between 3GPP and IETF on this one issue, as I see it.

As per the existing ECRIT requirements language, we would have:

Example: 		ECRIT:				3GPP:
9,112			Dial String				[TBD]
This can be anything 3GPP specifies
1-2-2			Emergency Number			"IMS
Emergency Call Identifier" (per below)
urn:service:sos	Emergency Service Identifier	"Emergency Service
Identifier" (alignment of ESI terms)

Additionally, assuming that emergency calls always pass through a
local-policy-driven P-CSCF (please correct if not the case), then the
P-CSCF could be responsible to do the translation from "IMS Emergency
Call Id" over to an "ESI" (if it needed to be done), otherwise it
consideration could be made for the UE to have already done the
translation.

Roger Marshall

>-----Original Message-----
>From: Hannes Tschofenig [mailto:[email-masked]] 
>Sent: Sunday, August 20, 2006 2:09 AM
>To: ECRIT; [email-masked]
>Subject: [Ecrit] Open Issues from the 3GPP CT/IETF ECRIT Joint 
>Session on Emergency Services
>
>Hi Hannu,
>Hi all,
>
>at the 3GPP CT/IETF ECRIT joint session on emergency services 
>we discussed the following aspects that required follow-up actions:
>
>IMS emergency call identifier, Emergency Dial String, Emergency Number:
>-----------------------------------------------------------------------
>
>Text from the meeting minutes:
>"
>Hannu then discussed the detection of emergency calls.  The 
>network is required to detect that a call is an emergency 
>call, but no specific requirements have been made on how this 
>should happen.  The terminal must also be able to detect an 
>emergency number (e.g. 112) or an "IMS emergency call 
>identifier".  This latter is a placeholder in the 3gpp 
>architecture.  The group then had a lively discussion of the 
>role of the IMS emergency call identifier.  After the 
>discussion, it is clear that "identifier" is being used by 
>3gpp here in a way here that does not match the way it is used 
>by the current IETF document set.  The intended 3gpp use is as 
>a short, mnemonic string that could be input by the users to 
>indicate that a call is an emergency.  As such, it is closer 
>to what the IETF thinks of as a dialstring, though without the 
>common connotation that it be purely numeric.  The 
>URN:service:sos identifier family, in contrast, is intended to 
>be used in protocol exchanges rather than as user-input 
>strings.  In different UIs, different input methods would be 
>used to invoke the look-up of those identifiers and the 
>initiation of emergency calls to the PSAPs identified. In some 
>UIs, the mapping might be from a well-known numeric string, 
>from a menu, or even from an action like the deployment of an 
>airbag and the trigger of a related sensor.
>
>Hannu asked if there was general agreement that there was no 
>reason to require a non-number user interface element.  There 
>was agreement to recommend that 3gpp should consider removing 
>this requirement while the exchanges are limited to voice 
>calls.  For multimedia, it may be required.  A CR to make this 
>change would need to be drafted and approved in 3gpp if 3gpp 
>accepts this recommendation.
>"
>
>Questions:
>* Has a CR been submitted?
>* Is there a chance to reduce the terminology mismatch?
>
>
>
>Privacy:
>--------
>
>Text from the meeting minutes:
>"
>The group then discussed the interaction of emergency call 
>location and privacy.  The current 3gpp requirements state 
>that locating emergency calls over-rides a subscriber's 
>privacy request, but that local regulation may over-ride this 
>requirement to restore the presumption of privacy.  The 
>Japanese delegation at a previous meeting had this privacy 
>concern, but there remained some confusion about the exact 
>nature of the issue.  The group recommended that the Japanese 
>delegates be probed by 3gpp for further information on their needs.
>"
>
>Question: Has the 3GPP learned more about the privacy aspects 
>raised by the Japanese delegate?
>
>
>
>Roaming:
>--------
>
>Text from the meeting minutes:
>"
>Brian raised the issue of calling during disasters scenarios, 
>when links 
>are broken between local network and home network.  In the 
>current 3gpp 
>spec, this is the same as an unauthenticated call by a phone without a 
>sim or usim card, and the same rules apply.  Several folks 
>raised issues 
>with the fragility of this connection between the home and 
>local network 
>and expressed concern that it implied two different cases (failure of 
>authentication because of network conditions and failure of 
>authentication because of lack of credentials) were being 
>subsumed into 
>a single response.
>
>During the course of this discussion, James Polk asked whether 
>3GPP had 
>defined roaming.  There are, unfortunately, several possible answers, 
>but the spirit of the 3gpp requirements is that the entities involved 
>share a regulatory environment.  This usually means that they 
>are in the 
>same country, but the U.S. is a special case.
>
>Milo noted that the issue of roaming is not quite the same in 3gpp2; 
>there the link local address or COA is used to contact the 
>local p-cscf, 
>and registration is with that local server, regardless of the roaming 
>status.
>
>This discussion caused the group to recommend two action items 
>for 3gpp: 
>  to open the question of what the criteria are for roaming in 
>an access 
>independent manner, and to open the related question of what are the 
>cellular specific criteria for roaming.
>"
>
>Question: What happened to the two action items?
>
>Ciao
>Hannes
>
>_______________________________________________
>Ecrit mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/ecrit
>

_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit