Материал: part08

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-ASSOCIATEindication.Thisparametershallcontainastructureddestinationaddressunambiguouswithintheglobalnetworkaddress​ 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 PS3.4. Transfer Syntaxes defined​ by this Standard and used by DICOM Application Entities are defined in PS3.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 present-​ ation 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.​

- Standard -​

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​

AfewoptionalparametersdefinedintheOSIACSE(ISO8649)andOSIPresentationService(ISO8822)Standardsarenotidentified​ 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.1A 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.2The Upper Layer (UL) service-provider shall issue an A-ASSOCIATE indication primitive to the called AE.​

7.1.2.3The 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.4If 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 PS3.7.​

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

7.1.2.6The 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.7Eitheranassociation-requestororacceptormaydisrupttheA-ASSOCIATEserviceprocedurebyissuinganA-ABORTrequest​ primitive (see Section 7.3). The remote AE receives an A-ABORT indication primitive. The association shall not be established.​

7.2 A-RELEASE Service​

ThegracefulreleaseofanassociationbetweentwoAEsshallbeperformedthroughACSEA-RELEASErequest,indication,response,​ andconfirmationprimitives.Theinitiatoroftheserviceishereaftercalledarequestorandtheservice-userthatreceivestheA-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.​

- Standard -​

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

7.2.2.6A 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.7AnA-RELEASEserviceprocedurecollisionresultswhenrequestorsinbothAEssimultaneouslyissueanA-RELEASEservice​ 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:​

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

b.​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.​

c.​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.​

7.3 A-ABORT Service​

The ACSE A-ABORT service shall be used by a requestor in either of the AEs to cause the abnormal release of the association. It​ shall be a non-confirmed service. However, because of the possibility of an A-ABORT service procedure collision, the delivery of the​ indication primitive is not guaranteed. Should such a collision occur, both AEs are aware that the association has been terminated.​ The abort shall be performed through A-ABORT request and A-ABORT indication primitives.​

Note​

An A-ABORT request primitive used on an established association may result in the destruction of data in transit.​

Figure 7-3 illustrates aborting an established association between two AE's.​

Figure 7-3. Association User Initiated Abort​

7.3.1 A-ABORT Parameters​

Table 7-5 lists the parameters for the A-ABORT service. Only the first parameter shall be used by DICOM Application Entities in this​ Standard.​

Table 7-5. A-ABORT Service Parameters​

7.3.1.1 Abort Source​

This parameter indicates the initiating source of this abort. It shall take one of the following symbolic values:​

a.​UL service-user​

- Standard -​

b.​UL service-provider (ACSE related)​

7.3.2 A-ABORT Service Procedure​

7.3.2.1WhentheA-ABORTserviceisused,theassociationshallbereleasedabnormallyandsimultaneouswiththeabnormalrelease​ of the underlying connection.​

7.3.2.2AULservice-userthatdesirestoreleasetheassociationabnormallyshallissuetheA-ABORTrequestprimitive.Thisrequestor​ shall not issue any further primitives for the association.​

7.3.2.3The UL service-provider shall issue an A-ABORT indication primitive to the acceptor. The UL service-provider shall assign​ the value of "UL service-user" for the Abort Source parameter. The association and the underlying connection have been released.​

7.3.2.4TheULservice-provider(ACSErelatedfunctions)mayitselfcausetheabnormalreleaseoftheassociationbecauseofinternal​ errors.Inthiscase,theULservice-providershallissueA-ABORTindicationprimitivestoacceptorsinbothAEs.TheULservice-provider​ shall assign the value of "UL service-provider" to the Abort Source parameter. The user information parameter shall not be used.​

7.4 A-P-ABORT Service​

The ACSE A-P-ABORT service shall be used by the UL service-provider to signal the abnormal release of the association due to​ problems in services at the Presentation Layer and below. This occurrence indicates the possible loss of information in transit. A-P-​ ABORT is a provider-initiated service.​

Figure 7-4 illustrates aborting an established association by an UL service-provider.​

Figure 7-4. Provider Initiated Abort​

7.4.1 A-P-ABORT Parameter​

Table 7-6 lists the parameter that shall be required for the A-P-ABORT service.​

Table 7-6. A-P-ABORT Service Parameters​

- Standard -​