A General Analysis The problem

In a GSM network, the usual and easiest approach to network quality monitoring is by means of OMC counters or performance indicators. The main reason for this is that they are usually available directly from the OMC (easy collection), and normally at no extra cost. Moreover, these counters are available at regular intervalsfor example, every hourwithout any manual intervention on the system. However, several limitations with OMC counters may prove problematic, depending on the structure and complexity of the network:

Available OMC counters usually cannot be all activated at the same time. It is therefore necessary to focus on specific tasks or indicators when setting up the system. The information contained in the counters and performance indicators is limited. Further detailed investigation is possible through re-configuring the active counters (when more detailed counter analysis is possible) or setting up some kind of data capture or measurement system in the trouble area. However, this type of intervention occurs after the problem has been detected with the performance indicators, and this problem may be not reproducible. In a complex multi-vendor system, OMC counters are specific to each vendors infrastructure. It may be difficult or even impossible to match information from different vendor sources, even for a simple analysis. This is because the methods for triggering counters and calculating performance indicators vary from one equipment manufacturer to another.

The solution
The solution to these restrictions is to use data collected from the A-interface (the MSC-BSS interface). This interface is standardized by ETSI and its implementation is mandatory. Advantages of using A-interface data are:

Network optimization based on A-interface analysis makes the process objective and independent of vendor infrastructure. Because the interface is standardized, the same analysis method can be applied over the entire network. A-interface provides the most global view in the GSM system architecture, and is the logical first step in a top-down approach for network optimization. Collecting data is usually easier (because of the reduced number of link connections) than for Abis or Drive Test data. In many networks, there are systems in place for link quality monitoring that can be re-configured for A-interface signaling data collection. The number of signaling timeslots on a set of A-interface links for an entire BSC is rather small. This makes A-interface data collection for one or more BSCs compatible within the capacity of a single data capture tool or protocol analyzer. Analyses can be run at BSC level, then at celland even at individual call level, with the same unique dataset. The overall analysis at BSC level may be used as a health check before investigating further to find cells with specific problems. Finally, in a problem cell, the specific types of problem calls may be investigated individually in detail. The entire process does not require additional data collection. Cause information, as determined by the BSS or MSC, is available on the A-interface for Call Control and Mobility Management procedures such as location update, call initiation or handover. This information often helps identify the source of a problem.

Of course, there are limitations to the use of Ainterface data, although these are far less constraining than the limitations of the OMC counters:

Although an A-interface trace does contain information about many more cells than a similar trace on, for example, the Abis interface, the main disadvantage is that it does not contain detailed radio link-related information such as that contained in Measurement Reports from the mobiles or Measurement Results from the BTS. However, A-interface analysis should not be seen as the only possible source of data for network optimization, but rather as the first step in the topdown optimization process.

Location Update
Count, percentage and breakdown of Location Update messages, types and reject causes. The analysis of Location Update procedures covers at least two aspects of GSM network optimization:

Dimensioning of the radio resources (AGCH and SDCCH) and tuning of the periodic updating timers in the MSC. Detection of infrastructure problems.

For the first aspect described above, analysis of LU type information elements in the Layer 3 messaging allows a clear repartition of the periodic procedures relative to the other location updating procedures. Periodic procedures are controllable by means of a timer broadcasted on the BCCH. This timer is used to trigger the procedure by each mobile camping in the network. Disproportionate periodic procedures will inevitably overload AGCH and SDCCH radio channels in busy areas of the network. So, to avoid overloading these signaling radio resources a proper balance must be found between correct dimensioning of the signaling channels and smart tuning of the periodic timer. On the other hand, periodic update procedure timing may have a direct influence on the time required to deliver SMS messages in poorly covered areas of the network. Normal Location Update procedures are not controllable in the international border areas of a network. However, they are controllable elsewhere in the network by designing appropriate MSC areas and LAC areas.

Finally, IMSI Attach procedures are not controllable although they can be turned off completelyand are totally dependant on the subscriber behavior. This can be used to indicate how subscribers use their phone in the network. A large proportion of IMSI Attach would indicate that people tend to switch their mobile off when they do not make a call; therefore they switch it back on every time they do make a call. The existing report and queries used for Location Update analysis give results at the BSC level. For finer investigation and tuning, it would be possible to write similar queries that give results at the cell level. The second aspect that will be covered here is the detection of infrastructure problems. In fact, in case the network rejects a Location Update attempt, the corresponding reject message contains a cause value that can help identify the source of the problem. Typically, 95% of the rejected attempts should be due to cause value 11 (PLMN not allowed). This cause value is normal, and means that there is no roaming agreement with the operator of the concerned subscriber, or the user has not subscribed to roaming services with his operator. Cause IMSI Unknown In HLR, for example, indicates that the card has not yet been activated. This situation occurs when a new subscriber purchases a SIM and tries to use it before the operator has registered the SIM in its billing system. Depending where the card was purchased (Service store, reseller, and so on) there is always some administrative delay between the purchase and the activation. This is not the case with a pre-paid card. Other cause values point to network failurefor example, inter-working link with foreign HLR down, congestion.

Clear Cause
Cause Code count and percentage for Clear Command messages. Where the assignment procedure is related to the set up of a call on the radio interface, the clear command

will provide information on how and why the call or connection is ended. Not all Cause codes for the Clear Command messages are problem causes. Typically, Cause values 9 and 11 (Call Control and Handover Successful, respectively) are normal connection clearing indicators. Call Control clearing means that whatever procedure, handled on the A-interface, was terminated correctly. Handover Successful clearing means that the call has been successfully handed over to another BSC. A breakdown in percentage of these cause values will thus clearly indicate:

The proportion of normal connection clearings. The relative individual importance of the remaining abnormal terminations.

To further investigate specific calls, you can use the Clear Command calls query to generate call substreams. By setting the proper filter conditions in the substream generator, it is possible to generate for example all calls with abnormal termination, or all calls with termination cause Radio Interface Failure, and so on.

Services Requested
Count, percentage and breakdown.

Channel Assignment
Assignment message count and percentage, Assignment Failure breakdown. Analyzing the procedure for radio-traffic channel assignment is interesting on the A-interface because it reveals problems related both to the radio interface itself and to the infrastructure by means of a cause value analysis. The TCH Assignment success rate is computed as:
# Assignment Complete / # Assignment Request

Similarly, the failure rate is computed as:

# Assignment Failure / # Assignment Request

Note that the sum of Assignment Complete and Assignment Failure messages should normally equal the number of Assignment Request messages. However, depending on the conditions when the trace was started and ended, some messages may be lost. See SCCP Connection Analysis above for a method of estimating the number of messages lost. In the report on assignment procedures, a deeper analysis of potential problem is possible by examining the Assignment Failure Cause breakdown report. In the logic of a top-down optimization approach, the cause value investigation for failed procedures will help to narrow the problem origin. In the report, cause values have been translated into clear text for easy identification. Note that the report also contains a cell-by-cell breakdown of the assignment procedure successrate. The combination of these three levels of analysis make it possible to localize the problems to specific cells or equipments. In addition, to allow a call-by-call detailed analysis of Assignment failure cases, a specific query is available in the workspace to generate sub streams of these problem calls.

Channel Assignment by Cell

Assignment message count and percentage for each cell.

Connection Analysis
Count and percentage of SCCP Connection messages. Breakdowns of SCCP Services Requested and CSSP Connection Refused Causes. As a container for the transfer of Layer 3 messages, the quality of the SCCP connections is important because it helps identify problems related to terrestrial links and resource management.

The SCCP connection success rate can be measured by the ratio:

# Connection Confirm messages / # Connection Request messages

Similarly, the failure rate is obtained with:

# Connection Refused messages / # Connection Request messages

Obtaining a high percentage of Connection Refused messages is (if not related to a hardware problem) usually a good indicator of a link or trunkdimensioning problem. It may also point to a lack of processing power in the MSC boards in charge of the management of these links. Note that the sum of Connection Confirm and Connection Refused messages should normally equal the number of Connection Request messages. However, depending on the conditions when the trace was started and ended, some messages may be lost. This may be the reason for occasional variations in the overall percentage results of a trace. A check for these lost messages could be implemented as an improvement to the existing SCCP report:
# Lost messages = # Request (# Confirm + # Refused)

A positive result would indicate that either Connection Confirm or Connection Refused messages have been lost. A negative number would mean that Connection Request messages have been lost. For further analysis, it is useful to break down the causes for SCCP Connection Refusals, as the information is embedded in the SCCP message and is available as an attribute in the Analyzer workspace. Cause values help the engineer in the troubleshooting process, as they often contain relevant information about the origin of a problem. A query listing all calls with an SCCP Connection Refused is available (in the workspace provided with this engineering note) for deeper investigations of these problem connections. The query can be displayed on a workbook for a rapid overview, or it can be used to generate sub-streams of the problem calls that can then be analyzed individually.

Connection Analysis by Cell

Connection statistics for each cell. In optimizing the radio resources of a GSM network, tasks such as traffic or signaling channel dimensioning require a key input: an estimation of the traffic mix (a table representing the relative importance of the different call procedures that make use of the radio resources). Each call procedure type is then analyzed individually to estimate the load that it generates on the different radio resources. Finally, the traffic mix and the load estimation are used together to compute the channel settings (combination of BCCH/PCH/AGCH/SDCCH and TCH) that will provide maximum capacity for the available resources. If initial SCCP Connection Request messages carry Layer 3 messages concerning the call procedure (almost all equipment manufacturer have implemented this method on the A-interface, but this is not a mandatory way of proceeding), a traffic mix can easily be established at BSC or even cell level using these SCCP messages. The fact that a traffic mix can be estimated at cell level is important in areas of the network of mixed cell types. For example, national border areas where a border cell may be mixed with nearby rural or urban cells. In fact this situation requires a mix of dimensioning rules: a border cell may require more SDCCH capacity to cope with Location Update traffic while an urban cell will be focused on providing maximum TCH capacity. So, it would not be wise to dimension the channels according to the entire area. Note that in the case of equipment sending empty Connection Request messages (the SCCP session is established before Layer 3 messages are sent), it is still possible to generate a traffic mix at BSC level by combining the results of different queries. One query based on one or more attributes would be required for each group of call procedures, as described below:

Attribute CMServiceType for: Emergency calls, MOC, SMS MO, Supplementary Services (an example of this query is available in the

workspace and report provided with this engineering note)

Attribute LocationUpdatingType for: IMSI attach, normal LU, periodic LU Attribute A_Msg_Type for: HO Attributes A_Um_Msg_Group and A_Um_Msg_Type for: IMSI detach, MTC/SMS MT, call Re-establishment.

The same process could be applied for individual cells, but the result consolidation would be more complex and falls outside of the scope of this engineering note. In the present CR distribution query and report, the distinction between SMS MT and MTC calls is based on a combination of elements: in fact, the Paging Response message does not indicate the SAPI for the radio link (this information distinguishes SMS services from voice services); this info is sent later in the message flow. As a workaround, it is possible to count the number of Setup messages for each individual cell. Setup messages are a unique identifier of MTC and MOC procedures. As we also have a count of the MOC procedures in the query, MTC calls may be calculated as the difference between the Setup and MOC counters. The SMS MT procedures are then computed from the MTC/SMS MT counter and the calculated MTC. The limitation of this method, however, lies in the fact that it does not take into account the possibility to have a failure of the call procedure before the Setup message is sent. In the workspace, there is a specific query that classifies each call in the trace according to its connection procedure type. This makes it easy to extract all calls of a particular type (using the sub stream generator) for individual analysis. For example, you could easily extract all SMS MO calls for detailed analysis. This is of course very useful for the load estimation described above.