Tổng đài NEAX 61 SIGMA

Tên đề tài: “Xây dựng quy trình bảo dưỡng, phòng ngừa hệ thống tổng đài NEAX 61 SIGMA” .

-o0o -

ĐỀ TÀI XÂY DỰNG QUY TRÌNH BẢO DƢỠNG PHÒNG NGỪA HỆ THỐNG TỔNG ĐÀI

********

Hà Nội tháng 08 năm 2012

1.2 Bảng tổng hợp các thiết bị phần cứng cần kiểm tra

1.3 Thống kê tài nguyên hệ thống phần cứng

1.3.1 Kiểm tra số liệu hệ thống

1.3.2 Kiểm tra cấu hình, trạng thái của toàn bộ hệ thống

1.3.3 Kiểm tra số liệu trung kế dịch vụ SVT

1.3.4 Kiểm tra bộ đếm lỗi tổng đài

1.4 Kiểm tra chuẩn đoán lỗi của các khối điều khiển trong hệ

thống HOST

1.4.1 Kiểm tra khối điều khiển xử lý CP

1.4.2 Kiểm tra khối chuyển mạch TSC

1.4.3 Kiểm tra khối chuyển mạch SSC

1.4.4 Kiểm tra khối DTIC

1.4.5 Kiểm tra khối RLUIC

1.4.6 Kiểm tra khối LOC

1.4.7 Kiểm tra khối SVC

1.4.8 Kiểm tra khối MIF

1.4.9 Kiểm tra khối LDC

1.4.10 Kiểm tra khối SPCH

1.4.11 Kiểm tra khối MCLK

1.4.12 Kiểm tra khối SCC

1.4.13 Kiểm tra khối HUB

1.5 Kiểm tra các trạng thái phần cứng của vệ tinh RLU

1.5.1 Mục đích

1.5.2 Nội dung thực hiện

1.5.3 Kiểm tra khối điều khiển vệ tinh RLOC

1.5.4 Kiểm tra khối RFHC

1.5.5 Kiểm tra khối LTE

1.6 Các quy trình kiểm tra, bảo dưỡng các thiết bị bị phụ trợ

1.6.1 Thực hiện bảo dưỡng đĩa cứng (DK)

1.6.2 Thực hiện bảo dưỡng ổ băng từ (DAT)

1.6.3 Kiểm tra các thông số kỹ thuật nguồn điện và các cảnh báo

liên quan

1.6.4 Kiểm tra việc thực hiện lấy cước online (CDT)

1.6.5 Kiểm tra các trạng thái hoạt động của kết nối phần khai

2.1.3 Bảng tổng hợp cứu khối phần mềm cần kiểm tra

2.1.4 Kiểm tra phần mềm hệ điều hành của tổng đài

2.1.5 Kiểm tra phần mềm khối điều khiển chuyển mạch thời

gian (TSW)

2.1.6 Kiểm tra phần mềm khối điều khiển chuyển mạch không

gian (SSW)

2.1.7 Kiểm tra phần mềm khối điều khiển vệ tinh (RLUIC)

2.1.8 Kiểm tra phần mềm khối điều khiển trung kế số (DTIC)

2.1.9 Kiểm tra phần mềm khối điều khiển điều khiển cục bộ

(LOC)

2.1.10 Kiểm tra phần mềm vệ tinh (RLOC)

2.1.11 Kiểm tra phần mềm khối điều khiển LDC

2.1.12 Kiểm tra phần mềm khối điều RFHC

2.1.13 Kiểm tra phần mềm khối đo thử dường dây thuê bao

2.2 Quy trình nạp patch file và một số quy trình BACKUP

2.2.1 Quy trình nạp patch file theo quy trình của nhà cung cấp

thiết bị(FILE UPDATE)

2.2.2 Quy trình gỡ bỏ một patth file theo quy trình của nhà cung

cấp thiết bị

2.2.3 Tạo băng BACKUP

2.2.4 Thực hiện tạo đĩa cứng dự phòng BACKUP DK

2.2.5 Tạo băng lỗi ( FAULT) cho hãng cung cấp thiết bị

CHƯƠNG III

QUY TRÌNH PHÂN TÍCH BẢN TIN QUAN TRẮC HỆ

THỐNG NEAX 61 SIGMA

3.1 Mục Đích đo lưu lượng

3.2 Lý thuyết giám sát lưu lượng

3.3 Chức năng và các kiểu đo trong quan trắc lưu lượng của

3.4.4 Lưu lượng trung kế liên đài

3.4.5 Giám sát lưu lượng báo hiệu CCS7

3.4.6 Giám sát lưu lượng các dịch vụ gia tăng (service)

3.4.7 Giám sát lưu lượng trung kế dịch vụ RCV

3.4.8 Giám sát lưu lượng trung kế dịch vụ REG

3.4.9 Trung kế Annoucement (ANM)

3.4.10 Giám sát lưu lượng các cuộc gọi bị cấm

3.5 Khuyến nghị điều khiển lưu lượng tổng đài NEAX 61

SIGMA

3.5.1 Trạng thái bình thường

3.5.2 Trạng thái gia tăng đột biến cuộc gọi

3.5.3 Trạng thái nghẽn mạng

3.5.4 Đăng ký giám sát các cuộc gọi khó kết nối (HTR)

3.6 Tính toán bộ nhớ và xác định khả năng cung cấp dịch vụ cho

3.6.2 Tính toán bộ nhớ

3.6.3 Xác định khả năng cung cấp dịch vụ cho thuê bao

CHƯƠNG IV

KIỂM TRA, DỰ TRÙ THIẾT BỊ DỰ PHÒNG, THỰC HIỆN

BÁO CÁO ĐÁNH GIÁ HỆ THỐNG NEAX 61 SIGMA

4.1 Kiểm tra, dự trù thiết bị dự phòng

4.1.1 Mục đích

4.1.2 Nội dung thực hiện

4.1.3 Đánh giá, dự trù danh mục bổ xung

4.1.4 Báo cáo đánh giá hệ thống

4.1.5 Đánh giá về hoạt động hệ thống

4.1.6 Các giải pháp và khuyến nghị

4.1.7 Kiểm tra các tài liệu cần thiết có tại trạm

4.1.8 Kiểm tra các thiết bị phụ trợ, và môi trường

4.1.9 Các biểu mẫu cập nhật

PHỤ LỤC

Phụ lục 1: Khắc phục lỗi MIF sau khi sét đánh mà không xoá và

tạo lại DATA

Phụ lục 2: Khắc phục lỗi MIF và ALARM_BUS sau khi bị sét

đánh bằng cách tạo xóa lại DATA

Phụ lục 3: Xử lý lỗi HUB

Phụ lục 4: Khắc phục lỗi SVC sau khi tổng đài bị sét đánh

Phụ lục 5: Vệ sinh các card tại vệ tinh

Phụ lục 6: Truy nhập DK hệ thống bằng giao diện GUI

Phụ lục 7: Các công việc bảo dưỡng phòng ngừa theo thời gian

Phụ lục 8: Tổng quan hệ thống NEAX 61 Sigma

Phụ lục 9: Cấu trúc phần mềm tổng đài NEAX 61SIGMA

Phụ lục 10: Tài liệu tham khảo

MỤC LỤC HÌNH VẼ

Trang

cước online CDT (charg data tranfer)

26

lượng cuộc gọi (EQT)

45

lượng trung kế liên đài (RUTS)

47

lượng CCS7

Bảng 3.7 Các tham số và ý nghĩa của kết quả quan trắc lưu

lượng CCS7

48

Bảng 3.10 Các tham số và ý nghĩa của kết quả quan trắc lưu

lượng tự động

52

Bảng 3.14 Các tham số và ý nghĩa của cấm cuộc gọi ra

Bảng 3.17 Các tham số và ý nghĩa của kết quả giám sát các cuộc

gọi khó kết nối(HTR)

58

Bảng 3.18 Mô tả cách tính dung lượng bộ nhớ đã chiếm dụng

trên CP của một tổng đài cụ thể

61

Bảng 3.19 Mô tả khả năng chiếm bộ nhớ của từng loại hình dịch

vụ

64

thời gian hệ thống NEAX 61 Sigma

89

CÁC THUẬT NGỮ TIẾNG ANH VIẾT TẮT

DTIM Module giao tiếp truyền dẫn số

O&M Phân hệ khai thác và bảo dƣỡng

RLUIC Bộ điều khiển giao tiếp vệ tinh

Việc nghiên cứu, xây dựng quy trình bảo dưỡng, phòng ngừa hệ thống NEAX

61 SIGMA để kỹ thuật viên trong Viễn thông Hà nội thực hiện là công việc cần thiết

và có nhiều lợi ích sau:

- Sớm phát hiện các lỗi, nguy cơ có thể gây ảnh hưởng đến chất lượng thông tin của hệ thống

- Các quy trình bảo dưỡng, phòng ngừa được mở rộng thêm nhiều hơn về các thiết bị kiểm tra phần cứng, phần mềm, dịch vụ cần kiểm tra

- Qua các đợt bảo dưỡng sẽ đưa ra các đánh giá về chất lượng hệ thống, xử lý các lỗi có trong hệ thống, tối ưu hoá tài nguyên hệ thống

- Nâng cao trình độ chuyên môn, trách nhiệm trong công việc đối với đội ngũ

kỹ thuật viên khai thác hệ thống

- Tiết kiệm chi phí, nâng cao hiệu quả kinh doanh cho Viễn thông Hà Nội trong việc thuê khoán bảo dưỡng hệ thống NEAX 61 Sigma đến thời điểm tháng 7 năm

2012 khoảng 48.000 số (với chi phí bảo dưỡng hàng năm là 1USD/line ) ≈ 48.000 USD /năm

Tuy nhiên trong quá trình biên soạn nhóm biên soạn không thể có những thiếu sót Vậy rất kính mong sự đóng góp của lãnh đạo các cấp, các phòng ban trong công

ty, Viễn thông Hà Nội có đóng góp để đề tài này hoàn thiện và có áp dụng thực tế cao nhất

Hà nội, ngày 10 tháng 07 năm 2012

CHƯƠNG I QUY TRÌNH KIỂM TRA THIẾT BỊ PHẦN CỨNG

- Đưa ra các khuyến nghị, điều kiện chuẩn bị trước khi chuẩn đoán (DGT) Tập hợp các bảng biểu báo cáo kiểm tra các thiết bị phần cứng làm cơ sở đánh giá về chất lượng thiết bị

- Liệt kê đánh giá tổng quan cấu hình hệ thống, thực hiện tối ưu hoá hệ thống trong việc quy hoạch lại phần cứng đảm bảo các hiệu quả trong khai thác (mở rộng cấu hình, thay đổi cấu hình, tối ưu hoá tài nguyên của thiết bị )

- Không nên dùng lệnh chuyển đổi tất cả các thiết bị logic phần cứng cùng một khối

điều khiển về chế dộ Active (ACT) theo các lệnh sau (vì rất dễ xảy ra xung đột khi có

một thiết bị lỗi, dẫn đến lỗi điều khiển toàn bộ các trạm điều khiển khác):

Trong đó x: chỉ số thiết bị của khối điều khiển (0 hoặc 1)

- Out of service thiết bị của thiết bị cần chuẩn đoán (DGT) sau đó DGT thiết bị

- Kiểm tra các bản tin lỗi để tìm ra hư hỏng (tra cứu theo tài liệu OUTPUT MANUAL và bảng lỗi INDEX )

- In service thiết bị sau khi đã chuẩn đoán xong

- Khi thay thế Card cần kiểm tra loại card, version, các switch, firmware đảm bảo phù hợp, tương thích với Card thay thế

- Khi thực hiện các quy trình đặc biệt cần phải thông báo và được sự đồng ý của người quản lý kỹ thuật của hệ thống theo chức năng được phân cấp

- Kết qủa thực hiện các quy trình phải được ghi chép sổ sách, cập nhật số liệu cẩn thận

1.2 BẢNG TỔNG HỢP CÁC THIẾT BỊ PHẦN CỨNG CẦN KIỂM TRA

STT TÊN KHỐI

XỬ LÝ

4 DTIC Khối điều khiển truyền dẫn số

5 RLUIC Khối điều khiển giao tiếp vệ tinh

7 SVC Bộ điều khiển giám sát

8 MIF Giao điện khai thác bảo dưỡng

11 MCLK Điều khiển đồng hồ trung tâm

12 SCC Bộ điều khiển giao diện hệ thống máy tính nhỏ

13 HUB Bộ chuyển mạch tốc độ cao HUB

14 RLOC Khối điều khiển vệ tinh

15 RFHC Bộ điều khiển thuê bao số tại vệ tinh

16 LTE Thiết bị Test đường dây thuê bao

Bảng 1.1 Tổng hợp các khối phần cứng cần bảo dưỡng

1.3 THỐNG KÊ TÀI NGUYÊN HỆ THỐNG PHẦN CỨNG:

Mục đích: Việc kiểm tra tài nguyên phần cứng giúp ta phát hiện sớm những lỗi thiết

bị, số liệu sai sót trong quá trình khai thác bảo dưỡng, dẫn đến số liệu thiếu hoặc thừa gây ảnh hưởng đến tính cước, chất lượng mạng Qua đó đánh giá hiệu năng, cấu hình của hệ thống để tối ưu hoá tài nguyên

1.3.1 Kiểm tra số liệu hệ thống:

- Kiểm tra số liệu thao tác các dịch vụ gia tăng:

>view cscall (kiểm tra năng lực xử lý link báo hiệu)

- Kiểm tra số liệu trung kế TRK:

# lan line state #

dev=cp00-lan0 st=ins(slv) md=nrm ldv=cp00-llan0

# hub state #

dev=hub sys_0=act sys_1=sby md=dlm

dev=hub0 sys_0=act sys_1=sby md=dlm type=ase0

sys_0=act sys_1=sby md=dlm

# sw state #

dev=sw sys_0=sby sys_1=act md=dlm

# tsw state #

dev=tsw00 sys_0=sby sys_1=act md=dlm

dev=tsw01 sys_0=sby sys_1=act md=dlm

# ssw state #

dev=ssw0 sys_0=sby sys_1=act md=dlm

# dtic state #

dev=dtic0000 sys_0=act sys_1=sby md=dlm

dev=dtic0001 sys_0=act sys_1=sby md=dlm

# loc state #

dev=loc0002 sys_0=act sys_1=sby md=dlm

dev=loc0012 sys_0=act sys_1=sby md=dlm

# rluic state #

dev=rluic0005 sys_0=sby sys_1=act md=dlm

dev=rluic0009 sys_0=act sys_1=sby md=dlm

# rloc unit state #

dev=rloc0024(18) ofn=trunggia inst_sac=on

dev=lte0002 sys_0=ins sys_1= - md= -

dev=lte0012 sys_0=ins sys_1= - md= -

dev=lte0024(18) sys_0=ins sys_1= - md= -

dev=cp00-csc001 sys_0=ins sys_1= - md= - dti=dti000110

kind_lk=0000

# lapdc state #

dev=ldc000200 sys_0=ins sys_1= - md= -

dev=ldc000201 sys_0=sby sys_1= - md= -

# rfhc state #

dev=rfhc002400 sys_0=ins sys_1= - md= -

dev=rfhc002401 sys_0=sby sys_1= - md= -

07/12/12_08:26:02 PHULO sigma103

view eqp end

Trạng thái ins, act là trạng thái hoạt động, trạng thái sby là trạng thái dự phòng của các phần điều khiển Trạng thái md=dlm, nrm là trạng thái hoạt động tốt mặt logic hoạt động và dự phòng của các phần điều khiển Trạng thái md= - là trạng thái các thiết bị hoạt động không có chế độ dự phòng

1.3.3 Kiểm tra số liệu trung kế dịch vụ SVT

Mục đích: Trung kế dịch vụ SVT gồm rất nhiều chức năng quan trọng trong tổng đài nhƣ cấp các dịch vụ gia tăng, TONE, âm thông báo (ANM), thu nhận tín hiệu quay số (SND/RCV), Việc kiểm tra số liệu trung kế dịch vụ ở tổng đài HOST và vệ tinh giúp phát hiện những sai sót, hƣ hỏng, số lƣợng trung kế dịch vụ hiện có qua đó có thể sửa chữa, mở rộng, tháo bỏ thêm trung kế dịch vụ giúp việc quản lý tài nguyên, thiết bị đƣợc tối đa hoá nhất, phòng ngừa các hƣ hỏng hiện có có thể gây mất ổn định về dịch

vụ cũng nhƣ chất lƣợng cuộc gọi

Nội dung thực hiện:

- Kiểm tra số lƣợng và trạng thái các card âm thông báo (ANM):

+ Card âm thông báo tại HOST:

>view anm st + Card âm thông báo tại vệ tinh:

>view anm st rlu=c1-c8

Trong đó c1-c8: tên trạm vệ tinh

- Kiểm tra số lƣợng và trạng thái các card tone (TONE):

+ Card TONE tại host:

>view tone st + Card TONE vệ tinh:

>view tone st rlu=c1-c8

Trong đó c1-c8: tên trạm vệ tinh

- Kiểm tra số lượng và trạng thái các card receiver(RCV):

+ Card Receiver tại host:

>view reg st all

+ Card Receiver tại vệ tinh:

>view reg st rlu=c1-c8

Trong đó: c1-c8: tên trạm vệ tinh

- Kiểm tra số lượng và trạng thái card hiển thị số(CLIP):

>view reg st all

- Kiểm tra số lượng và trạng thái các kênh thoại 3 bên (three way calling):

+ Kiểm tra xác định route name khai báo cho các kênh thoại 3 bên:

>view trk st smr

+ Kiểm tra kênh thoại ba bên:

>view trk st rn=c1-c8

Trong đó: c1-c8: tên đặt cho route name thoại 3 bên

1.3.4 Kiểm tra bộ đếm lỗi tổng đài

>view ercnt

1.4 KIỂM TRA CHUẨN ĐOÁN LỖI CỦA CÁC KHỐI ĐIỀU KHIỂN TRONG HỆ THỐNG HOST

1.4.1 Kiểm tra khối điều khiển xử lý CP

Mục đích: Đây là trung tâm giám sát và điều khiển của toàn bộ hệ thống Vì vậy muốn mọi hoạt động của hệ thống được liên tục và ổn định thì chúng ta phải thường xuyên kiểm tra, giám sát, phát hiện sớm lỗi và tìm cách khắc phục kịp thời Phân hệ xử lý bao gồm 4 bộ xử lý:

- Bộ xử lý cuộc gọi (CLP) làm nhiệm vụ xử lý các cuộc gọi của tổng đài

- Bộ xử lý quản lý tài nguyên (RMP) làm nhiệm vụ điều khiển chia sẻ tài nguyên cho toàn hệ thống

- Bộ xử lý báo hiệu kênh chung (CSP) thực hiện truyền kết hợp mức 3 của hệ thống báo hiệu kênh chung

- Bộ xử lý vận hành bảo dưỡng (OMP) giám sát việc vận hành bảo dưỡng của hệ thống

Nội dung thực hiện:

Lệnh thực hiện:

>chg cpDD chuyển trạng thái mặt Logic nếu có lỗi phải xử lý xong mới DGT

>ous cpDD-cpi (Out of service mặt Logic thiết bị cần chuẩn đoán)

>dgt exec cpDD-cpi disp=dtl (chuẩn đoán lỗi)

> ins cpDD-cpi (inservice lại thiết bị)

Trong đó DD: chỉ số của CP cần kiểm tra (00,01…)

i: chỉ số thiết bị 0 hoặc 1 của cp cần kiểm tra

- Kết quả chuẩn đoán sẽ chỉ ra kết quả của thiết bị (tốt hoặc bản tin lỗi cụ thể)

Khuyến nghị: Phân tích các lỗi theo hướng dẫn sách OUTPUT MANUAL, bảng tra cứu lỗi INDEX để xử lý theo quy trình

1.4.2 Kiểm tra khối chuyển mạch thời gian TSC

Mục đích:

Phân hệ chuyển mạch bao gồm một mạng phân chia thời gian và bộ điều khiển khối thoại Mạng phân chia thời gian thực hiện việc chuyển mạch thời gian (TSW) và chuyển mạch không gian (SSW) tín hiệu thoại, còn bộ điều khiển khối thoại thì điều khiển TSW và SSW theo bản tin điều khiển từ CLP thông qua HUB Vì vậy việc kiểm tra, giám sát thường xuyên sẽ làm giảm nguy cơ mất thông tin liên lạc, ảnh hưởng chất lượng cuộc gọi

Nội dung thực hiện:

Lệnh thực hiện:

>chg swi (chuyển trạng thái mặt Logic nếu có lỗi phải xử lý xong mới DGT)

>ous swi (out of service mặt Logic thiết bị cần chuẩn đoán)

>dgt exec swi disp=dtl (chuẩn đoán lỗi)

>ins swi (inservice lại thiết bị)

Trong đó i: chỉ số của chuyển mạch cần kiểm tra (0,1,2,3)

- Kết quả chuẩn đoán sẽ chỉ ra kết quả của thiết bị (tốt hoặc bản tin lỗi)

Khuyến nghị: Phân tích các lỗi theo hướng dẫn sách OUTPUT MANUAL, bảng tra cứu lỗi INDEX để xử lý theo quy trình

1.4.3 Kiểm tra khối chuyển mạch không gian SSC

Mục đích:

Phân hệ chuyển mạch bao gồm một mạng phân chia thời gian và bộ điều khiển khối thoại Mạng phân chia thời gian thực hiện việc chuyển mạch thời gian (TSW) và chuyển mạch không gian (SSW) tín hiệu thoại, còn bộ điều khiển khối thoại thì điều khiển TSW và SSW theo bản tin điều khiển từ CLP thông qua HUB Vì vậy việc kiểm tra, giám sát thường xuyên sẽ làm giảm nguy cơ mất thông tin liên lạc, ảnh hưởng chất lượng cuộc gọi

Nội dung thực hiện:

Lệnh thực hiện:

>chg swi (chuyển trạng thái mặt Logic nếu có lỗi phải xử lý xong mới DGT)

>ous swi (out of service mặt Logic thiết bị cần chuẩn đoán)

>dgt exec swi disp=dtl (chuẩn đoán lỗi)

>ins swi (inservice lại thiết bị)

Trong đó i: chỉ số của chuyển mạch cần kiểm tra (0,1,2,3)

>Kết quả chuẩn đoán sẽ chỉ ra kết quả của thiết bị (tốt hoặc bản tin lỗi)

Khuyến nghị: Phân tích các lỗi theo hướng dẫn sách OUTPUT MANUAL, bảng tra cứu lỗi INDEX để xử lý theo quy trình

1.4.4 Kiểm tra khối DTIC

Mục đích:

DTIC là khối điều khiển trung kế liên đài và các trung kế dịch vụ Việc bảo dưỡng, phát hiện các lỗi của hệ thống sẽ giảm thiểu các nguy cơ mất đường truyền, link báo hiệu và đảm bảo các dịch vụ cho hệ thống

Nội dung thực hiện:

>chg dticjklm (chuyển trạng thái mặt Logic nếu có lỗi phải xử lý xong mới DGT)

>ous dticijklm (out of service mặt Logic thiết bị cần chuẩn đoán)

>dgt exec dticijklm disp=dtl (chuẩn đoán lỗi)

>ins dticijklm (inservice lại thiết bị)

Trong đó i: chỉ số sys 0 hoặc 1 của thiết bị

1.4.5 Kiểm tra khối RLUIC

Mục đích:

RLUIC là khối điều khiển vệ tinh, việc bảo dƣỡng, phát hiện các lỗi của hệ thống sẽ giảm thiểu các nguy cơ mất an toàn thông tin cho các vệ tinh

Nội dung thực hiện:

>chg rluicjklm (chuyển trạng thái mặt Logic nếu có lỗi phải xử lý xong mới DGT)

>ous rluicijklm (out of service mặt Logic thiết bị cần chuẩn đoán)

>Lệnh: dgt exec rluicijkl disp=dtl (chuẩn đoán lỗi)

>ins rluicijklm (inservice lại thiết bị)

Trong đó i: chỉ số sys 0 hoặc 1 của thiết bị

>chg locjklm(chuyển trạng thái mặt Logic nếu có lỗi phải xử lý xong mới DGT)

>ous locijklm (out of service mặt Logic thiết bị cần chuẩn đoán)

>dgt exec locijklm disp=dtl (chuẩn đoán lỗi)

>ins locijklm (inservice lại thiết bị)

Trong đó i: chỉ số sys 0 hoặc 1 của thiết bị

SVC có chức năng giám sát các bộ xử lý, giám sát các lỗi của hệ thống gửi đến CP, khởi động lại tổng đài khi phát hiện lỗi nghiêm trọng Nên cần chuẩn đoán lỗi, phát hiện, sửa chữa ngăn ngừa nguy cơ lỗi

Nội dung thực hiện:

>chg svc (chuyển trạng thái mặt Logic nếu có lỗi phải xử lý xong mới DGT)

>ous svci (out of service mặt Logic thiết bị cần chuẩn đoán)

>dgt exec svci disp=dtl (chuẩn đoán lỗi)

>ins svci (inservice lại thiết bị)

Trong đó i: chỉ số của SVC cần kiểm tra (0,1)

- Kết quả chuẩn đoán sẽ chỉ ra kết quả của thiết bị (tốt hoặc bản tin lỗi)

Khuyến nghị: Phân tích các lỗi theo hướng dẫn sách OUTPUT MANUAL, bảng tra cứu lỗi INDEX để xử lý theo quy trình

1.4.8 Kiểm tra khối MIF

Mục đích:

Khối MIF là khối giao tiếp bảo dưỡng có chức năng thu thập các cảnh báo của hệ thống, và thực hiện kết nối RS232 cho khởi động lại tổng đài (phase) ở mức cao nhất (phase 3) Nên việc bảo dưỡng, kiểm tra kết nối có ý nghĩa rất quan trọng, đảm bảo cho việc xử lý, khai thác khi có sự cố khẩn cấp xảy ra

Nội dung thực hiện:

Lệnh thực hiện:

>ous mifi (out of service mặt Logic thiết bị cần chuẩn đoán)

>dgt exec mifi disp=dtl (chuẩn đoán lỗi)

>ins mifi (inservice lại thiết bị)

Trong đó i: chỉ số của MIF cần kiểm tra (0,1…)

- Kết quả chuẩn đoán sẽ chỉ ra kết quả của thiết bị (tốt hoặc bản tin lỗi)

Khuyến nghị: Phân tích các lỗi theo hướng dẫn sách OUTPUT MANUAL, bảng tra cứu lỗi INDEX để xử lý theo quy trình

1.4.9 Kiểm tra khối LDC

Mục đích:

Khối LDC điều khiển khối điều khiển kênh D ở tại HOST Việc bảo dưỡng thường xuyên các khối LDC giúp cho việc kết nối các thuê bao số quan trọng sử dụng các dịch vụ 2B+D, 30B+D được ổn định Đảm bảo chất lượng cuộc gọi

Nội dung thực hiện:

>ous ldcijklmn (out of service mặt Logic thiết bị cần chuẩn đoán)

>dgt exec ldcijklmn disp=dtl (chuẩn đoán lỗi)

>ins ldcijklmn (inservice lại thiết bị)

- Dựa vào kết quả chuẩn đoán để phân tích sự hoạt động và các lỗi của hệ thống

Nội dung thực hiện:

>chg cpDD-spch (chuyển trạng thái mặt Logic nếu có lỗi phải xử lý xong mới

DGT)

>ous cpDD-spchi (out of service mặt Logic thiết bị cần chuẩn đoán)

>dgt exec cpDD-spchi disp=dtl (chuẩn đoán lỗi)

>ins cpDD-spchi (inservice lại thiết bị)

- Dựa vào kết quả chuẩn đoán để phân tích sự hoạt động và các lỗi của hệ thống

Nội dung thực hiện:

>chg mclk (chuyển trạng thái mặt Logic nếu có lỗi phải xử lý xong mới DGT)

>ous mclki (out of service mặt Logic thiết bị cần chuẩn đoán)

>dgt exec mclki disp=dtl (chuẩn đoán lỗi)

>ins mclki (inservice lại thiết bị)

- Dựa vào kết quả chuẩn đoán để phân tích sự hoạt động và các lỗi của hệ thống

Nội dung thực hiện:

>ous scci (out of service mặt Logic thiết bị cần chuẩn đoán)

>dgt exec scci disp=dtl (chuẩn đoán lỗi)

>ins scci (inservice lại thiết bị)

- Dựa vào kết quả chuẩn đoán để phân tích sự hoạt động và các lỗi của hệ thống

>chg hub (chuyển trạng thái mặt Logic nếu có lỗi phải xử lý xong mới DGT)

>ous hubi (out of service mặt Logic thiết bị cần chuẩn đoán)

>dgt exec hubi disp=dtl (chuẩn đoán lỗi)

>ins hubi (inservice lại thiết bị)

- Dựa vào kết quả chuẩn đoán để phân tích sự hoạt động và các lỗi của hệ thống

1.5.2 Nội dung thực hiện

- Kiểm tra tiếp đất, hệ thống cung cấp nguồn, môi trường

- Vệ sinh các card của vệ tinh mỗi 1 năm 1 lần (tham khảo phụ lục 5)

- Kiểm tra trung kế PCM HOST-Vệ tinh, đánh giá báo cáo lưu lượng

- Kiểm tra hệ thống quạt làm mát bằng cách rút ra vệ sinh bằng hút bụi, nếu có hỏng hóc cần thay thế

- Kiểm tra các lưói lọc bụi tại các giá máy, vệ sinh sạch sẽ

- Kiểm tra các cảnh báo ngoài cơ bản: cảnh báo nguồn điện, cảnh báo cháy, nhiệt độ phòng, nguồn ACCU

- Kiểm tra các kết nối PCM và đánh giá lưu lượng HOST-RLU để thực hiện mở rộng hay bớt đi thiết bị PCM

- Liệt kê phân tích các lỗi của hệ thống

- TEST các chức năng của vệ tinh theo quy trình TEST vệ tinh

1.5.3 Kiểm tra khối điều khiển vệ tinh RLOC

Mục đích:

Kiểm tra chuẩn đoán lỗi của điều khiển vệ tinh (RLOC) để đảm bảo cho thuê bao hoạt động ổn định, liên tục, không để xảy ra tình trạng rớt cuộc gọi, không kết nối được , phát hiện kịp thời các lỗi tích tụ, hiện có để đưa ra các phương án sửa chữa lỗi

Nội dung thực hiện:

>chg rlocjklm (chuyển trạng thái mặt Logic nếu có lỗi phải xử lý xong mới DGT)

>ous rlocijklm (out of service mặt Logic thiết bị cần chuẩn đoán)

>dgt exec rlocijknm disp=dtl (chuẩn đoán lỗi)

>ins rlocijklm (inservice lại thiết bị)

Trong đó i: chỉ số sys 0 hoặc 1 của thiết bị

Nội dung thực hiện:

>ous rfhcijklmn (out of service mặt Logic thiết bị cần chuẩn đoán)

>dgt exec rfhcijklmn disp=dtl (chuẩn đoán lỗi)

>ins rfhcijklmn (inservice lại thiết bị)

>Dựa vào kết quả chuẩn đoán để phân tích sự hoạt động và các lỗi của hệ thống

Khối LTE thực hiện nhiệm vụ đo, kiểm tra chất lượng thuê bao của toàn bộ tổng đài

Vì vậy việc kiểm tra thường xuyên khối LTE giúp cho việc đo quét các thông số thuê bao toàn tổng đài được ổn định và chính xác

Nội dung thực hiện:

>ous ltejklm (out of service mặt Logic thiết bị cần chuẩn đoán)

>dgt exec ltejklm disp=dtl (chuẩn đoán lỗi)

>ins ltejklm (inservice lại thiết bị)

Dựa vào kết quả chuẩn đoán để phân tích sự hoạt động và các lỗi của hệ thống

Trong đó jk: chỉ số TW,lm: chỉ số KHW

Khuyến nghị:

- Phân tích các lỗi theo hướng dẫn sách OUTPUT MANUAL, bảng tra cứu lỗi INDEX

để xử lý

1.6 CÁC QUY TRÌNH KIỂM TRA, BẢO DƯỠNG CÁC THIẾT BỊ PHỤ TRỢ.

1.6.1 Thực hiện tra k bảo dưỡng đĩa cứng (DK)

Mục đích: Kiểm hả năng lưu trữ của ổ đĩa cứng, chất lượng của ổ điã cứng đảm bảo số liệu lưu trữ trên DK (số liệu tổng đài, firmware, cuớc…) là an toàn, không để xảy ra tình trạng mất số liệu Dọn dẹp số liệu không cần thiết có trong DK đảm bảo dung lượng lưu trữ

Quy trình thực hiện kiểm tra DK:

>view dkinf: để xác định dung lượng lưu trữ DK

>view blk: để xác định số block lỗi trên DK

>chg blk: để thay thế block bị lỗi của DK bằng block dự phòng nếu có

>fmt dk: để format lại DK khi thay thế mới, lỗi DK

- Kiểm tra các số liệu không cần thiết có trong DK và xoá đi (chỉ thực hiện với người

>dgt exec dat05 disp=dtl (chuẩn đoán lỗi)

- Cho băng vệ sinh DAT (Clearn DAT) vào ổ DAT để thực hiện việc vệ sinh đầu từ của DAT

Khuyến nghị:

- Khi DGT cần cho băng từ vào ổ DAT

- Phân tích các lỗi theo hướng dẫn sách OUTPUT MANUAL, bảng tra cứu lỗi INDEX

để xử lý

1.6.3 Kiểm tra các thông số kỹ thuật của hệ thống nguồn điện và các cảnh báo liên quan

Mục đích: Kiểm tra các thông số về nguồn điện, đảm bảo nguồn điện ổn định cung cấp cho thiết bị tại vệ tinh và HOST, kiểm tra các cảnh báo nguồn đảm bảo độ chính xác, nâng cao chất lượng tuổi thọ của hệ thống nguồn Trên cơ sở thực tế tính toán, yêu cầu

bổ xung, điều chỉnh các hệ thống, nguồn (ACCU, RECT) đảm bảo cho hệ thống được hoạt động ổn định

Công cụ kiểm tra: Đồng hồ vạn năng, các menu điều khiển, giám sát hệ thống nguồn Quy trình kiểm tra:

Tham chiếu thêm quy trình 5.6 “Đề tài quy trình vận hành bảo dưỡng Neax 61 Sigma

năm 2005”

- Kiểm tra điện áp cung cấp nguồn đầu vào (AC), đầu ra (DC) đảm bảo theo chỉ tiêu

kỹ thuật của máy nắn bằng cách đo đồng hồ vạn năng

- Kiểm tra công suất (dòng tải) sử dụng của hệ thống máy nắn RECT đảm bảo dòng tiêu thụ cho từng trạm vệ tinh và HOST (bằng bảng điều khiển của máy nắn RECT)

- Kiểm tra công suất dự phòng của máy nắn đảm bảo N+1 (khi có 1 máy nắn hỏng hệ thống RECT vẫn có thể hoạt động bình thường, không xảy ra quá tải)

- Kiểm tra phân tải của từng máy nắn RECT đảm bảo dòng tải phân bổ đều trên từng máy nắn (bằng bảng điều khiển của máy nắn RECT) Các máy nắn dòng tải phân bổ không được vượt quá nhau 10%

- Kiểm tra dung lượng của ACCU đảm bảo thời gian cung cấp điện cho hệ thống khi

có sự cố về nguồn AC, máy nắn…

- Cập nhật các kết quả vào biểu báo cáo

1.6.4 Kiểm tra việc thực hiện lấy cước online (CDT)

Mục đích: Chương trình lấy cước CDT là chương trình hỗ trợ cho người khai thác lấy cước được dễ dàng, thuận tiện, chính xác hơn là lấy cước theo cách truyền thống qua băng từ MT File cước được lưu trữ dưới dạng text và vó thể copy thành nhiều bản, giúp cho việc lưu trữ hay gửi đến trung tâm tính cước một cách nhanh chóng dễ dàng (Gửi qua mạng nội bộ, mail) độ an toàn khi lưu trữ rất cao, gọn nhẹ, dễ dàng nhanh chóng trong việc tra cứu các số liệu về cước, không tốn nhiều công sức như cách làm truyền thống

Quy trình kiểm tra:

- Kiểm tra kết nối kết nối mạng vật lý từ máy tính (cổng mạng ) đến mạng LAN của tổng đài

- Kiểm tra khai báo địa chỉ IP cổng kết nối tới tổng đài:

>view inet hst host=CDT ipadr=DDD.DDD.DDD.DDD

trong đó DDD.DDD.DDD.DDD: là địa chỉ của máy MAT

- Kiểm tra lớp lệnh truy nhập (acnt) cho kết nối CDT để đảm bảo acount chỉ thực hiện lệnh lấy cước:

>view acnt host name_hst=CDT

- Kiểm tra khai báo thuộc tính TCP/IP tại máy tính dùng để lấy cước

- Thiết lập setting của phần mềm CDT để khai báo các thông số kết nối, giao thức truyền file FTP:

+ Trong mục IP address: 10.10.0.13x ( địa chỉ IP tổng đài) + user name: CDT (account lấy cước riêng cho CDT để đảm bảo công việc bảo mật, không dùng chung cho các acount khác)

+ password và confirm password: xxxx (là mật khẩu của acount CDT) + FTP user name : ftp

+ password và confirm password: f1t2p3

- Kiểm tra phần mềm lấy cước CDT

Hình 1.1 Lưu đồ lấy cước AMA và MET bằng phần mềm lấy cước

online CDT (charg data tranfer)

1.6.5 Kiểm tra các trạng thái hoạt động của kết nối phần khai thác bảo dưỡng (MAT, RS232, LAN )

- Kiểm tra trạng thái hoạt động của các Terminal:

Set ama ovwr

close

Dload MET Dload MET

to PC

execute next

>view inet kind=map (kiểm tra các địa chỉ IP được phép truy nhập)

>view exc (kiểm tra quyền mà các acount được phép truy nhập)

- Các máy tính khai thác MAT

- Kiểm tra phần mềm VITAONE phục vụ cho GUI

- Các kết nối LAN, RS232

>view coc (kiểm tra trạng thái hoạt động của LAN và rs232)

- Các tham số kết nối RS232 như sau: (sử dụng Hyper terminal)

+ Bit per second: 9600

+ Data bits: 7

+ Parity: even

+ Stop bits: 1

+ Follow control: None

- Kiểm tra kết nối rs232 khởi động phase 3 (Master console):

+ Vào chương trình Vitaone

+ Chọn master console

+ Chọn restart system

+ Chọn phase 3

+ Kiểm tra kết nối cổng COM tới MIF

1.6.6 Quan trắc bộ đếm lỗi DTI

Mục đích:

Việc kiểm tra đánh giá các lỗi của đường truyền dẫn số (DTI) trong tổng đài là rất cần thiết vì đường truyền dẫn số kết nối thoại giữa tổng đài HOST-Vệ tinh, HOST-Liên đài Việc thống kê các lỗi sẽ tổng hợp được các lỗi cụ thể qua đó sẽ đánh giá và phân tích được chất lượng của thiết bị, môi trường truyền dẫn và đưa ra các phương án

xử lý nâng cao chất lượng đường truyền

Nội dung:

Kiểm tra số liệu đăng ký theo thời gian của các DTI:

>View ttoc sdl Kiểm tra số liệu bộ đếm lỗi DTI:

>View ttoc dmd Khuyến nghị :

Việc thực hiện xem kết quả bộ đếm lỗi DTI được thực hiện cập nhật trong các

ca trực để có số liệu báo cáo đánh giá cụ thể trong mỗi đợt bảo dưỡng phòng ngừa

1.7 ĐÁNH GIÁ SƠ BỘ

Thông qua tiến trình kiểm tra tài nguyên phần cứng như tài nguyên về báo hiệu, mạch thu phát SND/RCV, TONE, thoại hội nghị TWC, hiển thị số CLIP , kiểm tra trạng thái và bảo dưỡng các thành phần của hệ thống, số liệu thống kê lịch sử về lỗi của các trạm điều khiển cần đưa ra đánh giá sơ bộ về phần cứng theo các nội dung sau:

- Cấu hình hiện trạng của hệ thống

- Đánh giá sơ bộ về hiệu năng đáp ứng của hệ thống

- Thống kê số lần các trạm điều khiển và thành phần phần cứng khác bị lỗi, phân tích nguyên nhân và đưa ra giải pháp

- Nhận xét, đánh giá việc thực hiện định kỳ các quy trình bảo dưỡng phần cứng

- Đưa ra các khuyến nghị về việc mở rộng hoặc tối ưu hệ thống nhằm đảm bảo việc đáp ứng các dịch vụ một cách hiệu quả nhất

CHƯƠNG II

QUY TRÌNH KIỂM TRA PHẦN MỀM VÀ BACKUP

Tổng hợp, liệt kê các danh mục phần cứng có firmware, đưa ra các quy trình thực hiện khi thay đổi phần mềm theo yêu cầu của nhà cung cấp thiết bị (NEC), cập nhật các firmware mới Đưa ra các khuyến nghị, điều kiện chuẩn bị trước kiểm tra phần mềm

2.1.2 Quy trình thực hiện

+ Công tác chuẩn bị: Trước khi kiểm tra firmware các khối điều khiển cần kiểm tra các logic của các khối về cùng một trạng thái active (ACT) vì chỉ kiểm tra được firmware ở trạng thái mặt logic Active

+ Nếu có lỗi không tương thích giữa các khối điều khiển có cùng chung chức năng hoặc mất phần mềm Cần phải download lại phần mềm (theo quy trình dowload

firmware)

+ Kiểm tra các firmware lưu trong ổ đĩa cứng DK nhằm đảm bảo dữ liệu firmware đã thực sự được lưu trữ, cần thiết khi cần nạp lại cho các khối điều khiển khi cần (theo quy trình kiểm tra firmware trong đĩa cứng DK)

2.1.3 Bảng tổng hợp các khối phần mềm cần kiểm tra

STT Tên khối

xử lý

4 LOC Bộ xử lý cục bộ

6 RLUIC Khối điều khiển giao tiếp vệ tinh

số(dùng cho V5)

11 RFHC Khối điều khiển khung tại vệ tinh

Bảng 2.1 Tổng hợp các khối phần mềm cần bảo dưỡng

2.1.4 Kiểm tra phần mềm, hệ điều hành của tổng đài

Mục đích: Kiểm tra để biết đƣợc các phần mềm đang chạy của tổng đài, hệ điều hành, các patch file đã nạp cho bộ xử lý CP Kiểm tra sự đồng nhất số liệu phần mềm giữa các mặt của CP

Nội dung:

Kiểm tra phần mềm nạp cho CP và hệ điều hành

>view ipl imd=act

cp00 sfn=UXN3M030071 ver_sfl=RXUX-N3M-030-071 date=08/16/02

sfn=RTN3M32111A ver_sfl=RTOS_N3M-321-011 date=06/26/02

sfn=AP55CM37005 ver_sfl=AP55CMVIE 37005 date=10/23/02

pfn=AP55CM37005800 ver_pfl=AP55CMVIE 37005-800 date=10/23/02

………

- Trong đó:

cp00: bộ xử lý trung tâm CP00

sfn: là tên phần mềm

pfn: tên của patch file được nạp vào tổng đài

sfn=UXN là hệ điều hành UNIX

sfn= RTN là hệ điều hành RTOS

sfn=AP55CM là phần mềm phiên bản 5.5G

ver_sfl: số phiên bản của file hệ thống

date: ngày nạp file

Kiểm tra các phần mềm chƣa đƣợc kích hoạt ở CP:

>view ipl imd=inact all Kiểm tra quản lý những lần nạp pacth file trước cho bộ xử lý CP:

>view ipl log Kiểm tra sự tương thích file hệ điều hành giữa các CP

2.1.5 Kiểm tra phần mềm khối điều khiển chuyển mạch thời gian (TSW)

Lệnh thực hiện:

- Kiểm tra firmware đang hoạt động:

>view dloadinf tswijk type=cur

- Kiểm tra firmware lưu trữ tại DK:

>view dloadinf tsw type=dk

Dựa vào kết quả kiểm tra firmware:

- Xác định firmware đang hoạt động phải là firmware mới nhất cập nhật trong ổ đĩa

DK

- Xác định firmware giữa 2 mặt logic là giống nhau

- Sửa đổi lại firmware nếu mất phần mềm, hoặc nghi ngờ lỗi firmware:

>ous tswijk

>dload tswijk fn=c1-c15 type=all

>ins tsw Trong đó: i: sys_0 hoặc 1; jk: chỉ số TSW

c1-c15: Tên file firmware (lưu trữ ở DK)

-Kiểm tra lại firmware đã nạp

2.1.6 Kiểm tra phần mềm khối điều khiển chuyển mạch không gian (SSW)

Lệnh thực hiện:

- Kiểm tra firmware đang hoạt động:

>view dloadinf sswij type=cur

- Kiểm tra firmware lưu trữ tại DK:

>view dloadinf ssw Type=dk Dựa vào kết quả kiểm tra firmware:

- Xác định firmware đang hoạt động phải là firmware mới nhất cập nhật trong ổ đĩa

DK

- Xác định firmware giữa 2 mặt logic là giống nhau

- Sửa đổi lại firmware nếu mất phần mềm, hoặc nghi ngờ lỗi firmware:

>ous sswij

>dload sswij fn=c1-c15 type=all

>ins swj

Trong đó: i: sys_0 hoặc 1; jk: chỉ số TSW

c1-c15: Tên file firmware (lưu trữ ở DK)

- Kiểm tra lại firmware đã nạp

2.1.7 Kiểm tra phần mềm khối điều khiển vệ tinh (RLUIC)

Lệnh thực hiện:

- Kiểm tra firmware đang hoạt động:

>view dloadinf rluicijklm type=cur

- Kiểm tra firmware lưu trữ tại DK:

>view dloadinf rluic Type=dk Dựa vào kết quả kiểm tra firmware:

- Xác định firmware đang hoạt động phải là firmware mới nhất cập nhật trong ổ đĩa

DK

- Xác định firmware giữa 2 mặt logic là giống nhau

- Sửa đổi lại firmware nếu mất phần mềm, hoặc nghi ngờ lỗi firmware:

>ous rluicijklm

>dload rluicijklm fn=c1-c15 type=all

>ins rluicijklm Trong đó: i: sys_0 hoặc 1; jk: chỉ số tsw; lm: chỉ số KHW

1-c15: Tên file firmware (lưu trữ ở DK)

- Kiểm tra lại firmware đã nạp

2.1.8 Kiểm tra phần mềm khối điều khiển trung kế số (DTIC)

Lệnh thực hiện:

- Kiểm tra firmware đang hoạt động:

>view dloadinf dticijklm type=cur

- Kiểm tra firmware lưu trữ tại DK:

>view dloadinf dtic Type=dk Dựa vào kết quả kiểm tra firmware:

- Xác định firmware đang hoạt động phải là firmware mới nhất cập nhật trong ổ đĩa

DK

- Xác định firmware giữa 2 mặt logic là giống nhau

- Sửa đổi lại firmware nếu mất phần mềm, hoặc nghi ngờ lỗi firmware:

>ous dticijklm

>dload dticijklm fn=c1-c15 type=all

>ins dticijklm Trong đó: i: sys_0 hoặc 1; jk: chỉ số tsw; lm: chỉ số KHW

c1-c15: Tên file firmware (lưu trữ ở DK)

- Kiểm tra lại firmware đã nạp

2.1.9 Kiểm tra phần mềm khối điều khiển điều khiển cục bộ (LOC)

Lệnh thực hiện:

- Kiểm tra firmware đang hoạt động:

>view dloadinf loccijklm type=cur

- Kiểm tra firmware lưu trữ tại DK:

>view dloadinf loc type=dk Dựa vào kết quả kiểm tra firmware:

- Xác định firmware đang hoạt động phải là firmware mới nhất cập nhật trong ổ đĩa

DK

- Xác định firmware giữa 2 mặt logic là giống nhau

- Sửa đổi lại firmware nếu mất phần mềm, hoặc nghi ngờ lỗi firmware:

>ous locijklm

>dload locijklm fn=c1-c15 type=all

>ins locijklm

Trong đó: i: sys_0 hoặc sys_1; jk: chỉ số tsw; lm: chỉ số KHW

c1-c15: Tên file firmware (lưu trữ ở DK)

- Kiểm tra lại firmware đã nạp

2.1.10 Kiểm tra phần mềm vệ tinh (RLOC)

Lệnh thực hiện:

- Kiểm tra firmware đang hoạt động:

>view dloadinf rlocijklm type=cur

- Kiểm tra firmware lưu trữ tại DK:

>view dloadinf rloc Type=dk Dựa vào kết quả kiểm tra firmware:

- Xác định firmware đang hoạt động phải là firmware mới nhất cập nhật trong ổ đĩa

DK

- Xác định firmware giữa 2 mặt logic là giống nhau

- Sửa đổi lại firmware nếu mất phần mềm, hoặc nghi ngờ lỗi firmware:

>ous rlocijklm

>dload rlocijklm fn=c1-c15 type=all

>ins rlocijklm

Trong đó: i: sys_0 hoặc sys_1; jk: chỉ số tsw; lm: chỉ số KHW

c1-c15: Tên file firmware (lưu trữ ở DK)

2.1.11 Kiểm tra phần mềm khối điều LDC

Lệnh thực hiện:

- Kiểm tra firmware đang hoạt động:

>view dloadinf ldcijklmn type=cur

- Kiểm tra firmware lưu trữ tại DK:

>view dloadinf ldc type=dk

Dựa vào kết quả kiểm tra firmware:

- Xác định firmware đang hoạt động phải là firmware mới nhất cập nhật trong ổ đĩa

DK

- Xác định firmware giữa 2 mặt logic là giống nhau

- Sửa đổi lại firmware nếu mất phần mềm, hoặc nghi ngờ lỗi firmware:

>ous ldcijklmn

>dload ldcijklmn fn=c1-c15 type=all

>ins ldcijklmn

Trong đó: ij: chỉ số tsw; kl: chỉ số KHW; mn: chỉ số LDC

c1-c15: Tên file firmware (lưu trữ ở DK)

- Kiểm tra lại firmware đã nạp

2.1.12 Kiểm tra phần mềm khối điều khiển RFHC

Lệnh thực hiện:

- Kiểm tra firmware đang hoạt động:

>view dloadinf rfhcijklmn type=cur

- Kiểm tra firmware lưu trữ tại DK:

>view dloadinf rfhc Type=dk Dựa vào kết quả kiểm tra firmware:

- Xác định firmware đang hoạt động phải là firmware mới nhất cập nhật trong ổ đĩa

DK

- Xác định firmware giữa 2 mặt logic là giống nhau

- Sửa đổi lại firmware nếu mất phần mềm, hoặc nghi ngờ lỗi firmware:

>ous rfhcijklmn

>dload rfhcijklmn fn=c1-c15 type=all

>ins rfhcijklmn Trong đó: ij: chỉ số tsw; kl: chỉ số KHW; mn: chỉ số RFHC

c1-c15: Tên file firmware (lưu trữ ở DK)

- Kiểm tra lại firmware đã nạp

2.1.13 Kiểm tra phần mềm khối đo thử dường dây thuê bao (LTE)

Lệnh thực hiện:

- Kiểm tra firmware đang hoạt động:

>view dloadinf lteijkl type=cur

- Kiểm tra firmware lưu trữ tại DK:

>view dloadinf lte type=dk Dựa vào kết quả kiểm tra firmware:

- Xác định firmware đang hoạt động phải là firmware mới nhất cập nhật trong ổ đĩa

DK

- Xác định firmware giữa 2 mặt logic là giống nhau

- Sửa đổi lại firmware nếu mất phần mềm, hoặc nghi ngờ lỗi firmware:

>ous lteijkl

>dload lteijkl fn=c1-c15 type=all

>ins lteijkl

Trong đó: ij: chỉ số tsw; kl: chỉ số KHW của vệ tinh

- Kiểm tra lại firmware đã nạp

2.2 QUY TRÌNH NẠP PATCH FILE VÀ MỘT SỐ QUY TRÌNH BACKUP

2.2.1 Quy trình nạp patch file theo quy trình của nhà cung cấp thiết bị (FILE UPDATE)

Mục đích: Tạo quy trình thực hiện có sẵn khi có sự thay đổi về hệ thống do nhà cung

cấp thiết bị cung cấp hoặc nhà khai thác yêu cầu với mục đích:

+ Nâng cấp version phần mềm

+ Nâng cấp tính năng của phần mềm

+ Bổ xung dịch vụ mới

+ Sửa lỗi phần mềm: Các lỗi liên quan đến thuộc tính của hệ thống

Tuỳ thuộc vào mức độ thay đổi của từng version phần mềm mà có thể thay đổi:

+ Thay đổi phần nhân của chương trình (system file)

+ Thay đổi tập lệnh của tổng đài (command file)

+ Chuyển dữ liệu (data base, office data) từ hệ thống cũ (version cũ) sang hệ thống mới (version mới)

+ Kích hoạt phần mềm đã được update để tạo ra một hệ thống với software mới, số liệu cũ có một số thay đổi

+ Sửa đổi số liệu sau update sao cho cái mới tương đương với cái cũ

+ Sửa lỗi: Có thủ tục cụ thể

Cấu trúc file phần mềm tổng đài:

Một file phần mềm hệ thống cho tổng đài có cấu trúc như sau:

Ví dụ: File name(fn) = AP 35 CM 073V7 E37

Bước 1: Tạo backup file (dự phòng khi có lỗi xảy ra trong quá trình up date):

>cre bkf dat05 vol=c1-c8 kind=iplall

Trong đó c1-c8: tên nhãn của file backup

Bước 2: Kiểm tra trạng thái hệ thống:

>view cpall

>view all

+ Xem trạng thái cp0: act, cp1: sby (bắt buộc)

+ Các bộ điều khiển và các phần cứng thuộc giá cơ sở (BF) nên ở trạng thái hoạt động bình thường (act-sby)

Bước 3: Kiểm tra phần mềm:

- Mục đích: Kiểm tra xem tổng đài đang dùng version nào, đã có những patch file nào được đưa vào hệ thống, patch file sắp đưa vào có phù hợp không

>view ipl imd=act all (Cho biết version và các patch file đang sử dụng)

>view ipl imd=inact all (Trạng thái ban đầu trước khi đưa các patch file vào) >view cmdf (Hiện version của command file)

Bước 4: Kiểm tra nội dung các ô nhớ cần thay đổi:

>view mm cpDD la=H1-H8 size=4 type= word

H1-H8: Là địa chỉ ô nhớ

DD: chỉ số cp

+ Nếu đúng với nội dung theo thiết kế thì có thể áp dụng patch installation

+ Nếu khác với nội dung theo thiết kế thì dừng không đưa patch vào

Bước 5: Nạp patch file từ DAT, FD:

- Nạp patch file từ băng từ (DAT):

>view cpall (xác nhận tất cả CP là mặt 0: act, mặt 1: sby)

+ Kiểm tra và cho băng DAT vào ổ DAT

>load ipl pfl_mt dat05 (nạp patch file từ DAT vào DK)

>str fup all pfn ph=nph (khởi tạo nạp file) >load fup pfn=AP55CM37005E05 (ví dụ file ứng dụng G5.5)

>act fup (kích hoạt patch file) >stop fup md=upd (dừng nạp file)

>view mm cpDD la=H1-H8 size=4 type= word (kiểm tra bộ nhớ đã nạp)

- Nạp patch file từ đĩa mềm (FD):

+ Xác nhận tất cả CP là mặt 0: act, mặt 1: sby

+ Kiểm tra và cho băng FD vào

+ Tạo patch file từ file lệnh thực hiện qua GUI

> str fup all pfn ph=nph khởi tạo nạp file >load fup pfn=AP55CM37005E05 ( nạp file pfn=AP55CM37005E05 ) > act fup (kích hoạt patch file)

> stop fup md=upd (dừng nạp file)

> view mm cpDD la=H1-H8 size=4 type= word (kiểm tra bộ nhớ đã nạp)

2.2.2 Quy trình gỡ bỏ một patch file theo quy trình của nhà cung cấp thiết bị

Mục đích: Sau khi nạp patch file mà số liệu sau khi update không thay đổi, hoặc xuất

hiện các sự cố nghiêm trọng, không rõ nguyên nhân sau khi update thì ta phải thực hiện gỡ bỏ patch

Quy trình thực hiện:

Bước 1: Kiểm tra trạng thái CP:

>View cpall (đảm bảo sys0: act, sys1: sby)

Bước 2: Lệnh thứ tự thực hiện:

>Str ipl sfn copy

>Stop ipl md=upd

>Str ipl pfn imd=act

>Mod ipl kind=all pfn_del= AP55CM37005E05

>Stop ipl md=upd

>Set dbf dbdir=act

>Str fup all pfn ph=ph2

>Act fup

>Stop fup md=upd

Ghi chú: Nếu không xoá được patch file ( thủ tục xoá không thực hiện được, hệ thống

ở trạng thái bất thường, nhận và xử lý lệnh không thực hiện được) thì ta phải sử dụng băng BACKUP để khôi phục lại

2.2.3 Tạo băng Backup

Mục đích: Lưu trữ số liệu, cấu hình của tổng đài trước khi chỉnh sửa hệ thống (nạp patch file, nâng cấp phần cứng…) vào băng DAT, khi hệ thống nâng cấp có vấn đề lỗi

có thể nạp lại từ băng DAT

Các loại Backup của tổng đài NEAX

Thông thường có 2 loại backup số liệu:

Backup data (ipl_all : chỉ lưu trữ trên băng DAT)

Backup toàn bộ DK (dk_all : lưu trữ trên băng DAT và DK)

Khuyến nghị về chu kỳ Backup:

Backup trước khi tạo trạm, thay đổi phần mềm, nạp patch file , nâng cấp hệ thống, mở rộng hệ thống

Backup theo chu kỳ hàng tuần (chỉ cần backup ipl_all là đủ )