Contents

1   Introduction

This instruction concerns alarm handling.

1.1   Alarm Description

The threshold alarm E-CSCF Receives No LRF Response is issued when the connection to the Location Retrieval Function (LRF) does not work properly.

The alarm is based on the counter cscfMlHttpNoResponses.

The alarm is raised when the number of cscfMlHttpNoResponses has reached or exceeded its configured thresholdHigh within the time period configured by thresholdRateOfVariation and granularityPeriod.

The alarm is automatically ceased when it reaches or goes below the configured thresholdLow value.

The default values related to this alarm are: thresholdRateOfVariation=PER_GP, granularityPeriod=FIVE_MIN, thresholdHigh=2, and thresholdLow=0. This means that when the counter value is 2 or higher, the alarm is raised when the granularity period is ended. The alarm is ceased when the counter cscfMlHttpNoResponses has reached a value of 0 at the end of a granularity period.

Note:  

The thresholds for raising and ceasing this alarm are configurable. The default distinguished name for the thresholds is ManagedElement=<node_name>, SystemFunctions=1, Pm=1, PmJob=CscfMlThreshold,MeasurementReader=cscfMlHttpNoResponsesMeasReader, PmThresholdMonitoring=cscfMlHttpNoResponses.

It is not possible to change threshold values once they have been set. To change a threshold, first the PmThresholdMonitoring instance must be deleted and recreated with required thresholdHigh and thresholdLow.

For more information, refer to Performance Management.

The possible alarm causes and the corresponding fault reasons, fault locations, and impacts are described in Table 1.

Table 1    Alarm Causes

Alarm Cause	Description	Fault Reason	Fault Location	Impact
The PM counter cscfMlHttpNoResponses has reached or exceeded its configured upper threshold value.	The number of HTTP communication errors has reached or exceeded the configured threshold.	Peer entity communication problems (HTTP Responses): Connection Fault Time-out NoDnsResult InvalidResponse	Peer protocol communications problems between the Emergency Call Session Control Function (E-CSCF) and the LRF	Connection problems on Ml HTTP traffic interfaces causing communications issues with destination LRF.

Note:  

An alarm can appear as a result of maintenance activity.

The alarm attributes are listed and explained in Table 2.

Table 2    Alarm Attributes

Attribute Name	Attribute Value
Major Type	193
Minor Type	6684688
Managed Object Class	MeasurementReader
Managed Object Instance	ManagedElement=<node_name>,SystemFunctions=1, Pm=1, PmJob=CscfMlThreshold,MeasurementReader=cscfMlHttpNoResponsesMeasReader
Specific Problem	E-CSCF Receives No LRF Response
Event Type	communication (2)
Probable Cause	x733CommunicationsProtocolError (305)
Additional Text	cscfMlHttpNoResponses. Check connection to LRF. You may need to change value of ecscfHttpRequestTimer parameter
Perceived Severity	major (4)

1.2   Prerequisites

This section provides information on the documents, tools, and conditions that apply to the procedure.

1.2.1   Documents

This instruction references the following documents:

• Performance Management
• Managed Object Model (MOM)

1.2.2   Tools

No tools are required.

1.2.3   Conditions

No conditions.

2   Procedure

Note:  

If the reason for the alarm has disappeared after the granularity period, the alarm automatically ceases.

Do the following:

1. Check that the LRF address in the E-CSCF is correctly configured (ecscfEmergencyLRFAddress).
2. Check that the HTTP response time in the E-CSCF is correctly configured (ecscfHttpRequestTimer).
3. Check that the LRF address has proper resolution in the Domain Name System (DNS).
4. Analyze a potential error response from the LRF and take appropriate actions.
5. Detect and eliminate any connection problems to the LRF.
6. Confirm that the alarm has ceased. If the alarm remains, consult the next level of maintenance support. Further actions are outside the scope of this instruction.
7. Job is completed.