1 Notice (c) ZTE CORPORATION. ZTE Corporation, grants a free, irrevocable license to 3GPP2 and its Organizational Partners to incorporate text or other copyrightable material contained in the contribution and any modifications thereof in the creation of 3GPP2 publications; to copyright and sell in Organizational Partner's name any Organizational Partner's standards publication even though it may include all or portions of this contribution; and at the Organizational Partner's sole discretion to permit others to reproduce in whole or in part such contribution or the resulting Organizational Partner's standards publication. ZTE Corporation is also willing to grant licenses under such contributor copyrights to third parties on reasonable, non-discriminatory terms and conditions for purpose of practicing an Organizational Partner’s standard which incorporates this contribution. This document has been prepared by ZTE Corporation, to assist the development of specifications by 3GPP2. It is proposed to the Committee as a basis for discussion and is not to be construed as a binding proposal on ZTE Corporation. ZTE Corporation, specifically reserves the right to amend or modify the material contained herein and to any intellectual property of ZTE Corporation other than provided in the copyright statement Aug 26,2008 RECOMMENDATIONDiscuss/FYI RECOMMENDATION :Discuss/FYI The Issues on Supporting Emergency Service over HRPD Network

2Background(1)  Supporting emergency service over HRPD is a required feature in A.S0008/9-C v2.0  This feature is noted by ‘HRPD Emergency Indicator’, two cases are being considered: AT initiated emergency serviceAT initiated emergency service Network initiated emergency serviceNetwork initiated emergency service  For the network initiated emergency service, TSG-A sent a Liaison to TSG-X and TSG-C and got their correspondences  TSG-A has taken a proactive approach and future proofed the appropriate signaling links in the event that such a use case is someday supported

3Background(2)  TSG-A LS questions for TSG-X  Can a mechanism be provided for the PDSN to recognize the invocation of emergency services for dormant ATs?  Can the PDSN include an indication of emergency service to the PCF/AN in the GRE header?  TSG-X’s correspondence : “Based on S.R0115 All-IP Network Emergency Call Support - Stage 1 Requirements and the HRPD requirements in Annex A of X.S0049 All-IP Network Emergency Call Support, TSG-X has not identified a need for these new mechanisms.” “Based on S.R0115 All-IP Network Emergency Call Support - Stage 1 Requirements and the HRPD requirements in Annex A of X.S0049 All-IP Network Emergency Call Support, TSG-X has not identified a need for these new mechanisms.” In addition, TSG-X reviewed A which forwards an emergency services indicator over the A9 and A11 interfaces towards the PCF and PDSN and noted that corresponding PDSN procedures were not specified. TSG-X requests clarification on TSG-A’s intent for sending the indicator to the PDSN. TSG-X would be happy to have a joint meeting for further discussion on this subject. In addition, TSG-X reviewed A which forwards an emergency services indicator over the A9 and A11 interfaces towards the PCF and PDSN and noted that corresponding PDSN procedures were not specified. TSG-X requests clarification on TSG-A’s intent for sending the indicator to the PDSN. TSG-X would be happy to have a joint meeting for further discussion on this subject.

4Background(3)  TSG-A LS question for TSG-C  Can a mechanism be provided for including an indication of emergency services in the Paging message for dormant ATs?  TSG-C’s correspondence : Based on our discussion, if this functionality is used to support Call Back, S.R0115 says that Call Back should be supported; however, it is not explicitly defined. TSG-C requires additional discussion and need to consider the anticipated actions of the access terminal once this message (parameter) has been received from the access network. While the intent of this feature may be a “nice-to-have”, it lacks the end-to-end support that is needed to make it fully operational. At this point, a Stage 1 document which explains the functional aspects of the Call Back feature is needed prior to moving forward with standards development. Based on our discussion, if this functionality is used to support Call Back, S.R0115 says that Call Back should be supported; however, it is not explicitly defined. TSG-C requires additional discussion and need to consider the anticipated actions of the access terminal once this message (parameter) has been received from the access network. While the intent of this feature may be a “nice-to-have”, it lacks the end-to-end support that is needed to make it fully operational. At this point, a Stage 1 document which explains the functional aspects of the Call Back feature is needed prior to moving forward with standards development.

5 Issue Need to be Clarified   Is network initiated emergency service (e.g., callback) is one of the system requirements?   How to understand the section 4.3 in S.R v2.0: 4.3 CALLBACK Once the UE originates and completes the emergency call, a responsible public safety authority (e.g., PSAP) may need to call back to the UE that originated the emergency call. [EC-12] Callback of an IMS Registered UE with an assigned TEL URI SHALL be supported.

6 Develop End to End Solution for Callback  If Callback is required, we need to develop end to end solution for callback  Main issues need to be specified when supporting callback:  Require SIP message to be enhanced to indicate emergency service? E.g., Priority field in SIP Header may be considered to indicate emergency requestE.g., Priority field in SIP Header may be considered to indicate emergency request  Require Interworking between SIP protocol and ISUP protocol if PSAP is located in CS domain to include emergency indication TBD issueTBD issue  Can a mechanism be provided for the PDSN to recognize the invocation of emergency services for dormant ATs? E.g., PDSN may get emergency notification via PCRF in SBBC spec, etc, PDSN includes an indication of emergency service to the PCF/AN in the GRE header.E.g., PDSN may get emergency notification via PCRF in SBBC spec, etc, PDSN includes an indication of emergency service to the PCF/AN in the GRE header.  Can a mechanism be provided for including an indication of emergency services in the Paging a dormant ATs? E.g., AN may include emergency indicator in Paging messageE.g., AN may include emergency indicator in Paging message

7Others  TSG-A approved to send an emergency indicator received from air interface messages (i.e., ConnectionRequest or ReservationOnRequest) over A9 / A11 interfaces towards the PCF/PDSN  The intention for sending the indicator to the PDSN is to distinguish an emergency call from a normal VoIP call  An emergency call should have higher priority against normal calls. However, all the EF (expedited forwarding) flows share the same DSCP value ‘101110’  When receives emergency indicator from A11 interface, the PDSN may perform the followings  give higher priority to this call in resource allocation, so as to guarantee the successful setup of A10 connection  others compress the steps of PPP negotiations. For example, by skipping ACCM negotiationcompress the steps of PPP negotiations. For example, by skipping ACCM negotiation do some special handling for accounting/billing. For example, do not charge user for emergency calldo some special handling for accounting/billing. For example, do not charge user for emergency call

8Summary  Is network initiated emergency call (callback) a requirements in S.R v2.0?  How does 3GPP2 support network initiated emergency call (callback) at this stage?  TSG-A has taken a proactive approach and future proofed the appropriate signaling links in the event that such a use case is someday supported

9 Thank You