The DICOM associationhow two devices agree to talk
Before a scanner can send an image, or a viewer can ask a question, the two sides open an association: a short negotiation that fixes who is talking, what they will talk about and how the data is encoded. Every DICOM network exchange starts here.
- DICOM
- Network (TCP)
- Internal action
- Dashed = reply
Tip: click an arrow or box in the diagram to jump to that step. Time flows top to bottom.
Open the TCP connection
Core stepWhat happens
DICOM runs on top of TCP. The calling side opens a normal TCP connection to the IP address and port of the other device. Nothing DICOM-specific has happened yet.
Why it is needed
If this step fails, the problem is the network: a wrong IP address or port, a firewall, or a service that is not running. No DICOM log line will explain it.
Technical details
- PS3.8: port 104 is the well-known DICOM port (needs privileges on many systems); otherwise use the registered port 11112
- Port numbers must be configurable: any port works if both sides are set to it
- TLS can wrap the connection (Secure Transport Connection Profiles)
A-ASSOCIATE-RQ: propose what to talk about
Core stepWhat happens
The caller sends its request. It states who it is (Calling AE title), who it wants (Called AE title) and a list of presentation contexts: for each SOP Class it needs, the transfer syntaxes it can use.
Why it is needed
Both sides must agree up front on the services and the encoding. This is the check that stops a device from sending data the other side cannot read.
Technical details
- PDU type 0x01
- Calling AE title, Called AE title: 16 characters (ISO 646 basic set), leading and trailing spaces not significant, all spaces not allowed
- Application Context Name 1.2.840.10008.3.1.1.1 (the only one PS3.7 defines)
- Presentation Context items: ID (odd, 1 to 255), abstract syntax = SOP Class UID, 1..n transfer syntaxes
- User Information: maximum length item (51H, required), Implementation Class UID (52H, required) and optional Implementation Version Name (55H), optional SCU/SCP role selection (54H)
The acceptor checks the request
Key detailWhat happens
The called side decides whether to accept. It looks at the AE titles (many PACS only accept known callers), whether it supports each SOP Class and whether it can use one of the offered transfer syntaxes.
Why it is needed
This is where most "it does not work" cases are decided. A wrong AE title, an unknown SOP Class or no common transfer syntax each give a different, specific refusal.
Technical details
- Called AE title unknown: A-ASSOCIATE-RJ (reason 7)
- Calling AE title unknown: A-ASSOCIATE-RJ (reason 3)
- Context refused: AC with result 3 (abstract syntax not supported) or 4 (transfer syntaxes not supported)
- Too many associations or no resources: transient rejection by the service provider (source 3, reason 1 temporary congestion or 2 local limit exceeded)
- Protocol version not supported: rejection by the service provider (source 2, reason 2)
A-ASSOCIATE-AC: agree on the contexts
ConfirmationWhat happens
The acceptor replies with the same list of presentation contexts. Each one is marked accepted (with exactly one chosen transfer syntax) or refused (with a reason). The association is now open.
Why it is needed
The caller can only use contexts that were accepted. If the context it needs was refused, it must close the association and fix the configuration, since sending it anyway would fail.
Technical details
- PDU type 0x02
- Presentation Context result: 0 acceptance, 1 user rejection, 2 no reason, 3 abstract syntax not supported, 4 transfer syntaxes not supported
- Accepted transfer syntax, e.g. 1.2.840.10008.1.2 (Implicit VR Little Endian, always supported)
- Acceptor maximum length item (51H); a value of 0 means no maximum specified
- Instead of AC the acceptor can send A-ASSOCIATE-RJ (PDU 0x03): result, source, reason
DIMSE request in P-DATA-TF
Core stepWhat happens
Now the real work starts. The caller sends a DIMSE command, for example C-STORE-RQ, split into fragments that fit the maximum PDU length. A command may be followed by a data set, such as the image itself.
Why it is needed
The association is only the envelope. DIMSE is the actual conversation, and P-DATA-TF is the PDU that carries it.
Technical details
- PDU type 0x04, carries Presentation Data Values (PDVs)
- Each PDV names the presentation context ID it uses
- Command set always uses Implicit VR Little Endian
- Command: (0000,0100) CommandField, (0000,0110) MessageID, (0000,0800) CommandDataSetType
- Data set (if any) uses the negotiated transfer syntax
DIMSE response in P-DATA-TF
ConfirmationWhat happens
The acceptor answers with the matching response command and a status. Steps 5 and 6 can repeat many times on the same association, for instance once per image.
Why it is needed
The status tells the caller whether the request worked. Reusing one association for many messages avoids the cost of negotiating again each time.
Technical details
- CommandField = request value | 8000 (C-STORE-RQ 0001 gives C-STORE-RSP 8001)
- (0000,0120) MessageIDBeingRespondedTo matches the request
- (0000,0900) Status: 0000 success, FF00 pending, other = warning or failure
A-RELEASE-RQ: ask to close
Core stepWhat happens
When the caller is done it asks to release the association in an orderly way.
Why it is needed
An orderly release lets the acceptor finish anything pending and free its resources. Many PACS limit the number of open associations, so leaving them open can block other devices.
Technical details
- PDU type 0x05
- No parameters
A-RELEASE-RP: closed
ConfirmationWhat happens
The acceptor confirms the release. The association ends and the TCP connection is closed.
Why it is needed
Both sides now know the session ended cleanly. If something goes wrong at any point, either side can instead send A-ABORT, which ends the association at once without a reply.
Technical details
- PDU type 0x06
- A-ABORT (PDU 0x07) = abrupt end, no reply. Source 0 = service user, 2 = service provider
- Provider reasons: 0 not specified, 1 unrecognized PDU, 2 unexpected PDU, 4 unrecognized PDU parameter, 5 unexpected PDU parameter, 6 invalid PDU parameter value
All steps at a glance
Glossary
- AE / AE title
- Application Entity: a DICOM application on a device. Its AE title (max 16 characters) is the name other devices use to address it.
- Association
- A negotiated DICOM connection between two AEs, set up on top of a TCP connection. All DIMSE messages travel inside one.
- Presentation context
- One SOP Class (abstract syntax) paired with the transfer syntaxes offered for it. Each gets an odd ID (1, 3, 5 ...).
- SOP Class
- Service-Object Pair class. A UID naming one kind of object plus the service used on it, e.g. CT Image Storage (1.2.840.10008.5.1.4.1.1.2).
- Transfer syntax
- How a data set is encoded on the wire: byte order, explicit or implicit VR, and the image compression.
- DIMSE
- DICOM Message Service Element. The set of commands (C-STORE, C-FIND, N-CREATE ...) sent inside an association.
- SCU
- Service Class User. The side that asks for a service, such as a scanner that wants to store images.
- SCP
- Service Class Provider. The side that provides the service, such as a PACS that stores images.
Summary
- An association sits between TCP and the DIMSE messages. It is opened with
A-ASSOCIATE-RQand closed withA-RELEASE-RQ. - The caller proposes presentation contexts (SOP Class plus transfer syntaxes). The acceptor accepts each one with exactly one transfer syntax, or refuses it.
- Wrong AE titles give an
A-ASSOCIATE-RJ. A SOP Class or transfer syntax the other side does not know gives a refused context in theA-ASSOCIATE-AC. - Calling and called are about who opens the association. SCU and SCP are about who requests and who provides the service. They are independent: in a C-MOVE, the PACS is the SCP first and then calls out as SCU.
- One association can carry many DIMSE exchanges. Release it properly so the PACS keeps free association slots.
The 8 steps in plain text
Open the TCP connection
DICOM runs on top of TCP. The calling side opens a normal TCP connection to the IP address and port of the other device. Nothing DICOM-specific has happened yet.
Why: If this step fails, the problem is the network: a wrong IP address or port, a firewall, or a service that is not running. No DICOM log line will explain it.
A-ASSOCIATE-RQ: propose what to talk about
The caller sends its request. It states who it is (Calling AE title), who it wants (Called AE title) and a list of presentation contexts: for each SOP Class it needs, the transfer syntaxes it can use.
Why: Both sides must agree up front on the services and the encoding. This is the check that stops a device from sending data the other side cannot read.
The acceptor checks the request
The called side decides whether to accept. It looks at the AE titles (many PACS only accept known callers), whether it supports each SOP Class and whether it can use one of the offered transfer syntaxes.
Why: This is where most "it does not work" cases are decided. A wrong AE title, an unknown SOP Class or no common transfer syntax each give a different, specific refusal.
A-ASSOCIATE-AC: agree on the contexts
The acceptor replies with the same list of presentation contexts. Each one is marked accepted (with exactly one chosen transfer syntax) or refused (with a reason). The association is now open.
Why: The caller can only use contexts that were accepted. If the context it needs was refused, it must close the association and fix the configuration, since sending it anyway would fail.
DIMSE request in P-DATA-TF
Now the real work starts. The caller sends a DIMSE command, for example C-STORE-RQ, split into fragments that fit the maximum PDU length. A command may be followed by a data set, such as the image itself.
Why: The association is only the envelope. DIMSE is the actual conversation, and P-DATA-TF is the PDU that carries it.
DIMSE response in P-DATA-TF
The acceptor answers with the matching response command and a status. Steps 5 and 6 can repeat many times on the same association, for instance once per image.
Why: The status tells the caller whether the request worked. Reusing one association for many messages avoids the cost of negotiating again each time.
A-RELEASE-RQ: ask to close
When the caller is done it asks to release the association in an orderly way.
Why: An orderly release lets the acceptor finish anything pending and free its resources. Many PACS limit the number of open associations, so leaving them open can block other devices.
A-RELEASE-RP: closed
The acceptor confirms the release. The association ends and the TCP connection is closed.
Why: Both sides now know the session ended cleanly. If something goes wrong at any point, either side can instead send A-ABORT, which ends the association at once without a reply.
Common questions
What is a DICOM association?
A negotiated connection between two DICOM Application Entities. It is created with A-ASSOCIATE on top of a TCP connection, fixes which SOP Classes and transfer syntaxes will be used, and carries DIMSE messages until it is released.
What is the difference between an AE title and a hostname?
The hostname or IP address and port get you to the device (TCP). The AE title selects the DICOM application on that device and is checked during A-ASSOCIATE. Both must match what the other side has configured. AE titles are at most 16 characters and, in practice, are usually case sensitive.
Why was my association rejected?
An A-ASSOCIATE-RJ carries a result (1 permanent, 2 transient), a source (1 service user, 2 ACSE provider, 3 presentation provider) and a reason. Typical service-user reasons are 3 (calling AE title not recognized), 7 (called AE title not recognized) and 2 (application context name not supported). Transient rejections such as "local limit exceeded" can succeed on a retry.
What does a refused presentation context mean?
The association opened, but one proposed context was not accepted. Result 3 means the acceptor does not support that SOP Class (for example it does not store a certain modality). Result 4 means it supports the SOP Class but none of the transfer syntaxes offered, such as an unsupported JPEG 2000 variant.
Which transfer syntax is always available?
Implicit VR Little Endian (1.2.840.10008.1.2) is the default transfer syntax that every DICOM network implementation must support. Explicit VR Little Endian (1.2.840.10008.1.2.1) and the compressed syntaxes are optional.
What is the difference between A-RELEASE and A-ABORT?
A-RELEASE is a polite request and reply: both sides agree to end. A-ABORT ends the association immediately with no reply. It is sent by a side that hit a protocol error, or by the lower layer when the connection is lost.