You are on page 1of 121

XỬ LÝ BADCELL MẠNG VÔ TUYẾN

MỤC TIÊU BÀI GIẢNG

Nắm bắt được bộ chỉ tiêu chất lượng mạng vô tuyến 2G/3G/4G đã được
Tập đoàn ban hành.

Nắm được các tiêu chí đánh giá, điều kiện của Badcell 2G/3G/4G.

Các bước chính trong việc phân tích và xử lý Badcell 2G/3G/4G.

Nâng cao kinh nghiệm trong công tác xử lý KPIs, xử lý phản ánh khách
hàng mạng vô tuyến.
ĐỐI TƯỢNG HỌC TẬP

Cán bộ kỹ thuật, kỹ sư vận hành khai thác của VNPT-NET, VNPT


tỉnh/thành phố cần học xong bài giảng tối ưu cơ bản mạng vô
tuyến để nắm vững nội dung phân tích logfile hỗ trợ cho việc
phân tích logfile xử lý badcell.
1. Các chỉ tiêu mạng vô tuyến

TRONG QUÁ TRÌNH HỌC, MỜI CÁC BẠN KÍCH VÀO HÌNH
ẢNH ĐỂ HIỂN THỊ HÌNH ẢNH LỚN VÀ CHI TIẾT HƠN
1.1. Chỉ tiêu mạng vô tuyến 2G
Định nghĩa
- CSSR là tỷ lệ thiết lập cuộc gọi thành công.
- DCR là tỷ lệ cuộc gọi bị kết thúc bất thường.
- HOSR là tỷ lệ chuyển giao cuộc gọi thành công.
- SDCCH-Blocking Rate là tỷ lệ nghẽn kênh SDCCH.
- TCH Blocking Rate là tỷ lệ nghẽn kênh lưu lượng TCH.

Phương pháp xác định


- Thống kê phân đoạn truy nhập vô tuyến từ hệ thống OMC (PM-Tool, RIMS).

Tần suất và Phương pháp thống kê.


- Thống kê theo tháng theo từng mức mạng (Tỉnh/TP, BSC, RNC…).
1.2. Chỉ tiêu mạng vô tuyến 3G
Chỉ tiêu chất lượng mạng vô tuyến 3G-PS
3G-CS
Định nghĩa
- Access
CSV Call
Success
Setup Success Ratelà-tỷCSSR
Rate - ASR lệ phiên
là tỷtruy
lệ thiết
cập dữ
lập liệu
cuộcthành
gọi thoại
công.(circuit) thành công.
- Drop
CSV Drop - DRRate
Rate Call là tỷ -lệDCR
rớt phiên
là tỷ lệ
dữcuộc
liệu.gọi thoại (circuit) bị rớt.
- Radio
CS Intra
Resource
- Freq Handover
Congestion
Success RRCR
Rate - Rate - S.HOSR
là tỷ lệ nghẽn
là tỷ lệtàicuộc
nguyên
gọi chuyển
vô tuyến.
giao mềm thành công.
- Intra-Freq
CS Inter - Freq
Handover
Handover
Success
Success - S.HOSR
Rate Rate - IF.HOSR
là tỷ lệlàphiên
tỷ lệ cuộc
dữ liệu
gọichuyển
chuyểngiao
giaomềm
sangthành
tần sốcông.
khách thành công.
- Inter-Freq
CS Inter - RAT
Handover
Handover
Success
Success - IF HOSR
Rate Rate - IRATlàHOSR
tỷ lệ phiên
là tỷ lệ
dữcuộc
liệu gọi
chuyển
chuyển
giaogiao
sangsang
tần công
số khác
nghệ
thành
vô tuyến
công.khác thành
công.
Phương pháp xác định
-Phương
Thống kêpháp xác định
phân đoạn truy nhập vô tuyến từ hệ thống OMC (PM-Tool, RIMS).
- Thống kê phân đoạn truy nhập vô tuyến từ hệ thống OMC (PM-Tool, RIMS).
Tần suất và Phương pháp thống kê
-Tần suất
Thống kê và Phương
theo pháp
tháng theo thống
từng kê (Tỉnh/TP, BSC, RNC…)
mức mạng
- Thống kê theo tháng theo từng mức mạng (Tỉnh/TP,BSC, RNC…).
1.3. Chỉ tiêu chất lượng mạng vô tuyến 4G/LTE
Định nghĩa
Phương pháp xác định
Thống
-CSFB
RRC kê phânSuccess
đoạn
Preparation
Call Setup truy
Success nhập
Rate
Rate -vô tuyến từlàhệ
CSFB_Pre_SR
- RRC_CSSR tỷ thống
lệ tỷ lệOSS.
làthiết lập vềvô
kết nối
Fallback mạng
tuyến từ UEthành
3G/2G đến eNodeB
công. (RRC) thành công.
CSFB Pre SR = (Số lượng cuộc gọi CSFB được Fallback thành công/Số lượng cuộc gọi CSFB yêu cầu)*100%.
RRC_SR = (Số lượng RRC kết nối thành công/Số lượng RRC yêu cầu)* 100%.
Tần suất và Phương pháp thống kê
- Thống
VoLTE
ERAB kê Setup
ERAB
Call theo tháng
Call theo
Setup
Success từng- ERAB_CSSR
Success
Rate mức
Rate mạng (Tỉnh/TP,eNodeB…)
- VoL_ERAB_CSSR tỷ lệ thiết
là tỷ lệ thiết lậplàBearer từ UElập
đến S-GWtừ
Bearer UE đến
thành S-GW cho dịch vụ
công.
VoLTE thành
ERAB_SR công.
= (Số lượng ERAB kết nối thành công/Số lượng ERAB yêu cầu)* 100%.
VoL ERAB_SR = (Số lượng VoLTE ERAB kết nối thành công/Số lượng VoLTE ERAB yêu cầu)*100%.
Call Setup Success Rate (All Service) - CSSR là tỷ lệ thiết lập phiên dữ liệu thành công của UE.
VoLTE
CSSRIntra
= (SốFrequency
lượngRRC kếtHO Success
nối thành Rate
công/Số - VoLTE_IntraFreqH0_SR
lượng RRC yêu cầu) *(Số lượng ERAB tỷ lệ
là kết nốicuộc gọi chuyển
thành công/Số lượng giao
ERAB cùng tần100%.
yêu cầu)* số thành
công của cuộc gọi VoLTE.
Data Drop
VoLTE Call Rate - DCR
IntraFreqHO_SR là tỷ lệ
= (Số lượng giaodữ
phiên
chuyển liệu
cuộc gọibị rớt. cùng tần số thành công/Số lượng chuyển giao cuộc gọi VoLTE cùng tần số yêu
VoLTE
CDR = (Số lượng cuộc gọi kết thúc bất thường/Số lượng cuộc gọi) * 100%.
cầu)*100%.

Intra Frequency
VoLTE HO Success
Inter Frequency Rate - IntraFreqH0
HO Success SR là tỷ lệ cuộc gọi là
Rate- VoLTE_InterFreqHO_SR chuyển
tỷ lệ cuộc
giao cùng tần số giao
gọi chuyển thành tần số thành
công.
khác
công của cuộc gọi
IntraFreqHO_SR VoLTE.
= (Số lượng chuyển giao cùng tần số thành công/Số lượng chuyển giao cùng tần số yêu cầu)*100%.
VoLTE InterFreqHO_SR = (Số lượng chuyển giao cuộc gọi VoLTE khác tần số thành công/Số lượng chuyển giao cuộc gọi VoLTE khác tần số yêu
InterFrequency
cầu)*100%. Handover Success Rate - InterFreqHO_SR là tỷ lệ cuộc gọi chuyển sang tần số khác thành công.
InterFreqHO_SR = (Số lượng chuyển giao khác tần số thành công/Số lượng chuyển giao khác tần số yêu cầu)*100%.
Used Downlink Resource Block - Used_DL_R là hiệu suất sử dụng tài nguyên RB hướng downlink.
Inter-RAT HO =Out
Used_DL_RB (Số Success Rate RB
lượng tài nguyên (LTE
đượctosửUMTS)
dụng/SốIRATHOL2W_SR
lượng tài nguyên RB là tỷ lệ cuộc gọi chuyển giao sang công nghệ vô
có sẵn)*100%.
tuyến 3G thành công.
Used Uplink
IRATHO L2WResource Block
SR= (Số lượng - Used_UL_RB
chuyển 3Ghiệu
giao từ 4G sang là thànhsuất sửlượng
công/Số dụngchuyển
tài nguyên hướng
RBsang
giao từ 4G Uplink.
3G yêu cầu)*100%.
Used_UL_RB = (Số lượng tài nguyên RB được sử dụng/Số lượng tài nguyên RB có sẵn)*100%.
2. Các tiêu chí đánh giá và phân loại Badcell mạng vô tuyến
2.1. KPIs đánh giá Badcell 2G
2.1.1. Tỷ lệ thiết lập cuộc gọi thành công - Call Setup Succes Rate
Định nghĩa: Công thức CSSR được tính qua tỉ lệ thành công của hai giai đoạn là giai đoạn SDCCH và giai đoạn TCH. Tỉ lệ thành công giai đoạn
SDCCH được tính thông qua tương quan giữa tổng số lần rớt SDCCH và tổng số lần gán SDCCH thành công. Tỉ lệ thành công giai đoạn TCH được
tính thông qua tương quan giữa số lần MSC gán kênh (ASSIGNMENT REQUEST) và số lần MS truy nhập kênh TCH/CIC thành công (ASSIGNMENT
COMPLETE). Dạng tổng quát của công thức có thể được thể hiện như dưới:
𝑪𝑺𝑺𝑹 = 𝟏𝟎𝟎% ∗ 𝟏 − 𝑺𝑫𝑪𝑪𝑯𝑫𝑹𝑶𝑷𝑹𝑨𝑻𝑬 ∗ 𝑻𝑪𝑯𝑨𝑺𝑺𝑰𝑮𝑵𝑺𝑼𝑪𝑪𝑬𝑺𝑺𝑹𝑨𝑻𝑬

Tên KPI Tỷ lệ thiết lập cuộc gọi thành công Công thức

QĐ 1705 Call Setup Success Rate - CSSR

Pmtool Name Call Setup Success Rate V1

𝑀𝐶138+𝑀𝐶137+𝑀𝐶07 𝑀𝐶140𝐴− 𝑀𝐶142𝐸+𝑀𝐶142𝐹 −𝑀𝐶178


Alcatel CSSR (1 − ) × (1- ) × 100
𝑀𝐶04+𝑀𝐶148 𝑀𝐶140𝐴− 𝑀𝐶142𝐸+𝑀𝐶142𝐹

𝐶𝑁𝐷𝑅𝑂𝑃−𝐶𝑁𝑅𝐸𝐶𝑂𝑁𝐺 𝑇𝐶𝐴𝑆𝑆𝐴𝐿𝐿
Ericsson CSSR 100×(1- ) ×
𝐶𝑀𝑆𝐸𝑆𝑇𝐴𝐵 𝑇𝐴𝑆𝑆𝐴𝐿𝐿

𝐶𝑀30 𝐾3013𝐴+𝐾3013𝐵
Huawei CSSR 100 * (1- ( ) *
𝐾3003 𝐾3010𝐴+𝐾3010𝐵

𝑅𝐹𝐿𝑂𝑆𝑆𝐸𝑆𝑆𝐷 𝑀𝐴_𝐶𝑂𝑀𝑃𝐿𝐸𝑇_𝑇𝑂_𝑀𝑆𝐶
Motorola BSS_CSSR (1 − )× × 100
𝐴𝐿𝐿𝑂𝐶𝑆𝐷𝐶𝐶𝐻 − 𝐶𝐻𝐴𝑁𝑅𝐸𝑄𝐹𝐴𝐼𝐿 𝑀𝐴_𝑅𝐸𝑄_𝐹𝑅𝑂𝑀_𝑀𝑆𝐶
𝑅𝑂𝐿

(100-decode([C001193],0,0,([C001193]-[C001192])/[C001193]))*decode(100,0,0,(100-
NSN CSSR_V1
100*decode([C001225],0,0,[C001226]/[C001225]))/100)

𝐶900060053 𝐶900060028+𝐶900060199
ZTE CSSRBSS (1 − )× ×100
𝐶900060003−𝐶900060243 𝐶900060019+𝐶900060042

Đơn vị %
2.1.2. Tỷ lệ rớt cuộc gọi - Drop Call Rate

Định nghĩa: Là tỷ lệ số cuộc gọi bị rớt trên tổng số cuộc gọi thành công.

Tên KPI Tỷ lệ rớt cuộc gọi Công thức


QĐ 1705 Drop Call Rate - DCR

Pmtool Name Drop call rate

MC736 + MC621 + MC14C + MC739 + MC921C


Alcatel CDR - Drop call rate 100 ×
MC718 + MC717A + MC717B − (MC712 + MC924C)

100 * (TFNDROP + THNDROP + TFNDROPSUB + THNDROPSUB) / (TCASSALL +


Ericsson DCR - Drop call rate (nvl(NCELLREL_DHOVERSUC,0) - nvl(NICELASS_DHOSUCBCL,0) - nvl(NICELASS_DHOSUCWCL,0)) -
(nvl(NCELLREL_SHOVERSUC,0) - nvl(NICELASS_SHOSUCBCL,0) - nvl(NICELASS_SHOSUCWCL,0)))

[CM33]
Huawei DCR - Drop call rate 100 ×
[K3013A] + [CH323] + [CH343] − [CH313] − [CH333]

rf_loss_tch_roll + intra_cell_ho_los + o_intra_bs_ho_los + O_INTER_BS_HO_FAIL + O_INTER_BS_EQ_FA


Motorola DROPC - Drop call rate 100 ×
TOTAL_CALLS + I_INTER_BS_HO_SUC

nvl c057033 , 0 + nvl c057032 , 0 + nvl c057034 , 0 − nvl c004073 , 0 , 0,0, c057044
NSN DCR - Drop call rate 100 × 𝑑𝑒𝑐𝑜𝑑𝑒( )
nvl c057033 , 0 + nvl c057032 , 0 + nvl c057034 , 0 − nvl c004073 , 0

C900060054 + C900060055
ZTE DCR_V1 - Drop call rate v1 × 100
C900060028 + C900060199 + C900060098 + C900060102
Đơn vị %
2.1.3. Tỷ lệ chuyển giao thành công - Handover Success Rate
Định nghĩa: Là tỷ lệ giữa số lần handover thành công và tổng số lần handover được yêu cầu (HO Attempt). Có tất cả ba kiểu HO, đó là HO trong nội
bộ cell (Intra-Cell HO), HO trong nội bộ BSC (Intra-BSC HO) và HO giữa các BSC (Inter-BSC HO). Công thức HOSR của các hệ thống được xây
dựng như dưới đây, và tất cả đều là HO ra (Out Going HO). Công thức này mô tả tỉ lệ thành công cho tổng cộng cả 3 kiểu HO, vì trong các công thức
bao gồm các counter liên quan đến cả 3 trường hợp.
Tỷ lệ chuyển giao
Tên KPI Công thức
thành công
QĐ 1705 Handover Success Rate - HOSR

Pmtool Name Handover Success Rate

OHOSR - Handover 𝑀𝐶646 + 𝑀𝐶656 + 𝑀𝐶924𝐶


Alcatel × 100
Success Rate 𝑀𝐶645𝐴 + 𝑀𝐶655𝐴 + 𝑀𝐶924𝐵

HSR - Handover 𝑛𝑣𝑙 𝑁𝐶𝐸𝐿𝐿𝑅𝐸𝐿_𝑆𝐻𝑂𝑉𝐸𝑅𝑆𝑈𝐶, 0 + 𝑛𝑣𝑙(𝑁𝐸𝐶𝐸𝐿𝐿𝑅𝐸𝐿_𝑆𝐻𝑂𝑉𝐸𝑅𝑆𝑈𝐶, 0)


Ericsson × 100
Success Rate 𝑛𝑣𝑙 𝑁𝐶𝐸𝐿𝐿𝑅𝐸𝐿_𝑆𝐻𝑂𝑉𝐸𝑅𝐶𝑁𝑇, 0 + 𝑛𝑣𝑙(𝑁𝐸𝐶𝐸𝐿𝐿𝑅𝐸𝐿_𝑆𝐻𝑂𝑉𝐸𝑅𝐶𝑁𝑇, 0)

HOSR - Handover 𝐶𝐻303 + 𝐶𝐻323 + 𝐶𝐻343


Huawei × 100
Success Rate 𝐶𝐻310 + 𝐶𝐻330 + 𝐶𝐻300

HANSR - Handover o_inter_bs_ho_suc + intra_cell_ho_suc + o_intra_bs_ho_suc + O_INTER_BS_HO_CLR + O_INTRA_BS_HO_CLR + INTRA_CELL_HO_CLR


Motorola × 100
Success Rate o_inter_bs_ho_atm + o_intra_bs_ho_atm + INTRA_CELL_HO_F_F + INTRA_CELL_HO_H_H + INTRA_CELL_HO_F_H + INTRA_CELL_HO_H_F

HOSR - Handover c001195 + c001196 + c001197 + c004154 , 0,0,100 ∗ c004004 + c004014 + c004018 + c004158
NSN 𝑑𝑒𝑐𝑜𝑑𝑒( )
Success Rate c001195 + c001196 + c001197 + c004154

HOSR_V1 - Handover C900060120 + C900060094 + C900060096


ZTE × 100
Success Rate V1 C900060119 + C900060093 + C900060095

Đơn vị %
2.2. Chỉ tiêu Badcell 2G

a. Định nghĩa
- Cell vô tuyến di động 2G được xác định là cell xấu nếu rơi vào 1 trong các tiêu chí sau:
+ CSSR ≤ 95%
+ DCR ≥ 3 %
+ HOSR ≤ 95%
- Số liệu thống kê các chỉ tiêu trên với thời gian vi phạm ≥ 1 giờ/7 ngày, xét các giờ có Callvolume ≥ 50 cuộc
thoại/giờ, HO-Attemp ≥ 25 cuộc/giờ.

b. Yêu cầu
+ Toàn mạng: ≤ 2%
+ Mức Tỉnh, Quận, Huyện thuộc HNI, HCM, HPG, CTO, DNG: ≤ 1%
+ Mức Tỉnh, Quận, Huyện thuộc các Tỉnh/TP khác: ≤ 2%
2.3. Chỉ tiêu Badcell 3G-CS
2.3.1. Tỷ lệ thiết lập cuộc gọi thoại thành công - CSSR (Voice call)
Định
Tên KPI nghĩa: Làlậptiến
Tỷ lệ thiết cuộctrình
gọi thiết lập cuộc gọi trong 3G xảy ra trong ba giai đoạn: RRC, SCCP và RAB.
Công thức
thoại thành công
QĐ 1705 đoạn
- GiaiCSV Call RRC:
Setup Success
RNC ghiRatenhận
- CSSRyêu cầu cầu truy cập dịch vụ từ UE và gán kênh kết nối RRC giữa RNC và UE. KPI đánh giá thành công ở giai
Pmtool
đoạn CS_Call
này được Setuptính bởi Rate
Success công thức RRC Setup Success Rate.
Name
- Giai đoạn SCCP: RNC thiết lập một kết nối với mạng
(RAB.SuccEstab.CS.SpeechConv lõi, phục vụ cho một loạt các
+ VS.IRATHO.SuccReloc.DirRetry.CsDch tiến trình báo hiệu liên quan đến
+ VS.IRATHO.SuccReloc.DirRetry.CsHspa) mạng lõi như nhận thực
/ ((RAB.AttEstab.CS.SpeechConv
(Authentication), mã hóa (ciphering)… KPI đánh giá tiến trình này là +SCCP
- (VS.RAB.EstabCancel.CS.CallRelease.SpeechConv nvl(VS.RAB.EstabCancel.CS.CallRelease.SpeechConvHspa,0))
Setup Success Rate. -
(VS.IRATHO.AttRelocPrep.DirRetry - (VS.IRATHO.SuccReloc.DirRetry.CsDch + VS.IRATHO.SuccReloc.DirRetry.CsHspa))) +
- Giai đoạn RAB: Là giai đoạn gán kênh, mạng lõi gán tài/ (RRC.SuccConnEstab.OrigConvCall
((VS.RRC.AttConnRel.CS.Drop.CallSetup nguyên cho RNC để RNC +chuyển tiếp cho UE. KPI đánh
RRC.SuccConnEstab.TermConvCall + giá tiến trình này là RAB
Alcatel CS_CSSR
Setup Success Rate. RRC.SuccConnEstab.Emergency)) * (RRC.SuccConnEstab.OrigConvCall + RRC.SuccConnEstab.TermConvCall + RRC.SuccConnEstab.Emergency)) +
((VS.RRC.AttConnEstab.LastperProc.OrigConvCall + VS.RRC.AttConnEstab.LastperProc.TermConvCall + VS.RRC.AttConnEstab.LastperProc.Emergency
Do tiến trình SCCP Setup được chạy trên báo hiệu giữa RNC
+ RRC.FailConnEstab.3G2GRedirectEmergency) và MSS với độ tin cậy
- (RRC.SuccConnEstab.OrigConvCall rất cao (có thể nhận thấy
+ RRC.SuccConnEstab.TermConvCall + điều này trong
RRC.SuccConnEstab.Emergency))) * 100
tiến trình cấp phát báo hiệu SCCP khi bản tin ACK không xuất hiện như hai triến trình kia), đồng thời tiến trình SCCP không
100 * PmtotNoRrcConnectReqCsSucc / (pmTotNoRrcConnectReqCs - pmNoLoadSharingRrcConnCs) * pmNoNormalNasSignReleaseCs /
Ericsson trực tiếp đến phần
liên quanCS_CSSR vô tuyến 3G cũng như
(pmNoNormalNasSignReleaseCs UE nên công thức CSSR
+ pmNoSystemNasSignReleaseCs) thường được rút +gọn
* (pmNoRabEstablishSuccessSpeech như sau:
pmNoRabEstablishSuccessCs64) /
(pmNoRabEstablishAttemptSpeech + pmNoRabEstablishSuccessCs64 - pmNoDirRetryAtt)
𝑪𝑺𝑺𝑹 = 𝑹𝑹𝑪 𝑺𝒆𝒕𝒖𝒑 𝑺𝒖𝒄𝒄𝒆𝒔𝒔 𝑹𝒂𝒕𝒆 ∗ 𝑹𝑨𝑩 𝑺𝒆𝒕𝒖𝒑 𝑺𝒖𝒄𝒄𝒆𝒔𝒔 𝑹𝒂𝒕𝒆
(([Number of Successful RRC Connection Setups for Cell (Originating Conversational Call)]+[Number of Successful RRC Connection Setups for Cell
(Terminating Conversational Call)]+[Number of Successful RRC Connection Setups for Cell (Emergency Call)]) /([Number of RRC Connection Requests for
Cell (Originating Conversational Call)]+[Number of RRC Connection Requests for Cell (Emergency Call)]+[Number of RRC Connection Requests for Cell
Huawei CS_CSSR
(Terminating Conversational Call)])) * (([Number of Successful CS Streaming RAB Establishments for Cell] + [Number of Successful CS Conversational RAB
Establishments for Cell]) / ([Number of CS Streaming RAB Establishment Requests for Cell] + [Number of CS Conversational RAB Establishment Requests
for Cell])) * 100
decode( (rab_stp_att_cs_voice * (moc_conv_call_atts + mtc_conv_call_atts + emergency_call_atts - rrc_att_rep_mo_conv - rrc_att_rep_mt_conv -
rrc_att_rep_emergency - rrc_acc_rel_emergency - rrc_acc_rel_mo_conv - rrc_acc_rel_mt_conv - rrc_conn_stp_rej_emerg_call)),0,null, (100 *
((moc_conv_call_atts - moc_conv_call_fails + mtc_conv_call_atts - mtc_conv_call_fails + emergency_call_atts - emergency_call_fails -
NSN CSSR
rrc_acc_rel_emergency - rrc_acc_rel_mo_conv - rrc_acc_rel_mt_conv) / (moc_conv_call_atts + mtc_conv_call_atts + emergency_call_atts -
rrc_att_rep_mo_conv - rrc_att_rep_mt_conv - rrc_att_rep_emergency - rrc_acc_rel_emergency - rrc_acc_rel_mo_conv - rrc_acc_rel_mt_conv -
rrc_conn_stp_rej_emerg_call)) * ((rab_acc_comp_cs_voice) / (rab_stp_att_cs_voice))))
C310080195 / (C310080051-C310080052)*(C310100711+C310100734+C310100733+C310100735) /
ZTE V2_CSSRCSSPEECH
(C310090252+C310090274+C310090275+C310090276) * 100
Đơn vị %
2.3.2. Tỷ lệ rớt cuộc gọi thoại - DCR
Định nghĩa: Chỉ số rớt cuộc gọi trong 3G được tính tương ứng là tổng số cuộc rớt trên tổng số cuộc kết thúc ở cell đó. Tại
thời điểm hủy kết nối dịch vụ (RAB Release), RNC ghi nhận nguyên nhân giải phóng cuộc gọi đó là bình thường hay bất
thường để từ đó tính được tỉ lệ rớt cuộc.
𝑹𝑨𝑩 𝑨𝒃𝒏𝒐𝒎𝒂𝒍 𝑹𝒆𝒍𝒆𝒂𝒔𝒆
𝑫𝒓𝒐𝒑 𝑪𝒂𝒍𝒍 𝑹𝒂𝒕𝒆 =
𝑹𝑨𝑩 𝑵𝒐𝒎𝒂𝒍 𝑹𝒆𝒍𝒆𝒂𝒔𝒆 + 𝑹𝑨𝑩 𝑨𝒃𝒏𝒐𝒎𝒂𝒍 𝑹𝒆𝒍𝒆𝒂𝒔𝒆
DCR được chia nhỏ cho hai dịch vụ CS và PS, chỉ số CS DCR và PS DCR được tính tương ứng với các RAB là CS hay PS.
Tỷ lệ rớt cuộc gọi
Tên KPI Công thức
thoại
QĐ 1705 CSV Drop Call Rate - DCR (Voice call)
Pmtool
CS_Drop Call Rate
Name
100 * (( VS.IuAbnormalReleaseRequestCs.DlAsCnfOther + VS.IuAbnormalReleaseRequestCs.DlAsCnfCsSpeechNbLrAmr + VS.IuAbnormalReleaseRequestCs.DlAsCnfCsSpeechWbAmr +
VS.IuAbnormalReleaseRequestCs.DlAsCnfCsData + VS.IuAbnormalReleaseRequestCs.DlAsCnfCsStr57_6 + VS.IuAbnormalReleaseRequestCs.DlAsCnfCsStr14_4) /
Alcatel CS_DCR
(VS.IuReleaseCompleteCs.DlAsCnfOther + VS.IuReleaseCompleteCs.DlAsCnfCsSpeechNbLrAmr + VS.IuReleaseCompleteCs.DlAsCnfCsSpeechWbAmr +
VS.IuReleaseCompleteCs.DlAsCnfCsData + VS.IuReleaseCompleteCs.DlAsCnfCsStr57_6 + VS.IuReleaseCompleteCs.DlAsCnfCsStr14_4))
(pmNoSystemRabReleaseSpeech + pmNoSystemRabReleaseCs64) / (pmNoSystemRabReleaseSpeech + pmNoSystemRabReleaseCs64 + pmNoNormalRabReleaseSpeech +
Ericsson CS_DCR
pmNoNormalRabReleaseCs64) * 100
Huawei CS_DCR ([Number of CS RABs Abnormally Released for Cell]) / ([Number of CS RABs Abnormally Released for Cell]+[Number of CS RABs Normally Released for Cell]) * 100
100 * decode((rab_act_comp_cs_voice + rab_act_rel_cs_voice_srnc + rab_act_rel_cs_voice_p_emp + RAB_ACT_REL_CS_VOICE_HHO + RAB_ACT_REL_CS_VOICE_ISHO +
RAB_ACT_REL_CS_VOICE_GANHO + rab_act_fail_cs_voice_iu + rab_act_fail_cs_voice_radio + rab_act_fail_cs_voice_bts + rab_act_fail_cs_voice_iur + rab_act_fail_cs_voice_rnc +
RAB_ACT_FAIL_CS_VOICE_UE + RAB_ACT_FAIL_CS_VOICE_TRANS),0,null,(rab_act_rel_cs_voice_p_emp + rab_act_fail_cs_voice_iu + rab_act_fail_cs_voice_radio +
NSN DCR rab_act_fail_cs_voice_bts + rab_act_fail_cs_voice_iur + rab_act_fail_cs_voice_rnc + RAB_ACT_FAIL_CS_VOICE_UE + RAB_ACT_FAIL_CS_VOICE_TRANS) / (rab_act_comp_cs_voice +
rab_act_rel_cs_voice_srnc + rab_act_rel_cs_voice_p_emp + RAB_ACT_REL_CS_VOICE_HHO + RAB_ACT_REL_CS_VOICE_ISHO + RAB_ACT_REL_CS_VOICE_GANHO +
rab_act_fail_cs_voice_iu + rab_act_fail_cs_voice_radio + rab_act_fail_cs_voice_bts + rab_act_fail_cs_voice_iur + rab_act_fail_cs_voice_rnc + RAB_ACT_FAIL_CS_VOICE_UE +
RAB_ACT_FAIL_CS_VOICE_TRANS))
(C310231162+C310231163+C310231164+C310231165+C310231166+C310231167+C310231168+C310231169+C310231170+C310231171+C310231172+C310231173+C310231174+C3102
31175+C310231176+C310231177+C310231178+C310231179+C310231180+C310231181+C310231182+C310231183+C310231184) /
ZTE V2_DCRCS
(C310231185+C310231186+C310231187+C310231188+C310231189+C310231190+C310231191+C310231192+C310231193+C310231194+C310231195+C310231196+C310231197+C3102
31198+C310231199+C310231200+C310231201+C310231202+C310231203+C310231204+C310231205+C310231206+C310231207) * 100
Đơn vị %
2.3.3. Tỷ lệ chuyển giao cùng tần số dịch vụ thoại - S.HOSR
Định nghĩa: Có ba tiến trình HO quan trọng và thường thấy nhất trong 3G như sau:
- Soft HO. Soft HO chỉ những cuộc HO giữa các cell cùng tần số 3G với nhau, khi mà UE di chuyển giữa các cell 3G có thể chiếm đồng
thời tài nguyên của hai hoặc nhiều cell 3G cùng tần số cùng lúc. Soft HO thường được đánh đồng với Intra-Frequency HO, dù Intra-
Frequency HO không luôn luôn là soft HO, ví dụ như Intra-Frequency HO giữa các RNC không có giao diện IuR. Tuy nhiên, những
trường hợp này là thiểu số, và Soft HO là trường hợp HO chủ yếu nhất trên mạng 3G.
𝑨𝒄𝒕𝒊𝒗𝒆 𝑺𝒆𝒕 𝑼𝒑𝒅𝒂𝒕𝒆 𝑪𝒐𝒎𝒑𝒍𝒆𝒕𝒆
𝑺𝒐𝒇𝒕 𝑯𝑶𝑺𝑹 =
𝑨𝒄𝒕𝒊𝒗𝒆 𝑺𝒆𝒕 𝑼𝒑𝒅𝒂𝒕𝒆 𝑹𝒆𝒒𝒖𝒆𝒔𝒕
Tên KPI Tỷ lệ chuyển giao cùng tần số dịch vụ thoại Công thức

QĐ 1705 CS Handover Success Rate - HOSR


Pmtool Name CS_Soft/Softer Handover Success Rate

Alcatel CS_SOFT_HOSR 100 * (VS.RESERVED171 + VS.RESERVED173) / (VS.RESERVED176 + VS.RESERVED178)

((nvl(pmRlAddSuccessBestCellSpeech,0) + nvl(pmRlAddSuccessBestCellCsConvers,0)) /
Ericsson CS_SOFT_HOSR
(nvl(pmRlAddAttemptsBestCellSpeech,0) + nvl(pmRlAddAttemptsBestCellCsConvers,0))) * 100

([Number of Successful Soft Handovers in CS Domain for Cell (AMR Service)]+[Number of Successful Soft
Handovers in CS Domain for Cell (64 kbit/s Conversational Service)]) / ([Number of Soft Handover Attempts
Huawei CS_SOFT_HOSR
for Cell (AMR)]+[Number of Soft Handover Attempts in CS Domain for Cell (64 kbit/s Conversational
Service)])*{100}

decode((cell_add_req_on_sho_for_rt + cell_repl_req_on_sho_for_rt + cell_del_req_on_sho_for_rt),0,null,


NSN SOFTHOSR 100*(succ_updates_on_sho_for_rt) / (cell_add_req_on_sho_for_rt + cell_repl_req_on_sho_for_rt +
cell_del_req_on_sho_for_rt))

ZTE V2_SOFTHOSRCS (C310322495+C310322499-C310322497-C310322501) / (C310322495+C310322499) * 100


Đơn vị %
2.3.4. Tỷ lệ chuyển giao khác tần số dịch vụ thoại - IF HOSR
Định nghĩa: Inter-Frequency HO. Inter-Frequency HO là trường hợp HO giữa hai cell 3G chạy khác tần số.
𝑷𝒉𝒚𝒔𝒊𝒄𝒂𝒍 𝑪𝒉𝒂𝒏𝒏𝒆𝒍 𝑹𝒆𝒄𝒐𝒏𝒇𝒊𝒈𝒖𝒓𝒂𝒕𝒊𝒐𝒏 𝑪𝒐𝒎𝒑𝒍𝒆𝒕𝒆
𝑰𝑭 𝑯𝑶𝑺𝑹 =
𝑷𝒉𝒚𝒔𝒊𝒄𝒂𝒍 𝑪𝒉𝒂𝒏𝒏𝒆𝒍 𝑹𝒆𝒄𝒐𝒏𝒇𝒊𝒈𝒖𝒓𝒂𝒕𝒊𝒐𝒏 𝑹𝒆𝒒𝒖𝒆𝒔𝒕

Tên KPI Tỷ lệ chuyển giao khác tần số dịch vụ thoại Công thức

QĐ 1705 CS Inter-Freq Handover Success Rate - IF HOSR


Pmtool Name CS_Inter-Freq Handover Success Rate
Alcatel CS_INTER_FREQ_HOSR 100 * (VS.RESERVED112 / VS.RESERVED115)
((nvl(pmSuccNonBlindInterFreqHoCsSpeech12,0) +
nvl(pmSuccNonBlindInterFreqHoCsConversational,0)) /
Ericsson CS_INTER_FREQ_HOSR
(nvl(pmAttNonBlindInterFreqHoCsSpeech12,0) +
nvl(pmAttNonBlindInterFreqHoCsConversational,0))) * 100

[Number of Successful for CS Outgoing Inter-Frequency Hard Handovers for Cell] / [Number
Huawei CS_IF_HOSR
of Requests for CS Outgoing Inter-Frequency Hard Handovers for Cell]*{100}

100 * decode((intra_intra_hho_att_rt + intra_inter_hho_att_rt + inter_hho_att_rt +


hho_att_caused_sho_incap_rt +
immed_hho_csd_sho_incap_rt),0,null,(succ_intra_intra_hho_att_rt +
NSN CSINTERFREQHOSR
succ_intra_inter_hho_att_rt + succ_inter_hho_att_rt + succ_hho_caused_sho_incap_rt) /
(intra_intra_hho_att_rt + intra_inter_hho_att_rt + inter_hho_att_rt +
hho_att_caused_sho_incap_rt + immed_hho_csd_sho_incap_rt))
ZTE V2INTERFREQHOSRCS (C310332667-C310332671) / C310332667 * 100
Đơn vị %
2.3.5. Tỷ lệ chuyển giao IRAT dịch vụ thoại - IRAT HOSR
Định nghĩa: Inter-RAT HO. Do vùng phủ 3G không tốt bằng vùng phủ 2G,UE có nhu cầu phải được chuyển giao sang 2G
trong trường hợp đi ra khỏi vùng phủ 3G. HO kiểu này được gọi là Inter-RAT HO, khi UE chuyển giao giữa hai mạng vô
tuyến khác nhau.
𝑯𝒂𝒏𝒅𝒐𝒗𝒆𝒓 𝑭𝒓𝒐𝒎 𝑼𝑻𝑹𝑨𝑵 𝑪𝒐𝒎𝒑𝒍𝒆𝒕𝒆
𝑪𝑺 𝑰𝑹𝑨𝑻 𝑯𝑶𝑺𝑹 =
𝑯𝒂𝒏𝒅𝒐𝒗𝒆𝒓 𝑭𝒓𝒐𝒎 𝑼𝑻𝑹𝑨𝑵 𝑹𝒆𝒒𝒖𝒆𝒔𝒕
Tên KPI Tỷ lệ chuyển giao IRAT dịch vụ thoại Công thức

QĐ 1705 CS Inter-RAT Handover Success Rate - IRAT HOSR


Pmtool Name CS_Inter-RAT Handover Success Rate
100 * (IRATHO.SuccOutCS.RescueCs + IRATHO.SuccOutCS.ServiceCs + IRATHO.SuccOutCS.NoRsrcCs) /
Alcatel CS_IRAT_HOSR (VS.RrcHoFromUtranCmdTrigByEcNo.RescueCs + VS.RrcHoFromUtranCmdTrigByRscp.RescueCs + VS.RrcHoFromUtranCmdTrigRnc.ServiceCs
+ VS.RrcHoFromUtranCmdTrigRnc.NoRsrcAvailCacFailure + VS.RrcHoFromUtranCmdTrigByUeTxPowerMax)

Ericsson CS_IRAT_HOSR pmNoSuccessOutIratHoSpeech / (pmNoAttOutIratHoSpeech + pmNofailOutIratHoSpeechGsmFailure) * 100


Huawei CS_IRATHOSR [Number of Successful CS Outgoing Inter-RAT Handovers for Cell] / [Number of CS Outgoing Inter-RAT Handover Attempts]*{100}
100 * decode( (is_hho_att_ul_dch_q_rt + is_hho_att_ue_trx_pwr_rt + is_hho_att_dpch_pwr_rt + is_hho_att_cpich_rscp_rt +
is_hho_att_cpich_ecno_rt + is_hho_att_im_ims_rt + is_hho_att_emerg_call + is_hho_att_lb_capa_dl_rt + is_hho_att_lb_capa_ul_rt +
is_hho_att_lb_prx_tot_rt + is_hho_att_lb_ptx_tot_rt + is_hho_att_lb_res_lim_rt + is_hho_att_lb_rsvr_sc_rt + is_hho_att_sb_rt +
is_hho_att_ul_dch_wps_rt + att_ganho_amr_rt + att_isho_cell_shutdown_rt + att_isho_cell_block_rt - is_hho_att_2nd_best_cell_rt -
is_hho_att_3rd_best_cell_rt),0,null, (succ_is_hho_ul_dch_q_rt + succ_is_hho_ue_trx_pwr_rt + succ_is_hho_dl_dpch_pwr_rt +
succ_is_hho_cpich_rscp_rt + succ_is_hho_cpich_ecno_rt + succ_is_hho_im_ims_rt + succ_is_hho_emerg_call + succ_is_hho_lb_capa_dl_rt +
NSN IRATHOSR
succ_is_hho_lb_capa_ul_rt + succ_is_hho_lb_prx_tot_rt + succ_is_hho_lb_ptx_tot_rt + succ_is_hho_lb_res_lim_rt + succ_is_hho_lb_rsvr_sc_rt +
succ_is_hho_sb_rt + succ_is_hho_wps_rt + succ_ganho_amr_rt + succ_isho_cell_shutdown_rt + succ_isho_cell_block_rt) / (is_hho_att_ul_dch_q_rt
+ is_hho_att_ue_trx_pwr_rt + is_hho_att_dpch_pwr_rt + is_hho_att_cpich_rscp_rt + is_hho_att_cpich_ecno_rt + is_hho_att_im_ims_rt +
is_hho_att_emerg_call + is_hho_att_lb_capa_dl_rt + is_hho_att_lb_capa_ul_rt + is_hho_att_lb_prx_tot_rt + is_hho_att_lb_ptx_tot_rt +
is_hho_att_lb_res_lim_rt + is_hho_att_lb_rsvr_sc_rt + is_hho_att_sb_rt + is_hho_att_ul_dch_wps_rt + att_ganho_amr_rt +
att_isho_cell_shutdown_rt + att_isho_cell_block_rt - is_hho_att_2nd_best_cell_rt - is_hho_att_3rd_best_cell_rt))

(C310352945-C310352946-C310352947-C310352948-C310352949-C310352950-C310352951) /
ZTE V2_IRAT_HOSRCS
(C310352911+C310352912+C310352913+C310352914+C310352915+C310352916+C310352917) * 100
Đơn vị %
2.4. Chỉ tiêu KPIs Badcell 3G-PS
2.4.1. Tỷ lệ thiết lập dịch vụ Data thành công - ASR
Tỷ lệ thiết lập dịch vụ Data
Định nghĩa:
Tên KPI
thành côngLà tiến trìnhCông
– ASR thiết lập kết nối trong 3G xảy ra trong ba giai đoạn: RRC, SCCP và RAB. (Tương tự như Voice setup)
thức:𝑃𝑆𝑆𝑅 = 𝑅𝑅𝐶 𝑆𝑒𝑡𝑢𝑝 𝑆𝑢𝑐𝑐𝑒𝑠𝑠 𝑅𝑎𝑡𝑒 ∗ 𝑅𝐴𝐵 𝑆𝑒𝑡𝑢𝑝 𝑆𝑢𝑐𝑐𝑒𝑠𝑠 𝑅𝑎𝑡𝑒
QĐ 1705 Access Success Rate - ASR

- Giai đoạn RRC: RNC ghi nhận yêu cầu cầu truy cập dịch vụ từ UE và gán kênh kết nối RRC giữa RNC và UE. KPI đánh giá thành công ở giai
Pmtool Name PS_Call Setup Success Rate
(nvl(RAB.SuccEstab.PS.Sum,0) + nvl(VS.ReconfSucc.0kbps.DCH,0) + nvl(VS.ReconfSucc.0kbps.HSDSCH,0) + nvl(VS.ReconfSucc.0kbps.EDCH,0) + nvl(VS.UEStateTransSucc.PCH.CellDCH.DCH.HSDSCH,0) +
đoạn này được tính bởi công thức RRC Setup Success Rate.
nvl(VS.UEStateTransSucc.PCH.CellDCH.EDCH.HSDSCH,0) + nvl(VS.UEStateTransSucc.PCH.FACH,0)) / ((nvl(RAB.AttEstab.PS.Sum,0) + nvl(VS.ReconfAtt.0kbps.DCH,0) + nvl(VS.ReconfAtt.0kbps.HSDSCH,0) +
nvl(VS.ReconfAtt.0kbps.EDCH,0) + nvl(VS.UEStateTransAtt.PCH.FACH,0) + (nvl(VS.UEStateTransAtt.UraPCH.CellDCH.DCH.HSDSCH,0) + nvl(VS.UEStateTransAtt.CellPCH.CellDCH.DCH.HSDSCH,0) -
- Giai đoạn SCCP: RNC thiết lập một kết nối với mạng lõi, phục vụ cho một loạt các tiến trình báo hiệu liên quan đến mạng lõi như nhận thực
nvl(VS.UEStateTransCancel.UraPCH.CellDCH.DCH.HSDSCH,0)) + (nvl(VS.UEStateTransAtt.PCH.CellDCH.EDCH.HSDSCH,0) - nvl(VS.UEStateTransCancel.PCH.CellDCH.EDCH.HSDSCH,0))) -
nvl(VS.RAB.EstabCancel.PS.CallRel,0) + ( nvl(VS.MultiRAB.RejectRABSetupPS.RefCell.TotAffectedCalls,0) - nvl(VS.MultiRAB.RejectRABSetupPS.RefCell.TotMsgsRejected,0)) +
(Authentication), mã hóa (ciphering)… KPI đánh giá tiến trình này là SCCP Setup Success Rate.
((nvl(VS.RRC.AttConnRel.PS.Drop.CallSetup,0) / (nvl(RRC.SuccConnEstab.OrigStrmCall,0) + nvl(RRC.SuccConnEstab.OrigIntactCall,0) + nvl(RRC.SuccConnEstab.OrigBgrdCall,0) +
nvl(RRC.SuccConnEstab.OrigSubscCall,0) + nvl(RRC.SuccConnEstab.TermStrmCall,0) + nvl(RRC.SuccConnEstab.TermIntactCall,0) + nvl(RRC.SuccConnEstab.TermBgrdCall,0) +
- Giai đoạn RAB: là giai đoạn gán kênh, mạng lõi gán tài nguyên cho RNC để RNC chuyển tiếp cho UE. KPI đánh giá tiến trình này là RAB
nvl(RRC.SuccConnEstab.OrigHighPrioSig,0) + nvl(RRC.SuccConnEstab.TermHighPrioSig,0))) * (nvl(RRC.SuccConnEstab.OrigStrmCall,0) + nvl(RRC.SuccConnEstab.OrigIntactCall,0) +
Alcatel PS_CSSR
Setup Success Rate. nvl(RRC.SuccConnEstab.OrigBgrdCall,0) + nvl(RRC.SuccConnEstab.OrigSubscCall,0) + nvl(RRC.SuccConnEstab.TermStrmCall,0) + nvl(RRC.SuccConnEstab.TermIntactCall,0) +
nvl(RRC.SuccConnEstab.TermBgrdCall,0) + nvl(RRC.SuccConnEstab.OrigHighPrioSig,0) + nvl(RRC.SuccConnEstab.TermHighPrioSig,0))) + (((nvl(VS.RRC.AttConnEstab.LastperProc.OrigStrmCall,0) +

Do tiến trình SCCP Setup được chạy trên báo hiệu giữa RNC và MSS với độ tin cậy rất cao (có thể nhận thấy điều này trong tiến
nvl(VS.RRC.AttConnEstab.LastperProc.TermStrmCall,0) + nvl(VS.RRC.AttConnEstab.LastperProc.OrigIntactCall,0) + nvl(VS.RRC.AttConnEstab.LastperProc.TermIntactCall,0) +
nvl(VS.RRC.AttConnEstab.LastperProc.OrigBgrdCall,0) + nvl(VS.RRC.AttConnEstab.LastperProc.TermBgrdCall,0) + nvl(VS.RRC.AttConnEstab.LastperProc.OrigSubscCall,0)) +
trình cấp phát báo hiệu SCCP khi bản tin ACK không xuất hiện như hai triến trình kia), đồng thời tiến trình SCCP không liên quan
nvl(VS.RRC.AttConnEstab.LastperProc.OrigHighPrioSig,0) + nvl(VS.RRC.AttConnEstab.LastperProc.TermHighPrioSig,0) + nvl(VS.RRC.ConnectionReAttempt.3GLteRedirectionCellLoadPS,0) -
nvl(RRC.FailConnEstab.3GLTERedirectCellLoad,0)) - (nvl(RRC.SuccConnEstab.OrigStrmCall,0) + nvl(RRC.SuccConnEstab.OrigIntactCall,0) + nvl(RRC.SuccConnEstab.OrigBgrdCall,0) +
trực tiếp đến phần vô tuyến 3G cũng như UE nên công thức CSSR thường được rút gọn như sau:
nvl(RRC.SuccConnEstab.OrigSubscCall,0) + nvl(RRC.SuccConnEstab.TermStrmCall,0) + nvl(RRC.SuccConnEstab.TermIntactCall,0) + nvl(RRC.SuccConnEstab.TermBgrdCall,0) +
nvl(RRC.SuccConnEstab.OrigHighPrioSig,0) + nvl(RRC.SuccConnEstab.TermHighPrioSig,0)))) * 100
(pmNoRabEstablishSuccessPacketInteractive) / (pmNoRabEstablishAttemptPacketInteractive) * pmNoNormalNasSignReleasePs /(pmNoNormalNasSignReleasePs +
Ericsson PS_CSSR
pmNoSystemNasSignReleasePs)*pmTotNoRrcConnectReqPsSucc /(pmTotNoRrcConnectReqPs-pmNoLoadSharingRrcConnPs)*100
((([Number of Successful RRC Connection Setups for Cell (Originating Background Call)]+[Number of Successful RRC Connection Setups for Cell (Terminating Background Call)]+[Number of Successful RRC
Connection Setups for Cell (Originating Interactive Call)]+[Number of Successful RRC Connection Setups for Cell (Terminating Interactive Call)]) / ([Number of RRC Connection Requests for Cell (Originating
Background Call)]+[Number of RRC Connection Requests for Cell (Terminating Background Call)]+[Number of RRC Connection Requests for Cell (Originating Interactive Call)]+[Number of RRC Connection
Huawei PS_CSSR
Requests for Cell (Terminating Interactive Call)]))*{100})*(([Number of Successful PS Streaming RAB Establishments for Cell]+[Number of Successful PS Interactive RAB Establishments for Cell]+[Number of PS
Background RAB Establishment Attempts for Cell]+[Number of Successful PS Conversational RAB Establishments for Cell]) / ([Number of PS Streaming RAB Establishment Attempts for Cell]+[Number of PS
Interactive RAB Establishment Attempts for Cell]+[Number of PS Conversational RAB Establishment Attempts for Cell]+[Number of PS Background RAB Establishment Attempts for Cell])*{100}) / {100}
decode( (moc_inter_call_atts + moc_backg_call_atts + moc_high_prior_sign_atts + mtc_inter_call_atts + mtc_backg_call_atts + mtc_high_prior_sign_atts - rrc_att_rep_interactive - rrc_att_rep_mo_interactive -
rrc_att_rep_mo_high_pr_sign - rrc_att_rep_mo_background - rrc_att_rep_mt_background - rrc_att_rep_mt_high_pr_sign - rrc_acc_rel_interactive - rrc_acc_rel_mo_background - rrc_acc_rel_mo_high_pr_sign -
rrc_acc_rel_mo_interactive - rrc_acc_rel_mt_background - rrc_acc_rel_mt_high_pr_sign + moc_strea_call_atts + mtc_strea_call_atts - rrc_att_rep_mo_streaming - rrc_att_rep_mt_streaming -
rrc_acc_rel_mo_streaming - rrc_acc_rel_mt_streaming),0,null, (100 * (moc_inter_call_atts - moc_inter_call_fails + moc_backg_call_atts - moc_backg_call_fails + mtc_inter_call_atts - mtc_inter_call_fails +
mtc_backg_call_atts - mtc_backg_call_fails + moc_high_prior_sign_atts - moc_high_prior_sign_fails + mtc_high_prior_sign_atts - mtc_high_prior_sign_fails - rrc_acc_rel_interactive - rrc_acc_rel_mo_background -
NSN PSCSSR rrc_acc_rel_mo_high_pr_sign - rrc_acc_rel_mo_interactive - rrc_acc_rel_mt_background - rrc_acc_rel_mt_high_pr_sign + moc_strea_call_atts - moc_strea_call_fails + mtc_strea_call_atts - mtc_strea_call_fails -
rrc_acc_rel_mo_streaming - rrc_acc_rel_mt_streaming) / (moc_inter_call_atts + moc_backg_call_atts + moc_high_prior_sign_atts + mtc_inter_call_atts + mtc_backg_call_atts + mtc_high_prior_sign_atts -
rrc_att_rep_interactive - rrc_att_rep_mo_interactive - rrc_att_rep_mo_high_pr_sign - rrc_att_rep_mo_background - rrc_att_rep_mt_background - rrc_att_rep_mt_high_pr_sign - rrc_acc_rel_interactive -
rrc_acc_rel_mo_background - rrc_acc_rel_mo_high_pr_sign - rrc_acc_rel_mo_interactive - rrc_acc_rel_mt_background - rrc_acc_rel_mt_high_pr_sign + moc_strea_call_atts + mtc_strea_call_atts -
rrc_att_rep_mo_streaming - rrc_att_rep_mt_streaming - rrc_acc_rel_mo_streaming - rrc_acc_rel_mt_streaming))) * decode((rab_stp_att_ps_inter + rab_stp_att_ps_backg + rab_stp_att_ps_strea),0,null,
(rab_acc_comp_ps_inter + rab_acc_comp_ps_backg + rab_acc_comp_ps_strea) / (rab_stp_att_ps_inter + rab_stp_att_ps_backg + rab_stp_att_ps_strea))
ZTE V2_CSSRPS C310080196 / (C310080053-C310080054)*(C310100736+C310100739+C310100752+C310100768) / (C310090277+C310090280+C310090293+C310090309) * 100
Đơn vị %
2.4.2. Tỷ lệ rớt cuộc gọi data - DR
Định nghĩa: Chỉ số rớt cuộc gọi trong 3G được tính tương ứng là tổng số cuộc rớt trên tổng số cuộc kết thúc ở cell đó. Tại thời điểm
hủy kết nối dịch vụ (RAB Release), RNC ghi nhận nguyên nhân giải phóng cuộc gọi đó là bình thường hay bất thường để từ đó tính
được tỉ lệ rớt cuộc. 𝑷𝑺 𝑹𝑨𝑩 𝑨𝒃𝒏𝒐𝒎𝒂𝒍 𝑹𝒆𝒍𝒆𝒂𝒔𝒆
𝑫𝒓𝒐𝒑 𝑪𝒂𝒍𝒍 𝑹𝒂𝒕𝒆 =
𝑷𝑺 𝑹𝑨𝑩 𝑵𝒐𝒎𝒂𝒍 𝑹𝒆𝒍𝒆𝒂𝒔𝒆 + 𝑷𝑺 𝑹𝑨𝑩 𝑨𝒃𝒏𝒐𝒎𝒂𝒍 𝑹𝒆𝒍𝒆𝒂𝒔𝒆
𝑃𝑆 𝑅𝐴𝐵 𝐴𝑏𝑛𝑜𝑚𝑎𝑙 𝑅𝑒𝑙𝑒𝑎𝑠𝑒
Tên KPI Tỷ lệ rớt cuộc gọi data Công thức:= (𝑃𝑆 𝑅𝐴𝐵 𝑁𝑜𝑚𝑎𝑙 𝑅𝑒𝑙𝑒𝑎𝑠𝑒+𝑃𝑆 𝑅𝐴𝐵 𝐴𝑏𝑛𝑜𝑚𝑎𝑙 𝑅𝑒𝑙𝑒𝑎𝑠𝑒)
QĐ 1705 Drop Rate - DR
Pmtool Name PS_R99_HSPA_D_R
(nvl(VS.IuAbnormalReleaseRequestPs.DlAsCnfOther,0) + nvl(VS.IuAbnormalReleaseRequestPs.DlAsCnfPsIB128,0) + nvl(VS.IuAbnormalReleaseRequestPs.DlAsCnfPsIB256,0) + nvl(VS.IuAbnormalReleaseRequestPs.DlAsCnfPsIB384,0) +
nvl(VS.IuAbnormalReleaseRequestPs.DlAsCnfHsdpa,0) + nvl(VS.IuAbnormalReleaseRequestPs.DlAsCnfxPch,0) + nvl(VS.IuAbnormalReleaseRequestPs.DlAsCnfPsStrLt64,0) + nvl(VS.IuAbnormalReleaseRequestPs.DlAsCnfPsStr64,0) +
nvl(VS.IuAbnormalReleaseRequestPs.DlAsCnfPsStr128,0) + nvl(VS.IuAbnormalReleaseRequestPs.DlAsCnfPsStr256,0) + nvl(VS.IuAbnormalReleaseRequestPs.DlAsCnfPsStr384,0) +
nvl(VS.IuAbnormalReleaseRequestPs.DlAsCnfTrbCellFach,0) + nvl(VS.IuAbnormalReleaseRequestPs.DlAsCnfPsIBLt64,0) + nvl(VS.IuAbnormalReleaseRequestPs.DlAsCnfPsIB64,0) +
Alcatel PS_DCR nvl(VS.IuAbnormalReleaseRequestPs.DlAsCnfPsIbQChatHspa,0) + nvl(VS.IuAbnormalReleaseRequestPs.DlAsCnfEnhCellFach,0)) / (nvl(VS.RadioBearerReleaseSuccess.SrcCallOther,0) + nvl(VS.RadioBearerReleaseSuccess.SrcCallPsIbLt64,0)
+ nvl(VS.RadioBearerReleaseSuccess.SrcCallPsIb64,0) + nvl(VS.RadioBearerReleaseSuccess.SrcCallPsIb128,0) + nvl(VS.RadioBearerReleaseSuccess.SrcCallPsIb256,0) + nvl(VS.RadioBearerReleaseSuccess.SrcCallPsIb384,0) +
nvl(VS.RadioBearerReleaseSuccess.SrcCallHsdpaR99,0) + nvl(VS.RadioBearerReleaseSuccess.SrcCallHsdpaEdch,0) + nvl(VS.RadioBearerReleaseSuccess.SrcCallTrbFach,0) + nvl(VS.RadioBearerReleaseSuccess.SrcCallPsStrLt64,0) +
nvl(VS.RadioBearerReleaseSuccess.SrcCallPsStr64,0) + nvl(VS.RadioBearerReleaseSuccess.SrcCallPsStr128,0) + nvl(VS.RadioBearerReleaseSuccess.SrcCallPsStr256,0) + nvl(VS.RadioBearerReleaseSuccess.SrcCallPsStr384,0) +
nvl(VS.RadioBearerReleaseSuccess.SrcCallPsIbQChatHspa,0) + nvl(VS.IuReleaseCommandPSWithRAB,0)) * 100
100 * ((pmNoSystemRabReleasePacket) - (pmNoSystemRabReleasePacketUra) - ((pmChSwitchAttemptFachUra)-(pmChSwitchSuccFachUra)) - ((pmChSwitchAttemptDchUra)-(pmChSwitchSuccDchUra)) - ((pmChSwitchAttemptHsUra)-
PS_DCR_
Ericsson (pmChSwitchSuccHsUra))) / ((pmNoNormalRabReleasePacket) + (pmNoSystemRabReleasePacket) - (pmNoSystemRabReleasePacketUra) - (pmNoNormalRabReleasePacketUra) + (pmChSwitchSuccFachUra) + (pmChSwitchSuccDchUra) +
ACTIVE
(pmChSwitchSuccHsUra))
(([Number of PS RABs Abnormally Released for Cell] - [Number of Abnormally Released PS RABs that Are in CELL_PCH or URA_PCH State for Cell] - [Number of RABs Abnormally Released for PS Services during the State Transition from
CELL_DCH to CELL_PCH or URA_PCH for Cell] - [Number of call drops During the F2P State Transition for Cell]) / ([Number of PS RABs Abnormally Released for Cell] + [Number of PS RABs Normally Released for Cell] - [Number of Abnormally
Huawei PSDCRV2
Released PS RABs that Are in CELL_PCH or URA_PCH State for Cell] - [Number of Normally Released PS RABs that Are in CELL_PCH or URA_PCH State for Cell] + [Number of Successful State Transfers from CELL_DCH to CELL_PCH for
Cell] + [Number of Successful State Transfers from CELL_FACH to CELL_PCH for Cell])) * 100
100 * decode((rab_act_comp_ps_inter + rab_act_comp_ps_backg + rab_act_rel_ps_inter_srnc + rab_act_rel_ps_inter_hho + rab_act_rel_ps_inter_isho + rab_act_rel_ps_backg_srnc + rab_act_rel_ps_backg_hho + rab_act_rel_ps_bgr_isho +
rab_act_fail_ps_inter_iu + rab_act_fail_ps_inter_radio + rab_act_fail_ps_inter_bts + rab_act_fail_ps_inter_iur + rab_act_fail_ps_inter_rnc + rab_act_fail_ps_backg_iu + rab_act_fail_ps_backg_radio + rab_act_fail_ps_backg_bts +
rab_act_fail_ps_backg_iur + rab_act_fail_ps_backg_rnc + rab_act_fail_ps_backg_ue + rab_act_fail_ps_inter_ue + rab_act_fail_ps_inter_trans + rab_act_fail_ps_backg_trans),0,null,(rab_act_fail_ps_backg_trans + rab_act_fail_ps_inter_trans +
rab_act_fail_ps_inter_iu + rab_act_fail_ps_inter_radio + rab_act_fail_ps_inter_bts + rab_act_fail_ps_inter_iur + rab_act_fail_ps_inter_rnc + rab_act_fail_ps_backg_iu + rab_act_fail_ps_backg_radio + rab_act_fail_ps_backg_bts +
NSN PSDCR
rab_act_fail_ps_backg_iur + rab_act_fail_ps_backg_rnc + rab_act_fail_ps_backg_ue + rab_act_fail_ps_inter_ue - rab_act_fail_ps_backg_pch-rab_act_fail_ps_int_pch) / (rab_act_comp_ps_inter + rab_act_comp_ps_backg +
rab_act_rel_ps_inter_srnc + rab_act_rel_ps_inter_hho + rab_act_rel_ps_inter_isho + rab_act_rel_ps_backg_srnc + rab_act_rel_ps_backg_hho + rab_act_rel_ps_bgr_isho + rab_act_fail_ps_inter_iu + rab_act_fail_ps_inter_radio +
rab_act_fail_ps_inter_bts + rab_act_fail_ps_inter_iur + rab_act_fail_ps_inter_rnc + rab_act_fail_ps_backg_iu + rab_act_fail_ps_backg_radio + rab_act_fail_ps_backg_bts + rab_act_fail_ps_backg_iur + rab_act_fail_ps_backg_rnc +
rab_act_fail_ps_backg_ue + rab_act_fail_ps_inter_ue + rab_act_fail_ps_inter_trans + rab_act_fail_ps_backg_trans))
(C310241254+C310241255+C310241256+C310241257+C310241258+C310241259+C310241260+C310241261+C310241262+C310241263+C310241264+C310241265+C310241266+C310241267+C310241268+C310241269+C310241270+C31
0241271+C310241272+C310241273+C310241274+C310241275+C310241276+C310241277+C310241278+C310241279+C310241280+C310241281+C310241282+C310241283+C310241284+C310241285+C310241286+C310241287+C310241
288+C310241289+C310241290+C310241291+C310241292-C310282103-C310282104-C310282105-C310282106-C310282107-C310282108-C310282109-C310282110-C310282111-C310282112-C310282113-C310282114-C310282119) /
ZTE V2DCRPS
(C310241293+C310241294+C310241298+C310241299+C310241300+C310241301+C310241302+C310241303+C310241304+C310241305+C310241306+C310241307+C310241308+C310241309+C310241310+C310241311+C310241312+C31
0241313+C310241314+C310241315+C310241316+C310241317+C310241318+C310241319+C310241320+C310241321+C310241322+C310241323+C310241324+C310241325+C310241326+C310241327+C310241328+C310241329+C310241
330+C310241331+C310241332+C310241333+C310241334+C310241335+C310241336+C310241337+C310241338) * 100
Đơn vị %
2.4.3. Tỷ lệ chuyển giao cùng tần số dịch vụ data - S.HOSR
Soft HO. Soft HO chỉ những cuộc HO giữa các cell cùng tần số 3G với nhau, khi mà UE di chuyển giữa các cell 3G có thể chiếm đồng thời tài nguyên
của hai hoặc nhiều cell 3G cùng tần số cùng lúc. Soft HO thường được đánh đồng với Intra-Frequency HO, dù Intra-Frequency HO không luôn luôn là
soft HO, ví dụ như Intra-Frequency HO giữa các RNC không có giao diện IuR. Tuy nhiên, những trường hợp này là thiểu số, và Soft HO là trường
hợp HO chủ yếu nhất trên mạng 3G.
𝑨𝒄𝒕𝒊𝒗𝒆 𝑺𝒆𝒕 𝑼𝒑𝒅𝒂𝒕𝒆 𝑪𝒐𝒎𝒑𝒍𝒆𝒕𝒆
𝑺𝒐𝒇𝒕 𝑯𝑶𝑺𝑹 =
𝑨𝒄𝒕𝒊𝒗𝒆 𝑺𝒆𝒕 𝑼𝒑𝒅𝒂𝒕𝒆 𝑹𝒆𝒒𝒖𝒆𝒔𝒕

Inter-RAT HO. Do vùng phủ 3G không tốt bằng vùng phủ 2G,UE có nhu cầu phải được chuyển giao sang 2G trong trường hợp đi ra khỏi vùng phủ
3G. HO kiểu này được gọi là Inter-RAT HO, khi UE chuyển giao giữa hai mạng vô tuyến khác nhau.
𝑯𝒂𝒏𝒅𝒐𝒗𝒆𝒓 𝑭𝒓𝒐𝒎 𝑼𝑻𝑹𝑨𝑵 𝑪𝒐𝒎𝒑𝒍𝒆𝒕𝒆 𝑪𝒆𝒍𝒍 𝑪𝒉𝒂𝒏𝒈𝒆 𝑶𝒓𝒅𝒆𝒓 𝑭𝒓𝒐𝒎 𝑼𝑻𝑹𝑨𝑵 𝑪𝒐𝒎𝒑𝒍𝒆𝒕𝒆
𝑪𝑺 𝑰𝑹𝑨𝑻 𝑯𝑶𝑺𝑹 = 𝑷𝑺 𝑰𝑹𝑨𝑻 𝑯𝑶𝑺𝑹 =
𝑯𝒂𝒏𝒅𝒐𝒗𝒆𝒓 𝑭𝒓𝒐𝒎 𝑼𝑻𝑹𝑨𝑵 𝑹𝒆𝒒𝒖𝒆𝒔𝒕 𝑪𝒆𝒍𝒍 𝑪𝒉𝒂𝒏𝒈𝒆 𝑶𝒓𝒅𝒆𝒓 𝑭𝒓𝒐𝒎 𝑼𝑻𝑹𝑨𝑵 𝑹𝒆𝒒𝒖𝒆𝒔𝒕

Tỷ lệ chuyển giao cùng tần số dịch


Tên KPI Công thức
vụ data
QĐ 1705 Intra-Freq Handover Success Rate - S.HOSR
Pmtool Name PS_Soft/Softer Handover Success Rate
Alcatel PS_SOFT_HOSR 100 * (VS.RESERVED168 + VS.RESERVED170) / (VS.RESERVED174 + VS.RESERVED175)
(pmRlAddSuccessBestCellPacketLow + pmRlAddSuccessBestCellPacketHigh)/
Ericsson PS_SOFT_HOSR
(pmRlAddAttemptsBestCellPacketLow + pmRlAddAttemptsBestCellPacketHigh)*100
[Number of Successful Soft Handovers for PS Services for Cell] / [Number of Soft Handover Attempts for
Huawei PS_SOFT_HOSR
PS Services for Cell]*{100}
decode( (cell_add_req_on_sho_for_nrt + cell_repl_req_on_sho_for_nrt +
NSN SOFTHOSRPS cell_del_req_on_sho_for_nrt),0,null, 100 * (succ_updates_on_sho_for_nrt) / (cell_add_req_on_sho_for_nrt
+ cell_repl_req_on_sho_for_nrt + cell_del_req_on_sho_for_nrt))
ZTE V2SOFTHOSRPS (C310322496+C310322500-C310322498-C310322502) / (C310322496+C310322500) * 100
Đơn vị %
2.4.4. Tỷ lệ chuyển giao khác tần số dịch vụ data - IF HOSR
Định nghĩa: Inter-Frequency HO. Inter-Frequency HO là trường hợp HO giữa hai cell 3G chạy khác tần số.

Tên KPI Tỷ lệ chuyển giao khác tần


Công thức
số dịch vụ data
𝑃ℎ𝑦𝑠𝑖𝑐𝑎𝑙 𝐶ℎ𝑎𝑛𝑛𝑒𝑙 𝑅𝑒𝑐𝑜𝑛𝑓𝑖𝑔𝑢𝑟𝑎𝑡𝑖𝑜𝑛 𝐶𝑜𝑚𝑝𝑙𝑒𝑡𝑒
=
𝑃ℎ𝑦𝑠𝑖𝑐𝑎𝑙 𝐶ℎ𝑎𝑛𝑛𝑒𝑙 𝑅𝑒𝑐𝑜𝑛𝑓𝑖𝑔𝑢𝑟𝑎𝑡𝑖𝑜𝑛 𝑅𝑒𝑞𝑢𝑒𝑠𝑡

QĐ 1705 Inter-Freq Handover Success Rate - IF HOSR

Pmtool Name PS_Inter-Freq Handover Success Rate

Alcatel PS_INTER_FREQ_HOSR 100 * (VS.RESERVED111 / VS.RESERVED114)

(nvl(pmSuccNonBlindInterFreqHoPsInteractiveLess64,0) +
nvl(pmSuccNonBlindInterFreqHoPsInteractiveGreater64,0) + nvl(pmSuccNonBlindIfhoPsIntHs,0)) /
Ericsson PS_IF_HOSR
(nvl(pmAttNonBlindInterFreqHoPsInteractiveLess64,0) + nvl(pmAttNonBlindInterFreqHoPsInteractiveGreater64,0)
+ nvl(pmAttNonBlindIfhoPsIntHs,0)) * 100

[Number of Successful for PS Outgoing Inter-Frequency Hard Handovers for Cell] / [Number of Requests for PS
Huawei PS_IF_HOSR
Outgoing Inter-Frequency Hard Handovers for Cell]*{100}

100 * decode((intra_intra_hho_att_nrt + intra_inter_hho_att_nrt + inter_hho_att_nrt +


hho_att_caused_sho_incap_nrt + immed_hho_csd_sho_incap_nrt),0,null,(succ_intra_intra_hho_att_nrt +
NSN V2INTERFREQHOSRPS
succ_intra_inter_hho_att_nrt + succ_inter_hho_att_nrt + succ_hho_sho_incap_nrt) / (intra_intra_hho_att_nrt +
intra_inter_hho_att_nrt + inter_hho_att_nrt + hho_att_caused_sho_incap_nrt + immed_hho_csd_sho_incap_nrt))

ZTE V2INTERFREQHOSRPS (C310332668-C310332672) / C310332668 * 100


Đơn vị %
2.5. Chỉ tiêu Badcell 3G

a. Định nghĩa
- Cell vô tuyến di động 3G được xác định là cell xấu nếu rơi vào 1 trong các tiêu chí sau:
+ CS-CSSR ≤ 95%
+ CS-DCR ≥ 3 %
+ CS Intra-Freq-HOSR ≤ 95%
+ CS IF-HOSR ≤ 95%
+ CS Inter-RAT-HOSR ≤ 95%
+ PS-ASR ≤ 95%
+ PS-DCR ≥ 3%
+ PS IF-HOSR ≤ 95%
+ PS Intra-Freq-HOSR ≤ 95%.
- Số liệu thống kê các chỉ tiêu trên với thời gian vi phạm ≥ 1 giờ/7 ngày, xét các giờ có Callvolume ≥ 50 cuộc
thoại/giờ (miền CS) hoặc data volume ≥ 250 MB/giờ (miền PS), HO-Attemp ≥ 25 cuộc/giờ.
b. Yêu cầu
+ Toàn mạng: ≤ 2%
+ Mức Tỉnh, Quận, Huyện thuộc HNI, HCM, HPG, CTO, DNG: ≤ 1%
+ Mức Tỉnh, Quận, Huyện thuộc các Tỉnh/Tp khác: ≤ 2%
2.6. Chỉ tiêu KPIs đánh giá Badcell 4G
2.6.1. Tỷ lệ thiết lập dịch vụ thành công
Định nghĩa: Là tỷ lệ thiết lập tất cả các dịch vụ thành công bao gồm cả dịch vụ thoại VoIP, được tính toán toàn trình bao gồm cả tỷ lệ thiết lập thành
công RRC và tỷ lệ thiết lập thành công RAB.
𝐃𝐚𝐭𝐚 𝐂𝐚𝐥𝐥 𝐒𝐞𝐭𝐮𝐩 𝐒𝐮𝐜𝐜𝐞𝐬 𝐑𝐚𝐭𝐞 = 𝟏𝟎𝟎% ∗ 𝐑𝐑𝐂 𝐒𝐞𝐭𝐮𝐩 𝐒𝐮𝐜𝐜𝐞𝐬𝐬 𝐑𝐚𝐭𝐞 ∗ 𝐄𝐑𝐀𝐁 𝐒𝐞𝐭𝐮𝐩 𝐒𝐮𝐜𝐜𝐞𝐬𝐬 𝐑𝐚𝐭𝐞

Tỷ lệ thiết lập dịch vụ thành công RRC


Định nghĩa: Là tỷ lệ kết nối RRC thành công trên tổng số yêu cầu thiết lập kết nối RRC để khởi tạo dịch vụ.
RRC Setup Succes Rate = 100% ∗ RRCConnectionSucces sΤR RCConnectionAttempt

Tỷ lệ thiết lập dịch vụ thành công eRAB


Định nghĩa: Là tỷ lệ yêu cầu thiết lập kết nối ERAB thành công giữa UE và MME trên tổng số yêu cầu thiết lập kết nối ERABđối với tất cả các dịch vụ
bao gồm cả dịch vụ VoIP.
ERAB Setup Succes Rate = 100% ∗ ERABSetupSuccess/ERABSetupAttempt
Tỷ lệ thiết lập dịch vụ
Tên KPI Công thức
thành công CSSR
Data Call Setup
QĐ 2123
Success Rate
100*(([M8013C5]) / ([M8013C17] + [M8013C18] + [M8013C19] + [M8013C34] + [M8013C31] + [M8013C21])) * (([M8013C44]) / ([M8013C43])) * (([M8006C206] + [M8006C207] + [M8006C208] +
Call Setup Success
NSN Name [M8006C209] + [M8006C210] + [M8006C211] + [M8006C212] + [M8006C213] + [M8006C214]) / ([M8006C188] + [M8006C189] + [M8006C190] + [M8006C191] + [M8006C192] + [M8006C193] +
Rate (CSSR)
[M8006C194] + [M8006C195] + [M8006C196]))

(([L.RRC.ConnReq.Succ.Emc]+[L.RRC.ConnReq.Succ.HighPri]+[L.RRC.ConnReq.Succ.Mt]+[L.RRC.ConnReq.Succ.MoData]+[L.RRC.ConnReq.Succ.DelayTol])/([L.RRC.ConnReq.Att.Emc]+[L.RRC.ConnR
Huawei Call Setup Success
eq.Att.HighPri]+[L.RRC.ConnReq.Att.Mt]+[L.RRC.ConnReq.Att.MoData]+[L.RRC.ConnReq.Att.DelayTol]))*([L.S1Sig.ConnEst.Succ]/[L.S1Sig.ConnEst.Att])*([L.E-RAB.SuccEst]/([L.E-RAB.AttEst]-[L.E-
Name Rate
RAB.FailEst.X2AP]))*100

Ericsson Call Setup Success


100*([pmRrcConnEstabSucc] / ([pmRrcConnEstabAtt] - [pmRrcConnEstabAttReatt])) * ([pmS1SigConnEstabSucc] / [pmS1SigConnEstabAtt]) * ([pmErabEstabSuccInit] / [pmErabEstabAttInit])
Name Rate (CSSR)
100*(C373200000+C373200004+C373200008+C373200012+C373200016+C373200120+C373200152)/(C373200000+C373200004+C373200008+C3732000 12+C373200016+C373200120+C373200001
Call Setup Success +C373200002+C373200003+C373200005+C373200006+C373200007+C373200009+C373200010+C373200011+C373200013+C373200014+C373200015+C37 3200017+C373200018+C373200019+C3
ZTE Name
Rate (CSSR) 73200121+C373200122+C373200123+C373200152+C373200153+C373200154+C373200155))*(C373505473+C373505481)/(C373505473+C373505474+C373505475+C373505476+C373505477+C373
505478+C373505479+C373210589+C373505481+C373505482+C373505483+C373505484+C373505485+C373505486+C373505487+C373210599))
Pmtool Call Setup Success
Name Rate (CSSR)
Đơn vị %
2.6.2. Tỷ lệ rớt dịch vụ
Định nghĩa: Tỷ lệ rớt dịch ERAB được tính toán dựa trên tỷ lệ giải phóng ERAB của tất các các nguyên nhân bất thường
trên tổng số lần giải phóng ERAB.
𝑪𝒂𝒍𝒍 𝑫𝒓𝒐𝒑 𝑹𝒂𝒕𝒆 = 𝟏𝟎𝟎% ∗ 𝑬𝑹𝑨𝑩𝑨𝒃𝒏𝒐𝒓𝒎𝒂𝒍𝑹𝒆𝒍𝒆𝒂𝒔𝒆/𝑬𝑹𝑨𝑩𝑹𝒆𝒍𝒆𝒂𝒔𝒆

Tên KPI Tỷ lệ rớt dịch vụ Công thức


QĐ 2123 Call Drop Rate

100*([M8006C261] + [M8006C254] - [M8006C255] - [M8006C258] -


Service Drop (all
NSN Name [M8006C260])/([M8006C254] + [M8006C261] + [M8006C6] + [M8006C7] + [M8006C8] +
service)
[M8006C9] + [M8006C277])

Huawei Service Drop Rate nvl((nvl([L.E-RAB.AbnormRel],0)/(nvl([L.E-RAB.AbnormRel],1)+nvl([L.E-


Name (All) RAB.NormRel],0)+nvl([L.E-RAB.NormRel.IRatHOOut],0)))*100,0)
Ericsson Service Drop (all 100 * ( [pmErabRelAbnormalEnbAct] + [pmErabRelAbnormalMmeAct] ) / (
Name service) [pmErabRelAbnormalEnb] + [pmErabRelNormalEnb] + [pmErabRelMme] )
Service Drop (all 100*(C373210381+C373210391+C373210421+C373210441+C373210451+C373210511+
ZTE Name
service) New C373210521+C373505354)/(C373210461+C373505473+C373505481+C373546257)
Pmtool Service Drop (all
Name service)
Đơn vị %
2.6.3. Tỷ lệ chuyển giao cùng tần số thành công (Intra-frequency)
Định nghĩa: Tỷ lệ chuyển giao Intra-frequency thành công được tính dựa trên số lần chuyển giao thành công trên tổng số
yêu cầu chuyển giao giữa các cell cùng tần số bao gồm cả trường hợp chuyển giao trong cùng eNodeB và chuyển giao giữa
các eNodeB tính trong phase excution.
𝐈𝐧𝐭𝐫𝐚 𝐅𝐫𝐞𝐪𝐮𝐞𝐧𝐜𝐲 𝐇𝐎 𝐒𝐮𝐜𝐜𝐞𝐬𝐬 𝐑𝐚𝐭𝐞 = 𝟏𝟎𝟎% ∗ 𝐈𝐧𝐭𝐫𝐚𝐅𝐫𝐞𝐪𝐇𝐎𝐎𝐮𝐭𝐒𝐮𝐜𝐜𝐞𝐬 𝒔Τ𝑰 𝐧𝐭𝐫𝐚𝐅𝐫𝐞𝐪𝐇𝐎𝐎𝐮𝐭𝐀𝐭𝐭𝐞𝐦𝐩𝐭

Tỷ lệ chuyển giao Intra-


Tên KPI Công thức
frequency thành công

Infra Frequency HO Success


QĐ 2123
Rate

NSN Name Intra-frequency HO 100*([M8009C7] + [M8014C7] + [M8014C19] - [M8021C2]) / ([M8009C6] + [M8014C6] +[M8014C18] - [M8021C0])

Intra-Frequency Handover (([L.HHO.IntraeNB.IntraFreq.ExecSuccOut]+[L.HHO.IntereNB.IntraFreq.ExecSuccOut])/([L.HHO.IntraeNB.IntraFre


Huawei Name
Out Success Rate (All) q.ExecAttOut]+[L.HHO.IntereNB.IntraFreq.ExecAttOut]))*100

Intra-frequency HO
Ericsson Name 100 * ([pmHoExeSuccLteIntraF] / [pmHoExeAttLteIntraF])
Execution

100*(([C373250980]+[C373261280]+[C373271580])/([C373250980]+[C373250981]+[C373250982]+[C373250983]
+[C373250989]+[C373250901]+[C373250902]+[C373250903]+[C373250988]+[C373261280]+[C373261281]+[C37
ZTE Name Intra-frequency HO 3261282]+[C373261283]+[C373261201]+[C373261202]+[C373261203]+[C373261204]+[C373261289]+[C3732612
94]+[C373271580]+[C373271581]+[C373271582]+[C373271583]+[C373271501]+[C373271502]+[C373271503]+[
C373271504]+[C373271588]+[C373271593]))

Pmtool Name Intra-frequency HO

Đơn vị %
2.6.4. Tỷ lệ chuẩn bị CSFB thành công
Định nghĩa: Là tỷ lệ chuẩn bị CSFB thành công từ mạng E-UTRAN sang các mạng khác (UTRAN, GSM). Chỉ tiêu này đánh
giá tỉ lệ chuyển giao thành công sang các công nghệ 2G/3G khi thuê bao đang ở mạng 4G thực hiện cuộc gọi Voice.
𝐂𝐒𝐅𝐁 𝐏𝐫𝐞𝐩𝐚𝐫𝐚𝐭𝐢𝐨𝐧 𝐒𝐮𝐜𝐜𝐞𝐬𝐬 𝐑𝐚𝐭𝐞 = 𝟏𝟎𝟎% ∗ 𝐂𝐒𝐅𝐁_𝐏𝐫𝐞𝐩𝐚𝐫𝐚𝐭𝐢𝐨𝐧_𝐒𝐮𝐜𝐜𝐞𝐬 𝒔Τ𝑪 𝐒𝐅𝐁_𝐏𝐫𝐞𝐩𝐚𝐫𝐚𝐭𝐢𝐨𝐧_𝐀𝐭𝐭𝐞𝐦𝐩𝐭
Tỷ lệ chuẩn bị CSFB thành
Tên KPI Công thức
công
CSFB Preparation Success
QĐ 2123
Rate (%)
E-UTRAN Initial Context
NSN Name Setup Success Ratio being 100*decode([M8013C46],0,null,[M8013C48]/[M8013C46])
Subject for CS Fallback
Huawei
CSFB_Preparation_SR (L.CSFB.PrepSucc/L.CSFB.PrepAtt) x 100%
Name
Ericsson
NA NA
Name
E-UTRAN Initial Context 100*(decode([C373220644]+[C373220647]+[C373220650]+[C373220653],0,null,([C
ZTE Name Setup Success Ratio being 373220645]+[C373220648]+[C373220651]+[C373220654])/([C373220644]+[C3732
Subject for CS Fallback 20647]+[C373220650]+[C373220653])))
Pmtool
Name
Đơn vị %
2.6.5. Chỉ tiêu Bad cell 4G

a. Định nghĩa
- Cell vô tuyến di động 4G được xác định là cell xấu nếu rơi vào 1 trong các tiêu chí sau:
+ Data CSSR ≤ 95%
+ DCR ≥ 3 %
+ Intra-Freq-HOSR ≤ 95%
+ CSFB Preparation Success Rate ≤ 95%.
- Số liệu thống kê các chỉ tiêu trên với thời gian vi phạm ≥ 1 giờ/7 ngày, xét các giờ có data volume ≥ 500
MB/giờ, HO-Attemp ≥ 25 cuộc/giờ.
b. Yêu cầu
+ Toàn mạng: ≤ 2%
+ Mức Tỉnh, Quận, Huyện thuộc HNI, HCM, HPG, CTO, DNG: ≤ 1%
+ Mức Tỉnh, Quận, Huyện thuộc các Tỉnh/Tp khác: ≤ 2%
2.7. Phương pháp thống kê Badcell dựa trên hệ thống PMS
Như nội dung đã được hướng dẫn trong bài giảng về hệ thống PMS, trong khuôn khổ tài liệu về hướng dẫn xử lý Badcell sẽ
tập trung vào cách thống kê Badcell dựa trên chức năng lọc KPIs của hệ thống. Nhằm giúp các học viên có thể chủ động lấy
thông kê, theo dõi kết quả các Badcell đã tác động xử lý, chủ động đánh giá được các badcell phát sinh từ đó có thể lập kế
hoạch chi tiết và phối hợp cùng các đơn vị trong công tác xử lý.
Có 2 phương pháp thống kê Badcell trên hệ thống PMS
- Thống kê Badcell theo từng chỉ tiêu KPI. Ưu điểm cách lấy này là sẽ chỉ ra chi tiết các Cell và KPI vi phạm, nhược điểm là thống
kê mất nhiều thời gian vì phải lấy nhiều lần.
- Thống kê Badcell bằng cách gộp nhiều điều kiện badcell trong 1 lần lấy. Ưu điểm cách lấy này sẽ thống kê được toàn bộ các
Badcell không phải thực hiện lấy nhiều lần. Nhược điểm, là không chỉ ra rõ Cell đó vi phạm chỉ tiêu KPI nào.
Lưu ý: Để phục vụ công tác đánh giá, xử lý Badcell khi lấy thống kê thì ngoài các chỉ tiêu KPIs badcell nên bổ sung một số chỉ tiêu liên quan đến chất lượng
mạng như: Nghẽn tài nguyên vô tuyến, hiệu suất sử dụng tài nguyên vô tuyến…
2.7.1. Tổng hợp chỉ tiêu KPI Badcell và thiết lập công thức trên PMS
Các chỉ tiêu KPI đánh giá về Badcell
Tiêu
Tech Bổ tiêu chuẩn 206 Chỉ tiêu PM Diễn giải Công thức thiết lập trên PMS Ghi chú
chuẩn
Callvolume CALVOL Số cuộc >50
((CSSRV1<=95 or DCR>=3) or Lấy thêm các chỉ
CSSR CSSRV1 Tỉ lệ thiết lập cuộc gọi thành công <=95
2G (HOSR<=95 and HOSR_ATT>=25)) số nghẽn
HOSR HOSR Tỉ lệ chuyển giao thành công and CALVOL>=50 TCH,SDCCH
DCR DCR Tỉ lệ rớt cuộc >=3
Tỉ lệ thiết lập cuộc gọi thành công ((CSSR<=95 or DCR>=3) or
CS-CSSR CS_CSSR <=95
miền Voice ((IRATHOSR<=95 and
CS-DCR CS_DCR Tỉ lệ rớt cuộc thoại >=3 CS_IR_ATT>=25) or
Lấy thêm các chỉ
CS Intra-Freq-HOSR CS_HOSR Tỉ lệ chuyển giao mềm thành công <=95 (SOFTHOSR<=95 and
3G-CS số nghẽn CS_RAB
CS_SO_ATT>=25) or (
Tỉ lệ chuyển giao thành công giữa cac Congestion rate
CS IF-HOSR CS_IFHOSR <=95 CSINTERFREQHOSR<=95 and
tần số
CS_IF_ATT>=25))) and
CS Inter-RAT-HOSR CS_IRATHOSR Tỉ lệ chuyển giao thành công từ 3G-2G <=95 CALLVOLUME>=50
PS-ASR PSCSSR Tỉ lệ thiết lập thành công miền Data <=95 ((PSCSSR<=95 or PSDCR>=3) or
((SOFTHOSRPS<=95 and
PS-DCR PSDCR Tỉ lệ rớt phiên Data >=3 Lấy thêm các chỉ
PS_SO_ATT>=25 ) or
3G-PS số nghẽn PS_RAB
Tỉ lệ chuyển giao mềm thành công (V2INTERFREQHOSRPS<=95 and
PS IF-HOSR PSSOFTHOSRPS <=95 Congestion rate
miền data PS_IF_ATT>=25))) and
PSTRAFFIC>=0.25
Data CSSR CSSR Tỉ lệ thiết lập thành công miền Data <=95 Lấy thêm các chỉ
((CSSR<=95 or
số :
DCR SERVICE_DROP_ALL Tỉ lệ rớt phiên Data >=3 SERVICE_DROP_ALL>=3) or
-Resoure Block
Tỉ lệ chuyển giao thành công chuyển ((INTRA_FREQUENCY_HO<=95 and
4G CSFB Preparation Success Rate CSFB_SSR <=95 Usage
mạch kênh INTRA_HOSR_ATT>=25) or
-RRC_SSRATE,
Tỉ lệ chuyển giao thành công trong một (CSFB_SSR<=95 and
Intra-Freq-HOSR INTRA_FREQUENCY_HO <=95 ERAB_SSRATE_A
tần số CSFB_ATT>=25))) and TRAFFIC>=0.5
LL
2.7.2. Thống kê Badcell 2G
2.7.3. Thống kê Badcell 3G-CS
2.7.4. Thống kê Badcell 3G-PS
2.7.5. Thống kê Badcell 4G
3. Phân tích nguyên nhân và phương pháp xử lý
3.1. Quy trình xử lý Badcell
3.2. Diễn giải quy trình xử lý badcell
Hệ thống/ Người Đơn vị Đơn vị
Thời gian Biểu
Bước Mô tả công việc Thông tin đầu vào Thông tin đầu ra Công cụ thực chủ trì phối
/Tần suất mẫu
hỗ trợ hiện thực hiện hợp

Thẩm
Giám
Kiểm
Hỗ trợtra
sát
định
thẩmtại
hệbadcell
trạm:
thống
định, phân vô
để tuyến:
đưatíchvàovà danh
tạo CRs: sách Định kỳ
Các tham số hệ
-Giám
blacklist: Nếu sát,
Thẩm nguyên
định thuCRs thập
nhân dosốdo
VNPT
liệu
lỗi CSHT/phần
thống
T/TP kê đề định
xuấtcứng:
kỳ
trước
từChuyển
các
khi hệ hàng Số liệu KPIs KS Vô
1 thống mức KS Vô NOCx VTT/TP
Netx,
11
7 thống
bước
-thực Nếuhiện.
8
badcell
quan
thựctrắc hiện.
đủmứctiêu chuẩn
cell, trạm,đưaBSC/RNC,
vào danh sách quận giờ/ngày/
½
1 ngày
ngày Phương
Danh sáchánbadcell
xử lý mức
Kết cell/trạm…
quả xử lý tuyến
CV VTT/TP
Netx NOCx,
cell/trạm… Kết quả thẩm tuyến NOCx
16 -huyện,
blacklist Nếutrợ
Hỗ không
tỉnh,
phân
thì chuyển
khu
phải
tíchvực,
do
logfile
bước
lỗi
toànCSHT/phần
đo17mạng.
kiểm
để đưa để cứng:
tạo
vàoCRs,
danh
Chuyển
sau
sách đó 7tuần
ngày đề xuất đưa vào quản lý NMC Netx,
định
bước 9 để
chuyển
blacklist. CRs đocho kiểm VNPT hiệnT/TP trường.thực hiện. blacklist mạng VTT/TP
Phát
- Nếuhiện badcell badcell:
không thuộc blacklist: Quay lại bước 5 Hàng Các cell vi phạm
Thực
Xử
Phát
để lý hiện
xử hiện
CRs hiện
xử
lý lại badcell
từ đầu.lýtrường:
lỗithông
phầnqua các chỉ tiêu KPI được
cứng/CSHT: Bảng số liệu KPIs KS Vô
2 ngày/ chỉ tiêu NOCx
-quy Nếuđịnh
Thực nguyên
hiện theohiệu điều
nhân chỉnhdokiện tại quyết
CSHT/nguồn
outdoor theo các địnhCRs số đã
điện/truyền dẫn:
được
206/QĐ- mức cell/trạm… tuyến
hàng tuần (theo QĐ 206)
Thực
Đưa
VNPT-CN-CLG
phân hiện khắc
tích.
danh sáchngày phục.
badcell 20/02/2019
vào blacklistcủa Tập đoàn.
KS Vô Netx,
12 - Đo Nếu
Tậpkiểm,
do thiết
hợp phân
hồ bị tích,
sơ, hỏng
gửi đánh
hóc, KTM/TT
Ban giá
cầnlại thayvùngthế,phủ.
NMC bổ
để sung
thẩmvật định ½ ngày Phương án xử lý Kết quả xử lý VTT/TP
Tạo phiếu badcell: Các cell vi phạm tuyến
CV NOCx
NOCx,
-tư,
và Theo
thiết
đưa dõibị (trong
vào KPIs
danhhệ trường
thống.
sách hợp NETx có sẵn, VNPT
blacklist. Trình
DanhTập đoàn
sách KS
17 Khởi tạo phiếu thông báo 7 ngày Kết quả
chỉthẩm định KS Vô
quản lý
Vô NMC Netx,
3
8 -T/TP Sau
Trình không
khi xử còn):
danh lý xong,
sách NETx chuyển
badcell sẽxử bànlý badcell
bước
thuộc giao 13vật
blacklist để
đểtư, các
kiểm
để đơn
thiết
bantrabị
Côngvị ½ ngày
1 ngày Phương tiêu
án xử lý Kết quả
phê xử lý
duyệt
badcell tuyến
NOCx
VTT/TP
liên quan cùng tuyến
mạng NOCx
VTT/TP
cho
KPIs
nghệ VNPT
hệ
thẩm định,theo
thống.
T/TP. Địadõi
xem xétvàgiảm
điểm phốitrừ
bàn hợp
giao xử lý.
thiết
trong bị: Tại
công tácTrạm
đánh (theo QĐ 206)
Viễnkết
giá thông
quả củaBSCNETx hàng tại quý địa bàn.
của đơn vị.
Theo
- Thựcdõi
Kiểm hiện
tra vàkiểm
KPIs quản
hệtra, lý thay
côngđổi
thống: táctham
xử lý sốbadcell:
tại hiện trường Danh sách CV
KPIs của Netx,
4 -Nhận Kiểm kết
(tilt/alzimuth…).
tra quả
kết xử
quả lý badcell
KPIs lên từ
hệ các
thống. đơn vị để tổng hợp 7 ngày Danh sách
Danh sách badcell
badcell badcell gửicác
các quản
KS Vôlý NMC VTT/TP
13 ½ ngày badcell đãvịđược VTT/TP VTT/TP

- Sau báođó
Sau cáo
đó theo quy
chuyển
chuyển kết định.
kếtquả quảđến đến bướcbước để để
14 14 tổngtổnghợp.hợp đã được xử lý đơn mạng
tuyến NOCx
xử lý
kết quả xử lý.
Phân
Đo kiểm tíchhiệnđánh giá nguyên nhân badcell và đưa ra
trường:
- Đo cầu
yêu
Theo dõixử
kiểm kết
hiệnlý:quả
trườngxử lý badcell:
bài đo phù hợp. Phương
Kết quảán xửxử
lý lý
theo KS Vô Netx,
9 Nếu
--- Nếu nguyên nhân lỗithìhệ
do file, thống: Chuyển bước 6 ½ ngày Phương án xử lý KS Vô VTT/TP
5 tích sơxử
Phânbadcell bộ được
lý log chuyển
đưa ra cácbước đánh15 đểgiá đóng
ban ½ ngày Danh sách
Danh sách badcell
badcell đối với từng tuyến
KS Vô NOCx NOCx
VTT/TP
Netx,
14 để
phiếu kiểm xử tra
lý tham
badcell. số hệ thống.
đầu và đề xuất phương án xử lý (nếu có thể). 1 ngày Kết quả theo dõi tuyến NOCx
đã được xử lý badcell tuyến VTT/TP
Nếu badcell
-- Nếu không phải chưadoxửlỗilýhệ đượcthống: Chuyểnbước
thì chuyển bước16 để
7 để
kiểmvào
đưa
Phân tra
tíchtại trạm.
CRs:
danh sách thẩm định blacklist.
- Phân tích kết quả đo kiểm đưa ra CRs.
Kiểm
Đóng
- Trong tra
phiếu tham
trường xửsố lý hệ
hợp cầnthống:
badcell. phân tích chuyên sâu, gửi đề Danh sách badcell Kết thúc quá KS Vô Netx,
Kiểm đưa yêu cầu Phương án xử lý Kết quả xử lý
hoặcđổi,
15
10 -nghị ½ ngày NOCx
VTT/TP
tớitra,
VNPT phân NETxtíchđể vàhỗ trợrathẩmcác định CRsthay đề đã được xử lý trình theo dõi tuyến NOCx
VTT/TP
điều chỉnh tham số hệ thống
nghị VNPT NETx hỗ trợ phân tích logfile đo kiểm để (như: rà soát neighbor, KS Vô
6 ½ ngày Phương án xử lý Kết quả xử lý NOCx VTT/TP
điều chỉnh ngưỡng HO, …) để đảm bảo badcell được
tạo CRs. tuyến
khắc phục.
- Chuyển bước 14 để tổng hợp kết quả xử lý.
3.3. Ma trận RACI quy trình xử lý badcell
VNPT NET
VNPT T/TP
STT Các bước thực hiện Ban KTM
TTĐH NETx
NOCx NMC
1 Giám sát hệ thống vô tuyến I I AR I
2 Phát hiện badcell I I AR I
3 Tạo phiếu badcell I I AR I
4 Theo dõi và quản lý công tác xử lý badcell I I R AR

5 Phân tích đánh giá nguyên nhân badcell và đưa ra yêu cầu xử lý I I AR I

6 Kiểm tra tham số hệ thống I R AR I


7 Kiểm tra tại trạm AR I I I
8 Thực hiện xử lý lỗi phần cứng/CSHT AR R CI I

9 Đo kiểm hiện trường AR RC CI I

10 Phân tích CRs AR R R I


11 Hỗ trợ thẩm định, phân tích và tạo CRs R AR I I
12 Xử lý CRs hiện trường AR I CI I
13 Kiểm tra KPIs hệ thống R AR RC I
14 Theo dõi kết quả xử lý badcell I I AR R
15 Đóng phiếu xử lý badcell I I AR R
16 Thẩm định badcell để đưa vào danh sách blacklist R R R AR
17 Đưa danh sách badcell vào blacklist I CI R AR
3.4. Phân tích xử lý Badcell 2G
3.4.1. Những nguyên nhân thường gặp

- Do phần cứng: Sóng đứng (VSWR), lỗi hoặc suy giảm chất lượng các khối thu phát (TRE,ANC,CTU,DUP…)
- Do thiết kế RF: Thiết kế tần số không chính xác như: Trùng kênh, cận kênh BCCH,TCH gây nhiễu BCH, TCH… Đặc biệt
lưu ý trường hợp trùng, cận tần số BCCH sẽ gây suy giảm chất lượng rất lớn.
- Do outdoor thiết kế và lắp đặt không đúng: Chéo cell, overshoot, không đúng hướng, sai tọa độ. Các lỗi này dẫn đến
suy giảm chất lượng vô tuyến như Rx_level, Rx_Qual.
- Do chất lượng truyền tải: Rớt gói, mất đồng bộ.
- Do địa hình, vị trí lắp đặt trạm: Như trạm chiếm lĩnh độ cao, vùng phục vụ xa và overshoot qua 4,5 lớp trạm, trạm giáp
biên giới... Địa hình đồi núi dẫn đến chất lượng sóng không ổn định.
- Do khai báo: Khai báo sai, thiếu tham số vô tuyến.
- Do nghẽn: Năng lực cell không đủ để phục vụ lưu lượng dẫn đến các cuộc gọi không thiết lập được do hết tài nguyên
(Nghẽn kênh báo hiệu SDCCH và kênh traffic TCH).
3.4.2. Tổng hợp phân tích và xử lý Badcell 2G
KPI
Công nghệ
(Các KPI trong Nội dung kiểm tra/phân tích Phương án xử lý Kinh nghiệm xử lý
(2G/3G/4G)
tiêu chí badcell)
Kiểm tra hiện trường - Vùng
Az, tiltphủ
sai kém: Điều
thiết kế: chỉnh
Audit tilt/AZM...
lại tilt/AZM.
theo thiết kế và theo dõi. Vớibadcell
-Với badcellDropcall
Handover
CSSR phần
phần
phần lớnlớn lớn
gây
gây gây
rara
- Vùng phủ: Đo kiểm hiện trường để - Cập
Thiếu nhật
Az, tilt sai thông
Neighbour: sốRà
thiết kế: tạisoát,
Audithiệnlại trường
tối
theo Long/Lat,
ưuthiết
lại NeighbourTilt/Azimuth
kế và theo khu nhằm ra
dõi.vực cell bởi:
bởi:
đánh giá vùng phủ và chất lượng. thiết
- Nếukếphát
kém. lại RF
hiệncho Cell,feeder
Swap trạm đảm (đứng bảo:ở vùng phủ của cell A1 + Chất lượng vùng phủ kém do phủ
- Site audit cập nhật
Long/Lat,Azimuth/Tilt + Không
Nếu
-nhưng lạixảy
phát bắt ra
hiện các
Swap
được lỗifeeder
cellnhư
A2…): trùng
(Đứng
SửaBCCH,TCH.
ở vùng
lại phủ của
dây feeder chocell A1 với quá rộng. Ví dụ như các trạm chiếm
đúng
- Kiểm tra Long/Lat,Azimuth/Tilt có
:Long/Lat,Azimuth/Tilt. + Giảmlại
nhưng
anten. thiểu
bắt cận
được kênh
cellTCH.
A2…): Sửa lại dây feeder cho đúng với + Mất
độđồng
Truyền
lĩnh dẫn
cao, bộ truyền
chất
phủ dẫn
lượng
sóng biểnkém.
đảo, trạm
Kiểmvới
-đúng tradữ liệu thiết kế không có
Long/Lat,Azimuth/Tilt + Không bị chéo Cell.
anten. biên
+ kế và
giới...
Thiết
Call drop dokhai báo sai,
Handover thiếu như:
Fail.
đúng
Kiểm với dữthống.
tra hệ liệu thiết kế không. + Tínhphát
- Nếu đầy hiện
đủ của Neighbors.
Overshoot (MS bắt vào cell ở xa cùng vùng phủ Trung + Thiếtcặp
kế vàBCCH-BSIC, thiếu
khai báo sai, thiếu như:
-Kiểm
Kiểmtra
trahệ thống
cảnh báo về truyền dẫn: - Xử vì
thay lý cell
các ở cảnh
gần):báoCụpvề tilt
truyền
cell gâydẫnovershoot.
đảm bảo chất lượng truyền Neighbors,
Trùng cận kênh trùngBCCH/TCH.
cận kênh
- Kiểm
Lỗi BIT,tra cảnh
mất đồngbáo về truyền dẫn:
bộ... -dẫn
Xửtốt.
lý các cảnh báo về truyền dẫn đảm bảo chất lượng truyền BCCH/TCH. + Nghẽn tài nguyên vô tuyến:
2G DCR Kiểm tra hệ thống - Xử lý các cảnh báo về truyền dẫn đảm bảo chất lượng truyền
Lỗi BIT, mất đồng bộ...
- Kiểm tra lỗi thiết bị phần cứng: Xửtốt.
-dẫn lý các cảnh báo liên quan đến phần cứng các khôi thu phát, TCH/SDCCH
- Kiểm tra cảnh báo về truyền dẫn: dẫn tốt.
2G HOSR - Kiểm traRSSI,
(VSWR, lỗi thiết
lỏngbị đầu
phầnconnector,
cứng: -cảnh
Xử lýbáocácsóng
cảnhđứng...:
báo liên quan đến phần cứng các khôi thu phát, + Lỗi , suy giảm chất lượng phần
Lỗi BIT, mất đồng bộ... - Xử lý các cảnh báo liên quan đến phần cứng các khôi thu phát,
(VSWR, RSSI, lỏng
hỏng TRX, DDU,CTU2,DUP…) đầu connector, Đo kiểm
-cảnh báo sóng trường
hiện đứng... tìm nguồn nhiễu để xử lý. Một số nguồn cứng.
2G CSSR - Kiểm tra lỗi thiết bị phần cứng: cảnh báo sóng đứng...
-hỏng
KiểmTRX, DDU,CTU2,DUP…)
tra nhiễu. -nhiễu
Kiểmdo trachính
trùng/kềnội bộ
tầnmạng gây ra do thiết
số BCCH/TCH, BSICRFcủakhông tốt như
cell kém và các
(VSWR, RSSI, lỏng đầu connector, - Kiểm tra trùng/kề tần số BCCH/TCH, BSIC của cell kém và các
Kiểm tra
- Thống kênhiễu.
TA: Đánh giá sơ bộ vùng nhiều
cell xungtrùng kênh chỉnh
quanh, và cậnlạikênh BCCH/TCH.(
tần khác Một số nguồn nhiễu
ít nhiễu hơn.
hỏng TRX, DDU,CTU2,DUP…) cell xung quanh.
- Thống
phủ sóng.kê TA: Đánh giá sơ bộ vùng -cần có thêm
Thống kê TA, cụckết
tầnhợpsố với
phốiđo hợp như
kiểm cáctrường
hiện nguồnđể nhiễu
quyếtnguồn
địnhtừ
- Thống kê TA: Đánh giá sơ bộ vùng - Thống kê nghẽn TCH, SDCCH các Cell nằm trong
phủ sóng. máy chỉnh
điều phá sóng, các máy
Tilt nhằm đảmcốbảo định kéovùng
giữa dài, phủ
các nguồn
sóng và Repeater
chất
phủ sóng. Neighborslist và xử lý đảm bảo năng lực đáp ứng.
- Các thống kê liên quan: Nghẽn hoặc bộ
lượng kíchphủ
vùng sóng).
sóng.
- Thống kê tỉ lệ HOSR giữa các cặp
SDCCH, Nghẽn TCH. - Thống kê TA, kết hợp với đo kiểm hiện trường để quyết định
Cell trong Neighborlist.
điều chỉnh Tilt nhằm đảm bảo giữa vùng phủ sóng và chất
- Các thống kê liên quan: Nghẽn
lượng vùng phủ sóng.
SDCCH, Nghẽn TCH.
- Nghẽn TCH,SDCCH: Xử lý nghẽn bằng cách khai thêm tài
nguyên TCH,SDCCH nếu còn có thể nâng cấp. Trogn trường
hợp không thể nâng cấp trạm thì có thể đưa ra các phương án
san tải sang các Cell khác, bổ sung newsite...
3.5. Phân tích xử lý Badcell 3G
3.5.1. Những nguyên nhân thường gặp

- Lỗi phần cứng: Suy giảm chất lượng các khối thu phát, điều khiển, các cảnh báo suy hao.
- Lỗi suy giảm chất lượng truyền tải như: Delay,Jitter,Packet_loss,Frame_Loss..
- Do thiết kế RF: Thiết kế không chính xác dẫn đến một số lỗi như: Trùng PSC, Overshoot, thiếu Neighbors…
- Do lắp đặt không đúng: Chéo cell, overshoot..
- Do địa hình, vị trí lắp đặt trạm: Như trạm chiếm lĩnh độ cao, vùng phục vụ xa và overshoot qua 4,5 lớp trạm, trạm giáp
biên giới... Địa hình đồi núi dẫn đến chất lượng sóng không ổn định.
- Do khai báo: Khai báo sai tham số vô tuyến, sai các nguyên tắc Interworking giữa các lớp mạng.
- Do nghẽn: Năng lực cell không đủ để phục vụ lưu lượng dẫn đến các cuộc gọi không thiết lập được, không chuyển giao
được do hết tài nguyên( nghẽn CE,Power,IUB..)
- Nhiễu vô tuyến RTWP
3.5.2. Tổng hợp phân tích và xử lý Badcell 3G
KPI
Công nghệ
(Các KPI trong Nội dung kiểm tra/phân tích Phương án xử lý Kinh nghiệm xử lý
(2G/3G/4G)
tiêu chí badcell)
Kiểm tra
Kiểm tra hiện
hiệntrường
trường:
trường Điều chỉnh
- Điều chỉnhvùng
vùngphủ
phủhợp
hợp lýnếu
cáclýtrạmnếu vùng
vùng
2G/3Gphủphủ
nhằm trạm
trạm kém,
kém,
đảm nhiễu
nhiễu
bảo với với
chất các Đối với
Đối với Badcell
Badcell
các Badcell CS/PS
HO
CSSR thường Drop
về trong call các
các
CS-IRAT 3G
- Đo kiểm phân tích đánh giá vùng
Đo kiểm phân tích đánh giá vùng lượngphủ. trạm lân
các trạm cận.
lânphủ.
vùng cận. nguyên
nguyên có
thường nhân
nhân
rất chủ
chủ
1ít.sốCác yếu
yếu
nguyên sau:
nguyênlànhân
là:nhânchính
chủ
Site2G/3G.
phủ.
-phủ audit cập nhật: -- Cập
Cập nhật
nhậtthông
thôngtin
tinLong/Lat, Azimuth/Tilt
Long/Lat,Azimuth/Tilt
Long/Lat, Azimuth/Tiltvàvàthiết
và kếkế
thiết
thiết lạilại
kế RF nếunếu
lạiRF
RF có
các -như
yếuVùng
Vùng phủ
sau:
gây phủ quá
quárộng
Badcell rộng
CSSR không
dẫn đảmnghẽn
là:đến bảo
Long/Lat,Azimuth/Tilt.
- Site audit cập nhật: sự sai
trạm lệch.
có sự2G/3G
sai lệch.
nếu một trong hai trạm có sụ thay đổi. chất
tài
+ lượng
nguyên
Không
- Vùng trong

Update
phủ quá quá
chất thay
rộng trình
lượngđổi chuyển
dẫn vô
đếntuyến
cấu hình,
nghẽn
Kiểm tra Long/Lat,Azimuth/Tilt
-Long/Lat,Azimuth/Tilt
Long/Lat,Azimuth/Tilt. 2G/3G. có giao.
không
tham
tài nguyênđảm
số cácvàbảo.
trạm
chất2G lượngtrênvô 3G.tuyến
đúng
- Kiểm với
tradữLong/Lat,
liệu thiết Azimuth/Tilt
kế.
Long/Lat,Azimuth/Tilt có
có -+ Sai
Chất
Vùng
-không thiếu
lượng
phủ
đảm Neighbors
2Gtruyền
bảo. không hoặc
tải IP không
đảm không đảm
bảo cho
update cấu hình Neighbor (Đặc biệt là
Kiểm tra hệ
đúng với dữ thống
liệu thiết kế. -Tương tự như quá trình xử lý các Badcell về CSSR, DCR với bảo,
việc đặckêbiệt
chuyển
- Thiết các
dẫn lỗi:
saigiao. đếnTruyền dẫn lỗi
trùng PSC,
-Kiểm
Trạngtra hệNodeB,
thái thống các cảnh báo phần Badcell - Đảm bảo HOSR xử cũng
lý hếtphải
các xửcảnh báocảnh
lý các về phần cứng
báo liên đặcđến
quan biệtHW,
các các thay đổi về LAC/TAC/CI/PSC của
không
này rấtổn định Packet_loss,
nghiêm trọng vì ngoài gây
cứng
- Trạngnếu có NodeB,
thái như: Cáccác khối thu báo
cảnh phát, truyền
cảnh báo tải nhiễu,
liên quan đánhđến giácác
vùngkhối phủđiều
thông qua và
khiển thống
thu kê TPvô
phát ta cần các suy
External 3G Cell trong Neighbors
giảm
Frame_Loss...CSSR thì trùng PSC còn
Kiểm tra hệ thống -Xử lý triệt để các tồn tại cảnh báo các trạm 2G,3G. List).
3G điều
phần khiển
cứng nếu có như: Các khối thu thực
tuyến. hiện thêm một số công việc:
CS/PS IRAT - Kiểm tra cảnh báo, truyền dẫn các - Thống kê CS_IRAT cặp Neighbors nhằm lọc ra các cặp có tỉ lệ -dẫn - Thiết kế sai dẫn
đến DCR cao,HOSR đến trùng PSC,
kém, sai
chất
+ Thống kê cùng
tỉ lệ HOSR cácvị cặp Neighbors, rà soát cácvề cặp Cell Nghẽn tài nguyên vô tuyến các Cell
có tỉ thiếu
phát, điều khiển
RRU,BBU,RF_Module,FM_module. - Phối hợp các đơn phân tích, xử lý các lỗi suy giảm lượng Neighbors.
trạm, Cell 2G nằm trong Neighbors thấp để tập trung xử lý.
Kiểm tra chất lượng truyền tải IP của lệ tấplượng
để kiểm tra, xử lân cận,thoại
chấtkhông
lượng đảm truyềnbảo.tải không
CS-PS Drop -RRU,BBU,RF_Module,FM_module. chất ượng truyền
truyền tảilý.
tải IP (Phong
IP( Phong INOC-NET,TTĐH thông
INOC-NET,TTĐH thông tin
tin -- - Ngoài ra còn mốt số lỗi như: Các
3G CS/PS-CSSR List. cũng như các trạm lân cận nằm +
CS/PS SHO trạm - Kiểm tra,
Xử lýtỉnh
cập
các /thành
nhật
Cell lậnphố).
các tham số khai báo trên các
cận trong trường hợp nghẽn năng lực vô tuyến
Cell 2G/3G đảm bảo.
Call - Kiểm tra chất lượng truyền tải IP: VNPT quá trình thay đổi QoS hoặc các
- Thống
trong kê CR_IRAT
Neighbors list cặp Neighbors dẫn
Packet_Loss, nếu đến có sự HO thay
fail. đổi. Đối với 3G quan trọng là các tham số
Kiểm tra trên hệ thống các cảnh báo - Đánh giá vùng phủ phủ thông qua thống kê TP, kết hợp với đo tham số chất lượng phía truyền tải IP
3G-2G
Frame_loss,Jitter... LAC/RAC/CI.
+ Khai báo, cậpĐối vớiđảm
nhật 2G bảo là các tham
tuân thủ số LAC/RAC/CI/BCCH,
chiến lược interworking.
về chất lượng truyền tải IP như kiểm hiện trường đưa ra các khuyến nghị về điều chỉnh nhằm đẫn đến suy giảm chất lượng vô
Kiểm tra
-- Thống kê các
đánh tham số cấu
giá vùng hình
phủ: TP,Cell
rà + BSIC.
Update sự thay đổi các thông số Cell nằm trong Neighbor List.
đảm bảo vùng phủ cũng như chất lượng vùng phủ. Xử lý các
- Xử lý các Cell 2G có thống kê nghẽn kên traffic đảm bảo năng tuyến (Ít xảy ra nhưng nếu xảy ra là
Packet_Loss, Frame_loss,Jitter...
2G trong
soát Neighbors List.
Neighbors.
- Thống kê đánh giá vùng phủ: TP, TP. rà trường
Phối hợpxử trùng PSC nếu có.nếu có: Nguồn nhiễu ngoài như
Năng lực
- Thống kê tỉvôlệtuyến
HOSRcác giữaCell
các2G.
Cặp
-lực chohợpcác cuộc lý nguồn
gọi chuyểnnhiễu giao từ mạng 3G bằng cách năng sẽ bị ảnh hưởng trên diện rộng)
Đánh giá các KPI liên quan đến Kiểm
-các bộ tra tính đầyMáy
Repeater, đủ vàthu đúng
phát của Neighbors
vô số,
tuyến hoặc cũngnguồn
như năng
báocác nhiễu
soát Neighbors.
-Neighbors. cấp thêm phần cứng, bổ sung tần khai HR,Full-HR...
Đánh
--hiệu giá
suất, các
năng KPI
lực liên
Node:quan
Đánh giá các KPI liên quan đến hiệu
đến lực
nội vô
tại tuyến
phát của
sinh các
do cácNeighbors
vị trí tiếp đảm
xúc, bảo
tiếp HO
nối tốt không bị rớt
hiệu suất, năng
CE,Power,Code,IUB.
suất, năng lực Node: lực Node: cuộc.
Anten,Feeder,Jumper chưa tốt.
CE,Power,Code,IUB
- Thống kê nhiễu RTWP.
CE,Power,Code,IUB củacác
của cácnode,
node,cell - Phối
Đánhhợp xử lý nguồn
giá năng nhiễu nếu
lực Cell,Node: Cócó:thểNguồn
nâng cấpnhiễubằngngoài như
cách bổ
- Rà soát
cell
xung xung các bộ Repeater, Máy thu phát
khai báo hệ thống: LAC/CI, sung CE, nâng cấp băng thông, nâng cấp thêm Cell nếu có thế.
quanh.
quanh. vô tuyến hoặc các nguồn nhiễu
Thống
--PSC...
Rà soátkê nhiễu
khai báo RTWP.
chiến lược nội
- Ràtại phát
soát hệsinh do các
thống, vị trí cùng
kết hợp tiếp xúc, tiếp nốixử lý các trường
Drivingtest
Interworking giữa các lớp mạng. Anten,Feeder,Jumper
hợp các cell lân cận bịchưa trùngtốt. PSC.
3.6. Phân tích xử lý Badcell 4G
3.6.1. Những nguyên nhân thường gặp

- Lỗi phần cứng: Suy giảm chất lượng các khối thu phát, điều khiển, các cảnh báo suy hao.
- Lỗi suy giảm chất lượng truyền tải như: Delay,Jitter,Packet_loss,Frame_Loss..
- Do thiết kế RF: Thiết kế không chính xác dẫn đến một số lỗi như: PCI/RSI, Overshoot, thiếu Neighbors.
- Thiếu định tuyến X2.
- Do lắp đặt không đúng: Chéo cell, overshoot..
- Do địa hình, vị trí lắp đặt trạm: Như trạm chiếm lĩnh độ cao, vùng phục vụ xa và overshoot qua 4,5 lớp trạm, trạm giáp
biên giới... Địa hình đồi núi dẫn đến chất lượng sóng không ổn định.
- Do khai báo: Khai báo sai tham số vô tuyến, sai các nguyên tắc Interworking giữa các lớp mạng. (Mapping TAC/LAC,
Priority các lớp mạng 3G 900/2100…)
- Do nghẽn: Năng lực cell không đủ để phục vụ lưu lượng dẫn đến các cuộc gọi không thiết lập được, không chuyển giao
được do hết tài nguyên (Hiệu suất sử dụng Resouce Block cao, Power,IUB..)
- Nhiễu vô tuyến RTWP
3.6.2. Tổng hợp phân tích và xử lý Badcell 4G
KPI
Công nghệ
(Các KPI trong Nội dung kiểm tra/phân tích Phương án xử lý Kinh nghiệm xử lý
(2G/3G/4G)
tiêu chí badcell)
Kiểm tra hiện trường - Vùng phủ kém: Điều chỉnh tilt/AZM. tilt/AZM…
tilt/AZM Đối
Với với
- Badcell Badcell
Badcell4G4G CSSR CSFB
DCR rất ít xuất
thường
nguyên rất
nhânít.hiện.
- Đo kiểm phân tích đánh giá vùng - Az,
Cậptilt
nhậtsai thông
thiết kế: số Audit lại theo
Long/Lat, thiết kế vàràtheo
Azimuth/Tilt, soátdõi.
RF, thiết kế Nguyên
chủ
Các yếu nhân
trường
nhưhợp chủxảy
sau: yếuradẫn đến chỉ
thường do số
phủ. -lạiNếu
nếuphát
thông hiệntin Swap
thiếu feeder
có sựNeighbour:
thay đổi.(ĐứngRà ởsoát,
vùngtốiphủ ưu của cell A1
lại Neighbour KPI Vùng
VÙng
-các nàyphủ,
kémnhân:
phủ,
nguyên thường nằm
neighbors,
neighbors, ở các
truyền
truyền tải.vị trí
tải.
- Site audit cập nhật: Long/Lat, nhưng
khu
- Thựcvựclại
hiện bắtxử
cell được
kém lỗicell
lý (Do 4GA2…):
chéo bật
CellANRSửanên
nếu lạiđồng
có dây
cần feeder
check
bộ chuẩn choaudit
và đúngNB).
cùng với
số sóng
-+Để
Vùng 2G/3G
tối phủ kém…
ưu Neighbors
rộng đặc
hoặc ta biệt
phức
có thểlà
tạp:các
bật vị
Long/Lat,Azimuth/Tilt.
Azimuth/Tilt. -liệu
Nếu
anten. RFphát
đã được
hiện Swap thiết kế.feeder (Đứng ở vùng phủ của cell A1 trí
ANR chỉsau
Chiếm có trạm
lĩnhđóđộ 4G
dựa
cao, Only.
trên
biển
kếtđảo,
quảthiết
đó để kế
- Kiểm tra Long/Lat, Azimuth/Tiltcó
Long/Lat,Azimuth/Tilt có Nếu phát
-nhưng lại bắthiệnđược Overshoot:
cell A2…): CụpSửatilt cell gâyfeeder
lại dây overshoot.
cho đúng với -tối
Tiltưu,
không
Nguyên cânnhân
hợp
chỉnh.thứ 2: Vùng phủ sóng
lý.
đúng với dữ liệu thiết kế. anten. 3G/4
+ Trùngkhông đồng bộ có thể do độ
PCI/RSI.
- Nếu phát hiện Overshoot: Cụp tilt cell gây overshoot. cao Anten, góc ngẩng, góc phương
Kiểm tra hệ thống - Tương
Đảm bảo tự xử
như lý với
triệtphương
để các cảnhán xửbáo lý KPI
suyCSSRgiảm, ta lỗi cần
phầnxửcứng
lý và vị không đồng nhất .
RRC Setup - Thực Kiểm
Đối vớihiện kiểm tra
traIntra-Frequency
các cảnh báo HW các EnodeB
HOđặc đâybiệt đảm bảo:
là bằng cách thay thế HW.
Kiểm tra hệ thống
Success Rate/ tương - Tương tự như với phương án xử lý KPI CSSR ta cần xử lý và
các giữa
HO cảnhtự các
đối
báovới
liênxử
Cell 4G
quanlýcùng
4G đến CSSR:
tần vì +
cácsốkhối Xử lýtra
- Kiểm triệt để các
truyền dẫn:cảnh báo kê
Thống HW, truyền
chất lượng dẫn, trùngtảiPCI/RSI,
truyền IP trên
eRAB
PSCSFB
Intra- -
Setup Cảnh Tương tự như badcell CSSR, với đảm bảo:
thu
vậy báovàviệc
phát
ngoài phần
điều cứng,
kiểm
khiển tra truyền
vôcác tuyến.tải, tin nhiễu.
thông WEB ĐồngPing
hoặc thờitestta thực
vơi hiện:
số lượng mẫu lớn để đánh giá và phối
4G
4G Call Rate badcell DCR ta cũng cần kiểm tra:
DropRate/
Preparation
Success
Frequency + Xử lý triệt để các cảnh báo HW, truyền dẫn, trùng PCI/RSI,
vùng
- Kiểmphủ,
tương tự nhiễu.
tra4G_CSSR
chất Đồng
lượng như:thời
truyền với
Cảnh tải đó
báo +
IP hợpXử lý
Bậtcác
ANRcác
đơnđểcảnh
vịtựnhưbáo,
động các
INOC, cell
UpdateVNPT mất liên lạc Sau
Neighbors.
Tỉnh/thành của phốcác
khiđể trạm
ANR cáccập
xử lý.
đã Cell
Success
Data
HOSRCall + Cảnh báo phần cứng, truyền dẫn, nhiễu.
Rate Do
choCSFB
phần các
cứng, là truyền
EnodeB chuyển(Với giao
tải, 4G
trùngtừ
chất lớp lượng 3G
PCI/RSI - Đảm
nhật lân
đàycận
bảo nếu
đủvùng
sẽ thựccó.
phủ hiện
sóngtắt không
ANRphủ để tối
quá ưuxaNeighbors
gây suy giảm cho phù
chất
Setup vùng phủ, trùng PCI/RSI, nhiễu. - Đồng thời ta cần kiểm tra thêm lớp mạng 3G, các cell lân cận
mạng 4G
truyềnphủ
vùng tải vềcó 3G
thì thể để
lấy thực
ta cần tập hiện vào
trêntrung
trang cuộc
WEB: + Phối
lượng
hợp hợp
vớidẫnthực SNOC
đến tếsuymạng.kiểm
giảmtra khai
KPI. Kếtbáohợp Mapping
với Logfile TAC/LAC.
hiện trường
Success Rate gọi- Ngoài ra cần kiểm tra thêm: và các Cell nằm trong Neighbors list:
việc voice
kiểm nên
MMS.VNPT.VN) tra: ta cần kiểm tra thêm 1 + đưaKiểm
Phối tra và
ra hợp
các khaicác
khuyến
cùng báo
nghị Priority
VNPTvề cân CSFB
chỉnh theo
Tỉnh/Thành chiến
Tilt/Azimuth.
phố lượcbảng định
rà soát
+ Cảnh báo, năng lực và các thay + Rà soát Neighbors đảm bảo đủ, đúng., Update các thay đổi
số thông
- Kiểm
+ Thống tin:
trakê vùng
các phủ
cặp thông
Cell cóqua tỉ lệthống
Intra- Interworking:
- KiểmX2
tuyến tragiữa
PCI/RSIcác EnodeB
với các trạmnhằmlân
4G-->3G(2100)-->3G(900)--->2G đảm cận,
bảo đảm (chỉ
tỉ lệbảo khi không
cáckhông
cuộc có cặpcó
đổi thông tin các trạm 3G lân cận. thông tin phía các trạm 3G.
+kêCảnh
TA. báo các NodeB,Cell
Frequency-HOSR thành công 3G.thấp dịch trùng.vụNếu
Handover 3G)được
có thìưu cần tiên
thiết
trênkếgiao
và khai
diệnbáoX2 lại
là tối
để đa.
xử lý.
+ Kiểm tra tính đầy đủ và chính xác + Năng lực lớp mạng 3G đảm bảo cho các cuộc chuyển giao
-đểKiểm
tập trung
Thông tra
tinxem xửcólý. bị TAC/LAC
mapping trùng PCI/RSI - Xử lý nhiễu: Đối với các EnodeB hiện đang dùng dải tần số
Neighbors List. bằng cách nâng cấp, mở rộng NodeB.
với
4G/3G.
+ các trạm xung quanh không ?
Neighbors. 1800 chung với GSM-1800 vì vậy cần lưu ý nhiễu băng tần này
- Các công việc trên nhằm đảm bảo các cuộc Handover 4G-4G
Năng
(nếu
-+ X2 thấy lựckém
Handover. các cả
NodeB,cell 3G. do chống lấn vùng LTE-1800 và GSM-1800. (Tần số trung tâm).
và IRAT 4G-3G có tỉ lệ thành công cao từ đó giảm thiểu rớt
-+ Kiểm
Kiểmtra tracác
CSSR/DCR/HOSR) cấukhai
hìnhbáo cácPriority
Cell đặc CSFB
biệt
cuộc.
4G về
- Kiểm
các các
Cell tralớp
nằm mạng
nhiễu
Boder vàgiữa
xử lýcác nếu TAC,
có.
Border giữa các Vendor...
2G/3G(900/2100)
4. BỘ CẨM NANG XỬ LÝ BADCELL
4.1. Hệ Thống ERICSSON
4.1.1. BADCELL 2G_CSSR
Thể loại Chi tiết

Tên người xử lý case Nguyễn Anh Quang

Đơn vị RNOC3

Thời gian xử lý 28/8/2018

Chủng loại thiết bị Ericsson

Network 2G

Loại badcell Call setup success rate, nghẽn TCH

Mô tả thông tin lỗi Cell 2G_LTY042M11_QBH bị suy giảm CSSR, và nghẽn TCH.

Cảnh báo trạm/cell, Network Trạm không có cảnh báo phần cứng.

- Trạm sử dụng 2 luồng Abis (mục đích dự phòng)


Phân tích nguyên nhân lỗi - Kiểm tra chất lượng truyền dẫn thì nhận thấy 1 luồng Abis có chất lượng kém. Gây nên các kênh đang chạy trên
luồng kém này không thiết lập được cuộc gọi.

Phương án xử lý Các action thực hiện: Lock luồng bị chất lượng và yêu cầu xử lý.

Kết quả Sau khi xử lý xong KPI của Badcell đã tốt lại.
4.1.2. BADCELL 3G_CSSR
Thể loại Chi tiết
Tên người xử lý case Nguyễn Duy Khánh Đơn vị RNOC3 Thời gian xử lý 28/8/2018 Chủng loại thiết bị Ericsson Network 3G
Loại badcell CSSR
Mô tả thông tin lỗi Trạm overshoot gây nhiễu
Cảnh báo trạm/cell,
Trạm không có cảnh báo
Network
Phân tích logfile trạm thấy trạm overshoot qua 3 lớp trạm.

Phân tích nguyên nhân lỗi

Phương án xử lý Kiểm tra hiện trường, cho cụp tilt

Kết quả Sau khi xử lý xong KPI của Badcell đã tốt lại.
4.1.3. BADCELL 3G_PS_CSSR
Thể loại Chi tiết
Tên người xử lý case Hà Sơn Hải
Đơn vị RNOC2
Thời gian xử lý 03/08/2016
Chủng loại thiết bị ERICSSON
Network 3G
Loại badcell 3G_PS_CSSR kém
Chỉ số CSSR PS sector 3G_Q02097F4_HCM, phân tích các thành phần CSSR thì nhận thấy tỉ lệ thiết lập RAB
Mô tả thông tin lỗi
kém giảm còn 50%
Cảnh báo trạm/cell, Network Không có cảnh báo hardware
- Kiểm tra neighbour cell lỗi thấy khai báo đầy đủ.
- Thống kê các chỉ số KPI liên quan trên hệ thống nhận thấy tỉ lệ thiết lập RAB kém, UL sync kém.
- Cell kém từ khi DAS thay đổi thiết bị mới.
Phân tích nguyên nhân lỗi

Phương án xử lý Yêu cầu DAS điều chỉnh lại hệ thống MU-RU, theo dõi KPI và phản hồi.
KPI đã đạt yêu cầu

Kết quả
4.1.4. BADCELL 3G_PS_DCR
Case 1 Thể loại Chi tiết
Tên người xử lý case Hà Sơn Hải Đơn vị RNOC2 Thời gian xử lý 23/1/2019 -> 25/2/2019 Chủng loại thiết bị ERICSSON Network 3G

Loại badcell PS_DCR kém


Mô tả thông tin lỗi Thống kê thấy nhiều badcell 3G PS Drop call cao sau khi chuyển các RNC AGRNC12, CTRNC13 từ core Ericsson sang core NSN.
Cảnh báo trạm/cell,
Không có cảnh báo ở các badcell liên quan
Network
- Kiểm tra thống kê KPI liên quan
- Kiểm tra lại các tác động mạng lưới thời điểm lỗi
- Xác định nguyên nhân gây lỗi là đo tác động thay kết nối core từ RNC Ericsson.

Phân tích nguyên nhân lỗi

Phương án xử lý Phối hợp các đơn vị liên quan thay đổi tham số (RAN, core…), fall back
KPI cải thiện

Kết quả
4.1.5. BADCELL 3G_PS_DCR
Case 2 Thể loại Chi tiết
Tên người xử lý case Hà Sơn Hải Đơn vị RNOC2 Thời gian xử lý 15/5/2018 Chủng loại thiết bị ERICSSON Network 3G

Loại badcell Drop call CS & PS kém

Mô tả thông tin lỗi Chỉ số Dropcall CS PS của nhiều cell thuộc HCRNC18 kém bất thường, ảnh hưởng KPI mức RNC

Cảnh báo trạm/cell, Network Không có cảnh báo hardware


- Kiểm tra neighbour các cell lỗi thấy khai báo đầy đủ
- Kiểm tra log lỗi trên RNC thấy có một số lỗi liên quan đồng bộ vào các giờ khác nhau của các trạm khác nhau
- Phân tích vị trí của các cell này thấy cùng đi chung về một UPE truyền dẫn

Phân tích nguyên nhân lỗi

Phương án xử lý Yêu cầu VTT kiểm tra và xử lý truyền dẫn IP


KPI đã đạt yêu cầu

Kết quả
4.1.6. BADCELL 3G_CS_DCR
Case 1 Thể loại Chi tiết
Tên người xử lý case Hà Sơn Hải Đơn vị RNOC2 Thời gian xử lý 18/04/2018 Chủng loại thiết bị ERICSSON Network 3G
Loại badcell CS_DCR kém
Mô tả thông tin lỗi Chỉ số DCR CS sector 3G_Q05055M13_HCM kém
Cảnh báo trạm/cell,
Không có cảnh báo liên quan chất lượng
Network
- Thống kê KPI hệ thống, nhận thấy KPI DCR CS sector 3G_Q05055M13_HCM kém
- Kiểm tra các counter liên quan nhận thấy Drop call chủ yếu do Neighbor
- Kiểm tra các trạm mới phát sóng xung quanh

Phân tích nguyên nhân lỗi

Phương án xử lý Rà soát NB sector 3G_Q05055M13_HCM khai báo thêm với trạm mới phát sóng, xóa neighbor thừa, add thêm neighbor mới
KPI đã cải thiện

Kết quả
4.1.7. BADCELL 3G_CS/PS_HOSR
Thể loại Chi tiết
Tên người xử lý case Hà Sơn Hải Đơn vị RNOC2 Thời gian xử lý 05/06/2018 Chủng loại thiết bị ERICSSON Network 3G
Loại badcell Soft HO CS & PS kém
Mô tả thông tin lỗi Chỉ số Soft HO CS & PS sector 3G_HMO006M23_HCM kém
Cảnh báo trạm/cell,
Không có cảnh báo liên quan chất lượng
Network
- Thống kê KPI hệ thống, nhận thấy KPI Soft HO CS & PS sector 3G_HMO006M23_HCM kém

Phân tích nguyên nhân lỗi


- Kiểm tra nhận thấy số lượng attempt HO bị failed nhiều vào 1 cell 3G external, NB này do ANR tạo:

Phương án xử lý Kiểm tra thấy NB này ở xa, không cần thiết, do đó xóa NB kém này khỏi danh sách neighbor của cell
KPI đã cải thiện

Kết quả
4.1.8. BADCELL 4G_CSSR
Case 1 Thể loại Chi tiết
Tên người xử lý case Nguyễn Thanh Phương Đơn vị RNOC2 Thời gian xử lý 15/02/2019 - 26/02/2019 Chủng loại thiết bị Ericsson Network 4G
Loại badcell CSSR kém
Trạm 4G-Q07170M-HCM bị kém KPI Call Setup Success Rate cả 3 cell. KPI kém cả các giờ thấp điểm và cao điểm. Phân rã KPI thấy chỉ số eRAB Setup
Mô tả thông tin lỗi
Success Rate kém.
Cảnh báo trạm/cell,
Kiểm tra trên hệ thống trạm không có cảnh báo. Các chỉ số sóng đứng VSWR đều tốt. Truyền dẫn bình thường
Network
1. Từ KPI, thống kê xác định chỉ số Initial eRAB Setup Success Rate kém. Thống kê tỷ lệ [pmErabEstabSuccInit]/[pmErabEstabAttInit] thấp.
2. Thống kê các chỉ số SINR, CQI của các cell thấy giá trị thấp.
Phân tích nguyên nhân lỗi
3. Thống kê số lượng Handover attempt thì thấy các cell này Handover đều qua các cell xung quanh, không tập trung về 1 hướng cố định. Nghi ngờ các
anten đấu chéo sợi lẫn nhau
Phương án xử lý Yêu cầu onsite kiểm tra lại phần đấu nối feeder, jumper giữa các anten
Sau khi kiểm tra, xử lý xong chéo cell thì thống kê KPI trên hệ thống đã tốt trở lại

Kết quả
4.1.9. BADCELL 4G_CSSR
Case 2 Thể loại Chi tiết
Tên người xử lý case Lê Đình Dương Đơn vị RNOC3 Thời gian xử lý 12/01/2019 Chủng loại thiết bị Ericsson Network 4G
Loại badcell CSSR
Mô tả thông tin lỗi Tại tỉnh DNG, xác định 1 cell tồi 4G CSSR, KPI CSSR tồi và throughput cell 4G thấp tại các giờ trong ngày.
Cảnh báo trạm/cell, Network Trạm có cảnh báo phát sinh: VSWR RRU-1,RfPort = A
1. Rà soát Neighbor và tham số đầy đủ. Thực hiện lấy thống kê KPI Cell trên hệ thống:
2. Nhận thấy KPI của cell tồi CSSR và tốc độ throughput của cell thấp do nguyên nhân VSWR RRU-1,RfPort = A là lỗi sóng đứng tại RRU
sector 1.

Phân tích nguyên nhân lỗi

Các action thực hiện: Thực hiện đo kiểm tại trạm để xác định vị trí bị lỗi sóng đứng, sau khi xác định vị trí tại đầu Connector Anten, thực hiện
Phương án xử lý
làm lại đầu Connector.

Kết quả Sau khi xử lý xong cảnh báo KPI CSSR đã tốt trở lại.
4.1.10. BADCELL 4G_DCR
Case 1 Thể loại Chi tiết
Tên người xử lý case Nguyễn Thanh Phương Đơn vị RNOC2 Thời gian xử lý 26/02/2019 - 08/03/2019 Chủng loại thiết bị Ericsson Network 4G
Loại badcell Service Drop Rate
Trạm 4G-BTH138M-HCM, 2 cell 4G-BTH138M12-HCM và 4G-BTH138M13-HCM có KPI Service Drop Rate cao. KPI kém cả các giờ thấp điểm và
Mô tả thông tin lỗi
cao điểm. Phân rã KPI thấy chỉ số counter pmErabRelAbnormalEnbAct cao.
Cảnh báo trạm/cell, Network Kiểm tra trên hệ thống trạm không có cảnh báo. Các chỉ số sóng đứng VSWR đều tốt. Truyền dẫn bình thường
1. Từ KPI, thống kê xác định chỉ số pmErabRelAbnormalEnbAct cao.
Thống kê counter này cao có thể do vùng phủ kém, overshoot, hoặc bị chéo sector, lỗi HW, sóng đứng.
2. Thống kê các chỉ số SINR, CQI của các cell thấy giá trị thấp. KPI Intra HO kém đồng thời.
3. Kiểm tra logfile quét sóng thì thấy vùng phủ sector 2 & 3 chồng lấn lẫn nhau. Nghi ngờ chéo cell.
Phân tích nguyên nhân lỗi

Phương án xử lý Yêu cầu onsite kiểm tra lại phần đấu nối feeder, jumper giữa các anten
Sau khi kiểm tra, xử lý xong chéo cell thì thống kê KPI trên hệ thống đã tốt trở lại

Kết quả
4.1.11. BADCELL 4G_DCR
Case 2 Thể loại Chi tiết
Tên người xử lý case Nguyễn Thanh Phương Đơn vị RNOC2 Thời gian xử lý 12/02/2019 - 18/02/2019 Chủng loại thiết bị Ericsson Network 4G
Loại badcell Service Drop Rate
Mô tả thông tin lỗi Cell 4G-NKI051M13-CTO có KPI Service Drop Rate cao. KPI kém cả các giờ thấp điểm và cao điểm.
Kiểm tra trên hệ thống trạm không có cảnh báo. Tuy nhiên chỉ số nhiễu UL RSSI cao

Cảnh báo trạm/cell, Network

1. Chỉ số nhiễu UL RSSI cao sẽ làm ảnh hưởng đến việc trao đổi bản tin giữa UE và EnodeB, dẫn đến việc làm tăng khả năng drop call khi sử dụng
dịch vụ.
2. Nhiễu cao cũng làm ảnh hưởng đến tốc độ truy cập của khách hàng:

Phân tích nguyên nhân lỗi

Phương án xử lý Yêu cầu onsite kiểm tra lại phần đấu nối feeder, jumper, các đầu connector. Kiểm tra lại vùng phủ các trạm xung quanh.
Sau khi kiểm tra, xử lý xong các phần đấu nối dưới trạm, KPI đã tốt trở lại

Kết quả
4.1.12. BADCELL 4G_Intra-frequency_HO
Case 1 Thể loại Chi tiết
Tên người xử lý case Nguyễn Thanh Phương Đơn vị RNOC2 Thời gian xử lý Chủng loại thiết bị Ericsson Network 4G

Loại badcell Intra-frequency HO

Mô tả thông tin lỗi Cell 4G-LVO030M13-DTP có KPI Intra-frequency HO thấp, thống kê trung bình ngày chỉ đạt 92%

Cảnh báo trạm/cell, Network Kiểm tra trên hệ thống trạm không có cảnh báo. Các chỉ số sóng đứng VSWR đều tốt. Truyền dẫn bình thường
Từ KPI, thống kê tỷ lệ HO thành công trên từng cặp neighbour thì thấy số lượng HO failed chủ yếu sang neighbour 4G-LXU066M11-AGG, có
PCI=54 và tỷ lệ HO Success Rate cặp relation này là 0%.
Nghi ngờ bị trùng PCI trong neighbour list, kiểm tra thiết kế PCI trên map thì phát hiện trong neighbour list có 2 cell có cùng PCI=54 là 4G-
LXU066M11-AGG và 4G-CMO013M12-AGG. Dẫn đến hiện tượng PCI confusion, gây HO kém.

Phân tích nguyên nhân lỗi

Khoảng cách từ 4G-LVO030M13-DTP đến neighbour 4G-LXU066M11-AGG gần 12km, kiểm tra tilt, hướng các cell không có gì bất thường. Thực
Phương án xử lý
hiện xóa relation này để xử lý trùng PCI
Sau khi kiểm tra, xử lý xong chéo cell thì thống kê KPI trên hệ thống đã tốt trở lại

Kết quả
4.1.13. BADCELL 4G_Intra-frequency_HO
Case 2 Thể loại Chi tiết
Tên người xử lý case Lê Đình Dương Đơn vị RNOC3 Thời gian xử lý 2/11/2018 Chủng loại thiết bị Ericsson Network 4G
Loại badcell Intra HOSR
Mô tả thông tin lỗi Tại tỉnh DNG, xác định 1 cell tồi 4G HOSR intra, KPI thấp toàn bộ các giờ cả cao điểm và thấp điểm, giá trị Intra HOSR thấp dưới 70%.

Cảnh báo trạm/cell, Network Trạm không có cảnh báo phát sinh
1. Rà soát Neighbor và tham số đầy đủ. Thực hiện lấy thống kê KPI Cell to Cell trên hệ thống:

2. Nhận thấy KPI của cell tồi nhiều nhất đến Cell 4G-NHS027M11-DNG, kiểm tra khoảng cách giữa 2 trạm > 7 km trong khu vực thành phố với mật độ
trạm cao. Kiểm tra khai bao hệ thống Cell NHS027M11-DNG có PCI trùng với Neigbor của cell NHS036M12-DNG và bị Overshoot nên gây hiện tượng
Phân tích nguyên nhân lỗi
tồi KPI HO Intra.

Phương án xử lý Các action thực hiện: Thực hiện plan lại PCI và hiệu chỉnh vùng phủ cho cell 4G khu vực
Kết quả Sau khi xử lý xong cảnh báo KPI HOSR Inta đã tốt trở lại.
4.1.14. BADCELL 4G_IRAT_HOSR
Thể loại Chi tiết
Tên người xử lý case Nguyễn Thanh Phương Đơn vị RNOC2 Thời gian xử lý 09/01/2019 - 28/02/2019 Chủng loại thiết bị Ericsson Network 4G
Loại badcell Intra Freq HO, IRAT HO
Mô tả thông tin lỗi Cell 4G-Q08037M12-HCM có 2 chỉ số KPI kém là Intra-Frequency HO, IRAT HOSR.
Kiểm tra trên hệ thống cell này có cảnh báo RET

Cảnh báo trạm/cell,


Network

1. Cảnh báo RET thể hiện tilt điện của cell này hệ thống không giám sát được, có thể tilt điện thực tế sai khác với thiết kế, dẫn đến vùng phủ có thể
không hợp lý làm ảnh hưởng đến KPI của cell.
2. Thống kê thêm lưu lượng của cell để đánh giá nhận định về vùng phủ
Lưu lượng của cell tăng đột biến từ ngày 8/1, trùng với thời điểm phát sinh cảnh báo RET

Phân tích nguyên nhân lỗi

Phương án xử lý Yêu cầu onsite kiểm tra lại anten, xử lý cảnh báo RET
Sau khi kiểm tra, xử lý xong cảnh báo RET và cho calib lại anten thì KPI đã cải thiện, lưu lượng trở lại mức bình thường

Kết quả
4.2. Hệ Thống NOKIA
4.2.1. BADCELL 2G_CSSR

Case 1 Thể loại Chi tiết

Tên người xử lý case Trần Xuân Trường Đơn vị RNOC1 Thời gian xử lý 6/3/2019 Chủng loại thiết bị NSN Network 2G/3G

Loại badcell CS/PS: CSSR/HOSR/DCR

- Suy giảm KPI CSSR/HOSR/DCR.


Mô tả thông tin lỗi
- Khách hàng phản ánh khó thiết lập cuộc gọi, tỉ lệ cuộc gọi Drop cao.

- BSC/RNC không có cảnh báo.


Cảnh báo trạm/cell, Network
- BTS/NodeB không có cảnh báo HW, Chất lượng truyền dẫn tốt.

- Không xuất hiện cảnh báo từ BTS/NodeB. Thực hiện Reset BTS/NodeB chất lượng vẫn không cải thiện.
- Yêu cầu đo kiểm hiện trường để phân tích.
Phân tích nguyên nhân lỗi
- Qua phân tích Logfile nhận thấy BTS/NodeB đang bị đấu chéo cell( Nghĩa là phần đấu nối vật lý tại trạm không đúng như thiết kế) gây ra
hiện tượng nhiễu( Do trùng tần), Thiếu Neighbors gây ra hiện tượng suy giảm chất lượng.

- Thực hiện Site Audit.


Phương án xử lý - Thiết kế lại RF theo số liệu Site Audit.
- Khai báo lại CSDL , đấu nối lại vật lý tại BTS/NodeB theo thiết kế RF.

Kết quả - Sau khi thực hiện các chỉ số KPI đã tốt trở lại.
4.2.2. BADCELL 3G_CSSR
Case 1 Thể loại Chi tiết
Tên người xử lý case TRẦN CÔNG LƯƠNG Đơn vị RNOC2 Thời gian xử lý 5/12/2018 Chủng loại thiết bị NSN Network 3G
Loại badcell CSSR
Tại tỉnh Lâm Đồng tại khu vực trạm 3G_DLA025M_LDG, Xác định bị nhiễu UL gây CS, PS CSSR kém sector 2
Mô tả thông tin lỗi - Version RNC NSN
- Loại tủ NSN
Kiểm tra toàn bộ các cảnh báo của các badcell, tồn tại các cảnh báo 1 trạm 3G_DLA025M_LDG:
Cảnh báo trạm/cell, Network
- Không có cảnh báo hardware.

Phân tích nguyên nhân lỗi Từ KPI thống kê cell Bị nhiễu Uplink cao.
Thực hiện xử lý trạm theo 2 bước:
- Kiểm tra tần số 2G.
Phương án xử lý
- Hardware, kiểm tra jumper.
- Thống báo cục tần số kiểm tra. Sau khi cục tần số kiểm tra phát hiện nhiễu ngoài do cục phát tại wifi tại nhà dân bị lỗi.

Kết quả
4.2.3. BADCELL 3G_CSSR
Case 2 Thể loại Chi tiết
Tên người xử lý case Triệu Cường Đơn vị RNOC2 Thời gian xử lý 01/03/2019 Chủng loại thiết bị NSN Network 3G
Loại badcell CS-CSSR kém

Mô tả thông tin lỗi 3G_KSA019M_STG


Cảnh báo trạm/cell, Network Cell không có cảnh báo ngoài
Phân tích KPI thấy nguyên nhân kém CS CSSR là do Radio fail cao
Phân tích nguyên nhân lỗi
Thống kê RTWP thấy mức thu tăng cùng thời điểm CS CSSR giảm
- kiểm tra đấu nối connector, jumper
Phương án xử lý
- Nếu không hết tiến hành thay thiết bị jumper, connector, anten hoặc khối RF
Sau khi thay thế thiết bị DTRU mới thì trạm không còn bị pathbalance, CSSR tốt trở lại

Kết quả
4.2.4. BADCELL 3G_CSSR
Case 3 Thể loại Chi tiết
Tên người xử lý case TRẦN CÔNG LƯƠNG Đơn vị RNOC2 Thời gian xử lý 20/02/2019 Chủng loại thiết bị NSN Network 3G
Loại badcell CSSR
Tại tỉnh Kiên Giang tại khu vực trạm 3G_PQU030M_KGG, xác định khu vực 9 cell của trạm có chỉ số CSSR-CS kém gây khó gọi.
Mô tả thông tin lỗi - Version RNC-70 NSN
- Loại tủ SRAN
Kiểm tra toàn bộ các cảnh báo của các badcell, tồn tại các cảnh báo 1 trạm 3G_PQU030M_KGG:
Cảnh báo trạm/cell, Network
- Không có cảnh báo hardware.
Phân tích nguyên nhân lỗi Từ KPI thống kê cell có tỉ lệ DCH discarded frames, High Delay;DCH discarded frames, other error rất cao. Nghi ngờ do truyển dẫn.
Thực hiện xử lý trạm theo 2 bước:
Phương án xử lý
- Yêu cầu kiểm tra truyền dẫn. Xử lý nghẽn truyền dẫn.

Kết quả
4.2.5. BADCELL 3G_CSSR
Case 4 Thể loại Chi tiết
Tên người xử lý case Trần Xuân Trường

Đơn vị RNOC1

Thời gian xử lý 6/3/2019


Chủng loại thiết bị NSN
Network 3G
Loại badcell CSSR
- Thống kê bình thường, trạm không có cảnh báo.
Mô tả thông tin lỗi
- Phản ánh khách hàng khó thiết lập cuộc gọi, hay bị lặng tiếng, sôi rè.
- RNC không có cảnh báo.
Cảnh báo trạm/cell, Network
- NodeB không có cảnh báo HW, Chất lượng truyền dẫn tốt.
- Khóa từng Cell thuộc NodeB để thử dịch vụ kết quả cho thấy chỉ 1/3 Cell khó thiết lập cuộc gọi và xảy ra hiện
tượng sôi rè.
Phân tích nguyên nhân lỗi
- Đo kiểm hiện trường lấy Log để phân tích chi tiết nhận thấy bị trùng ScrambingCode với Cell nằm trong
Neighbors List.

Phương án xử lý -Thiết kế và khai báo lại ScarmblingCode cho Cell lỗi

Kết quả Sau khi thiết kế và khai báo Scramblingcode mới chất lượng dịch vụ đã tốt trở lại.
4.2.6. BADCELL 3G_CSSR
Case 5 Thể loại Chi tiết
Tên người xử lý case Phạm Hường Ánh Đơn vị RNOC3 Thời gian xử lý 25/11/2018 Chủng loại thiết bị NSN Network 3G
Loại badcell CSSR
Mô tả thông tin lỗi Tại tỉnh DLK, xác định 1 cell CSSR kém 3G_BHO025M12_DLK
Cảnh báo trạm/cell, Network Trạm không có cảnh báo phần cứng.
1. Kiểm tra trạm không có cảnh báo, truyền dẫn bình thường, phối hợp hiện trường đo kiểm thấy vùng phủ bị overshoot. Thực hiện điều chỉnh vùng
phủ hợp lý

Phân tích nguyên nhân lỗi

Phương án xử lý Các action thực hiện: Thực hiện điều chỉnh tilt cell 3G_BHO025M12_DLK từ 3->5
Kết quả Sau khi xử lý xong KPI CSSR đã tốt lên
4.2.7. BADCELL 3G_HOSR
Thể loại Chi tiết
Tên người xử lý case TRẦN CÔNG LƯƠNG Đơn vị RNOC2 Thời gian xử lý 2/2/2019 Chủng loại thiết bị NSN Network 3G
Loại badcell HOSR kém.
Tại tỉnh Hậu Giang tại khu vực trạm 3G_VTH033M_HUG đo kiểm chất lượng sóng kém (Ec/Io).
Mô tả thông tin lỗi - Version RNC NSN
- Loại tủ NSN

Kiểm tra toàn bộ các cảnh báo của các badcell:


Cảnh báo trạm/cell, Network
- Không có cảnh báo hardware.
Sau khi kiểm tra NB và thống kê. Thấy HOSR kém Sector 2 và sector 3.

Phân tích nguyên nhân lỗi

Thực hiện xử lý trạm theo 2 bước:


Phương án xử lý - Thực hiện đo kiểm. Xác định swap feeder.
- Tiến hành phối hợp điều chỉnh lại Feeader.
Kết quả Sau khi điều chỉnh, chất lượng trạm hiện tốt.
4.2.8. BADCELL 3G_CS_DCR
Case 1 Thể loại Chi tiết
Tên người xử lý case Triệu Cường Đơn vị RNOC2 Thời gian xử lý 01/03/2019 Chủng loại thiết bị NSN Network 3G

Loại badcell CS Drop cao

Mô tả thông tin lỗi 3G_DDO055M_CMU


Cảnh báo trạm/cell, Network Cell không có cảnh báo ngoài

Phân tích nguyên nhân lỗi Phân tích KPI thấy nguyên nhân kém CS DRC là do Radio fail cao
- Kiểm tra đấu nối connector, jumper
Phương án xử lý
- Reset khối RF module
Sau khi xử lý thì CS DRC giảm

Kết quả
4.2.9. BADCELL 3G_CS_DCR

Case 2 Thể loại Chi tiết

Tên người xử lý case Nguyễn Trọng Thắng

Đơn vị RNOC1

Thời gian xử lý 6/3/2019

Chủng loại thiết bị NSN

Network 3G

Loại badcell DCR cao bất thường

Mô tả thông tin lỗi -Chỉ số PS_DROP RNC tăng cao bất thường

NodeB của Badcell đang tồn tại các cảnh báo sau:
Cảnh báo trạm/cell, Network
-Rất nhiều cảnh báo Error của NodeB trên cùng 1 USPU
1. Rất nhiều cell thuộc RNC cảnh báo Error không rõ nguyên nhân.
Phân tích nguyên nhân lỗi
2. Các Cell có cảnh báo đều có chỉ sô PS_Drop tăng cao bất thường

Các action thực hiện:


Phương án xử lý
- Thực hiện Reset USPU chứa các Cell có cảnh báo Error.

Kết quả Sau khi Restart theo dõi thống kê chỉ số PS_Drop đã trở lại bình thường.
4.2.10. BADCELL 3G_CS_IRAT
Thể loại Chi tiết
Tên người xử lý case Trần Xuân Trường
Đơn vị RNOC1
Thời gian xử lý 6/3/2019
Chủng loại thiết bị NSN
Network 3G
Loại badcell CS_IRAT
- Thống kê RNC chỉ số CS_IRAT suy giảm nghiêm trọng.
Mô tả thông tin lỗi
- CS_Drop tăng do HO kém.

Cảnh báo trạm/cell, - RNC không có cảnh báo.


Network - NodeB không có cảnh báo HW, Chất lượng truyền dẫn tốt.

- CS_IRAT là chỉ số KPI đánh giá mức độ chuyển giao từ 3G-2G.


- Thống kê CS_HO 3G tốt vì vậy có thể xác nhận phân 3G không có lỗi bất thường.
- Tập trung kiểm tra các Actions thay đổi phía 2G để xác định nguyên nhân bằng các Audit lại các tham số của
Phân tích nguyên nhân lỗi
External 2G Neighbors như: LAC/CI/BSIC/BCCH(NCC/BCC).
- Sau khi kiểm tra nhận thấy rất nhiều External 2G neighbor cell được khai báo trên hệ thống 3G sai khác về thông số
với cấu hình đang chạy do việc đấu chuyển BTS trên BSC 2G.

Phương án xử lý - Cập nhật lại thông số External 2g Neighbors Cell trên hệ thống 3G

Kết quả - Sau khi cập nhật, theo dõi KPI hệ thống đã tốt trở lại.
4.2.11. BADCELL 4G_CSSR
Thể loại Chi tiết
Tên người xử lý case Phạm Hường Ánh Đơn vị RNOC3 Thời gian xử lý 27/12/2018 Chủng loại thiết bị NSN Network 4G
Loại badcell CSSR
Mô tả thông tin lỗi Tại tỉnh DLK, xác định 1 cell tồi 4G-BMT010M11-DLK CSSR kém

Cảnh báo trạm/cell, Network Trạm không có cảnh báo phát sinh
1. Rà soát tham số khai báo đúng
2. Phối hợp hiện trường đo kiểm phát hiện vùng phủ cell đang chồng lấn lên khu vực có 2 cell đang phủ đến là 4G-BMT009M11-DLK và 4G-
BMT008M11-DLK

Phân tích nguyên nhân lỗi

Phương án xử lý Các action thực hiện: Điều chỉnh azimuth từ 350->10 để tránh overlap và up tilt 1 độ cải thiện vùng phủ sóng.
Kết quả Sau khi xử lý xong cảnh báo KPI CSSR đã tốt trở lại.
4.2.12. BADCELL 4G_IntraFreq_HOSR
Case 1 Thể loại Chi tiết
Tên người xử lý case Triệu Cường Đơn vị RNOC2 Thời gian xử lý W4/2018 Chủng loại thiết bị NSN Network 4G
Loại badcell Intra Freq HOSR
Mô tả thông tin lỗi 4G-CMA042M11-CMU, 4G-CMA042M12-CMU
Cảnh báo trạm/cell, Network Cell không có cảnh báo ngoài
Kiểm tra đồng cảnh báo ngoài: không có
Phân tích nguyên nhân lỗi Kiểm tra thiết kế PCI, RSI: bình thường
Kiểm tra thống kê cell2Cell HO: phát hiện HO attemp không phù hợp với hướng thiết kế
- Kiểm tra đấu nối connector, jumper
Phương án xử lý - Hướng lắp đặt của cell: phát hiện cell 1 và 2 của trạm bị chéo jumper với nhau
- Xử lý lắp đặt lại jumper
Kết quả sau khi xử lý chéo jumper của 2 cell thì HO đã tốt trở lại

Kết quả
4.2.13. BADCELL 4G_IntraFreq_HOSR
Case 2 Thể loại Chi tiết
Tên người xử lý case TRẦN CÔNG MINH Đơn vị RNOC2 Thời gian xử lý 20/02/2019 Chủng loại thiết bị NSN Network 4G
Loại badcell Intra-Freq-HOSR ≤ 95%
Mô tả thông tin lỗi Tại DNI có cell 4G-TBO036M12-DNI chỉ số intra-freq-HOSR kém bất thường 85.71%. Không đạt theo tiêu chí badcell 4G
Kiểm tra toàn bộ các cảnh báo của các badcell, tồn tại các cảnh báo 1 trạm 4G-TBO036M-DNI:
Cảnh báo trạm/cell, Network
- Không có cảnh báo hardware.
- Thống kê các cặp Cell-2-cell bị intra HO fail của cell 4G-TBO036M12-DNI thấy chỉ có vài cặp Cell bị fial 100%, 1 số cặp cell fail <90%, các
cặp cell còn lại đều tốt >99%.
Phân tích nguyên nhân lỗi
‘- Tiến hành kiểm tra các cặp cell kém đều nằm gần, các cặp cell tốt có khoảng cách rất xa >4km.--> nghi ngờ cell bị overshoot. kiểm tra
tilt/hướng, độ cao anten: cao 31m, total titl =2.
Phương án xử lý Thực hiện down tilt xử lý overshoot.

Kết quả
4.2.14. BADCELL 4G_IntraFreq_HOSR
Case 3 Thể loại Chi tiết
Tên người xử lý case TRẦN CÔNG MINH
Đơn vị RNOC2
Thời gian xử lý 22/02/2019
Chủng loại thiết bị NSN
Network 4G
Loại badcell Intra-Freq-HOSR ≤ 95%
Mô tả thông tin lỗi 4G-LGI501S11-BTN: là trạm small cell mới phát sóng, có chỉ số intra Ho kém sang VTU, khoản cách rất xa
Kiểm tra toàn bộ các cảnh báo của các badcell, tồn tại các cảnh báo 1 trạm :
Cảnh báo trạm/cell, Network
- Không có cảnh báo hardware.
Thống kê KPI intra cặp Cell2cell giữa 4G-LGI501S11-BTN
Với NB xung quanh đều rất tốt, chỉ có cặp NB 4G-LGI501S11-BTN
Phân tích nguyên nhân lỗi
4G-LGI501S11-BTN - 4G-XMO003M11-VTU bị fail gần như toàn bộ lượng attamp >100 mẫu, gây ảnh hưởng mức cell <95%. Khoảng cách 2
cell này >20Km và tự học NB, dẫn đến trường hợp overshoot, KPI kém.
Thực hiện đổi giá trị tham số handoverAllowed của cell 4G-LGI501S11-BTN với NB 4G-XMO003M11-VTU từ giá trị Allowed --> forbidden.
Phương án xử lý
Không cho intra HO giữa 2 cặp NB này.

Kết quả
4.2.15. BADCELL 4G_InterFreq_HOSR
Case 1 Thể loại Chi tiết
Tên người xử lý case TRẦN CÔNG MINH

Đơn vị RNOC2

Thời gian xử lý 22/02/2019

Chủng loại thiết bị NSN


Network 4G
Loại badcell inter-IF HO kém

Mô tả thông tin lỗi Badcell vi phạm KPI E-UTRAN Inter-Freq HO SR kém cell 4G-HTB017M11-BTN <70%

Kiểm tra toàn bộ các cảnh báo của các badcell, tồn tại các cảnh báo 1 trạm :
Cảnh báo trạm/cell, Network
- Không có cảnh báo hardware.

- Thống kê KPI E-UTRAN Inter-Freq HO cell 4G-HTB017M11-BTN rất kém, cell này LTE20M, border gần các trạm LTE15M, khoản cách các trạm
Phân tích nguyên nhân lỗi >3km, sóng kém dẫn đến inter IF HO giữa các cell LTE20M.-LTE15M kém.
- Kiểm tra lắp đặt: bình thường.

Thực hiện điều chỉnh ngưỡng giá trị threshold2InterFreq, và threshold2a từ giá trị -105, -102 về -100 và -90 hạn chế inter IF HO giữa các cặp cell
Phương án xử lý
xa, sóng kém.

Kết quả
4.2.16. BADCELL 4G_InterFreq_HOSR
Case 2 Thể loại Chi tiết
Tên người xử lý case Trần Công Lương Đơn vị RNOC2 Thời gian xử lý 21/02/2019 Chủng loại thiết bị NSN Network 4G
Loại badcell Inter-Freq HO
Mô tả thông tin lỗi Cell 4G-BLA021M13-LDG có chỉ số Inter-Freq HO thấp, KPI thấp toàn bộ các giờ cả cao điểm và thấp điểm
Cảnh báo trạm/cell, Network - Version LTE NSN

Các nguyên nhân có thể gây ra lỗi Inter-Freq HOSR kém:


- Lỗi Hardware
- Overshoot
Phân tích nguyên nhân lỗi
- Lỗi mất đồng bộ
- Thống kê Timing Advance : UE ở khoảng cách xa (12-18 km)
- Thống kê HO cell to Cell: 4G-BLA021M13-LDG (15MHz)sang trạm 4G-DLI052M13-LDG (20MHz) (Khoảng cách 2 trạm 16km)
Để cải thiện Inter-Freq HOSR:
Phương án xử lý - Kiểm tra tất cả các lỗi HW
- Thực hiện chỉnh e-tilt từ 3 độ à 6 độ

Kết quả
4.3. HỆ THỐNG 2G MOTOROLA
4.3.1. BADCELL 2G_CSSR
Case 1 Thể loại Chi tiết
Tên người xử lý case NGUYỄN VIỆT NGHĨA
Đơn vị RNOC2
Thời gian xử lý
Chủng loại thiết bị Motorola
Network 2G
Loại badcell CSSR, DCR
Mô tả thông tin lỗi Trạm bị CSSR kém, DCR cao
Kiểm tra trạm có cảnh báo DRI

Cảnh báo trạm/cell, Network

Trạm có cảnh báo DRI.


Phân tích nguyên nhân lỗi
Kết hợp quét sóng onsite hiện trường thấy mức thu gần trạm kém bất thường.
Phương án xử lý Thay DRI bị lỗi

Kết quả KPI CSSR, DCR cải thiện


4.3.2. BADCELL 2G_CSSR

Case 2 Thể loại Chi tiết

Tên người xử lý case Nguyễn Hải Linh

Đơn vị RNOC1

Thời gian xử lý 2018

Chủng loại thiết bị Motorola

Network 2G

Loại badcell 2G_DCR, 2G_CSSR

- Xuất hiện badcell về DCR, CSSR cell 2G_VLC016M13_THA


Mô tả thông tin lỗi
- Có phản ánh khách hang về dịch vụ 2G: khó gọi, rớt cuộc cao

Cảnh báo trạm/cell, Network Trạm có cảnh báo lỗi ma trận thu tại DRI 2 0

Phân tích nguyên nhân lỗi Thay thế SURF của cell 3 trạm

Phương án xử lý Thay thế SURF của cell 3 trạm

Kết quả Chỉ số CSSR, DCR sau xử lý đã tốt trở lại, dịch vụ tốt, khách hàng không còn phản ánh.
4.3.3. BADCELL 2G_CSSR
Case 3 Thể loại Chi tiết
Tên người xử lý case Lê Đình Dương
Đơn vị RNOC3
Thời gian xử lý 3/6/2018
Chủng loại thiết bị Motorolla
Network 2G
Loại badcell Drop call, Call setup success rate.
Mô tả thông tin lỗi Tại tỉnh QNM, xác định 02 cell 2G_NTM004M12 _QNM và 2G_NTM001M13 có chỉ số CSSR, CDR kém.
Cảnh báo trạm/cell, Network Trạm không có cảnh báo phần cứng.
Kiểm tra trên map 2 cell tồi này có chung vùng phủ sóng, tiến hành đo kiểm hiện trường thu được logfile Drop call
và Blocked call tại vùng phủ 2 cell này rất lớn đồng thời logfile thể hiện Rxquality rất tồi. Nguyên nhân 2 cell này
nhiễu đồng kênh BCCH.

Phân tích nguyên nhân lỗi

Phương án xử lý Các action thực hiện: Plan lại tần số cho khu vực.
Kết quả Sau khi xử lý xong KPI của Badcell đã tốt lại. Đo kiểm không còn bị Dropcall và Blocked call.
4.3.4. BADCELL 2G_DCR
Case 1 Thể loại Chi tiết

Tên người xử lý case Nguyễn Hải Linh Đơn vị RNOC1 Thời gian xử lý 13/3/2019 Chủng loại thiết bị Motorola Network 2G
Loại badcell 2G_DCR
- Xuất hiện badcell về DCR, CSSR tại trạm NQN030M_NBH
Mô tả thông tin lỗi
- Có phản ánh khách hang về dịch vụ 2G: khó gọi, rớt cuộc cao
Cảnh báo trạm/cell, Network Trạm hoạt động bình thường, không có cảnh báo ngoài, truyền dẫn cũng nhu cảnh bảo Hardware.
Lấy thống kê hệ thống chỉ số Pathbalance cell 2 thấy chỉ số cao vượt ngưỡng chất lượng trong khoàng từ 100-120.

Quá trình xử lý

Phương án xử lý Kiểm tra lại phần cứng cell 2 trạm: SURF, DUPLEXER, CTU…Thực hiện cân chỉnh và thay thế khi cần thiết.
Kết quả Chỉ số CSSR, DCR sau xử lý đã tốt trở lại, dịch vụ tốt, khách hàng không còn phản ánh.
4.3.5. BADCELL 2G_DCR

Case 2 Thể loại Chi tiết

Tên người xử lý case Nguyễn Trần Minh Luân

Đơn vị RNOC3

Thời gian xử lý 10/05/2018

Chủng loại thiết bị Motorola

Network 2G

Loại badcell Drop call.

Mô tả thông tin lỗi Tại tỉnh DLK, Cell 2G_EKR033M12_DLK HOSR kém

Cảnh báo trạm/cell, Network Trạm không có cảnh báo phần cứng.

1. Rà soát tham số và Neighbor trên hệ thống hoàn toàn bình thường.


Phân tích nguyên nhân lỗi 2. Rà soát thống kê Handover cell to cell thấy handover kém với cell 2G_EKR022M11_DLK.
3. Kiểm tra thống kê KPI cell 2G_EKR022M11_DLK bình thường.

Phương án xử lý Thực hiện điều chỉnh ngưỡng HO cho phép thực hiện Handover sớm khi mức thu còn tốt.

Kết quả Sau khi xử lý xong KPI của Badcell tốt.


4.3.6. BADCELL 2G_HOSR

Case 1 Thể loại Chi tiết

Tên người xử lý case NGUYỄN VIỆT NGHĨA

Đơn vị RNOC2

Thời gian xử lý

Chủng loại thiết bị Motorola

Network 2G

Loại badcell HOSR

Mô tả thông tin lỗi Trạm có KPI HOSR kém

Cảnh báo trạm/cell, Network Kiểm tra trạm không tồn tại cảnh báo

- Thực hiện đo kiểm logfile theo hướng sector có KPI kém.


Phân tích nguyên nhân lỗi
- Lấy thống kê cell to cell Handover thấy cell handover nhiều với các cell ở vùng xa.

Phân tích logfile xác định là trạm overshoot.


Phương án xử lý Yêu cầu hiện trường thực hiện lấy lại tilt/hướng cell bị KPI kém => ra phương án tunning, downtilt để đảm bảo
vùng phủ cell không còn overshoot

Kết quả KPI HOSR cải thiện, quét sóng lại quanh khu vực cell không còn hiện tượng overshoot
4.3.7. BADCELL 2G_HOSR
Case 2 Thể loại Chi tiết

Tên người xử lý case Nguyễn Hải Linh

Đơn vị RNOC1

Thời gian xử lý 25/1/2019

Chủng loại thiết bị Motorola

Network 2G

Loại badcell 2G_HOSR

Xuất hiện nhiều badcell về HOSR ở cùng 1 khu vực thuộc tỉnh Hòa Bình: TPO008M_HBH, TPO012M_HBH,
Mô tả thông tin lỗi
TPO024M_HBH, TPO028M_HBH

Cảnh báo trạm/cell, Network Trạm hoạt động bình thường, không có cảnh báo ngoài, truyền dẫn cũng nhu cảnh bảo Hardware.

- Lấy thống kê hệ thống chỉ số IN_INTRA_BSS_NC_ATMPT, IN_INTRA_BSS_NC_SUC,


OUT_HO_NC_CAUSE_ATMPT,OUT_HO_NC_SUC
Phân tích nguyên nhân lỗi
thấy các cell khi handover sang trạm TPO009M_HBH đều fail nhiều
- Kiểm tra cảnh báo trạm TPO009M_HBH: trạm không cảnh báo, KPI hệ thống bình thường.

Phương án xử lý Nghi ngờ khả năng trạm lỗi card H2SC khiến các cell xung quanh không handover sang được: thay thế card H2SC
Kết quả Chỉ số HOSR sau xử lý đã tốt trở lại
4.3.8. BADCELL 2G_HOSR
Case 3 Thể loại Chi tiết
Tên người xử lý case Nguyễn Trần Minh Luân
Đơn vị RNOC3
Thời gian xử lý 15/06/2018
Chủng loại thiết bị Motorola
Network 2G
Loại badcell HOSR
Mô tả thông tin lỗi Tại tỉnh DLK cell 2G_EKR023M11_DLK HOSR kém.
Cảnh báo trạm/cell, Network Trạm không có cảnh báo phần cứng
1. Rà soát tham số và Neighbor trên hệ thống hoàn toàn bình thường.
2. Rà soát thống kê Handover cell to cell thấy handover kém với nhiều cell lân cận.
3. Đề nghị NET3 đo kiểm vùng phủ khu vực này phát hiện vùng phủ có quá nhiều cell phủ gây nhiễu:

Phân tích nguyên nhân lỗi

Phương án xử lý Các action thực hiện: Thực hiện quy hoạch lại tần số các cell phủ vào KV nhiễu
Kết quả Sau khi xử lý xong cảnh báo KPI HOSR đã tốt.
4.3.9. BADCELL 2G_HOSR

Case 4 Thể loại Chi tiết

Tên người xử lý case Nguyễn Trần Minh Luân

Đơn vị RNOC3

Thời gian xử lý 20/08/2018

Chủng loại thiết bị Motorola

Network 2G

Loại badcell HOSR

Mô tả thông tin lỗi Tại tỉnh PYN, cell 2G_TAN005M13_PYN HOSR kém.

Cảnh báo trạm/cell, Network Trạm không có cảnh báo phát sinh

- Rà soát tham số và Neighbor trên hệ thống hoàn toàn bình thường.


Phân tích nguyên nhân lỗi
- Kiểm tra thống kê nhiễu tần số TCH 42, nghi ngờ viettel sử dụng tần số BCCH 43 cận kênh gây nhiễu.

Phương án xử lý Thực hiện đổi tần số TCH 42 sang TCH 40

Kết quả Sau khi xử lý xong cảnh báo KPI HOSR đã tốt trở lại.
4.3.10. BADCELL 2G_HOSR
Case 5 Thể loại Chi tiết
Tên người xử lý case Nguyễn Trần Minh Luân

Đơn vị RNOC3
Thời gian xử lý 10/03/2019

Chủng loại thiết bị Motorola

Network 2G
Loại badcell HOSR

Mô tả thông tin lỗi Tại tỉnh GLI, cell 2G_PLU009M13_GLI HOSR kém.

Cảnh báo trạm/cell, Network Trạm không có cảnh báo phát sinh.
1. Rà soát tham số và Neighbor trên hệ thống hoàn toàn bình thường.
2. Kiểm tra thống kê HO Cell to cell phát hiện Handover kém với cell 2G_PLU032M22_GLI.
3. Đề nghị VNPT GLI đo kiểm, NET3 phân tích logfile phát hiện cell 2G_PLU032M22_GLI bị nhiễu đồng kênh TCH
610.
Phân tích nguyên nhân lỗi

Phương án xử lý NOC3 thực hiện quy hoạch lại tần số.


Kết quả Sau khi xử lý xong cảnh báo KPI HOSR đã cải thiện.
4.4. HỆ THỐNG ALCATEL
4.4.1. BADCELL 2G_CSSR
Case 1 Thể loại Chi tiết

Tên người xử lý case Trần Xuân Trường

Đơn vị RNOC1

Thời gian xử lý 11/3/2019

Chủng loại thiết bị Alcatel

Network 2G

Loại badcell 2G_CSSR

Xuất hiện Badcell CSSR rất kém tại Cao Bằng. Callvolume gần như bằng không.
Mô tả thông tin lỗi
Có phản ánh khách hang về dịch vụ 2G.
Cảnh báo trạm/cell, Network Trạm hoạt động bình thường, không có cảnh báo ngoài, truyền dẫn cũng nhu cảnh bảo Hardware.

Từ thống kê các định chỉ số RTCH_Asign_Failure cao, thống kế chỉ số này trên từng TRX để xác định TRX chất
Phân tích nguyên nhân lỗi
lượng kém.

Phương án xử lý Thực hiện khóa và thay thế TRX chất lượng kém

Kết quả Chỉ số CSSR đã tốt trở lại, dịch vụ tốt, khách hàng không còn phản ánh.
4.4.2. BADCELL 2G_CSSR
Case 2 Thể loại Chi tiết

Tên người xử lý case Trần Xuân Trường

Đơn vị RNOC1

Thời gian xử lý 11/3/2019

Chủng loại thiết bị Alcatel

Network 2G

Loại badcell 2G_HOSR

Mô tả thông tin lỗi -Xuất hiện nhiều Cell trên địa bàn 1 Tỉnh suy giảm chỉ số HOSR kém 2-3%.

-BSC hoạt động bình thường không có cảnh báo.


Cảnh báo trạm/cell, Network
-BTS xuất hiện nhiều cảnh báo CLK_Degrade trên card SUMA

Từ hệ thống xác định nguồn động bộ của BSC chạy trên trung kế nào, Trung kế đó cho dịch vụ thoại hay Data.
Phân tích nguyên nhân lỗi
Nếu nguồn đồng bộ đang chạy trên trung kế Data sẽ gây mất đồng bộ các BTS dẫn đến duy giảm chỉ số HOSR

Thực hiện khóa tất cả các luồng trung kế cho dịch vụ Data(Làm vào giờ thấp điểm do tác động này gây mất dịch
Phương án xử lý
vụ) mục đích để nguồn đồng bộ chuyển sang các trung kế cho dịch vụ thoại.

Kết quả Sau khi thực hiện chỉ số KPI HOSR đã tăng trở lại
4.4.3. BADCELL 2G_CSSR
Case 3 Thể loại Chi tiết

Tên người xử lý case Trần Xuân Trường

Đơn vị RNOC1

Thời gian xử lý 11/3/2019

Chủng loại thiết bị Alcatel

Network 2G

Loại badcell 2G_CSSR


- Cell có chỉ số CSSR=0, Thống kê vẫn có cuộc gọi .
Mô tả thông tin lỗi
- Phản ánh khách hang có sóng nhưng không gọi được
- BSC hoạt động bình thường không có cảnh báo.
Cảnh báo trạm/cell, Network
- BTS hoạt động bình thường, không có cảnh báo

-Kiểm tra cảnh báo trên hệ thống không có cảnh báo bất thường.
Phân tích nguyên nhân lỗi
-Cell vẫn có cuộc gọi, chiếm kênh nhưng chỉ có cuộc gọi HO(MO không có MT)

- Rà soát LAC/CI đã được khai trên hệ thống và Core CS phát hiện thấy CI của Cell này khai sai trên Core CS.
Phương án xử lý
- Xóa đi và khai lại CI trên tổng đài

Theo dõi thống kê sau khi thực hiện chỉ số CSSR đã tốt trở lại. Đã có cuộc gọi MO/MT/HO. Khách hàng đã hết
Kết quả
phản ánh.
4.4.4. BADCELL 2G_DCR
Thể loại Chi tiết

Tên người xử lý case Trần Xuân Trường

Đơn vị RNOC1

Thời gian xử lý 11/3/2019

Chủng loại thiết bị Alcatel

Network 2G

Loại badcell 2G_DCR

- Xuất hiện nhiều Cell trên địa bàn 1 Tỉnh suy giảm chỉ số Drop call .
Mô tả thông tin lỗi
- DCR mức BSC tăng cao bất thường trên tất cả các Cell.

- BSC hoạt động bình thường không có cảnh báo.


Cảnh báo trạm/cell, Network
- BTS hoạt động bình thường, không có cảnh báo

Từ thống kê hệ thống thấy rằng, tỉ lệ Call drop do nguyên nhân DR_Remote_TC tăng cao đột biến.
Quá trình xử lý
Thống kê trên OMC chỉ ra rằng chỉ số này tăng đột biến trên 1 trung kế nhất định

Thực hiện khóa traffic trên trung kế đó.


Phương án xử lý
Thực hiện Reset hoặc thay thế Card MT120( Transcoder Card) tại TC

Kết quả Theo dõi thống kê sau khi thực hiện chỉ số DCR đã tốt trở lại
4.4.5. BADCELL 2G_HOSR
Thể loại Chi tiết
Tên người xử lý case Trần Xuân Trường
Đơn vị RNOC1
Thời gian xử lý 11/3/2019

Chủng loại thiết bị Alcatel


Network 2G
Loại badcell 2G_HOSR
- 1 vài Cell có chỉ sô HOSR thấp .
Mô tả thông tin lỗi
- Chỉ số DCR tăng cao do nguyên nhân HO Failuare

- BSC hoạt động bình thường không có cảnh báo.


Cảnh báo trạm/cell, Network
- BTS hoạt động bình thường, không có cảnh báo

Thực hiện lấy thống kê đánh giá tỉ lệ HOSR giữa các cặp Cell nằm trong Neighbor_List.
Quá trình xử lý
Phát hiện các Cell có chỉ số Fail tăng cao để xử lý.

- Kiểm tra cảnh báo và tham số BTS không có gì bất thường


-Thực hiện Reset card điều khiển chính SUMA của BTS chứa Cell gây khó HO.
Phương án xử lý
- Xuất hiện cảnh báo Suma_CLK_Degrade.
- Thực hiện thay thế card Suma, để Clear cảnh báo Suma_CLK_Degrade

Kết quả Theo dõi thống kê sau khi thực hiện chỉ số HOSR đã tốt trở lại
4.4.6. BADCELL 3G_CSSR
Case 1 Thể loại Chi tiết
Tên người xử lý case Nguyễn Minh Tiến
Đơn vị RNOC2
Thời gian xử lý 3/2/2018
Chủng loại thiết bị Alcatel Lucent
Network 3G
Loại badcell CSSR CS kém
Chỉ số CSSR CS sector 3G-TPH020M41-TGG, phân tích các thành phần CSSR thì nhận thấy RRC kém giảm còn
Mô tả thông tin lỗi
90%
Cảnh báo trạm/cell, Network Không có cảnh báo liên quan chất lượng
Phân tích nguyên nhân lỗi Thống kê KPI hệ thống, nhận thấy KPI sector 3G-TPH020M41-TGG ngày 02/02/2018 bắt đầu suy giảm.
- Tiến hành reset mềm sector kém trên hệ thống, theo dõi KPI.
- Sau reset, KPI vẫn không cải thiện. Phối hợp hiện trường đo kiểm khu vực cell kém. Tỉ lệ thiết lập cuộc gọi kém,
Phương án xử lý đồng thời cho tiến hành reset cứng tại trạm. Theo dõi KPI.
- Sau khi reset cứng, KPI vẫn ko cải thiện. Tiến hành cho thay thế RRH và test lại hiện trường thấy tỉ lệ thiết lập đạt
100% và theo dõi KPI thấy chỉ số CSSR đã cải thiện hơn trước.
KPI đã cải thiện

Kết quả
4.4.7. BADCELL 3G_CSSR
Case 2 Thể loại Chi tiết

Tên người xử lý case Nguyễn Minh Tiến


Đơn vị RNOC2
Thời gian xử lý 15/05/2018
Chủng loại thiết bị Alcatel Lucent
Network 3G
Loại badcell CSSR CS kém

Mô tả thông tin lỗi Chỉ số CS IRAT sector 3G_Vinh-Long6_VLG kém

Cảnh báo trạm/cell, Network Không có cảnh báo liên quan chất lượng
- Thống kê KPI hệ thống, nhận thấy KPI sector 3G_Vinh-Long6_VLG kém.
- Vì ALU không có thống kê Cell-to-Cel để xác định quan hệ NB 3G-2G nào kém, Do đó rà soát các cảnh báo các NB 2G của cell 3G_Vinh-
Long6_VLG, phát hiện cell 2G_Vinh-Long3_VLG bị lỗi song đứng. Đề xuất xử lý lỗi cell 2G. Theo dõi KPI thấy đã cải thiện.
Phân tích nguyên nhân lỗi

- Kiểm tra thông số BCCH, BSIC, LAC, CI của các cell NB 2G của cell 3G_Vinh-Long6_VLG đã khai báo đúng chưa.
Phương án xử lý - Rà soát cảnh báo các cell NB 2G, phát hiện cell 2G_Vinh-Long3_VLG bị lỗi song đứng.
- Xử lý lỗi song đứng cell cell 2G_Vinh-Long3_VLG, KPI CS IRAT 3G đã cải thiện.
KPI đã cải thiện:

Kết quả
4.4.8. BADCELL 3G_PS_CSSR

Thể loại Chi tiết


Tên người xử lý case NGÔ HỒNG PHONG
Đơn vị RNOC2
Thời gian xử lý 8/2/2019
Chủng loại thiết bị ALU
Network 3G
Loại badcell PS CSSR
Mô tả thông tin lỗi Tại tỉnh BTE xác định khu vực 2 cell của 1 trạm bị suy giảm PS CSSR.
Kiểm tra toàn bộ các cảnh báo của các badcell, tồn tại các cảnh báo 1 trạm 3G_Mo-Cay-5_BTE:
Cảnh báo trạm/cell, Network
- BTS/0 NOT ENOUGH HSUPA RESOURCE
Từ KPI thống kê , xác định chi tiết nguyên nhân các cell này bị suy giảm RABEstabSuccessPS, nghi ngờ khả năng
Phân tích nguyên nhân lỗi
lỗi card CEM trạm 3G_Mo-Cay-5_BTE
Thực hiện xử lý trạm theo 2 bước:
Phương án xử lý - Reset CEM cảnh báo.
- Nếu KPI vẫn chưa tốt, thực hiện thay mới CEM của các cells bị suy giảm.

Kết quả
4.5. HỆ THỐNG HUAWEI
4.5.1. BADCELL 2G_CSSR
Case 1 Thể loại Chi tiết
Tên người xử lý case Lê Đình Dương Đơn vị RNOC 3 Thời gian xử lý 02/02/2019 Chủng loại thiết bị Huawei Network 2G
Loại badcell CSSR
Mô tả thông tin lỗi Tại tỉnh BDH, xác định 2 cell tồi 2G_VCH003M11_BDH và 2G_VCH003M12_BDH
Cảnh báo trạm/cell, Network Trạm không có cảnh báo phát sinh
1. Rà soát Neighbor và tham số đầy đủ. Thực hiện lấy thống kê KPI Cell trên hệ thống nhận thấy KPI tồi tại mọi
thời điểm trong ngày. Tiến hành phân tích log đo kiểm.
2. Nhận thấy vùng phủ 2 cell trùng nhau và mưc thu luôn gần bằng nhau -> 2 cell này bị chéo feeder sợi. 1 sợi Tx
của cell 1 chéo với 1 sợi Tx của cell 2.

Phân tích nguyên nhân lỗi

Phương án xử lý Các action thực hiện: Thực hiện đấu lại feeder cho trạm.
Kết quả Sau khi xử lý xong chéo feeder sợi KPI CSSR đã tốt trở lại.
4.5.2. BADCELL 2G_CSSR
Case 2 Thể loại Chi tiết
Tên người xử lý case Lê Đình Dương Đơn vị RNOC3 Thời gian xử lý 14/3/2018 Chủng loại thiết bị Huawei Network 2G
Loại badcell CSSR
Mô tả thông tin lỗi Tại tỉnh QNI, xác định 1 cell tồi CSSR, DCR 2G_DPO016M11_QNI
Cảnh báo trạm/cell, Network Trạm không có cảnh báo phát sinh
1. Rà soát Neighbor và tham số đầy đủ. Thực hiện lấy thống kê KPI Cell trên hệ thống nhận thấy KPI tồi tại mọi
thời điểm trong ngày. Tiến hành phân tích log đo kiểm nhận thấy mức thu của cell kém mặc dù ở gần trạm. Kiểm
tra lại khai báo trên hệ thống nhận thấy.

Phân tích nguyên nhân lỗi

2. Dữ liệu khai báo thể hiện cell 1 chỉ được khai báo phân tập thu 1 đường -> ảnh hưởng đến mức thu của cell gây
tồi CSSR và CDR.
Các action thực hiện: Thực hiện khai báo lại phân tập thu 2 đường

Phương án xử lý

Kết quả Sau khi thực hiện khai báo KPI CSSR, CDR đã tốt trở lại.
4.5.3. BADCELL 2G_CSSR
Case 3 Thể loại Chi tiết
Tên người xử lý case Phạm Hường Ánh Đơn vị RNOC3 Thời gian xử lý 05/07/2017 Chủng loại thiết bị Huawei Network 2G
Loại badcell HOSR, CSSR
Mô tả thông tin lỗi Tại tỉnh DNO, xác định 2G_DML021M12_DNO( Buon-Dak-Rla2_DNO) kém HOSR
Cảnh báo trạm/cell, Network Kiểm tra trạm không có cảnh báo liên quan phần cứng, truyền dẫn
Phối hợp hiện trường đo kiểm thấy nhiễu khu vực cell 2

Phân tích nguyên nhân lỗi

Các action thực hiện: Thực hiện đổi tần số TCH=9 sang 8 cho cell 2G_DML021M12_DNO và đổi tần số BCCH=8
Phương án xử lý
sang 10 cho cell 2G_DML021M13_DNO
Kết quả Sau khi xử lý xong cảnh báo KPI CSSR, HOSR đã tốt trở lại.
4.5.4. BADCELL 2G_DCR
Thể loại Chi tiết
Tên người xử lý case Nguyễn Duy Khánh Đơn vị RNOC3 Thời gian xử lý 13/06/2018 Chủng loại thiết bị Huawei Network 2G
Loại badcell HOSR, DCR
Mô tả thông tin lỗi Cell 2G_BTO011M11_QNI và 2G_BTO011M12_QNI handover kém với các trạm lân cận
Cảnh báo trạm/cell, Network Trạm không có cảnh báo HW.
- Rà soát tham số và Neighbor trên hệ thống hoàn toàn bình thường.
- Rà soát thống kê Handover cell to cell thấy handover kém.

Phân tích nguyên nhân lỗi

Phương án xử lý Kiểm tra hiện trường, xử lý chéo cell.


Kết quả Sau khi xử lý xong KPI HOSR của Badcell tốt, thoát badcell
4.5.5. BADCELL 3G_CSSR
Thể loại Chi tiết

Tên người xử lý case Trần Quang Nghĩa

Đơn vị RNOC1

Thời gian xử lý 06/03/2019

Chủng loại thiết bị Huawei

Network 3G

Loại badcell CSSR, PS_CSSR, kém

Mô tả thông tin lỗi Kiểm tra thống kê KPI xuất hiện suy giảm đột biến chỉ số PS_CSSR, CS_CSSR so với các ngày trước đó

Trạm xuất hiện cảnh báo:


Cảnh báo trạm/cell, Network
Board BFN abnormal trên card WBBP slot 3

Quá trình xử lý Suy giảm xuất hiện do phần cứng lỗi ở card WBBP slot 3 gây ra

Phương án xử lý 1. Thực hiện thay thế phần cứng bị lỗi

Kết quả 2. Theo dõi thống kê KPI và cảnh báo sau khi hiện trường thay thế phần cứng lỗi
4.5.6. BADCELL 3G_PS_CSSR

Thể loại Chi tiết

Tên người xử lý case Trần Quang Nghĩa

Đơn vị RNOC1

Thời gian xử lý 06/03/2019

Chủng loại thiết bị Huawei

Network 3G

Loại badcell PS_CSSR kém

Mô tả thông tin lỗi Kiểm tra thống kê KPI xuất hiện suy giảm chỉ số PS_CSSR tập trung một số giờ cao điểm

Cảnh báo trạm/cell, Network Không có cảnh báo từ các badcell

1. Kiểm tra event log của trạm


2. Xác định các thời điểm xảy ra sự suy giảm
Phân tích nguyên nhân lỗi 3. Kiểm tra thống kê các chỉ số KPI khác trong đó có chỉ số PS_RAB_Congestion. Phát hiện vào các thời điểm PS_CSSR kém xuất hiện
nghẽn cao
4. Lấy thống kê chi tiết về nghẽn nhận thấy các khung giờ cao điểm badcell có nghẽn cao về Uplink CE

1. Yêu cầu hiện trường bổ sung 1 card WBBPD1 hoặc 1 card UBBPD1
Phương án xử lý 2. Phối hợp khai báo cấu hình
3. Phân bổ license Uplink CE và theo dõi thống kê

Kết quả Sau khi xử lý xong KPI PS_CSSR đã trở về mức > 98%
4.5.7. BADCELL 3G_CS_DCR
Thể loại Chi tiết

Tên người xử lý case Trần Quang Nghĩa

Đơn vị RNOC1

Thời gian xử lý 06/03/2019

Chủng loại thiết bị Huawei

Network 3G

Loại badcell CS_CDR kém

Mô tả thông tin lỗi Kiểm tra thống kê KPI xuất hiện suy giảm KPI CS_CDR so với các ngày trước đó.

Kiểm tra alarm log trạm xuất hiện cảnh báo sau lặp lại nhiều lần trong ngày:
Cảnh báo trạm/cell, Network
- RF Unit maintenance link failure với cause là board power off

1. Kiểm tra alarm,event log của trạm.


Quá trình xử lý
2. Xác định lỗi gây ra liên quan tới khối thu phát RRU hoạt động chập chờn.

1. Yêu cầu hiện trường kiểm tra nguồn điện cấp cho RRU, cũng như khả năng hoạt động của phần cứng RRU.
Phương án xử lý
2. Phối hợp theo dõi cảnh báo và KPI sau khi hiện trường tiến hành xử lý lỗi.

Kết quả Sau khi xử lý xong KPI CS_CDR đã trở về mức dưới 2%
4.5.8. BADCELL 3G_PS_CSSR
Case 1 Thể loại Chi tiết
Tên người xử lý case Trần Quang Nghĩa
Đơn vị RNOC1
Thời gian xử lý 06/03/2019
Chủng loại thiết bị Huawei
Network 3G
Loại badcell PS_CSSR, CSSR kém

Mô tả thông tin lỗi Kiểm tra thống kê KPI xuất hiện suy giảm đột biến chỉ số CSSR vào một khoảng thời gian trong ngày

Cảnh báo trạm/cell, Network Không có cảnh báo từ các badcell

1. Kiểm tra event log của trạm.


2. Xác định các thời điểm xảy ra sự suy giảm.
3. Kiểm tra thống kê các chỉ số KPI khác trong đó có chỉ số PS_RAB_Congestion, CS_RAB_Congestion. Phát hiện
Quá trình xử lý
vào các thời điểm PS_CSSR, CS_CSSR kém xuất hiện nghẽn cao.
4. Lấy thống kê chi tiết về nghẽn nhận thấy khung giờ xuất hiện suy giảm đột biến badcell có nghẽn cao về Uplink
Power, cần mở rộng cấu hình trạm từ 2 tần số lên 3 tần số.

1. Yêu cầu kỹ sư RF thiết kế tần số nâng cấp cấu hình trạm từ 2/2/2 lên 3/3/3.
Phương án xử lý 2. Thực hiện khai báo cấu hình.
3. Theo dõi thống kê.

Kết quả Sau khi xử lý xong KPI CS_CSSR và PS_CSSR đã trở về mức > 98%
4.5.9. BADCELL 3G_PS_CSSR
Case 2 Thể loại Chi tiết

Tên người xử lý case Trần Quang Nghĩa

Đơn vị RNOC1

Thời gian xử lý 06/03/2019

Chủng loại thiết bị Huawei

Network 3G

Loại badcell PS_CSSR, CS_CDR kém

Mô tả thông tin lỗi Kiểm tra thống kê KPI xuất hiện suy giảm KPI PS_CSSR, CS_CDR so với các ngày trước đó

Kiểm tra alarm log trạm xuất hiện cảnh báo sau lặp lại nhiều lần trong ngày:
Cảnh báo trạm/cell, Network - IP Path Excessive Packet Loss Rate.
- MAC Excessive Frame Error Rate.

1. Kiểm tra alarm,event log của trạm thấy các cảnh báo nêu trên xuất hiện nhiều lần trong ngày.
Quá trình xử lý 2. Thực hiện thống kê KPI về chất lượng truyền dẫn của trạm thấy tỉ lệ rớt gói truyền dẫn cao > 2% nhiều giờ trong
ngày.

1. Yêu cầu VNPT tỉnh kiểm tra xử lý chất lượng truyền dẫn.
Phương án xử lý
2. Phối hợp theo dõi cảnh báo và KPI sau khi hiện trường tiến hành xử lý lỗi.

Kết quả Sau khi xử lý xong KPI CS_CDR đã trở về mức dưới 2%, KPI PS_CSSR đã trở về mức > 98%
4.5.10. BADCELL 3G_CS_IRAT_HOSR
Thể loại Chi tiết

Tên người xử lý case Trần Quang Nghĩa

Đơn vị RNOC1

Thời gian xử lý 06/03/2019

Chủng loại thiết bị Huawei

Network 3G

Loại badcell CS_IRAT HOSR kém

Mô tả thông tin lỗi Kiểm tra thống kê KPI xuất hiện suy giảm KPI CS_IRAT HOSR kém so với các ngày trước đó

Cảnh báo trạm/cell, Network Không xuất hiện cảnh báo

1. Kiểm tra thống kê KPI Handover giữa các cặp 3G-2G thấy tỉ lệ không thành công tập trung trên một số cell 2G.
2. Tiến hành so sánh cấu hình external 2G cell khai báo trên RNC so với cấu hình RF mới nhất hệ thống 2G.
Quá trình xử lý
3. Phát hiện sai lệch về BCCH giữa external 2G cell khai báo trên RNC so với cấu hình mới nhất trên hệ thống 2G
do hệ thống 2G mới thực hiện đổi tần để xử lý chất lượng 2G.

1. Update lại BCCH khai báo trong external 2G cell trên RNC.
Phương án xử lý
2. Theo dõi KPI sau khi thực hiện xử lý.

Kết quả Sau khi xử lý xong KPI CS_IRAT HOSR đã trở lại mức > 96%
4.6. HỆ THỐNG ZTE
4.6.1. BADCELL 2G_CSSR

Thể loại Chi tiết

Tên người xử lý case Nguyễn Trần Minh Luân

Đơn vị RNOC3

Thời gian xử lý 05/01/2019

Chủng loại thiết bị ZTE

Network 2G

Loại badcell CSSR

Mô tả thông tin lỗi Tại tỉnh KHA, cell 2G_CRH023M31_KHA CSSR suy giảm.

Cảnh báo trạm/cell, Network Trạm có cảnh báo chập chờn MLL TRX sector1

Quá trình xử lý KPI cell bị nghẽn do MLL TRX gây suy giảm CSSR.

Phương án xử lý Thực hiện reset phần cứng, theo dõi.

Kết quả Sau khi xử lý xong cảnh báo KPI CSSR đã cải thiện.
4.6.2. BADCELL 2G_HOSR
Thể loại Chi tiết
Tên người xử lý case Trần Minh Luân Đơn vị RNOC3 Thời gian xử lý 10/03/2019 Loại thiết bị Motorola Network 2G
Loại badcell HOSR
Mô tả thông tin lỗi Tại tỉnh GLI, cell 2G_PLU009M13_GLI HOSR kém.
Cảnh báo trạm/cell, Network Trạm không có cảnh báo phát sinh.
1. Rà soát tham số và Neighbor trên hệ thống hoàn toàn bình thường.
2. Kiểm tra thống kê HO Cell to cell phát hiện Handover kém với cell 2G_PLU032M22_GLI.
3. Đề nghị VNPT GLI đo kiểm, NET3 phân tích logfile phát hiện cell 2G_PLU032M22_GLI bị nhiễu đồng kênh TCH
610.

Phân tích nguyên nhân lỗi

Phương án xử lý NOC3 thực hiện quy hoạch lại tần số.


Kết quả Sau khi xử lý xong cảnh báo KPI HOSR đã cải thiện.
4.6.3. BADCELL 3G_DCR
Case 1 Thể loại Chi tiết
Tên người xử lý case Lê Đình Dương Đơn vị RNOC3 Thời gian xử lý 11/08/2018 Chủng loại thiết bị ZTE Network 3G
Loại badcell Drop call.
Mô tả thông tin lỗi Tại tỉnh QNM, xác định 1 cell tồi Dropcall 3G_TKY004M21.
Cảnh báo trạm/cell, Network Trạm không có cảnh báo phát sinh.
1. Rà soát tham số và Neighbor trên hệ thống hoàn toàn bình thường. Phối hợp với NET3 thực hiện đo kiểm xử lý
hiện trường kết quả chỉ ra cell 3G_TKY004M21 bị overshoot vùng phủ không hợp lý dẫn đến thuê bao ở xa bắt
được có RSCP và EcNo kém gấy rớt cuộc gọi.

Phân tích nguyên nhân lỗi

Phương án xử lý Các action thực hiện: Thực hiện downtilt cell 3G tối ưu lại vùng phủ cell Overshoot.
Kết quả Sau khi xử lý xong KPI của Badcell đã tốt lại. Đo kiểm không còn bị Dropcall.
4.6.4. BADCELL 3G_DCR
Case 2 Thể loại Chi tiết
Tên người xử lý case Lê Đình Dương Đơn vị RNOC3 Thời gian xử lý 11/01/2018 Chủng loại thiết bị ZTE Network 3G
Loại badcell CS DCR
Mô tả thông tin lỗi Tại tỉnh QNI, xác định 1 cell tồi CS DCR 3G_NHH015M23_QNI. KPI tồi tất cả các giờ trong ngày.
Cảnh báo trạm/cell, Network Trạm không có cảnh báo phát sinh.
1. Rà tham số hệ thống khai báo đầy đủ, kiểm tra logfile đo kiểm nhận thấy Cell bị Dropcall nguyên nhân do cell
phủ xa missing NB với trạm 3G_NHH003M23 dẫn đến hiện tượng bám cell 3G_NHH015M23 gây Dropcall.

Phân tích nguyên nhân lỗi

Phương án xử lý Các action thực hiện: Thực hiện khai báo lại Neighbor missing còn thiếu.
Kết quả Sau khi thực hiện khai báo KPI CS CDR đã tốt trở lại.
4.6.5. BADCELL 3G_CSSR
Case 2 Thể loại Chi tiết
Tên người xử lý case Lê Đình Dương Đơn vị RNOC3 Thời gian xử lý 27/12/2018 Chủng loại thiết bị ZTE Network 3G
Loại badcell CSSR
Mô tả thông tin lỗi Tại tỉnh QNM, xác định 1 cell tồi 3G CSSR, KPI thấp toàn bộ các giờ cao điểm.
Cảnh báo trạm/cell, Network Trạm không có cảnh báo phát sinh
1. Rà soát Neighbor và tham số đầy đủ. Thực hiện lấy thống kê KPI Cell to Cell trên hệ thống:

2. Nhận thấy KPI của cell tồi do nguyên nhẫn nghẽn RAB. Tiếp tục đo kiểm vùng phủ để xác định còn nguyên nhân
Phân tích nguyên nhân lỗi khác ảnh hưởng đến KPI không.

3. Nhận thấy khu vực có vùng phủ tốt nhưng nguyên nhân MS disconnect là do “Resources Unavailable trong bản
tin Layer 3 đọc trên Tems.
Phương án xử lý Các action thực hiện: Thực hiện nâng cấp card BPC cho trạm.
Kết quả Sau khi xử lý xong cảnh báo KPI CSSR đã tốt trở lại.

You might also like