ОБЪЕКТ MTC-IWF, ОБЪЕКТ PCRF И СПОСОБ СВЯЗИ

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

[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 предоставляет определенное правило ADC объекту 57 TDF.

[0065] На этапе S205, объект 57 TDF начинает DPI в отношении потока пользовательских данных UE 3, для того, чтобы обнаружить трафик конкретного приложения в соответствии с принятым правилом ADC. Затем, на этапе S206, в ответ на обнаружение трафика конкретного приложения, объект 57 TDF отправляет отчет об обнаружении объекту 5 PCRF. Отчет об обнаружении содержит информацию об уровнях 3 и 4 (например, IP-адрес узла, с которым UE 3 осуществляет связь, и номер порта), относящуюся к трафику конкретного приложения.

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

[0067] На этапе S209, P-GW 56, служащий в качестве PCEF, принимает правило PCC и применяет его к связи UE 3. Если быть точнее, P-GW 56 инициирует процедуру модификации сеанса IP-CAN в ответ на прием правила PCC.

[0068] Фиг. 4 является блок-схемой, показывающей пример конфигурации объекта 1 MTC-IWF, объекта 5 PCRF, P-GW 56 и объекта 57 TDF согласно этому варианту осуществления. В примере по Фиг. 4, объект 1 MTC-IWF включает в себя блок 101 управления. Блок 101 управления выполнен с возможностью отправки второго запроса QoS объекту 5 PCRF в ответ на прием первого запроса QoS от SCS 2.

[0069] В примере по Фиг. 4, объект 5 PCRF включает в себя блок 501 управления. Блок 501 управления выполнен с возможностью, в ответ на прием второго запроса QoS, определения правила ADC для определения трафика конкретного приложения UE 3 и предоставления определенного правила ADC объекту 57 TDF. Блок 501 управления дополнительно выполнен с возможностью приема отчета об обнаружении, относящегося к трафику конкретного приложения UE 3, от объекта 57 TDF, определения правила PCC, которое должно быть применено к трафику конкретного приложения UE 3, и предоставления определенного правила PCC для P-GW 56.

[0070] В примере по Фиг. 4, объект 57 TDF включает в себя блок 571 сигнализации и блок 572 обнаружения. Блок 571 сигнализации выполнен с возможностью приема правила ADC от объекта 5 PCRF (блока 501 управления) и отправки отчета об обнаружении, относящегося к трафику приложения, обнаруженному на основе правила ADC. Блок 572 обнаружения выполнен с возможностью выполнения DPI в отношении трафика пользовательских данных UE 3, для того, чтобы обнаружить трафик приложения, точно определенный правилом ADC.

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

[0072] Согласно этому варианту осуществления, SCS 2 может точно определить конкретную связь для UE 3, на которое нацелен запрос QoS, посредством информации об уровнях 5-7 эталонной модели OSI в первом запросе QoS. Например, конкретная связь для UE 3, на которое нацелен запрос QoS, может быть точно определена посредством имени приложения (например, YouTube (зарегистрированный товарный знак), Skype (зарегистрированный товарный знак)) в первом запросе QoS. В другом примере, конкретная связь для UE 3 может быть точно определена посредством ее предназначенного использования (например, фоновая связь, автоматическое обновление программного обеспечения, автоматическое считывание показателей) в первом запросе QoS. Таким образом, когда SCS 2 отправляет запрос QoS в PLMN (объект 1 MTC-IWF), возможно гибким образом точно определить конкретную связь для UE 3, на которое нацелен запрос QoS, посредством использования информации верхнего уровня (уровни 5-7).

[0073] Другой вариант осуществления 1

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

[0074] В вышеописанном втором варианте осуществления, описан пример применения правила PCC на основе запроса QoS, точно определяющего приложение посредством информации об уровнях 5-7. Конкретно, объект 5 PCRF согласно второму варианту осуществления использует DPI в TDF в ответ на запрос QoS, точно определяющий приложение посредством информации об уровнях 5-7, и тем самым получая информацию об уровнях 3 и 4, требуемую для принятия решения о правиле PCC (шаблоне SDF). Эта операция объекта 5 PCRF может быть выполнена для запроса QoS из другого узла или объекта (например, функции приложения), который отличается от SCS 2 и объекта 1 MTC-IWF. Таким образом, когда узел или объект (например, функция приложения) делает запрос QoS к объекту 5 PCRF, возможно гибким образом точно определить конкретную связь для UE 3, на которое нацелен запрос QoS, посредством использования информации верхнего уровня (уровни 5-7).

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

[0076] Операции объекта 1 MTC-IWF, SCS 2, UE 3, объекта 5 PCRF, S-GW 55, P-GW 56, объекта 57 TDF, и подобных, описанных в первом и втором вариантах осуществления, могут быть реализованы посредством предписания компьютерной системе, включающей в себя по меньшей мере один процессор (например, микропроцессор, микропроцессорный блок (MPU), центральный процессор (CPU)), выполнить программу. Если быть точнее, одна или более программ, содержащих инструкции, которые предписывают компьютеру выполнить алгоритмы, описанные с использованием Фиг. 2, 3 и подобные, могут быть поданы в компьютер.

[0077] Эти программы могут храниться и предоставляться компьютеру с использованием любого типа энергонезависимого компьютерно-читаемого носителя. Энергонезависимый компьютерно-читаемый носитель включает в себя любой тип материального носителя информации. Примеры энергонезависимого компьютерно-читаемого носителя включают в себя магнитные носители информации (такие как гибкие диски, магнитные пленки, накопители на жестких дисках и т.д.), оптико-магнитные носители информации (например, магнито-оптические диски), постоянную память на основе компакт-диска (CD-ROM), CD-R, CD-R/W, и полупроводниковые устройства памяти (такие как ROM с масочным программированием, программируемая ROM (PROM), стираемая PROM (EPROM), flash ROM, оперативная память (RAM) и т.д.). Эти программы могут быть предоставлены компьютеру с использованием любого типа промежуточного компьютерно-читаемого носителя. Примеры промежуточного компьютерно-читаемого носителя включают в себя электрические сигналы, оптические сигналы и электромагнитные волны. Промежуточный компьютерно-читаемый носитель может предоставлять программы компьютеру через линию проводной связи (например, электрические провода и оптоволоконные линии) или линию беспроводной связи.

[0078] Другой вариант осуществления 2

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

[0079] Фиг. 5 является схемой, показывающей пример конфигурации системы беспроводной связи, согласно этому варианту осуществления. Устройство 61 MTC может соединиться с PLMN 62 и может осуществлять связь с сервером 63 MTC через PLMN 62. Устройство 61 MTC может также называться как UE, которое исполняет приложение MTC UE. Устройством 61 MTC может быть устройство шлюза MTC.

[0080] Сетью 62 наземной мобильной связи общего пользования (PLMN) является 3GPP-сеть, т.е., универсальная мобильная телекоммуникационная система (UMTS) или усовершенствованная пакетная система (EPS), например. PLMN 62 включает в себя сеть радиодоступа (RAN) и базовую сеть. Если быть более точным, PLMN 62 включает в себя базовую станцию в качестве узла RAN, узел управления мобильностью в качестве объекта плоскости управления базовой сети (например, MME или функцию плоскости управления SGSN) и узел пересылки данных в качестве объекта пользовательской плоскости базовой сети (например, P-GW, S-GW, GGSN или функцию пользовательской плоскости SGSN). К тому же, PLMN 62 может включать в себя функцию взаимодействия для связи машинного типа (MTC-IWF), которая обеспечивает возможность взаимодействия уровня службы M2M, содержащего сервер 63 MTC, с PLMN 62.

[0081] Сервер 63 MTC соединяет приложение 64 M2M с PLMN 62 и обеспечивает приложению 64 M2M возможность осуществления связи с устройством 61 MTC посредством служб, обслуживаемых посредством PLMN 62. Сервер 63 MTC также называется сервером возможности предоставления услуг (SCS) или сервером M2M.

[0082] Приложение 64 M2M располагается вне PLMN 62 (т.е., располагается во внешней сети), исполняет приложение M2M (приложение MTC), и осуществляет связь с приложением MTC UE, реализованным в устройстве 61 MTC. Приложение 64 M2M в основном управляется поставщиком услуг M2M (поставщиком услуг MTC). Приложение 64 M2M также называется сервером приложений M2M или сервером приложений MTC.

[0083] Функционирование устройства 61 MTC, PLMN 62 и сервера 63 MTC согласно этому варианту осуществления описано более подробно ниже. В ответ на прикрепление устройства 61 MTC к PLMN 62 (этап S601), PLMN 62 функционирует для уведомления сервера 63 MTC о прикреплении устройства 61 MTC к PLMN 62 (этап S602). Следует отметить, что, прикрепление устройства 61 MTC к PLMN 62 означает, что управление мобильностью для устройства 61 MTC начато в PLMN 62. Например, в примере EPS, устройство 61 MTC регистрируется в MME из PLMN 62 и переходит из состояния с дерегистрацией управления мобильностью EPS (EMM) в состояние с регистрацией EMM. Другими словами, после прикрепления устройства 61 MTC к PLMN 62, PLMN 62 может выйти на устройство 61 MTC посредством поискового вызова. Таким образом, другими словами, PLMN 62 уведомляет сервер 63 MTC, что на устройство 61 MTC можно выйти посредством поискового вызова.

[0084] Сервер 63 MTC принимает уведомление о прикреплении (S602) устройства 61 MTC от PLMN 62 и распознает, что он теперь может осуществлять связь с устройством 61 MTC. Соответственно, сервер 63 MTC может начать осуществление связи с устройством 61 MTC (этап S603).

[0085] Операции на этапах S601-S603 особенно эффективны в случае, когда сервер 63 MTC не может точно распознать период, когда он может осуществлять связь с устройством 61 MTC через PLMN 62. Одним примером является случай, когда устройство 61 MTC останавливает функционирование модуля связи в большинстве случаев для того, чтобы уменьшить потребление электроэнергии. В этом случае, устройство 61 MTC может иметь расписание пробуждения/сна, которое задается сервером 63 MTC. Расписание пробуждения/сна задает период пробуждения и период сна. Во время периода пробуждения, устройство 61 MTC было прикреплено к PLMN 62 и может осуществлять связь с сервером 63 MTC через PLMN 62. Во время периода сна, устройство 61 MTC было откреплено от PLMN 62 и не может ответить на поисковый вызов от PLMN 6, и таким образом сервер 63 MTC не может осуществлять связь с устройством 61 MTC.

[0086] Устройство 61 MTC может осуществлять связь с PLMN 62 даже во время периода сна в ответ на некоторое событие запуска. Однако, сервер 63 MTC может не знать тот факт, что устройство 61 MTC было прикреплено к PLMN 62 (т.е., он может начать связь c устройством 61 MTC) за исключением предварительно определенного периода пробуждения. К тому же, может быть случай, когда устройство 61 MTC не прикрепляется к PLMN 62 даже во время периода пробуждения, когда нет данных для отправки, или когда не удовлетворяются точно определенные условия для передачи. К тому же, есть возможность, что внутренние часы в устройстве 61 MTC недостаточно точны, и соответственно расписание пробуждения/сна устройства 61 MTC является несинхронным с расписанием пробуждения/сна сервера 63 MTC. В этих случаях, сервер 63 MTC может точно не знать тот факт, что устройство 61 MTC было прикреплено к PLMN 62 (т.е., он может начать осуществление связи c устройством 61 MTC).

[0087] Вследствие этого, как описано выше, информируя сервер 63 MTC, что устройство 61 MTC было прикреплено к PLMN 62 (т.е., связь c устройством 61 MTC была начата), PLMN 62 может увеличить возможности для сервера 63 MTC для осуществления связи с устройством 61 MTC.

[0088] Этот вариант осуществления может быть эффективно применен, например, к случаю, когда устройство 61 MTC соединено с водомером реки и сообщает измеренный уровень воды серверу 63 MTC или приложению 64 M2M. Короткий период пробуждения (например, 1 минута) и длинный период пробуждения (например, 6 часов) могут быть заданы устройству 61 MTC посредством сервера 63 MTC. К тому же, устройство 61 MTC может сообщить новый результат измерения, только когда уровень измеренной воды превышает точно определенный порог. Устройство 61 MTC может не сообщать никакого результата измерения длительное время (например, несколько месяцев), пока уровень воды является нормальным.

[0089] Однако, когда один или более результатов измерения были сообщены от одного или нескольких водомеров (устройств MTC 61), и результат(ы) измерения указывает(ют) значение, которое предупреждает в возникновении наводнения, предпочтительно сразу и часто получать результаты измерения других водомеров (устройств MTC 61) чтобы более конкретно распознать текущую ситуацию. В этом случае, предпочтительно сразу обновить расписание пробуждения/сна всех релевантных устройств MTC 61 (например, устройств MTC 61, установленных на той же реке). Согласно операции на этапах S601-S603, описанных выше, сервер 62 MTC может точно распознать, что возможно начать связь c устройством 61 MTC (т.е., связь, прерванную мобильным устройством), и таким образом сервер 62 MTC может сразу отправить новое расписание пробуждения/сна также на устройство 62 MTC, из которого не был сообщен результат измерения.

[0090] Фиг. 6 является схемой последовательностей, показывающей конкретный пример операции на этапах S601-S603, описанной со ссылкой на Фиг. 5. В примере по Фиг. 6, PLMN 62 включает в себя MME 621 и объект 622 MTC-IWF. На этапе S701, устройство 61 MTC отправляет запрос прикрепления в MME 621 и инициирует процедуру прикрепления с MME 621. На этапе S702, MME 621 отправляет объекту 622 MTC-IWF уведомление, указывающее прикрепление устройства 61 MTC к PLMN 62. На этапе S702, в ответ на уведомление от MME 621, объект 622 MTC-IWF отправляет серверу 63 MTC уведомление, указывающее прикрепление устройства 61 MTC к PLMN 62. На этапе S704, сервер 62 MTC отправляет новое расписание пробуждения/сна устройству 61 MTC через PLMN 62. Новое расписание пробуждения/сна может быть отправлено посредством электронной почты, сообщения службы коротких сообщений (SMS) или службы мультимедийных сообщений (MMS), например.

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

[0092] Например, все или часть вариантов осуществления, раскрытых выше, могут быть описаны, но не ограничены этим, как нижеследующие дополнительные примечания.

[0093] (Дополнительное примечание 1)

Объект функции правил политики и тарификации (PCRF), включающий в себя:

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

[0094] (Дополнительное примечание 2)

Объект PCRF согласно дополнительному примечанию 1, в котором первое правило PCC отличается от второго правила PCC, которое должно быть применено к пользовательскому трафику.

[0095] (Дополнительное примечание 3)

Объект PCRF согласно дополнительному примечанию 1 или 2, в котором предоставление первого правила PCC узлу PCEF запускает генерирование нового выделенного однонаправленного канала для пересылки конкретного потока пакетов.

[0096] (Дополнительное примечание 4)

Объект PCRF согласно любому из дополнительных примечаний 1-3, в котором

блок управления предоставляет узлу TDF, имеющему функцию обнаружения трафика (TDF), правило обнаружения и управления приложениями (ADC) для обнаружения конкретного потока пакетов, и

блок управления предоставляет первое правило PCC узлу PCEF в ответ на обнаружение конкретного потока пакетов посредством узла TDF.

[0097] (Дополнительное примечание 5)

Объект PCRF согласно дополнительному примечанию 4, в котором

правило ADC содержит имя приложения, точно определяющее конкретный поток пакетов, и

первое правило PCC указывает по меньшей мере одно из адреса источника, адреса назначения, номера порта и идентификатора протокола, которые были обнаружены узлом TDF для конкретного потока пакетов на основе имени приложения.

[0098] (Дополнительное примечание 6)

Объект PCRF согласно любому из дополнительных примечаний 1-3, в котором

мобильная станция является устройством связи машинного типа (MTC), и

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

[0099] (Дополнительное примечание 7)

Объект PCRF согласно дополнительному примечанию 4 или 5, в котором

мобильная станция является устройством связи машинного типа (MTC), и

блок управления предоставляет правило ADC узлу TDF в ответ на прием, от объекта функции взаимодействия для связи машинного типа (MTC-IWF), запроса качества обслуживания, которое должно быть применено к конкретной связи устройства MTC.

[0100] (Дополнительное примечание 8)

Объект PCRF согласно дополнительному примечанию 4, 5 или 7, в котором блок управления уведомляет узел TDF о периоде, когда правило ADC должно быть введено в действие.

[0101] (Дополнительное примечание 9)

Объект PCRF согласно дополнительному примечанию 7, в котором

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

блок управления уведомляет узел TDF о периоде, когда правило ADC должно быть введено в действие, которое определено на основе периода, когда должно быть применено качество обслуживания.

[0102] (Дополнительное примечание 10)

Способ управления, выполняемый объектом функции правил политики и тарификации (PCRF), причем способ управления, включающий в себя:

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

[0103] (Дополнительное примечание 11)

Способ управления согласно дополнительному примечанию 10, в котором первое правило PCC отличается от второго правила PCC, которое должно быть применено к пользовательскому трафику.

[0104] (Дополнительное примечание 12)

Способ управления согласно дополнительному примечанию 10 или 11, в котором предоставление первого правила PCC узлу PCEF запускает генерирование нового выделенного однонаправленного канала для пересылки конкретного потока пакетов.

[0105] (Дополнительное примечание 13)

Способ управления согласно любому из дополнительных примечаний 10-12, в котором предоставление включает в себя

отправку узлу TDF, имеющему функцию обнаружения трафика (TDF), правила обнаружения и управления приложениями (ADC) для обнаружения конкретного потока пакетов, и

предоставление первого правила PCC узлу PCEF в ответ на обнаружение конкретного потока пакетов посредством узла TDF.

[0106] (Дополнительное примечание 14)

Способ управления согласно дополнительному примечанию 13, в котором

правило ADC содержит имя приложения, точно определяющее конкретный поток пакетов, и

первое правило PCC указывает по меньшей мере одно из адреса источника, адреса назначения, номера порта и идентификатора протокола, которые были обнаружены узлом TDF для конкретного потока пакетов на основе имени приложения.

[0107] (Дополнительное примечание 15)

Способ управления согласно любому из дополнительных примечаний 10-12, в котором

мобильная станция является устройством связи машинного типа (MTC), и

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

[0108] (Дополнительное примечание 16)

Способ управления согласно дополнительному примечанию 13 или 14, в котором

мобильная станция является устройством связи машинного типа (MTC), и

отправка включает в себя отправку правила ADC узлу TDF в ответ на прием, от объекта функции взаимодействия для связи машинного типа (MTC-IWF), запроса качества обслуживания, которое должно быть применено к конкретной связи устройства MTC.

[0109] (Дополнительное примечание 17)

Программа для предписания компьютеру выполнить способ управления, относящийся к функции правил политики и тарификации (PCRF), причем способ управления включает в себя:

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

[0110] (Дополнительное примечание 18)

Сетевой узел, расположенный в сети наземной мобильной связи общего пользования (PLMN), включающий в себя:

блок управления, выполненный с возможностью, в ответ на прикрепление устройства связи машинного типа (MTC) к PLMN, отправки серверу MTC, расположенному вне PLMN, уведомления, указывающего, что связь c устройством MTC возможна.

[0111] (Дополнительное примечание 19)

Сетевой узел согласно дополнительному примечанию 18, в котором сетевой узел является объектом функции взаимодействия для связи машинного типа (MTC-IWF).

[0112] (Дополнительное примечание 20)

Способ, выполняемый сетевым узлом, расположенным в сети наземной мобильной связи общего пользования (PLMN), включающий в себя:

в ответ на прикрепление устройства связи машинного типа (MTC) к PLMN, отправку серверу MTC, расположенному вне PLMN, уведомления, указывающего, что связь c устройством MTC возможна.

[0113] (Дополнительное примечание 21)

Способ согласно дополнительному примечанию 20, в котором сетевой узел является объектом функции взаимодействия для связи машинного типа (MTC-IWF).

[0114] Эта заявка основана на и испрашивает приоритет по патентной заявке Японии № 2014-002755, поданной 3 января, 2014, раскрытие которой включено в настоящий документ посредством ссылки в полном объеме.

Список ссылочных обозначений

[0115] 1 Объект функции взаимодействия для связи машинного типа (MTC-IWF)

2 Сервер возможности предоставления услуг (SCS)

3 Пользовательское оборудование (UE)

4 Сервер приложений MTC

11, 12 Интерфейс сигнализации (или опорная точка)

31 Приложение MTC UE

51 Домашний абонентский сервер (HSS)

52 Агент маршрутизации Diameter (DRA)

53 Объект управления мобильностью (MME)

54 Сеть радиодоступа (RAN)

55 Обслуживающий шлюз (S-GW)

56 Шлюз сети пакетной передачи данных (P-GW)

57 Функция обнаружения трафика (TDF)

101 Блок управления

501 Блок управления

561 Блок сигнализации

562 Блок обработки пакетов

571 Блок сигнализации

572 Блок обнаружения