DICOM Networking¶

• Table of contents
• DICOM Networking
  • Requesting an Association
    • AE Titles
    • Presentation, SOP Classes and Transfer Syntaxes
  • Accepting and Rejecting Associations
  • Releasing and Aborting Associations
  • Data Exchange (DIMSE)
    • Protocol Data Units
    • DIMSE Message Data
  • UIDs
  • Acknowledgements

DICOM uses the client/server model in order to describe network services: A client connects to the server and uses services of that server. DICOM uses the term "Service Class Provider (SCP)" instead of "server" and "Service Class User (SCU)" instead of client. Both terms are taken from the OSI standard. For starting a DICOM connection (an "association" in DICOM-speak), the client (SCU) sends an Association Request message to the server (SCP) describing the DICOM services and options that the client wants to use on the connection. The server looks at the proposed services and options and sends back a message to the client, telling the client whether which of the proposed services it supports. If some can be supported, an "Association Acknowledge" message is used which then establishes the association (connection). Otherwise, the server sends an "Association Reject" message to the client which tells the SCU that the connection establishment has failed. Note that there can be other reasons for a Association rejection besides unsupported services. All Association-related messages are belonging to the category of ACSE ("Association Control Service Element") message in DICOM (again, this was taken over from the OSI protocol).

Once the association is established, SCU and SCP can exchange messages on the connection. Those messages belong to another category called "DIMSE" (DICOM Message Service Element) which includes 11 different message types (and for each a request and a response message). The type of DIMSE message that can be used on an established association depends on the very service that has been negotiated using ACSE. Different services permit different DIMSE message types. For example, as we will see, the transfer of a DICOM image to an image archive uses the DIMSE C-STORE message, while searching a patient within the archive by the patient' name and patient's birth date uses the C-FIND message type.

The next subsections describe in some more detail how association negotiation works. There is another page that explains how to read DCMTK logs for association negotiation.

Requesting an Association¶

As described, an SCU sends the SCP an association request with the services and options to be used with the server. Besides others, this request contains the following information:

• Calling AE Title: Symbolic DICOM name of the SCU that wants to use a service on the SCP
• Called AE Title: Symbolic DICOM name of the SCP that the SCU wants to talk to
• Presentation Contexts: List of services that the SCU wants to use on the connection to the SCP (128 maximum), each consisting of:
  • SOP Class: The "name" of the DICOM service proposed to the SCP
  • List of Transfer Syntaxes: 1 or more proposed encodings that can be used for this SOP class

Let's look at this connection request in more detail.

AE Titles¶

Each DICOM system on the DICOM network gets assigned (usually configurable) a name called "Application Entity Title", shortly "AE Title", that identifies that DICOM system uniquely on the network. That means that on a single DICOM network, all systems must have a unique AETitle. This is usually ensured by the network administrators. An AE Title consists of a maximum of 16 characters. In practice, very often only capital letters are used, though it is also allowed to use small letters or even some other ASCII characters. When sending the association request the SCU tells the server its own AE Title ("Calling AE Title"), and the AE Title that (it thinks) the SCP uses ("Called AE Title").

Presentation, SOP Classes and Transfer Syntaxes¶

DICOM evolves for more than 20 years, thus many new networking have been introduced into the standard from its beginning in 1993. For example, the modality worklist service was introduced in 1996. Thus most DICOM systems do support the same network services but actually only understand a small subset: A PACS client does not have to act like a worklist server. Since different DICOM services are used for different purposes, the SCU proposes only the services it wants to use with an SCP, and the SCP can decide from the proposed services whether it can serve the client's wish list. For this reason, the client sends a list of 1-128 so-called Presentation Contexts to the server, each of them representing a single service the SCU wants to use. The service itself is identified by the SCU by sending the DICOM identifier of that service, the "SOP Class UID" (SOP = Service Object Pair) which is defined for each service in DICOM part 4. In the context of association negotiation, the field where the SOP class is sent is also called "Abstract Syntax". For now we use it as a synonym for SOP class. Along witch each SOP Class UID, the server sends a list of so-called Transfer Syntaxes which are the encodings the SCU proposes for this service. Transfer Syntaxes are explained below in more detail, but here is a typical example. There is a service (SOP Class) to store Mammography images from the SCU to the SCP. Mammography images can have a quite big memory size, so it makes sense to compress them. Thus, the SCU could offer the SCP a transfer syntax that includes compression of the mammography pixel data, e. g. a JPEG-2000 compression-based transfer syntax, and alternative as a second transfer syntax one that doe not compress the pixel data and must be supported by any SCP that accetps the mammography image SOP class in general. The figure below shows how an SCU could propose two Presentation Contexts, one for the transfer of mammography images and one for CT images. On top, let's add the SOP class for querying a modality worklist. The transfer syntaxes offered can be different for every of the proposed Presentation Contexts:

• Presentation Context ID 1
  • Abstract Syntax: Digital Mammography X-Ray Image Storage - For Presentation
  • List of Transfer Syntaxes:
    1. Implicit VR Little Endian
    2. JPEG 2000 Image Compression (Lossless Only)
• Presentation Context ID 3
  • Abstract Syntax: Modality Worklist Information Model - FIND
  • List of Transfer Syntaxes:
    1. Implicit VR Little Endian
    2. Explicit VR Little Endian
• Presentation Context ID 5
  • Abstract Syntax: JPEG Lossless, Non-Hierarchical (Process 14)
  • List of Transfer Syntaxes:
    1. Implicit VR Little Endian
    2. Explicit VR Little Endian

As noted, a maximum of 128 Presentation Contexts can be proposed, each proposing one Abstract Syntax (~SOP Class) that again includes a list of an arbitrary number of Transfer Syntaxes. Every presentation contexts gets assigned a unique Presentation Context ID by the SCU; only odd numbers are permitted which makes the lowes possible Presentation Context ID 1 and the highest 255. It is common to start with 1 and then monotonically increase them by 2 for each following one (1,3,5,...). The order of Presentation Contexts, and the order of Transfer Syntaxes in the request can be arbitrary. Note that one always have to propose Little Endian Implicit, DICOM's default transfer syntax.

Accepting and Rejecting Associations¶

In case the SCP can accept at least one of the Presentation Contexts, and all other parameters proposed (e.g. the AE Titles used) then it can accept the connection by sending an Association response message. It has one of three result status codes:

• Accepted
• Recjected (transient)
• Rejected (permanent)

In any case the response will include again the Calling AE Title and the Called AE Title which both are just copied from the request. In addition, a Responding AE Title is included which must be the same as the Called AE Title (remember, this is an OSI protocol; in OSI there is probably no requirement that both are the same but they decided to fix the value in DICOM).

If the result code is "Accepted" then the SCP includes a copy of the list of Presentation Contexts that the SCU has sent and for each of the proposals it does the following: The SCP marks for each requested Presentation Context whether it accepts or rejects it. In case of rejection, no further information is conveyed. In case it accepts a Presentation Context it selects exactly one of the proposed Transfer Snytaxes of that very Presentation Context and copies this (and on other Transfer Syntaxes) into the Presentation Context. From this information the SCU can see, which of the proposed services actually are supported by the SCP. If none, then the SCP would not send an Accepted but a Rejected result status. After this message exchange (Association request and acceptance), the DICOM connection (association) is established and is ready to transferring the actual data.

In the case the result is "Rejected (permanent)" the SCP can tell the SCU instead that his request is rejected, and will be rejected in the future. The reason could be that the requested Called AE Title is not available on the server or none of the SOP classes requested will ever be supported. A additional result code ("Diagnostic") can optionally be added by the SCP that tells you more about the reason of the rejection. In the worst case it contains "no reason" but also codes like "Calling AE Title not recognized" are offered by the standard. After the rejection message was sent, the DICOM association is over, i.e. neither SCU nor SCP could send actual data of this connection. Instead, the underlying TCP connection is closed and a new association request would have to be initiated.

Releasing and Aborting Associations¶

After association establishment both parties can exchange data (discussed further below). If either one (also the SCP can do this!) likes to close the connection, it has two possibilities:

• Sending an Association Release message
• Sending an Association Abort message

In the first case the other side receives the Association Release messages, and sends back a short confirmation message. Afterwards, the TCP connection is closed and the connection is over. This is the polite way of saying good bye in DICOM. The other way is to send an Association Abort message. In that case the sender does not even wait for a confirmation (there is none even defined in DICOM) but just closes the TCP connection after the message has been sent. This is the unpolite way of saying good bye. It is normally used if an unexpected situation is encountered and the sender wants to leave the association in a controlled but "urgent" way. It is the only request message in DICOM where no response from the receiver is expected.

In fact, there is a third way to leave: Just closing the TCP connection. This is not only not polite but (of course) not conforming to the DICOM standard. However it happens in practice, of course, e.g. due to unexpected application behavior of hardware failure.

Data Exchange (DIMSE)¶

After the association has been successfully negotiated using ACSE messages, i.e. at least one of the Presentation Contexts is accepted by the SCP, the actual data exchange can take place. This can include sending one or more CT images, worklist queries, or print jobs to the SCP. There are a couple of different DIMSE message types, each available as as a request and as a response message:

• C-STORE
• C-GET
• C-MOVE
• C-FIND
• C-ECHO
• N-EVENT-REPORT
• N-GET
• N-SET
• N-ACTION
• N-CREATE
• N-DELETE

As noted before, all those message types are used by different SOP classes, i.e. you only need only one or a few of them for each service that you negotiate. The difference between C-XXX and N-XXX ("Composite" versus "Normalized") is not so interesting for the moment. Just keep in mind that they are used from different SOP classes (e.g. Query/Retrieve from a PACS uses some of the C-style messages whereas the printing DICOM images uses N-style messages).

Protocol Data Units¶

If such a message is transferred on a DICOM connection, they are cut into pieces, so called Protocol Data Unit (PDUs). The PDU size is also negotiated during association negotiation. Evey PDU carries a reference number that relates back to one of the Presentation Context IDs that have been accepted by the SCP before. One could think of every accepted Presentation Context as a logical channel that is available for communication. Since each Presentation Context contains excactly one accepted Abstract Syntax (again, now think of it as being identical to SOP Class) with exactly one Transfer Syntax. By including the Presentation Context ID into each PDU the recever knows to which logical channel (SOP Class and Transfer Syntax encoding) this packet of data belongs to.

DIMSE Message Data¶

All DIMSE message types differ a little bit in the information they can transport. Overall the following is contained in the request (incomplete list):

• Message ID: The message ID of this messages (must be unique on the association)
• Affected SOP Class UID: The SOP Class this DIMSE message refers to (identical to the one of the referenced Presentation Context)
• Affected SOP Instance UID: The identifier of the very data instance being transported, e.g. the transported CT image.
• Priority: Fixed to either one of the values "HIGH", "NORMAL" and "LOW". Ignored by most receivers.
• Data Set: Actual Bulk data, e.g a CT Image, a worklist query, or something else. If message does not need workload (e. g the C-ECHO message type), it is not included.

The response contains similar fields. On top a a status code is included (0 means success, there are other codes which are not an error in some services). Also the field "Message ID Being Responded To" instead of Message ID is returned and contains a copy of the request's Message ID. This way the receiver of the response knows which of its DIMSE messages this response refers to (this is mostly interesting for DICOM's asynchronous transfer mode which is rarely supported in practice).

UIDs¶

You might have wondered what a UID (Unique Identifier) is since that term popped up a lot so far. A UID identifies something uniquely, in a world-wide fashion, and usually is a string of numbers that are separated by dots. Here is an example: "1.2.840.10008.5.1.4.1.1.2". UIDs are a used in two different ways in the DICOM context:

On the one hand, UIDs are used within the standard and are used to identify Transfer Syntaxes, SOP Classes and other stuff. That means that when the SCU sends a SOP Class UID to identify the DICOM services it likes to use by sending the related unique identifier in above format. The receiver can look up this UID in the standard and thus can recognize which service is meant. In fact the UID example below denotes the CT Image Storage SOP Class, which is the DICOM service to transfer CT Images. As another example, the one for MR would be "1.2.840.10008.5.1.4.1.1.4". Thus when I write above that the SOP Class UID is conveyed during association negotiation then such a UID string is meant.

On the other hand, every DICOM object that is created gets assigned such a UID by the creating application. A DICOM object can be a CT image, or also a print job. Also in this context, every single UID that is created by an pplication must be world-wide unique! There are some guidelines how this can be achieved but we won't describe here. Furthermore every DICOM Series and Study also gets assigned such a unique identifier each. If you don't know what this is: We get back to this topic later.

The structure of a UID follows some rules: A maximum of 64 characters is permitted, no dot can be follow directly by another dot, and no leading zeros are permitted (e.g. ".1.0.33." is permitted as part of a UID whereas ".1.033" is forbidden. An important point to understand is that the structure of a UID should never be interpreted in any way: You only should decide whether you either know a UID, or you don't know it. Never try to judge a UID by looking at similarities or a common string of starting number and dots.

Acknowledgements¶

This tutorial was supported through the NA-MIC project . NA-MIC is a national research center supported by grant U54 EB005149 from the NIBIB NIH HHS Roadmap for Medical Research Program.

Written my Michael Onken (DCMTK Team and Open Connections GmbH).