Well first of all, implicit detach mainly happens when the network detaches a subscriber without informing it,

and this happens mainly because the mobile did not send the periodic routing area update, and is not responding to the paging of the network after the expiry of the mobile reachable timer (by default it is 54 minutes for periodic routing area update + additional 4 minutes to page the mobile = 58 minutes in total). The cause is mainly due to loss of coverage for the mobile so it can not send the RAU or respond to network paging. Or in case it is really related to 3G to 2G handover, then it is good to check at which routing areas this is happening. This might give an idea if it is happening between different SGSNs or not. The mobile can be under one routing area in 3G and then it switches to another RA under 2G, and it sends the RAU to the SGSN handling the new RA with info about the old RA. If it is a new SGSN, then this new SGSN will attempt to check subscriber profile from the previous SGSN (based on the old RA provided), if it fails, it will ask for this subscriber's identity to be able to get its profile from the HLR. Failure is mainly because either the SGSNs are not communicating with each other, or the RA name resolution is not configured correctly at each SGSN (i.e. RA to SGSN IP mapping is not configured correctly). IF this happens then the old SGSN will have no idea what happened to this subscriber and will be waiting for its periodic RAU to be sent after 58 minutes, and apparently it will not receive it, so it will implicitly detach it from its subscriber database (it will be detached when checked on the SGSN). One suggestion, that I do not think is implemented at MTC, is to configure the RA codes on a common DNS server. This will make things centralized so that any change of a routing area code or moving this RA from BSC to BSC/RNC can be done at one place without having to update it on all SGSNs. one way to check if there is a problem in DNS mappings is to check also DNS captures for each SGSNs. It will show which RAs are being queried by the SGSN (in case they are not configured in its local host file).

Introduction:The signalling transported on the SDCCH channel is aimed at reaching the service requested by the Mobile Station; in some cases this represents only the setup of the service, in other cases the service is completely performed on the SDCCH channel. SDCCH usage: User Requests (Mobile Originated Call, SMS, Supplementary Services) Answer To paging (Mobile Terminated Call) Call - Re Establishment Location Update Procedure IMSI detach indication Signalling Analysis:-

First of all the channel request message is sent from the MS on RACCH Channel to the BTS and the BTS sends the channel required message to the BSC. This is always the first step for accessing the network. This part of signalling is performed for every MS accessing a service, independently on the kind of service required, meaning that it is valid also for all the other services (not call) the MS can ask: SMS, Location Update, IMSI detach, Supplementary Service.
This CR message consists of 8 bits 3 bits are reserved for the establishment cause and 5 bits for the random reference. Among the 8 possible combinations of establishment cause's 3 bits, 5 are valid as establishment causes. the other 3 combinations are not valid and then refused by the network. Reasons for SDCCH failures:Poor RF Condition Path imbalance or sensitivity difference between MS and BTS Co-BCCH & BSIC problem Ghost random RACCH Bursts of random accesses (HO access) channel activation not acknowledgement message failure Recommendations:-

Modify the SDCCH formula:- Remove the SDCCH fails due to Timer expiry T3101 from SDCCH abis failure counter SDCCH KPI could be improved by optimized use of cell parameters and removing the Co -BCCH and Co-BSIC problems. Lower the Rx Lev min Access in urban area. Make cell boundary less by tilting and improving coverage area. It has been observed that SDCCH failures are in the cells between location area boundaries due to high location updates.It is recommended that use cell hysteresis value high for example like 10dbm in the cells at location boundary. Also increase the periodic location update counter to lower the no of location updates.

What is Call Drop? The TCH call drop rate refers to the ratio of call drops to successful TCH seizures after the BSC successfully assigns TCHs to MSs. The TCH call drop rate can be measured from the following aspects: TCH call drop rate (including handover) TCH call drop rate (excluding handover) Formulas for Call Drop including handovers: TCH call drop rate (including handover) = Number of call drops on TCH/(Number of successful TCH seizures (signaling channel) + Number of successful TCH seizures (TCH) + Number of successful TCH Seizures in TCH handovers (TCH)) x 100%

Formulas for Call Drop excluding handovers: TCH call drop rate (excluding handover) = Number of call drops on TCH/Number of successful TCH seizures (TCH) x 100% Parameter Check list for Call Drop: These parameters are common for all the vendors the only difference is its name will be different. The settings of some parameters on the BSC and MSC sides may affect the TCH call drop rate. If the following situations occur, the TCH call drop rate may increase: 1. The parameters SACCH Multi-Frames and Radio Link Timeout are set to too small values. 2. The parameter RXLEV_ACCESS_MIN is set to a too small value. 3. The parameter RACH Min.Access Level is set to a too small value. 4. The parameters Min DL Power on HO Candidate Cell and Min Access Level Offset are inappropriately set. 5. The length of timer T3103 (this timer is set to wait for a Handover Complete message) is set to a too small value. 6. The length of timer T3109 (this timer is set to wait for a Release Indication message) is set to a too small value. 7. The length of timer T3111 (this timer specifies the connection release delay) is set to a too small value. 8. The length of timer T305/T308 is set to an invalid or too great value. 9. The parameter TCH Traffic Busy Threshold is set to a too small value. 10. The parameter Call Reestablishment Forbidden is set to Yes. 11. The parameters related to edge handover are inappropriately set. 12. The parameters related to BQ handover are inappropriately set. 13. The parameters related to interference handover are inappropriately set. 14. The parameters related to concentric cell handover are inappropriately set. 15. The parameters related to power control are inappropriately set. 16. T200 and N200 are set to too small values. 17. Some neighboring cell relations are not configured. 18. The parameter MAIO is inappropriately set. 19. The parameter Disconnect Handover Protect Timer is set to a too small value. 20. The parameter TR1N is set to a too small value. 21. The parameters Software Parameter 13 and MAX TA are set to too small values. 22. If a repeater is used, the parameter Directly Magnifier Site Flag is set to No.

16. Parameters related to power control If the power control level and quality threshold are set to small values, call drops are likely to occur because of low signal level or bad voice quality. 17. T200 and N200 If the parameters T200 FACCH/F, T200 FACCH/H, N200 of FACCH/Full rate, and N200 of FACCH/Half rate are set to small values, data links are disconnected too early. Thus, all drops are likely to occur. If call drops occur because of T200 expiry, you can increase the values of T200 and N200 properly. 18. Neighboring cell relations If the neighboring cells configured in the BA2 table are incomplete, call drops are likely to occur in the case of no suitable neighboring cell for handover and progressive deterioration in the voice quality. Neighboring cell relations should be configured completely on the basis of the drive test data and electronic map (for example, Nastar) to minimize the call drops due to no available neighboring cells. 19. MAIO If frequency hopping (FH) is applied in a cell and the MAIO is set inappropriately (for example, different TRXs serving the same cell have the same MAIO), frequency collision may occur during FH. Thus, the TCH call drop rate increases. 20. Disconnect Handover Protect Timer This parameter is a software parameter of the BSC. After receiving a DISCONNECT message from an MS, the BSC cannot hand over the MS within the period specified by this parameter. Therefore, the following case can be avoided: After being handed over to the target cell, the MS cannot be put on hook because it does not receive a release acknowledgement message. You are advised to set this parameter properly. 21. TR1N This parameter should be set on the MSC side. It is used to avoid the retransmission of short messages. When this parameter is set to a too great value, the MSC does not send a CLEAR CMD message if the MS receives a short message during link disconnection. As a result, the MS sends the BTS a DISC message to disconnect layer 2 connection. After receiving the DISC message, the BTS sends a REL_IND message to the BSC. Then, the BSC sends a CLEAR REQ message to the MSC and the number of call drops is incremented by one. 22. Software Parameter 13 and MAX TA When the parameter Software Parameter 13 is enabled and the parameter MAX TA is set to a too small value, the channel is released when the TA of a call exceeds the MAX TA. In this case, call drops occur. It is recommended that the parameter Software Parameter 13 should not be enabled. 23. Directly Magnifier Site Flag If a BTS is installed with repeaters, the handover between repeaters can only be asynchronous because the distance between repeaters is long. If synchronous handovers are performed, the handovers may fail and thus many call drops occur. Therefore, when a BTS is installed with repeaters, the parameter Directly Magnifier Site Flag should be set to Yes to avoid asynchronous handovers between cells under the same BTS.