Материал: part08

5-8​ Maximum-length-received​This parameter allows the association-acceptor to restrict the maximum length of the​ variable field of the P-DATA-TF PDUs sent by the requestor 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-acceptor.Otherwise,​ it shall be a protocol error.​

D.2 Extended User Information Negotiation​

The user information parameter, of the A-ASSOCIATE primitive, can be extended to support the negotiation needs of DICOM Applic-​ ation Entities using the UL Service. This will result in the definition of specific user information sub-items. These sub-items shall be​ assigned unique item-type values registered in PS3.7.​

Note​

1.​The values of the Sub-Items types in the User Information Field are assigned by this Standard in the range of 51H​ through FFH. Sub-Item values are defined by PS3.7 and PS3.8.​

2.​Succeeding editions of the Standard may define additional user information Sub-Items in a manner that does not affect​ the semantics of previously defined Sub-Items. Association acceptors compliant to an earlier edition of the Standard​ are required to ignore such unrecognized user information Sub-Items and not reject an Association because of their​ presence.​

- Standard -​

EUsageoftheP-DATAServiceBytheDICOM​

Application Entity (Normative)​

This Annex specifies how DICOM messages are encapsulated into the P-DATA Service by the DICOM Application Entity.​

E.1 Encapsulation Rules​

DICOM Messages are encapsulated in P-DATA request primitives as the user data of Presentation Data Values (PDV). A DICOM​ Message is fragmented in Command Fragments and Data Fragments, each placed in a PDV. The same presentation context shall​ be used for every fragment of the same message (i.e., same Presentation Context ID for the user data of the PDVs containing the​ fragments of a same message). A PDV User Data parameter shall contain one and only one fragment (either Command or Data)​ preceded by a Message Control Header. This header will indicate:​

a.​whether the fragment is of the Command or Data type​

b.​whether the fragment is or is not the last fragment of a Command/Data Stream of a DICOM Message​

A P-DATA request PDV List parameter shall contain one or more such PDV(s) (Message Control Header and a complete message​ fragment). Each PDV is wholly contained in a given P-DATA request primitive and does not span across several P-DATA request​ primitives. The PDVs contained in a P-DATA request primitive shall be related to the same DICOM message. Each fragment of a​ message shall consist of an even number of bytes.​

Note​

1.​No padding is necessary as PS3.5 defines messages on an even byte boundary.​

2.​The above rules state that each fragment contained in a PDV shall consist of an even number of bytes (only). Therefore,​ encoding such as Group Number, Element Number, Value Length, etc. (as defined by the DICOM Application Entity,​ see PS3.5) is not guaranteed to be within the same PDV.​

The fragmentation of any message results in a series of PDVs that shall be sent, on a given association, by a corresponding series​ of P-DATA requests preserving the ordering of the fragments of any message. Furthermore, no fragments of any other message shall​ be sent until all fragments of the current message have been sent (i.e., interleaving of fragments from different messages is not per-​ mitted).​

It is strongly recommended that two consecutive PDVs in the same P-DATA Request primitive (therefore containing fragments of the​ samemessageusingthesamePresentationContextID)donotcontaintwomessageControlHeaderswiththesametype(Command​ or Data). These should have been combined in a single PDV by the sender. However, receivers must be able to receive and process​ such PDVs.​

Note​

The above rules allow the sending in the same P-DATA request/indication of a Command fragment in the first PDV (with​ the last fragment flag set) followed by a Data Fragment in the second PDV (with the last fragment flag set or not). In partic-​ ular, if the negotiated maximum length for the PDV List parameter of the P-DATA request is sufficient to hold a complete​ message, a single P-DATA request can be used to exchange an entire message.​

Individual PDVs shall not be sent with Presentation-data-value fields consisting only of a single byte containing a Message Control​ Header, but without any other content in the fragment. These should have been combined with the preceding or succeeding PDVs​ by the sender.​

Note​

Eventhoughtheaboverulesprohibitthesendingofan"empty"PDV(suchaswiththelastfragmentflagset),itisrecommended​ that receivers be able to receive and process such PDVs.​

- Standard -​

E.2 Message Control Header Encoding​

The Message Control Header is located in front of each DICOM message fragment (see Figure E.2-1). Its presence is mandatory for​ all DICOM Abstract Syntaxes (see Annex B for further discussion on Abstract Syntaxes).​

The Message Control Header shall be made of one byte with the least significant bit (bit 0) taking one of the following values:​ a.​If bit 0 is set to 1, the following fragment shall contain Message Command information.​

b.​If bit 0 is set to 0, the following fragment shall contain Message Data Set information.​ The next least significant bit (bit 1) shall be defined by the following rules:​

a.​If bit 1 is set to 1, the following fragment shall contain the last fragment of a Message Data Set or of a Message Command.​ b.​If bit 1 is set to 0, the following fragment does not contain the last fragment of a Message Data Set or of a Message Command.​ Bits 2 through 7 are always set to 0 by the sender and never checked by the receiver.​

Note​

The Message Control Header, in the Transport data flow, is the 1st byte in each PDV. The Transfer Syntax, negotiated at​ association establishment, defines the encoding for the Command/Data fragment.​

PRESENTATION DATA VALUE AND THE MESSAGE CONTROL HEADER

Figure E.2-1. Presentation Data Value and the Message Control Header​

- Standard -​

F DICOM UL Encoding Rules for Application​ Contexts, Abstract Syntaxes, Transfer​ Syntaxes (Normative)​

F.1 Encoding Rules​

Application Context Names, Abstract Syntax Names, Transfer Syntax Names, and Service Class UIDs are OSI Object Identifiers in​ a numeric form as defined by ISO 8824. The encoding of these names in the DICOM UL protocol is specified in this Annex.​

Each component of a Name or UID is encoded as an ISO 646:1990-Basic G0 Set Numeric String of bytes (characters 0-9). Leading​ 0's of each component are not significant and shall not be sent. Components shall not be padded. Components shall be separated​ by the character "." (2EH). "Null" components (no numeric value between two separators) shall not exist. Components with the value​ zero (0) shall be encoded as (nnn.0.ppp). No separator nor padding shall be present before the first digit of the first component or​ after the last digit of the last component.​

Note​

1.​The string "1.2.840.123456.0.21.4" encoded as an ISO 646:1990-Basic G0 Set character string conveys the following​ UID or Name with the following sequence of Object Identifier components: { (1), (2), (840), (123456), (0), (21), (4) }.​

2.​The above rules have been made to simplify performing the comparison of UIDs.​

DICOMApplicationContextNames(rootplussuffix)shallnotexceed64totalcharacters(digitsandseparatorsbetweencomponents).​

DICOM Abstract and Transfer Syntax Names (root plus suffix) shall not exceed 64 total characters (digits and separators between​ components).​

- Standard -​

- Standard -​