Download doc - Technical Case Writing Guidelines_en

Technical Case Writing Guidelines Confidentiality:

Document Name Technical Case Writing Guidelines

Version V01.30 Effective Date 2013-12-12

Document Code

BPA

L1 13.0 Manage Base Support

Prepared By Yuan Linghui (ID: 00066393) L2 13.10 Manage Knowledge

Reviewed ByHuang Junhua (ID:

00162500)L3 Manage Explicit Knowledge

Approved By Tan Xinde (ID: 00118692) L4

Process OwnerKnowledge Management

Department Leader

Applicability Global Standard RoleTechnical case author and technical

case reviewer

Relevant Process, Guidelines, or Guide

Document Name Document Code

Manage Explicit Knowledge Process

1 Purpose

This document provides guidelines for engineers to write technical cases that are easy to find and easy to

understand so that these cases can help diagnose and solve problems. This document is applicable to all

technical cases to be submitted through the iCase system.

2 Abstract

This document provides guidelines for writing key fields of a technical case with examples.

3 Definition of Terms

Term Definition

Technical case

A technical case is the information about the symptom, causes, recovery measures, preventative

measures, and solution of a device or network fault that can be shared among customers and

engineers or technical problems that are frequently asked by customers.

Case

Nomination

Case nomination refers to the process when an iCare SR is resolved without any cases used

during searching knowledge in iCare system.

2023-04-22 HUAWEI Confidential Page 1 of 10


4 Content

4.1 Guidelines for Writing nomination Cases

4.1.1 Timeliness

Cases that are created at the request of iCare must be compiled and submitted for review within 10 days

after the compiler approves the request.

4.2 Guidelines for Writing Cases and Managing Operations

4.2.1 No Case Duplication

1) When submitting or reviewing a case, the author should search in case system to see whether there is

a duplicate case, which with same information in Problem Description, Cause, and Solution.

Avoid releasing duplicate cases on the system.

2) If Troubleshooting process and solution already exist in Documentations and Guides(Product

documentation,Precautions,Rectification and Bulletins,Release Documentation,Technical

Guide,Functions and Features),don’t create a case;

3) Do not duplicate information from archived documents by copying and pasting it.

4.2.2 Case Optimization and Update

If you want to correct errors in an existing case or add new information to it, follow the case optimization

process to update the case. Do not directly delete the existing case and upload a new one because this will

invalidate other documents and email links.

4.2.3 Practicality

Technical cases are written to help engineers or customers with their work and studies related to Huawei

products. The case content must be concise. It can be just a description of the handling process of a

specific fault or the reply to a specific question.

4.2.4 Writing Instructions

● Use correct punctuation marks.

Use punctuation marks correctly. Use half-width punctuation marks in English sentences. Do not

confuse full-width punctuation marks with half-width punctuation marks.

Do not overuse the exclamation mark (!). A counterexample is as follows:

Otherwise the speed would be extremely slow. It takes about two hours!!!

● Avoid spelling mistakes.

● Avoid using colloquial language.

For example, avoiding saying "We've done it", "our company", "our site", "our end", and "us".

● Do not include information that is technically irrelevant in your cases.



Counterexamples are as follows:

We reinstalled the system for the user because the user has a good relationship with us.

Suddenly, we were struck by an idea; The carrier does not admit this issue

The key is to find evidence.

We have asked for help from Huawei technical support engineers.

After the fault occurred, local Huawei offices tried to resolve it through remote phone

instructions but the issue persisted. Starting from the morning on February 2, engineers

dispatched by local Huawei offices tried many methods to restore services but the transmission

remained intermittent. As the fault could not be identified or rectified in a timely manner, the

pressure on local Huawei offices increased.

● Do not provide ambiguous conclusions.

For example, do not say "probably", or "supposedly".

● Provide formal product names or version numbers.

Provide product names or version numbers. That is, use the official names or numbers that Huawei

presents to its customers. The format of version numbers must comply with Huawei specifications.

For example, a C&C08 switch cannot be described as "a 08 device", and V610R105M8008 cannot

be described as "the 8K version".

If the case content is closely related to a patch version, specify the patch version in the version

description.

● Case generated by nomination should be written in English unless its from Chinese region.

4.2.5 Security and Confidentiality

To avoid infringement of right and disclosure of secrets, do not specify the names of individuals,

organizations, or countries. You can use codes to represent these names if necessary. Information related

to product defects must be strictly managed based on the confidentiality levels of documents.

● Comply with Huawei's requirements of network security behavior.

Do not include any malicious code, malicious software, backdoor virus, or undisclosed interfaces,

accounts, or default passwords in your cases.

Do not include any tools or methods that can be used to attack customers' networks or crack client

passwords.

Do not include information about how to illegally obtain software versions, patches, or licenses.

● Do not specify the names of sites, places, or individuals.

Do not specify the names of sites, places, or individuals. This is especially important for networks

such as government communication networks, communication networks for important activities, and

military networks. Do not disclose the location or contact information, or even the networking

information in the case description. If necessary, use the phrase "a certain site" instead of the specific

name.

● Abide <Network Security Forbidden Words and Cautioned Words Used Rules>

（http://w3.huawei.com/info/en/doc/viewDoc.do?did=545921&cata=123551）



● Do not specify names of carriers.

Do not specify names of carriers in your cases. If necessary, use phrases such as "a certain site" or

"an external site" instead. When describing interconnection or interworking problems, do not

specify carriers' access codes. For example, use 179X9 when referring to access code 17909.

● Use proper expressions when referring other vendors or their equipment.

Use codes when referring to a vendor. The format is "vendor" + initial capital letter. For example,

use vendor E to represent Ericsson, vendor B to represent Shanghai Bell, and vendor S to represent

Siemens. As for equipment, the format is initial capital letter + X (the length of X should be

consistent with that of the equipment name). For example, S1240 is referred to as SXXXX.

The following table lists of the codes of some vendors:

Vendor Vendor Code

Alcatel-Lucent Vendor A

Cisco Vendor C

Datang Vendor D

Ericsson Vendor E

Fujistu Vendor F

Juniper Vendor J

NSN Vendor N

NEC Vendor NEC

Nortel Vendor NL

Motorola Vendor M

ZTE Vendor Z

Shanghai Bell Vendor B

Siemens Vendor S

UT Vendor U

Lucent Vendor L

3com Vendor 3com

JULONG Vendor J

Nokia Vendor NK

Harbor Vendor H

Gaoke Vendor G

● Exercise caution when using sensitive words related to national or political information.

1. Exercise caution when using sensitive words such as "public security bureau", "public security



unit", "state council", "xx provincial government", "Chairman xx", "Premier xx", and "xx

military region". Avoid disclosing national secrets.

2. If possible, do not specify country names. Do not use religiously or politically sensitive words.

3. Lawful interception is a confidential action authorized by national laws. All information related

to lawful interception, including lawful interception protocols, is considered to be national

secrets. The confidentiality level of cases that involve security interception, public security

interception, public security bureau interception, and lawful interception must be Huawei

engineers.

4.3 Writing Guidelines for Key Fields

4.3.1 Title (Mandatory)

1. For a fault, write the symptom and cause of a fault in the title.

You are advised to use the “symptom+ cause” format, such as “XXX Fails due to XXX Cause”.

2. For an FAQ,write the title in any of the following formats:

● FAQ - What Is XXX?

● FAQ - Why XXX?

● FAQ - How to Do XXX?

3. The content in the title should be clear and concise and with a maximum of 200 characters.

4. The title should be one sentence, don’t add interpunction mark in title.

4.3.2 Product Information (Mandatory)

1. Must choose product name or PBI information.

2. If case refers to Multi-product, need click “Yes” in “Multi-product”.

4.3.3 Fault Type (Mandatory)

● Select a fault type based on the symptom, but not based on the root cause or solution.

● If there are multiple symptoms, select a fault type based on the primary symptom.

● If some new faults or FAQ cases don’t fall into any existing L2 or L3 Fault Type,select Others for

Fault Type.

4.3.4 Problem Description (Mandatory)

1. For a fault:

Write the symptom, alarm information, version information, networking overview (including related

devices) and operation scenario. If there are multiple symptoms, concentrate on the primary symptom.

If the fault occurred after some operations, the case need describe the operation details and related MML

commands.

If some counters issue, the case need show the counter ID and name.

If has alarm, the case need show the alarm ID and name.

Example:



AMR call drops always occur in a hotel in Huawei's new UMTS network, and the communication is poor.

What's more, calls cannot be connected in some place of the hotel.

2. For an FAQ:

Write the question.

Example:

Multiple accounts and packages are defined in the PPT service. The following describes how to configure

a multiaccount package.

4.3.5 Handling Process (Mandatory)

For a fault:

A handling process is a process in which you use product knowledge to analyze a fault based on the

collected fault information, and perform diagnosis operations to find the cause and solution for a fault.

Write the analysis process and fault diagnosis steps in a well-organized and logical manner and provide

the result of each step.

Observe the following rules when you write the fault diagnosis steps:

● Write steps that help diagnose a fault effectively, including the methods, commands, tools,

documents, and concurrent symptoms involved in the steps.

● Provide a clear result for each step. You are advised to use sentences that contain words indicating a

clear result, such as "The XXX cause is ruled out" or "The root cause is XXX."

● If no step that rules out a cause is involved, write the step in which the root cause is found.

Example:

1. The hotel where call dropping occurs is close to three sites. Some areas in the hotel have poor call

quality. Call dropping may occur due to pilot pollution because the areas receive many cell pilot

signals. In a test conducted in the hotel, a mobile phone receives signals from two or three cells. The

primary cell varies according to the location of the mobile phone. However, the signal in the primary

cell is at least 5 dB stronger than signals in other cells. Pilot pollution is ruled out as a cause for call

dropping.

2. Add intrafreqncell is run to query the configuration of neighboring cell relationship of sites 19, 20,

and 34. The query result shows that neighboring cell relationship has been configured for the three

sites. Failure to configure neighboring cell relationship is ruled out as a cause for call dropping.

3. A test is conducted using several types of terminals in the hotel room. The test result shows that call

dropping occurs almost at the same location (the corner) for all types of terminals. Call dropping

does not occur outdoors. Terminal type is ruled out as a cause for call dropping.

4. A test is conducted to determine whether high received total wideband power (RTWP) is the cause.

A dialing test is conducted inside the hotel and user signaling is traced on the radio network

controller (RNC). The tracing result shows that call dropping occurs after the UE switches between

cell of site 19, cell 10019, cell 20019, and cell of site 34. The tracing result contains "received-total-

wide-band-power=408". That is, RTWP = 408/10 - 112.1 = -71.3dBm. This is a high value. The

cause is synchronization failure. Several cells have high RTWP values. When a UE moves to these

cells from other cells, out-of-synchronization occurs for the uplink signals and call dropping occurs.

For an FAQ:



Write "N/A".

4.3.6 Cause (Mandatory)

1. For a fault:

A root cause is found during the handling process. It leads to a fault and is used for working out a

solution.

Example:

It’s a software bug in xxx version or scene.

Hardware issue.

temporary .tmp files not deleted in a timely manner

2. For an FAQ:Write "N/A".

4.3.7 Solution (Mandatory)

For a fault:

Write the workaround, preventative measure, or solution in this field. Specify whether the operation you

provide is a workaround, a preventative measure, or a solution so that engineers can perform an operation

correctly.

If need operation, the case must include operation steps, MML commands and each step check results.

The case must clear the solution operation risk if have any.

Example:

1. Workaround: Switch cross-connect services to the cross-connect board in slot 9.

2. Preventative measure: When the SSN1EAS2 board is used, do not use the cross-connect board in

slot 10 as the work board for OSN3500 and OSN7500.

3. Solution: Upgrade the software and logic of the SSN1EAS2 board on site to V100R10C03SPC203.

For an FAQ:

Provide a detailed answer to the question.

4.3.8 Suggestions (Optional)

Write the suggestions on how to prevent such a fault, such as routine maintenance suggestions. If you do

not have any valuable suggestions, do not specify this field.

Example:

Fault: Services are affected due to poor contact after a cable is connected to a network interface. This is

resulted from poor equipment room environment. The connector of the cable is covered in dust.

You can write the following suggestion for the preceding fault: Clean the equipment room routinely.

4.3.9 Keywords (Mandatory)

1. Write a few (generally one to three) words that are closely related to the technical case;

2. Separate them by space or comma (,);

3. Use the known information, such as fault symptom and alarm information as the keywords.



4. Do not use high frequency words, such as switch, trunk, 128 modules.

Example:

BB tone distortion Slow connection of intelligent public telephone calls Repeated triggering prevention

FCS_ERR BUS_ERR N1EAS2

4.3.10 Attachment (Optional)

Attachments are a supplement to the problem description or analysis process. The attachments may

include the snapshots of the problem, networking diagram, information tracing results, and signaling

tracing results. Observe the following rules when you specify the attachments:

● Do not attach archived documents, but provide a link for archived documents.

4.4 Case Example

Title：Single subscriber board failure causes time slot deadlock, and then causes the dialing tone cannot be heard

Case code：TC0000016029

Published On:：2004-12-03

Author：Chen Zhenrong

Product Information ： Fixed Network Access Network FTTx&xDSL UA5000 Series HONET UA5000

Fault Type：Service Voice service Announcement error

Keywords：dialing tone, Motherboard fault, cross feeder connection, timeslot

Problem Descriptiong：Several subscribers of an ONU complain that it is difficult for them to make phone calls (cannot hear dialing tone), but the incoming calls are normal.The ONU main control frame is the

GV5-I, the upper equipment is interconnected with the SXXX with 2M cable, passing through the STE, the lower

equipment is connected to the ONU passing through the built-in optical transmission equipment OptiX155A, the

subscriber frame is the RSP subscriber frame of the HONET ONU1000 cabinet, and the left and right RSP boards

provide a 2M each.

On the transmission side, the AN side, and the STE side, no transmission alarm or equipment alarm of the ONU is

found. The several complaining subscribers are of the same ONU frame.

Handling Process：Check whether subscribers of the whole frame hear no dialing tone. This problem might be caused by:

1. subscriber board failure or backplane failure (wet backplane or connection failure)

2. DTR board failure on the STE side

3. one-way audio of the 2M

4. subscriber board type problem

5. AV5 network board failure

6. dialing mode of the exchange and dialing configuration of the phone

Handler Process:

1. Perform dialing test for most of the subscribers in this frame: subscribers of the whole frame are failure.

2. Exchange the ASL board slot and replace the RSP board: the failure still exists. So we can exclude the board

problem.



3. Check the 2M: no cross-connected pair. Replace the 2M cable from the RSP to the tributary board and connect

the 2M on the tributary board to other reserved port (NE side): the failure still exists.

4. Replace the backplane: failure remains.

5. Check the subscriber board type: the feed distance is increased through enhancing feed voltage for the

CC0CASL. But if the distance is not that far, the level configuration of the CC0CASL is higher than that of the

CC08ASL. Therefore, when cooperating with some machine types, the signal cannot be received due to too high

level. Sometimes the dialing tone cannot be heard. But the current Huawei STE and subscriber board are

CC08ASL; this problem is of little possibility.

6. Because only one frame is failure, while subscriber service in other frames is normal, we can exclude backplane

failure of the GV5-1 main control board, receiving failure of the DTR board, dialing mode error of the exchange

side, and the dialing configuration of the phone.5. View the HW-TS figure, and we find time slot deadlock.

Because the backplane is replaced, guess the subscriber board failure. Block another 2M link and remove all the

subscriber boards, and then plug them in from the first subscriber board slot. Plug in a subscriber board, and dial

the phone at the same time. After it is configured as normal, plug in another subscriber board. When the fifth

subscriber board is plugged in, the time slot deadlock occurs.

7.This indicates the subscriber board has problem. Replace the board and the failure disappears.

Root cause：The subscriber board has problem lead to the time slot problem.

Solution：subscriber board has problem. Replace the board and the failure disappears.

Suggestions and Summary：When single frame has problem, the problem is often about the resource of this frame ,such as 2M highway, backboard, RSP/PV8 board.

Attachment：Related Chinese Case Code：TC0000015777

Related link：

5 Related Documents

No. Document Name Document Name

6 Record Keeping

Record

Name

Submitted

By

Kept

By

Place Where the

Record Is KeptTime Duration

Handling upon

Expiry

7 Document Preparation and Change History

Version Prepared/Revised By Date Revision Description and Reason Approved By


