PS3.8

Информация в данной публикации была признана технически обоснованной по консенсусу лиц, участвовавших в разработке и утверждении документа на момент его создания. Консенсус не обязательно означает единогласное согласие всех лиц, участвующих в разработке данного документа.

Стандарты и руководящие документы NEMA, одним из которых является документ, содержащийся в настоящем издании, разрабатываются в рамках добровольного процесса разработки стандартов на основе консенсуса. Этот процесс объединяет добровольцев и/или выявляет мнения лиц, заинтересованных в теме, охватываемой данной публикацией. Хотя NEMA администрирует процесс и устанавливает правила для обеспечения справедливости при достижении консенсуса, NEMA не пишет документ и не проводит независимое тестирование, оценку или проверку точности или полноты какой-либо информации, а также обоснованности каких-либо суждений, содержащихся в его стандартах и руководящих документах.

NEMA не несёт ответственности за любые телесные повреждения, имущественный ущерб или иные убытки любого характера, будь то специальные, косвенные, последующие или компенсационные, прямо или косвенно вытекающие из публикации, использования, применения или полагания на данный документ. NEMA отказывается от каких-либо гарантий, явных или подразумеваемых, относительно точности или полноты любой информации, опубликованной в данном документе, и не гарантирует, что информация в данном документе будет отвечать каким-либо конкретным целям или потребностям. NEMA не берёт на себя обязательств по гарантированию характеристик продуктов или услуг любого отдельного производителя или продавца на основании данного стандарта или руководства.

Публикуя и предоставляя доступ к данному документу, NEMA не берёт на себя оказание профессиональных или иных услуг от имени или в интересах какого-либо лица или организации, а также не берёт на себя выполнение каких-либо обязанностей, которые какое-либо лицо или организация должно перед третьими лицами. Любой, кто использует данный документ, должен полагаться на собственное независимое суждение или, в зависимости от обстоятельств, обратиться за консультацией к компетентному специалисту для определения мер разумной предусмотрительности в любой конкретной ситуации. Информация и иные стандарты по теме, охватываемой данной публикацией, могут быть доступны из других источников, которые пользователь может пожелать изучить для получения дополнительных взглядов или информации, не охваченных данной публикацией.

NEMA не обладает полномочиями и не берёт на себя контроль за соблюдением или обеспечение выполнения положений данного документа. NEMA не сертифицирует, не тестирует и не инспектирует продукты, конструкции или установки в целях безопасности или охраны здоровья. Любая сертификация или иное заявление о соответствии любой информации по безопасности и охране здоровья в данном документе не может быть приписано NEMA и является исключительной ответственностью лица, проводящего сертификацию, или составителя такого заявления.

Предисловие

Настоящий стандарт DICOM был разработан в соответствии с процедурами Комитета по стандартам DICOM.

Стандарт DICOM структурирован как многочастевой документ с использованием руководящих принципов, установленных в [ISO/IEC Directives, Part 2].

DICOM® является зарегистрированным товарным знаком Национальной ассоциации производителей электрооборудования (NEMA) для её стандартных публикаций, относящихся к цифровой передаче медицинской информации; все права защищены.

SNOMED®, SNOMED Clinical Terms®, SNOMED CT® являются зарегистрированными товарными знаками Международной организации по разработке стандартов терминологии в области здравоохранения (International Health Terminology Standards Development Organisation , IHTSDO); все права защищены.

1 Область применения и сфера действия

Протоколы связи, определяемые в настоящей части PS3, тесно соответствуют эталонной модели взаимодействия открытых систем ISO (ISO Open Systems Interconnection Basic Reference Model, ISO 7498-1, см. Рисунок 1-1). Они относятся к следующим уровням: физическому (Physical), канальному (Data Link), сетевому (Network), транспортному (Transport), сеансовому (Session), представительному (Presentation) и службам управления ассоциацией (Association Control Services, ACSE) прикладного уровня. Протоколы связи, определяемые настоящей частью, являются протоколами связи общего назначения (TCP/IP) и не специфичны для настоящего стандарта. Другие аспекты протоколов прикладного уровня рассматриваются в других частях настоящего стандарта, как описано в PS3.1 «PS3.1».

Рисунок 1-1. Эталонная модель OSI ISO (ISO OSI Basic Reference Model)

2 Нормативные ссылки

Следующие стандарты содержат положения, которые посредством ссылок в данном тексте составляют положения настоящего стандарта. На момент публикации были действительны указанные редакции. Все стандарты подлежат пересмотру, и сторонам соглашений, основанных на настоящем стандарте, рекомендуется рассмотреть возможность применения самых последних редакций стандартов, указанных ниже.

2.1 Международные стандарты

[ISO/IEC Directives, Part 2] ISO/IEC. 2021. 9.0. Rules for the structure and drafting of International Standards. http://www.iso.org/sites/directives/current/part2/index.xhtml .

[ISO 7498-1] ISO. 1994. Information Processing Systems - Open Systems Interconnection - Basic Reference Model.

[ISO 7498-3] ISO. 1997. Information Processing Systems - Open Systems Interconnection - Naming and Addressing.

[ISO 8327] ISO. 1996. Information Processing Systems - Open Systems Interconnection - Connection Oriented Session Protocol Specification.

[ISO 8649] ISO. 1988. Information processing systems - Open Systems Interconnection - Service definition for the Association Control Service Element (ACSE).

[ISO 8650] ISO. 1987. Information Processing Systems - Open Systems Interconnection - Protocol Specification for the Association Control Service Element.

[ISO/TR 8509] ISO. Information Processing Systems - Open Systems Interconnection - Service Conventions. ISO/TR 8509 был отозван. См. ISO/IEC 2382-26:1993 Information technology - Vocabulary - Part 26: Open systems interconnection .

[ISO 8822] ISO. 1988. Information processing systems - Open Systems Interconnection - Connection oriented presentation service definition.

[ISO 8823] ISO. 1988. Information processing systems - Open Systems Interconnection - Connection Oriented Presentation Protocol Specification.

[ISO 8824] ISO. 1990. Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1).

[ISO 8825] ISO. 1990. Information processing systems - Open Systems Interconnection - Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1).

[ISO/IEC 9545] ISO. 1994. Information processing systems - Open Systems Interconnection - Application Layer Structure.

[ISO/IEC 9834-1] ISO. 2012. Information processing systems - Open Systems Interconnection - Procedures for the operation of OSI Registration Authorities: General procedures and top arcs of the ASN.1 Object Identifier tree.

[ISO/IEC TR 10000-1] ISO. 1998. Information processing systems - Open Systems Interconnection - International Standardized Profiles, Part 1: Taxonomy Framework.

2.2 Прочие документы

[NIST SP 500-150] NIST. Stable Implementation Agreements for Open Systems Interconnection Protocols.

[RFC791] IETF. September 1981. Internet Protocol - DARPA Internet Protocol Specification. http://tools.ietf.org/html/rfc791 .

[RFC792] IETF. September 1981. Internet Control Message Protocol - DARPA Internet Program Protocol Specification. http://tools.ietf.org/html/rfc792 .

[RFC793] IETF. September 1981. Transmission Control Program - DARPA Internet Protocol Specification. http://tools.ietf.org/html/rfc793 .

[RFC950] IETF. August 1985. Internet Subnetting. http://tools.ietf.org/html/rfc950 .

[RFC1881] IETF. December 1995. IPv6 Address Allocation Management. http://tools.ietf.org/html/rfc1881 .

[RFC2460] IETF. December 1998. Internet Protocol, Version 6 (IPv6) Specification. http://tools.ietf.org/html/rfc2460 .

3 Определения

Для целей настоящего стандарта применяются следующие определения.

3.1 Определения эталонной модели

Настоящая часть стандарта основана на концепциях, разработанных в [ISO 7498-1], и использует следующие термины, определённые в нём:

Application Entity: См. [ISO 7498-1].
Application Layer: См. [ISO 7498-1].
Application Process: См. [ISO 7498-1].
Data Link Layer: См. [ISO 7498-1].
Layer Entity: См. [ISO 7498-1].
Network Layer: См. [ISO 7498-1].
Physical Layer: См. [ISO 7498-1].
Presentation Layer: См. [ISO 7498-1].
Presentation Service: См. [ISO 7498-1].
Protocol: См. [ISO 7498-1].
Protocol Data Unit: См. [ISO 7498-1].
Service: См. [ISO 7498-1].
Service Access Point: См. [ISO 7498-1].
Session Layer: См. [ISO 7498-1].
Transfer Syntax: См. [ISO 7498-1].
Transport Layer: См. [ISO 7498-1].
Transport Protocol: См. [ISO 7498-1].
Transport Connection: См. [ISO 7498-1].

3.2 Определения имён и адресации

Настоящая часть стандарта использует следующие термины, определённые в [ISO 7498-3]:

Calling Presentation Address: См. [ISO 7498-3].
Called Presentation Address: См. [ISO 7498-3].
Presentation Address: См. [ISO 7498-3].
Responding Presentation Address: См. [ISO 7498-3].
Called Application Entity Title: См. [ISO 7498-3].
Calling Application Entity Title: См. [ISO 7498-3].

3.3 Определения соглашений о службах

Настоящая часть стандарта использует следующие термины, определённые в [ISO/TR 8509]:

Service Provider: См. [ISO/TR 8509].
Service User: См. [ISO/TR 8509].
Confirmed Service: См. [ISO/TR 8509].
Non-confirmed Service: См. [ISO/TR 8509].
Primitive: См. [ISO/TR 8509].
Request (Primitive): См. [ISO/TR 8509].
Indication (Primitive): См. [ISO/TR 8509].
Response (Primitive): См. [ISO/TR 8509].
Confirmation (Primitive): См. [ISO/TR 8509].

3.4 Определения службы представления (Presentation Service)

Настоящая часть стандарта использует следующие термины, определённые в [ISO 8822]:

Abstract Syntax: См. [ISO 8822].
Abstract Syntax Name: См. [ISO 8822].
Presentation Context: См. [ISO 8822].
Presentation Data Values: См. [ISO 8822].
Transfer Syntax Name: См. [ISO 8822].

3.5 Определения службы ACSE

Настоящая часть стандарта использует следующие термины, определённые в [ISO 8649]:

Association: См. [ISO 8649].
Application Context: См. [ISO 8649].
Association Control Service Element (ACSE): См. [ISO 8649].
Association Initiator: См. [ISO 8649].

3.6 Определение из введения и обзора DICOM

Настоящая часть стандарта использует следующие термины, определённые в PS3.1:

Message: См. Message в PS3.1 .

3.7 Определения средств поддержки взаимодействия DICOM

Следующие определения обычно используются в настоящей части стандарта:

DICOM Upper Layer Service: Протоколы верхнего уровня (Upper Layer) относятся к сеансовому (Session), представительному (Presentation) и части прикладного (Application) уровня эталонной модели ISO. Эти протоколы обеспечивают службу верхнего уровня (Upper Layer Service). Данная служба является собственным подмножеством службы ACSE и службы уровня представления OSI.

3.8 Определения класса служб DICOM

Настоящая часть стандарта использует следующие термины, определённые в PS3.4:

Service-Object Pair Instance (SOP Instance): См. Service-Object Pair Instance в PS3.4 .

3.9 Определения структур данных и кодирования DICOM

Настоящая часть стандарта использует следующие термины, определённые в PS3.5:

Data Set: См. Data Set в PS3.5 .
Unique Identifier (UID): См. Unique Identifier в PS3.5 .

4 Символы и сокращения

В настоящей части стандарта используются следующие символы и сокращения.

ACR: American College of Radiology
ACSE: Association Control Service Element
ASCII: American Standard Code for Information Interchange
AE: Application Entity
ANSI: American National Standards Institute
AP: Application Process
ASE: Application Service Element
ARTIM: Association Request/Reject/Release Timer
CEN TC251: Comite Europeen de Normalisation-Technical Committee 251 - Medical Informatics
DICOM: Digital Imaging and Communications in Medicine
FDDI: Fiber Distributed Data Interface
HL7: Health Level 7
IEC: International Electrotechnical Commission
IEEE: Institute of Electrical and Electronics Engineers
ISDN: Integrated Services Digital Network
ISO: International Organization for Standardization
ISP: International Standardized Profile
JIRA: Japan Medical Imaging and Radiological Systems Industries Association
LAN: Local Area Network
NEMA: National Electrical Manufacturers Association
NIST: National Institute of Standards and Technology
OSI: Open Systems Interconnection
PDU: Protocol Data Unit
PDV: Presentation Data Value
SAP: Service Access Point
TCP/IP: Transmission Control Program/Internet Protocol
UID: Unique Identifier
UL: Upper Layer
WAN: Wide Area Network

5 Соглашения

В таблицах описания служб, приведённых в настоящей части стандарта, используются следующие соглашения.

(=): То же значение параметра, что использовалось в запросе (indication) или подтверждении (confirmation), должно быть тем же, что и в запросе (request) или ответе (response) соответственно.
C: Условный (по выбору пользователя)
M: Обязательное использование
MF: Обязательное с фиксированным значением
NU: Не используется
P: Инициируется поставщиком службы
U: По выбору пользователя
UF: По выбору пользователя с фиксированным значением

Пустые поля не применяются.

6 Среда поддержки сетевого взаимодействия

Сетевые службы взаимодействия (Network Communication Services), определяемые в PS3.8, представляют собой набор универсальных служб, обеспечивающих взаимодействие прикладных объектов DICOM (Application Entities). Они являются собственным подмножеством служб, предоставляемых службой представления OSI (OSI Presentation Service, ISO 8822) и элементом служб управления ассоциацией OSI (Association Control Service Element, ACSE, ISO 8649). Они называются службой верхнего уровня (Upper Layer Service или UL Service). Служба UL стандарта DICOM определяется в Разделе 7.

Эта служба UL обеспечивается протоколом верхнего уровня для TCP/IP (Upper Layer Protocol for TCP/IP, см. Раздел 9).

Рисунок 6-1 показывает стек протоколов TCP/IP, доступный для поддержки взаимодействия прикладных объектов DICOM.

Рисунок 6-1. Архитектура сетевых протоколов DICOM

7 Служба верхнего уровня OSI для прикладных сущностей DICOM

В данном разделе приведено описание того, как использовать Элемент службы управления ассоциацией OSI (ACSE) и уровень представления OSI для предоставления службы верхнего уровня, необходимой для поддержки взаимодействия прикладных сущностей DICOM. Данная служба верхнего уровня является полностью соответствующим подмножеством служб, предоставляемых ACSE и уровнем представления OSI.

Службы UL перечислены в Таблице 7-1.

Таблица 7-1. Службы верхнего уровня

СЛУЖБА	ТИП
A-ASSOCIATE	Подтвержденная
A-RELEASE	Подтвержденная
A-ABORT	Неподтвержденная
A-P-ABORT	Инициируемая поставщиком
P-DATA	Неподтвержденная

Помимо спецификации службы верхнего уровня, в данном разделе определяется на уровне параметров использование каждого элемента данной службы верхнего уровня прикладными сущностями DICOM. Правила, регламентирующие использование данной службы верхнего уровня прикладными сущностями DICOM, рассмотрены в PS3.7.

7.1 Служба A-ASSOCIATE

Установление ассоциации между двумя AE должно выполняться посредством примитивов запроса, индикации, ответа и подтверждения A-ASSOCIATE службы ACSE. Инициатор службы далее называется инициатором запроса, а пользователь службы, получающий индикацию A-ASSOCIATE, далее называется акцептором. Данная служба является подтвержденной.

Примечание

Служба A-ASSOCIATE поддерживает эквивалент установления канала в соединении точка-точка (см. отмененный PS3.9).

Рисунок 7-1 иллюстрирует установление ассоциации между двумя AE.

Рисунок 7-1. Запрос ассоциации

7.1.1 Параметры A-ASSOCIATE

Таблица 7-2 перечисляет параметры, которые должны требоваться для службы A-ASSOCIATE, используемой прикладными сущностями DICOM в настоящем Стандарте.

Таблица 7-2. Ключевые параметры службы A-ASSOCIATE

A-ASSOCIATE parameter name	Запрос	Индикация	Ответ	Подтверждение
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(=)

Примечание

См. Раздел 5 настоящего документа для ознакомления с условными обозначениями таблиц.

Таблица 7-3 перечисляет параметры службы A-ASSOCIATE, которые должны содержать фиксированные значения или не должны использоваться прикладными сущностями DICOM в настоящем Стандарте.

Таблица 7-3. Параметр службы A-ASSOCIATE (фиксированный или не используется)

A-ASSOCIATE parameter name	Запрос	Индикация	Ответ	Подтверждение
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 Режим (фиксированный)

Этот параметр допускает согласование дополнительного параметра службы OSI-ACSE Mode. Прикладные сущности DICOM используют только значение по умолчанию "normal". Поэтому этот параметр всегда должен указывать значение "normal".

7.1.1.2 Имя контекста приложения

Этот параметр идентифицирует контекст приложения, предложенный инициатором запроса. Акцептор должен вернуть то же или другое имя. Возвращенное имя должно указывать контекст приложения, используемый для данной ассоциации. Дополнительное обсуждение имён контекстов приложения приведено в Приложении A.

Контекст приложения — это явно определённый набор элементов служб приложения, связанных с ними параметров, а также любой другой информации, необходимой для взаимодействия прикладных сущностей в рамках ассоциации.

Примечание

Предложение альтернативного контекста приложения со стороны акцептора обеспечивает механизм ограниченного согласования. Если инициатор запроса не может работать в контексте приложения акцептора, он должен выдать примитив запроса A-Abort. Имена контекстов приложения для прикладной сущности DICOM, а также правила использования имён контекстов приложения определены в PS3.7.

7.1.1.3 Заголовок вызывающего AE

Этот параметр идентифицирует прикладную сущность (AE), которая должна содержать инициатор запроса службы A-ASSOCIATE. Он основан на исходном имени приложения DICOM (Source DICOM Application Name). Связь между именами приложений DICOM и заголовками AE указана в Приложении C. Заголовок вызывающего AE может как совпадать, так и не совпадать с адресом инициатора, присутствующим в DICOM-сообщениях, передаваемых через ассоциацию.

Примечание

Ответственность за проверку того, является ли заголовок вызывающего AE одним из известных ему удалённых имён приложений DICOM, несёт пользователь UL, получивший A-ASSOCIATE-RQ.

7.1.1.4 Заголовок вызываемого AE

Этот параметр идентифицирует прикладную сущность, которая должна содержать предполагаемого акцептора службы A-ASSOCIATE. Он основан на имени приложения-получателя DICOM (Destination DICOM Application Name). Связь между именем приложения DICOM и заголовками AE указана в Приложении C. Заголовок вызываемого AE может как совпадать, так и не совпадать с адресом получателя, присутствующим в DICOM-сообщениях, передаваемых через ассоциацию.

Примечание

Ответственность за проверку того, является ли заголовок вызываемого AE его (или одним из его) именем приложения DICOM, несёт пользователь UL, получивший A-ASSOCIATE-RQ.

7.1.1.5 Заголовок отвечающего AE (фиксированный)

Этот параметр идентифицирует AE, которая должна содержать фактического акцептора службы A-ASSOCIATE. В настоящем Стандарте он всегда должен содержать то же значение, что и заголовок вызываемого AE индикации A-ASSOCIATE.

7.1.1.6 Пользовательская информация

Этот параметр должен использоваться инициатором запроса и акцептором ассоциации для включения пользовательской информации прикладной сущности DICOM. Его значение зависит от контекста приложения, сопровождающего примитив. Использование этого параметра специфицировано в Приложении D.

Примечание

Этот параметр используется для передачи инициализационной информации для прикладных сущностей DICOM, определённой в контексте приложения, указанном значением сопровождающего параметра имени контекста приложения (Application Context Name).
Приложение D определяет некоторые подэлементы пользовательской информации и ссылается на PS3.7 для спецификации дополнительных подэлементов. PS3.7, в свою очередь, ссылается на PS3.4 для спецификации информации о классе службы и приложении (Service-class-application-information), используемой в некоторых подэлементах.

7.1.1.7 Результат

Этот параметр должен предоставляться либо акцептором запроса A-ASSOCIATE, либо поставщиком службы UL (функция, связанная с ACSE), либо поставщиком службы UL (функция, связанная с представлением). Он должен указывать результат использования службы A-ASSOCIATE. Он должен принимать одно из следующих символических значений:

accepted;
rejected (permanent);
rejected (transient).

Примечание

Значение rejected (permanent) означает, что вызывающему ассоциацию пользователю UL (при возврате такого результата на запрос ассоциации) не нужно «вызывать позже». Существует постоянная ситуация, препятствующая установлению ассоциации (например, неизвестное удалённое имя приложения DICOM).

7.1.1.8 Источник результата

Значение параметра предоставляется поставщиком службы UL. Он идентифицирует источник формирования параметра Result и параметра Diagnostic, если он присутствует. Он должен принимать одно из следующих символических значений:

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

Примечание

Если параметр Result имеет значение "accepted", значение этого параметра — "UL service-user".

7.1.1.9 Диагностика

Этот параметр должен использоваться только в том случае, если параметр Result имеет значение "rejected (permanent)" или "rejected (transient)". Он должен использоваться для предоставления диагностической информации о результате службы A-ASSOCIATE.

Если параметр Result Source имеет значение "UL service-user", он должен принимать одно из следующих символических значений:

no-reason-given
application-context-name not supported
calling-AE-title not recognized
called-AE-title not recognized
calling-AE-qualifier not recognized (см. примечание)
calling-AP-invocation-identifier not recognized (см. примечание)
calling-AE-invocation-identifier not recognized (см. примечание)
called-AE-qualifier not recognized (см. примечание)
called-AP-invocation-identifier not recognized (см. примечание)
called-AE-invocation-identifier not recognized (см. примечание)

Если параметр Result Source имеет значение "UL service-provider" (функция, связанная с ACSE), он должен принимать одно из следующих символических значений:

no-reason-given
no-common-UL version

Если источник результата имеет значение "UL service-provider" (функция, связанная с представлением), он должен принимать следующие символические значения:

no-reason-given
temporary-congestion
local-limit-exceeded
called-(Presentation) -address-unknown
Presentation-protocol version not supported
no-(Presentation) Service Access Point (SAP) available

Примечание

Несмотря на то, что некоторые из вышеуказанных символических значений соответствуют ошибкам параметров, не используемым в настоящем Стандарте, они включены для возможности уведомления об ошибках, возникающих в результате несанкционированного использования этих параметров.

7.1.1.10 Адрес представления вызывающего

Этот параметр должен содержать структурированный адрес назначения, однозначно определённый в структуре глобальных сетевых адресов. Это должен быть адрес TCP/IP. См. Приложение C.

7.1.1.11 Адрес представления вызываемого

7.1.1.12 Адрес представления отвечающего

В настоящем Стандарте адрес представления отвечающего всегда должен содержать то же значение, что и адрес представления вызываемого (called Presentation Address) индикации A-ASSOCIATE. Этот параметр должен содержать структурированный адрес назначения, однозначно определённый в структуре глобальных сетевых адресов.

7.1.1.13 Список определения контекстов представления

Этот параметр, используемый в запросе или индикации A-ASSOCIATE, должен состоять из списка, содержащего один или несколько контекстов представления. Каждый элемент должен содержать три компонента: идентификатор контекста представления, имя абстрактного синтаксиса (Abstract Syntax Name) и список из одного или нескольких имён трансферного синтаксиса (Transfer Syntax Names).

Компоненты идентификации контекста представления этого параметра существуют для различения контекстов представления при обмене данными. Такая идентификация контекста(ов) представления применяется только в рамках данной ассоциации (т.е. различные контексты представления могут идентифицироваться одним и тем же идентификатором контекста представления в разных ассоциациях). Инициатор ассоциации (association-requestor) обязан назначить произвольный, но не использованный идентификатор для каждого предлагаемого контекста представления в данной ассоциации. Не существует ограничений на порядок расположения контекстов представления относительно их идентификаторов.

Примечание

Отдельный контекст представления будет связан с каждым именем абстрактного синтаксиса (Abstract Syntax Name) в каждом из элементов параметра списка определения контекстов представления (Presentation Context Definition List). Если одно и то же имя абстрактного синтаксиса встречается более одного раза, для каждого вхождения будет создан отдельный и чётко идентифицированный контекст представления (поскольку для одного контекста представления может быть принят только один трансферный синтаксис).

Абстрактные синтаксисы, определённые настоящим Стандартом и используемые прикладными сущностями DICOM, определены в PS3.4. Трансферные синтаксисы, определённые настоящим Стандартом и используемые прикладными сущностями DICOM, определены в PS3.5. Дополнительное обсуждение абстрактных и трансферных синтаксисов приведено в Приложении B.

7.1.1.14 Список результатов определения контекстов представления

Этот параметр, используемый в ответе и подтверждении A-ASSOCIATE, указывает принятие или отклонение каждого из определений контекстов представления, предложенных в параметре списка определения контекстов представления (Раздел 7.1.1.13). Параметр списка результатов определения контекстов представления (Presentation Context Definition Result List) должен иметь форму списка значений результатов. Существует однозначное соответствие между каждым из этих значений результатов и каждым из контекстов представления, предложенных в параметре списка определения контекстов представления. Каждое значение результата представляет «acceptance» (принятие), «user-rejection» (отклонение пользователем) или «provider-rejection» (отклонение поставщиком). Значения результатов назначаются пользователем UL в примитиве ответа. Значения результатов могут быть отправлены в любом порядке.

Примечание

Порядок результатов может отличаться от предложенного порядка. Порядок не обязательно должен быть отсортирован по идентификатору, и инициатор не может предполагать или полагаться на какой-либо конкретный порядок.

В настоящем Стандарте для каждого контекста представления должен согласовываться только один трансферный синтаксис, даже если в конкретном контексте представления списка определения контекстов представления могло быть предложено более одного варианта трансферного синтаксиса.

7.1.1.15 Требования к представлению (фиксированное значение)

Этот параметр допускает согласование дополнительных функциональных блоков представления, помимо базового ядра представления (Presentation Kernel). Прикладные сущности DICOM используют только функциональный блок ядра (Kernel Functional Unit). Поэтому этот параметр всегда должен указывать "Presentation Kernel".

7.1.1.16 Требования к сеансу (фиксированное значение)

Этот параметр допускает согласование дополнительных функциональных блоков сеанса, помимо ядра сеанса (Session Kernel). Прикладными сущностями DICOM должен использоваться только функциональный блок ядра (Kernel) совместно с функциональным блоком полного дуплекса (Full Duplex Functional Unit).

7.1.1.17 Прочие параметры

Несколько дополнительных параметров, определённых в стандартах OSI ACSE (ISO 8649) и OSI Presentation Service (ISO 8822), здесь не идентифицированы. Они не требуются для взаимодействия прикладных сущностей DICOM и не должны использоваться в настоящем Стандарте.

7.1.2 Процедура службы A-ASSOCIATE

Прикладная сущность DICOM (включающая пользователя службы верхнего уровня), желающая установить ассоциацию, должна выдать примитив запроса A-ASSOCIATE. Вызываемый AE идентифицируется параметрами примитива запроса. Инициатор запроса не должен выдавать никаких примитивов, кроме примитива запроса A-ABORT, до тех пор, пока не получит примитив подтверждения A-ASSOCIATE.

Поставщик службы верхнего уровня (UL) должен выдать примитив индикации A-ASSOCIATE вызываемому AE.

Вызываемый AE должен принять или отклонить ассоциацию, отправив примитив ответа A-ASSOCIATE с соответствующим параметром Result. Поставщик службы верхнего уровня должен выдать примитив подтверждения A-ASSOCIATE с тем же параметром Result. Параметру Result Source должно быть присвоено символическое значение "UL service-user".

Если акцептор принимает ассоциацию, она становится доступной для использования. Оба AE теперь могут использовать любую службу, предоставляемую контекстом приложения DICOM, действующим в данный момент (за исключением A-ASSOCIATE).

Примечание

Это означает, что после установления ассоциации DICOM-сообщения могут обмениваться, как определено в PS3.7.

Если вызываемый AE отклоняет ассоциацию, ассоциация не должна быть установлена.

Поставщик службы UL может быть не способен поддержать запрошенную ассоциацию. В этой ситуации он должен вернуть примитив подтверждения A-ASSOCIATE инициатору запроса с соответствующим параметром Result (отклонено). Параметру Result Source должно быть соответствующим образом присвоено символическое значение "UL service-provider (ACSE related function)" или "UL service-provider (Presentation related function)". Примитив индикации не должен выдаваться. Ассоциация не должна быть установлена.

Как инициатор ассоциации (association-requestor), так и акцептор могут прервать процедуру службы A-ASSOCIATE, выдав примитив запроса A-ABORT (см. Раздел 7.3). Удалённый AE получает примитив индикации A-ABORT. Ассоциация не должна быть установлена.

7.2 Служба A-RELEASE

Корректное завершение ассоциации между двумя AE должно выполняться посредством примитивов запроса, индикации, ответа и подтверждения A-RELEASE службы ACSE. Инициатор службы далее называется инициатором запроса, а пользователь службы, получающий индикацию A-RELEASE, далее называется акцептором. Данная служба является подтвержденной.

Рисунок 7-2 иллюстрирует корректное завершение ассоциации между двумя AE.

Рисунок 7-2. Завершение ассоциации

7.2.1 Параметры A-RELEASE

Таблица 7-4 перечисляет параметры службы A-RELEASE, которые должны содержать фиксированные значения или не должны использоваться прикладными сущностями DICOM в настоящем Стандарте.

Таблица 7-4. Параметры службы A-RELEASE

A-RELEASE parameter name	Запрос	Индикация	Ответ	Подтверждение
reason	UF	UF(=)	UF	UF(=)
user information	NU	NU(=)	NU	NU(=)
result			MF	MF(=)

7.2.1.1 Причина (фиксированная)

При использовании в примитиве запроса этот параметр указывает общий уровень срочности запроса. В настоящем Стандарте этот параметр всегда должен использовать значение "normal".

7.2.1.2 Результат (фиксированный)

В настоящем Стандарте этот параметр всегда должен принимать значение "affirmative".

7.2.2 Процедура службы A-RELEASE

Пользователь службы UL, желающий завершить ассоциацию, должен выдать примитив запроса A-RELEASE. Этот инициатор запроса не должен выдавать никаких дополнительных примитивов, кроме примитива запроса A-ABORT, до тех пор, пока не получит примитив подтверждения A-RELEASE.

Примечание

Несмотря на то, что инициатор запроса службы A-RELEASE не должен выдавать никаких дополнительных примитивов, кроме A-ABORT, он может получать примитивы индикации P-DATA.

Поставщик службы UL должен выдать примитив индикации A-RELEASE акцептору. Акцептор после этого не должен выдавать никаких примитивов UL, кроме примитива ответа A-RELEASE, примитива запроса A-ABORT или примитива запроса P-DATA.

Для завершения службы A-RELEASE акцептор должен ответить на примитив индикации A-RELEASE, выдав примитив ответа A-RELEASE. Принимающая прикладная сущность DICOM всегда должна выдавать примитив ответа A-RELEASE с параметром результата "affirmative" (т.е. принимать завершение).

После выдачи ответа A-RELEASE акцептор не должен более выдавать никаких примитивов для данной ассоциации, включая запросы P-DATA.

Поставщик службы UL должен выдать примитив подтверждения A-RELEASE всегда со значением "affirmative" для параметра Result.

Инициатор запроса в любом из AE может прервать процедуру службы A-RELEASE, выдав запрос A-ABORT. Когда акцептор получает индикацию A-ABORT, ассоциация завершается с возможной потерей информации, находящейся в процессе передачи.

Коллизия процедуры службы A-RELEASE возникает, когда инициаторы запроса в обоих AE одновременно выдают примитив службы A-RELEASE. В этой ситуации оба пользователя службы UL получают неожиданный примитив индикации A-RELEASE. Для завершения нормального завершения ассоциации должна выполняться следующая последовательность:

Инициатор ассоциации (association-requestor) должен выдать примитив ответа A-RELEASE.
Акцептор ассоциации (association-acceptor) ожидает примитив подтверждения A-RELEASE от своего узла. При его получении он должен затем выдать примитив ответа A-RELEASE.
Инициатор ассоциации (association-requestor) получает примитив подтверждения A-RELEASE.

Ассоциация считается завершенной, когда оба пользователя службы ACSE получили примитив подтверждения A-RELEASE.

7.3 Служба A-ABORT

Служба A-ABORT (ACSE) должна использоваться инициатором запроса в любом из AE для аномального завершения ассоциации. Эта служба является неподтверждённой. Однако из-за возможной коллизии процедуры службы A-ABORT доставка примитива индикации не гарантируется. В случае возникновения такой коллизии оба AE уведомляются о том, что ассоциация завершена. Прерывание должно выполняться посредством примитивов запроса и индикации A-ABORT.

Примечание

Примитив запроса A-ABORT, используемый в установленной ассоциации, может привести к уничтожению данных, находящихся в процессе передачи.

Рисунок 7-3 иллюстрирует прерывание установленной ассоциации между двумя AE.

Рисунок 7-3. Прерывание ассоциации, инициированное пользователем

7.3.1 Параметры A-ABORT

Таблица 7-5 перечисляет параметры службы A-ABORT. В настоящем Стандарте прикладными сущностями DICOM должен использоваться только первый параметр.

Таблица 7-5. Параметры службы A-ABORT

A-ABORT Parameter Name	Запрос	Индикация
abort source		M
user information	NU	NU(=)

7.3.1.1 Источник прерывания

Этот параметр указывает инициирующий источник данного прерывания. Он должен принимать одно из следующих символических значений:

UL service-user
UL service-provider (ACSE related)

7.3.2 Процедура службы A-ABORT

При использовании службы A-ABORT ассоциация должна быть аномально завершена одновременно с аномальным разрывом базового соединения.

Пользователь службы UL, желающий аномально завершить ассоциацию, должен выдать примитив запроса A-ABORT. Этот инициатор запроса не должен выдавать никаких дополнительных примитивов для ассоциации.

Поставщик службы UL должен выдать примитив индикации A-ABORT акцептору. Поставщик службы UL должен присвоить значение "UL service-user" параметру Abort Source. Ассоциация и базовое соединение завершены.

Поставщик службы UL (функции, связанные с ACSE) может сам вызвать аномальное завершение ассоциации из-за внутренних ошибок. В этом случае поставщик службы UL должен выдать примитивы индикации A-ABORT акцепторам в обоих AE. Поставщик службы UL должен присвоить значение "UL service-provider" параметру Abort Source. Параметр пользовательской информации не должен использоваться.

7.4 Служба A-P-ABORT

Служба A-P-ABORT (ACSE) должна использоваться поставщиком службы UL для сигнализации об аномальном завершении ассоциации вследствие проблем в службах на уровне представления и ниже. Данное событие указывает на возможную потерю информации, находящейся в процессе передачи. A-P-ABORT — это служба, инициируемая поставщиком.

Рисунок 7-4 иллюстрирует прерывание установленной ассоциации поставщиком службы UL.

Рисунок 7-4. Прерывание, инициированное поставщиком

7.4.1 Параметр A-P-ABORT

Таблица 7-6 перечисляет параметр, который должен требоваться для службы A-P-ABORT.

Таблица 7-6. Параметры службы A-P-ABORT

A-P-ABORT Parameter Name	Индикация
provider reason	P

Параметр причины поставщика (provider reason) должен использоваться для передачи одной из следующих причин:

reason-not-specified
unrecognized-pdu
unexpected-pdu
unexpected-session-service primitive
unrecognized-pdu parameter
unexpected-pdu parameter
invalid-pdu-parameter value

Примечание

В дополнение к этим причинам может использоваться локально определённый список причин для отражения ошибок, вызвавших прерывание и возникших на уровне сеанса, транспорта, сети, канального и физического уровней. Формирование и обработка таких ошибок являются внутренними для реализации и, следовательно, выходят за рамки настоящего стандарта передачи данных.

7.4.2 Процедура службы A-P-ABORT

При обнаружении внутренней ошибки поставщиком службы UL примитивы индикации A-P-ABORT должны быть выданы акцепторам в обоих AE. Ассоциация должна быть аномально завершена. Инициаторы запроса в обоих AE не должны выдавать никаких дополнительных примитивов для ассоциации.

7.5 Информация о последовательности

Взаимодействия между конкретными процедурами служб, рассмотренными в Разделе 7.1, Разделе 7.2, Разделе 7.3 и Разделе 7.4 для подмножества ACSE службы верхнего уровня, определены в пункте 10 ISO 8649 — Определение службы ACSE (The ACSE Service Definition).

7.6 Служба P-DATA

Эта служба P-DATA уровня представления должна использоваться любым из AE для обеспечения обмена информацией приложения (т.е. DICOM-сообщениями). DICOM-сообщения должны обмениваться, как определено в PS3.7. Ассоциация обеспечивает одновременный двунаправленный обмен примитивами запроса/индикации P-DATA.

Рисунок 7-5 иллюстрирует передачу данных по установленной ассоциации между двумя AE.

Рисунок 7-5. Передача данных

7.6.1 Параметры P-DATA

Таблица 7-7 перечисляет параметр, который должен требоваться для службы P-DATA.

Таблица 7-7. Параметр службы P-DATA

P-DATA Parameter Name	Запрос	Индикация
presentation data value list	M	M(=)

Параметр списка значений данных представления (Presentation Data Value List) должен содержать одно или несколько значений данных представления (Presentation Data Values, PDV). Каждый PDV должен состоять из двух параметров: идентификатора контекста представления (Presentation Context ID) и значений пользовательских данных (User Data). Значения пользовательских данных берутся из абстрактного синтаксиса и кодируются в трансферном синтаксисе, идентифицированном идентификатором контекста представления. Этот ссылочный идентификатор контекста представления идентифицирует один из контекстов представления, согласованных во время установления ассоциации. Формат значений пользовательских данных, используемых в каждом PDV прикладными сущностями DICOM, специфицирован в Приложении E.

8 Профиль верхнего уровня DICOM OSI

Аннулировано. См. PS 3.8 2001.

9 Протокол верхнего уровня DICOM для TCP/IP

Протокол верхнего уровня DICOM, определяемый в данном разделе, должен использоваться совместно с транспортными уровнями TCP/IP..

9.1 Использование транспортной службы, предоставляемой TCP

9.1.1 Общие положения

Существует взаимно однозначное соответствие между транспортным соединением TCP и ассоциацией верхнего уровня. Поэтому применяются следующие правила:

Каждая ассоциация верхнего уровня должна поддерживаться одним и только одним транспортным соединением TCP.
Каждое транспортное соединение TCP должно поддерживать одну и только одну ассоциацию верхнего уровня.

Службы, предоставляемые транспортными службами TCP, формально не документированы. Поэтому в данном разделе используются «общепринятые» термины, применяемые в ряде реализаций программных интерфейсов TCP (например, Sockets). Однако для поддержки TCP/IP требуются следующие RFC. Они определяют поддержку, необходимую для IPv4.

RFC793, Transmission Control Program - DARPA Internet Protocol Specification
RFC791, Internet Protocol - DARPA Internet Protocol Specification
RFC792, Internet Control Message Protocol - DARPA Internet Program Protocol Specification
RFC950, Internet Subnetting

Кроме того, устройства, поддерживающие IPv6, должны соответствовать:

RFC1881, IPv6 Address Allocation Management
RFC2460, Internet Protocol, Version 6 (IPv6) Specification

Примечание

Существует множество других RFC, которые также могут применяться к конкретной реализации в зависимости от конкретного выбора аппаратных и программных функций.

Для установления соединения TCP должен использоваться порт TCP, служащий транспортным селектором. Сущность DICOM UL идентифицируется в заданной системе в сети по номеру порта, уникальному в пределах этой системы. Номера портов удалённых сущностей DICOM UL (хорошо известный номер порта или другие номера) должны быть настраиваемыми на сущностях DICOM UL.

Примечание

Настоятельно рекомендуется, чтобы системы, поддерживающие единственную сущность DICOM UL, использовали в качестве своего порта «хорошо известный порт», зарегистрированный для протокола верхнего уровня DICOM: номер порта 104 (десятичный), если операционная система разрешает доступ к привилегированным портам (в диапазоне от 0 до 1023), в противном случае рекомендуется использовать «зарегистрированный» номер порта 11112 (десятичный). См. «http://www.iana.org/assignments/port-numbers».

Прикладные сущности могут также получать доступ к транспортным службам TCP через безопасное транспортное соединение. Характер этого безопасного транспортного соединения определяется профилями безопасности (см. PS3.15). Профили безопасности определяют минимальные механизмы, необходимые для поддержки данного профиля. Другие механизмы также могут использоваться, если это согласовано при установлении безопасного транспортного соединения.

Примечание

DICOM не определяет, как устанавливается безопасное транспортное соединение, или значимость любых сертификатов, обменяемых во время аутентификации равноправных сущностей. Эти вопросы оставлены на усмотрение приложения, которое, как предполагается, следует некоторой политике безопасности. После того как приложение установило безопасное транспортное соединение, ассоциация верхнего уровня может использовать этот безопасный канал.
Может существовать взаимодействие между размером PDU и размером записи безопасного транспортного соединения, влияющее на эффективность передачи.
Зарегистрированные порты для безопасных транспортных соединений определены в PS3.15.

9.1.2 Открытие транспортного соединения TCP

Когда ассоциация должна быть установлена сущностью DICOM верхнего уровня, примитив запроса TRANSPORT CONNECT должен быть выдан транспортной службе TCP (активное открытие). После получения подтверждения транспортного соединения TCP (открытие завершено), PDU A-ASSOCIATE-RQ должна быть отправлена/записана в установленное транспортное соединение.

Когда сущность DICOM верхнего уровня активируется (состояние простоя ассоциации), она должна ожидать транспортные соединения TCP в пассивном режиме, инициируя «прослушивание» (listen). При получении входящего индикатора транспортного соединения TCP из сети он принимается, и должен быть запущен таймер ARTIM (таймер запроса/отклонения/завершения ассоциации). Любой дальнейший обмен PDU (чтение/запись) должен выполняться в соответствии со спецификациями конечного автомата верхнего уровня (включая истечение таймера ARTIM до получения PDU A-ASSOCIATE-RQ, см. Раздел 9.2).

9.1.3 Передача данных по соединению TCP

Обмен данными PDU (чтение/запись) по установленному соединению TCP должен следовать спецификациям конечного автомата протокола верхнего уровня DICOM (см. Раздел 9.2) и структуре PDU протокола верхнего уровня DICOM (см. Раздел 9.3).

9.1.4 Закрытие транспортного соединения TCP

Транспортные соединения TCP должны закрываться с использованием параметра «без задержки» (don't linger).

Транспортное соединение TCP закрывается в ряде ситуаций. Они описаны в конечном автомате протокола верхнего уровня DICOM. Некоторые типичные случаи рассматриваются ниже:

После отправки A-RELEASE-RQ и получения PDU A-RELEASE-RP
Когда транспортное соединение установлено удалённой сущностью UL DICOM и PDU A-ASSOCIATE-RQ не получена до истечения таймера ARTIM
Когда получена PDU A-ABORT
Когда PDU A-ABORT отправлена и таймер ARTIM истекает до закрытия транспортного соединения
Когда соединение TCP разъединяется поставщиком транспортной службы (например, из-за сбоя сети)
Когда соединение TCP разъединяется удалённой сущностью UL DICOM

Примечание

За исключением нормального завершения отклонения, завершения или прерывания ассоциации, а также в специфических ситуациях, таких как временная нехватка ресурсов, конечный автомат верхнего уровня не должен разрывать соединение TCP или отклонять его установление. Надлежащим поведением является использование служб отклонения или прерывания ассоциации.
Таймер ARTIM не должен использоваться для контроля за установлением или завершением ассоциации. Такой механизм относится к определению протокола уровня, находящегося над протоколом верхнего уровня DICOM (т. е. прикладной сущности DICOM, см. PS3.7).

9.1.5 Таймер ARTIM

Значение таймера ARTIM, используемого для управления запросом, отклонением и завершением ассоциаций на сущности DICOM UL, должно быть настраиваемым для поддержки широкого диапазона сетевых конфигураций.

9.2 Конечный автомат протокола верхнего уровня DICOM для TCP/IP

9.2.1 Определение состояний автомата

Таблица 9-1. Нет ассоциации

Состояние	Определение
Sta 1	Idle

Таблица 9-2. Установление ассоциации

Состояние	Определение
Sta 2	Транспортное соединение открыто (ожидание PDU A-ASSOCIATE-RQ)
Sta 3	Ожидание локального примитива ответа A-ASSOCIATE (от локального пользователя)
Sta 4	Ожидание завершения открытия транспортного соединения (от локальной транспортной службы)
Sta 5	Ожидание PDU A-ASSOCIATE-AC или A-ASSOCIATE-RJ

Таблица 9-3. Передача данных

Состояние	Определение
Sta 6	Ассоциация установлена и готова к передаче данных

Таблица 9-4. Завершение ассоциации

Состояние	Определение
Sta 7	Ожидание PDU A-RELEASE-RP
Sta 8	Ожидание локального примитива ответа A-RELEASE (от локального пользователя)
Sta 9	Сторона инициатора запроса при коллизии завершения; ожидание ответа A-RELEASE (от локального пользователя)
Sta 10	Сторона акцептора при коллизии завершения; ожидание PDU A-RELEASE-RP
Sta 11	Сторона инициатора запроса при коллизии завершения; ожидание PDU A-RELEASE-RP
Sta 12	Сторона акцептора при коллизии завершения; ожидание примитива ответа A-RELEASE (от локального пользователя)

Таблица 9-5. Ожидание закрытия транспортного соединения

Состояние	Определение
Sta 13	Ожидание индикатора закрытия транспортного соединения (ассоциация больше не существует)

9.2.2 Определение действий конечного автомата

Таблица 9-6. Действия, связанные с установлением ассоциации

Действие	Определение
AE-1	Выдать примитив запроса TRANSPORT CONNECT локальной транспортной службе Следующее состояние —Sta4
AE-2	Отправить PDU A-ASSOCIATE-RQ Следующее состояние —Sta5
AE-3	Выдать примитив подтверждения A-ASSOCIATE (принятие) Следующее состояние —Sta6
AE-4	Выдать примитив подтверждения A-ASSOCIATE (отклонение) и закрыть транспортное соединение Следующее состояние —Sta1
AE-5	Выдать примитив ответа транспортного соединения; запустить таймер ARTIM Следующее состояние —Sta2
AE-6	Остановить таймер ARTIM и если A-ASSOCIATE-RQ приемлема для поставщика службы: выдать примитив индикации A-ASSOCIATE Следующее состояние —Sta3 в противном случае: выдать PDU A-ASSOCIATE-RJ и запустить таймер ARTIM Следующее состояние —Sta13
AE-7	Отправить PDU A-ASSOCIATE-AC Следующее состояние —Sta6
AE-8	Отправить PDU A-ASSOCIATE-RJ и запустить таймер ARTIM Следующее состояние —STA13

Таблица 9-7. Действия, связанные с передачей данных

Состояние	Определение
DT-1	Отправить PDU P-DATA-TF Следующее состояние —Sta6
DT-2	Выдать примитив индикации P-DATA Следующее состояние —Sta6

Состояние

Определение

DT-1

Отправить PDU P-DATA-TF

Следующее состояние —Sta6

DT-2

Выдать примитив индикации P-DATA

Следующее состояние —Sta6

Таблица 9-8. Действия, связанные с завершением ассоциации

Действие	Определение
AR-1	Отправить PDU A-RELEASE-RQ Следующее состояние —Sta7
AR-2	Выдать примитив индикации A-RELEASE Следующее состояние —Sta8
AR-3	Выдать примитив подтверждения A-RELEASE и закрыть транспортное соединение Следующее состояние —Sta1
AR-4	Выдать PDU A-RELEASE-RP и запустить таймер ARTIM Следующее состояние —Sta13
AR-5	Остановить таймер ARTIM Следующее состояние —Sta1
AR-6	Выдать индикацию P-DATA Следующее состояние —Sta7
AR-7	Выдать PDU P-DATA-TF Следующее состояние —Sta8
AR-8	Выдать индикацию A-RELEASE (коллизия завершения): если инициатор ассоциации, следующее состояние — Sta9 если нет, следующее состояние — Sta10
AR-9	Отправить PDU A-RELEASE-RP Следующее состояние —Sta11
AR-10	Выдать примитив подтверждения A-RELEASE Следующее состояние —Sta12

Таблица 9-9. Действия, связанные с прерыванием ассоциации

Действие	Определение
AA-1	Отправить PDU A-ABORT (источник — пользователь службы) и запустить (или перезапустить, если уже запущен) таймер ARTIM Следующее состояние —Sta13
AA-2	Остановить таймер ARTIM, если он запущен. Закрыть транспортное соединение Следующее состояние —Sta1
AA-3	Если (прерывание инициировано пользователем службы): выдать индикацию A-ABORT и закрыть транспортное соединение в противном случае (прерывание инициировано поставщиком службы): выдать индикацию A-P-ABORT и закрыть транспортное соединение Следующее состояние —Sta1
AA-4	Выдать примитив индикации A-P-ABORT Следующее состояние —Sta1
AA-5	Остановить таймер ARTIM Следующее состояние —Sta1
AA-6	Игнорировать PDU Следующее состояние —Sta13
AA-7	Отправить PDU A-ABORT Следующее состояние —Sta13
AA-8	Отправить PDU A-ABORT (источник — поставщик службы), выдать индикацию A-P-ABORT и запустить таймер ARTIM Следующее состояние —Sta13

9.2.3 Таблица переходов состояний протокола верхнего уровня DICOM для TCP/IP

Переходы состояний протокола верхнего уровня DICOM определены в Таблице 9-10. Эта таблица охватывает как нормальные, так и ошибочные случаи работы протокола. В таблице описаны как вызываемая, так и вызывающая стороны ассоциации.

Таблица 9-10. Таблица переходов состояний протокола верхнего уровня DICOM

СОСТОЯНИЯ	Нет ассоц.ⁿ	Установление ассоциации				Передача данных	Завершение ассоциации (нормальное и коллизия)						Ожидание закр. Tp
СОБЫТИЯ	Sta1	Sta2	Sta3	Sta4	Sta5	Sta6	Sta7	Sta8	Sta9	Sta10	Sta11	Sta12	Sta13
Запрос A-ASSOCIATE (локальный пользователь)	AE-1 Sta4
Подтверждение трансп. соединенияⁿ (локальная транспортная служба)				AE-2 Sta5
PDU A-ASSOCIATE-AC (получена по транспортному соединению)		AA-1 Sta13	AA-8 Sta13		AE-3 Sta6	AA-8 Sta13	AA-8 Sta13	AA-8 Sta13	AA-8 Sta13	AA-8 Sta13	AA-8 Sta13	AA-8 Sta13	AA-6 Sta13
PDU A-ASSOCIATE-RJ (получена по транспортному соединению)		AA-1 Sta13	AA-8 Sta13		AE-4 Sta1	AA-8 Sta13	AA-8 Sta13	AA-8 Sta13	AA-8 Sta13	AA-8 Sta13	AA-8 Sta13	AA-8 Sta13	AA-6 Sta13
Индикатор транспортного соединения (локальная транспортная служба)	AE-5 Sta2
PDU A-ASSOCIATE-RQ (получена по транспортному соединению)		AE-6 Sta3 or 13	AA-8 Sta13		AA-8 Sta13	AA-8 Sta13	AA-8 Sta13	AA-8 Sta13	AA-8 Sta13	AA-8 Sta13	AA-8 Sta13	AA-8 Sta13	AA-7 Sta13
Примитив ответа A-ASSOCIATE (принятие)			AE-7 Sta6
Примитив ответа A-ASSOCIATE (отклонение)			AE-8 Sta13
Примитив запроса P-DATA						DT-1 Sta6		AR-7 Sta8
PDU P-DATA-TF		AA-1 Sta13	AA-8 Sta13		AA-8 Sta13	DT-2 Sta6	AR-6 Sta7	AA-8 Sta13	AA-8 Sta13	AA-8 Sta13	AA-8 Sta13	AA-8 Sta13	AA-6 Sta13
Примитив запроса A-RELEASE						AR-1 Sta7
PDU A-RELEASE-RQ (получена по открытому транспортному соединению)		AA-1 Sta13	AA-8 Sta13		AA-8 Sta13	AR-2 Sta8	AR-8 Sta9 or 10	AA-8 Sta13	AA-8 Sta13	AA-8 Sta13	AA-8 Sta13	AA-8 Sta13	AA-6 Sta13
PDU A-RELEASE-RP (получена по транспортному соединению)		AA-1 Sta13	AA-8 Sta13		AA-8 Sta13	AA-8 Sta13	AR-3 Sta1	AA-8 Sta13	AA-8 Sta13	AR-10 Sta12	AR-3 Sta1	AA-8 Sta13	AA-6 Sta13
Примитив ответа A-RELEASE								AR-4 Sta13	AR-9 Sta11			AR-4 Sta13
Примитив запроса A-ABORT			AA-1 Sta13	AA-2 Sta1	AA-1 Sta13	AA-1 Sta13	AA-1 Sta13	AA-1 Sta13	AA-1 Sta13	AA-1 Sta13	AA-1 Sta13	AA-1 Sta13
PDU A-ABORT (получена по открытому транспортному соединению)		AA-2 Sta1	AA-3 Sta1		AA-3 Sta1	AA-3 Sta1	AA-3 Sta1	AA-3 Sta1	AA-3 Sta1	AA-3 Sta1	AA-3 Sta1	AA-3 Sta1	AA-2 Sta1
Индикатор закрытия транспортного соединения (локальная транспортная служба)		AA-5 Sta1	AA-4 Sta1	AA-4 Sta1	AA-4 Sta1	AA-4 Sta1	AA-4 Sta1	AA-4 Sta1	AA-4 Sta1	AA-4 Sta1	AA-4 Sta1	AA-4 Sta1	AR-5 Sta1
Таймер ARTIM истёк (таймер отклонения/завершения ассоциации)		AA-2 Sta1											AA-2 Sta1
Получена нераспознанная или недопустимая PDU		AA-1 Sta13	AA-8 Sta13		AA-8 Sta13	AA-8 Sta13	AA-8 Sta13	AA-8 Sta13	AA-8 Sta13	AA-8 Sta13	AA-8 Sta13	AA-8 Sta13	AA-7 Sta13

9.3 Структура единиц данных протокола верхнего уровня DICOM для TCP/IP

9.3.1 Общие положения

Единицы данных протокола (PDU) представляют собой форматы сообщений, которыми обмениваются равноправные сущности в пределах уровня. PDU состоит из управляющей информации протокола и пользовательских данных. PDU состоят из обязательных фиксированных полей, за которыми следуют необязательные переменные поля, содержащие один или несколько элементов и/или подэлементов.

Элементы нераспознанных типов должны игнорироваться и пропускаться. Элементы должны располагаться в порядке возрастания их типов. Несколько экземпляров одного и того же элемента могут быть допустимы или нет, как указано для каждого элемента.

Протокол DICOM UL состоит из семи единиц данных протокола:

A-ASSOCIATE-RQ PDU
A-ASSOCIATE-AC PDU
A-ASSOCIATE-RJ PDU
P-DATA-TF PDU
A-RELEASE-RQ PDU
A-RELEASE-RP PDU
A-ABORT PDU

Кодирование PDU DICOM UL определяется следующим образом (порядок байтов Big Endian):

Примечание

Порядок байтов Big Endian был выбран для совместимости со средой OSI и TCP/IP. Это относится только к заголовкам PDU DICOM UL. Кодирование фрагментов сообщений PDV определяется синтаксисом передачи, согласованным при установлении ассоциации.

Каждый тип PDU состоит из одного или нескольких байтов, которые при представлении нумеруются последовательно, причём байт 1 является байтом с наименьшим номером.
Каждый байт в PDU состоит из восьми битов, которые при представлении нумеруются от 7 до 0, где бит 0 является младшим битом.
Когда последовательные байты используются для представления строки символов, наименьшие номера байтов представляют первый символ.
Когда последовательные байты используются для представления двоичного числа, байт с меньшим номером имеет наиболее значимое значение.
Байт с наименьшим номером помещается первым в потоке данных транспортной службы.
Обзор PDU представлен на Рисунке 9-1 и Рисунке 9-2. Подробная структура каждой PDU описана в следующих разделах.

Примечание

Ряд параметров, определённых в службе UL, не отражены в этих PDU (например, параметры службы, фиксированные значения, значения, не используемые прикладными сущностями DICOM).

Protocol Data Units Structure and Encoding

Рисунок 9-1. Структура и кодирование единиц данных протокола

Рисунок 9-2. Структура и кодирование единиц данных протокола

9.3.2 Структура PDU A-ASSOCIATE-RQ

PDU A-ASSOCIATE-RQ состоит из последовательности обязательных полей, за которыми следует поле переменной длины. Таблица 9-11 показывает последовательность обязательных полей.

Переменное поле должно состоять из одного элемента контекста приложения, одного или нескольких элементов контекста представления и одного элемента пользовательской информации. Подэлементы должны существовать для элементов контекста представления и пользовательской информации.

Таблица 9-11. Поля PDU A-ASSOCIATE-RQ

Байты PDU	Имя поля	Описание поля
1	PDU-type	01H
2	Reserved	Данное резервное поле должно передаваться со значением 00H, но не должно проверяться на это значение при получении.
3-6	PDU-length	Значение PDU-length должно быть равно количеству байтов от первого байта следующего поля до последнего байта переменного поля. Оно должно быть закодировано как беззнаковое двоичное число
7-8	Protocol-version	Это двухбайтовое поле должно использовать один бит для идентификации каждой версии протокола DICOM UL, поддерживаемой вызывающей оконечной системой. Данная версия — Версия 1, и она должна идентифицироваться установленным битом 0. Получатель данной PDU, реализующий только эту версию протокола DICOM UL, должен проверять только то, что бит 0 установлен.
9-10	Reserved	Данное резервное поле должно передаваться со значением 0000H, но не должно проверяться на это значение при получении.
11-26	Called-AE-title	Имя прикладного DICOM-приложения назначения. Оно должно кодироваться как 16 символов, определённых набором ISO 646:1990-Basic G0, причём начальные и конечные пробелы (20H) являются незначимыми. Значение, состоящее из 16 пробелов (20H), означающее «имя приложения не указано», не должно использоваться. Полное описание использования этого поля см. в Разделе 7.1.1.4.
27-42	Calling-AE-title	Имя исходного прикладного DICOM-приложения. Оно должно кодироваться как 16 символов, определённых набором ISO 646:1990-Basic G0, причём начальные и конечные пробелы (20H) являются незначимыми. Значение, состоящее из 16 пробелов (20H), означающее «имя приложения не указано», не должно использоваться. Полное описание использования этого поля см. в Разделе 7.1.1.3.
43-74	Reserved	Это резервное поле должно передаваться со значением 00H для всех байтов, но не проверяться на это значение при получении
75-xxx	Variable items	Это переменное поле должно содержать следующие элементы: один элемент контекста приложения, один или несколько элементов контекста представления и один элемент пользовательской информации. Полное описание использования этих элементов см. в Разделе 7.1.1.2, Разделе 7.1.1.13 и Разделе 7.1.1.6.

9.3.2.1 Структура элемента контекста приложения

Элемент контекста приложения состоит из последовательности обязательных полей, за которыми следует поле переменной длины. Таблица 9-12 показывает последовательность обязательных полей.

Таблица 9-12. Поля элемента Application Context

Байты элемента	Имя поля	Описание поля
1	Item-type	10H
2	Reserved	Данное резервное поле должно передаваться со значением 00H, но не должно проверяться на это значение при получении.
3-4	Item-length	Значение Item-length должно быть равно количеству байтов от первого байта следующего поля до последнего байта поля Application-context-name. Оно должно кодироваться как беззнаковое двоичное число.
5-xxx	Application-context-name	Допустимое имя Application-context-name должно кодироваться, как определено в Приложении F. Описание использования этого поля см. в Разделе 7.1.1.2. Имена Application-context-names структурированы как UID, определённые в PS3.5 (обзор этого понятия см. в Приложении A). Имена Application-context-names DICOM зарегистрированы в PS3.7.

9.3.2.2 Структура элемента контекста представления

Элемент контекста представления состоит из последовательности обязательных полей фиксированной длины, за которыми следует переменное поле. Таблица 9-13 показывает последовательность обязательных полей.

Переменное поле должно состоять из одного подэлемента абстрактного синтаксиса, за которым следует один или несколько подэлементов синтаксиса передачи.

Таблица 9-13. Поля элемента Presentation Context

Байты элемента	Имя поля	Описание поля
1	Item-type	20H
2	Reserved	Данное резервное поле должно передаваться со значением 00H, но не должно проверяться на это значение при получении.
3-4	Item-length	Значение Item-length должно быть равно количеству байтов от первого байта следующего поля до последнего байта последнего элемента Transfer Syntax. Оно должно кодироваться как беззнаковое двоичное число.
5	Presentation-context-ID	Значения Presentation-context-ID должны быть нечётными целыми числами от 1 до 255, кодируемыми как беззнаковое двоичное число. Полное описание использования этого поля см. в Разделе 7.1.1.13.
6	Reserved	Данное резервное поле должно передаваться со значением 00H, но не должно проверяться на это значение при получении.
7	Reserved	Данное резервное поле должно передаваться со значением 00H, но не должно проверяться на это значение при получении.
8	Reserved	Данное резервное поле должно передаваться со значением 00H, но не должно проверяться на это значение при получении.
9-xxx	Abstract/Transfer Syntax Sub-Items	Это переменное поле должно содержать следующие подэлементы: один абстрактный синтаксис и один или несколько синтаксисов передачи. Полное описание использования и кодирования этих подэлементов см. в Разделе 9.3.2.2.1 и Разделе 9.3.2.2.2.

9.3.2.2.1 Структура подэлемента абстрактного синтаксиса

Подэлемент абстрактного синтаксиса состоит из последовательности обязательных полей фиксированной длины, за которыми следует переменное поле. Таблица 9-14 показывает последовательность обязательных полей.

Таблица 9-14. Поля подэлемента Abstract Syntax

Байты элемента	Имя поля	Описание поля
1	Item-type	30H
2	Reserved	Данное резервное поле должно передаваться со значением 00H, но не должно проверяться на это значение при получении.
3-4	Item-length	Значение Item-length должно быть равно количеству байтов от первого байта следующего поля до последнего байта поля Abstract-syntax-name. Оно должно кодироваться как беззнаковое двоичное число.
5-xxx	Abstract-syntax-name	Это переменное поле должно содержать имя Abstract-syntax-name, относящееся к предлагаемому контексту представления. Допустимое имя Abstract-syntax-name должно кодироваться, как определено в Приложении F. Описание использования этого поля см. в Разделе 7.1.1.13. Имена Abstract-syntax-names структурированы как UID, определённые в PS3.5 (обзор этого понятия см. в Приложении B). Имена Abstract-syntax-names DICOM зарегистрированы в PS3.4.

9.3.2.2.2 Структура подэлемента синтаксиса передачи

Подэлемент синтаксиса передачи состоит из последовательности обязательных полей фиксированной длины, за которыми следует переменное поле. Таблица 9-15 показывает последовательность обязательных полей.

Таблица 9-15. Поля подэлемента Transfer Syntax

Байты элемента	Имя поля	Описание поля
1	Item-type	40H
2	Reserved	Данное резервное поле должно передаваться со значением 00H, но не должно проверяться на это значение при получении.
3-4	Item-length	Значение Item-length должно быть равно количеству байтов от первого байта следующего поля до последнего байта поля(ей) Transfer-syntax-name. Оно должно кодироваться как беззнаковое двоичное число.
5-xxx	Transfer-syntax-name(s)	Это переменное поле должно содержать имя Transfer-syntax-name, предложенное для данного контекста представления. Допустимое имя Transfer-syntax-name должно кодироваться, как определено в Приложении F. Описание использования этого поля см. в Разделе 7.1.1.13. Имена Transfer-syntax-names структурированы как UID, определённые в PS3.5 (обзор этого понятия см. в Приложении B). Имена Transfer-syntax-names DICOM зарегистрированы в PS3.5.

9.3.2.3 Структура элемента пользовательской информации

Элемент пользовательской информации состоит из последовательности обязательных полей фиксированной длины, за которыми следует переменное поле. Таблица 9-16 показывает последовательность обязательных полей.

Переменное поле должно состоять из одного или нескольких подэлементов User-Data.

Примечание

Подэлементы User-Data могут присутствовать в любом порядке внутри элемента User-Information. Не следует придавать значение порядку подэлементов User-Data в элементе пользовательской информации. Отправляющие приложения должны учитывать, что некоторые старые приложения могут ожидать, что подэлементы кодируются в порядке возрастания Item-type внутри включающего элемента.

Таблица 9-16. Поля элемента User Information

Байты элемента	Имя поля	Описание поля
1	Item-type	50H
2	Reserved	Данное резервное поле должно передаваться со значением 00H, но не должно проверяться на это значение при получении.
3-4	Item-length	Значение Item-length должно быть равно количеству байтов от первого байта следующего поля до последнего байта поля(ей) User-data. Оно должно кодироваться как беззнаковое двоичное число.
5-xxx	User-data	Это переменное поле должно содержать подэлементы User-data, определённые прикладной сущностью DICOM. Структура и содержание этих подэлементов определены в Приложении D.

9.3.3 Структура PDU A-ASSOCIATE-AC

PDU A-ASSOCIATE-AC состоит из последовательности обязательных полей, за которыми следует поле переменной длины. Таблица 9-17 показывает последовательность обязательных полей.

Переменное поле состоит из одного элемента контекста приложения, одного или нескольких элементов контекста представления и одного элемента пользовательской информации. Подэлементы должны существовать для элементов контекста представления и пользовательской информации.

Таблица 9-17. Поля PDU A-ASSOCIATE-AC

Байты PDU	Имя поля	Описание поля
1	PDU-type	02H
2	Reserved	Данное резервное поле должно передаваться со значением 00H, но не должно проверяться на это значение при получении.
3-6	PDU-length	Значение PDU-length должно быть равно количеству байтов от первого байта следующего поля до последнего байта переменного поля. Оно должно кодироваться как беззнаковое двоичное число.
7-8	Protocol-version	Это двухбайтовое поле должно использовать один бит для идентификации каждой версии протокола DICOM UL, поддерживаемой вызывающей оконечной системой. Данная версия — Версия 1, и она должна идентифицироваться установленным битом 0. Получатель данной PDU, реализующий только эту версию протокола DICOM UL, должен проверять только то, что бит 0 установлен.
9-10	Reserved	Данное резервное поле должно передаваться со значением 0000H, но не должно проверяться на это значение при получении.
11-26	Reserved	Данное резервное поле должно передаваться со значением, идентичным значению, полученному в том же поле PDU A-ASSOCIATE-RQ, однако его значение не должно проверяться при получении.
27-42	Reserved	Данное резервное поле должно передаваться со значением, идентичным значению, полученному в том же поле PDU A-ASSOCIATE-RQ, однако его значение не должно проверяться при получении.
43-74	Reserved	Данное резервное поле должно передаваться со значением, идентичным значению, полученному в том же поле PDU A-ASSOCIATE-RQ, однако его значение не должно проверяться при получении.
75-xxx	Variable items	Это переменное поле должно содержать следующие элементы: один элемент контекста приложения, один или несколько элементов контекста представления и один элемент пользовательской информации. Полное описание этих элементов см. в Разделе 7.1.1.2, Разделе 7.1.1.14 и Разделе 7.1.1.6.

9.3.3.1 Структура элемента контекста приложения

9.3.3.2 Структура элемента контекста представления

Элемент контекста представления состоит из последовательности обязательных полей фиксированной длины, за которыми следует переменное поле. Таблица 9-18 показывает последовательность обязательных полей.

Переменное поле должно состоять из одного подэлемента синтаксиса передачи.

Таблица 9-18. Поля элемента Presentation Context

Байты элемента	Имя поля	Описание поля
1	Item-type	21H
2	Reserved	Данное резервное поле должно передаваться со значением 00H, но не должно проверяться на это значение при получении.
3-4	Item-length	Значение Item-length должно быть равно количеству байтов от первого байта следующего поля до последнего байта подэлемента Transfer Syntax. Оно должно кодироваться как беззнаковое двоичное число.
5	Presentation-context-ID	Значения Presentation-context-ID должны быть нечётными целыми числами от 1 до 255, кодируемыми как беззнаковое двоичное число. Полное описание использования этого поля см. в Разделе 7.1.1.13.
6	Reserved	Данное резервное поле должно передаваться со значением 00H, но не должно проверяться на это значение при получении.
7	Result/Reason	Поле Result/Reason должно содержать целочисленное значение, кодируемое как беззнаковое двоичное число. Должно использоваться одно из следующих значений: 0 — принятие (acceptance) 1 — отклонение пользователем (user-rejection) 2 — нет причины (отклонение поставщиком) 3 — абстрактный синтаксис не поддерживается (отклонение поставщиком) 4 — синтаксисы передачи не поддерживаются (отклонение поставщиком)
8	Reserved	Данное резервное поле должно передаваться со значением 00H, но не должно проверяться на это значение при получении.
9-xxx	Transfer syntax sub-item	Это переменное поле должно содержать один подэлемент Transfer Syntax. Когда поле Result/Reason имеет значение, отличное от принятия (0), это поле не должно быть значимым, и его значение не должно проверяться при получении. Полное описание использования и кодирования этого элемента см. в Разделе 9.3.3.2.1.

9.3.3.2.1 Структура подэлемента синтаксиса передачи

Подэлемент синтаксиса передачи состоит из последовательности обязательных полей фиксированной длины, за которыми следует переменное поле. Таблица 9-19 показывает последовательность обязательных полей.

Таблица 9-19. Поля подэлемента Transfer Syntax

Байты элемента	Имя поля	Описание поля
1	Item-type	40H
2	Reserved	Данное резервное поле должно передаваться со значением 00H, но не должно проверяться на это значение при получении.
3-4	Item-length	Значение Item-length должно быть равно количеству байтов от первого байта следующего поля до последнего байта поля Transfer-syntax-name. Оно должно кодироваться как беззнаковое двоичное число.
5-xxx	Transfer-syntax-name	Это переменное поле должно содержать имя Transfer-syntax-name, предложенное для данного контекста представления. Допустимое имя Transfer-syntax-name должно кодироваться, как определено в Приложении F. Описание использования этого поля см. в Разделе 7.1.1.14. Имена Transfer-syntax-names структурированы как UID, определённые в PS3.5 (обзор этого понятия см. в Приложении B). Имена Transfer-syntax-names DICOM зарегистрированы в PS3.5.

9.3.3.3 Структура элемента пользовательской информации

Элемент пользовательской информации состоит из последовательности обязательных полей длины, за которыми следует переменное поле. Таблица 9-20 показывает последовательность обязательных полей.

Переменное поле должно состоять из одного или нескольких подэлементов User-Data.

Примечание

Подэлементы User-Data могут следовать в любом порядке внутри элемента User-Information. Не следует придавать значение порядку подэлементов User-Data внутри элемента User Information. Отправляющим приложениям следует учитывать, что некоторые старые приложения могут ожидать кодирования подэлементов в порядке возрастания значения поля Item-type внутри объемлющего элемента.

Таблица 9-20. Поля элемента User Information

Байты элемента	Имя поля	Описание поля
1	Item-type	50H
2	Reserved	Данное резервное поле должно передаваться со значением 00H, но не должно проверяться на это значение при получении.
3-4	Item-length	Значение Item-length должно быть равно количеству байтов от первого байта следующего поля до последнего байта поля(ей) User-data-information. Оно должно кодироваться как беззнаковое двоичное число.
5-xxx	User-data	Это переменное поле должно содержать подэлементы User-data, определённые прикладной сущностью DICOM. Структура и содержание этих подэлементов определены в Приложении D.

9.3.4 Структура PDU A-ASSOCIATE-RJ

PDU A-ASSOCIATE-RJ состоит из последовательности обязательных полей. Таблица 9-21 показывает последовательность обязательных полей.

Таблица 9-21. Поля PDU A-ASSOCIATE-RJ

Байты PDU	Имя поля	Описание поля
1	PDU-type	03H
2	Reserved	Данное резервное поле должно передаваться со значением 00H, но не должно проверяться на это значение при получении.
3-6	PDU-length	Значение PDU-length должно быть равно количеству байтов от первого байта следующего поля до последнего байта поля Reason/Diag. В случае данной PDU оно должно иметь фиксированное значение 00000004H, кодируемое как беззнаковое двоичное число.
7	Reserved	Данное резервное поле должно передаваться со значением 00H, но не должно проверяться на это значение при получении.
8	Result	Поле Result должно содержать целочисленное значение, кодируемое как беззнаковое двоичное число. Должно использоваться одно из следующих значений: 1 — постоянный отказ (rejected-permanent) 2 — временный отказ (rejected-transient)
9	Source	Поле Source должно содержать целочисленное значение, кодируемое как беззнаковое двоичное число. Должно использоваться одно из следующих значений: 1 — пользователь службы DICOM UL 2 — поставщик службы DICOM UL (функция, связанная с ACSE) 3 — поставщик службы DICOM UL (функция, связанная с представлением)
10	Reason/Diag.	Это поле должно содержать целочисленное значение, кодируемое как беззнаковое двоичное число. Если поле Source имеет значение (1) «пользователь службы DICOM UL», должно использоваться одно из следующих значений: 1 — причина не указана 2 — имя контекста приложения не поддерживается 3 — calling-AE-title не распознан 4-6 — зарезервировано 7 — called-AE-title не распознан 8-10 — зарезервировано Если поле Source имеет значение (2) «поставщик службы DICOM UL (функция, связанная с ACSE)», должно использоваться одно из следующих значений: 1 — причина не указана 2 — версия протокола не поддерживается Если поле Source имеет значение (3) «поставщик службы DICOM UL (функция, связанная с представлением)», должно использоваться одно из следующих значений: 0 — зарезервировано 1 — временная перегрузка 2 — превышен локальный лимит 3-7 — зарезервировано Примечание Резервные поля используются для сохранения симметрии со службами и протоколами OSI ACSE/Presentation.

9.3.5 Структура PDU P-DATA-TF

PDU P-DATA-TF состоит из последовательности обязательных полей фиксированной длины, за которыми следует поле переменной длины. Таблица 9-22 показывает последовательность обязательных полей.

Переменное поле данных должно содержать один или несколько элементов Presentation-Data-Value.

Таблица 9-22. Поля PDU P-DATA-TF

Байты PDU	Имя поля	Описание поля
1	PDU-type	04H
2	Reserved	Данное резервное поле должно передаваться со значением 00H, но не должно проверяться на это значение при получении.
3-6	PDU-length	Значение PDU-length должно быть равно количеству байтов от первого байта следующего поля до последнего байта переменного поля. Оно должно кодироваться как беззнаковое двоичное число.
7-xxx	Presentation-data-value Item(s)	Это переменное поле данных должно содержать один или несколько элементов Presentation-data-value. Полное описание использования этого поля см. в Разделе 9.3.5.1

9.3.5.1 Структура элемента значения данных представления

Элемент значения данных представления состоит из последовательности обязательных полей фиксированной длины, за которыми следует одно поле переменной длины. Таблица 9-23 показывает последовательность полей.

Переменное поле должно состоять из одного Presentation-Data-Value.

Таблица 9-23. Поля элемента Presentation-Data-Value

Байты элемента	Имя поля	Описание поля
1-4	Item-length	Значение Item-length должно быть равно количеству байтов от первого байта следующего поля до последнего байта поля Presentation-data-value. Оно должно кодироваться как беззнаковое двоичное число.
5	Presentation-context-ID	Значения Presentation-context-ID должны быть нечётными целыми числами от 1 до 255, кодируемыми как беззнаковое двоичное число. Полное описание использования этого поля см. в Разделе 7.1.1.13.
6-xxx	Presentation-data-value	Поле Presentation-data-value должно содержать информацию сообщений DICOM (команды и/или набор данных) с заголовком управления сообщениями. Полное описание использования этого поля см. в Приложении E.

9.3.6 Структура PDU A-RELEASE-RQ

PDU A-RELEASE-RQ состоит из последовательности обязательных полей. Таблица 9-24 показывает последовательность полей.

Таблица 9-24. Поля PDU A-RELEASE-RQ

Байты PDU	Имя поля	Описание поля
1	PDU-type	05H
2	Reserved	Данное резервное поле должно передаваться со значением 00H, но не должно проверяться на это значение при получении.
3-6	PDU-length	Значение PDU-length должно быть равно количеству байтов от первого байта следующего поля до последнего байта поля Reserved. В случае данной PDU оно должно иметь фиксированное значение 00000004H, кодируемое как беззнаковое двоичное число.
7-10	Reserved	Данное резервное поле должно передаваться со значением 00000000H, но не должно проверяться на это значение при получении.

9.3.7 Структура PDU A-RELEASE-RP

PDU A-RELEASE-RP состоит из последовательности обязательных полей. Таблица 9-25 показывает последовательность полей.

Таблица 9-25. Поля PDU A-RELEASE-RP

Байты PDU	Имя поля	Описание поля
1	PDU-type	06H
2	Reserved	Данное резервное поле должно передаваться со значением 00H, но не должно проверяться на это значение при получении.
3-6	PDU-length	Значение PDU-length должно быть равно количеству байтов от первого байта следующего поля до последнего байта поля Reserved. В случае данной PDU оно должно иметь фиксированное значение 00000004H, кодируемое как беззнаковое двоичное число.
7-10	Reserved	Данное резервное поле должно передаваться со значением 00000000H, но не должно проверяться на это значение при получении.

9.3.8 Структура PDU A-ABORT

PDU A-ABORT состоит из последовательности обязательных полей. Таблица 9-26 показывает последовательность полей.

PDU A-ABORT должна поддерживать как службу A-ABORT (инициированную пользователем), так и службу A-P-ABORT (инициированную поставщиком).

Таблица 9-26. Поля PDU A-ABORT

Байты PDU	Имя поля	Описание поля
1	PDU-type	07H
2	Reserved	Данное резервное поле должно передаваться со значением 00H, но не должно проверяться на это значение при получении.
3-6	PDU-length	Значение PDU-length должно быть равно количеству байтов от первого байта следующего поля до последнего байта поля Reserved. В случае данной PDU оно должно иметь фиксированное значение 00000004H, кодируемое как беззнаковое двоичное число.
7	Reserved	Данное резервное поле должно передаваться со значением 00H, но не должно проверяться на это значение при получении.
8	Reserved	Данное резервное поле должно передаваться со значением 00H, но не должно проверяться на это значение при получении.
9	Source	Поле Source должно содержать целочисленное значение, кодируемое как беззнаковое двоичное число. Должно использоваться одно из следующих значений: 0 — пользователь службы DICOM UL (инициированное прерывание) 1 — зарезервировано 2 — поставщик службы DICOM UL (инициированное прерывание)
10	Reason/Diag.	Это поле должно содержать целочисленное значение, кодируемое как беззнаковое двоичное число. Если поле Source имеет значение (2) «поставщик службы DICOM UL», должно использоваться одно из следующих значений: 0 — причина не указана; 1 — нераспознанная PDU 2 — непредвиденная PDU 3 — зарезервировано 4 — нераспознанный параметр PDU 5 — непредвиденный параметр PDU 6 — недопустимое значение параметра PDU Если поле Source имеет значение (0) «пользователь службы DICOM UL», это поле причины не должно быть значимым. Оно должно передаваться со значением 00H, но не должно проверяться на это значение при получении. Примечание Резервные поля используются для сохранения симметрии со службами и протоколом OSI ACSE/Presentation.

10 Соответствие

10.1 Требования к соответствию

10.1.1 Аннулировано

10.1.2 Поддержка сетевого взаимодействия TCP/IP

Реализация, заявляющая о соответствии поддержке сетевого взаимодействия DICOM TCP/IP, должна:

Соответствовать требованиям протокола верхних уровней DICOM, определённым в Разделе 9.
Использовать зарегистрированные имена контекстов приложения, имена абстрактных синтаксисов и имена трансферных синтаксисов, как определено для идентификаторов объектов OSI (ISO 8824 и ISO 9834-1).

Примечание

Приложение F определяет кодирование протокола верхнего уровня DICOM для имён контекстов приложения, имён абстрактных синтаксисов и имён трансферных синтаксисов. Кодирование, определённое ISO 8825, не используется.
Использовать один из опубликованных и утверждённых RFC, определяющих работу TCP/IP поверх конкретных физических сетей.

10.2 Заявление о соответствии

Реализация, заявляющая о соответствии DICOM для поддержки взаимодействия в сетевой среде, должна указать «Поддержка сетевого взаимодействия DICOM V3.0 TCP/IP» со списком физических сетей и соответствующей релевантной информацией о реализации. Это подразумевает выполнение требований соответствия, определённых в Разделе 10.1.2.

A Имена контекстов приложения (Информативное)

A.1 Определение контекста приложения

Контекст приложения явно определяет набор элементов служб приложения, связанные с ними параметры и любую другую информацию, необходимую для совместной работы прикладных сущностей в рамках ассоциации. Использование контекста приложения определено в PS3.7.

Две прикладные сущности при установлении ассоциации согласовывают контекст приложения. Инициатор запроса ассоциации предлагает имя контекста приложения, а акцептор возвращает либо то же, либо другое имя контекста приложения. Возвращённое имя указывает контекст приложения, используемый для данной ассоциации. Предложение альтернативного контекста приложения акцептором обеспечивает механизм ограниченного согласования. Если инициатор запроса не может работать в контексте приложения акцептора, он выдаёт примитив запроса A-Abort. Такое согласование способствует внедрению будущих версий прикладной сущности DICOM.

A.2 Кодирование и регистрация имён контекстов приложения DICOM

Структура имени контекста приложения основана на идентификации объектов OSI (числовая форма), определённой ISO 8824. Имена контекстов приложения являются зарегистрированными значениями, как определено ISO 9834-1, для обеспечения глобальной уникальности. Они кодируются, как определено в Приложении F, при использовании поддержки сетевого взаимодействия TCP/IP, определённой в Разделе 9.

A.2.1 Зарегистрированные имена контекстов приложения DICOM

Организация, ответственная за определение и регистрацию имён контекстов приложения DICOM, — NEMA. NEMA гарантирует уникальность всех имён контекстов приложения DICOM. Выбор зарегистрированных имён контекстов приложения DICOM, относящихся к прикладным сущностям DICOM, а также связанные с ними правила согласования, определены в PS3.7.

B Абстрактные и трансферные синтаксисы (Информативное)

B.1 Определение абстрактного синтаксиса

Абстрактный синтаксис — это спецификация элементов данных прикладного уровня с ассоциированной семантикой или управляющей информации протокола прикладного уровня с использованием правил нотации, не зависящих от техники кодирования, применяемой для их представления.

Примечание

В частности, он позволяет взаимодействующим прикладным сущностям согласовать согласованный набор элементов данных DICOM (например, из определённой версии Словаря данных) и/или определения классов информационных объектов.

B.2 Определение трансферного синтаксиса

Трансферный синтаксис — это набор правил кодирования, позволяющих однозначно представить элементы данных, определённые одним или несколькими абстрактными синтаксисами. В частности, согласование трансферных синтаксисов позволяет взаимодействующим прикладным сущностям договориться о техниках кодирования, которые они способны поддерживать (например, порядок байтов, сжатие и т. д.).

B.3 Кодирование и регистрация имён абстрактных и трансферных синтаксисов DICOM

Структура имён абстрактных и трансферных синтаксисов основана на идентификации объектов OSI (числовая форма), определённой ISO 8824. Имена абстрактных и трансферных синтаксисов являются зарегистрированными значениями, как определено ISO 9834-1, для обеспечения глобальной уникальности. Имена абстрактных и трансферных синтаксисов кодируются, как определено ISO 8825 (идентификаторы объектов в числовой форме), при использовании поддержки сетевого взаимодействия OSI, определённой в Разделе 8. Они кодируются, как определено в Приложении F, при использовании поддержки сетевого взаимодействия TCP/IP, определённой в Разделе 9.

B.3.1 Зарегистрированные имена абстрактных и трансферных синтаксисов DICOM

Организация, ответственная за определение и регистрацию имён абстрактных и трансферных синтаксисов DICOM, — NEMA. NEMA гарантирует уникальность всех имён абстрактных и трансферных синтаксисов DICOM. Выбор зарегистрированных имён абстрактных и трансферных синтаксисов DICOM, относящихся к определённой версии прикладных сущностей DICOM, а также связанные с ними правила согласования, определены в PS3.4 для абстрактных синтаксисов и PS3.5 для трансферных синтаксисов.

B.3.2 Частным образом определённые имена абстрактных и трансферных синтаксисов

Могут также использоваться частным образом определённые имена абстрактных и трансферных синтаксисов, однако они не будут регистрироваться NEMA. Организации, определяющие частные имена абстрактных и трансферных синтаксисов, несут ответственность за получение надлежащей регистрации, определённой для идентификаторов объектов OSI. Национальные организации по стандартизации, представляющие ряд стран (например, Великобритания, Франция, Германия, Япония, США и т. д.) в Международной организации по стандартизации, действуют как регистрационный орган, определённый ISO 9834-1.

Примечание

Например, в США ANSI присваивает (за плату) идентификаторы организаций любой запрашивающей организации. Этот идентификатор состоит из серии из четырёх числовых компонентов: 1 (идентифицирует ISO), 2 (идентифицирует ветвь органов-членов ISO), 840 (идентифицирует ANSI как орган-член ISO, представляющий США) и xxxxxx (идентифицирует конкретную организацию и выдаётся ANSI). Такой идентификатор может использоваться идентифицированной организацией в качестве корня, к которому она может добавить суффикс, состоящий из одного или нескольких числовых компонентов. Идентифицированная организация принимает на себя ответственность за надлежащую регистрацию этих суффиксов для обеспечения уникальности.

C Адресация DICOM (Нормативное)

C.1 Заголовки прикладных сущностей DICOM

Заголовок прикладной сущности DICOM (DICOM Application Entity Title) однозначно идентифицирует службу или приложение в конкретной системе в сети. Заголовки прикладных сущностей не зависят от сетевой топологии, поэтому устройство может быть физически перемещено, при этом соответствующий заголовок прикладной сущности может остаться прежним. См. PS3.5 для информации о кодировании заголовков прикладных сущностей DICOM.

Примечание

Заголовок прикладной сущности DICOM в стандарте ACR-NEMA назывался логическим адресом (Logical Address).

Заголовки прикладных сущностей DICOM используются в трёх случаях взаимодействия:

для идентификации вызываемой/вызывающей прикладных сущностей. Они используются для установления ассоциации и для обеспечения того, что ассоциация устанавливается с ожидаемым приложением.
для идентификации инициатора и предполагаемого получателя служб извлечения DICOM (DICOM Retrieve Services, см. PS3.4). Они передаются в DICOM-командах с сообщениями служб DIMSE C-MOVE и C-STORE, обмениваемыми по установленной ассоциации.
для идентификации расположения SCP службы извлечения для одного или нескольких экземпляров SOP (SOP Instances). Они передаются в наборах данных DICOM (DICOM DataSets) различных служб.

C.2 Правила использования именования и адресации

Заголовки прикладных сущностей DICOM используются в полях заголовков вызываемой/вызывающей прикладных сущностей службы верхнего уровня, в элементах данных заголовка прикладной сущности получателя перемещения (Move Destination) и инициатора перемещения (Move Originator) в наборе команд DICOM-сообщения, а также в различных атрибутах набора данных DICOM-сообщения.

Примечание

С одним заголовком прикладной сущности может быть связано несколько сетевых адресов, назначенных одной системе (например, хост с несколькими сетевыми интерфейсами).
С одним заголовком прикладной сущности может быть связано несколько TCP-портов с использованием одинаковых или различных IP-адресов.
Одиночная точка сетевого доступа (IP-адрес и TCP-порт) может поддерживать несколько заголовков прикладных сущностей.

Система DICOM в сети может поддерживать несколько процессов приложений, идентифицируемых различными заголовками прикладных сущностей DICOM.

При получении запроса ассоциации заголовок вызываемой прикладной сущности должен проверяться, чтобы ассоциация могла быть отклонена, если соответствующее локальное приложение не существует.

D Использование и формат параметра пользовательской информации A-ASSOCIATE (Нормативное)

Этот параметр обеспечивает согласование ряда функций, связанных с взаимодействием прикладных сущностей DICOM при установлении ассоциации.

D.1 Согласование максимальной длины

Данное согласование позволяет получателям ограничить размер параметров списка значений данных представления (Presentation Data Values List) в каждом подтверждении P-DATA. Инициатор запроса ассоциации должен указать в параметре пользовательской информации примитива запроса A-ASSOCIATE максимальную длину в байтах для параметра списка PDV, который он готов получать в каждом подтверждении P-DATA. Акцептор ассоциации должен обеспечивать при фрагментации DICOM-сообщений, чтобы список PDV, включённый в каждый запрос P-DATA, не превышал эту максимальную длину. Аналогично, акцептор ассоциации может указать в параметре пользовательской информации примитива ответа A-ASSOCIATE максимальную длину в байтах для параметра списка PDV, который он готов получать в каждом подтверждении P-DATA. Инициатор запроса ассоциации должен обеспечивать при фрагментации DICOM-сообщений, чтобы список PDV, включённый в каждый запрос P-DATA, не превышал эту максимальную длину. Различные максимальные длины могут быть указаны для каждого направления потока данных по ассоциации.

Поддержка элемента максимальной длины (Maximum Length Item) обязательна для всех реализаций, заявляющих о соответствии DICOM V3.0.

D.1.1 Структура подэлемента максимальной длины (A-ASSOCIATE-RQ)

Подэлемент максимальной длины (Maximum Length Sub-Item) должен состоять из последовательности обязательных полей фиксированной длины. В пользовательских данных (User Data) в A-ASSOCIATE-RQ должен присутствовать только один подэлемент максимальной длины. Таблица D.1-1 показывает последовательность обязательных полей.

Таблица D.1-1. Поля подэлемента максимальной длины (A-ASSOCIATE-RQ)

Байты элемента	Имя поля	Описание поля
1	Item-type	51H
2	Reserved	Данное резервное поле должно передаваться со значением 00H, но не должно проверяться на это значение при получении.
3-4	Item-length	Эта длина элемента (Item-length) должна равняться количеству байтов от первого байта следующего поля до последнего байта поля Maximum-length-received. Для данного элемента она должна иметь фиксированное значение 00000004H, закодированное как беззнаковое двоичное число.
5-8	Maximum-length-received	Этот параметр позволяет инициатору запроса ассоциации ограничить максимальную длину переменного поля PDU P-DATA-TF, отправляемых акцептором по установленной ассоциации. Это значение длины указывается как количество байтов, закодированное как беззнаковое двоичное число. Значение (0) указывает, что максимальная длина не задана. Это значение максимальной длины никогда не должно превышаться значениями длины PDU, используемыми в поле PDU-length PDU P-DATA-TF, получаемых инициатором запроса ассоциации. В противном случае это является ошибкой протокола.

D.1.2 Структура подэлемента максимальной длины (A-ASSOCIATE-AC)

Подэлемент максимальной длины (Maximum Length Sub-Item) должен состоять из последовательности обязательных полей фиксированной длины. В пользовательских данных (User Data) в A-ASSOCIATE-AC должен присутствовать только один подэлемент максимальной длины. Таблица D.1-2 показывает последовательность обязательных полей.

Таблица D.1-2. Поля подэлемента максимальной длины (A-ASSOCIATE-AC)

Байты элемента	Имя поля	Описание поля
1	Item-type	51H
2	Reserved	Данное резервное поле должно передаваться со значением 00H, но не должно проверяться на это значение при получении.
3-4	Item-length	Эта длина элемента (Item-length) должна равняться количеству байтов от первого байта следующего поля до последнего байта поля Maximum-length-received. Для данного элемента она должна иметь фиксированное значение 00000004H, закодированное как беззнаковое двоичное число.
5-8	Maximum-length-received	Этот параметр позволяет акцептору ассоциации ограничить максимальную длину переменного поля PDU P-DATA-TF, отправляемых инициатором запроса по установленной ассоциации. Это значение длины указывается как количество байтов, закодированное как беззнаковое двоичное число. Значение (0) указывает, что максимальная длина не задана. Это значение максимальной длины никогда не должно превышаться значениями длины PDU, используемыми в поле PDU-length PDU P-DATA-TF, получаемых акцептором ассоциации. В противном случае это является ошибкой протокола.

D.2 Расширенное согласование пользовательской информации

Параметр пользовательской информации примитива A-ASSOCIATE может быть расширен для поддержки потребностей согласования прикладных сущностей DICOM, использующих службу UL. Это приведёт к определению специфических подэлементов пользовательской информации. Этим подэлементам должны быть назначены уникальные значения типа элемента (item-type), зарегистрированные в PS3.7.

Примечание

Значения типов подэлементов (Sub-Items) в поле пользовательской информации назначаются настоящим Стандартом в диапазоне от 51H до FFH. Значения подэлементов определяются в PS3.7 и PS3.8.
Последующие редакции Стандарта могут определять дополнительные подэлементы пользовательской информации таким образом, который не влияет на семантику ранее определённых подэлементов. От акцепторов ассоциации, соответствующих более ранней редакции Стандарта, требуется игнорировать такие нераспознанные подэлементы пользовательской информации и не отклонять ассоциацию из-за их наличия.

E Использование службы P-DATA прикладной сущностью DICOM (Нормативное)

Это приложение определяет, как DICOM-сообщения инкапсулируются в службу P-DATA прикладной сущностью DICOM.

E.1 Правила инкапсуляции

DICOM-сообщения инкапсулируются в примитивы запроса P-DATA как пользовательские данные значений данных представления (Presentation Data Values, PDV). DICOM-сообщение фрагментируется на командные фрагменты (Command Fragments) и информационные фрагменты (Data Fragments), каждый из которых помещается в PDV. Для каждого фрагмента одного и того же сообщения должен использоваться один и тот же контекст представления (т. е. один и тот же идентификатор контекста представления (Presentation Context ID) для пользовательских данных PDV, содержащих фрагменты одного и того же сообщения). Параметр пользовательских данных PDV должен содержать один и только один фрагмент (командный или информационный), перед которым находится заголовок управления сообщением. Этот заголовок будет указывать:

является ли фрагмент командным (Command) или информационным (Data) типом
является ли фрагмент последним фрагментом потока команд/данных (Command/Data Stream) DICOM-сообщения или нет

Параметр списка PDV (PDV List) запроса P-DATA должен содержать один или несколько таких PDV (заголовок управления сообщением и полный фрагмент сообщения). Каждый PDV полностью содержится в данном примитиве запроса P-DATA и не распределяется по нескольким примитивам запроса P-DATA. PDV, содержащиеся в примитиве запроса P-DATA, должны относиться к одному и тому же DICOM-сообщению. Каждый фрагмент сообщения должен состоять из чётного числа байтов.

Примечание

Выравнивание не требуется, так как PS3.5 определяет сообщения на границе чётного байта.
Вышеприведённые правила гласят, что каждый фрагмент, содержащийся в PDV, должен состоять только из чётного числа байтов. Поэтому кодирование таких элементов, как номер группы (Group Number), номер элемента (Element Number), длина значения (Value Length) и т. д. (как определено прикладной сущностью DICOM, см. PS3.5), не гарантируется в пределах одного и того же PDV.

Фрагментация любого сообщения приводит к серии PDV, которые должны быть отправлены по данной ассоциации соответствующей серией запросов P-DATA с сохранением порядка следования фрагментов любого сообщения. Кроме того, никакие фрагменты другого сообщения не должны отправляться до тех пор, пока не будут отправлены все фрагменты текущего сообщения (т. е. чередование фрагментов из разных сообщений не допускается).

Настоятельно рекомендуется, чтобы два последовательных PDV в одном и том же примитиве запроса P-DATA (следовательно, содержащие фрагменты одного и того же сообщения с использованием одного и того же идентификатора контекста представления) не содержали два заголовка управления сообщением одного и того же типа (командный или информационный). Они должны быть объединены отправителем в один PDV. Однако получатели должны быть способны принимать и обрабатывать такие PDV.

Примечание

Вышеприведённые правила позволяют отправку в одном запросе/подтверждении P-DATA командного фрагмента в первом PDV (с установленным флагом последнего фрагмента) с последующим информационным фрагментом во втором PDV (с установленным или не установленным флагом последнего фрагмента). В частности, если согласованная максимальная длина для параметра списка PDV запроса P-DATA достаточна для размещения полного сообщения, для обмена целым сообщением может использоваться один запрос P-DATA.

Отдельные PDV не должны отправляться с полями Presentation-data-value, состоящими только из одного байта, содержащего заголовок управления сообщением, но без какого-либо другого содержимого во фрагменте. Они должны быть объединены отправителем с предшествующими или последующими PDV.

Примечание

Несмотря на то, что вышеприведённые правила запрещают отправку «пустого» PDV (например, с установленным флагом последнего фрагмента), рекомендуется, чтобы получатели могли принимать и обрабатывать такие PDV.

E.2 Кодирование заголовка управления сообщением

Заголовок управления сообщением (Message Control Header) располагается перед каждым фрагментом DICOM-сообщения (см. Рисунок E.2-1). Его наличие обязательно для всех абстрактных синтаксисов DICOM (см. Приложение B для дополнительного обсуждения абстрактных синтаксисов).

Заголовок управления сообщением должен состоять из одного байта, младший значащий бит (бит 0) которого принимает одно из следующих значений:

Если бит 0 установлен в 1, следующий фрагмент должен содержать командную информацию сообщения (Message Command).
Если бит 0 установлен в 0, следующий фрагмент должен содержать информацию набора данных сообщения (Message Data Set).

Следующий младший значащий бит (бит 1) должен определяться следующими правилами:

Если бит 1 установлен в 1, следующий фрагмент должен содержать последний фрагмент набора данных сообщения (Message Data Set) или командной части сообщения (Message Command).
Если бит 1 установлен в 0, следующий фрагмент не содержит последний фрагмент набора данных сообщения (Message Data Set) или командной части сообщения (Message Command).

Биты со 2-го по 7-й всегда устанавливаются в 0 отправителем и никогда не проверяются получателем.

Примечание

Заголовок управления сообщением в потоке транспортных данных является первым байтом каждого PDV. Трансферный синтаксис, согласованный при установлении ассоциации, определяет кодирование командного/информационного фрагмента (Command/Data).

Presentation Data Value and the Message Control Header

Рисунок E.2-1. Значение данных представления и заголовок управления сообщением

F Правила кодирования UL DICOM для контекстов приложения, абстрактных синтаксисов и трансферных синтаксисов (Нормативное)

F.1 Правила кодирования

Имена контекстов приложения (Application Context Names), имена абстрактных синтаксисов (Abstract Syntax Names), имена трансферных синтаксисов (Transfer Syntax Names) и UID классов служб (Service Class UIDs) являются идентификаторами объектов OSI в числовой форме, как определено ISO 8824. Кодирование этих имён в протоколе UL DICOM указано в данном приложении.

Каждый компонент имени или UID кодируется как строка цифр в кодировке ISO 646:1990-Basic G0 Set (символы 0-9). Ведущие нули каждого компонента не являются значащими и не должны отправляться. Компоненты не должны дополняться. Компоненты должны разделяться символом «.» (2EH). «Пустые» компоненты (без числового значения между двумя разделителями) не допускаются. Компоненты со значением ноль (0) должны кодироваться как (nnn.0.ppp). Ни разделитель, ни дополнение не должны присутствовать перед первой цифрой первого компонента или после последней цифры последнего компонента.

Примечание

Строка «1.2.840.123456.0.21.4», закодированная как строка символов в кодировке ISO 646:1990-Basic G0 Set, передаёт следующий UID или имя со следующей последовательностью компонентов идентификатора объекта: { (1), (2), (840), (123456), (0), (21), (4) }.
Вышеприведённые правила были приняты для упрощения выполнения сравнения UID.

Имена контекстов приложения DICOM (корень плюс суффикс) не должны превышать 64 символов всего (цифры и разделители между компонентами).

Имена абстрактных и трансферных синтаксисов DICOM (корень плюс суффикс) не должны превышать 64 символов всего (цифры и разделители между компонентами).

G Обзор концепций уровней и служб OSI (Информативное)

В многоуровневой модели взаимодействия, такой как эталонная модель из 7 уровней OSI, каждый уровень использует службу, предоставляемую уровнем, находящимся непосредственно ниже. Работа уровня протокола поверх службы нижнего уровня предоставляет новую службу уровню выше. Служба является «связующим звеном» между уровнями протоколов.

Службы описывают результирующие эффекты работы протокола без необходимости знания детальных спецификаций самого протокола. Протокол определяет горизонтальный диалог между двумя вычислительными системами через сеть, в то время как служба описывает вертикальные отношения внутри системы. См. Рисунок G-1.

Рисунок G-1. Отношение служб к протоколу

Служба верхнего уровня OSI описывается рядом примитивов службы. Каждый из них моделирует одно из функциональных взаимодействий между пользователем службы на уровне выше и поставщиком службы. В контексте настоящего Стандарта пользователь службы называется элементом службы приложения DICOM (DICOM Application Service Element). Поставщик службы называется верхним уровнем (Upper Layer) и выполняет протокол верхнего уровня (Upper Layer Protocol).

Примечание

Службы UL OSI, определённые в настоящем Стандарте, предоставляются протоколом верхнего уровня DICOM для TCP/IP (Раздел 9).

Эти примитивы службы пересекают границу уровня в так называемой точке доступа к службе (Service Access Point, SAP). В большинстве случаев существует прямая связь между примитивами службы в двух прикладных сущностях (AE). Это отражено в названиях этих примитивов:

Примитив запроса (request) в системе A вызывает примитив подтверждения (indication) в системе B.
Если примитив подтверждения (indication) в системе B требует ответа, в точке доступа к службе (SAP) в системе B может быть выдан примитив ответа (response). Этот примитив ответа вызовет примитив подтверждения (confirmation) в системе A.

Различные типы примитивов службы и их взаимосвязь показаны на Рисунке G-2. Пунктирные линии представляют обмен блоков данных протокола (Protocol Data Units), которые инициируются примитивами запроса/ответа или генерируют примитивы подтверждения.

Рисунок G-2. Соглашения описания службы

H Индекс типов элементов и PDU (Информативное)

Утратило силу.