ПЕРЕДАЧА ИНФОРМАЦИИ, ОТНОСЯЩЕЙСЯ К КАЧЕСТВУ ОБСЛУЖИВАНИЯ Российский патент 2009 года по МПК H04L29/06 

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

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

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

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

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

Операторы сети или поставщики услуг заинтересованы в наличии возможности оценивать качество обслуживания (КО, 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) и InitialBufferingTime (время начальной буферизации), причем запрашиваемыми параметрами видео являются Framegap_max (максимальный промежуток между кадрами?) Framegap_ave (средний промежуток между кадрами) и причем запрашиваемыми параметрами аудио являются AudioGap_ave (средняя пауза аудио) и AudioGap_max (максимальная пауза аудио). Должно быть отмечено, что имена параметров являются лишь примерами и что соответствующее имя может обозначать метрики, измерения и/или события.

S->C RTSP/1.0 200 OK   Cseq: 1   Content-Type (тип содержимого): application (приложение)/sdp   Content-Base (база для URL)(: rtsp://example.com/foo/bar/baz.3gp/   Content-Length: 800   Server: Nokia RTSP Server       v=0   o=-3268077682 433392265 IN IP4 63.108.142.6   s=QoS Enables Session Description Example   e=support@nokia.com   c=IN IP4 0.0.0.0   t=0 0   a=range:npt=0-83.660000   a=QoS-Metrics:{RTSPSetupTime, InitialBufferingTime};rate=End   a=control:*   m=video 0 RTP/AVP 96   b=AS:28   a=QoS-Metrics:{Framegap_max,   Framegap_ave};rate=15;range:npt=0-40   a=control:trackID=3 (идентификатор дорожки)   a=rtpmap:96 MP4V-ES/1000 (соответствие RTP)   a=range:npt=0-83.666000   a=fmtp:96profile-level-   id=8;config=000001b008000001b5090000010000000120008440fa28302090a28f   m=audio 0 RTP/AVP 98   b=AS:13   a=QoS-Metrics:{AudioGap_ave, AudioGap_max};rate=20   a=control:trackID=5   a=rtpmap:98 AMR/8000   a=range:npt=0-83.660000   a=fmtp:98 octet-align=1 (выравнивание октетов)   a=maxptime:200

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

Согласование QoS может быть выполнено на любой стадии в течение сеанса, если одна сторона пожелает передачу сигналов метрик QoS. В примере, приведенном в документе, это осуществлено на стадии установки сеанса с использованием атрибута SDP. Также возможно посылать метрики QoS в любом другом сообщении RTSP, используя атрибут SDP поля QoS-Metrics или поле QoS-Metrics заголовка в соответствии с изобретением.

Клиент 30 потоковой передачи выбирает приемлемые метрики QoS, приведенные в перечне в атрибуте SDP принятого сообщения 200 OK, или он предлагает новые значения в первом запросе SETUP. Если клиент 30 поддерживает метрики QoS, то он должен послать запрос SETUP или некоторое другое сообщение RTSP, содержащее выбранное/измененное поле QoS-Metrics либо для сеансового уровня, либо для уровня медиаданных, который является устанавливаемым. Такое сообщение запроса SETUP обозначено на фиг.4 в виде сообщения 3. Альтернативой сообщению RTSP был бы, например, запрос PLAY, обозначенный на фиг.4 в виде сообщения 5. Соответствующее примерное сообщение SETUP представлено в нижеследующем:

C->S SETUP rtsp://example.com/foo/bar/baz.3gp/trackID=3 RTSP/1.0   Cseq:2   QoS-Metrics:url="rtsp://example.com/foo/bar/baz.3gp/track ID=3";   metrics={Framegap_max, Framegap_ave};rate=10;range:npt=0-40,   url="rtsp://exampie.com/foo/bar/baz.3gp";   metrics={RTSPSetupTime, InitialBufferingTime};rate=End

В вышеупомянутом примере запроса SETUP клиент 30 потоковой передачи модифицирует частоту посылки метрики QoS с 15 на 10 для URL управления "rtsp://example.com/foo/bar/baz.3gp/trackID=3".

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

Сервер 20 потоковой передачи принимает этот запрос SETUP и возвращает обратно сообщение 200 OK с принятой метрикой QoS, переданной клиентом 30, присоединенной к повторному подтверждению изменений. Это сообщение 200 OK обозначено на фиг.4 как сообщение 4. Сервер 20 потоковой передачи может также отклонять изменения, осуществленные клиентом 30 потоковой передачи в сообщениях 200 OK. Чтобы отклонить изменения, сервер 20 потоковой передачи может либо устанавливать новые значения и вновь посылать модифицированные метрики обратно на клиент 30 потоковой передачи, присоединенные к сообщению 200 OK, либо он может просто игнорировать эти метрики и повторно не подтверждать их.

Если сервер 20 потоковой передачи подтвердил изменения, он может послать обратно нижеследующий примерный ответ на SETUP:

S->C RTSP/1.0 200 OK   Cseq: 2   Session: 17903320   Transport: RTP/AVP;unicast;client_port=7000-7001;server_port=6970-6971 (транспорт) (одноадресная) (клиентский порт) (серверный порт)   QoS-Metrics:url="rtsp://example.com/foo/bar/baz.3gp/trackID=3";   metrics={Framegap_max, Framegap_ave};rate=10;range:npt=0-40,url="rtsp://example.com/foo/bar/baz.3gp";   metrics={RTSPSetupTime, InitialBufferingTime};rate=End

По мере того как клиент 30 потоковой передачи принимает это сообщение 4 «200 OK» в ответ на его запрос 3 «SETUP», он понимает, что сервер 20 потоковой передачи поддерживает метрики QoS. Дополнительно клиент 30 понимает, что сервер 20 дал согласие поддерживать перечень метрик, приведенный в заголовке QoS-Metrics RTSP.

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

Если сервер 20 потоковой передачи не утверждает (не принимает) модификации, осуществленные клиентом 30 потоковой передачи, сервер 20 и клиент 30 могут продолжить повторное согласование, до запроса PLAY протокола RTSP, выполненного клиентом 30, обозначенного на фиг.4 как сообщение 5. Последующий ответ сервера 20 на сообщение PLAY протокола RTSP, обозначенного на фиг.4 как сообщение 6, затем возвращает окончательные согласованные метрики QoS, включая все значения (поля) QoS_Metrics сеансового уровня и уровня медиаданных.

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

Следует дополнительно отметить, что клиент 30 потоковой передачи может уже иметь описание SDP прежде, чем он начинает сеанс, например в форме файла. Если описание SDP извлечено средством, отличным от ответа на DESCRIBE от конкретного сервера 20, то первым сообщением, принятым сервером потоковой передачи, является сообщение 3 SETUP по фиг.4. Стрелки, соотнесенные с сообщением 1 запроса DESCRIBE и сообщением 2 ответа на DESCRIBE, на фиг.4 представлены поэтому только пунктирными линиями. Клиент 30 потоковой передачи может передавать в этом случае в сообщении 3 SETUP исходную информацию метрик QoS для согласований. Если сообщение 3 SETUP включает в себя информацию метрик QoS, сервер 20 потоковой передачи может принимать метрики или предлагать новые в ответе SETUP 4 и согласование метрик QoS может продолжаться в следующих сообщениях RTSP, как описано выше. Если первое сообщение 3 SETUP не включает в себя информацию метрик QoS, а сервер 20 потоковой передачи желает согласовать метрики QoS с клиентом 30 потоковой передачи, то сервер 20 потоковой передачи может запрашивать предоставление отчета об информации метрик QoS от клиента 30 потоковой передачи, используя ответ 4 на SETUP. Если клиент 30 потоковой передачи принимает запрашиваемые метрики QoS или хочет изменить их, клиент 30 потоковой передачи должен включать информацию о метриках в следующее сообщение RTSP. Если в следующем сообщении RTSP не имеется информации о метриках QoS, то это указывает, что клиент 30 потоковой передачи не поддерживает метрики QoS.

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

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

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

Feedbackheader (заголовок обратной связи) = "QoS-Feedback" ":" 1#(stream-url 1*(parameters) CRLF)

stream-url = "url" "=" rtsp_URL

parameters (параметры) = ";" Metrics "=" "{" SP / 1#(Value [SP

Timestamp]) "j"

Metrics = *TEXT

Value (значение) = 1*DIGIT ["." *DIGIT]

Timestamp (отметка времени) = 1*DIGIT

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

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

SP (пробел) = как определено в RFC 2326

Stream-url является URL сеанса RTSP или идентификатором URL управления медиаданными для параметра обратной связи. Поле Metrics в определении параметров содержит имя метрик, измерений или событий, и оно должно быть тем же, что и поле Metrics в поле согласований QoS-Metrics. Рекомендуется поддерживать порядок метрик таким же, чтобы упростить синтаксический анализ. Поле Value указывает результаты метрик. Необязательное поле Timestamp указывает время, когда произошло событие или измерение или когда были вычислены метрики. Заголовок также дает возможность сообщать о нулевых событиях посредством включения пробела (SP).

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

Если протоколом для сообщений обратной связи должен быть протокол RTCP вместо RTSP, то является возможным использовать пакеты APP (определенный для приложения пакет RTCP, тип 204 пакета) протокола RTCP или пакеты расширения RR (отчет приемника, тип 201 пакета) протокола RTCP. Каким бы ни был используемый пакет, он должен содержать, по меньшей мере, поле Metrics, поле Value и, необязательно, поле Timestamp. Metrics является именем метрики или указанием пустого сообщения (код ASCII (Американский стандартный код обмена информацией) или число). Value является результатом метрики (число). Timestamp является временем, когда событие произошло или была вычислена метрика (число), и его предоставляют только необязательно. Заголовки RTCP содержат информацию о конкретных медиаданных, так что нет необходимости повторять эту информацию добавочными полями.

В сообщениях обратной связи заголовок QoS-Feedback содержит только обновленные метрики QoS-Metrics. Если параметр метрики не приведен в перечне, но согласован в течение стадии установки, то предполагают, что этот параметр метрики должен быть неизменяемым/необновляемым. Клиент 30 потоковой передачи может использовать нижеследующее сообщение в любом сообщении RTSP после запроса PLAY. Такое сообщение обозначено на фиг.4 как сообщение 7. Следует отметить, что имена параметров являются лишь примерами.

OPTIONS (необязательные варианты) rtsp://example.com/foo/bar/baz.3gp RTSP/1.0

Cseq: 302

Session: 17903320

QoS-Feedback:

url="rtsp://example.com/foo/bar/baz.3gp/trackID=3";Framegap_max=100 6000; Framegap_ave=50 6000

url= "rtsp://example.com/foo/bar/baz.3gp/trackID=5";

AudioGap_ave=340.5 52;AudioGap_max=0 500

Также возможно объединять сообщения обратной связи протокола RTSP, чтобы избегать слишком высокой частоты посылки сообщения, например, вследствие посылки на основании событий.

В качестве альтернативы сообщению обратной связи протокола RTSP клиент 30 потоковой передачи может использовать, например, нижеследующее сообщение RR протокола RTCP для предоставления отчета о данных QoS:

Заголовок RTCP

Блок отчета

Конкретное расширение профиля

AudioGap_ave 105,5 6000 AudioGap_max 123 500

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

Заголовок APP протокола RTCP

Имя

QoS_Metrics

Зависящие от приложения данные

Audiogap_ave 105,5 6000 Audiogap_max 123 500

Если предоставляются отчеты об измерениях или событиях вместо вычисленной метрики, то описание события может включать в себя более одного значения. Это может представлять интерес, например, если в течение периода предоставления отчета имеются два отдельных события, когда пакеты RTP теряются.

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

OPTIONS rtsp://example.com/foo/bar/baz.3gp RTSP/1.0

Cseq: 302

Session: 17903320

QoS-Feedback:

url="rtsp://example.com/foo/bar/baz.3gp/trackID=3";Vcorruption_dur (продолжительность искажения)={100 6000, 215,4 11000};Lost_RTP (потерянные пакеты)={3 6000, 5 11000}

url="rtsp://example.com/foo/bar/baz.3gp/trackID=5";

Acorruption_dur={97 6000, 221 11000}

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

Заголовок RTCP

Блок отчета

Конкретное расширение профиля

Acorruption_dur 97 6000 Acorruption_dur 221 11000

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

Заголовок APP протокола RTCP

Имя

QoS_Metrics

Зависящие от приложения данные

Acorruption_dur 97 6000 Acorruption_dur 221 11000

Возможно, что либо сервер 20 потоковой передачи, либо клиент 30 желает изменить согласованные параметры в течение сеанса. Сервер 20 может пожелать, например, некоторую информацию более часто, тогда как клиент 30, возможно, известит, что он не может обеспечивать такое количество параметров, как согласовано. Также является возможным отключить полностью посылку метрик QoS. Чтобы вновь запустить ее позднее, клиент 30 потоковой передачи или сервер 20 потоковой передачи может послать новый запрос. В течение продолжающегося сеанса потоковой передачи является возможным использовать любое сообщение RTSP для повторного согласования параметров метрик QоS. Любое изменение первоначально согласованного предоставления отчета также относится к категории сообщения 7, показанного на фиг.4.

Нижеследующее является примером осуществляемого клиентом 30 или сервером 20 в течение сеанса запроса на изменение или запроса клиентом 30 или сервером 20 в течение сеанса повторного запуска после того, как метрики QoS были отключены:

C->S, S->C OPTIONS rtsp://example.com/foo/bar/baz.3gp/trackID=5 RTSP/1.0   Cseq: 302   Session: 17903320   QoS-Metrics: metrics=AudioGap_ave,AudioGap_num,   AudioGap_max;rate=20

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

S->C, C->S RTSP/1.0 200 OK   Cseq: 302   Session: 17903320   QoS-Metrics: metrics=AudioGap_ave,AudioGap_num,   AudioGap_max;rate=20

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

S->C, C->S RTSP/1.0 200 OK   Cseq: 302   Session: 17903320   QoS-Metrics: metrics=AudioGap_ave, AudioGap_max;rate=20

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

Нижеследующее является примером сообщения, выполняемого клиентом 30 или сервером 20 в течение сеанса, чтобы установить отключение метрик:

C->S, S->C OPTIONS rtsp://example.com/foo/bar/baz.3gp RTSP/1.0   Cseq: 302   Session: 17903320   QoS-Metrics: Off

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

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

C->S, S->C RTSP/1.0 200 OK   Cseq: 302   Session: 17903320   QoS-Metrics: Off

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

S->C, C->S RTSP/1.0 200 OK   Cseq: 302   Session: 17903320   QoS-Metrics:metrics=AudioGap_ave, AudioGap_max; rate=20

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

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

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

Описанный способ дает возможность передавать большее количество информации, чем в вышеупомянутом документе совещания Meeting № 28 TSG-S4 проекта 3GPP. Дополнительно, представленный способ выполняет установку (сеанса) быстрее, поскольку требуется меньшее количество сообщений. Предлагаемый способ также имеет преимущество, что дает возможность согласовывать каждую используемую метрику. Кроме того, он обеспечивает возможность повторного согласования посылки метрик в середине сеанса в случае необходимости, а также в случае необходимости устанавливать отключение посылки метрик полностью.

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

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

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

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

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

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

4. Способ по п.1, в котором упомянутую передачу выполняют в течение сеанса между первым устройством и вторым устройством для конкретной услуги.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

23. Устройство по п.12, причем упомянутое устройство является мобильным телефоном.

24. Устройство по п.12, причем упомянутое устройство является сетевым элементом сети.

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

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

27. Способ по п.26, в котором протокольное сообщение является одним из следующего: сообщением протокола потоковой передачи в реальном времени, сообщением протокола управления передачей в реальном времени, сообщением протокола инициации сеанса или описанием по протоколу описания сеанса.

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

29. Способ по п.26, в котором упомянутую передачу выполняют в течение сеанса между первым устройством и вторым устройством для конкретной услуги.

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

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

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

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

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

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

36. Устройство по п.34, в котором протокольное сообщение является одним из следующего: сообщением протокола потоковой передачи в реальном времени, сообщением протокола управления передачей в реальном времени, сообщением протокола инициации сеанса или описанием по протоколу описания сеанса.

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

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

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

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

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

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

43. Устройство по п.34, причем устройство является мобильным телефоном.

44. Устройство по п.34, причем устройство является сетевым элементом сети.

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