正如DICOM标准本身的命名那样,DICOM标准要解决的一个主要总是就是网络传输,也就是在各种各样的网络硬件和软件的环境下如何能够实现医学图像可靠地高效地传送到期望的目的计算机中为此,DICXOM标准采取的策略是在成熟的标准化的网络环境基础上增加对医学图像的支持而不是从最低层开始定义这样就可以直接利用现有的网络硬件和软件资源促进DICOM标准的开发和应用。
一、DICOM网络的层次模型
在DICOM标准的制定中主要彩了在实际中广泛使用的协议和影响较大R OSI网络协议作为对DICOM网络支持的基础在这两个协议之上分别定义了DICOM自己的基于消息的信息交换的上层协议DIMSE。为保持与以前版本的兼容仍保留了对点对点打印的支持。
在这个模型中,圆角框部分是DICOM标准中所定义的部分虚线框表示具体的应用程序由用户根据需求自行定义。方框部分则是在其它标准中所定义的,DICOM标准只不过直接使用。
应用程序与DICOM应用实体之间的应用程序接口(API)并不是在DICOM标准中说明而决定于实现一般这个API提供了对其它应用的连接构造和处理SOP实例并传送到远方应用等这类函数。
对应用层对应用褓提供了两组服务联系控制协议(ACSE)和DICOM消息协议(DIMSE),它们都必须对DICOM实现有效。ACSE是一个标准的OSI协议。DIMSE的DICOM服务,是应用实体中提供的服务的一部分。
在ACSE和DIMSE应用之间的接口是DICOM标准中说明的DICOM接口这个说明描述了对ACSE和DIMSE请求的每一个功能所要求的每一个叁数,是DICOM应用上下文的一部分。
TCP/IP栈和OSI应用服务扩展的组合广泛地应用在通过网络来实现DICOM。由于TCP/IP没有定义高层,DICOM所要求的应用表现和会话层功能在DICOM标准中组合为一个层称为DICOM高层或DUL。
DUL对TCP/IP协议栈使用了相同的DICOM接口,在低层DUL具有与TCP层的接口,在应用实体之间的DICOM联系映射到一个TCP连接表现地址映射到一个TCP端口号,与IP号或主机名相结合。这个IP号和TCP端口的组合称套接地址在网络中这个组合是唯一的。
在DICOM3.0版本中点对点环境是为保持与以前版本的兼容而保留的。
二、工作过程
对于一次DICOM的通信,具体过程为:
应用程序通过API发出DICOM功能服务要求
DICOM服务器构造应用实体将API参数放入应用实体上下文
应用实体根据上下文功能要求调用对应的DICOM上层服务功能
DICOM上层服务将相关参数组成TCP包传递给TCP SOCKET
操作系统的TCP/IP服务通过物理网络将数据传送到目标计算机
目标计算机在接收到信息后回送应答信息。
上面的通信过程只是一个非常示意性的概要说明,由于在网络中会出现的情况非常复杂实际的通信联络的过程和内容是繁琐而具体的,举个最简单的例子,我们在上一讲中介绍过传输语法它规定了传送内容的编码方式字节发送的次序、图像的封装形式等等在两台计算机网络中称主机之间进行DICOM通信时,DICOM需要就传输语法进行协商,首先由通信的请示方使用默认的传输语法给出自己可以用的传输语法清单由对方选择,通信的另一方则根据自身的硬件和操作系统等软件情况选择合适的舆语法,并回答对方。这样就确定了在其后通信中所采用的传输语法。
传输语法的协商只是DICOM网络通信中的一小部分,还有很多其它方面内容必须在通信的联系过程中确定具体可以查阅标准。
三、数据结构
在DICOM的各个网络层次上,使用了多种数据结构,下面介绍主要的两个数据结构。
1。消息
在DICOM的网络接口中信息是通过DICOM消息通信的。一个消息是由命令集与后面有条件的数据集复合而成的。命令集用来指明待完成的在数据集上的操作和通告。
命令集由若干个命令元素构成,命令元素包含有DIMSE协议指定主义的命令集中每个独立域中的编码值。每个命令元素由一个显示标记、值长度和值域复合而成数据集我们已经在第二讲中介绍过。
2。协议数据单元
协议数据单元(PDUS)是在对等实体间交换的信息格式,它用于将DICOM消息经DIMSE协议发送到对方。一个PDU将由协议控制信息和用户数据组成。PDUS由强制固定字段构成可选值字段包含一个或多个条目或子条目。DICOM UL 协议由P-DATA-TF PDU、A-ASSO-CIATION-RQ PDU、A-RELEASE-RQPDU、A-ABORT PDU等七种协议数据单元PDUs组成。
四、DIMSE联系协议
与其它通信协议一样,DICOM也使用了对等的观点是指通信双方的操作是在同一个层次上进行,例如,在说明数据链路层的操作,就认为发送的数据是传送到对方的数据链路层,对方的回应信息也来自数据链路层,而不考虑接收方数据链路层再向上层的信息交换。
两个应用实体之间的用于信息交换的连接称为联系。对一个联系,许多通信内容都是作为上下文被确定的,其中的内容可以发生变化,这种变化实际上体现了信息的交换。在DICOM标准中定义了这个上下文(称应用上下文),双方必须根据这个上下文的定义协调动作。
一个应用上下文用UID标识,并在联系初始化中传递到对方。通过比较应用上下文的UID,对方能够决定是否能够处理这个联系的请求。它可以为联系接受建立或拒绝它。
一个应用上下文覆盖了信息交换的全局功能。通过联系,哪一种类的信息交换能够发生是由SOP类和这些SOP类的服务类定义。联系的启动方建议的SOP将使用的类型、每个SOP类的SCU/SCP(服务类用户。服务类提供者)角色和信息的表示方式,取决于另一方的能力,它可以接受或拒绝每一个单独的SOP类。
经过这个协商过程,双方都知道对方的能力和限制。实际的信息交换能够根据服务类和SOP类角色(为这些类定义的)进行。当联系不再需要时,联系被终止。
在联系的初始化过程中,协商的每一个SOP类,必须在两个进程之间达成协议,涉及到两个进程之间使用的舆语法。启动方建议所有的特定SOP类能够处理的传输语法,另一方选择其中一个传输语法。经过协商双方SOP类都接受的表现上下文被确定。
一个表现层上下文通过双方都同意的数标识,称表现上下文ID。在一个联系的上下文中可能存在许多表现上下评语肺病下文ID标识了发生信息交换的SOP类。
以上联系中的信息都是封装在PDU中经过TCP/IP及物理层传送到对方的。
|