Nghiên cứu, xây dựng phần mềm nâng cao độ chính xác trong đo kiểm đánh giá KPI mạng vô tuyến

Nghiên cứu, xây dựng phần mềm nâng cao độ chính
xác trong đo kiểm đánh giá KPI mạng vô tuyến
Phạm Quốc Cường1, Tăng Tấn Chiến2
1

Trung tâm TMC MobiFone – Tổng Công ty Viễn thông MobiFone
Khoa Điện tử - Viễn thông, Trường Đại học Bách khoa, Đại học Đà Nẵng

2

Email: , ,
Abstract— Đo kiểm Drive Test, một trong những kỹ thuật để
đánh giá chất lượng các hệ thống thông tin di động 2G, 3G, 4G và
5G theo hướng cảm nhận người dùng tại các nhà mạng di động
trên thế giới nói chung và Việt Nam nói riêng. Việc đo kiểm đánh
giá đúng hiện trạng chất lượng mạng lưới là rất cần thiết để phục
vụ quá trình tối ưu hóa liên tục mạng vô tuyến của các nhà mạng
cũng như công tác đo kiểm mạng di động hàng năm theo Quy
chuẩn kỹ thuật quốc gia (QCVN) của Cục Viễn thông. Trong bài
báo này, chúng tôi nghiên cứu và xây dựng phần mềm có khả
năng tự động phát hiện, cảnh báo và xóa các logfile đo kiểm
Drive Test bị trùng lặp nhằm nầng cao độ chính xác trong việc
tính toán KPIs chất lượng dịch vụ di động bằng ngôn ngữ lập
trình C#.

II.

Kỹ thuật đo kiểm Drive Test là một phương pháp đo lường và
đánh giá vùng phủ, dung lượng, chất lượng dịch vụ (QoS) của
mạng vô tuyến di động (RAN) [1] được các nhà mạng thực
hiện đo định kỳ hoặc đột xuất để phục vụ công tác tối ưu hóa

cũng như xử lý các sự cố kỹ thuật phát sinh trên mạng lưới.
Ngoài ra, Cục Viễn thông – Bộ Thông tin & Truyền thông sử
dụng kỹ thuật đo Drive Test kết hợp đo cố định để công bố
chất lượng dịch vụ hàng năm của các nhà mạng tại Việt Nam
theo các Quy chuẩn kỹ thuật quốc gia QCVN36 dành cho dịch
vụ thoại [2], QCVN81 dành cho dịch vụ truy cập dữ liệu
Internet [3].
Tùy vào mục đích đo kiểm để triển khai các hệ thống máy đo
khác nhau, các thiết bị sẽ thực hiện đo và lưu dữ liệu dưới dạng
logfile gồm những thông tin như [5], [6], [7]:
x Mức thu vùng phủ 2G (RxLev), 3G (RSCP), 4G/5G
(RSRP).
x Chất lượng vùng phủ 2G (RxQual), 3G (EcNo, Pilot
Pollution), 4G/5G (RSRQ, SINR)
x Tốc độ tải dữ liệu đường lên/đường xuống
x Chất lượng thoại MOS.
x Tỉ lệ chuyển giao thành công (handover) giữa các lớp
mạng 2G, 3G, 4G và 5G, …

Keywords- Drive Test, Xây dựng phần mềm, Nâng cao độ chính
xác, KPIs, Chất lượng dịch vụ.

I.

ĐO KIỂM DRIVE TEST

GIỚI THIỆU

Hiện nay, hầu hết các nhà mạng di động trên thế giới nói
chung và Việt Nam nói riêng sử dụng kỹ thuật đo kiểm Drive

Test để đánh giá chất lượng mạng vô tuyến theo hướng cảm
nhận người dùng QoE [1]. Có rất nhiều hệ thống máy đo đánh
giá chất lượng mạng vô tuyến 2G, 3G, 4G và 5G trên thế giới
bao gồm [1]:
x TEMS - InfoVista
x NEMO – Keysight Technologies
x Swissqual - Rhode & Schwarz
x RantCell - Megron Tech
x QXDM – Qualcomm Technologies
Thực tế hiện nay vẫn chưa có một phần mềm nào tự động
phát hiện, cảnh báo và xóa các logfile đo kiểm Drive Test bị
trùng lặp do lỗi trong quá trình thực hiện thao tác đo, sao lưu
dữ liệu lên hệ thống bản đồ số vùng phủ, … của hầu hết các hệ
thống máy đo với dung lượng cơ sở dữ liệu hàng trăm TB.
Bài báo thực hiện nghiên cứu và xây dựng phần mềm hỗ trợ
phát hiện, cảnh báo và xóa các logfile đo kiểm trùng lặp bằng
ngôn ngữ lập trình C#.
Phần còn lại của bài báo được tổ chức như sau: Trong phần
II, chúng tôi trình bày khái quát về kỹ thuật đo kiểm Drive
Test. Trong phần III, chúng tôi đề xuất thiết kế và xây dựng
thuật toán của phần mềm. Phần IV cung cấp các kết quả ứng
dụng phần mềm trong thực tế. Cuối cùng, bài báo được kết
luận trong phần V.

Hình 1. Hệ thống máy đo benchmarking Nemo Outdoor [4]

Các logfile sau khi đo sẽ được nhập vào phần mềm phân tích
như TEMS Discovery (InfoVista), Nemo Analyze (Keysight),

19

NQDI (Rhode & Schwarz) … sau đó xuất ra số lượng mẫu đo
đạc để tính toán KPIs, các bản tin Layer 2 & Layer 3 để xử lý
sự cố mạng lưới. Dữ liệu đo kiểm có số lượng và dung lượng
file rất lớn có thể xem là big data, thống kê trung bình logfile
bài đo benchmarking chất lượng dịch vụ 2G/3G/4G ba nhà
mạng lớn nhất Việt Nam tại một tỉnh khoảng 200-300GB với
hàng nghìn logfile do đó việc thao tác lỗi đo, sao lưu dữ liệu
lên hệ thống có thể dẫn đến logfile đo bị trùng lặp dẫn đến việc
đánh giá KPIs không còn chính xác do sai lệch số mẫu. Để đảm
bảo tính chính xác trong các báo cáo chất lượng mạng thì tại
mỗi thời điểm, số mẫu được lưu lại phải là duy nhất.
III.

THIẾT KẾ VÀ XÂY DỰNG PHẦN MỀM

1. Đặt vấn đề
Hiện nay, chưa có công cụ tự động nào phát hiện, cảnh báo và
xóa logfile đo kiểm bị trùng lặp trước khi nhập vào phần mềm
phân tích đánh giá KPIs nhằm đảm bảo tính chính xác trong
công tác đo đánh giá chất lượng mạng định kỳ.
Việc xuất hiện logfile trùng lặp trong kết quả đo sẽ làm sai lệch
số liệu báo cáo và việc kiểm tra logfile bị trùng lặp trước đây
hoàn toàn thực hiện thủ công theo phương thức hậu xử lý
(post-processing) gây lãng phí về tài nguyên phần cứng lẫn thời
gian. Bài báo đề xuất giải pháp tiền xử lý logfile (preprocessing) có thể phát hiện và xóa hàng loạt logfile bị trùng
lặp của nhiều hệ thống máy đo kiểm trên thế giới hiện nay
trước khi thực hiện thao tác nhập logfile vào phần mềm phân
tích như: Nemo Analyze, TEMS Discovery, NQDI, QCAT, …

Hình 3. Sơ đồ khối phương pháp xử lý dữ liệu đo kiểm mạng vô tuyến
trước đây và phương pháp mới

2. Thiết kế phần mềm
x Mục đích:
Xây dựng phần mềm có tính năng phát hiện hàng loạt
logfile đo kiểm mạng vô tuyến bị trùng lặp với lượng dữ liệu
đầu vào có thể xem là big data.
Đưa ra danh sách tên các file bị trùng lặp để có thể biết tại
khu vực nào đang xảy ra hiện tượng đo lỗi để tiến hành đo
kiểm lại để thực hiện đánh giá, tối ưu mạng vô tuyến chính xác
hơn.
Phần mềm khả năng tiền xử lý logfile của nhiều hãng cung
cấp thiết bị đo mạng viễn thông lớn hiện nay như: TEMS,
Nemo, Rohde & Schwarz, Qualcomm.
x Kiến trúc phần mềm:
Phần mềm được thiết kế với ba module chính trên nền tảng
Visual C# do Microsoft hỗ trợ các thư viện có sẵn trên hệ điều hành
Windows:

Hình 2. So sánh quy trình phát hiện logfile trùng lặp theo cách truyền
thống (post-processing) và giải pháp đề xuất (pre-processing)

Hình 4. Các module chính của phần mềm

Quá trình tiền xử lý logfile đảm bảo dữ liệu đầu vào là duy
nhất tại mỗi thời điểm máy đo lấy mẫu, do đó tổng dung lượng
logfile cần xử lý có thể sẽ giảm nếu xuất hiện logfile trùng lặp
vì vậy thời gian phân tích xử lý và xuất báo cáo của phần mềm

hãng như: TEMS Discovery, Nemo Analyze, … sẽ được cải
thiện là điều tất yếu. Hình 3 so sánh phương pháp mới đề xuất
so với phương pháp cũ trước đó.

Việc chia phần mềm làm ba module để các quá trình xử lý diễn
ra song song với nhau nhằm giảm thời gian so với việc thực thi
tuần tự, ngoài ra còn tận dụng ưu điểm của các vi xử lý đa lõi
(multi-core), đa luồng (multi-thread) được trang bị trên hầu hết
các bộ xử lý hiện nay.
3. Thuật toán so sánh logfile
Các hàm IO của Visual C# sẽ hỗ trợ đọc các logfile và lưu trữ
dưới dạng kiểu dữ liệu chuỗi (Strings) [8]. Hình 5 trình bày lưu
đồ thuật toán so sánh hai logfile cơ bản:

20


Thực hiện tiền xử lý logfile hệ thống TEMS của hãng InfoVista
đo kiểm các dịch vụ sau tại Thành phố Huế (Thừa-Thiên Huế)
x Tải dữ liệu 3G/4G theo hướng đường lên/đường
xuống.
x Thực hiện cuộc gọi thoại ở chế độ DualMode 2G-3G
x Thực hiện cuộc gọi CSFB từ mạng 4G/LTE về mạng
2G/3G
x Tải dữ liệu liên công nghệ vô tuyến IRAT tripple
mode: 2G/3G/4G
Dung lượng logfile là 6.35GB, số lượng logfile là 833, do quá
trình thao tác sao lưu hoặc dump máy tính trong quá trình đo
dẫn đến quy trình lưu logfile bị trùng (duplicate) và phần mềm
sẽ thực thi thuật toán để phát hiện, cảnh báo và xóa các logfile

này.
-Nếu thực hiện theo quy trình cũ, phương pháp post-processing
thì thời gian để phát hiện được logfile bị trùng dao động hơn 4
giờ do mất 3 giờ 55 phút để phần mềm TEMS Discovery phân
tích logfile.

Hình 5. Lưu đồ thuật toán so sánh logfile

Lưu đồ thuật toán để so sánh 2 logfile có giống nhau hay không
gồm 3 bước [8]:
B1: Đọc file và so sánh nếu hai tham chiếu file trỏ đến cùng
một file có giống nhau hay không.
B2: Nếu hai file khác nhau về tham chiếu thì sẽ so sánh độ dài
của 2 logfile nhờ vào hàm length để xác định kích thước liệu có
bằng nhau.
B3: Đọc và so sánh từng byte dữ liệu một của hai logfile cho
đến khi phát hiện ra byte sai khác hoặc kết thúc file.
IV.

KẾT QUẢ NGHIÊN CỨU VÀ ỨNG DỤNG THỰC TẾ

1. Giao diện của phần mềm
Hình 6 là giao diện GUI của phần mềm sau khi lập trình theo
thuật toán đề xuất và đóng gói, giao diện GUI sẽ chỉ đến thư
mục chứa logfile cần thực hiện tiền xử lý.
Hình 7. Phần mềm phân tích logfile trong quá trình post-processing

-Thực hiện theo phương pháp pre-processing do bài báo đề
xuất:
x Chọn đường dẫn đến thư mục chưa logfile và thực thi

thuật toán

Hình 6. Giao diện GUI của phần mềm

2. Các tính năng chính của phần mềm
Phần mềm hỗ trợ tiền xử lý các định dạng logfile của hầu hết
các hãng đo kiểm lớn trên thế giới như: .nmf (Nemo), .trp
(TEMS), .rmscd (R&S), .isf (Qualcomm), …
Kết quả sau quá trình chạy thuật toán phân tích so sánh là
thống kê số lượng logfile, cảnh báo các tên logfile trùng lặp và
tùy biến xóa hàng loạt logfile bị trùng nhằm đảm bảo dữ liệu
đo kiểm là duy nhất tại mỗi thời điểm lấy mẫu.
Phần mềm sử dụng giao diện GUI trực quan, chạy trên các máy
tính sử dụng hệ điều hành Windows, được xây dựng theo kiểu
phần mềm đa luồng (multi-threads) nên sẽ tăng tốc độ xử lý dữ
liệu nếu máy tính tích hợp vi xử lý đa lõi (multi-core).
3. Kết quả và ứng dụng thực tế

Hình 8. Phần mềm MobiFiltering nhận diện thư mục chứa logfile để
thực hiện pre-processing

x

21

Sau thời gian xử lý khoảng 8 phút (467,49s) phần
mềm trả về kết quả sau:
o Phát hiện 16 logfile bị trùng lặp trong tổng
số 833 files
o Thống kê tỉ lệ logfile theo dung lượng file

o
o

Đưa ra tùy chọn xóa logfile trùng lặp ‘Delete
duplicate files’
Xuất ra tên các logfile bị trùng lặp để xử lý
thêm trước khi nhập logfile vào phần mềm
phân tích xuất KPIs, số liệu.

Hình 11. Tùy chọn xóa tất cả logfile trùng lặp.

x

Kết quả sau khi xóa và thực hiện kiểm tra lại

Hình 9. Kết quả đầu ra sau khi chạy thuật toán so sánh

x

Các tên logfile bị trùng lặp có thể xuất ra file .txt để
có thể tiến hành đo lại tại các thời điểm lỗi.

x

Tùy chọn xóa các logfile bị trùng và chỉ giữ lại một
phiên bản duy nhất.

Hình 12. Các logfile đo kiểm là duy nhất sau khi xử lý

Hình 10. Danh sách các logfile bị trùng lặp.

V.

KẾT LUẬN

Bài báo đã trình bày về kỹ thuật đo kiểm Drive Test và xây
dựng thuật toán để phát triển phần mềm ứng dụng nâng cao
chất lượng đo kiểm đánh giá KPI mạng vô tuyến thông tin di
động và có thể tiền xử lý hầu hết logfile của các hệ thống máy
đo trên thế giới như TEMS, Nemo, Swissqual, QXDM, …
Nâng cao độ chính xác trong công tác đo kiểm đánh giá, báo
cáo chất lượng mạng di động là cần thiết để quá trình tối ưu
hóa vùng phủ của các nhà mạng mang lại hiệu quả; ngoài ra
với giải pháp tiền xử lý mà bài báo đề xuất giúp rút ngắn thời

22


[5]

gian, tài nguyên phần cứng xử lý dữ liệu big data theo phương
pháp cũ (post-processing) trước đây.
TÀI LIỆU THAM KHẢO
[1]

[2]

[3]

[4]

[6]

Phạm Quốc Cường, Tăng Tấn Chiến, “Nghiên cứu xây dựng phần mềm
đánh giá chất lượng mạng vô tuyến giữa các nhà mạng di động theo tọa
độ địa lý” Tạp chí Khoa học Công nghệ - Đại học Đà Nẵng, vol. 17, no.
5, pp. 30-34, Aug. 2019.
Cục Viễn thông, “QCVN36:2015/BTTTT – Quy chuẩn kỹ thuật Quốc
gia về chất lượng dịch vụ điện thoại trên mạng viễn thông di động mặt
đất” Bộ Thông tin và Truyền thông, 2015.
Cục Viễn thông, “QCVN81:2014/BTTTT – Quy chuẩn kỹ thuật Quốc
gia về chất lượng dịch vụ truy nhập Internet trên mạng viễn thông di
động mặt đất IMT-2000” Bộ Thông tin và Truyền thông, 2014.
Technical team, “Nemo Outdoor Product Description” Anite-Filand,
2014.

[7]

[8]

23

Tito Yuwono, Fitrah Ferdiyanto, “RF measument and analysis of 2G
GSM network performance case study: Yogyakarta Indonesia”, 2015
IEEE 3rd International Conference on Smart Instrumentation,
Measurement and Applications (ICSIMA), 2015.
Jelena Sokic, Marija Vucicevic, Mladen Koprivica, Aleksanda
Neskovic, “Comparative analysis of UMTS signal quality of mobile

operators”,
2011 19thTelecommunications Forum (TELFOR)
Proceedings of Papers, IEEE, 2011.
He Xian, Wu Muqing, MiaoJiansong, Zhang Cunyi, “The impact of
channel environment on the RSRP and RSRQ measument of handover
performance”, 2011 International Conference on Electronics,
Communications and Control (ICECC), IEEE, 2011.
/>