ПРАВИЛА УПРАВЛЕНИЯ И ТАРИФИКАЦИИ ПОЛИТИКИ (РСС), ОСНОВАННЫЕ НА ПРОТОКОЛЕ МОБИЛЬНОСТИ

Настоящая заявка испрашивает приоритет предварительной заявки США № 61/021013, озаглавленной «PCC RULES BASED ON IP-CAN FOR MOBILE IP», поданной 14 января 2008 г., которая переуступлена правопреемнику настоящей заявки и включена в настоящую заявку посредством ссылки.

I. Область техники, к которой относится изобретение

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

II. Уровень техники

Сети беспроводной связи широко развернуты для обеспечения различных услуг связи, таких как речь, видео, пакетные данные, передача сообщений, широковещательная передача и т.д. Этими сетями могут быть сети множественного доступа, способные поддерживать многочисленных пользователей посредством совместного использования доступных сетевых ресурсов. Примеры таких сетей множественного доступа включают в себя сети множественного доступа с кодовым разделением (CDMA), сети множественного доступа с временным разделением (TDMA), сети множественного доступа с частотным разделением (FDMA), системы множественного доступа с ортогональным частотным разделением (OFDMA) и сети множественного доступа с частотным разделением на одной несущей (SC-FDMA).

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

Сущность изобретения

В данном документе описываются методы поддержки функций PCC в сети беспроводной связи. В одном аспекте правила PCC для PCC-сеанса могут определяться на основе (т.е. посредством принятия во внимание) параметра, который может указывать, использует ли UE протокол мобильности. Этим параметром может быть параметр IP-CAN Type (тип сети доступа со связностью по протоколу Интернета (IP-связностью)), который присутствует в сигнализации PCC. Правила PCC, определенные таким образом, могут обеспечивать некоторые преимущества, как описано ниже.

В одной разработке функция правил управления и тарификации политики (PCRF) (или эквивалентный сетевой объект) может принимать запрос/указание от первого сетевого объекта (например, домашнего агента) на установление PCC-сеанса для UE, осуществляющего доступ к первому сетевому объекту, используя протокол мобильности (например, MIP). Запрос может включать в себя параметр IP-CAN Type, который может устанавливаться на протокол мобильности. PCRF может определять протокол мобильности, используемый UE, основываясь на параметре IP-CAN Type, и может удостоверять правила PCC для PCC-сеанса, основываясь на протоколе мобильности. Правила PCC могут включать в себя первый набор по меньшей мере одного фильтра для идентификации пакетов для PCC-сеанса, указание, подсчитывать ли пакеты для тарификации, правила качества обслуживания (QoS) для пакетов, информацию тарификации для PCC-сеанса и/или другую информацию, относящуюся к PCC-сеансу. PCRF может посылать правила PCC на первый сетевой объект, который может применять правила PCC к пакетам для PCC-сеанса и может подсчитывать каждый пакет для тарификации.

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

Ниже более подробно описываются различные аспекты и признаки раскрытия.

Краткое описание чертежей

Фиг.1 изображает примерное развертывание сети.

Фиг.2 изображает обработку пакета для туннелирования пакета протокола Интернета (IP).

Фиг.3 и 4 изображают два процесса для поддержки PCC, используя IP-CAN Type.

Фиг.5 и 6 изображают процесс и устройство соответственно для поддержки функций PCC посредством PCRF.

Фиг.7 и 8 изображают процесс и устройство соответственно для поддержки функций PCC домашним агентом.

Фиг.9 и 10 изображают процесс и устройство соответственно для поддержки функций PCC обслуживающим шлюзом.

Фиг.11 и 12 изображают процесс и устройство соответственно для поддержки функций PCC посредством UE.

Фиг.13 изображает блок-схему различных сетевых объектов на фиг.1.

Подробное описание

Методы, описанные в данном документе, могут использоваться для различных сетей беспроводной связи, таких как CDMA, TDMA, FDMA, OFDMA, SC-FDMA и другие сети. Термины «сеть» и «система» часто используются попеременно. Сеть CDMA может реализовать радиотехнологию, такую как универсальный наземный радиодоступ (UTRA), cdma2000 и т.п. UTRA включает в себя широкополосный CDMA (WCDMA) и другие варианты CDMA. cdma2000 охватывает стандарты IS-2000 (CDMA2000 1X), IS-95 и IS-856. Сеть TDMA может реализовать радиотехнологию, такую как глобальная система мобильной связи (GSM). Сеть OFDMA может реализовать радиотехнологию, такую как развитый UTRA (E-UTRA), ультрамобильная широкополосная сеть (UMB), IEEE 802.11 (Wi-Fi (беспроводная точность)), IEEE 802.16 (WiMAX (общемировая совместимость широкополосного беспроводного доступа)), IEEE 802.20, Flash-OFDM® (быстрый доступ с малым временем ожидания и бесшовным переходом между базовыми станциями на основе мультиплексирования с ортогональным частотным разделением) и т.д. UTRA и E-UTRA являются частью универсальной системы мобильной связи (UMTS). Долгосрочное развитие (LTE) Проекта партнерства по созданию системы третьего поколения (3GPP) представляет собой предстоящую версию UMTS, которая использует E-UTRA. UTRA, E-UTRA, UMTS, LTE и GSM описаны в документах организации «Проект партнерства по созданию системы 3-го поколения» (3GPP). cdma2000 и UMB описаны в документах организации «Проект 2 партнерства по созданию системы 3-го поколения» (3GPP2). Методы, описанные в данном документе, могут использоваться для сетей и радиотехнологий, приведенных выше, а также для других сетей и радиотехнологий. Для ясности некоторые аспекты методов описываются ниже для LTE, и терминология LTE используется ниже в большей части описания.

Фиг.1 изображает примерное развертывание 100 сети. UE 110 может выполнять связь с сетью 120а развитого универсального наземного радиодоступа (E-UTRAN) или сетью 120b радиодоступа (RAN) не-3GPP для приема одной или нескольких услуг по передаче данных, таких как Интернет-связность, служба коротких сообщений (SMS), мгновенный обмен сообщениями (IM), доступ по протоколу приложений для беспроводной связи (WAP), потоковая передача мультимедийных данных, обмен мультимедийными сообщениями и т.д. UE 110 также может упоминаться как мобильная станция, терминал, терминал доступа, абонентский блок, станция и т.д. UE 110 может быть сотовый телефон, персональный цифровой помощник (PDA), беспроводный модем, устройство беспроводной связи, карманное устройство, портативный компьютер, беспроводный телефон, станция беспроводного абонентского доступа (WLL) и т.д.

E-UTRAN 120а может включать в себя развитые узлы В (eNB), которые поддерживают радиосвязь для UE. eNB может быть стационарная станция, которая выполняет связь с UE, и также может упоминаться как узел В, базовая станция, точка доступа и т.д. Обслуживающий шлюз (SGW) 130а может завершать интерфейс к E-UTRAN 120а и может выполнять различные функции, такие как поддержка эстафетной передачи обслуживания UE между eNB, буферизация, маршрутизация и направление данных для UE, инициирование запускаемой сетью процедуры запроса обслуживания, функции учета для тарификации и т.д. Домашний агент (HA) 140 может выполнять связь с обслуживающим шлюзом 130а непосредственно или косвенно и может поддерживать один или несколько протоколов мобильности, таких как MIP, прокси-мобильный IP (PMIP), протокол мобильного Интернета с двойным стеком версии 6 (DSMIPv6), режим совмещенного адреса обслуживания протокола мобильного Интернета версии 4 (MIPv4-CCoA), протокол туннелирования системы пакетной радиосвязи общего пользования (GPRS) (GTP) и т.д. Домашний агент 140 может сохранять информацию о текущем местонахождении для роуминга UE и может маршрутизировать пакеты для этих UE. Домашним агентом 140 может быть шлюз, выделенный в качестве домашнего агента, или шлюз, который может предоставлять функциональную возможность домашнего агента, а также другие функциональные возможности.

Хотя это не показано на фиг.1, шлюз сети передачи пакетных данных (PDN) может соединять обслуживающий шлюз 130а и домашний агент 140. Шлюз PDN может выполнять функции, такие как функции фильтрации пакетов и распределения IP-адреса для UE, управления селектированием и приведения в исполнение тарифа уровня обслуживания, протокола динамического конфигурирования хоста (DHCP) для клиента и сервера, функциональную возможность шлюзового узла поддержки GPRS (GGSN) и т.д. Блок 142 аутентификации, авторизации и учета/домашнего абонентского сервера (AAA/HSS) может хранить относящуюся к подписке информацию (например, профили пользователей) и информацию о местонахождении для UE. AAA/HSS 142 может выполнять аутентификацию и авторизацию UE и может предоставлять информацию для UE для запроса сетевых объектов.

RAN 120b не-3GPP может представлять собой сеть CDMA2000 1X, сеть WiMAX, сеть Wi-Fi или RAN некоторого другого типа. RAN 120b не-3GPP может выполнять сопряжение с шлюзом 130b не-3GPP, который может выполнять функции, аналогичные функциям, выполняемым обслуживающим шлюзом 130а.

PCRF 150 и функция приведения в исполнение политики и тарификации (PCEF) могут вместе поддерживать функции PCC. Экземпляр PCEF может быть совмещен с каждым из шлюзов 130а и 130b и домашним агентом 140, как показано на фиг.1. PCRF 150 может служить в качестве контроллера для PCC, принимать информацию обслуживания от функций приложения (AF) и предоставлять правила PCC для PCEF. PCEF может приводить в исполнение правила PCC, предоставляемые PCRF 150. Например, PCEF может устанавливать QoS для IP-потока и может обеспечивать функцию тарификации для IP-потока, основываясь на правилах PCC. IP-поток также может упоминаться как поток данных и т.д. PCC, PCRF и PCEF описаны в документе 3GPP TS 23.203, озаглавленном «Policy and charging control architecture», который находится в свободном доступе.

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

RAN и сетевые объекты на фиг.1 могут принадлежать к одной или нескольким наземным сетям мобильной связи общего пользования (PLMN). Например, домашняя PLMN (HPLMN) может включать в себя домашнего агента 140 и AAA/HSS 142, и визитная PLMN (VPLMN) может включать в себя E-UTRAN 120а и обслуживающий шлюз 130а. RAN 120b не-3GPP и шлюз 130b не-3GPP могут принадлежать к HPLMN или VPLMN. PCRF 150 может включать в себя домашнюю PCRF (H-PCRF) в HPLMN и визитную PCRF (V-PCRF) в VPLMN. Каждая PLMN также может включать в себя другие сетевые объекты, не показанные на фиг.1.

Фиг.1 изображает некоторые сетевые объекты, которые могут поддерживать сеть доступа с IP-связностью (IP-CAN). IP-CAN представляет собой совокупность сетевых объектов и интерфейсов, которые обеспечивают связность для транспортировки по протоколу IP между UE и объектами базовой сети. Сетевые объекты на фиг.1 могут выполнять связь друг с другом непосредственно или косвенно, например, при помощи одной или нескольких сетей передачи данных. Сетевые объекты на фиг.1 описаны в документе 3GPP TS 36.300, озаглавленном «Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall description», и в документе 3GPP TS 23.401, озаглавленном «General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access». Эти документы находятся в свободном доступе у 3GPP.

UE 110 может получать Интернет-связность посредством прямого IP-доступа и/или мобильного IP-доступа. Прямой IP-доступ ссылается на обмен IP-пакетами между UE 110 и удаленным объектом без поддержки мобильности UE. Мобильный IP-доступ ссылается на обмен IP-пакетами между UE 110 и удаленным объектом посредством сетевого объекта, который может поддерживать отслеживание местонахождения UE и направлять IP-пакеты на UE, используя туннелирование. Мобильный IP-доступ может поддерживаться с использованием MIP, PMIP, DSMIPv6, MIPv4-CCoA, GTP или некоторого другого протокола мобильности. Например, UE 110 может получить прямой IP-доступ при помощи обслуживающего шлюза 130а или шлюза 130b не-3GPP и может обмениваться IP-пакетами при помощи шлюза 130а или 130b без туннелирования. UE 110 также может получить мобильный IP-доступ при помощи домашнего агента 140, используя протокол мобильности, такой как MIP. Для мобильного IP-доступа IP-пакеты могут туннелироваться между UE 110 и домашним агентом 140 при помощи шлюзов 130а или 130b.

Фиг.2 изображает пример обработки для туннелирования IP-пакета, посылаемого по восходящей линии связи от UE 110 на домашний агент 140. UE 110 может выполнять связь с другим UE и может генерировать IP-пакет 210 для посылки на другое UE. IP-пакет 210 включает в себя IP-заголовок и полезные данные. IP-заголовок включает в себя различные поля, включающие в себя поле адреса источника, поле адреса назначения и поле протокола. Поле адреса источника может устанавливаться на IP-адрес UE 110 (IP-адрес UE1), поле адреса назначения может устанавливаться на IP-адрес другого UE (IP-адрес UE2), и поле протокола может устанавливаться на протокол транспортного уровня (например, протокол управления передачей (TCP), протокол пользовательских дейтаграмм (UDP) и т.д.), используемый для данных, посылаемых в полезных данных. Полезные данные IP-пакета 210 могут переносить дейтаграммы транспортного уровня, которые могут включать в себя заголовок и полезные данные. Заголовок транспортного уровня может включать в себя (i) поле порта источника, которое может устанавливаться на порт в UE 110 (порт Y), и (ii) порт назначения, который может устанавливаться на порт на другом UE (порт Z). Поля адреса источника, адреса назначения и протокола заголовка IP-пакета 210 и поля порта источника и порта назначения заголовка дейтаграммы транспортного уровня могут рассматриваться как поля внутреннего заголовка.

IP-пакет 210 представляет собой нетуннелированный пакет и может инкапсулироваться в туннелированный IP-пакет 220 посредством UE 110 для восходящей линии связи. Для туннелированного IP-пакета 220 поле адреса источника может устанавливаться на IP-адрес UE 110 (IP-адрес UE1), и поле адреса назначения может устанавливаться на IP-адрес домашнего агента 140 (IP-адрес HA). Поля адреса источника, адреса назначения и протокола заголовка IP-пакета 220 могут рассматриваться как поля внешнего заголовка.

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

Для восходящей линии связи UE 110 может выполнять туннелирование для IP-пакетов, и домашний агент 140 может выполнять детуннелирование. UE 110 может посылать туннелированные IP-пакеты на шлюз 130а или 130b, который может направлять туннелированные IP-пакеты домашнему агенту 140. Для нисходящей линии связи домашний агент 140 может выполнять туннелирование для IP-пакетов, и UE 110 может выполнять детуннелирование. Домашний агент 140 может посылать туннелированные IP-пакеты на шлюз 130а или 130b, который может направлять туннелированные IP-пакеты на UE 110. Для упрощения IP-пакеты также упоминаются просто как пакеты в нижеследующем описании.

Как показано на фиг.1, PCRF 150 может посылать правила PCC для PCC-сеансов на PCEF. PCC-сеанс может устанавливаться между PCRF 150 и обслуживающим шлюзом 130а, шлюзом 130b не-3GPP или домашним агентом 140 и может охватывать один или несколько IP-потоков. Каждый IP-поток может идентифицироваться набором параметров, которые могут включать в себя адрес источника, адрес назначения, протокол транспортного уровня, порт источника и порт назначения, показанные на фиг.2. Правила PCC для каждого PCC-сеанса могут включать в себя информацию об IP-потоках в PCC-сеансе, правила QoS или политику для применения к IP-потокам, информацию тарификации для IP-потоков и/или другую информацию, относящуюся к PCC-сеансу. Правила QoS могут указывать полосу частот, задержку и приоритет для IP-потоков, блокировку или пропускание пакетов в IP-потоке и т.д. Информация тарификации может указывать механизм(ы) тарификации для IP-потоков, например помесячную абонентскую плату, тарификацию на основе времени или количества пакетов.

Когда используется протокол мобильности, такой как MIP, пакеты могут туннелироваться между UE 110 и домашним агентом 140 через шлюз 130, которым может быть обслуживающий шлюз 130а или шлюз 130b не-3GPP. Шлюзу 130 должно быть известно, что пакеты туннелируются для того, чтобы корректно применять подходящие правила PCC.

Кроме того, могут быть сценарии, в которых как домашний агент 140, так и шлюз 130 имеют активные PCC-сеансы для тарификации посредством PCRF 150. Это может происходить, например, тогда, когда UE 110 имеет прямой IP-доступ через шлюз 130 и также имеет мобильный IP-доступ через домашнего агента 140. Шлюз 130 может направлять как нетуннелированные пакеты для прямого IP-доступа, так и туннелированные пакеты от домашнего агента 140 для мобильного IP-доступа. Так как и шлюз 130, и домашний агент 140 направляют туннелированные пакеты, эти пакеты должны подсчитываться только один раз, чтобы исключить двойную тарификацию. Это же может также применяться тогда, когда домашний агент 140 и шлюз 130 являются совмещенными, но имеют разные PCC-сеансы с PCRF 150.

В одном аспекте правила PCC для PCC-сеанса могут определяться на основе параметра, который может указывать, использует ли UE протокол мобильности. В одной разработке параметром является параметр IP-CAN Type, который присутствует в сигнализации PCC. Параметр IP-CAN Type обычно предоставляет информацию о типе радиодоступа, например E-UTRA, UTRA, CDMA2000 1X, WiMAX, Wi-Fi и т.д. Параметр IP-CAN Type может быть расширен для предоставления информации о протоколе мобильности. Например, параметр IP-CAN Type может указывать: (i) использует ли UE или нет протокол мобильности и (ii) какой используется протокол мобильности, например MIP, PMIP, DSMIPv6, MIPv4-CCoA, GTP и т.д. Параметр IP-CAN Type может использоваться для различения между туннелированными пакетами и нетуннелированными пакетами, как описано ниже.

Для PCC-сеанса между шлюзом 130 (например, обслуживающим шлюзом 130а или шлюзом 130b не-3GPP) и PCRF 150 для прямого IP-доступа параметр IP-CAN Type может устанавливаться на тип радиодоступа. Шлюз 130 затем может подсчитывать нетуннелированные пакеты для PCC-сеанса для тарификации, и домашний агент 140 может пропускать подсчет нетуннелированных пакетов.

Для PCC-сеанса между домашним агентом 140 и PCRF 150 для мобильного IP-доступа параметр IP-CAN Type может устанавливаться на протокол мобильности (например, MIP). Этот PCC-сеанс может ассоциироваться с туннелированными пакетами, и правила PCC для PCC-сеанса могут относиться к туннелированным пакетам. Домашний агент 140 может подсчитывать туннелированные пакеты для тарификации. Шлюз 130 не будет подсчитывать туннелированные пакеты для тарификации, так как он не будет иметь PCC-сеанса с параметром IP-CAN Type, установленным на протокол мобильности.

Таблица 1 суммирует использование параметра IP-CAN Type для передачи разных типов PCC-сеанса. Таблица 1 также суммирует действие, выполняемое каждым сетевым объектом для каждого типа PCC-сеанса.

Фиг.3 изображает разработку процесса 300 для поддержки PCC, используя параметр IP-CAN Type. UE 110 может осуществлять доступ к RAN (например, E-UTRAN 120а или RAN 120b не-3GPP на фиг.1) и может выполнять связь с шлюзом 130 (например, обслуживающим шлюзом 130а или шлюзом 130b не-3GPP) для аутентификации доступа (этап 1). Шлюз 130 может дополнительно выполнять связь с AAA/HSS 142 для аутентификации, авторизации и учета (AAA) и аутентификации доступа UE 110 (также этап 1). UE 110 затем может выполнять конфигурирование IP-адреса посредством шлюза 130, и ему может назначаться IP-адрес (этап 2).

Шлюз 130 может посылать запрос/указание на установление сеанса канала IP-CAN на PCRF 150 (этап 3). Запрос может включать в себя идентификацию UE для UE 110, параметр IP-CAN Type и, возможно, другую информацию. Параметр IP-CAN Type может идентифицировать тип радиодоступа (например, E-UTRA, UTRA, WiMAX и т.д.) для устанавливаемого IP-CAN-сеанса (или PCC-сеанса). PCRF 150 может определить, что требуется авторизация PCC, и может запросить авторизацию разрешенной услуги (услуг) и информацию о правилах PCC от локального или внешнего объекта (не показан на фиг.3). PCRF 150 может выполнять авторизацию и принятие решения о политике по запросу от шлюза 130 и может определять правила PCC для PCC-сеанса, основываясь на параметре IP-CAN Type и другой информации. PCRF 150 затем может возвращать подтверждение приема (Ack) установления IP-CAN-сеанса на шлюз 130 (этап 4). Подтверждение приема может включать в себя правила PCC, информацию тарификации и/или другую информацию для PCEF на шлюзе 130. PCEF может приводить в исполнение правила PCC от PCRF 150.

Первый PCC-сеанс может устанавливаться между шлюзом 130 и PCRF 150 на этапах 3 и 4. Этот PCC-сеанс может ассоциироваться с типом радиодоступа, приведенным в параметре IP-CAN Type, посылаемом на этапе 3, и IP-адресом, назначенным UE 110 на этапе 2. Этот характерный для радиодоступа PCC-сеанс также может ассоциироваться с нетуннелированными пакетами, которые могут идентифицироваться на основе шаблона потока данных обслуживания, включенного в правила PCC, предоставляемые PCRF 150 на этапе 4. Шаблон потока данных обслуживания может включать в себя набор фильтров потока данных обслуживания, используемый для идентификации нетуннелированных пакетов для IP-потоков, охватываемых PCC-сеансом. Шлюз 130 может обнаруживать нетуннелированные пакеты для PCC-сеанса, основываясь на шаблоне потока данных обслуживания, и может подсчитывать эти пакеты для тарификации, как указано информацией тарификации, предоставляемой PCRF 150 (блок 5).

Потом UE 110 может потребоваться использование MIP. UE 110 может определять, что оно выполняет связь с визитной сетью, так как префикс IP-адреса для его домашней сети (HNP) отличается от префикса IP-адреса для шлюза 130. UE 110 может выполнять обмен ключами через Интернет (IKEv2) для установления безопасного ассоциирования с домашним агентом 140 (этап 6). Домашний агент 140 дополнительно может выполнять связь с AAA/HSS 142 для AAA для обмена ключами через Интернет для UE 110 (также этап 6). UE 110 может получать новый IP-адрес в качестве домашнего адреса.

UE 110 после этого может посылать обновление привязки и может предоставлять свое текущее местоположение домашнему агенту 140 (этап 7). Домашний агент 140 затем может посылать запрос/указание на установление сеанса канала IP-CAN на PCRF 150 (этап 8). Запрос может включать в себя параметр IP-CAN Type, который может идентифицировать протокол мобильности (например, MIP) для устанавливаемого IP-CAN-сеанса. PCRF 150 может определять авторизацию PCC, если необходимо, и может принимать решение по запросу от домашнего агента 140. PCRF 150 затем может возвращать подтверждение приема установления IP-CAN-сеанса домашнему агенту 140 (этап 9). Подтверждение приема может включать в себя правила PCC, информацию тарификации, информацию о заголовке инкапсуляции туннелирования для протокола мобильности и/или другую информацию для PCEF на домашнем агенте 140. PCEF может приводить в исполнение правила PCC, обеспечиваемые PCRF 150. PCRF 150 также может подавать на шлюз 130 правила PCC для туннелированных пакетов для PCC-сеанса между домашним агентом 140 и PCRF 150 (этап 10). Шлюз 130 может использовать правила PCC для поддержки QoS для туннелированных пакетов и/или выполнения других функций. Домашний агент 140 также может возвращать подтверждение приема привязки на UE 110 (этап 11).

Второй PCC-сеанс может устанавливаться между домашним агентом 140 и PCRF 150 на этапах 8 и 9. Этот PCC-сеанс может ассоциироваться с протоколом мобильности, приведенным в параметре IP-CAN Type, посылаемым на этапе 8, и IP-адресом, назначенным UE 110 на этапе 6. Этот характерный для протокола мобильности PCC-сеанс также может ассоциироваться с туннелированными пакетами, которые могут идентифицироваться на основе шаблона потока данных обслуживания, включенного в правила PCC, предоставляемые PCRF 150 на этапе 9. Шаблон потока данных обслуживания может включать в себя набор фильтров потока данных обслуживания, используемый для идентификации туннелированных пакетов для IP-потоков, охватываемых PCC-сеансом. Домашний агент 140 может обнаруживать туннелированные пакеты для PCC-сеанса, основываясь на шаблоне потока данных обслуживания, и может подсчитывать эти пакеты для тарификации, как указано информацией тарификации, предоставляемой PCRF 150 (блок 12).

Фиг.4 изображает разработку другого процесса 400 для поддержки PCC, использующего параметр IP-CAN Type. UE 110 может осуществлять доступ к E-UTRAN 120а, которая может принадлежать HPLMN для UE. UE 110 может выполнять связь с домашним агентом 140 для конфигурирования IP-адреса (этап 1). Домашний агент 140, которым может быть шлюз PDN в HPLMN, может дополнительно выполнять связь с AAA/HSS 142 для AAA и аутентификации доступа UE 110 (также этап 1). UE 110 может получать IP-адрес и префикс домашней сети (HNP) от домашнего агента 140.

Домашний агент 140 может посылать запрос/указание на установление сеанса канала IP-CAN на PCRF 150 (этап 2). Запрос может включать в себя параметр IP-CAN Type, который может идентифицировать тип радиодоступа (например, E-UTRA) для устанавливаемого IP-CAN-сеанса. PCRF 150 может определять авторизацию PCC, если необходимо, и может принимать решение по запросу от домашнего агента 140. PCRF 150 затем может возвращать подтверждение приема установления IP-CAN-сеанса на домашний агент 140 (этап 3). Подтверждение приема может включать в себя правила PCC, информацию тарификации и/или другую информацию для PCEF на домашнем агенте 140. PCEF может приводить в исполнение правила PCC, предоставляемые PCRF 150.

Первый PCC-сеанс может устанавливаться между домашним агентом 140 и PCRF 150 на этапах 2 и 3. Этот PCC-сеанс может ассоциироваться с типом радиодоступа, приведенным в параметре IP-CAN Type, посылаемом на этапе 2, и HNP, предоставляемым для UE 110 на этапе 1. Домашний агент 140 может обнаруживать нетуннелированные пакеты для PCC-сеанса, основываясь на шаблоне потока данных обслуживания, предоставляемом PCRF 150, и может подсчитывать эти пакеты для тарификации (блок 4).

UE 110 может выполнять обмен ключами через Интернет для установления безопасного ассоциирования с домашним агентом 140 (этап 5). UE 110 может понять, что оно находится в HPLMN. В результате протокол мобильности может не активизироваться, и может не устанавливаться PCC-сеанс для протокола мобильности.

После этого UE 110 может переместиться в RAN 120b не-3GPP и может выполнять аутентификацию доступа и конфигурирование IP-адреса с шлюзом 130b не-3GPP (этап 6). Шлюз 130b может дополнительно устанавливать связь с AAA/HSS 142 для AAA для аутентификации доступа UE 110 (также этап 6). Шлюз 130b может выполнять связь с PCRF 150 для установления сеанса управления шлюзом (этап 7) и может устанавливать параметр IP-CAN Type на тип радиодоступа (например, WiMAX) (этап 7). PCRF 150 может устанавливать сеанс управления шлюзом для шлюза 130b и может посылать подтверждение приема на установление сеанса управления шлюзом (этап 8). Сеанс управления шлюзом может ассоциироваться с типом радиодоступа, предоставляемым шлюзом 130b.

После этого UE 110 может посылать обновление привязки и может предоставлять свое текущее местоположение домашнему агенту 140 (этап 9). Домашний агент 140 затем может посылать запрос/указание на установление сеанса канала IP-CAN на PCRF 150 (этап 10). Указание может включать в себя параметр IP-CAN Type, который может идентифицировать протокол мобильности (например, DSMIPv6) для устанавливаемого IP-CAN-сеанса. PCRF 150 может определять авторизацию PCC, если необходимо, и может принимать решение по запросу от домашнего агента 140. PCRF 150 затем может возвращать подтверждение приема установления IP-CAN-сеанса домашнему агенту 140 (этап 11). Подтверждение приема может включать в себя правила PCC и другую информацию для PCEF на домашнем агенте 140. PCEF может приводить в исполнение правила PCC, предоставляемые PCRF 150. PCRF 150 также может предоставлять шлюзу 130b правила PCC для туннелированных пакетов для PCC-сеанса между домашним агентом 140 и PCRF 150 (этап 12). Шлюз 130 может использовать правила PCC для поддержки QoS для туннелированных пакетов и/или для выполнения других функций. Домашний агент 140 также может возвращать подтверждение приема привязки на UE 110 (этап 13).

Второй PCC-сеанс может устанавливаться между домашним агентом 140 и PCRF 150 на этапах 10 и 11. Этот PCC-сеанс может ассоциироваться с протоколом мобильности, представленным в параметре IP-CAN Type, HNP домашнего агента 140 и адресом обслуживания (CoA) для UE 110. Домашний агент 140 может обнаруживать туннелированные пакеты для PCC-сеанса, основываясь на шаблоне потока данных обслуживания, предоставляемом PCRF 150 на этапе 11, и может подсчитывать эти пакеты для тарификации (блок 14).

Как показано на фиг.3 и 4, PCC может поддерживаться указанием шлюзу 130 или домашнему агенту 140, применяются ли правила PCC только к нетуннелированным пакетам (например, для первого PCC-сеанса на фиг.3 и 4), или только к туннелированным пакетам (например, для второго PCC-сеанса на фиг.3 и 4), или к обоим нетуннелированным и туннелированным пакетам (не показано на фиг.3 и 4). Шлюз 130 или домашний агент 140 может подсчитывать все пакеты для его PCC-сеанса для тарификации, и каждый пакет будет подсчитываться только один раз или шлюзом 130, или домашним агентом 140. Шлюз 130 или домашний агент 140 может правильно подсчитывать пакеты для своего PCC-сеанса(ов) даже тогда, когда присутствуют как туннелированный трафик (например, трафик MIP), так и нетуннелированный трафик (например, трафик локального отвода), например, как показано на фиг.4.

Фиг.3 и 4 изображают две разработки использования параметра IP-CAN Type для поддержки PCC для протоколов мобильности. Методы могут использоваться для различных протоколов мобильности, таких как MIP, DSMIPv6, MIPv4-CCoA, PMIP, GTP и т.д. В качестве примера, в случае MIPv4 параметр IP-CAN Type может устанавливаться на MIPv4-CCoA вместо MIP на фиг.3 и 4.

Для ясности некоторые аспекты методов были описаны для LTE. Методы также могут использоваться для других беспроводных сетей, которые могут включать в себя другие сетевые объекты, которые могут выполнять функции, эквивалентные функциям сетевых объектов, показанных на фиг.1. Например, в UMTS версии 8 шлюз PDN может служить в качестве как обслуживающего шлюза, так и домашнего агента для UE. Шлюз PDN может иметь два PCC-сеанса для UE. В одном PCC-сеансе шлюз PDN может служить в качестве обслуживающего шлюза для прямого IP-доступа UE посредством UTRAN. В другом PCC-сеансе шлюз PDN может служить в качестве домашнего агента для мобильного IP-доступа UE посредством другой RAN. UE может посылать как нетуннелированные пакеты для прямого IP-доступа, так и туннелированные пакеты для мобильного IP-доступа. Нетуннелированные и туннелированные пакеты могут соответствовать разным шаблонам потока данных обслуживания на шлюзе PDN для двух PCC-сеансов, и каждый пакет может подсчитываться только один раз для соответствующего PCC-сеанса. Этот сценарий может быть показан процессом 400 на фиг.4, в этом случае домашний агент 140 может представлять шлюз PDN, первый PCC-сеанс может быть для прямого IP-доступа, и второй PCC-сеанс может быть для мобильного IP-доступа.

Фиг.5 изображает разработку процесса 500 для поддержки функций PCC в беспроводной сети. Процесс 500 может выполняться посредством PCRF (как описано ниже) или некоторого другого сетевого объекта. PCRF может принимать запрос/указание от первого сетевого объекта (например, домашнего агента) на установление PCC-сеанса для UE, осуществляющего доступ к первому сетевому объекту, используя протокол мобильности (например, MIP, PMIP, DSMIPv6, MIPv4-CCoA, GTP и т.д.) (блок 512). PCRF может определять протокол мобильности, используемый UE, основываясь на запросе (блок 514). В одной разработке PCRF может получать параметр IP-CAN Type из запроса и может определять протокол мобильности, используемый UE, основываясь на параметре IP-CAN Type. Протокол мобильности также может передаваться другим образом, например используя другие параметры, посылаемые в запросе.

PCRF может определять правила PCC для PCC-сеанса, основываясь на протоколе мобильности и, возможно, другой информации (блок 516). Правила PCC могут содержать набор по меньшей мере одного фильтра для идентификации пакетов для PCC-сеанса, указание, подсчитывать ли пакеты для тарификации, правила QoS для пакетов, информацию тарификации для PCC-сеанса и/или другую информацию, относящуюся к PCC-сеансу. PCRF может посылать правила PCC на первый сетевой объект (блок 518).

Пакеты для PCC-сеанса могут инкапсулироваться в туннелированные пакеты, которые могут обмениваться между UE и первым сетевым объектом при помощи второго сетевого объекта (например, обслуживающего шлюза). В данном случае PCRF может определять вторые правила PCC, содержащие (i) набор по меньшей мере одного фильтра для идентификации туннелированных пакетов и (ii) указание, чтобы не подсчитывать туннелированные пакеты для тарификации, которое может неявно предоставляться посредством отсутствия информации тарификации во вторых правилах PCC (блок 520). Например, вторые правила PCC могут включать в себя только правила QoS и набор по меньшей мере одного фильтра и без информации тарификации. PCRF может посылать вторые правила PCC на второй сетевой объект для применения к туннелированным пакетам (блок 522). Туннелированные пакеты могут подсчитываться один раз для тарификации первым сетевым объектом, а не вторым сетевым объектом.

PCRF может принимать второй запрос от третьего сетевого объекта (например, другого обслуживающего шлюза) на установление второго PCC-сеанса для UE. UE может иметь прямой IP-доступ к третьему сетевому объекту и может обмениваться пакетами с третьим сетевым объектом без туннелирования. PCRF может определять тип радиодоступа, используемый UE для третьего сетевого объекта, основываясь на втором запросе. В одной разработке PCRF может получать параметр IP-CAN Type из второго запроса и может определять тип радиодоступа, используемый UE, основываясь на параметре IP-CAN Type. PCRF может определять третьи правила PCC для второго PCC-сеанса, основываясь на типе радиодоступа, используемом UE. Третьи правила PCC могут содержать по меньшей мере один фильтр для идентификации нетуннелированных пакетов для второго PCC-сеанса и другую информацию. PCRF может затем посылать третьи правила PCC на третий сетевой объект.

Фиг.6 изображает разработку устройства 600 для поддержки функций PCC в беспроводной сети. Устройство 600 включает в себя модуль 612 для приема запроса от первого сетевого объекта на установление PCC-сеанса для UE, осуществляющего доступ к первому сетевому объекту, используя протокол мобильности, модуль 614 для определения протокола мобильности, используемого UE, основываясь на запросе, модуль 616 для определения правил PCC для PCC-сеанса, основываясь на протоколе мобильности, модуль 618 для посылки правил PCC на первый сетевой объект, модуль 620 для определения вторых правил PCC, содержащих набор по меньшей мере одного фильтра для идентификации туннелированных пакетов для PCC-сеанса и указание, чтобы не подсчитывать туннелированные пакеты для тарификации, и модуль 622 для посылки вторых правил PCC на второй сетевой объект для применения к туннелированным пакетам.

Фиг.7 изображает разработку процесса 700 для поддержки функций PCC. Первый сетевой объект (например, домашний агент) может принимать доступ UE, основываясь на протоколе мобильности (блок 712). Первый сетевой объект может посылать запрос на второй сетевой объект (например, PCRF) на установление PCC-сеанса для UE (блок 714). Запрос может содержать протокол мобильности, используемый UE. В одной разработке запрос может содержать параметр IP-CAN Type, который может устанавливаться на протокол мобильности, используемый UE.

Первый сетевой объект может принимать правила PCC для PCC-сеанса от второго сетевого объекта (блок 716). Правила PCC могут определяться посредством PCRF, основываясь на протоколе мобильности. Правила PCC могут содержать набор по меньшей мере одного фильтра для идентификации пакетов для PCC-сеанса, указание, подсчитывать ли пакеты для тарификации, правила QoS для пакетов, информацию тарификации для PCC-сеанса и/или другую информацию для PCC-сеанса. Первый сетевой объект может применять правила PCC к пакетам, обмениваемым с UE для PCC-сеанса (блок 718). Эти пакеты могут посылаться в туннелированных пакетах. В одной разработке блока 718 первый сетевой объект может идентифицировать пакеты для PCC-сеанса, основываясь на наборе по меньшей мере одного фильтра, полученном из правил PCC. Первый сетевой объект может подсчитывать пакеты для тарификации.

Фиг.8 изображает разработку устройства 800 для поддержки функций PCC. Устройство 800 включает в себя модуль 812 для принятия доступа UE, основываясь на протоколе мобильности на первом сетевом объекте, модуль 814 для посылки запроса на второй сетевой объект для установления PCC-сеанса для UE, причем запрос содержит протокол мобильности, используемый UE, модуль 816 для приема правил PCC для PCC-сеанса от второго сетевого объекта, причем правила PCC определяются на основе протокола мобильности, и модуль 818 для применения правил PCC к пакетам, обмениваемым с UE для PCC-сеанса.

Фиг.9 изображает разработку процесса 900 для поддержки функций PCC. Первый сетевой объект (например, обслуживающий шлюз) может принимать правила PCC для PCC-сеанса, установленного вторым сетевым объектом (например, домашним агентом) для UE, осуществляющего доступ ко второму сетевому объекту, используя протокол мобильности (например, MIP) (блок 912). UE и второй сетевой объект могут обмениваться туннелированными пакетами, которые могут направляться первым сетевым объектом. Первый сетевой объект может идентифицировать туннелированные пакеты для PCC-сеанса, основываясь на первом наборе по меньшей мере одного фильтра, полученного из правил PCC (блок 914). Первый сетевой объект может пропускать подсчет туннелированных пакетов для тарификации, при этом туннелированные пакеты подсчитываются вместо этого вторым сетевым объектом для тарификации (блок 916).

Первый сетевой объект может посылать запрос на установление второго PCC-сеанса для UE, осуществляющего доступ к первому сетевому объекту, используя прямой IP-доступ (блок 918). Запрос может включать в себя параметр IP-CAN Type, установленный на тип радиодоступа, используемый UE для первого сетевого объекта. Первый сетевой объект может принимать вторые правила PCC для второго PCC-сеанса, которые могут определяться на основе типа радиодоступа, используемого UE (блок 920). Первый сетевой объект может идентифицировать нетуннелированные пакеты для второго PCC-сеанса, основываясь на втором наборе по меньшей мере одного фильтра, полученного из вторых правил PCC (блок 922), и может подсчитывать нетуннелированные пакеты для тарификации (блок 924).

Фиг.10 изображает разработку устройства 1000 для поддержки функций PCC. Устройство 1000 включает в себя модуль 1012 для приема правил PCC на первом сетевом объекте, причем правила PCC предназначены для PCC-сеанса, установленного вторым сетевым объектом для UE, осуществляющего доступ ко второму сетевому объекту, используя протокол мобильности, модуль 1014 для идентификации туннелированных пакетов для PCC-сеанса, основываясь на первом наборе по меньшей мере одного фильтра, полученном из правил PCC, модуль 1016 для отсутствия подсчета туннелированных пакетов для тарификации, причем туннелированные пакеты подсчитываются вторым сетевым объектом для тарификации, модуль 1018 для посылки запроса на установление второго PCC-сеанса для UE, осуществляющего доступ к первому сетевому объекту, используя прямой IP-доступ, модуль 1020 для приема вторых правил PCC для второго PCC-сеанса, модуль 1022 для идентификации нетуннелированных пакетов для второго PCC-сеанса, основываясь на втором наборе по меньшей мере одного фильтра, полученном из вторых правил PCC, и модуль 1024 для подсчета нетуннелированных пакетов для тарификации.

Фиг.11 изображает разработку процесса 1100, выполняемого UE. UE может осуществлять доступ к первому сетевому объекту (например, домашнему агенту), используя протокол мобильности (например, MIP) (блок 1112). Первый сетевой объект может устанавливать PCC-сеанс для UE, основываясь на протоколе мобильности, например, посредством установки параметра IP-CAN Type на протокол мобильности. UE может обмениваться туннелированными пакетами с первым сетевым объектом для PCC-сеанса (блок 1114). Первый сетевой объект может подсчитывать туннелированные пакеты для тарификации в соответствии с правилами PCC, определенными для PCC-сеанса, основанными на протоколе мобильности.

UE может осуществлять доступ ко второму сетевому объекту (например, обслуживающему шлюзу), используя прямой IP-доступ (блок 1116). Второй сетевой объект может устанавливать второй PCC-сеанс для UE, основываясь на типе радиодоступа (например, E-UTRA, UTRA, WiMAX, Wi-Fi и т.д.), используемом UE для второго сетевого объекта. UE может обмениваться нетуннелированными пакетами со вторым сетевым объектом для второго PCC-сеанса (блок 1118). Второй сетевой объект может подсчитывать нетуннелированные пакеты для тарификации в соответствии со вторыми правилами PCC, определенными для второго PCC-сеанса, основываясь на типе радиодоступа.

Туннелированные пакеты для первого PCC-сеанса могут обмениваться между UE и первым сетевым объектом через второй сетевой объект. Туннелированные пакеты могут подсчитываться первым сетевым объектом для тарификации и могут не подсчитываться вторым сетевым объектом.

Фиг.12 изображает разработку устройства 1200 для UE. Устройство 1200 включает в себя модуль 1212 для доступа UE к первому сетевому объекту, используя протокол мобильности, причем первый сетевой объект устанавливает PCC-сеанс для UE, основываясь на протоколе мобильности, модуль 1214 для обмена туннелированными пакетами с первым сетевым объектом для PCC-сеанса, причем первый сетевой объект подсчитывает туннелированные пакеты для тарификации в соответствии с правилами PCC, определенными для PCC-сеанса, основываясь на протоколе мобильности, модуль 1216 для доступа UE ко второму сетевому объекту, используя прямой IP-доступ, причем второй сетевой объект устанавливает второй PCC-сеанс для UE, основываясь на типе радиодоступа, используемом UE для второго сетевого объекта, и модуль 1218 для обмена нетуннелированными пакетами со вторым сетевым объектом для второго PCC-сеанса, причем второй сетевой объект подсчитывает нетуннелированные пакеты для тарификации в соответствии со вторыми правилами PCC, определенными для второго PCC-сеанса, основываясь на типе радиодоступа.

Модули на фиг.6, 8, 10 и 12 могут содержать процессоры, электронные устройства, аппаратные устройства, электронные компоненты, логические схемы, памяти, программные коды, программно-аппаратные коды и т.д. или любую их комбинацию.

Фиг.13 изображает блок-схему разработки UE 110, RAN 120, шлюза 130, домашнего агента 140 и PCRF 150. RAN 120 может быть E-UTRAN 120а или RAN 120b не-3GPP на фиг.1 или некоторая другая RAN. Шлюзом 130 может быть обслуживающий шлюз 130а или шлюз 130b не-3GPP на фиг.1 или некоторый другой шлюз. Для упрощения фиг.13 изображает (i) один контроллер/процессор 1310, одну память 1312 и один приемник/передатчик 1314 для UE 110, (ii) один контроллер/процессор 1320, одну память (Mem) 1322, один приемник/передатчик 1324 и один блок 1326 связи (Comm) для RAN 120, (iii) один контроллер/процессор 1330, одну память 1332 и один блок 1334 связи для шлюза 130, (iv) один контроллер/процессор 1340, одну память 1342 и один блок 1344 связи для домашнего агента 140, и (v) один контроллер/процессор 1350, одну память 1352 и один блок 1354 связи для PCRF 150. Как правило, каждый объект может включать в себя любое количество контроллеров, процессоров, блоков памяти, приемопередатчиков, блоков связи и т.д.

По нисходящей линии связи RAN 120 может передавать данные и сообщения на UE в пределах ее зоны покрытия. Данные и сообщения могут обрабатываться процессором 1320 и приводиться в определенное состояние передатчиком 1324 для генерирования сигналов нисходящей линии связи, которые могут передаваться на UE. На UE 110 сигналы нисходящей линии связи от RAN 120 могут приниматься и приводиться в определенное состояние приемником 1314 и обрабатываться процессором 1310 для восстановления данных и сообщений, посылаемых на UE 110. Память 1312 может хранить программные коды и данные для UE 110. Процессор 1310 может выполнять или управлять процессом 1100 на фиг.11 и/или другими процессами для методов, описанных в данном документе. Процессор 1310 также может выполнять обработку для UE 110 в потоке 300 и 400 сообщений на фиг.3 и 4 соответственно.

По восходящей линии связи UE 110 может передавать данные и сообщения на RAN 120. Данные и сообщения могут обрабатываться процессором 1310 и приводиться в определенное состояние передатчиком 1314 для генерирования сигнала восходящей линии связи, который может передаваться на RAN 120. На RAN 120 сигналы восходящей линии связи от UE 110 и других UE могут приниматься и приводиться в определенное состояние приемником 1324 и дополнительно обрабатываться процессором 1320 для восстановления данных и сообщений, посылаемых при помощи UE. Память 1322 может хранить программные коды и данные для RAN 120, которые могут обмениваться с другими сетевыми объектами при помощи блока 1326 связи.

В шлюзе 130 процессор 1330 может выполнять обработку для шлюза, память 1332 может хранить программные коды и данные для шлюза, и блок 1334 связи может позволять шлюзу выполнять связь с другими сетевыми объектами. Процессор 1330 может выполнять или управлять процессом 900 на фиг.9 и/или другими процессами для методов, описанных в данном документе. Процессор 1330 также может выполнять обработку для шлюза 130 в потоке 300 сообщений на фиг.3 и для шлюза 130b не-3GPP в сообщении 400 на фиг.4.

На домашнем агенте 140 процессор 1340 может выполнять обработку для домашнего агента, память 1342 может хранить программные коды и данные для домашнего агента, и блок 1344 связи может позволять домашнему агенту выполнять связь с другими сетевыми объектами. Процессор 1340 может выполнять или управлять процессом 700 на фиг.7 и/или другими процессами для методов, описанных в данном документе. Процессор 1340 также может выполнять обработку для домашнего агента 140 в потоках 300 и 400 сообщений на фиг.3 и 4 соответственно.

В PCRF 150 процессор 1350 может выполнять обработку для PCRF, память 1352 может хранить программные коды и данные для PCRF, и блок 1354 связи может позволять PCRF выполнять связь с другими сетевыми объектами. Процессор 1350 может выполнять или управлять процессом 500 на фиг.5 и/или другими процессами для методов, описанных в данном документе. Процессор 1350 также может выполнять обработку для PCRF 150 в потоках 300 и 400 сообщений на фиг.3 и 4 соответственно.

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

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

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

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

В одной или нескольких примерных разработках описанные функции могут быть реализованы аппаратными, программными, аппаратно-программными средствами или любой их комбинацией. Если они реализованы программными средствами, функции могут храниться или передаваться в виде одной или нескольких инструкций или кода на считываемой компьютером среде. Считываемая компьютером среда включает в себя как запоминающую среду компьютера, так и среду связи, включающую в себя любую среду, которая способствует пересылке компьютерной программы из одного места в другое. Запоминающая среда может представлять собой любую доступную среду, к которой может обращаться компьютер общего назначения или специального назначения. В качестве примера, а не ограничения, такая считываемая компьютером среда может содержать RAM, ROM, EEPROM, компакт-диск или другое запоминающее устройство на оптическом диске, запоминающее устройство на магнитных дисках или другие магнитные запоминающие устройства или любую другую среду, которая может использоваться для переноса или хранения требуемого средства программного кода в виде инструкций или структур данных и к которой может обращаться компьютер общего назначения или специального назначения или процессор общего назначения или специального назначения. Также любое соединение правильно называется считываемой компьютером средой. Например, если программные средства передаются с веб-сайта, сервера или другого удаленного источника, используя коаксиальный кабель, волоконно-оптический кабель, витую пару, цифровую абонентскую линию (DSL) или беспроводные технологии, такие как инфракрасные, радиочастотные или микроволновые, тогда коаксиальный кабель, волоконно-оптический кабель, витая пара, DSL или беспроводные технологии, такие как инфракрасные, радиочастотные и микроволновые, включаются в определение среды. Диск (disk) и диск (disc), как используется в данном документе, включает в себя компакт-диск (CD), лазерный диск, оптический диск, цифровой многофункциональный диск (DVD), дискету и диск Blu-ray (синелучевой диск), где диски (disk) обычно воспроизводят данные магнитным образом, тогда как диски (disc) воспроизводят данные оптическим образом при помощи лазеров. Комбинации вышеупомянутых также должны быть включены в объем считываемых компьютером сред.

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