SC-AllIP A- PathsTwdsAllIP_A Ericsson1 All-IP Evolution Paths Towards an All-IP network Ericsson

SC-AllIP A- PathsTwdsAllIP_A Ericsson2 Presentation plan  1- Evolution paths, starting from current standards  step 0: Current situation with PS (TSB-115, 3GPP2 PS0001)  step 1: Introduction of IP technology in Radio and CS network; PS domain independence  step 2: The emerging all-IP solution  step 3: The all-IP target model  2- Access Control Server  3- Relation to other technologies & standards  4- Conclusion

SC-AllIP A- PathsTwdsAllIP_A Ericsson3 1- Evolution paths

SC-AllIP A- PathsTwdsAllIP_A Ericsson4 Evolution paths  Recognizing that already existing service providers :  inherit networks various in diverse conditions  operate networks under diverse traffic & commercial conditions  Recognizing that some service providers :  do not need/want to use legacy networks  We propose Voice and Packet migration paths  that can evolve at various speeds, function of the service providers needs

SC-AllIP A- PathsTwdsAllIP_A Ericsson5 Evolution path, step 0 Current situation for PS

SC-AllIP A- PathsTwdsAllIP_A Ericsson6 Evolution path, step 0 Current situation for PS  Current cdma2000 architecture  based on TIA TSB-115 (former PN-4286), and 3GPP2 PS0001 (former PN-4732)  embrace Mobile IP with an AAA bundling.  MSC “imposes” tight connection between Circuit and Packet Switched domains… … justification: maximum reuse of existing functionality & faster availability … setting up &maintaining packet data session, CS/PS coordination  Ericsson’s vision:  legacy voice services should evolve towards IP transport  CS and PS should be made separately “evolvable”, at different speed  PS should evolve from current architecture

SC-AllIP A- PathsTwdsAllIP_A Ericsson7 Evolution path, step 1a Transition to IP transport in Radio network

SC-AllIP A- PathsTwdsAllIP_A Ericsson8 Evolution path, step 1a Transition to IP transport in Radio network  IP-based transport protocol introduced in the transport and signaling legacy network (BS).  Signaling will still be access specific, whilst carried over an IP protocol.  Payload protocols will most likely be evolved from current IETF protocols, taking into account wireless requirements.  Neither the MS nor the core network sees any change in interfaces.

SC-AllIP A- PathsTwdsAllIP_A Ericsson9 Evolution path, step 1b Transition to IP transport in CS network

SC-AllIP A- PathsTwdsAllIP_A Ericsson10 Evolution path, step 1b Transition to IP transport in CS network  IP-based transport protocols are introduced in the legacy core network (MSC).  Specifically:  carry the signaling over IP instead of SS7 (ANSI41 over STCP over IP).  voice could be carried over IP instead of PCM structured trunks.  Protocols used in the CS network should to largest possible extent be based on open IETF based protocols

SC-AllIP A- PathsTwdsAllIP_A Ericsson11 Evolution path, step 1c Emerging of PS domain independence

SC-AllIP A- PathsTwdsAllIP_A Ericsson12 Evolution path, step 1c Emerging of PS domain independence  3GPP: SGSN performs GPRS related tasks (i.e., packet session control, mobility management)  step 0 cdma2000: handled by the MSC.  Consequence: difficult to change session control & mobility management as it directly impacts: A interface, MSC, and ANSI-41.  We propose to surgically extract the PS related functionalities, currently hosted in the MSC, and move them to an Access Control Server (ACS)  NB: ACS will not be involved in switching/routing of user packet data.

SC-AllIP A- PathsTwdsAllIP_A Ericsson13 Evolution path, step 2 The emerging all-IP solution

SC-AllIP A- PathsTwdsAllIP_A Ericsson14 Evolution path, step 2 The emerging all-IP solution  Multimedia call models are provided in the packet core network (e.g. CSCF).  The network:  is not only a bearer network,  it is also a Multimedia service provider network,  it is able to provide multimedia services to users.  In this section we identify potential sub-steps.

SC-AllIP A- PathsTwdsAllIP_A Ericsson15 Evolution path, step 2 The emerging all-IP solution  Step 2a: Build a multimedia call model into the packet data core network. This implies building the infrastructure necessary to interface to the legacy systems (signaling and media gateways).  Step 2b: Roaming with legacy network  Step 2c: Modified service (legacy and new services ) architecture. Need to define API for service triggers and service capability. Needed to maintain legacy service continuity and to facilitate the introduction of entirely new services in the IP domain.

SC-AllIP A- PathsTwdsAllIP_A Ericsson16 Evolution path, step 2 Intermediate Reference Model

SC-AllIP A- PathsTwdsAllIP_A Ericsson17 Evolution path, step 2 Intermediate Reference Model  Legacy terminal support (even though implemented using IP transport) is not the scope of the ALL-IP target model.  It is an intermediate step towards an All-IP model.  The above figure stresses the importance of supporting legacy service during the migration to the “target model”, which is indicated in step 3 below.

SC-AllIP A- PathsTwdsAllIP_A Ericsson18 Evolution path, step 3 The All-IP target Model

SC-AllIP A- PathsTwdsAllIP_A Ericsson19 Evolution path, step 3 The All-IP target Model  When service provider feels it is appropriate to “abandon” CS, he can adopt the all-IP target model.  This model results of 3GPP option 1 evolution, taking into account cdma2000 “culture”:  support of 2G air interface  AAA  Mobile IP

SC-AllIP A- PathsTwdsAllIP_A Ericsson20 2- Access Control Server

SC-AllIP A- PathsTwdsAllIP_A Ericsson21 Access Control Server  MSC integrates all CS and PS control functionalities  Basic functionalities:  make the PS domain independent of the MSC.  an IP entity, which comprise the functionality to set up and maintaining packet data sessions (e.g. packet data registration, connection handling)  connect to the evolved HLR via the PLMN IP network. (e.g., PLMN IP Network: general: any suitable IP network. Specifics: could be an inter/intra PLMN IP network).

SC-AllIP A- PathsTwdsAllIP_A Ericsson22 Access Control Server, step 0 today

SC-AllIP A- PathsTwdsAllIP_A Ericsson23 Access Control Server, step 0 today  MSC integrates all CS and PS control functionalities

SC-AllIP A- PathsTwdsAllIP_A Ericsson24 Access Control Server, step 1c Packet control functions extracted from the MSC

SC-AllIP A- PathsTwdsAllIP_A Ericsson25 Access Control Server, step 1c Packet control functions extracted from the MSC  ACS: rudimental packet control functionality  RAN interface is IP based  separate bearer control function for packet data services  RN function altered to address the packet bearer function, when packet service is requested  HLR+:  HLR with packet data user profiles  keeps a packet data subscriber profile, including QoS profile.  Interfaces with the ACS through an open IP-based protocol.

SC-AllIP A- PathsTwdsAllIP_A Ericsson26 Access Control Server, step 2 Increased ACS functionalities

SC-AllIP A- PathsTwdsAllIP_A Ericsson27 Access Control Server, step 2 Increased ACS functionalities  ACS:  handles more packet related functions, so that MSC is not anymore impacted by packet related changes

SC-AllIP A- PathsTwdsAllIP_A Ericsson28 Access Control Server, step 3 ACS: cut MSC umbilical cord

SC-AllIP A- PathsTwdsAllIP_A Ericsson29 Access Control Server, step 3 ACS: cut MSC umbilical cord  ACS: cut umbilical cord with MSC  PAC: cut umbilical cord with HLR

SC-AllIP A- PathsTwdsAllIP_A Ericsson30 Access Control Server, step 1c Packet control fnct. extracted from the MSC, signaling considerations

SC-AllIP A- PathsTwdsAllIP_A Ericsson31 Access Control Server, step 1c Packet ctrl. fnct. extracted from the MSC, signaling considerations  a) New message. Format: Common Parameters [Voice Specific] [Packet specific].  b) ANSI-41 REGNOT “built” from the Common Parameters & Voice Specific parts. Note: Unchanged Authentication towards MSC/VLR/HLR  c) New message. Format: Common Parameters and the Packet specific parameters. Sent on an IP-based interface. Authentication: with the HLR+. ACS gets a profile back (info about QoS class of the user etc.). This procedure could be done in parallel to b)

SC-AllIP A- PathsTwdsAllIP_A Ericsson32 Access Control Server, step 1c Packet ctrl. fnct. extracted from the MSC, packet session set up

SC-AllIP A- PathsTwdsAllIP_A Ericsson33 Access Control Server, step 1c Packet ctrl. fnct. extracted from the MSC, packet session set up  a) New message. Packet Session Request. Requests packet service. Improved Service Option negotiation. Intent: better support upcoming multimedia services. New radio bearers may be dynamically negotiated.  b) ACS authorizes the request. Used: user’s packet access profile. Stores info about the requested (and actual) QoS profile for the call.  c) Traffic channel established.  d) MT confirms: traffic channel is available.  e) MSC/VLR is notified that the packet service is active (on traffic channel)  f) After an R-P connection has been set up, PPP (or future protocol “Simple HDLC”) connection is negotiated, and Mobile IP Registration is performed

SC-AllIP A- PathsTwdsAllIP_A Ericsson34 Access Control Server, step 1c Packet control functions extracted from the MSC …reminder...

SC-AllIP A- PathsTwdsAllIP_A Ericsson35 3- Relation to other technologies & standards

SC-AllIP A- PathsTwdsAllIP_A Ericsson36 Relation to other technologies & standards

SC-AllIP A- PathsTwdsAllIP_A Ericsson37 Relation to other technologies & standards  We acknowledge that 3GPP and 3GPP2 are inherited from different basic networks.  We see a merit in identifying common logical entities between UMTS & cdma2000  Intent: consider reuse, while leaving the radio access intact  Respecting their uniqueness, we propose to identify commonalties between the two evolution paths.

SC-AllIP A- PathsTwdsAllIP_A Ericsson38 4- Conclusion

SC-AllIP A- PathsTwdsAllIP_A Ericsson39 Conclusion step-through-at-your-pace migration path  We proposed a migration path from today’s cdma2000 architecture to an advanced all-IP solution.  This path allows migration of circuit switched domain and packet switched domain to progress at different speeds.  Service providers can select the most appropriate speed, function of their business plans and local traffic contingencies.

SC-AllIP A- PathsTwdsAllIP_A Ericsson40 Conclusion step-through-at-your-pace migration path

SC-AllIP A- PathsTwdsAllIP_A Ericsson41 Conclusion importance of supporting legacy in an evolutionary way  We also emphasized the importance of supporting legacy services during the migration.  The goal is that the steps themselves are evolutionary and a carrier can decide to stop the evolution of its network at any step.

SC-AllIP A- PathsTwdsAllIP_A Ericsson42 Conclusion Access Control Server: helps migration  We propose a new logical entity: the Access Control Server.  ACS:  acts in the PS domain  will simplify the migration towards All-IP, by decoupling control functionalities from the MSC (legacy, 2G)

SC-AllIP A- PathsTwdsAllIP_A Ericsson43 Conclusion reuse can be good  We should try to identify as much commonalties as possible in regards of:  protocol reuse,  IETF,  3GPP

SC-AllIP A- PathsTwdsAllIP_A Ericsson44 Conclusion reuse can be good

SC-AllIP A- PathsTwdsAllIP_A Ericsson45 Conclusion  step-through-at-your-pace migration path  importance of supporting legacy in an evolutionary way  Access Control Server: helps migration  reuse can be good