Association Negotiation

The very first item proposed by the initiating SCU (Service Class User) . It defines the overall framework for the association, which for standard DICOM networking is always the fixed UID 1.2.840.10008.3.1.1.1. If the SCP (Service Class Provider) does not accept this specific context, the association is immediately rejected. This element acts as a protocol version check, ensuring both systems are speaking the same base language before diving into specific capabilities.

The core of the negotiation where the SCU proposes a list of SOP Classes it wants to use, each paired with one or more Transfer Syntaxes it supports.

• Abstract Syntax: The specific SOP Class UID (e.g., 1.2.840.10008.5.1.4.1.1.2 for CT Image Storage).
• Transfer Syntax List: Ordered list of encoding rules (e.g., JPEG Lossless, Explicit VR Little Endian).

The SCP responds to each proposal with an acceptance of one Transfer Syntax or a rejection. This allows a single association to multiplex different data types and compression schemes.

An optional but critical negotiation phase for setting operational parameters using a key-value structure.

• Maximum PDU Length: The most vital item, defining the largest packet size (in bytes) the receiver can handle. The SCP selects the minimum of the two proposed values to prevent buffer overflows.
• Implementation Class UID: A unique identifier for the software version, crucial for debugging interoperability issues.
• Asynchronous Operations Window: Negotiates how many outstanding commands can be in flight without a response, enabling high-throughput pipelines.

During negotiation, each Presentation Context can be proposed with a specific role. While a PACS typically acts as an SCP for the Storage SOP Class, a modality might propose to act as an SCU for the Storage Commitment Push Model SOP Class. This explicit role selection prevents a device from being asked to perform an operation it is not designed for, such as a CT scanner being asked to store images from the network.

The negotiation is physically transmitted as a single A-ASSOCIATE-RQ PDU from the SCU, followed by an A-ASSOCIATE-AC or A-ASSOCIATE-RJ PDU from the SCP. The structure is strictly binary-encoded:

• PDU Header: Contains the length and type.
• Variable Items: The Application Context, Presentation Contexts, and User Information.

A rejection (RJ) includes a specific Result and Source code, such as '2 - application-context-name-not-supported', allowing for automated diagnostic logging.

For advanced SOP Classes, standard Presentation Context acceptance is insufficient. Extended Negotiation allows for sub-options to be passed as opaque blobs during the association.

• Storage Commitment: Negotiates the port and AE Title for the reverse connection.
• MPPS (Modality Performed Procedure Step) : Defines the strict sequence of procedure states.
• Structured Reporting: Agrees on the specific templates and coded terminologies to be used. This mechanism prevents the association from succeeding only to fail later due to unsupported feature subsets.