DICOM:DICOM3.0 Network Communication Protocol

reprint:http://blog.csdn.net/zssureqh/article/details/41016091 Background:

The column named Dicom Medical image processing reason is: Bo Master is from the medical image processing algorithm research began to contact the DICOM protocol. The original understanding of the limitations, that dicom is just a simple file format convention, in short, I thought the DICOM protocol is the extension of the DCM file format description. In fact, with the deepening of the medical industry, the DICOM protocol also has a more comprehensive understanding. It is only now found that the DCM file is only a subset of the DICOM protocol, only a data structure in the entire protocol, and the DICOM protocol is more about the medical industry services and related processes of the agreement, so in fact, the most important dicom protocol is the flow of information, the hospital's overall operating process of the agreement. In my opinion, dicom can be divided into two broad categories (this is only from the daily work of dicom-related practitioners): 1) dicom medical image processing, that is, the processing of specific data in DCM files, said the image may be a little narrow, generalized also includes waveform (ECG), video (ultrasound) and so on 2) dicom network transmission, mainly describes the information in the hospital system of interaction between the mode and transmission format. Like my previous research is completely in the first category of "Dicom medical image Processing", once the Dicom file format is resolved in fact, and conventional image processing is no different. If this is all, it can be said that there is no relationship with medical care, and the medical industry is closely linked to the second type of "DICOM network Transmission", which is the daily patient to hospital visits and other general process of abstraction, is the core of the DICOM standard. Therefore, this blog post focuses on "DICOM network Transmission" in the first Link: Network Connectivity (association, in the OSI called Connection), and combined with DCMTK and fo-dicom source code for an example introduction.

DICOM Network transport: Server Side (SERVER,SCP)/Client (Client,scu):

DICOM uses the C/s pattern to describe network transport: the client connects to the server and then uses the services (services) provided by the server. Unlike server and client in a traditional network connection, the server in Dicom is called service class Provider,client called service class User. To establish a DICOM connection (association, called Connection in the traditional OSI model), the client sends a connection request message to the server that mainly describes the Dicom service and related settings that the client expects for this connection The server then looks at the requested information sent by the client, confirms that it supports the service requested by the client and gives feedback (called the Response Information Response message in dicom). The response information is divided into the following categories: 1) If the server supports certain services requested by the client, the server sends a confirmation message (association acknowledge), indicating that the connection is complete, 2) otherwise sending the Reject Message (association Reject), The notification client (SCU) connection failed. All connection-related information is defined in the ACSE (Association Control Service Element) in the DICOM protocol.

Once the network connection is established, the client (SCU) and the service-side (SCP) can interact with the information. The Dimse (dicom message Service Element) in the DICOM standard divides this information into 11 categories (see details in the DICOM protocol, or see my previous blog post http://blog.csdn.net/ zssureqh/article/details/39098621). The type of DIMSE information provided differs depending on the connection information (ACSE). For example, a traditional dicom image to the server for archiving, using C-Store DIMSE message, if you want to use patient name and patient's birth date to query the patient's file, need DIMSE c-find message.

To request a connection:

As described above, the client SCU sends a connection request to the server-side SCP, requesting service and related information. In addition, the following information is included in the request message:

• Requester-side entity name (calling AE Title): Used in dicom services to refer to the symbol of the client (SCU), as in our name;
• Requested entity name (called AE Title): Used to refer to a service-side (SCP) symbol in the Dicom service, as in our name;
• Description context (Presentation contexts): is a service manifest (list of services). The inventory capacity of up to 128 is used to describe the services the client wishes to receive from the server, each of which includes the SOP class and List of Transfer syntaxes.

The above three information is described in more detail below:

AE Title: In Dicom network each DICOM system will be assigned a name, namely application Entity Title, referred to as Aetitle. AE title is used to identify the only (unique) dicom system in the DICOM network (somewhat similar to the IP address in the Internet), so in a DICOM network environment, ensure that each dicom system has a unique name- This work is usually done by a DICOM network administrator. AE title up to 16 characters, usually in the actual application of the use of uppercase letters, of course, you can also use lowercase letters and other ASCII code. During the connection process, the client SCU sends its own AE title (that is, calling AE title) and the service's AE title (that is, called AE title, which, of course, is expected by the client, which may not be the case).

The         presentation contexts:dicom protocol has been in place for more than more than 20 years, and since the DICOM standard was introduced in 1993, new network connections have been added to the DICOM protocol. For example, the MWL service introduced in 1996, Modality Worklist services (for a description of WML can be found in the previous blog post). As a result, most dicom systems only support some of the services in the DICOM standard, such as PACs systems, which often do not provide WML services. Different DICOM services are used for different purposes, and the client (SCU) sends to the service side (SCP) The services it wants to obtain from the server, and the server will see if the services it provides are the clients ' expectations to decide whether to provide them. For these reasons, the client (SCU) sends a list of messages that are less than 128 in length, known as description contexts (Presentation contexts), to the server, each of which represents a service expected by a client. The client uses a dicom identifier to identify each service, the SOP class UID (service Object Pair Class Unique Identifier), which is described in detail in section 4 of the DICOM standard. In the context of the connection, the SOP Class being sent is also called Abstract semantic abstraction Syntax (must be distinguished from syntaxes in the transfer syntaxes, before the post http://blog.csdn.net/ There was a simple comparison of zssureqh/article/details/39213817#t12 's knowledge reserves. The description of this in Offis's wiki is originally in the context of association negotiation, the field where the SOP class was sent is also called "Abstr Act Syntax ".), so the abstract Syntax is synonymous with the SOP Class UID. While transferring the SOP Class UID (that is, abstract Syntax), the encoding format corresponding to the service is sent, i.e. transfer syntaxes. For example, mammography X-rays are usually very large and need to be compressed. When a client sends contextual information to the server, it provides the server with a way to compress a mammogram, such as JPEG2000, and also provides a terminal connection to most image transfer servicesThe non-compression method. As shown in the following:

The client SCU sends three contextual information (up to 128) to the server, and each contextual information (Presentation context) contains a service that the client expects and a number of related transports, such as the Presentation context ID A digital mammography storage service is described in 1, with two encoding methods implicit VR Little endian and JPEG 2000 (lossless compression). Each contextual information is marked with an odd number on the client (min. 1, max. 255), usually monotonically increasing from 1th, 1, 3, 5 、......。 The order of the context information and its internal encoding format can be set freely. As you can see, each service must provide a implicit VR Little endian encoding format, as this is the default transfer encoding in the DICOM protocol.

Accept (Deny) A connection: The server-side SCP accepts at least one contextual information (Presentation context) and other parameters of the SCU request (for example, AE Titles). The server then sends a connection response message to the client to accept the link request. There are three status of link message responses:

• Accept
• To refuse (short)
• Refusal (permanent)

The connection Response message copies the service-side AE title (that is, the called AE title) and the client AE title (that is, calling AE title) directly in the connection request message and returns.        Also returns the response AE title (that is, respponding AE title), which is the same as the service-side AE title (which is required in the OSI protocol, but differs from the DICOM protocol in that the OSI protocol does not require the same). When the message response result is accepted (that is, accepted), the server-side SCP confirms the context information (Presentation context) of the client SCU request, is accepted or rejected, as shown in Appendix D to part 7th of the DICOM standard, As the dicom-service-user of the service trigger, 5 kinds of description contexts are given, IDs 1, 3, 5, 7, 9, but only three of them (IDs 1, 3, 9) are supported on the SCP side. And only one of these transfersyntax is supported for each abstractsyntax server.

As shown, if the presentation context of the SCU request is rejected, the SCP will not send any further information, or if a presentation context is accepted, The SCP chooses one of the transport semantics to be added to the presentation context corresponding to the return information to notify the SCU. If no presentation context is accepted, a reject message is sent, at which point the result code is rejected. When the connection is established, you are ready to transfer the data body.
If the result status code is "rejected (permanent)" indicates that the service-side SCP notifies the client SCU that its request was rejected, subsequent rejections are also denied. This is usually caused by two kinds, one is the requested AE title does not exist, that is, the entity does not exist in the network, and the service-side SCP does not support any service (i.e. SOP Class) requested by the client SCU. In the case of rejection, the SCP can optionally return the diagnostic status code to notify the client of the reason for the rejection; in the worst case, the server-side SCP returns only "calling AE Title not recognized". In the Deny state, the DICOM connection terminates, the SCP and SCU cannot transfer data, while the underlying TCP connection is closed until the client SCU sends the connection request again. to release (terminate) a connection:

After the connection is established, the connecting parties begin to exchange data. If either side wants to terminate the connection (server-side SCP can also), there are two ways:

• Send a connection release message;
• Send a connection termination message;

In the first case, the party receiving the connection release message sends a confirmation message to the sender. The TCP connection is then closed and the DICOM connection terminates, which is the normal way to close the Dicom network connection, and in the second case, after the client sends the discard message, it does not wait for the acknowledgment on the server to actively shut down the TCP connection. This shutdown is not normal, typically occurs after a customer has encountered an unexpected situation, which is the only request information in Dicom that does not require the server to send the response information. Of course, there is a third way of interruption, which is to directly close the TCP connection, which is often caused by a hardware error.

Data exchange (Date Exchange) Dimse:

After a successful connection is made with the ACSE message, the client sends a request that at least one of the context-sensitive services is accepted by the server, and the real data begins to exchange, such as one or more CT images, worklist queries, print requests, and so on. As mentioned above, the DICOM protocol specifies 11 kinds of DIMSE messages, each of which can act as a client request or a response from the server. 11 Types of DIMSE messages are as follows: C-ctore, C-get, C-move, C-find, C-echo, N-event-report, N-get, N-set, N-acton, N-create, N-delete. All messages can be used by different services, according to presentation context, you only need one or more of them.

Pdu-protocol Data Units:

In a dicom system connection, each DIMSE message is split into multiple fragments during transmission, called the Protocol Data Unit, or PDU. The size of the PDU is also negotiated during the connection establishment process. Each PDU fragment contains a number associated with the presentation Context ID. We can think of each presentation context as a logical channel of communication between the two sides, by including the presentation context ID in the PDU, the receiver knows which channel the PDU belongs to and can reorganize multiple PDU fragments.

Dimse Message Data:

Each DIMSE message is transmitted in a different way, and the request message is primarily composed of the following:

• Message ID: Unique indication of each message in the connection
• Affected the SOP class specified in the SOP class UID:DIMSE message, which is the abstract Syntax specified in presentation context.
• Affected SOP Instance UID: A truly transmitted Entity data identifier, such as the mammogram data mentioned in the example above
• Priority: Message prioritization, divided into high, NORMAL, low three, but most of the receiving end are ignored.
• Data Set: the transmitted information.

The response message (response) content is similar to the above. First includes a status message, such as 0 for success, and a message ID of Being responsed to, which copies and returns the message ID of the requester, so that the receiving side knows the destination of the response.

The corresponding implementation in the Open Source Library: DCMTK:

The DCMTK Open Source Library is more focused on layers to implement the connectivity (ACSE) and message transmission (DIMSE) between Dicom application entities (AE), which are mainly divided into Dimse (application layer), ACSE (which belongs to the application layer in the OSI Seven layer Protocol) and Dul (dicom The Upper layer, which interfaces to the TCP/IP layer in the OSI, is the third most significant. The user realizes its Dicom service according to the process stipulated in DICOM standard by using the data structure and operation function of each layer specified in the DICOM protocol provided by DCMTK.

In the dimse.h/dimse.cc , we give the structure of the various services stipulated in the DICOM protocol, and T_dimse_ as prefix, for example T_DIMSE_C_STORERQ/T_DIMSE_C_STORERSP, T_ DIMSE_FINDRQ/T_DIMSE_FINDRSP, T_DIMSE_CECHORQ/T_DIMSE_CECHORSP, etc. in addition, the various services corresponding to the operation function of the declaration, dimse_ as a prefix, such as Dimse_echouser /dimse_sendechoresponse, Dimse_storeuser/dimse_storeprovider/dimse_sendstoreresponse, and so on, the specific function definitions are placed in separate files, Mainly have dimecho.cc, dimfind.cc, dimget.cc, dimmove.cc, dimstore.cc.

In assoc.h/assoc.cc , the corresponding structure of the ACSE application layer is encapsulated, with t_asc_ as prefix, for example t_asc_parameters, T_asc_association, t_asc_ Presentationcontext and so on, and the corresponding operation function of connection establishment or interrupt is given, with asc_ as prefix, for example asc_initializenetwork, Asc_dropnetwork, asc_ Requestassociation, Asc_receiveassociation, Asc_acknowledgeassociation, Asc_rejectassociation, ASC_ Releaseassociation and so on.

The related data structure of dicom Upper layer is given in dul.h/dul.cc , which is prefixed with dul_, for example Dul_associateserviceparameters, Dul_ Presentationcontext, Dul_transfersyntax, DUL_PDV, Dul_pdvlist, and the operation functions of the DUL layer are also given, with Dul_ as the prefix, such as Dul_initializenetwork, Dul_requestassociation, Dul_releaseassociation, Dul_readpdvs, Dul_writepdvs, DUL_NEXTPDV and so on.

Fo-dicom:

Fo-dicom Open Source Library More emphasis on the DICOM message flow to encapsulate, in the implementation of the overall DIMSE message flow framework, the user has been reserved for each stage of the interface, user-friendly continue to customize the implementation.

In the PDU.cs , the corresponding service object of ACSE application layer is given, mainly RAWPDU, PDU, A-associate-rq, A-associate-ac, A-ASSOCIATE-RJ, A-RELEASE-RQ, A-RELEASE-RP, A-abort, PDATATF.

A series of subclasses derived from dicommessage as a base class, such as Dicomrequest/dicomresponse, Dicomcechorequest/dicomcechoresponse, Dicomcstorerequest/dicomcstoreresponse, etc. the package responds to the various messages specified in the DICOM protocol.

In the Dicomservice class, the process of interaction between Scp/scu is given in the whole DICOM protocol, but the connection operation of different ACSE application layer and the message operation of DIMSE layer are provided with corresponding interfaces. The user's own intentions are implemented by invoking subsequent callback functions.

A series of interface classes based on Idicomserviceuser/idicomserviceprovider, Idicomcstoreprovider, Idicomcechoprovider , etc. This part gives the callback function interface of a series of operations in Dicomservice, and the concrete implementation is done by the user.

An entity class based on Dicomclient/dicomserver , which is a required class for the user to build both the SCP and the SCU on their own. It can be said that Dicomclient and Dicomserver are the SCU and SCP of a simple implementation of DICOM services. For example, var server = new Dicomserver<dicomcechoprovider> (12345) in the instance of Fo-dicom, and a SCP server with a port number of 12345 receiving C-echo service is turned on var client = new Dicomclient (), client. Negotiateasyncops (); client. Addrequest (New Dicomcechorequest ()); A simple SCU client that initiates a C-ECHO request is implemented.

DICOM3.0 Standard Analysis: PDU vs PDV:

The interpretation and definition of the PDU (Protocol Data Unit) in the DCMTK3.0 standard is consistent with the blog post described above, but there are two explanations for PDV in the standard are Protocol data value and presentation data value , I prefer the latter. The PDU described above refers to a message fragment passed over the establishment of a DICOM connection, in the English language "If such a message is transferred to a dicom connection, they is cut into pieces, blog post So called Protocol Data Unit (PDUs). " Note Here is the message, not just what we call Dicom message (see Figure 1), but also includes the connection messages used in the ACSE protocol, such as A-ASSOCIATION-RQ, A-ASSOCIATION-RSP, A-abort , this type of message is described in detail in part 8th of the DICOM3.0 protocol (see Figure 2).

The Variable field variable area in the P-DATA-TF PDU structure in Figure 2 is PDV, which is presentation DATA Value. Here PDV refers to several fragments of dicom Message that have been segmented during a specific transmission (this section is described in detail in Appendix E of part 8th of the DICOM3.0 standard, see Figure 3, which is actually the Dimse Message Data mentioned above). It can be verified in the PDU.cs file in Fo-dicom, where the members of the child class P-DATA-TF of the PDU contain a PDV linked list, or list<pdv>.

In a nutshell: PDUs refer to fragments of various messages transmitted in the DICOM protocol (including ACSE and Dimse), PDV refers to the segmented fragment of the DICOM message, and belongs to the Variable field part of the P-DATA-TF class PDU.

ACSE vs Dimse:

ACSE is described in the 8th section of DICOM3.0, which is titled Network communication Support for Message Exchange, so you can conclude that ACSE primarily should be the user connection establishment phase. The establishment of the Connection (association) is the first step in the interaction between the two dicom entities (AE), and the data encoding format and the mode of transmission are negotiated in the connection established by AES. DICOM AES uses the Acse-associate service to establish the connection, and the main use of the Acse-associate service is application context, Presentation context, and user information Items (detailed in Appendix 3 of part 7th of the DICOM3.0 standard). ACSE service mainly has a-associate, A-release, A-abort, A-p-abort, p-data five categories, the corresponding PDU has A-ASSOCIATE-RQ, A-associate-ac, A-ASSOCIATE-RJ, P-DATA-TF, A-release-rq, A-RELEASE-RP, a-abort seven kinds.

Dimse is described in the 7th section of DICOM3.0, which is titled Message Exchange, which explains that Dimse is a provision for DICOM transport messages. DIMSE service types are C-Store, C-get, C-move, C-find, C-echo, N-event-report, N-get, N-set, N-action, N-create, N-DELETE, such as.

The above comparison shows that ACSE is the foundation of Dimse and Dimse is realized on ACSE. As mentioned in PDU vs PDV, DIMSE message is transmitted through the P-DATA-TF service in ACSE after association is established, and various DIMSE messages are split into PDVS into P-DATA-TF variable Field. As shown in the following:

Finally, by looking at the ENDPDU and PROCESSPDATATF functions in the fo-dicom, you can have a more visual understanding of what kind of service the PDU belongs to in ENDPDU by reading the first 6 bytes of the PDU within the ACSE function, such as A-associ ATE-RQ, A-associate-ac, A-ASSOCIATE-RJ, P-DATA-TF, A-release-rq, A-RELEASE-RP, A-abort; when the PDU belongs to the P-DATA-TF type, Go inside the PROCESSPDATATF function. By extracting the PDVS from the Variable field in the P-DATA-TF PDU to determine what kind of Dimse message, mainly C-STORE-RQ/C-STORE-RSP, C-FIND-RQ/C-FIND-RSP, c-echo-rq/ C-ECHO-RSP, C-MOVE-RQ/C-MOVE-RSP and so on.

Resources:

Http://support.dcmtk.org/redmine/projects/dcmtk/wiki/DICOM_NetworkingIntroduction#Protocol-Data-Units, the English original of this article

http://medical.nema.org/medical/dicom/current/output/html/part07.html,DICOM3.0 Standard part 7th

http://medical.nema.org/medical/dicom/current/output/html/part08.html,DICOM3.0 Standard part 8th

Https://github.com/redmoxie/fo-dicom,fo-dicom Source

Http://support.dcmtk.org/redmine/projects/dcmtk/files,DCMTK Source

Follow-up Column blog introduction:

Develop Web PACs applications with PHP Skel combined with DCMTK

Direct operation of DICOM data with Oracle

Application of the asynchronous programming pattern of C # in fo-dicom

Practical testing of VMware three network connection modes

DICOM:DICOM3.0 Network Communication Protocol