Giám sát lưu lượng trực tiếp trên NGN
Trên hệ thống tổng đài NGN nhà cung cấp xây dựng chương trình thống kê các thông số mà NGN xử lý trong quá trình thiết lập cuộc gọi thành công cụ đo trực tiếp lưu lượng trên NGN như phần 4.3.2. đã nêụ Công cụ này dùng để giám sát QoS đối với dịch vụ điện thoại viễn thông quốc tế truyền thống. Qua nghiên cứu bản chất và cách thức của chương trình này, tiến hành thực hiện khai báo để đo trực tiếp trên NGN với các chu kỳ đo 15’ cho việc thống kê th o hướng liên lạc, 24h cho việc thống kê th o đích đến và giờ bận, hiện các chương trình đo này được sử dụng phục vụ việc giám sát của kỹ thuật viên trực ca theo dõi 24h/24h -7 ngày/tuần. Phép đo này có những ưu khuyết điểm sau:
Ưu điểm: số liệu lấy trực tiếp từ tổng đài nên nhanh và chính xác. Số liệu tự động phun ra màn hình alarm consol và ghi vào tệp th o định dạng tên và đường dẫn quy định giúp dễ dàng tra cứụ Các tham số đo như LOAD, BLO LI, C%ANS … giúp cho trực ca dễ nhận biết vấn đề ảnh hưởng đến QoS.
Khuyết điểm: màn hình alarm consol ngoài việc nhận số liệu đo traffic còn nhận các số liệu cảnh báo khác do đó cũng sẽ bất tiện khi có quá nhiều cảnh báo cùng xuất rạ Kết quả đo xuất ra mỗi 15’ th o dạng t xt nên khó giám sát sự thay đổi và việc tìm số liệu cũng mất thời gian hơn nữa nếu muốn biết số liệu th o giờ hay khoảng thời gian lớn hơn thì phải thực hiện tính bằng taỵ
Giải pháp: Do kết quả đo xuất ra đều có định dạng cụ thể nên có thể viết phần mềm thống kê, tra cứu, vẽ đồ thị và báo cáo phục vụ công tác giám sát chất lượng mạng và dịch vụ. Ngoài những số liệu có trong phép đo có thể thêm vào những trường mang tính chất diễn giải dễ hiểu liên quan như tên đối tác, điểm báo hiệu tương ứng chẳng hạn, cũng có thể thay tên trường bằng những tên thường dùng (thay ATB bằng cong tion, CCU bằng số cuộc thất bại…). Có thể lựa chọn số liệu cho các báo cáo khác nhau phục vụ công việc như báo cáo lưu lượng, báo cáo nghẽn, báo cáo nghẽn tổn thất như minh họa dưới đây
Hình 3.26. Minh họa báo cáo lưu lượng
Hình 3.27. Minh họa báo cáo nghẽn
Kết quả thực hiện: Các ca trực dựa vào kết quả đo được phát hiện sớm những hướng kết nối có tỷ lệ thành công thấp bất thường, có tỷ lệ nghẽn cao, những nước (đích đến) có tỷ lệ thành công thấp và lưu lượng bất thường báo cáo và đề xuất hướng xử lý phù hợp. Đặc biệt trong năm có những thời điểm lưu lượng phát sinh lớn bất thường như dịp Lễ Giáng sinh, Tết nguyên đán trong một khoảng thời gian nhất định như giao thừa hay Giáng sinh, để có thể nhanh chóng xác định hướng nghẽn, đích nghẽn phục vụ việc định tuyến chuyển lưu lượng hay cắt/mở kênh đáp ứng nhu cầu dịch vụ của khách hàng.
Giám sát QoS trên số liệu cước
Số liệu cước mặc dù do NGN xuất ra nhưng được truyền qua hình thức truyền số liệu qua s rv r cước, tại đây số liệu sẽ được chuyển sang dạng có cấu trúc tạm gọi là số liệu thô. Phải có một chương trình phần mềm khác để lọc lựa số liệu phục vụ thông kê đối soát với từng đối tác trong nước và quốc tế th o những khuôn dạng đã thống nhất trước trong hợp đồng. Phòng tin học xây dựng một số ứng dụng trong SQL cho việc các đơn vị khác muốn tham khảo số liệu cước như trình bày ở phần 4.3.3. Những ưu khuyết điểm của việc tra cứu này như sau:
Ưu điểm: số liệu cước là số liệu tương đối đầy đủ thông tin liên quan, được lưu giữ trong thời gian dài (hằng năm), được cập nhật sau mỗi 30’. Trên s rv r cước lưu giữ số liệu của toàn Công ty nên có thể tham khảo được số liệu của softswich HNI và softswich HCM. Rất hữu ích đối với trường hợp cần tra cứu chi tiết cuộc gọi nhất là từ những phản ánh của khách hàng.
Khuyết điểm: Số liệu này thuộc sự quản lý của Phòng tin học Công ty do vậy chương trình sử lý số liệu thô chỉ phục vụ cho công việc liên quan đến tính cước nên chưa đưa ra một số báo cáo chung cần thiết thường gặp phục vụ cho công tác giám sát QoS. Không tiện cho các báo cáo tổng hợp, những nhận định chung, đánh giá chung. Hơn nữa để sử dụng được thì khai thác viên cần phải biết cấu trúc câu lệnh và dạng lệnh của SQL, là phần mềm do phòng tin học sử dụng cho việc thống kê số liệụ
Giải pháp: xây dựng chương trình thống kê từ số liệu thô th o những tiêu chí yêu cầu, hiển thị trực quan dể hiểu để người dùng có thể lọc lựa th o nhu cầu của mình.
Kết quả thực hiện: Hiện nay Trung tâm viễn thông khu vực 3 đã xây dựng một chương trình xử lý số liệu cước thô phục vụ công tác giám sát QoS trên WEB. Chương trình này được đặt trên s rv r của mạng nội bộ nên nhiều bộ phận liên quan có thể truy cập vào tra cứu những số liệu liên quan cần thiết đến phần công việc của họ.
Hình 3.30. Màn hình chính của chương trình QoS
Chương trình này giám sát nhiều loại lưu lượng và có phần riêng cho NGN
Hình 3.31. Phần giám sát cho NGN
Có thể lọc lựa th o Rout (hướng định tuyến), th o Provinc (tỉnh/thành phố), th o Cari r (đối tác) hay kết hợp th o Rout -Country (hướng định tuyến và nước). Tất cả các nhánh này đều có thể đưa các tiêu chí lọc lựa th o thời gian (từ giờ/ngày/tháng/năm đến giờ/ngày/tháng/năm), th o chiều dịch vụ (ĐẾN/ĐI/ALL), th o dịch vụ (IĐ/VOIP/ALL), th o tổng đài (HNI/HCM), th o hướng định tuyến (tên rout /tên đối tác), th o vùng lưu lượng (HANOI/DANANG/HCM), theo Cause code (mã lỗi được quy định của ITU) ngoài ra còn có tiêu chí phụ như số lượng cuộc gọi phải lớn hơn bao nhiêu cuộc và th o dải CIC quy định cho từng Trung tâm.
Từ số liệu CRD thô xây dựng bộ tiêu chí lọc đánh giá chất lượng dịch vụ để đưa ra danh sách cần lưu ý (gọi là black list). Danh sách này được hiển thị th o tỉnh, th o nước liên lạc và th o đối tác (chiều đi/chiều đến) như minh họa dưới đây:
Hình 3.33. Danh sách các nước cần lưu ý QoS
Hình 3.34. Danh sách các đối tác(chiều đi) cần lưu ý QoS
Hình 3.35. Danh sách các đối tác (chiều đến) cần lưu ý QoS
Nếu số liệu nằm dưới ngưỡng của bộ tiêu chí thì sẽ được bôi màu đỏ gây sự chú ý cho kỹ thuật viên. Tùy th o phân loại phản ánh trên black list sẽ tra tìm lọc lựa th o Rout (hướng định tuyến), th o Provinc (tỉnh/thành phố), th o Cari r (đối tác) hay kết hợp th o Rout -Country (hướng định tuyến và nước) để có thông tin chi tiết cho những bước tiếp th ọ
Ví dụ th o bảng trên TLTC đi Itaty qua hướng PRPFTFO là 20.1%, lọc lựa th o Route-Country hiển thị tất cả các lỗi (caus cod ) xảy ra như sau:
Hình 3.36. Số liệu và đồ thị chi tiết nguyên nhân thất bại các cuộc gọi đi Itaty qua hướng PRPFTFO
Nguyên nhân thất bại tập trung vào mã lỗi 3 (no route to destination) 51.71% và 16 (normal call cl aring) 40.11%. Mã 16 hầu như là cuộc gọi kết thúc th o cách thông thường không có lỗi kỹ thuật. Mã lỗi 3 phản ánh nghẽn đầu ra đến Italy qua đối tác
PRPFTF. Bước tiếp th o là tra cứu số liệu cước chi tiết về loại cuộc gọi này trên SQL, thống kê lựa lọc những thông tin cần thiết như A-number, B-number, starttime, cause cod … để gởi cho đối tác xử lý. Không phải trường hợp cũng dễ dàng tìm được nguyên nhân và xử lý được chúng ngay, cũng có trường hợp đối tác gởi caus cod về không đúng gây mất nhiều thời gian xử lý.
Ngoài ra từ những nguồn thông tin khác nhau cũng có thể chọn lựa số liệu lọc lựa th o hướng kết nối, th o nước liên lạc, th o đối tác hay th o tỉnh/thành phố để truy tìm nguyên nhân ảnh hưởng đến chất lượng dịch vụ. Một số hình ảnh minh họa số liệu được lọc lựa như sau:
Thống kê dịch vụ IĐ&VOIP từ thuê bao Mobiphon ngày 2/5/2013 hiển thị th o hướng định tuyến rạ
Hình 3.37. Kết quả thống kê cuộc gọi xuất phát từ VMS sử dụng dịch vụ IĐ&VOIP ngày 2/5/2013
Thống kê nguyên nhân thất bại ngày 2/5/2013 th o các tiêu chí ở hình 4.37
Hình 3.39. Ý nghĩa của các nguyên nhân thất bại theo ITU Q.850
Hình 3.40. Đồ thị phân nhóm nguyên nhân thất bại
Tra cứu số liệu dưới hình thức bảng biểu hay đồ thị, dựa vào danh sách cần chú ý của “black list” các kỹ thuật viên nhanh chóng nhận định các hướng kết nối, các đích đến, các điểm xuất cần tra cứu chi tiết để xác định nguyên nhân bất thường gây ảnh hưởng đến chất lượng dịch vụ, từ đó sẽ thực hiện việc xử lý tùy trường hợp để giải quyết đ m đến cho khách hàng một chất lượng dịch vụ tối đa có thể được.
Hiện nay mạng báo hiệu của VNPT được quy hoạch tập trung vào hệ thống Standalone STP theo 2 phân cấp quốc tế và quốc nộị Việc quy hoạch này giúp gỡ bỏ cách nối mạng báo hiệu kiểu mạng nhện trước kia, mỗi khi mở kênh mạch với bất kỳ đối tác nào cũng đều phải đấu nối kênh báo hiệu với đối tác đó. Hiện nay quy hoạch tập trung các đối tác trong nước chỉ cần đấu kênh báo hiệu lên STP quốc nội là có thể được kết nối với tất cả các kênh còn lại khi có nhu cầu, tương tự với các đối tác quốc tế.
Hình 3.41. Sơ đồ tổng quát mạng báo hiệu của VNPT-I
Hình 3.43. Sơ đồ kết nối báo hiệu với VMS
Hình 3.44. Sơ đồ kết nối báo hiệu với VTN
Hình 3.45. Sơ đồ kết nối cho việc truy cập chương trình AIS-STP của VNPT-I
Dùng chương trình AIS-STP của nhà cung cấp thiết bị TEKELEC-USA để bắt bản tin trực tiếp hay tìm bản tin trong thời gian trước đó trên hệ thống STP1&2. Chương trình này có những ưu khuyết điểm sau:
Ưu điểm: có thể đo được báo hiệu toàn trình cho một cuộc gọi thay vì phải đo hai chặng: trong nước và quốc tế riêng như mô hình cũ. Có thể bắt bản tin r altim . Có thể tra cứu lại các bản tin trong thời gian trước.
Khuyết điểm: Thời gian lưu bản tin chỉ được 15 ngày trong khi yêu cầu của việc giám sát QoS đôi khi cần lâu hơn. Do mô hình mạng STP quốc tế chỉ đặt tại Hà nội và TP HCM nên tại Đà nẵng muốn vào chương trình AIS STP phải truy cập qua mạng Int rn t do đó tốc độ truy cập và truy xuất số liệu phụ thuộc vào tốc độ mạng int rn t.
Giải pháp: nâng cấp khả năng lưu trữ số liệu lên 45 ngàỵ Đấu chuyển kết nối cho mạng TT3 có thể truy xuất dữ liệu qua DCN.
Kết quả thực hiện: việc tra cứu trên STP không chỉ có được những dữ liệu như trên CDR mà còn có cả những tham số chi tiết được khai báo trong tổng đài do đó vô cùng hữu ích khi tra cứu, tuy nhiên do dữ liệu rất chi tiết nên số lượng dữ liệu lớn do đó công cụ này chỉ dùng trong trường hợp khi các công cụ khác không tìm ra nguyên nhân hoặc dùng để phối hợp với đối tác khi nguyên nhân tìm được liên quan đến những tham số được khai báo trong tổng đàị
Giám sát trên IP core Phép đo trễ trên IP CORE
Kết quả thực hiện: Sử dụng lệnh trên rout r cor để đo roundtrip th o sơ đồ trong phần 3.3.1. kết quả như sau:
Bảng 3.1. Kết quả đo round trip
Ngày Thời
điểm
Round Trip: ( min/avg/max) ms
Ngưỡng (ms) Lunex(8.26.87.227) CHT- I(220.128.58.242) TSC(10.10.10.3) 2/2/2013 21h 208/212/228 84/96/140 196/198/200 300 2/3/2013 7h 204/206/208 84/84/88 192/195/196 300 2/4/2013 10h00 204/208/212 88/89/92 200/201/204 300 6/19/2013 11h 220/223/228 64/64/68 208/208/208 300 6/19/2013 14h 212/219/228 56/59/60 208/208/208 300 6/19/2013 16h 212/217/224 60/60/64 208/210/220 300 6/20/2013 9h 212/220/224 64/64/68 208/208/208 300 6/20/2013 10h00 220/221/228 64/64/68 208/208/212 300 6/20/2013 11h 212/226/240 64/65/68 208/208/208 300 6/20/2013 13h 212/214/220 60/62/64 208/208/212 300 6/23/2013 21h 212/219/232 64/66/68 208/208/208 300 6/23/2013 23h 188/194/200 64/66/68 208/208/212 300 6/24/2013 3h 216/218/220 64/66/68 208/208/212 300 6/24/2013 4h 212/220/228 64/66/68 208/208/208 300 6/26/2013 23h 184/192/196 64/64/68 208/208/208 300 6/27/2013 2h 192/196/200 64/67/76 208/208/208 300 6/27/2013 4h 188/194/200 64/64/68 208/208/208 300
Hình 3.46. Đồ thị minh họa kết quả đo đối với đối tác Lunex
Hình 3.47. Đồ thị minh họa kết quả đo đối với đối tác CHT-I
Ưu điểm: Dựa vào phép đo này để biết được thời gian trễ đối với từng đối tác có đạt hay không.
Khuyết điểm: Để giám sát thường xuyên thông số này có thể viết chương trình cho chạy lệnh này liên tục 24/24h rồi dùng phần mềm Whit sharp để bắt thông tin, tuy nhiên dữ liệu thu được là rất lớn sẽ nhanh chóng gây tràn bộ nhớ.
Kết quả thực hiện: thường chỉ sử dụng phép đo này trong trường hợp giám sát lưu lượng thấy dấu hiệu bất thường.
Nhận thấy rằng ngay cả ở giờ cao điểm thì thời gian trễ vẫn nằm trong ngưỡng cho phép. Dựa vào phép đo này để biết được thời gian trễ đối với từng đối tác có đạt hay không.
Chương trình đo PRTG Traffic grapher -Giám sát thông lượng trên IP CORE
Đây là phần mềm do nhà cung cấp thiết bị CISCO cung cấp được cài đặt đo 24/24h và 7ngày/tuần để giám sát thông lượng trên IP cor nhằm sớm phát hiện hiện tượng nghẽn, đột biến về lưu lượng trên Ip cor .
Một số kết quả đo hiển thị bằng đồ thị
Hình 3.48. Kết quả phép đo 24 giờ
Hình 3.50. Kết quả phép đo 60 phút-30giây/lần
Hình 3.51. Kết quả phép đo 356 ngày
Bảng 3.2. Dữ liệu trích ngang- phép đo24 giờ
time Traffic IN Traffic IN Traffic OUT Traffic OUT Sum Sum kbyte kbit/second kbyte kbit/second kbyte kbit/second 06/08/2013 3:10 PM - 3:15 PM 441,157.28 15,275.20 88,786.44 3,073.87 529,943.72 18,349.07 06/08/2013 3:05 PM - 3:10 PM 570,670.80 15,584.68 112,023.29 3,059.29 682,694.09 18,643.96 06/08/2013 3:00 PM - 3:05 PM 601,945.34 16,439.31 126,084.84 3,443.42 728,030.18 19,882.73 06/08/2013 2:55 PM - 3:00 PM 588,503.39 16,071.14 116,001.69 3,167.83 704,505.07 19,238.97 06/08/2013 12:20 AM - 12:25 AM 114,715.71 3,132.61 27,785.48 758.779 142,501.19 3,891.39 06/08/2013 12:15 AM - 12:20 AM 133,022.35 3,632.88 31,845.15 869.759 164,867.50 4,502.64 05/08/2013 11:55 PM - 12:00 AM 124,904.45 3,411.52 38,533.21 1,052.46 163,437.66 4,463.98 05/08/2013 11:50 PM - 11:55 PM 143,123.87 3,908.76 46,095.76 1,258.93 189,219.63 5,167.69 05/08/2013 11:45 PM - 11:50 PM 143,427.31 3,917.44 54,302.57 1,483.22 197,729.88 5,400.65 05/08/2013 11:40 PM - 11:45 PM 584,419.17 15,961.73 74,697.98 2,040.16 659,117.15 18,001.89 05/08/2013 11:35 PM - 11:40 PM 1,623,623.33 44,340.18 102,846.62 2,808.68 1,726,469.95 47,148.85
05/08/2013 11:30 PM - 11:35 PM 193,210.69 5,276.29 66,876.71 1,826.36 260,087.39 7,102.65 05/08/2013 11:25 PM - 11:30 PM 217,678.42 5,944.27 74,556.18 2,035.95 292,234.59 7,980.22 05/08/2013 10:50 PM - 10:55 PM 326,433.04 8,914.69 161,155.72 4,401.21 487,588.76 13,315.90 05/08/2013 10:20 PM - 10:25 PM 462,651.31 12,634.73 236,603.82 6,461.29 699,255.13 19,096.02 05/08/2013 10:15 PM - 10:20 PM 496,815.43 13,566.83 252,083.76 6,884.03 748,899.19 20,450.85