Introduction to the FARS Feature

When a UE service is faulty, OM engineers need to quickly locate and rectify the fault. The
U2000 provides the Fault Assistant Resolved Solution (FARS) feature to help OM engineers
collect the raw signaling data of a specified object and range. The data post-analysis function of
FARS helps OM engineers filter and analyze the collected raw data so that they can locate the
fault within the shortest time.

Overview
As a feature of the U2000, the FARS consists of the graphical user interface (GUI) for tracing
signaling and the signaling trace service, namely, FarsService. Running on the U2000 server as
an independent service, the FarsService provides GUIs for users to process services, manage
collection tasks, and monitor collection tasks.

The FARS provides the data collection and data analysis functions to help OM engineers locate
faults. Data collection depends on the trace or monitoring tasks created on the U2000 client.
When creating trace or monitoring tasks, OM engineers need to specify the information about
the object to be traced or monitored and the information about the NE related to the object.
For example, when creating a UE trace task, OM engineers need to specify the UE identity, such
as the IMSI. When creating a cell trace task, OM engineers need to specify the cell information
such as the cell ID. Based on the preset task information, the U2000 collects data such as the
signaling interacted between NEs, internal NE messages, NE resource usage, and traffic. In
addition, the U2000 displays the collected data on the U2000 client for OM engineers to check
or export. The FARS provides various post-analysis functions for collected data, such as
message comparison and message filtering. These functions help OM engineers locate faults.

NOTE:

In the event of a subscriber service fault, to locate the fault cause as soon as possible,
FARS helps O&M engineers collect raw signaling data of a specified object and scope
and analyzes the data. The data is saved as files on the U2000 server or recorded in a
database. If FARS tasks are deleted manually or due to timeout, the data will be deleted
accordingly. Data collected for FARS tasks may involve personal data of subscribers, such
as IMEISV, IMEI, MSISDN, MS IP address, IMSI, location information in the MDT, client
user name, client IP address, and client MAC address. To prevent personal data from
disclosure, you are advised to delete the data after it is used. In addition, FARS provides
the anonymization function and NEs provide the function of anonymizing security-
sensitive data source. If the anonymization function is enabled, FARS encrypts IMSIs and
IMEIs using HMAC-SHA256 and does not encrypt location information and unit ID. For
eNodeBs and pico base stations, FARS encrypts their IP addresses using HMAC-SHA256
or stores the last 16 bits of the IP addresses. You are advised to conform to laws and
regulations in related countries and take adequate measures to protect personal data.
Application Scenario
The FARS provides various trace or monitoring functions. When processing service problems,
such as multiple call drops, poor-quality handovers, and poor quality of voice services, or when
the rate of a data service is low or a data service is unavailable, OM engineers can customize
different policies based on site requirements.

Type Application Scenario

Type Application Scenario

Trace Locating link faults

To locate link faults when NEs fail to be interconnected initially, field
engineers can create a link trace task on the U2000 and check whether the
negotiated link parameters of NEs are consistent or whether the link data is
correct.

Handling complaints of subscribers

When using radio network services, subscribers file complaints related to
quality of service (QoS) if the services do not meet the requirements. In
such a case, OM engineers can create a trace on the U2000 to analyze the
signaling of standard interfaces during a call or analyze the cell data to
locate and rectify network faults.

Testing networks
If a new device is used, the new device needs to be tested whether it meets
the requirement of each test item. Field engineers can create a trace on the
U2000 and then collect the data generated during the drive test to check
whether the existing network meets the requirements.

Locating UE faults
When a UE is faulty, OM engineers can create a trace on the U2000 to
obtain the signaling during a call.

Checking the radio coverage of BTSs

To check whether the radio coverage of BTSs meets the network design
requirements, field engineers can create a trace task on the U2000 during
the drive test. By collecting the data generated during the drive test, field
engineers can check whether the radio coverage rate meets the
requirements.

Testing new network features

When applying a new feature in an area, network planning engineers can
create a trace on the U2000 to test the implementation of the feature. The
new network feature may be an optimized algorithm or an optimized
network architecture.

Identifying interworking call failures for a convergent GMSC

When interworking calls between a local network with another carrier's
network using the convergent GMSC fails, and a large number of calls fail,
you can create trace tasks on the U2000 to collect trace messages of a
single user or interface trace messages between NEs for fault identification.
Type Application Scenario

Monitoring Monitoring device status in the event of heavy traffic

The device status in scenarios of heavy traffic, such as during holidays and
festivals, is monitored, helping identify and handle exceptions in time.

Checking the alarm recovery status after handling NE alarms

After handling alarms such as high CPU usage and over-high board
temperature, OM engineers can check the alarm recovery status using the
monitoring function.

Monitoring resource usage

OM engineers can monitor the TRX performance, MAC error frames, IP
packet loss, and status of links on the air interface to evaluate network
status and adjust network parameters in time.

Trace or Monitoring Principles

Figure 1 shows the interactions between the U2000 and NEs after a trace or monitoring task is
created.

Figure 1 Trace or monitoring principles

1. The U2000 issues the predefined trace or monitoring task parameters in commands to an
NE. After the commands are issued successfully, a corresponding trace or monitoring task
is registered on the NE.
If multiple NEs to be traced/monitored are defined in a trace or monitoring task, the
U2000 issues the commands to all the NEs defined in the task.
 2. Based on the trace or monitoring parameters, the NE that receives the commands
identifies the targets to be traced/monitored, such as interfaces, cells, subscribers, boards,
and links.
If the NE determines that this trace or monitoring task requires another NE, it issues the
commands for registering this trace or monitoring task to the target NE.

3. The NE that receives the trace or monitoring task periodically collects trace or monitoring
data.

4. The NE reports the trace or monitoring result to the U2000 as a file or message.

5. The U2000 parses the trace or monitoring result and then saves the parsing result to the
database. OM engineers can check the result on the U2000 client.

Parent Topic: FARS Overview

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.
Next topic >