A Free Trial That Lets You Build Big!
Start building with 50+ products and up to 12 months usage for Elastic Compute Service
Over the past year has been insisting on the weekend to write blog, finishing work and spare time of the drip. For new knowledge points and new technologies will be written separately, for DICOM-related knowledge in the dicom medical image Processing column, in fact, dicom English full name is Digital Imaging and Communications in Medicine, which is medical digital imaging and communication. This indicates that the DICOM standard should at least be divided into two parts: image processing and network communication. I've also discussed the column names before, in short, because of historical reasons and self-laziness has not taken the effort to open a column, for the moment. Although no re-opening column, but in order to facilitate the classification of the review, in the 2015 New Year I will follow the title prefix to a simple classification of categories: related to image processing, such as compression/decompression, field additions and deletions, image data processing, column blog title continues to the original dicom medical image processing: as a prefix, and replace the prefix with a more concise dicom, related to the DICOM network transport :.
Previously, blog post specifically combed through the DICOM standard for network-related content (see:dicom Medical Image processing: A comprehensive analysis of communication service modules in the DICOM3.0 standard ,dicom medical image processing: DICOM network transmission ), In the recent reorganization of fo-dicom developed PACS-related test cases, the fo-dicom and mdcm two libraries were again compared, at the same time re-read the DICOM3.0 standard part of the chapter, found that previously overlooked many of the details, especially written this article. To add to the previous series of negligence and bug fixes, and deepen the understanding of DICOM network transmission.
PS: DICOM medical image processing every article in the column before the written, I do my best to review, translation of relevant information, writing, debugging local samples, in order to the high quality of the article, but after all, personal time and energy constraints, there will inevitably be flaws in the blog, recommended to read when possible to browse the topic of the latest blog post, Because there are often blog post errors. In addition, if you find a question welcome message or mail exchange.
The 7th part of the DICOM3.0 standard, titled "Message Exchange", shows from the title that part 7th focuses on the network transport portion of the DICOM protocol. The official introduction to this section is as follows:
This is the DICOM standard specifies the dicom Message Service Element (DIMSE) . The DIMSE defines an application service Element (both the service and protocol) used by peer DICOM APPL Ication entities for the purpose of exchanging medical images and related information.
The DIMSE provides its services is relying on the Dimse protocol. The DIMSE protocol defines the encoding rules necessary to construct Messages. A Message is composed of a Command set (defined in this part of the DICOM standard) followed by a conditional Data Set (DE Fined in PS 3.5).
According to the previous DICOM medical image processing: A comprehensive analysis of the DICOM3.0 standard in the Communication Services Module described in the Dimse classified asPresentation LayerTo indicate the underlying services provided in the DICOM protocol, that is, the provisions of the DIMSE protocolService Primitives(Service Primitives), which communicates services between the peer Dicom application entity (application entity). As shown in the following:
Here the so-called Dicom application Entity, fromactualWe see in real life a variety of software or applications that use DICOM standards, or devices that install this software or application;Concept, the 3rd part of the DICOM3.0 standard (Information Object definitions), Part 4 (Service Class specifications), 5th (Data Structure and Encoding), the 6th part (Data Dictionary) together define the model.
The message in Dimse consists of a command and a dataset (data set), and the detailed structure is not covered here, and it is interesting to be able to scroll through the DICOM3.0 Standard part 7th section 6.3. Here we mainly introduce the services stipulated in the DIMSE agreement, in order to better understand the following, before reading please go to"Knowledge point Supplement"section, familiarize yourself with the concepts and understand the differences, especially the SCP (service class Provider) and Dimse-service-provider, SCU (service class User) and Dimse-service-user.
The DIMSE message service element supports interaction between peer Dimse-service-user, which plays invoking Dimse-service-user and performing on both sides of the Dimse-service-user respectively Dimse-service-user role. This is similar to the SCU and SCP we often refer to, one side triggering (invoking), one side responding (performing). Although the roles played by the two sides are different, the names contain the user, meaning that both parties are users of the DIMSE agreement, which is easily confused with the traditional SCU and SCP. Specific differences can be found in"Knowledge point Supplement"A section.
The two services offered by DIMSE are as follows:
The DIMSE service is based on the connection establishment, that is, the DIMSE layer below is the Dicom Upper layer protocol layer, the introduction of the Dicom Upper layer protocol in the DICOM3.0 standard in the 8th part.
DICOM3.0 the 8th section of the standard titled "Network Communication Support for Message Exchange", This section describes the common service (generic services) for communication (Communicaton) between DICOM application entities. This type of service is related to the session layer, presentation layer, and application layer in the OSI model, which is uniformly referred to as the UL service, which is a subset of the ACSE Service (Association Control Service Element) and the OSI Presentation Layer service. The DICOM standard 7th section, just mentioned above, details how to use the upper Layer service to complete the interaction between DICOM application entities.
UL Service upper layer services include A-associate, A-release, A-abort, A-p-abort, p-data five kinds, as shown:
For the various services in, DICOM3.0 part 8th gives a detailed definition, such as the various parameters that are used interactively between peer dicom entities. Here is a brief example of A-associate, as shown in:
Is the whole process of a-associate service, it can be clearer and more intuitive to see the difference between invoking dimse-service-user/performing Dimse-service-user and SCU/SCP concept, The left and right sides of the requestor and acceptor (both sides of the protocol stack upper layer N) are the users of the service, i.e. invoking Dimse-service-user and performing, relative to the middle (the lower N-1 in the protocol stack) Dimse-service-user. And if one side is the requester side (requestor) from a service implementation perspective, one side is the response End (acceptor), which is the most common SCU and SCP in Dicom.
Service is established and based on the agreement, DICOM Standard 8th part 9th Chapter emphatically introduced the DICOM UL Service use agreement. The UL protocol is based on the TCP/IP protocol, and the dicom upper body (i.e. DICOM UL entity) is calibrated by the system-specified port number in network interaction. Therefore, a TCP connection needs to be established during communication, and a TCP link should only support one and only one Dicom UL Association.DICOM Upper Layer State machine:
Similar to the traditional TCP connection, the Transport connect request primitive is emitted to the TCP Transport layer when the Dicom upper layer is to establish a link. Once the connection acknowledgement semantics for the TCP Transport layer is received, the A-ASSOCIATE-RQ PDU is sent on the established TCP connection.
After the connection is established, the transmission of PDUs over the TCP connection (the structure of the PDU is described in detail in the reference to DICOM3.0 standard part 8th, section 9.3) follows the Dicom upper layer protocol state machine , the dicom Upper layer . State machines (especially finite state machines) are an important tool in the field of software engineering, and many of the models used are state machines, such as the compilation of code, and the introduction of state machines in the "Compiling Principle" (finite), for example, in digital circuits (microcontroller/embedded development), Sequential logic design between various transactions and interrupts; Even the computers we use today are finite state machines as computational models and so on. Baidu Encyclopedia in the finite state machine Fsm,finite the following introduction:
In addition to modeling the reaction systems described here, finite state automata are important in many different fields, including electronic engineering, linguistics, computer science, philosophy, biology, mathematics, and logic. Finite state machine is a kind of automata which is researched in automata theory and computational theory. In computer science, finite state machines are widely used for modeling application behavior, hardware circuit system design, software engineering, compilers, network protocols, and computational and language research.
Dicom UL Service protocol is based on the TCP protocol, the TCP protocol is usually used a finite state machine with 11 states 11 States of the finite state machine to represent, in the DICOM3.0 standard 8th part 9.2 of the dicom Upper The Layer state machine uses 13 states to describe the entire process. There are 19 types of events associated with them, up to 28 actions can be triggered, and the entire State transfer table is quite complex, as shown in:
DICOM3.0 Standard gives is a two-dimensional state transfer table, look more tired, not intuitive, is my hand-painted state machine conversion diagram, because there is no handy UML modeling tools can only hand-painted, we will look at it.
The circles in the circle represent the various states of the Dicom Upper Layer protocol, and the lines with arrows are transitions between states, and the numbers on the arrow lines represent events that change the state of the trigger. Understand that should understand the entire DICOM communication set up the basic process, because the time relationship in this blog post the state diagram is not detailed, the following blog post will be fo-dicom, DCMTK as an example of the state diagram in detail the various states.
Before the column introduced the design structure of fo-dicom, here is a brief talk about the DICOM network communication Service base class is Dicomservice, as for the example explanation part, here first make a notice, the next post in detail.Knowledge Point Supplement: Protocol Protocol:
Protocol protocol: Here is the Protocol refers to the computer Domain network protocol (other non-related areas, such as trade, please do their own brain repair, I do not understand). A set of rules, standards, or conventions established by a protocol for data exchange in a computer network. Consists of three elements, namely semantics, syntax, and timing. The description of Baidu Encyclopedia is:
Service Primitive Services Primitive:
(1) Semantics. Semantics is the interpretation of the meaning of each part of the control information. It specifies what kind of control information needs to be emitted, as well as the actions performed and what responses are made.
(2) syntax. syntax is the structure and format of user data and control information, and the order in which the data appears.
(3) Timing. Timing is a detailed description of the order in which events occur. (also referred to as "Synchronization").
The three elements are depicted as: what the semantics mean to do, what the syntax means to do, and the order in which the timings are made.
Service primitives: The interface between the user and the protocol entity is actually a piece of program code, but it is indivisible. Communication between service users and service providers can be achieved through the service primitives. There are only four types of service primitives, namely request, indication (indication), response (Response), acknowledgment (Confirm).
Note: Unlike the Protocol, the service primitive is used for service providers and service users, and the protocol is used for communication between service users. The protocol is the rule that controls communication between peer entities and is horizontal. Service is the function that the lower layer provides to the upper level through the indirect port, which is vertical. The implementation of the Protocol ensures that services can be provided up to the next level, and the services provided below are required to implement this layer protocol.
"Note": to differentiate between invoking dimse-service-user/performing Dimse-service-user and service class Scu/service class The SCP will need to refer to the Protocol (PROTOCOL) and services (service) above. Taking the seven-layer protocol in the OSI open model as an example, the invoking Dimse-service-user/performing Dimse-service-user is named in terms of service and protocol, and the upper layer of the model is dependent on the model lower layer. The Dimse upper layer (dimse-service-user) on both sides of all peers in the peer entity is the user of the Dimse lower level (dimse-service-provider) service; service class Scu/service class SCP is from the perspective of realistic modeling, the two ends of the DICOM network communication peer are regarded as service users and service providers respectively.
State in state: status, State, is the operation of a system at some point in its life cycle, when the system performs some action, or waits for some external input.
events in a state machine: events, event, are things that occur in a certain time and space that are meaningful to the system.
action in a state machine: When an event is distributed by a state machine system, it responds to the event, and the response is completed at the moment by the relevant action.
DICOM:DICOM3.0 Network Communication Protocol (cont.)
Start building with 50+ products and up to 12 months usage for Elastic Compute Service