База ГОСТовallgosts.ru » 35. ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ. МАШИНЫ КОНТОРСКИЕ » 35.240. Применение информационных технологий

ГОСТ Р 57377-2016 Информатизация здоровья. Функциональная совместимость систем и сетей телездравоохранения. Часть 2. Системы реального времени

Обозначение: ГОСТ Р 57377-2016
Наименование: Информатизация здоровья. Функциональная совместимость систем и сетей телездравоохранения. Часть 2. Системы реального времени
Статус: Принят

Дата введения: 01/01/2018
Дата отмены: -
Заменен на: -
Код ОКС: 35.240.80
Скачать PDF: ГОСТ Р 57377-2016 Информатизация здоровья. Функциональная совместимость систем и сетей телездравоохранения. Часть 2. Системы реального времени.pdf
Скачать Word:ГОСТ Р 57377-2016 Информатизация здоровья. Функциональная совместимость систем и сетей телездравоохранения. Часть 2. Системы реального времени.doc


Текст ГОСТ Р 57377-2016 Информатизация здоровья. Функциональная совместимость систем и сетей телездравоохранения. Часть 2. Системы реального времени



ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ

НАЦИОНАЛЬНЫЙ

СТАНДАРТ

РОССИЙСКОЙ

ФЕДЕРАЦИИ

ГОСТР

57377-

2016/

ISO/TR 16056-2: 2004

Информатизация здоровья

ФУНКЦИОНАЛЬНАЯ СОВМЕСТИМОСТЬ СИСТЕМ И СЕТЕЙ ТЕЛЕЗДРАВООХРАНЕНИЯ

Часть 2

Системы реального времени

(ISO/TR 16056-2:2004,

Health informatics — Interoperability of teiehealth systems and networks —

Part 2: Real-time systems,

IDT)

Издание официальное

Москва

Стандартииформ

2017

ГОСТ Р 57377—2016

Предисловие

1    ПОДГОТОВЛЕН Федеральным государственным бюджетным учреждением «Центральный научно-исследовательский институт организации и информатизации здравоохранения Министерства здравоохранения Российской Федерации» (ЦНИИОИЗ Минздрава) и обществом с ограниченной ответственностью «Корпоративные электронные системы » на основе собственного перевода на русский язык англоязычной версии международного документа, указанного в пункте 4

2    ВНЕСЕН Техническим комитетом по стандартизации ТК468 «Информатизация здоровья» при ЦНИИОИЗ Минздрава — постоянным представителем ИСО ТС 215

3    УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 29 декабря 2016 г. № 2105-ст

4    Настоящийстандартидентичен международному документу ISO/TR 16056-2:2004 «Информатизация здоровья. Функциональная совместимость систем и сетей телездравоохранения. Часть 2. Системы реального времени» (ISO/TR 16056*2:2004 «Health informatics — Interoperability of telehealth systems and networks — Part 2: Real-time systems». IDT).

Наименование настоящего стандарта изменено относительно наименования указанного международного документа для приведения в соответствие с ГОСТ Р1.5—2012 (пункт 3.5).

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

5    ВВЕДЕН ВПЕРВЫЕ

Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 201S г. No 162-ФЗ «О стандартизации е Российской Федерации». Информация об измене• ниях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — е ежемесячном информационном указателе «Национальные стандарты». В случав пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет ()

© Стандартинформ.2017

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

ГОСТ Р 57377—2016

Содержание

1    Область применения...................................................1

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

3    Термины и определения................................................2

4    Сокращения........................................................9

5    Стандарты мультимедийной конференции....................................10

5.1    Общие положения.................................................10

5.2    Рекомендации Н.320 ............................................... 11

5.3    Рекомендации Н.321 и Н.310..........................................13

5.4    Рекомендации Н.323 ............................................... 14

5.5    Рекомендации Н.324 ............................................... 17

5.6    Рекомендации Т. 120...............................................18

6    Приложения телеэдравоохранения.........................................20

6.1    Общие сведения..................................................20

6.2    Телвобучение....................................................20

6.3    Твлеконсультация.................................................21

7    Проблемы функциональной совместимости...................................22

7.1    Общие сведения..................................................22

7.2 Источники проблем функциональной совместимости, связанные со стандартами.........23

7.3 Источники проблем функциональной совместимости, связанные с изделием...........26

7.4    Источники проблем функциональной совместимости, связанные с реализацией.........27

8    Требования функциональной совместимости..................................28

8.1    Общие положения.................................................28

8.2    Установление вызова...............................................29

8.3    Получение, обработка и передача мультимедийных данных......................29

8.4    Управление ближними и удаленными устройствами...........................30

8.5    Завершение вызова................................................30

9    Функциональная совместимость в неоднородных сетях телеэдравоохранения.............30

9.1    Общие положения.................................................30

9.2    Функциональная совместимость систем Н.320 в сети типа Frame Relay...............31

9.3    Функциональная совместимость систем, совместимых с Н.Зхх в неоднородных сетях......32

10    Подход к созданию функционально совместимых архитектур.......................35

10.1    Общие положения................................................35

10.2    Области функционирования компонентов телеэдравоохранения..................35

Приложение ДА (справочное) Сведения о соответствии ссылочных международных стандартов

и международных документов национальным стандартам.................38

Библиография........................................................39

in

ГОСТ Р 57377—2016

Введение

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

Обмен данными в телездравоохранении может быть реализован тремя способами: в реальном времени, с промежуточным хранением или сприменением методов потоковой передачи данных. Обмен информацией в реальном времени подразумевает непосредственное участие всех сторон в сеансе телеэдравоохранения. тогда как при обмене информацией с промежуточным хранением процесс включает отправку, рассмотрение и возвращение информации в течение определенного периода времени. Потоковая передача данных является способом передачи данных реального времени или хранимых данных, таких как звук, видео, документы, фотоснимки, а также других типов данных по сетям с приемлемым уровнем качества обслуживания (OoS). При потоковой передаче данных принимающая система может начать воспроизведение или отображение данных до получения полного объема информации.

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

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

1)    слишком широкое определение телездравоохранения:

2)    отсутствие стандартов, разработанных специально для сферы телездравоохранения:

3)    недостаточно скоординированное сотрудничество между информационными и телекоммуникационными компаниями.

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

«Официального» стандарта применительно к телездравоохранению не существует. В сфере телездравоохранения используются нормы и рекомендации здравоохранения высокого уровня и технические стандарты, разработанные для различных секторов, включая мультимедийные конференции, информационные технологии, сектора обмена данными и обеспечения информационной безопасности медицинских данных. Существующие нормативы и стандарты сфокусированы на функциональных и эксплуатационных требованиях и не обеспечивают функциональной совместимости различных систем телеэдравоохранения. Дополнительные проблемы связаны с тем. что все эти стандарты и потребности технологий телеэдравоохранения быстро меняются.

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

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

IV

ГОСТ Р 57377—2016

также разработать комплекс стандартов по телездравоохранению и внедрить их в соответствующие отрасли промышленности.

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

Часть 1. Введение и определения. В данной части содержится введение в телездравоохранение и даются определения телездравоохранекия. функциональной совместимости и связанных с ними терминов.

Часть 2. Системы реального времени. В данной части определяется область применения технических стандартов, относящихся кприложениям реального времени (включая видео*, аудио- и информационные конференции), идентифицируются пробелы и совпадения в стандартах, определяются требования к функционально совместимым системам и сетям телеэдравоохранения. идентифицируются структурные компоненты для создания решений для функционально совместимых систем телездравоохранения.

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

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

v

ГОСТ Р 57377—2016/ISO/TR 16056-2:2004

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Информатизация здоровья

ФУНКЦИОНАЛЬНАЯ СОВМЕСТИМОСТЬ СИСТЕМ И СЕТЕЙ ТЕЛЕЗДРАВООХРАНЕНИЯ

Часть 2

Системы реального времени

Health Informatics, interoperability of teiehealtn systems and networks. Part 2. Real-time systems

Дата введения — 2018—01—01

1    Область применения

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

8 частности, настоящий стандарт рассматривает четыре основные области:

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

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

Ш) Требования к функционально совместимым системам и сетям телездравоохранения. Настоящий стандарт определяет требования функциональной совместимости на разных уровнях взаимодействия между системами телездравоохранения и дает ряд руководящих указаний о том. как функциональная совместимость может архивироваться.

iv) Общие принципы функционально совместимых архитектур. Настоящий стандарт определяет функционально совместимые структурные элементы для решений телездравоохранения и взаимодействия между этими структурными элементами и изучает возможность стандартизации этих структурных элементов.

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

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

8 настоящем стандарте использованы следующие международные стандарт и документы. Применяют только указанное издание.

CEN/TC 251/N99-097 (1999) Health Informatics — Interoperability of Healthcare Multimedia Report Systems. Final draft CEN Report (Информатизация здравоохранения. Функциональная совместимость мультимедийных систем генерации отчетов в сфере здравоохранения)

Издание официальное

1

ГОСТ Р 57377—2016

ISO/IEC 17000:2004 Conformity assessment. Vocabulary and general principles (Оценка соответствия. Словарь и общие принципы)

ITU-T Recommendation G.711 (1986) Pulse code modulation (PCM) of voice frequencies (Импульснокодовая модуляция (ИКМ) частот голосового спектра)

ITU-T Recommendation G.722 (1993) 7 KHz audio-coding within 64 kbit/s (Аудиокодирование на 7 КГц при 64 кбит/с)

ITU-T Recommendation G.728 (1992) Coding of speech at 16 kbit/s using low-delay code excited linear prediction (Кодирование речи при 16 кбит/ссприменением управляемого кодом линейного предсказания с малой задержкой)

ITU-T Recommendation Н.221 (1993) Frame structure for а 64 to 1920 kbit/s channel in audiovisual teleservices (Структура кадра для канала от 64 до 1920 кбит/с в аудиовизуальных телеуслугах)

ITU-T Recommendation Н.230 (1997) Frame-synchronous control and indication signals for audiovisual systems (Управление с синхронизацией кадров и сигналы индикации в аудиовизуальных системах)

ITU-T Recommendation Н.242 (1996) System for establishing communication between audiovisual terminals using digital channels up to 2 Mbit/s (Система для установления связи между аудиовизуальными терминалами с использованием цифровых каналов до2 Мбит/с)

ITU-T Recommendation Н.243(1997) Procedures for establishing communication between three or more audiovisual terminals using digital channels up to 1920 kbit/s (Процедуры установления связи между тремя и более аудиовизуальными терминалами с использованием цифровых каналов до 1920 кбит/с)

ITU-T Recommendation Н.224 (1994) A real time control protocol for simplex applications using the H.221 LSD/HSD/HLP channels (Протокол управления в реальном времени для симплексных приложений с использованием каналов Н.221 LSD/HSD/HLP)

ITU-T Recommendation Н.281 (1994) Afarend camera control protocol for videoconferences using Н.224 (Протокол управления удаленной камерой для видеоконференций с использованием Н.224)

ITU-T Recommendation Н.233 (1996) Confidentiality System for Audiovisual Services (Система конфиденциальности для аудиовизуальных сервисов)

ITU-T Recommendation Н.234 (1996) Encryption key management and authentication system for audiovisual services (Управление криптографическими ключами и система аутентификации для аудиовизуальных сервисов)

ITU-T Recommendation Н.320 (1996) Narrow-band visual telephone systems and terminal equipment (Узкочастотные еидеотелефонные системы и терминальное оборудование)

ITU-T Recommendation Т.120 (1996) Data protocols for multimedia conferencing (Протоколы передачи данных для мультимедийных конференций)

ITU-T Recommendation Т.121 (1996) Generic application template (Шаблон обобщенного приложения)

ITU-T Recommendation Т.122 (1993) Multipoint communication service for audiographics and audiovisual conferencing service definition (Сервис многоточечной связи для приложений аудиографичес-ких и аудиовизуальных конференций)

ITU-T Recommendation Т.123 (1994) Protocol stacks for audiographic and audiovisual teleconference applications (Протокольные стеки для приложенийаудиографичвских иаудиовиэуальных конференций) ITU-T Recommendation Т.124 (1995) Generic conference control (Управление обобщенной конференцией)

ITU-T Recommendation Т.125 (1994) Multipoint communication service protocol specification (Спецификация протоколов для сервиса многоточечной связи)

ITU-T Recommendation Т.126 (1995) Multipoint still image and annotation protocol (Многоточечный протокол для статического изображения и аннотации)

ITU-T Recommendation Т.127 (1995) Multipoint binary file transfer protocol (Многоточечный протокол передачи двоичных файлов)

3 Термины и определения

В настоящем стандарте применены следующие термины с соответствующими определениями:

3.1    аккредитация (accreditation): Аттестация третьей стороной, относящаяся к органу по оценке соответствия, служащая формальным доказательством его компетентности для выполнения конкретных задач по оценке соответствия.

3.2    A-закон (A-law): Вариант аудиокодирования G.711. используемый в основном в Северной Америке и Японии.

Примечание — Связанные термины включают в себя и-закон и G.711.

2

ГОСТ Р 57377—2016

3.3    асинхронная передача (asynchronous transmission): Передача отдельных байтов без временной зависимости между байтами.

3.4    аудиографический терминал (audiographic terminal): Терминал, имеющий возможность звукового и графического отображения информации, но не имеющий возможность видеоотображения.

3.5    аудиовизуальный терминал (audiovisual terminal): Терминал, имеющий возможность звукового. графического и видеоотображения информации.

3.6    интерфейс передачи данных с номинальной скоростью, ИНС (basic rate interface. BRI): ISDN-сервис, включающий два В-канала (канала-носителя), работающих со скоростью 64 кбит/с каждый, и один D-канал (канал данных), работающий со скоростью 16 кбит/с.

3.7    вызов (call): Двухточечные мультимедийные коммуникации между Двумя конечными точками по Н.32х.

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

3.9    канал передачи сигналов о вызовах (call signaling channel): Надежный канал, используемый для передачи сообщений об установлении вызова в соответствии с 0.931.

3.10    разъединение вызова (call teardown): Процесс завершения связи и освобождения всех ресурсов, зарезервированных для этой связи.

3.11    централизованная многоточечная конференция (centralized multipoint conference): Конференция, при которой все терминалы-участники сообщаются двухточечным способом посредством МБУ.

3.12    сертификация (certification): Аттестация третьей стороной в отношении продуктов, процессов. систем или лиц.

Примечания

1    Сертификация системы управления иногда также называется регистрацией.

2    Сертификация применима ко всем объектам оценки соответствия, за исключением самих органов оценки соответствия, на которые распространяется аккредитация.

3.13    блок обслуживания какала: БОК(channel service unit. CSU): Интерфейс, используемый для подключения терминала или компьютера к цифровой среде так же. как модем используется для подключения к аналоговой среде.

3.14    прибор сэарядовой связью; ПЗС (charge coupled device. ССО):Устройстео. используемое в камерах в качестве оптического сканирующего механизма.

Примечание — Он содержит сдвиговый регистр, который хранит образцы аналоговых сигналов. Аналоговый заряд последовательно передается на устройство посредством пошаговых напряжений и сохраняется а потенциальных ямах, образованных под электродами. Заряд передается от одной ямы к другой посредством пошаговых напряжений.

3.15    КОдер-ДЕКодер, КОмпрессия/ДЕКомпрессия. КОДЕК (COder/DECoder. compression/ DECompression. CODEC): Устройство или программное обеспечение, используемое для интерактивных видеосистем, конвертирующее аналоговый сигнал в цифровой, а затем выполняющее его декомпрессию. позволяющую использовать более низкоскоростные пинии связи

Примечание — на принимающем конце линии сигнал распаковывается и конвертируется обратно в аналоговый вывод данных совместимым кодеком. Способ (алгоритм) упаковывания может являться «фирменным» или основанным на стандарте.

3.16    единый промежуточный формат; ЕПФ (common intermediate format. CIF): Рекомендованный МСЭ-Т стандартный формат сканирования видеоизображения, в котором сохраняется информация по яркости (освещенности) и двум компонентам цветового контраста (цветности).

Примечание — С IF содержит 352 пикселя а строке при 288 строках в кадре для яркости и 176 пикселей в строке при 144 строках в кадре для цветности. См. также 4CIF.

3.17    композитный видеосигнал (composite video): Тил видеосигнала, в котором вся информация — красный, синий и зеленый сигналы, а также иногда одновременно и звуковые сигналы смешиваются вместе.

Примечание — Композитный видеосигнал используется устройствами, соответствующими системе NTSC (см. стандарт NTSC).

3

ГОСТ Р 57377—2016

3.18    оценка соответствия (conformity assessment): Демонстрация того, что определенные требования к продукту, процессу, системе, личности или органу, выполнены.

Примечание — Соответствие ряду спецификаций является предпосылкой к функциональной совместимости. Однвко семо по себе соответствие спецификациям не гарантирует функциональной совместимости систем.

3.19    блок обслуживания данных, БОД (data service unit. OSU): Устройство, используемое при цифровой передаче для подключения БОК к терминальному оборудованию (терминалу или компьютеру). так же. как модем используется для подключения к аналоговой среде.

Примечание — См. также БОК.

3.20    децентрализованная многоточечная конференция (decentralized multipoint conference): Конференция, при которой все участвующие в ней терминалы осуществляют многоадресную передачу всем другим участвующим терминалам без использования МБУ.

3.21    конечная точка (end point): Терминал, шлюз или МБУ.

3.22    6.711: Рекомендация МСЭ-Т в отношении цифрового воспроизведения речи с частотой до 3.4 КГц. производящего потокданных64 Кб/с.

Примечание — Широко используется в телефонных сетях. Существует в двух ввривнтах: А-закон и ц -закон.

3.23    G.722: Рекомендация МСЭ-Т в отношении цифрового воспроизведения аудио с частотой до 7 КГц. производящего лоток данных 64 Кб/с. с гораздо более высоким качеством, чем в G.711.

3.24    G.728: Рекомендация МСЭ-Теотношении цифрового воспроизведения аудио, производящего лоток данных 16 Кб/с. обеспечивающего качество, близкое к телефонной передаче звука.

3.25    контроллер шлюза (gatekeeper): Объект стандарта Н.323. обеспечивающий трансляцию адресов, контроль доступа и иногда управление полосой пропускания в ЛВС для терминалов, шлюзов и МБУ Н.323.

3.26    шлюз (gateway): Объект стандарта Н.323. предоставляющий двустороннюю связь в реальном времени между терминалами стандарта Н.323 в ЛВС и другими терминалами МСЭ в глобальной сети, или к другому шлюзу Н.323.

3.27    общее соединение для конференции; ОСК (generic conference call. GCC): Комплекс услуг по конференции, описанный в Рекомендации МСЭ-Т Т.124.

3.28    Н.221: Рекомендация МСЭ-Т, определяющая, как мультиплексировать видео- и аудиоданные в кадрах с использованием каналов 64-1920 Кб/с для сервисов коммутируемых и арендуемых сетей, за исключением пакетированных сетей.

3.29    H.225D: Рекомендация МСЭ-Т. определяющая сообщения для управления соединением, включая передачу сигналов, регистрацию и доступ, а также пакетиэацию/синхрониэацию медиасистем.

3.30    Н.230: Рекомендация МСЭ-Т. определяющая синхронное управление кадрами и сигналы индикации для аудиовизуальных систем.

3.31    Н.231: Рекомендация МСЭ-Т. определяющая устройство многоточечного управления.

3.32    Н.235: Рекомендация МСЭ-Т. определяющая инфраструктуру безопасности, используемую для обеспечения аутентификации, кодирования и целостности систем Н.323.

3.33    Н.242: Рекомендация МСЭ-Т. определяющая, как устанавливается связь между аудиовизуальными терминалами через цифровые каналы на скорости до 2 Мб/с.

3.34    Н.243: Рекомендация МСЭ-Т. определяющая установление связи между тремя и более аудиовизуальными терминалами через цифровые каналы на скорости до 2 Мб/с.

3.35    Н.245: Рекомендация МСЭ-Т. определяющая сообщения для открытия и закрытия каналов для потоков данных и другие команды, запросы и индикации между двумя конечными точками Н.323.

3.36    Н.261: Рекомендация МСЭ-Т. определяющая алгоритм кодирования и компрессии для двух вариантов разрешения видео: 352 х 288 CIF и 176 х 144 QCIF.

Примечание — Н.261 используется е Н.Э20 и Т.120.

3.37    Н.263: Рекомендация МСЭ-Т, определяющая новый видеокодек для видео, передаваемого по сетям с коммутацией пакетов или ОАТЛ.

Примечание — Н.263 оптимизирует Н.261 для очень низкой скорости кодирования видео ниже 64 Кб/с. Н.26Э делает возможной лучшую компенсацию движения, более точные векторы движения, оптимизированную квантизацию для очень низких скоростей и арифметическое кодирование.

3.38    Н.310: Комплекс стандартов МСЭ-Т. ратифицированных в 1995 году, которые описывают технические спецификации для адаптации узкополосных еидеотелефонных терминалов ISDN, определенных в Н.320. к широкополосным средам ISDN (в-ISDN) и АТМ.

4

ГОСТ Р 57377—2016

Примечание — Н.310 добавляет алгоритм видеокомпрессии MPEG-2. который обеспечивает качество видео по стандарту MPEG-2.

3.39    Н.320: Комплекс стандартов МСЭ-Т. ратифицированных в 1990 году, которые определяют то. как связываются системы голосовой и видеоконференции через сети ISON или арендуемые сети с использованием полосы пропускания от 64 Кб/с до 1920 Кб/с.

3.40    Н.323: Комплексстандартов МСЭ-Т. ратифицированных в 1996 году, расширяющих Н.320 до компьютерных сетей, включая ЛВС и Интернет.

Примечание — Н.323 поддерживает как прямые, так и многоточечные операции. Кроме того, в н.323 используются многие компоненты из спецификации Н.32х, такие как видеокодек н.261. аудиокодек G.711. видеокодек Н.263. G.722. G.723 и G.728. Новым в Н.323 является определение контроллера шлюза, который позволяет администраторам ЛВС управлять видеотрафиком для обеспечения QoS. В Н.323 также дается определение шлюза LAN/H.320. который позволяет узлу Н.323 взаимодействовать с терминалами Н.320/Н.Э24.

3.41    Н.324: Комплекс стандартов МСЭ-Т. ратифицированных в 1996 году, которые позволяют проводить видеоконференции с использованием стандартных аналоговых телефонных линий со свойствами, аналогичными описанным в Н.320.

Примечание — В Н.324 используется Н.263. который содержит более хороший кодек для ОАТЛ. чем Н.261. Н.263 является улучшенной версией Н.261. добавляющей формат 128 «96 sub-QCIF (SGClF). При использовании модема со скоростью 28.6 или 36.6 Кб/с. Н.263 может производить частоту кадров, приближенную к частоте, обеспечиваемой системами Н.320 через ISON.

3.42    функциональная совместимость (interoperability); Способность двух и более систем (компьютеры, устройства связи, сети, программное обеспеченней другие компоненты информационных технологий) взаимодействовать друг с другом и обмениваться информацией предписанным методом для получения предсказуемого результата.

3.43    тестирование функциональной совместимости (interoperability testing): Оценка способности двух и более систем взаимодействовать друге другом и обмениваться электронными данными.

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

3.44    ц-эакон(ц-1а>у): Вариант аудиокодирования G.711. используемыйпреимущестеенноеСевер* ной Америке и Японии.

Примечание — См. также G.711 и А-закон.

3.45    блок многоточечного управления; БМУ (multipointcontrol unit. MCU); Конечная точка в ЛВС. позволяющая трем и более терминалам и шлюзам участвовать в многоточечной конференции.

Примечание — БМУ обязательно содержит МК и опционально — МП.

3.46    многоточечный контроллер: МК (multipoint controller. МС); Объект, обеспечивающий управление тремя и более терминалами при многоточечной конференции.

3.47    многоточечный процессор; МП (multipoint processor. МР); Объект, обеспечивающий обработку потоков аудио- и/или видеоданных при многоточечной конференции.

Примечание — МП предусматривает смешивание, переключение и другие виды обработки потока данных под контролем МК.

3.48    многоточечная конференция (multipoint conference); Конференция между тремя и более терминалами, объединенными ЛВС или сетью с коммутацией каналов.

3.49    Стандарт NTSC (NTSC Standard); Стандарт телевещания, установленный Национальным комитетом по телевизионным стандартам (NTSC).

Примечание — Используется е Северной Америке. Японии и некоторых других странах. Формат NTSC: 525 строк в кадре: 30 кадров в секунду (кадр/сек.>; коэффициент черезстрочности 2:1; формат кадра 4:3; уравнение цветовой матрицы: У ■ 0.3R ♦ 0.59G ♦ 0.11В: I * 0.6R - 0.28G -0.32В: Q ■ 0.21R - 0.52G * 0.31В. где R « красный. G ■ зеленый и В * синий.

5

ГОСТ Р 57377—2016

3.50    протокол прямой передачи (point-to-point protocol): Протокол, определенный в RFC 1661, стандарт Интернета для передачи дейтаграмм сетевого уровня (например. IP пакетов) через последовательные двухточечные линии связи.

3.51    интерфейс передачи данных с базовой скоростью; ИБС (primary rate interface. PRI): Сервис ISDN, включающий 23 В-канала (канала-носителя), работающих оо скоростью 64 Кб/с каждый, и один D-канал (канал данных), работающий со скоростью 16 Кб/с.

3.52    импульсно-кодовая модуляция (pulse code modulation): Метод, используемый для цифровой дискретизации звука.

Примечание — Входящие колебания с полосой пропускания до 4.0 КГц отбираются с рекомендованной скоростью 8000 выборок в секунду. Каждая выборка конвертируется в одно из 212 цифровых значений и затем компрессируется в соответствии либо с A-законом, либо с и-законом. Такая схема выборки адекватна для голосовой связи.

3.53    качество обслуживания; КО (quality of service. QoS): Комплекс сетевых технологий, позволяющих сети обрабатывать информационный трафик с минимальным количеством отрицательных последствий для сетевого окружения, используемого множеством других пользователей.

Примечание — Получатели QoS оговаривают в договоре об уровне услуг (SLA) требования к производительности. потере пакетов, времени задержки и дрожания.

3.54    формат ТВ-изображения. специфицируемый Рекомендациями Н.261 МККТТ (quarter common intermediate format. QCIF): Данный формат предусматривает 176 пикселей в строке при 144 строках в кадре для яркости и 68 пикселей в строке при 72 строках в кадре для цветности.

Примечание — См. также CIF.

3.55    протокол поточной передачи реального времени; ПППРВ (real-time streaming protocol. RTSP): Протокол уровня приложения, устанавливающий и контролирующий один или несколько синхронизированных во времени потоков непрерывных сред.

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

3.56    протокол передачи данных реального времени (real-time transport protocol. RTP): Протокол обмена данными, обеспечивающий передачу данных в реальном времени, например передачу в реальном времени или интерактивный обмен аудио- и видеоданными по IP-сетям с коммутацией пакетов.

Примечание — RTP действует поверх UOP. используя его свойства мультиплексной передачи и контроля ошибок.

3.57    заданное требование (specified requirement): Сформулированная потребность или ожидание.

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

3.58    язык интеграции синхронизированных мультимедийных данных (synchronized multimedia integration language. SMIL): Позволяете легкостью разрабатывать интерактивные аудиовизуальные презентации.

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

3.59    синхронная передача (synchronous transmission); Передача данных, в ходе которой данные пересылаются с фиксированной скоростью при синхронизации передающего и принимающего устройств.

3.60    Т.120: Комплексстандартов МСЭ-Т. ратифицированных в 1996 году, в которых определяется совместное использование документов и электронных досок.

Примечание — Стандарты Т.120 обеспечивают вудиографическую часть семейств стандартов Н.320. Н.323 и Н.Э24. Они также работают независимо в режиме аудиогрвфической конференции для низкочастотного канала. Возможности электронных досок позволяют совместное использование документов многими пользователями так. что они могут одновременно просматривать и вносить комментарии в документы, используя ручки, маркеры и чертежные инструменты. Данная спецификация также допускает возможность проведения сессий Т.120 только с

6

ГОСТ Р 57377—2016

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

3.61    Т.121: Стандарт МСЭ-Т. устанавливающий обобщенный шаблон приложений (GAT). который определяет общий набор руководств по созданию протоколов приложений и средства управления, контролирующие ресурсы, используемые приложением.

Примечание — В T.121 также описано, каким образом протокол приложения, например Т.127, используемый для передачи данных, выполняет следующие функции:

•    регистрирует себя в конференции.

•    применяет свои возможности локально и удаленно и

•    взаимодействует и договаривается о возможностях сдругими приложениями.

Для продуктов, разрабатываемых под стандарты Т.120. Т.121 является необходимым стандартом, чтобы обеспечить совместимость приложений. МСЭ также рекомендует, чтобы нестандартные приложения соответствовали требованиям Т.121 с целью обеспечения функциональной совместимости продуктов.

3.62    Т.122: Стандарт МСЭ-Т. определяющий многоточечные сервисы, позволяющие одному или нескольким участникам передавать данные в ходе конференции.

Примечание — Такие многоточечные сервисы реализованы в Т.125, который обеспечивает механизм для передачи данных. Вместе стандарты Т.122 и Т.125 обеспечивают услуги многоточечной связи (УМС) стандарта Т.120.

3.63    Т.123: Стандарт МСЭ-Т. определяющий передачу и упорядочение данных, а также управление потоком данных в сетях, включая функции соединения, разъединения, отправки и приема.

Примечание — Для передачи данных Т.123 определяет ряд профилей сетевого интерфейса. Кроме того. Т.123 обеспечивает механизм исправления ошибок, гарантирующий точную и надежную доставку данных. В дополнение к стандарту проведения телеконференций, в Т.123, приложение 8. определен протокол для безопасного проведения конференций с передачей денных.

3.64    Т.124: Стандарт МСЭ-Т. обеспечивающий общее соединение для конференции (ОСК) для инициализации и администрирования многоточечных телеконференций.

Примечание — ОСК выполняет следующие функции:

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

•    поддерживает списки участников конференций и их приложений. БОК идентифицирует совместимые приложения и возможности, позволяя продуктам взаимодействовать, и

•    отслеживает ресурсы услуги многоточечной связи (УМС). чтобы избежать конфликтов в случае, когда участники конференции используют разные протоколы приложений, например Т.127 для передачи файлов и Т.128 для совместного использования приложений.

3.65    Т.125: Стандарт МСЭ-Т. определяющий, как передаются данные в ходе конференции.

Примечание — Т.125 определяет частные и широковещательные каналы передачи данных и обеспечивает точную и эффективную связь между многими пользователями. Т.125 также реализует многоточечные сервисы, определенные в Т.122.

3.66    Т.126: Стандарт МСЭ-Т, определяющий, как приложение отправляет и получает информацию с электронной доски, в сжатой или несжатой форме, для просмотра и обновления участниками многоточечной конференции.

Примечание — Ролью Т.126 является управление многопользовательским рабочим пространством, предоставляемым электронной доской.

3.67    Т.127: Стандарт МСЭ-Т. определяющий, как между участниками конференции одновременно передаются файлы.

Примечание — Т.127 (также известный какТ.МВТР — многоточечная передача двоичных файлов) обеспечивает выбор и передачу одного или нескольких файлов в сжетом или несжатом виде всем или выбранным участникам в хода конференции.

3.66 Т.128: Стандарт МСЭ-Т. определяющий протокол совместного использования программ, устанавливая, как участники конференции no Т.120 могут совместно использовать локальные программы. В частности. Т.128 дает возможность многим участникам конференции просматривать и сотрудничать при совместном использовании программ.

7

ГОСТ Р 57377—2016

3.69    Т.134: Протокол, обеспечивающий двухточечное и многоточечное распространение текстовых сообщений в ходе конференции по Т.120.

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

3.70    Т.135: Протокол, позволяющий пользователю резервировать и контролировать ресурсы многоточечной конференции.

Примечание — Данный протокол определяет протоколы резервирования ресурсов конференции в среде Т.120, как правило, между клиентским приложением и системой планирования, резервирующей ресурсы для устройств многоточечного управления {БМУ) или мостов.

3.71    Т.136: Протокол, определяющий, как дистанционное управление устройствами и конфигурирование могут осуществляться с использованием Т.120 в качестве транспортного протокола.

3.72    Т.140: Протокол для текстового общения в мультимедийных приложениях.

Примечание — Протокол для текстового общения в рамках Т.120: используется вместе с Т.134.

3.73    T.AVC: Протокол, описывающий управление аудио- и видеовозможностями персонального компьютера или видеоконференции.

Примечание — Данный стандарт расширяет возможности, предлагаемые Н.Э20.

3.74    T.RDC: Рекомендация, обеспечивающая управление удаленными аудио- и видеоустройствами в ходе конференции.

Примечание — Будучи относительно новой рекомендацией. T.RDC является рвсширением Н.261 для управления удаленной камерой.

3.75    Телездравоохранение (telehealth): использование телекоммуникационной техники в целях дистанционного обеспечения телемедицины, обучения медицинского персонала и медицинского просвещения населения.

Примечание — См. GATES 1994.

3.76    телемедицина (telemedicine): Использование передовых телекоммуникационных технологий для обмена информацией о здоровье и предоставления услуг здравоохранения независимо от географических, временных, социальных и культурных барьеров.

Примечание — См. Рейд. 1996.

3.77    терминал (terminal): Конечное оборудование, которое обеспечивает двустороннее общение с другим терминалом, шлюзом или БМУ в режиме реального времени.

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

3.78    проверка соответствия (testing of conformity): Определение, удовлетворяет ли одна или несколько характеристик объекта, оцениваемого на соответствие, заданным требованиям в соответствии с процедурой.

Примечание — Понятие «проверке» обычно откосится к материалам, изделиям или процессам. Основным результатом проверки соответствия является отчет о проверке, включающий заданные требования, реальные результаты проверки и статус соответствия (то есть прошло или нет денное изделие проверку).

3.79    протокол управления передачей данных/межсетевой протокол (transport control protocol/intemet protocol, TCP/IP): Протоколы Ethernet, фактически являющиеся стандартом и входящие e4.2BSDUnix.

Примечание — TCP/IP был разработан OARPA для межсетевого обмена. Он содержит протоколы как сетевого, так и транспортного уровней. 8 то время как TCP и IP определяют два протокола на конкретных уровнях. TCP/IP часто используется для обозначения всего основанного на них набора протоколов МО США. включая telnet. FTP. UDPhRDP.

3.80    протокол дейтаграмм пользователя (user datagram protocol): Ненадежный сетевой уровень, расположенный на том же уровне сетевого стека, что и TCP.

3.81    видеоконференция (videoconferencing): Электронная форма связи, позволяющая людям, находящимся в разных местах, осуществлять непосредственную аудио- и видеосвязь. Кроме того, под этим термином понимается комплекс технологий, интегрирующих видеоинформацию с аудиоинфор-

8

ГОСТ Р 57377—2016

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

3.62 потоковое видео (video streaming): Метод передачи мультимедийной информации (напри* мер, аудио*, видеоизображений, текста, буквенно-цифровых данных, данных временного ряда, форм колебаний) по сетям с обоснованным значением QoS.

Примечание — Получающая система воспроизводит (отображает или проигрывает) информацию в то время как данные передаются в фоновом режиме. Обычно никакого хранения данных в ходе потоковой передачи не происходит. Следующие протоколы были разработаны в IETF и веб-консорциуме (W3C) для обеспечения потоковой передачи данных:

-    RTP.

-    RTSP и

• SMIL (язык интеграции синхронизированных мультимедийных данных).

3.83 зона (zone): Комплекс всех терминалов, шлюзов и ЕМУ. управляемый одним контроллером шлюзов.

Примечание — Зона должна включать, по крайней мере, один терминал и может включать сегменты Л8С. соединенные посредством маршрутизаторов.

4 Сокращения

8 настоящем стандарте применены следующие сокращения:

AAL — уровень адаптации режима асинхронной лередачи (AAL — ATM Adaptation Layer:

ACR — Американская коллегия радиологов (ACR — American College of Radiologists):

АЦАЛ —Асинхронная цифровая абонентская линия (ADSL — Asynchronous Digital Subscriber Line);

ANSI — Американский национальный институт стандартов (ANSI — American National Standards Institute):

ATM    — Режим асинхронной передачи (ATM — Asynchronous Transfer Mode);

8-ISDN — Широкополосная ISDN. см. H.310 (B-ISDN — Broadband ISDN);

ИНС — Интерфейс лередачи данных с номинальной скоростью (8RI — Basic Rate Interface); ПЗС    — Прибор с зарядовой связью (CCD — Charge Coupled Device);

CIF    — Единый промежуточный формат (CIF — Common Intermediate Format);

КУС — Контроль, управление и сигнализация (CMS — Control, Management and Signalling); КОДЕК — КОдер-ДЕКодер (также КОмпрессия/ДЕКомпрессия) (CODEC — COder/DECoder (COmpression/DECompression));

БОК — Блок обслуживания канала (CSU — Channel Service Unit);

DARPA — Управление перспективных исследований Министерства обороны (CUJA)(DARPA — Defense Advanced Research Projects Agency (USA));

MO — Министерство обороны (США) (DOD — Department of Defense (USA));

БОД — Блок обслуживания данных (DSU — Data Service Unit);

OCK — Общее соединение для конференции (GCC — Generic Conference Call);

IETF — Рабочая группа инженеров Интернет (IETF — Internet Engineering Task Force);

IP — Интернет протокол (IP — Internet Protocol);

ISDN — Цифровые сети с интеграцией служб (ISDN — Integrated Services Digital Networks); МСЭ-Т — Международный союз электросвязи — Телекоммуникации (ITU-T — International Telecommunications Union — Telecommunications);

ЛВС — Локальная вычислительная сеть (LAN — Loca Area Network);

MK — Многоточечный контроллер (MC — Multipoint Controller):

БМУ — Блок многоточечного управления (MCU — Multipoint Control Unit):

МП — Многоточечный процессор (MP — Multipoint Processor);

NTSC — Национальный комитет телевизионных стандартов (NTSC — National Television Standards Committee);

BOC — Взаимодействие открытых систем (OSI — Open system interconnection);

PHY — Физический уровень (PHY — Physical Layer);

ПТТЛ — Простая традиционная телефонная система (POTS - Plain Old Telephone System);

ИБС    — Интерфейс первичного уровня (PRI — Primary Rate Interface);

QCIF —формат ТВ-изображения. специфицируемый Рекомендациями Н.261 МККТТ (QCIF — Quarter Common Intermediate Format);

9

ГОСТ Р 57377—2016

QoS    — Качество услуг {QoS — Qualityof Service);

RTCP — Протокол управления реального времени (RTCP — Real-Time Control Protocol);

RTP — Транспортный протокол реального времени (RTP — Real-Time Transport Protocol);

RTSP — Протокол потоковой передачи в режиме реального времени (RTSP — Real-Time Streaming Protocol);

СКК    —Сетьс коммутацией каналов (SCN — Switched Circuit Network);

КС56 — Коммутируемая сеть 56 (SW56 — Switched 56 Network).

SMIL — Язык интеграции синхронизированныхмультимедийных данных (SMIL — Synchronized Multimedia Integration Language);

TCP — Протокол управления передачей (TCP — Transmission Control Protocol);

UDP — Протокол дейтаграмм пользователя (UDP — User Datagram Protocol);

ГВС — Глобальная вычислительная сеть (WAN — Wide Area Network).

5 Стандарты мультимедийной конференции

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

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

В дополнение к двухточечной конференции, многоточечная конференция можетбытьустановлена с использованием ЕМУ. ЕМУ также может транслировать конференцию с одного участка на другие.

Установленные стандарты включают в себя;

a)    Н.320 — для видеоконференций через сети с коммутацией каналов, такие как ISDN. Коммутируемая сеть 56 и арендуемые сети.

b)    Н.321 — для мультимедийных конференций всредахВ-ISDN.B-ISDN зависит от переключения ATM. который имеет значительные преимущества в виде гарантированного QoS. Н.321 также вовлекает Н.310 — рекомендацию для систем и терминалов широкополосной аудиовизуальной связи.

c)    Н.322 — для использования оборудования Н.320 в ЛВС с гарантированным QoS (Isoethemet).

d)    Н.323 — комплекс спецификаций для аудиовизуальной связи через сети с коммутацией пакетов, ЛВС и Интернет.

e)    Спецификации Т.120для электронных и аудиовизуальных конференций.

f)    Рекомендации Н.Зххи Т.120 имеют первостепенное значение для приложений телездравоох-ранения в реальном времени.

Стандарты и соответствующие коммуникационные сети продемонстрированы в таблице 1.

Таблице 1 — Сводная информация по стандартам для мультимедийных конференций

Н.320

Н.321

Н.Э10

H.322

Н.323

Н.324

Сеть

Сети е коммутацией канэлое (ISON)

BISON

(ATM)

в-ISDN

(ATM)

Сети с коммутацией пакетов с ЛВС с гарантированной полосой пропускания (например.

Iso-elheinel)

Сети с коммутацией пакетов с ЛВС без га ра нт ироеакной полосы пропускания (например. Интернет)

Аналоговая телефонная коммутируемая сеть общего пользования

Интерфейс

1.400

AAL 1.363

AAL 1.363

I.400

TCP/IP

V.34

сети

AJM 1.361

AJM 1.361

или

V.90

PHY 1.400

PHY 1.400

TCP/IP

Компрессия

Н.261

H.261

H.261*

Н.261

Н.261*

Н.261*

видео

H.262*

H.263

MPEG-2*

Н.263

Н.263*

Компрессия

6.711*

6.711*

G.711*

6.71Г

G.711*

6.723.1*

аудио

0.722

6.722

6.722

G.722

G.722

6.729

6.728

6.728

6.726

6.728

6.723

MPEG-1*

6.728

MPEG-2

6.729

10

ГОСТ Р 57377—2016

Окончание таблицы 1

Н.320

Н.321

Н.310

Н 322

Н 323

Н.324

Сеть

Сети с коммутацией каналов {iSDN)

в-ISON

|АТМ)

в-ISON

(ATM}

Сети с коммутацией пакетов с ЛВС с гарантированной полосой пропускания (например, Iso-othemel)

Сети с коммутацией пакетов с ЛвС без гарантированной полосы пропускания {например. Интернет}

Аналоговая телефонная коммутируемая сеть общего пользования

Денные

T.120

Т.120

Т.120

Т.120

Т.120

Т.120

Т.434

Т.84

Мультиплекс

Н.221

Н.221

Н.221

Н.222

Н.221

Н.225

Н.223

Передаче сигнала

Н.230

Н.242

Н.230

Н.242

Н.230

H.24S

Н.242

Н.230

Н.245

Н.245

Установление

соединения

0.931

0.931

0.2931

Q.931

0.931

V.2S

БМУ

Н.243

Н.243

Н.231

Н.243

Н.231

Н.243

Н.323

н/д

Упрееление камерой

Н.224

Н.281

Н.224

Н.281

Н.224

Н.281

Н.224

Н.281

Н.224

Н.281

Н.224

Н.281

Безопасность

Н.233

Н.234

Н.233

Н.234

Н.233

Н.234

Н.233

Н.234

Н.233

Н.234

Н.235

Н.233

Н.234

H.23S

* Обязательное свойство

5.2 Рекомендации Н.320

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

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

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

На приемном конце линии комбинированные данные декомпрессируются, декодируются и перед представлением видео- и аудиоданных к потоку аудиоданных применяется задержка.

Н.233 и Н.234 определяют конфиденциальность передачи между терминалами Н.320. Н.233 описывает требования кшифрованию и относится ко множеству возможных алгоритмов (Стандарт кодирования данных (DES). быстрый алгоритм шифрования данных (FEAL) и Криптографическая хэш-функ-ция (BCRYPT)). а Н.234 описывает методы аутентификации и управления кодировкой.

На рисунке 1 демонстрируется взаимосвязь компонентов Рекомендации Н.320 и показана связь терминала Н.320с внешними устройствами.

Сами по себе Рекомендации Н.320 не определяют то. как данные должны кодироваться, но может применяться передача собственных данных. Этот недостаток был учтен в стандарте Т.120, но Т.120 является необязательным в Н.320 и может не включаться в оборудование телеэдравоохраиения.

Н.320 определяет коэффициент использования полосы частот в диапазоне от 64 кбит/с до 1920 кбит/с. В пределахэтого диапазона допускаютсятолькоопределенные специфические полосычас-тот. а они ограничены для определенных групп различных каналов ISDN (г. е. для групп по 64 кбит/с для диапазона 64—364 кбит/с. для групп по 384 кбит/с для диапазона 284—1920 кбит/с).

и

ГОСТ Р 57377—2016

«ж

Рисунок 1 — Терминал Н.320

Рекомендации Н.231 и Н.243определяют многоточечные соединения между терминалами Н.320. а то время как Н.231 определяет БМУ, которое служит в качестве моста в многоточечных (трех* или более) соединениях и предоставляет возможности сведения аудио и коммутации видео. Н.243 определяет протокол связи между терминалом Н.320 и БМУ. Два или более БМУ могут быть последовательно подключены, как показано на рисунке 2.

Рисунок 2 — Многоточечная конфигурация

В таблице 2 представлены возможности системы по стандарту Н.320.

12

ГОСТ Р 57377—2016

Таблица 2 — Сводная информаций по рекомендациям Н.320

Свойство

Обязательный мннимуы

Необязательный максимум

Разрешение, пиксель

QCIF (176 * 144)

CIF (352 к288). 2CIF.4CIF

Частота кадров, к/с

ДО 7.5

До 30

Скорость передачи, кбит/с

56/64

2.048

Компенсация движения:

•    кодер, пиксель:

•    декодер

Нет

Дв

Де (поиск 30 х 30 пикселей) Дв

Предвврительная/последующвя обработка

Нет

Расширенная

Кодирование аудио

G.711

G.722. G.728

Электронная конференция Т.120

Нет

Расширенная

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

5.3 Рекомендации Н.321 и Н.310

Рекомендации Н.321 описывают технические спецификации для адаптации узкополосных терминалов. соответствующих Н.320. к В-ISDN. В то время как ISON работает на скорости, равной или меньшей. чем базовая скорость (например. 1.544 Мбайт/с). B-ISON работает на скоростях выше базовой.

Как описано в 1.121, тип передачи — АТМ. при котором данные передаются в виде нескольких блоков фиксированного размера, которые называются ячейки.

АТМ работает в режиме с установлением соединения и обеспечивает QoS. При установлении соединения пользователь уровня АТМ оговаривает требования к QoS трафика. Примерами этих требований может бытьскорость или верхние границы изменения времени задержки, или же потеря ячеек. Сеть распределяет ресурсы в начале сеанса связи для соответствия требованиям QoS. Сеть может не принять соединение, если невозможно поддерживать QoS существующих соединений. В течение всей длительности соединения сеть ограничивает трафик так. чтобы обеспечивалось QoS. В конце соединения ресурсы сети освобождаются.

РисунокЗ отображает обобщенный терминал Н.321.

AAL (уровень адаптации АТМ) улучшает уровень АТМ для поддержки функций, требуемых для предоставления QoS для мультимедийных потоков, включая:

1)    контрольошибокпередачи;

2)    сегментация и повторная сборка информации верхнего уровня в ячейках ATM;

3)    регулирование потери ячеек;

4)    регулирование дрожания при задержке при передаче ячеек;

5)    передача информации о синхронизации.

Терминал Н.321 соответствует требованиям Н.320. Необязательный еидеокодек Н.263. предназначенный для низкоскоростных терминалов, также является частью некоторых терминалов Н.321. так как предоставляет видео высокого разрешения, например. 4CIF и 16CIF. которые являются привлекательными для широкополосных терминалов Н.321.

Рекомендации Н.ЗЮ были разработаны для предоставления терминалов высокого разрешения, способных обрабатывать H.262/MPEG-2 видео и MPEG-1 аудио. Совместная работа терминалов Н.ЗЮ и Н.321/Н.320 является обязательным требованием. Она достигается посредством общего комплекса функций Н.320/Н.321. определенных в Рекомендациях Н.ЗЮ.

13

ГОСТ Р 57377—2016

Область лриююм ян

B4S0N

Рисунок 3 — Терминал К.321

Сети АТМ поддерживают видео, закодированные с переменной битовой скоростью (VBR), позволяющие переданной скорости динамически отражать информационное содержание видеосигнала. Таким образом, кодек VBR может поддерживать постоянное качество передачи потоков мультимедийных данных.

Как показанов таблицей Рекомендации Н.310 включают в себя функциональность Н.321. Поэтому нет необходимости в шлюзах между терминалами Н.ЗЮи Н.321 в B-ISDN.

5.4 Рекомендации Н.323

В1996 году МСЭ опубликовал набор стандартов Н.323 посредством объединения возможностей коммуникаций и конференций в пакетных сетях. ЛВС и сети Интернет/Интранет. Н.323 является комплексным стандартом, который охватывает выбор аудио- и видеокодеков, совместно используемых приложений, управление соединениями и управление системой, обеспечивая функциональную совместимость продуктов Н.323 и Н.320.

Компоненты Н.323 включают в себя:

a)    терминалы для того, чтобы обеспечивать связь в реальном времени и действовать в качестве клиентов в компьютерной сети:

b)    шлюзы для предоставления услуг клиентам Н.323. чтобы те могли осущвсгвлятьсвязьссвтями. не относящимся к Н.323. Услуги, предоставляемые шлюзами, включают в себя:

1)    преобразование между форматами передачи, например, между Н.225 и Н.221.

2)    преобразование между процедурами связи, например, между Н.245 и Н.242. и

3)    установление и завершение соединения для ЛВС и телефонных сетей с коммутацией

каналов;

14

ГОСТ Р 57377—2016

c)    контроллеры шлюза для предоставления услуг терминалам в сети, в частности:

1)    управление полосой пропускания для того, чтобы выделять, управлять и контролировать доступную полосу пропускания для зарегистрированных конечных точек.

2)    преобразование символьного имени в IP-адрес и на оборот, и

3)    сервисы управления для зарегистрированных конечных точек Н.323:

d)    ЕМУ для предоставления возможности сведения аудио и коммутации видео между тремя и более терминалами и поддержки других функций управления, требуемых в многоточечной конференции. таких как переговоры Н.245 между терминалами для установления их способностей по обработке аудио и видео.

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

5.4.1 Терминалы Н.323

Обязательные характеристики терминала Н.323 схожи собязательными характеристиками терминала Н.320. Таким образом, минимальный уровень связи между Н.323 и Н.320 обеспечивается без необходимости в использовании перекодирующих шлюзов. Задержка в приемном тракте обеспечивается для синхронизации аудио и видео и буферизации дрожания.

Рисунок 4 демонстрирует взаимосвязь между компонентами Рекомендаций Н.323 и показывает связи терминала Н.323 с внешними устройствами.

Рисунок 4 — Терминал Н.323

8 таблице 3 представлены Рекомендации Н.323 иТ. 120 для модели взаимодействия открытых систем (ВОС).

15

ГОСТ Р 57377—2016

Таблица 3 — Пакет протоколов Н.323 и Т.120

вое

Аудио

Видео

Контроль и управление терминалом

Данные

Приложения

7

G.711.G.722. G.728. G.723. G.729

Н.261.

Н.263

RTCP Н.225 RAS-канал

Знак

вызова

Н.225

Канал

управления

Н.245

Т.126/Т.127

Т.124/Т.125

Т.122

Презентации

6

Сеансовый

S

RTP

Х.224

Т.123

Транспортный

4

UDP (Ненадежный транспорт)

TCP (Надежный транспорт)

Сетевой

3

IP

Канала данных

2

Управление доступом к среде (IEEE 802.3)

Физический

1

Физический (IEEE 802.3)

Так какаудио- и видеопотоки допускают наличие ошибок, но не допускают задержек, они используют RTP, работающий на более эффективном, но ненадежном транспорте UDP. Большая часть функций по контролю и управлению терминалом и электронные конференции используют надежный транспорт TCP с расширенными механизмами проверки ошибок и проверки доставки данных.

В таблице 4 представлена сводная информация по возможностям системы стандарта Н.323.

Таблице 4 — Сводная информация по Рекомендациям Н.323

Свойство

Обязательный минимум

Необязательный максимум

Разрешение, пиксель

QCIF (176 * 144)

CIF (352 к268). 2CIF, 4 *CIF

Частоте кадров, к/с

До 7.S

До 30

Скорость передачи, кбит/с

56/64

2.048

Компенсация движения. • кодер, пиксель: •декодер

Нет

Да

Дв (поиск 30 н 30 пикселей) Да

Предав рительнвя/последующая обработка

Нет

Расширенная

Кодирование аудио

G.711

G.723 или G.729. если полоса пропускания < 64 кбит/с

G.722. G.728. G.723.1 G.729

Электронная конференция Т.120

Нет

Расширенная

5.4.2 Шлюзы

Шлюз, в соответствии с Рекомендациями Н.246. предоставляет все виды электрического и логического преобразования, требуемые для предоставления связи между Терминалом Н.323 в сети с коммутацией пакетов и Терминалом Н.320 в сети с коммутацией каналов. Некоторые шлюзы могут предоставлять функциональную совместимость с другими типами терминалов, включая Н.324 и Н.310.

Шлюз работает какТерминал Н.323 или БМУвсетис коммутацией пакетов и Терминал Н.320 всети с коммутацией каналов, с функциями преобразования протоколов между ними.

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

16

ГОСТ Р 57377—2016

5.4.3    Контроллер шлюза

Контроллер шлюза предоставляет функции управления сетью для систем Н.323. Он устанавливав ет политики в отношении использования ресурсов сети и осуществляет эти политики, например, предоставление Терминалам Н.323 разрешения на осуществление вызова с использованием полосы пропускания сети определенной емкости.

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

Контроллер шлюза является необязательным компонентом системы Н.323. Однако если он включен в сеть. Терминал Н.323 должен его использовать.

5.4.4    Блок многоточечного управления

БМУ состоит из двух частей: МК и МП. МК отвечает за общие режимы работы переговоров Н.245 между всеми терминалами, а также открытие и закрытие логических каналов для распределения потока данных. МП осуществляет функции обработки потока данных, такие как сведение аудио и коммутация видео, переход от одних кодеков и скоростей к другим, а также многоадресная передача.

Н.323 поддерживает централизованные, децентрализованные и гибридные многоточечные конференции. Централизованные конференции должны использовать БМУ. состоящее из МКи МП аудио- и видеоданных. Все терминалы отправляют потоки аудио, видеоданных и управления на БМУ сиспользо-ванием двухточечной связи. МК централизованно управляет конференцией с использованием функций управления Н.245. а МК осуществляет сведение аудио-, коммутацию видео и распределение данных, и отправляет потоки обработанных данных участникам.

Децентрализованные многоточечные конференции используют многоадресную передачу вместо БМУ. тем самым, участвующие терминалы осуществляют многоадресную передачу аудио и видео без использования БМУ. Однако если в многоточечную конференцию вовлечена электронная конференц-связь. тогда для обеспечения функциональности Н.245 используется МК. а для централизованной обработки совместно используемых данных используется МП. Г ибридные многоточечные конференции используют комбинацию централизованных и децентрализованных характеристик. Некоторые терминалы могут работать в централизованном режиме, другие — в децентрализованном, а БМУ используется для соединения этих двух режимов.

Методы реализации БМУ варьируются от простой системы, предоставляющей возможности для проведения многоточечной конференции для однородных терминалов до сложной системы, способной поддерживать различные типы конференций с неоднородными терминалами и сетями, участвующими в этих конференциях, и предоставляющие современный комплекс функций представления (например, функция продолжительного присутствия) и возможностей для управления конференцией (например, речевое управление, управление ведущим). Эти различия вносят свой вклад в проблемы функциональной совместимости в сетях тепеэдравоохранения.

5.5 Рекомендации Н.324

Рекомендация Н.324 рассматривает и характеризует общий метод одновременного совместного использования видео, голоса и данных с использованием соединения через модем, осуществляемого посредством одной аналоговой телефонной линии (ПТТЛ). Ока также характеризует функциональную совместимость в этих условиях так. чтобы видеотелефоны, например те. что работают по Н.324. смогли подключаться иосуществлять мультимедийный сеанс. Поддержка каждоготипа данных необязательна, но если она обеспечивается, то требуется возможность использовать определенный общий режим, чтобы все терминалы, поддерживающие этот тип данных, могли быть совместимыми.

Рисунок 4 демонстрирует взаимосвязь между компонентами Рекомендаций Н.323 и показывает связи терминала Н.323 с внешними устройствами.

Терминалы Н.324 обычно применяются в отдельных устройствах, таких как видеотелефоны. Они также могут быть интегрированы в персональные компьютеры.

17

ГОСТ Р 57377—2016

I Uowrrop {

камеры |

L______ „„.J

ндешы

г.........1

1 Дмыкаммо- !

Арыояпек

| мырофоиа 1

S____ _ 1

G.723.1

Г----------]

{ данных Г и__________J

V.14 I IAW |

I____________J

УЬрмгиню аиста моя НШ

№нм

PSTN

Рисунок 5 — Терминал Н.324

5.6 Рекомендации Т.120

5.6.1    Обзор Т.120

Рекомендации Т.120 содержат ряд протоколов связи и приложений, а также сервисы, которые предоставляют поддержку многоточечных электронных конференций в реальном времени. Эти много* точечные средства являются важными структурными элементами для целого ряда совместных приложений. включая конференции с использованием настольных компьютеров и многопользовательские приложения.

Обобщенный обзор стандарта Т.120 представлен на рисунке 6.

5.6.2    Состав уровня Т.120

Т.120 состоит из нескольких уровней:

a)    уровень транспортного протокола поддерживает характерный для сети стек транспорта для каждой поддерживаемой сети, такой как ISDN. ПТТЛ. ЛВС и Интернет:

b)    Сервисы многоточечной конференции (MCS. Т.122/Т.125) предоставляют транспортные соединения, ориентированные на многоточечные подключения;

c)    Универсальное управление конференцией (GCC. Т.124) предоставляет сервисы для установления и завершения конференций, управления конференциями, работы с реестрами приложений и общего проведения конференции. GCC также осуществляет согласование между совместным использованием данных и аудио/еидео в многоточечных конференциях:

d)    Универсальный шаблон приложения предоставляет руководство для развития протоколов приложения Т.120 иотвечает за управление событиями уровня сети, включая управление подключениями. участниками конференций, а также данными конференции:

e)    Подуровень протокола может включать в себя:

1)    многоточечный протокол Т.126 для статического изображения и аннотации для совместного использования данных,

2)    многоточечный протокол передачи двоичных файлов Т.127 для передачи файлов в многоточечной конференции или

3)    протокол совместного использования приложения T.Share для разрешения совместного использования приложений участниками конференции Т. 120.

Контроллер узлов, показанный на рисунке 6. является объектом управления и контроля для Т.120и отвечает за руководство событиями уровня сети, включая управление подключениями, участниками конференций, а также данными конференции. Этот контроллер принимает управление другими уровнями Т.120, в частности транспортным уровнем, и использует GCC. MCS и другие сервисы протокола для

18

ГОСТ Р 57377—2016

Рисунок 6 — Рекомендадии Т.120

управления всей конференцией. Контроллер узлов действует как транслятор, обеспечивая то. что события правильно упорядочены и интерпретированы. Сам по себе контроллер узлов не входит в область применения Рекомендаций Т.120.

5.6.3 Функциональная совместимость Т. 120

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

Функциональная совместимость продуктов Т.120 измеряется на двух уровнях: на уровне сети и на уровне приложений. Стандарты Т.122. Т.123. Т.124 и Т.125 составляют уровень сети Т.120. Изделия и сервисы, соответствующие этим стандартам, имеют необходимую инфраструктуру для того, чтобы:

a)    устанавливать и поддерживать конференции не зависимо от платформы:

b)    управлять множественными участниками и программами и

c)    точно и безопасно отправлять и получать данные через различные поддерживаемые сетевые подключения.

19

ГОСТ Р 57377—2016

Стандарты Т.126 и Т.127 составляют уровень приложений Т.120. Эти стандарты гарантируют, что электронная доска и приложения, разработанные по Т.120, могут взаимодействовать на разных плат* формах и в разных сетях, а также в ходе многоточечных конференций.

Т.120 решает проблему недостатка стандартизации для сервисов данных Н.320/Н.323. С использованием Рекомендаций Т.120 возможно спроектироватьсереисы для электронных конференций, которые будут совместимы с оборудованием от различных поставщиков через неоднородные сети (с коммутацией каналов, с коммутацией пакетов, с сотовой коммутацией и ЛВС).

Однако реализации, основанные на Т.120, до сих пор не могут предоставить сервисы высокого качества для аудио- и видеоконференций вместе с сервисами электронных конференций. Разделение аудио, видео и данных на отельные сервисы, при котором аудио и видео рассматриваются совершенно по-разному, не оправдано с точки зрения приложений телездравоохранения.

6 Приложения телездравоохранения

6.1    Общие сведения

Системы телездравоохранения, как определено в настоящем стандарте, способны обрабатывать различные типы данных, включая:

a)    аудио — обычно представлен как одномерный массив, например, речь, звуки сердцебиения при различных уровнях напряжения;

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

c)    числовые значения — целые числа или числа с плавающей точкой, полученные при прямых измерениях, например систолическое и диастолическое давление, объем крови, или расчеты, например, средний вес:

d)    векторы (форма колебания) — представлены в виде одномерных массивов значений, полученных при прямом измерении, например, е электрокардиограммах, или при расчетах, например, кривая объема левого желудочка, гистограмма;

e)    изображения — двумерный массив целых чисел, иногда чисел с плавающей точкой, например. цифровые рентгенограммы и МРТ-изображения;

f)    динамические ряды — ряд многомерных массивов, синхронизированных по времени, например. анимации ангиографии и анимации МРТ;

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

h) текст — свободный текст, состоящий из строк, целых чисел или чисел с плавающей точкой, например, индивидуальные данные пациента, метки и аннотации; и

<) документы — структурированный текст, подходящий для компьютерной обработки, например, записи врача и отчеты об интерпретации данных. Документ, содержащий структурированный текст, может иметь пометку с указанием его порядка, структуры, схемы и формата. Примеры включают в себя документы в формате HTML или XML.

Системы телездравоохранения могут обмениваться любым сочетанием вышеуказанных типов данных в виде асинхронного или синхронного трафика.

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

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

6.2    Телеобучение

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

20

ГОСТ Р 57377—2016

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

Таблица 5 — Сводная информация о функциональности системы телеобучения

Функция

Тнл/источник данных

Размер, Мв или полоса пропускания. кби|/с

Стандарт полирования

Прием, кодирование и сжатие видео

Вкдео/видеокамера

Видео/документчсвмера

64—2000"

Видеостандарты Н.26х

Кодирование и сжатие предварительно записанного видео

Видео/видеомагнитофон

64—2000*’

Видеостандарты Н.26х

Устное общение в реальном времени

Аудио/микрофон

2.4—14Ю*1

Аудиоствндврты G.7xx

Предварительно записанное устное общение

Аудио/видеомагнитофон

2.4—1410*'

Аудиостандарты G.7xx

Прием, кодирование и передача статических изображений. Передача двоичных файлов. Совместное использование приложений.

Обмен текстовыми сообщениями

Двоичный файл/разное (например. видеокамера, документ-камера. цифровая камере, сканер)

64—2000*’

Стандарты многоточечной передачи данных Т.120

Управление системой

Команда управления/кодек

3.5—350*'

Стандарты по сигнализации Н.230 H.242/H.24S

Многоточечная конференция

Команда управления/кодек

Стандарты по проведению сеансов

безопасность

Кодек, ориентированный на алгоритм обеспечения защиты или специализированный прибор системы защиты

Стандарты шифрования Н.233/Н.234

*' 8 зависимости от коэффициента сжатия и качества сигнала.

6.3 Телеконсультация

Система телеконсультации упрощает предоставление специальных услуг (например, психическое здоровье, кардиология или дерматология) работниками здравоохранения, пациентам и/или участковым врачам. Обычно система предоставляет возможности проведения мультимедийных конференций в реальном времени наряду с возможностью работы с медицинскими специализированными потоками данных (например, тоны сердца и легких, ЭКГ. видео и неподвижные изображения, полученныес использованием специализированных приборов).

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

Таблица 6 — Сводная информация о функциональности системы телеконсультациии

Функция

Тип/источмик данных

Размер. Мв или полоса пропускания, кбит/с

Стандарт кодирования

Кодирование и сжатие видео

Видео/видеокамера

Видео/документ-камера

64—2000*’

Видеостандарты Н.26х

Кодирование и сжатие предварительно записанного видео

Видео/видеомагнитофон

64—2000*’

видеостандарты Н.26х

21

ГОСТ Р 57377—2016

Окончание таблицы 6

Функция

Тип/источинк данных

Размер. МВ или полоса пропускания, *6ит/с

Стендер! кодирования

Устное общение е реальном времени

Аудио/микрофон

2.4—1410*'

Аудиостандарты 6.7хх

Предварительно записанное устное общение

Аудио/видеомагнитофон

2.4—1410“

Аудио стандарты G.7xx

Статические изображения. Передача двоичных фвйлоа. Совместное использование приложений.

Обмен текстовыми сообщениями

Двоичный файл/рвзное (например, специализированный прибор, видеокамера. цифровая камера)

64—2000*'

Стандарты многоточечной передачи данных Т.120

Прием и передача тонов сердца и легких

Аналоговые звуковые сигнал ы/ахустический стетоскоп или Цифровые сигнвлы/циф-ровой стетоскоп

Меняется

Аудио стандарты С.7хх или стандарты передачи данных Т.120

Прием и передача ЭКГ

Сигналы форм колебв-ний/системв ЭКГ

Меняется

Собственной разработки

Управление системой

Команда упрввления/ко-дек

3.5—350“

Стандарты по сигнализации Н.230 Н.242/Н.245

Многоточечная конференция

Команда улравления/Ко-дек

Стандарты по проведению сеансов

Безопасность

Кодек, ориентированный на алгоритм обеспечения защиты или специализированный прибор системы защиты

Стандарты шифрования Н.233/Н.234

а> В зависимости от коэффициента сжатия и качества сигнала.

7 Проблемы функциональной совместимости

7.1 Общие сведения

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

Отношения между сторонами, вносящими вклад в вопросы функциональной совместимости, показаны на рисунке 7.

Рекомендации Т.Зхх и Т.120, разработанные МСЭ-Т, переработаны в набор технологий реализации. Разработчики используют эти технологии для разработки изделий мультимедийных конференций. Так как стандарты предоставляют только платформу разработки и не определяют конкретные реализации, разработчики используют технологии реализации для создания изделий, соответствующих Т.ЗххЯ.120 и обладающих уникальными дополнительными характеристиками. Разработчики сетей, системные интеграторы и поставщики услуг выбирают из множества этих изделий такие, которые для реализации системы телездравоохранения способны предоставлять услуги мультимедийной связи.

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

Настоящий стандарт рассматривает три источника проблем функциональной совместимости в сетях телездравоохранения:

1) стандарты или рекомендации, разработанные МСЭ-Т и другими стандартизующими организациями:

22

ГОСТ Р 57377—2016

Рисунок 7 — Стороны, вносящие вклад в вопросы функциональной совместимости

2)    технологии реализации и изделия телездравоохранения;

3)    технологии телеэдравоохранения, которые фактически реализованы изделиями телездравоохранения. связанными через коммуникационные сети.

7.2 Источники проблем функциональной совместимости, связанные со стандартами

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

7.2.1 Свободная адаптация предыдущих протоколов

Одним из требований к новым спецификациям является совместимость с более ранними и общепризнанными стандартами, например. Рекомендации Н.323должны быть совместимы с Рекомендациями Н.320. однако новые спецификации должны учитывать уникальные требования новой предметной области, например. Н.323 должен включать в себя требования пакетных сетей. Достаточно часто составляющие более ранних спецификаций модифицируются с целью включения характеристик новой среды в свободной манере.

Пример — 0.937.

Данный протокол сигнализации для управления вызовами был позаимствован из ISDN и впоследствии изменен для использования в изделиях Н.323. При использовании в Н.323 сохранялась схема оригинального протокола Q.931. но были переопределены значения многих полей для Н.323. Кроме того, многие поля в ориеинальном протоколе Q.931 остаются неопределенными для Н.323. Гем не менее, существуют попытки использования зтих полей именно в том виде, в котором они используются в ISDN. Разработчики, работающие над Н.323. невольно интерпретируют и настраивают Q.931. потому что пакетные сети по определению являются сетями без маршрутизации информации и опираются на разные архитектуры с использованием совершенно разных компонентов и процедур. Когда изделия используют оригинальную реализацию Q.931 и запускают ее. как часть реализации Н.323. они не могут соответствовать Н.323 в строгом понимании стандарта.

23

ГОСТ Р 57377—2016

7.2.2    Свободно определенные методы кодирования и декодирования

Часть существующих проблем функциональной совместимости можно было найти еще и в том. как стандарт Н.323 был определен. Н.323 объединяет Н.225, RTP и RTCP. Каждый из этих протоколов должен быть закодирован е соответствии с согласованной формулой.

Пример — Н.225 в сравнении с RTP/RTCP.

Н.225 основывается на языке ASN.1 для кодирования и декодирования. При атом RTP и RTCP. взятые из IETF, основаны на формуле TLV (тип-длина-значение). Это ведет к проблемам функциональной совместимости среди изделий мультимедийных конференций, использующих эти разные формулы кодирования и декодирования.

7.2.3    Противоречивое определение обязательных/иеобязательных требований

В то время какспецификации для необязательных компонентов являются полными, определение того, как и когда их использовать, является гораздо менее точным. Это ведет к реализации различных поднаборов Рекомендаций Н.32х/Т.120 и. как следствие, к проблемам с функциональной совместимое* тью систем телездравоохранения.

Примеры

1    RTP/RTCP.

Эти протоколы одобрены IETF перед разработкой Н.323. R7P/RTCP является продуманным протоколом с большим количеством элементов и полей для обязательных и дополнительных процедур (особенно RTCP), которые частично накладываются на друеие протоколы, определенные в рамках Рекомендаций Н.323. Некоторые раэработ чики придерживаются руководств RTCP. друеие же придерживаются Н.323 и моеут выбрать пропустить определенные поля при реализации стандарта. Поэтому, одна реализация может отличаться и не соответствовать друеим реализациям, что ведет к проблемам функциональной совместимости. Например, в RTCP поле яспате* присваивает уникальное имя потокуданных и является обязательным, в Рекомендациях Н.323 это поле является излишним. В Н.323 идентификация и ассоциация потока осуществляется посредством Н.225 (с использованием Н.245). Некоторые совместимые с Н.323 изделия не используют поле «слете». Друеие изделия, придерживающиеся ориеинальных RTP/RTCP, ожидают использования этоео поля в сообщении. Это препятствует функционально совместимой работе систем.

2    Выбор аудиокодеков.

Н.323 предписывает, что, если доступная скорость вышеб4кбит/с, елавным (основным) кодеком является 0.711. С друзой стороны, если доступная скорость ниже 64 кбит/с. то правиле меняются. В частности, если это аолосовой вызов, то аудиокодеком должен быть G.729. а если при соединении используется вудио и видео, то кодеком является G.723 (G.723 сильнее сжимает аолос и использует меньшую полосу пропускания, чем 0.729 или Q.711, оставляя больше места видео части соединения;.

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

7.2.4    Пробелы в рекомендациях

Полнота стандартов является широко известной проблемой, при этом последующие выпуски Рекомендаций Н.323/Т.120 имеют пробелы в определении важных характеристик.

Примеры

1    Безопасность.

Н.323версии1. исправленная в 1995 воду, не в полной мере рассматривала безопасность. Ранее разработчики рассматривали возможность использования характеристик безопасности, определенные на уровне IP. впоследствии был разработан новый стандарт Н.235. как часть Н.323 версии 2 стандарта. Аспекты безопасности изделий, соответствующие Н.323 версии 1. вероятно, не являются функционально совместимыми с характеристиками безопасности изделий. соответствующихН.323версии 2.

2    Мультиплексная передача.

В настоящее время нет определений функционально совместимой мультиплексной передачи потоков данных в Рекомендациях Н.323 или в R TP/RTCP. Хотя некоторые предложения обсуждались и на форуме VoIP, и в IETF. на настоящий момент определенноео решения не существует. Пока не будет оговорена стандартная методика, такая ситуация будет источником проблем для функциональной совместимости в будущем.

7.2.5    Отсутствие спецификаций для кодирования данных в Рекомендациях Н.320/Н.323

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

24

ГОСТ Р 57377—2016

Пример— Н.32хиТ.120.

В Рекомендациях Н.320/Н.323 не даны спецификации для кодирования данных, поэтому часто при-меняется способ передачи данных собственной разработки. Спецификации для кодирования данных включены в Рекомендацию Т.120, но Т.120 не является частью Н.320/Н.323 и не обязательно реализуются в системах телездравоохранения.

7.2.6    Совершенствование Рекомендаций Т.120

Рекомендации Т.120 рассматривают недочеты в рекомендациях Н.320 и Н.323. а именно отсутствие стандартизации сервисов электронных конференций и недостаток надежного и универсального протокола передачи данных, не зависимого от базовой сетевой инфраструктуры и передаваемых данных. Назначением Рекомендации Т.120 не является обозначение интерфейса программирования приложений для разработки приложений или определение конкретных функций на уровне приложений. Акцент делается на стандартизацию уровня протокола передачи данных, т. е. информации, передаваемой и принимаемой по сети.

При осторожном использовании рекомендаций Т.120, можно проектировать сервисы для аудио-, видеоконференций и электронных конференций, которые будут взаимодействовать между различными поставщиками оборудования в сетях с коммутацией каналов (например. ISDN) или сетях с коммутацией пакетов (например, технология ретрансляции кадров Frame Relay). Тем не менее, есть еще несколько областей, где проблемафункциональной совместимости для стандартов. совместимыхсТ.120(и последующих совместимых с Т.120 продуктов), должна быть тщательно изучена. Они включают в себя спецификации для:

•    T.Sound — передача аудиообъектов;

•    T.MPTV — передача визуальных объектов в формате MPEG;

•    T.PRIV — сервисы шифрования связи приложений и

•    T.RDC — удаленное управление устройством. Предоставляются механизмы для управления удаленными камерами и аудиоустройствами (например, громкость звука). Спецификации для контроля и управления другими устройствами (например, видеомагнитофонами и сканерами) все еще находятся в разработке. Кроме того, в стадии рассмотрения находятся управление и контроль сетевых устройств, таких как ЕМУ. шлюзы и коммутаторы.

7.2.7    Свободно определенные спецификации для ЕМУ

Большинство ЕМУ обеспечивают поддержку видео, аудио и данных Т.120. Однако некоторые из них поддерживают только поднабор аудиокодеков (например. G.711 и G.722). обеспечивая в качестве замены перекодирование. Этот подход может привести к некоторой задержке или потере качества. Некоторые из них могут сводить звуковые данные только в форме полудуплекса.

7.2.8    Совершенствующиеся/иеопределениые спецификации для шлюзов и контроллеров шлюзов

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

Примеры

1    Различные возможности.

Шлюз может быть очень простым и обрабатывать только одно соединение между сетью с коммутацией пакетов и сетью с коммутацией каналов. Он также может быть очень сложным, обрабатывая множество одновременных соединений, выполняя перекодирование видео- и аудиопотоков и взаимодействуя с несколькими различными сетями с коммутацией каналов. Он может также включать в себя друеие функции, такие как функции контроллера шлюза или ЕМУ.

2    Неопределенные соединения между контроллерами шлюзов.

Разрешение адреса для конкретных тополовий определено в Н.323. В Н.323 v.2 концепция псевдонимов была расширена для поддержки различных схем адресации. Список Н.323 v.1 был расширен новыми форматами Н.323 v.2. Тем не менее, четко определенного способе взаимодействия контроллеров шлюзов с обоими из атих схем нет, а также в стандарте не указано, должны ли они быть объединены при связисдруеим контроллером шлюза. Это приводит к проблемам с функциональной совместимостью.

7.2.9    Свободно определенное управление полосой пропускания

И Н.320. и Н.323 поддерживают функции совместного использования полосы пропускания, т. е. доступная полоса пропускания делится между видео, аудио и данными. Тем не менее, распределение

2S

ГОСТ Р 57377—2016

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

7.2.10 Плохая стандартизация медиаконференций

Рекомендации Т.120 для сервисов многоточечной связи (MCS). общего соединения для конференции (GCC). и обобщенного шаблона приложений (GAT) плохо стандартизированы, поэтому многие детали реализации оставлены для интерпретации.

Пример — Определение MCS через множество коммуникационных стеков.

UCS сосредоточены только не передаче данных и иенорирует передачу аудио и видео. Разделение видео, аудио и денных в различных сервисах, учитывая, что аудио и видео не являются частью спецификации, не приемлемо с точки зрения приложений. /Громе тоео. жесткая модель управления вызовами GCC может также отражать важный стиль конференций, но. вероятно, будет являться оераничите-лем для приложений телездравоохранения.

7.3 Источники проблем функциональной совместимости, связанные с изделием

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

7.3.1    Задержка между появлением стандартов (постоянно развивающихся) и изделий

Обратная совместимость требуется МСЭ-Т. В то время как каждая новая версия рекомендаций

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

Пример — Ассоциация между протоколами Н.323.

вопрос связывания (или ассоциации) сообщений и протоколов Н.323 в рамках тово же вызова в Н.323 и Н.323 v.1 v.2 решается по-разному. В Н.323 v.1 исполнители моеут выбрать один из двух вариантов при осуществлении ассоциации между различными сообщениями в различных протоколах. Они моеут использовать:

a)    ориеинальные поля Q.931 — ConterencelD и CRV и

b)    поля для управления вызовами источника и назначения Address и AnswerCatl. определенные в сервере уделенного доступе fAASJ и Q.931.

В Н.323 v.2, ассоциация сообщений различных протоколов определяется еорездо точнее с использованием Callldentltler. Поле Callldentltler было добевлено во все протоколы Н.323, в результате чеео каждое сообщение, принадлежащее тому же вызову, является идентифицируемым и очевидным. Наборы сообщений лееко •ассоциируются» со своими партнерами. Еще одно преимущество переходе к Callldentltler заключается в том. что новея методике охветыввет все тополоеии, что в перспективе упрощает жизнь разработчикам и исполнителям.

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

7.3.2    Реализация различных подкаборов стандартов

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

Пример — Ускоренная реализация.

Некоторые изделия Н.323 моеут не поддерживать некоторые из характеристик, зависящих от пропускной способности сети. Н.323. таких как видеокодек Н.263. и еудиокодвк G.723.1. Кроме тоео, в

26

ГОСТ Р 57377—2016

Н.263 есть несколько различных «вариантов* Н.263. а именно: Н.263 (проект;. Н.263 (окончательный) и Н.263 *. Внедрение только обяаательново видеокодека Н.261 на основе ISDN и аудиокодека G.711 или друеой версии кодека Н.263 приводит к проблемам с функциональной совместимостью.

7.3.3 Собственные разработки

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

7.4 Источники проблем функциональной совместимости, связанные с реализацией

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

7.4.1    Неопределенные спецификации для связи с контроллером шлюза

Как указано выше, связь между контроллерами шлюзов не определена в Н.323 v.2.

Пример — Разрешение адреса.

Разрешение адреса определяется в Н.323 для конкретных тололоеий. В Н.323 v.2 концепция псевдонимов была расширена для поддержки различных схем адресации. CnucoxH.323v.1 был расширен новыми форматами Н.323 v.2. Тем не менее, нет четко определенного способе работы контроллеров шлюзов с обоими иззтих схем, а стандарт не указывает, должны ли они быть скомбинированы при осуществлении связи с друаим контроллером шлюза. Сетевые разработчики ищут общие решения для решения зтой проблемы. Гем не менее, хоада реализуются различные схемы разрешения адресов, это приведет к проблемам с функциональной совместимостью.

7.4.2    Связь шлюза с контроллером шлюза

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

a)    сообщения между шлюзом и контроллером определяются с помощью RAS. Шлюз сообщает, какую он имеет полосу пропускания, какие интерфейсы в сети с коммутацией каналов может предоставить для связи/пользователей. и то, какие префиксы необходимо набрать, чтобы получить доступ к конкретному сервису:

b)    когда вызывающий терминал хочет пройти через шлюз, то явным образом запрашивает у контроллера шлюза доступ к шлюзу. Это необходимо, чтобы терминал знал, какие услуги он хочет получить в рамках разрешения адреса и полосы лропускания/качества обслуживания. Запрос передается из пользовательского интерфейса сетевым объектам с использованием RAS и сигнализации вызова Q.931.

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

7.4.3    Децентрализованная многоточечная конференция

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

a)    в 0.931. Н.245 или в обоих из них нет спецификаций о том. кто должен давать команды;

b)    нет спецификаций для терминалов, как определять, какие многоточечные режимы поддерживаются.

Разработчики решений в области телездравоохранения реализовали различные решения для решения этих проблем. Однако это ведет к проблемам функциональной совместимости.

27

ГОСТ Р 57377—2016

8 Требования функциональной совместимости

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

Функциональная совместимость имеет различные значения в зависимости от того, какой уровень в архитектурной модели рассматривается:

•    взаимосвязанность — неразрывное соединение различных сетей в глобальной инфраструктуре;

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

•    взаимообмен и интерпретация — поддержка взаимозаменяемой информации и интерпретация этой информации, зависящая от бизнес-контекста, между различными приложениями.

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

Функциональная совместимость может быть достигнута множеством способов, включая:

-    внедрение системных и сетевых компонентов, которые взаимодействуют на желаемом уровне:

-    внедрение шлюзов, трансляторов или мостов, позволяющих достигнуть функциональной совместимости несопоставимых систем:

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

Данный раздел описывает требования к взаимодействующим решениям, использующим первые два подхода.

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

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

28

ГОСТ Р 57377—2016

Системы телеэдравоохранения соединены между собой через различные каналы связи или сети (например, сети с коммутацией каналов, с коммутацией пакетов, телефонные сети или беспроводные сети).

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

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

a)    установление вызова;

b)    получение, обработка и передача мультимедийного контента в режиме полного дуплекса или полудуплекса:

c)    управление ближними и удаленными устройствами и

d)    завершение вызова.

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

8.2    Установление вызова

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

В самом деле, в сетевой среде ISON вызов устанавливается с помощью D-канала. Впоследствии один В-канал открыт для двунаправленной связи для передачи структуры данных о кадре Н.221. Это позволяет понимать значение битов посредством отношения каждого их положения в кадре. В этот момент запускается терминал для работы в аудиорежиме. На следующем этапе терминалы меняются своими возможностями, в ходе чего каждый терминал определяет режимы, которые он способен поддерживать. Если необходимо использовать дополнительные каналы, то терминал, который установил начальное соединение, настраивает дополнительные каналы. После установления каналов, которые необходимо использовать, терминалы переходят на обычный режим работы, оговоренный ранее (согласно Н.242) и каналы синхронизированы для компенсации разницы в задержке между участвующими каналами.

Системы телеэдравоохранения. работающие всетях на основе IP. используют эту функцию совершенно по-разному. Они используют IP-адреса вместо телефонных номеров и передают параметры управления конференции с помощью TCP/IP. Они используют формат передачи Н.225 и процедуру связи Н.245 для передачи сигналов, регистрации, допуска, пакетирования, мультиплексирования/ демультиплексирования и синхронизации мультимедийных потоков.

Для обеспечения функциональной совместимости между различными системами и типами сетей телеэдравоохранения. системы телеэдравоохранения должны быть в состоянии:

a)    устанавливать вызов посредством различных поддерживаемых сетевых подключений:

b)    определять, могут ли продукты телеэдравоохранения открывать каналы и передавать данные после установления вызова;

c)    принимать вызов посредством предустановленных кодеков и оговаривать подходящий набор кодеков: и

d)    обеспечивать правильную работу всей последовательности управления.

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

8.3    Получение, обработка и передача мультимедийных данных

Как указано в таблице 1. поддержка аудио-, видеокодеков и кодеков данных значительно различается в системах телеэдравоохранения. совместимыхс различными Рекомендациями Н.Зхх. Реализации этой функции существенно различаются во всех трех аспектах: системах телеэдравоохранения. типах мультимедийных данных и типах сетей.

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

29

ГОСТ Р 57377—2016

Для обеспечения функциональной совместимости между различными системами телездравоох-ранения, типами мультимедийных данных и типами сетей, изделия тепеэдравоохранения должны быть в состоянии:

a)    поддерживать получение, кодирование/конеертацию. компрессию и передачу различных типов медиаданных, определенных в стандартных рекомендациях (например, Н.323) в месте отправки;

b)    поддерживать получение, декомпрессию, декодирование/конвертацию и представление типов медиаданных, определенных в стандартных рекомендациях (например. Н.323) в месте получения;

c)    адаптироваться к различным скоростям передачи в случае, когда системы взаимосвязаны посредством различных сетей, например. ISDN и коммутируемой сети 56 (согласование скоростей);

d)    адаптироваться к различиям в режиме кодека (например, аудиорежиме) для ц-эзкона и А-зако-HaeG.711;

e)    поддерживать выбор источников аудио, видео и данных:

f)    комбинировать (мультиплексировать) и разделять (демультиплексировать) управляющую информацию ираэл ичные типы данных(например.аудио, видео и данные)вместеотправкииполучения соответственно;

д) поддерживать электронные конференции с использованием стандартов МСЭ-Т серии Т.120 совместно с режим видеоконференции, включая:

1)    передачу данных.

2)    обмен текстовыми сообщениями.

3)    обмен через доску сообщений.

4)    совместное использование приложений;

h) увеличить доступную полосу пропускания (например, через соединение нескольких каналов в сетях с коммутацией каналов) в целях оптимизации качества передаваемых данных.

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

8.4    Управление ближними и удаленными устройствами

Эта функция включает в себя:

a)    способность выбирать локальные или удаленные аудио- или видеоисточники;

b)    способность контролировать локальные или удаленные видеокамеры в рамках осуществления функций «пакорама/наклон/эум» (PTZ);

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

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

8.5    Завершение вызова

Как и в случае установления вызова, фактическая реализация этой функции зависит от типа сети, используемой для связи участвующих систем тепеэдравоохранения. В среде ISDN, терминал, который инициирует завершение вызова, отправляет сообщение о разъединении через D-канал, а затем переводит в режим ожидания все каналы так, что информация больше не передается. Фактическое отключение и освобождение сетевых каналов происходят после получения сообщения об отключении. IP-сети обрабатывают функцию завершения вызова посредством отправления параметров управления через TCP/IP.

Эта функция включает в себя:

a)    запуск отключения терминалом, участвующим в сеансе телеэдравоохранения;

b)    завершение соединения и освобождение сетевых ресурсов.

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

9 Функциональная совместимость в неоднородных сетях

телездравоохранения

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

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

30

ГОСТ Р 57377—2016

совместимых с Н.32х систем, предоставляющих мультимедийные сервисы в сетях с коммутацией пакетов и в сетях с коммутацией каналов.

9.2 Функциональная совместимость систем Н.320 в сети типа Frame Relay Совместимые с Н.320 устройства были разработаны для работы в сервисах с коммутацией каналов. таких как ISDN или соединение по выделенной линии. Однако, иногда есть необходимость в интеграции видеосервисов, основанных на Н.320. есущестеующие решения по передаче данных и голоса по сети типа Frame Relay. На рисунке 9 изображены сети, состоящие из совместимых с Н.320 терминалов. встроенных в существующие услуги передачи данных и голоса.

Терминал

н.320

LAN

Блок

формирования

видеокадров

Ковам

ДОС

*3

—f—1

Блок формирования видеокадров

Терминал

Н.320

Блок

формирования

видеокадров

Терминал

Н.320

LAN

Рисунок 9 — видеосерейсы Н.320. встроенные в существующие сети передачи данных

и голоса по технологии Frame Relay

Для предоставления видеосервисов посети типа Frame Relay, требуется несколько дополнительных компонентов, а именно блок формирования видеокадров и переключатель доступа. Блок формирования видеокадров предоставляет возможность конвертировать непрерывные потоки данных Н.320 в пакеты Frame Relay. Переключатель доступа обеспечивает локальную связность и возможности переключения для нескольких потоков данных. В то время как вышеуказанное обеспечивает функциональную совместимость на уровнях связности и передачи данных, существует два возможных технических вопроса, которые могут повлиять на качество пакетированного оцифрованного видео:

• дрожание или - пропущенные кадры.

8 приложениях по выделенной линии с использованием мультиплексирования с временным разделением (ТОМ), фазовое дрожание не является проблемой, так как видеокадры поступают в известные, предсказуемые интервалы. Тем не менее, сети типа Frame Relay позволяют использовать кадры переменной длины, приводящие к переменным и непредсказуемым вариантам задержки или дрожания. Если это дрожание превышает способность приемного устройства его компенсировать при помощи буферизации, то качество видео ухудшается.

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

31

ГОСТ Р 57377—2016

превышают гарантированную пользователем скорость передачи данных (CIR). Другими словами, если сервис Frame Relay настроен на CIR со скоростью 128 кбит/с. но фактический пакет данных передается при 192 кбит/с. то кадры, которые превышают CIR в 128 кбит/с. будут отбрасывать набор битов. Если какой-то промежуточный коммутатор в сети становится перегруженным, то эти кадры могут бытьотбро-шены. В то время как случайный пропуск кадра может вызвать щелчки или треск в аудио и некоторую пик-селизацию видео, слишком много пропущенных кадров вызовет заметные потери в качестве видео.

Существует несколько методов обеспечения качества видео в сетях типа Frame Relay. Один из них заключается в настройке размера кадра для оптимальной производительности сети. Другой способ заключается в использовании механизмов QoS. таких как схема упорядочивания трафика для любых каналов, передающих видео через устройство доступа к сети с ретрансляцией кадров (FRAD) на определенном идентификаторе канала передачи данных (DLCI). Этот способ, однако, требует детального анализа и контроля трафика, за которым следует тщательная настройка работы сети типа Frame Relay.

9.3 Функциональная совместимость систем, совместимых с Н.Зхх в неоднородных сетях

Для обеспечения функциональной совместимости различных конечных устройств и сетей передачи данных необходимо несколько основных устройств: шлюз, контроллер шлюза и ЕМУ. На рисунке 10 изображены сети телездравоохранения, состоящие из терминалов, совместимых с Т.120, и различных Н.Зхх Рекомендаций, соединенных между собой различными сетями.

Шлюз и контроллер шлюза играют важную роль в обеспечении неразрывности взаимосвязанности терминалов. Шлюз соединяет конференции на основе Н.323 с другими сетями, протоколами связи и мультимедийным форматом. В этом случае он объединяет терминалы Н.323 с терминалами Н.320 по ISDN, терминалы Н.324 по ПТТЛ итерминалы Н.310 no 8-ISDN/ATM. Услуги, предоставляемые шлюзом, включают в себя:

a)    установление вызова для участвующих терминалов:

b)    трансляцию между процедурами связи (например, Н.245 и Н.242);

c)    трансляцию между форматами передачи (например. Н.225 и Н.221):

d)    трансляцию между аудио- и видеокодеками:

e)    завершение вызова.

9.3.1    Функции контроллера шлюза

Контроллер шлюза осуществляет следующие важные функции:

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

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

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

d)    управление зонами для облегчения регистрации терминалов, шлюзов и ЕМУ в зоне контроллера шлюза. Эго облегчает реализацию политик в отношении группирования участков телездраеоохране-ния.

9.3.2    Функции ЕМУ

ЕМУ поддерживает конференции между тремя и более терминалами. Он предоставляет следующие функции:

a)    хранение и управление спецификациями участка телездравоохранения, включая скорость передачи, доступ к сети, параметры конференции и поддержку режимов видео/аудио/данных (Н.323/Н.320, Т.120);

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

32

ГОСТ Р 57377—2016

Терминал

Видеотелефон IP    н.323

Терминал

Н.323

БМУ

Термтал

Н.320

Сеть

B-ISDN

АТМ

Телефонная

сеть

I

Терминал

Н.320/Н.321

Видеотелефон Н.324

Рисунок 10 — Взаимосвязанность в среде неоднородных систем и сетей

c)    планирование и возможность управления календарными событиями, включая обнаружение и разрешение конфликтов;

d)    установление вызова для облегчения автоматизации создания конференции, включая;

1)    набор номера участников.

2)    способность принимать вызовы участников, имеющих коммутируемый доступ к БМУ. и

3)    смешанный коммутируемый доступ и набор номера;

e)    поддержка следующих режимов/кодеков аудио» и видеоконференций для облегчения процесса получения, обработки и передачи характерных для сервиса типов данных телездравоохранения. К ним относятся;

1)    видеоконференции Н.32х и

2)    аудиоконференции G.7xx;

f)    поддержка электронных конференций с использованием Рекомендаций Т.120, включая:

1)    передачу файлов.

2)    обмен сообщениями.

3)    обмен через доску сообщений и

4)    совместное использование приложений;

33

ГОСТ Р 57377—2016

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

h)    возможности согласования скоростей, позволяющие терминалам с различными скоростями передачи (например. 256.364 и 448 Кбит/с) участвовать в конференции и поддерживать свои собственные скорости и связанный с ними уровень качества видео/аудио;

i)    функции управления медиаданными для облегчения предоставления услуг телеэдравоох-ранения на нескольких участках. Перечень этих функций включает в себя:

1)    контроль медиаданных и маршрутизация (например, контроль одноадресной и многоадресной передачи).

2)    коммутация и сведение медиаданных (например, коммутация видео и сведение аудио), и

3)    отсечение медиаданных на основе требований сервисов телездравоохранения (например, присваивания приоритетов);

j)    функции контроля медиапрезенгаций и конференций для облегчения предоставления сервисов телездравоохранения. Кним относятся;

1)    непрерывное присутствие, позволяющее всем участникам в полной мере участвовать в конференции с помощью видео и/или аудио.

2)    контроль голосового управления, при помощи которого система переключает отображаемое видео при смене говорящего.

3)    председательский контроль, при помощи которого оператор выполняет функцию переключения видео.

4)    переключение презентации, позволяющее участникам в любое время увидеть говорящего, а говорящему увидеть всех/некоторых участников, и

5)    режим принудительного включения видео (трансляция) и смешанное управление (некоторые участники пользуются голосовым управлением, а некоторые председательским контролем);

k)    интеграция мультимедиа, позволяющая интегрировать аудио- и видеоконференции с электронными конференциями, включая передачу файлов, обмен сообщениями, обмен через доску сообщений и совместное использование приложений, при котором участники конференции могут обмениваться данными в сочетании с режимами аудио/видеоконференций:

l)    поддержка различных типов конференций для облегчения предоставления услуг телеэдраео* охранения. К ним относятся;

1)    централизованная многоточечная конференция, в ходе которой потоки аудио, видео и данных от отдельных терминалов отправляются на ЕМУ. который централизованно выполняет сведение аудио, коммутацию видео и распределение данных, а также отправляет обработанные потоки на участвующие терминалы,

2)    децентрализованная многоточечная конференция, входе которой участвующие терминалы осуществляют групповую передачу аудио и видео на другие участвующие терминалы без использования ЕМУ. Однако если в многоточечной конференции используется совместное использование данных, то для централизованной обработки и распределения данных на участвующие терминалы необходимо ЕМУ.

3)    гибридная многоточечная конференция, в ходе которой некоторые терминалы работают в централизованном режиме, а некоторые в распределенном режиме;

т) функции учета, отчетности и выставления счетов, в том числе;

-    отчеты использования ЕМУ (дата, время, продолжительность, участники).

• отслеживание неудачных конференций.

-    выставление счетов, в том числе:

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

9.3.3 Требования к проектированию. Решения в области телездравоохранения

С точки зрения общего проекта решений в области телездравоохракения. обычно учитываются следующие требования:

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

34

ГОСТ Р 57377—2016

b) возможности QoS, реализованные в целях обеспечения оптимальной производительности и желаемого уровня качества для конкретныхсервисовтелездравоохранения. Это может быть достигнуто путем надлежащего проектирования решений в области телездравоохранения, в том числе:

1)    правильно определенные и реализованныесетевыеэоныисегменты. например, спомощью коммутируемых сегментов ЛВС вместо ЛВС с общим доступом в IP-сетях,

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

3)    правильный выбор кодеков и других аппаратных компонентов, которые обладают хорошо подобранными спецификациями в таких областях, как циклы процессора, объем памяти, параметры буферизации, и

4)    оптимальная конфигурация контроллера шлюза, шлюза, и БМУ для типов терминалов и ожидаемые сервисы телездравоохранения (например, выбор соответствующих кодеков, полосы пропускания и режимов работы для предоставления сервисов телекардиологии).

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

10 Подход к созданию функционально совместимых архитектур

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

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

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

a)    каждый компонент способен выполнять специализированные услуги, которые объявлены через опубликованный интерфейс и зарегистрированы. Эта регистрация позволяет другим компонентам (потребителям услуг) найти услуги, которые соответствуют их потребностям;

b)    после размещения компонент становится доступным в сети и призывается с помощью стандартизованного, не зависящего от платформы, протокола для выполнения заявленных услуг; и

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

10.2    Области функционирования компонентов телеэдравоохранения

Чтобы определить границы между компонентами, функциональность решений телеэдравоохра-нения разделена на зоны обслуживания, включая:

10.2.1 Пользовательский интерфейс

Пользовательский интерфейс представляет собой аппаратные средства и/или программное обеспечение, с которым пользователь взаимодействует при доступе к системе, и включает в себя:

a)    средства управления, которые бы ознакомили пользователя с использованием системы (например, как запустить, провести измерения, осуществить калибровку устройства и выполнить его остановку);

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

c)    механизмы, которые обеспечивают обратную связь с пользователем по результату услуг, предоставленных другими компонентами.

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

3S

ГОСТ Р 57377—2016

10.2.2    Медицинские приборы

Медицинские приборы могут предоставить следующие возможности:

a)    получение данных:

b)    аналогово-цифровые преобразования:

c)    обработка и фильтрация сигналов;

d)    анализ и представление полученных данных:

e)    предоставление консультаций по уходу:

f)    прогнозирование неблагоприятных аффектов:

д)    предоставление подходящих вариантов помощи пациентам: и

Ь) передача данных пациента на другие приборы или в компьютерную систему.

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

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

10.2.3    Диспетчер данных

Диспетчер данных реализует возможности управления базами данных, включая:

a)    хранение и поиск данных:

b)    обслуживание данных (добавление, изменение и удаление);

c)    поддержание целостности и безопасности данных:

d)    хранение и поддержание информации касательно самих компонентов системы, например, их работоспособности, емкости и состояния;

е)    хранение и управление метаданными, например, информацией об элементах данных, хранящихся в базе данных;

f) хранение и управление информацией о данных, хранящихся по определенному предмету, и то. как можно получить доступ к этим данным независимо от типа носителя (диска или смарт-карты), управления хранением данных (например, реляционная база данных или объектная база данных), или местоположения прибора (локальное или удаленное); и

д)    управление данными и метаданными.

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

10.2.4    Диспетчер обработки

Диспетчер обработки осуществляет специализированные функции обработки мультимедийных данных, включая:

a)    кодирование и декодирование;

b)    компрессия и декомпрессия:

c)    преобразование и форматирование:

d)    фильтрация и интеграция данных; и

е)    получение данных из сигналов измерений.

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

10.2.5    Диспетчер связей

Диспетчер связей поддерживает работу в сети и передачу данных через различные телекоммуникационные технологии и протоколы, включая:

a)    согласование и запросы возможностей;

b)    распределение полосы пропускания и других сетевых ресурсов:

c)    соэданиесетевыхсоединений;

d)    передача данных;

e)    закрытие сетевых соединений; и

f)    освобождение сетевых ресурсов.

Например, набор протоколов МСЭ-Т или технологию Bluetooth для беспроводной связи.

36

ГОСТ Р 57377—2016

10.2.6    Диспетчер ресурсов

Снабженный «знаниями)* о медицинских данных (содержание, представление и значение), кли-нической обработке и коммуникациях, диспетчер ресурсов способен осуществлять:

a)    преобразование целей, ориентированных на предметную область (например, медицинских целей) в «знания», выраженные в технических терминах:

b)    достижение конкретных цепей путем приобретения ресурсов в свое распоряжение (например, услуг, предоставляемых конкретным компонентам), их использования (например, связывание между собой и использование их сервисов) и высвобождения: и

c)    управление объединением системы и ресурсов данных.

10.2.7    Диспетчер интеграции

Это «операционная система» системы телездравоохранения. способная осуществлять:

a)    интеграцию компонентов системы, доступных в сети;

b)    облегчение взаимодействия между этими компонентами;

c)    интеграцию данных и информации, доступной в сети, такой, как:

1)    клиническая терминология для поддержки задач интеграции данных или

2)    медицинские знания (например, клинические рекомендации) и данные (например, медицинская карта пациента) для принятия клинических решений;

d)    интерпретацию медицинских данных и информации, такой как:

1)    информация, полученная от медицинских приборов, или

2)    информация, полученная из исходных данных.

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

37

ГОСТ Р 57377—2016

Приложение ДА (справочное)

Сведения о соответствии ссылочных международных стандартов и международных документов национальным стандартам

Таблице ДА.1

Обоамачение ссылочного международного стенде рта. документа

Стелен»

соответствия

Обозначение и наименование соответствующего национального стандарта

CEN/TC 251/N99-097 (1999)

ISO/IEC 17000:2004

ITU-T Recommendation С.711 (1968)

ITU-T Recommendation G.722 (1993)

ITU-T Recommendation <3.728 (1992)

ITU-T Recommendation H.221 (1993)

ITU-T Recommendation H.230 (1997)

ITU-T Recommendation H.242 (1996)

ITU-T Recommendation H.243 (1997)

ITU-T Recommendation H.224 (1994)

*

ITU-T Recommendation H.261 (1994)

ITU-T Recommendation H.233 (1996)

ITU-T Recommendation H.234 (1996)

ITU-T Recommendation Н.Э20 (1996)

ITU-T Recommendation T.120{1996)

ITU-T Recommendation T.121 (1996)

ITU-T Recommendation T.122 (1993)

ITU-T Recommendation T.123 (1994)

ITU-T Recommendation T.124 (1996)

ITU-T Recommendation T.12S (1994)

ITU-T Recommendation T.126 (1996)

ITU-T Recommendation T.127 (1996)

* Соответствующий национальный стандарт отсутствует.

38

ГОСТ Р 57377—2016

Библиография

(1)    Antezans. F. (1997). Telehealth and telemedicine will henceforth be part of the strategy for health for all. 1997 Press Release.

(2)    Bashshur. R.. Senders. J.. and Shannon. G. (1997). Telemedicine Theory and Practice. Springfield, IL: Charles C Thomas

(3)    Coiera. E. (1997). Guide to Medical informatics. The internet and Telemedicine. Arnold A Member of the Hodder Headline Group. Copublished in the USA by Oxford University Press. ISBN 0-412-75710-9

(4)    Darklns. A. W. and Cary. M. A. (2000). Telemedicine and Telehealth. Principles. Policies. Performance, and Pitfalls. Spnngler Publishing Company. ISBN 0-8261-1302-8

(5)    Field. M. J. (Editor) (1996). Telemedicine. A Guide to Assessing Telecommunications In Health Care. Institute of Medicine. ISBN 0-309-05531-8

(6)    GATES (1994), Global Access Telehealth and Education System. Final Report. The International Space University. Summer Session, The Unlversltat Aut noma de Barcelona, Spain

(7)    Halsall. F. (2001). Multimedia Communications. Applications. Networks. Protocols and Standards. Addison-Wesley. ISBN 0-201-39818-4

(8)    Igras. E. (1999). Alberta Teiehealth Network. Interoperability Guidelines. Alberta Research Council, Calgary. Alberta. Canada

(9)    Maheu. M.. Whitten. P. and Allen. A. (2001). E-Health. Teiehealth. and Telemedicine. A Guide to Start-up and Success. Jossey-Bass W Wiley Company. ISBN 0-7879-4420-3

(10)    Picot. J. and Cradduck. T. (2000). The Teiehealth Industry in Canada: Industry Profile and Capability Analysis. Industry Canada. March 2000

(11)    Preston. J. (1993), The Telemedicine Handbook. Telemedical Interactive Consultative Services

(12)    Reid, J. (1996). A Telemedicine Primer. Understanding the issues. Innovatrve Medical Communications

(13)    Riesmeler. J.. Eichelberg. M.. Punys. J.. Punys V.. Lemome. 0.. end 8alogh. N. (2000). Guidelines for open scaleabte applications in telemedicine. D11.1.8-27-2000. INCO-COPERNICUS Project NR. PL961144-SAMTA

(14)    Wu. C-H. and Irwm. J. 0. (1998). Emerging Multimedia Computer Communication Technologies. Prentice Hall PTR. ISBN 0-13-079967-X

39

ГОСТ Р 57377—2016

УДК 004:61:006.354    ОКС 35.240.80    П85    ОКСТУ4002

Ключевые слова: здравоохранение, информатизация здоровья, электронный учет здоровья, телемедицина. системы и сети, функциональная совместимость, системы реального времени

Редактор А.Ф. Копчин Технический редактор В.Н. Прусакова Корректор О в. Лазарева Компьютерная верстка И.А НапеОкиноО

Сдано е набор 09.01.2017.    Подписано в печать 09 02.2017. Формат 60 » 84Гарнитура Ариел.

Уел. печ. л. 5.12. Уч.-изд. л. 4.83. Тираж 24 »кз. Зак. 322.

Подготовлено на основе электронной версии, предоставленной разработчиком стандарта

Издано и отпечатано во ФГУП «СТАНДАР ТИН ФОРМ». 123995 Москва, Гранатный пер.. 4.