HƯỚNG DẪN XỬ LÝ BADCELL 2G ALCATEL

You might also like

Download as docx, pdf, or txt
Download as docx, pdf, or txt
You are on page 1of 4

HƯỚNG DẪN XỬ LÝ BADCELL 2G ALCATEL

1. BADCELL CSSR:

+ Những nguyên nhân thường gặp:

- Do phần cứng: Sóng đứng (VSWR), ANC lỗi, TRE lỗi

- Do tần số: Thiết kế không tốt gây nhiễu BCH, TCH.

- Do outdoor thiết kế và lắp đặt không tốt: Chéo cell, overshoot, không đúng hướng, sai tọa độ

- 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 đinh.

- Do khai báo: Khai báo sai tần số.

- Do nghẽn: Năng lực cell không đủ để phục vụ

+ Các bước để xử lý CSSR:

- Do phần cứng: Theo dõi cảnh báo hệ thống để phát hiện lỗi phần cứng và VSWR, sử dụng NPO
để giám sát hiệu suất TRE. Nếu có lỗi phần cứng thì thực hiện thay thế, xử lý lỗi…

- Do tần số: Kiểm tra lại tần số bằng Atoll, kết hợp với đo bằng máy TEMS, kiểm tra lắp đặt
outdoor tại hiện trường. Kiểm tra lại khai báo. Lấy thống kê nhiễu từ NPO

- Do outdoor: Đo bằng máy TEMS và kiểm tra hiện trường outdoor (kiểm tra azimuth, tilt, chéo
cell)

- Do địa hình, vị trí lắp đặt: Kiểm tra vùng phủ bằng thống kê TA, kiểm tra độ phức tạp địa hình
bằng thống kê Rxlev và Rxqual, kết hợp với Driving Test. Đa phần với các trạm này không có phương án
xử lý và được đưa vào blacklist.

- Do khai báo: Kiểm tra rà soát lại khai báo

- Do nghẽn: Cắm thêm phần cứng và khai báo thêm tần số. Có thể cắm thêm trạm.

+ Công thức CSSR:

CSSR = (1- SDCCH_drop_rate )*(1- RTCH_assign_unsuccess_rate )

CSSR = 100 * (1 - (MC138 + MC07 + MC137) / (MC148)) * (1 - ((MC140B - MC718) / ((MC140A+MC140B)


- (MC142E + MC142F))))

*SDCCH_drop_rate = SDCCH_drop / SDCCH_assign_success

*RTCH_assign_unsuccess_rate = RTCH_assign_unsuccess / RTCH_assign_request 

- Nhận xét:

- Từ công thức ta thấy, muốn tăng CSSR chúng ta cần phải giảm Drop SDDCH và RTCH assign fail.

- Drop SDDCH gây ra do các nguyên nhân chính: do địa hình phức tạp (đồi núi, sông hồ..), do
chất lượng mạng (overshoot, nhiễu…), do phần cứng (suy hao, phần cứng…)
- RTCH assign fail gây ra do các nguyên nhân chính: do địa hình phức tạp (đồi núi, sông hồ..), do
chất lượng mạng (overshoot, nhiễu…), do phần cứng (suy hao, phần cứng…)

- Kinh nghiệm: Nếu do địa hình phức tạp, nhiễu thì Drop SDDCH sẽ rất cao, RTCH assign fail thể
hiện không rõ nét. Nếu do phần cứng thì RTCH assign fail thể hiện rõ nét hơn.

2. BADCELL Drop Call Rate:

+ Những nguyên nhân thường gặp:

- Do phần cứng: Sóng đứng (VSWR), ANC lỗi, TRE lỗi

- Do truyền dẫn kém: Như nháy, BER…

- Do tần số: Thiết kế không tốt gây nhiễu BCH, TCH. Thiết kế thiếu neighbor

- Do outdoor thiết kế và lắp đặt không tốt: Chéo cell, overshoot, không đúng hướng, sai tọa
độ….

- 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 đinh.

- Do khai báo: Khai báo sai tần số, khai báo thiếu HO….

+ Các bước để xử lý DCR:

- Do phần cứng: Theo dõi cảnh báo hệ thống để phát hiện lỗi phần cứng và VSWR, sử dụng NPO
để giám sát hiệu suất TRE. Nếu có lỗi phần cứng thì thực hiện thay thế, xử lý lỗi…

- Do tần số: Kiểm tra lại tần số bằng Atoll, kết hợp với đo bằng máy TEMS, kiểm tra lắp đặt
outdoor tại hiện trường. Kiểm tra lại khai báo. Lấy thống kê nhiễu từ NPO

- Do outdoor: Đo bằng máy TEMS và kiểm tra hiện trường outdoor (kiểm tra azimuth, tilt, chéo
cell)

- Do địa hình, vị trí lắp đặt: Kiểm tra vùng phủ bằng thống kê TA, kiểm tra độ phức tạp địa hình
bằng thống kê Rxlev và Rxqual, kết hợp với Driving Test. Đa phần với các trạm này không có phương án
xử lý và được đưa vào blacklist.

- Do khai báo: Kiểm tra rà soát lại khai báo

+ Công thức DCR:

Call_drop_rate  = Call_drop / RTCH_success_end

* Call_drop = Call_drop_radio + Call_drop_HO + Call_drop_BSS + Call_drop_preemption

* RTCH_success_end =  RTCH_success - RTCH_HO_Out_success 
- Nhận xét:

- Call Drop Radio: Nguyên nhân gây ra do nhiễu, overshoot, địa hình phức tạp (hoàn toàn liên
quan đến phần vô tuyến). Thường được xác định bằng driving test và rà soát tần số.

- Call_drop_HO: Xảy ra trong quá trình Handover. Thường được xác định bằng driving test

- Call_drop_BSS: Bao gồm Drop do truyền dẫn và phần cứng. Drop do truyền dẫn thì chia làm 2
đoạn truyền dẫn: môt là truyền dẫn từ BTS về BSC, 2 là từ BSC về TC. Drop do phần cứng thì chia làm 2
phần: một là do phần cứng BTS (VSWR, TRE, ANC…), hai là do phần cứng BSC (JBXCCP…).

- Call_drop_preemption: tính năng không kích hoạt.

3. BADCELL HOSR:

+ Những nguyên nhân thường gặp:

- Do phần cứng: Sóng đứng (VSWR), ANC lỗi, TRE lỗi, SUMA (Clock hardware degrade)

- Do tần số: Thiết kế không tốt gây nhiễu BCH, TCH. Thiết kế thiếu neighbor

- Do outdoor thiết kế và lắp đặt không tốt: Chéo cell, overshoot, không đúng hướng, sai tọa
độ….

- 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 đinh.

- Do khai báo: Khai báo sai tần số, khai báo thiếu HO….

- Do nghẽn: Năng lực cell không đủ để phục vụ

+ Các bước để xử lý HOSSR:

- Do phần cứng: Theo dõi cảnh báo hệ thống để phát hiện lỗi phần cứng và VSWR, sử dụng NPO
để giám sát hiệu suất TRE. Nếu có lỗi phần cứng thì thực hiện thay thế, xử lý lỗi…

- Do tần số: Kiểm tra lại tần số bằng Atoll, kết hợp với đo bằng máy TEMS, kiểm tra lắp đặt
outdoor tại hiện trường. Kiểm tra lại khai báo

- Do outdoor: Đo bằng máy TEMS và kiểm tra hiện trường outdoor (kiểm tra azimuth, tilt, chéo
cell)

- Do địa hình, vị trí lắp đặt: Kiểm tra vùng phủ bằng thống kê TA, kiểm tra độ phức tạp địa hình
bằng thống kê Rxlev và Rxqual, kết hợp với Driving Test. Đa phần với các trạm này không có phương án
xử lý và được đưa vào blacklist.

- Do khai báo: Kiểm tra rà soát lại khai báo

- Do nghẽn: Cắm thêm phần cứng và khai báo thêm tần số. Có thể cắm thêm trạm

- Kiểm tra các cặp HO fail, tập trung xử lý vào các cặp đó. Các bước tác động chính khi xử lý tại
bước này:
* Nếu số lượng attempt ít mà drop call cao, có thể xem xét bỏ đi

* Nếu số lượng attempt cao mà drop cao, cần driving test tập trung vào cặp đó. Kiểm tra
tần số, khoảng cách giữa các trạm… Rồi sau đó phân tích thêm.

You might also like