TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI VIỆN ĐIỆN TỬ VIỄN THÔNG BÁO CÁO Đề tài QUẢN LÝ MẠNG CHO HỆ THỐNG LƯU TRỮ VÀ TRUYỀN THÔNG HÌNH ẢNH PACS Giảng viên hướng dẫn TS Nguyễn Thái Hà Sinh viên thực hiện MSSV Nội dung Nguyễn Xuân Huy 20131785 (trang 1 43) Bùi Ngọc Tuyên 20134352 (trang 43 73) Hà Nội, 12 – 2016 Tóm tắt nội dung Hệ thống lưu trữ và truyền thông hình ảnh (PACS) đã được triển khai nhanh chóng đến các bệnh viện trên toàn thế gới hơn 5 năm quá Mặc dù các hệ thống này nâng cao hiệu quả làm việc.
Giới thiệu
Với sự phát triển của công nghệ viễn thông, mạng dữ liệu đã trở thành yếu tố thiết yếu trong cuộc sống hiện đại Các tổ chức và cộng đồng sử dụng mạng để chia sẻ thông tin và giao tiếp Hiện nay, hầu hết các công ty kết nối Internet thông qua các nhà cung cấp dịch vụ, trong khi các tập đoàn lớn thường xây dựng mạng riêng để bảo mật thông tin Công nghệ tiên tiến cho phép kết nối các mạng khác nhau qua bộ định tuyến và cầu nối, như Ethernet và Token Ring Trong thập kỷ qua, đã có nhiều nỗ lực nhằm chuẩn hóa giao thức mạng, giúp thiết bị hoạt động hiệu quả trong môi trường đa nhà cung cấp.
Nhu cầu giao tiếp mạng không chỉ dừng lại ở lĩnh vực kinh doanh; từ giữa những năm 1990, các bệnh viện đã bắt đầu kết nối các thiết bị chẩn đoán hình ảnh Nhờ vào sự tiến bộ của công nghệ mạng, những thiết bị này hiện được liên kết với hệ thống lưu trữ trung tâm (PACS), cung cấp kho lưu trữ và dịch vụ quản lý chẩn đoán hình ảnh cùng báo cáo Hệ thống PACS giúp cải thiện quy trình làm việc tại bệnh viện, rút ngắn thời gian chẩn đoán từ hàng giờ xuống chỉ còn vài phút, đồng thời giảm thiểu chi phí quản lý một cách đáng kể.
Nghiên cứu khoa học vẫn đang tiến triển, dẫn đến việc phát triển và triển khai nhiều loại thiết bị chẩn đoán hình ảnh trong các bệnh viện nhằm đáp ứng các nhu cầu đa dạng.
Với sự gia tăng số lượng thiết bị chẩn đoán hình ảnh, việc theo dõi và duy trì kết nối với PACS không còn khả thi bằng phương pháp thủ công Để giải quyết vấn đề này, chúng tôi đã phát triển hệ thống giám sát PACS (PACS Monitor system) nhằm cung cấp thu thập thống kê, quản lý cấu hình và quản lý lỗi cho các quản trị viên PACS Hệ thống PACS Monitor cho phép xác định và giải quyết hiệu quả các vấn đề kết nối Chúng tôi áp dụng giao thức quản lý mạng đơn giản (SNMP) cho hệ thống theo dõi y tế Mặc dù mục tiêu của dự án này chỉ tập trung vào quản lý dữ liệu PACS trong dịch vụ lưu trữ, hệ thống có thể mở rộng để hỗ trợ quản lý dữ liệu cho các thiết bị chẩn đoán hình ảnh khác.
Bài viết cung cấp cái nhìn tổng quan về môi trường bệnh viện trong phần 2, trong khi phần 3 thảo luận về giao thức truyền thông giữa PACS và thiết bị chẩn đoán hình ảnh Phần 4 trình bày tổng quan về SNMP, và phần 5 nêu rõ động lực áp dụng SNMP trong hệ thống y tế Phần 6 tập trung vào thiết kế và thực hiện hệ thống PACS Monitor, cuối cùng, phần 7 đánh giá kết quả phát triển của chúng tôi.
Bệnh viện
Lịch sử của bệnh viện
Bệnh viện đầu tiên được người La Mã thành lập trước thế kỷ thứ 3 nhằm chữa trị cho binh lính bị ốm và bị thương, với phương pháp điều trị chủ yếu là cách ly bệnh nhân Đến giữa thời Trung Cổ, số lượng bệnh viện do các nhà tu xây dựng tăng lên, một số bệnh viện có khả năng chứa hơn 2000 bệnh nhân Trong thời gian này, y tế tiến bộ chậm, cây thuốc là nguồn chữa trị chính Đầu thế kỷ 18, chính quyền bắt đầu cung cấp dịch vụ chăm sóc sức khỏe, dẫn đến sự ra đời của nhiều bệnh viện mới Những đột phá khoa học và y tế vào giữa thế kỷ 19, như phát hiện tia X của Wilhem Conrad Rontgen, giúp bác sĩ hiểu rõ hơn về cơ thể và các căn bệnh Các tiến bộ khác trong những năm 1990 đã phát triển nhiều thiết bị chẩn đoán không xâm lấn như MRI, CT, và siêu âm, cho phép bác sĩ chẩn đoán chính xác hơn Sự phát triển chuyên môn trong các lĩnh vực y tế đã dẫn đến việc hình thành các phòng ban khác nhau trong bệnh viện, như tim mạch, thần kinh và ung thư, làm việc cùng nhau để chăm sóc sức khỏe cho bệnh nhân Khi cấu trúc bệnh viện trở nên phức tạp, công nghệ thông tin được áp dụng nhằm cải thiện quản lý và cung cấp dịch vụ chăm sóc sức khỏe cho cộng đồng.
Hệ thống công nghệ thông tin bệnh viện
Nhân viên y tế tại bệnh viện hiện đại sử dụng thiết bị chẩn đoán và hệ thống công nghệ thông tin hàng ngày Các hệ thống này hoạt động liên kết với nhau ở các khoa khác nhau, cung cấp nhiều chức năng như thanh toán, hình ảnh, thuốc và báo cáo chẩn đoán Hình 1 minh họa sự tương tác giữa các hệ thống này.
Các tương tác trong hệ thống công nghệ thông tin bệnh viện bao gồm các modalities, hệ thống lưu trữ và truyền thông hình ảnh (PACS), hệ thống thông tin chẩn đoán hình ảnh (RIS), hệ thống thông tin y tế bệnh viện, và hệ thống tự động hóa.
2.2.1 Hệ thống thông tin bệnh viện ( Hospital Information System - HIS ).
Hệ thống thông tin bệnh viện (HIS) được sử dụng để quản lý bệnh viện và quy trình lâm sàng, còn được gọi là ADT, ghi lại thông tin nhập viện, xuất viện và chuyển viện của bệnh nhân Khi bệnh nhân nhập viện, thông tin cá nhân sẽ được nhập vào HIS và tự động gửi đến các hệ thống như RIS và PACS, giúp giảm thiểu lỗi đánh máy Một lợi ích khác của HIS là khả năng tự động ghi lại chi phí dịch vụ như giường bệnh, xét nghiệm, thuốc, phí tư vấn và thực phẩm Nhiều bệnh viện còn kết nối HIS với các hệ thống tự động khác để nâng cao hiệu suất và đảm bảo an toàn cho bệnh nhân.
2.2.2 Hệ thống tự động hóa (Automation System)
Công nghệ tự động hóa trong bệnh viện chủ yếu được áp dụng cho quy trình quản lý thuốc và bệnh nhân, giúp giảm thiểu lỗi thuốc và nâng cao an toàn cho bệnh nhân thông qua việc quét mã vạch Nhiều bệnh viện đã tự động hóa hoàn toàn quy trình này, bao gồm quy định, đóng gói và phân phát thuốc mà không cần sự can thiệp của con người Nhân viên y tế có thể sử dụng thiết bị không dây kết hợp với máy quét mã vạch để xác định chính xác liều lượng thuốc cho từng bệnh nhân, từ đó đảm bảo cung cấp dịch vụ chăm sóc sức khỏe chất lượng cao.
2.2.3 Hệ thống thông tin chẩn đoán hình ảnh (Radiology Information System -
Hệ thống RIS (Radiology Information System) được sử dụng trong khoa chẩn đoán hình ảnh để theo dõi và quản lý bệnh nhân, phim và nguồn cung cấp Khi bác sĩ yêu cầu kỹ thuật viên chụp hình, thủ tục sẽ được đặt qua RIS, với thông tin cá nhân và quy trình được gửi ngay lập tức đến PACS dưới dạng điện tử Thông tin này cũng được truyền đến máy chụp hình theo yêu cầu RIS cho phép cập nhật và truyền tự động thông tin cá nhân bệnh nhân đến PACS, từ đó nâng cao hiệu quả quản lý và quy trình làm việc lâm sàng trong khoa chẩn đoán hình ảnh.
2.2.4 Hệ thống lưu trữ và truyền hình ảnh (Picture Archiving and
Hệ thống PACS (Hệ thống lưu trữ và truyền tải hình ảnh) giúp bệnh viện quản lý và lưu trữ ảnh chẩn đoán một cách hiệu quả Ảnh chẩn đoán được gửi đến PACS ở dạng điện tử sau khi thực hiện chụp – chiếu, cho phép kỹ thuật viên dễ dàng xem xét và xác nhận hình ảnh Sau đó, bác sĩ chẩn đoán hình ảnh có thể nhanh chóng đọc và thực hiện chẩn đoán Quá trình này, trước đây mất hơn một giờ với phim truyền thống, giờ chỉ còn chưa đầy năm phút, giúp bệnh nhân nhận được điều trị kịp thời Việc sử dụng PACS không chỉ tiết kiệm thời gian mà còn cho phép bác sĩ tập trung vào việc đọc hình ảnh và báo cáo chẩn đoán, thay vì phải sắp xếp và xử lý phim.
Phương thức chẩn đoán hình ảnh là công cụ quan trọng giúp bác sĩ xác định chính xác tình trạng sức khỏe mà không cần phẫu thuật Các thiết bị như MRI, CT, CR, US, PET và NM hiện có mặt tại nhiều bệnh viện hiện đại, mỗi loại có đặc điểm riêng Chẳng hạn, CR sử dụng tia X trên mặt phẳng ngang, trong khi CT sử dụng tia X trên mặt phẳng đứng Hình ảnh MRI mang lại độ tương phản tốt nhất giữa mô bình thường và mô bất thường, còn hình ảnh NM hữu ích trong việc phát hiện kích thước và sự có mặt bất thường trong cơ quan Công nghệ chẩn đoán hình ảnh hiện đại cho phép bác sĩ yêu cầu nhiều loại hình chụp khác nhau để có cái nhìn toàn diện về cấu trúc cơ thể, nâng cao độ chính xác trong chẩn đoán Trước đây, bác sĩ chỉ nhận được phim X-quang sau vài giờ, nhưng với sự phát triển của PACS, họ có thể truy cập ngay lập tức vào các hình ảnh này tại trạm làm việc.
Giao thức truyền thông và khung tích hợp (Communication Protocol and Integration Framework)
Trong bệnh viện, hệ thống công nghệ thông tin và thiết bị chẩn đoán giao tiếp qua các giao thức truyền thông như DICOM và HL7 Những chuẩn này được sử dụng để truyền thông giữa RIS, PACS và các phương thức khác Tuy nhiên, chúng không đủ cho việc tích hợp giữa các hệ thống bệnh viện từ các nhà cung cấp khác nhau Do đó, IHE (Integrating the Healthcare Enterprise) đã được thành lập vào năm 1998 nhằm giải quyết vấn đề tích hợp trong quy trình làm việc của bệnh viện.
2.3.1 Số hóa và truyền ảnh y tế (Digital Imaging and Communication in
DICOM là một giao thức mạng quan trọng trong bệnh viện, đánh dấu sự khởi đầu của kỹ thuật số trong ngành chẩn đoán hình ảnh Tiêu chuẩn DICOM đảm bảo khả năng tương tác giữa các thiết bị chẩn đoán hình ảnh từ nhiều nhà cung cấp khác nhau, xác định lớp mạng truyền thông cho việc trao đổi tin nhắn, cú pháp, và ý nghĩa của lệnh cùng thông tin liên quan Giao thức này được áp dụng rộng rãi trong các thiết bị chẩn đoán và hệ thống PACS để trao đổi hình ảnh và thông tin bệnh nhân.
2.3.2 Chuẩn HL7 (Health Level Seven - HL7)
HL7 là một giao thức truyền thông quan trọng trong bệnh viện, cung cấp nền tảng cho việc mã hóa và trao đổi thông tin chăm sóc sức khỏe bệnh nhân giữa các hệ thống khác nhau qua mạng TCP/IP Tiêu chuẩn này cho phép truyền tải hồ sơ bệnh nhân, đơn hàng và thông tin tài chính một cách hiệu quả thông qua hệ thống thông tin bệnh viện (HIS).
RIS, and PACS mà không cần sự can thiệp của con người Tuy nhiên, HL7 không cung cấp bất kỳ hỗ trợ nào cho dữ liệu hình ảnh.
2.3.3 Liên hợp các doanh nghiệp chăm sóc sức khỏe ( - IHE)
IHE là chương trình được thành lập bởi các chuyên gia chăm sóc sức khỏe nhằm cải thiện sự tích hợp giữa thiết bị chẩn đoán và hệ thống công nghệ thông tin bệnh viện Mặc dù tiêu chuẩn DICOM và HL7 đã được sử dụng, nhưng các giải thích về tiêu chuẩn này có sự khác biệt giữa các nhà cung cấp, gây khó khăn trong việc tích hợp thiết bị IHE giải quyết vấn đề này bằng cách định nghĩa các vấn đề tích hợp chung trong quản trị, quy trình lâm sàng, truy cập thông tin và cơ sở hạ tầng IHE lựa chọn các tiêu chuẩn phù hợp để đáp ứng nhu cầu tích hợp và ghi lại chi tiết trong IHE Technical Framework, giúp các nhà cung cấp y tế phát triển sản phẩm dễ dàng hơn và cải thiện tích hợp trong bệnh viện.
Quy trình làm việc của bệnh viện
Quy trình làm việc của bệnh viện là quá trình và luồng thông tin chăm sóc bệnh nhân, bắt đầu từ việc nhập thông tin cá nhân vào HIS bởi bộ phận tiếp nhận khi bệnh nhân đến Thông tin này sau đó được chuyển đến RIS để yêu cầu máy quét và thực hiện thủ tục qua PACS Trước khi quét, RIS thực hiện truy vấn để lấy quy trình làm việc, sau khi quét, ảnh chẩn đoán được gửi đến PACS và tin nhắn MPPS được gửi để thông báo hoàn tất PACS chuyển hướng tin nhắn MPPS đến RIS để nhận diện trạng thái thủ tục, sau đó gửi tin nhắn cam kết lưu trữ đến PACS để xác nhận hình ảnh đã được lưu chính xác Cuối cùng, RIS truy vấn PACS để xác nhận sự tồn tại của ảnh và gửi tin nhắn yêu cầu cập nhật đến HIS để ghi nhận chi phí chụp ảnh vào tài khoản bệnh nhân.
Hình 2 Quy trình làm việc của một bệnh viện điển hình: quá trình và luồng tin chăm sóc bệnh nhân trong một bệnh viện
Số hóa và truyền ảnh y tế ( Digital Imaging and Communication in Medicine)
Dịch vụ DICOM Upper Layer (DICOM Upper Layer Service)
Dịch vụ DICOM Upper Layer (UL) cung cấp một mạng giao tiếp chung cho các đối tượng áp dụng (Application Entities - AEs) để trao đổi tin nhắn DICOM Các AEs là những ứng dụng chẩn đoán hình ảnh có khả năng thực hiện giao tiếp theo tiêu chuẩn DICOM.
Những dịch vụ UL này bao gồm: A-SSOCIATE, A-RELEASE, A-ABORT,A-P- ABORT và P-DATA.
Dịch vụ A-ASSOCIATE giúp thiết lập liên kết giữa hai AEs, hoạt động như một hình thức xác nhận Trong quá trình này, người chấp nhận (acceptor) sẽ phản hồi bằng A-ASSOCIATE response sau khi nhận A-ASSOCIATE indication từ người khởi đầu (initiator) của dịch vụ, như được minh họa trong Hình 4.
Hình 4 Thiết lập liên kết giữa 2 AEs qua dịch vụ A-ASSOCIATE
Trong quá trình thiết lập liên kết, nhiều thông số quan trọng được thương thảo giữa các AEs, bao gồm chức danh AEs đang gọi/đã gọi, địa chỉ trình bày đang gọi/đã gọi, và danh sách ngữ cảnh trình bày Chức danh AEs giúp xác định người yêu cầu và người chấp nhận, trong khi địa chỉ trình bày xác định địa chỉ IP của cả hai bên Danh sách ngữ cảnh trình bày bao gồm việc xác định tên cú pháp trừu tượng và cú pháp chuyển, trong đó cú pháp trừu tượng điều chỉnh trường hợp dịch vụ ghép đổi tượng (Service-Object Pair SOP) có thể thay đổi giữa các AEs Cú pháp chuyển định nghĩa dạng nén áp dụng cho các định nghĩa SOP, bao gồm quy tắc, ngữ nghĩa và dịch vụ của trường hợp Trong DICOM, có hai loại lớp SOP: lớp SOP hỗn hợp và lớp SOP tiêu chuẩn.
SOP đa hợp cho phép tích hợp nhiều loại thông tin trong một trường hợp, trong khi lớp SOP tiêu chuẩn chỉ cho phép một kiểu thông tin duy nhất Ví dụ, tập tin hình ảnh chẩn đoán như ảnh CT thuộc lớp SOP đa hợp, thường chứa thông tin về bệnh nhân, thông tin nghiên cứu và dữ liệu điểm ảnh Ngược lại, chuỗi in thuộc lớp SOP tiêu chuẩn, chỉ bao gồm thông tin liên quan đến việc in ấn.
Dịch vụ A-RELEASE, được sử dụng bởi các AEs để giải phóng liên kết DICOM, là một loại xác nhận quan trọng Dịch vụ này có thể được khởi động bởi bất kỳ AEs nào và bao gồm các thông số như nguyên nhân và kết quả, với các giá trị cố định là "normal" và "affirmative".
Hình 5 Liên kết release giữa 2 AEs qua dịch vụ A-RELEASE
Dịch vụ DICOM UL bao gồm hai giao diện chính là A-ABORT và A-P-ABORT, được sử dụng để hủy bỏ các liên kết A-ABORT cho phép một trong các AEs thông báo về sự ngắt bất thường của liên kết, trong khi A-P-ABORT được áp dụng bởi nhà cung cấp dịch vụ DICOM UL để ngắt các liên kết khi phát hiện lỗi dưới ranh giới dịch vụ DICOM UL Cả hai giao diện này đều thuộc loại không xác nhận, như đã được minh họa trong Hình 6 và Hình 7.
Hình 6 Hủy bỏ liên kết giữa 2 AEs qua dịch vụ A-ABORT
Hình 7 Dịch vụ UL cấp hủy bỏ liên kết qua dịch vụ A-P-ABORT
Dịch vụ P-DATA được sử dụng để trao đổi tin nhắn DICOM giữa 2 AEs Dịch vụ này là một kiểu không xác nhận, minh họa trong Hình 8.
Hình 8 Truyền dữ liệu giữa 2 AEs qua dịch vụ P-DATA.
Cả hai AEs có thể khởi động truyền thông hai chiều thông qua dịch vụ này, trong đó danh sách giá trị dữ liệu trình bày (PDV) đóng vai trò quan trọng Mỗi PDV bao gồm ID bối cảnh trình bày và trường giá trị dữ liệu người dùng, với ID bối cảnh trình bày xác định cú pháp trừu tượng và cú pháp truyền áp dụng cho tin nhắn DICOM Tin nhắn này được gửi đến AE thông qua trường giá trị dữ liệu người dùng, và các thông số DICOM sẽ được thảo luận chi tiết trong phần tiếp theo.
3.1.5 DICOM Uper Layer Protocol ( Giao thức DICOM Upper Layer)
Mỗi kết nối DICOM thành công trải qua ba giai đoạn: thiết lập liên kết, truyền dữ liệu và giải phóng liên kết Trong giai đoạn thiết lập liên kết, dịch vụ A-ASSOCIATE được sử dụng, trong khi giai đoạn truyền dữ liệu sử dụng dịch vụ P-DATA Cuối cùng, giai đoạn giải phóng liên kết áp dụng các dịch vụ A-RELEASE, A-ABORT và A-P-ABORT Tất cả các dịch vụ này đều được hỗ trợ bởi giao thức DICOM Upper Layer, bao gồm bảy đơn vị dữ liệu giao thức (Protocol Data Unit - PDU), trong đó có A-ASSOCIATE.
Các PDU như RQ PUD, A-ASSOCIATE-AC PDU, A-ASSOCIATE-CJ PDU, P-DATA-TF PDU, A-RELEASE-RQ PDU, A-RELEASERP PDU, và A-ABORT PDU được mã hóa theo trật tự byte Big Endian Cấu trúc của những PDU này được minh họa trong Hình 9, Hình 10 và Hình 11, với tất cả kích thước trường được đo bằng byte.
Các loại PDU được thiết lập như sau: 01H cho A-ASSOCIATE-RQ PDU, 02H cho A-ASSOCIATE-AC PDU, và 03H cho A-ASSOCIATE-RJ PDU, được sử dụng bởi dịch vụ A-ASSOCIATE để thiết lập liên kết Đối với dịch vụ A-RELEASE, loại PDU được thiết lập là 05H cho A-RELEASE-RQ PDU và 06H cho A-RELEASE-RP PDU, nhằm giải phóng liên kết Dịch vụ A-ABORT và A-P-ABORT sử dụng A-ABORT PDU với loại PDU được thiết lập là 07H để hủy bỏ liên kết Cuối cùng, P-DATA, với loại PDU được thiết lập là 04H, được sử dụng cho việc truyền dữ liệu.
Tin nhắn DICOM được trao đổi giữa các AEs thông qua P-DATA PDU, và khi kích thước tin nhắn vượt quá giới hạn PDU, tin nhắn sẽ được chia thành nhiều lệnh hoặc đoạn dữ liệu Mỗi đoạn và tiêu đề kiểm soát tin nhắn được đóng gói trong một PDV Các PDV này được gửi tuần tự để đảm bảo thứ tự của các đoạn lệnh trong tin nhắn Đích AE xác định phần cuối của luồng PDV bằng cách kiểm tra bit ít quan trọng thứ 2 trong tiêu đề điều khiển; bit này được đặt là 1 để chỉ ra đoạn cuối và 0 để chỉ ra đoạn tiếp theo Khi đích AE nhận PDV cuối, tất cả các đoạn sẽ được ghép lại để tái tạo tin nhắn DICOM hoàn chỉnh.
Chi tiết về từng trường được trình bày trong Hình 9, Hình 10 và Hình 11, theo tiêu chuẩn “DICOM phần 8: Mạng truyền thông hỗ trợ cho trao đổi tin nhắn (Network Communication Support for Message Exchange)”.
Hình 9 Cấu trúc mã hóa A-ASSOCIATE-RQ/A-ASSOCIATE-AC PDU sử dụng trong thiết lập liên kết.
Hình 10 Cấu trúc mã hóa A-ASSOCIATE-RJ/A-RELEASE-RQ/A-RELEASE- RP/A-ABORT PDU sử dụng trong giải phóng liên kết.
Hình 11 Cấu trúc mã hóa P-DATA-TF PDU sử dụng trong truyền dữ liệu.
Ứng dụng trao đổi tin nhắn DICOM (DICOM Application Message Exchange)
3.2.1 Các thành phần dịch vụ tin nhắn DICOM (DICOM Message Service
DICOM AEs sử dụng dịch vụ tin nhắn phần tử DICOM (DIMSE) để truyền thông Phần của DICOM AE sử dụng DIMSE được gọi là người dùng dịch vụ DIMSE DICOM AE có khả năng tạo ra các ứng dụng tin nhắn DICOM khác nhau, sử dụng dịch vụ DIMSE đa dạng để truyền thông tin ứng dụng cho các người dùng DIMSE cùng cấp Tin nhắn DICOM được gửi đến đích AE thông qua P-DATA PDU, như đã đề cập trong Phần 3.1.5.
DIMSE bao gồm C-STORE, C-FIND, C-MOVE, C-GET, C-ECHO, N-EVENT-REPORT, NGET, N-SET, N-ACTION, N-CREATE, and N-DELETE Mô tả của những dịch vụDIMSE này được tóm tắt trong Bảng 1.
Bảng 1 Mô tả của các dịch vụ DIMSE gồm C-STORE, C-FIND, C-MOVE, C- GET, C-ECHO, N-EVENT-REPORT, N-GET, N-SET, N-ACTION, N-CREATE, and N-DELETE.
C-STORE Dịch vụ này cho phép người dùng dịch vụ DIMSE yêu cầu lưu trữ của trường hợp ghép SOP đến người dùng dịch vụ DIMSE cùng cấp C-FIND Sử dụng dịch vụ này, người dùng dịch vụ DIMSE có thể yêu cầu để phù hợp với một chuỗi các thuộc tính chống lại thuộc tính được thiết đặt của trường hợp DICOM SOP được quản lý bởi người dùng dịch vụ DIMSE cùng cấp Phản ứng của dịch vụ này là trả về một danh sách kết quả chứa các thuộc tính được yêu cầu và các giá trị tương ứng.
C-MOVE Dịch vụ này cho phép người dùng dịch vụ để yêu cầu di chuyển trường hợp ghép SOP lưu trữ trong người dùng dịch vụ DIMSE cùng cấp đến người dùng dịch vụ DIMSE thứ 3.
C-GET Người dùng dịch vụ DIMSE có thể sử dụng dịch vụ này để lấy ra các trường hợp ghép SOP từ người dùng dịch vụ DIMSE cùng cấp. E-ECHO Sử dụng dịch vụ này, người dùng dịch vụ DIMSE có thể xác minh cuối để kết thúc giao tiếp với người dùng dịch vụ DIMSE cùng cấp.
Dịch vụ này cho phép người dùng dịch vụ DIMSE báo cáo một sự kiện liên quan đến trường hợp SOP đến người dùng dịch vụ
N-GET Sử dụng dịch vụ này, người dùng dịch vụ DIMSE có thể lấy ra thông tin từ người dùng dịch vụ DIMSE cùng cấp N-SET Người dùng dịch vụ DIMSE có thể sử dụng dịch vụ để yêu cầu sử đổi của thông tin thực hiện bởi người dùng dịch vụ DIMSE cùng cấp.
N-ACTION Với dịch vụ này, người dùng dịch vụ DIMSE có thể yêu cầu người dùng dịch vụ DIMSE cùng cấp thực hiện một hành động.
N-CREATE Người dùng dịch vụ DIMSE có thể yêu cầu người dùng dịch vụ
DIMSE cùng cấp để tạo một trường hợp SOP sử dụng dịch vụ này. N-DELETE Người dùng dịch vụ DIMSE có thể yêu cầu người dùng dịch vụ
DIMSE cùng cấp xóa trường hợp SOP sử dụng dịch vụ này.
Tất cả các hoạt động DIMSE đều được xác nhận là dịch vụ Khi người dùng dịch vụ DIMSE gửi yêu cầu, dịch vụ DIMSE sẽ thực hiện và trả lại kết quả, như được minh họa trong Hình 12.
Hình 12 Yêu cầu và đáp ứng gốc trong tất cả hoạt động DIMSE.
Mỗi tin nhắn DICOM cần có lệnh thiết đặt đi kèm với tập dữ liệu có điều kiện Các phần tử lệnh thiết đặt khác nhau xuất hiện trong các dịch vụ DIMSE khác nhau, trong đó mỗi phần tử lệnh có thể xác định ba trường: tên rõ ràng, giá trị độ dài và trường giá trị Hình 13 minh họa mã hóa của lệnh thiết đặt DICOM Mã hóa của dữ liệu thiết đặt DICOM được thảo luận chi tiết trong tiêu chuẩn "DICOM Part 5: Data structures and Encoding".
Hình 13 Cấu trúc tin nhắn DICOM được sử dụng trong dịch vụ DIMSE.
3.2.3 Trường tin nhắn trong dịch vụ DIMSE
Giá trị đại diện (VR) xác định kiểu dữ liệu cho trường giá trị trong Command Element, với một số giá trị đại diện phổ biến như Application Entity (AE), Unique Identifier (UI), Unsigned Long (UL), và Unsigned Short (US) Kích thước byte tối đa của AE là 16, trong khi UI là 64 Độ dài của UL là 4 byte và US là 2 byte Dịch vụ DIMSE thường được sử dụng bao gồm C-STORE, C-FIND, và C-MOVE, với các trường tin nhắn quan trọng của những dịch vụ này được thảo luận trong bài viết Thông tin chi tiết về các trường tin nhắn khác trong dịch vụ DIMSE có thể được tìm thấy trong tiêu chuẩn “DICOM Part 7: Message Exchange”.
The message fields required in the C-STORE service include Group Length, Affected SOP Class UID, Command Field, Message ID, Priority, Data Set Type, Affected SOP Instance UID, Move Originator Application Entity Title, Move Originator Message ID, and Data Set The main message fields are summarized in Table 2.
Bảng 2 Trường tin nhắn chính trong yêu cầu dịch vụ C-STORE
(0000,0100) US Trường này được thiết đặt là 0001H cho tin nhắn C-STORE-RQ.
Message ID (0000,0110) US Trường này chưa giá trị thực hiện cụ thể.
Nó phân biệt tin nhắn này với tin nhắn khác.
Priority (0000,0700) US Các mức ưu tiên được thiết đặt thành một trong các giá trị sau:
Giá trị của các mức độ được xác định như sau: THẤP = 0002H, TRUNG BÌNH = 0000H, CAO = 0001H Loại dữ liệu (0000, 0800) của Mỹ xác định các trường giá trị có trong tin nhắn, với giá trị được thiết lập thành bất kỳ giá trị nào khác 0101H.
(0000,1030) AE Gồm DICOM AE Title của người yêu cầu
Trong bài viết này, chúng tôi đề cập đến Message ID (0000,0110) trong trao đổi tin nhắn C-MOVE-RQ, cùng với các hoạt động con C-STORE được thực hiện Tập dữ liệu này là một ứng dụng cụ thể không có thẻ.
The message fields in the C-STORE response service include Group Length, Affected SOP Class UID, Affected SOP Instance UID, Command Field, Message ID Being Responded To, Data Set Type, and Status The key message fields are summarized in Table 3.
Bảng 3 Trường tin nhắn chính trong đáp ứng dịch vụ C-STORE.
Trường tin Tag VR Mô tả nhắn
(0000,0100) US Trường này được thiết đặt là 8001H cho tin nhắn C-STORE-RSP Message ID
(0000,0120) US Giá trị được thiết lập của trường Message
ID (0000,0110) được sử dụng trong liên kết tin nhắn C-STORE-RQ, trong khi Trường Date Set Type (0000,0800) chỉ ra rằng giá trị không tồn tại trong tin nhắn với giá trị được thiết đặt là 0101H Trường Status (0000,0900) cung cấp thông tin về trạng thái dịch vụ C-STORE; ví dụ, mã A7xx chỉ ra rằng người sử dụng dịch vụ DIMSE đã từ chối hoạt động do ảnh hưởng bên ngoài Trong yêu cầu dịch vụ C-FIND, các trường tin nhắn bao gồm Group Length, Affected SOP Class UID, Command Field, Message ID, Priority, Data Set Type, và Identifier, với các trường tin nhắn chính được trình bày trong Bảng 4.
Bảng 4 Trường tin nhắn chính trong yêu cầu dịch vụ C-FIND
Trường tin nhắn Tag VR Mô tả
Trường US được thiết lập là 0020H cho tin nhắn C-FIND-RQ, trong khi Message ID (0000,0110) chứa giá trị thực hiện cụ thể, giúp phân biệt tin nhắn này với các tin nhắn khác.
US Mức độ ưu tiên được đặt là một trong các giá trị sau LOW = 0002H MEDIUM = 0000H HIGH = 0001H Data Set Type (0000,0800
US Trường này xác định trường Data Set tồn tại trong tin nhắn, và giá trị được đặt là giá trị bất kỳ khác 0101H
(No Tag) - Tập dữ liệu, nó được mã hóa định danh cho phù hợp.
The message fields in the C-FIND service response include Group Length, Affected SOP Class UID, Command Field, Message ID Being Responded To, Data Set Type, Status, and Identifier The primary message fields are detailed in Table 5.
Bảng 5 Trường tin nhắn chính trong đáp ứng dịch vụ C-FIND
Trường tin nhắn Tag VR Mô tả
Command Field (0000,0100) US Trường này được thiết đặt là 8020H cho tin nhắn C-FIND-RSP Message ID
(0000,0120) US Thiết đặt giá trị của trường Message ID
(0000,0110) được sử dụng trong liên kết
C-FIND-RQ Message Data Set Type (0000,0800) US Trường này chỉ ra những trường Date
DICOM File
Tập tin DICOM là dạng Composite SOP được lưu trữ trên phương tiện truyền thông như ổ cứng, thuộc về Composite Information Object Definition (IOD) Composite IOD được hình thành từ nhiều mẫu dữ liệu trừu tượng hướng đối tượng, như Patient, General Study, General Series, General Image, Overlay Plane, MR Image và CT Image Mỗi Composite IOD có yêu cầu sử dụng khác nhau cho các mẫu dữ liệu trừu tượng, bao gồm bắt buộc, có điều kiện và tùy chọn Khi một tập tin DICOM được khai báo theo Composite IOD, tất cả dữ liệu trừu tượng bắt buộc phải có mặt, trong khi các mẫu dữ liệu trừu tượng có điều kiện cần phải đáp ứng các điều kiện riêng Các mẫu dữ liệu trừu tượng này được định nghĩa cho ảnh.
CT được trình bày trong Bảng 8.
Bảng 8 Các mẫu dữ liễu trừu tượng trong ảnh CT IOD
Thông tin đối tượng Module Sử dụng
Patient – bệnh nhân Patient – Bệnh Nhân Madatory – bắt buộc
Cinical Trial Subject – đối tượng thử nghiệm lâm sàng
User Option – người dùng tùy chọn
Study – nghiên cứu General Study – nghiên cứu chung
Patient Study – nghiên cứu bệnh nhân
Clinical Trial Study – nghiên cứu thử nghiệm lâm sàng
Series – chuỗi General Series - chuỗi chung
MandatoryClinical Series – chuỗi lâm User option sàng Freme of Reference – khung tham chiếu
Equipment – thiết bị General Equipment – thiết bị chung
Image – hình ảnh General Image - hình ảnh chung
Image Plane - ảnh phẳng Mandatory Image Pixel – độ phân giải ảnh
Conditional – có điều kiện: cần thiết nếu tương phản môi trường được sử dụng trong ảnh này
CT Image - ảnh CT Mandatory Overlay Plane – phủ mặt User option
Trong lập trình hướng đối tượng, các thuộc tính khác nhau được xác định để truyền đạt các giá trị trường hợp trong mẫu dữ liệu trừu tượng Những thuộc tính này có thể yêu cầu hoặc không yêu cầu tùy thuộc vào loại thuộc tính trong tập dữ liệu.
Loại 1: thuộc tính này phải tồn tại với dữ liệu hợp lệ và có độ dài khác không.
Loại 1C: Khi các điều kiện cụ thể được đáp ứng, thuộc tính này phải tồn tại với dữ liệu hợp lệ và có độ dài khác không.
Loại 2: thuộc tính này phải tồn tại, nhưng giá trị độ dài có thể bằng không khi chưa biết.
Loại 2C: khi điều kiện cụ thể được đáp ứng, thuộc tính này phải tồn tại Tuy nhiên, giá trị độ dài có thể bằng không khi chưa biết
Loại 3: thuộc tính này là tùy chọn, và giá trị độ dài có thể bằng 0.
Thuốc tính mô-dun khung tham chiếu được trình bày trong bảng 9.
Bảng 9 Thuộc tính được sử dụng trong module khung tham chiếu
Tên thuộc tính Tag Type Mô tả
1 Định danh khung tham chiếu duy nhất cho một Series – Chuỗi Position Reference
Indicator – vị trí chỉ định tham chiếu
Một phần của giải phẫu bệnh được sử dụng làm tham chiếu bao gồm các cấu trúc như mào chậu, khoang mũi, khuyết cảnh xương ức, khớp mu, mũi ức, ống tai ngoài và xương sườn cụt.
Thông tin về các IOD khác và thuộc tính module được cung cấp trong tiêu chuẩn
“DICOM Part 3: Information Object Definition”.
Phương thức quản lý mạng đơn giản (Simple Network Management Protocol)
Lịch sử của SNMP
Trong những năm 1970, khi các bộ giao thức TCP/IP đang phát triển, quản lý mạng không phải là mối quan tâm lớn do các nhà mạng thường nhỏ và tập trung Công cụ quản lý mạng chủ yếu là ICMP, cho phép kiểm tra kết nối lớp ba và truyền thông đơn giản giữa các thiết bị, với PING là ví dụ nổi bật để theo dõi tình trạng hoạt động của mạng Tuy nhiên, khi mạng mở rộng về kích thước và khoảng cách, khả năng của ICMP trở nên không đủ Để giải quyết vấn đề này, Simple Gateway Management Protocol (SGMP) được phát hành vào năm 1987, cung cấp khuôn khổ quản lý mạng và phương thức theo dõi cổng một cách đơn giản, phục vụ như một giải pháp tạm thời trong khi các giao thức tiên tiến hơn đang được phát triển, với khái niệm quản lý mạng ba mục đích được đề xuất.
High-Level Entity Management System (HEMS)
Simple Network Management Protocol (SNMP)
Common Management Information Protocol over TCP/IP (CMOT)
Đề xuất đã được phân tích bởi Internet Activities Board (IAB) và kết quả được trình bày trong Request for Comment (RFC) 1052 Đề nghị HEMS bị bác bỏ do yêu cầu thực hiện quá phức tạp IAB ưu tiên CMOT qua SNMP vì sự phù hợp với tiêu chuẩn ISO Tuy nhiên, do CMOT chưa hoàn thiện, SNMP được chọn làm giải pháp tạm thời trước khi các giải pháp dài hạn của CMOT được hoàn tất.
Với tính chất đơn giản của giao thức, SNMP nhanh chóng được áp dụng và trở thành tiêu chuẩn quản lý mạng Khi CMOT hoàn thành, SNMP đã được triển khai rộng rãi trên Internet Do đó, vào tháng 5 năm 1990, IAB đã chính thức chọn SNMP làm tiêu chuẩn quản lý mạng.
Đặc trưng của SNMP
Sự thành công của SNMP có thể được quy bởi các bộ tính năng được cung cấp bởi giao thức đơn giản này Lợi thế của SNMP:
SNMP là giao thức nhẹ, đơn giản, được thiết kế để giảm thiểu tác động lên thiết bị điều hành, chiếm ít tài nguyên hệ thống và giảm chi phí thực hiện Phát triển độc lập khỏi hệ điều hành và ngôn ngữ lập trình, SNMP có khả năng hoạt động dễ dàng trên nhiều nền tảng khác nhau.
Các hoạt động chính của SNMP không bị ràng buộc bởi các thiết bị điều hành, cho phép mở rộng dễ dàng để hỗ trợ các thiết bị và thông tin quản lý mới SNMP là giao thức không độc quyền, được xác định rõ ràng và duy trì tích cực bởi IAB.
Cấu trúc của SNMP
Cấu trúc SNMP bao gồm hai thành phần chính là đại lý SNMP và người quản lý SNMP, với sự sắp xếp đặc trưng được minh họa trong Hình 17.
Đại lý SNMP là chương trình tồn tại trong các thiết bị quản lý mạng như router, cầu và trung tâm Chúng cung cấp khả năng lấy và sửa đổi thông tin quản lý từ các thiết bị này Ngoài ra, các đại lý SNMP có thể được lập trình để tự động truyền tải thông tin khi có sự kiện đáng chú ý xảy ra.
SNMP (Simple Network Management Protocol) cho phép quản lý mạng thông qua việc thu thập và chỉnh sửa thông tin từ các đại lý SNMP Người quản lý SNMP, thường được cài đặt trên một máy tính, cung cấp giao diện cho người dùng để kiểm soát và giám sát quá trình quản lý mạng Do tính không đồng bộ trong giao tiếp giữa người quản lý và các đại lý, SNMP có khả năng gửi nhiều yêu cầu mà không cần chờ phản hồi.
4.3.1 Thông tin quản lý cơ sở và định danh đối tượng Để nhóm và nhận diện số lượng lớn các thông tin được duy trì thông qua SNMP, định danh đối tượng (Object Identifier - OID) đã được giới thiệu OIDs là chuỗi số tương tự như số điện thoại, các chữ số được tổ chức theo thứ bậc Mỗi số của một OID đại diện cho một nhánh cụ thể của các cấu trúc quản lý Ví dụ, số đầu tiên của một OID được sử dụng để xác định các tổ chức tiêu chuẩn Hiện nay, có ba nhánh chính đối với các tiêu chuẩn: Uỷ ban tư vấn cho điện báo quốc tế và điện thoại (CCITT), Tổ chức Tiêu chuẩn Quốc tế (ISO) và liên doanh ISO / CCITT Hầu hết các hoạt động quản lý mạng hiện nay hoạt động tại chi nhánh ISO, với 1.3.6.1 OID dành riêng cho cộng đồng Internet.
OIDs được sử dụng để đại diện cho hai loại đối tượng quản lý: đối tượng vô hướng và đối tượng bảng Đối tượng vô hướng đại diện cho các trường đối tượng duy nhất, trong khi đối tượng bảng kết hợp nhiều đối tượng quản lý liên quan vào một bảng Số cuối cùng của một OID giúp phân biệt hai loại đối tượng này, với giá trị 0 xác định đối tượng vô hướng và giá trị khác 0 biểu thị một chỉ số vào bảng.
Trong quá trình thiết lập mạng, OIDs được nhận biết bởi cả người quản lý SNMP và các đại lý SNMP Khi người quản lý SNMP cần truy vấn thông tin từ các thiết bị mạng, họ sẽ đưa các OID tương ứng vào yêu cầu quản lý Các đại lý SNMP sẽ dịch các OID này và phản hồi với giá trị của các tham số được yêu cầu Chẳng hạn, để kiểm tra bộ nhớ khả dụng trên một switch Cisco, người quản lý SNMP sẽ gửi yêu cầu SNMP với OID 1.3.6.1.4.1.9.9.48.1.1.1.6.1 Sau khi nhận yêu cầu, các switch Cisco sẽ kiểm tra bộ nhớ trong và cung cấp phản hồi phù hợp.
OIDs rất hữu ích cho việc truy cập đối tượng quản lý, nhưng khó khăn cho con người do tính chất của chúng Để khắc phục điều này, nhóm OIDs được kết hợp thành một cơ sở thông tin quản lý (MIB), là một tập tin văn bản chứa các bản dịch OIDs sang định dạng dễ đọc MIB thường được biểu diễn dưới dạng một cây trừu tượng, trong đó mỗi đối tượng quản lý được thể hiện qua những chiếc lá Ví dụ, tất cả các thông số SNMP của sản phẩm Cisco đều bắt nguồn từ nút gốc Cisco với OID 1.3.6.1.4.9.
Để truy cập cây MIB, cả người quản lý SNMP và SNMP cần được cài đặt Việc cài đặt MIB bao gồm việc đặt các MIB ở vị trí dễ tiếp cận cho các module.
SNMP cho OID dịch Do được cài đặt một MIB mà nhiều ứng dụng mạng làm việc chặt chẽ với OIDs hơn.
Hoạt động của SNMP
Các hoạt động cơ bản của SNMP tuân theo quy trình yêu cầu và đáp ứng, trong đó yêu cầu thường được phát sinh từ người quản lý SNMP và được đáp ứng bởi các đại lý SNMP Phiên bản đầu tiên của giao thức SNMP, SNMPv1, được mô tả trong RFC 1157, đã giới thiệu bốn hoạt động cơ bản: get, get-next, set, và trap Các phiên bản sau của giao thức đã bổ sung thêm nhiều hoạt động mới nhằm cải thiện khả năng quản lý mạng Bài viết này sẽ trình bày chi tiết bốn hoạt động cơ bản của SNMP.
Các ứng dụng phổ biến nhất của SNMP bao gồm việc lấy thông tin từ các đại lý SNMP thông qua các yêu cầu từ người quản lý Khi một yêu cầu get-request được gửi, các đại lý SNMP sẽ cố gắng lấy giá trị hiện tại của các đối tượng quản lý từ các thiết bị cơ bản Nếu việc lấy thông tin thành công, một thông điệp get-response sẽ được gửi lại cho người quản lý SNMP với các thông tin đã yêu cầu Tuy nhiên, trong trường hợp các đại lý SNMP đang chịu tải nặng, yêu cầu có thể bị bỏ qua.
Việc xử lí một yêu cầu giữa người quản lý và đại lý SNMP được minh họa trong hình
1 Quản lý SNMP muốn truy vấn bộ nhớ xử lý còn lại trên một router Nó kiểm tra cơ sở dữ liệu SNMP nội bộ của mình và xác định các OID cho đối tượng này Một SNMP get-request được gửi đến các đại lý với OID này SNMP.
2 Khi nhận được yêu cầu, các đại lý SNMP truy xuất thông tin yêu cầu từ các cơ sở dữ liệu tại router.
3 Các đại lý SNMP phản hồi với một get-response chỉ ra các xử lý bộ nhớ còn lại.
Hình 19 Xử lý yêu cầu giữa người quản lí và đại lý SNMP
Mặc dù yêu cầu get-request chỉ chứa một OID duy nhất, người dùng có thể thêm nhiều OID khác để lấy nhiều giá trị Tuy nhiên, kích thước của thông điệp get-response bị giới hạn bởi khả năng của đại lý, với kích thước tối đa dự kiến của thông điệp sẽ là.
Một yêu cầu GET có kích thước 484 byte với nhiều OID có thể không được xử lý đúng cách Trong những trường hợp này, các đại lý SNMP sẽ phản hồi bằng cách gửi lỗi không có dữ liệu Thông tin chi tiết về các mã lỗi được đề cập trong phần 4.5.
Các hoạt động trong phần 4.4.1 nhằm mục đích thu thập các đối tượng vô hướng, trong khi các hoạt động get-next-request được thiết kế riêng cho các đối tượng dạng bảng Người quản lý SNMP có khả năng sắp xếp các hoạt động bảng theo thứ tự tuần tự, như được minh họa trong Hình 20, cho thấy ứng dụng của các hoạt động get-next-request.
1 Người quản lý SNMP muốn truy vấn bảng định tuyến có chứa các địa chỉ tiếp theo trong một router Nó xác định các OID cho hàng đầu tiên của bảng định tuyến và tạo ra một get-request đến các đại lý SNMP.
2 Khi nhận được yêu cầu, các đại lý SNMP truy vấn bảng định tuyến và lấy địa chỉ ban đầu.
3 Các tác nhân SNMP phản hồi với một get-response chứa các thông tin thu được.
4 Thay vì xác định OID tiếp theo để truy cập vào bảng định tuyến, quản lý SNMP khởi tạo một get-next-request sử dụng OID cùng cung cấp trong bước 1.
5 Vì get-next-request được sử dụng để tiếp tục truy xuất các OID hiện tại, khi các đại lý SNMP nhận được yêu cầu này, nó lấy địa chỉ thứ hai từ bảng định tuyến.
6 Tương tự như đáp ứng với một hoạt động, các đại lý SNMP phản hồi với một get- response chứa các thông tin thu được Tuy nhiên, trong đáp ứng này OID là địa chỉ thứ hai của bảng định tuyến.
7 Người quản lý SNMP giải nén các OID trả lại trong get-response để truy cập vào các hàng tiếp theo của bảng định tuyến.
Các hoạt động get-next-request do người quản lý SNMP thực hiện có thể tiếp tục cho đến khi nhận được lỗi từ các đại lý SNMP, khi đó chỉ mục cuối cùng của bảng đã đạt tới Những hoạt động này rất hữu ích trong trường hợp kích thước của bảng chưa được xác định trước.
SNMP không chỉ thu thập thông tin về các đối tượng quản lý mà còn cung cấp khả năng thay đổi giá trị của các đối tượng này và thêm mới các hàng trong bảng quản lý.
Vì mỗi đối tượng khác nhau có quyền truy cập riêng, việc kiểm soát quyền truy cập là rất quan trọng Hình 21 minh họa rõ ràng rằng không phải tất cả các đối tượng quản lý đều thực hiện một cách đồng nhất, mà hoạt động này cần được thiết lập một cách cụ thể và có chủ đích.
1 Quản lý SNMP muốn thay đổi tốc độ cổng của một router Nó kiểm tra cơ sở dữ liệu SNMP nội bộ của mình và xác định các OID cho đối tượng này Một set-request được gửi đến các đại lý với OID này.
2 Khi nhận được yêu cầu, đầu tiên các đại lý SNMP xác định đối tượng cấu hình Nếu truy cập là có sẵn, các thiết lập mới được áp dụng tại các bộ định tuyến Tuy nhiên, nếu đối tượng là chỉ đọc, một lỗi được trả lại.
3 Các đại lý SNMP phản hồi với một get-response phản ánh cấu hình đã sửa đổi.
Kiểu thông điệp SNMP
Thông điệp SNMP bao gồm hai phần chính: phần đầu là tiêu đề, chứa thông tin thay đổi theo phiên bản SNMP, và phần thứ hai là tải trọng, giữ nguyên trên tất cả các phiên bản Hình 23 minh họa định dạng thông điệp SNMPv1 cho việc nhận và thiết lập hoạt động.
Hình 22 Định dạng thông điệp SNMPv1
Tiêu đề thông điệp SNMPv1 bao gồm phiên bản và các lĩnh vực truyền thông, đảm bảo rằng người quản lý và đại lý SNMP sử dụng cùng một phiên bản Lĩnh vực truyền thông cung cấp chứng thực giữa hai bên, với giá trị truyền thông được xác định trước trong giai đoạn thiết lập để truy cập thành công vào các đối tượng quản lý Tuy nhiên, SNMPv1 không hỗ trợ riêng tư, khiến thông điệp SNMP có nguy cơ bị bắt trong mạng và các giá trị truyền thông có thể dễ dàng bị trích xuất.
Các thành phần tải trọng của thông điệp SNMPv1 bao gồm dữ liệu giao thức SNMP thực tế, được gọi là đơn vị PDU Phần này mô tả các hoạt động SNMP cụ thể, với các trường PDU quy định các loại PDU như get-request, get-next-request, get-response và set-request.
Yêu cầu định danh (ID) trong lĩnh vực tương quan giúp cung cấp nhiều yêu cầu và đáp ứng khác nhau Các lĩnh vực báo lỗi-trạng thái kết hợp với các chỉ số lỗi để truyền tải thông tin lỗi Chúng được sử dụng độc quyền bởi đại lý SNMP trong PDU get-response, với hai lĩnh vực xác định tình trạng của các hoạt động get/set.
SNMPv2
Sự phát triển nhanh chóng của SNMPv1 đã chỉ ra nhiều thiếu sót của giao thức này, bao gồm khả năng thu thập dữ liệu hạn chế từ các đối tượng quản lý và các lỗ hổng về xác thực và bảo mật Do đó, SNMPv2 đã được giới thiệu như một phiên bản cải tiến, được định nghĩa trong RFC.
RFC 1901 và RFC 1908 tập trung vào việc khắc phục những thiếu sót của phiên bản SNMP trước đó Mặc dù có nhiều biến thể của SNMPv2 nhằm cải thiện tính năng bảo mật, nhưng sự thiếu đồng thuận trong các đề xuất đã khiến việc tăng cường bảo mật phải được trì hoãn đến phiên bản tiếp theo Phần này sẽ trình bày những thay đổi chức năng chính của SNMPv2.
SNMPv1 cung cấp bốn hoạt động quản lý mạng cơ bản, nhưng không đủ cho các hệ thống mạng quy mô lớn Để cải thiện khả năng quản lý, SNMPv2 đã giới thiệu hai hoạt động mới là get-bulk và inform.
Mặc dù hoạt động get trong SNMP cho phép thu hồi nhiều giá trị từ đối tượng quản lý, nhưng các đại lý SNMP thường gặp hạn chế về kích thước thông báo, dẫn đến việc không thể trả lại tất cả giá trị yêu cầu Trong trường hợp này, đại lý SNMP sẽ phản hồi với thông báo lỗi 'tooBig', và không cung cấp thông tin yêu cầu Do đó, người quản lý SNMP cần chia nhỏ các yêu cầu thành nhiều hoạt động get khác nhau để thu thập toàn bộ dữ liệu mong muốn, đặc biệt là khi yêu cầu một lượng lớn dữ liệu từ các đối tượng quản lý khác nhau.
Các hoạt động get-bulk được thiết kế để khắc phục sự thiếu hiệu quả trong giao tiếp SNMP Khởi xướng bởi người quản lý SNMP, hoạt động này cho phép các đại lý SNMP gửi nhiều dữ liệu hơn trong thông điệp phản hồi Cách tiếp cận này giúp loại bỏ sự lặp lại hoặc các hoạt động get-next từ người quản lý SNMP, như được minh họa trong Hình 25.
1 Người quản lý SNMP muốn truy vấn bảng định tuyến có chứa các địa chỉ tiếp theo trong một router Nó xác định các OID cho hàng đầu tiên của bảng định tuyến và tạo ra một yêu cầu get-bulk cho các đại lý Nội dung chi tiết các yêu cầu được đưa ra trong RFC 1905.
2 Khi nhận được yêu cầu, các đại lý SNMP truy vấn các bảng định tuyến và truy xuất danh sách đầy đủ của các địa chỉ.
3 Các đại lý SNMP phản hồi với một get-response chứa danh sách các địa chỉ.
Hình 23 Ví dụ về yêu cầu get-bulk
4.6.1.2 Hoạt động thông báo ( inform)
Trong các hệ thống mạng quy mô lớn, SNMP (Simple Network Management Protocol) là công cụ quan trọng cho các nhà quản lý nhằm duy trì cơ sở hạ tầng hiệu quả SNMPv2 đã giới thiệu các hoạt động thông báo tài khoản cho các hệ thống phân cấp quản lý, giúp cải thiện khả năng quản lý mạng Hoạt động này cho phép thông tin liên lạc giữa các quản lý, từ đó nâng cao khả năng giám sát và điều phối trong quản lý mạng Hình 26 minh họa rõ nét việc ứng dụng các hoạt động thông báo này.
1 Giám đốc một SNMP chịu trách nhiệm cho việc sao lưu mạng muốn thông báo cho người quản lý SNMP gốc rễ của vấn đề mạng vào một trong các nút của nó Một thông báo được bắt đầu vào gốc SNMP manger mô tả vấn đề.
2 Người quản lý SNMP gốc trả lời với một tin nhắn giống hệt nhau thông báo chỉ nhận thành công của thông điệp ban đầu.
Hình 24 Sơ đồ khối mô tả hoạt động thông báo.
SNMPv3
SNMPv3 được phát triển nhằm khắc phục những vấn đề tồn tại trong hai phiên bản trước đó Phiên bản này không phải là một sự thay thế độc lập mà được xây dựng dựa trên nền tảng của SNMPv1 và SNMPv2 SNMPv3 cung cấp các tính năng xác thực và bảo mật nâng cao cho quản lý mạng.
Xác thực là quá trình xác nhận danh tính giữa các bên trong hạ tầng SNMP, trong đó người quản lý và đại lý SNMP chia sẻ một khóa bí mật thông qua một hàm băm an toàn SNMPv3 xác định hai giao thức xác thực: HMAC-MD5-96 là giao thức bắt buộc sử dụng hàm băm MD5, trong khi HMAC-SHA-96 là giao thức tùy chọn dựa trên thuật toán băm SHA-1 Mặc dù chi tiết về các giao thức này không nằm trong phạm vi của dự án, nhưng hình 24 cung cấp cái nhìn tổng quan về ứng dụng xác thực trong SNMP.
Hình 25 Quá trình gửi quá trình xác thực (a), nhận quá trình xác thực (b)
Dựa trên một khóa xác thực chia sẻ, các đối tượng khởi tạo xác thực Mã tin (MAC) và gắn nó vào tin nhắn Khi quá trình xác thực hoàn tất thành công ở bên nhận, tính xác thực và toàn vẹn của thông điệp sẽ được đảm bảo.
SNMPv3 không chỉ cung cấp chứng thực tính toàn vẹn và thông điệp mà còn tích hợp chức năng kịp thời để ngăn chặn thông điệp giả mạo Một cơ chế đồng bộ phức tạp được áp dụng để xác định thời gian giao tiếp với một thiết bị từ xa Nếu phản hồi cho một thông điệp nhận được nằm ngoài cửa sổ thời gian ước tính, thông điệp đó sẽ bị bỏ qua Thông thường, cửa sổ thời gian chấp nhận được được thiết lập là 150 giây.
4.7.2 Bảo mật Để cung cấp bảo mật trong SNMPv3, giao thức mã hóa phải được sử dụng Tuy nhiên, vì những hạn chế về công nghệ mã hóa khác nhau giữa các quốc gia, sự riêng tư là tùy chọn trong SNMPv3 Nếu thực hiện SNMPv3 lựa chọn để sử dụng mã hóa, mã hóa dữ liệu Standard (DES) thuật toán mã hóa phải được sử dụng.
Để đảm bảo an toàn thông tin trong SNMP, một chìa khóa bảo mật cần được tạo ra giữa người quản lý và đại lý SNMP nhằm mã hóa dữ liệu Chìa khóa này chỉ được sử dụng để mã hóa các thành phần của SNMP Mặc dù thông tin chi tiết về quá trình mã hóa không nằm trong phạm vi của dự án, nhưng tổng quan về các ứng dụng mã hóa được thể hiện trong Hình 25.
Hình 26 Mã hóa thông điệp SNMP: (a) quá trình gửi mã hóa (b) nhận quá trình giải mã.
Trong SNMPv3, có ba mức độ bảo mật được giới thiệu Mức độ đầu tiên không cung cấp chứng thực hoặc tính riêng tư, tương đương với SNMPv1 và SNMPv2 Mức độ thứ hai áp dụng xác thực nhưng không có tính riêng tư Cuối cùng, mức độ bảo mật cao nhất yêu cầu cả xác thực và tính riêng tư được sử dụng.
Chứng thực và các giao thức bảo mật cung cấp chức năng bảo mật ở cấp độ quản lý và đại lý Trong khi đó, các giao thức điều khiển truy cập đảm bảo an ninh ở mức độ PDU, được sử dụng trong SNMP để xác định khả năng sửa đổi các đối tượng quản lý bởi các thực thể từ xa.
Trong SNMPv3, cơ chế kiểm soát truy cập được gọi là View-Based Access Control Model (VACM), được giới thiệu trong RFC 2575 VACM xác định quyền truy cập vào cơ sở dữ liệu cho từng nhóm quản lý SNMP khác nhau, với mỗi nhóm đại diện cho một mức độ bảo mật cụ thể Chẳng hạn, người quản lý SNMP gốc có thể được cấp quyền truy cập đầy đủ để sửa đổi tất cả các đối tượng quản lý, trong khi những người quản lý khác có thể chỉ được phép truy cập theo chế độ chỉ đọc Việc thực hiện kiểm soát truy cập trong hạ tầng SNMP giúp nâng cao tính bảo mật và hiệu quả của quy trình quản lý mạng.
