СПОСОБ ВЫБОРА МУЛЬТИМЕДИЙНОГО ПОТОКА
METHOD OF SELECTING MULTIMEDIA STREAM

Область техники, к которой относится изобретение
Настоящее изобретение относится к способу и устройству для выбора мультимедийного потока в системе сотовой радиосвязи.
Уровень техники
В существующих системах сотовой радиосвязи сами мобильные станции отвечают за запрашивание подходящих контекстов протокола передачи пакетных данных (PDP) для данных услуг или мультимедийных потоков. Поскольку именно мобильные станции управляют согласованием PDP-контекстов, для любой данной мобильной станции является несложным то, чтобы коррелировать то, какие PDP-контексты должны использоваться для каких услуг или мультимедийных потоков.
В 3GPP версия 7 введен принцип запрошенного сетью качества обслуживания (QoS), см. также 3GPP TS 23.060, Общий сервис пакетной радиопередачи (General Packet Radio Service (GPRS)); Описание Сервиса (Service description); Стадия 2 (Stage 2). Основная идея состоит в том, чтобы разрешать владельцам радиоресурсов, операторам, определять то, какой тип однонаправленного канала следует использовать для данной услуги или мультимедийного потока.
Те же принципы должны использоваться, если система является EPS-системой, см. 3GPP TS 23.401 и 23.402. К примеру, если используется архитектура 23.401, то PDN GW используется вместо GGSN, MME вместо SGSN, и PDN-соединения или однонаправленные EPS-каналы используются вместо PDP-контекстов, а имена процедур являются другими.
Введение запрошенных сетью PDP-контекстов приводит к этому, точка принятия решения о том, какой PDP-контекст следует использовать для услуги или мультимедийного потока, перемещается от мобильной станции к сети. Это означает, что мобильная станция не контролирует привязку между PDP-контекстами и услугами/мультимедийными потоками, и как результат мобильная станция не может знать, какой PDP-контекст следует использовать для данной услуги или мультимедийного потока.
Следовательно, информация о том, какой тип PDP-контекста необходимо использовать для данной услуги/мультимедийного потока, должна сообщаться посредством сети мобильной станции. Уведомление относительно того, какой PDP-контекст следует использовать, является прямым процессом в случае, когда нет уже установленного подходящего PDP-контекста. Фиг.1 показывает поток сигналов для этого случая, поскольку он уже задан в 3GPP версии 7. Таким образом, когда нет уже установленного подходящего PDP-контекста, шлюзовой узел поддержки GPRS (GGSN) сначала получает триггер из структуры управления политиками относительно того, что новая услуга или мультимедийный поток запущен. Это приводит к выбору такой политики, что дополнительный PDP-контекст, использующий "процедуру активации вторичного PDP-контекста", должен быть установлен с определенным качеством обслуживания (QoS), выбранным посредством сетевых политик.
Затем GGSN передает в служебных сигналах информацию о том, какой PDP-контекст следует устанавливать, посредством отправки сообщения инициирования активации PDP-контекста с запрашиваемым QoS, шаблоном потока трафика (TFT), конфигурационными параметрами протокола (PCO) и т.д. Информация на этапе 2 перенаправляется в мобильный терминал посредством SGSN с использованием сообщения с запросом на активацию PDP-контекста. Мобильный терминал включает информацию, которую он принял на этапе 3, в "процедуру активации вторичного PDP-контекста", чтобы устанавливать новый PDP-контекст.
Тем не менее, в случае запрошенных сетью PDP-контекстов сеть может захотеть использовать уже существующий PDP-контекст для передачи мультимедиа. В этом случае мобильная станция не должна начинать "процедуру активации вторичного PDP-контекста", чтобы устанавливать новый PDP-контекст. Вместо этого мобильный терминал должен уведомляться посредством уровня управления GPRS-сеансами о том, что сеть выбрала уже существующий PDP-контекст для передачи мультимедиа.
Причина, по которой мобильная станция должна уведомляться о том, что уже установленный PDP-контекст должен использоваться для передачи мультимедиа, показана на фиг.2. Согласование сеанса на базе мультимедийной подсистемы на базе IP-протокола (IMS) содержит два раунда согласования мультимедийных характеристик. Первый раунд переговоров помечен "1" на фиг.2. Этот раунд согласования должен содержать информацию о том, какие типы мультимедиа IMS-клиент A хочет использовать в связи, как описано в SIP INVITE, и какой из предложенных типов мультимедиа IMS-клиент B поддерживает, как описано в SIP 183 Session Progress. Дополнительно первый раунд согласования также должен содержать информацию о текущем состоянии резервирования ресурса для мультимедиа для этих двух IMS-клиентов. В этот момент IMS-клиенты A и B не знают, какой PDP-контекст следует использовать для согласуемого мультимедийного потока, поэтому IMS-клиент A и IMS-клиент B должны указывать то, что они не имеют ресурсов для передачи мультимедиа, используя такие SDP-атрибуты как "a=inactive" и объявляя, что предварительные условия SIP не удовлетворены, т.е. объявляя, что по сведению IMS-клиентов ресурсы не зарезервированы.
На фиг.2 сеть инициирует новые PDP-контексты для мультимедиа. Это приводит к передаче служебных сигналов на уровне управления GPRS-сеансами. IMS-клиенты могут осуществлять доступ к этой информации и таким образом должны уведомляться о том, что новый PDP-контекст установлен.
Когда IMS-клиент A уведомляется о том, что новый PDP-контекст установлен, т.е. ресурсы зарезервированы для мультимедиа, он инициирует второй раунд согласования, помеченный как "2" на фиг.2. Конфигурация мультимедиа является идентичной результату первого раунда согласования. Отличие состоит в том, что IMS-клиент A должен теперь указывать, что он имеет ресурсы и может начинать передачу мультимедиа, к примеру, посредством индикатора "a=sendrecv", и что предварительные условия SIP теперь удовлетворяются.
Тем не менее, не разрешается такой случай, в котором сеть решает использовать уже установленный PDP-контекст для мультимедиа, когда процедура запрошенной сетью активации PDP-контекста используется. В этом случае IMS-клиенты, которые не знают то, является ли какой-либо из уже установленных PDP-контекстов подходящим для передачи мультимедиа, указывают в первом раунде согласования, что они не имеют ресурсов ("a=inactive", предварительные условия SIP не удовлетворены).
Следовательно, существует потребность в способе, устройстве и системе, которые позволяют обрабатывать случай, когда сеть решает использовать уже установленный PDP-контекст для мультимедиа, когда процедура запрошенной сетью активации PDP-контекста используется.
Сущность изобретения
Цель настоящего изобретения состоит в том, чтобы предоставлять возможность системе сотовой связи использовать уже установленный PDP-контекст для мультимедиа, когда используется процедура запрошенной сетью активации PDP-контекста.
Эта и другие цели получаются посредством способа, устройства и системы, как изложено в прилагаемой формуле изобретения. Следовательно, предусмотрен способ выбора мультимедийного потока в системе сотовой радиосвязи. В соответствии со способом запрос на мультимедийный поток может приниматься от мобильного терминала. Когда запрос принят, может быть определено то, что существующий PDP-контекст или однонаправленный EPS-канал должны использоваться для запрашиваемого мультимедийного потока, и передается в служебных сигналах в мобильную станцию то, что должны использоваться существующий PDP-контекст или однонаправленный EPS-канал.
Поскольку в традиционных системах отсутствует сигнал, чтобы отправлять из сети в IMS-клиент, чтобы сообщать то, что сеть определила, что IMS-клиент должен использовать уже установленный PDP-контекст для передачи мультимедиа, невозможно использовать установленный PDP-контекст для передачи мультимедиа. Следовательно, в существующих системах IMS-клиенты никогда не уведомляются о том, что ресурсы фактически уже присутствуют, и они не могут продолжать последовательность служебных сигналов установления IMS-сеанса и сообщать, что они не имеют ресурсов.
В соответствии с настоящим изобретением сигнал используется для того, чтобы указывать мобильному терминалу/IMS-клиенту то, что уже установленный PDP-контекст является предпочтительным выбором сети, чтобы использоваться для передачи мультимедиа. Например, уже существующая процедура "инициированной GGSN модификации PDP-контекста" или процедура "запрошенной сетью активации PDP-контекста" может использоваться, или эквивалентный сигнал может добавляться, чтобы указывать мобильному терминалу/IMS-клиенту то, что уже установленный PDP-контекст является предпочтительным выбором сети, которая должна использоваться для передачи мультимедиа. Это может получаться посредством отправки информации в мобильную станцию, включающей в себя один или более идентификаторов, которые мобильная станция может использовать для того, чтобы коррелировать с уже существующим PDP-контекстом. Такими идентификаторами могут быть, например:
- шаблон потока трафика (TFT) с информацией фильтра восходящей и/или нисходящей линии связи,
- идентификатор точки доступа к сетевой службе (NSAPI),
- PDP-адрес.
Краткое описание чертежей
Настоящее изобретение далее подробнее описывается посредством неограничивающих примеров и со ссылкой на прилагаемые чертежи, на которых:
- фиг.1 - это представление, иллюстрирующее установление запрошенного сетью PDP-контекста,
- фиг.2 - это представление, иллюстрирующее передачу служебных сигналов установления IMS-сеанса, и
- фиг.3 - это представление, иллюстрирующее установление сеанса с использованием предварительно установленного/уже существующего PDP-контекста,
- фиг.4 - это узел в системе сотовой радиосвязи,
- фиг.5 - это мобильная станция, и
- фиг.6 - это блок-схема последовательности операций способа, иллюстрирующая этапы алгоритма, выполняемые в системе сотовой радиосвязи.
Подробное описание изобретения
В случае если сеть решила использовать PDP-контекст, который уже установлен, поток сигналов на фиг.2 может быть таким, как проиллюстрировано на фиг.3. Таким образом, базовая IMS-сеть A отправляет Diameter AAR, чтобы предоставлять информацию об услуге/мультимедийном потоке для PCRF. PCRF осуществляет выбор политики и отправляет информацию в сообщении Diameter RAR. GGSN, который является точкой активации политики, принудительно активирует политики и, как результат, определяется, что уже существующий PDP-контекст должен использоваться для этой услуги/мультимедийного потока.
В соответствии с одним вариантом осуществления GGSN затем может непосредственно подтверждать прием Diameter RAR с помощью Diameter RAA в PCRF и одновременно отправляет информацию в мобильную станцию через SGSN с использованием либо:
- сообщения с запросом на обновление PDP-контекста, если используется процедура инициированной GGSN модификации PDP-контекста для этой цели (не показана на фиг.3), либо
- другого подходящего сообщения, например, инициирования активации PDP-контекста, при использовании процедуры запрошенной сетью активации вторичного PDP-контекста для этой цели, которое отправляется в SGSN.
Это сообщение, можно сказать, переносит информацию в SGSN о том, что уже существующий PDP-контекст должен использоваться для услуги или передачи мультимедиа. В случае если это сообщение с запросом на обновление PDP-контекста используется, SGSN должен рассматривать процедуру как обычную инициированную GGSN модификацию PDP-контекста и не знать о том, что система преобразует новый мультимедийный поток в уже существующий PDP-контекст при использовании запрашиваемого сетью QoS. Тем не менее, если другой сигнал (к примеру, инициирование активации PDP-контекста) должен использоваться, может требоваться или не требоваться новая логика SGSN для того, чтобы понимать, что уже инициированный PDP-контекст должен использоваться. Информацией, предоставленной в SGSN, который должен использоваться для того, чтобы идентифицировать PDP-контекст, может быть, например:
- идентификатор GTP-туннеля (к примеру, TEID),
- NSAPI (идентификатор PDP-контекста),
- PDP-адрес, или
- фильтры шаблонов потоков трафика (TFT).
SGSN затем разрешается использовать эту информацию и коррелировать его с уже установленными PDP-контекстами, и понимать, что он уже имеет этот PDP-контекст активированным при необходимости. Независимо о того, используется новая логика SGSN или используется уже существующая логика инициированной GGSN модификации PDP-контекста, либо запрошенной сетью активации PDP-контекста, SGSN должен сообщать в мобильную станцию, которая выполнена с возможностью использовать запрошенную сетью активацию PDP-контекста, что услуга/мультимедийный поток должны отправляться по уже существующему PDP-контексту.
Эта информация может отправляться в мобильный терминал с использованием, например:
- сообщения с запросом на модификацию PDP-контекста, или
- другого подходящего сообщения, такого как сообщение с запросом на активацию PDP-контекста.
Чтобы также сообщать мобильному терминалу о том, что уже существующий PDP-контекст должен использоваться для услуги или передачи мультимедиа. Информацией, предоставляемой в мобильную станцию для того, чтобы сообщать об этом, может быть, например, одно или более из следующего:
- NSAPI (идентификатор PDP-контекста),
- PDP-адрес,
- шаблон потока трафика (TFT) с информацией фильтра восходящей и/или нисходящей линии связи.
Кроме того, вероятно, что должен использоваться TFT восходящей линии связи. TFT должен инструктировать мобильную станцию маршрутизировать мультимедийный поток по соответствующему PDP-контексту/RAB. Информации TFT, к примеру информации фильтра восходящей линии связи и нисходящей линии связи или DSCP, наряду с PDP-адресом и APN достаточно для UE, чтобы понимать то, для какого потока данных об услугах должен использоваться PDP-контекст. Для IMS это означает, что IP-адрес и порты, уведомляемые в SDP, соответствуют принимаемой информации TFT. Для другой услуги или если SDP обновляется с помощью DSCP, Diffserv Codepoints (DSCP) могут использоваться для того, чтобы коррелировать услугу с соответствующим PDP-контекстом.
Если PDP-контекст, который должен использоваться, уже не включает в себя TFT (в нуле или одном PDP-контексте может отсутствовать информация TFT), то сеть направляет мультимедийный поток в PDP-контекст посредством добавления TFT к PDP-контексту с использованием процедуры инициированной GGSN модификации PDP-контекста.
Мобильная станция затем коррелирует или конфигурирует себя так, чтобы использовать информацию, принятую сетью, что приводит к использованию уже установленного PDP-контекста. Это приводит к тому, что PDP-контекст, который уже существует, используется, и нет необходимости начинать процедуру активации вторичного PDP-контекста.
После того как мобильный терминал обнаружил, что услуга/мультимедийный поток должен использовать уже существующий PDP-контекст, он сообщает IMS-клиенту, что он содержит ресурсы. После этого IMS-клиент продолжает передачу служебных сигналов установления IMS-сеанса, указывающую то, что он имеет ресурсы для мультимедиа.
На фиг.4 проиллюстрирован узел 400 в системе сотовой радиосвязи. Узел 400 содержит функцию (PCRF) 407 управления политиками, выполненную с возможностью осуществлять выборы политик, касающиеся того, какой PDP-контекст следует использовать для конкретного запроса на услугу или мультимедийный поток от мобильной станции, подключенной к системе сотовой радиосвязи. PCRF также может находиться вне узла 400, когда узел 400 выполнен с возможностью подключаться к PCRF. Узел 400 дополнительно содержит приемное устройство, выполненное с возможностью принимать запросы на различные услуги или мультимедийные потоки от мобильных станций, подключенных к системе сотовой радиосвязи. Узел 400 также содержит блок 403 выбора решений, который выполнен с возможностью определять, что уже существующий PDP-контекст должен использоваться для принимаемого запроса на услугу или мультимедийный поток от мобильной станции в случае, если имеется подходящий существующий PDP-контекст для использования. Также узел 400 содержит модуль для передачи в служебных сигналах в другой сетевой узел, такой как обслуживающий узел поддержки GPRS (SGSN), то, что уже существующий PDP-контекст должен использоваться для запрашиваемой услуги или мультимедийного потока, посредством отправки информации о PDP-контексте, который должен использоваться.
Информацией об уже существующем PDP-контексте может быть, например, идентификатор GTP-туннеля (к примеру, TEID), NSAPI (идентификатор PDP-контекста), PDP-адрес или фильтры шаблонов потоков трафика (TFT).
На фиг.5 проиллюстрирована мобильная станция 501. Мобильная станция содержит блок 503, выполненный с возможностью конфигурировать себя с использованием принимаемой информации PDP-контекста для выяснения того, что она уже имеет этот PDP-контекст активированным, как описано выше.
На фиг.6 проиллюстрирована блок-схема последовательности операций способа, показывающая этапы алгоритма, выполняемого при определении PDP-контекста для запрашиваемого мультимедийного потока в системе сотовой радиосвязи. Сначала на этапе 601 запрос на мультимедийный поток (или услугу) принимается от мобильного терминала. Затем на этапе 603 определяется то, должен ли существующий PDP-контекст использоваться для запрашиваемого мультимедийного потока. Если на этапе 603 определено то, что существующий PDP-контекст должен использоваться, процедура переходит к этапу 605. Если на этапе 603 определено то, что новый PDP-контекст должен использоваться, процедура переходит к этапу 607, где новый PDP-контекст создается в соответствии с существующими принципами.
На этапе 605 уведомление отправляется к запрашивающему мобильному терминалу, например, через SGSN, содержащее информацию о PDP-контексте, который должен использоваться.
Использование способа, устройства и системы, описанных в данном документе, должно приводить к тому, что сеть сотовой связи может маршрутизировать трафик по уже существующим PDP-контекстам или однонаправленному EPS-каналу при использовании активации однонаправленного EPS-канала или запрошенного сетью PDP-контекста.