X50-20090615-0xx ZTE VSP Proposal 1 Title: 3GPP2 Specific Vendor Specific Protocol Sources: ZTE Contact: Rajesh Bhalla

Slides:



Advertisements
Similar presentations
HSGW requested UE Detach for SIPTO HUAWEI Jixing Liu: Notice The contributors grants a free, irrevocable.
Advertisements

X xx CT+ZTE PCC for cdma2000 UE Init Call Flows 1 1 Title: PCC for cdma2000 – UE-Init Example Call Flows Sources: CTC, ZTE Contact: CHINA TELECOM.
Page 1 Title: Traffic Detection Function Extensions for cdma2000 1x and HRPD Networks Sources: Qualcomm Contact: George Cherian
HUAWEI TECHNOLOGIES CO., LTD. Huawei Technologies Co., Ltd. grant a free, irrevocable license to 3GPP2 and its Organizational Partners to.
X xxx Pre-Registration Context in eHRPD 1 Pre-Registration Context Removal in eHRPD System Sources: China Telecom, ZTE Contact: Li
TSG-C Title: CSNA-Lite L2 Ack issue ____________________________________________________________________________________________________________________.
XHRPD Example Scenario for MSS Masa Shirota Qualcomm Inc. July 15, GPP2 Dalian Meeting Recommendation: FYI Notice QUALCOMM Incorporated grants a.
3GPP2 A r0 3GPP2 C xxxr0 TSG-A WG3 and TSG-C WG2 Title: HRPD Redirect on EPC Unavailable Source: Mike DolanAlcatel-Lucent Dave.
1 IP Service Authorization Support and Mobility Selection for X.S0011-E Source: QUALCOMM Inc.: Masa Shirota, George Cherian, Jun Wang,
1 Title: TDF support in cdma2000 1x and HRPD Networks Sources: China Telecom, ZTE, Huawei Contact: CT: Heng Nie ( ), Congjie Mao(
China Telecomm Peirong Xie ZTE Corporation Rajesh Bhalla Huawei Jixing Liu
1 cdma2000® Data Service Transition to NULL Support Jun Wang Ravi Patwardhan June 5, 2003 Recommendation -
3GPP2 X xxx Title: SIP6 access and MIP6 Access Differentiation Sources: ZTE Contact: Rajesh Bhalla
Broadcast Area Based Management for BCMCS Quanzhong Gao Weidong Wu 04/05/2005.
Security Framework for (e)HRPD 1 S GPP2 TSG-S WG4 Source: QUALCOMM Incorporated Contact(s): Anand Palanigounder
IP Packet Tunneling and Routing in UMB March 26 th, 2007 Qualcomm/Alcatel-Lucent/Hitachi Notice Contributors grant a free, irrevocable license to 3GPP2.
Authentication Profile for UICC- less eHRPD Terminals QUALCOMM Incorporated Contact(s): Anand Palanigounder Jun Wang.
80-VXXX-X A July 2008 Page 1 QUALCOMM Confidential and Proprietary PCC Support for cdma2000 QUALCOMM Inc. Jun Wang, George Cherian, Masa Shirota
1 Notice Contributors grant a free, irrevocable license to 3GPP2 and its Organization Partners to incorporate text or other copyrightable material contained.
The contributing companies grant a free, irrevocable license to 3GPP2 and its Organizational Partners to incorporate text or other copyrightable.
QUALCOMM Incorporated 1 Protocol Options for BSN- BSMCS Controller Interface Jun Wang, Kirti Gupta 05/16/2005 Notice: Contributors grant a free, irrevocable.
HUAWEI TECHNOLOGIES CO., LTD. Slide title :40-47pt Slide subtitle :26-30pt Color::white Corporate Font : FrutigerNext LT Medium Font to.
X xxx China Telecom Requirements on Accounting at HA/LMA Title: Accounting at HA/LMA for cdma2000 (Work Item # 3GPP ) Sources: China Telecom.
Title: Type: Arial Bold Size : 32-36pt Color : The theme blue Subtitle: Type : Arial Size : 24pt Color: The theme gray 1 TSG-C SWG2.2 Title: Idle Load.
Page 1 January 16, 2008 Source: 3GPP2 TSG-S WG4 (Security) Contacts: Anand Palanigounder, Chair, TSG-S WG4 ( Zhibi Wang,
80-VXXX-X A July 2008 Page 1 QUALCOMM Confidential and Proprietary PMIP Comparison QUALCOMM Inc. Jun Wang, George Cherian, Masa Shirota
80-VXXX-X A July 2008 Page 1 QUALCOMM Confidential and Proprietary PCC Support for cdma2000 QUALCOMM Inc. Jun Wang, George Cherian, Masa Shirota
May 12, 2008 Alcatel Lucent, Cisco, Motorola, Nortel, Verizon ABSTRACT: Proposed is additional key hierarchy and derivation for EPS access over eHRPD.
X xxx ZTE Discussion on cdma2000 Charging with PCC Title: Discussion on PCC Charging for cdma2000 1x and HRPD Sources: China Telecom, ZTE Contact:
1 Title: eHRPD offline charging proposal Sources: China Telecom Contact: CT: Peirong Wenyi ZTE:
1 Authentication and User Profile April 24, 2007 Jun Wang QUALCOMM Inc. Notice Contributors grant a free, irrevocable license to 3GPP2 and its Organization.
Source companies grant a free, irrevocable license to 3GPP2 and its Organizational Partners to incorporate text or other copyrightable material contained.
HUAWEI TECHNOLOGIES CO., LTD. Slide title :40-47pt Slide subtitle :26-30pt Color::white Corporate Font : FrutigerNext LT Medium Font to.
X xxx ZTE Discussion on cdma2000 Charging with PCC Title: Discussion on handover indicator transfer in S2a Sources: China Telecom, Huawei, Alcatel-Lucent.
3GPP2 SX r0 TSG-SX WG3 - PDS Title: Overview of the 3GPP TFT change and Possible Solutions Source: TSG-SX WG3 Chair and Vice Chair Abstract:
March 2011 C2 – Company Confidential SOURCE: Jialin Zou, David Rossetti, Satish Kanugovi (Alcatel-Lucent)
Background Both RoHCv1 and RoHC v2 are supported in 3GPP LTE R8 and R9
HRPD Network Load Balance ZTE grants a free, irrevocable license to 3GPP2 and its Organizational Partners to incorporate text or other copyrightable material.
ABSTRACT: This contribution proposes the HRPD-WiMAX handoff solution. TITLE: HRPD-WiMAX Handoff TSG-A WG4 RECOMMENDATION: Review and Adopt Samsung Electronics.
Supporting Local Breakout in HRPD Femto Peerapol Tinnakornsrisuphap Qualcomm Doug Knisely
August 25, 2008 Alcatel Lucent ABSTRACT: 1x System Reliability is important in the face of major events, such as an earthquake. There are several ways.
Jun Wang Anand Palanigounder Peerapol Tinnakornsrisuphap
X xxx ZTE Discussion on cdma2000 Charging with PCC Title: Inter-RAT RAN information management protocol Stack Sources: NSN Contact: Scott Marin,
3GPP2 X xxx Title: Subscriber QoS Profile Support in eHRPD System Sources: China Telecom, ZTE Contact: CT: Peirong Li Wenyi.
Page 1 Notice © All rights reserved. Qualcomm Incorporated grants a free, irrevocable license to 3GPP2 and its Organizational Partners to incorporate.
Comment to Limited Idle Mode Nortel Networksgrants a free, irrevocable license to 3GPP2 and its Organizational Partners to incorporate text or other copyrightable.
1 | Tunneling Method – Inter-tech. HO | August 2007 Title: A Tunneling Method for Inter-Technology Handoff Source: Mike Dolan, Alcatel-Lucent,
Jun Wang Anand Palanigounder Peerapol Tinnakornsrisuphap
EHRPD-LTE Inter Technology Spectrum Optimization Source: Qualcomm Incorporated Contact: Jun Wang/George Cherian September 9, 2013 Notice ©2013. All rights.
Tunneling Protocol Structures for UMB to HRPD Interworking Linhai He Peerapol Tinnakornsrisuphap
111 X TITLE A Proposal For QoS and Charging Policy Control SOURCE Parviz Yegani Tel: Fax:
1 MAPSUP in eHRPD: Data forwarding Tunnel Sources: ZTE Contact: Bi YiFeng Rajesh Bhalla
X xx CT+ZTE PCC for cdma2000 MS Init Call Flows 1 1 Title: PCC for cdma2000 – MS-Init Call Flow Example Sources: CTC, ZTE Contact: CHINA TELECOM.
1 MAPSUP in eHRPD Sources: ZTE Contact: Bi YiFeng Rajesh Bhalla ABSTRACT:
80-VXXX-X A July 2008 Page 1 QUALCOMM Confidential and Proprietary PCC Support for cdma2000 QUALCOMM Inc. Jun Wang, George Cherian, Masa Shirota
C Title: Next Steps for Femtocells Date: 03 December 2007 Source: Airvana, Alcatel-Lucent, Nortel Abstract:The contribution addresses.
Idle-State Data Buffering and Paging Framework June 04, 2007 Source companies grant a free, irrevocable license to 3GPP2 and its Organizational Partners.
1 Notice (c) ZTE CORPORATION. ZTE Corporation, grants a free, irrevocable license to 3GPP2 and its Organizational Partners to incorporate text or other.
0 软交换应用的探讨 赵慧玲 2004 年 05 月 Dynamically Coverage Management By Caiqin Zhu(Catherine Zhu) China Telecom Apr © GPP2 China Telecom.
1 PPP Free Operation Mobility Management January 16, 2006 Jun Wang, Pete Barany, Raymond Hsu Qualcomm Inc Notice: Contributors grant free, irrevocable.
1 Subject:Draft Responses to BBF Comments re. cdma2000 MO Preview Date: 25 January 2010 Source: Doug Knisely TSG-X FMOAHG Co-chair, BBF Liaison Contact:
Adding LTE-1x CSFB IOS specification in 3GPP2 Sources: China Telecom, Contact: Li Wenyi ABSTRACT: This contribution is to analyze the.
1 Notice (c) ZTE CORPORATION. ZTE Corporation, grants a free, irrevocable license to 3GPP2 and its Organizational Partners to incorporate text or other.
1 Title: A Proposal for Identifying Hand-In Femto Cell Sources: ZTE Contact: Yonggang Fang Xiaowu Zhao
1 OMP for Dual Rx AT in LTE tunneled mode Contributors grants a free, irrevocable license to 3GPP2 and its Organizational Partners to incorporate text.
Signaling Packet Routing for Layer 3 approach in UMB-HRPD/1x interworking KDDI Corporation, Tsunehiko Chiba, Osamu.
Clarifications on Work Split among TSG-X/A for 3GPP2 Network Evolution March 26, 2007 Airvana/Alcatel-Lucent/CTC/Fujitsu/ Hitachi/KDDI/NEC/Qualcomm/ZTE.
1 IP Service Authorization Support and Mobility Selection Source: QUALCOMM Inc.: Masa Shirota, George Cherian, Jun Wang,
Source: Qualcomm Incorporated Contact: Jun Wang, George Cherian March 1, 2010 Page 1 3GPP2 Femtocell Phase II Femto Access Control Enhancement Notice ©
E-UTRAN - HRPD rev B Interworking
Presentation transcript:

X xx ZTE VSP Proposal 1 Title: 3GPP2 Specific Vendor Specific Protocol Sources: ZTE Contact: Rajesh Bhalla ABSTRACT: Extensible mechanisms based on IETF recommendations are needed to allow for the exchange of configuration and/or operational parameters between the UE and the HSGW at any time during IP-CAN sessions. Such parameters may pertain to a protocol layer above LCP. Such parameters may also pertain to a single IP-CAN session, or to several/all IP-CAN sessions Recommendation: Review and adopt ZTE 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 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 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 contributors. ZTE specifically reserves the right to amend or modify the material contained herein and to any intellectual property of contributors other than provided in the copyright statement above.

X xx ZTE VSP Proposal 2 Introduction  Background 3GPP2 VSNCP and VSNP protocols (as specified in X.S0057) are based on the PPP Vendor Protocol framework defined in RFC3772 VSNCP and VSNP are 3GPP2 proprietary network control and network protocols, defined to meet eHRPD access network specific requirements for eHRPD – E- UTRAN Interworking RFC3772 provides another protocol, the Vendor Specific Protocol (VSP – Protocol Number 0x405b) VSP is intended for use in situations where per-link signaling is required  The Proposal The proposal is to adopt RFC3772 recommended framework for 3GPP2 Vendor Specific Protocol (VSP) (Protocol Number – 0x405b) RFC2153 specifies another framework for PPP Vendor Extensions. That framework, however, is not well suited for the requirements specific to eHRPD – E- UTRAN Interworking Per the proposed RFC3372 recommended VSP framework in this contribution and the accompanying protocol detailed contribution: once the underlying PPP session has been established and peer entities authenticated (if so required), either the UE and/or the HSGW can initiate the exchange of the necessary parameters by the use of VSP protocol

X xx ZTE VSP Proposal RFC3772 Based 3GPP2 VSP Framework High Level Description  The proposed 3GPP2 VSP is based on the VSP framework in RFC3772 (Protocol Number 0x405b)  The proposed 3GPP2 VSP provides a mechanism for peer-to-peer signaling between the UE and the HSGW for the exchange of necessary parameters  Such 3GPP2 VSP signaling does not impact LCP and/or other network layer protocols (viz. VSNCP and VSNP) and is applicable to the data-link between the UE and the HSGW  3GPP2 VSP uses the same packet exchange and option extension mechanisms as LCP specified in RFC1661, but with a different set of options  One 3GPP2 VSP packet is carried in the PPP Information field, with the Protocol field set to 0x405b  Once the underlying PPP session has been established and peer entities authenticated (if so required), 3GPP2 VSP signaling can be performed at any time. Per the proposed 3GPP2 VSP framework:  Either the UE and/or the HSGW can initiate the exchange of required parameters by the use of a VSP Configure-Request packet  On successful processing of the VSP Configure-Request packet, the receiving entity responds with a VSP Configure-Ack packet

X xx ZTE VSP Proposal Example 3GPP2 VSP Packet Exchange  The figure below illustrates an example high level HSGW initiated parameter exchange procedure based on the proposed 3GPP2 Vendor Specific Protocol

X xx ZTE VSP Proposal Different VSP Approaches Discussions  RFC2153 and RFC3772 provide two different approaches for PPP extensions  Some of the differences in the two approaches include the Protocol Number and the packet format  X.S0011-D adopted VSP packet based on RFC2153  However, we chose RFC3772 for 3GPP2 VSNCP and 3GPP2 VSNP  We could have achieved similar VSNCP and VSNP functionality by using RFC2153 VSP framework though  Rightly – we did not use RFC2153 framework for 3GPP2 VSNCP and 3GPP2 VSNP, as RFC3772 addresses some of the problems in RFC2153 based approach !!  RFC2153 VSP exchange happens at LCP level, and there could/would be parameters exchanged between the UE and the HSGW that do not belong to the LCP layer  (Just to mention, most of the parameters exchanged between the UE and the PDSN in X.S0011-D by use of RFC2153 VSP do not belong to the LCP layer)  RFC3772 provides a method that addresses the problems that have been identified for the RFC2153 VSP approach  From that perspective: RFC3772 mentions about the problems with using RFC2153 extensions. Notably :  RFC2153 VSP happens at LCP layer, hence the exchange of the parameters could begin before identification and authentication of the peer has been done  The use of non-standardized protocol number/Kind values for parameter exchange is not conducive to the development of efficient diagnostic mechanisms. Having an IANA specified fixed number for VSP provides a reasonable diagnostic approach  In addition (though not in RFC3772), the exchange of the parameters that do not belong to LCP, at LCP layer (in RFC2153 approach) is a protocol-layer violation

X xx ZTE VSP Proposal VSP Based on RFC2153 Framework Some Details  The ‘Protocol’ field is set to: 0xC021  LCP ‘Information’ field contains Vendor Specific Packet (VSP) with Code= ‘0’  3GPP2 specific ‘Kind’ values are defined for the exchange of different parameters between the UE and the PDSN  Based on the ‘Kind’ value, a different set of additional parameters (Values) can be defined  Value(s) field is customized to be vendor specific  No standardized approach for the format of the Value(s) field has been defined

X xx ZTE VSP Proposal VSP Based on RFC3772 Framework Some Details  The ‘Protocol’ field is set to: 0x405b  The ‘Information’ field contains one packet with the format below  The ‘Data’ field is customized to be vendor specific

X xx ZTE VSP Proposal VSP Based on RFC3772 Framework Some Details (contd..)  The proposal is to standardize the format of the ‘Data’ field to be similar to the LCP Packet Format (RFC1661)  Having defined LCP-similar packet format, extensions for carrying the ‘parameters’ are defined by inheriting the format of LCP ‘Configuration Options’ (RFC1661)  Similar to RFC1661, ‘Code’ values are proposed for Configure-Request, Configure-Ack and Configure-Reject VSP packets to enable the exchange of parameters between the UE and the HSGW  (Any other names for the packets could be chosen for achieving similar functionality)  All of the above is similar and intuitive to the framework adopted for the definition of 3GPP2 VSNCP protocol

X xx ZTE VSP Proposal RFC2153 Vs RFC3772 VSP Protocol Framework  RFC2153  Extensions for exchanging new parameter types are defined by defining new ‘Kind’ values  ‘Kind’ values are defined for every new parameter that needs to be exchanged  The behavior and associated response for a VSP packet is based on the ‘Kind’ value  As new ‘Kind’ values are defined, associated behavior needs to be defined as well  This definition of the behavior for every ‘Kind’ value is in addition to the definition of the method for the handling of the associated parameters exchanged (within the Values field)  RFC3772  A new protocol number (0x405b) makes the need for defining ‘behavior’ for every new type of parameter exchanged not necessary  By defining generic behavior for supported ‘Code’ values (request, ack, reject packets etc.), definition of the behavior for handling the packet for every new type of parameter exchanged not necessary  The behavior for handling of the packets with the identified ‘Code’ values is inherited from PPP framework (RFC1661)  With that done in the baseline 3GPP2 VSP framework, the extensions for new parameter types are defined with the definition of Configuration Options for new parameters that need to be exchanged.  This framework and extension mechanisms align with the approach used for other protocols as well (e.g., PPP, VSNCP, etc.)  In summary; for defining extensions for new parameter types:  RFC2153 framework needs definition of new ‘Kind’ values, description of the behavior for packets with new ‘Kind’ values, the description of new associated parameters (within the Value field) and the associated behavior for handling new parameters  RFC3772 framework needs definition of new Configuration Options (for new parameters to be exchanged) and the associated behavior for handling the new parameters

X xx ZTE VSP Proposal RFC2153 vs RFC3772 VSP Approach Used  No protocol-layer violations with RFC3772 based framwork  The currently identified parameters that need to be exchanged between the UE and the HSGW have nothing to do with the LCP-layer  A protocol-layer violation-proof method is used for VSP based parameter exchange  RFC2153 defined VSP packet can still be used if some parameter(s) specific to LCP are identified for exchange between the UE and the HSGW  No exchange of parameters till the peer has been identified and authenticated  X.S0011-D VSP procedures do not state of any such restrictions/limitations on the exchange of LCP based VSP packets  That is not to say that such classification/limitations cannot be added at this stage or in the future  Doing so would make LCP based VSP implementation much fuzzy though  We would not want to say that certain ‘Kind’ of VSP packets cannot be exchanged till LCP negotiations and the (next level) of authentication has been completed, whereas other ‘Kind’ of VSP packets have no such restrictions  Whereas, with RFC3772 based approach, such VSP exchange happens only past-PPP establishment and authentication phase

X xx ZTE VSP Proposal Proposal and Recommendations  In summary; for defining extensions for new parameter types:  RFC2153 framework needs definition of new ‘Kind’ values, description of the behavior for packets with new ‘Kind’ values, the description of new associated parameters (within the Value field) and the associated behavior for handling new parameters  Whereas, RFC3772 framework needs definition of new Configuration Options (for new parameters to be exchanged) and the associated behavior for handling the new parameters  No protocol-layer violations with the RFC3772 based approach  RFC2153 based VSP can be used for the exchange of LCP related parameters (as and when identified)  No parameter exchange till the peer has been identified and authorized (if authorization required)  IANA specified protocol number for VSP; assuring industry and IETF support (in the future) and also for matters such as standardized diagnostic tools etc.  The recommendation, therefore, is to adopt RFC3772 VSP framework for the definition of 3GPP2 Vendor Specific Protocol for eHRPD deployments