10.4 Core Network Procedures
10.4 Core Network ProceduresThe packet network for cdma2000 uses IETF-defined procedures for mobility, security, and session management. Some of these procedures are enhanced for the packet network. This section describes these procedures, along with the enhancements. 10.4.1 R-P Interface (A10/A11 Interface)The R-P interface is an extension of the mobile IP version 4 to allow MM between the RN and the PDSN. More specifically , it is the interface between the PCF and the PDSN. The R-P interface is standardized by ITU documentation in the IOS specifications. The R-P interface is also referred to as A10/A11 interface in the specifications. MOBILE IP ENHANCEMENTS FOR A10/A11 (R-P)For the A11 interface, base mobile IP is extended to accommodate specific changes for the cellular access. A mechanism is added to enable the generic routing encapsulation (GRE) and reverse tunneling during A11 registration. GRE and reverse tunneling are used to tunnel user plane packets for an MS between the PCF and PDSN. Two new messages, registration update and registration acknowledge , are added to support the R-P session disconnection during handover. The base mobile IP depends on lifetime timer expiry for releasing a registered session. For cellular, this would increase the blocking time for the radio resource allocated at the source RN. Therefore, explicit messages are defined to expedite the release of the resources at the source RN. Addressing is also handled differently in the A11 messages compared to the base mobile IP. In the A11-registration request message, the IP source address in the IP header and the CoA field are set to the IP address of the PCF. The IP destination address and the HA address field are set to the address of the PDSN designated for the call. The home address field is set to zeros. Instead of home address, the PCF sets a session-specific extension to identify a session. This extension uniquely identifies a session between an MS and its serving PDSN. This extension is mandatory in all the A11 messages and is shown in Figure 10-6. Figure 10-6. Session-specific extension. The following are the fields in the SSE:
GENERIC ROUTING ENCAPSULATION (GRE) FOR A10GRE framing is used for tunneling the user plane between the PCF and PDSN. GRE is a simple tunneling protocol and is carried over IP, which in turn is carried over the A10 bearer connections. The PCF and the PDSN IP addresses are used in the source and destination address fields of the IP header used with a GRE packet. For identifying an A10 bearer connection, the PSI (packet session ID) is used and is inserted as the key field in the GRE header. The PCF informs the PDSN about the PSI by inserting it in the A11-registration request message. The PSI is only unique in a PCF; therefore, the MN session reference ID (MN-SRID) is used together with the mobile identifier (IMSI) over the A10/A11 connection to identify a packet session for a specific mobile across PCFs and PDSNs. 10.4.2 A8/A9 Interface and A1 Interface InteractionsThe A8/A9 interface links the packet session management on PCF/PDSN with the MSC call control (CC) procedures and the BSC RRM. The standards have specified an open interface between the BSC and PCF called A8/A9 interface. However, the vendors have not implemented PCF as a separate NE. The implementation of the A8/A9 interface varies from one vendor to another. In this section the standardized A8/A9 interface is assumed. An interaction between A8/A9 interface and the CC messages occurs during the setup for a packet data session. The MS initiates a packet data session by exchanging the same set of CC messages toward MSC as it would exchange for a voice call, but with the data service request. During the session establishment, the MSC recognizes that the service request is for data and sends an assignment request for data service to BSS without allocating a circuit. The BSC at this point initiates A8/A9 connection setup. Another interaction between A8/A9 and CC messages occurs for the dormant state. An MS goes into the dormant state when it is not exchanging data with the network for a certain time. In the dormant state, only RR and CC connections are released at the BSC and MSC to conserve the most needed radio resources. The A10/A11 and PPP connections are maintained for the MS. The BSC uses A9 signaling to notify the PCF, which keeps the A10/A11 connection and releases the A8/A9 connection. At the same time the BSC also notifies the MSC to release the call connections. An MS can reactivate the dormant state by performing a call establishment procedure with the BSC and MSC. The resulting A8/A9 connection reconnects to the existing A10/A11 connection. The dormant state can also be reactivated by the network when the data packets arrive for a dormant MS at the PCF. The PCF starts buffering the packets and initiates a service request toward the BSC containing the identity of the MS that needs to be paged. The BSC forwards the request toward the MSC. The MSC pages the MS and proceeds with the rest of the CC procedure as in a mobile- terminated call. Once the call connection is established, the PCF starts delivering buffered and oncoming packets to the MS. 10.4.3 Mobility Management (MM)The IP services use both the PS network MM procedures as well as the CS network MM procedures. The PS network MM procedures are A11 registration, mobile IP registration, handovers, and security. The CS network MM procedures are location update, handovers, and security. Some PS network MM procedures need CS network MM procedures for complete execution. For example, the PS hard handover signaling interacts with the CS hard handover for complete execution. Other PS network MM procedures execute independent of the CS network MM procedures. For example, the PS user authentication procedure (CHAP/PAP) is executed independent of the CS user authentication procedure. In this section, only the different types of the PS network handovers are described. The PS network registrations and security were explained in Sections 10.2.2 and 10.4.1. DORMANT HANDOVERAn MS stays dormant by releasing the radio resources but keeping the A10 and PPP connections. When the MS moves under a different BSC, which is attached to a new PCF, the dormant handover takes place to move the A10 connection to the new PCF. An MS in the dormant state monitors the packet zone identifier (PZID), system identifier (SID), and network identifier (NID). When any of these identifiers changes, the MS sends a request for the dormant handover. The MS sends the old PZID, SID, or NID to the target PCF via BSC. The target PCF establishes an A10 connection with the PDSN. The target PCF sends the source and the target PCF information to the serving PDSN. The serving PDSN uses this information to determine whether the PDSN is changed or not. If the PDSN is changed, it performs mobile IP registration. If the new PCF is attached to a different PDSN, the target PDSN sends registration update to the source PCF to release the resources at the source PCF. HARD HANDOVERHard handover is initiated by the source BSC during the active state of a data session. The packet data hard handover involves both CS and PS network handover. The handover request is first communicated to the target BSC through the MSC as in the CS network handover. The target BSC after realizing that the request is for a data session initiates A8/A9 connection setup with the target PCF. After the setup of A8/A9 connection, it acknowledges the handover request to the source BSC as in the CS network handover. When the MS acquires the target BSC, it sends a notification to the target PCF. This notification triggers PCF to establish an A10 connection with the PDSN. PDSN functions differently for intra-PDSN and inter-PDSN hard handovers. In case of intra-PDSN hard handover, PDSN only releases the A10 connection with the source PCF. In case of inter-PDSN hard handover, the source PDSN has to wait for the expiry of the registration timer before it can release the A10 connection. This is because of the absence of any inter-PDSN interface. Inter-PDSN hard handover also requires establishment of the PPP link between the target PDSN and the MS, and the mobile IP registration of the new PDSN with the HA. The MS does not start getting data from the network until the completion of the mobile IP registration and the establishment of the PPP link. This makes the overall procedure very slow and may result in considerable loss of data packets. The hard handover mechanism by itself can't recover the loss of data packets. It is up to the application (e.g., TCP) to recover from this loss. FAST HANDOVERHard handover is slow and results in packet loss; this makes it unsuitable for delay sensitive or real-time traffic. To solve these problems of hard handover, a fast handover procedure was developed by 3GPP2. This fast handover procedure is different from the fast handover process developed by the Mobile IPWG in the IETF. The fast handover is achieved by anchoring the call to the serving PDSN. Layer 2 sideways tunnels, called the PP interface, are created between the PDSNs for the bidirectional transport of bearer data (PPP frames ) between the target PDSN and the serving PDSN. Effectively, the MS remains connected to the serving PDSN during the active state of the session. PPP establishment at the target PDSN and mobile IP registration are performed only when the MS moves to the dormant state of the call. The PP interface supports both the signaling and bearer channels. The PP signaling channel provides capabilities for the bearer channel control. The sideways tunnel is terminated when the MS registers at the target PDSN during the dormant state. The target PDSN now becomes the serving PDSN for subsequent activations of the packet session. The future enhancements of fast handover procedures are planned to enable mobile IP registrations to occur during the active state of the call. 10.4.4 QoS in the CNThe standards have specified QoS in the core network based on differentiated services. But the reality is that QoS is not supported in the core network. This section gives an overview of QoS from the specifications. QoS is provisioned in the home AAA server as a user profile parameter and is called 3GPP2 differentiated service class options. It is sent to the PDSN in the RADIUS access accept message. The MS can optionally support differentiated services or may rely on the network to perform packet marking. The network may overwrite the marking of the packet by the MS. The 3GPP2 differentiated service class options specify groupings of differentiated service classes. The exact grouping is not specified in the specifications. Classification rules and policing parameters for use of the differentiated services classes are configured by the visited access provider in the PDSN and are not sent in the RADIUS profile parameter. The method by which service providers agree to the same PDSN configuration definitions for each class is also needed but not specified. The differentiated services class, from a downlink packet, is copied to the differentiated service field of the mobile IP tunnel (RFC 2002). This is done by HA for every downlink packet. In the uplink direction, the PDSN determines the differentiated services field of each tunneled packet to the HA if reverse tunneling is enabled.  |
EAN: 2147483647
Pages: 164