Правила управления и тарификации политики (рсс), основанные на протоколе мобильности

Правила управления и тарификации политики (рсс), основанные на протоколе мобильности

Иллюстрации

Показать все

Реферат

Настоящая заявка испрашивает приоритет предварительной заявки США № 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-сеанса.

Таблица 1
	IP-CAN Type установлен на тип радиодоступа	IP-CAN Type установлен на протокол мобильности
Используется для	PCC-сеанс с прямым IP-доступом	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). Первый с