Transcript X31-20050926-029 R2 QCOM 3GPP2 Packet Data Network

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