Область техники, к которой относится изобретение
Настоящее изобретение касается сетей подвижной связи, включая сквозное управление качеством обслуживания (КО), и, более конкретно, касается динамического санкционирования данных различного формата и управления классами КО сеанса связи (соединения между пользователями или подвижными терминалами, или между подвижным терминалом и сервером), содержащего множество разных типов потоков данных различного формата в пределах сетей подвижной связи.
Уровень техники
Современные сети подвижной связи типа сетей, стандартизированных посредством спецификаций 3GPP (Проект партнерства 3-его поколения), включая все сети ГСМС (Глобальной системы мобильной связи) и 3-и поколения сетей ГСМС, являются бесшовной интеграцией сетей цифровой сотовой связи и систем персональной связи, с целью обеспечения телекоммуникационных сервисных функций, включая, например, сервисные функции сетей передачи данных подвижным объектам и мультимедийные сервисные функции МП (межсетевого протокола).
Каждая система 3GPP может включать в себя базовую сеть и инфраструктуру сети радиосвязи с абонентами, использующую технологии общих услуг пакетной радиосвязи (ОУПР) и расширенных скоростей передачи данных для глобального развития (РСПГР), или поддерживающую универсальную наземную радиосвязь с абонентами (УНРА), действующую и при дуплексной связи с частотным разделением (ДСЧР), и при дуплексной связи с временным разделением (ДСВР). Базовая сеть (БС) логически может быть разделена на домены с коммутацией каналов (КК) и домены с коммутацией пакетов (КП), с объектами БС, предусмотренными для трафика пользователя и связанной передачи сигналов, и мультимедийную подсистему МП (МПС МП) с объектами базовой сети (БС), предусмотренными для мультимедийных сервисных функций МП. Некоторые объекты БС типа домашнего сервера абонента (ДСА), домашнего регистра (ДР), центра аутентификации (ЦА), гостевого регистра (ГР) и регистра идентификации аппаратуры (РИА) могут быть общими для доменов КП и КК, в то время как другие объекты БС типа центра коммутации подвижной связи (ЦКПС) и межсетевого коммутационного центра подвижной связи МКЦПС являются специфичными для домена КК, предназначенными для оперирования сервисными функциями с коммутацией каналов на/от подвижных станций, а такие, как узел поддержки ОУПР (общих услуг пакетной радиосвязи) межсетевого интерфейса (УПОМИ) и УПО обслуживания (УПОО) являются специфичными для домена КП, предназначенными для оперирования передачей пакетов на/от подвижных станций.
Для мультимедийных сервисных функций МП можно обеспечивать функциональные объекты МПС МП типа функции управления запросом сеанса связи (ФУЗСС), чтобы оперировать связанными с ФУЗСС процедурами, включая установление контекста ПОПД (протокола обмена пакетированными данными, например, МП) для связанной с МПС МП передачи сигналов, регистрации и других процедур для сеансов связи МПС МП. ФУЗСС может действовать как ФУЗСС представительства (ФУЗСС-П), чтобы служить в качестве первой контактной точки для пользовательского оборудования (ПО) (то есть, устройства, обеспечивающего пользователю доступ к сетевым службам, например к подвижному терминалу) в пределах мультимедийной подсистемы МП (МПС МП), ФУЗСС обслуживания (ФУЗСС-О), чтобы оперировать режимами сеанса связи в сети, или как ФУЗСС запрашивания (З-ФУЗСС), чтобы служить в качестве контактной точки в пределах сети оператора для всех соединений МПС МП, предназначенных либо для абонента этого сетевого оператора, либо для абонента роуминга (автоматической настройки на локальные сети связи) в данной зоне обслуживания. См., например, 3GPP Техническое описание (TS) 23.002, V5.9.0 (декабрь 2002 г.) "Сетевая архитектура"; 3GPP TS 23.101, V4.0.0 (апрель 2002 г.) "Общая архитектура УСМЭ (универсальной системы мобильной электросвязи)"; и 3GPP TS 23.110, V4.0.0 (апрель 2001 г.) "Уровень декомпозиции доступа УСМЭ: услуги и функции"; и 3GPP Техническое описание (TS) 23.228, V6.0.1 (январь 2003 г.) "Мультимедийная подсистема МП (МПС МП)". Все спецификации 3GPP (GSM/3G) можно найти и загрузить из сервера 3GPP с адресом ftp://ftp.3gpp.org/specs, и все они тем самым включены здесь путем ссылки. Помимо этого, механизмы для создания, поддержания и корректирования спецификаций 3GPP (включая различные Редакции данной спецификации 3GPP с новыми или измененными функциональными возможностями) также можно найти в 3GPP Техническом описании (TS) 21.900 V5.0.1 (сентябрь 2002 г.) "Способы групповой работы технического описания".
Функция принятия стратегических решений (ФПСР) была стандартизирована для осуществления контроля управления классами качества обслуживания (КО) сеанса связи, содержащего множество потоков данных различного формата, которая делает стратегические решения на основании информации, связанной с сеансом связи и данными различного формата, включая максимальный санкционированный класс трафика для заданного потока данных различного формата между двумя пользователями (подвижными терминалами), или между подвижным терминалом и сервером, и затем обменивается информацией для принятия решения с УПОМИ через интерфейс Go, как сформулировано в 3GPP TS 29.207 V.5.2.0 (декабрь 2002 г.) "Стратегический контроль через Интерфейс Go", Редакция 5; 3GPP TS 23.207 V.5.6.0 (декабрь 2002 г.) "Концепция и архитектура качества обслуживания (КО) сквозной передачи", Редакция 5; и 3GPP TS 29.208 V.5.2.0 (декабрь 2002 г.) "Потоки сквозной сигнализации качества обслуживания (КО)", Редакция 5. Такая ФПСР может быть встроена в ФУЗСС-П, как сформулировано в спецификации 3GPP, Редакция 5 (декабрь 2002 г.), или в качестве альтернативы, может быть реализована в отдельном сетевом элементе, который является отдельным от ФУЗСС-П, как сформулировано в спецификации 3GPP, Редакция 6 (январь 2003 г.).
В общем, когда между пользовательскими оборудованиями (ПО) (например, подвижными терминалами) или между подвижным терминалом и сервером установлен сеанс связи (соединение), и сеанс связи изменяется (например, с сеанса связи двунаправленного звукового сигнала и однонаправленного видеосигнала только на сеанс связи однонаправленного видеосигнала), ФПСР изменяет класс трафика (с диалогового на потоковый). Это происходит потому, что сеанс связи, когда он установлен между пользовательскими оборудованиями (ПО) (например, подвижными терминалами), или между подвижным терминалом и сервером, содержит двунаправленный поток звукового сигнала и однонаправленный поток видеосигнала. Двунаправленный поток звукового сигнала используется для разговора в реальном масштабе времени и, следовательно, требует класс трафика в реальном масштабе времени с малой задержкой, то есть, ДИАЛОГОВЫЙ класс трафика. Однонаправленный поток видеосигнала используется для передачи движущихся видеоизображений только в одном направлении. Такой однонаправленный поток видеосигнала в реальном масштабе времени допускает более длительные задержки в передаче сигналов и изменения задержек (a.k.a. (известные также как) "флуктуация"), потому что отправитель не ожидает приема каких-либо ответов. В результате, на практике для однонаправленного потока в реальном масштабе времени обычно используется ПОТОКОВЫЙ класс трафика. Если сеанс связи изменяется, то есть, если один из двунаправленного потока звукового сигнала и однонаправленного потока видеосигнала заканчивается и удаляется из сеанса связи, класс трафика для ресурсов однонаправленного канала сеанса связи должен быть изменен ФПСР соответствующим образом. Например, если двунаправленный поток звукового сигнала с ДИАЛОГОВЫМ (CONVERSIONAL) классом трафика исключается из сеанса связи, однонаправленный поток видеосигнала с ПОТОКОВЫМ классом трафика, как требуется по умолчанию, теперь имеет "самый высокий класс трафика" сеанса связи. Следовательно, ФПСР изменяет (то есть, понижает) класс трафика для однонаправленного канала сеанса связи с ДИАЛОГОВОГО класса трафика на ПОТОКОВЫЙ класс трафика.
Однако некоторые параметры типа размера буфера в принимающем терминале в этих классах трафика являются разными, изменение класса трафика с присущим изменением задержки передачи сигналов вызовет исчезновения значащих разрядов буфера в принимающем терминале или сервере, таким образом снижая качество соединения, воспринимаемое конечным пользователем.
Другая значительная проблема может возникать, когда однонаправленный поток (например, видеосигнала) добавляется к существующему сеансу связи, содержащему двунаправленный поток (например, звукового сигнала). Сообщаемый запрос класса трафика однонаправленного потока видеосигнала обычно является потоковым. Класс трафика двунаправленного сеанса связи является диалоговым. Если потоки данных различного формата имеют временное соотношение (например, устное пояснение потока видеосигнала в потоке звукового сигнала), различие классов трафика вызовет различие в задержках передачи сигналов (из-за разных протяженностей буферов в приемных устройствах, чтобы компенсировать разные задержки и флуктуацию времени задержки в передаче), таким образом снижая качество соединения, воспринимаемое конечным пользователем.
Соответственно, имеется необходимость в решениях, которые могут быть подходящими для всех систем, в которых сеанс связи (соединение между пользователями или подвижными терминалами, или между подвижным терминалом и сервером) может содержать множество различных типов потоков данных различного формата, и которые касаются динамического санкционирования данных различного формата и лучшего управления классами качества обслуживания (КО) сеанса связи (соединения между пользователями или подвижными терминалами, или между подвижным терминалом и сервером), содержащего множество различных типов потоков данных различного формата в пределах сетей подвижной связи, таких, что, когда поток (потоки) данных различного формата во время сеанса связи изменяе(ю)тся (новые потоки начинаются, а существующие потоки исключаются), класс трафика сеанса связи определяется в соответствии с самым высоким требованием класса трафика, определяемым потоками данных различного формата, принадлежащими одному и тому же сеансу связи, с целью устранения различия в задержках передачи потоков данных различного формата, принадлежащих к одному и тому же сеансу связи, и, следовательно, улучшая качество соединения, воспринимаемое конечным пользователем.
Раскрытие сущности изобретения
Различные аспекты настоящего изобретения направлены на решения задачи динамического санкционирования данных различного формата и лучшего управления классами качества обслуживания (КО) сеанса связи (соединения между пользователями или подвижными терминалами, или между подвижным терминалом и сервером), содержащего множество различных типов потоков данных различного формата в пределах сетей подвижной связи, так что, когда во время сеанса связи один или более потоков данных различного формата изменяются (новые потоки запускаются, а существующие потоки исключаются), класс трафика сеанса связи определяется в соответствии с самым высоким требованием класса трафика, определяемым потоками данных различного формата, принадлежащими тому же сеансу связи, чтобы исключить различие в задержках передачи потоков данных различного формата, принадлежащих одному и тому же сеансу связи, и поэтому улучшая качество соединения, воспринимаемое конечным пользователем.
В соответствии с одним аспектом настоящего изобретения, в сети подвижной связи обеспечена функция принятия стратегических решений (ФПСР) для определения максимального санкционированного класса трафика для заданного потока данных различного формата сеанса связи между двумя подвижными терминалами, или между подвижным терминалом и сервером. Такая ФПСР сконфигурирована для определения, исключены ли из сеанса связи один или несколько потоков данных различного формата, требующие самый высокий класс трафика в пределах множества разных типов потоков данных различного формата, когда сеанс связи установлен и изменяется между двумя подвижными терминалами или между подвижным терминалом и сервером, через линию связи; и поддерживания используемого класса трафика для остающихся потоков данных различного формата для сеанса связи, если из сеанса связи исключены один или несколько потоков данных различного формата, требующих самый высокий класс трафика.
В соответствии с другим аспектом настоящего изобретения, конфигурирована функция принятия стратегических решений (ФПСР) для определения, добавляется ли однонаправленный поток к сеансу связи, содержащему двунаправленный поток, когда сеанс связи устанавливается или изменяется между двумя подвижными терминалами или между подвижным терминалом и сервером, через линию связи; и применения самого высокого класса трафика, назначенного для какого-либо из потоков данных различного формата сеанса связи, для всех потоков данных различного формата сеанса связи в течение времени существования сеанса связи, если к сеансу связи, содержащему двунаправленный поток в сети подвижной связи, добавляется однонаправленный поток, для определения максимального санкционированного класса трафика для заданного потока данных различного формата сеанса связи между двумя подвижными терминалами или между подвижным терминалом и сервером, через линию связи.
В соответствии с еще одним аспектом настоящего изобретения, обеспечен машиночитаемый носитель информации с командами, которые при выполнении сетью подвижной связи исполняют способ определения максимального санкционированного класса трафика для заданного потока данных различного формата сеанса связи между двумя подвижными терминалами или между подвижным терминалом и сервером, включающий в себя определение, добавляется ли однонаправленный поток к сеансу связи, содержащему двунаправленный поток, когда сеанс связи устанавливается или изменяется между двумя подвижными терминалами, или между подвижным терминалом и сервером, через линию связи; и применение самого высокого класса трафика, назначенного для какого-либо из потоков данных различного формата сеанса связи, для всех потоков данных различного формата сеанса связи в течение времени существования сеанса связи, если к сеансу связи, содержащему двунаправленный поток, добавляется однонаправленный поток.
Настоящее изобретение более определенно описано в нижеследующем описании со ссылкой на чертежи, прилагаемые только в качестве примера.
Краткое описание чертежей
Более полная оценка настоящего изобретения и многих из его сопутствующих преимуществ станут очевидными, когда они станут лучше понятны в отношении последующего подробного описания при его рассмотрении совместно с прилагаемыми чертежами, на которых подобные ссылочные позиции обозначают те же или аналогичные компоненты, и на которых:
фиг.1 иллюстрирует примерную архитектуру сетевой системы для обеспечения телекоммуникационных сервисных функций, включая мультимедийные сервисные функции МП в соответствии со спецификациями 3GPP, Редакция 5;
фиг.2 иллюстрирует примерную архитектуру интерфейса функциональных объектов МПС МП в соответствии со спецификациями 3GPP, Редакция 5;
фиг.3 иллюстрирует примерную архитектуру интерфейса функциональных объектов МПС МП согласно варианту осуществления настоящего изобретения;
фиг.4 иллюстрирует примерный рабочий сеанс связи между двумя пользовательскими оборудованиями (подвижными терминалами), или между подвижным терминалом и сервером, с использованием новых правил отображения, когда потоки данных различного формата являются однонаправленными и имеют одинаковое направление, согласно варианту осуществления настоящего изобретения;
фиг.5 иллюстрирует примерный рабочий сеанс связи между двумя пользовательскими оборудованиями (подвижными терминалами), или между подвижным терминалом и сервером, с использованием новых правил отображения, когда потоки данных различного формата являются однонаправленными и не имеют одинакового направления, согласно варианту осуществления настоящего изобретения;
фиг.6 иллюстрирует примерный рабочий сеанс связи между двумя пользовательскими оборудованиями (подвижными терминалами) или между подвижным терминалом и сервером, с использованием новых правил отображения, когда один поток данных различного формата является двунаправленным, а другой является однонаправленным, согласно варианту осуществления настоящего изобретения; и
фиг.7 иллюстрирует примерный рабочий сеанс связи между двумя пользовательскими оборудованиями (подвижными терминалами) или между подвижным терминалом и сервером, с использованием новых правил отображения, когда один поток данных различного формата является двунаправленным (не звукового сигнала/видеосигнала), а другой является однонаправленным (звукового сигнала/видеосигнала), согласно варианту осуществления настоящего изобретения.
Лучший вариант осуществления изобретения
Настоящее изобретение является подходящим для использования со всеми типами сетей, поддерживающих множество различных типов потоков данных различного формата, включая, например, сети ГСМС (Глобальной системы мобильной связи) 2-ого и 3-его поколения, транзитные сети типа Интернет, Intranet, локальные сети связи (ЛСС) и основанные на АПД (асинхронной передаче данных) транзитные сети, и многократные поля коммутации типа коммутируемых телефонных сетей общего пользования (КТСОП), ЦСИФ (цифровые сети с интеграцией функций), сети МП/сети ЛСС, X.25 и сети связи общего пользования наземных подвижных объектов (ССОП НПО) и взаимосвязанные системы и связанные с ними протоколы, используемые для передач речевых сигналов, сообщений, данных и изображений между системами в таких сетях подвижной связи. Однако ради простоты обсуждения будут сконцентрированы главным образом на простой мультимедийной сети, включающей в себя объекты мультимедийной подсистемы МП (МПС МП) для обеспечения мультимедийных сервисных функций МП.
Теперь внимание будет направлено на чертежи, и в частности, на фиг.1, на которой иллюстрируется примерная архитектура сетевой системы для обеспечения телекоммуникационных сервисных функций, включая мультимедийные сервисные функции МП согласно спецификации 3GPP, Редакции 5. Как показано на фиг.1, архитектура 100 сетевой системы может в общих чертах включать в себя, например, инициирующее пользовательское оборудование (ПО) 110, оконечное пользовательское оборудование (ПО) 120, или наоборот, и линию связи 130, выполненную с возможностью подключения пользовательских оборудований (ПО) 110/120, и которая может охватывать единственную сеть или различные сети, например типа сети связи общего пользования наземных подвижных объектов (ССОП НПО) 132, одной или более транзитных сетей 134 и многократного поля 136 коммутации. Пользовательское оборудование (ПО) 110/120 может быть любым устройством или пользовательским терминалом для обеспечения пользователю возможности доступа к сетевым службам, включая, например, удаленный сервер или подвижный терминал для ГСМС, как определено в 3GPP TS 24.002, V5.0.0 (декабрь 2001 г.), Редакция 5.
Каждое ПО 110/120 может включать в себя, например, передвижное оконечное устройство (ПОУ) 112, терминальное оборудование (ТО) 114 и терминальную функцию адаптации (ТФА) 116, выполненную с возможностью осуществления радиопередачи и связанных функций, и которая может содержать сквозные приложения, чтобы поддерживать телекоммуникационные сервисные функции.
Транзитная сеть 134 может включать в себя, но не ограничена этим, Интернет, Intranet, локальную сеть связи (ЛСС) или основанную на АПД транзитную сеть. Многократное поле 136 коммутации может включать в себя, но не ограничено этим, коммутируемую телефонную сеть общего пользования (КТСОП), ЦСИФ, сеть МП/ЛСС, X.25 или другую сеть связи общего пользования наземных подвижных объектов (ССОП НПО).
Фиг.2 иллюстрирует примерную архитектуру интерфейса функциональных объектов МПС МП в сетях подвижной связи согласно спецификации 3GPP, Редакции 5. Как показано на фиг.2, узел поддержки ОУПР (общих услуг пакетной радиосвязи) межсетевого интерфейса (УПОМИ) 210 и функция управления запросом сеанса связи представительства (ФУЗСС-П) 220 представляют сетевые объекты, которые являются частью базовой сети. УПОМИ 210 может использоваться для оперирования пакетной передачей на/от ПО 110/120 (например, подвижных станций). ФУЗСС-П 220 может использоваться, чтобы служить в качестве первой контактной точки для данного ПО 110/120 и обеспечивать услуги управления сеанса связи и связанными с ФУЗСС процедурами, включая установление контекста ПОПД (протокола обмена пакетированными данными, например, МП) для мультимедийной подсистемы МП (МПС МП), связанной с передачей сигналов, регистрацией и другими процедурами для сеансов связи МПС МП.
Согласно спецификации 3GPP, Редакции 5 (декабрь 2002 г.), в ФУЗСС-П 220 встроена функция принятия стратегических решений (ФПСР) 222, чтобы контролировать сеанс связи МПС МП, когда ПО 110 выпускает или принимает сообщение ПИСС (протокола инициирования сеанса связи), содержащее передачу сигналов ПОСС (протокол описания сеанса связи), чтобы согласовывать параметры для сеанса связи МПС МП, принимая стратегические решения на основании связанной с сеансом связи МПС МП и данными различного формата информацией, полученной от ФУЗСС-П 220, включая решения относительно максимального санкционированного класса трафика для заданного потока данных различного формата между двумя пользователями (например, подвижными терминалами) или между подвижным терминалом и сервером и затем обмениваться информацией для принятия решения с УПОМИ 210 через интерфейс Go, как сформулировано в 3GPP TS 29.207 V.5.2.0 (декабрь 2002 г.) "Стратегический контроль через интерфейс Go", Редакция 5. Кроме того, для каждого контекста ПОПД (протокола обмена пакетированными данными, например, МП) допускается только один сеанс связи МПС МП. В качестве альтернативы, ФПСР также может быть реализована в отдельном сетевом элементе, который является отдельным от ФУЗСС-П 220, как описано в спецификации 3GPP, Редакции 6 (январь 2003 г.).
Как предварительно обсуждалось и как сформулировано в спецификации 3GPP, Редакции 5, ФПСР 222 может использоваться для генерирования совокупности информации связывания (главным образом, средства идентификации санкционирования), чтобы связать уровень МПС МП и уровень однонаправленного канала ОУПР сеанса связи МПС МП, и посылать информацию связывания в УПОМИ 210 через пользовательское оборудование (ПО) 110. Информация связывания сопоставляет контекст ПОПД (протокола обмена пакетированными данными, например, МП) с одним или более компонентами данных различного формата (потоками МП) сеанса связи МПС МП и используется УПОМИ 210 для запроса информации локальной стратегии на основе обслуживания (ЛСОО) от ФПСР 222. Такая информация связывания обычно включает в себя:
(1) средство идентификации санкционирования, посылаемое ФУЗСС-П 220 на ПО 110 во время передачи сигналов ПИСС/ПОСС, и
(2) один или более идентификаторов потока (которые могут быть добавлены ПО 110 после приема информации связывания от ФУЗСС-П/ФПСР), используемые ПО 110, УПОМИ 210 и ФПСР 222, чтобы уникально идентифицировать поток (потоки) данных различного формата МП, связанные с сеансом связи ПИСС.
При приеме такой информации связывания УПОМИ 210 затем используется для поиска адреса ФПСР из совокупности информации связывания (из средства идентификации санкционирования), принятой от ПО 110, идентифицирования правильной ФПСР и верифицирования, что операции контекста ПОПД, запрашиваемые ПО 110, действуют в соответствии с предшествующим согласованием на уровне МПС МП.
В УПОМИ 210 пункт приведения в исполнение стратегии (ППС) 212 является логическим объектом, который поддерживает связь с ФПСР относительно управления локальной стратегией на основе обслуживания (ЛСОО). Для простоты полагается, что УПОМИ 210 не явно содержит ППС 212, если не указано иначе. УПОМИ 210 посылает запросы в ФПСР 222 и принимает от нее решения. УПОМИ 210 может помещать в кэш данные стратегических решений ФПСР, которые могут использоваться позже для локальных стратегических решений, обеспечивая возможность УПОМИ 210 выполнять решение стратегического управления относительно санкционирования качества обслуживания (КО) для модификаций контекста ПОПД без требования дополнительного взаимодействия с ФПСР 222. Функциональные возможности ППС для ЛСОО в УПОМИ описаны в 3GPP TS 29.207 V.5.2.0 (декабрь 2002 г.) "Стратегический контроль через интерфейс Go", Редакция 5, и включены здесь путем ссылки, и, следовательно, повторять здесь их не требуется.
Как ПО 110, так и УПОМИ 210 также могут включать в себя механизмы для управления сквозными функциями качества обслуживания (КО) МП и связанными потоками передачи сигналов, как описано в 3GPP TS 23.207 V.5.6.0 (декабрь 2002 г.) "Концепция и архитектура качества обслуживания (КО) сквозной передачи", Редакция 5; и 3GPP TS 29.208 V.5.2.0 (декабрь 2002 г.) "Потоки сквозной сигнализации качества обслуживания (КО)", Редакция 5, и включено здесь путем ссылки. Например, ПО 110 может включать в себя клиентское приложение (не показанное), программу-менеджера обслуживания однонаправленного канала МП (ООК) (не показанную), функцию преобразования/отображения (не показанную) и, если требуется, программу-менеджера обслуживания однонаправленного канала (ООК) УСМЭ (не показанную). Аналогично этому, УПОМИ 210 также может включать в себя программу-менеджера ООК МП (не показанную), функцию преобразования/отображения (не показанную) и, если требуется, программу-менеджера ООК УСМЭ (не показанную). Программы-менеджеры ООК МП обычно используют стандартные механизмы МП для управления обслуживанием однонаправленного канала МП. Функции преобразования/отображения обеспечивают взаимодействие между механизмами и параметрами, используемыми в обслуживании однонаправленного канала УСМЭ, и используемыми в обслуживании однонаправленного канала МП, и взаимодействуют с программами-менеджерами ООК МП. Программы-менеджеры ООК УСМЭ используют стандартные механизмы УСМЭ для управления обслуживанием однонаправленного канала УСМЭ (универсальной мобильной системы электросвязи) и функциями управления качеством обслуживания для обслуживания однонаправленного канала УСМЭ.
В общем, между пользовательскими оборудованиями (ПО) (например, подвижными терминалами, способными передавать и принимать мультимедийные потоки МП) или между подвижным терминалом и сервером устанавливается сеанс связи (соединение). Сеанс связи, когда он устанавливается между пользовательскими оборудованиями (ПО) (например, подвижными терминалами), или между подвижным терминалом и сервером, содержит, например, двунаправленный поток звукового сигнала и однонаправленный поток видеосигнала. Двунаправленный поток звукового сигнала используется для разговора в реальном масштабе времени, и, следовательно, для него требуется класс трафика в реальном масштабе времени с малой задержкой, то есть, ДИАЛОГОВЫЙ класс трафика. Однонаправленный поток видеосигнала используется для передачи движущихся видеоизображений только в одном направлении. Такой однонаправленный поток видеосигнала в реальном масштабе времени допускает более длительные задержки передачи сигналов и изменения задержки (a.k.a. флуктуация), потому что отправитель не ожидает приема какого-либо ответа. В результате, для однонаправленного потока в реальном масштабе времени на практике обычно используется ПОТОКОВЫЙ класс трафика. ДИАЛОГОВЫЙ класс трафика отличается короткой максимальной задержкой передачи сигналов и изменением задержки, чтобы снизить до минимума задержку, испытываемую поддерживающими связь сторонами (то есть, подвижными терминалами, или связь между подвижным терминалом и сервером), тогда как ПОТОКОВЫЙ класс трафика отличается более длительной максимальной задержкой передачи сигналов и изменением задержки, потому что нет двусторонней связи в реальном масштабе времени с ожидаемыми ответами в реальном масштабе времени. В результате, ДИАЛОГОВЫЙ класс трафика известен как "более высокий класс трафика" по сравнению с ПОТОКОВЫМ классом трафика, который известен как "более низкий класс трафика".
Согласно 3GPP TS 23.107, могут быть другие классы трафика, требуемые в примерном сеансе связи типа ИНТЕРАКТИВНОГО класса трафика и ФОНОВОГО класса трафика. Например, ИНТЕРАКТИВНЫЙ класс трафика может отличаться тем, что допускает еще более длительные задержки передачи сигналов и флуктуацию, чем ПОТОКОВЫЙ класс трафика, а следовательно, является "более низким классом трафика", чем ПОТОКОВЫЙ класс трафика. ФОНОВЫЙ класс трафика может отличаться тем, что допускает еще более длительные задержки передачи сигналов и флуктуацию, и в результате, является еще более низким классом трафика, чем ИНТЕРАКТИВНЫЙ класс трафика. Однако потоки звукового сигнала и видеосигнала примерного сеанса связи могут переноситься одним и тем же однонаправленным каналом (например, контекстом ПОПД в сетевой системе), или могут иметь временное соотношение друг с другом, означающее, что ресурсы однонаправленного канала целого сеанса связи имеют ДИАЛОГОВЫЙ класс трафика в соответствии с "самым высоким классом трафика" сеанса связи.
Через некоторое время сеанс связи может измениться, а именно, поддерживающие связь стороны (то есть, подвижные терминалы, или связь между подвижным терминалом и сервером) могут пожелать прервать, например, двунаправленный поток звукового сигнала в сеансе связи, в то же время поддерживая однонаправленный поток видеосигнала в сеансе связи. Класс трафика для ресурсов однонаправленного канала сеанса связи должен быть изменен соответствующим образом посредством ФПСР. Например, если сеанс связи изменяется, и двунаправленный поток звукового сигнала с ДИАЛОГОВЫМ (CONVERSIONAL) классом трафика из сеанса связи исключается, однонаправленный поток видеосигнала, с ПОТОКОВЫМ классом трафика, как требуется по умолчанию, теперь имеет "самый высокий класс трафика" сеанса связи. Следовательно, ФПСР изменяет (то есть, понижает) класс трафика для однонаправленного канала сеанса связи с ДИАЛОГОВОГО класса трафика на ПОТОКОВЫЙ класс трафика.
Однако, когда сеанс связи изменяется (например, с двунаправленного звукового сигнала и однонаправленного видеосигнала только на сеанс связи однонаправленного видеосигнала), и класс трафика изменяется посредством ФПСР 222 (например, с диалогового на потоковый), некоторые параметры типа размера буфера в принимающем терминале являются разными в этих классах КО, и изменение класса трафика с присущим изменением задержки передачи сигналов может вызывать исчезновения значащих разрядов буфера в принимающем терминале, таким образом снижая качество соединения, воспринимаемое конечным пользователем.
Например, когда устанавливается сеанс связи (соединение), подвижные терминалы, или подвижный терминал и сервер, начинают обмен информацией с помощью двунаправленного звукового потока. На этой стадии ФПСР 222 назначает для звукового потока максимальный санкционированный класс трафика, соответствующий ДИАЛОГОВОМУ. После прохождения некоторого времени один из подвижных терминалов, или из подвижного терминала и сервера, решает добавить в обмен информацией поток видеосигнала, и поток видеосигнала является однонаправленным. На этой стадии ФПСР 222 проверяет текущую совокупность мультимедийных потоков МП, принадлежащих сеансу связи (соединению), и решает назначить для потока видеосигнала максимальный санкционированный класс трафика, соответствующий "ДИАЛОГОВОМУ". Этот класс выбирается потому, что уже имеется существующий двунаправленный поток данных различного формата, который санкционирован как "ДИАЛОГОВЫЙ" класс трафика. В результате подвижный терминал или сервер, принимающий и звуковой поток, и поток видеосигнала, может получать синхронизацию звукового сигнала-видеосигнала. После прохождения некоторого времени эти два подвижных терминала или подвижный терминал и сервер, решают прервать речевую связь, но продолжать однонаправленную передачу видеосигнала. На этой стадии ФПСР 222 проверяет текущую совокупность мультимедийных потоков МП, принадлежащих сеансу связи (в обмене информацией остается только однонаправленный поток видеосигнала), и решает изменить его на максимальный санкционированный "ПОТОКОВЫЙ" класс трафика. Это происходит потому, что однонаправленный поток данных различного формата всегда получает максимальный санкционированный класс трафика, соответствующий "ПОТОКОВОМУ".
Однако, если максимальный санкционированный класс трафика изменяется с "ДИАЛОГОВОГО" на "ПОТОКОВЫЙ", это изменение может создать проблемы для подвижного терминала или сервера, принимающего поток видеосигнала. В частности, изменение может вызвать повторное согласование контекста ПОПД, где отличается не только класс трафика, но также отличается и задержка передачи. В результате большая задержка передачи может производить частые и повторяющиеся исчезновения значащих разрядов буфера в принимающем подвижном терминале и приводить к прерывистым данным различного формата, приводя к более низкому качеству, воспринимаемому конечным пользователем. Это происходит из-за того, что буфер подвижного терминала или сервера имеет размер, соответствующий задержке передачи "ДИАЛОГОВОГО" класса трафика, а не "ПОТОКОВОГО" класса трафика.
Также может возникать другая значительная проблема, когда однонаправленный поток (например, видеосигнала) добавляется к существующему сеансу связи, содержащему двунаправленный поток (например, звукового сигнала). Сообщаемый запрос класса трафика однонаправленного потока видеосигнала обычно является потоковым. Класс трафика двунаправленного сеанса связи является диалоговым. Если потоки данных различного формата имеют временное соотношение (например, устное пояснение потока видеосигнала в потоке звукового сигнала), различие классов трафика вызовет разницу в задержках передачи сигналов (из-за разных протяженностей буферов в приемных устройствах, чтобы компенсировать различные задержки и флуктуации времени задержки в передаче), таким образом снижая качество соединения, воспринимаемое конечным пользователем.
Например, если сеанс связи (соединение) начинается с однонаправленным потоком. На этой стадии ФПСР 222 назначает "ПОТОКОВЫЙ" класс в качестве максимального санкционированного класса трафика. После прохождения некоторого времени к обмену информацией добавляется двунаправленный поток речевого сигнала. На этой стадии ФПСР 222 назначает для звукового потока максимальный санкционированный класс трафика, соответствующий "ДИАЛОГОВОМУ". ФПСР 222 также повторно проверяет максимальный санкционированный класс трафика первого существующего потока и корректирует его на "ДИАЛОГОВЫЙ". В некоторых случаях корректирование может запускать повторное согласование контекста ПОПД для мультимедийных потоков МП, в частности, когда мультимедийные потоки МП связаны и требуют синхронизации. Однако в большинстве случаев корректирование не требуется.
Обращаясь теперь к фиг.3, отметим, что там иллюстрируется примерная архитектура интерфейса функциональных объектов МПС МП согласно варианту осуществления настоящего изобретения. Архитектура интерфейса, как показано на фиг.3, благоприятно поддерживает используемый класс трафика для сеанса связи, то есть, для остальной части мультимедийных потоков МП, когда потоки данных различного формата, требующие самый высокий класс трафика, исключаются из сеанса связи, чтобы избегать проблем, возникающих при изменении класса трафика, и применяет самый высокий класс трафика (в реальном масштабе времени, то есть, диалоговый, потоковый), назначенный для какого-либо из потоков данных различного формата сеанса связи, для всех потоков данных различного формата (в реальном масштабе времени) сеанса связи в течение времени существования сеанса связи, чтобы избегать проблем, возникающих при добавлении потока данных различного формата к существующему сеансу связи.
Как показано на фиг.3, алгоритм 310 может быть реализован как часть ФПСР 222, независимо от того, встроена ли ФПСР 222 в ФУЗСС-П 220 или остается отдельным от ФУЗСС-П 220 сетевым объектом. В алгоритме 310 исключение одного или нескольких мультимедийных потоков в течение времени существования сеанса связи (соединения) может быть определено так, чтобы не понижать предварительно назначенный максимальный санкционированный класс трафика, и, аналогичным образом, добавление потоков данных различного формата может быть определено так, чтобы назначать максимальный класс трафика потоков для всех потоков (в реальном масштабе времени) сеанса связи (соединения). Использование такого алгоритма 310 может быть подходящим для всех систем, включая все будущие мультимедийные сети, в которых один сеанс связи может содержать множество различных типов потоков данных различного формата, и может соответствовать, например, 3GPP TS 23.207 V.5.6.0 (декабрь 2002 г.) "Концепция и архитектура качества обслуживания (КО) сквозной передачи", Редакция 5; и 3GPP TS 29.208 V.5.2.0 (декабрь 2002 г.) "Потоки сквозной сигнализации качества обслуживания (КО)", Редакция 5.
Синхронизация потоков данных различного формата в реальном масштабе времени также может быть улучшена посредством исключения разницы в задержках передачи потоков данных различного формата, принадлежащих одному и тому же сеансу связи, таким образом улучшая качество, воспринимаемое на целевом назначении. Может иметь место недостаток, заключающийся в том, что классы КО, назначенные некоторым потокам данных различного формата в сеансе связи, могут быть выше, чем требуется, таким образом снижая полную пропускную способность сети, и потенциально также вызывая более высокие затраты на соединения для конечного пользователя.
Например, пользователь/ПО начинает сеанс связи или продлевает сеанс связи с потоками более низкого класса трафика, с однонаправленным потоком (потоками) потокового класса. На этой стадии ФПСР 222 назначает "ПОТОКОВЫЙ" класс в качестве максимального санкционированного класса трафика для соответствующих потоков данных различного формата. Позже, в течение времени существования сеанса связи, пользователь/ПО запускает двунаправленный поток (например, звукового сигнала) в пределах того же самого сеанса связи. На этой стадии ФПСР 222 назначает для потока звукового сигнала максимальный санкционированный класс трафика, соответствующий "ДИАЛОГОВОМУ". ФПСР 222 также повторно проверяет максимальный санкционированный класс трафика уже существующего потока (потоков). Корректирование существующих потоков данных различного формата к значению класса трафика нового двунаправленного потока может не потребоваться, потому что однонаправленные потоки потокового класса были запущены до двунаправленных потоков диалогового класса и, следовательно, не могут иметь временное соотношение с двунаправленным потоком диалогового класса. Корректирование не требуется, потому что классы КО, назначенные некоторым потокам данных различного формата в сеансе связи, могут быть выше, чем требуемые, таким образом снижая полную пропускную способность сети, и потенциально также вызывая более высокие затраты на соединение для конечного пользователя.
Однако, корректирования можно избежать, если сначала запускается/запускаются однонаправленный поток (потоки) потокового класса, и рассматривается как независимый от более позднего двунаправленного потока или потоков, то есть, временных соотношений нет. Тогда синхронизация не требуется, то есть, когда добавится двунаправленный диалоговый поток данных различного формата, класс трафика останется "ПОТОКОВЫМ". (В системе МПС МП потоки с различными классами трафика/КО будут тогда использовать раздельные контексты ПОПД). В качестве альтернативы, если сначала запускается двунаправленный диалоговый поток, а позже к сеансу связи добавляется однонаправленный поток потокового класса, однонаправленный поток потокового класса рассматривается как зависящий от двунаправленного, то есть, между ними имеется временное соотношение. Тогда требуется синхронизация, то есть, класс трафика однонаправленного потока потокового класса будет установлен на такое же значение, как класс трафика двунаправленного потока, то есть, на "ДИАЛОГОВЫЙ" (посредством ФПСР 222). (В системе МПС МП потоки с различными классами трафика/КО могут тогда использовать общий контекст ПОПД или раздельные контексты ПОПД).
Как показано на фиг.3, ФПСР 222 может быть сконфигурирована для определения максимального санкционированного класса трафика для заданного потока данных различного формата соединения между двумя пользователями или подвижными терминалами, или между подвижным терминалом и сервером. Примерный алгоритм 310 в ФПСР 222 может включать в себя следующее:
If (если) для данного потока X назначен максимальный санкционированный класс трафика,
then (тогда)
добавление или исключение одного или нескольких потоков данных различного формата в течение времени существования сеанса связи (соединения) не производит никакого изменения для предварительно назначенного максимального санкционированного класса трафика для потока X.
Также могут потребоваться правила отображения в соответствии с 3GPP TS 29.208 V.5.2.0 (декабрь 2002 г.) "Потоки сквозной сигнализации качества обслуживания (КО)", Редакция 5, чтобы для потокового обслуживания можно было назначить подходящий максимальный санкционированный класс КО. Такие правила отображения могут использоваться ФПСР 222, как показано на фиг.3, при инициировании или изменении сеанса связи, для получения подходящего максимального санкционированного КО на компонент данных различного формата. Однако необходимо определить надлежащее отображение, чтобы гарантировать, что будущие сервисные функции не будут ограничены, а также можно было избегать неправильного применения, мошенничества и неэффективности. В общем, потоковое обслуживание может быть характеризовано направлением потока данных - оно является однонаправленным - и типом данных различного формата - звукового сигнала или видеосигнала. Таким образом, можно проанализировать все компоненты данных различного формата, принадлежащие одному сеансу связи. Например, если все компоненты данных различного формата звукового сигнала и видеосигнала являются однонаправленными и имеют одинаковое направление, приложение можно рассматривать как потоковое, и поэтому КО ограничивается потоковым, которое можно применять в качестве максимального санкционированного КО.
Обратимся теперь к фиг.4-7, на которых показаны примеры правил отображения. Например, фиг.4 иллюстрирует примерный рабочий сеанс связи между двумя пользовательскими оборудованиями (подвижными терминалами), когда потоки данных различного формата являются однонаправленными и имеют одинаковое направление согласно варианту осуществления настоящего изобретения. Фиг.5 иллюстрирует примерный рабочий сеанс связи между двумя пользовательскими оборудованиями (подвижными терминалами), когда потоки данных различного формата являются однонаправленными и не имеют одинакового направления согласно варианту осуществления настоящего изобретения. Фиг.6 иллюстрирует примерный рабочий сеанс связи между двумя пользовательскими оборудованиями (подвижными терминалам), когда один поток данных различного формата является двунаправленным, а другой поток является однонаправленным согласно варианту осуществления настоящего изобретения. Наконец, фиг.7 иллюстрирует примерный рабочий сеанс связи между двумя пользовательскими оборудованиями (подвижными терминалами), когда один поток данных различного формата является двунаправленным (незвукового сигнала/видеосигнала), а другой является однонаправленным (звукового сигнала/видеосигнала) согласно варианту осуществления настоящего изобретения.
В частности, на фиг.4, когда потоки данных различного формата (звукового сигнала и видеосигнала) являются однонаправленными и имеют одинаковое направление, санкционирование потока данных различного формата будет представлять собой "ПОТОКОВЫЙ". На фиг.5, когда потоки данных различного формата являются однонаправленными и не имеют одинакового направления, санкционирование потока данных различного формата будет представлять собой "ДИАЛОГОВЫЙ". На фиг.6, когда один поток данных различного формата является двунаправленным, а другой является однонаправленным, санкционирование потока данных различного формата будет "ДИАЛОГОВЫЙ". На фиг.7, когда один поток данных различного формата является двунаправленным (незвукового сигнала/видеосигнала), а другой является однонаправленным (звукового сигнала/видеосигнала), санкционирование потока данных различного формата будет "ДИАЛОГОВЫЙ" для приложения и "ПОТОКОВЫЙ" для видеосигнала.
Правила отображения могут быть расширены так, чтобы гарантировать надлежащее назначение максимального санкционированного класса КО в соответствии с требуемым обслуживанием. Правила, определяющие отображение параметров ПОСС для максимальных санкционированных классов КО, расширяются, например, таким образом, чтобы обеспечить возможность отображения потокового класса в случае компонентов однонаправленных данных различного формата типа "звукового сигнала" или "видеосигнала", имеющих одинаковое направление. Ниже приведены примеры правил отображения, которые могут использоваться ПО 110 (например, подвижным терминалом или сервером) и ФПСР 222, как показано на фиг.2 и фиг.3.
В частности, таблица № 1 иллюстрирует примерные правила отображения для получения максимальных санкционированных скоростей передачи данных и максимального санкционированного класса качества обслуживания (КО) на компонент данных различного формата в ФПСР 222. Такие примерные правила отображения могут быть упакованы в программном модуле, хранящемся или обеспеченном на пригодной для чтения компьютером среде, или в качестве альтернативы, их можно обеспечивать через подкачку из Интернета, или они могут быть встроены в ФПСР 222, как показано на фиг.2 и фиг.3. В соответствии с таблицей № 1 таблица № 2 иллюстрирует примерные правила отображения для получения максимальной санкционированной полосы пропускания и максимального санкционированного класса трафика на компонент данных различного формата в ПО 110 (например, подвижном терминале или сервере). Аналогичным образом такие правила отображения также могут быть упакованы в программном модуле, хранящемся или обеспеченном на пригодной для чтения компьютером среде, или в качестве альтернативы, их можно обеспечивать через подкачку из Интернета, или они могут быть встроены в ПО 110 (например, подвижный терминал или сервер), как показано на фиг.2 и фиг.3.
ФПСР 222, в течение продолжающегося сеанса связи, должна сохранять санкционированные параметры КО МП на компонент данных различного формата. Когда УПОМИ 210 запрашивает санкционированные параметры КО УСМЭ для активизированного/измененного контекста ПОПД, несущего один или более компонент (компонентов) данных различного формата, ФПСР 222 может использовать правила отображения, как показано, например, в таблице №2, чтобы вычислять санкционированные параметры КО МП.
ПО 110 в течение продолжающегося сеанса связи должно сохранять санкционированные параметры КО УСМЭ на компонент данных различного формата. Перед активизацией или изменением контекста ПОПД ПО 110 может проверить, что запрашиваемая Гарантируемая скорость передачи битов UL/DL (если класс трафика является диалоговым или потоковым) или запрашиваемая максимальная скорость передачи битов UL/DL (если класс трафика является интерактивным или фоновым) не превышает максимальную санкционированную полосу пропускания UL/DL на контекст ПОПД (рассчитываемую в соответствии с правилами отображения). Кроме того, ПО 110 может выполнять проверку так, чтобы запрашиваемый класс трафика параметра КО УСМЭ не превышал максимальный санкционированный класс трафика на контекст ПОПД (рассчитываемый в соответствии с правилами отображения).
Как описано выше, архитектура сетевого интерфейса согласно варианту осуществления настоящего изобретения обеспечивает решения для динамического санкционирования данных различного формата и лучшего управления классами КО сеанса связи (соединения между пользователями или подвижными терминалами, или между подвижным терминалом и сервером), содержащего множество различных типов потоков данных различного формата в пределах сетей подвижной связи, так что, когда во время сеанса связи один или несколько потоков данных различного формата в пределах множества разных типов потоков данных различного формата изменяются (новые потоки запускаются, а существующие потоки исключаются), класс трафика сеанса связи определяется в соответствии с самой высокой потребностью класса трафика, определяемой потоками данных различного формата, принадлежащими тому же сеансу связи, чтобы исключить различие в задержках передачи потоков данных различного формата, принадлежащих одному и тому же сеансу связи, и поэтому улучшая качество соединения, воспринимаемое конечным пользователем. Синхронизация потоков данных различного формата в реальном масштабе времени также может быть улучшена благодаря устранению различия в задержках передачи потоков данных различного формата, принадлежащих одному и тому же сеансу связи, таким образом улучшая качество, воспринимаемое на целевом назначении.
Хотя были проиллюстрированы и описаны варианты осуществления настоящего изобретения, которые, как здесь рассматривается, являются примерными, специалистам в данной области техники должно быть понятно, что можно делать различные видоизменения и модификации, и можно выполнять заменены элементов на эквивалентные, не выходя при этом за рамки истинного объема настоящего изобретения. Кроме того, можно делать множество модификаций, чтобы адаптировать конкретную ситуацию к положениям настоящего изобретения, не отходя при этом от главного объема настоящего изобретения. Поэтому предполагается, что настоящее изобретение не ограничено конкретным вариантом осуществления, раскрытым как предполагаемый лучший вариант осуществления для выполнения настоящего изобретения, но что настоящее изобретение включает в себя все варианты осуществления, попадающие в объем притязаний прилагаемой формулы изобретения.
Изобретение относится к сетям подвижной связи. Технический результат заключается в улучшении качества соединения. Когда во время сеанса связи потоки данных различного формата изменяются (новые потоки запускаются, а существующие потоки исключаются), класс трафика сеанса связи определяется в соответствии с самым высоким требованием класса трафика, определяемым потоками данных различного формата, принадлежащими одному и тому же сеансу связи, чтобы исключить различие в задержках передачи потоков данных различного формата, принадлежащих одному и тому же сеансу связи. 4 н.п. ф-лы, 7 ил., 2 табл.
СПОСОБ И УСТРОЙСТВО УПРАВЛЕНИЯ ПЕРЕДАЧЕЙ ПАКЕТОВ ДАННЫХ В КАНАЛЕ СВЯЗИ ОБЩЕГО ПОЛЬЗОВАНИЯ | 1997 |
|
RU2115246C1 |
Переносная печь для варки пищи и отопления в окопах, походных помещениях и т.п. | 1921 |
|
SU3A1 |
Переносная печь для варки пищи и отопления в окопах, походных помещениях и т.п. | 1921 |
|
SU3A1 |
WO 9816036 A1, 16.04.1998 | |||
WO 9709836 A1, 13.03.1997. |
Авторы
Даты
2007-04-27—Публикация
2004-02-10—Подача