HUAWEI SGSN9810 Serving GPRS Support Node Troubleshooting

3 Service Faults

3
About This Chapter
3.1 MS Attach Faults This section describes MS attach faults. 3.2 PDP Activation Faults This section describes the PDP activation faults. 3.3 RAU and Handoff Faults This section describes some RAU and handoff faults. 3.4 Bill Faults This section describes bill faults.

Service Faults

This section describes MS attach faults,PDP activation faults,RAU and handoff faults,bill faults.

Issue 02 (2007-12-30)

Huawei Technologies Proprietary

3-1

3 Service Faults

HUAWEI SGSN9810 Serving GPRS Support Node Troubleshooting

3.1 MS Attach Faults

This section describes MS attach faults. 3.1.1 Background Knowledge of MS Attach In the GSM or UMTS packet switched (PS) domain, there are three attach procedures. GPRS attach, GPRS attach when the MS is already IMSI-attached , Combined GPRS and IMSI attach. 3.1.2 Failure to Receive the Attach Request The SGSN does not receive the Attach Request sent by a MS. 3.1.3 Attach Reject:GPRS Service not allowed Upon receiving an Attach Request sent by a MS, the SGSN sends an Attach Reject message carrying the cause value "GPRS service not allowed" to the MS. 3.1.4 Attach Reject:Illegal MS Upon receiving the Send Authentication Info Ack message sent by the HLR, the SGSN sends an Attach Reject message carrying the cause value "Illegal MS." 3.1.5 Attach Reject:Protocol error, unspecified(No Response from HLR) After the SGSN sends an Update Location message to the HLR, the HLR does not send an, or the SGSN does not receive any Insert Subscriber Data message or Update Location Ack message from the HLR. Therefore, the SGSN sends an Attach Reject message to the MS, carrying the cause value "Protocol error, unspecified." 3.1.6 Attach Reject:Protocol error, unspecified(IMSI-GT Not Configured) Upon receiving an Attach Request sent by a MS, the SGSN sends an Attach Reject message carrying the cause value "protocol error." 3.1.7 Attach Reject:Protocol error, unspecified(ODB Not Supported) The mobile application part (MAP) module supports all operator determined barring (ODB) functions. During a MS attach, you can view the correct Insert Subscription Data message on the Gr interface, but the SGSN rejects this message carrying the cause value "protocol error." 3.1.8 Attach Reject:Other Cause Values Upon receiving an Update Location Ack message sent by the HLR, the SGSN sends an Attach Reject message carrying a specific cause value. 3.1.9 Attach Accept:MSC temporarily not reachable(Not Sending Location Update Request) Upon receiving an Update Location Ack message during a combined GPRS/IMSI attach, the SGSN sends an Attach Accept message carrying the cause value " mobile service switching center (MSC) temporarily not reachable" instead of sending a Location Update Request. 3.1.10 Attach Accept:MSC temporarily not reachable(Failure to Receive a Location Update Accept) After sending a Location Update Request during a combined GPRS/IMSI attach, the SGSN does not receive a Location Update Accept message sent by the VLR. The SGSN sends an Attach Accept message carrying the cause value "MSC temporarily not reachable." 3.1.11 Other attach failure: No Attach Complete message returned from the UE During a 3G attach, the SGSN has sent the Attach Accept message to the UE and assigned a new PTMSI to that UE, however the UE does not return the Attach Complete message as stated in the protocol. Therefore, the UE keeps sending AttachReq messages and the SGSN keeps sending AttachAcc messages, so the packet services of the UE cannot be carried out. 3.1.12 Gb Interface Parameters Inconsistency (2.5G)
3-2 Huawei Technologies Proprietary Issue 02 (2007-12-30)

HUAWEI SGSN9810 Serving GPRS Support Node Troubleshooting

3 Service Faults

During a 2.5G MS attach, The SGSN sends an Attach Accept message to a packet control unit (PCU) and allocates a new temporary link level identity (TLLI) to the MS. The MS does not return an Attach Complete message. The MS repeatedly sends AttachReq messages and the SGSN repeatedly sends AttachAcc messages. 3.1.13 Wrong Configuration of the Mutual Aid DPC Authentication during the attach is normal. The MAP receives a P-ABORT message from the lower-layer protocol 30 seconds after the location update is initiated. 3.1.14 IMSI Not Known During a location update, the HLR rejects the Attach Request sent by the MS with the cause value "IMSI not known." 3.1.15 MS Inaccessible All MSs in one cell cannot access the network or implement the GPRS services in a certain period. The Gb interface tracing or Ns interface tracing shows that the SGSN does not send any message to the MSs after receiving AttachReq messages from MSs. Forward and reverse messages are unavailable in the MS tracing. 3.1.16 Using Original PTMSI After SIM Card Change When you perform GPRS service using a MS without authentication, a fault occurs. After the attach using the SIM1 is complete, remove the battery and perform the attach using SIM2. The attach succeeds. When you query the subscriber context on the LMT using the IMSI of SIM2, the system prompts that the subscriber does not exist. 3.1.17 IMSI Number Segment Varying with 2G and 3G MSs After receiving an Attach Request sent by a MS, the SGSN does not respond, or the SGSN sends an Attach Reject message carrying one of the following cause values before authentication. protocol error,no suitable cell in this laorgprs service not allowed. 3.1.18 APN Varying with MSs A MS succeeds in location update, but the SGSN sends an Attach Reject message immediately carrying either of the following cause values, no suitable cells in laorgprs service not allowed. 3.1.19 Restriction Location Area (Routing Area) Within the IMSI Number Segment After the MS sends an Attach Request, the attach in some routing areas succeeds. But in some routing areas, the SGSN, before initiating the authentication, sends an Attach Reject message carrying either of the following cause values,la not allowedorgprs service not allowed. 3.1.20 MS Authentication Failure The authentication parameter of the SGSN is set to allow authentication. During a MS attach, after the SGSN sends an Authentication Encryption Request, the MS returns an authentication encryption failure message, carry one of the following cause values,sync failure, mac failureandgsm authentication unacceptable,After the SGSN re-initiates authentication, the authentication sometimes fails. 3.1.21 Encryption Failure (3G) Encryption allocation fails during the process of 3G MS attach, thus resulting in an attach failure.

3.1.1 Background Knowledge of MS Attach

In the GSM or UMTS packet switched (PS) domain, there are three attach procedures. GPRS attach, GPRS attach when the MS is already IMSI-attached , Combined GPRS and IMSI attach.
l

GPRS attach

Issue 02 (2007-12-30)

Huawei Technologies Proprietary

3-3

3 Service Faults
l l

HUAWEI SGSN9810 Serving GPRS Support Node Troubleshooting

GPRS attach when the MS is already IMSI-attached Combined GPRS and IMSI attach

The combined GPRS and IMSI attach is a typical procedure. Figure 3-1shows the combined GPRS and IMSI attach procedure. You can enable MS tracing or interface tracing on an LMT of the SGSN system to obtain signaling messages of the attach procedures. Figure 3-1 Combined GPRS and IMSI attach procedure
MS BSS/ UTRAN newSGSN old SGSN GGSN new EIR MSC/ VLR old HLR MSC/ VLR

1. Attach Request

2. Identification Request 2. Identification Response

3. Identity Request 3. Identity Response 4. Authentication 5. IMEI Check 6a. Update Location 6b. Cancel Location 6c. Cancel Location Ack 6d. Insert Subscriber Data 6e. Insert Subscriber Data Ack 6f. Update Location Ack 7b. Update Location 7c. Cancel Location 7d. Cancel Location Ack 7e. Insert Subscriber Data 7f. Insert Subscriber Data Ack 7h. Location Update Accept 8. Attach Accept C1 7g. Update Location Ack 7a. Location Update Request

9. Attach Complete 10.TMSI Reallocation Complete

Common Faults The following are common MS attach faults:

l l l l

Failure to Receive the Attach Request GPRS Service Not Allowed Illegal MS No Response from HLR
Huawei Technologies Proprietary Issue 02 (2007-12-30)

3-4

HUAWEI SGSN9810 Serving GPRS Support Node Troubleshooting

l l l l l l l l l l l l l l l l

3 Service Faults

IMSI-GT Not Configured ODB Not Supported Other Cause Values Not Sending Location Update Request Failure to Receive a Location Update Accept Other attach failure: No Attach Complete message returned from the UE Gb Interface Parameters Inconsistency (2.5G) Wrong Configuration of Mutual Aid Between SCCP and DPC IMSI Not Known MS Inaccessible Using Original PTMSI After SIM Card Change IMSI Number Segment Varying with 2G and 3G MSs APN Varying with MSs Restriction Location Area (Routing Area) Within the IMSI Number Segment MS Authentication Failure Encryption Failure (3G)

3.1.2 Failure to Receive the Attach Request

The SGSN does not receive the Attach Request sent by a MS.

Context
Possible Cause:
l l

The Gb interface in the 2.5G network is faulty. The lu interface in the 3G network is faulty.

Procedure
Refer to 6 Iu Interface Faultsor 7 Gb Interface Faults. ----End

3.1.3 Attach Reject:GPRS Service not allowed

Upon receiving an Attach Request sent by a MS, the SGSN sends an Attach Reject message carrying the cause value "GPRS service not allowed" to the MS.

Context
Possible Cause:
l

The MS is roaming and the public land mobile network (PLMN) to which it belongs is not configured as an interconnected PLMN in the SGSN. The subscriber is an mobile virtual network operator (MVNO) subscriber. The number of MVNO subscribers currently attached in the system reaches the limit.
Huawei Technologies Proprietary 3-5

Issue 02 (2007-12-30)

3 Service Faults

HUAWEI SGSN9810 Serving GPRS Support Node Troubleshooting

Procedure
Step 1 Check the traced signaling to obtain the IMSI of the MS. Step 2 Execute LST CONNECTPLMN on the LMT to query information on the interconnected PLMN.
l

If the configuration of the original interconnected PLMN is incorrect, execute MOD CONNECTPLMN on the LMT to modify the configuration. If the PLMN information is not found, execute ADD CONNECTPLMN on the LMT to add the record of an interconnected PLMN.

Step 3 If the subscriber is an MVNO subscriber, check the number of subscribers attached in the system and the system limit using LST MVNORES and DSP MVNOUSR. If the two numbers are the same, it is necessary to expend the MVNO capacity. ----End

3.1.4 Attach Reject:Illegal MS

Upon receiving the Send Authentication Info Ack message sent by the HLR, the SGSN sends an Attach Reject message carrying the cause value "Illegal MS."

Context
Possible Cause:
l l l

The MS is unauthorized. The MS subscription data is wrong. The MS fails authentication because its authentication parameter is inconsistent with that in the HLR.

Procedure
Step 1 Contact the HLR maintenance personnel to confirm the MS subscription data.If the MS is unauthorized, you need not handle the fault. Step 2 If the subscription data is wrong, ask the HLR maintenance personnel to modify it. ----End

3.1.5 Attach Reject:Protocol error, unspecified(No Response from HLR)

After the SGSN sends an Update Location message to the HLR, the HLR does not send an, or the SGSN does not receive any Insert Subscriber Data message or Update Location Ack message from the HLR. Therefore, the SGSN sends an Attach Reject message to the MS, carrying the cause value "Protocol error, unspecified."

Context
Possible Cause: The Gr interface is faulty.
3-6 Huawei Technologies Proprietary Issue 02 (2007-12-30)

HUAWEI SGSN9810 Serving GPRS Support Node Troubleshooting

3 Service Faults

Procedure
Refer to 4 SS7 Interface Faultsfor details. ----End

3.1.6 Attach Reject:Protocol error, unspecified(IMSI-GT Not Configured)

Upon receiving an Attach Request sent by a MS, the SGSN sends an Attach Reject message carrying the cause value "protocol error."

Context
Possible Cause: The global title (GT) code is unavailable for location update because the IMSI-GT table is not configured. Therefore, the attach request is rejected.

Procedure
To remove this fault, add the associated configuration record. ----End

3.1.7 Attach Reject:Protocol error, unspecified(ODB Not Supported)

The mobile application part (MAP) module supports all operator determined barring (ODB) functions. During a MS attach, you can view the correct Insert Subscription Data message on the Gr interface, but the SGSN rejects this message carrying the cause value "protocol error."

Context
Possible Cause: The MS subscribes to the ODB function. But the ODB parameter is set to forbid the MS to access the network.

Procedure
Step 1 Check the subscription data in the Gr interface tracing message. Step 2 Check if the ODB function is configured and supported. To remove the fault, do the following:
l l

Contact the HLR personnel to cancel the ODB subscription. Change "ODB support" to "ODB not support" in the MAPFUNC table of the SGSN.

----End
Issue 02 (2007-12-30) Huawei Technologies Proprietary 3-7

3 Service Faults

HUAWEI SGSN9810 Serving GPRS Support Node Troubleshooting

3.1.8 Attach Reject:Other Cause Values

Upon receiving an Update Location Ack message sent by the HLR, the SGSN sends an Attach Reject message carrying a specific cause value.

Context
Possible Cause: The subscription data in the HLR does not match that in the SGSN. Table 3-1lists the cause values. Table 3-1 Possible causes for attach reject Cause Value Illegal MS Possible Causes
l l

The MS is not defined in the HLR. The authentication fails. The MS is prohibited to access the visited PLMN (VPLMN). The MS is in ODB status. The MS is barred in the HLR.

PLMN not allowed

l l

Location Area not allowed

The non-roaming MS is prohibited to attach in the location area specified by a zone code (ZC). The roaming MS is prohibited to attach in the location area specified by a ZC.

Roaming not allowed in this location area (LA)

Procedure
Step 1 contact the HLR maintenance personnel to confirm the MS subscription data.If the MS is unauthorized, you need not handle the fault. Step 2 If the subscription data is wrong, ask the HLR maintenance personnel to modify it. ----End

3.1.9 Attach Accept:MSC temporarily not reachable(Not Sending Location Update Request)
Upon receiving an Update Location Ack message during a combined GPRS/IMSI attach, the SGSN sends an Attach Accept message carrying the cause value " mobile service switching center (MSC) temporarily not reachable" instead of sending a Location Update Request.

Context
Possible Cause:
3-8 Huawei Technologies Proprietary Issue 02 (2007-12-30)

HUAWEI SGSN9810 Serving GPRS Support Node Troubleshooting

l l

3 Service Faults

Visitor location register (VLR) information is unavailable. The correspondence between the VLR and location area identification (LAI) is incorrect.

Procedure
Step 1 Check the identity of the routing area (RA) where the MS locates and the number of VLR serving the RA. Step 2 Execute LST VLR on the LMT to check if the VLR is properly configured. If it is improperly configured, execute MOD VLR to modify the configuration or ADD VLR to add the VLR configuration. Step 3 Execute LST LAIVLR on the LMT to check if the correspondence between the LAI and the VLR is correct. Step 4 If the correspondence between the LAI and the VLR is incorrect, do the following: Execute ADD LAIVLR to add an RAI-VLR correspondence.Execute RMV LAIVLR to remove the wrong correspondence, and then execute ADD LAIVLR to add an RAI-VLR correspondence. ----End

3.1.10 Attach Accept:MSC temporarily not reachable(Failure to Receive a Location Update Accept)
After sending a Location Update Request during a combined GPRS/IMSI attach, the SGSN does not receive a Location Update Accept message sent by the VLR. The SGSN sends an Attach Accept message carrying the cause value "MSC temporarily not reachable."

Context
Possible Cause: The Gs interface is faulty.

Procedure
Refer to4 SS7 Interface Faultsfor details. ----End

3.1.11 Other attach failure: No Attach Complete message returned from the UE
During a 3G attach, the SGSN has sent the Attach Accept message to the UE and assigned a new PTMSI to that UE, however the UE does not return the Attach Complete message as stated in the protocol. Therefore, the UE keeps sending AttachReq messages and the SGSN keeps sending AttachAcc messages, so the packet services of the UE cannot be carried out.

Context
Possible Cause: The 3G attach requires encryption. The SGSN however does not initiate the authentication encryption procedure or the SGSN initiates an authentication encryption procedure which indicates that the encryption is not required.
Issue 02 (2007-12-30) Huawei Technologies Proprietary 3-9

3 Service Faults

HUAWEI SGSN9810 Serving GPRS Support Node Troubleshooting

Procedure
Check the authentication flag and encryption flag using LST PMM and LST 3GAUTHCIPH. If the flags are off, enable the authentication and encryption functions for that subscriber using SET PMM and ADD/MOD 3GAUTHCIPH.
NOTE

Use SET PMM to set the authentication flag and encryption flag for all the subscribers. Use ADD/MOD 3GAUTHCIPH to set the authentication flag and encryption flag for specified subscribers.

----End

3.1.12 Gb Interface Parameters Inconsistency (2.5G)

During a 2.5G MS attach, The SGSN sends an Attach Accept message to a packet control unit (PCU) and allocates a new temporary link level identity (TLLI) to the MS. The MS does not return an Attach Complete message. The MS repeatedly sends AttachReq messages and the SGSN repeatedly sends AttachAcc messages.

Context
Possible Cause: The Gb interface parameters on the SGSN and those on the PCU are inconsistent.

Procedure
Refer to 7 Gb Interface Faults. ----End

3.1.13 Wrong Configuration of the Mutual Aid DPC

Authentication during the attach is normal. The MAP receives a P-ABORT message from the lower-layer protocol 30 seconds after the location update is initiated.

Context
Possible Cause: The mutual aid DPC configuration is wrong.

Procedure
The signaling point of the mutual aid DPC in the SCCP DPC table does not reaches the destination normally.Thus, when the SCCP performs load sharing, there is response to the signaling sent to the main signaling point but no response to the signaling sent to the mutual aid DPC. ----End

3.1.14 IMSI Not Known

During a location update, the HLR rejects the Attach Request sent by the MS with the cause value "IMSI not known."
3-10 Huawei Technologies Proprietary Issue 02 (2007-12-30)

HUAWEI SGSN9810 Serving GPRS Support Node Troubleshooting

3 Service Faults

Context
Possible Cause:
l l

The MS is unauthorized and is not defined in the HLR. The IMSIGT or SCCPGT table is wrongly configured. The MSs in the HLR1 are configured into HLR2.

Procedure
To locate and remove the fault, contact the HLR maintenance personnel for help. If the HLR is correctly configured, add the subscription information into the HLR. ----End

3.1.15 MS Inaccessible
All MSs in one cell cannot access the network or implement the GPRS services in a certain period. The Gb interface tracing or Ns interface tracing shows that the SGSN does not send any message to the MSs after receiving AttachReq messages from MSs. Forward and reverse messages are unavailable in the MS tracing.

Context
Possible Cause: After the cell is reset, the PCU does not send the cell flow control message. Thus, the SGSN discards the MS message capsule directly.

Procedure
Step 1 Execute DSP PTPBVC to check if the cell receives the flow control message.If the cell receives no flow control message, reset the cell to allow the PCU to report the cell flow control message again. Step 2 If the fault persists, ask the PCU maintenance personnel to check the PCU settings. ----End

3.1.16 Using Original PTMSI After SIM Card Change

When you perform GPRS service using a MS without authentication, a fault occurs. After the attach using the SIM1 is complete, remove the battery and perform the attach using SIM2. The attach succeeds. When you query the subscriber context on the LMT using the IMSI of SIM2, the system prompts that the subscriber does not exist.

Context
Possible Cause: The MS stores the PTMSI in the MS memory rather than the SIM card. After the SIM card is replaced, the MS-originated PTMSI attach uses the PTMSI in the MS rather than the PTMSI saved in the SIM card. Thus, the MS with the wrong PTMSI accesses the SGSN.
Issue 02 (2007-12-30) Huawei Technologies Proprietary 3-11

3 Service Faults

HUAWEI SGSN9810 Serving GPRS Support Node Troubleshooting

Procedure
To remove the fault, enable the authentication function. ----End

3.1.17 IMSI Number Segment Varying with 2G and 3G MSs

After receiving an Attach Request sent by a MS, the SGSN does not respond, or the SGSN sends an Attach Reject message carrying one of the following cause values before authentication. protocol error,no suitable cell in this laorgprs service not allowed.

Context
Possible Cause:
l

The MS property is configured according to the IMSI number segment, but the resource type of the USPU is not configured correctly. The MS property is configured according to the IMSI number segment, but the GPRS subscriber cannot access the UMTS network according to the configuration in the service function table.

Procedure
Step 1 The attach request may be discarded or there is no response in one of the following cases:The MS is configured as GPRS MS, and all the USPUs are configured as UMTS boards. Step 2 The MS is configured as UMTS MS, and all the USPUs are configured as GPRS boards. The MS is configured as GPRS MS, but the GPRS subscriber cannot access the UMTS network according to the configuration in the service function table. When accessing the UMTS network, this MS is rejected with the cause value "no suitable cell in this LA." If a value change takes place, the cause value may change to "gprs service not allowed." ----End

3.1.18 APN Varying with MSs

A MS succeeds in location update, but the SGSN sends an Attach Reject message immediately carrying either of the following cause values, no suitable cells in laorgprs service not allowed.

Context
Possible Cause: The MS access function based on the access point name (APN) is enabled in the service extension table. But no APN is configured or a wrong APN is configured.

3-12

Huawei Technologies Proprietary

Issue 02 (2007-12-30)

HUAWEI SGSN9810 Serving GPRS Support Node Troubleshooting

3 Service Faults

Procedure
To locate and remove the fault, check if there is an intersection between the APNs of the PLMN on the APNNI list and the APNs that the MS subscribes to. ----End

3.1.19 Restriction Location Area (Routing Area) Within the IMSI Number Segment
After the MS sends an Attach Request, the attach in some routing areas succeeds. But in some routing areas, the SGSN, before initiating the authentication, sends an Attach Reject message carrying either of the following cause values,la not allowedorgprs service not allowed.

Context
Possible Cause: The IMSI is configured in the restriction location area table and the IMSI of this MS is within the restriction number range.

Procedure
Step 1 Check the IMSI of the MS that initiates the attach is configured in the restriction location area table. Step 2 There is an intersection between the restriction location area or routing area and the routing area of the MS currently attached. ----End

3.1.20 MS Authentication Failure

The authentication parameter of the SGSN is set to allow authentication. During a MS attach, after the SGSN sends an Authentication Encryption Request, the MS returns an authentication encryption failure message, carry one of the following cause values,sync failure, mac failureandgsm authentication unacceptable,After the SGSN re-initiates authentication, the authentication sometimes fails.

Context
Possible Cause:
l l

The authentication set defined in the HLR is wrong. The authentication set of the SGSN does not match that of the MS. The attach may succeed after you re-obtain the authentication set. An unauthorized MS uses the IMSI for attach. The authentication fails.

Procedure
To locate and remove the fault, check that the authentication set of the MS is correct. ----End
Issue 02 (2007-12-30) Huawei Technologies Proprietary 3-13

3 Service Faults

HUAWEI SGSN9810 Serving GPRS Support Node Troubleshooting

3.1.21 Encryption Failure (3G)

Encryption allocation fails during the process of 3G MS attach, thus resulting in an attach failure.

Context
Possible Cause: The configuration of the encryption algorithm is wrong.

Procedure
There is no an intersection between UEA0 or UEA1 algorithm and circuit switched (CS) algorithm because only UEA0 or EA1 algorithm is configured. Therefore, the encryption allocation fails. To remove this fault, configure both the UEA0 algorithm and the UEA1 algorithm. ----End

3.2 PDP Activation Faults

This section describes the PDP activation faults. 3.2.1 Background Knowledge of PDP Activation Before you use the PS service, the PDP activation procedure needs to be initiated. 3.2.2 Failure to Receive the Activate PDP Context Request The SGSN does not receive any Activate PDP Context Request sent by a MS. 3.2.3 Requested Service Option Not Subscribed Case I After receiving an Activate PDP Context Request, the SGSN sends an Activate PDP Context Reject message carrying the cause value "requested service option not subscribed."The session management (SM) rejects the mobility management (MM) activation request. The domain name service (DNS) resolution request from the SM to the GTP is unavailable in the internal tracing of SM (PID = 29). 3.2.4 Requested Service Option Not Subscribed Case II Upon receiving a PDP Activation Request sent by a MS, the SGSN sends an Activate PDP Context Reject message carrying the No.33 cause value "requested service option not subscribed." Execute DSP USPUPDP to check if the APN in the subscribed PDP is the same as that in the PDP Activation Request. 3.2.5 Activate PDP Context Reject:Missing or unknown APN Upon receiving an Activate PDP Context Request, the SGSN sends an Activate PDP Context Reject message carrying the cause value "Missing or unknown APN." 3.2.6 Activate PDP Context Reject:Protocol error unspecified After initiating the radio access bearer (RAB) assignment procedure, the SGSN receives no RAB Assignment Response or receives an RAB Assignment Response indicating the RAB assignment failure. The SGSN sends an Activate PDP Context Reject message carrying the cause value "Protocol error unspecified." 3.2.7 Activate PDP Context Reject:Activation rejected by GGSN The SGSN sends an Activate PDP Context Reject message to the MS carrying the cause value "Activation rejected by GGSN."
3-14 Huawei Technologies Proprietary Issue 02 (2007-12-30)

HUAWEI SGSN9810 Serving GPRS Support Node Troubleshooting

3 Service Faults

3.2.8 Activate PDP Context Reject:User Authentication failed After the GGSN responds with a Create PDP Context Response, the SGSN sends an Activate PDP Context Reject message carrying the cause value "User Authentication failed." 3.2.9 Activate PDP Context Reject:Operator Determined Barring The SGSN sends an Activate PDP Context Reject message to a MS carrying No.8 cause value "Operator Determined Barring." 3.2.10 Activate PDP Context Reject:Service option not supported Upon receiving a Create PDP Context Response, the GGSN sends an Activate PDP Context Reject message to a MS carrying the cause value "Service option not supported." 3.2.11 Activate PDP Context Reject:Insufficient resources Upon sending a Create PDP Context Request, the SGSN sends an Activate PDP Context Reject message carrying the No.26 cause value "Insufficient resources." A Create PDP Context Response sent from the GGSN may appear in the user tracing. 3.2.12 GTP-C Path Faulty After a 2G MS activates a PDP context, the SGSN immediately initiates the PDP deactivation. 3.2.13 Improper Counter Setting in GTP Version To verify the APN, the PDP context activation test is performed in multiple GGSNs. The initial PDP context activation of some GGSNs fails. Later activations are normal. The APN is "test.sd" and "test.bj". 3.2.14 Forward Packet Unavailable After Activation Succeeds After the activation succeeds, only the reverse packet is available. The MS initiates the deactivation automatically.

3.2.1 Background Knowledge of PDP Activation

Before you use the PS service, the PDP activation procedure needs to be initiated. Figure 3-2illustrates the procedure for MS-originated PDP context activation in the 2.5G communication system. Figure 3-3illustrates the procedure for MS-originated PDP context activation in the 3G communication system. You can obtain the signaling message of the PDP activation procedure by enabling a MS tracing or interface tracing on an LMT. Figure 3-2 PDP context activation procedure in 2.5G
MS BSS 2G-SGSN 2G-GGSN

1. Activate PDP Context Request C1 2. Security Functions 3. Invoke Trace 4. Create PDP Context Request 5. Create PDP Context Response 6. BSS Packet Flow Context Procedures C2 7. Activate PDP Context Accept

Issue 02 (2007-12-30)

Huawei Technologies Proprietary

3-15

3 Service Faults

HUAWEI SGSN9810 Serving GPRS Support Node Troubleshooting

Figure 3-3 PDP context activation procedure in 3G

MS UTRAN 3G-SGSN 3G-GGSN

1. Activate PDP Context Request C1 2. Create PDP Context Request 3. Create PDP Context Response 4. Radio Access Bearer Setup 5. Invoke Trace 6. Update PDP Context Request 7. Update PDP Context Response C2 8. Activate PDP Context Accept

Common Faults Common PDP activation faults include:

l l l l l l l l l l l l l

Failure to Receive the Activate PDP Context Request Requested Service Option Not Subscribed Case I Requested Service Option Not Subscribed Case II Missing or Unknown APN Protocol Error Unspecified Activation Rejected by GGSN User Authentication Failure Requested Service Option Not Subscribed Operator Determined BarringService Option Not Supported Insufficient Resources GTP-C Path Faulty Improper Counter Setting in GTP Version Forward Packet Unavailable After Activation Succeeds

3.2.2 Failure to Receive the Activate PDP Context Request

The SGSN does not receive any Activate PDP Context Request sent by a MS.

Context
Possible Cause:
3-16 Huawei Technologies Proprietary Issue 02 (2007-12-30)

HUAWEI SGSN9810 Serving GPRS Support Node Troubleshooting

l l

3 Service Faults

The Gb interface in the 2.5G network is faulty. The lu interface in the 3G network is faulty.

Procedure
Refer to 6 Iu Interface Faultsor 7 Gb Interface Faultsfor details. ----End

3.2.3 Requested Service Option Not Subscribed Case I

After receiving an Activate PDP Context Request, the SGSN sends an Activate PDP Context Reject message carrying the cause value "requested service option not subscribed."The session management (SM) rejects the mobility management (MM) activation request. The domain name service (DNS) resolution request from the SM to the GTP is unavailable in the internal tracing of SM (PID = 29).

Context
Possible Cause:
l l l

A mismatch of the tripletPDP address type, PDP address, and APN occurs. The subscribed quality of service (QoS) in the PDP is invalid. A roaming MS cannot enable the PDP according to the configuration in the interconnection PLMN table. A roaming MS cannot enable the PDP according to the configuration in the billing parameter table.

Procedure
Step 1 Check if the triplet matches the unique subscribed PDP according to the routing algorithm defined in Appendix A of 3rd generation partnership project (3GPP) 23.060. If a mismatch occurs, the triplet in the PDP-activated message or the subscription data may be wrong. To remove this fault, modify the subscription data in the HLR or the triplet in the PDP-activated message. Step 2 Check if the invalid value is available in the subscribed QoS in the HLR by comparing the valid value range of each QoS property in the 2GSM or 3GSM protocol configuration table.
NOTE

If only QoS98 is subscribed in the HLR, the extension QoS is zero. The PDP-activated message, however, carries QoS99. In this case, the SGSN uses the extension QoS for negotiation and detects that the extension QoS subscribed is invalid. Therefore, you need to validate the subscribed QoS in the HLR.

Step 3 If the MS is roaming, execute LST CONNECTPLMN to check if the SM service is activated in the interconnection PLMN table. If it is not allowed, execute ADD CONNECTPLMN to activate the SM service in the interconnection PLMN table. Step 4 If the MS is roaming, execute LST CHGBEHA to check if the roaming MS is forbidden to activate the PDP according to the configuration in the billing parameter table. If it is forbidden, execute RMV CHGBEHA to remove the parameter that does not allow the roaming MS to activate the PDP. ----End
Issue 02 (2007-12-30) Huawei Technologies Proprietary 3-17

3 Service Faults

HUAWEI SGSN9810 Serving GPRS Support Node Troubleshooting

3.2.4 Requested Service Option Not Subscribed Case II

Upon receiving a PDP Activation Request sent by a MS, the SGSN sends an Activate PDP Context Reject message carrying the No.33 cause value "requested service option not subscribed." Execute DSP USPUPDP to check if the APN in the subscribed PDP is the same as that in the PDP Activation Request.

Context
Possible Cause: The APN in the subscribed PDP has implicit characters. The characters in the APN must be explicit american standard code for information interchange (ASCII) characters, as defined in the protocol. The valid value range is as follows:
l l l l

"0" to "9" "a" to "z" "A" to "Z" "-"

The coding form is length + value (LV). For example, the hexadecimal codes of APN = huawei1.com in the Activation Request message are 07 68 75 61 77 65 69 31 03 63 6f 6d. Table 3-2lists the code descriptions. Table 3-2 Code description Code 07 68 75 61 77 65 69 31 03 63 6f 6d Description The length of the first section of APN "huawei1" The length of the second section of APN "com"

If you add an implicit space at the end when editing APN on a MS, the codes are 07 68 75 61 77 65 69 31 04 63 6f 6d 20. Table 3-3 lists the code description. Table 3-3 Code description Code 07 68 75 61 77 65 69 31 04
3-18 Huawei Technologies Proprietary

Description The length of the first section of APN "huawei1" The length of the second section of APN
Issue 02 (2007-12-30)

HUAWEI SGSN9810 Serving GPRS Support Node Troubleshooting

3 Service Faults

Code 63 6f 6d 20

Description "com "

The message tracing shows huawei1.com, but the APN match fails.

Procedure
To remove the fault, ensure that the hexadecimal codes corresponding to the APN in the PDP Activation Request are correct. ----End

3.2.5 Activate PDP Context Reject:Missing or unknown APN

Upon receiving an Activate PDP Context Request, the SGSN sends an Activate PDP Context Reject message carrying the cause value "Missing or unknown APN."

Context
Possible Cause:
l l l l l

DNS resolution fails and the IP address of the GGSN is unavailable. The APN OI is not configured in the 2GSM or 3GSM configuration table. The GGSN prompts that the APN is faulty. The PDP cannot use the APN OI of the VPLMN in the subscription. The GGSN address that supports the dynamic host configuration protocol (DHCP) and mobile IP (MIP) is not configured.

Procedure
Step 1 Check if the GGSN address corresponding to the APN is configured through SM internal tracing. The SM receives an empty GGSN address in the DNS resolution response after sending a DSN resolution request. Check if the GGSN address corresponding to the APN is correctly configured. If it is wrong, execute ADD IPV4DNSH on the LMT to configure the GGSN address in the DNSH table.If the DNS does not respond, check and repair the link from the SGSN to the DNS. For details, refer to 5 Gn/Gp/Ga Interface Faults Step 2 The GGSN may return an APN error. The GGSN sends a Create PDP Context Response to the SGSN carrying the cause value "Missing or unknown APN." In this case, modify the configuration in the GGSN to allow APN access. Step 3 If the parameter VPLMN Address Allowed is set to NO during PDP subscription in the HLR, the roaming MS cannot use APN OI of VPLMN to activate the PDP. In this case, modify VPLMN Address Allowed to YES. Step 4 If the MS initiates PDP activation in the DHCP or MIP mode, it obtains the IP address of the GGSN through the SGSN configuration rather than the DNS resolution. If the IP address of the GGSN is not configured in the SGSN, the MS cannot obtain the IP address of the GGSN. The cause value is "Missing or unknown APN." To remove the fault, execute ADD DHCPGIP to
Issue 02 (2007-12-30) Huawei Technologies Proprietary 3-19

3 Service Faults

HUAWEI SGSN9810 Serving GPRS Support Node Troubleshooting

add the IP address of the GGSN supporting DHCP and execute ADD MIPGIP to add the IP address of the GGSN supporting MIP. ----End

3.2.6 Activate PDP Context Reject:Protocol error unspecified

After initiating the radio access bearer (RAB) assignment procedure, the SGSN receives no RAB Assignment Response or receives an RAB Assignment Response indicating the RAB assignment failure. The SGSN sends an Activate PDP Context Reject message carrying the cause value "Protocol error unspecified."

Context
Possible Cause: The RNC does not respond correctly to the RAB assignment request from the SGSN.

Procedure
Contact the RNC maintenance personnel to locate the RAB assignment failure. ----End

3.2.7 Activate PDP Context Reject:Activation rejected by GGSN

The SGSN sends an Activate PDP Context Reject message to the MS carrying the cause value "Activation rejected by GGSN."

Context
Possible Cause:
l l l

The GGSN responds with a failure message. The GGSN response timed out. The response from the GGSN is wrongly coded.

Procedure
If the GGSN responds with a Create PDP Context Response carrying the failure cause value, the GGSN is faulty or the request sent by the SGSN is illegal. To locate the fault, check the failure cause value in the Create PDP Context Response. If the GGSN responds with a Create PDP Context Response carrying the success cause value, the coding of the GGSN response message is incorrect. Check if the message contains the necessary IEs or the mandatory information element (IE) value is correct. In this case, the GGSN personnel need to locate the fault.If the GGSN does not respond and the activation is rejected 30 seconds later, you can infer that the link from the SGSN to GGSN is blocked. For details, refer to5 Gn/Gp/Ga Interface Faults ----End

3.2.8 Activate PDP Context Reject:User Authentication failed

After the GGSN responds with a Create PDP Context Response, the SGSN sends an Activate PDP Context Reject message carrying the cause value "User Authentication failed."
3-20 Huawei Technologies Proprietary Issue 02 (2007-12-30)

HUAWEI SGSN9810 Serving GPRS Support Node Troubleshooting

3 Service Faults

Context
Possible Cause:
l

The authentication between the GGSN and the authentication, authorization and accounting (AAA) server fails. The tunnel between the GGSN and the AAA server is blocked.

Procedure
The GGSN sends a Create PDP Context Response carrying the No.29 cause value "User Authentication failed." The authentication function is enabled in the GGSN, but the PDP activation is rejected owing to authentication failure. In this case, ask the GGSN personnel to remove the fault. ----End

3.2.9 Activate PDP Context Reject:Operator Determined Barring

The SGSN sends an Activate PDP Context Reject message to a MS carrying No.8 cause value "Operator Determined Barring."

Context
Possible Cause:
l

If the MS subscribes to All Packet Switch Services Barred in the HLR, the MS cannot activate the PDP in the home PLMN (HPLMN) or VPLMN. If the MS subscribes to VPLMN AP Access Barred when defined in the HLR, the MS cannot activate the PDP using APN OI of VPLMN while attaching to VPLMN. If the MS subscribes to HPLMN AP Access Barred when defined in the HLR, the MS cannot activate the PDP using APN OI of HPLMN when attaching to VPLMN.

Procedure
To locate the fault, check if the MS subscribes to the ODB.
NOTE

ODB is a function introduced from the R4 protocol version. The subscribed ODB in the HLR takes effect only when the SGSN is configured as R4 protocol version and ODB is supported in the MAP function list.

----End

3.2.10 Activate PDP Context Reject:Service option not supported

Upon receiving a Create PDP Context Response, the GGSN sends an Activate PDP Context Reject message to a MS carrying the cause value "Service option not supported."

Context
Possible Cause:
Issue 02 (2007-12-30) Huawei Technologies Proprietary 3-21

3 Service Faults
l

HUAWEI SGSN9810 Serving GPRS Support Node Troubleshooting

License restriction on the activation in the point-to-point protocol (PPP), MIP, or IPV6 mode Restriction on the number of PDPs activated by the wild card

Procedure
Step 1 Check the PDP Activation Request message if the activation is in the PPP, MIP, or IPV6 mode. Step 2 Check if the PPP, MIP, or IPV6 mode in the license is ON. If the PPP, MIP, or IPV6 mode in the license is not ON, apply for a new license. Step 3 Check if the subscriber is a wild card subscriber (the subscribed APN is "*"). Step 4 Check if the restriction on the number of PDPs activated by the wild card is ON in the compatibility configuration table. Step 5 Execute SET COMPATIBILITY to change the restriction on the number of PDPs activated by the wild card to OFF. ----End

3.2.11 Activate PDP Context Reject:Insufficient resources

Upon sending a Create PDP Context Request, the SGSN sends an Activate PDP Context Reject message carrying the No.26 cause value "Insufficient resources." A Create PDP Context Response sent from the GGSN may appear in the user tracing.

Context
Possible Cause:
l l l l l l l

Resource request failure License restriction PDP resource congestion of the USPU Center processing unit (CPU) congestion of the UGBI PDP resource congestion of the UGBI Charging restriction Not Configuring the UGTP Board of GTPU or GTPC_GTPU Type

Procedure
Step 1 Check if the UGFU status is normal and if an alarm of UGFU resource congestion arises. Step 2 The activation request may be rejected owing to UGFU failure or resource congestion. Step 3 Check if the number of activated PDPs reaches the maximum and if an alarm of USPU resource congestion arises. Step 4 The activation request may be rejected owing to license restriction and PDP specification. Step 5 Check if an alarm of CPU congestion or PDP congestion of the UGBI arises. Step 6 The activation request may be rejected owing to the CUP congestion of the UGBI.
3-22 Huawei Technologies Proprietary Issue 02 (2007-12-30)

HUAWEI SGSN9810 Serving GPRS Support Node Troubleshooting

3 Service Faults

Step 7 Execute SET CHGCHAR to change the charging restriction icon in the parameter table of the charging property to disable this function. If the charging restriction is enabled, the subscriber data service of certain charging property is restricted when the bill cache is full. Thus, the activation request is rejected. Step 8 If only the GTP-C function rather than the GTP-U function is configured for the UGTP board, the system cannot apply for the GTP-U resources during the activation process, thus resulting in the activation failure. You can use the LST BRD command to check the configuration of the UGTP board. If only the GTP-C function is configured, you can use the command ADD BRD or MOD BRD to tune the data configuration. ----End

3.2.12 GTP-C Path Faulty

After a 2G MS activates a PDP context, the SGSN immediately initiates the PDP deactivation.

Context
Possible Cause: After the SGSN sends a PDP ACT ACCEPT message to the MS, the subnetwork dependent convergence protocol (SNDCP) link must be set up between the UGBI and the MS to notify the UGFU of the path information on the data plane. In this case, the UGFU needs to check the path on the data plane. If the path on the data plane is disrupted or faulty, the activation procedure fails. Thus, the SGSN initiates PDP deactivation after sending the PDP ACT ACCEPT message.

Procedure
Check if the path on the data plane is normal or repaired.Enable the echo probe on the data plane in the GUPPUB table. ----End

3.2.13 Improper Counter Setting in GTP Version

To verify the APN, the PDP context activation test is performed in multiple GGSNs. The initial PDP context activation of some GGSNs fails. Later activations are normal. The APN is "test.sd" and "test.bj".

Context
Possible Cause: The GTP version is incorrect.

Procedure
Step 1 Send a message of the GTPV1 to the peer node but receive no response. Step 2 Re-send N3 counter times and wait for T3 timer seconds. If there is no response, the SGSN sends a message of GTPV0 to the peer node. Meanwhile, the SGSN sends an Activation Reject
Issue 02 (2007-12-30) Huawei Technologies Proprietary 3-23

3 Service Faults

HUAWEI SGSN9810 Serving GPRS Support Node Troubleshooting

message to the MS. If the session management (SM) does not receive response from the peer node, it sends a PDP Activation Reject message. Step 3 Check data configuration and then find that the N3 counter is five and the T3 timer is 6 s. To reduce the negotiation time, change the N3 counter to three and T3 timer to 3 s. Step 4 Use "test.sd" to perform activation and find that the version of the first CREATE_PDP_CONTEXT_REQUEST message is GTPV0. Step 5 Use "test.sd" to perform activation and find that the version of the first three messages is GTPV1 and that of the fourth message is GTPV0. This indicates that the peer node has responded and the PDP activation has succeeded. The SGSN sends the CREATE_PDP_CONTEXT_REQUEST message to the peer node five times consecutively, but the peer node does not respond. At the sixth time, the peer node sends a RESPONSE message but the SGSN rejects the activation. The GTPV1 version is in use for the first five PDP context requests and the GTPV0 version is in use for the sixth time. This is because the GTP protocol of the 3G protocol is the GTPV1 version and is compatible with the GTPV0 version. Therefore, the following version negotiation procedure exists in the creation of a PDP context request: The reason that the GTPV0 is used in the first activation is described below. Once the GTP tunnel is set up, the tunnel information (including the GUP version information) is saved. During the period no service is available for the tunnel, the tunnel information is deleted to avoid version upgrade of the peer node. Therefore, after the activation using "test.sd" succeeds, the next activation uses the saved version information to create a context request. To remove the fault, execute RMV GTPCPATH to delete the path of some GTP tunnel. ----End

3.2.14 Forward Packet Unavailable After Activation Succeeds

After the activation succeeds, only the reverse packet is available. The MS initiates the deactivation automatically.

Context
Possible Cause: The Gi interface of the GGSN is blocked.

Procedure
To remove the fault, contact the GGSN maintenance personnel for help. ----End

3.3 RAU and Handoff Faults

This section describes some RAU and handoff faults. 3.3.1 Background Knowledge of RAU and Handoff
3-24 Huawei Technologies Proprietary Issue 02 (2007-12-30)

HUAWEI SGSN9810 Serving GPRS Support Node Troubleshooting

3 Service Faults

The RAU procedure is the same as the attach procedure. Relocation procedure consists of: Serving SRNS relocation procedure (soft handoff) ,Combined hard handoff and SRNS relocation procedure (hard handoff) ,Relocation procedure for combined cell update or RAU update. 3.3.2 Failure to Send Inter-SGSN RAU The MS initiates the inter-SGSN RAU. The SGSN sends an RAU REJ message carrying the cause value "Implicit detach." 3.3.3 CS Paging Failure During the combined GPRS/IMSI attach with the MS network mode 1, the MSC initiates a paging, the SGSN responds with a MOBILE STATUS message carrying the cause value "Mandatory IE Error." 3.3.4 Relocation Procedure Failure Relocation is a complex procedure. The relocation often fails during interconnection with the equipment of other vendors.

3.3.1 Background Knowledge of RAU and Handoff

The RAU procedure is the same as the attach procedure. Relocation procedure consists of: Serving SRNS relocation procedure (soft handoff) ,Combined hard handoff and SRNS relocation procedure (hard handoff) ,Relocation procedure for combined cell update or RAU update. The RAU procedure is the same as the attach procedure. Refer to 3.1.1 Background Knowledge of MS Attachfor details. Relocation procedure consists of:
l l l

Serving SRNS relocation procedure (soft handoff) Combined hard handoff and SRNS relocation procedure (hard handoff) Relocation procedure for combined cell update or RAU update

Figure 3-4shows the 3G soft handoff procedure, which is the same as the other two procedures.

Issue 02 (2007-12-30)

Huawei Technologies Proprietary

3-25

3 Service Faults

HUAWEI SGSN9810 Serving GPRS Support Node Troubleshooting

Figure 3-4 3G soft handoff procedure

MS Source RNC SRNS relocation 1. Decision to perform Target RNC Old SGSN New SGSN GGSN

2. Relocation Required 3. Forward Relocation Request 4. Relocation Request Establishment of Radio Access Bearers 4. Relocation Request Acknowledge 5. Forward Relocation Response C1 6. Relocation Command A 7. Relocation Commit 8. Forwarding of data 9. Relocation Detect 10. RNTI Reallocation B 12. RNTI Reallocation Complete 13. Relocation Complete T3TUNNEL 14. Iu Release Command D 14. Iu Release Complete 15. Routing Area Update 13. Forward Relocation Complete C 11. Update PDP Context Request 11. Update PDP Context Response

C2

The 3G soft handoff procedure is as follows: 1. 2. The source RNC initiates SRNS relocation. The source serving RNC (SRNC) sends a Relocation Required message (Relocation Type, Cause, Source Identity (ID), Target ID, Source RNC to target RNC transparent container) to the old SRNC.
NOTE

The source SRNC sets Relocation Type to UE not involved. Source to Target RNC Transparent Container includes the necessary information of relocation coordination, security functionality, and radio resource control (RRC) protocol context.

3.

The old SGSN determines whether the SRNS relocation is an intro-SGSN SRNS relocation or inter-SGSN SRNS relocation. In the case of inter-SGSN SRNS relocation, the old SGSN initiates the relocation resource allocation procedure by sending a Forward Relocation Request message (IMSI, Tunnel Endpoint Identifier Signaling, MM Context, PDP Context, Target Identification, UMTS terrestrial radio access network (UTRAN) transparent container, and radio access network application part (RANAP) Cause). Meanwhile, a timer is started. The Forward Relocation Request message is applicable only to the inter-SGSN SRNS relocation. The new SGSN sends a Relocation Request message (Permanent NAS UE Identity, Cause, core network (CN) Domain Indicator, Source RNC to target RNC transparent container,
Huawei Technologies Proprietary Issue 02 (2007-12-30)

4.

3-26

HUAWEI SGSN9810 Serving GPRS Support Node Troubleshooting

3 Service Faults

RABs to be setup) to the target RNC.For each requested RAB, RABs To Be Setup includes information such as RAB ID, RAB parameters, Transport Layer Address, and Iu Transport Association. The following are included in the information description:
l

The RAB ID information element includes the network layer service access point identifier (NSAPI) value value. The RAB parameters information provides the QoS profile. The Transport Layer Address is the SGSN address for user data. Iu Transport Association corresponds to the uplink tunnel endpoint identifier data (TEID).

l l l

5.

After all necessary resources for accepted RABs, including the Iu user plane, are successfully allocated, the target RNC sends the Relocation Request Acknowledge message (RABs setup, RABs failed to setup) to the new SGSN. The Target RNC receives the PDUs from the source SRNC and the new SGSN for each RAB to be set up. When the resource for the transmission of user data between the new SGSN and the target RNC is allocated, and the new SGSN is ready for the SRNS relocation, the new SGSN sends the Forward Relocation Response (Cause, RANAP Cause, and Target RNC Information) to the old SGSN. This message indicates that the target RNC is ready to receive the forwarded downlink packets from the source SRNC. The RAB Setup Information, one information element for each RAB, contains the RNC TEID and RNC IP address for data forwarding from the source SRNC to the target RNC. The old SGSN continues the relocation of SRNS by sending a relocation command (RABs to be released and RABs subject to data forwarding) message to the source SRNC. The old SGSN decides the RABs subject to data forwarding based on QoS and those RABs are to be included in the RABs subject to data forwarding.For each RAB subject to data forwarding, the information element unit includes RAB ID, Transport Layer Address, and Iu Transport Association.Transport Layer Address and Iu Transport Association are used for forwarding of downlink N-PDU from the source SRNC to the target RNC. Upon receiving the Relocation Command from the PS domain, the source RNC initiates the data forwarding timer. Upon completion of the relocation, the source RNC is ready to trigger the SRNS relocation by sending a Relocation Commit message (SRNS contexts) to the target RNC. The purpose of this procedure is to transfer the SRNS context from the source RNC to the target RNC.The SRNS contexts include:
l

6.

7.

8.

The sequence number of the next GTP-PDUs to be sent on the reverse and forward links. The sequence number of the next packet data convergence protocol (PDCP) sending or receiving data from the MS.

The PDCP sequence number using RLC unacknowledged mode is not in use. 9. Upon sending the Relocation Commit message, the source RNC begins forwarding data for the RABs to be subject for data forwarding. The data is forwarded through the Iu interface during the SRNS relocation. This means that the GTP-PDUs exchanged between the source RNC and the target RNC are duplicated in the source RNC and routed at the IP layer toward the target RNC.

10. The target RNC sends a Relocation Detect message to the new SGSN when the relocation execution trigger is received. When the Relocation Detect message is sent, the target RNC starts SRNC operation. 11. After sending the Relocation Detect, the source RNC sends an RNTI Reallocation message to the MS, including UE information elements and CN information elements.The UE information elements include new SRNC identity and S-RNTI. The CN information
Issue 02 (2007-12-30) Huawei Technologies Proprietary 3-27

3 Service Faults

HUAWEI SGSN9810 Serving GPRS Support Node Troubleshooting

elements include routing area identification (RAI) and LAI. The procedure is coordinated in all Iu signaling connections existing for the MS. 12. Upon receiving the Relocation Detect, the CN switches the user plane from the source RNC to the target RNC. If the SRNS Relocation is an inter-SGSN SRNS relocation, the new SGSN sends an Update PDP Context Request message (new SGSN address, SGSN tunnel endpoint identifier, QoS negotiated) to the GGSNs concerned. The GGSN updates the PDP context and returns an Update PDP Context Response message (GGSN Tunnel Endpoint Identifier). 13. Upon completing the reassignment, the MS sends an RNTI Reallocation Complete message to the target RNC and then, the packet switch with the MS begins. 14. When the target RNC receives the RNTI Reallocation Complete message indicating that the SRNC-ID+S RNTI are successfully exchanged with the MS through the radio protocols, the target RNC initiates the Relocation Complete procedure by sending the Relocation Complete message to the new SGSN. The purpose of the Relocation Complete procedure is to indicate by the target RNC the completion of the SRNS relocation to the CN.
l

Upon receiving the Relocation Complete message, the CN switches the user plane from the source RNC to the target RNC. If the SRNS Relocation is an inter-SGSN SRNS relocation, the new SGSN sends a Forward Relocation Complete message to the old SGSN to notify it of the completion of the SRNS relocation.

15. Upon receiving Relocation Complete or Forward Relocation Complete during the interSGSN SRNS relocation, the old SGSN sends Iu Release Command to the source RNC. When the data forwarding timer of the RNC expires, the source RNC responds with an Iu Release Complete. 16. If the new RAI is different from the old one after the MS completes RNTI relocation, the MS initiates routing area (RA) update procedure, which is only a subset of RA update because the MS operates in the PMM-CONNECTED mode. Common Faults The following are common faults of RAU and handoff:
l l l

Failure to Send Inter-SGSN RAU CS Paging Failure Relocation Procedure Failure

3.3.2 Failure to Send Inter-SGSN RAU

The MS initiates the inter-SGSN RAU. The SGSN sends an RAU REJ message carrying the cause value "Implicit detach."

Context
Possible Cause:
l l l

DNS configuration faults Peer faults Configuration faults

Huawei Technologies Proprietary Issue 02 (2007-12-30)

3-28

HUAWEI SGSN9810 Serving GPRS Support Node Troubleshooting

3 Service Faults

Procedure
Step 1 Trace signaling to obtain the old RAI. Step 2 Check that the RAI is configured with DNS. If the DNS is not configured, add the configuration on the DNS server or execute ADD IPV4DNSH on the LMT. If the data configuration is correct, you can infer that the fault may be caused by the peer end. Do the following to confirm that the fault is caused by the peer end: Step 3 Check if the alarm of link interruption arises to confirm that the link is normal for the address. Step 4 Obtain the Gn interface signaling tracing and check if the peer end sends an SGSN Context Response message to the local end. Step 5 If the peer end sends the SGSN Context Response message, check if the cause value carried is "Accepted." Ask the peer end maintenance personnel to remove the faults. ----End

3.3.3 CS Paging Failure

During the combined GPRS/IMSI attach with the MS network mode 1, the MSC initiates a paging, the SGSN responds with a MOBILE STATUS message carrying the cause value "Mandatory IE Error."

Context
Possible Cause: The VLR number in the CS paging message from the MSC to the SGSN is not configured in the VLR table of the SGSN.

Procedure
Upon receiving the CS paging, the SGSN checks the VLR number. If the SGSN does not find the VLR number in the VLR configuration table, the SGSN responds with a Mandatory IE Error message because the VLR number is a mandatory information element in the CS paging.Wrong configuration at the MSC/VLR side causes this fault. Ask MSC/VLR personnel to remove this fault. ----End

3.3.4 Relocation Procedure Failure

Relocation is a complex procedure. The relocation often fails during interconnection with the equipment of other vendors.

Context
Possible Cause:
l

During the inter-SGSN relocation, the old SGSN queries the DNS configuration through the TRNC specified by the SRNC to obtain the new SGSN address. If the query fails, the
Huawei Technologies Proprietary 3-29

Issue 02 (2007-12-30)

3 Service Faults

HUAWEI SGSN9810 Serving GPRS Support Node Troubleshooting

old SGSN sends a Reloc Prepare Fail message to the SRNC carrying the cause value "unknown target rnc."
l

After the relocation with the routing area changed is complete, the MS must initiate the RAU. Otherwise, the SGSN detaches the MS for the sake of resource protection. After receiving a RELOC REQUIRED message sent from the SRNC, the SGSN sends a RELOC PREPARE FAIL message and releases the SCCP connection. Inconsistency of the RNC protocol version and SGSN protocol version causes coding and encoding failure, thus resulting in relocation failure. The cell format of the Gn interface causes internal relocation procedure failure. After the relocation with the routing area changed is complete, the MS must initiate the RAU. Otherwise, the SGSN detaches the MS for the sake of resource protection. In some cases, however, the MS initiates the RAU before the new RNC sends a RELOC COMPLETE message. Thus, the RAU is discarded.

l l

Procedure
Step 1 If the DNS configuration is wrong, add the DNS configuration on the DNS server or execute ADD IPV4DNSH on the LMT. Step 2 If the data configuration at the AN side is wrong, contact the AN personnel for help. Step 3 If the protocol versions are inconsistent, confirm the protocol versions supported by the RNC and adjust the software parameters. Step 4 If the cell format of the Gn interface has an error, confirm the protocol versions supported by the RNC and adjust the software parameters. Step 5 RAU message discard is caused by wrong data configuration at the AN side. Contact the AN personnel for help. ----End

3.4 Bill Faults

This section describes bill faults. 3.4.1 Background Knowledge of Bill The billing system consists of the following three modules:USPU moduleUGTP module UCDR module. 3.4.2 Short-Conversation-Time Bills The GPRS billing is incorrect because 67 bills are generated in four seconds (from 16:05:09 to 16:05:13 on Jan, 18). 3.4.3 Bills with Zero Traffic Traffic in an S-CDR bill keeps as zero for a long time. 3.4.4 Traffic in the Generated Partial Bill Larger Than the Traffic Threshold You can set the time threshold and traffic threshold in the partial S-CDRs. After you set the traffic threshold, the traffic in the generated partial S-CDRs is larger than the threshold. 3.4.5 Useless Bill Remaining in the UCDR The R98 bills on the UCDR cannot be removed, and the hard disk cannot be formatted. To upgrade the bill protocol version of Ga interface to R99, engineers in this office disconnect the Ga interface and modify the configuration of the SGSN and CG.
3-30 Huawei Technologies Proprietary Issue 02 (2007-12-30)

HUAWEI SGSN9810 Serving GPRS Support Node Troubleshooting

3 Service Faults

3.4.6 Great Difference Between Traffic in S-CDR Bill and Traffic Measured by MS The traffic in the S-CDR bill differs substantially from the traffic measured by the MS. The difference rate is up to 30%. 3.4.7 Empty MSISDN Field The MSISDN field is empty in the generated R98 bill. 3.4.8 Long-Conversation-Time Bills Exceeding the Time Threshold The S-CDR bill does not generate bills according to the time threshold only from 3:00 to 4:00 every morning (the S-CDR bill is configured to generate bills according to the time threshold and traffic threshold). Thus, the S-CDR bill in the case of light traffic exceeds the time threshold. 3.4.9 Bills with Zero Time Length The duration and traffic of an S-CDR bill are zero. 3.4.10 S-CDR Bill Repetition The two S-CDR bills of a subscriber have an overlap of 80 seconds.

3.4.1 Background Knowledge of Bill

The billing system consists of the following three modules:USPU moduleUGTP module UCDR module.
l

USPU module (in the USPU board) It implements the following functions:

Collecting the information of mobility management generated-charging data record (MCDR), SGSN delivered short message mobile originated CDR (S-SMO-CDR), and SGSN delivered short message mobile terminated CDR (S-SMT-CDR), and generating semi-finished M-CDR, S-SMO-CDR, and S-SMT-CDR. Receiving the message of querying user charging and customized applications for mobile network enhanced logic (CAMEL) charging information from the UGFU and sending the query result to the UGTP. Transferring CAMEL traffic measurement information between the in-switching manager(INSM) and the UGTP. Sending all semi-finished M-CDR, S-SMO-CDR, and S-SMT-CDR to the UCDR.

UGTP module (in the UGTP board with the GTP type of "GTPU only" and "GTPC and GTPU both") It implements the following functions:

Collecting PDP context charging information, and generating semi-finished S-CDR and sending it to the UCDR. Receiving the CAMEL traffic measurement command transferred from the USPU and measuring CAMEL user data traffic information, which is sent to the INSM through the USPU.

UCDR module (in the UCDR board) It implements the following functions:

Performing abstract syntax notation one (ASN.1) coding for the semi-finished S-CDR, M-CDR, S-SMO-CDR, and S-SMT-CDR sent from the USPU and UGTP. Caching the semi-finished S-CDR, M-CDR, S-SMO-CDR, and S-SMT-CDR sent from the USPU and UGTP.

Issue 02 (2007-12-30)

Huawei Technologies Proprietary

3-31

3 Service Faults

HUAWEI SGSN9810 Serving GPRS Support Node Troubleshooting

Sending the semi-finished S-CDR, M-CDR, S-SMO-CDR, and S-SMT-CDR sent from the USPU and UGFU to the charging gateway (CG) through the Ga interface. Caching the bills in the hard disk when the communication between the SGSN and all CGs is interrupted and sending these bills to the CG after the communication becomes normal.

Common Faults The following are common faults of billing:

l l l l l l l l l

Short-Conversation-Time Bills Bills with Zero Traffic Traffic in the Generated Partial Bill Larger Than the Traffic Threshold Useless Bill Remaining in the UCDR Great Difference Between Traffic in S-CDR Bill and Traffic Measured by MS Empty MSISDN Field Long-Conversation-Time Bills Exceeding the Time Threshold Bills with Zero Time Length S-CDR Bill Repetition

3.4.2 Short-Conversation-Time Bills

The GPRS billing is incorrect because 67 bills are generated in four seconds (from 16:05:09 to 16:05:13 on Jan, 18).

Context
Possible Cause:
l l

Extremely heavy traffic affects the MS. The MS activates the third and fourth services, but the GGSN in the PS domain does not control the traffic of the third and fourth services. Thus, heavy traffic affects the SGSN directly.

Procedure
Step 1 Check the Gb traffic statistics to analyze the packet loss ratio. If the packet loss ratio is very high, you can infer that extremely heavy traffic affects the SGSN. Step 2 Measure the traffic of all bills to analyze the traffic rate. If the rate is very high or exceeds the maximum rate of the GPRS service, it proves that extremely heavy traffic affects the SGSN. ----End

3.4.3 Bills with Zero Traffic

Traffic in an S-CDR bill keeps as zero for a long time.

Context
Possible Cause:
3-32 Huawei Technologies Proprietary Issue 02 (2007-12-30)

HUAWEI SGSN9810 Serving GPRS Support Node Troubleshooting

3 Service Faults

After the MS activation, the traffic keeps as less than 10 KB for a long time.

Procedure
To locate and remove the fault, create a user tracing task and measure the traced packets to confirm that the traffic of this MS is light.When the traffic is less than the threshold configured, it is not reported to the call detail record (CDR) module. Thus, traffic in the S-CDR bill has been zero for a long time. To remove the fault, adjust the threshold (the minimum is 1 KB). ----End

3.4.4 Traffic in the Generated Partial Bill Larger Than the Traffic Threshold
You can set the time threshold and traffic threshold in the partial S-CDRs. After you set the traffic threshold, the traffic in the generated partial S-CDRs is larger than the threshold.

Context
Possible Cause: The UGFU measures traffic based on packets.

Procedure
The forward engine of the UGFU measures the traffic according to the length of the transmitted packets. The length of one packet is larger than 1 KB. Therefore, the traffic measured may exceed the traffic threshold in the S-CDR bills. The extra traffic is relevant to the packet length. ----End

3.4.5 Useless Bill Remaining in the UCDR

The R98 bills on the UCDR cannot be removed, and the hard disk cannot be formatted. To upgrade the bill protocol version of Ga interface to R99, engineers in this office disconnect the Ga interface and modify the configuration of the SGSN and CG.

Context
Possible Cause: The upgrade operation is improper.

Procedure
Step 1 Maintain the Ga interface configuration of the original protocol version. Step 2 Add the Ga interface configuration of the latest protocol version. Step 3 Restart the USPU and the UGTP with the GTP type of "GTPU only" or "BOTH GTPC and GTPU." Step 4 Execute DSP CHGFILE to query the CG hard disk to ensure that bills of the original protocol version do not exist.
Issue 02 (2007-12-30) Huawei Technologies Proprietary 3-33

3 Service Faults

HUAWEI SGSN9810 Serving GPRS Support Node Troubleshooting

Step 5 Remove the Ga interface configuration of the original protocol version. Step 6 Upgrade the CG protocol version. ----End

3.4.6 Great Difference Between Traffic in S-CDR Bill and Traffic Measured by MS
The traffic in the S-CDR bill differs substantially from the traffic measured by the MS. The difference rate is up to 30%.

Context
Possible Cause: The air interface resource is insufficient for a large amount of GPRS subscribers. Also, many logical link control (LLC) frames are lost and the PCU reports many LLC-DISCARD messages. But the lost bytes in LLC-DISCARD are not deducted from the PDP owing to protocol defects. Thus, the traffic in the S-CDR bill is greater than the traffic measured by the MS.

Procedure
This fault is caused by protocol defects. LLC-DISCARD does not carry NSAPI and thus cannot locate the PDP used by this subscriber through TLLI. Therefore, the LLC-DISCARD cannot deduct the PDP traffic.For most GPRS subscribers, if only one PDP is activated, the PDP traffic can be deducted forcibly. But the defects persist because the LLC-DISCARD does not know whether the data frame is lost or the signaling frame is lost. ----End

3.4.7 Empty MSISDN Field

The MSISDN field is empty in the generated R98 bill.

Context
Possible Cause: The bill protocol specification is wrongly configured.

Procedure
Maintenance personnel convert the GPRS bill version generated by the SGSN from R98 to R99 by configuring Ga interface parameter on the LMT. After the conversion, the CG does not support R99. The maintenance personnel then convert the bill version from R99 to R98 without changing the bill specification from GSM1215V760 to CMCCV130. Actually, the MSISDN field is not defined in the GSM1215V760 specification. Thus, the MSISDN information is unavailable for the generated bill. To remove this fault, change the R98 bill specification to CMCCV130, which supports the MSISDN information. ----End
3-34 Huawei Technologies Proprietary Issue 02 (2007-12-30)

HUAWEI SGSN9810 Serving GPRS Support Node Troubleshooting

3 Service Faults

3.4.8 Long-Conversation-Time Bills Exceeding the Time Threshold

The S-CDR bill does not generate bills according to the time threshold only from 3:00 to 4:00 every morning (the S-CDR bill is configured to generate bills according to the time threshold and traffic threshold). Thus, the S-CDR bill in the case of light traffic exceeds the time threshold.

Context
It is essential for the charging module of the UGTP to check the resource to ensure that the resource can be released normally. For the sake of system performance, the resource check is performed at midnight. To reduce the impact on traffic charging, the S-CDR bill is generated according to the traffic. Time-based charging is disabled.

Procedure
To locate the fault, check if the following command exists in the MML file: ADD RESCH: BT=UGTP, ST=4&0, MPID=173; The charging module of the UGTP checks the resource at 4:00 every morning. During the resource check, the charging module of the UGTP generates S-CDR bills only according to the traffic threshold to reduce the system load. Then, the function of generating bills according to the time threshold is disabled. The resource check lasts half an hour. After that, the S-CDR bills are generated according to the time threshold and traffic threshold as configured. ----End

3.4.9 Bills with Zero Time Length

The duration and traffic of an S-CDR bill are zero.

Context
The duration between the PDP context deactivation and the previous bill generation is less than 400 ms. Therefore, the duration of the latter bill is zero. This bill, however, cannot be combined with the previous bill because the cause of bill generation is different. This is a normal case.

Procedure
Step 1 Analyze bill files to ensure that the cause of closing this bill with the duration to be zero is Normal Release. This means that the bill is the last bill of the PDP context. Step 2 Analyze the previous bill to ensure that the cause of closing the previous bill is Volume Limit. This means that the traffic threshold is generated. After the bill is generated, the system traffic is zero. Step 3 During the short time after the previous bill is generated, the PDP context is deactivated (duration between the generation of the two bills does not exceed 400 ms). Thus, a bill with the following features is generated owing to round:
l l

Time length: zero Traffic: zero

Huawei Technologies Proprietary 3-35

Issue 02 (2007-12-30)

3 Service Faults
l

HUAWEI SGSN9810 Serving GPRS Support Node Troubleshooting

Closing cause: Normal Release

----End

3.4.10 S-CDR Bill Repetition

The two S-CDR bills of a subscriber have an overlap of 80 seconds.

Context
When an MS activates two or more PDP contexts, bills with time overlap are generated. This is a normal case.

Procedure
To locate and remove this fault, analyze the two S-CDR bills. The time in the two bills is overlapped, but the ChargingID in the two bills is different.An S-CDR bill is a bill of PDP context as defined in the 3GPP protocol 32.215 and 32.015. ChargingID identifies different PDP contexts.If one MS activates multiple PDP contexts, ChargingID determines whether these bills are in the same PDP context. The ChargingIDs of the two bills are different. Therefore, these two bills are in different PDP contexts for the same MS. ----End

3-36

Huawei Technologies Proprietary

Issue 02 (2007-12-30)