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

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

Группа П85

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

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

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

Часть 2

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

Health informatics. Interoperability of telehealth systems and networks. Part 2. Real-time systems

ОКС 35.240.80
ОКСТУ 4002

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

Предисловие

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

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

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 29 декабря 2016 г. N 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 июня 2015 г. N 162-ФЗ "О стандартизации в Российской Федерации". Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе "Национальные стандарты", а официальный текст изменений и поправок - в ежемесячном информационном указателе "Национальные стандарты". В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя "Национальные стандарты". Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

_______________

* Таблицу соответствия национальных стандартов международным см. по ссылке. - .

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

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

ITU-T Recommendation G.711 (1988) 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 a 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) A far end camera control protocol for videoconferences using H.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-law): Вариант аудиокодирования G.711, используемый в основном в Северной Америке и Японии.

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

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): Надежный канал, используемый для передачи сообщений об установлении вызова в соответствии с Q.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, CCD): Устройство, используемое в камерах в качестве оптического сканирующего механизма.

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

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

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

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

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

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

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

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

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

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

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

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

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

3.22 G.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: Рекомендация МСЭ-Т, определяющая алгоритм кодирования и компрессии для двух вариантов разрешения видео: 352288 CIF и 176144 QCIF.

Примечание - Н.261 используется в Н.320 и Т.120.

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

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

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

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

3.38 Н.320: Комплекс стандартов МСЭ-Т, ратифицированных в 1990 году, которые определяют то, как связываются системы голосовой и видеоконференции через сети ISDN или арендуемые сети с использованием полосы пропускания от 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/Н.324.

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

Примечание - В Н.324 используется Н.263, который содержит более хороший кодек для ОАТЛ, чем Н.261. Н.263 является улучшенной версией Н.261, добавляющей формат 12896 sub-QCIF (SQCIF). При использовании модема со скоростью 28,8 или 36,6 Кб/с, Н.263 может производить частоту кадров, приближенную к частоте, обеспечиваемой системами Н.320 через ISDN.

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

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

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

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

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

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

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

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

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

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

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

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

Примечание - Используется в Северной Америке, Японии и некоторых других странах. Формат NTSC: 525 строк в кадре; 30 кадров в секунду (кадр/сек); коэффициент черезстрочности 2:1; формат кадра 4:3; уравнение цветовой матрицы: Y=0,3R+0,59G+0,11В; I=0,6R-0,28G-0,32В; Q=0,21R-0,52G+0,31В, где R = красный, G = зеленый и В = синий.

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 цифровых значений и затем компрессируется в соответствии либо с А-законом, либо с -законом. Такая схема выборки адекватна для голосовой связи.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- регистрирует себя в конференции,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- RTP,

- RTSP и

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

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

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

4 Сокращения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Как описано в I.121, тип передачи - ATM, при котором данные передаются в виде нескольких блоков фиксированного размера, которые называются ячейки.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.4.2 Шлюзы

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

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

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

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 обычно применяются в отдельных устройствах, таких как видеотелефоны. Они также могут быть интегрированы в персональные компьютеры.

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

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

5.6.1 Обзор Т.120

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пример - Q.931.

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

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. RTP/RTCP является продуманным протоколом с большим количеством элементов и полей для обязательных и дополнительных процедур (особенно RTCP), которые частично накладываются на другие протоколы, определенные в рамках Рекомендаций Н.323. Некоторые разработчики придерживаются руководств RTCP, другие же придерживаются Н.323 и могут выбрать пропустить определенные поля при реализации стандарта. Поэтому, одна реализация может отличаться и не соответствовать другим реализациям, что ведет к проблемам функциональной совместимости. Например, в RTCP поле "спате" присваивает уникальное имя потоку данных и является обязательным. В Рекомендациях Н.323 это поле является излишним. В Н.323 идентификация и ассоциация потока осуществляется посредством Н.225 (с использованием Н.245). Некоторые совместимые с Н.323 изделия не используют поле "спате". Другие изделия, придерживающиеся оригинальных RTP/RTCP, ожидают использования этого поля в сообщении. Это препятствует функционально совместимой работе систем.

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

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

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

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

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

Примеры

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

a) оригинальные поля Q.931 - ConferencelD и CRV и

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

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

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

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

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

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

Некоторые изделия Н.323 могут не поддерживать некоторые из характеристик, зависящих от пропускной способности сети, Н.323, таких как видеокодек Н.263, и аудиокодек G.723.1. Кроме того, в Н.263 есть несколько различных "вариантов" Н.263, а именно: Н.263 (проект), Н.263 (окончательный) и Н.263 +. Внедрение только обязательного видеокодека Н.261 на основе ISDN и аудиокодека G.711 или другой версии кодека Н.263 приводит к проблемам с функциональной совместимостью.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рисунок 8 - Аспекты функциональной совместимости для сервисов телездравоохранения реального времени

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

g) поддерживать электронные конференции с использованием стандартов МСЭ-Т серии Т.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 системы, работающие в сети с коммутацией каналов, и более обобщенную конфигурацию совместимых с Н.32х систем, предоставляющих мультимедийные сервисы в сетях с коммутацией пакетов и в сетях с коммутацией каналов.

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

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

Рисунок 9 - Видеосервисы Н.320, встроенные в существующие сети передачи данных и голоса по технологии Frame Relay

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

- дрожание или

- пропущенные кадры.

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

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

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

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

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

Шлюз и контроллер шлюза играют важную роль в обеспечении неразрывности взаимосвязанности терминалов. Шлюз соединяет конференции на основе Н.323 с другими сетями, протоколами связи и мультимедийным форматом. В этом случае он объединяет терминалы Н.323 с терминалами Н.320 по ISDN, терминалы Н.324 по ПТТЛ и терминалы Н.310 по B-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) хранение и управление требованиями сервисов телездравоохранения, включая обязательные и необязательные устройства, приоритеты сервисов, требования к полосе пропускания, наличие определенных режимов/кодеков медиаконференций и желаемый уровень качества аудио/видео для этих сервисов;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

количество неудачных соединений, осуществленных участником, и причины неудач,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

d) анализ и представление полученных данных;

e) предоставление консультаций по уходу;

f) прогнозирование неблагоприятных эффектов;

g) предоставление подходящих вариантов помощи пациентам; и

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

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

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

10.2.3 Диспетчер данных

Диспетчер данных реализует возможности управления базами данных, включая:

a) хранение и поиск данных;

b) обслуживание данных (добавление, изменение и удаление);

c) поддержание целостности и безопасности данных;

d) хранение и поддержание информации касательно самих компонентов системы, например, их работоспособности, емкости и состояния;

е) хранение и управление метаданными, например, информацией об элементах данных, хранящихся в базе данных;

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

g) управление данными и метаданными.

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

10.2.4 Диспетчер обработки

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

a) кодирование и декодирование;

b) компрессия и декомпрессия;

c) преобразование и форматирование;

d) фильтрация и интеграция данных; и

е) получение данных из сигналов измерений.

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

10.2.5 Диспетчер связей

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

a) согласование и запросы возможностей;

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

c) создание сетевых соединений;

d) передача данных;

e) закрытие сетевых соединений; и

f) освобождение сетевых ресурсов.

Например, набор протоколов МСЭ-Т или технологию Bluetooth для беспроводной связи.

10.2.6 Диспетчер ресурсов

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

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

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

c) управление объединением системы и ресурсов данных.

10.2.7 Диспетчер интеграции

Это "операционная система" системы телездравоохранения, способная осуществлять:

a) интеграцию компонентов системы, доступных в сети;

b) облегчение взаимодействия между этими компонентами;

c) интеграцию данных и информации, доступной в сети, такой, как:

1) клиническая терминология для поддержки задач интеграции данных или

2) медицинские знания (например, клинические рекомендации) и данные (например, медицинская карта пациента) для принятия клинических решений;

d) интерпретацию медицинских данных и информации, такой как:

1) информация, полученная от медицинских приборов, или

2) информация, полученная из исходных данных.

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

Приложение ДА
(справочное)

Сведения о соответствии ссылочных международных стандартов и международных документов национальным стандартам

Таблица ДА.1

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

Электронный текст документа
и сверен по:

, 2017