7.2 A-RELEASE Service
Prev | 7 OSI Upper Layer Service for DICOM Application Entities | Next

## 7.2 A-RELEASE Service

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

Figure 7-2 illustrates the graceful release of an association between two AEs.

Figure 7-2. Association Release

### 7.2.1 A-RELEASE Parameters

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

Table 7-4. A-RELEASE Service Parameters

A-RELEASE parameter name | Request | Indication | Response | Confirmation
--- | --- | --- | --- | ---
reason | UF | UF(=) | UF | UF(=)
user information | NU | NU(=) | NU | NU(=)
result |  |  | MF | MF(=)

#### 7.2.1.1 Reason (Fixed)

When used on the request primitive, this parameter identifies the general level of urgency of the request. This parameter shall always use the value "normal" in this standard.

#### 7.2.1.2 Result (Fixed)

This parameter shall always take the value "affirmative" in this standard.

### 7.2.2 A-RELEASE Service Procedure

7.2.2.1 An UL service-user that desires to release the association shall issue an A-RELEASE request primitive. This requestor shall not issue any further primitives other than an A-ABORT request primitive until it receives an A-RELEASE confirmation primitive.

### Note

Even though the requestor of the A-RELEASE service shall not issue any further primitive other than A-ABORT, it may receive P-DATA Indication primitives.

7.2.2.2 The UL service-provider shall issue an A-RELEASE indication primitive to the acceptor. The acceptor then shall not issue any UL primitives other than an A-RELEASE response primitive, an A-ABORT request primitive, or P-DATA Request primitive.

7.2.2.3 To complete the A-RELEASE service, the acceptor shall reply to the A-RELEASE indication primitive by issuing an A-RELEASE response primitive. An accepting DICOM Application Entity shall always issue an A-RELEASE response primitive with an "affirmative" result parameter (i.e., accept the release).

7.2.2.4 After an A-RELEASE response has been issued, the acceptor shall not issue any further primitives for the association thereafter, including P-DATA Requests.

7.2.2.5 The UL service-provider shall issue an A-RELEASE confirmation primitive always with an "affirmative" value for the Result parameter.

7.2.2.6 A requestor in either AE may disrupt the A-RELEASE service procedure by issuing an A-ABORT request. When the acceptor receives an A-ABORT indication, the association is released with the possible loss of information in transit.

7.2.2.7 An A-RELEASE service procedure collision results when requestors in both AEs simultaneously issue an A-RELEASE service primitive. In this situation, both UL service-users receive an unexpected A-RELEASE indication primitive. The following sequence shall occur to complete the normal release of the association:

1. The association-requestor shall issue an A-RELEASE response primitive.

2. The association-acceptor waits for an A-RELEASE confirmation primitive from its peer. When it receives one, it shall then issue an A-RELEASE response primitive.

3. The association-requestor receives an A-RELEASE confirmation primitive.

The association shall be released when both ACSE service-users have received an A-RELEASE confirmation primitive.

Prev | Up | Next
7 OSI Upper Layer Service for DICOM Application Entities | Home | 7.3 A-ABORT Service