Материал: part08

B Abstract and Transfer Syntaxes​ (Informative)​

B.1 Abstract Syntax Definition​

An Abstract Syntax is the specification of Application Layer data elements with associated semantics or Application Layer protocol​ control information by using notation rules that are independent of the encoding technique used to represent them.​

Note​

In particular, it allows the communicating Application Entities to negotiate an agreed set of DICOM Data Elements (e.g., from​ a specific version of the Data Dictionary) and/or Information Object Class definitions.​

B.2 Transfer Syntax Definition​

A Transfer Syntax is a set of encoding rules able to unambiguously represent the data elements defined by one or more Abstract​ Syntaxes. In particular, negotiation of Transfer Syntaxes allows the communicating Application Entities to agree on the encoding​ techniques they are able to support (e.g., byte ordering, compression, etc.).​

B.3 DICOM Abstract and Transfer Syntax Names Encoding and Registration​

The Abstract and Transfer Syntax Name structure is based on the OSI Object Identification (numeric form) as defined by ISO 8824.​ Abstract and Transfer Syntax Names are registered values as defined by ISO 9834-1 to ensure global uniqueness. Abstract and​ TransferSyntaxNamesareencodedasdefinedinISO8825(ObjectIdentifiersofnumericform)whentheOSInetworkcommunication​ support is used as defined in Section 8. They are encoded as defined in Annex F when the TCP/IP network communication support​ is used as defined in Section 9.​

B.3.1 DICOM Registered Abstract and Transfer Syntax Names​

The organization responsible for the definition and registration of DICOM Abstract and Transfer Syntax Names is NEMA. NEMA​ guarantees uniqueness for all DICOM Abstract and Transfer Syntax Names. A choice of DICOM registered Abstract and Transfer​ Syntax Names related to a specific version of the DICOM Application Entities, as well as the associated negotiation rules, are defined​ in PS3.4 for Abstract Syntaxes and PS3.5 for Transfer Syntaxes.​

B.3.2 Privately Defined Abstract and Transfer Syntax Names​

PrivatelydefinedAbstractandTransferSyntaxNamesmayalsobeused,however,theywillnotberegisteredbyNEMA.Organizations​ that define private Abstract and Transfer Syntax Names are responsible to obtain their proper registration defined for OSI Object​ Identifiers. National Standards Organizations representing a number of countries (e.g., UK, France, Germany, Japan, USA, etc.) to​ the International Standards Organization act as a registration authority as defined by ISO 9834-1.​

Note​

For example, in the USA, ANSI assigns (for a fee) Organization Identifiers to any requesting organization. This identifier is​ made of a series of four numeric components; 1 (identifies ISO), 2 (identifies the ISO member bodies branch), 840 (identifies​ ANSI as the ISO member body representing the USA), and xxxxxx (identifies a specific organization and is issued by ANSI).​ Such an identifier may be used by the identified organization as a root to which it may add a suffix made of one or more​ numeric components. The identified organization accepts the responsibility to properly register these suffixes to ensure​ uniqueness.​

- Standard -​

- Standard -​

C DICOM Addressing (Normative)​

C.1 DICOM Application Entity Titles​

A DICOM Application Entity Title uniquely identifies a service or application on a specific system in the network. Application Entity​ Titles are independent of network topology so a device may be physically moved while its corresponding Application Entity Title may​ remain the same. See PS3.5 for the encoding of DICOM Application Entity Titles.​

Note​

DICOM Application Entity Title was called Logical Address in the ACR-NEMA Standard.​

DICOM Application Entity Titles are used in three instances of communication:​

a.​to identify the Called/Calling Application Entities. They are used to establish an association and to ensure that the association is​ established with the expected application.​

b.​to identify the originator and intended destination of DICOM Retrieve Services (see PS3.4). They are conveyed in DICOM​ Commands with messages of the DIMSE C-MOVE and C-STORE Services exchanged over an established association.​

c.​to identify the location of a Retrieve Service SCP for one or more SOP Instances. They are conveyed in DICOM DataSets of​ various services.​

C.2 Naming and Addressing Usage Rules​

DICOM Application Entity Titles are used in the Called/Calling Application Entity Title fields of the Upper Layer Service, in the Move​ DestinationandMoveOriginatorApplicationEntityTitledataelementsintheDICOMMessageCommandSet,andinvariousAttributes​ of the DICOM Message Data Set.​

Note​

1.​A single Application Entity Title can be associated with multiple network addresses assigned to a single system (e.g.,​ multi-homed host).​

2.​A single Application Entity Title can be associated with multiple TCP Ports using the same or different IP Addresses.​

3.​A single network access point (IP Address and TCP Port) can support multiple Application Entity Titles.​

A DICOM system on a network may support several application processes identified by different DICOM Application Entity Titles.​

Upon receiving an association request, the Called Application Entity Title shall be validated so an association can be rejected when​ the corresponding local application does not exist.​

- Standard -​

- Standard -​

D Use and Format of the A-ASSOCIATE User​ Information Parameter (Normative)​

This parameter allows for the negotiation of a number of features related to the communication of DICOM Application Entities at as-​ sociation establishment.​

D.1 Maximum Length Negotiation​

This negotiation allows the receivers to limit the size of the Presentation Data Values List parameters of each P-DATA Indication.​ Theassociation-requestorshallspecifyintheuserinformationparameteroftheA-ASSOCIATErequestprimitivethemaximumlength​ in bytes for the PDV list parameter it is ready to receive in each P-DATA indication. The association-acceptor shall ensure in its​ fragmentation of the DICOM Messages that the list of PDVs included in each P-DATA request does not exceed this maximum length.​ Likewise, the association-acceptor can specify in the user information parameter of A-ASSOCIATE response primitive the maximum​ length in bytes for the PDV list parameter it is ready to receive in each P-DATA indication. The association-requestor shall ensure in​ its fragmentation of the DICOM Messages that the list of PDVs included in each P-DATA request does not exceed this maximum​ length. Different maximum lengths can be specified for each direction of data flow on the association.​

The Maximum Length Item support is required for all DICOM V3.0 conforming implementations.​

D.1.1 Maximum Length Sub-Item Structure (A-ASSOCIATE-RQ)​

The Maximum Length Sub-Item shall be made of a sequence of mandatory fixed length fields. Only one Maximum Length Sub-Item​ shall be present in the User Data information in the A-ASSOCIATE-RQ. Table D.1-1 shows the sequence of the mandatory fields.​

Table D.1-1. Maximum Length Sub-Item Fields (A-ASSOCIATE-RQ)​

5-8​ Maximum-length-received​This parameter allows the association-requestor to restrict the maximum length of the​ variable field of the P-DATA-TF PDUs sent by the acceptor on the association once​ established. This length value is indicated as a number of bytes encoded as an unsigned​ binary number. The value of (0) indicates that no maximum length is specified. This​ maximum length value shall never be exceeded by the PDU length values used in the​ PDU-lengthfieldoftheP-DATA-TFPDUsreceivedbytheassociation-requestor.Otherwise,​ it shall be a protocol error.​

D.1.2 Maximum Length Sub-Item Structure (A-ASSOCIATE-AC)​

The Maximum Length Sub-Item shall be made of a sequence of mandatory fixed length fields. Only one Maximum Length Sub-Item​ shall be present in the User Data information in the A-ASSOCIATE-AC. Table D.1-2 shows the sequence of the mandatory fields.​

Table D.1-2. Maximum Length Sub-Item Fields (A-ASSOCIATE-AC)​

- Standard -​