DICOM PS3.22 2021c - Real-Time Communication

6 Data Communication Requirements (Current)
Prev |  | Next

# 6 Data Communication Requirements

Figure 5-1 in PS3.1 presents the general communication model of the DICOM Standard, which spans both network (on-line) and storage media interchange (off-line) communications. Application Entities may utilize any of the following transport mechanisms:

- the DICOM Message Service and Upper Layer Service, which provides independence from specific physical networking communication support and protocols such as TCP/IP,

- the DICOM Web Service API and HTTP Service, which allows use of common hypertext and associated protocols for transport of DICOM services,

- the Basic DICOM File Service, which provides access to Storage Media independently from specific physical media storage formats and file structures, or

- DICOM Real-Time Communication, which provides real-time transport of DICOM metadata based on SMPTE and RTP.

This Part describes the DICOM Real-Time Communication, which uses the RTP protocol as defined in [SMPTE ST 2110-10], as depicted in Figure 6-1a.

Figure 6-1a. DICOM Communication Model for Real-Time Communication

## 6.1 Interaction

As shown in Figure 6-1, a device can have multiple Sources, one for each Essence which corresponds of the type of bulk data (video, audio or medical metadata), each Source producing one or multiple Flows representing the same content in different formats (high definition, low definition, uncompressed, compress with or without loss, …).

Several Sources may be grouped in a Source Group. A concrete experience of a Source Group is a Rendition, defined as a collection of time-synchronized Flows intended for simultaneous presentation (e.g., the audio channel of a surgical camera).

Figure 6-1. Real World diagram of DICOM-RTV

DICOM Real-Time Video standard specifies the communication mechanism for metadata, associated with real-time video and/or audio, originated from a medical imaging device. The mechanism involves one Source and one Flow of "DICOM Video Metadata Essence" for each video Flow and one Source and one Flow of "DICOM Audio Metadata Essence" for each audio Flow. Optionally, there is one Source and one Flow for the "DICOM Rendition Metadata" associating multiple Flows produced by the same device.

The interaction shall be as shown in Figure 6-2.

Figure 6-2. Interaction Diagram

[SMPTE ST 2110-10] provides end-to-end network transport functions for applications transmitting real-time data. Content is transmitted in RTP sessions using RTP packets respecting [SMPTE ST 2110-10].

A device can provide and/or consume content. A device that provides content has one or more Sources that can be of different Essences (e.g., Video and Audio). A Source is the origin of one or more Flows. Multiple Flows coming from the same Source are representations of the same content in different resolutions and/or codings. This is a broadcast/multicast protocol, so a device provides content whether or not a consuming device is present. A device that consumes content can subscribe/unsubscribe to available Flows.

The context and content of a video and/or audio Flow is described by a DICOM Metadata Flow, which is associated with each Flow. However the same DICOM Metadata Flow may be used to describe more than one Flow if their content is the same and their coding are close enough not to affect professional interpretation. A DICOM Rendition Metadata Flow may be used to associate multiple Flows provided by one device.

Prev |  | Next
5 Conventions | Home | 6.2 Transport

DICOM PS3.22 2021c - Real-Time Communication