15.3 3GPP2 Standard Evolution
| Chapter 13 provides the current view of the network architecture for provisioning of IP services. The evolution of the 3GPP2 cdma2000 network will be focused on three main aspects: enhancements to the cdma2000 radio interface, evolution of the core network at the IP transport level, and service evolution. 15.3.1 Evolution of cdma2000 Radio InterfaceUnlike other evolutionary paths taken by competing GSM and TDMA technologies that have interim 2.5-generation technologies, with cdma2000 (also called 1xRTT), the third-generation (3G) wireless technology has arrived. However, the performance of the "wireless Web" based on currently deployed 2.5-generation technology, such as GPRS, and 3G technology, such as cdma2000, as well as soon to be deployed 3G technology, such as UMTS, is still a far cry from what subscribers can receive currently over the "wired Web." Wireless industry organizations are working fervently to develop evolutionary paths toward closing of this performance gap. The marriage of mobile IP with cdma2000 has facilitated a true "always-on" mobile Internet service delivering user mobility anytime , anywhere . However, significant challenges remain before the wireless Internet performance comes close to that of the wired Web. One such challenge is the coexistence of circuit switched voice and packet switched data, resulting in a suboptimal over-the-air access performance for packet data services. The other challenge is seamless merger of an IP-based packet core network into an IP-based access network to create an all-IP network (core and access). In this section we will first briefly review the access technology evolution followed by a review of the underlying network evolution plans. 15.3.2 cdma2000 Access Network EvolutionThe evolution of cdma2000 access technology beyond 1xRTT is called 1xEV (Figure 15-2). It is geared toward being backward compatible with current CDMA technologies and forward compatible with each evolution step. 1xEV consists of two distinct but compatible standards using a standard 1.25-MHz carrier: Figure 15-2. CDMA evolution paths.
1xEV-DO is a companion standard to cdma2000 that enables higher data rates by decoupling voice and data in access network by mandating a separate carrier for packet data. It is designed to be an overlay technology and very suitable for hotspot deployment. However, it is backward compatible and allows hand-offs to a 1xRTT carrier if simultaneous voice and data services are needed. By allocating a separate carrier for data, it is possible to deliver peak rates of up to 2.4 Mbps. 1xEV-DV is the next step in the evolution of the cdma2000 technology and designed to improve system capacity and performance for mixed voice and data traffic. The first release of the standard is currently under review as cdma2000 Release C and was approved in 2002. New concepts, such as fast cell switching, to facilitate support of real-time applications over the packet data channel are being considered . Increased system data capacity over 1xEV-DO is provided by addition of new packet data states, such as a virtual active state. Allowing independent target FERs for data streams provides enhanced support for QoS. The framework for an all-IP network is being established via IP multicast/broadcast support. It is prudent to note that some key features could be delayed to the next release of the standard. 15.3.3 Evolution of cdma2000 Access and Core Networks to All-IPIn North America many network operators are keen on migrating to an all-IP network in which the core as well as the access network is IP based. The foundation of such a migration is the existing TIA/EIA-41, cdma2000, and IOS standards with support of both circuit and packet switched technologies. 3GPP2 and its organizational partners have recommended a phased approach to achieving the goal of an all-IP network. The phases can either be sequentially evolved or can be a "mix and match" evolution. These proposals have been defined at a high level, and standards activity is in progress to define details. Figures 15-3 and 15-4 depict the current paths of evolving to an all-IP network. Figure 15-3. Sequential phase evolution. Figure 15-4. "Mix and match" phase evolution. In Phase 0 the legacy core network is defined by TIA/EIA-41, which defines the network functional components , interfaces, and protocols. The packet core is defined by P.R0001, which describes the overall packet architecture with simple and mobile IP as access methods . The access and the radio networks are defined by IOS version 4.x1 and IS-2000. IOS version 4.x1 defines the interface between the circuit switched MAC and BS as well as the packet control function (PCF) and the PDSN, while the IS2000 family of standards defines the air interface. Phase 1 is the first step toward the evolution into an all-IP network. The main thrust of this phase is the separation of the access and core networks. In the core networks the focus is toward carrying the TIA/EIA-41 operations over IP. In the access networks, signaling links wherever possible will be carried over IP while the bearer transport will continue to be based on IOS. The radio interface will remain based on the IS-2000 family of standards. Phase 2 introduces an IP multimedia domain, allowing VoIP. The core network will transport both signaling and bearer streams over IP and support IP multimedia services. Legacy equipment will continue to use legacy transport mechanisms. On the access side, the separation of the signaling and bearer streams is mandated with the signaling links carried over IP transport. The radio interface would have to be evolved to support end-to-end IP multimedia call control (such as SIP) while at the same time providing support to legacy equipment. Phase 3 is the culmination of the process of evolving to an all-IP network. The significant achievement of this phase is the extension of IP over the radio interface. The core network will throw off the shackles of legacy non-IP support requirements. IP multimedia will be the network technology with support for enhanced IP multimedia services. The access network too will complete the move to an IP-based transport with support for enhanced service and QoS. The radio interface will move to an IP transport for both signaling and bearer stream. 15.3.4 Evolution of cdma2000 Core Network: The All-IP NAMThe cdma2000 all-IP network architecture model (NAM) represents the model of the target architecture for the evolution of the cdma2000 networks toward an architecture based completely on IP protocols. Evolution of the cdma2000 network has already started in standardization, with small steps taken to improve the functionality of the current cdma2000 network toward the concepts defined in the all-IP NAM. In this section we describe the main features of the all-IP NAM, in order to provide the reader with an understanding of the direction in the evolution of cdma2000 and of the major evolutionary steps. The all-IP NAM architecture is based on three major protocols:
In the following section, the details of the architecture are described. ARCHITECTURE MODELA set of architectural principles is used in the all-IP NAM architecture. In particular, the architecture derives from the following objectives:
Figure 15-5 provides a simplified representation of the cdma2000 all-IP NAM. In the diagram, only the aspects related to IP and multimedia services are described, whereas aspects related to support of legacy terminals are not represented. Figure 15-5. All-IP NAM architecture. To better describe the cdma2000 all-IP NAM, the following sections describe the principal functionality in the architecture. ACCESS FUNCTIONALITYAccess functionality provides control and management of access to network resources (e.g., radio bearers, IP bearers ), as shown in Figure 15-6. The purpose of access functionality is to hide access-specific aspects to other functionalities. The access functionality contains L2 functions specific to an access technology (e.g., access technology specific authentication and authorization); it receives QoS requests through the network functionality and translates these requests into access-specific QoS requests. The access network, the access gateway (AGW), and the AAA (authentication, authorization, and accounting) support access functionality. Figure 15-6. Access functionality. The access network (AN) in cdma200 all-IP NAM performs mobility management functions for registering, authorizing, authenticating, and paging IP-based terminals. The AN supports handoff within an AN and between ANs of the same technology. AN can be enhanced to support handoffs between ANs of different technologies. The cdma2000 AN contains the base station transceiver system (BTS), the base station controller (BSC), the mobility manager (MM), and the packet control function (PCF). In particular, the mobility manager is responsible for handling registration messages from the MS, for establishing of logical bearers through the IP multimedia domain core network, for communicating with the AAA for access network authentication, for authorizing radio link access (multimedia registration, multimedia page response, interradio access network handoff), and for accounting. The packet control function (PCF) is responsible for establishing, maintaining, and terminating Layer 2 connections to the AGW, interacting with PDSN to support dormant handoff , maintaining knowledge of radio resource status (e.g., active, dormant), buffering packets arriving from the AGW when radio resources are not in place or are insufficient to support the flow from the AGW, relaying packets to and from the AGW, and collecting and sending radio link (air interface)-related accounting information to the AGW. PCF behaves very similarly to the PCF in current cdma2000 network. The AGW supports both the multimedia and legacy MS domains and provides the core network with access to the resources of the access network (e.g., radio bearers) by presenting a common interface to the specific capabilities, configurations, and resources of the different access network technologies. The AGW supports inter-access gateway handoffs, provides foreign agent functionality (for Mobile IPv4) and/or attendant functionality (for mobile IPv6), and acts as a peer function for link layer termination of the IP traffic between the MN and the network (e.g., PPP). AGW provides the interface to access network functions such as the PCF function, provides access to network-level registration and authentication for the mobile station (e.g., mobile IP registration), and communicates with the AAA for user authentication, access authorization to the core network, and accounting purposes. AGW supports link-layer handoffs between homogeneous access networks supported by the same AGW and may be extended to support link-layer handoffs among access networks of differing technologies when the access networks are supported by the same access gateway. AGW communicates with the core quality of service manager (CQM) for management of core QoS resources, intercepts and processes QoS requests from the mobile station, provides policy decision information to the access network for enforcement within the access network, and enforces policy decisions for authorized services by policing traffic to and from mobile stations as per QoS profile. The QoS allocation requests from the MN are forwarded by the AGW to the CQM for authorization. The AAA provides IP-based authentication, authorization, and accounting. The AAA maintains security associations with peer AAA entities to support intra- and/or inter-administrative domain AAA functions. AAA provides authentication of terminal devices and subscribers by verifying an entity identity for network access, QoS request, multimedia resource request, or service request, and by providing authentication and/or encryption keys to establish dynamic security associations between network entities. AAA provides authorization of requests for services and/or bandwidth and has access to the policy repository, directory services, subscriber profiles, and device register. AAA provides the authorization decision for services, and bandwidth in terms of whether a user or device is authorized for a particular service, and to what levels a given service may be used. An entity that requests authorization from the AAA entity may receive a set of information that allows it to make further decisions concerning services and/or bandwidth without a new request to the AAA entity (i.e., the requesting entity may be able to cache authorization information from the AAA entity). Cached information may have an assigned expiration time. The AAA entity may send unsolicited messages containing policy decisions to appropriate entities. AAA also performs accounting functionality by gathering data concerning the services, QoS, and multimedia resources requested and used by individual subscribers. Currently, the all-IP NAM utilizes Radius as the AAA protocol and will soon adopt Diameter Mobile IPv4 and Diameter NASREQ application. The service authorization request may be sent to the AAA by access gateway via the CQM (i.e., in case of a request for QoS authorization), or by the session control manager once it has determined the specific service to be provided in the case of a multimedia session. AAA may provide authorization by providing a set of information that allows other entities to make further decisions concerning services and/or bandwidth without a new request to the AAA entity (i.e., the requesting entity may be able to cache authorization information from the AAA entity). AAA may also send unsolicited messages containing policy decisions to appropriate entities. AAA also performs accounting functionality by gathering data concerning the services, QoS, and multimedia resources requested and used by individual subscribers. NETWORK FUNCTIONALITYThe purpose of network functionality is to provide end-to-end IP connectivity between the mobile station (including devices connected to it) and other IP entities in the architecture (Figure 15-7). The access functionality appears to the network functionality as a link layer. The network functionality controls the access functionality through the access gateway-core quality of service manager and protocols/mechanisms such as DiffServ and RSVP. The network functionality is provided through the core QoS manager (CQM), the mobile IP home agent (HA), the AAA, and the subscription quality of service manager (SQM). Figure 15-7. Network functionality. The CQM provides management of core network QoS resources within its own core network necessary to support services to network users. It communicates with the access gateway to provide authorization of resource allocations . The CQM makes policy decisions with regard to use of core network QoS resources within its own network, including consideration of service-level agreements. QoS policy information for network resource utilization may be forwarded to and cached by the CQM. CQM manages resources of the border router and access gateway that handle traffic between low-speed networks (e.g., radio access network) and the high-speed backbone core network. The mobile IP HA provides two major functions, according to mobile IP:
The HA accepts registration requests using the mobile IP protocol and uses the information in those requests to update internal information about the current point of attachment of the user (i.e., the current IP address to be used to transmit and receive IP packets to and from that user). The HA interacts with the AAA to authorize mobile IP registration requests from mobile nodes. The HA also interacts with the access gateway to receive subsequent mobile IP registration requests. The HA may interact with several network entities in performing its work of forwarding IP packets to the current point of attachment of the user. The SQM provides management of QoS resources on a per subscription basis for users subscribed to the home network. AAA interrogates SQM to authorization allocation of resource for a given subscriber based on policy rules defined by the user subscription and current allocations already made with respect to that subscription. SQM keeps track of QoS allocated in the core network on a subscription base. MULTIMEDIA SERVICE APPLICATION CONTROL FUNCTIONALITYThe multimedia service application control functionality implements the call control and services/applications that provide the multimedia services. The multimedia service application control functionality is access independent and represents an abstraction above the network plane. The network functionality provides end-to-end IP connectivity to the multimedia control functionality by ensuring that IP packets are routed correctly and the necessary QoS is available, so that these entities may communicate directly. For example, a SIP client in the MN may communicate with SIP servers (SCMs) in the network, assuming the SIP client has obtained knowledge about the IP address to use. The multimedia service application control functionality is supported by the multimedia client and/or applications in the MN, the network capability gateway (NCGW), the session control manager (SCM), the AAA, and the service applications. Figure 15-8 depicts the multimedia service control functionality. Figure 15-8. Multimedia service control functionality. The service applications provide value-added network-based services for wireless subscribers. These services may be accessed via the network capability gateway or accessed directly from the user's MN. Service applications may reside inside or outside of the operator's network (e.g., operator applications or Internet applications). Service applications may access network resources (e.g., session control manager, position server) for functionality needed during service logic execution. These service applications use standard APIs (e.g., open service architecture [OSA] API) supported by the NCGW. The APIs allow access to service applications during SIP sessions and allow service applications to access resources in the network (e.g., position server, SCM, AAA) as required for service logic execution. Service applications that reside outside of the wireless network operator network may also access private databases, SIP or http servers, and other functionality on equipment provided by a third party. Service applications (e.g., hosted on equipment in the Internet or a private network) may also not use network resources other than for bearer management. The NCGW provides access to network resources needed during service application execution. The interface toward the service application uses API interfaces such as Open Service Architecture (OSA). The interfaces toward other network entities use the relevant protocols. The NCGW, in conjunction with AAA and the position server (for position-related requests), is responsible for guaranteeing proper authorization for access to resources. The SCM establishes, monitors , manages, and releases multimedia sessions and manages the user's service interactions. The SCM is responsible for managing the allocation of required resources such as announcement servers, and multiparty bridges, for maintaining knowledge of session states and user's service precedence, for providing session state information to the authorization function as needed, for supporting the decision-making responsibilities of the authorization function while allowing the authorization function to remain stateless relative to the subscriber's open sessions, and for performing session processing tasks (e.g., network selection) required for session completion. As can be seen in Figure 15-8, the functionality of the SCM in a roaming situation is split between the visited network and the home network. The SCM function in the home network is responsible for multimedia session control and IP service control and may be further divided into an interrogating-session control manager and a serving-session control manager for load sharing and/or hiding of the internal network structure to other networks, or for allocation of a serving SCM close to the mobile station. The interrogating SCM would in such a case be the entry point to the network, responsible for locating the serving SCM serving the user, while the serving SCM is the entity actually keeping the session state. The SCM function in the visited network proxies requests from the mobile station to an SCM in the home network and returns responses from the home network (proxy session control manager); it allocates local resources and provides access to local services (local session control manager); and it supports emergency calls (emergency-session control manager). The proxy SCM is adopted only in case of SIP sessions, as seen in Figure 15-8. SCM communicates with AAA for two reasons: to support authorization/authentication for users, and to establish secure communications with other SCM entities (e.g., through the passing of addresses and security tokens). Through the AAA the SCM uses information from various databases (e.g., subscriber profile) and invocation of various services applications to determine the exact service being requested. The media gateway (MGW) is responsible for converting the media, which is typically voice, between the CDMA network and the PSTN. For calls originating or terminating in the PSTN, the MGW plays the role of media converter. The media gateway control function (MGCF) is responsible for translating the signaling between SIP an ISUP, as well as managing the assignment of trunks and circuits on the PSTN interface of the MGW. The MGCF interfaces to PSTN signaling on one side which uses ISUP and the SCM on the other side (CDMA network) which uses SIP as the signaling protocol for session setup. The MGCF interface to the session control manager is for communicating session control information (e.g., via a protocol like SIP). 15.3.5 Future Evolution of cdma2000 Core NetworkTwo main threads will characterize the evolution of the cdma2000 network to an all-IP NAM and the future evolution of the all-IP NAM:
When operators propose new service requirements, the all-IP NAM will be modified in terms of network functionalities and protocols to satisfy such requirements. Evolution of service provisioning is described in following sections. The main evolution regarding the IP transport infrastructure will be the adoption of mobile IPv6. Adopting mobile IPv6 in the all-IP NAM implies a set of changes in terms of protocols and functionalities in the network. In fact, with mobile IPv4, either Radius or Diameter MIPv4 are used in the network to provide user authentication, authorization, accounting, and support of IP mobility. The mobile IPv4 network model identifies the foreign agent function and defines the mechanisms for a mobile node to register with the network. However, the network model for mobile IPv6 does not foresee a foreign agent and does not define any registration protocol between the mobile node and the network. The mobile IPv6 network model uses instead an attendant functionality in the default router: In the All-IP NAM, the attendant is located in the AGW. The attendant should have a function similar to the foreign agent, but the mobile IPv6 signaling is not directed to the attendant. In fact, whereas in mobile IPv4 registration request messages allow the mobile node to register with the network, obtain authorization to access network resources, and indicate to the home agent the current point of attachment, mobile IPv6 defines only a way for the MN to communicate to the home agent and correspondent nodes the current point of attachment to the network in terms of a care-of address through binding update messages. Therefore, a registration/authorization protocol between the mobile node and the network (in this case, the attendant in the AGW) is needed in order to allow mobile nodes to obtain authorization to gain IP connectivity and access network resources. In order to adopt mobile IPv6 in the all-IP NAM, the following mobile IPv6-related protocols are needed:
Two main paths can be identified for the evolution of all-IP NAM from mobile IPv4 to mobile IPv6:
In the second scenario, IPv6 is provided to mobile nodes as a service over mobile IPv4, therefore enabling mobility of IPv6 nodes. This is similar to the support of IPv6 in UMTS, where IPv6 is a service provided to the user and mobility is supported through UMTS-specific mobility mechanisms. The drivers behind the adoption of this additional steps in the evolution of the 3GPP2 network architecture will be the ability to support IPv6 mobility with minimal changes to the network (i.e., addition of NATs, network address translators) while allowing operators deploying a mobile IPv4 All-IP NAM to reuse completely the investment. Such a scenario becomes plausible if the growth of data services will not justify large investments in network equipments. Operators may see the direct adoption of mobile IPv6 as a dangerous and costly disruption, since it will require operators already deploying a mobile IPv4 all-IP NAM network to modify network elements in order to support mobile IPv6 and the related protocols. Therefore, the direct evolution to mobile IPv6 may be problematic from a political point of view. However, the evolution to mobile IPv6 will be justified in case of significant growth of data services, since the adoption of IPv6 and mobile IPv6 allows operators to deploy a more efficient network architecture. In conclusion, the steps in the evolution of cdma2000 that will actually take place in the next years are dependent mainly on the market thrust toward data and multimedia IP services.  |
EAN: 2147483647
Pages: 164