Объект mtc-iwf, объект pcrf и способ связи

Иллюстрации

Показать все

Изобретение относится к области управления качеством обслуживания в системе беспроводной связи. Техническим результатом является обеспечение возможности управления качеством обслуживания конкретной связи в сети наземной мобильной связи общего пользования (PLMN) в ответ на запрос качества обслуживания от сервера возможности предоставления услуг (SCS). Для этого посредством объекта обслуживания принимают от внешнего сервера первый запрос пересылки данных в фоновом режиме и на основании первого запроса отправляют объекту функции правил политики и тарификации (PCRF) второй запрос пересылки данных в фоновом режиме. Причем политика пересылки данных в фоновом режиме определяется объектом PCRF на основании информации в первом запросе. 6 н. и 17 з.п. ф-лы, 6 ил.

Реферат

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

[0001] Настоящая заявка относится к управлению качеством обслуживания в системе беспроводной связи.

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

[0002] Проект партнерства по системам третьего поколения (3GPP) изучил стандартизацию связи машинного типа (MTC). MTC также называется сетью машина-машина (M2M) или сетью датчиков. 3GPP задает мобильные станции (MS, US), реализованные в машинах и датчиках для MTC, как "устройства MTC". Устройства MTC обычно располагаются в различных типах оборудования, включающего в себя машины (например, торговые машины, топливные счетчики, электрические счетчики, транспортные средства, железнодорожные транспортные средства) и датчики (например, датчики, относящиеся к окружающей среде, сельскому хозяйству или дорожному движению). Устройства MTC соединены с сетью наземной мобильной связи общего пользования (PLMN) и осуществляют связь с сервером приложений (AS) MTC. Сервер приложений MTC располагается вне PLMN (т.е., располагается во внешней сети), исполняет приложение MTC и осуществляет связь с приложением MTC UE, реализованным в устройствах MTC. Сервер приложений MTC обычно управляется поставщиком услуг MTC (поставщиком услуг M2M).

[0003] 3GPP точно определяет элементы сети, включающие в себя сервер возможности предоставления услуг (SCS) и функцию взаимодействия для связи машинного типа (MTC-IWF), опорные точки и процедуры для обеспечения серверу приложений MTC возможности осуществления связи с устройствами MTC (см. непатентную литературу 1). Опорные точки также называются "интерфейсами".

[0004] SCS является объектом для соединения сервера приложений MTC с 3GPP PLMN и для обеспечения серверу приложений MTC возможности осуществления связи с UE (т.е., устройством MTC), посредством услуг PLMN, заданных посредством 3GPP. К тому же, SCS обеспечивает серверу приложений MTC возможность осуществления связи с MTC-IWF. Предполагается, что SCS управляется оператором PLMN или поставщиком услуг MTC.

[0005] MTC-IWF является объектом плоскости управления, который принадлежит к PLMN. MTC-IWF имеет интерфейс сигнализации (опорную точку) с SCS и имеет интерфейсы сигнализации (опорные точки) с узлами в PLMN (например, домашний абонентский сервер (HSS), центр обслуживания службы передачи коротких сообщений (SMS-SC), обслуживающий узел поддержки GPRS (SGSN), объект управления мобильностью (MME) и центр коммутации мобильной связи (MSC)). MTC-IWF служит в качестве интерфейса плоскости управления для обеспечения 3GPP PLMN и уровню службы M2M, включающему в себя SCS, возможности взаимодействия друг с другом, при этом скрывая сведения топологии 3GPP PLMN.

[0006] Непатентная литература 2 раскрывает в разделе 7.4.2 процедуру модификации сеанса, инициированную посредством PCRF. В одном примере, функция правил политики и тарификации (PCRF) инициирует процедуру модификации сеанса IP-CAN в ответ на обнаружение трафика приложения (например, службы потоковой передачи видео, службы VoIP, службы совместного использования файлов посредством P2P, характерного для HTTP трафика) посредством функции обнаружения трафика (TDF). В другом примере, PCRF инициирует процедуру модификации сеанса IP-CAN в ответ на служебную информацию (например, изменение в уровне приоритета), предоставленную или отозванную функцией приложения (AF). Непатентная литература 3 раскрывает в разделе 4.3.1 процедуру модификации сеанса IP-CAN, которая подобна процедуре, раскрытой в непатентной литературе 2.

Список цитируемой литературы

Непатентная литература

[0007] [Непатентная литература 1] 3GPP TS 23.682 V11.5.0 (2013-09) "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Architecture enhancements to facilitate communications with packet data networks and applications (Release 11)", сентябрь 2013

[Непатентная литература 2] 3GPP TS 23.203 V11.11.0 (2013-09) "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Policy and charging control architecture (Release 11)", сентябрь 2013

[Непатентная литература 3] 3GPP TS 29.213 V11.8.0 (2013-09) "3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Policy and Charging Control signaling flows and Quality of Service (QoS) parameter mapping (Release 11)", сентябрь 2013

СУЩНОСТЬ ИЗОБРЕТЕНИЯ

Техническая проблема

[0008] Настоящий изобретатель изучил различные способы использования приложения MTC. Например, предполагается, что сеть наземной мобильной связи общего пользования (PLMN) динамически регулирует качество обслуживания конкретной связи (потока служебных данных), касающейся UE (устройства MTC), как например, политику QoS (например, идентификатор класса QoS (QCI), приоритет выделения и удержания (ARP), максимальную скорость передачи битов (MBR), гарантированную скорость передачи битов (GBR)), в ответ на запрос сервером приложений MTC. Для того, чтобы реализовать этот случай использования, например, может быть предпочтительно, чтобы MTC-IWF имела возможность запросить элемент сети в PLMN управлять качеством обслуживания (управления QoS) конкретной связи, в ответ на прием от SCS запроса качества обслуживания. Однако, непатентная литература 1-3 не ознакамливает с такой операцией управления или процедурой управления.

[0009] Ввиду вышеуказанного, одной целью вариантов осуществления, раскрытых в этом описании, является предусмотреть объект MTC-IWF, объект PCRF, способ управления и программу для способствования управлению качеством обслуживания конкретной связи в PLMN в ответ на запрос, посредством SCS, качества обслуживания. Другие цели или проблемы и новаторские признаки станут понятны из описания данной спецификации или прилагаемых чертежей.

Решение проблемы

[0010] В одном аспекте, объект MTC-IWF включает в себя блок управления. Блок управления выполнен с возможностью, в ответ на прием от SCS первого запроса качества обслуживания, которое должно быть применено к конкретной связи устройства MTC, отправки объекту PCRF второго запроса на применение качества обслуживания к конкретной связи.

[0011] В одном аспекте, способ, выполняемый объектом MTC-IWF, включает в себя, в ответ на прием от SCS первого запроса качества обслуживания, которое должно быть применено к конкретной связи устройства MTC, отправку объекту PCRF второго запроса на применение качества обслуживания к конкретной связи.

[0012] В одном аспекте, программа содержит инструкции для предписания компьютеру выполнить способ, выполняемый объектом MTC-IWF, описанным в предыдущем параграфе.

[0013] В одном аспекте, объект PCRF включает в себя блок управления. Блок управления выполнен с возможностью, в ответ на прием от объекта MTC-IWF запроса качества обслуживания, которое должно быть применено к конкретной связи устройства MTC, выполнения управления для применения качества обслуживания к конкретной связи.

[0014] В одном аспекте, способ, выполняемый объектом PCRF, включает в себя, в ответ на прием от объекта MTC-IWF запроса качества обслуживания, которое должно быть применено к конкретной связи устройства MTC, выполнение управления для применения качества обслуживания к конкретной связи.

[0015] В одном аспекте, программа содержит инструкции для предписания компьютеру выполнить способ, выполняемый объектом PCRF, описанным в предыдущем параграфе.

[0016] В одном аспекте, объект PCRF включает в себя блок управления. Блок управления выполнен с возможностью, в ответ на обнаружение конкретного потока пакетов из пользовательского трафика, отправленного или принятого мобильной станцией по уже установленному однонаправленному каналу, предоставления узлу PCRF, имеющему функцию введения в действие политики и тарификации (PCEF), первого правила управления политикой и тарификацией (PCC), которое должно быть применено к конкретному потоку пакетов. В одном примере, мобильной станцией может быть устройство MTC. В этом случае, блок управления может предоставить первое правило PCC узлу PCEF в ответ на прием от объекта MTC-IWF запроса качества обслуживания, которое должно быть применено к конкретной связи устройства MTC.

[0017] В одном аспекте, способ, выполняемый объектом PCRF, включает в себя, в ответ на обнаружение конкретного потока пакетов из пользовательского трафика, отправленного или принятого мобильной станцией по уже установленному однонаправленному каналу, предоставление узлу PCRF, имеющему функцию введения в действие политики и тарификации (PCEF), первого правила управления политикой и тарификацией (PCC), которое должно быть применено к конкретному потоку пакетов. В одном примере, мобильной станцией может быть устройство MTC. В этом случае, предоставление может включать в себя предоставление первого правила PCC узлу PCEF в ответ на прием от объекта MTC-IWF запроса качества обслуживания, которое должно быть применено к конкретной связи устройства MTC.

[0018] В одном аспекте, программа содержит инструкции для предписания компьютеру выполнить способ, выполняемый объектом PCRF, описанным в предыдущем параграфе.

Полезные эффекты изобретения

[0019] Согласно аспектам, описанным выше, возможно предусмотреть объект MTC-IWF, объект PCRF, способ управления и программу для способствования управлению качеством обслуживания конкретной связи в PLMN в ответ на запрос, посредством SCS, качества обслуживания.

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

[0020] Фиг. 1 является схемой, показывающей систему беспроводной связи, согласно первому и второму вариантам осуществления.

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

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

Фиг. 4 является блок-схемой, показывающей пример конфигурации нескольких объектов или узлов, согласно второму варианту осуществления.

Фиг. 5 является схемой, показывающей систему беспроводной связи, согласно другому варианту осуществления 2.

Фиг. 6 является схемой последовательностей, показывающей один пример операции, согласно другому варианту осуществления 2.

ОПИСАНИЕ ВАРИАНТОВ ОСУЩЕСТВЛЕНИЯ

[0021] В дальнейшем конкретные варианты осуществления будут разъяснены подробно со ссылкой на прилагаемые чертежи. Одинаковые символы назначаются одинаковым или соответствующим элементам на всех чертежах, и повторные разъяснения будут опущены по необходимости.

[0022] Первый вариант осуществления

Фиг. 1 является схемой, показывающей пример конфигурации системы беспроводной связи, согласно этому варианту осуществления. Системой беспроводной связи согласно этому варианту осуществления является, например, система беспроводной связи (EPS) 3GPP. EPS также называется системой проекта долгосрочного развития (LTE). В дальнейшем, посредством иллюстрации описывается случай, когда системой беспроводной связи согласно этому варианту осуществления является EPS. Однако, следует отметить, что этот вариант осуществления также применим к другой системе беспроводной связи, такой как универсальная мобильная телекоммуникационная система (UMTS).

[0023] UE 3 исполняет приложение 31 MTC UE и служит в качестве устройства MTC. UE 3 в качестве устройства MTC соединяется с MME 53 через сеть 54 радиодоступа (RAN) и осуществляет связь с сервером 4 приложений MTC. RAN 54 включает в себя усовершенствованную сеть наземного радиодоступа к UMTS (E-UTRAN).

[0024] UE 3 может быть устройством шлюза MTC. Устройство шлюза MTC имеет функцию мобильной связи 3GPP (т.е., функции UE) и соединяется с расположенным рядом устройством (например, датчиком, меткой радиочастотной идентификации (RFID), навигационным устройством автомобиля) посредством технологии персонального/локального соединения. Конкретные примеры технологии персонального/локального соединения включают в себя IEEE 802.15, ZigBee (зарегистрированный товарный знак), Bluetooth (зарегистрированный товарный знак) и IEEE 802.11a. Расположение рядом устройство, которое соединено с устройством шлюза MTC, является обычно устройством, которое не имеет функции мобильной связи 3GPP, но может быть устройством, которое имеет функцию мобильной связи (т.е., устройством MTC).

[0025] В данном описании, термин "устройство MTC" и термин "устройство шлюза MTC" особенно неотличимы друг от друга. Соответственно, термин "устройство MTC", используемое в данном описании, включает в себя устройство шлюза MTC. Вследствие этого, UE 3 в качестве устройства MTC также означает UE 3 в качестве устройства шлюза MTC.

[0026] Объект 1 функции взаимодействия для MTC (MTC-IWF) является объектом плоскости управления, который принадлежит PLMN. Объект 1 MTC-IWF осуществляет связь с другими элементами сети посредством интерфейсов сигнализации (опорных точек). Объект 1 MTC-IWF служит в качестве интерфейса плоскости управления или шлюза для обеспечения 3GPP PLMN и уровню службы M2M, включающему в себя SCS 2, возможности взаимодействия друг с другом, при этом скрывая сведения топологии 3GPP PLMN. В дальнейшем описаны интерфейсы сигнализации (опорные точки) объекта 1 MTC-IWF и другие элементы сети.

[0027] Объект 1 MTC-IWF осуществляет связь с сервером возможности предоставления услуг (SCS) 2 посредством опорной точки Tsp. SCS 2 соединяет сервер 4 приложений MTC с PLMN и обеспечивает серверу 4 приложений MTC возможность осуществления связи с UE 3 (т.е., устройством MTC) посредством служб PLMN, заданных посредством 3GPP. Сервер 4 приложений MTC также называется сервером приложений M2M. К тому же, SCS 2 обеспечивает серверу 4 приложений MTC возможность осуществления связи с объектом 1 MTC-IWF. SCS 2 управляется оператором PLMN или поставщиком услуг MTC. SCS 2 также называется сервером MTC или сервером M2M. SCS 2 может быть одиночным, автономным физическим объектом или может быть функциональным объектом, добавленным к другому элементу сети (например, серверу 4 приложений MTC). Опорная точка Tsp используется, например, для отправки запроса передачи запуска устройства (запроса запуска устройства (DTR)) от SCS 2 объекту 1 MTC-IWF и сообщения результата запуска устройства из объекта 1 MTC-IWF в SCS 2.

[0028] Объект 1 MTC-IWF осуществляет связь с домашним абонентским сервером (HSS) 51 посредством опорной точки S6m. HSS 51 является узлом плоскости управления, расположенным в базовой сети PLMN (т.е., усовершенствованной базовой сети пакетной передачи данных (EPC) в EPS) и управляет абонентской информацией UE 3. Опорная точка S6m используется, например, для отправки запроса касательно абонентской информации от объекта 1 MTC-IWF в HSS 51 и для отправки абонентской информации от HSS 51 объекту 1 MTC-IWF.

[0029] Объект 1 MTC-IWF осуществляет связь с объектом 53 управления мобильностью (MME) посредством опорной точки T5b. MME 53 является узлом базовой сети EPS и выполняет управление мобильностью (например, регистрацию позиции) UE 3, управление однонаправленным каналом (например, установление однонаправленного канала, модификация конфигурации однонаправленного канала и освобождение однонаправленного канала), и подобное. MME 53 отправляет и принимает управляющие сообщения узлу (т.е., eNodeB) и от него в RAN 54, и отправляет и принимает сообщения NAS для UE 3 и от него. Сообщения NAS не прерываются в RAN 54 и прозрачным образом передаются и принимаются между UE 3 и MME 53 вне зависимости от технологии радиодоступа, используемой в RAN.

[0030] Вышеописанные опорные точки Tsp, S6m и T5b заданы в непатентной литературе 1. Однако, непатентная литература 1 не задает опорные точки между объектом 1 MTC-IWF и объектом 5 PCRF, и между объектом 1 MTC-IWF и агентом 52 маршрутизации Diameter (DRA).

[0031] Объект 5 функции правил политики и тарификации (PCRF) является объектом плоскости управления, который расположен в базовой сети (т.е., EPC) EPS. Объект 5 PCRF определяет правило управления политикой и тарификацией (PCC), которое должно быть применено к потоку служебных данных UE 3, и отправляет определенное правило PCC в P-GW 56, имеющий функцию введения в действие политики и тарификации (PCEF). Правило PCC содержит политику QoS, которая должна быть применена к потоку служебных данных UE 3, правило тарификации и шаблон потока служебных данных (SDF) для обнаружения потока служебных данных. К тому же, объект 5 PCRF предоставляет правило обнаружения и управления приложениями (ADC) объекту 57 функции обнаружения трафика (TDF). Правило ADC используется в объекте 57 TDF для того, чтобы обнаруживать трафик конкретного приложения (например, службы потоковой передачи видео, службы VoIP, службы совместного использования файлов посредством P2P, характерного для HTTP трафика) из трафика пользовательских данных, отправленного или переданного посредством UE 3. Правило ADC содержит идентификационную информацию уровней 4-7 эталонной модели OSI, которая требуется для идентификации трафика приложения.

[0032] Объект 5 PCRF имеет интерфейс сигнализации (т.е., опорную точку Gx) с функцией введения в действие политики и тарификации (PCEF), расположенный в P-GW 56. Объект 5 PCRF имеет интерфейс сигнализации (т.е., опорную точку Sd) с объектом 57 функции обнаружения трафика (TDF). К тому же, объект 5 PCRF имеет интерфейс сигнализации (т.е., опорную точку Gxc) с функцией привязки однонаправленных каналов и представления отчетов о событиях (BBERF), расположенной в S-GW 55.

[0033] К тому же, объект 5 PCRF имеет интерфейс 11 сигнализации с объектом 1 MTC-IWF. Интерфейсом 11 сигнализации может быть опорная точка Rx. Опорная точка Rx является интерфейсом между PCRF и функцией приложения (AF). В этом случае, объект 5 PCRF может принять служебную информацию уровня приложения от объекта 1 MTC-IWF, определить правило PCC и предоставить правило PCC для P-GW 56.

[0034] Агент 52 маршрутизации Diameter (DRA) является объектом плоскости управления, который располагается в базовой сети (EPC) EPS. DRA 52 делает возможным расположение множества объектов PCRF в базовой сети (EPC). Конкретно, DRA 52 ассоциирует абонента (UE 3), использующего PLMN, с объектом PCRF, который выполняет управление QoS и управление тарификацией в отношении сеанса IP-CAN абонента. Сведения функции DRA описаны в 3GPP TS 29.213 и IETF RFC 3588.

[0035] DRA 52 может быть реализован как перенаправляющий DRA или как DRA-посредник. Когда DRA 52 реализован как перенаправляющий DRA, в ответ на прием сообщения запроса Diameter от клиента (например, функции приложения (AF), S-GW 55 как BBERF, P-GW 56 как PCEF, и объекта 1 MTC-IWF), DRA 52 отправляет пару атрибут-значение Diameter (Diameter AVP) обратно клиенту. Diameter AVP (т.е., AVP перенаправление-хост-использование), отправленная от DRA 52, указывает объект PCRF, которому клиент должен отправить сообщение запроса Diameter. Когда DRA 52 реализован как DRA-посредник, в ответ на прием сообщения запроса Diameter от клиента (например, функции приложения (AF), S-GW 55 как BBERF, P-GW 56 как PCEF, и объекта 1 MTC-IWF), DRA 52 пересылает принятое сообщение запроса Diameter соответствующему объекту PCRF.

[0036] Следует отметить, что, когда в PLMN есть только один объект 1 MTC-IWF, или когда объект 1 MTC-IWF заранее знает объект 5 PCRF, который управляет сеансом IP-CAN для UE 3 в качестве устройства MTC, например, интерфейс сигнализации 12 между объектом 1 MTC-IWF и DRA 52 может быть опущен. Другими словами, объект 1 MTC-IWF необязательно выполняет сигнализацию с DRA 52.

[0037] Обслуживающий шлюз (S-GW) 55 является узлом пересылки пакетов пользовательской плоскости, расположенным в базовой сети EPS, и он пересылает пакеты пользовательских данных UE 3. S-GW 55 служит в качестве шлюза для RAN 54. S-GW 55 имеет интерфейс туннелирования пользовательской плоскости (т.е., опорную точку S1-U) с RAN 54 (т.е., E-UTRAN) и имеет интерфейс туннелирования пользовательской плоскости (т.е., опорную точку S5/S8) с P-GW 56. S-GW 55 имеет интерфейс сигнализации (т.е., опорную точку S11) с MME 53.

[0038] К тому же, S-GW 55 может иметь функцию привязки однонаправленных каналов и представления отчетов о событиях (BBERF). S-GW 55, служащий в качестве BBERF, принимает правило QoS от объекта 5 PCRF, обнаруживает поток служебных данных (т.е., поток IP-пакетов) UE 3, который должен управляться на основе правила QoS, и ассоциирует обнаруженный поток служебных данных с соответствующим однонаправленным каналом IP-CAN (EPS однонаправленным каналом), соответствующим правилу QoS. К тому же, S-GW 55, служащий в качестве BBERF, сообщает о событии объекту 5 PCRF, на основе триггера события, установленного объектом 5 PCRF.

[0039] Шлюз 56 сети пакетной передачи данных (P-GW) является узлом пересылки пакетов пользовательской плоскости, который расположен в базовой сети (EPC) EPS, и пересылает пакеты пользовательских данных 3. P-GW 56 служит в качестве шлюза для внешней сети пакетной передачи данных (PDN) и предоставляет UE 3 возможность соединения с внешней PDN. Внешняя PDN включает в себя SCS 2 и сервер 4 приложений MTC, например. К тому же, P-GW 56 имеет функцию запуска тарификации (CTF), функцию данных тарификации (CDF) и функцию введения в действие политики и тарификации (PCEF). P-GW 56, служащий в качестве PCEF, выполняет управление качеством обслуживания (QoS) и тарификацию однонаправленного канала на основе потока (FBC) по каждому потоку служебных данных (т.е., потоку IP-пакетов) UE 3 в соответствии с правилом управления политикой и тарификацией (PCC), поданным от объекта 5 PCRF. FBC реализована посредством CTF, CDF, и PCEF P-GW 56.

[0040] Другими словами, P-GW 56 различает множество потоков служебных данных, отправленных или принятых посредством UE 3, с использованием шаблона SDF или шаблона потока трафика (TFT) и назначает каждый поток служебных данных однонаправленному каналу EPS (однонаправленному каналу сети доступа с возможностью соединения по IP (IP-CAN)), соответствующему QoS потока служебных данных. К тому же, P-GW 56 контролирует поток служебных данных как событие с возможностью тарификации, которое запускает генерирование и закрытие записи данных тарификации (CDR), подсчитывает число пакетов в потоке служебных данных, и генерирует CDR, содержащую информацию тарификации, относящуюся к потоку служебных данных. Следует отметить, что событием с возможностью тарификации является активность, которая использует ресурсы или службы, обслуживаемые сетью связи. Событием с возможностью тарификации является, например, связь пользователь-пользователь (например, одиночный вызов, сеанс обмена данными или короткое сообщение), связь пользователь-сеть (например, администрирование профиля службы)), связь между сетями (например, пересылка вызовов, сигнализация или короткие сообщения), или мобильность (например, роуминг или передача обслуживания между системами). CDR является форматированной информацией тарификации (например, время вызова, объем переданных данных и т.д.).

[0041] Объект 57 функции обнаружения трафика (TDF) имеет функцию глубокой проверки пакетов (DPI). Объект 57 TDF принимает правило обнаружения и управления приложениями (ADC) от объекта 5 PCRF посредством опорной точки Sd, выполняет глубокую проверку пакетов в отношении пользовательских пакетов в соответствии с правилом ADC, и обнаруживает трафик приложения (например, службу потоковой передачи видео, службу VoIP, службу совместного использования файлов посредством P2P, характерный для HTTP трафик), точно определенный правилом ADC. Затем, объект 57 TDF сообщает объекту 5 PCRF результат обнаружения трафика приложения посредством опорной точки Sd. Функция объекта 57 TDF может сочетаться с PCEF. Другими словами, объект 57 TDF может быть расположен в P-GW 56. Еще раз другими словами, P-GW 56 может иметь PCEF, расширенную с помощью ADC.

[0042] В дальнейшем описано управление качеством обслуживания конкретной связи UE 3. В примере по Фиг. 1, объект 1 MTC-IWF имеет интерфейс 11 сигнализации (опорную точку) с объектом 5 PCRF. В ответ на прием первого запроса QoS от SCS 2 посредством опорной точки Tsp, объект 1 MTC-IWF отправляет второй запрос QoS объекту 5 PCRF посредством интерфейса 11 сигнализации.

[0043] Первый запрос QoS, который отправлен от SCS 2 объекту 1 MTC-IWF, запрашивает качество обслуживания, которое должно быть применено в конкретной связи UE 3 в качестве устройства MTC. Конкретной связью UE 3 может быть связь с конкретной системой, связь по конкретному протоколу или трафик конкретного приложения. Другими словами, конкретная связь для UE 3 может быть точно определена посредством любой одной идентификационной информации об уровне 3-7 эталонной модели OSI или ее комбинации.

[0044] Для того, чтобы точно определить качество обслуживания, первый запрос QoS может указать по меньшей мере одно из идентификатора класса QoS (QCI), приоритета выделения и удержания (ARP), максимальной скорости передачи битов (MBR), гарантированной скорости передачи битов (GBR) и уровня приоритета (например, высокого приоритета, среднего приоритета и низкого приоритета). К тому же, первый запрос QoS может содержать имя приложения (например, YouTube (зарегистрированный товарный знак), Skype (зарегистрированный товарный знак)) для того, чтобы точно определить конкретную связь для UE 3. К тому же, первый запрос QoS может содержать по меньшей мере одно из адреса источника, адреса назначения, номера порта и идентификатора протокола для идентификации потока пакетов конкретной связи UE 3. Кроме того, первый запрос QoS может указать предназначенное использование (например, фоновая связь, автоматическое обновление программного обеспечения, автоматическое считывание показаний) конкретной связи.

[0045] Первый запрос QoS может содержать внешний идентификатор (внешний ID), ассоциированный с UE 3, для того, чтобы точно определить целевое UE 3. Внешний ID используется для идентификации UE 3 вне PLMN, содержащей SCS 2 и сервер 4 приложений MTC. Внешним ID может быть, например, номер абонента мобильной связи ISDN (MSISDN).

[0046] Первый запрос QoS может содержать идентификатор SCS 2 для того, чтобы указать отправителя SCS 2. К тому же, первый запрос QoS может содержать идентификатор транзакции (например, порядковый номер) для того, чтобы отличаться среди множества первых запросов QoS, отправленных от SCS 2.

[0047] Второй запрос QoS, который отправлен от объекта 1 MTC-IWF в объект 5 PCRF, может указывать информацию, аналогичную информации, содержащейся в первом запросе QoS, для того, чтобы точно определить качество обслуживания. Конкретно, второй запрос QoS может указывать по меньшей мере одно из QCI, ARP, MBR, GBR и уровня приоритета. К тому же, второй запрос QoS может содержать по меньшей мере одно из адреса источника, адреса назначения, номера порта и идентификатора протокола для идентификации потока пакетов конкретной связи UE 3. Кроме того, второй запрос QoS может указывать предназначенное использование конкретной связи.

[0048] Второй запрос QoS может содержать внутренний идентификатор (внутренний ID), ассоциированный с UE 3, для того, чтобы точно определить целевое UE 3. Внутренний ID используется для идентификации UE 3 внутри PLMN. Внутренним ID является, например, международный идентификатор абонента мобильной связи (IMSI). Объект 1 MTC-IWF может получить внутренний ID для UE 3, спрашивая HSS 51 о внутреннем ID, соответствующим внешнему ID для UE 3.

[0049] В случае, когда множество объектов 5 PCRF расположены в PLMN, объект 1 MTC-IWF должен выбрать объект 5 PCRF, который управляет служебными потоками UE 3, из множества объектов 5 PCRF. Таким образом, объект MTC-IWF 5 может обмениваться управляющими сообщениями с DRA 52 и тем самым получая адрес соответствующего объекта 5 PCRF от DRA 52.

[0050] Объект 5 PCRF выполняет управление для применения качества обслуживания, запрошенного посредством второго запроса QoS, к конкретной связи UE 3 в ответ на прием второго запроса QoS от объекта 1 MTC-IWF. Для того, чтобы применить качество обслуживания, запрошенное посредством второго запроса QoS, к конкретной связи UE 3, объект 5 PCRF может управлять по меньшей мере одним из P-GW 56, служащего в качестве PCEF, и объекта 57, служащего в качестве TDF.

[0051] Если быть точнее, объект 5 PCRF может сгенерировать правило PCC на основе качества обслуживания, указанного посредством второго запроса QoS, идентификатора UE 3 и идентификационной информации (например, имени приложения, адреса источника, номера порта или идентификатора протокола, или любой их комбинации) конкретной связи, и предоставить сгенерированное правило PCC для P-GW 56. Предоставление правила PCC для P-GW 56 запускает модификацию сеанса IP-CAN касательно UE 3. Например, модификация сеанса IP-CAN включает в себя обновление QoS однонаправленного канала IP-CAN (однонаправленного канала EPS), который был уже установлен, или включает в себя обновление шаблона SDF или шаблона потока трафика (TFT). К тому же, когда политика QoS, которая должна быть применена к потоку служебных данных (потоку IP-пакетов) конкретной связи UE 3, отличается от политики QoS однонаправленного канала EPS, который был уже установлен, модификация однонаправленного канала IP-CAN может включать в себя генерирование нового выделенного однонаправленного канала EPS для пересылки потока служебных данных конкретной связи UE 3.

[0052] К тому же, объект 5 PCRF может сгенерировать правило ADC на основе идентификационной информации (например, имени приложения) конкретной связи, указанной посредством второго запроса QoS, и предоставить сгенерированное правило PCC объекту 57 TDF. Затем, в ответ на обнаружение потока пакетов конкретной связи из пользовательского трафика, отправленного или принятого посредством UE 3 через однонаправленный канал EPS, который был уже установлен, объект 5 PCRF может сгенерировать правило PCC, которое должно быть применено к потоку пакетов конкретной связи. Например, когда конкретная связь для UE 3 точно определяется информацией об уровнях 5-7 (например, именем приложения) эталонной модели OSI во втором запросе QoS, объект 5 PCRF не может сгенерировать достаточное правило PCC только из информации, содержащейся во втором запросе QoS в некоторых случаях. Это потому, что не известна информация об уровнях 3 и 4, требуемая для правила PCC (если быть точнее, шаблона SDF или TFT), такая как IP-адрес узла, с которым UE 3 осуществляет связь. Соответственно, объект 5 PCRF может обнаружить трафик конкретной связи (т.е., трафик конкретного приложения) из потока пользовательских данных UE 3 посредством функции глубокой проверки пакетов (DPI) в объекте 57 TDF. Объект 5 PCRF таким образом получает информацию, требуемую для определения правила PCC, которой является информация об уровнях 3 и 4, такая как IP-адрес узла, с которым UE 3 осуществляет связь, и номер порта.

[0053] Фиг. 2 является схемой последовательностей, показывающей один пример управления качеством обслуживания (управления QoS) для UE 3 на основе запроса от SCS 2. На этапе S101, SCS 2 отправляет первый запрос QoS объекту 1 MTC-IWF посредством опорной точки Tsp. Первый запрос QoS содержит внешний ID для UE 3 для идентификации UE 3, для которого должно быть выполнено управление. К тому же, первый запрос QoS содержит информацию для идентификации конкретной связи UE 3, которая включает в себя, например, имя приложения, номер порта или IP-адрес узла, с которым UE 3 осуществляет связь, или любую их комбинацию. Кроме того, первый запрос QoS указывает информацию для идентификации требуемого качества обслуживания, которая включает в себя, например, QCI, ARP, MBR, GBR или уровень приоритета, или любую их комбинацию.

[0054] На этапе S102, в ответ на прием первого запроса QoS от SCS 2, объект 1 MTC-IWF спрашивает HSS 1 о внутреннем ID, соответствующем внешнему ID для UE 3, указанному посредством первого запроса QoS. Объект 1 MTC-IWF может запросить HSS 51 отправить абонентскую информацию, соответствующую внешнему ID для UE 3. Следует отметить, что, когда объект 1 MTC-IWF уже знает внутренний ID для UE 3, этап S102 может быть пропущен.

[0055] На этапе S103, объект 1 MTC-IWF спрашивает DRA 52 об объекте 5 PCRF, который управляет сеансом IP-CAN для UE 3. Объект 1 MTC-IWF может запросить DRA 52 отправить адрес объекта 5 PCRF, который управляет сеансом IP-CAN для UE 3. Следует отметить, что, когда в PLMN расположен только один объект 5 PCRF, или объект 1 MTC-IWF уже знает объект 5 PCRF, который управляет UE 3 в качестве устройства MTC, этап S103 может быть пропущен.

[0056] На этапе S104, объект 1 MTC-IWF отправляет второй запрос QoS объекту 5 PCRF через интерфейс 11 сигнализации. В примере по Фиг. 2, второй запрос QoS содержит внутренний ID для UE 3 для идентификации UE 3, для которого должно быть выполнено управление. К тому же, второй запрос QoS содержит информацию для идентификации конкретной связи UE 3, которая включает в себя, например, имя приложения, номер порта или IP-адрес узла, с которым UE 3 осуществляет связь, или любую их комбинацию. Кроме того, второй запрос QoS указывает информацию для идентификации требуемого качества обслуживания, которая включает в себя, например, QCI, ARP, MBR, GBR или уровень приоритета, или любую их комбинацию.

[0057] На этапе S105, в ответ на прием второго запроса QoS от объекта 1 MTC-IWF, объект 5 PCRF определяет правило PCC, которое должно быть применено к конкретной связи UE 3. Это правило PCC содержит шаблон SDF (т.е., пакетный фильтр) для идентификации потока пакетов, относящегося к конкретной связи UE 3, и также содержит информацию для управления QoS (например, QCI, ARP, MBR, GBR). К тому же, правило PCC может содержать информацию для управления тарификацией (например, ключ тарификации, способ тарификации, способ измерения) в отношении конкретной связи UE 3. На этапе S106, объект 5 PCRF отправляет определенное правило PCC в P-GW 56 (PCEF) для того, чтобы ввести в действие определенное правило PCC в отношении конкретной связи UE 3.

[0058] На этапе S107, P-GW 56, служащий в качестве PCEF, принимает правило PCC и затем применяет его к связи UE 3. Если быть точнее, P-GW 56 инициирует процедуру модификации сеанса IP-CAN в ответ на прием правила PCC. Как описано ранее, модификация сеанса IP-CAN может включать в себя обновление QoS однонаправленного канала IP-CAN (однонаправленного канала EPS), который был уже установлен, или включает в себя обновление шаблона SDF или шаблона потока трафика (TFT), например. К тому же, когда политика QoS, которая должна быть применена к потоку служебных данных (потоку IP-пакетов), относящемуся к конкретной связи UE 3, отличается от политики QoS однонаправленного канала EPS, который был уже установлен, модификация однонаправленного канала IP-CAN может включать в себя генерирование нового выделенного однонаправленного канала EPS для пересылки потока служебных данных конкретной связи UE 3.

[0059] Как понятно из вышеуказанного описания, в этом варианте осуществления, объект 1 MTC-IWF и объект 5 PCRF функционируют для регулирования качества обслуживания (QoS) конкретной связи (например, трафика конкретного приложения) UE 3 на основе запроса, посредством SCS 2, качества обслуживания (QoS). Таким образом, согласно этому варианту осуществления, возможно способствовать управлению качества обслуживания конкретной связи UE 3 в PLMN в ответ на запрос, посредством SCS 2, качества обслуживания.

[0060] Второй вариант осуществления

В этом варианте осуществления, описан другой конкретный пример управления качеством обслуживания (управления QoS) для UE 3 на основе запроса от SCS 2. Пример конфигурации системы беспроводной связи согласно этому варианту осуществления является таким же как пример конфигурации, показанный на Фиг. 1.

[0061] Фиг. 3 является схемой последовательностей, показывающей один пример управления качеством обслуживания (управления QoS) для UE 3 на основе запроса от SCS 2. В примере по Фиг. 3, первый запрос QoS, который отправлен из SCS 2, и второй запрос QoS, который отправлен из объекта 1 MTC-IWF, идентифицируют конкретную связь для UE 3 посредством информации об уровнях 5-7 (например, имени приложения) эталонной модели OSI. Соответственно, для того, чтобы обнаружить трафик конкретной связи (т.е., трафик конкретного приложения) из потока пользовательских данных UE 3, объект 5 PCRF использует функцию глубокой проверки пакетов (DPI) в объекте 57 TDF. Объект 5 PCRF таким образом получает информацию, требуемую для определения правила PCC, которой является информация об уровнях 3 и 4 (например, IP-адрес узла, с которым UE 3 осуществляет связь, и номер порта), относящаяся к конкретной связи UE 3.

[0062] На этапе S201, SCS 2 отправляет первый запрос QoS объекту 1 MTC-IWF посредством опорной точки Tsp. Первый запрос QoS содержит информацию об уровнях 5-7 (например, имя приложения) для идентификации конкретной связи UE 3. К тому же, как первый запрос, описанный выше по отношению к Фиг. 2, первый запрос QoS может содержать внешний ID для UE 3 и информацию для идентификации требуемого качества обслуживания (например, QCI, ARP, MBR, GBR или уровень приоритета).

[0063] На этапе S202, объект 1 MTC-IWF отправляет второй запрос QoS объекту 5 PCRF через интерфейс 11 сигнализации. Второй запрос QoS содержит информацию об уровнях 5-7 (например, имя приложения) для идентификации конкретной связи UE 3. К тому же, как второй запрос, описанный выше по отношению к Фиг. 2, второй запрос QoS может содержать внутренний ID для UE 3 и информацию для идентификации требуемого качества обслуживания (например, QCI, ARP, MBR, GBR или уровень приоритета). К тому же, до этапа S202 могут быть сделаны запрос к HSS 51 и запрос к DRA 52 (этапы S102 и S103 на Фиг. 2)

[0064] На этапе S203, в ответ на прием второго запроса QoS, объект 5 PCRF определяет правило ADC, которое должно быть использовано для обнаружения трафика конкретной связи (т.е., трафика конкретного приложения) из потока пользовательских данных UE 3. Это правило ADC содержит идентификатор (например, IP-адрес) целевого UE 3 и идентификатор (например, имя приложения) приложения, которое должно быть обнаружено. На этапе S204, объект 5 PCRF предоставляет опреде