servicing tips for 3g nodes

3 Service Faults

About This Chapter

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

3.1 MS Attach FaultsThis section describes MS attach faults.

3.2 PDP Activation FaultsThis section describes the PDP activation faults.

3.3 RAU and Handoff FaultsThis section describes some RAU and handoff faults.

3.4 Bill FaultsThis section describes bill faults.

HUAWEI SGSN9810 Serving GPRS Support NodeTroubleshooting 3 Service Faults

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

3.1 MS Attach FaultsThis section describes MS attach faults.

3.1.1 Background Knowledge of MS AttachIn the GSM or UMTS packet switched (PS) domain, there are three attach procedures. GPRSattach, GPRS attach when the MS is already IMSI-attached , Combined GPRS and IMSI attach.

3.1.2 Failure to Receive the Attach RequestThe SGSN does not receive the Attach Request sent by a MS.

3.1.3 Attach Reject:GPRS Service not allowedUpon receiving an Attach Request sent by a MS, the SGSN sends an Attach Reject messagecarrying the cause value "GPRS service not allowed" to the MS.

3.1.4 Attach Reject:Illegal MSUpon receiving the Send Authentication Info Ack message sent by the HLR, the SGSN sendsan 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, orthe SGSN does not receive any Insert Subscriber Data message or Update Location Ack messagefrom the HLR. Therefore, the SGSN sends an Attach Reject message to the MS, carrying thecause 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 messagecarrying 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 onthe Gr interface, but the SGSN rejects this message carrying the cause value "protocol error."

3.1.8 Attach Reject:Other Cause ValuesUpon receiving an Update Location Ack message sent by the HLR, the SGSN sends an AttachReject 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, theSGSN sends an Attach Accept message carrying the cause value " mobile service switchingcenter (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 UpdateAccept)After sending a Location Update Request during a combined GPRS/IMSI attach, the SGSN doesnot receive a Location Update Accept message sent by the VLR. The SGSN sends an AttachAccept message carrying the cause value "MSC temporarily not reachable."

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

3.1.12 Gb Interface Parameters Inconsistency (2.5G)

3 Service FaultsHUAWEI SGSN9810 Serving GPRS Support Node

Troubleshooting

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

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 notreturn an Attach Complete message. The MS repeatedly sends AttachReq messages and theSGSN repeatedly sends AttachAcc messages.

3.1.13 Wrong Configuration of the Mutual Aid DPCAuthentication during the attach is normal. The MAP receives a P-ABORT message from thelower-layer protocol 30 seconds after the location update is initiated.

3.1.14 IMSI Not KnownDuring a location update, the HLR rejects the Attach Request sent by the MS with the causevalue "IMSI not known."

3.1.15 MS InaccessibleAll MSs in one cell cannot access the network or implement the GPRS services in a certainperiod. The Gb interface tracing or Ns interface tracing shows that the SGSN does not send anymessage to the MSs after receiving AttachReq messages from MSs. Forward and reversemessages are unavailable in the MS tracing.

3.1.16 Using Original PTMSI After SIM Card ChangeWhen you perform GPRS service using a MS without authentication, a fault occurs. After theattach using the SIM1 is complete, remove the battery and perform the attach using SIM2. Theattach 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 MSsAfter receiving an Attach Request sent by a MS, the SGSN does not respond, or the SGSN sendsan Attach Reject message carrying one of the following cause values before authentication.“protocol error”,“no suitable cell in this la”or“gprs service not allowed”.

3.1.18 APN Varying with MSsA MS succeeds in location update, but the SGSN sends an Attach Reject message immediatelycarrying either of the following cause values, “no suitable cells in la”or“gprs service notallowed”.

3.1.19 Restriction Location Area (Routing Area) Within the IMSI Number SegmentAfter the MS sends an Attach Request, the attach in some routing areas succeeds. But in somerouting areas, the SGSN, before initiating the authentication, sends an Attach Reject messagecarrying either of the following cause values,“la not allowed”or“gprs service not allowed”.

3.1.20 MS Authentication FailureThe 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 authenticationencryption failure message, carry one of the following cause values,“sync failure”, “macfailure”and“gsm authentication unacceptable”,After the SGSN re-initiates authentication, theauthentication 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 AttachIn the GSM or UMTS packet switched (PS) domain, there are three attach procedures. GPRSattach, GPRS attach when the MS is already IMSI-attached , Combined GPRS and IMSI attach.l GPRS attach



l GPRS attach when the MS is already IMSI-attached

l Combined GPRS and IMSI attach

The combined GPRS and IMSI attach is a typical procedure. Figure 3-1shows the combinedGPRS and IMSI attach procedure.

You can enable MS tracing or interface tracing on an LMT of the SGSN system to obtainsignaling messages of the attach procedures.

Figure 3-1 Combined GPRS and IMSI attach procedure

7d. Cancel LocationAck

7c. Cancel Location

7b. Update Location

7g. Update Location Ack

7e. Insert Subscriber Data

7f. Insert Subscriber DataAck

6d. Insert Subscriber Data 6c. Cancel Location Ack

6b. Cancel Location

3. Identity Response

2. Identification Response

2. Identification Request 1. Attach Request

5. IMEI Check

3. Identity Request

4. Authentication

6a. Update Location

7a. Location Update Request

7h. Location Update Accept

6f. Update Location Ack

6e. Insert Subscriber Data Ack

MSBSS/

UTRAN newSGSN old SGSN GGSN HLREIRold

MSC/ VLRnew

MSC/ VLR

9. Attach Complete

8. Attach Accept

10.TMSI Reallocation Complete

C1

Common Faults

The following are common MS attach faults:

l Failure to Receive the Attach Request

l GPRS Service Not Allowed

l Illegal MS

l No Response from HLR


Troubleshooting


l IMSI-GT Not Configured

l ODB Not Supported

l Other Cause Values

l Not Sending Location Update Request

l Failure to Receive a Location Update Accept

l Other attach failure: No Attach Complete message returned from the UE

l Gb Interface Parameters Inconsistency (2.5G)

l Wrong Configuration of Mutual Aid Between SCCP and DPC

l IMSI Not Known

l MS Inaccessible

l Using Original PTMSI After SIM Card Change

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

l APN Varying with MSs

l Restriction Location Area (Routing Area) Within the IMSI Number Segment

l MS Authentication Failure

l Encryption Failure (3G)

3.1.2 Failure to Receive the Attach RequestThe SGSN does not receive the Attach Request sent by a MS.

ContextPossible Cause:

l The Gb interface in the 2.5G network is faulty.

l The lu interface in the 3G network is faulty.

ProcedureRefer to 6 Iu Interface Faultsor 7 Gb Interface Faults.

----End

3.1.3 Attach Reject:GPRS Service not allowedUpon receiving an Attach Request sent by a MS, the SGSN sends an Attach Reject messagecarrying the cause value "GPRS service not allowed" to the MS.


l The MS is roaming and the public land mobile network (PLMN) to which it belongs is notconfigured as an interconnected PLMN in the SGSN.

l The subscriber is an mobile virtual network operator (MVNO) subscriber. The number ofMVNO subscribers currently attached in the system reaches the limit.



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 interconnectedPLMN.l If the configuration of the original interconnected PLMN is incorrect, execute MOD

CONNECTPLMN on the LMT to modify the configuration.l 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 systemand the system limit using LST MVNORES and DSP MVNOUSR. If the two numbers are thesame, it is necessary to expend the MVNO capacity.

----End

3.1.4 Attach Reject:Illegal MSUpon receiving the Send Authentication Info Ack message sent by the HLR, the SGSN sendsan Attach Reject message carrying the cause value "Illegal MS."


l The MS is unauthorized.

l The MS subscription data is wrong.

l The MS fails authentication because its authentication parameter is inconsistent with thatin the HLR.

Procedure

Step 1 Contact the HLR maintenance personnel to confirm the MS subscription data.If the MS isunauthorized, 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 fromHLR)

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


The Gr interface is faulty.


Troubleshooting


Procedure

Refer to 4 SS7 Interface Faultsfor details.

----End

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

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

Context

Possible Cause:

The global title (GT) code is unavailable for location update because the IMSI-GT table is notconfigured. 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 NotSupported)

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 onthe 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 accessthe 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 Contact the HLR personnel to cancel the ODB subscription.

l Change "ODB support" to "ODB not support" in the MAPFUNC table of the SGSN.

----End



3.1.8 Attach Reject:Other Cause ValuesUpon receiving an Update Location Ack message sent by the HLR, the SGSN sends an AttachReject 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 causevalues.

Table 3-1 Possible causes for attach reject

Cause Value Possible Causes

Illegal MS l The MS is not defined in the HLR.

l The authentication fails.

PLMN not allowed l The MS is prohibited to access the visitedPLMN (VPLMN).

l The MS is in ODB status.

l The MS is barred in the HLR.

Location Area not allowed The non-roaming MS is prohibited to attachin the location area specified by a zone code(ZC).

Roaming not allowed in this location area(LA)

The roaming MS is prohibited to attach in thelocation area specified by a ZC.

Procedure

Step 1 contact the HLR maintenance personnel to confirm the MS subscription data.If the MS isunauthorized, 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 SendingLocation Update Request)

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

Context

Possible Cause:


Troubleshooting


l Visitor location register (VLR) information is unavailable.

l The correspondence between the VLR and location area identification (LAI) is incorrect.

ProcedureStep 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 improperlyconfigured, execute MOD VLR to modify the configuration or ADD VLR to add the VLRconfiguration.

Step 3 Execute LST LAIVLR on the LMT to check if the correspondence between the LAI and theVLR is correct.

Step 4 If the correspondence between the LAI and the VLR is incorrect, do the following: ExecuteADD LAIVLR to add an RAI-VLR correspondence.Execute RMV LAIVLR to remove thewrong correspondence, and then execute ADD LAIVLR to add an RAI-VLR correspondence.

----End

3.1.10 Attach Accept:MSC temporarily not reachable(Failure toReceive a Location Update Accept)

After sending a Location Update Request during a combined GPRS/IMSI attach, the SGSN doesnot receive a Location Update Accept message sent by the VLR. The SGSN sends an AttachAccept message carrying the cause value "MSC temporarily not reachable."


The Gs interface is faulty.

ProcedureRefer to4 SS7 Interface Faultsfor details.

----End

3.1.11 Other attach failure: No Attach Complete message returnedfrom the UE

During a 3G attach, the SGSN has sent the Attach Accept message to the UE and assigned anew PTMSI to that UE, however the UE does not return the Attach Complete message as statedin the protocol. Therefore, the UE keeps sending AttachReq messages and the SGSN keepssending AttachAcc messages, so the packet services of the UE cannot be carried out.


The 3G attach requires encryption. The SGSN however does not initiate the authenticationencryption procedure or the SGSN initiates an authentication encryption procedure whichindicates that the encryption is not required.



ProcedureCheck the authentication flag and encryption flag using LST PMM and LST3GAUTHCIPH. If the flags are off, enable the authentication and encryption functions for thatsubscriber 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/MOD3GAUTHCIPH 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 notreturn an Attach Complete message. The MS repeatedly sends AttachReq messages and theSGSN repeatedly sends AttachAcc messages.


The Gb interface parameters on the SGSN and those on the PCU are inconsistent.

ProcedureRefer to 7 Gb Interface Faults.

----End

3.1.13 Wrong Configuration of the Mutual Aid DPCAuthentication during the attach is normal. The MAP receives a P-ABORT message from thelower-layer protocol 30 seconds after the location update is initiated.


The mutual aid DPC configuration is wrong.

ProcedureThe signaling point of the mutual aid DPC in the SCCP DPC table does not reaches thedestination normally.Thus, when the SCCP performs load sharing, there is response to thesignaling sent to the main signaling point but no response to the signaling sent to the mutual aidDPC.

----End

3.1.14 IMSI Not KnownDuring a location update, the HLR rejects the Attach Request sent by the MS with the causevalue "IMSI not known."


Troubleshooting


Context

Possible Cause:

l The MS is unauthorized and is not defined in the HLR.

l The IMSIGT or SCCPGT table is wrongly configured. The MSs in the HLR1 are configuredinto HLR2.

Procedure

To locate and remove the fault, contact the HLR maintenance personnel for help. If the HLR iscorrectly configured, add the subscription information into the HLR.

----End

3.1.15 MS InaccessibleAll MSs in one cell cannot access the network or implement the GPRS services in a certainperiod. The Gb interface tracing or Ns interface tracing shows that the SGSN does not send anymessage to the MSs after receiving AttachReq messages from MSs. Forward and reversemessages 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 SGSNdiscards the MS message capsule directly.

Procedure

Step 1 Execute DSP PTPBVC to check if the cell receives the flow control message.If the cell receivesno flow control message, reset the cell to allow the PCU to report the cell flow control messageagain.

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 ChangeWhen you perform GPRS service using a MS without authentication, a fault occurs. After theattach using the SIM1 is complete, remove the battery and perform the attach using SIM2. Theattach 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 isreplaced, the MS-originated PTMSI attach uses the PTMSI in the MS rather than the PTMSIsaved in the SIM card. Thus, the MS with the wrong PTMSI accesses the SGSN.



Procedure

To remove the fault, enable the authentication function.

----End

3.1.17 IMSI Number Segment Varying with 2G and 3G MSsAfter receiving an Attach Request sent by a MS, the SGSN does not respond, or the SGSN sendsan Attach Reject message carrying one of the following cause values before authentication.“protocol error”,“no suitable cell in this la”or“gprs service not allowed”.

Context

Possible Cause:

l The MS property is configured according to the IMSI number segment, but the resourcetype of the USPU is not configured correctly.

l The MS property is configured according to the IMSI number segment, but the GPRSsubscriber cannot access the UMTS network according to the configuration in the servicefunction table.

Procedure

Step 1 The attach request may be discarded or there is no response in one of the following cases:TheMS 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 networkaccording to the configuration in the service function table.

When accessing the UMTS network, this MS is rejected with the cause value "no suitable cellin this LA." If a value change takes place, the cause value may change to "gprs service notallowed."

----End

3.1.18 APN Varying with MSsA MS succeeds in location update, but the SGSN sends an Attach Reject message immediatelycarrying either of the following cause values, “no suitable cells in la”or“gprs service notallowed”.

Context

Possible Cause:

The MS access function based on the access point name (APN) is enabled in the service extensiontable. But no APN is configured or a wrong APN is configured.


Troubleshooting


ProcedureTo locate and remove the fault, check if there is an intersection between the APNs of the PLMNon the APNNI list and the APNs that the MS subscribes to.

----End

3.1.19 Restriction Location Area (Routing Area) Within the IMSINumber Segment

After the MS sends an Attach Request, the attach in some routing areas succeeds. But in somerouting areas, the SGSN, before initiating the authentication, sends an Attach Reject messagecarrying either of the following cause values,“la not allowed”or“gprs service not allowed”.


The IMSI is configured in the restriction location area table and the IMSI of this MS is withinthe restriction number range.

Procedure

Step 1 Check the IMSI of the MS that initiates the attach is configured in the restriction location areatable.

Step 2 There is an intersection between the restriction location area or routing area and the routing areaof the MS currently attached.

----End

3.1.20 MS Authentication FailureThe 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 authenticationencryption failure message, carry one of the following cause values,“sync failure”, “macfailure”and“gsm authentication unacceptable”,After the SGSN re-initiates authentication, theauthentication sometimes fails.


l The authentication set defined in the HLR is wrong.

l The authentication set of the SGSN does not match that of the MS. The attach may succeedafter you re-obtain the authentication set.

l An unauthorized MS uses the IMSI for attach. The authentication fails.

ProcedureTo locate and remove the fault, check that the authentication set of the MS is correct.

----End



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


The configuration of the encryption algorithm is wrong.

ProcedureThere is no an intersection between UEA0 or UEA1 algorithm and circuit switched (CS)algorithm because only UEA0 or EA1 algorithm is configured. Therefore, the encryptionallocation fails. To remove this fault, configure both the UEA0 algorithm and the UEA1algorithm.

----End

3.2 PDP Activation FaultsThis section describes the PDP activation faults.

3.2.1 Background Knowledge of PDP ActivationBefore you use the PS service, the PDP activation procedure needs to be initiated.

3.2.2 Failure to Receive the Activate PDP Context RequestThe SGSN does not receive any Activate PDP Context Request sent by a MS.

3.2.3 Requested Service Option Not Subscribed Case IAfter receiving an Activate PDP Context Request, the SGSN sends an Activate PDP ContextReject message carrying the cause value "requested service option not subscribed."The sessionmanagement (SM) rejects the mobility management (MM) activation request. The domain nameservice (DNS) resolution request from the SM to the GTP is unavailable in the internal tracingof SM (PID = 29).

3.2.4 Requested Service Option Not Subscribed Case IIUpon receiving a PDP Activation Request sent by a MS, the SGSN sends an Activate PDPContext Reject message carrying the No.33 cause value "requested service option notsubscribed." Execute DSP USPUPDP to check if the APN in the subscribed PDP is the same asthat in the PDP Activation Request.

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

3.2.6 Activate PDP Context Reject:Protocol error unspecifiedAfter initiating the radio access bearer (RAB) assignment procedure, the SGSN receives no RABAssignment Response or receives an RAB Assignment Response indicating the RAB assignmentfailure. 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 GGSNThe SGSN sends an Activate PDP Context Reject message to the MS carrying the cause value"Activation rejected by GGSN."


Troubleshooting


3.2.8 Activate PDP Context Reject:User Authentication failedAfter the GGSN responds with a Create PDP Context Response, the SGSN sends an ActivatePDP Context Reject message carrying the cause value "User Authentication failed."

3.2.9 Activate PDP Context Reject:Operator Determined BarringThe 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 supportedUpon receiving a Create PDP Context Response, the GGSN sends an Activate PDP ContextReject message to a MS carrying the cause value "Service option not supported."

3.2.11 Activate PDP Context Reject:Insufficient resourcesUpon sending a Create PDP Context Request, the SGSN sends an Activate PDP Context Rejectmessage carrying the No.26 cause value "Insufficient resources." A Create PDP ContextResponse sent from the GGSN may appear in the user tracing.

3.2.12 GTP-C Path FaultyAfter a 2G MS activates a PDP context, the SGSN immediately initiates the PDP deactivation.

3.2.13 Improper Counter Setting in GTP VersionTo verify the APN, the PDP context activation test is performed in multiple GGSNs. The initialPDP 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 SucceedsAfter the activation succeeds, only the reverse packet is available. The MS initiates thedeactivation automatically.

3.2.1 Background Knowledge of PDP ActivationBefore 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.5Gcommunication system. Figure 3-3illustrates the procedure for MS-originated PDP contextactivation in the 3G communication system.

You can obtain the signaling message of the PDP activation procedure by enabling a MS tracingor interface tracing on an LMT.

Figure 3-2 PDP context activation procedure in 2.5G

2G-GGSN

7. Activate PDP Context Accept

5. Create PDP Context Response

4. Create PDP Context Request

1. Activate PDP Context Request

2G-SGSNBSS

2. Security Functions

MS

6. BSS Packet Flow Context Procedures

C1

C2

3. Invoke Trace



Figure 3-3 PDP context activation procedure in 3G

3G-GGSN

8. Activate PDP Context Accept

3. Create PDP Context Response

2. Create PDP Context Request

1. Activate PDP Context Request

3G-SGSNUTRANMS

4. Radio Access Bearer Setup

C1

C2

5. Invoke Trace

7. Update PDP Context Response

6. Update PDP Context Request

Common Faults

Common PDP activation faults include:

l Failure to Receive the Activate PDP Context Request

l Requested Service Option Not Subscribed Case I

l Requested Service Option Not Subscribed Case II

l Missing or Unknown APN

l Protocol Error Unspecified

l Activation Rejected by GGSN

l User Authentication Failure

l Requested Service Option Not Subscribed

l Operator Determined BarringService Option Not Supported

l Insufficient Resources

l GTP-C Path Faulty

l Improper Counter Setting in GTP Version

l Forward Packet Unavailable After Activation Succeeds

3.2.2 Failure to Receive the Activate PDP Context RequestThe SGSN does not receive any Activate PDP Context Request sent by a MS.



Troubleshooting


l The Gb interface in the 2.5G network is faulty.

l The lu interface in the 3G network is faulty.

ProcedureRefer to 6 Iu Interface Faultsor 7 Gb Interface Faultsfor details.

----End

3.2.3 Requested Service Option Not Subscribed Case IAfter receiving an Activate PDP Context Request, the SGSN sends an Activate PDP ContextReject message carrying the cause value "requested service option not subscribed."The sessionmanagement (SM) rejects the mobility management (MM) activation request. The domain nameservice (DNS) resolution request from the SM to the GTP is unavailable in the internal tracingof SM (PID = 29).


l A mismatch of the triplet—PDP address type, PDP address, and APN occurs.

l The subscribed quality of service (QoS) in the PDP is invalid.

l A roaming MS cannot enable the PDP according to the configuration in the interconnectionPLMN table.

l A roaming MS cannot enable the PDP according to the configuration in the billingparameter table.

ProcedureStep 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 mismatchoccurs, 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-activatedmessage.

Step 2 Check if the invalid value is available in the subscribed QoS in the HLR by comparing the validvalue 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 extensionQoS 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 activatedin the interconnection PLMN table. If it is not allowed, execute ADD CONNECTPLMN toactivate 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 toactivate 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 toactivate the PDP.

----End



3.2.4 Requested Service Option Not Subscribed Case IIUpon receiving a PDP Activation Request sent by a MS, the SGSN sends an Activate PDPContext Reject message carrying the No.33 cause value "requested service option notsubscribed." Execute DSP USPUPDP to check if the APN in the subscribed PDP is the same asthat in the PDP Activation Request.


The APN in the subscribed PDP has implicit characters. The characters in the APN must beexplicit american standard code for information interchange (ASCII) characters, as defined inthe protocol. The valid value range is as follows:

l "0" to "9"

l "a" to "z"

l "A" to "Z"

l "-"

The coding form is length + value (LV).

For example, the hexadecimal codes of APN = huawei1.com in the Activation Request messageare 07 68 75 61 77 65 69 31 03 63 6f 6d.

Table 3-2lists the code descriptions.

Table 3-2 Code description

Code Description

07 The length of the first section of APN

68 75 61 77 65 69 31 "huawei1"

03 The length of the second section of APN

63 6f 6d "com"

If you add an implicit space at the end when editing APN on a MS, the codes are 07 68 75 6177 65 69 31 04 63 6f 6d 20.

Table 3-3 lists the code description.

Table 3-3 Code description

Code Description

07 The length of the first section of APN

68 75 61 77 65 69 31 "huawei1"

04 The length of the second section of APN


Troubleshooting


Code Description

63 6f 6d 20 "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 PDPActivation Request are correct.

----End

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

Context

Possible Cause:

l DNS resolution fails and the IP address of the GGSN is unavailable.

l The APN OI is not configured in the 2GSM or 3GSM configuration table.

l The GGSN prompts that the APN is faulty.

l The PDP cannot use the APN OI of the VPLMN in the subscription.

l The GGSN address that supports the dynamic host configuration protocol (DHCP) andmobile 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 DSNresolution request. Check if the GGSN address corresponding to the APN is correctlyconfigured. If it is wrong, execute ADD IPV4DNSH on the LMT to configure the GGSN addressin the DNSH table.If the DNS does not respond, check and repair the link from the SGSN to theDNS. 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 theSGSN carrying the cause value "Missing or unknown APN." In this case, modify theconfiguration 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 VPLMNAddress Allowed to YES.

Step 4 If the MS initiates PDP activation in the DHCP or MIP mode, it obtains the IP address of theGGSN through the SGSN configuration rather than the DNS resolution. If the IP address of theGGSN is not configured in the SGSN, the MS cannot obtain the IP address of the GGSN. Thecause value is "Missing or unknown APN." To remove the fault, execute ADD DHCPGIP to



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

----End

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


The RNC does not respond correctly to the RAB assignment request from the SGSN.

ProcedureContact the RNC maintenance personnel to locate the RAB assignment failure.

----End

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


l The GGSN responds with a failure message.

l The GGSN response timed out.

l The response from the GGSN is wrongly coded.

ProcedureIf 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 thefailure cause value in the Create PDP Context Response. If the GGSN responds with a CreatePDP Context Response carrying the success cause value, the coding of the GGSN responsemessage is incorrect. Check if the message contains the necessary IEs or the mandatoryinformation element (IE) value is correct. In this case, the GGSN personnel need to locate thefault.If the GGSN does not respond and the activation is rejected 30 seconds later, you can inferthat the link from the SGSN to GGSN is blocked. For details, refer to5 Gn/Gp/Ga InterfaceFaults

----End

3.2.8 Activate PDP Context Reject:User Authentication failedAfter the GGSN responds with a Create PDP Context Response, the SGSN sends an ActivatePDP Context Reject message carrying the cause value "User Authentication failed."


Troubleshooting



l The authentication between the GGSN and the authentication, authorization and accounting(AAA) server fails.

l The tunnel between the GGSN and the AAA server is blocked.

ProcedureThe GGSN sends a Create PDP Context Response carrying the No.29 cause value "UserAuthentication failed." The authentication function is enabled in the GGSN, but the PDPactivation is rejected owing to authentication failure. In this case, ask the GGSN personnel toremove the fault.

----End

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


l If the MS subscribes to All Packet Switch Services Barred in the HLR, the MS cannotactivate the PDP in the home PLMN (HPLMN) or VPLMN.

l If the MS subscribes to VPLMN AP Access Barred when defined in the HLR, the MScannot activate the PDP using APN OI of VPLMN while attaching to VPLMN.

l If the MS subscribes to HPLMN AP Access Barred when defined in the HLR, the MScannot activate the PDP using APN OI of HPLMN when attaching to VPLMN.

ProcedureTo 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 versionand ODB is supported in the MAP function list.

----End

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




l License restriction on the activation in the point-to-point protocol (PPP), MIP, or IPV6mode

l 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 inthe 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 thecompatibility configuration table.

Step 5 Execute SET COMPATIBILITY to change the restriction on the number of PDPs activatedby the wild card to OFF.

----End

3.2.11 Activate PDP Context Reject:Insufficient resourcesUpon sending a Create PDP Context Request, the SGSN sends an Activate PDP Context Rejectmessage carrying the No.26 cause value "Insufficient resources." A Create PDP ContextResponse sent from the GGSN may appear in the user tracing.


l Resource request failure

l License restriction

l PDP resource congestion of the USPU

l Center processing unit (CPU) congestion of the UGBI

l PDP resource congestion of the UGBI

l Charging restriction

l 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 resourcecongestion 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.


Troubleshooting


Step 7 Execute SET CHGCHAR to change the charging restriction icon in the parameter table of thecharging property to disable this function. If the charging restriction is enabled, the subscriberdata service of certain charging property is restricted when the bill cache is full. Thus, theactivation 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 resultingin the activation failure. You can use the LST BRD command to check the configuration of theUGTP board. If only the GTP-C function is configured, you can use the command ADD BRDor MOD BRD to tune the data configuration.

----End

3.2.12 GTP-C Path FaultyAfter a 2G MS activates a PDP context, the SGSN immediately initiates the PDP deactivation.


After the SGSN sends a PDP ACT ACCEPT message to the MS, the subnetwork dependentconvergence protocol (SNDCP) link must be set up between the UGBI and the MS to notify theUGFU 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 planeis disrupted or faulty, the activation procedure fails.

Thus, the SGSN initiates PDP deactivation after sending the PDP ACT ACCEPT message.

ProcedureCheck if the path on the data plane is normal or repaired.Enable the echo probe on the data planein the GUPPUB table.

----End

3.2.13 Improper Counter Setting in GTP VersionTo verify the APN, the PDP context activation test is performed in multiple GGSNs. The initialPDP context activation of some GGSNs fails. Later activations are normal. The APN is "test.sd"and "test.bj".


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 sendsa message of GTPV0 to the peer node. Meanwhile, the SGSN sends an Activation Reject



message to the MS. If the session management (SM) does not receive response from the peernode, 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. Toreduce 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 firstCREATE_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 GTPV1and that of the fourth message is GTPV0. This indicates that the peer node has responded andthe PDP activation has succeeded.

The SGSN sends the CREATE_PDP_CONTEXT_REQUEST message to the peer node fivetimes consecutively, but the peer node does not respond. At the sixth time, the peer node sendsa 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 isin use for the sixth time. This is because the GTP protocol of the 3G protocol is the GTPV1version and is compatible with the GTPV0 version. Therefore, the following version negotiationprocedure 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 deletedto avoid version upgrade of the peer node.

Therefore, after the activation using "test.sd" succeeds, the next activation uses the saved versioninformation 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 SucceedsAfter the activation succeeds, only the reverse packet is available. The MS initiates thedeactivation automatically.


The Gi interface of the GGSN is blocked.

ProcedureTo remove the fault, contact the GGSN maintenance personnel for help.

----End

3.3 RAU and Handoff FaultsThis section describes some RAU and handoff faults.

3.3.1 Background Knowledge of RAU and Handoff


Troubleshooting


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 relocationprocedure (hard handoff) ,Relocation procedure for combined cell update or RAU update.

3.3.2 Failure to Send Inter-SGSN RAUThe MS initiates the inter-SGSN RAU. The SGSN sends an RAU REJ message carrying thecause value "Implicit detach."

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

3.3.4 Relocation Procedure FailureRelocation is a complex procedure. The relocation often fails during interconnection with theequipment of other vendors.

3.3.1 Background Knowledge of RAU and HandoffThe RAU procedure is the same as the attach procedure. Relocation procedure consists of:Serving SRNS relocation procedure (soft handoff) ,Combined hard handoff and SRNS relocationprocedure (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 Knowledgeof MS Attachfor details.

Relocation procedure consists of:

l Serving SRNS relocation procedure (soft handoff)

l Combined hard handoff and SRNS relocation procedure (hard handoff)

l 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.



Figure 3-4 3G soft handoff procedure

T3-TUNNEL

B C

A

MS TargetRNC

SourceRNC

OldSGSN

NewSGSN

GGSN

3. Forward Relocation Request

4. Relocation Request

2. Relocation Required

6. Relocation Command

5. Forward Relocation Response

4. Relocation Request Acknowledge

9. Relocation Detect

13. Relocation Complete

13. Forward Relocation Complete

10. RNTI Reallocation

12. RNTI Reallocation Complete

Establishment of Radio Access Bearers

15. Routing Area Update

11. Update PDP Context Request

14. Iu Release Command

14. Iu Release Complete

C1

C2

7. Relocation Commit

8. Forwarding of data

11. Update PDP Context Response

D

SRNS relocation1. Decision to perform

The 3G soft handoff procedure is as follows:

1. The source RNC initiates SRNS relocation.2. 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 TransparentContainer includes the necessary information of relocation coordination, security functionality, andradio resource control (RRC) protocol context.

3. The old SGSN determines whether the SRNS relocation is an intro-SGSN SRNS relocationor inter-SGSN SRNS relocation. In the case of inter-SGSN SRNS relocation, the old SGSNinitiates the relocation resource allocation procedure by sending a Forward RelocationRequest message (IMSI, Tunnel Endpoint Identifier Signaling, MM Context, PDP Context,Target Identification, UMTS terrestrial radio access network (UTRAN) transparentcontainer, and radio access network application part (RANAP) Cause). Meanwhile, a timeris started. The Forward Relocation Request message is applicable only to the inter-SGSNSRNS relocation.

4. 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,


Troubleshooting


RABs to be setup) to the target RNC.For each requested RAB, RABs To Be Setup includesinformation such as RAB ID, RAB parameters, Transport Layer Address, and Iu TransportAssociation. 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.l The RAB parameters information provides the QoS profile.

l The Transport Layer Address is the SGSN address for user data.

l Iu Transport Association corresponds to the uplink tunnel endpoint identifier data(TEID).

5. After all necessary resources for accepted RABs, including the Iu user plane, aresuccessfully 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 PDUsfrom the source SRNC and the new SGSN for each RAB to be set up.

6. When the resource for the transmission of user data between the new SGSN and the targetRNC is allocated, and the new SGSN is ready for the SRNS relocation, the new SGSNsends the Forward Relocation Response (Cause, RANAP Cause, and Target RNCInformation) to the old SGSN. This message indicates that the target RNC is ready to receivethe forwarded downlink packets from the source SRNC. The RAB Setup Information, oneinformation element for each RAB, contains the RNC TEID and RNC IP address for dataforwarding from the source SRNC to the target RNC.

7. The old SGSN continues the relocation of SRNS by sending a relocation command (RABsto be released and RABs subject to data forwarding) message to the source SRNC. The oldSGSN decides the RABs subject to data forwarding based on QoS and those RABs are tobe included in the RABs subject to data forwarding.For each RAB subject to dataforwarding, the information element unit includes RAB ID, Transport Layer Address, andIu Transport Association.Transport Layer Address and Iu Transport Association are usedfor forwarding of downlink N-PDU from the source SRNC to the target RNC.

8. Upon receiving the Relocation Command from the PS domain, the source RNC initiatesthe data forwarding timer. Upon completion of the relocation, the source RNC is ready totrigger the SRNS relocation by sending a Relocation Commit message (SRNS contexts) tothe target RNC. The purpose of this procedure is to transfer the SRNS context from thesource RNC to the target RNC.The SRNS contexts include:l The sequence number of the next GTP-PDUs to be sent on the reverse and forward

links.l 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 datafor the RABs to be subject for data forwarding. The data is forwarded through the Iuinterface during the SRNS relocation. This means that the GTP-PDUs exchanged betweenthe source RNC and the target RNC are duplicated in the source RNC and routed at the IPlayer toward the target RNC.

10. The target RNC sends a Relocation Detect message to the new SGSN when the relocationexecution trigger is received. When the Relocation Detect message is sent, the target RNCstarts SRNC operation.

11. After sending the Relocation Detect, the source RNC sends an RNTI Reallocation messageto the MS, including UE information elements and CN information elements.The UEinformation elements include new SRNC identity and S-RNTI. The CN information



elements include routing area identification (RAI) and LAI. The procedure is coordinatedin all Iu signaling connections existing for the MS.

12. Upon receiving the Relocation Detect, the CN switches the user plane from the source RNCto the target RNC. If the SRNS Relocation is an inter-SGSN SRNS relocation, the newSGSN sends an Update PDP Context Request message (new SGSN address, SGSN tunnelendpoint identifier, QoS negotiated) to the GGSNs concerned. The GGSN updates the PDPcontext and returns an Update PDP Context Response message (GGSN Tunnel EndpointIdentifier).

13. Upon completing the reassignment, the MS sends an RNTI Reallocation Complete messageto the target RNC and then, the packet switch with the MS begins.

14. When the target RNC receives the RNTI Reallocation Complete message indicating thatthe SRNC¬-ID+S RNTI are successfully exchanged with the MS through the radioprotocols, the target RNC initiates the Relocation Complete procedure by sending theRelocation Complete message to the new SGSN. The purpose of the Relocation Completeprocedure is to indicate by the target RNC the completion of the SRNS relocation to theCN.

l Upon receiving the Relocation Complete message, the CN switches the user plane fromthe source RNC to the target RNC.

l If the SRNS Relocation is an inter-SGSN SRNS relocation, the new SGSN sends aForward Relocation Complete message to the old SGSN to notify it of the completionof the SRNS relocation.

15. Upon receiving Relocation Complete or Forward Relocation Complete during the inter-SGSN 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 IuRelease Complete.

16. If the new RAI is different from the old one after the MS completes RNTI relocation, theMS initiates routing area (RA) update procedure, which is only a subset of RA updatebecause the MS operates in the PMM-CONNECTED mode.

Common Faults

The following are common faults of RAU and handoff:

l Failure to Send Inter-SGSN RAU

l CS Paging Failure

l Relocation Procedure Failure

3.3.2 Failure to Send Inter-SGSN RAUThe MS initiates the inter-SGSN RAU. The SGSN sends an RAU REJ message carrying thecause value "Implicit detach."

Context

Possible Cause:

l DNS configuration faults

l Peer faults

l Configuration faults


Troubleshooting


ProcedureStep 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 ADDIPV4DNSH on the LMT. If the data configuration is correct, you can infer that the fault maybe 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 ContextResponse 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 FailureDuring the combined GPRS/IMSI attach with the MS network mode 1, the MSC initiates apaging, the SGSN responds with a MOBILE STATUS message carrying the cause value"Mandatory IE Error."


The VLR number in the CS paging message from the MSC to the SGSN is not configured inthe VLR table of the SGSN.

ProcedureUpon receiving the CS paging, the SGSN checks the VLR number. If the SGSN does not findthe VLR number in the VLR configuration table, the SGSN responds with a Mandatory IE Errormessage because the VLR number is a mandatory information element in the CS paging.Wrongconfiguration at the MSC/VLR side causes this fault. Ask MSC/VLR personnel to remove thisfault.

----End

3.3.4 Relocation Procedure FailureRelocation is a complex procedure. The relocation often fails during interconnection with theequipment of other vendors.


l During the inter-SGSN relocation, the old SGSN queries the DNS configuration throughthe TRNC specified by the SRNC to obtain the new SGSN address. If the query fails, the



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 theRAU. Otherwise, the SGSN detaches the MS for the sake of resource protection.

l After receiving a RELOC REQUIRED message sent from the SRNC, the SGSN sends aRELOC PREPARE FAIL message and releases the SCCP connection. Inconsistency of theRNC protocol version and SGSN protocol version causes coding and encoding failure, thusresulting in relocation failure.

l The cell format of the Gn interface causes internal relocation procedure failure.

l After the relocation with the routing area changed is complete, the MS must initiate theRAU. Otherwise, the SGSN detaches the MS for the sake of resource protection. In somecases, however, the MS initiates the RAU before the new RNC sends a RELOCCOMPLETE message. Thus, the RAU is discarded.

Procedure

Step 1 If the DNS configuration is wrong, add the DNS configuration on the DNS server or executeADD 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 RNCand adjust the software parameters.

Step 4 If the cell format of the Gn interface has an error, confirm the protocol versions supported bythe RNC and adjust the software parameters.

Step 5 RAU message discard is caused by wrong data configuration at the AN side. Contact the ANpersonnel for help.

----End

3.4 Bill FaultsThis section describes bill faults.

3.4.1 Background Knowledge of BillThe billing system consists of the following three modules:USPU module、UGTP module、UCDR module.

3.4.2 Short-Conversation-Time BillsThe GPRS billing is incorrect because 67 bills are generated in four seconds (from 16:05:09 to16:05:13 on Jan, 18).

3.4.3 Bills with Zero TrafficTraffic 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 ThresholdYou can set the time threshold and traffic threshold in the partial S-CDRs. After you set thetraffic threshold, the traffic in the generated partial S-CDRs is larger than the threshold.

3.4.5 Useless Bill Remaining in the UCDRThe R98 bills on the UCDR cannot be removed, and the hard disk cannot be formatted. Toupgrade the bill protocol version of Ga interface to R99, engineers in this office disconnect theGa interface and modify the configuration of the SGSN and CG.


Troubleshooting


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

3.4.7 Empty MSISDN FieldThe MSISDN field is empty in the generated R98 bill.

3.4.8 Long-Conversation-Time Bills Exceeding the Time ThresholdThe S-CDR bill does not generate bills according to the time threshold only from 3:00 to 4:00every morning (the S-CDR bill is configured to generate bills according to the time thresholdand traffic threshold). Thus, the S-CDR bill in the case of light traffic exceeds the time threshold.

3.4.9 Bills with Zero Time LengthThe duration and traffic of an S-CDR bill are zero.

3.4.10 S-CDR Bill RepetitionThe two S-CDR bills of a subscriber have an overlap of 80 seconds.

3.4.1 Background Knowledge of BillThe billing system consists of the following three modules:USPU module、UGTP 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 (M-CDR), SGSN delivered short message mobile originated – CDR (S-SMO-CDR), andSGSN delivered short message mobile terminated – CDR (S-SMT-CDR), andgenerating semi-finished M-CDR, S-SMO-CDR, and S-SMT-CDR.

– Receiving the message of querying user charging and customized applications formobile network enhanced logic (CAMEL) charging information from the UGFU andsending the query result to the UGTP.

– Transferring CAMEL traffic measurement information between the in-switchingmanager(INSM) and the UGTP.

– Sending all semi-finished M-CDR, S-SMO-CDR, and S-SMT-CDR to the UCDR.

l UGTP module (in the UGTP board with the GTP type of "GTPU only" and "GTPC andGTPU both")


– Collecting PDP context charging information, and generating semi-finished S-CDR andsending it to the UCDR.

– Receiving the CAMEL traffic measurement command transferred from the USPU andmeasuring CAMEL user data traffic information, which is sent to the INSM throughthe USPU.

l UCDR module (in the UCDR board)


– 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 fromthe USPU and UGTP.



– Sending the semi-finished S-CDR, M-CDR, S-SMO-CDR, and S-SMT-CDR sent fromthe 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 allCGs is interrupted and sending these bills to the CG after the communication becomesnormal.

Common Faults

The following are common faults of billing:

l Short-Conversation-Time Bills

l Bills with Zero Traffic

l Traffic in the Generated Partial Bill Larger Than the Traffic Threshold

l Useless Bill Remaining in the UCDR

l Great Difference Between Traffic in S-CDR Bill and Traffic Measured by MS

l Empty MSISDN Field

l Long-Conversation-Time Bills Exceeding the Time Threshold

l Bills with Zero Time Length

l S-CDR Bill Repetition

3.4.2 Short-Conversation-Time BillsThe GPRS billing is incorrect because 67 bills are generated in four seconds (from 16:05:09 to16:05:13 on Jan, 18).


l Extremely heavy traffic affects the MS.

l The MS activates the third and fourth services, but the GGSN in the PS domain does notcontrol the traffic of the third and fourth services. Thus, heavy traffic affects the SGSNdirectly.

Procedure

Step 1 Check the Gb traffic statistics to analyze the packet loss ratio. If the packet loss ratio is veryhigh, 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 themaximum rate of the GPRS service, it proves that extremely heavy traffic affects the SGSN.

----End

3.4.3 Bills with Zero TrafficTraffic in an S-CDR bill keeps as zero for a long time.



Troubleshooting


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

ProcedureTo locate and remove the fault, create a user tracing task and measure the traced packets toconfirm 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 beenzero 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 TrafficThreshold

You can set the time threshold and traffic threshold in the partial S-CDRs. After you set thetraffic threshold, the traffic in the generated partial S-CDRs is larger than the threshold.


The UGFU measures traffic based on packets.

ProcedureThe forward engine of the UGFU measures the traffic according to the length of the transmittedpackets. The length of one packet is larger than 1 KB. Therefore, the traffic measured may exceedthe 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 UCDRThe R98 bills on the UCDR cannot be removed, and the hard disk cannot be formatted. Toupgrade the bill protocol version of Ga interface to R99, engineers in this office disconnect theGa interface and modify the configuration of the SGSN and CG.


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 andGTPU."

Step 4 Execute DSP CHGFILE to query the CG hard disk to ensure that bills of the original protocolversion do not exist.



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 TrafficMeasured by MS

The traffic in the S-CDR bill differs substantially from the traffic measured by the MS. Thedifference rate is up to 30%.

Context

Possible Cause:

The air interface resource is insufficient for a large amount of GPRS subscribers. Also, manylogical 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 cannotlocate the PDP used by this subscriber through TLLI. Therefore, the LLC-DISCARD cannotdeduct the PDP traffic.For most GPRS subscribers, if only one PDP is activated, the PDP trafficcan be deducted forcibly. But the defects persist because the LLC-DISCARD does not knowwhether the data frame is lost or the signaling frame is lost.

----End

3.4.7 Empty MSISDN FieldThe 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 R99by configuring Ga interface parameter on the LMT. After the conversion, the CG does notsupport R99. The maintenance personnel then convert the bill version from R99 to R98 withoutchanging the bill specification from GSM1215V760 to CMCCV130. Actually, the MSISDNfield is not defined in the GSM1215V760 specification. Thus, the MSISDN information isunavailable for the generated bill. To remove this fault, change the R98 bill specification toCMCCV130, which supports the MSISDN information.

----End


Troubleshooting


3.4.8 Long-Conversation-Time Bills Exceeding the Time ThresholdThe S-CDR bill does not generate bills according to the time threshold only from 3:00 to 4:00every morning (the S-CDR bill is configured to generate bills according to the time thresholdand traffic threshold). Thus, the S-CDR bill in the case of light traffic exceeds the time threshold.

ContextIt is essential for the charging module of the UGTP to check the resource to ensure that theresource can be released normally.

For the sake of system performance, the resource check is performed at midnight. To reduce theimpact on traffic charging, the S-CDR bill is generated according to the traffic. Time-basedcharging is disabled.

ProcedureTo 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 theresource check, the charging module of the UGTP generates S-CDR bills only according to thetraffic threshold to reduce the system load. Then, the function of generating bills according tothe time threshold is disabled.

The resource check lasts half an hour. After that, the S-CDR bills are generated according to thetime threshold and traffic threshold as configured.

----End

3.4.9 Bills with Zero Time LengthThe duration and traffic of an S-CDR bill are zero.

ContextThe duration between the PDP context deactivation and the previous bill generation is less than400 ms. Therefore, the duration of the latter bill is zero. This bill, however, cannot be combinedwith 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 isNormal 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 trafficis zero.

Step 3 During the short time after the previous bill is generated, the PDP context is deactivated (durationbetween the generation of the two bills does not exceed 400 ms). Thus, a bill with the followingfeatures is generated owing to round:l Time length: zero

l Traffic: zero



l Closing cause: Normal Release

----End

3.4.10 S-CDR Bill RepetitionThe two S-CDR bills of a subscriber have an overlap of 80 seconds.

ContextWhen an MS activates two or more PDP contexts, bills with time overlap are generated. This isa normal case.

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

----End


Troubleshooting


servicing tips for 3g nodes

Documents