Professional Documents
Culture Documents
MSOFTX3000 is one of the core network equipment of UMTS mobile communications system. It plays a very important role in the network. Therefore, when faults occur to MSOFTX3000, rapid locating and clearing of the faults is one of the most important factors for the stable and safe operation of UMTS system. The course mainly introduce MSOFTX3000 common fault description and troubleshooting.
Page 2
able to: Master important point of MSOFTX3000 operation and maintenance Master every kind of fault description Master every kind of fault troubleshooting.
Page 3
Chapter 1 Mc server fault analysis method Chapter 2 interface fault analysis Chapter 3 service fault analysis
Page 4
Chapter 1 Mc server fault analysis method 1.1 General Flow of Troubleshooting 1.2 Common Fault Locating Methods 1.3 Common System Running Faults
Page 5
Fault
locati ng
Fault cleari ng
Page 6
Chapter 1 Mc server fault analysis method 1.1 General Flow of Troubleshooting 1.2 Common Fault Locating Methods 1.3 Common System Running Faults
Page 7
Page 8
Chapter 1 Mc server fault analysis method 1.1 General Flow of Troubleshooting 1.2 Common Fault Locating Methods 1.3 Common System Running Faults
Page 9
in only one way, through BAM Software loading faults include loading process disabled and board failed to be started after loading
Operation fault
LMT operating faults include unable to run normally, BAM can not be run normally
Page 10
Resource fault
Resource fault refers to resource congestion.System will produce congestion alarm during the fault procedure and overloading alarm before the fault happens.
Clock fault
Page 11
Chapter 1 Mc server fault analysis method Chapter 2 interface fault analysis Chapter 3 service fault analysis
Page 12
Page 13
Category
Fault description
MTP link disconnected MTP link is normal, but C/D interface service is interrupted The corresponding E1 link of C/D interface has a slip frame
Link disconnected
Page 14
disconnected, check whether MTP link is faulty first, and then make the
Yes
Page 15
In LMT, the alarm console will display the relevant alarms for the signaling link fault. Alarm name E1 link failure alarm MTP signalling link unusable signalling link test failure link locating fault
HUAWEI TECHNOLOGIES CO., LTD. All rights reserved Page 16
Command name
Command function
DSP N7LNK
DSP N7DLNK DSP N7DPC
DSP N7RT
Page 17
2
3 4 5 6
Configuration error happens to such MTP parameters as destination signaling point, link and route.
Data configuration error happens to the corresponding E1 port of the link in WEPI board. Misconnected RX/TX port of E1 cable, inconsistency between port connection and data configuration, abnormal connector connection, etc. Hardware fault in MTP- link E1 cable transmission fault, peer-end-related causes, etc.
Page 18
Troubleshooting procedures
Check link status Check the data configuration Check data configuration of E1 port Check link physical connection Relevant hardware fault Other causes
Page 19
C/D interface service can not go on normally. But MTP link is in normal status.
Relevant alarms displayed at the alarm console
Possible fault causes
Serial No. 1 2 3
Fault cause SCCP layer management status error Data configuration error in SCCP layer Configuration error in the SCCP of the peer end
Description SCCP subsystem in abnormal status Configuration error in such SCCP parameters as DSP, SSN, GT, etc. Configuration error in the SCCP of the peer end
Page 20
Troubleshooting procedures
Check the SCCP layer data configuration Query SCCP layer management status Check the peer end SCCP layer
Page 21
Case Analysis I
HLR GT Configuration Error Leads to the Update Location Failure Fault description
Some subscriber can not Update Location successfully. Start the subscriber tracing in LMT, and the following facts are found: at the C/D interface, MSC-Server has already sent the Update Location message, and HLR returns the Insert Subscriber Data message. But MSC-Server does not return Insert Subscriber Data Ack message as specified in the protocol.
Page 22
Case Analysis I
Troubleshooting procedures
Query the subsystem configuration, and it turns out that the corresponding HLR is configured correctly. Query the GT configuration, and it turns out there is no GT configuration corresponding to the ISDN of HLR. Add the corresponding GT configuration of the ISDN of HLR, then the MS is attached successfully.
Page 23
Case Analysis II
Trace the A/Iu interface, and it is found that MSOFTX3000 responds to a LOCATION_UPDATING_REQUEST message with a LOCATION_UPDATING_REJECT message which contains the cause value PLMN not allowed. At the same time, trace the C/D interface, and no messages are found.
Page 24
Case Analysis II
Troubleshooting procedures
Query the IMSI-GT translation information. According to the translated global title, MSOFTX3000 addresses the subscriber resident HLR. If it turns out there is no IMSI-GT translation information according to subscribers IMSI, the preceding failure occurs.
Page 25
Trace the C/D interface, and the following are found: MSOFTX3000 sends a MAP_UPDATE_LOCATION message and receives a MAP_UPDATE_LOCATION ACK message which contains the roaming not allowed error. The regional subscription response parameter in the MAP_INSERT_SUBSCRIBER_DATA ACK message sent by MSOFTX3000 indicates the MSOFTX3000 area restricted entirely because of regional subscription or regional subscription not supported by the VLR; and the regional roaming restriction flag in the basic subscriber data is set as Y. All message is normal but attachment fails.
Page 26
For the first symptom, if roaming not allowed is specific to PLMN not allowed, it indicates that the telecom carrier does not allow the subscriber to roam in this PLMN (refer to Case Analysis II) . If roaming not allowed is specific to ODB, possibly the subscriber is not allowed to roam to the MSOFTX3000 or the roaming data of the MSOFTX3000 is not added as a roaming area of the HLR. Contact the subscriber and the subscriberhomed HLR to solve the problem. For the second symptom, possibly the zone code restriction service cause the failure. For example, the zone codes configured in the MSOFTX3000 has no intersection set with the zone codes subscribed in the HLR. Execute the LST ZC command to check the zone code configurations and modify the configuration errors.
HUAWEI TECHNOLOGIES CO., LTD. All rights reserved Page 27
Troubleshooting procedures(2)
For the third symptom, possibly the enhanced roaming restriction service cause the failure. Execute the LST ROAMRESTGRP/LST ROAMRESTGRP command to check the enhanced roaming restriction service configurations and modify the configuration errors.
Page 28
Case Analysis IV
MSC-Server Data Configuration Error Leads to Combined
Attachment Failure
Fault description
An MS originates combined attachment. The PS domain is attached successfully, but the CS domain is attached unsuccessfully. Start the subscriber tracing in LMT, and it is found out: the peer end MSC-Server has not returned Location Update Accept message after MSC-Server sent out Location Update Request message and the Attach Accept sent by MSCServer indicates "MSC-Server temporarily not reachable".
Page 29
Case Analysis IV
Troubleshooting procedures
In LMT, use the command DSP N7LNK to query the links destined to MSC-Server. It is found out that the link is in normal status, "Yes" for the domain "transmission service" and "No" for the domain "link fault". Check the SCCP data configuration of MSC-Server, and it turns out that the data configuration is correct.
It is suspected that there is configuration error at the peer end. Contact MSC-Server maintenance staff, and it is confirmed that the GT of MSC-Server has not been configured correctly.
MSC-Server modifies the data configuration, and the MS is attached successfully.
Page 30
Page 31
Fault Classification
Fault description
Abnormal trunk state: When you query the state of a trunk, the state is displayed as faulty or unknown. Conversation exception: The call can not success because there is some problem in the IAM message.
Page 32
Check the distribution of CIC with the command LST CIC, and check whether it is consistent with that at the peer end. Check whether MGW trunk cables are correctly connected. Reset the trunk circuit, and check whether the circuit is in normal state after the resetting. Perform signaling tracing on the signaling links. Reset the abnormal trunk circuit. Check whether the peer end responds to the resetting. If not, the fault may reside in the peer end. In this case, contact the maintenance personnel at the peer end to clear the fault.
Page 33
Use the command DSP N7DPC to query the faulty circuit . If the cause is DPC inaccessibility, first solve the signaling system
Page 34
For configuration of PRA circuits, PBXs of some companies require CRC mode in E1 transmission. In this case, you can modify the E32 port property to CRC4_MULTIFRAME through the maintenance terminal of UMGW with the command SET E1PORT. Check the data configuration in MGW: whether MGW is normal; whether the E32 board, E1 interface, and timeslots are normal; and whether E1 connections are correct. If the fault is caused by hardware blocking at the peer end, contact the peer end for solution.
Page 35
There are very many elements in the message can infect the conversation. For example TMR/ CAT/ FCI. If some call can not success , we first check this elements in the iam message. In different call, these elements will have different value.
Normally, the CAT almost is ordinary, the TMR almost is speech. But when the VP call, the TMR must be the 64k unstrict.
Page 36
Page 37
Mc interface fault
Classification of Common Faults
Page 38
Mc interface fault
Fault description
Mc Link fault: The state of Mc interface links is always invalid or there are alarms for Mc interface link faults. MGW fault: When you query MGW state, its state is displayed as faulty all the time.
Page 39
Mc interface fault
1
2
Configuration error
Connection error Wrong connection or networking of cables associated with the Mc interface No request to establish the Mc link No link setup process initiated with the command ACT VMGW after H.248 link data is added in MGW
Page 40
Mc interface fault
Troubleshooting procedures (Mc Link fault)
Page 41
Mc interface fault
Possible fault causes (MGW fault)
Serial No.
1
Description MGW is not registered to the MSC Server. MGW becomes fault because Mc interface links are faulty
Page 42
Mc interface fault
If Mc interface links is faulty, deal with it firstly. If MGW is not registered, contract MGW maintenance personnel
Page 43
Fault Case
Fault description
In LMT, use the MML command DSP MCLNK and query the state of Mc links, the result is that Mc Links are faulty.
Troubleshooting procedures
Check the Server/Client Mode in MGW configuration using LST MGW command, it is correct if the result is: MSOFTX3000 is Server and UMG9800 is Client. Check the checksum arithmetic of SCTPPARA, and find that MSOFTX3000 is CRC32 but UMG9800 is ADLER32. Modify the checksum arithmetic of SCTPPARA to CRC32 in UMG9800, and Mc links are normal.
Page 44
Chapter 1 Mc server fault analysis method Chapter 2 interface fault analysis Chapter 3 service fault analysis
Page 45
Page 46
Network Access Failure Caused by LAI/GCI Error Trace the A/Iu interface, and it is found that MSOFTX3000 responds to a LOCATION_UPDATING_REQUEST message with a LOCATION_UPDATING_REJECT message which contains the cause value network failure. At the same time, trace the C/D interface, and no messages are found.
Page 47
When a UE is performing a location update, according to the GCI carried in the LOCATION_UPDATING_REQUEST, MSOFTX3000 looks up the corresponding global cell data and location area data in the LAI/SAI configurations. If no data records match, the preceding failure occurs. Based on the GCI parameter carried in the LOCATION_UPDATING_REQUEST, execute the LST LAIGCI or LST LAISAI command to query whether a record in the LAI/GCI configurations matches that piece of global cell and location area data and whether that piece of data is correct.
Page 48
Trace the A/Iu interface, and it is found that MSOFTX3000 responds to a LOCATION_UPDATING_REQUEST message with a LOCATION_UPDATING_REJECT message. Trace the C/D interface, and the following are found: MSOFTX3000 receives a MAP_UPDATE_LOCATION ACK message which carries the unknown user error.
Page 49
If the HLR directly returns an error unknown user, possibly the subscriber does not subscribe in the corresponding HLR or the subscribers E.214 global title is translated to an incorrect HLR. In the case of unknown user, check whether the subscriber has subscribed in the corresponding HLR. In addition, check whether the subscribers E.214 addressing is configured, in MSOFTX3000, to a correct HLR, excluding the case that an incorrect configuration to an incorrect HLR causes the HLR to return the unknown user error.
Page 50
Page 51
The traced signaling at the subscriber interface reveals that the MSOFTX3000 sends DISCONECT message with cause code unassigned or unallocated number
Fault causes
Page 52
When a mobile subscriber dials a specific fixed subscriber number segment, the call fails. It is found that the MSOFTX3000 did not send IAM/IAI messages to the opposite office after assignment is finished, or the number format of the sent messages does not conform to the inter-office agreement.
Fault causes
Page 53
Page 54
Page 55
Page 56
When subscribers register forwarded-to numbers, trace their interfaces and then find MSOFTX3000 has reported forwarded-to numbers to HLR but HLR returns registration errors.
Page 57
Troubleshooting procedures
Subscriber aspect: Subscriber aspect refers to the fact that subscribers do not apply for call forwarding service or the format of the forwarded-to numbers registered by subscribers is incorrect. Check whether subscribers have used call forwarding service and forwarded-to numbers meet corresponding requirements.
Page 58
Analysis Error
Fault description
In a forwarded call triggered by this MSOFTX3000, trace user interface according to the calling number. HLR has returned the correct forwarded-to number but MSOFTX3000 has not sent the IAM/IAI message to the corresponding exchange.
Page 59
Comparing number analysis flow for forwarded-to numbers by MSC-Server with that for general called numbers, there are two major differences: One is that handles forwarded-to numbers in a default manner before number analysis; Another is that controls the analysis flow for forwarded-to numbers by some software parameters. Check number analysis data according to forwarded-to numbers. If MSOFTX3000 cannot standardize the format of forwarded-to numbers correctly by default, then add corresponding standardized records, whose [call source] parameter is set to MAP, to called number pre-analysis. If software parameters cause this problem, then update corresponding parameters.
Page 60
Summary
classical and common locating method for MSOFTX3000 operation and maintenance.
The most important point is to
Page 61
Thank You
www.huawei.com