7.1 A-ASSOCIATE service

The establishment of an association between two AEs shall be performed through ACSE A-ASSOCIATE request, indication, response and confirmation primitives. The initiator of the service is hereafter called a requestor and the service-user which receives the A-ASSOCIATE indication is hereafter called the acceptor. It shall be a confirmed service.

Note: The A-ASSOCIATE service supports the equivalent of a channel establishment in a point-to-point interface (See PS 3.9).

Figure 7-1 illustrates the association establishment between two AEs.

[pic]

Figure 7-1 ASSOCIATE REQUEST

7.1.1 A-ASSOCIATE PARAMETERS

Table 7-2 lists the parameters that shall be required for the A-ASSOCIATE service used by DICOM Application Entities in this standard.

Table 7-2KEY A-ASSOCIATE SERVICE PARAMETERS

A-ASSOCIATE parameter name Request Indication Response Confirmation
application context name M M(=) M M(=)
calling AE title M M(=) M M(=)
called AE title M M(=) M M(=)
user information M M(=) M M(=)
result M M(=)
result source M
diagnostic U C(=)
calling presentation address M M(=)
called presentation address M M(=)
presentation context definition list M M(=)
presentation context definition list result M M(=)

Note: See Section 5 of this part for table conventions.

Table 7-3 lists the parameters for the A-ASSOCIATE service which shall contain fixed values or shall not be used by DICOM Application Entities in this standard.

Table 7-3A-ASSOCIATE SERVICE PARAMETER (FIXED OR NOT USED)

A-ASSOCIATE parameter name Request Indication Response Confirmation
mode UF MF(=)
responding AE title MF MF(=)
calling/called/responding AE qualifier NU NU NU NU
calling/called/responding AP invoc-id NU NU NU NU
calling/called/responding AE invoc-id NU NU NU NU
responding presentation address MF MF(=)
default context name/result NU NU NU NU
presentation & session requirements UF UF(=) UF UF(=)
other parameters (see ISO 8822 & 8649) NU NU NU NU

7.1.1.1 Mode (fixed)

This parameter allows the negotiation of the optional Mode OSI-ACSE Service parameter. Only the default value of “normal” is used by DICOM Application Entities. Therefore, this parameter shall always specify the value “normal.”

7.1.1.2 Application context name

This parameter identifies the application context proposed by the requestor. The acceptor shall return either the same or a different name. The returned name shall specify the application context to be used for this association. Further discussion on Application Context Names can be found in Annex A.

An application context is an explicitly defined set of application service elements, related options, and any other information necessary for the interworking of application entities on an association.

Note: The offer of an alternate application context by the acceptor provides a mechanism for limited negotiation. If the requestor cannot operate in the acceptor's application context, it shall issue an A-Abort request primitive. Application Context Names for the DICOM Application Entity as well as Application Context Names usage rules are defined in PS 3.7.

7.1.1.3 Calling AE title

This parameter identifies the Application Entity (AE) that shall contain the requestor of the A-ASSOCIATE service. It is based on the Source DICOM Application Name. The relationship between DICOM Application Names and AE titles is specified in Annex C. The Calling AE title may or may not be the same as the Initiator Address present in DICOM Messages exchanged over the association.

Note: It is the responsibility of the UL User that received the A-ASSOCIATE-RQ to verify whether the Calling AE Title is one of its known remote DICOM Application Names.

7.1.1.4 Called AE title

This parameter identifies the Application Entity that shall contain the intended acceptor of the A-ASSOCIATE service. It is based on the Destination DICOM Application Name. The relationship between DICOM Application Name and AE titles is specified in Annex C. The Called AE title may or may not be the same as the Receiver Address present in DICOM Messages exchanged over the association.

Note: It is the responsibility of the UL User that received the A-ASSOCIATE-RQ to verify whether the Called AE Title is its (or one of its) DICOM Application Name(s).

7.1.1.5 Responding AE title (fixed)

This parameter identifies the AE that shall contain the actual acceptor of the A-ASSOCIATE service. In this standard it shall always contain the same value as the Called AE Title of the A-ASSOCIATE indication.

7.1.1.6 User information

This parameter shall be used by the requestor and the acceptor of the association to include DICOM Application Entity user information. Its meaning shall depend on the application context that accompanies the primitive. The usage of this parameter is specified in Annex D.

Notes: 1. This parameter is used to carry initialization information for the DICOM Application Entities as defined in the application context specified by the value of the accompanying Application Context Name parameter.

2. Annex D specifies some user information sub-items, and references PS3.7 for the specification of additional sub-items. PS3.7, in turn, references PS3.4 for the specification of Service-class-application-information used in some sub-items.

7.1.1.7 Result

This parameter shall be provided either by the acceptor of the A-ASSOCIATE request, by the UL service-provider (ACSE related function), or by the UL service-provider (Presentation related function). It shall indicate the result of using the A-ASSOCIATE service. It shall take one of the following symbolic values:

a) accepted;

b) rejected (permanent);

c) rejected (transient).

Note: The rejected (permanent) implies that the association calling UL user (when returning such a result to an association request) does not need to “call later.” A permanent situation exists that prevents the association establishment (e.g. remote DICOM Application Name unknown).

7.1.1.8 Result source

The value of the parameter is supplied by the UL service-provider. It identifies the creating source of the Result parameter and the Diagnostic parameter, if present. It shall take one of the following symbolic values:

a) UL service-user;

b) UL service-provider (ACSE related function);c) UL service-provider (Presentation related function).

Note: If the Result parameter has the value “accepted,” the value of this parameter is “UL service-user.”

7.1.1.9 Diagnostic

This parameter shall only be used if the Result parameter has the value of “rejected (permanent)” or “rejected (transient).” It shall be used to provide diagnostic information about the result of the A-ASSOCIATE service.

If the Result Source parameter has the value “UL service-user,” it shall take one of the following symbolic values:

a) no-reason-given

b) application-context-name not supported

c) calling-AE-title not recognized

d) called-AE-title not recognized

e) calling-AE-qualifier not recognized (see note)

f) calling-AP-invocation-identifier not recognized (see note)

g) calling-AE-invocation-identifier not recognized (see note)

h) called-AE-qualifier not recognized (see note)

i) called-AP-invocation-identifier not recognized (see note)

j) called-AE-invocation-identifier not recognized (see note)

If the Result Source parameter has the value “UL service-provider” (ACSE related function), it shall take one of the following symbolic values:

a) no-reason-given

b) no-common-UL version

If the result source has the value “UL service-provider” (Presentation related function), it shall take the following symbolic values:

a) no-reason-given

b) temporary-congestion

c) local-limit-exceeded

d) called-(Presentation)-address-unknown

e) Presentation-protocol version not supported

f) no-(Presentation) Service Access Point (SAP) available

Note: Even though some of the above symbolic values correspond to parameter errors not used in this standard, they are included to allow the notification of errors resulting from the unauthorized use of these parameters.

7.1.1.10 Calling presentation address

This parameter shall contain a structured destination address unambiguous within the global network address structure. This shall be a TCP/IP Address. See Annex C.

7.1.1.11 Called presentation address

This parameter shall contain a structured destination address unambiguous within the global network address structure. This shall be a TCP/IP Address. See Annex C.

7.1.1.12 Responding presentation address

In this standard, a responding presentation address shall always contain the same value as the called Presentation Address of the A-ASSOCIATE indication. This parameter shall contain a structured destination address unambiguous within the global network address structure.

7.1.1.13 Presentation context definition list

This parameter used in an A-ASSOCIATE request or indication shall consist of a list containing one or more presentation contexts. Each item shall contain three components, a presentation context identification, an Abstract Syntax Name, and a list of one or more Transfer Syntax Names.

The presentation context identification components of this parameter exist to distinguish presentation contexts in communication. Such an identification of presentation context(s) applies only within the context of a given association (i.e. different presentation contexts may be identified by the same presentation context identification on different associations). It is the association-requestor's responsibility to assign an arbitrary, but unused identifier for each proposed presentation context on a given association. There is no restriction on the ordering of the presentation contexts in relation to their identifiers.

Note: A separate presentation context will be associated with each Abstract Syntax Name in each of the elements of the Presentation Context Definition List parameter. If the same Abstract Syntax Name occurs more than once, a separate and distinctly identified presentation context will be generated for each occurrence (as only one Transfer Syntax per presentation context can be accepted).

Abstract Syntaxes defined by this standard and used by DICOM Application Entites are defined in PS 3.4. Transfer Syntaxes defined by this standard and used by DICOM Application Entities are defined in PS 3.5. Further discussion on Abstract Syntaxes and Transfer Syntaxes can be found in Annex B.

7.1.1.14 Presentation context definition result list

This parameter used in the A-ASSOCIATE Response and Confirmation indicates the acceptance or rejection of each of the presentation context definitions proposed in the presentation context definition list parameter (Section 7.1.1.13). The Presentation Context Definition Result List parameter shall take the form of a list of result values. There is a one to one correspondence between each one of these result values and each of the presentation contexts proposed in the Presentation Context Definition List parameter. Each result value represents either “acceptance,” “user-rejection,” or “provider-rejection.” The values of the results are assigned by the UL user on the response service primitive. The result values may be sent in any order.

Note: The order of the results may be different than the order proposed. The order need not be sorted by identifier, and the Initiator may not assume or depend upon any particular order.

In this standard only one Transfer Syntax per presentation context shall be agreed to, even though more than one choice of Transfer Syntaxes may have been offered in a specific presentation context of the Presentation Context Definition list.

7.1.1.15 Presentation requirements (fixed value)

This parameter allows the negotiation of optional presentation functional units beyond the Presentation Kernel. Only the Kernel Functional Unit is used by DICOM Application Entities. Therefore, this parameter shall always specify “Presentation Kernel.”

7.1.1.16 Session requirements (fixed value)

This parameter allows the negotiation of optional session Functional Units beyond the Session Kernel. Only the Kernel functional unit with the Full Duplex Functional Unit shall be used by DICOM Application Entities.

7.1.1.17 Other parameters

A few optional parameters defined in the OSI ACSE (ISO 8649) and OSI Presentation Service (ISO 8822) Standards are not identified here. They are not necessary for the communication of DICOM Application Entities and shall not be used in this standard.

7.1.2 A-ASSOCIATE SERVICE PROCEDURE

7.1.2.1 A DICOM Application Entity (which includes the Upper Layer service-user) that desires to establish an association shall issue an A-ASSOCIATE request primitive. The called AE is identified by parameters of the request primitive. The requestor shall not issue any primitives except an A-ABORT request primitive until it receives an A-ASSOCIATE confirmation primitive.

7.1.2.2 The Upper Layer (UL) service-provider shall issue an A-ASSOCIATE indication primitive to the called AE.

7.1.2.3 The called AE shall accept or reject the association by sending an A-ASSOCIATE response primitive with an appropriate Result parameter. The Upper layer service-provider shall issue an A-ASSOCIATE confirmation primitive having the same Result parameter. The Result Source parameter shall be assigned the symbolic value of “UL service-user.”

7.1.2.4 If the acceptor accepts the association, the association is available for use. Both AEs may now use any service provided by the DICOM application context that is in effect (with the exception of A-ASSOCIATE).

Note: This implies that once the association has been established, DICOM Messages can be exchanged as defined in PS 3.7.

7.1.2.5 If the called AE rejects the association, the association shall not be established.

7.1.2.6 The UL service-provider may not be capable of supporting the requested association. In this situation, it shall return an A-ASSOCIATE confirmation primitive to the requestor with an appropriate Result parameter (rejected). The Result Source parameter shall be appropriately assigned either the symbolic value of “UL service-provider (ACSE related function)” or “UL service-provider (Presentation related function).” The indication primitive shall not be issued. The association shall not be established.

7.1.2.7 Either an association-requestor or acceptor may disrupt the A-ASSOCIATE service procedure by issuing an A-ABORT request primitive (see Section 7.3). The remote AE receives an A-ABORT indication primitive. The association shall not be established.