Передача информации, относящейся к качеству обслуживания

Передача информации, относящейся к качеству обслуживания

Иллюстрации

Показать все

Реферат

ОБЛАСТЬ ТЕХНИКИ, К КОТОРОЙ ОТНОСИТСЯ ИЗОБРЕТЕНИЕ

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

УРОВЕНЬ ТЕХНИКИ

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

Для услуги класса потоковой передачи сервер потоковой передачи посылает медиаданные (мультимедийные данные) через сеть на клиент потоковой передачи с тем, чтобы медиаданные могли быть обработаны на стороне клиента как установившийся и непрерывный поток. Примером приложения потоковой передачи является коммерческое видеоизделие для Интернет. Сервер потоковой передачи также может постоянно находиться в пределах сети.

Операторы сети или поставщики услуг заинтересованы в наличии возможности оценивать качество обслуживания (КО, QoS), воспринимаемое пользователем клиента потоковой передачи. В настоящее время сеанс потоковой передачи, как определено с использованием протоколов, стандартизованных в техническом описании TS 26.234 проекта 3GPP (Third Generation Partnership Project, Проект партнерства систем связи 3-го поколения, ППСС3П), предлагает возможность располагать ограниченным количеством информации о воспринятом конечным пользователем качестве. Отчеты приемника (получателя) по протоколу управления передачей в реальном времени (Real-Time Transport Control Protocol, RTCP) клиент передает на сервер, чтобы предоставить информацию о поведении сети, например информацию о потерях пакетов, флуктуации времени задержки, о накопленном наивысшем принятом последовательном номере и другую информацию о пакетах транспортного протокола (Real-Time Transport Protocol, RTP) реального времени. Кроме того, отчеты отправителя по протоколу RTCP, передаваемые сервером на клиент, содержат информацию об отправителе.

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

Документы RFC (Рабочее предложение) 2328 комитета IETF (комитет по инженерным вопросам Интернет, КИВИ) (техническое описание RTSP, апрель 1998 г.), RFC 3550 комитета IETF (техническое описание RTP, июль 2003 г.) и проект расширенных отчетов (RTCP XR, май 2003 г.) для протокола управления протоколом RTP, например, дают возможность клиенту потоковой передачи предоставлять информацию о принятых пакетах RTP, включая долю потери пакетов, флуктуацию времени задержки, наивысший принятый последовательный номер и последовательность потерь пакетов.

Два документа: проект Rel-6 "PSS Quality Metrics Permanent Document" (Постоянный документ по метрикам качества PSS (Packet-Switched Streaming, потоковая передача с коммутацией пакетов)), совещания Meeting № 27 TSG-S4 3GPP, 7-11 июля 2003 г., Tdoc S4-030562, и в "Stream Quality Metrics Client metrics" (Метрики качества потока, метрики клиента), совещания Meeting № 26 TSG-S4 3GPP, 5-9 мая 2003 г., Tdoc 34-030353, описывают дополнительные общие вопросы метрик QoS в проекте 3GPP. Первый документ описывает, какую информацию следует посылать, используя 25 различных параметров для метрик речи, аудио, видео, устройства воспроизведения и сети, и какой протокол следует использовать. Кроме того, второй документ определяет высокоуровневые требования и технические рассмотрения. Документы определяют способ, каким образом клиент вычисляет информацию и посылает ее на сервер при запрашивании. Для целей транспорта предлагается использовать сообщение GET_PARAMETER (получить параметр) протокола потоковой передачи в реальном времени (Real-Time Streaming Protocol, RTSP), которое посылают от сервера на клиент, и сообщение SET_PARAMETER (установить параметр) протокола RTSP, которое посылают от клиента на сервер.

Эти сообщения определены более подробно в документе "Streaming quality Metrics - Transport" (Метрики качества потоковой передачи - Транспорт), совещания Meeting № 28 TSG-S4 3GPP, 1-5 сентября 2003 г., Tdoc S4-030629. Предлагается, чтобы сообщение SET_PARAMETER протокола RTSP было передаваемым от сервера на клиент, чтобы запускать метрики QoS. Клиент может отвечать сообщением 200 OK («успешно») протокола RTSP, если он дает согласие посылать метрики QoS. Сервер может затем посылать описание сеанса метрик QoS с помощью последующего сообщения SET_PARAMETER, включающего в состав описание METRICS-SETUP (установка метрик) сеанса метрик, которое содержит параметры Range (диапазон), Period (промежуток времени) и Sender (отправитель). Также это сообщение должно быть принято клиентом с ответным сообщением 200 OK протокола RTSP. В качестве альтернативы сервер может запросить с помощью сообщения GET_PARAMETER, чтобы клиент предоставил описание сеанса метрик QoS. Как только сеанс метрик QoS описан и согласован, то либо клиент может посылать метрику QoS с помощью сообщения SET_PARAMETER, либо сервер может извлекать метрику QoS с помощью сообщения GET_PARAMETER.

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

СУЩНОСТЬ ИЗОБРЕТЕНИЯ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Альтернативами использованию нового заголовка или атрибута по RTSP являются использование определения нового сообщения RTSP для передачи сигналов метрик QoS, использование поля Content-Length (размер содержимого в байтах) и вставка тела сообщения в конец сообщения RTSP или определение набора параметров, связанных с метриками QoS, для использования с сообщениями SET_PARAMETER и GET_PARAMETER протокола RTSP. Разработчик может выбрать не использовать поле заголовка RTSP для метрик QoS для того, чтобы полностью отделить сигнализацию метрик QoS от сигнализации сеансового уровня.

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

Протокольным сообщением в обоих аспектах изобретения может быть, в частности, хотя не ограничительно, сообщение протокола RTSP, сообщение протокола RTCP, сообщение протокола (Session Initiation Protocol, SIP) инициации сеанса или описание по протоколу (Session Description Protocol, SDP) описания сеанса. Особым преимуществом использования сообщений RTSP в предлагаемых способах является то, что этот протокол обеспечивает приспосабливаемые передачи, которые являются более надежными, чем передачи по RTCP.

Услугой, к которой относится качество обслуживания, может быть в обоих аспектах изобретения, например, хотя не ограничительно, услуга класса потоковой передачи. В частности, для такой услуги класса потоковой передачи могут использоваться протоколы RTSP и RTCP. Соответственно, предлагаемыми устройствами могут быть, например, приемное устройство или передающее устройство для услуг класса потоковой передачи, то есть клиент потоковой передачи или сервер потоковой передачи. Изобретение обеспечивает особо подходящие способы, чтобы предоставлять возможность серверу потоковой передачи выявлять, как клиент потоковой передачи фактически принимает данные, и иметь большее количество информации о качестве пользовательского практического опыта (QoE, Quality of Experience (качество практического опыта, КПО)), а также о трудностях, с которыми может столкнуться сеанс потоковой передачи.

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

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

В эффективном варианте осуществления, например, для услуги класса потоковой передачи информация, связанная с QoS, включена в сообщение протокола (SDP) описания сеанса или в поле заголовка в ответном сообщении 200 OK на сообщение DESCRIPTION (описание) протокола RTSP, в сообщение SETUP (установка) протокола RTSP, в сообщение PLAY (воспроизведение) протокола RTSP, в сообщение PAUSE (пауза передачи) протокола RTSP или в сообщение TEARDOWN (прекращение передачи и освобождение ресурсов) протокола RTSP. Предпочтительно сообщение "установка параметров метрик QoS" является присоединенным к сообщению SDP внутри ответа на сообщение DESCRIPTION протокола RTSP. Дополнительно предпочтительно сообщение "изменение параметров метрик QoS" является присоединенным к какому-либо сообщению протокола RTSP, подобному PAUSE, инициированному либо клиентским устройством, либо пользователем клиентского устройства. Должно быть отмечено, что SDP не может использоваться в течение сеанса.

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

Частота предоставления отчета может быть периодической, управляемой событиями или в конце сеанса. В случае периодического предоставления отчета промежуток времени запрашивается сервером потоковой передачи и согласовывается с клиентом потоковой передачи. Клиент потоковой передачи отвечает согласованными значениями, которые могут быть менее оптимальными, чем запрошенные сервером. В случае управляемого событиями предоставления отчета клиент потоковой передачи предоставляет отчеты о событиях "плохое качество". Это минимизирует количество информации, передаваемой от клиента потоковой передачи на сервер потоковой передачи. Предоставление отчета в конце сеанса может вызывать трудности, если сеанс заканчивается аварийно. Если услуга находится в состоянии Pause («пауза»), клиент может не посылать связанные с QoS данные обратной связи, чтобы избежать расходования радиоресурсов из-за фиктивных данных. Сервер должен быть способным обрабатывать такое прерывание.

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

Кроме того, следует позаботиться, чтобы различные серверы вычисляли метрику QoS таким же образом, чтобы обеспечить объективность.

Поскольку уровни 3 и 4 (L3-L4) метрик являются доступными через обычные отчеты RTCP или отчеты XR протокола RTCP, изобретение особо подходит для передачи метрик уровня 5 (L5) и необработанных данных. Клиент должен быть способным буферизовать ряд отчетов QoS и посылать их в отдельном отчете, добавив указание диапазона времени, чтобы минимизировать количество сообщений, посылаемых по радиоинтерфейсу. Примерами посылаемой информации являются идентификатор (ИД, ID) сеанса, продолжительность времени между разрушениями (искажениями данных), отметка времени и т.д.

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

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

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

фиг.2 - таблица, представляющая события и измерения, которые могут быть выявлены клиентом системы по фиг.1;

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

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

ПОДРОБНОЕ ОПИСАНИЕ ИЗОБРЕТЕНИЯ

На фиг.1 схематично представлена система 10, в которой может применяться изобретение.

Система 10 содержит сервер 20 потоковой передачи, обеспечивающий в качестве примера потоковое видео «по требованию». Система 10 дополнительно содержит клиент 30 потоковой передачи, который может быть осуществлен, например, в мобильном телефоне. Клиент 30 потоковой передачи соединен через сеть 40 с сервером 20 потоковой передачи, и может требовать и принимать приложение потокового видео от сервера 20 потоковой передачи. Сеть 40 может содержать, например, соединенные между собой наземную сеть мобильной связи общего пользования (НСМСОП, PLMN), к которой могут осуществлять доступ мобильный телефон с помощью клиента 30 потоковой передачи, и сеть Интернет, к которой сервер 20 потоковой передачи может быть присоединен. Должно быть понятно, что клиент 30 потоковой передачи может также быть частью сетевого элемента сети 40.

Сервер 20 потоковой передачи включает в себя предназначенный для компоновки сообщений RTSP компонент 21 компоновки, который соединен с передатчиком TX 22, и компонент 23 отсоединения, предназначенный для отделения данных QoS, который соединен с приемником RX 24. Клиент 30 потоковой передачи равным образом включает в себя компонент 31 компоновки для осуществления компоновки сообщений RTSP, который соединен с передатчиком TX 32, и компонент 33 отсоединения для отделения данных QoS, который соединен с приемником 34 RX. Компоненты 21, 23, 31 и 33 могут быть осуществлены, в частности, посредством программного обеспечения, но равным образом посредством аппаратных средств.

Клиенту 30 потоковой передачи дана возможность обеспечивать три вида связанных с QoS значений для передачи на сервер потоковой передачи, а именно события, измерения и метрики. События определены как инциденты или ошибки в клиенте 30 потоковой передачи, которые вызывают аномалии и отличия от гипотетического эталонного безошибочного осуществления среды передачи, и могут содержать, например, продолжительность речевой паузы. Измерения определены как система отслеживания, чтобы осуществлять мониторинг (текущий контроль) сеанса потоковой передачи в обычных или необычных (аварийных) условиях, и могут содержать, например, время установки сеанса. Метрики являются вычислениями на основании событий и измерений и могут содержать, например, среднюю и/или максимальную продолжительность речевой паузы.

В системе 10 по фиг.1 осуществлен способ, который может обрабатывать передачу событий, измерений и метрик от клиента 30 потоковой передачи на сервер 20 потоковой передачи. Более конкретно, все связанные с QoS данные в любом направлении между клиентом 30 потоковой передачи и сервером 20 потоковой передачи, включая также события, измерения и метрики в качестве связанных с QoS данных определения и согласования, присоединяют для передачи посредством компонентов 21, 31, компоновки соответственно, к сообщениям RTSP, скомпонованным каким-либо образом для некоторой другой цели. Дополненное сообщение RTSP затем передает передатчик 22, 32 соответствующего передающего устройства 20, 30 через сеть 40 на приемник 34, 24 соответствующего приемного устройства 30, 20. В соответственном приемном устройстве 30, 20 данные QoS отделяют для дальнейшего использования из принятого сообщения RTSP в соответствующем компоненте отсоединения, предназначенном для отделения данных 33, 23 QoS.

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

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

Кроме того, обеспечиваются четыре способа задания частоты для передачи от клиента 30 потоковой передачи на сервер 20 потоковой передачи сообщений обратной связи, содержащих события, измерения и/или метрики.

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

В системе по фиг.1 передачу связанных с QoS данных осуществляют преимущественно в две стадии: в стадию согласования в течение установки соединения для сеанса потоковой передачи и в стадию обратной связи в течение продолжающегося сеанса потоковой передачи. Обе стадии будут описаны ниже со ссылкой на фиг.4. На фиг.4 показано схематическое изображение передачи сигналов, представляющее сигнализацию между сервером 20 потоковой передачи и клиентом 30 потоковой передачи. Кроме того, предоставлена возможность стадий повторного согласования в течение продолжающегося сеанса потоковой передачи.

В установке соединения RTSP для сеанса потоковой передачи клиент 30 потоковой передачи и сервер 20 потоковой передачи согласуют, какие метрики, измерения и события посылают и как часто. Для согласования определен нижеследующий новый заголовок QoS-Metrics (метрики QoS), который отличается от заголовка, определенного в вышеупомянутом документе совещания Meeting № 28 TSG-SA4:

QoS-header (заголовок QoS) = "QoS-Metrics" ":" "Off" | 1#(stream-url ";" Metrics ";" Sending-rate [";" Range]) CRLF (конец строки с переходом в новую строку)

stream-url (унифицированный указатель ресурса для потока) = "url" "=" rtsp_URL (URL по RTSP)

Metrics = "metrics" "=" "{" 1#(1*TEXT) "}"

Sending-rate (скорость посылки) = "rate" "=" 1*DIGIT (цифра) | "End" (конец)

Range = как определено в RFC 2327

DIGIT = как определено в RFC 2326

Rtsp_URL = как определено в RFC 2326

Этот заголовок может быть частью любого сообщения протокола RTSP, передаваемого сервером 20 потоковой передачи или клиентом 30 потоковой передачи.

Имеются два способа использования заданных метрик QoS. Если используется только параметр Off, это указывает, что либо сервер 20, либо клиент 30 хочет отменить передачу событий, измерений и метрик. Если, с другой стороны, заголовок содержит другие параметры, то есть stream-url, Metrics, Sending-rate и, возможно, Range, то требуется запустить или повторно запустить передачу метрики соответственно.

Поле stream-url является URL сеанса RTSP или идентификатором URL управления по протоколу RTSP для медиаданных. Если заголовок используется вместе с информацией URL управления сеансом протокола RTSP, то поле QoS-Metrics используется на сеансовом уровне. Если URL является URL управления медиаданными по протоколу RTSP, то поле QoS-Metrics используется на уровне медиаданных и каждые медиаданные получают свою собственную строку метрики QoS. Возможно, что на один и тот же URL осуществляется ссылка более одного раза. Если информация Sending-Rate и Range отличается от предварительно заданной, то новые параметры метрики рассматриваются в качестве отличающегося набора параметров, который является действительным для этого конкретного URL, но для другой метрики. В противном случае, на один и тот же URL управления RTSP не должна осуществляться ссылка более одного раза для одинаковых значений Sending-Rate и Range.

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

Поле Sending-rate используется для установления частоты посылки. Если значением Sending-rate является 0, то клиент 30 может посылать сообщения обратной связи в любое время в зависимости от событий, происходящих в клиенте 30. Значения больше 1 указывают в секундах точный интервал посылки сообщений. Самый коротким интервалом является один раз в секунду, а самый длинный интервал является неопределенным. Интервал посылки обратной связи может быть различным для различных медиаданных, но рекомендуется поддерживать своего рода синхронизацию, чтобы избежать добавочного трафика. Значение End указывает, что только одно сообщение обратной связи посылают в конце сеанса.

Поле Range может использоваться для задания выдержки времени для посылки обратной связи. Это сходно с посылкой параметра Off, но позволяет заранее определить диапазон времени для состоянии On в течение стадии согласования.

Заданное поле QoS-Metrics может рассматривать ситуацию, в которой вычисления метрики выполняют в сервере 20 потоковой передачи и в которой клиент 30 потоковой передачи посылает на сервер только события и/или измерения, и равным образом ситуацию, в которой клиент 30 потоковой передачи посылает предварительно вычисленные метрики на сервер 20 потоковой передачи.

Кроме того, определен новый атрибут Qos-Metrics для SDP, который может использоваться либо как атрибут SDP сеансового уровня, либо уровня медиаданных. Синтаксис определения основан на документах RFC 2327, которые включены в настоящий документ путем ссылки:

a=QoS-Metrics: Metrics ";" Sending-rate [";" Range])

CRLF

Metrics = "metrics" "=" "{" 1#(1*TEXT) "}"

Sending-rate = "rate" "=" 1*DIGIT | "End"

Range = как определено в RFC 2327

DIGIT = как определено в RFC 2327

Для открытия сеанса потоковой передачи клиент 30 потоковой передачи передает на сервер 20 потоковой передачи запрос DESCRIBE протокола RTSP в виде сообщение 1 по фиг.4:

C->S	DESCRIBE rtsp://example.com/foo/bar/baz.3gp RTSP/1.0
	Cseq: 1

Представление C->S указывает передачу от клиента 30 на сервер 20.

Фактическое согласование поля QoS-Metrics затем может быть начато с первого ответа на DESCRIBE, как изложено ниже.

Приняв запрос 1 DESCRIBE от клиента 30, сервер 20 приводит перечень желательной информации метрик QoS в описании SDP, используя атрибут SDP (поля) QoS-Metrics. Эти метрики могут быть заданы или на сеансовом уровне, или на уровне медиаданных в SDP. Это придает гибкость обработке QoS, так что важные компоненты медиаданных могут быть отслежены более подробно. Сервер 20 потоковой передачи присоединяет описание SDP к ответу 200 OK на DESCRIBE и передает ответ в виде сообщения 2 по фиг.4 на клиент 30 потоковой передачи. Также возможно, что сервер приводит перечень метрик QoS в ответном сообщении на DESCRIBE, предпочтительно с использованием заголовка QoS-Metrics, чем с использованием атрибута SDP. Клиент 30 потоковой передачи должен проверить наличие такого заголовка в ответе.

Должно быть отмечено, что в вышеупомянутом документе относительно TSG-S4 Meeting № 28 уже четыре специализированных сообщения QoS требуются до этой стадии.

В нижеследующем представлен пример соответствующего сообщения сеансового уровня, причем требуемыми параметрами сеанса являются RTSPSetupTime (время установки сеанса передачи по протоколу RTSP)