C ALL SETUP – C ORE N ETWORK FAILURES

After establishment of the RRC connection the UE and the CN exchange Direct Transfer messages so the UE can GPRS attach to the PS network, perform a Location or Routing Area Update or initiate a data, voice or VT call. LAU/RAU involve just the mobility management procedures while the Call setup also includes call control and session management protocols for CS and PS calls respectively.

The following subsections are summarising possible failures that might occur during these procedures. The subsections are grouped by the following three different protocols:

• Mobility Management (MM) and GPRS Mobility Management (GMM)

• Call Control (CC)

• Session Management (SM)

The three protocols are sublayer protocols of the Connection Management (CM); these protocols are specified in [5] and [8]. CM failures causes like “CM

Service Reject Cause” is mapped on the Reject Cause of the Mobility Management IE [5].

Note that (almost) any failure in this subsection is not UTRAN related because Direct Transfer messages are transparent to the UTRAN⁴. Any of the failures can be easily detected by the corresponding failure messages.

Because the protocols are transparent to the UTRAN all PM KPIs are defined within the CN entities e.g. SGSN / GGSN, 3G-MSC, … basis.

5.3.1. Mobility Management failures 5.3.1.1. Concept

The main function of the mobility management is to support the mobility of user terminals, such as informing the network of its present location and providing user identity confidentiality. A mobility management context in the SGSN or 3G-MSC is a prerequisite for the initialisation of voice, data or VT services.

5.3.1.2. Failure symptoms, identification and fixes for improvement

For the root cause analysis please review the timer settings supervising the mobility management protocols as specified in [5] chapter 11.2. The settings of these timers are specified and not configurable. In addition Mobility Management failures might be due to missing roaming agreement, locked SIM card, CN problems like authentication not possible due to inaccessible HLR database etc.

The failure messages are retrieved from [5] chapter 9.2 (MM/CM) and 9.4 (GMM). Table 21 below is listing the Mobility Management failures as they can be retrieved by interface traces:

Problem Trace Trigger

MM Authentication Reject

Uu or Iub or Iu Any occurrence of a MM Authentication reject message sent by the CN e.g. because of not-allowed national/international roaming

CM Service Reject Uu or Iub or Iu Any occurrence of a CM Service reject message sent by the CN; the reject cause will give an indication of the occurred failure.

CM Service Abort Uu or Iub or Iu Any occurrence of a CM Service abort message sent by the UE. This message is sent by the mobile station to the network to request the abortion of the first MM connection establishment in progress and the release of the RR connection.

MM Abort Uu or Iub or Iu Any occurrence of a MM Abort message sent by the CN. This message is sent by the network to the mobile station to initiate the abortion of all MM connections and to indicate the reason for the abortion. The rejection cause will give an indication about the occurred failure.

MM Location

Updating Reject

Uu or Iub or Iu Any occurrence of a MM Location updating reject message sent by the CN. The specified rejection cause will indicate the reason for the failure e.g. IMSI unknown in the HLR, illegal MS/ME, roaming not allowed etc.

GMM Attach Reject Uu or Iub or Iu Any occurrence of a GMM Attach Reject message sent by the CN The specified rejection cause will indicate the reason for the failure e.g.

protocol error, wrong or incorrect IE format etc.

4 Exception: there might be the case that due to a bad RF environment the direct transfer messages cannot be delivered to the other entity because the RLC layer is not able to deliver the corresponding message also after RLC retransmissions, RLC resets etc. It is up to the corresponding higher layer (e.g. CC, GMM, MM or SM) to react accordantly of the discarded message.

GMM Authentication and Ciphering Failure

Uu or Iub or Iu Any occurrence of a GMM Authentication and Ciphering Failure message sent by the UE. The specified rejection cause will indicate the reason for the failure e.g. a sync failure.

GMM Authentication and Ciphering Reject

Uu or Iub or Iu Any occurrence of a GMM Authentication and Ciphering Reject message sent by the CN.

GMM Routing Area Update Reject

Uu or Iub or Iu Any occurrence of a GMM Routing area update reject message sent by the CN. The specified rejection cause will indicate the reason for the failure e.g. protocol error, wrong or incorrect IE format etc.

GMM Service Reject Uu or Iub or Iu Any occurrence of a GMM Service reject message sent by the CN

Table 21: Identification of Mobility Management failures in interface traces

Table 22 below is listing the PM KPIs of the Mobility Management as they can be retrieved by the PM system of the 3G-MSC and SGSN:

PM system

Counter / KPI KPI Name / Description

SGSN (MM.AttGprsAttach.U – MM.SuccGprsAttach.U) / MM.AttGprsAttach.U * 100

GPRS attach failure rate

SGSN (attAuthInSgsn – succAuthInSgsn) / attAuthInSgsn * 100 Authentication failure rate

SGSN (MM.AttGprsDetachSgsn.U –

MM.SuccGprsDetachSgsn.U) / MM.AttGprsDetachSgsn.U * 100

SGSN initiated GPRS detach failure rate

3G-MSC (attInterVLRLocationUpdates +

Inter SGSN routing area update success rate

SGSN MM.SuccIntraSgsnRaUpdate.U /

MM.AttIntraSgsnRaUpdate.U * 100

Intra SGSN routing area update success rate

3G-MSC VS.mobileOrigAttRejected The counter is incremented for a mobile origination attempt that MSC for reasons other than system resource overload related.

3G-MSC VS.mobileTermAttRejected The counter is incremented for a mobile termination attempt that is rejected by the MSC for reasons other than system resource overload related.

Table 22: PM KPIs/Counters for (GPRS) Mobility Management failures 5.3.2. Call Control failures

5.3.2.1. Concept

This subsection describes failures on the Call Control (CC) protocol. The CC protocol is responsible for CS call establishment and clearing procedures, call information phase procedures etc. CC procedures can only be performed if a MM context has been established between the UE and the CN (subsection 5.3.1).

5.3.2.2. Failure symptoms, identification and fixes for improvement

Any occurrence of a CC Disconnect message (either UE or CN initiated) with specified cause other than “normal event”

Ubnormal CC Release

Uu or Iub or Iu

Any occurrence of a CC Release / Release Complete message (either UE or CN initiated) with specified cause other than “normal event”

Table 23: Identification of CC failures in interface traces

Table 24 below is listing the PM KPIs of the CC failures as they can be retrieved by the PM system of the 3G-MSC:

PM system

Counter / KPI⁵ KPI Name / Description

3G-MSC NoCCDisconnectUbnormalEvent / NoCCDisconnects * 100 Ubnormal CC Disconnect Rate 3G-MSC NoCCReleaseUbnormalEvent / NoCCReleases * 100 Ubnormal CC Release Rate

Table 24: PM KPIs for CC failures

Depending on the specified failure cause the failure might be due to missing resources (e.g. “requested circuit/channel not available”), drive test configuration issue (e.g. “User busy”) or protocol failure.

For the root cause analysis please check the timer settings supervising the CC protocol in [5] chapter 11.3. The settings of these timers are not configurable.

5.3.3. Session Management failures 5.3.3.1. Concept

The main function of SM is to support the PDP context handling of the PS services. The SM comprises procedures for identified PDP context activation, deactivation and modification. SM procedures for identified access can only be performed if a GMM context has been established between the UE and the CN (subsection 5.3.1).

5.3.3.2. Failure symptoms, identification and fixes for improvement

The failure messages are retrieved from [5]. Table 25 below is listing the SM failures as they can be retrieved by interface traces:

Problem Trace Trigger

SM Activate PDP Context Reject

Uu or Iub or Iu Any occurrence of a SM Activate PDP Context Reject message sent by the CN. The specified rejection cause is giving an indication of the type of failure e.g. protocol error, missing or faulty APN, lack of resources etc.

SM Activate Secondary PDP Context Reject

Uu or Iub or Iu Any occurrence of a SM Activate Secondary PDP Context Reject message sent by the CN. The specified rejection cause is giving an indication of the type of failure e.g.

5 Dummy names

protocol error, missing or faulty APN, lack of resources etc.

SM Request PDP Context Activation Reject

Uu or Iub or Iu Any occurrence of a SM Request PDP Context Activation Reject message sent by the UE. The specified rejection cause is giving an indication of the type of failure e.g.

protocol error, feature not supported, lack of resources etc.

SM Modify PDP Context Reject

Uu or Iub or Iu Any occurrence of a SM Modify PDP Context Reject message sent by the CN. The specified rejection cause is giving an indication of the type of failure e.g. protocol error, service option not supported, lack of resources etc.

Table 25: Identification of SM failures in interface traces

Table 26 below is listing the PM KPIs of the SM failures as they can be retrieved by the PM system of the GGSN:

PM system

Counter / KPI KPI Name / Description

SGSN (1-((SM.FailActPdpCtxMs.Cause) / (SM.FailActPdpCtxMs.Cause+SM.SuccActPdpCtxMs))

)*100

Session establishment success rate

SGSN SM.SuccModPdpContextSgsn.U /

SM.AttModPdpContextSgsn.U * 100

Network originated session modification success rate

Table 26: PM KPIs for SM failures

The most common SM failures are PDP Context activation failures due to wrong or missing APN or if the user is not allowed to subscribe to PS services. This is also a typical configuration issue of the drive test equipment.

For the root cause analysis please review also the timer settings supervising the SM protocol in [5] chapter 11.2.3. The settings of these timers are specified and not configurable.