* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Download X31-20050926-029 R2 QCOM 3GPP2 Packet Data Network
Point-to-Point Protocol over Ethernet wikipedia , lookup
IEEE 802.1aq wikipedia , lookup
Distributed firewall wikipedia , lookup
Asynchronous Transfer Mode wikipedia , lookup
Computer network wikipedia , lookup
Wireless security wikipedia , lookup
Piggybacking (Internet access) wikipedia , lookup
List of wireless community networks by region wikipedia , lookup
Zero-configuration networking wikipedia , lookup
Internet protocol suite wikipedia , lookup
Serial digital interface wikipedia , lookup
Network tap wikipedia , lookup
SIP extensions for the IP Multimedia Subsystem wikipedia , lookup
Deep packet inspection wikipedia , lookup
Wake-on-LAN wikipedia , lookup
Extensible Authentication Protocol wikipedia , lookup
Recursive InterNetwork Architecture (RINA) wikipedia , lookup
UniPro protocol stack wikipedia , lookup
CDMA2000 Packet Data Access Network Evolution September 26, 2005 Jun Wang, Pete Barany, Bibhu Mohanty Qualcomm Inc Notice: Contributors grant free, irrevocable license to 3GPP2 and its Organization 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 portions of the contribution; and at the Organization Partner’s sole discretion to permit others to reproduce in whole or in part such contributions or the resulting Organizational Partner’s standards publication. Contributors are 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 the contributors 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 the contributors. The contributors specifically reserves the right to amend or modify the material contained herein and nothing herein shall be construed as conferring or offering licenses or rights with respect to any intellectual property of the contributors other than provided in the copyright statement above. 1 Outline • • • • • • • • Current Architecture Problems with Current Architecture Objectives Proposed New Architecture Proposed Solution Call Flows Transition Plan Conclusion and Further Works 2 Current Packet Data Network Architecture HA HAAA HA Packet Data network ISP HA network PSTN IMS Servers Home IP network IMS Service Network “Public” Public” IP Network MGW User data HSS signaling P-P Interface PDSN Operator IP Network PDSN A10/A11 A13 in A.S0009 A10/A11 PCF A8/A9 BTS B Node BTS B Node A13 in A.S0008 or A3/ A7 in IOS 5.0 BTS B Node Opeartor IP Network 3GPP2 Operator IP Network PCF A8/A9 Operator IP Network BSC/AN RNC 3GPP2 Specific Nodes BTS B Node Operator IP ” Network RNC BSC/AN BTS BTS B Node BSC/AN RNC BTS B Node BTS B Node BTS B Node BTS B Node MS/AT 3 Current User Plane Protocol Stack for Simple IP App App TCP/UDP TCP/UDP IP IP PPP encap. PPP encap. HDLC-like Framing HDLC-like Framing Cdma2000 Air Interface MS/AT Cdma2000 Air Interface GRE GRE GRE GRE IP IP IP IP Link Layer Link Layer Link Layer Link Layer PL PL PL PL BSC/AN PCF IP Link Layer Link Layer PL PL End Host PDSN 4 Current 3GPP2 Solutions • PPP at the PDSN and the MS/AT • PPP performs following functions – – – – – – Packet Data Service Authentication IP address allocation IP header compression negotiation and configuration Protocol identification HDLC-like Framing for higher layer packets Error detection for higher layer packets • For Access Network Authentication: – 1x: Using IS-41 authentication procedures – HRPD: Rely on PPP CHAP between the AT and AN 5 Problems with the Current Architecture • Network Complexity – Need multiple interfaces – Require too many 3GPP2 specific entities – Handoff Complexity (Inter-PDSN, Inter PCF, Inter BSC handoff) • Substantial Latency for both signaling and bearer – Call setup Latency – Bearer Transmission Latency • HDLC-like Framing is not efficient – Processing Intensive – Unpredictable Increase in Bandwidth • Can only have one Header Compression (HC) Instance because of single PPP restriction • Excess coupling between RAN and PDSN – Packet Dropping in the RAN affects HC state in the PDSN – Need Flow Control Mechanism between the RAN and the PDSN • Centralized Architecture limits Scalability – PDSN needs to maintain per-user states for all terminals in dormancy • Hard to add new features/services 6 Objectives (1) • Simplify the network architecture – Streamline network entities and interfaces – Simplify handoff procedures • Universal access – Common Mobility management across several access networks – Cdma2000/WCDMA/WLAN… • • • • • • Common user experience across different networks Interworking between the new network and legacy network Smooth Transition to the new architecture Ability of rapid introduction of new services Reduce the cost of network/operations Backward Compatibility – Backward Compatibility to the legacy network – Backward Compatibility to the legacy terminal 7 Objectives (2) • Improve data transmission/ bandwidth efficiency • Seamless Handoff • Provide “Always On” capability while minimizing the state maintenance • Reduce Signaling latency/chattiness • Reduce media transmission delay • Improve network security • Enhance packet data service provisioning 8 Proposed New Architecture HA HAAA HA Packet Data network ISP HA network PSTN LMHA: Local Mobility Home Agent IMS Servers Home IP network IMS Service Network “Public” Public” IP Network MGW CAP: Controlling Access Point AGW: Access Gateway RRM: Radio Resource Management HSS LMHA DHCP Server User Data/ Signaling LMHA Signaling Only 3GPP2 Specific Nodes Operator IP Network CAP AGW CAP CAP RRM AGW AGW RRM 3GPP2 Operator IP Network RRM Operator IP Network BTS BTS BTS MS/AT BTS BTS BTS 9 Functions of Access Network Entities (1) • Local Mobility Home Agent (LMHA) Functions: – Controlling/ Delegating IP address to the MS/AT – Mobility Management by acting as a MIP Home Agent for the MS/AT • Controlling Access Point (CAP) includes two entities: – Access Gateway (AGW) – Radio Resource Management (RRM) • Access Gateway (AGW) Functions: – – – – First-Hop Router for the MS/AT Authentication Functions RADIUS Client (for authentication) Mobility Management by sending Binding Updates to the LMHA on behalf of the MS/AT – DHCP Relay/Server – Some other 3GPP2 specific PDSN functions (Hot lining?) 10 Functions of Access Network Entities (2) • Radio Resource Management (RRM) Functions: – – – – – – Common Resource Management Dedicated Resource Management Radio Session Management Maintain the MS/AT Session State Session Transfer Radio Link Management: – Connection Setup and Release – Handoff – QoS Support – – – – – Header Compression Accounting Functions RADIUS Client (for accounting) TFT Ingress address filtering • Base Transceiver System (BTS) Functions: – – – – IP Terminating Point Common Resource Management Dedicated Resource Management Implementing OTA Protocol Stack (along with RRM) 11 Interfaces • Interface between LMHA and CAP: – Use IETF Standard Protocol (e.g., MIP) • Interface between CAP and CAP: – 3GPP2 standard interface 12 Proposed Solution • Key Concepts – Remove HDLC-like Framing and use Segment Based Framing in the CAP – Authentication: – Use IETF protocol, e.g., EAP – IP Address Assignment: – Use IETF protocol, e.g., DHCP – Header Compression Negotiation: – Using OTA signaling – Maintain the packet data session state in the CAP – Decoupling Handoff from Session Transfer – Current 3GPP2 specific PDSN/PCF functions integrated to the CAP – CAP Interworks with legacy RANs via existing 3GPP2 interfaces 13 Proposed User Plane Protocol Stack for Simple IP App App TCP/UDP TCP/UDP IP IP IP Seg. Framing Seg. Framing IP IP Cdma2000 Air Interface Cdma2000 Air Interface Link Layer Link Layer PL PL MS/AT CAP IP Link Layer Link Layer PL PL End Host LMHA 14 Authentication • Potential EAP Methods: – Possible Requirements: – Need to provide mutual authentication – Need to provide User Identity Privacy – Need to derive session keys for OTA protection – Candidate Solutions: – EAP-AKA – EAP-TLS-PSK (does not provide user identity privacy) – EAP-TTLS • EAP Transport: – EAP over PANA, or – EAP over cdma2000 15 Call Flows for Evolved Architecture (1) (for Simple IPv6 or Mobile IPv6 MS) MS CAP/BTS DHCP Server LMHA MIPv6 HA HAAA 1. OTA Signaling 2. EAP over PANA or EAP over cdma2000 Link Layer 4. Key Exchange to derive key for OTA protection 6.IP Add Prefix via IPv6 RA 3. EAP over RADIUS (or DIAMETER) 5. Get IP Add Prefix Delegated by LMHA via DHCPv6 8. MIPv6 NEMO BU/BA (binding IP Add Prefix to CAP’s IP add) 7. Autoconfig MS’s Simple IP add Optional: Only for MIPv6 9 MIPv6 BU/Ba to bind MS’s HoA to MS’s CoA (POPA Add) 10 User Packet Flow between MS and Internet via LMHA and CAP 16 Call Flows for Evolved Architecture (2) (for Simple IPv4 MS) MS CAP/BTS DHCP Server LMHA HAAA 1. OTA Signaling 2. EAP over PANA or over cdma2000 Link Layer 3. EAP over RADIUS (or DIAMETER) 4. Key Exchange to derive key for OTA protection 5. DHCPv4 Messages (MS’s IP add) 6. DHCPv4 Messages relayed by CAP (MS’s IP add delegated by LMHA) 7. MIPv4 BU/BA (binding MS’s IP Add to CAP’s IP add) 8 User Packet Flow between MS and Internet via LMHA and CAP 17 Call Flows for Evolved Architecture (3) (for MIP4 MS) MS CAP/BTS (MIPv4 FA) DHCP Server LMHA HA HAAA 1. OTA Signaling 2. EAP over PANA or over cdma2000 Link Layer 3. EAP over RADIUS (or DIAMETER) 4. Key Exchange to derive key for OTA protection 5. DHCPv4 to get FA CoA (x) for MS (Delegated by LMHA) 6. Send FA CoA (x) to MS via MIPv4 RA 7. MIPv4 BU/BA (binding MS’s IP Add (x) to CAP’s IP add) 8. RRQ (NAI, HoA=?, FA CoA=x) 9. RRQ (NAI, HoA=?, FA CoA=x) 10. Assign HoA (y) and Binding HoA (y) to FA CoA (x0 12. RRP (HoA=y, CoA=x) 11. RRP (HoA=y, CoA=x) 13. User Packet Flow between MS and Internet via LMHA and CAP 18 EAP over PANA Using EAP-AKA as Authentication Method Supplicant Authenticator Authentication Server AT (PaC) CAP (PAA/ EP) HAAA 1. Connection and session establishment 2. Client obtains prePANA IP address 3. PANA-PAA-Discover/UDP/IP 4. PANA-Start-Request [EAP-Request/Identity]/UDP/IP 5. PANA-Start-Answer [EAP-Response/Identity (includes user’s NAI)]/UDP/IP If EAP Response Messages are not piggybacked on PANA-Start-Answer Messages and PANA-Auth-Answer messages, then six more messages are required 6. RADIUS Access-Request [EAP-Response/Identity (includes user’s NAI)] 7. HAAA runs AKA algorithms, generates RAND and AUTN 9. PANA-Auth-Request [EAP-Request/AKA-Challenge (AT_RAND, AT_AUTN, AT_MAC)]/UDP/IP 8. RADIUS Access-Challenge [EAP-Request/AKA-Challenge (AT_RAND, AT_AUTN, AT_MAC)] 10. AT runs AKA algorithms, verifies AUTN and MAC, derives RES and session key (TEKs for EAP-AKA packets and MSK for link-layer) 11. PANA-Auth-Answer [EAP-Response/AKA-Challenge (AT_RES, AT_MAC)]/UDP/IP 12. RADIUS Access-Request [EAP-Response/AKA-Challenge (AT_RES, AT_MAC)] 13. HAAA checks the given RES and MAC and finds them to be correct, derives session key (TEKs for EAPAKA packets and MSK for link-layer) 15. PANA-Bind-Request [EAP-Success][MAC]/UDP/IP 16. PANA-Bind-Answer [MAC]/UDP/IP 14. RADIUS Access-Accept [EAP-Success] [MS-MPPE-Recv-Key (MSK)] 19 EAP over cdma2000 Link Layer Using EAP-AKA as Authentication Method Supplicant Authenticator Authentication Server AT CAP HAAA 1. Connection and session establishment 2. EAP-Request/Identity 3. EAP-Response/Identity (includes user’s NAI) 4. RADIUS Access-Request [EAP-Response/Identity (includes user’s NAI)] 5. HAAA runs AKA algorithms, generates RAND and AUTN 7. EAP-Request/AKA-Challenge (AT_RAND, AT_AUTN, AT_MAC) 6. RADIUS Access-Challenge [EAP-Request/AKA-Challenge (AT_RAND, AT_AUTN, AT_MAC)] 8. AT runs AKA algorithms, verifies AUTN and MAC, derives RES and session key (TEKs for EAP-AKA packets and MSK for link-layer) 9. EAP-Response/AKA-Challenge (AT_RES, AT_MAC) 10. RADIUS Access-Request [EAP-Response/AKA-Challenge (AT_RES, AT_MAC)] 11. HAAA checks the given RES and MAC and finds them to be correct, derives session key (TEKs for EAPAKA packets and MSK for link-layer) 13. EAP-Request/AKA-Notification (AT_MAC) 14. EAP-Response/AKA-Notification (AT_MAC) 17. EAP-Success 12. RADIUS Access-Challenge [EAP-Request/AKA-Notification (AT_MAC)] 15. RADIUS Access-Request [EAP-Response/AKA-Notification (AT_MAC)] 16. RADIUS Access-Accept [EAP-Success] [MS-MPPE-Recv-Key (MSK)] 20 Packet Headers (MS/AT Simple IP) MS/AT Forward CAP LMHA Src=MS IP Add Src=CAP IP Add Dest=CN IP Add Dest=LMHA IP Add CN Src=MS IP Add Dest=CN IP Add Src=MS IP Add Dest=CN IP Add Reverse Src=LMHA IP Add Dest=CAP IP Add Src=CN IP Add Dest=MS IP Add Src=CN IP Add Src=CN IP Add Dest=MS IP Add Dest=MS IP Add 21 Packet Headers (MS/AT MIPv6) MS/AT Tunnel Mode (Rev) CAP LMHA Src=MS CoA Src=CAP IP Add Dest=HA IP Add Dest=LMHA IP Add Src=MS HoA Src=MS CoA Dest=CN IP Add Dest=HA IP Add HA CN Src=MS CoA Dest=HA IP Add Src=MS HoA Src=MS HoA Dest=CN IP Add Src=MS HoA Dest=CN IP Add Dest=CN IP Add RR Mode (Rev) Src=CAP IP Add Src=MS CoA Dest=LMHA IP Add Dest=CN IP Add Src=MS CoA ... HAO in Dest Option Header: MS HoA Dest=CN IP Add Src=MS CoA ... Dest=CN IP Add HAO in Dest Option Header: MS HoA ... HAO in Dest Option Header: MS HoA 22 Packet Headers (MS/AT MIPv4) MS/AT CCoA (Rev) CAP LMHA Src=MS CoA Src=CAP IP Add Dest=HA IP Add Dest=LMHA IP Add Src=MS HoA Src=MS CoA Dest=CN IP Add Dest=HA IP Add HA CN Src=MS CoA Dest=HA IP Add Src=MS HoA Src=MS HoA Dest=CN IP Add Src=MS HoA Dest=CN IP Add Dest=CN IP Add FA CoA (with RT, Rev) Src=CAP IP Add Dest=LMHA IP Add Src=MS HoA Src=MS CoA Dest=CN IP Add Dest=HA IP Add Src=MS CoA Dest=HA IP Add Src=MS HoA Src=MS HoA Dest=CN IP Add Src=MS HoA Dest=CN IP Add Dest=CN IP Add FA CoA (For) Src=MS HoA Dest=CN IP Add Src=LMHA IP Add Src=HA IP Add Src=CN IP Add Dest=CAP IP Add Dest=MS CoA Dest=MS HoA Src=HA IP Add Src=CN IP Add Dest=MS CoA Dest=MS HoA Src=CN IP Add Dest=MS HoA 23 Advantages of the Proposal • Simplify the architecture • More effective packet dropping in the CAP – CAP can drop packets prior to applying compression – Take advantage of better and more up-to-date air link information • Better integration between IP header compression algorithms and the CDMA2000 air interface error and timing recovery • Simpler CAP-LMHA interface – Air interface changes do not affect LMHA, so no development impact of air interface enhancements – No tight coupling for signaling such as flow control – LMHA becomes a general purpose router => cost effective • Faster introduction of new services • Easier for interworking between different technologies • Simplify the Handoff procedures 24 Proposed Evolution Path • Begin with PPP in HDLC-like framing currently deployed • Make PDSN and RAN QoS aware to identify QoS flows • Allow RAN to negotiate, configure and implement IP header compression and allow PDSN to send IP traffic without PPP for Auxiliary SI (SO67 Support) We are here (Mid term architecture) • PPP Free in RAN (CAP) and introduce LMHA as a general IP Router – – – – Allow CAP to configure the IP addresses and other IP attributes Allow CAP to perform authentication Move other 3GPP2 specific functions to the CAP CAP Supports both CAP-CAP interface and CAP-AN interface • Support PPP in HDLC-like framing at the CAP for legacy MS • Completely drop support for PPP in HDLC-like framing when there no legacy MS in the network 25 Conclusions • Evolved Architecture will: – Reduce network complexity by reducing the number of interfaces and network entities – Improve performance by reducing the signaling and bearer latency – Speed up deployment of new services/features by leveraging the existing 3GPP2 and IETF protocols and minimizing 3GPP2 specific network entities – Improve bandwidth efficiency and reduce processing overhead by eliminating HDLC-like framing – Enable multiple header compression channels by eliminating the PPP – Enhance Scalability by adopting a distributed architecture 26 Recommendations • The Group Should Start Work on Evolved New Architecture ASAP • The PPP Free Work Item Should Apply to the Evolved New Architecture as well • Furthermore, Any New Features/Capabilities should be able to work with current architecture and New Evolved Architecture 27