DICOM：DICOM3.0網絡通訊協議（續）

轉載：http://blog.csdn.net/zssureqh/article/details/44278693

題記：

近一年來一直堅持週末寫博客，整理工做和閒暇之餘的點點滴滴。對於新知識點、新技術的涉獵會單獨成文，對於與DICOM相關的知識統一放在了DICOM醫學圖像處理 專欄裏，其實DICOM英文全稱是Digital Imaging and Communications in Medicine，即醫學數字成像和通訊。這就代表DICOM標準至少應該分紅圖像處理和網路通訊兩大部分。以前也探討過專欄名稱 的問題，總而言之因爲歷史緣由和自身懶惰一直沒有抽出精力再開一個專欄，暫且如此吧。雖然沒有從新開專欄，可是爲了方便你們分類查閱，在2015新一年裏我將按照標題前綴來簡單劃分一下類別：與圖像處理相關的，諸如壓縮/解壓縮、字段增刪改、圖像數據處理，專欄博文標題繼續以本來的DICOM醫學圖像處理： 爲前綴，而與DICOM網絡傳輸相關的將前綴更換爲更簡潔的DICOM：。

背景：

以前博文中專門梳理過DICOM標準中與網絡傳輸相關的內容（詳情參見：DICOM醫學圖像處理：全面解析DICOM3.0標準中的通信服務模塊 、DICOM醫學圖像處理：DICOM網路傳輸 ），近期在從新整理fo-dicom開發的PACS相關測試用例時，對fo-dicom和mDCM兩個庫進行了再一次比較，與此同時從新翻閱了DICOM3.0標準中的部分章節，發覺以前曾經忽略了其中的不少細節，特編寫此文。一來對以前該系列博文的疏忽和BUG進行補充修復，二來加深一下DICOM網絡傳輸的瞭解。
PS: DICOM醫學圖像處理專欄中的每一篇文章成文以前，我都盡我所能查閱、翻譯相關資料，編寫、調試本地示例，以求文章的高質量，但畢竟我的時間和精力所限，博文中不免會有紕漏，建議閱讀時請儘量先瀏覽該主題的最新發表博文，由於那裏每每會給出以前博文中的錯誤。另外若是發現問題歡迎留言或郵件交流。

DICOM網絡傳輸：

DIMSE：

DICOM3.0標準的第7部分標題爲「Message Exchange」，從標題能夠看出第7部分着重介紹DICOM協議中的網絡傳輸部分。官方對於該部分的介紹以下：

This Part of the DICOM Standard specifies the DICOM Message Service Element (DIMSE) . The DIMSE defines an Application Service Element (both the service and protocol) used by peer DICOM Application Entities for the purpose of exchanging medical images and related information.

The DIMSE provides its services by relying on the DIMSE protocol. The DIMSE protocol defines the encoding rules necessary to construct Messages. A Message is composed of a Command Set (defined in this part of the DICOM Standard) followed by a conditional Data Set (defined in PS 3.5). 

按照以前DICOM醫學圖像處理：全面分析DICOM3.0標準中的通信服務模塊中的描述，將DIMSE歸類爲表示層，用於指出DICOM協議中提供的各項基礎服務，也就是DIMSE Protocol中規定的 服務原語 （Service Primitives），爲對等DICOM 應用實體（Application Entity）之間交流服務。以下圖所示：
 

這裏所謂的DICOM Application Entity，從實際來看就是咱們現實生活中看到的使用DICOM標準的各類軟件或應用，也能夠指安裝此軟件或應用的設備；從概念 來看，就是由DICOM3.0標準中的第3部分（Information Object Definitions）、第4部分（Service Class Specifications）、第5部分（Data Structure and Encoding）、第6部分（Data Dictionary）共同定義出的模型。
DIMSE中消息由指令（Command）和數據集（Data Set）構成，詳細結構這裏就不介紹了，有興趣可翻閱DICOM3.0標準第7部分第6.3章節。這裏咱們主要介紹一下DIMSE協議規定的服務，爲了更好地理解下文，在閱讀以前請轉到「知識點補充」一節，熟悉相關概念，瞭解彼此之間的區別，尤爲是SCP（Service Class Provider）與DIMSE-Service-Provider、SCU（Service Class User）與DIMSE-Service-User。
DIMSE消息服務元素支持對等DIMSE-Service-User之間交互，其中對DIMSE-Service-User雙方分別扮演invoking DIMSE-service-user和performing DIMSE-service-user角色。這與咱們常提到的SCU和SCP類似，一方觸發（invoking)，一方響應(performing）。雖然雙方扮演的角色不一樣，可是名稱中都帶有user，意思就是說雙方都是DIMSE協議的使用者，這就是與傳統SCU、SCP容易混淆的地方。具體的區別可參見「知識點補充」一節。
DIMSE提供的兩種服務示意圖以下：
 

DIMSE服務是在鏈接創建基礎之上，即DIMSE層下方是DICOM Upper Layer Protocol層，關於DICOM Upper Layer協議的介紹在DICOM3.0標準中第8部分。

DICOM Upper Layer Service：

DICOM3.0標準第8部分標題爲「Network Communication Support for Message Exchange」，該部分描述了DICOM應用實體間用於通訊（Communicaton）的通用服務（generic services）。該類服務與OSI模型中的會話層、表示層和應用層相關，DICOM標準將其統一稱之爲UL Service，該服務是ACSE服務（Association Control Service Element）和OSI表示層服務的子集。剛剛上文提到的DICOM標準第7部分中詳細介紹如何使用Upper Layer Service來完成DICOM應用實體間的交互。
UL Service上層服務包括A-ASSOCIATE、A-RELEASE、A-ABORT、A-P-ABORT、P-DATA五種，以下圖所示：
 

對於上圖中的各類服務，DICOM3.0第8部分給出了詳細定義，例如在對等DICOM實體間交互使用的各類參數。這裏以A-ASSOCIATE爲例簡單介紹一下，以下圖所示：
 

上圖是A-ASSOCIATE服務的整個流程，從圖中能夠更清晰、更直觀的看出以前invoking DIMSE-service-user/performing DIMSE-service-user與SCU/SCP概念之間的區別，圖中左右兩側的Requestor和Acceptor（左右兩側都是協議棧的上層N）相對於中間（中間是協議棧中的下層N-1）來講都是服務的使用者，即invoking DIMSE-service-user和performing DIMSE-service-user。而若是從服務實現角度來看一方是請求端（Requestor），一方是響應端（Acceptor），也就是DICOM中最多見到的SCU和SCP。

DICOM Upper Layer Protocol for TCP/IP：

服務是創建和依託於協議之上的，DICOM標準第8部分第9章着重介紹了DICOM UL Service使用的協議。UL Protocol創建在TCP/IP協議之上，在網絡交互中DICOM上層實體（即DICOM UL entity）由系統指定的端口號來標定。所以在通訊過程當中須要創建TCP鏈接，一個TCP連接應當只支持一個且僅有一個DICOM UL Association。

DICOM Upper Layer State Machine：

與傳統TCP鏈接創建類似，當DICOM上層實體欲創建一個連接時，會發出TRANSPORT CONNECT請求原語到TCP傳輸層。一旦接收到TCP傳輸層的鏈接確認語義，此時會在創建起的TCP鏈接上發送A-ASSOCIATE-RQ PDU。
鏈接創建後，在TCP鏈接之上傳輸PDUs（PDU的結構詳細介紹參照DICOM3.0標準第8部分第9.3節）遵循DICOM上層協議狀態機 ，即DICOM Upper Layer State Machine 。狀態機（尤爲是有限狀態機，Finite State Machine）是軟件工程領域的一種重要工具，不少應用的模型都是狀態機，例如代碼的編譯，在《編譯原理》一書中有對狀態機的介紹；例如數字電路（單片機/嵌入式開發）中，各類事務和中斷之間的時序邏輯設計；乃至咱們當今使用的計算機就是使用有限狀態機做爲計算模型的等等。百度百科中對於有限狀態機FSM，Finite State Machine的介紹以下：

除了建模這裏介紹的反應系統以外，有限狀態自動機在不少不一樣領域中是重要的，包括電子工程、 語言學、計算機科學、哲學、生物學、數學和邏輯學。有限狀態機是在自動機理論和計算理論中研究的一類自動機。在計算機科學中，有限狀態機被普遍用於建模應用行爲、硬件電路系統設計、軟件工程，編譯器、網絡協議、和計算與語言的研究。 

DICOM UL Service Protocol是創建在TCP協議之上的，TCP協議一般使用一個具備11種狀態的有限狀態機11種狀態的有限狀態機來表示，在DICOM3.0標準第8部分第9.2章節中給出的DICOM Upper Layer State Machine使用了多大13中狀態（State）來描述整個流程。與其相關的事件（Event）有19種，可觸發的動做（Action）多達28種，整個狀態轉移表至關複雜，以下圖所示：
 

DICOM3.0標準中給出的是一張二維狀態轉移表，查看起來比較累，不夠直觀，下圖是我手繪的狀態機轉換圖，因爲手頭沒有順手的UML建模工具只能手繪，你們就將就看看吧。
 

上圖中的圓圈表明的是DICOM Upper Layer Protocol的各類狀態，帶箭頭的連線是個狀態之間的轉換，箭頭連線上的數字分別表明各類觸發狀態改變的事件。理解了上圖就應該理解了整個DICOM通信創建的基本流程，因爲時間關係在本博文中就不對該狀態圖詳細展開了，後續博文中會以fo-dicom、dcmtk爲實例詳細介紹狀態圖中的各類狀態。

fo-dicom實例講解：

以前專欄裏介紹過fo-dicom的設計結構，這裏簡單的說一下其中關於DICOM網絡通信服務的基類是DicomService，至於實例講解部分，這裏先作個預告，下一篇博文中再詳細介紹。

知識點補充：

協議Protocol：

協議Protocol：這裏的協議指的是計算機領域的網絡協議（其餘非相關領域，諸如貿易之類的，請你們自行腦補，我不懂）。協議爲計算機網絡中進行數據交換而創建的規則、標準或約定的集合。由三個要素組成，即語義、語法和時序。百度百科的描述爲：

(1) 語義。語義是解釋控制信息每一個部分的意義。它規定了須要發出何種控制信息，以及完成的動做與作出什麼樣的響應。
(2) 語法。語法是用戶數據與控制信息的結構與格式，以及數據出現的順序。
(3) 時序。時序是對事件發生順序的詳細說明。（也可稱爲「同步」）。
人們形象地把這三個要素描述爲：語義表示要作什麼，語法表示要怎麼作，時序表示作的順序。 

服務原語Service Primitive：

服務原語（Service Primitives）：用戶和協議實體間的接口,其實是一段程序代碼，但其具備不可分割性。經過服務原語能實現服務用戶和服務提供者間的交流。服務原語只有四種類型，分別是請求（Request）、指示（Indication）、響應（Response）、確認（Confirm）。
【注】： 與協議不一樣的是，服務原語用於服務提供者與服務用戶，而協議是用於服務用戶之間的通訊.協議是控制對等實體之間通訊的規則，是水平的。服務是下層經過層間接口向上層提供的功能，是垂直的。協議的實現保證了可以向上一層提供服務，要實現本層協議還需使用下層提供的服務。

DICOM中各類user/provider：

• DIMSE-service-user：that part of an application entity which makes use of the DICOM Message Service Element.
• DIMSE-service-provider： an abstraction of the totality of those entities which provide DIMSE services to peer DIMSE-service-users.
• invoking DIMSE-service-user：the DIMSE-service-user that invokes a DIMSE operation or notification.
• performing DIMSE-service-user：the DIMSE-service-user that performs a DIMSE operation or notification invoked by a peer DIMSE-service-user.
• Service Class User：role of an Application Entity that uses a DICOM network service;typically, a client. Examples: imaging modality (image storage SCU, and modality worklist SCU),imaging workstation (image query/retrieve SCU)
• Service Class Provider： role of an Application Entity that provides a DICOM network service; typically, a server that performs operations requested by another Application Entity(Service Class User). Examples: Picture Archiving and Communication System (image storage SCP, and image query/retrieve SCP), Radiology Information System (modality worklist SCP).

【注】： 要區分invoking DIMSE-service-user/performing DIMSE-service-user與Service Class SCU/Service Class SCP就須要提到上文中的協議（Protocol）和服務（Service）。以OSI開放模型中的七層協議爲例，invoking DIMSE-service-user/performing DIMSE-service-user的命名方式是以服務和協議角度出發，模型上層依賴於模型下層，在對等實體中全部對等實體兩端的DIMSE上層（DIMSE-service-user）都是DIMSE下層（DIMSE-service-provider）服務的使用者；Service Class SCU/Service Class SCP是從現實建模角度出發，將DICOM網絡通訊對等實體兩端分別當作服務使用者和服務提供者。

狀態機State Machine：

狀態機中的狀態(State):狀態，State，就是一個系統在其生命週期中某一時刻的運行狀況，此時系統會執行一些動做，或者等待一些外部輸入。
狀態機中的事件(Event):事件，Event，就是在必定時間和空間上發生的對系統有意義的事情。
狀態機中的動做(Action):當一個事件被狀態機系統分發，即響應該事件，此刻系統會經過相關動做來完成響應。